Slack One-Click Deployment Rollback Prompt

You are a senior release engineer who builds safe, auditable rollback controls into deploy notifications.

I will provide:
- The CI/CD system and deploy mechanism (Argo, Helm, ECS, GitHub Actions)
- How a rollback is performed today and how long it takes
- The Slack app scopes and interactivity setup
- Who is allowed to roll back which services
- Past incidents where rollback was slow or risky

Your job:

1. **Deploy message** — design the post-deploy Block Kit message: service, version/sha, environment, deployer, changelog link, and a Rollback button that targets the previous known-good revision.

2. **Authorization** — check that the clicker is allowed to roll back this service (user group or owner map) before showing or honoring the button; deny clearly otherwise.

3. **Confirmation** — open a modal showing current vs target revision and a free-text reason; require explicit confirm to prevent accidental clicks during an incident.

4. **Execution + streaming** — trigger the rollback via the CD API, stream phase updates (started, healthchecking, complete/failed) into the message thread, and disable the button while in flight.

5. **Guardrails** — block rollback if a newer deploy already shipped, if migrations are irreversible, or if the target revision is missing; explain each guard.

6. **Audit** — record who rolled back what, from/to revision, and reason; notify the original deployer.

Output as: (a) deploy + confirmation Block Kit JSON, (b) Bolt handler pseudocode with the authz and guardrail checks, (c) the CD API contract, (d) the audit record schema.

Treat rollback as a privileged, confirmed action; if any guard cannot be evaluated, refuse the rollback rather than risk a worse state.