You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/discover grew layer by layer — Live catalog fetch, Derived name-heuristic graph,
Simulated idle→active→complete animation, Real single-capability execution, Real
3-capability authored pipeline, Runtime-discovered plan→review→execute. Six overlapping
stories, inconsistent, and the copy no longer matches what the page does (the hero still
says "Heuristic composition. Simulated execution."). Now that the real
runtime-discovered loop works (traverse-embedder-web@0.9.0, Spec 1277), collapse the
page to that one flow, keep the graph, and make it showcase real stated goals being
discovered, planned, reviewed, and executed against the live registry.
Decision log (brainstorm 2026-09-09)
1. Scope of the cut
Options: collapse to the runtime-discovered flow only · keep authored-Real as a
"canned" tier · quarantine Derived+Simulated as a labelled illustration. Decision: Collapse to one flow. Cut Derived, Simulated, and both authored-Real
demos. A single-capability goal naturally produces the "1 capability" case, so the
authored demos are redundant. Why: The user's complaint is inconsistency and strange wording; one mechanism is
the only way to fix that. "Only the real thing."
2. What the graph renders
Options: the plan + live execution in one graph, three phases · graph shows
executed result only, plan in a side table · keep the existing Goal→system→chain→Result
layout wired to real data. Decision: One graph, three phases — planned (mappings unconfirmed) → reviewed →
executing/succeeded/failed, driven by the real ComposedWorkflowTrace. Why: The graph you review is the graph that runs — one honest artifact; directly
delivers "watch goals execute". Note: executeBrowserComposedWorkflow returns the whole
trace at once, so phase 3 is a fast staggered reveal of a real result, not a live
stream.
3. Goals UX
Options: goal gallery, on-demand run · auto-cycle pausing at each gate · two goals
side by side. Decision: A row of 3 preset goal cards. Click one → discovery → plan → review gate →
(click to confirm) → execution. One goal at a time, visitor-driven. Why: Respects the explicit Spec-1277 review gate (the confirm click is itself part
of the showcase); auto-cycle can't auto-execute without weakening the governance
property.
4. Goal set
Options: 3 goals (multi-node, single-node, no-plan) · 4–5 goals all producing a plan
· 2 goals. Decision: 3 goals — one that discovers the multi-node chain
(period.finalize → summary.aggregate → uncertainty.score or the subset the planner
returns), one that discovers a single capability, one that legitimately finds no
structural candidate, shown as a real outcome, not an error. Why: Covers the range in 3 cards; the no-plan case honestly shows the planner only
chains what structurally fits — it doesn't invent.
5. Hero framing
Options: lead with the action ("Watch a goal get planned and executed — for real")
· lead with the trust boundary ("The browser proposes. The runtime decides.") · plain
and functional. Decision: Lead with the action. Subhead states the mechanism precisely: the browser
fetches the live registry, a deterministic structural planner (no LLM, no
name-matching, no NL) proposes a workflow, the visitor reviews it, the governed
runtime executes it in the tab. Why: The page's job is to showcase goals executing; the governance points are the why it's impressive and belong in the immediate subhead. Cleanly replaces the false
Live/Heuristic/Simulated headline.
6. Live-registry element
Options: compact stats strip + per-run capability cards · drop it, links in the
graph · keep the full browsable card grid. Decision: Keep the live "N published versions · M capabilities · K namespaces" line.
Drop the persistent grid. After a run, show cards only for the capabilities actually
used, each deep-linking to its real registry contract. Why: The stats are cheap proof the whole thing runs on real published
infrastructure; per-run cards ground the abstract graph in real contracts without a big
persistent widget.
7. Transparency section
Options: keep a dedicated section rewritten for the one flow · fold into hero +
inline annotations · replace prose with a trust-boundary diagram. Decision: Keep a dedicated section. One clear block: what the browser does / what it
does NOT do (no LLM, no name/NL/model inference, no backend, never has runtime
authority) / what the runtime does (validate, authorize each pure_read node, execute
offline, redacted trace). Links Spec 1277. Why: This section is the page's credibility anchor and the truthfulness test hangs
off its strings.
8. Truthfulness test
Options: lean (load-bearing facts + anti-pattern guards) · comprehensive (pin every
string) · minimal (negatives only). Decision: Lean. Delete the 3 blocks guarding removed features. Keep one block:
asserts the mechanism copy (structural planner, no LLM/NL/model, review gate,
browser=proposer / runtime=authority, no backend); the module calls browserLocalPlan
then executeBrowserComposedWorkflow with mapping_unconfirmed cleared only in the
confirm step; the fail-closed strings exist; negatives — no "AI agent" / "the browser
executes" / "simulated" / "heuristic composition". Why: Guard the real risks (over-claiming, fake-execution language) without pinning
every word — pinning every word is the same friction that let strange wording accrete.
9. Landing state
Options: auto-run the first goal to the review gate · fully inert until a click ·
auto-run the first goal fully through execution. Decision: On load, auto-discover + plan the first goal and draw the proposal in the
graph, then stop at the review gate. Execution and other goals stay on-demand. Why: The page is alive within ~2s (a real discovered plan on screen) without
auto-executing anything; the human confirm step is preserved.
10. PR strategy
Options: one PR · staged (build new, then remove old) · staged (strip first, then
rebuild). Decision: One PR — the whole redesign together. Why: It's a redesign, not an incremental feature; a half-migrated page would be more
inconsistent than today, which is the opposite of the goal. CI (truthfulness + E2E)
proves the replacement.
11. Cleanup scope
Options: keep the pipeline bundle as the offline-planning fixture, delete the rest ·
delete everything authored · keep both bundles + a BundleEmbedder canary test. Decision: Keep public/bundles/discover-real-pipeline/ as the offline browserLocalPlan test fixture. Delete: the single-capability bundle
(public/bundles/discover-real/), src/scripts/discover-real.js, src/scripts/discover-real-pipeline.js, their page UI, and the BundleEmbedder
execution tests. Why: The redesigned page never calls BundleEmbedder; testing it is testing the
SDK. Keep only what a fast offline planning test needs.
Definition of done
/discover is a single flow: 3 goal cards → discover (live catalog → digest-verified snapshot) → deterministic structural plan → explicit review gate → executeBrowserComposedWorkflow → redacted per-node trace.
The G6 graph renders the discovered proposal (nodes + edges + mapping annotations) and recolours through planned → reviewed → executing/succeeded/failed from the real ComposedWorkflowTrace.
On load, goal 1 auto-discovers + plans to the review gate; execution and goals 2–3 are on-demand.
Goal 3 produces "no structural candidate" as a designed, non-error outcome.
Hero: "Watch a goal get planned and executed — for real" + precise mechanism subhead. No "Live catalog data. Heuristic composition. Simulated execution." anywhere.
Compact live stats strip retained; per-run cards for used capabilities deep-link to real contracts; no persistent card grid.
Dedicated transparency section rewritten for the one flow (browser does / doesn't / runtime does), links Spec 1277.
Removed: Derived heuristic, Simulated animation, both authored-Real demos, discover-real.js, discover-real-pipeline.js, public/bundles/discover-real/, their tests. public/bundles/discover-real-pipeline/ kept as the offline planning fixture.
tests/discover-truthfulness.test.mjs reduced to one lean block per decision 8; obsolete blocks deleted.
E2E rewritten: one spec covering plan-on-load → review → execute → terminal: succeeded, plus the no-candidate goal.
npm test, npm run build, npm run test:e2e green; browser-verified; deployed.
One PR. PR body states what the page now does end to end and what was removed.
Non-goals
Auto-executing without a human confirm; an LLM / NL goal parser; streaming per-node
execution (the SDK returns the trace whole); keeping any authored-bundle mode; a traverse-cli serve / backend.
Related
website#68 (runtime-discovered Phases 1+2 — shipped, this consolidates the page around
it), #63/#65/#67/#72/#73, Spec 1277-browser-local-workflow-composition, ADR-0062, traverse-embedder-web@0.9.0, discussion #1102, traverse#1150.
Why
/discovergrew layer by layer — Live catalog fetch, Derived name-heuristic graph,Simulated idle→active→complete animation, Real single-capability execution, Real
3-capability authored pipeline, Runtime-discovered plan→review→execute. Six overlapping
stories, inconsistent, and the copy no longer matches what the page does (the hero still
says "Heuristic composition. Simulated execution."). Now that the real
runtime-discovered loop works (
traverse-embedder-web@0.9.0, Spec 1277), collapse thepage to that one flow, keep the graph, and make it showcase real stated goals being
discovered, planned, reviewed, and executed against the live registry.
Decision log (brainstorm 2026-09-09)
1. Scope of the cut
Options: collapse to the runtime-discovered flow only · keep authored-Real as a
"canned" tier · quarantine Derived+Simulated as a labelled illustration.
Decision: Collapse to one flow. Cut Derived, Simulated, and both authored-Real
demos. A single-capability goal naturally produces the "1 capability" case, so the
authored demos are redundant.
Why: The user's complaint is inconsistency and strange wording; one mechanism is
the only way to fix that. "Only the real thing."
2. What the graph renders
Options: the plan + live execution in one graph, three phases · graph shows
executed result only, plan in a side table · keep the existing Goal→system→chain→Result
layout wired to real data.
Decision: One graph, three phases — planned (mappings unconfirmed) → reviewed →
executing/succeeded/failed, driven by the real
ComposedWorkflowTrace.Why: The graph you review is the graph that runs — one honest artifact; directly
delivers "watch goals execute". Note:
executeBrowserComposedWorkflowreturns the wholetrace at once, so phase 3 is a fast staggered reveal of a real result, not a live
stream.
3. Goals UX
Options: goal gallery, on-demand run · auto-cycle pausing at each gate · two goals
side by side.
Decision: A row of 3 preset goal cards. Click one → discovery → plan → review gate →
(click to confirm) → execution. One goal at a time, visitor-driven.
Why: Respects the explicit Spec-1277 review gate (the confirm click is itself part
of the showcase); auto-cycle can't auto-execute without weakening the governance
property.
4. Goal set
Options: 3 goals (multi-node, single-node, no-plan) · 4–5 goals all producing a plan
· 2 goals.
Decision: 3 goals — one that discovers the multi-node chain
(
period.finalize → summary.aggregate → uncertainty.scoreor the subset the plannerreturns), one that discovers a single capability, one that legitimately finds no
structural candidate, shown as a real outcome, not an error.
Why: Covers the range in 3 cards; the no-plan case honestly shows the planner only
chains what structurally fits — it doesn't invent.
5. Hero framing
Options: lead with the action ("Watch a goal get planned and executed — for real")
· lead with the trust boundary ("The browser proposes. The runtime decides.") · plain
and functional.
Decision: Lead with the action. Subhead states the mechanism precisely: the browser
fetches the live registry, a deterministic structural planner (no LLM, no
name-matching, no NL) proposes a workflow, the visitor reviews it, the governed
runtime executes it in the tab.
Why: The page's job is to showcase goals executing; the governance points are the
why it's impressive and belong in the immediate subhead. Cleanly replaces the false
Live/Heuristic/Simulated headline.
6. Live-registry element
Options: compact stats strip + per-run capability cards · drop it, links in the
graph · keep the full browsable card grid.
Decision: Keep the live "N published versions · M capabilities · K namespaces" line.
Drop the persistent grid. After a run, show cards only for the capabilities actually
used, each deep-linking to its real registry contract.
Why: The stats are cheap proof the whole thing runs on real published
infrastructure; per-run cards ground the abstract graph in real contracts without a big
persistent widget.
7. Transparency section
Options: keep a dedicated section rewritten for the one flow · fold into hero +
inline annotations · replace prose with a trust-boundary diagram.
Decision: Keep a dedicated section. One clear block: what the browser does / what it
does NOT do (no LLM, no name/NL/model inference, no backend, never has runtime
authority) / what the runtime does (validate, authorize each
pure_readnode, executeoffline, redacted trace). Links Spec 1277.
Why: This section is the page's credibility anchor and the truthfulness test hangs
off its strings.
8. Truthfulness test
Options: lean (load-bearing facts + anti-pattern guards) · comprehensive (pin every
string) · minimal (negatives only).
Decision: Lean. Delete the 3 blocks guarding removed features. Keep one block:
asserts the mechanism copy (structural planner, no LLM/NL/model, review gate,
browser=proposer / runtime=authority, no backend); the module calls
browserLocalPlanthen
executeBrowserComposedWorkflowwithmapping_unconfirmedcleared only in theconfirm step; the fail-closed strings exist; negatives — no "AI agent" / "the browser
executes" / "simulated" / "heuristic composition".
Why: Guard the real risks (over-claiming, fake-execution language) without pinning
every word — pinning every word is the same friction that let strange wording accrete.
9. Landing state
Options: auto-run the first goal to the review gate · fully inert until a click ·
auto-run the first goal fully through execution.
Decision: On load, auto-discover + plan the first goal and draw the proposal in the
graph, then stop at the review gate. Execution and other goals stay on-demand.
Why: The page is alive within ~2s (a real discovered plan on screen) without
auto-executing anything; the human confirm step is preserved.
10. PR strategy
Options: one PR · staged (build new, then remove old) · staged (strip first, then
rebuild).
Decision: One PR — the whole redesign together.
Why: It's a redesign, not an incremental feature; a half-migrated page would be more
inconsistent than today, which is the opposite of the goal. CI (truthfulness + E2E)
proves the replacement.
11. Cleanup scope
Options: keep the pipeline bundle as the offline-planning fixture, delete the rest ·
delete everything authored · keep both bundles + a BundleEmbedder canary test.
Decision: Keep
public/bundles/discover-real-pipeline/as the offlinebrowserLocalPlantest fixture. Delete: the single-capability bundle(
public/bundles/discover-real/),src/scripts/discover-real.js,src/scripts/discover-real-pipeline.js, their page UI, and theBundleEmbedderexecution tests.
Why: The redesigned page never calls
BundleEmbedder; testing it is testing theSDK. Keep only what a fast offline planning test needs.
Definition of done
/discoveris a single flow: 3 goal cards → discover (live catalog → digest-verified snapshot) → deterministic structural plan → explicit review gate →executeBrowserComposedWorkflow→ redacted per-node trace.ComposedWorkflowTrace.discover-real.js,discover-real-pipeline.js,public/bundles/discover-real/, their tests.public/bundles/discover-real-pipeline/kept as the offline planning fixture.tests/discover-truthfulness.test.mjsreduced to one lean block per decision 8; obsolete blocks deleted.terminal: succeeded, plus the no-candidate goal.npm test,npm run build,npm run test:e2egreen; browser-verified; deployed.Non-goals
Auto-executing without a human confirm; an LLM / NL goal parser; streaming per-node
execution (the SDK returns the trace whole); keeping any authored-bundle mode; a
traverse-cli serve/ backend.Related
website#68 (runtime-discovered Phases 1+2 — shipped, this consolidates the page around
it), #63/#65/#67/#72/#73, Spec
1277-browser-local-workflow-composition, ADR-0062,traverse-embedder-web@0.9.0, discussion #1102, traverse#1150.