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

2026-10-10

Transaction Science

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

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]>

4e52e7923a

• View at this point in history

2026-10-10 17:20:03 -04:00

Transaction Science

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

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]>

ee44f1871c

• View at this point in history

2026-10-10 04:27:29 -04:00

2026-10-09

Transaction Science

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

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]>

3a8a2161d5

• View at this point in history

2026-10-09 22:24:11 -04:00

Transaction Science

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

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]>

df9d349d92

• View at this point in history

2026-10-09 21:46:01 -04:00

Transaction Science

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

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]>

b77b332d3d

• View at this point in history

2026-10-09 19:26:20 -04:00

Transaction Science

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

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]>

07ee78d414

• View at this point in history

2026-10-09 19:24:45 -04:00

Transaction Science

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

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]>

3f26fab1f4

• View at this point in history

2026-10-09 19:22:41 -04:00

Transaction Science

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

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]>

2c5f382492

• View at this point in history

2026-10-09 18:49:16 -04:00

Transaction Science

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

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]>

bf7c61ff0b

• View at this point in history

2026-10-09 18:46:28 -04:00

Transaction Science

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

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]>

c4e592cfa4

• View at this point in history

2026-10-09 18:36:04 -04:00