re: land the F5/F6 title-clock corpus (docs/re, reference data, sylpheed-formats) #23
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: fabi/Sylpheed#23
Reference in New Issue
Block a user
Delete Branch "auto/frame-blend-draw-path"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes the gap #8 describes: this is the Decoder's working branch, and none of
its answered work is reachable from
mainyet. 502 files, +76 780/−1 320,514 commits ahead of
main/ 0 behind.What this carries
F5 — does Ⓐ snap or accelerate the title build-in?
f5-a-press-snaps-the-plate.md—read the correction inline, not just the conclusion. The page first
concluded Ⓐ snaps only the plate and refutes
clock: "shared"; apre-registered wider test
(
f5-artwork-window-prereg.md) thenshowed the artwork snaps too, on a control that had been matched inside the
11–12 frame input-latency gap. The corrected answer: one shared clock, Ⓐ
advances it into
[100, 238]. Also landing: the snap target isundecodable-with-reach within
[160,238)(
f5-snap-target-undecodable-with-reach.md),verified against a full-quad reader
(
f5-verified-with-full-quad-reader.md).F6 — what is the human watching, and what drives it.
f6-what-the-human-is-watching.mdplus 11 numbered units (
f6-unit1…f6-unit11) covering the plate/sweepidentity, the parent-alpha gating relationship, the leaf clock in title units,
and the two-leaf period.
f6-out-of-sample-RESULT.mdis included aswritten: 3 of 6 pre-registered predictions failed. The passing half (leaf
period ratio, strip-size ratio, pulse/sweep loop ratio) is what
sylpheed-formatsbuilds on; the sweep→plate separation constant andcheck_labels.pyare explicitly withdrawn in the same page. Issue #9 tracksshaping what's still open from that result — this PR is the corpus as it
stands, corrections included, not a claim that F6 is fully closed.
Everything else on the branch —
docs/re/METHOD.md,REFUTED.md(910-line diff, the R1 reclassification pass), the paint-order/blend-mode/
rotation decode, the boot/GamePart registry work, BGM two-stems, menu-audio
cues, menu-nav semantics, the double-tap latch (H1), and the captures/data
files each finding cites as evidence — is the accumulated, previously
unproposed history of this branch.
docs/port/HANDOFF.mdis the entry point;everything here is reachable from it.
Citations checked
origin/auto/port-p6-audio'sboot.gd/screen_view.gdcitef5-a-press-snaps-the-plate.md,f5-snap-target-undecodable-with-reach.md,f5-verified-with-full-quad-reader.md, andf6-unit10-parent-alpha-gates-the-sweep.mdby path. All four land in thisPR at the paths cited.
Flagging for review, not blocking on
docs/re/captures/carries ~113 MB of PNG screenshots of the running game,committed as evidence cited by specific findings (the pattern
docs/agents/PROTOCOL.md's Files table anddocs/port/DECISIONS.mdbothalready document). That's a different thing from the 545 MB bulk-extracted-
disc-content incident the hard rule was tightened over — no raw disc assets,
no sprites/audio pulled wholesale, one annotated frame per finding — but the
volume is worth a human look given how that incident happened.
Fixed: this PR was red
cargo build -p sylpheed-cliafter resolving the merge's one real conflict(a rustfmt-only clash in
sylpheed-cli/src/main.rs) was not proof the mergewas sound —
sylpheed-viewerbroke without appearing in the conflict at all:this branch added
ComposeOptions::at, andmain's Explorer had a structliteral that predated the field.
at: Nonerestores its exact priorbehavior (the field's own doc comment: "
Nonekeeps the settled composite,which is what every existing caller wants") — no change to the Explorer's
data source, design, or static-only rule.
cargo check --workspace --all-targetsandcargo build --workspaceareboth clean now (pre-existing rustc/clippy debt tracked separately in #12/#13,
not touched here).
Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
The four durations withdrawn yesterday were produced by a classifier costing 1503 ms/frame draining an 8 fps x11grab at 0.64 fps -- a backlog, which preserves ordering and destroys durations. This is the instrument for retaking them. What makes it cheap: every committed capture aligns at exactly dy=0 dx=0 (five-screens-acceptance), so the +/-8 px offset search screen_match does at full resolution is 25 ZNCCs buying nothing on this path. Decimate 4x, do one ZNCC per reference. Measured 8.7 ms per frame including the glyph count -- 173x. Controls, run before the measurement and not after it: * 9/9 content controls, including the two committed movie frames that are the class this oracle exists to reject; * 4/4 on the plate detector itself, which is a threshold on the green-glyph counter and so needs its own control (no-plate title 159, plate title 753, movie frames 0). And three things learned from run 1, folded back in: * do NOT restart the stream once the measurement is under way. Run 1's restart landed 0.25 s after the (A) press and its stale frames straddled exactly the interval being timed; * press INLINE, not through pad.py's subprocess -- an interpreter start plus the 0.25 s hold sat between the press and the timestamp; * count the longest run of byte-identical surface means and report it. That is the freeze signature, and it is how run 2 showed the 26.626 hold is the guest rather than the capture path. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLwThe one number the port said decides a structural question on its side: whether `ScreenView` has to draw two builds at once. It does. The boot title shows build 4 alone, and 2.13 s after build 4 stops animating it composites build 2 over it. Two independent boots agree to 6 ms (2.138 / 2.132), which is under one sample interval. Measure from SETTLED, not from first pixels. "First drawn -> plate" is 3.78 s in one run and 4.26 s in the other, because the build-in animation itself ran 1.64 s and 2.13 s -- that spread is the emulator's frame pacing, and it is exactly the kind of number that looks like a measurement. Ruled out before believing it: that the plate was pulsing all along, too dim for a thresholded glyph counter. The counter reads EXACTLY 154 -- the committed no-plate title's own value -- for every frame of a plateau nearly one full pulse period long, with zero variation, and the surface mean is flat to +/-0.03 across it. A cycling overlay moves both. Also settled, and also not: * the black hold between two screens is 0.14-0.30 s, which brackets the port's authored 0.17-0.23 s and the file's declared 12 units. Their constant stands. * the (A)->menu latency is STILL not available, and now the reason is known. Both runs freeze one frame for ~1.4 s at surface mean 26.626 -- agreeing between runs to six decimals, and reproduced in run 2 with stream restarts disabled, so it is not the capture path. It is a guest load stall: the (B) path, which loads nothing, has no freeze at all. Any figure from it would be an emulator load time. Refutation attempt, recorded whether or not it survived: navigation.md's "the title is not input-ready for about ten seconds, and even then (A) registers roughly half the time". At 7.29 s and 7.28 s after the title settled, (A) was accepted first press in both runs, as was (B) on the menu. n=2 only makes "half the time" unlikely (p ~ 0.25); it contradicts the ten seconds outright. And the standing red banner is withdrawn: the interactive title IS reachable in this container, twice, with no pad input, in ~3.5 minutes. Why it changed is NOT established -- this container came up with no Xenia storage root at all, so run 1 created a profile -- and that is written as a correlation for the next session to test rather than as a cause. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLwThe port hit `sound_bank_riffs("BGM_103.slb")` returning three against a census that says two, and refused to guess which to drop. It was our reader. `to_xma_riffs`'s hybrid branch derives a leading packet stream's start as `first_riff % XMA1_PACKET`. That is right only when the bank header is smaller than one 2048-byte packet -- true of the voice banks the branch was written for (1392/1468/1600/1728), false of a music bank, whose header is exactly five packets. The modulus returned 0 and the whole 10 240-byte header was emitted as sub-wave 0. The header states its own length, so the guard needs no threshold: BE u32 0x800 at +0x18 with the bank id repeated at +0x00 and +0x20, header length in blocks at +0x24. Disc-wide over sound.pak's 9 519 entries, 28 match at offset 0 -- every music bank, ids 1001-1023 and 1101-1105 -- and on 28/28 the declared header ends EXACTLY at the first RIFF. Zero have a gap, so a header and a leading packet stream never coexist here; zero false positives among the other 9 491. Controlled rather than argued: decoding the emitted region through the same chain, on the same bank, in the same run gives 0.009 s of PCM where the bank's real wave 0 gives 87.744 s against a declared 87.75. The region is also 99.1% zero bytes. And the oracle had already said two -- the XMA probe at the main menu saw exactly two streams, at BGM_103's two declared wave sizes. BGM_106-109 are deliberately NOT in the 28: their entries start mid-bank, so they have no header at offset 0 and their leading region is real audio. The VOICE_D_453 recovery is untouched and its tests still pass, 10/10 green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLwThe port put two of my pages against each other: settle->plate 2.135 s and one focus-ring revolution 2.177 s, both a declared 120 units during a static hold, 2% apart against a 6 ms run-to-run agreement. Fair challenge. The resolution is that the question assumes a stable wall clock. Same interval, same container, same day: 2.138, 2.132, and 2.549 s -- a 19% swing, caused by adding --log_ui_draws=true. The 2% is a fifth of that. The two pages were never in conflict about the game; they are three readings of one declared quantity through a clock that moves. What settles the quantity is the disc. Wall clock cannot separate the hypotheses, so I tried to measure frames instead. Both instruments are recorded as failures rather than published as numbers: * Canary's own [UI-CAP] counter -- the one that produced the corpus's 28.5 fps -- costs a third of the frame rate. 300 frames in 16.567 s = 18.11 fps on a screen that gives ~28 without it. That reclassifies 28.5 as a load-dependent lower bound; it does not overturn it. * A distinct-frame counter over the spinning ring FAILED its decisive control: 15.88 fps against the game's own 17.59 in the same window, 10% low, so the ring does not change on every presented frame. Its static control also read 2.63 instead of ~0. Dead, not tuneable, per METHOD.md. The rule that follows, and it applies to everything I hand the port: a measured interval landing near a round number of declared units almost certainly IS that number of units. Ship the units. Also recovered here, because the same question needed it: the static PPC route. Four tools open /work/xenia-rs/sylpheed.db and nothing in this repository builds it -- no disassembler, no PPC decoder, and default.xex is encrypted (zero plaintext "GamePart"). Xenia decompresses the image at load, so dump_image.py reads it out of guest memory and validates it against the corpus's own landmarks: the 29-entry GamePart id table at 0x820A1630 and the Xbox 360 D3D runtime strings. String search and table dumps work again; instruction-level work does not, and the present interval I wanted is an immediate, not a string. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014voBspJ6kFncNErZJuZcLwThe placement region is `frames` records of `{u32 time; 36-byte pose}` after an 8-byte header, so the time word PRECEDES the pose it belongs to. Our parser's 40-byte window opened at the pose, four bytes into the record, and then read the word at its `+36` as that pose's time -- which is the NEXT pose's. Every pose field was right; only the time association slipped by one. Two things the corpus has carried for weeks are that off-by-one and nothing else: "a group's data stops 4 bytes short of its final block's time slot", and "the last keyframe carries no time". The group is not short (8 + frames*40 is exact) and no time is missing -- the first pose's time is the lead-in word at `header + 8` that `parse_placements` skipped without asking what it was. Disc-wide, 33 archives, 13 991 groups, each test with a control: A lead-in prepended to the shifted times is non-decreasing 13991/13991 B a non-zero lead-in is strictly below the next time 5058/5058 control (another group's lead-in, same bundle) 70.9% C multi-segment alpha ramp at a constant rate, corrected 857/1540 the same, under the old reading 0/1042 C is the one that cannot be argued with: interpolation between keyframes is linear, and under the old reading not one multi-keyframe ramp on the disc comes out at a constant rate. Adoption is free on every static composite, which is what the corpus previously declined it over. `SYLPHEED_KF_TIME_SHIFT=1` moved GP_TITLE build 7 by 13.1% of its pixels because it left pose 0 untimed; with the lead-in restored, all 12 GP_TITLE builds render byte-identically, and across 217 builds in six archives only two elements pick a different rest pose -- both times between two poses that are equally invisible. `SYLPHEED_KF_TIME_SHIFT` is gone; `SYLPHEED_KF_TIME_LEGACY=1` restores the old reading for A/B work. ui_header_time_disc needed one line: 546 bundles whose every group is a single static pose now report max_time = 0 where they previously reported no time at all. Excluding them, the result it guards strengthened -- the bound holds over 2 859 bundles instead of 2 313, still with zero violations. Not established: the executable's own parser. Reach is written down. docs/re/ui-keyframe-record-layout.md Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Nsxw1A9JseUw99Yw1ZRQzYThe port hit a 2+1 chunk signature on a resolved movie-voice region and asked whether the bank-header explanation that closed HANDOFF Q10 also covers it, rather than assuming it. It does not, and the discriminator is mechanical. Disc-wide over the 95 English movie-voice regions the manifest binds: 78 open with a bank header -- bank_header_len fires, 10240 B = 5 packets exactly, every time. That is the BGM case. 17 open with a leading headerless stream -- bank_header_len is None, and all 17 have length congruent to 1392 mod 2048, the disc s own derived data offset. No other residue occurs. 0 begin at a RIFF. Counting chunks does not discriminate: 8 bank-header regions also yield three chunks. slb.rs already predicted this in its own doc comment -- the header signature has "zero false positives on the 7993 mid-bank windows, where the leading region IS real" -- and a voice region is a mid-bank window by construction. Also tested the obvious defence of dropping the leading chunk, that it is the predecessor cue s audio: 0 of 17 leading spans lie inside any other resolved region, 0.0 percent on every one. The test finds overlaps where they exist (16 overlapping pairs among the regions, 60 exactly-adjacent boundaries, 73 of 78 bank-header regions starting where another ends), so the zero is not the instrument. Left open, with reach: the census covers movie-voice regions only, and the same stream carries the in-mission VOICE_D_* cues, which are not enumerated -- the leading bytes plausibly belong to one of those. Could not be settled by listening: no XMA1 decoder in this container, and sylpheed-cli audio info reports these chunks as 16 channels / 4310 Hz / 2-bit, which is visibly wrong. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1PdFive corrections across two agents in two days share one shape, and it is worth naming as a family rather than fixing one at a time. None was carelessness about the measurement -- every underlying observation was true of the asset actually looked at. The failure is reaching for the general form in the same breath as the specific one, where the two are indistinguishable on the page and the general one is what the next reader uses. Three were the port s and two were mine, and the entry names both sides: the two chunks are two stems of one performance -- true of a music bank, written as a fact about voice, where one of the two is digital silence the extra bytes are a duplicated channel, not fidelity -- true of ADV, and the size ratio it implies runs 0.0778 to 2.9163 across the disc everything the sequencer paces off rest.t is late -- true of the title, and false of the screens actually checked a three-stream cue is a movie cue -- mine, and BIRD_224 is neither take the highest-rate, highest-gain stream -- mine, and on ADV those two criteria select different streams The counter is the same every time: run the census before writing the rule. Where the census cannot be run, write the specific sentence and say it is specific. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1PdBoth 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_01QsEPXWVaEpyfudtR6re1PdThe ADV audio capture I shared with the port is withdrawn as evidence. They could not match it against anything -- the movie bed, any of the three voice streams, BGM_103, S00A -- with best-vs-runner-up margins of 0.001 to 0.016 everywhere, and they controlled that three ways before saying so. They also noticed capture channels 3 and 6 were byte-identical. That duplicate pair reproduces without the emulator, and it is my capture chain. Six channels each carrying a different tone, played to the null sink and recorded from its monitor with the same parec invocation: sink map NOT matching the client (the original setup) expected 400 800 200 1600 3200 6400 captured 400 3200 200 800 800 200 ch2 == ch5 byte-identical sink map made identical to Canary s stream map, and passed to parec too captured 400 800 200 1600 3200 6400 no duplicates -- CONTROL PASSED PulseAudio remaps when the maps differ, and a 6-channel remap silently drops channels and duplicates others. No error, no warning; the WAV has the right length, channel count and plausible per-channel levels. Withdrawn with it: "all six channels carry signal", and the observation that non-zero surround and LFE weakly supported the 5.1 reading of a voice cue s three streams. The port said a duplicated channel is not an independent one and they were right before this control existed. Unaffected: the three-XMA-context concurrency result, which is read from the emulator s own log rather than the audio path, on two independent boots. The control needed no emulator, no disc and thirty seconds. It was not run, an artefact was published, and the person who found the defect was the one who could not see the instrument. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1PdRecorded 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_01QsEPXWVaEpyfudtR6re1PdThe human identified that both agents were fighting the wrong subsystem, and testing it here confirms the diagnosis and finds the limit. A PulseAudio null sink s MONITOR is sampled on a wall clock: when the client is late PulseAudio does not wait, it emits silence to keep its own timeline. So the 39.3 percent silence in the take-2 capture was never audio that went missing, it was silence PulseAudio invented -- which is why PULSE_LATENCY_MSEC gave a non-monotonic curve and never won. The instrument was wrong, not mistuned. ALSA s file plugin has no clock; it tees exactly what the client writes, so a slow producer yields a shorter file rather than a gap-riddled one. Control with six distinct tones: 12.000 s against a 12.000 s source, 0.00 percent silence, zero gaps, no duplicate channels. Channel order comes out as ALSA s FL FR BL BR FC LFE rather than WAV s FL FR FC LFE BL BR -- deterministic and invertible, not data loss. Three configuration traps recorded in the order they bite: ALSA_CONFIG_PATH replaces the whole config so the stock one must be included; but WITH that include a pcm.!default override silently does not take, in either the inline or the alias form, so the slave must be declared with an inline plugin type and no include; and a pipe to head SIGPIPEs the producer before it writes, which looks exactly like a broken config. And the limit the proposer honestly flagged, now measured: a bare file tee is not enough for Xenia, because its ALSA writer thread pads silence whenever the ring buffer is empty (alsa_audio_driver.cc:359). Against a device that never blocks it free-ran at about 250x real time -- 7.34 GB, 12746 s of nominal audio, in 50 s of wall clock, nearly all driver-generated silence. Killed and deleted; it would have filled the disk. The configuration that satisfies both constraints is a tee in FRONT of a paced slave: type file with slave.pcm { type pulse }. The file plugin captures what the client writes and the slave supplies the clock, so the wall-clock silence insertion happens downstream of the capture point. Control through that exact config: 12.000 s, 0.00 percent silence, zero gaps. Consequences for verification: short file becomes the failure mode, so a capture check needs an expected-duration test alongside silence and gap rate, and a runaway guard is not optional. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1PdFound 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_01QsEPXWVaEpyfudtR6re1PdRecords the settle-time decode, and corrects two claims it overturns. docs/re/structures/ui-settle-time.md is the finding: a settled screen is one instant every element is posed at, the disc names it (the midpoint of the longest keyframe-free interval), and the title's arc closes from 33.22 to 11.79 with the clipped-pixel count landing on the console's 1459 within 0.5%. Includes the disc-wide reach -- only 30% of bundles have a window wide enough to trust -- and a three-way figure. Withdrawn in ui-rotation-implemented.md: * "Flat. No minimum." was not a property of rotation. `at` posed LEAVES ONLY, so the scan moved the light sweeps and never touched the top-level flashes. * "our renderer does not draw ptlogo1/ptlogo2 at all" is wrong. Both are drawn; the four elements the diagnostic named are kind-0x4 ghosts sharing their template's name. Hiding the real ones makes the error WORSE by +5.20 and +7.47. * Its 10.92 baseline is not reproducible -- 14.07 at its own pre-change tag and 14.07 today -- so the "1.7% better" verdict rests on an unrecorded recipe. Flagged in title-residual-tone-vs-geometry.md too. METHOD.md gains two traps: a shared CARGO_TARGET_DIR makes a `git worktree` build silently replace the binary you run next (it cost three renders here, caught only because a missing flag was a hard error rather than a wrong number); and an aggregate computed per-element is not a state of the system. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pdruled out Last iteration I recorded eff3's absence as unexplained after withdrawing a bad explanation for it. The previous capture survived on disk with 6907 frames, and the attract loop returns to the title, so it contains a SECOND build-in at frames 5942..7025. eff3 is absent there too. Three alternative explanations tested and failed: * sampling phase -- eff3 is non-zero for t in (58,64), SIX units, against a 2.23-unit step. A window wider than the step cannot be missed; frames 133 (t=60.1) and 134 (t=62.3) sit inside it and draw eff2 and eff4 instead. * a draw the log cannot see -- exactly 2 draws per frame carry no geometry, on all 932 settled title frames, always the same full-screen-triangle shader, and present on frames where no wipe element is active. * a bad position guess -- dropping position entirely, ZERO quads anywhere on screen in either build-in window have a width within +-30 of 408. The width spectrum jumps straight from 262 to 748. Draw counts across both entries: eff1 4, eff2 3, eff3 0, eff4 6, against ~5 expected each. The four are a right-aligned wipe (938+258, 788+408, 447+749, 64+1133, all ending at x~1196) -- a left-growing reveal in four widths, of which the game draws three. Why is NOT established: nothing in eff3's element record differs from its neighbours. Classified measured, not decoded, and the port is told that dropping eff3 means authoring a behaviour I cannot derive from the file. Two further corrections, both to my own earlier claims: * "frame 107 is the title composited once" was an over-read. It binds NO texture and only 4 of its 27 draws log geometry. The second title entry has no such frame. * the two build-ins are NOT frame-identical. I had that from a coincidentally aligned pair of rows; aligned properly only 4 of 46 frames match. They are the same animation at different sampling phases -- which is precisely what makes the eff3 result robust. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1PdPartly closes ui-prm-primitives.md's standing blocker, "where an UNMEASURED primitive paints". Raised by the port: build_12/build_15 composite to solid black at every instant of their declared life, because pgloading_eff00.prm -- a full-screen opaque quad -- sorts last. The rule is a constraint read off the file, not a preference: an element that covers the screen and is fully opaque at some instant cannot paint above anything visible at that instant. Where the elements visible during its opaque span are ALL of them, its position is forced to first. pgloading_eff00.prm is opaque for 39 instants and all 9 other elements are visible inside that span -> forced first, 4/4 instances. Two controls, both measured orders from the running game, and the rule has to survive both: * palogo_eff0.prm is measured painting FIRST -- opaque 211 instants, forced below 6 of 6. It is NAMED like an overlay, so a name-based rule sorts it wrong against a measured order. Occlusion gets it right. * pteff00.prm is measured painting LAST -- opaque for 2 instants at its screen's entry and exit, forced below only 3 of 23, so the constraint permits it on top where it belongs. Disc-wide: 80 instances forced first, 50 constrained but not forced, 0 unconstrained. The split runs almost exactly along the names -- every *base* is forced, every *eff00* is not -- with three families crossing it, which is exactly why the name is not the rule. It also explains 36 builds the corpus had recorded as "coming out one colour" with no cause: pzeff00.prm is forced first in 32 of 32 instances, so they were wiped by our own sort rather than by the game. The rule's real limit was found by its own disc-wide test failing. Applied to any element it claimed 22 .t32 SPRITES must sort first against their own layer keys -- pneff01.t32 (key 0xd850, #8 of 13) and pbfriendly.t32 (0x9230, #17 of 49). A sprite's ELEMENT alpha says nothing about whether its TEXTURE covers the screen, so forced_backdrop is now restricted to untextured primitives, which is also the only case derived_paint_order consults it for. Reach stated: assumes straight alpha-over (blend mode is still open, and an additive quad at alpha 255 would not occlude); it is a lower bound, not an ordering; and there is no new oracle measurement -- both controls are prior ones, and a loading screen is not reachable from the title path. 3 new disc tests; the 13 paint-order tests are green, including the_derived_order_matches_the_measured_ones_up_to_ties. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1PdFollows the necessity census. 'The order moves' is a property of the sort; the tie-break work already found reorders costing zero pixels, so the picture moving is a separate claim. Rendered each of the 62 deciding builds twice and diffed. 38 .prm deciders: changed_px == ink_px in ALL 38. Without the rule the primitive sorts last, paints over everything, and the screen composites to pure black. The port's original contradiction argument, measured on 38 builds across seven archives instead of argued on two. 24 .tbm deciders: zero -- and that is MY INSTRUMENT, not a finding. The control asked whether the composite had ink; it always does. The question was whether the reordered ELEMENT has ink, and compose draws no pixels at all for a .tbm. So those 24 zeros measure our renderer's blindness by construction. tie_break_pixel_cost.rs already had the per-element ink_mask this needed. Reported rather than quietly patched: a control that cannot fail is the shape this corpus keeps paying for. Also corrects two things the port agent caught: - 'Two renderers, same answer' was true of the six GP_TITLE instances and not of the other 74. The port's re-run of my probe is my code executed twice; its independent leg was removing its own exporter post-pass, which covers GP_TITLE only. The disc-wide 62 has one witness and the page now says so. - forced_backdrop_necessity.rs defaulted to GP_TITLE with no argument, so a bare run printed 6 instances in the same format as 80. It now walks every dat/*.pak and reports the archive count. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vThe port agent produced a genuine second witness for the pixel-cost claim: it re-checked GP_TITLE entry 12 in Godot, which shares no code with compose, swapping only paint_order. 59 530 px ink with the rule, exactly 0 without it. The strong form -- the screen ceasing to exist, not merely changing a lot -- now has two real renderers behind it on that entry. Its figures did not match ours, so I counted the same composite every way: RGB > 0 ours 49 771 Godot 59 530 16 % apart RGB > 1 ours 48 043 Godot 48 368 0.68 % apart The entire disagreement lives in pixels whose value is exactly 1. That is a 1-LSB sampling artefact between two samplers, not a different set of inked pixels. So '>0' is not a portable ink convention between renderers on a mostly-dark frame and '>1' is; any future cross-renderer ink figure should say which it used. Also worth recording: our 49 771 was never a threshold figure. It is exact RGBA inequality between the two paint orders, which over a black backdrop coincides with ink>0 -- so it belongs against the port's 59 530, not its 48 368. Matching it to the 48 368 would have made the two renderers look like they agreed for the wrong reason. The without-the-rule column is 0 at every threshold here too, matching Godot: the strong form is not threshold-sensitive in either renderer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vThe port agent pointed out that forced_backdrop_necessity.rs collapsed sprite_layer_key (a u16 read from the T8aD header, decoded) with implied_layer_key (this crate's table of positions MEASURED in the running game), and that 'has its own key' therefore reads as file-backed when it is not. Splitting them is stronger than either of us stated: read from the T8aD header: 0 implied (measured): 14 10x pfbase.tbm, 4x palogo_eff0.prm nothing at all: 66 62 decided, 4 inert Zero. There is no instance on the disc where a forced element also carries a file-read layer key, so this rule has never been checked against a decoded field -- there is no case where both can speak. That is what a keyless-element fallback necessarily looks like, but it removes a check a reader would assume exists. Also corrects something I said to the port and had wrong. 'None of the 18 is evidence for the rule in any direction' conflated two questions. Whether the rule changes the composite: no, the sort already had the key. Whether the rule gets the RIGHT answer: yes, and the 14 implied keys are measured positions, so this is the rule agreeing with the oracle -- its only external corroboration, and there are 14 instances of it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vTailing the log from BEFORE the music starts cut the unsampled backlog from 616 samples spanning offsets 32..2,559,033 to 125 spanning 32..515,239, so the first pass is sampled like any later cycle. Offsets below loop_start play exactly once, which is why the previous run could not measure them. Wraps at 96.46 / 158.33 / 220.21 s, gaps 61.87 / 61.87, both contexts together. Two derivations, neither converting bits to seconds: (a) time to read_offset crossing loop_start, plus a 1.33 s head correction at a rate measured on 748 timestamped samples of that same stretch (b) first pass (offset 32 -> loop_end) minus the cycle Both give 9.44 s on both contexts -- four numbers, one value. So the loop region is [9.44, 71.31] s of an 87.744 s wave, cycling every 61.87 s. The first 9.44 s is an intro played once; the last 16.4 s, the fade-out bgm-two-stems.md documents, is never played at all. The decoder reads ahead of playback, but both endpoints are read_offset events so the lead cancels in the difference. One boot, one bank. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vApplying my own METHOD entry one iteration after writing it found four refuted statements still asserted unmarked where a reader lands: * envelope correlation 'has no resolving power' -- in three places including HANDOFF. The port controlled the same estimator on a single track and got r=1.0000 at zero offset; the saturation needs CONCURRENT streams sharing timing. I agreed to this in a message and never landed it. * '8 of 10 three-chunk regions' -- still asserted in HANDOFF in a different section from its own correction. * 'r9 is a wild pointer, never a guest address' -- still asserted inside the kept-for-the-record section. * the ALSA channel permutation, stated without scope, when a later capture measured the identity and labelling from it put the silent channel on the wrong name. All four marked in place, striking the sentence and pointing forward. Two lessons added: a 'kept for the record' section still asserts, so labelling the heading is not enough; and naming a refuted claim keeps it greppable, so the audit returns its own corrections as hits and every hit needs reading. The first item is the one worth admitting: I acknowledged that correction in a message, wrote the entry about corrections that never land, and then did not land my own for a full iteration. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vmenu-navigation-semantics.md had this row at yellow with an EMPTY evidence cell, and it is what the port still authors as on_cancel. Delivery-confirmed via [RE-INPUT] (B is kXInputPadB = 0x5801), change detected rather than timed. B delivered at 331.2 s; the glyph leaves 327 by 331.6 and 73.5 % of pixels differ. Both captures name themselves: PROJECT SYLPHEED with the (C)2006,2007 SQUARE ENIX line. Three things measured: * B on the main menu goes to the title; * latency <= 0.4 s at a 4 Hz sample rate, where the corpus previously had this as 'not measured (a backlogged probe void)'; * NO loading screen in between -- the disc carries four pgloading_* bundles and none appears on this path. What the run CANNOT say, recorded in the table rather than glossed: 'B on the title -> nothing' is still unevidenced. The second B was delivered during the title's build-in, so the glyph 0 -> 154 change after it is the build-in completing, not a response. A run that answers that row must wait for the title to settle before pressing. The 're-draws PRESS A after a beat' half of the first row is also still unevidenced -- the run ended with the plate absent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vrest_plateau() selects the LONGEST run of identical adjacent poses, which need not be the run covering the screen's settle instant. rest_vs_settle left a 21.9 % disagreement that I recorded as ambiguous by construction. It is not. CONTROL exactly one plateau, covering the settle instant: 3 072 / 3 072 agree (100.0 %) TEST more than one plateau, at least one covering: 1 622 elements, agree on 586 (36.1 %) of the 1 036 disagreements, rest() landed on a run NOT covering the settle instant: 1 036 -- all of them, no exceptions Both poses are genuinely held in these cases -- they are plateau cases, not transients -- so this is rest() returning a pose the screen has ALREADY LEFT by the time it settles. This corrects my own METHOD entry of two iterations ago, which said a candidate cannot be adjudicated against the incumbent it replaces. Too strong. The bare comparison cannot; the comparison plus a structural property that independently says which side is wrong in each disagreement can. What I lacked was not an oracle but a discriminator. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vWent to refute sylpheed-port's finding that their check-all allowance ("the pin is not on main, so this compares two decoder eras") explained nothing, by extending its reach past three screens. Found the premise is understated. git rev-list --left-right --count origin/main...HEAD -> 0 171 main has nothing we lack; we are 171 commits ahead of it. Its tip is dated 2026-08-29, the pin tag is not an ancestor of it, and its ui_layout.rs still reads "Keyframe time, or None for the group's last frame" -- the pre-fix association that takes a pose's time from the NEXT record and leaves a group's final pose untimed. That is the exact bug that left fade_quads.py stale and made screen-transitions.md publish a 0.87-4.08 s fade-in for a 0.20-0.27 s ramp. So "sync with main first" is currently backwards: main is the stale era, and `git merge origin/main` is a no-op from any topic branch -- it says "Already up to date" every iteration, which reads as "I am current" and means "main has nothing". Do not pin to main. The port's measurement stands: across their three screens the two eras render identically, which is consistent with the association fix moving TIMES and not pixels -- same signature as the .tbm and stale-sylpheed-cli findings. Not settled: whether the eras render identically beyond three screens (the disc-wide build-and-compare is not done), and why 171 commits are unmerged, which is a human's call. Also adds the METHOD entry the port offered: an allowance is a claim and it decays; allow by NAME, never by COUNT, because a count cannot notice that a different row started failing while the total held steady. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vThe mirror of sylpheed-port's sweep after their exit_ramp_units catch, where a refuted 24.0 survived in a `get(..., 24.0)` fallback because the authored entry had been deleted as progress and the deletion was a no-op. 112 fallback sites across sylpheed-formats and sylpheed-cli. 64 supply 0, false, empty or Default -- sentinels asserting nothing. Of the 48 remaining most are pass-through or an extent. Positive control: the filter found media.rs:314 unwrap_or(anchor), the voice-region start fallback landed earlier this session, so the detector finds a known case rather than only reporting absence. The mesh.rs cluster (1.0, 0.85, 0.5, 0.70, 0.45) is env-var tunables with defaults documented in xbg7-mesh.md. ui_layout.rs, the crate the port pins, has 8 sites; 6 sentinel or pass-through and 2 that could fabricate a quantity. Both fabricate a value that is LEGITIMATE, which is worse than the port's conspicuous 24.0: :695 unwrap_or((DESIGN_W, DESIGN_H)) -- 1280x720, which is what every real screen states, so no parser output can distinguish read from invented. MEASURED: it fires 0 times in 965 builds disc-wide, so design_w/design_h is read and the port can rely on it. :1681 kf.time.unwrap_or(0) in the serialiser -- 0 is a real keyframe time (pose 0's time IS 0). Unreachable today under the corrected record layout, the same status as their exit_ramp_units branch, but a fabricated 0 would be indistinguishable from a real one. The measuring instrument failed its own control first: a version reading EVERY RATC child reported all 965 builds stating a non-standard design size (GP_TUTORIAL 12x3), where `screen list` prints 1280x720 for every one -- a T8aD sprite header read at +0x18 is garbage that passes the range test. Filtered to the .rat records, it reproduces screen list exactly. METHOD: a fallback default is an authored value no reader can see, and the dangerous ones are IN-RANGE -- the only way to know is to count how often they fire, which no parser output reveals. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vsylpheed-port pointed out that classifying defaults "by inspection" is exactly the method that cannot see an in-range fallback, and that correction applies to my own sweep from an hour ago: I waved 64 sites through by reading them. Counted instead, disc-wide over 965 builds and 24 811 keyframes: ui_layout.rs:1681 untimed poses (would fabricate t=0): 0 ui_layout.rs:1010 pose_at queries 168 264, None (reads a=0): 0 Two zeroes, which is the result this corpus now distrusts most, so the detector was made to prove it can see a hit: ask pose_at for a time no build declares. The control FAILED -- 10 906 out-of-range queries, 0 None -- so the detector was blind and the :1010 zero measured nothing. The failure is the finding. pose_at is TOTAL: reading the source, its only None path is an `if ks.is_empty() { return None }` guard, and disc-wide there are 0 elements with zero keyframes out of 5 453. So :1010's unwrap_or(0) is unreachable BY CONSTRUCTION, which is stronger than "0 in this corpus" -- and it was established by the control failing rather than by the count passing. Without the control this corpus would have recorded a true conclusion resting on a meaningless number. :1681 stands differently: 0 of 24 811, and time really is Option<u32> with the stale reader demonstrably producing None (its screen info prints a trailing -), so the state is representable and a detector would see it. :973 is not a hazard -- guarded two lines later by `if tmax == 0 { return false; }`, where reading is sufficient because the guard is the proof. METHOD gains both: a zero is worth nothing until the detector is shown able to report non-zero; and the habit under several of this week's errors, which is reading a PROXY for the thing when the thing itself is one command away -- a line count for an era, a type name's spelling for its default, an ordinal for an entry, a fallback's text for its firing rate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vsylpheed-port could not transfer the masking rule to their screens and inferred a precondition: my free-running element is a localised plate I can crop around, theirs is a wide sweep they cannot. Tested against my own screen, that is wrong. The JP title carries the SAME sweep -- the leaves are identical on entries 4, 5 and 7, which I established last iteration -- and it crosses the box: two renders of build 7 on the settled plateau, t=135 vs t=240 whole frame RMSE 12.135 95 791 px in the box RMSE 11.923 57 981 px <- the sweep IS inside the box differences span y 70..674, x 128..1140; the box is y 54..476, x 389..776 So the crop did not exclude the mover, and the in-box between-session term of 0.3215 has no explanation in the crop. Which leaves a tension worth stating: two RENDERS one plateau-phase apart differ by 11.9 inside the box; two CAPTURES of that screen from different sessions differ by 0.32 there; and the --at sweep of renders against a capture is flat to 1.2 across t=135..240, despite those renders differing from each other by 11.9. A metric cannot be insensitive to an 11.9 change unless what changed is largely absent from what it is compared against. Hypothesis, recorded as untested: the game may not draw these leaves on the settled title at all, while our renderer poses them wherever --at says. That would explain the flat plateau, the tiny between-session term and part of the ~40 residual together. It would also mean the port's "the leaf free-runs in the game too" is not established by their evidence -- their two minima come from two DIFFERENT screens, which can differ for reasons other than phase, whereas my two captures are of the same screen and barely differ where the sweep would be. Not claiming the leaves are invisible; that needs a draw-stream check for pteff03/pteff03a on a settled title, which is one run. What is established is narrower and enough to stop the inference. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vThe frame-rate test sylpheed-port and I agreed was the only clean route left. Same strips, same screen, --framerate_limit=15 against the default. The limit demonstrably took effect: the title settled at 862 s against 241 s. First, a gate this work should have had from the start. A slope is only a rate if its residual is random, so count sign changes in the residual: default 1299x1303 -4.348 rms 3.33 43/111 OK 883x1134 +4.284 rms 3.08 21/76 SYSTEMATIC 890x1134 +4.284 rms 3.19 15/54 SYSTEMATIC limit 15 1299x1303 -2.032 rms 1.51 44/83 OK 883x1134 +2.003 rms 1.12 36/61 OK 890x1134 +1.999 rms 0.74 12/37 SYSTEMATIC So one of the two strips I quoted as "agreeing to three significant figures" FAILS the linearity gate at default fps: that agreement was between a rate and a slope through a curve. The port had already caveated the claim for a different reason; this weakens it further from my own side. The result, on the one group passing the gate at both settings: -4.348 px/frame at default against -2.032 at limit 15, a ratio of 2.14. THE LEAF IS NOT FRAME-LOCKED. A fixed number of units per submitted frame predicts px/frame unchanged; it changed by 2.14x. Dead. A simple wall-clock model is dead too, in the other direction: fewer frames per second means more wall time per frame, so a time-driven leaf should move MORE px/frame at a lower limit. It moved LESS. Neither model fits and I have no third. Reach: the effective frame rate was NOT measured. The timing instrument I added polls for the capture log, which is created when the capture is ARMED rather than when it finishes, so it reported 0.728 s and is void. The 3.6x boot slowdown says the limit took effect, not that fps went 28 -> 15. The RATIO is measured; the absolute rate still is not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vsylpheed-port's BLOCKED row asks for a second value on one outgoing screen -- what would make "the gap tracks the outgoing screen" predictive rather than a restatement of the data. First, a correction their ask surfaced without needing a run: THE MENU ALREADY HAD TWO VALUES AND THEY DIFFER -- 0 leaving for the title, 1 leaving for EXTRAS. So "the outgoing screen determines the gap" was too strong and is withdrawn; what holds is an ordering, not a determination. Also recorded: their ask is answerable only from the menu, since the title's sole exit is (A) to the menu and EXTRAS's sole exit is (B) to the menu. Then took a third menu-outgoing measurement, to a screen outside GP_TITLE. Confound named in advance rather than after: that transition leaves the ARCHIVE, so a pak load could inflate the gap for reasons unrelated to the outgoing screen. Result: outgoing quad rises across frames 24-28 (4-5 frames, matching build 5's declared 10-unit close), then ONE empty frame at 30. Gap = 1, identical to menu -> EXTRAS. So the confound is measured ABSENT -- leaving the archive costs no extra black, which is worth having on its own. Six transitions now group as: menu {0, 1, 1} over three different destinations including another pak, EXTRAS {2}, title {3, 3, 3}. The ordering rests on 3+1+3 measurements and the menu's three agree to within one frame. Still not predictive: outgoing closes are 5, 5, 4 frames against gaps {0,1}, {2}, {3}, and EXTRAS has n=1 with no way to obtain a second value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vI recorded EXTRAS as able to supply only one gap measurement because "its sole exit is (B) to the menu", and called that n=1 STRUCTURAL -- a word that retires a question. The disc refutes it in one command: build 6 declares three buttons, ptbtn11/ptbtn12/ptbtn13, all kind 0x3002. The cap was an unverified assertion I had already written into HANDOFF twice. Measured EXTRAS -> a screen outside GP_TITLE via (A): outgoing quad rises across frames 36-40 (4-5 frames, matching build 6's declared 10-unit close), then THREE empty frames at 42, 43, 44, then a different archive builds (23-28 draws/frame against GP_TITLE's 11-14). Gap = 3. So EXTRAS as outgoing gives {2, 3}, and seven transitions now group as: menu {0,1,1} n=3, EXTRAS {2,3} n=2, title {3,3,3} n=3. A pairwise control that holds the destination class constant: menu -> another archive gives 1, EXTRAS -> another archive gives 3. Same kind of destination, gap differs by outgoing screen. That is the strongest support yet for the outgoing-screen dependence because it removes the destination as the variable. But the clean ordering is GONE: EXTRAS {2,3} and title {3,3,3} overlap at 3, so "menu < EXTRAS < title" no longer separates them. What survives is weaker -- the outgoing screen constrains the gap to a ~2-wide band and the bands are not disjoint. METHOD: a structural limit is a claim and needs checking like any other. "Structural" and "impossible" are the two words most worth distrusting in your own notes, because they retire a question rather than answering it and nothing later re-opens them. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vsylpheed-port promoted my unverified "EXTRAS is stuck at n=1, a structural limit" out of a message into DECISIONS.md as an established fact, while holding the file that refuted it -- their own authored/flow.json, recording ptbtn11 -> GP_MISSION_SELECT. Their corollary is sharper than my original entry: distrust "structural" and "impossible" hardest when SOMEONE ELSE writes them, because they arrive without the doubt the author would have had. Swept this side for the same shape. It is clean: port-supplied figures are attributed in the text ("port reports 866 keyframes ... 0 untimed"), the ui_layout.rs comment on the unreachable fallback cites MY OWN measurement of 0 untimed of 24 811 across 965 builds rather than their 866, and their quantisation floor of 0.41 appears in no document of mine at all. Reach stated: this tests attribution WORDING and the port-supplied figures I could enumerate, not every reliance. A negative from a naive check is not proof of absence, and saying so is the point of recording it. What protected it was a habit rather than vigilance -- writing the source into the sentence. That is now the third instance of one remedy: state what the number is a number of; write the index space into the token (e10 rather than "build 10"); write the source into the claim. Put the qualifier in the text, never in the reader's memory. Also fixes the half-guard the port called out. The effective-config block reported `arming on` from screen_id.py, which cannot separate the main menu from EXTRAS -- so it announced "menu" while the run was armed on EXTRAS, a field the guard could not resolve for exactly the two screens in question. It now prints both that value AND the discriminator with its margin, so the ambiguity is visible rather than hidden. NOT yet verified in a run -- per the port's own --no-hold lesson, parsed and edited is not working. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vTwo things in one run, on the screen that motivated both. First, the effective-config guard I had flagged as "not yet verified" -- leaving a doubt in my own file, which is the shape sylpheed-port had just caught themselves in. Verified now: arming on = menu [screen_id: cannot separate menu/EXTRAS] discriminator = extras rmse=18.94 (other main_menu 30.09, margin 11.15) Before the fix this run would have announced "arming on = menu" while armed on EXTRAS. The ambiguity is visible instead of hidden. Second, a replicate of the table's weakest cell. Second EXTRAS -> menu: outgoing quad 229, 255, 255 across frames 29-31, then TWO empty frames at 32 and 33. Gap = 2, identical to the first. Eight transitions now say something sharper than the outgoing-screen story, which is superseded a second time: title -> menu 3, 3, 3 n=3 repeats agree EXTRAS -> menu 2, 2 n=2 repeats agree menu -> title 0 n=1 menu -> EXTRAS 1 n=1 menu -> other 1 n=1 EXTRAS -> other 3 n=1 Every repeated pair is identical -- five replicates, no variation -- and every differing value comes from a different pair. The same origin gives different values to different destinations (menu 0 vs 1, EXTRAS 2 vs 3). So the origin CONSTRAINS the gap and the ORDERED PAIR determines it, reproducibly. For the port: a constant black_hold_units is excluded and keying on the outgoing screen is excluded too. Any keyed version must be keyed on the ordered pair, with a measured value per pair -- six known, two replicated, none predicted by anything declared. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vThree refutations written as prose under ### headings never entered the register: check_refuted.py parses * "claim" lines, so the count stayed at 188. Registered them properly (188 -> 192). A register that parses one syntax silently ignores every other, and it is invisible from the author's side -- ask the register what it holds, do not re-read what you wrote. Both standing false positives were bullets under a header that retracts the whole list, with no marker in the +-4-line window: scope marks them, not proximity. The scan now includes the nearest preceding header and matches markers case-insensitively ('An earlier version' was missed by the marker 'an earlier version'). Controlled by planting a real revival and confirming it is still caught; register now runs clean at 0. Also records sylpheed-port's diagnosis of the phase-lock fallout: a number can be inapplicable rather than wrong, and a tension built on one is manufactured. Plus their point that some claims are not registrable in a substring register at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vskip_intro.sh admits a static screen at d <= 1500 between grabs 0.6 s apart. Over 72 samples of the failing boot the MINIMUM was 1551 -- zero could ever pass. The timeout is unreachable by construction, not bad luck about intro length. The premise is in the script's own comment ('the resting title barely changes') and it is refuted by this session's own draw capture: the title free-runs two full-screen-height sweep leaves and pulses the plate. HANDOFF already said a settled screen is not a static screen. wait_plate_pulse.py, which counts glyph pixels instead of demanding stillness, reached TITLE SETTLED at 245.6 s on the same game the same day. Threshold deliberately NOT raised: 7 of 72 samples fall under 2000, so a gate loose enough to admit this title would also admit movie frames -- the confusion the script's own header records paying for once already. Cost recorded: the focus-persistence question it was booted for is unanswered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vChasing the reach I recorded this morning found the binding it said was missing. Every DLG_ string in the image is pointed at by one aligned word at a 12-byte stride: {u32 handler, u32 id, u32 name_ptr}, spanning 0x820A0A2C..0x820A0D68 with three distinct handlers. Complete -- 70 names, 70 records, none unmatched -- and the ids are banded and monotonic with a single gap at 24. Read from the image directly. Refutation attempt on the shared reach, which both agents had recorded: 'another four-button dialog with the same rows would be indistinguishable'. Scanned every build in every pak for four buttons within 6 px of 259/329/399/469. Control found both incumbents; zero rivals exist anywhere on the disc. So the geometric identification is unique disc-wide, which is stronger than what either of us claimed. Still unbound: id 2000 to a pak entry. The tie remains uniqueness plus the oracle capture, not a pointer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vTwo things, both from reading the image. The record layout is {id, name_ptr, handler}, not {handler, id, name_ptr} as first published -- the same three fields shifted by one word, so every record was credited with the previous record's handler. Caught by a control dump: under the old alignment record 0 had a 'handler' of 0x10000000, not a code address. ids and names are unaffected and DLG_SELECT_DIFFICULTY is still id 2000; only the attribution moved. Corrected histogram over 70 records: 0x821D0808 x43, 0x821D05D8 x24, 0x821CFD80 x3. And the id-to-pak-entry join is not reachable this way. All three handlers load the same global at 0x828E2B14 and two take addresses at 0x828E45E0/4640/467C, and every one of those sits inside a 364 601-byte contiguous zero run -- BSS, populated only at runtime. Controlled: the dialog table itself reads non-zero through the same arithmetic, so the addressing is right and the data is genuinely absent. Reach stated: this closes one route, not the question. 'Not in the image' is not established -- 'not reachable from the dialog handlers' is. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vCloses the one route t32-blend-mode-not-on-disc.md left open: the executable's draw path. Canary's UI draw capture now logs RB_BLENDCONTROL0 per draw, and the game was driven to the main menu and to EXTRAS with F10 at each. The title-side UI uses two blend states and ONE pixel shader: 0x07010701 src=ONE dst=1-SRC_ALPHA alpha-over (premultiplied) ptbase, pteff05, the fade quad, ptmsg, ptmsg2, pttitle, buttons 0x01010101 src=ONE dst=ONE ADDITIVE ptframe1, ptframe2, ptframe3, pteff20, both rotated sweep strips Two controls, both run before the result was read: * the NDC->pixel conversion that identifies a draw by its quad size reproduces 1134 and 1303 px for the two rotated sweep strips -- numbers measured by a different tool in a different session -- on BOTH screens. The tool prints PASS/FAIL and disclaims its own output on FAIL. * pixel shader 0xE59B2B3DA4AA9008 is used with BOTH states, 12 draws additive and 18 alpha-over. ptframe1 and ptbase run the same shader; only the blend register differs. So this is a blend result, not a shader result. This confirms the port's independent measurement -- it solved the composite per pixel from two backgrounds and found additive halves alpha-over's error on both frames -- by a route with nothing in common with it. So the blend is no longer authored: 'any blend you choose is authored' was true of the disc and is not true of the game. What is still unknown is which field selects it; elements sharing a mode are batched into one draw call, so the selection happens before the draw. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vThe human asked both agents for a critical retro; it reached me relayed through sylpheed-port, and I am treating it as a message rather than as their word while staying paused on RE iterations. Worst failure first: I READ the refutation that mattered and routed around it instead of auditing it. REFUTED.md killed the blend bit with our own renderer as its instrument, and I quoted the 'a claim resting on our renderer is a claim about our renderer' rule at the port in the same session while not applying it to my own register. Underneath it is the sharper one: I twice accepted render-derived labels for a disc-side question. My 'no field separates them' negative was tested against a partition that was wrong in six places, all six of which the oracle later called additive. Also recorded: the silent vertex truncation, a coverage claim written rather than computed and wrong by four, a batching generalisation refuted by the log it was written from, and navigation whose fix was worse than the bug. Two additions to the port's list of shared costs: neither of us has ever given a negative a positive control, so 'absent' and 'my search does not work' are indistinguishable in every undecodable page I have written; and we keep attributing a three-way residual to whichever leg we happen to be looking at. Their eight proposals attacked one by one -- P2 sharpened into a re-classification rather than bookkeeping, P5 pushed back on ('suppression localises disagreement; only the oracle labels it'), the rest agreed with amendments. And the check the retro forced: my rival sweep covered the T8aD header and not the 60-byte declaration entry, whose earlier hunt used the corrupted labels. Swept properly, 16 of the 35 measured elements have no declaration entry at all and 0 declaration bits separate the other 19. The decode is not underdetermined -- run because it could have gone the other way. The PROTOCOL delta is presented, not applied. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vThe Port's standing ask list is not in my loop brief, which BLOCKED.md itself records as having cost three sessions. My brief does force HANDOFF.md open every iteration and HANDOFF is mine to write, so the pointer lives there. One line in a file I own; no brief change and no human needed. R11 says a cross-agent pointer must fail loudly when it goes stale, because every staleness incident here has been silent. peer_asks.sh exits 2, 3 or 4 with a message for a missing remote, a renamed branch or a moved file, and lists the branches it can see so the fix is obvious. A blank output is a failure, not an empty ask list. Its own first version was wrong in the way this retro is about. Written as `git show ... || { echo missing; exit 4; }`, piping it into `head` closed the pipe, git died of SIGPIPE, and the fallback printed 'the file is missing' for a file it had just printed in full. An error path that fires on success is worth no more than one that never fires. Existence is now checked with `cat-file -e` and the content exec'd; all four paths were exercised before this commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vThe R11 self-catch existed only in a commit message and a script comment. §5's own rule says the file carries the finding, so it belongs in the retro. Writing the BLOCKED.md pointer, the obvious form -- git show || { echo missing; exit 4; } -- prints "the file is missing" for a file it has just printed in full, because piping into head closes the pipe and git dies of SIGPIPE. An error path that fires on success is worth no more than one that never fires. Same family as the port's MIX default and my vertex cap, with one difference worth keeping: both of those needed an outside observer, and this one did not, because all four paths were exercised rather than the happy one. A script with three failure branches has three tests and they cost a line each. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8vAnswered against the pre-registration committed before the capture. Units per second was the last open number on the PRESS (A) plate, and both prior measurements of it were wall-clock readings off an emulator that runs the guest slow by an unknown factor. They disagreed by 2.9x, because a 30 Hz guest at full speed and a 60 Hz guest at half speed look identical on a wall clock. The ruler here is not a clock. ADV.wmv declares 30.0000 fps in its own ASF header, so a decoded movie frame is a tick the emulator's speed cannot stretch. Presented frames per decoded movie frame is guest_fps/30 with no wall clock in the chain. predicted H_A 30 fps -> 60 units/s -> 1.0 H_B 60 fps -> 120 units/s -> 2.0 measured 1.0000 Both pre-registered guards pass. Guard 2: a perfect repeating 3-buffer cycle, 52 uses each (exactly 156/3), 2 chroma planes per luma on 156 of 156. Guard 1: run lengths are 156 runs ALL of length 1 -- no smear, so the dropped-movie-frame bias that would have pushed the answer toward 120 is measurably absent rather than argued away. So H_A. The port keeps its 60 and changes nothing. REFUTES the live H3 hypothesis that 120 units/s explains the play-test's late plate. That hypothesis was well-formed and attractive precisely because it would have explained the complaint, which is why it needed a ruler that is not a clock. Which means finding 3 still has no cause. The strongest remaining candidate is decoded rather than speculative: the plate's declared onset is t=214, not t=236 -- a 22-unit fade, matching the T=22 the oracle confirmed by measuring +23 alpha per presented frame on that element. The pre-registered control could NOT be run: this logger build emits vb= addresses, not vertex contents, so there was no alpha to check +34 against. A weaker control is substituted and labelled -- the splash shader/blend census, which validates the log's structure (what this measurement uses) and not alpha extraction (which it does not). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5tRan --framerate_limit=30 against predictions committed beforehand. Every discriminating row went to the frame-based column: frame-based time-based (mine) measured presents/s ~27 ~27 28.4 modal alpha step 17 unchanged 34 doubled 17 UNCHANGED units/s ~30 halved ~60 unchanged 30.2 / 30.3 publisher dwell ~8.5 s ~4.2 s 8.450 s DOUBLED developer dwell ~7.0 s ~3.5 s 6.923 s DOUBLED Both controls passed first. The limiter took effect (28.4 presents/host-s against 51-55, interval mass moving from one 60 Hz vblank to two, 422 of 468), and all 8/8 splash quad rects are identical so nothing but the frame rate differs. So the UI clock advances exactly 1 unit per presented frame. The step is 17 on every quad at 28.4, 51.4 and 54.8 presents/s, and 255*1/15 = 17 with the declared T=15. units/second = presents/second, and seconds are not a property of the game. The port's 60 stands: the guest presents once per 60 Hz vblank unconstrained, and 1 unit per present at 60/s is 60 units/s. Same answer as my first position, finally with a tested mechanism instead of an inference. This withdraws units-per-frame-is-not-a-constant.md in its central claim. My "a time-based clock is immune to dropped frames so the dwell is stable" was a real prediction and it failed -- the dwell doubled. The four-run agreement I read as evidence was four runs at similar frame rates. h3-units-per-frame-measured.md's +34 is now the anomaly rather than the rule: 34 per label at 27.2 labels/s against 17 per present at 28.4 presents/s. Both cannot be presents. Not asserting it is wrong, only that one of them must explain the disagreement. Three of my four positions came from inference over a measured quantity; this one came from changing an input and watching what moved. The opportunistic comparison pointed exactly the wrong way because nothing controlled what else differed between those captures. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5tApplying my own lesson to my own corpus rather than only stating it. I exported the content-hash patch and stopped; auditing the docs for "/canary sha" citations found three pages naming d90d14e02, and checking /canary's history found the exposure is four commits deep, not one. Bounded by measurement rather than guess: branch -r --contains puts 590912722 on origin/sylpheed-re and finds no remote for anything after it, so the container-only stack is exactly these four. 0f920e645 blend= per draw <- the ENTIRE blend decode rests on this fa1e4c221 vertex dump 8 -> 64 <- at 8 the log silently dropped four quads of the EXTRAS 24-index batch d90d14e02 RT state, resolves, PS constants ab3203f79 h= content hash The sharpest case is 0f920e645. Without it a draw log records no blend state at all, so ui-blend-mode-decoded.md's 35-element oracle -- which overturned a REFUTED entry and deleted the port's authored blend map -- could not be re-derived by anyone who cloned this repository. The failure mode is silent: the recipe LOOKS complete and only fails for someone on a different machine, long after its author could say what the flag did. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5tQuestion 1's behavioural half is answered elsewhere and measured. This is the other half -- which function -- and it is not found. Recorded as a bounded negative so the next attempt does not repeat four searches. Excluded, all by exhaustive scans of the image: integer lerp shape (divw with mullw and subf within 10 instructions): 28 sites image-wide, NONE in the UI region 0x82200000-0x823FFFFF mulli by 40, the keyframe record stride: 31 sites, NONE in the UI region addi rX,rX,40 in the UI region: 43 sites; the screen/bundle ones at 0x823CCA6C and 0x823CCA94 disassemble to a 40-byte container COPY loop (CTR=10, ten-word copy), a vector reallocation, not an evaluator fmadd-family in the UI region: 811 sites over 142 pages -- too diffuse to select on, so float is neither excluded nor narrowed The first two together say the evaluator does not compute its fraction with integer multiply-and-divide and does not index records by multiplication. With the measured steps landing on exact integers, the likeliest remaining shape is a float lerp with a per-segment reciprocal, converted to a byte -- stated as a hypothesis, not a finding. Names the route I would take next and did not have budget for: trace DOWN from the quad emitter. sub_823C2AC0 has exactly 6 callers, four of them sibling emitters, and sub_822380B0 reads its colour from this+0x04..0x10. Whoever writes those fields is one step from the interpolator. Reach stated: the two opcode negatives are exhaustive over the whole image rather than sampled, but they do not exclude the interpolator living outside the UI region, which is an assumption inherited from ui-quad-class-foothold.md and not independently checked. Not blocking the port: it needs whether to lerp and how, which is answered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5tAnswers question 3 of the 2026-09-02 play-test, from Canary's own source. Gamma: Canary applies NONE. VdGetCurrentDisplayGamma is declared kStub and only reports kernel_display_gamma_type (default 2, TV/BT.709) to the guest so D3D can build a ramp. And the guest does not apply one either, for the splash: its dumped pixel shader is four ALU ops -- tfetch2D, three muls, a max -- with no pow, no ramp, no lookup. Geometry: yes, the presenter resamples. present_letterbox defaults true and present_safe_area_x/y default to 100, so the guest's 1280x720 is scaled to fit the window and letterboxed with nothing cropped. That accounts for a number the corpus has carried without explaining: captures measure the game surface at 1279x675, and a single-pixel oracle placed at 1280x720 coordinates read the copyright line instead. The structural consequence is the useful part. There are two measurement paths and only one has Canary in it: pixels guest draw -> EDRAM -> resolve -> front buffer -> presenter (scale + letterbox) -> X11 -> screenshot -> PNG => carries a resample vertex stream guest CPU writes a vertex buffer -> the draw logger reads guest memory directly => carries nothing The per-frame alpha series is the second path, which is why it can be stated as the game's values rather than as pixels we measured. Everything measured off a PNG carries the resample: every RMSE against a capture, every glyph count, every surface mean. Refutation attempt on this corpus's own founding principle, "the oracle is the real game running in Canary, captured": it SURVIVES but needs a qualifier it has never carried. A PNG capture is the oracle plus a resample. Harmless for ordering, counts, durations and change; a filter in the path for anything pixel-exact. The vertex stream is the stronger oracle and should be preferred where the question can be asked of it. Not measured: the resample's actual filter. I read the cvars saying scaling happens, not the kernel doing it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5tUnit 8's rate (0.514 units/frame) rests on one wrap, a start-to-wrap span rather than a period. Hardening it needs a longer capture with two or more wraps. Two attempts, both failed on the harness rather than the game. First launch never started: the pgrep && echo || { } guard took the wrong branch, no output directory was created and no process ran, while a stale emulator from the previous iteration was still up. It looked like a running capture for several minutes. Second launch started, armed, pressed A and wrote no draw log at all -- canary.stdout stayed at 0 bytes and no xenia_re_ui_draws log appeared, despite the script printing "armed at 8s". Likely a race with the orphaned emulator from the first failure, not confirmed. Unit 8's numbers are unaffected; they came from the intact f6 capture, which is still on disk. The offset has two independent supports; the rate still rests on a single wrap and the port should not ship on it. The lesson, and it is the second harness failure of this shape: "armed at 8s" printed while nothing was being logged. The arming step reports success on SENDING the keystroke, not on the logger responding -- the same silent failure that cost the first F1 probe a run, which I "fixed" by making the window lookup fatal. That fix was too narrow: the window was found, the key was sent, and the log still never appeared. The check that would have caught both is to wait for the draw log to exist and be non-empty after arming, and abort loudly otherwise. A probe that cannot confirm its own instrument is recording is a probe whose negatives mean nothing, and I have now written that bug twice. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5tat, the Explorer's literal didn't`cargo build -p sylpheed-cli` after resolving the merge's one real conflict (a rustfmt-only clash) was not "the merge is resolved" -- it only checked the crate whose conflict I'd just looked at. `cargo check --workspace --all-targets` finds the actual break: sylpheed-viewer's `compose_screen` builds a `ComposeOptions` struct literal, and this branch added a field (`at: Option<u32>`, for posing a composite mid-animation) that main's Explorer code never had to name because every prior caller used `..Default::default()` or the field didn't exist yet. Neither side's diff touched the other's line, so nothing in the conflict pointed at it. `at: None` is the only correct value here -- the doc comment on the field already says so ("`None` keeps the settled composite, which is what every existing caller wants"), and the Explorer's screen view has no notion of mid-animation posing to wire up. This restores its exact prior behavior; nothing about the Explorer's data source, static-only rule, or design changes. PR #23 is red on this. Fixes it in place rather than opening a second PR, since it is the same unit -- a merge I performed that did not actually leave a building tree.Pushed
322869bonto this branch — same PR, no new one needed. Answers issue#9 (shape the F6 out-of-sample residue): a static review connecting the two
plate-relative failures to
f6-unit10's already-decoded finding that thesweep and plate families are separately gated, which means their relative
phase has no structural guarantee of being constant. Repaired
check_labels.pyto stop reporting that as a label failure (split intogating identity checks, still 3/3, and informational timing checks, still
0/2) rather than widening its tolerances. Verified against synthetic data
shaped like the real residue — no capture survives in this container to run
it against real logs. Filed a follow-on (#25) for the capture work this
would actually need. Nothing here reinstates the withdrawn sweep→plate lead.
f3-title-plays-bgm-102-and-103.md's BGM census resolved a literal `addi r5,r0,<imm>` before every call to the play primitive, which is blind by construction to a cue id supplied any other way. Two of the primitive's 34 callers ARE supplied another way -- one is a register passthrough inside a generic 6-caller wrapper `sub_821CCCB0(obj, cueId)` with a -1 "don't play" sentinel. One of its six callers chains back to slot 1 of GamePart_Title's OWN dispatch table at 0x820a3dec, identified by its adjacent RegisterToFactory<0, class silph::GamePart_Title> string -- the same convention already used disc-wide for the other 28 GameParts, not a neighbourhood guess this time. Traced as far as static analysis goes: the field that would carry the cue id traces to a 19-caller shared helper's return value, too common to be title-specific -- reads as "allocate a sound-emitter handle", not "here is the cue". The value most likely gets set at whatever runtime moment the game wants this emitter to speak, which a disassembly listing does not contain. Classified undecodable-with-reach, not a fourth thing -- narrower and better-aimed than the prior reach ("SE goes through a different call"). Every address cited was independently re-decoded from the raw .pe bytes (file offset = VA - 0x82000000), not taken from the database's own mnemonic/operands columns, and all agree. Refutation attempt this iteration: checked whether the "6 callers is exhaustive" claim for sub_821CCCB0 survives indirect dispatch (a plain kind='call' xref scan is blind to a vtable/function-pointer-array entry). Checked function_pointer_array_entries and kind='ind_call' xrefs for all four functions in the chain -- none found. The claim survives. What would close it: --xma_param_probe=true during a title boot's build-in, watching for a newly-decoded stream when the plate reaches full alpha with no input -- the same technique menu-audio-cues.md used for the menu's SE census. Not run this iteration; this is the static half only.Pushed
dff5f77— same PR. Advances issue #5 (F3's sting half): found a real,byte-verified call chain from GamePart_Title's own dispatch table into the
sound-play primitive with a non-literal cue id, distinct from the seven
literal BGM calls already in this PR. Doesn't close #5 — the specific cue
value isn't statically pinned and needs a dynamic check — so #5 stays
state/approvedrather than moving to needs-human.Pushed
9141741— same PR. Advances issue #1: found that this corpus's own"no auto-repeat, measured" claim (menu-navigation-semantics.md, 2026-08-30)
was measuring our scripted pad driver's deliberate one-event-per-press
design, not the game — refutation attempt recorded, claim demoted to
unsettled rather than flipped outright (a second piece of evidence pulls the
other way and isn't resolved). Corrected the row in place, added a REFUTED.md
section, and left a concrete 400 ms/100 ms prediction from Canary's SDL
driver source for the next dynamic run. F1's actual numbers are still open.
Reviewed at
bade9721, reproduced locally in the CI image (rust 1.98.1,--cpus=6 --memory=7g). Red for three independent reasons, not one.1 · Compile error — merge-induced, one line.
ComposeOptionsgained anatfield on this branch;
maincontributed a literal construction of it that doesnot set it.
Fix, verified — with it,
cargo check --workspace --all-targetsexits 0 andthere is nothing behind it:
Noneis right by the field's own doc: it "keeps the settled composite, which iswhat every existing caller wants".
⚠️ This is why
cargo build -p sylpheed-clicould not tell you the merge wasresolved. The conflict was in
sylpheed-cli; the breakage is insylpheed-viewer, which the merge never touched on either side. A merge canbreak a crate whose files did not change — and the crate you just fixed is the
one place the break cannot be, because you just looked at it.
2 · clippy
-D warnings— 10 errors. This branch predates the lint gate, sothese are its own code, not drift:
The five
Keyframeones carry mechanicalhelp:lines.too_many_argumentsisa judgement call — take the
#[allow]with a reason if the signature is right.⚠️ Two of these (
map_or,too_many_arguments) are exactly what #15 is about: Imeasured on 1.98.1, CI floats
@stable. Trust the runner's list over mine.3 · rustfmt — 411 hunks across 107 files, nearly all
examples/.mainhada sweep; these 480 files never did.
cargo fmt --all, committed on its own.Not blocking, but worth knowing:
WASM — WebandFormattingsat pendingfor 40+ minutes behind the failed native job. The runner serialises, so a pending
check here is not necessarily a slow one.
Not merging. Push the three fixes and I will look again when the checks are
green. The ~113 MB
docs/re/captures/question you raised is a separate decisionand does not block this.
— and see #24: nothing in your brief would have brought you back to this PR at
all. That is fixed there, not here.
Pushed
dfbefff— same PR. Continues issue #1: tracedC_PAD_RINGBUFandfound it carries analog-axis-shaped fields alongside the button word, which
rules out a keystroke queue and points at polled state instead — refutes my
own prior naming inference from last iteration. Narrows the next step to
re-running an existing, already-validated draw-log instrument rather than
building a new driver capability. Also closed out #3 (F2 mix) with a pointer
to the already-answered
f2-no-gain-field-in-tables.md, already in this PR— no new commit needed for that one.
Pushed
089aa8d— same PR. First dynamic attempt on issue #1 (previous threeiterations were static-only). Built a new capture harness, hit and fixed
three real infrastructure bugs, found a fourth. The interesting one:
confirmed a fresh, profile-less container reproduces the already-documented
title-a-press-fault.md crash on ANY bare run-canary call — worth knowing for
any future session in a freshly-restarted container, not just this script.
No F1 number yet; ran out of iteration budget after 4 boot attempts before
a clean end-to-end run.
Pushed
2939fa2— same PR. First clean end-to-end run on issue #1's harness(built two iterations ago, debugged through 4 bugs last iteration). Measured
result: holding a direction through the scripted file driver produces one
cursor step and no repeat over ~8s of guest time, tracked per-frame off the
draw log — refutes my own prior lean that coarse sampling was hiding a fast
repeat. Reconciled against the standing human/pad.py conflict: repeat is
very likely Keystroke-REPEAT-driven (a real controller's SDL driver has
this, at a documented 400ms/100ms), and the file driver deliberately never
emits that flag. Named next step (add opt-in REPEAT support to the file
driver) not attempted this iteration.
Pushed
e61937f— same PR. Issue #1 answered: patched Canary's file driver(opt-in Keystroke REPEAT, SDL driver's own 400/100ms constants), rebuilt,
re-ran the null-result capture — cursor now cycles continuously instead of
moving once. Measured 12 frames initial delay, 4 frames steady interval at
29.87fps guest. Moved #1 to state/needs-human and pinged the Port's #2 with
the numbers.
Continues the static lead from two iterations ago (f3-title-sting-mechanism-found-not-value.md) with the dynamic half it named as the next step. Booted with --xma_param_probe=true (the same census menu-audio-cues.md used for the menu's SE cues), no pad input, recording continuously from window-open: a glyph time series (not a threshold trigger) and every newly-seen XMA-PARAM stream, stamped on arrival since Xenia's own log carries no timestamps. Positive control, and a real one: the probe caught the title's two BGM stems starting at t=147.6s, matching f3-title-plays-bgm-102-and-103.md's already-established finding exactly -- the instrument finds a real stream before being asked to find nothing. From the plate's first visible activity through 68 seconds of build-in plus fully-settled pulsing (killed at t=220.1s), zero new XMA streams appeared beyond the two BGM stems and three unidentified early ones (boot splash, not this question). No SE-range stream, no second BGM, nothing -- measured, not the prior static reach limit. Refutation attempt this iteration, recorded either way: my first read of the fine-grained glyph series said BGM and the plate's build-in start at "essentially the same moment". Checking the raw per-sample data instead of a coarse table refutes that -- first non-zero glyph reading is ~0.67s after BGM onset, and immediately noisy rather than a clean climb. Corrected in the doc rather than left as an overclaim for someone chasing frame-accurate sync later. Reference data: docs/re/data/f3-sting-{glyph-timeseries,xma-param-arrivals}.tsv -- derived numeric/log-line data, not a capture of rendered game content.Pushed
3d71388— same PR. Issue #5 (F3) fully closed: the BGM half wasalready decoded, and this iteration measured the sting half dynamically —
no sound plays when the title plate appears, confirmed with a working
positive control (the probe caught the already-known BGM stems on cue) and
68 seconds of observed build-in plus settled pulsing with zero new streams.
Moved #5 to state/needs-human.
Pushed
891c38e— same PR. No emulator-requiring approved item was open thisiteration (everything from this batch landed and moved to needs-human), so
used it for corpus consistency instead: fixed a genuinely stale row in
menu-navigation-semantics.md(NEW GAME's destination was refuted as ahang 2026-08-28, but the page's own table and status line never caught up
to its own correction), and the identical failure mode in my own recent
work (HANDOFF.md's old summary table still quoted the withdrawn
no-auto-repeat finding). Not tied to a specific new question; general
housekeeping.
Pushed the mechanical half —
d394ba6a,cae0a4bd,e6266b19. Verified inthe CI image (
--cpus=6 --memory=7g): check 0 · build 0 · test 228 passed /0 failed / 14 ignored · clippy 0 · WASM 0 · fmt 0 hunks.
⚠️ The clippy list was 80, not the 14 I reported. Clippy stops at the first
failing compilation unit, so my first run only saw as far as
sylpheed-formats'library.
cargo clippy --workspace --all-targets --keep-goingis what makes thelist complete — worth knowing, because the short list looks finished and isn't.
60 were machine-applicable; the rest are in the commit message with reasons.
Two carry a judgement rather than a fix, and can be argued with:
blit's eight arguments get#[allow(too_many_arguments)]. Each is adistinct axis of one draw call; a struct would relocate the list, not shorten it.
#[allow(needless_range_loop)]inblend_vs_t8ad_bit, where the index isinto a map's value and the lookup changes every iteration.
And one thing I took out rather than decided: a dead
let off = b.len();inratc.rs'sfalls_back_to_the_scan_without_an_opt_block. The sibling test at:162computes the same value and assertskids[0].offset == off; this onenever used it. Dropping it is the lint fix. Adding the assertion would be a
test change, and that is yours to make — if it was meant to be there, say so
and it goes back as a real assertion instead.
Nothing in this push touches a finding, a measurement, or a decode path.