ci(release): approve green, reviewed develop-into-next syncs as supabase-oss

[avallete]

Summary

Claude-resolved sync/develop-into-next PRs now get approved without a maintainer when the merge is clean in practice:

• every check except Require fast-forward is green on the head,
• the AI review posted a review on that exact head,
• Claude fixed or declined every finding (declining the ones the merge did not introduce),
• no .github/ workflow suggestions are waiting.

sync-repair plans an approve action in that state, and a new approve job submits an approval for that commit as supabase-oss through the auto-approve environment. The approval runs fast-forward.yml as usual, which re-checks the approver, the head and the checks before moving next.

A head moved past the reviewed commit, by a repair commit or a maintainer push, is never re-reviewed, so it still waits for a person. The job skips if the head moved or supabase-oss already approved that commit.

This reverses the documented rule that the bot never approves sync heads; release-process.md records the new accepted decision. Reviewers should confirm the auto-approve environment's branch rule lets sync-repair runs on develop deploy.

Linked issue

• I'm a Supabase maintainer.

Checklist

• The PR title follows Conventional Commits.
• Tests added or updated for the change.

🤖 Generated with Claude Code

[Coly010]

a few gaps in what counts as "reviewed and answered" that i think need closing before the bot moves next on its own - inline below.

one that isn't in the diff: if either model job fails or times out, adjudicate swaps in empty findings and post-review still posts the marker (ai-review.yml:427-438), so a half review (or one model skimming a huge next...sync diff) counts as reviewed. could the auto-approve path require both models to have completed?

on your env question - auto-approve only allows develop, so the workflow_run/schedule runs deploy fine. rest looks good to me, and with those four sorted i'm happy to approve!

[avallete]

/ai-review

[avallete]

/ai-review

[github-actions]

🤖 AI Review

Verified all six findings from both independent reviews; none overlap. Five are confirmed, and the force-push posting failure remains uncertain because its GitHub API trigger is not established by the repository code. The main issue is an approval race that can bypass a maintainer's change request. Other confirmed concerns are workflow compatibility, missing automatic promotion retries, external reviewers blocking automation, and contradictory release documentation.

Findings

Severity	Location	Category	Sources	Claim
🟠 MAJOR	.github/workflows/sync-repair.yml:170	race-condition	codex	The approval job can approve and promote a sync after a maintainer requests changes because it does not refresh the review eligibility decision.
🟡 MINOR	.github/scripts/ai-review/post-review.ts:1176	compatibility	claude	Older pull_request workflow copies fail to post reviews after develop receives this script because they do not provide the newly required HEAD_SHA and REVIEWS_COMPLETE variables.
🟡 MINOR	.github/scripts/ai-review/post-review.ts:797	error-handling	claude	Pinning commit_id can lose a completed review when GitHub rejects a reviewed commit removed by a force-push, because the 422 fallback retains the rejected SHA.
🟡 MINOR	.github/workflows/sync-repair.yml:176	error-handling	codex	An existing bot approval permanently suppresses automatic promotion retries for that head even when the original promotion failed or was refused.
🟡 MINOR	.github/scripts/sync-agent.ts:630	robustness	claude	A change-request review from an account without write access can indefinitely stop automatic approval of a sync PR.
🟡 MINOR	apps/cli/docs/release-process.md:363	documentation	codex	The release runbook retains a maintainer-approval guarantee for edits that the new automation can land without a person reviewing them.

Stats

Claude findings: 3 · Codex findings: 3 · Confirmed: 5 · Refuted: 0 · Uncertain: 1

---

Models: claude-opus-5-5 + gpt-6.1-sol · Trigger: manual · Workflow run

This review runs once per PR. A maintainer can request another with a /ai-review comment.

[jgoux]

The maintainer hold on automatic approval can be bypassed (P1), and there are two paths where supabase-oss approves despite findings that were never addressed (P2). Details inline.

[jgoux]

Thanks for the fixes. All four earlier points hold up at this head: change requests count regardless of author_association, the marker leads the body and superseded reviews are skipped, suggestions are posted before replies, and the approver comes from the event payload. One minor test-coverage note inline.

Fixed!