re: six runs with no arrival, and an accidental no-pilot control

wave6_probe refuses to interpret a run whose roster count is not the reproduced
baseline of 116, per the discard rule. This run passed and its first sample is
identical to the earlier link run: 116 records, 300 craft, 41 deployed, strength
histogram 2x24, 4x1, 8x4, 18x12. The deployment is deterministic at mission
start.

The pilot failed to bind, which accidentally supplied the control condition the
kill-versus-no-kill experiment needed. With nobody flying, not one craft was
destroyed in four minutes -- exactly 300 across all 22 samples -- against 16-20
losses in each piloted run. So losses are attributable to the player being in
the fight, and NPC crossfire destroys nothing by itself. That was an open
question two iterations ago.

Still no arrival. Zero 0 -> n transitions in either condition, across roughly
fifteen minutes of cumulative Stage 02 flight and windows up to 240 s. The 75
records holding no craft at mission start still hold none at the end. Against a
route table scheduling phase-1 arrivals at t = 90/120/170/210/240, that is now a
strong negative rather than a null result.

Three readings survive: the timetable's t is not seconds (at 30 Hz the whole
phase-1 schedule finishes inside 8 s, before any first sample); arrivals are
event-gated and no run supplied the trigger; or the mission is not advancing its
phase clock at all.

The third has never been checked and is the cheapest to eliminate, so it is now
the prime suspect. Nothing in six runs has confirmed that mission time advances:
the craft count freezes without a pilot, REMAINING OB has never read as a
counter, and no clock has been located. Every "no arrival" observation is
consistent with a scheduler that simply is not running, in which case the
arrival results so far are measuring a stopped clock.

docs/re/BACKLOG.md

@@ -353,7 +353,17 @@ search cannot find a *schedule*.
   distinct VAs (116 == 116), so the VA-aliasing explanation is 🔴 refuted too.
   🟡 The single 42/170 run stays unexplained; rule adopted: **discard a run that
   disagrees with 116 rather than interpreting it, and reproduce any finding in
-  ≥2 runs.** ❔ No arrival seen in any run yet.
+  ≥2 runs.**
+* ✅🔴 **Six runs, no arrival — plus an accidental control**
+  ([`mission-arrival-watch.md`](mission-arrival-watch.md), 2026-08-24). Deployment
+  reproduces byte-for-byte (116 records, 300 craft, 41 deployed, strengths
+  2×24/4×1/8×4/18×12). ✅ **Losses require the player**: an unpiloted run held at
+  exactly 300 craft for 240 s / 22 samples, vs 16–20 losses in each piloted run —
+  so NPC crossfire destroys nothing on its own. 🔴 **Zero `0→n` arrivals in either
+  condition**, ~15 min cumulative. ❔ **Prime suspect: the phase clock may not be
+  advancing at all** — never checked. **Next: find the mission timer** (HUD digits
+  or a fixed-rate counter); if it is stopped, every arrival result so far is
+  measuring a stopped clock.
   Earlier framing:
   [`mission-per-record-strength.md`](mission-per-record-strength.md) — one run
   gives 116 records/300 craft, the next 42/170, same disc, save and script. Save

docs/re/mission-arrival-watch.md

@@ -0,0 +1,70 @@
+# Six runs, no arrival — and an accidental control
+
+Status: ✅ the deployment structure reproduces exactly; ✅ losses require the
+player; 🔴 **no arrival has ever been observed**, across six runs; ❔ whether
+mission/phase time is advancing at all is now the prime suspect and is untested.
+
+## ✅ The deployment structure reproduces byte-for-byte
+
+`tools/re-capture/wave6_probe.py` refuses to interpret a run whose roster count
+is not the reproduced baseline of 116 (the discard rule from
+[mission-per-record-strength.md](mission-per-record-strength.md)). This run
+passed, and its first sample is *identical* to the earlier link run:
+
+```
+roster records: 116     craft=300     deployed=41/116
+strengths [(2, 24), (4, 1), (8, 4), (18, 12)]
+```
+
+Same 41 deployed of 116, same discrete strength histogram, same total. The
+deployment is deterministic at mission start.
+
+## ✅ Losses require the player — an accidental control run
+
+The pilot failed to bind this run (`BIND FAILED, no pilot`), so the craft sat
+unattended. That is the control condition the kill-versus-no-kill experiment
+needed, and it arrived by accident:
+
+| condition | duration | losses |
+|---|---|---|
+| hunting pilot | 168 s | 300 → 288 |
+| hunting pilot | 168 s | 296 → 280 |
+| **no pilot** | **240 s** | **300 → 300, zero** |
+
+With nobody flying, **not one craft was destroyed in four minutes** — the count
+held at exactly 300 for all 22 samples. So the 16–20 losses in the piloted runs
+are attributable to the player being in the fight, and **NPC crossfire does not
+by itself destroy anything**. That was an open question two iterations ago and
+it is now answered.
+
+## 🔴 No arrival, in either condition, in six runs
+
+Zero `0 → n` transitions. Not with a hunting pilot, not without one, across
+roughly fifteen minutes of cumulative Stage 02 flight and windows up to 240 s.
+The 75 records that hold no craft at mission start still hold none at the end.
+
+Set against `Route_S02.tbl`, which schedules phase-1 arrivals at
+t = 90, 120, 170, 210, 240 in groups of 3, 3, 3, 2, 1, this is now a strong
+negative rather than a null result. Three readings survive:
+
+1. **The timetable's `t` is not seconds.** At 30 Hz the whole phase-1 schedule
+   completes inside 8 s — before any probe's first sample — and everything that
+   was going to arrive already had.
+2. **Arrivals are event-gated** and no run supplied the trigger. The control run
+   supplied nothing at all; the piloted runs killed 16–20 craft, which may be
+   below a threshold or of the wrong squadrons.
+3. **The mission is not advancing its phase clock**, so no schedule ever fires.
+
+## ❔ The prime suspect is now (3), and it is untested
+
+Nothing in six runs has confirmed that mission or phase time is advancing at
+all. The craft count is frozen without a pilot; `REMAINING OB` has never read as
+a counter; no clock has been located. Every "no arrival" observation is
+consistent with a mission whose scheduler is simply not running under these
+conditions — and that possibility has never been checked, which makes it the
+cheapest thing to eliminate next.
+
+**Next: find the mission timer.** The HUD shows elapsed mission time, so a
+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.