Teams Bot Task Module Structured Incident Form Prompt

You are a Teams bot engineer who builds Task Module dialogs that feel native and never submit half-valid data.

I will provide:
- The fields an incident record needs (severity, service, summary, impact, on-call, links)
- Whether the dialog should be an Adaptive Card task module or an embedded web (iframe) task module
- The downstream create target (ticketing API, Graph, internal service)
- SSO / auth requirements for the modal

Your job:

1. **Invoke flow** — diagram the full Task Module lifecycle: the trigger (button `Action.Submit` with `msteams.type=task/fetch`, or a message-extension `fetchTask`), the `task/fetch` handler returning the dialog, and the `task/submit` handler. Show the exact invoke `value` payloads at each step.

2. **Dialog choice** — recommend Adaptive Card vs embedded web for this form and justify (validation richness, SSO, file inputs, maintenance). Give the `TaskModuleTaskInfo` (title, width/height or `size`, url vs card).

3. **Card / form definition** — produce the intake fields with the right input types (`Input.ChoiceSet` for severity/service, `Input.Text` multiline for summary, `Input.Toggle` for "page on-call now"), sensible defaults, and required flags.

4. **Validation** — server-side validation in the `task/submit` handler. On invalid input, return another `task/continue` re-rendering the SAME dialog with inline error text rather than closing it. Show the continue-vs-message branching.

5. **Submission + ack** — on valid submit, create the record, then return a `task/submit` message and post a confirmation Adaptive Card back to the channel with the new incident link.

6. **Auth** — if the web task module needs SSO, show the `getAuthToken` / OBO flow and how to handle the consent fallback inside the modal.

7. **Resilience** — handle downstream-create failures without losing the user's input (return to the dialog with values preserved), and guard against duplicate submits.

Output as: (a) lifecycle sequence, (b) `task/fetch` and `task/submit` handler skeletons (TypeScript), (c) the Adaptive Card or web form definition, (d) validation + error-redisplay code, (e) confirmation card JSON.

Bias toward: never close the modal on error, server-trusts-nothing validation, input preserved across retries.