notes: run-canary is silent by default, which records perfect silence

Both of these cost time in one session and both are the kind that look like
success.

run-canary line 82 is SDL_AUDIODRIVER=${SDL_AUDIODRIVER:-dummy}, and its own
header explains why: --apu=nop stalls the guest in the intro movie, so the SDL
driver against a dummy device is what lets the title advance. But the comment s
premise -- "there is no PulseAudio here" -- stopped being true when
tools/audio-capture landed, since that starts a daemon on demand. So a capture
through the null sink records pure silence, of the right length, behind a run
that looks perfectly healthy. The override is
PULSE_SINK=cap SDL_AUDIODRIVER=pulseaudio run-canary, and the live check is
pactl list sink-inputs: empty means Canary never attached and the sink sits at
IDLE. audio-capture s own -inf peak warning is the backstop, but it only fires
after the whole run.

Separately, pkill -f and pgrep -f match the caller s OWN command line. Hit twice
here: pkill -9 -f adv_audio_cap.sh killed the shell running it, and an
until ! pgrep -f "probe.py --run" loop never exited because the loop s own
command line contained the pattern -- which looks exactly like the job hanging.
Kill by process name with ps -o pid= -C instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd

docs/agents/CONTAINER-NOTES.md

@@ -40,6 +40,25 @@ python3 tools/re-capture/gmem.py find hex:820af844 400
 ```
 
 * **One emulator at a time.** `run-canary` enforces it with a lockfile.
+* 🔴 **`run-canary` is SILENT by default, and that defeats `audio-capture`.**
+  Line 82 is `export SDL_AUDIODRIVER="${SDL_AUDIODRIVER:-dummy}"`, and its
+  header explains why: `--apu=nop` stalls the guest in the intro movie, so the
+  SDL driver against a *dummy* device is what lets the title advance. The
+  comment's premise — "there is no PulseAudio here" — **stopped being true when
+  `tools/audio-capture` landed**, and it starts a daemon on demand.
+  So a capture through the null sink records **pure silence**, at the right
+  length, with a perfectly healthy-looking run behind it. To actually record the
+  game:
+
+  ```bash
+  audio-capture start                     # or load a null sink yourself
+  PULSE_SINK=cap SDL_AUDIODRIVER=pulseaudio run-canary …
+  ```
+
+  ⚠️ **Check `pactl list sink-inputs` before trusting a recording.** If it is
+  empty, Canary never attached and you are recording zeroes; the sink also sits
+  at `IDLE`. `audio-capture run` warns on a `-inf` peak afterwards, which is the
+  backstop — but a live check fails in seconds instead of after the whole run.
 * Boot is slow cold, ~25 s once the shader/code caches are warm — so a
   launch-and-dump fits in a single call.
 * **Screens: classify by whole-image statistics** (`screen_id.py`), not named

docs/re/METHOD.md

@@ -109,6 +109,12 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
 * **Raw grep cannot see inside compressed pak entries.**
 * **Commit messages go in a file** (`git commit -F`); a literal `|` in a table
   cell needs escaping; `git log --all -- <path>` can hang.
+* **`pkill -f PATTERN` / `pgrep -f PATTERN` match YOUR OWN command line.** Hit
+  twice in one session: `pkill -9 -f adv_audio_cap.sh` killed the shell that ran
+  it, and an `until ! pgrep -f "probe.py --run"` loop never exited because the
+  loop's own command line contained the pattern. Kill by process name
+  (`ps -o pid= -C xenia_canary`) or exclude self; a wait-loop that greps for its
+  own text waits forever and looks like the job hanging.
 * **"Build 10" of a pak is ambiguous — always say which index space.**
   `sylpheed-cli screen list GP_TITLE.pak` reports **12** builds and numbers them
   0–11; `screen list --all` reports **16** and numbers them 0–15. Only under