Codex legacy migration

Greenfield Codex releases do not rely on an unbounded chain of old SQL migrations as the primary story. Instead:

1. Baseline schema — Arca applies one manifest-defined DDL snapshot on Turso; schema_version holds the single maintained BASELINE_VERSION (see crates/vox-db/src/schema/manifest.rs). Any MAX(schema_version) not equal to that baseline is treated as non-baseline / legacy for normal opens. Legacy multi-row chains require export → fresh DB → import.
2. Importers — Rust modules read legacy exports or attached old DBs and write normalized rows into the new baseline.

API surface (crate)

• vox_db::codex_legacy in crates/vox-db/src/codex_legacy.rs — verify_legacy_store, LegacyImportSource, JSONL export/import helpers.

Shipped CLI (minimal vox binary)

• vox codex verify — connection + schema_version + manifest-derived reactivity tables + legacy-chain flag
• vox codex export-legacy — dump portable JSONL artifact (LEGACY_EXPORT_TABLES — full baseline user tables except schema_version)
• vox codex import-legacy — full snapshot restore: DELETE all LEGACY_EXPORT_TABLES on the target, then INSERT rows from JSONL (fresh baseline DB only; not a merge)
• vox codex cutover — local legacy file → timestamped codex-cutover-*.jsonl + .sidecar.json, new --target-db, import, verify

See cli.md.

Training telemetry SQLite sidecar (not JSONL cutover)

When the canonical vox.db is still on a legacy chain, VoxDb::connect_default returns LegacySchemaChain until you export, re-init on baseline, and import. Mens training does not open a separate telemetry file automatically. After you migrate the main DB, all training rows use the canonical file.

Operator guide: how-to-voxdb-canonical-store.

Import sources

See Codex vNext schema and ADR 004.