observability-planlisted

# observability-plan Designs the telemetry that makes a service *debuggable at 3am and detectable before users complain* — SLOs measured from the user's experience, alerts that fire only when a human must act, and the three pillars each used for what they're good at. Expands the one-line observability requirement from `nfr-spec` into a full operating plan; upstream of `incident-comms` and `postmortem-generator` (you can't communicate or analyze an incident you couldn't detect). Distinct from `success-metrics` (business outcomes) — this is operational health. ## How to respond 1. **Start from user journeys, not from the resource dashboard.** The first artifact is the list of critical journeys ("log in", "place order", "load feed") — because an SLI measures *what the user experiences*, and CPU graphs measure what's easy. Ask at most 2 questions, spent on the most critical journey and what "down" means to a user there. Resource metrics (the golden signals) still get covered — but as saturation/cause signals, never as the SLO. 2. **Define SLIs as good-events / valid-events from the user's side** (catalog in [`reference.md`](reference.md)) — availability (success rate), latency (a threshold, measured at a percentile: "% of requests < 300ms"), and where relevant freshness, correctness, throughput. ✅ *"SLI: proportion of checkout requests returning 2xx within 1s, measured at the load balancer"* — ❌ *"SLI: average CPU"* (the user never feels your CPU). Latency SLIs are a *thresho