Stuck Crewmate Recovery

stuck-crewmate-recovery

Use this playbook when the session-start digest reports an ordinary direct report's endpoint dead or its metadata has no window, or when a direct report is stale, looping, repeatedly confused, asking a question its brief already answers, unresponsive, or when a steer failed to land. A stale or dead-endpoint report for a worker whose pull request has already landed is not a recovery case: the work is finished, so close the task through ordinary teardown (AGENTS.md section 7 for firstmate, the landed-work rule in bin/fm-branch-prompt.sh for the supervision branch) instead of this playbook, never with --force.

Follow the crew-hosted Lavish board contract in docs/configuration.md when recovering a worker that hosts a board.

Interrupt, stop, and relaunch a worker through bin/fm-control.sh <task-id> interrupt|exit|relaunch, which resolves the recorded runtime itself, verifies each action, and never tears down or discards anything (docs/agent-control.md). That plane covers workers running in this home; a remotely placed secondmate is refused by name and reconciled through secondmate-provisioning instead. Load harness-adapters before a resume command or a harness-specific skill invocation, and whenever the adapter's own quirks matter. The target window's harness is recorded as harness= in state/<id>.meta.

Session-start reconciliation for a dead ordinary direct report

This procedure covers ordinary kind=ship and kind=scout direct reports. Load secondmate-provisioning instead for kind=secondmate recovery.

For a REMOTE secondmate, fm-crew-state and fm-peek read the actual remote endpoint over fm-on.sh, and fm-send reports a delivered-with-pending-confirmation steer as delivered (their headers own the contracts); an unknown-remote read or unreachable-host failure means the remote state could not be read, never that the mate is dead or the send failed. Recover a genuinely stuck remote mate only through bin/fm-spawn.sh <id> --secondmate, never raw herdr pane close/kill surgery, which strands the endpoint binding.

Treat the digest's endpoint result as a presence signal, not proof that the task's work or validation run is gone. Read the targeted current state with bin/fm-crew-state.sh <id> before deciding to relaunch. A no-mistakes run matched to the crew's branch and current code remains authoritative when the endpoint is dead: handle a terminal or parked run through the normal lifecycle, and keep supervising an active run instead of creating a duplicate worker.

When no authoritative run accounts for the task, inspect only its recorded backend and worktree inventory. Use treehouse status for treehouse-backed tmux, herdr, zellij, or cmux tasks, and use the recorded orca_worktree_id= and terminal= for Orca tasks. Do not sweep another home's endpoints or infer ownership from a matching window label.

Before relaunch, prove that no live agent still owns the recorded task and that the existing worktree remains available. Preserve its uncommitted changes and commits, keep the same task identity, and resume or relaunch the recorded harness in that existing worktree with the same brief plus a concise progress note. A HERDR endpoint that is not merely idle but destroyed - a pane or workspace removed in Herdr churn - is recovered by that same relaunch, which creates one fresh endpoint in the existing worktree and rebinds the task's record to it; nothing special is needed, and the worktree is untouched (docs/agent-control.md "Reclaiming a task whose endpoint is gone"). That relaunch proves the endpoint is destroyed before it rebinds, so a Herdr server that was merely stopped is adopted back rather than duplicated. On tmux there is no reclaim: a task record carries no socket identity for its endpoint, so a missing window cannot be told apart from one on a tmux server this seat cannot address, and both exit and relaunch refuse. Do not work around either refusal by respawning - it means a live agent may still hold that worktree. That reclaim is the owning home's operation only, and a secondmate is the one exception: recover it through bin/fm-spawn.sh <id> --secondmate as above. Do not use a fresh generic spawn while the recorded worktree is unaccounted for, because allocating another worktree can split one task across two copies. If the worktree or ownership cannot be reconciled safely, leave all state intact and report the task failed or blocked with the conflicting evidence.