re: long run — a squadron ground 18 to 2, still no arrival

The per-record instrument works and resolves individual squadrons. Over 240 s
with the hunting pilot, seven loss events all landed on the same record,
tracking one e007 Turret squadron from 18 craft down to 2 while deployed held at
41 and the global count fell 300 to 284. Losses come in steps of 2 after an
opening drop of 4, which is unexplained and recorded rather than smoothed over.

This weakens the frame-rate explanation from the previous iteration. At ~16.5
fps against a 30 Hz tick, game time runs at about 55 % of wall-clock, so route
entries t = 90 and t = 120 land near 163 s and 218 s wall. The run reached 234 s
wall, roughly 129 game-seconds, passing both, and no arrival occurred at either.
"The runs were too short" no longer covers t = 90 and t = 120, though it still
covers 170, 210 and 240 -- the run was cut at 240 s by the turn timeout rather
than the planned 330 s, so t = 170 was never reached.

It also sharpens the event-gated model into something testable. The squadron
ended at 2, not 0, and no squadron has been eliminated in any run so far. If the
trigger is a squadron being wiped out rather than merely damaged, every
observation to date is explained: seven kills produced no arrival because they
never finished anything off.

Next is the cheapest decisive experiment yet available: run 60-90 s longer so
that squadron reaches zero and watch for a 0 -> n in the following samples. The
~210 s title movie at boot remains the binding constraint, leaving about 350 s of
observation per turn.

docs/re/BACKLOG.md

@@ -366,9 +366,16 @@ search cannot find a *schedule*.
   **16.5/s**, which is the emulator's known ~14–19 fps. 🟡 New leading
   explanation: **the runs were far too short in GAME time** — at ~55% of
   wall-clock, the longest 240 s run reached only t≈132, past the t=90/120 route
-  entries but nowhere near t=170/210/240. **Next: one long run** (~350 s probe)
-  watching for `0→n` near t≈163 s and 218 s wall. If still nothing, the
-  frame-rate explanation is refuted and event-gating returns as front-runner.
+  entries but nowhere near t=170/210/240. ✅🔴 **Long run done (2026-08-24)**: per-record tracking
+  works — watched ONE turret squadron fall **18→14→12→10→8→6→4→2** over seven
+  loss events while `deployed` held at 41. 🔴 **Still no arrival at 234 s wall
+  (≈129 game-s), past both t=90 and t=120**, so the "too short" explanation no
+  longer covers those (it still covers t=170/210/240; the run was cut at 240 s by
+  the turn timeout, not the planned 330 s). 🟡 **Sharper hypothesis:** the
+  squadron ended at **2, never 0** — no squadron has ever been eliminated in any
+  run, so the trigger may be *elimination*, not damage. **Next: run ~60–90 s
+  longer so that squadron reaches 0, and watch for `0→n`** — a direct test of the
+  event-gated model.
   ⚠️ The ~210 s title movie at boot is the binding constraint on observable game
   time per turn.
   Earlier framing:

docs/re/mission-arrival-watch.md

@@ -68,3 +68,64 @@ cheapest thing to eliminate next.
 digit-recognition read of the clock region, or a memory scan for a counter that
 advances at a fixed rate, would settle whether phase time moves. If it does not,
 every arrival conclusion so far is measuring a stopped clock.
+
+---
+
+# Long run: a squadron ground 18 → 2, still no arrival (2026-08-24)
+
+Status: ✅ per-record tracking works and resolves individual squadrons; 🔴 the
+frame-rate "runs were too short" explanation is **weakened**; 🟡 a sharper
+event-gating hypothesis now has a specific test.
+
+## ✅ The instrument works — one squadron watched down to 2
+
+240 s with the hunting pilot, sampling every ~15 s:
+
+```
+t= 54s  loss  UN_e007_ADAN_Turret  18 -> 14
+t= 89s  loss  UN_e007_ADAN_Turret  14 -> 12
+t=106s  loss  UN_e007_ADAN_Turret  12 -> 10
+t=124s  loss  UN_e007_ADAN_Turret  10 ->  8
+t=139s  loss  UN_e007_ADAN_Turret   8 ->  6
+t=172s  loss  UN_e007_ADAN_Turret   6 ->  4
+t=209s  loss  UN_e007_ADAN_Turret   4 ->  2
+```
+
+Seven loss events, **all on the same record**, tracking one squadron's strength
+from 18 down to 2 while `deployed` held at 41 and the global craft count fell
+300 → 284. This is the squadron-resolved signal the last several iterations were
+building toward, and it behaves exactly as the link predicts.
+
+Losses come in steps of 2 (after an opening −4), which is unexplained and worth
+noting rather than smoothing over.
+
+## 🔴 The frame-rate explanation is weakened
+
+[mission-clock-advances.md](mission-clock-advances.md) proposed that six empty
+runs were simply too short: at ~16.5 fps against a 30 Hz tick, game time runs at
+about 55 % of wall-clock, so t = 90 and t = 120 of the route timetable would land
+at roughly **163 s and 218 s wall**.
+
+This run reached **234 s wall ≈ 129 game-seconds**, passing both. **No arrival
+occurred at either point.** So "the runs were too short" no longer covers t = 90
+and t = 120, though it still covers t = 170, 210 and 240.
+
+The run was cut at 240 s rather than the planned 330 s — the turn's timeout fired
+first. Stated plainly because it means t = 170 was never reached.
+
+## 🟡 A sharper hypothesis, with a clean test
+
+The squadron ended the run at **2 craft, not 0**. If arrivals are event-gated as
+the user proposed, the trigger may be a squadron being *eliminated* rather than
+merely damaged — and no squadron has ever reached zero in any run. That fits
+every observation so far: seven kills produced no arrival because they never
+finished anything off.
+
+**Test:** run long enough for that turret squadron to reach 0 and watch whether a
+`0 → n` follows within the next samples. It fell 18 → 2 in 240 s, so roughly
+another 60–90 s of the same pilot behaviour should finish it. This is now the
+cheapest decisive experiment available, and it is a direct test of the
+event-gated model rather than another null result.
+
+The binding constraint remains the ~210 s title movie at boot, which leaves only
+about 350 s of observation per turn.