101 lines
4.3 KiB
Markdown
101 lines
4.3 KiB
Markdown
# 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:
|
|
|
|
```md
|
|
### <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.
|