web

Overview ¶

Web dashboard — a read-only live view of the agent, served over HTTP.

Step 2 of the front-end plan. The dashboard is a second subscriber to the event core.Bus (stdout is the first): every event the terminal renders is also pushed to any connected browser over Server-Sent Events. Enable with -serve (defaults to :7777) or -serve :PORT.

Design: this is an instrument panel, not a webpage. Dark, monospace, dense — it mirrors what you watch in the terminal but makes it reachable from another machine on the LAN. The live transcript is the centerpiece; a stats strip and a todo rail frame it. Read-only by design: it observes, it does not drive the agent (driving stays in the terminal/TUI).

Implementation is stdlib net/http + SSE, no framework — the idiomatic choice for a small embedded status server. SSE (not websockets) because the data flow is one-directional (server→browser) and SSE reconnects itself and rides plain HTTP.

Dashboard HTML — served at /. A single self-contained page: no build step, no external assets, inline CSS/JS. Instrument-panel aesthetic: dark, monospace, dense; the live event stream is the centerpiece.

Headless mode — the agent driven solely from the web dashboard.

No terminal reader, no TUI. The loop blocks on browser submissions and runs each as a turn, with all output flowing through the event core.Bus to the dashboard's SSE stream. This is the intended shape for "run it on a box, interact from a browser (phone, laptop) on the LAN": there's no human at the terminal, so there's nothing to select against — the browser queue is the only input source, which makes this the simplest and most robust of the three front-end paths.

Input parity with the REPL: a submitted line is classified the same way (!shell / @file / /command / prompt) so the dashboard user gets the same affordances. Read-only /commands run via the shared dispatcher; stateful ones report that they need the REPL (a headless session can't, e.g., /reload itself).