0a9bf4e16a
check-all's four remaining red rows. What I established, and two hypotheses that died on the way -- the second is the one worth reading. ✅ build_12 / build_15 are ONE ELEMENT. All 951 differing pixels lie inside pgloading_loop5 (pgloading_ring.png, 333x276 at [1,444]) and the diff's own bbox x 69..301 y 478..710 sits entirely within it. That also answers, with no rule at all, why build_00 and build_01 AGREE: the port's own draw log says they draw 7 elements to build_12's 10, and pgloading_loop5 is one of the three they never draw. The loading screens that agree are the ones that never draw the element the disagreement is in. 🔴 REFUTED, and it looked strong. ui_layout.rs:86 states in its own words that "rotation_deg is decoded but NOT rendered", and the port does render it. A census over all sixteen exported screens gave: every screen with a non-zero rest rotation DIFFERS, every screen without agrees -- 6 of 6 both ways, including both legacy rows. Widening it to any rotating element (rest rotation OR a two-keyframe 360 spinner at any depth) breaks it: build_00 and build_01 carry two spinners each, the port draws both, and they agree with the reference. A rule that holds on 14 of 16 and fails on the two cases nobody had looked at is a rule fitted to the rows it was built from. Recorded rather than deleted, because the ui_layout.rs:86 comment is exactly what the next reader will find. 🟡 main_menu_jp / extras_jp carry the same sweep leaves -- ptloop01/pteff03 at rot 30, ptloop02/pteff03a at rot -45 -- whose phase residual is the reason already named for `title`, and their means (0.79, 0.66) sit with title's 0.44 rather than their EN twins' 3.94 and 6.74. Consistent with, not established: nobody has isolated those leaves on those screens. 🔴 And an asymmetry this exposed, now DECLARED rather than left silent. main_menu_jp contains exactly the six elements main_menu marks additive, and extras_jp all nine of extras'. The map is keyed by screen name and the Decoder's RB_BLENDCONTROL0 log was taken on the ENGLISH screens, so the port draws them additive on EN and alpha-over on JP -- asserting by omission that the JP build blends differently, which is the LESS likely possibility. Both options assert something unmeasured; only one of them was visible. The map is NOT extended (that would extrapolate a measurement onto a build nobody drove to) and the claim is instead written into authored/rendering.json's additive_elements_why, plus a low-priority ask H6 that says out loud it may not be worth a boot -- MISSION §7 puts JP out of scope and it costs two rows. check-all stays red on the same four. Nothing was excused. Not settled: why the two renderers disagree on pgloading_loop5 specifically; the JP blend question; H1 (key repeat); whether the splashes tick at the title's rate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
Sylpheed
A clean-room reverse engineering and port project for Project Sylpheed: Arc of Deception (Xbox 360, 2007).
Three things live here, in one repository so that a change spanning them lands as one commit:
| The decoders | crates/sylpheed-formats — the disc's formats, read and verified disc-wide |
| The port | port/ — a Godot 4 project, plus crates/sylpheed-export which converts a disc into the open asset tree it reads |
| The corpus | docs/re/ — what has been reverse engineered, with its evidence, its retractions and its dead ends |
You need your own copy of the game. No game content is in this repository and none ever will be. The exporter reads the disc you supply.
The oracle is the real game
sylpheed-cliand the Explorer are tools for verifying our decoding. They are hypotheses under test and they have been wrong. When something must be checked against the truth, the truth is the game running in Xenia Canary, captured — not any renderer of ours.
This is stated first because getting it backwards is the most expensive mistake this project has made.
Layout
crates/
sylpheed-formats/ the decoders. Disc-wide verified; the corpus is its spec
sylpheed-cli/ headless tools -- render a screen, dump a table, probe audio
sylpheed-viewer/ the Explorer: a human's window onto the disc. STATIC data only
sylpheed-export/ disc -> the open, moddable asset tree
port/ the Godot 4 project. Reads open formats ONLY
authored/ decisions that are NOT on the disc, each with its reason
data/
base/ generated by the exporter. Gitignored, never hand-edited
mods/ drop-in overrides. Yours
docs/
re/ the corpus: findings, refutations, method traps
game/ how the game is navigated -- menus, modals, flight
port/ the port's mission, its handoff contract, modding rules
-- and RUNNING.md, which is how you actually start it
agents/ how the agent team works together
tools/ capture harnesses, probes, the share tool
exchange/ transient inter-agent files. NOT in git
docker/ the agent containers
Where to start
docs/re/INDEX.md— what is decodeddocs/re/REFUTED.md— what has been tested and dieddocs/re/METHOD.md— traps this project has already paid fordocs/game/navigation.md— how the game is navigateddocs/port/MODDING.md— why the asset tree looks the way it does
Xenia Canary is a separate repository: it is a fork tracking upstream, and it carries our instrumentation.
Conventions
Confidence is per claim, never per document: ✅ CONFIRMED · 🟡 PROBABLE ·
❔ HYPOTHESIS · ❌ REFUTED. A withdrawn result is kept with its reasoning
rather than deleted — that is why the numbers here can be trusted.