docs(testing): record the corpus sweep's blind spot, and file the load-sensitive case

Two findings from the 4.9 work, neither of which belongs in that item's own entry.

docs/testing.md: the house corpus sweep — describe() + lint() + every storey's
SVG, 95 artifacts — carries NO parse- or resolve-stage diagnostic, because
lint() is the soundness layer alone. Measured: `arch lint materials` returns []
while `arch compile materials` returns W_SCALE_OVERFLOW. So a change to
W_SCALE_OVERFLOW, W_DRAWING_OVERFLOW, any W_*_OFF_WALL or E_PARSE is invisible
to a clean sweep, which then reports "nothing moved" in the same reassuring
voice it uses when nothing did. Sweep 125 when a change can reach the resolver,
and pick the non-vacuity plant with care: a lint-stage change moves nothing in
the diagnostic sweep and would wrongly read as a broken check.

Backlog 4.10: test/roof.test.ts's PDF case opens with a dynamic import of pdfkit
under a 5000 ms budget. 674 ms alone, 5821 ms under heavy parallel load — it
fails as a timeout there and passes 32/32 three times alone, including on main.
Filed rather than smoothed over, because AGENTS.md records that this suite has
no known flake. The entry notes it is the mirror of G.9: there the text was NOT
a timeout and two agents assumed load anyway.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PDo6xNNG4fJpBAPR3ha8R4

Author: Chan Meng

docs/backlog.md

@@ -1747,6 +1747,38 @@ auto-fit cannot start seeing ground.
 generator's size cap, and the full catalogue reaches a model through `llms-full.txt` /
 `arch context --section errors` either way, which DID regenerate.
 
+### 4.10 · A 5 s test budget on a heavy optional import — `todo`
+
+Found 2026-09-04 while gating item 4.9, and worth filing because `AGENTS.md` currently records that
+the suite has **no known flake**.
+
+`test/roof.test.ts` → "PDF export draws it" opens with `await import("pdfkit")`, a heavy optional
+dependency, under vitest's default **5000 ms** per-test budget. Measured on this machine:
+
+| condition | duration | verdict |
+|---|---|---|
+| file run alone, machine idle | **674 ms** | passes, 7.4x margin |
+| inside a full-suite run under heavy parallel load | **5821 ms** | **fails: `Test timed out in 5000ms`** |
+
+So the margin is real but it is a margin on an **import**, not on the assertion — the same run had
+`test/zones.test.ts` take 105 s. It reproduced twice under load and passed 32/32 three times when run
+alone, including on `main`, so it is not a defect in `roof` and was not introduced by 4.9, which does
+not touch that file.
+
+**The trap this entry exists to mark.** The failure text says `Test timed out in 5000ms`, which is
+exactly the diagnosis item G.9 records being WRONG about twice — there, the text said
+`expected at least 1 JSON envelope(s) on stdout, saw 0`, which is not a timeout at all, and two agents
+theorised about load from the *shape* of the symptom without reading it. Here the text really is a
+timeout and the margin was measured, so the reading holds. **Read the assertion, then measure the
+margin; do not pattern-match either way.**
+
+Options, in the order they are worth trying: give this one case an explicit timeout that reflects what
+it does (a dynamic import of an optional native-ish package is not a 5 ms unit test); or hoist the
+capability probe so the import is paid once per file rather than inside the timed case; or leave it and
+say plainly in `AGENTS.md` that the suite has one load-sensitive case, since a number nobody can
+reproduce on a quiet machine is worse than a documented one. **Do not raise the global
+`testTimeout`** — that hides every future instance of the same shape.
+
 ### 4.1 · Joinery pass performance — `todo`
 
 `toScene` got roughly **3× slower** when v1.30 replaced the three wall-lowering paths with one

docs/testing.md

@@ -449,6 +449,31 @@ than stripping text), and remember the corpus fans out: 30 `examples/*.arch` pro
 because `garden-house`, `hillside-villa`, `townhouse` and `two-storey` emit one per storey. A sweep
 that finds 30 has already lost the multi-storey plans.
 
+**The house corpus sweep has a BLIND SPOT, and it is not small.** The sweep everyone reaches for is
+`describe()` + `lint()` + every storey's SVG — 95 artifacts over the 30 examples. Those three payloads
+between them carry **no parse- or resolve-stage diagnostic**, because `lint()` is the soundness layer
+alone. Measured:
+
+```
+arch lint    examples/materials.arch  ->  []
+arch compile examples/materials.arch  ->  ["W_SCALE_OVERFLOW"]
+```
+
+So a change to `W_SCALE_OVERFLOW`, `W_DRAWING_OVERFLOW`, any `W_*_OFF_WALL`, `E_PARSE` or anything
+else raised before `lint()` runs is **invisible to a clean 95-artifact sweep**, and the sweep will
+report "nothing moved" in the same reassuring voice it uses when nothing did. Found in 2026-09 while
+closing backlog 4.9, whose whole subject is a resolve-stage diagnostic: the specified sweep could not
+see the item's own change.
+
+**Sweep 125 when a change can reach the resolver**: add `compile().diagnostics` as a fourth payload,
+one row per example. The two sets are complements — `lint()` covers the lint rules and nothing else,
+`compile()` covers parse and resolve and nothing else — so neither alone is a corpus check.
+
+Prove that one non-vacuous the same way, and pick the plant with care: a lint-stage change (repairing
+an example's furniture, say) moves **nothing** in the diagnostic sweep and would wrongly read as a
+broken check. Perturb something the resolver decides — moving `materials.arch` from A3 to A2 drops
+its `W_SCALE_OVERFLOW` and the sweep names exactly that row.
+
 The same instinct applies to the code under test: **zero corpus movement is not evidence the new path
 ran.** Instrument it with a counter, show which examples reach it and how often, then remove the
 counter and confirm with `grep -c`. Backlog G.1 is the worked example — the changed path fires 228