Skip to content

feat: a reviewer's surplus insight becomes the next item, not a refusal (#171) - #173

Merged
thedancingdeveloper merged 1 commit into
mainfrom
feat/follow-ups-not-refusals
Aug 5, 2026
Merged

feat: a reviewer's surplus insight becomes the next item, not a refusal (#171)#173
thedancingdeveloper merged 1 commit into
mainfrom
feat/follow-ups-not-refusals

Conversation

@thedancingdeveloper

Copy link
Copy Markdown
Contributor

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. Both have since been filed
by hand as rdpapp#2 and rdpapp#3, which is the behaviour this makes
automatic.

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.md forbids, arriving by a friendlier route.

The prompt says it plainly:

This does not soften anything below. A criterion the task states and the
change does not meet is a rejection, and no follow-up substitutes for one.

and a test asserts a rejection produces nothing at all.

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.
  • Prose after the list ends the list. Attributing a proposal the reviewer
    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 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. 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

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>
@thedancingdeveloper
thedancingdeveloper merged commit 22e84cb into main Aug 5, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

A reviewer's surplus insight should become the next item, not a refusal of this one

1 participant