Quitting an in-process chat silently strands its running task

Start with internal/session/task_run_belt.go at cutBeltRun and driveBeltRun, then reproduce the scripted RunEngine scenario described in the issue, including the done-during-close race. Read internal/manual/chat/worker-harness.md:523 for the current promise. Done means the in-process close behavior is explicit and ordered, the e2e and unit acceptance cases pass, and the manual plus change entry are updated.

Found on santos/dev2 at 008363c98 (#1410). It reaches dev when #1410 merges.

What happened

On 2026-09-24, /quit during a /task in codeaf chat --no-host closed the window without warning. The run later read interrupted; its file never landed, and its branch and copy remained. worker-harness.md says closing the window, ctrl+c and /quit do not stop a run and its work lands by itself. The engine road did land in the control run. Related design: #1318.

Replication

Deterministic (no model). In internal/session, use a scripted RunEngine whose worker waits on a channel. Start a belt run, call Agent.Close, release the worker, and inspect the root and target Git tree. Today the close cancels the driver and the non-done result takes the interruption return without landing.

Field (real models). With OPENROUTER_API_KEY, deepseek/deepseek-v4-flash and a throwaway Git repository, ask /task run sleep 45, then write done.txt containing done; while it runs, enter /quit. Allow about two minutes and a few cents. Reopen: done.txt is absent and the run is interrupted. Repeat on the engine road as a control.

Where

internal/session/task_run_belt.go:744, cutBeltRun, cancels the run; driveBeltRun at :795 returns without landing when closing. The unqualified manual promise is internal/manual/chat/worker-harness.md:523.

The fix

Make the close behavior explicit on the in-process road: keep the run alive through an owner able to finish it, or warn before quitting that the run will be interrupted. Make the manual precise for both roads.

Suspicion, not reproduced

From reading the code, not reproduced: Agent.Close cancels the run but never waits on run.over. A run answering done during close may merge into the person's checkout after Close returns. A hand test pressing /quit as the final leaf finishes, plus a session test whose RunEngine.Start answers done just after cancellation and asserts run.over closed before Close returns, would settle this.

Acceptance

• e2e: codeaf chat --no-host gives the chosen explicit close warning or completes landing; the run, file and branch match its words.
• Unit: close and driver completion have a defined ordering, including the done-during-close race.
• Update worker-harness.md and a change entry's invalidates.