myomer system COMPLETE -- the 'WAVE 6 mover cutover' was a phantom built on

a misattribution; the authentic couplings are all live

THE CORRECTION [T1]: @004b9550/@004b95b8 ('ConnectToMover'/'Disconnect
FromMover') are MechWeapon::ConfigureMappables/ChooseButton -- their +0x31C
is the weapon TriggerState and **(mech+0x128) is the CONTROLS MAPPER's
button roster (the MECHWEAP.CPP assert string + the trigger-edge detector
@004b9608 sit adjacent in the image).  The binary has NO dynamic myomer->
speed feed: AvailableOutput has exactly TWO callers in the whole image --
RegisterMaxOutput (assembly) and the SeekVoltageGraph sampler -- and
speedEffect@0x31C is a published GAUGE attribute.

The authentic myomer system (now fully live):
1. drive heat (#85, this morning);
2. VITAL death -- myomers are the only authored vital=1 subsystem
   (BTL4.RES res+0x48 scan): destroying them kills the mech via the #80
   vital-crit path (this is also the ram-death mechanism -- myomers are a
   0.35-weight collision-rattle target);
3. the assembly-time gait cap: RegisterMaxOutput @004b8ef0 raises
   mech+0x7A0 to AvailableOutput(top gear) = base x ~1.4284 -- now called
   (idempotent max, per tick; the 0x358 layout lock leaves no latch room)
   with real OwnerBaseSpeed/OwnerMaxSpeed bridges; the old per-frame
   reverseSpeedMax2 heal that would have clobbered it is garbage-guarded;
4. the ENG-page power curve at correct absolute scale (real base speed);
5. electrical sourcing (low gears run on a browned-out generator).

REMOVED (inventions): the mechmppr `speedDemand *= speedEffect` demand
multiplier + BTMyomersDriveOf + the Myomers ConnectToMover/MoverAttach
family.  Damaged-but-alive myomers heat faster and drop the power curve
but do NOT slow the mech (gitea #75's premise is falsified by the binary;
the real damage slowdown is the LEG-damage gimp gait).  Seek gears change
heat/sourcing/graph -- never speed.

Verified live: a mech at myomer dmg=0.234 (speedEffect attr 0.766)
beelines at full commanded speed with dmgGain=1.234 heat; 0 faults.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019Zh7PTkFy4KwTzVighLR9J

context/subsystems.md

@@ -66,8 +66,35 @@ Making a base byte-exact GROWS every subclass — they must be re-based TOGETHER
     change needs its own verification pass).
 - **WAVE 5** — Torso (aim twist/elevation; joint-I/O reconstructed; the BLH record disables torso →
   faithfully no visible twist).
-- **WAVE 6** — Myomers (mover-coupled; the mover feed is still inert — WAVE 6 cutover — but **DRIVE
-  HEAT IS LIVE**, #85 fix 2026-07-31, see below).
+- **WAVE 6 — ✅ MYOMER SYSTEM COMPLETE (2026-07-31).  The "mover cutover" concept is DEAD — it
+  was built on a misattribution.**  `@004b9550/@004b95b8` (the "ConnectToMover/DisconnectFromMover"
+  bodies) are **MechWeapon::ConfigureMappables/ChooseButton** — their `+0x31C` is the weapon
+  TriggerState and `**(mech+0x128)` is the CONTROLS MAPPER's button roster (proven by the
+  MECHWEAP.CPP assert string + the trigger-edge detector @004b9608 adjacent).  **The binary has NO
+  dynamic myomer→speed feed**: `AvailableOutput` has exactly TWO callers in the whole image —
+  `RegisterMaxOutput` (assembly) and the SeekVoltageGraph sampler — and `speedEffect@0x31C` is a
+  published GAUGE attribute.  The authentic myomer system, all live in the port now:
+  1. **Heat** — the drive-heat integrator (#85, below).
+  2. **Vital death** — myomers are the ONLY `vital=1` subsystem in the authored records
+     (BTL4.RES `res+0x48` scan): destroying them KILLS the mech (the #80 vital-crit path).  This
+     is also the collision ram-death mechanism (myomers are a 0.35-weight rattle target).
+  3. **The assembly cap** — `RegisterMaxOutput @004b8ef0`: `mech+0x7A0 = max(cap,
+     AvailableOutput(topGear))` = base × ~1.4284, the gait rise-clamp both channels bound
+     against (part_012:12103/12334).  Port: each myomer registers per tick (idempotent max();
+     the 0x358 layout lock leaves no latch room) — state-identical to once-at-assembly.  The
+     old per-frame `reverseSpeedMax2 = reverseStrideLength` heal (which would have clobbered
+     it) is garbage-guarded only now.  `Mech+0x34C` (base) = port `reverseStrideLength`,
+     `Mech+0x7A0` (cap) = port `reverseSpeedMax2` — both documented misnomers.
+  4. **The ENG-page power curve** — SeekVoltageResponse, now at the correct absolute scale
+     (OwnerBaseSpeed reads the real base instead of the 1.0 stub).
+  5. **Electrical sourcing** — low seek gears keep the myomers runnable on a browned-out
+     generator (HasVoltage: `gear voltage <= measured`).
+  **Deliberately REMOVED (was an invention): the `speedDemand *= speedEffect` demand multiplier**
+  (mechmppr.cpp) and `BTMyomersDriveOf`.  Damaged-but-alive myomers heat faster and drop the
+  power curve but do NOT slow the mech — gitea #75's premise is falsified by the binary; the
+  mech's damage slowdown is the LEG-damage gimp gait, a separate live mechanism.  Seek gears do
+  NOT change speed (heat + sourcing + graph only).  Verified live: a mech with dmg=0.234
+  (speedEffect attr 0.766) beelines at full commanded speed with dmgGain=1.234 heat.
   **✅ MYOMER DRIVE HEAT LIVE (#85, 2026-07-31) [T2].** The five Mech motion operands of the
   drive-heat integrator `@004b8d18` were `return 0.0f` cross-family shims, so the (fully
   reconstructed) integrator accumulated `ratio² · damageGain · 0` every tick — myomers ice cold at