Critstorm
Multi-Session Roadmap

01Where we are

Two waves of foundation are in. The game itself has not started yet.

• What shipped so far is scaffolding, not gameplay: the headless physics sim, its pixel buffer rendered under the Pixi stage, a world-bootstrap generator (terrain floor + storm core + strike zone), and a headless storm-harness CLI with stubbed bot strategies.
• The actual game — gold eruptions, the bank-or-ride surge, defenses, meta progression, presentation — is entirely ahead of us.
• The build order is not a free choice: the epics have hard blocks dependencies. The critical path to something playable runs gold loop → surge, and almost everything else hangs off those two.
• Every open issue now carries a readiness label (agent-ready / agent-draft / needs-human) and a wave label (wave-3 … wave-7), so a session can be fired with bd list --label wave-3.

02The dependency spine

Blocks-edges between epics force a mostly-linear order. b4r is done; mhz then hkm are the critical path.

flowchart LR
b4r["b4r · sim + render ✓"] --> mhz["mhz · gold loop"]
mhz --> hkm["hkm · surge (bank-or-ride)"]
mhz --> j5g["j5g · defenses"]
mhz --> sh8["sh8 · presentation"]
hkm --> cz["4cz · economy harness"]
hkm --> gen["gen · meta layer"]
hkm --> npq["npq · storm arc & finale"]

03The wave plan

Each wave is one (or a few) agent sessions, grouped so dependencies are satisfied and file-ownership doesn't collide.

04The v0.1 milestone

Finishing waves 3 and 4 is the design's own vertical slice — the smallest build where the pitch is visible in a 10-second clip.

05The readiness labels

A three-tier scheme, not a binary — the middle tier is where an agent does the work but you review before the next issue builds on it.

Why three tiers matter: the binary hides the two spots where the whole downstream chain depends on getting a shape right. mhz.2 (the Lagrangian value-conservation contract) and hkm.1 (the surge state machine) are keystones — if an agent gets the contract or the state shape wrong, every issue built on top inherits the mistake. Those want a human eye on the design before the dependents run, even though the agent can write them.

06The 7g6 finding

One wave-2.5 issue came back with a real result instead of a green checkmark — worth reading.

This is not a bug to fix now. Design §6 says the late-game growth curve is supposed to come "mostly through multiplier growth + collection efficiency" — i.e. from the surge multiplier (hkm.1) and the collector (mhz.4), neither of which exists yet. So 7g6 was mis-scoped as buildable today. It's been re-scoped: relabeled agent-draft + wave-5, given dependencies on hkm.1 and mhz.4, and the intended assertion is parked as an it.skip in sim/storm-simulator.test.ts with the full analysis in the test body. It comes back in wave 5 once the surge economy makes the assertion meaningful.

07How each wave gets fired

Reuse the wave-2 pattern that worked, minus the two things that tripped the safety gate.

• Agents run in isolated git worktrees → branch → PR (keeps main clean, lets you review)
• No bd inside worktrees — the beads DB isn't available there; all issue bookkeeping happens from the main checkout afterward
• Reviews are comment-only — the classifier blocks an agent approving its own PR
• Merges are done by you (or by me on your explicit go-ahead) — the classifier blocks agent-driven merges
• Keystone review is at merge — no mid-workflow pause. Wave 3 splits into a foundation PR you merge (reviewing the value contract then) before consumers fan out

08Wave 3, concretely

Decisions made — here's how the gold loop actually runs, in two phases forced by a hard code dependency.

The gold loop can't run as one fan-out: mhz.2's value field must exist in code before the collector, eruption spawner, and loss rules (mhz.3/4/5) can be written against it. So wave 3 is two phases: