Skip to content

Platform Admin Overview

This page is the present-state map for everything else in this section.

Two views, one platform

The platform shell is at /apps/web/. It serves two audiences:

  • Signed-in users see their account: Devices they paired, Spaces they own, runtime cards under their authority root. This is the present-state view, implemented and live on hivecast.ai.
  • Platform admins need every account: cross-principal Device list, Space list, deployment health, audit trails. This is the target view; the data is in system.auth and system.devices but no admin UI consumes it across principals.

Today, an operator who needs the admin view either invokes ops directly via matrix invoke or inspects state files. There is no separate admin dashboard URL.

What exists today

Live on hivecast.ai

Per the latest P1.22 progress notes:

  • Device list (signed-in user's own Devices) with online/offline/revoked, last-seen, route-key/Space-path links, runtime host count, runtime count, web app count.
  • Per-Device cards for Chat, Director, Edge, Inference Settings with route-plan diagnostics.
  • Action row: Open Chat, Open Director, Open AI Providers, Open Edge, Connect Device.
  • Reachability probes: bus-auth + per-actor request/reply health.
  • Live route-plan diagnostics with routeSource / targetSource provenance.

Operator-level via CLI

bash
# Cross-principal listing
matrix invoke system.auth auth.principal.list '{}'

# Cross-principal Device fleet
matrix invoke system.devices devices.list '{"includeOffline":true}'
# (today scopes by default to caller; loopback bypasses)

# Direct namespace inspection
matrix invoke system.auth auth.namespace.list '{"principalId":"p_xxx"}'

# Direct Host Link list
matrix invoke system.auth auth.hostLink.list '{"principalId":"p_xxx"}'

Operator-level via state files

The platform Host's <host-home>/state/auth-state.json is the source of truth for principals, Spaces, namespace claims, Host Links, sessions revoked, and pending OAuth states. Operator-readable, operator-editable.

The runtime records are at <host-home>/runtimes/*.json.

What does NOT exist

The pages in this section enumerate what an admin dashboard should show. None of them are implemented as UI today. They are documented so:

  • Designers planning the admin dashboard have a coherent target.
  • Operators know what they would have if the dashboard existed (and how to do it manually today).
  • The schema/API gaps are visible (some pages are blocked on auth.space.list, auth.principal.suspend, etc.).

Specifically not implemented:

  • Cross-principal Device fleet view in UI.
  • Cross-principal Space list in UI.
  • Deployment profiles + rollout orchestrator (per Deployments).
  • Audit log viewer / export.
  • Billing tier UI.
  • Roles + permissions UI.
  • Secrets management UI.
  • Break-glass procedures (formalized).

Mapping gaps to ownership

GapWorkstream / loose-end
Device fleet viewP1.16 (Devices ontology), P1.22 (dashboard parity)
Space listnew; downstream of P1.23f (spacePath/authority)
Deployments / rollouts / rollbackWORKSTREAMS/docker-npm-parity/
Audit lognew (no current owner)
Billingnew; depends on Stripe integration
Role/permission/secrets UItied to system-security + system-factotum UI work
Break-glassnew

How to read the rest of this section

Each Operations page documents the target user flow for an admin task and the present-state CLI/state workaround. Each Security page documents the target model and the present-state defaults.

Reference pages document data sources — the routes, ops, and stores an admin dashboard would consume.

See also

Source: WORKSTREAMS/loose-ends/items/P1.22-dashboard-device-navigation-edge-parity.md is the longest single record of present-state dashboard work. WORKSTREAMS/loose-ends/INDEX.md is the live ledger.