You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Reviewer Rejection Protocol specifies that a rejected artifact locks out its original author and requires a different agent to revise. There is no enforcement surface for this on GitHub, because every agent commits and reviews under the same account.
gh pr review --approve is rejected outright:
Can not approve your own pull request.
Observed
Four for four today. PRs #1818, #1819, #1820, and #1821 were all reviewed by a designated reviewer agent (Flight) that could not register a GitHub approval. Each review was posted as a PR comment and merged on that basis.
Those reviews were substantive — one of them caught a query that had been non-functional since the day it was written (#1822) — so the problem is not review quality. The problem is that the approval is convention-only and leaves no machine-checkable record. Nothing distinguishes "reviewed and approved by a second agent" from "merged unreviewed" in the GitHub API.
Why this is worth deciding rather than patching
The lockout protocol currently depends entirely on the Coordinator honoring it. That works while a Coordinator is in the loop and fails silently otherwise — the same failure class as everything else found this session: a control whose success and non-execution are indistinguishable from the outside.
Options (decision needed, not an implementation task yet)
Distinct reviewer identity — a separate account or GitHub App for reviewer agents, making native approvals work and required_approving_review_count enforceable. Highest fidelity, highest setup cost.
Problem
The Reviewer Rejection Protocol specifies that a rejected artifact locks out its original author and requires a different agent to revise. There is no enforcement surface for this on GitHub, because every agent commits and reviews under the same account.
gh pr review --approveis rejected outright:Observed
Four for four today. PRs #1818, #1819, #1820, and #1821 were all reviewed by a designated reviewer agent (Flight) that could not register a GitHub approval. Each review was posted as a PR comment and merged on that basis.
Those reviews were substantive — one of them caught a query that had been non-functional since the day it was written (#1822) — so the problem is not review quality. The problem is that the approval is convention-only and leaves no machine-checkable record. Nothing distinguishes "reviewed and approved by a second agent" from "merged unreviewed" in the GitHub API.
Why this is worth deciding rather than patching
The lockout protocol currently depends entirely on the Coordinator honoring it. That works while a Coordinator is in the loop and fails silently otherwise — the same failure class as everything else found this session: a control whose success and non-execution are indistinguishable from the outside.
Options (decision needed, not an implementation task yet)
required_approving_review_countenforceable. Highest fidelity, highest setup cost.Option 3 is legitimate. What is not legitimate is leaving it ambiguous, because the protocol currently reads as enforceable.
Related
If option 2 is chosen, it depends on #1823 being resolved first — a verdict written to an ignored path is not an audit trail.
Owners
Flight / Coordinator decision.