# Browser feasibility report

## Result

The remaining Phase 0 browser gates pass. A Worker running in headless Chrome can:

1. Dynamically compile and instantiate a Memory64 module generated with `wasm-encoder`.
2. Instantiate a raw `wasm32-unknown-unknown` artifact using Icicle's pinned P-code model and execute the normalized semantics corresponding to AArch64 `mov x0, #42; add x0, x0, #1`, producing `43`.
3. Call a Promise-bearing JavaScript import from Wasm, suspend the Wasm stack through JSPI, resume on a later event-loop turn, add one in Wasm, and resolve the promising export with `42`.

The automated run on July 24, 2026 used Playwright's Chrome `149.0.7827.55`. The test requires Chrome 137 or newer because JSPI shipped in Chrome 137. The implementation follows the WebAssembly proposal's current `WebAssembly.Suspending` and `WebAssembly.promising` API.

Primary references:

- [Chrome 137 release notes](https://developer.chrome.com/release-notes/137#javascript_promise_integration)
- [WebAssembly JavaScript Promise Integration proposal](https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md)

## Artifacts and boundaries

- `crates/wasm-probe` generates the Memory64 and JSPI core Wasm fixtures.
- `experiments/icicle-wasm` is a standalone Cargo workspace that pins Icicle revision `6f53b6016e63ddcff80a105b8e5ad37caf7a6ed3` and emits the P-code semantic fixture.
- `web/scripts/generate-probes.mjs` builds and copies generated artifacts into `web/public`; generated `.wasm` files are ignored by Git.
- `web/src/probe.worker.ts` performs all compilation, instantiation, semantic, and suspension checks away from the main thread.

The browser fixture intentionally depends only on Icicle's `pcode` package. Deeper SLEIGH and CPU crates still need the two narrow portability changes recorded in the Icicle dependency report, while `icicle-vm` remains excluded because it unconditionally reaches the native Cranelift JIT.

## Reproduction

```sh
pnpm --dir web install --frozen-lockfile
pnpm --dir web run check
pnpm --dir web run build
pnpm --dir web test
```

The build and test hooks regenerate all three `.wasm` files. The Playwright test asserts that Memory64, AArch64 P-code semantics, and JSPI are supported; capability-only results for tail calls, SIMD, relaxed SIMD, multiple memories, typed function references, and finalized exception handling remain visible in the report but do not gate Phase 0.

## Failure diagnostics

Each probe is isolated and returns an independent result. Fetch, compilation, instantiation, missing-export, and JSPI exceptions are caught and attached to the corresponding feature result rather than crashing the Worker. The page exposes the diagnostic as the result element's `title`, and a top-level Worker failure changes the status element to an explicit error state.

The JSPI check also rejects false positives where the API names exist but:

- the wrapped export does not return a Promise;
- the host Promise resolves synchronously instead of suspending Wasm; or
- the resumed value does not flow back through Wasm and produce `42`.

## Phase 0 conclusion

All Phase 0 acceptance gates now have executable evidence:

- reusable Icicle components and rejected boundaries are documented;
- a browser artifact executes an AArch64-derived semantic operation;
- generated Wasm compiles and runs in Chrome;
- dependency licensing has been reviewed; and
- ADR-0001 records both the selected foundation and fallback boundary.

The next milestone is Phase 1's ELF inspection CLI and static process-image loader.