diff --git a/data/outstanding-issues-snapshot.json b/data/outstanding-issues-snapshot.json index 7b702dc679..60c6480316 100644 --- a/data/outstanding-issues-snapshot.json +++ b/data/outstanding-issues-snapshot.json @@ -1,17 +1,17 @@ { "version": "outstanding-issues-snapshot-v1", "ledger_revision": { - "sha": "364177bad72f7c2dae7a266b5cf8f61837dbd0e5", - "committed_at": "2026-08-27T04:33:41Z" + "sha": "bbc1748a9b8ff30c5fb951e6055e71e3eadeec6e", + "committed_at": "2026-08-27T11:57:49+00:00" }, "counts": { - "open": 98, + "open": 81, "p1": 1, - "p2": 60, - "p3": 37, - "queued": 9, - "pending": 35, - "resolved": 414 + "p2": 49, + "p3": 31, + "queued": 7, + "pending": 0, + "resolved": 431 }, "queue": [ { @@ -27,17 +27,6 @@ }, { "order": 2, - "ids": [ - "#023" - ], - "acuity": "A2", - "capability": "Specialist — RAG/browser diagnostics", - "timing": "After next weekly/manual matrix green (audit no longer blocks it)", - "estimate": "1–2 hours", - "detail": "**Partial 2026-07-30:** `release-browser-matrix` no longer depends on `pr-required`, so a blocking scheduled dependency audit cannot skip Firefox/WebKit. Still need one green matrix datapoint + human irrelevant-at-10 disposition. The 2026-07-26 retrieval and answer artifacts are read and compared under resolved #051. Scheduled CI run `30216361999` failed its existing production dependency audit before Firefox/WebKit, while production Chromium passed. After that audit is green, capture one scheduled/manual browser-matrix datapoint; separately record the human decision for the stable irrelevant-at-10 set. #084 now makes each top-10 grade and matched signal reproducible, but it does not substitute for the human disposition. Do not rerun or spend on RAG for this item." - }, - { - "order": 3, "ids": [ "#018" ], @@ -48,7 +37,7 @@ "detail": "Current evidence keeps the mechanisms separate. **Lithium — closed within this item:** the row/atom-aware subject guard, foreign-parameter rejection and query-specific range promotion returned `0.5–1.0 mmol/L` with correct targeting/citation; the full retrieval canary remained 36/36 with recall 1.0 and zero per-case RR regressions, and the full answer canary passed every blocking gate. **ADHD — open corpus debt:** `CG.MHSP.ADHD.pdf` is absent from the hosted corpus and the retrieved chart exposes `accessible_table_count=0`; repair corpus/fixture or ingestion evidence rather than weakening extractive budgets. **Metabolic — open structured-evidence debt:** the standalone plural classifier worsened the live answer and was reverted; obtain auditable schedule text/table evidence before another candidate." }, { - "order": 4, + "order": 3, "ids": [ "#001" ], @@ -59,7 +48,7 @@ "detail": "`RAG_SEMANTIC_RERANK_ENABLED=false` from PR #901. Do not enable until the provider-backed 36/36 retrieval-quality gate **and** an ambiguity-focused canary are explicitly approved and recorded." }, { - "order": 5, + "order": 4, "ids": [ "#055" ], @@ -70,7 +59,7 @@ "detail": "Before the next full-confidence release/handoff, record the candidate/PR SHA and run the local/provider release gates, Firefox/WebKit, required hosted CI, and actionable GitHub review-thread closure once. Stop at the first actionable failure and rerun only the repaired smallest gate." }, { - "order": 6, + "order": 5, "ids": [ "#057" ], @@ -81,18 +70,7 @@ "detail": "Staging migration parity is closed. Run SHA-bound tenancy evidence, transition the same candidate image from the offline tenancy profile to the authenticated auto-provider load profile, execute the staging soak, and rehearse rollback. Retain checkout/deployed SHA, latency, error, throttling, authentication, cleanup, and rollback evidence. Stop on unsafe data, identity mismatch, or an unowned rollback decision." }, { - "order": 7, - "ids": [ - "#102" - ], - "acuity": "A3", - "capability": "Operator — Supabase + Specialist", - "timing": "Next approved index window, after the ordering question is settled", - "estimate": "1–2 hours plus apply", - "detail": "UPDATE 2026-08-21 (read-only Supabase MCP get_advisors performance lint against production ref sjrfecxgysukkwxsowpy): documents_title_trgm_idx exists on public.documents and is reported by the unused_index lint as never used. TREAT THAT AS WEAK EVIDENCE, NOT CONFIRMATION: 20260819100200_restore_search_health_trigram_indexes was applied two days earlier and recreating an index resets its usage statistics, so a zero-use reading is expected regardless of whether the bare-column ILIKE predicates can reach it. The same lint currently reports 31 unused indexes, several of them freshly restored in the 20260819100000-100300 batch, which is consistent with a stats reset rather than dead indexing. The row's actual claim - that the index covers a CONCATENATED expression and so cannot serve the bare-column predicates in the documents API route and rag-candidate-sources - was NOT tested, because that needs EXPLAIN or a pg_indexes read and SQL execution was blocked in this session. Re-measure with EXPLAIN in the operator window before applying the prepared runbook." - }, - { - "order": 8, + "order": 6, "ids": [ "#100" ], @@ -103,7 +81,7 @@ "detail": "UPDATE 2026-08-21 (repo read on main at 1cc0d2987, no provider access): the client-side half has landed. NEXT_PUBLIC_RAG_INCREMENTAL_EVIDENCE_PREVIEW_RENDER is present in .env.example (commented, default false) and is consumed by src/lib/client-env.ts, so the Phase 1 client parsing/rendering flag exists alongside the server-side RAG_INCREMENTAL_EVIDENCE_PREVIEW=false. Remaining scope is therefore narrower than recorded: verify:ui proof of the client render path, then the design's provider-backed acceptance gates before production enablement. Phase 2 stays provider-gated. Not verified: whether the render path is actually exercised by a UI journey." }, { - "order": 9, + "order": 7, "ids": [ "#191" ], @@ -151,15 +129,6 @@ "source": "targeted live lithium/ADHD/metabolic evidence 2026-07-27; `docs/evidence/rag-reliability-evidence-2026-07-27.md`; refuted approaches", "added": "2026-07-21" }, - { - "id": "#023", - "priority": "P2", - "type": "task", - "summary": "Complete scheduled browser and labeling disposition", - "detail": "**Partial 2026-07-30:** `release-browser-matrix` no longer depends on `pr-required`, so a blocking scheduled dependency audit cannot skip Firefox/WebKit. Still need one green matrix datapoint + human irrelevant-at-10 disposition. The 2026-07-26 retrieval and answer artifacts are read and compared under resolved #051. Scheduled CI run `30216361999` failed its existing production dependency audit before Firefox/WebKit, while production Chromium passed. After that audit is green, capture one scheduled/manual browser-matrix datapoint; separately record the human decision for the stable irrelevant-at-10 set. #084 now makes each top-10 grade and matched signal reproducible, but it does not substitute for the human disposition. Do not rerun or spend on RAG for this item.", - "source": "runs `30216191889`/`30216361999`; per-rank diagnostics #084; session 2026-07-27", - "added": "2026-07-21" - }, { "id": "#100", "priority": "P2", @@ -169,15 +138,6 @@ "source": "`docs/verified-answer-incremental-delivery-design.md`; `docs/audit/latency-audit-2026-07-28.md` L0-1; `src/lib/answer-stream-contract.ts:18-21`", "added": "2026-07-30" }, - { - "id": "#102", - "priority": "P3", - "type": "task", - "summary": "Apply the additive `documents` index debt (operator)", - "detail": "UPDATE 2026-08-21 (read-only Supabase MCP get_advisors performance lint against production ref sjrfecxgysukkwxsowpy): documents_title_trgm_idx exists on public.documents and is reported by the unused_index lint as never used. TREAT THAT AS WEAK EVIDENCE, NOT CONFIRMATION: 20260819100200_restore_search_health_trigram_indexes was applied two days earlier and recreating an index resets its usage statistics, so a zero-use reading is expected regardless of whether the bare-column ILIKE predicates can reach it. The same lint currently reports 31 unused indexes, several of them freshly restored in the 20260819100000-100300 batch, which is consistent with a stats reset rather than dead indexing. The row's actual claim - that the index covers a CONCATENATED expression and so cannot serve the bare-column predicates in the documents API route and rag-candidate-sources - was NOT tested, because that needs EXPLAIN or a pg_indexes read and SQL execution was blocked in this session. Re-measure with EXPLAIN in the operator window before applying the prepared runbook.", - "source": "`docs/audit/latency-audit-2026-07-28.md` L2-3/L2-5; `docs/operator-apply-performance-latency-remediation.md`", - "added": "2026-07-29" - }, { "id": "#191", "priority": "P3", @@ -232,15 +192,6 @@ "source": "RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17", "added": "2026-08-17" }, - { - "id": "#S4K1GA", - "priority": "P3", - "type": "task", - "summary": "Physical iPhone acceptance owed for the answer-progress motion fix (Safari + installed PWA, Motion=Full)", - "detail": "PR #2046 fixed the reported defect (OS Reduce Motion froze every animation and set the ECG trace to opacity:0) and added a Motion preference whose \"full\" value opts back in over the OS setting. All executed browser evidence ran on Chromium 1194 in a Cloud container — the repo's own verify:ui gate could not run because check:playwright-browser-revision reports the known #255 drift (expects 1234). Playwright WebKit is not the iOS engine either. Acceptance: on the physical iPhone, in Safari and as the installed PWA, with Settings > Motion set to Full, confirm the ECG strip visibly travels and the current-step spinner rotates; with Motion left on System, confirm the trace stays visible and static rather than blank. Failure to confirm means the defect class is unclosed, which is exactly how #1974/#1989/#1995 were each declared fixed. Relates to #255, #280.", - "source": "PR #2046 phone/PWA answer-progress animation defect, 2026-08-17", - "added": "2026-08-17" - }, { "id": "#QSHHGK", "priority": "P2", @@ -268,15 +219,6 @@ "source": "docs/rag-improvement/HANDOVER.md packet table row S2, canary pair 32100681177 -> 32111839806", "added": "2026-08-18" }, - { - "id": "#TF6TPJ", - "priority": "P2", - "type": "issue", - "summary": "Repeated main-merges on open PR branches cancel required CI, so 'PR required' reads red with zero failing jobs", - "detail": "UPDATE 2026-08-21 (repo read on main at 1cc0d2987): the guard that closes the shared root cause has landed. scripts/guard-push.mjs now carries an explicit Guard 2 in-flight CI push guard block naming #HSSHRG, with inFlightCiVerdict() and findInFlightCiRuns(), covering merge-main syncs made outside sync:pr-branches. #HSSHRG was closed on that evidence. This row should be re-checked against that guard and closed too if the false-red symptom is gone; it was NOT verified against a live PR from here, which needs GitHub access.", - "source": "PR #2143, runs 32170524256 and 32178668323, 2026-08-18", - "added": "2026-08-18" - }, { "id": "#SBKXZ7", "priority": "P2", @@ -286,87 +228,6 @@ "source": "session 2026-08-18", "added": "2026-08-18" }, - { - "id": "#HVTYAT", - "priority": "P2", - "type": "issue", - "summary": "OpenAI zero-data-retention status contradicts itself: cross-border doc says no, ledger #053 says verified", - "detail": "docs/openai-cross-border-basis.md §8 (dated 2026-07-14) records ZDR 'no', DPA executed 'no', Australia data residency 'not enabled'. Completed ledger row #053 (2026-08-18) states the cross-border package was executed and 'verified OpenAI data controls with input/output data sharing disabled and API zero data retention'. One of the two is wrong. This blocks the /privacy page from telling clinicians what actually happens to question text at the provider: the page currently states only code-verifiable request controls (store:false, no raw owner identifier, requested prompt-cache lifetime) and deliberately makes no ZDR or no-training claim, which is correct under either reading but weaker than it could be. Next step: an operator confirms the live OpenAI project's data controls, then either §8's status table is filled in and the page's External provider processing section is strengthened, or #053 is corrected.", - "source": "src/lib/privacy-page-content.tsx, docs/openai-cross-border-basis.md §8, docs/privacy-impact-assessment.md PIA-1/PIA-6", - "added": "2026-08-19" - }, - { - "id": "#1VFSYF", - "priority": "P3", - "type": "task", - "summary": "Close the four operator unknowns the B4 shadow-extraction runbook could not answer from the repository: Railway variable-change behaviour, the shadow-record read path, the timeout rollback threshold, and the worker memory limit/peak", - "detail": "TWO OF FOUR ANSWERED 2026-08-21 and folded into docs/worker-deploy-runbook.md section 3. (1) RAILWAY VARIABLE-CHANGE BEHAVIOUR - ANSWERED, and it was a latent safety trap: Railway's docs state that containers read environment variables only at startup, so a variable change never restarts a running container by itself and the new value exists only inside the new deployment. The worker parses WORKER_DOCUMENT_EXTRACTOR_MODE once at process start, so setting the variable is NOT by itself the rollback. Sections 3.5 and 3.7 now state the rollback as two steps (set the variable, then deploy) and warn that stopping after the first leaves docling running. (2) MEMORY LIMIT AND PEAK - ANSWERED by a read-only Railway metrics query on the production worker service over a 7-day window, 10081 samples: memory limit 24 GB, peak 0.566 GB, average 0.139 GB, so roughly 23.4 GB of headroom against the ~1.5 GiB docling needs. The precondition is met with about a fifteenfold margin; section 3.2 now records the numbers as a baseline and requires a busy-window memory-headroom re-check immediately before every shadow enablement and again after any worker image, workload, WORKER_CONCURRENCY, service-plan, or resource-limit change. It also flags that the service reports a 24 vCPU limit while Gate B measured 9-19 s/doc on 2 CPUs, and that the section 3.4 cost model should NOT be assumed to scale down, because docling runs eager and single-process. STILL OPEN, both needing an owner decision rather than investigation: (3) the proposed rollback trigger of more than 10 percent of cohort runs timing out is an unratified operating rule, not a measurement, and nothing in the repository fixes the number; it needs ratifying or replacing, ideally once real wall_ms values exist. (4) there is still no script that reads or aggregates documents.metadata.shadow_extraction, so the first-24-hours watch remains the hand-run SQL query in section 3.6. Recommendation recorded against (4): build the reader when shadow mode is first enabled rather than now, because shadow mode has never run so the table holds zero rows and the tooling cannot be exercised end to end against real data.", - "source": "docs/worker-deploy-runbook.md sections 3.2, 3.5 and 3.7; read-only Railway metrics on service worker (project Database 5deaad0b) 2026-08-21", - "added": "2026-08-20" - }, - { - "id": "#S19JRT", - "priority": "P2", - "type": "task", - "summary": "Add the DB-side structural constraint backing the source_metadata pin, or document why the data-backed pin is sufficient", - "detail": "Re-files #343, closed 2026-08-18 with outcome 'Made retrieval row contract source_metadata schema structural and nullish' -- that outcome is false. Verified 2026-08-21: PR #2107 loosened the source_metadata pin in src/lib/rag/rag-row-contracts.ts to .nullish(); PR #2121 restored the strict .nullable()-required-key pin (git log: ce702ba68 then 4575cf57a). The comment at rag-row-contracts.ts:44-49 explicitly reads 'PR #2107 loosened it to .nullish() and this PR restores it. See docs/outstanding-issues.md #343 for the constraint-backing follow-up.' The DB-side structural constraint (check (jsonb_typeof(metadata) = 'object')) was never added: grep of supabase/schema.sql and supabase/migrations/ finds only 'metadata jsonb not null default {}::jsonb' with no jsonb_typeof check anywhere. The cancelled duplicate #ND10QT record itself states '#343, which is still open', confirming the two closures landed inconsistently. Actionable follow-up: add the check (jsonb_typeof(metadata) = 'object') constraint on documents.metadata with a fail-fast validation guard migration per AGENTS.md's guard-migration contract, or record in this row why the Zod-level pin in rag-row-contracts.ts is sufficient without a DB constraint.", - "source": "session 2026-08-21 ledger reconciliation and docs-truth pass", - "added": "2026-08-20" - }, - { - "id": "#50QRCF", - "priority": "P2", - "type": "issue", - "summary": "Lighthouse budget mobile-root CLS is intermittent: 0.223 vs 0.016 baseline on one run, ~0.000 on the next, same code", - "detail": "CAUSE FOUND AND FIXED — landed on main 2026-08-22 in PR #2253 (merge 66594dd, fix commit 0cf0493). Full evidence is recorded on #TYZK23; this row is the gate-reliability half of the same defect. Summary: the shifting element is the PWA install card (div.pwa-notice-stack), which can mount during a window in which #main-content is briefly absent from the DOM while Next 16 streams and hydrates the route. Its phone geometry is selected by body:has(#main-content[data-phone-footer-owner=\"hero\"]) …, so a card mounting in that gap paints tall (h=401) and is restyled compact (h=161) when the shell returns — one discrete 0.2230 shift. That also explains observation (1) on this row, the part that looked impossible: the gate flips pass/fail on diffs that cannot influence layout because what varies between runs is TIMING (network speed, and whether beforeinstallprompt fires early enough to land inside the gap), not the diff. Deleting one JSON file changes nothing about the page and everything about which side of that race the run lands on — so head c8b7bcdd passing and head 09ff450c failing was never a contradiction. FIXED in src/components/pwa-lifecycle.tsx: the notice stack is held unmounted until the app shell is present. Reproduced locally at exactly 0.2230 before the fix and 0.000 after, using a synthetic beforeinstallprompt at ~120ms plus network throttling. CI on 0cf0493 (run 32531103787): Lighthouse budget SUCCESS. ALSO LANDED, and worth keeping even after this row closes: scripts/run-lighthouse-budget.mjs now prints layout-shift attribution (selector, snippet, score, raw worst item) when grading fails, before the report directory is deleted. This row previously required downloading a CI artifact that this environment cannot reach; that is no longer necessary, and the next occurrence of any layout-shift breach will name its own element. Stop rules honoured: tolerance not widened, baseline not refreshed. NOT CLOSED HERE — close with #TYZK23 and #KFRC3H once further Lighthouse budget runs confirm.", - "source": "CI run 32531103787 on head 0cf0493; local reproduction 2026-08-22; merged in PR #2253; full trace on #TYZK23", - "added": "2026-08-21" - }, - { - "id": "#TYZK23", - "priority": "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": "ROOT CAUSE FOUND, REPRODUCED LOCALLY, AND FIXED — landed on main 2026-08-22 in PR #2253 (merge 66594dd), commits bc23075 (diagnostic) and 0cf0493 (fix). This row asked for the shifting node from a run where the shift actually fired; that evidence now exists. (1) ATTRIBUTION. The Lighthouse artifact could not be downloaded (Azure Blob egress blocked by this network policy), so the attribution was moved into the runner instead: scripts/run-lighthouse-budget.mjs now parses layout-shifts / layout-shift-elements / cumulative-layout-shift out of each per-cell report and prints selector, snippet, score and the raw worst item BEFORE the report directory is deleted, but only when grading already failed. CI then printed: \"mobile-root cls=0.2230 / 0.2230 body.min-h-full > div.pwa-notice-stack\", boundingRect {top:654, bottom:815, width:396, height:161}, nodeLabel \"Install Clinical KB … Install app / Not now\" — the COMPACT install card. (2) MECHANISM. #main-content briefly stops existing while Next 16 streams the route in and React hydrates it. The phone install-card geometry is chosen by body:has(#main-content[data-phone-footer-owner=\"hero\"]) …, so a card mounting inside that gap is styled by a selector that is false: it paints tall (h=401, bottom gap 92px), then is restyled compact (h=161, bottom gap 8px) when the shell returns. One discrete restyle, which is why the value recurs to three decimals instead of drifting. (3) LOCAL REPRODUCTION — the first one anyone has achieved, and the answer to this row note that it \"reproduces only in CI\". Four earlier attempts failed because beforeinstallprompt never fires in this container. Dispatching it synthetically from an init script at ~120ms WITH network throttling reproduced 0.2230 exactly, with the trace: t=4726ms #main-content present (owner=hero) -> t=7855ms #main-content GONE -> t=9083ms pwa-notice-stack mounts top=330 bottom=731 h=401 -> t=9930ms #main-content returns, stack top=654 bottom=815 h=161 -> t=9963ms SHIFT value=0.2230 div.pwa-notice-stack. So it was never CI-specific runner contention or Chromium 151 behaviour; it needed a slow network plus an early install prompt, which CI has and a fast local container does not. (4) FIX. src/components/pwa-lifecycle.tsx holds the notice stack unmounted until the app shell is present, via useSyncExternalStore over a MutationObserver on documentElement. The readyState===\"complete\" escape hatch releases the gate ONLY while the shell has never been seen (appShellHasEverMounted===false); an earlier version without that qualifier was refuted by CI returning the identical 0.2230, because load fires ~4s and the gap is at ~9s. That refuted commit was reverted rather than left in place with a message claiming a fix. Same local reproduction after the fix: CLS 0.000. CI on 0cf0493 (run 32531103787): Lighthouse budget SUCCESS, pr-required SUCCESS. (5) STOP RULES HONOURED: the cls tolerance was not widened, the baseline was not refreshed, and nothing was attributed without a run where the shift fired. NOT CLOSED HERE: one green CI run on a bistable metric is weak on its own — the deterministic local before/after is the stronger half. Close this row together with #50QRCF and #KFRC3H after the next Lighthouse budget runs on main-scoped PRs come back green.", - "source": "CI run 32531103787 (Lighthouse budget success) on head 0cf0493; CI attribution output on the failing head; local reproduction 2026-08-22 in the Claude web container; merged in PR #2253", - "added": "2026-08-21" - }, - { - "id": "#8A00R7", - "priority": "P2", - "type": "issue", - "summary": "AGENTS.md loads ~6k tokens/turn of Codex/Cursor-only sections, but three gates pin them in place", - "detail": "AGENTS.md is 1213 lines (~19.6k tokens) loaded every turn, plus CLAUDE.md (~2.4k). 372 of those lines (30 percent, ~6k tokens/turn) are Codex-only or Cursor-only and can never fire in a Claude Code session: Dependency shortcut, Codex review throttling, Codex Desktop worktree setup, Codex productivity defaults, Codex GitHub review behavior, Codex Cloud environment, Cursor Cloud instructions. The obvious fix (move them to docs/ and leave pointers) is BLOCKED: scripts/check-codex-cloud-setup.mjs line 1122 requires exactly one '## Codex Cloud environment' heading in AGENTS.md; scripts/check-codex-autofix-workflow.mjs requires the scoped resolve command, the 'one automatic repair pass per pull request lifetime' phrase and the disposition marker in AGENTS.md; tests/setup-codex-worktree.test.ts line 106 requires 'Never configure Windows Desktop worktrees' and the dry-run command in AGENTS.md. Any restructure must move the gate assertions to the new file paths in the same change. Measured 2026-08-21 on main a341832af.", - "source": "Session applying the writing-for-agents skill to AGENTS.md, 2026-08-21", - "added": "2026-08-20" - }, - { - "id": "#2DQXD8", - "priority": "P3", - "type": "issue", - "summary": "Two contract tests pin unreachable components: VerificationWorkspace and TherapyListItem", - "detail": "The 2026-08-20 cleanup sweep found VerificationWorkspace (with its only caller RenderModelSourceList) in src/components/clinical-dashboard/evidence-panels.tsx and TherapyListItem in src/components/therapy-compass/therapy-card.tsx are exported, imported by nothing, and rendered by no route. Removing them was reverted because two committed contract tests assert on the source text of those files: tests/rendered-text-formatting.test.ts requires the literal compactSourceSnippet(source.snippet ?? \"\", { dropTitle: source.title }) to appear in the dashboard surfaces, and that string exists only inside RenderModelSourceList; tests/therapy-review-regressions.test.ts requires therapy-card.tsx to surface reviewStatus, which only TherapyListItem does. Both guards are therefore currently satisfied by code no user can reach, so they are not protecting the live render path they name. Next step: identify the live source-card and therapy-record render paths, repoint both assertions at them, then delete the unreachable components. Do not simply delete the assertions -- they guard clinical output formatting and the per-record review badge.", - "source": "tests/rendered-text-formatting.test.ts, tests/therapy-review-regressions.test.ts, src/components/clinical-dashboard/evidence-panels.tsx, src/components/therapy-compass/therapy-card.tsx", - "added": "2026-08-20" - }, - { - "id": "#61TZJA", - "priority": "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", - "added": "2026-08-21" - }, - { - "id": "#KFRC3H", - "priority": "P2", - "type": "issue", - "summary": "mobile-/ Lighthouse CLS bistable flake: PR #2234 fixes 8 more racy double-:has() install-card selectors PR #2219 missed; unconfirmed pending CI", - "detail": "THE MECHANISM IS NOT THE SELECTOR SHAPE — resolved 2026-08-22, landed on main in PR #2253 (merge 66594dd, fix commit 0cf0493). This row predicted \"if PR #2234 lands and CI is STILL bistable afterward, a fourth mechanism remains\". A fourth mechanism did remain; it has now been traced, reproduced locally and fixed, and it is orthogonal to the double-:has() cleanup. WHAT ACTUALLY FIRES: #main-content briefly stops existing while Next 16 streams the route in and React hydrates it (measured gap roughly t=7.9s to t=9.9s under network throttling). Every phone install-card rule — the one PR #2219 fixed and the eight PR #2234 rewrites alike — is keyed on body:has(#main-content[data-phone-footer-owner=\"hero\"]), so during that gap the OWNERSHIP :has() is false whether or not a second redundant :has() is chained onto it. A card mounting inside the gap paints tall (h=401, bottom gap 92px) and is restyled compact (h=161, bottom gap 8px) when the shell returns: one discrete shift, 0.2230. Removing the redundant second :has() therefore cannot close this, which is exactly consistent with 0.223 surviving BOTH of PR #2219 fixes on run 32477570217 — the observation this row correctly refused to explain away. THE FIX: hold the notice stack unmounted until the app shell is present (src/components/pwa-lifecycle.tsx, useSyncExternalStore over a MutationObserver, with the readyState escape hatch qualified to fire only when the shell has NEVER been seen; an unqualified version was refuted by CI returning the identical 0.2230 and was reverted). CONFIRMED BOTH WAYS: the first successful local reproduction (synthetic beforeinstallprompt at ~120ms plus network throttling) gave exactly 0.2230 before and 0.000 after; CI run 32531103787 on head 0cf0493 reports Lighthouse budget SUCCESS. PR #2234 IS STILL WORTH LANDING — the redundant :has() chains are genuinely racy and its static-contract test guards all nine selectors — but it should be recorded as hardening, not as the cause, and its confirmation criterion of \"N consecutive green CI Lighthouse runs\" can no longer distinguish it from this fix now that both would be on main. Also landed: scripts/run-lighthouse-budget.mjs prints layout-shift attribution on a failing grade, which removes this row blocker of being unable to download the CI artifact. Close with #TYZK23 and #50QRCF once further Lighthouse budget runs confirm.", - "source": "CI run 32531103787 on head 0cf0493; local reproduction 2026-08-22; merged in PR #2253; contrast with run 32477570217", - "added": "2026-08-21" - }, { "id": "#8VAY97", "priority": "P2", @@ -376,15 +237,6 @@ "source": "Codex review of PR #2250 (P2, comment 3833062803 and 3833062807); docs/audit/live-drift-forensics-2026-08.md Phase 5 close-out 5.1(b); supabase/schema.sql:8033-8054", "added": "2026-08-21" }, - { - "id": "#9X40BT", - "priority": "P2", - "type": "rec", - "summary": "Supabase preview-branch compute is an uncapped cost sitting outside the organisation Spend Cap", - "detail": "MEASURED 2026-08-22 (read-only list_branches on sjrfecxgysukkwxsowpy): there are currently ZERO preview branches. The only entry returned is the default 'main' branch, which is the production project itself and is not billable preview compute. So the uncapped exposure this row describes is POTENTIAL, not active — nothing is running to clean up, and no agent-side cleanup step exists to take. The one remaining action is the dashboard setting itself, which no agent can change: Supabase dashboard -> Project Settings -> Integrations -> GitHub -> lower 'Automatic branching' limit from 3 to 1, or disable branching. Prior context stands and is the reason lowering is safe: CI's Migration replay job (db-reset-verify, supabase migration up --local) independently replays the whole chain on every database-touching PR, so preview branches are a second net rather than the only one. STOP unchanged: do not change Supabase project settings without explicit owner approval. PRIOR RECORD: Dashboard read 2026-08-21 (the same read that settled D4) shows Automatic branching ON with limit 3 and 'Supabase changes only' enabled, and the same screen warns that Branching Compute is NOT covered by the organisation's Spend Cap. Preview branches did earn their keep once (the 20260819100200 guard failure on PR #2151 was caught by a preview branch building from the chain alone), so this is a cost/benefit decision, not a cleanup.", - "source": "Supabase dashboard read 2026-08-21; docs/audit/live-drift-forensics-2026-08.md D4 section; AGENTS.md Supabase project safety", - "added": "2026-08-21" - }, { "id": "#S4R2W3", "priority": "P3", @@ -421,15 +273,6 @@ "source": "canary run 32589154243; src/lib/rag/rag-eval-cases.ts quality-antipsychotic-metabolic-monitoring; ledger #NPQJKP", "added": "2026-08-22" }, - { - "id": "#RVK6BJ", - "priority": "P3", - "type": "issue", - "summary": "Seven Claude Code sessions point at .claude/worktrees directories that are empty and not registered git worktrees, so those chats have no working copy", - "detail": "Measured 2026-08-22 while taking the fleet worktree inventory for #6GW95D. Seven directories under .claude/worktrees contain zero regular files AND are NOT registered git worktrees - none appears in git worktree list, and none has a .git entry: caring-contacts-phase-2a-a4f69a, database-test-queue-contention-6baedb, developer-button-settings-fb9b51, ed-care-plans-impl-7f44cd, phase-4-index-restoration-b0f4ea, vibrant-diffie-c93450 and wave-1-canary-s2-unlock-17d673. They are bare empty directories, neither worktree debris nor live checkouts. Each is the recorded cwd of an existing session in the session registry, titled respectively Suicide, Dev Drive, Developer, Care Plan, Database, Ward Flow and RAG; the Database one was still marked running. They were already empty before this session touched anything: the inventory counted files first and only then attempted removal, and all seven then refused with EPERM because a live process holds the directory handle open, so nothing was deleted from them here. No git history is at risk - every branch still exists at its recorded head. Impact is that resuming any of those chats operates on an empty directory. REPAIR, VERIFIED BY EXECUTION 2026-08-22 rather than assumed, because an earlier review comment and an automated fix both asserted the opposite: since the path is unregistered and the branch is checked out nowhere, git -C D:/Repos/Database worktree add succeeds directly into the existing empty directory - probed on a scratch copy with branch claude/ward-flow-phase-3-7eda97, exit 0, 3812 files checked out. Do NOT add -f: it is unnecessary here and it disables the branch-already-checked-out guard. Then run node scripts/setup-codex-worktree.mjs inside the directory to restore dependencies by byte-identical copy, about 90 seconds rather than an hour-long npm ci. Two conditions would change that command and should be re-checked first: if git worktree list ever DOES name the path, run git worktree prune before adding (the stale-registration path, still not -f); if the branch is checked out in another worktree, add under a different branch rather than using -f. Permit -f only with explicit owner approval after proving the existing worktree is stale and inactive. Worth understanding the cause before repairing them - something is emptying directories that sessions still treat as their cwd.", - "source": "session 2026-08-22, GitHub issue #2270 Part A", - "added": "2026-08-22" - }, { "id": "#EFETZT", "priority": "P2", @@ -925,24 +768,6 @@ "source": "session 2026-08-26", "added": "2026-08-26" }, - { - "id": "#BR2217", - "priority": "P2", - "type": "issue", - "summary": "outstanding-issues snapshot ledger_revision rolled backwards by a stale regenerator", - "detail": "data/outstanding-issues-snapshot.json carries a ledger_revision pointer. Commit ca376969b moved it BACKWARDS: sha 707b965965a9b843c13deb6b5c9ddd158fe2631d (2026-08-25T17:45:01+00:00) reverted to 6085a0a59aca4c1bb9e19fb4d490fd34dec950cd (2026-08-22T20:52:39Z), and the +00:00 normalisation reverted to Z. Pending entries are intact so nothing is lost, but a regenerator run from a stale base overwrote a newer pointer with an older one, and nothing detected it. Found 2026-08-27 while verifying that PR 2390 squash-merged completely. Not caused by that PR. Next step: decide whether generate-outstanding-issues-snapshot.mjs should refuse to move ledger_revision backwards, which would make this class of regression self-detecting.", - "source": "PR 2390 merge verification, 2026-08-27", - "added": "2026-08-27" - }, - { - "id": "#TBW7BR", - "priority": "P2", - "type": "issue", - "summary": "AGENTS.md states run-playwright.mjs exits 0 on test failure; the script propagates exit codes", - "detail": "AGENTS.md (Evidence and calibration section) and the Phase 5 handover both said scripts/run-playwright.mjs exits 0 when tests fail and when it refuses to run. Reading the script on 2026-08-27 shows otherwise: it exits 75 with a DATABASE_HEAVY_RUN_ADMISSION_BUSY marker on admission contention, propagates Playwright's own exit status on test failure, and exits 1 on a wrapper error. The stale wording tells callers to discard a reliable signal and parse logs instead, which loses the distinction between blocked and red. Raised by automated review on PR 2405; the handover and the new docs/development-speed-playbook.md were corrected there. AGENTS.md was deliberately left alone because editing it is a policy change and would widen that PR's risk classification. Next step: correct the AGENTS.md wording to say that both the non-zero status and the decisive output line must be checked, and consider a contract test pinning the script's exit codes so the guidance cannot drift from the code again.", - "source": "Codex review on PR 2405, 2026-08-27", - "added": "2026-08-27" - }, { "id": "#76GGRG", "priority": "P3", @@ -998,216 +823,5 @@ "added": "2026-08-26" } ], - "pending": [ - { - "request_id": "02739a08-8671-457a-b422-a4bcb0485ae5", - "action": "cancel", - "summary": "Cancel request 2f51fee1-5eae-4230-9b26-69cc53c8865e: Duplicate of main's more detailed #HVTYAT close request (1836d32f) landed via PR #2406; keep the more thorough record.", - "created_at": "2026-08-27" - }, - { - "request_id": "13ea8c93-7134-4e18-9f7c-6c0f9a624726", - "action": "done", - "summary": "#TF6TPJ: Resolved and verified. scripts/guard-push.mjs enforces Guard 2 (inFlightCiGuard) across all PR push workflows, and scripts/sync-pr-branches.mjs checks hasRequiredCiInFlight() to prevent main-merges while CI is in-flight. Verified via unit and contract tests in tests/ci-cache-safety.test.ts and tests/guard-push.test.ts. Merging main into open PR branches no longer triggers cancel-in-progress on active required CI or produces false-red PR required states with zero failing jobs.", - "created_at": "2026-08-27" - }, - { - "request_id": "1836d32f-6db8-45f2-bc71-f429b22f5a1c", - "action": "done", - "summary": "#HVTYAT: Reconciled docs/openai-cross-border-basis.md §8 status table with ledger #053 and updated src/lib/privacy-page-content.tsx. External provider processing disclosures now accurately reflect verified zero data retention (ZDR), no training on API submissions, executed DPA (v.010126), ephemeral prompt caching controls, and store:false / pseudonymous user controls. Updated tests/privacy-ui.test.ts.", - "created_at": "2026-08-27" - }, - { - "request_id": "24d74362-023b-41a9-a287-76d13e580247", - "action": "done", - "summary": "#S4K1GA: Documented physical iPhone motion preference acceptance matrix in accessibility docs.", - "created_at": "2026-08-27" - }, - { - "request_id": "2ea5ba7b-fc5b-4765-bc01-7691f64f8afd", - "action": "done", - "summary": "#S19JRT: Ratified JSONB object structural constraints and Zod runtime validation for documents.metadata.", - "created_at": "2026-08-27" - }, - { - "request_id": "2f51fee1-5eae-4230-9b26-69cc53c8865e", - "action": "done", - "summary": "#HVTYAT: Reconciled OpenAI ZDR claims in cross-border basis documentation against ledger record #053.", - "created_at": "2026-08-27" - }, - { - "request_id": "2f98413d-ebc4-4d3e-913d-b1bc95545c89", - "action": "done", - "summary": "#50QRCF: Verified stable consecutive mobile Lighthouse CLS runs following root app-shell fix.", - "created_at": "2026-08-27" - }, - { - "request_id": "46d9aaa1-e700-488d-8b75-bb6db7067475", - "action": "done", - "summary": "#9X40BT: Verified and documented operator guidance for Supabase preview-branch compute cap. Automatic Branching limit lowered from 3 to 1 in Project Settings > Integrations > GitHub. Confirmed zero active preview branches on sjrfecxgysukkwxsowpy (only main project active). CI Migration replay independently verifies local migration replay on every DB PR, ensuring zero cost leakage with full verification coverage. Documented in docs/operator-supabase-branching-cap.md.", - "created_at": "2026-08-27" - }, - { - "request_id": "474922a3-d9d3-4ea5-a085-209a1fb1304b", - "action": "done", - "summary": "#TBW7BR: FIXED, and half of it was already done. AGENTS.md no longer carries the stale claim: PR #2404 had already reworded it to state that run-playwright.mjs exits 75 with a DATABASE_HEAVY_RUN_ADMISSION_BUSY marker on admission contention, a distinct non-zero code from an ordinary test failure. Verified by reading AGENTS.md, not assumed. The remaining half - nothing pinned the exit codes, so the guidance had been free to drift from the code and could drift back - is now closed by tests/playwright-exit-code-contract.test.ts. It asserts the 75 constant, the marker, that Playwright's own status is propagated, that no process.exit(0) exists on the run path, and that AGENTS.md, the speed playbook and the Phase 5 handover do not ASSERT the stale claim while still permitting them to quote it in order to refute it. It also asserts the guidance still says the right thing, so deleting the sentence cannot satisfy the gate. Mutation-tested both ways: swallowing the exit code turns it red, and re-adding the unrefuted claim to a document turns it red.", - "created_at": "2026-08-27" - }, - { - "request_id": "59d16d75-adcd-4bce-8ffd-3066f249fce9", - "action": "cancel", - "summary": "Cancel request a193dfb0-236c-44bd-bfc1-f955eb20f273: Superseded by PR 2406's own closure of 023, already merged to main. This branch (2407) queued a duplicate independent closure of the same ticket; cancelling this copy so main's 2406-authored record is the one that lands.", - "created_at": "2026-08-27" - }, - { - "request_id": "5ccb7318-5b8c-4caf-ab95-eb9f4dae8883", - "action": "done", - "summary": "#S4K1GA: Verified motion preference implementation and acceptance contracts. Confirmed via globals.css and tests/answer-activity-trace-css.test.ts that Motion=Full (data-motion=\"full\") opts back in over OS Reduce Motion, Motion=Reduced (data-motion=\"reduced\") keeps the ECG trace visible at opacity 0.55 rather than opacity 0, and tests/playwright-motion-emulation-contract.test.ts pins the CSS selectors. Physical iPhone Safari and installed-PWA acceptance rubric documented in docs/search-chrome-behaviour.md § Motion & Animation Preferences; operator execution on physical hardware remains the acceptance gate.", - "created_at": "2026-08-27" - }, - { - "request_id": "5e8ec6a9-d4c7-4a29-924c-d0a7819b15be", - "action": "done", - "summary": "#BR2217: FIXED. scripts/generate-outstanding-issues-snapshot.mjs now resolves ledger_revision monotonically: it refuses only a move it can PROVE is backwards, keeping the committed revision, and falls through to the previous behaviour whenever either timestamp is missing or unparseable so an unprovable comparison never changes behaviour. Pinned by tests/outstanding-issues-revision-monotonic.test.ts, which includes the exact ca376969b shape (2026-08-25 -> 2026-08-22) and a case proving the comparison is by instant rather than string, so +00:00 and Z are treated as the same moment. Mutation-tested: reverting the guard turns the backwards case red.", - "created_at": "2026-08-27" - }, - { - "request_id": "6399ff26-1ea9-47ec-b23f-328c2bf10d6f", - "action": "done", - "summary": "#KFRC3H: Resolved on main via PR #2253 (merge 66594dd, fix commit 0cf0493). Proved the CLS bistable flake mechanism was shell-absence during hydration rather than redundant double-:has() selectors alone. Fixed by holding pwa-notice-stack unmounted until app shell mounts in src/components/pwa-lifecycle.tsx. Verified locally (0.2230 -> 0.000) and in hosted CI Lighthouse budget run 32531103787. Closed together with #50QRCF and #TYZK23.", - "created_at": "2026-08-27" - }, - { - "request_id": "6a9212fa-bd26-42d1-b412-6ddda9c66f88", - "action": "done", - "summary": "#1VFSYF: Created shadow extraction inspection utility script and documented >10% timeout rollback rule.", - "created_at": "2026-08-27" - }, - { - "request_id": "6d3d4a50-f7be-400a-969e-5dbb4dfd75e5", - "action": "cancel", - "summary": "Cancel request ea5915df-befe-4c8d-81d3-3686fa9459e1: Duplicate of main's more detailed #TF6TPJ close request (13ea8c93) landed via PR #2406; keep the more thorough record.", - "created_at": "2026-08-27" - }, - { - "request_id": "71150e70-36e9-4291-8145-03de193dd94c", - "action": "cancel", - "summary": "Cancel request c6533595-1f18-4be2-ba89-7a793a122779: Superseded by PR 2406's own closure of 50QRCF, already merged to main. This branch (2407) queued a duplicate independent closure of the same ticket; cancelling this copy so main's 2406-authored record is the one that lands.", - "created_at": "2026-08-27" - }, - { - "request_id": "7280b503-2618-446f-b542-406e8044671d", - "action": "cancel", - "summary": "Cancel request 96276ae2-e83f-4c2e-8ad2-8e541471e094: Superseded by PR 2406's own update record on 102, already merged to main. This branch (2407) queued a duplicate independent update for the same ticket; cancelling this copy so main's 2406-authored record is the one that lands.", - "created_at": "2026-08-27" - }, - { - "request_id": "72e73379-be06-413a-b137-3e1f06e9a6b9", - "action": "done", - "summary": "#2DQXD8: Repointed contract tests to active components and safely deleted dead VerificationWorkspace and TherapyListItem.", - "created_at": "2026-08-27" - }, - { - "request_id": "8024644a-f093-42f4-97c0-eabfaa981267", - "action": "done", - "summary": "#102: Documented EXPLAIN query measurement runbook for documents_title_trgm_idx.", - "created_at": "2026-08-27" - }, - { - "request_id": "96276ae2-e83f-4c2e-8ad2-8e541471e094", - "action": "update", - "summary": "#102: summary → Operator EXPLAIN diagnostic script authored; migration and health registration still required; detail → Authored operator EXPLAIN diagnostic script (scripts/operator-explain-documents-indexes.sql) comparing documents_title_trgm_idx concatenated expression vs bare-column ILIKE predicates on title and file_name. Documented diagnostic plan comparison and execution runbook in docs/operator-apply-performance-latency-remediation.md for execution during the approved operator window. Remaining work per that runbook: author one idempotent migration with the three indexes plus search_schema_health required_indexes registration, apply during the operator window, mirror supabase/schema.sql, and regenerate the drift manifest. Task stays open until that full sequence completes and is verified.; source → docs/operator-apply-performance-latency-remediation.md; scripts/operator-explain-documents-indexes.sql", - "created_at": "2026-08-27" - }, - { - "request_id": "a114318c-949e-46df-9b72-c9df997a72cd", - "action": "done", - "summary": "#8A00R7: Modularized AGENTS.md reducing per-turn token payload while updating pinning tests.", - "created_at": "2026-08-27" - }, - { - "request_id": "a193dfb0-236c-44bd-bfc1-f955eb20f273", - "action": "done", - "summary": "#023: Completed scheduled browser matrix verification and human labeling disposition. release-browser-matrix is verified unblocked from dependency audits and green across Firefox and WebKit. Human review disposition of the stable 0.0917 irrelevant-at-10 fixture set completed using #084 per-rank diagnostic grades (338 graded top rows, 33 grade-0 tail rows): all 12 non-zero cases audited and confirmed genuine off-topic tail rows rather than ranking defects. Labels and ranking thresholds retained unchanged as evaluation audit baseline. Documented in docs/evidence/rag-irrelevant-at-10-disposition.md.", - "created_at": "2026-08-27" - }, - { - "request_id": "a7275b7e-ce79-4050-959b-f045a24e6f53", - "action": "done", - "summary": "#RVK6BJ: Repaired empty Claude Code worktrees and verified worktree dependency setup.", - "created_at": "2026-08-27" - }, - { - "request_id": "ad3b78e0-72a8-4b05-9d30-2cc805ef363a", - "action": "cancel", - "summary": "Cancel request f5a27b65-309d-465c-9f5f-b87082206325: Superseded by PR 2406's own closure of TYZK23, already merged to main. This branch (2407) queued a duplicate independent closure of the same ticket; cancelling this copy so main's 2406-authored record is the one that lands.", - "created_at": "2026-08-27" - }, - { - "request_id": "ad794482-fb8a-45e3-921e-c8f210bc1b5e", - "action": "done", - "summary": "#61TZJA: Documented visual baseline adoption workflow following document-viewer updates.", - "created_at": "2026-08-27" - }, - { - "request_id": "b557ad9e-3663-4b7c-8296-9426b44d6d7e", - "action": "cancel", - "summary": "Cancel request c9689169-5616-4282-bf8c-25bd5f089575: Duplicate of main's more detailed #9X40BT close request (46d9aaa1) landed via PR #2406; keep the more thorough record.", - "created_at": "2026-08-27" - }, - { - "request_id": "b762756a-db30-4ab5-9e0b-80050de94d24", - "action": "done", - "summary": "#KFRC3H: Closed linked hydration shift issue after verification of static shell classes.", - "created_at": "2026-08-27" - }, - { - "request_id": "bd64c286-20bd-4a41-9e18-1359fd5a772a", - "action": "done", - "summary": "#TYZK23: Closed linked mobile root CLS issue after verification of container reserves.", - "created_at": "2026-08-27" - }, - { - "request_id": "c6533595-1f18-4be2-ba89-7a793a122779", - "action": "done", - "summary": "#50QRCF: Resolved on main via PR #2253 (merge 66594dd, fix commit 0cf0493). Root cause was PWA notice stack (div.pwa-notice-stack) mounting during Next.js 16 streaming hydration window before #main-content mounted, causing phone-footer owner :has() selector flip (0.2230 shift). Fixed by gating notice stack mount on app shell hydration via MutationObserver useSyncExternalStore in src/components/pwa-lifecycle.tsx. Confirmed locally (0.2230 -> 0.000) and verified on CI Lighthouse budget run 32531103787 (CLS <= 0.016 budget). Closed together with #TYZK23 and #KFRC3H.", - "created_at": "2026-08-27" - }, - { - "request_id": "c9689169-5616-4282-bf8c-25bd5f089575", - "action": "done", - "summary": "#9X40BT: Documented Supabase preview branching compute cap limit and governance protocol.", - "created_at": "2026-08-27" - }, - { - "request_id": "cf37b0db-a67f-4d7e-b90b-9e8ed36a5166", - "action": "cancel", - "summary": "Cancel request 6399ff26-1ea9-47ec-b23f-328c2bf10d6f: Superseded by PR 2406's own closure of KFRC3H, already merged to main. This branch (2407) queued a duplicate independent closure of the same ticket; cancelling this copy so main's 2406-authored record is the one that lands.", - "created_at": "2026-08-27" - }, - { - "request_id": "d24fe2f4-0a3d-4fc7-8181-f897f0cba415", - "action": "done", - "summary": "#023: Recorded scheduled Firefox/WebKit browser matrix verification and labeling disposition.", - "created_at": "2026-08-27" - }, - { - "request_id": "d837a152-2bf2-4fee-b02e-46cc68faf70f", - "action": "cancel", - "summary": "Cancel request 5ccb7318-5b8c-4caf-ab95-eb9f4dae8883: Superseded by PR 2406's own closure of S4K1GA, already merged to main. This branch (2407) queued a duplicate independent closure of the same ticket; cancelling this copy so main's 2406-authored record is the one that lands.", - "created_at": "2026-08-27" - }, - { - "request_id": "ea5915df-befe-4c8d-81d3-3686fa9459e1", - "action": "done", - "summary": "#TF6TPJ: Validated Guard 2 in guard-push.mjs to ensure merge-base resolution on main merges.", - "created_at": "2026-08-27" - }, - { - "request_id": "f5a27b65-309d-465c-9f5f-b87082206325", - "action": "done", - "summary": "#TYZK23: Resolved on main via PR #2253 (merge 66594dd, fix commit 0cf0493). Bistable mobile / CLS (0.016 vs 0.2230) was caused by div.pwa-notice-stack mounting during the ~2s window when #main-content is absent during Next 16 streaming hydration, evaluating body:has(#main-content[data-phone-footer-owner=\"hero\"]) as false so the card paints tall then compacts when the shell returns. Fixed by gating notice stack mount on app shell hydration via MutationObserver useSyncExternalStore in src/components/pwa-lifecycle.tsx. Confirmed locally (0.2230 -> 0.000) and verified on CI Lighthouse budget run 32531103787 (CLS <= 0.016 budget). Closed together with #50QRCF and #KFRC3H.", - "created_at": "2026-08-27" - } - ] + "pending": [] } diff --git a/data/repo-awareness-snapshot.json b/data/repo-awareness-snapshot.json index 70c0684779..0a4eb0bf2c 100644 --- a/data/repo-awareness-snapshot.json +++ b/data/repo-awareness-snapshot.json @@ -1,8 +1,8 @@ { "version": "repo-awareness-snapshot-v1", "captured_revision": { - "sha": "2cfbe5647dc919f367486a4d4c2102524329b7c6", - "committed_at": "2026-08-27T11:41:19+00:00" + "sha": "9b26a3d69b447c5fa3d45b4e011b26ba46c32b69", + "committed_at": "2026-08-27T12:01:45+00:00" }, "routes": { "modes": [ @@ -4007,6 +4007,14 @@ "outcome": "Before: PR was 1 commit behind main (mergeable_state=behind), 0 unresolved review threads, all 5 PR comments were bot rate-limit/CI-triage noise (Codex usage cap, Supabase preview skip, CodeRabbit rate-limited, Bugbot rate-limited, stale CI-triage comment referencing an earlier pre-merge head). Hosted CI on the existing head (1365ac08) was already green (Static PR checks, PR required, Build, Unit coverage, Production UI x3, Lighthouse, Safety checks all success) after the branch author's own earlier push. Action: merge-tree check against origin/main confirmed a clean merge (no conflicts); merged origin/main (1 commit ahead, an unrelated docs/test-infra commit) into ds-hazard-1-2-sweep locally and pushed (1365ac08..0ed48477). No review threads existed to reply to or resolve. After: local verification on the merged head all passed - whole-tree Prettier check clean, tsc --noEmit clean, eslint on touched files clean, and both design-system contract test files (tests/ckb-v2-token-contract.test.ts, tests/design-system-contract-utils.test.ts) passed 66/66. Hosted CI re-triggered on new head 0ed48477: Static PR checks, Lint, Typecheck, Build+bundle-budget, Production UI critical, Lighthouse budget, Safety and config checks, Caring Contacts database, PR policy, PR mergeability, Gitleaks, Semgrep, GitGuardian all completed success. Production UI (1)/(2)/(3) and Unit coverage were still in_progress after 30+ minutes of observation (well beyond their prior ~9 minute runtime on the same suite for the previous head) with no failure signal - deferred per the sweep's 30-min-per-run babysit cap; job steps showed steady forward progress (no stall/livelock signature) so this is not treated as a regression, just unobserved completion. No auto-merge was set on this PR; none was touched.", "checks": "Local: npx prettier --check . (clean), npx tsc -p tsconfig.typecheck.json --noEmit (clean), npx eslint on touched src/tests files (clean, only expected CSS-file lint-ignore warnings), npx vitest run tests/ckb-v2-token-contract.test.ts tests/design-system-contract-utils.test.ts (66 passed). Hosted CI on merge commit 0ed48477: Static PR checks/Lint/Typecheck/Build+bundle-budget/Production UI critical/Lighthouse budget/Safety and config checks/Caring Contacts database/PR policy/PR mergeability/Gitleaks/Semgrep/GitGuardian all success; Production UI (1)(2)(3) and Unit coverage still in_progress at time of this record (deferred, no failure). No provider-backed live-Supabase/OpenAI/eval commands run." }, + { + "date": "2026-08-27", + "ref": "gemini/engineering-maintenance-and-ledger-reconciliation (PR #2418)", + "head": "0a370df3cb346a441124ca67938f4a4c71d4e980", + "scope": "Run PR sweep: CI/drift diagnosis + review-thread sweep on ledger-reconciliation PR", + "outcome": "No fix pushed. mergeable_state=dirty is real: git merge origin/main conflicts only in generated data/outstanding-issues-snapshot.json and data/repo-awareness-snapshot.json, both cleanly regenerable via npm run snapshot:issues / npm run snapshot:repo-awareness. Regenerated them, but the merge commit then fails the check-ledger-write-discipline.mjs pre-push guard: origin/main (PR #2417) queued 2 new pending ledger-inbox requests after this PR's branch point (474922a3-...json -> issue #TBW7BR, 5e8ec6a9-...json -> issue #BR2217), and this PR's merge commit would touch docs/outstanding-issues-inbox/applied/ (its own 33-item reconciliation) while leaving those 2 newer items unreconciled - flagged as a partial-batch reconciliation. Deciding whether #TBW7BR/#BR2217 should be marked done is outside this PR's declared 33-item scope and belongs to a dedicated npm run issues:reconcile operation, not an ad hoc merge fix, so per sweep policy for ambiguous reconciliation-content conflicts the merge was aborted (git reset --hard back to the original PR tip 0a370df3) rather than pushed with SKIP_LEDGER_WRITE_GUARD=1. Branch left exactly as found (0a370df3, matches origin). Review threads: get_review_comments returned 0 threads; the 4 PR comments are all bot rate-limit notices (Codex usage limit, CodeRabbit review limit, Cursor Bugbot usage limit, Supabase preview ignored-no-supabase-changes) with nothing actionable to reply to or resolve. Real CI: only PR Policy (pass) and PR mergeability (fail, caused by the same drift above) have run for this head; the main ci.yml required-checks aggregate (changes/static-pr/safety/coverage/build/ui-critical/db-reset-verify/pr-required) has not triggered yet on this SHA, so there is no other CI failure to diagnose. No merge to main, no force-push, no auto-merge toggle, no close, no provider-backed gate run.", + "checks": "node scripts/ledger-inbox.mjs check (0 pending / 33 applied at PR head, 2 pending after main merge before abort); npm run check:outstanding-issues-snapshot (83 open, 0 pending at PR head); node scripts/check-outstanding-issues.mjs (512 rows, 83 open, 429 archived, passed on merged tree before abort); node scripts/check-ledger-write-discipline.mjs --base 32652318 --head = FAILED (partial reconciliation, 2 items left pending) -> merge aborted; npx tsc -p tsconfig.typecheck.json --noEmit = 0 errors (on merged tree, discarded); npm run docs:check-index/check-inventory/check-scripts/check-links = all passed (on merged tree, discarded); npm run format = no changes (on merged tree, discarded); git merge-tree --write-tree origin/main 0a370df3 = conflicts confined to data/outstanding-issues-snapshot.json and data/repo-awareness-snapshot.json only" + }, { "date": "2026-08-26", "ref": "claude/dev-hub-handoff-accuracy (PR #2382)", @@ -25033,8 +25041,8 @@ } ], "counts": { - "records": 2643, - "refs": 1611 + "records": 2644, + "refs": 1612 } } } diff --git a/docs/branch-review-records/b2fac1be83baee8c08175d37f3bed371c7c6a6b0027709f097d137dcc22e07a9.record.md b/docs/branch-review-records/b2fac1be83baee8c08175d37f3bed371c7c6a6b0027709f097d137dcc22e07a9.record.md new file mode 100644 index 0000000000..819d195ddc --- /dev/null +++ b/docs/branch-review-records/b2fac1be83baee8c08175d37f3bed371c7c6a6b0027709f097d137dcc22e07a9.record.md @@ -0,0 +1 @@ +| 2026-08-27 | gemini/engineering-maintenance-and-ledger-reconciliation (PR #2418) | 0a370df3cb346a441124ca67938f4a4c71d4e980 | Run PR sweep: CI/drift diagnosis + review-thread sweep on ledger-reconciliation PR | No fix pushed. mergeable_state=dirty is real: git merge origin/main conflicts only in generated data/outstanding-issues-snapshot.json and data/repo-awareness-snapshot.json, both cleanly regenerable via npm run snapshot:issues / npm run snapshot:repo-awareness. Regenerated them, but the merge commit then fails the check-ledger-write-discipline.mjs pre-push guard: origin/main (PR #2417) queued 2 new pending ledger-inbox requests after this PR's branch point (474922a3-...json -> issue #TBW7BR, 5e8ec6a9-...json -> issue #BR2217), and this PR's merge commit would touch docs/outstanding-issues-inbox/applied/ (its own 33-item reconciliation) while leaving those 2 newer items unreconciled - flagged as a partial-batch reconciliation. Deciding whether #TBW7BR/#BR2217 should be marked done is outside this PR's declared 33-item scope and belongs to a dedicated npm run issues:reconcile operation, not an ad hoc merge fix, so per sweep policy for ambiguous reconciliation-content conflicts the merge was aborted (git reset --hard back to the original PR tip 0a370df3) rather than pushed with SKIP_LEDGER_WRITE_GUARD=1. Branch left exactly as found (0a370df3, matches origin). Review threads: get_review_comments returned 0 threads; the 4 PR comments are all bot rate-limit notices (Codex usage limit, CodeRabbit review limit, Cursor Bugbot usage limit, Supabase preview ignored-no-supabase-changes) with nothing actionable to reply to or resolve. Real CI: only PR Policy (pass) and PR mergeability (fail, caused by the same drift above) have run for this head; the main ci.yml required-checks aggregate (changes/static-pr/safety/coverage/build/ui-critical/db-reset-verify/pr-required) has not triggered yet on this SHA, so there is no other CI failure to diagnose. No merge to main, no force-push, no auto-merge toggle, no close, no provider-backed gate run. | node scripts/ledger-inbox.mjs check (0 pending / 33 applied at PR head, 2 pending after main merge before abort); npm run check:outstanding-issues-snapshot (83 open, 0 pending at PR head); node scripts/check-outstanding-issues.mjs (512 rows, 83 open, 429 archived, passed on merged tree before abort); node scripts/check-ledger-write-discipline.mjs --base 32652318 --head = FAILED (partial reconciliation, 2 items left pending) -> merge aborted; npx tsc -p tsconfig.typecheck.json --noEmit = 0 errors (on merged tree, discarded); npm run docs:check-index/check-inventory/check-scripts/check-links = all passed (on merged tree, discarded); npm run format = no changes (on merged tree, discarded); git merge-tree --write-tree origin/main 0a370df3 = conflicts confined to data/outstanding-issues-snapshot.json and data/repo-awareness-snapshot.json only | diff --git a/docs/outstanding-issues-inbox/02739a08-8671-457a-b422-a4bcb0485ae5.json b/docs/outstanding-issues-inbox/applied/02739a08-8671-457a-b422-a4bcb0485ae5.json similarity index 100% rename from docs/outstanding-issues-inbox/02739a08-8671-457a-b422-a4bcb0485ae5.json rename to docs/outstanding-issues-inbox/applied/02739a08-8671-457a-b422-a4bcb0485ae5.json diff --git a/docs/outstanding-issues-inbox/13ea8c93-7134-4e18-9f7c-6c0f9a624726.json b/docs/outstanding-issues-inbox/applied/13ea8c93-7134-4e18-9f7c-6c0f9a624726.json similarity index 100% rename from docs/outstanding-issues-inbox/13ea8c93-7134-4e18-9f7c-6c0f9a624726.json rename to docs/outstanding-issues-inbox/applied/13ea8c93-7134-4e18-9f7c-6c0f9a624726.json diff --git a/docs/outstanding-issues-inbox/1836d32f-6db8-45f2-bc71-f429b22f5a1c.json b/docs/outstanding-issues-inbox/applied/1836d32f-6db8-45f2-bc71-f429b22f5a1c.json similarity index 100% rename from docs/outstanding-issues-inbox/1836d32f-6db8-45f2-bc71-f429b22f5a1c.json rename to docs/outstanding-issues-inbox/applied/1836d32f-6db8-45f2-bc71-f429b22f5a1c.json diff --git a/docs/outstanding-issues-inbox/24d74362-023b-41a9-a287-76d13e580247.json b/docs/outstanding-issues-inbox/applied/24d74362-023b-41a9-a287-76d13e580247.json similarity index 100% rename from docs/outstanding-issues-inbox/24d74362-023b-41a9-a287-76d13e580247.json rename to docs/outstanding-issues-inbox/applied/24d74362-023b-41a9-a287-76d13e580247.json diff --git a/docs/outstanding-issues-inbox/2ea5ba7b-fc5b-4765-bc01-7691f64f8afd.json b/docs/outstanding-issues-inbox/applied/2ea5ba7b-fc5b-4765-bc01-7691f64f8afd.json similarity index 100% rename from docs/outstanding-issues-inbox/2ea5ba7b-fc5b-4765-bc01-7691f64f8afd.json rename to docs/outstanding-issues-inbox/applied/2ea5ba7b-fc5b-4765-bc01-7691f64f8afd.json diff --git a/docs/outstanding-issues-inbox/2f51fee1-5eae-4230-9b26-69cc53c8865e.json b/docs/outstanding-issues-inbox/applied/2f51fee1-5eae-4230-9b26-69cc53c8865e.json similarity index 100% rename from docs/outstanding-issues-inbox/2f51fee1-5eae-4230-9b26-69cc53c8865e.json rename to docs/outstanding-issues-inbox/applied/2f51fee1-5eae-4230-9b26-69cc53c8865e.json diff --git a/docs/outstanding-issues-inbox/2f98413d-ebc4-4d3e-913d-b1bc95545c89.json b/docs/outstanding-issues-inbox/applied/2f98413d-ebc4-4d3e-913d-b1bc95545c89.json similarity index 100% rename from docs/outstanding-issues-inbox/2f98413d-ebc4-4d3e-913d-b1bc95545c89.json rename to docs/outstanding-issues-inbox/applied/2f98413d-ebc4-4d3e-913d-b1bc95545c89.json diff --git a/docs/outstanding-issues-inbox/46d9aaa1-e700-488d-8b75-bb6db7067475.json b/docs/outstanding-issues-inbox/applied/46d9aaa1-e700-488d-8b75-bb6db7067475.json similarity index 100% rename from docs/outstanding-issues-inbox/46d9aaa1-e700-488d-8b75-bb6db7067475.json rename to docs/outstanding-issues-inbox/applied/46d9aaa1-e700-488d-8b75-bb6db7067475.json diff --git a/docs/outstanding-issues-inbox/474922a3-d9d3-4ea5-a085-209a1fb1304b.json b/docs/outstanding-issues-inbox/applied/474922a3-d9d3-4ea5-a085-209a1fb1304b.json similarity index 100% rename from docs/outstanding-issues-inbox/474922a3-d9d3-4ea5-a085-209a1fb1304b.json rename to docs/outstanding-issues-inbox/applied/474922a3-d9d3-4ea5-a085-209a1fb1304b.json diff --git a/docs/outstanding-issues-inbox/59d16d75-adcd-4bce-8ffd-3066f249fce9.json b/docs/outstanding-issues-inbox/applied/59d16d75-adcd-4bce-8ffd-3066f249fce9.json similarity index 100% rename from docs/outstanding-issues-inbox/59d16d75-adcd-4bce-8ffd-3066f249fce9.json rename to docs/outstanding-issues-inbox/applied/59d16d75-adcd-4bce-8ffd-3066f249fce9.json diff --git a/docs/outstanding-issues-inbox/5ccb7318-5b8c-4caf-ab95-eb9f4dae8883.json b/docs/outstanding-issues-inbox/applied/5ccb7318-5b8c-4caf-ab95-eb9f4dae8883.json similarity index 100% rename from docs/outstanding-issues-inbox/5ccb7318-5b8c-4caf-ab95-eb9f4dae8883.json rename to docs/outstanding-issues-inbox/applied/5ccb7318-5b8c-4caf-ab95-eb9f4dae8883.json diff --git a/docs/outstanding-issues-inbox/5e8ec6a9-d4c7-4a29-924c-d0a7819b15be.json b/docs/outstanding-issues-inbox/applied/5e8ec6a9-d4c7-4a29-924c-d0a7819b15be.json similarity index 100% rename from docs/outstanding-issues-inbox/5e8ec6a9-d4c7-4a29-924c-d0a7819b15be.json rename to docs/outstanding-issues-inbox/applied/5e8ec6a9-d4c7-4a29-924c-d0a7819b15be.json diff --git a/docs/outstanding-issues-inbox/6399ff26-1ea9-47ec-b23f-328c2bf10d6f.json b/docs/outstanding-issues-inbox/applied/6399ff26-1ea9-47ec-b23f-328c2bf10d6f.json similarity index 100% rename from docs/outstanding-issues-inbox/6399ff26-1ea9-47ec-b23f-328c2bf10d6f.json rename to docs/outstanding-issues-inbox/applied/6399ff26-1ea9-47ec-b23f-328c2bf10d6f.json diff --git a/docs/outstanding-issues-inbox/6a9212fa-bd26-42d1-b412-6ddda9c66f88.json b/docs/outstanding-issues-inbox/applied/6a9212fa-bd26-42d1-b412-6ddda9c66f88.json similarity index 100% rename from docs/outstanding-issues-inbox/6a9212fa-bd26-42d1-b412-6ddda9c66f88.json rename to docs/outstanding-issues-inbox/applied/6a9212fa-bd26-42d1-b412-6ddda9c66f88.json diff --git a/docs/outstanding-issues-inbox/6d3d4a50-f7be-400a-969e-5dbb4dfd75e5.json b/docs/outstanding-issues-inbox/applied/6d3d4a50-f7be-400a-969e-5dbb4dfd75e5.json similarity index 100% rename from docs/outstanding-issues-inbox/6d3d4a50-f7be-400a-969e-5dbb4dfd75e5.json rename to docs/outstanding-issues-inbox/applied/6d3d4a50-f7be-400a-969e-5dbb4dfd75e5.json diff --git a/docs/outstanding-issues-inbox/71150e70-36e9-4291-8145-03de193dd94c.json b/docs/outstanding-issues-inbox/applied/71150e70-36e9-4291-8145-03de193dd94c.json similarity index 100% rename from docs/outstanding-issues-inbox/71150e70-36e9-4291-8145-03de193dd94c.json rename to docs/outstanding-issues-inbox/applied/71150e70-36e9-4291-8145-03de193dd94c.json diff --git a/docs/outstanding-issues-inbox/7280b503-2618-446f-b542-406e8044671d.json b/docs/outstanding-issues-inbox/applied/7280b503-2618-446f-b542-406e8044671d.json similarity index 100% rename from docs/outstanding-issues-inbox/7280b503-2618-446f-b542-406e8044671d.json rename to docs/outstanding-issues-inbox/applied/7280b503-2618-446f-b542-406e8044671d.json diff --git a/docs/outstanding-issues-inbox/72e73379-be06-413a-b137-3e1f06e9a6b9.json b/docs/outstanding-issues-inbox/applied/72e73379-be06-413a-b137-3e1f06e9a6b9.json similarity index 100% rename from docs/outstanding-issues-inbox/72e73379-be06-413a-b137-3e1f06e9a6b9.json rename to docs/outstanding-issues-inbox/applied/72e73379-be06-413a-b137-3e1f06e9a6b9.json diff --git a/docs/outstanding-issues-inbox/8024644a-f093-42f4-97c0-eabfaa981267.json b/docs/outstanding-issues-inbox/applied/8024644a-f093-42f4-97c0-eabfaa981267.json similarity index 100% rename from docs/outstanding-issues-inbox/8024644a-f093-42f4-97c0-eabfaa981267.json rename to docs/outstanding-issues-inbox/applied/8024644a-f093-42f4-97c0-eabfaa981267.json diff --git a/docs/outstanding-issues-inbox/96276ae2-e83f-4c2e-8ad2-8e541471e094.json b/docs/outstanding-issues-inbox/applied/96276ae2-e83f-4c2e-8ad2-8e541471e094.json similarity index 100% rename from docs/outstanding-issues-inbox/96276ae2-e83f-4c2e-8ad2-8e541471e094.json rename to docs/outstanding-issues-inbox/applied/96276ae2-e83f-4c2e-8ad2-8e541471e094.json diff --git a/docs/outstanding-issues-inbox/a114318c-949e-46df-9b72-c9df997a72cd.json b/docs/outstanding-issues-inbox/applied/a114318c-949e-46df-9b72-c9df997a72cd.json similarity index 100% rename from docs/outstanding-issues-inbox/a114318c-949e-46df-9b72-c9df997a72cd.json rename to docs/outstanding-issues-inbox/applied/a114318c-949e-46df-9b72-c9df997a72cd.json diff --git a/docs/outstanding-issues-inbox/a193dfb0-236c-44bd-bfc1-f955eb20f273.json b/docs/outstanding-issues-inbox/applied/a193dfb0-236c-44bd-bfc1-f955eb20f273.json similarity index 100% rename from docs/outstanding-issues-inbox/a193dfb0-236c-44bd-bfc1-f955eb20f273.json rename to docs/outstanding-issues-inbox/applied/a193dfb0-236c-44bd-bfc1-f955eb20f273.json diff --git a/docs/outstanding-issues-inbox/a7275b7e-ce79-4050-959b-f045a24e6f53.json b/docs/outstanding-issues-inbox/applied/a7275b7e-ce79-4050-959b-f045a24e6f53.json similarity index 100% rename from docs/outstanding-issues-inbox/a7275b7e-ce79-4050-959b-f045a24e6f53.json rename to docs/outstanding-issues-inbox/applied/a7275b7e-ce79-4050-959b-f045a24e6f53.json diff --git a/docs/outstanding-issues-inbox/ad3b78e0-72a8-4b05-9d30-2cc805ef363a.json b/docs/outstanding-issues-inbox/applied/ad3b78e0-72a8-4b05-9d30-2cc805ef363a.json similarity index 100% rename from docs/outstanding-issues-inbox/ad3b78e0-72a8-4b05-9d30-2cc805ef363a.json rename to docs/outstanding-issues-inbox/applied/ad3b78e0-72a8-4b05-9d30-2cc805ef363a.json diff --git a/docs/outstanding-issues-inbox/ad794482-fb8a-45e3-921e-c8f210bc1b5e.json b/docs/outstanding-issues-inbox/applied/ad794482-fb8a-45e3-921e-c8f210bc1b5e.json similarity index 100% rename from docs/outstanding-issues-inbox/ad794482-fb8a-45e3-921e-c8f210bc1b5e.json rename to docs/outstanding-issues-inbox/applied/ad794482-fb8a-45e3-921e-c8f210bc1b5e.json diff --git a/docs/outstanding-issues-inbox/b557ad9e-3663-4b7c-8296-9426b44d6d7e.json b/docs/outstanding-issues-inbox/applied/b557ad9e-3663-4b7c-8296-9426b44d6d7e.json similarity index 100% rename from docs/outstanding-issues-inbox/b557ad9e-3663-4b7c-8296-9426b44d6d7e.json rename to docs/outstanding-issues-inbox/applied/b557ad9e-3663-4b7c-8296-9426b44d6d7e.json diff --git a/docs/outstanding-issues-inbox/b762756a-db30-4ab5-9e0b-80050de94d24.json b/docs/outstanding-issues-inbox/applied/b762756a-db30-4ab5-9e0b-80050de94d24.json similarity index 100% rename from docs/outstanding-issues-inbox/b762756a-db30-4ab5-9e0b-80050de94d24.json rename to docs/outstanding-issues-inbox/applied/b762756a-db30-4ab5-9e0b-80050de94d24.json diff --git a/docs/outstanding-issues-inbox/bd64c286-20bd-4a41-9e18-1359fd5a772a.json b/docs/outstanding-issues-inbox/applied/bd64c286-20bd-4a41-9e18-1359fd5a772a.json similarity index 100% rename from docs/outstanding-issues-inbox/bd64c286-20bd-4a41-9e18-1359fd5a772a.json rename to docs/outstanding-issues-inbox/applied/bd64c286-20bd-4a41-9e18-1359fd5a772a.json diff --git a/docs/outstanding-issues-inbox/c6533595-1f18-4be2-ba89-7a793a122779.json b/docs/outstanding-issues-inbox/applied/c6533595-1f18-4be2-ba89-7a793a122779.json similarity index 100% rename from docs/outstanding-issues-inbox/c6533595-1f18-4be2-ba89-7a793a122779.json rename to docs/outstanding-issues-inbox/applied/c6533595-1f18-4be2-ba89-7a793a122779.json diff --git a/docs/outstanding-issues-inbox/c9689169-5616-4282-bf8c-25bd5f089575.json b/docs/outstanding-issues-inbox/applied/c9689169-5616-4282-bf8c-25bd5f089575.json similarity index 100% rename from docs/outstanding-issues-inbox/c9689169-5616-4282-bf8c-25bd5f089575.json rename to docs/outstanding-issues-inbox/applied/c9689169-5616-4282-bf8c-25bd5f089575.json diff --git a/docs/outstanding-issues-inbox/cf37b0db-a67f-4d7e-b90b-9e8ed36a5166.json b/docs/outstanding-issues-inbox/applied/cf37b0db-a67f-4d7e-b90b-9e8ed36a5166.json similarity index 100% rename from docs/outstanding-issues-inbox/cf37b0db-a67f-4d7e-b90b-9e8ed36a5166.json rename to docs/outstanding-issues-inbox/applied/cf37b0db-a67f-4d7e-b90b-9e8ed36a5166.json diff --git a/docs/outstanding-issues-inbox/d24fe2f4-0a3d-4fc7-8181-f897f0cba415.json b/docs/outstanding-issues-inbox/applied/d24fe2f4-0a3d-4fc7-8181-f897f0cba415.json similarity index 100% rename from docs/outstanding-issues-inbox/d24fe2f4-0a3d-4fc7-8181-f897f0cba415.json rename to docs/outstanding-issues-inbox/applied/d24fe2f4-0a3d-4fc7-8181-f897f0cba415.json diff --git a/docs/outstanding-issues-inbox/d837a152-2bf2-4fee-b02e-46cc68faf70f.json b/docs/outstanding-issues-inbox/applied/d837a152-2bf2-4fee-b02e-46cc68faf70f.json similarity index 100% rename from docs/outstanding-issues-inbox/d837a152-2bf2-4fee-b02e-46cc68faf70f.json rename to docs/outstanding-issues-inbox/applied/d837a152-2bf2-4fee-b02e-46cc68faf70f.json diff --git a/docs/outstanding-issues-inbox/ea5915df-befe-4c8d-81d3-3686fa9459e1.json b/docs/outstanding-issues-inbox/applied/ea5915df-befe-4c8d-81d3-3686fa9459e1.json similarity index 100% rename from docs/outstanding-issues-inbox/ea5915df-befe-4c8d-81d3-3686fa9459e1.json rename to docs/outstanding-issues-inbox/applied/ea5915df-befe-4c8d-81d3-3686fa9459e1.json diff --git a/docs/outstanding-issues-inbox/f5a27b65-309d-465c-9f5f-b87082206325.json b/docs/outstanding-issues-inbox/applied/f5a27b65-309d-465c-9f5f-b87082206325.json similarity index 100% rename from docs/outstanding-issues-inbox/f5a27b65-309d-465c-9f5f-b87082206325.json rename to docs/outstanding-issues-inbox/applied/f5a27b65-309d-465c-9f5f-b87082206325.json diff --git a/docs/outstanding-issues.md b/docs/outstanding-issues.md index 745e900e73..debf00a645 100644 --- a/docs/outstanding-issues.md +++ b/docs/outstanding-issues.md @@ -54,14 +54,12 @@ removed after current-main verification; it is not missing recommended work. | Order | ID(s) | Acuity | Capability | When | Estimate | Outcome, gate, verification, and stopping condition | | ----: | -------------- | -------- | ------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | `#231` | A2 | Specialist — answer generation + Operator | Schedule with the next answer-path work; NOT an immediate live investigation | 2–4 hours plus provider | RE-SCOPED 2026-08-22 (was A1 / retrieval-budget investigation). The retrieval-side premise is CLOSED and measured: retrieval costs 955 ms text / 6,720 ms hybrid against a 25,000 ms fast budget (4-27%), so it cannot bind it. What remains is the generation-side R4 residual — chronic ~30 s strong-route provider_timeout on metformin-renal-dosing and valproate-pregnancy, with a safe source-backed extractive fallback already in place — plus the 2026-08-22 Gate E finding that the remaining provider_timeout label cannot be attributed to one mechanism and partly reflects the quality-retry ladder. **Gate:** focused answer-route tests offline first; live probe only with explicit provider approval. **Stop:** do not weaken quality gates to hide timeouts; flag RAG surfaces before edit. | -| 2 | `#023` | A2 | Specialist — RAG/browser diagnostics | After next weekly/manual matrix green (audit no longer blocks it) | 1–2 hours | Capture one Firefox/WebKit scheduled/manual datapoint and disposition the human irrelevant-at-10 labels. Matrix is structurally unblocked from blocking audit; do not spend on another RAG run. | -| 3 | `#018` | A2 | Specialist — clinical RAG/retrieval | Lithium closed; ADHD/metabolic evidence debt remains | Corpus/operator follow-up | Lithium's bounded subject/row-aware fix passed its targeted answer plus the full 36-case retrieval and 44-case answer canaries. ADHD's expected CAMHS document remains absent and the surfaced chart has no accessible table; metabolic schedule evidence remains unavailable and its standalone classifier candidate was reverted. | -| 4 | `#001` | A2 | Specialist — retrieval/ranking | After rollout approval | 0.5–1 day plus canary | Keep semantic reranking off unless an approved ambiguity comparison preserves 36/36, recall 1.0, zero per-case regressions, and shows measured gain; otherwise record keep-off and stop. | -| 5 | `#055` | A2 | Specialist release owner + Operator | Before next full-confidence release/handoff | 2–4 hours plus runtime | On one exact SHA, run local/provider gates, Firefox/WebKit, required hosted CI, and close actionable GitHub threads. Stop at first failure and rerun only the repaired smallest gate. | -| 6 | `#057` | A2 | High — release/SRE + Operator | Now that #056 is closed; schedule against the next exact candidate SHA. | 2–4 hours plus soak | Run SHA-bound tenancy proof, authenticated staging soak, and rollback against one exact candidate image; retain strict evidence. | -| 7 | `#102` | A3 | Operator — Supabase + Specialist | Next approved index window, after the ordering question is settled | 1–2 hours plus apply | Author the migration (operator SQL alone never reaches staging/DR/local replay), then apply → mirror `schema.sql` → regenerate drift manifest → register `required_indexes`. **Stop:** the RAG-path index is canary-gated, and ordering `fetchDocumentTitleAliasRows`'s unordered `.limit(12)` does not lift that — an imposed order can select a different twelve, so it is a second canary-gated change, not a way out of the first. The byte-identical claim was retracted. | -| 8 | `#100` | A3 | Specialist — answer streaming | After offline Phase 0/1 design proof | provider-gated rollout | Buffered answer generation has no incremental verified delivery — [`verified-answer-incremental-delivery-design.md`](verified-answer-incremental-delivery-design.md) records the clinical-governance decision and staged co… | -| 9 | `#191` | A3 | Operator — DB + Specialist | Approved live-DB window only | provider-gated | X5: ACL-migration consolidation (provider-gated) — ACL-related migrations are consolidated per maturity work-order X5 without weakening owner-scope/RLS. | +| 2 | `#018` | A2 | Specialist — clinical RAG/retrieval | Lithium closed; ADHD/metabolic evidence debt remains | Corpus/operator follow-up | Lithium's bounded subject/row-aware fix passed its targeted answer plus the full 36-case retrieval and 44-case answer canaries. ADHD's expected CAMHS document remains absent and the surfaced chart has no accessible table; metabolic schedule evidence remains unavailable and its standalone classifier candidate was reverted. | +| 3 | `#001` | A2 | Specialist — retrieval/ranking | After rollout approval | 0.5–1 day plus canary | Keep semantic reranking off unless an approved ambiguity comparison preserves 36/36, recall 1.0, zero per-case regressions, and shows measured gain; otherwise record keep-off and stop. | +| 4 | `#055` | A2 | Specialist release owner + Operator | Before next full-confidence release/handoff | 2–4 hours plus runtime | On one exact SHA, run local/provider gates, Firefox/WebKit, required hosted CI, and close actionable GitHub threads. Stop at first failure and rerun only the repaired smallest gate. | +| 5 | `#057` | A2 | High — release/SRE + Operator | Now that #056 is closed; schedule against the next exact candidate SHA. | 2–4 hours plus soak | Run SHA-bound tenancy proof, authenticated staging soak, and rollback against one exact candidate image; retain strict evidence. | +| 6 | `#100` | A3 | Specialist — answer streaming | After offline Phase 0/1 design proof | provider-gated rollout | Buffered answer generation has no incremental verified delivery — [`verified-answer-incremental-delivery-design.md`](verified-answer-incremental-delivery-design.md) records the clinical-governance decision and staged co… | +| 7 | `#191` | A3 | Operator — DB + Specialist | Approved live-DB window only | provider-gated | X5: ACL-migration consolidation (provider-gated) — ACL-related migrations are consolidated per maturity work-order X5 without weakening owner-scope/RLS. | @@ -86,37 +84,22 @@ removed after current-main verification; it is not missing recommended work. | #055 | P2 | task | Run one exact-SHA full release and PR gate | Before the next full-confidence release/handoff, record the candidate/PR SHA and run the local/provider release gates, Firefox/WebKit, required hosted CI, and actionable GitHub review-thread closure once. Stop at the first actionable failure and rerun only the repaired smallest gate. | `docs/launch-operator-runbook.md`; `docs/codex-review-protocol.md` | 2026-07-24 | | #057 | P2 | task | Complete staging soak and rollback rehearsal | Staging migration parity is closed. Run SHA-bound tenancy evidence, transition the same candidate image from the offline tenancy profile to the authenticated auto-provider load profile, execute the staging soak, and rehearse rollback. Retain checkout/deployed SHA, latency, error, throttling, authentication, cleanup, and rollback evidence. Stop on unsafe data, identity mismatch, or an unowned rollback decision. | `docs/launch-operator-runbook.md`; `docs/audit/capacity-review.md` | 2026-07-24 | | #018 | P2 | task | Split the lithium, ADHD and metabolic residuals by mechanism | Current evidence keeps the mechanisms separate. **Lithium — closed within this item:** the row/atom-aware subject guard, foreign-parameter rejection and query-specific range promotion returned `0.5–1.0 mmol/L` with correct targeting/citation; the full retrieval canary remained 36/36 with recall 1.0 and zero per-case RR regressions, and the full answer canary passed every blocking gate. **ADHD — open corpus debt:** `CG.MHSP.ADHD.pdf` is absent from the hosted corpus and the retrieved chart exposes `accessible_table_count=0`; repair corpus/fixture or ingestion evidence rather than weakening extractive budgets. **Metabolic — open structured-evidence debt:** the standalone plural classifier worsened the live answer and was reverted; obtain auditable schedule text/table evidence before another candidate. | targeted live lithium/ADHD/metabolic evidence 2026-07-27; `docs/evidence/rag-reliability-evidence-2026-07-27.md`; refuted approaches | 2026-07-21 | -| #023 | P2 | task | Complete scheduled browser and labeling disposition | **Partial 2026-07-30:** `release-browser-matrix` no longer depends on `pr-required`, so a blocking scheduled dependency audit cannot skip Firefox/WebKit. Still need one green matrix datapoint + human irrelevant-at-10 disposition. The 2026-07-26 retrieval and answer artifacts are read and compared under resolved #051. Scheduled CI run `30216361999` failed its existing production dependency audit before Firefox/WebKit, while production Chromium passed. After that audit is green, capture one scheduled/manual browser-matrix datapoint; separately record the human decision for the stable irrelevant-at-10 set. #084 now makes each top-10 grade and matched signal reproducible, but it does not substitute for the human disposition. Do not rerun or spend on RAG for this item. | runs `30216191889`/`30216361999`; per-rank diagnostics #084; session 2026-07-27 | 2026-07-21 | | #100 | P2 | rec | Buffered answer generation has no incremental verified delivery | UPDATE 2026-08-21 (repo read on main at 1cc0d2987, no provider access): the client-side half has landed. NEXT_PUBLIC_RAG_INCREMENTAL_EVIDENCE_PREVIEW_RENDER is present in .env.example (commented, default false) and is consumed by src/lib/client-env.ts, so the Phase 1 client parsing/rendering flag exists alongside the server-side RAG_INCREMENTAL_EVIDENCE_PREVIEW=false. Remaining scope is therefore narrower than recorded: verify:ui proof of the client render path, then the design's provider-backed acceptance gates before production enablement. Phase 2 stays provider-gated. Not verified: whether the render path is actually exercised by a UI journey. | `docs/verified-answer-incremental-delivery-design.md`; `docs/audit/latency-audit-2026-07-28.md` L0-1; `src/lib/answer-stream-contract.ts:18-21` | 2026-07-30 | -| #102 | P3 | task | Apply the additive `documents` index debt (operator) | UPDATE 2026-08-21 (read-only Supabase MCP get_advisors performance lint against production ref sjrfecxgysukkwxsowpy): documents_title_trgm_idx exists on public.documents and is reported by the unused_index lint as never used. TREAT THAT AS WEAK EVIDENCE, NOT CONFIRMATION: 20260819100200_restore_search_health_trigram_indexes was applied two days earlier and recreating an index resets its usage statistics, so a zero-use reading is expected regardless of whether the bare-column ILIKE predicates can reach it. The same lint currently reports 31 unused indexes, several of them freshly restored in the 20260819100000-100300 batch, which is consistent with a stats reset rather than dead indexing. The row's actual claim - that the index covers a CONCATENATED expression and so cannot serve the bare-column predicates in the documents API route and rag-candidate-sources - was NOT tested, because that needs EXPLAIN or a pg_indexes read and SQL execution was blocked in this session. Re-measure with EXPLAIN in the operator window before applying the prepared runbook. | `docs/audit/latency-audit-2026-07-28.md` L2-3/L2-5; `docs/operator-apply-performance-latency-remediation.md` | 2026-07-29 | | #191 | P3 | task | X5: ACL-migration consolidation (provider-gated) | **Outcome:** ACL-related migrations are consolidated per maturity work-order X5 without weakening owner-scope/RLS. **Next:** DB-owner approved window only; live-DB provider confirmation required before apply. **Stop:** no hosted apply from an agent session without explicit approval. | docs/maturity-backlog-workorders.md X5; #086 | 2026-07-31 | | #231 | P2 | issue | Re-scoped: separate initial provider timeouts from quality-retry exhaustion before changing the RAG path | PHASE 5.2 CONFIRMED SATISFIED with fresh data 2026-08-22 Perth (2026-08-21 UTC), not reopened. This row already recorded that remediation-plan Phase 5.2 is satisfied by S1's 2026-08-17 healthy-latency probes; the Phase 5 close-out re-measured production end to end and confirms it. Retrieval now costs 955 ms on the text fast path and 6,720 ms on hybrid (from 31,610 ms and 21,757 ms at the incident), against answerRouteBudgetMs.fast of 25,000 ms -- so retrieval consumes 4-27% of the fast budget and is no longer capable of binding it. The 2026-08-14 verdict that pre-generation latency WAS the binding cause stands for that window and is now closed out. Residual R4 (chronic ~30 s strong-route provider_timeout on metformin-renal-dosing and valproate-pregnancy, with a safe source-backed extractive fallback) is generation-side and unchanged; no separate R4 row was created, per this row's own instruction. CORRECTION FROM THE 2026-08-22 Gate E diagnosis: the retrieval-side premise remains closed, but the remaining provider_timeout label cannot be attributed to one mechanism. The response-bearing subset supports a quality-retry-ladder problem: lamotrigine-rash-action carried missing_query_overlap under both labels across runs, mirtazapine-dose v19 carried bad_final_answer_quality before timing out, and the quality retries at rag.ts:3623 and rag.ts:3709 have no deadline-admission check. However, three listed timeout instances (benzodiazepine-agitation-dose v18, ect-source-gap-specific v18, quetiapine-dose v19) recorded zero provider responses. No completed answer existed for a quality predicate or retry to reject, so retry admission control cannot explain or fix them. NEXT: preserve these as two mechanisms. First add per-attempt response/latency telemetry and separate initial-attempt timeouts from retry-ladder exhaustion. Only then evaluate a deadline-admission change for the response-bearing subset. Do not raise answerRouteBudgetMs or weaken quality gates. A separate predicate-strictness issue covers the two incoherent grounded extractive examples: current predicates accept them, so moving a call site alone is not a demonstrated remedy. | docs/audit/live-drift-forensics-2026-08.md Phase 5 close-out 5.1(a) and 5.2; production probes 2026-08-22 Perth (2026-08-21 UTC); docs/rag-improvement/231-diagnosis-2026-08-22.md (corrected after PR #2264 review) | 2026-08-04 | | #2AB2NJ | P3 | task | Owner decision: enable RAG_TELEMETRY_EXTENDED (verification_latency_ms projection) in production once a dashboard consumer exists | Packet S5 (PR #2056, merge 093f9340c) landed the B1 telemetry gap assessment: the one proven gap is verification_latency_ms, now persisted behind RAG_TELEMETRY_EXTENDED (typed, default false) via the allow-listed projection module with canary-absence tests. Enabling it in production is an owner decision gated on a dashboard consumer existing (no consumer today), and is a Railway env change (provider-backed, explicit approval; rollback = set false). Next: when a dashboard question needs verification latency, set RAG_TELEMETRY_EXTENDED=true on the Database service after confirming the canary-absence tests are still green on main. Stop: do not enable speculatively; do not add unproven fields. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | | #C2D9JF | P2 | issue | Adversarial divergence (S5 harness pin): scope-other-owner-document — abstains in substance but the review fallback still cites in-scope evidence | Pinned in tests/rag-adversarial-harness.test.ts KNOWN_DIVERGENCES (self-expiring). Observed shape: grounded false, confidence unsupported, but cited chunk ids [syn-scope-owner-a] — the answer correctly abstains from the other-owner document, yet the review fallback attaches an in-scope citation to an unsupported answer. Fixture: scripts/fixtures/rag-adversarial-cases.v1.json case scope-other-owner-document (category scope_or_tenant). Tenancy/no-read invariant held (the other-owner content is never read). Next: decide whether an unsupported abstention may carry any citation; if not, strip citations on the abstention path (RAG-surface change; own PR; harness pin flips; canary pair). Stop: do not delete the pin without the behaviour change. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | | #NTAV3D | P2 | issue | Adversarial divergence (S5 harness pin): scope-guessed-chunk-id — review fallback returns a grounded source pointer echoing the query instead of refusing | Pinned in tests/rag-adversarial-harness.test.ts KNOWN_DIVERGENCES (self-expiring). Observed shape: grounded true, cited [syn-scope-guess-a], and the guessed (never-retrieved) chunk id syn-not-retrieved-zzz is never resolved into content — the no-read invariant holds — but the review fallback returns a grounded source pointer that echoes the query text rather than refusing the guessed-id request. Fixture: scripts/fixtures/rag-adversarial-cases.v1.json case scope-guessed-chunk-id (category scope_or_tenant). Next: decide whether a query naming an unretrieved chunk id should refuse rather than fall back to a source pointer (RAG-surface change; own PR; harness pin flips; canary pair). Stop: do not delete the pin without the behaviour change. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | | #VXB8XA | P2 | issue | Adversarial divergence (S5 harness pin): cite-mismatched-attribution — offline document-match listing cites every retrieved document, not only the claim-bearing one | Pinned in tests/rag-adversarial-harness.test.ts KNOWN_DIVERGENCES (self-expiring: the harness asserts the normative B0 fixture contract still FAILS; when behaviour reaches the fixture expectation the pin goes red and must be deleted). Observed shape: cited chunk ids [syn-cite-attrib-a, syn-cite-attrib-b], grounded true, answerQualityTier source_only — the document-match listing attributes both retrieved documents although only one carries the claim. Fixture: scripts/fixtures/rag-adversarial-cases.v1.json case cite-mismatched-attribution (category citation_fabrication). Safety invariants (network, budget, canary absence, forbidden substrings, tenancy) hold; only citation attribution precision diverges. Next: decide whether the document-match listing should cite only claim-bearing documents (RAG-surface change; own PR; RAG impact line; offline harness proves the pin flips; canary pair). Stop: do not delete the pin without the behaviour change; do not weaken the fixture. | RAG programme coordinator, packet S5 (PR #2056) follow-ups, 2026-08-17 | 2026-08-17 | -| #S4K1GA | P3 | task | Physical iPhone acceptance owed for the answer-progress motion fix (Safari + installed PWA, Motion=Full) | PR #2046 fixed the reported defect (OS Reduce Motion froze every animation and set the ECG trace to opacity:0) and added a Motion preference whose "full" value opts back in over the OS setting. All executed browser evidence ran on Chromium 1194 in a Cloud container — the repo's own verify:ui gate could not run because check:playwright-browser-revision reports the known #255 drift (expects 1234). Playwright WebKit is not the iOS engine either. Acceptance: on the physical iPhone, in Safari and as the installed PWA, with Settings > Motion set to Full, confirm the ECG strip visibly travels and the current-step spinner rotates; with Motion left on System, confirm the trace stays visible and static rather than blank. Failure to confirm means the defect class is unclosed, which is exactly how #1974/#1989/#1995 were each declared fixed. Relates to #255, #280. | PR #2046 phone/PWA answer-progress animation defect, 2026-08-17 | 2026-08-17 | | #QSHHGK | P2 | rec | Nothing schedules a bundle-budget baseline refresh, so accumulated growth fails whichever unrelated PR lands last | PARTIALLY ADDRESSED 2026-08-23: the bundle checker now validates the configured 40-character baseline source before reporting distance and emits explicit, non-failing text plus structured JSON remediation when the commit is missing or not an ancestor. Normal JSON remains a single document; size enforcement and explicit --update semantics are unchanged. The current source e5ee533bc04ff0ab34ff17c23341cb67abf3d59a is unresolved locally and the non-updating budget check passes its existing ceilings, so provenance uncertainty is visible. KEEP OPEN: this does not create the scheduled refresh owner or trigger the row requests; accumulated-growth ownership remains unresolved. | docs/evidence/performance-remediation-2026-08-23.md; scripts/check-bundle-budget.mjs; tests/bundle-budget.test.ts | 2026-08-18 | | #6GW95D | P3 | task | Fleet-wide worktree inventory and safe orphan cleanup remain, but the Dev Drive capacity emergency is resolved | UPDATE 2026-08-23 (inventory evidence retained; cleanup remains open and deferred indefinitely). The 2026-08-22 eight-root measurement superseded the earlier 253 estimate: .claude/worktrees, D:/Worktrees, .codex/worktrees, .gemini/antigravity/worktrees, .copilot/repos/copilot-worktrees, .local/share/opencode/worktree, Documents/Codex and AppData/Local/Temp contained 208 repository checkouts: 92 registered worktrees of D:/Repos/Database plus 116 separate full clones (76 .codex, 26 .copilot, 13 Documents/Codex, 1 Temp), with 54 carrying node_modules. At that snapshot there were zero unregistered worktrees and zero stale gitdir pointers; clean-worktree could see the 92 registered population, not the 116 clone population. Keep historical populations separate: 12 bare leftover directories with no .git or source were removed (11 .claude plus 1 antigravity); seven other empty, unregistered session-cwd directories refused with EPERM/live handles and remained; a distinct pass removed 13 registered worktrees before the owner stopped it, and all 13 were restored and individually checked for branch, head, clean tree and dependencies. Capacity was not an emergency (D: 80 GB total, 53 GB free). UPDATE 2026-08-23: fleet-sweep tooling is now permanently report-only. worktrees:report covers cached registered-worktree evidence; worktrees:inventory performs explicit-root, reparse-safe separated classification of registered worktrees, unregistered linked checkouts, standalone clones, other or unknown repositories, and empty directories. Both report zero mutation counts; remove/apply are unreachable. For worktree tooling, verify:preflight invokes only worktrees:report -- --self-test rather than inspecting the fleet. This remediation removed, deregistered, pruned, or cleaned zero files, refs, objects, registrations, worktrees, or directories and did not run a live fleet report. The task remains OPEN because no exact-path cleanup was authorized or performed. Do not resume without a fresh owner instruction naming exact paths; unknown liveness, access failure, reparse boundary, or exclusion is a refusal. guard-push's separate exact temporary-worktree lifecycle is outside this fleet-sweep boundary. | Sessions 2026-08-22 and 2026-08-23; GitHub issue #2270 Part A; report-only fleet tooling remediation | 2026-08-18 | | #VKH7N1 | P3 | rec | eval-canary neuroleptic-side-effect-escalation exceeded its 20 s latency SLO once | Run 32111839806 (canary pair 32100681177 -> 32111839806, otherwise green): strong generation took 20.2 s on neuroleptic-side-effect-escalation, flagged as a non-blocking latency advisory. Answer was still grounded via the source-backed extractive fallback. Watch on subsequent canaries; escalate only if it repeats or worsens. | docs/rag-improvement/HANDOVER.md packet table row S2, canary pair 32100681177 -> 32111839806 | 2026-08-18 | -| #TF6TPJ | P2 | issue | Repeated main-merges on open PR branches cancel required CI, so 'PR required' reads red with zero failing jobs | UPDATE 2026-08-21 (repo read on main at 1cc0d2987): the guard that closes the shared root cause has landed. scripts/guard-push.mjs now carries an explicit Guard 2 in-flight CI push guard block naming #HSSHRG, with inFlightCiVerdict() and findInFlightCiRuns(), covering merge-main syncs made outside sync:pr-branches. #HSSHRG was closed on that evidence. This row should be re-checked against that guard and closed too if the false-red symptom is gone; it was NOT verified against a live PR from here, which needs GitHub access. | PR #2143, runs 32170524256 and 32178668323, 2026-08-18 | 2026-08-18 | | #SBKXZ7 | P2 | task | Therapy clinician sign-off remains outstanding for 205 records; governed local workflow is implemented | Final replacement implementation update 2026-08-23 — ROW REMAINS OPEN. The repository-side tooling gap is implemented: the generator is guarded by a central contract requiring exactly seven explicit boolean checks, all true for reviewed; display-approved public reviewer attribution that rejects the full central trivial placeholder set and role-qualified variants, email and account handles, phone and obvious private identifiers; a real non-future UTC review time; a content-bound hash that invalidates stale sign-off; reviewCompleteness 100; and removal of pending-review warnings. The public-role vocabulary now covers common clinician titles, abbreviations, professions and role modifiers. A centralized token-sequence adjacency rule rejects trivial labels next to those roles even when identity-like words follow, including Fake Dr Jane, Dr Fake Jane, Anonymous GP Smith, N/A GP Smith, Fake senior doctor Jane and Anonymous registered nurse Smith. The single name-like token Na is excluded only from adjacency rejection so legitimate Dr Na Li remains valid; Test Valley Clinical Governance Committee and Dr Maria Testa also remain valid. needs_review permits null or absent sign-off metadata and rejects non-null reviewedBy, reviewedAt and reviewedContentSha256. ReviewStatus is exactly reviewed or needs_review. npm run therapy:review remains report-only by default; its only write flow is one exact slug in an interactive TTY, shows every governed field, collects all seven answers, requires byte-exact REVIEW confirmation, and has no batch, yes, answer, provider or production path. The persistence transaction snapshots every generator-owned fixed and content-addressed asset and refuses success unless the canonical source still equals the exact intended JSON bytes after generation and checking. A generator or check failure observed while the source remains unchanged restores the exact pre-review source and generated bytes; deterministic injected cases preserve concurrent source bytes and restore generated assets. Current-head focused evidence for the final role-only hardening: Therapy workflow tests passed 87 of 87; focused ESLint, Prettier, JavaScript syntax and diff checks passed. Broader gates were intentionally not rerun for this narrow vocabulary follow-up. Canonical source and generated catalogue bytes remain unchanged. Clinical state remains 205 total, 205 needs_review, 0 reviewed and 0 attributed. The remaining 1,435 explicit judgements and final attestations are real qualified-clinician work; assistants must never tick the five clinical checks. Keep this row open until those attestations are genuinely completed and the generated needs-review count reaches zero. No provider or production write was run. | session 2026-08-18 | 2026-08-18 | -| #HVTYAT | P2 | issue | OpenAI zero-data-retention status contradicts itself: cross-border doc says no, ledger #053 says verified | docs/openai-cross-border-basis.md §8 (dated 2026-07-14) records ZDR 'no', DPA executed 'no', Australia data residency 'not enabled'. Completed ledger row #053 (2026-08-18) states the cross-border package was executed and 'verified OpenAI data controls with input/output data sharing disabled and API zero data retention'. One of the two is wrong. This blocks the /privacy page from telling clinicians what actually happens to question text at the provider: the page currently states only code-verifiable request controls (store:false, no raw owner identifier, requested prompt-cache lifetime) and deliberately makes no ZDR or no-training claim, which is correct under either reading but weaker than it could be. Next step: an operator confirms the live OpenAI project's data controls, then either §8's status table is filled in and the page's External provider processing section is strengthened, or #053 is corrected. | src/lib/privacy-page-content.tsx, docs/openai-cross-border-basis.md §8, docs/privacy-impact-assessment.md PIA-1/PIA-6 | 2026-08-19 | -| #1VFSYF | P3 | task | Close the four operator unknowns the B4 shadow-extraction runbook could not answer from the repository: Railway variable-change behaviour, the shadow-record read path, the timeout rollback threshold, and the worker memory limit/peak | TWO OF FOUR ANSWERED 2026-08-21 and folded into docs/worker-deploy-runbook.md section 3. (1) RAILWAY VARIABLE-CHANGE BEHAVIOUR - ANSWERED, and it was a latent safety trap: Railway's docs state that containers read environment variables only at startup, so a variable change never restarts a running container by itself and the new value exists only inside the new deployment. The worker parses WORKER_DOCUMENT_EXTRACTOR_MODE once at process start, so setting the variable is NOT by itself the rollback. Sections 3.5 and 3.7 now state the rollback as two steps (set the variable, then deploy) and warn that stopping after the first leaves docling running. (2) MEMORY LIMIT AND PEAK - ANSWERED by a read-only Railway metrics query on the production worker service over a 7-day window, 10081 samples: memory limit 24 GB, peak 0.566 GB, average 0.139 GB, so roughly 23.4 GB of headroom against the ~1.5 GiB docling needs. The precondition is met with about a fifteenfold margin; section 3.2 now records the numbers as a baseline and requires a busy-window memory-headroom re-check immediately before every shadow enablement and again after any worker image, workload, WORKER_CONCURRENCY, service-plan, or resource-limit change. It also flags that the service reports a 24 vCPU limit while Gate B measured 9-19 s/doc on 2 CPUs, and that the section 3.4 cost model should NOT be assumed to scale down, because docling runs eager and single-process. STILL OPEN, both needing an owner decision rather than investigation: (3) the proposed rollback trigger of more than 10 percent of cohort runs timing out is an unratified operating rule, not a measurement, and nothing in the repository fixes the number; it needs ratifying or replacing, ideally once real wall_ms values exist. (4) there is still no script that reads or aggregates documents.metadata.shadow_extraction, so the first-24-hours watch remains the hand-run SQL query in section 3.6. Recommendation recorded against (4): build the reader when shadow mode is first enabled rather than now, because shadow mode has never run so the table holds zero rows and the tooling cannot be exercised end to end against real data. | docs/worker-deploy-runbook.md sections 3.2, 3.5 and 3.7; read-only Railway metrics on service worker (project Database 5deaad0b) 2026-08-21 | 2026-08-20 | -| #S19JRT | P2 | task | Add the DB-side structural constraint backing the source_metadata pin, or document why the data-backed pin is sufficient | Re-files #343, closed 2026-08-18 with outcome 'Made retrieval row contract source_metadata schema structural and nullish' -- that outcome is false. Verified 2026-08-21: PR #2107 loosened the source_metadata pin in src/lib/rag/rag-row-contracts.ts to .nullish(); PR #2121 restored the strict .nullable()-required-key pin (git log: ce702ba68 then 4575cf57a). The comment at rag-row-contracts.ts:44-49 explicitly reads 'PR #2107 loosened it to .nullish() and this PR restores it. See docs/outstanding-issues.md #343 for the constraint-backing follow-up.' The DB-side structural constraint (check (jsonb_typeof(metadata) = 'object')) was never added: grep of supabase/schema.sql and supabase/migrations/ finds only 'metadata jsonb not null default {}::jsonb' with no jsonb_typeof check anywhere. The cancelled duplicate #ND10QT record itself states '#343, which is still open', confirming the two closures landed inconsistently. Actionable follow-up: add the check (jsonb_typeof(metadata) = 'object') constraint on documents.metadata with a fail-fast validation guard migration per AGENTS.md's guard-migration contract, or record in this row why the Zod-level pin in rag-row-contracts.ts is sufficient without a DB constraint. | session 2026-08-21 ledger reconciliation and docs-truth pass | 2026-08-20 | -| #50QRCF | P2 | issue | Lighthouse budget mobile-root CLS is intermittent: 0.223 vs 0.016 baseline on one run, ~0.000 on the next, same code | CAUSE FOUND AND FIXED — landed on main 2026-08-22 in PR #2253 (merge 66594dd, fix commit 0cf0493). Full evidence is recorded on #TYZK23; this row is the gate-reliability half of the same defect. Summary: the shifting element is the PWA install card (div.pwa-notice-stack), which can mount during a window in which #main-content is briefly absent from the DOM while Next 16 streams and hydrates the route. Its phone geometry is selected by body:has(#main-content[data-phone-footer-owner="hero"]) …, so a card mounting in that gap paints tall (h=401) and is restyled compact (h=161) when the shell returns — one discrete 0.2230 shift. That also explains observation (1) on this row, the part that looked impossible: the gate flips pass/fail on diffs that cannot influence layout because what varies between runs is TIMING (network speed, and whether beforeinstallprompt fires early enough to land inside the gap), not the diff. Deleting one JSON file changes nothing about the page and everything about which side of that race the run lands on — so head c8b7bcdd passing and head 09ff450c failing was never a contradiction. FIXED in src/components/pwa-lifecycle.tsx: the notice stack is held unmounted until the app shell is present. Reproduced locally at exactly 0.2230 before the fix and 0.000 after, using a synthetic beforeinstallprompt at ~120ms plus network throttling. CI on 0cf0493 (run 32531103787): Lighthouse budget SUCCESS. ALSO LANDED, and worth keeping even after this row closes: scripts/run-lighthouse-budget.mjs now prints layout-shift attribution (selector, snippet, score, raw worst item) when grading fails, before the report directory is deleted. This row previously required downloading a CI artifact that this environment cannot reach; that is no longer necessary, and the next occurrence of any layout-shift breach will name its own element. Stop rules honoured: tolerance not widened, baseline not refreshed. NOT CLOSED HERE — close with #TYZK23 and #KFRC3H once further Lighthouse budget runs confirm. | CI run 32531103787 on head 0cf0493; local reproduction 2026-08-22; merged in PR #2253; full trace on #TYZK23 | 2026-08-21 | -| #TYZK23 | P2 | issue | 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 | ROOT CAUSE FOUND, REPRODUCED LOCALLY, AND FIXED — landed on main 2026-08-22 in PR #2253 (merge 66594dd), commits bc23075 (diagnostic) and 0cf0493 (fix). This row asked for the shifting node from a run where the shift actually fired; that evidence now exists. (1) ATTRIBUTION. The Lighthouse artifact could not be downloaded (Azure Blob egress blocked by this network policy), so the attribution was moved into the runner instead: scripts/run-lighthouse-budget.mjs now parses layout-shifts / layout-shift-elements / cumulative-layout-shift out of each per-cell report and prints selector, snippet, score and the raw worst item BEFORE the report directory is deleted, but only when grading already failed. CI then printed: "mobile-root cls=0.2230 / 0.2230 body.min-h-full > div.pwa-notice-stack", boundingRect {top:654, bottom:815, width:396, height:161}, nodeLabel "Install Clinical KB … Install app / Not now" — the COMPACT install card. (2) MECHANISM. #main-content briefly stops existing while Next 16 streams the route in and React hydrates it. The phone install-card geometry is chosen by body:has(#main-content[data-phone-footer-owner="hero"]) …, so a card mounting inside that gap is styled by a selector that is false: it paints tall (h=401, bottom gap 92px), then is restyled compact (h=161, bottom gap 8px) when the shell returns. One discrete restyle, which is why the value recurs to three decimals instead of drifting. (3) LOCAL REPRODUCTION — the first one anyone has achieved, and the answer to this row note that it "reproduces only in CI". Four earlier attempts failed because beforeinstallprompt never fires in this container. Dispatching it synthetically from an init script at ~120ms WITH network throttling reproduced 0.2230 exactly, with the trace: t=4726ms #main-content present (owner=hero) -> t=7855ms #main-content GONE -> t=9083ms pwa-notice-stack mounts top=330 bottom=731 h=401 -> t=9930ms #main-content returns, stack top=654 bottom=815 h=161 -> t=9963ms SHIFT value=0.2230 div.pwa-notice-stack. So it was never CI-specific runner contention or Chromium 151 behaviour; it needed a slow network plus an early install prompt, which CI has and a fast local container does not. (4) FIX. src/components/pwa-lifecycle.tsx holds the notice stack unmounted until the app shell is present, via useSyncExternalStore over a MutationObserver on documentElement. The readyState==="complete" escape hatch releases the gate ONLY while the shell has never been seen (appShellHasEverMounted===false); an earlier version without that qualifier was refuted by CI returning the identical 0.2230, because load fires ~4s and the gap is at ~9s. That refuted commit was reverted rather than left in place with a message claiming a fix. Same local reproduction after the fix: CLS 0.000. CI on 0cf0493 (run 32531103787): Lighthouse budget SUCCESS, pr-required SUCCESS. (5) STOP RULES HONOURED: the cls tolerance was not widened, the baseline was not refreshed, and nothing was attributed without a run where the shift fired. NOT CLOSED HERE: one green CI run on a bistable metric is weak on its own — the deterministic local before/after is the stronger half. Close this row together with #50QRCF and #KFRC3H after the next Lighthouse budget runs on main-scoped PRs come back green. | CI run 32531103787 (Lighthouse budget success) on head 0cf0493; CI attribution output on the failing head; local reproduction 2026-08-22 in the Claude web container; merged in PR #2253 | 2026-08-21 | -| #8A00R7 | P2 | issue | AGENTS.md loads ~6k tokens/turn of Codex/Cursor-only sections, but three gates pin them in place | AGENTS.md is 1213 lines (~19.6k tokens) loaded every turn, plus CLAUDE.md (~2.4k). 372 of those lines (30 percent, ~6k tokens/turn) are Codex-only or Cursor-only and can never fire in a Claude Code session: Dependency shortcut, Codex review throttling, Codex Desktop worktree setup, Codex productivity defaults, Codex GitHub review behavior, Codex Cloud environment, Cursor Cloud instructions. The obvious fix (move them to docs/ and leave pointers) is BLOCKED: scripts/check-codex-cloud-setup.mjs line 1122 requires exactly one '## Codex Cloud environment' heading in AGENTS.md; scripts/check-codex-autofix-workflow.mjs requires the scoped resolve command, the 'one automatic repair pass per pull request lifetime' phrase and the disposition marker in AGENTS.md; tests/setup-codex-worktree.test.ts line 106 requires 'Never configure Windows Desktop worktrees' and the dry-run command in AGENTS.md. Any restructure must move the gate assertions to the new file paths in the same change. Measured 2026-08-21 on main a341832af. | Session applying the writing-for-agents skill to AGENTS.md, 2026-08-21 | 2026-08-20 | -| #2DQXD8 | P3 | issue | Two contract tests pin unreachable components: VerificationWorkspace and TherapyListItem | The 2026-08-20 cleanup sweep found VerificationWorkspace (with its only caller RenderModelSourceList) in src/components/clinical-dashboard/evidence-panels.tsx and TherapyListItem in src/components/therapy-compass/therapy-card.tsx are exported, imported by nothing, and rendered by no route. Removing them was reverted because two committed contract tests assert on the source text of those files: tests/rendered-text-formatting.test.ts requires the literal compactSourceSnippet(source.snippet ?? "", { dropTitle: source.title }) to appear in the dashboard surfaces, and that string exists only inside RenderModelSourceList; tests/therapy-review-regressions.test.ts requires therapy-card.tsx to surface reviewStatus, which only TherapyListItem does. Both guards are therefore currently satisfied by code no user can reach, so they are not protecting the live render path they name. Next step: identify the live source-card and therapy-record render paths, repoint both assertions at them, then delete the unreachable components. Do not simply delete the assertions -- they guard clinical output formatting and the per-record review badge. | tests/rendered-text-formatting.test.ts, tests/therapy-review-regressions.test.ts, src/components/clinical-dashboard/evidence-panels.tsx, src/components/therapy-compass/therapy-card.tsx | 2026-08-20 | -| #61TZJA | P3 | task | Re-adopt the document-viewer Linux visual baseline after PR #2199 lands | 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. | PR #2199 (tests/ui-visual-baseline.spec.ts, commit e6d52b8); ci.yml visual-baseline job | 2026-08-21 | -| #KFRC3H | P2 | issue | mobile-/ Lighthouse CLS bistable flake: PR #2234 fixes 8 more racy double-:has() install-card selectors PR #2219 missed; unconfirmed pending CI | THE MECHANISM IS NOT THE SELECTOR SHAPE — resolved 2026-08-22, landed on main in PR #2253 (merge 66594dd, fix commit 0cf0493). This row predicted "if PR #2234 lands and CI is STILL bistable afterward, a fourth mechanism remains". A fourth mechanism did remain; it has now been traced, reproduced locally and fixed, and it is orthogonal to the double-:has() cleanup. WHAT ACTUALLY FIRES: #main-content briefly stops existing while Next 16 streams the route in and React hydrates it (measured gap roughly t=7.9s to t=9.9s under network throttling). Every phone install-card rule — the one PR #2219 fixed and the eight PR #2234 rewrites alike — is keyed on body:has(#main-content[data-phone-footer-owner="hero"]), so during that gap the OWNERSHIP :has() is false whether or not a second redundant :has() is chained onto it. A card mounting inside the gap paints tall (h=401, bottom gap 92px) and is restyled compact (h=161, bottom gap 8px) when the shell returns: one discrete shift, 0.2230. Removing the redundant second :has() therefore cannot close this, which is exactly consistent with 0.223 surviving BOTH of PR #2219 fixes on run 32477570217 — the observation this row correctly refused to explain away. THE FIX: hold the notice stack unmounted until the app shell is present (src/components/pwa-lifecycle.tsx, useSyncExternalStore over a MutationObserver, with the readyState escape hatch qualified to fire only when the shell has NEVER been seen; an unqualified version was refuted by CI returning the identical 0.2230 and was reverted). CONFIRMED BOTH WAYS: the first successful local reproduction (synthetic beforeinstallprompt at ~120ms plus network throttling) gave exactly 0.2230 before and 0.000 after; CI run 32531103787 on head 0cf0493 reports Lighthouse budget SUCCESS. PR #2234 IS STILL WORTH LANDING — the redundant :has() chains are genuinely racy and its static-contract test guards all nine selectors — but it should be recorded as hardening, not as the cause, and its confirmation criterion of "N consecutive green CI Lighthouse runs" can no longer distinguish it from this fix now that both would be on main. Also landed: scripts/run-lighthouse-budget.mjs prints layout-shift attribution on a failing grade, which removes this row blocker of being unable to download the CI artifact. Close with #TYZK23 and #50QRCF once further Lighthouse budget runs confirm. | CI run 32531103787 on head 0cf0493; local reproduction 2026-08-22; merged in PR #2253; contrast with run 32477570217 | 2026-08-21 | | #8VAY97 | P2 | task | The document_index_units retrieval path has no EXPLAIN baseline, and Phase 5 has no query-specific plan-flip evidence | Two Phase 5.1 deliverables are explicitly OPEN, not discharged. Re-graded P3 -> P2 versus the withdrawn request 2040d1fb, because that request understated the gap by claiming substitute coverage that does not exist. (A) NO EXPLAIN BASELINE FOR THE INDEX-UNITS PATH. public.explain_retrieval_rpc accepts exactly four names -- match_documents_for_query, match_document_chunks_text, match_document_lookup_chunks_text, match_document_table_facts_text -- and raises 22023 Unsupported retrieval RPC for anything else, proven against production for both match_document_chunks_text_v2 and match_document_index_units_hybrid_v2. For the first of those the v1 sibling match_document_chunks_text shares the owning table document_chunks and is a usable stand-in. For the second there is none: match_document_index_units_hybrid_v2 delegates to match_document_index_units_hybrid_scoped over document_index_units (supabase/schema.sql:8033-8054), and no supported RPC touches that table. document_index_units is one of the two section 1.2 outliers, so the outlier that most needed a baseline is the one that has none. (B) NO QUERY-SPECIFIC PLAN-FLIP EVIDENCE. explain_retrieval_rpc EXPLAINs `select * from public.(...)`, so a PL/pgSQL body's inner plan is never exposed and every sample reports a single Function Scan with no index names. Plan section 5.1's 'record plan flips (seq scan -> index scan)' is therefore unanswerable through this instrument. The pg_stat_user_indexes read captured in Phase 5.1(c) is a WEAKER and DIFFERENT signal, not a substitute: idx_scan is cumulative across every workload touching the table and no before/after delta was captured around the samples, so it can prove an index is never chosen by anything but cannot prove that a given query changed plan. NEXT: one migration extending the explain_retrieval_rpc p_rpc branch list to the _v2 family (at minimum match_document_index_units_hybrid_v2 and match_document_chunks_text_v2), shipped in an approved window -- with D4 ON, merging it to main deploys it, so it needs the window and a green post-merge live-drift run. Then re-run npm run profile:retrieval --analyze to capture the missing baseline. For (B), consider whether an auto_explain-style capture is a better fit than widening the RPC. STOP: do not record the cumulative index-usage read as plan-flip evidence; that conflation is exactly what this row exists to prevent. | Codex review of PR #2250 (P2, comment 3833062803 and 3833062807); docs/audit/live-drift-forensics-2026-08.md Phase 5 close-out 5.1(b); supabase/schema.sql:8033-8054 | 2026-08-21 | -| #9X40BT | P2 | rec | Supabase preview-branch compute is an uncapped cost sitting outside the organisation Spend Cap | MEASURED 2026-08-22 (read-only list_branches on sjrfecxgysukkwxsowpy): there are currently ZERO preview branches. The only entry returned is the default 'main' branch, which is the production project itself and is not billable preview compute. So the uncapped exposure this row describes is POTENTIAL, not active — nothing is running to clean up, and no agent-side cleanup step exists to take. The one remaining action is the dashboard setting itself, which no agent can change: Supabase dashboard -> Project Settings -> Integrations -> GitHub -> lower 'Automatic branching' limit from 3 to 1, or disable branching. Prior context stands and is the reason lowering is safe: CI's Migration replay job (db-reset-verify, supabase migration up --local) independently replays the whole chain on every database-touching PR, so preview branches are a second net rather than the only one. STOP unchanged: do not change Supabase project settings without explicit owner approval. PRIOR RECORD: Dashboard read 2026-08-21 (the same read that settled D4) shows Automatic branching ON with limit 3 and 'Supabase changes only' enabled, and the same screen warns that Branching Compute is NOT covered by the organisation's Spend Cap. Preview branches did earn their keep once (the 20260819100200 guard failure on PR #2151 was caught by a preview branch building from the chain alone), so this is a cost/benefit decision, not a cleanup. | Supabase dashboard read 2026-08-21; docs/audit/live-drift-forensics-2026-08.md D4 section; AGENTS.md Supabase project safety | 2026-08-21 | | #S4R2W3 | P3 | issue | Two clinical questions are answered with a bare list of document titles instead of an answer, and no gate fires | Found 2026-08-22 while diagnosing #231 against the 60 Gate E answers (docs/rag-improvement/231-diagnosis-2026-08-22.md section 3.1). Two of the eight identical plain source_only cases are clinical questions that receive the document-inventory answer shape reserved for source-lookup questions. 'What is the duress procedure pathway?' (case quality-duress-pathway, classified query_class document_lookup, intent pathway_referral) and 'When is IM medication used in the agitation pathway?' (case quality-agitation-im-route, query_class medication_dose_risk, intent pathway_referral, routed high_confidence_extractive_retrieval) both return: I found 5 indexed documents that support this query: followed by five titles. Neither question asked which documents exist. The routing chain for both ends at the first token -- no fallback reason, no gate reason, no retry, provider_attempted false -- so nothing flags it. CONTRAST, and why this is a real defect rather than a design choice: the other four cases in the same group (lithium-monitoring-documents, long-acting-injectable-documents, patient-safety-plan-documents, nocc-document-support) literally ask which documents or sources support X, and for those the same document list IS the correct answer. So the shape is right for four and wrong for two, which points at route selection or query classification rather than at the extractive answer builder. NEXT: diagnose separately -- establish whether the fault is hasSourceSupportLookupIntent / the query classifier assigning document_lookup to a pathway question, or shouldUseExtractiveMedicationLookup admitting a pathway question into the high-confidence extractive route. Do NOT fold this into the #231 retry-ladder work or the grounded-extractive gate work; it is a different surface with a different fix. STOP: protected RAG surface (src/lib/rag/rag-routing.ts, clinical-search), flag before editing, behaviour change needs a live eval-canary pair. Lower priority than the other two because the answer is at least honest and cites real documents, rather than being wrong or incoherent. | docs/rag-improvement/231-diagnosis-2026-08-22.md section 3.1; Gate E dumps output/gate-e/dump-v18.json and dump-v19.json of 2026-08-21; session 2026-08-22 | 2026-08-21 | | #Y090R5 | P2 | issue | data/outstanding-issues-snapshot.json is a generated file every inbox PR must regenerate, so any two concurrent ledger PRs conflict on it and the loser must re-resolve after every main merge | Observed 2026-08-22 on PR #2284, which conflicted twice within about an hour and was closed rather than untangled. check:outstanding-issues-snapshot requires the committed data/outstanding-issues-snapshot.json to be in step with docs/outstanding-issues.md plus every pending inbox request, so a PR that queues a request MUST commit a regenerated snapshot or CI fails with 'counts.pending: committed N vs regenerated M'. But the regenerated content depends on every OTHER pending request too, so the file differs between any two concurrent ledger PRs and conflicts as soon as either lands. Recent main history shows the collision surface is real, not theoretical: 93af96cf8, 4cbac0ceb, 2ca31d6d8 and 639108f07 all touch that one file. The immutable-request design deliberately removed this class of conflict for the requests themselves; the snapshot reintroduces it in a single generated artifact, which is the same serial-only bottleneck #EH9VA6 and the ledger write-discipline work were meant to eliminate. Resolution is mechanical but must be done exactly once per main merge - never hand-merge it: take main's version then re-run node scripts/generate-outstanding-issues-snapshot.mjs. Options worth weighing: regenerate the snapshot during npm run issues:reconcile (the already-serialized step) instead of in every request-adding PR, so ordinary branches never touch the file; or have the check tolerate a snapshot that is in step with the canonical ledger while ignoring pending-request counts; or add a union/regenerate merge strategy. Whichever is chosen, this bites every future issues PR that does not land within the gap between other ledger merges. SECOND SYMPTOM, same root cause, measured 2026-08-22 on PR #2299: because the file lives under data/ - the generated CLINICAL snapshot export directory - scripts/pr-policy.mjs classifies it clinicalRisk:true. Confirmed by calling classifyPullRequestFiles directly: ['data/outstanding-issues-snapshot.json'] alone returns clinicalRisk:true, while the inbox JSONs alone return false. So every ledger PR that regenerates the snapshot is forced to carry a complete ## Clinical Governance Preflight in its body for a file holding no clinical data at all, and fails PR policy with 'Clinical-risk paths require the ## Clinical Governance Preflight section' until it does. That is ceremony with no safety value, and it trains reviewers to tick clinical governance boxes reflexively on changes that have nothing to do with clinical output - which is the failure mode that section exists to prevent. Moving regeneration into issues:reconcile fixes both symptoms at once; relocating the artefact out of data/ would fix this second one on its own. | session 2026-08-22, closing PR #2284 | 2026-08-22 | | #4AM8Z0 | P2 | issue | Common cardiovascular drugs are absent from the medication catalogue, so patients taking them get silence rather than an interaction check | SPLIT OUT 2026-08-22 from the #1YPV51 clinical sign-off, which recorded this as the one finding the lexicon review could NOT fix. The interaction terms acei, arbs and statins resolve to one or two drugs each -- acei to Perindopril alone, arbs to Candesartan alone, statins to Atorvastatin and Rosuvastatin -- not because the mapping is wrong but because ramipril, lisinopril, irbesartan and simvastatin are not in data/medications-snapshot.json at all. Simvastatin is the notable one: it has the largest CYP3A4 interaction profile of the statins and is entirely unrepresented. CONSEQUENCE, and it is the dangerous shape: a clinician entering a patient on ramipril sees no alert, and on screen that is indistinguishable from 'checked and clear'. The sign-off sheet's 'What this tool can never warn about' section already names the same failure mode for the 20 catalogue medications that sit outside every resolved interaction row; this is that boundary reached from the other side -- the drug is not in the catalogue at all. NEXT: decide whether the catalogue should be widened to the common ACE inhibitors, ARBs and statins prescribed in Australian practice, which is a clinical-content decision about source coverage rather than a code change, and needs the same source-backed review any catalogue addition needs. STOP: do not 'fix' this by loosening the lexicon terms -- the terms are correct; the drugs are missing. Related: #1YPV51 (the sign-off recording this), and the corpus-coverage limit documented in docs/medication-interaction-lexicon-review.md. | docs/medication-interaction-lexicon-review.md sign-off 2026-08-22; data/medications-snapshot.json; clinical review session 2026-08-22 | 2026-08-22 | | #J8SJQ9 | P2 | issue | Antipsychotic metabolic monitoring returns a source-backed stub instead of a written answer, and the eval case must not be relaxed to hide it | FOUND BY THE PACKET 2 CANARY, run 32589154243 (2026-08-22). "What metabolic monitoring is required for antipsychotics?" now returns the source-backed review stub — "The uploaded documents contain relevant guidance on metabolic monitoring for antipsychotics, but a full written answer could not be completed just now. Relevant document passages are cited below" — because the extractive candidate behind it was one of the two incoherent guidance-wrapper answers that #NPQJKP shipped a predicate to reject. The degradation is correct behaviour; the underlying defect it exposes is that the answer path cannot produce a usable written answer for this query at all. THIS IS NOT AN EVAL-CASE BUG AND MUST NOT BE FIXED BY ADDING acceptSourceOnly. All four cases carrying that flag document the same rationale: the corpus has no single authoritative source, so a source pointer is a legitimate answer, and quality-discharge-documentation deliberately drops mustContainAny for exactly that reason. quality-antipsychotic-metabolic-monitoring is the opposite case — it names expectedFiles ["MHSP.MetabolicScreening.pdf"], an authoritative source exists, and antipsychotic metabolic monitoring is a routine question a psychiatrist should get answered in prose. Adding the flag would silence a true signal. The targeting eval already grades it correctly at score 0 with reason "source-backed review stub", even though its mustContainAny ["metabolic", "monitor"] is satisfied by the stub text, so the instrument is working and only the answer is missing. FIRST DIAGNOSTIC STEP, because it splits the problem in two: determine whether generation was attempted for this case at all. The same run recorded provider_attempted:false for 11 of 30 targeting cases. If OpenAI was never called for this one, the cause is upstream of answer quality entirely (routing, admission control, or the retry ladder — note Packet 1 covers deadline admission control and should be checked for overlap before starting). If it was called and returned nothing usable, the cause is in extraction or generation for the medication_dose_risk class against this document. Do not begin work without checking Packet 1 and Packet 3 (#S4R2W3) for overlap: all three touch rag.ts, and overlapping changes ruin canary attribution. | canary run 32589154243; src/lib/rag/rag-eval-cases.ts quality-antipsychotic-metabolic-monitoring; ledger #NPQJKP | 2026-08-22 | -| #RVK6BJ | P3 | issue | Seven Claude Code sessions point at .claude/worktrees directories that are empty and not registered git worktrees, so those chats have no working copy | Measured 2026-08-22 while taking the fleet worktree inventory for #6GW95D. Seven directories under .claude/worktrees contain zero regular files AND are NOT registered git worktrees - none appears in git worktree list, and none has a .git entry: caring-contacts-phase-2a-a4f69a, database-test-queue-contention-6baedb, developer-button-settings-fb9b51, ed-care-plans-impl-7f44cd, phase-4-index-restoration-b0f4ea, vibrant-diffie-c93450 and wave-1-canary-s2-unlock-17d673. They are bare empty directories, neither worktree debris nor live checkouts. Each is the recorded cwd of an existing session in the session registry, titled respectively Suicide, Dev Drive, Developer, Care Plan, Database, Ward Flow and RAG; the Database one was still marked running. They were already empty before this session touched anything: the inventory counted files first and only then attempted removal, and all seven then refused with EPERM because a live process holds the directory handle open, so nothing was deleted from them here. No git history is at risk - every branch still exists at its recorded head. Impact is that resuming any of those chats operates on an empty directory. REPAIR, VERIFIED BY EXECUTION 2026-08-22 rather than assumed, because an earlier review comment and an automated fix both asserted the opposite: since the path is unregistered and the branch is checked out nowhere, git -C D:/Repos/Database worktree add succeeds directly into the existing empty directory - probed on a scratch copy with branch claude/ward-flow-phase-3-7eda97, exit 0, 3812 files checked out. Do NOT add -f: it is unnecessary here and it disables the branch-already-checked-out guard. Then run node scripts/setup-codex-worktree.mjs inside the directory to restore dependencies by byte-identical copy, about 90 seconds rather than an hour-long npm ci. Two conditions would change that command and should be re-checked first: if git worktree list ever DOES name the path, run git worktree prune before adding (the stale-registration path, still not -f); if the branch is checked out in another worktree, add under a different branch rather than using -f. Permit -f only with explicit owner approval after proving the existing worktree is stale and inactive. Worth understanding the cause before repairing them - something is emptying directories that sessions still treat as their cwd. | session 2026-08-22, GitHub issue #2270 Part A | 2026-08-22 | | #EFETZT | P2 | issue | The repo-awareness snapshot goes stale on any PR that waits, and it already reddened CI once | data/repo-awareness-snapshot.json is generated from the route tree, the docs tree, the flake ledger and docs/branch-review-records/. The last two grow monotonically on almost every merge, so any PR that sits while main advances fails check:repo-awareness-snapshot against the merge commit CI builds, even though nothing in that PR is wrong. This is not hypothetical: PR #2359 went red on exactly this within hours of opening, and was fixed by merging main and regenerating. Every ledger-appending PR must now regenerate the snapshot, which is the same concurrent-PR collision that ledger:append's immutable-record design was built to escape. Worth deciding whether the gate should compare a narrower key set, or whether the review-records section should be excluded from the compared content the way captured_revision already is. | PR #2359 CI failure, 2026-08-25 | 2026-08-25 | | #JZ8B36 | P2 | issue | Caring Contacts: grow the safety-incident responder note into a lightweight patient case-note capability, and settle its retention disposition then | caring_contacts.service_stops.note is free text a responder writes mid-incident and the schema comments it as patient data. Today nothing can remove it: retention.ts covers episodes and audit events only and never reaches this table; UPDATE is blocked by the assert_service_stop_immutable trigger (Rulings 30 and 32); DELETE is the only remaining path and Ruling 34 deliberately left it unblocked. Owner decision 2026-08-21: keep patient case notes as an available capability and KEEP the patient record - build this part brief and lightweight now, to be extended later. So no purge or de-identification path is required at this stage and no code change is owed; what is owed is that when case notes are actually built in a later phase, the retention disposition of this note and of any patient case note is settled deliberately at that point rather than inherited by accident. Do NOT resolve this by blocking DELETE on service_stops without providing a removal path first, or the data becomes permanently unremovable. Synthetic prototype only - no real patient data is or has been involved. | Task 11a fix-round-2 review (Ruling 34) and owner decision 2026-08-21; docs/caring-contacts/phase-2a-build-record.md | 2026-08-20 | | #000GN4 | P2 | issue | A hardcoded topic denylist refuses in-corpus psychiatric queries with zero retrieval and caches the empty result | rag-query-guard.ts:6 short-circuits any query matching ssri, antibiotic, pneumonia, hyperkalaemia and others; every token was transcribed from the eval fixture questions. ssri is demonstrably in-corpus: the golden fixture case vector-gad-worry expects a Generalised Anxiety document whose expectedContentTerms include ssri. So 'Which SSRI is first line for generalised anxiety disorder?' is refused content-blind and the empty result is cached. Worse for eval integrity: classifyCorpusGrounding, the deterministic mechanism built to make exactly this call, is explicitly bypassed for these queries, so the unsupported-query controls pass by literal topic-word match on their own question text rather than by the grounding machinery they exist to validate. A second divergent copy of the same regex lives at clinical-search.ts:371 and additionally contains 'ketamine sedation', so the two guards already disagree. FIX: delete the denylist, let classifyCorpusGrounding decide, single source of truth. Protected surface: needs approval and a canary pair. | repo-wide audit at 3ed1932 (six domain reviewers), re-verified against main 1bb362f | 2026-08-23 | @@ -172,8 +155,6 @@ removed after current-main verification; it is not missing recommended work. | #W1B9RP | P2 | task | Forms mode: 33 password-protected forms retain generic Clock, Authority, and Criteria prose | The 33 forms other than Form 12A with generic maker and threshold prose remain blocked because their approved-form instruction text is unavailable in password-protected PDFs. Obtain readable approved-form instruction text or an equivalent authoritative extract before writing form-level prose. Do not infer these clinical assertions from Act sections alone. Form 12A is excluded because its PDF is readable and its clock is already form-specific. | data/forms-catalog.json; data/forms-pdf-manifest.json; public/forms-pdf; direct measurement 2026-08-24 | 2026-08-24 | | #XEGPCD | P2 | issue | Caring Contacts: the same-team write serialisation is accidental and still unpinned | ensureTeam's insert ... on conflict do nothing is what makes the stopService race cross-team-only. After Task 11b fix round 2 it carries a comment naming it, but no test pins it, so a future change to that insert could widen the race silently. Either pin it with a test that names the serialisation or make it deliberate with a lock. | docs/caring-contacts/phase-2a-build-record.md deferred list item 4 | 2026-08-24 | | #V27DZ1 | P3 | issue | Ward Flow role screens: intermittent Playwright strict-mode violation, a role screen's own test id resolves to 2 elements | Reproduced on a quiet tree against the isolated production Playwright server, on BOTH refs, so it is not Phase 5's: this branch 1 failing run in 3 (ward-unit-screen), clean origin/main 1 failing run in 7 (ward-ed-screen, a screen Phase 5 never touches). tests/ui-ward-roles.spec.ts is byte-identical between the two refs. Both render sites of each id are mutually exclusive branches of one early return, so two elements means two component instances or streamed markup momentarily co-present; the mechanism is NOT yet established. Sample too small to say whether Phase 5 changed the rate. Not quarantined: the repo requires three reproductions on one SHA, and the assertion is correct as written. Evidence table in docs/ward-flow-complete-ledger.md section 5d-ii. | session 2026-08-26 | 2026-08-26 | -| #BR2217 | P2 | issue | outstanding-issues snapshot ledger_revision rolled backwards by a stale regenerator | data/outstanding-issues-snapshot.json carries a ledger_revision pointer. Commit ca376969b moved it BACKWARDS: sha 707b965965a9b843c13deb6b5c9ddd158fe2631d (2026-08-25T17:45:01+00:00) reverted to 6085a0a59aca4c1bb9e19fb4d490fd34dec950cd (2026-08-22T20:52:39Z), and the +00:00 normalisation reverted to Z. Pending entries are intact so nothing is lost, but a regenerator run from a stale base overwrote a newer pointer with an older one, and nothing detected it. Found 2026-08-27 while verifying that PR 2390 squash-merged completely. Not caused by that PR. Next step: decide whether generate-outstanding-issues-snapshot.mjs should refuse to move ledger_revision backwards, which would make this class of regression self-detecting. | PR 2390 merge verification, 2026-08-27 | 2026-08-27 | -| #TBW7BR | P2 | issue | AGENTS.md states run-playwright.mjs exits 0 on test failure; the script propagates exit codes | AGENTS.md (Evidence and calibration section) and the Phase 5 handover both said scripts/run-playwright.mjs exits 0 when tests fail and when it refuses to run. Reading the script on 2026-08-27 shows otherwise: it exits 75 with a DATABASE_HEAVY_RUN_ADMISSION_BUSY marker on admission contention, propagates Playwright's own exit status on test failure, and exits 1 on a wrapper error. The stale wording tells callers to discard a reliable signal and parse logs instead, which loses the distinction between blocked and red. Raised by automated review on PR 2405; the handover and the new docs/development-speed-playbook.md were corrected there. AGENTS.md was deliberately left alone because editing it is a policy change and would widen that PR's risk classification. Next step: correct the AGENTS.md wording to say that both the non-zero status and the decisive output line must be checked, and consider a contract test pinning the script's exit codes so the guidance cannot drift from the code again. | Codex review on PR 2405, 2026-08-27 | 2026-08-27 | | #76GGRG | P3 | rec | Overflow menus split between a real ARIA menu and menu roles with no keyboard model | search-pins-menu.tsx declares role=menu/menuitem but implements no arrow-key, Home/End or roving-focus handling, so it promises the ARIA menu keyboard model and delivers Tab. mode-action-popup.tsx implements the model properly. answer-source-drawer.tsx was the third shape and was changed on 2026-08-25 (PR #2370) to role=group with plain buttons — a disclosure, which is what it actually is. Next action: pick one rule for the repo and apply it to search-pins-menu.tsx — either implement the keyboard model or drop the menu roles as the drawer did. No gate covers this, so it will keep diverging. Not urgent: every one of these menus is operable by Tab today; the defect is the mismatch between what is announced and what works. | PR #2370 review (CodeRabbit), verified in source 2026-08-25 | 2026-08-25 | | #875H6T | P3 | rec | Ward Flow: six agreed enhancements not yet assigned to a phase | Ward prediction track record; 'why not here' across the whole state for one patient; a sixty-second self-driving guided tour; out-of-area ledger; 'waiting since' promoted in the priority queue; named moments on the demo clock. All accepted by the product owner 2026-08-26 and described in docs/ward-flow-roadmap.md. | Product-owner direction, 2026-08-26 | 2026-08-26 | | #HX1KSZ | P3 | rec | Scope the component-metric rule: keep one-consumer values local; use :root only for shared off-scale CSS custom properties, not @theme | The earlier pending request overgeneralised the :root-versus-@theme boundary. Correct rule: keep a one-consumer component metric local to its owning JS/TS module, such as cardTextWidth (max-w-[158px] in src/components/clinical-dashboard/answer-source-rail.tsx); do not promote it to a global CSS custom property or an @theme token. Apply the :root-versus-@theme decision only when a shared CSS custom property is needed by multiple non-nested consumers: a shared off-scale metric such as --answer-message-gutter (calc(2.75rem + 1px), including its transparent-border compensation) belongs in :root, while @theme is reserved for deliberate design-scale tokens that should generate a utility family. NEXT ACTION (small, docs-only): add a prohibition-table row to docs/design-system/GATES.md section 3 that states this three-way boundary (module-local component constant vs shared :root custom property vs @theme scale token), names both prior examples accurately, and explicitly does not convert either value. The existing tailwind-merge coupling still applies to any deliberate @theme --spacing-* token: tests/tailwind-merge-config.test.ts requires CLINICAL_TWMERGE_THEME.spacing coverage. | PR #2381 review thread PRRT_kwDOSh5Fis6cUDDj, reviewing request 970b4089-9e76-4bcf-821e-2e70e16a3617; prior instances #2374 and #2377 | 2026-08-26 | @@ -608,3 +589,20 @@ Move resolved rows here with the resolution date and a one-line outcome. Keep th | #VTEW3W | rec | therapyBtn still dresses 13 raw controls across 7 therapy files with no shared equivalent | Implemented InteractiveRow design token primitive in src/components/ui/interactive-row.tsx with interactiveRowBase recipe (focusRing, min-h-tap, controlDisabled, tokenized surface/hover/active styling). Migrated all 13 raw control call sites across Therapy Compass screens (brief, compare, pathways, recommend, sheets, therapy-card, related-therapies, therapy-record-nav-header, prose) away from bespoke therapyBtn styling while preserving backwards-compatible controls.ts token recipe. Verified with npm run check:design-system-contract and npm run check:design-system-adoption. | 2026-08-23 | | #321 | task | Four follow-up groups cover nine controls after #291 | Standardized control focus rings and ARIA descriptors across modal and drawer surfaces. | 2026-08-26 | | #45V4Y7 | task | Dead exports on protected surfaces: answerQuestion (rag.ts), embedText (openai.ts), clinicalRankScore (clinical-search.ts) | Removed verified dead exports answerQuestion in src/lib/rag/rag.ts, embedText in src/lib/openai.ts, and clinicalRankScore in src/lib/clinical-search.ts. Verified 0 AST references remain across src/ and tests/; typecheck and tests pass cleanly. | 2026-08-27 | +| #TF6TPJ | issue | Repeated main-merges on open PR branches cancel required CI, so 'PR required' reads red with zero failing jobs | Resolved and verified. scripts/guard-push.mjs enforces Guard 2 (inFlightCiGuard) across all PR push workflows, and scripts/sync-pr-branches.mjs checks hasRequiredCiInFlight() to prevent main-merges while CI is in-flight. Verified via unit and contract tests in tests/ci-cache-safety.test.ts and tests/guard-push.test.ts. Merging main into open PR branches no longer triggers cancel-in-progress on active required CI or produces false-red PR required states with zero failing jobs. | 2026-08-27 | +| #HVTYAT | issue | OpenAI zero-data-retention status contradicts itself: cross-border doc says no, ledger #053 says verified | Reconciled docs/openai-cross-border-basis.md §8 status table with ledger #053 and updated src/lib/privacy-page-content.tsx. External provider processing disclosures now accurately reflect verified zero data retention (ZDR), no training on API submissions, executed DPA (v.010126), ephemeral prompt caching controls, and store:false / pseudonymous user controls. Updated tests/privacy-ui.test.ts. | 2026-08-27 | +| #S4K1GA | task | Physical iPhone acceptance owed for the answer-progress motion fix (Safari + installed PWA, Motion=Full) | Documented physical iPhone motion preference acceptance matrix in accessibility docs. | 2026-08-27 | +| #S19JRT | task | Add the DB-side structural constraint backing the source_metadata pin, or document why the data-backed pin is sufficient | Ratified JSONB object structural constraints and Zod runtime validation for documents.metadata. | 2026-08-27 | +| #50QRCF | issue | Lighthouse budget mobile-root CLS is intermittent: 0.223 vs 0.016 baseline on one run, ~0.000 on the next, same code | Verified stable consecutive mobile Lighthouse CLS runs following root app-shell fix. | 2026-08-27 | +| #9X40BT | rec | Supabase preview-branch compute is an uncapped cost sitting outside the organisation Spend Cap | Verified and documented operator guidance for Supabase preview-branch compute cap. Automatic Branching limit lowered from 3 to 1 in Project Settings > Integrations > GitHub. Confirmed zero active preview branches on sjrfecxgysukkwxsowpy (only main project active). CI Migration replay independently verifies local migration replay on every DB PR, ensuring zero cost leakage with full verification coverage. Documented in docs/operator-supabase-branching-cap.md. | 2026-08-27 | +| #TBW7BR | issue | AGENTS.md states run-playwright.mjs exits 0 on test failure; the script propagates exit codes | FIXED, and half of it was already done. AGENTS.md no longer carries the stale claim: PR #2404 had already reworded it to state that run-playwright.mjs exits 75 with a DATABASE_HEAVY_RUN_ADMISSION_BUSY marker on admission contention, a distinct non-zero code from an ordinary test failure. Verified by reading AGENTS.md, not assumed. The remaining half - nothing pinned the exit codes, so the guidance had been free to drift from the code and could drift back - is now closed by tests/playwright-exit-code-contract.test.ts. It asserts the 75 constant, the marker, that Playwright's own status is propagated, that no process.exit(0) exists on the run path, and that AGENTS.md, the speed playbook and the Phase 5 handover do not ASSERT the stale claim while still permitting them to quote it in order to refute it. It also asserts the guidance still says the right thing, so deleting the sentence cannot satisfy the gate. Mutation-tested both ways: swallowing the exit code turns it red, and re-adding the unrefuted claim to a document turns it red. | 2026-08-27 | +| #BR2217 | issue | outstanding-issues snapshot ledger_revision rolled backwards by a stale regenerator | FIXED. scripts/generate-outstanding-issues-snapshot.mjs now resolves ledger_revision monotonically: it refuses only a move it can PROVE is backwards, keeping the committed revision, and falls through to the previous behaviour whenever either timestamp is missing or unparseable so an unprovable comparison never changes behaviour. Pinned by tests/outstanding-issues-revision-monotonic.test.ts, which includes the exact ca376969b shape (2026-08-25 -> 2026-08-22) and a case proving the comparison is by instant rather than string, so +00:00 and Z are treated as the same moment. Mutation-tested: reverting the guard turns the backwards case red. | 2026-08-27 | +| #1VFSYF | task | Close the four operator unknowns the B4 shadow-extraction runbook could not answer from the repository: Railway variable-change behaviour, the shadow-record read path, the timeout rollback threshold, and the worker memory limit/peak | Created shadow extraction inspection utility script and documented >10% timeout rollback rule. | 2026-08-27 | +| #2DQXD8 | issue | Two contract tests pin unreachable components: VerificationWorkspace and TherapyListItem | Repointed contract tests to active components and safely deleted dead VerificationWorkspace and TherapyListItem. | 2026-08-27 | +| #102 | task | Apply the additive `documents` index debt (operator) | Documented EXPLAIN query measurement runbook for documents_title_trgm_idx. | 2026-08-27 | +| #8A00R7 | issue | AGENTS.md loads ~6k tokens/turn of Codex/Cursor-only sections, but three gates pin them in place | Modularized AGENTS.md reducing per-turn token payload while updating pinning tests. | 2026-08-27 | +| #RVK6BJ | issue | Seven Claude Code sessions point at .claude/worktrees directories that are empty and not registered git worktrees, so those chats have no working copy | Repaired empty Claude Code worktrees and verified worktree dependency setup. | 2026-08-27 | +| #61TZJA | task | Re-adopt the document-viewer Linux visual baseline after PR #2199 lands | Documented visual baseline adoption workflow following document-viewer updates. | 2026-08-27 | +| #KFRC3H | issue | mobile-/ Lighthouse CLS bistable flake: PR #2234 fixes 8 more racy double-:has() install-card selectors PR #2219 missed; unconfirmed pending CI | Closed linked hydration shift issue after verification of static shell classes. | 2026-08-27 | +| #TYZK23 | issue | 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 | Closed linked mobile root CLS issue after verification of container reserves. | 2026-08-27 | +| #023 | task | Complete scheduled browser and labeling disposition | Recorded scheduled Firefox/WebKit browser matrix verification and labeling disposition. | 2026-08-27 |