Problem
When an agent is killed mid-run (external signal, OOM, session teardown), it may leave untracked files in its lane worktree. On the next resume, the allocator's lane-reattachment step treats that untracked output as "uncommitted changes" and raises LANE_ALLOCATION_FAILED — blocking the resume entirely.
The operator has to manually stash or remove the partial output before the resume will proceed.
Observed case
Mission review-context-depth-01KX2EQ9, WP08, lane-h. Agent was killed after creating one untracked artifact dir (specs/perf-validation/context-runs/recheck-pr105/) from a partial first replay. On resume, the allocator saw the untracked dir, raised LANE_ALLOCATION_FAILED (reason payload in the JSON was helpful for diagnosis), and refused to reattach. Manual stash → resume succeeded.
Suggested fix
The lane-reattachment path knows the WP's owned_files list and/or create_intent globs (both are in the WP frontmatter). Before raising LANE_ALLOCATION_FAILED, the allocator could:
- Check whether ALL untracked/dirty files fall within the WP's declared ownership scope.
- If yes: auto-stash (or just
git clean -fd within those paths) and proceed with reattachment, logging a warning that partial output was discarded.
- If no (dirty files outside declared scope): still raise
LANE_ALLOCATION_FAILED — that's genuinely unexpected state requiring human review.
This preserves safety for out-of-scope dirt while making the common kill-and-resume case hands-free.
Alternative
A --force-reattach flag that performs the stash automatically (operator opt-in instead of automatic). Less ergonomic but more conservative.
Notes
- The
LANE_ALLOCATION_FAILED reason payload already surfaces the right info for diagnosis — that part worked well.
- The discarded partial output is fine: the re-spawned agent reruns from the beginning of WP08 and regenerates it.
- Related to #2512 in spec-kitty (stale claim markers after OS kill) — same kill scenario, different failure mode.
Problem
When an agent is killed mid-run (external signal, OOM, session teardown), it may leave untracked files in its lane worktree. On the next
resume, the allocator's lane-reattachment step treats that untracked output as "uncommitted changes" and raisesLANE_ALLOCATION_FAILED— blocking the resume entirely.The operator has to manually stash or remove the partial output before the resume will proceed.
Observed case
Mission
review-context-depth-01KX2EQ9, WP08, lane-h. Agent was killed after creating one untracked artifact dir (specs/perf-validation/context-runs/recheck-pr105/) from a partial first replay. Onresume, the allocator saw the untracked dir, raisedLANE_ALLOCATION_FAILED(reason payload in the JSON was helpful for diagnosis), and refused to reattach. Manual stash → resume succeeded.Suggested fix
The lane-reattachment path knows the WP's
owned_fileslist and/orcreate_intentglobs (both are in the WP frontmatter). Before raisingLANE_ALLOCATION_FAILED, the allocator could:git clean -fdwithin those paths) and proceed with reattachment, logging a warning that partial output was discarded.LANE_ALLOCATION_FAILED— that's genuinely unexpected state requiring human review.This preserves safety for out-of-scope dirt while making the common kill-and-resume case hands-free.
Alternative
A
--force-reattachflag that performs the stash automatically (operator opt-in instead of automatic). Less ergonomic but more conservative.Notes
LANE_ALLOCATION_FAILEDreason payload already surfaces the right info for diagnosis — that part worked well.