KB: autocannon jam/coolant -- SOLVED from decomp, QA behavior CONFIRMED faithful

Reproduced the QA report end-to-end from the decomp + raw-binary-verified constants.
The coolant-priority effect is real but fire-rate-dependent: at the ~11s combat
cadence, not-boosted jams (T=1058>1000) while boosting the AFC's condenser keeps it
below the line (T=953, no jam) -- exactly as the QA described. Max-spam (8s) overheats
regardless (why the earlier 'weak boost' read was wrong); 16s never jams. All AFC100
constants verified authentic vs BTL4.RES raw bytes (afc_dump.py). No bug, no stand-in.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

context/open-questions.md

@@ -413,32 +413,32 @@ register.  ⚠ The audit also flags the damage-economy item as SELF-CONTRADICTOR
   under reconstruction: config-mode regrouping (task #6), generator reassignment (ids 4-8),
   coolant valves.
 
-- **AUTOCANNON JAM / coolant-priority — mechanism FAITHFUL + COMPLETE; a CALIBRATION question
+- **✅ AUTOCANNON JAM / coolant-priority — FAITHFUL + CONFIRMED against QA ground-truth, SOLVED
-  pending QA ground-truth (2026-07-14) [T1 mechanism / T3 pacing].** An original QA dev reports:
+  purely from the decomp (2026-07-14) [T1/T2].** An original QA dev reported: "all AFCs jam on their
-  "all AFCs jam on their 3rd shot if coolant priority isn't boosted; boosted → almost never jam."
+  3rd shot if coolant priority isn't boosted; boosted → almost never jam." VERDICT: the whole chain
-  Full decomp hunt (2 agents) confirms the whole chain is reconstructed end-to-end and the port is
+  is reconstructed end-to-end, FAITHFUL, and reproduces the reported behavior — no bug, no stand-in.
-  FAITHFUL — **do NOT "fix" it by driving a weapon's `coolantFlowScale` from the valve; that field
+  **DO NOT "fix" it by driving a weapon's `coolantFlowScale` from the valve; that field being a
-  being a constant 1.0 for weapons is AUTHENTIC** (the ONLY writer of any HeatSink `+0x15C` from a
+  constant 1.0 for weapons is AUTHENTIC** (the ONLY writer of any HeatSink `+0x15C` from a valve value
-  valve value is `RecomputeCondenserValves`/FUN_0049f788, which iterates ONLY the condenser chain
+  is `RecomputeCondenserValves`/FUN_0049f788, which iterates ONLY the condenser chain `mech+0x7cc`).
-  `mech+0x7cc`). Authentic mechanism: a weapon dumps `heatCostToFire` (AFC100=6.5e7 raw) into its
+  Mechanism: a weapon dumps `heatCostToFire` (AFC100=6.5e7 raw) into its OWN linked condenser (AFC100→
-  OWN linked condenser; the condenser sheds to the shared bank at a rate scaled by its valve SHARE
+  Condenser4); the condenser sheds to the shared bank at a rate scaled by its valve SHARE
-  (`coolantFlowScale = valveState_i / Σ valveState`, MoveValve msg id 4, detents 1/5/50/0). Boosting
+  (`coolantFlowScale = valveState_i / Σ valveState`, MoveValve msg id 4, detents 1/5/50/0). The
-  ONE condenser's valve (share ~0.17→~0.9 = ~5× conductance) drops its equilibrium temp so the
+  weapon's OWN thermal conductance (35500) caps how fast it sheds into its condenser, so coolant
-  weapon dumping into it stays below `degradationTemperature`(1000) → `heatAlarm`=0 → CheckForJam
+  priority shifts the weapon's equilibrium only ~100 K — but that is EXACTLY enough to straddle the
-  early-returns → no jam. Starved → condenser saturates → weapon crosses 1000 → the STICKY
+  `degradationTemperature`(1000) jam line at combat fire rates. Cross `1000` → `heatAlarm`≥1 → the
-  probabilistic jam (`p=clamp(0.41·T/failT,0.05,1)`, JammedState 5, clears only on ResetToInitialState)
+  jam roll arms (`p=clamp(0.41·T/failT, 0.05, 1)`); on a hit → sticky `JammedState`(5), clears only on
-  latches. Two distinct "jam" states: **degradation 1000 → probabilistic sticky jam** (the pilot's
+  ResetToInitialState. (Distinct: `failureTemperature`(2000) → self-clearing overheat lockout,
-  "jam"); **failure 2000 → deterministic self-clearing overheat lockout** (recoil-pinned + weaponAlarm 7,
+  recoil-pinned + weaponAlarm 7.) **ALL constants VERIFIED AUTHENTIC vs the raw BTL4.RES bytes**
-  re-fires each frame until it cools). ALL thermal constants load strictly from the resource (no
+  (`scratchpad/afc_dump.py`): AFC100 startT=77, degradT=1000, failT=2000, thermalConductance=35500,
-  stand-in fallback — a missing value ERRORS). **Empirical (BT_JAM_LOG/BT_VALVE, madcat AFC100):**
+  thermalMass=94700, heatCostToFire(+0x1A4)=6.5e7, recharge(+0x190)=8, damage=25, minJamChance=0.05 —
-  uncooled the weapon crosses 1000 at ~shot 4 and PLATEAUS ~1400 (conduction balances input), giving
+  no mis-scaling. **THE ANSWER IS FIRE-RATE-DEPENDENT** (measured, BT_JAM_LOG/BT_VALVE_BOOST/BT_AF_PERIOD,
-  ~25% probabilistic jam — directionally right but NOT the QA's deterministic "3rd shot". Gap is
+  madcat AFC100 → Condenser4): at MAX spam (8s recharge) the AFC overheats regardless (~1460 boosted
-  calibration (condenser thermalMass/conductance live in LAST.EGG, unread) + scenario (fire rate;
+  ~1360 — both jam); at a SLOW cadence (16s) it plateaus ~770 and never jams; at the ~11s COMBAT cadence
-  which condenser boosted — a uniform BT_VALVE is normalized away, need a targeted per-condenser
+  it is DECISIVE — **not boosted → 1058 K (jams), boosted (Condenser4 valve→50, others→1) → 953 K (never
-  boost). NEXT: get QA to clarify (a) deterministic lockout vs probabilistic jam, (b) per-weapon vs
+  jams)**. So the QA is right and the reconstruction is faithful; the earlier "boost is weak" read was
-  global coolant boost + which control; THEN verify calibration — do NOT tune the heat economy to
+  an artifact of testing at max spam (above the window). Diag probes committed: `BT_JAM_LOG`
-  force "3rd shot" without ground-truth (would be un-faithful). Diag probes committed: `BT_JAM_LOG`
+  (projweap.cpp), `BT_VALVE`/`BT_VALVE_BOOST=<condenserNum>` (heatfamily_reslice.cpp), `BT_AF_PERIOD=<sec>`
-  (projweap.cpp), `BT_VALVE` (heatfamily_reslice.cpp). See [[combat-damage]], [[subsystems]] heat.
+  (mech4.cpp). See [[combat-damage]], [[subsystems]] heat.
 
 - **Subsystem-panel online/offline gate — fields unidentified [T4] (2026-07-12).** The binary's
   SubsystemCluster draw-state reads `*(subsystem+0x40)==1` and `*(subsystem+0x278)!=4`; neither