xenia-rs/migration/claude-memory/project_xenia_rs_duckdb.md at e6d43a23ac393004d2e5adf2f0395fd0b5e6448b

Files

MechaCat02 e6d43a23ac chore: add migration/ bundle for cross-machine setup

Bundles state that lives OUTSIDE the xenia-rs repo so a fresh clone on
another machine can be brought up to identical configuration via
migration/setup.sh:

  - claude-memory/             ~/.claude/projects/-home-fabi-RE-Project-Sylpheed/memory/
                               (103 files, 1.1 MB - MEMORY.md + every
                                project_xenia_rs_*.md from audits
                                addis_signext through audit-058)
  - project-root/dot-claude/   <project-root>/.claude/settings.json
                               (Stop hook + permissions)
  - project-root/ppc-manual/   <project-root>/ppc-manual/
                               (PowerPC reference docs, 397 files, 3.7 MB)
  - project-root/run-canary.sh <project-root>/run-canary.sh
  - README.md                  Human-readable setup checklist
  - setup.sh                   Idempotent installer (also reclones
                               xenia-canary at pinned HEAD 6de80dffe)
  - MANIFEST.md                Per-file mapping + per-file-not-bundled
                               restoration recipe

Excluded from bundle (not shippable via git):
  - Sylpheed ISO (7.8 GB; copyright; manual copy required)
  - sylpheed.db (395 MB; regenerable from XEX via analysis tooling)
  - target/ build artifacts (rebuild on target)
  - audit-runs probe firehoses (.log/.stdout/.stderr ~11 GB; rerun if needed)
  - audit-runs memory dumps (.bin ~4.5 GB; rerun audit-026/027/029 if needed)
  - xenia-canary checkout (setup.sh reclones from
    git.mc02.dev/fabi/Xenia-Canary.git at HEAD 6de80dffe)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-10 21:38:38 +02:00

1.0 KiB

Raw Blame History

name, description, type, originSessionId

name	description	type	originSessionId
xenia-rs analysis DB is DuckDB, not SQLite	Reminder that xenia-analysis switched from rusqlite to duckdb — the `.db` extension is misleading	project	f35a2810-e5b7-46ac-a4d9-ea87304be179

Why: Historical — files named like sylpheed.db still use the legacy extension, but the file format is DuckDB (verified via file sylpheed.db → "DuckDB database file, version 64"). xenia-analysis/Cargo.toml depends on duckdb = { workspace = true }; there is no rusqlite. The CLI memory's mention of "SQLite DB" is stale.

How to apply:

CLI sqlite3 path.db will not open it; use python3 -c "import duckdb; con = duckdb.connect('path.db', read_only=True); ..." or install the duckdb CLI.
Schema matches what the CLI memory describes (functions/imports/instructions/labels/metadata/sections/xrefs), just with DuckDB's SQL dialect. SHOW TABLES works; SELECT name FROM sqlite_master also works for compat.
When querying, prefer Python with read_only=True so you don't step on concurrent writers.

1.0 KiB Raw Blame History

1.0 KiB

Raw Blame History