Runtime Dashboard Design

Goal

Add a lightweight local dashboard for runtime memory debugging. The dashboard should make Zaxy's Eventloom capture, graph projection, retrieval diagnostics, and provenance visible without introducing a second mutation path.

Scope

This slice builds a read-only live local web app for the active workspace. It focuses on runtime memory and debugging: Eventloom sessions, graph projection health, memory checkout diagnostics, recent observations, and interactive graph inspection.

It does not build a hosted multi-tenant dashboard, graph editing tools, memory invalidation workflows, compaction controls, feedback submission, or codebase-intelligence visualization. Those can be added later as explicit follow-up slices.

Architecture

Add a separate dashboard command:

zaxy dashboard --host 127.0.0.1 --port 8765

The command starts a localhost-only web server with static UI assets and a small read-only JSON API. It should not run inside the MCP server by default and should not append to Eventloom or mutate Neo4j.

Backend:

Frontend:

Primary tabs:

Workspace And Session Scope

zaxy dashboard shows only the active workspace by default. It must not crawl local project directories, discover unrelated .eventloom folders, or merge projects implicitly.

Default resolution:

  1. current working directory
  2. workspace root
  3. .eventloom under that workspace, unless overridden by config or CLI
  4. selected session/domain using the same workspace-neutral defaults as zaxy serve
  5. matching Neo4j graph projection filtered by session/domain

Explicit overrides:

zaxy dashboard --workspace /path/to/project
zaxy dashboard --eventloom-path /path/to/project/.eventloom
zaxy dashboard --session-id default
zaxy dashboard --domain my-project

The dashboard header always shows the resolved workspace, Eventloom path, domain, session, read-only mode, and Neo4j connection status.

An all-project dashboard is out of scope for the MVP. If added later, it should require an explicit workspace registry or command-line flag.

Graph Model

The graph tab is for runtime memory debugging, not arbitrary Neo4j browsing.

Initial graph views:

Graph interactions:

Scale constraints:

Read-Only API

All MVP endpoints are GET and scoped to the resolved workspace/session/domain:

GET /api/status
GET /api/sessions
GET /api/events?session_id=&type=&actor=&q=&limit=&cursor=
GET /api/checkout?session_id=&query=
GET /api/graph/summary?session_id=
GET /api/graph/neighborhood?session_id=&node_id=&view=&hops=&limit=
GET /api/graph/search?session_id=&q=&view=&limit=
GET /api/graph/path-to-event?session_id=&node_id=&limit=

Event panels read from Eventloom logs. Status panels reuse existing memory status, doctor-style checks, graph projection status, and inferred-edge status. Graph panels read from Neo4j through read-only query methods. Checkout panels use the same policy module as MemoryFabric and MCP checkout so the dashboard shows the same trust guidance that model-facing interfaces receive.

The frontend polls status and event data periodically. Graph requests are user-driven to avoid accidental large reads.

Read-Only Enforcement

The dashboard must be read-only by construction:

Any future remote mode must be a separate design with authentication and tenant scoping.

Error Handling

The dashboard should remain useful when one layer is unavailable:

Testing

Tests should cover:

Integration tests with real Neo4j can be marked integration; unit tests should mock graph access by default.