Files
git.stella-ops.org/docs/modules/ui/restoration-topics/platform-ops-consolidation.md

3.6 KiB

Platform Ops Consolidation

Recommendation

Do not restore old Platform Ops as a second ops product.

Merge the legacy overview and legacy leaves into the active Ops > Operations shell and keep one consolidated operator surface.

Why

  • The current app already has an Ops > Operations route tree.
  • The old platform-ops pages and the newer platform/ops pages describe the same operator concerns with different shells.
  • Duplicating ops navigation would recreate the same fragmentation that dropped the original branch.

Primary Placement

  • Menu group: Ops
  • Section: Operations

Canonical root:

  • /ops/operations

Product Shape

One overview page plus grouped subroutes is enough.

Core groups on the overview

  • Blocking
    • Data Integrity, AOC Compliance, critical platform alerts
  • Execution
    • Jobs & Queues, Scheduler, Dead-Letter, Signals
  • Health
    • Health & SLO, Diagnostics, system status
  • Supply And Airgap
    • Feeds & Airgap, Offline Kit, Pack Registry
  • Capacity
    • Quotas & Limits

Merge Map

Keep as the main shell

  • current PlatformOpsOverviewPageComponent
  • current operations.routes.ts

Absorb from legacy Platform Ops

  • old overview cards and descriptive grouping
  • telemetry and federation-style operational snapshots where still useful
  • any platform-state widgets missing from the newer overview

Placement For Single Actions And Stray Pages

Agent fleet

  • Do not duplicate under Ops as a first-class page
  • Primary home should be Setup > Topology
  • Ops overview may deep-link to topology health when operator context requires it

Security data freshness / data trust details

  • Put under Data Integrity
  • Not as a standalone ops product page

Diagnostics

  • Keep as a submenu under Ops > Operations
  • Do not split it into a second “doctor-style” product entry if the route already exists

AOC compliance

  • Keep under Ops > Operations
  • Surface blocking status cards on overview, full detail in its own child route

Quotas, offline kit, feeds, health

  • Keep as child routes under Ops > Operations
  • Use grouped cards on the overview page, not new sidebar branches

Suggested Submenu Structure

  • Ops > Operations > Overview
  • Ops > Operations > Data Integrity
  • Ops > Operations > Jobs & Queues
  • Ops > Operations > Health & SLO
  • Ops > Operations > Feeds & Airgap
  • Ops > Operations > Offline Kit
  • Ops > Operations > Quotas & Limits
  • Ops > Operations > AOC Compliance
  • Ops > Operations > Diagnostics
  • Ops > Operations > Signals
  • Ops > Operations > Pack Registry

What Not To Do

  • Do not revive /platform-ops/* as a parallel route tree.
  • Do not keep both a legacy ops overview and a current ops overview.
  • Do not put topology ownership under Ops when Setup already owns it.

Detailed UX And Sprint

  • Detailed UX dossier: ../platform-ops-consolidation/README.md
  • Implementation sprint: ../../../implplan/SPRINT_20260307_026_FE_platform_ops_consolidation.md

Corroborating 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

Final Call

This is a consolidation job, not a restoration of a separate product. Keep one Ops > Operations shell, absorb the missing legacy widgets and grouping logic, and deep-link out to Setup-owned topology where needed.