Problem
Ad-hoc task builders (afx spawn --task ...) have no working resume path. When a task builder's session dies (or its registry row is lost, #1254), the standing recovery rule — worktree exists → resume, never destroy/recreate — is impossible to follow:
afx spawn <task-id> --resume → rejected: the positional only accepts issue identifiers (Invalid issue identifier: task-w-yI).afx spawn --branch builder/task-<id> --resume → fatal: --branch and --resume are mutually exclusive (spawn.js).afx spawn --task "..." --resume → spawnTask() calls generateShortId() unconditionally, so validateResumeWorktree() checks a worktree at the NEW random id's path, which can never exist. There is no way to name an existing task worktree.- Even if (3) validated,
spawnTask() never calls discoverResumeSession() and passes no resume object to startBuilderSession() — unlike the issue-numbered spec path, which resumes via claude --resume <uuid>. A task 'resume' would silently start a FRESH conversation in the worktree while appearing to be a resume.
Point 4 is the sharp edge: an operator following docs would believe they revived the same agent when they got a new one — an invisible identity swap.
Observed in the wild (2026-07-26, shannon workspace)
A task builder authored a correction set under an author-rotation discipline that required the SAME author for a follow-up pass. Its session became unaddressable (registry row gone, process still alive). No resume form worked; the follow-up had to be re-ruled to a fresh hand under an amended lineage.
Ask
Either (a) support afx spawn --task-id task-<id> --resume (or accept the existing task id positionally) that reuses the existing worktree AND goes through discoverResumeSession() like the spec path, or (b) have all --resume-adjacent errors state explicitly that task builders are not resumable, so operators don't design processes (author rotation, same-author rulings) that assume they are.
Related: #1254 (nested task-spawned ghost registration).
Problem
Ad-hoc task builders (
afx spawn --task ...) have no working resume path. When a task builder's session dies (or its registry row is lost, #1254), the standing recovery rule — worktree exists → resume, never destroy/recreate — is impossible to follow:afx spawn <task-id> --resume→ rejected: the positional only accepts issue identifiers (Invalid issue identifier: task-w-yI).afx spawn --branch builder/task-<id> --resume→fatal: --branch and --resume are mutually exclusive(spawn.js).afx spawn --task "..." --resume→spawnTask()callsgenerateShortId()unconditionally, sovalidateResumeWorktree()checks a worktree at the NEW random id's path, which can never exist. There is no way to name an existing task worktree.spawnTask()never callsdiscoverResumeSession()and passes no resume object tostartBuilderSession()— unlike the issue-numbered spec path, which resumes viaclaude --resume <uuid>. A task 'resume' would silently start a FRESH conversation in the worktree while appearing to be a resume.Point 4 is the sharp edge: an operator following docs would believe they revived the same agent when they got a new one — an invisible identity swap.
Observed in the wild (2026-07-26, shannon workspace)
A task builder authored a correction set under an author-rotation discipline that required the SAME author for a follow-up pass. Its session became unaddressable (registry row gone, process still alive). No resume form worked; the follow-up had to be re-ruled to a fresh hand under an amended lineage.
Ask
Either (a) support
afx spawn --task-id task-<id> --resume(or accept the existing task id positionally) that reuses the existing worktree AND goes throughdiscoverResumeSession()like the spec path, or (b) have all--resume-adjacent errors state explicitly that task builders are not resumable, so operators don't design processes (author rotation, same-author rulings) that assume they are.Related: #1254 (nested task-spawned ghost registration).