perf-budgetlisted

# Perf budget Frontend performance degrades by accumulation: every change adds a little, no single change is worth objecting to, and the app is slow a year later with no commit to blame. A budget converts that into a check that fails on the commit responsible. ## 1 — Measure the baseline Measure before setting any number. A budget invented from best practice either fails on day one or is loose enough to permit the regression you were guarding against. **Bundle.** Production build per app, then the composition: initial versus lazy chunks, the ten largest modules, the shared vendor chunk. Use the bundler's own analysis (`--stats-json`, `rollup-plugin-visualizer`, `source-map-explorer`) — a raw byte total tells you a number changed, not what changed. **Runtime.** Lighthouse on the routes that matter, in a consistent configuration: LCP, CLS, INP, TBT. Run it three times and take the median; a single Lighthouse run is noise wearing a number. **Render.** For screens that felt slow, a profiler trace: what re-renders, how often, what is doing the work. Record all of it in `docs/agent/perf-baseline.md` with the commit and the measurement conditions. Numbers measured under different conditions cannot be compared, and the comparison is the entire point. ## 2 — Set the budgets Two numbers per metric, both derived from the baseline: - **Warn** — roughly current plus 5%. Prompts a look. - **Fail** — the point at which the user experience is genuinely worse, or the number the team