44 KiB
44 KiB
Pack 12 — Release Bundle Organizer (Bundles, Bundle Versions, Component Versions, Config + Changelog per Repo)
This pack adds the missing Release Bundle Organizer while keeping your release-first / digest-first restructuring intact, and wiring it into Release Control (regions/envs/inputs) + Approvals + Evidence + Operations (AirGap).
12.1 Menu graph (Mermaid) — where Bundle Organizer lives in the redesigned IA
Scope: only the parts relevant to bundles. This keeps Release Control as a root menu (per your instruction) and makes Bundles a first-class part of Releases, not buried.
flowchart TD
ROOT[Stella Ops Console] --> DASH[Dashboard]
ROOT --> REL[Releases]
ROOT --> APPR[Approvals]
ROOT --> SEC[Security]
ROOT --> EVID[Evidence]
ROOT --> OPS[Operations]
ROOT --> INT[Integrations]
ROOT --> RC[Release Control (ROOT)]
%% Releases submenus
REL --> REL_LIST[Releases (Promotions)]
REL --> BUNDLES[Bundles (Organizer)]
REL --> COMPONENTS[Components (Service Versions)]
%% Bundles area
BUNDLES --> B_CAT[Bundle Catalog]
BUNDLES --> B_DETAIL[Bundle Detail]
BUNDLES --> B_BUILDER[Create Bundle Version (Builder)]
BUNDLES --> BV_DETAIL[Bundle Version Detail]
BUNDLES --> B_MAT[Materialize to Environment]
BUNDLES --> B_CHANGE[Changelog (per repo)]
%% Components area
COMPONENTS --> C_CAT[Component Catalog]
COMPONENTS --> CV_DETAIL[Component Version Detail]
COMPONENTS --> C_IMPORT[Import/Sync Versions]
%% Cross-links
B_DETAIL -. "Create promotion" .-> REL_LIST
B_MAT -. "Creates approval request" .-> APPR
BV_DETAIL -. "Evidence export" .-> EVID
B_MAT -. "Uses env inputs" .-> RC
B_MAT -. "Uses Vault/Consul" .-> INT
B_MAT -. "Option: Build AirGap bundle" .-> OPS
12.2 Terminology (so screens stay unambiguous)
- Component Version = digest-first identity of a microservice image (digest is authoritative) + a display version (e.g.,
2.1.0), plus SBOM/finding snapshots and provenance links. - Bundle = logical product/service-set (e.g., “Platform Release”), with many Bundle Versions over time.
- Bundle Version = immutable snapshot: exact component digests + bundle manifest digest + policy evaluation snapshot + derived changelog pointers.
- Materialization = resolving environment-specific inputs (Vault/Consul/overrides) to produce a deployment plan for a region/env (and optionally an AirGap artifact).
12.3 Screen — Bundle Catalog
Formerly (where it “lived” pre-redesign)
-
Not a dedicated concept. Closest proxy:
- Releases list (
/releases) with “Components” count - “AirGap Bundles” existed but under Operations → Feeds → AirGap Bundles (offline artifact focus, not release model focus)
- Releases list (
Why changed like this
- Stella is release-centric; releases should promote bundle versions (stable, versioned) rather than ad-hoc component lists.
- Operators need a canonical place to organize bundles by product/team/repo-set and track their version history.
Screen graph (Mermaid)
flowchart LR
A[Bundle Catalog] --> B[Bundle Detail]
A --> C[Create New Bundle]
A --> D[Component Catalog]
A --> E[Changelog (per repo)]
A --> F[Search/Filter by product/team/repo-set]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Releases ▸ Bundles (Organizer) │
│ Legacy: N/A (new). Previously: Releases (/releases) contained components directly. │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Search: [ platform ] Tags: [All] Team: [All] Repo-set: [All] Status: [Active] │
│ Actions: [+ New Bundle] [Import from Repo Set] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────┬──────────┬───────────────┬─────────────────┬────────────────┐│
│ │ Bundle │ Versions │ Last Version │ Last Promotion │ Security Signal ││
│ ├─────────────────────────────┼──────────┼───────────────┼─────────────────┼────────────────┤│
│ │ Platform Release │ 18 │ 1.3.0-rc1 │ staging → prod │ 1 crit reachable││
│ │ Hotfix Bundle │ 6 │ 1.2.4 │ prod │ clean ││
│ │ Feature Branch Preview │ 3 │ 2.0.0-alpha │ dev │ info only ││
│ └─────────────────────────────┴──────────┴───────────────┴─────────────────┴────────────────┘│
│ Click a bundle → Bundle Detail │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.4 Screen — Bundle Detail (Overview + Versions + Deployments)
Formerly
-
Partially in:
- Releases row detail (implicit)
- “Create Release” (implicit composition)
- “Approvals” (promotion context)
-
But no persistent bundle object existed.
Why changed like this
-
Bundle is the stable unit of release governance:
- It is what you reason about (changelog, SBOM summary, reachability coverage).
- Releases become “promotions of bundle version X to env Y”.
-
It’s also where you attach bundle-level intent (owner/team, repo-set, default workflow).
Screen graph (Mermaid)
flowchart TD
A[Bundle Detail] --> B[Versions Tab]
A --> C[Deployments/Promotions Tab]
A --> D[Components Tab]
A --> E[Config & Inputs Tab]
A --> F[Changelog Tab (per repo)]
A --> G[Create Bundle Version]
A --> H[Materialize to Environment]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Bundle: Platform Release │
│ Legacy: N/A (new). Previously: “Platform Release” existed only as a Release row in /releases │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Owner: ci-pipeline Team: platform Repo-set: {api-gw, user-svc, web-fe, worker} │
│ Default workflow: Canary 10→50→100 Default policy baseline: Prod │
│ │
│ Tabs: [Overview] [Versions] [Promotions] [Components] [Config & Inputs] [Changelog] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Overview │
│ Latest Bundle Version: 1.3.0-rc1 Bundle Manifest Digest: sha256:abcd... │
│ Security Snapshot: 1 critical reachable | 0 high reachable | VEX coverage 62% │
│ Reachability Coverage: Image 100% | Build 78% | Runtime 35% │
│ │
│ Actions: [Create New Bundle Version] [Materialize to Env] [Create Promotion/Release] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.5 Screen — Create Bundle Version (Builder / Wizard)
Formerly
-
Implicit in:
- Releases → + Create Release (user picked components / versions ad-hoc)
- CI pipeline output (digest exists, but bundle composition logic is external/manual)
Why changed like this
-
You explicitly want:
- “microservice with digest becomes version X”
- “bundle includes variables derived from Vault/Consul for env”
- “bundle includes changelog per repository”
-
This requires an explicit builder that:
- selects component versions (digests),
- computes changelog diffs,
- validates SBOM + reachability coverage readiness,
- produces an immutable bundle version.
Screen graph (Mermaid)
flowchart TD
A[Bundle Version Builder] --> S1[Step 1: Base Version]
A --> S2[Step 2: Select Component Versions]
A --> S3[Step 3: Config Contracts (vars required)]
A --> S4[Step 4: Changelog Preview (per repo)]
A --> S5[Step 5: Validate (policy + readiness)]
A --> S6[Step 6: Finalize → Create Bundle Version]
S6 --> BV[Bundle Version Detail]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Create Bundle Version — Platform Release │
│ Legacy: Releases ▸ +Create Release (implicit) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Steps: (1) Base (2) Components (3) Config (4) Changelog (5) Validate (6) Finalize │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ (1) Base Version │
│ Base: [ 1.2.3 ] (diff will be computed vs base) │
│ New version label: [ 1.3.0-rc1 ] │
│ Notes: [ Release candidate for next major version ] │
│ │
│ Next → │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.6 Screen — Builder Step: Select Component Versions (digest-first → display version)
Formerly
- Components were directly attached to a Release row; versions/digests were not first-class.
- Digest→version mapping usually lived in CI/repo tags and wasn’t visible in Stella.
Why changed like this
- Digest-first is required for determinism; version labels help humans.
- This screen makes it explicit and auditable: what digest is being promoted and why we call it version X.
Screen graph (Mermaid)
flowchart LR
A[Select Component Versions] --> B[Pick from Component Catalog]
A --> C[Import latest from CI/Registry]
A --> D[Open Component Version Detail]
A --> E[Continue to Config Contracts]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Create Bundle Version — Step (2) Components │
│ Legacy: Release row “Components: N” (no explicit digest→version mapping UI) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Repo-set: api-gw, user-svc, web-fe, worker │
│ │
│ ┌───────────────┬───────────────┬───────────────────────────┬─────────────┬──────────────────┐│
│ │ Component │ Display Ver. │ Digest (authoritative) │ SBOM Status │ Reachability ││
│ ├───────────────┼───────────────┼───────────────────────────┼─────────────┼──────────────────┤│
│ │ api-gateway │ 2.1.0 │ sha256:1111... │ OK │ Image+Build ││
│ │ user-service │ 3.0.0-rc1 │ sha256:2222... │ OK │ Image only (gap) ││
│ │ web-frontend │ 2.0.0 │ sha256:3333... │ OK │ Image+Runtime ││
│ │ worker │ 3.1.0 │ sha256:4444... │ PENDING │ — ││
│ └───────────────┴───────────────┴───────────────────────────┴─────────────┴──────────────────┘│
│ Actions: [Import Latest] [Open Component Detail] │
│ Gate note: “SBOM PENDING” will block finalize if policy requires SBOM for prod. │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.7 Screen — Builder Step: Config Contracts (variables required by services)
Formerly
-
Config came from outside Stella or scattered across:
- Vault (secrets),
- Consul (KV),
- deployment manifests,
- Release Control env config.
Why changed like this
-
You want bundle to include “variables derived from Vault/Consul for this env”.
-
To do that deterministically, Stella needs:
- a contract: what variables each service requires,
- a binding: where to source them per region/env.
Design choice:
- Contracts live with the bundle/component (what is needed).
- Bindings live with Release Control → Environment Inputs (where it comes from in a region/env). This keeps “what” separate from “where”.
Screen graph (Mermaid)
flowchart TD
A[Config Contracts Step] --> B[View service variable requirements]
A --> C[Link to Env Bindings (Release Control)]
A --> D[Validate: missing bindings?]
A --> E[Continue to Changelog]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Create Bundle Version — Step (3) Config Contracts │
│ Legacy: N/A (new). Previously: env vars existed in Vault/Consul + manifests, not bundled. │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Variable requirements (by component) │
│ │
│ api-gateway │
│ - RATE_LIMIT_MAX (required) source: consul kv key: service/api-gw/rate_limit_max │
│ - JWT_PUBLIC_KEYS (required) source: vault path: secret/api-gw/jwt_keys │
│ │
│ user-service │
│ - AUTH_TIMEOUT_MS (required) source: consul kv key: service/user/auth_timeout_ms │
│ - DB_PASSWORD (required) source: vault path: secret/user/db_password │
│ │
│ Binding check (target env later): │
│ US-East/us-prod: 2 missing bindings (DB_PASSWORD, JWT_PUBLIC_KEYS) → will block materialize │
│ Link: [Open Release Control → us-prod → Inputs] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.8 Screen — Builder Step: Changelog Preview (per repository)
Formerly
- Changelog was manual or external (GitHub/GitLab release notes), not attached to the release object in Stella.
Why changed like this
-
You require “bundle along with change log, per repository”.
-
This gives reviewers and auditors a deterministic view:
- “what changed in api-gw between digest A and digest B”
- tied to the exact component versions.
Screen graph (Mermaid)
flowchart LR
A[Changelog Preview] --> B[Repo diff summary per component]
A --> C[Expand commit/PR list]
A --> D[Export changelog]
A --> E[Continue to Validate]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Create Bundle Version — Step (4) Changelog (per repo) │
│ Legacy: N/A (new). Previously: release notes lived in SCM/CI tools, not in Stella. │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Base: 1.2.3 → New: 1.3.0-rc1 │
│ │
│ api-gateway: 12 commits (3 PRs) │
│ • PR #431: add rate limiting feature │
│ • PR #428: fix header parsing bug │
│ │
│ user-service: 4 commits (1 PR) │
│ • PR #77: critical fix for user authentication timeout │
│ │
│ web-frontend: 2 commits │
│ worker: 0 commits │
│ │
│ [Export as Markdown] [Attach to Bundle Version Notes] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.9 Screen — Builder Step: Validate (policy readiness + SBOM + feeds + reachability)
Formerly
-
Validation was split:
- Approvals page mentions policy + reachability,
- Security pages show findings,
- Operations show feeds/job status,
- none were unified at “bundle creation”.
Why changed like this
- Bundle version should be created as an auditable artifact with a clear “ready for prod?” signal.
- This is where we prevent “unknown SBOM state” from entering promotion pipeline.
Screen graph (Mermaid)
flowchart TD
A[Validate Bundle Version] --> B[Policy Gate Evaluation Snapshot]
A --> C[SBOM & Findings Readiness]
A --> D[Hybrid Reachability Coverage Check]
A --> E[Feed Freshness / Integration Health]
A --> F[Finalize]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Create Bundle Version — Step (5) Validate │
│ Legacy: distributed across Approvals + Security + Ops + Integrations │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Policy baseline: Prod (US-East) │
│ │
│ Gates │
│ ✓ All component digests resolved │
│ ✗ SBOM scan pending: worker sha256:4444... (required for prod) │
│ ✓ CVE feeds fresh (NVD: synced 1h ago, OSV: synced 20m ago) │
│ ⚠ Hybrid reachability coverage: runtime evidence 35% (policy: warn, not block) │
│ │
│ Action required: [Trigger SBOM Scan Now] (or change component selection) │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.10 Screen — Bundle Version Detail (immutable snapshot + evidence pointers)
Formerly
-
Not a first-class object. Closest:
- Release detail (not shown in PoC screenshots) + Evidence exports
- But there was no immutable “bundle version” with its own digest.
Why changed like this
-
This is the deterministic record that promotions reference:
- It is what you replay/verify against,
- what you export evidence for,
- what you diff between versions.
Screen graph (Mermaid)
flowchart TD
A[Bundle Version Detail] --> B[Manifest Tab (digests + versions)]
A --> C[Security Snapshot Tab]
A --> D[Reachability Coverage Tab]
A --> E[Changelog Tab]
A --> F[Evidence Tab (DSSE/provenance links)]
A --> G[Promote/Materialize Actions]
A --> H[Diff vs previous version]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Bundle Version: Platform Release 1.3.0-rc1 │
│ Legacy: N/A (new). Previously: release rows mixed composition + promotion. │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Bundle manifest digest: sha256:abcd... Created: Jan 11, 2026 by ci-pipeline │
│ Base version: 1.2.3 Diff: +2 components changed, +16 commits total │
│ │
│ Tabs: [Manifest] [Security] [Reachability] [Changelog] [Evidence] [Promotions] [Diff] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Manifest (digest-first) │
│ api-gateway v2.1.0 sha256:1111... SBOM OK │
│ user-service v3.0.0-rc1 sha256:2222... SBOM OK │
│ web-frontend v2.0.0 sha256:3333... SBOM OK │
│ worker v3.1.0 sha256:4444... SBOM OK │
│ │
│ Actions: [Materialize to Env] [Create Promotion] [Export Evidence Pack] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.11 Screen — Component Catalog (Service Versions)
Formerly
-
Implicit:
- registry contains digests
- CI contains build versions
- Stella UI doesn’t centralize digest→version mapping, SBOM state, reachability sources
Why changed like this
-
You need a stable bridge:
- digest-first identity,
- human-friendly version labels,
- SBOM + reachability metadata used by bundle builder and approvals.
Screen graph (Mermaid)
flowchart LR
A[Component Catalog] --> B[Component Version Detail]
A --> C[Import from Registry/CI]
A --> D[Manage Version Mapping Rules]
A --> E[Link to bundles using this component]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Releases ▸ Components (Service Versions) │
│ Legacy: N/A (new). Previously: versions lived in CI/registry only. │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Filter: Repo [All] SBOM [All] Reachability [Any] Deployed [Any] │
│ Actions: [Import Latest] [Sync Now] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ ┌───────────────┬───────────────┬───────────────────────┬──────────┬────────────────────────┐│
│ │ Component │ Version Label │ Digest │ SBOM │ Reachability Sources ││
│ ├───────────────┼───────────────┼───────────────────────┼──────────┼────────────────────────┤│
│ │ api-gateway │ 2.1.0 │ sha256:1111... │ OK │ image, build ││
│ │ user-service │ 3.0.0-rc1 │ sha256:2222... │ OK │ image ││
│ │ web-frontend │ 2.0.0 │ sha256:3333... │ OK │ image, runtime ││
│ └───────────────┴───────────────┴───────────────────────┴──────────┴────────────────────────┘│
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.12 Screen — Component Version Detail (SBOM + findings + hybrid reachability)
Formerly
-
SBOM/finding visibility existed, but:
- Findings list was global and empty in PoC,
- Reachability concept existed in approvals but not clearly traceable to image/build/runtime sources,
- No single “component version truth page”.
Why changed like this
-
This screen is the forensic anchor:
- if a bundle is blocked, you drill into the component version to see why (SBOM, CVEs, reachability evidence sources).
Screen graph (Mermaid)
flowchart TD
A[Component Version Detail] --> B[SBOM Summary]
A --> C[Findings (reachable/not)]
A --> D[Reachability (image/build/runtime)]
A --> E[Provenance/Attestations]
A --> F[Used-in Bundles]
A --> G[Deployed-in Environments]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Component Version: user-service v3.0.0-rc1 │
│ Digest: sha256:2222... │
│ Legacy: N/A (new). Previously: info split across registry + approvals + security views. │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Tabs: [SBOM] [Findings] [Reachability] [Provenance] [Used-in Bundles] [Deployed-in Envs] │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Findings snapshot │
│ Critical reachable: 0 High reachable: 0 High not reachable: 2 │
│ VEX: statement present for CVE-XXXX (not exploitable: config) │
│ │
│ Reachability coverage │
│ Image evidence: ✓ Build evidence: ✗ Runtime evidence: ✗ │
│ Note: policy may warn or block based on baseline. │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.13 Screen — Materialize Bundle Version to Environment (resolve Vault/Consul + produce deployment plan)
Formerly
- No explicit step. Operators/CI manually resolved env inputs and then deployed.
- Release Control had environment config; Integrations had Vault; but no “bundle→env resolved view”.
Why changed like this
-
Your requirement explicitly: “bundle includes variables derived from vaults and consul for this env”.
-
This screen is where the bundle becomes deployable in a specific region/env:
- resolve required variables,
- detect missing bindings,
- produce a deterministic deployment plan,
- then create a promotion/approval.
Screen graph (Mermaid)
flowchart TD
A[Materialize Bundle → Environment] --> B[Select Region/Env]
A --> C[Resolve Inputs (Vault/Consul)]
A --> D[Show Missing/Overrides]
A --> E[Generate Deployment Plan]
A --> F[Create Promotion/Approval]
A --> G[Optional: Build AirGap Artifact]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Materialize: Platform Release 1.3.0-rc1 → US-East / us-prod │
│ Legacy: N/A (new). Previously: env vars resolved outside Stella, deployment was external. │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Inputs resolution │
│ ✓ consul: service/api-gw/rate_limit_max = 500 │
│ ✓ vault: secret/api-gw/jwt_keys = (sealed) │
│ ✗ vault: secret/user/db_password = MISSING (binding not configured) │
│ │
│ Result │
│ Status: BLOCKED (cannot materialize) │
│ Fix: [Open Release Control → US-East/us-prod → Inputs] │
│ │
│ When resolved: [Generate Deployment Plan] [Create Promotion Request] [Build AirGap Bundle] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.14 Screen — Changelog (per repo) for a Bundle Version (drilldown)
Formerly
- External to Stella (SCM release notes / PR list / commit diff)
Why changed like this
- Auditors and approvers need changelog tied to exact digests.
- This page also prevents “bundle label changed but nothing actually changed” confusion.
Screen graph (Mermaid)
flowchart LR
A[Bundle Version Changelog] --> B[Repo-level diff]
A --> C[Commit/PR detail]
A --> D[Export (md/pdf)]
A --> E[Link to approvals referencing this version]
ASCII mock
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Changelog — Platform Release 1.3.0-rc1 (vs 1.2.3) │
│ Legacy: N/A (new). Previously: changelog was not a Stella object. │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ api-gateway │
│ + PR #431 rate limiting feature │
│ + PR #428 header parsing fix │
│ │
│ user-service │
│ + PR #77 auth timeout critical fix │
│ │
│ web-frontend │
│ + commit 8f2a... update UI │
│ │
│ Exports: [Markdown] [Attach to Evidence Packet] │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
12.15 Screen — Optional integration: Build AirGap Bundle (linking to existing Ops screen)
Formerly
- Operations → Feeds → AirGap Bundles (tab), disconnected from release objects.
Why changed like this
- AirGap artifacts should be generated from a specific bundle version + environment materialization.
- Keep the existing Ops screen (for storage/transfer), but initiate and trace it from the bundle context.
Screen graph (Mermaid)
flowchart LR
A[Bundle Version Detail] --> B[Materialize to Env]
B --> C[Build AirGap Bundle]
C --> D[Operations → AirGap Bundles (tracking)]
D --> E[Download/Transfer/Verify]
ASCII mock (in-bundle launch)
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
│ Build AirGap Bundle │
│ Legacy: Ops ▸ Feeds ▸ AirGap Bundles (no release linkage) │
├──────────────────────────────────────────────────────────────────────────────────────────────┤
│ Source: Platform Release 1.3.0-rc1 (bundle digest sha256:abcd...) │
│ Target: US-East / us-prod │
│ Includes: images (14) + manifests + resolved config overlays + checksums │
│ │
│ [Start Build] → tracking will appear in Ops ▸ AirGap Bundles │
└──────────────────────────────────────────────────────────────────────────────────────────────┘
What this changes elsewhere (minimal but necessary touchpoints)
To preserve functionality yet make it “Stella Ops way”, two UI pivots must happen:
-
Releases list (
/releases)- continues to exist, but each release row becomes: Promotion of {Bundle Version} to {Env path}
- “Components” column becomes derived from bundle version.
-
Approvals (
/approvals)- approvals reference bundle version digest + materialization result (inputs resolved / missing).
These are cross-screen wiring changes; the new screens in this pack provide the missing first-class objects required to make that consistent and auditable.
If you want the next pack, I can do Pack 13: “Releases + Approvals screens updated to reference Bundle Versions everywhere” (Mermaid graphs + ASCII mocks + legacy naming).