docs(website): phase 10 — public nav sections and added links, and the §7 amendment #108

wtclaude · 2026-08-08T05:44:49Z

wtclaude commented

2026-08-08 05:44:49 +00:00

Docs pair for RunicGateway/website#125. Targets edge.

Records the capability asked for before the cutover: dropdown sections in the public header, with the coded entries organised into them and admin-authored links alongside.

§7 is amended rather than quietly contradicted. It said the override layer "cannot introduce a to that is not already in the hardcoded NAV array". That remains true of every coded entry, and the restated constraint spells out what an added link may be — a same-origin path, carrying no gate of its own, advertising a route rather than granting one — plus why the property is structural rather than a check someone has to remember: coded entries live in a map keyed by routes the base array declares, and everything that can name an arbitrary path lives in links, where the rule is applied on both the write and the read path. A section has no route at all: it only opens, so it adds no reachable surface.

§6.4 gains the { items, sections, links } wrapper, with the two properties worth knowing — a bare map still reads as the items map, and a nav with no sections still stores one, so this changed nothing for a nav that does not use it.

§9 gains three acceptance criteria: an empty dropdown does not render at all, an added link cannot leave the origin, and deleting a section returns its entries to the top level rather than removing them.

"Phase 10 as landed" records why the Public tab needed its own tree editor (a public section is an entry in the top-level order, unlike the sidebar's fixed coded frame), why moving between containers stayed a dropdown rather than a cross-container drag, why the menu opens on click with a trigger that is not a link, that the shape change was free only because nothing had shipped — and the palette-vs-full-nav bug this surfaced in the phase 6–8 save path.

api-route-inventory.json is unchanged: phase 10 adds no routes.

Checklist

I have read CONTRIBUTING.md.
The change builds and existing tests/checks pass locally.
I have added or updated tests/docs where it makes sense.
My commits are reasonably scoped with clear messages.

AI-assisted contributions (required)

No AI tools were used to produce this contribution.
AI tools were used. Tool(s): Claude Code (Opus 5). I have reviewed and understand
every change, and take responsibility for it. AI-authored commits are
marked with a Co-Authored-By / Assisted-By trailer.

License

I agree that my contribution is licensed under this project's license
(GNU GPL v3.0 or later), and I have the right to contribute it.

Docs pair for RunicGateway/website#125. Targets **`edge`**. Records the capability asked for before the cutover: dropdown sections in the public header, with the coded entries organised into them and admin-authored links alongside. **§7 is amended rather than quietly contradicted.** It said the override layer "cannot introduce a `to` that is not already in the hardcoded `NAV` array". That remains true of every **coded** entry, and the restated constraint spells out what an added link may be — a same-origin path, carrying no gate of its own, **advertising** a route rather than **granting** one — plus why the property is structural rather than a check someone has to remember: coded entries live in a map keyed by routes the base array declares, and everything that *can* name an arbitrary path lives in `links`, where the rule is applied on both the write and the read path. A section has no route at all: it only opens, so it adds no reachable surface. **§6.4** gains the `{ items, sections, links }` wrapper, with the two properties worth knowing — a bare map still reads as the items map, and a nav with no sections still stores one, so this changed nothing for a nav that does not use it. **§9** gains three acceptance criteria: an empty dropdown does not render at all, an added link cannot leave the origin, and deleting a section returns its entries to the top level rather than removing them. **"Phase 10 as landed"** records why the Public tab needed its own tree editor (a public section is an entry in the top-level order, unlike the sidebar's fixed coded frame), why moving between containers stayed a dropdown rather than a cross-container drag, why the menu opens on click with a trigger that is not a link, that the shape change was free only because nothing had shipped — and the palette-vs-full-nav bug this surfaced in the phase 6–8 save path. `api-route-inventory.json` is unchanged: phase 10 adds no routes. ## Checklist - [x] I have read [CONTRIBUTING.md](CONTRIBUTING.md). - [x] The change builds and existing tests/checks pass locally. - [x] I have added or updated tests/docs where it makes sense. - [x] My commits are reasonably scoped with clear messages. ## AI-assisted contributions (required) - [ ] No AI tools were used to produce this contribution. - [x] AI tools were used. Tool(s): `Claude Code (Opus 5)`. I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a `Co-Authored-By` / `Assisted-By` trailer. ## License - [x] I agree that my contribution is licensed under this project's license (**GNU GPL v3.0 or later**), and I have the right to contribute it.

wtclaude added 1 commit 2026-08-08 05:44:51 +00:00

docs(website): phase 10 — public nav sections and added links, and the §7 amendment 2784cad6e4

Records the capability asked for before the edge -> main cutover: dropdown
sections in the public header, with the coded entries organised into them and
admin-authored links alongside.

§7 is amended rather than quietly contradicted. It said the override layer
"cannot introduce a `to` that is not already in the hardcoded NAV array"; that
remains true of every CODED entry, and the restated constraint spells out what an
added link may be — a same-origin path, carrying no gate of its own, advertising
a route rather than granting one — plus why the property is structural: coded
entries live in a map keyed by routes the base array declares, and everything
that can name an arbitrary path lives in `links`, where the rule is applied.

§6.4 gains the { items, sections, links } wrapper, including the two properties
worth knowing: a bare map still reads as the items map, and a nav with no
sections still stores one.

§9 gains three acceptance criteria — the empty dropdown does not render, an added
link cannot leave the origin, and deleting a section returns its entries to the
top level rather than removing them.

"Phase 10 as landed" records why the Public tab needed its own tree editor, why
moving between containers stayed a dropdown rather than a cross-container drag,
why the menu opens on click and its trigger is not a link, and the palette-vs-full-nav
bug this surfaced in the phase 6-8 save path.

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

whitlocktech approved these changes 2026-08-08 06:00:14 +00:00

whitlocktech merged commit 2e955f1e9c into edge

2026-08-08 06:00:20 +00:00

whitlocktech deleted branch docs/theming-nav-phase-10

2026-08-08 06:00:21 +00:00

whitlocktech referenced this issue from a commit

2026-08-08 06:00:22 +00:00

Merge pull request 'docs(website): phase 10 — public nav sections and added links, and the §7 amendment' (#108) from docs/theming-nav-phase-10 into edge

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/docs#108