External reviewers (Codex, CodeRabbit) post inline comments after every push, not just on initial PR open. Treating their comments as advisory means real bugs slip through. The loop below treats each unaddressed P1 / P2 as a failed test and re-enters the editor stage automatically.
The poll
After every git push, the Reviewer-feedback agent runs:
gh api repos/{org}/{repo}/pulls/{n}/comments
The response is a list of inline comments, each carrying:
body— the comment text (often categorised by Codex / CodeRabbit as P1 / P2 / P3).pathandline— where the finding applies.user.login— to filter to known reviewer bots.created_at— to sort by recency.
The agent classifies each comment by severity (regex on common reviewer formats — **P1**, 🚨, Critical, etc.) and persists them into the PR's status object.
Severity → action
| Severity | Action |
|---|---|
| P1 | Hard block. Re-enter Editor with the comment as input. Resolve before merging — never argue down. |
| P2 | Soft block. Re-enter Editor unless the agent has a justified counter-argument committed to the PR description. |
| P3 | Acknowledge in the PR description; do not block. |
| Style / nit | Acknowledge silently in the PR description; do not block. |
The agent argues down via a comment like:
Reviewer raised "X may regress under high concurrency". The relevant code path is single-threaded by request scope; concurrency cannot trigger this path. Not changing.
If the reviewer responds with a refinement, the loop continues.
Re-entering the editor
When a P1 / P2 lands and the agent decides to fix:
- The Reviewer-feedback agent appends the comment as an issue to a scratchpad on the worktree branch.
- It re-spawns the Editor with
inputs.review_findings = [...]plus the original spec. - The Editor's iteration loop now has two stop conditions: spec tests pass AND review findings addressed.
- After the new commit, the Verifier re-runs and the loop repeats.
Idempotence
The poll is idempotent — comments don't disappear, so re-runs see the same set. The agent tracks "comment id → status" in summary.json so:
- Comments already addressed in a previous iteration aren't re-actioned.
- Comments argued down don't trigger re-entry on every loop.
- Reviewer comebacks (a new comment on the same line) DO re-trigger because the comment id is new.
When to short-circuit
Two cases where the loop deliberately exits without addressing a comment:
- Stale comment — the file or line no longer exists after a refactor. The agent posts a "no longer applicable" reply and moves on.
- Out of scope — the comment refers to behaviour outside this PR's spec. The agent files a follow-up plan in
wiki/plans/and replies with a link.
Both require committing a justification to the PR description so reviewers can see the exit reasoning.
Why this is non-optional
Standing memory rules:
feedback_codex_review_loop.md(added 2026-04-25 after PR #325 landed carrying a Codex P1 missed during parallel auto-merges).feedback_no_auto_merge_until_full_ci_and_review.md(added 2026-04-28 after PR #367 merged with failing dashboard-coverage / dashboard-server-required jobs).
Both pre-date this section but are the same shape: external-reviewer bots can fail silently if you don't poll, and parallel merges can race past the "required check" gate if you don't wait for the aggregate green. The pipeline encodes both as gates the orchestrator cannot skip.
Cross-references
- PRD-to-PR pipeline — stage 7.
- Verification and evidence — the dossier the Verifier produces is independent of this loop.
- Agent roles and model routing — the Reviewer role.
- Merge flow & PR velocity — merge-queue gates this loop respects.