critic-perf-budget

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-PROTOCOL.md 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.