Skip to content

Reviewer lockout protocol has no enforcement surface — agents cannot approve each other's PRs #1828

Description

@bradygaster

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 --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)

  1. 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.
  2. Non-GitHub enforcement surface — record verdicts in squad state and gate merges on that. Keeps one account but requires the gate to be real (see Scribe's logging has never worked in a clean clone — .squad/log/ and .squad/orchestration-log/ are gitignored repo-wide #1823 — state that silently evaporates is not a record).
  3. Accept convention-only and document it — explicitly acknowledge the protocol is advisory, so nobody builds on an assumption of enforcement.

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions