Task: Build the operations screens in ores.web

The five operations journeys run in ores.web against the real server, as the accepted prototype draws them: the services roster, the whole grid with its node table and wrapper panel, the bus vitals and streams, the logs filter bar, and the versions panels with the footer. The screens ride the journey runtime the Setup group landed, with a hand-written BFF route per screen. Operations is an area the system-administration menu carries: the four installation screens carry "Back to operations" navigation rather than tabs, and the versions screen is offered in every mode, so a tenant administrator and a regular user reach it as well. Where the data-model linkages are not yet closed, the screen states the gap as the prototype does rather than showing a guess.

• The five screens run against the real server on the journey runtime, and no journey entity is added.
• Each screen carries its Related journeys links, and the versions panel reads the database from the login answer with no request of its own.
• The Operations area is reached from the system-administration menu; the four installation screens carry "Back to operations" navigation and no other mode offers them; the versions screen is offered in every mode, so a tenant administrator and a regular user reach it; and every screen carries the footer with both builds.
• Every gap the five journeys record is either closed or stated on the screen, and the statement is recorded.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

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 rows above describe the tree as it stood when the first three screens landed. The message bus and the logs have been inspected but never executed. From that point the workflow changed to implement-and-merge, with a separate hourly job building latest main and running the suites for every PR merged since its last check. The numbers above therefore do not cover those two, and this record says so rather than quoting a suite that never ran against them.

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 five screens are built and on main, across three merges: #2811 carried the area, the versions screen, the services roster and the compute grid, with the platform work beneath them; #2825 carried the message bus; and the logs follow in the last PR of this task.

Each screen runs against the real server on the journey runtime, no journey entity was added, every screen carries its Related journeys links and the footer, the Operations area is reached from the system-administration menu alone, and the versions screen is offered in every mode so a tenant administrator and a regular user reach it.

What each screen states rather than hides is the part worth recording, since the acceptance asks for every gap to be closed or stated:

• The versions screen reads its database from the login answer and makes no request of its own.
• The services roster renders every expected row, quiet ones included, and reads a quiet instance as lost and never stopped, because a heartbeat cannot tell a stop from a fall.
• The compute grid states that its node table is the installation's while the counters above it are computed for one tenant. That is a property of the system, not an artefact of the screen, and the ledger that would change it is a story that is not built.
• The message bus states that its counters are running totals since the server started, so the movement over a range is computed from the samples.
• The logs offer only filter values the store can match. The prototype offered a client source and uppercase levels, neither of which could ever return a row, and the journey forbids offering one.

Three defects surfaced underneath the screens and are corrected rather than carried: node names were identifiers where a person needs a name, the host table grew by a version on every heartbeat, and five environment variables looked authoritative and were inert.

Two deviations, both stated rather than glossed. The Goal says the screens ride the journey runtime; they ride the application's screens and the BFF route pattern, because the runtime is a linear rail and these are read-model screens, which that runtime's own page allows for. And the logs screen does not build the opened-entry detail or the session and account filters, because the accepted prototype does not draw them; the filter bar is the six the task named.