docs(db): re-measure staging drift at current main after the snapshot v2 migration (#056)

[BigSimmo]

Summary

Documentation and evidence only. Re-measures check:drift against the staging Supabase tier now that main carries the migration that redefines schema_drift_snapshot() itself, and records the result as a dated subsection of the Phase 2 forensics.

• docs/audit/live-drift-forensics-2026-08.md § 2.5 — "Re-measure against current main". Phase 2 (Replay the migration chain onto staging to parity, and record that the chain does not reproduce schema.sql (Phase 2, #056) #2093) measured 19 drift findings at base ed43a64f2. Since then exactly one commit touched supabase/: 9c660af1f (PR feat(db): migration-history probe, guard-migration contract, and index-monitoring ratchet (remediation Phase 6) #2058, Phase 6), which added 20260818090000_schema_drift_snapshot_history_probe.sql plus a regenerated schema.sql, a regenerated drift-manifest.json, and five migration_history allowlist entries. Those 19 were therefore measured with a snapshot v1 probe against an older manifest, which is why the number needed re-taking rather than re-quoting.
• docs/outstanding-issues-inbox/5ed2f873-….json — the queued #056 update carrying the re-measured count. It is an immutable inbox request; docs/outstanding-issues.md is untouched and one serialized npm run issues:reconcile will apply it after this lands.

What was done in the staging window

Owner-authorized staging window, target Clinical KB Staging (ikoiolksxqxfxgiyqpnu), via the Supabase MCP connector. Production sjrfecxgysukkwxsowpy was never a target: the ref was passed explicitly on every call and list_projects was the only call that named production at all. Measurement only — no drift finding was fixed, and no vault secret was seeded into staging.

1. Before-gap: exactly one version. Staging held 194 rows in supabase_migrations.schema_migrations against 195 repository migration files; the two-way diff named 20260818090000 and nothing else. It is not one of the duplicate earlier/later pairs of § 2.4 finding 2 — all eight of those remain present from the Phase 2 replay — so the stop-and-report condition for applying an older body over a newer one did not arise.
2. Applied by the Phase 2 method.execute_sql ran the repository file's content verbatim, then a second execute_sql wrote an explicit history row carrying the repository's own version and name. apply_migration was not used: it stamps a connector-generated version, which docs/staging-setup.md forbids. Read back byte-identical — md5 839bed0b741cb75b79f6eb0c46ed0a50, 9034 bytes, matching md5sum of the file. Staging now holds 195 rows, latest 20260818090000, zero statements IS NULL, an empty two-way diff, and documents/document_chunks still 0.
3. check:drift against staging, current manifest. Exit code 1, complete output pasted into § 2.5.

Result: still 19, and the composition is unchanged

All 19 findings persist with the same categories, keys, and manifest/live hash pairs, even though the manifest moved underneath them (2026-08-17T16:38:39.818Z / a6fb923400f8… against § 2.3's 2026-08-16T14:37:41.042Z / 365e3368a47b…): 7 match_*SET work_memdef_hash mismatches, 8 objects only schema.sql declares, 3 table column-set mismatches, 1 document_chunks_content_trgm_idx definition mismatch. Nothing new appeared and nothing changed category. Staging still carries work_mem on 7 match_* functions rather than 8, re-confirming § 2.4 finding 3 on the current chain.

Two observations are new to this run, and neither is a drift finding:

• The snapshot v2 migration_history block is live and clean. The probe reports ok and returns zero rows, so the new category contributes 0 findings — the expected result for an environment built by a faithful chain replay. It is evidence the probe runs end-to-end against a real database, not evidence that production is clean; production has not been measured with v2.
• Five migration_history allowlist entries report stale.20260701010000, 20260701020000, 20260701030000, 20260701060000 and 20260702000000 (all guard.class superseded, added by PR feat(db): migration-history probe, guard-migration contract, and index-monitoring ratchet (remediation Phase 6) #2058) match nothing on staging because those history-repair rows are production's. This is a warning, not a failure — the run still exits 1 solely on the 19 — and § 2.5 records that check:drift --prune-stale must not be run against staging, because it would delete allowlist entries that exist for production.

One positive confirmation: schema_drift_snapshot itself does not appear among the function mismatches. Before this window it could not — staging carried v1 while the manifest carried v2 — so its absence is direct evidence that PR #2058's migration body and the schema.sql mirror regenerated from it agree.

The § 2.3 conclusion is unchanged and is repeated in § 2.5: check:drift builds its expected side from supabase/schema.sql rather than from the migration chain, and a complete, byte-verified chain still disagrees with it in 19 places. Every disposition remains repo-side work for Phase 3.

Testing

npm run verify:pr-local -- --files docs/audit/live-drift-forensics-2026-08.md,docs/outstanding-issues-inbox/5ed2f873-e23b-4504-ad7b-8afb0ae39889.json selected the recognised low-risk documentation route and completed all eleven checks:

PR-local verification summary:
- completed: check:runtime, check:installed-lock-parity, format:changed, sitemap:check, docs:check-index, docs:check-inventory, docs:check-scripts, docs:check-links, check:branch-review-ledger, check:outstanding-issues, check:ledger-write-discipline
- failed: (none)
- not reached: (none)

Decisive lines from the ledger guards, which are the gates that matter for an inbox request:

Ledger inbox check passed: 2 pending request(s), 251 applied.
Outstanding-issues guard passed: 361 rows (105 open, 256 archived), unique display and durable ids, collision-free allocation enabled, deprecated next-id marker ignored, no merge driver, no ids deleted from base 4551b6e4d80d.
Ledger write discipline passed for 4551b6e4d80d..HEAD.

npm run docs:check-links — docs link check passed: 1881 repo path references resolve.npm run format was run repo-wide and committed; prettier --check on both changed files reports All matched files use Prettier code style!.

Lint, typecheck, the unit suite, RAG fixture scan, build, and browser gates were not run: the changed paths are documentation and an immutable ledger request, which verify:pr-local classifies as recognised low-risk scope with no build-affecting or executable product changes. classifyPullRequestFiles returns clinicalRisk: false, operationalRisk: false, ragRanking: false for both paths.

No provider-backed gate was run. The only hosted access was the authorized staging window described above.

[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.

[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 ↗︎.

[coderabbitai]

Warning

Review limit reached

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

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in:9 minutes

Limit details: You’ve used all 1 included review currently available under your plan. You completed 101 included PR reviews in the past 7 days; at that activity level, included reviews refill 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 for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 5601574f-058b-46cc-9d1a-a1039adb0cd7

📥 Commits

Reviewing files that changed from the base of the PR and between e1749bf and fec42f0.

📒 Files selected for processing (3)

• docs/audit/live-drift-forensics-2026-08.md
• docs/branch-review-records/627ade3c681407cb483184c4fed41fa07bb1dd9f0333ad1b31c2aedd7950a251.record.md
• docs/outstanding-issues-inbox/5ed2f873-e23b-4504-ad7b-8afb0ae39889.json

---

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