preparation for ui re-shelling

This commit is contained in:
master
2026-02-18 23:03:07 +02:00
parent cb3e361fcf
commit c2f13fe588
46 changed files with 16727 additions and 0 deletions

View File

@@ -0,0 +1,617 @@
## 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.