system.devices

Status: not consumed by Director today. Director does not call system.devices ops in the current code. The actor exists, owns the Devices facade, and is consumed by matrix-edge and matrix-web. This page documents why Director doesn't and what would change if it did.

What `system.devices` is

CLAUDE.md ("Architecture") and WORKSTREAMS/product-launch/HIVECAST-DEVICE-ENROLLMENT-SPEC.md define system.devices as the product/account-facing Device facade:

devices.list — list linked Devices for the principal/account.
devices.get — single Device record.
devices.heartbeat — heartbeat received from a Device.
devices.runtimes.list / .register — runtimes per Device.

Each entry in system.devices.<deviceSlug> represents a linked compute participant (laptop, workstation, VM, server, container, phone, appliance). The deviceSlug is the stable management projection key under the owning principal/Space.

Why Director skips it today

Director answers actor-namespace questions ("what is this mount, what does it accept"). The Device facade answers product/account questions ("which laptop is this, when did it last heartbeat, what runtimes does it own"). Those are different lenses on the same compute.

Specifically:

system.runtimes answers "which runtimes are running on the Host I'm currently connected to". Director uses this.
system.devices answers "which Devices does my account own across the federation". Director would need account/Space context (matrix-web/matrix-edge already have this) to render anything meaningful.

DirectorServiceTargets.ts does not list system.devices. DirectorRuntimeAdapter makes no devices.* calls (verified by reading the full adapter).

Where Devices lives in the UI today

Local Edge dashboard: matrix-edge package — /apps/edge/.
Cloud dashboard: matrix-web (the platform shell on HiveCast) — /apps/web/.

Both consume devices.list directly and render the canonical Devices page with online/offline/revoked state, runtime grouping, and Device link metadata.

Hypothetical Director integration (target state)

If Director were to surface Devices as a top-level pane, the wiring would look like:

director-devices-shell
└── consumes:
    - system.devices devices.list  → IDirectorDevice[]
    - system.devices devices.get   → IDirectorDevice
    - system.runtimes runtimes.registered → cross-link runtimes by deviceSlug

That is target state, not current code. The current Director surface stops at the Host boundary because that is where its trust model is well-defined: the Director page is talking to one runtime root, served by one gateway, owned by one Host. Cross-Host federation is a different conversation.

Reference

Spec: WORKSTREAMS/product-launch/HIVECAST-DEVICE-ENROLLMENT-SPEC.md
Loose end items: WORKSTREAMS/loose-ends/items/P1.22*.md (dashboard navigation, edge parity).

system.devices ​

What system.devices is ​

Why Director skips it today ​

Where Devices lives in the UI today ​

Hypothetical Director integration (target state) ​

Reference ​