saranskumar Goal
Design failure behavior so users can recover and operators can diagnose issues.
When to Use
- A system spans multiple failure points.
- UX for failure or retry is unclear.
- Jobs, integrations, or AI calls can fail independently.
Instructions
- Enumerate failure classes: validation, auth, network, provider, data, and operator error.
- Decide what the user sees, what is retried, and what is logged.
- Define typed backend errors and client-facing messages.
- Plan retry, dead-letter, and escalation behavior for async work.
- Tie error handling to observability and supportability.
Constraints
- Do not leak sensitive internals to end users.
- Do not rely only on generic toast messages for complex failures.
- Treat silent failure as a bug.
Output Format
- Failure taxonomy
- User-facing behavior
- System behavior
- Retry/logging notes
Examples
- "Design error handling for uploads and AI processing."
- "How should this app surface provider failures?"