TL;DR: flyway_schema_history is the source of truth - the agent's memory of the run is not. Query the history table ordered by installed_rank, check the success column, and run `flyway info` to see the pending set. Repair any failed row, then re-run `flyway migrate`: it resumes where it stopped and never re-applies a successful migration.

The problem as reported:
```text
agent applied 12 of 30 flyway migrations then crashed - flyway_schema_history disagrees with what the agent remembers
```

1. Read the history table: `select version, description, success, installed_on from flyway_schema_history order by installed_rank;`. Expected: 12 rows with success true, and possibly one trailing row with success false if the crash landed mid-migration.
2. Run `flyway info`. Expected: the succeeded versions show Success, the rest show Pending.
3. If a row shows success false: figure out what that migration did, manually finish or undo its partial effects in the database, then run `flyway repair`. Expected: `flyway info` shows that version as Pending again instead of Failed.
4. Do not edit any migration file that already applied - the checksum column will mismatch and flyway will refuse to run anything. A change to applied SQL is a new migration, full stop.
5. Run `flyway migrate`. Expected: applies only the pending versions in order and ends with a success message naming the count applied.
6. Verify: re-run the query from step 1. Expected: all 30 rows present with success true.

## Use this when
- A flyway run was interrupted by a crash, kill, or lost connection.
- The agent's notes about progress conflict with the history table.
- A migration row is stuck in failed state.

## Not for this skill when
- The history table itself is missing or corrupt - that's a baseline/repair scenario, not a resume.
- You're using a different migration tool - each has its own state table and resume command.

## Variant phrasings
- flyway crashed mid migrate how to resume
- flyway_schema_history success false after crash
- flyway re-run after crash skips applied migrations
- flyway repair failed migration row

## Why it happens
Flyway writes each migration's outcome into the history table as it goes, so the table reflects what the database actually did. The agent's in-memory notes reflect what it hoped to do - after a crash those two disagree, and the table wins.

## Edge cases
- Version 13 half-applied its DDL before crashing: flyway can't roll back DDL on most databases, so repair the row only after manually reconciling the schema.
- Out-of-order migrations with outOfOrder enabled: installed_rank, not version order, is the application order - read that column.
- Another instance is migrating the same database concurrently: coordinate first; two writers will deadlock or interleave versions.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7492vy1q8nnQV6NQVMXG3Q