diff --git a/public/llms.txt b/public/llms.txt index 8841937..da92796 100644 --- a/public/llms.txt +++ b/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 diff --git a/public/runtime/runtime.wasm b/public/runtime/runtime.wasm index be725b3..ca10087 100644 Binary files a/public/runtime/runtime.wasm and b/public/runtime/runtime.wasm differ diff --git a/public/runtime/runtime.wasm.sha256 b/public/runtime/runtime.wasm.sha256 index 91af17e..bb5f432 100644 --- a/public/runtime/runtime.wasm.sha256 +++ b/public/runtime/runtime.wasm.sha256 @@ -1 +1 @@ -sha256:a254c161d5699b19ffe6eb47d2e11e45a39363ae8b2a9ac435d54a09fb31d782 +sha256:b313b5c5c11291d9e9669125a0a9a77aa42a911b15d431a73e86b17c874e298c diff --git a/src/pages/questions/does-the-website-use-the-latest-traverse-embedder.astro b/src/pages/questions/does-the-website-use-the-latest-traverse-embedder.astro index 463aa63..c141762 100644 --- a/src/pages/questions/does-the-website-use-the-latest-traverse-embedder.astro +++ b/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 = [ --- Short answer: mostly, and it can lag. The marketing site follows the published package line after each release. That is honesty, not a secret second runtime.

What is pinned today

-

On traverse-framework/website, package.json depends on traverse-embedder-web at ^0.16.2 (updated November 5, 2026). npm’s current published line for that package is also 0.16.2, lockstep with Traverse v0.16.2 crates. The lag: the /discover execute panel loads its own copy of runtime.wasm from /runtime/runtime.wasm, pinned to the v0.13.0 digest (a254c161…). Current releases ship theirs on runtime-wasm-v0.16.2 (details). Cite what ships today for the consumer list apps should build against.

+

On traverse-framework/website, package.json depends on traverse-embedder-web at ^0.16.2 (updated November 5, 2026). npm’s current published line for that package is also 0.16.2, lockstep with Traverse v0.16.2 crates. The /discover execute panel loads its own copy of runtime.wasm from /runtime/runtime.wasm. Since November 5, 2026 that copy is the runtime-wasm-v0.16.2 release asset (runtime 0.16.2, bridge 1.1.0, sha256 b313b5c5…), and the page checks that digest before every execute. It replaced the v0.13.0 copy (a254c161…). 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 (runtime.wasm details). Cite what ships today for the consumer list apps should build against.

How /discover admits its demo model

The public /discover generate panel (discover-generate.js) constructs an ExactModelBrowserHost and admits the fixture.responder@1.0.0 conformance fixture through registerPackage(manifestBytes, wasm, signatureBytes, policy). Since v0.16.0 registration takes the execution policy (Decision 120), and since v0.15.0 hosts require modelUsage whenever pins exist; the demo passes non_commercial. The Ed25519 signature over the exact model.manifest.json bytes, the pin digest, and the WASM digest are all verified before execute. The fixture is signed with Traverse's published test-only key, which the demo trusts only for that fixture. Product hosts configure their own trust roots. The 0.13 pin used insertVerified, which 0.14 removed.

diff --git a/src/scripts/discover.js b/src/scripts/discover.js index 60d032c..4462385 100644 --- a/src/scripts/discover.js +++ b/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. diff --git a/tests/e2e/discover.spec.mjs b/tests/e2e/discover.spec.mjs index e878591..c59ebd8 100644 --- a/tests/e2e/discover.spec.mjs +++ b/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").