mycovault-schema-migrationlisted

# Safely Versioning the Myco Vault SQLite Schema The Myco vault is a SQLite database at `.myco/myco.db`. Its schema evolves through a numbered migration chain — each version is an incremental step applied on top of the previous one. This matters because vaults are long-lived: users have real sessions, spores, and graph data that must survive every upgrade. Breaking the chain means breaking their data. ## Prerequisites - Know which schema version is current. Check `SCHEMA_VERSION` in `packages/myco/src/db/schema.ts`. - Know the migration chain itself — the `MIGRATIONS` registry array and every `migrateVXToVY` function — lives in a *separate* file, `packages/myco/src/db/migrations.ts` (~4,400 lines). `schema.ts` only owns the version constant, the fresh-install DDL application, and `createSchema()`'s driver loop. - Know exactly what you're adding — table name, column names and types, constraints, indexes. - Understand whether the change needs a **backfill** (populating existing rows after adding a column) or is append-only. ## Steps ### 1. Find the schema files and the current version ```bash grep -n "SCHEMA_VERSION = " packages/myco/src/db/schema.ts ``` `createSchema()` (in `schema.ts`) is the driver, not the chain itself: ```ts export function createSchema(db: Database, machineId: string = DEFAULT_MACHINE_ID): void { if (hasSchemaVersionTable(db)) { // existing vault: run any migrations the vault hasn't reached yet for (const migration of MIGRATIONS) {