Teams to PagerDuty Bidirectional Bridge Prompt

You are a senior SRE who has built incident bridges that on-call engineers trust enough to drive an incident entirely from Teams. I want a bidirectional Teams ↔ PagerDuty integration with no double-acks and no orphaned channels.

I will provide:
- PagerDuty config (services, escalation policies, webhook v3 subscriptions, REST API access)
- Teams side (bot/app, Graph permissions, how channels are created)
- Identity sources (how a Teams user maps to a PD user)
- Lifecycle I want mirrored (trigger, ack, resolve, reassign, priority change, notes)

Your job:

1. **Inbound: PD → Teams** — handle webhook v3 events (`incident.triggered/acknowledged/resolved/escalated/annotated`). Verify the webhook signature. On trigger, create or reuse a dedicated incident channel, post an adaptive card with severity, service, and Action.Execute buttons (Ack, Resolve, Reassign, Add note). On state changes, update the SAME card/thread rather than spamming.

2. **Outbound: Teams → PD** — card actions call the PD REST API as the acting engineer: ack/resolve via incidents API, reassign by escalation/assignment, notes via the notes endpoint. Return a refreshed card reflecting the new state.

3. **Identity mapping** — resolve the Teams AAD user to a PagerDuty user id (email match + override table); if unmapped, act via a service token but stamp the note with the human's name, and surface a "link your account" card.

4. **Idempotency & loop prevention** — use PD `dedup_key`/incident id + event signature so a PD-originated ack doesn't bounce back as a Teams-originated ack. Track a correlation key per incident in a small store.

5. **Reliability** — retries with backoff, dead-letter for failed deliveries, and reconciliation that re-syncs state if a webhook is missed.

6. **Channel hygiene** — auto-post a resolution summary, pin the timeline, and archive/lock the channel on resolve per policy.

Output as: (a) inbound webhook handler with signature verification, (b) outbound action handlers, (c) the identity-mapping + correlation store schema, (d) two adaptive cards (active / resolved), (e) a failure-mode table (missed webhook, unmapped user, duplicate event) with mitigations.

Bias toward: idempotency over optimism, acting as the real human, and one living card over a wall of updates.