docs(db): record the 2026-08-20 alignment window and reopen the D4 question - #2201
Conversation
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…estion The PGRST106 fix (PR #2198, squash a341832) merged before its production window, so the window's pre-flight found 20260820120000 already applied and db push was never run. Verified read-only against sjrfecxgysukkwxsowpy: stmt_count 3 (executed statements, not mark-applied), prosecdef true, provolatile s, search_path="", proacl postgres=X/postgres | service_role=X/postgres, and the function returns probe ok with version_count 211 against 211 history rows and 211 local files. No guard migration is owed. Two open items are recorded rather than absorbed. D4 is unresolved again. created_by and idempotency_key are NULL on every row from 20260818090000 onward, including ones this programme applied by operator db push, so the history table carries no provenance signal. The 2026-08-19 observation recorded as "D4 is OFF" was that migrations sat pending WHILE a PR was open; that never tested deploy-on-merge, and so never contradicted section 3.7's 34-second application after #2106's squash-merge. Until the dashboard is re-checked, assume merging a migration PR deploys it to production. Staging is one version behind (210 rows, function absent, pending set exactly 20260820120000). Both write paths were denied by the session auto-mode classifier under the live-Supabase confirmation rule added by PR #2196, so Phase 4's staging parity is open by one version until an operator applies it. Also lands the owed PR #2198 review-ledger record, whose original push was cut short when the branch was deleted on merge. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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:47 minutes Limit details: You’ve used the included review currently available. Your 85 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 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:4c0fa08ded
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Uh oh!
There was an error while loading. Please reload this page.
… is re-verified The 2026-08-20 window update reopened D4 (Supabase GitHub auto-deploy), but the status board's active instructions still told a coordinator the opposite: the "Next dispatches" line, the D4 owner-decision entry, the 2026-08-19 "Resolved" paragraph, and the pre-window forensics section all said D4 is OFF and every migration needs its own explicit `db push`. A coordinator reading those could merge a migration PR outside its approved window — the unapproved production schema change the update exists to prevent. All four now point at the reopened decision: assume merging a migration PR deploys it to production until the dashboard toggle is re-verified. Push-before- merge stays the required order, for the inverted reason. Also lands the PR #2201 review-ledger record. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HoyoNN7nCUVDLaE84k6e6c
Uh oh!
There was an error while loading. Please reload this page.
Summary
Documentation-only. Records the 2026-08-20 production window for the migration-history alignment fix (PR #2198), and lands that PR's owed review-ledger record.
20260820120000already applied andsupabase db pushwas never run against production. Verified read-only againstsjrfecxgysukkwxsowpy: history rowstmt_count 3(executed statements, not mark-applied),prosecdef true,provolatile s,search_path="",proacl postgres=X/postgres | service_role=X/postgres, and the function returnsprobe: okwithversion_count 211against 211 history rows and 211 local migration files. No guard migration is owed.created_byandidempotency_keyare NULL on every row from20260818090000onward — including ones this programme applied by operatordb push— so the history table carries no provenance signal. The 2026-08-19 observation recorded as "D4 is OFF" was that migrations sat pending while a PR was open; that never tested deploy-on-merge, and so never contradicted §3.7's 34-second application after feat(db): codify live SET work_mem on the ten match_* RPCs, the eight schema-only objects, and three chain-stale columns (#316) #2106's squash-merge. Recorded as: re-verify the dashboard, and until then assume merging a migration PR deploys it to production.['20260820120000'], zero remote-only. Both write paths were denied by the session's auto-mode classifier under the live-Supabase confirmation rule added by PR fix(settings): re-land orphaned auto-mode supabase soft-deny from #2195 #2196, so Phase 4's staging parity is open by one version until an operator applies it. Recorded as blocked, not skipped.RAG impact: no retrieval behaviour change — documentation and a review-ledger record only; no code, migration, schema, or fixture is touched.
Verification
npx prettier --writeon both changed docs; the pre-push guard checked the pushed commit.supabase db querycalls against an explicitly passed--project-ref, made during the owner-authorised window and recorded indocs/audit/live-drift-forensics-2026-08.md.Clinical Governance Preflight
Clinical KB Database(sjrfecxgysukkwxsowpy)Notes
created_byis NULL, which is metadata about the history table.D:\Repos\Databaseremains linked to staging; the production link used here was made in a dedicated worktree and is removed at the end of the session.