docs(db): settle D4 with direct evidence — production is still bound to git main - #2205
Conversation
…to git main The Codex P1 on PR #2201 flagged the coordination board carrying two opposite D4 instructions at once; the auto-resolve task corrected most of them after merge. This finishes the job with the evidence that removes the ambiguity entirely, rather than leaving a "treat as ON, re-verify the dashboard" caveat that the next coordinator has to act on under uncertainty. list_branches(sjrfecxgysukkwxsowpy) returns one record binding PRODUCTION to git main, created 2026-06-27 with updated_at 2026-07-04. Because updated_at predates 2026-08-19, whatever was changed that day never touched this binding, so the section 3.7 mechanism - migrations applied 34 seconds after a squash-merge - is intact. D4 is ON. Merging a migration PR deploys it to production, deploy-then-merge ordering is unenforceable, and merge approval is the operative control. Three remaining stale or now-answered spots are corrected: the KEY FINDING heading still read "auto-deploy disabled"; the window update still read "D4 is UNRESOLVED again"; and owner item (1) still asked for a dashboard re-check that this evidence makes unnecessary. The forensics section heading and its "treat as UNRESOLVED" paragraph are replaced with the branch record. Deliberately additive: the corrections already on main from the auto-resolve task are preserved untouched, including the safe-either-way build-pattern note. 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:41 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 (2)
Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:655a432e9e
ℹ️ 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.
Uh oh!
There was an error while loading. Please reload this page.
…at holds either way Addresses both Codex findings on PR #2205. P1: the branch record proves production is BOUND to git main; no field of it reports the "Deploy to production" setting, and the superseded 2026-08-19 account describes that setting changing without the binding being deleted. So "toggle off, binding intact" cannot be ruled out from here, and the previous wording presented an inference as a direct read. The failure modes are not symmetric: declaring D4 ON tells operators to skip db push, and if the toggle is actually off every merged migration then sits unapplied and drift returns silently - the original incident. Declaring it OFF risks only a redundant no-op push. The evidence is still recorded and still strong (branch record with updated_at 2026-07-04, section 3.7's 34-second apply, 20260820120000 arriving unpushed), but it now carries its limit, and the operative instruction is the rule that is correct under both states: never merge a migration PR outside its approved window, and after any migration merges run supabase migration list and db push anything still pending. One extra command, wrong under neither hypothesis. What would replace the rule with a fact is a dashboard read of the toggle or a deployment-settings API. P2: the board said "no dashboard re-check is needed" while the active Next dispatches paragraph still required a per-migration db push and a toggle re-verification - mutually exclusive procedures depending on which paragraph a coordinator read. All active D4 sections now carry one state and one order; the KEY FINDING heading and the window update no longer assert ON. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Uh oh!
There was an error while loading. Please reload this page.
Summary
Finishes the Codex P1 raised on #2201 (the coordination board carrying two opposite D4 instructions at once). The auto-resolve task corrected most of them after that PR merged; this adds the evidence that removes the ambiguity entirely, instead of leaving a "treat as ON, re-verify the dashboard" caveat the next coordinator has to act on under uncertainty.
list_branches(sjrfecxgysukkwxsowpy)returns exactly one record, and it binds production to gitmain:{"name":"main","is_default":true,"git_branch":"main","project_ref":"sjrfecxgysukkwxsowpy", "created_at":"2026-06-27T14:10:20.550361+00:00","updated_at":"2026-07-04T08:15:07.640507+00:00"}updated_atpredates 2026-08-19, so whatever was changed that day never touched this binding — §3.7's mechanism (migrations applied 34 seconds after a squash-merge) is intact. D4 is ON. Merging a migration PR deploys it to production; deploy-then-merge ordering is unenforceable; merge approval is the operative control.Three spots are corrected:
KEY FINDINGheading still read "D4 DECIDED (auto-deploy disabled)".Plus the forensics section heading and its "treat D4 as UNRESOLVED" paragraph, replaced with the branch record.
Deliberately additive. The corrections already on
mainfrom the auto-resolve task are preserved untouched, including the safe-either-way build-pattern note. An earlier attempt to apply my whole file version would have deleted them; that was backed out and redone as targeted edits.RAG impact: no retrieval behaviour change — documentation only; no code, migration, schema, or fixture is touched.
Verification
npx prettier --checkon both changed docs: "All matched files use Prettier code style!"list_branchescall against an explicitly named project ref during the owner-authorised window, and is recorded indocs/audit/live-drift-forensics-2026-08.md.Clinical Governance Preflight
Clinical KB Database(sjrfecxgysukkwxsowpy)Notes