docs(issues): close the migration-history rows and re-scope the zero-scan measurement

[BigSimmo]

Summary

Post-drift ledger tidying. Five immutable inbox requests, no canonical-ledger edit. The reconcile follows in its own serialized branch once this lands.

• Close #M54C4N (live-drift's Align migration history step fails on PGRST106). Fixed by PR fix(db): read migration history through a service-role RPC so live-drift can pass (#316) #2198 (a341832af), which landed 20260820120000_migration_history_versions_rpc with the schema.sql mirror, a regenerated drift manifest and a rewritten scripts/check-migration-history-alignment.ts. Verified against live-drift run 32514326022 itself (head main11550416206e8c90900ddeea0993337824873a55, conclusion success): the step now reports Remote migration versions: 211 (read via rpc), Remote-only (Preview blockers): 0 and Migration history alignment OK: every remote version exists locally, and the preceding step reports No unexpected schema drift between live and supabase/schema.sql.
• Close #056 (reconcile the existing staging migration history). Staging ikoiolksxqxfxgiyqpnu verified at full parity by a read-only query from a dedicated linked worktree: 211 history rows, latest 20260820120000, zero statements IS NULL, migration_history_versions() present, that row carrying 3 statements — equal to the 211 migration files on main and the 211 remote versions live-drift read from production. The 19 check:drift findings recorded inside that row were a schema.sql-versus-chain disagreement, separately resolved by PR feat(db): codify live SET work_mem on the ten match_* RPCs, the eight schema-only objects, and three chain-stale columns (#316) #2106 and PR feat(db): Phase 4 — restore 20 missing indexes, drop 2 orphans, land guard migrations (#316) #2151, so closing on parity grounds loses nothing. #057 remains the open follow-on.
• Close #3514B7 (live production carries a migration that exists nowhere in the repository). Premise falsified: the migration landed on main in PR fix(db): read migration history through a service-role RPC so live-drift can pass (#316) #2198 together with the mirror and manifest, and local 211 == remote 211 with zero remote-only versions, so production is no longer ahead of the repository.
• Re-scope #47M1XD (restored trigram indexes have never been scanned) with a second read-only production window. The attribution retraction is now stronger and the experiment the row proposed is now known not to discriminate — detail below.
• Escalate #M6JNR8 P2 to P1 (recommended-execution-queue rows cannot be re-graded by any ledger writer operation), with the re-confirmation recorded in its Source cell. Detail preserved unchanged.

The one job this PR could not do

The stale #231 queue row is unchanged, and that is deliberate. It could not be corrected by any sanctioned path:

• updateIssue edits only the Open-items pri/summary/detail/source cells; the sole queue-touching function is pruneResolvedIdFromQueue, which runs on done and only deletes.
• A hand edit of the queue row was refused by the gate, as designed. Probe commit changing row 1 from A1 to A2, reverted immediately: docs/outstanding-issues.md does not exactly match the audited application of 0 moved inbox request(s) from the base.
• Reconciling in this same PR was also refused, as designed: docs/outstanding-issues-inbox/applied/<uuid>.json was introduced without moving the identical pending request from the base.

#M6JNR8 already documents this exact instance and carries an explicit STOP against hand-editing it. It is now P1 because the row is the first thing the session-start hook surfaces and has mis-directed two sessions into a retrieval investigation the measurements closed. The fix is the owner's call between the two options that row names; this PR does not pick one and does not weaken the check.

#47M1XD — what the second window found

• The zero-scan finding got stronger. Between the 2026-08-21 read and 2026-08-22 07:23 UTC the serving indexes advanced under live traffic (document_chunks_search_idx 37,717 to 37,911; documents_title_search_idx 37,299 to 37,512; HNSW 4,906 to 4,921; the sibling-table trigram index 2,372 to 2,389) while document_chunks_content_trgm_idx (OID 1491258) and documents_title_trgm_idx (OID 1491257) stayed at idx_scan 0 andidx_tup_read 0, OIDs unchanged. A counter reset before the first read would have been re-populated by that traffic. Still not proof: pg_stat_reset_single_table_counters is invisible, and production is PostgreSQL 17.6, which predates pg_stat_all_indexes.stats_reset.
• The before/after ANALYZE experiment cannot discriminate, so it was not run.documents, document_chunks, document_table_facts and document_index_units were all ANALYZEd on 2026-08-18 18:08 UTC and every one reports n_mod_since_analyze = 0. Re-ANALYZing an unmodified table re-samples the same rows, so a flat result would be uninterpretable. The owner was asked and chose to skip it; no production mutation was made.
• document_embedding_fields is the one stale table (last analyzed 2026-06-25, 3,148 modifications against 271,097 live tuples, about 1.2% — below the autoanalyze threshold). Hygiene, not a cause of a 31-second regression.
• Plan shapes via public.explain_retrieval_rpc are all a single Function Scan with no inner index names, re-confirming #8VAY97. Real execution times: 1.000 / 4.306 / 0.904 / 15.760 ms.

Verification

Ledger/docs-only diff (5 new JSON inbox requests). npm run verify:pr-local not run: it routinely exceeds 10 minutes on cross-worktree lock contention, and its covering gates were run directly instead.

• npm run check:ledger-write-discipline — Ledger write discipline passed for dea32b8d26b3..HEAD.
• npm run check:outstanding-issues — Ledger inbox check passed: 5 pending request(s), 525 applied. and Outstanding-issues guard passed: 437 rows (78 open, 359 archived), unique display and durable ids, collision-free allocation enabled, deprecated next-id marker ignored, no merge driver, no ids deleted from base dea32b8d26b3.
• npm run check:branch-review-ledger — Branch review ledger guard passed: 880 live table records + 1206 archived + 447 immutable (880 under the 2026-07-29 machine-readable contract), immutable review writes, six cells each, no conflict markers, mojibake, heading records, or duplicates.
• npx prettier --check docs/outstanding-issues-inbox/*.json — All matched files use Prettier code style!
• Reconcile rehearsed locally and reverted: it applies all five cleanly, prunes #056 from the queue, renumbers 1 to 10, and sets #M6JNR8 to P1.

UI verification not run: no UI, routing, styling, or browser behaviour changed.

Risk and rollout

• Risk: minimal. No executable source, schema, migration, workflow, or configuration change. The five inbox requests are inert until a later serialized npm run issues:reconcile applies them.
• Rollback: git revert the single commit; the requests are additive files and nothing reads them until reconcile.
• Provider or production effects: None. Two read-only Supabase windows were used for verification — staging ikoiolksxqxfxgiyqpnu for the #056 parity check and production sjrfecxgysukkwxsowpy for the #47M1XD characterisation — from a dedicated worktree with the project ref re-read before each call and supabase unlink afterwards. No write, no ANALYZE, no migration, no mark-apply. Read-only GitHub Actions reads verified live-drift run 32514326022.
• RAG impact: no retrieval behaviour change — ledger corrections and read-only production measurement; no ranking, selection, or ordering surface touched

Clinical Governance Preflight

• Source-backed claims still require linked source verification before clinical use
• No patient-identifiable document workflow was introduced or expanded without explicit governance approval
• Supabase target remains Clinical KB Database (sjrfecxgysukkwxsowpy)
• Service-role keys and private document access remain server-only
• Demo/synthetic content remains clearly separated from real clinical sources
• Source metadata, review status, and outdated/unknown-source behavior remain conservative
• Deployment classification/TGA SaMD impact was checked when clinical decision-support behavior changed

Notes

• The reconcile is a required follow-up and must be a separate branch cut from origin/mainafter this lands — the write-discipline gate structurally refuses a queue-and-reconcile in one transaction, proven above. Never merge main into that branch and never use GitHub's "Update branch" button on it.
• Owner-only items surfaced by this session, both already tracked: #9X40BT (lower the Supabase automatic-branching limit from 3 to 1 — Branching Compute sits outside the org Spend Cap) and #CCZ4HB (CodeRabbit spending cap exhausted; PR docs(issues): reconcile 19 queued ledger requests and close #316 #2261 landed with no automated review).

[coderabbitai]

Warning

Review limit reached

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

Your current included review allowance is based on your included PR review attempts over the past 7 days.

Next review available in:20 minutes

Limit details: You’ve used the included review currently available. Your 90 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

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

How can I continue?

Wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 137f7e66-1a1d-44c9-a5c0-16fc3fc8b338

📥 Commits

Reviewing files that changed from the base of the PR and between a25a547 and 07d68b5.

📒 Files selected for processing (6)

• docs/branch-review-records/e1e55cd4fef796216d96d803aaf29e7120ffd9bf6f295b54668280658e5684b5.record.md
• docs/outstanding-issues-inbox/65494c5f-927b-4d0d-8564-5933a7c723f3.json
• docs/outstanding-issues-inbox/7ab00925-b9c6-4395-b708-5485d9908fc0.json
• docs/outstanding-issues-inbox/993f7ca7-5277-4399-82fc-19ff981823e4.json
• docs/outstanding-issues-inbox/9bc32602-fe95-40e6-a28c-f28149863699.json
• docs/outstanding-issues-inbox/c6d13677-3dc7-4bea-9a49-d3e200b4eb3e.json

---

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

[supabase]

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

---

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