Skip to content

The Dashboard ​

The dashboard is stepbook's visual inspector — a local React app that reads the same state/ directory the CLI writes. It's where you browse runs, inspect each step's output, compare runs, and run stability and query analyses interactively.

It's optional: everything the dashboard shows is also available from the CLI. But for exploring a pipeline and chasing down "what changed and why," the UI is usually faster.

Launching it ​

sh
stepbook dashboard            # opens http://127.0.0.1:6125
stepbook dashboard -p 7000    # a specific port (strict — errors if taken)

Or, from the stepbook repo itself, npm run dev runs the dashboard against examples/demo and falls through to the next free port if 6125 is busy. The difference: npm run dev is lenient about the port, stepbook dashboard -p <n> is strict — because there you asked for a specific one.

Layout ​

The dashboard has three regions:

  • Left rail — the selected run's trajectory as a tree of nested, selectable nodes, plus a list of recent runs. A straight-line pipeline lists its units; an agent expands into its turns (decide#0, act#0, decide#1, …), and nested calls nest. Selecting a node focuses the canvas on that call; selecting a run points every panel at that run's snapshot.
  • Canvas (the main area) — per-node views of the currently selected node: its input, its output, its source code, and the analysis views.
  • Bottom drawer — addon panels that span the whole run rather than a single node: checks, history, and telemetry.

A project switcher in the top nav lets you point the dashboard at a different stepbook project under your workspace without restarting it.

Stepbook dashboard — main view with the selected step's output in the canvas and Checks in the drawer.

Canvas views (per node) ​

These follow the trajectory node you've selected in the left rail.

  • Input — the exact data that call received: the argument the runner passed when it invoked this unit (for a loop turn, the state at that turn). For the entrypoint node it's the pipeline input. You can pick which input file or run to view.

  • Output — this node's output for the selected run, rendered structurally.

  • Code — the unit's source file, opened read-only. A source-link button opens it in your editor (configurable via editor in the config).

    Code canvas showing the parse step's source file.

  • Compare — diff this node's output between two runs, side by side. The visual counterpart to stepbook snapshot-diff.

    Compare canvas showing FROM/TO snapshot diff with assertion flips and field-drift summary.

  • Stability — run this unit N times (or use the last N historical runs) and see the outputs clustered by similarity, with outliers flagged. The visual counterpart to stepbook variance. Most useful for LLM units. See Drift & Stability.

  • Query — run a query against this node's output and view the result as a table, JSON, or raw value. The Monaco editor is in YAML mode with query-keyword completion — the same StepQL the stepbook q command runs; drop into raw JSONata via the jsonata: field. Saved queries persist per step with their language tag so recall round-trips correctly.

Addon panels (whole run) ​

These live in the bottom drawer and reflect the selected run as a whole.

  • Checks — every assertion result for the run, grouped by node, with failing items expanded inline. The tab carries a live badge when checks are failing.

  • History — every run, newest first; sortable and filterable. Selecting a run here drives the rest of the UI.

    History drawer with a pass/fail bar chart and the run list.

  • Telemetry — cost, latency, token counts, and cache-hit rates over time, drawn from what your units report via ctx.report — summed across a loop's turns. See ctx.report.

Running from the UI ​

You don't have to drop to the terminal to execute the pipeline. The dashboard can trigger runs the same way the CLI does, including the partial-run shortcuts:

  • Run — execute the whole pipeline against the canonical input.
  • Run from here — re-execute from the selected unit onward (maps to --from <unit>).
  • Run unit — re-execute just the selected unit with cached neighbors (maps to --just <unit>).

Because each unit call is cached on its source-file hash, editing a unit file and re-running from the UI re-executes only what actually changed. See The Cache.

Live reload ​

When you edit a unit file or the pipeline while the dashboard is open, it picks up the change without a full page reload — the trajectory tree and source views stay in sync. Re-run from the UI to see the new output.

Next ​

Released under the MIT License.