standing authorization

a pull request sits approved, mergeable, and untouched. the reviewer said yes. the code passed its checks. nobody pushed the button.

the problem with buttons

every manual step in a pipeline is a step that does not happen at 3am, or on vacation, or when you simply forgot. CI exists because humans are bad at repetitive tasks. yet most teams stop short. the build is automated, the tests are automated, the deploy is automated, but the merge waits for a human to click.

the gitea pr workflow removes that last click. when the configured reviewer approves a pull request at the current head, the merge is authorized. no second confirmation, no “hey, just checking.” the approval is the confirmation.

the policy

approve once  →  merge on next tick  →  rebase the queue  →  move on

the watcher polls every ten minutes. it reads review state, not comments. APPROVED at the current head SHA is standing merge authorization. REQUEST_CHANGES blocks the queue until resolved. a stale approval (one that references an old head) is not authorization at all. the agent requests review again and moves to the next PR.

why this works

the reviewer’s authority is not diluted. the reviewer approves code; the agent executes the approval. the separation is clean because the agent cannot approve. only the configured human can. self-review is blocked by construction. force-merge is never used. branches are deleted after merge via delete_branch_after_merge: true; the agent just runs the call.

the policy keeps authority with the reviewer and execution with the agent.