Files
git.stella-ops.org/docs/modules/ui/v2-rewire/pack-13.md
2026-02-18 23:03:07 +02:00

618 lines
37 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

## Pack 13 — Releases + Approvals redesigned to be **Bundleversion driven** (digestfirst), with SBOM findings + hybrid reachability surfaced as **2ndclass** signals
This pack updates the existing **Releases** and **Approvals** areas so every promotion is anchored on an immutable **Bundle Version** (bundle manifest digest), while keeping the UI familiar and preserving current functionality.
---
# 13.1 Menu graph (Mermaid) — Releases + Approvals area (and their crosslinks)
```mermaid
flowchart TD
ROOT[Stella Ops Console] --> REL[Releases]
ROOT --> APPR[Approvals]
ROOT --> RC[Release Control (ROOT)]
ROOT --> EVID[Evidence]
ROOT --> SEC[Security]
ROOT --> OPS[Operations]
ROOT --> INT[Integrations]
%% Releases
REL --> REL_LIST[Releases (Promotions)]
REL --> REL_CREATE[Create Promotion]
REL --> REL_DETAIL[Promotion Detail]
REL_DETAIL --> REL_RUN[Deployment Run (timeline/logs)]
REL_DETAIL --> REL_EVID[Evidence Snapshot]
REL_DETAIL --> REL_SEC[Security Snapshot]
REL_DETAIL --> REL_REACH[Reachability Snapshot]
%% Approvals
APPR --> APPR_LIST[Approvals Queue]
APPR --> APPR_DETAIL[Approval Detail]
APPR_DETAIL --> APPR_GATES[Gate Results]
APPR_DETAIL --> APPR_RISK[SBOM/Findings + Reachability]
APPR_DETAIL --> APPR_EVID[Evidence used for decision]
APPR_DETAIL --> APPR_REPLAY[Replay/Verify decision]
%% Cross links
REL_CREATE -.select bundle version.-> BUNDLE[(Bundle Version Detail)]
REL_DETAIL -.references.-> BUNDLE
APPR_DETAIL -.references.-> BUNDLE
REL_CREATE -.materialize inputs.-> RC
REL_CREATE -.inputs from.-> INT
REL_DETAIL -.export.-> EVID
APPR_DETAIL -.exception request.-> SEC
REL_DETAIL -.ops signals.-> OPS
APPR_DETAIL -.ops signals.-> OPS
```
---
# 13.2 Releases subgraph (Mermaid) — screens and flow
```mermaid
flowchart LR
A[Releases (Promotions) List] --> B[Promotion Detail]
A --> C[Create Promotion]
C --> D[Materialize Bundle → Env]
D --> E[Evaluate Gates]
E --> F[Request Approval (if needed)]
F --> G[Run Workflow / Deploy]
G --> B
B --> H[Export Evidence]
B --> I[Rollback / Re-run]
```
---
# 13.3 Screen — Releases (Promotions) List
### Formerly
* **Releases** (`/releases`)
Shows release rows with status (Draft/Ready/Deploying/Deployed/Rolled back), env, components count, created, actions.
### Why changed like this
* The “release” row needs to represent a **promotion run** of a **Bundle Version** (digestfirst), not an adhoc component list.
* This preserves the list UX, but adds the missing anchors:
* **Bundle name + bundle version**
* **Bundle manifest digest**
* **SBOM / findings summary**
* **Data freshness / nightly ops signals** (so you dont approve based on stale feeds or failed rescans)
* **Hybrid reachability coverage** surfaced as a compact signal (2ndclass, not a whole new menu)
### Screen graph (Mermaid)
```mermaid
flowchart TD
A[Releases (Promotions) List] --> B[Filter by Region/Env/Status]
A --> C[Open Promotion Detail]
A --> D[Create Promotion]
A --> E[Open Bundle Version Detail]
A --> F[Jump to Approvals (if pending)]
```
### ASCII mock
```text
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Releases (Promotions) │
│ Legacy name/location: "Releases" (/releases) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Region [All] Env [All] Status [All] Bundle [search...] Data Health [All] │
│ Actions: [+ Create Promotion] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌──────────────────────────────┬───────────────┬──────────────┬──────────────┬──────────────┐ │
│ │ Promotion (Bundle Version) │ Env Path │ Status │ Risk Signal │ Data Health │ │
│ ├──────────────────────────────┼───────────────┼──────────────┼──────────────┼──────────────┤ │
│ │ Hotfix Bundle 1.2.4 │ stage→prod │ DEPLOYING │ clean │ OK │ │
│ │ manifest: sha256:abcd... │ US-East │ │ Reach: 1/0/0 │ feeds fresh │ │
│ │ Platform Release 1.3.0-rc1 │ stage→prod │ READY │ 1 crit reach │ WARN │ │
│ │ manifest: sha256:beef... │ EU-West │ │ Reach: 1/0/3 │ NVD stale 3h │ │
│ │ Platform Release 1.2.2 │ prod │ ROLLED BACK │ 2 high reach │ OK │ │
│ └──────────────────────────────┴───────────────┴──────────────┴──────────────┴──────────────┘ │
│ Risk Signal format: Critical reachable / High reachable / High not reachable (and VEX % link) │
│ Data Health: feed freshness + scan job status + integration connectivity (links to Ops) │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
```
---
# 13.4 Screen — Create Promotion (wizard)
### Formerly
* **+ Create Release** on `/releases` (button)
In PoC, this likely created a “release row” with components count, but no explicit bundle version composition workflow.
### Why changed like this
* Promotion should start by selecting a **Bundle Version** (already composed in Bundle Organizer), then:
1. choose region + env path,
2. **materialize** env-specific inputs (Vault/Consul),
3. evaluate policy gates with freshest data,
4. create approval request (if required),
5. run deployment workflow.
This turns “Create Release” into “Create Promotion” while keeping the Releases menu.
### Screen graph (Mermaid)
```mermaid
flowchart TD
A[Create Promotion] --> B[Step 1: Select Bundle Version]
A --> C[Step 2: Select Region + Env Path]
A --> D[Step 3: Materialize Inputs (Vault/Consul)]
A --> E[Step 4: Evaluate Gates (policy + data freshness)]
A --> F[Step 5: Approval Requirements + Justification]
A --> G[Step 6: Launch Promotion / Schedule]
G --> H[Promotion Detail]
```
### ASCII mock
```text
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Create Promotion │
│ Legacy name/location: "+ Create Release" (button on /releases) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Steps: (1) Bundle Version (2) Target Env (3) Inputs (4) Gates (5) Approvals (6) Launch │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ (1) Select Bundle Version │
│ Bundle: [Platform Release ▼] │
│ Version: [1.3.0-rc1 ▼] manifest digest: sha256:beef... │
│ Snapshot: 1 critical reachable | VEX 62% | Reach coverage: Img100/Build78/Run35 │
│ Links: [Open Bundle Version Detail] │
│ │
│ Next → │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
```
---
# 13.5 Screen — Create Promotion Step: Materialize Inputs (Vault/Consul) + bind check
### Formerly
* Env variables and secrets were implied:
* Vault integration exists under **Settings → Integrations**
* Release Control had “Environments” but no “promotion-time resolved plan” UI
### Why changed like this
* This is where your requirement becomes enforceable:
* “bundle becomes deployable to env X with variables from Vault/Consul”
* Missing bindings must block (or warn) **before** you request approvals.
### Screen graph (Mermaid)
```mermaid
flowchart LR
A[Inputs Materialization] --> B[Resolve from Vault/Consul]
A --> C[Detect missing bindings]
A --> D[Preview resolved deployment plan]
A --> E[Link: Release Control → Env Inputs]
A --> F[Continue to Gates]
```
### ASCII mock
```text
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Create Promotion — Step (3) Inputs (Materialize) │
│ Legacy: scattered across Integrations (Vault) + Release Control (env config) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Target: US-East / us-prod │
│ │
│ Resolution results │
│ ✓ consul service/api-gw/rate_limit_max = 500 │
│ ✓ vault secret/api-gw/jwt_keys = (sealed) │
│ ✗ vault secret/user/db_password = MISSING binding │
│ │
│ Outcome: BLOCKED — cannot proceed to policy evaluation / approval request │
│ Fix: [Open Release Control → US-East/us-prod → Inputs] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
```
---
# 13.6 Screen — Promotion Detail (Release Detail)
### Formerly
* Likely “Release detail” behind the eye icon on `/releases`
(not included in your screenshots, but implied by actions)
### Why changed like this
* Promotion detail must clearly tie together:
* bundle version identity (digest-first),
* gate outcome + explanation,
* SBOM findings summary by env,
* hybrid reachability coverage for confidence,
* ops data health (feeds/rescans/integrations),
* evidence snapshot and export.
**Hybrid reachability** remains 2ndclass: a tab/section, not its own menu.
### Screen graph (Mermaid)
```mermaid
flowchart TD
A[Promotion Detail] --> B[Overview]
A --> C[Gate Trace (why pass/block)]
A --> D[Security Snapshot (SBOM findings)]
A --> E[Reachability Snapshot (image/build/runtime)]
A --> F[Deployment Run Timeline]
A --> G[Evidence Snapshot + Export]
A --> H[Ops/Data Health]
A --> I[Diff vs previous deployed bundle]
```
### ASCII mock
```text
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Promotion: Platform Release 1.3.0-rc1 (manifest sha256:beef...) │
│ Legacy name/location: Release detail from "Releases" (/releases) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Env Path: EU-West / eu-stage → eu-prod Status: READY Workflow: Canary 10→50→100 │
│ Requested by: alice.johnson Justification: scheduled release w/ rate limiting + bug fixes │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Tabs: [Overview] [Gates] [Security] [Reachability] [Run] [Evidence] [Ops/Data] [Diff] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Overview │
│ Risk summary: 1 critical reachable (eu-prod) | 0 high reachable | 3 high not reachable │
│ VEX coverage: 62% │
│ Data health: WARN — NVD feed stale 3h; last rescan job failed (worker) │
│ │
│ Actions: [Request Approval] [Run Now] [Schedule] [Export Evidence] [Rollback (if running)] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
```
---
# 13.7 Screen — Promotion Detail: Gates (explain “why” + tie to freshness)
### Formerly
* “Policy Gates” summary existed on Approvals cards (“PASS/BLOCK”) but lacked:
* structured trace,
* explicit linkage to data freshness and job state.
### Why changed like this
* Stellas value is “explain every decision” / deterministic traceability.
* Gate trace must include:
* what inputs were used (bundle digest, env, policy baseline),
* whether CVE feeds were fresh,
* whether SBOM scans completed,
* reachability evidence quality (warn/block based on baseline).
### Screen graph (Mermaid)
```mermaid
flowchart LR
A[Gates Tab] --> B[Gate Results Table]
A --> C[Gate Trace Detail (inputs + evidence)]
A --> D[Replay evaluation]
A --> E[Link to Exception Request]
```
### ASCII mock
```text
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Gates — Platform Release 1.3.0-rc1 → EU-West/eu-prod │
│ Legacy: Approvals cards showed PASS/BLOCK without full trace │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Baseline: Prod-EU-West | Evaluated: Feb 18, 08:30 | Data: NVD stale 3h (warn threshold 2h) │
│ │
│ ┌──────────────────────────────┬──────────┬──────────────────────────────────────────────────┐ │
│ │ Gate │ Result │ Why │ │
│ ├──────────────────────────────┼──────────┼──────────────────────────────────────────────────┤ │
│ │ SBOM scans complete │ FAIL │ worker digest pending scan (required for prod) │ │
│ │ Critical reachable CVEs │ FAIL │ CVE-XXXX reachable in eu-prod (no VEX) │ │
│ │ Feed freshness │ WARN │ NVD last sync 3h │ │
│ │ Reachability coverage runtime │ WARN │ runtime evidence 35% (policy warn) │ │
│ └──────────────────────────────┴──────────┴──────────────────────────────────────────────────┘ │
│ Actions: [Replay Gate Eval] [Request Exception] [Open Findings] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
```
---
# 13.8 Approvals subgraph (Mermaid) — screens and flow
```mermaid
flowchart TD
A[Approvals Queue] --> B[Approval Detail]
B --> C[Approve / Reject]
B --> D[View Gate Trace]
B --> E[View Security Snapshot]
B --> F[View Evidence]
B --> G[Request Exception]
C --> H[Promotion continues / deploy run starts]
```
---
# 13.9 Screen — Approvals Queue
### Formerly
* **Approvals** (`/approvals`)
Shows pending items with justification, policy gates PASS/BLOCK, approvals count, approve/reject buttons.
### Why changed like this
* Approval items must reference:
* the **Bundle Version** (manifest digest),
* the **target region/env path**,
* **SBOM findings summary** (critical reachable per env),
* **hybrid reachability confidence**,
* **data freshness / nightly job issues** that might invalidate the scan picture.
This allows reviewers to answer: “Is this safe to promote *right now*?”
### Screen graph (Mermaid)
```mermaid
flowchart LR
A[Approvals Queue] --> B[Filter by Region/Env/Status/Risk]
A --> C[Open Approval Detail]
A --> D[Jump to Promotion Detail]
A --> E[Jump to Bundle Version Detail]
```
### ASCII mock
```text
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Approvals │
│ Legacy name/location: "Approvals" (/approvals) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filters: Status [Pending] Region [All] Env [All] Risk [All] Data Health [All] │
│ │
│ Results (2) │
│ ┌──────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Platform Release 1.3.0-rc1 (manifest sha256:beef...) eu-stage → eu-prod │ │
│ │ Justification: scheduled release with rate limiting feature and bug fixes. │ │
│ │ Gates: BLOCK (2/4) Approvals: 0/2 │ │
│ │ Risk: 1 critical reachable (eu-prod) | VEX 62% | Reach Img100/Build78/Run35 │ │
│ │ Data health: WARN (NVD stale 3h; rescan job failed) │ │
│ │ [Approve] [Reject] [View Details] │ │
│ └──────────────────────────────────────────────────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────────────────────────────────────────────────┐ │
│ │ Hotfix Bundle 1.2.4 (manifest sha256:abcd...) us-stage → us-prod │ │
│ │ Justification: critical fix for user authentication timeout issue. │ │
│ │ Gates: PASS (4/4) Approvals: 1/2 │ │
│ │ Risk: clean | Reach Img100/Build100/Run80 │ │
│ │ Data health: OK │ │
│ │ [Approve] [Reject] [View Details] │ │
│ └──────────────────────────────────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
```
---
# 13.10 Screen — Approval Detail (decision packet)
### Formerly
* Likely behind “View Details” on `/approvals` (not shown), plus scattered info across:
* Security overview/findings,
* Evidence exports,
* Replay/Verify.
### Why changed like this
* Approval is the decision choke point; it must show:
* what is being approved (bundle digest),
* what env(s) are impacted,
* why gates pass/block,
* SBOM findings and reachability evidence quality,
* evidence pointers for audit,
* replay/verify capability.
### Screen graph (Mermaid)
```mermaid
flowchart TD
A[Approval Detail] --> B[Decision Overview]
A --> C[Gate Results + Trace]
A --> D[SBOM Findings (by env)]
A --> E[Reachability (image/build/runtime)]
A --> F[Evidence used]
A --> G[Ops/Data Health]
A --> H[Replay/Verify]
A --> I[Approve/Reject actions]
```
### ASCII mock
```text
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Approval: Platform Release 1.3.0-rc1 → EU-West/eu-prod │
│ Legacy name/location: Approval detail from "Approvals" (/approvals) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Bundle version: Platform Release 1.3.0-rc1 │
│ Manifest digest: sha256:beef... Requested by: alice.johnson Requested: 36d ago │
│ Env path: eu-stage → eu-prod Workflow: Canary 10→50→100 │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Tabs: [Overview] [Gates] [Security] [Reachability] [Evidence] [Ops/Data] [Replay/Verify] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Overview │
│ Current gate state: BLOCK │
│ Blocking reasons: (1) critical reachable CVE without VEX (2) SBOM scan incomplete │
│ │
│ Actions: [Approve] (disabled) [Reject] [Request Exception] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
```
---
# 13.11 Approval Detail: Security tab (SBOM findings by env + “what changed”)
### Formerly
* Security summary existed, but disconnected from the approval object and env context.
### Why changed like this
* Approvals must be grounded in:
* **which environments** have critical reachable issues,
* and whether they are already present (“existing risk”) or introduced by this promotion (“delta”).
### Screen graph (Mermaid)
```mermaid
flowchart LR
A[Security Tab] --> B[Findings summary by severity + reachability]
A --> C[By environment breakdown]
A --> D[Delta vs currently deployed bundle in target env]
A --> E[Open Finding detail / VEX]
```
### ASCII mock
```text
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Security — Approval Detail │
│ Legacy: Security Overview/Findings were separate from Approvals │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Summary (target env: eu-prod) │
│ Critical reachable: 1 High reachable: 0 High not reachable: 3 VEX coverage: 62% │
│ │
│ By environment │
│ eu-stage: 0 critical reachable │
│ eu-prod : 1 critical reachable (CVE-XXXX in user-service sha256:2222...) │
│ │
│ Delta (vs currently deployed bundle in eu-prod) │
│ +1 critical reachable introduced by this promotion │
│ Links: [Open Finding] [Open Component Version] [Open VEX Statement] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
```
---
# 13.12 Approval Detail: Reachability tab (hybrid reachability as 2ndclass)
### Formerly
* Reachability appeared conceptually in approvals (“policy + reachability”) but without clear sourcing.
### Why changed like this
* You require hybrid reachability from:
* **image (Dover scan)**,
* **build evidence**,
* **runtime evidence**.
* This must be visible during approvals but stays 2ndclass (tab).
### Screen graph (Mermaid)
```mermaid
flowchart TD
A[Reachability Tab] --> B[Coverage metrics: image/build/runtime]
A --> C[Evidence sources list]
A --> D[Policy interpretation (warn/block thresholds)]
A --> E[Drill into component reachability]
```
### ASCII mock
```text
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Reachability — Approval Detail │
│ Legacy: reachability referenced but not clearly sourced │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Coverage (for bundle version) │
│ Image evidence: 100% Build evidence: 78% Runtime evidence: 35% │
│ │
│ Interpretation (baseline Prod-EU-West) │
│ • Runtime coverage < 50% → WARN (does not block) │
│ • Critical reachable requires runtime evidence OR VEX override → BLOCK │
│ │
│ Component breakdown │
│ user-service sha256:2222... Image ✓ Build ✗ Runtime ✗ │
│ api-gateway sha256:1111... Image ✓ Build ✓ Runtime ✗ │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
```
---
# 13.13 Approval Detail: Ops/Data tab (nightly job + feed + integration health)
### Formerly
* Feeds freshness: **Operations → Feeds**
* Background jobs: **System → Background Jobs**
* Integrations: **Settings → Integrations**
* None were summarized at approval time.
### Why changed like this
* Approvals must warn if:
* CVE feeds are stale,
* SBOM rescans failing,
* integrations disconnected (e.g., Vault/Registry/CI),
because decision confidence is reduced.
### Screen graph (Mermaid)
```mermaid
flowchart LR
A[Ops/Data Tab] --> B[Feed freshness (NVD/OSV)]
A --> C[SBOM rescan job status]
A --> D[Integration connectivity]
A --> E[Links: Ops/System/Integrations]
```
### ASCII mock
```text
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Ops/Data Health — Approval Detail │
│ Legacy: separate screens (Ops Feeds, System Jobs, Integrations) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Feeds │
│ OSV: synced 20m ago (OK) │
│ NVD: synced 3h ago (WARN; threshold 2h) │
│ │
│ Nightly jobs │
│ SBOM rescan (worker sha256:4444...): FAILED (last run 1h ago) │
│ Reachability import (runtime): RUNNING │
│ │
│ Integrations │
│ Registry: OK CI/CD: DEGRADED (Jenkins) Vault: OK │
│ Links: [Open Ops Feeds] [Open System Jobs] [Open Integrations] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
```
---
## What stays the same (so we preserve PoC functionality)
* **Releases list** still shows statuses like Draft/Ready/Deploying/Deployed/Rolled back.
* **Approvals queue** still has Approve/Reject and the same “requested by + justification” feel.
* Promotion path concept (staging → production) remains identical — now **regionscoped** and bundleversionanchored.
---
If you say “continue”, **Pack 14** will cover the **Release Run / Deployment timeline** screen (logs, checkpoints, rollback triggers, evidence capture points) and how it ties into **Replay/Verify** and **Evidence Export** without adding new toplevel clutter.