fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: withdraw the no-disc banner -- the disc is mounted, and both instruments that said otherwise were blind to it

Browse Source 
The container was replaced at 11:07:38 UTC, 25 minutes after b9aca6a wrote
"the decoder container has no disc". /disc is a real read-only bind mount
(device 2050 against /'s 92), 6.2 GB, 74 entries under dat/, and
`sylpheed-cli screen list` returns 12 GP_TITLE builds.

The reusable half is the instruments. `find / -xdev` cannot cross into a bind
mount on another device, so its "no ISO, no default.xex, no GP_TITLE.pak"
is what it returns whether or not the disc is there. `sylph-doctor` only ever
looks under /work and never consults $SYLPHEED_DISC, so it still reports
"no ISO" against a disc that works. Two instruments, one blind spot, read as
corroboration.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KNR5Y79D1T4bBr6gJQaWFP
This commit is contained in:
sylph-decoder
2026-08-29 11:12:36 +00:00
parent 3a87a26235
commit 7e20853592
2 changed files with 58 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
docs/port/HANDOFF.md
View File

@@ -23,23 +23,31 @@ There is no fourth kind. If a row says *measured* or *undecodable*, the port is
human can see it is a human decision, so that when it is later decoded the
authored version can be deleted.
## 🔴 2026-08-29 — the decoder container has no disc, so nothing here can be extended right now
## ✅ 2026-08-29 — the disc is back in the decoder container; the red banner that stood here is withdrawn
`find / -xdev` finds **no ISO, no `default.xex` and no `GP_TITLE.pak`**; `/exchange`
is empty; `sylph-doctor` agrees. Root cause is in the launcher, not the disc:
`06676d3` moved `/work` from a bind mount of the human's working tree (which
*contained* the ISO and `sylph_extract/`) to the agent's own named volume, and no
disc mount was added to replace it — `sylph-decoder` still forwards `SYLPH_ISO` as
a bare environment variable with nothing bind-mounted behind it. `sylph-port`
mounts the disc properly, so **only the decoder is affected**.
**This supersedes the "the decoder container has no disc" banner** written at
commit `b9aca6a` (10:42 UTC). That diagnosis was true for the container it was
written in, and a human has since fixed it: this container's PID 1 started at
**11:07:38 UTC**, 25 minutes later, and it has the disc mounted.
**What that means for you:** every row below still stands — they are already
written down with their evidence, and `docs/re/captures/` (99 MB) and
`docs/re/data/` (2.5 MB) are in git. But until a human adds the mount, the decoder
cannot boot the oracle, cannot run `sylpheed-cli` against a pak, cannot run the
disc-gated tests, and cannot disassemble the executable. **Do not wait on a new
measurement.** Full diagnosis and the one-line fix:
[`capture-harness-status.md`](../re/capture-harness-status.md#-2026-08-29--the-disc-is-not-in-the-decoder-container-at-all).
Verified, not assumed:
| | |
|---|---|
| `/disc` | a real read-only bind mount on device 2050 (`/` is device 92), **6.2 GB**, 74 entries under `dat/`, `default.xex` present |
| `/iso/game.iso` | present, 7 835 492 352 B |
| end-to-end | `sylpheed-cli screen list $SYLPHEED_DISC/dat/GP_TITLE.pak` returns **12 screen builds**, matching [`ui-title-build-map.md`](../re/ui-title-build-map.md) |
⚠️ **`sylph-doctor` still reports "no ISO" and "no extracted disc", and it is
wrong.** It looks only under `/work` (`find /work -maxdepth 2 -iname '*.iso'`
and `-d /work/sylph_extract/dat`); it never consults `$SYLPHEED_DISC`. Do not
take its two ✖/! lines as evidence about the disc — the disc is at `/disc`
and works. Same trap for `find / -xdev`, which by definition cannot cross into
a bind mount on another device, and which is what the withdrawn banner ran.
**What that means for you:** the decoder can boot the oracle, run
`sylpheed-cli` against a pak, run the disc-gated tests and read the executable
again. New measurements are available; ask for them.
## Status

36
docs/re/capture-harness-status.md
View File

@@ -365,7 +365,41 @@ command-line override.
---
# 🔴 2026-08-29 — the disc is not in the decoder container at all
# ✅ 2026-08-29 (later) — the disc is back, and the section below is withdrawn as CURRENT status
Kept for its history, not as a live claim. The container was replaced: PID 1
here started at **11:07:38 UTC**, 25 minutes after commit `b9aca6a` wrote the
section below at 10:42, and the replacement has the disc mounted.
| check | result |
|---|---|
| `/proc/mounts` | `/dev/sda2 /disc ext4 ro,relatime` — a real bind mount |
| device | `/disc` is device **2050**; `/` is device **92** |
| size | 6.2 GB, 74 entries under `dat/`, `default.xex` = 3 497 984 B |
| ISO | `/iso/game.iso`, 7 835 492 352 B |
| end to end | `sylpheed-cli screen list /disc/dat/GP_TITLE.pak` → 12 builds, element/sprite counts matching the committed build map |
⚠️ **Two instruments would have said "no disc" either way, and both are still
in place.** This is the reusable lesson, and it is worth more than the
resolved incident:
* **`find / -xdev` cannot see `/disc`.** `-xdev` refuses to cross a filesystem
boundary; `/disc` is on a different device from `/`. The withdrawn section's
headline measurement — "no ISO, no `default.xex`, no `GP_TITLE.pak` anywhere"
— is what that command returns **whether or not the disc is mounted**. It had
no reach over the question it was used to answer.
* **`sylph-doctor` never checks `$SYLPHEED_DISC`.** Its two disc lines are
`find /work -maxdepth 2 -iname '*.iso'` and `[ -d /work/sylph_extract/dat ]`
(lines 79–82). With the disc at `/disc` it reports "no ISO under /work" and
"no extracted disc — Reborn disc tests will SKIP" — as it does right now,
against a working disc. "`sylph-doctor` agrees" was two instruments sharing
one blind spot, not corroboration.
**To check for the disc, ask the variable that names it**: `ls "$SYLPHEED_DISC/dat"`,
or `sylpheed-cli screen list "$SYLPHEED_DISC/dat/GP_TITLE.pak"`, which fails
loudly and cheaply.
# 🔴 2026-08-29 — the disc is not in the decoder container at all *(WITHDRAWN — see the section immediately above)*
**Status:** ✅ **diagnosed, root-caused in the launcher.** This supersedes every
"the emulator did not reach the title" entry above as the *current* reason the