test(ui-tools): fix the diagnosis-map hydration race, and capture the bistable mobile-/ CLS finding

docs/outstanding-issues-inbox/02a39fa5-f889-4098-96a7-d5b9e5352b8f.json

@@ -0,0 +1,11 @@
+{
+ "version": 2,
+ "id": "02a39fa5-f889-4098-96a7-d5b9e5352b8f",
+ "createdOn": "2026-08-21",
+ "action": "update",
+ "payload": {
+ "id": "#JVYQEM",
+ "detail": "PARTIALLY STALE as of 2026-08-21 — verify before acting. The phone remedy this row proposes has already landed: --spacing-mode-home-composer-phone in src/app/globals.css now reads 10.125rem, not the 6.625rem recorded here, and the surrounding comment states the raise was made to cover the hint row. What remains open is the WIDE case, which that same comment calls out explicitly: --spacing-mode-home-composer-wide is still 5.5rem (88px) against a settled 160px at 1280 and 199px at 800, and it is deliberately NOT raised to match, because the sm+ surface swaps the phone ticket for a prompt-chip row that rewraps with viewport width, so no single static value is correct at every width. That needs a different mechanism (measure-and-publish, or a container-query reserve), not a bigger constant. Also: do NOT treat this row as the cause of the mobile-/ CLS 0.223 breach seen on PR #2199 — that value is bistable, an order of magnitude larger than the ~0.035 recorded here, and did not reproduce under either local harness; it has its own row. Next: confirm the phone case is closed by measuring a ticket-bearing mode home, then scope the wide-reserve mechanism separately.",
+ "baseRowFingerprint": "0bb1409b0da2428870573be1e788cef36978acc437a7c8e2c975e7813f1c928b"
+ }
+}

docs/outstanding-issues-inbox/3b9a4858-2665-4fe7-9ff4-ada3e650c644.json

@@ -0,0 +1,14 @@
+{
+ "version": 2,
+ "id": "3b9a4858-2665-4fe7-9ff4-ada3e650c644",
+ "createdOn": "2026-08-21",
+ "action": "add",
+ "payload": {
+ "pri": "P3",
+ "type": "task",
+ "summary": "Watch runner usage now that every main push gets its own CI concurrency group",
+ "detail": "PR #2209 (merged af2075a) changed ci.yml so base-branch pushes key concurrency on github.run_id. The defect it fixed was real: cancel-in-progress: false only prevents supersession, while GitHub separately keeps at most ONE pending run per concurrency group, so during a merge burst each newly queued main run cancelled the one already waiting. Observed 2026-08-20: a1c2ced, d745d15, 97f6142 and 1cc0d29 all cancelled while a ~70-minute release-browser-matrix held CI-refs/heads/main, and a mobile-/ CLS regression rode through that gap. The accepted cost is a real one and nobody has measured it yet: a burst of N merges now produces N concurrent runs instead of one plus a survivor, each carrying release-browser-matrix. The in-file comment already accepts this ('concurrent main runs, one per merge, each already scoped by the changes job'), but that was written as a prediction, not an observation. Next: after a few days of normal traffic, compare Actions minutes on main-branch pushes against the week before af2075a, and confirm no queueing/limit pressure appeared. If the cost is worse than the defect, the alternative is a bounded group (for example keyed on run_id only while a long job is in the workflow) rather than reverting to the shared group, which would restore the eviction hole. Pinned by the 'never cancels an in-flight run for a base-branch push' case in tests/ci-cache-safety.test.ts, which now also asserts the per-run key.",
+ "source": "PR #2209, merged af2075a; ci.yml concurrency block",
+ "issueUlid": "01M0HRBSN472G3XZ07F1XKV80V"
+ }
+}

docs/outstanding-issues-inbox/5f472de7-797f-49ba-8ba5-b5b6d4a7ad7a.json

@@ -0,0 +1,14 @@
+{
+ "version": 2,
+ "id": "5f472de7-797f-49ba-8ba5-b5b6d4a7ad7a",
+ "createdOn": "2026-08-21",
+ "action": "add",
+ "payload": {
+ "pri": "P2",
+ "type": "issue",
+ "summary": "mobile-/ Lighthouse CLS is bistable at 0.016 or 0.223 and reproduces only in CI, so the budget gate randomly reddens UI PRs and each looks like its own regression",
+ "detail": "BISTABLE, NOT A REGRESSION. Five CI measurements across PR #2199 heads: 175c641 FAIL (2/3 samples, cls 0.223), 74f39f0 FAIL (3/3, 0.223), 8506db3 PASS (no breach detected at all — 4 artifact files, no confirmation samples collected), c56d12d FAIL (2/3, 0.223), 4eabf0b FAIL. The decisive pair is 8506db3 -> c56d12d: the ONLY delta between those heads is 26 ledger JSON files under docs/outstanding-issues-inbox/, zero source code. The value recurring to three decimals is one discrete layout shift firing or not, rather than accumulating noise. NOT PR #2199's: it changes only DocumentViewer.tsx and document-viewer/document-overview-landing.tsx, and DocumentViewer is imported solely by src/app/(search-app)/documents/[id]/{page,loading}.tsx, so neither module is in the client bundle for /. TWO NEGATIVE LOCAL RESULTS, 2026-08-21, both in the Claude web container on Chromium 141: (1) scripts/measure-cls-attribution.mjs against / reported 'CLS=0.000 shifts=0' with the reserve timeline showing a single unset write at 436ms; (2) a full local npm run verify:lighthouse -- --keep, which applies Lighthouse's own mobile emulation and throttling, reported mobile-root cls 0.000 against the 0.016 baseline (ungraded: 'evidence incomplete — browser drift', HeadlessChrome/141 vs the baseline's /151). So the shift does not fire under either local harness and depends on something CI-specific — runner CPU contention, or Chromium 151 behaviour. NOT #JVYQEM, or at least not confidently: that row's phone remedy has already landed (--spacing-mode-home-composer-phone is 10.125rem, not the 6.625rem it records) and its scale (~0.035) is an order of magnitude below 0.223. NEXT STEP THAT DOES NOT NEED A REPRO: every failing run uploads a lighthouse-budget-<runid> artifact containing the full Lighthouse report; download lighthouse-budget-32463920997 (or any failing run) and read the mobile-root cumulative-layout-shift audit's debugdata, which names the shifting node directly. Only if that is empty is a CI-side attribution dispatch needed. Stop rules: do not raise the cls tolerance in lighthouse-budget.json to clear it; do not re-adopt the Lighthouse baseline while the metric is bistable, because the refresh would bake in whichever state that run happened to land on; and do not attribute it to a component without evidence from a run where it actually fired.",
+ "source": "CI runs 32412788947, 32415624534, 32459391430, 32460303619, 32463920997 on PR #2199; local attribution + Lighthouse runs 2026-08-21",
+ "issueUlid": "01M0HRMKMATYZK236NWYZM74NG"
+ }
+}

docs/outstanding-issues-inbox/dceb6940-445e-4dc4-93b1-3fd9aa51f3fe.json

@@ -0,0 +1,14 @@
+{
+ "version": 2,
+ "id": "dceb6940-445e-4dc4-93b1-3fd9aa51f3fe",
+ "createdOn": "2026-08-21",
+ "action": "add",
+ "payload": {
+ "pri": "P3",
+ "type": "task",
+ "summary": "Re-adopt the document-viewer Linux visual baseline after PR #2199 lands",
+ "detail": "PR #2199 makes document search on demand, which moves the document-viewer golden two ways: the overview action reads 'Search document' instead of 'Add to scope', and the closed composer releases the desktop sm:pb-40 clearance that was previously always reserved. The committed tests/__screenshots__/linux/document-viewer.png therefore drifts the moment that PR merges. This is ordinary pixel drift, which scripts/classify-visual-baseline-outcome.mjs scores advisory rather than red, and the visual-baseline job runs only on pushes to main — so the refresh point is post-land, from that run's artifact, via npm run design-system:baselines:adopt. Blocked until #2199 merges: adopting earlier would commit a golden for a state main does not have. Related: the same PR removed .document-viewer-composer from that target's mask (it is no longer rendered in the default state, and assertMaskSelectors fails loudly on a mask matching zero nodes), so the closed composer's resting layout is now inside the compared region rather than painted over. Stop rule: adopt from the CI artifact only, never from a developer machine or this container — font hinting alone would make every later run red, which is what the suite's own header warns about.",
+ "source": "PR #2199 (tests/ui-visual-baseline.spec.ts, commit e6d52b8); ci.yml visual-baseline job",
+ "issueUlid": "01M0HRBCD261TZJAHSXSFTMRTY"
+ }
+}

tests/ui-tools.spec.ts

@@ -2570,7 +2570,15 @@ test.describe("Clinical KB tools directory and legacy launcher", () => {
  test("diagnosis map keeps labels contained and the selected inspector out of the canvas", async ({ page }) => {
  await page.setViewportSize({ width: 320, height: 700 });
  await gotoLauncher(page, "/differentials/diagnoses/catatonia-in-mood-disorder?tab=map");
- await visibleByTestId(page, "open-diagnosis-map").click();
+ // `gotoLauncher` waits only for #main-content, so the trigger is present and clickable
+ // before React has attached its onClick. A click landing in that window is swallowed and
+ // the dialog simply never opens — which is how this test failed on CI run 32460303619
+ // ("element(s) not found" for the dialog after a 10s wait) while passing on the head
+ // immediately before it, whose only delta was ledger JSON. Same wait every other click in
+ // this file already uses.
+ const openMap = visibleByTestId(page, "open-diagnosis-map");
+ await waitForReactEventHandler(openMap);
+ await openMap.click();
 
  const dialog = page.getByTestId("diagnosis-map-dialog");
  const canvas = dialog.getByTestId("diagnosis-map-full-canvas");