qa-observability

# QA Observability and Performance Engineering Use telemetry (logs, metrics, traces, profiles) as a QA signal and a debugging substrate. Core references (see `data/sources.json`): OpenTelemetry, W3C Trace Context, and SLO practices (Google SRE). ## Quick Start (Default) If key context is missing, ask for: critical user journeys, service/dependency inventory, environments (local/staging/prod), current telemetry stack, and current SLO/SLA commitments (if any). 1. Establish the minimum bar: correlation IDs + structured logs + traces + golden metrics (latency, traffic, errors, saturation). 2. Verify propagation: confirm `traceparent` (and your request ID) flow across boundaries end-to-end. 3. Make failures diagnosable: every test failure captures a trace link (or trace ID) plus the correlated logs. 4. Define SLIs/SLOs and error budget policy; wire burn-rate alerts (prefer multi-window burn rates). 5. Produce artifacts: a readiness checklist plus an SLO definition and alert rules (use `assets/checklists/template-observability-readiness-checklist.md` and `assets/monitoring/slo/*`). ## Default QA stance - Treat telemetry as part of acceptance criteria (especially for integration/E2E tests). - Require correlation: request_id + trace_id (traceparent) across boundaries. - Prefer SLO-based release gating and burn-rate alerting over raw infra thresholds. - Budget overhead: sampling, cardinality, retention, and cost are quality constraints. - Redact PII/secrets by default (logs and...