feat: a reviewer's surplus insight becomes the next item, not a refusal (#171) - #173
Merged
Merged
Conversation
Two items were rejected having met every criterion their briefs stated, both because the reviewer would additionally have done something else: "the other two bundle entry points have no explanation at all" "the code does not demonstrate any explicit guard against future accidental serialization of Snippet::text" Both are good observations. Neither was in the item. Rejecting on them discarded the work *and* the observation: the item goes back to be rewritten identically, and nothing records what was noticed. So the rubric now asks for them. When every stated criterion is met the reviewer approves and lists what else it would have done under Follow-ups, and those are kept as plan-shaped markdown for a person to accept or discard — plus an event each, because the stream is the source of truth and a coordinator should not need to know where a file is. **Only on approval, and that is the whole safety property.** A rejection has already said what is wrong and gets no second channel; allowing follow-ups there is how "approve and defer" grows into a way to wave a failed criterion through. The prompt says a criterion the task states and the change does not meet is still a rejection and no follow-up substitutes for one, and a test asserts a rejection produces nothing. Two smaller boundaries, both tested. "- none" is an answer, not an item: a backlog filled with the absence of findings is worse than an empty one. And prose after the list ends the list — attributing a proposal the reviewer did not make is worse than missing one, because a person triages it, finds nothing behind it, and trusts the next one less. A plan document rather than queue rows, for the reason `inception` produces a PLAN.md: writing straight to the queue forks the pipeline into a generated path and a hand-written one that diverge forever. Both executors share the parser and the recorder, so this cannot drift the way the review rubric did (#167). Closes #171. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two items were rejected having met every criterion their briefs stated, both
because the reviewer would additionally have done something else:
Both are good observations. Neither was in the item. Rejecting on them
discarded the work and the observation — the item goes back to be rewritten
identically, and nothing records what was noticed. Both have since been filed
by hand as
rdpapp#2andrdpapp#3, which is the behaviour this makesautomatic.
What changes
When every stated criterion is met, the reviewer approves and lists what else
it would have done under Follow-ups. Those are kept as plan-shaped markdown
for a person to accept or discard, plus an event each — the stream is the
source of truth, and a coordinator should not need to know where a file is.
The safety property
Only on approval. A rejection has already said what is wrong and gets no
second channel. Allowing follow-ups there is exactly how "approve and defer"
grows into a way to wave a failed criterion through — the gate-weakening
AGENTS.mdforbids, arriving by a friendlier route.The prompt says it plainly:
and a test asserts a rejection produces nothing at all.
Two smaller boundaries, both tested
findings is worse than an empty one.
did not make is worse than missing one: a person triages it, finds nothing
behind it, and trusts the next one less.
Why a plan document rather than queue rows
The same reason
inceptionproduces aPLAN.md: writing straight to the queueforks the pipeline into a generated path and a hand-written one that diverge
forever. Nothing here is admitted to anything until a human moves it into a
plan.
Both executors share the parser and the recorder, so this cannot drift the way
the review rubric did (#167).
All four gates green.
Closes #171.
🤖 Generated with Claude Code