A rewritten brief returns a stalled item to the queue - #179
Merged
Conversation
The other half of the loop #174 opened. An agent can now say "this item cannot be done as written" and have that recorded as work needing a person — and until this, the person acting on it changed nothing: R7 -> pending [already failed in the queue] applied refresh queue row item R7 in project rdpapp: update title, brief and dependencies; state stays failed The heading is the proposal and the line below it is what happened. The brief updated, the item stayed unclaimable, and the next run said `nothing to do`. Not resetting state on a refresh is the right instinct — `adopt` must not silently un-fail work, and an item that failed its checks five times should not become pending because someone fixed a typo in its title. But a changed **brief** is a different item in the only sense that matters: the attempt that failed was made against wording that no longer exists, so keeping the verdict records a decision about a question nobody is asking. So `revives()` is deliberately narrow: - only `failed` and `blocked`. `done` is not stalled, and editing the description of finished work does not un-finish it; - only the brief. A changed title, label or dependency moves nothing; - compared stripped, so re-parsing a plan cannot revive an item because a newline moved. `last_error` is cleared with the state. The next attempt is told what the previous one was refused for, and that refusal is about wording it can no longer reproduce. The attempt *count* is untouched: what changed is the question, not the fact that it was once attempted. The report line no longer contradicts itself two lines apart — it says either "state returns to pending from failed" or "state stays failed", whichever is about to be true. One existing test seeded an item with no brief at all and then adopted a plan that supplied one, which is a rewrite under this rule. Reseeded with the plan's brief so it tests the unchanged re-sync its name claims, with the revive case pinned separately rather than the original assertion loosened. Closes #178. 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
1 participant
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.
Closes #178. Found by iterating on rdpapp R7.
#174 let an agent say "this cannot be done as written" and have it recorded as work needing a person. This is the half that acts on the person having looked: a human rewrote the brief,
adoptreportedR7 -> pendingand then left itfailed, and the next run saidnothing to do.revives()is deliberately narrow — onlyfailed/blocked, only the brief, compared stripped so a moved newline is not a rewrite.doneis never revived.last_erroris cleared with the state, since the refusal is about wording the next attempt cannot reproduce; the attempt count stays, because what changed is the question, not the fact it was attempted.The report line no longer says
-> pendingandstate stays failedtwo lines apart.Nine tests. One existing adoption test seeded an item with no brief, so the plan supplying one counted as a rewrite — reseeded with the plan's brief so it tests the unchanged re-sync its name claims, and the revive case is pinned separately rather than the original assertion loosened.
All four gates green locally.
🤖 Generated with Claude Code