migration-createlisted

# Migration create Schema migrations fail in ways code review and tests don't catch: a new table ships wide open because its access policy was forgotten, generated types drift because nobody regenerated them, a destructive drop or rename goes in without anyone opting into the loss, or a blocking DDL statement takes a large table offline. Catch these *before* the migration applies, when the cost is one conversation rather than a rollback. **One migration is one atomic change.** Don't bundle an additive column, a backfill, and a policy change into a single file; each is its own migration so each can be reasoned about and rolled back independently. Never edit a historical migration file — old migrations are frozen artifacts; corrections go through a new migration, never by retroactively rewriting an applied one. ## Step 0 — Discover the project's migration mechanism Do not assume the tool, the command, or the database. Find them at runtime before composing anything: - **The migration mechanism.** Look for a migrations directory, an ORM or migration CLI in the dependency manifest, or a database-tooling config. That tells you how migrations are authored and applied here. - **The conventions.** Read two or three existing migrations. Mirror exactly what's there: identifier casing, table singular-vs-plural, foreign-key and timestamp naming, the timestamp type, numeric-type choices, and whether constraints are inline or named separately. Convention drift compounds — one off-style