doctor enhancements, setup, enhancements, ui functionality and design consolidation and , test projects fixes , product advisory attestation/rekor and delta verfications enhancements
This commit is contained in:
master
535
docs-archived/ui-analysis/rework/01-ui-rework-adivsory.md
Normal file
535
docs-archived/ui-analysis/rework/01-ui-rework-adivsory.md
Normal file
@@ -0,0 +1,535 @@
|
||||
Below is a UI/UX advisory based on your **new product vision** (evidence-based release control plane with hybrid reachability) and the ASCII blueprints of the **current UI information architecture**.
|
||||
|
||||
I’m going to be blunt: you already have many of the right primitives (evidence bundles, proof chain, policy simulation, orchestration, reachability center), but the **IA and “default story”** still tells users “scanner + admin console.” The fix is not cosmetic—this is a **release-first product re‑framing** in navigation, objects, and workflows.
|
||||
|
||||
---
|
||||
|
||||
## 1) What the UI must communicate in 10 seconds
|
||||
|
||||
When a buyer opens Stella Ops, they must immediately understand:
|
||||
|
||||
1. **“What is deployed where”** (by digest, per environment/target)
|
||||
2. **“What is allowed to ship next”** (promotion requests + approvals)
|
||||
3. **“Why it is allowed/blocked”** (policy gates + reachability evidence)
|
||||
4. **“Where the evidence is”** (one-click proof chain and export)
|
||||
|
||||
Everything else (vuln explorer, SBOM graph, VEX hub, feeds, ops health) is supporting detail.
|
||||
|
||||
Right now the UI communicates: “Security dashboard → findings → triage → policy → ops/admin.”
|
||||
That’s the wrong default narrative for a release control plane.
|
||||
|
||||
---
|
||||
|
||||
## 2) New UX mental model: 5 core objects, 3 core jobs
|
||||
|
||||
### Core objects (they must exist everywhere as first-class nouns)
|
||||
|
||||
* **Release**: bundle of component→digest mappings (immutable identity)
|
||||
* **Environment**: Dev/QA/Staging/Prod (policies, windows, approvals)
|
||||
* **Promotion**: request to move a Release to an Environment
|
||||
* **Deployment**: execution instance (workflow run against targets)
|
||||
* **Evidence Packet**: signed bundle of inputs/outputs of a decision/run
|
||||
|
||||
### Core jobs (the UI must optimize for these first)
|
||||
|
||||
1. **Ship a release**: create → request promotion → approve → deploy
|
||||
2. **Explain/justify a decision**: why allowed/blocked + evidence
|
||||
3. **Operate with confidence**: drift, CVE updates, replay, audit export
|
||||
|
||||
Your current UI has these elements, but they’re **fragmented across Analyze/Triage/Policy/Evidence/Ops**.
|
||||
|
||||
---
|
||||
|
||||
## 3) High-level IA change: make “Releases” the product, not a submenu
|
||||
|
||||
### Current top-level nav (scanner-centric)
|
||||
|
||||
HOME / ANALYZE / TRIAGE / POLICY / OPS / NOTIFY / ADMIN
|
||||
|
||||
### Recommended top-level nav (release control plane)
|
||||
|
||||
Use fewer, higher-signal nouns. Example:
|
||||
|
||||
1. **Control Plane** (default landing)
|
||||
2. **Releases**
|
||||
3. **Approvals**
|
||||
4. **Security**
|
||||
5. **Evidence**
|
||||
6. **Operations**
|
||||
7. **Settings** (consolidated configuration)
|
||||
|
||||
If you insist on 5 groups max, merge:
|
||||
|
||||
* **Control Plane + Releases** (same section)
|
||||
* **Operations** remains admin-only
|
||||
* **Settings** stays separate
|
||||
|
||||
### What changes immediately
|
||||
|
||||
* **Home `/` becomes “Control Plane Overview”** (release pipeline + action inbox)
|
||||
* **Release Orchestrator becomes the central product area** (not hidden)
|
||||
* **Analyze/Triage collapse into “Security”** (because they exist to inform release gating)
|
||||
* **Evidence becomes a single unified section** (today it’s scattered across triage, evidence-export, proof-chain, release evidence)
|
||||
|
||||
---
|
||||
|
||||
## 4) Shell & navigation redesign: move from top mega-menu to left rail
|
||||
|
||||
Your current header menu already has too many cognitive branches. A release control plane benefits from a **left navigation rail** + a **top bar for global context**.
|
||||
|
||||
### Proposed shell blueprint
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Stella Ops [Global Search: release/digest/CVE/env] [Tenant ▼] [User] │
|
||||
│ Offline: OK | Feeds: 2026-01-15 | Policy: prod-baseline v3 | Evidence: ON │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ CONTROL PLANE │ Control Plane Overview │
|
||||
│ Releases │ ┌────────────────────────────────────────────────────────┐ │
|
||||
│ Approvals │ │ Environment Pipeline: Dev → QA → Staging → Prod │ │
|
||||
│ Security │ │ Dev: v1.3.0 QA: v1.2.5 Stg: v1.2.4 Prod: v1.2.3 │ │
|
||||
│ Evidence │ └────────────────────────────────────────────────────────┘ │
|
||||
│ Operations │ ┌───────────────────────────┐ ┌──────────────────────────┐ │
|
||||
│ Settings │ │ Action Inbox │ │ Drift & Risk Changes │ │
|
||||
│ │ │ - 3 approvals pending │ │ - 2 prod drifts detected │ │
|
||||
│ │ │ - 1 blocked promotion │ │ - 5 CVEs updated │ │
|
||||
│ │ │ - 2 failed deployments │ │ - 1 key expiring │ │
|
||||
│ │ └───────────────────────────┘ └──────────────────────────┘ │
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Top bar is for:**
|
||||
|
||||
* Global search
|
||||
* Tenant context
|
||||
* Offline / feed snapshot / policy baseline status (your differentiators)
|
||||
* Evidence mode (exportability / signing availability)
|
||||
* User actions
|
||||
|
||||
**Left nav is for the product story.**
|
||||
|
||||
---
|
||||
|
||||
## 5) Consolidate configuration into a single “Settings” area
|
||||
|
||||
You already identified this, and you’re correct. Right now configuration is scattered:
|
||||
|
||||
* `/setup`, `/console/configuration`, `/integrations`, `/admin/*`, `/ops/*`, `/concelier/*`
|
||||
|
||||
This creates a “Where do I configure X?” problem and makes the product feel unfinished.
|
||||
|
||||
### Proposed Settings structure (single hub, left-side tabs)
|
||||
|
||||
**Settings**
|
||||
|
||||
* **Integrations**
|
||||
|
||||
* Registries
|
||||
* SCM
|
||||
* CI/CD
|
||||
* Targets & Hosts
|
||||
* Secrets
|
||||
* Notifications
|
||||
* **Release Control**
|
||||
|
||||
* Environments (policies, approval rules, freeze windows)
|
||||
* Targets (Docker/Compose/ECS/Nomad)
|
||||
* Agents (health, capabilities)
|
||||
* Workflows (templates, step registry)
|
||||
* **Trust & Signing**
|
||||
|
||||
* Keys (rotation)
|
||||
* Issuers
|
||||
* Certificates
|
||||
* Rekor / transparency settings
|
||||
* **Security Data**
|
||||
|
||||
* Advisory sources / connectors
|
||||
* Feed mirror / airgap
|
||||
* Version locks
|
||||
* **Identity & Access**
|
||||
|
||||
* Users
|
||||
* Roles & scopes
|
||||
* OAuth clients
|
||||
* API keys
|
||||
* **Tenant / Branding**
|
||||
* **Usage & Limits** (quotas, throttle)
|
||||
* **System**
|
||||
|
||||
* Platform health
|
||||
* Doctor diagnostics
|
||||
* SLOs
|
||||
* Jobs / queues (admin-only)
|
||||
|
||||
### What to *move* under Settings (specific existing routes)
|
||||
|
||||
* `/console/configuration` → Settings → Integrations
|
||||
* `/integrations/*` → Settings → Integrations (same UI, one place)
|
||||
* `/admin/trust/*` → Settings → Trust & Signing
|
||||
* `/admin/registries` → Settings → Integrations → Registries (merge)
|
||||
* `/admin/notifications` → Settings → Integrations → Notifications (or Settings → Notifications)
|
||||
* `/ops/feeds`, `/ops/offline-kit` → Settings → Security Data (unless you want “Operations”)
|
||||
* `/ops/quotas` → Settings → Usage & Limits
|
||||
* `/console/admin/*` → Settings → Identity & Access (admin-only)
|
||||
|
||||
This one consolidation will make the product feel 2x more mature.
|
||||
|
||||
---
|
||||
|
||||
## 6) Rebuild “Home” into a Release Control Plane dashboard (not a security dashboard)
|
||||
|
||||
Your current Home dashboard is well designed—but it optimizes the wrong story (vulns, risk, reachability pie charts).
|
||||
|
||||
### Replace `/` with: “Control Plane Overview”
|
||||
|
||||
Must show:
|
||||
|
||||
* Environment pipeline status (what’s deployed)
|
||||
* Pending promotions & approvals
|
||||
* Deployment outcomes (last N)
|
||||
* Drift / risk changes since last evidence
|
||||
* “System trust posture” (feeds stale? keys expiring? offline?)
|
||||
|
||||
Security metrics should be **secondary** and contextual.
|
||||
|
||||
### Keep the current security dashboard, but move it under Security
|
||||
|
||||
* The existing `/` dashboard becomes `/security/overview` (or `/security/dashboard`)
|
||||
|
||||
---
|
||||
|
||||
## 7) Make “Approvals” a first-class product surface, not a subpage
|
||||
|
||||
Approvals are the moment where buyers “feel” governance and auditability.
|
||||
|
||||
### Current approvals blueprint is good; what’s missing is evidence-first structure
|
||||
|
||||
**Approval card must answer:**
|
||||
|
||||
1. What is changing?
|
||||
2. What is the risk delta?
|
||||
3. What do the gates say?
|
||||
4. Where is the evidence?
|
||||
5. What do I do next?
|
||||
|
||||
### Suggested approval card layout
|
||||
|
||||
```
|
||||
Release: app-svc v1.2.5 (Digest bundle locked)
|
||||
From: QA → To: Staging Requested by: deploy-bot 2h ago
|
||||
|
||||
WHAT CHANGED (Diff summary)
|
||||
- Components changed: 3
|
||||
- New CVEs introduced: 2 (1 reachable)
|
||||
- Fixed CVEs: 5
|
||||
- Config drift: none
|
||||
|
||||
GATES (Policy baseline: stg-baseline v3.1)
|
||||
✅ SBOM valid + signed
|
||||
✅ Provenance present (SLSA attestation)
|
||||
⚠️ 3 high CVEs (2 not-affected via VEX, 1 uncertain reachability)
|
||||
❌ 1 reachable critical path found (confidence 0.82)
|
||||
|
||||
ACTIONS:
|
||||
[View Evidence Packet] [View Reachability Witness] [Request Exception] [Approve] [Reject]
|
||||
```
|
||||
|
||||
Key UX improvements:
|
||||
|
||||
* **Diff-first** becomes a core affordance everywhere (you already have lineage diff patterns—reuse them).
|
||||
* “View Reachability Witness” must exist right on the approval decision (this is your moat).
|
||||
|
||||
---
|
||||
|
||||
## 8) Unify “Releases” around digest-first identity and environment mapping
|
||||
|
||||
Today you have:
|
||||
|
||||
* Artifact Workspace (triage)
|
||||
* Release Orchestrator (separate)
|
||||
* Findings and scans (analyze)
|
||||
|
||||
To match the vision, “Release” becomes the thing users manage, and “Artifacts” become a supporting detail.
|
||||
|
||||
### New Releases area should have 4 core pages
|
||||
|
||||
1. **Releases List**
|
||||
2. **Release Detail**
|
||||
3. **Environment Detail**
|
||||
4. **Deployment Runs**
|
||||
|
||||
#### Release detail page should be your flagship screen
|
||||
|
||||
Must include:
|
||||
|
||||
* Release identity (bundle, digests)
|
||||
* Promotion history and current deployment per environment
|
||||
* Gate results (policy + reachability + VEX)
|
||||
* Evidence packet + proof chain (one-click)
|
||||
* “Create promotion request” and “Rollback” actions
|
||||
|
||||
**Release detail blueprint (suggested)**
|
||||
|
||||
```
|
||||
RELEASE: v1.2.5 Bundle: sha256:bundle... Created by CI: gh-actions #882
|
||||
|
||||
[Overview] [Components] [Gates] [Promotions] [Deployments] [Evidence] [Proof Chain]
|
||||
|
||||
OVERVIEW
|
||||
- Dev: deployed ✓ QA: deployed ✓ Staging: pending approval ⚠ Prod: v1.2.3
|
||||
- Risk score: 62 (↓ -8 from previous) Reachability coverage: 89%
|
||||
|
||||
PRIMARY ACTIONS: [Request Promotion] [Generate Evidence] [Export] [Replay Verify]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9) Embed reachability everywhere it matters (and nowhere it doesn’t)
|
||||
|
||||
Reachability is not a separate “center” for most users. It’s an explanation layer that must appear:
|
||||
|
||||
* On approvals (decision moment)
|
||||
* On finding detail (why this CVE matters)
|
||||
* On release gates (why blocked/allowed)
|
||||
* In evidence packet (what was proven)
|
||||
|
||||
### Reachability presentation rules (UX contract)
|
||||
|
||||
* Always show a **three-tier summary**:
|
||||
|
||||
* **State**: Reachable / Unreachable / Uncertain
|
||||
* **Confidence**: numeric and explained (“0.82; runtime signal present”)
|
||||
* **Evidence**: witness path / guards / dynamic edges
|
||||
|
||||
* Only show full graphs on demand (progressive disclosure).
|
||||
|
||||
* “Uncertain” must be actionable: show why uncertain, and the top 1–2 ways to resolve uncertainty (runtime signal, config, guard).
|
||||
|
||||
### Add a “Witness Viewer” component (reusable)
|
||||
|
||||
A dedicated view that can render:
|
||||
|
||||
* Mermaid/DOT export
|
||||
* Call path
|
||||
* Guards/dynamic loading notes
|
||||
* Evidence URIs
|
||||
* Replay/verify button
|
||||
|
||||
This becomes a shared panel used in:
|
||||
|
||||
* Approvals
|
||||
* Finding detail slide-out
|
||||
* Evidence packet viewer
|
||||
|
||||
---
|
||||
|
||||
## 10) Evidence: stop scattering it; make one “Evidence” experience
|
||||
|
||||
You currently have evidence in:
|
||||
|
||||
* `/evidence/*`
|
||||
* `/proofs/:subjectDigest`
|
||||
* `/triage/audit-bundles`
|
||||
* `/release-orchestrator/evidence`
|
||||
|
||||
This is a classic maturity killer: users lose trust when “audit artifacts” are spread across 4 locations.
|
||||
|
||||
### Recommended change
|
||||
|
||||
Create **one Evidence section** with:
|
||||
|
||||
* Evidence Packets (searchable, filterable by release/env/deployment)
|
||||
* Proof Chains
|
||||
* Replay/Verify
|
||||
* Export Center
|
||||
* Audit Bundles (as a type of evidence packet)
|
||||
|
||||
Then:
|
||||
|
||||
* Remove / hide “Evidence” tabs inside other areas, replacing them with a link:
|
||||
|
||||
* “Open Evidence Packet” → takes you to Evidence section pre-filtered.
|
||||
|
||||
---
|
||||
|
||||
## 11) Rename/merge “Analyze” + “Triage” into a single “Security” area
|
||||
|
||||
Right now:
|
||||
|
||||
* Analyze = findings/vulns/graph/lineage/reachability/vex/unknowns/patch-map
|
||||
* Triage = artifacts/exceptions/audit bundles/risk profiles
|
||||
|
||||
To a customer this reads like: “two versions of security.”
|
||||
|
||||
### Recommended Security structure
|
||||
|
||||
**Security**
|
||||
|
||||
* Overview (the old home security dashboard)
|
||||
* Findings (scans & findings)
|
||||
* Vulnerabilities (global library CVEs)
|
||||
* Artifact Intelligence (SBOM graph, lineage diff, unknowns, patch map)
|
||||
* VEX (hub + consensus + conflicts)
|
||||
* Exceptions (policy exceptions and risk acceptances)
|
||||
* Risk (profiles / scoring explanations)
|
||||
|
||||
And crucially:
|
||||
|
||||
* Each of these pages must link back to **Releases/Environments impacted**.
|
||||
|
||||
Example:
|
||||
|
||||
* Vulnerability detail shows: “Impacts: 3 releases; deployed in Prod: yes/no.”
|
||||
|
||||
That’s how security becomes a gate, not a silo.
|
||||
|
||||
---
|
||||
|
||||
## 12) Fix route and naming inconsistencies (small work, big polish)
|
||||
|
||||
Your own observations list the fragmentation. Customers feel this as “unfinished.”
|
||||
|
||||
### Normalize path prefixes
|
||||
|
||||
* `/release-orchestrator/*` → `/releases/*` (or `/control-plane/*`)
|
||||
* `/admin/vex-hub/*` → `/security/vex/*`
|
||||
* `/scheduler/*` → `/ops/scheduler/*` (or `/operations/scheduler/*`)
|
||||
* `/console/admin/*` → `/settings/access/*` (admin-only)
|
||||
* `/concelier/trivy-db-settings` → `/settings/security-data/trivy`
|
||||
|
||||
### Normalize nouns in the UI
|
||||
|
||||
* “Artifact Workspace” is security-centric; for release product it becomes:
|
||||
|
||||
* “Artifacts” (inventory) or “Digests”
|
||||
* “Scans & Findings” should be “Findings”
|
||||
* “Policy Studio” is fine for power users, but add a simple “Policies” list entry for everyone.
|
||||
|
||||
---
|
||||
|
||||
## 13) Add an “Action Inbox” to unify the product experience
|
||||
|
||||
Today approvals are one page, exceptions are another, dead-letter jobs are in ops, drift alerts are separate docs.
|
||||
|
||||
Create a single page: **Inbox**
|
||||
|
||||
* Pending approvals
|
||||
* Pending exception reviews
|
||||
* Drift alerts (reachability drift, risk drift)
|
||||
* Failed deployments
|
||||
* Key expirations / feed staleness (if they block evidence)
|
||||
|
||||
This becomes the daily entry point for an operator.
|
||||
|
||||
---
|
||||
|
||||
## 14) Styling and readability guidance (practical, not decorative)
|
||||
|
||||
A release control plane UI must be “audit calm,” not “security noisy.”
|
||||
|
||||
**Rules:**
|
||||
|
||||
* Prefer **text + badge** over emoji status indicators in production UI.
|
||||
* Use **progressive disclosure**: summary → details panel → deep technical view.
|
||||
* Replace “dashboard card overload” with 2–3 high-signal panels:
|
||||
|
||||
* Pipeline
|
||||
* Inbox
|
||||
* Drift/Risk Changes
|
||||
* Make **digest visibility consistent**:
|
||||
|
||||
* show short digest everywhere; full digest on hover/copy
|
||||
* Provide “Copy” buttons for operational fields (digest, env, release id, evidence id).
|
||||
* Use consistent phrasing for gates:
|
||||
|
||||
* PASS / WARN / BLOCK
|
||||
* always with one-line reason
|
||||
* Show **policy baseline version** and **feed snapshot version** where decisions are made. That’s trust.
|
||||
|
||||
---
|
||||
|
||||
## 15) Concrete agent task list (what to change, where)
|
||||
|
||||
### A) Navigation & IA refactor
|
||||
|
||||
1. **Add new top-level nav items**:
|
||||
|
||||
* Control Plane, Releases, Approvals, Security, Evidence, Operations, Settings
|
||||
2. **Move Release Orchestrator into nav** and make it default landing route.
|
||||
3. **Remove Analyze/Triage split** from top-level; merge into Security.
|
||||
4. **Move VEX Hub out of /admin** and into Security section (keep permissions).
|
||||
5. **Add Settings section** and start migrating config pages under it.
|
||||
|
||||
### B) Home `/` replacement
|
||||
|
||||
1. Replace `HomeDashboardComponent` content:
|
||||
|
||||
* Pipeline view, inbox, drift/risk deltas, system trust posture.
|
||||
2. Move existing “Security Dashboard” content to `/security/overview`.
|
||||
|
||||
### C) Release experience upgrades
|
||||
|
||||
1. Implement **Release Detail flagship page**:
|
||||
|
||||
* Tabs: Overview, Components, Gates, Promotions, Deployments, Evidence, Proof Chain
|
||||
2. Implement **Diff-first** view for promotions (reuse lineage diff patterns).
|
||||
|
||||
### D) Approvals redesign
|
||||
|
||||
1. Make Approvals a first-class nav item.
|
||||
2. Add “View Evidence Packet” + “View Reachability Witness” as primary actions.
|
||||
3. Add “Request Exception” flow from the approval screen (no hunting).
|
||||
|
||||
### E) Evidence unification
|
||||
|
||||
1. Create a single Evidence hub:
|
||||
|
||||
* Bundles, Proof Chains, Replay/Verify, Export
|
||||
2. Redirect:
|
||||
|
||||
* `/proofs/:subjectDigest` into Evidence area
|
||||
* `/release-orchestrator/evidence` becomes a filtered Evidence view
|
||||
* `/triage/audit-bundles` becomes Evidence → Audit Bundles
|
||||
|
||||
### F) Settings consolidation
|
||||
|
||||
1. Create Settings shell page + left sidebar.
|
||||
2. Migrate:
|
||||
|
||||
* Integrations (merge configuration pane + integration hub)
|
||||
* Trust, registries, notifications, feeds/offline kit, quotas
|
||||
3. Deprecate redundant entry points after migration.
|
||||
|
||||
### G) Cross-linking (critical)
|
||||
|
||||
Add “Impacts” panels everywhere:
|
||||
|
||||
* On CVE detail: affected releases/environments + deployed status
|
||||
* On Finding detail: show release gate impact + direct link to approval/promotion
|
||||
* On Release gate: show underlying findings list filtered to that release
|
||||
|
||||
### H) Reachability witness viewer component
|
||||
|
||||
1. Build a reusable panel:
|
||||
|
||||
* State, confidence, witness path, guards/dynamic loading flags, replay verify
|
||||
2. Embed it in:
|
||||
|
||||
* Approvals
|
||||
* Finding detail
|
||||
* Evidence packet viewer
|
||||
|
||||
---
|
||||
|
||||
## 16) What I would prioritize (highest ROI, least debate)
|
||||
|
||||
If you do only three things first, do these:
|
||||
|
||||
1. **Make `/` the Control Plane Overview** (pipeline + inbox + drift)
|
||||
2. **Consolidate Settings** (stop configuration fragmentation)
|
||||
3. **Make Approvals evidence-first with reachability witness** (moat on display)
|
||||
|
||||
Everything else becomes easier after those.
|
||||
|
||||
---
|
||||
Reference in New Issue
Block a user