From b42d8eb4d7b1c2a94c5ea9b4f99e69cb5effa6f1 Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Thu, 13 Aug 2026 08:25:51 +0000
Subject: [PATCH 1/7] docs(issues): close #248 with migration-history
 forensics; open #312 for residual live drift
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

#248 investigation (no hosted access needed): 20260705180000's DDL never
executed on live — the history row was recorded out-of-band. Partial
transactional apply and later manual drops are excluded; two more of its
indexes are still missing on live per the 2026-08-09 live-drift run.
check:drift did catch the class (red since 2026-07-26) but the failures
were unrouted and 07-19 was green under a stale manifest.

#312 captures the residual: 21 missing_live indexes, 10 match_* RPC
def_hash mismatches, and the unrouted weekly red run.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L7umYGe6hbCfq3NmpZ4Gz4
---
 docs/outstanding-issues.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/docs/outstanding-issues.md b/docs/outstanding-issues.md
index 9d8a9ce3c5..4a6987db0a 100644
--- a/docs/outstanding-issues.md
+++ b/docs/outstanding-issues.md
@@ -130,14 +130,13 @@ removed after current-main verification; it is not missing recommended work.
 | 75 | `#242` | A2 | High — design-system baselines | After human review of Linux baselines | 1–2 hours | Commit approved Linux visual baselines and promote adoption not-committed → committed. **Stop:** never commit baselines from an unreviewed machine run. |
 | 76 | `#244` | A3 | High — design tokens / forced-colors | With any ckb-v2 forced-colours edit | 15–30 min | Keep grouped dark selectors in the forced-colours media block so specificity matches dark rules. **Stop:** do not trim to a single `.ckb-v2.ckb-v2` selector. |
 | 77 | `#245` | A3 | High — cross-mode links | Next CrossModeLinks / analytics pass | 30–60 min | responsive-compact CrossModeLinks keeps duplicate rails in the DOM; prefer one mount or accept test double-counts. **Stop:** do not break phone-only rail contract. |
-| 78 | `#248` | A2 | Operator — Supabase + Specialist | After PR #1614 symptom repair; approved live/history window | 1–2 hours | Investigate why 20260705180000 search-health indexes were missing on live despite applied history; decide if drift checks should catch this class. **Stop:** no hosted mutation without approval. |
-| 79 | `#250` | A2 | High — multi-agent execution | After Wave 0 queue repair on main (done in this capture); run remaining Wave 0/#202 process gates next on the engineering track | multi-wave | Execute the fastest-wins multi-wave plan (Waves 0–4 + operator track) with parallel agents and per-PR gates. Waves do not outrank A1 acuity. **Stop:** provider/RAG approvals still required where flagged. |
-| 80 | `#253` | A2 | High — phone results UI | Next open-PR sweep | 15–30 min | Decide #1606's fate: the `MobileResultFilterControl` it rewrites was deleted by #247, so there is nothing left to hand-merge. Verify keyboard parity of the replacement sheet on a real device, then close #1606 as superseded. **Stop:** the decision is a human's; do not close #1606 automatically. |
-| 81 | `#254` | A2 | Operator — Codex Cloud | Before #1617 leaves draft | 1–2 hours | Re-run Codex Cloud acceptance at the exact current head or mark head-independent evidence. **Stop:** do not treat stale pins as coverage. |
-| 82 | `#257` | Optional | High — formulation/specifiers flake | Standing until second reproduction | 15–30 min | Single unreproduced ui-formulation flake when run with ui-specifiers — record a second sighting only; do not quarantine until three on the same SHA. **Stop:** do not weaken assertions. |
+| 78 | `#250` | A2 | High — multi-agent execution | After Wave 0 queue repair on main (done in this capture); run remaining Wave 0/#202 process gates next on the engineering track | multi-wave | Execute the fastest-wins multi-wave plan (Waves 0–4 + operator track) with parallel agents and per-PR gates. Waves do not outrank A1 acuity. **Stop:** provider/RAG approvals still required where flagged. |
+| 79 | `#253` | A2 | High — phone results UI | Next open-PR sweep | 15–30 min | Decide #1606's fate: the `MobileResultFilterControl` it rewrites was deleted by #247, so there is nothing left to hand-merge. Verify keyboard parity of the replacement sheet on a real device, then close #1606 as superseded. **Stop:** the decision is a human's; do not close #1606 automatically. |
+| 80 | `#254` | A2 | Operator — Codex Cloud | Before #1617 leaves draft | 1–2 hours | Re-run Codex Cloud acceptance at the exact current head or mark head-independent evidence. **Stop:** do not treat stale pins as coverage. |
+| 81 | `#257` | Optional | High — formulation/specifiers flake | Standing until second reproduction | 15–30 min | Single unreproduced ui-formulation flake when run with ui-specifiers — record a second sighting only; do not quarantine until three on the same SHA. **Stop:** do not weaken assertions. |
 
 
-<!-- issues:next-id=312 -->
+<!-- issues:next-id=313 -->
 ## Open items
 
 > **Merged-main canary update (2026-07-23, run `30018289898`):** the new structured report correctly recorded evaluated tree `c24f2e8f2d30d0c59fc1eba025d3dcd63478137e`, run/attempt identity and `cross-region-runner` latency context. Golden retrieval remained 36/36 with document/content recall 1.0 and no failed cases. The 44-case answer gate had grounded-supported and unsupported-correct rates of 1.0, but failed because `neuroleptic-side-effect-escalation` again returned one citation where two are required (citation-failure rate 0.0227). `admission-discharge-comparison` again omitted the specific AKG admission document after `comparison_source_extractive_fallback`; `admission-discharge-coverage-paraphrase` was advisory-only at 24,870 ms. Answer cost was reported as `$0.234736`. Do not retry immediately: retain this as the first structured datapoint, compare it with the scheduled 2026-07-26 report, and keep retrieval/ranking unchanged.
@@ -234,7 +233,6 @@ removed after current-main verification; it is not missing recommended work.
 | #242 | P2 | task | Commit approved Linux visual baselines and promote adoption not-committed → committed | VERIFIED CORRECT 2026-08-12 — re-checked against merged main during the full ledger sweep and left unchanged: Six linux/ PNGs are committed, but the adoption manifest still carries 68 `not-committed` entries — the surfaces flip is the remaining work, as stated. This stamp exists so a later reader can tell "checked and still true" from "never looked at"; the two were indistinguishable before. Baselines and provenance are DONE as of PR #1729 (branch claude/ds-adopt-visual-baselines): all six linux/ PNGs committed from ubuntu artifact visual-baseline-31251091603 (main @ bc33d414e), AWAITING_BASELINE emptied, and tests/__screenshots__/linux/provenance.json written with per-candidate SHA-256 + dimensions and an approved human review. Proven by that PR's own run: visual-junit tests=9 failures=0 skipped=0, and no visual-candidates/ directory, i.e. all six compared rather than skipped. REMAINING: only the surfaces flip to baseline.status committed. Blocked on ordering, measured 2026-08-08: validateLinuxVisualBaselineSet short-circuits on declaredPaths.length===0, so declaring files activates its rule that no non-allowlisted path may change since candidateSourceHead — and PR #1729 necessarily changed tests/design-system-adoption.test.ts, whose initialiseCandidateRepository seeded fixtures from the LIVE spec and so failed the moment AWAITING_BASELINE emptied. The two cannot land together. Next: after #1729 merges, re-capture candidates from a main run that already contains that fixture fix, then flip the surfaces against that head. Note this does not affect whether pixels compare — Playwright compares because the goldens exist on disk. | PR #1616 review findings; session 2026-08-05 | 2026-08-05 |
 | #244 | P3 | rec | Forced-colours v2 mapping depends on grouped dark selectors staying in the media block | IN FLIGHT 2026-08-12 in PR #1841 (forced-colours selector specificity). Checked against the open-PR list during the full ledger sweep. Do NOT start this row while that PR is open — duplicating a queued conversion is the exact failure #292 records, and it has happened twice. Re-verify this row against main after that PR merges, and close it there rather than here. ckb-v2-tokens.css forced-colours block lists .ckb-v2.ckb-v2, .dark .ckb-v2.ckb-v2, and .ckb-v2.dark.ckb-v2 so specificity matches dark rules. Trimming to a single .ckb-v2.ckb-v2 silently drops dark HCM. Next: keep the contract test pin; never trim that selector group. | PR #1616 review findings; session 2026-08-05 | 2026-08-05 |
 | #245 | P3 | rec | responsive-compact CrossModeLinks keeps duplicate rails in the DOM | IN FLIGHT 2026-08-12 in PR #1842 (CrossModeLinks rail behaviour). Checked against the open-PR list during the full ledger sweep. Do NOT start this row while that PR is open — duplicating a queued conversion is the exact failure #292 records, and it has happened twice. Re-verify this row against main after that PR merges, and close it there rather than here. Phone chip rail and md+ card rail both mount; display:none removes the inactive from the a11y tree. Tests/analytics counting role=link see doubles; cross-mode-links-rail is phone-only. Next: prefer the variant test ids; do not collapse to one rail with JS breakpoints (hydration risk). | PR #1616 review findings; session 2026-08-05 | 2026-08-05 |
-| #248 | P2 | issue | Investigate why 20260705180000 search-health indexes were missing on live despite applied history | PR #1614 repairs the symptom with a mark-applied guard only. Confirm out-of-band whether the earlier reconcile migration partially applied, indexes were manually dropped, or schema_migrations was repaired — and whether check:drift should have caught this class before runtime search_schema_health. Renumbered from this PR's original #237 → #246 because main already used #237–#247 (PR #1616 findings plus the results-bar rows from PR #1615). | PR #1614 review / session 2026-08-05 (renumbered on main merge) | 2026-08-05 |
 | #250 | P2 | task | Execute the fastest-wins multi-wave plan (Wave 0–4) | SUPERSEDED IN LARGE PART 2026-08-12 — this row is a wave plan whose contents have been overtaken, and as written it now misdirects. Rows it names as live A1 work are CLOSED: #207 and #226 were archived on main, and #166 (its sibling in that cluster) archived in the 2026-08-12 sweep. Of its engineering waves: 1B's gate-integrity set is done (#149, #210 re-scoped, #204/#167 covered by in-flight PR #1837); 1C's hygiene set is largely done or in flight (#232, #151, #154, #187, #142, #156, #186 all now carry IN FLIGHT notes against PR #1835/#1836); Wave 0/#202 is in flight in PR #1840. What genuinely remains of the plan is Wave 1A (#147 phone CLS, still open and still reproducible offline at zero provider cost), Wave 2 (#117 then #118), and Wave 3 (#098 then #189). The A1 track is now just #059, #053 and #231 — two operator rows and one live investigation. Next: either re-cut this row against that much smaller remainder, or close it and let #147/#117/#118/#098/#189 stand on their own, which is probably the honest move now that the multi-agent framing has served its purpose. Stop unchanged: no RAG behaviour change without flag plus canary, no provider gates without approval, and do not mix operationalRisk with clinical or UI in one squash. | session 2026-08-05 fastest-wins plan | 2026-08-05 |
 | #253 | P3 | task | #1606 needs a hand-merge against merged PR #1615, not a rebase | SUPERSEDED IN PART 2026-08-07: the component both PRs rewrite no longer exists. `MobileResultFilterControl` — the native `<select>` whose system-blue selected-value highlight #1606 set out to fix — was deleted when every mode moved to `ResultFilterTrigger` + `ResultFilterSheet` (#247). The blue-highlight defect is therefore gone by removal rather than by #1606's portal menu, and #1615's iOS 16px anti-zoom rule no longer applies to any phone results filter (it still governs other native selects; see search-chrome-behaviour rule 5). What is left of this row is a decision, not a merge: #1606 is still open and cannot be rebased onto a function that was deleted. Recommend closing it as superseded rather than hand-merging — but that is a human call, and this row stays open until someone makes it. On keyboard parity, correcting an earlier version of this row that claimed otherwise: `ResultFilterSheet` does NOT use native radio inputs. It is `role="radiogroup"` over buttons with a bespoke roving-tabIndex handler — one tab stop per group, Arrow/Home/End moving focus, selection following except onto a dead end — modelled on `SegmentedControl`. That is the same shape #1606 hand-rolled, so parity is plausible but not free; the DOM tests in `tests/search-results-header-band.dom.test.tsx` pin it, and a real-device pass is still worth doing before closing #1606. The Codex P2 about ArrowDown focusing a disabled placeholder is answered by construction: arrowing onto a dead end moves focus so its note is announced but never commits it, asserted by "puts a dead end on the arrow path without ever selecting it". | session 2026-08-05 open-PR review sweep; PR #1606 (open, dirty, verified live); Codex review thread on search-results-header-band.tsx:696 | 2026-08-05 |
 | #254 | P2 | issue | PR #1617's Codex Cloud acceptance evidence is pinned to a head the branch has moved past | PR #1617 is the surviving side of the Codex Cloud MCP dispute (PR #1613 was closed against it on 2026-08-05), and its whole case rests on one first-hand measurement: a fresh Codex Cloud task reporting 'no Railway tool exposed', 'no Supabase tool exposed', 'no GitHub tool exposed' — zero provider tools from repo-written MCP config — while the hosted OAuth path passed in ChatGPT. That evidence is recorded in docs/audit/cloud-connection-acceptance-2026-08-05.md against task head 76dfe85fa93787b3845d0bd460aa18ff753ca2ca, and the PR body states 'The final branch head is 7d485f88db391cc7e8e73c57ddbde61f532375fc'. The branch head is now bf7684a77ef5fa5d53a1e7891cb7f446d4741e4a, so both pins are stale and the acceptance no longer describes what would merge. This matters more than usual because the acceptance IS the argument: #1613 was closed on the strength of it, and its own merge gate is the kind of exact-head check that a moved head invalidates. Next action: before #1617 leaves draft, re-run the fresh Codex Cloud acceptance at the exact current head and update both the report and the body pin, or state explicitly which parts of the evidence are head-independent (the connector-page absence of Railway/Supabase is a product-surface fact and does not depend on the head; the zero-tool discovery result does). Stop: do not treat the 76dfe85f/7d485f88 evidence as covering the current head, and do not reopen #1613 on the basis that #1617's evidence is stale — staleness is not refutation. Renumbered from this PR's original #251 → #254 because main claimed #249–#251 via PR #1624. | session 2026-08-05 open-PR review sweep; PR #1617 body and docs/audit/cloud-connection-acceptance-2026-08-05.md | 2026-08-05 |
@@ -269,6 +267,7 @@ removed after current-main verification; it is not missing recommended work.
 | #309 | P2 | task | Facet groups of 6-20 options render as chips, not the dense list docs/filter-contract.md section 5 requires | Raised by the Codex reviewer on PR #1858 (P2) and correct. Section 5 of docs/filter-contract.md sets density by option count: <=5 chips, 6-20 dense full-width list with a right-aligned count column and group headings, >20 or >3 groups adds find-a-filter and collapse-by-default. Formulation is the first real facet adoption and renders NINE derived domains, so it should be in the 6-20 band, but ResultFilterFacetChips only has one layout — a wrapping chip row — and it is used at both breakpoints. So the first adoption sets the precedent of bypassing the density rule. **Why it was not fixed in #1858:** making the shared renderer density-aware changes a component every facet consumer will use, needs a layout decision at both breakpoints, and overlaps the >20 tier that PR F is scheduled to port up from the documents panel (which already has its own dense list, find-a-filter and collapse). That is a design decision and a PR of its own, not a scoped fix inside a mode adoption. **Next:** decide whether the shared renderer grows a density prop derived from options.length, or whether PR F's port-up supplies the dense tier and facet modes adopt it then; either way add a nine-option DOM assertion so the band is pinned rather than incidental. **Stop:** do not add a per-mode dense list — a second hand-rolled facet layout is exactly the breakpoint drift the shared renderer was extracted to remove. Services (PR C) will have six groups and hits the >3-groups branch of the same rule, so this should be settled before or with it. | Codex review on PR #1858; docs/filter-contract.md section 5 | 2026-08-12 |
 | #310 | P2 | issue | Fuzzy catalogue search can match a DIFFERENT drug: fluoxetine to duloxetine at edit distance 2 | MEASURED 2026-08-12 by running the matcher itself, not by reading it. PR #1851 adds Damerau-Levenshtein typo recovery to `src/lib/catalog-search.ts` (`fuzzySearchTokenCount`, `boundedTypoDistance`, `typoDistanceLimit`) and folds it into the score. The tier `term.length >= 8 -> 2 edits` is the problem: Damerau counts an adjacent transposition as ONE edit, so `fluoxetine` -> `duloxetine` is distance 2 (substitute f->d, transpose lu->ul) and both are 10 characters. Confirmed hits against the PR's own algorithm: **fluoxetine -> duloxetine** (SSRI vs SNRI, different drugs), **prednisone -> prednisolone** (different drugs). Intended cases also confirmed working: sertraline -> setraline, olanzapine -> olanzepine. The existing guards DO hold — SSRI/SNRI, ADHD/ODD, citalopram/escitalopram, clozapine/clonazepam and quetiapine/olanzapine all correctly return no match. ONE MITIGATION, stated so this is not over-read: terms under 5 characters are excluded entirely. The fuzzy trigger is evaluated independently for each candidate record, so the hazard persists when both the exact drug and a two-edit near-match are present: the exact record receives a literal score while the wrong drug can independently receive a fuzzy score and appear as an additional result. Blast radius is wide because `catalog-search.ts` feeds ELEVEN modules — medications.ts (prescribing), dsm.ts, differentials.ts, differential-stream.ts, universal-search.ts, specifiers-search-index.ts, tools-catalog.ts, form-ranker.ts, service-ranker.ts. TESTED FIX: capping the >=8 tier at 1 edit removes both cross-drug hits and preserves every legitimate typo recovery in the sample — a one-line change to `typoDistanceLimit`. Next: if PR #1851 is still open, raise this on it; if it merged, apply the cap directly and add a test over real catalogue drug names with both the exact and near-match records present, asserting the wrong drug is excluded while the exact drug remains. Stop: do not remove fuzzy search outright — the typo recovery is genuinely useful and the guards are otherwise well judged. Note `classifyPullRequestFiles` returns clinicalRisk:true for this path (governance preflight fires) but ragRanking:false, which is correct — this is catalogue ranking, not the pgvector retrieval path. | session 2026-08-12; PR #1851 (codex/investigate-recent-regression-issues); algorithm re-run locally against real drug-name pairs; src/lib/catalog-search.ts | 2026-08-12 |
 | #311 | P3 | task | Promote the derived ledger loss-detector into scripts/ — it has now earned its place twice | During the 2026-08-12 sweep, two main-merges silently reverted edits to `docs/outstanding-issues.md`, including the ENTIRE #293 refutation (a `grep sm:min-h-0` returned 0; the text survived only in commit a6bfc6f). It went unnoticed because the recovery script was HAND-ENUMERATED — it listed 15 archives and 8 updates from one commit and could therefore only restore what the author remembered. The replacement is derived rather than listed: read every row id this branch has ever stamped out of `git rev-list <merge-base>..HEAD` plus `git show <commit>:docs/outstanding-issues.md`, then assert each of those ids that is still OPEN carries its stamp text, and exit non-zero listing any that lost it. It has now proved itself twice — it caught the intentional #262 divergence (main's version was newer than the branch's, correctly left alone) and would have caught the #293 loss the hand-written list missed. The plan that created it said it should stay a scratch script 'unless it proves useful more than once'; that condition is met. Next: port it to scripts/ (suggested `check-ledger-stamp-retention.mjs`), generalise the stamp token from the hard-coded 2026-08-12 date to a `--since` or marker argument, add a self-test in the style of the other ledger scripts, and document it beside `ledger:dedupe` for use after any main sync that touches the ledger. Stop: do NOT wire it into verify:cheap or CI — it is a branch-local safety net for a human or agent mid-sweep, and it has no meaning on a branch that has not stamped rows. Related: #156 and #168, which track the id-allocation race that produces these merges in the first place. | session 2026-08-12 ledger sweep; scratch loss-check.mjs; #293 restoration from a6bfc6f | 2026-08-12 |
+| #312 | P1 | issue | Live DB is missing 21 repo-defined indexes and 10 retrieval RPC bodies diverge; weekly live-drift has been red since 2026-07-26 with no routing | Found while closing #248 (2026-08-13). The 20260804110240/#1614 repair fixed only the 4 search_schema_health-monitored indexes. The 2026-08-09 scheduled live-drift run (Actions run 31330856982) still reports: 21 missing_live indexes spanning many migrations — including documents_title_trgm_idx and document_chunks_content_trgm_idx from 20260705180000 (RAG hot-path trigram indexes; also the subject of #102's bare-column work), audit_logs_*, document_images_*, ingestion_job_stages_*, medication_records_owner_category_idx, rag_aliases/rag_queries/rag_query_misses indexes, api_rate_limits, storage_cleanup_jobs, image_caption_cache, indexing_v3_agent_jobs, document_index_quality, document_publication_approvals, documents_registry_projection_lookup_idx, document_chunks_anchor_idx, document_index_units_heading_path_idx, document_summaries_owner_idx — plus 2 unexpected_live indexes and def_hash mismatches on 10 match_* retrieval RPCs (protected RAG surface: live function bodies differ from repo; could be benign normalization or real divergence — must be diffed, not assumed). Root-cause pattern per #248 closure: migration-history rows recorded without their DDL executing, exposed when the 2026-07-31 manifest regeneration caught schema.sql up to reality (07-19 run was green under the stale manifest). Next (operator + specialist, approved window; NO hosted mutation without approval): (1) run the fingerprint query — select version, name, statements is null as repaired from supabase_migrations.schema_migrations where version in ('20260705180000') — and sample other versions whose objects are missing, to confirm the mark-applied mechanism; (2) diff each mismatched match_* RPC live body vs repo before touching anything (RAG impact assessment; live may be AHEAD of repo or behind); (3) codify or repair the 21 indexes via the documented concurrent-prebuild + mark-applied guard pattern of 20260804110240, batched, not raw SQL; (4) route scheduled live-drift failures somewhere visible (issue auto-comment or notification) so a red weekly run cannot sit unactioned for 3 weeks again; (5) re-run live-drift green. Sequencing note: doing (3) for the two trigram indexes overlaps #102 — coordinate so the canary-gated #102 work is not preempted by a blind restore. | session 2026-08-13 / Actions runs 30763871562 + 31330856982 / #248 closure | 2026-08-13 |
 
 ## Resolved / archive
 
@@ -478,3 +477,4 @@ Move resolved rows here with the resolution date and a one-line outcome. Keep th
 | #202 | rec | Recommendation answers must revalidate the ledger against origin/main, not a stale checkout | Resolved 2026-08-12: issues:report reads cached origin/main when available and emits explicit revalidation and checkout-lag metadata, with a visible stale fallback. | 2026-08-12 |
 | #249 | rec | Extend issues/plan with an agent-safe wins classifier | Resolved 2026-08-12: issues:report provides a conservative optional agent-safe-wins classifier while retaining A1 blockers and queue order. | 2026-08-12 |
 | #251 | rec | Handoff checklist should pair gates skill with verification-router | Resolved 2026-08-12: handoff pairs verification routing with one smallest gate and requires a decisive proof line without default broad-gate stacking. | 2026-08-12 |
+| #248 | issue | Investigate why 20260705180000 search-health indexes were missing on live despite applied history | Investigation complete 2026-08-13 (session, Fable). Determined from repo + PR #1614 + live-drift workflow history, no hosted access needed: 20260705180000's DDL NEVER EXECUTED on live — its history row was recorded out-of-band (mark-applied/repair or hand-apply of the function half only). Evidence: (1) Supabase wraps each migration in one transaction, so a persisted partial apply is impossible; (2) the later 20260706010000/20260706200000 migrations are behaviorally live (alias-aware health function; schema_drift_snapshot RPC), which requires 20260705180000's history row recorded first; (3) of its 10 create-index statements, the only ones 'present' before the 08-04 repair were those satisfied by legacy-named aliases, and TWO MORE of its indexes (documents_title_trgm_idx, document_chunks_content_trgm_idx) are STILL missing on live per the 2026-08-09 live-drift run — impossible if the migration had run. 'Manually dropped later' and 'partial transaction' are excluded. check:drift DID catch this class: scheduled live-drift red on 2026-07-26 and 2026-08-02 with exactly these missing_live findings, before the 08-04 runtime discovery — the gap was 07-19 green under a pre-07-31 stale manifest plus no routing of red scheduled runs to anyone. Residual one-query operator confirmation (statements IS NULL fingerprint in supabase_migrations.schema_migrations for version 20260705180000) folded into the new follow-up row with the live drift backlog. | 2026-08-13 |

From cc82d60f1fbd39c2fa0c2e59d5c47cf4dfa9758f Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Thu, 13 Aug 2026 09:06:35 +0000
Subject: [PATCH 2/7] docs(db): add database remediation and future-proofing
 plan; anchor it on #312

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L7umYGe6hbCfq3NmpZ4Gz4
---
 docs/database-remediation-plan.md | 195 ++++++++++++++++++++++++++++++
 docs/outstanding-issues.md        |   2 +-
 2 files changed, 196 insertions(+), 1 deletion(-)
 create mode 100644 docs/database-remediation-plan.md

diff --git a/docs/database-remediation-plan.md b/docs/database-remediation-plan.md
new file mode 100644
index 0000000000..81bd9b4a5a
--- /dev/null
+++ b/docs/database-remediation-plan.md
@@ -0,0 +1,195 @@
+# Database remediation & future-proofing plan — 2026-08
+
+Owner: operator (Josh) + specialist session. Source findings: ledger `#248` (closed 2026-08-13)
+and `#312` (P1, open). Companion evidence: live-drift Actions runs `30763871562` (2026-08-02) and
+`31330856982` (2026-08-09), PR #1614, `supabase/migrations/20260804110240_restore_rag_search_health_indexes.sql`.
+
+**Scope.** Fixes, in dependency order: the live-vs-repo schema gap (21 missing indexes, 2
+unexpected indexes, 10 diverged `match_*` RPC bodies), the migration-history integrity defect that
+caused it, drift-detection routing, and the surrounding database debt (`#102`, `#011`, `#036`,
+`#022`, `#025`, `#056`/`#057`, `#183`, `#188`/`#196`–`#200`, `#191`, `#098`/`#099`). Ends with
+standing protections so a history row can never again be recorded without its DDL being verified.
+
+**Standing rules for every phase.** No hosted mutation without explicit approval for that phase.
+Never raw-SQL a drift fix — every live change is codified (migration + `schema.sql` mirror +
+regenerated `drift-manifest.json`) in the same change. PITR/backup restore point captured before
+any mutating phase. Every phase ends with pasted decisive evidence, not exit codes. RAG-protected
+surfaces (`match_*` RPCs, anything under `src/lib/rag/**`) are flagged before editing and
+behaviour changes need a live eval-canary pair (36/36, recall 1.0, zero per-case rr regressions).
+
+---
+
+## Phase 0 — Enablement (repo-side, no hosted access; can start immediately)
+
+0.1 **Drift-failure routing** (the "red for three weeks, nobody told" fix). Extend
+`.github/workflows/live-drift.yml`: on failure, create-or-update a pinned GitHub issue titled
+`Live drift check failing` carrying the finding list, and mark it resolved-comment on the next
+green run. Failure becomes a visible, assignable object instead of a silent red row.
+
+0.2 **Post-migration drift trigger.** Add a `workflow_run`/`push` trigger so live-drift also runs
+after any push to `main` that touches `supabase/migrations/**` — drift is checked within minutes
+of the change that could cause it, not up to a week later.
+
+0.3 **Session tooling** (`#183`): add `SUPABASE_ACCESS_TOKEN` (and Sentry token if desired) to the
+operator environment/secrets so migration-history reads and CLI repair are possible in approved
+windows. Names only in logs, never values.
+
+0.4 **Evidence file**: create `docs/audit/live-drift-forensics-2026-08.md`; all phase outputs land
+there, dated.
+
+Gate: `check:github-actions` (workflow pin/policy), `verify:pr-local` for the workflow edits.
+
+## Phase 1 — Forensics: establish the truth (read-only hosted window, ~1 h)
+
+1.1 **Migration-history fingerprint.** Run and record:
+
+```sql
+select version, name, statements is null as no_statements,
+       coalesce(cardinality(statements), 0) as stmt_count
+from supabase_migrations.schema_migrations
+order by version;
+```
+
+Every `no_statements = true` row is a mark-applied/repair fingerprint. Expected: `20260705180000`
+and plausibly the ancestors of the other 19 missing indexes. This converts "systemic pattern" from
+inference to a named list.
+
+1.2 **RPC divergence dossier.** For each of the 10 mismatched `match_*` functions:
+`select pg_get_functiondef(oid)` on live, diff against the repo's canonical body, classify:
+**live-ahead** (hotfixed live, repo stale), **repo-ahead** (live stale), or **normalization
+noise** (whitespace/qualifier only). No edits. This is the highest-stakes unknown in the whole
+plan — live retrieval behaviour may currently depend on bodies the repo does not contain.
+
+1.3 **Index inventory & sizing.** For the 21 missing and 2 unexpected indexes: owning-table
+`pg_relation_size`, and `EXPLAIN (ANALYZE, BUFFERS)` for the known hot queries
+(`documents` title ILIKE, `document_chunks` content search, `rag_retrieval_logs` miss scan).
+These are the before-measurements for Phase 4, including the `#231` latency hypothesis.
+
+Stop rule: read-only; if anything unexpected appears (e.g. objects missing that the app needs
+right now), report before proceeding.
+
+## Phase 2 — Staging rehearsal (`#056`, prerequisite for safe production work)
+
+2.1 Bring `Clinical KB Staging` to full migration parity (it is ~24 migrations behind). This
+doubles as the rehearsal: the replay exercises every migration end-to-end, including the
+`20260804110240` guard (staging must prebuild or take the transactional builds — it is idle, so
+transactional is fine there).
+
+2.2 Run `check:drift` against staging. Staging green proves the repo chain is self-consistent
+before production is touched.
+
+2.3 Keep `#057` (soak + rollback drill) queued for after Phase 3, against an exact candidate.
+
+## Phase 3 — RPC reconciliation (clinical-risk core; before indexes because it can change answers)
+
+Per the Phase 1.2 classification:
+
+- **Normalization noise** → fix the manifest normalizer / regenerate; no hosted change.
+- **Live-ahead** → codify the live body into a new migration + `schema.sql` mirror.
+  PR carries `RAG impact: no retrieval behaviour change — codifying already-live body` and the
+  diff as evidence. This is the safe default and likely majority case.
+- **Repo-ahead** → deploying the repo body changes live behaviour: requires the approved
+  eval-canary pair (baseline → post, 36/36, recall 1.0) around the deploy. Batch these
+  separately; one revertible migration each.
+
+Stop rule: any RPC whose diff is not clearly classifiable gets its own decision item — never
+"probably fine".
+
+## Phase 4 — Index restoration (mutating window, off-peak, batched)
+
+4.1 **Batch A — small tables** (`audit_logs`, `api_rate_limits`, `rag_aliases`, `rag_queries`,
+`rag_query_misses`, `image_caption_cache`, `storage_cleanup_jobs`, `indexing_v3_agent_jobs`,
+`document_index_quality`, `document_publication_approvals`, `medication_records`,
+`ingestion_job_stages`, `document_summaries_owner_idx`): `CREATE INDEX CONCURRENTLY IF NOT EXISTS`
+one at a time, verify `indisvalid AND indisready`, drop-and-retry any invalid build.
+
+4.2 **Batch B — large tables** (`document_chunks_anchor_idx`, `document_chunks_content_trgm_idx`,
+`documents_title_trgm_idx`, `documents_registry_projection_lookup_idx`,
+`document_index_units_heading_path_idx`, `document_images_*`): same procedure, off-peak, one at a
+time, monitoring locks. Note: the two trigram indexes are the canonical `20260705180000`
+definitions — restoring them is completing an already-recorded migration, **not** `#102`'s
+canary-gated bare-column work, which stays separately gated.
+
+4.3 **Unexpected live indexes** (`document_table_facts_document_id_idx`,
+`storage_cleanup_jobs_owner_id_idx`): decide codify (add to a migration + mirror) or
+`DROP INDEX CONCURRENTLY` if redundant with a canonical index. No silent allowlisting.
+
+4.4 **Codify.** One reconcile migration per batch following the `20260804110240` pattern
+exactly: the migration **validates** (presence, `indisvalid`/`indisready`, normalized
+`pg_get_indexdef` match) and fails fast — it never builds. Mark applied only after live
+validation passes. Mirror into `schema.sql`, `npm run drift:manifest`, extend
+`search_schema_health()`'s `required_indexes` for any index the runtime should monitor.
+
+4.5 **Prove it.** Dispatch live-drift: must be green (or only reasoned allowlist warnings).
+Paste the "Compared … against live" + zero-drift lines into the evidence file.
+
+## Phase 5 — Measure and close the loop
+
+5.1 Re-run the Phase 1.3 `EXPLAIN` set; record plan flips (seq scan → index scan) and timings.
+
+5.2 Re-test `#231`: with trigram indexes present, measure whether the 25 s fast-route budget
+still binds. If latency collapses, `#231` may close or re-scope; if not, its investigation
+continues with better data.
+
+5.3 If any Phase 3 RPC deploy changed behaviour: `eval:retrieval:quality` must show 36/36.
+Run `check:production-readiness` once at the end of the window.
+
+## Phase 6 — Future-proofing (make recurrence structurally impossible)
+
+6.1 **History-integrity probe in drift.** Extend `schema_drift_snapshot()` (new migration) to
+also return `schema_migrations` versions with `statements IS NULL`, and teach `check:drift` to
+report any such row not on a reviewed allowlist (each allowlisted version needs a pointer to its
+guard migration). A mark-applied row without a validating guard migration becomes permanent,
+visible drift.
+
+6.2 **Guard-migration contract.** Document in `AGENTS.md`/`docs/database-drift-detection.md`:
+any history repair or mark-applied MUST ship a fail-fast validation migration (the
+`20260804110240` pattern). Add a repo test asserting every allowlisted `statements IS NULL`
+version has a matching `*_restore_*`/`*_reconcile_*` guard file.
+
+6.3 **Runtime coverage ratchet.** `search_schema_health()` monitors a curated index list; the 21
+missing indexes were invisible to it. Add a repo test that every index created by migrations on
+retrieval-critical tables is either in `required_indexes` or consciously listed as unmonitored —
+so coverage decisions are explicit.
+
+6.4 **DR codification** (`#188` → `#196`–`#200`): move `pg_cron` schedules and `app.*` GUCs into
+idempotent migrations where the platform allows; write the operator runbook + names-only verify
+script for Vault secrets, edge-function deploys, and dashboard settings. Then `#057`'s restore
+drill validates the whole set.
+
+6.5 **Same-window dashboard items:** `#011` percentage-based connection-pool allocation;
+`#200` re-entered auth/pool/keys config verification.
+
+## Phase 7 — Deferred structural debt (after drift is green and stays green)
+
+- `#022` hosted apply of the BMJ attestation migration (its own approved window + human review).
+- `#025` configure the Railway webhook so the deployed document-change plumbing goes live.
+- `#036` explicit `public_corpus` marker migration (privacy hardening; supabase-schema-guardian
+  review).
+- `#191` ACL-migration consolidation (maturity X5) — **last**, because rewriting migration files
+  is exactly the operation the new history-integrity checks exist to police; doing it after 6.1/6.2
+  means the safety net is live.
+- `#098`/`#099` round-trip budget tests on the answer path (repo-side, independent).
+
+---
+
+## Order rationale (why this sequence)
+
+Truth before mutation (Phase 1), rehearsal before production (Phase 2), the change that can alter
+clinical answers before the changes that only speed them up (Phase 3 before 4), measurement before
+closure (Phase 5), and prevention built while the incident is fresh (Phase 6). Consolidation and
+nice-to-haves last (Phase 7). Phase 0 is first because it needs no approval and immediately fixes
+the failure that let this sit unnoticed.
+
+## Approval map
+
+| Phase | Hosted access                                              | Approval needed                                      |
+| ----- | ---------------------------------------------------------- | ---------------------------------------------------- |
+| 0     | none (GitHub Actions secrets already hold the service key) | repo PR review only                                  |
+| 1     | read-only production                                       | yes — read window                                    |
+| 2     | staging mutation                                           | yes — staging window                                 |
+| 3     | production RPC deploys                                     | yes — per batch; canary approval for repo-ahead RPCs |
+| 4     | production DDL (concurrent)                                | yes — off-peak window per batch                      |
+| 5     | read-only + one eval dispatch (~$1–2) if RPCs changed      | yes for eval                                         |
+| 6     | one migration deploy (6.1); rest repo/docs                 | yes for 6.1                                          |
+| 7     | per item                                                   | per item                                             |
diff --git a/docs/outstanding-issues.md b/docs/outstanding-issues.md
index 4a6987db0a..4d421bd342 100644
--- a/docs/outstanding-issues.md
+++ b/docs/outstanding-issues.md
@@ -267,7 +267,7 @@ removed after current-main verification; it is not missing recommended work.
 | #309 | P2 | task | Facet groups of 6-20 options render as chips, not the dense list docs/filter-contract.md section 5 requires | Raised by the Codex reviewer on PR #1858 (P2) and correct. Section 5 of docs/filter-contract.md sets density by option count: <=5 chips, 6-20 dense full-width list with a right-aligned count column and group headings, >20 or >3 groups adds find-a-filter and collapse-by-default. Formulation is the first real facet adoption and renders NINE derived domains, so it should be in the 6-20 band, but ResultFilterFacetChips only has one layout — a wrapping chip row — and it is used at both breakpoints. So the first adoption sets the precedent of bypassing the density rule. **Why it was not fixed in #1858:** making the shared renderer density-aware changes a component every facet consumer will use, needs a layout decision at both breakpoints, and overlaps the >20 tier that PR F is scheduled to port up from the documents panel (which already has its own dense list, find-a-filter and collapse). That is a design decision and a PR of its own, not a scoped fix inside a mode adoption. **Next:** decide whether the shared renderer grows a density prop derived from options.length, or whether PR F's port-up supplies the dense tier and facet modes adopt it then; either way add a nine-option DOM assertion so the band is pinned rather than incidental. **Stop:** do not add a per-mode dense list — a second hand-rolled facet layout is exactly the breakpoint drift the shared renderer was extracted to remove. Services (PR C) will have six groups and hits the >3-groups branch of the same rule, so this should be settled before or with it. | Codex review on PR #1858; docs/filter-contract.md section 5 | 2026-08-12 |
 | #310 | P2 | issue | Fuzzy catalogue search can match a DIFFERENT drug: fluoxetine to duloxetine at edit distance 2 | MEASURED 2026-08-12 by running the matcher itself, not by reading it. PR #1851 adds Damerau-Levenshtein typo recovery to `src/lib/catalog-search.ts` (`fuzzySearchTokenCount`, `boundedTypoDistance`, `typoDistanceLimit`) and folds it into the score. The tier `term.length >= 8 -> 2 edits` is the problem: Damerau counts an adjacent transposition as ONE edit, so `fluoxetine` -> `duloxetine` is distance 2 (substitute f->d, transpose lu->ul) and both are 10 characters. Confirmed hits against the PR's own algorithm: **fluoxetine -> duloxetine** (SSRI vs SNRI, different drugs), **prednisone -> prednisolone** (different drugs). Intended cases also confirmed working: sertraline -> setraline, olanzapine -> olanzepine. The existing guards DO hold — SSRI/SNRI, ADHD/ODD, citalopram/escitalopram, clozapine/clonazepam and quetiapine/olanzapine all correctly return no match. ONE MITIGATION, stated so this is not over-read: terms under 5 characters are excluded entirely. The fuzzy trigger is evaluated independently for each candidate record, so the hazard persists when both the exact drug and a two-edit near-match are present: the exact record receives a literal score while the wrong drug can independently receive a fuzzy score and appear as an additional result. Blast radius is wide because `catalog-search.ts` feeds ELEVEN modules — medications.ts (prescribing), dsm.ts, differentials.ts, differential-stream.ts, universal-search.ts, specifiers-search-index.ts, tools-catalog.ts, form-ranker.ts, service-ranker.ts. TESTED FIX: capping the >=8 tier at 1 edit removes both cross-drug hits and preserves every legitimate typo recovery in the sample — a one-line change to `typoDistanceLimit`. Next: if PR #1851 is still open, raise this on it; if it merged, apply the cap directly and add a test over real catalogue drug names with both the exact and near-match records present, asserting the wrong drug is excluded while the exact drug remains. Stop: do not remove fuzzy search outright — the typo recovery is genuinely useful and the guards are otherwise well judged. Note `classifyPullRequestFiles` returns clinicalRisk:true for this path (governance preflight fires) but ragRanking:false, which is correct — this is catalogue ranking, not the pgvector retrieval path. | session 2026-08-12; PR #1851 (codex/investigate-recent-regression-issues); algorithm re-run locally against real drug-name pairs; src/lib/catalog-search.ts | 2026-08-12 |
 | #311 | P3 | task | Promote the derived ledger loss-detector into scripts/ — it has now earned its place twice | During the 2026-08-12 sweep, two main-merges silently reverted edits to `docs/outstanding-issues.md`, including the ENTIRE #293 refutation (a `grep sm:min-h-0` returned 0; the text survived only in commit a6bfc6f). It went unnoticed because the recovery script was HAND-ENUMERATED — it listed 15 archives and 8 updates from one commit and could therefore only restore what the author remembered. The replacement is derived rather than listed: read every row id this branch has ever stamped out of `git rev-list <merge-base>..HEAD` plus `git show <commit>:docs/outstanding-issues.md`, then assert each of those ids that is still OPEN carries its stamp text, and exit non-zero listing any that lost it. It has now proved itself twice — it caught the intentional #262 divergence (main's version was newer than the branch's, correctly left alone) and would have caught the #293 loss the hand-written list missed. The plan that created it said it should stay a scratch script 'unless it proves useful more than once'; that condition is met. Next: port it to scripts/ (suggested `check-ledger-stamp-retention.mjs`), generalise the stamp token from the hard-coded 2026-08-12 date to a `--since` or marker argument, add a self-test in the style of the other ledger scripts, and document it beside `ledger:dedupe` for use after any main sync that touches the ledger. Stop: do NOT wire it into verify:cheap or CI — it is a branch-local safety net for a human or agent mid-sweep, and it has no meaning on a branch that has not stamped rows. Related: #156 and #168, which track the id-allocation race that produces these merges in the first place. | session 2026-08-12 ledger sweep; scratch loss-check.mjs; #293 restoration from a6bfc6f | 2026-08-12 |
-| #312 | P1 | issue | Live DB is missing 21 repo-defined indexes and 10 retrieval RPC bodies diverge; weekly live-drift has been red since 2026-07-26 with no routing | Found while closing #248 (2026-08-13). The 20260804110240/#1614 repair fixed only the 4 search_schema_health-monitored indexes. The 2026-08-09 scheduled live-drift run (Actions run 31330856982) still reports: 21 missing_live indexes spanning many migrations — including documents_title_trgm_idx and document_chunks_content_trgm_idx from 20260705180000 (RAG hot-path trigram indexes; also the subject of #102's bare-column work), audit_logs_*, document_images_*, ingestion_job_stages_*, medication_records_owner_category_idx, rag_aliases/rag_queries/rag_query_misses indexes, api_rate_limits, storage_cleanup_jobs, image_caption_cache, indexing_v3_agent_jobs, document_index_quality, document_publication_approvals, documents_registry_projection_lookup_idx, document_chunks_anchor_idx, document_index_units_heading_path_idx, document_summaries_owner_idx — plus 2 unexpected_live indexes and def_hash mismatches on 10 match_* retrieval RPCs (protected RAG surface: live function bodies differ from repo; could be benign normalization or real divergence — must be diffed, not assumed). Root-cause pattern per #248 closure: migration-history rows recorded without their DDL executing, exposed when the 2026-07-31 manifest regeneration caught schema.sql up to reality (07-19 run was green under the stale manifest). Next (operator + specialist, approved window; NO hosted mutation without approval): (1) run the fingerprint query — select version, name, statements is null as repaired from supabase_migrations.schema_migrations where version in ('20260705180000') — and sample other versions whose objects are missing, to confirm the mark-applied mechanism; (2) diff each mismatched match_* RPC live body vs repo before touching anything (RAG impact assessment; live may be AHEAD of repo or behind); (3) codify or repair the 21 indexes via the documented concurrent-prebuild + mark-applied guard pattern of 20260804110240, batched, not raw SQL; (4) route scheduled live-drift failures somewhere visible (issue auto-comment or notification) so a red weekly run cannot sit unactioned for 3 weeks again; (5) re-run live-drift green. Sequencing note: doing (3) for the two trigram indexes overlaps #102 — coordinate so the canary-gated #102 work is not preempted by a blind restore. | session 2026-08-13 / Actions runs 30763871562 + 31330856982 / #248 closure | 2026-08-13 |
+| #312 | P1 | issue | Live DB is missing 21 repo-defined indexes and 10 retrieval RPC bodies diverge; weekly live-drift has been red since 2026-07-26 with no routing | APPEND 2026-08-13: full remediation + future-proofing plan authored at docs/database-remediation-plan.md (phases 0-7: routing + post-migration drift trigger first, read-only forensics, staging rehearsal #056, RPC reconciliation before index restoration, batched CREATE INDEX CONCURRENTLY + 20260804110240-pattern guard migrations, EXPLAIN/#231 re-measure, history-integrity probe in schema_drift_snapshot, guard-migration contract, DR codification #196-#200, deferred #022/#025/#036/#191). This row remains the tracking anchor; execute per the plan's approval map. Prior detail: Found while closing #248 (2026-08-13). The 20260804110240/#1614 repair fixed only the 4 search_schema_health-monitored indexes. The 2026-08-09 scheduled live-drift run (Actions run 31330856982) still reports 21 missing_live indexes spanning many migrations, 2 unexpected_live indexes, and def_hash mismatches on 10 match_* retrieval RPCs (protected RAG surface — diff before touching). Root cause: migration-history rows recorded without their DDL executing. No hosted mutation without approval. | session 2026-08-13 / Actions runs 30763871562 + 31330856982 / #248 closure | 2026-08-13 |
 
 ## Resolved / archive
 

From 5c9e1b6a6766efee147af97ff1ef2a53729f56e9 Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Thu, 13 Aug 2026 09:23:10 +0000
Subject: [PATCH 3/7] docs(db): add multi-session remediation playbook with
 per-phase prompts

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01L7umYGe6hbCfq3NmpZ4Gz4
---
 docs/database-remediation-playbook.md | 254 ++++++++++++++++++++++++++
 1 file changed, 254 insertions(+)
 create mode 100644 docs/database-remediation-playbook.md

diff --git a/docs/database-remediation-playbook.md b/docs/database-remediation-playbook.md
new file mode 100644
index 0000000000..3f7347cc7c
--- /dev/null
+++ b/docs/database-remediation-playbook.md
@@ -0,0 +1,254 @@
+# Database remediation playbook — multi-session execution guide
+
+Companion to [`database-remediation-plan.md`](database-remediation-plan.md) (the plan of record —
+read it first in every session). This playbook exists so the work can be executed across **many
+separate chat sessions**: each phase below carries the full context a fresh session needs and a
+ready-to-paste prompt. Tracking anchor: ledger `#312` (P1). Update it as phases complete.
+
+---
+
+## Context briefing (paste-adjacent background every session can rely on)
+
+**What happened.** Investigation of ledger `#248` (closed 2026-08-13) proved that migration
+`20260705180000_reconcile_search_health_indexes.sql` was recorded as applied on the live Supabase
+project (`Clinical KB Database`, ref `sjrfecxgysukkwxsowpy`) **without its DDL ever executing**.
+The history row was recorded out-of-band (mark-applied/repair). Evidence: Supabase wraps each
+migration in one transaction (partial persistence impossible); later 2026-07-06 migrations are
+behaviorally live, requiring that history row to pre-exist; and two of its indexes are still
+missing on live today. This is systemic, not one-off.
+
+**Current live state** (from scheduled `live-drift.yml` Actions run `31330856982`, 2026-08-09):
+
+- 21 `missing_live` indexes across many migrations — tables: `audit_logs` (2), `api_rate_limits`,
+  `document_chunks` (2, incl. `document_chunks_content_trgm_idx`), `document_images` (3),
+  `document_index_quality`, `document_index_units`, `document_publication_approvals`,
+  `document_summaries`, `documents` (2, incl. `documents_title_trgm_idx`),
+  `image_caption_cache`, `indexing_v3_agent_jobs`, `ingestion_job_stages`, `medication_records`,
+  `rag_aliases`, `rag_queries`, `rag_query_misses`, `storage_cleanup_jobs`.
+- 2 `unexpected_live` indexes: `document_table_facts_document_id_idx`,
+  `storage_cleanup_jobs_owner_id_idx`.
+- `def_hash` mismatches on 10 `match_*` retrieval RPCs (protected RAG surface; live bodies vs
+  repo — direction unknown until diffed).
+- The weekly `live-drift` run has been red since 2026-07-26 with no notification routing.
+
+**Prior repair to imitate.** PR #1614 / migration `20260804110240_restore_rag_search_health_indexes.sql`
+is the approved pattern: operator prebuilds indexes with `CREATE INDEX CONCURRENTLY` outside any
+transaction, validates `pg_index.indisvalid AND indisready` plus normalized `pg_get_indexdef`
+against a pinned canonical definition, and only then marks a fail-fast guard migration applied.
+
+**Key repo facts every session needs:**
+
+- Repo: `BigSimmo/Database`, default branch `main`. Live Supabase ref `sjrfecxgysukkwxsowpy`
+  (the ref `qjgitjyhxrwxsrydablr` is stale — never use). Migrations target role `postgres`.
+- `supabase/migrations/` is the source of truth; `supabase/schema.sql` is a mirror;
+  `supabase/drift-manifest.json` is generated (`npm run drift:manifest`, needs Docker) and
+  sha-pinned to `schema.sql`.
+- `check:drift` compares live (`public.schema_drift_snapshot()` RPC, service-role only) against
+  the manifest. `search_schema_health()` is the runtime probe; its `required_indexes` list lives
+  inside the function and is changed only by migration, never by editing `schema.sql`.
+- Ledger: `docs/outstanding-issues.md`, mutated only via `npm run issues:add|update|done`.
+- AGENTS.md rules that bind here: provider confirmation boundary (no OpenAI/Supabase/CI calls
+  without explicit user approval); RAG ranking protection (flag before touching `match_*` RPCs or
+  `src/lib/rag/**`; behaviour changes need a live eval-canary pair 36/36 / recall 1.0); run
+  `npm run format` and commit before every push; `npm run check:migration-role` after Supabase SQL
+  changes; PR bodies are parsed input (`RAG impact:` line, Clinical Governance Preflight).
+- Related open ledger rows: `#312` (anchor), `#102` (canary-gated documents index debt — do NOT
+  fold into the restore), `#231` (latency budget binding — trigram-index hypothesis), `#056`/`#057`
+  (staging parity, soak), `#011` (pool allocation), `#036` (public-corpus marker), `#022` (BMJ
+  attestation apply), `#025` (webhook inert), `#183` (missing SUPABASE_ACCESS_TOKEN),
+  `#188`/`#196`–`#200` (DR gaps), `#191` (ACL consolidation — last), `#098`/`#099` (round trips).
+
+**Session hygiene for every phase:** start from a fresh worktree off latest `origin/main`
+(`newtask` skill), one branch per phase (`claude/db-remediation-phase-N`), record evidence in
+`docs/audit/live-drift-forensics-2026-08.md`, hand off via the `handoff` skill, and update `#312`
+via `npm run issues:update` before the session ends.
+
+**Model guidance:** Fable for Phases 1, 3, 6 (and #191 later) — judgment-heavy, expensive
+mistakes. Opus is sufficient for Phases 0, 2, 4, 5, 7 — execution against this playbook.
+
+---
+
+## Phase 0 — Enablement (repo-only; no approval window needed) · Opus · 2–4 h
+
+Deliverables: drift-failure routing, post-migration drift trigger, evidence file scaffold.
+Definition of done: PR merged; `check:github-actions` and `verify:pr-local` green; a forced
+`workflow_dispatch` failure produces/updates the pinned issue.
+
+**Prompt to paste:**
+
+> Read docs/database-remediation-plan.md and docs/database-remediation-playbook.md, then execute
+> Phase 0 only. On a fresh branch off origin/main: (1) extend .github/workflows/live-drift.yml so
+> a failed run creates or updates a single pinned GitHub issue titled "Live drift check failing",
+> body containing the drift finding lines from the run log and the run URL, and so the next green
+> run comments resolution on that issue — use a SHA-pinned actions/github-script step consistent
+> with this repo's pinning policy and the least permissions that work (issues: write on that job
+> only); (2) add a trigger so live-drift also runs on push to main when supabase/migrations/** or
+> supabase/schema.sql changed; keep schedule + workflow_dispatch; keep concurrency
+> cancel-in-progress: false; (3) create docs/audit/live-drift-forensics-2026-08.md with headed
+> empty sections for Phases 1–5 evidence; (4) do NOT touch any Supabase code or call any provider.
+> Run npm run check:github-actions and npm run verify:pr-local, run npm run format and commit it,
+> push, open a PR (no RAG impact line needed — no RAG surface touched), and update ledger #312 via
+> npm run issues:update noting Phase 0 delivered. Do not watch the PR after opening it.
+
+Note for the operator (not the model): adding `SUPABASE_ACCESS_TOKEN` to environment secrets
+(`#183`) is dashboard work you do yourself; never paste token values into a chat.
+
+## Phase 1 — Read-only forensics (approved read-only window) · Fable · 1–2 h
+
+Deliverables: migration-history fingerprint list, RPC divergence dossier (10 diffs classified),
+index sizing + `EXPLAIN` baselines. Definition of done: all three recorded in the forensics doc;
+`#312` updated with the named mark-applied version list; no writes performed.
+
+**Prompt to paste:**
+
+> Read docs/database-remediation-plan.md and docs/database-remediation-playbook.md. I authorize a
+> READ-ONLY window against the live Supabase project Clinical KB Database
+> (sjrfecxgysukkwxsowpy) for Phase 1. Absolutely no INSERT/UPDATE/DELETE/DDL — SELECT and EXPLAIN
+> only; stop and report if any step would write. Execute: (1) run the migration-history
+> fingerprint query from the plan (statements IS NULL over supabase_migrations.schema_migrations)
+> and list every no-statements version with its name; (2) for each of the 10 match_* RPCs named in
+> the 2026-08-09 live-drift log, fetch pg_get_functiondef from live and diff against the repo's
+> canonical body (search supabase/migrations for the latest create-or-replace of each), then
+> classify each as live-ahead, repo-ahead, or normalization noise, quoting the decisive diff hunks
+> — this is a protected RAG surface, so classification accuracy matters more than speed, and any
+> ambiguous diff is recorded as UNCLASSIFIED with the ambiguity explained, never guessed; (3) for
+> the 21 missing and 2 unexpected indexes, record owning-table pg_relation_size and run EXPLAIN
+> (ANALYZE, BUFFERS) for the documents title ILIKE query, the document_chunks content search, and
+> the rag_retrieval_logs miss scan as before-baselines. Write all evidence with dates and run IDs
+> into docs/audit/live-drift-forensics-2026-08.md, update ledger #312, commit, push, PR (docs-only;
+> RAG impact line not required since no RAG code changed — but state in the PR body that RPC diffs
+> were read and classified). Do not fix anything in this phase.
+
+## Phase 2 — Staging parity rehearsal (approved staging window) · Opus · 2–4 h
+
+Deliverables: staging at full migration parity; `check:drift` green against staging.
+Definition of done: pasted replay output + green drift line in the forensics doc; `#056` updated.
+
+**Prompt to paste:**
+
+> Read docs/database-remediation-plan.md and docs/database-remediation-playbook.md. I authorize
+> mutation of the STAGING Supabase tier (Clinical KB Staging) only — production
+> (sjrfecxgysukkwxsowpy) remains read-only and must not be targeted; verify the target ref before
+> every command and abort if it resolves to production. Execute Phase 2: replay the full committed
+> migration chain onto staging to parity (staging is idle, so guard migrations like 20260804110240
+> may need their indexes built first — build them transactionally or concurrently there, then
+> proceed), then run check:drift against staging and get it green. Record the replay tail, any
+> migration that misbehaved on clean replay (that is a finding — capture it), and the green drift
+> output in docs/audit/live-drift-forensics-2026-08.md. Update ledger #056 and #312, commit, push,
+> PR. If any migration fails on clean replay, stop, record, and report rather than patching live
+> objects by hand.
+
+## Phase 3 — RPC reconciliation (approved production window; canary approvals per repo-ahead RPC) · Fable · 2–6 h
+
+Prerequisite: Phase 1 dossier. Deliverables: every mismatched RPC codified or reconciled.
+Definition of done: zero function `def_hash` mismatches on the next live-drift run (or reasoned
+allowlist entries); eval evidence attached for any behaviour-changing deploy.
+
+**Prompt to paste:**
+
+> Read docs/database-remediation-plan.md, docs/database-remediation-playbook.md, and the Phase 1
+> RPC dossier in docs/audit/live-drift-forensics-2026-08.md. Flag now, before editing: this task
+> touches protected RAG retrieval RPCs. I authorize Phase 3 against production
+> (sjrfecxgysukkwxsowpy) per the dossier's classifications: for normalization-noise entries, fix
+> the manifest/normalizer side only and regenerate; for live-ahead entries, author migrations that
+> codify the live body verbatim plus the schema.sql mirror and regenerated drift-manifest, PR body
+> carrying "RAG impact: no retrieval behaviour change — codifying already-live body" with the diff
+> as evidence; for repo-ahead entries, STOP and list them with their behavioural delta — each
+> needs my separate explicit approval and a live eval-canary pair (baseline then post, 36/36
+> retrieval cases, recall 1.0, zero per-case rr regressions) around its deploy, one revertible
+> migration each. Any UNCLASSIFIED entry stays untouched and is escalated to me. Run npm run
+> check:migration-role and tests/supabase-schema.test.ts, format, commit, push, PR with the full
+> Clinical Governance Preflight. Update #312 with per-RPC outcomes.
+
+## Phase 4 — Index restoration (approved off-peak production window) · Opus · 2–3 h active
+
+Prerequisites: Phases 1–3. Deliverables: 21 indexes restored + validated, 2 unexpected indexes
+dispositioned, guard migrations landed, live-drift green. Definition of done: green live-drift
+dispatch output pasted; `search_schema_health()` still `ok: true`.
+
+**Prompt to paste:**
+
+> Read docs/database-remediation-plan.md and docs/database-remediation-playbook.md plus the Phase
+> 1 sizing table. I authorize Phase 4 DDL against production (sjrfecxgysukkwxsowpy) in this
+> off-peak window. Procedure, exactly: capture/confirm a PITR restore point first; then for Batch
+> A (small tables) and Batch B (large tables, one at a time) run CREATE INDEX CONCURRENTLY IF NOT
+> EXISTS with the canonical definitions from the repo migrations, after each build verify
+> pg_index.indisvalid AND indisready and DROP INDEX CONCURRENTLY + retry any invalid build; hold
+> the two #102-adjacent bare-column indexes out entirely — restore only the canonical
+> 20260705180000 trigram definitions; disposition the 2 unexpected_live indexes per the plan
+> (codify or DROP INDEX CONCURRENTLY if redundant — state which and why). Then author one
+> fail-fast guard migration per batch following 20260804110240 exactly (validates, never builds),
+> mirror into schema.sql, npm run drift:manifest, extend search_schema_health() required_indexes
+> via migration for indexes the runtime should monitor, run check:migration-role and the supabase
+> schema tests, format, commit, push, PR ("RAG impact: no retrieval behaviour change — restoring
+> already-recorded canonical index definitions; ordering-affecting surfaces untouched"), full
+> governance preflight. Finally dispatch the live-drift workflow and paste its green output into
+> docs/audit/live-drift-forensics-2026-08.md. Update #312. If any single build repeatedly fails or
+> locks, skip it, record it, continue the batch, and report — never fall back to a transactional
+> build on production.
+
+## Phase 5 — Measure and close the loop (read-only + optional eval; ~$1–2 if RPCs changed) · Opus · 1–2 h
+
+Deliverables: after-EXPLAINs, `#231` re-test, readiness check. Definition of done: before/after
+table in the forensics doc; `#231` updated with data; `check:production-readiness` output recorded.
+
+**Prompt to paste:**
+
+> Read docs/database-remediation-plan.md, docs/database-remediation-playbook.md, and the Phase 1
+> baselines. I authorize a read-only production window plus npm run check:production-readiness
+> (and eval:retrieval:quality ONLY if Phase 3 deployed a behaviour-changing RPC — ask me first if
+> unsure). Re-run the Phase 1.3 EXPLAIN (ANALYZE, BUFFERS) set and build a before/after table
+> showing plan changes and timings; then assess ledger #231: with the trigram indexes present,
+> exercise the answer path's retrieval timing and state with evidence whether the 25s fast-route
+> budget still binds — update #231 accordingly (close, re-scope, or confirm still open). Record
+> everything in docs/audit/live-drift-forensics-2026-08.md, update #312, commit, push, PR.
+
+## Phase 6 — Future-proofing (repo + one migration deploy) · Fable · 4–6 h
+
+Deliverables: history-integrity probe, guard-migration contract + enforcing test, monitoring
+ratchet. Definition of done: `check:drift` reports unguarded `statements IS NULL` versions; repo
+test fails on an allowlisted version without a guard file; docs updated; migration deployed.
+
+**Prompt to paste:**
+
+> Read docs/database-remediation-plan.md and docs/database-remediation-playbook.md, then execute
+> Phase 6. Design first, then build: (1) a migration extending public.schema_drift_snapshot() to
+> also return supabase_migrations.schema_migrations versions whose statements IS NULL, and a
+> check-drift change reporting any such version absent from a new reviewed allowlist
+> (supabase/drift-allowlist.json style — every entry needs a reason and a pointer to its guard
+> migration); think about how this could false-positive (legitimate repairs, squashed baselines)
+> and make the allowlist expressive enough to stay honest without being a rubber stamp; (2) a
+> documented guard-migration contract in docs/database-drift-detection.md and an AGENTS.md note:
+> any mark-applied/history repair MUST ship a fail-fast validation migration per 20260804110240,
+> plus a repo test asserting every allowlisted no-statements version has a matching guard
+> migration file; (3) a repo test ratcheting index monitoring: every index defined by migrations
+> on retrieval-critical tables (documents, document_chunks, document_index_units,
+> document_embedding_fields, document_memory_cards, rag_retrieval_logs) is either in
+> search_schema_health() required_indexes or in an explicit unmonitored list with reasons. Deploy
+> only the snapshot migration to production with my approval when the PR is ready — everything
+> else is repo-side. Run check:migration-role, the supabase schema tests, verify:pr-local; format,
+> commit, push, PR with governance preflight and "RAG impact: no retrieval behaviour change —
+> observability-only snapshot extension". Update #312 and capture any residuals via /issues.
+
+## Phase 7 — Deferred debt (each its own session)
+
+Run each as an independent task when its trigger arrives; none blocks the phases above.
+
+- `#022` BMJ attestation hosted apply — Opus; needs its own approved window + human review step.
+- `#025` Railway webhook configuration — operator dashboard + Opus verification session.
+- `#036` explicit public-corpus marker migration — Opus, with supabase-schema-guardian review.
+- `#191` ACL-migration consolidation — **Fable**, only after Phase 6 is live; prompt should
+  require proving RLS/owner-scope equivalence before and after consolidation.
+- `#196`–`#200` DR codification + `#057` soak/rollback drill — Opus, following
+  docs/operator-backlog.md; verify with names-only output.
+- `#098`/`#099` round-trip budget tests — Opus, repo-only.
+- `#011` pool allocation + `#200` dashboard settings — operator dashboard work, no model needed.
+
+---
+
+## Cross-session tracking
+
+After every phase: update `#312` (`npm run issues:update`), append evidence to
+`docs/audit/live-drift-forensics-2026-08.md`, and record the phase's PR in the normal ledger flow.
+If a session dies mid-phase, the next session re-reads this playbook, the forensics doc, and
+`#312`, and resumes from the last recorded evidence — nothing lives only in chat.

From c3990af2c8be86405a5077c188dfa9099c322aef Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Thu, 13 Aug 2026 18:04:41 +0800
Subject: [PATCH 4/7] docs(db): address live-drift review feedback

---
 docs/database-remediation-plan.md             | 20 ++++++++++--------
 docs/database-remediation-playbook.md         | 21 +++++++++++--------
 .../06779fd3-636c-4c46-900e-89b7ad58a6fe.json | 13 ------------
 .../a3dca734-d253-4c42-8edc-dc690dd140dc.json | 10 +++++++++
 .../b9c97f0e-c175-437e-812d-b70054c666b2.json | 10 ---------
 .../dec50a21-f143-485d-a6b1-f9c3621013a6.json | 13 ++++++++++++
 6 files changed, 46 insertions(+), 41 deletions(-)
 delete mode 100644 docs/outstanding-issues-inbox/06779fd3-636c-4c46-900e-89b7ad58a6fe.json
 create mode 100644 docs/outstanding-issues-inbox/a3dca734-d253-4c42-8edc-dc690dd140dc.json
 delete mode 100644 docs/outstanding-issues-inbox/b9c97f0e-c175-437e-812d-b70054c666b2.json
 create mode 100644 docs/outstanding-issues-inbox/dec50a21-f143-485d-a6b1-f9c3621013a6.json

diff --git a/docs/database-remediation-plan.md b/docs/database-remediation-plan.md
index 8617965f01..9bb9a18561 100644
--- a/docs/database-remediation-plan.md
+++ b/docs/database-remediation-plan.md
@@ -1,15 +1,16 @@
 # Database remediation & future-proofing plan — 2026-08
 
-Owner: operator (Josh) + specialist session. Source findings: ledger `#248` (closure queued by
-this PR) and the queued P1 live-drift follow-up. Companion evidence: live-drift Actions runs
+Owner: operator (Josh) + specialist session. Source findings: open ledger `#248` (whose causal
+conclusion awaits a read-only history and audit check) and the queued P1 live-drift follow-up.
+Companion evidence: live-drift Actions runs
 `30763871562` (2026-08-02) and
 `31330856982` (2026-08-09), PR #1614, `supabase/migrations/20260804110240_restore_rag_search_health_indexes.sql`.
 
 **Scope.** Fixes, in dependency order: the live-vs-repo schema gap (21 missing indexes, 2
-unexpected indexes, 10 diverged `match_*` RPC bodies), the migration-history integrity defect that
-caused it, drift-detection routing, and the surrounding database debt (`#102`, `#011`, `#036`,
+unexpected indexes, 10 diverged `match_*` RPC bodies), the unresolved cause of the affected
+migration history, drift-detection routing, and the surrounding database debt (`#102`, `#011`, `#036`,
 `#022`, `#025`, `#056`/`#057`, `#183`, `#188`/`#196`–`#200`, `#191`, `#098`/`#099`). Ends with
-standing protections so a history row can never again be recorded without its DDL being verified.
+standing protections so unverified history repairs remain visible and cannot silently mask drift.
 
 **Standing rules for every phase.** No hosted mutation without explicit approval for that phase.
 Never raw-SQL a drift fix — every live change is codified (migration + `schema.sql` mirror +
@@ -51,9 +52,10 @@ from supabase_migrations.schema_migrations
 order by version;
 ```
 
-Every `no_statements = true` row is a mark-applied/repair fingerprint. Expected: `20260705180000`
-and plausibly the ancestors of the other 19 missing indexes. This converts "systemic pattern" from
-inference to a named list.
+Treat every `no_statements = true` row as a candidate mark-applied/repair signal, not proof of
+cause. Record whether `20260705180000` has that signal, then pair it with relevant audit history
+to distinguish skipped DDL from indexes that were created and later dropped. This turns the current
+hypothesis into a named, evidence-backed conclusion.
 
 1.2 **RPC divergence dossier.** For each of the 10 mismatched `match_*` functions:
 `select pg_get_functiondef(oid)` on live, diff against the repo's canonical body, classify:
@@ -140,7 +142,7 @@ Run `check:production-readiness` once at the end of the window.
 6.1 **History-integrity probe in drift.** Extend `schema_drift_snapshot()` (new migration) to
 also return `schema_migrations` versions with `statements IS NULL`, and teach `check:drift` to
 report any such row not on a reviewed allowlist (each allowlisted version needs a pointer to its
-guard migration). A mark-applied row without a validating guard migration becomes permanent,
+guard migration). A history-repair row without a validating guard migration becomes permanent,
 visible drift.
 
 6.2 **Guard-migration contract.** Document in `AGENTS.md`/`docs/database-drift-detection.md`:
diff --git a/docs/database-remediation-playbook.md b/docs/database-remediation-playbook.md
index c87bfe17ea..a5d9333fb1 100644
--- a/docs/database-remediation-playbook.md
+++ b/docs/database-remediation-playbook.md
@@ -11,13 +11,13 @@ numeric ID by exact title before updating it; never assume an ID.
 
 ## Context briefing (paste-adjacent background every session can rely on)
 
-**What happened.** Investigation of ledger `#248` (closure queued by this PR) proved that migration
-`20260705180000_reconcile_search_health_indexes.sql` was recorded as applied on the live Supabase
-project (`Clinical KB Database`, ref `sjrfecxgysukkwxsowpy`) **without its DDL ever executing**.
-The history row was recorded out-of-band (mark-applied/repair). Evidence: Supabase wraps each
-migration in one transaction (partial persistence impossible); later 2026-07-06 migrations are
-behaviorally live, requiring that history row to pre-exist; and two of its indexes are still
-missing on live today. This is systemic, not one-off.
+**What happened.** Ledger `#248` remains open. Current evidence shows that migration
+`20260705180000_reconcile_search_health_indexes.sql` is recorded as applied on the live Supabase
+project (`Clinical KB Database`, ref `sjrfecxgysukkwxsowpy`) while two of its indexes are
+currently missing. Supabase's transaction model excludes a persisted partial application, and later
+migrations show that history advanced, but neither point distinguishes skipped DDL/mark-applied
+history from indexes that were created and later dropped. The Phase 1 read-only history and audit
+check must establish that cause before the row is closed or remediation is attributed to it.
 
 **Current live state** (from scheduled `live-drift.yml` Actions run `31330856982`, 2026-08-09):
 
@@ -99,7 +99,8 @@ Note for the operator (not the model): adding `SUPABASE_ACCESS_TOKEN` to environ
 
 Deliverables: migration-history fingerprint list, RPC divergence dossier (10 diffs classified),
 index sizing + `EXPLAIN` baselines. Definition of done: all three recorded in the forensics doc;
-The live-drift tracking item is updated with the named mark-applied version list; no writes performed.
+The live-drift tracking item is updated with the no-statements version list and the evidence-based
+conclusion for `#248`; no writes performed.
 
 **Prompt to paste:**
 
@@ -108,7 +109,9 @@ The live-drift tracking item is updated with the named mark-applied version list
 > (sjrfecxgysukkwxsowpy) for Phase 1. Absolutely no INSERT/UPDATE/DELETE/DDL — SELECT and EXPLAIN
 > only; stop and report if any step would write. Execute: (1) run the migration-history
 > fingerprint query from the plan (statements IS NULL over supabase_migrations.schema_migrations)
-> and list every no-statements version with its name; (2) for each of the 10 match_* RPCs named in
+> and list every no-statements version with its name. For `#248`, record whether that result
+> supports a mark-applied/repair history; otherwise retain the alternative that the indexes were
+> created and later dropped. (2) for each of the 10 match_* RPCs named in
 > the 2026-08-09 live-drift log, fetch pg_get_functiondef from live and diff against the repo's
 > canonical body (search supabase/migrations for the latest create-or-replace of each), then
 > classify each as live-ahead, repo-ahead, or normalization noise, quoting the decisive diff hunks
diff --git a/docs/outstanding-issues-inbox/06779fd3-636c-4c46-900e-89b7ad58a6fe.json b/docs/outstanding-issues-inbox/06779fd3-636c-4c46-900e-89b7ad58a6fe.json
deleted file mode 100644
index 65942c5a5c..0000000000
--- a/docs/outstanding-issues-inbox/06779fd3-636c-4c46-900e-89b7ad58a6fe.json
+++ /dev/null
@@ -1,13 +0,0 @@
-{
-  "version": 1,
-  "id": "06779fd3-636c-4c46-900e-89b7ad58a6fe",
-  "createdOn": "2026-08-13",
-  "action": "add",
-  "payload": {
-    "pri": "P1",
-    "type": "issue",
-    "summary": "Live DB is missing 21 repo-defined indexes and 10 retrieval RPC bodies diverge; weekly live-drift has been red since 2026-07-26 with no routing",
-    "detail": "APPEND 2026-08-13: full remediation + future-proofing plan authored at docs/database-remediation-plan.md (phases 0-7: routing + post-migration drift trigger first, read-only forensics, staging rehearsal #056, RPC reconciliation before index restoration, batched CREATE INDEX CONCURRENTLY + 20260804110240-pattern guard migrations, EXPLAIN/#231 re-measure, history-integrity probe in schema_drift_snapshot, guard-migration contract, DR codification #196-#200, deferred #022/#025/#036/#191). This row remains the tracking anchor; execute per the plan's approval map. Prior detail: Found while closing #248 (2026-08-13). The 20260804110240/#1614 repair fixed only the 4 search_schema_health-monitored indexes. The 2026-08-09 scheduled live-drift run (Actions run 31330856982) still reports 21 missing_live indexes spanning many migrations, 2 unexpected_live indexes, and def_hash mismatches on 10 match_* retrieval RPCs (protected RAG surface — diff before touching). Root cause: migration-history rows recorded without their DDL executing. No hosted mutation without approval.",
-    "source": "session 2026-08-13 / Actions runs 30763871562 + 31330856982 / #248 closure"
-  }
-}
diff --git a/docs/outstanding-issues-inbox/a3dca734-d253-4c42-8edc-dc690dd140dc.json b/docs/outstanding-issues-inbox/a3dca734-d253-4c42-8edc-dc690dd140dc.json
new file mode 100644
index 0000000000..af74baa5ae
--- /dev/null
+++ b/docs/outstanding-issues-inbox/a3dca734-d253-4c42-8edc-dc690dd140dc.json
@@ -0,0 +1,10 @@
+{
+  "version": 1,
+  "id": "a3dca734-d253-4c42-8edc-dc690dd140dc",
+  "createdOn": "2026-08-13",
+  "action": "update",
+  "payload": {
+    "id": "#248",
+    "detail": "APPEND 2026-08-13: the prior closure is withdrawn. Repository and live-drift evidence establishes that 20260705180000_reconcile_search_health_indexes.sql is recorded as applied while documents_title_trgm_idx and document_chunks_content_trgm_idx are missing on live. Supabase transaction semantics exclude a persisted partial migration, but the present record does not distinguish skipped DDL/history repair from indexes created and later dropped. In an approved read-only window, query supabase_migrations.schema_migrations for the 20260705180000 statements fingerprint and inspect the relevant audit/history evidence; retain both hypotheses until that evidence establishes the cause. Separately, scheduled check:drift did detect the missing indexes, but red runs were not routed."
+  }
+}
diff --git a/docs/outstanding-issues-inbox/b9c97f0e-c175-437e-812d-b70054c666b2.json b/docs/outstanding-issues-inbox/b9c97f0e-c175-437e-812d-b70054c666b2.json
deleted file mode 100644
index 9a0ab12d24..0000000000
--- a/docs/outstanding-issues-inbox/b9c97f0e-c175-437e-812d-b70054c666b2.json
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "version": 1,
-  "id": "b9c97f0e-c175-437e-812d-b70054c666b2",
-  "createdOn": "2026-08-13",
-  "action": "done",
-  "payload": {
-    "id": "#248",
-    "outcome": "Investigation complete 2026-08-13 (session, Fable). Determined from repo + PR #1614 + live-drift workflow history, no hosted access needed: 20260705180000's DDL NEVER EXECUTED on live — its history row was recorded out-of-band (mark-applied/repair or hand-apply of the function half only). Evidence: (1) Supabase wraps each migration in one transaction, so a persisted partial apply is impossible; (2) the later 20260706010000/20260706200000 migrations are behaviorally live (alias-aware health function; schema_drift_snapshot RPC), which requires 20260705180000's history row recorded first; (3) of its 10 create-index statements, the only ones 'present' before the 08-04 repair were those satisfied by legacy-named aliases, and TWO MORE of its indexes (documents_title_trgm_idx, document_chunks_content_trgm_idx) are STILL missing on live per the 2026-08-09 live-drift run — impossible if the migration had run. 'Manually dropped later' and 'partial transaction' are excluded. check:drift DID catch this class: scheduled live-drift red on 2026-07-26 and 2026-08-02 with exactly these missing_live findings, before the 08-04 runtime discovery — the gap was 07-19 green under a pre-07-31 stale manifest plus no routing of red scheduled runs to anyone. Residual one-query operator confirmation (statements IS NULL fingerprint in supabase_migrations.schema_migrations for version 20260705180000) folded into the new follow-up row with the live drift backlog."
-  }
-}
diff --git a/docs/outstanding-issues-inbox/dec50a21-f143-485d-a6b1-f9c3621013a6.json b/docs/outstanding-issues-inbox/dec50a21-f143-485d-a6b1-f9c3621013a6.json
new file mode 100644
index 0000000000..228c5a3118
--- /dev/null
+++ b/docs/outstanding-issues-inbox/dec50a21-f143-485d-a6b1-f9c3621013a6.json
@@ -0,0 +1,13 @@
+{
+  "version": 1,
+  "id": "dec50a21-f143-485d-a6b1-f9c3621013a6",
+  "createdOn": "2026-08-13",
+  "action": "add",
+  "payload": {
+    "pri": "P1",
+    "type": "issue",
+    "summary": "Live DB is missing 21 repo-defined indexes and 10 retrieval RPC bodies diverge; weekly live-drift has been red since 2026-07-26 with no routing",
+    "detail": "APPEND 2026-08-13: full remediation + future-proofing plan is at docs/database-remediation-plan.md (phases 0-7: routing + post-migration drift trigger, read-only forensics, staging rehearsal #056, RPC reconciliation before index restoration, batched CREATE INDEX CONCURRENTLY + 20260804110240-pattern guard migrations, EXPLAIN/#231 re-measure, history-integrity probe, guard-migration contract, DR codification #196-#200, deferred #022/#025/#036/#191). This row is the tracking anchor and follows the plan approval map. The 2026-08-09 scheduled live-drift run (Actions run 31330856982) reports 21 missing_live indexes across multiple migrations, 2 unexpected_live indexes, and def_hash mismatches on 10 match_* retrieval RPCs (protected RAG surface — diff before touching). The migration-history cause remains unresolved: distinguish skipped DDL/history repair from later index drops with the approved read-only fingerprint and audit check before attributing the drift. No hosted mutation without approval.",
+    "source": "session 2026-08-13 / Actions runs 30763871562 + 31330856982 / open #248"
+  }
+}

From 47e799d3ec443d949fad9dbfc8ccce18f411b2ae Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Thu, 13 Aug 2026 18:32:41 +0800
Subject: [PATCH 5/7] docs: clarify verification evidence and provider
 confirmation

---
 ...c7faaa7a08338429d6d22a13b62d1380353d41b7a0d4.record.md | 2 +-
 docs/database-remediation-playbook.md                     | 8 +++++---
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/docs/branch-review-records/5285abb7f77709fe9c44c7faaa7a08338429d6d22a13b62d1380353d41b7a0d4.record.md b/docs/branch-review-records/5285abb7f77709fe9c44c7faaa7a08338429d6d22a13b62d1380353d41b7a0d4.record.md
index 30d78fa472..c98b1aab74 100644
--- a/docs/branch-review-records/5285abb7f77709fe9c44c7faaa7a08338429d6d22a13b62d1380353d41b7a0d4.record.md
+++ b/docs/branch-review-records/5285abb7f77709fe9c44c7faaa7a08338429d6d22a13b62d1380353d41b7a0d4.record.md
@@ -1 +1 @@
-| 2026-08-13 | claude/fable-tasks-issues-49hnvp | 5c9e1b6a6766efee147af97ff1ef2a53729f56e9 | PR #1906 failing CI conflict repair | Resolved the main-sync ledger conflict by preserving main #312 and converting the PR closure and follow-up into merge-safe inbox requests; removed numeric-ID assumptions from the remediation docs. | Latest GitHub Actions mergeability log inspected; format, sitemap, docs, links, and outstanding-issues checks PASS |
+| 2026-08-13 | claude/fable-tasks-issues-49hnvp | 5c9e1b6a6766efee147af97ff1ef2a53729f56e9 | PR #1906 failing CI conflict repair | Resolved the main-sync ledger conflict by preserving main #312 and converting the PR closure and follow-up into merge-safe inbox requests; removed numeric-ID assumptions from the remediation docs. | Latest GitHub Actions mergeability log inspected; decisive output lines for format, sitemap, documentation, link, and outstanding-issues checks were not captured in this record, so no pass status is claimed for them |
diff --git a/docs/database-remediation-playbook.md b/docs/database-remediation-playbook.md
index a5d9333fb1..d9d089aac1 100644
--- a/docs/database-remediation-playbook.md
+++ b/docs/database-remediation-playbook.md
@@ -88,9 +88,11 @@ Definition of done: PR merged; `check:github-actions` and `verify:pr-local` gree
 > supabase/schema.sql changed; keep schedule + workflow_dispatch; keep concurrency
 > cancel-in-progress: false; (3) create docs/audit/live-drift-forensics-2026-08.md with headed
 > empty sections for Phases 1–5 evidence; (4) do NOT touch any Supabase code or call any provider.
-> Run npm run check:github-actions and npm run verify:pr-local, run npm run format and commit it,
-> push, open a PR (no RAG impact line needed — no RAG surface touched), and update the live-drift tracking item via
-> npm run issues:update noting Phase 0 delivered. Do not watch the PR after opening it.
+> Run npm run check:github-actions and npm run verify:pr-local, run npm run format and commit
+> locally. Stop before pushing, opening a PR, dispatching a workflow, or updating the live-drift
+> tracking item with npm run issues:update; those are provider-backed actions and require explicit
+> user confirmation. After confirmation, publish the branch, open the PR (no RAG impact line needed
+> — no RAG surface touched), update the tracking item, and do not watch the PR after opening it.
 
 Note for the operator (not the model): adding `SUPABASE_ACCESS_TOKEN` to environment secrets
 (`#183`) is dashboard work you do yourself; never paste token values into a chat.

From 0278652780aed45501189327fca0cd7210b2e5ee Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Thu, 13 Aug 2026 18:46:08 +0800
Subject: [PATCH 6/7] fix(ledger): correct immutable record address

---
 ...daf9efba33fea5fa2d4be509699f05b5ea443fe5c5e2792daad.record.md | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 docs/branch-review-records/65bc60c1d30f0daf9efba33fea5fa2d4be509699f05b5ea443fe5c5e2792daad.record.md

diff --git a/docs/branch-review-records/65bc60c1d30f0daf9efba33fea5fa2d4be509699f05b5ea443fe5c5e2792daad.record.md b/docs/branch-review-records/65bc60c1d30f0daf9efba33fea5fa2d4be509699f05b5ea443fe5c5e2792daad.record.md
new file mode 100644
index 0000000000..c98b1aab74
--- /dev/null
+++ b/docs/branch-review-records/65bc60c1d30f0daf9efba33fea5fa2d4be509699f05b5ea443fe5c5e2792daad.record.md
@@ -0,0 +1 @@
+| 2026-08-13 | claude/fable-tasks-issues-49hnvp | 5c9e1b6a6766efee147af97ff1ef2a53729f56e9 | PR #1906 failing CI conflict repair | Resolved the main-sync ledger conflict by preserving main #312 and converting the PR closure and follow-up into merge-safe inbox requests; removed numeric-ID assumptions from the remediation docs. | Latest GitHub Actions mergeability log inspected; decisive output lines for format, sitemap, documentation, link, and outstanding-issues checks were not captured in this record, so no pass status is claimed for them |

From fc1c30aa7a7c5cfafe3421344181b513ffbdca92 Mon Sep 17 00:00:00 2001
From: BigSimmo <87357024+BigSimmo@users.noreply.github.com>
Date: Thu, 13 Aug 2026 18:46:10 +0800
Subject: [PATCH 7/7] fix(ledger): complete immutable record rename

---
 ...9fe9c44c7faaa7a08338429d6d22a13b62d1380353d41b7a0d4.record.md | 1 -
 1 file changed, 1 deletion(-)
 delete mode 100644 docs/branch-review-records/5285abb7f77709fe9c44c7faaa7a08338429d6d22a13b62d1380353d41b7a0d4.record.md

diff --git a/docs/branch-review-records/5285abb7f77709fe9c44c7faaa7a08338429d6d22a13b62d1380353d41b7a0d4.record.md b/docs/branch-review-records/5285abb7f77709fe9c44c7faaa7a08338429d6d22a13b62d1380353d41b7a0d4.record.md
deleted file mode 100644
index c98b1aab74..0000000000
--- a/docs/branch-review-records/5285abb7f77709fe9c44c7faaa7a08338429d6d22a13b62d1380353d41b7a0d4.record.md
+++ /dev/null
@@ -1 +0,0 @@
-| 2026-08-13 | claude/fable-tasks-issues-49hnvp | 5c9e1b6a6766efee147af97ff1ef2a53729f56e9 | PR #1906 failing CI conflict repair | Resolved the main-sync ledger conflict by preserving main #312 and converting the PR closure and follow-up into merge-safe inbox requests; removed numeric-ID assumptions from the remediation docs. | Latest GitHub Actions mergeability log inspected; decisive output lines for format, sitemap, documentation, link, and outstanding-issues checks were not captured in this record, so no pass status is claimed for them |