Pack 2 — Integrations + Admin/Settings + Feeds + Release Bundle Organizer (new)
Below you get:
- Mermaid menu graphs (global + per area)
- For each screen in this pack: (a) “Previously / why moved”, (b) a Mermaid screen graph, © an ASCII wireframe that also shows “formerly called …” inside the screen header.
1) Menu graphs (Mermaid)
1.1 Global navigation map (v3 IA)
mindmap
root((Stella Ops))
Dashboard["Dashboard / Command Center\n(formerly: Control Plane)"]
ReleaseControl["Release Control (root)"]
Releases["Releases"]
ReleaseBundles["Release Bundles (NEW)"]
BundleCatalog["Bundle Catalog"]
BundleOrganizer["Bundle Organizer / Composer"]
BundleVersion["Bundle Version Detail"]
Approvals["Approvals"]
Deployments["Deployments"]
RegionsEnv["Regions & Environments"]
ReleaseSetup["Setup (Admin)"]
EnvConfig["Environments (region-aware)"]
Targets["Targets"]
Agents["Agents"]
Workflows["Workflows"]
Security["Security"]
Findings["Findings (SBOM + CVE)"]
Reachability["Hybrid Reachability"]
VEX["VEX Hub"]
Exceptions["Exceptions"]
SBOMGraph["SBOM Graph (future)"]
Evidence["Evidence & Audit"]
EvidenceBundles["Evidence Bundles"]
Packets["Evidence Packets"]
Replay["Replay / Verify"]
ProofChains["Proof Chains"]
Export["Export Center"]
Operations["Operations"]
OpsSummary["Ops Summary / Nightly Report"]
PlatformHealth["Platform Health"]
Scheduler["Scheduler Runs"]
Orchestrator["Orchestrator Jobs"]
DeadLetter["Dead Letter Queue"]
Quotas["Quotas & Throttles"]
FeedsAirgap["Feeds & AirGap"]
Integrations["Integrations"]
Overview["Overview / Health"]
SCM["SCM"]
CICD["CI/CD"]
Registries["Registries"]
Secrets["Secrets (Vault/Consul)"]
Notifications["Notifications"]
Advisory["Advisory Sources (OSV/NVD/...)"]
Admin["Administration (formerly: Settings)"]
IAM["Identity & Access"]
PolicyGov["Policy Governance"]
Trust["Trust & Signing"]
Usage["Usage & Limits"]
Tenant["Tenant & Branding"]
System["System (Admin tools)"]
Why this matches “Stella Ops way”: digest‑first promotion decisions, evidence bundles (“Decision Capsules”), hybrid reachability, and orchestration across SCM/registries/Vault/Consul are explicitly first‑class in the product’s own positioning. (Stella Ops Suite)
1.2 Integrations menu graph
flowchart TD I0["Integrations / Overview"] I1["SCM"] I2["CI/CD"] I3["Registries"] I4["Secrets (Vault / Consul)"] I5["Notifications"] I6["Advisory Sources (OSV/NVD/...)"] I7["Integration Detail (plugin page)"] I8["Test Connection"] I9["Sync Logs / Errors"] I10["Go to Ops → Feeds & AirGap"] I0 --> I1 I0 --> I2 I0 --> I3 I0 --> I4 I0 --> I5 I0 --> I6 I1 --> I7 I2 --> I7 I3 --> I7 I4 --> I7 I6 --> I7 I7 --> I8 I7 --> I9 I6 --> I10
1.3 Administration menu graph (formerly Settings)
flowchart TD A0["Administration (home)"] A1["Identity & Access"] A2["Policy Governance"] A3["Trust & Signing"] A4["Usage & Limits"] A5["Tenant & Branding"] A6["System (Admin tools)"] A1a["Users / Roles / OAuth / API Tokens / Tenants"] A2a["Baselines / Rules / Simulation / Exception Workflow"] A3a["Keys / Issuers / Certs / Rekor / Trust Scoring / Audit Log"] A4a["Usage meters + quota config"] A6a["Health / Doctor / SLO / Background Jobs"] A0 --> A1 --> A1a A0 --> A2 --> A2a A0 --> A3 --> A3a A0 --> A4 --> A4a A0 --> A5 A0 --> A6 --> A6a
1.4 Operations → Feeds & AirGap menu graph
flowchart TD F0["Ops → Feeds & AirGap (formerly Operations → Feeds)"] F1["Feed Mirrors"] F2["Mirror Detail"] F3["AirGap Bundles"] F4["AirGap Bundle Detail / Import/Export"] F5["Version Locks"] F6["Feed Sync Status (OSV/NVD/etc)"] F7["Nightly Ops Report (feed failures)"] F0 --> F1 --> F2 F0 --> F3 --> F4 F0 --> F5 F1 --> F6 F6 --> F7
1.5 Release Bundles (NEW) menu graph
flowchart TD B0["Release Bundles (root menu)"] B1["Bundle Catalog (per repo)"] B2["Bundle Organizer / Composer"] B3["Bundle Version Detail"] B4["Submit for Approval"] B5["Promote / Deploy"] B6["Evidence Capsule / Export"] B0 --> B1 --> B3 B1 --> B2 --> B3 B3 --> B4 B4 --> B5 B3 --> B6
This “bundle = set of digests (component→digest mapping)” is the invariant you want for digest‑first identity (not tags), and it’s explicitly called out as a core principle. (Gitea: Git with a cup of tea)
2) Screen pack (each: prior location + why + mermaid + ASCII)
2.1 Integrations — Overview / Health
New location: Integrations → Overview Previously: Settings → Integrations (“Integrations”) Why moved / changed:
- Integrations directly affect promotion evidence (SBOM inputs, reachability, VEX feeds, approvals, secrets) → they should be visible as an operational control surface, not buried under Settings. (Stella Ops Suite)
- Stella treats integrations as pluggable while the orchestration core stays stable—UI should reflect that with a first‑class “Integration Health” hub. (Gitea: Git with a cup of tea)
- Feed/connectivity failures must surface upstream into Nightly Ops Report and promotion gating (blocked because “NVD not synced”, “Vault unreachable”, etc.). (Stella Ops Suite)
Screen graph
flowchart LR S["Integrations Overview"] --> D["Integration Detail"] S --> W["Add Integration Wizard"] D --> T["Test Connection"] D --> L["Sync / Error Logs"] D --> P["Permissions + Scope"] S --> O["Ops → Nightly Report (integration impact)"] S --> F["Ops → Feeds & AirGap (for advisory sources)"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Stella Ops [Search…] (admin) |
|--------------------------------------------------------------------------------------------------|
| NAV | Integrations / Overview |
|---------------------------| formerly: Settings → Integrations |
| Dashboard |----------------------------------------------------------------------|
| Release Control | Status summary (last check: 2m) |
| Security | [Connected: 6] [Degraded: 1] [Disconnected: 1] |
| Evidence & Audit |----------------------------------------------------------------------|
| Operations | Filters: [All] [SCM] [CI/CD] [Registries] [Secrets] [Notif] [Feeds] |
| Integrations (YOU ARE) |----------------------------------------------------------------------|
| Administration | Integration Health Matrix |
| | NAME TYPE STATUS LAST SYNC IMPACT |
| | GitHub Enterprise SCM ✅ 5m release notes |
| | GitLab SaaS SCM ✅ 2m changelog |
| | Jenkins CI/CD ⚠️ 1h build attest. |
| | Harbor Registry Registry ✅ 30m image pulls |
| | Vault Secrets ✅ 10m env vars |
| | Consul Secrets ☐ add — service config |
| | OSV Feed Advisory ✅ 1h CVE source |
| | NVD Feed Advisory ❌ — CVE source |
| |----------------------------------------------------------------------|
| | Actions: [Add Integration] [View Ops Impact] [Go to Feeds & AirGap] |
+--------------------------------------------------------------------------------------------------+
2.2 Integration Detail (plugin page template)
New location: Integrations → (pick category) → Integration Detail Previously: Settings → Integrations (tile click opened details) Why changed:
- Make every connector feel like a plugin with a consistent diagnostic footprint: scopes, sync lag, last errors, and “what release-control artifacts depend on it.” (Gitea: Git with a cup of tea)
- Explicit “Impact” is critical for buyers: if this is down, what breaks (e.g., SBOM ingest, CVE feed, approvals, evidence export). (Gitea: Git with a cup of tea)
Screen graph
flowchart TB D["Integration Detail"] --> C["Config"] D --> S["Status + Health"] D --> E["Errors / Logs"] D --> X["Test Connection"] D --> I["Impact Map (what depends on this)"] C --> P["Permissions / Scopes"] C --> R["Rate limits / schedules"] I --> RC["Release Control gates affected"] I --> OPS["Ops alerts + nightly report"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Integrations / Harbor Registry [Test] [Disable] |
| formerly: Settings → Integrations → Harbor Registry |
|--------------------------------------------------------------------------------------------------|
| Status: ✅ Connected Last sync: 30m Next sync: 30m Owner: platform-team |
|--------------------------------------------------------------------------------------------------|
| Tabs: [Overview] [Config] [Scopes] [Logs] [Impact] |
|--------------------------------------------------------------------------------------------------|
| Overview |
| Endpoint: https://harbor.example.internal |
| Auth: Robot token ************ |
| Repos tracked: 42 Images/day: 110 Errors(24h): 0 |
|--------------------------------------------------------------------------------------------------|
| Impact (why this matters) |
| - Bundle composer: resolves tags → digests |
| - Releases: promotion pulls from this registry |
| - Evidence: stores resolved digest mapping |
| If DOWN: promotions blocked (reason: "registry unreachable") |
+--------------------------------------------------------------------------------------------------+
2.3 Notifications (Rules + Channels + Templates)
New location: Integrations → Notifications Previously: Settings → Notifications Why moved / changed:
- Notifications are effectively an integration surface (email/Slack/webhooks) and should live alongside other connectors.
- Also: “policy gates + approvals + ops incidents” generate events that must be provably delivered / auditable (store delivery logs as part of evidence trail if needed). (Stella Ops Suite)
Screen graph
flowchart LR N["Notifications Home"] --> R["Rule Builder"] N --> CH["Channels"] N --> T["Templates"] N --> L["Delivery / Activity Log"] R --> EVT["Event catalog (Approvals, Blocks, Feed stale, SBOM rescan fail...)"] CH --> SL["Slack config"] CH --> EM["Email config"] CH --> WH["Webhook config"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Integrations / Notifications [Add Rule] [Edit Tmpl] |
| formerly: Settings → Notifications |
|--------------------------------------------------------------------------------------------------|
| LEFT: Rules | RIGHT: Channels | Templates |
|------------------------------------------+----------------------------------+------------------|
| Rule: "Block promotion on reachable crit"| Email ✅ active | Default: Gate |
| When: Approval requested | Slack ✅ active | Default: Approval |
| Then: Slack #release-approvals | Webhook ⚠ not configured | Default: Ops |
|------------------------------------------+----------------------------------+------------------|
| Rule: "Ops: NVD stale > 24h" | | [Edit Templates] |
| When: Advisory feed stale | | |
| Then: Email secops@... + webhook | | |
|--------------------------------------------------------------------------------------------------|
| Activity Log (delivery) |
| 08:30 Slack ✅ "Promotion blocked: reachable CVEs" approval-id=ap-1021 |
| 08:31 Email ✅ "NVD stale > 24h" ops-incident=inc-77 |
+--------------------------------------------------------------------------------------------------+
3) Operations: Feeds & AirGap
3.1 Ops → Feeds & AirGap (Feed Mirrors list)
New location: Operations → Feeds & AirGap → Feed Mirrors Previously: Operations → Feeds (“Feed Mirror & AirGap Operations”) Why changed:
- Feeds/mirroring is operationally tied to air‑gap readiness and advisory freshness—both are directly called out as core capabilities. (Stella Ops Suite)
- Mirror freshness should roll up into Nightly Ops Report and also appear as a gate input (“cannot promote while CVE sources are stale” if policy demands). (Stella Ops Suite)
Screen graph
flowchart LR M["Feed Mirrors (list)"] --> MD["Mirror Detail"] M --> A["AirGap Bundles"] M --> V["Version Locks"] M --> O["Ops Summary / Nightly Report"] MD --> H["Sync history"] MD --> E["Errors"] MD --> S["Storage usage"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Operations / Feeds & AirGap — Feed Mirrors [Refresh] [Create Mirror]|
| formerly: Operations → Feeds |
|--------------------------------------------------------------------------------------------------|
| KPIs: Mirrors=4 Synced=3 Stale=1 Errors=0 Storage=128GB |
| Filters: [All statuses] [All feed types] Search: _____________ |
|--------------------------------------------------------------------------------------------------|
| NAME TYPE STATUS LAST SYNC NEXT SYNC SIZE ACTIONS |
| osv-mirror-1 OSV ✅ synced 1h 1h 12GB View Logs Rotate Keys |
| nvd-mirror-1 NVD ⚠ stale 26h now 40GB View Logs Force Sync |
| ghsa-mirror GHSA ✅ synced 2h 2h 8GB View Logs |
| vendor-feed-x Custom ✅ synced 30m 30m 68GB View Logs |
|--------------------------------------------------------------------------------------------------|
| Note: Stale mirrors can block promotion if policy requires "fresh advisory inputs". |
+--------------------------------------------------------------------------------------------------+
3.2 Feed Mirror Detail
New location: Operations → Feeds & AirGap → Feed Mirrors → (Mirror Detail) Previously: inside the same page; not clearly separated Why changed:
- Operators need a forensic view: sync window, diffs, retries, errors, and storage growth.
- Also needs a crisp “impact” callout: which scanners/policies are consuming this feed. (Gitea: Git with a cup of tea)
Screen graph
flowchart TB D["Mirror Detail"] --> H["Sync History"] D --> E["Error Timeline"] D --> I["Input/Output stats (new CVEs/day)"] D --> S["Storage + retention"] D --> IMP["Impact (gates + scanners)"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Feeds & AirGap / Mirror: nvd-mirror-1 [Force Sync] [Disable] |
| formerly: Operations → Feeds → (NVD feed issues) |
|--------------------------------------------------------------------------------------------------|
| Status: ⚠ STALE (26h) Last success: Feb 17 06:10 Last attempt: Feb 18 07:30 (timeout) |
|--------------------------------------------------------------------------------------------------|
| Tabs: [Overview] [History] [Errors] [Storage] [Impact] |
|--------------------------------------------------------------------------------------------------|
| Overview |
| Source: NVD JSON 2.0 Mirror URL: https://stella.local/mirrors/nvd |
| Retention: 30 days Storage: 40GB Bandwidth cap: 10Mbps |
|--------------------------------------------------------------------------------------------------|
| Errors (last 24h) |
| 07:30 timeout contacting upstream |
| 06:30 503 upstream |
|--------------------------------------------------------------------------------------------------|
| Impact |
| - Nightly SBOM rescan depends on advisory freshness |
| - Policy Gate "Fresh Advised CVEs" may BLOCK promotion |
+--------------------------------------------------------------------------------------------------+
3.3 AirGap Bundles (Offline Kit builder / list)
New location: Operations → Feeds & AirGap → AirGap Bundles Previously: Operations → Feeds → AirGap Bundles Why changed:
- Air‑gap workflows are core (offline verification/export/import). Bundles must be first‑class alongside mirror health. (Stella Ops Suite)
- This screen ties directly into the Evidence export pipeline (what gets sealed, signed, and carried offline). (Stella Ops Suite)
Screen graph
flowchart LR A["AirGap Bundles (list)"] --> C["Create AirGap Bundle"] A --> D["AirGap Bundle Detail"] C --> SEL["Select: advisories + policy packs + signing keys + docs"] D --> V["Verify bundle signatures offline"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Feeds & AirGap / AirGap Bundles [Create Bundle] [Import] |
| formerly: Operations → Feeds → AirGap Bundles |
|--------------------------------------------------------------------------------------------------|
| Bundles let an offline site import: advisory mirrors + policy packs + signing roots + docs. |
|--------------------------------------------------------------------------------------------------|
| NAME CONTENTS CREATED STATUS ACTIONS |
| offline-kit-2026-02 OSV+NVD + PolicyPack v12 + keys Feb 18 08:00 ✅ ready Download Verify|
| offline-kit-qa OSV only + PolicyPack v12 Feb 10 09:00 ✅ ready Download Verify|
|--------------------------------------------------------------------------------------------------|
| Create flow (summary): Choose contents → build → sign → export → verify/import offline. |
+--------------------------------------------------------------------------------------------------+
3.4 Version Locks (for deterministic mirrors / policy packs)
New location: Operations → Feeds & AirGap → Version Locks Previously: tab on Operations → Feeds Why changed:
- Determinism requires explicit “what versions were used” (policy pack version, feed snapshot, tooling version). This supports replayable audit. (Stella Ops Suite)
Screen graph
flowchart TB V["Version Locks"] --> L1["Lock policy pack version"] V --> L2["Lock advisory snapshot"] V --> L3["Lock scanner runtime version"] V --> R["Replay uses locked inputs"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Feeds & AirGap / Version Locks [Create Lock] [Docs] |
| formerly: Operations → Feeds → Version Locks |
|--------------------------------------------------------------------------------------------------|
| Purpose: freeze exact inputs for deterministic replay & offline verification |
|--------------------------------------------------------------------------------------------------|
| TYPE CURRENT LOCK SCOPE CREATED ACTIONS |
| Policy Pack core-pack v12 org-wide Feb 01 Edit History |
| NVD Snapshot nvd@2026-02-17T06:10Z prod-gates Feb 17 Edit Diff |
| OSV Snapshot osv@2026-02-18T08:00Z all Feb 18 Edit |
| Scanner Runtime scanner@sha256:abcd... nightly-jobs Jan 29 Edit |
+--------------------------------------------------------------------------------------------------+
4) Administration (formerly Settings)
4.1 Identity & Access (Users/Roles/OAuth/API Tokens/Tenants)
New location: Administration → Identity & Access Previously: Settings → Identity & Access Why changed (mostly “reframed”, not “moved”):
- This remains admin-only, but it’s now explicitly separated from operational screens to keep the core UI “release/evidence first.”
- Also: approvals, signatures, and evidence tie back to who acted; IAM is part of the audit chain. (Stella Ops Suite)
Screen graph
flowchart LR I["Identity & Access"] --> U["Users"] I --> R["Roles"] I --> O["OAuth Clients"] I --> K["API Tokens"] I --> T["Tenants"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Administration / Identity & Access [Add User] [Add Token]|
| formerly: Settings → Identity & Access |
|--------------------------------------------------------------------------------------------------|
| Tabs: [Users] [Roles] [OAuth Clients] [API Tokens] [Tenants] |
|--------------------------------------------------------------------------------------------------|
| USERS |
| NAME EMAIL ROLE STATUS LAST SEEN ACTIONS |
| Alice Johnson alice@corp Approver Active 1d Edit Disable |
| David Wilson david@corp ReleaseEng Active 3h Edit Disable |
|--------------------------------------------------------------------------------------------------|
| Note: Approvals are signed/attributed to identities; tokens are audited. |
+--------------------------------------------------------------------------------------------------+
4.2 Policy Governance (Baselines / Rules / Simulation / Exception workflow)
New location: Administration → Policy Governance Previously: Settings → Policy Governance Why changed:
- Policy is a first‑class input to promotion gates (“why allowed/blocked”) and should be expressed as governable baselines, rules, simulation, and exception workflow. (Stella Ops Suite)
- Exception workflow needs tight coupling to “Security → Exceptions” and “Approvals” (who can override what, for how long). (Stella Ops Suite)
Screen graph
flowchart TB P["Policy Governance"] --> B["Policy Baselines"] P --> G["Governance Rules"] P --> S["Policy Simulation"] P --> E["Exception Workflow"] E --> X["Security → Exceptions (operational view)"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Administration / Policy Governance [Create Baseline] [Run] |
| formerly: Settings → Policy Governance |
|--------------------------------------------------------------------------------------------------|
| [Policy Baselines] [Governance Rules] [Policy Simulation] [Exception Workflow] |
|--------------------------------------------------------------------------------------------------|
| Baselines |
| - prod-baseline: requires (reachability<=HIGH, advisories fresh, approvals=2, signed evidence) |
| - staging-baseline: relaxed (approvals=1) |
|--------------------------------------------------------------------------------------------------|
| Quick actions |
| - Edit Rules (OPA/Rego / CEL / built-in) |
| - Run Simulation (what would block current pending approvals?) |
| - Configure Exception Workflow (who can grant overrides, expiry, evidence required) |
+--------------------------------------------------------------------------------------------------+
4.3 Trust & Signing (keys, issuers, certificates, transparency log, trust scoring)
New location: Administration → Trust & Signing Previously: Settings → Trust & Signing Why changed:
- “Prove it” requires signed/verifiable artifacts; trust roots and transparency logs are admin-managed but must be clearly modeled. (Stella Ops Suite)
- The audit log here is trust‑domain specific (keys/issuers changes) and supports evidence-grade posture. (Stella Ops Suite)
Screen graph
flowchart LR T["Trust & Signing"] --> K["Signing Keys"] T --> I["Issuers"] T --> C["Certificates"] T --> R["Transparency Log (Rekor)"] T --> S["Trust Scoring"] T --> A["Trust Audit Log"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Administration / Trust & Signing [Rotate Keys] [Audit] |
| formerly: Settings → Trust & Signing |
|--------------------------------------------------------------------------------------------------|
| Cards |
| [Signing Keys] [Issuers] [Certificates] [Transparency Log (Rekor)] |
| [Trust Scoring] [Trust Audit Log] |
|--------------------------------------------------------------------------------------------------|
| Key status (summary) |
| Cosign root: ✅ active Rekor: ✅ configured TLS: ✅ valid until 2026-11-01 |
|--------------------------------------------------------------------------------------------------|
| Note: key changes are audited; releases/evidence must validate under these trust roots. |
+--------------------------------------------------------------------------------------------------+
4.4 Usage & Limits (tenant usage + quota configuration)
New location: Administration → Usage & Limits Previously: Settings → Usage & Limits Why changed:
- Separate commercial/tenant quotas from operational throttles (Ops → Quotas & Throttles). This screen is “governance/config + usage meters”; Ops screen is “incident-level consumption + throttling.”
- Keeps “release/evidence first” for daily operators, while admins can tune capacity and limits.
Screen graph
flowchart LR U["Usage & Limits"] --> Q["Configure Quotas"] U --> OPS["Ops → Quotas & Throttles (runtime throttle events)"] U --> E["Evidence storage usage drilldown"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Administration / Usage & Limits [Configure Quotas] |
| formerly: Settings → Usage & Limits |
|--------------------------------------------------------------------------------------------------|
| Usage meters (this month) |
| Scans: 6,500/10,000 Storage: 42GB/100GB Evidence Packets: 2,800/10,000 API: 15k/100k |
|--------------------------------------------------------------------------------------------------|
| Quota Configuration |
| - Scan concurrency limit: 20 |
| - Evidence retention: 90 days |
| - API rate limits: 1000/min |
| Link: "View live throttles" → Ops → Quotas & Throttles |
+--------------------------------------------------------------------------------------------------+
4.5 System (Admin tools: health, doctor, SLO, background jobs)
New location: Administration → System (admin-only) Previously: Settings → System Why changed:
- “System” is still admin-only, but Background Jobs and “Health Check” must deep-link into Ops views (Scheduler/Orchestrator/Platform Health) so troubleshooting is one click.
- Keeps non-admin operators focused on release pipeline while preserving an admin cockpit.
- Deterministic replay and evidence workflows depend on stable system health (jobs running, feeds syncing, signing available). (Stella Ops Suite)
Screen graph
flowchart TB S["System (Admin)"] --> H["Health Check"] S --> D["Doctor (diagnostics)"] S --> L["SLO Monitoring"] S --> J["Background Jobs"] H --> PH["Ops → Platform Health"] J --> OR["Ops → Orchestrator"] J --> SCH["Ops → Scheduler Runs"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Administration / System (Admin only) [Run Doctor] [View SLO] |
| formerly: Settings → System |
|--------------------------------------------------------------------------------------------------|
| Cards |
| [Health Check] → (deep link) Ops → Platform Health |
| [Doctor] → diagnostics bundle (exportable) |
| [SLO Monitoring] |
| [Background Jobs] → (deep link) Ops → Orchestrator / Scheduler |
|--------------------------------------------------------------------------------------------------|
| Health (summary): ✅ All systems operational |
| Background jobs: Nightly SBOM rescan ✅ Advisory sync ⚠ NVD stale Evidence sealing ✅ |
+--------------------------------------------------------------------------------------------------+
5) Release Control Setup (moved out of Settings) — and NEW Release Bundles
5.1 Release Control → Setup (Admin)
New location: Release Control → Setup Previously: Settings → Release Control (“Release Control”) Why moved / changed:
- Release Control is the product core; configuration that defines environments/targets/agents/workflows belongs under the same umbrella so operators don’t context-switch into “Settings” for release-critical topology. (Stella Ops Suite)
- Environment topology must be region‑aware (your requirement) because “what is deployed where” must map cleanly across regions/tiers. (Gitea: Git with a cup of tea)
- Vault/Consul are explicitly part of the orchestrated release system; tying setup here makes bundle composition consistent. (Stella Ops Suite)
Screen graph
flowchart TD R["Release Control → Setup"] --> E["Environments (region-aware)"] R --> T["Targets"] R --> A["Agents"] R --> W["Workflows"] E --> RGN["Region model + env policies"] W --> G["Policy gates + approvals mapping"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Release Control / Setup (Admin) [Manage Envs] [Targets] [Workflows]|
| formerly: Settings → Release Control |
|--------------------------------------------------------------------------------------------------|
| Tiles |
| [Environments] region-aware topology, promotion paths |
| [Targets] docker/compose/ssh/winrm/ecs/nomad endpoints |
| [Agents] deployment agents + credentials |
| [Workflows] templates for promote → deploy → evidence |
|--------------------------------------------------------------------------------------------------|
| Quick status |
| Regions defined: 3 Environments: 12 Targets: 41 Agents: 6 Workflows: 5 |
+--------------------------------------------------------------------------------------------------+
5.2 Release Bundles — Bundle Catalog (NEW)
New location: Release Bundles → Bundle Catalog Previously: No direct equivalent (closest: “Releases” list was acting like a loose bundle list) Why it exists / why first-class:
- You want: “microservice digest becomes version X” + “env variables from Vault/Consul” + “multi-service bundle with changelog per repository.” That is exactly the digest-first invariant expressed as component→digest mapping packaged into a releaseable unit. (Gitea: Git with a cup of tea)
- It reduces chaos: “Release” becomes a promotion event, while “Bundle Version” is the artifact that gets promoted, audited, replayed. (Stella Ops Suite)
Screen graph
flowchart LR C["Bundle Catalog"] --> O["Bundle Organizer (create/edit)"] C --> D["Bundle Version Detail"] D --> A["Submit to Approvals"] D --> E["Export Evidence Capsule"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Release Bundles / Catalog [Create Bundle] [Import Bundle] |
| formerly: (none) — NEW |
|--------------------------------------------------------------------------------------------------|
| Filters: Repo: [All] Env: [All] Status: [Draft/Ready/Promoted] Search: _____________ |
|--------------------------------------------------------------------------------------------------|
| BUNDLE (Repo) LATEST VER COMPONENTS LAST CHANGE POLICY EVIDENCE ACTIONS |
| platform-release 1.3.0-rc1 14 2h ago ✅ pass ✅ sealed View Promote |
| payments-suite 2.8.4 6 1d ago ⚠ warn ☐ pending View Compose |
| hotfix-auth 1.2.4 1 30m ago ✅ pass ✅ sealed View Promote |
|--------------------------------------------------------------------------------------------------|
| Notes: |
| - Bundle Version contains: image digests + env overlays (Vault/Consul) + changelog + evidence |
+--------------------------------------------------------------------------------------------------+
5.3 Release Bundles — Bundle Organizer / Composer (NEW)
New location: Release Bundles → Bundle Organizer Previously: spread across “Releases”, “Integrations”, and external tooling Why changed:
- This is where you operationalize: “repo → set of services → digest pinning → versioning → env overlays → changelog.”
- It becomes the single deterministic place to build the “what” before the “promote.” (Gitea: Git with a cup of tea)
Screen graph
flowchart TB O["Bundle Organizer"] --> R["Select Repository / Bundle Name"] O --> S["Select services/images (tag → resolve → digest)"] O --> V["Versioning (derive version X)"] O --> ENV["Env overlays (Vault + Consul)"] O --> CL["Changelog (commits/PRs/tickets)"] O --> VAL["Validate: SBOM + reachability + policy gates"] VAL --> SAVE["Save Draft / Publish Bundle Version"] SAVE --> AP["Submit for Approval"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Release Bundles / Organizer (Composer) [Save Draft] [Publish] [Submit] |
| formerly: (none) — NEW |
|--------------------------------------------------------------------------------------------------|
| Bundle identity |
| Repo: platform-release (GitHub) Bundle: Platform Release Version: 1.3.0-rc1 (auto) |
|--------------------------------------------------------------------------------------------------|
| Step 1 — Components (digest-first) |
| Service Input Tag Resolved Digest SBOM Reachable CVEs |
| api-gateway api:1.3.0-rc1 sha256:aaaa... ✅ 0 crit reachable |
| web-frontend web:2.0.0 sha256:bbbb... ✅ 1 high reachable |
| worker worker:3.1.0 sha256:cccc... ☐ pending scan |
| [+ Add service] [Resolve all tags → digests] |
|--------------------------------------------------------------------------------------------------|
| Step 2 — Env overlays (region/env aware) |
| Target: prod / us-east-1 |
| Vault paths: kv/prod/platform/* Consul keys: platform/prod/* |
| Overlay diff (computed): +RATE_LIMIT=1000 -FEATURE_FLAG_X |
|--------------------------------------------------------------------------------------------------|
| Step 3 — Changelog (per repo) |
| PRs: 12 Commits: 48 Tickets: JIRA-102, JIRA-119 Pipeline: jenkins#7712 |
|--------------------------------------------------------------------------------------------------|
| Validate |
| Policy gates: ✅ pass (except: "web-frontend reachable high") → requires approval |
| Evidence: will seal on publish |
+--------------------------------------------------------------------------------------------------+
5.4 Bundle Version Detail (NEW)
New location: Release Bundles → Bundle Version Detail Previously: partially in “Release detail” + “Evidence” Why changed:
- Bundle Version Detail is the canonical “what is this artifact” page: digests, overlays, reachable CVEs, policy decision trace, approvals, and evidence export. This aligns with “Decision Capsule / replayable evidence.” (Stella Ops Suite)
Screen graph
flowchart LR D["Bundle Version Detail"] --> P["Policy Decision Trace"] D --> SB["SBOM + Findings Summary"] D --> HR["Hybrid Reachability Evidence"] D --> AP["Approvals"] D --> EV["Evidence Capsule / Export"] D --> PR["Promote / Deploy"]
ASCII mock
+--------------------------------------------------------------------------------------------------+
| Bundle: Platform Release Version: 1.3.0-rc1 Status: READY [Promote] [Export] |
| formerly: (none) — NEW |
|--------------------------------------------------------------------------------------------------|
| Composition (digests) |
| api-gateway → sha256:aaaa… web-frontend → sha256:bbbb… worker → sha256:cccc… |
|--------------------------------------------------------------------------------------------------|
| Security summary |
| Reachable: CRIT 0 | HIGH 1 | MED 0 | LOW 3 Hybrid sources: build + image + runtime |
| Environments impacted: prod/us-east-1, prod/eu-west-1 |
|--------------------------------------------------------------------------------------------------|
| Policy decision trace |
| Gate: "No reachable critical" ✅ Gate: "Reachable high requires 2 approvals" ⚠ pending |
|--------------------------------------------------------------------------------------------------|
| Evidence |
| Capsule: sealed ✅ signatures ✅ replayable ✅ export formats: tar.gz / zip / oci |
+--------------------------------------------------------------------------------------------------+
What I did with “Security Data” (old Settings item)
In the redesign, the old Settings → Security Data is absorbed into:
- Integrations → Advisory Sources (connectivity/config of OSV/NVD/etc)
- Operations → Feeds & AirGap (mirroring, freshness, offline kits, version locks)
Reason: advisory inputs are both an integration and an operational SRE concern, and they directly affect promotion gates. (Stella Ops Suite)
