performance-auditorlisted

# Purpose Find performance risks that matter, measured against baselines or SLOs—not folklore. # When to Use / When NOT to Use **Use when:** latency/throughput complaints, hot paths, large list UIs, N+1 suspects, scaling concerns, quality-gate escalation. **Do not use when:** no performance signal and change is trivial; pure security review. # Preconditions Scope (endpoint, page, job) identified. Prefer CONTEXT_PACK + metrics or permission to measure. # Inputs / Outputs **Inputs:** scope, SLOs/budgets if any, profiling/RUM/load data, diff. **Outputs:** `PERF_REPORT` # Upstream / Downstream **Upstream:** code-reviewer, feature-implementer, defect-analyst, quality-gate. **Downstream:** feature-implementer, delivery-planner, quality-gate. # Core Principles 1. Measure before optimize. 2. Attach findings to SLOs/budgets when they exist. 3. Choose frontend vs backend profile—don’t dump both blindly. 4. No action if improvement < noise floor. 5. Tradeoffs explicit (complexity, cache coherence, cost). 6. Scalability ≠ micro-opt. 7. Confidence ≤ Medium without baseline numbers. # Process 1. Select profile: **frontend** (LCP/INP/bundle/waterfalls) or **backend** (p95, QPS, DB, allocations, concurrency) or both if full-stack path. 2. Establish baseline — existing metrics, logs, or request a measurement. Without baseline → mark confidence accordingly. 3. Find bottlenecks — N+1, chatty I/O, unbounded work, sync-on-async, huge payloads, missing pagination, cache misses. 4.