Add the content.isDescription column

[cqnykamp]

Do not let a deploy run this migration. Apply it out-of-band first, mark it applied, then deploy. The full procedure, with the pre-flight results already gathered from prod, is in MANUAL_MIGRATION_PLAN.md.

ALTER TABLE `content` ADD COLUMN `isDescription` BOOLEAN NOT NULL DEFAULT false;

What the column is for

A problem set has no way to include an introduction, a section header, or shared setup text — every child document is a scored, numbered problem.

The viewer already has the concept. SingleDocSource.isDescription marks a document as unscored and unnumbered, and it is already implemented there for question numbering, credit, shuffle anchoring, and the per-item attempt button. There is just no way to set it. This column is where that setting will live.

Nothing reads it yet; the API that uses it is a separate PR. Applying this on its own changes no behavior.

Why it ships on its own

ADD COLUMN on content cannot use instant DDL. The table carries two FULLTEXT indexes (content_name_idx, content_source_idx), which force InnoDB all the way back to ALGORITHM=COPY — a full table rebuild. On dev3 that took 7 minutes 3 seconds, against a 5-minute deploy timeout.

The deploy kills the rebuild partway through. MySQL DDL is not transactional, so the column commits while Prisma's bookkeeping does not, leaving _prisma_migrations with an unfinished row. Every subsequent deploy then fails with P3009 — including a rollback to main — until someone runs prisma migrate resolve by hand. This is not hypothetical; it happened on dev3 on 2026-08-15 at 02:30 UTC.

Prod's content table is larger, so expect longer, with writes blocked for the duration. The underlying timeout problem is tracked in #3027.

Keeping the migration in its own PR means that window gets scheduled and reviewed on its own, and nothing else has to roll back with it.

🤖 Generated with Claude Code