fix(footer): send each documentation link to the section its label names #20

wtclaude · 2026-08-27T05:30:40Z

wtclaude commented

2026-08-27 05:30:40 +00:00

Reported from the live site. All three links under Documentation pointed at /docs/ — three labels, one destination, which is also the page the header's Docs link already opens.

before                          after
Getting started    -> /docs/    -> /docs/getting-started/requirements/
Administration     -> /docs/    -> /docs/administration/configuration/
Building a module  -> /docs/    -> /docs/modules/building-a-module/

Each now lands inside the section its label names. The docs home ("What is Runic Gateway?", the first page of Getting started) stays the header's link rather than becoming a fourth route to the same page.

Why nothing caught it

Worth writing down, because the answer is not "we were careless" — it is that the property was never asserted anywhere:


`checkLinks.mjs`	resolves every internal href against the build. `/docs/` resolves. Three links to a page that exists are three valid links
`checkSidebar.mjs`	compares the docs tree to `plannedSidebar`. The footer is not the sidebar
`checkA11y.mjs`	checks structure. Three correctly marked-up anchors are correct markup

The bug is not a broken link. It is a link that goes somewhere other than where its label says, and nothing in eleven checks or two suites was looking at that.

The guard

The columns move to src/data/footer.mjs, beside legal.mjs and collection.mjs — a column list inside an .astro component cannot be imported by a test, which is the whole reason for the move. test/footer.test.mjs then asserts six things:

every destination within a column is distinct;
no destination is repeated across columns;
each documentation link starts with its own section prefix (not merely /docs/, which is what shipped);
none of them is the docs home;
both documentation entry points are directory URLs under /docs/;
the two Project links still read brand.giteaOrg and brand.discordInvite rather than hard-coded values (§7, D13).

No new check script — this is a test in the existing suite, which is where it belongs and keeps D53 intact.

What was run

The guard was verified by reintroducing the bug: putting /docs/ back under Administration fails two tests with the message the next person would need —

✖ each documentation link lands inside the section its label names
  AssertionError: "Administration" points at /docs/, which is not inside /docs/administration/
✖ no documentation link is the docs home, which the header already carries

Restored, and npm run verify is green end to end:

checkSidebar / checkScreens / checkTokens / checkBrand / playDataSafety   pass
astro check: 0 errors        npm test: 42 pass, 0 fail   (36 + 6 new)
checkLinks: 2410 internal link(s) resolve and 124 repository link(s) point at a branch.
checkFacts: 19 facts agree with their authorities.
checkQuickstart: 59 checks passed against website main.
checkReference: 22 enumeration check(s) passed against their sources.
test:served: 7 pass, 0 fail
checkA11y: 50 built pages pass all seven structural checks.
checkCsp: 50 pages carry a policy; 410 inline scripts and 104 inline styles all hashed.

And the built page itself, since the data being right and the render being right are two claims:

rendered Documentation column, dist/client/index.html:
  Getting started      -> /docs/getting-started/requirements/
  Administration       -> /docs/administration/configuration/
  Building a module    -> /docs/modules/building-a-module/

Merging rolls the container over automatically; nothing to do on the host.

AI-assisted — written with Claude Code (Opus 5); commits carry Co-Authored-By: Claude.

🤖 Generated with Claude Code

Reported from the live site. All three links under **Documentation** pointed at `/docs/` — three labels, one destination, which is also the page the header's `Docs` link already opens. ``` before after Getting started -> /docs/ -> /docs/getting-started/requirements/ Administration -> /docs/ -> /docs/administration/configuration/ Building a module -> /docs/ -> /docs/modules/building-a-module/ ``` Each now lands **inside the section its label names**. The docs home ("What is Runic Gateway?", the first page of Getting started) stays the header's link rather than becoming a fourth route to the same page. ## Why nothing caught it Worth writing down, because the answer is not "we were careless" — it is that the property was never asserted anywhere: | | | |---|---| | `checkLinks.mjs` | resolves every internal href against the build. **`/docs/` resolves.** Three links to a page that exists are three valid links | | `checkSidebar.mjs` | compares the docs tree to `plannedSidebar`. The footer is not the sidebar | | `checkA11y.mjs` | checks structure. Three correctly marked-up anchors are correct markup | **The bug is not a broken link.** It is a link that goes somewhere other than where its label says, and nothing in eleven checks or two suites was looking at that. ## The guard The columns move to **`src/data/footer.mjs`**, beside `legal.mjs` and `collection.mjs` — a column list inside an `.astro` component cannot be imported by a test, which is the whole reason for the move. `test/footer.test.mjs` then asserts six things: - every destination within a column is distinct; - no destination is repeated across columns; - each documentation link starts with **its own section prefix** (not merely `/docs/`, which is what shipped); - none of them is the docs home; - both documentation entry points are directory URLs under `/docs/`; - the two Project links still read `brand.giteaOrg` and `brand.discordInvite` rather than hard-coded values (§7, D13). **No new check script** — this is a test in the existing suite, which is where it belongs and keeps D53 intact. ## What was run The guard was verified by **reintroducing the bug**: putting `/docs/` back under Administration fails two tests with the message the next person would need — ``` ✖ each documentation link lands inside the section its label names AssertionError: "Administration" points at /docs/, which is not inside /docs/administration/ ✖ no documentation link is the docs home, which the header already carries ``` Restored, and `npm run verify` is green end to end: ``` checkSidebar / checkScreens / checkTokens / checkBrand / playDataSafety pass astro check: 0 errors npm test: 42 pass, 0 fail (36 + 6 new) checkLinks: 2410 internal link(s) resolve and 124 repository link(s) point at a branch. checkFacts: 19 facts agree with their authorities. checkQuickstart: 59 checks passed against website main. checkReference: 22 enumeration check(s) passed against their sources. test:served: 7 pass, 0 fail checkA11y: 50 built pages pass all seven structural checks. checkCsp: 50 pages carry a policy; 410 inline scripts and 104 inline styles all hashed. ``` And the built page itself, since the data being right and the render being right are two claims: ``` rendered Documentation column, dist/client/index.html: Getting started -> /docs/getting-started/requirements/ Administration -> /docs/administration/configuration/ Building a module -> /docs/modules/building-a-module/ ``` Merging rolls the container over automatically; nothing to do on the host. --- - [x] **AI-assisted** — written with Claude Code (Opus 5); commits carry `Co-Authored-By: Claude`. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

wtclaude added 1 commit 2026-08-27 05:30:41 +00:00

fix(footer): send each documentation link to the section its label names

PR checks / checks (pull_request) Successful in 9m38s

Details

12c416f5fc

All three links under "Documentation" pointed at /docs/. Three labels — Getting
started, Administration, Building a module — and one destination, which is the
docs home and also what the header's Docs link already opens.

They now land inside the section they name:

  Getting started     /docs/getting-started/requirements/
  Administration      /docs/administration/configuration/
  Building a module   /docs/modules/building-a-module/

The docs home stays the header's link rather than becoming a fourth route to the
same page.

Eleven checks and two suites could not see this, and the reason is worth keeping:
the bug is not a broken link. checkLinks resolves every internal href against the
build and /docs/ resolves — three links to a page that exists are three valid
links. checkSidebar compares the docs tree to the planned tree and never looks at
the footer. checkA11y checks structure, and three correctly marked-up anchors are
correct markup. Nothing asserted that a link goes where its label says.

So the columns move to src/data/footer.mjs, beside legal.mjs and collection.mjs,
and test/footer.test.mjs asserts it: every destination in a column distinct, no
destination repeated across columns, each documentation link inside its own
section prefix, none of them the docs home, and the two Project links still read
from the brand. A column list inside an .astro component cannot be imported by a
test, which is the whole reason for the move.

Verified by reintroducing the bug: the suite fails with "Administration points at
/docs/, which is not inside /docs/administration/". Restored, npm run verify is
green — 42 tests, eleven checks, and the built index.html renders three distinct
hrefs.

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

whitlocktech merged commit 268e1c98fc into main

2026-08-27 05:31:36 +00:00

whitlocktech deleted branch fix/footer-docs-links

2026-08-27 05:31:37 +00:00

whitlocktech referenced this issue from a commit

2026-08-27 05:31:37 +00:00

Merge pull request 'fix(footer): send each documentation link to the section its label names' (#20) from fix/footer-docs-links into main

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/runicgateway.com#20