backend-error-handling

# Error Handling Skill **Degree of freedom: MIXED.** Which layer and message `[HIGH freedom]`; existing-type/boundary probes `[LOW freedom — run exactly]`. ## How to reason 1. **Observe** — existing error types, boundaries, `ActionResult` / `ApiError` 2. **Interpret** — missing layer vs inconsistent shape vs swallowed catch 3. **Classify** — reuse-existing / extend-codes / add-boundary / toast-only 4. **Severity** — unhandled 500 on a mutation outranks a missing toast ## Worked example > **Observe:** `createUser` throws Prisma `P2002`; UI shows a blank catch; `ActionResult` already lives in `types/errors.ts`. > **Interpret:** known conflict is unmapped; no field/toast path. > **Classify:** reuse `ActionResult` + `CONFLICT`; toast the message; do not add a second error type. > **Verify:** duplicate email returns `{ success: false, error: { code: 'CONFLICT' } }`; form alert shown. ## Self-critique before reporting - **Reuse shape** — searched `ActionResult` / `ApiError` / `error.tsx` before adding a type - **User-safe** — `INTERNAL_ERROR` is generic; PII is not in the client message - **Layered** — boundary + action result + toast, not toast-only - **Right owner** — plan-only observability audit → `plan-error-handling`; live Sentry triage → `debug-sentry-monitor` Layered error handling for full-stack apps: one action-result shape, boundaries, and toasts. ## When to Use - Adding error handling to new features - Improving error user experience - Standardizing error resp...