Exercise 3: Why Not migrate dev in Production? — Possible Solution
====================================================================

What could go wrong:

  - migrate dev is designed for disposable development databases. If
    it detects drift, or a change it can't apply safely, it can offer
    to reset the database — which deletes all the data. On production,
    that means losing real customers' data.
  - It can create brand-new migrations from whatever schema file is on
    the server. Those migrations were never reviewed or tested, and
    they wouldn't exist in the team's migration history.
  - It needs a shadow database, which production database users
    usually (and rightly) can't create.

What should happen instead:

  1. Migrations are created in development with migrate dev, reviewed,
     and committed to version control.
  2. They're tested on a staging or test database.
  3. Production runs only:   npx prisma migrate deploy
     This applies the committed, pending migrations in order and does
     nothing else — no new migrations, no drift checks, no resets.
  4. Take a backup before migrating, and check with
     npx prisma migrate status afterwards.

WHY THIS WORKS AS AN ANSWER
------------------------------
It names the specific dangers (resets, unreviewed migrations, the
shadow database) rather than just saying "don't", and gives the real
production workflow.