pcbjam/docs/features/async/22-absorbing-libcontext.md

22 — Absorbing libcontext: one scheduler for JS ↔ Asyncify ↔ fibers

Status: PLAN (2026-08-06), not started. Continues 20 after its D-1/D0/D1 landed, its D2 was reverted, and its D3 met its goal by other means. Read 20 §10 (work log) and 21 (park-site table) first; this doc assumes both.

Decisions already taken by the user: absorb (the scheduler takes over libcontext's wasm backend — one fiber system, not two cooperating ones), and the work continues on feature/async-mailbox.

1. The bug this exists to kill

The blue screen: RuntimeError: index out of bounds (and its siblings unreachable executed, indirect call to null) raised from Asyncify.doRewind, killing the tab during board loads. Its shape, in the field logs' own words: a context gets recovered twice, or recovered by a different fiber than the one that parked it, or recovered from a buffer another party has since overwritten (aliased-wake-live: restoring currData=X over Y).

This is not doc 19's hang. Doc 19 is fixed (a quasi-modal's nested loop no longer parks on a coroutine stack), and that fix removed one ingredient — concurrent parks on fiber stacks — without touching the cause. Anyone reading doc 20 alone may conclude the migration is optional; measured against the blue screen it is not.

2. Why the guards cannot fix it (the real diagnosis)

Asyncify.currData is a single global slot naming "the context currently unwinding or rewinding". Today three layers each decide swaps and resumes with partial information:

layer	decides	guards it invented
libcontext (kicad/thirdparty/libcontext/libcontext.cpp)	every fiber↔fiber swap	swap_suspended, jump-refused-parked, jump-refused-hot-main, ghost-resume epochs
the JS shim (scripts/common/shims/asyncify-scheduler.js)	wake delivery, resume admission	__internallyParked, __parkSleepBuf, __validSuspensions, fiber-resume-refused, aliased-wake-live
wx (wxwidgets/src/wasm/evtloop.cpp)	whether dispatch may run	wxWasmDispatchDepth interlock, zero/restore around parks

The bookkeeping is already centralised — the decision is not. S2 made currData a single-writer accessor with a stray tripwire, and the shim already wraps Fibers.finishContextSwitch and authorises the write. So the shim sees every swap; what it cannot do is prevent one, because the decision to swap was made in libcontext, which never told it. Each layer is therefore reduced to answering "is entering this fiber safe?" by inference, and each invented its own heuristic. That thicket is the patchwork.

Centralising means moving the decision, not adding more observation.

3. Why the phases knotted (do not repeat this)

Doc 20 sequenced D2 (dispatch on a context) → D3 (waits yield contexts). Both orders fail:

• D2 alone (measured, reverted): a quasi-modal opened from a tick handler suspends the dispatch context inside a still-in-place wait, adding an Asyncify layer beneath every libcontext fiber. The coroutine-nested battery died at fiber_create_run_destroy_inside_modal (aliased-wake-live → fiber-resume-refused). Growing a context pool made it worse (8 contexts burned in 30 ms — a context suspended in a modal is consumed for that modal's lifetime); falling back to entry-stack dispatch did not help either, because the extra layer exists the moment the context is suspended.
• D3 alone (measured, guarded): a wait must yield the context that owns its stack, and the doc-19 path's owner is a tool coroutine, not a scheduler context. yield_park now refuses that case (foreignStackRefusals) rather than saving the tool fiber's stack into the host context's fiber struct.

So the dependency is a knot: dispatch needs waits migrated, waits need tool coroutines to be contexts, tool coroutines are libcontext's. Absorbing libcontext is what unties it, which is why it comes first here rather than last.

4. Target architecture

browser tick ─► scheduler.drain()          ONE decision point
                  │  registry = truth; at most one transition in flight
                  ├─► dispatch context     (wx handlers)
                  ├─► tool contexts        (KiCad COROUTINEs — libcontext's clients)
                  ├─► wait contexts        (modal / nested / popup)
                  └─► bridge contexts      (lib, 3D, occ, ngspice, clipboard, font)

Invariants, all already implemented and tested in wx/wasm/private/sched_context.h:

1. Star, not mesh — contexts yield only to the scheduler; only the scheduler resumes. A resume is a registry lookup, never an inference.
2. One transition in flight; drain() is not re-entrant.
3. Wakes never resume inline — mark_ready queues, drain resumes from a clean stack.
4. A context yields only its own stack — enforced by stack-range ownership check.
5. Buffers are owned: one context, one stack, one asyncify buffer, never shared.

5. Phases

Estimates assume one engineer familiar with this stack, and are grounded in this run's measured cycle costs (§8). The A / BCD / E / F split matters: A is landable alone because it is behaviour-preserving; B+C+D must land together (§3).

Phase A — absorb libcontext's wasm backend (3–5 d) · landable alone

Replace the body of libcontext's wasm implementation so make_fcontext / jump_fcontext / release_fcontext become thin adapters over pcbjam_sched, keeping the exact same observable semantics (symmetric swap, same return values, same INVOCATION_ARGS contract). The registry now knows every tool fiber: its stack range, its buffer, its status.

• Keep libcontext's existing guards as tripwires that must never fire; do not delete.
• No caller changes. KiCad still calls jump_fcontext; TOOL_MANAGER is untouched.
• Gate: coroutine trio + coroutine-nested + races + full kicad suite unchanged, and zero tripwire firings across the fuzz suites.
• Why it is safe alone: semantics are identical; only the party doing the bookkeeping changes. This is the de-risking step D2 never had.

Phase B — tool coroutines become scheduler contexts (1–2 wk) · the bulk

Flip the topology from symmetric to star: COROUTINE::Resume/Call become mark-ready-and-drain; a coroutine yields to the scheduler rather than to its resumer.

• The seam is CALL_CONTEXT/doCall/doResume in kicad/include/tool/coroutine.h plus TOOL_MANAGER's m_activeState handling.
• RunMainStack must keep working — it is now "run on the scheduler's caller context".
• Expect this to be most of the risk and most of the calendar time.

Seam read in full after Phase A landed (2026-08-06) — the crux, stated precisely. TOOL_MANAGER's contract is SYNCHRONOUS and the star's is not, and that single mismatch is the phase:

• dispatchInternal does st->cofunc->Call( st->initialEvent ) and then, on the very next line, if( !st->cofunc->Running() ) finishTool( st ) (common/tool/tool_manager.cpp:870-874). So Call must run the coroutine to its first yield before returning. Same shape at ShutdownTool (:592) and the pending-wait resume (:808).
• The star says a resume happens from a clean stack via drain(), and drain() deliberately refuses re-entry — a context calling it would turn the star into a cycle. But dispatch RUNS on a stack the scheduler may own (that is Phase D), so "Call → drain" is re-entrant by construction unless dispatch is already a context. This is the same knot doc 20 §3 measured from the other side, and it is why B, C and D cannot be separated.
• CALL_CONTEXT::Continue's CONTINUE_AFTER_ROOT loop (coroutine.h:175-183) is a second, hand-rolled scheduler: the coroutine jumps to the ROOT stack, the root runs m_mainStackFunction, then resumes the coroutine. Under the star this is just "park with a reason, let the scheduler run the functor, mark ready" — the loop should disappear rather than be ported.

A Phase A measurement that changes B's shape: grace-ring-over-capacity: 33 — KiCad holds 30+ coroutines that never finished and whose owners are gone, and still jumps into them. Under the star every one needs a live context (128 KB + buffer each, vs libcontext's 512 K), so B must fix the lifetime, not just the topology: give COROUTINE an owning handle and destroy the context when the tool state is popped. The grace ring is the measurement of exactly how much that is worth, and it should fall out of the tree at the end of B, not survive into C.

Divergence policy (§10 q4), now answerable: Phase A touched KiCad only inside thirdparty/libcontext — vendored code, no upstream conflict. B is the first phase to restructure coroutine.h + tool_manager.cpp, which CLAUDE.md's "keep the fork close to upstream" rule makes a real cost. Decide before starting: either accept the divergence, or keep the star adapter entirely inside libcontext + sched_context.h and leave both KiCad files untouched, which is likely possible because the whole seam is jump_fcontext calls.

Phase C — waits yield the owning context (3–5 d)

wxWasmYieldUntil becomes a context yield: look up the owner of the current stack (the mechanism exists), park it, and let resolveWait mark it ready. The doc-19 main-stack bounce (wx/wasm/private/mainstack.h) becomes unnecessary and should be removed in the same flip — it is a mitigation for exactly the condition this phase eliminates.

Phase D — dispatch on a context (3–5 d)

Doc 20's D2, retried. The reverted implementation is recoverable from git (design-b D2 in the work log) and was correct apart from its dependencies; the pool idea in it is wrong and must not come back — one dispatch context suffices once waits yield.

B + C + D land as ONE commit. Each alone regresses. Build them on a sub-branch, keep every guard as a tripwire, flip once, gate hard.

Sub-branch feature/async-star-flip (2026-08-06): the core mechanism is built and proven, the wiring is not. Landed there: fiber_transfer(from, to, value) — libcontext's symmetric swap expressed as a star transition (park the source, make the target runnable, the scheduler performs every entry) — plus fiber_start (the lane's entry point, since a transfer needs a running context to park) and drain_all (the top-level pump, because a star transition only makes work runnable).

The question that decided whether B is possible at all is answered YES and pinned by star_transfer_call_is_synchronous: parking the caller and resuming it when the callee yields is indistinguishable, in the caller's own C++ frame, from a synchronous return. So TOOL_MANAGER's Call(); if( !Running() ) contract survives the flip untouched — which is what makes a KiCad-minimal Phase B realistic.

The constraint that fixes the order of the remaining wiring — ONE root, not two. ensure_scheduler_context() adopts whatever stack first calls drain(), and libcontext's ensure_main_context() adopts whatever stack first calls jump_fcontext. In production both are the main stack, so the scheduler fiber and the libcontext root would be two emscripten_fiber_ts describing the SAME stack — mutual corruption the moment either is entered. In Phase A this was harmless (nothing in KiCad ever called drain()); at the flip it is fatal. Therefore:

1. D first, inside the flip: dispatch moves onto its own context, so the main stack is only ever the scheduler and nothing else runs there.
2. libcontext's root then adopts the running context (the dispatch context), never the main stack.
3. Only then may jump_fcontext become fiber_transfer, because every caller is now provably on a context and can park.
4. C follows naturally: wxWasmYieldUntil yields the owning context, resolveWait marks it ready, and the doc-19 mainstack bounce comes out.

The tick becomes fiber_start(dispatch, …) + drain_all() from a fresh JS task.

MEASURED PLAN CORRECTION (2026-08-06): D forces D5, and E cannot wait. The wiring above is implemented on the sub-branch (dispatch context + wxWasmYieldUntil yielding its owner + the shim routing resolveWait to mark_ready + libcontext's root adopting the running context + jump_fcontext becoming fiber_transfer). wx compiles, the sched-context battery and 41 of 48 wx/asyncify tests stay green — but the coroutine and coroutine-nested harnesses now fail with overlapped-wake: restoring currData=… over null, the exact class this work exists to remove, and the trace names the cause:

fcs old=…    new=…     w=0 rf=wxWasmTopLevelTick
fcs old=…    new=…     ROOT w=0 rf=dynCall_vi
[wx-asyncify] overlapped-wake: restoring currData=… over null

wxGUIEventLoop::DoRun's top-level loop parks the MAIN stack every frame in wxWasmYieldToBrowser (doc 21's W2, classified "safe by construction … unless D5 is taken"). That classification held only while dispatch also ran on the main stack. Once the scheduler swaps contexts from the tick, the main stack's per-frame Asyncify park and the scheduler's transitions interleave over one currData.

So the one-root constraint is stronger than first written: the main stack must be the scheduler and nothing else — which means the main loop itself has to become a context (D5), not merely dispatch (D). D5 is therefore no longer optional and no longer "decide with Phase E telemetry"; it is part of the same flip. By the same argument, any remaining in-place Asyncify park under a context (doc 21's K1–K7 bridges and the T1–T3 levers) can reproduce this, so E belongs in the flip too, or each bridge must be proven never to run beneath a context first.

Revised flip contents: D5 + D + C + B + E, landed together. That is a bigger single commit than doc 22 §5 planned, and it is the honest consequence of the measurement — the alternative (landing D without D5) is the partial migration this document forbids.

What D5 actually costs (analysed 2026-08-07, before writing any of it)

DONE 2026-08-07 — see §10's D5 entry. Options (1)+(2) below were both needed; delta-zero on the batteries; three non-D5 findings recorded there, including a real regression in the WIP libcontext change that must be fixed before the flip.

wxGUIEventLoop::DoRun's top-level body is:

while( !m_shouldExit ) { wxWasmScheduleProcessEvents(); wxWasmYieldToBrowser(); }

The park is not incidental — it is how a synchronous C++ frame waits for the next frame. A frame that must not park has only one other way to wait: return. So D5 is not "run the loop on a context" bolted onto the current shape; it is:

1. the loop body moves to a main-loop context whose per-frame wait is yield_park;
2. DoRun returns to main(), and the app is thereafter driven by JS ticks calling the pump (a rAF loop marking the main-loop context ready, then drain_all());
3. therefore main() must return without tearing wx down — the runtime stays alive (EXIT_RUNTIME=0, no wx cleanup on that path).

Step 3 is the real cost: it changes application lifetime, and the existing comments record that this area was deliberately built to avoid exactly that (simulate_infinite_loop=1's unwind throw is fatal under native wasm-EH — docs/features/wasm-exceptions/08+09). Returning normally is NOT that throw and should be safe, but it needs its own gate: teardown paths, ~wxTopLevelWindowWasm, the shutdown latch in S6, and the "quit notify only from IsMainFrame" fix from v0.1.28 all live on the assumption that DoRun returning means the app is ending.

No smaller fix exists, and this was checked rather than assumed: the scheduler stack IS the main stack, so while the main stack is Asyncify-parked in the rAF yield, any pump entry re-enters wasm on a stack that is logically suspended — which is the overlapped-wake above. Since the loop parks every frame, there is no window in which pumping is safe. Hence the park has to go, and hence the return.

Recommended next move: do D5 first and ALONE on the sub-branch, gated by the wx battery + coroutine trio (no KiCad build needed — it is wx-only), because it is the step most likely to be wrong and the cheapest to iterate on. Only once the main stack is provably scheduler-only should D/C/B/E be re-enabled on top; they are already written and committed here (WIP star-flip), currently sitting behind this blocker.

Where the D5 change must go — traced, and it is not in the wasm layer. The call chain is main() → wxEntry → wxApp::OnRun() → MainLoop() → wxEventLoop::Run() → wxGUIEventLoop::DoRun(), and wx/app.h:102 states the contract plainly: "When OnRun() returns, the program starts shutting down." So DoRun returning is not a local wasm-port decision — it propagates up into wx's own teardown.

That collides with CLAUDE.md's standing rule ("don't change the wxwidgets core unless absolutely necessary; fix things in the wasm layer"). This is the case that rule's escape hatch exists for, but it must be taken deliberately, not discovered mid-flip. Three options, in the order they should be evaluated:

1. A wasm-port OnRun override that starts the main-loop context, returns to JS, and never lets wx's shutdown path run — keeps the change inside src/wasm/, which is where the rule wants it. Verify what wxEntry does after OnRun returns before assuming this is enough.
2. A core wxEntry/OnRun change gated behind __WXWASM__, if (1) cannot keep teardown from running.
3. Keep DoRun from returning at all by parking its frame on a context — rejected above, because the frame that waits for the next browser frame must either park the stack it stands on (the thing D5 removes) or return.

Whichever is chosen, the gate must cover teardown explicitly: ~wxTopLevelWindowWasm, S6's shutdown latch, and v0.1.28's "quit notify only from IsMainFrame" fix all encode the current assumption that a returning DoRun means the app is ending.

Phase E — bridges on contexts (1 wk)

Doc 21 §1's K1–K7 and W4/W5 through one wasm_await_promise-style helper. After this no handleSleep park happens on any fiber stack — assert it. Take each bridge's deep-park high-water from its own beacon and size buffers from that (doc 21 §2b); D1's ~34 B/frame is a synthetic floor, not a budget.

Phase F — delete the guard thicket (2–3 d)

Only now, and only guards that have been provably silent: libcontext's refusals, the shim's quarantine/consume-once, the wx interlock and its zero/restore sites, the open/fiber-busy gates. Flip fiber-resume-park.spec.ts from "refused" to "resumed after its park resolves".

Total: ~4–6 weeks, of which B is half.

6. Gates — what "done" means

The batteries never reproduced the blue screen, so they cannot certify it. Use all three:

1. The crash's own repro (the only proof that matters): REPRO_PROFILE + a ≥120 MB project + 2–4 warm loads; watch for the 68/N counters and kill-fiber signature. Target: rootHotTotal == 0, zero aliased-wake-live, zero refusals.
2. The full net: kicad suite, wx battery, coroutine trio, races, sched-context, quasimodal-strand (now a green regression pin), the drift/collab fuzz suites.
3. Tripwire silence: every guard retained during A–E must record zero firings across a full fuzz run before Phase F deletes it.

Known-pre-existing failures to expect and NOT chase: occ-probe glb format matrix, and e2e/modal.spec.ts:125 (environment-sensitive; fails on unchanged binaries).

7. Invariants and traps learned in this run

Hard-won; each cost at least one build+test cycle.

1. Fiber C stacks must be 16-byte aligned. EM_ASM puts its argument buffer on the running stack and the glue asserts buf % 16 == 0; emscripten's malloc gives 8. A misaligned context traps in readEmAsmArgs on every EM_ASM (found via 107 wx failures). AlignedBuffer in sched_context.h handles it — do not hand a fiber a std::vector<char>::data().
2. emscripten_stack_get_base()/end() describe the CURRENT stack, not the main one. finishContextSwitch calls emscripten_stack_set_limits with the incoming fiber's bounds, so a live query reports "on the main stack" from everywhere and detects nothing — silently. Capture the main stack's bounds once, where you are provably on it.
3. Every emscripten_fiber_t needs its own asyncify buffer, including the host side of a swap. A zero-initialised one has a null buffer and traps on first swap. This briefly looked like proof that fiber-on-context nesting was impossible; it is not — fiber_nests_in_context pins that it works.
4. A wait must yield the context that owns its stack. Yielding a context you merely sit on top of saves the wrong stack into its fiber struct: silent, total, undetectable after the fact.
5. Partial migration is worse than none — measured twice (§3). If a change leaves one participant parking in place while another expects contexts, it will regress.
6. A parked context must not be freed, and a resume must never be inferred. Both are registry lookups; keep them that way.
7. Test-infrastructure trap: tests/apps/gal-webgl + build-wasm/sysroot hold gitignored artifacts no normal build produces. Losing them looks like a 29-test mass regression. Fix: scripts/setup-worktree.sh. When triaging a mass failure, first run find tests/apps -name '*.wasm' -newermt <last known good> — it settles "my change vs the environment" in seconds.

8. Cycle costs (for planning)

Measured on the dev Mac, warm caches: wx rebuild ~5 min · all wx test apps ~10 min · docker/build.sh kicad_editor ~15 min · wx+asyncify+coroutine battery ~5 min · full kicad suite ~8 min. So one full "change → verdict" loop on a KiCad-side change is ~25–30 min, and a wx-only change ~20 min. Budget phases accordingly; batch experiments per build.

9. Where the pieces are

what	where
context primitives + registry + memory gate	wxwidgets/include/wx/wasm/private/sched_context.h (header-only)
its harness + gate	tests/apps/standalone/sched-context/, tests/asyncify/sched-context.spec.ts
the scheduler shim (mailbox, waits, wakes, guards)	scripts/common/shims/asyncify-scheduler.js
libcontext's wasm backend (Phase A's target)	kicad/thirdparty/libcontext/libcontext.cpp
tool coroutine seam (Phase B)	kicad/include/tool/coroutine.h, kicad/common/tool/tool_manager.cpp
wait bridges (Phase C)	wxwidgets/src/wasm/evtloop.cpp, dialog.cpp, window.cpp
the doc-19 mitigation to remove at Phase C	wxwidgets/include/wx/wasm/private/mainstack.h, wasm/bindings/main_stack_runner.h, TOOL_MANAGER::RunOnMainStackIfActiveTool
park-site inventory	21 §1
doc-19 regression pin	tests/kicad/quasimodal-strand.spec.ts

Branch: feature/async-mailbox, unpushed across 6 repos. Baseline tags: mailbox-s0-baseline, d-1-pre-delete. Tag before each phase's flip.

10. Work log

Phase A — DONE, gate met (2026-08-06) ✅

Final gate: full kicad suite 139 passed / 1 failed — the failure is the known pre-existing occ-probe glb format matrix, i.e. the baseline exactly. wx battery 346 passed / 1 failed (pre-existing e2e/modal.spec.ts:125) / 3 skipped; coroutine trio + nested + races + asyncify 48/48; sched-context 2/2 including three new fiber-lane scenarios. Tripwire sweep over every suite log: zero sched-divergence-*, zero swap-lost, zero fiber_swap() refusals, zero FIBER-SWAP-NONENTERABLE, zero FIBER-RELEASE-RUNNING, zero jump-into-reclaimed, zero grace-ring-evict. The registry's view agreed with libcontext's protocol on every swap in the suite — which is the whole claim Phase A had to earn before Phase B moves the decision.

Landed (working tree, uncommitted):

• sched_context.h grew the fiber lane: fiber_adopt_current / fiber_create (caller-owned C stack adopted, registry-owned asyncify buffer) / fiber_swap / fiber_enterable / fiber_release, with its own counters so the D1 star memory gate keeps meaning what it meant. Suspended-capture high-water is sampled before the resume consumes it (afterwards it always reads 0) — that number is Phase E's sizing input.
• libcontext.cpp's wasm backend became the adapter: wasm_fcontext keeps only protocol state (return_to, transfer_value, epochs, refcounts); the emscripten_fiber_t + buffer live in the registry; every swap (jump and trampoline return) goes through pcbjam_sched::fiber_swap. swap_suspended stays AUTHORITATIVE for the parked-jump refusal and the registry only observes, beaconing sched-divergence-* on disagreement (see bug 3).
• thirdparty/libcontext/CMakeLists.txt gained the wx include path under EMSCRIPTEN. Harness + spec: 3 fiber-lane scenarios, fiber stats assertions.

Four real bugs, every one caught by a tripwire rather than by guessing. Each is worth reading before Phase B, because three of them are the same mistake:

1. Never infer the swap's from side. The first cut derived it from the lane's "current", which goes stale across a handleSleep park exactly like g_current_context does — the wrong context got marked Suspended, the real swapper stayed "Running" forever, and every later jump into it was wrongly refused (a dispatch the legacy guard would have allowed). libcontext KNOWS who is swapping out; fiber_swap(from, to) now mirrors its answer, keeping the two layers in lockstep by construction.

2. A release must always release. libcontext's refcount drop deletes the struct unconditionally; the registry refusing a "Running" release while the caller frees anyway left a permanent ghost (plus a dangling g_current_context — the garbage-id beacon) that poisoned every later enterability answer. Now: release always, FIBER-RELEASE-RUNNING beacon.

3. The registry must not OVERRULE the protocol, only record it. Keying the parked-jump refusal on fiber_enterable() refused a dispatch the legacy backend permitted: Symbol Properties stopped opening (quasimodal-strand, a fiber the registry still called Running while swap_suspended said validly suspended). Phase A moves the BOOKKEEPING, not the decision. swap_suspended is authoritative again; every disagreement is now a recorded fact instead of a behaviour change, and those recordings are the evidence Phase B's flip gets designed on.

4. Absorbing the buffer un-hid a KiCad use-after-free. TOOL_MANAGER keeps raw fcontext_ts that outlive the COROUTINE owning them and jumps into them after the last refcount is gone. This "worked" for years for a reason worth writing down: the freed block was ~512 K (the asyncify buffer lived INSIDE the struct), and malloc parks that size in a large bin, so freed stayed readable essentially forever. Moving the buffer into the registry left a ~64-byte struct — recycled on the next call — so sched_id read back as a freelist pointer (0x16554B0), the swap was refused, and EVERY canvas tool wedged ("click never landed a selection", "box-select never selected anything", 19 suite failures). The change did not introduce the bug; it removed the size accident that concealed it.

The rule all four share, and the one to carry into B–E: the registry may only record what the protocol actually did — it may not guess it, and it may not refuse anything the legacy code permitted. Phase A is behaviour-preserving or it is nothing.

The grace ring (bug 4's containment, and a Phase B input). Released contexts are kept, not freed: the struct is never deleted (protocol state only now — tens of bytes, cheaper than the accident it replaces, and it makes a stale jump land on a real sched_id), and the FIBER (512 K + registry entry) is bounded by a 32-entry ring. Eviction takes only coroutines that actually FINISHED — evicting by age alone dropped long-lived tool coroutine #1 that TOOL_MANAGER re-enters, and m-move plus lock-resist failed. An evicted context keeps its struct with sched_id zeroed so a later jump takes the ghost contract callers already handle.

Measured, and it is the number Phase B needs: grace-ring-over-capacity: 33 fired in 4 specs — i.e. 33 released coroutines were live with NONE evictable, because none had finished. So KiCad really does hold 30+ never-finished coroutines whose owners are gone, and the ring cannot reclaim them: worst case that is ~16 MB of retained asyncify buffers, and it grows with the working set rather than being capped by the ring. This is not a leak Phase A may fix (that would change behaviour); it is exactly what Phase B removes by giving coroutines scheduler-owned lifetimes, and it should be re-measured after that flip.

Process traps paid for in this run:

• Build against the libs volume (COMPOSE_PROJECT_NAME=kicad-wasm-libs). A bare docker/build.sh creates a cold per-branch volume whose sysroot lacks glm and dies at the gl1 shim.
• npx playwright test does NOT sync output/*.wasm into tests/apps/kicad/; only npm run test:kicad (which runs setup:kicad first) does. A retest after a rebuild that shows byte-identical beacons is testing the OLD binary — this cost a full diagnosis cycle.
• A Docker VM at 100% disk fails builds with exit 137 and simultaneously crash-loops the user's unrelated postgres containers (could not write lock file). Diagnose and report; never prune or delete Docker state to clear it.

Baseline tags phase-a-pre on root/pcbjam/kicad/wxwidgets.

D5 — built, measured, delta-zero (2026-08-07) ✅ with findings

Baseline tags d5-pre on root/pcbjam/kicad/wxwidgets. Option (1)+(2) from the analysis above: the wasm OnRun override alone is NOT enough — verified: wxEntryReal runs OnExit() (the CallOnExit destructor) and the wxInitializer destructor's wxEntryCleanup right after OnRun returns — so a minimal __WXWASM__-gated change in init.cpp accompanies it.

Landed (wxwidgets, on the sub-branch):

• wxApp::OnRun() (wasm port) calls wxWasmDetachMainLoop(this): the whole stock main loop (wxAppBase::OnRun → MainLoop → Run → DoRun) moves onto a wx-main-loop fiber-lane context (1 MB stack / 512 K asyncify, same sizing as the dispatch context), so the loop object, its activator and m_shouldExit all live on the context stack and ScheduleExit/IsInsideRun keep working. On detach failure it falls back to the inline loop (pre-D5 shape) — nothing depends on the context existing.
• DoRun's per-frame wait: can_yield_here() → arm a rAF wake → yield_park("frame"); else the old in-place wxWasmYieldToBrowser. The rAF callback and the first kick are both fresh JS tasks calling wxWasmMainLoopPump (Fresh → fiber_start, parked at "frame" → mark_ready, then drain_all) — mirroring wxWasmDispatchOnContext.
• First entry MUST come from a clean task AFTER main() returns (a setTimeout kick armed in the detach): entering from OnRun's own frame would capture main()/wxEntry frames into the scheduler fiber's buffer and main would "return" inside a later pump's rewind.
• Main-stack bounds are captured in the detach, the last moment we provably stand on the main stack — DoRun now runs on the context, where the live-query trap (§7.2) would record the context's bounds and silently break wxWasmOnCoroutineStack.
• Teardown moved to the loop context's exit path: after the loop exits (S6 latch fires as before), the context entry runs OnExit() + wxUninitialize(), then parks forever. init.cpp (__WXWASM__-gated): CallOnExit skips OnExit when detached, and a wxAtomicInc(gs_initData.nInitCount) after OnRun pins wxEntryCleanup off — the loop context's own wxUninitialize balances it. EXIT_RUNTIME is unset (default 0) everywhere, so main() returning keeps the runtime alive.
• Doc 22 flip staging switches in evtloop.cpp: wxWASM_STAR_DISPATCH (Phase D tick dispatch, currently 0 — re-enable for the flip) and wxWASM_D5_DETACH (1).

Gate: 387 passed / 3 skipped across wx battery + asyncify + coroutine projects with D5 ON, and — the load-bearing number — the failure set is IDENTICAL with D5 OFF (same tree, toggle flipped): D5 is delta-zero. The per-frame scheduler↔loop-context swap pairs are visible and clean in the flight recorder (rf=wxWasmMainLoopPump). The failures themselves predate D5, and a working-tree bisection (revert one file at a time, rebuild apps, rerun) decomposed them into three ingredients — none of them D5:

1. The WIP jump_fcontext→fiber_transfer libcontext change moves the nested death from case 5 to case 2 (baseline_fiber_alone, hot-main-swap-out → Aborted inside the swap); reverting the one file moves it back — but does NOT make the suite green (see 2). Whether that is a semantic delta in the dormant fallback (current()==0 → Phase A direct swap — a line-by-line audit found none: the transfer_value assignments are idempotent and the transfer branch is unreachable) or merely binary layout shifting the same cliff (finding 3 proves layout alone can) is UNDETERMINED. Treat it as a cliff datapoint, not a proven regression — do not burn a build cycle hunting a delta that may not exist. What IS corrected: the WIP-tip nested failure was blamed on the D wiring, but it reproduces with the D tick gated off.
2. The Phase A scoreboard is stale for coroutine-nested TODAY: at the exact Phase A state (wx 719fd98798, Phase A shim + libcontext, freshly rebuilt), nested dies deterministically at fiber_yield_across_modal_close — hot-main-swap-out occurrence 3 → abort — on both engines. Nothing on the branch causes it; the 8/6 green is not reproducible in today's environment. Re-baseline before attributing nested reds to a change.
3. asyncify-races wakeup_during_transition sits on the same cliff: green at Phase A wx, red with the WIP+D5-dark wx library on the same shim/libcontext — it flips with wx binary layout/timing, not with any active code path.

All three are the hot-main-swap-out wake-window class (doc 21's W/K sites): a libcontext jump inside a root sleep-wake continuation writes a ~1 KB unrewindable capture (rem= telemetry confirms), and whether the eventual rewind survives is environment- and layout-sensitive. That fragility is not fixable at D5 — it is exactly what C+B+E remove structurally (no in-place parks → no wake windows → no hot jumps), so expect these harnesses to go green AT the flip, not before it.

Still open from the teardown gate: the detached exit path (loop exits → OnExit + wxUninitialize on the context) compiles and is reachable but no battery spec drives a real app quit through it; add one before the flip relies on it. (Closed the same day: tests/e2e/app-quit.spec.ts + a wx_test_quit hook in minimal_test.cpp drive a real File→Quit-shaped exit and assert the S6 latch fires "clean" with no traps — green in the D-on probe below.)

D-on probe (2026-08-07) — flip staging measured; the cliff solved; two Phase B gaps named

wxWASM_STAR_DISPATCH=1 on top of D5 engages D (dispatch context) + C (waits park it)

• B's transfer mechanism (libcontext root adopts the running context, jumps become transfers) in one flip. Three build-measure cycles, each fixing what the previous named:

1. THE "ENVIRONMENTAL CLIFF" WAS ADOPTED-STACK ALIGNMENT — §7 trap 1, live all week. The first D-on run killed the plain coroutine suite at its FIRST case with Aborted(Assertion failed); the JS stack named readEmAsmArgs's buf % 16 == 0 assert. The coroutine harness allocates fiber stacks with std::make_unique<char[]> — plain new, 8-byte aligned — and fiber_create adopted the range raw, so whether a given stack landed 16-aligned was HEAP-HISTORY LUCK. Phase A moved the 512 K asyncify buffers into registry-malloc'd blocks, shifting the heap layout for everything after — which is why the deaths appeared this week, moved with any binary change, were deterministic per build, and read as "environmental". This retires the D5 entry's findings 2 and 3 with a mechanism: nested's case-5 death and the races layout flips were alignment luck, not a mystery. Fix: fiber_create adopts the largest 16-aligned sub-range (bottom up, size down, ≤30 bytes lost) and refuses stacks too small to align. KiCad's real COROUTINE maps whole pages (aligned), which is why production never saw it — only new char[] clients (the harness) sat on the cliff.

2. With alignment fixed, D5+D reached 388 passed — plain coroutine, coroutine- pthread, wakeup_during_transition AND the new app-quit teardown spec all green. Remaining: nested fiber_create_run_destroy_inside_modal ([sched-ctx] REFUSED mark_ready() on a running context — the modal's wake was lost) and races nested_quasi_modal_pump_error (watchdog, suspension never completed).

3. THE ONE-ROOT BINDING WAS WRONG — the root's identity is a PER-JUMP question. The D wiring bound libcontext's root ONCE to current() at first jump (the dispatch context). But mailbox timers and DOM handlers still enter on the MAIN stack until Phase E completes, and a timer jumping a fiber from the main stack then used the DISPATCH context's fiber struct as its from-side while that context sat PARKED in a modal — overwriting the parked capture, marking it Running, and losing the modal's resolve (mark_ready() on a running context). Landed in libcontext: resolve_root_identity() (the running scheduler context, else a lazily-adopted main-stack fiber) stamps the root at EVERY jump out, replacing the bind-once.

A second half was attempted and REVERTED the same day: routing a jump INTO the root at "whoever entered me" (entered_from_sched), to cover a delayed yield-back after other stacks re-stamped the root. It is wrong for CONTINUE_AFTER_ROOT — that invocation jumps into the root struct meaning THE ACTUAL ROOT of the moment (to run a main-stack functor), not the enterer, and misrouting it threw an uncaught C++ exception out of a rewind (nested_coroutine_call_and_resume). Correct routing is invocation-aware — libcontext only sees the type inside INVOCATION_ARGS — which is Phase B's redesign, not an adapter patch. The delayed-yield-back stale stamp is therefore gap 3 below (it only bites with D on).

4. That fix un-hid the last gap: FINISHED-COROUTINE TRANSFER LIVELOCK. With the routing correct, nested's case-3 mechanism is closed but the plain coroutine suite livelocked: the recorder shows two finished coroutines' trampoline "bounce" loops (while(true) re-entry ghost contract) expressed as star transfers, each bounce marking the other Ready — a mutual re-queue that ping-pongs across ticks forever. One symptom of the same incompleteness: sched-divergence-enterable storms on every transfer jump, because fiber_enterable() predates the star statuses (a transfer-parked context reads Parked, not Suspended). This is exactly the Phase B §5 scope ("give COROUTINE an owning handle", "the CONTINUE_AFTER_ROOT loop should disappear rather than be ported") — not patchable at the adapter.

Decision: wxWASM_STAR_DISPATCH back to 0. D5 + the alignment fix + the root-identity fix land as proven groundwork (all are correct or inert at D-off); the flip re-enables the switch when Phase B owns coroutine lifetimes. The two gaps it must close, each with a deterministic repro suite:

1. Wake ordering: a resolve arriving while the target context is Running must QUEUE (the S2 deferred-wake law applied to the registry), not refuse — mark_ready() on a running context is a lost wake today. Repro: nested case 3 at D-on (pre-root-fix shape).
2. Finished-coroutine lifetime: transfers into/out of trampoline re-entry loops livelock; Phase B's owning handles + scheduler-owned lifetimes replace the ghost bounce. Repro: plain coroutine suite at D-on with the root-identity fix. Include the fiber_enterable() status mapping (Parked/Ready are valid suspensions for the cross-check) in the same change.
3. Invocation-aware root routing: a jump into the root struct must resolve to the actual-root-of-the-moment for CONTINUE_AFTER_ROOT but to the enterer's identity for a delayed yield-back (a coroutine resumed across JS turns after other stacks re-stamped the root). The adapter cannot tell them apart; the star topology (every party a context, return_to a registry id) makes the question disappear.

Phase B at D-on (2026-08-07) — gaps 1+2 CLOSED, and the boundary found

Gaps 1 and 2 are fixed and the wx battery is green at D-on: 395 passed, 1 failed (the pre-existing modal.spec.ts:125) — the first clean battery with dispatch contexts, context waits and star transfers all live. What landed:

• Terminal finish (gap 2). fiber_finish_transfer marks a finished coroutine Finished — never re-queued, never re-entered — and fiber_transfer refuses into a Finished context, dropping the caller into libcontext's existing ghost contract. This replaces the trampoline's while(true) ghost re-entry, which as transfers had two finished coroutines marking each other Ready forever. fiber_enterable now accepts the star statuses (a transfer-parked context holds a capture as valid as a symmetric Suspended one), which also silenced the sched-divergence-enterable storm.
• Dispatch is an IDLE-REUSE SET, not one context — doc 22's "one context suffices" was wrong. A nested quasi-modal loop is a wait that only a LATER dispatch can resolve, so a single dispatcher parked in that loop can never be released: nested_quasi_modal_pump_error wedged exactly there. A tick now reuses any context parked at dispatch-idle and allocates only when all are parked deeper. This is NOT D2's pool (which took a fresh context per tick and grew with the tick rate); the live count is bounded by real modal-nesting depth — 1 in steady state.
• abandon_transition (a new containment). With a second dispatcher the race's bomb finally fired and revealed the next layer: an exception escaping a handler propagates out THROUGH drain()'s fiber swap, so its post-swap bookkeeping never runs, the registry stays "transition in flight", and every later pump refuses — a permanently dead pump and every outstanding wait stalled. The JS error paths now abandon the transition and POISON the half-unwound context (Finished; the dispatch set prunes it), mirroring wx_dispatch_abandon. .ci-cache-epoch → 12.

THE BOUNDARY, measured on the full KiCad suite (135 passed / 5 failed vs the 139/1 baseline). Four canvas-tool specs — eeschema draw-wires, pcbnew draw-lines, pcbnew move-with-m, presence-locks move — die with index out of bounds in doRewind ← finishContextSwitch ← Fibers.trampoline ← maybeStopUnwind: the BLUE SCREEN itself, reproduced by the migration's own transitional state.

The reason the harness cannot see this, and the reason it is a boundary rather than a bug: real KiCad tool coroutines park IN PLACE inside their bodies (a tool waiting for the next event asyncify-parks on its own stack — doc 21's tool-side sites). A star transfer turns one symmetric swap into a park-and-drain round trip, and doing that over a stack that is already asyncify-parked mid-body rewinds state the fiber layer cannot see. The harness's coroutines yield cleanly, so the transfer lane looks correct there while KiCad's real tools break — the same "the harness models the shape, not the parks" lesson as doc 19.

Consequence for the plan: D cannot carry KiCad until the tool-body park sites are contexts too. That is C+E completion (every wait yields its owning context; no handleSleep park on any fiber stack), which doc 22 §5 already requires before the flip — this measurement just proves the ordering is not negotiable and that D-on without it is precisely the partial migration §7.5 forbids.

Landing state: wxWASM_STAR_DISPATCH back to 0, with everything above kept — all of it is correct-or-inert at D-off, and gaps 1+2 stay closed for the flip.

The tool-body park site, NAMED (2026-08-07) — RunSynchronousAction's spin loop

Traced rather than inferred, and it is ONE site, not the open-ended set doc 21's K7 row feared:

TOOL_MANAGER::RunSynchronousAction        kicad/include/tool/tool_manager.h:197
  -> processEvent( event )                kicad/common/tool/tool_manager.cpp:366
  -> while( synchronousControl == STS_RUNNING ) {   :368
         wxYield();                                  :370   nested dispatch
         wxMilliSleep( 1 );                          :371   -> nanosleep
     }
        nanosleep (main thread)           wasm/shims/nanosleep_yield.c:41
          -> __wasm_main_thread_yield_ms                    :32  EM_ASYNC_JS
             = AN ASYNCIFY PARK OF THE STACK IT STANDS ON, in a loop, inside a tool body

This is doc 21's K7 row, and its caller set is not "anything that sleeps" — for the canvas tools it is exactly this one loop. The evidence closing the case is that RunSynchronousAction's callers are precisely the tools whose specs died at D-on: pcbnew/tools/edit_tool_move_fct.cpp (move-with-m, presence-locks move), eeschema/tools/sch_drawing_tools.cpp (draw wires), the drawing/edit tools behind draw-lines. The spec comments already described the symptom from the outside — "KiCad's GAL updates the active tool's world-space cursor from the asyncified pointer-move handler" — without naming the park; this is that park.

Why it is fatal under D-on specifically: the loop parks the stack it stands on and then wxYield()s, so a nested dispatch runs tool work ON TOP of a stack that is mid-park. Pre-D that stack was the entry stack and the fiber layer never tried to move it; with dispatch on a context, a star transfer targets a context whose capture is mid-flight — doRewind → index out of bounds.

The fix shape (next increment): the wait must yield the owning context. Replace the spin with a context park — synchronousControl transitioning out of STS_RUNNING marks the parked context ready — so the frame waits by yielding rather than by sleeping-in-place. Notes for whoever takes it:

• This is a tool_manager.cpp change, i.e. the first Phase B edit to KiCad proper, so §5's divergence question comes due (accept it, or hide the park behind a wx-side helper the wasm port supplies and KiCad calls unconditionally — the latter keeps the fork close to upstream and is likely possible, since the loop only needs "wait until this atomic changes").
• wxYield() inside the loop must keep working: under the star it becomes "let the scheduler run other contexts", which is what a context park already does — so the yield call can likely go away with the sleep rather than be ported.
• Gate on the KiCad suite (the four canvas-tool specs are the red-to-green pins), never the harness battery — the harness has no RunSynchronousAction and will stay green either way. That is this session's most transferable lesson.

The sleep moved to a context — and the REAL blocker surfaced (2026-08-07)

Built and measured. wasm/shims/context_sleep.cpp: a main-thread nanosleep whose frame stands on a scheduler context that OWNS the stack arms a mailbox wake and yield_parks that context instead of suspending the stack in place; anything else falls back to the Asyncify yield. It lives in the sleep primitive rather than in tool_manager.cpp deliberately — KiCad and the wx core stay untouched (CLAUDE.md's fork rule), and the whole K7 class moves at once instead of the one measured caller.

One correction paid for on the way, worth keeping in mind for every future park site: a context may have only ONE wake owner. The first cut parked whatever context was current, including the MAIN-LOOP context — whose wake already belongs to the rAF pump. The frame wake then resumed a capture the sleep wake had consumed: doRewind trap arriving through wxWasmArmFrameWake, and the eeschema simulator spec went red at D-off. wxWasmContextWakeIsPumpOwned() now excludes the main-loop and dispatch contexts (their parks are the pumps' contract); tool coroutines, which have no other wake source, are exactly the ones that park. D-off re-verified at 139/1 with the shim in — it is correct-or-inert exactly as required.

At D-on the four canvas-tool specs still fail, and the trace names a DIFFERENT cause — the one that actually blocks Phase D. The fatal swap is fcs old=<libcontext ROOT> new=<tool coroutine> rf=dynCall_iiii, and the JS stack above it is mouseEventHandlerFunc → registerMouseEventCallback: a DOM mouse handler entering wasm DIRECTLY on the main stack, not through the tick.

So the same tool coroutine is entered by two different mechanisms:

entry	path	how the coroutine is resumed
the tick (wxWasmTopLevelTick)	dispatch context → fiber_transfer	STAR: parked by the scheduler, capture owned by the scheduler swap
a DOM mouse/key handler	main stack, current() == 0 → direct-swap fallback	SYMMETRIC: entered by emscripten_fiber_swap from the root

A coroutine suspended by a star transfer and later resumed by a direct symmetric swap rewinds through an entry path its capture was not written for — index out of bounds in doRewind. This is doc 22 §7 rule 5 (partial migration is worse than none) in its purest measured form, and it explains why the harness stays green: its coroutines are only ever entered from one place.

Therefore the next Phase B/D increment is not another park site — it is the DOM event entries. Every registerMouseEventCallback / key / wheel / resize handler that today runs wx dispatch inline on the main stack must instead hand its event to the dispatch context (enqueue + pump), exactly as the tick already does. Only when EVERY entry into a tool coroutine goes through the scheduler does the mixed-mode rewind class disappear. Note this also subsumes the "one root" work: with no dispatch on the main stack, resolve_root_identity() always answers "the running context".

Landing state: wxWASM_STAR_DISPATCH back to 0, context-sleep and its pump-ownership guard kept (inert at D-off, verified 139/1).

DOM entries on the dispatch context — THE CANVAS TOOLS GO GREEN (2026-08-07)

The increment the section above ordered, built and measured: every entry that can reach a tool coroutine now goes through the scheduler.

• wxWasmRunOnDispatchContext(fn, arg) (evtloop.cpp) hands work to a dispatch context and pumps. It is SYNCHRONOUS in the common case — drain_all returns once the context parks at idle, i.e. after the job completed — so callers that need an answer still get one. It falls back to running inline when already on a dispatch context (same-stack recursion, as wxYield does) or when the registry says another context is running, which is the in-place-parked-bridge window Phase E closes.
• All four DOM callbacks (MouseCallback, WheelCallback, TouchCallback, KeyCallback) and the mailbox tick now route through it. Jobs are heap-owned with ownership going to whoever finishes last, because a job may park for a dialog's lifetime: the job deletes itself if the caller has given up, else the caller deletes it and reads its result. Keys keep their synchronous preventDefault (the job writes it before it can park; a job that parks anyway leaves the default — the browser cannot wait for a modal).
• The context-sleep wake had to learn the same lesson in reverse: now that the mailbox runs ON a context, wake_sleeper must not call drain_all from there (drain refuses re-entry, correctly). It marks ready and lets the outer drain_all — still pumping on the scheduler stack — perform the entry, with an armed pump as a backstop.

Result at D-on: KiCad 136 passed / 3, and all four canvas-tool specs are GREEN (eeschema draw-wires, pcbnew draw-lines, pcbnew move-with-m, presence-locks move). The mixed-mode rewind class — a coroutine entered by a star transfer from the tick and by a direct symmetric swap from a DOM handler — is gone, which was Phase D's blocker.

The 3 remaining, and 2 of them are pins measuring a world D5 deleted. Besides the pre-existing occ-probe, timer-park-repro and quasimodal-strand's staging test fail on ONE assertion: "scheduler shim observed the concurrent-park window", expected > 0, got 0. Everything else in those specs passes — fired=true done=true parked=true errors=0, i.e. the parking timer handler parks, rewinds and survives.

That counter fires when handleSleep is entered while currData is non-null: two concurrent in-place Asyncify parks. The lever stages "timer park × MAIN-LOOP YIELD PARK" (its own header says so), and D5 removed the main loop's Asyncify park — so the overlap cannot occur any more. The spec's comment even anticipates the shape of this: "that assert fails only if the lever itself never created the overlap (a broken repro, not a passing one)" — here the repro is not broken, its ingredient was deliberately eliminated.

Do NOT paper over this by relaxing the assert. It is a Phase F decision, alongside fiber-resume-park.spec.ts's red→green flip: each lever gets re-pinned to the post-migration invariant (the runtime survives AND no concurrent-park window is observable) with the evidence recorded, or a replacement lever is built that stages a still-possible overlap. Until then the honest statement is: at D-on those two specs cannot stage their scenario, and the runtime behaviour they guard is green.

Landing state: wxWASM_STAR_DISPATCH back to 0 (all of the above is inert there), everything kept. Next: Phase E — the K1–K7 bridges are now the only in-place parks left under a context, and they are what the current() != 0 fallback above still tolerates.

Phase E, first attempt: K1 as a context wait — REVERTED, and what it cost

The bridge pattern doc 22 §5 calls for, tried on K1 (sch_io_pcbjam_lib.cpp, the symbol-library request — chosen first because doc 21 makes it the doc-19 exposure: a chooser's lazy load parks the TOOL COROUTINE that owns the chooser):

  before:  char* r = pcbjam_libs_request_js(op, lib, arg, kind);   // EM_ASYNC_JS, parks in place
  after:   int t = wxWasmBeginWait("lib");
           pcbjam_libs_request_start(t, op, lib, arg, kind);       // EM_JS, resolves the wait
           wxWasmYieldUntil(t);                                    // context park, or in-place fallback
           char* r = pcbjam_libs_take_result(t);

Result: the KiCad suite went from 7 minutes to 1.2 HOURS — 111 passed, the rest timing out, and the app going SILENT right after a library request. A parked context that nobody resumes. Reverted; the tree keeps the working EM_ASYNC_JS.

A PRECONDITION the attempt discovered — re-add it WITH the next conversion, it is not in the tree. wxWasmYieldUntil must not park a context whose wait is already resolved: resolveWait DELETES the entry, so a bridge whose promise settles before the caller reaches the park leaves that context waiting for a wake nobody sends. The in-place form had no such window (the same expression created and awaited the promise); every bridge converted to this pattern re-opens it. The guard is four lines —

EM_JS(int, wxWasmWaitPendingJs, (int token), {          // resolveWait deletes the entry
    return globalThis.__wxScheduler.waits.has(token) ? 1 : 0;
});
...
    if (self && pcbjam_sched::can_yield_here())
    {
        if (!wxWasmWaitPendingJs(token))    // already resolved: do NOT park
            return 0;

— and it was NOT the hang (the hang reproduced with it in place). It is deliberately NOT landed: it sits in the wait path of every modal and nested loop, and the only build that ever contained it was the broken one, so it has never been measured at D-off. It belongs in the same commit as the bridge conversion it protects, gated together.

Where the next attempt should start — hypotheses, in the order the evidence supports them. Not yet distinguished; do this with a focused repro (open a schematic with the chooser, one lib request), not the full suite:

1. The resolve never reaches the registry. resolveWait routes a context-parked token to Module["_wxWasmSchedResolveContextWait"] + _armSchedPump; if either export is missing from the KiCad link (they are EMSCRIPTEN_KEEPALIVE in wx, but this is the first KiCad-side caller of the wait registry) the mark-ready silently never happens. Check Module["_wxWasmSchedResolveContextWait"] in the console first — it is one line and would explain the symptom exactly.
2. The lib path runs where can_yield_here() is true but the resumer cannot reach it — e.g. inside the chooser's modal, where the dispatch context is already parked at a "nested" wait and the lib wait parks it a second time (a context can hold only ONE park; the second yield would strand the first).
3. Asyncify instrumentation closure. Removing the EM_ASYNC_JS from this translation unit changes which functions binaryen instruments; the KiCad lib path now reaches an unwind only through wxWasmYieldUntilJs. If the closure no longer covers a frame in that path, the fallback park corrupts instead of suspending.

Process note for the next attempt: gate a bridge conversion on a SINGLE spec first (eeschema.spec.ts or a chooser spec), not npm run test:kicad — this attempt cost a 1.2-hour suite run to learn one bit. The full suite is the confirmation, not the probe.

Phase E retry: K1 LANDED — the strand was a certainty, not a race (2026-08-08)

Gate: full KiCad suite 139 passed / 1 failed (pre-existing occ-probe glb) / 30 skipped in 7.2 min — the Phase A baseline exactly, with the K1 conversion IN. The casualty class went first: eeschema-ui 3/3 in 17.7 s (attempt 1 hung it at boot for 3 min per test), then strand + sim + modal-stack 6/6. Zero [wx-wait] beacons fired.

The diagnosis, from evidence attempt 1 left behind rather than a rebuild. The broken run's playwright report survived (tests/playwright-report, 111 expected / 26 unexpected) and all 26 failures are the same shape: #canvas never appeared — BOOT hangs, not chooser hangs. A live probe of the bare test page then supplied the missing fact: test pages install no kicadLibs provider at all. So on every spec page the converted bridge resolved its wait synchronously (no-hook → resolveWait(token, 0) inside the same wasm turn), resolveWait DELETED the entry, and the C++ then parked a context whose wake had already been spent. Not a race — a certainty on every provider-less page, which is why 26 specs died broadly instead of one chooser flow. (Hypothesis 1 was falsified first: both exports are real export assignments in the surviving glue, and they come from the wx side of the link, identical in both builds.)

The §"first attempt" guard is LOSSY and was NOT landed — this landed instead. The 4-line waits.has guard returns 0 for an already-resolved wait, dropping the result (a malloc'd payload pointer for lib requests, a return code for modals). The result-preserving shape, all three pieces required together:

1. Retention (shim): resolveWait keeps a resolved-but-unawaited non-context entry in the map with result attached (counter earlyWaitResolves), instead of deleting it. Context-parked and promise-awaited resolves behave exactly as before.
2. Peek-and-consume (wx): wxWasmYieldUntil checks waitEarlyResolved(token) before parking a context and returns takeWaitResult(token) instead of parking; waitPromise consumes a retained entry too — which also fixes a PRE-EXISTING data loss (a synchronous C++ resolve before wxWasmYieldUntilJs used to return 0 with an "unknown token" warning).
3. Deferred resolution (bridge contract): a converted bridge must never call resolveWait synchronously from its start function — every path defers to at least a microtask. pcbjam_libs_request_start wraps the provider in Promise.resolve(...) so even a synchronous provider resolves on a microtask.

Beacons on the two previously-silent links stay in: a resolve for an unregistered context-wait token, and a refused mark_ready, both warn with the token identity.

Why attempt 1 "reproduced with the guard in place" could not be reproduced: not resolvable from surviving evidence; the equivalent-but-stronger mechanism gates green today. The stale-sync trap (a retest against unsynced binaries) remains the likeliest explanation. The retention design is landed regardless — it is strictly stronger.

Honest coverage note: the bare-page probe shows waitsBegun == 0 at boot — K1's main-thread path is THIN on test pages (the chooser path proxies from pthread workers, untouched). The park-then-resolve half of the mechanism is exercised by every modal at D-off (same wxWasmYieldUntil path); the async-provider half needs the standalone/web smoke before Phase E is called done. For K2–K7: the retention and peek live in shared code — only the defer-the-resolve contract must be repeated per bridge.

A latent break the battery rerun un-hid (NOT this retry's doing): coroutine-pthread-ondemand aborted at missing function: _Z23pcbjam_context_sleep_msd on both engines. The 8/7 context-sleep commit added a bare extern int pcbjam_context_sleep_ms(double) to wasm/shims/nanosleep_yield.c; the test-app Makefile compiles that file with $(CXX) and its comment ("em++ keys language off the .c extension") is wrong — em++ compiles it as C++, so the declaration MANGLES, and the standalone apps do not link context_sleep.cpp at all. Broken since 8/7; unnoticed because the wx battery was never rerun after that commit (the KiCad gate was). Fix in nanosleep_yield.c: the declaration is now extern "C"-guarded AND __attribute__((weak)) with a null check — an app without the scheduler shim falls back to the in-place Asyncify yield, which is exactly the behaviour those apps pin. Lesson for the phase log: a wx-shim commit gated only on the KiCad suite can silently break the standalone battery — run both nets when wasm/shims/ changes.

Battery after the fix: 388 passed / 8 failed / 3 skipped — the failure set is EXACTLY the documented pre-existing D-off landing set (nested case-3 ×3 tests ×2 engines, wakeup_during_transition layout-sensitive, modal.spec.ts:125), with pthread-ondemand green on both engines. The shim's resolveWait retention change is regression-free against every modal/nested/popup wait the battery stages.

1. pthreads. Doc 21 §2 settled that every Asyncify park is main-thread and the lib bridge's worker path is a blocking proxy. Phase A must re-check that libcontext is never driven from a worker before assuming the scheduler is main-thread-only.
2. Buffer sizing. Still unmeasured for real park sites (§5 Phase E). libcontext's 512 K is inherited, D1's 128 K is a guess with a synthetic floor behind it.
3. D5 (main loop as a context) stays optional. The 68/1 class is currently held closed by v0.1.28's scheduling trick; decide with Phase E's telemetry in hand, not before.
4. Does Phase B change upstream-divergence policy? It touches coroutine.h and tool_manager.cpp structurally. Worth deciding up front whether that divergence is acceptable or whether the adapter should stay entirely inside libcontext.