# Parallel "Deepen the Systems" Wave — ready-to-fire plan

**Status:** STAGED. Do NOT launch until the TRIGGER below is met. Authored while the camera/visibility
pass is still running.

## TRIGGER (fire the wave only when all true)
1. A mech renders on screen (camera pass done).
2. There is a world/environment to be in (terrain/cavern renders — Tier 1).
3. The player mech moves/turns under control input with a following camera (Tier 2 — basic piloting).

Why wait: parallel reconstruction is only **compile-verified**; correctness shows up at **runtime**, and
we've repeatedly hit runtime-only bugs (vtable artifact, shadowed `subsystemArray`, null scenarioRole).
A pilotable build is the **test harness** that lets the serial integration pass validate the wave's output.
Firing earlier just piles up plausible-but-wrong code with nothing to check it against.

## SERIAL pre-work that must finish first (NOT part of the wave)
- **Tier 1 — world/terrain render:** fix `DPLRenderer::MakeEntityRenderables` `/RTC1` uninit bug
  (`L4VIDEO.cpp:5211`) + load the cavern environment so non-mech entities draw. (btl4grnd.cpp + engine.)
- **Tier 2 — locomotion:** wire control input → mech per-frame mover/Animate consumer → chase camera.
  This touches `mech.cpp` + `mechmppr.cpp` (shared cores) so it's serial, done before the wave.
These two are the critical path to "pilotable" and must not run concurrently with the wave (shared-file
contention on mech.cpp / btl4vid.cpp / camera).

## THE WAVE — parallel agents, partitioned by DISJOINT file ownership
Same model as the compile wave that worked (7 families, no collisions). Each agent: reconstruct the REAL
per-frame behavior of its subsystems (the streamed objects currently have only minimal `MechSubsystem`
base behavior) from the **binary oracle** (`decomp/recovered/all/part_*.c`, `vtables.tsv`, `functions_index.tsv`)
+ the **RP analog** (`...\trunk\RP\`, `WEAPSYS`/`VTV*`) + surviving headers. Verify by COMPILE
(`compile1.cmd <file>`), match the oracle, and flag cross-family needs (don't edit headers you don't own).

| # | Agent (track) | Owns (`decomp/reconstructed/`) | Reconstruct |
|---|---|---|---|
| 1 | **Heat/power** | heat.cpp/hpp, powersub.cpp/hpp, gnrator.cpp/hpp | HeatSink heat-flow/coolant per-frame, HeatableSubsystem thresholds, PoweredSubsystem voltage bus, Generator output. (Owns the subsystem BASE classes — coordinate first.) |
| 2 | **Energy weapons** | mechweap.cpp/hpp, emitter.cpp/hpp (+ survived GAUSS.CPP/PPC.CPP) | MechWeapon fire/cooldown/heat-cost, Emitter beam (PPC/Gauss) FireWeapon (vtable slot 18). |
| 3 | **Projectile/missile weapons** | projweap, mislanch, missile, seeker, projtile, misthrst, ammobin (.cpp/.hpp) | ProjectileWeapon/MissileLauncher fire, Missile/Seeker flight + homing, AmmoBin counts, MissileThruster. |
| 4 | **Sensors/targeting/tech** | sensor.cpp/hpp, mechtech.cpp/hpp | Sensor target acquisition/lock, MechTech repair/diagnostics. |
| 5 | **Movement subsystems** | gyro.cpp/hpp, torso.cpp/hpp, myomers.cpp/hpp | Gyro stability, Torso twist/aim, Myomers actuation. |
| 6 | **Damage/messaging** | mechdmg.cpp/hpp, dmgtable.cpp/hpp, messmgr.cpp/hpp | DamageZone TakeDamage → structure/armor, damage-table rolls, SubsystemMessageManager dispatch. |
| 7 | **HUD / 2D track** (independent, HIGHEST risk) | hud.cpp/hpp, btl4gaug/gau2/gau3/galm (.cpp/.hpp) + a NEW `dpl2d` over-D3D layer | The `dpl2d_*` 2D layer (no D3D equivalent exists — from-scratch over the D3D device) + gauge widgets reading real subsystem state + `.gim/.gat/.pcc` cockpit assets. The one genuine unknown; give it the most room. |

(Track 8 — world/terrain — is the SERIAL Tier-1 pre-work above, not a wave slot.)

## Ownership / contention rules (critical — agents run concurrently, no git worktrees)
- Edit ONLY your owned `.cpp` + `.hpp`. Need a base-class change in a header you don't own → REPORT it
  ("CROSS-FAMILY NEEDS"), don't edit it.
- Heat/power (agent 1) owns the subsystem base classes weapons/sensors/movement derive from → if its base
  signatures change, let it settle first OR have it publish the final base surface up front.
- Do NOT touch `mech.cpp`/`mech.hpp`/`btl4vid.cpp` (cores + render) — those are serial-integration territory.
- Each agent runs builds against the SAME build dir → builds are serialized by the OS; that's fine for
  `compile1.cmd` single-file checks (preferred) but don't run full `cmake --build` concurrently.

## After the wave: SERIAL integration pass
One bring-up loop (debugger-driven) runs the pilotable build with the deepened systems active and validates
behavior at runtime — fix interaction bugs, wire the cross-family needs the wave reported, confirm
weapons/heat/damage/HUD actually function together. This is where the parallel reconstruction gets its
correctness check. THEN: Tier 5 (enemy AI / `path.cpp` reconstruction) + mission objectives/scoring.

## Dispatch checklist (when triggered)
- [ ] Confirm pilotable (3 trigger conditions).
- [ ] Re-verify build GREEN + all 43 modules compile (baseline).
- [ ] Launch agents 1–6 (combat) as one parallel batch; launch agent 7 (HUD) as its own long-running track.
- [ ] Collect reports → reconcile CROSS-FAMILY NEEDS → serial integration pass.
- [ ] `path.cpp` / enemy AI is its own pass after combat is validated.