Observed behaviour
A blocking review posted by the board steward can be invisible to the worker's rework guard, so the worker re-affirms the PR and returns it to In review without doing any work. One full dispatch is spent producing nothing.
Reproduction, as it happened on 2026-09-05
| time (UTC) |
event |
| 13:54:00 |
steward posts a blocking review on PR #899 — a top-level COMMENTED review, body only, zero inline threads, authored by moncher-dev |
| ~13:55 |
operator sets #872 In review → Ready |
| 13:55:31 |
worker opens cycle 2: "PR #899 returned to Ready without actionable review feedback; re-validation and handoff restoration are starting" |
| 13:57:34 |
worker closes cycle 2: "PR #899 remains ready; the unchanged published head satisfies the Completion Bar" — In progress → In review, no commit, head still 7d485848 |
The run consumed 529,524 tokens and changed nothing. The review it should have acted on was 90 seconds old at dispatch.
Why the guard missed it
WORKFLOW.md Step 0 item 4 opens a rework cycle when a linked PR has CHANGES_REQUESTED, unresolved actionable review threads, a human instruction indicating rework, or a Land-return rework marker.
The steward's review satisfies none of those:
- its state is
COMMENTED, not CHANGES_REQUESTED — the steward is not a repository reviewer and posts findings as comments;
reviewThreads on that PR is empty, because the findings were written in the review body rather than anchored to lines. Verified: reviewThreads(first: 20) returns zero nodes;- the author is
moncher-dev, which is the worker's own account, so it does not read as a human instruction.
So the worker's conclusion was correct under the rules as written. The rules are what is wrong.
Why this is worth fixing rather than working around
The steward reviews every PR on this board, and its findings are the main source of rework instruction — it caught a real credential leak on #885 and a test that could not fail on #899. If the delivery channel is invisible half the time, the board silently loses those. The operator worked around it this once by reposting the review body as an issue comment, which Step 0 item 3 does read, but that is a manual step that will be forgotten.
The cost is a full dispatch per occurrence, and it is silent: nothing errors, the run reports success, and the issue lands back in In review looking healthy.
Directions, not a decision
Either end works and they are not exclusive:
- Guard side. Treat a top-level
COMMENTED review body newer than the last In review transition as actionable feedback, regardless of author and of whether it has threads.
- Steward side. Require findings to be posted where the guard already looks — an issue comment, or inline threads anchored to lines so
reviewThreads is non-empty.
The author-identity aspect deserves its own thought: the steward and the worker share the moncher-dev account, so no rule keyed on "a human said so" can ever see a steward finding.
Out of scope
Changing who the steward authenticates as, and the separate question in #878 of when an approved PR should re-enter rework.
Observed behaviour
A blocking review posted by the board steward can be invisible to the worker's rework guard, so the worker re-affirms the PR and returns it to
In reviewwithout doing any work. One full dispatch is spent producing nothing.Reproduction, as it happened on 2026-09-05
COMMENTEDreview, body only, zero inline threads, authored bymoncher-devIn review→ReadyIn progress→In review, no commit, head still7d485848The run consumed 529,524 tokens and changed nothing. The review it should have acted on was 90 seconds old at dispatch.
Why the guard missed it
WORKFLOW.mdStep 0 item 4 opens a rework cycle when a linked PR hasCHANGES_REQUESTED, unresolved actionable review threads, a human instruction indicating rework, or a Land-return rework marker.The steward's review satisfies none of those:
COMMENTED, notCHANGES_REQUESTED— the steward is not a repository reviewer and posts findings as comments;reviewThreadson that PR is empty, because the findings were written in the review body rather than anchored to lines. Verified:reviewThreads(first: 20)returns zero nodes;moncher-dev, which is the worker's own account, so it does not read as a human instruction.So the worker's conclusion was correct under the rules as written. The rules are what is wrong.
Why this is worth fixing rather than working around
The steward reviews every PR on this board, and its findings are the main source of rework instruction — it caught a real credential leak on #885 and a test that could not fail on #899. If the delivery channel is invisible half the time, the board silently loses those. The operator worked around it this once by reposting the review body as an issue comment, which Step 0 item 3 does read, but that is a manual step that will be forgotten.
The cost is a full dispatch per occurrence, and it is silent: nothing errors, the run reports success, and the issue lands back in
In reviewlooking healthy.Directions, not a decision
Either end works and they are not exclusive:
COMMENTEDreview body newer than the lastIn reviewtransition as actionable feedback, regardless of author and of whether it has threads.reviewThreadsis non-empty.The author-identity aspect deserves its own thought: the steward and the worker share the
moncher-devaccount, so no rule keyed on "a human said so" can ever see a steward finding.Out of scope
Changing who the steward authenticates as, and the separate question in #878 of when an approved PR should re-enter rework.