diff --git a/docker/decoder/sylph-decoder b/docker/decoder/sylph-decoder index df75430e..2ba16652 100755 --- a/docker/decoder/sylph-decoder +++ b/docker/decoder/sylph-decoder @@ -123,7 +123,16 @@ docker_args() { # emulator and scrape /dev/shm to get at it. An earlier belief that this # file was STALE was tested and refuted -- it is current. -v "${SYLPH_PE:-$PROJECT/Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).pe}:/image/sylpheed.pe:ro" - -e "SYLPHEED_DB=/xenia-rs/sylpheed.db" + # 🔴 THE DISASSEMBLY DATABASE. This used to be read from the xenia-rs clone + # (`SYLPHEED_DB=/xenia-rs/sylpheed.db`). That repo is retired, its directory + # is gone, and the mount that served it was removed -- so the variable named + # a path that did not exist and `zq.py` had nothing to open. The database now + # lives beside the repo as a build artefact; mounted at the container's repo + # root, which is where `zq.py` looks when `$SYLPHEED_DB` is unset. + # + # Read-only on purpose: the host owns it, DuckDB takes an exclusive lock to + # write, and two agents plus the human sharing one file would corrupt it. + # Regenerating means writing elsewhere and pointing `$SYLPHEED_DB` at it. -e "SYLPHEED_PE=/image/sylpheed.pe" -e "SYLPHEED_IMAGE_BASE=0x82000000" # 🔴 EVIDENCE IS SHARED, NOT COMMITTED (issue #49). Each agent works in its @@ -276,6 +285,20 @@ docker_args() { echo "==> NOTE: no ISO at $_iso -- Canary has nothing to boot." >&2 fi + # The disassembly database. `zq.py` looks at the repo root when $SYLPHEED_DB + # is unset, so mounting it there needs no environment variable at all -- which + # is what the dead `/xenia-rs/sylpheed.db` variable taught: a path in an env + # var and a path in a mount drift apart silently. + _db="${SYLPH_DB:-$PROJECT/Sylpheed/sylpheed.db}" + if [ -f "$_db" ]; then + _out+=(-v "$_db:/work/sylpheed.db:ro") + else + echo "==> NOTE: no sylpheed.db at $_db -- /sylph-dis and zq.py cannot run." >&2 + echo " build one: cargo run --release -p sylpheed-xexdb --bin sylph-xexdb -- \\" >&2 + echo " dis \"\$SYLPH_ISO\" --db sylpheed.db --analyze sql --quiet" >&2 + echo " then re-apply the RE names with tools/apply_re_symbols.sql" >&2 + fi + # ── GPU ── # Three distinct cases, and conflating them is how you end up believing you # have hardware Vulkan while actually running llvmpipe: diff --git a/docs/agents/decoder-loop.md b/docs/agents/decoder-loop.md index 04a6804a..50838b2b 100644 --- a/docs/agents/decoder-loop.md +++ b/docs/agents/decoder-loop.md @@ -56,11 +56,23 @@ rather than left in a document you might not reach. | path | what | env | |---|---|---| | `/image/sylpheed.pe` | the decompressed executable image | `SYLPHEED_PE` | -| `/xenia-rs/sylpheed.db` | a disassembly database, 586 MB | `SYLPHEED_DB` | +| `sylpheed.db` at the repo root | the disassembly database, 337 MB | — (`zq.py` finds it; `$SYLPHEED_DB` only to override) | +| `/canary/build/bin/Linux/Release/xenia_canary` | the built oracle, inside the `/canary` mount | — | | `/disc` | the extracted disc | `SYLPHEED_DISC` | | `/iso/game.iso` | the retail ISO Canary boots | `SYLPH_ISO` | | `/canary` | the Canary source, read-write | `XENIA_SRC` | +⚠️ **The database is read-only and is NOT in git** — it is a build artefact, and +`docs/re/captures/` is the same (issue #49). If either is missing the launcher +says so and prints the command that builds it. Query the database with +`python3 tools/zq.py …`, never by reading a disassembly dump. + +⚠️ **The built Canary carries the `RE-INPUT`/`RE-DRAW` instrumentation but NOT +the `audit_61` guest-PC branch probe** — that lives only on +`auto/canary-instrumentation-snapshot-2026-07-28` and `phase-a-tracing` +(fork issue #1), so a probe run needs those two commits on `sylpheed-re` and a +rebuild first. Verified by `strings` on the binary, not assumed. + **The `.pe` is a flat VA dump**: file offset = `VA - 0x82000000`. Reading `0x820A1630` is `seek(0xA1630)`. No XEX decrypt, no LZX, **no booted emulator** — dumping guest memory works but makes the whole static corpus depend on a running