bot reviewer: emit APPROVE when no blocking findings remain — comment verdicts wedge PRs behind stale request-changes

[bpamiri]

Symptom (hit twice on 2026-06-11, PRs #3043 and #3044)

The single Reviewer posts request changes, the author addresses everything, the Reviewer re-reviews the new head and posts a comment-state review explicitly confirming all blocking findings are resolved — but GitHub keeps the PR merge-blocked: a reviewer's CHANGES_REQUESTED stays active until the same reviewer submits an APPROVE or the review is dismissed. Comment-state reviews do not supersede it. Result: every request-changes round permanently wedges the PR pending a manual dismissal by a maintainer, even when the bot's own latest review says "resolved, non-blocking".

Fix

In .claude/commands/review-pr.md: when the verdict is "no correctness/security/cross-engine findings; nits only or nothing" AND a prior wheels-bot CHANGES_REQUESTED exists on an earlier SHA of the same PR, submit the review with event=APPROVE (nits go in the body) instead of COMMENT. Guard: never APPROVE when any blocking finding remains; the existing one-substantive-review-per-SHA contract and post-job marker guard are unaffected (an approval is still a review on the SHA).

Acceptance

• Sequence request-changes → fix push → re-review with zero blocking findings ends with the PR mergeable without human review-state surgery.
• A re-review that still has blocking findings continues to use request-changes.

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior with a clear what-happened / what-expected: a re-review that confirms all blocking findings are resolved is submitted as a COMMENT-state review, but the reviewer's earlier CHANGES_REQUESTED "stays active until the same reviewer submits an APPROVE or the review is dismissed," so the PR stays merge-blocked. Reproduced "twice on 2026-06-11, PRs #3043 and #3044."

Suspected layer

bot-tooling — this is outside the documented framework layers (model / controller / view / router / middleware / migrator / cli / di / job / mailer / sse / seed / config). The defect lives in the bot's own review automation, not in vendor/wheels/**. There is no .ai/wheels/<layer>/ doc for this; the relevant reference is .ai/wheels/wheels-bot.md.

Fix sketch

Single file: .claude/commands/review-pr.md. Per the issue, the verdict/output step (around the "overall verdict" / --approve / --comment guidance near lines 137–173) should be amended so that when the verdict is "no correctness/security/cross-engine findings; nits only or nothing" and a prior wheels-bot CHANGES_REQUESTED exists on an earlier SHA of the same PR, the review is submitted with event=APPROVE (nits in the body) instead of COMMENT. Hard guard: never APPROVE while any blocking finding remains; a re-review with blocking findings continues to use request-changes. The one-substantive-review-per-SHA contract and post-job marker guard are unaffected.

Confidence: low

The fix shape is clear and well-specified by the reporter, but it (a) modifies the review bot's own auto-approval behavior — a self-referential, sensitive change to when the bot will APPROVE a PR without a human — and (b) targets .claude/commands/, which maps to none of the documented framework layers and has no propose-fix layer doc; both reasons keep this manual for human review rather than auto-firing a fix PR.

<!-- wheels-bot:triage:3048 -->
<!-- wheels-bot:triage-class:bug -->