UI v2 Rewire Sprint Planning Guide

Status: SUPERSEDED (2026-07-13); historical planning guidance only Date: 2026-02-20

This guide records how the historical v2 redesign was decomposed. It is not current UI authority; use the source pointers and active program in the directory currency notice.

1) Required reading order for planners

1. source-of-truth.md
2. authority-matrix.md
3. pack-22.md plus authoritative fallback packs for selected capability area
4. Current UI/backend implementation (src/Web/**, src/**/WebService/**) for feasibility and contract checks

Do not start sprint writing from raw pack text alone.

2) Planning constraints

• Higher pack number is authoritative for overlaps.
• Keep redesign deterministic and offline-capable.
• Treat IA route migration and backend contract/migration work as separate tasks.
• Backend dependency sprints (contracts + DB migrations) must complete before FE cutover tasks are marked DONE.
• Preserve migration safety with redirect/alias tasks in rollout sprints.

3) Recommended multi-sprint decomposition

Use independent streams so multiple teams can run in parallel.

4) Endpoint and contract investigation workflow

Backend coverage is incomplete for Pack 22. Every sprint must include an explicit endpoint contract pass.

4.1 For each planned screen, classify backend status

Use one of these states:

• EXISTS_COMPAT - endpoint exists and contract matches target UI
• EXISTS_ADAPT - endpoint exists but response/request shape or semantics must be adapted
• MISSING_NEW - endpoint does not exist and must be specified/implemented

4.2 Required investigation steps

1. Locate current route/component wiring in UI.
2. Locate current API client call(s) in UI client layer.
3. Locate backend endpoint(s) across service modules.
4. Compare current contract to target pack behavior.
5. Record status (EXISTS_COMPAT / EXISTS_ADAPT / MISSING_NEW) in the ledger.
6. If MISSING_NEW, write contract + DB migration tasks with request/response schema, auth scope, and deterministic behavior requirements.

4.3 Search anchors (read-only references)

• UI routing and nav:
  • src/Web/StellaOps.Web/src/app/app.routes.ts
  • src/Web/StellaOps.Web/src/app/layout/app-sidebar/app-sidebar.component.ts
  • src/Web/StellaOps.Web/src/app/routes/*.ts
• UI API clients:
  • src/Web/StellaOps.Web/src/app/core/api/*.ts
• Backend endpoint surfaces:
  • src/**/WebService/Endpoints/*.cs
  • src/**/Infrastructure/** for data dependencies
• Platform DB migrations:
  • src/Platform/__Libraries/StellaOps.Platform.Database/Migrations/Release/*.sql

5) Mandatory sprint ticket fields (for every UI feature ticket)

Use this minimum structure in planning docs:

### <Ticket ID> - <Feature>
- Canonical source: <source-of-truth section + authority-matrix row + pack sections>
- UI scope: <routes/components>
- Backend contract status: EXISTS_COMPAT | EXISTS_ADAPT | MISSING_NEW
- Endpoint(s): <current or proposed>
- DB migration impact: <existing migration or new migration file>
- Auth scope impact: <new/changed scopes>
- Offline/determinism impact: <none or required behavior>
- Redirect/deprecation impact: <legacy paths>
- Evidence required: <tests, screenshots, contract tests>

6) First planning backlog (must be created before build sprints)

1. Backend dependency sprint for global context and releases read-model contracts (/api/v2/context/*, /api/v2/releases/*).
2. Backend dependency sprint for topology inventory contracts (/api/v2/topology/*) and migrations.
3. Backend dependency sprint for security disposition contracts (/api/v2/security/findings, /api/v2/security/disposition).
4. FE nav migration sprint from old roots to Dashboard/Releases/Security/Evidence/Topology/Operations/Integrations/Administration.
5. Route alias/deprecation sprint from legacy domains and paths.

7) Definition of ready for implementation sprint

A capability is ready only when:

• authoritative pack sections are listed,
• endpoint status is classified for each screen,
• missing contracts are specified,
• DB migrations are identified,
• scope/permission changes are identified,
• migration/redirect handling is scoped,
• test evidence expectations are explicit.