diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index 32e1cd82..96b16ef0 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -471,6 +471,19 @@ search cannot find a *schedule*. missed by one second. 🟑 Coverage assumes the 55 % wallβ†’game factor; the witness has measured 8–24/s across runs, and at the low end the same window covers only ~117 game-s (t=90 only). **Pinning the tick rate would make this sharp.** +* βœ…πŸŸ‘ **(2026-08-24) The 42-anomaly is STAGE 01, and it hands us two results.** + Rescans stuck at 42 (not a load race); live RAM holds `UN_S01_Asteroid_cmesh_*` + and `UnitGroup_S01.tbl` with S02 absent β€” **the launch sometimes loads Stage 01** + (the discard rule caught every such run). βœ… That supplies the refutation test + recorded as *blocked* for lack of a second stage: S01 static **42 members / 13 + units** vs live **42 records / 13 definitions**, composition 20/20, 6/6, 5/5, + 2/2 β€” **one record per member now holds on two independent stages.** + 🟑 **Route times are almost certainly FRAMES**: S01 phase 2 has t=1500/1800/2100, + which as seconds is 25–35 min into one phase (implausible) but at 30 Hz is + 50/60/70 s. β‡’ S02's t=90…240 would be **3–8 seconds**, all before the probe's + first sample (~25 s in) β€” explaining every null result, and consistent with + `deployed=41` already at t=0. **Test: sample at flight+2 s vs flight+30 s** β€” + a reordering of the probe, not new decoding. πŸ”΄ `SYLPH_HZ=3` refuted as a lever: it gave the LOWEST frame rate (8/s) with the most kills, so pilot polling is not the throttle. * ~~🚧 BLOCKER: t=210/240 unreachable in one turn~~ β€” **superseded, see above**; diff --git a/docs/re/mission-arrival-watch.md b/docs/re/mission-arrival-watch.md index 3477abc3..699111ad 100644 --- a/docs/re/mission-arrival-watch.md +++ b/docs/re/mission-arrival-watch.md @@ -494,3 +494,69 @@ this result sharp. `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.