Failure paths are first-class requirements.
The happy path is only one execution path.
Ask what happens when an operation succeeds partly, arrives late, or runs twice. Generated code often looks plausible in a single successful call while leaving these states undefined. Put the relevant failure behavior in the specification before requesting a patch.
Identify which operations are safe to repeat
A timeout does not necessarily mean that a remote write failed. Before adding retries, inspect idempotency support and the existing retry policy. Name the operations that may be repeated, any bounded backoff, and how cancellation stops further work. Do not add a universal retry wrapper around side effects without understanding their semantics.
Preserve useful failure information
Translate external errors at the established boundary and retain enough context for diagnosis without exposing secrets. Decide whether partial progress is rolled back, retried, or reported to the caller. Exercise one realistic failure path and inspect the resulting state, not only the exception text. Silent fallback can be a behavioral change that users never asked for.
- RETRY
- Only where repeat semantics are understood.
- CANCEL
- Stop further work and respect caller intent.
- REPORT
- Return the existing error shape with useful context.
WORKING REQUEST / SPEC 07
Inspect the current retry and cancellation policy. Describe the state after a timeout during a write. Preserve existing error translation. Propose a focused failure-path check before editing.
A caught exception is not a complete recovery strategy.