wai-web: reach builds — L1, L2, J and an ES5 loader (CI verdict pending) #205

Merged

dcharlot merged 10 commits from wai/reach-builds into main 2026-10-10 23:00:19 -04:00

Conversation 0 Commits 10 Files changed 26 +15747 -13

dcharlot commented 2026-10-09 18:47:13 -04:00

Owner

Copy link

The shipped wai-web package needs WebAssembly with sign-extension, non-trapping float-to-int and bulk memory, a 64-bit integer that crosses the JS boundary as BigInt, and ES modules. This PR adds three builds derived from that package, and an ES5 loader that picks between them, in wai/wai-web/reach/. The Rust does not change.

CI verdict: pending. The forge run of wai-web-reach.yml for the head 3a8a2161 is run #2640 (id 3740), queued behind the linux runner's backlog. Until it, or a later run, finishes green, nothing here is CI-verified; the executed equivalent below is a local run of the same workflow, not a forge verdict. This description will name the green run.

What is built

rung	build	for engines with
shipped	the package itself	every feature above
L1	the shipped binary, legalised at the JS interface (wasm-opt --legalize-js-interface, binaryen version_123)	the same WebAssembly, but no BigInt at the boundary
L2	MVP-lowered (--signext-lowering --llvm-nontrapping-fptoint-lowering --llvm-memory-copy-fill-lowering), then legalised	MVP WebAssembly
J	the MVP module translated by wasm2js, one ES5 script per profile	ES5 and typed arrays, no WebAssembly

L2 and J come in profiles: full, verify_decode, verify and receipt. profiles.json lists the exports each keeps, and wasm-metadce drops the rest.

The J and L1/L2 scripts share an ES5 runtime (the builtins an old engine lacks, and i64 joined and split at the boundary: a BigInt where the engine has one, a Number exact below 2^53 where it does not) and the shipped glue compiled to ES5 with a fixed, counted set of changes (manifest.json records the counts).

wai-load.js chooses a rung from feature probes alone, never the user agent: WebAssembly.validate on probe modules, one instantiated module that returns its i64 argument, and checks for typed arrays and BigInt. An early WebAssembly engine line (WebAssembly and the stack-trace capture API, but no RegExp dotAll flag: the feature noDotAll) gets J, or the L2 receipt build, because the full MVP module has crashed an engine of that line on arm64. A rung can be forced, and detection never throws.

The package of record, and CI

reach/record/ keeps the package the site serves under /wai/pkg/: wai_web_bg.wasm c2b63f74…050e and wai_web.js f63605f0…6f6a, built from wai/wai-web at 248846f1 (manifest.json input.commit; input.source says how). wai-web-reach.yml runs a leg per package on the linux runner:

• record: both files must have the manifest's SHA-256; build.sh runs with WAI_REACH_REQUIRE_RECORD=1, which refuses any other package, so all 11 outputs must have the manifest's SHA-256 and size: the bytes the site serves under /wai/pkg/reach/. Then run-modern.mjs and the engine images run on those outputs.
• tree: wai-web built from this tree, so a change to wai-web meets the reach builds before the package of record moves to it.

The package is kept, not rebuilt in CI: built in the linux runner's image from the same commit, with the export at the same physical path and every remap, its glue is the same and its wasm is not (the code section differs; measured twice).

J's wasm2js is binaryen's WebAssembly build of the same release (npm binaryen 123.0.0, pinned with its integrity hash in package-lock.json), run on Node. The x86_64 Linux archive's native wasm2js allocates the translation's locals differently from the macOS archive's; the WebAssembly build gives the macOS archive's output on every host, for every profile, so no recorded output changed.

Artifacts

From reach/manifest.json. Brotli is quality 11.

file	rung	profile	SHA-256	bytes	brotli
wai-load.js	all	—	c3dc79392e6bf75d6cc190cd38eabab94f449d0d3687585cae6c3e03fe6775a2	16,621	4,474
wai_web.j.full.js	J	full	1af5b5917ecb3097e8eb3c79342dd087bd3febeef58bd2222b623e0099b17848	5,969,835	1,053,831
wai_web.j.receipt.js	J	receipt	b6c52b020c3daef6f0dc5a7ccbbd8e7134a951012987ceaaf66fdfaad9e2d77b	996,473	251,134
wai_web.j.verify.js	J	verify	4862fb576c72bb12bffe4799684450c81a3181a34db134118a44e12b9204ab76	3,086,139	606,845
wai_web.j.verify_decode.js	J	verify_decode	d2bb946fbab8dbcc5fb7ca101b6c4615881d3f1f1de47813a0b3c9e080f1b1bf	3,310,622	642,273
wai_web.reach.js	L1, L2	full	747db637684c8ffed24aab175a3dc1a399901c1d9699dd99c86a090b4b78bf0c	198,994	18,502
wai_web_bg.l1.wasm	L1	full	25e728714bcc67ccb133042012860a53c881ea6c26c3dc7538bf378c0598b3b8	2,591,481	683,525
wai_web_bg.l2.full.wasm	L2	full	5af77d42fbd2e2e6023789aca42dcb62c6bcf1ccb29e7303b31de5e6251fa88e	2,591,161	684,042
wai_web_bg.l2.receipt.wasm	L2	receipt	89ad094a90fbc31aa3399d0e4db41728c742c110a90480952f3c2527310fb821	393,027	163,989
wai_web_bg.l2.verify.wasm	L2	verify	cbf4d3705f566b76ea1aab6d4513a51632df0373338e0e206cceff9d4b7c6a00	1,222,037	407,801
wai_web_bg.l2.verify_decode.wasm	L2	verify_decode	efe0033b1cfc151054baf6282bd6cd9b2a264cf5df8321586cdbcf1f62928b87	1,316,304	433,878

No output holds a host path or a toolchain folder: the package of record was rebuilt with the standard library's sources remapped to /rustc/<the compiler's commit> (the earlier package carried the build host's toolchain folder in its panic locations, and every reach binary and J bundle with it). The J bundles' base64 data segments were decoded and checked too.

Results at 3a8a2161

where	what	result
forge, run #2640	wai-web-reach.yml, both legs	pending (queued)
the linux runner's host, forgejo-runner exec of wai-web-reach.yml in the runner's image (an executed equivalent, not a forge verdict)	gate; record leg; tree leg	all three jobs green. Record leg: reach/record/ held to the manifest, build.sh "all 11 outputs equal reach/manifest.json", run-modern green (every rung and profile forced, the ES5-stripped engine, the demo verify scripts on shipped, L1, L2 and J, the measurement's written files equal), and every engine image green. Tree leg: the same steps green on the tree's own build
the linux runner's image, build.sh alone with WAI_REACH_REQUIRE_RECORD=1	the package of record	all 11 outputs equal the manifest (before this head they did not: the 4 J bundles differed)
macOS arm64	build.sh with WAI_REACH_RECORD=1	the same 11 outputs; only the manifest's tool lines changed
the WAI site, build-wasm-pkg.sh … wai/reach from 3a8a2161	the served reach files	every output equals the manifest; SHA256SUMS unchanged

What the engine images cover, by Node image and the engine features each has: node:0.12 (no WebAssembly) → J; node:8.0.0 (WebAssembly without the dotAll flag) → J for the full build, L2 for the receipt profile; node:8 (MVP WebAssembly, no BigInt) and node:10 (MVP WebAssembly with BigInt) → L2; node:12 and node:14 (the shipped build's WebAssembly features, no BigInt at the boundary) → L1. The README says which device classes each stands for, by capability. No real old device has been run. These proxies do not cover 32-bit ARM code generation, engines with the JIT off, small memories, or engine families other than the proxied one.

Falsifications (earlier heads, unchanged code paths)

Each break was made on committed code and built with build.sh; the named test was run, the file restored, and every break also made build.sh refuse its outputs against reach/manifest.json.

variant	break	named test, result
L1	no --legalize-js-interface	L1/full receipt_verify and i64_boundary FAIL on current Node, node:12 and node:14
L2	lowered, not legalised	L2/full receipt_verify and i64_boundary FAIL on current Node, node:8 and node:10
L2	sign-extension not lowered	the build refuses it at the MVP read-back
J	the glue keeps the shipped detach-only memory-view checks	J/full: most workloads FAIL on current Node and node:0.12; the control, L1 on node:12, passes
J and L2 receipt	the receipt profile leaves out the provenance exports	receipt_verify FAIL
loader	the bulk-memory probe declares a data segment it lacks	the rung check FAILS on current Node and node:12; the control, node:0.12, still gets J
runtime	without BigInt, an i64 result's low half is read as signed	i64_boundary FAIL on the ES5-stripped engine, node:0.12 and node:8; the control, node:10, passes

At this head the record leg itself was the falsification of the J translation: before the WebAssembly wasm2js, it refused the four J bundles on the linux runner's image.

Review fixes in this round

• CI holds the served bytes to the manifest (the record leg), and J reproduces on every host.
• wai-load.js: the feature noDotAll (was named after one engine); its reasons and comment say what the engine lacks.
• README, CHANGELOG and wai/README.md: the proxies by Node image and engine features, the device classes by capability, no engine, browser or OS family names; no counts that drift. The CHANGELOG claims no CI result.
• The PR title no longer says byte-identical before a CI verdict.

🤖 Generated with Claude Code

The shipped wai-web package needs WebAssembly with sign-extension, non-trapping float-to-int and bulk memory, a 64-bit integer that crosses the JS boundary as `BigInt`, and ES modules. This PR adds three builds derived from that package, and an ES5 loader that picks between them, in `wai/wai-web/reach/`. The Rust does not change. **CI verdict: pending.** The forge run of `wai-web-reach.yml` for the head `3a8a2161` is run #2640 (id 3740), queued behind the linux runner's backlog. Until it, or a later run, finishes green, nothing here is CI-verified; the executed equivalent below is a local run of the same workflow, not a forge verdict. This description will name the green run. ## What is built | rung | build | for engines with | |---|---|---| | shipped | the package itself | every feature above | | **L1** | the shipped binary, legalised at the JS interface (`wasm-opt --legalize-js-interface`, binaryen `version_123`) | the same WebAssembly, but no `BigInt` at the boundary | | **L2** | MVP-lowered (`--signext-lowering --llvm-nontrapping-fptoint-lowering --llvm-memory-copy-fill-lowering`), then legalised | MVP WebAssembly | | **J** | the MVP module translated by `wasm2js`, one ES5 script per profile | ES5 and typed arrays, no WebAssembly | L2 and J come in profiles: `full`, `verify_decode`, `verify` and `receipt`. `profiles.json` lists the exports each keeps, and `wasm-metadce` drops the rest. The J and L1/L2 scripts share an ES5 runtime (the builtins an old engine lacks, and i64 joined and split at the boundary: a `BigInt` where the engine has one, a `Number` exact below 2^53 where it does not) and the shipped glue compiled to ES5 with a fixed, counted set of changes (`manifest.json` records the counts). `wai-load.js` chooses a rung from feature probes alone, never the user agent: `WebAssembly.validate` on probe modules, one instantiated module that returns its i64 argument, and checks for typed arrays and `BigInt`. An early WebAssembly engine line (WebAssembly and the stack-trace capture API, but no RegExp `dotAll` flag: the feature `noDotAll`) gets J, or the L2 receipt build, because the full MVP module has crashed an engine of that line on arm64. A rung can be forced, and detection never throws. ## The package of record, and CI `reach/record/` keeps the package the site serves under `/wai/pkg/`: `wai_web_bg.wasm` `c2b63f74…050e` and `wai_web.js` `f63605f0…6f6a`, built from `wai/wai-web` at `248846f1` (`manifest.json` `input.commit`; `input.source` says how). `wai-web-reach.yml` runs a leg per package on the linux runner: - **record**: both files must have the manifest's SHA-256; `build.sh` runs with `WAI_REACH_REQUIRE_RECORD=1`, which refuses any other package, so all 11 outputs must have the manifest's SHA-256 and size: the bytes the site serves under `/wai/pkg/reach/`. Then `run-modern.mjs` and the engine images run on those outputs. - **tree**: wai-web built from this tree, so a change to wai-web meets the reach builds before the package of record moves to it. The package is kept, not rebuilt in CI: built in the linux runner's image from the same commit, with the export at the same physical path and every remap, its glue is the same and its wasm is not (the code section differs; measured twice). J's `wasm2js` is binaryen's WebAssembly build of the same release (npm `binaryen` 123.0.0, pinned with its integrity hash in `package-lock.json`), run on Node. The x86_64 Linux archive's native `wasm2js` allocates the translation's locals differently from the macOS archive's; the WebAssembly build gives the macOS archive's output on every host, for every profile, so no recorded output changed. ## Artifacts From `reach/manifest.json`. Brotli is quality 11. | file | rung | profile | SHA-256 | bytes | brotli | |---|---|---|---|---|---| | `wai-load.js` | all | — | `c3dc79392e6bf75d6cc190cd38eabab94f449d0d3687585cae6c3e03fe6775a2` | 16,621 | 4,474 | | `wai_web.j.full.js` | J | full | `1af5b5917ecb3097e8eb3c79342dd087bd3febeef58bd2222b623e0099b17848` | 5,969,835 | 1,053,831 | | `wai_web.j.receipt.js` | J | receipt | `b6c52b020c3daef6f0dc5a7ccbbd8e7134a951012987ceaaf66fdfaad9e2d77b` | 996,473 | 251,134 | | `wai_web.j.verify.js` | J | verify | `4862fb576c72bb12bffe4799684450c81a3181a34db134118a44e12b9204ab76` | 3,086,139 | 606,845 | | `wai_web.j.verify_decode.js` | J | verify_decode | `d2bb946fbab8dbcc5fb7ca101b6c4615881d3f1f1de47813a0b3c9e080f1b1bf` | 3,310,622 | 642,273 | | `wai_web.reach.js` | L1, L2 | full | `747db637684c8ffed24aab175a3dc1a399901c1d9699dd99c86a090b4b78bf0c` | 198,994 | 18,502 | | `wai_web_bg.l1.wasm` | L1 | full | `25e728714bcc67ccb133042012860a53c881ea6c26c3dc7538bf378c0598b3b8` | 2,591,481 | 683,525 | | `wai_web_bg.l2.full.wasm` | L2 | full | `5af77d42fbd2e2e6023789aca42dcb62c6bcf1ccb29e7303b31de5e6251fa88e` | 2,591,161 | 684,042 | | `wai_web_bg.l2.receipt.wasm` | L2 | receipt | `89ad094a90fbc31aa3399d0e4db41728c742c110a90480952f3c2527310fb821` | 393,027 | 163,989 | | `wai_web_bg.l2.verify.wasm` | L2 | verify | `cbf4d3705f566b76ea1aab6d4513a51632df0373338e0e206cceff9d4b7c6a00` | 1,222,037 | 407,801 | | `wai_web_bg.l2.verify_decode.wasm` | L2 | verify_decode | `efe0033b1cfc151054baf6282bd6cd9b2a264cf5df8321586cdbcf1f62928b87` | 1,316,304 | 433,878 | No output holds a host path or a toolchain folder: the package of record was rebuilt with the standard library's sources remapped to `/rustc/<the compiler's commit>` (the earlier package carried the build host's toolchain folder in its panic locations, and every reach binary and J bundle with it). The J bundles' base64 data segments were decoded and checked too. ## Results at `3a8a2161` | where | what | result | |---|---|---| | forge, run #2640 | `wai-web-reach.yml`, both legs | **pending** (queued) | | the linux runner's host, `forgejo-runner exec` of `wai-web-reach.yml` in the runner's image (an executed equivalent, not a forge verdict) | gate; record leg; tree leg | all three jobs green. Record leg: reach/record/ held to the manifest, `build.sh` "all 11 outputs equal reach/manifest.json", run-modern green (every rung and profile forced, the ES5-stripped engine, the demo verify scripts on shipped, L1, L2 and J, the measurement's written files equal), and every engine image green. Tree leg: the same steps green on the tree's own build | | the linux runner's image, `build.sh` alone with `WAI_REACH_REQUIRE_RECORD=1` | the package of record | all 11 outputs equal the manifest (before this head they did not: the 4 J bundles differed) | | macOS arm64 | `build.sh` with `WAI_REACH_RECORD=1` | the same 11 outputs; only the manifest's tool lines changed | | the WAI site, `build-wasm-pkg.sh … wai/reach` from `3a8a2161` | the served reach files | every output equals the manifest; SHA256SUMS unchanged | What the engine images cover, by Node image and the engine features each has: `node:0.12` (no WebAssembly) → J; `node:8.0.0` (WebAssembly without the `dotAll` flag) → J for the full build, L2 for the receipt profile; `node:8` (MVP WebAssembly, no `BigInt`) and `node:10` (MVP WebAssembly with `BigInt`) → L2; `node:12` and `node:14` (the shipped build's WebAssembly features, no `BigInt` at the boundary) → L1. The README says which device classes each stands for, by capability. **No real old device has been run.** These proxies do not cover 32-bit ARM code generation, engines with the JIT off, small memories, or engine families other than the proxied one. ## Falsifications (earlier heads, unchanged code paths) Each break was made on committed code and built with `build.sh`; the named test was run, the file restored, and every break also made `build.sh` refuse its outputs against `reach/manifest.json`. | variant | break | named test, result | |---|---|---| | L1 | no `--legalize-js-interface` | `L1/full receipt_verify` and `i64_boundary` **FAIL** on current Node, `node:12` and `node:14` | | L2 | lowered, not legalised | `L2/full receipt_verify` and `i64_boundary` **FAIL** on current Node, `node:8` and `node:10` | | L2 | sign-extension not lowered | the build refuses it at the MVP read-back | | J | the glue keeps the shipped detach-only memory-view checks | `J/full`: most workloads **FAIL** on current Node and `node:0.12`; the control, L1 on `node:12`, passes | | J and L2 receipt | the receipt profile leaves out the provenance exports | `receipt_verify` **FAIL** | | loader | the bulk-memory probe declares a data segment it lacks | the rung check **FAILS** on current Node and `node:12`; the control, `node:0.12`, still gets J | | runtime | without `BigInt`, an i64 result's low half is read as signed | `i64_boundary` **FAIL** on the ES5-stripped engine, `node:0.12` and `node:8`; the control, `node:10`, passes | At this head the record leg itself was the falsification of the J translation: before the WebAssembly `wasm2js`, it refused the four J bundles on the linux runner's image. ## Review fixes in this round - CI holds the served bytes to the manifest (the record leg), and J reproduces on every host. - `wai-load.js`: the feature `noDotAll` (was named after one engine); its reasons and comment say what the engine lacks. - README, CHANGELOG and `wai/README.md`: the proxies by Node image and engine features, the device classes by capability, no engine, browser or OS family names; no counts that drift. The CHANGELOG claims no CI result. - The PR title no longer says byte-identical before a CI verdict. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 2 commits 2026-10-09 18:47:13 -04:00

wai-web: reach builds — L1 legalised, L2 MVP-lowered, J wasm2js, and an ES5 loader ... c4e592cfa4

The shipped wai-web package needs WebAssembly with sign-extension, non-trapping
float-to-int and bulk memory, and i64 crossing the JS boundary as BigInt.
reach/build.sh derives three more builds from that package with pinned tools
(binaryen version_123 by archive SHA-256; TypeScript, esbuild and acorn by
package-lock.json):

- L1: the shipped binary legalised at the JS interface, for engines where i64
  does not cross as BigInt;
- L2: MVP-lowered and legalised, at four profiles (full, verify_decode, verify,
  receipt), for MVP-only WebAssembly;
- J: the wasm2js translation, one ES5 script per profile, with an ES5-floor
  runtime and glue: memory views refreshed when the buffer changes, i64 values
  carried as Numbers where there is no BigInt.

wai-load.js (ES5) picks shipped, L1, L2 or J from feature probes alone and
says why; a rung can be forced for testing.

test/conformance.js (ES5) runs the workloads over the repository's corpora on
any rung and compares every output with the shipped build's; run-modern.mjs
forces every rung and profile on a modern Node and runs the demo verify
scripts against each full build.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web reach: the recorded manifest, the README, the CHANGELOG, and CI on the engine lines ... bf7c61ff0b

reach/manifest.json is the build of the package the site serves (wai_web_bg.wasm
0063129a..., wai_web.js f63605f0...); given that package, build.sh refuses any
output whose SHA-256 differs. The manifest records where the package came from.

wai-web-reach.yml (linux runner) builds wai-web from the tree with the web target,
runs build.sh and run-modern.mjs on it, then runs conformance.js in one Node image
per engine line: node:0.12 (J), node:8.0.0 (J, and the L2 receipt build),
node:8 and node:10 (L2), node:12 and node:14 (L1). Each must be given its rung by
the loader's probes, and every output must equal the shipped build's. The README
says which device classes each image stands for, and that no real old device has
been run.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 1 commit 2026-10-09 18:50:35 -04:00

wai-web reach: the i64 workload crosses a low half with its top bit set ... 2c5f382492

2^32 + 2^31 goes in as a parameter and comes back as a result, so the Number
path (no BigInt) is tested where the low half's sign bit matters.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 1 commit 2026-10-09 19:23:53 -04:00

wai-web reach: direct i64 results with a high low half; the shipped wasm streams in browsers ... 3f26fab1f4

The runtime's falsification (an i64 result's low half read as signed where there
is no BigInt) passed every workload: op_lamport returns its u64 through memory,
not as an i64 result, so no workload returned an i64 whose low half has its top
bit set. quantizeScale(0.75, 32) and (1.5, 32) now do, with a zero and a
non-zero high half.

For the shipped rung a browser now hands the glue the wasm URL, so the module
compiles while it downloads; a host that reads files still hands it the bytes.
The recorded manifest changes for wai-load.js only.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 1 commit 2026-10-09 19:24:54 -04:00

ci(wai-web-reach): build the package outside the tree ... 07ee78d414

The wasm-bindgen glue is an ES module in a .js file. Under wai/wai-web/reach/ the
nearest package.json (the build tools' pins) has no "type", so Node would read
the glue as CommonJS first. In $RUNNER_TEMP no package.json applies; only the
reach build and the reference, which the engine images read, stay in the
workspace.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 1 commit 2026-10-09 19:26:23 -04:00

ci(wai-web-reach): gate the build on the pull request's own diff ... b77b332d3d

A rebase's push delta fires every path-filtered workflow; the reach job builds
wai-web and runs six engine images, so it now runs only when
scripts/pr-touches-paths.py says the pull request touches its paths (failing
open, and always on main), as wai-pack does.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 1 commit 2026-10-09 21:46:30 -04:00

wai-web reach: CI holds the served bytes to the manifest; the package of record kept in-tree ... df9d349d92

The reach builds' byte-identity rested on local runs: CI built wai-web from the tree,
which can never be the package the site serves, so build.sh took its "not the recorded
input" branch and the recorded outputs were never checked there.

- reach/record/ keeps the package of record: the two files the site serves under
  /wai/pkg/. It is rebuilt from wai/wai-web at 248846f1 with the site's recipe, which now
  also remaps the standard library's sources in the toolchain to /rustc/<the compiler's
  commit>: the old remap kept the toolchain's folder, named after the build host, in
  every panic location of generic std code (and so in every reach binary and J bundle).
  manifest.json is re-recorded from it, with input.commit.
- The package is kept rather than rebuilt in CI: the same commit and recipe give a
  different wasm on the linux runner's host than on the macOS arm64 host that built it
  (measured twice in the runner's image, with the export at /tmp and at /private/tmp; the
  glue is the same, the code section is not).
- wai-web-reach.yml runs a leg per package. The record leg checks reach/record/ against
  the manifest's SHA-256 and runs build.sh with the new WAI_REACH_REQUIRE_RECORD=1, which
  refuses any other package, so every output must equal the manifest; then run-modern and
  the engine images run on those outputs. The tree leg is the earlier job. Step names
  describe each image by its engine features.
- wai-load.js: the early-engine probe is the feature `noDotAll` (was `v8Before62`), and
  its reasons and comment say what the engine lacks, not which engine it is.
- README, CHANGELOG and wai/README: the proxies are named by Node image and engine
  features, and the device classes they stand for by capability; no engine, browser or
  OS family names. Counts that drift ("five counted places", "four profiles", "the four
  int_synth vectors") describe the shape instead. The CHANGELOG describes what CI runs
  and claims no CI result.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot changed title from wai-web: reach builds — L1, L2, J and an ES5 loader, byte-identical to the shipped build to wai-web: reach builds — L1, L2, J and an ES5 loader (CI verdict pending) 2026-10-09 21:46:44 -04:00

dcharlot added 1 commit 2026-10-09 22:24:13 -04:00

wai-web reach: J's wasm2js from binaryen's WebAssembly build, so every host gives the recorded bytes ... 3a8a2161d5

The record leg, run in the linux runner's image, built 7 of the 11 recorded outputs and
refused the four J bundles: the x86_64 Linux archive's native wasm2js allocates the
translation's locals differently from the macOS archive's (the same MVP module in, the
i64-lowering temporaries and coalesced locals out in another order). Each host is
deterministic on its own; the difference is between the archives' builds.

- build.sh runs wasm2js from binaryen's WebAssembly build of the same release (npm
  binaryen 123.0.0, pinned with its integrity hash in package-lock.json) on Node, after
  checking its version is the pinned release. Its output is the macOS archive's for every
  profile, so no recorded output changes; only the manifest's tool lines do. The four
  translations run side by side.
- In the linux runner's image (catthehacker/ubuntu:act-22.04, Node 24.18, x86_64), build.sh
  with WAI_REACH_REQUIRE_RECORD=1 on reach/record/ now gives all 11 outputs equal to
  reach/manifest.json; on macOS arm64 the re-recorded manifest has the same 11 outputs.
- README, CHANGELOG and the workflow say which wasm2js J uses and why.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 1 commit 2026-10-10 04:59:46 -04:00

wai-web reach: the provenance vector's signer id is a label ... ee44f1871c

The reach receipt workloads verified a receipt copied from the site, written by
wai_prov before its signer id became a label: it named a domain under did:web,
which signer_ids_are_labels refuses (jwp-receipts §7.1, §7.8).

wai_prov gains --carry <receipt.json>: it measures nothing, carries each
step's figure and label from an earlier receipt for the same lineage, and signs
them with its published test seed (0x70 x 32) under its label
did:example:wai-prov. It refuses a receipt that does not verify or whose steps
are not this run's (operations, input and output hashes, work), and writes no
report. The vector is regenerated with it: the envelope is unchanged, the
figures are the ones wai_prov first measured for these bytes, and carrying the
receipt onto itself writes both files again byte for byte. The vector's README
states how it is made and the command.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot added 13 commits 2026-10-10 17:26:53 -04:00

wai: wai generate and wai score build|render, with native pins a sink checks against ... a220d16a48

`wai generate` makes a wai.generate.spectral picture with the reference generator at
any size and prints its SHA-256; with --instr it makes a listed size of an instruction
object of form v0, which it reads as a sink does, and --write-instr writes one.
`wai score build` writes a WSCR from integer note fields only; `wai score render`
prints samples, pcm_sha256, mixdown_blake3 and score_hash, and --pcm writes the samples.

Vectors: tests/vectors/generate/sizes.json (256x128, 640x320) and instr-v0.json (the
object, its four listed sizes and 28 objects a sink refuses); score-conformance gains
pcm_sha256 for every vector and notes/<name>.json, the authoring form, which
`wai score build` turns back into the committed WSCR byte for byte. Every pin was made
natively and equals the shared browser binding's output.

`wai wrap` refuses a wai.generate.spectral payload that is not a form-v0 object, in
every build. No library source changes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai SPEC §5: the payload of wai.generate.spectral is an instruction object (form v0) ... 3770d1ab8e

The registration is completed as §8 permits: the row named the generator and no byte
layout. The payload is one canonical JSON object naming the model by its SHA-256 and
giving the prompt, the seed, the steps and every size a sink makes, each within stated
bounds and with one serialization per object, so an envelope's content hash names the
instructions. A sink makes only listed sizes, with that model only; conformance is
generation-equivalence at each listed size, and a sink holding a size's SHA-256 does
not present a picture that differs or accept one on a 64-bit FNV-1a alone. The
envelope's intent is `create`: a generator does not back `replicate` (§7), and this
keeps that rule.

The registry row names the payload; §8 lists the completion. score §2.3 documents the
integer authoring form `wai score build` reads, and §4 the pcm_sha256 every vector now
states. CI builds the `wai` binary with `generate` and `score` in both profiles of the
integer-kernel steps and runs tests/cli_generate_score.rs there; the two larger listed
sizes of instr-v0.json run in the release step.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai cli tests: the two instr_sizes callers each write their own object file ... 35debe1706

instr_makes_the_listed_small_sizes and instr_makes_the_listed_large_sizes run at
once in the release step, and both removed and rewrote one scratch file,
object.instr, while the other's `wai generate --instr` children read it. A remove
or a truncating write landing as a child opened the file would refuse the object
and fail the test. Each caller now names its own file.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai cli tests: the note-count guard is what refuses the crafted WSCR ... 0d123ab7f2

score_render_refuses_a_note_count_its_bytes_cannot_hold wrote a file with no
contract section, so the reader refused it with MissingSection(0x01) before
parse_notes reserved anything, guard or no guard: the test checked only which
message came first. The file now carries a well-formed contract (section 0x01) and
a notes section of only the count (0x02), and the same file declaring no notes is
shown to render, so without the guard the reader reaches Vec::with_capacity.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai score render: refuse a contract that is not one channel of wai.det.fixed64 ... 887c99a61f

render printed "channels":2 beside a mono mixdown of `duration` samples when a WSCR's
contract said two channels, and rendered a contract whose numeric profile was
wai.det.float64; a verifier following SPEC §7 Digests would read that PCM as stereo
frames. render now refuses both, as build refuses to write them.
score_render_refuses_a_contract_it_does_not_render patches the committed scale.wscr
in place for each case.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai score build: refuse a member given twice in the authoring form ... 95fa7244f6

The authoring form (score §2.3) is the definition, yet a note holding both
"start":0 and "start":5 built with start 5 (serde_json keeps the last value) and
the same hash as a note with start 5 alone; another JSON reader could keep the
first. wai_cli/strict_json.rs reads JSON with every object's members distinct and
refuses a repeat, and build reads its document through it. Two refused cases are
added: a note field and a document member, each given twice.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai generate.spectral form v0: accepted objects at every bound, and each refusal's reason ... f0107b07b8

instr-v0.json had one accepted object and 28 refused ones, none at an inclusive
bound, so a second sink stricter by one passed every vector; and the CLI test held
only that each object was refused, not why, so a rule relaxed (a quotation mark let
into the prompt) stayed green while the canonical-bytes check refused the object
in its place.

- The reader (wai_cli/instr.rs) refuses with a reason code, the first rule broken
  in a stated order; a member given twice is refused as such (strict_json).
- The vector gains twelve accepted objects (seed 0 and 2^32 - 1, steps 1 and 64,
  an empty prompt, 256 bytes, 0x20 and 0x7e, JSON's structural characters, a side of
  1, a side of 4096 and 2^23 pixels, 16 sizes, the w-then-h order), each with the
  SHA-256 of its first listed size made natively; eight more refused objects (types,
  a fraction in a size, a negative side, an escaped line feed, a backslash, cut-short
  JSON); and a reason for every refused object.
- tests/cli_generate_score.rs asserts each refusal's reason through `wai generate
  --instr` and `wai wrap`, and makes and wraps every accepted object.
- tests/generate.rs states form v0 a second time, independently of the reader, and
  holds the object, the accepted and the refused lists to it, making each accepted
  object's output with the library.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai generate.spectral: the generator's envelope carries intent create, and wrap writes no other ... da03ef1524

SPEC §5 said the envelope's intent is `create`, but `wai wrap` refused only
`replicate` and wrote wai.generate.spectral envelopes with `--intent improve` or
`--intent banana`, and the non-conforming list did not mention intent. The
sentence is now a rule: an envelope that names the generator, as capability or
fallback, carries `create`, one with another intent is non-conforming, and wrap
refuses any other. wrap_writes_the_generator_only_with_intent_create covers
improve, an open string, a case variant, the empty string and the fallback.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai generate.spectral: the model is the parameter set, so the envelope carries no pin; inspect and unwrap report the payload ... 7e3b883074

Form v0 names the model inside the payload by the SHA-256 of one file, and SPEC §5
never said how that relates to §3.1's parameter-set pin, which governs every
GenerativeDeterministic capability: whether a generate envelope carries a pin, or
which wins when a pin and `model` disagree. The library registers the set as
several files, so a form-less pin over the very file `model` names would be
refused form_required. SPEC §5 now states the relation: the model file is the
parameter set and `model` its identity; an envelope that names the generator
carries no `prior` and a sink refuses one that does, whatever it names. §3.1 says
so beside the pin rules, the non-conforming list names it, and prior-carriage §7's
row says the set is never pinned and names the file. No library source changes.

`wai inspect` and `wai unwrap` reported a generate envelope with a corrupt
payload as conforming ("component roles ✓", no payload line). They now report
the payload (form v0, with the reader's reason), the intent and any pin of every
envelope or WAI2 component that names the generator, ✓ or ✗; inspect's verdict
says the envelope does not conform. inspect_and_unwrap_report_the_generators_envelope
covers a prompt byte changed in place, the intent improve, a pin over the model
file itself, and a WAI2 component with and without a pin.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai REGISTRY: the status note names wai.generate.spectral among the registrations v0.4.0 completes ... cdc351b33c

The hand-written Status note listed the integer codecs whose registrations v0.4.0
completes and left out wai.generate.spectral, which SPEC §8 now says §5 completes.
The note sits outside the generated region the library test compares.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

wai-web wasm32 CI: the browser generator and score synth make every native pin ... 4c09bea76a

The CHANGELOG said every pin equals the shared browser binding's output, and the
browser sink's form-v0 reading has no CI of its own, yet wai-web-wasm.yml ran no
generate or score check. demo/verify_generate_wasm.mjs runs generateSpectral at
every size the generate vectors pin (sizes.json, instr-v0.json's four listed sizes,
and the first listed size of each object at a bound of form v0), checks each
object names the committed model, and runs ScoreSink over every score-conformance
vector for its pcm_sha256, mixdown hash and score hash. The workflow runs it on the
node build and now also triggers on wai/score-conformance/. 35 checks pass locally
on a wasm32 build of this tree.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge origin/main into wai/generate-score-cli ... 815f3fb8c2

Brings in #200 (HTTP receipts and keys) and #206 (wai-ops) among the rest
of main. One conflict, wai/CHANGELOG.md: both sides added entries at the
top of v0.4.0. Kept every entry; this branch's "Generated pictures and
scores" stays on top as the newest, main's entries follow unchanged.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Merge wai/generate-score-cli (with main) into wai/reach-builds ... 4e52e7923a

Brings in #197 (wai generate and wai score build|render) and, through it,
main as of #200 and #206. One conflict, wai/CHANGELOG.md: both sides added
entries at the top of v0.4.0. Kept every entry, newest first: this
branch's "wai-web on older engines: the reach builds", then #197's
"Generated pictures and scores", then main's entries unchanged.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot referenced this pull request from a commit 2026-10-10 22:23:54 -04:00

Merge wai/reach-builds (with #197 and main) into wai/d1-record-true

dcharlot referenced this pull request from a commit 2026-10-10 22:24:07 -04:00

Merge wai/d1-record-true (with #205, #197 and main) into wai/w4-4-staged-packages

dcharlot merged commit 997dac7cdf into main 2026-10-10 23:00:19 -04:00

dcharlot referenced this pull request from a commit 2026-10-10 23:00:20 -04:00

Merge pull request 'wai-web: reach builds — L1, L2, J and an ES5 loader (CI verdict pending)' (#205) from wai/reach-builds into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!205

No description provided.