Survey S1's premise before entering it: a JVM can reach a component

0007 is what happens when a stage is entered on an unchecked premise, so
entering S1 starts with checking the one 0005 assumes -- a JVM reaching
Wasm through FFM and wasmtime.

It holds, and the margin is narrower than it looked. Search said the
wasmtime C API had no component model support and pointed at an open
issue; the issue is closed, and the shared library the flake pins tells
the real story:

    wasmtime 40.0.2   0 exported wasmtime_component_* symbols
    wasmtime 43.0.1   138
    wasmtime 45.0.0   154
    wasmtime 47.0.1   154

Counted from the dylibs in the nix store rather than read from release
notes -- the survey skill's own warning is that negative claims rot
fastest, and this was one.

tools.json already requires >=43.0.0, set months ago for WASI 0.3. That
is also the first version with a component C API. The coincidence is
load-bearing and 0005 now says not to lower it.

From the JVM, java.lang.foreign resolves wasmtime_component_new,
_linker_new, _linker_instantiate, _instance_get_func and _func_call out
of that library on Java 25. So the path exists end to end. What it does
not show is a value crossing it, which is S1's first unit rather than a
survey probe -- recorded as such.

Two things the survey surfaced that S1 has to answer rather than assume:

- Locating libwasmtime needed an absolute nix store path, and CLAUDE.md
  forbids machine-specific paths in committed files. How cljwit.host
  finds the library is an open design question, not a detail.
- Endive -- a Bytecode Alliance-hosted fork of Chicory adding a Cranelift
  backend -- targets full Component Model support on the JVM with *no
  native dependency*. It does not have it yet (Cranelift and WasmGC
  first) and Chicory itself has no component model at all. So the native
  path is the only one today and a pure-JVM one is plausibly coming,
  which matters for cljwit.host's deployment story. Re-check at S1's
  design.

wasmtime is now in refs.json (large, opt-in) since its C API is what S1
binds to.

Claude-Session: https://claude.ai/code/session_01XF5Hfq4Ca2N2XYEzWQQuHt

Author: chaploud

doc/design/0005-implementation-language.md

@@ -52,6 +52,51 @@ expand Clojure source. Any other host reimplements macroexpansion.
   requires the compiler to exist before the compiler exists. Revisit once S3
   can compile the analyzer.
 
+## The S1 host path, surveyed 2026-07-30
+
+This note assumes a JVM reaching Wasm through FFM and wasmtime. Entering S1
+means checking that, because `0007` is what happens when a stage is entered on
+an unchecked premise.
+
+**It holds, and the margin is narrower than it looks.** wasmtime's C API gained
+the component model between v40 and v43 — measured by counting exported symbols
+in the shared library the flake pins, not by reading release notes:
+
+| wasmtime | `wasmtime_component_*` exported |
+|---|---|
+| 40.0.2 | **0** |
+| 43.0.1 | 138 |
+| 45.0.0 | 154 |
+| 47.0.1 | 154 |
+
+`tools.json` already requires ≥ 43.0.0, set for WASI 0.3 — the same version
+that first ships the component C API. That coincidence is load-bearing and
+should not be lowered.
+
+From the JVM, `java.lang.foreign.SymbolLookup` on Java 25 resolves
+`wasmtime_component_new`, `_linker_new`, `_linker_instantiate`,
+`_instance_get_func` and `_func_call` out of that library. So the path exists
+end to end; what it does *not* yet show is a value crossing it, which is S1's
+first unit rather than a survey probe.
+
+**One constraint surfaced that S1 has to answer:** finding
+`libwasmtime.dylib` needed an absolute store path, and `.claude/CLAUDE.md`
+forbids machine-specific paths in anything committed. How `cljwit.host` locates
+the library — bundled, `pkg-config`, an env var, a documented convention — is
+an open S1 design question, not a detail.
+
+**The alternative worth watching: [Endive].** A Bytecode Alliance–hosted fork of
+[Chicory] (a pure-Java Wasm runtime) that adds a Cranelift backend and targets
+full Component Model support on the JVM **with no native dependency**. It does
+not have the component model yet — Cranelift and WasmGC come first — and
+Chicory itself lists GC on its 2026 roadmap with no component model at all. So
+today the native path is the only one, and a pure-JVM path is plausibly coming.
+That matters for `cljwit.host`'s deployment story and should be re-checked at
+S1's design, not assumed either way.
+
+[Endive]: https://bytecodealliance.org/articles/endive-and-the-next-chapter-of-webassembly-on-the-jvm
+[Chicory]: https://github.com/dylibso/chicory
+
 ## Consequences
 
 - Development requires a JVM; deployment does not. This must be stated plainly

doc/status.md

@@ -3,17 +3,27 @@
 _Short by design, and printed at every session start — so findings live in
 `doc/design/`, plans in `doc/roadmap.md`, and only the present tense here._
 
-**Updated:** 2026-07-29 · **Phase:** feasibility (pre-alpha, no compiler)
+**Updated:** 2026-07-30 · **Phase:** S0 closed, entering S1 (pre-alpha, no compiler)
 
 ## Next
 
+**S1's premise is checked** (`0005`, surveyed 2026-07-30): wasmtime's C API
+gained the component model between v40 and v43 — 0 exported
+`wasmtime_component_*` symbols at 40.0.2, 154 at the pinned 47.0.1 — and the
+JVM resolves them through `java.lang.foreign` on Java 25. `tools.json`'s ≥43
+minimum, set for WASI 0.3, is also the component minimum; do not lower it.
+
 1. **Record a B6 prediction in `doc/design/0002-*` before writing any of it.**
    B6 has no row in that table yet, and the table is the discipline.
 2. **B6 — the component boundary crossing.** A GC-to-linear-memory copy per
    aggregate argument (`doc/design/0007-*`), which is what "a Rust developer
    calls a Clojure component" actually costs, and which no S0 benchmark
    touches. `doc/roadmap.md` places it at the head of S1.
-3. **Firm up V8's crossover**, the one soft figure left. wasmtime's is now
+3. **Get a value across the boundary from the JVM.** Symbol resolution proves
+   reachability, not a working call. This is S1's first real unit, and it will
+   force the open question `0005` now records: how `cljwit.host` locates
+   `libwasmtime` without a machine-specific path.
+4. **Firm up V8's crossover**, the one soft figure left. wasmtime's is now
    nine measured points at 26.6%; V8's interpolates onto a −0.01 ns endpoint
    inside its own spread, so the data bounds it only to 70–90%. Points at
    k = 7, 8, 10 would settle it.

refs.json

@@ -14,6 +14,7 @@
     "zwasm":          { "url": "https://github.com/clojurewasm/zwasm",            "why": "sibling; a Wasm engine written from scratch, including its JIT notes" },
     "clj.wasm":       { "url": "https://github.com/kanaka/clj.wasm",              "why": "earlier exploration of this exact question" },
 
+    "wasmtime":        { "url": "https://github.com/bytecodealliance/wasmtime",     "large": true, "why": "the C API cljwit.host binds to (crates/c-api), and the reference Component Model implementation" },
     "component-model": { "url": "https://github.com/WebAssembly/component-model", "why": "the Canonical ABI we must emit by hand (S4); issue #525 is GC-in-ABI, still a pre-proposal" },
     "wit-bindgen":     { "url": "https://github.com/bytecodealliance/wit-bindgen", "why": "how every other language binds WIT — no Clojure backend, so this is the shape to match, not to use" },
     "dart-sdk":        { "url": "https://github.com/dart-lang/sdk",                "large": true, "why": "dart2wasm: the closest prior art for lowering a GC'd object model onto WasmGC (pkg/dart2wasm)" },