error-envelopelisted

# Error Envelope ## Purpose Provide one standardized way to (1) validate a request at the boundary and (2) return every error in a consistent, machine-readable envelope. These are high-volume boilerplate that teams re-implement inconsistently, one endpoint returns `{ "error": "bad" }`, the next returns a 200 with `{ "success": false }`, a third leaks a stack trace. The cure is a single validation layer plus a single error format: **RFC 9457 Problem Details** (`application/problem+json`), which obsoletes RFC 7807 (same wire format, updated reference). ## The RFC 9457 envelope Every error response is `application/problem+json` with these standard members (all optional, but be consistent): | Member | Meaning | |---|---| | `type` | A URI identifying the problem *kind* (dereferenceable docs, or `about:blank`). The primary identifier. | | `title` | Short, human-readable, stable summary for that `type`. | | `status` | The HTTP status code, duplicated in the body. | | `detail` | Human-readable explanation specific to *this* occurrence. | | `instance` | A URI for this specific occurrence (e.g. the request path or an error id). | Add **extension members** for machine use: `errors` (per-field validation failures), `traceId`/`requestId`, `code` (your internal error code), `retryAfter`. See `references/rfc9457.md`. ## Validation → error, at the boundary Validate params, query, and body **before** business logic. A validator failure is not an exception to leak, map it into the envelop