Workbench redesign: make dev mode an application explorer with live route rendering, MCP/hooks traces, and embedded host sessions

[ScriptedAlchemy]

Problem

The current Workbench exposes a large number of framework-oriented pages (Overview, Routes, MCP, Hooks, Playground, Artifacts, Comparisons, Evals, Logs, Hosts, etc.) and much of the useful application behavior is split across them.

That makes the dev experience feel like an administrative console for Agent Bundle internals rather than the dev server for the plugin being built.

For a meta-framework whose product intent is roughly "Next.js for agent-host plugins", the default development experience should answer four questions immediately:

1. What surfaces does my plugin expose?
2. What does this route actually render/return?
3. What happens when Claude/Codex/Cursor invokes it?
4. Which hooks/events/MCP calls fired, in what order, with what context/result?

Today the Routes page is primarily a table/catalog with source/config/input information. Tool routes can hand off to a separate MCP session, while non-tool routes often stop at validation. Hooks, MCP, logs, runtime/App preview, and host behavior live in separate top-level pages. That is technically powerful but cognitively fragmented.

Direction

Reframe Workbench as an application explorer + live host lab over the canonical Application IR / manifest from #592.

The primary UI should be centered around one navigable tree of the plugin's actual surfaces, not around Agent Bundle subsystems.

Illustrative shell:

┌─────────────────────────────────────────────────────────────────────────────┐
│ cargo-hauler                                      build ✓  Claude ● Codex ○ │
├──────────────────────┬─────────────────────────────────────┬────────────────┤
│ APPLICATION          │ ROUTE / SURFACE                     │ INSPECTOR      │
│                      │                                     │                │
│ MCP                  │ hauler_status                       │ Input          │
│  Tools               │                                     │ Context        │
│   hauler_status  ◀   │ [ rendered Agent document ]         │ Trace          │
│   hauler_request     │                                     │ Projection     │
│   hauler_result      │ daemon running ...                  │ Raw MCP        │
│  Resources           │ ...                                 │ Source         │
│  Prompts             │                                     │                │
│  Apps                │ ─────────────────────────────────── │                │
│   dashboard          │ Structured result                   │                │
│                      │ { ... }                              │                │
│ Events / Hooks       │                                     │                │
│  session/start       │ [ Run ] [ Open in host ]            │                │
│  tool/before         │                                     │                │
│  tool/after          │                                     │                │
│  stop                │                                     │                │
│                      │                                     │                │
│ CLI                  │                                     │                │
│  request             │                                     │                │
│  status              │                                     │                │
│ Scripts              │                                     │                │
├──────────────────────┴─────────────────────────────────────┴────────────────┤
│ TRACE  session/start → tool/before → tools/call hauler_status → tool/after │
└─────────────────────────────────────────────────────────────────────────────┘

The exact visual design is open. The information architecture is the important part.

---

1. One application navigation tree

Replace most top-level product navigation with a route/surface tree derived from the compiled application graph.

Suggested groups:

MCP
  Tools
  Resources
  Prompts
  Apps

Events / Hooks
  session/start
  agent/start
  tool/before
  tool/after
  stop
  ...

CLI
Scripts
Skills
Rules / Commands

Each leaf is a first-class application surface.

Selecting a leaf opens the same central route workspace regardless of kind.

Do not make users think "Routes page vs MCP page vs Hooks page" to inspect one logical route.

Keep framework/admin views secondary

Artifacts, diagnostics, projection comparisons, eval management, raw logs, and build internals remain useful, but should move behind an Inspect, Build, or advanced/devtools area instead of defining the primary navigation.

2. Render the route as the primary result

For executable/rendered routes, the center pane should show what the plugin author actually created.

For a tool route:

Input controls
   ↓
Run
   ↓
Rendered Agent Document
Structured result
Metadata
Progress stream

The rendered Agent Document should be visually rendered, not primarily shown as JSON/protocol envelopes.

Allow tabs/toggles for:

• Rendered
• Structured result
• Raw AgentDocument
• MCP projection
• CLI projection, when available

But Rendered should be the default.

This is analogous to a web framework dev server showing the page before showing request headers or compiled chunks.

3. Every executable route should be directly runnable

The current Routes UX has a significant distinction where tools can open in MCP while other route kinds often provide validation only.

Workbench should have one invocation abstraction capable of running any route that Agent Bundle can execute safely in dev:

• MCP tools;
• prompts/resources where meaningful;
• CLI routes;
• scripts;
• semantic event routes/hooks;
• App/browser routes;
• future page routes.

For event routes, provide generated event-input forms plus host fixtures/presets:

Event: tool/before
Host fixture: Claude | Codex | Cursor | Canonical
Payload: {...}

[ Run event ]

Then render:

Canonical input
Observed request context
Providers
Returned decision / Agent document
Projected Claude hook result
Projected Codex result
Projected Cursor result

4. Treat MCP as a route projection, not a separate product page

The existing MCP tooling is extensive and should be reused, not discarded.

Move its useful pieces into contextual panes around MCP surfaces:

When selecting MCP > Tools > hauler_status:

• list schema/config;
• invoke it directly;
• render the result;
• show structuredContent/content/_meta;
• show MCP protocol trace;
• preview its bound MCP App;
• inspect/list related resources/prompts;
• optionally open the full raw MCP session inspector.

The standalone "MCP page" can survive as an advanced protocol session view, but normal tool development should not require navigating away from the route.

5. Treat hooks/events the same way

Hooks should appear beside tools in the application tree.

Selecting Events > tool/before should show:

• semantic event name;
• source;
• supported host projections/capabilities;
• canonical payload schema;
• host-specific input examples;
• Run button;
• rendered/context result;
• host-lowered hook response;
• recent live invocations of that hook.

The current separate Hooks area becomes a contextual event simulator/live history rather than a parallel navigation universe.

6. Add a unified live invocation trace

The most useful debugging surface is not a generic log stream. It is a correlated timeline of application activity.

For example:

22:41:04.101 Claude session started
22:41:04.118 event session/start
               context.host = claude
               result = continue + context
22:41:09.532 tool/before
               tool = Bash
22:41:09.541 MCP tools/call hauler_status
               input = {...}
               provider haulerDaemon 3.2ms
               render shell 8.1ms
               render complete 14.7ms
22:41:09.558 tool/after
22:41:09.562 notice delivered

Each trace entry should be clickable and open the corresponding route with that invocation snapshot loaded.

Trace should correlate:

• host session / conversation;
• semantic event routes;
• MCP requests;
• route execution;
• providers;
• state/notices where relevant;
• render events/progress;
• projection/lowering;
• diagnostics/errors.

This should consume the same execution tracing from the one execution kernel described by #592 rather than adding Workbench-only instrumentation semantics.

7. Embedded real host sessions

Add an optional Hosts panel based on PTY + terminal rendering (for example xterm.js or equivalent) so developers can launch real Claude Code / Codex / other CLI hosts already attached to the dev plugin.

Illustrative layout:

Hosts
  Claude ●
  Codex  ●
  Cursor external

┌────────────────────────────────────────────┐
│ Claude                                     │
│ > what cargo jobs are currently running?  │
│                                            │
│ ...                                        │
└────────────────────────────────────────────┘

Workbench/server responsibilities:

• allocate PTY;
• launch the real host process with the dev plugin already installed/attached through the existing stable dev proxy/epoch mechanism;
• stream PTY bytes to the browser terminal;
• resize terminal;
• terminate/restart explicitly;
• correlate the host process/session with the unified invocation trace.

The browser terminal should be a view onto a real local process, not a simulated chat UI.

Security / authority

This is explicitly developer-local functionality.

• no arbitrary remote PTY exposure;
• bind through the existing authenticated foreground dev server;
• explicit host launch action;
• project-root/workspace authority is visible;
• preserve host's own permission/consent behavior rather than bypassing it;
• terminal and route invocation share trace IDs but not hidden credentials/content beyond what the host actually emits.

8. "Open in host" from any relevant route

For a route, provide:

Run directly
Open in Claude
Open in Codex

Open in host should focus/start that host terminal and seed an appropriate developer prompt or invocation context where feasible.

For example a tool could seed:

Call the cargo-hauler hauler_status tool and explain the result.

The important point is not prompt generation. It is making the loop:

route source -> direct run -> real host run -> hook/MCP trace

one click apart.

9. Bound MCP Apps/browser previews to their routes

If a tool has _meta.ui.resourceUri -> dashboard, its App preview should appear directly in the selected tool's workspace.

Likewise selecting the App itself should show:

• actual browser view;
• bound tools;
• live client calls in the same trace;
• structured route data;
• host profile selector where MCP App hosts differ.

Do not require the user to mentally join Routes, MCP, and an App preview page.

This aligns with #564/#594.

10. Make the route URL-addressable

Workbench navigation should map naturally to URLs such as:

/routes/mcp/hauler/tool/hauler_status
/routes/events/tool/before
/routes/cli/status
/routes/apps/hauler/dashboard
/hosts/claude
/trace/<invocation-id>

Exact paths are non-normative.

Benefits:

• refresh preserves context;
• links in diagnostics jump directly to the route;
• trace entries deep-link;
• browser history works;
• tests can address a route deterministically.

11. Simplify the default nav aggressively

Target primary nav should be closer to:

Application
Host sessions
Trace
Diagnostics

with Application expanded into the route tree.

Advanced secondary surfaces can include:

Build / artifact
Projection comparison
Evals
Raw logs
Framework internals

A plugin author should not need to know which internal Workbench subsystem owns a capability.

12. Reuse current Workbench machinery

This is primarily an information-architecture consolidation, not a request to throw away existing implementation.

Existing useful systems include:

• compiled route catalog and generated schema editor;
• MCP session controller;
• MCP App renderer/preview;
• runtime bridge/trace;
• hook simulator/client;
• playground/script execution;
• live host dev proxy/adoption;
• diagnostics/log clients;
• artifact/projection inspection.

The problem is that these currently present as separate products.

Refactor them behind one route-centric shell.

Relationship to #592

This should be the Workbench manifestation of #592.

If #592 says:

one application graph, one execution kernel, many projections

then Workbench should visually present exactly that:

one application tree
      ↓
one selected route
      ↓
run/render
      ↓
inspect projections + live host executions

Workbench must consume the canonical Application IR/manifest and execution trace rather than maintaining independent MCP/hook/playground catalogs where that can be avoided.

Non-goals

• building a fake Claude/Codex chat clone;
• replacing the actual host UIs;
• making PTY hosting part of production plugin artifacts;
• exposing arbitrary system terminals remotely;
• turning Agent Bundle into an IDE/code editor;
• hiding raw MCP/hook protocol data from advanced users.

Acceptance criteria

• Primary navigation is application/surface-centric rather than subsystem-centric.
• MCP tools/resources/prompts/apps, semantic event/hooks, CLI routes, and scripts are navigable in one application tree.
• Selecting an executable route shows its rendered output as the primary result.
• Tools can be invoked without navigating to a separate MCP page.
• Event/hook routes can be invoked with canonical or host fixture payloads and show the projected host result.
• MCP raw protocol inspection remains available contextually/advanced.
• Bound MCP App previews appear from the relevant tool/App route workspace.
• Live route/event/MCP calls produce one correlated trace timeline.
• Clicking a trace entry opens the corresponding route/invocation snapshot.
• Claude/Codex CLI hosts can optionally be launched in authenticated local PTYs embedded in the Workbench.
• Host terminals are attached to the current dev plugin/proxy and their plugin calls appear in the same trace.
• Routes and trace entries are deep-linkable by URL.
• Artifacts/comparisons/evals/raw logs remain available but are secondary developer tooling.
• The redesign reuses existing Workbench controllers/clients rather than duplicating MCP/hook/runtime semantics.

Related: #592, #564, #594, #595, #596.

[ScriptedAlchemy]

Deeper audit against current Workbench + examples/audiobook-curator:

Current UX is capability-rich but workflow-poor

The current rail is organized around Agent Bundle subsystems:

Build: Overview, Routes
Capabilities: Skills, Hooks, Lifecycles, Hosts, Playground, MCP playground
Quality: Evals, Comparisons
Inspect: Artifacts, Logs

That is visible directly in packages/workbench/src/workbench-screen.tsx. This organization makes sense to framework maintainers, but not to a plugin author asking "what does my plugin do and what will the agent see?"

Concrete audiobook-curator example

search_audible.tsx returns a rich Agent document:

<Agent.Result value={receipt}>
  <Agent.Text>{audibleSearchHeadline(receipt)}</Agent.Text>
  <SearchRanking receipt={receipt} />
</Agent.Result>

SearchRanking then renders candidate counts, query info, up to ten ranked headings, edition cards, regional warnings, and a human-review callout.

That authored result is the product. But the current Routes page represents the route primarily as a table row (Route ID, Source, Config and input) plus generated/raw input controls. For a tool, its main action is Open in MCP session; for non-tool/non-CLI kinds the page explicitly says Validation only; this route kind is not invokable from Routes.

So the most obvious day-to-day workflow:

find search_audible
enter title
run
see exactly what the agent will see
change JSX
see it update

is not the primary route experience.

The rendered-document capability exists, but in the wrong place

The Runtime Playground already has machinery to decode stored Flight into a real Agent Document and render it as elements (Document tab). This proves the framework can visually render Agent Documents. But that capability is isolated behind the optional Runtime Playground/history model instead of being the default output pane for every conventional rendered route.

The redesign should extract/reuse this renderer as a normal route-workspace primitive. A route invocation should produce a renderable AgentDocument regardless of whether it came through the special Runtime Playground.

Traces are fragmented by page

The docs explicitly state: Only actions started in Playground join its ordered durable trace. Hook and MCP page operations stay independent even while a Playground session is open.

That is the opposite of what the dev UX needs. A developer running a real host or clicking a tool should be able to observe the resulting sequence without first choosing the special "trace-owning" page.

The unified trace in this issue should therefore be an observation stream over the execution kernel, while "record a reproducible scenario/eval" can remain an explicit opt-in session. Separate observability from durable scenario recording.

Hooks are currently protocol/debug oriented

The Hooks page is strong as a codec debugger: it shows canonical intent/input, host mapping, native input, native output, canonical result, and supports fixture/inline JSON. Keep that capability.

But it should become the Inspector for a selected event route rather than a separate top-level destination. Default view should emphasize the plugin-visible result/decision/context first; canonical/native codec panes should be secondary tabs.

Hosts page is discovery, not host development

The current Hosts/Discovery page is useful for checking host installations, paths, bundle state, durable state, MCP server declarations, and a read-only initialize + tools/list probe. It explicitly cannot call tools.

Rename/preserve this as something like Host diagnostics or an Inspector panel. It is not the developer workflow implied by "Hosts".

A real Host sessions experience should be the PTY-backed Claude/Codex sessions described in the issue, already connected to the dev plugin/proxy, with calls correlated into the live trace.

MCP is over-separated

The MCP page already owns valuable machinery: session controller, protocol trace, App preview, resource handling, consent, Inspector launcher. None of that should be deleted. But normal route development should reuse it contextually.

For an audiobook tool, the developer should not have to understand this navigation sequence:

Routes -> locate tool -> configure input -> Open in MCP session -> MCP playground -> call -> inspect result -> maybe App preview -> Logs/Playground for another trace

It should be:

Application -> MCP -> Tools -> search_audible
                 ↓
            input + Run
                 ↓
        rendered agent response
                 ↓
       [Agent] [Structured] [MCP] [Trace]

MCP is then just one projection tab of that invocation. The full raw MCP playground remains an advanced session tool.

Proposed day-to-day audiobook flow

Application
└─ MCP
   └─ curator
      ├─ Tools
      │  ├─ inventory_sources
      │  ├─ search_audible    ← selected
      │  ├─ identify_audible_sample
      │  ├─ select_audible_edition
      │  ├─ prepare_audiobook
      │  ├─ apply_audiobook_metadata
      │  └─ ...
      ├─ Resources
      ├─ Prompts
      └─ Apps

Center pane:

Search Audible
Search Audible regions and return ranked identity evidence requiring human review.

Title     [ Dune________________ ]
Author    [ Frank Herbert_______ ]
Regions   [ us ] [ uk ] [+]

[ Run ]  [ Run in Claude ] [ Run in Codex ]

Preview
────────────────────────────────────────────
Found 8 candidates for Dune.

Candidates          8
Regions with errors 0
Query               Dune

Rank 1 · score 0.94 · us
┌──────────────────────────────────────────┐
│ Dune                                     │
│ Frank Herbert · narrated by ...          │
│ ASIN ...                                 │
│ ...                                      │
└──────────────────────────────────────────┘
...

[review callout]
────────────────────────────────────────────

Rendered | Structured result | MCP | CLI | Trace

Right inspector:

Route
  src/mcp/curator/tools/search_audible.tsx

Request context
  workspace  /Users/.../library
  host       simulated / Claude
  session    ...

Providers
  library    2.1 ms

Execution
  handler    432 ms
  render     5 ms

Projection
  MCP tool: search_audible
  openWorld: true

Now changing SearchRanking, EditionCard, Callout, or the route JSX has an immediately understandable visual verification loop.

Default surface should optimize for agent-driven development

Most source changes may be written by an agent, but the human review loop is visual/behavioral. The Workbench should therefore optimize for rapid inspection rather than authoring:

1. agent edits plugin;
2. build/HMR succeeds;
3. human opens route from tree;
4. fixture/last input is already present;
5. human presses Run or route auto-replays last safe read-only invocation;
6. rendered output is immediately visible;
7. human can compare Claude/Codex projection or launch the real host;
8. trace makes hidden hooks/MCP/provider activity visible.

This is much closer to the role Storybook/Next dev tools play for UI applications than the current administrative dashboard model.

Information hierarchy recommendation

Primary:

Application
Sessions
Trace
Problems

Inside Application, one route tree owns MCP, hooks/events, CLI, scripts, Apps, Skills, rules/commands.

Secondary/advanced drawer:

Build
Artifacts
Host diagnostics
Protocol inspector
Evals
Comparisons
Raw logs

The existing pages can be incrementally decomposed into these contextual panels instead of rewritten from scratch.

[ScriptedAlchemy]

Follow-up: the route JSX itself should be the primary Workbench rendering source. Agent Bundle already has the right seam: server route JSX decodes into a transport-neutral AgentDocument, and Workbench already has an agent-document-stage.tsx that maps those semantic nodes into browser React UI. The redesign should promote that path rather than inventing a parallel Workbench-specific result model.

Recommended architecture:

route JSX / Server Components
        ↓
RSC execution (same as production)
        ↓
AgentDocument / render-event stream
        ↓
┌─────────────────┬──────────────────┬─────────────────┐
│ MCP projector   │ CLI projector    │ Browser renderer│
└─────────────────┴──────────────────┴─────────────────┘

The browser renderer should be a first-class projection of the semantic AgentDocument tree. Agent.Text, Agent.Markdown, Agent.Context, Agent.Json, Agent.Progress, Agent.Error, resources/images/audio, nested Agent.Result, etc. can each have a rich browser component rather than being shown primarily as protocol JSON. This gives plugin authors one JSX authoring model and lets the Workbench present it nicely.

Do not normally execute arbitrary route Server Component modules directly in the browser. They may import Node-only code, providers, filesystem/daemon logic, secrets, or server-only packages. Execute the route through the existing server/RSC runtime and stream the semantic document to the Workbench. The browser only renders the resulting document.

For pure presentation components, an optional future browser/client compilation path can use Rsbuild resolve/loader layers or aliases, but it should be an optimization/extension rather than the correctness path. The semantic document is the stable boundary.

This also suggests expanding the Agent component vocabulary where useful. Instead of plugin authors hand-building Markdown strings for rich output, support semantic components that lower differently per projection, e.g. Agent.Table, Agent.List, Agent.Code, Agent.Badge, Agent.Section, Agent.Link, possibly Agent.Action. MCP/CLI can lower these to Markdown/text/content blocks while Workbench renders proper DOM components. The key is to keep them presentation semantics, not browser-specific DOM.

For live rendering, Workbench should consume the existing shell | progress | replace | error | complete render-event stream so Suspense/progress appears visually as it does during execution rather than waiting for only the final snapshot.

Acceptance addition for #600:

• Rendered route view uses the actual AgentDocument emitted by production route execution.
• Workbench has a browser renderer registry for AgentDocument node kinds.
• The rendered pane updates from render-event streaming, including progress/Suspense states.
• Raw AgentDocument and MCP/CLI lowered forms remain inspectable as secondary tabs.
• Route modules are not browser-bundled by default; server-only imports remain legal.
• Shared semantic presentation components can have richer browser renderers without changing their agent-facing meaning.
• No duplicate Workbench-specific JSX/result contract is introduced.

[ScriptedAlchemy]

Cleanup/removal pass against the current Workbench surface.

The redesign should not only add the new application explorer; it should explicitly delete the current subsystem-oriented page model where those pages become redundant.

Current top-level pages

packages/workbench/src/workbench-screen.tsx currently exposes:

Overview
Routes
Skills
Hooks
Lifecycles
Hosts
Playground
MCP playground
Evals
Comparisons
Artifacts
Logs

The target should be much smaller:

Application
Sessions
Trace
Problems
Advanced

with the application tree inside Application rather than a separate Routes page.

Remove as standalone top-level pages

Overview

Delete the current dashboard/sitemap role.

BundleWorkflow is mostly links into the other subsystem pages plus capability counters. Once Application is the default landing view, this page has no distinct job.

Keep only useful build/adoption status as compact topbar/status UI or Advanced > Build.

Delete/decompose:

• overview-page.tsx as a top-level page;
• BundleWorkflow action routing;
• overview-only capability summary cards;
• overview-model.ts pieces that exist solely to choose/recommend Workbench pages.

HostAdoptionSection / build-health information can survive as a reusable status panel, not as justification for an Overview page.

Routes

Delete as a standalone table page.

Its useful pieces become the Application explorer:

• route catalog -> application tree;
• generated input editor -> selected route inspector;
• source/config/schema -> inspector tabs;
• route invocation -> central Run action;
• MCP prefill/handoff -> contextual protocol/host actions.

Delete the giant all-routes table once the tree/workspace exists.

Hooks

Delete as a standalone page.

Move hook fixture/canonical/native codecs, simulator controls, and result inspection into selected Events / Hooks route workspaces.

There should not be a separate navigation universe for hooks.

Lifecycles

Delete as a standalone page after its replay functionality is absorbed into event routes and Trace.

lifecycles-page.tsx already renders replay through AgentDocumentStage; useful pieces are:

• native receipt fixture/paste input;
• canonical identity/context;
• lineage;
• native projection;
• deterministic replay.

These belong as Replay / Native tabs on an event route or invocation trace entry, not another top-level product.

Playground

Delete the general-purpose Playground page.

It currently multiplexes script.run, hook.simulate, skill.inspect, mcp.call-tool, and native.prompt. That multiplexing exists because those capabilities were separated elsewhere.

After #600:

• scripts run from their Script route;
• hooks run from Event routes;
• MCP tools run from Tool routes;
• skills are inspected from Skills in the application tree;
• native host prompting moves to Sessions.

Keep durable scenario recording/replay infrastructure only where it serves eval/repro workflows. Do not retain a generic Playground as a second execution model.

MCP playground

Remove from primary navigation.

Normal MCP development moves into the selected MCP route. Preserve the low-level raw session/protocol inspector under something like:

Advanced > Protocol inspector

or a contextual Raw MCP tab.

Do not preserve McpPage as a peer of the Application explorer simply because its controller implementation is substantial.

Skills

Remove the standalone Skills page from primary navigation.

Skills are application surfaces and should appear in the Application tree. Reuse the good existing SkillDocumentPanel implementation there:

• source/generated switch;
• rendered/markdown switch;
• target projection;
• resources;
• eval coverage.

No separate top-level Skills product is necessary.

Rename / repurpose

Current Hosts / Discovery

The current DiscoveryPage is not really "Hosts" in the intended new UX. It inventories installed hosts/bundles, durable-state locations, MCP declarations, and performs a read-only MCP probe.

Rename/move it to:

Advanced > Host diagnostics

The new top-level Sessions page should mean actual running Claude/Codex PTY sessions attached to the dev plugin.

Do not merge host diagnostics with PTY session UI; they solve different problems.

Logs

Remove Logs from primary navigation.

The correlated execution Trace should become the normal debugging surface. Raw producer logs remain useful only when diagnosing framework/build plumbing.

Move the existing filtered log viewer to:

Advanced > Raw logs

Do not duplicate route/MCP/hook execution events into two equally prominent timelines.

Keep, but secondary

Artifacts

Keep functionality, demote to Advanced > Build artifact.

The artifact tree, hashes, provenance, emitted executables, and epoch diff are useful framework/build diagnostics but not everyday plugin development.

Also remove duplicated runtime summaries from this page when the application manifest/tree already exposes the same hooks/MCP/executable inventory. Artifact inspection should answer "what bytes were emitted?", not re-document the application graph.

Evals

Keep as a distinct advanced workflow. Evals have their own lifecycle and durable evidence semantics and are not merely route inspection.

Place under Advanced > Evals or a secondary Quality area.

Comparisons

Keep the comparison machinery, but make it a subview of Evals rather than a top-level page:

Evals
  Runs
  Compare

There is no reason for Comparisons to occupy equal navigation weight with Application/Sessions/Trace.

Resulting information architecture

Application
  MCP
    Tools
    Resources
    Prompts
    Apps
  Events / Hooks
  CLI
  Scripts
  Skills
  Rules / Commands

Sessions
  Claude
  Codex
  external hosts

Trace
  live correlated invocations
  invocation detail/replay

Problems
  compiler/runtime diagnostics

Advanced
  Build artifact
  Host diagnostics
  Protocol inspector
  Evals
    Runs
    Compare
  Raw logs

Code cleanup requirement

This cannot be implemented as "hide old nav links and leave all page architecture intact".

As each capability moves into the route-centric shell, delete obsolete page composition/state and duplicated client/catalog plumbing.

Specific cleanup targets:

• shrink WorkbenchPage from the current subsystem enum;
• remove pagesFor() / generalWorkbenchPages capability-driven page selection once navigation derives from the application graph;
• remove page-recommendation logic from Overview;
• break up the current ~74KB main.tsx shell: route/application workspace, sessions, trace, diagnostics and Advanced areas should own their own controllers;
• eliminate duplicate routes / hooks / lifecycles / playground catalogs when canonical Application IR + manifest can supply the surface graph;
• merge Playground's operation-specific execution paths into route invocation/session APIs, then delete unused playground operation selection UI;
• delete standalone page CSS/components after their useful panels have been extracted;
• update Workbench surface/capability tests so they assert application nodes/features rather than a fixed list/order of subsystem pages;
• remove hash-only page routing (#hooks, #mcp, etc.) in favor of actual deep route/session/trace URLs.

Acceptance additions

• Overview, Routes, Hooks, Lifecycles, Playground, and standalone Skills no longer exist as top-level Workbench destinations.
• MCP playground is advanced/contextual protocol inspection, not primary navigation.
• Existing Hosts discovery UI is renamed/demoted to Host diagnostics; Sessions means real host sessions.
• Logs is demoted to Raw logs; correlated Trace is the normal execution debugger.
• Comparisons is a subview of Evals, not a top-level page.
• Artifacts and Evals remain available under Advanced/secondary tooling.
• WorkbenchPage and pagesFor() no longer model plugin capabilities as a list of product pages.
• Old page-specific controllers/catalogs are removed once their functionality is absorbed; no permanent compatibility shell for the old Workbench IA.
• main.tsx is decomposed substantially rather than accumulating the new explorer alongside all old page orchestration.

[ScriptedAlchemy]

Ruthless UI audit after reading the current pages in detail. The standard should be: does this UI materially help a plugin author inspect a surface, run it, see what it rendered, observe a real host, or verify behavior? If not, remove it from the main product and preferably delete the page architecture rather than merely hiding it.

Keep only four primary jobs

1. Inspect a surface
2. Run it
3. See exactly what it rendered / returned
4. Observe what a real host did

Everything else is secondary evidence.

Current page-by-page verdict

Overview — DELETE as a page

Current Overview mostly summarizes capability counts, build state, host adoption, and links the user to the real pages. The useful content is:

• build status;
• current/adopted epoch;
• contract-gate failures;
• top-level diagnostics.

Those belong in the persistent shell/topbar/Problems panel, not a dashboard the user has to visit.

Remove:

• capability cards;
• "recommended next actions";
• page-level workflow links;
• Overview navigation entry;
• most overview-page.tsx / overview-model.ts UI glue once shell status consumes the useful pieces.

Routes — DELETE as a page, KEEP its useful primitives

The current Routes page has real value hidden inside a catalog table:

Keep:

• application tree data;
• route description/source;
• static config summary;
• generated input controls;
• raw JSON fallback;
• schema/contract information;
• CLI argv preview when useful.

Delete:

• giant route table as the primary experience;
• separate route-group sections;
• Validate input as a main workflow;
• Open in MCP session handoff;
• Validation only; this route kind is not invokable from Routes state.

All of that becomes the selected route workspace. The input editor should directly invoke the selected route.

Hooks — DELETE as a page

The current Hook UI is mostly a codec debugger. Useful pieces:

• canonical fixture generator;
• canonical input editor;
• host projection selector;
• canonical result;
• native input/output;
• diagnostics;
• replay of captured input.

These belong under a selected Events / Hooks > <route> workspace, with the plugin-visible result first and the codec details under an Inspector tab.

The Hook picker itself disappears because the application tree already selects the hook.

Lifecycles — DELETE entirely as a separate product concept

This overlaps heavily with Hooks and Trace. Useful pieces:

• replay an observed native receipt;
• show canonical context/lineage;
• render the AgentDocument;
• show native projected response.

That is just event invocation history + replay. Fold it into:

Event route -> Recent invocations -> select invocation -> Replay
Trace entry -> Replay

There should not be both Hooks and Lifecycles in the user's mental model.

Playground — DELETE as a product

This is the biggest conceptual fat source.

The generic Playground currently multiplexes:

• script.run;
• hook.simulate;
• skill.inspect;
• mcp.call-tool;
• native.prompt;
• durable session/replay/export/eval recording.

Every one of those has a more natural home:

script.run      -> selected Script route
hook.simulate   -> selected Event route
skill.inspect   -> selected Skill
mcp.call-tool   -> selected Tool
native.prompt   -> Host Session
trace/session   -> global Trace / explicit recording

Delete the generic operation selector, target selector, hook/script/skill/MCP catalogs, and Playground-specific information architecture.

Retain the underlying durable recording/replay machinery only if Evals or explicit "Record scenario" uses it. Do not preserve a public Playground just because the machinery exists.

Runtime Playground — KEEP THE ENGINE, DELETE THE PAGE/PRODUCT

The runtime code has genuinely useful machinery:

• execute production RSC route;
• read render events;
• read AgentDocument;
• preserve last-good output during HMR failure;
• App preview lifecycle;
• state reset/fixture support;
• runtime vectors/current-vs-stale evidence.

That should become the route execution engine behind the selected route view.

Delete the idea that the developer enters a separate Runtime Playground to access it.

RuntimeStage itself should also simplify. The current grid of Agent-visible output, Native response, Model-visible output, App preview, etc. is framework-internal evidence. Default selected-route view should be:

Rendered
Structured
Trace

with Native, Model-visible, raw Flight, runtime vector, etc. in Inspector/Advanced.

MCP playground — DEMOTE HARD; possibly remove the page after route integration

There is a lot of valuable protocol machinery here, but very little of it deserves a top-level page.

Keep contextually:

• direct tool invocation;
• resource read;
• prompt get;
• MCP App preview;
• protocol trace;
• task/progress inspection;
• consent handling;
• session restart/cancel when debugging transport behavior.

Delete from normal workflow:

• manual server/target/epoch binding selectors when the selected route already identifies them;
• duplicate tool catalog browsing;
• separate MCP navigation just to call a tool;
• route-to-MCP handoff state.

Long-term the standalone MCP page should survive only as Advanced > Protocol inspector. If all remaining operations can be contextual panels, delete the page entirely.

Hosts / Discovery — CUT MOST OF IT

Current Hosts is actually installation/discovery diagnostics, not host development.

Useful:

• is Claude/Codex installed;
• version/path;
• is the dev plugin attached/current;
• actionable failure reason;
• maybe one MCP handshake health indicator.

Probably unnecessary in normal UI:

• verbose finding tables;
• full bundle-root detail;
• marketplace detail;
• durable-store file listings;
• read-only tools/list catalog;
• redacted launch command/env dump;
• standalone MCP probe result UI.

Most of that can be CLI doctor output or a collapsed Advanced > Host diagnostics panel.

The primary Sessions UI should instead be real PTY-backed Claude/Codex sessions.

Skills — KEEP AS APPLICATION LEAVES, CUT THE PAGE FRAMEWORK

Skills are actual plugin product surface, so they belong in the application tree.

Useful:

• rendered skill document;
• raw Markdown;
• source vs generated target output when they differ;
• diagnostics;
• resource links/tree;
• possibly eval coverage.

Cut:

• separate Skills top-level navigation/product;
• excessive provenance/build ID/details in the default view;
• target selector when there is only one relevant projection;
• always-visible frontmatter dump.

Default selected Skill should simply render the document. Put source/generated diff, frontmatter, resources, eval coverage in Inspector tabs.

Logs — REMOVE from normal navigation

The current Logs page is a generic producer log viewer with producer/level/kind/context filters. This is useful for framework debugging, not normal plugin development.

Normal developers need correlated Trace, not log archaeology.

Keep raw logs only under Advanced > Raw logs, or consider removing the browser UI entirely if CLI/file access plus Trace covers real workflows.

If retained, it should not maintain a competing primary observability model.

Artifacts — KEEP ONLY AS ADVANCED BUILD INSPECTOR

Useful when debugging compiler/package output:

• emitted file tree;
• executable/manifests inventory;
• validation diagnostics;
• source provenance;
• build diff.

Not useful day-to-day:

• SHA-256 everywhere;
• bytes/mode on every row by default;
• runtime hook/MCP tables duplicated from the application graph.

Simplify to a file tree + selected-file metadata, and surface compiler diagnostics in Problems. Keep digests/modes/provenance behind details.

Evals — KEEP, but simplify around suites/runs/results

This is a genuinely distinct workflow and worth keeping.

Core useful UI:

• choose suite;
• run/cancel;
• see cases/trials/outcomes;
• failures;
• evidence;
• compare against another run.

Potential fat:

• too much provenance/evidence metadata expanded by default;
• raw artifacts as first-class cards;
• separate Comparisons product.

Use one Evals area:

Evals
  Suites
  Runs
  Compare

Comparisons — DELETE as standalone page

The functionality is useful. The page is not.

Fold baseline/candidate comparison directly into Evals. Same data, one mental model.

Proposed minimum Workbench

The strongest simplification is even smaller than the earlier proposal:

Application
Sessions
Trace
Problems

Advanced
  Evals
  Artifact
  Protocol
  Host diagnostics
  Raw logs

Application itself contains every plugin-authored surface. There is no separate Routes/Skills/Hooks/MCP/Playground navigation.

Default selected-route workspace

Keep this brutally small:

<route name + description>

[input]
[ Run ] [ Claude ] [ Codex ]

Rendered
────────────────────────
actual AgentDocument DOM
────────────────────────

Rendered | Data | Trace

Inspector drawer only when opened:

Source
Schema
Context
Providers
Projection
MCP/native protocol
Runtime vector
Raw document

For an App route, the center is the App iframe. For a Skill, rendered Markdown. For an event, rendered decision/context. For a CLI/script route, rendered terminal/document output.

Concrete deletion acceptance

• Remove overview page and capability-card workflow UI.
• Remove routes page; extract tree/input/schema primitives into Application route workspace.
• Remove standalone hooks page.
• Remove standalone lifecycles page and fold replay into event route/Trace.
• Remove generic playground page and operation selector.
• Remove Runtime Playground as a navigable product; reuse runtime engine under route execution.
• Remove standalone skills page; Skills are Application leaves.
• Remove standalone comparisons page; fold into Evals.
• Remove logs from primary navigation; assess whether browser raw-log UI is worth retaining at all.
• Remove hosts discovery from primary navigation and cut verbose probe/detail UI; retain only actionable host diagnostics.
• MCP page becomes advanced protocol inspector only, with a follow-up decision to delete it entirely if contextual route panes cover all useful operations.
• Artifact UI defaults to simple emitted tree; hide hashes/modes/provenance/runtime duplication under selected-file details.
• Runtime output defaults to rendered AgentDocument; native/model/raw/runtime identity are inspector details.
• Primary Workbench can be understood without knowing Agent Bundle subsystem names.

The goal should not be "preserve every existing feature somewhere." The goal is to preserve every useful capability while deleting duplicate pages, selectors, catalogs, and presentation models.

[ScriptedAlchemy]

PR 1 of 3 merged: #629 → c9cc7937f on main.

Landed: the new shell (Application · Trace · Problems · Advanced; Sessions is PR 3), the Application tree from the compiled route catalog, the route workspace with Rendered-by-default (the Runtime Playground's Flight→AgentDocument renderer extracted to application/rendered-document.tsx), one invocation API (POST/GET /api/routes/invocations, route.invocation event, AB8231/AB8232/AB8236–AB8238) behind a dev-server backend and an optional devRuntime backend, URL routing for every view (/routes/mcp/<server>/tool/<name>, /routes/events/…, /routes/cli/…, /routes/scripts/…, /routes/skills/…, /trace, /problems, /advanced/*), and the full deletion ledger from the audit (Overview, Routes, Hooks, Lifecycles, Playground, Runtime Playground, Comparisons, Discovery cut to host diagnostics; 231 files, −20k lines net). en + zh docs rewritten; agent-bundle/test inspectWorkbenchSurface now reports the Application tree (breaking, minor).

Self-review (two Sol rounds) fixed five findings before merge, notably: the render child is now packaged (dist/route-invocation-child.js) and proven from an installed tarball; route manifest and invocations are pinned to the last published epoch and answer 409 AB8232 while source is newer than the build; the render child's process tree is reaped after every invocation.

Next: PR 2 — unified live trace (route invocations + MCP protocol + hook receipts + logs on one correlated timeline under /trace).