Deliver a real governed execution mode for /discover

[enricopiovesan]

Problem

/discover now truthfully labels its heuristic simulation, but users still cannot observe a real governed execution in the browser.

Scope

Add a separately labeled real-execution mode. The existing truthful simulation remains available until the new path satisfies all evidence requirements. The page must not claim that an external proposer/model is runtime authority.

Definition of done

• The page presents distinct Simulation and Real execution modes; each labels live, derived, and simulated elements above the fold.
• Real mode invokes a supported browser-reachable governed host path using a verified, pinned public artifact; it never fabricates a success state.
• The UI shows artifact/contract identity, contract-validation result, terminal outcome, and redacted per-invocation trace evidence.
• Unavailable transport, identity failure, invalid input, authorization rejection, and execution failure are visibly distinct and cannot be rendered as success.
• At least one checked-in browser E2E test proves a real successful execution and one rejection path against a deterministic fixture.
• The page copy and technical disclosure are reviewed against the actual implementation; no hero claim exceeds the evidence.
• The integration references the applicable Traverse host contract/version and has a documented local reproduction path.

Dependencies

Use the existing browser-host and verified-artifact foundations; do not reopen closed #1105 or #1157 unless a concrete regression is found.

[enricopiovesan]

Governance audit

No new runtime authority is required for this integration. Existing Specs 023, 115, and 118 plus ADR-0044 govern verified browser execution. If implementation requires a new public transport, request-time fetch, or changed trust boundary, stop and file a Traverse spec ticket rather than extending this issue implicitly.

[enricopiovesan]

website#58 — Spec + DoD enrichment (DRAFT — proposed comment for Ready review)

Ticket: #58 · Deliver a real governed execution mode for /discover
Project: "App Reference" · Status: Todo · Assignee: none
This is a draft for product review. It does not claim the ticket, change status, or authorize Real-mode code.
Proceed to implementation only when Status = Ready and Agent = Unassigned.

---

1. Context (unchanged intent, current facts)

/discover (src/pages/discover.astro + public/assets/js/discover.js) is a truthful
marketing demo with three labeled modes:

• Live — the browser fetches registry.traverse-framework.com/catalog.json at
  runtime; cards + graph nodes deep-link to real published contracts. No fixtures.
• Derived — a client-side name/namespace verb heuristic (STAGES in discover.js)
  groups by namespace and orders a plausible ingest → interpret → decide → act pipeline.
  Local JS only — not MCP, not a planner, not an LLM.
• Simulated — the G6 graph animates each node idle → active → complete via
  sleep(). Visualization only; no WASM executes.

This ticket adds a fourth, separately labeled mode: Real — proof, in the visitor's
browser, against a pinned public artifact, that a governed Traverse capability actually
executed and returned a verifiable receipt. Simulation stays and remains the default
until Real meets every evidence item below.

Foundations now exist (they didn't when the umbrella was filed)

The umbrella traverse#1150 ("truthful /discover now, real browser agent later", still
open, p1) spawned a gap inventory (traverse#1099) whose children have since all
closed as completed, and Traverse v0.10.0 (2026-09-05) shipped the missing
runtime pieces:

Gap	Issue	Status	What shipped
Browser embedder had no distributable build	traverse#1097	closed ✓	packages/web publish path
No auto-composition planner	traverse#1098	closed ✓ (spec 113)	declarative workflow planner — proposal only, human promotes
execute_entrypoint unreachable from a browser	traverse#1100, #1105	closed ✓ (spec-complete)	routed via execute_entrypoint MCP tool over spec 023 transport; inline body + non-fixed bundle
Governed browser-demo trust boundary unspecified	traverse#1157	closed ✓	governing integration slice (Specs 108/109/113, ADR-0050)
WASM artifacts had no CORS	registry#304	closed ✓	artifacts CORS-enabled like catalog.json
consumes/emits unpopulated	registry#305	closed ✓	(composition metadata — not needed for single-capability Real)

v0.10 release note: "a governed browser proposal host, plus browser execution of a
single verified capability that returns an execution receipt along the validated
execute_entrypoint path (spec 023)" and "verified registry metadata … CLI
materializes verified registry artifacts locally (spec 120, ADR-0051)."

Consequence: #58's dependency line ("use the existing browser-host and
verified-artifact foundations; do not reopen closed #1105 or #1157") is satisfiable
today. The remaining risk is verification / deployment reachability, not missing
runtime capability — see §6.

2. What "Real" means on this static marketing site

/discover is a static Astro page on GitHub Pages (traverse-framework.com). No
backend, no server, no secrets. "Real" is bounded to what an unauthenticated browser
can do against public infrastructure:

1. Browser-reachable governed host path. Real executes through a supported,
   documented Traverse browser execution entry point — the v0.10 governed browser
   execution host reaching execute_entrypoint over the spec 023 non-stdio transport —
   consumed as a public, versioned client artifact (published traverse-embedder-web
   / MCP browser client), loaded via a pinned (SRI where possible) <script>. No
   hand-rolled runtime in discover.js; no private Traverse crates; no serve sidecar
   (a static site can't host one, and spec 115/118 FR-004/FR-006 forbid serve
   fetch/sync/mutate on startup/execution regardless).
2. Pinned public artifact identity. Real targets exactly one capability release,
   pinned by immutable coordinates + content digest (namespace/id@version + sha256),
   resolved through the verified registry artifact path (spec 120 / ADR-0051), not
   mutable catalog.json "latest". The pinned digest is committed in page source and
   shown in the UI. Fetched digest ≠ pinned digest → fail closed, no execution.
3. Verifiable terminal outcome. A run is "Real-successful" only if the browser holds
   an execution receipt / trace summary from the governed host tying {pinned artifact
   identity, validated input, contract-validation result, output hash, outcome}
   together. No receipt → not a success; render the failure reason.
4. One capability, not a workflow. Real executes a single atomic verified capability
   via execute_entrypoint. Multi-capability composition stays Derived + Simulated —
   the v0.10 planner composes by schema-shape heuristic and is authoritative only after
   human export/promotion (spec 113 / Decision 62 / ADR-0043). Per traverse#1150 and
   #1157, any planner (browser-side or external) is an untrusted proposer; the
   runtime alone validates and authorizes. The marketing page must never present
   heuristic ordering as governed workflow validation.

3. Stays Simulation forever vs what Real must prove

Concern	Stays Simulation / Derived (always)	Real must prove (evidence in UI)
Pipeline ordering (ingest→…→act)	Yes — client-side name heuristic, never governed	—
Multi-node workflow execution	Yes — animated states only	Out of scope for this ticket
"Goal" / intent framing	Yes — illustrative copy	—
LLM / model / agent proposer	Yes — there is none; never add one	Never. No model chooses or generates anything. Capability + input come from committed config.
Single capability execution	Sim path stays available + labeled	Real WASM executed in-browser via governed host; receipt returned
Contract validation of input/output	Simulated "✓" log lines on sim path	Real schema/manifest/placement/policy/risk/resource validation result from the governed host
Artifact identity	n/a on sim path	Pinned ns/id@version + digest shown; digest-checked before run
Per-invocation trace	n/a on sim path	Redacted metadata + hashes only (spec 079 / ADR-0045 shape); never raw payloads
Registry catalog contents + card deep-links	Live (unchanged)	Live (unchanged)
Authority	"simulation" wording throughout	Runtime is the only authority; planner/proposal is untrusted (traverse#1150, #1157)

Rule of thumb: Real proves "this one governed thing ran — here is the receipt."
Everything about how capabilities compose stays Derived + Simulated until Traverse
ships browser-hosted governed workflow execution as a supported public surface.

4. Fail-closed UX copy (transport / registry / identity / validation / auth / execution)

Real must never render a success it cannot back with a receipt. Each failure emits a
distinct, non-alarming run-log line and leaves the Real result node un-completed (no
green state). Maps to #58 DoD item 4 ("visibly distinct and cannot be rendered as
success").

Failure	Trigger	Run-log copy	Mode badge
Transport unavailable	governed browser host client fails to load / init / no reachable endpoint	✗ real mode unavailable — the governed browser execution host did not load. Simulation is still available.	Real: unavailable
Registry unreachable	verified-artifact fetch fails / non-200 / CORS	✗ real mode unavailable — could not retrieve the verified registry artifact (<reason>). Nothing here is faked.	Real: unavailable
Artifact identity failure	fetched digest ≠ pinned digest, or signature/verification fails	✗ real mode halted — artifact identity did not match the pinned value. Refusing to run an unverified binary.	Real: failed (identity)
Invalid input	governed host rejects input vs contract schema	✗ real mode halted — the governed host rejected this input against the published contract (<detail>).	Real: failed (validation)
Authorization rejection	manifest / placement / policy / risk / resource / connector check denies	✗ real mode halted — the runtime declined to authorize this invocation (<check>). This is a real governance decision, not an error.	Real: failed (authorization)
Execution failure / no receipt	run throws, times out, or returns without a verifiable receipt	✗ real mode halted — execution did not return a verifiable receipt. Not reporting this as a success.	Real: failed (no receipt)

In every failure case: Simulation stays selectable and clearly the default; the first
viewport still reads Live / Derived / Simulated (+ Real only when Real succeeds).

5. Non-goals (explicit)

• No LLM / model proposer anywhere in /discover. No hosted model, no MCP "propose"
  loop that calls a model, no text generation, no automatic ambiguity resolution. The
  capability and its input are chosen by committed page config, never inferred.
  (Enforces traverse#1150 / #1157 / ADR-0050 provider-neutrality.)
• No fabricated success. No optimistic UI, no "assume it worked", no mocked receipt,
  no catch-all that paints a success state.
• No private Traverse imports. Public, versioned, published surfaces only (registry
  HTTP; published traverse-embedder-web / MCP browser client). No unpublished crates,
  no monorepo build output vendored into the site.
• No serve / sidecar / backend / CORS-hiding proxy. Static site only. No
  build-time execution passed off as runtime.
• No workflow-level "governed execution" claim. Real is single-capability; heuristic
  ordering is never relabeled as validated composition.
• No removal or de-emphasis of Simulation until every DoD item is met and signed off.
• No use of the expedition demo bundle as the happy path — pin a real, generally
  published capability release.
• No reopening traverse#1105 / #1157 unless a concrete regression is found (per Deliver a real governed execution mode for /discover #58).

6. Dependencies — foundations shipped; verification gaps remain

Foundations (all closed / shipped): traverse#1097, #1098, #1099, #1100, #1105, #1157;
registry#304, #305; Traverse v0.10.0 (spec 023 browser execution, spec 120 / ADR-0051
verified registry, spec 109 risk metadata + is_automatic_eligible()). Umbrella
traverse#1150 remains open (p1) and is the product-credibility parent.

Verify before flipping to Ready (these are the real risks):

1. A CDN-loadable browser client actually exists. Is traverse-embedder-web (or the
   spec-023 MCP browser client) published and consumable by a plain static site — a
   pinned <script> from a CDN, no bundler/build step? traverse#1097 closed "completed"
   but its own body flagged that publishing might need its own spec (API surface,
   versioning, security posture). Confirm the published artifact + its version.
2. A browser-reachable execute_entrypoint endpoint is deployed. traverse#1105
   identified three gaps (no non-stdio transport, local-path-only input, fixed bundle)
   and closed "spec-complete" — spec done ≠ endpoint deployed. Confirm there is a
   public, CORS-open, non-stdio execute_entrypoint transport a GitHub Pages origin can
   reach, or that the embedder runs the WASM fully client-side (which registry#304's
   CORS fix now permits).
3. An open capability to pin. Need ≥1 published capability whose effect class /
   determinism class make it is_automatic_eligible() (spec 109) and safe to execute
   unauthenticated from a marketing page. Confirm one exists and pick it (see Q1).
4. Receipt/trace-summary shape is stable enough (spec 023) to render identity +
   validation + outcome without pre-1.0 churn breaking the page. Soft.
5. The #1157 governing spec/ADR — capture its number and confirm nothing in it
   restricts an anonymous GitHub Pages origin from the browser-demo boundary.

If any of 1–3 is unmet at implementation time, Real ships disabled behind the
"Real: unavailable" state — never faked.

7. Definition of Done — enriched (extends #58's existing 7 items)

Keep #58's current checklist; the items below refine and add to it.

• (refines Deliver a real governed execution mode for /discover #58.1) /discover presents Simulation and Real as two
  explicitly labeled modes; both label live / derived / simulated (and, for Real,
  real-executed) above the fold. First viewport still passes the "truth test".
• (new) Simulation path is unchanged in behaviour and is the default; all
  existing tests/discover-truthfulness.test.mjs assertions still pass.
• (refines Deliver a real governed execution mode for /discover #58.2) Real runs through a supported, public, versioned Traverse
  browser execution surface (named + version pinned in source) — no bespoke runtime
  in discover.js, no private imports, no sidecar. Never fabricates success.
• (new) Real targets one capability release pinned by namespace/id@version +
  sha256 digest, committed in source and shown in the UI; digest is re-checked
  against the fetched verified artifact before execution (mismatch → §4 identity
  failure).
• (refines Deliver a real governed execution mode for /discover #58.3) On success the UI shows: pinned artifact/contract identity,
  contract-validation result, terminal outcome, and a redacted per-invocation
  trace (metadata + hashes only, no raw payloads).
• (refines Deliver a real governed execution mode for /discover #58.4) Real fails closed on: transport unavailable, registry
  unreachable, identity failure, invalid input, authorization rejection, execution
  failure / missing receipt — each with its distinct §4 copy. No path renders these
  as success.
• (new) No LLM / model / planner proposer is added; capability + input come from
  committed config. Any "proposal" framing states it is untrusted and non-authoritative.
• (refines Deliver a real governed execution mode for /discover #58.5) ≥1 checked-in browser E2E test proves a real successful
  execution and ≥1 rejection path, against a deterministic fixture (pinned
  capability + fixed input).
• (new) tests/discover-truthfulness.test.mjs updated in the same PR:
  (a) Real copy uses "real"/"executed" only where backed by a receipt;
  (b) each §4 fail-closed string is asserted present;
  (c) existing anti-lying assertions retained;
  (d) no label: 'AI Agent' | 'MCP' | 'Runtime' regressions.
• (refines Deliver a real governed execution mode for /discover #58.6/Deliver a real governed execution mode for /discover #58.7) PR description states, per mode, what is live vs derived
  vs simulated vs real-executed; references the applicable Traverse host
  contract/version; documents a local reproduction path.
• (new) Reviewed against traverse-framework/.github constitution + AI-agent
  hardening; no new external script origins beyond the pinned Traverse browser
  client + the existing G6 CDN.

8. Open questions for product (@enricopiovesan — needs-enrico; label doesn't exist in this repo yet)

1. Which capability do we pin? Need one published, unauthenticated, side-effect-free,
   roughly-deterministic capability release, safe to execute from a marketing page and
   is_automatic_eligible() (spec 109). Preferred showcase capability, or should the
   registry publish one for this purpose?
2. Is there a bundler-free, CDN-loadable browser client today (traverse-embedder-web
   or the spec-023 MCP browser client) with a version we can pin? If not, this ticket
   blocks on that distribution/publish work (possibly its own spec, per traverse#1097).
3. Client-side WASM execution vs remote execute_entrypoint? registry#304's CORS fix
   permits fetching + running WASM fully in-browser. Is that the intended Real path, or
   is there a deployed public execute_entrypoint endpoint a GitHub Pages origin should
   call? (Affects the whole integration shape.)
4. Receipt display depth. Minimum (identity + pass/fail + output hash) vs a fuller
   redacted trace. Any fields that must not be shown on a public page?
5. Mode default + entry. Simulation stays default — is Real an explicit opt-in
   toggle/tab, or does the page attempt Real once on load then fall back to Simulation?
   (Recommendation: explicit opt-in toggle, Simulation pre-selected.)
6. Scope confirmation: single-capability only for Real v1; workflow-level stays
   Simulated — agreed? (Matches spec 113 "proposal, not authority".)
7. Ownership / tracking: stays a website deliverable with Traverse/registry as
   upstream, or does it need a coordinated cross-repo milestone under traverse#1150?
8. What is the #1157 governing spec/ADR number, and does it need any amendment for an
   anonymous (no-auth) GitHub Pages origin?

---

Prepared as a Ready-review draft. Not claiming the ticket; no status/assignee change.

[enricopiovesan]

Q2 / Q3 verification — browser client + execution path

Read-only investigation of the shipped surfaces. TL;DR: the ready path is
BundleEmbedder, client-side, no deployed endpoint required. This supersedes the
earlier "prefer remote execute_entrypoint" note in the draft above.

Q2 — Is there a consumable browser client? Yes, with one caveat.

traverse-embedder-web@0.7.0 is published on npm:

• Apache-2.0, zero runtime dependencies, ~130 KB unpacked, published 2026-08-24
  (same day traverse#1097 closed). Single version so far; the package "versions in
  lockstep with the Traverse workspace".
• Description: "Public Traverse platform embedder SDK for Web/TypeScript clients,
  implementing embedder-api/1.0.0 (spec 068)". Source: traverse/packages/web/TraverseEmbedder.
• Caveat: it's ESM-only — "type": "module", main: ./dist/index.js, no
  browser / unpkg / jsdelivr / UMD field. It is not a drop-in <script src>.

Recommended consumption: npm install traverse-embedder-web@0.7.0 and let Astro
bundle it into the discover page script (lockfile gives us integrity). Alternatives:
<script type="module"> importing https://cdn.jsdelivr.net/npm/traverse-embedder-web@0.7.0/+esm,
or vendor a pinned copy under public/assets/vendor/. The current
<script src="/assets/js/discover.js" defer> becomes a bundled module either way —
a real but contained change.

Q3 — Execution path: BundleEmbedder, in-browser, no server.

What the SDK actually does (from its README + dist/*.d.ts):

• BundleEmbedder.init({ manifestPath, loader: new FetchBundleLoader(), platform: "web" })
  loads a pre-vetted application bundle (app.manifest.json, schema 1.0.0 — spec 044).
• It digest-verifies every bundled WASM (verifyArtifactDigest(bytes, declaredDigest, label)
  via WebCrypto; sha256: metadata in the manifest).
• It host-ABI-validates every module against a deny-by-default whitelist
  (HOST_ABI_V1_WHITELIST, findUnauthorizedImport) — only
  wasi_snapshot_preview1.fd_read / fd_write / proc_exit and reserved
  traverse_host.*. No filesystem, network, or env. Same rules as the native executor.
• It executes in the browser's own WebAssembly host via a minimal WASI preview1
  shim — no nested engine, no traverse-cli serve sidecar, no remote endpoint
  (spec 068 FR-002 / NFR-001).
• Events use the cross-platform envelope:
  event_type: "state_changed" | "capability_invoked" | "capability_result" | "error"
  — maps directly onto the graph's idle → running → complete states, now driven by
  real execution events.

No deployed execute_entrypoint endpoint is needed. ADR-0044 reserved
execute_entrypoint for arbitrary live-registry capability execution and reserved
BundleEmbedder for "a pre-vetted application bundle shipped with the app itself" —
which is exactly the Real-mode shape #58 asks for ("verified, pinned public artifact").
traverse#1105's three gaps (no non-stdio transport / local-path input / fixed bundle)
only block the execute_entrypoint path and are not on this critical path.

Tradeoff: Real mode executes a capability from a committed, pinned bundle — a
fixed subset — not an arbitrary live pick from catalog.json. Live mode's
full-catalog browsing + deep-links are unchanged; Real mode is explicitly the
"run this one pinned, verified thing" mode.

The SDK covers #58 DoD item 3 directly (no synthesized evidence)

#58 DoD item 3 needs	SDK provides
artifact / contract identity	releaseEvidence() → package name+version, runtime impl (browser-webassembly), bundle identity, sha-256 digest of every bundled WASM (spec 068 FR-008 / NFR-002)
contract-validation result	host-ABI validation + validateBundleCompatibility() + verifyArtifactDigest(), stable error codes (unsupported_bundle_schema, bundle_load_failed, …)
terminal outcome	`EmbeddedTraceOutcome = "completed"
redacted per-invocation trace	embedded-trace-api/1.0.0 companion (spec 517): traceList() / traceGet() → EmbeddedTraceSummary / EmbeddedTraceDetail (phases, selectedTarget, placement). Explicitly "safe public … never contains runtime error details"; "secrets never appear in events, errors, or evidence" (spec 068 NFR-004)
never fabricate success	stable EmbedderErrorCodes; "never fall back to a sidecar"; "writes are never silently dropped"

Remaining work / smaller unknowns

1. A bundle wrapping a pinned registry capability. The SDK needs an
   app.manifest.json bundle. The Traverse monorepo has 5 example bundles
   (traverse-starter, doc-approval, meeting-notes, registry-consumer,
   expedition-readiness) but those are monorepo examples, not the intended
   production artifact (and the expedition bundle is explicitly off-limits as the
   happy path). Likely need to build one (traverse-cli app new + pin one
   registry-published capability into it), then commit it under
   public/bundles/discover-real/ with a provenance note (capability
   ns/id@version + sha256 + source URL). Committing it (vs runtime-fetching from
   the registry) makes registry#304's CORS fix irrelevant here and makes the E2E
   test deterministic and offline.
2. Linear pipelines only. BundleEmbedder rejects event-driven/conditional
   edges at init. Fine for a single-capability demo; do not try to drive the
   multi-node composition graph through it.
3. Version pinning. traverse-embedder-web tracks the Traverse workspace
   version; pin 0.7.0 exactly and bump deliberately with its own evidence.

Updated recommendations

• Q3: use BundleEmbedder (client-side). Drop the "deployed
  execute_entrypoint endpoint" option unless product specifically wants live
  arbitrary-capability execution later — that's a separate, larger effort.
• Q1: pin a single pure-transform registry capability (a
  validate / score / evaluate / normalize type — the examples/capabilities/core-*
  set shows the shape) wrapped in a committed bundle. Confirm effect class = none and
  determinism class = deterministic so it's genuinely is_automatic_eligible()
  (spec 109). If no published capability qualifies cleanly, ask registry to publish a
  purpose-built demo-safe one.
• This makes Deliver a real governed execution mode for /discover #58 implementable now once product answers Q1 (which capability),
  Q4 (receipt display depth), Q5 (opt-in toggle — recommended), Q6 (single-capability
  v1 — recommended). Q2/Q3 are resolved. Q7/Q8 are tracking/documentation.

[enricopiovesan]

Decision log — Real governed execution mode for /discover (#58)

Brainstorm session resolving the open product questions from the two prior comments
(Spec+DoD enrichment; Q2/Q3 verification). Q2 (a browser client exists —
traverse-embedder-web@0.7.0, ESM-only) and Q3 (execution path — BundleEmbedder,
client-side, no server) were already verified and are treated as settled inputs here.

Outcome: #58 has no remaining external blockers and can move Todo → Ready.

---

1. Real mode v1 scope

Question: Single governed capability now, or hold Real mode until Traverse ships
governed browser workflow execution?

Options considered:

• Single capability now — pros: unblocks Deliver a real governed execution mode for /discover #58 on already-shipped foundations, honest and bounded, matches the ADR-0044 split; cons: only one graph node is ever "real", two labeled sub-modes to maintain.
• Wait for workflow execution — pros: eventually covers the whole pipeline, one mode; cons: no shipped path, no dated milestone (traverse#1150 open) — indefinite wait, leaves v0.10 browser-execution work unused.
• Single now + workflow-ready UI — pros: momentum now, no rework later; cons: speculative design cost for an unscheduled capability.

Recommendation: Single capability now (plain). Foundations are shipped; #58's DoD is already written around one pinned artifact; "wait" has no end date; a mode toggle is cheap to extend later.

Decision: Single capability now.

Why: Nothing to wait for, and the ticket's evidence requirements already describe a single-capability shape.

---

2. Which published capability to pin

Question: Which registry capability should Real mode execute in-browser?

Context: all 83 non-deprecated catalog capabilities are network-forbidden, no-filesystem,
no-host-API, stateless, memory_only — so a purpose-built "demo-safe" capability is
unnecessary. 36 list browser as a preferred target.

Options considered:

• core.calculate-price@1.1.0 — pros: instantly legible (line items → quote), reads as real business logic, 95.9% line coverage; cons: needs a committed pricing_config + line-items fixture.
• core.authorize@1.2.0 — pros: the output is a governed policy decision (allow/deny), perfect thematic fit; cons: more abstract for a general audience.
• review.state-transition-decide@1.0.0 — pros: smallest input surface, 100% coverage; cons: dry, low impact, least connected to the page's ingest→…→act framing.

Recommendation: core.calculate-price@1.1.0. A non-technical visitor understands it at a glance while it still reads as logic that "should need a backend" — the strongest first impression. authorize is the runner-up if the demo should literally be a governance decision.

Decision: core.calculate-price@1.1.0
(digest sha256:a046e5d001ae78b8de339d40378e2c22f04384d601a1b801b52cf99a3e44f0b2).

Why: Legibility is the priority for a marketing page; the result is human-readable and the "ran for real in your tab" point lands.

---

3. Real mode entry

Question: Explicit opt-in, or auto-attempt Real on page load?

Options considered:

• Explicit opt-in button — pros: no embedder/WASM work on a normal view, visitor consciously chooses "real", smaller reliability/abuse surface, failures only seen by opt-ins; cons: visitors who never click never see it.
• Auto-attempt, silent fallback — pros: everyone sees real execution when it works, zero effort; cons: every pageview loads the embedder + runs WASM, every view is a live third-party dependency, silent fallback blurs the sim/real honesty line.
• Auto-attempt after sim, narrated — pros: sees both, transition narrated, zero-click; cons: still an every-pageview dependency, longer sequence, more state.

Recommendation: Explicit opt-in button. The page's value is being trustworthy about what's real; a deliberate action reinforces that, and Real mode's dependencies stay off the critical path of a normal visit. Narrated auto-run is the acceptable middle if zero-click is required.

Decision: Explicit opt-in button. Simulation stays the default; no silent fallback.

Why: Protects the honesty line and keeps a third-party execution path off 100% of pageviews.

---

4. Receipt display depth (successful Real run)

Question: How much does the UI show after a successful Real run?

Options considered:

• Identity + verdict + output — pros: closes the loop (real execution → real verifiable result), best payoff from choosing calculate-price, still honest; cons: must clearly label the output as coming from the committed demo input.
• Identity + verdict only — pros: every field load-bearing, nothing to redact-review, fastest, matches DoD item 3's literal list; cons: hides the result, wastes calculate-price's legibility.
• Full expandable trace — pros: maximal transparency, shows execution phases; cons: spec-517 detail is abstract for this audience and pre-1.0 (may churn).

Recommendation: Identity + verdict + output. The capability was chosen for a legible result; show it. Keep any deeper trace optional and collapsed; don't build UI against the pre-1.0 trace-detail shape now.

Decision: Show pinned ns/id@version, artifact sha256 (pinned vs verified match),
contract-validation result, terminal outcome, output hash, and the actual returned
quote (labeled as the result of the committed demo input). Deeper redacted trace
optional/collapsed.

Why: The "…and here's the real answer" moment is the point; the fixture input is
non-sensitive so the full output is safe to show.

---

5. Consuming traverse-embedder-web@0.7.0 (ESM-only)

Question: npm + build-time bundle, CDN ESM import, or vendored copy?

Options considered:

• npm install + Astro bundle — pros: version + integrity in package-lock, standard supply-chain story for a WASM-executing SDK, no runtime CDN dep, no new script origin, offline E2E; cons: discover.js becomes a bundled module (build-step change).
• CDN ESM import (jsdelivr +esm) — pros: zero build change, version pinned in URL; cons: runtime jsdelivr dependency + auto-ESM transform, second external script origin (page already loads G6 from unpkg), no SRI, harder offline E2E.
• Vendored pinned copy — pros: no build change, self-hosted, exact bytes in-repo, offline; cons: manual re-vendor per bump, ~130KB checked in, no lockfile integrity.

Recommendation: npm install + Astro bundle. Correct integrity story for shipping this to the public site; adds no external origin; Astro already builds the site; offline deterministic E2E is far easier.

Decision: npm install traverse-embedder-web@0.7.0 as a pinned dependency; import
it in the discover page script; Astro/Vite bundles it at build time.

Why: Lockfile + CI integrity beats a runtime CDN transform (no SRI) or a manual
re-vendor treadmill. Note: tests/discover-truthfulness.test.mjs source-string
assertions must be re-pointed at the new bundled entry location.

---

6. Pinned WASM byte source at Real-run time

Question: Vendor the pinned .wasm into the committed bundle, fetch it from the
registry at runtime, or fetch-with-vendored-fallback?

Options considered:

• Vendor into committed bundle — pros: no dependency on registry CORS (the historically-broken path) or GitHub/Azure uptime, exact bytes reviewable, offline deterministic E2E, most literal "pinned artifact"; cons: a few hundred KB checked in, deliberate re-vendor on version bump.
• Fetch from registry at runtime — pros: no binary in repo, transparently the published bytes, bump = change the pin; cons: hard dependency on artifact CORS (closed as fixed, deployment unverified) + GitHub Releases/Azure uptime every run; the Azure-redirect CORS gap is exactly registry#304.
• Fetch, fall back to vendored — pros: live normally, resilient; cons: two code paths, still must vendor + provenance the fallback (pay both costs), "which bytes ran" needs careful surfacing.

Recommendation: Vendor into the committed bundle, plus a CI check that the committed
sha256 equals the registry catalog's declared digest. The page still re-verifies the
digest with WebCrypto before executing.

Decision: Vendor core.calculate-price@1.1.0's .wasm + contract.json +
app.manifest.json into public/bundles/discover-real/; CI asserts committed digest ==
registry catalog digest; runtime re-verifies with WebCrypto before execute.

Why: Most literal reading of "pinned artifact", removes registry artifact CORS from
the critical path, and makes registry#304 a non-blocker for #58.

---

7. Tracking the remaining work

Question: website-repo deliverable linked to the umbrella, a cross-repo milestone,
or standalone?

Options considered:

• website deliverable linked to traverse#1150 — pros: all remaining work is one repo / one PR, no coordination overhead, umbrella already exists, lineage stays discoverable; cons: a foundation regression mid-build is handled ad hoc.
• Cross-repo milestone — pros: one visible cross-repo status place; cons: heavyweight now that implementation is single-repo and every dependency is closed/shipped.
• Standalone in website — pros: simplest; cons: loses the trail to why /discover was simulation-first and to the p1 umbrella.

Recommendation: website deliverable linked to traverse#1150, with depends-on
references to the closed foundations.

Decision: Keep #58 self-contained in website; link it under traverse#1150; no new
milestone.

Why: Implementation is entirely a website concern with dependencies already
shipped; a milestone would be bureaucracy over a solved dependency graph, but the
umbrella link keeps the lineage findable.

---

8. The #1157 governing spec (lookup, not a decision)

Question: What spec/ADR number governs the browser-demo boundary, and does it
restrict an anonymous origin?

Finding: No new spec. PR #1172 (merged 2026-08-26) added
docs/browser-demo-governance-boundary.md; its Governing Spec section:
"Existing approved Specs 108, 109, and 113; ADR-0043 and ADR-0050. No amendment is
required." The boundary governs planner authority / trust boundaries. #58's Real
mode has no planner (single pinned capability, committed input), so it sits well
inside the boundary; nothing there restricts an anonymous GitHub Pages origin.

---

Resolved dependency status (for the Ready flip)

Item	Status
traverse#1097 — browser embedder published	✅ traverse-embedder-web@0.7.0 on npm
traverse#1100 / #1105 — execute_entrypoint from a browser	✅ Not on this path — BundleEmbedder chosen (ADR-0044 split)
traverse#1157 / PR #1172 — governed browser-demo boundary	✅ Documented; Specs 108/109/113 + ADR-0043/0050
registry#304 — WASM artifact CORS	✅ Non-blocker — WASM is vendored (decision 6)
registry#305 — consumes/emits backfill	✅ Irrelevant for single-capability execution
traverse#1150 — product-credibility umbrella	🔗 Open (p1); #58 links under it

Deferred to implementation (not product decisions)

• The committed fixture input for calculate-price (currency + lines +
  pricing_config) — pick realistic, non-sensitive values.
• The E2E rejection-path fixture — recommend a tampered-digest case (exercises the
  identity gate); optionally also a schema-invalid input.
• Whether the Real button sits inside the existing graph panel or in its own strip —
  visual design call.
• Re-pointing tests/discover-truthfulness.test.mjs at the bundled discover entry and
  adding: fail-closed copy assertions, "real"/"executed" only-with-receipt assertions,
  retained anti-lying assertions.

[enricopiovesan]

Decision log — Real mode implementation choices (#58)

Follow-up brainstorm to the product decision log above. Scope: the implementation
infrastructure, once it was clear the website repo has no CI test run, no E2E
runner, and no bundler config beyond Astro defaults (only dependency is astro;
discover.js is a plain static file in public/). These are engineering decisions,
not product ones — recorded here so the eventual implementer doesn't re-litigate them.

---

1. CI test gate

Question: Add a CI workflow that runs the test suite on every PR, or keep tests local?

Options considered:

• Add test.yml PR workflow (npm test + digest gate + E2E) — pros: the truthfulness assertions and digest pin finally enforce something (they run nowhere today), Deliver a real governed execution mode for /discover #58's "checked-in browser E2E" is only meaningful if CI runs it, catches future regressions; cons: new workflow, browser install adds CI minutes.
• Fast Node tests in CI, E2E local-only — pros: cheap fast gate on honesty-critical checks, no browser in CI; cons: E2E rots, partial DoD enforcement.
• Keep all tests local-only — pros: zero new CI, matches minimal repo; cons: a truthfulness regression or silent digest drift ships to prod, E2E becomes checkbox theatre.

Recommendation: Add test.yml. The truthfulness test and the new digest gate exist to stop the page quietly lying — that guarantee is worthless unenforced.

Decision: Add a test.yml PR workflow running npm ci + npm test + the Playwright E2E on every PR to main.

Why: Enforcement is the whole point of the honesty tests; the CI cost is a one-time addition.

---

2. Browser E2E runner

Question: Playwright, a lighter hand-driven browser lib, or jsdom in the current Node runner?

Options considered:

• @playwright/test — pros: faithfully runs a real browser + native WASM + Web Locks / IndexedDB / WebCrypto that the embedder needs, trivial DOM assertions, webServer runs astro preview automatically, retries/fixtures; cons: real devDependency + browser binary in a one-dep repo, first-time setup.
• playwright-core / puppeteer hand-driven — pros: smaller kit; cons: lose the runner (webServer/fixtures/retries), hand-roll launch/teardown, still downloads a browser in CI so barely lighter, more bespoke glue.
• jsdom/linkedom in node --test — pros: no browser download, runs in npm test as-is; cons: not a real browser — FetchBundleLoader / IndexedDB / Web Locks / crypto.subtle may be absent or misbehave, Deliver a real governed execution mode for /discover #58 says "browser E2E" specifically, risk of proving the wrong thing.

Recommendation: @playwright/test. #58 mandates a browser E2E and the embedder is built on browser APIs — only a real browser proves it. Accept the toolchain cost.

Decision: @playwright/test, added as a devDependency in PR A. npm test stays fast pure-Node; a separate npm run test:e2e; CI runs both.

Why: The embedder's dependence on Web Locks / IndexedDB / WebCrypto / native WASM means anything less than a real browser risks a false green.

---

3. Script restructuring for bundling traverse-embedder-web

Question: Move the whole discover.js into Astro's pipeline, or add Real mode as a separate bundled module?

Options considered:

• Separate src/scripts/discover-real.js, existing file untouched — pros: zero diff to the 530-line simulation code under the most "don't regress" scrutiny, existing truthfulness-test read() path unchanged, clean sim/real isolation, Real code loads only on click; cons: two files share a small surface (graph-node update, log lines) via a window hand-off, test gains a 3rd read().
• Move whole script into src/, merge Real logic in — pros: one file, idiomatic Astro; cons: shipped file becomes minified so the test asserts on source not output, the working file moves, more churn.
• Single merged bundled module — pros: one file end to end; cons: largest diff to working simulation code, highest regression risk on the Simulated path.

Recommendation: Separate module. Leave the honesty-critical simulation file alone; Real mode is its own small Astro-bundled module the opt-in button lazy-imports.

Decision: New src/scripts/discover-real.js (Astro/Vite bundled), dynamically
import()-ed on first click of the Real button. public/assets/js/discover.js
unchanged. Truthfulness test gains a read of the new module.

Why: Smallest blast radius on the Simulated path the whole page is built around.

---

4. Hero headline

Question: Reword the tested H1 to name real execution, or keep it and surface Real elsewhere?

Options considered:

• Keep headline verbatim, surface Real in the graph section — pros: the H1 stays the always-true default state (Real is opt-in, not default), satisfies "no hero claim exceeds the evidence", minimal copy churn, existing regex keeps guarding sim wording; cons: a skimmer might miss that real execution exists.
• Rework headline to include "real execution" + update the test — pros: fuller story at the top, discoverable at a glance; cons: changes a deliberately-worded tested line, risks overclaiming (one opt-in pinned capability ≠ the pipeline) — the exact DoD warning, more test churn.
• Keep headline, add an eyebrow line — pros: discoverable without touching the tested line; cons: heavier two-line hero, still copy to review against the governance audit.

Recommendation: Keep it verbatim. Single-capability opt-in Real doesn't belong in the H1 next to the always-true "Live · Heuristic · Simulated".

Decision: H1 unchanged; truthfulness regex unchanged. Real is introduced as a
labelled control + result panel in the graph section, plus one added sentence in the
hero sub-paragraph (reviewed for no overclaim).

Why: "No hero claim exceeds the evidence" (#58 DoD) + the pre-existing governance-audit constraint on trust-boundary wording.

---

5. Demo fixture input

Question: What input does Real mode send to core.calculate-price@1.1.0?

Options considered:

• Contract's own use_cases[0].input_example verbatim (USD, 2×$50 SKU-100, summer-10 10% discount, 8% tax → net $97.20) — pros: guaranteed schema-valid, owner-authored, strongest honesty story, no guesswork, output visibly exercises a discount rule + a tax rule; cons: abstract "SKU-100" naming.
• Hand-authored friendlier variant — pros: more inviting; cons: we author the nested discount_rules/tax_rules (real risk of a subtle invalid field), loses the "capability's own example" hook, more review.
• Contract example sent, display-relabeled — pros: schema-safe input + friendlier UI; cons: input-vs-display mismatch, slight honesty smell.

Recommendation: Contract example verbatim. It already produces a clear business-logic result; label the UI "the capability's own documented example input".

Decision: Send use_cases[0].input_example exactly as published. Expected output
totals.net = 97.2 — the E2E success assertion hard-codes this.

Why: Zero schema risk, best honesty story, deterministic E2E.

---

6. E2E rejection path

Question: Which single rejection does the E2E prove (tampered digest / schema-invalid input / both)?

Options considered:

• Tampered artifact digest — pros: exercises the highest-stakes guarantee ("don't execute an unverified binary"), fully deterministic, no coupling to the capability's own error behaviour; cons: needs a way to corrupt the bytes, slightly artificial.
• Schema-invalid input — pros: no second binary, tiny fixture, exercises the embedder's real validation path; cons: couples to where validation runs and the pre-1.0 error shape, proves a lower-stakes guarantee.
• Both — pros: covers the two likely failure modes; cons: more code + the corrupt-bytes mechanism, Deliver a real governed execution mode for /discover #58 asks for one.

Recommendation: Tampered digest. The identity gate is the fail-closed path most likely to be implemented subtly wrong.

Decision: Tampered-digest rejection, implemented via Playwright request
interception (page.route returns corrupted bytes for the .wasm fetch) — no
production test hook, no committed second binary. Assert failed (identity) and no
success state.

Why: Enforces the "refuse an unverified binary" guarantee without adding a
test-only affordance to production code.

---

7. PR structure

Question: One PR, two, or three?

Options considered:

• Two — PR A: vendored bundle + digest test + test.yml + pinned dep; PR B: Real mode UI + wiring + truthfulness updates + E2E. Pros: PR A small/low-risk/fast, lands the CI gate + verified pin before feature code, PR B is one focused feature, clean bisect; cons: two review cycles, PR A briefly merges assets nothing consumes.
• One — pros: nothing merges unused, one review; cons: large multi-concern diff, likely "please split".
• Three (tooling / bundle / feature) — pros: each tiny; cons: three cycles for a modest feature, tooling PR adds Playwright with nothing using it — same critique thrice.

Recommendation: Two. Right granularity — infra/asset PR is genuinely low-risk and valuable first; feature PR stays reviewable.

Decision: Two PRs, A then B as above.

Why: Lands the enforcement (CI + digest pin) before any feature code, without over-splitting.

---

Net effect on the implementation plan

• PR A now also adds .github/workflows/test.yml and @playwright/test +
  playwright.config.mjs (with a webServer running astro preview), plus a
  test:e2e script.
• discover.js does not move; Real mode lives in src/scripts/discover-real.js.
• Hero H1 and its truthfulness assertion are unchanged.
• E2E: one success (assert net $97.20, digest "verified match", outcome completed)
  • one tampered-digest rejection via page.route (assert failed (identity), no
    success). Both deterministic, offline.
• Still nothing required from the traverse or registry teams.

[enricopiovesan]

PR A open — #63 (bundle + digest gate + test CI)

Implementation started (Enrico approved the decision logs in review). Status moved to In Progress; needs-enrico cleared.

#63 stages the verified bundle and the test infrastructure — no page changes:

• public/bundles/discover-real/ — spec-044 bundle wrapping core/core.calculate-price@1.1.0, pinned sha256:a046e5d0…44f0b2, run client-side by traverse-embedder-web@0.7.0 BundleEmbedder.
• Key de-risking result: BundleEmbedder loads this hand-built single-capability bundle and executes the real published WASM to the correct deterministic output (totals.net 97.20, discount + tax rules applied) — verified in tests/discover-bundle.test.mjs, which runs in npm test. The "does BundleEmbedder accept a single-capability bundle / does the real wasm run" risk from the decision log is retired.
• New .github/workflows/test.yml (there was no test CI). Weekly non-blocking job checks the pin against the live catalog.

CI on #63: governance, CLA, node --test all green.

PR B next: the opt-in Real button + result panel in discover.astro, src/scripts/discover-real.js embedder wiring with the six fail-closed states, truthfulness-test updates, and the Playwright E2E (success + tampered-digest rejection).

[enricopiovesan]

PR B open — #64 (Real mode UI + wiring + E2E)

Stacked on #63. Adds the fourth mode: an opt-in Real run that executes core/core.calculate-price@1.1.0 as WASM in the visitor's browser via BundleEmbedder, with a receipt.

DoD status:

• Distinct Simulation / Real modes; live / derived / simulated / real all labelled above the fold (hero + "How this is built"). H1 unchanged.
• Real uses a supported public browser path (traverse-embedder-web@0.7.0), a pinned + digest-verified artifact; never fabricates success.
• UI shows artifact/contract identity, digest match, contract-validation result, terminal outcome, output hash, the quote, and a redacted per-invocation trace.
• Six fail-closed states (transport / registry / identity / validation / authorization / no-receipt), each visibly distinct, none renderable as success.
• Checked-in browser E2E: one real success + one tampered-digest rejection (tests/e2e/discover-real.spec.mjs, new e2e CI job).
• Copy reviewed against implementation; no hero claim exceeds evidence; composed pipeline explicitly not executed.
• References the host contract/version (embedder-api/1.0.0, spec 057/068) with a documented local repro (npm run test:e2e).
• No LLM/planner/proposer added; capability + input from committed config.
• discover-truthfulness extended; no label: 'Real Agent'/pipeline-is-real regressions.

CI on #64: governance ✅ · CLA ✅ · node --test ✅ (6) · playwright e2e ✅ (2/2 Chromium).

Merge order: #63 → then #64 retargets to main.

[enricopiovesan]

Shipped ✅

Both PRs merged to main and deployed:

• feat(discover): stage pinned governed-execution bundle for Real mode (#58) #63 — pinned core/core.calculate-price@1.1.0 bundle + digest gate + first test CI → 19f0ee6
• feat(discover): add opt-in Real execution mode (#58) #65 — opt-in Real execution mode (supersedes the auto-closed feat(discover): add opt-in Real execution mode (#58) #64) → 67a08f6

main CI at 67a08f6: test (node --test + playwright e2e) success, Deploy to GitHub Pages success. Real mode is live on https://traverse-framework.com/discover.html — click “Run this one for real →” in the graph section.

DoD — all met

• Distinct Simulation / Real, all four states (live / derived / simulated / real) labelled above the fold; H1 unchanged.
• Real runs core/core.calculate-price@1.1.0 as WASM in-browser via traverse-embedder-web@0.7.0 BundleEmbedder; artifact pinned + digest-reverified; fails closed, never fabricates success.
• Receipt shows identity, digest match, contract-validation result, terminal outcome, output hash, the quote, and a redacted trace.
• Six visibly-distinct fail-closed states; none renderable as success.
• Checked-in Chromium E2E: one real success + one tampered-digest rejection; runs in CI.
• No LLM / planner / proposer; capability + input from committed config. No traverse-cli serve, no private imports.
• Governance audit satisfied (Specs 023/115/118 + ADR-0044; no new transport/fetch/trust-boundary).

Nothing outstanding on the traverse or registry side. Please move the project card to Done — I don't have access to the board field.

[enricopiovesan]

Toward #1102-B: what's unblocked shipped, what's blocked is filed

Re-scoped after clarifying the target is #1102's medium-term demo (a real runtime + a model selecting capabilities at runtime), not just pinned single-capability execution.

Blocked upstream — issues filed today

Pillar of #1102-B	Blocker	Issue
Runtime discovery + verified fetch from the live registry	prepareRegistryDependency (spec 080) needs per-capability contractUrl + contractDigest; the registry publishes neither (WASM mirror is CORS-open now)	traverse-framework/registry#383
A model / planner selecting capabilities in-browser	No traverse-planner-web on npm; planner is server-side; main proposal/entrypoint APIs need a deployed public traverse-cli serve host that doesn't exist	traverse-framework/traverse#1269
"WASM AI model" vs remote selection endpoint	product decision, still open	tracked on traverse#1150 / discussion #1102

Building any of these in the website JS now = inventing runtime/selection behaviour, which CLAUDE.md + the #58 governance audit forbid. So they wait on the two issues.

Not blocked — shipped as PR #67

A second opt-in Real demo: a real 3-capability governed pipeline, period.finalize → summary.aggregate → uncertainty.score, executed client-side via BundleEmbedder as one direct workflow — real WASM, one execution event per node, each node consuming the previous node's output. Digests pinned + re-verified. npm test 8/8, Playwright 3/3.

This delivers #1102-B's real multi-capability WASM execution + ordering + per-node traces. It does not do discovery or selection — capabilities/order are authored in a committed bundle and the page says so (links traverse#1150). That's the honest maximum until #383 / #1269 land.