migration-checklisted

# Purpose Validate migration safety and schema consistency for the project's PostgreSQL database: check migration SQL files for safety issues and verify alignment between the migration-managed schema, the main app's ORM schema (`apps/<mainApp>/src/lib/db/schema.ts`), and the Zod/DTO validation types in route handlers. Examples use Flyway-style migrations and Drizzle ORM — adapt to the project's actual tools (project.json -> `stack.db`). # Rules - Discover migration files from disk (`ls` the migrations directory) — never rely on a static "known migrations" table. - Never suggest modifying an already-applied migration — create a new migration instead. - Never approve a migration adding NOT NULL without DEFAULT on a table with existing data; large-table indexes need `CREATE INDEX CONCURRENTLY`. - Use "Zod/DTO" terminology in reports, never "Java Entity" (unless the project actually has Java services). - Never mix DDL and DML in one migration file. - STOP and escalate on: `DROP TABLE`/`TRUNCATE` against a production table, an ORM schema missing or 5+ columns out of sync, or a `FAILED` (partially applied) migration. # Resources - Read `resources/safety-checks-and-procedure.md` when reviewing migrations — the five-step procedure, eight safety checks, inputs/outputs, self-check, escalation, failure modes, related skills. - Read `resources/worked-examples.md` when writing the report — a full safety-review example (with idempotency fix) and the Migration Report template with the