migratelisted

# Migrate — apply pending FS-side migrations Atelier has two migration surfaces: | Surface | Where | When applied | |---|---|---| | SQLite schema | `backend/src/infrastructure/database/migrations.py` | Auto, on backend boot (`initialize_database`) | | FS state (transcripts, JSON files) | `scripts/migrate-*.py` | **Manual — this skill** | This skill runs everything in the second column. It exists so a contributor can pull a change to logged event shape (or any on-disk schema) and get their existing works migrated without hunting for the right script. ## Steps ### 1. Discover migrations ```bash ls scripts/migrate-*.py 2>/dev/null ``` If nothing matches, say "no FS-side migrations registered" and stop. There's nothing to do. ### 2. Run each, in alphabetical order For each `scripts/migrate-*.py`: ```bash cd backend && uv run python ../scripts/<name>.py ``` The `cd backend` step is intentional — every migration script does `sys.path.insert(0, "<repo>/backend")` so it can import `src.*`, but it still runs better inside the backend venv that owns the dependency tree. `uv run` activates the venv on the fly. Migrations **must be idempotent** — re-running them on already-migrated data is a no-op. That's the contract; don't try to track "have I run this already" state. If a contributor adds a non-idempotent script, that's a bug in the script. ### 3. Surface what each script printed Each script prints its own summary (e.g. "rewrote 3 transcripts; 12 already canonical"). Pas