notes: build-canary points at a source root that does not exist here

Recorded as a blocker rather than worked around, because it changes what the
next session can plan.

The faithful-capture route is an internal tap at SDLAudioDriver::SubmitFrame,
which receives exactly frame_size_ bytes of the guest s own frame in guest order
with no wall clock in the loop. A cvar-gated WAV writer there would record what
the guest PRODUCED rather than what a device CONSUMED, so it would be gap-free
however slowly the emulator runs -- which is precisely the defect that made both
ADV captures unusable.

The change is small. The build is not. build-canary builds
${PROJECT_DIR:-/work}/xenia-canary, which does not exist in this container; the
source is at /canary. The warm 235 MB tree at /sylph-home/re/canary-build is
configured with CMAKE_HOME_DIRECTORY=/work/xenia-canary, also missing, and its
build-Release.ninja carries no per-file rules -- it re-runs CMake first, and that
reconfigure fails on the absent root. So any Canary change is a full reconfigure
against /canary plus a full compile, at SYLPH_JOBS=4 on a box sitting at about
700 MB free with a documented history of full-parallel builds OOM-killing the
host.

Not attempted: that is a whole session s risk for one probe, and the next session
should decide with the cost in front of it rather than discover it halfway
through.

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

docs/agents/CONTAINER-NOTES.md

@@ -12,6 +12,17 @@ already went wrong once.
 * **The toolchain is real.** `tools/re-capture/rebuild_canary.sh` exists because
   the old box had no cmake/ninja/clang and only runtime sonames, so it hand-
   relinked object files. **Do not use it here.** Use `build-canary`.
+  🔴 **But `build-canary` does not work in this container as it stands
+  (2026-08-29).** It builds `${PROJECT_DIR:-/work}/xenia-canary`, which **does
+  not exist here** — the Canary source is at **`/canary`** (`$XENIA_SRC`). The
+  warm 235 MB tree at `/sylph-home/re/canary-build` is configured with
+  `CMAKE_HOME_DIRECTORY=/work/xenia-canary`, also missing, and its
+  `build-Release.ninja` carries **no per-file rules** — it wants to re-run CMake
+  first, which would fail on the absent source root. **So any Canary change is a
+  full reconfigure against `/canary` plus a full compile**, not an incremental
+  one. Budget for that before starting: `SYLPH_JOBS=4`, and this box has been
+  sitting at **~700 MB free** with a documented history of full-parallel builds
+  OOM-killing the host.
 * **numpy and Pillow are installed.** `entities2.py`, `flight_probe.py` and the
   image oracles work. Their absence used to look like a logic bug.
 

docs/re/audio-capture-channel-map-trap.md

@@ -199,12 +199,30 @@ below real time becomes a hole in the file, and the timebase is warped
 non-uniformly — deleting the silences does not repair it, it just compresses time
 unevenly.
 
-❔ **The route that would work is an internal tap**, and it does not exist yet:
+❔ **The route that would work is an internal tap**, and it does not exist yet.
-`SDLAudioDriver::SubmitFrame` sees every frame the guest actually produces, in
+`SDLAudioDriver::SubmitFrame(float* frame)`
-guest order, with no wall clock involved. A cvar-gated WAV writer there would be
+(`/canary/src/xenia/apu/sdl/sdl_audio_driver.cc`) receives exactly `frame_size_`
-the same shape as `xma_param_probe` — additive, default-off, read-only — and
+bytes — `sizeof(float) × frame_channels_ × channel_samples_` — of the guest's own
-`/canary` is writable with `build-canary` available. **Not attempted this
+frame, in guest order, with **no wall clock in the loop**. A cvar-gated WAV
-iteration.**
+writer there is the same shape as `xma_param_probe`: additive, default-off,
+read-only. It would produce a gap-free recording however slowly the emulator
+runs, because it records what the guest *produced* rather than what a device
+*consumed*.
+
+🔴 **Blocked on the build, not on the change — and this is a container fact
+worth knowing before anyone plans around it.** `build-canary` builds
+`${PROJECT_DIR:-/work}/xenia-canary`, which does not exist here; the source is at
+`/canary`. The warm 235 MB tree at `/sylph-home/re/canary-build` is configured
+with `CMAKE_HOME_DIRECTORY=/work/xenia-canary` — also missing — and its
+`build-Release.ninja` has no per-file rules, so it re-runs CMake first and that
+reconfigure fails on the absent root. **Any Canary change is therefore a full
+reconfigure plus a full compile**, at `SYLPH_JOBS=4` on a box sitting at ~700 MB
+free with a documented history of parallel builds OOM-killing the host.
+
+**Not attempted, deliberately** — that is a whole session's risk for one probe,
+and the rule here is not to improvise around a blocker. Recorded so the next
+session can decide with the cost in front of it rather than discovering it
+halfway through a build.
 
 ## 🔴 And a provenance number I got wrong