Task: Serve the services roster

The services screen shows the installation as a roster: one row per expected instance, kept whether it reports or not, with a state word for each. The screen needs two reads and neither exists (The services roster has no read). The expected services and their replica counts live in the service registry, a code-generation model for the deployment tooling with no operation. The states beyond running have no source at all: running means a sample arrived within five minutes, and stopped or missing are answerable by nothing. This task serves the roster: the expected rows with their replica counts, and the last report of every instance at any age, so a quiet instance keeps its row with the age of its last report.

• A read serves the installation's expected services and their replica counts, from the service registry.
• A read serves the last report of every instance at any age, so running, lost and missing each have a source. Telling a graceful stop from a lost instance moved to Record service starts and stops on 2026-10-06, because heartbeats alone cannot.
• The reads carry the permission the journey records, or the task says why not and links the tree-wide capture.
• The capture The services roster has no read moves out of the inbox with this task's evidence.

The data shape. The screen reads one list of roster slots, ordered by service name and then slot. A slot is one expected instance of one service:

A service expects replicas slots. Its instances are ranked by their last report, newest first, and the newest replicas of them fill the slots. An instance that reported within the running window is running; one that reported earlier is lost; a slot no instance fills is missing. The instance id is a fresh UUID at every start, so an older instance ranked past replicas is a restart's leftover and is not shown.

Where the roster comes from. The registry is a codegen model, and codegen already renders its database identity into SQL (users, grants, accounts, roles). The expected services follow the same path. A new archetype, ores.sql.service.expected_services_populate, renders every enabled registry entry into ores_telemetry_expected_services_tbl (service_name, replicas). The table name falls under the telemetry service's existing ores_telemetry_ grant. A compiled table in the telemetry binary was the alternative; the database keeps the roster queryable from psql and follows the registry's existing precedent.

The read. A new subject, telemetry.v1.services.roster, carries the slots. One SQL function ranks the latest report per instance at any age against the expected table, so the ranking runs where the index is. telemetry.v1.services.list keeps its five-minute meaning, and the running window becomes one named constant that both reads share.

The permission. Both reads check telemetry::samples:read. The seed grants it to SuperAdmin (through *) and to service roles only, which matches the access model: the installation screens are the system administrator's alone.

Units, each ending in a check:

1. The table, the archetype and the generated populate. Check: codegen renders the populate byte-stable; the drift checks pass.
2. The roster messages in the telemetry model; regenerate the C++ and TypeScript protocol. Check: generated code compiles; the drift sweep is clean.
3. The SQL function, the repository read, the handler, the subscription, and the permission on both reads. Check: repository tests for running, lost, missing and a restart's leftover; a refused caller.
4. Build and ctest. The schema change moves the database fingerprint, so the live check needs a database recreate, which is the operator's call.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

The table that came before. The decommissioned controller kept a service table, ores_controller_service_definitions_tbl, with desired_replicas, enabled, args_template and a restart policy. Story Process supervisor config passthrough gap dropped it on 2026-08-07 (commit 6610f847fd), once systemd owned supervision. The reason was duplication: its rows were seeded by hand beside the registry, so a new setting had to be fixed in several places, and service_registry.org became the one source that compass systemd generate reads. The expected-services table does not restore that: it holds only the service name and its replicas, codegen renders it from the registry, and nothing but the roster read uses it. The registry stays the one source.

Stale inventories on main. Regenerating the physical-space inventories for the new archetype also rewrote nine other inventory pages whose archetypes landed without a regeneration. Those rewrites are left out of this change, because they belong to the components that added the archetypes.

The capture names the two candidates for the state source — a state read, or the latest sample per instance at any age — and the task settles which. The registry already holds the truth the expected rows need: every service, its replicas and its enabled flag, one read away.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The roster is served. telemetry.v1.services.roster answers with one slot per expected instance of every enabled registry service, and each slot says running, lost or missing, with the instance's last report at any age. The expected services come from the registry: a generated table carries each service's replicas, its display name, one sentence on what it does, and its service account. Both liveness reads check telemetry::samples:read.

Four changes joined the task at the operator's word on 2026-10-06. Every service account carries a human-readable name (for example Analytics Service) in place of its username. Every registry service account carries a picture, a Fluent UI icon from the system avatars dataset, and the two administrators' PNG pictures became icons from the same set. The roster's quiet state is called lost rather than stopped, because heartbeats cannot tell the two apart.

On the running fleet the roster read 23 of 25 expected instances as running. The other two are real findings: ores.storage.service and the web BFF publish no heartbeat, so they read as missing while systemd runs them. Record service starts and stops owns that fix, beside the graceful stop.

Not proven here: a NATS request to telemetry.v1.services.roster from a signed-in client, and a refused caller. The handler is built and the shared authorise helper refuses a caller without the permission, but no test drives the subject; the screens task is its first client.