stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity

feat(web): harden split release promotion handoff

Browse Source 
Signed-off-by: master <>
This commit is contained in:
master
2026-03-31 23:52:32 +03:00
parent 58f9d759f5
commit b6bf113b99
19 changed files with 953 additions and 191 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
docs/implplan/SPRINT_20260322_001_FE_wizard_split.md
View File

@@ -1,67 +0,0 @@
# Sprint 20260322-001 — Split Create Wizard into Version / Hotfix / Release
## Topic & Scope
- Split the monolithic "Create Release" wizard into 3 distinct wizards matching DevOps concepts.
- **Version**: artifact definition (name, version, images, scripts). No deployment info.
- **Hotfix**: single emergency package (one image + tag). Minimal.
- **Release**: deployment plan. Picks a Version or Hotfix, then configures WHERE (regions, envs) and HOW (stages, strategy). If hotfix → no stages, just target env. If version → requires promotion stages.
- If Version/Hotfix doesn't exist during Release creation → inline creation within the same page.
- Working directory: `src/Web/StellaOps.Web/src/app/features/release-orchestrator/releases/`
## Dependencies & Concurrency
- Tasks are sequential (shared component first, then 3 wizards, then routes).
## Delivery Tracker
### TASK-001 - Create Version wizard
Status: TODO
Owners: FE
Task description:
- New component: `create-version.component.ts`
- Steps: 1) Name + Version + Description 2) Components (images + scripts) with autocomplete 3) Review & Seal
- Autocomplete: name defaults to last used or generic, version auto-increments
- Component search uses existing registry API
- No regions, no stages, no strategy, no deployment config
- Route: `/releases/versions/new`
### TASK-002 - Create Hotfix wizard
Status: TODO
Owners: FE
Task description:
- New component: `create-hotfix.component.ts`
- Single step or 2 steps: 1) Pick one Docker image + tag 2) Confirm
- No name (derives from image), no version (uses digest)
- Minimal, fast-track flow
- Route: `/releases/hotfixes/new`
### TASK-003 - Create Release wizard
Status: TODO
Owners: FE
Task description:
- New component: `create-release.component.ts` (replaces old wizard)
- Steps: 1) Pick Version or Hotfix (with inline create option) 2) Target (regions, envs, stages) 3) Strategy config 4) Review & Create
- If Version selected → stages required (Dev → Stage → Prod)
- If Hotfix selected → just target env, no stages
- Inline create: if version/hotfix doesn't exist, expand an inline creation form
- Route: `/releases/new`
### TASK-004 - Update routes and navigation
Status: TODO
Owners: FE
Task description:
- `/releases/versions/new` → CreateVersionComponent
- `/releases/hotfixes/new` → CreateHotfixComponent
- `/releases/new` → CreateReleaseComponent
- Update sidebar "New Version" page action to point to `/releases/versions/new`
- Update pipeline page "New Release" to point to `/releases/new`
- Remove old `create-release.component.ts` or rename
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-03-22 | Sprint created. | Planning |
## Decisions & Risks
- Old create-release component will be replaced, not refactored (too intertwined).
- Inline version/hotfix creation within release wizard is complex — may use dialog or expandable section.
- Custom scripts support deferred to follow-up sprint.

3
docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md
View File

@@ -14,6 +14,7 @@ Sprint: `20260218_005`, task `R0-06`
- Backend administration adapters now cover Pack-21 A0-A7 (`/api/v1/administration/{summary,identity-access,tenant-branding,notifications,usage-limits,policy-governance,trust-signing,system}`), so `S00-T05-ADM-01` is reclassified to `EXISTS_COMPAT`.
- Trust owner mutation routes for keys/issuers/certificates/transparency log are implemented under `/api/v1/administration/trust-signing/*` with `platform.trust.write` / `platform.trust.admin`, backed by Platform DB migration `046_TrustSigningAdministration.sql`.
- Readiness reconciliation is recorded in `S16_release_readiness_package.md`.
- Frontend release creation was re-aligned on 2026-03-31: `/releases/new` is now a split-flow handoff page, `/releases/promotions/create` is the canonical target/gate/approval flow, and `/releases/deployments/new` remains only as a compatibility redirect into promotions.
## Status class definitions
@@ -29,7 +30,7 @@ Sprint: `20260218_005`, task `R0-06`
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Dashboard | Dashboard v3 mission board | `source-of-truth.md 3.2`, `authority-matrix.md A: Dashboard`, `pack-16.md` | `/` (control-plane/dashboard variants) | `GET /api/v1/dashboard/summary`; existing promotion, approval, and scan summary endpoints | `EXISTS_COMPAT` | `Web` (composition) + `ReleaseOrchestrator`, `Policy`, `Scanner` | No new scopes; requires existing viewer scopes | Implemented in Platform pack adapters with deterministic data-confidence, CritR env breakdown, B/I/R coverage, and top-driver fields consumed by dashboard v3 cards | Route finalized to `/api/v1/dashboard/summary`; validated by `PackAdapterEndpointsTests` | `S00-T05-DASH-01` |
| Release Control | Bundle catalog/detail/builder | `source-of-truth.md 3.1`, `authority-matrix.md A: bundles`, `pack-12.md` | `/release-control/bundles/*` | `GET /api/v1/release-control/bundles`; `GET /api/v1/release-control/bundles/{bundleId}`; `GET /api/v1/release-control/bundles/{bundleId}/versions`; `GET /api/v1/release-control/bundles/{bundleId}/versions/{versionId}`; `POST /api/v1/release-control/bundles`; `POST /api/v1/release-control/bundles/{bundleId}/versions`; `POST /api/v1/release-control/bundles/{bundleId}/versions/{versionId}/materialize` | `EXISTS_COMPAT` | `Platform` (`StellaOps.Platform.WebService`) | `orch:read` (read routes), `orch:operate` (create/publish/materialize) | Implemented with Postgres-backed lifecycle tables (`release.control_bundles*`) plus deterministic list ordering and idempotent materialization key handling | Collision with Evidence bundle export routes resolved by dedicated `/api/v1/release-control/*` namespace; frontend bundle surfaces are now API-bound (see sprint `20260219_003` RC3-06) | `S00-T05-RC-01` |
| Release Control | Promotions list/create/detail | `source-of-truth.md 3.1`, `authority-matrix.md A: releases`, `pack-13.md` | `/release-control/promotions/*` | `GET /api/release-jobengine/approvals` (list); `GET /api/release-jobengine/approvals/{id}` (detail); `GET /api/release-jobengine/releases/{releaseId}/available-environments` (target preflight); `GET /api/release-jobengine/releases/{releaseId}/promotion-preview` (gate preflight); `POST /api/release-jobengine/releases/{releaseId}/promote` (create); `POST /api/release-jobengine/approvals/{id}/approve`; `POST /api/release-jobengine/approvals/{id}/reject` | `EXISTS_COMPAT` | `ReleaseOrchestrator` | Existing `orch:read` / `orch:operate` | Legacy promotion/approval payloads are enriched with manifest digest, risk snapshot, hybrid reachability coverage, ops confidence, and decision digest via `ApprovalEndpoints.WithDerivedSignals` | Contract fields verified by `ReleaseControlV2EndpointsTests`; Pack 13 digest-first promotion cards no longer depend on frontend-only gap placeholders | `S00-T05-RC-02` |
| Release Control | Promotions list/create/detail | `source-of-truth.md 3.1`, `authority-matrix.md A: releases`, `pack-13.md` | `/releases/promotions/*` | `GET /api/release-jobengine/approvals` (list); `GET /api/release-jobengine/approvals/{id}` (detail); `GET /api/release-jobengine/releases/{releaseId}/available-environments` (target preflight); `GET /api/release-jobengine/releases/{releaseId}/promotion-preview` (gate preflight); `POST /api/release-jobengine/releases/{releaseId}/promote` (create); `POST /api/release-jobengine/approvals/{id}/approve`; `POST /api/release-jobengine/approvals/{id}/reject` | `EXISTS_COMPAT` | `ReleaseOrchestrator` | Existing `orch:read` / `orch:operate` | Legacy promotion/approval payloads are enriched with manifest digest, risk snapshot, hybrid reachability coverage, ops confidence, and decision digest via `ApprovalEndpoints.WithDerivedSignals` | Contract fields verified by `ReleaseControlV2EndpointsTests`; `/releases/new` now hands users into this surface and `/releases/deployments/new` is retained only as a compatibility redirect. Bundle/version/hotfix context may be preserved on the handoff page, but the FE no longer aliases those identities into the promotion API's `releaseId` parameter. | `S00-T05-RC-02` |
| Release Control | Run timeline, checkpoints, rollback | `source-of-truth.md 3.1`, `authority-matrix.md A: run timeline`, `pack-14.md` | `/deployments/*` and run views | `GET /api/v1/runs/{id}` (run detail); `GET /api/v1/runs/{id}/steps` (step list); `GET /api/v1/runs/{id}/steps/{stepId}` (step detail + logs); `POST /api/v1/runs/{id}/rollback` (trigger rollback) | `EXISTS_COMPAT` | `ReleaseOrchestrator` | Existing `orch:read` / `orch:operate` | Implemented v2 run contracts include ordered checkpoints plus explicit evidence-thread and log-artifact links; rollback returns deterministic accepted payload with guard state | `/api/v1/runs/*` and `/v1/runs/*` compatibility routes are live and test-backed; policy-coupled rollback guard hardening remains future work | `S00-T05-RUN-01` |
| Approvals | Approvals v2 tabs and decision packet | `source-of-truth.md 3.3`, `authority-matrix.md A: approvals`, `pack-17.md` | `/approvals/*` | `GET /api/v1/approvals` (queue); `GET /api/v1/approvals/{id}` (detail); `GET /api/v1/approvals/{id}/gates` (gate trace); `GET /api/v1/approvals/{id}/evidence` (evidence packet); `GET /api/v1/approvals/{id}/security-snapshot` (security tab data); `GET /api/v1/approvals/{id}/ops-health` (ops/data tab); `POST /api/v1/approvals/{id}/decision` (approve/reject/defer/escalate) | `EXISTS_COMPAT` | `Policy` + `ReleaseOrchestrator` | Existing policy reviewer / approver scopes | v2 approvals adapter routes now return deterministic decision-packet shapes containing digest, gate trace, security snapshot (risk + B/I/R), and ops/data confidence payloads | Deterministic ordering and contract fields are verified in `ReleaseControlV2EndpointsTests` (queue determinism, gate ordering, decision mutation, not-found behavior) | `S00-T05-APR-01` |
| Environment | Environment detail standard tabs | `source-of-truth.md 3.1 and 3.6`, `authority-matrix.md A: env detail`, `pack-18.md` | `/environments/*` | `GET /api/v1/environments/{id}` (detail); `GET /api/v1/environments/{id}/deployments` (deployment history); `GET /api/v1/environments/{id}/security-snapshot` (security state); `GET /api/v1/environments/{id}/evidence` (evidence summary); `GET /api/v1/environments/{id}/ops-health` (data confidence) | `EXISTS_COMPAT` | `ReleaseOrchestrator` | Existing `orch:read` | Pack-18 environment tab contracts are implemented with standardized header fields (manifest digest, risk snapshot, B/I/R coverage, ops confidence) and deterministic deployment ordering | Environment adapters are live under `/api/v1/environments/*` and validated in `ReleaseControlV2EndpointsTests` | `S00-T05-ENV-01` |