walnut-testing

# Testing — Implementation Details For testing philosophy, run commands, and anti-patterns, see project `CLAUDE.md`. For the layered pipeline (which tier to run when), see [docs/reference/testing-pipeline.md](../../../docs/reference/testing-pipeline.md). ## Run the cheap layer (start here) ```bash npm run test:quick # 306 pure-logic files, ~51s — the default npm run test:focus <path> # one file/dir, 0.3-30s npm run test:baseline # ⭐ the honest verdict: fails ONLY on NEW failures npm run test:pre-commit # maps your diff → affected tiers ``` **`npm run test:baseline` is how you judge a change.** The suite carries **118 pre-existing failures on `main`** (recorded in `tests/setup/known-failures.json`, measured in a clean clone of `844dc84`). The baseline gate ignores those and fails only on failures absent from the list, so you get a yes/no answer instead of eyeballing an aggregate. Fixed some? `npm run test:baseline:record`. ⚠️ **Never raise the worker budget** (`tests/setup/worker-budget.ts`, 2 workers locally). Uncapped fan-out hard-crashed the dev Mac twice in July 2026. `npm test` runs tiers *sequentially* for the same reason — don't "optimise" it back to parallel. ### The mergeConfig trap (cost 2× suite runtime for months) `mergeConfig` **CONCATENATES** `include`/`exclude` arrays. Passing `include` through its second argument appends to the base's `tests/**` instead of replacing it — so `vitest.unit.config.ts` and `vitest.integration.config.ts` e...