feat(db): codify live SET work_mem on the ten match_* RPCs, the eight schema-only objects, and three chain-stale columns (#316)

[BigSimmo]

Summary

Database remediation Phase 3 (reframed, ledger #316): repo-side codification of already-live state so the migration chain, supabase/schema.sql and production agree. No canonical (schema.sql = production) function body changed; no hosted value changed; no production access. Staging received the migrations in an owner-authorised window (below). Owner decisions D1 (codify-as-live) and D2 (work_mem eval-canary exemption) are in force.

RAG impact: no retrieval behaviour change — codifying already-live SET work_mem attributes, mirror-only objects, and three already-live RPC bodies into the migration chain; no canonical function body changed

• SET work_mem on the ten match_* RPCs — schema.sql now carries set work_mem = '<live value>' on every definition (both the legacy and the effective block for match_document_chunks_hybrid and match_document_table_facts_text), and supabase/migrations/20260818110000_codify_live_rpc_work_mem.sql runs one ALTER FUNCTION … SET work_mem per function, versioned after every recreate (including the 20260724120000 recreate that dropped the setting on table_facts_text). Values are exactly the live ones from forensics §1.2: 128 MB on chunks_hybrid, embedding_fields_hybrid, index_units_hybrid, index_units_hybrid_v2; 64 MB on the other six. Proof: the regenerated supabase/drift-manifest.jsondef_hash for all ten equals the live production def_hash from issue Live drift check failing #1963 (Actions run 32051068106) byte-for-byte — e.g. match_document_chunks_hybrid5902c39286335c07714e498ea31513a0, match_document_table_facts_text0ef9a5dfbde03fe6d48d9223e245aa69 — so the next production live-drift run reports zero match_* mismatches once the migration is marked applied.
• Eight schema.sql-only objects codified — 20260818111000_codify_schema_only_indexes_and_triggers.sql creates, verbatim from schema.sql, the five document_embedding_fields_* indexes, documents_status_idx, and the documents_updated_at / ingestion_jobs_updated_at triggers (forensics §2.3 b). Disjoint from #102. All six indexes stay on supabase/search-health-unmonitored-indexes.json (reasons refreshed to cite the migration); search_schema_health()required_indexes is deliberately untouched — Phase 4.4 decides that by its own migration.
• Staging-finding triage (forensics §3.3) — document_chunks is CHAIN-stale (token_estimate integer not null default 0 exists in schema.sql, production and app code, in zero migrations); rag_visual_eval_cases / rag_visual_eval_runs are CHAIN-stale (20260705230000 sets search_path with pg_catalog last, so their id default bound to extensions.gen_random_uuid(); schema.sql and production bind the core function). Both fixed idempotently by 20260818112000_reconcile_chain_stale_table_columns.sql. document_chunks_content_trgm_idx: production's restored definition (coalesce(content, '') form, 8499c3d3…) is canonical = schema.sql = 20260705180000; staging carries the 20260606000000 bare-content form (c3db2960…) because later creators use if not exists — staging-only residual for Phase 4.4, no escalation. Nothing UNCLASSIFIED.
• Forward-codify three hybrid RPC bodies (found by the staging proof) — 20260818113000_forward_codify_hybrid_owner_matches_bodies.sql re-creates match_document_embedding_fields_hybrid, match_document_index_units_hybrid, match_document_memory_cards_hybrid_v2 verbatim from schema.sql. On a chain-built database these three still carry the legacy fail-open, sentinel-blind predicate (owner_filter is null or d.owner_id = owner_filter) because 20260712000000_forward_codify_retrieval_owner_matches.sql left the body codification to an owner step that never happened for them (five other RPCs were codified later). schema.sql == production for all three (manifest def_hash = live def_hash, forensics §3.1), so this is a reproducibility hole for migrations-only environments, not a production tenancy hole; the migration is a no-op on production. Every SET clause is restated so proconfig is preserved; ACLs untouched. Protected RAG surface: this migration contains RPC bodies — copied byte-for-byte from the canonical definitions, nothing edited.
• Evidence and ledger — forensics docs/audit/live-drift-forensics-2026-08.md §Phase 3 written (3.5 carries the staging evidence); #316 update (one combined request — the earlier one is cancelled in-inbox to avoid a same-id collision) and the #183 rider (Supabase CLI authenticated + repo linked to staging) queued as inbox requests (docs/outstanding-issues-inbox/), plus two P3 captures (check:drift column-diff clip; PR template lacks RAG impact: guidance), all reconciled later on a fresh-base branch.

Staging proof — RUN (forensics §3.5)

Gate opened when the Phase 2 re-measure (#2104) merged. Owner-authorised staging window on ikoiolksxqxfxgiyqpnu (ref verified via list_projects, project id passed literally on every call; production never targeted): 20260818110000 / 111000 / 112000 applied by the Phase 2 method (file verbatim + explicit history row, never apply_migration), md5-identical read-back for all three (dd5c8c9e…, 9d02d14e…, ea5f9c69…); staging 198 rows, no_statements 0, corpus 0. Offline reproduction of check:drift (same categoryKeys/comparedFields, per-object md5; 590/594 hash-equal):

UNEXPECTED DRIFT (4):
! [functions] mismatch public.match_document_embedding_fields_hybrid(...) -- body: legacy owner predicate on staging (chain-stale)
! [functions] mismatch public.match_document_index_units_hybrid(...) -- same
! [functions] mismatch public.match_document_memory_cards_hybrid_v2(...) -- same
! [indexes] mismatch document_chunks_content_trgm_idx -- expected residual (Phase 4.4)

The 8 never-created objects, the 3 column-set mismatches and 4 of the 7 work_mem mismatches are gone. The three remaining functions are the reason for 20260818113000; its staging apply is pending owner permission (the tool-permission classifier declined the hosted CREATE OR REPLACE of protected RPCs in-session), after which the trgm index should be the single residual.

Production window — NOT authorised in this PR (for the coordinator)

Live state already matches for everything here, so one window can mark all of these applied together, and only the first is a real change:

Migration	Effect on production
20260818090000_schema_drift_snapshot_history_probe	real change — schema_drift_snapshot() v2 (Phase 6.1)
20260818110000_codify_live_rpc_work_mem	no-op — the ten work_mem values already match
20260818111000_codify_schema_only_indexes_and_triggers	no-op — all eight objects already exist
20260818112000_reconcile_chain_stale_table_columns	no-op — column and both defaults already as declared
20260818113000_forward_codify_hybrid_owner_matches_bodies	no-op — identical to the live bodies (hash proof §3.1)

No canary (D2), no index build, no data change, no body that production does not already run.

Verification

• npm run verify:pr-local — 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, lint, typecheck; test reported Test Files 3 failed | 656 passed | 2 skipped (661) · Tests 3 failed | 7051 passed | 29 skipped (7083) in an 822 s run — the three are tests/session-start-hook.test.ts (known Windows-environmental) plus two host-load timeouts (tests/codex-cloud-setup.test.ts 120 s, tests/private-access-routes.test.ts 30 s) which pass in isolation: npx vitest run tests/codex-cloud-setup.test.ts tests/private-access-routes.test.ts tests/worker-observability.test.ts → Test Files 3 passed (3) · Tests 182 passed (182); the three not-reached stages were run directly: Offline RAG fixture and manifest validation passed (36 golden cases, 26 suites)., data/medication-interaction-index.json is up to date (525 rows)., docs/medication-interaction-lexicon-review.md is up to date (37 catalogue terms).
• npm run drift:manifest — Replay complete in 75s (container start included). Wrote supabase/drift-manifest.json; the ten def_hash values equal live (see Summary).
• npm run check:migration-role — Hosted migration-role guard passed: active hosted SQL/tooling uses postgres and immutable applied history is unchanged.
• npx vitest run tests/supabase-schema.test.ts tests/drift-detection.test.ts tests/migration-history-guards.test.ts tests/search-health-index-coverage.test.ts tests/retrieval-access-scope.test.ts tests/migration-history-placeholders.test.ts tests/hosted-migration-role-guard.test.ts tests/guard-push.test.ts — Test Files 8 passed (8) · Tests 149 passed (149)
• npm run check:production-readiness — run in this env-less worktree: FAIL (2) are the expected provider capability gaps (Missing server env config …, Missing OPENAI_API_KEY), not regressions; no provider was contacted.
• UI verification not run: no UI, routing, or styling change.
• eval:retrieval:quality not run: no retrieval, ranking, selection, chunking, or scoring behaviour changed (attribute-only; owner decision D2).

Risk and rollout

• Risk: low. Every statement is idempotent against production's current state; work_mem is planner memory (latency-only, result sets fixed by each RPC's ORDER BY … LIMIT). The schema.sql edits are 12 additive set work_mem lines; the manifest regeneration proves they reproduce live hashes exactly.
• Rollback: revert the PR (restores the previous schema.sql / manifest and removes the three migration files). If a migration were already applied to a hosted target, ALTER FUNCTION … RESET work_mem / drop index / drop trigger / alter column … drop default are the one-statement inverses; none is needed for production, whose state does not change.
• Provider or production effects: staging (ikoiolksxqxfxgiyqpnu) received 20260818110000 / 111000 / 112000 in an owner-authorised window; production untouched. Applying to production needs the coordinator's window (table above).

Clinical Governance Preflight

Complete this section when the change touches ingestion, answer generation, search/ranking, source rendering, document access, privacy, production env, or clinical output.

• 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

• Protected RAG surface flagged before editing (AGENTS.md "RAG ranking protection"): the ten match_* definitions changed only by the set work_mem attribute line; bodies, signatures, return shapes, volatility, search_path / plan_cache_mode clauses and ACLs are untouched, and the drift-hash equality with live is the proof.
• Follow-ups surfaced (not fixed here): scripts/check-drift.ts:192 clips columns diffs to 240 chars per side, so a wide-table column drift never names the column; .github/pull_request_template.md carries no RAG impact: guidance although pr-policy.mjs hard-blocks RAG-surface PRs without it.

[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 recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in:59 seconds

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: 57f468d6-62b9-4257-80c8-b766358934f8

📥 Commits

Reviewing files that changed from the base of the PR and between 7e91590 and 63c3e86.

📒 Files selected for processing (13)

• docs/audit/live-drift-forensics-2026-08.md
• docs/branch-review-records/094e8208cf8f6aac89158b14059d7ea3c97f584cd8555ccb73d251d72ed9845e.record.md
• docs/branch-review-records/e7988c8069a294eb5d39a6292bfe60f94f940fdc0c272877227a7de151077d5a.record.md
• docs/outstanding-issues-inbox/41576279-d570-436b-a80b-d23b555845af.json
• docs/outstanding-issues-inbox/4dbcdcce-3645-4e08-8813-e85ab1fe7bcc.json
• docs/outstanding-issues-inbox/565cf4ff-5aa6-456b-abfc-92c4765049e4.json
• docs/outstanding-issues-inbox/a42b6382-9e7c-4633-9180-c86d03ad0bf1.json
• supabase/drift-manifest.json
• supabase/migrations/20260818110000_codify_live_rpc_work_mem.sql
• supabase/migrations/20260818111000_codify_schema_only_indexes_and_triggers.sql
• supabase/migrations/20260818112000_reconcile_chain_stale_table_columns.sql
• supabase/schema.sql
• supabase/search-health-unmonitored-indexes.json

---

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

[supabase]

Updates to Preview Branch (claude/schema-work-mem-codify-6200f1) ↗︎

Deployments	Status	Updated
Database	✅	Tue, 18 Aug 2026 09:50:56 UTC
Services	✅	Tue, 18 Aug 2026 09:50:56 UTC
APIs	✅	Tue, 18 Aug 2026 09:50:56 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	✅	Tue, 18 Aug 2026 09:50:59 UTC
Migrations	✅	Tue, 18 Aug 2026 09:51:01 UTC
Seeding	✅	Tue, 18 Aug 2026 09:51:03 UTC
Edge Functions	✅	Tue, 18 Aug 2026 09:51:04 UTC

---

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