c4bda95cca
Generated on the final tree: the views page, rebuilt (802 495 bytes, under 1 MiB) from its sources; the notebooks' stored outputs; the agent docs. The pins that move: wai-web's course check names its engine now, so its digest moves (374b400e... to 969b2c1c..., and with every release from here), and the page's wasm32 count is 18 (native 26, as pinned). wai-quantum-qpu's library count is 34, as the cherry-picked pin says. What replaying each workflow's jobs found, each fixed here: - the views page's one line carried the estimate pane's English note, "no other beats on both", which the comparative-prose check reads across the line; the note says "none of the others beats on both"; - the docs runner's broken.qasm is broken on purpose, so the editors check requires it to fail to parse, as the intent set's broken programs; - the command line's parse test named the service's submit and task in a build without the service; those checks are a test of their own, built with it; - the set-only Merkle helpers warned in a build without receipts; - a one-element loop in the service's strict test; - the energy job looked for the live counter's line at the start of a line, where --nocapture puts it after the test's name; - the Python test comparing a run on the service with one here now leaves out the provenance the service adds, and checks it is there. The release heading's caller list is the final API check's: the frame text's new fields and variant, and the request's compile passes and mitigation. Co-Authored-By: Claude Opus 5.5 <[email protected]>
2.4 KiB
wai-quantum-views
The engine inside WAI Quantum's views for agent hosts. A host that draws
interactive views (the Model Context Protocol's extension
io.modelcontextprotocol/ui, version 2026-01-26) draws a tool's answer from a
ui://wai-quantum/* resource: one self-contained page, in a sandboxed frame,
with no network (wai_quantum::engine::views). The page draws what the
server's engine computed. What it computes itself, the check of the receipt
of what it shows, it computes with this crate: the engine's own
job::verify, built for WebAssembly and, from the WebAssembly, translated to
JavaScript, since a host's content-security policy may refuse to compile
WebAssembly (the extension's default policy does) while the page's own script
runs.
The interface has no imports: wq_alloc a buffer, write a request (JSON)
into it, wq_call it, and read the answer (JSON) at wq_out. The requests are
{"op": "verify", "job": {"request", "result"}} (the answer {"valid", "key", "signer"}) and {"op": "version"}.
Building the page
cd wai/quantum-studio && npm ci # binaryen, pinned, and esbuild
bash wai/wai-quantum-views/build.sh # writes wai/wai-quantum/views/
build.sh builds this crate for wasm32-unknown-unknown (paths remapped out
of the binary), optimises it for size and translates it to JavaScript with
binaryen, and runs wai/quantum-studio/build-views.mjs, which bundles the
views (wai/quantum-studio/src/views/, from the Studio's components) and
writes the page and its manifest.json: each part's size and SHA-256, and
every source with its SHA-256. The page is 802 KB: the script 94 KB (the
Studio's English words among it), the styles 49 KB, the engine 194 KB as
WebAssembly (258 KB in base64) and 401 KB as JavaScript. Every view is held under 1 MiB.
On x86_64 Linux with Rust 1.98.0 the build gives the same bytes in a clean CI
image. The engine's bytes change when anything in wai-quantum changes (its
code is laid out anew), so CI holds the page's script and styles to their
sources and warns of an engine to rebuild; the scripted host
(wai/quantum-studio/test/views.test.mjs) holds the committed page's engine,
in both forms, to the receipts the current servers seal.
Tests
cargo test --release here: a sealed job verifies through the three exports,
a changed count or verdict does not, and a compile's certificate verifies.
CI: .github/workflows/wai-quantum-views.yml.