## Pack 13 — Releases + Approvals redesigned to be **Bundle‑version driven** (digest‑first), with SBOM findings + hybrid reachability surfaced as **2nd‑class** 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 cross‑links) ```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 sub‑graph (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** (digest‑first), not an ad‑hoc 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 don’t approve based on stale feeds or failed rescans) * **Hybrid reachability coverage** surfaced as a compact signal (2nd‑class, 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 2nd‑class: 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 * Stella’s 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 sub‑graph (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 2nd‑class) ### 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 2nd‑class (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 **region‑scoped** and bundle‑version‑anchored. --- 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 top‑level clutter.