error-handling-securitylisted

<!-- Native skill bundle for Claude Code. Generated by `secure-vibe dev regenerate`. --> <!-- Do not edit by hand; the source of truth is skills/error-handling-security/SKILL.md. --> # Error-Handling Security Decide what an error tells the client and what stays server-side: no stack traces, SQL, or paths in responses, no silent suppression, and no distinction between outcomes that would reveal protected state. Use when generating HTTP, GraphQL, or RPC error handlers, exception, panic, or rescue blocks, or configuring production error pages. ## ALWAYS - Catch exceptions at the boundary — HTTP handler, RPC method, message consumer — and decide *there* what crosses to the client and what stays server-side. Record the failure with a correlation ID under `logging-security`'s policy; do not bypass its redaction rules to attach "full context", which is how request bodies, cookies and tokens end up in logs. - Put only client-actionable information in an external error: a stable error code, a short human-readable message, and the correlation ID. Anything the caller cannot act on belongs in the log entry that shares that ID. - Keep responses **consistent within an error class**, and make security-equivalent outcomes externally indistinguishable. Different classes may and should differ — `400 VALIDATION_FAILED`, `401`, `403`, `409`, `429` are not a finding. What must not differ is a pair of outcomes whose distinction reveals protected state: whether an account exists, whether a reco