parallel-session-lanelisted

# Parallel session lane Several agent sessions may run against one repository at the same time. Every step below exists to keep their HEADs, indexes, and diffs from colliding. Each rule was written after the collision it prevents actually happened. ## 0. Getting into this mode Until #661 a human opened N terminals and assigned lanes by hand — this skill described a mode nothing could put you in. `rails-flow` now ships an assigner: ```bash python3 "${CLAUDE_PLUGIN_ROOT}/scripts/assign_lanes.py" app/models app/controllers --budget-usd 6 ``` It prints the `git worktree add` per lane and the session command with `RAILS_FLOW_LANE` set. It **refuses** overlapping lanes, a single lane, a dirty tree, and a missing lane guard. **It prepares; it does not spawn.** Creating a worktree is mechanical and deciding when an agent starts is not, so it prints the commands rather than running them. **No tmux and no daemon**, deliberately. `swarm-forge` needs message passing because its roles cannot see each other's state; ours can — `compose_state.py` derives the driver's state *from the repository* and a work order is a committed file. Git is the handoff medium and it survives a reboot, which a tmux session does not. **You will be told when you need this.** (#723) Until now activation was entirely on a human remembering to run the assigner *before* opening the sessions — so the protocol shipped and stayed dormant, and four unlaned sessions in one directory did exactly what it exists to