HiveCast Platform

Appearance

Admin surfaces ​

HiveCast platform admin is partially built. This page enumerates what exists today, what is target state, and where each piece of the target is owned.

What works today ​

The signed-in user shell at https://hivecast.ai/apps/web/#dashboard (or local http://127.0.0.1:3100/apps/web/#dashboard) is the closest thing to a platform admin UI. It currently renders, for the signed-in account:

  • Device list — linked Devices for the principal, with online/offline status, last-seen timestamps, route-key/Space-path link, runtime host count, runtime count, web app count.
  • Per-Device detail — Runtime Host(s), runtime list, app-route cards (Chat, Director, Edge, Inference Settings) with route-plan diagnostics.
  • Live route plans — for each app card, the URL, appName, gateway, target authority root, runtime id, package, asset provider, and routeSource / targetSource provenance.
  • Reachability probes — bus authorization separated from actor request/reply health. The dashboard probes system.runtimes runtimes.list, host.control status, system.devices devices.list, and per-runtime system.runtimes.<runtimeId>.control runtime.health.
  • Action row — Open Chat, Open Director, Open AI Providers, Open Edge, Connect Device. Action hrefs use linked-Space namespace routes when available, falling back to current-host /apps/<app>/ routes.

Source: projects/matrix-3/packages/matrix-web/src/ (the dashboard surface). The 250-line P1.22 progress log in WORKSTREAMS/loose-ends/items/P1.22-dashboard-device-navigation-edge-parity.md is the canonical record of what shipped.

What is not in the user shell ​

The user shell is the user's own view of their own account. It is NOT the platform-operator view. The following platform-operator concerns are not surfaced anywhere today:

  • Cross-principal Device list (every linked Device on the platform).
  • Cross-principal Space list.
  • Deployment profiles, rollouts, rollback orchestration.
  • Audit log viewer / export.
  • Billing tier management.
  • Role assignments.
  • Permission grants.
  • Secrets management UI.
  • Break-glass procedures.

Each of these is documented in Platform Admin, but every page in that section is explicitly target state.

Why platform-admin has its own section ​

The user shell answers "what does my account look like." A platform admin needs to answer "what does every account look like" — Device fleet across users, deployment health across the cluster, security incidents across principals. That is a separate UI surface with separate authorization (admin role) and separate data sources (cross-principal aggregations).

The data is available today through system.auth, system.devices, and system.runtimes — these actors can list across principals when called with appropriate scope. The UI to consume that data is the missing piece.

Loose ends owning the gaps ​

GapOwning loose-end / workstream
Device fleet viewP1.16 (Devices page ontology), P1.22 (dashboard parity)
Deployment profilesWORKSTREAMS/docker-npm-parity/
Rollouts / rollbackWORKSTREAMS/docker-npm-parity/
Audit log UInew (no current owner)
Billing tier UInew (Stripe integration is in ARCHITECTURE-PLATFORM-TOPOLOGY.md §11 as target state)
Role + permission UItied to system-security package design
Secrets management UItied to system-factotum UI
Break-glass proceduresnew (operational runbook target)

WORKSTREAMS/loose-ends/INDEX.md is the live ledger of the launch-readiness state.

Operator workarounds available today ​

Until the admin UI exists, an operator does the following with CLI tools and direct actor invocations:

  • List principals. matrix invoke system.auth auth.principal.list '{}' returns every principal known to the local Host (on the platform Host: every signed-in user).
  • List Devices for a principal. matrix invoke system.devices devices.list '{"principalId":"p_xxx","includeOffline":true}'.
  • Inspect a Device. matrix invoke system.devices devices.get '{"deviceId":"<deviceSlug>"}'.
  • Revoke a Device. matrix invoke system.auth auth.hostLink.revoke '{"hostLinkId":"<id>"}' or POST /api/devices/:deviceId/revoke from a signed-in operator session.
  • Read raw runtime state. Inspect <host-home>/runtimes/*.json and <host-home>/host.status.json on the platform Host.
  • Read auth state. Inspect the JSON state files under <host-home>/state/ (HostAuthStateStore-backed). These are operator-internal, not stable APIs.

These are not user-facing flows. They are how an operator runs HiveCast today.

When the admin surface ships ​

The plan recorded in WORKSTREAMS/loose-ends/INDEX.md is to land platform-admin views incrementally:

  1. Cross-principal Device list — earliest because the data is already in system.devices.
  2. Audit log query API + simple viewer — depends on standardizing the audit event shape.
  3. Deployment profile records + rollout reconciler — requires the docker-npm-parity work.
  4. Role/permission/secrets UI — depends on system-security package design.
  5. Billing — depends on Stripe integration; lowest priority pre-launch.

This page will be updated as each lands.

See also ​

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