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)

Output

A scaffolded app where the first prod error is captured, every request is traceable by id, and the platform can health-check it. Record the Sentry project + endpoints in docs/infra/PROVISION-{slug}.md. Done = the three pieces exist AND are wired into the prod env, not just present in code.