Exercise 2: migrate dev vs. migrate deploy — Possible Solution
====================================================================

WHAT migrate dev DOES
------------------------------
prisma migrate dev is built for local development. It compares the
current schema.prisma against the database's own migration history,
can generate a brand-new migration file when it detects a real
difference, applies it immediately, and - in certain drift situations,
such as the local database having diverged from what the migration
history expects - can prompt to reset the development database
entirely and reapply every migration from scratch.

WHAT migrate deploy DOES DIFFERENTLY
------------------------------
prisma migrate deploy only applies migration files that already exist,
already committed, in prisma/migrations/. It never generates a new
migration on its own, and it never prompts for confirmation or offers
to reset anything - it simply applies whatever pending migrations exist
and stops.

WHY ONLY migrate deploy BELONGS IN A DEPLOYMENT SCRIPT
------------------------------
A deployment script runs unattended, against a real database holding
real data. migrate dev's own behaviors - generating a migration on the
fly, or resetting the database on drift - would be genuinely dangerous
run automatically against production: an unattended reset could
silently destroy real data, and there's no human present to answer a
prompt that migrate dev might otherwise show. migrate deploy's more
restrained, prompt-free behavior is exactly what a script running
without a human watching actually needs.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly distinguishes what each command can do (generating
migrations and resetting vs. only applying what's committed), and it
correctly explains why the more powerful, interactive command is
unsafe for an unattended production context specifically - not just
that "deploy is the production one" without saying what makes it safer.