Skip to content

Dashboard: Runtime hosts

Status: target state. Per-Device RuntimeHostView rendering exists in the user shell. A fleet-wide Runtime Host inventory across principals does not.

Target view

A flat table of every Runtime Host across the fleet:

  • Owning Device, owning principal.
  • Supervisor process metadata (uptime, version, host control mount).
  • Runtime count under this supervisor.
  • Health status (heartbeat freshness, runtime registration completeness).
  • Authority root, wire root.

Drill-in to a Runtime Host shows every runtime it supervises, every app it exposes, route plans, and direct lifecycle controls (start/stop/reload).

What exists today

User-shell RuntimeHostView

Per P1.22 (commit 3f2c06ee), the user shell renders one RuntimeHostView per Device:

  • id: install_<short>:host.control
  • hostControlMount
  • authorityRoot, wire root
  • routeKey, publicNamespace
  • runtime count
  • web app count

Live proof: a Gmail Device shown as 1 runtime host · 8 runtimes · 4 web apps.

Per-Host introspection

bash
# On a Device or the platform Host
matrix invoke host.control status '{}' --home <host-home>
matrix invoke system.runtimes runtimes.list '{}' --home <host-home>

host.control status returns the supervisor's runtime records. system.runtimes runtimes.list returns the bus-registered runtimes. They should match on a healthy Host.

Per-Runtime control

Each runtime exposes a system.runtimes.<runtimeId>.control mount with runtime.health. The dashboard probes these.

What the target needs

  1. Cross-Host introspection. Today host.control is per-Host (each Device has its own). A platform admin needs a single view across every Host. Either (a) a federated query from the platform Host that fans out to per-Device host.control mounts, or (b) a system.devices.runtime-hosts.list aggregator.
  2. Multi-RuntimeHost fixture support. A Device today has one Runtime Host (the Host Service install). The runtime-environment-multi-instance workstream allows multiple per Device. The RuntimeHostView derivation must handle that case (target).
  3. Lifecycle ops at the admin level. Restart a Runtime Host on a Device, scoped to the admin's permission. Today only the Device owner can do this.

How a Device's RuntimeHostView is built

From P1.22 notes:

  1. Read system.devices.devices.list for the principal — yields Devices and their runtime summaries.
  2. For each Device, group runtimes by their supervisor. Today: one supervisor per Device.
  3. Each RuntimeHostView carries id, hostControlMount, authorityRoot, wireRoot, routeKey, publicNamespace, runtime count, web app count.

The aggregator lives in the Web shell's data layer plus a contribution from system-gateway-http's /api/identity/runtime-summary route.

Why this matters

A Runtime Host is the unit of restart. An admin who restarts a Runtime Host cycles every runtime under it — Chat, Director, Edge, inference. Doing this intentionally across a fleet (e.g., to pick up a new version) requires the rollout machinery (target). Doing it one Host at a time requires a cross-fleet view (target). Today both are manual.

Per-Runtime drill

A target sub-view: drill from a Runtime Host into one runtime. Show:

  • Runtime id, mount, package, version.
  • inventory[] — the actor mounts this runtime owns.
  • claims[] — which mount claims this runtime publishes (kind: authoritative, proxy, mirror, local-only).
  • requiredPackages[] — its dependencies.
  • Last heartbeat.
  • Recent log lines.

Today this is matrix invoke system.runtimes runtimes.list '{}' plus log tailing.

Multi-Runtime-Host case (target)

Per the P1.22 closure prerequisites, a Device with multiple Runtime Hosts (e.g., personal Host + per-Space sub-Host) must render two RuntimeHostView groups. Each group has independent app-route attribution and independent restart semantics. The schema and aggregator support this; the test fixture and rendering code do not yet exercise it.

See also

Source: WORKSTREAMS/loose-ends/items/P1.22-dashboard-device-navigation-edge-parity.md for present-state. P1.22a-device-runtime-host-reachability-topology.md for the topology contract.