From 646123a286174160943e31e7fccc2a83a5df874e Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 21 Aug 2026 08:59:20 +0000 Subject: [PATCH 1/2] test(ui-tools): wait for the diagnosis-map trigger's React handler before clicking MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The dialog assertion failed on CI run 32460303619 with "element(s) not found" after a full 10s wait — the click had landed but nothing opened. `gotoLauncher` waits only for `#main-content`, so the trigger is present and clickable before React attaches its `onClick`, and a click inside that window is swallowed. This is a race, not a regression, and the runs prove it: `Production UI (3)` passed on head 8506db3 and failed on c56d12d, whose only delta was 26 ledger JSON files. Same code, different outcome. The file already carries `waitForReactEventHandler` with an `onClick` default and uses it before fifteen other clicks; this one call site simply predates that pattern. No assertion is weakened and nothing is skipped or quarantined — which would not have been permitted anyway on a single observation, under the three-reproductions-on-one-SHA rule in `tests/flake-ledger.json`. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01HoyoNN7nCUVDLaE84k6e6c --- tests/ui-tools.spec.ts | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/tests/ui-tools.spec.ts b/tests/ui-tools.spec.ts index 92c9f62c49..9706eb1f09 100644 --- a/tests/ui-tools.spec.ts +++ b/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"); From 8607102766d34d9327568fd2af77785ee0820498 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 21 Aug 2026 08:59:38 +0000 Subject: [PATCH 2/2] docs(issues): capture the bistable mobile-/ CLS, the baseline chore, and the concurrency follow-up MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Four inbox requests, none of which edit the canonical ledger: - P2 issue — mobile-/ Lighthouse CLS is bistable at 0.016 or 0.223 and fires only in CI. Records the five-run evidence, why PR #2199 cannot be the cause, and two negative local results: the attribution harness reports zero shifts, and a full local Lighthouse run with the same mobile emulation reports 0.000. Names the next step that needs no reproduction — read the mobile-root layout-shift debugdata out of a failing run's uploaded report artifact. - P3 task — re-adopt the document-viewer Linux visual baseline once PR #2199 lands. Blocked until then: adopting earlier would commit a golden for a state main does not have. - P3 task — watch runner usage now that every main push gets its own concurrency group (PR #2209). The in-file comment accepts the cost as a prediction; nobody has measured it. - update to #JVYQEM — marks it partially stale. Its phone remedy already landed (the token reads 10.125rem, not the 6.625rem the row records); the wide reserve is what remains, and it needs a mechanism rather than a bigger constant. Also warns against reading it as the cause of the 0.223 breach. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01HoyoNN7nCUVDLaE84k6e6c --- .../02a39fa5-f889-4098-96a7-d5b9e5352b8f.json | 11 +++++++++++ .../3b9a4858-2665-4fe7-9ff4-ada3e650c644.json | 14 ++++++++++++++ .../5f472de7-797f-49ba-8ba5-b5b6d4a7ad7a.json | 14 ++++++++++++++ .../dceb6940-445e-4dc4-93b1-3fd9aa51f3fe.json | 14 ++++++++++++++ 4 files changed, 53 insertions(+) create mode 100644 docs/outstanding-issues-inbox/02a39fa5-f889-4098-96a7-d5b9e5352b8f.json create mode 100644 docs/outstanding-issues-inbox/3b9a4858-2665-4fe7-9ff4-ada3e650c644.json create mode 100644 docs/outstanding-issues-inbox/5f472de7-797f-49ba-8ba5-b5b6d4a7ad7a.json create mode 100644 docs/outstanding-issues-inbox/dceb6940-445e-4dc4-93b1-3fd9aa51f3fe.json diff --git a/docs/outstanding-issues-inbox/02a39fa5-f889-4098-96a7-d5b9e5352b8f.json b/docs/outstanding-issues-inbox/02a39fa5-f889-4098-96a7-d5b9e5352b8f.json new file mode 100644 index 0000000000..35fca377e9 --- /dev/null +++ b/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" + } +} diff --git a/docs/outstanding-issues-inbox/3b9a4858-2665-4fe7-9ff4-ada3e650c644.json b/docs/outstanding-issues-inbox/3b9a4858-2665-4fe7-9ff4-ada3e650c644.json new file mode 100644 index 0000000000..11cf36e67a --- /dev/null +++ b/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" + } +} diff --git a/docs/outstanding-issues-inbox/5f472de7-797f-49ba-8ba5-b5b6d4a7ad7a.json b/docs/outstanding-issues-inbox/5f472de7-797f-49ba-8ba5-b5b6d4a7ad7a.json new file mode 100644 index 0000000000..b8d7fec57d --- /dev/null +++ b/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- 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" + } +} diff --git a/docs/outstanding-issues-inbox/dceb6940-445e-4dc4-93b1-3fd9aa51f3fe.json b/docs/outstanding-issues-inbox/dceb6940-445e-4dc4-93b1-3fd9aa51f3fe.json new file mode 100644 index 0000000000..e1b87973a2 --- /dev/null +++ b/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" + } +}