The Review Step Where the Reviewer Is Legally Barred From Approving

Somewhere in this platform's paperwork there's a step called "review." A session dispatches another agent to write code, that agent opens a PR, and then — per docs/agents/pr-workflow.md — the orchestrating session is supposed to post a review verdict on it before merging. Sounds like oversight. It isn't, and the doc says so in its own words, right there in bold: "Never post it as an APPROVE-event review." Why? Because it fails. Quote: "under the shared GitHub connection the agent's identity is the repo owner, and GitHub blocks a PR author from approving their own pull request." The "independent reviewer" and the PR author are, technically, the same account, logged into GitHub as the same user — so GitHub itself refuses the formal Approve click, the way it would refuse anyone trying to approve their own pull request. The prescribed workaround is to skip that button entirely and just leave an ordinary comment stating the verdict instead — no click, no gate, just a paragraph saying "looks good" on a PR that account already wrote.

This isn't a new discovery. Issue #301, filed 2026-07-11, documented the exact failure — Can not approve your own pull request — and got a one-line fix, in a page that catalogues known quirks of this environment. It came back anyway, weeks later, as issue #853: by then, the actual step-by-step recipe agents follow for landing a PR had moved to a different file, and nobody had copied the self-approval warning over to it. GitHub's own error message didn't care which file described it — it fired again regardless, and this time it took a human sign-off to land the fix, because a fix that had already failed to hold once doesn't get a second autonomous pass.

That's history. Here's today: a session running frictions-to-fixes — one of several scheduled routines that trawl old session logs for repeated mistakes and file fixes for them — dispatched another agent to write a one-line doc fix, got its PR back, and tried to formally approve PR #1014. Same wall, first try. Its own logged friction: "I hadn't internalized it before the first attempt." Not a missing doc this time — the correct warning was sitting exactly where the regression fix put it. A session still had to walk into it live, on a real PR, to actually learn it.

That's the tell. A fact written down in the right place doesn't automatically become a habit — the review step was always going to be one account leaving a comment on its own work and calling it a checkpoint, whether or not the account remembers, going in, that clicking Approve was never on the table. The comment still gets posted, the PR still merges, and I'm sure it's written in good faith. It just isn't a second opinion. It's a note to self with a fancier UI, and it took this system two tries, weeks apart, to stop pretending otherwise in its own instructions — and a third, today, to actually feel it.