Story: Document the operations journeys

Five journeys document the operator's view of a running installation: See the running services, Watch the compute grid, Watch the message bus, Read the telemetry logs, and Check the versions and the database. Four are for a system administrator; the last is for any signed-in user. Each follows the User Journey Extraction Standard, and a clickable prototype on a throwaway branch proves the screens.

• The five journeys are user_journey documents in the operations group, each following the User Journey Extraction Standard and passing compass lint.
• Every operation each journey names is checked against the generated protocol and marked exists, partial or missing; every gap is recorded.
• Every telemetry and super-admin screen of the legacy ores.qt client has a disposition: kept, changed or dropped.
• A clickable prototype runs on a throwaway branch and is linked from each journey it proves.

• The catalogue of five journeys was agreed with the product owner before any journey document was written, as the standard requires: See the running services, Watch the compute grid, Watch the message bus, Read the telemetry logs, and Check the versions and the database.
• The journeys form a new operations group. Services and the message bus stay as separate journeys: they answer different questions from different operations.
• The versions journey is for any signed-in user; the other four are for a system administrator.
• The legacy ores.qt telemetry and super-admin inventory lives on the operations group hub. Every screen read has a disposition: covered by a journey, changed, deferred or dropped.
• The database fingerprint has no read operation today; under the accepted design the login answer carries it. The versions journey records the gap, and the prototype settled that the row rides the login answer rather than a read of its own.
• The services screen is a roster: one row per expected instance under its service, and a row never disappears. An instance is running, stopped or missing, in the installation's own words with the shell's existing tones; the instance count warns when a service is short; an older build is prominent, never buried.
• The compute wrappers are the grid screen's. A wrapper runs on a node, so the grid shows it beside the nodes; the services roster shows the installation's services.
• The grid is the installation's, not the tenant's: every tenant's work runs on the same hosts. The tenant filter under the read is a defect, filed as a capture.
• Operations is an area, not tabs: one screen per journey with "Back to operations" navigation, sharing the shell and the footer.

• Host, workunit and app management — the pages behind the grid's read-only view. They belong to Extract the ores.compute user journeys.
• The rest of the per-component extraction, which keeps its tasks under Extract the user journeys that replace the ores.qt screens.
• Implementing the journeys in ores.web for real. The prototype is a throwaway design record, and the story does not merge it.