This repository has been archived on 2026-10-08. You can view files and clone it. You cannot open issues or pull requests or push a commit.
Files
maestro/web
naps62-yolo 0f3770f711
ci / rust (push) Failing after 5m5s
feat(maestro-tui): CatalogStore over WS /api/events (NAP-278)
CatalogStore is the TUI's view of the daemons-and-sessions tree, backed by
`WS /api/events` on the local daemon. The daemon's WS opens with a Snapshot
frame, so that's bootstrap; subsequent frames are deltas. No separate REST
round-trip needed.

Surface:
- `apply_event` — pure, used by tests directly and by the WS loop.
- `snapshot()` — cheap O(d+s) read returning sorted Vec views + monotonic
  version for cheap render staleness checks.
- `wait_for_initial_snapshot` / `changed` — render-loop wakeups.
- `run_events_loop(ws_url)` — long-running task with exponential backoff
  (1s → 30s, ±25% jitter). Reconnect re-sends a fresh Snapshot, which
  reconciles state without server-side replay.

8 unit tests + 1 axum WS round-trip integration test passing.
2026-05-28 22:08:06 +00:00
..

maestro-web

Browser UI for Maestro. Connects to the registry HTTP/WS API for the catalog and to individual daemons (via direct WebSocket) for terminal I/O.

Framework choice: vanilla TypeScript

No frontend framework. The UI is small enough that the cost of pulling in Preact / Solid / Leptos doesn't pay back. xterm.js does all the heavy rendering; everything else is a session tree and a spawn form, both trivial in plain DOM.

This decision is non-architectural — swap in a framework later without touching the registry or daemon if needed.

Layout

src/
  main.ts        # entry point, hash-route dispatch
  api.ts         # registry HTTP API client
  events.ts      # `/api/events` WebSocket subscriber
  catalog.ts     # session tree view (groups by metadata.label)
  attach.ts     # xterm.js + daemon WS attach view
  spawn.ts       # spawn-session modal
  types.ts       # mirror of `maestro-protocol` JSON shapes
  styles.css     # mobile-first base styles

Routing is hash-based:

  • #/ → catalog
  • #/attach/<session-id> → terminal

This keeps the registry's static handler dumb (no SPA fallback needed). Concurrent attaches: open the same #/attach/<id> URL in another tab.

Dev

pnpm install
pnpm dev      # http://localhost:5173, proxies /api → http://127.0.0.1:8080
pnpm build    # → dist/, embedded into the registry binary at cargo build time

The Vite dev server proxies /api and the events WebSocket to a maestro-registry. Default is http://127.0.0.1:8080; point it elsewhere by exporting MAESTRO_REGISTRY before pnpm dev:

MAESTRO_REGISTRY=https://maestro-registry.example.com pnpm dev
# Daemon-facing URL also works — `wss://...` is rewritten to `https://...`
# and a trailing `/daemon` is stripped.
MAESTRO_REGISTRY=wss://maestro-registry.example.com/daemon pnpm dev

Direct daemon WS connections (for attach) bypass the proxy and use the URL returned by GET /api/sessions/:id/connect-info.

Production

pnpm build writes the bundle to web/dist/. The Rust registry crate embeds that directory via rust-embed at compile time and serves it from /. See crates/maestro-registry/src/web_assets.rs.