Dispatch binds facts to a workflow run, not to the task, and never cleans up after itself #1807

Written-by: Chief

The dispatch path works, but it carries facts in the wrong place and leaves every carrier behind. Two changes, both owner-requested on 2026-10-30:

1. Bind the work to the task, not to the workflow

Today a dispatch is one throwaway script per beat — /data/dsh/bot/workspace/disp<HHMM>.mjs — whose body is a hand-written brief string passed to

call('flybot/workflow/assign', { workflowId, taskId, title, brief })

The facts (tip sha, check state, gate reason, what to do step by step) live inside that string, and the string belongs to one run on one lane. So when a run dies and the work moves from the PR lane to the dirty-PR lane — which happened twice this morning (p1795, p1771-replay2/p1771-replay3) — the whole brief is rewritten by hand for the new lane. The same facts get copied a third time into the next beat's script. Nothing owns them.

Wanted: the task is the object that holds the facts; a workflow lane is only an executor. Assigning work means pointing a task at a lane, and the lane reads the task. A re-dispatch to another lane must not need the brief rewritten — the facts already on the task are what the new lane gets.

Shape that would satisfy it:

• a task carries id, title, brief (the facts), status, and the lane that currently holds it;
• workflow/assign takes the task id and resolves the brief from the task, so brief is not a per-call argument;
• re-dispatching to another lane keeps the same task id and the same facts, and appends one line saying which lane it moved to and why (this is the handoff record track_tasks already has a field for);
• a run reports back onto the task, so the next beat reads the task instead of the run.

2. Keep the filesystem bounded, and settle what matters into Project State

/data/dsh/bot/workspace is now 75 GB in 4278 entries, 2711 of them one-shot .mjs scripts, plus per-session checkout directories of 1–4 GB each (w1712 4.0 G, replay-1727 3.3 G, t1462 2.6 G, replay-1715 2.1 G, …). None of it is ever removed: each beat adds a script, each replay adds a tree.

The information worth keeping is small — what merged, which tip, why a line was re-dispatched, what the owner decided — and it belongs in Project State (PROJECT.md, ROADMAP.md, decisions/<date>-<slug>.md, LESSONS.md), not in a script body nor in a 3 GB checkout.

Wanted:

• a dispatch script is a transient: it lives in the task's own temp area and is deleted when the task closes (done or blocked), so their count tracks live tasks, not beats elapsed;
• a session checkout/worktree is deleted when its task closes, with the same rule;
• the durable facts of a closed task are written once into Project State by the run that closes it — a merged sha, a decision, a lesson — and the task's brief shrinks to a pointer at that record;
• a guard that reports the two numbers (one-shot scripts, checkout bytes) so unbounded growth is visible instead of being found by accident.

Acceptance

• A task can be re-dispatched from one lane to another without rewriting its facts, and the second lane sees exactly what the first one saw.
• After a task closes, no file created for it remains outside Project State.
• The workspace reports a bounded count and size, and a beat that adds nothing leaves both unchanged.
• Project State answers "why was this re-dispatched / what merged" without reading a script.

Related: #1775 (route a card by its own handoff) is the first slice of the routing half.