re: the boot harness was blinking slower than the title -- diagnosed

Four consecutive runs failed to reach the interactive title, across two
locales, two launch paths and two display-gamma settings. I attributed it
in turn to a stale oracle, to the locale, and to the attract loop. It was
none of those.

  one `screenshot` call, emulator running:  10.8 s
  one `screenshot` call, emulator killed:    0.117 s

92x, measured at a 1-minute load average of 1.80 -- so it is contention
with the emulator through the X server, not background load.
skip_intro.sh takes two grabs per iteration plus a numpy import, giving a
median sampling interval of 41 s in the last run (38/82/41/20/30/30/35/
47/46/45/44/43/21/19). The title lasts "a few seconds" before the attract
loop reclaims it -- wait_title.sh's own header says so. The harness was
sampling slower than the event it was waiting for. That also explains why
runs at 16:43-18:05 the same day succeeded.

Withdrawn as CAUSES, though the observations stand: "the JP run never
reaches the interactive title", "neither locale reaches it without a pad
press", and "the game sat in the attract loop for 604 s". The English
control did control for locale -- it just shared the same defect.

Also recorded: I set kernel_display_gamma_type = 0 for the gamma control
run, which brightens the frame (mid-attract mean 122.8 vs 52.5/82.8 at
type 2) -- and skip_intro classifies movie-vs-static on an ABSOLUTE rmse
threshold, so the gamma change biased the very classifier the run
depended on. Changing a display setting and a capture behaviour in one
run confounds both. Config restored to type 2.

The fix is not applied: make the probe cheap enough to outpace the title
window (small region, no convert round trip, one long-lived process).
Every remaining emulator-side question is waiting on that.

docs/re/METHOD.md

@@ -496,3 +496,17 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   whose flat regions are pure black — every model scored ≈ 0.00 error there. That
   is not corroboration; it is a test with no power, and reporting the 0.00 as
   agreement would have dressed an untested claim as a verified one.
+* **Time your probe against the thing you are probing for.** Four runs concluded
+  "the game never reaches the title". `screenshot` costs **10.8 s while xenia is
+  running** and **0.117 s once it is killed** — 92× — so a two-grab polling loop
+  samples every ~41 s, against a title screen this corpus documents as lasting a
+  few seconds. The harness was blinking slower than the event. Before believing a
+  negative from a polling loop, measure its interval and compare it to the
+  duration of what you are waiting for; and measure the probe's cost *under the
+  same load as the run*, because idle timing here was off by two orders of
+  magnitude.
+* **Do not change a display setting and a capture behaviour in the same run.**
+  `kernel_display_gamma_type = 0` brightens the frame, and `skip_intro.sh`
+  classifies movie-vs-static on an *absolute* rmse threshold — so the gamma
+  change biased the very classifier the run depended on. Harness thresholds tuned
+  on one output configuration are not portable to another.

docs/re/REFUTED.md

@@ -430,3 +430,9 @@ neighbourhood, not just the line.
   locale*" → **refuted by the English control.** 75 samples over 734 s with the
   same flags and oracle, every one glyph = 0. Neither locale presents the
   interactive title without a pad press.
+* "neither locale reaches the interactive title without a pad press" /
+  "the game sat in the attract loop for 604 s" → **withdrawn as causes.** Both
+  rest on runs whose polling loop sampled every ~41 s, because `screenshot`
+  costs 10.8 s while the emulator runs (0.117 s idle, 92×). A title lasting a few
+  seconds would be missed. The observations stand; the conclusions drawn from
+  them do not. [`capture-harness-status.md`](capture-harness-status.md)

docs/re/capture-harness-status.md

@@ -0,0 +1,66 @@
+# 🔴 Why the boot harness stopped reaching the title — `screenshot` costs 10.8 s
+
+**Status:** ✅ **diagnosed, with a control.** Four consecutive runs on
+2026-08-28/29 failed to reach the interactive title, across two locales, two
+launch paths and two display-gamma settings. The cause is none of those.
+
+## The measurement
+
+| condition | one `screenshot` call |
+|---|---|
+| while Xenia Canary is running | **10.8 s** |
+| immediately after killing it | **0.117 s** |
+
+**92×.** The 1-minute load average at the slow measurement was 1.80, so this is
+contention with the emulator (both go through the same X server), not general
+system load.
+
+## Why that breaks the harness
+
+`skip_intro.sh` takes **two** grabs 0.6 s apart per iteration, plus an
+`is_title.py` numpy load. Its actual sample timestamps in the last run:
+
+```
+57, 95, 177, 218, 238, 298, 333, 380, 426, 471, 515   → intervals
+38, 82, 41, 20, 30, 30, 35, 47, 46, 45, 44, 43, 21, 19  median 41 s
+```
+
+A **41-second** sampling interval against a title screen that the corpus already
+documents as lasting *"a few seconds"* before auto-returning to the attract loop
+(`wait_title.sh`'s own header). The harness is not seeing a stuck game; it is
+blinking slower than the thing it is looking for.
+
+That is also why runs at 16:43–18:05 the same day succeeded and later ones did
+not — nothing about the game changed.
+
+## 🔴 What this retracts
+
+Three earlier conclusions were built on these runs and are **withdrawn as
+causes**, though the observations stand:
+
+* *"the Japanese-locale run never reaches the interactive title"* — it may well
+  have appeared, unsampled.
+* *"neither locale reaches the interactive title without a pad press"* — the
+  English control shared the same defect, so it controlled for locale but not for
+  the sampling rate.
+* *"the game sat in the attract loop for 604 s"* — what was observed is that
+  **every one of ~15 samples** landed on movie content, which at a 41 s interval
+  is a much weaker statement than it reads as.
+
+## ⚠️ A confound I introduced
+
+Setting `kernel_display_gamma_type = 0` makes the frame substantially brighter
+(a mid-attract frame measured mean **122.8** against **52.5** and **82.8** on
+comparable phases at type 2). `skip_intro.sh` classifies movie-vs-static on an
+**absolute** rmse threshold of 1500 between two grabs, so a brighter output
+inflates that difference and biases every frame toward "movie". **The capture
+harness's tuning is coupled to the display settings** — changing gamma and
+capture behaviour in one run confounds both.
+
+## The fix, not applied here
+
+Make the probe cheap enough to sample faster than the title window: grab a small
+region rather than the full surface, drop the ImageMagick `convert` round trip,
+or keep the glyph test in one long-lived process instead of re-importing numpy
+per sample. None of that is done — this page is the diagnosis, and it is what
+every remaining emulator-side question is waiting on.