Teams Card-Based Deployment Approval Prompt

You are a senior platform engineer who has built deployment-approval workflows on Microsoft Teams using Adaptive Cards + a Bot Framework backend + audit storage.

I will provide:
- CI/CD platform (GitHub Actions, Azure Pipelines, Spinnaker, ArgoCD)
- What constitutes a "risky" deploy (e.g. production, off-hours, large diff, schema change)
- Approver groups (AAD groups or explicit lists)
- Audit + retention requirements
- Existing notification channels

Your job:

1. **Trigger conditions** — when does CI ask for approval instead of auto-deploying?
   - Target environment (prod)
   - Time window (off-hours, weekend)
   - Diff signature (DB migration files, dependency major bump, IAM policy change)
   - SLO state (in fast-burn → block, in healthy → allow)
   - Recent prior-incident proximity

2. **Adaptive Card design** — the approval card includes:
   - **Header** — environment badge (prod = red), service, requestor (with AAD photo)
   - **Title** — "Deploy v1.42.3 to production?"
   - **Context FactSet**:
     - Service / Service owner team
     - From version → To version
     - Change summary (1-line from commit / PR title)
     - Diff size + risky paths flagged
     - SLO state at request time
     - Linked CI build URL + PR URL
   - **Reviewer panel** — who's required (N from group), who's approved so far
   - **Actions** — Approve, Reject, Request changes (with comment), Open diff
   - **Footer** — request id, timeout deadline

3. **Approval rules**:
   - N-of-M from a configured AAD group
   - Service owner is always an eligible approver (RACI)
   - Requestor cannot self-approve
   - Approver identity validated server-side via AAD token verification (don't trust client-side claim)

4. **State machine** — the card has states: Pending → Approved → Rejected → Expired. Each transition: update card in place via `Action.Execute`, post a thread reply, update CI.

5. **CI integration** — the CI step waits for approval via:
   - **Polling** — CI polls the bot's approval API
   - **Callback** — bot calls back to CI (GitHub `repository_dispatch`, Azure Pipelines REST API) on decision
   Recommend callback for lower latency.

6. **Rollback hook** — for every approved deploy, the card stores enough context to trigger a rollback. After deploy completion, post a follow-up card with "Health: OK / Degraded" + "Rollback" button that triggers the inverse pipeline.

7. **Audit log** — record: request id, requestor, service, environment, version, summary, diff hash, approvers (names + timestamps), decision, outcome (deploy result + duration + post-deploy SLO snapshot). Storage: Log Analytics + a SharePoint list for auditor view.

8. **Compliance overlay** — SOX evidence trail, separation-of-duties enforcement (requestor ≠ approver), retention of approval records aligned to regime.

9. **Anti-patterns to avoid** — single rubber-stamp approver, missing diff context, no timeout (cards expire forgotten), no rollback hook, client-side identity claims trusted.

10. **Failure handling** — what if the bot is down when CI asks for approval? Recommend: CI fails open vs fails closed based on environment risk (prod fails closed).

Output as: (a) trigger condition logic, (b) Adaptive Card JSON for the request card, (c) state-transition card JSONs (approved / rejected / expired), (d) approval rule engine pseudocode, (e) CI integration pattern (polling vs callback), (f) audit log schema, (g) rollback hook design.

Bias toward: identity validated server-side, every decision auditable, timeouts default-safe, rollback always available.