fix(settings): re-land orphaned auto-mode supabase soft-deny from #2195 - #2196
Conversation
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 the included review currently available. Your 84 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 |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
Uh oh!
There was an error while loading. Please reload this page.
…estion (#2201) * docs(ledger): record the PR #2198 migration-history alignment review Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(db): record the 2026-08-20 alignment window and reopen the D4 question 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> * docs(db): treat a merged migration PR as a production deploy until D4 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 --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Summary
main. The commit is cherry-picked unchanged (a1259e5e9→3151c1e4e), authorship preserved.Bash(supabase migration list:*) and other read-only supabase inspection subcommandsout ofautoMode.allowand intoautoMode.soft_deny, and adds the guard test that pins it there.Why this PR exists. PR #2195 had squash auto-merge armed. GitHub merged it the moment the required checks went green, at head
a96f5307. The Codex auto-resolve workflow pushed its P1 fix to the branch roughly five minutes later, ata1259e5e9— after the PR was already merged and closed. GitHub resolved the review thread, so the finding reads as fixed, butmainat2abbe006still carries the original rule inautoMode.allowand does not contain the guard test. Verified withgit merge-base --is-ancestor a1259e5e9 origin/main(false) and by reading.claude/settings.jsonatorigin/main.Why the finding is correct (verified independently rather than taken on the reviewer's word):
npx supabase migration list --linkedis the repository's own documented flow (README.md:64,docs/supabase-migration-reconciliation.md:14) and it reads the live linked project, whileAGENTS.md:512requires explicit confirmation for any Supabase interaction, "including indirect tooling". Allowing it in auto mode was a real, if narrow, hole: an autonomous read against the liveClinical KB Databaseproject with no prompt.Verification
npx vitest run tests/claude-code-settings.test.ts tests/session-start-hook.test.ts:autoMode.allow, the new test fails as it should:The working tree was restored to HEAD afterwards. A check that cannot fail is not a check.
npx prettier --check .claude/settings.json tests/claude-code-settings.test.ts→All matched files use Prettier code style!autoMode.allowcontains nosupabaserule;autoMode.soft_denycontains the inspection rule.Verification not run: the full
npm run verify:pr-local. The diff is one relocated configuration string plus a seven-line test, in the same file scope as #2195, whichclassifyPullRequestFilesreturns asclinicalRisk: false,operationalRisk: false,ragRanking: false,ui: false. The committed tests that parse this file are the smallest checks capable of detecting a regression here, and the new one is proven able to fail. CI'spr-requiredaggregate remains the backstop.Risk and rollout
supabase migration list --linked, which is the documented intent.git revertthis commit; behaviour returns to today'smain.Follow-up worth considering (not in this PR)
The auto-merge race that stranded this fix is not specific to it: any PR with auto-merge armed can have a late review-bot fix land after the merge, with the review thread still auto-resolved so nothing looks wrong.
docs/outstanding-issues.mdmay be the right home for that.🤖 Generated with Claude Code