docs/solutions/developer-experience/2026-03-26-fast-suite-thresholds-should-be-ci-aware.md
pnpm test:slowest was enforcing the same hard-fail thresholds everywhere:
75ms/test150ms/file totalThat is fine on a fast local machine. It is too tight for noisy CI runners.
The result was dumb: a branch could be locally clean, then fail pnpm check in CI because one otherwise normal fast-suite spec wandered into the mid-70ms range.
*.slow.ts[x]That would have moved healthy specs out of the fast lane just because GitHub runners are slower and noisier than a local dev machine.
That would have thrown away the useful local signal. The local fast loop is where you actually want the stricter guardrail.
Make the thresholds environment-aware in tooling/config/test-suites.mjs:
75ms/test and 150ms/file90ms/test and 180ms/file75ms/test and 150ms/fileThat keeps local enforcement sharp while still surfacing slow drift in CI logs before it becomes a hard failure.
The repo has two different jobs here:
One shared threshold was trying to do both jobs and doing neither well.
The split fixes that:
*.slow.ts[x]If a timing gate is meant to protect developer workflow, do not assume CI and local hardware deserve the same hard-fail bucket.
Keep the local bar honest. Give CI enough headroom to avoid random red builds. Surface the tighter local bar in CI as a warning if you still want eyes on drift.
These commands passed after the change:
pnpm lint:fix
CI=1 pnpm test:slowest -- --top 5
pnpm check