Record named steps when a seat is recycled

[jim80net]

Operator summary

Before

When a seat was recycled — replaced with a fresh session — observers could not tell which step had actually finished. A failed or retried attempt could also leave a leftover in-progress mark that hid a later successful recycle.

Change

Recycle now records four named steps: handoff written, waiting for close, fallback respawn, and takeover confirmed. Each attempt owns its own record. If an attempt retries or is superseded, that record is removed before the next try; a cleanup failure stops the retry instead of leaving a stale in-progress mark.

After

recycle status can report which step the current attempt is in. A finished successful recycle is not hidden by an abandoned retry.

Identifiers

• Branch: agent/retro-0905-p1-l-recycle-phases
• Head: 83ef2a367c2109d9dac118d9e4ba01bea2878c60
• Base: 6e1c66496918fc6ed9750e0bef7f36b650719335

Summary

Adds typed recycle lifecycle phases (handoff-written, awaiting-close, fallback-respawn, takeover-confirmed) and token-safe phase sidecar finalization. A retryable post-handoff busy path removes that attempt's phase record before continue; cleanup failure is joined to the busy error and breaks the loop. Stale-retry and concurrent-newer-token controls remain.

This branch is based on recycle lifecycle hardening already present on 0299b8bd (not the later GHI bounce head). Unique vs that parent: cmd/flotilla/recycle.go, cmd/flotilla/recycle_test.go, openspec/specs/recycle/spec.md.

---

Summary by cubic

Recycle now records four named lifecycle phases — handoff-written, awaiting-close, fallback-respawn, takeover-confirmed — and exposes them through flotilla recycle status --json, so observers can see exactly which step an attempt is in. A retried or superseded attempt removes its own phase record before continuing, so an abandoned retry can no longer leave an in-progress mark that hides a later successful recycle.

Behavior

• Recycle refuses to touch a desk that is actively composing, and refuses stale retries aimed at a process generation already retired by a successful recycle; legacy pre-generation success records now block an already-running command without wedging later retries.
• During close, recycle can now answer harness background-work exit confirmations by selecting the option that exits, including when the harness renders descriptive or Unicode task labels; ordinary numbered prompts are left untouched.
• If phase-record cleanup fails, the retry stops instead of proceeding with a stale in-progress mark.

Status records

• Successful recycles record the retired process generation, and stale-retry refusals do not overwrite that record.
• Success records are finalized under the pane transaction lock, and status writes are serialized, so a concurrent failure cannot hide a success.
• A failed attempt that hits a transient read error leaves the existing record untouched rather than overwriting a possible concurrent success.
• A failed terminal status write keeps the phase record in place, preserving in-progress visibility.
• The final outcome keeps the last phase after the in-progress record is cleared.

^{Written for commit 093e084. Summary will update on new commits.}

[cubic-dev-ai]

All reported issues were addressed across 9 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 4 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>