From 07be55f4312a36884a2210306c23613a50756ec6 Mon Sep 17 00:00:00 2001 From: vklimontovich Date: Fri, 8 May 2026 13:23:12 -0400 Subject: [PATCH] feat(ai-review): state-aware PR verdict, explicit APPROVE/REQUEST_CHANGES MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Previously the prompt told Codex to "post a concise positive review" when clean, without specifying the GitHub review event. Codex defaulted to event=COMMENT, which doesn't satisfy branch protection's "needs an approval" gate — so even clean re-reviews never unblocked merge. Two changes to the PR-mode section of the prompt: 1. Before deciding, the bot now fetches the PR's existing review threads and treats resolved ones as previously-handled. It won't re-raise a finding the maintainer already chose to close. 2. Explicit event mapping: - event=APPROVE when no actionable issues remain - event=REQUEST_CHANGES only for new unaddressed issues - event=COMMENT for informational-only reviews End result: first run finds an issue → REQUEST_CHANGES. Author fixes and resolves the thread. Push triggers re-review → bot sees thread resolved + no new issues → APPROVE → branch protection cleared. --- .github/workflows/ai-review.yml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/.github/workflows/ai-review.yml b/.github/workflows/ai-review.yml index 5731c12..5b5aed2 100644 --- a/.github/workflows/ai-review.yml +++ b/.github/workflows/ai-review.yml @@ -221,9 +221,12 @@ jobs: 6. Never call this review "WIP", "draft", or "preliminary". If `review_mode` is `pr`: - 1. Post a PR review directly to GitHub (do not delegate posting to workflow wrapper logic). - 2. Include summary and inline comments when appropriate. - 3. If there are no meaningful issues, post a concise positive review. + 1. Before deciding the verdict, fetch the PR's existing review threads via the GitHub API and inspect each thread's `isResolved` state and comments. Treat resolved threads as previously-handled: do not re-raise the same finding even if the underlying code still looks the same to you — the author has already given a reason and the maintainer chose to close it. + 2. Choose the GitHub review event explicitly: + - Use `event=APPROVE` when no actionable issues remain — i.e. there are no unresolved review threads with valid concerns, AND the diff at HEAD has no new actionable issues. This is what unblocks branch protection on a clean re-review. + - Use `event=REQUEST_CHANGES` only when there is a *new* actionable issue the author has not addressed. + - Use `event=COMMENT` only for informational reviews that should not gate the merge. + 3. Post the PR review directly to GitHub (do not delegate posting to workflow wrapper logic). Include a summary and inline comments when appropriate. If `review_mode` is `commit`: 1. Write `.github/codex/output/review.md`.