observability-baseline

# observability-baseline stack-baseline names Sentry and wires it nowhere — so every shipped product's first prod incident is invisible, and l3-support triages blind. This skill makes three things exist at scaffold time. Defaults baked in; no founder question. ## 1. Error capture (Sentry) - `instrumentation.ts` (Next.js) / SDK init at process start; DSN from `SENTRY_DSN` env (never hardcoded). - CI uploads source maps on release so stack traces are readable (release = git sha). - Capture unhandled rejections + a global error boundary on the client. ## 2. Request-id structured logging - A logger that emits **JSON** (not `console.log` prose) with a per-request `request_id` (generate at the edge, propagate via header/async-local-storage). - Levels: error / warn / info / debug — diagnostics go to **stderr**, never mixed into user-facing stdout. (Same discipline as the CLI logging gap, DEEPEN d94.) - One log line per request with: request_id, method, path, status, latency_ms. ## 3. Health endpoints - `GET /healthz` — liveness (process up). `GET /readyz` — readiness (deps reachable: db, cache). Cheap, unauthenticated, no PII. - These are what infra-provisioner probes and what a load balancer checks. ## Wiring (a skill is shelfware unless a consumer loads it) | Consumer | What it does with this skill | |----------|------------------------------| | **app-scaffolder** | bakes `instrumentation.ts` + the JSON logger + `/healthz`+`/readyz` into the generated app; adds `S...