From 0feadc42058fe7e8c6d092d526c394533d2555c6 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Thu, 27 Aug 2026 01:34:09 +0000 Subject: [PATCH] re: mission TIME is the liveness oracle, and it explains the earlier "0 movers" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The OB kill test did not run -- the guest froze about a minute into the mission -- but sampling the HUD's own mission clock beside the counter caught it instantly. Twelve samples over ~4 minutes of wall time: the first reads TIME 00:43.24, every one after reads 01:02.23 unchanged, with REMAINING OB 004 throughout. frozen.py agrees (max_pixel_delta=0), movers in the entity window are 0, and screen_id still says `flight` with the process alive. Worth a file because the mission clock defeats both traps this corpus has paid for: it is the simulation's own counter, so neither a frozen world nor a finished one advances it, where screen_id and pixel-churn are fooled by a GAME OVER screen that animates. Rule recorded: "X never changed" is only evidence if TIME changed across the same window. It also closes an open ❔ from earlier this session -- entity-position-anchor- refuted.md's "0 of 64 regions changed across 357 MB, cause unknown, not reproduced". Same signature, now reproduced: it was this freeze. Still unrun for the fourth iteration: the kill test itself. Not conceptually blocked -- blocked by attrition, with this run dying at t~62s, before even the t=120 arrival the trajectory prediction needs. --- .../re/mission-time-is-the-liveness-oracle.md | 71 +++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 docs/re/mission-time-is-the-liveness-oracle.md diff --git a/docs/re/mission-time-is-the-liveness-oracle.md b/docs/re/mission-time-is-the-liveness-oracle.md new file mode 100644 index 00000000..3cb24769 --- /dev/null +++ b/docs/re/mission-time-is-the-liveness-oracle.md @@ -0,0 +1,71 @@ +# ✅ The HUD's mission TIME is the liveness oracle — and it closes the "0 movers" mystery + +Measured 2026-08-27, Stage 02 (guarded route, stage asserted), attempting the +`REMAINING OB` kill test. + +## What happened + +The kill test **did not run**: the guest froze about a minute into the mission. +It was caught immediately, and by the cheapest possible means — sampling the +HUD's own **mission clock** beside the counter. + +![TIME frozen at 01:02.23](captures/mission-time-frozen-timeline.png) + +Twelve samples over ~4 minutes of wall time. The first reads `TIME 00:43.24`; +every one after reads **`01:02.23`**, unchanged, with `REMAINING OB : 004` +throughout. + +Confirmed three independent ways at the same moment: + +| check | verdict | +|---|---| +| mission `TIME` | frozen at `01:02.23` | +| `frozen.py` | `frozen max_pixel_delta=0 gap=6.0s` | +| movers in the entity window | **0** | +| `screen_id.py` | still `flight` | +| process | alive | + +## ✅ Why this is worth a file: TIME beats every other liveness check + +This corpus has twice recorded a confident negative that turned out to be about a +dead world — the in-mission freeze, and the **GAME OVER screen animating** while +tools reported "the counter never moved" +([mission-freeze-and-ob-flag.md](mission-freeze-and-ob-flag.md)). Both defeated +`screen_id.py`, and the second defeated pixel-churn detection too, because a +finished mission still animates. + +**The mission clock defeats neither trap, because it is the simulation's own +counter.** A frozen sim does not advance it; a finished mission does not advance +it; a live one always does. It costs one crop of an already-taken screenshot. + +**Rule:** sample `TIME` beside any in-mission measurement. A reading of "X never +changed" is only evidence if `TIME` changed across the same window. + +Crop used here: `convert shot.png -crop 210x46+995+38 +repage time.png` +(the `REMAINING OB` digits are `-crop 150x46+1085+232`). Montaging N crops into +one strip makes a whole run's timeline readable in a single look. + +## ✅ It also closes an earlier ❔ from this session + +[`entity-position-anchor-refuted.md`](entity-position-anchor-refuted.md) recorded +a session where **0 of 64 sampled regions changed across the whole 357 MB +mapping** while the HUD rendered, and left the cause ❔ — "not reproduced; cause +unknown". It is now reproduced, with a diagnosis: that was **this freeze**. The +signature matches exactly — movers 0, screen still `flight`, process alive at +full CPU, and nothing in guest memory advancing. + +So that open question is answered, and the general lesson it was filed under +stands reinforced rather than replaced. + +## ❌ What did NOT get done + +The `REMAINING OB` kill test — kill one `e010`, expect the counter to fall by +exactly 1 — is **still unrun**, now for the fourth iteration. It is not blocked by +anything conceptual; it is blocked by attrition. Roughly half of Stage 02 runs +end early, and this one froze at t≈62 s, before the t=120 arrival that the +[trajectory prediction](ob-counts-marked-attackers.md) needs, let alone before any +kill. + +❔ **The freeze's cause remains uninvestigated.** This run establishes only that +it happens, that it happened at t≈62 s of mission time, and that TIME detects it +in one crop.