discover: ship runtime-wasm-v0.16.2 in the execute panel

public/llms.txt

@@ -102,7 +102,7 @@ Current packages (Traverse v0.16.2, Nov 4, 2026, additive patch on v0.16.0): npm
 - [Why does model.execute return unauthorized_output?](https://traverse-framework.com/questions/why-does-model-execute-return-unauthorized-output.html): the Spec 104 host-private filter rejects strings starting with `/` or containing `://`; the full `ModelRightsRecord` carries `source_url`, so don't forward it. `model.execute@1.1.0` (registry#641 closed via #645, 2026-10-29; same WASM digest as 1.0.0) defines the normative flat `model_evidence` (`license_id`, `commercial_use`, `status`, `effective_usage`, optional URL-free `derivation`); full nested record is non-conformant. Shipped host binding still open (traverse#1719).
 - [Does the same Traverse WASM give byte-identical output on every host?](https://traverse-framework.com/questions/does-the-same-wasm-give-byte-identical-output-on-every-host.html): same WASM + same input bytes → same output bytes, but on v0.15.0 hosts don't always pass the same bytes: `traverse-mcp` re-serializes request JSON with sorted keys, embedders pass caller bytes through, so catalog `core.authorize@1.2.0` gives the same decision/reason/obligations/trace but a different `policy_hash` (`2a126b86…` vs `51a64653…`). Sorted-key input → byte-identical on all three. Fixed in v0.16.0 (Nov 2, breaking): Decision 118 + Spec `1722-canonical-guest-input-bytes`. Every host feeds guests RFC 8785 (JCS) canonical JSON input; unrepresentable input → `input_not_canonicalizable`; outputs never rewritten; conformance fixture `fixtures/cross-host/canonical-input-v1` on native, `runtime.wasm`, Node (traverse#1739, merged Oct 28). v0.15.0 keeps the old behavior. Write-up: [Same WASM, two hashes](https://traverse-framework.com/blog/same-wasm-two-hashes.html). Demo rerun on `main` before the tag (Browser + Node + traverse-mcp all `51a64653…`): [One audit fingerprint, every host](https://traverse-framework.com/blog/hash-converges.html). Rerun Nov 3 on released bits, Node (npm 0.16.0) + `traverse-mcp-v0.16.0` binary → both `51a64653…`, full output byte-identical; browser not rerun: [Traverse v0.16.0: same input, same output](https://traverse-framework.com/blog/traverse-0-16-0-same-input-same-output.html).
 - [What is digits-mlp?](https://traverse-framework.com/questions/what-is-digits-mlp.html): first trained exact-ref package in v0.14.0 (UCI digits MLP, 96.10% held-out, bit-identical); test-only signing; not a general LLM.
-- [Does the website use the latest traverse-embedder-web?](https://traverse-framework.com/questions/does-the-website-use-the-latest-traverse-embedder.html): site pins `^0.16.2` (matching npm, Nov 5) and `/discover` admits its signed demo fixture through `registerPackage` with an execution policy and `modelUsage: non_commercial`; the `/discover` execute panel still ships its own `runtime.wasm` pinned to the v0.13.0 digest; the site can lag future releases, so product apps pin published packages, not the website demo.
+- [Does the website use the latest traverse-embedder-web?](https://traverse-framework.com/questions/does-the-website-use-the-latest-traverse-embedder.html): site pins `^0.16.2` (matching npm, Nov 5) and `/discover` admits its signed demo fixture through `registerPackage` with an execution policy and `modelUsage: non_commercial`; the `/discover` execute panel ships its own `runtime.wasm`, the `runtime-wasm-v0.16.2` release asset (`b313b5c5…`, updated Nov 5 from the v0.13.0 copy); the site can lag future releases, so product apps pin published packages, not the website demo.
 - [How does Traverse complement Hugging Face?](https://traverse-framework.com/questions/how-does-traverse-complement-hugging-face.html): Hub = provenance; Traverse = pinned signed client-first capability; not Transformers.js/Hub replacement; no defer promise until a second executor exists.
 
 ## Optional

public/runtime/runtime.wasm.sha256

@@ -1 +1 @@
-sha256:a254c161d5699b19ffe6eb47d2e11e45a39363ae8b2a9ac435d54a09fb31d782
+sha256:b313b5c5c11291d9e9669125a0a9a77aa42a911b15d431a73e86b17c874e298c

src/pages/questions/does-the-website-use-the-latest-traverse-embedder.astro

@@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({
     name: 'Does the Traverse website use the latest traverse-embedder-web?',
     acceptedAnswer: {
       '@type': 'Answer',
-      text: 'Mostly. As of November 5, 2026 the website pins traverse-embedder-web at ^0.16.2, the line npm publishes with Traverse v0.16.2, and the /discover generate panel admits its demo fixture through registerPackage(manifestBytes, wasm, signatureBytes, policy) and passes modelUsage. One part lags: the /discover execute panel ships its own runtime.wasm copy pinned to the v0.13.0 digest. The demo fixture is signed with Traverse\'s published test-only key, which it trusts only for that demo. The site can still lag a future release, so treat published npm/crates versions and what-is-real-today as the product line, not the website pin.',
+      text: 'Yes. As of November 5, 2026 the website pins traverse-embedder-web at ^0.16.2, the line npm publishes with Traverse v0.16.2, and the /discover generate panel admits its demo fixture through registerPackage(manifestBytes, wasm, signatureBytes, policy) and passes modelUsage. The /discover execute panel ships its own runtime.wasm copy, and since November 5, 2026 that copy is the runtime-wasm-v0.16.2 release asset (sha256 b313b5c5...), digest-verified before every run. The demo fixture is signed with Traverse\'s published test-only key, which it trusts only for that demo. The site can still lag a future release, so treat published npm/crates versions and what-is-real-today as the product line, not the website pin.',
     },
   }],
 });
@@ -24,7 +24,7 @@ const relatedLinks = [
 ---
 <QuestionLayout
   title="Does the Traverse website use the latest traverse-embedder-web?"
-  description="The site pins traverse-embedder-web ^0.16.2, matching npm, and /discover admits its signed demo fixture through registerPackage with modelUsage. The execute panel's runtime.wasm still lags at v0.13.0. The site can lag future releases: pin published packages, not the website demo."
+  description="The site pins traverse-embedder-web ^0.16.2, matching npm, and /discover admits its signed demo fixture through registerPackage with modelUsage. The execute panel's runtime.wasm is the runtime-wasm-v0.16.2 release asset. The site can lag future releases: pin published packages, not the website demo."
   canonical="https://traverse-framework.com/questions/does-the-website-use-the-latest-traverse-embedder.html"
   category="Runtime and architecture"
   relatedLinks={relatedLinks}
@@ -33,7 +33,7 @@ const relatedLinks = [
   <p><strong>Short answer:</strong> <strong>mostly</strong>, and it can lag. The marketing site follows the published package line after each release. That is honesty, not a secret second runtime.</p>
 
   <h2>What is pinned today</h2>
-  <p>On <code>traverse-framework/website</code>, <code>package.json</code> depends on <code>traverse-embedder-web</code> at <code>^0.16.2</code> (updated November 5, 2026). npm’s current published line for that package is also <strong>0.16.2</strong>, lockstep with <a href="https://github.com/traverse-framework/traverse/releases/tag/v0.16.2">Traverse v0.16.2</a> crates. The lag: the /discover execute panel loads its own copy of <code>runtime.wasm</code> from <code>/runtime/runtime.wasm</code>, pinned to the v0.13.0 digest (<code>a254c161…</code>). Current releases ship theirs on <code>runtime-wasm-v0.16.2</code> (<a href="/questions/where-does-bundleembedder-get-runtime-wasm.html">details</a>). Cite <a href="/what-is-real-today.html">what ships today</a> for the consumer list apps should build against.</p>
+  <p>On <code>traverse-framework/website</code>, <code>package.json</code> depends on <code>traverse-embedder-web</code> at <code>^0.16.2</code> (updated November 5, 2026). npm’s current published line for that package is also <strong>0.16.2</strong>, lockstep with <a href="https://github.com/traverse-framework/traverse/releases/tag/v0.16.2">Traverse v0.16.2</a> crates. The /discover execute panel loads its own copy of <code>runtime.wasm</code> from <code>/runtime/runtime.wasm</code>. Since November 5, 2026 that copy is the <code>runtime-wasm-v0.16.2</code> release asset (runtime 0.16.2, bridge 1.1.0, sha256 <code>b313b5c5…</code>), and the page checks that digest before every execute. It replaced the v0.13.0 copy (<code>a254c161…</code>). The one known execute failure on that page (the report.* embedding chain stops at node 1 on a memory limit) is unchanged with the new bytes (<a href="/questions/where-does-bundleembedder-get-runtime-wasm.html">runtime.wasm details</a>). Cite <a href="/what-is-real-today.html">what ships today</a> for the consumer list apps should build against.</p>
 
   <h2>How /discover admits its demo model</h2>
   <p>The public <a href="/discover.html">/discover</a> generate panel (<code>discover-generate.js</code>) constructs an <code>ExactModelBrowserHost</code> and admits the <code>fixture.responder@1.0.0</code> conformance fixture through <strong><code>registerPackage(manifestBytes, wasm, signatureBytes, policy)</code></strong>. Since v0.16.0 registration takes the execution policy (Decision 120), and since v0.15.0 hosts require <code>modelUsage</code> whenever pins exist; the demo passes <code>non_commercial</code>. The Ed25519 signature over the exact <code>model.manifest.json</code> bytes, the pin digest, and the WASM digest are all verified before execute. The fixture is signed with Traverse's published <strong>test-only</strong> key, which the demo trusts only for that fixture. Product hosts configure their own trust roots. The 0.13 pin used <code>insertVerified</code>, which 0.14 removed.</p>

src/scripts/discover.js

@@ -22,11 +22,11 @@ const CONTRACT_SCHEMA_VERSION = '1.0.0';
    never fetches this itself (it's host-owned); this site ships its own copy
    under public/runtime/ and digest-verifies it before every execute, the
    same way every other artifact on this page is verified. Pin source:
-   traverse-framework/traverse runtime/runtime.wasm.sha256 at v0.13.0 (the
-   certified binary was rebuilt for v0.13.0 with a 32 MiB nested-wasmi memory
-   ceiling, #1480). */
+   traverse-framework/traverse release runtime-wasm-v0.16.2 (runtime 0.16.2,
+   bridge 1.1.0), the bytes pinned in runtime/ at tag v0.16.2. Earlier pin was
+   the v0.13.0 rebuild with a 32 MiB nested-wasmi memory ceiling (#1480). */
 const RUNTIME_WASM_URL = '/runtime/runtime.wasm';
-const RUNTIME_WASM_DIGEST = 'a254c161d5699b19ffe6eb47d2e11e45a39363ae8b2a9ac435d54a09fb31d782';
+const RUNTIME_WASM_DIGEST = 'b313b5c5c11291d9e9669125a0a9a77aa42a911b15d431a73e86b17c874e298c';
 
 /* Three committed goals: a structured Spec-113 target + starting facts each.
    No natural language: the target is an exact capability identity.

tests/e2e/discover.spec.mjs

@@ -25,8 +25,8 @@ test('goal 1 (price a quote) auto-plans on load, then review + execute for real
 
 // doc-approval.analyze used to trap with `execution_failed` ("wasm
 // `unreachable` instruction executed") under the v0.11/v0.12 nested
-// runtime.wasm. With the v0.13.0 certified runtime.wasm and
-// traverse-embedder-web@0.13.0 the full two-node chain executes for real.
+// runtime.wasm. Since the v0.13.0 certified runtime.wasm (and still with the
+// runtime-wasm-v0.16.2 asset) the full two-node chain executes for real.
 test('goal (doc-approval chain) plans a real two-node structural chain and executes it for real', async ({ page }) => {
   test.slow();
   await page.goto('/discover.html');
@@ -90,7 +90,7 @@ test('the translate-fr-semantic goal plans, then the local runtime genuinely ref
   await expect(page.locator('#discover-log')).toContainText('real governance decision, not an error');
 });
 
-// KNOWN ISSUE (still present at v0.13.0): report.collect-fragments
+// KNOWN ISSUE (still present with runtime-wasm-v0.16.2, Nov 5 2026): report.collect-fragments
 // fails differently from the (now fixed) unreachable-trap capabilities — it fails to
 // instantiate memory under the nested runtime.wasm's resource limiter
 // ("a resource limiter denied to allocate or grow the linear memory").