Task 3 found Prisma's generated migration SQL never emits an
explicit ENGINE=... clause, same root cause as the already-accepted
collation exception (no schema-level attribute exists). No practical
impact: the baseline never executes this SQL against the real DB,
and any fresh deploy still gets InnoDB from the server default.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Task 1's reviewer found the original schema.prisma didn't reproduce
db/schema.sql's DDL (DATETIME(3) vs DATETIME, auto-generated index
names, no explicit precision on defaults). Verified the real DDL via
SHOW CREATE TABLE and empirically confirmed @db.DateTime(0) plus
explicit map: names close the gap. Two remaining differences (table
collation, no DB-level ON UPDATE for updatedAt) are Prisma/MySQL
provider limitations with no schema-level fix; documented as
accepted, per user decision, since the baseline never executes this
SQL against the real database and all writes go through Prisma.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Task-by-task plan to replace the mariadb pool/repository with
Prisma Client and baseline Prisma Migrate against the existing
conversion_jobs table without data loss.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Plans the replacement of the raw mariadb pool and hand-written
repository with Prisma Client, plus a no-data-loss Prisma Migrate
baseline against the existing conversion_jobs table.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Covers data model, backend threading through registry/image/imageToPdf/worker, frontend controls, validation, and testing for a new quality/compressionLevel option on image conversions.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
18 bite-sized TDD tasks from project scaffolding through the React
frontend and an end-to-end pipeline test, following the approved design
spec.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
anthony
