new-migrationlisted

# New migration — scaffold a forward-only migration step Two flavours, picked by the first argument: - **`db`** — adds a step to `backend/src/infrastructure/database/migrations.py`. For SQLite schema changes (new columns, ALTERs). Runs automatically on backend boot. - **`fs`** — creates a new `scripts/migrate-<slug>.py`. For on-disk state (transcripts, work.json, agent.json shape changes). Runs via the `/migrate` skill. Both produce **forward-only, idempotent** migrations — that's the project's convention. There's no "down". ## Usage ``` /new-migration db options-column # bumps SCHEMA_VERSION + adds an ALTER block /new-migration fs transcript-canonical # creates scripts/migrate-transcript-canonical.py ``` ## DB flavour ### 1. Read the current state ```bash grep -n "CURRENT_SCHEMA_VERSION\|if existing ==" backend/src/infrastructure/database/migrations.py | tail -5 ``` Find the current `CURRENT_SCHEMA_VERSION = N` and the most recent `if existing == N:` block (the last one before the unknown-version raise). ### 2. Bump the version + add the new step Edit `backend/src/infrastructure/database/migrations.py`: - Bump `CURRENT_SCHEMA_VERSION` from `N` to `N+1`. - Insert a new block right after the existing `if existing == N-1:` ones, before the `if existing == CURRENT_SCHEMA_VERSION:` final block: ```python if existing == N: # vN → vN+1: <one-line summary of the change>. # # <a paragraph or two on the WHY — what user-visible behaviour # chang