a04d8a67401425236da11c9b0cb404d2c25ef486
9 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Sylpheed port agent
|
dbbf28e22f |
port: my branch IS the stale era, and verify-screen's reference was never its own build
Told the Decoder their diagnosis was wrong. They were right. ui_layout.rs is md5 b6c19d08 in my working tree, at HEAD, on my pushed branch and on origin/main -- one file, stale marker present, tree clean. What misled me is the same trap a third time: CARGO_TARGET_DIR is a shared /sylph-home/port/target-container, so two source trees write one binary and cargo fingerprints per source path -- each build reports Finished while the binary on disk belongs to whichever tree wrote last. A CLI built from my workspace is 3a39fce (stale, rest t=70), identical to one built from origin/main; the binary verify-screen actually used was 8e0aa76 (fixed, rest t=12), from a tree nobody had named. It happened to be the right era, which is worse than wrong -- it agreed with the pin by luck and one rebuild would have flipped it silently, and title_jp differs by 74507 px between eras. verify-screen now reads the reference CLI's pteff00 rest instant and compares it against the export the port reads, refusing to score if they disagree. Controlled both ways: passes with the matching binary, refuses the stale one built from my own workspace. And the pin is load-bearing, not an annoyance to revert: the workspace crate is stale, so the pin is the only reason the export is correct. Consequence worth stating -- my published branch carries the stale crate, so anyone building sylpheed-cli from it gets the stale decoder. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
a43dee3ab0 |
port: the loading screens are no longer black -- it was the paint order
verify-screen's header has said since P1 that build_12/build_15 render pure black in both renderers, with an open question whether that was the port's bug or the decoders' reading of rest. Measured today: max 214.5 on both sides, mean 1.949 port against 1.918 reference. Not blank, and they agree. It was the paint order. My own earlier measurement had already answered it and I had not connected them: removing the forced-backdrop pass makes the first element pgloading_loop5 and the black screen returns. pgloading_eff00 carries layer: null, layer_source: none -- the only elements in the export with neither a read nor an implied key -- so its position rests entirely on the occlusion constraint. The guard stays, with the stale paragraph kept as history. It was right when written, and a guard that stops firing is the kind that rots out of a tool. Refutation attempt on the Decoder's census scope: my six transient ptlogo_back2eff* on title are also GP_TITLE, so if they were fallback fires their count of four would be wrong. Their claim survives -- all six reach rest by the plateau path, alpha 255->255 with identical pos and scale, so the fallback never runs. The two censuses differ in scope, not in fact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
835acf930e |
port: WITHDRAW the claim that the port drifted away from the game -- wrong frame
The previous entry scored verify-screen's title_jp frame against the oracle and concluded the port had moved away from the game. That frame is posed --pose=rest, which the port does not ship. Posed as it runs, the disputed block scores +0.9994 against the reference's +0.8727, and the whole surface +0.9652 against +0.9200 -- holding under gamma compensation and on the English control (+0.9946 vs +0.9560). The port is closer to the game than the reference on both title screens. Mechanism: ptlogo_back2eff1 is (0,0)(98,0)(100,255)(102,255)(104,0) -- a 4-unit sparkle whose rest.t is the peak of its own flash. Six of them stagger across the logo, so --pose=rest fires every sparkle at once. The 25.6% excess light was real and was in a frame nobody sees. verify-screen is not at fault: it poses rest deliberately, so that both renderers read one decoder and the run is a consistency check. I used a consistency-check frame for a correctness question. Its header now says its frames must never be scored against a capture. A second claim in that entry was also wrong -- both screens draw those layers under pose=rest; I had compared a --menu timeline log against a verify-screen rest log and read a mode difference as a screen difference. verify-capture takes a fifth per-row field, a capture crop, because this capture is a full display frame with the surface at +0+45 while the others are pre-cropped. With it title_jp reads RMSE 20.91 / 1.04%, beside title's 14.16 / 0.21%. The row prints 'no capture' until their branch merges. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
8ae0ec2287 |
port: verify-screen was nondeterministic; pin the pulse phase in the harness
Running the full set after the plate fix, press_start returned over3 5021, 8919, 5021 on three identical runs. The plate's looping focus record takes its phase from time_units, which free-runs, so the captured frame lands wherever the grab fell -- while the reference renderer cannot pulse at all. The port is not the thing that is wrong: the pulse is measured and a thing that pulses does not stop because the screen arrived. ScreenView.loop_phase_units pins it, negative means free-running and stays the default everywhere, and only the harness passes --loop-phase=0. Controlled: pinned, 3 runs identical; free-running, 3 of 4 identical and one different. That 3-of-4 is why it survived -- it looks deterministic most of the time, and without the negative control a no-op flag would have been indistinguishable from a fix. With the phase pinned press_start reads max 1 / over3 0 OK -- the recorded baseline exactly. Fifteen of sixteen rows now match. The sixteenth, title_jp, has genuinely drifted: 155/20498 -> 233/61208, deterministic, on the Godot side, localized to one 350x396 block at (405,74). There is no capture of the Japanese title, so I can say the renderers moved apart but not which moved. Recorded as an ask, not resolved. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
71243bcc60 |
port: confirm no screen of mine carries a .tbm, and guard verify-screen anyway
The Decoder found that sylpheed-cli screen render silently omits the background of any .tbm-bearing build, and stated that none of my screens has one. That is a claim about my tree and it decides whether my regression baseline is sound, so I tested it: zero .tbm across all 16 builds in my manifest -- wider than the five they said. Both controls fired (GP_TUTORIAL build 0 -> pubase.tbm; GP_TITLE build 5 -> none); my first attempt's control printed nothing and I nearly read that as agreement. verify-screen now names the omission on any .tbm-bearing row. It cannot fire on a screen I ship -- which is how a guard goes dead -- so its expression is controlled directly in both directions. No verdict or bar changes. Regression unchanged: title max 6 / over3 790, main_menu max 4 / over3 0. Their identification (reading TUTORIAL off the framebuffer) and my edge correlation (run before their message, blind to the text) agree on GP_TUTORIAL build 0 from no shared assumption. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
fd6d9b6d47 |
port: add check-all; verify-screen ignored its own statistic; 'six expected DIFFERS' was wrong
Eleven tools and nothing ran them together -- the ninth instance of correct, documented and unexercised, one level up. check-all runs the four that assert, reports the oracle table, and gives verify-screen an allowance that EXPIRES when the pin lands rather than standing forever. All eleven exercised first; none had rotted. verify-screen computed over3 because 'a single max cannot tell 2 pixels from 25 444' and then decided the verdict on max alone: main_menu (max 4, over3 0) read DIFFERS while extras (max 3, over3 0) read OK. The bar is unchanged; a frame with no pixel over it now gets its own ROUNDING verdict. And corrects a claim I have given the Decoder more than once. The real count was ten, now eight: six forced-backdrop, two rounding, and TWO UNEXPLAINED -- title at 790 px and title_jp at 20498, neither carrying a forced element. My leaf hypothesis is refuted: emptying draw_leaf_for changes the numbers not at all. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
bb9626defe |
port: the game decodes all three voice streams at once, and two baseline rows were comparing blank frames
TWO FINDINGS, one mine and one handed to me, and the second retires a premise I built on twice. THE P1 BASELINE HAD ROWS THAT PROVED NOTHING. `build_12` and `build_15` render pure black in BOTH renderers -- mean 0, max 0 -- so the difference is zero and `verify-screen` scored them `max 0 over3 0 OK`, the strongest verdict it has. Two of sixteen rows were comparing nothing against nothing. Worse than a missing test, because a missing test is visible in the count. Cause isolated by a control, not by reading: `build_00`/`build_01` are the same loading screen minus three elements and render fine (mean 1.913, max 214.5). The dressed variants add `pgloading_eff00`, a 1280x720 primitive resting OPAQUE BLACK at t=38 inside its own opening black hold, with no layer key so paint order puts it last. The rule I was about to write -- "rest.t before the last timed keyframe is the pathology" -- was killed by running the census first: 152 of 212 elements in this export have rest.t earlier than their last timed keyframe. It is the norm. What is actually unusual is the CONTENT, and its reach is one: `pgloading_eff00` is the only element in the export whose resting pose is a fully opaque full-frame quad. One instance is not a rule, so the renderer is unchanged and the HARNESS is fixed: a blank pair now reports BLANK -- both renderers drew nothing; this row proves nothing. `status` is untouched, so an unrelated DIFFERS still fails. THE VOICE EXPORT IS KNOWN INCOMPLETE. The Decoder booted Canary with --xma_param_probe and the game decodes ALL THREE streams CONCURRENTLY, in three XMA contexts whose byte sizes match the disc payloads exactly. So "three presentations of one take, pick one" is refuted by the running game and the question I had been arguing -- WHICH presentation -- has no answer. This one no census could have caught. Every measurement was right: the streams are equal-duration, one is silence, one is 0.60x another with the residual 26.8 dB down. The frame around them was wrong, and the file says ChannelMask 0x0002 on all three. It took the running game -- which is the mission's own sentence arriving in practice. BEHAVIOUR HELD DELIBERATELY. An equal-gain 1/n sum of channel pairs is not a downmix either -- MISSION section 6 pins an explicit matrix for exactly that reason -- and summing cost S00A 6.02 dB when one stream was silence. Swapping one guess for another on a message is what produced this entry twice. What changed is that the wrongness is now LOUD, because this failure sounds like success: one stream is clean audible dialogue. A top-level manifest warning per movie, the console line, and the authored entry all say `1 of 3 streams`. "They are 5.1" is recorded as the Decoder's HYPOTHESIS with its own counter-evidence attached, and nothing builds on it. What settles it is asked: a recording of the game's own output over ADV through the null sink, which turns channel roles into a fit against an oracle. Refutation attempt, survived: the Decoder's loading-screen variant map. Entries 0/1 carry 7 elements and 12/15 carry those seven plus baseeff, eff00 and loop5 -- exact in count and identity, and it is what made build_00 a control. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF |
||
|
Sylpheed port agent
|
cdea236713 |
port: the P1 regression harness could not have run since the monorepo merge
verify-screen resolves its reference binary to a path build-reference-cli
stopped being able to produce: that script greps Cargo.toml for a
`Syplheed-Reborn.git", rev = "..."` pin, and
|
||
|
MechaCat02
|
65cefa74c3 |
monorepo: one repository for the decoders, the port and the corpus
Some checks failed
Merges the Godot port into the reverse-engineering repository, preserving both
histories -- 1019 commits of corpus plus the port's 31, brought in by subtree
merge and then moved into place so git can follow each file across the rename.
The reason is not tidiness. The two-repo split forced the exporter to depend on
the decoders by pinned revision, and that created a whole class of failure that
now disappears: a sha reachable only from a topic branch, orphaned by a
squash-merge, breaking a fresh checkout silently at build time. It also forced a
live read-only mount of one agent's working tree into another's container, which
is why a contract file could move mid-iteration. With a path dependency, a
decoder change and the exporter change it requires land in the same commit or
not at all.
Canary stays separate: it is a fork tracking upstream.
New structure for the long term:
docs/game/ how the game is NAVIGATED -- menus, modals, prompts, alerts,
and in-game flight. Written so nobody rediscovers it. Mostly
open questions on purpose; the in-game tutorials are the
resource for the flight half.
docs/port/MODDING.md
modding as a constraint on the exporter TODAY, not a later
feature: one logical asset in one file (the disc splits nearly
everything, and resolving that is the exporter's job), names a
person recognises, PNG/OGG/OGV/JSON only, base-and-overrides so
re-exporting is always safe, provenance in every file.
data/base + data/mods
generated tree and drop-in overrides, both gitignored
exchange/ transient inter-agent files, deliberately outside history
docs/agents/ the team protocol
Both the README and the navigation doc lead with the correction that cost the
most: the oracle is the real game under Xenia Canary. Reborn's renderer is a
hypothesis under test, it has been wrong, and treating it as ground truth
propagated into three documents and both agents before a human caught it.
Scripted modding stays possible without being built: no screen name is hardcoded
in GDScript and there is no native code in port/, which is what Godot Mod Loader
needs to be able to substitute behaviour later.
|