Database schema drift recovery after partial migration failure in Prisma

Problem Context

Prisma Migrate maintains a _prisma_migrations table that tracks which migrations have been applied to the database. This table includes an applied column that indicates whether a migration has completed successfully.

Unresolved Behavior

When a migration fails partway through execution—particularly one that includes multiple DDL statements—the database may end up in an inconsistent state. Some schema changes may have applied while others did not, yet the migration record may incorrectly reflect the state. The prisma migrate dev command may detect this drift and propose a reset, but the actual behavior depends on the database engine's transaction support and how Prisma handles partial failures.

Key Uncertainty

The core question centers on how Prisma determines and reports migration state when a failure occurs mid-migration. Specifically, when the applied column in _prisma_migrations is set to false but some DDL changes have already committed to the database, what is the recommended path to reconcile this state without data loss?

Questions

1. When prisma migrate dev detects drift between schema.prisma and the database, what is the exact condition that triggers a destructive reset versus a migration replay?
2. When a migration fails after partial DDL application, does prisma migrate resolve --rolled-back correctly revert the internal tracking state, and what manual steps are required to ensure the database schema matches the resolved state?
3. Is there a documented procedure to manually adjust the _prisma_migrations table to align with a known database state after a failed migration, without triggering an automatic reset?