TL;DR: Roll forward, not back. Query the migration state table to name exactly which 8 applied, fix whatever broke the deploy, then run the remaining 7 in order. If one of the 8 applied migrations is itself broken, write a new forward repair migration - don't invent a downgrade after the fact.

The problem as reported:
```text
agent ran 8 of 15 migrations before the deploy failed - no down migrations exist and production is half-migrated
```

1. Name the applied 8. Query the tool's state table - e.g. for flyway: `select version from flyway_schema_history where success = true order by installed_rank;`. Expected: exactly 8 rows; you now know which migrations the database has.
2. Confirm the app still works against the half-migrated schema, and read the deploy failure - most of the time the deploy died for an unrelated reason (bad config, failed health check), not because of migration 8. Expected: a concrete, named blocker.
3. Fix the blocker. Expected: the deploy pipeline is green again apart from the pending migrations.
4. Run the migration command for the remaining 7. Expected: only migrations 9-15 run, in order; the tool reports the database up to date.
5. Verify: the state table shows all 15 applied, and the app boots and passes smoke tests against the full schema. Expected: no gaps, no errors.
6. Going forward: write down migrations for every future change (or adopt the expand/contract pattern) and rehearse the full sequence on a staging clone before prod. Expected: the next failed deploy has a tested path back.

## Use this when
- A deploy died partway through a migration sequence.
- No down migrations exist and production is partially migrated.
- The only safe direction is forward.

## Not for this skill when
- Down migrations exist and a rollback is genuinely safe - then roll back instead.
- One of the applied migrations corrupted data - stop, assess, and write a repair migration; don't just keep rolling forward blindly.

## Variant phrasings
- migration failed halfway no rollback available
- half migrations applied deploy failed
- production half migrated no down migration
- resume failed deploy migrations forward

## Why it happens
Migration runners apply in order and stop at the first failure. Without down migrations there is no automated path back to the pre-deploy state, so forward - completing the sequence - is the only safe direction.

## Edge cases
- Migration 8 of 8 half-applied: check whether your tool wraps each migration in a transaction (postgres DDL is transactional, MySQL's is not) - non-transactional engines need manual reconciliation.
- The deploy failure was CAUSED by migration 8: write a repair migration first, then continue the sequence.
- Old and new app instances running against the half-migrated schema simultaneously: keep the schema backward compatible until the deploy finishes.

## Provenance

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