[jbspeakr]

Requested by Jan · project thread

What this changes

Jan found the pills on the MCP matrix repetitive and loud, and the "scan" links too, and asked for icons. Three things repeated across the whole table, and each one competed with the status glyphs, which are the data:

Place	Before	After
Column head, level	Outlined pill in its level colour (MUST in the threat red) on all 26 columns	Plain mono text in --ink-2, like the AS/RS party under it
Row head, classes	Two outlined pills on a second line (public oauth)	Two small line icons after the name, in --ink-2. The rows are one line again
Row head, scan	The word "scan" on every row	A small trace icon. It is faint until its row is hovered or focused, and turns --signal on its own hover
Cell	A <details> popover (and, with JS, a dialog) holding a copy of the observation	A link to that feature's row on the server page (/mcp/servers/<id>/#<feature-id>), highlighted with :target
Legend	Levels in their colours, "scan" next to a server's name	Levels in plain ink, and each icon beside its word

The class icons (ClassIcon.astro) are one stroked path each, with no colour:

• Access: a globe for public, a padlock for closed.
• Auth: two arrows for OAuth (the redirect and token exchange), a key for API key, and a dash for no authentication (like not applicable).
• Unknown, on either axis, is the dashed ring of a recorded unknown. A class nobody has stated yet is drawn fainter.

The words stay as the tooltip and as visually hidden text.

Why levels stay text. Levels have an order (MUST > SHOULD > MAY). Any icon set for them would read as a strength scale, and the dot and ring shapes are already taken by the status glyphs and by the changed and new marks. That keeps to "Neutral. Nothing is ranked or scored."

Why cells now link to the server page. Lighthouse's performance check on /mcp/ has failed on main since #74 (0.93–0.94 against a 0.95 minimum, blocking time around 300 ms against 200 ms). The ~900 inline observation copies were about 70% of the page: 1.2 MB and about 22,000 elements. The server page already shows every record, with its earlier observations.

• The page drops to 0.49 MB.
• Main-thread work on load roughly halves: 470 → 245 ms, median of 8 interleaved local runs at phone size.
• ObservationDetail and the cell dialog (M10) are removed.
• Spec 001's acceptance scenario 2 is amended. The design notes and the accessibility page's motion list are updated.
• Without JavaScript the cells are plain links, so the page still works.

The phone group switcher from #64 is unchanged. On phones the classes stay hidden, as before.

Also in this PR: the standards-map "recently revised" e2e test now waits for the fade to settle (toHaveCSS) instead of reading the opacity while the fade is still running. It flaked on main too.

Screenshots

From astro preview, 1440px and 390px. The cells look the same in the link version.

	Before (main)	After
Light
Dark
Phone

Row and legend, at 2×:

The screenshots were committed once for stable URLs and removed in the next commit, so the squashed diff has no images.

Code checklist

• pnpm check passes.
• CI is green on 9ddfc6c, Lighthouse included.
• Pages still read fully without JavaScript. The island now only filters and syncs the URL.
• Both themes checked. The baselines were refreshed with the refresh-screenshots label.
• docs/scanner.md, docs/design.md, spec 001 and the accessibility page are updated.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EqAPiJogKVL56XAubsugEh

[jbspeakr]

CI on bbbc9c9 failed only on standards.spec.ts › "recently revised is a view of the map" (light and dark). This PR doesn't touch the standards map. The test read the faded node's opacity while the transition was still running, and got 0.36 and 0.217 where it expected 0.2. It flaked the same way on the first run of this PR too. 841e2b2 swaps the one-shot read for toHaveCSS, which retries until the fade settles. It passed 9 of 9 locally. The matrix baselines from the refresh job pass.

---

Generated by Claude Code

[jbspeakr]

On 841e2b2 the e2e suite is green: 447 passed, including the standards-map fix. The only failure left is Lighthouse on /mcp/. The performance score was 0.93 against a minimum of 0.95, and Total Blocking Time was about 300 ms against a 200 ms budget.

This is not from this PR. main has failed the same assertion since #74 (run 39965428026: 0.94, TBT 284 ms). #76's run on main stopped at e2e before Lighthouse ran. This PR only adds 39 small SVGs and one hover rule to the matrix, and its numbers are within the run-to-run spread main shows (0.90–0.94). I know of no fix yet. I'm re-running the failed job once.

---

Generated by Claude Code

[jbspeakr]

9ddfc6c fixes the Lighthouse failure on /mcp/ at its cause. Each of the ~900 cells carried an inline copy of its observation for the popover and the dialog. Those copies were about 70% of the page: 1.2 MB and about 22,000 elements.

Each cell now links to its feature's row on the server page (/mcp/servers/<id>/#<feature-id>, highlighted with :target). That row already shows the status, method, date, observer, evidence and earlier records.

• The page drops to 0.49 MB.
• Main-thread work on load roughly halves: 470 → 245 ms, median of 8 interleaved local runs at phone size.
• ObservationDetail and the cell dialog (M10) are removed.
• Spec 001's acceptance scenario 2 is amended.
• The e2e tests follow the link instead.

Jan still has to choose between this and keeping slimmer popovers. If Jan picks the popovers, this commit gets reverted.

---

Generated by Claude Code