bef068479e75809b1ca1ae4b85b8f1b8632b0fdf
16 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
sylph-decoder
|
53997dfcbd |
re: the CLI binary was STALE -- screen info's keyframe times were the old parser's
The copy of sylpheed-cli in this container was built 2026-08-29 12:38, before the keyframe-record-layout fix. The old parser shifted every time by one slot and could not time a group's final pose, printing a trailing '-': stale pteff00.prm 4 kf rest t=70 [12:0,0 70:0,0 80:0,0 -:0,0] fresh pteff00.prm 4 kf rest t=12 [ 0:0,0 12:0,0 70:0,0 80:0,0] Both outputs are well-formed and neither announces its age. That refutes the premise of screen-transitions.md's 2026-08-29 section, which argued from 'there is exactly one untimed keyframe, and every element has it'. There is no untimed keyframe, so the question it answered -- is 0.4 s the missing duration of that keyframe -- has lost its subject. The ratio test in the same section is untouched. And it decodes the number the port asked about: pteff00.prm's final ramp is 70 -> 80 = 10 units, about 0.167 s, not the ~24 this page authored. I tried to refute the port's 10 against the bytes and could not. So the measured ~0.4 s is NOT the ramp alone -- 24 units measured against 10 decoded. That the remaining ~14 units are exactly the black hold is arithmetic that fits (0.233 s, inside this corpus's own 0.17-0.23 s plateau) and is NOT a measurement; the decomposition stays open. CONTAINER-NOTES gains the trap. Renders are byte-identical across the two binaries (max per-channel difference 0 on GP_TUTORIAL build 0), so element identity, pivots, keyframe counts and screen render output are unaffected -- it is the times that move. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
01b8191d90 |
re: the menu BGM loop is NOT captured -- and the rig that cannot take it
Recorded per 'do not improvise around a blocker'. The question is what the game does at BGM_103's loop seam, where the corpus has 'not a seamless loop, no loop-point field found, so the menu loop is authored' and the port measures a 3.4 s near-silent seam. Audio needs the ALSA tee; detecting the title needs video, so --gpu=null was unavailable. Measured twice: the guest runs at ~0.20x real time (76.5 s of audio in 378 s of wall clock) and the title is not reached in 300 s even after tapping A to skip the movie, with the tee's slave ending in a broken pipe and Xenia in underrun recovery. Not a crash -- rss 701 MB with 9.5 GB free, and the 'Killed' line is this harness's own cleanup. REFUTED along the way: CONTAINER-NOTES says --gpu=null runs here die at ~70 s. The intro-audio capture ran 148.02 s under --gpu=null and ended on its probe's timer with the emulator alive and the whole ADV movie decoded. More than twice the quoted lifetime. That note had been the reason not to use --gpu=null for anything long, which is exactly what a clean audio capture needs. The route left, written down rather than attempted: use the XMA probe log as the screen oracle instead of video. Sitting on the main menu decodes exactly BGM_103's two waves, so their byte_sizes appearing IS the menu -- which is better provenance for an audio question than a screenshot anyway. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v |
||
|
sylph-decoder
|
8143499244 |
re: downgrade -- the drift explains the 4.1% in sign, not magnitude
The port refuted the stronger half of the last claim and was right. I wrote that the units/frame drift explained the publisher splash's 4.1% error against its declared dwell. It explains the sign only. Their test verified exactly here: the publisher/developer dwell ratio is 1.2143 declared, 1.2784 as the corpus's three cold boots measure it, and 1.3678 as this container's drift predicts -- so the drift's direction is right and real evidence, but its magnitude is about 2.4x too strong. One refinement, because the means are being compared more finely than n=3 supports: the corpus's three boots individually give excesses of +0.89%, +8.24% and +6.79%, a spread of 7.3 percentage points -- WIDER than the 5.30 pp gap under test -- and boot 1's ratio (1.2251) is essentially the declared 1.2143. This run sits 2.3 sigma above their mean: suggestive, not established. Not closable without a frame log from the corpus's instrument, which was screenshot timing and has none. An attempt to give this side an n of 3 failed on tooling and is recorded: ARM=early loses its F10 about 40% of the time -- two of five runs logged "ARMED EARLY" and produced no draw log at all, with nothing in the session log distinguishing them. Also fences the 33% drift against a misreading the port flagged: it is PRESENTATION pacing and cannot reach keyframe_units_per_second = 60, which is the game's logical rate, decoded under Q1, and which a renderer converts through at its own frame rate. And records a cross-check neither side went looking for: the batch counts are 1 and 2 on the publisher against 3 and 6 on the developer, and the port reports a count restricted to SPRITE-BEARING elements reproduces that exactly from the export -- so palogo_eff0, the layerless forced backdrop, is not in the batched draw, confirmed from the file. Two instruments that disagreed about that element in every previous iteration now agree on which one it is. New tool splash_boundaries.py carries the corrected counting method. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
b562b9bfd5 |
re: the top-level clock freezes at the settle point -- closing the 114-vs-120 gap
Measured in the title draw capture, re-read with the per-quad parser. GP_TITLE build 4 declares t = 0..269, about 120 presented frames at this run's pacing. The title dwell lasted ~1100. ptcopyright declares alpha >= 1 for 106 units (t=138..244) and is drawn for 1050 frames; ptlogo1 declares an exit at t=264 and is drawn for 1095. Both vanish within three frames of the dwell ending. So the top-level clock advances through the build-in, stops inside the settle window [160,236], and holds. The exit ramp is not played on a timer -- it plays when something makes the screen leave. That is ui-settle-time.md's decode seen from the other side and observed in the running game rather than inferred from the file. A nested record keeps looping on its own clock throughout. This closes the 114-vs-120 gap, and it was my arithmetic rather than a discrepancy in the decode. The 2.231 units/frame was regressed over BUILD-IN events -- the only stretch in which the top-level clock advances -- and applied to a period measured over the settled dwell, where that clock is frozen and only the plate's own record is running. Two different clocks. The declared 120 was never in doubt from the calibration-free dark-fraction test. The 51.158-frame period is now confirmed by a second independent estimator: autocorrelation returns lag 51 with clean harmonics at 102 and 154. Its FIRST version failed its control, returning 48 for a period known to be 51.158, because it indexed by sample position where the log's frame numbers have gaps. Recorded, because the failure is the reason the second version can be trusted. Not settled: the sweeps' period. The same validated estimator disagrees between two dwells of one screen -- 515 vs 452 frames for the same family -- and a 14% disagreement within one screen is not a period. The +0x08 field cannot settle it either, since ptloop01/ptloop02 have zero slack. Blocker recorded in CONTAINER-NOTES: a single A press on the title faults the guest. Three menu-capture attempts, two ending in register dumps of 223 MB and 519 MB, against three no-input runs in the same session that all completed. And a guest fault writes an UNBOUNDED register dump to stdout on a filesystem at 91%, so any scripted button press needs a size guard. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
fe70a0cd27 |
notes: build-reborn points at a source root that does not exist either
Found while checking what "Reborn" names. build-reborn line 15 is
SRC="${PROJECT_DIR:-/work}/Syplheed-Reborn" -- transposed letters -- and no such
directory exists; the workspace is at /work itself. It fails immediately with
cd: /work/Syplheed-Reborn: No such file or directory, so the documented way to
run the disc-gated tests is broken in this container.
Records the direct alternative, setting SYLPHEED_DISC by hand, which is what this
session has actually been doing.
This is the second wrapper here pointing at a source root that does not exist --
build-canary has the same defect and blocks the audio tap. Worth checking a
wrapper s SRC before trusting that a green or a failure came from your own code.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd
|
||
|
sylph-decoder
|
18d4fe61f4 |
re: substituted silence destroys information, additive padding does not
The distinction is the port s and it is sharper than the framing this page had. PulseAudio s monitor SUBSTITUTES: audio that existed is replaced by silence to keep the wall clock, so information is destroyed and deleting the holes only compresses time unevenly. Xenia s padding is ADDITIVE: the silence is inserted between samples the guest emitted, so nothing is lost and every real sample is present and in order. So stripping all-channel-zero runs from an ALSA-tee capture is exact rather than a repair, which means even the 0.70x rendered capture at 9.98 percent padding is usable for correlation, where none of the PulseAudio-monitor captures ever were however they were tuned. Recorded as unverified: the port is controlling it by padding a known source to match and checking the stripped result correlates back. Consequence for check-capture recorded too: its silence and gap-rate rule was built when only damage existed and cannot distinguish genuine emulator padding from capture damage, so a FAIL on an ALSA-tee capture is a statement about the recording path rather than the file s usability. Also promotes the runaway guard to a first-class CONTAINER-NOTES entry at the port s request -- 7.34 GB in 50 seconds at about 250x real time is not a footnote -- and adds --gpu=null there, which is what takes the guest from 0.70x to 0.96x and stops the padding, with its two caveats: no video for provenance, and runs die at about 70 s with PM4_DRAW_INDX failures. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
7ff56fee3f |
notes: point the container page at the working audio-capture route
The entry already warned that run-canary is silent twice over, but stopped there -- and fixing only the mutes still yields an unfaithful capture, because a PulseAudio null sink s monitor is wall-clocked and invents silence when the client is late. Adds the pointer to the ALSA file-tee page, with the two things a reader needs before starting: the slave must pace or the tee free-runs at about 250x real time, and a size guard is not optional. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
64b30969d5 |
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
|
||
|
sylph-decoder
|
68aa19283d |
notes: run-canary is silent TWICE over, and the 6-channel stream is a red herring
Completes an entry committed an hour ago that was incomplete, which is worse than absent because it looked authoritative. Fixing SDL_AUDIODRIVER alone still records silence: run-canary also passes --mute=true on its own command line (line 98). With the driver fixed and the mute left alone, Canary attaches a healthy 6-channel stream, holds it at 100 percent volume, reports Corked: no, and emits nothing. Both layers have to go, and "$@" is last so --mute=false on the caller s side wins. Also records that parec defaults to stereo/44.1 kHz and will resample a 6-channel monitor without saying so -- the first successful-looking capture came back 2ch 44100 from a 6ch sink. And a red herring I nearly published as a finding. pactl shows Canary s stream as float32le 6ch 48000Hz with a full 5.1 channel map, which reads as the guest requesting 5.1 and would have been strong support for the hypothesis that a voice cue s three streams are 5.1 channel pairs. It is not evidence about the game at all: AudioDriver::kFrameChannelsDefault is a hardcoded 6, and the code path actually used, SDLAudioSystem::CreateDriver(index, semaphore, &driver), constructs SDLAudioDriver(semaphore) taking every default. The format is Xenia s; only the content of those six channels is the guest s. That is the same failure this corpus recorded in METHOD earlier today -- the specific observation and the general rule reading identically -- caught this time before it was written down rather than after. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd |
||
|
sylph-decoder
|
cb612a82ff |
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
|
||
|
MechaCat02
|
f1b87e47b6 |
decoder: tell it about the reference assets, and that the DB can be wrong
Some checks failed
The mounts landed but the agent could not learn of them: I documented them in CONTAINER-NOTES.md, which the decoder's prompt does not list, and then restarted the container -- so a fresh session with no memory of the exchange had a 586 MB database and a decompressed image sitting unmentioned in its filesystem. Now in the PROMPT itself, not only in a document, because the prompt is the one thing a new session is guaranteed to read. CONTAINER-NOTES.md is also added to its reading list. And the caveat that matters more than the asset. The .pe is PRIMARY -- the bytes the console executed. The database is somebody's ANALYSIS of them, produced by a disassembler that had to guess, and it is wrong in the ways disassemblers are wrong: misdecoded mnemonics where data was read as code, function boundaries short or long or merged or split, coverage missing entirely for code reached only by indirect dispatch, and names that are derived rather than symbols. So a finding resting on a database row is not established until the bytes agree: read the same address out of the .pe and check. Where they disagree the image wins, and the disagreement is itself worth recording, because it tells the next reader which parts of the database to distrust. A fast index into 9.2 MB of machine code, not a source of truth. |
||
|
MechaCat02
|
72b10e7d03 |
decoder: mount the disassembly DB and the flat VA image
Some checks failed
The decoder had neither, and reported the gap precisely: four scripts in this repo READ /work/xenia-rs/sylpheed.db and nothing produces it, so the whole static PPC route was consumers with the producer missing. Both exist on the host and are now mounted read-only: the 586 MB database (25 481 functions, 851 classes with RTTI, EH tables, imports, 1.8M indirect-dispatch candidates) and the decompressed image. The image is the more useful of the two. It is a FLAT VA DUMP -- file offset = VA - 0x82000000 -- so reading a known address needs no XEX decrypt, no LZX, and no booted emulator. The decoder had independently recovered the same bytes by dumping /dev/shm/xenia_memory_* and validating against the GamePart table, which is good work and a sound method, but it noted itself that needing a running emulator is a bad dependency for something the entire static corpus rests on. It does not need one. Also recorded that an earlier claim the .pe was STALE was tested and refuted, so nobody re-litigates it, and that instructions.raw is an INT rather than hex. Written down as reference material, explicitly NOT a deliverable: they are read-only, they come from outside the repository, and a fresh checkout elsewhere has neither. Reimplementing the producer belongs in sylpheed-formats, and until it exists every static finding rests on an artefact this project cannot rebuild. |
||
|
MechaCat02
|
2021eee47d |
agents: merge main at the start of every iteration
Some checks failed
Both agents read the protocol, their mission and the shared tooling from their OWN checkout, and both work on topic branches -- so without an explicit sync they follow whichever version of the rules existed when the branch started. Found concretely: tools/audio-capture and two protocol revisions were on main while the decoder worked for hours from a branch that had neither. The port had merged on its own initiative and did have them, which is exactly the kind of divergence nobody notices until the two disagree about what the rules say. |
||
|
MechaCat02
|
20b3c74b2c |
agents: they never spoke, the decoder lost the disc, and both shared one state dir
Some checks failed
Three defects, all mine, found by checking instead of assuming. **They never exchanged a word.** SendMessage=0, ListAgents=0 across both new sessions. PROTOCOL.md specified in detail what a message MAY and MAY NOT do and never said how to send one or that the other agent was addressable -- they knew that last time only because the human told them directly, and rebuilding with fresh volumes wiped it. Policy without mechanism is prose. Now documented with the two addresses, a worked example, and an instruction to introduce themselves on the first iteration rather than waiting to have a question. **The decoder lost the disc and the ISO.** They used to arrive inside the project mount and silently stopped when /work became a clone. Silently is the word: the disc-gated tests SELF-SKIP without SYLPHEED_DISC and report green, so a whole test suite would have passed while measuring nothing. Both are now mounted explicitly, the ISO at a stable path so run-canary does not depend on host directory names. **Both agents shared one Claude state directory.** They share the host's ~/.claude, and once both working directories became /work they resolved to the same projects/-work/ -- two supposedly independent agents writing to one place, which undoes the point of separate checkouts. Each now has its own volume, seeded once from the host with credentials only, so a token refresh writes locally and neither can corrupt the host's auth. Also widened the pacing rule. It banned ScheduleWakeup by name; the decoder then scheduled itself an hourly cron job -- not harmful, but the same instinct that ended a run yesterday, through a door I had left open. Now: no self-scheduling by any route. Mount audit after the changes: shared and intentional are the exchange volume and the read-only credential seed. Everything else -- repo, Claude state, cargo, target, canary, disc, ISO -- is per agent or one-sided. |
||
|
MechaCat02
|
06676d3dc0 |
containers: each agent clones the monorepo into its own volume
Some checks failed
The last structural fix for the collision class that has bitten three times. Both containers now clone the repository into their OWN named volume instead of bind-mounting a human's working tree, so an agent's local git config cannot capture a human's commits, a credential helper cannot leak a container-only path onto the host, and a `git add -A` cannot sweep another party's in-flight files. Cloned once at startup and never auto-pulled: pulling under a running agent moves files out from under whatever it is mid-edit, which is the same bug again. Accepted knowingly: Claude Code keys per-project memory off the working directory, so moving off the host path starts that memory empty. The corpus in docs/ is the memory that matters and it travels with the clone. Other changes: * docker/agent -> docker/decoder; the launcher is sylph-decoder. Roles, not "the agent", now that there is more than one. * /reborn is gone -- one repository now, so the port reads HANDOFF from its own checkout rather than through a live read-only mount of someone else's tree. * Canary mounts separately at /canary; it stays a fork tracking upstream. * A shared `sylpheed-exchange` volume at /exchange, with tools/ on PATH so `share` is available in both. * The decoder's credential file gets the .host-copy treatment the port already had -- `credential.helper=store` rewrites by rename-over-target, which is EBUSY on a bind mount and reports a fatal that is not one. * Budget split deliberately: decoder 5 cpu / 6 GB, port 3 / 4, leaving room for the planned Referee. "Half the host" was right when there was one agent. Prompts move to docs/agents/ and are rewritten around the protocol: the oracle is the running game, dynamic RE stays with the decoder, each iteration must attempt to refute one claim of the other, and neither may verify its way out of its own role. |
||
|
MechaCat02
|
a8815f2826 |
agents: the team protocol, the share tool, and a player's-eye navigation doc
Some checks failed
**navigation.md rewritten from the player's chair.** It was written from the inside out -- GamePart ids, pak names, sprite names -- which is how WE find things, not what the game shows anyone. Now it describes what is on screen, what you press and what happens, with internals as footnotes. Most rows are open on purpose: it exists to be filled in by playing, and the in-game tutorials are the resource for the flight half. **tools/share** gives transient files provenance without giving them history. Three kinds of thing were travelling down one channel with opposite needs: code and decoded knowledge want permanence, cited evidence wants permanence, and "look at this PNG" wants no history at all. The third kind bloats a repository forever; passing it by message is worse, because the receiver gets bytes with no idea which build produced them. `share put` records who, when, what, the sender's commit, and whether their tree was dirty -- because a capture taken from a modified tree cannot be reproduced from the sha, and the receiver deserves to know that before building an argument on it. **docs/agents/PROTOCOL.md** is the contract. The parts that matter: Dynamic RE stays with the Decoder -- most of what is open is behavioural and cannot be answered from the file. What the planned Referee adds is different: bias enters at what you CHOOSE to capture, so a corpus captured to a fixed protocol by someone with no hypothesis is worth more than one captured to settle an argument. A message may point, ask, prioritise and challenge. It may not change scope, redefine ground truth, or carry a finding instead of writing it down -- including a message claiming to relay the human, because a relayed instruction has no evidence attached and this project has watched a wrong belief travel further and faster than its correction. Adversarial duty is explicit: every iteration, try to refute one claim of another agent and record the attempt either way. Run your own instrument through a control first. Disagreements go to the human with both positions, not to whoever is more certain. And no agent may verify its way out of its own role: the Port has no oracle, the Decoder builds nothing, the Referee interprets nothing. |