host: doc — complete boost diagnosis (nil .sxbc bytecode + manifest-mapped lib resolution)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

plans/host-spa.md

@@ -55,15 +55,33 @@ bignum mul/div_small). Verified: NIST/CID vectors match native↔js↔wasm; nati
 conformance 271/271; **the freshly-built browser kernel now BOOTS** (SxKernel
 live, data-sx-ready=true, crypto-sha256 correct on js + wasm).
 
-REMAINING for boost (separate layer — web-stack loading, NOT crypto):
-- `.sxbc` still fail `VM: unknown opcode 0` against the SX-level `vm.sx`
-  interpreter, even freshly recompiled — a bytecode-format mismatch (likely the
-  sx-vm-extensions merge changed sx_vm.ml's opcodes but the served `vm.sx` wasn't
-  regenerated). So the web stack falls back to `.sx` source.
-- `boot.sx` SOURCE then fails `Expected list, got string` (fails on the old
-  main-worktree kernel too), so `process-boosted` never runs → boost 0/N.
-  Next: either regenerate `vm.sx` to match the compiler so `.sxbc` load, or fix
-  the `boot.sx` source-eval failure so source fallback completes.
+REMAINING for boost (separate layer — web-stack loading, NOT crypto). Two
+compounding roots, both fully diagnosed:
+
+1. **`.sxbc` carry NIL bytecode.** `compile-modules.js` (via the native binary)
+   emits `:bytecode (nil nil nil …)` placeholders, not real bytecode — so the
+   SX-level `vm.sx` interpreter reads nil → `VM: unknown opcode 0`, and the web
+   stack falls back to `.sx` source for every module. (Confirmed by inspecting a
+   freshly-compiled `dom.sxbc`.) The native compiler isn't producing bytecode in
+   this path.
+
+2. **Source-fallback can't resolve manifest-mapped libraries.** With imports
+   stripped, all 23 `boot.sx` body forms load clean — the `Expected list, got
+   string` is from an `import`. `boot.sx` imports `(sx signals-web)`, but that
+   library is *defined inside `signals.sx`* (the file→library names don't match;
+   the module-manifest maps `"sx signals-web" → signals.sxbc`). The `.sx`
+   source-fallback resolver maps a library to a like-named FILE, looks for a
+   non-existent `signals-web.sx`, and the failed resolution returns a string into
+   a list op → the error → `boot.sx` never loads → `process-boosted` never runs →
+   boost 0/N. (A `signals-web.sx` bridge that imports signals was NOT sufficient
+   — there is at least one more such mismatch among the imports.)
+
+THE CLEAN FIX is a proper bundle rebuild via `scripts/sx-build-all.sh` so the
+`.sxbc` carry real bytecode and the manifest-driven path loads everything (no
+source fallback, so root #2 never triggers) — gated on fixing root #1 (why
+`compile-modules.js` emits nil bytecode). Alternatively, make the source-fallback
+resolver manifest-aware. Neither is a quick edit; it's a web-stack build-tooling
+sub-project. The kernel itself is now correct and boots.
 
 ## Rebuild attempt (2026-06-28) — FAILED, reverted (superseded by the fix above)