re: F6 unit 9 -- wrap-to-wrap period NOT obtained, two harness failures

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

docs/re/f6-unit9-wrap-period-not-obtained.md

@@ -0,0 +1,49 @@
+# 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:
+
+1. **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.
+2. **Second launch started, armed, pressed Ⓐ — and wrote no draw log.**
+   `canary.stdout` stayed at **0 bytes** and no `xenia_re_ui_draws_01.log` appeared,
+   despite the script printing `armed 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.

tools/re-capture/title_sweep_probe.sh

@@ -17,7 +17,7 @@ OUT="${1:-/sylph-home/re/f6}"; mkdir -p "$OUT"; rm -f "$OUT"/xenia_re_ui_draws_*
 pad(){ printf '%s' "$1" > "$XENIA_PAD_FILE.tmp"; mv "$XENIA_PAD_FILE.tmp" "$XENIA_PAD_FILE"; }
 pad ""
 ( cd "$OUT" && nohup run-canary --log_ui_draws=true \
-    --ui_draw_capture_frames=2500 --ui_draw_capture_max=600000 \
+    --ui_draw_capture_frames=6000 --ui_draw_capture_max=1500000 \
     >"$OUT/canary.stdout" 2>"$OUT/canary.stderr" & )
 sleep 8
 win="$(xdotool search --name "Xenia-canary" | tail -1)"
@@ -25,6 +25,6 @@ win="$(xdotool search --name "Xenia-canary" | tail -1)"
 xdotool windowactivate "$win" 2>/dev/null; xdotool key --window "$win" F10; xdotool key F10
 echo "armed at ${SECONDS}s"
 sleep 12; pad "press=A"; sleep 0.4; pad ""; echo "A (skip video) at ${SECONDS}s"
-sleep 45          # let the title build in and settle, no further input
+sleep 150         # let the title build in and settle, no further input
 pkill -x xenia_canary
 echo "done at ${SECONDS}s"; ls -la "$OUT"/*.log 2>/dev/null