"""#137: post the clean mechanism write-up (the inline attempt was shell-mangled)."""
import sys
sys.path.insert(0, r"C:\git\bt411\scratchpad\night7")
import gitea

BODY = """*(Reposting -- the previous comment was mangled in transit. This is the readable version.)*

**MECHANISM SOLVED -- and it is not the respawn.** Controlled A/B on one bench, only the load differs:

| load | respawns | post-reset runaway |
|---|---|---|
| 0.95 throttle + continuous missile fire | 4 | **17 frozen samples, T climbs 77 -> ~11,600** |
| 0.50 throttle, no weapons | 2 | **0** |

Measured, not argued:

* **The reset works.** `T == startingTemperature` (77) at every single reset, in both runs.
  `HeatSink::RTIS @004ad760` does `param_1[0x45] = param_1[0x4f]`, and our port matches --
  additionally resetting `heatEnergy`, which it must, since the sim derives
  `currentTemperature = heatEnergy / thermalMass`.
* **The stale cache is real but harmless.** Nothing in the reset chain writes
  `Myomers::speedEffect` (@0x31C) -- `Myomers::RTIS @004b8aa4` only chains to the
  PoweredSubsystem one -- so it survives the reset reading 0. It self-heals on the very next
  tick (`T=77.13` -> `speedEffect=1`). Not the bug.
* **With ordinary load the myomers never approach `failT=2000` after a respawn.**

## What players are actually experiencing

Run hard -> myomers pass `failT=2000` -> the derating curve `@004b8ac0` returns 0.0 -> chain
MAX 0 -> `speedDemand *= 0` -> bogged down -> die, often *because* bogged down. The respawn
correctly resets to 77. Resume high throttle and firing and it climbs back over the cliff within
seconds -- which reads as "respawned with the heat bar maxed".

That also explains the intermittency (5 of 61 field respawns, ~8%): it tracks how hard you were
driving into and out of the respawn, not the respawn itself.

Oracle's "loop 5 and generator D heating up as all the excess heat goes into the loop" is
confirmed literally -- the myomers link to **Condenser5** (`mass=250000 k=190000`).

## The remaining defect: the climb RATE

Overshooting roughly 6x past a cliff the design treats as coolant-managed (`degradeT=1000`
governor onset, `failT=2000`) is not a lever a player can work with. That is the real ticket now.

Suspect under review, **not yet proven**: the kinetic term. The binary `@004b8d18` applies **no**
`time_slice` to it (`fVar5 * fVar1`), while the climb and accel terms both carry `param_2` -- i.e.
it is a per-frame energy add at the pod's fixed ~28 Hz. Our port rate-normalises it
(`work * (time_slice * 28)`), which agrees per-second at any frame rate, so this is not yet a
demonstrated discrepancy. Next step is a term-by-term dump (`BT_MYO_LOG`) against the authored
tuning: VelocityEfficiency 0.995, AccelerationEfficiency 0.8, thermalMass 2.5e5.

**Retitling suggestion:** this should stop being "respawn comes back hot" and become
"myomer heat rate under sustained load overshoots the failure cliff"."""

gitea.comment(137, BODY)
gitea.call("/issues/137", method="PATCH", payload={
    "title": "Myomer heat rate under sustained load overshoots the failure cliff (was: respawn came back with MYOMERS heat MAXED)"})
print("posted + retitled #137")