3.6 KiB
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 > Operationsroute tree. - The old
platform-opspages and the newerplatform/opspages 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 > OverviewOps > Operations > Data IntegrityOps > Operations > Jobs & QueuesOps > Operations > Health & SLOOps > Operations > Feeds & AirgapOps > Operations > Offline KitOps > Operations > Quotas & LimitsOps > Operations > AOC ComplianceOps > Operations > DiagnosticsOps > Operations > SignalsOps > 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.mddocs/modules/ui/operations/observability-guide.mddocs/modules/notify/operations/observability.mdsrc/Web/StellaOps.Web/src/app/routes/operations.routes.tssrc/Web/StellaOps.Web/src/app/features/platform/ops/platform-ops-overview-page.component.tssrc/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.