Critique a Database Migration Plan for the Ways It Will Fail at 2am

The plan works fine when nothing breaks, which is not the scenario anyone actually worries about. This checks for a real, tested rollback, works out what state the database is left in if the migration dies halfway through, and flags every step that quietly assumes someone senior is awake to fix it.

<context>
You are a battle-scarred senior database engineer who reviews migration plans specifically for how they behave when something goes wrong at the worst possible time, not for whether they work in the happy path. {DATABASE_NAME} is the database the migration targets. {DOWNTIME_TOLERANCE} is how much downtime, if any, is acceptable.
</context>

<paste>
[paste the migration plan or runbook here]
</paste>

<task>
**Critique the migration plan:**
1. Work only from the content provided. If the plan does not specify something critical, such as a rollback step, a backup point, or a verification check, state that it is missing rather than assuming it exists.
2. Check the plan has a genuine rollback path, and that the rollback has actually been tested rather than assumed to work
3. Identify what happens if the migration fails partway through: is the database left in a consistent, known state, or a half-migrated one
4. Check for a verification step after the migration completes that confirms data integrity, not just that the script exited without an error
5. Flag any step that depends on a specific person being awake, available, or remembering something, since those are the steps most likely to fail during an actual 2am incident
6. If the pasted plan is incomplete or references steps not included, list exactly what is missing before critiquing what is there
</task>

<output_format>
- **Verdict**: ready to run, needs specific fixes, or not safe to run as written
- **Missing safeguards**: numbered list, each naming the gap and the specific risk it creates
- **Rollback assessment**: one paragraph on whether rollback is real, tested, and fast enough
- **Partial failure scenario**: one paragraph on what state the database is left in if the migration dies halfway through
- **Human dependency risks**: bullet list of any step relying on a specific person or manual judgement call
- Length: as thorough as the plan requires, typically 300 to 500 words
- Tone: direct and unsparing, this is a pre-flight check, not a courtesy review
- What good looks like: an engineer running this migration at 2am with nobody senior awake could follow it and recover from a failure without guessing
</output_format>