Recover interrupted ZCode work without losing changes

[Futuri-Risk]

Parent

#1

What to build

Prove and complete the recovery path for interrupted ZCode ACP workers using FirstMate's existing stuck-crewmate recovery plus Treehouse preservation.

When a ZCode worker dies, wedges, or loses its ACP process, unique uncommitted/unlanded work must stay associated with the original task and remain recoverable without the user locating branches or worktrees manually. Add new recovery code only for a demonstrated gap in upstream behavior.

Cloud implementation requirement: Complete all implementation, repository changes, tests, fixtures, static/contract verification, and integration analysis possible from the GitHub/chat environment. Do not defer implementation merely because final production binaries or private services are unavailable. Clearly identify only the minimal runtime observations that require later local certification.

Acceptance criteria

• Killing or losing a ZCode ACP worker does not destroy or recycle its dirty/unlanded Treehouse worktree.
• Recovery uses the recorded task/worktree identity and does not allocate a conflicting clean worktree while the original remains authoritative.
• A resumable worker/session is resumed when the existing stack supports it; otherwise FirstMate can relaunch/recover into the preserved local copy.
• Untracked files, uncommitted modifications, and local commits remain preserved through the recovery path.
• Unsafe teardown/release is refused while unique work remains unlanded.
• Existing FirstMate/Treehouse recovery mechanisms are reused before introducing new state machinery.
• Any added recovery behavior is justified by a concrete failing acceptance case rather than speculative duplication.
• Tests deliberately simulate interruption states and prove preservation plus correct task association.

Blocked by

• Dispatch ZCode crewmates through ACPx #3 Dispatch ZCode crewmates through ACPx