diff --git a/docs/outstanding-issues.md b/docs/outstanding-issues.md
index 6fbc240135..a0a243bda5 100644
--- a/docs/outstanding-issues.md
+++ b/docs/outstanding-issues.md
@@ -163,9 +163,12 @@ removed after current-main verification; it is not missing recommended work.
 | 110 | `#255` | A2 | High — Cloud/browser gates | Next environment image update | 2–4 hours | Align Cloud Playwright browser builds with lockfile pin; document CI delegation until then. **Stop:** do not force mismatched Chromium revisions. |
 | 111 | `#256` | A2 | High — mode section nav | Next information-page / mode-nav pass | 2–4 hours | Declared information-page section sets whose target ids nothing renders — verify each set against the rendered DOM per route; render anchors or delete the set. **Stop:** do not audit by grepping for `id=` alone (sectionId props exist). |
 | 112 | `#257` | Optional | High — formulation/specifiers flake | Standing until second reproduction | 15–30 min | Single unreproduced ui-formulation flake when run with ui-specifiers — record a second sighting only; do not quarantine until three on the same SHA. **Stop:** do not weaken assertions. |
+| 113 | `#286` | A3 | High — in-page nav + frontend | After owner go-ahead for the information-page series | 1–2 days | Convert the six pill-rail information pages onto `InPageNavHeader`, widen Server Component–safe actions, then delete `informationPageSectionDefinitions`. **Gate:** focused DOM/contract tests + `verify:phone-chrome` for touched owners. **Stop:** do not convert DocumentViewer here; do not verify anchors by grepping `id=` alone. |
+| 114 | `#287` | A3 | High — in-page nav + clinical owner | After `#286`; medications needs an owner product call | 0.5–1 day design + convert | Decide medications tab model, presentations MobileTabs vs `InPageNavHeader`, and factsheets heading→id scheme; convert or record lasting exceptions. **Stop:** do not port medications mechanically. |
+| 115 | `#288` | Optional | High — document chrome | After `#286`/`#287`, or when declaring the series complete | 30–60 min | Confirm DocumentViewer non-adoption (already noted in `docs/search-chrome-behaviour.md`) as the final end state, or schedule a separate convergence PR that leaves pinned `--document-*` CSS names untouched. |
 
 
-<!-- issues:next-id=287 -->
+<!-- issues:next-id=289 -->
 ## Open items
 
 > **Merged-main canary update (2026-07-23, run `30018289898`):** the new structured report correctly recorded evaluated tree `c24f2e8f2d30d0c59fc1eba025d3dcd63478137e`, run/attempt identity and `cross-region-runner` latency context. Golden retrieval remained 36/36 with document/content recall 1.0 and no failed cases. The 44-case answer gate had grounded-supported and unsupported-correct rates of 1.0, but failed because `neuroleptic-side-effect-escalation` again returned one citation where two are required (citation-failure rate 0.0227). `admission-discharge-comparison` again omitted the specific AKG admission document after `comparison_source_extractive_fallback`; `admission-discharge-coverage-paraphrase` was advisory-only at 24,870 ms. Answer cost was reported as `$0.234736`. Do not retry immediately: retain this as the first structured datapoint, compare it with the scheduled 2026-07-26 report, and keep retrieval/ranking unchanged.
@@ -294,8 +297,8 @@ removed after current-main verification; it is not missing recommended work.
 | #252 | P2 | issue | check:bundle-budget counts mockup chunks, contradicting #013's initial-bundle position | The budget's totalGzipBytes comes from measureChunkPaths(walkJsFiles(CHUNKS_DIR)) — EVERY built client chunk, including routes that 404 in production. The manifest-scoped initialDashboardChunks set is used only for the fixture-payload assertion, not the budget. So two repo positions disagree about mockups and nothing says so: #013 records that mockup chunks 'are not an initial production bundle' and must not be restructured without deploy-artifact evidence, while the gate charges them against a repo-wide ceiling. PR #1580 is the live cost — a mockups-only PR blocked on 'FAIL +10.1% vs baseline (tolerance 10%)' for chunks no user can load; it has sat red and unmerged since 2026-08-02. Docs now state the mechanism (AGENTS.md gate bullet, CLAUDE.md mockups bullet) so it stops being a surprise, but the metric decision is unmade. Next action: pick one and make the script say so — (a) exclude mockup-only chunks from totalGzipBytes so the number means production weight, which matches #013 but removes all back-pressure on mockup growth (59 routes on main today, 4 more in open PRs); or (b) keep counting them, rename the reported metric so it does not read as production bundle weight, and treat the tolerance as a deliberate hygiene ceiling. Option (b) additionally wants the mockup share reported separately, which is the measurement #013 asks for before any prune. Stop: do not raise the tolerance or run --update to clear #1580 — that discards the only back-pressure without deciding anything. Renumbered from this PR's original #249 → #252 because main claimed #249–#251 via PR #1624. | session 2026-08-05 open-PR review; PR #1580 Build log; scripts/check-bundle-budget.mjs; ledger #013 | 2026-08-05 |
 | #253 | P3 | task | #1606 needs a hand-merge against merged PR #1615, not a rebase | SUPERSEDED IN PART 2026-08-07: the component both PRs rewrite no longer exists. `MobileResultFilterControl` — the native `<select>` whose system-blue selected-value highlight #1606 set out to fix — was deleted when every mode moved to `ResultFilterTrigger` + `ResultFilterSheet` (#247). The blue-highlight defect is therefore gone by removal rather than by #1606's portal menu, and #1615's iOS 16px anti-zoom rule no longer applies to any phone results filter (it still governs other native selects; see search-chrome-behaviour rule 5). What is left of this row is a decision, not a merge: #1606 is still open and cannot be rebased onto a function that was deleted. Recommend closing it as superseded rather than hand-merging — but that is a human call, and this row stays open until someone makes it. On keyboard parity, correcting an earlier version of this row that claimed otherwise: `ResultFilterSheet` does NOT use native radio inputs. It is `role="radiogroup"` over buttons with a bespoke roving-tabIndex handler — one tab stop per group, Arrow/Home/End moving focus, selection following except onto a dead end — modelled on `SegmentedControl`. That is the same shape #1606 hand-rolled, so parity is plausible but not free; the DOM tests in `tests/search-results-header-band.dom.test.tsx` pin it, and a real-device pass is still worth doing before closing #1606. The Codex P2 about ArrowDown focusing a disabled placeholder is answered by construction: arrowing onto a dead end moves focus so its note is announced but never commits it, asserted by "puts a dead end on the arrow path without ever selecting it". | session 2026-08-05 open-PR review sweep; PR #1606 (open, dirty, verified live); Codex review thread on search-results-header-band.tsx:696 | 2026-08-05 |
 | #254 | P2 | issue | PR #1617's Codex Cloud acceptance evidence is pinned to a head the branch has moved past | PR #1617 is the surviving side of the Codex Cloud MCP dispute (PR #1613 was closed against it on 2026-08-05), and its whole case rests on one first-hand measurement: a fresh Codex Cloud task reporting 'no Railway tool exposed', 'no Supabase tool exposed', 'no GitHub tool exposed' — zero provider tools from repo-written MCP config — while the hosted OAuth path passed in ChatGPT. That evidence is recorded in docs/audit/cloud-connection-acceptance-2026-08-05.md against task head 76dfe85fa93787b3845d0bd460aa18ff753ca2ca, and the PR body states 'The final branch head is 7d485f88db391cc7e8e73c57ddbde61f532375fc'. The branch head is now bf7684a77ef5fa5d53a1e7891cb7f446d4741e4a, so both pins are stale and the acceptance no longer describes what would merge. This matters more than usual because the acceptance IS the argument: #1613 was closed on the strength of it, and its own merge gate is the kind of exact-head check that a moved head invalidates. Next action: before #1617 leaves draft, re-run the fresh Codex Cloud acceptance at the exact current head and update both the report and the body pin, or state explicitly which parts of the evidence are head-independent (the connector-page absence of Railway/Supabase is a product-surface fact and does not depend on the head; the zero-tool discovery result does). Stop: do not treat the 76dfe85f/7d485f88 evidence as covering the current head, and do not reopen #1613 on the basis that #1617's evidence is stale — staleness is not refutation. Renumbered from this PR's original #251 → #254 because main claimed #249–#251 via PR #1624. | session 2026-08-05 open-PR review sweep; PR #1617 body and docs/audit/cloud-connection-acceptance-2026-08-05.md | 2026-08-05 |
-| #255 | P2 | issue | Remote/Cloud containers cannot run any browser gate: Playwright lock drift plus a missing Chromium build | Remote/Cloud containers cannot run any browser gate: Playwright lock drift plus a missing Chromium build. In the 2026-08-05 remote container, npm run verify:pr-local failed closed at its first precondition — 'check:installed-lock-parity ... playwright: installed 1.62.0 does not match locked 1.62.1' — and Chromium could not launch: the image ships chromium-1194 while the pin wants revision 1234. So verify:ui, verify:phone-chrome and verify:release are unrunnable remotely regardless of the diff. Fix is image/pin alignment, not an install. Second reproduction 2026-08-07 (PR #1670): identical versions two days later on a different image instance, on a docs-only diff with no browser gate in its plan — so the blast radius is any scope, not just browser proof. THIRD REPRODUCTION 2026-08-08 (Claude Code on the web, PR #1744): identical versions again. New and more useful than the repetition: this row's Stop rule was VIOLATED, which is itself the finding. That session set PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH=/opt/pw-browsers/chromium-1194/chrome-linux/chrome and ran the full Chromium suite against the mismatched 1194 build, reporting '406 passed, 2 failed' into a PR body as browser evidence. Per this row that run is NOT evidence, and the PR merged with it presented as such. Two contributing causes worth fixing rather than just re-recording: (a) the workaround is SUGGESTED BY THE TOOLING — scripts/run-playwright.mjs's own preflight prints 'or set PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH to a launchable Chromium binary', so a session following the error message lands exactly on the forbidden path; (b) nothing outside this ledger states the prohibition, so a session that has not read docs/outstanding-issues.md cannot know. Next action, sharpened: align the image's Playwright browser builds with the lockfile pin; AND change run-playwright.mjs's preflight message so it stops recommending the override (or makes it print an explicit 'not valid as gate evidence' warning when used); AND state the prohibition in docs/testing.md where a session actually looks. Stop: do not set PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD or point executablePath at a mismatched build to force a green browser run, and do not quote such a run as browser evidence in a PR body — a browser gate run against the wrong revision is not evidence. Related but distinct from #149 (parity checker scope) and #285 (Node floor blocking npm ci). | session 2026-08-05 open-PR review sweep; verify:pr-local and verify:phone-chrome attempts on PRs #1620/#1621 | 2026-08-05 |
-| #256 | P2 | issue | Declared information-page section sets whose target ids nothing renders | A set in informationPageSectionDefinitions claims its route before the mode branch, then AvailableInformationPageNavigation drops every item whose targetIds are absent from the DOM and returns null, so the page shows no navigation at all. Proven live on PR #1647: specifierSections/formulationSections declared ten ids (specifier-overview, formulation-five-ps, and eight more) that no component rendered; invisible while those pages carried their own subnav, a dead end the moment it moved to the shared bar. Fixed for those two by wiring the anchors in. CONFIRMED 2026-08-07 (session after PR #1679), both remaining suspected sets are dead, so two live routes currently draw NO section nav: (1) /forms/<slug> — formSections declares six targetIds; form-detail-page.tsx:881 carries form-decision-context-mobile as a testId, NOT an element id, and form-overview, form-priority-facts, form-legal-boundary, form-information and form-source-verification-mobile are rendered nowhere in src/components. (2) /differentials/presentations/<slug> — all six differential-presentation-* targetIds absent; checked for a dynamic builder too, and the only template-literal section id in that family is differential-section-${section.id} in differential-detail-page.tsx, a different prefix on a different route, so nothing is hiding behind a sectionId prop here. Next: per route, either render the anchors or delete the declared set; forms and differential-presentations are independent and can be separate commits. Do NOT audit by grepping for id= alone: several live sections render through a sectionId prop (source-evidence), so a source scan reports them dead — assert against the rendered DOM per route, as tests/page-secondary-navigation.dom.test.tsx already does for services/specifiers/formulation. | session 2026-08-06 PR #1647; diagnosis completed 2026-08-07 alongside PR #1679 | 2026-08-06 |
+| #255 | P2 | issue | Remote/Cloud containers cannot run any browser gate: Playwright lock drift plus a missing Chromium build | In the 2026-08-05 remote container, npm run verify:pr-local failed closed at its first precondition — 'check:installed-lock-parity ... playwright: installed 1.62.0 does not match locked 1.62.1' — and Chromium could not launch at all: 'Executable doesn't exist at /opt/pw-browsers/chromium_headless_shell-1234/...' while the image only ships chromium-1194 and chromium_headless_shell-1194. So verify:ui, verify:phone-chrome and verify:release are all unrunnable in a remote session regardless of the diff, and verify:pr-local cannot even reach its selected gates. This is not a one-off 'run npm ci': the installed Playwright disagrees with the lockfile, and installing the locked 1.62.1 would request a browser revision the image also does not carry, so the fix is an image/pin alignment rather than an install. Consequence worth writing down: PRs authored from remote sessions can only produce static and unit evidence locally and must delegate browser proof to CI's Production UI jobs, which is what #1620/#1621/#1622 did — #1621's Chromium evidence came entirely from CI (0 failed of 17, all three Production UI shards). Next action: align the container image's Playwright browser builds with the lockfile pin, or document the delegation explicitly in docs/testing.md so a remote session does not read a fail-closed parity error as a defect in its own change. Related but distinct from #149, which is about the parity checker only comparing seven top-level packages rather than about an actual blocking drift. Stop: do not work around it by setting PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD or pointing executablePath at the mismatched 1194 build to force a green browser run — a browser gate run against the wrong revision is not evidence. Renumbered from this PR's original #252 → #255 because main claimed #249–#251 via PR #1624. **Second reproduction 2026-08-07 (remote container, PR #1670):** identical parity failure, same versions — 'playwright: installed 1.62.0 does not match locked 1.62.1' — two days later on a different image instance, so this is a standing property of the remote image rather than one bad container. New detail: the diff was docs-only (two append-only ledger files), and parity still halted `verify:pr-local` at step 2 of a 10-step plan that contained no browser gate at all. So the blast radius is wider than browser proof: a remote session cannot complete the PR-local gate for ANY scope, and has to re-run the selected steps by hand to get evidence (done there: the remaining eight all passed). That strengthens the documentation half of the next action — docs/testing.md should say a remote session may see this on a diff that never touches a browser. | session 2026-08-05 open-PR review sweep; verify:pr-local and verify:phone-chrome attempts on PRs #1620/#1621 | 2026-08-05 |
+| #256 | P2 | issue | Declared information-page section sets whose target ids nothing renders | A set in informationPageSectionDefinitions claims its route before the mode branch, then AvailableInformationPageNavigation drops every item whose targetIds are absent from the DOM and returns null, so the page shows no navigation at all. Proven live on PR #1647: specifierSections/formulationSections declared ten ids that no component rendered; fixed for those two by wiring the anchors in. RE-VERIFIED 2026-08-08 against origin/main e71b23b, which corrects the 2026-08-07 diagnosis in both directions. (1) FORMS IS FIXED - all six formSections targetIds now render as element ids: form-overview (form-detail-page.tsx:700), form-priority-facts (:823), form-legal-boundary (:835), form-information (:859), form-source-verification-mobile (:882), form-decision-context-mobile (:891). The earlier reading that these were rendered nowhere, and that form-decision-context-mobile was a testId only, no longer holds - :891 carries the element id and :892 additionally passes the same string as a testId. (2) DIFFERENTIAL-PRESENTATIONS SHELL SET IS CLOSED - `differentialPresentationSections` was deleted and `/differentials/presentations/` is declared locally owned in `page-secondary-navigation.tsx` (hasLocalInformationPageNavigation). The page uses MobileTabs / review sidebar; remaining product work to adopt `InPageNavHeader` (or record a lasting exception) lives under #287, not this dead-targetIds defect. (3) NEW, NOT PREVIOUSLY RECORDED - two DSM routes have the same defect: /dsm/diagnoses/[slug] declares five sections and renders three (key-features and record-summary are absent as element ids; Key features carries id=key-features-title on its h2 only, dsm-diagnosis-page.tsx:107), and /dsm/diagnoses/[slug]/differentials declares four and renders one (dsm-differential-filters, :108; dsm-differential-overview, -considerations and -clarify exist nowhere - nearest real elements are the h3s why-consider-title :213, features-favour-title :225, clarify-title :252). **Next:** the DSM half is in scope for #286; presentations shell ownership is already local (see #287 for the InPageNavHeader product decision). This row stays open until the DSM dead anchors land, then closes. Do NOT audit by grepping for id= alone - several live sections render through a sectionId prop (source-evidence), so a source scan reports them dead; assert against the rendered DOM per route, as tests/page-secondary-navigation.dom.test.tsx already does for services/specifiers/formulation. | session 2026-08-06 PR #1647; diagnosis completed 2026-08-07 alongside PR #1679 | 2026-08-06 |
 | #257 | P3 | issue | Single unreproduced ui-formulation flake: keeps specifier and formulation route families clinically separate | Observed once on 2026-08-06 at PR #1647 head f5833acc, running tests/ui-formulation.spec.ts + tests/ui-specifiers.spec.ts together against local Chromium (1 failed, 11 passed). Did NOT reproduce: passed in isolation with --grep, and passed again on a full-file re-run (7/7). Recorded only so a second sighting is recognisable as a second rather than looking like a first. Per docs/testing.md this is one reproduction of three — do NOT quarantine, and do not weaken the assertion. Next: no action unless it recurs; if a second reproduction lands on the same SHA, note it here, and only on a third open a tests/flake-ledger.json entry with @quarantine and a <=30-day expiry. | session 2026-08-06; PR #1647 | 2026-08-06 |
 | #258 | P2 | rec | The PR-handoff stop rule is enforced for Claude Code only; Codex and Cursor get prose with no gate | **Outcome:** a session that opens a PR stops following it in every agent this repo supports, not just Claude Code. **Detail:** PR #1649 added `.claude/hooks/pr-handoff-stop.sh` plus the AGENTS.md "Stop when the pull request is open" section. The hook is registered in `.claude/settings.json`, which only Claude Code reads, so the PostToolUse marker and the PreToolUse denials (shell `gh pr checks/status/view/run watch`, GitHub MCP tools named pull_request/workflow_run/workflow_job/check_run/check_suite/job_log/update_branch, and Monitor/ScheduleWakeup/CronCreate) simply do not exist for Codex or Cursor sessions. Those agents get the AGENTS.md prose and nothing else — and prose alone is exactly what was already in force, and already insufficient, before #1649. Cost is the same long tail of post-handoff CI polling the hook was built to cut, just relocated to whichever agent lacks the gate; a cloud Codex session is the worst case because nothing naturally ends it. **Next:** cheapest first — check whether Codex and Cursor expose any pre-tool interception this repo can register (Codex plugin hooks under `plugins/clinical-kb/`, Cursor rules under `.cursor/`); if neither offers a deny path, the fallback is a shared marker file plus a wrapper the agent is told to route `gh` through, which is weaker but still detectable. If no mechanism exists at all, record that explicitly here so the gap is a known limit rather than an open task. **Stop:** do not weaken the Claude Code hook to make the tools symmetric, and do not add a second copy of the deny list — one script, multiple registrations. | PR #1649; .claude/hooks/pr-handoff-stop.sh; .claude/settings.json; AGENTS.md "Stop when the pull request is open"; session 2026-08-07 | 2026-08-07 |
 | #260 | P2 | task | Two unpushed Sentry commits are stranded on a Windows-only branch and will be lost with that machine | **Outcome:** the Sentry setup/logging-hardening work is either shipped or consciously discarded, not left sitting in one machine's reflog. **Detail:** `claude/cloud-pr-loop-prevention-bc052b` carries two commits — `c3c9d6a31` and `abbcdc8e9`, ~389 lines across `src/sentry.*.config.ts`, `src/lib/env.ts`, `src/lib/supabase/client.tsx`, `src/components/ui-primitives.tsx` — that were never pushed and are not the authoring session's own work. The branch does not exist on the remote, so the commits are unreachable from any cloud or remote container; a 2026-08-07 remote session could not inspect, verify, or ship them and could only record their existence. The same worktree (`.claude/worktrees/pensive-borg-6be2f0`) still holds the same four files uncommitted. Two Sentry branches DO exist on origin — `claude/sentry-nextjs-sdk-setup-2v24q5` and `cursor/sentry-nextjs-sdk-7cee` — but whether either already carries this change is unconfirmed: a three-dot diff against `origin/main` from the remote container returned empty for both, which is not trustworthy as proof either way and was not pursued further. Note this touches `src/lib/env.ts` and `src/lib/supabase/client.tsx`, so it is not a docs-class change and needs a real gate whenever it does ship. **Next:** from the Windows machine, diff those two commits against the two remote Sentry branches to decide whether the work is already represented. If it is, delete the branch; if it is not, push it and open a PR rather than leaving it local. **Stop:** do not discard the commits blind, and do not assume the remote Sentry branches supersede them without a content diff — nothing has yet compared them. | session 2026-08-07 remote container; handoff notes from the PR #1649 session; origin branches claude/sentry-nextjs-sdk-setup-2v24q5 and cursor/sentry-nextjs-sdk-7cee | 2026-08-07 |
@@ -321,8 +324,10 @@ removed after current-main verification; it is not missing recommended work.
 | #282 | P3 | task | Probe the corpus for JBIG2/JPX before deciding whether pdf.js needs its decoder assets shipped | **Outcome:** a measured decision about pdf.js's cMap/standard-font/WASM assets rather than an assumption either way. **Detail:** getDocument is configured with url plus the on-demand fetch flags and nothing else, so 'wasmUrl', 'standardFontDataUrl', 'cMapUrl' and 'iccUrl' are all unset. pdfjs-dist ships those assets (wasm 1.5 MB, standard_fonts 804 KB, cmaps 1.7 MB) and nothing copies them into public/. With wasmUrl null, 'useWorkerFetch' resolves false and the WASM image decoders cannot load, so JBIG2 and JPEG2000 images fall back to the JS decoders or fail; those are exactly the encodings a scanned guideline uses, and this repo runs an OCR pipeline, which implies scanned sources exist. Non-embedded standard-14 fonts fall back to system fonts, which is a fidelity risk on a clinical document rather than a failure. **Next:** sample the real corpus for JBIG2/JPX-encoded images and for PDFs relying on the standard 14 before shipping ~2 MB of static assets; if the corpus does use them, copy into public/pdfjs, set the URLs, and add immutable cache headers in next.config.ts (public/ is not counted by check:bundle-budget, so there is no budget risk — the cost is bytes over the wire on first use). **Stop:** do not ship the assets on the assumption alone. | session 2026-08-08 document-viewer optimisation; node_modules/pdfjs-dist/types/src/display/api.d.ts | 2026-08-08 |
 | #283 | P3 | rec | The 100-id batch signed-URL route still has no caller | **Outcome:** either the batch minter is used or it is retired, rather than sitting as an untested, unreachable privileged surface. **Detail:** src/app/api/images/signed-urls/route.ts POSTs up to 100 image ids and returns their signed URLs, with its own rate limit, owner scoping and committed-generation filter. Nothing in src/ calls it — only tests/private-access-routes.test.ts imports it. The viewer resolves images one at a time through use-signed-image-url.ts. The 2026-08-08 pass added in-flight deduplication there, which removes the duplicate-consumer case (a figure and its lightbox racing for the same asset) but not the many-distinct-images case: a page of N figures is still N round trips where one batch call would do. **Next:** decide deliberately — wire the rail/filmstrip to the batch route when a page mounts several distinct images at once, or delete the route and its tests. The cost of leaving it is a privileged endpoint no product code exercises. **Stop:** if wiring it, keep the per-image endpoint for the lightbox's retry path; do not make the batch the only way to mint a URL. | session 2026-08-08 document-viewer optimisation; src/app/api/images/signed-urls/route.ts | 2026-08-08 |
 | #284 | P3 | issue | tests/pr-handoff-stop.test.ts fails whenever the suite runs as root | **Outcome:** 'npm run test' is green in a root container, so a real failure is not hidden behind a known one. **Detail:** 'pr-handoff-stop hook > emits handoff context only when the marker file exists' expects markerExists('sess-readonly') to be false — it makes the marker directory read-only and asserts the hook could not write there. Root ignores the permission bits, so the write succeeds and the assertion fails. Reproduced on an unmodified bc33d41 checkout as well as on the viewer-optimisation branch, so it is environment-dependent, not a regression. Cost is that every full-suite run in a root container reports '1 failed', which trains readers to skim past the failure count. **Next:** skip the case when 'process.getuid?.() === 0' with an explicit reason, or drop privileges for that assertion. **Stop:** do not delete the coverage — the read-only case is the point of the test on a normal user account. | session 2026-08-08 full-suite runs; reproduced on bc33d41 | 2026-08-08 |
-| #285 | P2 | issue | Node 24.13.0 in the Claude Code web container blocks npm ci entirely (jsdom engine floor) | Measured 2026-08-08 in a Claude Code on the web container. `npm ci --include=dev` cannot complete at all: it aborts with EBADENGINE — 'Not compatible with your version of node/npm: jsdom@30.0.1 ... Required: {node: ^22.22.2 \|\| ^24.15.0 \|\| >=26.0.0} Actual: {node: v24.13.0, npm: 11.17.0}'. The repo requires Node 24.x and 24.13.0 satisfies that major, so `check:runtime` passes ('PASS: Node runtime 24.13.0 matches required Node 24.x') while the documented install command is unrunnable. Consequence: when the container's node_modules is incomplete (see #149), the repo's own documented repair — `npm ci --include=dev` — is unavailable, and a session must fetch individual packages by tarball to proceed. Because engine-strict is on, no single-package `npm install` works either: npm evaluates the whole tree and fails on jsdom regardless of the package requested. Next action: raise the container image's Node to >= 24.15.0, or (weaker) record in docs/codex-cloud.md and docs/testing.md that npm ci is unavailable below 24.15.0 so a session does not read the abort as a repo defect. Stop: do not work around it with --engine-strict=false or --force; AGENTS.md forbids bypassing engine checks, and the tree it produces would be unverified. Distinct from #204 (npm install/npm ci lockfile disagreement) and from #149 (parity checker scope) — this is the install command being blocked before any lockfile question arises. | session 2026-08-08 (PR #1744 mode-routing work) | 2026-08-08 |
-| #286 | P3 | issue | tests/pr-handoff-stop.test.ts fails on clean main in the web container, reading as a false regression | Measured 2026-08-08. `tests/pr-handoff-stop.test.ts` > 'emits handoff context only when the marker file exists' fails with `expected true to be false` at the `out.markerExists('sess-readonly')` assertion. Verified pre-existing rather than change-induced: it fails identically on a clean checkout of the base commit (confirmed by stashing all work and re-running), and it failed on every full-suite run across the session — the rest of the suite was green at 5660 passed. Likely cause: the 'readonly' scenario the test constructs depends on chmod-based write denial, which does not hold when the process runs as root (the web container's default), so the hook writes its marker where the test expects the write to be refused. Cost: it is the single red line in an otherwise green `npm run test`, so every future session in this environment must re-derive that it is environmental before trusting the suite — this session spent a stash/restore cycle doing exactly that. Next action: make the readonly scenario robust to running as root — assert on an explicit unwritable path (a missing parent directory, or a path under a read-only mount) rather than on chmod semantics — or skip it with a stated reason when `process.getuid?.() === 0`. Stop: do not weaken the assertion to accept a created marker; the behaviour under test (no marker when the session directory is unwritable) is the point. | session 2026-08-08 (PR #1744 mode-routing work) | 2026-08-08 |
+| #285 | P2 | issue | Fresh remote/Cloud containers cannot run npm ci — shipped Node 24.13.0 is below the ^24.15.0 floor that main's jsdom@30.0.1 now requires | Observed 2026-08-08 in a Claude Code web container while syncing PR #1730. npm ci --include=dev aborts with EBADENGINE on jsdom@30.0.1 (needs Node ^22.22.2, ^24.15.0 or >=26); the container ships v24.13.0, so node_modules stays stale and the pre-push static guard then fails typecheck on the missing tailwind-merge added by #1678. Worked around by nvm install 24.19.0 plus a PATH prefix (nvm use alone does not stick — system node shadows it). Next action: raise the engines.node floor in package.json to >=24.15 so the mismatch fails loudly at the declared contract, and provision a compatible Node in the remote/Cloud setup path so a fresh container is not blocked at first install. | session 2026-08-08 (PR #1730) | 2026-08-08 |
+| #286 | P2 | task | PR 2 of the in-page nav series - convert the six pill-rail information pages onto InPageNavHeader | **Outcome:** the six routes still drawing the shell-owned pill rail use the documented default in-page navigation template, and the rail behind them is deleted. **Detail:** PR 1 landed as 2806d5e (#1740), extracting InPageNavHeader plus PageSection/toDocumentSections and usePageSectionWeights into src/components/in-page-nav/, and converting differential-detail-page.tsx as proof. Remaining routes: /services/[slug], /forms/[slug], /specifiers/[slug] (record and reference), /formulation/[slug], /dsm/diagnoses/[slug], /dsm/diagnoses/[slug]/differentials. Settled with the owner: replace the rail at every width, drop the InformationPageBreadcrumbs row but keep the large in-body h1, move each record's actions into the ellipsis sheet. **Next:** FIRST widen InPageNavHeader actions from the render prop (close) => ReactNode to ReactNode or ((close) => ReactNode) and close both sheets on pathname change - four of the seven components in scope are Server Components (specifier-record-page, specifier-reference-page, formulation-mechanism-page, dsm-diagnosis-page carry no use client) and React refuses to pass a function across that boundary, so all four fail to build against the current signature. Then add use-resolved-page-sections and use-in-page-section-nav, generalise useDocumentChromeMetrics for an --inpage-anchor-offset, add scroll-mt to every anchor (information-page sections carry none today), convert each page, then delete informationPageSectionDefinitions and the section kind in secondary-navigation.tsx. Two DSM routes declare anchors nothing renders - see #256. Full brief: artifact 77de9f5b-d195-409d-8156-2e4b41cd2f45. **Stop:** do not convert DocumentViewer in this PR (its chrome-metric property names are contract-pinned by tests/header-scroll-hide-contract.test.ts:110-113), and do not verify anchors by grepping for id= - assert against the rendered DOM per route. | session 2026-08-08; PR #1740 (2806d5e) | 2026-08-08 |
+| #287 | P2 | task | PR 3 of the in-page nav series - the three locally-owned routes each need a decision, not just a conversion | **Outcome:** every information page uses the documented in-page navigation template, or has a recorded reason not to. **Detail:** the last three routes each own a different bespoke pattern, and none is a mechanical port. (1) /medications/[slug] - SectionTabs at medication-record-page.tsx:183 SWAPS CONTENT rather than scrolling: sectionsByTab[activeTab] at :391 filters record.sections by type, so a different set mounts per tab. The InPageNavHeader track is scroll-spy over anchors that all exist at once, so adopting it means either driving tab state from the track (the track stops meaning where am I on the page) or flattening to one scrolling page - a real behaviour change to a clinical record, and a product call. (2) /differentials/presentations/[slug] - MobileTabs at differential-presentation-workflow-page.tsx plus the xl review sidebar; the old `differentialPresentationSections` shell set is gone and the route is locally owned (`page-secondary-navigation.tsx`). Remaining work is the product decision to adopt `InPageNavHeader` (or keep the tab/sidebar model with a recorded reason), not resurrecting deleted section targetIds. (3) /factsheets/[slug] - the On this page list at factsheet-detail-page.tsx:365-371 is li text with no link, button or handler, and the sections themselves carry no ids at all (:214, :267, :313, :447, :453, :471); the tail is data-driven via factsheet.sections.map keyed on section.heading (:538), so anchor ids must be generated deterministically from headings and that generator becomes the contract the section list depends on. Therapy Compass is deliberately excluded from the whole series - ModeNav is a different multi-route pattern. **Next:** decide the medications tab model first (owner decision, blocks planning); decide whether presentations keep MobileTabs/sidebar or adopt InPageNavHeader; choose the factsheets heading-to-id scheme. Then convert. **Stop:** do not port medications mechanically - swapping the tablist for a scroll track silently changes what a clinician sees on a medication record. | session 2026-08-08; follows #286 | 2026-08-08 |
+| #288 | P3 | rec | Decide whether DocumentViewer adopts the template it was extracted from, or the partial adoption is recorded as final | **Outcome:** the in-page navigation template has one deliberate owner story rather than an unexplained gap. **Detail:** PR 1 (2806d5e, #1740) extracted the header from DocumentViewer.tsx and differential-detail-page.tsx, which held it near-verbatim twice, into src/components/in-page-nav/InPageNavHeader. differential-detail-page was converted onto it; DocumentViewer was deliberately NOT, because its own useDocumentSectionSpy and useDocumentChromeMetrics wiring and its CSS custom-property names (--document-anchor-offset, --document-sticky-header-height, [data-document-sticky-header]) are pinned verbatim by tests/header-scroll-hide-contract.test.ts:110-113. Once #286 and #287 land, the template is adopted on every information page EXCEPT DocumentViewer. `docs/search-chrome-behaviour.md` (Default in-page navigation template) already records that DocumentViewer keeps its own header copy because it owns the page h1, uses edge-glass-header, and is pinned by visual baselines — so the gap is documented, not overlooked. #286 generalises chrome metrics for information pages only; it does not close DocumentViewer convergence. **Next:** owner decision only — convert DocumentViewer later (leaving pinned `--document-*` property names untouched per tests/header-scroll-hide-contract.test.ts:110-113), or explicitly mark the documented non-adoption as the final end state in this ledger when the series closes. **Stop:** do not rename or repoint the pinned document CSS custom properties to unify them with the information-page ones - the contract test pins those exact strings and the document route is the highest-traffic surface in the app. | session 2026-08-08; PR #1740 | 2026-08-08 |
 
 ## Resolved / archive