simulation-laneslisted

# Simulation Lanes Parallel isolated implementation lanes, with graduation by cherry-pick. ## The graduated workflow The lane is the **primary** implementation surface. Main receives only proven code. ``` plan -> ground lane (shared infra) -> parallel landing lanes -> verify -> merge -> review -> cherry-pick to main ``` This is not a safety net bolted onto normal development. It is the development path. Work done directly on main has skipped the thing that makes graduation mean anything. ## Topology A **ground** lane holds changes every landing needs — migrations, shared infrastructure, common types. Landing lanes branch from ground, so they inherit prepared infrastructure instead of each re-deriving it. ``` main (frozen baseline) └── ground shared infra + migrations ├── landing-a sub-phase A ├── landing-b sub-phase B └── landing-c sub-phase C ``` Cap concurrency at **4 landings**. Beyond that, port and datastore allocation collides and verification stops being trustworthy. If a phase has more parallel-safe sub-phases than that, sequence them in waves. ## Resource allocation Each lane needs its own service port and its own datastore namespace, recorded in the plan. Claude Code's native worktree support (`claude --worktree`) can replace manual setup. ```bash git worktree add ../lane-ground -b sim/ground git worktree add ../lane-a -b sim/landing-a sim/ground ``` ## Verification before merge Run before merging any