v0.9.0 Phase 1: Lane CLI + Runtime backends (tmux, worktrees, stream-json logs)

[Hmbown]

Parent: #4175

Problem

Today durable multi-agent runs are ad hoc: tmux sessions, worktrees, and headless codewhale exec are wired separately. There is no first-class Lane (running workflow instance) or Runtime adapter layer.

Per the approved architecture, tmux durability belongs in Runtime, not Fleet.

Scope

Implement Phase 1 of the Fleet/Workflow/Lane/Runtime model:

Lane registry + CLI

codewhale lane list
codewhale lane status <lane-id>
codewhale lane attach <lane-id>      # tmux attach when runtime=tmux
codewhale lane logs <lane-id>        # tail stream-json / journal
codewhale lane stop <lane-id>

Each lane binds: workflow name, fleet name, issue/goal id, runtime backend, branch/worktree refs, started/stopped timestamps.

Runtime backends (adapter trait)

Backend	Use case
tmux	Durable local sessions + attach
inline	In-process subagents (current TUI path)
vm	Remote workbench / cloud VM
ci	GitHub Actions / headless gate runs

Runtime owns: worktree/branch provisioning, process/session lifecycle, stream-json log capture, reconnect/attach metadata.

Worktree provisioning

• Move/adopt worktree pool concerns from scattered call sites (v0.9.4 WhaleFlow: worktree pool management for parallel agent isolation #4016) into Runtime — not Fleet.
• Lane records which worktrees a run created; Runtime cleans up on lane stop (configurable TTL).

Non-goals

• Fleet role resolution (Phase 2, v0.9.1 Phase 2: Workflow steps reference Fleet roles (not raw prompts/profiles) #4177)
• Workflow step schema changes (Phase 2)
• Gates/handoffs (Phase 3, v0.9.1 Phase 3: Workflow gates and handoffs between Fleet roles #4179)

Acceptance criteria

• codewhale lane list|status|attach|logs|stop works against a tmux-backed lane.
• Lane registry persists across CLI invocations (e.g. under CODEWHALE_HOME).
• Runtime tmux adapter: create session, stream-json log file, attach metadata, stop/cleanup.
• Runtime provisions isolated worktree + branch for a lane when configured.
• Fleet module does not import tmux or session management.
• Integration test: start lane → attach → stop → worktree TTL cleanup.

Related

• v0.9.1 architecture: Fleet / Workflow / Lane / Runtime product model (canonical tracker) #4175 — Product model tracker
• v0.9.1 Phase 2: Workflow steps reference Fleet roles (not raw prompts/profiles) #4177 — Phase 2: Workflow role resolution
• v0.9.1 Phase 3: Workflow gates and handoffs between Fleet roles #4179 — Phase 3: Gates + handoffs
• v0.9.1: Stopship workflow as fleet-backed lane (dogfood #4090/#4093/#4094) #4178 — Stopship dogfood lane
• v0.9.0 Workflow: product-readiness tracker #4038 — Workflow product-readiness
• v0.9.4 WhaleFlow: worktree pool management for parallel agent isolation #4016 — Worktree pool (implement inside Runtime, not Fleet)
• feat(workflows): v0.8.68 agent execution lanes and milestone sync #4163 — Agent workflow playbook
• docs/AGENT_WORKFLOWS_0868.md