docs(website): Phase 2 PR 8 — the nav interleave and the feature-provider seam #133

wtclaude · 2026-08-11T04:43:21Z

wtclaude commented

2026-08-11 04:43:21 +00:00

Records Phase 2 PR 8 of the module system. Code: RunicGateway/website#135.

MODULE_SYSTEM.md gains the PR entry in §2.7 and built-it notes on §1.4 and §1.5. MODULE_API.md §3.3 is amended where building it settled something the draft had left open — or had wrong.

The amendments to §3.3

The pipeline arrow was backwards. It read defaults → role/feature filtering → admin overrides. Both layouts have always run the override merge first and the filter last, deliberately: that is what keeps the filter a boundary an override cannot cross (THEMING_AND_NAV.md §7). Corrected to defaults (core + modules) → admin overrides → role/feature filtering.
feature was documented as public-area-only. It now applies in all three areas. Core's admin and player navs still carry no flags — but a module row that declares a gate and has it silently ignored is a trap, so the field means one thing everywhere.
How a provider is found: by the module that registered the row, not by a prefix parsed out of the flag name. Core's own rows resolve against the owner id core, which core registers useShardFlags under, so the ten shard-gated header rows keep the exact strings they carry today and Phase 3 moves them without a rename.
What a provider hook returns — a Set-like, or null while in flight — and that every unknown fails open, since the server is the gate.
Why one hook per provider in a loop is legal (fixed-length list, registration complete before first render), and why the enumerator is a module export rather than a member of the registry object handed to modules.
Six details the interleave settled: unordered rows append rather than defaulting to 0; an ungrouped admin row gets its own trailing group rather than joining core's Dashboard/Account furniture; a module-created group is a legal override destination; a colliding to is dropped with a warning; and why the interleave must precede the override merge.

`MOD_PATHS`

Its replacement is recorded in both files, including the defect the derivation fixed: the moderator redirect was a third hardcoded list and it disagreed with MOD_PATHS about /admin/houses, so a moderator who clicked Houses in their own sidebar was bounced back to Moderation. THEMING_AND_NAV.md §7's "moderator confinement" note is amended to match, including that the redirect now derives from the base nav so an override cannot move that boundary either way.

AI disclosure

This contribution was AI-assisted (Claude Code). Commits carry Co-Authored-By: Claude <noreply@anthropic.com>.

Records Phase 2 PR 8 of the module system. Code: RunicGateway/website#135. `MODULE_SYSTEM.md` gains the PR entry in §2.7 and built-it notes on §1.4 and §1.5. `MODULE_API.md` §3.3 is amended where building it settled something the draft had left open — or had wrong. ## The amendments to §3.3 - **The pipeline arrow was backwards.** It read *defaults → role/feature filtering → admin overrides*. Both layouts have always run the override merge **first** and the filter last, deliberately: that is what keeps the filter a boundary an override cannot cross (`THEMING_AND_NAV.md` §7). Corrected to *defaults (core + modules) → admin overrides → role/feature filtering*. - **`feature` was documented as public-area-only.** It now applies in all three areas. Core's admin and player navs still carry no flags — but a module row that declares a gate and has it silently ignored is a trap, so the field means one thing everywhere. - **How a provider is found:** by the module that registered the row, not by a prefix parsed out of the flag name. Core's own rows resolve against the owner id `core`, which core registers `useShardFlags` under, so the ten shard-gated header rows keep the exact strings they carry today and Phase 3 moves them without a rename. - **What a provider hook returns** — a Set-like, or `null` while in flight — and that every unknown **fails open**, since the server is the gate. - **Why one hook per provider in a loop is legal** (fixed-length list, registration complete before first render), and why the enumerator is a module export rather than a member of the `registry` object handed to modules. - **Six details the interleave settled:** unordered rows append rather than defaulting to 0; an ungrouped admin row gets its own trailing group rather than joining core's Dashboard/Account furniture; a module-created group is a legal override destination; a colliding `to` is dropped with a warning; and why the interleave must precede the override merge. ## `MOD_PATHS` Its replacement is recorded in both files, including the defect the derivation fixed: the moderator redirect was a **third** hardcoded list and it disagreed with `MOD_PATHS` about `/admin/houses`, so a moderator who clicked Houses in their own sidebar was bounced back to Moderation. `THEMING_AND_NAV.md` §7's "moderator confinement" note is amended to match, including that the redirect now derives from the **base** nav so an override cannot move that boundary either way. ## AI disclosure - [x] This contribution was AI-assisted (Claude Code). Commits carry `Co-Authored-By: Claude <noreply@anthropic.com>`.

wtclaude added 1 commit 2026-08-11 04:43:23 +00:00

docs(website): settle the nav interleave and the feature-provider seam f740530eb8

Records Phase 2 PR 8 of the module system: MODULE_SYSTEM.md gains the PR
entry in 2.7 and the built-it notes on 1.4 and 1.5; MODULE_API.md 3.3 is
amended where building it settled something the draft left open or got wrong.

The amendments to 3.3:

- The pipeline arrow had role/feature filtering BEFORE admin overrides. The
  code has always been the other way round, deliberately - the filter runs
  last so it stays a boundary an override cannot cross (THEMING_AND_NAV 7).
- `feature` was documented as public-area-only. It applies in all three
  areas: core's admin and player navs still carry no flags, but a module row
  that declares a gate and has it silently ignored is a trap.
- How a provider is found: by the module that registered the row, not by a
  prefix parsed out of the flag name. Core's own rows resolve against the
  owner id `core`, which core registers useShardFlags under.
- What a provider hook returns, and that every unknown fails OPEN.
- Why calling one hook per provider in a loop is legal, and why the
  enumerator is a module export rather than a member of registry.
- Six details the interleave settled: unordered rows append rather than
  defaulting to 0; an ungrouped admin row gets its own trailing group rather
  than joining core's; a module-created group is a legal override
  destination; a colliding `to` is dropped with a warning; and why the
  interleave must precede the override merge.

MOD_PATHS' replacement is recorded in both files, including the defect the
derivation fixed: the moderator redirect was a third hardcoded list that
disagreed with MOD_PATHS about /admin/houses. THEMING_AND_NAV 7's
"moderator confinement" note is amended to match.

Code: website PR 8 (client-only; 160 client tests, manifest and OpenAPI
unchanged), verified with the 7.7 browser smoke.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech merged commit d66ee832c5 into main

2026-08-11 05:29:20 +00:00

whitlocktech deleted branch docs/module-nav-interleave

2026-08-11 05:29:21 +00:00

whitlocktech referenced this issue from a commit

2026-08-11 05:29:22 +00:00

Merge pull request 'docs(website): Phase 2 PR 8 — the nav interleave and the feature-provider seam' (#133) from docs/module-nav-interleave into main

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/docs#133