70799488fe
PORT-MISSION §3: "When the RE agent later decodes something you had authored, delete the authored entry and let the exporter emit it. That deletion is the measure of progress." This is that deletion. authored/rendering.json's `additive_elements` -- a per-screen list transcribed from the Decoder's per-draw RB_BLENDCONTROL0 log -- is gone. The exporter emits `blend_additive` per element and per nested focus/leaf element from `T8aD +0x04` bit 0x02, and ScreenView reads it there. Both accessor spellings are needed: `ptbtn00f.t32` is in build.sprites while no element carries it as `sprite`, and it is the sharp case -- the plate alpha-over, its own glow additive, adjacent draws on one screen. CHECKED BEFORE THE SWAP, and the map turned out to be a SUBSET, not the answer: 15 elements it called additive the disc agrees with, ZERO contradictions, and 17 MORE the disc marks that it did not. Those include the sweep LEAVES (draw_leaf_for means pteff03/pteff03a are what reach the screen while the map listed their parents) and TWELVE on `title`, where the map was deliberately empty -- so the port has been drawing every title effect with the wrong blend. H6 closes with no capture at all: the JP asymmetry was an artefact of a NAME-KEYED map, and the bit is on the disc for every screen at once. 🔴 AND IT INTRODUCED A REGRESSION, WHICH IS REPORTED, NOT HIDDEN. Against the oracle captures on the GPU: main_menu 10.88 -> 13.02, main_menu_options 11.56 -> 13.57. Deterministic to the digit over three runs, so not sampling noise. Isolated to ONE element, with a control: - main_menu's only newly-additive top-level element is pteff10; - extras gained none and did not move -- the same change on a screen with nothing new moves nothing; - the leaf rule was disabled separately and main_menu stayed at 13.02, so pteff03/pteff03a are NOT the cause. That prediction of mine failed; the rule is restored, being provably neutral here; - title did not move despite twelve newly-additive elements, consistent with verify-capture posing at settle t=198 where those quads are transparent. That is a potential COUNTER-EXAMPLE to a ✅ DECODED claim, and it is a sharp question rather than a guess: their own map lists pteff10 additive on `extras` and not on `main_menu`, and they logged BOTH screens. Asked in BLOCKED.md H6. Shipped anyway, for reasons stated rather than assumed: +2.14 is inside the harness's own ±3.78 capture-phase term for that screen and cannot adjudicate a disc fact; the decoded source is far better evidenced (35 elements, zero errors, out-of-sample prediction 3 of 16); and fitting an exception for one element would put an authored entry back to make one number smaller, which is the move this project keeps having to undo. It is a KNOWN regression, not an unnoticed one. Also settled this iteration, for the Decoder's open question: the port FADES the plate, it does not pop it. Frozen sweep of the plate region -- 210u 0.1457, 216u 0.1573, 222u 0.1727, 228u 0.1900, 236u 0.2142 -- a clean monotone ramp across the declared 214->236. So t=236 is the port's COMPLETION, not its onset, and the 0.367 s "late plus a pop" reading does not apply. Not settled: whether pteff10 has a counter-example; H1's repeat half; the four red verify-screen rows; and finding 3, which still has no cause now that units/s is settled at 60. 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.