Marks 0_init as applied via prisma migrate resolve so Prisma's
migration history is in sync with the pre-existing conversion_jobs
table, without running any SQL against the table itself.
Review of Task 1 (d86245a) found two issues:
1. prisma/schema.prisma didn't reproduce db/schema.sql's DDL exactly.
Add @db.DateTime(0) to createdAt/updatedAt/expiresAt/cleanedAt (Prisma
otherwise defaults to DATETIME(3)), and explicit map: names on the
uuid unique constraint and status/expiresAt indexes so they match the
real table's uniq_uuid/idx_status/idx_expires_at. Verified via
`prisma migrate diff --from-empty --to-schema-datamodel`, which now
shows DATETIME(0)/CURRENT_TIMESTAMP(0) and the correct names. Table
collation and updated_at's ON UPDATE CURRENT_TIMESTAMP remain
documented, accepted gaps with no schema-level fix in Prisma's mysql
provider.
2. The original @prisma/client@6/prisma@6 pin used --force without
diagnosing why. Reinstalled with `npm install @prisma/client@6
prisma@6 --save-dev` (no --force) directly against this project's
node_modules: it completed cleanly with no conflicts, confirming
--force was unnecessary.
`prisma validate`, `prisma generate`, and the full test suite
(69 passed, 4 pre-existing failures unrelated to this change) all pass.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
anthonyandClaude Sonnet 5