Enforce single terminal review decision per PR review run #211

New Issue

2026-07-05T15:31:48-05:00

jcwalker3 commented

2026-07-05 15:31:48 -05:00

Problem

Reviewer agents can submit conflicting review states on the same PR in a single review run, such as APPROVE followed by REQUEST_CHANGES. This creates confusing audit history and may trigger automation based on the earlier state.

Observed failure

The reviewer of PR #203 posted an APPROVE, then later posted REQUEST_CHANGES in the same run.

Required wall

A reviewer run may submit only one terminal review decision for a selected PR: APPROVE, REQUEST_CHANGES, or COMMENT. Once submitted, no second terminal review state may be posted in the same run unless the operator explicitly authorizes a correction.

Acceptance criteria

Add per-run review mutation state tracking.
Block second terminal review submissions in the same run by default.
Add a correction mode requiring explicit reason, prior review ID/state, and operator authorization.
Final handoff must include terminal review count and selected final state.

Origin incident: PR #203 review run (APPROVE followed by REQUEST_CHANGES in one run).
#179 — reviewer A-bar proofs in review_proofs.py; per-run terminal-decision tracking belongs in the same proof family (gitea_review_pr / gitea_submit_pr_review path and CLI review_pr.py).
#197 — hard-stop purity after capability denial (same one-run-one-outcome discipline, capability side).

### Problem Reviewer agents can submit conflicting review states on the same PR in a single review run, such as APPROVE followed by REQUEST_CHANGES. This creates confusing audit history and may trigger automation based on the earlier state. ### Observed failure The reviewer of PR #203 posted an APPROVE, then later posted REQUEST_CHANGES in the same run. ### Required wall A reviewer run may submit only one terminal review decision for a selected PR: APPROVE, REQUEST_CHANGES, or COMMENT. Once submitted, no second terminal review state may be posted in the same run unless the operator explicitly authorizes a correction. ### Acceptance criteria * Add per-run review mutation state tracking. * Block second terminal review submissions in the same run by default. * Add a correction mode requiring explicit reason, prior review ID/state, and operator authorization. * Final handoff must include terminal review count and selected final state. ### Related * Origin incident: PR #203 review run (APPROVE followed by REQUEST_CHANGES in one run). * #179 — reviewer A-bar proofs in `review_proofs.py`; per-run terminal-decision tracking belongs in the same proof family (`gitea_review_pr` / `gitea_submit_pr_review` path and CLI `review_pr.py`). * #197 — hard-stop purity after capability denial (same one-run-one-outcome discipline, capability side).

jcwalker3 added the status:in-progress label 2026-07-05 15:48:41 -05:00

jcwalker3 referenced this issue from a commit

2026-07-05 15:50:58 -05:00

Enforce single terminal review decision per PR review run (Issue #211)

jcwalker3 referenced a pull request that will close this issue

2026-07-05 15:51:08 -05:00

feat(reviewer-workflow): enforce single terminal review decision per PR review run #214

jcwalker3 referenced a pull request that will close this issue

2026-07-05 16:02:33 -05:00

feat(reviewer-workflow): enforce single terminal review decision per PR review run #214

sysadmin referenced this issue

2026-07-05 16:07:09 -05:00