xenia-rs/migration/README.md

Cross-machine migration snapshot

This directory bundles the parts of the working state that live OUTSIDE the xenia-rs git repo, so a fresh clone on another machine can be brought up to the exact same configuration without manual file-shuffling.

It is paired with branch chore/portable-snapshot. If you're reading this on a machine other than the original, you are on that branch.

TL;DR — how to set up a new machine

# 1. Clone into the canonical path (matches embedded paths in memory).
mkdir -p ~/'RE Project Sylpheed'
cd ~/'RE Project Sylpheed'
git clone https://git.mc02.dev/fabi/xenia-rs.git
cd xenia-rs
git checkout chore/portable-snapshot

# 2. Run the installer (idempotent; safe to re-run).
bash migration/setup.sh

# 3. Manual steps the script will remind you about:
#    - Copy the Sylpheed ISO into the project root.
#    - Regenerate sylpheed.db once (analysis tooling pulls XEX from the ISO).
#    - Build canary Debug if you intend to run cross-runtime probes.
#    - Switch back to master and continue from HEAD ac2f89a (or merge this
#      branch into master if you want to keep the audit-runs/findings.md
#      history; the branch is purely additive).

What gets installed where

Source under migration/	Target on new machine
claude-memory/ (1.1 MB, 103 files)	~/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/
project-root/dot-claude/settings.json	<project-root>/.claude/settings.json
project-root/ppc-manual/ (3.7 MB)	<project-root>/ppc-manual/
project-root/run-canary.sh	<project-root>/run-canary.sh

Where <project-root> is the parent directory of this xenia-rs clone (i.e. ~/'RE Project Sylpheed'/ if you followed the TL;DR layout).

What is NOT bundled and why

Thing	Why excluded	How to restore on new machine
Sylpheed ISO (~7.8 GB)	Size + copyright; cannot ship via git	Copy manually from the original machine to <project-root>/Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).iso
sylpheed.db (~395 MB)	Reproducible from XEX + analysis tooling; permanent git bloat	After cargo build, regenerate. See Regenerating sylpheed.db below
xenia-canary repo	Separate git project with own remote	cd <project-root> && git clone https://git.mc02.dev/fabi/Xenia-Canary.git xenia-canary && cd xenia-canary && git checkout 6de80dffe. (setup.sh does this automatically if the directory is missing.)
target/ build artifacts	Reproducible via cargo build	cargo build --release
Probe .log/.stdout/.stderr raw dumps (~11 GB)	Already gitignored; only summaries committed	Not needed; rerun the relevant audit if you want fresh logs
Memory-dump .bin files (~4.5 GB)	Captured by audits 026/027/029; gitignored	Re-run those audits if needed

Regenerating sylpheed.db

After cargo build --release succeeds and the ISO is in place:

cd ~/'RE Project Sylpheed/xenia-rs'
# The analyzer binary scans the XEX inside the ISO and writes sylpheed.db
# next to it. (Exact subcommand to be confirmed against current main.rs:
# look near `--analyze` or `analyze` subcommand.)
cargo run --release --bin xenia-rs -- analyze \
  "../Project Sylpheed - Arc of Deception (USA, Europe) (En,Ja).iso"

The output is sylpheed.db (~395 MB) and is gitignored.

If the analyzer subcommand has changed, the source of truth is the post-M1-M12-overhaul analysis crates under crates/xenia-analysis/ + crates/xenia-app/src/main.rs. Check --help for the current invocation.

Picking up where the previous session left off

The most recent audit chain (050-058) is summarized in ~/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/MEMORY.md (restored by setup.sh). Specifically:

• Master HEAD ac2f89a — post-AUDIT-054 VFS layout fix.
• Plateau: swaps=1 / draws=0.
• Last unfinished audit: AUDIT-059. Recommended next step is in project_xenia_rs_audit_058_sub825070F0_activation_2026_05_10.md — pivot to unblocking the AUDIT-049 main-thread wedge (handle 0x12A4), not chasing the static caller ladder of sub_825070F0 further.

To continue: instruct the agent on the new machine to "resume the autonomous audit loop from AUDIT-059 per the memory file's recommendations." The agent should read MEMORY.md first to load context, then dispatch the next audit.

Branch policy

chore/portable-snapshot is purely additive over master:

• Commit 1: audit-findings.md backfill (1943 lines of audit history)
• Commit 2: audit-runs/ summary artifacts (~284 files, ~52 MB)
• Commit 3: this migration/ directory + .gitignore *.bin exclusion

None of the commits touch crate source code. Merging into master is safe once you're satisfied the new machine works. The branch can also be kept as a stable snapshot anchor if you prefer keeping master purely "code".

Verifying integrity post-setup

# After setup.sh:
ls "$HOME/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/" | wc -l   # should be ~103
cat "$HOME/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/MEMORY.md" | head -5
cat "<project-root>/.claude/settings.json" | head -10
ls "<project-root>/ppc-manual/"        # alu/ branch/ fpu/ etc.
ls "<project-root>/xenia-canary"       # should exist after setup.sh
git -C "<project-root>/xenia-canary" rev-parse HEAD   # 6de80dffe

If any of those checks fail, rerun setup.sh from inside migration/.