diff --git a/game/reconstructed/projweap.cpp b/game/reconstructed/projweap.cpp
index b05de0c..8b6964d 100644
--- a/game/reconstructed/projweap.cpp
+++ b/game/reconstructed/projweap.cpp
@@ -551,8 +551,8 @@ Logical
 	// so gate the roll on the weapon actually being in a degraded HEAT STATE (heatAlarm
 	// level >= 1) instead of the raw heatLoad.  In bring-up the alarm stays 0 (temp <<
 	// degradation threshold) -> weapons fire reliably; real jams return once the heat model
-	// drives true temps.  (FOLLOW-UP: make JammedState recoverable via an unjam delay so
-	// even a genuine overheat jam clears.)
+	// drives true temps.  (The old FOLLOW-UP suggesting an "unjam delay" is RETIRED --
+	// 2026-07-23 decomp check: the binary has NO in-mission unjam; permanence is authentic.)
 	if (heatAlarm.GetLevel() < HeatSink::DegradationHeat)		// was: if (heatLoad <= 0.0f)
 		return False;
 
@@ -776,7 +776,13 @@ void
 															// -- the recharge dial ANIMATES
 		break;
 
-	case 5:		// Jammed @4bbe8e -- cleared only by ResetToInitialState / msg 2
+	case 5:		// Jammed @4bbe8e -- cleared ONLY by ResetToInitialState (mission
+				// reset/respawn).  ⚠ CORRECTED 2026-07-23: msg 2 CAUSES a jam
+				// (HandleMessage @004bcabc: SetLevel(this+0x350, 5) -- a
+				// malfunction inducer), it does NOT clear one; the old comment
+				// had it backwards.  There is NO in-mission unjam in the
+				// binary -- the EJECT cycle (UpdateEject) is the anti-cook-off
+				// ammo JETTISON (DumpAmmo -> NoAmmo), not an unjam.
 		if (trigger)
 		{
 			weaponAlarm.SetLevel(TriggerDuringJamState);	// @4bbe95 blip 6