BigSimmo · BigSimmo · Jul 30, 2026 · Jul 30, 2026
@@ -83,7 +83,7 @@ removed after current-main verification; it is not missing recommended work.
 | 34 | `#105` | Optional | High — browser/UI verification | When a driven-browser session is available | 30–60 minutes | Decide how the ten `LoadingPanel` fallbacks can be observed at all, then verify or re-scope. A cold-load grep cannot see them — every lazy surface mounts behind interaction state, so nothing renders them on first paint — and a claimed cold-load verification was withdrawn 2026-07-30 after it turned out to be matching `ModeHomePageSkeleton`. Either drive the interaction in a browser and assert the surface's specific label, or record that they are unobservable on cold load. The preconnect half is already verified; do not redo it. **Stop:** do not close this on a cold-load grep. |
 | 35 | `#126` | Optional | Standard — repository hygiene | Once per UTC calendar quarter, or when the live ledger grows large | 5–15 minutes | Run `npm run ledger:rotate -- --dry-run`, then `npm run ledger:rotate` if the preview looks right; commit the live+archive diff. Stop if dry-run shows unexpected mass moves or archive path collisions. |
 
-<!-- issues:next-id=151 -->
+<!-- issues:next-id=154 -->
 
 ## Open items
 
@@ -142,13 +142,16 @@ removed after current-main verification; it is not missing recommended work.
 | #147 | P2 | rec | Mobile CLS breaches four routes, and it reproduces exactly offline | **Outcome:** mobile CLS is under 0.1 on every measured route, or each remaining breach has a recorded reason. **Measured 2026-07-30 with the LOCAL OFFLINE production harness** (`CHROME_PATH=/opt/pw-browsers/chromium npm run verify:lighthouse -- --keep`; Lighthouse 12.8.2, Chromium 141.0.7390.37, demo corpus, inert loopback Supabase). Mobile CLS: `/dsm` 0.363, `/documents/search` 0.220, `/therapy-compass` 0.142, `/` 0.023 — `/forms` did not measure locally (Lighthouse `NO_NAVSTART`, its own "run again" transient), but the live dispatch put it at 0.212. Desktop passes everywhere: 0.016–0.097. **The finding that matters is that these reproduce the live production dispatch EXACTLY.** Against run `30548662649` on `psychiatry.tools`, all four locally measurable mobile routes match to three decimals — 0.023 / 0.142 / 0.220 / 0.363 on both — and the desktop range matches at both endpoints, 0.016–0.097. So CLS on these routes is deterministic layout structure, not network, latency, or production data. Three consequences: (a) the CLS half of `#017` is debuggable and gate-able locally at zero provider cost; (b) `#017`'s recorded blocker "prod server hard-requires Supabase secrets" is stale — `scripts/run-lighthouse-budget.mjs` builds and serves an offline production app precisely to sidestep that, and its earlier note that dev-mode CLS looked "excellent at 0.00–0.04" was measuring DEV, which does not reproduce production; (c) re-dispatching the live workflow to re-measure CLS buys nothing. **LCP does NOT reproduce and must not be read from local runs:** local mobile LCP is 2014–2051 ms against 3639–4716 ms live, because the loopback server has no network latency. The LCP _ranking_ does survive — `/therapy-compass` is the outlier both locally (4978 ms, ~2.4x every other route) and live — which corroborates `#117` rather than replacing it. Mobile TBT, local: `/documents/search` 581 ms, `/dsm` 448, `/therapy-compass` 379, `/` 338. **Ranking by measured contribution, which is what `#017` asked for:** 1. `/dsm` CLS 0.363 (3.6x the threshold, the worst single number anywhere); 2. `/documents/search` 0.220; 3. `/forms` 0.212 (live only); 4. `/therapy-compass` 0.142, and separately the sole LCP outlier via `#117`; 5. `/` 0.023, which passes and needs nothing. **Next:** attribute the shifts to elements. Lighthouse's `layout-shift-elements` audit returned **zero items on every route** — the `cumulative-layout-shift` audit carries only `debugdata` — so attribution needs a driven Chromium session with a `PerformanceObserver` on `layout-shift`, reading `entry.sources[].node` and `entry.value`, against the same offline production build. Start with `/dsm`. **Gate — `#118` owns it, and this row supplies a constraint it was missing.** `#118` already tracks flipping `lighthouse-budget.json` to `enforce: true` and says not to do it "before `#117` or the baseline pins a known-slow route". These numbers make that concrete: 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. Separately, no baseline could have been committed from this run anyway — the grader correctly refused it as incomplete evidence because `/forms` produced no report, and that refusal was not overridden. **Reproduction trap:** without `CHROME_PATH`, `chrome-launcher` cannot find a browser in this container and every route fails; the harness reads `CHROME_PATH`/`PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH` (`run-lighthouse-budget.mjs:291`) but nothing sets either, even though `PLAYWRIGHT_BROWSERS_PATH` is set. Related to `#121`. Also seen: a truncated `progress` package in the npx cache broke Lighthouse startup entirely; clearing the npx cache entry fixed it. **Stop:** do not re-dispatch the live Web-Vitals workflow to re-measure CLS — it is reproducible offline for free. Do not commit a budget baseline from a run with a failed route. Do not treat local LCP numbers as production LCP. | `#017` live run `30548662649`; local `verify:lighthouse` 2026-07-30; `lighthouse-budget.json` | 2026-07-30 |
 | #149 | P2 | issue | `check:installed-lock-parity` only compares seven top-level packages, so transitive drift passes | **Outcome:** a session cannot run local gates against a `node_modules` that silently disagrees with the lockfile. **Evidence 2026-07-30:** the `SessionStart` hook reported "node_modules matches the lockfile, skipping install" while `brace-expansion` was installed at **1.1.16** and the lockfile pinned **1.1.18** — the CVE-2026-14257 patch. Every local gate run in that window was weaker than it appeared, including several `verify:cheap` runs reported as green during PR #1430/#1444 work. It surfaced only because `tests/installed-lock-parity.test.ts` asserts the patched behaviour directly (`maxLength` honoured); its failure was initially mistaken for a pre-existing repo defect, since it also failed on clean `main` **in the same stale container**. `npm ci --include=dev` fixed it. **CORRECTION 2026-07-30 (PR #1496 review, Codex):** an earlier version of this row said the parity check lives only in `verify:ui` and proposed adding it to `verify:cheap`. **Both were wrong** — `verify:cheap:internal` already runs `check:installed-lock-parity`, so that follow-up was a no-op, and it ran green throughout the stale window. The real gap is its **scope**: `scripts/check-installed-lock-parity.mjs` compares only seven top-level packages (`criticalInstalledPackages` = next, react, react-dom, eslint, playwright, typescript, vitest), so a stale **transitive** dependency is invisible to it. Proved by faking `node_modules/brace-expansion` back to `1.1.16` against the `1.1.18` lockfile pin: `npm run check:installed-lock-parity` **exits 0**. That also explains why the hook and the gate both reported parity while the tree was stale — neither was looking at the package that drifted. **Next:** broaden the check beyond the seven names — validate the full installed tree against the lockfile, or stamp the install with the lockfile hash and compare that — so transitive drift is caught rather than assumed absent. **Stop:** do not treat a green `check:installed-lock-parity` as proof the install is lockfile-current; today it means seven packages match. | `scripts/check-installed-lock-parity.mjs`; `tests/installed-lock-parity.test.ts`; `package.json` | 2026-07-30 |
 | #150 | P2 | issue | CodeRabbit reviewed none of a full day's PRs; spending cap reached | **Outcome:** the repo's second automated reviewer is either funded or acknowledged as absent, rather than appearing to review while skipping. **Evidence 2026-07-30:** CodeRabbit posted "Review limit reached … Your organization has reached its usage spending cap" on **every** PR opened that day — #1404, #1430, #1444, #1445, #1479 — reviewing none of them. Each notice renders as an ordinary bot comment, so a skimming reader sees reviewer activity where there was no review. The Codex connector was the sole substantive reviewer across those PRs and found three real defects that had survived local gates and self-review: a proxy-variable inference in #1430, an `unset` vs `unspecified` git-attribute conflation in #1444, and an earlier P1 recursive-delete on an unvalidated `--dir`. **Next:** decide whether to raise the cap, switch to label-based opt-in so the budget lands on PRs that need it, or accept single-reviewer coverage explicitly. **Stop:** do not read a CodeRabbit comment as a completed review without checking it is not a rate-limit notice. | PRs #1404/#1430/#1444/#1445/#1479; `.coderabbit.yaml` | 2026-07-30 |
+| #151 | P3 | issue | `gh pr checks` cannot read CI, but the Actions API can | **Outcome:** nobody concludes CI is unverifiable when it is merely reached through a different endpoint. **Detail:** the session `gh` credential is a fine-grained PAT with **Actions: read** but **not Checks: read**. `gh pr checks` fails per context with `Resource not accessible by personal access token` and `GET /repos/:o/:r/commits/:sha/check-runs` returns 403, so the obvious routes look like a hard wall. `GET .../commits/:sha/status` succeeds but returns `total: 0`, because this repo reports through Actions rather than legacy commit statuses — a silent empty result that reads like an absence of checks instead of an absence of permission. **The working route** is `gh api "repos/BigSimmo/Database/actions/runs?head_sha=<sha>"` with a jq filter over `.workflow_runs[]`, which returned CI, PR Policy, PR mergeability, SAST and Secret Scan all `completed/success` for PR #1490. **Cost of not knowing this:** two PRs were handed off as green-locally-but-unverifiable and armed for auto-merge instead of merged; #1490 was then closed unmerged and its unique content lost (re-landed as #152). **Next:** either add Checks: read to the PAT so `gh pr checks` works, or document the Actions query as the supported way to read CI here. **Stop:** do not report CI as unreadable without trying the Actions endpoint. | session 2026-07-30; PRs #1490, #1494 | 2026-07-31 |
+| #152 | P2 | issue | Uncommitted work sits in worktrees whose branches are already merged | **Outcome:** work that exists in no branch and no PR is either committed or knowingly discarded, not lost to a disk reclaim. **Inventory 2026-07-30**, all on branches fully merged into `main`, so the changes existed nowhere else: `codex/reconcile-immediate-20260730` +395/-200 across 19 files including `.github/workflows/ci.yml` and `package.json`; `codex/document-results-mockup-20260730` 8 files plus an untracked `document-search-results/page.tsx` under `src/app/mockups/`; `codex/chat-ledger-triage-d344` `docs/outstanding-issues.md` +59/-61; `claude/section-spy-browser-coverage` `tests/ui-smoke.spec.ts` +51. **Preserved 2026-07-31, not reviewed:** each was committed on its own already-merged branch as a `wip: preserve uncommitted work before worktree cleanup` snapshot — `748ef018f`, `5dbd9f965`, `b7eae51a4`, `d949859c3` respectively. All four worktrees are clean now. None is pushed; the snapshots exist to stop silent loss, not to endorse the content. First captured in PR #1490, which was closed unmerged, so it is re-landed here. **Next:** per snapshot, review and either promote it to a branch/PR or `git reset --hard HEAD~1` to drop it. **Stop:** do not remove a merged branch's worktree without checking it for uncommitted work first — that check is why the 2026-07-30 cleanup removed only one of its two candidates. | session 2026-07-30 worktree cleanup; PR #1490 (closed) | 2026-07-31 |
 
 ## Resolved / archive
 
 Move resolved rows here with the resolution date and a one-line outcome. Keep them — do not delete.
 
 | ID | Type | Summary | Outcome | Resolved |
 | ---- | ----- | --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
+| #153 | issue | Pre-commit hook aborted commits in worktrees lacking the sync script | Resolved 2026-07-31 by PR #1494. `core.hooksPath` is an absolute path to the primary checkout, so `.githooks/pre-commit` runs from every linked worktree, including ones whose branch predates the docs-sync tooling and so lacks `scripts/update-docs-inventory.mjs`; those commits died with `MODULE_NOT_FOUND`. PR #1442 had already tracked the hook and script onto `main`, leaving only the guard, which #1494 added to `main`'s committed hook: the inventory task drops itself when its script is missing, and the all-tasks-empty early exit is re-checked (without that, an empty `docs_to_check` makes the trailing diff match every modified file and fail the commit for unrelated reasons). Verified in an isolated repository where the script genuinely does not exist — deleting it from a real worktree does not exercise this path, because the mixed-inputs guard sees the unstaged deletion and fails first. `codex/docs-sync-automation-pr` is superseded and can be abandoned. | 2026-07-31 |
 | #105 | task | Verify the #017-exempt client latency wins in a browser | Resolved 2026-07-30. The preconnect/dns-prefetch half was already proved in SSR and the live DOM. The remaining fallback was verified in driven Chromium by switching the dashboard from Answer to Documents while delaying the exact document-search-results chunk by 1.6 s: role=status with aria-label=Loading document results appeared after 315 ms at 1440x900 and 123 ms at 390x844, then disappeared when the chunk executed. The phone pass used keyboard activation, reduced motion, and forced colors, retained focus on Mode Documents, and had zero horizontal overflow. | 2026-07-30 |
 | #127 | issue | Document-route phone header intermittently failed to hide | Resolved 2026-07-30 by PR #1427, which fixed the short/clamped drag mechanism. Its runway polling and delivered-travel assertions then passed across the four recorded post-fix runs and the later PR #1480 exact-head browser/PWA document-header journeys, with no recurrence. | 2026-07-30 |