…cal layout

Add @zenstackhq/migration: a native, Prisma-independent schema migration
engine built on Kysely, wired into the CLI behind --native /
ZENSTACK_NATIVE_MIGRATE.

Engine:
- snapshot (SchemaDef -> stable JSON) + diff -> migration.ts (migrate(db))
- migrate dev / deploy / status / reset, plus baseline and
  resolve --applied for adopting an existing (e.g. Prisma-built) database
- Drizzle-like rename resolution via a resolver callback + an interactive
  CLI prompt (data-preserving RENAME instead of drop+create)
- tracking table renamed to zenstack_migration(_lock)

Prisma physical compatibility (verified against Prisma v7):
- constraint/index names (<table>_pkey/_fkey/_key/_idx, mapped names,
  63/64-char truncation) and default type mapping per provider

Drop SchemaDbPusher: testtools now builds test databases via the engine's
DDL applier over the client's own connection (fixes in-memory SQLite);
remove $pushSchema from the client contract. Native migration now supports
delegate (polymorphic) models via the delegate foreign key.

Move migration tests to tests/e2e/migration to break the
migration<->testtools dependency cycle.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Replace the blanket `unsupported` for changed columns with attribute-level
diffing:

- alter-column for type / nullability / default / native-type changes —
  ALTER on postgres/mysql, table rebuild on sqlite (which also covers PK
  changes there); data-preserving, applied via migrate dev/deploy
- alter-enum-add-values: append enum values on postgres
  (ALTER TYPE ... ADD VALUE IF NOT EXISTS)
- rename-aware sqlite rebuild (copy source -> target columns)

Add tests/e2e/migration/alter-column.test.ts and a TODO.md tracking the
remaining gaps vs prisma migrate.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

- add-foreign-key / drop-foreign-key: FK added/dropped on existing columns
  and onDelete/onUpdate changes (previously silently ignored) — drop + re-add
  on postgres/mysql, table rebuild on sqlite
- add-primary-key / drop-primary-key: composite @@id changes drop + re-add the
  constraint on postgres/mysql (sqlite via rebuild); single-@id moves stay manual

Add alter-foreign-key / alter-primary-key e2e tests and update TODO.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Generalize the PK diff to the effective primary key (composite @@id columns
or the single @id column flag), so moving @id from one column to another is a
drop + re-add of the constraint (named deterministically) on postgres/mysql,
and a table rebuild on sqlite — matching Prisma, and better than Drizzle which
can't name the old constraint and leaves the DROP as a manual step.

- columnsEqualIgnoringName / isSimpleColumnAlter ignore the primaryKey flag
  (handled by the PK diff, not as a column alteration)
- add-primary-key carries the new PK columns

Add single-@id move tests; update TODO.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

The full migration suite now runs on TEST_DB_PROVIDER=mysql (107/108, only
the pg-specific enum test skipped). Handle MySQL's DDL differences in the
engine:

- alter-column uses MODIFY COLUMN (Kysely's granular alterColumn emits
  Postgres syntax MySQL rejects)
- drop-index uses `DROP INDEX name ON table`; drop-primary-key uses
  `DROP PRIMARY KEY` (MySQL's PK is always named PRIMARY)
- foreign keys are added/dropped explicitly and ordered (drops before their
  columns, adds after) since MySQL ignores inline REFERENCES and blocks
  dropping an FK column — for both migrate and db push, incl. FK introspection
  and FK-backing-index handling in push
- writer imports `sql` when sql.raw is used

Extend the migration test harness for MySQL (isolated db, introspection,
capped connection pools) and make the native-types test provider-aware.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Add a checksum column to zenstack_migration storing the SHA-256 of each
applied migration.ts. deploy() verifies applied migrations against their
on-disk files first and refuses (returns an error, applies nothing) if one was
edited after being applied — matching Prisma. Checksums are recorded/backfilled
after deploy/reset and by resolveApplied/baseline (legacy rows without a
checksum are tolerated and backfilled).

Add checksum tests; update TODO.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…hanges (mysql)

PostgreSQL can't drop enum values in place, so removal/reorder now emits a
recreate-enum change: create <name>_new, cast every using column over
(USING col::text::new, dropping/restoring column defaults around the cast),
swap names, drop the old type. Appends keep using ALTER TYPE ... ADD VALUE.

MySQL enums are inline in the column type, so value changes are lowered to
the existing alter-column path (MODIFY COLUMN restating the new enum(...)),
one per using column, emitted after the table loop so renames land first.

SQLite enum value changes are now a no-op (enums are plain text there)
instead of surfacing as unsupported.

Both narrowing paths fail at apply time if a removed value is still present
in row data (strict mode on MySQL), matching Prisma's behavior.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Destructive changes (drop table/column, columns lost in a sqlite rebuild,
enum value removals) were generated silently. generate() now computes
warnings from the snapshot diff and, when a confirmDataLoss hook is set,
filters them data-aware against the live database (a warning is suppressed
only when a probe proves no rows are at risk; probe errors keep it) and
asks for confirmation before writing the migration folder.

CLI wiring for migrate dev: interactive terminals get the warning list and
a y/N prompt (default N); non-interactive runs print the warnings and abort
with guidance; --create-only generates and prints warnings without
prompting. Baseline never prompts (it diffs from an empty snapshot).
Without the hook the engine behaves exactly as before.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>