Fabian Hamm 4057bee897 test: report which corpora a run actually had (#16)
`cargo test --workspace` reports the same tally whether the disc corpus was
exercised or entirely absent. Measured: the disc suites RAN on a developer
desktop (1936 s, mesh_consistency_disc alone 1220 s) and SKIPPED on CI
(2.4 s total) -- and both reported 207 passed / 0 failed / 14 ignored across
30 suites.

Two mechanisms compound:

  * a skip is a PASSING test. The gated suites `eprintln!("SKIP: ...")` and
    return early from a test that still passes, so a skipped suite and a
    fully exercised one both score 1 passed. The totals are invariant.
  * the message is invisible. `cargo test` captures a passing test's output,
    so NEITHER log contains a `SKIP:` line. The absence of one proves
    nothing, which makes the obvious check useless too.

And `14 ignored` cannot help: `#[ignore]` is static, so that column is the
literal count of attributes in the source and cannot move at runtime. Ask
what this check would still report if the corpus were entirely absent, and
the answer is 207/0/14.

This is #16's remedy (2) -- the only one that touches the REPORT, which is
the defect. Remedies (1) and (3) improve the control and are left open.

Adds `tests/corpus_report.rs`: always runs, never fails, resolves all three
corpora exactly as the per-suite helpers do, and records what was available.
It writes to a FILE rather than relying on stdout, because a passing test's
stdout is captured and would be invisible in exactly the CI log that needs
it; the workflow then prints that file. It also appends to
GITHUB_STEP_SUMMARY when set.

Run here, it immediately shows the thing the issue is about -- all three
corpora resolve through the HARDCODED fallback, so SYLPHEED_DISC is not
controlling anything on this machine:

  SYLPHEED_DISC   PRESENT via the HARDCODED fallback, NOT $SYLPHEED_DISC
  SYLPHEED_RES3D  PRESENT via the HARDCODED fallback, NOT $SYLPHEED_RES3D
  SYLPHEED_ISO    PRESENT via the HARDCODED fallback, NOT $SYLPHEED_ISO

The ABSENT branch is the one CI takes and cannot be reached on a machine
that has the corpora, so `resolve_renders_every_branch` exercises it
directly rather than shipping it unrun -- along with "set but does not
resolve", which is what a typo in the env var produces and which is
deliberately reported as a DIFFERENT state from absent, since the two want
different fixes.

Verified: `cargo fmt --all -- --check` clean. Clippy is unchanged by this
(a test target; CI's `cargo clippy --workspace` does not build test cfg) --
it fails identically on unmodified main here with
`only_used_in_recursion` at vfs.rs:85, which is the rustc 1.90.0 vs the
runner's 1.98.1 divergence, i.e. #15, not this.

Refs #16

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-09 07:39:49 +02:00

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-cli and 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

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.

Description
No description provided
Readme MIT 820 MiB
Languages
Rust 57.6%
Python 27.7%
Shell 10.6%
GDScript 3.5%
Dockerfile 0.4%
Other 0.1%