diff --git a/scratchpad/night14/solve137.py b/scratchpad/night14/solve137.py
new file mode 100644
index 0000000..2576130
--- /dev/null
+++ b/scratchpad/night14/solve137.py
@@ -0,0 +1,58 @@
+"""#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")