database-migrations

# /supergraph:database-migrations Safe, reversible database schema changes for production systems. Announce: "🗄️ /supergraph:database-migrations — checking blast radius and migration safety..." ## When to Activate - Creating or altering database tables - Adding/removing columns or indexes - Running data migrations (backfill, transform) - Planning zero-downtime schema changes - Setting up migration tooling for a new project ## Steps ### 1. Check blast radius (MANDATORY before writing any migration) Use `CBM_PROJECT`: `search_graph` schema/model symbols, `trace_path` inbound and data-flow, then validated `dependencies`, `hubs`, and `test-gaps` recipes. Schema changes to hub tables (e.g. `users`, `orders`) ripple through repositories, queries, services. If blast radius > 20 files → STOP and discuss with user. **Serena symbol-level impact (optional):** ``` mcp__serena__find_referencing_symbols(symbol=<column_or_model_name>) ``` Finds ORM field references that graph tools see only at file level — e.g. a Prisma field rename that `query_graph` sees as "file touched" but Serena sees as "12 usages in service layer". Skip if Serena unavailable. ### 2. Choose migration pattern Select the appropriate pattern from the sections below (PostgreSQL, Prisma, Drizzle, etc.) based on detected project type from `.supergraph-env`. ### 3. Write migration Follow Migration Safety Checklist before writing SQL/ORM migration code. ### 4. Verify flows After migration written: Use `trace_path(p...