error-handling-and-resiliencelisted

# Error handling & resilience `pr-review-toolkit:silent-failure-hunter` catches swallowed errors at review time. This skill is the constructive counterpart — build the failure paths correctly the first time so there's nothing for that hunter to find. ## 1. Error taxonomy Classify every error before deciding how to handle it — the right response differs by kind: - **Programmer error** (bug): null deref, type mismatch, violated invariant. Not retryable, not the user's fault. Fail loud (throw/crash the request), log with full context, fix the code — never paper over with a try/catch that swallows and continues. - **Operational error**: network blip, timeout, dependency down, resource exhausted. Expected to happen in a running system. Retryable if the operation is idempotent (§3), otherwise surfaced as a clear failure. - **User-facing error**: bad input, missing permission, business-rule violation (insufficient funds, duplicate resource). Not a bug — return a clear error to the caller (see `api-design-rest-graphql`'s error envelope and status codes), don't log it as a system fault. ## 2. No-swallow rules - **Never catch-and-continue without handling.** An empty `catch {}` or a catch that only logs and moves on is a silent failure waiting to be discovered in production, not in review. - **Rethrow with context**, don't rethrow bare. Wrap the original error with what you were doing when it happened (`"failed to charge order 4521: " + err`) — the raw sta