diff --git a/docs/re/script-runtime-probe.md b/docs/re/script-runtime-probe.md
index dd4a36fd..99d65270 100644
--- a/docs/re/script-runtime-probe.md
+++ b/docs/re/script-runtime-probe.md
@@ -476,3 +476,45 @@ That leaves the third candidate: **the anomalous run's mission never loaded**,
 and its `IN FLIGHT` was a misdetection. Consistent with what became of it — it
 was **frozen on a black screen** when checked afterwards. Not proven, but it is
 now the only surviving explanation rather than one of three.
+
+## 🔴 WITHDRAWN: "the condition coroutine is not polling"
+
+That explanation — promoted to "real evidence" after the poke experiments — is
+**wrong**. Tracing Stage 02 phase 1 by **control flow** (following op 12 jumps
+and the six conditional branches, not linear decode) gives the whole chain:
+
+```
+timer5 @ 4.0s  -> trigger 0x2D30   (timer_set(1200,180); timer_resume; set_flag(0))
+               -> start_coroutine at 0x2FE8
+               -> coroutine 0xBB9C :  wait_s(0.2) ; builtin103 ; yield ; unit_hp_pct(TCN001,…)
+               -> … -> 0xF524 :       unit_state(ADN110/111/112) -> set_flag(8)
+```
+
+**Exactly one** of phase 1's 79 coroutine entries reaches `0xF524` under a real
+control-flow walk, and its body is a **`wait_s(0.2)` loop**. So the condition is
+polled at **5 Hz**, from 4 seconds into the phase — the opposite of what I
+concluded.
+
+⚠️ Two weaker methods gave the wrong answer first, and both are worth naming:
+*linear decode* fell through into unrelated code and implicated 30-odd entries;
+*"nearest preceding entry"* implicated `0xBB9C` only by luck of proximity
+(`0x3988` bytes away). Only following branches settles containment.
+
+⚠️ I also matched `start_coroutine` operands **across phases** at first, which is
+meaningless — the operand is relative to `[phase+232]`, which differs per phase.
+Same trap that broke `isl.py`'s jump targets, hit again three iterations later.
+
+### 🟡 So why did the pokes do nothing? A different explanation is needed
+
+With the polls running at 5 Hz, "nobody was looking" is out. The likeliest
+remaining reason is that **neither poke produced the state the predicate tests**:
+
+* `+16` — built-in 69 never reads it (established at `0x8226ADF0`);
+* `+4 = 0` — that takes the handler's **early-exit** path, which is the same
+  branch an *undeployed* unit takes. The script very likely reads that as "not
+  here" rather than "destroyed".
+
+**This is a hypothesis, not a finding.** What would settle it: read what built-in
+69 returns for a genuinely destroyed squadron versus a zeroed handle — the run
+that caught `ADN111` dying naturally at 433 s is the reference, and its record is
+the thing to compare against.