supervisor_takeover destroys the paused lane: task marked skipped, batch completed 0/1, worktree+branch removed, uncommitted work lost

[HenryLach]

Summary

supervisor_takeover is documented as a non-destructive park: "worktrees, branches, batch state, sessions preserved." In penster batch henrylach-20260903T… (TP-2039), invoked while the single task was in a governance hold, the engine instead treated the paused wave as terminal: it marked TP-2039 skipped, "completed" the batch 0/1, ran a no-op merge onto the orch branch, and removed the lane worktree and its branch. The worker's uncommitted work in that worktree was destroyed. Committed work survived only as dangling commits and was recovered by hand into rescue/tp2039-lane-iter3.

Sequence

1. TP-2039 plan gate reached the REVISE cap (round 2). Per the operator's standing rule the worker entered a hard hold and both worker and supervisor escalated to the operator, who was away.
2. The runtime kept re-spawning worker iterations against the held task (four iterations, each idling; each re-spawn pushed "continue Steps 2–6", which the worker correctly refused).
3. To stop the budget burn the supervisor walked the parking ladder: trigger_wrap_up (one-shot, consumed), orch_pause (blocks new tasks only, not iterations inside a running task), then supervisor_takeover.
4. On takeover the engine: marked the task skipped, recorded the batch as completed 0/1, executed a merge that integrated nothing, and cleaned the lane worktree and branch.
5. Uncommitted files in the lane (a helper source file, its tests, a config field) were lost. Lane commits were recovered from the reflog/dangling objects.

Expected

• Takeover pauses the wave and preserves the lane worktree, its branch, and batch state exactly as documented. A held or paused task is not terminal; it must not be marked skipped and must not trigger batch completion or a merge.
• There is a way to park a running task that stops iteration re-spawns without ending the task. Today orch_pause does not stop in-task iterations and trigger_wrap_up is single-use, so the only remaining lever was the one that destroyed state.
• Cleanup of a lane worktree never runs while that worktree has uncommitted changes, regardless of task state. At minimum: refuse and report; better: auto-stash or auto-commit with a hold:/wip: prefix onto the lane branch before any removal.

Actual

• Paused wave treated as terminal → task skipped → batch "completed" → no-op merge → worktree + branch removed.
• Uncommitted work destroyed with no warning.

Related

• Cap-ruling hold: runtime must block .DONE and merge while an operator ruling is pending (.PENDING-RULING) #627 (cap-ruling hold: runtime must block .DONE/merge while an operator ruling is pending). This is the complementary failure: the runtime had no hold state, so the supervisor reached for takeover, which then destroyed the lane. A first-class hold state (a task status such as held that stops iteration re-spawns, blocks .DONE/merge, and preserves the lane) would resolve both.
• feat(gate-integrity): task must not finalize succeeded while steps lack an explicit APPROVE in their review files #626 (no finalize without explicit APPROVE): the batch here was finalized with the step's latest review file still reading REVISE.
• Program history: this is the third runtime bug hit in one day on this program, after the stale-executing rehydration trap and the completion re-triggers.

Suggested minimal cut

1. Takeover/pause never changes a task's status to skipped and never triggers batch completion or merge.
2. Worktree removal refuses when git status --porcelain is non-empty in the lane.
3. A held task status that suppresses iteration re-spawns until a ruling mailbox message arrives (shared with Cap-ruling hold: runtime must block .DONE and merge while an operator ruling is pending (.PENDING-RULING) #627).

[HenryLach]

Minimal cut implemented (commit a32cde3): the data-loss half is closed. removeWorktree and forceCleanupWorktree (the raw-rmSync last resort, incl. batch-start leftover cleanup) now refuse to remove a worktree with uncommitted changes unless the caller explicitly opts in after preserving progress. A toplevel-identity check keeps corrupted/orphaned-worktree recovery working (their git context resolves to the parent repo — they fall through to removal). The reset-failure cleanup paths in engine/resume surface a refusal loudly and track it for the cleanup gate — never force-cleaning past it. Behavioral tests cover refusal-preserves-work, forceCleanup honoring the guard, opt-in removal, and corrupted/orphaned removal.

Still open — the core bug: takeover treating a paused wave as terminal (task skipped, batch 'completed 0/1', no-op merge, branch removal). That needs a state-machine diagnosis and is planned together with #627's held state as the next designed piece of work. With this cut, a recurrence would wrongly mark the task skipped but can no longer destroy uncommitted work.

[HenryLach]

Status update (for agents reading this issue)

Data-loss half fixed in PR #632 (commit a32cde3e), targeting v0.30.6; the takeover state-machine half remains open (Tier-2 design with #627).

What you will observe

• removeWorktree / forceCleanupWorktree refuse a worktree with uncommitted changes (git status --porcelain): the worktree, its branch and the uncommitted files stay put; the refusal is logged (REFUSED to remove worktree with N uncommitted change(s)) and tracked for the cleanup gate. Only a caller that has preserved progress can pass allowDirty.
• Corrupted/orphaned worktrees (git context resolves to the parent repo) still remove — recovery flows keep working.
• A later provisioning error "worktree already exists" therefore means preserved work awaiting a human decision, not a bug.

Related (from #631, same PR): orch_abort and integration cleanup are now bound to the batch they act on and refuse under a live/unknown engine — a takeover can no longer sweep another batch's refs. supervisor_takeover itself is unchanged here; do not use it on an inherited paused/held lane — use the #631 recovery path (orch_resume(force=true) after the takeover summary's Engine line reads dead/exited).

[HenryLach]

Partial fix shipped in v0.30.6 (the minimal / Tier-1 cut described above, live-verified on Penster). This issue stays open for its Tier-2 scope, which is the next design pass together with #627 (held state, durable hold record, typed rulings, takeover state machine, full coverage gate, engine lease/generation).