Three fixes:
1. Framework: render-dom-lake preserves SSR elements during hydration.
When client-side render-to-dom encounters a lake with an existing
DOM element (from SSR), it reuses that element instead of creating
a new one. This prevents the SSR HTML from being replaced with
unresolvable raw SX expressions (~tw calls).
2. Stepper: skip rebuild-preview on initial hydration. Uses a non-
reactive dict flag (not a signal) to avoid triggering the effect
twice. On first run, just initializes the DOM stack from the
existing SSR content by computing open-element depth from step
types and walking lastElementChild.
3. Stepper: rebuild-preview computes correct DOM stack after re-render.
Same depth computation + DOM walk approach. This fixes the bug where
do-step after do-back would append elements to the wrong parent
(e.g. "sx" span outside h1).
Also: increased code view font-size from 0.5rem to 0.85rem.
Playwright tests:
- lake never shows raw SX during hydration (mutation observer)
- back 6 + forward 6 keeps all 4 spans inside h1
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The stepper's split-tag and steps-to-preview used (list) with append!,
but in the WASM kernel (list) creates immutable List values — append!
returns a new list without mutating, so children accumulate nowhere.
Changed all accumulator initializations to (mutable-list):
- split-tag: cch, cat, spreads
- steps-to-preview: bc-loop inner children, initial call
- result and tokens lists in the parsing setup
Also includes WASM rebuild with append! primitive and &rest fixes.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Replace Node.js compile-modules.js with direct Sx_compiler.compile_module
calls in mcp_tree.ml. No subprocess, no JIT warm-up, no Node.js.
23 files compile in 1.9 seconds.
Also includes rebuilt WASM kernel (iterative cek_run) and all 23
bytecode modules recompiled with native compiler.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Bytecode modules are now serialized as s-expressions (.sxbc) in addition
to JSON (.sxbc.json). The .sxbc format is the canonical representation —
content-addressable, parseable by the SX parser, and suitable for CID
referencing. Annotation layers (source maps, variable names, tests, docs)
can reference the bytecode CID without polluting the bytecode itself.
Format: (sxbc version hash (code :arity N :bytecode (...) :constants (...)))
The browser loader tries .sxbc first (via load-sxbc kernel primitive),
falls back to .sxbc.json. Caddy needs .sxbc MIME type to serve the new
format (currently 404s, JSON fallback works).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
