Teams Bot GitHub Actions Run Status Card Prompt

You are a senior DevOps engineer who has built GitHub Actions -> Microsoft Teams status integrations using the Bot Framework, Graph proactive messaging, and Adaptive Cards that update in place as a run progresses.

I will provide:
- Repos and workflows to track, and which branches/environments matter
- Target Teams channel(s) or chats and routing rules
- Whether re-run/approve actions from Teams are required
- Auth available (GitHub App vs PAT) and the bot's identity
- Volume (runs/hour peak) and reliability needs

Your job:

1. **Ingestion** — recommend a GitHub App with a `workflow_run` and `workflow_job` webhook. Show the signature verification step (`X-Hub-Signature-256` HMAC over the raw body) and why you must compute it before JSON parsing.

2. **State model** — map `workflow_run.status`/`conclusion` (queued, in_progress, completed + success/failure/cancelled/timed_out) to a canonical run state. Track jobs from `workflow_job` events for a step-level breakdown.

3. **Update-in-place** — this is the key UX: post one card when a run starts, then UPDATE the same message as it progresses instead of spamming. Explain the two paths:
   - Bot Framework `updateActivity` using the stored `activityId` + conversation reference
   - Adaptive Card Universal Action `refresh` for user-triggered refresh
   Include how to persist the `activityId` keyed by `run_id`.

4. **Card design** — Adaptive Card 1.5:
   - Status header with a colored badge (green success / red failure / amber running) and a spinner-like "In progress" `TextBlock`
   - `FactSet`: repo, branch, actor, trigger event, duration
   - A `Container` per job with a pass/fail icon; expand failed jobs via `Action.ShowCard` showing the failed step name
   - `Action.OpenUrl` to the run, and `Action.Execute` "Re-run failed jobs" / "Approve deployment" (calls the GitHub REST API `POST /actions/runs/{id}/rerun-failed-jobs` or the deployment approval endpoint)

5. **Proactive messaging** — for a first post to a channel the bot must be installed; cover Graph `POST /teams/{id}/channels/{id}/messages` vs Bot Framework proactive with a stored conversation reference, and the "bot not in roster" pitfall.

6. **Reliability** — retries on transient GitHub 5xx, respecting the GitHub REST secondary rate limits, and deduping duplicate webhook deliveries by `delivery` GUID.

7. **Security of actions** — gate "Re-run"/"Approve" by mapping the Teams user (from the invoke `from.aadObjectId`) to a GitHub identity/permission before calling the API.

Output as: (a) webhook ingestion + signature verification code, (b) canonical run state machine, (c) the update-in-place activityId persistence design, (d) Adaptive Card JSON, (e) the Action.Execute handler calling the GitHub API with an authz check, (f) rate-limit and dedup handling.

Bias toward: one evolving card per run over notification spam, verified webhooks, and per-user authorization on actions.