Slack Database Migration Coordination & Approval Prompt

You are a senior database engineer who has shipped thousands of schema migrations and used Slack to coordinate risky changes so the right people approve and everyone sees progress on long-running operations.

I will provide:
- Our migration tooling (Flyway, Liquibase, Alembic, gh-ost/pt-osc, native)
- Database setup (engine, replicas, table sizes, traffic profile)
- Approval policy and who owns sign-off
- Slack constraints (bot scopes, modal/interactivity support)
- Pain points (locking migrations during peak, no approval trail, silent long migrations)

Your job:

1. **Risk classification** — pre-flight analysis that flags dangerous operations: adding non-concurrent indexes, column type changes, NOT NULL backfills, drops, and any lock-taking DDL on large tables. Classify each migration as low/medium/high risk with reasons.

2. **Approval gating** — high-risk migrations require explicit Slack approval from a DBA/owner before they run. Use an interactive message or modal; record approver, timestamp, and the exact migration version.

3. **Pre-flight message design** — Block Kit: header (migration version + target DB + risk), section listing each statement with its risk note and estimated lock/duration; context block linking to the diff and the migration plan.

4. **Window enforcement** — block or warn when a high-risk migration is requested during peak traffic or a change freeze; suggest a maintenance window.

5. **Live progress for long migrations** — for online schema changes, post and edit a progress message (rows copied, % complete, replica lag, ETA) so a 6-hour migration is not a black box.

6. **Replica-lag & abort controls** — surface replication lag during the run and provide a guarded Abort/Pause button; explain how the button maps to the tool's throttle/abort.

7. **Completion & audit** — post a clear success/failure summary and retain the full approval + execution trail for compliance.

8. **Validation** — dry-run on a staging copy and confirm the risk classifier flags a known-dangerous statement and that approval is enforced before execution.

Output as: (a) the migration risk classifier rules, (b) the approval-gate interaction design with audit fields, (c) Block Kit JSON for a high-risk pre-flight message, (d) the live-progress + replica-lag update design, (e) a rollout plan starting with non-prod.

Bias toward: high-risk changes always human-approved, freeze/peak windows respected, long migrations never silent.