A pull-request reviewer's verdict is validated on agent agent finish and then discarded. main.py persists reviewer_verdict for the inner reviewer role, but for pr-reviewer-quality and pr-reviewer-logic it only checks that the value is approved or rejected and writes status, finished_at and note to the agent row.
agent gate record then validates the agent's task_id, status, vendor and role, and never compares its own --verdict against the one the reviewer finished with. The two commands are the documented two-step verdict flow, but nothing binds them together.
So an agent finished as rejected can back an approved gate, and an agent finished as approved can back a rejected one. Neither is refused.
This predates the findings-comment change in #32 — the relevant lines are unchanged on develop. It is filed rather than fixed there because binding the two commands changes what agent agent finish persists and what agent gate record accepts, which affects every instance and every workflow, not only the review path.
Worth noting that #32 raises the cost of the mismatch: a rejected gate now queues a public comment on the pull request, so recording the wrong verdict publishes findings under a verdict the reviewer did not give.
Found by a Codex logic lens during the review rounds of #32. Reported as PLAUSIBLE there — the lens could not run a probe in its sandbox — then confirmed by reading cmd_agent's finish path and cmd_gate on develop.
A pull-request reviewer's verdict is validated on
agent agent finishand then discarded.main.pypersistsreviewer_verdictfor the innerreviewerrole, but forpr-reviewer-qualityandpr-reviewer-logicit only checks that the value isapprovedorrejectedand writesstatus,finished_atandnoteto the agent row.agent gate recordthen validates the agent'stask_id,status,vendorandrole, and never compares its own--verdictagainst the one the reviewer finished with. The two commands are the documented two-step verdict flow, but nothing binds them together.So an agent finished as
rejectedcan back anapprovedgate, and an agent finished asapprovedcan back arejectedone. Neither is refused.This predates the findings-comment change in #32 — the relevant lines are unchanged on
develop. It is filed rather than fixed there because binding the two commands changes whatagent agent finishpersists and whatagent gate recordaccepts, which affects every instance and every workflow, not only the review path.Worth noting that #32 raises the cost of the mismatch: a
rejectedgate now queues a public comment on the pull request, so recording the wrong verdict publishes findings under a verdict the reviewer did not give.Found by a Codex logic lens during the review rounds of #32. Reported as PLAUSIBLE there — the lens could not run a probe in its sandbox — then confirmed by reading
cmd_agent's finish path andcmd_gateondevelop.