fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: stop telling people to use the retired xenia-rs #43

Merged
fabi merged 1 commits from docs/retire-xenia-rs-instructions into main 2026-09-16 18:55:49 +00:00
Conversation 0 Commits 1 Files Changed 9 +25 -22
fabi commented 2026-09-16 18:37:31 +00:00
Owner
Copy Link

Instructions and generated text that still sent readers to the retired xenia-rs. Provenance and dated
research records are deliberately left alone: "lifted from xenia-rs", or a finding naming the database it
was measured against, is still true, and rewriting it would falsify the record.

file problem
docs/re/README.md the RE toolchain guide queried xenia-rs/sylpheed.db with xenia-rs/zq.py, and said to prefer xenia-rs probes over Canary
challenge-mission-gate.md, structures/achievements.md reproduction commands python3 xenia-rs/zq.py dis …
sylpheed-xexdb/SCHEMA.md titled after the retired xenia-analysis crate; cited xenia-rs dis
sylpheed-xexdb/src/formatter.rs wrote "generated by xenia-rs" into every disassembly (no test pins it)
sylph-xexdb.rs, db.rs "SQLite" / "writer for xenia-rs"
sylpheed-formats/src/hash.rs pointed at xenia-rs/RE_SYMBOLS.md → docs/re/RE_SYMBOLS.md

Verified: each rewritten reproduction command was extracted from its doc and run as written against the
regenerated database. All 5 exit 0 and return the disassembly they describe. The README's function count
(25 676) comes from the database itself. cargo fmt --all -- --check is clean.

Not changed: the Oracle bullet says Canary's native Linux ELF "crashes / does not run". That's about
Canary, and it conflicts with a July note saying the native build works. Neither claim has been verified here.

🤖 Generated with Claude Code

Instructions and generated text that still sent readers to the retired `xenia-rs`. **Provenance and dated research records are deliberately left alone**: *"lifted from xenia-rs"*, or a finding naming the database it was measured against, is still true, and rewriting it would falsify the record. | file | problem | |---|---| | `docs/re/README.md` | the RE toolchain guide queried `xenia-rs/sylpheed.db` with `xenia-rs/zq.py`, and said to **prefer xenia-rs probes over Canary** | | `challenge-mission-gate.md`, `structures/achievements.md` | reproduction commands `python3 xenia-rs/zq.py dis …` | | `sylpheed-xexdb/SCHEMA.md` | titled after the retired `xenia-analysis` crate; cited `xenia-rs dis` | | `sylpheed-xexdb/src/formatter.rs` | **wrote** *"generated by xenia-rs"* into every disassembly (no test pins it) | | `sylph-xexdb.rs`, `db.rs` | "SQLite" / "writer for xenia-rs" | | `sylpheed-formats/src/hash.rs` | pointed at `xenia-rs/RE_SYMBOLS.md` → `docs/re/RE_SYMBOLS.md` | **Verified:** each rewritten reproduction command was extracted from its doc and run as written against the regenerated database. All 5 exit 0 and return the disassembly they describe. The README's function count (25 676) comes from the database itself. `cargo fmt --all -- --check` is clean. **Not changed:** the Oracle bullet says Canary's native Linux ELF *"crashes / does not run"*. That's about Canary, and it conflicts with a July note saying the native build works. Neither claim has been verified here. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
fabi added 1 commit 2026-09-16 18:37:31 +00:00
docs: stop telling people to use the retired xenia-rs
All checks were successful
CI / Native — linux (pull_request) Successful in 2h4m59s
Details
CI / WASM — Web (pull_request) Successful in 30m45s
Details
CI / Formatting (pull_request) Successful in 1m11s
Details
124b9a1561 
Instructions and generated text that still sent readers to `xenia-rs`, which is
archived and deleted locally. Provenance and dated research records are left as
they are — "lifted from xenia-rs", or a finding stating what database it was
measured against, is still true, and rewriting it would falsify the record.

Changed, because each one tells someone what to do today or writes stale text:

  docs/re/README.md          the RE toolchain guide queried `xenia-rs/sylpheed.db`
                             with `xenia-rs/zq.py`, and its "Dynamic" bullet said
                             to prefer xenia-rs's probe suite OVER Canary. Now:
                             `sylpheed.db` at the repo root (how to build it and
                             re-stamp names), `tools/zq.py`, dynamic = Canary, and
                             `.rdata` reads from the `.pe` (offset = VA - 0x82000000)
                             in place of `--dump-addr`.
  challenge-mission-gate.md, structures/achievements.md
                             reproduction commands `python3 xenia-rs/zq.py dis …`
  crates/sylpheed-xexdb/SCHEMA.md
                             titled after the retired `xenia-analysis` crate,
                             citing `xenia-rs dis`, pointing at a `xenia-analysis`
                             source path
  sylpheed-xexdb/src/formatter.rs
                             WROTE "generated by xenia-rs" into every disassembly
                             it produced (no test pins the banner)
  sylph-xexdb.rs, db.rs      "SQLite" / "DuckDB writer for xenia-rs"
  sylpheed-formats/src/hash.rs
                             pointed at `xenia-rs/RE_SYMBOLS.md`, now at
                             `docs/re/RE_SYMBOLS.md`

Verified: every rewritten reproduction command was extracted from the doc and
run as written against the regenerated database — all 5 exit 0 and return the
disassembly they describe. The README's function count (25 676) is the database's
own. `cargo fmt --all -- --check` clean.

Not changed, deliberately: the README's Oracle bullet says Canary's native Linux
ELF "crashes / does not run". That is about Canary, not xenia-rs, and it conflicts
with a July note that the native build works — unverified either way here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fabi merged commit c082d72bdc into main 2026-09-16 18:55:49 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
agent/decoder
Owned by the Decoder (disc to meaning; runs the emulator)
 agent/port
Owned by the Port (disc to playable; no RE)
 kind/ask
One agent asking the other for something it cannot answer in role
 kind/bundle
A bundle the human defined; agents decompose it into items
 kind/defect
Found by a play-test or a check
 kind/item
One unit of work, small enough to finish in a single session
 state/approved
Human approved the shape; an agent may start
 state/blocked
Waiting on another item; use the Depends-On field, not prose
 state/in-progress
An agent is working it now
 state/needs-human
Done as far as an agent can tell -- a person must look. The body says what to look at
 state/proposed
Agent proposed this item; awaiting the human's approval to start
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
sylph-decoder sylph-pi sylph-port fabi
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fabi/Sylpheed#43
Delete Branch "docs/retire-xenia-rs-instructions"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?