Ct dev slot commit often

In a CreatorTrack isolated-build session (worktree via forge_creatortrack_agent_bootstrap.sh), the dev-slot reaper removes a worktree after ~45min idle / when over the cap, and it takes UNCOMMITTED work with it. On 2026-07-08 a full multi-file Task (publish pipeline) built over ~45min of heads-down editing was lost when the slot reaped, because the dev server hadn't been hit and the files weren't committed yet. Committed branch commits survived (the branch + its history are untouched); only the working tree was gone.

Why: the reaper is idle-based and does not preserve dirty worktrees. Long build stretches without a dev-server request go idle.

How to apply: commit each plan task the moment it verifies, before starting the next one (never batch multiple tasks' worth of uncommitted files). If a slot is reaped, git worktree add <path> <existing-branch> re-checks-out the branch (the bootstrap's -b fails when the branch already exists); the per-slot DB clone usually survives, but re-run the migrate script to be sure. See [[reference_creatortrack_dev_slot_reaper]].