Since #594 and #601 the only copy of every thread is ~/.tcode/tcode.db; the JSONL originals are deleted once the store opens. Turso is pre-1.0 and the blast radius of a corruption is now the whole store, with the sqlite3 CLI (.recover) as the only fallback.
Proposal: a periodic backup owned by the store, run off the host loop when idle or at startup once per day, using VACUUM INTO '<data dir>/backups/tcode-<date>.db' (supported by Turso 0.8.1; the SQLite backup API is not). Keep the last N copies (3?), verify each with PRAGMA quick_check on the copy, and delete older ones. A 10 GB store copies in tens of seconds; it must not block the UI and must be skipped while a migration is running. Restore is manual for now: stop Tcode, replace tcode.db, remove tcode.db-wal.
Decisions for the maintainer: cadence, how many copies, whether to expose it in Settings, and whether a failed backup should be surfaced in the UI.
Since #594 and #601 the only copy of every thread is
~/.tcode/tcode.db; the JSONL originals are deleted once the store opens. Turso is pre-1.0 and the blast radius of a corruption is now the whole store, with thesqlite3CLI (.recover) as the only fallback.Proposal: a periodic backup owned by the store, run off the host loop when idle or at startup once per day, using
VACUUM INTO '<data dir>/backups/tcode-<date>.db'(supported by Turso 0.8.1; the SQLite backup API is not). Keep the last N copies (3?), verify each withPRAGMA quick_checkon the copy, and delete older ones. A 10 GB store copies in tens of seconds; it must not block the UI and must be skipped while a migration is running. Restore is manual for now: stop Tcode, replacetcode.db, removetcode.db-wal.Decisions for the maintainer: cadence, how many copies, whether to expose it in Settings, and whether a failed backup should be surfaced in the UI.