---
name: critic-perf-budget
description: Critic that forces every behavior to declare explicit performance thresholds (TTI, p95 latency, error rate). Invoked by contract-verify.
---

# Perf-budget critic

> **Protocol:** Follow `reference/CRITIC-RULES.md` (the compact runtime rules) at the plugin root for severity
> definitions (the closed enum blocker/warning/info), the output JSON schema,
> ID prefixes, and shared anti-patterns. This skill defines only WHAT to look
> for. Do not invent severities like "high"/"medium" — the validator rejects them.
> Do not re-check anything the deterministic validator (`scripts/validate.mjs`)
> already covers; add the judgment layer on top.

A feature without a perf budget can't fail performance review — by
definition. This critic prevents that loophole.

> **Gating is contextual + configurable (handled by the validator, not
> you).** Field *presence* is governed by `conventions.perfBudget` /
> the contract's `perfBudgetPolicy`: `required` (blocker), `warn`
> (warning — the default), or `off`. When checked, one relevant numeric
> field is enough (ttiMs for UI, p95LatencyMs for a network call). Don't
> emit a presence finding the validator already handles — your job is
> the *judgment* layer: are the declared budgets realistic for the
> platform, and do they cover the behavior's real hot path?

## What to check

### 1. Every behavior has `perfBudget`

Each `### B<N>` must declare:

```
- perfBudget:
    ttiMs: <integer>            # Time to Interactive for the screen
    p95LatencyMs: <integer>     # backend response time
    errorRatePct: <number>      # max acceptable error rate %
```

Missing any field → **blocker**.

### 2. Budgets are concrete numbers, not "fast"

If any field is `TBD` or a string, emit a **blocker** with a suggested
default based on the behavior type:
- Page load behaviors: tti ≤ 2500ms, error ≤ 1%
- API-triggered behaviors: p95 latency ≤ 800ms, error ≤ 0.5%
- Background syncs: p95 latency ≤ 5000ms, error ≤ 2%

### 3. Budgets are realistic for the platform

If the contract's `platforms` includes mobile and the perf budget assumes
desktop-class network (tti ≤ 500ms), flag as **warning** — mobile p95
network is generally 1500ms+ for cold loads.

### 4. Budgets match the success metric

If a success metric implies a certain UX speed (e.g., "X% of users
complete X within Y seconds"), the per-behavior budgets must total
under Y. Flag inconsistencies.

### 5. There's a measurement plan

The behavior's `instrumentation` should let the launch-report skill
*measure* these budgets after ship. Cross-check that the events fire at
the right point in the flow to capture the budgeted timing.

If the behavior measures `tti` but the event fires before render
completes, flag as **warning** — the data will lie.

## Severity

- **blocker** — missing budgets, or budgets are placeholders.
- **warning** — unrealistic for platform, mismatched to success metric,
  unmeasurable with declared instrumentation.
- **info** — suggestions for tighter budgets.

## Output

Same JSON array shape as other critics.