git.stella-ops.org/docs/modules/ui/v2-rewire/sprint-planning-guide.md

UI v2 Rewire Sprint Planning Guide

Status: Planning-only guidance Date: 2026-02-18

This guide defines how to decompose the canonical redesign into many implementation sprints.

1) Required reading order for planners

1. source-of-truth.md
2. authority-matrix.md
3. Authoritative packs for the 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 nav placement changes and backend contract changes as separate work items.
• 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.

Stream	Scope	Primary packs
S0-Spec	close spec gaps and freeze canonical IA terms	pack-21.md, pack-19.md, pack-20.md
S1-NavShell	root nav structure, route aliases, breadcrumbs, migration banners	pack-21.md, pack-16.md
S2-ReleaseCore	bundles, releases, approvals, run timeline	pack-12.md, pack-13.md, pack-14.md, pack-17.md
S3-EnvOps	environment detail + data confidence + ops bubble-up	pack-18.md, pack-15.md, pack-16.md
S4-SecurityEvidence	Security consolidation + Evidence consolidation + cross-links	pack-19.md, pack-20.md
S5-AdminIntegrations	Administration A0-A7, Integrations taxonomy, feeds split	pack-21.md, pack-10.md

4) Endpoint and contract investigation workflow

Backend coverage is incomplete in some areas. 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).
6. If MISSING_NEW, write a contract task with request/response schema, auth scope, and evidence 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/features/**/**.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

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>
- 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. Spec gap sprint for Security & Risk -> Advisory Sources detailed screen model and contracts.
2. Nav migration sprint defining final rendering strategy for Release Control-owned capabilities.
3. Trust ownership transition sprint (Administration owner, Evidence consumer links and redirects).
4. Route alias/deprecation sprint from legacy settings and historical 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,
• scope/permission changes are identified,
• migration/redirect handling is scoped,
• test evidence expectations are explicit.