feat(db): Phase 6.2 — guard the fifteen no-statements history rows (#Q5JHBJ)

[BigSimmo]

Summary

• Phase 6.2 (#Q5JHBJ, #316 umbrella): guard the fifteen migration_history no-statements rows. Six fail-fast validation guard migrations per the 20260804110240 pattern — 20260819110000 dropped objects (absence of 7 functions + 4 indexes), 110100 catalog comments + the purge-rag-retrieval-logs cron job, 110200 three document foreign keys, 110300 forty-six operational index shapes, 110400 the index_generation_id promotion (6 columns + 6 partial indexes + 3 def_hashes), 110500 fifteen function def_hashes read from schema_drift_snapshot() itself — and the fifteen supabase/drift-allowlist.json entries that point at them (class validation, never bare). Every one of the fifteen is validation: none earned superseded (no single later executed migration re-creates every object) or no_ddl (COMMENT ON is a catalog write, not an empty file). schema.sql and drift-manifest.json are unchanged (validation-only guards create nothing).
• Already applied to both hosted tiers inside the owner-authorised window (D4 is OFF, so merge deploys nothing): production by a real supabase db push (pending set was exactly the six; rows carry statements, no_statements false; 210 rows; corpus untouched), staging by the Phase 2 method (six md5-matched rows, no_statements 0, drift comparison green).
• Live-drift run 32251326536 dispatched on this branch: Compare live schema drift SUCCESS — No unexpected schema drift, all 20 history rows allowed. #316's finding set is empty for the first time since 2026-07-26. The job still concludes failure on the next step (Align migration history for Supabase Preview, check:migration-history), which ran for the first time ever and cannot read supabase_migrations over PostgREST (PGRST106, schema not exposed) — a Phase 0 latent defect, not drift; queued as its own P2 in this PR's inbox request, owner decision.
• tests/migration-history-guards.test.ts: the "validation guard must not create the objects it validates" check now ignores string literals/comments (the 20260804110240 reference pattern pins canonical create index … text as data and would have failed the raw regex; no validation entry had ever exercised it), additionally requires set local statement_timeout, and pins that 20260804110240 passes the predicate while a real create index statement fails it.
• Docs: forensics §6.2 completion (classification table, chain-replay + mutation proofs, production/staging pastes, live-drift paste), coordination board row 6 + "where the programme stands", docs/database-drift-detection.md live-state paragraph; ledger inbox requests (#Q5JHBJ update, new P2 for the align step).

Verification

• npm run verify:pr-local — exit 0: Test Files 682 passed | 2 skipped (684) · Tests 7398 passed | 57 skipped (7455), Offline RAG fixture and manifest validation passed (36 golden cases, 26 suites), failed: (none).
• npx vitest run tests/migration-history-guards.test.ts tests/drift-detection.test.ts tests/supabase-schema.test.ts tests/search-health-index-coverage.test.ts tests/migration-history-placeholders.test.ts tests/hosted-migration-role-guard.test.ts — Test Files 6 passed (6) · Tests 113 passed (113).
• npm run check:migration-role — Hosted migration-role guard passed: active hosted SQL/tooling uses postgres and immutable applied history is unchanged.
• npm run check:drift -- --self-test — check-drift: all offline self-tests passed.
• Whole-chain replay into the scratch supabase/postgres:17.6.1.127 image (roles + scaffold, every migration in order, each in its own transaction): Applied 210/210 (all six 20260819110* history guards included) and CHAIN == MANIFEST: no unexpected drift — every hand repair in forensics §2.3/§3.3/Phase 4 is reproduced by the chain; no reconcile migration needed. Seven guard mutants (wrong hash, wrong index def, dropped index, present "absent" index, wrong column type, FK cascade, removed comment) each raise and name their object.
• Production dry-run of all six guards read-only before the push: all passed; a deliberately wrong-hash mutant failed on production naming public.reset_document_index(uuid) def_hash 243f3960…; cron/comment branches confirmed exercised (cron_schema true · purge_job_rows 1).
• npm run check:production-readiness — Verification not run: the change is validation-only guard migrations and allowlist entries; no clinical workflow, privacy, environment or deployment behaviour changed, and the hosted state was proven directly (production dry-runs + push + live-drift green).
• UI verification not run: no UI, routing, styling or browser behaviour changed.

Risk and rollout

• Risk: low. The six migrations read the catalog and raise; they create, alter and drop nothing. They are already applied on production and staging with executed statements. A fresh replay (CI Migration replay, Supabase Preview, db reset, DR) now fails loudly if any of the fifteen versions' objects is missing or mis-shaped — which is the intended behaviour. The test-file change is a predicate refinement (strips string literals before the create-index check), not a class widening.
• Rollback: revert the commit (removes the six files and fifteen allowlist entries). The six applied history rows would then read as remote-only to migration list; if a rollback is ever needed, remove the rows explicitly in an authorised window rather than leaving history and repo disagreeing. No schema object changes to undo.
• Provider or production effects: explicitly authorised one-off production window on sjrfecxgysukkwxsowpy — supabase migration list, read-only guard dry-runs, supabase db push --skip-vault of exactly the six versions, migration list again, supabase unlink; staging ikoiolksxqxfxgiyqpnu by the Phase 2 method; one live-drift workflow dispatch on this branch. No vault access, no data writes, no migration repair.
• RAG impact: no retrieval behaviour change — validation-only guard migrations and allowlist entries; no RPC body, ranking, selection or index definition changed (the 110500 guard pins match_* bodies to the hashes live already carries).

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

• Phase 4's table said 20260712170500 carries "43 names"; it carries 44create index if not exists statements, of which 42 persist (the two document_table_facts_* left-prefix indexes are re-dropped by 20260712172000 and proven absent by the 110000 guard).
• The live-drift job will stay red on its Align migration history step until the owner decides how check:migration-history should read supabase_migrations (expose the schema read-only / wire SUPABASE_ACCESS_TOKEN#183 and use supabase migration list / add a versions RPC). Pinned issue Live drift check failing #1963 therefore does not self-close yet even though its drift block is empty.
• Ledger: #Q5JHBJ update and the new P2 are queued as inbox requests; run npm run issues:reconcile from a serialized fresh base after this lands.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[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:56 minutes

Limit details: You’ve used the included review currently available. Your 102 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?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

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: 4d374ff3-a8e4-4d7d-8bf3-3dd63825bbcb

📥 Commits

Reviewing files that changed from the base of the PR and between c0b4e84 and 341b64c.

📒 Files selected for processing (13)

• docs/audit/live-drift-forensics-2026-08.md
• docs/database-drift-detection.md
• docs/database-remediation-coordination.md
• docs/outstanding-issues-inbox/bbac85a9-de92-42c5-b9e2-3b1fa2a89a56.json
• docs/outstanding-issues-inbox/cc60253d-6efe-44ab-a615-8584ab0983b6.json
• supabase/drift-allowlist.json
• supabase/migrations/20260819110000_validate_history_dropped_objects.sql
• supabase/migrations/20260819110100_validate_history_comments_and_retention.sql
• supabase/migrations/20260819110200_validate_history_document_foreign_keys.sql
• supabase/migrations/20260819110300_validate_history_operational_index_shapes.sql
• supabase/migrations/20260819110400_validate_history_index_generation_promotion.sql
• supabase/migrations/20260819110500_validate_history_function_bodies.sql
• tests/migration-history-guards.test.ts

---

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

[supabase]

Updates to Preview Branch (claude/migration-history-drift-allowlist-37444c) ↗︎

Deployments	Status	Updated
Database	✅	Wed, 19 Aug 2026 12:40:18 UTC
Services	✅	Wed, 19 Aug 2026 12:40:18 UTC
APIs	✅	Wed, 19 Aug 2026 12:40:18 UTC

Tasks are run on every commit but only new migration files are pushed.
Close and reopen this PR if you want to apply changes from existing seed or migration files.

Tasks	Status	Updated
Configurations	✅	Wed, 19 Aug 2026 12:40:19 UTC
Migrations	✅	Wed, 19 Aug 2026 12:40:21 UTC
Seeding	✅	Wed, 19 Aug 2026 12:40:23 UTC
Edge Functions	✅	Wed, 19 Aug 2026 12:40:24 UTC

---

View logs for this Workflow Run ↗︎.
Learn more about Supabase for Git ↗︎.