The spec's boot gates (canvas, registry, title) are all wx-side and go
live seconds before WasmTool drops its opaque boot overlay (ready only
flips after the collab seed + waitForWxUi). The Tools click landed on
the overlay, the popup never opened, and the menu-item wait timed out —
flaky on CI (the 1s title poll sometimes samples after overlay unmount),
100% locally. Add the inset-0.z-30 count-0 guard the chrome-toggle /
tool-switch / quit-* specs already use.
Verified: web-chromium 5/5, web-firefox 8/9 (was 0/5, 0/1). The one
remaining firefox failure is a distinct pre-existing wasm trap on the
CvPcb-open path (EVT.MENU dispatch → "index out of bounds" in a worker),
same signature as the eeschema-fp-selector CI trap — now known to
reproduce on macOS real GL too. Left as a TODO(cvpcb-open-trap) in the
spec; needs a debug-symbol repro.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Rb9jsqtHsC3tHTaJ45244j
The three page.waitForTimeout calls in eeschema-assign-footprints.spec.ts
are legitimate interaction dwells (two poll intervals that pump the wx
event loop inside asserting loops, one first-paint settle before a
screenshot), but were unannotated, so the determinism guard failed CI.
Mark each with a `dwell:` note per tests/TESTING.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
