# spikes/wasm-phase5 — parity, audit, and performance harness

Phase 5's production exit requires the full network suite to pass on the WASM
worker and performance numbers to be published. The production worker is not in
this branch yet, so this spike builds the Phase 5 harness and records the native
baseline that the WASM worker must match.

Run on `k-uce`:

```bash
bash spikes/wasm-phase5/run_phase5.sh
```

Expected final line:

```text
PHASE5 HARNESS: PASS
```

Artifacts are written under `/tmp/uce/wasm-phase5/`:

- `native-network.json` — full native network suite result.
- `native-starter.json` — starter-focused parity subset; this protects against
  a vacuous `--match starter` exit gate.
- `site-static-audit.{json,md}` — candidate cross-request/static-state risks in
  `site/` for the §3.2 semantic change audit.
- `benchmark.{json,md}` — warmed native baseline for the three Phase 5 budget
  pages:
  - `template-heavy-doc`: `/doc/singlepage.uce`
  - `sqlite-page`: `/demo/sqlite.uce`
  - `component-heavy-starter`: `/examples/uce-starter/?dashboard`

`benchmark.py` also accepts `--wasm-base-url` once a WASM worker endpoint exists.
When provided, it compares WASM medians against the Phase 5 budget of ≤2× native
page latency. Workspace birth and internal component call overhead budgets still
need worker-internal probes; this harness documents the gap rather than faking
those numbers.

Current scope:

- Native parity and baseline collection are automated.
- WASM parity/performance comparison is ready but blocked on the production WASM
  worker endpoint.
- The static-state audit is heuristic and intentionally conservative; findings
  must be reviewed by a human before migration work is scheduled.