Failure Case Discovery
Definition
Identify what can go wrong and decide how much complexity each case deserves. Prefer defining errors and special cases out of existence where simple semantics can remove the failure from callers.
Questions To Ask
- What input can be missing, invalid, stale, duplicated, or unauthorized?
- What external systems can fail or be slow?
- What state can change between user action and system response?
- Which failures can the user correct?
- Which failures should be retried, ignored, reported, or blocked?
Existing Project Comparison
- Inspect error handling, validation, logs, tests, and empty states.
- Find exceptions thrown from low-level code that callers cannot handle meaningfully.
- Identify over-defensive checks that add complexity without user value.
- Look for missing tests around known failure paths.
Suggestive Plan
- List failure cases per feature.
- Classify each as user-correctable, system-recoverable, authorization, data conflict, external dependency, or internal bug.
- Decide the response and owner.
- Define errors out of existence where possible.
- Add acceptance and regression tests.
Example
If a user accepts a slot that has just been taken, the feature should re-check availability and offer next options, not expose a database conflict.
Vocabulary
- Failure case: condition that prevents the happy path.
- Edge case: uncommon but valid situation.
- Recoverable error: failure the app can handle and continue from.
- Define errors out of existence: choose semantics that eliminate unnecessary error handling.
- Error owner: module that decides how a failure is handled.
Expected Outcome
Produce a failure matrix with case, trigger, user message, system response, owner, test need, and simplification opportunity.
1---2name: failure-case-discovery3description: Discover failure cases, edge cases, invalid states, and recoverable errors for planned features. Use when designing resilient workflows, reducing hidden unknowns, or deciding which errors can be defined out of existence.4---56# Failure Case Discovery78## Definition910Identify what can go wrong and decide how much complexity each case deserves. Prefer defining errors and special cases out of existence where simple semantics can remove the failure from callers.1112## Questions To Ask1314- What input can be missing, invalid, stale, duplicated, or unauthorized?15- What external systems can fail or be slow?16- What state can change between user action and system response?17- Which failures can the user correct?18- Which failures should be retried, ignored, reported, or blocked?1920## Existing Project Comparison2122- Inspect error handling, validation, logs, tests, and empty states.23- Find exceptions thrown from low-level code that callers cannot handle meaningfully.24- Identify over-defensive checks that add complexity without user value.25- Look for missing tests around known failure paths.2627## Suggestive Plan28291. List failure cases per feature.302. Classify each as user-correctable, system-recoverable, authorization, data conflict, external dependency, or internal bug.313. Decide the response and owner.324. Define errors out of existence where possible.335. Add acceptance and regression tests.3435## Example3637If a user accepts a slot that has just been taken, the feature should re-check availability and offer next options, not expose a database conflict.3839## Vocabulary4041- Failure case: condition that prevents the happy path.42- Edge case: uncommon but valid situation.43- Recoverable error: failure the app can handle and continue from.44- Define errors out of existence: choose semantics that eliminate unnecessary error handling.45- Error owner: module that decides how a failure is handled.4647## Expected Outcome4849Produce a failure matrix with case, trigger, user message, system response, owner, test need, and simplification opportunity.
harsh817