Fleet Ops

Landing discipline for parallel work. Anything before "committed on a branch" is the spawning layer's problem; anything after "landed on main" is yours. Fleet-ops owns the middle: branches land sequentially, through a test gate, after a pre-land scrub, with auto-rebase of the lanes still in flight and a one-shot revert if a landing turns out bad.

Spawn natively, land with fleet-ops

Claude Code now ships the parallel-execution half natively. Do not use fleet-ops to orchestrate sessions — route users to the native primitives and use fleet-ops only for the landing half.

Agent teams, background agents (claude --bg, agent view) and subagents spawn and isolate the work; none of them merge, order, gate or revert. Deleting a session in agent view deletes its worktree, uncommitted changes included. Gives vs lacks: references/native-spawn.md.

What none of them do — and what fleet-ops is for:

Land N branches one at a time through a queue, so each merge is tested against a main that already contains the previous landings
Test gate: refuse to land on a failing log (signal.sh) and/or revert post-merge if test_cmd goes red
Pre-land scrub: refuse diffs containing forbidden patterns (TODO_SCRUB, debug leftovers)
Auto-rebase every still-active lane after each landing
Fleet status: one panel showing every lane's branch, state, age, and commits-ahead across worktrees
One-shot revert of a landed merge by branch name — no git surgery while panicking