# 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: `../../../docs-archived/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.