Platform Ops Consolidation

Status: Shipped on 2026-03-07

Recommendation

Keep one consolidated operator shell under Ops > Operations and absorb the useful legacy platform-ops surfaces into it.

• Canonical mount: /ops/operations
• Suggested user-facing title: Operations
• Suggested overview page title: Platform Ops

This is not a restoration of an abandoned product. It is a consolidation of operator navigation, overview grouping, and missing widgets into the existing route tree.

Shipped Scope

• Mounted one grouped Ops > Operations overview with blocking-strip status, quick submenu chips, pending-action callouts, and an explicit Setup ownership boundary.
• Standardized canonical route helpers under /ops/operations/* and rewired active overview and child-page links away from dead /platform/ops/* paths.
• Added legacy alias redirects for both /platform-ops/* and /platform/ops/* into the live Operations shell.
• Preserved agent-fleet and topology ownership under Setup > Topology while adding direct Operations handoffs where runtime monitoring needs to cross that boundary.
• Added focused route, component, and Playwright verification plus a checked-feature note at docs/features/checked/web/operations-consolidation-ui.md.

Withdrawn Surfaces

• Data Integrity overview (withdrawn 2026-10-08). /ops/operations/data-integrity showed fixed feed-lag, backlog, dead-letter and impacted-release values that no service measured, and its region and time selectors drove no request. The bare path now resolves to the normal Page Not Found page and no navigation entry links to it. The legacy /platform-ops/data-integrity and /platform/ops/data-integrity bookmarks no longer target it; they follow the legacy alias catch-all like any other unknown legacy path. Former entry points now name the owner surface instead: per-source advisory and VEX freshness at /ops/integrations/advisory-vex-sources, service status at /ops/operations/doctor.
• Data Integrity drilldowns (withdrawn 2026-10-08). The nightly ops report, feeds freshness, scan pipeline, reachability ingest, integration connectivity, DLQ and replays, and data-quality SLO pages under /ops/operations/data-integrity/<section>, and the job run detail at /ops/operations/data-integrity/nightly-ops/<runId>, rendered constant rows: fixed jobs, run ids and timestamps, reachability coverage of 84, 92 and 61 percent, fixed DLQ items and fixed SLO values. No page read an owner service, so the whole family is withdrawn: every /ops/operations/data-integrity/... path resolves to the normal Page Not Found page, and the /platform-ops/data-integrity/<section> and /platform/ops/data-integrity/<section> aliases are removed (those bookmarks follow the legacy alias catch-all). Use the owner surfaces instead: advisory and VEX source freshness at /ops/integrations/advisory-vex-sources, service health and SLOs at /ops/operations/doctor, scheduled runs at /ops/operations/scheduler/runs, and jobs at /ops/operations/jobengine/jobs. No replacement drilldown is planned.
• Dead-letter recovery (withdrawn 2026-10-09). /ops/operations/dead-letter and its queue and entry/:entryId children only stated that dead-letter recovery was not connected, because no service publishes a dead-letter API. The route family and its /ops/jobengine/dead-letter*, /platform-ops/dead-letter* and /platform/ops/dead-letter* aliases are withdrawn; the canonical paths resolve to the normal Page Not Found page and the alias bookmarks follow the legacy alias catch-all. Failed scheduled runs are retried from the Runs tab of /ops/operations/jobengine.

Contained Surfaces

• SLO Monitoring (contained 2026-10-09). The SLO service (/api/v1/release-orchestrator/slos) has no objective store: its reads return an empty read model and its writes answer 501 Not Implemented. The SLO Monitoring tab of /ops/operations/doctor and the /ops/operations/doctor/slo/definitions, /ops/operations/doctor/slo/alerts and /ops/operations/doctor/slo/<sloId> pages therefore offer no authoring, acknowledge or alert-threshold control and no authoring form; the definitions page states that SLO authoring is not available in the Console. The alert page and the tab show the number of configured objectives and the number with a successful evaluation next to the alert and status counts, read from the SLO service summary with its update time. An empty alert list shows the No alerts firing success state only when every configured objective has a successful evaluation and none is in warning or critical status; with an objective in either status the page says so instead. With no objective configured, none evaluated, a partially evaluated set or an unreadable summary, the page states that case; an unknown count reads unknown, not 0. The objective page states not found for an unknown objective and unavailable for a failed read instead of loading indefinitely, and shows no state, history or threshold section in either case. For a loaded objective, a failed state, forecast, history or threshold read is stated as unavailable. General SLO authoring is deferred and has no Console surface.
• SLO read access (2026-10-20). Every SLO read requires the orch:read scope: the Release Orchestrator SLO group is protected by its orchestrator read policy. Before the first read, the SLO Monitoring tab and the definitions, alerts and objective pages check that the session holds orch:read. The admin scope also passes this check; ui.admin alone does not. A session without the scope sends no SLO request and does not poll. The page shows SLO data is not readable with this session. It states that every SLO read requires orch:read and that this is a permission gap, not an absence of objectives or alerts. It shows no error panel, empty state, loading state, coverage line, Refresh or Definitions control. The Diagnostics route stays open to every role; only the SLO reads are gated. The roles executive-assurance-viewer and security-risk-manager do not hold orch:read, so they see this statement.
• Event Stream (contained 2026-10-09). /ops/operations/event-stream no longer shows a Connected or Degraded event-bus status, a transport name, event-rate and last-event tiles, an empty Recent Events table or a fixed list of event types: none of them was measured. The page states three modes. The live stream is not available: the Console holds no event-bus connection. The page reads no snapshot; Scheduler run state on the Runs tab of Scheduled Jobs is a bounded snapshot read when the tab opens or is refreshed. History is owned by Timeline: the audit events that services record in Timeline are listed in Audit Trail (/ops/operations/audit?tab=all-events). The page links there only for a session that passes the Audit Trail route guard and holds timeline:read; otherwise it names the missing access. Timeline event replay answers 501 outside development hosts and has no Console control.

Why This Is The Right Shape

• The current app already routes operators through /ops/operations.
• The dead and weak-route platform-ops pages overlap with the live ops shell rather than introducing a separate domain.
• Restoring the old shell would recreate fragmentation between overview pages, diagnostics, quotas, AOC, and air-gap operations.
• The correct move is to strengthen one overview and one child-route tree.

Operator Modes

1. Control Room Mode

• Used by operators scanning for blocking platform issues.
• Focus: overview, blocking cards, and high-priority drills.

2. Subsystem Specialist Mode

• Used by operators responsible for one area such as quotas, offline kit, job queues, or AOC.
• Focus: a dedicated child route reached from grouped cards.

3. Triage Handoff Mode

• Used when another shell surfaces an ops problem and links into operations.
• Focus: deep link into the relevant child route with preserved return context.

Recommended IA

Overview groups

• Blocking
  • critical platform alerts
• Execution
  • jobs and queues
  • scheduler
  • signals
• Health
  • health and SLO
  • diagnostics
  • system status
• Supply And Airgap
  • feeds and airgap
  • offline kit
  • pack registry
• Capacity
  • quotas and limits
• Communications
  • notifications

Child routes

• Overview
• Jobs & Queues
• Health & SLO
• Feeds & Airgap
• Offline Kit
• Quotas & Limits
• Diagnostics
• Signals
• Pack Registry
• Notifications

Page Anatomy

Overview page

• top blocking strip:
  • open incidents
  • highest-risk subsystem
  • degraded status count
• grouped cards:
  • each card shows status, trend, queue depth, or freshness
  • each card links to a single child route
• lower sections:
  • recent changes
  • pending operator actions
  • cross-links to Setup-owned topology when infra ownership is involved

Child routes

• keep a consistent subpage layout:
  • status summary cards
  • main table or chart
  • action rail
  • diagnostics or evidence side panel when relevant

Route Contract

Prefer the current route family and tighten it rather than creating new paths.

Canonical routes

• /ops/operations
• /ops/operations/jobs-queues
• /ops/operations/health-slo
• /ops/operations/feeds-airgap
• /ops/operations/offline-kit
• /ops/operations/quotas
• /ops/operations/doctor
• /ops/operations/signals
• /ops/operations/packs
• /ops/operations/notifications

Alias and cleanup rules

• legacy /platform-ops/* bookmarks should redirect into /ops/operations/*
• duplicate overview routes should be retired once card parity is reached
• child-route labels should match the sidebar and overview cards exactly

Verification

• Angular:
  • npx ng test --watch=false --include src/tests/platform-ops/platform-ops-routes.spec.ts --include src/tests/platform-ops/platform-ops-overview-page.component.spec.ts --include src/tests/platform-ops/platform-feeds-airgap-page.component.spec.ts --include src/tests/navigation/legacy-redirects.spec.ts
  • Data Integrity withdrawal: npx vitest run --config vitest.codex.config.ts src/tests/platform-ops/data-integrity-overview-withdrawal.spec.ts src/tests/platform-ops/data-integrity-drilldowns-withdrawal.spec.ts
• Playwright:
  • PLAYWRIGHT_PORT=4410 npx playwright test tests/e2e/operations-consolidation.spec.ts --workers=1
• Checked feature record:
  • docs/features/checked/web/operations-consolidation-ui.md

What To Merge

Preserve as the main shell

• PlatformOpsOverviewPageComponent
• operations.routes.ts

Absorb from legacy Platform Ops

• PlatformOpsOverviewComponent
• federation and telemetry summary cards that still add value
• any distinctive capacity or compliance widgets not already surfaced

Single Actions And Supporting Surfaces

Agent fleet

• primary home: Setup > Topology
• operations overview may show health summary and deep-link out

Diagnostics

• keep as Ops > Operations > Diagnostics
• avoid a second top-level doctor product entry
• diagnostic runs are single-flight from the Console: while a run is active, run and re-run controls stay disabled and the page shows completion percentage plus queued/running/completed check state
• active-run progress is owned by the shared Doctor store so progress remains visible when an operator leaves and returns to the Diagnostics route during the same Console session

AOC violations and reports

• withdrawn on 2026-10-08 (SPRINT_20261007_002 CCP-004, CCP-005): the AOC Compliance pages rendered fixed Platform values and no service owns AOC data, so the family is not part of the Operations shell

Offline import/export helpers

• keep inside Offline Kit or Feeds & Airgap
• do not create separate sidebar products

Cross-Product Entry Points

• Mission Control
  • links to degraded subsystem routes
• Setup > Topology
  • links back to operations when infra state impacts runtime operations
• Evidence or Releases
  • links into signals or pack registry when evidence freshness blocks a workflow

UI Standards For Implementation

• One shell, one overview, one submenu tree.
• Group cards by operator concern, not by backend service name alone.
• Preserve stable deep links from cards to subpages.
• Keep Setup-owned infrastructure management distinct from Ops-owned runtime monitoring.
• Treat legacy routes as migration aliases only.

Non-Goals

• Do not revive /platform-ops/* as a parallel route tree.
• Do not duplicate topology ownership under Ops.
• Do not create separate overview pages for each subsystem when grouped cards already solve discoverability.

Source Inputs

• docs/UI_GUIDE.md
• docs/modules/ui/operations/observability-guide.md
• docs/modules/notify/operations/observability.md
• src/Web/StellaOps.Web/src/app/routes/operations.routes.ts
• src/Web/StellaOps.Web/src/app/features/platform/ops/platform-ops-overview-page.component.ts
• src/Web/StellaOps.Web/src/app/features/platform-ops/platform-ops-overview.component.ts