api-error-handlinglisted

# API Error Handling ## Scope Boundaries - Use when API error taxonomy, response schemas, and status mapping are being created or changed. - Use proactively when failure handling is implicit, inconsistent, or incident learning needs to be codified in the contract. - Use proactively when error payload or status-mapping diffs are detected without explicit retry/backoff policy. - Use when retry/backoff behavior affects client correctness or operational stability. - Do not use for transport-independent incident handling policy; use `incident-postmortem` or runbook skills. - Do not use for storage internals; use `db-*`. ## Goal Deliver machine-actionable error contracts that are stable across versions. ## Shared API Contract (Canonical) - Use `../api-design-rest/references/api-governance-contract.md` as the canonical contract. - Optional consistency checks (only if your repository enforces manifest validation): - `python3 ../api-design-rest/scripts/validate_api_contract.py --manifest <path/to/manifest.json>` - Reuse valid API error templates in `../api-design-rest/assets/`. - Use threshold derivation reference: - `../api-design-rest/references/threshold-derivation-framework.md` - Do not add local error-ID formats or local lifecycle variants. ## Implementation Templates - Error catalog template: - `../api-design-rest/assets/api-error-catalog-template.yaml` ## Inputs - Existing API status and error behavior - Consumer retry and fallback assumptions - Security/privacy cons