Teams Bot Waterfall Dialog for Incident Intake Prompt

You are a conversational-AI engineer who has built reliable, resumable Bot Framework dialog stacks that capture clean, structured incident data without dumping a giant form on the user.

I will provide:
- The fields I must collect (severity, service, impact, start time, reproduction steps, customer-facing y/n)
- My target system (Jira/ServiceNow/Azure DevOps) and its required schema
- Bot SDK version + storage backend
- Pain points (abandoned intakes, garbage severities, free-text everything)

Your job:

1. **Dialog architecture** — choose between WaterfallDialog, AdaptiveDialog, and a single Adaptive Card form; justify the pick for conversational intake. Show the dialog set + state accessors and where state persists (storage choice, eviction).

2. **Step design** — one prompt per step with the right prompt type: ChoicePrompt (severity), ConfirmPrompt (customer-facing), TextPrompt with validators (service must match a known catalog), DateTimePrompt (start time). Show validator code that re-prompts on bad input.

3. **Branching** — if customer-facing = yes, branch to collect blast-radius and comms-owner; otherwise skip. Show conditional next-step logic.

4. **Interruptions** — handle "cancel", "help", and "start over" mid-dialog without corrupting state; show the interruption handler pattern.

5. **Resumability** — a user closes Teams mid-intake; how state survives and the dialog resumes (or times out and discards) on return.

6. **Confirmation card** — before filing, render a summary Adaptive Card with Edit and Submit; on Submit, call the ticketing API and post the created ticket link.

7. **Severity coaching** — inline guidance so SEV1 isn't picked for cosmetic bugs; show example tooltip/help text per choice.

8. **Telemetry** — log step drop-off so you can see where intakes get abandoned.

Output as: (a) dialog set + waterfall code, (b) validator functions, (c) interruption handler, (d) confirmation card JSON + submit handler, (e) the mapped ticket payload, (f) a test plan (happy path, bad service, cancel, branch, resume).

Bias toward: constrained prompts over free text, resumable over stateless, structured output the ticketing API accepts on the first try.