9bd7297757
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 9fbb352 replaced it with a path
dependency. The grep returns nothing, the script exits 1, and the binary left
behind predates the merge -- three hours older than the sources, from a revision
nothing points at. The consumer only checked that the file EXISTED.
DECISIONS already carries "the reference renderer was stale for three diff runs"
from P2. This would have been the fourth, by a different mechanism: not a
forgotten rebuild but a build step that could no longer succeed.
The fix is a deletion. Revision-keying solved a two-repo problem -- /reborn's
target/ was a live mount that moved mid-run -- and the monorepo removed that
problem by construction. verify-screen now builds sylpheed-cli from the
workspace, which is the same decoder the exporter and the port read.
BASELINE, all 16 screens, after four milestones of renderer change: no new
drift. The only substantial disagreement is title_jp (max 155, 20498 px), which
is the same one P1 recorded and left open -- ptlogo_eff2 at 125 % scale, where
blit samples the destination pixel's corner and a GPU samples its centre. The
port still does not match it, because matching means reproducing a half-pixel
bias on purpose to make a number smaller.
`max` alone could not tell 2 pixels from 25 000: main_menu and title_jp produced
the same DIFFERS verdict. The script now also reports how many pixels are over
the bar. The bar is NOT raised -- tuning a threshold until things match is the
failure its own header warns about.
Stated plainly because sixteen OK rows look reassuring: the harness renders
--pose=rest, so NONE of the last four milestones' visible work is under test --
not the spinning ring, not the plate composite, not any timeline behaviour, not
audio.
REFUTATION: the RE agent's answer naming "builds 0/1 and 10/11" as the loading
screen is false in the index space this export uses -- entries 10 and 11 are
palogo_sqex and palogo_gamearts, the splashes, which the same agent identified
as such answering my ask 1. Over the twelve is_build bundles, ordinals 10/11 ARE
entries 12/15, so the finding is right and the enumeration is not mine.
authored/screen_names.json is keyed by ENTRY, and someone writing keys "10" and
"11" from that message would name the publisher wordmark and the developer logos
as loading screens, and everything would still validate and run.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WM5XL4HfrHuxz8RiMWdCMC
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
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.