stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 2 Releases Wiki Activity
Files
12d7eda923aee51eae6d07a0ea5ab88030e021a1
git.stella-ops.org/docs/modules/ui/v2-rewire/pack-04.md
master c2f13fe588 preparation for ui re-shelling
2026-02-18 23:03:07 +02:00

54 KiB
Raw Blame History

Pack 4 — Release Control (root) + Bundle Organizer + Regions/Environments (with SBOM + Reachability surfaced)

Below is a complete Mermaid IA graph for the Release Control area (as a root menu), plus screen-by-screen Mermaid navigation graphs and ASCII mockups. Each screen includes: formerly (where it lived before) + why it moved / changed.

0) Global navigation (updated)

flowchart TD
  A[Stella Ops] --> D[Dashboard]
  A --> RC[Release Control]
  A --> SEC[Security]
  A --> EA[Evidence & Audit]
  A --> OPS[Operations]
  A --> INT[Integrations]
  A --> ADM[Administration]

What changed vs PoC:

  • In the PoC, “Release Control” is under Settings. You asked that Release Control becomes a root menu because it’s the center of gravity (release/hotfix + security + auditability).
  • “Dashboard” becomes release-centric and surfaces SBOM findings + reachability + nightly job health (second-class, not buried).

1) Release Control menu graph (full)

flowchart TD
  RC[Release Control] --> RC0[Control Plane]
  RC --> RC1[Regions & Environments]
  RC --> RC2[Bundles]
  RC --> RC3[Releases]
  RC --> RC4[Hotfixes]
  RC --> RC5[Approvals]
  RC --> RC6[Deployments]

  RC --> RC7[Configure]
  RC7 --> RC7a[Targets]
  RC7 --> RC7b[Agents]
  RC7 --> RC7c[Workflows]

  RC2 --> RC2a[Bundle Catalog]
  RC2 --> RC2b[Bundle Organizer]
  RC2 --> RC2c[Bundle Detail / Versions]

  RC3 --> RC3a[Release List]
  RC3 --> RC3b[Release Detail]

RC-DASH — Dashboard (Release Ops)

Previously

  • Formerly: Control Plane (top-level menu) – the pipeline tiles + pending approvals + active deployments. (Screenshot: “Control Plane” page.)

Now (Redesign)

  • Now: Dashboard (root) → “Release Ops Dashboard”

Why this change

  • Your requirement: the dashboard must surface SBOM findings, specifically:

    • “no issues” vs “X envs with critical reachable”
    • identify Env N / Env M with details

  • Also must surface nightly jobs health (SBOM rescan, CVE source sync, integration connectivity), and hybrid reachability coverage.

  • The PoC dashboard currently shows deployment pipeline but hides security posture and scan freshness.

Dashboard navigation graph

flowchart TD
  Dash[Dashboard] -->|click Region/Env tile| EnvDetail[Environment Detail]
  Dash -->|click "Critical Reachable"| Findings[Security Findings]
  Dash -->|click "Bundle at Risk"| BundleDetail[Bundle Detail]
  Dash -->|click "Pending Approval"| ApprovalDetail[Approval Detail]
  Dash -->|click "Nightly Jobs"| Nightly[Operations: Nightly Jobs Report]
  Dash -->|click "Release"| ReleaseDetail[Release Detail]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ DASHBOARD (Release Ops)   Time: Last 24h ▾   Region: All ▾   Env: All ▾     Search: _____     │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ AT-A-GLANCE                                                                                   │
│ ┌───────────────┐ ┌───────────────┐ ┌────────────────────┐ ┌──────────────────┐             │
│ │ Pending Appr:2 │ │ Deploying: 1  │ │ Critical Reachable │ │ Integrations     │             │
│ │ (Prod:2)       │ │ (Hotfix 1.2.4)│ │ 2 envs (Prod+UAT)   │ │ 1 degraded,1 down│            │
│ └───────────────┘ └───────────────┘ └────────────────────┘ └──────────────────┘             │
│                                                                                               │
│ ENVIRONMENT STATUS (by Region) — includes Runtime + Image SBOM + Reachability Coverage         │
│  Region tabs: [us-east] [us-west] [eu-central] [ap-south]                                      │
│  ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│  │ ENV        Runtime   Image SBOM    Reachability (Build/Registry/Runtime)   Notes         │  │
│  │ dev        OK        OK           80% / 70% / 20%                          coverage gap  │  │
│  │ staging    OK        WARN         92% / 85% / 60%                          1 med reach. │  │
│  │ uat        DEGRADED  FAIL         95% / 90% / 90%                          CRIT reachable│  │
│  │ prod       DEGRADED  FAIL         98% / 95% / 95%                          CRIT reachable│  │
│  └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ FINDINGS HOTSPOTS (Critical Reachable)              NIGHTLY HEALTH (last run)                  │
│ ┌─────────────────────────────────────────────┐    ┌───────────────────────────────────────┐ │
│ │ prod/us-east  3 CRIT reachable  (Open)  >    │    │ SBOM Rescan: FAIL (stale 2d)   >     │ │
│ │ uat/eu-central 1 CRIT reachable (Open)  >    │    │ CVE Feed Sync: DEGRADED (NVD)  >     │ │
│ │ staging/...    0                              │    │ Integration Check: OK                │ │
│ └─────────────────────────────────────────────┘    │ Evidence Sign/Verify: OK               │ │
│                                                   └───────────────────────────────────────┘ │
│                                                                                               │
│ RECENT BUNDLES / RELEASES                                                                      │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Bundle v2.1.0 (payments-suite)  -> staging  | Risk: PASS | Evidence: Complete     (Open) │  │
│ │ Hotfix 1.2.4 (auth-service)     -> prod     | Risk: WARN | Evidence: Partial      (Open) │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC0 — Control Plane (Promotion pipeline)

Previously

  • Formerly: Control Plane (top-level menu) — environment pipeline + pending approvals + active deployments.

Now

  • Now: Release Control → Control Plane

Why this change

  • Control Plane is not a generic dashboard; it’s release governance execution view.
  • Dashboard stays summary; Control Plane becomes “run the shop”: promotion paths, gates, rollback/hotfix, regionalized env lanes.

Screen navigation graph

flowchart TD
  CP[RC: Control Plane] --> Env[Regions & Environments]
  CP --> Rel[Release Detail]
  CP --> Appr[Approvals]
  CP --> Dep[Deployments]
  CP --> Bund[Bundle Detail]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL / CONTROL PLANE      Region: us-east ▾   Path: dev→staging→uat→prod ▾          │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ PIPELINE (region lane)                                                                         │
│  dev            staging                 uat                     prod                            │
│ ┌─────────┐    ┌─────────────────┐     ┌─────────────────┐     ┌──────────────────────────┐    │
│ │ 0 rel   │ -> │ 2 rel | HEALTHY  │ ->  │ 0 rel | UNKNOWN  │ ->  │ 1 rel | DEGRADED         │    │
│ │ SBOM OK │    │ SBOM WARN (1)    │     │ SBOM ?           │     │ SBOM FAIL (CRIT reach.)  │    │
│ └─────────┘    └─────────────────┘     └─────────────────┘     └──────────────────────────┘    │
│                                                                                               │
│ PENDING GATES / ACTIONS                                                                       │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ [Approval] API Gateway v2.1.0  staging→prod  Policy: PASS  Reachability: OK        (Open)│  │
│ │ [Approval] User Service v3.0.0 staging→prod  Policy: BLOCK Reachability: CRIT      (Open)│  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ ACTIVE DEPLOYMENTS                                                                            │
│  Hotfix 1.2.4  → prod/us-east  status: RUNNING  agent: prod-agent-01  (View deployment)       │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC1 — Regions & Environments

Previously

  • Formerly: partial + fragmented:

    • Control Plane (only a flat pipeline, not regional)
    • Settings → Release Control → Environments (config only, no operational SBOM posture view)
    • Security screens for findings (not tied to env operational posture)

Now

  • Now: Release Control → Regions & Environments

Why this change

  • You asked for environments organized per region (missing today).
  • Each environment must show Runtime status + Image/SBOM status + Reachability coverage — not only “docker status”.

Screen navigation graph

flowchart TD
  RE[RC: Regions & Environments] --> ED[Environment Detail]
  RE --> RCcfg[Release Control: Configure/Targets]
  RE --> SECFind[Security Findings]
  RE --> Bund[Bundle Detail]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL / REGIONS & ENVIRONMENTS        Search env/bundle: ________                   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Region: us-east                                                                                │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Environment  Runtime   Bundle/Version     Image SBOM   Critical Reachable   Coverage      │  │
│ │ dev          OK        platform v1.3.0-rc1 OK          0                  B80/R70/RT20    │  │
│ │ staging      OK        api-suite v2.1.0    WARN        0                  B92/R85/RT60    │  │
│ │ uat          DEGRADED  api-suite v2.1.0    FAIL        1                  B95/R90/RT90    │  │
│ │ prod         DEGRADED  hotfix v1.2.4       FAIL        3                  B98/R95/RT95    │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ Region: eu-central                                                                             │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ ...                                                                                         │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│ Legend: Coverage = Build/Registry/Runtime                                                     │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC1a — Environment Detail

Previously

  • Formerly: not a first/second class page. Operators had to stitch together:

    • runtime health (somewhere else)
    • findings (Security → Findings)
    • SBOM analytics (Analytics → SBOM Lake)
    • reachability (not visible / scattered)
    • release context (Releases)

Now

  • Now: Release Control → Regions & Environments → Environment Detail

Why this change

  • This is where you make go/no-go decisions. It must unify:

    • what is deployed (bundle + digests)
    • SBOM posture (image + rescan freshness)
    • reachability coverage (Build/Registry/Runtime)
    • the actionable list of critical reachable issues

Screen navigation graph

flowchart TD
  ED[Environment Detail] --> Rel[Release Detail]
  ED --> Bund[Bundle Detail]
  ED --> Findings[Security Findings (filtered to env)]
  ED --> Nightly[Ops: Nightly Jobs (filtered)]
  ED --> Appr[Approvals (filtered to env)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ ENVIRONMENT: prod / us-east      Runtime: DEGRADED      Current Bundle: hotfix v1.2.4         │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ DEPLOYED ARTIFACTS (digests)                    SBOM + REACHABILITY                           │
│ ┌─────────────────────────────────────────────┐ ┌───────────────────────────────────────────┐ │
│ │ service          digest        version      │ │ Image SBOM: FAIL (3 CRIT reachable)       │ │
│ │ auth-service     sha256:...     1.2.4       │ │ Last SBOM scan: 2h ago  | Rescan: nightly │ │
│ │ api-gateway      sha256:...     2.1.0       │ │ Reachability coverage: Build 98%          │ │
│ │ worker           sha256:...     3.1.0       │ │                         Registry 95%       │ │
│ └─────────────────────────────────────────────┘ │                         Runtime 95%        │ │
│                                                └───────────────────────────────────────────┘ │
│                                                                                               │
│ TOP FINDINGS (Critical reachable)                                                             │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ CVE-2026-1234 | pkg:openssl | reachable: YES | path: api-gateway->tls->... | Fix: 1.2.5    │  │
│ │ CVE-2026-2222 | pkg:...     | reachable: YES | runtime confirmed | mitigation: VEX?       │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ NIGHTLY STATUS (impacting this env)                                                           │
│ SBOM rescan: OK  | CVE feed sync: DEGRADED (NVD) | Integration: Jenkins WARN | Evidence: OK   │
│                                                                                               │
│ ACTIONS: [Open Approvals] [Request Hotfix] [Force Rescan] [Generate Evidence Bundle]          │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC2a — Bundle Catalog

Previously

  • Formerly: there is no “bundle catalog”.

  • The closest analogs:

    • Releases list (but it’s a mixed concept: release events + component sets)
    • ad-hoc “create release” flow (digest-first, per release)

Now

  • Now: Release Control → Bundles → Bundle Catalog

Why this change

  • You asked for a Release Bundle Organizer: bundles must be first-class.

  • Bundles are the stable unit that carries:

    • component digests
    • version mapping
    • config materialization (Vault/Consul)
    • per-repo change log
    • security posture + evidence completeness

Screen navigation graph

flowchart TD
  BC[Bundle Catalog] --> BO[Bundle Organizer (create version)]
  BC --> BD[Bundle Detail]
  BC --> RL[Release List (filtered by bundle)]
  BC --> ED[Environment Detail (where deployed)]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE CONTROL / BUNDLES / CATALOG        [Create Bundle]   Search: ________   Risk: All ▾  │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Bundles                                                                                       │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Bundle            Latest Version   Repos(services)   Risk (CRIT reach)  Evidence   Deployed│  │
│ │ payments-suite    v2.1.0           6 (12 svcs)       PASS (0)           COMPLETE   staging │  │
│ │ platform-core     v1.3.0-rc1       3 (8 svcs)        WARN (0)           PARTIAL    dev     │  │
│ │ hotfix-auth       v1.2.4           1 (1 svc)         FAIL (3)           COMPLETE   prod    │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│ Actions per row: (Open) (New Version) (Promote) (Export Evidence)                               │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC2b — Bundle Organizer (NEW: bundle composition + config materialization + changelog)

Previously

  • Formerly: scattered across:

    • Releases → Create Release (component selection/digest)
    • SCM/CI/CD systems for “what changed”
    • Vault/Consul for runtime config (not captured as release artifact)
    • Evidence/attestations stored elsewhere (not presented as bundle version contract)

Now

  • Now: Release Control → Bundles → Bundle Organizer

Why this change

  • Your explicit requirement:

    • microservice digest becomes version X
    • plus env variables derived from Vault + Consul
    • plus other microservices becomes a bundle
    • plus change log per repository

  • This turns releases into an auditable contract: “this exact set of digests + this exact config snapshot”.

Screen navigation graph

flowchart TD
  BO[Bundle Organizer] --> BD[Bundle Detail / Version]
  BO --> INT[Integrations (SCM/CI/CD/Registry/Vault/Consul)]
  BO --> SEC[Security preflight (policy + reachability)]
  BO --> EA[Evidence pack preview]
  BO --> RL[Create Release from Bundle Version]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ BUNDLE ORGANIZER (Create/Update Bundle Version)    Bundle: payments-suite ▾   Version: v2.1.1 │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ STEP BAR: ① Select repos  ② Select digests  ③ Materialize config  ④ Change log  ⑤ Validate   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ REPOSITORIES / SERVICES              DIGESTS + VERSION MAP                  CONFIG SNAPSHOT   │
│ ┌───────────────────────────────┐   ┌───────────────────────────────────┐  ┌───────────────┐ │
│ │ repo: api-gateway             │   │ svc          digest      ver       │  │ Env: staging  │ │
│ │   commits: 9 (since v2.1.0)   │   │ api-gateway  sha256...   2.1.1     │  │ Vault: path…  │ │
│ │ repo: auth-service            │   │ auth-service sha256...   1.2.5     │  │ Consul: kv…   │ │
│ │   commits: 2                  │   │ worker       sha256...   3.1.1     │  │ Resolved vars │ │
│ │ repo: worker                  │   │ ...                               │  │  DB_URL=...   │ │
│ └───────────────────────────────┘   └───────────────────────────────────┘  │  FEATURE_X=on │ │
│                                                                            └───────────────┘ │
│                                                                                               │
│ CHANGE LOG (per repository)                                                                   │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ api-gateway: PR#123 add rate limiting | PR#128 fix header parsing                          │  │
│ │ auth-service: PR#77 fix auth timeout                                                      │  │
│ │ worker: PR#44 reduce queue retries                                                       │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ PREFLIGHT VALIDATION                                                                          │
│ Policy simulation: PASS  | SBOM delta scan: WARN (1 MED) | Reachability: OK | Evidence: Ready │
│ ACTIONS: [Save Bundle Version] [Create Release Run] [Export Bundle Manifest]                  │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC2c — Bundle Detail / Versions

Previously

  • Formerly: there was no bundle entity; release detail partially served as “bundle detail”.

Now

  • Now: Release Control → Bundles → Bundle Detail

Why this change

  • Bundle Detail becomes the auditable contract object:

    • versions timeline
    • component digests
    • config snapshots (Vault/Consul refs + resolved values hash)
    • SBOM posture + reachability + evidence completeness
    • links to release runs across environments

Screen navigation graph

flowchart TD
  BD[Bundle Detail] --> BV[Bundle Version Detail]
  BD --> RL[Release Runs using this bundle]
  BD --> ED[Environments where deployed]
  BD --> EA[Evidence Bundle Export]
  BD --> SEC[Security posture drilldown]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ BUNDLE: payments-suite                                                                        │
│ Latest: v2.1.1   Risk: WARN (0 CRIT reachable)   Evidence: COMPLETE   Deployed: staging, dev  │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ VERSIONS                                                                                      │
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ v2.1.1  created Feb 18  | repos changed: 3 | policy: PASS | sbom: WARN | reach cov: 92/85/60│ │
│ │ v2.1.0  created Feb 12  | repos changed: 6 | policy: PASS | sbom: OK   | reach cov: 90/80/40│ │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│                                                                                               │
│ THIS VERSION CONTENT (v2.1.1)                                                                 │
│ Components(digests) | Config snapshot refs (Vault/Consul) | Change log per repo | Evidence    │
│ [Open version detail] [Export manifest] [Generate audit bundle]                               │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC3a — Releases list (Release Runs)

Previously

  • Formerly: Releases (top-level menu)

Now

  • Now: Release Control → Releases

Why this change

  • Releases should be treated as promotion runs of a bundle version across envs (and regions).
  • The PoC release list lacks explicit bundle/version framing and doesn’t tie in security posture at list level.

Screen navigation graph

flowchart TD
  RL[Release List] --> RD[Release Detail]
  RL --> BD[Bundle Detail]
  RL --> ED[Environment Detail]
  RL --> AP[Approvals]
  RL --> DP[Deployments]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASES (Promotion Runs)     Status: All ▾   Env: All ▾   Region: All ▾   [Create Release]   │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Release Run        Bundle/Version        Path              Status      Risk     Evidence    │  │
│ │ Hotfix 1.2.4       hotfix-auth v1.2.4    staging→prod      DEPLOYING   FAIL     COMPLETE    │  │
│ │ Platform 1.3.0-rc1 platform-core v1.3.0  dev→staging       READY       WARN     PARTIAL     │  │
│ │ API Gateway 2.1.0  payments-suite v2.1.0 staging→prod      PENDING     PASS     COMPLETE    │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
│ Row actions: Open | Approvals | Deployment | Export Evidence                                   │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC3b — Release Detail (promotion, policy, SBOM, reachability, evidence)

Previously

  • Formerly: release detail was implicit/limited; approvals had some gating info; security detail was elsewhere.

Now

  • Now: Release Control → Releases → Release Detail

Why this change

  • Release Detail must unify:

    • approval gates (policy + human)
    • SBOM posture (including reachable critical)
    • hybrid reachability coverage (Build/Registry/Runtime)
    • evidence chain status (signing/rekor/proof)

Screen navigation graph

flowchart TD
  RD[Release Detail] --> APD[Approval Detail]
  RD --> DP[Deployment Detail]
  RD --> BD[Bundle Version Detail]
  RD --> Findings[Security Findings filtered]
  RD --> EA[Evidence Bundle + Proof Chains]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ RELEASE RUN: API Gateway 2.1.0     Bundle: payments-suite v2.1.0    staging → production       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ GATES                                                                                          │
│ ┌───────────────────────────────┐  ┌───────────────────────────────┐  ┌─────────────────────┐ │
│ │ Policy Gates: PASS (2/2)      │  │ Human Approvals: 1/2          │  │ Evidence: COMPLETE  │ │
│ │ Reachability requirement: OK  │  │ Pending: sec-lead             │  │ DSSE ✓ Rekor ✓      │ │
│ └───────────────────────────────┘  └───────────────────────────────┘  └─────────────────────┘ │
│                                                                                               │
│ SECURITY POSTURE                                                                              │
│ SBOM: WARN (0 CRIT reachable, 1 MED)   | Coverage: Build 92% / Registry 85% / Runtime 60%     │
│ Top deltas: +pkgX 1.2.3  -pkgY 4.5.6                                                            │
│ [Open findings] [Request VEX] [Force rescan]                                                   │
│                                                                                               │
│ PROMOTION TIMELINE                                                                            │
│ staging: READY  → prod: PENDING APPROVAL  → (deploy agent: prod-agent-01)                      │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC4 — Hotfixes

Previously

  • Formerly: hotfixes are just “Releases” with a name “Hotfix …”, not a first-class fast-path.

Now

  • Now: Release Control → Hotfixes

Why this change

  • Hot patches are central to Stella Ops: they deserve:

    • dedicated queue
    • forced visibility on dashboard
    • explicit “expedite policy” handling (still audited)

Screen navigation graph

flowchart TD
  HX[Hotfixes] --> RD[Release Detail (hotfix mode)]
  HX --> AP[Approvals]
  HX --> ED[Environment Detail]
  HX --> EA[Evidence export]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ HOTFIXES     Status: All ▾   Region: All ▾   [Request Hotfix]                                  │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Hotfix          Target Env     Status      CRIT Reachable  Evidence   Requested By         │  │
│ │ Hotfix 1.2.4     prod/us-east   DEPLOYING   3              COMPLETE   security-team        │  │
│ │ Hotfix 1.2.3     prod/eu        DEPLOYED    0              COMPLETE   deploy-bot           │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC5 — Approvals (release-centric)

Previously

  • Formerly: Approvals (top-level menu)

Now

  • Now: Release Control → Approvals (still can be quick-access pinned)

Why this change

  • Approvals are a release control primitive; they belong under Release Control.
  • Also: approvals must show SBOM+reachability and not only “policy gates pass/block”.

Screen navigation graph

flowchart TD
  AP[Approvals Queue] --> APD[Approval Detail]
  AP --> RD[Release Detail]
  AP --> Findings[Security Findings]
  AP --> EA[Evidence]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ APPROVALS     Status: Pending ▾  Env: prod ▾  Sort: Risk ▾                                      │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ [1] API Gateway v2.1.0  staging→prod  Policy: PASS  Reachability: OK  SBOM: OK     (Open)     │
│     Evidence: COMPLETE | Requested: alice.johnson | Age: 36d                                     │
│                                                                                               │
│ [2] User Service v3.0.0 staging→prod  Policy: BLOCK Reachability: CRIT  SBOM: FAIL  (Open)     │
│     CRIT reachable: CVE-... | Evidence: PARTIAL | Requested: david.wilson | Age: 36d           │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC5a — Approval Detail (decision with full context)

Previously

  • Formerly: approval cards + minimal “View Details”.

Now

  • Now: Release Control → Approvals → Approval Detail

Why this change

  • Approval must be explainable (audit):

    • “what changed” (bundle changelog per repo)
    • “what’s the risk” (reachability, criticality)
    • “what evidence exists” (SBOMs, attestations, policy decision record)

Screen navigation graph

flowchart TD
  APD[Approval Detail] --> BD[Bundle Version Detail]
  APD --> Findings[Findings (delta+reachable)]
  APD --> EA[Evidence Packet / Proof Chain]
  APD --> RD[Release Detail]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ APPROVAL: User Service v3.0.0-rc1   staging → production   Risk: HIGH                           │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ SUMMARY: Policy: BLOCK (2 gates failed)  | CRIT reachable: 1 | Evidence: PARTIAL               │
│                                                                                               │
│ WHAT CHANGED (per repo)                                                                      │
│ - auth-service: PR#77 fix auth timeout                                                        │
│ - api-gateway: PR#123 rate limiting                                                           │
│                                                                                               │
│ SECURITY (hybrid reachability)                                                                │
│ Coverage: Build 95% / Registry 90% / Runtime 90%                                               │
│ Blocking item: CVE-2026-XXXX reachable via api-gateway->...                                    │
│                                                                                               │
│ EVIDENCE                                                                                       │
│ SBOMs: present ✓ | Attestations: missing ✗ | Policy Decision: present ✓ | Rekor: present ✓     │
│                                                                                               │
│ DECISION: [Approve] [Reject] [Request VEX] [Request Rescan] [Request Exception]                │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC6 — Deployments (promotion execution)

Previously

  • Formerly: deployment execution signals were split:

    • Control Plane active deployments summary
    • Operations → Orchestrator / Scheduler (technical execution)
    • “Deployment status” not tied cleanly to release run object

Now

  • Now: Release Control → Deployments (release-run aware), still links to Ops internals

Why this change

  • Release operators need a release-centric deployment view:

    • “this release run” → “these targets” → “this agent” → status/logs

  • Ops remains for deep platform internals; Release Control shows the release execution view.

Screen navigation graph

flowchart TD
  DEP[RC: Deployments] --> RD[Release Detail]
  DEP --> ED[Environment Detail]
  DEP --> OPS[Operations: Orchestrator/Scheduler (deep)]
  DEP --> DLQ[Operations: Dead Letter]

ASCII mock

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ DEPLOYMENTS (Release execution)   Time: 24h ▾   Status: Running ▾                              │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐  │
│ │ Release Run        Target             Agent            Status     Logs     Retry / Rollback │  │
│ │ Hotfix 1.2.4       prod/us-east       prod-agent-01    RUNNING    View     (Retry) (Rollback)│ │
│ │ API Gateway 2.1.0  prod/eu-central    prod-agent-eu    QUEUED     View     (Cancel)         │  │
│ └─────────────────────────────────────────────────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC7 — Configure (Targets, Agents, Workflows) — moved out of Settings

RC7a — Targets

Previously

  • Formerly: Settings → Release Control → Targets

Now

  • Now: Release Control → Configure → Targets

Why this change

  • Targets are not “generic settings”; they’re release control primitives tied to region/env topology.
flowchart TD
  T[Targets] --> TE[Target Detail]
  T --> RE[Regions & Environments]
  T --> AG[Agents]

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ CONFIGURE / TARGETS     [Add Target]   Region: us-east ▾                                       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Target Name     Type       Bound Env(s)           Status     Agent Pool                        │
│ prod-us-east    k8s        prod/us-east           OK         prod-agent-01,02                   │
│ uat-eu          k8s        uat/eu-central         WARN       uat-agent-eu                       │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC7b — Agents

Previously

  • Formerly: Settings → Release Control → Agents

Now

  • Now: Release Control → Configure → Agents

Why this change

  • Agents are part of the release execution chain; operators need them in release context.
flowchart TD
  AG[Agents] --> AGD[Agent Detail]
  AG --> DEP[Deployments]
  AG --> PH[Operations: Platform Health]

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ CONFIGURE / AGENTS     [Register Agent]                                                       │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Agent           Region     Last Seen   Capability (deploy/scan)   Status                        │
│ prod-agent-01   us-east    2m ago      deploy+runtime-scan        OK                            │
│ uat-agent-eu    eu-central 1h ago      deploy                      DEGRADED                      │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

RC7c — Workflows

Previously

  • Formerly: Settings → Release Control → Workflows

Now

  • Now: Release Control → Configure → Workflows

Why this change

  • Workflows define the promotion contract (gates, evidence requirements). It’s core to release control.
flowchart TD
  WF[Workflows] --> WFD[Workflow Detail]
  WF --> PG[Policy Governance]
  WF --> EA[Evidence requirements]

┌───────────────────────────────────────────────────────────────────────────────────────────────┐
│ CONFIGURE / WORKFLOWS     [Create Workflow]                                                    │
├───────────────────────────────────────────────────────────────────────────────────────────────┤
│ Workflow            Applies To        Gates (policy/human)     Evidence Requirements            │
│ standard-prod       prod/*            policy+2 approvals       SBOM+attest+rekor+decision       │
│ hotfix-expedite     prod/* hotfix     policy+1 approval        SBOM+decision+rekor              │
└───────────────────────────────────────────────────────────────────────────────────────────────┘

What I’ll send next (if you reply “continue”)

  • Pack 5: Integrations + Administration/Settings screens (Identity & Access, Trust & Signing, Policy Governance, Notifications, Usage & Limits, System, Tenant/Branding) — each with Mermaid graphs + ASCII + “formerly/why”.
  • Pack 6: Security + Evidence + Operations screens converted to the same Mermaid-per-screen + ASCII format (so everything is consistent end-to-end).