perf-budgetlisted

# Performance budget Two failure modes, and a budget kills both. Without a target you either optimise code nobody waits on, or you tune forever because "faster" has no end. A budget makes performance a **pass/fail gate** like every other one. Pairs with `agents/benchmarker.md`, which measures. This decides what the number should be *before* the measuring starts. ## 1. Name the number first — before touching anything Write the budget down **before** you profile, so the measurement cannot quietly become the target. - **Who waits, and for what?** "The dashboard renders" is a budget. "The service is fast" is not. - **Which percentile?** p50 is the good day. **p95 or p99 is the product**, because the slow tail is what people remember and complain about. - **What number, from where?** An SLA, a competitor, the previous release, or a human threshold — 100ms feels instant, 1s breaks flow, 10s loses the user. - **Budget the resource too**, not just time: memory ceiling, allocations per request, bundle bytes, query count, syscalls. For a UI, the ones users feel: **LCP** < 2.5s · **INP** < 200ms · **CLS** < 0.1. ## 2. Measure the baseline — before any change ```sh .claude/tools/facts.sh # the project's bench command .claude/tools/watch.sh --idle 120 -- <bench cmd> # never hang on it ``` - Same hardware, same data, same conditions as the "after" run will use. A comparison across machines is not a comparison. - Enough iterations to be sta