7863ad3b62
Unit 8's rate (0.514 units/frame) rests on one wrap, a start-to-wrap span
rather than a period. Hardening it needs a longer capture with two or more
wraps. Two attempts, both failed on the harness rather than the game.
First launch never started: the pgrep && echo || { } guard took the wrong
branch, no output directory was created and no process ran, while a stale
emulator from the previous iteration was still up. It looked like a running
capture for several minutes.
Second launch started, armed, pressed A and wrote no draw log at all --
canary.stdout stayed at 0 bytes and no xenia_re_ui_draws log appeared,
despite the script printing "armed at 8s". Likely a race with the orphaned
emulator from the first failure, not confirmed.
Unit 8's numbers are unaffected; they came from the intact f6 capture,
which is still on disk. The offset has two independent supports; the rate
still rests on a single wrap and the port should not ship on it.
The lesson, and it is the second harness failure of this shape: "armed at
8s" printed while nothing was being logged. The arming step reports success
on SENDING the keystroke, not on the logger responding -- the same silent
failure that cost the first F1 probe a run, which I "fixed" by making the
window lookup fatal. That fix was too narrow: the window was found, the key
was sent, and the log still never appeared. The check that would have
caught both is to wait for the draw log to exist and be non-empty after
arming, and abort loudly otherwise. A probe that cannot confirm its own
instrument is recording is a probe whose negatives mean nothing, and I have
now written that bug twice.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2.4 KiB
F6 unit 9 — the wrap-to-wrap period was NOT obtained: two harness failures, no new data
Status: ❔ not answered — the run did not produce data. 2026-09-02.
Question: what is the leaf's loop period measured wrap-to-wrap? Look at: frames between consecutive wraps. Pass = ≥2 wraps; fail = fewer. Not covered: everything else in F6.
What happened
Unit 8's rate (0.514 units/frame, leaf ≈ ½ × title) rests on one wrap — a start-to-wrap span, not a period. Hardening it needs a longer title capture with two or more wraps. Two attempts, both failed on the harness rather than the game:
- First launch never started. The
pgrep … && echo || { … }guard I wrote took the wrong branch — the output directory was never created and no process ran, while a stale emulator from the previous iteration was still up. It looked like a running capture for several minutes. - Second launch started, armed, pressed Ⓐ — and wrote no draw log.
canary.stdoutstayed at 0 bytes and noxenia_re_ui_draws_01.logappeared, despite the script printingarmed at 8s. The likely cause is a race with the orphaned emulator from failure 1, but I did not confirm it.
What stands, unchanged
Unit 8's two numbers are not affected — they came from the intact f6 capture,
which is still on disk. The offset (+40 title units) has two independent supports;
the rate (0.514×) still rests on a single wrap and the port should not ship on
it, which is what I told them before this attempt.
🔴 The lesson, since it is the second harness failure in two iterations
armed at 8s printed while nothing was being logged. The script's arming step
reports success on sending the keystroke, not on the logger responding — exactly
the silent-failure shape that cost the first F1 probe a whole run, and which I
"fixed" then by making the window lookup fatal. That fix was too narrow: the
window was found, the key was sent, and the log still never appeared.
The check that would have caught both: after arming, wait for
xenia_re_ui_draws_*.log to exist and be non-empty, and abort loudly if it does
not. A probe that cannot confirm its own instrument is recording is a probe whose
negatives mean nothing — and I have now written that same class of bug twice.
Next
Add that assertion to title_sweep_probe.sh, then re-run. The measurement itself
is unchanged and cheap; only the harness needs the guard.