Teams Adaptive Card Kubernetes CrashLoopBackOff Alert Prompt

You are an SRE who has built Kubernetes alerting into Microsoft Teams using Adaptive Cards, backed by Alertmanager/Prometheus and a small remediation service with cluster RBAC.

I will provide:
- Alert source (Prometheus/Alertmanager, Kubernetes events, or a controller)
- Clusters/namespaces in scope and their criticality
- Target Teams channels and on-call routing
- Which remediation actions are allowed from Teams (restart, rollback, scale, cordon)
- The RBAC / identity model for gating actions

Your job:

1. **Signal** — define the alert: a pod in `CrashLoopBackOff` (from `kube_pod_container_status_waiting_reason{reason="CrashLoopBackOff"}` or a Kubernetes `Warning` event `BackOff`). Include restart count threshold and a de-flap window so a single restart doesn't page.

2. **Enrichment** — before posting, gather: namespace, deployment/owner ref, restart count, `lastState.terminated.reason` + exit code (e.g. OOMKilled 137, Error 1), image tag, node, and the last ~15 log lines from the crashing container (`kubectl logs --previous`). Redact secrets.

3. **Card design** — Adaptive Card 1.5:
   - Header `Container` with `style: attention` and pod/namespace
   - `FactSet`: restarts, exit code + reason, owner, node, image
   - A `TextBlock` (monospace via `fontType: monospace`) with the sanitized log tail, wrapped and truncated
   - Severity/OOM badge when `reason == OOMKilled`
   - `Action.OpenUrl` to the Grafana dashboard and to the pod in your K8s UI
   - `Action.Execute` "Restart pod", "Rollback deploy", "Scale to 0", "Ack/Silence" with `verb`/`data`

4. **Remediation handler** — the invoke-response flow: receive the `adaptiveCard/action`, resolve the Teams user (`from.aadObjectId`) to a K8s RBAC subject, authorize, then call the Kubernetes API (`delete pod`, `rollout undo`, `scale`) and return a refreshed card showing the new state and who acted.

5. **Correlation** — group flapping pods of the same deployment into one card, and link to the incident channel; avoid one card per restart.

6. **Reliability** — throttle per deployment, respect Teams posting limits, and dedup by `namespace/pod/reason`. Update the same card as restart counts climb rather than reposting.

7. **Audit** — record every button action (who, what, when, result) to an audit log, and reflect it in the card footer.

Output as: (a) the alert rule + de-flap window, (b) the enrichment/redaction pipeline, (c) Adaptive Card JSON with monospace log block, (d) the RBAC-gated Action.Execute handler calling the K8s API, (e) correlation/dedup rules, (f) the audit design.

Bias toward: server-side RBAC authorization on every action, log redaction, and one evolving card per incident.