docs(issues): rank #017's mobile breach, withdraw a wrong #105 verification, restore #105 after an upstream deletion

[BigSimmo]

Summary

Docs only, one file. Four ledger changes: a new measured finding, a retraction of a claim made earlier in this same PR, the restoration of a row main deleted, and a new defect filed about how that deletion went unnoticed.

• #147 filed — mobile CLS breaches four routes, and it reproduces EXACTLY offline.#017 asked for the mobile breach to be ranked by measured contribution. Ranking it turned up something that changes what the work costs. Running the local offline production Lighthouse harness over the same five routes the live dispatch used, the mobile CLS numbers do not merely correlate with production — they match run 30548662649 to three decimals on all four locally measurable routes (/dsm 0.363, /documents/search 0.220, /therapy-compass 0.142, / 0.023), and the desktop range matches at both endpoints (0.016–0.097). /forms did not measure locally (Lighthouse NO_NAVSTART, its own "run again" transient); live it was 0.212. So CLS on these routes is deterministic layout structure, not network, latency, or production data — the CLS half of #017 is debuggable and gate-able locally at zero provider cost, and #017's recorded premise that production vitals need Supabase secrets is stale, since scripts/run-lighthouse-budget.mjs builds and serves an offline production app precisely to sidestep it. Its earlier "dev-mode CLS is excellent at 0.00–0.04" note was measuring dev, which does not reproduce production; that is why the breach looked locally unreachable. LCP does not reproduce and must not be read from local runs — 2014–2051 ms local against 3639–4716 ms live, because loopback has no network latency — though its ranking survives, with /therapy-compass the outlier both ways, corroborating #117.
• #105 stays open, and a verification claimed on it is withdrawn. An earlier revision of this PR closed #105 and archived it, on the strength of role="status" aria-label="Loading" appearing in the SSR HTML of /, /dsm and /forms. Those hits are real, but that exact string has exactly one renderer in src/ — ModeHomePageSkeleton (src/components/mode-home-page-skeleton.tsx:8). LoadingPanel never emits a bare "Loading" label; it renders aria-label={label}, always something specific like "Loading differentials". Re-checked per route against a running server, /, /dsm, /forms, /differentials and /favourites all return zeroLoadingPanel labels. The row is reopened with the withdrawn claim recorded in place, so the next person does not repeat it.
• Why it cannot be seen that way is the useful part. Codex's mechanism finding on this PR is correct and is not what failed: the installed Next 16 loader sets hasSuspenseBoundary whenever a loading element is supplied — not only when ssr is false — and BailoutToCSR throws on the server, so a mounted ssr:false surface does emit its fallback into the response HTML. What was missing is that this only fires for a surface that mounts during the initial render, and none of the eleven in clinical-dashboard-lazy.tsx do: every one sits behind interaction state (ClinicalDashboard.tsx:3666-4070). So neither a cold-load grep nor the throttled check the row originally prescribed can observe them. Both the row and its queue entry now say so, with an explicit stop rule against re-closing on a cold-load grep.
• #105 is also restored here, because main deleted it. Commit d8b034c8 (PR fix: guard upload limits in production builds #1441, "guard upload limits in production builds") removed three rows from the Open items table and added zero to the archive: #085, which that PR genuinely resolved by adding scripts/check-upload-limit-parity.mjs; #119, a duplicate of #122; and #105, which is open and unresolved. This branch mirrors main on the two dispositionable rows and keeps #105, which was not dispositionable. It survived only because the conflict was resolved row by row and re-diffed with column padding normalised away afterwards.
• #148 filed — a row can leave this ledger and no gate notices.npm run check:outstanding-issues validates duplicate ids, an id present in both tables, a stale issues:next-id marker, and malformed rows — every shape the 2026-07-29 triple collision took (#112). It never compares against the previous revision, so a row that simply disappears is invisible to it, in verify:cheap and in static-pr alike. The proposed fix is a deletion check against the merge base, explicitly not a union merge driver: #133 removed that driver deliberately, and reinstating it would bring back the duplicate-row damage it was removed to stop. The file's own Conventions already say "Keep them — do not delete", and #140 is precedent for archiving even a duplicate rather than removing it.
• #017 and the recommended queue are synchronised with all of the above, and #147 is de-duplicated against main's #118, which landed mid-review and already owns adopting the Lighthouse baseline. #147 contributes the constraint #118 was missing: pinning a baseline today would bake CLS 0.363 on /dsm in as the accepted value, so the CLS fixes must land first or the gate ratifies the breach it exists to catch.

On the diff size. The churn is large relative to the semantic change because of the Prettier markdown-table reflow recorded in ledger #133 — editing the widest cell in a column repads every row. Normalising column padding away, the change is the #017 queue and detail rows, the #105 queue and detail rows, the new #147 and #148 rows plus #147's queue row, and the issues:next-id bump.

On the merge conflicts. This branch hit five genuine conflicts with main on docs/outstanding-issues.md — every sync so far — each confirmed with git merge-tree --write-tree origin/main HEAD before acting rather than taken from GitHub's dirty label. That file deliberately carries no union merge driver (#133), so overlapping edits conflict loudly by design. Each was resolved row by row, never by taking a side: main's #086 X3 progress, #013 measurement-gating, #122, #145 and #146 were all kept alongside this branch's rows, and for one sync the rows were hashed rather than eyeballed to prove main had not touched #017 or #105. That per-sync cost — and the fact that the fifth sync arrived carrying an upstream row deletion — is an argument for merging this sooner rather than continuing to re-sync it.

Verification

Verification not run: npm run verify:pr-local — the diff is prose in docs/**, touching no source, test, config, schema or workflow file, so no build, browser, or DB gate applies. The gates that do cover this file were run and are pasted below.

• npm run check:outstanding-issues — Outstanding-issues guard passed: 144 rows (70 open, 74 archived), unique ids, next-id=149 above the highest, no merge driver. This is the gate that catches a bad conflict resolution or a stale id marker — though per #148 it is precisely the gate that does not catch a deleted row.
• npm run check:branch-review-ledger — passed; npm run ledger:dedupe reported No exact duplicate records in docs/branch-review-ledger.md (144 unique dated rows). Run because merging main five times brought ledger appends with it.
• npx prettier --check . — All matched files use Prettier code style! Whole-tree, not per-file, and run against the committed state.
• The #147 measurement itself: CHROME_PATH=/opt/pw-browsers/chromium npm run verify:lighthouse -- --keep, Lighthouse 12.8.2, Chromium 141.0.7390.37, nine of ten runs producing reports. CLS read back from each report's cumulative-layout-shift.numericValue.
• The withdrawal: grep -rn 'aria-label="Loading"' src/ --include=*.tsx returns one line, mode-home-page-skeleton.tsx:8; a per-route check of five routes against a running server returns zero LoadingPanel labels.
• The #148 claim: git show d8b034c8 -- docs/outstanding-issues.md shows three -| #… lines and zero +| #… lines, and none of #085, #105, #119 appears anywhere in origin/main's file, open or archived.
• Semantic diff re-derived with column padding normalised away after every sync, confirming the churn contains only the intended rows and that no main row was lost.

Deliberately not done: no Lighthouse budget baseline was committed.lighthouse-budget.json still has baseline: null and enforce: false, so that gate cannot yet catch a regression. The grader refused this run as incomplete evidence because /forms produced no report, and that refusal was correct and was not overridden. See the #118 note above for why a baseline should not be pinned yet even from a complete run.

UI verification not run: no UI, routing, styling, reduced-motion or forced-colors code changed. Note that verify:ui would not have caught the #105 error either — that was a wrong reading of a grep, not a rendering regression.

Risk and rollout

• Risk: Low. Tracking prose only; no code, no behaviour, no schema.
• Rollback: revert the single squash commit. That reinstates a known-wrong #105 verification instruction, drops #147 and #148, and re-deletes #105 — so a revert should be paired with restoring that row by hand.
• Provider or production effects: None. The Lighthouse measurement was a local offline production build with an inert loopback Supabase URL and the demo corpus; the route checks used a local dev server. The #017 live numbers were read from an already-completed dispatch, and nothing here re-dispatches it.

Notes

• Nothing under src/lib/rag/** or any other retrieval, ranking, or clinical surface is touched, so no RAG impact: line and no Clinical Governance Preflight is required — classifyPullRequestFiles sees one docs/** path.
• #148 records a defect whose cause sits on main, in another PR's conflict resolution. This branch records it and restores the one row that should not have gone; it does not attempt to repair #085/#119 back into the archive, which is a separate call for whoever owns that history.
• Two reproduction traps are recorded in #147 so the next Lighthouse run does not lose the time this one did: the harness reads CHROME_PATH/PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH (run-lighthouse-budget.mjs:291) but nothing in this container sets either despite PLAYWRIGHT_BROWSERS_PATH being set, so chrome-launcher fails on every route; and a truncated progress package in the npx cache broke Lighthouse startup outright.
• The three review threads (one Codex, two CodeRabbit) are answered. The Codex thread carries a follow-up correction: its mechanism claim was right, my application of it was not.
• Branch restarted from origin/main after test(rag): pin Supabase round-trip budgets on the answer path #1450 merged, keeping the same name, per the merged-PR rule.

🤖 Generated with Claude Code

https://claude.ai/code/session_01361jh3eYVjJCzXWjAhdZiF

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in:1 minute

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: a4d1c673-f71f-45ba-9173-d8ee26ef649c

📥 Commits

Reviewing files that changed from the base of the PR and between ff170ed and 7ec5bd0.

📒 Files selected for processing (2)

• docs/branch-review-ledger.md
• docs/outstanding-issues.md

📝 Walkthrough

Walkthrough

Updated two outstanding-issues queue entries with the graded Lighthouse result for row #017 and browser verification progress for row #105, including remaining LoadingPanel lazy-loading coverage.

Changes

Outstanding issue status updates

Layer / File(s)	Summary
Queue status records docs/outstanding-issues.md	Row #017 now records the dispatched and graded mobile Lighthouse result with all five routes breaching thresholds and remains open. Row #105 records verified preconnect behavior and identifies LoadingPanel lazy-loading coverage as the remaining work.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Possibly related PRs

• BigSimmo/Database#1043: Updates related Web Vitals baseline entries in the same outstanding-issues ledger.
• BigSimmo/Database#1377: Updates overlapping row #105 browser and UI verification status.
• BigSimmo/Database#1385: Introduces the Lighthouse dispatch and grading rules referenced by row #017.

Suggested reviewers:claude

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title is specific, concise enough, and matches the main docs-only changes to #017 and #105.
Description check	✅ Passed	The description covers the required Summary, Verification, Risk and rollout, and Notes sections with relevant detail.

---

_{Comment @coderabbitai help to get the list of available commands.}

[supabase]

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit:0c2e2b361b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/outstanding-issues.md`:
- Line 142: Update the queue entry for `#105` to remove the completed preconnect
verification and stop directing reviewers to run verify:ui. Align it with the
remaining LoadingPanel verification by requiring a throttled-network browser
check only, while preserving the existing queue format and references.
- Line 112: Update the recommended queue entry for `#017` to reflect that
Lighthouse evidence has already been dispatched and graded; replace the
instruction to capture evidence with the next action of ranking mobile findings
by measured contribution, consistent with the detailed `#017` row.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 031fbb10-5c99-4774-a0c3-9af8cd66ec95

📥 Commits

Reviewing files that changed from the base of the PR and between 9e1d9cf and ff170ed.

📒 Files selected for processing (1)

• docs/outstanding-issues.md