VIRGO

Hub web dashboard

Source
docs/design/HUB-WEB-DASHBOARD.md
Pinned at
d62e85485903a5537ee2b73c14201597e29bdaa5
sha256
b7f333e51f003db925e73a672fb1481e383f9d00112d4d651e94131eb8051f93

This page is the specification itself, rendered from the pinned source above. Its text is reproduced exactly; only its presentation is added.

Hub web dashboard (v0 draft)

Status: decision consolidation (2026-08-03~04) — pre-implementation.

virgo hub serves a local web page alongside hub services. Purpose: the eyes of the system, and the place where difficult setup happens AFTER onboarding.

Screens

  1. Status — live rendering of virgo status: machines (advertisement freshness), personas (fence, host, model, health), queues/streams, recent lifecycle events. Read-only.
  2. Preferences — user-editable configuration (display, notification, pacing). Writes go through the same mechanized config paths as the CLI. (POST-v1: read-first v1 excludes it; the config path is carried by plan item V2-509.)
  3. Setup checklist (first-class, not an extension) — every deferred-from- onboarding item appears here with its own guided flow: channel credential placement, workspace/project bindings, integrations, per-persona settings. Complete them anytime; the dashboard shows what remains.
  4. Personas — one view per persona for its character overlay, language and tone, channel bindings, role/class/project registration, repository anchor, and retirement. Personas are organized as the root/workspace/project/role address tree with path filters. Its Records tab embeds the reusable record viewer described below.
  5. Knowledge Explorer — browse and search typed records by kind, workspace, and persona; inspect provenance and follow relations such as supersedes, relates, and depends.
  6. Skills — inspect persona, class, and workspace work skills; edit personal skills directly and submit shared class/workspace revisions for approval.
  7. Diagnostics — last admitted inbound and downstream freshness per channel lane, plus the guided one-message check defined in CHANNEL-DIAGNOSTICS.md. The panel renders the same redacted receipt as the CLI and never exposes a bearer, payload, sender, or conversation identifier.

Persona edits and live activation

The dashboard never edits a live materialized persona folder. A change is submitted through the same persona-regeneration API as the CLI, producing a new content-addressed candidate generation. The owner sees its diff and required restart effect. Applying it runs the normal checkpoint -> compose -> audit -> same-identity down/up path; a failed gate leaves the current generation active. Channel rebindings that the runtime contract marks hot-reloadable may take effect without a persona restart, but still produce a durable configuration revision and authority check. The UI states which path a change will use before confirmation.

Reusable record viewer

Knowledge display is one kind-agnostic component, not separate viewers per screen. It renders a metadata header, provenance (who, when, source), body, edge list, search, and filters. The Explorer screen, the Personas screen's Records tab, and record details opened from Status all compose this same component. Adding a node kind requires no viewer rewrite; an optional kind-specific body renderer may enhance, but never replace, the common contract.

The product record schema and materialization boundary are specified in RECORD-GRAPH.md.

Boundaries (binding)

  1. Bound to tailnet/loopback with authentication — never publicly exposed.
  2. Credentials are neither displayed nor editable in the UI.
  3. Status is read-only; every mutation routes through the same mechanized CLI/API paths with their gates — the web UI is never a bypass surface.
  4. UI assets are embedded in the same release SHA as everything else; no separately-versioned frontend.

Workspace isolation

One Virgo installation serves one owner and N workspaces (work domains). The dashboard is a SINGLE instance: workspace appears as a filter/switcher dimension on the status screen and as a tag on setup-checklist items — never as separate per-workspace UIs. Isolation is enforced by capability stamps and the transport's cross-workspace deny, not by UI separation. Persona duties bind to projects inside a workspace. If workspace members ever need access, they get workspace-scoped viewing rights inside the same UI.

Machines are workspace-NEUTRAL resources: they belong to the installation, and a single machine may host personas from different workspaces — placement follows capacity and policy, not workspace isolation. Pinning a workspace to specific machines, if ever needed, is an optional placement constraint, not a structural rule.

Extension candidates (design headroom, not commitments)

  • Prompt-registry review UI (new consent screen -> owner picks -> stored).
  • Onboarding progress view for machines mid-wizard.
  • Pending-approvals view (decisions awaiting the owner).