preparation for ui re-shelling
This commit is contained in:
master
910
docs/modules/ui/v2-rewire/pack-02.md
Normal file
910
docs/modules/ui/v2-rewire/pack-02.md
Normal file
@@ -0,0 +1,910 @@
|
||||
## Pack 2 — Integrations + Admin/Settings + Feeds + **Release Bundle Organizer** (new)
|
||||
|
||||
Below you get:
|
||||
|
||||
1. **Mermaid menu graphs** (global + per area)
|
||||
2. 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)
|
||||
|
||||
```mermaid
|
||||
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])
|
||||
|
||||
---
|
||||
|
||||
### 1.2 Integrations menu graph
|
||||
|
||||
```mermaid
|
||||
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)
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```mermaid
|
||||
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])
|
||||
|
||||
---
|
||||
|
||||
# 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][1])
|
||||
* 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][2])
|
||||
* Feed/connectivity failures must surface upstream into **Nightly Ops Report** and **promotion gating** (blocked because “NVD not synced”, “Vault unreachable”, etc.). ([Stella Ops Suite][1])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][2])
|
||||
* 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][3])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][4])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][1])
|
||||
* 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][5])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][3])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][1])
|
||||
* This screen ties directly into the **Evidence export pipeline** (what gets sealed, signed, and carried offline). ([Stella Ops Suite][4])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][4])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][4])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
I["Identity & Access"] --> U["Users"]
|
||||
I --> R["Roles"]
|
||||
I --> O["OAuth Clients"]
|
||||
I --> K["API Tokens"]
|
||||
I --> T["Tenants"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][5])
|
||||
* Exception workflow needs tight coupling to “Security → Exceptions” and “Approvals” (who can override what, for how long). ([Stella Ops Suite][5])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][4])
|
||||
* The audit log here is trust‑domain specific (keys/issuers changes) and supports evidence-grade posture. ([Stella Ops Suite][6])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U["Usage & Limits"] --> Q["Configure Quotas"]
|
||||
U --> OPS["Ops → Quotas & Throttles (runtime throttle events)"]
|
||||
U --> E["Evidence storage usage drilldown"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][4])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][1])
|
||||
* 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][3])
|
||||
* Vault/Consul are explicitly part of the orchestrated release system; tying setup here makes bundle composition consistent. ([Stella Ops Suite][6])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][2])
|
||||
* It reduces chaos: “Release” becomes a *promotion event*, while “Bundle Version” is the *artifact* that gets promoted, audited, replayed. ([Stella Ops Suite][5])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][2])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][4])
|
||||
|
||||
### Screen graph
|
||||
|
||||
```mermaid
|
||||
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
|
||||
|
||||
```text
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| 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][1])
|
||||
|
||||
---
|
||||
|
||||
[1]: https://stella-ops.org/?utm_source=chatgpt.com "Stella Ops Suite - Evidence-Grade Release Control for Non ..."
|
||||
[2]: https://git.stella-ops.org/stella-ops.org/git.stella-ops.org/commit/d509c44411709db41f2fd497ac7f5ec8b8e96c63?files=docs%2Fproduct&utm_source=chatgpt.com "release orchestrator pivot, architecture and ... - Stella Ops Suite"
|
||||
[3]: https://git.stella-ops.org/stella-ops.org/git.stella-ops.org/src/commit/490339561842d30f212e390efb9e8409cd395fe3/docs-archived/ui-analysis/rework/01-ui-rework-adivsory.md?utm_source=chatgpt.com "git.stella-ops.org/01-ui-rework-adivsory.md at ... - Stella Ops Suite"
|
||||
[4]: https://stella-ops.org/why/?utm_source=chatgpt.com "Stella Ops Suite — Evidence-Grade Release Orchestration Control ..."
|
||||
[5]: https://stella-ops.org/faq/?utm_source=chatgpt.com "Frequently Asked Questions - Stella Ops Suite"
|
||||
[6]: https://stella-ops.org/about/?utm_source=chatgpt.com "About Stella Ops Suite — Evidence-Grade Release ..."
|
||||
Reference in New Issue
Block a user