Split out of the field report in #232, which described this gap but deliberately did not file it
("it's a design change rather than a defect … CONTRIBUTING.md points at Discord for changes this
size, so I haven't just filed it"). Filing it here so the design question is at least on the
record and can be accepted or declined explicitly. Credit to @Polloinfilzato for the report and
the field data.
The gap
There is no non-destructive way past an escalation under worktree isolation:
Phase.ESCALATED is terminal, so resume skips the story.resolve re-drives it from scratch.--restore-patch is rejected under worktree isolation.
The work itself is not lost — keep_failed leaves the branch mounted — it simply cannot be
continued. Every recovery is a hand-rolled version of one missing command: merge the kept
branch, mark the story done, start a fresh run.
Why it matters more than the raw frequency suggests
From the reporter's week of unattended overnight runs: the recovery was needed four times, with
zero work lost, and one of those avoided a ~28M-token re-drive. Crucially, most
escalations in that sample were false positives — the recurring shape being the review session's
VC-hygiene gate raising a CRITICAL escalation ("working tree is dirty…") because the dev pass left
artifact files uncommitted, while the same message self-reports Status: done with a full
delivery summary. A mechanical block, not a quality objection. Three separate stories hit it.
So the common case is: a story that is actually finished, blocked behind a terminal phase whose
only exit is to throw the work away and pay for it again.
Precedent
#172 / #173 established exactly this principle on the dev-retry path — a retry after a timeout
used to roll back commits the attempt had already landed; the fix was to accept the baseline it
had advanced past rather than re-derive it. This is the sibling case on the escalation path.
Design questions
- What is the safe shape — a
resolve --continue that adopts the kept branch as the attempt
baseline, or an explicit finalize <story> that merges the kept branch and advances
sprint-status without re-running dev?
- What guards the "actually finished" claim? Adopting a kept branch on operator say-so is a new
trust boundary. The reporter's own protocol distinguishes verified false positive → finalize
and continue from real doubt → get a second opinion — but that judgment currently lives
outside the engine, and the project's stated line is no LLM in the control loop.
- Review debt. The report's sharpest observation is that finalizing a story bypasses that
story's automated review, and the resulting obligation "has to land somewhere that blocks" — a
log line is not a queue. In one case the skipped review, run days later, found a HIGH-severity
security defect, and the stories most likely to be finalized this way are the security-sensitive
ones already flagged for follow-up. Any finalize path probably has to file into deferred-work.md
rather than merely journal.
Possibly a cheaper first move
If the recurring trigger really is the VC-hygiene gate firing on orchestrator-owned artifact
residue, narrowing that escalation may remove most of the demand for a continuation path at all —
compare #123, which is the same "residue the orchestrator itself owns should not block" argument on
the rollback path.
Refs: #232 (source), #172, #173, #123.
Split out of the field report in #232, which described this gap but deliberately did not file it
("it's a design change rather than a defect …
CONTRIBUTING.mdpoints at Discord for changes thissize, so I haven't just filed it"). Filing it here so the design question is at least on the
record and can be accepted or declined explicitly. Credit to @Polloinfilzato for the report and
the field data.
The gap
There is no non-destructive way past an escalation under worktree isolation:
Phase.ESCALATEDis terminal, soresumeskips the story.resolvere-drives it from scratch.--restore-patchis rejected under worktree isolation.The work itself is not lost —
keep_failedleaves the branch mounted — it simply cannot becontinued. Every recovery is a hand-rolled version of one missing command: merge the kept
branch, mark the story done, start a fresh run.
Why it matters more than the raw frequency suggests
From the reporter's week of unattended overnight runs: the recovery was needed four times, with
zero work lost, and one of those avoided a ~28M-token re-drive. Crucially, most
escalations in that sample were false positives — the recurring shape being the review session's
VC-hygiene gate raising a CRITICAL escalation ("working tree is dirty…") because the dev pass left
artifact files uncommitted, while the same message self-reports
Status: donewith a fulldelivery summary. A mechanical block, not a quality objection. Three separate stories hit it.
So the common case is: a story that is actually finished, blocked behind a terminal phase whose
only exit is to throw the work away and pay for it again.
Precedent
#172 / #173 established exactly this principle on the dev-retry path — a retry after a timeout
used to roll back commits the attempt had already landed; the fix was to accept the baseline it
had advanced past rather than re-derive it. This is the sibling case on the escalation path.
Design questions
resolve --continuethat adopts the kept branch as the attemptbaseline, or an explicit
finalize <story>that merges the kept branch and advancessprint-status without re-running dev?
trust boundary. The reporter's own protocol distinguishes verified false positive → finalize
and continue from real doubt → get a second opinion — but that judgment currently lives
outside the engine, and the project's stated line is no LLM in the control loop.
story's automated review, and the resulting obligation "has to land somewhere that blocks" — a
log line is not a queue. In one case the skipped review, run days later, found a HIGH-severity
security defect, and the stories most likely to be finalized this way are the security-sensitive
ones already flagged for follow-up. Any finalize path probably has to file into
deferred-work.mdrather than merely journal.
Possibly a cheaper first move
If the recurring trigger really is the VC-hygiene gate firing on orchestrator-owned artifact
residue, narrowing that escalation may remove most of the demand for a continuation path at all —
compare #123, which is the same "residue the orchestrator itself owns should not block" argument on
the rollback path.
Refs: #232 (source), #172, #173, #123.