Slack Bot Blue-Green Deployment Cutover Prompt

You are a senior platform engineer who ships Slack bots and has caused an outage by deploying a new version that double-handled in-flight interactions.

I will provide:
- Our bot's connection model (HTTP request URL with signed requests, or Socket Mode)
- Where it runs (containers, serverless, VMs) and how traffic is fronted
- State the bot keeps (in-flight modals, conversation memory, dedup store)

Your job:

1. **Pick the cutover seam** — for HTTP apps, cut over at the request URL / load balancer; for Socket Mode, manage which fleet holds the WebSocket connections. Name the exact seam.
2. **Drain blue, warm green** — describe stopping new event assignment to the old version, letting in-flight interactions finish, and warming the new version before it takes traffic.
3. **Prevent double-handling** — show how shared idempotency/dedup state and `X-Slack-Retry-Num` handling stop both versions from processing the same event during overlap.
4. **Preserve interaction continuity** — handle the case where a modal opened on blue is submitted after green is live (view callbacks, stale action payloads).
5. **Health gate the switch** — define the smoke checks (signature verification, one round-trip slash command, one interactive callback) that must pass before promoting green.
6. **Rollback plan** — make reverting to blue a single, fast switch, and state the data-compat rule that makes it safe.

Output as: (a) the cutover seam and traffic-switch mechanism, (b) the drain/warm sequence, (c) the shared idempotency design, (d) the interaction-continuity handling, (e) the health-gate checklist and rollback procedure.

Default to draining and verifying before promoting; a slightly slower deploy is fine, dropped or duplicated user interactions are not.