46 KiB
46 KiB
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, (c) 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)