docs(db): Phase 1.2 RPC divergence dossier — all ten match_* mismatches classified (#316) - #2087
Conversation
…es classified (#316) Read-only Supabase connector session against sjrfecxgysukkwxsowpy (ref verified first; four SELECT statements, zero writes). Every one of the ten def_hash mismatches is an attribute-only difference: live pg_get_functiondef carries a SET work_mem clause that supabase/schema.sql (the manifest source) omits, and stripping that single line reproduces the manifest hash byte-for-byte for 10/10 under the exact 20260706200000 normalization. Zero body divergences, zero repo-ahead, zero UNCLASSIFIED. Four are mirror-stale (live = migration 20260724000000, schema.sql lacks the clause); six are live-ahead attribute-only (128MB on four, live-only work_mem on the two _v2s and on table_facts_text after its 20260724120000 recreate). Owner decisions (128MB vs 64MB, canary exemption) are flagged, not asserted. Queues one #316 inbox update. No RPC, migration or RAG code changed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:6 minutes Limit details: You’ve used all 1 included review currently available under your plan. You completed 100 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 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
Comment |
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…SET-attribute hash trap Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Docs-only PR completing Phase 1.2 of the database remediation programme by recording and classifying the remaining ten match_* RPC def_hash mismatches as attribute-only (SET work_mem present in live pg_get_functiondef, absent from supabase/schema.sql), plus queuing a single #316 outstanding-issues inbox update.
Changes:
- Adds a detailed Phase 1.2 completion dossier section to
docs/audit/live-drift-forensics-2026-08.mdwith method, queries, and per-function classification. - Updates
docs/database-remediation-playbook.mdto correct a prior trap-list statement and to note that functionSETattributes affect drift hashing. - Queues a
#316outstanding-issues inbox update request and appends the corresponding immutable branch review record.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| docs/audit/live-drift-forensics-2026-08.md | Adds the Phase 1.2 completion block with evidence, normalization rule, and per-function classification summary. |
| docs/database-remediation-playbook.md | Corrects the migration trap-list note and documents that SET attributes are included in the drift hash. |
| docs/outstanding-issues-inbox/1591ee4a-ce24-4091-93ba-ac4e7819fb60.json | Queues an #316 “update” request capturing Phase 1.2 completion details and next steps. |
| docs/branch-review-records/0363fe6d8b7a12cc846d0bb62401f25b543e33bee5210cfc9708ac8c0ba8b348.record.md | Adds the immutable review record for this docs-only PR’s scope and verification summary. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…nchor Two stale pointers in the playbook's context briefing, both of which misdirect a fresh session before it reads anything else. The phase status block still said Phase 1.2 was outstanding and gating Phase 3, and named "complete 1.2, then Phase 2" as the next step. Both have since landed: 1.2 in PR #2087 (all ten mismatches attribute-only SET work_mem, zero body divergence, zero repo-ahead, zero UNCLASSIFIED) and Phase 2 in PR #2093 (staging at full parity, check:drift against staging red with 19 items — the finding the phase existed to produce, with a re-measure owed once staging carries 20260818090000). Phase 6 is repo-side complete with its migration deploy still owed. The block now records that and defers to docs/database-remediation-coordination.md as the live board rather than becoming a second source of truth beside it. It also flags that Phase 3 has been reframed: zero repo-ahead bodies means no eval canary, which the Phase 3 prompt further down this file still assumes. That prompt and the traps list are deliberately left untouched here — the reframing and its owner decisions belong to the coordination board, and duplicating them would recreate the drift this change is repairing. The tracking anchor quoted the row title "Live DB is missing 21 repo-defined indexes and 10 retrieval RPC bodies diverge". The row has since been retitled to "Live DB has 20 currently missing repo-defined indexes and 10 retrieval RPC bodies diverge; weekly live-drift has been red since 2026-07-26 with no routing", so the exact-title lookup the playbook instructs could no longer match. The "21" was preserved deliberately in #1979 because it was the lookup key; correcting the row is what broke it. Anchor updated to the current title, verified character for character against the row on main. No issues:update queued: #316 and #56 are owned by other running chats, and a second pending mutation on either row would make the inbox refuse the batch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BKNFogaYfCQBvFVqFQnfRt
Summary
docs/database-remediation-plan.md, ledger#316): the RPC divergence dossier is complete. In an owner-authorized read-only Supabase connector window againstClinical KB Database(sjrfecxgysukkwxsowpy, ref verified before the first query; fourSELECTstatements; zero writes), the ten outstandingmatch_*def_hashmismatches were fetched withpg_get_functiondef, re-hashed with the exact20260706200000normalization rule, and diffed against the repo's canonical bodies.SET work_mem TO '…'clause thatsupabase/schema.sql(the manifest source) omits; stripping exactly that one line reproduces the manifest hash byte-for-byte for 10/10. Zero body divergences, zero repo-ahead, zero UNCLASSIFIED. Four are mirror-stale (live equals migration20260724000000; onlyschema.sqllacks the clause), six are live-ahead attribute-only (128MBon four functions, live-onlywork_memon both_v2s and onmatch_document_table_facts_textafter its20260724120000recreate). Owner decisions — keep 128MB or standardise to 64MB, and whether a planner-memory attribute is exempt from the repo-ahead eval-canary rule — are flagged in the dossier, not asserted.docs/audit/live-drift-forensics-2026-08.md§1.2, and one#316inbox update request is queued (docs/outstanding-issues-inbox/1591ee4a-….json). No other ledger row is touched.schema.sql,drift-manifest.json, orsrc/lib/rag/**file was changed, so this is a docs-only PR and noRAG impact:line is required. Nothing was fixed in this phase, per the plan's stop rules.Verification
npm run verify:pr-local -- --files docs/audit/live-drift-forensics-2026-08.md,docs/outstanding-issues-inbox/1591ee4a-ce24-4091-93ba-ac4e7819fb60.json— recognised low-risk docs scope; decisive lines:docs link check passed: 1826 repo path references resolve.,Outstanding-issues guard passed: 348 rows (97 open, 251 archived) …,Ledger inbox check passed: 2 pending request(s), 217 applied.,Ledger write discipline passed for ed43a64f206e..HEAD.,- failed: (none),- not reached: (none).npm run docs:check-linksandnpm run check:outstanding-issuesrun standalone before commit (same passing lines).npm run formatrun and committed before push.Risk and rollout
sjrfecxgysukkwxsowpy(explicitly authorized for Phase 1.2 in the task message); no other provider touched.Notes
20260724120000_table_facts_plpgsql_execute.sqldoes contain acreate or replace function(line 9), contrary to the playbook's trap list — a one-line docs follow-up for the coordinator.docs/database-remediation-coordination.md, PR docs(db): land and re-baseline the remediation coordination board (#316) #2044) is the coordinator chat's to make.#056, Phase 6 design) were not touched.🤖 Generated with Claude Code