Sylpheed/docs/re/mission-arrival-watch.md

# Six runs, no arrival — and an accidental control

> 🔴 **SUPERSEDED 2026-08-25 — the premise was an instrument limit, not a fact
> about the game.** Arrivals *do* happen and are directly observable in the
> script VM's per-unit table: ADN110/111/112 flip from "not deployed" to
> "active" at ~143 s, matching their routes' `t=170` timetable entry, while the
> count of active records climbs 24 → 35 in four minutes. Everything below
> remains accurate about **craft counting**, which conflates deployment with
> attrition and cannot see an arrival. See
> [script-runtime-probe](script-runtime-probe.md) and
> [mission-wave-arrivals](mission-wave-arrivals.md).

Status: ✅ the deployment structure reproduces exactly; ✅ losses require the
player; ~~🔴 no arrival has ever been observed~~ — **superseded, see the banner above**;
the "is mission time advancing at all?" suspicion is also answered: it is, and
the timetable is in seconds.

## ✅ 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.

---

# 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.

---

# Player death bounds every run — and a harness bug (2026-08-24)

Status: 🔴 a harness bug means earlier windows were shorter than reported;
✅ a record reaching 0 was observed for the first time; ✅ **after the player
dies the mission is completely static**, so observation is bounded by survival,
not by probe duration; 🔴 the elimination test did not complete.

## 🔴 Correction: the previous run was not "cut by the turn timeout"

The `sed` used to derive each session script from the last stripped the probe's
arguments, so line 14 of `wave5/census/wave6_session.sh` invoked the probe with
**no arguments at all**. Every derived probe has been running on its own
defaults, ignoring the durations passed on the command line.

So the previous iteration's claim that the run "was cut at 240 s by the turn
timeout, not the planned 330 s" is **wrong**: the probe simply used its default
of 240 s. The pilot received the requested 330 s while the probe watched for 240,
a mismatch that went unnoticed because the numbers were plausible.

No earlier conclusion is invalidated — the windows were real, just shorter than
intended and misattributed. Fixed: all three sessions now pass `"$SECS" "$EVERY"`.

## ✅ First observed `n → 0`: the player

```
t= 83s  loss  UN_f001_TCAF_DeltaSaber_T_Player  2 -> 0
        loss  UN_e007_ADAN_Turret               18 -> 16
        loss  UN_e007_ADAN_Turret               18 -> 14
```

`deployed` fell 41 → 40. This is the first time in eight runs that any record has
reached zero, and it confirms the signal registers elimination, not just damage.

**No arrival followed.** That is weak evidence at best against the
squadron-elimination trigger, since the record eliminated was the *player*, not
an enemy squadron.

Two other turret records dropped from 18 in the same sample, which is noted
without interpretation — it may be the death explosion, or simply three changes
landing in one 13 s bucket.

## ✅ The real constraint: nothing happens after the player dies

For the remaining **220 seconds** the mission was frozen: craft held at exactly
288, zero losses, zero arrivals, across 18 consecutive samples.

That reframes every run in this file. **The usable observation window is not the
probe duration — it is however long the player survives.** A 340 s probe that
loses its pilot at 83 s yields 83 s of evidence and 257 s of nothing. Several
earlier "no arrivals over 240 s" results may have been much shorter in practice
than they appear.

It also explains why `pilot.py` was written to survive rather than to shoot: the
`SYLPH_HUNT=1` mode added two iterations ago drops `TURRET_KEEPOUT` from 2500 to
600, which buys kills at the cost of exactly the survival the run depends on.

## 🔴 The elimination test did not complete

The target squadron reached 14, not 0, before the pilot died. The test — does
wiping out an enemy squadron release a wave — remains **unrun**.

## What is needed

A pilot that kills *and* survives. The two existing modes sit at opposite
extremes: survival mode kills nothing in 240 s, hunt mode kills steadily and dies
at 83 s. A middle setting — hunt turrets but keep the evade/retire behaviour, or
a keep-out between 600 and 2500 — is the obvious next step, and it is a tuning
change rather than a new discovery.

---

# ✅ The elimination test ran — and refutes the elimination trigger (2026-08-24)

Status: ✅ an enemy squadron was wiped out and observed; 🔴 **no arrival
followed**, so "a wave is released when a squadron is eliminated" is refuted for
this case; ✅ the keep-out tuning gave a surviving pilot that still kills;
🔴 the guest stalled late in the run, which bounds the valid window and is now
detected automatically.

## ✅ The tuning worked

`SYLPH_KEEPOUT` makes the hunt keep-out a knob rather than a hard-coded 600.
At **1400** the pilot both kills and survives — hull 1500 and escorted asset
100 % for the entire run, `ENGAGE` throughout, 8 loss events against 7 in the
run where it died at t = 83 s.

## ✅ An enemy squadron reached zero

```
t= 30s  loss  UN_e007_ADAN_Turret       18 -> 10
t= 44s  loss  UN_e007_ADAN_Turret       10 ->  8
t= 96s  loss  UN_e007_ADAN_Turret        8 ->  4
t=124s  loss  UN_e007_ADAN_Turret        4 ->  2
t=150s  loss  UN_e010_ADAN_Attacker_S    8 ->  6
t=163s  loss  UN_e007_ADAN_Turret        2 ->  0     <-- ELIMINATED, deployed 41 -> 40
t=176s  loss  UN_f106_TCAF_Destroyer     4 ->  2
t=202s  loss  UN_e007_ADAN_Turret       18 -> 16
```

An enemy squadron destroyed outright, for the first time in nine runs.

## 🔴 No arrival followed — the elimination trigger is refuted

`ARRIVALS=0` at every sample, including all of those after t = 163. The
hypothesis from the previous iteration — that a wave is released when a squadron
is *wiped out* rather than merely damaged — does not survive its first test.

**The window matters and is smaller than it looks:** valid observation after the
elimination is about **90 seconds**, not the 143 s the log appears to show, for
the reason below. Within that 90 s two further losses occurred (t = 176, t = 202),
so the mission was demonstrably still live and still processing kills — it simply
produced no arrival.

This refutes elimination-of-one-squadron as *the* trigger. It does not refute
event-gating generally: a threshold across several squadrons, an objective
completion, or a specific squadron could all still be the gate.

## 🔴 The guest stalled at ~t = 255 s, and flat samples look identical to a quiet mission

The pilot's own telemetry gives it away: the **last 400 log lines contain one
distinct speed value, against 236 in the first 400**, with no timestamp gaps.
The process kept logging; the game stopped advancing.

Every sample after roughly t = 255 s is therefore a frozen guest, not a quiet
mission — and nothing in the probe's output distinguished the two. The same
ambiguity affects any earlier run's trailing flat samples.

**Fixed:** `wave6_probe.py` now locates a counter that advances at frame rate
(the technique from [mission-clock-advances.md](mission-clock-advances.md)),
samples it every tick, and prints `*** GUEST STALLED ***` when it fails to
advance. This makes every future run self-validating. It is implemented but has
**not yet run**, so it is unverified.

## What is still open

* Whether any event gates arrivals — elimination of a single squadron is out,
  but thresholds, objectives and specific squadrons are untested.
* Whether an arrival is observable at all. Nine runs, zero `0 → n`.
* Re-examining earlier "flat" results now that a stall and a quiet mission are
  known to look the same.

---

# The first apparent arrival is flicker, not a wave (2026-08-24)

Status: 🔴 the single `0 → 2` observed on the cheap probe is **not** accepted as
an arrival; ✅ the reason is visible in the same log; ✅ the probe now requires
persistence.

The first run with cheap sampling reported one arrival:

```
t=229s  loss  UN_e007_ADAN_Turret  1 -> 0
t=259s  ARRIVAL UN_e007_ADAN_Turret  0 -> 2
t=274s  loss  UN_e007_ADAN_Turret  2 -> 0
```

Two craft appearing and vanishing again within 15 s is not what a wave looks
like. **The same log contains the giveaway:** at t = 60 s a record read **13**, and
at t = 75 s the same record read **14** — an *increase* — with no event printed,
because the probe only surfaced decreases. The hull-based liveness read
flickers, and a flicker that happens to straddle zero is indistinguishable from
an arrival under the old rule.

So the count is **0 confirmed arrivals**, in eleven runs.

## The rule this produces

An increase from zero counts only if it **persists across two consecutive
samples**, and every increase is now printed, not just those from zero. A
candidate that returns to zero at the next sample is discarded as flicker. Both
changes are in `wave7_probe.py`; **neither has run yet.**

Had the old rule stood, this run would have been written up as "first arrival
observed" — the strongest-looking result of the whole line of work, and wrong.

---

# Run 12: the persistence rule does its job (2026-08-24)

16 losses over 290 s with a bound pilot, and:

```
TOTAL candidate-up=0 down=16 CONFIRMED arrivals=0
```

One increase was surfaced — `UN_e007_ADAN_Turret 13 -> 15` — and correctly **not**
counted, because it does not start from zero. Under the pre-fix rule it would
have been invisible; under the old *arrival* rule a similar flicker straddling
zero was nearly written up as the first arrival. The new "print every increase"
behaviour makes the flicker visible as flicker.

**Still zero confirmed arrivals, now across twelve runs.**

Caveat on this run: its 13 "stalled" flags are false positives from the
single-word witness (see [guest-stalls.md](guest-stalls.md)), so the run was
healthy — but that also means the witness cannot yet certify it.

---

# Run 16: the first trustworthy negative (2026-08-24)

Every previous "no arrival" result carried a caveat — a stalled guest, an
unvalidated witness, a probe degrading the thing it measured. This one does not:

* the stall witness is validated (zero contradictions with loss data);
* it reported **no stall on any sample**;
* the guest was demonstrably live throughout — 8 losses spread across the run;
* the run ended on the turn timeout, not a freeze.

**Result: 0 confirmed arrivals over 210 s of verified-live Stage 02 flight.**

That is the first observation in this line of work that means what it says. It
does not settle the question — 210 s of wall-clock is roughly 115 s of game time
at the measured frame rate, so the route table's t = 170/210/240 entries are
still out of reach — but it does establish that **nothing arrives in the first
~115 game-seconds of Stage 02 phase 1 while the player kills eight craft**.

One flicker `up` was surfaced and correctly not counted.

Sixteen runs, still no arrival. The difference is that this one is evidence.

---

# Run 17: the clean result reproduces, and the window is being eaten by startup

## ✅ Reproduced (n = 2)

```
tick witnesses: 4584 candidates, using 32 at 11/s
t=  0s … t=240s   no stall flag on any sample
9 losses, 4 flicker `up` events (none from zero), 0 confirmed arrivals
```

Second consecutive run with no stalls, confirming that disabling the periodic
rescan is what fixed the freezes. The trustworthy negative now extends to
**240 s of verified-live flight ≈ 132 game-seconds**, past the route table's
t = 90 and t = 120 entries with nothing arriving.

Four increases were surfaced and all correctly rejected — the flicker rate is
substantial, roughly one per minute, which is exactly why the persistence rule
matters.

## 🔴 Startup costs ~100 s of a ~350 s budget

The arithmetic does not add up unless something slow sits between them: boot
finished at 249 s, the probe ran 240 s, and the turn's 595 s cap fired. That
leaves about **100 s unaccounted for** — the witness calibration plus the initial
craft enumeration.

`enumerate_craft` was iterating **every 4-byte word of 32 MB in Python**, 8
million steps, to find 14 fixed needles. Replaced with `bytes.find()` per
definition VA, which is the same search at C speed and is what the vtable scan
already did.

If that recovers most of the 100 s, the observation window grows from ~240 s to
~340 s — about **187 game-seconds**, which would finally reach the **t = 170**
route entry. Not yet run.

---

# 🚧 BLOCKER: two of the schedule's entries are unreachable in one turn (2026-08-24)

This should have been computed several iterations ago instead of being
approached one run at a time.

A turn's shell call is capped at 595 s. Boot costs ~220 s (a ~190 s title movie
that cannot be tapped through plus ~35 s to flight) and probe startup ~25 s,
leaving **~350 s of observation**. At the measured ~55 % of real-time, that is
**~193 game-seconds**.

| route entry | wall-clock needed | status |
|---|---|---|
| t = 90 | 164 s | ✅ reachable — observed, no arrival |
| t = 120 | 218 s | ✅ reachable — observed, no arrival |
| t = 170 | 309 s | ✅ reachable, but only on a run that does not freeze |
| **t = 210** | **382 s** | ❌ **out of reach in one turn** |
| **t = 240** | **436 s** | ❌ **out of reach in one turn** |

So the tail of Stage 02's phase-1 schedule cannot be tested under the current
harness at all, however many runs are attempted. Recorded as a blocker rather
than worked around.

**What would unblock it,** neither of which is mine to decide:

1. **Skip the title movie.** It is ~190 s of the 220 s boot — more than half the
   budget — and `launch_mission.sh` waits it out because tapping breaks the
   title. If there is a safe skip, the window roughly doubles to ~540 s ≈ 297
   game-seconds, which covers every entry including t = 240.
2. **A longer shell timeout**, if the harness allows it.

## This run: discarded

Frozen at t = 90 s, 15 stalled samples, 3 losses. Correctly flagged and not
interpreted. Freeze tally is now **3 clean of 5** (210, 240, 300 clean; 60, 90
frozen), lower than the 3-of-4 quoted last iteration.

## What stands

**0 confirmed arrivals over 300 s of verified-live flight (~165 game-seconds)**,
covering the t = 90 and t = 120 route entries. That is unchanged, and it is the
strongest statement this harness can currently support.

---

# ✅ BLOCKER REMOVED: the emulator survives between calls (2026-08-24)

The previous entry declared t = 210 and t = 240 unreachable because a shell call
is capped at 595 s. **That was wrong, and it rested on an assumption I never
tested:** `launch_mission.sh` leaves the emulator running, and it survives
*between* Bash calls within a turn — checked directly, 611 s elapsed and still
running after the launching call had returned.

So observation is not capped by one call. `tools/re-capture/attach_session.sh`
attaches a pilot and probe to an already-running mission, and attaches can be
chained.

## The result on one continuous mission

| segment | window | stalls |
|---|---|---|
| initial run | 300 s | none |
| attach | 540 s, first stall at t = 135 s | frozen after |

**Cumulative verified-live: 435 s of wall-clock**, during which the craft
population fell **300 → 258** (42 destroyed) and `deployed` fell 41 → 38.

```
TOTAL candidate-up=0 down=8 CONFIRMED arrivals=0
```

**0 confirmed arrivals**, across the longest verified-live observation yet.

| route entry | wall needed | covered? |
|---|---|---|
| t = 90 | 164 s | ✅ |
| t = 120 | 218 s | ✅ |
| t = 170 | 309 s | ✅ |
| **t = 210** | **382 s** | ✅ |
| t = 240 | 436 s | ✗ (one second short) |

Four of five phase-1 arrival times passed with nothing arriving while 42 craft
were destroyed.

## 🟡 The coverage claim is sensitive to an assumption

The wall→game conversion uses 55 %, from a ~16.5 /s frame rate against an assumed
30 Hz tick. But the witness has measured **8, 11, 11, 21 and 24 /s** across runs —
a 3× spread. At the low end the factor is 0.27, and the same 435 s covers only
~117 game-seconds, which would reach **t = 90 only**.

So the honest statement is: **nothing arrived in 435 s of verified-live Stage 02
phase-1 flight with 42 kills**, which covers the first four route entries *if*
the game runs at ~55 % of real-time and only the first *if* it runs at the
slowest rate observed. Pinning the tick rate is now the thing that would make
this result sharp.

## 🔴 Refuted: the pilot's poll rate is not what limits frame rate

`SYLPH_HZ=3` (down from 8) produced the **lowest** calibrated rate of any run,
8 /s, alongside the most kills (26). So the pilot's polling is not the throttle,
and lowering it is not a way to buy game time. n = 1.

---

# 🟡 The route times are almost certainly FRAMES — and the "42 anomaly" was Stage 01

## ✅ The 42-record anomaly is solved: it is a different stage

The rescan-until-baseline retry settled it — five rescans over 50 s, stuck at 42,
so not a load race. Inspecting the live mission instead of guessing:

* records include `UN_S01_Asteroid_cmesh_01a/01b/02a/…` — Stage 01 asteroids;
* `UnitGroup_S01.tbl` is resident in guest RAM, `UnitGroup_S02.tbl` is **not**.

**The launch sometimes loads Stage 01 instead of Stage 02.** The discard rule
caught every one of those runs, which is why they never contaminated a result.

## ✅ And that supplied the missing refutation test, for free

`mission-liveness-probe.md` recorded the roster identity as blocked: the obvious
check — a *different* stage's record count against its member sum — needed a save
we do not have. Stage 01 loading by accident provides it:

| | static (disc) | live (RAM) |
|---|---|---|
| members / roster records | **42** | **42** |
| distinct unit types / definitions | **13** | **13** |
| `UN_e007_ADAN_Turret` | 20 | 20 |
| `UN_f001_TCAF_DeltaSaber_T` | 6 | 6 |
| `UN_e010_ADAN_Attacker_S` | 5 | 5 |
| `UN_e106_ADAN_Destroyer` | 2 | 2 |

One record per roster member now holds on **two independent stages** with
completely different rosters.

## 🟡 Stage 01's timetable says the unit is frames, not seconds

```
Stage 01 phase 1:  t=0:15, t=40:3, t=70:2, t=80:1, t=110:1, t=140:1
Stage 01 phase 2:  t=0:17, t=1500:1, t=1800:3, t=2100:4
```

**t = 2100 as seconds is 35 minutes into a single phase**, and 1500/1800/2100
would be three arrivals spread over the last ten minutes of it. That is not a
plausible mission. At 30 Hz they are **50, 60 and 70 seconds**, which is exactly
the shape of a paced phase.

If the unit is frames at 30 Hz, then Stage 02's phase-1 entries at
t = 90/120/170/210/240 are **3, 4, 5.7, 7 and 8 seconds** — every one of them
before the probe's first sample, which lands ~25 s after flight is detected.

**That would explain every null result in this file at a stroke**, and it is
consistent with what the probe has always seen: `deployed = 41` already at t = 0
and never changing.

Kept at 🟡: it is an inference from the implausibility of one reading, not a
direct measurement. But it is now the leading explanation, ahead of event-gating.

## The test that would settle it

Sample **within the first seconds of flight**, before startup costs, and compare
`deployed` at flight+2 s against flight+30 s. Under the frames reading the count
climbs during those seconds and is finished before the current probe ever looks;
under any seconds reading it is flat there and climbs later.

That requires the probe's ~25 s of enumeration and calibration to happen *after*
a first cheap sample, which is a reordering rather than new decoding.

---

# Sampling from the first moment (2026-08-24)

## ✅ Setup cost cut from ~25 s to ~0.5 s

`early_probe.py` defers everything expensive: no witness calibration (two 32 MB
reads), no per-record labelling, and the heap scan uses `bytes.find`. Setup
completes in **0.5–0.8 s**, so the first sample lands essentially at flight
detection instead of 25 s after it.

## 🔴 Still flat: deployed is 41 at flight+0.8 s and never climbs

```
+  0.8s  deployed= 41  craft=298
+  2.1s  deployed= 41  craft=298
   … every sample to +252s …
+252.0s  deployed= 40  craft=282
```

The only change in 252 s is 41 → 40, one squadron wiped out. **No climb at any
point**, so no arrival is observable from flight detection onward — which under
the frames reading is expected, since the whole phase-1 schedule would be over
within 8 s of mission start.

## 🔴 A flaw in the `--wait` variant: it caught the ready room

To get ahead of flight detection, a second run started the probe *before* the
launch and waited for the roster to appear. It did appear — 116 records — but the
numbers were **`deployed = 39`, `craft = 276`**, flat for the whole 200 s window.

That is not the mission. **The roster is built before take-off**, so waiting for
it catches the READY ROOM, and the probe's window expired around the time flight
actually began. Waiting for the roster is not the same as catching mission start,
and the test as designed does not do what it claims.

## 🟡 But the two runs together suggest deployment happens at take-off

| state | deployed | craft |
|---|---|---|
| ready room | 39 | 276 |
| in flight (from t+0.8 s onward) | 41 | 300 |

Two more records and 24 more craft appear between the ready room and flight.
These are **different runs**, so this is suggestive rather than measured — but it
points at deployment being a single step at take-off rather than a schedule
unfolding during the mission.

**Next:** one run with the probe waiting for the roster and sampling for ~400 s,
long enough to span ready room → take-off → flight in a single continuous
series. That would show the 39 → 41 step directly, or refute it.

---

# ✅ Deployment is resolved at mission LOAD (2026-08-24)

The run that was supposed to catch a take-off step instead removed the
hypothesis. One continuous series, 64 samples over ~380 s, started when the
roster appeared and running through the ready room, take-off (`IN FLIGHT` at
+47 s) and the whole flight:

```
+    0.3s  deployed= 41  craft=292
   … 64 samples, ZERO changes …
last     deployed= 41  craft=292
```

**Not one change in either number**, across the ready room, the transition, and
several minutes of flight.

## 🔴 Refuted: my own "deployment happens at take-off"

The previous entry noted ready room 39/276 against flight 41/300 and suggested
deployment was a single step at take-off, flagged 🟡 because the numbers came
from *different runs*. Measured within one run, there is no step: the values are
identical before and after take-off. **That was cross-run variance and the
hypothesis is withdrawn.**

## What this establishes

**The roster is already deployed when the roster first exists** — 41 of 116
records hold craft before the ready room ends, and nothing changes afterwards.
Combined with everything else in this file:

* every participant is allocated at mission load (roster identity, two stages);
* 41 of 116 records are deployed from the first observable instant;
* no `0 → n` transition occurs in the ready room, at take-off, or in up to 435 s
  of verified-live flight with 42 kills.

So **Stage 02 phase 1 has no observable in-mission arrival at all.** Whatever the
route table's first-keyframe times do, they do not release squadrons on a clock
that this instrumentation can see, and they do not respond to the player
destroying 42 craft.

## What remains open

* The route times still mean *something* — the values 0/90/120/170/210/240 and
  S01's 1500/1800/2100 are structured, not noise. The frames reading
  (t = 2100 → 70 s at 30 Hz) remains the best fit, in which case they are most
  likely **fly-in animation timings applied at load**, not release times.
* Phases 2 and 3 are entirely untested. Every run has stayed in phase 1, and
  phase advance was never located. If arrivals exist, a phase transition is the
  most likely place to see one.
* This run had **no pilot**, so it says nothing new about event-gating; the
  piloted 435 s run already covers that.