preparation for ui re-shelling
This commit is contained in:
master
@@ -0,0 +1,153 @@
|
||||
# Sprint 20260218_005 - UI V2 Rewire Spec Freeze
|
||||
|
||||
## Topic & Scope
|
||||
- Freeze all unresolved IA decisions before implementation sprints begin so downstream work cannot diverge.
|
||||
- Produce complete, self-contained specs for Advisory Sources, Release Control capability rendering, trust ownership transition, and route deprecation.
|
||||
- Bootstrap a root-domain endpoint contract ledger that classifies all screens as `EXISTS_COMPAT`, `EXISTS_ADAPT`, or `MISSING_NEW`.
|
||||
- Working directory: `docs/modules/ui/v2-rewire`.
|
||||
- Expected evidence: finalized specification docs, route mapping matrix, contract ledger v1, and signed handoff packet.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: none.
|
||||
- Downstream dependencies: this sprint must be DONE before sprints `20260218_006`, `20260218_007`, and `20260218_008` can move to DOING.
|
||||
- Safe parallelism:
|
||||
- `R0-01` and `R0-02` can run in parallel.
|
||||
- `R0-03` can run in parallel with `R0-01` and `R0-02`.
|
||||
- `R0-04` depends on `R0-01`, `R0-02`, and `R0-03`.
|
||||
- `R0-05` depends on `R0-03` and `R0-04`.
|
||||
- `R0-06` depends on `R0-01` through `R0-05`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/sprint-planning-guide.md`
|
||||
- `docs/modules/ui/v2-rewire/multi-sprint-plan.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-19.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-20.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-21.md`
|
||||
- `src/Web/StellaOps.Web/src/app/app.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/layout/app-sidebar/app-sidebar.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/legacy-redirects.routes.ts`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### R0-01 - Freeze canonical IA taxonomy and ownership model
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, Documentation author
|
||||
Task description:
|
||||
- Finalize the top-level IA taxonomy as the only allowed root-domain structure for implementation work. The taxonomy must explicitly define the seven roots: Dashboard, Release Control, Security and Risk, Evidence and Audit, Integrations, Platform Ops, and Administration.
|
||||
- Freeze ownership boundaries that resolve known conflicts from earlier packs. The self-contained spec must explicitly define: Policy Governance owner, Trust and Signing owner, System owner, and the split of legacy Security Data between Integrations, Platform Ops, and Security and Risk.
|
||||
- Define forbidden alternatives so downstream sprints cannot re-open superseded placements.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Canonical root-domain taxonomy is documented with final naming and order.
|
||||
- [ ] Ownership boundaries for Policy, Trust, System, and Security Data split are explicit and conflict-free.
|
||||
- [ ] Superseded alternatives are listed as non-allowed implementations.
|
||||
- [ ] Decision record includes rationale and impacted downstream sprints.
|
||||
|
||||
### R0-02 - Produce full Advisory Sources screen specification
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, Security lead, Documentation author
|
||||
Task description:
|
||||
- Create a complete screen spec for `Security and Risk -> Advisory Sources` with no reliance on pack text at implementation time. The spec must include exact screen sections, filters, columns, actions, detail drawer/page behavior, empty states, stale data states, and hard-fail states.
|
||||
- The spec must define field-level ownership and the link contract between Advisory Sources and the two adjacent surfaces: `Integrations` (connectivity and source config) and `Platform Ops` (mirror and freshness operations).
|
||||
- Include explicit behavior for conflicting advisory signals, unsigned advisories, and stale source freshness relative to policy gate decisions.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Screen layout and interaction model are fully specified.
|
||||
- [ ] Field-level ownership matrix is present for Security and Risk vs Integrations vs Platform Ops.
|
||||
- [ ] Data-state behavior is defined for healthy, stale, unavailable, and conflict conditions.
|
||||
- [ ] API dependency list for this screen is present with initial status class per dependency.
|
||||
|
||||
### R0-03 - Freeze Release Control capability rendering policy
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Project Manager, UX lead, Frontend lead
|
||||
Task description:
|
||||
- Freeze one nav rendering policy for Release Control-owned capabilities. The policy must explicitly answer whether Releases and Approvals appear as direct shortcuts, nested-only entries, or hybrid shortcuts with strict ownership labeling.
|
||||
- The policy must include desktop and mobile nav behavior, breadcrumbs, route naming, and legacy-label transition text. It must explicitly prevent mixed implementations across teams.
|
||||
- Include route alias requirements needed to support staged migration from current navigation.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] One rendering policy is selected and documented for desktop and mobile.
|
||||
- [ ] Breadcrumb and route naming rules are specified with concrete examples.
|
||||
- [ ] Legacy label behavior is specified for migration period.
|
||||
- [ ] Explicit do and do-not list prevents mixed rendering variants.
|
||||
|
||||
### R0-04 - Freeze Trust and Signing ownership transition policy
|
||||
Status: TODO
|
||||
Dependency: R0-01
|
||||
Owners: Product Manager, Security architect, Documentation author
|
||||
Task description:
|
||||
- Finalize transition where `Administration` is owner of Trust and Signing and `Evidence and Audit` plus `Security and Risk` consume trust state via deep links and context panels.
|
||||
- Define canonical link paths, allowed embedding patterns, and non-allowed ownership regressions.
|
||||
- Define temporary aliasing behavior for legacy trust routes and timeline for removal.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Ownership and consumption model is explicit and final.
|
||||
- [ ] Cross-link contract is defined for all consuming screens.
|
||||
- [ ] Alias and deprecation behavior is defined by route family.
|
||||
- [ ] Auth scope and role implications are documented.
|
||||
|
||||
### R0-05 - Produce route deprecation and migration baseline
|
||||
Status: TODO
|
||||
Dependency: R0-03
|
||||
Owners: Project Manager, Frontend lead
|
||||
Task description:
|
||||
- Create a complete route baseline mapping current paths to target IA paths. Include routes from root navigation, settings-derived paths, and legacy redirects.
|
||||
- Each route must be assigned one explicit action: keep, redirect, alias, or remove-later. Include rationale and migration risk per high-traffic route.
|
||||
- Include sequence guidance for when redirects can be activated relative to implementation sprints.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Baseline map covers all root domains and major child route families.
|
||||
- [ ] Every mapped route has exactly one migration action.
|
||||
- [ ] High-risk deep-link routes have mitigation notes.
|
||||
- [ ] Activation sequence aligns with downstream sprint dependency plan.
|
||||
|
||||
### R0-06 - Bootstrap endpoint contract ledger v1
|
||||
Status: TODO
|
||||
Dependency: R0-02
|
||||
Owners: Project Manager, API architect, Module leads
|
||||
Task description:
|
||||
- Produce v1 endpoint contract ledger for all active-authority screens defined in `docs/modules/ui/v2-rewire/authority-matrix.md`. The ledger must be self-contained and include candidate endpoints, status class, owner module, auth scope impact, schema delta, and ticket linkage.
|
||||
- No screen may remain unclassified. `MISSING_NEW` entries must include proposed endpoint contracts and owning module.
|
||||
- Ledger must identify cross-module dependencies that require explicit allowance in implementation sprint files.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] All active-authority screens are present in ledger v1.
|
||||
- [ ] All rows have non-empty status class and owner module.
|
||||
- [ ] All `MISSING_NEW` rows include concrete proposed endpoint contracts.
|
||||
- [ ] Ledger review sign-off captured from frontend and backend leads.
|
||||
|
||||
### R0-07 - Publish S00 handoff packet
|
||||
Status: TODO
|
||||
Dependency: R0-06
|
||||
Owners: Project Manager
|
||||
Task description:
|
||||
- Publish a handoff packet for sprints `20260218_006` through `20260218_008` containing frozen decisions, unresolved risks, route migration baseline, and contract ledger references.
|
||||
- The handoff packet must explicitly list blocked topics (if any) and mitigation actions with owners.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Handoff packet is published and linked from the sprint file.
|
||||
- [ ] Downstream sprint owners and dependencies are explicit.
|
||||
- [ ] Remaining risks have owners and checkpoint dates.
|
||||
- [ ] All non-shipped exploratory work is reset to TODO with notes.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for v2 rewire spec freeze and contract-ledger bootstrap. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision pending: final rendering policy for Release Control-owned capabilities (`Releases`, `Approvals`, `Deployments`, `Regions and Environments`, `Bundles`) must be frozen before nav implementation.
|
||||
- Risk: unresolved Advisory Sources boundary can duplicate logic across Security and Risk, Integrations, and Platform Ops; mitigation is field-level ownership matrix in `R0-02`.
|
||||
- Risk: trust ownership transition can break historical deep links and user expectations; mitigation is explicit alias/deprecation policy in `R0-04` and `R0-05`.
|
||||
- Risk: hidden backend gaps may stall frontend sprints; mitigation is complete classification in `R0-06` with `MISSING_NEW` proposals.
|
||||
- Existing code references for migration analysis: `src/Web/StellaOps.Web/src/app/app.routes.ts`, `src/Web/StellaOps.Web/src/app/features/settings/settings.routes.ts`, `src/Web/StellaOps.Web/src/app/routes/legacy-redirects.routes.ts`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-02-19: Review drafts for `R0-01`, `R0-02`, and `R0-03`.
|
||||
- 2026-02-20: Review and sign off `R0-04` and `R0-05`.
|
||||
- 2026-02-21: Review `R0-06` ledger and publish `R0-07` handoff packet.
|
||||
@@ -0,0 +1,120 @@
|
||||
# Sprint 20260218_006 - UI V2 Rewire Navigation Shell and Route Migration
|
||||
|
||||
## Topic & Scope
|
||||
- Implement the canonical navigation shell and route framework for the new IA, using frozen outputs from sprint `20260218_005`.
|
||||
- Deliver a single rendering model for root domains and Release Control-owned capabilities with deterministic route behavior.
|
||||
- Include migration-safe aliases, breadcrumbs, and transition labels that preserve usability during staged cutover.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: route tree changes, nav model updates, redirect behavior tests, breadcrumb/label verification artifacts.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_005_DOCS_ui_v2_rewire_spec_freeze.md` must be DONE.
|
||||
- Downstream dependencies: required before `20260218_007`, `20260218_008`, `20260218_009`, and `20260218_010` can finalize routes.
|
||||
- Safe parallelism:
|
||||
- `N1-01` and `N1-02` can run in parallel after dependency resolution.
|
||||
- `N1-03` depends on `N1-01`.
|
||||
- `N1-04` depends on `N1-02`.
|
||||
- `N1-05` depends on `N1-01` through `N1-04`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/sprint-planning-guide.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_sprint_spec_package.md`
|
||||
- `src/Web/StellaOps.Web/src/app/app.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/layout/app-sidebar/app-sidebar.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/legacy-redirects.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/layout/breadcrumb/breadcrumb.component.ts`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### N1-01 - Implement canonical root-domain navigation model
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer, UX developer
|
||||
Task description:
|
||||
- Replace current sidebar root model with canonical domains in this order: Dashboard, Release Control, Security and Risk, Evidence and Audit, Integrations, Platform Ops, Administration.
|
||||
- Implement the frozen Release Control capability rendering policy from sprint `20260218_005` with explicit prevention of mixed variants.
|
||||
- Preserve scope-based visibility behavior and ensure hidden groups do not break active-route resolution.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Root nav displays canonical domains and labels exactly.
|
||||
- [ ] Release Control capability rendering matches frozen policy for desktop and mobile.
|
||||
- [ ] Scope gating behavior remains deterministic and tested.
|
||||
- [ ] No orphaned nav items link to removed or undefined routes.
|
||||
|
||||
### N1-02 - Build canonical route tree scaffolding for IA v2
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Refactor root route declarations to align with canonical IA while keeping runtime compatibility via staged aliases.
|
||||
- Introduce target route families for each domain and define placeholder-compatible child trees for sprints `007` to `015`.
|
||||
- Ensure route titles and metadata match canonical naming.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Root route tree includes all canonical domains.
|
||||
- [ ] Target child route families exist for all planned capability areas.
|
||||
- [ ] Route metadata uses canonical names and ownership.
|
||||
- [ ] Existing deep links continue to resolve via aliases or redirects.
|
||||
|
||||
### N1-03 - Implement breadcrumb and transition-label policy
|
||||
Status: TODO
|
||||
Dependency: N1-01
|
||||
Owners: Frontend developer, UX developer
|
||||
Task description:
|
||||
- Apply one breadcrumb convention across canonical domains and child routes.
|
||||
- Add transition labels (formerly called) where migration policy requires them.
|
||||
- Ensure transition labels are contextual, temporary, and do not alter canonical route names.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Breadcrumb behavior is consistent across root and child routes.
|
||||
- [ ] Transition labels appear only where specified by migration policy.
|
||||
- [ ] Canonical labels remain primary in all navigational surfaces.
|
||||
- [ ] Unit tests cover breadcrumb generation and transition-label conditions.
|
||||
|
||||
### N1-04 - Implement migration alias and redirect framework
|
||||
Status: TODO
|
||||
Dependency: N1-02
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Update redirect and alias rules to map legacy paths to canonical IA routes according to the baseline deprecation map from sprint `20260218_005`.
|
||||
- Ensure query parameters and fragments remain preserved through redirects.
|
||||
- Add guard-safe behavior for authenticated and unauthenticated redirect paths.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Legacy settings and historical routes map to canonical targets per approved policy.
|
||||
- [ ] Query and fragment preservation is verified for redirect families.
|
||||
- [ ] No redirect loops are present in route tests.
|
||||
- [ ] Redirect behavior is documented in sprint execution evidence.
|
||||
|
||||
### N1-05 - Navigation shell verification and regression tests
|
||||
Status: TODO
|
||||
Dependency: N1-04
|
||||
Owners: Frontend developer, QA
|
||||
Task description:
|
||||
- Add targeted unit and E2E checks for sidebar groups, root routes, breadcrumbs, and key redirects.
|
||||
- Verify behavior for desktop collapsed sidebar, desktop expanded, and mobile navigation drawer.
|
||||
- Verify scope-filtered user profiles do not produce dead-end navigation.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Unit tests cover nav model, visibility filtering, and breadcrumb rules.
|
||||
- [ ] E2E checks cover canonical root traversal and critical redirects.
|
||||
- [ ] Mobile and desktop nav behavior passes targeted checks.
|
||||
- [ ] No runtime nav errors in console/network during traversal.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for v2 navigation shell and route migration foundation. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision dependency: Release Control capability rendering policy from sprint `20260218_005` is binding.
|
||||
- Risk: redirect misconfiguration can silently break deep links; mitigate with explicit alias tests and no-loop checks.
|
||||
- Risk: scope-filtered visibility can hide required parent groups; mitigate with permission-profile test matrix.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/layout/app-sidebar/app-sidebar.component.ts`, `src/Web/StellaOps.Web/src/app/app.routes.ts`, `src/Web/StellaOps.Web/src/app/routes/legacy-redirects.routes.ts`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-02-20: Confirm canonical root nav and route tree (`N1-01`, `N1-02`).
|
||||
- 2026-02-21: Validate breadcrumb, transition labels, and redirect framework (`N1-03`, `N1-04`).
|
||||
- 2026-02-22: Complete verification and publish regression evidence (`N1-05`).
|
||||
@@ -0,0 +1,132 @@
|
||||
# Sprint 20260218_007 - UI V2 Rewire Administration Foundation
|
||||
|
||||
## Topic & Scope
|
||||
- Implement the Administration domain as the owner surface for IAM, tenants/branding, notifications, usage/limits, policy governance, trust/signing, and system admin controls.
|
||||
- Deliver fully specified Admin A0 through A7 screens with explicit cross-links to Release Control, Security and Risk, Evidence and Audit, and Platform Ops.
|
||||
- Preserve migration compatibility from legacy settings paths while converging on canonical IA ownership.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: implemented admin routes/screens, cross-link behavior proofs, access-control validation, and migration checks.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_005_DOCS_ui_v2_rewire_spec_freeze.md`, `SPRINT_20260218_006_FE_ui_v2_rewire_navigation_shell_route_migration.md`.
|
||||
- Downstream dependencies: informs `20260218_014` and `20260218_015` trust and policy consumption surfaces.
|
||||
- Safe parallelism:
|
||||
- `A2-01` and `A2-02` can run in parallel.
|
||||
- `A2-03` depends on `A2-01`.
|
||||
- `A2-04` depends on `A2-01` and `A2-02`.
|
||||
- `A2-05` depends on `A2-04`.
|
||||
- `A2-06` depends on `A2-01` through `A2-05`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-21.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_sprint_spec_package.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/settings/settings.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/app.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/core/auth/`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### A2-01 - Build Administration shell and A0 overview
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer, UX developer
|
||||
Task description:
|
||||
- Implement `Administration` root shell and overview (`A0`) with summary cards for Identity and Access, Tenant and Branding, Notifications, Usage and Limits, Policy Governance, Trust and Signing, and System.
|
||||
- Overview must include operational drilldown links for quotas and system health while maintaining Administration ownership.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Administration shell route and overview screen are implemented.
|
||||
- [ ] A0 contains all canonical cards and link targets.
|
||||
- [ ] Ownership labels are explicit and match canonical IA.
|
||||
- [ ] Legacy settings links route correctly into Administration surfaces.
|
||||
|
||||
### A2-02 - Implement A1 through A4 operational admin pages
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement `A1 Identity and Access`, `A2 Tenant and Branding`, `A3 Notifications`, and `A4 Usage and Limits` with complete page-level structure.
|
||||
- Each page must include explicit action surfaces and linkouts: identity scope diagnostics, tenant branding application state, notification rule/channel/template management, and usage policy controls.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] A1 through A4 routes and page components are implemented.
|
||||
- [ ] Each page includes defined sections, actions, and state handling.
|
||||
- [ ] Cross-links to dependent domains are present where required.
|
||||
- [ ] Access-controlled actions respect existing scopes and permissions.
|
||||
|
||||
### A2-03 - Implement A5 Policy Governance under Administration ownership
|
||||
Status: TODO
|
||||
Dependency: A2-01
|
||||
Owners: Frontend developer, Policy UX owner
|
||||
Task description:
|
||||
- Implement `A5 Policy Governance` as Administration-owned surface with deep links to Release Control gate usage contexts.
|
||||
- Include policy baseline, rule, simulation, and exception-workflow views or links according to frozen ownership policy.
|
||||
- Explicitly prevent regression to Release Control ownership labeling.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] A5 surface is present under Administration and labeled as owner.
|
||||
- [ ] Policy sub-areas are reachable and internally consistent.
|
||||
- [ ] Release Control linkage exists as consumer context, not owner.
|
||||
- [ ] Breadcrumbs and labels reflect final ownership policy.
|
||||
|
||||
### A2-04 - Implement A6 Trust and Signing plus A7 System
|
||||
Status: TODO
|
||||
Dependency: A2-02
|
||||
Owners: Frontend developer, Security UX owner
|
||||
Task description:
|
||||
- Implement `A6 Trust and Signing` and `A7 System` as Administration-owned surfaces.
|
||||
- A6 must expose keys, issuers, certificates, transparency log, trust scoring, and audit references, with explicit consumer links to Evidence and Security pages.
|
||||
- A7 must expose system admin controls and diagnostics with drilldowns into Platform Ops operational pages.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] A6 and A7 routes and UI surfaces are implemented.
|
||||
- [ ] A6 shows all trust primitives and allowed consumer links.
|
||||
- [ ] A7 includes diagnostics/admin controls and ops drilldowns.
|
||||
- [ ] Ownership labels prevent fallback to Evidence/System-root legacy models.
|
||||
|
||||
### A2-05 - Migrate legacy settings routes to Administration targets
|
||||
Status: TODO
|
||||
Dependency: A2-04
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Update route mappings for legacy settings items that now belong to Administration.
|
||||
- Ensure each legacy path resolves to one canonical Administration destination with preserved query and fragment where applicable.
|
||||
- Keep transitional compatibility labels where migration policy requires them.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] All Administration-owned legacy settings routes have explicit canonical targets.
|
||||
- [ ] Redirect/alias behavior matches deprecation baseline.
|
||||
- [ ] Query and fragment preservation verified.
|
||||
- [ ] No duplicate ownership routes remain active.
|
||||
|
||||
### A2-06 - Administration verification and access-control coverage
|
||||
Status: TODO
|
||||
Dependency: A2-05
|
||||
Owners: Frontend developer, QA
|
||||
Task description:
|
||||
- Add targeted tests for Administration route coverage, ownership labeling, deep links, and permission behavior.
|
||||
- Validate no regressions for authenticated admin and non-admin users.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Unit/E2E tests cover A0 through A7 primary paths.
|
||||
- [ ] Permission matrix checks validate visibility and action gating.
|
||||
- [ ] Migration routes are validated via automated or scripted checks.
|
||||
- [ ] Execution evidence captures passing behavior and residual risks.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for Administration ownership implementation in IA v2. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision binding: Administration owns Policy Governance, Trust and Signing, and System per sprint `20260218_005` freeze.
|
||||
- Risk: trust ownership migration can create duplicate entry points; mitigate by canonical route enforcement and alias pruning.
|
||||
- Risk: policy governance users may expect Release Control ownership; mitigate with explicit context links and transition labels.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/features/settings/settings.routes.ts`, `src/Web/StellaOps.Web/src/app/core/auth/`, `src/Web/StellaOps.Web/src/app/routes/legacy-redirects.routes.ts`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-02-21: A0-A4 implementation review (`A2-01`, `A2-02`).
|
||||
- 2026-02-22: A5-A7 ownership and linkage review (`A2-03`, `A2-04`).
|
||||
- 2026-02-23: Migration and verification closure (`A2-05`, `A2-06`).
|
||||
@@ -0,0 +1,134 @@
|
||||
# Sprint 20260218_008 - UI V2 Rewire Integrations and Platform Ops Data Integrity
|
||||
|
||||
## Topic & Scope
|
||||
- Implement canonical Integrations taxonomy and Platform Ops Data Integrity model with explicit separation of connectivity ownership and decision-impact consumption.
|
||||
- Deliver screen-level behavior for integrations hub/detail and platform data-integrity operations including feeds, mirrors, airgap, locks, and health confidence.
|
||||
- Ensure Security Data split is implemented exactly: Integrations and Platform Ops own source health operations, Security and Risk consumes gating impact.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: implemented integrations/ops routes and pages, cross-domain links, freshness-state behavior tests, and contract classification updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_005_DOCS_ui_v2_rewire_spec_freeze.md`, `SPRINT_20260218_006_FE_ui_v2_rewire_navigation_shell_route_migration.md`.
|
||||
- Downstream dependencies: feeds into dashboard, approvals, environment detail, and advisory sources in sprints `012`, `011`, `013`, and `014`.
|
||||
- Safe parallelism:
|
||||
- `I3-01` and `I3-02` can run in parallel.
|
||||
- `I3-03` depends on `I3-01`.
|
||||
- `I3-04` depends on `I3-02`.
|
||||
- `I3-05` depends on `I3-03` and `I3-04`.
|
||||
- `I3-06` depends on `I3-01` through `I3-05`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-10.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-15.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-21.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/operations/operations.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/integration-hub/`
|
||||
- `src/Web/StellaOps.Web/src/app/features/feed-mirror/`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### I3-01 - Implement Integrations domain taxonomy and overview
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement Integrations root with canonical categories: SCM, CI/CD, Registries, Secrets, Targets/Runtimes, Feeds, Notification Providers.
|
||||
- Implement Integrations overview with operational health summary, degradation indicators, and direct jump actions to connector detail pages.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Integrations taxonomy and root pages match canonical category model.
|
||||
- [ ] Overview includes status/freshness/impact summary cards.
|
||||
- [ ] Category filtering and search behavior is deterministic.
|
||||
- [ ] Broken/degraded connectors expose actionable drilldowns.
|
||||
|
||||
### I3-02 - Implement Platform Ops Data Integrity overview and subpages
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement Data Integrity as Platform Ops source of truth with subpages: overview, nightly report, feeds freshness, scan pipeline health, reachability ingest health, integration connectivity, DLQ and replays, data quality SLOs.
|
||||
- Ensure pages summarize and link to specialized operational pages without duplicating ownership responsibilities.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Data Integrity overview and all required subpages are implemented.
|
||||
- [ ] Subpage models include state for healthy, degraded, stale, and failed conditions.
|
||||
- [ ] Deep links route to owning operational screens.
|
||||
- [ ] No duplicated conflicting health source-of-truth is introduced.
|
||||
|
||||
### I3-03 - Implement Integration detail standard contract view
|
||||
Status: TODO
|
||||
Dependency: I3-01
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement standardized Integration detail template with required sections: config, status and health, errors/logs, test connection, impact map, permissions/scopes.
|
||||
- Impact map must explicitly list affected release, approvals, SBOM ingest, and evidence workflows.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Detail template is consistent across connector categories.
|
||||
- [ ] Impact map fields and links are present and actionable.
|
||||
- [ ] Scope/permission diagnostics are visible and accurate.
|
||||
- [ ] Error and recovery actions are available for degraded connectors.
|
||||
|
||||
### I3-04 - Implement Feeds and AirGap ops surfaces under Platform Ops
|
||||
Status: TODO
|
||||
Dependency: I3-02
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement or align pages for feed sources/freshness, mirrors, airgap bundles, and version locks under Platform Ops.
|
||||
- Ensure Integrations and Data Integrity pages link to these screens as operational drilldowns.
|
||||
- Enforce canonical ownership: these are operations controls, not settings controls.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Feed source, mirror, airgap, and lock pages are accessible under Platform Ops.
|
||||
- [ ] Cross-links from Integrations and Data Integrity are implemented.
|
||||
- [ ] Ownership labels and breadcrumbs are canonical.
|
||||
- [ ] No stale settings-era route remains primary for these capabilities.
|
||||
|
||||
### I3-05 - Implement Security Data split wiring and impact propagation
|
||||
Status: TODO
|
||||
Dependency: I3-04
|
||||
Owners: Frontend developer, Product engineer
|
||||
Task description:
|
||||
- Wire split contract for legacy Security Data:
|
||||
- Connectivity and freshness managed in Integrations and Platform Ops.
|
||||
- Decision impact consumed in Security and Risk Advisory Sources surface.
|
||||
- Implement explicit context payload transfer for source freshness and impact severity used by downstream domains.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Split ownership is visible and consistent in UI flows.
|
||||
- [ ] Context payloads for impact and freshness are available to downstream surfaces.
|
||||
- [ ] No single page incorrectly combines both ownership responsibilities.
|
||||
- [ ] Contract-ledger status is updated for affected rows.
|
||||
|
||||
### I3-06 - Verification, contract classification, and regression checks
|
||||
Status: TODO
|
||||
Dependency: I3-05
|
||||
Owners: Frontend developer, QA
|
||||
Task description:
|
||||
- Execute targeted tests for Integrations and Data Integrity route families, including degraded/stale states.
|
||||
- Update endpoint contract ledger with observed status class for all screens in this sprint scope.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Unit/E2E checks cover Integrations and Data Integrity critical paths.
|
||||
- [ ] Stale and degraded state behavior is validated.
|
||||
- [ ] Contract ledger rows for this sprint are updated and reviewed.
|
||||
- [ ] Residual risks are documented with concrete follow-up actions.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for Integrations and Platform Ops Data Integrity implementation. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision binding: Security Data ownership split from sprint `20260218_005` is mandatory.
|
||||
- Risk: same data shown by multiple domains may drift; mitigate with single-source ownership and linked drilldowns only.
|
||||
- Risk: degraded-state UX can become inconsistent across connectors; mitigate with one detail template and shared status conventions.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/features/integration-hub/`, `src/Web/StellaOps.Web/src/app/features/feed-mirror/`, `src/Web/StellaOps.Web/src/app/features/operations/operations.routes.ts`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-02-22: Integrations taxonomy and Data Integrity overview review (`I3-01`, `I3-02`).
|
||||
- 2026-02-23: Detail and Feeds/AirGap ops review (`I3-03`, `I3-04`).
|
||||
- 2026-02-24: Split wiring and verification closure (`I3-05`, `I3-06`).
|
||||
@@ -0,0 +1,129 @@
|
||||
# Sprint 20260218_009 - UI V2 Rewire Bundle Organizer and Lifecycle
|
||||
|
||||
## Topic & Scope
|
||||
- Implement the Release Control bundle lifecycle as the immutable release input model.
|
||||
- Deliver complete bundle catalog, bundle detail, bundle builder, bundle version detail, and materialize-to-environment flow.
|
||||
- Ensure bundle identity is digest-first and supports per-repository changelog and config contract materialization.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: bundle route implementation, builder workflow behavior, validation states, and contract-ledger updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_005_DOCS_ui_v2_rewire_spec_freeze.md`, `SPRINT_20260218_006_FE_ui_v2_rewire_navigation_shell_route_migration.md`, `SPRINT_20260218_008_FE_ui_v2_rewire_integrations_platform_ops_data_integrity.md`.
|
||||
- Downstream dependencies: required for promotions (`010`), approvals (`011`), environment detail (`013`), and dashboard risk summaries (`012`).
|
||||
- Safe parallelism:
|
||||
- `B4-01` and `B4-02` can run in parallel.
|
||||
- `B4-03` depends on `B4-01`.
|
||||
- `B4-04` depends on `B4-02`.
|
||||
- `B4-05` depends on `B4-03` and `B4-04`.
|
||||
- `B4-06` depends on `B4-01` through `B4-05`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-12.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/release-orchestrator/`
|
||||
- `src/Web/StellaOps.Web/src/app/core/api/`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### B4-01 - Implement bundle catalog and bundle detail
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement bundle catalog view with canonical columns: bundle name, latest bundle version, component count, regions/environments impact, readiness indicators.
|
||||
- Implement bundle detail with overview, versions, deployments usage, and evidence pointers.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Bundle catalog route and page are implemented with required fields.
|
||||
- [ ] Bundle detail route and sections are implemented.
|
||||
- [ ] Catalog-to-detail navigation and filtering work deterministically.
|
||||
- [ ] Empty and error states are implemented with actionable guidance.
|
||||
|
||||
### B4-02 - Implement bundle builder workflow shell
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer, UX developer
|
||||
Task description:
|
||||
- Implement builder workflow with steps: select component versions, config contracts, changelog preview, validation.
|
||||
- Builder must preserve a clear draft state model and prevent invalid step advancement.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Builder route and step navigation are implemented.
|
||||
- [ ] Step progression is gated by required validations.
|
||||
- [ ] Draft state is deterministic and recoverable on refresh/re-entry.
|
||||
- [ ] Step error messaging is explicit and actionable.
|
||||
|
||||
### B4-03 - Implement component selection and digest-first identity view
|
||||
Status: TODO
|
||||
Dependency: B4-01
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement component version selection table with digest-first identity and display version labels.
|
||||
- Show required metadata: SBOM presence/freshness, finding counters, reachability coverage, provenance pointers.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Component selector exposes digest-first identity and display version correctly.
|
||||
- [ ] Required metadata fields are visible and sortable/filterable.
|
||||
- [ ] Selection constraints prevent incompatible component combinations.
|
||||
- [ ] Selection state is carried forward to later builder steps.
|
||||
|
||||
### B4-04 - Implement config-contract and changelog steps
|
||||
Status: TODO
|
||||
Dependency: B4-02
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement config-contract step including required inputs, source bindings (Vault/Consul style), and readiness checks.
|
||||
- Implement changelog preview grouped by repository with clear commit/range summaries.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Config-contract step validates required inputs and binding readiness.
|
||||
- [ ] Changelog step presents per-repo diffs with deterministic ordering.
|
||||
- [ ] Validation failures are surfaced with clear remediation guidance.
|
||||
- [ ] Output from both steps is preserved in draft bundle state.
|
||||
|
||||
### B4-05 - Implement bundle validation and immutable version detail
|
||||
Status: TODO
|
||||
Dependency: B4-04
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement final validation step covering policy readiness, SBOM readiness, reachability evidence availability, and data-freshness preconditions.
|
||||
- Implement bundle version detail as immutable snapshot containing manifest digest, component map, config snapshot, and evidence links.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Validation summary includes all required readiness checks.
|
||||
- [ ] Version publish action creates immutable snapshot representation in UI state.
|
||||
- [ ] Bundle version detail displays manifest and linked evidence context.
|
||||
- [ ] Failure states block publish with explicit blocking reasons.
|
||||
|
||||
### B4-06 - Implement materialize-to-environment flow and verification
|
||||
Status: TODO
|
||||
Dependency: B4-05
|
||||
Owners: Frontend developer, QA
|
||||
Task description:
|
||||
- Implement materialize-to-environment flow from bundle version detail, including environment selection and input readiness summary.
|
||||
- Add targeted tests for bundle lifecycle routes and state transitions.
|
||||
- Update contract ledger rows for bundle pages and builder dependencies.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Materialization flow is available from bundle version detail.
|
||||
- [ ] Environment readiness summary includes required preconditions.
|
||||
- [ ] Bundle lifecycle unit/E2E checks pass.
|
||||
- [ ] Contract ledger updates are complete and reviewed.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for bundle organizer and lifecycle implementation. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision binding: bundle lifecycle semantics are digest-first and immutable.
|
||||
- Risk: builder complexity can create fragile client state; mitigate with explicit step state machine and test coverage.
|
||||
- Risk: missing backend composition endpoints may block progress; mitigate via early contract classification and `MISSING_NEW` proposals.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/features/release-orchestrator/`, `src/Web/StellaOps.Web/src/app/core/api/`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-02-23: Catalog/detail and builder shell review (`B4-01`, `B4-02`).
|
||||
- 2026-02-24: Selection/config/changelog review (`B4-03`, `B4-04`).
|
||||
- 2026-02-25: Validation/materialization and test closure (`B4-05`, `B4-06`).
|
||||
@@ -0,0 +1,114 @@
|
||||
# Sprint 20260218_010 - UI V2 Rewire Releases Promotions and Run Timeline
|
||||
|
||||
## Topic & Scope
|
||||
- Implement bundle-version anchored promotions and release detail flow in Release Control.
|
||||
- Deliver release creation, release list, release detail, and run timeline integration with rollback and replay-context entry points.
|
||||
- Ensure promotion decisions and execution states are traceable and linked to approvals, evidence, and environment context.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: release routes/screens, promotion wizard behavior, timeline behavior, and contract-ledger updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_009_FE_ui_v2_rewire_bundle_organizer_lifecycle.md`, `SPRINT_20260218_006_FE_ui_v2_rewire_navigation_shell_route_migration.md`, `SPRINT_20260218_008_FE_ui_v2_rewire_integrations_platform_ops_data_integrity.md`.
|
||||
- Downstream dependencies: required before approvals enhancements (`011`) and final dashboard/environment risk surfacing (`012`, `013`).
|
||||
- Safe parallelism:
|
||||
- `R5-01` and `R5-02` can run in parallel.
|
||||
- `R5-03` depends on `R5-01`.
|
||||
- `R5-04` depends on `R5-02`.
|
||||
- `R5-05` depends on `R5-03` and `R5-04`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-13.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-14.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/release-orchestrator/releases/`
|
||||
- `src/Web/StellaOps.Web/src/app/features/deployments/`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### R5-01 - Implement promotions list with bundle-version identity
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement release promotions list with canonical columns: promotion id, bundle version identity, source and target env path, gate status, decision status, run status, and freshness indicators.
|
||||
- Include list-level filters for environment, status, risk summary, and freshness state.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Promotions list route and page are implemented.
|
||||
- [ ] Required columns and filters are present.
|
||||
- [ ] Row navigation to release detail is deterministic.
|
||||
- [ ] Empty, loading, and error states are complete.
|
||||
|
||||
### R5-02 - Implement create promotion wizard
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement wizard for selecting bundle version, promotion path, target environments, and input materialization readiness.
|
||||
- Wizard must surface preflight checks and block submission when gating prerequisites are unresolved.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Create promotion wizard route and steps are implemented.
|
||||
- [ ] Preflight checks and blocking states are visible and enforceable.
|
||||
- [ ] Submission payload includes bundle-version identity and target path context.
|
||||
- [ ] Validation and failure messages are actionable.
|
||||
|
||||
### R5-03 - Implement release detail with gate and evidence summary
|
||||
Status: TODO
|
||||
Dependency: R5-01
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement release detail as canonical promotion case file with overview, gates summary, security snapshot, ops/data summary, and evidence pointers.
|
||||
- Ensure detail page deep-links into approvals, environment detail, and run timeline.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Release detail sections and summaries are implemented.
|
||||
- [ ] Deep links to approvals/env/run/evidence targets function correctly.
|
||||
- [ ] Gate status is human-readable and includes blocking rationale.
|
||||
- [ ] Page supports stale/partial data states gracefully.
|
||||
|
||||
### R5-04 - Implement run timeline shell and step detail integration
|
||||
Status: TODO
|
||||
Dependency: R5-02
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement run timeline entry from release detail showing stage checkpoints, step statuses, and evidence capture moments.
|
||||
- Implement step-detail navigation with logs/artifacts/evidence pointers and rollback trigger visibility.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Timeline view and step navigation are implemented.
|
||||
- [ ] Step detail includes logs, artifacts, and evidence pointers.
|
||||
- [ ] Rollback/retry control visibility follows status and role conditions.
|
||||
- [ ] Timeline state handling is deterministic for partial runs.
|
||||
|
||||
### R5-05 - Verify promotions and timeline flows and update contract ledger
|
||||
Status: TODO
|
||||
Dependency: R5-04
|
||||
Owners: Frontend developer, QA
|
||||
Task description:
|
||||
- Add targeted unit and E2E checks for release list, create wizard, release detail, and timeline paths.
|
||||
- Update endpoint contract ledger for promotions and run timeline APIs, including any `MISSING_NEW` proposals.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Tests cover create -> detail -> timeline flow.
|
||||
- [ ] Blocking and degraded states are tested.
|
||||
- [ ] Contract-ledger rows are updated and reviewed.
|
||||
- [ ] Residual risks are documented with owner and follow-up sprint.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for promotions and run timeline implementation. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision binding: promotions are anchored to immutable bundle versions.
|
||||
- Risk: run timeline may depend on backend step granularity not currently exposed; mitigate with early contract classification.
|
||||
- Risk: promotion preflight checks can diverge from approval checks; mitigate by reusing shared gate summary model.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/features/release-orchestrator/releases/`, `src/Web/StellaOps.Web/src/app/features/deployments/`, `src/Web/StellaOps.Web/src/app/core/api/`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-02-24: Promotions list and creation wizard review (`R5-01`, `R5-02`).
|
||||
- 2026-02-25: Release detail and timeline integration review (`R5-03`, `R5-04`).
|
||||
- 2026-02-26: Verification and contract-ledger closure (`R5-05`).
|
||||
@@ -0,0 +1,117 @@
|
||||
# Sprint 20260218_011 - UI V2 Rewire Approvals Decision Cockpit
|
||||
|
||||
## Topic & Scope
|
||||
- Implement approvals v2 as a self-sufficient decision cockpit with full operational/security/evidence context.
|
||||
- Deliver approvals queue and approval detail tabs: overview, gates, security, reachability, ops/data health, evidence, replay/verify, and history.
|
||||
- Ensure decision actions are auditable and clearly linked to policy, evidence, and environment impact.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: approvals UI implementation, decision-flow tests, audit-linked actions, and contract-ledger updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_010_FE_ui_v2_rewire_releases_promotions_run_timeline.md`, `SPRINT_20260218_008_FE_ui_v2_rewire_integrations_platform_ops_data_integrity.md`, `SPRINT_20260218_006_FE_ui_v2_rewire_navigation_shell_route_migration.md`.
|
||||
- Downstream dependencies: dashboard and environment standardization sprints consume approval summaries.
|
||||
- Safe parallelism:
|
||||
- `A6-01` and `A6-02` can run in parallel.
|
||||
- `A6-03` depends on `A6-01`.
|
||||
- `A6-04` depends on `A6-02`.
|
||||
- `A6-05` depends on `A6-03` and `A6-04`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-17.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-13.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/approvals/`
|
||||
- `src/Web/StellaOps.Web/src/app/core/api/`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### A6-01 - Implement approvals queue v2
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement approvals queue with decision-critical columns: request id, bundle version, source and target env, gate status, risk summary (`CritR`, SBOM freshness), data confidence, pending approvers, and age.
|
||||
- Add filter and search model for environment, status, risk type, and data confidence severity.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Queue route and page are implemented with required columns.
|
||||
- [ ] Filters and search support decision-critical triage.
|
||||
- [ ] Queue rows link to approval detail reliably.
|
||||
- [ ] Empty/error/loading states are complete.
|
||||
|
||||
### A6-02 - Implement approval detail overview and gates tabs
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement overview tab with promotion summary, target risk, data confidence summary, and quick decision context.
|
||||
- Implement gates tab with full gate trace including policy decisions, timestamps, and blocking rationale.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Overview and gates tabs are implemented.
|
||||
- [ ] Gate trace contains explicit pass/fail/waived states.
|
||||
- [ ] Blocking reasons are human-readable and actionable.
|
||||
- [ ] Tabs handle partial data and stale snapshots gracefully.
|
||||
|
||||
### A6-03 - Implement security, reachability, and ops/data tabs
|
||||
Status: TODO
|
||||
Dependency: A6-01
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement security tab showing SBOM findings by environment and delta context.
|
||||
- Implement reachability tab with hybrid B/I/R summary and evidence age.
|
||||
- Implement ops/data health tab with data integrity confidence and failing-source links.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Security tab includes env-scoped findings and summary metrics.
|
||||
- [ ] Reachability tab includes B/I/R coverage and evidence-age indicators.
|
||||
- [ ] Ops/data tab links to Data Integrity and source details.
|
||||
- [ ] All three tabs use consistent severity and freshness semantics.
|
||||
|
||||
### A6-04 - Implement evidence, replay/verify, and history tabs
|
||||
Status: TODO
|
||||
Dependency: A6-02
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement evidence tab with decision packet contents and export hooks.
|
||||
- Implement replay/verify tab for contextual verification path entry.
|
||||
- Implement history tab with decision lifecycle timeline and actor trail.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Evidence tab includes packet references and actions.
|
||||
- [ ] Replay/verify tab links to correct verification contexts.
|
||||
- [ ] History tab captures lifecycle chronology and actors.
|
||||
- [ ] Tabs preserve context identifiers across navigation.
|
||||
|
||||
### A6-05 - Implement decision actions and verify approvals flow
|
||||
Status: TODO
|
||||
Dependency: A6-04
|
||||
Owners: Frontend developer, QA
|
||||
Task description:
|
||||
- Implement approve/reject/defer/escalate actions with confirmation, reason capture, and auditable submission.
|
||||
- Add targeted tests for queue to detail traversal and decision action outcomes.
|
||||
- Update endpoint contract ledger entries for approvals and linked evidence/gate APIs.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Decision actions enforce reason capture and confirmation rules.
|
||||
- [ ] Action outcomes are reflected in queue/detail/history states.
|
||||
- [ ] Approvals flow tests pass for happy path and blocking path.
|
||||
- [ ] Contract-ledger rows are updated and reviewed.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for approvals decision cockpit implementation. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision binding: approvals must be decision-complete without forcing operators to hunt across domains.
|
||||
- Risk: tab payload fan-out may cause latency and partial data; mitigate with clear stale/partial states and lazy loading strategy.
|
||||
- Risk: decision actions without audit context can fail compliance; mitigate with enforced reason capture and history linkage.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/features/approvals/`, `src/Web/StellaOps.Web/src/app/core/api/`, `src/Web/StellaOps.Web/tests/e2e/`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-02-25: Queue and core tab review (`A6-01`, `A6-02`).
|
||||
- 2026-02-26: Advanced tabs review (`A6-03`, `A6-04`).
|
||||
- 2026-02-27: Decision action verification and ledger update (`A6-05`).
|
||||
@@ -0,0 +1,113 @@
|
||||
# Sprint 20260218_012 - UI V2 Rewire Dashboard V3 Mission Board
|
||||
|
||||
## Topic & Scope
|
||||
- Implement Dashboard v3 as the release mission board with environment risk, SBOM state, hybrid reachability, and data-integrity signals.
|
||||
- Deliver mission-critical drilldowns to releases, approvals, environment detail, security findings, and ops data integrity.
|
||||
- Ensure dashboard aggregates are accurate, freshness-aware, and non-duplicative of owning domains.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: dashboard UI implementation, card/drawer flows, cross-link tests, and aggregate contract-ledger updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_008_FE_ui_v2_rewire_integrations_platform_ops_data_integrity.md`, `SPRINT_20260218_010_FE_ui_v2_rewire_releases_promotions_run_timeline.md`, `SPRINT_20260218_011_FE_ui_v2_rewire_approvals_decision_cockpit.md`.
|
||||
- Downstream dependencies: consumed by environment detail and security/evidence consolidation sprints.
|
||||
- Safe parallelism:
|
||||
- `D7-01` and `D7-02` can run in parallel.
|
||||
- `D7-03` depends on `D7-01`.
|
||||
- `D7-04` depends on `D7-02`.
|
||||
- `D7-05` depends on `D7-03` and `D7-04`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-16.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/control-plane/`
|
||||
- `src/Web/StellaOps.Web/src/app/layout/`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### D7-01 - Implement dashboard header, filters, and mission summary
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement dashboard header with global filters (region, environment, time window) and mission status summary.
|
||||
- Include canonical mission summary indicators for active promotions, blocked promotions, highest risk environment, and data integrity status.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Header and global filters are implemented and functional.
|
||||
- [ ] Mission summary indicators are visible and context-aware.
|
||||
- [ ] Filter state is deterministic and URL-safe where required.
|
||||
- [ ] Empty and loading states are defined.
|
||||
|
||||
### D7-02 - Implement regional pipeline status board
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement regional pipeline board showing per-environment deploy status, SBOM freshness, CritR summary, and B/I/R coverage.
|
||||
- Provide direct links to environment detail and release detail from pipeline nodes.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Regional pipeline board includes required env-level status fields.
|
||||
- [ ] Node links route to environment and release context correctly.
|
||||
- [ ] Severity and freshness indicators follow shared conventions.
|
||||
- [ ] Board handles incomplete regional data without breaking layout.
|
||||
|
||||
### D7-03 - Implement SBOM findings snapshot and drawer flow
|
||||
Status: TODO
|
||||
Dependency: D7-01
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement SBOM findings snapshot card and expandable drawer with environment-level breakdown.
|
||||
- Include filters for critical reachable focus, prod-only scope, and stale/missing SBOM states.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Snapshot card is present with actionable summary values.
|
||||
- [ ] Drawer flow includes env breakdown and quick filters.
|
||||
- [ ] Drawer links to security findings with preserved context.
|
||||
- [ ] Error/stale indicators are explicit.
|
||||
|
||||
### D7-04 - Implement hybrid reachability and nightly/data-integrity cards
|
||||
Status: TODO
|
||||
Dependency: D7-02
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement hybrid reachability summary card (B/I/R coverage) and nightly/data-integrity signals card.
|
||||
- Cards must link to owning domains (Security and Risk, Platform Ops Data Integrity) and avoid duplicating deep operational controls.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Hybrid reachability and nightly/data cards are implemented.
|
||||
- [ ] Cards link to owning pages with context filters.
|
||||
- [ ] Card semantics and thresholds align with shared severity model.
|
||||
- [ ] No duplicated ownership behavior is introduced.
|
||||
|
||||
### D7-05 - Dashboard verification and aggregate contract updates
|
||||
Status: TODO
|
||||
Dependency: D7-04
|
||||
Owners: Frontend developer, QA
|
||||
Task description:
|
||||
- Add tests covering dashboard mission board interactions, drawer behavior, and drilldown links.
|
||||
- Update endpoint contract ledger rows for dashboard aggregate dependencies and freshness model.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Unit/E2E checks pass for dashboard critical flows.
|
||||
- [ ] Drilldown navigation is validated across key cards.
|
||||
- [ ] Aggregate contract rows updated in ledger.
|
||||
- [ ] Residual dashboard risks documented with follow-up owners.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for dashboard v3 mission-board implementation. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision binding: dashboard is a mission board and must summarize, not re-own, downstream domain controls.
|
||||
- Risk: aggregate cards may mask stale source data; mitigate with explicit freshness badges and stale state UX.
|
||||
- Risk: too many cards can fragment operator attention; mitigate by preserving critical path ordering and contextual drilldowns.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/features/control-plane/`, `src/Web/StellaOps.Web/src/app/layout/`, `src/Web/StellaOps.Web/src/app/core/api/`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-02-26: Header, filters, and pipeline board review (`D7-01`, `D7-02`).
|
||||
- 2026-02-27: Snapshot and integrity card review (`D7-03`, `D7-04`).
|
||||
- 2026-02-28: Verification and ledger update closure (`D7-05`).
|
||||
@@ -0,0 +1,115 @@
|
||||
# Sprint 20260218_013 - UI V2 Rewire Environment Detail Standardization
|
||||
|
||||
## Topic & Scope
|
||||
- Implement standardized Environment Detail as the single environment decision view.
|
||||
- Deliver canonical environment header and tabs: overview, deploy status, SBOM/findings, reachability, inputs, promotions/approvals, data confidence, evidence/audit.
|
||||
- Ensure environment page links to bundle, release run, security, ops, and evidence contexts without ownership duplication.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: environment detail implementation, tab behavior checks, cross-link validation, and contract-ledger updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_009_FE_ui_v2_rewire_bundle_organizer_lifecycle.md`, `SPRINT_20260218_010_FE_ui_v2_rewire_releases_promotions_run_timeline.md`, `SPRINT_20260218_008_FE_ui_v2_rewire_integrations_platform_ops_data_integrity.md`, `SPRINT_20260218_012_FE_ui_v2_rewire_dashboard_v3_mission_board.md`.
|
||||
- Downstream dependencies: provides core context for approvals, security, and evidence deep-link consistency.
|
||||
- Safe parallelism:
|
||||
- `E8-01` and `E8-02` can run in parallel.
|
||||
- `E8-03` depends on `E8-01`.
|
||||
- `E8-04` depends on `E8-02`.
|
||||
- `E8-05` depends on `E8-03` and `E8-04`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-18.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/release-orchestrator/environments/`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### E8-01 - Implement standardized environment header shell
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement environment detail shell with canonical header summary: deploy status, SBOM freshness, CritR, hybrid B/I/R coverage, and data confidence.
|
||||
- Header must include explicit identity for region, environment, and active bundle/release context.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Header shows all required summary fields.
|
||||
- [ ] Region/environment identity and context links are explicit.
|
||||
- [ ] Severity and freshness semantics align with shared model.
|
||||
- [ ] Header supports partial data with deterministic fallback states.
|
||||
|
||||
### E8-02 - Implement overview and deploy-status tabs
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement overview tab with top risks, pending actions, and quick links.
|
||||
- Implement deploy-status tab with runtime targets, service states, and recent deployment checkpoints.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Overview tab includes risk and action summaries.
|
||||
- [ ] Deploy tab includes target/service status detail.
|
||||
- [ ] Links route to release run and deployment details correctly.
|
||||
- [ ] Tab state remains stable across filter changes.
|
||||
|
||||
### E8-03 - Implement SBOM/findings and reachability tabs
|
||||
Status: TODO
|
||||
Dependency: E8-01
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement SBOM/findings tab with deployed inventory, SBOM state, CritR/HighR/HighNR summaries, and finding links.
|
||||
- Implement reachability tab with hybrid B/I/R matrix, source presence, and evidence age indicators.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] SBOM/findings tab includes env-scoped inventory and finding summary.
|
||||
- [ ] Reachability tab includes B/I/R matrix and evidence-age fields.
|
||||
- [ ] Links to Security and Risk findings preserve environment context.
|
||||
- [ ] Non-available data states are represented clearly.
|
||||
|
||||
### E8-04 - Implement inputs, promotions/approvals, data confidence, and evidence tabs
|
||||
Status: TODO
|
||||
Dependency: E8-02
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement inputs tab with configuration materialization readiness and binding diagnostics.
|
||||
- Implement promotions/approvals tab with env-scoped timeline and pending decisions.
|
||||
- Implement data confidence tab as env-scoped Data Integrity summary.
|
||||
- Implement evidence/audit tab with env snapshot and proof references.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Inputs tab includes readiness and binding visibility.
|
||||
- [ ] Promotions/approvals tab includes pending and historical context.
|
||||
- [ ] Data confidence tab links to owning Ops Data Integrity pages.
|
||||
- [ ] Evidence tab links to Evidence and Audit exports/references.
|
||||
|
||||
### E8-05 - Verify environment detail and update contract ledger
|
||||
Status: TODO
|
||||
Dependency: E8-04
|
||||
Owners: Frontend developer, QA
|
||||
Task description:
|
||||
- Add tests for environment detail shell and all canonical tabs.
|
||||
- Verify deep links to bundles, release runs, approvals, security, ops, and evidence.
|
||||
- Update endpoint contract ledger rows for environment-scoped data dependencies.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Tab-level tests cover major happy path and degraded path scenarios.
|
||||
- [ ] Cross-domain deep links are validated end-to-end.
|
||||
- [ ] Ledger rows for environment detail dependencies are updated.
|
||||
- [ ] Residual risks are recorded with owner and mitigation path.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for standardized environment detail implementation. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision binding: environment detail is the single environment decision page and must aggregate, not duplicate domain ownership.
|
||||
- Risk: tab fan-out can create latency or stale states; mitigate with explicit loading/staleness semantics.
|
||||
- Risk: inconsistent context propagation can break drilldowns; mitigate with canonical environment context payload across links.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/features/release-orchestrator/environments/`, `src/Web/StellaOps.Web/src/app/core/api/`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-02-27: Header and first tab-set review (`E8-01`, `E8-02`).
|
||||
- 2026-02-28: Remaining tab-set review (`E8-03`, `E8-04`).
|
||||
- 2026-03-01: Verification and ledger update closure (`E8-05`).
|
||||
@@ -0,0 +1,115 @@
|
||||
# Sprint 20260218_014 - UI V2 Rewire Security and Risk Consolidation
|
||||
|
||||
## Topic & Scope
|
||||
- Implement the consolidated Security and Risk domain with decision-first ordering.
|
||||
- Deliver risk overview, findings explorer/detail, vulnerabilities explorer/detail, SBOM lake/graph placement, VEX, exceptions, and Advisory Sources.
|
||||
- Preserve second-class visibility of reachability and enforce ownership split for advisory source operations vs decision impact.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: security route implementation, cross-link behavior, advisory-source behavior, and contract-ledger updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_005_DOCS_ui_v2_rewire_spec_freeze.md`, `SPRINT_20260218_008_FE_ui_v2_rewire_integrations_platform_ops_data_integrity.md`, `SPRINT_20260218_012_FE_ui_v2_rewire_dashboard_v3_mission_board.md`, `SPRINT_20260218_013_FE_ui_v2_rewire_environment_detail_standardization.md`.
|
||||
- Downstream dependencies: evidence and audit integration checks in sprint `015` and cutover in sprint `016`.
|
||||
- Safe parallelism:
|
||||
- `S9-01` and `S9-02` can run in parallel.
|
||||
- `S9-03` depends on `S9-01`.
|
||||
- `S9-04` depends on `S9-02`.
|
||||
- `S9-05` depends on `S9-03` and `S9-04`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-19.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_advisory_sources_spec.md` (or equivalent signed output from sprint `20260218_005`)
|
||||
- `docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/security/`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### S9-01 - Implement risk overview and findings explorer
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement risk overview as the entry page emphasizing what blocks releases and where critical reachable risk exists.
|
||||
- Implement findings explorer with filters for severity, reachability, environment, bundle, freshness, and exception status.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Risk overview and findings explorer routes are implemented.
|
||||
- [ ] Findings filters support decision-critical triage dimensions.
|
||||
- [ ] Risk-to-release and risk-to-environment links are functional.
|
||||
- [ ] Data-state behavior for stale/partial feeds is clear.
|
||||
|
||||
### S9-02 - Implement vulnerabilities explorer and detail surfaces
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement vulnerabilities explorer for CVE-centric analysis with impacted environment and disposition context.
|
||||
- Implement vulnerability detail with affected components, evidence pointers, exception linkage, and issuer/VEX context where applicable.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Vulnerabilities list and detail routes are implemented.
|
||||
- [ ] Required impacted-context fields are visible.
|
||||
- [ ] Links to findings, exceptions, and evidence are functional.
|
||||
- [ ] Placeholder-only legacy behavior is removed.
|
||||
|
||||
### S9-03 - Implement SBOM data surfaces and VEX/Exceptions integration
|
||||
Status: TODO
|
||||
Dependency: S9-01
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement SBOM lake and SBOM graph placement within Security and Risk domain with decision-context links.
|
||||
- Implement VEX and exceptions pages with explicit links to trust, policy, and approval implications.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] SBOM lake/graph pages are reachable within canonical security structure.
|
||||
- [ ] VEX and exceptions pages include decision-context links.
|
||||
- [ ] Trust consumer links align with Administration ownership policy.
|
||||
- [ ] Reachability remains second-class but visible in relevant views.
|
||||
|
||||
### S9-04 - Implement Advisory Sources screen and split ownership behavior
|
||||
Status: TODO
|
||||
Dependency: S9-02
|
||||
Owners: Frontend developer, Product engineer
|
||||
Task description:
|
||||
- Implement Advisory Sources according to signed S00 spec, including source health, decision-impact indicators, and drilldowns.
|
||||
- Enforce split behavior:
|
||||
- Integrations and Platform Ops own connectivity and mirror operations.
|
||||
- Security and Risk owns gating impact representation and policy relevance.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Advisory Sources route and screen are implemented per signed S00 spec.
|
||||
- [ ] Source health and decision-impact fields follow ownership matrix.
|
||||
- [ ] Drilldowns to Integrations and Platform Ops preserve context.
|
||||
- [ ] Conflict/stale/unavailable advisory states are explicitly handled.
|
||||
|
||||
### S9-05 - Security consolidation verification and ledger updates
|
||||
Status: TODO
|
||||
Dependency: S9-04
|
||||
Owners: Frontend developer, QA
|
||||
Task description:
|
||||
- Add targeted tests for all consolidated security routes and cross-domain links.
|
||||
- Update endpoint contract ledger rows for security and advisory-source dependencies.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Unit/E2E checks pass for risk/findings/vuln/SBOM/VEX/exceptions/advisory routes.
|
||||
- [ ] Cross-links to approvals/releases/env/evidence/ops are validated.
|
||||
- [ ] Contract-ledger rows updated with final status class and deltas.
|
||||
- [ ] Residual issues are recorded with owner and mitigation plan.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for Security and Risk consolidation implementation. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision binding: Security and Risk is decision-first; reachability remains visible as second-class context.
|
||||
- Risk: Advisory Sources can regress into mixed ownership; mitigate with strict field-level ownership contract from S00.
|
||||
- Risk: SBOM and vulnerability models may diverge in filters/labels; mitigate with shared taxonomy and filter-strip components.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/features/security/`, `src/Web/StellaOps.Web/src/app/core/api/`, `src/Web/StellaOps.Web/tests/e2e/`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-02-28: Core risk/findings/vuln review (`S9-01`, `S9-02`).
|
||||
- 2026-03-01: SBOM/VEX/Exceptions and Advisory Sources review (`S9-03`, `S9-04`).
|
||||
- 2026-03-02: Verification and ledger closure (`S9-05`).
|
||||
@@ -0,0 +1,115 @@
|
||||
# Sprint 20260218_015 - UI V2 Rewire Evidence and Audit Consolidation
|
||||
|
||||
## Topic & Scope
|
||||
- Implement consolidated Evidence and Audit domain centered on release, bundle, environment, and approval evidence retrieval.
|
||||
- Deliver evidence home router, evidence packs, bundles, export center, proof chains, replay/verify, and audit log surfaces.
|
||||
- Enforce trust ownership transition: Trust and Signing remains Administration-owned with Evidence as consumer.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: evidence route implementation, retrieval/export flows, audit navigation proofs, and contract-ledger updates.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_005_DOCS_ui_v2_rewire_spec_freeze.md`, `SPRINT_20260218_007_FE_ui_v2_rewire_administration_foundation.md`, `SPRINT_20260218_010_FE_ui_v2_rewire_releases_promotions_run_timeline.md`, `SPRINT_20260218_011_FE_ui_v2_rewire_approvals_decision_cockpit.md`.
|
||||
- Downstream dependencies: cutover and QA sprint `016`.
|
||||
- Safe parallelism:
|
||||
- `V10-01` and `V10-02` can run in parallel.
|
||||
- `V10-03` depends on `V10-01`.
|
||||
- `V10-04` depends on `V10-02`.
|
||||
- `V10-05` depends on `V10-03` and `V10-04`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/pack-20.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_trust_ownership_transition.md` (or equivalent signed output from sprint `20260218_005`)
|
||||
- `docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/evidence/`
|
||||
- `src/Web/StellaOps.Web/src/app/features/evidence-export/`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### V10-01 - Implement evidence home router and navigation model
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement Evidence home as router page that directs users by evidence need: promotion decision, bundle evidence, environment snapshot, proof verification, and audit trail.
|
||||
- Include clear entry actions to packs, bundles, exports, proof chains, replay, and audit log.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Evidence home route and page are implemented.
|
||||
- [ ] Router shortcuts map to canonical evidence surfaces.
|
||||
- [ ] Context keys for release/bundle/env/approval are preserved.
|
||||
- [ ] Empty/error states provide actionable next steps.
|
||||
|
||||
### V10-02 - Implement evidence packs, bundles, and detail pages
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement evidence packs list/detail and evidence bundles list/detail pages.
|
||||
- Detail pages must include payload summary, evidence inventory, related decisions, and export actions.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Packs and bundles list/detail routes are implemented.
|
||||
- [ ] Detail pages show inventory and relation context.
|
||||
- [ ] Export and cross-link actions are functional.
|
||||
- [ ] Search/filter behavior is deterministic.
|
||||
|
||||
### V10-03 - Implement export center, proof chains, and replay/verify
|
||||
Status: TODO
|
||||
Dependency: V10-01
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement export center with export jobs and scope templates.
|
||||
- Implement proof chains view and detail traversal.
|
||||
- Implement replay/verify surface with context-preserving entry from approvals and releases.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Export center, proof chains, and replay routes are implemented.
|
||||
- [ ] Context-preserving links from approvals/releases are functioning.
|
||||
- [ ] Job/status handling includes queued/running/failed/succeeded states.
|
||||
- [ ] Replay entry paths retain decision context identifiers.
|
||||
|
||||
### V10-04 - Implement consolidated audit log and trust consumer links
|
||||
Status: TODO
|
||||
Dependency: V10-02
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Implement consolidated audit log view with filters for actor, action, resource type, and domain context.
|
||||
- Implement consumer links from evidence pages to Administration-owned Trust and Signing pages per transition policy.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Audit log route and filter model are implemented.
|
||||
- [ ] Audit entries deep-link to related evidence/release/approval entities.
|
||||
- [ ] Trust links follow Administration ownership without duplicate owner pages.
|
||||
- [ ] Legacy trust-in-evidence ownership labels are removed.
|
||||
|
||||
### V10-05 - Evidence consolidation verification and ledger updates
|
||||
Status: TODO
|
||||
Dependency: V10-04
|
||||
Owners: Frontend developer, QA
|
||||
Task description:
|
||||
- Add targeted tests for end-to-end evidence retrieval/export/replay/audit navigation.
|
||||
- Update endpoint contract ledger rows for evidence APIs and ownership boundaries.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Unit/E2E checks pass for evidence critical workflows.
|
||||
- [ ] Cross-domain links from approvals/releases/env remain intact.
|
||||
- [ ] Contract-ledger rows are updated and reviewed.
|
||||
- [ ] Residual risks and blockers are captured with mitigation owners.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for Evidence and Audit consolidation implementation. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision binding: Trust and Signing ownership remains in Administration; Evidence consumes trust state.
|
||||
- Risk: evidence context keys can drift between pages; mitigate with unified context identifier model.
|
||||
- Risk: export and replay status handling may diverge by endpoint; mitigate with shared status component and contract alignment.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/features/evidence/`, `src/Web/StellaOps.Web/src/app/features/evidence-export/`, `src/Web/StellaOps.Web/src/app/core/api/`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-01: Home router and packs/bundles review (`V10-01`, `V10-02`).
|
||||
- 2026-03-02: Export/proof/replay and audit/trust-link review (`V10-03`, `V10-04`).
|
||||
- 2026-03-03: Verification and ledger closure (`V10-05`).
|
||||
@@ -0,0 +1,118 @@
|
||||
# Sprint 20260218_016 - UI V2 Rewire Cutover Redirects and QA Readiness
|
||||
|
||||
## Topic & Scope
|
||||
- Execute final IA cutover for canonical routes and labels with migration-safe redirects and compatibility behavior.
|
||||
- Complete end-to-end QA coverage for all root domains and critical workflows under the finalized IA.
|
||||
- Deliver release-readiness evidence package with residual risk register and go/no-go checklist.
|
||||
- Working directory: `src/Web/StellaOps.Web`.
|
||||
- Expected evidence: final redirect map implementation, E2E verification artifacts, accessibility checks, readiness report.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Upstream dependencies: `SPRINT_20260218_006_FE_ui_v2_rewire_navigation_shell_route_migration.md`, `SPRINT_20260218_007_FE_ui_v2_rewire_administration_foundation.md`, `SPRINT_20260218_008_FE_ui_v2_rewire_integrations_platform_ops_data_integrity.md`, `SPRINT_20260218_009_FE_ui_v2_rewire_bundle_organizer_lifecycle.md`, `SPRINT_20260218_010_FE_ui_v2_rewire_releases_promotions_run_timeline.md`, `SPRINT_20260218_011_FE_ui_v2_rewire_approvals_decision_cockpit.md`, `SPRINT_20260218_012_FE_ui_v2_rewire_dashboard_v3_mission_board.md`, `SPRINT_20260218_013_FE_ui_v2_rewire_environment_detail_standardization.md`, `SPRINT_20260218_014_FE_ui_v2_rewire_security_risk_consolidation.md`, `SPRINT_20260218_015_FE_ui_v2_rewire_evidence_audit_consolidation.md`.
|
||||
- Safe parallelism:
|
||||
- `C11-01` and `C11-02` can run in parallel.
|
||||
- `C11-03` depends on `C11-01`.
|
||||
- `C11-04` depends on `C11-02`.
|
||||
- `C11-05` depends on `C11-03` and `C11-04`.
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/v2-rewire/source-of-truth.md`
|
||||
- `docs/modules/ui/v2-rewire/authority-matrix.md`
|
||||
- `docs/modules/ui/v2-rewire/S00_route_deprecation_map.md` (or equivalent signed output from sprint `20260218_005`)
|
||||
- `docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/legacy-redirects.routes.ts`
|
||||
- `src/Web/StellaOps.Web/tests/e2e/`
|
||||
- `docs/qa/feature-checks/FLOW.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### C11-01 - Finalize redirect and alias cutover behavior
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer
|
||||
Task description:
|
||||
- Apply final redirect/alias behavior from approved deprecation map for all legacy route families.
|
||||
- Remove temporary aliases marked remove-later where safe and maintain required compatibility aliases.
|
||||
- Verify query and fragment preservation for all retained redirects.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Redirect map implementation matches approved deprecation baseline.
|
||||
- [ ] Removed aliases are explicitly listed with rationale.
|
||||
- [ ] Preserved aliases are tested for query/fragment behavior.
|
||||
- [ ] No redirect loops remain.
|
||||
|
||||
### C11-02 - Apply final canonical labeling and breadcrumb cleanup
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Frontend developer, UX developer
|
||||
Task description:
|
||||
- Remove stale transition labels where migration window is complete and keep only required compatibility labels.
|
||||
- Ensure all root and child routes use canonical names in nav, headers, breadcrumbs, and search entries.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Canonical naming is consistent across all navigation surfaces.
|
||||
- [ ] Deprecated labels are removed or marked with explicit sunset policy.
|
||||
- [ ] Breadcrumb chains are accurate across all root domains.
|
||||
- [ ] Search and quick-nav entries align with canonical names.
|
||||
|
||||
### C11-03 - Execute critical-path E2E verification suite
|
||||
Status: TODO
|
||||
Dependency: C11-01
|
||||
Owners: QA, Frontend developer
|
||||
Task description:
|
||||
- Execute E2E verification for critical workflows:
|
||||
- dashboard to release to approval decision flow,
|
||||
- bundle to promotion to run timeline,
|
||||
- environment detail to security and evidence,
|
||||
- admin trust/policy/system cross-domain flows,
|
||||
- integrations and data-integrity stale/failure handling.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Critical-path E2E scenarios pass with evidence artifacts.
|
||||
- [ ] Failures are triaged with root cause and owner assignment.
|
||||
- [ ] No unresolved critical severity failures remain.
|
||||
- [ ] Verification records include command output and artifact paths.
|
||||
|
||||
### C11-04 - Execute accessibility and regression hardening checks
|
||||
Status: TODO
|
||||
Dependency: C11-02
|
||||
Owners: QA, Frontend developer
|
||||
Task description:
|
||||
- Run focused accessibility checks on nav, complex tables, tab systems, and action dialogs.
|
||||
- Run regression checks for permissions, mobile navigation, and high-latency/stale-data UI behavior.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Accessibility checks are run and documented for critical surfaces.
|
||||
- [ ] Keyboard and focus behavior is verified for nav and dialogs.
|
||||
- [ ] Mobile navigation and responsive behavior pass checks.
|
||||
- [ ] Regression issues are triaged with owner and priority.
|
||||
|
||||
### C11-05 - Publish release readiness package and go/no-go decision
|
||||
Status: TODO
|
||||
Dependency: C11-04
|
||||
Owners: Project Manager, QA lead
|
||||
Task description:
|
||||
- Publish final readiness package including route cutover summary, QA outcomes, contract-ledger status, and residual risks.
|
||||
- Produce go/no-go recommendation with explicit blocking conditions if unresolved.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Readiness package includes route, QA, and contract-ledger summaries.
|
||||
- [ ] Residual risks are clearly prioritized with mitigation owner.
|
||||
- [ ] Go/no-go recommendation is explicit and justified.
|
||||
- [ ] Sprint closure status reflects real outcome (`DONE` or `BLOCKED`).
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-02-18 | Sprint created for final IA cutover, redirects, and QA readiness. | Planning |
|
||||
|
||||
## Decisions & Risks
|
||||
- Risk: removing aliases too early can break saved deep links; mitigate with explicit traffic/usage checks before removal.
|
||||
- Risk: final label cleanup can confuse users during transition; mitigate with controlled compatibility labels and communication.
|
||||
- Risk: cross-domain E2E suite may reveal latent contract gaps; mitigate with strict triage and no silent acceptance.
|
||||
- Existing code references: `src/Web/StellaOps.Web/src/app/routes/legacy-redirects.routes.ts`, `src/Web/StellaOps.Web/tests/e2e/`, `src/Web/StellaOps.Web/src/app/layout/`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-03: Redirect and labeling cutover review (`C11-01`, `C11-02`).
|
||||
- 2026-03-04: E2E and accessibility/regression review (`C11-03`, `C11-04`).
|
||||
- 2026-03-05: Readiness package and go/no-go decision (`C11-05`).
|
||||
34
docs/modules/ui/v2-rewire/README.md
Normal file
34
docs/modules/ui/v2-rewire/README.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# UI v2 Rewire (Canonical Planning Set)
|
||||
|
||||
This directory contains two things:
|
||||
- Raw iterative design packs (`pack-01.md` ... `pack-21.md`)
|
||||
- Cleansed planning inputs for sprint decomposition
|
||||
|
||||
Use these files as the planning entrypoint:
|
||||
- `source-of-truth.md` - canonical IA decisions and normalized terminology
|
||||
- `authority-matrix.md` - pack precedence, supersession, and explicit overrides
|
||||
- `sprint-planning-guide.md` - how to split this redesign into many implementation sprints
|
||||
- `multi-sprint-plan.md` - first full many-sprint decomposition (Draft 1)
|
||||
|
||||
S00 package files:
|
||||
- `S00_sprint_spec_package.md` - detailed S00 sprint spec with acceptance criteria
|
||||
- `S00_contract_ledger_template.md` - reusable endpoint contract ledger template
|
||||
- `S00_endpoint_contract_ledger_v1.md` - starter ledger sheet for immediate use
|
||||
|
||||
## Precedence policy
|
||||
|
||||
This planning set uses a strict rule: for overlapping decisions, **higher pack number wins**.
|
||||
|
||||
A higher pack that does not define a screen in detail does not erase the latest lower-pack detail for that screen.
|
||||
|
||||
## Raw materials
|
||||
|
||||
Raw packs are preserved as historical input and should not be used directly as the source of truth for sprint planning:
|
||||
- `pack-01.md` ... `pack-21.md`
|
||||
- `prompt.txt`
|
||||
|
||||
## Planning rule
|
||||
|
||||
When a sprint references a UI redesign requirement, it must cite:
|
||||
1. The canonical file (`source-of-truth.md` and/or `authority-matrix.md`), and
|
||||
2. The authoritative pack section listed there.
|
||||
45
docs/modules/ui/v2-rewire/S00_advisory_sources_spec.md
Normal file
45
docs/modules/ui/v2-rewire/S00_advisory_sources_spec.md
Normal file
@@ -0,0 +1,45 @@
|
||||
# S00 Advisory Sources Specification
|
||||
|
||||
Status: Draft (created for sprint planning pointer integrity)
|
||||
Date: 2026-02-18
|
||||
|
||||
## Purpose
|
||||
Define `Security and Risk -> Advisory Sources` as the decision-impact view of advisory-source health.
|
||||
|
||||
## Ownership split
|
||||
- `Integrations` owns source connector configuration, credentials, and connectivity checks.
|
||||
- `Platform Ops` owns mirror/freshness operation workflows.
|
||||
- `Security and Risk` owns advisory decision impact (gate relevance, risk confidence impact).
|
||||
|
||||
## Screen structure
|
||||
- Header: scope filters (region, env, source family, freshness severity).
|
||||
- Summary cards: healthy sources, stale sources, unavailable sources, conflicting-source warnings.
|
||||
- Source table columns:
|
||||
- Source name
|
||||
- Last successful ingest
|
||||
- Freshness SLA
|
||||
- Current freshness age
|
||||
- Signature/trust status
|
||||
- Impacted decisions count
|
||||
- Impact severity
|
||||
- Actions: open connector config, open mirror ops, open impacted findings/gates
|
||||
- Detail panel:
|
||||
- Source status timeline
|
||||
- Conflict diagnostics
|
||||
- Signed/unsigned advisory ratio
|
||||
- Impacted release/approval/environment references
|
||||
|
||||
## State behavior
|
||||
- Healthy: all freshness and signature checks pass.
|
||||
- Stale: freshness age exceeds SLA; show gating confidence warning.
|
||||
- Unavailable: source unreachable; mark impacted decisions as degraded confidence.
|
||||
- Conflict: source statements disagree; show conflict badge and triage action.
|
||||
|
||||
## Required links
|
||||
- To `Integrations` connector detail with preserved source id.
|
||||
- To `Platform Ops` feeds/mirror page with preserved source id.
|
||||
- To `Security and Risk` findings filtered by source impact.
|
||||
|
||||
## Contract notes
|
||||
- This screen likely requires an aggregate endpoint composed from integrations + ops + security data.
|
||||
- Initial classification expected: `MISSING_NEW` pending contract definition.
|
||||
27
docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md
Normal file
27
docs/modules/ui/v2-rewire/S00_endpoint_contract_ledger_v1.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# S00 Endpoint Contract Ledger v1 (Starter)
|
||||
|
||||
Status: Starter sheet
|
||||
Instructions: replace placeholder values with discovered implementation reality.
|
||||
Template source: `S00_contract_ledger_template.md`
|
||||
|
||||
| Domain | Screen/Page | Canonical source refs | Current route/page | Current endpoint candidate(s) | Status | Owner module | Auth scope impact | Schema delta summary | Decision/risk notes | Action ticket |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| Dashboard | Dashboard v3 mission board | `source-of-truth.md 3.2`, `authority-matrix.md A: Dashboard`, `pack-16.md` | `/` (control-plane/dashboard variants) | `TBD` | `EXISTS_ADAPT` | `Web` | `TBD` | aggregate model for CritR, SBOM freshness, B/I/R, data integrity likely needs composition changes | route naming and model aggregation not finalized | `S00-T05-DASH-01` |
|
||||
| Release Control | Bundle catalog/detail/builder | `source-of-truth.md 3.1`, `authority-matrix.md A: bundles`, `pack-12.md` | `/releases/*` and related bundle placeholders | `TBD` | `MISSING_NEW` | `ReleaseOrchestrator` | `TBD` | bundle-version lifecycle and materialization contracts likely incomplete | high risk for schema spread across modules | `S00-T05-RC-01` |
|
||||
| Release Control | Promotions list/create/detail | `source-of-truth.md 3.1`, `authority-matrix.md A: releases`, `pack-13.md` | `/releases/*` | `TBD` | `EXISTS_ADAPT` | `ReleaseOrchestrator` | `TBD` | bundle-version anchoring required in promotion contracts | depends on bundle contract finalization | `S00-T05-RC-02` |
|
||||
| Approvals | Approvals v2 tabs and decision packet | `source-of-truth.md 3.3`, `authority-matrix.md A: approvals`, `pack-17.md` | `/approvals/*` | `TBD` | `EXISTS_ADAPT` | `Policy` | `TBD` | richer gate trace and ops/data context payloads expected | cross-service joins may be needed | `S00-T05-APR-01` |
|
||||
| Release Runs | Run timeline and rollback | `source-of-truth.md 3.1`, `authority-matrix.md A: run timeline`, `pack-14.md` | `/deployments/*` and run views | `TBD` | `EXISTS_ADAPT` | `ReleaseOrchestrator` | `TBD` | checkpoint-level evidence/log linkage may be partial | rollback guard semantics must be explicit | `S00-T05-RUN-01` |
|
||||
| Environment | Environment detail standard tabs | `source-of-truth.md 3.1 and 3.6`, `authority-matrix.md A: env detail`, `pack-18.md` | `/environments/*` | `TBD` | `EXISTS_ADAPT` | `ReleaseOrchestrator` | `TBD` | env summary requires deploy+security+ops evidence merge | risk of expensive fan-out queries | `S00-T05-ENV-01` |
|
||||
| Security and Risk | Risk overview/findings/vuln/vex/exceptions | `source-of-truth.md 3.4`, `authority-matrix.md A: security`, `pack-19.md` | `/security/*` | `TBD` | `EXISTS_ADAPT` | `Scanner` | `TBD` | decision-first grouping and filters may require endpoint normalization | mapping from existing pages may be non-trivial | `S00-T05-SEC-01` |
|
||||
| Security and Risk | Advisory Sources | `source-of-truth.md 3.4 and 5`, `authority-matrix.md B: legacy security data split`, `pack-21.md` | `TBD` | `TBD` | `MISSING_NEW` | `Integrations` | `TBD` | final screen spec pending S00-T01, likely needs new aggregate endpoint | ownership boundary unresolved until S00 freeze | `S00-T05-SEC-02` |
|
||||
| Evidence and Audit | Evidence home/packs/bundles/export/proof/replay/audit | `source-of-truth.md 3.5`, `authority-matrix.md A: evidence`, `pack-20.md` | `/evidence/*` | `TBD` | `EXISTS_ADAPT` | `EvidenceLocker` | `TBD` | requires consolidated navigation model and consistent search keys | trust links must follow administration ownership override | `S00-T05-EVID-01` |
|
||||
| Administration | A0-A7 admin surfaces (IAM, policy, trust, system) | `source-of-truth.md 2.2 and 3.8`, `authority-matrix.md A: administration`, `pack-21.md` | `/settings/*` migration targets `TBD` | `TBD` | `EXISTS_ADAPT` | `Authority` | `TBD` | ownership shift from settings to administration needs route/permissions cleanup | high migration surface area | `S00-T05-ADM-01` |
|
||||
| Integrations | Integrations taxonomy and detail + feeds tie-in | `source-of-truth.md 3.7`, `authority-matrix.md A: integrations`, `pack-21.md`, `pack-10.md` | `/settings/integrations/*` and related | `TBD` | `EXISTS_ADAPT` | `Integrations` | `TBD` | advisory connectivity and impact mapping may require model split | coordinate with Advisory Sources spec | `S00-T05-INT-01` |
|
||||
| Platform Ops | Data Integrity and Feeds/AirGap ops | `source-of-truth.md 3.6`, `authority-matrix.md A: ops`, `pack-15.md`, `pack-10.md` | `/operations/*` | `TBD` | `EXISTS_ADAPT` | `Orchestrator` | `TBD` | data-integrity aggregate likely spans scheduler/orchestrator/integrations | ensure no duplicated source-of-truth cards | `S00-T05-OPS-01` |
|
||||
|
||||
## Completion checklist
|
||||
|
||||
- [ ] Replace all `TBD` values with concrete route and endpoint references.
|
||||
- [ ] Verify one status class per row.
|
||||
- [ ] Add rows for additional active-authority screens discovered during route audit.
|
||||
- [ ] Link each `Action ticket` to a concrete sprint task.
|
||||
19
docs/modules/ui/v2-rewire/S00_handoff_packet.md
Normal file
19
docs/modules/ui/v2-rewire/S00_handoff_packet.md
Normal file
@@ -0,0 +1,19 @@
|
||||
# S00 Handoff Packet
|
||||
|
||||
Status: Placeholder (created for sprint planning pointer integrity)
|
||||
Date: 2026-02-18
|
||||
|
||||
## Upstream artifacts
|
||||
- `S00_advisory_sources_spec.md`
|
||||
- `S00_nav_rendering_policy.md`
|
||||
- `S00_trust_ownership_transition.md`
|
||||
- `S00_route_deprecation_map.md`
|
||||
- `S00_endpoint_contract_ledger_v1.md`
|
||||
|
||||
## Downstream target sprints
|
||||
- `SPRINT_20260218_006_FE_ui_v2_rewire_navigation_shell_route_migration.md`
|
||||
- `SPRINT_20260218_007_FE_ui_v2_rewire_administration_foundation.md`
|
||||
- `SPRINT_20260218_008_FE_ui_v2_rewire_integrations_platform_ops_data_integrity.md`
|
||||
|
||||
## Current status
|
||||
- This packet is a planning placeholder and will be expanded when sprint `20260218_005` reaches DONE.
|
||||
25
docs/modules/ui/v2-rewire/S00_nav_rendering_policy.md
Normal file
25
docs/modules/ui/v2-rewire/S00_nav_rendering_policy.md
Normal file
@@ -0,0 +1,25 @@
|
||||
# S00 Nav Rendering Policy
|
||||
|
||||
Status: Draft (created for sprint planning pointer integrity)
|
||||
Date: 2026-02-18
|
||||
|
||||
## Policy statement
|
||||
Release Control-owned capabilities may be rendered as direct shortcuts if and only if ownership remains labeled as Release Control in breadcrumbs and headers.
|
||||
|
||||
## Allowed model
|
||||
- Root domains remain canonical.
|
||||
- Shortcuts allowed for `Releases` and `Approvals` when they route to Release Control-owned routes.
|
||||
- `Bundles`, `Deployments`, and `Regions and Environments` remain under Release Control navigation hierarchy.
|
||||
|
||||
## Breadcrumb rules
|
||||
- Any shortcut route must render breadcrumb prefix `Release Control`.
|
||||
- Header titles use canonical naming; optional compatibility labels may be temporary.
|
||||
|
||||
## Non-allowed model
|
||||
- Dual ownership labels for same screen.
|
||||
- Divergent mobile vs desktop ownership paths.
|
||||
- Legacy settings-first entry as primary owner path.
|
||||
|
||||
## Route guidance
|
||||
- Use alias redirects for historical direct paths.
|
||||
- Canonical targets must live under final IA route families.
|
||||
26
docs/modules/ui/v2-rewire/S00_route_deprecation_map.md
Normal file
26
docs/modules/ui/v2-rewire/S00_route_deprecation_map.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# S00 Route Deprecation Map
|
||||
|
||||
Status: Draft baseline (created for sprint planning pointer integrity)
|
||||
Date: 2026-02-18
|
||||
|
||||
## Purpose
|
||||
Baseline mapping for legacy route families to canonical IA targets.
|
||||
|
||||
## Route action values
|
||||
- `keep`
|
||||
- `redirect`
|
||||
- `alias`
|
||||
- `remove-later`
|
||||
|
||||
## Baseline mapping examples
|
||||
| Legacy family | Canonical target family | Action |
|
||||
| --- | --- | --- |
|
||||
| `/settings/*` admin-owned surfaces | `/administration/*` | `redirect` |
|
||||
| `/settings/security-data` | split to `/integrations/*` and `/security/*` contexts | `redirect` |
|
||||
| `/integrations/*` legacy settings paths | `/integrations/*` canonical root | `alias` |
|
||||
| historical trust routes | `/administration/trust*` | `redirect` |
|
||||
| historical ops aliases | `/operations/*` canonical root | `alias` |
|
||||
|
||||
## Notes
|
||||
- Full detailed map is completed in sprint `20260218_005` task `R0-05`.
|
||||
- Query and fragment preservation is required for redirect families.
|
||||
23
docs/modules/ui/v2-rewire/S00_trust_ownership_transition.md
Normal file
23
docs/modules/ui/v2-rewire/S00_trust_ownership_transition.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# S00 Trust Ownership Transition
|
||||
|
||||
Status: Draft (created for sprint planning pointer integrity)
|
||||
Date: 2026-02-18
|
||||
|
||||
## Ownership decision
|
||||
`Administration` is the owner domain for Trust and Signing.
|
||||
|
||||
## Consumer model
|
||||
- `Evidence and Audit` consumes trust state through deep links and contextual trust indicators.
|
||||
- `Security and Risk` consumes issuer/signature confidence as decision context.
|
||||
|
||||
## Route policy
|
||||
- Legacy trust routes redirect or alias to Administration trust pages.
|
||||
- Evidence and Security pages must not host owner-duplicate trust management screens.
|
||||
|
||||
## UX policy
|
||||
- Trust actions (rotate, issuer management, cert lifecycle) remain in Administration.
|
||||
- Consumer pages provide contextual links with preserved entity ids.
|
||||
|
||||
## Risk controls
|
||||
- Prevent duplicate owner surfaces.
|
||||
- Ensure breadcrumbs and page headers always indicate Administration ownership.
|
||||
32
docs/modules/ui/v2-rewire/all.md
Normal file
32
docs/modules/ui/v2-rewire/all.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# UI v2 Rewire - Cleansed Index
|
||||
|
||||
This file is the canonical entrypoint for planning work.
|
||||
|
||||
## Use these first
|
||||
|
||||
- `README.md`
|
||||
- `source-of-truth.md`
|
||||
- `authority-matrix.md`
|
||||
- `sprint-planning-guide.md`
|
||||
- `multi-sprint-plan.md`
|
||||
|
||||
## S00 package
|
||||
|
||||
- `S00_sprint_spec_package.md`
|
||||
- `S00_contract_ledger_template.md`
|
||||
- `S00_endpoint_contract_ledger_v1.md`
|
||||
|
||||
## Raw pack archive (historical inputs)
|
||||
|
||||
- `pack-01.md` ... `pack-21.md`
|
||||
- `prompt.txt`
|
||||
|
||||
## Precedence reminder
|
||||
|
||||
For overlapping guidance, higher pack number wins.
|
||||
|
||||
For partial higher packs, keep latest lower-pack detail only for uncovered screens.
|
||||
|
||||
## Planning policy
|
||||
|
||||
Do not open sprint tickets directly from raw packs without citing canonical files above.
|
||||
64
docs/modules/ui/v2-rewire/authority-matrix.md
Normal file
64
docs/modules/ui/v2-rewire/authority-matrix.md
Normal file
@@ -0,0 +1,64 @@
|
||||
# UI v2 Rewire Authority Matrix
|
||||
|
||||
Status: Canonical planning reference
|
||||
Date: 2026-02-18
|
||||
|
||||
This matrix defines which pack is authoritative for each capability and which packs are superseded.
|
||||
|
||||
## A) Capability authority
|
||||
|
||||
| Capability area | Authoritative pack(s) | Superseded packs | Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| Dashboard mission board | `pack-16.md` | `pack-01.md`, `pack-04.md`, `pack-08.md`, `pack-11.md` | Keep release-centric board with SBOM/CritR/Data Integrity signals. |
|
||||
| Release bundles and organizer | `pack-12.md`, `pack-21.md` | `pack-01.md`, `pack-02.md`, `pack-04.md`, `pack-08.md`, `pack-11.md` | Pack 21 sets placement; Pack 12 keeps detailed builder and lifecycle flows. |
|
||||
| Releases promotion flow | `pack-13.md` | `pack-01.md`, `pack-04.md`, `pack-08.md` | Bundle-version anchored promotion model. |
|
||||
| Approvals detailed decision flow | `pack-17.md` and `pack-13.md` | `pack-01.md`, `pack-04.md`, `pack-08.md` | Pack 17 overrides approval detail/tab model; Pack 13 still provides base coupling to promotions. |
|
||||
| Run timeline / rollback / replay context | `pack-14.md` | Earlier implicit run views in packs 1/4/8 | Canonical run lifecycle and checkpoint model. |
|
||||
| Environment detail standard | `pack-18.md` | `pack-01.md`, `pack-04.md`, `pack-08.md`, `pack-11.md` | Standardized header and env tab set. |
|
||||
| Security decision-first console | `pack-19.md` plus `pack-21.md` (advisory mapping) | `pack-03.md`, `pack-07.md` | Pack 19 is base Security model; Pack 21 adds Advisory Sources split intent. |
|
||||
| Evidence and audit chain | `pack-20.md` | `pack-03.md`, `pack-09.md`, `pack-11.md` | Pack 20 is authoritative except Trust ownership override from Pack 21. |
|
||||
| Ops data confidence model | `pack-15.md`, `pack-21.md`, `pack-10.md` | `pack-03.md`, `pack-06.md`, `pack-09.md`, `pack-11.md` | Pack 15 defines Data Integrity; Pack 21 defines ops taxonomy; Pack 10 retains feeds/airgap detail. |
|
||||
| Integrations structure | `pack-21.md`, `pack-10.md` | `pack-02.md`, `pack-05.md`, `pack-09.md` | Pack 21 sets taxonomy; Pack 10 keeps concrete hub/detail flows. |
|
||||
| Administration structure | `pack-21.md` | `pack-02.md`, `pack-05.md`, `pack-09.md`, `pack-11.md` | Canonical A0..A7 admin model. |
|
||||
|
||||
## B) Explicit higher-pack overrides
|
||||
|
||||
| Decision | Replaced guidance | Canonical guidance |
|
||||
| --- | --- | --- |
|
||||
| Policy Governance location | Release Control variants in Packs 5 and 9 | `Administration -> Policy Governance` (`pack-21.md`) |
|
||||
| Trust & Signing ownership | Evidence ownership in Packs 9, 11, and 20 | `Administration -> Trust & Signing` with Evidence/Security cross-links (`pack-21.md`) |
|
||||
| System location | Operations Platform Admin in Pack 9, root System in Pack 11 | `Administration -> System` with Platform Ops drilldowns (`pack-21.md`) |
|
||||
| Legacy Security Data split | Mixed settings-placement drafts in Packs 2/5/9/10 | Connectivity in Integrations/Ops, decision impact in Security (`pack-21.md`) |
|
||||
|
||||
## C) Pack lifecycle classification
|
||||
|
||||
| Pack | Status for planning | Primary reason |
|
||||
| --- | --- | --- |
|
||||
| `pack-01.md` | Superseded baseline | Early release-control draft replaced by later domain packs. |
|
||||
| `pack-02.md` | Superseded baseline | Early settings/admin/integration placement replaced. |
|
||||
| `pack-03.md` | Superseded baseline | Early security/evidence/ops model replaced by 15/19/20/21. |
|
||||
| `pack-04.md` | Superseded baseline | Early Release Control model replaced by 12/13/16/17/18/21. |
|
||||
| `pack-05.md` | Superseded baseline | Transitional admin/integration moves replaced by 21. |
|
||||
| `pack-06.md` | Superseded baseline | Ops structure replaced by 15 and 21 taxonomy. |
|
||||
| `pack-07.md` | Superseded baseline | Security model replaced by 19. |
|
||||
| `pack-08.md` | Partially superseded reference | Useful as RC nesting reference only; most details replaced. |
|
||||
| `pack-09.md` | Superseded baseline | Settings migration draft overridden by 21. |
|
||||
| `pack-10.md` | Active partial authority | Still needed for detailed Integrations/Feeds/AirGap flows. |
|
||||
| `pack-11.md` | Superseded baseline | Replaced by 12-21 and overridden by 21 on key ownerships. |
|
||||
| `pack-12.md` | Active authority | Bundle organizer deep specification. |
|
||||
| `pack-13.md` | Active authority | Promotion flow baseline; approvals partially overridden by 17. |
|
||||
| `pack-14.md` | Active authority | Run timeline, checkpoints, rollback/replay hooks. |
|
||||
| `pack-15.md` | Active authority | Data Integrity operations model. |
|
||||
| `pack-16.md` | Active authority | Dashboard v3 canonical model. |
|
||||
| `pack-17.md` | Active authority | Approvals v2 canonical detail model. |
|
||||
| `pack-18.md` | Active authority | Environment detail canonical standard. |
|
||||
| `pack-19.md` | Active authority | Security consolidation baseline. |
|
||||
| `pack-20.md` | Active authority with override | Evidence consolidation; Trust ownership overridden by 21. |
|
||||
| `pack-21.md` | Highest-precedence authority | Final admin/integration/settings split and top-level grouping intent. |
|
||||
|
||||
## D) Raw pack usage policy
|
||||
|
||||
For sprint planning, use raw packs only through this sequence:
|
||||
1. Find capability in Section A.
|
||||
2. Start with listed authoritative pack(s).
|
||||
3. Open superseded packs only for migration context or missing implementation detail.
|
||||
266
docs/modules/ui/v2-rewire/multi-sprint-plan.md
Normal file
266
docs/modules/ui/v2-rewire/multi-sprint-plan.md
Normal file
@@ -0,0 +1,266 @@
|
||||
# UI v2 Rewire Multi Sprint Plan (Draft 1)
|
||||
|
||||
Status: Ready for sprint authoring
|
||||
Date: 2026-02-18
|
||||
Source set: `source-of-truth.md`, `authority-matrix.md`, `sprint-planning-guide.md`
|
||||
|
||||
## Scope and intent
|
||||
|
||||
This is the first implementation decomposition for the v2 UI rewire.
|
||||
It is designed for many execution sprints with clear dependencies and parallel lanes.
|
||||
|
||||
Precedence rule: higher pack number wins for overlap.
|
||||
|
||||
## Mandatory contract workflow (all sprints)
|
||||
|
||||
For each screen in sprint scope, classify backend readiness:
|
||||
- `EXISTS_COMPAT`
|
||||
- `EXISTS_ADAPT`
|
||||
- `MISSING_NEW`
|
||||
|
||||
Each sprint must produce a contract ledger with:
|
||||
- screen
|
||||
- required behavior
|
||||
- current endpoint candidate
|
||||
- status class
|
||||
- auth scope impact
|
||||
- schema delta
|
||||
- owner module
|
||||
|
||||
## Wave map
|
||||
|
||||
| Wave | Sprints | Goal |
|
||||
| --- | --- | --- |
|
||||
| Wave 0 | S00 | Freeze final spec and remove residual ambiguity |
|
||||
| Wave 1 | S01, S02, S03 | Navigation shell and foundational admin/integration/ops taxonomy |
|
||||
| Wave 2 | S04, S05, S06, S07 | Release core (bundles, promotions, approvals, runs) |
|
||||
| Wave 3 | S08, S09, S10, S11 | Dashboard, env standardization, security and evidence consolidation |
|
||||
| Wave 4 | S12, S13 | Migration cutover, redirects, QA hardening, release readiness |
|
||||
|
||||
## Sprint catalog
|
||||
|
||||
### S00 - Spec freeze and unresolved gaps
|
||||
- Canonical packs: 21, 19, 20
|
||||
- Goal: lock unresolved model gaps before feature implementation starts.
|
||||
- Primary outputs:
|
||||
- final `Advisory Sources` screen spec (Security and Risk)
|
||||
- final rule for Release Control-owned capability rendering (shortcut vs nested)
|
||||
- final Trust ownership transition policy (Administration owner, Evidence consumer)
|
||||
- final route deprecation map baseline
|
||||
- Contract work:
|
||||
- start global endpoint ledger, initial status for all top-level screens.
|
||||
- Dependencies: none.
|
||||
- Parallelism: blocks S01-S03 start for any unresolved ownership topic.
|
||||
|
||||
### S01 - Nav shell and route framework
|
||||
- Canonical packs: 21, 16
|
||||
- Goal: create stable shell for new IA without breaking existing behavior.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- root nav groups aligned to canonical IA
|
||||
- breadcrumb updates and migration labels
|
||||
- route alias skeleton for staged cutover
|
||||
- Contract work:
|
||||
- ledger for nav-linked routes and their current API assumptions.
|
||||
- Dependencies: S00.
|
||||
- Parallelism: can run with S02 and S03 after S00 decisions are frozen.
|
||||
|
||||
### S02 - Administration and Integrations restructuring
|
||||
- Canonical packs: 21, 10
|
||||
- Goal: move settings-heavy capability into Administration and Integrations model.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- Admin A0-A7 routing and page ownership
|
||||
- Integrations taxonomy and detail flow alignment
|
||||
- Security Data split wiring (Integrations + Platform Ops + Security)
|
||||
- Contract work:
|
||||
- classify admin and integration endpoints; identify missing APIs for advisory source health and impact mapping.
|
||||
- Dependencies: S00, S01.
|
||||
- Parallelism: can run with S03.
|
||||
|
||||
### S03 - Platform Ops and Data Integrity foundation
|
||||
- Canonical packs: 15, 21, 10
|
||||
- Goal: establish Data Integrity as the operational truth source.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- Data Integrity overview and subviews
|
||||
- ops links from dashboard/approvals/security placeholders
|
||||
- feeds/airgap ops alignment with integrations view
|
||||
- Contract work:
|
||||
- classify freshness, job health, ingest, DLQ, and integration connectivity APIs.
|
||||
- Dependencies: S00, S01.
|
||||
- Parallelism: can run with S02.
|
||||
|
||||
### S04 - Bundle organizer and bundle lifecycle
|
||||
- Canonical packs: 12, 21
|
||||
- Goal: implement bundle-first model for release inputs.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- bundle catalog/detail/builder flow
|
||||
- component version selection and config contract steps
|
||||
- materialize to environment flow shell
|
||||
- Contract work:
|
||||
- classify component inventory, digest mapping, changelog, and materialization APIs.
|
||||
- define new schemas where missing (`MISSING_NEW`).
|
||||
- Dependencies: S00, S01, S02.
|
||||
- Parallelism: can start before S05.
|
||||
|
||||
### S05 - Releases promotion flow (bundle-version anchored)
|
||||
- Canonical packs: 13
|
||||
- Goal: convert release flow to immutable bundle-version promotions.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- promotions list and create wizard
|
||||
- release detail and gate summary model
|
||||
- links to run timeline, approvals, evidence snapshots
|
||||
- Contract work:
|
||||
- classify promotion creation/status/history APIs and gate evaluation contracts.
|
||||
- Dependencies: S04.
|
||||
- Parallelism: can run with S06 once S04 contracts are stable.
|
||||
|
||||
### S06 - Approvals v2 decision cockpit
|
||||
- Canonical packs: 17, 13
|
||||
- Goal: make approvals self-sufficient for decisioning.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- approvals queue v2
|
||||
- approval detail tabs (overview, gates, security, reachability, ops/data, evidence, replay, history)
|
||||
- consistent cross-links to Security/Evidence/Ops/Release Control
|
||||
- Contract work:
|
||||
- classify approval packet, gate trace, decision action, and evidence retrieval APIs.
|
||||
- Dependencies: S05 and S03 baseline availability.
|
||||
- Parallelism: partial overlap with S07 allowed.
|
||||
|
||||
### S07 - Run timeline, checkpoints, rollback and replay context
|
||||
- Canonical packs: 14
|
||||
- Goal: provide auditable execution timeline for each promotion run.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- run timeline page
|
||||
- step detail with logs/artifacts/evidence capture points
|
||||
- rollback and rerun controls with safe gating
|
||||
- Contract work:
|
||||
- classify run-step logs/artifact/retry/rollback APIs and permissions.
|
||||
- Dependencies: S05.
|
||||
- Parallelism: can run with S06.
|
||||
|
||||
### S08 - Dashboard v3 mission board
|
||||
- Canonical packs: 16
|
||||
- Goal: upgrade dashboard to release-risk mission board.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- env risk panel (`CritR`, SBOM freshness, B/I/R coverage)
|
||||
- nightly/data integrity signal cards
|
||||
- fast drilldowns to approvals/releases/security/ops
|
||||
- Contract work:
|
||||
- classify aggregated dashboard endpoints and freshness metadata contracts.
|
||||
- Dependencies: S03, S05, S06.
|
||||
- Parallelism: can run with S09.
|
||||
|
||||
### S09 - Environment detail standardization
|
||||
- Canonical packs: 18
|
||||
- Goal: unify environment decision state in one screen shell.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- standard env header
|
||||
- tabs for deploy, SBOM/findings, reachability, inputs, promotions/approvals, data confidence, evidence
|
||||
- canonical deep links into bundle/run/security/evidence pages
|
||||
- Contract work:
|
||||
- classify environment-scoped status and evidence APIs.
|
||||
- Dependencies: S03, S04, S05.
|
||||
- Parallelism: can run with S08 and S10.
|
||||
|
||||
### S10 - Security and Risk consolidation
|
||||
- Canonical packs: 19, 21
|
||||
- Goal: implement decision-first Security model with advisory-source split.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- risk overview, findings explorer/detail, vulnerabilities explorer/detail
|
||||
- SBOM lake/graph placement, VEX, exceptions
|
||||
- Advisory Sources screen per S00 finalized spec
|
||||
- Contract work:
|
||||
- classify findings/vuln/vex/exception/advisory-source APIs and filtering contracts.
|
||||
- Dependencies: S00, S03, S08.
|
||||
- Parallelism: can run with S11 once cross-link contracts stabilize.
|
||||
|
||||
### S11 - Evidence and Audit consolidation
|
||||
- Canonical packs: 20 with 21 trust override
|
||||
- Goal: implement evidence chain navigation and audit retrieval model.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- evidence home router
|
||||
- evidence packs, bundles, export center, proof chains, replay/verify, audit log
|
||||
- Trust links to Administration-owned surface
|
||||
- Contract work:
|
||||
- classify evidence pack/bundle/export/proof/replay/audit APIs and ownership boundaries.
|
||||
- Dependencies: S00, S05, S06.
|
||||
- Parallelism: can run with S10.
|
||||
|
||||
### S12 - Migration and redirect cutover
|
||||
- Canonical packs: 21 plus affected domain packs
|
||||
- Goal: make IA migration safe for existing users and links.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- full redirect map for legacy settings and historical aliases
|
||||
- breadcrumb and legacy-name compatibility labels
|
||||
- deprecation telemetry hooks
|
||||
- Contract work:
|
||||
- no new domain APIs expected; verify alias routes and fallback behaviors.
|
||||
- Dependencies: S01-S11 (or at least all impacted route owners).
|
||||
- Parallelism: mostly late-phase integration sprint.
|
||||
|
||||
### S13 - E2E QA hardening and release readiness
|
||||
- Canonical packs: all active authority packs
|
||||
- Goal: prove end-to-end behavior against final IA and contracts.
|
||||
- Working directory (implementation): `src/Web/StellaOps.Web`
|
||||
- Primary outputs:
|
||||
- route and workflow E2E coverage for all root domains
|
||||
- accessibility and regression checks for nav and critical workflows
|
||||
- final contract ledger closure report
|
||||
- Contract work:
|
||||
- verify all screens have final status not `MISSING_NEW`.
|
||||
- Dependencies: S02-S12 completion candidates.
|
||||
- Parallelism: can stage as rolling QA, but final signoff occurs last.
|
||||
|
||||
## Cross-module backend ownership map (planning)
|
||||
|
||||
These modules are likely to receive backend contract work during implementation sprints:
|
||||
- `src/ReleaseOrchestrator/`
|
||||
- `src/Policy/`
|
||||
- `src/EvidenceLocker/`
|
||||
- `src/Attestor/`
|
||||
- `src/Signer/`
|
||||
- `src/Integrations/`
|
||||
- `src/Scanner/`
|
||||
- `src/Orchestrator/`
|
||||
- `src/Scheduler/`
|
||||
- `src/Authority/`
|
||||
|
||||
Each sprint that touches these must include explicit cross-module allowance in its sprint file.
|
||||
|
||||
## Initial sequencing recommendation
|
||||
|
||||
1. Execute S00 to remove final ambiguity.
|
||||
2. Run S01 + S02 + S03 in parallel.
|
||||
3. Start release core S04 -> S05, then branch into S06 and S07.
|
||||
4. Run S08 + S09 + S10 + S11 as parallel domain upgrades.
|
||||
5. Finish with S12 migration cutover and S13 final QA signoff.
|
||||
|
||||
## Proposed sprint filename seeds (for `docs/implplan` authoring)
|
||||
|
||||
- `SPRINT_20260218_001_DOCS_ui_v2_rewire_spec_freeze.md` (S00)
|
||||
- `SPRINT_20260218_002_FE_ui_v2_rewire_nav_shell.md` (S01)
|
||||
- `SPRINT_20260218_003_FE_ui_v2_rewire_admin_integrations.md` (S02)
|
||||
- `SPRINT_20260218_004_FE_ui_v2_rewire_platform_ops_data_integrity.md` (S03)
|
||||
- `SPRINT_20260218_005_FE_ui_v2_rewire_bundle_lifecycle.md` (S04)
|
||||
- `SPRINT_20260218_006_FE_ui_v2_rewire_releases_promotions.md` (S05)
|
||||
- `SPRINT_20260218_007_FE_ui_v2_rewire_approvals_v2.md` (S06)
|
||||
- `SPRINT_20260218_008_FE_ui_v2_rewire_run_timeline.md` (S07)
|
||||
- `SPRINT_20260218_009_FE_ui_v2_rewire_dashboard_v3.md` (S08)
|
||||
- `SPRINT_20260218_010_FE_ui_v2_rewire_environment_detail.md` (S09)
|
||||
- `SPRINT_20260218_011_FE_ui_v2_rewire_security_consolidation.md` (S10)
|
||||
- `SPRINT_20260218_012_FE_ui_v2_rewire_evidence_audit_consolidation.md` (S11)
|
||||
- `SPRINT_20260218_013_FE_ui_v2_rewire_migration_redirects.md` (S12)
|
||||
- `SPRINT_20260218_014_FE_ui_v2_rewire_release_readiness_qa.md` (S13)
|
||||
|
||||
Note: creation of official sprint files is intentionally deferred until write scope includes `docs/implplan`.
|
||||
583
docs/modules/ui/v2-rewire/pack-01.md
Normal file
583
docs/modules/ui/v2-rewire/pack-01.md
Normal file
@@ -0,0 +1,583 @@
|
||||
# Pack 1 — Release Control (root menus)
|
||||
|
||||
## Legend (used everywhere)
|
||||
|
||||
* **CritR** = *Critical Reachable* findings count (hybrid reachability)
|
||||
* **SBOM** = SBOM presence + freshness (OK / Stale / Missing)
|
||||
* **Cov** = reachability coverage sources: **B/I/R** = Build / Image (Dover/Docker) / Runtime
|
||||
Example: `Cov 2/3` means two sources available; hover shows which.
|
||||
* **Hybrid Reachability** = union/merge of Build + Image + Runtime reachability signals.
|
||||
|
||||
---
|
||||
|
||||
## 0) Left-nav structure (Release Control as root)
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
subgraph LeftNav["Left Nav"]
|
||||
subgraph RC["Release Control (ROOT)"]
|
||||
DASH["Dashboard<br/>(formerly: Control Plane)"]
|
||||
REL["Releases<br/>(formerly: Releases)"]
|
||||
BUN["Bundles<br/>(NEW: Release Bundle Organizer)"]
|
||||
APR["Approvals<br/>(formerly: Approvals)"]
|
||||
DEP["Deployments<br/>(formerly: Active Deployments widget)"]
|
||||
REG["Regions & Environments<br/>(formerly: env pipeline widget)"]
|
||||
end
|
||||
|
||||
subgraph SR["Security & Risk (group)"]
|
||||
SR1["Risk Overview (formerly: Security Overview)"]
|
||||
SR2["Findings (formerly: Security Findings)"]
|
||||
SR3["Reachability Coverage (NEW)"]
|
||||
SR4["SBOM Explorer (formerly: SBOM Graph)"]
|
||||
SR5["VEX Hub (formerly: VEX Hub)"]
|
||||
SR6["Exceptions (formerly: Exceptions)"]
|
||||
end
|
||||
|
||||
subgraph EA["Evidence & Audit (group)"]
|
||||
EA1["Decision Capsules (formerly: Evidence Bundles / Packets)"]
|
||||
EA2["Proof Chains (formerly: Proof Chains)"]
|
||||
EA3["Replay / Verify (formerly: Replay/Verify)"]
|
||||
EA4["Export Center (formerly: Export)"]
|
||||
EA5["Coverage Metrics (formerly: SBOM Lake)"]
|
||||
end
|
||||
|
||||
subgraph IN["Integrations (group)"]
|
||||
IN1["Integrations Hub (formerly: Integrations)"]
|
||||
IN2["Feeds & Mirrors (formerly: Operations → Feeds)"]
|
||||
end
|
||||
|
||||
subgraph PO["Platform Ops (group)"]
|
||||
PO1["Nightly Ops Report (NEW)"]
|
||||
PO2["Platform Health (formerly: Platform Health)"]
|
||||
PO3["Jobs / Orchestrator (formerly: Orchestrator)"]
|
||||
PO4["Scheduler Runs (formerly: Scheduler)"]
|
||||
PO5["Dead Letter (formerly: Dead Letter)"]
|
||||
PO6["Quotas & Usage (formerly: Quotas)"]
|
||||
end
|
||||
|
||||
subgraph AD["Administration (group)"]
|
||||
AD1["Policy Governance"]
|
||||
AD2["Trust & Signing"]
|
||||
AD3["Identity & Access"]
|
||||
AD4["System"]
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1) Release Control — menu/screen graph (Pack 1 scope)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
DASH --> REL
|
||||
DASH --> BUN
|
||||
DASH --> APR
|
||||
DASH --> DEP
|
||||
DASH --> REG
|
||||
|
||||
REL --> RDETAIL["Release Detail"]
|
||||
BUN --> BDETAIL["Bundle Detail / Compose"]
|
||||
APR --> ADETAIL["Approval Detail"]
|
||||
REG --> EDETAIL["Environment Detail"]
|
||||
DEP --> DDETAIL["Deployment Detail"]
|
||||
|
||||
%% common crosslinks (second-class but not buried)
|
||||
DASH -. "CritR hotspots" .-> FIND["Security & Risk → Findings"]
|
||||
RDETAIL -. "Risk tab" .-> FIND
|
||||
BDETAIL -. "Component findings" .-> FIND
|
||||
ADETAIL -. "Evidence preview" .-> CAPS["Evidence & Audit → Decision Capsule"]
|
||||
DDETAIL -. "Proof" .-> CAPS
|
||||
|
||||
%% nightly ops signal (dashboard card)
|
||||
DASH -. "Nightly failures" .-> NIGHT["Platform Ops → Nightly Ops Report"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 1 — Dashboard (Release Control)
|
||||
|
||||
**Formerly:** `Control Plane` (plus some signals scattered in `Security Overview`, `Integrations`, `Platform Health`).
|
||||
**Why changed:** Stella Ops needs a **release-centric “mission board”**: what is promoting, what is blocked, and what is risky *by region/env* — including **SBOM status + hybrid reachability (CritR)** and **nightly data freshness**. This prevents “green deploy / red risk” blind spots.
|
||||
|
||||
### Mermaid — Dashboard navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
DASH["Dashboard"] -->|click release row| RDETAIL["Release Detail"]
|
||||
DASH -->|pending approvals| APR["Approvals"]
|
||||
DASH -->|active deployments| DEP["Deployments"]
|
||||
DASH -->|region pipeline| REG["Regions & Environments"]
|
||||
DASH -->|CritR hotspot| FIND["Security & Risk → Findings (filtered)"]
|
||||
DASH -->|Nightly failures| NIGHT["Platform Ops → Nightly Ops Report"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Dashboard
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Stella Ops [Search releases/digests/CVEs] Region: All▼ Env: All▼ Time: 24h▼ |
|
||||
| Status: Offline OK | Feed: Live | Policy Pack: latest | Evidence: ON |
|
||||
+----------------------------------------------------------------------------------+
|
||||
| RELEASE CONTROL DASHBOARD (formerly: Control Plane) |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Region Pipelines (Deploy + SBOM + Risk) |
|
||||
| US-East: Dev[Deploy OK|SBOM OK|CritR 0|Cov 3/3] -> Stg[OK|OK|0|3/3] -> |
|
||||
| Prod[DEGRADED|SBOM STALE|CritR 4|Cov 2/3] |
|
||||
| EU-West: Dev[OK|OK|0|3/3] -> Stg[OK|MISSING|CritR ?|Cov 1/3] -> Prod[OK|OK|1|3/3]|
|
||||
| APAC: ... |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Pending Approvals (2) | Active Deployments (1) |
|
||||
| - API Gateway v2.1.0 US-E/Prod | - Hotfix 1.2.4 US-East/Prod RUNNING |
|
||||
| Gate: PASS Approvals: 1/2 | Targets: 1/1 Evidence: sealing... |
|
||||
| - User Service v3.0.0-rc1 EU/Prod| |
|
||||
| Gate: BLOCK (CritR 2) | |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Critical Reachable Hotspots (CritR) | Nightly Ops Signals |
|
||||
| - US-East/Prod: CritR 4 (openssl, log4j...) | SBOM Rescan: WARN (1 failed) |
|
||||
| - EU-West/Prod: CritR 1 (glibc...) | CVE Feeds: ERROR (NVD stale 18h)|
|
||||
| - APAC/Stg: CritR 2 (xz...) | Integrations: DEGRADED (Jenkins)|
|
||||
| [View Findings] | Reachability ingest: WARN (Runtime)|
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Recent Releases / Promotions |
|
||||
| Release Type Status Regions CritR max Evidence |
|
||||
| Hotfix 1.2.4 Single PROMOTING US-East 4 Sealing... |
|
||||
| Platform 1.3.0-rc1 Bundle READY All 0 Ready |
|
||||
|----------------------------------------------------------------------------------|
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 2 — Releases (ledger)
|
||||
|
||||
**Formerly:** `Releases`.
|
||||
**Why changed:** keep the ledger, but make it **digest-first + bundle-aware**, and show **risk + SBOM freshness + reachability coverage** at the list level so operators don’t need to click into each release to see “is it actually safe to promote”.
|
||||
|
||||
### Mermaid — Releases navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
REL["Releases"] -->|select row| RDETAIL["Release Detail"]
|
||||
REL -->|Create Hotfix| NEWREL["New Release (Single Digest)"]
|
||||
REL -->|Create from Bundle| BUN["Bundles"]
|
||||
REL -->|Compare| COMP["Compare Releases (diff)"]
|
||||
REL -. "Export evidence" .-> EA4["Export Center"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Releases
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Releases (formerly: Releases) [Create Hotfix] [Create from Bundle] |
|
||||
| Filters: Region▼ Env Path▼ Type▼ Status▼ Search... |
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Release / Version Type Status Regions Env Path CritR SBOM |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Hotfix 1.2.4 Single PROMOTING US-East Stg→Prod 4 STALE |
|
||||
| Platform Release 1.3.0-rc1 Bundle READY All Stg→Prod 0 OK |
|
||||
| Platform Release 1.2.3 Bundle DEPLOYED All Prod 0 OK |
|
||||
| Feature Branch 2.0.0-a Bundle DRAFT EU-West Dev - - |
|
||||
| Platform Release 1.2.2 Bundle ROLLED_BACK US-East Prod - OK |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Row actions: [View] [Compare] [Evidence] [Rollback] [Promote] |
|
||||
+----------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 3 — Release Detail (case file)
|
||||
|
||||
**Formerly:** scattered between `Releases` (list), `Approvals` (decision context), `Security Findings` (risk details), and `Export/Replay`.
|
||||
**Why changed:** Stella Ops’ center of gravity is a **release decision bound to a digest** (or bundle digest). This screen becomes the “case file”: promotion edge, risk, reachability sources, policy inputs, approvals, deployment, and evidence — in one place.
|
||||
|
||||
### Mermaid — Release Detail navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
RDETAIL["Release Detail"] --> APR["Approvals (filtered to this release)"]
|
||||
RDETAIL --> DEP["Deployments (filtered)"]
|
||||
RDETAIL --> FIND["Findings (filtered)"]
|
||||
RDETAIL --> CAPS["Decision Capsule (for this edge)"]
|
||||
RDETAIL --> BDETAIL["Bundle Detail (if Type=Bundle)"]
|
||||
RDETAIL --> REG["Regions & Environments (focus edge)"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Release Detail
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Release: Hotfix 1.2.4 Type: Single Digest Digest: sha256:abcd... |
|
||||
| Path: US-East Staging → Production Status: PROMOTING |
|
||||
| Summary: CritR 4 | SBOM STALE | Cov 2/3 (Build+Image; Runtime missing) |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Promotion Timeline (edges) | Gate Summary |
|
||||
| Staging → Prod [BLOCKED?] | Policy: PASS |
|
||||
| - Findings: CritR 4 | Data freshness: WARN (SBOM stale) |
|
||||
| - Approvals: 1/2 | Reachability: WARN (Runtime missing) |
|
||||
| - Evidence: Sealing... | Human: PENDING (1 remaining) |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Tabs: [Overview] [Components] [Risk] [Reachability] [Approvals] [Deployments] [Evidence] |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Overview: |
|
||||
| - Requested by: security-team - Change summary: "Critical security patch" |
|
||||
| - Inputs frozen: Policy Pack vX.Y - SBOM scan time: 18h ago (stale threshold 6h)|
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Risk (summary): |
|
||||
| CritR: 4 HighR: 7 MedR: 12 (hybrid reachability) |
|
||||
| Top drivers: openssl CVE-xxxx, libxml2 CVE-yyyy |
|
||||
| [Open Findings (filtered)] |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Evidence: |
|
||||
| Decision Capsule: DSSE ✓ Rekor ✓ Replayable ✓ [View Capsule] [Export] |
|
||||
+----------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 4 — Bundles (Release Bundle Organizer) **NEW**
|
||||
|
||||
**Formerly:** not present; *closest concept* was `Export Center → StellaBundle` but that is an **audit/export artifact**, not an operator workflow for composing deployable multi-service releases.
|
||||
**Why added / why here:** You need a **bundle organizer** to turn “microservice digest + env-derived variables + other microservices + changelog” into a **bundle version** with a **bundle digest**. This stays digest-first (everything pinned by digest), but becomes human-operable for multi-service systems.
|
||||
|
||||
### Bundle concept (explicit)
|
||||
|
||||
A **Bundle** =
|
||||
|
||||
* Components: `service/repo → digest → derived component version`
|
||||
* Config Snapshot per region/env: references to Vault/Consul inputs + hashes (no secret values)
|
||||
* Changelog per repo: commit/PR range between previous bundle and this bundle
|
||||
* Bundle digest: hash of the bundle manifest (components + config snapshot refs + metadata)
|
||||
* Used to create **Releases** (promotions) across environments.
|
||||
|
||||
### Mermaid — Bundles navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
BUN["Bundles"] -->|select bundle| BDETAIL["Bundle Detail / Compose"]
|
||||
BUN -->|Create bundle| BCREATE["Create Bundle (from repos/services)"]
|
||||
BDETAIL -->|Generate Release Candidate| REL["Releases (new release from bundle)"]
|
||||
BDETAIL -->|Compare to previous bundle| BDIFF["Bundle Diff (components+config+changelog)"]
|
||||
BDETAIL -->|Fetch config snapshot| CFG["Config Snapshot (Vault/Consul refs)"]
|
||||
BDETAIL -. "Risk preview" .-> FIND["Findings (bundle-filtered)"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Bundles (Organizer)
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Bundles (NEW) (formerly: N/A; concept overlaps Export Center but different) |
|
||||
| [Create Bundle] Filters: Repo▼ Region▼ Env▼ Status▼ Search... |
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Bundle / Version Status Components Regions Env Baseline CritR SBOM |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Platform Bundle 1.3.0 READY 12 All Stg baseline 0 OK |
|
||||
| Checkout Bundle 2026.02 DRAFT 7 EU-West Dev baseline - - |
|
||||
| Hotfix Set 1.2.4 READY 1 US-East Prod baseline 4 STALE|
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Row actions: [Compose] [Compare] [Create Release] [Export Manifest] |
|
||||
+----------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 5 — Bundle Detail / Compose (Bundle “case file”)
|
||||
|
||||
**Formerly:** not present; composition typically happens in external tooling (CI/CD templates, Helm charts, spreadsheets).
|
||||
**Why changed:** This is the missing “organizer” you called out. It makes bundles **auditable, repeatable, and env-config-aware**, while preserving digest-first identity.
|
||||
|
||||
### Mermaid — Bundle Detail / Compose graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
BDETAIL["Bundle Detail / Compose"] -->|Edit components| COMP["Component Picker (repo/service)"]
|
||||
BDETAIL -->|Pin digest & derive version| MAP["Digest→Version Mapping"]
|
||||
BDETAIL -->|Fetch env config refs| CFG["Config Snapshot (Vault/Consul)"]
|
||||
BDETAIL -->|View changelog| CHG["Changelog (per repo)"]
|
||||
BDETAIL -->|Validate| VAL["Bundle Validation (SBOM, attestation, policy inputs)"]
|
||||
BDETAIL -->|Lock| LOCK["Lock Bundle (freeze manifest)"]
|
||||
BDETAIL -->|Create Release| REL["Create Release from Bundle"]
|
||||
BDETAIL -. "Preview risk" .-> FIND["Findings (bundle-filtered)"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Bundle Detail / Compose
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Bundle: Platform Bundle 1.3.0 Status: DRAFT Bundle Digest: sha256:bund... |
|
||||
| Baseline: Staging Regions: All Last updated: 5m ago |
|
||||
| Actions: [Validate] [Lock Bundle] [Create Release] [Export Manifest] |
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Tabs: [Components] [Config Snapshots] [Changelog] [Risk Preview] [Evidence Inputs]|
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Components (12) |
|
||||
| Service/Repo Digest Derived Ver SBOM CritR Prov |
|
||||
| api-service sha256:aaa... 2.1.0 OK 0 SLSA ✓ |
|
||||
| web-frontend sha256:bbb... 2.0.0 OK 0 SLSA ✓ |
|
||||
| worker sha256:ccc... 3.1.0 STALE 1 SLSA ✓ |
|
||||
| ... |
|
||||
| [Add Component] [Pin Digest] [Import from CI] |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Config Snapshots (refs only — no secret values) |
|
||||
| Region/Env Vault paths (count) Consul prefixes (count) Snapshot Hash |
|
||||
| US-East/Prod 12 6 sha256:cfg1... |
|
||||
| EU-West/Prod 11 6 sha256:cfg2... |
|
||||
| Notes: "Vault unreachable" would show as ERROR and block Lock/Release optionally |
|
||||
| [Fetch Snapshots] [View Ref List] [Diff vs previous bundle] |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Changelog (per repo) |
|
||||
| api-service: v2.0.8 → v2.1.0 (12 PRs) [View] |
|
||||
| web-frontend: v1.9.1 → v2.0.0 (30 PRs) [View] |
|
||||
|----------------------------------------------------------------------------------|
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 6 — Approvals (queue)
|
||||
|
||||
**Formerly:** `Approvals`.
|
||||
**Why changed:** Keep it, but make approvals explicitly tied to **promotion edges** and show the **risk + freshness + reachability** context right in the queue so reviewers don’t approve blind.
|
||||
|
||||
### Mermaid — Approvals navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
APR["Approvals"] -->|open request| ADETAIL["Approval Detail"]
|
||||
APR -->|filter by region/env| APR
|
||||
ADETAIL -->|Approve/Reject| APR
|
||||
ADETAIL -. "Open release case file" .-> RDETAIL["Release Detail"]
|
||||
ADETAIL -. "Open findings" .-> FIND["Findings (filtered)"]
|
||||
ADETAIL -. "Open capsule preview" .-> CAPS["Decision Capsule"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Approvals
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Approvals (formerly: Approvals) Filters: Region▼ Env▼ Status▼ Risk▼ Search... |
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Request Edge Gate Approvals CritR SBOM |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| API Gateway v2.1.0 US-East Stg→Prod PASS 1/2 0 OK |
|
||||
| User Service v3.0.0-rc1 EU-West Stg→Prod BLOCK 0/2 2 OK |
|
||||
| Notes: BLOCK reasons show inline: (Policy fail / CritR / data stale / missing Cov)|
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Actions per row: [Approve] [Reject] [View Detail] |
|
||||
+----------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 7 — Approval Detail (gate breakdown + evidence preview)
|
||||
|
||||
**Formerly:** “View Details” from `Approvals` (implied) + bits from `Findings` and `Export/Replay`.
|
||||
**Why changed:** The approver needs a single page that explains **why** an edge is blocked/passing, with **hybrid reachability** and **data freshness** spelled out, plus a preview of the evidence capsule that will be sealed.
|
||||
|
||||
### Mermaid — Approval Detail graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
ADETAIL["Approval Detail"] -->|Approve| ACT1["Approve action"]
|
||||
ADETAIL -->|Reject| ACT2["Reject action"]
|
||||
ADETAIL --> RDETAIL["Release Detail"]
|
||||
ADETAIL --> FIND["Findings (edge-filtered)"]
|
||||
ADETAIL --> CAPS["Decision Capsule Preview"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Approval Detail
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Approval Detail (formerly: Approvals → View Details) |
|
||||
| Release: User Service v3.0.0-rc1 Edge: EU-West Staging → Production |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Gate Summary: BLOCK |
|
||||
| - Policy: PASS |
|
||||
| - Risk: CritR 2 (Hybrid reachability) |
|
||||
| - SBOM: OK (fresh) |
|
||||
| - Reachability Coverage: 3/3 (Build+Image+Runtime) |
|
||||
| - Data Freshness: OK (Feeds synced 2h ago) |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Risk Drivers (CritR): |
|
||||
| - CVE-XXXX in package foo@1.2.3 Reachable via path: foo->bar->... |
|
||||
| - CVE-YYYY in package baz@4.5.6 Reachable via runtime trace |
|
||||
| [Open Findings (filtered)] |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Evidence Preview: |
|
||||
| Capsule will include: policy inputs, SBOM refs, reachability sources, decision log|
|
||||
| DSSE: pending seal Rekor: pending Replay: enabled |
|
||||
| [View Capsule Draft] [Approve] [Reject] |
|
||||
+----------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 8 — Regions & Environments (promotion graph + env tiles)
|
||||
|
||||
**Formerly:** pipeline widget on `Control Plane` (flat, not region-first).
|
||||
**Why changed:** You explicitly need **Region → Environments** as a first-class topology, and each env must summarize not only “deploy health” but also **SBOM + CritR + Cov**.
|
||||
|
||||
### Mermaid — Regions & Environments graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
REG["Regions & Environments"] -->|select env node| EDETAIL["Environment Detail"]
|
||||
REG -->|select edge| EDGE["Edge Inspector (gates, approvals, evidence)"]
|
||||
REG -. "View findings for env" .-> FIND["Findings (env-filtered)"]
|
||||
REG -. "View deployments for env" .-> DEP["Deployments (env-filtered)"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Regions & Environments
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Regions & Environments (formerly: Control Plane pipeline) Region: US-East▼ |
|
||||
| [Edit Graph] (role-gated) |
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Promotion Graph (US-East) |
|
||||
| Dev [OK|SBOM OK|CritR 0|Cov 3/3] --> Staging [OK|OK|0|3/3] --> Prod [DEG|STALE|4|2/3] |
|
||||
| |
|
||||
| Right Inspector (selected: Prod node) |
|
||||
| - Deploy health: DEGRADED (1 target failing) |
|
||||
| - SBOM: STALE (last scan 18h) |
|
||||
| - CritR: 4 (hybrid) |
|
||||
| - Coverage: Build ✓ Image ✓ Runtime ✗ |
|
||||
| - Feed freshness: NVD stale 18h (WARN/ERROR) |
|
||||
| Actions: [View Findings] [View Deployments] [View Config Snapshot] |
|
||||
+----------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 9 — Environment Detail (region/env “single pane”)
|
||||
|
||||
**Formerly:** no dedicated page; fragments in `Control Plane`, `Platform Health`, `Findings`, and CI/CD/inventory.
|
||||
**Why changed:** Operators need a **per region/env** summary showing *what’s deployed* and *what’s risky* with **SBOM status** and **reachability source coverage** — so it’s clear if risk posture is trustworthy.
|
||||
|
||||
### Mermaid — Environment Detail graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
EDETAIL["Environment Detail"] --> FIND["Findings (env-filtered)"]
|
||||
EDETAIL --> DEP["Deployments (env-filtered)"]
|
||||
EDETAIL --> CFG["Config Snapshot refs (env)"]
|
||||
EDETAIL -. "Nightly issues affecting this env" .-> NIGHT["Nightly Ops Report"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Environment Detail
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Environment Detail US-East / Production (formerly: N/A) |
|
||||
| Deploy: DEGRADED | SBOM: STALE | CritR: 4 | Cov: 2/3 | Feeds: NVD stale 18h |
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Deployed Workloads (by digest) |
|
||||
| Service Image Digest Version SBOM CritR Last Deploy |
|
||||
| api-service sha256:aaa... 2.1.0 OK 0 08:12 |
|
||||
| web-frontend sha256:bbb... 2.0.0 OK 0 08:12 |
|
||||
| worker sha256:ccc... 3.1.0 STALE 1 08:12 |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Critical Reachable Findings (CritR 4) [Open Findings] |
|
||||
| - CVE-XXXX foo@1.2.3 reachable via ... |
|
||||
| - CVE-YYYY bar@4.5.6 reachable via runtime traces (missing today!) |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Config Snapshot (refs only) |
|
||||
| Vault refs: 12 paths | Consul refs: 6 prefixes | Snapshot hash: sha256:cfg1... |
|
||||
| [View refs] [Diff vs last snapshot] |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Related: [Deployments] [Approvals] [Evidence] |
|
||||
+----------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 10 — Deployments (promotion execution view)
|
||||
|
||||
**Formerly:** “Active Deployments” widget + implicit status in Releases list.
|
||||
**Why changed:** Keep the operational view, but tie it to **release/bundle digests** and show **SBOM/risk context** so deployments aren’t treated as purely operational success/failure.
|
||||
|
||||
### Mermaid — Deployments graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
DEP["Deployments"] -->|select run| DDETAIL["Deployment Detail"]
|
||||
DEP -->|filter by release/env| DEP
|
||||
DDETAIL --> RDETAIL["Release Detail"]
|
||||
DDETAIL --> CAPS["Decision Capsule"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Deployments
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Deployments (formerly: Active Deployments widget) |
|
||||
| Filters: Region▼ Env▼ Status▼ Release▼ Search... |
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Release Region/Env Status Targets SBOM CritR Evidence |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Hotfix 1.2.4 US-East/Prod RUNNING 1/1 STALE 4 Sealing... |
|
||||
| Platform 1.2.3 EU-West/Prod COMPLETED 3/3 OK 0 Sealed ✓ |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Actions: [View Detail] |
|
||||
+----------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Screen 11 — Deployment Detail (run + proof)
|
||||
|
||||
**Formerly:** not a dedicated PoC screen (implied behind deployment status).
|
||||
**Why changed:** When something fails, you need traceability: what digest was applied, where, what verification occurred, and what evidence was produced.
|
||||
|
||||
### Mermaid — Deployment Detail graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
DDETAIL["Deployment Detail"] --> CAPS["Decision Capsule (final)"]
|
||||
DDETAIL --> EDETAIL["Environment Detail"]
|
||||
DDETAIL --> RDETAIL["Release Detail"]
|
||||
```
|
||||
|
||||
### ASCII wireframe — Deployment Detail
|
||||
|
||||
```text
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Deployment Detail (formerly: N/A) |
|
||||
| Release: Hotfix 1.2.4 Edge: US-East Staging→Prod Run: dep-0042 |
|
||||
| Status: RUNNING Targets: 1/1 Started: 08:12 Actor: deploy-bot |
|
||||
+----------------------------------------------------------------------------------+
|
||||
| Steps / Timeline |
|
||||
| 1) Resolve artifact digests ✓ |
|
||||
| 2) Fetch config snapshot refs ✓ (vault ok, consul ok) |
|
||||
| 3) Apply to target(s) ✓ |
|
||||
| 4) Post-deploy verification WARN (runtime reachability missing) |
|
||||
| 5) Seal evidence capsule IN PROGRESS |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Deployed Digests |
|
||||
| - api-service sha256:aaa... - worker sha256:ccc... |
|
||||
|----------------------------------------------------------------------------------|
|
||||
| Evidence |
|
||||
| Capsule: DSSE pending | Rekor pending | Replay enabled |
|
||||
| [View Capsule] [Replay/Verify] [Export] |
|
||||
+----------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Release Bundle Organizer — key design notes (so it matches your requirement)
|
||||
|
||||
What you asked for, explicitly, is now represented in **Bundles + Bundle Detail**:
|
||||
|
||||
* **“microservice with digest becomes version X”**
|
||||
|
||||
* Bundle composer maintains a **Digest→Version mapping** per component (derived from git tag/build metadata or manually pinned).
|
||||
* **“variables derived from vaults and consul for this env”**
|
||||
|
||||
* Bundle stores **config snapshot references + hashes** per region/env; values are not shown, but the snapshot is reproducible and auditable.
|
||||
* **“other microservices becomes bundle along with change log. per repository.”**
|
||||
|
||||
* Bundle includes per-repo changelog (diff vs prior bundle baseline).
|
||||
* **“release digest first”**
|
||||
|
||||
* The bundle itself has a **bundle digest** (manifest hash). Promotions can be bound to that digest exactly like a single-image hotfix.
|
||||
|
||||
---
|
||||
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 ..."
|
||||
1309
docs/modules/ui/v2-rewire/pack-03.md
Normal file
1309
docs/modules/ui/v2-rewire/pack-03.md
Normal file
File diff suppressed because it is too large
Load Diff
857
docs/modules/ui/v2-rewire/pack-04.md
Normal file
857
docs/modules/ui/v2-rewire/pack-04.md
Normal file
@@ -0,0 +1,857 @@
|
||||
## Pack 4 — Release Control (root) + Bundle Organizer + Regions/Environments (with SBOM + Reachability surfaced)
|
||||
|
||||
Below is a **complete Mermaid IA graph** for the **Release Control** area (as a **root menu**), plus **screen-by-screen Mermaid navigation graphs** and **ASCII mockups**.
|
||||
Each screen includes: **formerly (where it lived before)** + **why it moved / changed**.
|
||||
|
||||
---
|
||||
|
||||
# 0) Global navigation (updated)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Stella Ops] --> D[Dashboard]
|
||||
A --> RC[Release Control]
|
||||
A --> SEC[Security]
|
||||
A --> EA[Evidence & Audit]
|
||||
A --> OPS[Operations]
|
||||
A --> INT[Integrations]
|
||||
A --> ADM[Administration]
|
||||
```
|
||||
|
||||
**What changed vs PoC:**
|
||||
|
||||
* In the PoC, “Release Control” is under **Settings**. You asked that **Release Control becomes a root menu** because it’s the center of gravity (release/hotfix + security + auditability).
|
||||
* “Dashboard” becomes **release-centric** and **surfaces SBOM findings + reachability + nightly job health** (second-class, not buried).
|
||||
|
||||
---
|
||||
|
||||
# 1) Release Control menu graph (full)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RC[Release Control] --> RC0[Control Plane]
|
||||
RC --> RC1[Regions & Environments]
|
||||
RC --> RC2[Bundles]
|
||||
RC --> RC3[Releases]
|
||||
RC --> RC4[Hotfixes]
|
||||
RC --> RC5[Approvals]
|
||||
RC --> RC6[Deployments]
|
||||
|
||||
RC --> RC7[Configure]
|
||||
RC7 --> RC7a[Targets]
|
||||
RC7 --> RC7b[Agents]
|
||||
RC7 --> RC7c[Workflows]
|
||||
|
||||
RC2 --> RC2a[Bundle Catalog]
|
||||
RC2 --> RC2b[Bundle Organizer]
|
||||
RC2 --> RC2c[Bundle Detail / Versions]
|
||||
|
||||
RC3 --> RC3a[Release List]
|
||||
RC3 --> RC3b[Release Detail]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC-DASH — Dashboard (Release Ops)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Control Plane` (top-level menu) – the pipeline tiles + pending approvals + active deployments.
|
||||
(Screenshot: “Control Plane” page.)
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Dashboard` (root) → “Release Ops Dashboard”
|
||||
|
||||
### Why this change
|
||||
|
||||
* Your requirement: the dashboard must **surface SBOM findings**, specifically:
|
||||
|
||||
* “no issues” vs “X envs with critical reachable”
|
||||
* identify **Env N / Env M** with details
|
||||
* Also must surface **nightly jobs health** (SBOM rescan, CVE source sync, integration connectivity), and **hybrid reachability coverage**.
|
||||
* The PoC dashboard currently shows deployment pipeline but **hides security posture and scan freshness**.
|
||||
|
||||
### Dashboard navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Dash[Dashboard] -->|click Region/Env tile| EnvDetail[Environment Detail]
|
||||
Dash -->|click "Critical Reachable"| Findings[Security Findings]
|
||||
Dash -->|click "Bundle at Risk"| BundleDetail[Bundle Detail]
|
||||
Dash -->|click "Pending Approval"| ApprovalDetail[Approval Detail]
|
||||
Dash -->|click "Nightly Jobs"| Nightly[Operations: Nightly Jobs Report]
|
||||
Dash -->|click "Release"| ReleaseDetail[Release Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ DASHBOARD (Release Ops) Time: Last 24h ▾ Region: All ▾ Env: All ▾ Search: _____ │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ AT-A-GLANCE │
|
||||
│ ┌───────────────┐ ┌───────────────┐ ┌────────────────────┐ ┌──────────────────┐ │
|
||||
│ │ Pending Appr:2 │ │ Deploying: 1 │ │ Critical Reachable │ │ Integrations │ │
|
||||
│ │ (Prod:2) │ │ (Hotfix 1.2.4)│ │ 2 envs (Prod+UAT) │ │ 1 degraded,1 down│ │
|
||||
│ └───────────────┘ └───────────────┘ └────────────────────┘ └──────────────────┘ │
|
||||
│ │
|
||||
│ ENVIRONMENT STATUS (by Region) — includes Runtime + Image SBOM + Reachability Coverage │
|
||||
│ Region tabs: [us-east] [us-west] [eu-central] [ap-south] │
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ ENV Runtime Image SBOM Reachability (Build/Registry/Runtime) Notes │ │
|
||||
│ │ dev OK OK 80% / 70% / 20% coverage gap │ │
|
||||
│ │ staging OK WARN 92% / 85% / 60% 1 med reach. │ │
|
||||
│ │ uat DEGRADED FAIL 95% / 90% / 90% CRIT reachable│ │
|
||||
│ │ prod DEGRADED FAIL 98% / 95% / 95% CRIT reachable│ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ FINDINGS HOTSPOTS (Critical Reachable) NIGHTLY HEALTH (last run) │
|
||||
│ ┌─────────────────────────────────────────────┐ ┌───────────────────────────────────────┐ │
|
||||
│ │ prod/us-east 3 CRIT reachable (Open) > │ │ SBOM Rescan: FAIL (stale 2d) > │ │
|
||||
│ │ uat/eu-central 1 CRIT reachable (Open) > │ │ CVE Feed Sync: DEGRADED (NVD) > │ │
|
||||
│ │ staging/... 0 │ │ Integration Check: OK │ │
|
||||
│ └─────────────────────────────────────────────┘ │ Evidence Sign/Verify: OK │ │
|
||||
│ └───────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ RECENT BUNDLES / RELEASES │
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Bundle v2.1.0 (payments-suite) -> staging | Risk: PASS | Evidence: Complete (Open) │ │
|
||||
│ │ Hotfix 1.2.4 (auth-service) -> prod | Risk: WARN | Evidence: Partial (Open) │ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC0 — Control Plane (Promotion pipeline)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Control Plane` (top-level menu) — environment pipeline + pending approvals + active deployments.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Control Plane`
|
||||
|
||||
### Why this change
|
||||
|
||||
* Control Plane is not a generic dashboard; it’s **release governance execution view**.
|
||||
* Dashboard stays summary; Control Plane becomes “run the shop”: **promotion paths**, **gates**, **rollback/hotfix**, **regionalized env lanes**.
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
CP[RC: Control Plane] --> Env[Regions & Environments]
|
||||
CP --> Rel[Release Detail]
|
||||
CP --> Appr[Approvals]
|
||||
CP --> Dep[Deployments]
|
||||
CP --> Bund[Bundle Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL / CONTROL PLANE Region: us-east ▾ Path: dev→staging→uat→prod ▾ │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ PIPELINE (region lane) │
|
||||
│ dev staging uat prod │
|
||||
│ ┌─────────┐ ┌─────────────────┐ ┌─────────────────┐ ┌──────────────────────────┐ │
|
||||
│ │ 0 rel │ -> │ 2 rel | HEALTHY │ -> │ 0 rel | UNKNOWN │ -> │ 1 rel | DEGRADED │ │
|
||||
│ │ SBOM OK │ │ SBOM WARN (1) │ │ SBOM ? │ │ SBOM FAIL (CRIT reach.) │ │
|
||||
│ └─────────┘ └─────────────────┘ └─────────────────┘ └──────────────────────────┘ │
|
||||
│ │
|
||||
│ PENDING GATES / ACTIONS │
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ [Approval] API Gateway v2.1.0 staging→prod Policy: PASS Reachability: OK (Open)│ │
|
||||
│ │ [Approval] User Service v3.0.0 staging→prod Policy: BLOCK Reachability: CRIT (Open)│ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ ACTIVE DEPLOYMENTS │
|
||||
│ Hotfix 1.2.4 → prod/us-east status: RUNNING agent: prod-agent-01 (View deployment) │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC1 — Regions & Environments
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** partial + fragmented:
|
||||
|
||||
* `Control Plane` (only a flat pipeline, not regional)
|
||||
* `Settings → Release Control → Environments` (config only, no operational SBOM posture view)
|
||||
* `Security` screens for findings (not tied to env operational posture)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Regions & Environments`
|
||||
|
||||
### Why this change
|
||||
|
||||
* You asked for **environments organized per region** (missing today).
|
||||
* Each environment must show **Runtime status + Image/SBOM status + Reachability coverage** — not only “docker status”.
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RE[RC: Regions & Environments] --> ED[Environment Detail]
|
||||
RE --> RCcfg[Release Control: Configure/Targets]
|
||||
RE --> SECFind[Security Findings]
|
||||
RE --> Bund[Bundle Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL / REGIONS & ENVIRONMENTS Search env/bundle: ________ │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Region: us-east │
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Environment Runtime Bundle/Version Image SBOM Critical Reachable Coverage │ │
|
||||
│ │ dev OK platform v1.3.0-rc1 OK 0 B80/R70/RT20 │ │
|
||||
│ │ staging OK api-suite v2.1.0 WARN 0 B92/R85/RT60 │ │
|
||||
│ │ uat DEGRADED api-suite v2.1.0 FAIL 1 B95/R90/RT90 │ │
|
||||
│ │ prod DEGRADED hotfix v1.2.4 FAIL 3 B98/R95/RT95 │ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ Region: eu-central │
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ ... │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ Legend: Coverage = Build/Registry/Runtime │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC1a — Environment Detail
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** not a first/second class page. Operators had to stitch together:
|
||||
|
||||
* runtime health (somewhere else)
|
||||
* findings (`Security → Findings`)
|
||||
* SBOM analytics (`Analytics → SBOM Lake`)
|
||||
* reachability (not visible / scattered)
|
||||
* release context (`Releases`)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Regions & Environments → Environment Detail`
|
||||
|
||||
### Why this change
|
||||
|
||||
* This is where you make go/no-go decisions. It must unify:
|
||||
|
||||
* what is deployed (bundle + digests)
|
||||
* SBOM posture (image + rescan freshness)
|
||||
* reachability coverage (Build/Registry/Runtime)
|
||||
* the actionable list of critical reachable issues
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
ED[Environment Detail] --> Rel[Release Detail]
|
||||
ED --> Bund[Bundle Detail]
|
||||
ED --> Findings[Security Findings (filtered to env)]
|
||||
ED --> Nightly[Ops: Nightly Jobs (filtered)]
|
||||
ED --> Appr[Approvals (filtered to env)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ ENVIRONMENT: prod / us-east Runtime: DEGRADED Current Bundle: hotfix v1.2.4 │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ DEPLOYED ARTIFACTS (digests) SBOM + REACHABILITY │
|
||||
│ ┌─────────────────────────────────────────────┐ ┌───────────────────────────────────────────┐ │
|
||||
│ │ service digest version │ │ Image SBOM: FAIL (3 CRIT reachable) │ │
|
||||
│ │ auth-service sha256:... 1.2.4 │ │ Last SBOM scan: 2h ago | Rescan: nightly │ │
|
||||
│ │ api-gateway sha256:... 2.1.0 │ │ Reachability coverage: Build 98% │ │
|
||||
│ │ worker sha256:... 3.1.0 │ │ Registry 95% │ │
|
||||
│ └─────────────────────────────────────────────┘ │ Runtime 95% │ │
|
||||
│ └───────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ TOP FINDINGS (Critical reachable) │
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ CVE-2026-1234 | pkg:openssl | reachable: YES | path: api-gateway->tls->... | Fix: 1.2.5 │ │
|
||||
│ │ CVE-2026-2222 | pkg:... | reachable: YES | runtime confirmed | mitigation: VEX? │ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ NIGHTLY STATUS (impacting this env) │
|
||||
│ SBOM rescan: OK | CVE feed sync: DEGRADED (NVD) | Integration: Jenkins WARN | Evidence: OK │
|
||||
│ │
|
||||
│ ACTIONS: [Open Approvals] [Request Hotfix] [Force Rescan] [Generate Evidence Bundle] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC2a — Bundle Catalog
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** there is no “bundle catalog”.
|
||||
* The closest analogs:
|
||||
|
||||
* `Releases` list (but it’s a mixed concept: release events + component sets)
|
||||
* ad-hoc “create release” flow (digest-first, per release)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Bundles → Bundle Catalog`
|
||||
|
||||
### Why this change
|
||||
|
||||
* You asked for a **Release Bundle Organizer**: bundles must be **first-class**.
|
||||
* Bundles are the stable unit that carries:
|
||||
|
||||
* **component digests**
|
||||
* **version mapping**
|
||||
* **config materialization (Vault/Consul)**
|
||||
* **per-repo change log**
|
||||
* **security posture + evidence completeness**
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
BC[Bundle Catalog] --> BO[Bundle Organizer (create version)]
|
||||
BC --> BD[Bundle Detail]
|
||||
BC --> RL[Release List (filtered by bundle)]
|
||||
BC --> ED[Environment Detail (where deployed)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL / BUNDLES / CATALOG [Create Bundle] Search: ________ Risk: All ▾ │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundles │
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Bundle Latest Version Repos(services) Risk (CRIT reach) Evidence Deployed│ │
|
||||
│ │ payments-suite v2.1.0 6 (12 svcs) PASS (0) COMPLETE staging │ │
|
||||
│ │ platform-core v1.3.0-rc1 3 (8 svcs) WARN (0) PARTIAL dev │ │
|
||||
│ │ hotfix-auth v1.2.4 1 (1 svc) FAIL (3) COMPLETE prod │ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ Actions per row: (Open) (New Version) (Promote) (Export Evidence) │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC2b — Bundle Organizer (NEW: bundle composition + config materialization + changelog)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** scattered across:
|
||||
|
||||
* `Releases → Create Release` (component selection/digest)
|
||||
* SCM/CI/CD systems for “what changed”
|
||||
* Vault/Consul for runtime config (not captured as release artifact)
|
||||
* Evidence/attestations stored elsewhere (not presented as *bundle version contract*)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Bundles → Bundle Organizer`
|
||||
|
||||
### Why this change
|
||||
|
||||
* Your explicit requirement:
|
||||
|
||||
* microservice digest becomes **version X**
|
||||
* plus **env variables** derived from **Vault + Consul**
|
||||
* plus **other microservices** becomes a **bundle**
|
||||
* plus **change log per repository**
|
||||
* This turns releases into an auditable contract: “**this exact set of digests + this exact config snapshot**”.
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
BO[Bundle Organizer] --> BD[Bundle Detail / Version]
|
||||
BO --> INT[Integrations (SCM/CI/CD/Registry/Vault/Consul)]
|
||||
BO --> SEC[Security preflight (policy + reachability)]
|
||||
BO --> EA[Evidence pack preview]
|
||||
BO --> RL[Create Release from Bundle Version]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ BUNDLE ORGANIZER (Create/Update Bundle Version) Bundle: payments-suite ▾ Version: v2.1.1 │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ STEP BAR: ① Select repos ② Select digests ③ Materialize config ④ Change log ⑤ Validate │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ REPOSITORIES / SERVICES DIGESTS + VERSION MAP CONFIG SNAPSHOT │
|
||||
│ ┌───────────────────────────────┐ ┌───────────────────────────────────┐ ┌───────────────┐ │
|
||||
│ │ repo: api-gateway │ │ svc digest ver │ │ Env: staging │ │
|
||||
│ │ commits: 9 (since v2.1.0) │ │ api-gateway sha256... 2.1.1 │ │ Vault: path… │ │
|
||||
│ │ repo: auth-service │ │ auth-service sha256... 1.2.5 │ │ Consul: kv… │ │
|
||||
│ │ commits: 2 │ │ worker sha256... 3.1.1 │ │ Resolved vars │ │
|
||||
│ │ repo: worker │ │ ... │ │ DB_URL=... │ │
|
||||
│ └───────────────────────────────┘ └───────────────────────────────────┘ │ FEATURE_X=on │ │
|
||||
│ └───────────────┘ │
|
||||
│ │
|
||||
│ CHANGE LOG (per repository) │
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ api-gateway: PR#123 add rate limiting | PR#128 fix header parsing │ │
|
||||
│ │ auth-service: PR#77 fix auth timeout │ │
|
||||
│ │ worker: PR#44 reduce queue retries │ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ PREFLIGHT VALIDATION │
|
||||
│ Policy simulation: PASS | SBOM delta scan: WARN (1 MED) | Reachability: OK | Evidence: Ready │
|
||||
│ ACTIONS: [Save Bundle Version] [Create Release Run] [Export Bundle Manifest] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC2c — Bundle Detail / Versions
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** there was no bundle entity; release detail partially served as “bundle detail”.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Bundles → Bundle Detail`
|
||||
|
||||
### Why this change
|
||||
|
||||
* Bundle Detail becomes the **auditable contract object**:
|
||||
|
||||
* versions timeline
|
||||
* component digests
|
||||
* config snapshots (Vault/Consul refs + resolved values hash)
|
||||
* SBOM posture + reachability + evidence completeness
|
||||
* links to release runs across environments
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
BD[Bundle Detail] --> BV[Bundle Version Detail]
|
||||
BD --> RL[Release Runs using this bundle]
|
||||
BD --> ED[Environments where deployed]
|
||||
BD --> EA[Evidence Bundle Export]
|
||||
BD --> SEC[Security posture drilldown]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ BUNDLE: payments-suite │
|
||||
│ Latest: v2.1.1 Risk: WARN (0 CRIT reachable) Evidence: COMPLETE Deployed: staging, dev │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ VERSIONS │
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ v2.1.1 created Feb 18 | repos changed: 3 | policy: PASS | sbom: WARN | reach cov: 92/85/60│ │
|
||||
│ │ v2.1.0 created Feb 12 | repos changed: 6 | policy: PASS | sbom: OK | reach cov: 90/80/40│ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ THIS VERSION CONTENT (v2.1.1) │
|
||||
│ Components(digests) | Config snapshot refs (Vault/Consul) | Change log per repo | Evidence │
|
||||
│ [Open version detail] [Export manifest] [Generate audit bundle] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC3a — Releases list (Release Runs)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Releases` (top-level menu)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Releases`
|
||||
|
||||
### Why this change
|
||||
|
||||
* Releases should be treated as **promotion runs** of a **bundle version** across envs (and regions).
|
||||
* The PoC release list lacks explicit **bundle/version** framing and doesn’t tie in security posture at list level.
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RL[Release List] --> RD[Release Detail]
|
||||
RL --> BD[Bundle Detail]
|
||||
RL --> ED[Environment Detail]
|
||||
RL --> AP[Approvals]
|
||||
RL --> DP[Deployments]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASES (Promotion Runs) Status: All ▾ Env: All ▾ Region: All ▾ [Create Release] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Release Run Bundle/Version Path Status Risk Evidence │ │
|
||||
│ │ Hotfix 1.2.4 hotfix-auth v1.2.4 staging→prod DEPLOYING FAIL COMPLETE │ │
|
||||
│ │ Platform 1.3.0-rc1 platform-core v1.3.0 dev→staging READY WARN PARTIAL │ │
|
||||
│ │ API Gateway 2.1.0 payments-suite v2.1.0 staging→prod PENDING PASS COMPLETE │ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ Row actions: Open | Approvals | Deployment | Export Evidence │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC3b — Release Detail (promotion, policy, SBOM, reachability, evidence)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** release detail was implicit/limited; approvals had some gating info; security detail was elsewhere.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Releases → Release Detail`
|
||||
|
||||
### Why this change
|
||||
|
||||
* Release Detail must unify:
|
||||
|
||||
* approval gates (policy + human)
|
||||
* SBOM posture (including reachable critical)
|
||||
* hybrid reachability coverage (Build/Registry/Runtime)
|
||||
* evidence chain status (signing/rekor/proof)
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RD[Release Detail] --> APD[Approval Detail]
|
||||
RD --> DP[Deployment Detail]
|
||||
RD --> BD[Bundle Version Detail]
|
||||
RD --> Findings[Security Findings filtered]
|
||||
RD --> EA[Evidence Bundle + Proof Chains]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE RUN: API Gateway 2.1.0 Bundle: payments-suite v2.1.0 staging → production │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ GATES │
|
||||
│ ┌───────────────────────────────┐ ┌───────────────────────────────┐ ┌─────────────────────┐ │
|
||||
│ │ Policy Gates: PASS (2/2) │ │ Human Approvals: 1/2 │ │ Evidence: COMPLETE │ │
|
||||
│ │ Reachability requirement: OK │ │ Pending: sec-lead │ │ DSSE ✓ Rekor ✓ │ │
|
||||
│ └───────────────────────────────┘ └───────────────────────────────┘ └─────────────────────┘ │
|
||||
│ │
|
||||
│ SECURITY POSTURE │
|
||||
│ SBOM: WARN (0 CRIT reachable, 1 MED) | Coverage: Build 92% / Registry 85% / Runtime 60% │
|
||||
│ Top deltas: +pkgX 1.2.3 -pkgY 4.5.6 │
|
||||
│ [Open findings] [Request VEX] [Force rescan] │
|
||||
│ │
|
||||
│ PROMOTION TIMELINE │
|
||||
│ staging: READY → prod: PENDING APPROVAL → (deploy agent: prod-agent-01) │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC4 — Hotfixes
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** hotfixes are just “Releases” with a name “Hotfix …”, not a first-class fast-path.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Hotfixes`
|
||||
|
||||
### Why this change
|
||||
|
||||
* Hot patches are central to Stella Ops: they deserve:
|
||||
|
||||
* dedicated queue
|
||||
* forced visibility on dashboard
|
||||
* explicit “expedite policy” handling (still audited)
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
HX[Hotfixes] --> RD[Release Detail (hotfix mode)]
|
||||
HX --> AP[Approvals]
|
||||
HX --> ED[Environment Detail]
|
||||
HX --> EA[Evidence export]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ HOTFIXES Status: All ▾ Region: All ▾ [Request Hotfix] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Hotfix Target Env Status CRIT Reachable Evidence Requested By │ │
|
||||
│ │ Hotfix 1.2.4 prod/us-east DEPLOYING 3 COMPLETE security-team │ │
|
||||
│ │ Hotfix 1.2.3 prod/eu DEPLOYED 0 COMPLETE deploy-bot │ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC5 — Approvals (release-centric)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Approvals` (top-level menu)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Approvals` (still can be quick-access pinned)
|
||||
|
||||
### Why this change
|
||||
|
||||
* Approvals are a release control primitive; they belong under Release Control.
|
||||
* Also: approvals must show **SBOM+reachability** and not only “policy gates pass/block”.
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
AP[Approvals Queue] --> APD[Approval Detail]
|
||||
AP --> RD[Release Detail]
|
||||
AP --> Findings[Security Findings]
|
||||
AP --> EA[Evidence]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ APPROVALS Status: Pending ▾ Env: prod ▾ Sort: Risk ▾ │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ [1] API Gateway v2.1.0 staging→prod Policy: PASS Reachability: OK SBOM: OK (Open) │
|
||||
│ Evidence: COMPLETE | Requested: alice.johnson | Age: 36d │
|
||||
│ │
|
||||
│ [2] User Service v3.0.0 staging→prod Policy: BLOCK Reachability: CRIT SBOM: FAIL (Open) │
|
||||
│ CRIT reachable: CVE-... | Evidence: PARTIAL | Requested: david.wilson | Age: 36d │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC5a — Approval Detail (decision with full context)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** approval cards + minimal “View Details”.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Approvals → Approval Detail`
|
||||
|
||||
### Why this change
|
||||
|
||||
* Approval must be explainable (audit):
|
||||
|
||||
* “what changed” (bundle changelog per repo)
|
||||
* “what’s the risk” (reachability, criticality)
|
||||
* “what evidence exists” (SBOMs, attestations, policy decision record)
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
APD[Approval Detail] --> BD[Bundle Version Detail]
|
||||
APD --> Findings[Findings (delta+reachable)]
|
||||
APD --> EA[Evidence Packet / Proof Chain]
|
||||
APD --> RD[Release Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ APPROVAL: User Service v3.0.0-rc1 staging → production Risk: HIGH │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ SUMMARY: Policy: BLOCK (2 gates failed) | CRIT reachable: 1 | Evidence: PARTIAL │
|
||||
│ │
|
||||
│ WHAT CHANGED (per repo) │
|
||||
│ - auth-service: PR#77 fix auth timeout │
|
||||
│ - api-gateway: PR#123 rate limiting │
|
||||
│ │
|
||||
│ SECURITY (hybrid reachability) │
|
||||
│ Coverage: Build 95% / Registry 90% / Runtime 90% │
|
||||
│ Blocking item: CVE-2026-XXXX reachable via api-gateway->... │
|
||||
│ │
|
||||
│ EVIDENCE │
|
||||
│ SBOMs: present ✓ | Attestations: missing ✗ | Policy Decision: present ✓ | Rekor: present ✓ │
|
||||
│ │
|
||||
│ DECISION: [Approve] [Reject] [Request VEX] [Request Rescan] [Request Exception] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC6 — Deployments (promotion execution)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** deployment execution signals were split:
|
||||
|
||||
* `Control Plane` active deployments summary
|
||||
* `Operations → Orchestrator / Scheduler` (technical execution)
|
||||
* “Deployment status” not tied cleanly to release run object
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Deployments` (release-run aware), still links to Ops internals
|
||||
|
||||
### Why this change
|
||||
|
||||
* Release operators need a release-centric deployment view:
|
||||
|
||||
* “this release run” → “these targets” → “this agent” → status/logs
|
||||
* Ops remains for deep platform internals; Release Control shows the release execution view.
|
||||
|
||||
### Screen navigation graph
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
DEP[RC: Deployments] --> RD[Release Detail]
|
||||
DEP --> ED[Environment Detail]
|
||||
DEP --> OPS[Operations: Orchestrator/Scheduler (deep)]
|
||||
DEP --> DLQ[Operations: Dead Letter]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ DEPLOYMENTS (Release execution) Time: 24h ▾ Status: Running ▾ │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Release Run Target Agent Status Logs Retry / Rollback │ │
|
||||
│ │ Hotfix 1.2.4 prod/us-east prod-agent-01 RUNNING View (Retry) (Rollback)│ │
|
||||
│ │ API Gateway 2.1.0 prod/eu-central prod-agent-eu QUEUED View (Cancel) │ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# RC7 — Configure (Targets, Agents, Workflows) — moved out of Settings
|
||||
|
||||
## RC7a — Targets
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Settings → Release Control → Targets`
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Configure → Targets`
|
||||
|
||||
### Why this change
|
||||
|
||||
* Targets are not “generic settings”; they’re **release control primitives** tied to region/env topology.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
T[Targets] --> TE[Target Detail]
|
||||
T --> RE[Regions & Environments]
|
||||
T --> AG[Agents]
|
||||
```
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ CONFIGURE / TARGETS [Add Target] Region: us-east ▾ │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Target Name Type Bound Env(s) Status Agent Pool │
|
||||
│ prod-us-east k8s prod/us-east OK prod-agent-01,02 │
|
||||
│ uat-eu k8s uat/eu-central WARN uat-agent-eu │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## RC7b — Agents
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Settings → Release Control → Agents`
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Configure → Agents`
|
||||
|
||||
### Why this change
|
||||
|
||||
* Agents are part of the release execution chain; operators need them in release context.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
AG[Agents] --> AGD[Agent Detail]
|
||||
AG --> DEP[Deployments]
|
||||
AG --> PH[Operations: Platform Health]
|
||||
```
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ CONFIGURE / AGENTS [Register Agent] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Agent Region Last Seen Capability (deploy/scan) Status │
|
||||
│ prod-agent-01 us-east 2m ago deploy+runtime-scan OK │
|
||||
│ uat-agent-eu eu-central 1h ago deploy DEGRADED │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## RC7c — Workflows
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Settings → Release Control → Workflows`
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Release Control → Configure → Workflows`
|
||||
|
||||
### Why this change
|
||||
|
||||
* Workflows define the promotion contract (gates, evidence requirements). It’s core to release control.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
WF[Workflows] --> WFD[Workflow Detail]
|
||||
WF --> PG[Policy Governance]
|
||||
WF --> EA[Evidence requirements]
|
||||
```
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ CONFIGURE / WORKFLOWS [Create Workflow] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Workflow Applies To Gates (policy/human) Evidence Requirements │
|
||||
│ standard-prod prod/* policy+2 approvals SBOM+attest+rekor+decision │
|
||||
│ hotfix-expedite prod/* hotfix policy+1 approval SBOM+decision+rekor │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I’ll send next (if you reply “continue”)
|
||||
|
||||
* **Pack 5:** Integrations + Administration/Settings screens (Identity & Access, Trust & Signing, Policy Governance, Notifications, Usage & Limits, System, Tenant/Branding) — each with Mermaid graphs + ASCII + “formerly/why”.
|
||||
* **Pack 6:** Security + Evidence + Operations screens converted to the same **Mermaid-per-screen + ASCII** format (so everything is consistent end-to-end).
|
||||
515
docs/modules/ui/v2-rewire/pack-05.md
Normal file
515
docs/modules/ui/v2-rewire/pack-05.md
Normal file
@@ -0,0 +1,515 @@
|
||||
## Pack 5 — Integrations + Administration + moved “Policy Governance” + moved “Trust & Signing”
|
||||
|
||||
Below are **(1) Mermaid graphs** for the **menus** and for **each screen**, and **(2) an ASCII mock** per screen, each preceded by: **where it lived before + why it moved**.
|
||||
(Where you see “Formerly: …” that’s intended to be shown on-screen under the title as a small breadcrumb/helper label, per your requirement.)
|
||||
|
||||
---
|
||||
|
||||
# 1) Integrations
|
||||
|
||||
## 1.1 Integrations menu graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
IN_ROOT["Integrations (root menu)"] --> IN_OV["Connections (Overview)"]
|
||||
IN_ROOT --> IN_CATALOG["Catalog / Add Integration"]
|
||||
IN_ROOT --> IN_SEC_DATA["Security Data Sources (CVE/VEX/Advisories)"]
|
||||
IN_ROOT --> IN_SENSORS["Sensors & Reachability Sources (Build/Image/Runtime)"]
|
||||
|
||||
IN_OV --> IN_DETAIL["Integration Detail"]
|
||||
IN_DETAIL --> IN_TEST["Test Connection"]
|
||||
IN_DETAIL --> IN_SYNC["Sync & Health History"]
|
||||
IN_DETAIL --> IN_PERMS["Scopes / Permissions"]
|
||||
IN_DETAIL --> IN_IMPACT["Impact Map: Releases, Bundles, SBOM, Approvals, Evidence"]
|
||||
IN_DETAIL --> IN_ALERTS["Alerts & Routing"]
|
||||
|
||||
IN_CATALOG --> IN_ADD["Add Integration Wizard"]
|
||||
IN_ADD --> IN_DETAIL
|
||||
|
||||
IN_SEC_DATA --> IN_FEEDS["Feeds: NVD / OSV / Vendor / Internal"]
|
||||
IN_FEEDS --> IN_FEED_DETAIL["Feed Detail (sync status, errors, retention)"]
|
||||
|
||||
IN_SENSORS --> IN_BUILD["Build Reachability Source"]
|
||||
IN_SENSORS --> IN_IMAGE["Image/Dover Reachability Source"]
|
||||
IN_SENSORS --> IN_RUNTIME["Runtime Reachability Source"]
|
||||
```
|
||||
|
||||
> Note: **Feed mirroring / airgap bundling** stays under **Operations → Feeds & Airgap** (because that’s “run/operate”), but **Integrations** must show **dependency + impact** (“if NVD down, what breaks?”).
|
||||
|
||||
---
|
||||
|
||||
## 1.2 Screen: Integrations → Connections (Overview)
|
||||
|
||||
**Formerly:** `Settings → Integrations` (`/settings/integrations`)
|
||||
**Why moved:** Integrations are **not “settings”** in StellaOps—they’re **operational dependencies** that directly affect **release decisions**, **SBOM freshness**, **reachability coverage**, **evidence completeness**, and **nightly jobs**. Making this a **root menu** also lets the dashboard link to it as a **first-class dependency view**.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A["Integrations → Connections (Overview)"] --> B["Integration Detail"]
|
||||
A --> C["Add Integration Wizard"]
|
||||
A --> D["Security Data Sources"]
|
||||
A --> E["Sensors & Reachability Sources"]
|
||||
A --> F["Operations → Nightly Ops Report (jobs impacted)"]
|
||||
B --> G["Test Connection"]
|
||||
B --> H["Sync & Health History"]
|
||||
B --> I["Impact Map"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Integrations ▸ Connections [ + Add Integration ]|
|
||||
| Formerly: Settings ▸ Integrations |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Status Summary: Connected 6 Degraded 1 Disconnected 1 Filter: [All|SCM|CI/CD|Reg|...] |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| NAME / TYPE STATUS LAST OK IMPACT (what breaks if degraded) |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| GitHub Enterprise / SCM CONNECTED 5m ago Release Bundles: changelog, repo mapping |
|
||||
| GitLab SaaS / SCM CONNECTED 2m ago Release Bundles: changelog, repo mapping |
|
||||
| Jenkins / CI DEGRADED 1h ago Provenance gaps, build reachability stale |
|
||||
| Harbor / Registry CONNECTED 30m ago Digest resolution, image inventory |
|
||||
| HashiCorp Vault / Secrets CONNECTED 10m ago Bundle variables (env config), approvals |
|
||||
| Slack / Notifications CONNECTED - Alerts routing |
|
||||
| OSV Feed / Feeds CONNECTED 1h ago CVE ingestion (OSV) |
|
||||
| NVD Feed / Feeds DISCONNECTED ? CVE ingestion (NVD) -> SBOM rescan risk |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Attention: NVD Feed DISCONNECTED → CVE freshness degraded → approvals may switch to "Needs Review"|
|
||||
| Deep Links: [View Nightly Ops Report] [Go to Feed Mirror & Airgap Ops] |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1.3 Screen: Integrations → Integration Detail
|
||||
|
||||
**Formerly:** there was no dedicated “detail page” (tiles only under Settings → Integrations).
|
||||
**Why added:** You need a **single pane** that explains **scope + health + impact**. This is also where you show **reachability-source coverage** and **how this integration feeds Release Bundle Organizer**.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["Integration Detail"] --> B["Edit Configuration"]
|
||||
A --> C["Test Connection"]
|
||||
A --> D["Sync Now / Re-auth"]
|
||||
A --> E["Sync & Health History"]
|
||||
A --> F["Permissions/Scopes"]
|
||||
A --> G["Impact Map (Releases/Bundles/SBOM/Evidence)"]
|
||||
A --> H["Alert Routing (who gets paged)"]
|
||||
A --> I["Related: Ops Nightly Report"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Integrations ▸ Connection Detail: NVD Feed [Edit] [Test] |
|
||||
| Formerly: Settings ▸ Integrations (tile) |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Status: DISCONNECTED Last Successful Sync: 2026-02-17 01:12 UTC Owner: Security Ops |
|
||||
| Endpoint: https://... Auth: API Key (expired) |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| HEALTH & HISTORY | IMPACT MAP |
|
||||
|----------------------------------------------|--------------------------------------------------|
|
||||
| Last 24h: 0 OK / 12 Failures | Dashboards: CVE freshness widget = RED |
|
||||
| Error: 401 Unauthorized | Nightly jobs: SBOM rescan may fail / partial |
|
||||
| Retries: exponential backoff | Approvals: policy gates fall back to "manual" |
|
||||
| [View Full History] | Evidence: missing CVE snapshot for attestations |
|
||||
|----------------------------------------------|--------------------------------------------------|
|
||||
| REACHABILITY INPUTS (for findings context) | USED BY RELEASE BUNDLE ORGANIZER |
|
||||
| Build reachability: N/A | - enriches bundle with "CVE snapshot version" |
|
||||
| Image/Dover reachability: N/A | - pins vulnerability dataset used for release |
|
||||
| Runtime reachability: N/A | |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Actions: [Re-authenticate] [Sync Now] [Open Nightly Ops Report filtered to "CVE Feeds"] |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1.4 Screen: Integrations → Add Integration Wizard
|
||||
|
||||
**Formerly:** `Settings → Integrations → Add Integration` button
|
||||
**Why kept here:** still valid, but now it sits under a **root Integrations** area and must force the user to confirm **impact mapping** (what features depend on it) and **which regions/environments it supports**.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A["Add Integration Wizard"] --> B["Choose Type (SCM/CI/Registry/Secrets/Feeds/Notifications/Sensor)"]
|
||||
B --> C["Configure Endpoint & Auth"]
|
||||
C --> D["Select Regions/Envs Scope"]
|
||||
D --> E["Define Impact Map + Owners"]
|
||||
E --> F["Test Connection"]
|
||||
F --> G["Create & Go to Detail"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Integrations ▸ Add Integration (Wizard) Step 3 of 6 |
|
||||
| Formerly: Settings ▸ Integrations ▸ Add Integration |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| 1) Type 2) Auth 3) Scope (Regions/Envs) 4) Impact 5) Test 6) Done
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Scope (where this integration is valid): |
|
||||
| Regions: [x] us-east [x] eu-west [ ] ap-south |
|
||||
| Environments: [x] prod [x] staging [x] dev |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Impact Mapping (required): |
|
||||
| [x] Release Bundles (changelog / metadata) |
|
||||
| [x] SBOM ingestion / CVE sync |
|
||||
| [ ] Approvals routing |
|
||||
| Owner (pager): security-oncall |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| [Back] [Next: Impact Mapping] |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1.5 Screen: Integrations → Security Data Sources
|
||||
|
||||
**Formerly:** `Settings → Security Data` (no screenshot provided, but it exists in nav)
|
||||
**Why moved:** This is **operational security data** (feeds, advisory sources, SBOM parsing rules, reachability dataset versions). It belongs next to **Integrations**, because it’s fundamentally “external dependency + sync + health + impact”.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["Integrations → Security Data Sources"] --> B["Feeds (NVD/OSV/Vendor/Internal)"]
|
||||
A --> C["VEX Sources (vendor statements, internal VEX)"]
|
||||
A --> D["Dataset Versions & Retention"]
|
||||
B --> E["Feed Detail"]
|
||||
E --> F["Sync History"]
|
||||
E --> G["Errors & Remediation"]
|
||||
E --> H["Used By: Approvals / Evidence snapshots"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Integrations ▸ Security Data Sources |
|
||||
| Formerly: Settings ▸ Security Data |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| DATASETS USED FOR RELEASE DECISIONS (must be auditable) |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Source Type Status Last Sync Dataset Version Used by |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| NVD CVE Feed DISCONNECTED - - Approvals, Evidence, SBOM |
|
||||
| OSV CVE Feed CONNECTED 1h 2026.02.18.01 Approvals, Evidence, SBOM |
|
||||
| Vendor VEX VEX CONNECTED 24h 2026.02.17 VEX Hub, Findings |
|
||||
| Internal VEX VEX CONNECTED 5m live VEX Hub, Exceptions |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Controls: [Retention policy] [Dataset snapshot rules] [Export dataset attestation] |
|
||||
| Cross-links: [Operations ▸ Feed Mirrors] [Operations ▸ Nightly Jobs] |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 2) Administration
|
||||
|
||||
## 2.1 Administration menu graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
ADM_ROOT["Administration (root menu)"] --> ADM_IAM["Identity & Access"]
|
||||
ADM_ROOT --> ADM_TENANT["Tenant & Branding"]
|
||||
ADM_ROOT --> ADM_NOTIF["Notifications"]
|
||||
ADM_ROOT --> ADM_USAGE["Usage & Limits"]
|
||||
ADM_ROOT --> ADM_SYSTEM["System (Admin-only)"]
|
||||
|
||||
ADM_IAM --> ADM_USERS["Users"]
|
||||
ADM_IAM --> ADM_ROLES["Roles"]
|
||||
ADM_IAM --> ADM_OAUTH["OAuth Clients"]
|
||||
ADM_IAM --> ADM_TOKENS["API Tokens"]
|
||||
ADM_IAM --> ADM_TENANTS["Tenants"]
|
||||
|
||||
ADM_NOTIF --> ADM_RULES["Rules"]
|
||||
ADM_NOTIF --> ADM_CHANNELS["Channels"]
|
||||
ADM_NOTIF --> ADM_TEMPLATES["Templates"]
|
||||
ADM_NOTIF --> ADM_LOG["Delivery Log"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2.2 Screen: Administration → Identity & Access
|
||||
|
||||
**Formerly:** `Settings → Identity & Access` (`/settings/admin`)
|
||||
**Why moved:** This is pure **admin control plane** (users/roles/tokens/tenants). Keeping it out of the release/security nav reduces clutter and avoids “settings dumping ground”.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A["Administration → Identity & Access"] --> B["Users"]
|
||||
A --> C["Roles"]
|
||||
A --> D["OAuth Clients"]
|
||||
A --> E["API Tokens"]
|
||||
A --> F["Tenants"]
|
||||
A --> G["Audit Log (Evidence & Audit)"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Administration ▸ Identity & Access |
|
||||
| Formerly: Settings ▸ Identity & Access |
|
||||
| Tabs: [Users] [Roles] [OAuth Clients] [API Tokens] [Tenants] |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Users [ + Add User]|
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Name Email Role Status Actions |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| alice.johnson alice@company.com Release Admin Active [Edit] [Disable] |
|
||||
| david.wilson david@company.com Approver Active [Edit] [Disable] |
|
||||
| ... |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Note: Role "Approver" can approve releases but cannot edit policy baselines. |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2.3 Screen: Administration → Tenant & Branding
|
||||
|
||||
**Formerly:** `Settings → Tenant / Branding` (no screenshot provided)
|
||||
**Why moved:** Tenant-level admin belongs together with Identity, Usage, Notifications.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["Administration → Tenant & Branding"] --> B["Tenant Profile"]
|
||||
A --> C["Branding (logo/colors)"]
|
||||
A --> D["Regions enabled (global config)"]
|
||||
A --> E["Data retention defaults"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Administration ▸ Tenant & Branding |
|
||||
| Formerly: Settings ▸ Tenant / Branding |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Tenant Profile | Branding |
|
||||
|----------------------------------------|----------------------------------------------------------|
|
||||
| Name: ExampleCorp | Logo: [Upload] |
|
||||
| Default Region: eu-west | Theme: Light / Dark |
|
||||
| Enabled Regions: [x] us-east [x] eu-west [ ] ap-south |
|
||||
| Retention: Evidence 365d, Logs 30d | Product Name: "Stella Ops" / "ExampleOps" |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| [Save Changes] |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2.4 Screen: Administration → Notifications
|
||||
|
||||
**Formerly:** `Settings → Notifications` (`/settings/notifications`)
|
||||
**Why moved:** Notification rules are **tenant-admin policy**. Channels still depend on integrations (Slack/Webhook/Email), so this screen should “consume” those and link back.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A["Administration → Notifications"] --> B["Notification Rules"]
|
||||
A --> C["Channels"]
|
||||
A --> D["Templates"]
|
||||
A --> E["Delivery Log"]
|
||||
C --> F["Integrations → Slack/Webhook detail"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Administration ▸ Notifications |
|
||||
| Formerly: Settings ▸ Notifications |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| [Notification Rules] [Channels] [Templates] |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Rules | Channels | Templates |
|
||||
|------------------------------|--------------------------------------------|---------------------|
|
||||
| + Add Rule | Email ACTIVE | Edit Templates |
|
||||
| | Slack ACTIVE (via Integrations) | |
|
||||
| | Webhook NOT CONFIGURED | |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Activity / Delivery Log |
|
||||
| [View Log] (filter: release approvals, critical findings, feed failures, nightly job failures) |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2.5 Screen: Administration → Usage & Limits
|
||||
|
||||
**Formerly:**
|
||||
|
||||
* `Settings → Usage & Limits` (`/settings/usage`)
|
||||
* **and** `Operations → Quotas` (overlapping/duplicated concepts)
|
||||
**Why moved & changed:** unify into one **tenant-level** view: **consumption + quota config + throttles**. Operations can still show “operator quota dashboard”, but **admin owns quotas/limits**.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["Administration → Usage & Limits"] --> B["Usage Summary"]
|
||||
A --> C["Quota Configuration"]
|
||||
A --> D["Throttle Events (read-only)"]
|
||||
D --> E["Operations → Quota / Throttle report (detail)"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Administration ▸ Usage & Limits |
|
||||
| Formerly: Settings ▸ Usage & Limits + Operations ▸ Quotas |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Scans Storage Evidence Packets API Requests |
|
||||
| 6,500/10,000 42GB/100GB 2,800/10,000 15,000/100,000 |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Quota Configuration |
|
||||
| Configure limits and throttle settings for your tenant. |
|
||||
| [Configure Quotas] |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| Throttle Events (last 24h): none → [View in Operations ▸ Quotas] |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2.6 Screen: Administration → System
|
||||
|
||||
**Formerly:** `Settings → System` (`/settings/system`)
|
||||
**Why moved:** This is strictly **admin-only platform control**. Also, it must link to operational diagnostics (**Ops → Platform Health**, **Ops → Nightly Jobs**, **Ops → Dead Letter**).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["Administration → System"] --> B["Health Check (components)"]
|
||||
A --> C["Doctor (diagnostics)"]
|
||||
A --> D["SLO Monitoring"]
|
||||
A --> E["Background Jobs (admin view)"]
|
||||
E --> F["Operations → Scheduler / Nightly Jobs"]
|
||||
B --> G["Operations → Platform Health"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Administration ▸ System (Admin only) |
|
||||
| Formerly: Settings ▸ System |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| [Health Check] [Doctor] [SLO Monitoring] |
|
||||
| All systems operational Run diagnostics View & configure SLOs |
|
||||
| [View Details] [Run Doctor] [View SLOs] |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| [Background Jobs] |
|
||||
| Monitor and manage background job processing. |
|
||||
| [View Jobs] → deep link: Operations ▸ Scheduler / Nightly Ops Report |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 3) Moved into Release Control: “Policy Governance”
|
||||
|
||||
## 3.1 Screen: Release Control → Governance & Policy
|
||||
|
||||
**Formerly:** `Settings → Policy Governance` (`/settings/policy`)
|
||||
**Why moved:** These rules/baselines **define release gates** and belong with **Release Control** (environments, targets, workflows). This is a *core* function, not a generic setting.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["Release Control → Governance & Policy"] --> B["Policy Baselines (per env/region)"]
|
||||
A --> C["Governance Rules (org-wide)"]
|
||||
A --> D["Policy Simulation"]
|
||||
A --> E["Exception Workflow"]
|
||||
E --> F["Security → Exceptions (requests & approvals)"]
|
||||
C --> G["Approvals / Policy Gates (uses these rules)"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Release Control ▸ Governance & Policy |
|
||||
| Formerly: Settings ▸ Policy Governance |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| [Policy Baselines] [Governance Rules] [Policy Simulation] |
|
||||
| Create / manage baselines Define org rules for releases Test changes before applying |
|
||||
| [ + Create Baseline ] [Edit Rules] [Run Simulation] |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| [Exception Workflow] |
|
||||
| Configure how policy exceptions are requested & approved. |
|
||||
| [Configure Workflow] → deep link: Security ▸ Exceptions |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 4) Moved into Evidence & Audit: “Trust & Signing”
|
||||
|
||||
## 4.1 Screen: Evidence & Audit → Trust & Signing
|
||||
|
||||
**Formerly:** `Settings → Trust & Signing` (`/settings/trust`)
|
||||
**Why moved:** Trust & signing is the **spine of auditing** (DSSE envelopes, Rekor/transparency logs, signing keys, audit log). It should sit with **Evidence Bundles / Proof Chains / Replay/Verify**.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A["Evidence & Audit → Trust & Signing"] --> B["Signing Keys"]
|
||||
A --> C["Issuers"]
|
||||
A --> D["Certificates"]
|
||||
A --> E["Transparency Log (Rekor config)"]
|
||||
A --> F["Trust Scoring"]
|
||||
A --> G["Trust Audit Log"]
|
||||
A --> H["Evidence Bundles"]
|
||||
A --> I["Proof Chains"]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Evidence & Audit ▸ Trust & Signing |
|
||||
| Formerly: Settings ▸ Trust & Signing |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| [Signing Keys] [Issuers] [Certificates] |
|
||||
| Manage keys for Trusted issuers TLS/signing certs |
|
||||
| evidence & attests for VEX/attests upload/manage |
|
||||
| [Manage Keys] [Manage Issuers] [Manage Certificates] |
|
||||
|--------------------------------------------------------------------------------------------------|
|
||||
| [Transparency Log] [Trust Scoring] [Audit Log] |
|
||||
| Configure Rekor logs Scoring policy for artifacts Trust-related audit events |
|
||||
| [Configure Rekor] [Edit Score Config] [View Audit Log] |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What’s next (Pack 6 suggestion)
|
||||
|
||||
If you want me to continue immediately, Pack 6 should cover: **Operations** (Scheduler, Dead Letter, Platform Health, Orchestrator, Feeds & Airgap), and ensure each has:
|
||||
|
||||
* Mermaid menu graph
|
||||
* Mermaid per-screen graph
|
||||
* ASCII mock with “Formerly …” label
|
||||
* Explicit surfacing of: **nightly SBOM rescans**, **CVE feed sync health**, **integration failures**, and **hybrid reachability freshness**.
|
||||
761
docs/modules/ui/v2-rewire/pack-06.md
Normal file
761
docs/modules/ui/v2-rewire/pack-06.md
Normal file
@@ -0,0 +1,761 @@
|
||||
## Pack 6 — Operations (keep IA intact; add Nightly + make Ops screens “2nd-class” not buried)
|
||||
|
||||
This pack stays consistent with the **root menus already agreed**:
|
||||
|
||||
* **Dashboard**
|
||||
* **Release Control**
|
||||
* **Security**
|
||||
* **Evidence & Audit**
|
||||
* **Operations**
|
||||
* **Integrations**
|
||||
* **Administration**
|
||||
|
||||
Operations here is strictly: **platform + pipelines + feeds + background jobs + execution diagnostics** that *support* release/hotfix/audit, but do not replace them.
|
||||
|
||||
---
|
||||
|
||||
# 1) Operations menu graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
OPS[Operations] --> OPS0[Operations Overview]
|
||||
OPS --> OPS1[Nightly Ops Report]
|
||||
OPS --> OPS2[Scheduler]
|
||||
OPS --> OPS3[Orchestrator]
|
||||
OPS --> OPS4[Platform Health]
|
||||
OPS --> OPS5[Dead Letter Queue]
|
||||
OPS --> OPS6[Feeds & Airgap]
|
||||
OPS --> OPS7[Quotas & Throttling]
|
||||
|
||||
OPS2 --> OPS2a[Runs]
|
||||
OPS2 --> OPS2b[Schedules]
|
||||
OPS2 --> OPS2c[Worker Fleet]
|
||||
|
||||
OPS3 --> OPS3a[Jobs]
|
||||
OPS3 --> OPS3b[Backfill]
|
||||
OPS3 --> OPS3c[Access & Permissions]
|
||||
|
||||
OPS6 --> OPS6a[Feed Mirrors]
|
||||
OPS6 --> OPS6b[Airgap Bundles]
|
||||
OPS6 --> OPS6c[Version Locks]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 2) Operations Overview
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** no dedicated overview; operators bounced between `Platform Health`, `Scheduler`, `Feeds`, `Dead Letter`, etc.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Operations → Operations Overview`
|
||||
|
||||
### Why changed
|
||||
|
||||
* You need a single ops landing that answers:
|
||||
**“Is the platform able to produce trustworthy release decisions right now?”**
|
||||
That means: feeds synced, SBOM scans healthy, reachability ingest healthy, scheduler ok, DLQ clean.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Operations Overview] --> B[Nightly Ops Report]
|
||||
A --> C[Platform Health]
|
||||
A --> D[Feeds & Airgap]
|
||||
A --> E[Scheduler Runs]
|
||||
A --> F[Dead Letter Queue]
|
||||
A --> G[Integrations Overview]
|
||||
A --> H[Dashboard (impact view)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS OVERVIEW Time: 24h ▾ │
|
||||
│ Formerly: (new) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ RELEASE-DECISION READINESS │
|
||||
│ ┌───────────────────────┐ ┌───────────────────────┐ ┌────────────────────────┐ ┌─────────────┐ │
|
||||
│ │ CVE Data Freshness │ │ SBOM Rescan Health │ │ Reachability Ingest │ │ Evidence Pipe│ │
|
||||
│ │ OSV: OK NVD: DOWN │ │ OK (last: 02:00) │ │ Build OK / Image OK │ │ OK (DSSE/Log)│ │
|
||||
│ └───────────────────────┘ └───────────────────────┘ │ Runtime DEGRADED │ └─────────────┘ │
|
||||
│ └────────────────────────┘ │
|
||||
│ │
|
||||
│ EXECUTION HEALTH │
|
||||
│ ┌────────────────────────────┐ ┌───────────────────────────┐ ┌───────────────────────────┐ │
|
||||
│ │ Scheduler: DEGRADED │ │ Dead Letter: 0 retryable │ │ Feeds Mirror: NO DATA │ │
|
||||
│ │ Runs load failed (API) │ │ Errors last 7d: none │ │ Status unknown │ │
|
||||
│ │ [Open Runs] │ │ [Open DLQ] │ │ [Open Feeds] │ │
|
||||
│ └────────────────────────────┘ └───────────────────────────┘ └───────────────────────────┘ │
|
||||
│ │
|
||||
│ TOP IMPACT (what’s blocked) │
|
||||
│ - Approvals may switch to manual review due to NVD down │
|
||||
│ - Prod runtime reachability ingest degraded → “reachable” confidence reduced │
|
||||
│ [Open Dashboard impact panel] [Open Nightly Ops Report] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 3) Nightly Ops Report (critical missing piece you asked for)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** partially implied by `Scheduler Runs` and scattered integration tiles; not consolidated.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Nightly Ops Report`
|
||||
|
||||
### Why changed
|
||||
|
||||
* You explicitly require reporting when:
|
||||
|
||||
* **SBOM re-scan nightly** fails/stales
|
||||
* **CVE sources not synced**
|
||||
* **integrations not connectable**
|
||||
* **reachability ingest** (Build / Image/Dover / Runtime) is degraded
|
||||
* This is not a “first-class product feature page,” but it must be **second-class** and linked from Dashboard + Approvals.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Nightly Ops Report] --> B[Job Run Detail]
|
||||
A --> C[Scheduler Runs (filtered)]
|
||||
A --> D[Integrations (impacted)]
|
||||
A --> E[Feeds & Airgap (if feed-related)]
|
||||
A --> F[Dashboard (impact)]
|
||||
A --> G[Security Findings (if rescan anomalies)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ NIGHTLY OPS REPORT Date: Today ▾ │
|
||||
│ Formerly: (new; scattered across Scheduler/Integrations/Feeds) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ PIPELINES (nightly) │
|
||||
│ ┌─────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Job Status Last Run Freshness SLA Impact │ │
|
||||
│ │ SBOM Rescan (images) OK 02:00 < 24h Approvals trustworthy │ │
|
||||
│ │ CVE Feed Sync (OSV) OK 01:10 < 6h Findings accurate │ │
|
||||
│ │ CVE Feed Sync (NVD) FAIL - < 6h Approvals may go manual │ │
|
||||
│ │ Reachability Ingest (Build) OK 02:05 < 24h build reach coverage OK │ │
|
||||
│ │ Reachability Ingest (Image) OK 02:07 < 24h image reach coverage OK │ │
|
||||
│ │ Reachability Ingest (Runtime)DEGRADED 02:15 < 24h runtime reach confidence ↓ │ │
|
||||
│ │ Integration Health Check WARN 02:20 < 24h Jenkins degraded │ │
|
||||
│ └─────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ FAILURES / REMEDIATION │
|
||||
│ - NVD Feed: 401/timeout → [Open Integration Detail] [Open Feed Mirrors] │
|
||||
│ - Runtime reachability ingest: agent missing in eu-central → [Worker Fleet] │
|
||||
│ │
|
||||
│ EXPORT: [Download nightly report JSON/CSV] (for audit/compliance evidence) │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 4) Scheduler (Runs / Schedules / Worker Fleet)
|
||||
|
||||
## 4.1 Scheduler menu screen (entry)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Operations → Scheduler` (you had “Scheduler Runs” page directly)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Scheduler` is an entry page with tabs/links to Runs/Schedules/Worker Fleet.
|
||||
|
||||
### Why changed
|
||||
|
||||
* Preserve current functionality but reduce “dead end” screens. Also gives operators quick pivot to **Worker Fleet**, which you already expose as a button.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Operations → Scheduler] --> B[Runs]
|
||||
A --> C[Schedules]
|
||||
A --> D[Worker Fleet]
|
||||
B --> E[Nightly Ops Report]
|
||||
B --> F[Job Run Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ SCHEDULER │
|
||||
│ Formerly: Operations ▸ Scheduler (Runs) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Runs] [Schedules] [Worker Fleet] │
|
||||
│ Quick actions: [Retry Connection] [Open Nightly Ops Report] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4.2 Scheduler → Runs
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Operations → Scheduler` page (“Scheduler Runs”)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Scheduler → Runs`
|
||||
|
||||
### Why changed
|
||||
|
||||
* Same screen, but:
|
||||
|
||||
* must link to **nightly pipelines** (SBOM rescan, CVE sync, reachability ingest)
|
||||
* must indicate when Runs page is failing (API) and suggest “what breaks”
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Scheduler Runs] --> B[Run Detail]
|
||||
A --> C[Schedules]
|
||||
A --> D[Worker Fleet]
|
||||
A --> E[Nightly Ops Report]
|
||||
A --> F[Integrations (if failures due to dependency)]
|
||||
```
|
||||
|
||||
### ASCII mock (based on your screenshot)
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ SCHEDULER ▸ RUNS [Manage Schedules]│
|
||||
│ Formerly: Operations ▸ Scheduler Runs │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ⚠ Failed to load scheduler runs [Retry Connection] │
|
||||
│ Impact if persists: Nightly SBOM rescans may be stale; approvals confidence reduced │
|
||||
│ │
|
||||
│ Filters: Status ▾ Time Range: Last 24h ▾ │
|
||||
│ Metrics: Total 0 | Completed 0 | Running 0 | Failed 0 │
|
||||
│ │
|
||||
│ Runs table (when available): job name | status | start | end | region/env | error | link │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4.3 Scheduler → Schedules (NEW screen)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** button “Manage Schedules” existed, but not represented in navigation structure.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Scheduler → Schedules`
|
||||
|
||||
### Why changed
|
||||
|
||||
* Schedules are how you guarantee: **nightly SBOM rescans**, **CVE sync**, **reachability ingest**. Must be visible.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Scheduler Schedules] --> B[Schedule Detail]
|
||||
A --> C[Runs (filtered)]
|
||||
A --> D[Nightly Ops Report]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ SCHEDULER ▸ SCHEDULES [New Schedule] │
|
||||
│ Formerly: Operations ▸ Scheduler (Manage Schedules button) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Nightly Critical Pipelines │
|
||||
│ - SBOM Rescan (images): 02:00 daily Regions: all Envs: prod/staging SLA: <24h │
|
||||
│ - CVE Sync OSV: hourly SLA: <6h │
|
||||
│ - CVE Sync NVD: hourly SLA: <6h │
|
||||
│ - Reachability Ingest: 02:05 daily Sources: build/image/runtime │
|
||||
│ - Integration Health Check 02:20 daily │
|
||||
│ Actions: [Edit] [Disable] [Run Now] [View Runs] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4.4 Scheduler → Worker Fleet (NEW screen)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** “Worker Fleet” button existed on Scheduler Runs.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Scheduler → Worker Fleet`
|
||||
|
||||
### Why changed
|
||||
|
||||
* Worker issues directly cause: **reachability ingest gaps**, **scan gaps**, **sync gaps**. Operators need a first hop.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Worker Fleet] --> B[Worker Detail]
|
||||
A --> C[Scheduler Runs]
|
||||
A --> D[Platform Health]
|
||||
A --> E[Regions & Environments (Release Control)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ SCHEDULER ▸ WORKER FLEET │
|
||||
│ Formerly: Operations ▸ Scheduler (Worker Fleet button) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Worker Region Capabilities Last Seen Status Notes │
|
||||
│ worker-us-01 us-east sbom-scan + ingest 1m OK - │
|
||||
│ worker-eu-02 eu-central runtime reach ingest 3h DEGRADED runtime coverage ↓ │
|
||||
│ worker-ap-01 ap-south feed mirror 2m OK - │
|
||||
│ │
|
||||
│ Actions: [Open Worker] [Drain] [Restart] (admin permissions required) │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 5) Orchestrator
|
||||
|
||||
## 5.1 Orchestrator Dashboard
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Operations → Orchestrator` (“Orchestrator Dashboard”)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Orchestrator → Dashboard`
|
||||
|
||||
### Why changed
|
||||
|
||||
* Preserve, but add:
|
||||
|
||||
* “what you can do” (access rights) stays
|
||||
* link to **Jobs**, **Backfill**, **DLQ**, **Scheduler**
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Orchestrator Dashboard] --> B[Jobs]
|
||||
A --> C[Backfill]
|
||||
A --> D[Dead Letter Queue]
|
||||
A --> E[Scheduler Runs]
|
||||
A --> F[Administration → Identity & Access (role request)]
|
||||
```
|
||||
|
||||
### ASCII mock (based on your screenshot)
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ ORCHESTRATOR ▸ DASHBOARD │
|
||||
│ Formerly: Operations ▸ Orchestrator │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Jobs (View job status and history) [Open Jobs] │
|
||||
│ │
|
||||
│ Your Orchestrator Access │
|
||||
│ - View Jobs: Granted │
|
||||
│ - Operate: Denied │
|
||||
│ - Manage Quotas: Denied │
|
||||
│ - Initiate Backfill: Denied │
|
||||
│ │
|
||||
│ Links: [Dead Letter Queue] [Scheduler Runs] [Request Role] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5.2 Orchestrator → Jobs (NEW explicit page)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** hidden behind “Jobs” card.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Orchestrator → Jobs`
|
||||
|
||||
### Why changed
|
||||
|
||||
* Jobs are where you diagnose “why isn’t SBOM data updating” or “why is evidence bundle not generating”.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Orchestrator Jobs] --> B[Job Detail]
|
||||
A --> C[Dead Letter Queue (filtered by job)]
|
||||
A --> D[Scheduler Runs (job schedule)]
|
||||
A --> E[Nightly Ops Report]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ ORCHESTRATOR ▸ JOBS │
|
||||
│ Formerly: Operations ▸ Orchestrator (Jobs card) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Job Name Category Last Run Status Failures(7d) Links │
|
||||
│ SBOM Rescan Images security 02:00 OK 0 [Runs] [DLQ] │
|
||||
│ CVE Sync NVD security - FAIL 12 [Runs] [Int] │
|
||||
│ Evidence Bundle Export evidence 03:00 OK 0 [Runs] [DLQ] │
|
||||
│ Reachability Ingest Runtime security 02:15 DEGRADED 3 [Runs] [Fleet] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5.3 Orchestrator → Backfill (NEW explicit page)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** implied by “Initiate Backfill” permission but no UX.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Orchestrator → Backfill`
|
||||
|
||||
### Why changed
|
||||
|
||||
* Operators often need to backfill after restoring a feed, adding a registry integration, or enabling a region.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Backfill] --> B[Backfill Run Detail]
|
||||
A --> C[Scheduler Runs]
|
||||
A --> D[Nightly Ops Report]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ ORCHESTRATOR ▸ BACKFILL │
|
||||
│ Formerly: (implicit; access permission only) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Backfill type: [SBOM] [CVE Dataset] [Reachability] [Evidence Index] │
|
||||
│ Scope: Region ▾ Environment ▾ Time range ▾ │
|
||||
│ [Start Backfill] (requires permission) │
|
||||
│ │
|
||||
│ Recent Backfills: none │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 6) Platform Health
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Operations → Platform Health` (your screenshot shows this)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Platform Health`
|
||||
|
||||
### Why changed
|
||||
|
||||
* Keep it under operations, but make it **release-decision aware**:
|
||||
|
||||
* show dependencies (feeds, integrations, signing log)
|
||||
* show “what feature is impacted” if a dependency is unhealthy
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Platform Health] --> B[Service Health Detail]
|
||||
A --> C[Dependencies Detail]
|
||||
A --> D[Operations Overview]
|
||||
A --> E[Integrations (dependency)]
|
||||
A --> F[Dashboard (impact)]
|
||||
```
|
||||
|
||||
### ASCII mock (based on your screenshot)
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ PLATFORM HEALTH Auto-refresh: 10s│
|
||||
│ Formerly: Operations ▸ Platform Health │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ⚠ Unable to load platform health data. Try refreshing. │
|
||||
│ Impact: release gating, SBOM ingestion, evidence export may be degraded │
|
||||
│ │
|
||||
│ Service Health (group by state) Dependencies │
|
||||
│ ┌─────────────────────────────────────────────┐ ┌───────────────────────────────────────┐ │
|
||||
│ │ HEALTHY: ... DEGRADED: ... DOWN: ... │ │ Feeds: NVD down, OSV ok │ │
|
||||
│ │ [View service list] │ │ SCM: ok CI: warn Registry: ok │ │
|
||||
│ └─────────────────────────────────────────────┘ └───────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ Incident Timeline (last 24h): none │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 7) Dead Letter Queue
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Operations → Dead Letter` (your screenshot)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Dead Letter Queue`
|
||||
|
||||
### Why changed
|
||||
|
||||
* Keep, but ensure DLQ clearly states:
|
||||
|
||||
* which pipeline failed (SBOM rescan, CVE sync, evidence export, reach ingest)
|
||||
* quick actions: replay job, open job detail, open integration/feeds
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Dead Letter Queue] --> B[DLQ Entry Detail]
|
||||
A --> C[Replay (job retry)]
|
||||
A --> D[Orchestrator Jobs (filtered)]
|
||||
A --> E[Scheduler Runs (filtered)]
|
||||
A --> F[Integrations Detail]
|
||||
A --> G[Feeds & Airgap]
|
||||
```
|
||||
|
||||
### ASCII mock (based on your screenshot)
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ DEAD LETTER QUEUE MANAGEMENT [Export CSV] [Refresh]│
|
||||
│ Formerly: Operations ▸ Dead Letter │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Error Distribution (last 7 days): No data │
|
||||
│ By Tenant: No data │
|
||||
│ │
|
||||
│ Queue Browser │
|
||||
│ Error Type ▾ Status ▾ Search (job id / entry id) ____ [Clear] │
|
||||
│ │
|
||||
│ No dead-letter entries match your filters │
|
||||
│ (When entries exist: show Job, Pipeline, Region/Env, Error, Retryable?, Link to Integration) │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 8) Feeds & Airgap (Feed Mirrors / Airgap Bundles / Version Locks)
|
||||
|
||||
## 8.1 Feeds & Airgap entry
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Operations → Feeds` (“Feed Mirror & AirGap Operations”)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Feeds & Airgap` (same content, clearer name)
|
||||
|
||||
### Why changed
|
||||
|
||||
* This is operational infrastructure for offline/airgap + mirroring. It remains under operations, but must link to Integrations + Security Data Sources for impact.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Feeds & Airgap] --> B[Feed Mirrors]
|
||||
A --> C[Airgap Bundles]
|
||||
A --> D[Version Locks]
|
||||
A --> E[Integrations → Security Data Sources]
|
||||
A --> F[Nightly Ops Report]
|
||||
```
|
||||
|
||||
### ASCII mock (based on your screenshot)
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ FEEDS & AIRGAP OPERATIONS [Refresh] │
|
||||
│ Formerly: Operations ▸ Feeds (Feed Mirror & AirGap Operations) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Feed Mirrors] [Airgap Bundles] [Version Locks] │
|
||||
│ Status: No sync data | Status unknown │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8.2 Feed Mirrors tab
|
||||
|
||||
**Formerly:** same page under `Operations → Feeds` (tab “Feed Mirrors”).
|
||||
**Why changed:** keep but add dependency/impact to releases.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Feed Mirrors] --> B[Mirror Detail]
|
||||
A --> C[Security Data Sources]
|
||||
A --> D[Nightly Ops Report]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ FEED MIRRORS │
|
||||
│ Formerly: Operations ▸ Feeds ▸ Feed Mirrors │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Total mirrors: 0 | Synced: 0 | Stale: 0 | Errors: 0 | Total storage: 0B │
|
||||
│ Search mirrors: ____ Status ▾ Feed Type ▾ [Refresh] │
|
||||
│ │
|
||||
│ No mirrors found matching your criteria │
|
||||
│ (When configured: show NVD/OSV mirror status + last sync + staleness + errors) │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8.3 Airgap Bundles tab
|
||||
|
||||
**Formerly:** tab existed but not emphasized.
|
||||
**Why changed:** Airgap is part of “operate in constrained networks” — must be second-class.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Airgap Bundles] --> B[Bundle Export Detail]
|
||||
A --> C[Evidence & Audit → Export Center]
|
||||
A --> D[Release Control → Bundle Catalog]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ AIRGAP BUNDLES │
|
||||
│ Formerly: Operations ▸ Feeds ▸ AirGap Bundles │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundle Name Contents (feeds/sboms/policy) Size Created Status │
|
||||
│ daily-airgap-2026-02 NVD+OSV + SBOM index + policy 2.1GB 02:30 READY │
|
||||
│ ... │
|
||||
│ Actions: [Download] [Verify] [Rebuild] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8.4 Version Locks tab
|
||||
|
||||
**Formerly:** tab existed but unclear purpose.
|
||||
**Why changed:** Version locks are how you enforce **determinism** of datasets (feeds + SBOM tooling) for auditing.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Version Locks] --> B[Lock Detail]
|
||||
A --> C[Evidence & Audit → Proof Chains]
|
||||
A --> D[Integrations → Security Data Sources]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ VERSION LOCKS (Deterministic datasets for audit) │
|
||||
│ Formerly: Operations ▸ Feeds ▸ Version Locks │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Lock Name Dataset(s) Locked Version Used By │
|
||||
│ prod-release-lock OSV + internal VEX 2026.02.18.01 prod approvals │
|
||||
│ audit-jan-2026 NVD snapshot 2026.01.31 auditor evidence │
|
||||
│ Actions: [Create Lock] [Rotate] [Export Attestation] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 9) Quotas & Throttling
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Operations → Quotas` (“Operator Quota Dashboard”)
|
||||
* **Plus:** `Settings → Usage & Limits` (overlapping)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Operations → Quotas & Throttling` = **operational telemetry + throttles**
|
||||
* **Admin → Usage & Limits** = **configuration + entitlements** (already in Pack 5)
|
||||
|
||||
### Why changed
|
||||
|
||||
* Separates **“observe”** (ops) from **“configure limits”** (admin).
|
||||
* Keeps existing “Operator Quota Dashboard” but clarifies scope.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Quotas & Throttling] --> B[Throttle Event Detail]
|
||||
A --> C[Administration → Usage & Limits (configure quotas)]
|
||||
A --> D[Operations Overview]
|
||||
```
|
||||
|
||||
### ASCII mock (based on your screenshot)
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ QUOTAS & THROTTLING [Export Report] [Refresh]│
|
||||
│ Formerly: Operations ▸ Quotas │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Consumption Trend (30 days) | Quota Forecast │
|
||||
│ (chart) | (chart) │
|
||||
│ │
|
||||
│ Top Tenants by Usage: No tenant data available │
|
||||
│ Recent Throttle Events: none in last 24h │
|
||||
│ │
|
||||
│ Config: quotas are set in Administration ▸ Usage & Limits [Open] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 10) Mapping (guarantee reorg intact; no feature loss)
|
||||
|
||||
To show you I’m not drifting the IA, here is the **preservation mapping** for Operations items:
|
||||
|
||||
* **Feeds** (old Ops) → **Operations → Feeds & Airgap** (same content, clarified)
|
||||
* **Scheduler Runs** (old Ops) → **Operations → Scheduler → Runs** (same, plus links)
|
||||
* **Orchestrator** (old Ops) → **Operations → Orchestrator** (same, plus explicit Jobs/Backfill)
|
||||
* **Platform Health** (old Ops) → **Operations → Platform Health** (same, plus impact)
|
||||
* **Dead Letter** (old Ops) → **Operations → Dead Letter Queue** (same, plus pipeline context)
|
||||
* **Quotas** (old Ops) → **Operations → Quotas & Throttling** (telemetry)
|
||||
while quota configuration stays in **Administration → Usage & Limits** (as in Pack 5)
|
||||
* **Nightly Ops Report** (new but required by your criteria) sits under **Operations**, and is linked from **Dashboard + Approvals + Integrations**
|
||||
|
||||
---
|
||||
|
||||
If you reply **“continue”**, Pack 7 will convert the remaining **Security** screens (Overview, Findings, Vulnerabilities, VEX Hub, Exceptions, SBOM Graph, SBOM Lake) into the same:
|
||||
✅ Mermaid menu graph + Mermaid per-screen graph + ASCII + Formerly/Why moved, and make sure **reachability (build/image/runtime)** is clearly second-class everywhere it matters.
|
||||
683
docs/modules/ui/v2-rewire/pack-07.md
Normal file
683
docs/modules/ui/v2-rewire/pack-07.md
Normal file
@@ -0,0 +1,683 @@
|
||||
## Pack 7 — Security (menu + every screen graph + ASCII mocks; keep the main IA intact)
|
||||
|
||||
Security stays a **root menu**. This pack reorganizes Security pages to be **release/bundle aware**, surfaces **SBOM findings + hybrid reachability (build / image-Dover / runtime)** as **second-class**, and adds clear links to **Nightly Ops Report** + **Integrations health** when data is stale.
|
||||
|
||||
---
|
||||
|
||||
# 1) Security menu graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
SEC[Security] --> SEC_OV[Overview]
|
||||
SEC --> SEC_FIND[Findings]
|
||||
SEC --> SEC_VULN[Vulnerabilities]
|
||||
SEC --> SEC_VEX[VEX Hub]
|
||||
SEC --> SEC_EXC[Exceptions]
|
||||
SEC --> SEC_COV[Coverage & Analytics]
|
||||
SEC --> SEC_GRAPH[SBOM Graph (Beta)]
|
||||
|
||||
SEC_FIND --> SEC_FIND_DETAIL[Finding Detail]
|
||||
SEC_VULN --> SEC_VULN_DETAIL[Vulnerability Detail (CVE)]
|
||||
SEC_VEX --> SEC_VEX_DETAIL[VEX Statement Detail]
|
||||
SEC_EXC --> SEC_EXC_DETAIL[Exception Detail / Request]
|
||||
```
|
||||
|
||||
> **Reachability (Build / Image-Dover / Runtime)** is **not** a root product menu; it is **embedded as a first-visible widget** in **Security Overview** and **a first-class facet/column** in **Findings/Vulnerabilities** (i.e., second-class across the product, not buried).
|
||||
|
||||
---
|
||||
|
||||
# 2) Security → Overview
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Security → Overview` (`/security/overview`), showing severity counters, VEX coverage, active exceptions, etc.
|
||||
* Missing: explicit **“where reachable criticals exist”** and **hybrid reachability coverage**.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Security → Overview` (same route), but it becomes the **security posture cockpit for release decisions**:
|
||||
|
||||
* “Critical reachable issues” surfaced by **Region → Environment**
|
||||
* **SBOM freshness** + **Reachability coverage** (build/image/runtime)
|
||||
* **CVE dataset freshness** (OSV/NVD) and explicit link to **Nightly Ops Report**
|
||||
* “Top affected bundles/releases” to drive hotfix decisions
|
||||
|
||||
### Why changed
|
||||
|
||||
StellaOps is about **release/hotpatch governance** + **auditable decisions**. Security Overview must answer in 10 seconds:
|
||||
|
||||
* “Are we safe to promote?”
|
||||
* “If not, which envs/regions are blocked and why?”
|
||||
* “Is the data trustworthy (feeds, scans, reachability) or are we blind?”
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Security Overview] --> B[Security Findings (filtered)]
|
||||
A --> C[Vulnerabilities (filtered)]
|
||||
A --> D[VEX Hub]
|
||||
A --> E[Exceptions]
|
||||
A --> F[Coverage & Analytics]
|
||||
A --> G[Operations: Nightly Ops Report]
|
||||
A --> H[Integrations: Security Data Sources]
|
||||
A --> I[Release Control: Bundle Organizer / Hotfix]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ OVERVIEW [Run Scan] │
|
||||
│ Formerly: Security ▸ Overview │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Scope: Region ▾ (All) Environment ▾ (All) Time ▾ (Last 7d) │
|
||||
│ Data Health: CVE Feeds OSV: OK | NVD: DOWN → [Open Nightly Ops Report] [Open Integrations] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ POSTURE (hybrid reachability aware) │
|
||||
│ Critical (Reachable): 3 envs | High (Reachable): 6 envs | Medium: 12 envs │
|
||||
│ Reachability sources coverage: Build 92% | Image/Dover 96% | Runtime 61% │
|
||||
│ SBOM freshness: Images scanned <24h: 88% | Runtime inventory <24h: 54% │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ WHERE THE RISK IS (Region → Env) │
|
||||
│ - eu-west ▸ prod-eu Critical reachable: 5 (Top: log4j, openssl) [View Findings] │
|
||||
│ - us-east ▸ staging-us Critical reachable: 2 (Top: curl) [View Findings] │
|
||||
│ - us-east ▸ prod-us High reachable: 7 (Top: glibc) [View Findings] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ VEX COVERAGE EXCEPTIONS │
|
||||
│ Findings w/ VEX: 14 | Awaiting VEX: 6 Active: 2 Pending: 1 Expiring<14d: 1 │
|
||||
│ [Open VEX Hub] [Open Exceptions] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ RELEASE IMPACT │
|
||||
│ Hotfix candidates (bundles/releases): │
|
||||
│ - Bundle: api-gateway@v2.1.0 (prod-eu) Critical reachable: 3 [Open Bundle] │
|
||||
│ - Bundle: user-service@v3.0.0-rc1 High reachable: 4 [Open Bundle] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 3) Security → Findings
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Security → Findings` (`/security/findings`)
|
||||
Table included: CVE, package, severity, CVSS, reachable, VEX, release impact, delta, environments, first seen.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Security → Findings` stays, but becomes **hybrid reachability first-visible**:
|
||||
|
||||
* Replace single “Reachable” with:
|
||||
|
||||
* **Hybrid Reachable** (computed)
|
||||
* **Build Reachable / Image(Dover) Reachable / Runtime Reachable**
|
||||
* Add **Region** + **Environment** filters (region-first model)
|
||||
* Add **Bundle / Release** filters (release governance model)
|
||||
* Add **Dataset provenance** (which CVE snapshot + SBOM snapshot the decision used)
|
||||
|
||||
### Why changed
|
||||
|
||||
Reachability is part of “what is exploitable for us” and must not be buried. Also, findings must route to **Release Bundles** and evidence.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Security Findings] --> B[Finding Detail]
|
||||
A --> C[Vulnerability Detail (CVE)]
|
||||
A --> D[VEX Hub (filtered by CVE)]
|
||||
A --> E[Exceptions (filtered)]
|
||||
A --> F[Release Control: Bundle Organizer (filtered)]
|
||||
A --> G[Operations: Nightly Ops Report (data health)]
|
||||
A --> H[Evidence & Audit: Proof Chain (for decision)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ FINDINGS [Export CSV] │
|
||||
│ Formerly: Security ▸ Findings │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Severity ▾ Hybrid Reachable ▾ Reach Source ▾(Any/Build/Image/Runtime) VEX ▾ │
|
||||
│ Region ▾ Environment ▾ Bundle/Release ▾ Time ▾ │
|
||||
│ Banner: NVD feed stale → reachability/score may be incomplete [Open Nightly Ops Report] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ CVE Package Sev CVSS Hybrid Build Image Runtime VEX Bundle Impact First │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ CVE-XXXX openssl CRIT 9.8 YES NO YES YES Await api-gateway@2.1.0 2d │
|
||||
│ CVE-YYYY log4j CRIT 10.0 YES YES YES NO NotAff user-svc@3.0.0 1d │
|
||||
│ CVE-ZZZZ curl HIGH 8.1 NO NO NO NO - none 7d │
|
||||
│ Actions per row: [View Finding] [View CVE] [Request Exception] [Open Bundle] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 4) Security → Finding Detail (new explicit drill-down)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** implicit (row in Findings table, no dedicated “decision page”).
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Security → Findings → Finding Detail`
|
||||
|
||||
### Why changed
|
||||
|
||||
A finding needs an **auditable explanation page**:
|
||||
|
||||
* What data was used (SBOM snapshot, CVE dataset version)
|
||||
* Reachability per source (build/image/runtime)
|
||||
* Impacted **bundles/releases** and environments
|
||||
* Associated **VEX** and **exceptions**
|
||||
* Deep links to **Proof Chain / Evidence Bundle**
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Finding Detail] --> B[Vulnerability Detail (CVE)]
|
||||
A --> C[VEX Statement Detail]
|
||||
A --> D[Exception Detail / Request]
|
||||
A --> E[Release Control: Bundle Organizer (affected bundles)]
|
||||
A --> F[Evidence & Audit: Proof Chains]
|
||||
A --> G[Evidence & Audit: Replay/Verify]
|
||||
A --> H[Operations: Nightly Ops Report (if stale inputs)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ FINDING DETAIL: CVE-XXXX in openssl │
|
||||
│ Formerly: Security ▸ Findings (row drilldown) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Severity: CRITICAL CVSS: 9.8 EPSS: (if available) KEV: (if available) │
|
||||
│ Data provenance: SBOM snapshot: 2026-02-18T02:00Z | CVE dataset: OSV-2026.02.18.01 | NVD: stale │
|
||||
│ │
|
||||
│ REACHABILITY (HYBRID) │
|
||||
│ Hybrid Reachable: YES (because Image/Dover=YES OR Runtime=YES) │
|
||||
│ ┌───────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Source Coverage Result Evidence link │ │
|
||||
│ │ Build 92% NO [build reach report] │ │
|
||||
│ │ Image/Dover96% YES [image reach report] │ │
|
||||
│ │ Runtime 61% YES [runtime reach report] │ │
|
||||
│ └───────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ AFFECTED (Region → Env) │
|
||||
│ - eu-west ▸ prod-eu reachable=YES first seen=2d bundle: api-gateway@2.1.0 [Open Bundle] │
|
||||
│ - us-east ▸ staging-us reachable=YES first seen=1d bundle: api-gateway@2.1.0 [Open Bundle] │
|
||||
│ │
|
||||
│ CONTROLS │
|
||||
│ VEX: Awaiting VEX → [Open VEX Hub] Exceptions: none → [Request Exception] │
|
||||
│ Evidence: [Open Proof Chain] [Replay/Verify] [Export Evidence Bundle snapshot] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 5) Security → Vulnerabilities (CVE Catalog)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Security → Vulnerabilities` (`/security/vulnerabilities`) but it was a placeholder (“pending data integration”).
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Security → Vulnerabilities` becomes the **CVE catalog** view:
|
||||
|
||||
* CVE metadata + source freshness (OSV/NVD/vendor)
|
||||
* “In our estate” counts: findings total + reachable total
|
||||
* Drill-down to CVE detail
|
||||
|
||||
### Why changed
|
||||
|
||||
You need both:
|
||||
|
||||
* **Findings** = concrete occurrences in your envs/bundles
|
||||
* **Vulnerabilities** = global CVE view with intelligence + provenance
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Vulnerabilities (Catalog)] --> B[Vulnerability Detail (CVE)]
|
||||
A --> C[Security Findings (filtered by CVE)]
|
||||
A --> D[Integrations: Security Data Sources]
|
||||
A --> E[Operations: Nightly Ops Report (feed failures)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ VULNERABILITIES (CVE CATALOG) │
|
||||
│ Formerly: Security ▸ Vulnerabilities (pending integration) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Severity ▾ In-Our-Estate ▾(Any/Yes) Reachable ▾(Any/Yes) Source ▾(OSV/NVD/Vendor) │
|
||||
│ Data freshness: OSV OK | NVD DOWN → [Open Integrations] [Open Nightly Ops Report] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ CVE Sev CVSS Sources In our estate Reachable Top bundles impacted │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ CVE-XXXX CRIT 9.8 OSV,NVD* 12 findings 7 api-gateway@2.1.0, web@2.0.0 │
|
||||
│ CVE-YYYY HIGH 8.1 OSV 3 findings 0 none │
|
||||
│ Actions: [View CVE] [View Findings] │
|
||||
│ *NVD stale indicator │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 6) Vulnerability Detail (CVE) — new
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** none (catalog didn’t exist).
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Security → Vulnerabilities → Vulnerability Detail`
|
||||
|
||||
### Why changed
|
||||
|
||||
You need a single place to explain the vulnerability and tie it to:
|
||||
|
||||
* findings + reachability + bundles
|
||||
* VEX statements
|
||||
* evidence snapshot (dataset versions)
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Vulnerability Detail (CVE)] --> B[Security Findings (filtered)]
|
||||
A --> C[Finding Detail]
|
||||
A --> D[VEX Statement Detail]
|
||||
A --> E[Exceptions (filtered)]
|
||||
A --> F[Release Control: Bundle Organizer]
|
||||
A --> G[Evidence & Audit: Proof Chains (dataset attestation)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ CVE DETAIL: CVE-XXXX │
|
||||
│ Formerly: (new) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Severity: CRITICAL CVSS: 9.8 │
|
||||
│ Sources: OSV (fresh) | NVD (stale) | Vendor advisory (optional) │
|
||||
│ Affected: openssl < 3.0.2 (example) Fixed: 3.0.2+ (example) │
|
||||
│ Dataset evidence: OSV snapshot 2026.02.18.01 [Export dataset attestation] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ IN OUR ESTATE │
|
||||
│ Findings: 12 | Hybrid reachable: 7 │
|
||||
│ Reachability breakdown: Build 2 | Image/Dover 6 | Runtime 5 │
|
||||
│ Top impacted bundles: api-gateway@2.1.0, web-frontend@2.0.0 │
|
||||
│ [View Findings] [Open Bundle Organizer filtered] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ CONTROLS │
|
||||
│ VEX statements: 1 Not-Affected, 1 Under-Investigation → [Open VEX Hub filtered] │
|
||||
│ Exceptions: 2 active (prod-eu) → [Open Exceptions filtered] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 7) Security → VEX Hub
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Security → VEX Hub` (`/security/vex`) but showing error and limited utility.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Security → VEX Hub` becomes the **exploitability statement center**:
|
||||
|
||||
* Search statements by CVE/component/bundle
|
||||
* Show statement validity (issuer, signature, scope, expiry)
|
||||
* Directly explain policy effect (“blocks/unblocks approvals”)
|
||||
|
||||
### Why changed
|
||||
|
||||
VEX is essential to **reduce noise** and to make decisions **auditable**. It must be adjacent to findings.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[VEX Hub] --> B[VEX Statement Detail]
|
||||
A --> C[Security Findings (filtered by CVE/component)]
|
||||
A --> D[Integrations: VEX Sources]
|
||||
A --> E[Evidence & Audit: Trust & Signing]
|
||||
A --> F[Release Control: Governance & Policy (how VEX affects gates)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ VEX HUB [ + Search Statements ]│
|
||||
│ Formerly: Security ▸ VEX Hub │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Banner: VEX source error → [Retry] (if feeds/integration failing) │
|
||||
│ Coverage: Findings with VEX: 14 | Awaiting VEX: 6 │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Statement ID Issuer Scope (bundle/env) Status Validity Actions │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ vex-001 VendorA api-gateway@2.1.0 NOT_AFFECTED signed [View] │
|
||||
│ vex-002 InternalSec prod-eu / web@2.0.0 INVESTIGATING signed [View] │
|
||||
│ vex-003 VendorB openssl component-wide AFFECTED signed [View] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 8) VEX Statement Detail — new
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** implicit.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Security → VEX Hub → Statement Detail`
|
||||
|
||||
### Why changed
|
||||
|
||||
You need a **decision artifact** that auditors can read:
|
||||
|
||||
* statement content + signature chain
|
||||
* scope (which bundle/env/component)
|
||||
* policy effect
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[VEX Statement Detail] --> B[Trust & Signing (issuer, cert)]
|
||||
A --> C[Security Findings (affected)]
|
||||
A --> D[Vulnerability Detail (CVE)]
|
||||
A --> E[Evidence & Audit: Proof Chain]
|
||||
A --> F[Release Control: Governance & Policy]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ VEX STATEMENT DETAIL: vex-001 │
|
||||
│ Formerly: VEX Hub (statement row) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Issuer: VendorA Signature: VALID Rekor entry: present [View in Trust & Signing] │
|
||||
│ Scope: Bundle api-gateway@2.1.0 | Regions: eu-west, us-east | Envs: prod, staging │
|
||||
│ CVEs: CVE-XXXX, CVE-AAAA │
|
||||
│ Status: NOT_AFFECTED Reason: component not reachable in shipped configuration (example) │
|
||||
│ Policy Effect: allows approvals to proceed for scoped bundles (per governance rules) │
|
||||
│ Evidence: [Open Proof Chain] [Export to Evidence Bundle] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 9) Security → Exceptions
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Security → Exceptions` (`/security/exceptions`)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Security → Exceptions` remains, but:
|
||||
|
||||
* exceptions are tied to **Finding/CVE + Region/Env + Bundle/Release**
|
||||
* includes **expiry + mitigation** as first-visible fields
|
||||
* links to **Release Control → Exception Workflow** (configuration lives there now)
|
||||
|
||||
### Why changed
|
||||
|
||||
Exceptions are part of **release governance** and must be traceable to **what was accepted**, **where**, and **until when**.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Security Exceptions] --> B[Exception Detail / Request]
|
||||
A --> C[Security Findings (filtered)]
|
||||
A --> D[Release Control: Governance & Policy (exception workflow)]
|
||||
A --> E[Evidence & Audit: Evidence Bundle (for exception record)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ EXCEPTIONS [ + Request Exception ]│
|
||||
│ Formerly: Security ▸ Exceptions │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Status ▾ Region ▾ Environment ▾ Bundle/Release ▾ Expiring soon ▾ │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Exception ID Finding/CVE Scope (region/env) Bundle Reason Expires Status │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ exc-101 CVE-XXXX eu-west/prod-eu api@2.1.0 mitigation… 14d ACTIVE │
|
||||
│ exc-102 CVE-YYYY us-east/staging-us user@3.0.0 rollback… 2d PENDING │
|
||||
│ Actions: [View] [Extend] [Revoke] [Export evidence] │
|
||||
│ Workflow config: Release Control ▸ Governance & Policy ▸ Exception Workflow [Open] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 10) Exception Detail / Request — new explicit page
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** implied; request button existed but no structured “audit-grade” view.
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Security → Exceptions → Detail/Request`
|
||||
|
||||
### Why changed
|
||||
|
||||
This is the artifact auditors will ask for:
|
||||
|
||||
* what risk accepted, scope, mitigation, approvals, expiry
|
||||
* evidence attachments / signatures
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Exception Detail] --> B[Finding Detail]
|
||||
A --> C[Vulnerability Detail (CVE)]
|
||||
A --> D[Evidence & Audit: Proof Chain]
|
||||
A --> E[Evidence & Audit: Export Center]
|
||||
A --> F[Release Control: Governance & Policy (workflow)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ EXCEPTION DETAIL: exc-101 │
|
||||
│ Formerly: Security ▸ Exceptions (row) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Finding: CVE-XXXX in openssl Severity: CRITICAL Hybrid reachable: YES │
|
||||
│ Scope: eu-west ▸ prod-eu | Bundle: api-gateway@2.1.0 │
|
||||
│ Reason: customer outage risk if patched immediately (example) │
|
||||
│ Mitigation: WAF rule + restricted egress + monitoring │
|
||||
│ Expires: 2026-03-04 Approvers: security-lead, release-manager │
|
||||
│ Evidence: [Attach] [Open Proof Chain] [Export to Evidence Bundle] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11) Security → Coverage & Analytics (SBOM Lake moved)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Analytics → SBOM Lake` (`/analytics/sbom-lake`)
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Security → Coverage & Analytics`
|
||||
(and cross-linked from **Evidence & Audit** because it measures attestation coverage)
|
||||
|
||||
### Why changed
|
||||
|
||||
SBOM Lake is not “generic analytics.” It directly answers:
|
||||
|
||||
* “Do we have enough SBOM + reachability + VEX + policy-decision attestations to trust promotions?”
|
||||
* “Which regions/envs are blind or stale?”
|
||||
That is **security posture** and must live under Security.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Coverage & Analytics] --> B[Security Findings (filtered)]
|
||||
A --> C[VEX Hub (filtered)]
|
||||
A --> D[Operations: Nightly Ops Report]
|
||||
A --> E[Integrations: Security Data Sources]
|
||||
A --> F[Evidence & Audit: Proof Chains]
|
||||
A --> G[Administration: Usage & Limits]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock (expanded SBOM + reachability coverage)
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ COVERAGE & ANALYTICS │
|
||||
│ Formerly: Analytics ▸ SBOM Lake │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Region ▾ Environment ▾ Min Severity ▾ Time Window ▾ │
|
||||
│ Banner: Analytics API auth error (if any) → [Open System] [Open Integrations] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ATTESTATION COVERAGE (last 30d) │
|
||||
│ SBOM: 88% | VEX: 62% | Policy Decision: 91% | Human Approval: 74% │
|
||||
│ Complete Chains: 71% (SBOM+Reachability+Policy+Evidence) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ HYBRID REACHABILITY COVERAGE │
|
||||
│ Build reach coverage: 92% (fresh <24h: 90%) │
|
||||
│ Image/Dover coverage: 96% (fresh <24h: 88%) │
|
||||
│ Runtime coverage: 61% (fresh <24h: 54%) │
|
||||
│ → gaps reduce confidence in “reachable” classification │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ APPROVAL VELOCITY / BLOCKERS │
|
||||
│ - Top blocker: NVD feed stale (dataset) → [Nightly Ops Report] │
|
||||
│ - Top blocker: runtime reach ingest degraded (eu-central agent) → [Worker Fleet] │
|
||||
│ Exports: [Export CSV] [Export coverage attestation snapshot] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12) Security → SBOM Graph (Beta)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Security → SBOM Graph` (`/security/sbom`) but the build says “not yet available.”
|
||||
|
||||
### Now
|
||||
|
||||
* **Now:** `Security → SBOM Graph (Beta)` remains, but positioned explicitly as:
|
||||
|
||||
* a visualization tool for dependency relationships and component impact
|
||||
* driven by **Bundles/Releases**, with region/env lens
|
||||
* links back to Findings and to Bundle Organizer
|
||||
|
||||
### Why changed
|
||||
|
||||
Even if not implemented yet, the IA must reserve the place so it doesn’t get shoved into random “analytics” later. It’s a security tool.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[SBOM Graph (Beta)] --> B[Security Findings (component/CVE filtered)]
|
||||
A --> C[Release Control: Bundle Organizer]
|
||||
A --> D[Vulnerability Detail (CVE)]
|
||||
A --> E[Coverage & Analytics]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ SBOM GRAPH (BETA) │
|
||||
│ Formerly: Security ▸ SBOM Graph (not available) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Scope: Bundle/Release ▾ Region ▾ Environment ▾ │
|
||||
│ (Graph canvas) │
|
||||
│ - Nodes: components/packages/images/services │
|
||||
│ - Edges: dependency relationships │
|
||||
│ │
|
||||
│ Side panel: Selected node → vulnerabilities + reachability + affected bundles │
|
||||
│ Actions: [View Findings] [View CVE] [Open Bundle Organizer] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Preservation mapping (prove the reorg stays intact)
|
||||
|
||||
* `Security → Overview` stays **Security root**
|
||||
* `Security → Findings` stays **Security root**, but now **hybrid reachability** is first-visible
|
||||
* `Security → Vulnerabilities` becomes real (was placeholder)
|
||||
* `Security → VEX Hub` stays under **Security root**
|
||||
* `Security → Exceptions` stays under **Security root**, with workflow config linked to **Release Control**
|
||||
* `Analytics → SBOM Lake` is moved to **Security → Coverage & Analytics** (and cross-linked from Evidence & Audit)
|
||||
* `Security → SBOM Graph` stays, labeled **Beta**
|
||||
|
||||
---
|
||||
|
||||
If you want, Pack 8 can cover **Release Control** screens in the same format (Mermaid + ASCII + Formerly/Why) including the missing **Release Bundle Organizer** you called out (microservice digest→version, env vars from Vault/Consul, per-repo changelog, bundle composition, promotion paths).
|
||||
984
docs/modules/ui/v2-rewire/pack-08.md
Normal file
984
docs/modules/ui/v2-rewire/pack-08.md
Normal file
@@ -0,0 +1,984 @@
|
||||
## Pack 8 — Release Control (root menu)
|
||||
|
||||
This pack gives you: **(1)** Mermaid for the **Release Control menu** and **every screen flow**, **(2)** an **ASCII mock** per screen, and **(3)** “**Formerly / Why changed**” per screen. It also adds the missing **Release Bundle Organizer** (digest→version, Vault/Consul-derived env variables, per-repo changelog, bundle composition).
|
||||
|
||||
---
|
||||
|
||||
# 1) Release Control menu graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RC[Release Control] --> RC_HOME[Control Plane]
|
||||
RC --> RC_BUNDLES[Bundles]
|
||||
RC --> RC_RELEASES[Releases]
|
||||
RC --> RC_APPROVALS[Approvals]
|
||||
RC --> RC_ENV[Regions & Environments]
|
||||
RC --> RC_DELIVERY[Delivery]
|
||||
|
||||
RC_BUNDLES --> B_CAT[Bundle Catalog]
|
||||
RC_BUNDLES --> B_ORG[Bundle Organizer]
|
||||
RC_BUNDLES --> B_REPOS[Repositories & Versions]
|
||||
|
||||
B_CAT --> B_DETAIL[Bundle Detail]
|
||||
B_ORG --> B_DETAIL
|
||||
|
||||
RC_RELEASES --> R_LIST[Releases List]
|
||||
R_LIST --> R_DETAIL[Release Detail]
|
||||
|
||||
RC_APPROVALS --> A_QUEUE[Approvals Queue]
|
||||
A_QUEUE --> A_DETAIL[Approval Detail]
|
||||
|
||||
RC_ENV --> REG_OV[Region Overview]
|
||||
REG_OV --> ENV_DETAIL[Environment Detail]
|
||||
RC_ENV --> PROMO[Promotion Paths]
|
||||
|
||||
RC_DELIVERY --> TARGETS[Targets]
|
||||
RC_DELIVERY --> AGENTS[Agents]
|
||||
RC_DELIVERY --> WF[Workflows]
|
||||
```
|
||||
|
||||
**Design intent:** Release Control is where you **compose**, **promote**, and **govern** releases/hotfixes—**with bundles as the organizing primitive**, regions first, and security/evidence surfaced at decision points.
|
||||
|
||||
---
|
||||
|
||||
# 2) Release Control → Control Plane
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Control Plane` (top-level)
|
||||
Showed environment pipeline (Dev/Staging/UAT/Prod), pending approvals, active deployments, recent releases.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Control Plane`
|
||||
Adds:
|
||||
|
||||
* **Region-first** pipeline (tabs or left rail: `eu-west`, `us-east`, etc.)
|
||||
* **Per-env SBOM posture** (not just deploy health): critical reachable, SBOM freshness, reachability coverage
|
||||
* **Nightly Jobs / Data Health** summary (feeds, rescan backlog, integration connectivity)
|
||||
* Quick jumps into **Bundles**, **Approvals**, **Environment Detail**, **Nightly Ops Report**
|
||||
|
||||
### Why changed
|
||||
|
||||
This page must drive **release governance**. The first question is not “what deployed?” but:
|
||||
**“What can be safely promoted in each region, given current SBOM + reachability + feed health?”**
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
CP[Release Control: Control Plane] --> A[Approvals Queue]
|
||||
CP --> R[Releases List]
|
||||
CP --> B[Bundle Catalog]
|
||||
CP --> E[Environment Detail]
|
||||
CP --> P[Promotion Paths]
|
||||
CP --> S[Security Overview]
|
||||
CP --> N[Operations: Nightly Ops Report]
|
||||
CP --> I[Integrations: Status]
|
||||
CP --> EV[Evidence & Audit: Export Center]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ CONTROL PLANE [Create Bundle] │
|
||||
│ Formerly: Control Plane │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Region: [All ▾] eu-west us-east ap-south Time: Last 24h ▾ │
|
||||
│ Data Health: OSV OK | NVD STALE | Registry OK | Vault OK | Jenkins DEGRADED → [Nightly Ops] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ REGION PIPELINE (env status + SBOM posture) │
|
||||
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
|
||||
│ │ Dev │→ │ Staging │→ │ UAT │→ │ Production │ │
|
||||
│ │ Deploy: OK │ │ Deploy: OK │ │ Deploy: ? │ │ Deploy: DEG │ │
|
||||
│ │ SBOM: 0 crit │ │ SBOM: 1 crit* │ │ SBOM: - │ │ SBOM: 5 crit* │ │
|
||||
│ │ ReachCov: 72% │ │ ReachCov: 81% │ │ ReachCov: - │ │ ReachCov: 58% │ │
|
||||
│ │ [Open] │ │ [Open] │ │ [Open] │ │ [Open] │ │
|
||||
│ └───────────────┘ └───────────────┘ └───────────────┘ └───────────────┘ │
|
||||
│ *crit = critical reachable │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ PENDING APPROVALS (region/env aware) ACTIVE DEPLOYMENTS │
|
||||
│ - api-gateway@bundle v2.1.0 staging→prod PASS 1/2 - hotfix 1.2.4 prod-eu RUNNING │
|
||||
│ - user-service@bundle v3.0.0 staging→prod BLOCK 0/2 [View All] │
|
||||
│ [View Approvals] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ BUNDLES READY / AT RISK │
|
||||
│ - Bundle: platform@v1.3.0-rc1 Staging SBOM: clean Evidence: 92% [Open Bundle] │
|
||||
│ - Bundle: api-gateway@v2.1.0 Prod SBOM: 3 crit* NVD stale [Open Findings] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 3) Release Control → Bundles → Bundle Catalog
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** no explicit bundle concept.
|
||||
|
||||
* Bundling was implied by `Releases` and “components count”.
|
||||
* Digest was primary; “bundle organization” and “per-repo changelog” were not first-class.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Bundles → Bundle Catalog`
|
||||
|
||||
* Lists **Bundle Versions** as the thing that gets promoted
|
||||
* Shows **security posture per bundle** (critical reachable counts, reachability coverage)
|
||||
* Shows **evidence completeness** (is the bundle audit-ready)
|
||||
* One click to “Create Release” or “Request Approval” in a region/env
|
||||
|
||||
### Why changed
|
||||
|
||||
StellaOps is “**promote by digest**,” but humans and auditors reason in **versions** and **bundles**:
|
||||
|
||||
* “api-gateway v2.1.0 in prod-eu” (bundle version)
|
||||
* “what changed since v2.0.9” (changelog)
|
||||
* “what config snapshot was used” (Vault/Consul references)
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
BC[Bundle Catalog] --> BD[Bundle Detail]
|
||||
BC --> BO[Bundle Organizer]
|
||||
BC --> RV[Repositories & Versions]
|
||||
BC --> AQ[Approvals Queue]
|
||||
BC --> RL[Releases List]
|
||||
BC --> SF[Security Findings (filtered)]
|
||||
BC --> EV[Evidence & Audit: Export Center]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ BUNDLES ▸ CATALOG [ + Create Bundle ] │
|
||||
│ Formerly: (N/A) Bundles were implicit under Releases/components │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Repo ▾ Bundle Name ▾ Version ▾ Region ▾ Env ▾ SBOM Status ▾ Evidence ▾ │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundle Version Repo Scope SBOM (crit*) ReachCov Evidence Actions │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ api-gateway v2.1.0 gateway-repo 3 crit* 81% 88% [Open] [Rel] │
|
||||
│ user-service v3.0.0-rc1 user-repo 0 77% 91% [Open] [Rel] │
|
||||
│ platform v1.3.0-rc1 multi-repo 1 high* 66% 74% [Open] [Rel] │
|
||||
│ *crit* = critical reachable (hybrid reachability) │
|
||||
│ [Rel] = Create Release / Request Approval │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 4) Release Control → Bundles → Bundle Organizer (the missing core)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** partial/implicit across:
|
||||
|
||||
* `Releases` (components count)
|
||||
* SCM/CI (outside StellaOps) for composing “what is in a release”
|
||||
* Vault/Consul config was not attached as a release artifact
|
||||
* No consistent “digest→version” mapping with changelog & config snapshot
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Bundles → Bundle Organizer`
|
||||
|
||||
* **Digest→Version**: a microservice digest becomes a **bundle version** (semver/rc)
|
||||
* **Bundle composition**: multiple microservices + their pinned digests/versions
|
||||
* **Env variables**: references to **Vault** and **Consul** keys used for a given env/region
|
||||
(store pointers + redacted resolved values, not secrets)
|
||||
* **Per-repo changelog**: commits/tags between prior version and new digest
|
||||
* Built-in “security/evidence readiness” before generating a release/approval
|
||||
|
||||
### Why changed
|
||||
|
||||
This is the governance kernel: **what exactly is being promoted**, with **what config**, and **what changed**, in a form that is exportable as evidence.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
BO[Bundle Organizer] --> BD[Bundle Detail]
|
||||
BO --> RV[Repositories & Versions]
|
||||
BO --> INT[Integrations: SCM/CI/Registry/Vault/Consul]
|
||||
BO --> SF[Security Findings (bundle filtered)]
|
||||
BO --> EV[Evidence & Audit: Proof Chain + Export]
|
||||
BO --> REL[Create Release]
|
||||
BO --> APR[Request Approval]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock (tabs show bundle composition + config + changelog)
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ BUNDLES ▸ ORGANIZER: Create/Update Bundle │
|
||||
│ Formerly: (N/A) Composition lived across CI/CD + Releases list │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundle: [api-gateway] Version: [v2.1.0 ▾] Region: [eu-west ▾] Target Env: [staging→prod ▾] │
|
||||
│ Repo(s): gateway-repo, auth-repo, shared-lib-repo │
|
||||
│ Tabs: [Components] [Config (Vault/Consul)] [Changelog] [Security] [Evidence] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ COMPONENTS │
|
||||
│ Service/Microservice Digest (registry) Derived Version SBOM Reach (H/B/I/R) │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ api-gateway sha256:abc... v2.1.0 OK YES/NO/YES/YES │
|
||||
│ auth-sidecar sha256:def... v1.8.4 WARN NO/NO/YES/NO │
|
||||
│ shared-config git: tag v4.2.0 → v4.2.1 v4.2.1 - - │
|
||||
│ [ + Add service ] [Auto-derive versions] [Pin digests] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ CONFIG (Vault / Consul) (stored as references + redacted snapshot) │
|
||||
│ Vault paths: kv/prod/eu-west/api-gateway/* (status: connected) │
|
||||
│ Consul prefix: eu-west/prod/api-gateway/ (status: connected) │
|
||||
│ Resolved variables (redacted): RATE_LIMIT=*** DB_HOST=*** FEATURE_FLAG_X=*** │
|
||||
│ [Validate access] [Snapshot config refs] [Diff vs previous bundle] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ CHANGELOG (per repository) │
|
||||
│ gateway-repo: v2.0.9 → digest abc... 12 commits 3 PRs [View] │
|
||||
│ auth-repo: v1.8.3 → digest def... 4 commits 1 PR [View] │
|
||||
│ [Generate release notes] [Attach links] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ACTIONS │
|
||||
│ [Save Bundle Draft] [Sign Bundle] [Create Release] [Request Approval] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Reachability note:** the table explicitly shows **Hybrid/Build/Image(Dover)/Runtime** reach flags (second-class, not buried).
|
||||
|
||||
---
|
||||
|
||||
# 5) Release Control → Bundles → Bundle Detail
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** fragmented:
|
||||
|
||||
* Release row detail (not dedicated)
|
||||
* Evidence scattered under Evidence menu
|
||||
* Config (Vault/Consul) not attached as a release artifact
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Bundles → Bundle Detail`
|
||||
|
||||
* Shows: components + digests + derived versions
|
||||
* Config snapshot pointers (Vault/Consul)
|
||||
* Security posture (crit reachable, VEX coverage)
|
||||
* Evidence readiness + export
|
||||
* Buttons: create release, request approval, open findings
|
||||
|
||||
### Why changed
|
||||
|
||||
Bundle Detail is the **canonical “what is this thing?”** page used by:
|
||||
|
||||
* release managers,
|
||||
* security reviewers,
|
||||
* auditors.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
BD[Bundle Detail] --> BO[Bundle Organizer]
|
||||
BD --> REL[Create Release]
|
||||
BD --> APR[Request Approval]
|
||||
BD --> SF[Security Findings (bundle filtered)]
|
||||
BD --> VEX[VEX Hub (bundle filtered)]
|
||||
BD --> ENV[Environment Detail (where deployed)]
|
||||
BD --> EV[Evidence & Audit: Export Bundle]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ BUNDLES ▸ DETAIL: api-gateway v2.1.0 │
|
||||
│ Formerly: (N/A) This information was split across Releases + external CI/CD │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Scope: Region eu-west | Promotion: staging → production │
|
||||
│ Security: Critical reachable: 3 High reachable: 1 VEX: awaiting 2 │
|
||||
│ Data provenance: SBOM snapshot 2026-02-18T02:00Z | CVE dataset OSV OK | NVD STALE │
|
||||
│ Actions: [Edit Bundle] [Create Release] [Request Approval] [Export Evidence] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ COMPONENTS (pinned) │
|
||||
│ - api-gateway v2.1.0 digest sha256:abc... │
|
||||
│ - auth-sidecar v1.8.4 digest sha256:def... │
|
||||
│ - shared-config v4.2.1 git tag │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ CONFIG REFERENCES │
|
||||
│ Vault: kv/prod/eu-west/api-gateway/* Consul: eu-west/prod/api-gateway/* │
|
||||
│ Config diff vs previous: 7 keys changed (redacted) [View Diff] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ DEPLOYMENT FOOTPRINT │
|
||||
│ Deployed in: staging-eu (YES) prod-eu (NO) runtime inventory fresh: 54% │
|
||||
│ [Open Environment Detail] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 6) Release Control → Bundles → Repositories & Versions
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** implicit across SCM tags and container registries; StellaOps didn’t own the “digest→version lineage”.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Bundles → Repositories & Versions`
|
||||
|
||||
* Per repo:
|
||||
|
||||
* last built digests
|
||||
* derived versions
|
||||
* SBOM status + scan freshness
|
||||
* changelog anchors (tags/commits)
|
||||
* Feeds into Bundle Organizer
|
||||
|
||||
### Why changed
|
||||
|
||||
You can’t do bundle governance without a stable mapping from:
|
||||
**repo changes → artifact digest → bundle version → release approval decision**.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RV[Repositories & Versions] --> BO[Bundle Organizer]
|
||||
RV --> BD[Bundle Detail (filtered)]
|
||||
RV --> INT[Integrations: SCM/Registry/CI]
|
||||
RV --> SF[Security Findings (repo/component filtered)]
|
||||
RV --> N[Operations: Nightly Ops Report (failed scans/builds)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ BUNDLES ▸ REPOSITORIES & VERSIONS │
|
||||
│ Formerly: (N/A) Versioning lineage lived outside StellaOps │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Repo: [gateway-repo ▾] Branch: main ▾ Time: Last 30d ▾ │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Digest Derived Version Built By SBOM Fresh Crit* Notes │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ sha256:abc... v2.1.0 Jenkins <24h 3 used in prod-eu? NO │
|
||||
│ sha256:aaa... v2.0.9 Jenkins 7d 0 previous stable │
|
||||
│ Actions: [Open in Bundle Organizer] [View Changelog] [View Findings] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 7) Release Control → Releases → Releases List
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Releases` (top-level) `/releases`
|
||||
|
||||
* Listed releases with status, env, components, created, actions.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Releases → Releases List`
|
||||
|
||||
* Adds:
|
||||
|
||||
* **Region** filter and region column
|
||||
* **Bundle link** (release points to a bundle version)
|
||||
* **Security snapshot** at time of release creation (crit reachable, feed status)
|
||||
* Evidence readiness (quick indicator)
|
||||
|
||||
### Why changed
|
||||
|
||||
A release is the **execution** of promoting a **bundle** into a **region/env**—with a captured security/evidence snapshot.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RL[Releases List] --> RD[Release Detail]
|
||||
RL --> BD[Bundle Detail]
|
||||
RL --> AQ[Approvals Queue (filtered)]
|
||||
RL --> ENV[Environment Detail]
|
||||
RL --> EV[Evidence & Audit: Export Center]
|
||||
RL --> SF[Security Findings (release snapshot)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ RELEASES ▸ LIST [ + Create Release ]│
|
||||
│ Formerly: Releases (top-level) /releases │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Status ▾ Region ▾ Env ▾ Bundle ▾ Type ▾(release/hotfix) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Release Bundle Status Region Env Path Crit* Evidence │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ Hotfix 1.2.4 platform@1.2.4 DEPLOYING eu-west staging→prod 0 93% │
|
||||
│ Platform 1.3.0-rc1 platform@1.3.0 READY us-east staging→prod 1 74% │
|
||||
│ Actions: [Open] [Open Bundle] [Open Approvals] [Export Evidence] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 8) Release Control → Releases → Release Detail
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** release row “View” icon; no canonical execution page shown in the PoC.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Releases → Release Detail`
|
||||
|
||||
* Execution timeline:
|
||||
|
||||
* selected targets
|
||||
* workflow steps
|
||||
* deployment status by target
|
||||
* rollback state
|
||||
* Security snapshot at decision time (crit reachable, reach coverage)
|
||||
* Evidence snapshot (policy decision, approvals, signatures)
|
||||
* Links to Orchestrator/Scheduler when something fails
|
||||
|
||||
### Why changed
|
||||
|
||||
This is the page that explains:
|
||||
|
||||
* what happened,
|
||||
* why it was allowed,
|
||||
* and what evidence proves it.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RD[Release Detail] --> BD[Bundle Detail]
|
||||
RD --> AD[Approval Detail]
|
||||
RD --> ENV[Environment Detail]
|
||||
RD --> WF[Workflows]
|
||||
RD --> T[Targets]
|
||||
RD --> O[Operations: Orchestrator]
|
||||
RD --> S[Operations: Scheduler Runs]
|
||||
RD --> SF[Security Findings (snapshot)]
|
||||
RD --> EV[Evidence & Audit: Export Evidence Bundle]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ RELEASE DETAIL: Hotfix 1.2.4 │
|
||||
│ Formerly: Releases list → row “View” │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundle: platform@1.2.4 Region: eu-west Path: staging → production Status: DEPLOYING │
|
||||
│ Security snapshot: crit reachable=0 | reach cov=78% | feeds: OSV OK, NVD OK │
|
||||
│ Evidence snapshot: policy decision signed | approvals 2/2 | proof chain complete=YES │
|
||||
│ Actions: [Rollback] [Pause] [Export Evidence] [Open Bundle] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ TARGET EXECUTION │
|
||||
│ Target Status Workflow Step Last Update Logs │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ prod-eu-1 RUNNING Deploy → Verify 2m ago [View] │
|
||||
│ prod-eu-2 PENDING Deploy - - │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ TIMELINE │
|
||||
│ ✓ bundle resolved → ✓ policy gates → ✓ approvals → ▶ deploy(prod-eu-1) → ▢ deploy(prod-eu-2) │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 9) Release Control → Approvals → Approvals Queue
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Approvals` (top-level) `/approvals`
|
||||
Showed approval cards with policy gates, approvals count, approve/reject.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Approvals → Queue`
|
||||
|
||||
* Adds:
|
||||
|
||||
* region filter and explicit “this is blocked because crit reachable in env X”
|
||||
* **hybrid reachability** breakdown in the card (H/B/I/R)
|
||||
* explicit “data health” banner if feeds/scans stale (to prevent approving blind)
|
||||
|
||||
### Why changed
|
||||
|
||||
Approvals are where release control meets security/evidence. The queue must show:
|
||||
|
||||
* “blocked because real exploitable risk exists”
|
||||
* “blocked because we don’t have trustworthy data”
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
AQ[Approvals Queue] --> AD[Approval Detail]
|
||||
AQ --> BD[Bundle Detail]
|
||||
AQ --> SF[Security Findings (filtered)]
|
||||
AQ --> EX[Security Exceptions (filtered)]
|
||||
AQ --> N[Operations: Nightly Ops Report]
|
||||
AQ --> EV[Evidence & Audit: Proof Chain]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ APPROVALS ▸ QUEUE │
|
||||
│ Formerly: Approvals (top-level) /approvals │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Status ▾ Region ▾ Env ▾ Bundle ▾ │
|
||||
│ Banner: NVD stale → approvals may be incomplete [Open Nightly Ops Report] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ [Pending] api-gateway bundle v2.1.0 staging→prod (eu-west) Policy: PASS 1/2 Approvals: 1/2│
|
||||
│ Security: crit reachable=3 (prod-eu) Reach(H/B/I/R)=YES/NO/YES/YES VEX awaiting=2 │
|
||||
│ Actions: [View Details] [Approve] [Reject] [Request Exception] │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ [Pending] user-service bundle v3.0.0-rc1 staging→prod (us-east) Policy: BLOCK 0/2 Approvals 0/2│
|
||||
│ Block reason: Evidence incomplete (missing signed policy decision) │
|
||||
│ Actions: [View Details] [Open Evidence] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 10) Release Control → Approvals → Approval Detail
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** Approvals card “View Details” (not shown as a full audit-grade page).
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Approvals → Approval Detail`
|
||||
|
||||
* Full gate breakdown:
|
||||
|
||||
* security (crit reachable, VEX, exceptions)
|
||||
* evidence (signed decision, proofs)
|
||||
* data freshness (feeds/scans)
|
||||
* Shows “approve” rationale (captured, signed, exportable)
|
||||
|
||||
### Why changed
|
||||
|
||||
Approval is the most scrutinized action. It must produce a **defensible audit artifact**.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
AD[Approval Detail] --> BD[Bundle Detail]
|
||||
AD --> SF[Security Findings]
|
||||
AD --> EX[Exceptions]
|
||||
AD --> VEX[VEX Hub]
|
||||
AD --> EV[Evidence & Audit: Proof Chain + Export]
|
||||
AD --> N[Operations: Nightly Ops Report]
|
||||
AD --> RD[Release Detail (after approval)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ APPROVAL DETAIL: api-gateway v2.1.0 staging→prod (eu-west) │
|
||||
│ Formerly: Approvals list → card “View Details” │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Decision: PENDING Requested by: alice.johnson Age: 36d │
|
||||
│ Bundle: api-gateway v2.1.0 Target: prod-eu │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ GATES │
|
||||
│ - Security Gate: FAIL (crit reachable=3) [View Findings] [Request Exception] │
|
||||
│ - Evidence Gate: PASS (policy decision signed, proof chain complete) [Open Proof Chain] │
|
||||
│ - Data Freshness: WARN (NVD stale) [Open Nightly Ops Report] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ APPROVER ACTION │
|
||||
│ Rationale (required): _______________________________________________________________ │
|
||||
│ [Approve] [Reject] (writes signed decision + links evidence bundle) │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11) Release Control → Regions & Environments → Region Overview
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Settings → Release Control → Environments` (“Manage Environments”)
|
||||
Region concept was missing/implicit.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Regions & Environments → Region Overview`
|
||||
|
||||
* Regions are the top organizing primitive
|
||||
* Each region lists envs (dev/staging/prod) with:
|
||||
|
||||
* deployment health
|
||||
* **SBOM posture** (crit reachable counts)
|
||||
* freshness of runtime inventory
|
||||
|
||||
### Why changed
|
||||
|
||||
Promotion decisions differ by region (different runtime reality, different config sources, different agent health).
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
REG[Region Overview] --> ENV[Environment Detail]
|
||||
REG --> PROMO[Promotion Paths]
|
||||
REG --> T[Targets]
|
||||
REG --> A[Agents]
|
||||
REG --> SEC[Security Overview (region filtered)]
|
||||
REG --> OPS[Operations: Platform Health]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ REGIONS & ENVIRONMENTS ▸ REGION OVERVIEW │
|
||||
│ Formerly: Settings ▸ Release Control ▸ Environments │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Region: eu-west │
|
||||
│ Environments: │
|
||||
│ - dev-eu Deploy OK SBOM crit*=0 Runtime inventory fresh 68% [Open] │
|
||||
│ - staging-eu Deploy OK SBOM crit*=1 Runtime inventory fresh 61% [Open] │
|
||||
│ - prod-eu Deploy DEG SBOM crit*=5 Runtime inventory fresh 54% [Open] │
|
||||
│ *crit* = critical reachable (hybrid) │
|
||||
│ [Configure Promotion Paths] [Targets] [Agents] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12) Release Control → Regions & Environments → Environment Detail
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** partially under Settings/Release Control and scattered operational pages.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Regions & Environments → Environment Detail`
|
||||
|
||||
* Environment posture includes:
|
||||
|
||||
* deployment status
|
||||
* **image SBOM status**
|
||||
* reachability coverage (build/image/runtime)
|
||||
* config sources (Vault/Consul pointers used)
|
||||
* Shows “what’s running” and “what is promotable next”
|
||||
|
||||
### Why changed
|
||||
|
||||
This page must connect runtime truth (inventory) to release governance (approvals).
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
ED[Environment Detail] --> AQ[Approvals Queue (env filtered)]
|
||||
ED --> RL[Releases List (env filtered)]
|
||||
ED --> BD[Bundle Catalog (env compatible)]
|
||||
ED --> SF[Security Findings (env filtered)]
|
||||
ED --> INT[Integrations: Vault/Consul/Registry]
|
||||
ED --> AG[Agents]
|
||||
ED --> TG[Targets]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ ENVIRONMENT DETAIL: prod-eu (eu-west) │
|
||||
│ Formerly: Settings ▸ Release Control (partial) + scattered ops pages │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Deploy Health: DEGRADED | Active release: Hotfix 1.2.4 (RUNNING) │
|
||||
│ SBOM Posture: crit reachable=5 | high reachable=7 │
|
||||
│ Reachability coverage: Build 92% | Image/Dover 96% | Runtime 54% │
|
||||
│ Config sources: Vault kv/prod/eu-west/* | Consul eu-west/prod/* │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ WHAT’S RUNNING (inventory) │
|
||||
│ Service Version/Digest SBOM Fresh Crit* Reach(H/B/I/R) │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ api-gateway v2.0.9 / sha256:aaa... <24h 3 YES/NO/YES/YES │
|
||||
│ user-service v2.9.4 / sha256:bbb... 3d 0 NO/NO/NO/NO │
|
||||
│ Actions: [View Findings] [Open Bundles compatible] [Open Approvals] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13) Release Control → Regions & Environments → Promotion Paths
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** implicit in pipeline UI + Settings/Release Control environments; not region-aware.
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Regions & Environments → Promotion Paths`
|
||||
|
||||
* Configure per region:
|
||||
|
||||
* allowed paths (dev→staging→prod)
|
||||
* gates required per hop
|
||||
* required evidence set for promotion (e.g., policy decision signed)
|
||||
|
||||
### Why changed
|
||||
|
||||
Promotion rules are governance, and **regions differ**.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
PP[Promotion Paths] --> ED[Environment Detail]
|
||||
PP --> WF[Workflows]
|
||||
PP --> POL[Administration: Policy Governance]
|
||||
PP --> EXW[Administration: Exception Workflow]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ PROMOTION PATHS (eu-west) │
|
||||
│ Formerly: implicit pipeline + Settings ▸ Release Control │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Path: dev-eu → staging-eu → prod-eu │
|
||||
│ Gates per hop: │
|
||||
│ - dev→staging: SBOM scan required, evidence optional │
|
||||
│ - staging→prod: no crit reachable, VEX required for high+ reachables, signed policy decision │
|
||||
│ Workflow template: prod-deploy-v3 │
|
||||
│ [Edit] [Link Workflow] [View Policy Rules] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 14) Release Control → Delivery → Targets
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Settings → Release Control → Targets`
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Delivery → Targets`
|
||||
|
||||
* Targets are region/env scoped (prod-eu-1, prod-us-2, etc.)
|
||||
* Show target readiness and compatibility (agent health, required capabilities)
|
||||
|
||||
### Why changed
|
||||
|
||||
Targets are operational, but they determine whether a release can execute safely. Keeping them under Release Control preserves governance context.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
T[Targets] --> ED[Environment Detail]
|
||||
T --> A[Agents]
|
||||
T --> WF[Workflows]
|
||||
T --> RD[Release Detail]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ DELIVERY ▸ TARGETS │
|
||||
│ Formerly: Settings ▸ Release Control ▸ Targets │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Region ▾ Env ▾ Status ▾ │
|
||||
│ Target Region Env Agent Status Capabilities │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ prod-eu-1 eu-west prod-eu agent-eu-1 READY deploy,verify,inventory │
|
||||
│ prod-eu-2 eu-west prod-eu agent-eu-2 DEGRADED deploy │
|
||||
│ Actions: [Open] [Test] [Assign Workflow] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 15) Release Control → Delivery → Agents
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Settings → Release Control → Agents`
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Delivery → Agents`
|
||||
|
||||
* Agents are tied to targets and regions
|
||||
* Must show whether agents can also provide required **runtime inventory** signals (needed for hybrid reachability)
|
||||
|
||||
### Why changed
|
||||
|
||||
Agent health affects not only deployment but **whether your reachability and inventory data is trustworthy**.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
AG[Agents] --> T[Targets]
|
||||
AG --> ED[Environment Detail]
|
||||
AG --> OPS[Operations: Platform Health]
|
||||
AG --> N[Operations: Nightly Ops Report]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ DELIVERY ▸ AGENTS │
|
||||
│ Formerly: Settings ▸ Release Control ▸ Agents │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Agent Region Status Deploy Capable Runtime Inventory Last Seen Notes │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ agent-eu-1 eu-west OK YES YES 1m ago - │
|
||||
│ agent-eu-2 eu-west DEGRADED YES NO 2h ago inventory stuck│
|
||||
│ Actions: [Open] [Restart] [View Logs] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 16) Release Control → Delivery → Workflows
|
||||
|
||||
### Previously
|
||||
|
||||
* **Formerly:** `Settings → Release Control → Workflows`
|
||||
|
||||
### Now (Redesign)
|
||||
|
||||
* **Now:** `Release Control → Delivery → Workflows`
|
||||
|
||||
* Workflow templates include:
|
||||
|
||||
* deploy steps
|
||||
* verify steps
|
||||
* evidence capture steps (sign decisions, export proofs)
|
||||
* optional SBOM scan / rescan triggers (for hotfix)
|
||||
|
||||
### Why changed
|
||||
|
||||
Workflows enforce consistency across releases/hotpatches and ensure evidence is captured uniformly.
|
||||
|
||||
---
|
||||
|
||||
## Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
WF[Workflows] --> RD[Release Detail]
|
||||
WF --> PP[Promotion Paths]
|
||||
WF --> T[Targets]
|
||||
WF --> EV[Evidence & Audit: Proof Chains]
|
||||
WF --> OPS[Operations: Scheduler/Orchestrator]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ RELEASE CONTROL ▸ DELIVERY ▸ WORKFLOWS │
|
||||
│ Formerly: Settings ▸ Release Control ▸ Workflows │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Workflow Template: prod-deploy-v3 │
|
||||
│ Steps: │
|
||||
│ 1) Resolve bundle + config refs (Vault/Consul) │
|
||||
│ 2) Policy gates (security + evidence + data freshness) │
|
||||
│ 3) Require approvals │
|
||||
│ 4) Deploy to targets │
|
||||
│ 5) Verify (health + smoke) │
|
||||
│ 6) Capture evidence (signed decision, logs, provenance) │
|
||||
│ 7) Export bundle (optional) │
|
||||
│ [Edit] [Clone] [Assign to Promotion Path] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What stayed intact (your requirement)
|
||||
|
||||
* **Release Control is a root menu** (not grouped under Settings).
|
||||
* Security + Evidence + Operations remain separate roots; Release Control screens **link** to them where needed (findings, nightly jobs, export evidence), but do not absorb them.
|
||||
|
||||
---
|
||||
|
||||
## Next pack options (you choose with one line)
|
||||
|
||||
1. **Pack 9 — Administration (Settings)**: Identity & Access, Trust & Signing, Policy Governance, Notifications, Usage & Limits, System (with same Mermaid + ASCII + formerly/why).
|
||||
2. **Pack 10 — Integrations**: consolidate integrations + feeds under a coherent “data sources” model and show how degraded integrations bubble up into approvals/releases.
|
||||
1372
docs/modules/ui/v2-rewire/pack-09.md
Normal file
1372
docs/modules/ui/v2-rewire/pack-09.md
Normal file
File diff suppressed because it is too large
Load Diff
409
docs/modules/ui/v2-rewire/pack-10.md
Normal file
409
docs/modules/ui/v2-rewire/pack-10.md
Normal file
@@ -0,0 +1,409 @@
|
||||
## Pack 10 — Integrations + Security Data Ops (Feeds & AirGap)
|
||||
|
||||
Below is the **Mermaid IA for the menus + per-screen navigation graphs**, and then **ASCII mocks for each screen**.
|
||||
For every screen: **Formerly (old location/name)** + **why this is moved/reshaped**.
|
||||
|
||||
---
|
||||
|
||||
## 10.1 Menu graph (Mermaid) — Integrations + Feeds/AirGap Ops
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
|
||||
%% ROOT (only the parts this pack touches)
|
||||
ROOT[Stella Ops Console] --> INT[Integrations]
|
||||
ROOT --> OPS[Platform Ops]
|
||||
|
||||
%% INTEGRATIONS
|
||||
INT --> INT_HUB[Integrations Hub\n(overview + connectors)]
|
||||
INT_HUB --> INT_DETAIL[Integration Detail]
|
||||
INT_HUB --> INT_ADD[Add Integration Wizard]
|
||||
INT_HUB --> INT_FILTERS[Category Filters\nSCM / CI-CD / Registries / Secrets&Config / Notifications / Security Data]
|
||||
|
||||
%% FEEDS & AIRGAP (Platform Ops)
|
||||
OPS --> FEED_OPS[Feeds & AirGap Ops\n(Security Data Ops)]
|
||||
FEED_OPS --> FEED_SOURCES[Sources & Freshness]
|
||||
FEED_OPS --> FEED_MIRRORS[Feed Mirrors]
|
||||
FEED_OPS --> FEED_AIRGAP[AirGap Bundles]
|
||||
FEED_OPS --> FEED_LOCKS[Version Locks]
|
||||
|
||||
%% Cross-links (2nd-class entry points)
|
||||
INT_HUB -. "Degraded/Disconnected impact" .-> FEED_SOURCES
|
||||
FEED_SOURCES -. "Open connector config" .-> INT_DETAIL
|
||||
FEED_OPS -. "Shows up on Dashboard: Nightly Ops Signals" .-> ROOT
|
||||
```
|
||||
|
||||
Key placement decisions (keeps the reorg “release-first”):
|
||||
|
||||
* **Integrations** = “connectors & configuration surface” (what talks to what).
|
||||
* **Feeds & AirGap Ops** = “operator workflows & determinism controls” (mirrors, airgap bundles, version locks).
|
||||
This aligns with your ask that **freshness + sync failures are visible**, and that **determinism controls exist without being “third class.”**
|
||||
|
||||
---
|
||||
|
||||
# 10.2 Screen — Integrations Hub
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Settings → Integrations** (`/settings/integrations`)
|
||||
* Also implicitly included “Feeds” (OSV/NVD cards) here.
|
||||
|
||||
### Why change
|
||||
|
||||
* This is a **first-response triage page**: if approvals are blocked, SBOM scans are stale, or evidence generation fails, the operator needs **a single place** to see **which dependency is degraded and what it impacts**.
|
||||
* Adds a required concept: **“Impact on Release Control”** (what gates become unreliable if an integration is down).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Integrations Hub] -->|click card| B[Integration Detail]
|
||||
A -->|Add Integration| C[Add Integration Wizard]
|
||||
A -->|filter: SCM/CI/CD/Registries/Secrets/Feeds| A
|
||||
A -->|feeds degraded?| D[Feeds & AirGap Ops: Sources]
|
||||
B -->|view logs| B
|
||||
B -->|test connection| B
|
||||
B -->|back| A
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Integrations Hub (Formerly: Settings ▸ Integrations) │
|
||||
│ Org: Acme Region: All Env Scope: All Window: 30d │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Summary: Connected: 6 Degraded: 1 Disconnected: 1 Last full health check: 02:10 │
|
||||
│ │
|
||||
│ Filters: [All] [SCM] [CI/CD] [Registries] [Secrets & Config] [Notifications] [Security Data]│
|
||||
│ Actions: [+ Add Integration] [Run Health Check] │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Needs Attention (Impact on Release Control) │
|
||||
│ • NVD Feed: DISCONNECTED → CVE freshness unknown → Policy gates may be unreliable │
|
||||
│ • Jenkins: DEGRADED → Build attestations delayed → Release bundle evidence may lag │
|
||||
│ • Vault: OK (but token expires in 3d) → Env var resolution risk upcoming │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Integrations (table view) │
|
||||
│ ┌──────────────────────┬──────────────┬──────────────┬─────────────┬──────────────────────┐ │
|
||||
│ │ Name │ Type │ Status │ Last Sync │ Used By │ │
|
||||
│ ├──────────────────────┼──────────────┼──────────────┼─────────────┼──────────────────────┤ │
|
||||
│ │ GitHub Enterprise │ SCM │ CONNECTED │ 5m ago │ Bundles, Changelog │ │
|
||||
│ │ GitLab SaaS │ SCM │ CONNECTED │ 2m ago │ Bundles, Changelog │ │
|
||||
│ │ Jenkins │ CI/CD │ DEGRADED │ 1h ago │ Attestations, Builds │ │
|
||||
│ │ Harbor Registry │ Registry │ CONNECTED │ 30m ago │ SBOM ingest, Images │ │
|
||||
│ │ HashiCorp Vault │ Secrets │ CONNECTED │ 10m ago │ Env vars, Bundles │ │
|
||||
│ │ Slack │ Notification │ CONNECTED │ - │ Approvals alerts │ │
|
||||
│ │ OSV Feed │ SecurityData │ CONNECTED │ 1h ago │ Vulnerability scans │ │
|
||||
│ │ NVD Feed │ SecurityData │ DISCONNECTED │ - │ Vulnerability scans │ │
|
||||
│ └──────────────────────┴──────────────┴──────────────┴─────────────┴──────────────────────┘ │
|
||||
│ Hint: click any row/card → Integration Detail │
|
||||
└────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 10.3 Screen — Integration Detail
|
||||
|
||||
### Formerly
|
||||
|
||||
* No dedicated “detail” surface in the screenshots (integrations were mostly **cards**).
|
||||
This is effectively **new**, but replaces the need to “hunt” across settings + ops pages.
|
||||
|
||||
### Why change
|
||||
|
||||
* You need **traceability** from an outage → **which releases / gates / bundles / envs are impacted**.
|
||||
* Enables the missing operational requirement you called out: **nightly job failures due to integration issues** are explainable from the integration itself.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Integration Detail] --> B[Config & Credentials]
|
||||
A --> C[Health & Logs]
|
||||
A --> D[Mappings]
|
||||
A --> E[Permissions/Scopes]
|
||||
A --> F[Downstream Impact]
|
||||
C -->|retry connection| C
|
||||
C -->|open affected jobs| G[Nightly Ops Report (Platform Ops)]
|
||||
A -->|back| H[Integrations Hub]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Integration Detail: NVD Feed (Formerly: shown as card in Settings ▸ Integrations) │
|
||||
│ Type: Security Data Source Status: DISCONNECTED Owner: security-team │
|
||||
│ Region: US-East (toggle) EU-West (toggle) APAC (toggle) │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Overview] [Config] [Health & Logs] [Mappings] [Permissions] │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Overview │
|
||||
│ Last successful sync: — │
|
||||
│ Freshness SLA: 6h Current freshness: UNKNOWN → Gating risk: HIGH │
|
||||
│ Used by: Vulnerability scan ingestion, Release gates, Nightly rescans │
|
||||
│ │
|
||||
│ Downstream impact │
|
||||
│ • Approvals & Gates: “CVE freshness” gate → currently degraded │
|
||||
│ • Nightly SBOM rescan: will flag “data source unavailable” │
|
||||
│ • Audit bundles: will include “feed freshness unknown” note │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Health & Logs (latest) │
|
||||
│ 02:11 ERROR connect timeout to nvd.example.gov │
|
||||
│ 02:11 WARN falling back to OSV only (coverage reduced) │
|
||||
│ Action: [Retry Connection] [Test DNS] [View Related Nightly Jobs] │
|
||||
└────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 10.4 Screen — Add Integration Wizard
|
||||
|
||||
### Formerly
|
||||
|
||||
* **“+ Add Integration”** existed on Settings → Integrations, but without a standardized “impact/mapping” workflow shown.
|
||||
|
||||
### Why change
|
||||
|
||||
* This wizard becomes the enforcement point for:
|
||||
|
||||
* **Region scoping** (your missing “environments per region” theme).
|
||||
* **Mapping to downstream use** (Release Bundle Organizer, approvals, SBOM ingest, etc.).
|
||||
* **Secrets hygiene** (Vault/Consul integration must be wired correctly).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
S[Add Integration Wizard] --> A[1. Choose Type]
|
||||
A --> B[2. Configure Connection]
|
||||
B --> C[3. Scope & Mapping\n(Region/Env/Repos/Targets)]
|
||||
C --> D[4. Test Connection]
|
||||
D --> E[5. Save & Initial Sync]
|
||||
E --> F[Integration Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Add Integration Wizard (Formerly: + Add Integration on Settings ▸ Integrations) │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Step 1/5 — Choose type │
|
||||
│ [SCM] GitHub / GitLab │
|
||||
│ [CI/CD] Jenkins / Actions │
|
||||
│ [Registry] Harbor / ECR / GCR │
|
||||
│ [Secrets] Vault │
|
||||
│ [Config] Consul (recommended for bundle vars) │
|
||||
│ [Notifications] Slack / Email / Webhook │
|
||||
│ [Security Data] OSV / NVD / CISA │
|
||||
│ │
|
||||
│ Next: [Continue] │
|
||||
└────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 10.5 Screen — Feeds & AirGap Ops (Sources & Freshness)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Operations → Feeds** (`/operations/feeds`)
|
||||
Screen title: **“Feed Mirror & AirGap Operations”**
|
||||
* Also partially represented as OSV/NVD “Feeds” cards under Settings → Integrations.
|
||||
|
||||
### Why change
|
||||
|
||||
* This becomes the **operator-grade control surface** for:
|
||||
|
||||
* **Freshness** (are CVE sources synced, within SLA?).
|
||||
* **Determinism** (version locks).
|
||||
* **AirGap readiness** (bundles).
|
||||
* It is “second-class” (reachable from Dashboard “Nightly Ops Signals”), not buried.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Feeds & AirGap Ops] --> B[Sources & Freshness]
|
||||
A --> C[Feed Mirrors]
|
||||
A --> D[AirGap Bundles]
|
||||
A --> E[Version Locks]
|
||||
B -->|open source integration| F[Integration Detail]
|
||||
B -->|create mirror| C
|
||||
E -->|lock for release| G[Release Detail\n(Determinism tab)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Feeds & AirGap Ops (Formerly: Operations ▸ Feeds → "Feed Mirror & AirGap Operations") │
|
||||
│ Org: Acme Region: US-East Window: 7d │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Sources & Freshness] [Feed Mirrors] [AirGap Bundles] [Version Locks] │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Sources & Freshness │
|
||||
│ ┌───────────────┬──────────────┬───────────────┬──────────────┬───────────────────────────┐ │
|
||||
│ │ Source │ Status │ Last Sync │ Freshness SLA │ Notes / Impact │ │
|
||||
│ ├───────────────┼──────────────┼───────────────┼──────────────┼───────────────────────────┤ │
|
||||
│ │ OSV │ OK │ 1h ago │ 6h │ Full OK │ │
|
||||
│ │ NVD │ DISCONNECTED │ — │ 6h │ Approval gating risk HIGH │ │
|
||||
│ │ CISA KEV │ OK │ 3h ago │ 24h │ OK │ │
|
||||
│ └───────────────┴──────────────┴───────────────┴──────────────┴───────────────────────────┘ │
|
||||
│ Actions: [Retry failed sources] [Open Integration Detail] [Create Mirror] │
|
||||
└────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 10.6 Screen — Feeds & AirGap Ops (Feed Mirrors)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Operations → Feeds → **Feed Mirrors** tab.
|
||||
|
||||
### Why change
|
||||
|
||||
* Keep same capability, but add:
|
||||
|
||||
* Region scoping and storage accounting per region.
|
||||
* A clear connection to **gating data freshness** and **nightly job health**.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Feed Mirrors] --> B[Create/Edit Mirror]
|
||||
A --> C[Mirror Detail]
|
||||
C -->|force sync| C
|
||||
C -->|view sync logs| C
|
||||
A -->|back| D[Feeds & AirGap Ops]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Feeds & AirGap Ops ▸ Feed Mirrors (Formerly: Operations ▸ Feeds ▸ Feed Mirrors) │
|
||||
│ Region: EU-West │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ KPI: Total Mirrors: 4 Synced: 3 Stale: 1 Errors: 0 Storage: 28GB │
|
||||
│ Actions: [+ Create Mirror] [Sync All] [Export Mirror Config] │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Mirrors │
|
||||
│ ┌───────────────┬──────────┬───────────────┬───────────┬───────────┬──────────────────────┐ │
|
||||
│ │ Mirror Name │ Source │ Status │ Last Sync │ Storage │ Actions │ │
|
||||
│ ├───────────────┼──────────┼───────────────┼───────────┼───────────┼──────────────────────┤ │
|
||||
│ │ nvd-eu-mirror │ NVD │ STALE (8h) │ 8h ago │ 12GB │ [Sync] [Edit] [Logs] │ │
|
||||
│ │ osv-eu-mirror │ OSV │ SYNCED │ 1h ago │ 4GB │ [Sync] [Edit] [Logs] │ │
|
||||
│ │ kev-eu-mirror │ CISA KEV │ SYNCED │ 3h ago │ 1GB │ [Sync] [Edit] [Logs] │ │
|
||||
│ └───────────────┴──────────┴───────────────┴───────────┴───────────┴──────────────────────┘ │
|
||||
└────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 10.7 Screen — Feeds & AirGap Ops (AirGap Bundles)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Operations → Feeds → **AirGap Bundles** tab.
|
||||
|
||||
### Why change
|
||||
|
||||
* This is essential for environments that must prove:
|
||||
|
||||
* The release decision was made using a **known dataset snapshot**.
|
||||
* The bundle contains **feeds + policy pack versions + evidence tooling metadata**.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[AirGap Bundles] --> B[Create AirGap Bundle]
|
||||
A --> C[Bundle Detail]
|
||||
C -->|download| C
|
||||
C -->|verify signatures| C
|
||||
C -->|pin version locks| D[Version Locks]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Feeds & AirGap Ops ▸ AirGap Bundles (Formerly: Operations ▸ Feeds ▸ AirGap Bundles) │
|
||||
│ Region: APAC │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Actions: [+ Create Bundle] [Download latest] [Verify bundle] │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundles │
|
||||
│ ┌───────────────────┬───────────┬──────────────┬───────────────┬──────────────────────────┐ │
|
||||
│ │ Bundle Name │ Target Env│ Contents │ Built At │ Actions │ │
|
||||
│ ├───────────────────┼───────────┼──────────────┼───────────────┼──────────────────────────┤ │
|
||||
│ │ apac-prod-2026-02- │ Prod │ OSV+NVD+KEV │ 2026-02-18 02: │ [Download] [Verify] │ │
|
||||
│ │ apac-uat-2026-02- │ UAT │ OSV+KEV │ 2026-02-17 02: │ [Download] [Verify] │ │
|
||||
│ └───────────────────┴───────────┴──────────────┴───────────────┴──────────────────────────┘ │
|
||||
│ Notes: Bundle embeds version locks + signing metadata for audit. │
|
||||
└────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 10.8 Screen — Feeds & AirGap Ops (Version Locks)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Operations → Feeds → **Version Locks** tab.
|
||||
|
||||
### Why change
|
||||
|
||||
* Version locks are the core of **reproducible gating**:
|
||||
|
||||
* “This approval used NVD snapshot X, OSV snapshot Y.”
|
||||
* Essential for external audits and internal replay/verify.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Version Locks] --> B[Create Lock]
|
||||
A --> C[Lock Detail]
|
||||
A --> D[Apply Lock to Region/Env]
|
||||
A --> E[Apply Lock to Release]
|
||||
E --> F[Release Detail\nDeterminism tab]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Feeds & AirGap Ops ▸ Version Locks (Formerly: Operations ▸ Feeds ▸ Version Locks) │
|
||||
│ Region: US-East │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Actions: [+ Create Version Lock] [Apply to Release] [Apply to Env] │
|
||||
├────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Locks │
|
||||
│ ┌───────────────┬───────────────┬───────────────┬──────────────────────┬───────────────────┐ │
|
||||
│ │ Lock ID │ Sources │ Created │ Scope │ Actions │ │
|
||||
│ ├───────────────┼───────────────┼───────────────┼──────────────────────┼───────────────────┤ │
|
||||
│ │ lock-2026-02-18│ NVD, OSV, KEV │ 2026-02-18 │ US-East / Prod │ [View] [Apply] │ │
|
||||
│ │ lock-2026-02-17│ OSV, KEV │ 2026-02-17 │ APAC / UAT │ [View] [Apply] │ │
|
||||
│ └───────────────┴───────────────┴───────────────┴──────────────────────┴───────────────────┘ │
|
||||
│ Audit note: locks are referenced in Evidence Bundles + Replay/Verify. │
|
||||
└────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What changed vs the *previous* draft (to keep the reorg intact)
|
||||
|
||||
* I’m keeping **Integrations Hub** under **Integrations** (configuration + dependency map).
|
||||
* I’m placing **Feeds & AirGap Ops** under **Platform Ops** (operator workflows + determinism tooling), but it remains **second-class** because:
|
||||
|
||||
* It’s linked from **Integrations Hub** (source issues → ops controls),
|
||||
* and it should be linked from the **Dashboard “Nightly Ops Signals”** card.
|
||||
|
||||
---
|
||||
|
||||
If you want, I can do **Pack 11** next for the remaining “Settings-class” pages you attached (Usage & Limits, Notifications, Identity & Access, Trust & Signing, System) but **in the new IA**, with the same: **Mermaid menu + per-screen graphs + ASCII mocks + Formerly/Why**.
|
||||
642
docs/modules/ui/v2-rewire/pack-11.md
Normal file
642
docs/modules/ui/v2-rewire/pack-11.md
Normal file
@@ -0,0 +1,642 @@
|
||||
## Pack 11 — Release Control (root) + Governance + Admin (IAM/Notifications/Usage) + System + Trust & Signing
|
||||
|
||||
This pack converts the *remaining “Settings” pages* into the **release-first Stella Ops IA**, adds the **missing region-first environment model**, and makes **governance + determinism** explicit (aligned with Stella’s stated focus on digest-first release identity, evidence, reachability/hybrid reachability, and audit exports). ([Stella Ops Suite][1])
|
||||
|
||||
---
|
||||
|
||||
# 11.1 Menu graph (Mermaid) — the menus touched in this pack
|
||||
|
||||
> NOTE: This is a **partial root graph** (only the menus we’re redesigning here). It preserves your “main reorg” (release-first), keeps **Release Control as a root menu**, and moves “Settings” items into **Admin / System / Evidence Trust** where they belong.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
|
||||
ROOT[Stella Ops Console] --> RC[Release Control (ROOT)]
|
||||
ROOT --> ADM[Administration]
|
||||
ROOT --> SYS[System (Platform)]
|
||||
ROOT --> EVID[Evidence]
|
||||
ROOT --> INT[Integrations]
|
||||
|
||||
%% RELEASE CONTROL
|
||||
RC --> RC_HOME[Release Control Home]
|
||||
RC --> RC_REG[Regions & Environments]
|
||||
RC --> RC_TARGETS[Deployment Targets]
|
||||
RC --> RC_AGENTS[Agents]
|
||||
RC --> RC_WF[Workflows]
|
||||
RC --> RC_GOV[Governance\n(Policy, Gates, Simulation, Exception Workflow)]
|
||||
RC_REG --> RC_ENV[Environment Detail]
|
||||
|
||||
%% ADMIN
|
||||
ADM --> IAM[Identity & Access]
|
||||
ADM --> NOTIF[Notifications]
|
||||
ADM --> LIMITS[Usage & Limits]
|
||||
ADM --> BRAND[Tenants & Branding]
|
||||
|
||||
%% SYSTEM
|
||||
SYS --> SYS_HOME[System Console\n(Health, Doctor, SLO, Jobs)]
|
||||
SYS_HOME --> JOBS[Background Jobs]
|
||||
SYS_HOME --> HEALTH[Health Check Detail]
|
||||
|
||||
%% EVIDENCE / TRUST
|
||||
EVID --> TRUST[Trust & Signing]
|
||||
TRUST --> KEYS[Signing Keys]
|
||||
TRUST --> ISSUERS[Issuers]
|
||||
TRUST --> CERTS[Certificates]
|
||||
TRUST --> REKOR[Transparency Log]
|
||||
TRUST --> SCORE[Trust Scoring]
|
||||
TRUST --> AUDIT[Audit Log]
|
||||
|
||||
%% CROSS LINKS (2nd-class, not buried)
|
||||
RC_ENV -. "Vault/Consul inputs" .-> INT
|
||||
JOBS -. "Feed sync failures" .-> INT
|
||||
RC_GOV -. "Exception workflow uses Security Exceptions" .-> ROOT
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.2 Screen — Release Control Home
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Settings → Release Control** (`/settings/release-control`)
|
||||
(cards: Environments, Targets, Agents, Workflows)
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* Stella is explicitly **release-governance centric** (promotion graphs, digest-first identity, deterministic decision records). ([Gitea: Git with a cup of tea][2])
|
||||
* So “Release Control” must be **ROOT** (operator-facing), not buried under Settings.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Release Control Home] --> B[Regions & Environments]
|
||||
A --> C[Deployment Targets]
|
||||
A --> D[Agents]
|
||||
A --> E[Workflows]
|
||||
A --> F[Governance Hub]
|
||||
A --> G[Integrations Hub]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Release Control (ROOT) │
|
||||
│ Legacy: Settings ▸ Release Control (/settings/release-control) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Purpose: configure how releases are promoted + executed across regions/envs (digest-first). │
|
||||
│ Region scope: [All] US-East EU-West APAC Env types: Dev/QA/Staging/Prod │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Quick Links │
|
||||
│ [Regions & Environments] [Targets] [Agents] [Workflows] [Governance] │
|
||||
│ │
|
||||
│ Attention (release-impacting drift) │
|
||||
│ • EU-West Prod: env variables source missing (Consul mapping not configured) │
|
||||
│ • US-East Stage: agent offline → promotions will stall │
|
||||
│ • Policy baseline “Prod” updated yesterday → 2 approvals will replay under new baseline │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.3 Screen — Regions & Environments
|
||||
|
||||
### Formerly
|
||||
|
||||
* Accessed via **Settings → Release Control → Manage Environments** (button from the card)
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* You called out a missing core: **environments must be organized per region**.
|
||||
* Stella’s model is “what is deployed where” must be unambiguous; region-first is required for that clarity. ([Gitea: Git with a cup of tea][2])
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Regions & Environments] --> B[Region Detail]
|
||||
B --> C[Environment Detail]
|
||||
A --> D[Create Region]
|
||||
B --> E[Create Environment]
|
||||
C --> F[Promotion Graph]
|
||||
C --> G[Env Inputs (Vault/Consul)]
|
||||
C --> H[Env SBOM & Findings Summary]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Regions & Environments │
|
||||
│ Legacy: Settings ▸ Release Control ▸ Environments (Manage Environments) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Regions: [ + Create Region ] │
|
||||
│ │
|
||||
│ ┌───────────────────────┬───────────────┬───────────┬──────────────────────────────────────┐ │
|
||||
│ │ Region │ Environments │ Agents OK │ Release Health Summary │ │
|
||||
│ ├───────────────────────┼───────────────┼───────────┼──────────────────────────────────────┤ │
|
||||
│ │ US-East │ 6 (2 prod) │ 5/6 │ 1 env w/ critical reachable findings │ │
|
||||
│ │ EU-West │ 4 (1 prod) │ 4/4 │ clean │ │
|
||||
│ │ APAC │ 3 (1 prod) │ 3/3 │ feeds stale → gating risk medium │ │
|
||||
│ └───────────────────────┴───────────────┴───────────┴──────────────────────────────────────┘ │
|
||||
│ Click a region → Region Detail │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.4 Screen — Region Detail
|
||||
|
||||
### Formerly
|
||||
|
||||
* Not present as a first-class concept (regions missing; envs likely flat)
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* Region is the natural unit for:
|
||||
|
||||
* feed freshness / mirror selection,
|
||||
* deployment agents & targets,
|
||||
* environment variables sources (Vault/Consul partitioning).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Region Detail] --> B[Environment Detail]
|
||||
A --> C[Region Agents]
|
||||
A --> D[Region Feeds Freshness]
|
||||
A --> E[Region Targets]
|
||||
A --> F[Region Defaults\n(policy baseline, locks, inputs)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Region: US-East │
|
||||
│ Legacy: (new) — previously environments were not region-first │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Defaults: Policy Baseline = Prod-US-East Feed Lock = lock-2026-02-18 Vars = Vault+Consul │
|
||||
│ │
|
||||
│ Environments │
|
||||
│ ┌───────────────┬──────────────┬───────────────┬─────────────────────┬──────────────────────┐│
|
||||
│ │ Env │ Type │ Promotion Path │ SBOM/Security Status │ Agent/Target ││
|
||||
│ ├───────────────┼──────────────┼───────────────┼─────────────────────┼──────────────────────┤│
|
||||
│ │ us-dev │ Dev │ — │ informational only │ agent-01 / docker-01 ││
|
||||
│ │ us-stage │ Staging │ dev→stage │ 2 high (not reachable)│ agent-02 / docker-02 ││
|
||||
│ │ us-prod │ Production │ stage→prod │ 1 critical reachable │ agent-03 / docker-03 ││
|
||||
│ └───────────────┴──────────────┴───────────────┴─────────────────────┴──────────────────────┘│
|
||||
│ Links: [Feeds Freshness] [Agents] [Targets] [Region Defaults] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.5 Screen — Environment Detail (Config + Status summary)
|
||||
|
||||
### Formerly
|
||||
|
||||
* “Environment” concept appeared on **Control Plane / Releases / Approvals** pages, but
|
||||
* no dedicated region-first “env detail” with **SBOM + reachability + runtime proof** surfaced.
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* Stella’s promise includes **reachability and hybrid reachability evidence**. ([Gitea: Git with a cup of tea][2])
|
||||
* Environment is where hybrid reachability becomes meaningful:
|
||||
|
||||
* **Image reachability** (static),
|
||||
* **Build reachability** (build-time evidence),
|
||||
* **Runtime reachability** (environment traces).
|
||||
* This must be **second-class** (tabs/sections), not buried.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Environment Detail] --> B[Overview]
|
||||
A --> C[Promotion Rules]
|
||||
A --> D[Inputs\n(Vault/Consul mappings)]
|
||||
A --> E[SBOM & Findings Summary]
|
||||
A --> F[Reachability Coverage\n(image/build/runtime)]
|
||||
A --> G[Targets & Agents]
|
||||
A --> H[Audit Trail\n(decisions affecting env)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Environment: us-prod (Region: US-East) │
|
||||
│ Legacy: part of Settings ▸ Release Control ▸ Environments / scattered across Control Plane │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Overview] [Promotion] [Inputs] [SBOM & Findings] [Reachability] [Targets/Agents] [Audit]│
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Overview │
|
||||
│ Current deployed bundle: bundle-us-prod-2026.02.18-01 │
|
||||
│ Current deployed digests: 14 images (13 known scanned / 1 pending scan) │
|
||||
│ │
|
||||
│ Security summary (last 24h) │
|
||||
│ Critical reachable: 1 | High reachable: 0 | High not reachable: 3 | VEX coverage: 62% │
|
||||
│ “Why?” links → open Finding set filtered to env + reachability class │
|
||||
│ │
|
||||
│ Hybrid reachability coverage (2nd-class, but visible here) │
|
||||
│ Image evidence: 100% | Build evidence: 78% | Runtime evidence: 35% │
|
||||
│ Gap: runtime traces missing on 9 services → enable agent trace hook / importer │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.6 Screen — Deployment Targets
|
||||
|
||||
### Formerly
|
||||
|
||||
* Settings → Release Control → **Manage Targets**
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* Targets are release execution primitives (where things get deployed).
|
||||
* Putting them under Release Control keeps “release execution” in the same domain as “release governance”.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Targets] --> B[Target Detail]
|
||||
A --> C[Create Target]
|
||||
B --> D[Test Connection]
|
||||
B --> E[Assigned Environments]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Deployment Targets │
|
||||
│ Legacy: Settings ▸ Release Control ▸ Targets (Manage Targets) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Region: [All] US-East EU-West APAC Type: [Docker Hosts] [VM Groups] [Baremetal] │
|
||||
│ Actions: [+ Create Target] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌───────────────┬───────────┬─────────────┬──────────────┬─────────────────────────────────┐│
|
||||
│ │ Target │ Region │ Status │ Last Check │ Used by Environments ││
|
||||
│ ├───────────────┼───────────┼─────────────┼──────────────┼─────────────────────────────────┤│
|
||||
│ │ docker-us-03 │ US-East │ HEALTHY │ 2m ago │ us-prod, us-stage ││
|
||||
│ │ docker-eu-01 │ EU-West │ HEALTHY │ 3m ago │ eu-prod ││
|
||||
│ │ docker-apac-02 │ APAC │ DEGRADED │ 12m ago │ apac-uat ││
|
||||
│ └───────────────┴───────────┴─────────────┴──────────────┴─────────────────────────────────┘│
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.7 Screen — Agents
|
||||
|
||||
### Formerly
|
||||
|
||||
* Settings → Release Control → **Manage Agents**
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* Agents are needed for:
|
||||
|
||||
* deployment execution,
|
||||
* optional runtime evidence collection (hybrid reachability),
|
||||
* replay/verify hooks.
|
||||
* Keeping them here keeps the “control plane” coherent with Stella’s evidence and reachability focus. ([Gitea: Git with a cup of tea][2])
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Agents] --> B[Agent Detail]
|
||||
B --> C[Capabilities\n(deploy, trace, attest)]
|
||||
B --> D[Assigned Targets/Envs]
|
||||
B --> E[Health Logs]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Agents │
|
||||
│ Legacy: Settings ▸ Release Control ▸ Agents (Manage Agents) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌───────────────┬───────────┬─────────────┬─────────────────────┬──────────────────────────┐│
|
||||
│ │ Agent │ Region │ Status │ Capabilities │ Assigned ││
|
||||
│ ├───────────────┼───────────┼─────────────┼─────────────────────┼──────────────────────────┤│
|
||||
│ │ agent-03 │ US-East │ HEALTHY │ deploy, attest, trace│ us-prod ││
|
||||
│ │ agent-02 │ US-East │ HEALTHY │ deploy, attest │ us-stage ││
|
||||
│ │ agent-apac-01 │ APAC │ DEGRADED │ deploy │ apac-uat ││
|
||||
│ └───────────────┴───────────┴─────────────┴─────────────────────┴──────────────────────────┘│
|
||||
│ Note: Trace capability drives “runtime reachability coverage” on env detail. │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.8 Screen — Workflows
|
||||
|
||||
### Formerly
|
||||
|
||||
* Settings → Release Control → **Edit Workflows**
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* Workflows are the **standardized release execution templates** (canary, A/B, rollback) that Stella highlights as part of release governance and controlled rollout. ([Stella Ops Suite][1])
|
||||
* This becomes the canonical place to manage them.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Workflows] --> B[Workflow Editor]
|
||||
B --> C[Validate Workflow]
|
||||
B --> D[Publish Version]
|
||||
B --> E[Used by Releases/Policies]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Workflows │
|
||||
│ Legacy: Settings ▸ Release Control ▸ Workflows (Edit Workflows) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌──────────────────────┬───────────────┬──────────┬────────────────────────────────────────┐ │
|
||||
│ │ Workflow │ Version │ Status │ Used by │ │
|
||||
│ ├──────────────────────┼───────────────┼──────────┼────────────────────────────────────────┤ │
|
||||
│ │ Rolling Update │ v3 │ ACTIVE │ default │ │
|
||||
│ │ Canary 10% → 50% → 100│ v2 │ ACTIVE │ prod baselines │ │
|
||||
│ │ Fast Rollback │ v1 │ ACTIVE │ incident response │ │
|
||||
│ └──────────────────────┴───────────────┴──────────┴────────────────────────────────────────┘ │
|
||||
│ Actions: [Create] [Edit] [Validate] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.9 Screen — Governance Hub (Policy baselines, gate rules, simulation, exception workflow)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Settings → Policy Governance** (`/settings/policy`)
|
||||
|
||||
* Policy Baselines
|
||||
* Governance Rules
|
||||
* Policy Simulation
|
||||
* Exception Workflow
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* Governance is not “settings”; it is **core Release Control**:
|
||||
|
||||
* policy-as-code evaluation with traceable outcomes (“why blocked?”) and replayability is a stated Stella deliverable. ([Gitea: Git with a cup of tea][2])
|
||||
* So it becomes: **Release Control → Governance** (still admin-controlled, but release-centric).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Governance Hub] --> B[Policy Baselines]
|
||||
A --> C[Gate Rules]
|
||||
A --> D[Policy Simulation]
|
||||
A --> E[Exception Workflow Config]
|
||||
C --> F[Gate Detail\n(why blocked trace model)]
|
||||
E --> G[Security Exceptions\n(request/approve)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Release Control ▸ Governance │
|
||||
│ Legacy: Settings ▸ Policy Governance (/settings/policy) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Cards │
|
||||
│ [Policy Baselines] [Gate Rules] [Policy Simulation] [Exception Workflow] │
|
||||
│ │
|
||||
│ Recent governance changes (audit-relevant) │
|
||||
│ • Prod baseline updated: CVE freshness gate now “hard block” │
|
||||
│ • Exception workflow: requires 2 approvers for critical reachable │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.10 Screen — Identity & Access
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Settings → Identity & Access** (`/settings/admin`)
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* This is classic administrative scope: users, roles, API keys, OAuth clients, tenants.
|
||||
* Move under **Administration**, not in release/security menus.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Identity & Access] --> B[Users]
|
||||
A --> C[Roles]
|
||||
A --> D[OAuth Clients]
|
||||
A --> E[API Tokens]
|
||||
A --> F[Tenants]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Administration ▸ Identity & Access │
|
||||
│ Legacy: Settings ▸ Identity & Access (/settings/admin) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Users] [Roles] [OAuth Clients] [API Tokens] [Tenants] │
|
||||
│ Banner: failures here can block approvals + evidence signing (auth). │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.11 Screen — Notifications
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Settings → Notifications** (`/settings/notifications`)
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* Also admin scope.
|
||||
* But must support release-centric alerting: approvals waiting, feed stale, scan failed, evidence export ready.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Notifications] --> B[Rules]
|
||||
A --> C[Channels]
|
||||
A --> D[Templates]
|
||||
A --> E[Delivery Log]
|
||||
B --> F[Rule Detail\n(event→recipients)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Administration ▸ Notifications │
|
||||
│ Legacy: Settings ▸ Notifications (/settings/notifications) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Rules (event triggers) Channels Templates │
|
||||
│ - approval.pending → #release-approvals - Email: Active - Approval request │
|
||||
│ - feed.stale → #sec-ops - Slack: Active - Feed stale alert │
|
||||
│ - scan.failed → #build-cops - Webhook: Not configured - Scan failure │
|
||||
│ - evidence.ready → email auditors │
|
||||
│ [View Delivery Log] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.12 Screen — Usage & Limits
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Settings → Usage & Limits** (`/settings/usage`)
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* This is tenant/admin entitlement + limit configuration.
|
||||
* Keep operational usage charts accessible, but do **quota enforcement config** here; operational throttles remain in **Platform Ops → Quotas**.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Usage & Limits] --> B[Entitlements Summary]
|
||||
A --> C[Quota Configuration]
|
||||
A --> D[Usage Reports]
|
||||
A --> E[Throttle Events Link\n(to Ops Quotas)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Administration ▸ Usage & Limits │
|
||||
│ Legacy: Settings ▸ Usage & Limits (/settings/usage) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ This month: Scans 6,500/10,000 Storage 42/100 GB Evidence Packets 2,800/10,000 │
|
||||
│ API Requests 15,000/100,000 │
|
||||
│ │
|
||||
│ [Configure Quotas] [Export Usage Report] Link: [View Operational Throttles (Ops ▸ Quotas)]│
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.13 Screen — System Console (Health / Doctor / SLO / Background Jobs)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Settings → System** (`/settings/system`)
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* System health + background jobs directly explain:
|
||||
|
||||
* “why are feeds stale?”
|
||||
* “why are rescans failing?”
|
||||
* “why are evidence exports missing?”
|
||||
* That’s operational, not “settings”. It becomes **System (Platform)**, reachable as root and also second-class from the Dashboard “Nightly Ops Signals”.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[System Console] --> B[Health Check Detail]
|
||||
A --> C[Doctor]
|
||||
A --> D[SLO Monitoring]
|
||||
A --> E[Background Jobs]
|
||||
E --> F[Nightly Ops Report\n(job failures → impacts)]
|
||||
E --> G[Dead Letter Queue]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ System (Platform) │
|
||||
│ Legacy: Settings ▸ System (/settings/system) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Health Check: ● All systems operational [View Details] │
|
||||
│ Doctor: [Run Doctor] SLO Monitoring: [View SLOs] │
|
||||
│ Background Jobs: [View Jobs] │
|
||||
│ │
|
||||
│ Operator note: job failures here must surface on Dashboard + block/reduce confidence in gates. │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 11.14 Screen — Trust & Signing
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Settings → Trust & Signing** (`/settings/trust`)
|
||||
|
||||
### Why moved / reshaped
|
||||
|
||||
* This is the cryptographic and issuer-trust foundation for:
|
||||
|
||||
* DSSE evidence, attestations,
|
||||
* issuer trust/conflict resolution for VEX,
|
||||
* transparency logs.
|
||||
* Those belong under **Evidence → Trust & Signing**, consistent with Stella’s emphasis on verifiability and audit export. ([Gitea: Git with a cup of tea][2])
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Trust & Signing] --> B[Signing Keys]
|
||||
A --> C[Issuers]
|
||||
A --> D[Certificates]
|
||||
A --> E[Transparency Log]
|
||||
A --> F[Trust Scoring]
|
||||
A --> G[Audit Log]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Evidence ▸ Trust & Signing │
|
||||
│ Legacy: Settings ▸ Trust & Signing (/settings/trust) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Modules │
|
||||
│ [Signing Keys] [Issuers] [Certificates] [Transparency Log] [Trust Scoring] [Audit Log] │
|
||||
│ │
|
||||
│ Why here: this config affects evidence packets, attestations, issuer trust, and audits. │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What I did NOT include yet (next pack)
|
||||
|
||||
You explicitly flagged **Release Bundle Organizer** as crucial. It needs its own pack because it’s not a single screen—it’s a workflow:
|
||||
|
||||
* Bundle catalog (per repo / per product line),
|
||||
* Bundle compose (digests → service versions),
|
||||
* Env-var resolution (Vault + Consul mappings per env/region),
|
||||
* Bundle changelog (per repository),
|
||||
* Bundle → Release promotion linkage.
|
||||
|
||||
If you say “continue”, **Pack 12** will be *only* the Bundle Organizer: full Mermaid graphs + ASCII mocks + “formerly/why” (it’s mostly net-new).
|
||||
|
||||
[1]: https://stella-ops.org/license/?utm_source=chatgpt.com "License & Fork-Friendly Governance - Stella Ops Suite"
|
||||
[2]: https://git.stella-ops.org/stella-ops.org/git.stella-ops.org?utm_source=chatgpt.com "stella-ops.org/git.stella-ops.org - Stella Ops Suite"
|
||||
728
docs/modules/ui/v2-rewire/pack-12.md
Normal file
728
docs/modules/ui/v2-rewire/pack-12.md
Normal file
@@ -0,0 +1,728 @@
|
||||
## Pack 12 — Release Bundle Organizer (Bundles, Bundle Versions, Component Versions, Config + Changelog per Repo)
|
||||
|
||||
This pack adds the missing **Release Bundle Organizer** while keeping your **release-first / digest-first** restructuring intact, and wiring it into **Release Control (regions/envs/inputs)** + **Approvals** + **Evidence** + **Operations (AirGap)**.
|
||||
|
||||
---
|
||||
|
||||
# 12.1 Menu graph (Mermaid) — where Bundle Organizer lives in the redesigned IA
|
||||
|
||||
> Scope: *only the parts relevant to bundles*. This keeps **Release Control** as a root menu (per your instruction) and makes **Bundles** a first-class part of **Releases**, not buried.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
|
||||
ROOT[Stella Ops Console] --> DASH[Dashboard]
|
||||
ROOT --> REL[Releases]
|
||||
ROOT --> APPR[Approvals]
|
||||
ROOT --> SEC[Security]
|
||||
ROOT --> EVID[Evidence]
|
||||
ROOT --> OPS[Operations]
|
||||
ROOT --> INT[Integrations]
|
||||
ROOT --> RC[Release Control (ROOT)]
|
||||
|
||||
%% Releases submenus
|
||||
REL --> REL_LIST[Releases (Promotions)]
|
||||
REL --> BUNDLES[Bundles (Organizer)]
|
||||
REL --> COMPONENTS[Components (Service Versions)]
|
||||
|
||||
%% Bundles area
|
||||
BUNDLES --> B_CAT[Bundle Catalog]
|
||||
BUNDLES --> B_DETAIL[Bundle Detail]
|
||||
BUNDLES --> B_BUILDER[Create Bundle Version (Builder)]
|
||||
BUNDLES --> BV_DETAIL[Bundle Version Detail]
|
||||
BUNDLES --> B_MAT[Materialize to Environment]
|
||||
BUNDLES --> B_CHANGE[Changelog (per repo)]
|
||||
|
||||
%% Components area
|
||||
COMPONENTS --> C_CAT[Component Catalog]
|
||||
COMPONENTS --> CV_DETAIL[Component Version Detail]
|
||||
COMPONENTS --> C_IMPORT[Import/Sync Versions]
|
||||
|
||||
%% Cross-links
|
||||
B_DETAIL -. "Create promotion" .-> REL_LIST
|
||||
B_MAT -. "Creates approval request" .-> APPR
|
||||
BV_DETAIL -. "Evidence export" .-> EVID
|
||||
B_MAT -. "Uses env inputs" .-> RC
|
||||
B_MAT -. "Uses Vault/Consul" .-> INT
|
||||
B_MAT -. "Option: Build AirGap bundle" .-> OPS
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.2 Terminology (so screens stay unambiguous)
|
||||
|
||||
* **Component Version** = *digest-first* identity of a microservice image (digest is authoritative) + a **display version** (e.g., `2.1.0`), plus SBOM/finding snapshots and provenance links.
|
||||
* **Bundle** = logical product/service-set (e.g., “Platform Release”), with many **Bundle Versions** over time.
|
||||
* **Bundle Version** = immutable snapshot: exact component digests + bundle manifest digest + policy evaluation snapshot + derived changelog pointers.
|
||||
* **Materialization** = resolving **environment-specific inputs** (Vault/Consul/overrides) to produce a deployment plan for a region/env (and optionally an AirGap artifact).
|
||||
|
||||
---
|
||||
|
||||
# 12.3 Screen — Bundle Catalog
|
||||
|
||||
### Formerly (where it “lived” pre-redesign)
|
||||
|
||||
* **Not a dedicated concept**. Closest proxy:
|
||||
|
||||
* **Releases** list (`/releases`) with “Components” count
|
||||
* “AirGap Bundles” existed but under **Operations → Feeds → AirGap Bundles** (offline artifact focus, not release model focus)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Stella is release-centric; releases should promote **bundle versions** (stable, versioned) rather than ad-hoc component lists.
|
||||
* Operators need a canonical place to **organize bundles** by product/team/repo-set and track their version history.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Bundle Catalog] --> B[Bundle Detail]
|
||||
A --> C[Create New Bundle]
|
||||
A --> D[Component Catalog]
|
||||
A --> E[Changelog (per repo)]
|
||||
A --> F[Search/Filter by product/team/repo-set]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Releases ▸ Bundles (Organizer) │
|
||||
│ Legacy: N/A (new). Previously: Releases (/releases) contained components directly. │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Search: [ platform ] Tags: [All] Team: [All] Repo-set: [All] Status: [Active] │
|
||||
│ Actions: [+ New Bundle] [Import from Repo Set] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌─────────────────────────────┬──────────┬───────────────┬─────────────────┬────────────────┐│
|
||||
│ │ Bundle │ Versions │ Last Version │ Last Promotion │ Security Signal ││
|
||||
│ ├─────────────────────────────┼──────────┼───────────────┼─────────────────┼────────────────┤│
|
||||
│ │ Platform Release │ 18 │ 1.3.0-rc1 │ staging → prod │ 1 crit reachable││
|
||||
│ │ Hotfix Bundle │ 6 │ 1.2.4 │ prod │ clean ││
|
||||
│ │ Feature Branch Preview │ 3 │ 2.0.0-alpha │ dev │ info only ││
|
||||
│ └─────────────────────────────┴──────────┴───────────────┴─────────────────┴────────────────┘│
|
||||
│ Click a bundle → Bundle Detail │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.4 Screen — Bundle Detail (Overview + Versions + Deployments)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Partially in:
|
||||
|
||||
* **Releases** row detail (implicit)
|
||||
* “Create Release” (implicit composition)
|
||||
* “Approvals” (promotion context)
|
||||
* But **no persistent bundle object** existed.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Bundle is the stable unit of release governance:
|
||||
|
||||
* It is what you reason about (changelog, SBOM summary, reachability coverage).
|
||||
* Releases become “promotions of bundle version X to env Y”.
|
||||
* It’s also where you attach bundle-level intent (owner/team, repo-set, default workflow).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Bundle Detail] --> B[Versions Tab]
|
||||
A --> C[Deployments/Promotions Tab]
|
||||
A --> D[Components Tab]
|
||||
A --> E[Config & Inputs Tab]
|
||||
A --> F[Changelog Tab (per repo)]
|
||||
A --> G[Create Bundle Version]
|
||||
A --> H[Materialize to Environment]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Bundle: Platform Release │
|
||||
│ Legacy: N/A (new). Previously: “Platform Release” existed only as a Release row in /releases │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Owner: ci-pipeline Team: platform Repo-set: {api-gw, user-svc, web-fe, worker} │
|
||||
│ Default workflow: Canary 10→50→100 Default policy baseline: Prod │
|
||||
│ │
|
||||
│ Tabs: [Overview] [Versions] [Promotions] [Components] [Config & Inputs] [Changelog] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Overview │
|
||||
│ Latest Bundle Version: 1.3.0-rc1 Bundle Manifest Digest: sha256:abcd... │
|
||||
│ Security Snapshot: 1 critical reachable | 0 high reachable | VEX coverage 62% │
|
||||
│ Reachability Coverage: Image 100% | Build 78% | Runtime 35% │
|
||||
│ │
|
||||
│ Actions: [Create New Bundle Version] [Materialize to Env] [Create Promotion/Release] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.5 Screen — Create Bundle Version (Builder / Wizard)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Implicit in:
|
||||
|
||||
* **Releases → + Create Release** (user picked components / versions ad-hoc)
|
||||
* CI pipeline output (digest exists, but bundle composition logic is external/manual)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* You explicitly want:
|
||||
|
||||
* “microservice with digest becomes version X”
|
||||
* “bundle includes variables derived from Vault/Consul for env”
|
||||
* “bundle includes changelog per repository”
|
||||
* This requires an explicit **builder** that:
|
||||
|
||||
* selects component versions (digests),
|
||||
* computes changelog diffs,
|
||||
* validates SBOM + reachability coverage readiness,
|
||||
* produces an immutable **bundle version**.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Bundle Version Builder] --> S1[Step 1: Base Version]
|
||||
A --> S2[Step 2: Select Component Versions]
|
||||
A --> S3[Step 3: Config Contracts (vars required)]
|
||||
A --> S4[Step 4: Changelog Preview (per repo)]
|
||||
A --> S5[Step 5: Validate (policy + readiness)]
|
||||
A --> S6[Step 6: Finalize → Create Bundle Version]
|
||||
S6 --> BV[Bundle Version Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Create Bundle Version — Platform Release │
|
||||
│ Legacy: Releases ▸ +Create Release (implicit) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Steps: (1) Base (2) Components (3) Config (4) Changelog (5) Validate (6) Finalize │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ (1) Base Version │
|
||||
│ Base: [ 1.2.3 ] (diff will be computed vs base) │
|
||||
│ New version label: [ 1.3.0-rc1 ] │
|
||||
│ Notes: [ Release candidate for next major version ] │
|
||||
│ │
|
||||
│ Next → │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.6 Screen — Builder Step: Select Component Versions (digest-first → display version)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Components were directly attached to a **Release** row; versions/digests were not first-class.
|
||||
* Digest→version mapping usually lived in CI/repo tags and wasn’t visible in Stella.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Digest-first is required for determinism; version labels help humans.
|
||||
* This screen makes it explicit and auditable: **what digest** is being promoted and **why we call it version X**.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Select Component Versions] --> B[Pick from Component Catalog]
|
||||
A --> C[Import latest from CI/Registry]
|
||||
A --> D[Open Component Version Detail]
|
||||
A --> E[Continue to Config Contracts]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Create Bundle Version — Step (2) Components │
|
||||
│ Legacy: Release row “Components: N” (no explicit digest→version mapping UI) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Repo-set: api-gw, user-svc, web-fe, worker │
|
||||
│ │
|
||||
│ ┌───────────────┬───────────────┬───────────────────────────┬─────────────┬──────────────────┐│
|
||||
│ │ Component │ Display Ver. │ Digest (authoritative) │ SBOM Status │ Reachability ││
|
||||
│ ├───────────────┼───────────────┼───────────────────────────┼─────────────┼──────────────────┤│
|
||||
│ │ api-gateway │ 2.1.0 │ sha256:1111... │ OK │ Image+Build ││
|
||||
│ │ user-service │ 3.0.0-rc1 │ sha256:2222... │ OK │ Image only (gap) ││
|
||||
│ │ web-frontend │ 2.0.0 │ sha256:3333... │ OK │ Image+Runtime ││
|
||||
│ │ worker │ 3.1.0 │ sha256:4444... │ PENDING │ — ││
|
||||
│ └───────────────┴───────────────┴───────────────────────────┴─────────────┴──────────────────┘│
|
||||
│ Actions: [Import Latest] [Open Component Detail] │
|
||||
│ Gate note: “SBOM PENDING” will block finalize if policy requires SBOM for prod. │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.7 Screen — Builder Step: Config Contracts (variables required by services)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Config came from outside Stella or scattered across:
|
||||
|
||||
* Vault (secrets),
|
||||
* Consul (KV),
|
||||
* deployment manifests,
|
||||
* Release Control env config.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* You want bundle to include “variables derived from Vault/Consul for this env”.
|
||||
* To do that deterministically, Stella needs:
|
||||
|
||||
* a **contract**: what variables each service requires,
|
||||
* a **binding**: where to source them per region/env.
|
||||
|
||||
> Design choice:
|
||||
>
|
||||
> * **Contracts live with the bundle/component** (what is needed).
|
||||
> * **Bindings live with Release Control → Environment Inputs** (where it comes from in a region/env).
|
||||
> This keeps “what” separate from “where”.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Config Contracts Step] --> B[View service variable requirements]
|
||||
A --> C[Link to Env Bindings (Release Control)]
|
||||
A --> D[Validate: missing bindings?]
|
||||
A --> E[Continue to Changelog]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Create Bundle Version — Step (3) Config Contracts │
|
||||
│ Legacy: N/A (new). Previously: env vars existed in Vault/Consul + manifests, not bundled. │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Variable requirements (by component) │
|
||||
│ │
|
||||
│ api-gateway │
|
||||
│ - RATE_LIMIT_MAX (required) source: consul kv key: service/api-gw/rate_limit_max │
|
||||
│ - JWT_PUBLIC_KEYS (required) source: vault path: secret/api-gw/jwt_keys │
|
||||
│ │
|
||||
│ user-service │
|
||||
│ - AUTH_TIMEOUT_MS (required) source: consul kv key: service/user/auth_timeout_ms │
|
||||
│ - DB_PASSWORD (required) source: vault path: secret/user/db_password │
|
||||
│ │
|
||||
│ Binding check (target env later): │
|
||||
│ US-East/us-prod: 2 missing bindings (DB_PASSWORD, JWT_PUBLIC_KEYS) → will block materialize │
|
||||
│ Link: [Open Release Control → us-prod → Inputs] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.8 Screen — Builder Step: Changelog Preview (per repository)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Changelog was manual or external (GitHub/GitLab release notes), not attached to the release object in Stella.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* You require “bundle along with change log, per repository”.
|
||||
* This gives reviewers and auditors a deterministic view:
|
||||
|
||||
* “what changed in api-gw between digest A and digest B”
|
||||
* tied to the exact component versions.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Changelog Preview] --> B[Repo diff summary per component]
|
||||
A --> C[Expand commit/PR list]
|
||||
A --> D[Export changelog]
|
||||
A --> E[Continue to Validate]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Create Bundle Version — Step (4) Changelog (per repo) │
|
||||
│ Legacy: N/A (new). Previously: release notes lived in SCM/CI tools, not in Stella. │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Base: 1.2.3 → New: 1.3.0-rc1 │
|
||||
│ │
|
||||
│ api-gateway: 12 commits (3 PRs) │
|
||||
│ • PR #431: add rate limiting feature │
|
||||
│ • PR #428: fix header parsing bug │
|
||||
│ │
|
||||
│ user-service: 4 commits (1 PR) │
|
||||
│ • PR #77: critical fix for user authentication timeout │
|
||||
│ │
|
||||
│ web-frontend: 2 commits │
|
||||
│ worker: 0 commits │
|
||||
│ │
|
||||
│ [Export as Markdown] [Attach to Bundle Version Notes] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.9 Screen — Builder Step: Validate (policy readiness + SBOM + feeds + reachability)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Validation was split:
|
||||
|
||||
* Approvals page mentions policy + reachability,
|
||||
* Security pages show findings,
|
||||
* Operations show feeds/job status,
|
||||
* none were unified at “bundle creation”.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Bundle version should be created as an auditable artifact with a clear “ready for prod?” signal.
|
||||
* This is where we prevent “unknown SBOM state” from entering promotion pipeline.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Validate Bundle Version] --> B[Policy Gate Evaluation Snapshot]
|
||||
A --> C[SBOM & Findings Readiness]
|
||||
A --> D[Hybrid Reachability Coverage Check]
|
||||
A --> E[Feed Freshness / Integration Health]
|
||||
A --> F[Finalize]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Create Bundle Version — Step (5) Validate │
|
||||
│ Legacy: distributed across Approvals + Security + Ops + Integrations │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Policy baseline: Prod (US-East) │
|
||||
│ │
|
||||
│ Gates │
|
||||
│ ✓ All component digests resolved │
|
||||
│ ✗ SBOM scan pending: worker sha256:4444... (required for prod) │
|
||||
│ ✓ CVE feeds fresh (NVD: synced 1h ago, OSV: synced 20m ago) │
|
||||
│ ⚠ Hybrid reachability coverage: runtime evidence 35% (policy: warn, not block) │
|
||||
│ │
|
||||
│ Action required: [Trigger SBOM Scan Now] (or change component selection) │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.10 Screen — Bundle Version Detail (immutable snapshot + evidence pointers)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Not a first-class object. Closest:
|
||||
|
||||
* Release detail (not shown in PoC screenshots) + Evidence exports
|
||||
* But there was no immutable “bundle version” with its own digest.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* This is the deterministic record that promotions reference:
|
||||
|
||||
* It is what you **replay/verify** against,
|
||||
* what you **export evidence** for,
|
||||
* what you diff between versions.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Bundle Version Detail] --> B[Manifest Tab (digests + versions)]
|
||||
A --> C[Security Snapshot Tab]
|
||||
A --> D[Reachability Coverage Tab]
|
||||
A --> E[Changelog Tab]
|
||||
A --> F[Evidence Tab (DSSE/provenance links)]
|
||||
A --> G[Promote/Materialize Actions]
|
||||
A --> H[Diff vs previous version]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Bundle Version: Platform Release 1.3.0-rc1 │
|
||||
│ Legacy: N/A (new). Previously: release rows mixed composition + promotion. │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundle manifest digest: sha256:abcd... Created: Jan 11, 2026 by ci-pipeline │
|
||||
│ Base version: 1.2.3 Diff: +2 components changed, +16 commits total │
|
||||
│ │
|
||||
│ Tabs: [Manifest] [Security] [Reachability] [Changelog] [Evidence] [Promotions] [Diff] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Manifest (digest-first) │
|
||||
│ api-gateway v2.1.0 sha256:1111... SBOM OK │
|
||||
│ user-service v3.0.0-rc1 sha256:2222... SBOM OK │
|
||||
│ web-frontend v2.0.0 sha256:3333... SBOM OK │
|
||||
│ worker v3.1.0 sha256:4444... SBOM OK │
|
||||
│ │
|
||||
│ Actions: [Materialize to Env] [Create Promotion] [Export Evidence Pack] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.11 Screen — Component Catalog (Service Versions)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Implicit:
|
||||
|
||||
* registry contains digests
|
||||
* CI contains build versions
|
||||
* Stella UI doesn’t centralize digest→version mapping, SBOM state, reachability sources
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* You need a stable bridge:
|
||||
|
||||
* digest-first identity,
|
||||
* human-friendly version labels,
|
||||
* SBOM + reachability metadata used by bundle builder and approvals.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Component Catalog] --> B[Component Version Detail]
|
||||
A --> C[Import from Registry/CI]
|
||||
A --> D[Manage Version Mapping Rules]
|
||||
A --> E[Link to bundles using this component]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Releases ▸ Components (Service Versions) │
|
||||
│ Legacy: N/A (new). Previously: versions lived in CI/registry only. │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filter: Repo [All] SBOM [All] Reachability [Any] Deployed [Any] │
|
||||
│ Actions: [Import Latest] [Sync Now] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌───────────────┬───────────────┬───────────────────────┬──────────┬────────────────────────┐│
|
||||
│ │ Component │ Version Label │ Digest │ SBOM │ Reachability Sources ││
|
||||
│ ├───────────────┼───────────────┼───────────────────────┼──────────┼────────────────────────┤│
|
||||
│ │ api-gateway │ 2.1.0 │ sha256:1111... │ OK │ image, build ││
|
||||
│ │ user-service │ 3.0.0-rc1 │ sha256:2222... │ OK │ image ││
|
||||
│ │ web-frontend │ 2.0.0 │ sha256:3333... │ OK │ image, runtime ││
|
||||
│ └───────────────┴───────────────┴───────────────────────┴──────────┴────────────────────────┘│
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.12 Screen — Component Version Detail (SBOM + findings + hybrid reachability)
|
||||
|
||||
### Formerly
|
||||
|
||||
* SBOM/finding visibility existed, but:
|
||||
|
||||
* Findings list was global and empty in PoC,
|
||||
* Reachability concept existed in approvals but not clearly traceable to image/build/runtime sources,
|
||||
* No single “component version truth page”.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* This screen is the forensic anchor:
|
||||
|
||||
* if a bundle is blocked, you drill into the **component version** to see why (SBOM, CVEs, reachability evidence sources).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Component Version Detail] --> B[SBOM Summary]
|
||||
A --> C[Findings (reachable/not)]
|
||||
A --> D[Reachability (image/build/runtime)]
|
||||
A --> E[Provenance/Attestations]
|
||||
A --> F[Used-in Bundles]
|
||||
A --> G[Deployed-in Environments]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Component Version: user-service v3.0.0-rc1 │
|
||||
│ Digest: sha256:2222... │
|
||||
│ Legacy: N/A (new). Previously: info split across registry + approvals + security views. │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [SBOM] [Findings] [Reachability] [Provenance] [Used-in Bundles] [Deployed-in Envs] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Findings snapshot │
|
||||
│ Critical reachable: 0 High reachable: 0 High not reachable: 2 │
|
||||
│ VEX: statement present for CVE-XXXX (not exploitable: config) │
|
||||
│ │
|
||||
│ Reachability coverage │
|
||||
│ Image evidence: ✓ Build evidence: ✗ Runtime evidence: ✗ │
|
||||
│ Note: policy may warn or block based on baseline. │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.13 Screen — Materialize Bundle Version to Environment (resolve Vault/Consul + produce deployment plan)
|
||||
|
||||
### Formerly
|
||||
|
||||
* No explicit step. Operators/CI manually resolved env inputs and then deployed.
|
||||
* Release Control had environment config; Integrations had Vault; but no “bundle→env resolved view”.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Your requirement explicitly: “bundle includes variables derived from vaults and consul for this env”.
|
||||
* This screen is where the bundle becomes deployable in a specific **region/env**:
|
||||
|
||||
* resolve required variables,
|
||||
* detect missing bindings,
|
||||
* produce a deterministic deployment plan,
|
||||
* then create a promotion/approval.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Materialize Bundle → Environment] --> B[Select Region/Env]
|
||||
A --> C[Resolve Inputs (Vault/Consul)]
|
||||
A --> D[Show Missing/Overrides]
|
||||
A --> E[Generate Deployment Plan]
|
||||
A --> F[Create Promotion/Approval]
|
||||
A --> G[Optional: Build AirGap Artifact]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Materialize: Platform Release 1.3.0-rc1 → US-East / us-prod │
|
||||
│ Legacy: N/A (new). Previously: env vars resolved outside Stella, deployment was external. │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Inputs resolution │
|
||||
│ ✓ consul: service/api-gw/rate_limit_max = 500 │
|
||||
│ ✓ vault: secret/api-gw/jwt_keys = (sealed) │
|
||||
│ ✗ vault: secret/user/db_password = MISSING (binding not configured) │
|
||||
│ │
|
||||
│ Result │
|
||||
│ Status: BLOCKED (cannot materialize) │
|
||||
│ Fix: [Open Release Control → US-East/us-prod → Inputs] │
|
||||
│ │
|
||||
│ When resolved: [Generate Deployment Plan] [Create Promotion Request] [Build AirGap Bundle] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.14 Screen — Changelog (per repo) for a Bundle Version (drilldown)
|
||||
|
||||
### Formerly
|
||||
|
||||
* External to Stella (SCM release notes / PR list / commit diff)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Auditors and approvers need changelog tied to exact digests.
|
||||
* This page also prevents “bundle label changed but nothing actually changed” confusion.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Bundle Version Changelog] --> B[Repo-level diff]
|
||||
A --> C[Commit/PR detail]
|
||||
A --> D[Export (md/pdf)]
|
||||
A --> E[Link to approvals referencing this version]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Changelog — Platform Release 1.3.0-rc1 (vs 1.2.3) │
|
||||
│ Legacy: N/A (new). Previously: changelog was not a Stella object. │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ api-gateway │
|
||||
│ + PR #431 rate limiting feature │
|
||||
│ + PR #428 header parsing fix │
|
||||
│ │
|
||||
│ user-service │
|
||||
│ + PR #77 auth timeout critical fix │
|
||||
│ │
|
||||
│ web-frontend │
|
||||
│ + commit 8f2a... update UI │
|
||||
│ │
|
||||
│ Exports: [Markdown] [Attach to Evidence Packet] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 12.15 Screen — Optional integration: Build AirGap Bundle (linking to existing Ops screen)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Operations → Feeds → AirGap Bundles** (tab), disconnected from release objects.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* AirGap artifacts should be generated *from a specific bundle version + environment materialization*.
|
||||
* Keep the existing Ops screen (for storage/transfer), but **initiate and trace** it from the bundle context.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Bundle Version Detail] --> B[Materialize to Env]
|
||||
B --> C[Build AirGap Bundle]
|
||||
C --> D[Operations → AirGap Bundles (tracking)]
|
||||
D --> E[Download/Transfer/Verify]
|
||||
```
|
||||
|
||||
### ASCII mock (in-bundle launch)
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Build AirGap Bundle │
|
||||
│ Legacy: Ops ▸ Feeds ▸ AirGap Bundles (no release linkage) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Source: Platform Release 1.3.0-rc1 (bundle digest sha256:abcd...) │
|
||||
│ Target: US-East / us-prod │
|
||||
│ Includes: images (14) + manifests + resolved config overlays + checksums │
|
||||
│ │
|
||||
│ [Start Build] → tracking will appear in Ops ▸ AirGap Bundles │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What this changes elsewhere (minimal but necessary touchpoints)
|
||||
|
||||
To preserve functionality yet make it “Stella Ops way”, two UI pivots must happen:
|
||||
|
||||
1. **Releases list** (`/releases`)
|
||||
|
||||
* continues to exist, but each release row becomes:
|
||||
**Promotion of {Bundle Version} to {Env path}**
|
||||
* “Components” column becomes derived from bundle version.
|
||||
|
||||
2. **Approvals** (`/approvals`)
|
||||
|
||||
* approvals reference bundle version digest + materialization result (inputs resolved / missing).
|
||||
|
||||
These are cross-screen wiring changes; the *new screens in this pack* provide the missing first-class objects required to make that consistent and auditable.
|
||||
|
||||
---
|
||||
|
||||
If you want the next pack, I can do **Pack 13**: “Releases + Approvals screens updated to reference Bundle Versions everywhere” (Mermaid graphs + ASCII mocks + legacy naming).
|
||||
617
docs/modules/ui/v2-rewire/pack-13.md
Normal file
617
docs/modules/ui/v2-rewire/pack-13.md
Normal file
@@ -0,0 +1,617 @@
|
||||
## Pack 13 — Releases + Approvals redesigned to be **Bundle‑version driven** (digest‑first), with SBOM findings + hybrid reachability surfaced as **2nd‑class** signals
|
||||
|
||||
This pack updates the existing **Releases** and **Approvals** areas so every promotion is anchored on an immutable **Bundle Version** (bundle manifest digest), while keeping the UI familiar and preserving current functionality.
|
||||
|
||||
---
|
||||
|
||||
# 13.1 Menu graph (Mermaid) — Releases + Approvals area (and their cross‑links)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
|
||||
ROOT[Stella Ops Console] --> REL[Releases]
|
||||
ROOT --> APPR[Approvals]
|
||||
ROOT --> RC[Release Control (ROOT)]
|
||||
ROOT --> EVID[Evidence]
|
||||
ROOT --> SEC[Security]
|
||||
ROOT --> OPS[Operations]
|
||||
ROOT --> INT[Integrations]
|
||||
|
||||
%% Releases
|
||||
REL --> REL_LIST[Releases (Promotions)]
|
||||
REL --> REL_CREATE[Create Promotion]
|
||||
REL --> REL_DETAIL[Promotion Detail]
|
||||
REL_DETAIL --> REL_RUN[Deployment Run (timeline/logs)]
|
||||
REL_DETAIL --> REL_EVID[Evidence Snapshot]
|
||||
REL_DETAIL --> REL_SEC[Security Snapshot]
|
||||
REL_DETAIL --> REL_REACH[Reachability Snapshot]
|
||||
|
||||
%% Approvals
|
||||
APPR --> APPR_LIST[Approvals Queue]
|
||||
APPR --> APPR_DETAIL[Approval Detail]
|
||||
APPR_DETAIL --> APPR_GATES[Gate Results]
|
||||
APPR_DETAIL --> APPR_RISK[SBOM/Findings + Reachability]
|
||||
APPR_DETAIL --> APPR_EVID[Evidence used for decision]
|
||||
APPR_DETAIL --> APPR_REPLAY[Replay/Verify decision]
|
||||
|
||||
%% Cross links
|
||||
REL_CREATE -.select bundle version.-> BUNDLE[(Bundle Version Detail)]
|
||||
REL_DETAIL -.references.-> BUNDLE
|
||||
APPR_DETAIL -.references.-> BUNDLE
|
||||
REL_CREATE -.materialize inputs.-> RC
|
||||
REL_CREATE -.inputs from.-> INT
|
||||
REL_DETAIL -.export.-> EVID
|
||||
APPR_DETAIL -.exception request.-> SEC
|
||||
REL_DETAIL -.ops signals.-> OPS
|
||||
APPR_DETAIL -.ops signals.-> OPS
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.2 Releases sub‑graph (Mermaid) — screens and flow
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Releases (Promotions) List] --> B[Promotion Detail]
|
||||
A --> C[Create Promotion]
|
||||
C --> D[Materialize Bundle → Env]
|
||||
D --> E[Evaluate Gates]
|
||||
E --> F[Request Approval (if needed)]
|
||||
F --> G[Run Workflow / Deploy]
|
||||
G --> B
|
||||
B --> H[Export Evidence]
|
||||
B --> I[Rollback / Re-run]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.3 Screen — Releases (Promotions) List
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Releases** (`/releases`)
|
||||
Shows release rows with status (Draft/Ready/Deploying/Deployed/Rolled back), env, components count, created, actions.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* The “release” row needs to represent a **promotion run** of a **Bundle Version** (digest‑first), not an ad‑hoc component list.
|
||||
* This preserves the list UX, but adds the missing anchors:
|
||||
|
||||
* **Bundle name + bundle version**
|
||||
* **Bundle manifest digest**
|
||||
* **SBOM / findings summary**
|
||||
* **Data freshness / nightly ops signals** (so you don’t approve based on stale feeds or failed rescans)
|
||||
* **Hybrid reachability coverage** surfaced as a compact signal (2nd‑class, not a whole new menu)
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Releases (Promotions) List] --> B[Filter by Region/Env/Status]
|
||||
A --> C[Open Promotion Detail]
|
||||
A --> D[Create Promotion]
|
||||
A --> E[Open Bundle Version Detail]
|
||||
A --> F[Jump to Approvals (if pending)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Releases (Promotions) │
|
||||
│ Legacy name/location: "Releases" (/releases) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Region [All] Env [All] Status [All] Bundle [search...] Data Health [All] │
|
||||
│ Actions: [+ Create Promotion] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌──────────────────────────────┬───────────────┬──────────────┬──────────────┬──────────────┐ │
|
||||
│ │ Promotion (Bundle Version) │ Env Path │ Status │ Risk Signal │ Data Health │ │
|
||||
│ ├──────────────────────────────┼───────────────┼──────────────┼──────────────┼──────────────┤ │
|
||||
│ │ Hotfix Bundle 1.2.4 │ stage→prod │ DEPLOYING │ clean │ OK │ │
|
||||
│ │ manifest: sha256:abcd... │ US-East │ │ Reach: 1/0/0 │ feeds fresh │ │
|
||||
│ │ Platform Release 1.3.0-rc1 │ stage→prod │ READY │ 1 crit reach │ WARN │ │
|
||||
│ │ manifest: sha256:beef... │ EU-West │ │ Reach: 1/0/3 │ NVD stale 3h │ │
|
||||
│ │ Platform Release 1.2.2 │ prod │ ROLLED BACK │ 2 high reach │ OK │ │
|
||||
│ └──────────────────────────────┴───────────────┴──────────────┴──────────────┴──────────────┘ │
|
||||
│ Risk Signal format: Critical reachable / High reachable / High not reachable (and VEX % link) │
|
||||
│ Data Health: feed freshness + scan job status + integration connectivity (links to Ops) │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.4 Screen — Create Promotion (wizard)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **+ Create Release** on `/releases` (button)
|
||||
In PoC, this likely created a “release row” with components count, but no explicit bundle version composition workflow.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Promotion should start by selecting a **Bundle Version** (already composed in Bundle Organizer), then:
|
||||
|
||||
1. choose region + env path,
|
||||
2. **materialize** env-specific inputs (Vault/Consul),
|
||||
3. evaluate policy gates with freshest data,
|
||||
4. create approval request (if required),
|
||||
5. run deployment workflow.
|
||||
|
||||
This turns “Create Release” into “Create Promotion” while keeping the Releases menu.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Create Promotion] --> B[Step 1: Select Bundle Version]
|
||||
A --> C[Step 2: Select Region + Env Path]
|
||||
A --> D[Step 3: Materialize Inputs (Vault/Consul)]
|
||||
A --> E[Step 4: Evaluate Gates (policy + data freshness)]
|
||||
A --> F[Step 5: Approval Requirements + Justification]
|
||||
A --> G[Step 6: Launch Promotion / Schedule]
|
||||
G --> H[Promotion Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Create Promotion │
|
||||
│ Legacy name/location: "+ Create Release" (button on /releases) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Steps: (1) Bundle Version (2) Target Env (3) Inputs (4) Gates (5) Approvals (6) Launch │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ (1) Select Bundle Version │
|
||||
│ Bundle: [Platform Release ▼] │
|
||||
│ Version: [1.3.0-rc1 ▼] manifest digest: sha256:beef... │
|
||||
│ Snapshot: 1 critical reachable | VEX 62% | Reach coverage: Img100/Build78/Run35 │
|
||||
│ Links: [Open Bundle Version Detail] │
|
||||
│ │
|
||||
│ Next → │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.5 Screen — Create Promotion Step: Materialize Inputs (Vault/Consul) + bind check
|
||||
|
||||
### Formerly
|
||||
|
||||
* Env variables and secrets were implied:
|
||||
|
||||
* Vault integration exists under **Settings → Integrations**
|
||||
* Release Control had “Environments” but no “promotion-time resolved plan” UI
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* This is where your requirement becomes enforceable:
|
||||
|
||||
* “bundle becomes deployable to env X with variables from Vault/Consul”
|
||||
* Missing bindings must block (or warn) **before** you request approvals.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Inputs Materialization] --> B[Resolve from Vault/Consul]
|
||||
A --> C[Detect missing bindings]
|
||||
A --> D[Preview resolved deployment plan]
|
||||
A --> E[Link: Release Control → Env Inputs]
|
||||
A --> F[Continue to Gates]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Create Promotion — Step (3) Inputs (Materialize) │
|
||||
│ Legacy: scattered across Integrations (Vault) + Release Control (env config) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Target: US-East / us-prod │
|
||||
│ │
|
||||
│ Resolution results │
|
||||
│ ✓ consul service/api-gw/rate_limit_max = 500 │
|
||||
│ ✓ vault secret/api-gw/jwt_keys = (sealed) │
|
||||
│ ✗ vault secret/user/db_password = MISSING binding │
|
||||
│ │
|
||||
│ Outcome: BLOCKED — cannot proceed to policy evaluation / approval request │
|
||||
│ Fix: [Open Release Control → US-East/us-prod → Inputs] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.6 Screen — Promotion Detail (Release Detail)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Likely “Release detail” behind the eye icon on `/releases`
|
||||
(not included in your screenshots, but implied by actions)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Promotion detail must clearly tie together:
|
||||
|
||||
* bundle version identity (digest-first),
|
||||
* gate outcome + explanation,
|
||||
* SBOM findings summary by env,
|
||||
* hybrid reachability coverage for confidence,
|
||||
* ops data health (feeds/rescans/integrations),
|
||||
* evidence snapshot and export.
|
||||
|
||||
**Hybrid reachability** remains 2nd‑class: a tab/section, not its own menu.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Promotion Detail] --> B[Overview]
|
||||
A --> C[Gate Trace (why pass/block)]
|
||||
A --> D[Security Snapshot (SBOM findings)]
|
||||
A --> E[Reachability Snapshot (image/build/runtime)]
|
||||
A --> F[Deployment Run Timeline]
|
||||
A --> G[Evidence Snapshot + Export]
|
||||
A --> H[Ops/Data Health]
|
||||
A --> I[Diff vs previous deployed bundle]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Promotion: Platform Release 1.3.0-rc1 (manifest sha256:beef...) │
|
||||
│ Legacy name/location: Release detail from "Releases" (/releases) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Env Path: EU-West / eu-stage → eu-prod Status: READY Workflow: Canary 10→50→100 │
|
||||
│ Requested by: alice.johnson Justification: scheduled release w/ rate limiting + bug fixes │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Overview] [Gates] [Security] [Reachability] [Run] [Evidence] [Ops/Data] [Diff] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Overview │
|
||||
│ Risk summary: 1 critical reachable (eu-prod) | 0 high reachable | 3 high not reachable │
|
||||
│ VEX coverage: 62% │
|
||||
│ Data health: WARN — NVD feed stale 3h; last rescan job failed (worker) │
|
||||
│ │
|
||||
│ Actions: [Request Approval] [Run Now] [Schedule] [Export Evidence] [Rollback (if running)] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.7 Screen — Promotion Detail: Gates (explain “why” + tie to freshness)
|
||||
|
||||
### Formerly
|
||||
|
||||
* “Policy Gates” summary existed on Approvals cards (“PASS/BLOCK”) but lacked:
|
||||
|
||||
* structured trace,
|
||||
* explicit linkage to data freshness and job state.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Stella’s value is “explain every decision” / deterministic traceability.
|
||||
* Gate trace must include:
|
||||
|
||||
* what inputs were used (bundle digest, env, policy baseline),
|
||||
* whether CVE feeds were fresh,
|
||||
* whether SBOM scans completed,
|
||||
* reachability evidence quality (warn/block based on baseline).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Gates Tab] --> B[Gate Results Table]
|
||||
A --> C[Gate Trace Detail (inputs + evidence)]
|
||||
A --> D[Replay evaluation]
|
||||
A --> E[Link to Exception Request]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Gates — Platform Release 1.3.0-rc1 → EU-West/eu-prod │
|
||||
│ Legacy: Approvals cards showed PASS/BLOCK without full trace │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Baseline: Prod-EU-West | Evaluated: Feb 18, 08:30 | Data: NVD stale 3h (warn threshold 2h) │
|
||||
│ │
|
||||
│ ┌──────────────────────────────┬──────────┬──────────────────────────────────────────────────┐ │
|
||||
│ │ Gate │ Result │ Why │ │
|
||||
│ ├──────────────────────────────┼──────────┼──────────────────────────────────────────────────┤ │
|
||||
│ │ SBOM scans complete │ FAIL │ worker digest pending scan (required for prod) │ │
|
||||
│ │ Critical reachable CVEs │ FAIL │ CVE-XXXX reachable in eu-prod (no VEX) │ │
|
||||
│ │ Feed freshness │ WARN │ NVD last sync 3h │ │
|
||||
│ │ Reachability coverage runtime │ WARN │ runtime evidence 35% (policy warn) │ │
|
||||
│ └──────────────────────────────┴──────────┴──────────────────────────────────────────────────┘ │
|
||||
│ Actions: [Replay Gate Eval] [Request Exception] [Open Findings] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.8 Approvals sub‑graph (Mermaid) — screens and flow
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Approvals Queue] --> B[Approval Detail]
|
||||
B --> C[Approve / Reject]
|
||||
B --> D[View Gate Trace]
|
||||
B --> E[View Security Snapshot]
|
||||
B --> F[View Evidence]
|
||||
B --> G[Request Exception]
|
||||
C --> H[Promotion continues / deploy run starts]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.9 Screen — Approvals Queue
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Approvals** (`/approvals`)
|
||||
Shows pending items with justification, policy gates PASS/BLOCK, approvals count, approve/reject buttons.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Approval items must reference:
|
||||
|
||||
* the **Bundle Version** (manifest digest),
|
||||
* the **target region/env path**,
|
||||
* **SBOM findings summary** (critical reachable per env),
|
||||
* **hybrid reachability confidence**,
|
||||
* **data freshness / nightly job issues** that might invalidate the scan picture.
|
||||
|
||||
This allows reviewers to answer: “Is this safe to promote *right now*?”
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Approvals Queue] --> B[Filter by Region/Env/Status/Risk]
|
||||
A --> C[Open Approval Detail]
|
||||
A --> D[Jump to Promotion Detail]
|
||||
A --> E[Jump to Bundle Version Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Approvals │
|
||||
│ Legacy name/location: "Approvals" (/approvals) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Status [Pending] Region [All] Env [All] Risk [All] Data Health [All] │
|
||||
│ │
|
||||
│ Results (2) │
|
||||
│ ┌──────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Platform Release 1.3.0-rc1 (manifest sha256:beef...) eu-stage → eu-prod │ │
|
||||
│ │ Justification: scheduled release with rate limiting feature and bug fixes. │ │
|
||||
│ │ Gates: BLOCK (2/4) Approvals: 0/2 │ │
|
||||
│ │ Risk: 1 critical reachable (eu-prod) | VEX 62% | Reach Img100/Build78/Run35 │ │
|
||||
│ │ Data health: WARN (NVD stale 3h; rescan job failed) │ │
|
||||
│ │ [Approve] [Reject] [View Details] │ │
|
||||
│ └──────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ ┌──────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Hotfix Bundle 1.2.4 (manifest sha256:abcd...) us-stage → us-prod │ │
|
||||
│ │ Justification: critical fix for user authentication timeout issue. │ │
|
||||
│ │ Gates: PASS (4/4) Approvals: 1/2 │ │
|
||||
│ │ Risk: clean | Reach Img100/Build100/Run80 │ │
|
||||
│ │ Data health: OK │ │
|
||||
│ │ [Approve] [Reject] [View Details] │ │
|
||||
│ └──────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.10 Screen — Approval Detail (decision packet)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Likely behind “View Details” on `/approvals` (not shown), plus scattered info across:
|
||||
|
||||
* Security overview/findings,
|
||||
* Evidence exports,
|
||||
* Replay/Verify.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Approval is the decision choke point; it must show:
|
||||
|
||||
* what is being approved (bundle digest),
|
||||
* what env(s) are impacted,
|
||||
* why gates pass/block,
|
||||
* SBOM findings and reachability evidence quality,
|
||||
* evidence pointers for audit,
|
||||
* replay/verify capability.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Approval Detail] --> B[Decision Overview]
|
||||
A --> C[Gate Results + Trace]
|
||||
A --> D[SBOM Findings (by env)]
|
||||
A --> E[Reachability (image/build/runtime)]
|
||||
A --> F[Evidence used]
|
||||
A --> G[Ops/Data Health]
|
||||
A --> H[Replay/Verify]
|
||||
A --> I[Approve/Reject actions]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Approval: Platform Release 1.3.0-rc1 → EU-West/eu-prod │
|
||||
│ Legacy name/location: Approval detail from "Approvals" (/approvals) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundle version: Platform Release 1.3.0-rc1 │
|
||||
│ Manifest digest: sha256:beef... Requested by: alice.johnson Requested: 36d ago │
|
||||
│ Env path: eu-stage → eu-prod Workflow: Canary 10→50→100 │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Overview] [Gates] [Security] [Reachability] [Evidence] [Ops/Data] [Replay/Verify] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Overview │
|
||||
│ Current gate state: BLOCK │
|
||||
│ Blocking reasons: (1) critical reachable CVE without VEX (2) SBOM scan incomplete │
|
||||
│ │
|
||||
│ Actions: [Approve] (disabled) [Reject] [Request Exception] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.11 Approval Detail: Security tab (SBOM findings by env + “what changed”)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Security summary existed, but disconnected from the approval object and env context.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Approvals must be grounded in:
|
||||
|
||||
* **which environments** have critical reachable issues,
|
||||
* and whether they are already present (“existing risk”) or introduced by this promotion (“delta”).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Security Tab] --> B[Findings summary by severity + reachability]
|
||||
A --> C[By environment breakdown]
|
||||
A --> D[Delta vs currently deployed bundle in target env]
|
||||
A --> E[Open Finding detail / VEX]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Security — Approval Detail │
|
||||
│ Legacy: Security Overview/Findings were separate from Approvals │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Summary (target env: eu-prod) │
|
||||
│ Critical reachable: 1 High reachable: 0 High not reachable: 3 VEX coverage: 62% │
|
||||
│ │
|
||||
│ By environment │
|
||||
│ eu-stage: 0 critical reachable │
|
||||
│ eu-prod : 1 critical reachable (CVE-XXXX in user-service sha256:2222...) │
|
||||
│ │
|
||||
│ Delta (vs currently deployed bundle in eu-prod) │
|
||||
│ +1 critical reachable introduced by this promotion │
|
||||
│ Links: [Open Finding] [Open Component Version] [Open VEX Statement] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.12 Approval Detail: Reachability tab (hybrid reachability as 2nd‑class)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Reachability appeared conceptually in approvals (“policy + reachability”) but without clear sourcing.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* You require hybrid reachability from:
|
||||
|
||||
* **image (Dover scan)**,
|
||||
* **build evidence**,
|
||||
* **runtime evidence**.
|
||||
* This must be visible during approvals but stays 2nd‑class (tab).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Reachability Tab] --> B[Coverage metrics: image/build/runtime]
|
||||
A --> C[Evidence sources list]
|
||||
A --> D[Policy interpretation (warn/block thresholds)]
|
||||
A --> E[Drill into component reachability]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Reachability — Approval Detail │
|
||||
│ Legacy: reachability referenced but not clearly sourced │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Coverage (for bundle version) │
|
||||
│ Image evidence: 100% Build evidence: 78% Runtime evidence: 35% │
|
||||
│ │
|
||||
│ Interpretation (baseline Prod-EU-West) │
|
||||
│ • Runtime coverage < 50% → WARN (does not block) │
|
||||
│ • Critical reachable requires runtime evidence OR VEX override → BLOCK │
|
||||
│ │
|
||||
│ Component breakdown │
|
||||
│ user-service sha256:2222... Image ✓ Build ✗ Runtime ✗ │
|
||||
│ api-gateway sha256:1111... Image ✓ Build ✓ Runtime ✗ │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 13.13 Approval Detail: Ops/Data tab (nightly job + feed + integration health)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Feeds freshness: **Operations → Feeds**
|
||||
* Background jobs: **System → Background Jobs**
|
||||
* Integrations: **Settings → Integrations**
|
||||
* None were summarized at approval time.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Approvals must warn if:
|
||||
|
||||
* CVE feeds are stale,
|
||||
* SBOM rescans failing,
|
||||
* integrations disconnected (e.g., Vault/Registry/CI),
|
||||
because decision confidence is reduced.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Ops/Data Tab] --> B[Feed freshness (NVD/OSV)]
|
||||
A --> C[SBOM rescan job status]
|
||||
A --> D[Integration connectivity]
|
||||
A --> E[Links: Ops/System/Integrations]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Ops/Data Health — Approval Detail │
|
||||
│ Legacy: separate screens (Ops Feeds, System Jobs, Integrations) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Feeds │
|
||||
│ OSV: synced 20m ago (OK) │
|
||||
│ NVD: synced 3h ago (WARN; threshold 2h) │
|
||||
│ │
|
||||
│ Nightly jobs │
|
||||
│ SBOM rescan (worker sha256:4444...): FAILED (last run 1h ago) │
|
||||
│ Reachability import (runtime): RUNNING │
|
||||
│ │
|
||||
│ Integrations │
|
||||
│ Registry: OK CI/CD: DEGRADED (Jenkins) Vault: OK │
|
||||
│ Links: [Open Ops Feeds] [Open System Jobs] [Open Integrations] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What stays the same (so we preserve PoC functionality)
|
||||
|
||||
* **Releases list** still shows statuses like Draft/Ready/Deploying/Deployed/Rolled back.
|
||||
* **Approvals queue** still has Approve/Reject and the same “requested by + justification” feel.
|
||||
* Promotion path concept (staging → production) remains identical — now **region‑scoped** and bundle‑version‑anchored.
|
||||
|
||||
---
|
||||
|
||||
If you say “continue”, **Pack 14** will cover the **Release Run / Deployment timeline** screen (logs, checkpoints, rollback triggers, evidence capture points) and how it ties into **Replay/Verify** and **Evidence Export** without adding new top‑level clutter.
|
||||
482
docs/modules/ui/v2-rewire/pack-14.md
Normal file
482
docs/modules/ui/v2-rewire/pack-14.md
Normal file
@@ -0,0 +1,482 @@
|
||||
## Pack 14 — Release Run / Deployment Timeline (workflow checkpoints, logs, rollback, evidence capture, replay/verify)
|
||||
|
||||
This pack adds the **“run view”** that ties together everything Stella Ops promises: *promote by digest, explain every decision, evidence-backed audit, deterministic replay* — without turning reachability into a top-level area.
|
||||
|
||||
---
|
||||
|
||||
# 14.1 Menu graph (Mermaid) — where “Release Run” sits in the IA
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
ROOT[Stella Ops Console] --> REL[Releases]
|
||||
ROOT --> APPR[Approvals]
|
||||
ROOT --> EVID[Evidence]
|
||||
ROOT --> OPS[Operations]
|
||||
ROOT --> RC[Release Control (ROOT)]
|
||||
ROOT --> INT[Integrations]
|
||||
ROOT --> SEC[Security]
|
||||
|
||||
REL --> REL_LIST[Releases (Promotions)]
|
||||
REL_LIST --> PROMO_DETAIL[Promotion Detail]
|
||||
PROMO_DETAIL --> RUN_TAB[Run / Timeline]
|
||||
RUN_TAB --> STEP_DETAIL[Step Detail: logs + artifacts + evidence]
|
||||
RUN_TAB --> ROLLBACK[Rollback / Re-run]
|
||||
RUN_TAB --> SCHEDULE[Schedule / Automation]
|
||||
|
||||
STEP_DETAIL -. export evidence .-> EVID
|
||||
STEP_DETAIL -. replay policy .-> EVID
|
||||
RUN_TAB -. ops health .-> OPS
|
||||
|
||||
EVID --> PKT[Packets]
|
||||
EVID --> CHAIN[Proof Chains]
|
||||
EVID --> REPLAY[Replay/Verify]
|
||||
EVID --> EXPORT[Export Center]
|
||||
EVID --> BUNDLES[Evidence Bundles]
|
||||
|
||||
OPS --> ORCH[Orchestrator]
|
||||
OPS --> SCHED[Scheduler Runs]
|
||||
OPS --> DLQ[Dead Letter]
|
||||
OPS --> FEEDS[Feeds + AirGap Ops]
|
||||
OPS --> HEALTH[Platform Health]
|
||||
|
||||
RUN_TAB -. links to .-> ORCH
|
||||
RUN_TAB -. links to .-> SCHED
|
||||
RUN_TAB -. links to .-> FEEDS
|
||||
RUN_TAB -. links to .-> HEALTH
|
||||
|
||||
PROMO_DETAIL -. findings snapshot .-> SEC
|
||||
PROMO_DETAIL -. env inputs .-> RC
|
||||
PROMO_DETAIL -. secrets/providers .-> INT
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 14.2 Run lifecycle graph (Mermaid) — promotion execution stages + checkpoints
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Promotion Created] --> B[Inputs Materialized]
|
||||
B --> C[Policy Gate Eval]
|
||||
C --> D{Approval Required?}
|
||||
D -- yes --> E[Approval Decision]
|
||||
D -- no --> F[Deploy Workflow Start]
|
||||
|
||||
E --> F
|
||||
F --> G[Canary 10%]
|
||||
G --> H{SLO/Health OK?}
|
||||
H -- no --> R[Auto-Rollback / Pause]
|
||||
H -- yes --> I[Canary 50%]
|
||||
I --> J{SLO/Health OK?}
|
||||
J -- no --> R
|
||||
J -- yes --> K[100% Rollout]
|
||||
K --> L[Post-Deploy Verify]
|
||||
L --> M[Finalize + Seal Evidence]
|
||||
M --> N[Promotion Complete]
|
||||
|
||||
%% Evidence capture points
|
||||
C -. DSSE policy decision .-> EV[Evidence Pack]
|
||||
F -. provenance/attestations .-> EV
|
||||
L -. runtime reachability snapshot .-> EV
|
||||
M -. Rekor/tlog receipts .-> EV
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 14.3 Screen — Run / Timeline (Promotion Run)
|
||||
|
||||
### Formerly (where it lived pre-redesign)
|
||||
|
||||
Pieces existed but were **fragmented**:
|
||||
|
||||
* **Control Plane** dashboard showed *Active Deployments* (high-level only).
|
||||
* **Operations → Orchestrator** (jobs access) and **Operations → Scheduler** (runs) were operational but not “release narrative”.
|
||||
* Evidence was in **Evidence → Packets / Proof Chains / Export**, but not tied to a run timeline.
|
||||
* Any detailed logs typically lived outside Stella (CI/CD, deploy system, cluster logs).
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* A release promotion must be **auditable as a single storyline**:
|
||||
|
||||
* what happened,
|
||||
* when,
|
||||
* what data it used,
|
||||
* what it decided,
|
||||
* what evidence was sealed at each checkpoint,
|
||||
* and what actions are safe now (pause, rollback, replay).
|
||||
* This screen becomes the **single pane** that links out to specialized areas (Ops, Evidence), instead of forcing users to hunt.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Run / Timeline] --> B[Stage timeline with checkpoints]
|
||||
A --> C[Current status + next step]
|
||||
A --> D[Links to logs, artifacts, evidence]
|
||||
A --> E[Actions: pause/retry/rollback]
|
||||
A --> F[Data health banner: feeds/jobs/integrations]
|
||||
A --> G[Drill into Step Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Promotion Run / Timeline │
|
||||
│ Legacy name/location: No single screen. Pieces were Control Plane "Active Deployments" + Ops. │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Promotion: Platform Release 1.3.0-rc1 manifest sha256:beef... │
|
||||
│ Target: EU-West / eu-stage → eu-prod Workflow: Canary 10→50→100 │
|
||||
│ Status: RUNNING (Canary 10%) Started: Feb 18, 08:30 │
|
||||
│ Data health: WARN — NVD stale 3h | Rescan job failed (worker) | Jenkins degraded │
|
||||
│ Links: [Ops Feeds] [System Jobs] [Integrations] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Timeline (click any step) │
|
||||
│ 08:30 ✓ Inputs Materialized (Vault/Consul resolved, 0 missing) [View] │
|
||||
│ 08:31 ✓ Gate Eval (Policy) PASS/WARN (reach runtime 35%) [View] │
|
||||
│ 08:32 ✓ Approval APPROVED by bob.smith [View] │
|
||||
│ 08:33 ▶ Deploy Canary 10% RUNNING (2/10 targets healthy) [View] [Pause] │
|
||||
│ ---- ○ Deploy Canary 50% PENDING [—] │
|
||||
│ ---- ○ Deploy 100% PENDING [—] │
|
||||
│ ---- ○ Post-Deploy Verify PENDING [—] │
|
||||
│ ---- ○ Seal Evidence PENDING [—] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Quick actions: [Pause] [Retry step] [Rollback] [Export evidence (partial)] [Replay policy] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 14.4 Screen — Step Detail (Logs + Artifacts + Evidence captured at that checkpoint)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Logs: CI/CD (e.g., Jenkins), deploy agent logs, platform logs — outside Stella.
|
||||
* Evidence: visible only under **Evidence** menus and not connected to “the step that created it”.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Step Detail is the “unit of explanation”.
|
||||
* Every meaningful checkpoint should show:
|
||||
|
||||
* **inputs** used,
|
||||
* **outputs** produced,
|
||||
* **logs**,
|
||||
* **evidence items** sealed (or pending),
|
||||
* and **links** to canonical storage (Evidence Packets / Proof Chains).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Step Detail] --> B[Overview: inputs/outputs + timestamps]
|
||||
A --> C[Logs (stream / download)]
|
||||
A --> D[Artifacts (manifests, plans, diffs)]
|
||||
A --> E[Evidence items (DSSE, receipts, proofs)]
|
||||
A --> F[Actions: retry step / mark failed / pause]
|
||||
A --> G[Jump: Evidence Packet / Proof Chain]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Step Detail: Gate Eval (Policy) │
|
||||
│ Legacy name/location: gate result surfaced loosely on Approvals; evidence elsewhere. │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Start: 08:31 End: 08:31:12 Duration: 12s Result: PASS (2 WARN) │
|
||||
│ Inputs: bundle manifest sha256:beef... | baseline Prod-EU-West | feeds: NVD stale 3h │
|
||||
│ Outputs: policy verdict id: verdict-123 | decision digest: sha256:dd77... │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Overview] [Logs] [Artifacts] [Evidence] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Evidence captured │
|
||||
│ ✓ DSSE envelope: policy-decision.dsse (digest sha256:dd77...) │
|
||||
│ ✓ Rekor receipt: rekor-entry.json (tlog index 9918271) │
|
||||
│ ○ Proof chain: pending until "Seal Evidence" step │
|
||||
│ Links: [Open Evidence Packet] [Open Proof Chain] [Replay this Verdict] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 14.5 Screen — Deploy Stage View (targets, health, checkpoints, rollback triggers)
|
||||
|
||||
### Formerly
|
||||
|
||||
* “Active Deployments” showed minimal progress.
|
||||
* Detailed rollout/targets health likely lived in your deploy system (outside Stella).
|
||||
* Platform Health screen exists, but not contextualized to a specific promotion.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* This is where “release operations” actually happens:
|
||||
|
||||
* show **targets** in the region/env,
|
||||
* show **health gates** / SLO checks,
|
||||
* show **automatic rollback triggers**,
|
||||
* link to platform health and logs.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Deploy Stage View] --> B[Targets table (per region/env)]
|
||||
A --> C[SLO / health checks]
|
||||
A --> D[Auto-rollback rules + trigger state]
|
||||
A --> E[Actions: pause/continue/rollback]
|
||||
A --> F[Link: Platform Health]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Step Detail: Deploy Canary 10% │
|
||||
│ Legacy name/location: Control Plane "Active Deployments" (summary only) + external deploy logs │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Stage: Canary 10% Policy: proceed if 95% healthy for 5m, error rate < 1% │
|
||||
│ Current: 2/10 healthy | Error rate: 0.4% | Latency p95: 210ms | SLO: OK │
|
||||
│ Auto-rollback trigger: NOT TRIGGERED │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Targets (EU-West / eu-prod) │
|
||||
│ ┌───────────────┬───────────┬──────────┬──────────────┬───────────────┐ │
|
||||
│ │ Target │ Version │ Health │ Notes │ Logs │ │
|
||||
│ ├───────────────┼───────────┼──────────┼──────────────┼───────────────┤ │
|
||||
│ │ eu-prod-01 │ bundle@beef│ ✓ │ ok │ [open] │ │
|
||||
│ │ eu-prod-02 │ bundle@beef│ ✓ │ ok │ [open] │ │
|
||||
│ │ eu-prod-03 │ old │ ○ │ pending │ [open] │ │
|
||||
│ └───────────────┴───────────┴──────────┴──────────────┴───────────────┘ │
|
||||
│ Actions: [Pause] [Continue to 50%] (disabled until criteria met) [Rollback] [Open Platform Health]│
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 14.6 Screen — Rollback / Re-run (safe ops controls)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Rollback existed as a **status** (“ROLLED_BACK”) in Releases list.
|
||||
* Actual rollback execution likely happened externally or via Orchestrator privileges.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Rollback must be:
|
||||
|
||||
* explicit,
|
||||
* traceable,
|
||||
* evidence-backed (what was rolled back, why, and what is the resulting state).
|
||||
* Re-run is needed for transient failures (e.g., feed sync delay, rescan job retry), but must preserve determinism (re-run should record new evidence with timestamps, and keep old evidence).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Rollback/Re-run] --> B[Select scope: step / stage / full rollback]
|
||||
A --> C[Preview impact (targets + versions)]
|
||||
A --> D[Reason + ticket]
|
||||
A --> E[Execute]
|
||||
E --> F[Run Timeline updates + evidence appended]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Rollback / Re-run │
|
||||
│ Legacy name/location: Release status "ROLLED_BACK" existed; rollback execution was not unified │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Promotion: Platform Release 1.3.0-rc1 → EU-West/eu-prod │
|
||||
│ Current stage: Canary 10% (RUNNING) │
|
||||
│ │
|
||||
│ Choose action: │
|
||||
│ ( ) Re-run current step (Deploy Canary 10%) │
|
||||
│ ( ) Pause promotion │
|
||||
│ ( ) Rollback to previously deployed bundle version (manifest sha256:prev...) │
|
||||
│ │
|
||||
│ Preview rollback impact: │
|
||||
│ - 2 targets currently on new bundle → will revert to prev bundle │
|
||||
│ - 8 targets still old → unchanged │
|
||||
│ │
|
||||
│ Reason (required): [ incident #1234: elevated latency ] │
|
||||
│ [Execute] [Cancel] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 14.7 Screen — Evidence Timeline (what evidence exists now vs what seals at finalize)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Evidence existed under:
|
||||
|
||||
* **Evidence → Packets**
|
||||
* **Evidence → Proof Chains**
|
||||
* **Evidence → Export**
|
||||
* **Evidence → Evidence Bundles**
|
||||
…but the *relationship to the run stages* wasn’t visible.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Auditors and operators need to answer:
|
||||
|
||||
* “What evidence is already available mid-run?”
|
||||
* “What is pending until completion?”
|
||||
* “What exactly was sealed and when?”
|
||||
* This is the bridge between *Ops timeline* and *audit artifacts*.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Evidence Timeline (per promotion)] --> B[Evidence items by checkpoint]
|
||||
A --> C[Open Packet]
|
||||
A --> D[Open Proof Chain]
|
||||
A --> E[Export Evidence Pack]
|
||||
A --> F[Generate Auditor Bundle]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Evidence Timeline — Promotion Run │
|
||||
│ Legacy name/location: Evidence artifacts existed, but not linked to run checkpoints │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Checkpoint → Evidence │
|
||||
│ Inputs Materialized │
|
||||
│ ✓ resolved-inputs.json (hash sha256:aa11...) │
|
||||
│ │
|
||||
│ Gate Eval (Policy) │
|
||||
│ ✓ policy-decision.dsse ✓ rekor receipt ✓ verdict-123 │
|
||||
│ │
|
||||
│ Deploy Canary 10% │
|
||||
│ ○ deploy-attestation.dsse (pending) │
|
||||
│ │
|
||||
│ Seal Evidence (final) │
|
||||
│ ○ proof-chain.json ○ audit-pack.tar.gz ○ evidence-bundle.zip │
|
||||
│ │
|
||||
│ Actions: [Open Evidence Packet] [Open Proof Chain] [Export Pack (partial)] [Generate Auditor Bundle]│
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 14.8 Screen — Replay/Verify (contextual replay for *this run*)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Evidence → Replay/Verify** (“Verdict Replay”) existed as a standalone screen:
|
||||
|
||||
* user inputs verdict id or image reference,
|
||||
* sees replay requests + determinism overview.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Replay should be reachable from where it matters:
|
||||
|
||||
* a specific policy decision checkpoint in a promotion run.
|
||||
* Keep the existing Replay/Verify functionality, but add a **contextual wrapper**:
|
||||
|
||||
* pre-fills verdict id + bundle digest + env baseline,
|
||||
* shows determinism status for this promotion.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Run → Replay/Verify] --> B[Pre-filled replay request]
|
||||
B --> C[Replay requests list]
|
||||
C --> D[Determinism metrics]
|
||||
D --> E[Link: Evidence → Replay/Verify canonical view]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Replay/Verify — For this Promotion │
|
||||
│ Legacy name/location: "Verdict Replay" (Evidence → Replay/Verify) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Pre-filled replay request │
|
||||
│ Verdict ID: verdict-123 │
|
||||
│ Bundle: Platform Release 1.3.0-rc1 manifest sha256:beef... │
|
||||
│ Baseline: Prod-EU-West │
|
||||
│ Reason: [ Audit verification / policy change test ] │
|
||||
│ [Request Replay] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Recent replay requests (for this promotion) │
|
||||
│ rr-001 COMPLETED Feb 18, 08:30 match │
|
||||
│ rr-002 RUNNING Feb 18, 07:30 │
|
||||
│ Determinism: total 2 | matching 1 | mismatches 1 | match rate 50% │
|
||||
│ Link: [Open canonical Replay/Verify screen] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 14.9 Screen — Schedule / Automation (promotion scheduling + link to Scheduler Runs)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Operations → Scheduler** existed (“Scheduler Runs”) but disconnected from promotions.
|
||||
* Release list had statuses but scheduling wasn’t first-class in the release context.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
* Scheduling belongs to release operations, but we don’t want a new menu.
|
||||
* This screen:
|
||||
|
||||
* schedules this promotion (or a step),
|
||||
* writes a scheduler job,
|
||||
* then links to **Scheduler Runs** for execution diagnostics.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[Schedule Promotion] --> B[Choose time/window]
|
||||
A --> C[Choose constraints (feeds fresh, scans complete)]
|
||||
A --> D[Create scheduler job]
|
||||
D --> E[View Scheduler Runs]
|
||||
E --> F[Back to Run Timeline]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Schedule Promotion │
|
||||
│ Legacy name/location: Ops → Scheduler (runs), no promotion-level scheduling UI │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Promotion: Hotfix Bundle 1.2.4 → US-East/us-prod │
|
||||
│ │
|
||||
│ Schedule: [ Feb 19, 02:00 AM ] Window: [ 2h ] │
|
||||
│ Preconditions: │
|
||||
│ [x] NVD/OSV feeds fresh (< 1h) │
|
||||
│ [x] SBOM rescans complete │
|
||||
│ [ ] Integrations healthy (warn only) │
|
||||
│ │
|
||||
│ [Create Schedule] Link: [Open Scheduler Runs] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Result: what you gain with Pack 14
|
||||
|
||||
* A promotion is now a **single auditable narrative**:
|
||||
|
||||
* timeline + logs + checkpoints,
|
||||
* policy decision trace,
|
||||
* deploy stage health gates,
|
||||
* rollback controls,
|
||||
* evidence sealing,
|
||||
* deterministic replay.
|
||||
* Hybrid reachability becomes a **2nd-class** signal woven into checkpoints (Policy + Post-Deploy Verify), not a top-level section.
|
||||
* Existing PoC pages remain valid, but are now **linked meaningfully** from the run storyline.
|
||||
|
||||
---
|
||||
|
||||
If you want the next pack: **Pack 15** will unify **Nightly Ops Report + Data Freshness** (feeds, rescans, integration degradation) into a single **Operations “Data Integrity”** view and show how it bubbles up to Dashboard/Releases/Approvals without duplicating screens.
|
||||
516
docs/modules/ui/v2-rewire/pack-15.md
Normal file
516
docs/modules/ui/v2-rewire/pack-15.md
Normal file
@@ -0,0 +1,516 @@
|
||||
## Pack 15 — Operations: **Data Integrity** (Nightly Ops Report + Data Freshness unified; bubbles into Dashboard / Releases / Approvals)
|
||||
|
||||
This pack creates a single **Operations → Data Integrity** area that answers:
|
||||
“**Can we trust today’s SBOM/CVE/reachability data to approve and promote? If not, what’s broken, where, and what decisions are impacted?**”
|
||||
|
||||
It **does not duplicate** existing specialized pages (Scheduler/Orchestrator/Integrations/Feeds). It **summarizes + links** to them.
|
||||
|
||||
---
|
||||
|
||||
# 15.1 Operations menu graph (Mermaid) — Data Integrity added as a first‑class Ops area
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
OPS[Operations] --> OPS_DI[Data Integrity]
|
||||
OPS --> OPS_PH[Platform Health]
|
||||
OPS --> OPS_ORCH[Orchestrator]
|
||||
OPS --> OPS_SCHED[Scheduler]
|
||||
OPS --> OPS_DLQ[Dead Letter]
|
||||
OPS --> OPS_QUOTA[Quotas]
|
||||
OPS --> OPS_EXPORT[Export]
|
||||
|
||||
OPS_DI --> DI_OV[Overview]
|
||||
OPS_DI --> DI_NIGHT[Nightly Ops Report]
|
||||
OPS_DI --> DI_FEEDS[Feeds Freshness]
|
||||
OPS_DI --> DI_SCAN[Scan Pipeline Health]
|
||||
OPS_DI --> DI_REACH[Reachability Ingest Health]
|
||||
OPS_DI --> DI_INTEG[Integration Connectivity]
|
||||
OPS_DI --> DI_DLQ[DLQ & Replays]
|
||||
OPS_DI --> DI_SLO[Data Quality SLOs]
|
||||
```
|
||||
|
||||
**Design intent:** “Data Integrity” is the operator console for **freshness + pipeline status** that directly affects approvals/promotions.
|
||||
|
||||
---
|
||||
|
||||
# 15.2 Bubble‑up graph (Mermaid) — how Data Integrity signals surface elsewhere (no duplication)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
DI[Ops: Data Integrity\n(single source of truth for data health)] --> DASH[Dashboard\nNightly Ops Signals card]
|
||||
DI --> REL[Releases List\nData Health column + banner]
|
||||
DI --> APR[Approvals\nOps/Data tab + warnings]
|
||||
DI --> SEC[Security Overview\nFeed freshness + scan freshness badges]
|
||||
DI --> ENV[Env Detail\nSBOM freshness + runtime coverage]
|
||||
|
||||
DI --> INT[Integrations Hub\nconnector config & tests]
|
||||
DI --> FEED[Feeds & AirGap Ops\nmirrors/locks/airgap artifacts]
|
||||
DI --> SCHED[Scheduler Runs]
|
||||
DI --> ORCH[Orchestrator Jobs]
|
||||
DI --> DLQ[Dead Letter]
|
||||
DI --> PH[Platform Health]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 15.3 Screen — Data Integrity Overview
|
||||
|
||||
### Previously (where it lived)
|
||||
|
||||
* There was **no single overview**.
|
||||
* Equivalent fragments existed in:
|
||||
|
||||
* **Nightly Ops Report** (your new screen request),
|
||||
* **Operations → Feeds** (freshness),
|
||||
* **Settings → Integrations** (connectivity),
|
||||
* **Settings → System → Background Jobs** (job failures),
|
||||
* **Operations → Dead Letter** (queue stuck),
|
||||
* plus scattered banners on approvals.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
You need **one** authoritative place to see:
|
||||
|
||||
* **SBOM scan / rescan status**
|
||||
* **CVE feed sync freshness**
|
||||
* **Integration connectivity**
|
||||
* **Reachability ingest health (build / image / runtime)**
|
||||
* **Which approvals/releases are currently “unsafe to approve” because data is stale**
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Data Integrity Overview] --> B[Nightly Ops Report]
|
||||
A --> C[Feeds Freshness]
|
||||
A --> D[Scan Pipeline Health]
|
||||
A --> E[Reachability Ingest Health]
|
||||
A --> F[Integration Connectivity]
|
||||
A --> G[DLQ & Replays]
|
||||
A --> H[Platform Health]
|
||||
A --> I[Impacted Decisions\n(approvals/releases)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ DATA INTEGRITY ▸ OVERVIEW │
|
||||
│ Legacy: N/A (new). Previously: Ops Feeds + Settings System Jobs + Integrations + DLQ scattered │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Scope: Region ▾ (All) Environment Type ▾ (All) Window ▾ (24h) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ DATA TRUST SCORE (for approvals/promotions) │
|
||||
│ Feeds Freshness: WARN (NVD stale 3h) SBOM Pipeline: FAIL (rescan job failing) │
|
||||
│ Reachability Ingest: WARN (runtime coverage 35%) Integrations: DEGRADED (Jenkins) │
|
||||
│ DLQ: WARN (reachability events queued: 1,230) │
|
||||
│ Links: [Nightly Ops Report] [Feeds Freshness] [Integrations] [DLQ] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ IMPACTED DECISIONS │
|
||||
│ Approvals blocked due to data issues: 2 │
|
||||
│ - Platform Release 1.3.0-rc1 → EU-West/eu-prod (SBOM incomplete + NVD stale) [Open] │
|
||||
│ Promotions running with WARN confidence: 1 [Open Releases filtered] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ TOP FAILURES (what to fix first) │
|
||||
│ 1) Nightly SBOM rescan FAILED (registry auth timeout) → stale SBOM on 12 component versions │
|
||||
│ 2) NVD feed stale 3h → CVE freshness gate WARN/FAIL depending on baseline │
|
||||
│ 3) Runtime reachability ingest lagging (agent-apac-01 degraded) → runtime coverage 35% │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 15.4 Screen — Nightly Ops Report (Jobs + causes + impact)
|
||||
|
||||
### Previously (where it lived)
|
||||
|
||||
* You asked for “some report about nightly jobs status” (new requirement).
|
||||
* Related fragments existed in:
|
||||
|
||||
* **Settings → System → Background Jobs**
|
||||
* **Operations → Scheduler** (runs)
|
||||
* **Operations → Orchestrator** (job execution)
|
||||
* plus manual checks in logs
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Nightly Ops Report becomes the **release‑impact view** of jobs:
|
||||
|
||||
* not just “job failed”
|
||||
* but **what release governance capability is now untrustworthy** (feeds/scans/reachability/evidence).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Nightly Ops Report] --> B[Job Run Detail]
|
||||
A --> C[Scheduler Runs]
|
||||
A --> D[Orchestrator]
|
||||
A --> E[DLQ & Replays]
|
||||
A --> F[Integrations Detail]
|
||||
A --> G[Impacted Bundles/Envs]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ DATA INTEGRITY ▸ NIGHTLY OPS REPORT │
|
||||
│ Legacy: Settings ▸ System ▸ Background Jobs + Ops Scheduler/Orchestrator (no release context) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Window: Last 24h Region: All │
|
||||
│ Summary: 7 jobs OK 2 WARN 2 FAIL │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Job Schedule Last Run Status Why it matters (release impact) │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ cve-sync-osv 02:00 02:01 OK vulnerability data freshness │
|
||||
│ cve-sync-nvd 02:05 02:05 WARN NVD stale → gating confidence drops │
|
||||
│ sbom-ingest-registry 02:10 02:10 OK new images get SBOM │
|
||||
│ sbom-nightly-rescan 02:20 02:21 FAIL stale SBOM → approvals may block │
|
||||
│ reachability-ingest-image 02:30 02:31 OK image reachability evidence │
|
||||
│ reachability-ingest-runtime 02:35 02:36 WARN runtime reach coverage degraded │
|
||||
│ evidence-seal-bundles 02:45 02:46 OK audit pack completion │
|
||||
│-------------------------------------------------------------------------------------------------│
|
||||
│ Row actions: [View Run] [Open Scheduler] [Open Orchestrator] [Open Integration] [Open DLQ] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 15.5 Screen — Job Run Detail (root cause + affected assets)
|
||||
|
||||
### Previously
|
||||
|
||||
* Scheduler/Orchestrator showed raw execution, but not mapped to:
|
||||
|
||||
* “affected environments”
|
||||
* “affected bundles”
|
||||
* “approvals degraded”
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This is the **investigation page** that bridges Ops mechanics to release decisions.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Job Run Detail] --> B[Logs & traces]
|
||||
A --> C[Failed items list\n(images/components/envs)]
|
||||
A --> D[Open DLQ bucket]
|
||||
A --> E[Open Integration Detail]
|
||||
A --> F[Show impacted approvals/releases]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Job Run Detail: sbom-nightly-rescan (Run #8841) │
|
||||
│ Legacy: Scheduler/Orchestrator run detail (without release impact mapping) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Status: FAIL Started: 02:21 Ended: 02:24 Error: registry auth timeout │
|
||||
│ Integration: Harbor Registry (token expired) → [Open Integration Detail] │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Affected items │
|
||||
│ - 12 images not rescanned (SBOM freshness > 24h) │
|
||||
│ - 3 bundle versions impacted (approvals may block) │
|
||||
│ - Regions impacted: EU-West, US-East │
|
||||
│ Links: [Open impacted approvals] [Open bundles] [Open DLQ bucket] [Open logs] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 15.6 Screen — Feeds Freshness (operator view, but tied to gating)
|
||||
|
||||
### Previously (where it lived)
|
||||
|
||||
* **Operations → Feeds** (“Feed Mirror & AirGap Operations” → Sources & Freshness)
|
||||
* Also partially visible as “feeds” cards under Integrations.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Feeds Freshness becomes a **Data Integrity subpage** because it’s primarily:
|
||||
|
||||
* “Can we trust vulnerability data for today’s approvals?”
|
||||
It still links to **Feeds & AirGap Ops** for mirrors/locks (no duplication).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Feeds Freshness] --> B[Feeds & AirGap Ops: Sources]
|
||||
A --> C[Version Locks]
|
||||
A --> D[Mirror Detail]
|
||||
A --> E[Impacted approvals\n(CVE freshness gate)]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ DATA INTEGRITY ▸ FEEDS FRESHNESS │
|
||||
│ Legacy: Operations ▸ Feeds ▸ Sources & Freshness (and partial cards in Integrations) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Region: EU-West SLA profile: Prod (fresh < 2h) │
|
||||
│ │
|
||||
│ Source Status Last Sync SLA Resulting gate impact │
|
||||
│----------------------------------------------------------------------------------------------- │
|
||||
│ OSV OK 20m ago 6h OK │
|
||||
│ NVD WARN 3h ago 2h approvals may WARN/FAIL depending baseline │
|
||||
│ CISA KEV OK 3h ago 24h OK │
|
||||
│ │
|
||||
│ Actions: [Open Feeds & AirGap Ops] [Apply Version Lock] [Retry NVD Sync] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 15.7 Screen — Scan Pipeline Health (SBOM ingest + rescan + vulnerability match)
|
||||
|
||||
### Previously
|
||||
|
||||
* SBOM status scattered across:
|
||||
|
||||
* Security views (findings)
|
||||
* Jobs views (background jobs)
|
||||
* Registry integration
|
||||
* No single “pipeline health” page to explain staleness.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
You explicitly require:
|
||||
|
||||
* “nightly SBOM re‑scan issues”
|
||||
* “CVE source not synced”
|
||||
This page shows the pipeline chain end‑to‑end and where it’s breaking.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Scan Pipeline Health] --> B[SBOM ingest status]
|
||||
A --> C[SBOM rescan status]
|
||||
A --> D[CVE match status]
|
||||
A --> E[Open Nightly Ops Report]
|
||||
A --> F[Open Integrations]
|
||||
A --> G[Open Security findings impact]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ DATA INTEGRITY ▸ SCAN PIPELINE HEALTH │
|
||||
│ Legacy: implied across Security + System Jobs + Registry integration │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Pipeline stages (last 24h) │
|
||||
│ 1) Image discovery (registry) OK new images: 48 │
|
||||
│ 2) SBOM generation/ingest OK sboms produced: 47 pending: 1 │
|
||||
│ 3) Nightly SBOM rescan FAIL 12 images stale > 24h │
|
||||
│ 4) CVE feeds sync WARN NVD stale 3h │
|
||||
│ 5) CVE ↔ SBOM match/update WARN results may be incomplete │
|
||||
│ │
|
||||
│ Impact summary │
|
||||
│ - Environments with “unknown SBOM freshness”: 2 (EU-West prod, APAC uat) │
|
||||
│ - Approvals blocked due to missing SBOM: 1 │
|
||||
│ Links: [Nightly Ops Report] [Feeds Freshness] [Integrations] [Security Findings] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 15.8 Screen — Reachability Ingest Health (Build / Image / Runtime)
|
||||
|
||||
### Previously
|
||||
|
||||
* Reachability was referenced in approvals/security, but ingestion health wasn’t first-class.
|
||||
* Runtime evidence depended on agent telemetry; failures were seen indirectly.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
You require hybrid reachability evidence from:
|
||||
|
||||
* **Dover image**
|
||||
* **build**
|
||||
* **running environment**
|
||||
This screen makes it operationally visible when one source is missing so reachability confidence is downgraded.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Reachability Ingest Health] --> B[Image/Dover ingest]
|
||||
A --> C[Build ingest]
|
||||
A --> D[Runtime ingest]
|
||||
A --> E[Agents health]
|
||||
A --> F[DLQ bucket]
|
||||
A --> G[Impact: approvals using reachability gate]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ DATA INTEGRITY ▸ REACHABILITY INGEST HEALTH │
|
||||
│ Legacy: implicit (Approvals/Security reachability columns) + Agent health elsewhere │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Coverage (last 24h) │
|
||||
│ Image/Dover: 100% (OK) Build: 78% (WARN) Runtime: 35% (WARN) │
|
||||
│ │
|
||||
│ Pipelines │
|
||||
│ Image/Dover ingest: OK last batch: 02:31 backlog: 0 │
|
||||
│ Build ingest: WARN last batch: 01:10 backlog: 220 (CI degraded) │
|
||||
│ Runtime ingest: WARN last batch: 00:55 backlog: 1,230 (agent-apac-01 degraded) │
|
||||
│ │
|
||||
│ Links: [Open Agents] [Open DLQ bucket] [Open impacted approvals] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 15.9 Screen — Integration Connectivity (data‑plane dependencies)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Settings → Integrations** (hub)
|
||||
* But release operators need a data-integrity lens: “which pipeline is broken because which connector is down?”
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This view is the “dependency slice” of Integrations:
|
||||
|
||||
* still links to the canonical **Integrations Hub** for configuration,
|
||||
* but shows **pipeline impact** directly (feeds/scans/reachability/evidence).
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Integration Connectivity] --> B[Integrations Hub]
|
||||
A --> C[Open Integration Detail]
|
||||
A --> D[Show dependent jobs]
|
||||
A --> E[Show impacted approvals/releases]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ DATA INTEGRITY ▸ INTEGRATION CONNECTIVITY │
|
||||
│ Legacy: Settings ▸ Integrations (no “pipeline impact” slice) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Connector Status Dependent pipelines Impact │
|
||||
│----------------------------------------------------------------------------------------------- │
|
||||
│ Harbor Registry WARN SBOM rescan, image discovery rescan failing │
|
||||
│ Jenkins DEGRADED build reachability ingest, attestations build coverage down │
|
||||
│ Vault OK env input materialization none │
|
||||
│ Consul OK env config bindings none │
|
||||
│ NVD Source DISCONNECTED CVE freshness approvals warn/block │
|
||||
│ │
|
||||
│ Actions per row: [Open Detail] [Test] [View dependent jobs] [View impacted approvals] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 15.10 Screen — DLQ & Replays (data pipelines stuck)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Operations → Dead Letter** existed, but not clearly integrated into “why approvals are unsafe.”
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This screen becomes the “last mile” of data integrity:
|
||||
|
||||
* When pipelines fail, DLQ grows.
|
||||
* DLQ items correspond to missing SBOM updates, missing reachability evidence, failed evidence sealing.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[DLQ & Replays] --> B[DLQ buckets by pipeline]
|
||||
A --> C[Item detail + payload]
|
||||
A --> D[Replay item]
|
||||
A --> E[Open Job Run Detail]
|
||||
A --> F[Open Integration Detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ DATA INTEGRITY ▸ DLQ & REPLAYS │
|
||||
│ Legacy: Operations ▸ Dead Letter (queue view without release impact context) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Buckets (24h) │
|
||||
│ reachability-runtime-ingest: 1,230 (agent degraded) │
|
||||
│ sbom-nightly-rescan: 340 (registry auth timeout) │
|
||||
│ evidence-seal-bundles: 12 (transparency log unreachable) │
|
||||
│ │
|
||||
│ Select bucket → items │
|
||||
│ item-7781 payload: runtime-trace batch#991 age: 2h action: [Replay] [View] [Link job] │
|
||||
│ item-7782 payload: runtime-trace batch#992 age: 2h action: [Replay] [View] [Link job] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 15.11 Screen — Data Quality SLOs (data‑SLO slice, links to System SLO Monitoring)
|
||||
|
||||
### Previously
|
||||
|
||||
* **Settings/System → SLO Monitoring** (or System root in the redesigned IA)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Keep SLO engine canonical under **System**, but provide a “data integrity slice” here so operators see:
|
||||
|
||||
* feed freshness SLO
|
||||
* SBOM staleness SLO
|
||||
* runtime coverage SLO
|
||||
…with deep links to the full SLO view.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Data Quality SLOs] --> B[System SLO Monitoring (canonical)]
|
||||
A --> C[Show SLO breaches that impact approvals]
|
||||
A --> D[Open impacted approvals/releases]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ OPERATIONS ▸ DATA INTEGRITY ▸ DATA QUALITY SLOs │
|
||||
│ Legacy: System ▸ SLO Monitoring (not scoped to data integrity) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ SLO Target Current Status Approval impact │
|
||||
│----------------------------------------------------------------------------------------------- │
|
||||
│ CVE feed freshness (NVD/OSV) <2h 3h WARN gate may warn/fail │
|
||||
│ SBOM staleness (prod envs) <24h 12 stale FAIL blocks prod promotions │
|
||||
│ Runtime reach coverage (prod) >50% 35% WARN reduces confidence │
|
||||
│ │
|
||||
│ Links: [Open System SLO Monitoring] [Open impacted approvals] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What this pack changes on other screens (without duplicating them)
|
||||
|
||||
These are *UI hooks* (badges/banners/cards) driven by Data Integrity:
|
||||
|
||||
* **Dashboard**: “Nightly Ops Signals” card points to **Ops → Data Integrity Overview**.
|
||||
* **Releases list**: “Data Health” column/badge links to **Data Integrity Overview** filtered to the region.
|
||||
* **Approvals**: “Ops/Data” tab links to **Data Integrity Overview** + the exact failing job/feed/DLQ bucket.
|
||||
* **Security Overview**: shows “feeds fresh / stale” and “SBOM freshness” badges, with a link to Data Integrity.
|
||||
|
||||
---
|
||||
|
||||
If you want the next pack: **Pack 16** can update the **Dashboard** mock explicitly to add the “Nightly Ops Signals” card and the **SBOM + reachable criticals by environment** summary you requested earlier, wired directly into the Data Integrity + Security + Env Detail pages.
|
||||
238
docs/modules/ui/v2-rewire/pack-16.md
Normal file
238
docs/modules/ui/v2-rewire/pack-16.md
Normal file
@@ -0,0 +1,238 @@
|
||||
## Pack 16 — Dashboard upgrade: **SBOM findings + critical reachable by env**, **per‑env deploy+SBOM status**, and **Nightly Ops/Data Integrity** signals (wired, not duplicated)
|
||||
|
||||
This pack keeps the re-org intact (release-centric). It upgrades the **Dashboard (formerly “Control Plane”)** so the operator immediately sees:
|
||||
|
||||
* **“No issues” vs “X environments with critical reachable issues”** (and which envs)
|
||||
* **Per-environment status** that includes **deploy/runtime** *and* **image SBOM status**
|
||||
* **Nightly jobs + data freshness** issues that directly affect gating/approvals (CVE feeds, SBOM rescan, integration health)
|
||||
* **Hybrid reachability** coverage (Build / Image / Runtime) as **2nd-class** signal on the dashboard
|
||||
|
||||
---
|
||||
|
||||
# 16.1 Dashboard navigation graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
DASH[Dashboard\n(formerly: Control Plane)] --> REL[Releases]
|
||||
DASH --> APPR[Approvals]
|
||||
DASH --> DEPLOY[Deployments / Promotion Runs]
|
||||
DASH --> REGENV[Regions & Environments]
|
||||
DASH --> FIND[Security Findings\n(filtered)]
|
||||
DASH --> RISK[Risk Overview]
|
||||
DASH --> DI[Ops: Data Integrity]
|
||||
DASH --> FEEDS[Ops: Feeds & AirGap]
|
||||
DASH --> INT[Integrations Hub]
|
||||
DASH --> EVID[Evidence & Audit]
|
||||
|
||||
%% What cards link to
|
||||
DASH --> CARD_SBOM[Card: SBOM Findings Snapshot]
|
||||
CARD_SBOM --> FIND
|
||||
|
||||
DASH --> CARD_HYB[Card: Hybrid Reachability Coverage]
|
||||
CARD_HYB --> RISK
|
||||
|
||||
DASH --> CARD_DI[Card: Nightly Ops Signals]
|
||||
CARD_DI --> DI
|
||||
|
||||
DASH --> CARD_PIPE[Regional Promotion Pipelines]
|
||||
CARD_PIPE --> REGENV
|
||||
CARD_PIPE --> REL
|
||||
|
||||
DASH --> CARD_APPR[Card: Pending Approvals]
|
||||
CARD_APPR --> APPR
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 16.2 Screen — Dashboard (v3) — release-centric + “security reality” surfaced
|
||||
|
||||
### Formerly (where it lived pre-redesign)
|
||||
|
||||
* **Control Plane** was the root screen.
|
||||
* It showed:
|
||||
|
||||
* environment pipeline (Dev/Staging/UAT/Prod) *without regions*
|
||||
* pending approvals + active deployments + recent releases
|
||||
* **SBOM findings / critical reachable issues** were effectively buried:
|
||||
|
||||
* **Security → Findings**
|
||||
* **Security → Overview**
|
||||
* **Nightly jobs / data freshness / integration drift** were scattered:
|
||||
|
||||
* **Operations → Feeds**
|
||||
* **Settings → Integrations**
|
||||
* **Settings → System → Background Jobs**
|
||||
* **Operations → Scheduler / Dead Letter**
|
||||
|
||||
### Why it’s changed like this
|
||||
|
||||
Stella Ops is about **promotion-by-digest with defensible security + evidence**.
|
||||
So the home screen must answer (in <30 seconds):
|
||||
|
||||
1. **Can I safely approve/promote right now?** (data fresh? feeds OK? rescans OK? integrations OK?)
|
||||
2. **Where are my critical reachable issues?** (which envs, which CVEs, what reachability confidence?)
|
||||
3. **Are environments healthy AND do they have SBOM coverage?** (runtime + SBOM freshness/coverage together)
|
||||
|
||||
This keeps reachability **2nd-class** (dashboard + risk drilldowns), not a top-level “product area”.
|
||||
|
||||
---
|
||||
|
||||
## Dashboard screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Dashboard] --> B[Regional Promotion Pipelines\n(per region: Dev→Stage→UAT→Prod nodes)]
|
||||
A --> C[Environments at Risk table\n(deploy + SBOM + CritR + B/I/R)]
|
||||
A --> D[SBOM Findings Snapshot card\n(no issues vs envs with CritR)]
|
||||
A --> E[Hybrid Reachability Coverage card\n(Build/Image/Runtime)]
|
||||
A --> F[Nightly Ops Signals card\n(Data Integrity)]
|
||||
A --> G[Pending Approvals card]
|
||||
A --> H[Active Deployments card]
|
||||
A --> I[Recent Releases table]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Dashboard (v3)
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ DASHBOARD (Formerly: Control Plane) │
|
||||
│ Purpose: release-centric status across regions: promotion + risk + proof + data freshness │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Search: [ releases, digests, CVEs...________________________ ] Org: Acme Region: All Window:24h│
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ REGIONAL PROMOTION PIPELINES (nodes show: Deploy + SBOM + CritR + Hybrid reach B/I/R) │
|
||||
│ │
|
||||
│ US-East [Dev: Deploy OK | SBOM OK | CritR 0 | B/I/R 3/3] → [Stage: OK | OK | 0 | 3/3] → │
|
||||
│ [UAT: OK | OK | 1 | 2/3] → [Prod: DEGRADED | SBOM STALE | CritR 2 | 2/3] │
|
||||
│ │
|
||||
│ EU-West [Dev: OK | OK | 0 | 3/3] → [Stage: OK | OK | 0 | 3/3] → [UAT: OK | OK | 0 | 3/3] → │
|
||||
│ [Prod: OK | OK | 0 | 3/3] │
|
||||
│ │
|
||||
│ APAC [Dev: OK | SBOM MISSING(2 imgs) | CritR 0 | 2/3] → [Stage: OK | OK | 0 | 2/3] → │
|
||||
│ [UAT: UNKNOWN | OK | 0 | 2/3] → [Prod: OK | OK | 0 | 2/3] │
|
||||
│ │
|
||||
│ Click a node → Env Detail (deploy + SBOM status + findings + evidence + inputs) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ENVIRONMENTS AT RISK (top 5) │
|
||||
│ ┌───────────────┬───────────────┬──────────────┬─────────────┬───────────┬──────────┬──────────┐ │
|
||||
│ │ Region/Env │ Deploy Health │ SBOM Status │ Crit Reach │ Hybrid B/I/R │ Last SBOM │ Action │ │
|
||||
│ ├───────────────┼───────────────┼──────────────┼─────────────┼───────────┼──────────┼──────────┤ │
|
||||
│ │ US-East / Prod │ DEGRADED │ STALE (26h) │ 2 │ 2/3 │ 26h │ [Open] │ │
|
||||
│ │ US-East / UAT │ OK │ OK │ 1 │ 2/3 │ 2h │ [Open] │ │
|
||||
│ │ APAC / Dev │ OK │ MISSING (2) │ 0 │ 2/3 │ — │ [Open] │ │
|
||||
│ └───────────────┴───────────────┴──────────────┴─────────────┴───────────┴──────────┴──────────┘ │
|
||||
│ Notes: SBOM Status reflects image SBOM coverage+freshness; Deploy reflects runtime/service health │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ SNAPSHOTS (cards) │
|
||||
│ ┌──────────────────────────────┬──────────────────────────────┬──────────────────────────────┬──┐│
|
||||
│ │ SBOM Findings Snapshot │ Hybrid Reachability Coverage │ Nightly Ops Signals (Data │Pending│
|
||||
│ │ (click → details drawer) │ (Build/Image/Runtime) │ Integrity) (click → Ops) │Approvals│
|
||||
│ │ │ │ │(2) │
|
||||
│ │ Crit reachable envs: 2 │ Build: OK (02:10) │ SBOM rescan: FAIL │ - API │
|
||||
│ │ Crit reachable total: 3 │ Image: OK (02:12) │ NVD feed: STALE (3h) │ Gateway│
|
||||
│ │ No issues envs: 5 │ Runtime: WARN (APAC missing) │ Jenkins: DEGRADED │ Gate: │
|
||||
│ │ Top envs: US-East Prod, UAT │ Hybrid verdict: 2/3 in US-East│ DLQ: 1,230 runtime events │ PASS/ │
|
||||
│ │ [Open Findings] │ [Open Risk] │ [Open Data Integrity] │ BLOCK │
|
||||
│ └──────────────────────────────┴──────────────────────────────┴──────────────────────────────┴──┘│
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ACTIVE DEPLOYMENTS │
|
||||
│ Hotfix 1.2.4 → US-East Prod (RUNNING) [Open Run Timeline] │
|
||||
│ │
|
||||
│ RECENT RELEASES │
|
||||
│ Hotfix 1.2.4 PROMOTING US-East Stage→Prod Components: 1 [Review] │
|
||||
│ Platform 1.3.0-rc1 READY EU-West Stage→Prod Components: 4 [Review] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Key dashboard upgrades vs prior Control Plane**
|
||||
|
||||
* Pipeline nodes now show **Deploy + SBOM status + Crit reachable + Hybrid coverage** in-line.
|
||||
* A dedicated **“Environments at Risk”** table makes “env N and env M with findings” explicit.
|
||||
* **Nightly Ops Signals** is a first-class dashboard card but links to **Ops → Data Integrity** (no duplication).
|
||||
|
||||
---
|
||||
|
||||
# 16.3 Screen — SBOM Findings Snapshot (dashboard drawer / panel)
|
||||
|
||||
This satisfies your “with details” requirement **without creating a new top-level screen**.
|
||||
|
||||
### Formerly (where it lived)
|
||||
|
||||
* Details were only available by going to:
|
||||
|
||||
* **Security → Findings** and filtering
|
||||
* sometimes **Security → Overview**
|
||||
* There wasn’t a dashboard-level “what’s actually burning” view.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Operators need fast answers:
|
||||
|
||||
* which environments are impacted,
|
||||
* how many **critical reachable**,
|
||||
* what packages/CVEs,
|
||||
* and what reachability evidence exists (Build / Image / Runtime).
|
||||
|
||||
This drawer is “2nd-class”: it’s a **dashboard drilldown**, not a new top menu.
|
||||
|
||||
---
|
||||
|
||||
## Drawer screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Dashboard: SBOM Findings Snapshot Drawer] --> B[Env list with CritR counts]
|
||||
A --> C[Top CVEs/packages per env]
|
||||
A --> D[Reachability evidence by source\n(Build/Image/Runtime)]
|
||||
A --> E[Actions: Open Findings filtered]
|
||||
A --> F[Actions: Open Env Detail]
|
||||
A --> G[Actions: Request Exception / Create Work Item]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — SBOM Findings Snapshot Drawer
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SBOM FINDINGS SNAPSHOT (Drawer) │
|
||||
│ Formerly: Security ▸ Findings (manual filtering) │
|
||||
│ Why: show “no issues vs critical reachable envs” + immediate details from the Dashboard │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Summary (24h): │
|
||||
│ Critical reachable envs: 2 Total Crit reachable: 3 Envs with no findings: 5 │
|
||||
│ Data confidence: WARN (NVD stale 3h, runtime ingest lag) │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Environments with Critical Reachable │
|
||||
│ ┌──────────────────┬───────────┬───────────────┬───────────────┬───────────────┬───────────┐ │
|
||||
│ │ Region/Env │ CritR │ Top CVE │ Top Package │ Reach evidence│ Actions │ │
|
||||
│ ├──────────────────┼───────────┼───────────────┼───────────────┼───────────────┼───────────┤ │
|
||||
│ │ US-East / Prod │ 2 │ CVE-2026-1234 │ openssl │ B/I/R: 2/3 │ [Env] [Find]│
|
||||
│ │ │ │ CVE-2026-9001 │ log4j │ Runtime: WARN │ [Exception]│
|
||||
│ │ US-East / UAT │ 1 │ CVE-2026-2222 │ glibc │ B/I/R: 2/3 │ [Env] [Find]│
|
||||
│ └──────────────────┴───────────┴───────────────┴───────────────┴───────────────┴───────────┘ │
|
||||
│ Notes: “Reach evidence” reflects hybrid sources: Build (static), Image (Dover/scan), Runtime. │
|
||||
├───────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Quick filters: [Only CritR] [Only Reachable] [Only Prod] [Only SBOM stale/missing] │
|
||||
│ Links: [Open Security Findings (filtered)] [Open Risk Overview] │
|
||||
└───────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What changes elsewhere (just wiring, no new screens)
|
||||
|
||||
* Clicking an **environment node** or an **at-risk table row** goes to **Regions & Environments → Env Detail**, where you already have:
|
||||
|
||||
* deploy/runtime state,
|
||||
* image SBOM coverage/freshness,
|
||||
* findings,
|
||||
* reachability summary,
|
||||
* evidence + inputs.
|
||||
* Clicking **Nightly Ops Signals** goes to **Ops → Data Integrity Overview** (Pack 15).
|
||||
|
||||
---
|
||||
|
||||
If you confirm this dashboard direction is correct, **Pack 17** will apply the same “data health + SBOM status + Crit reachable + B/I/R” pattern into the **Approvals** detail view (so approvers see exactly why a gate is PASS/WARN/BLOCK and what data is missing) without making reachability a top-level menu.
|
||||
556
docs/modules/ui/v2-rewire/pack-17.md
Normal file
556
docs/modules/ui/v2-rewire/pack-17.md
Normal file
@@ -0,0 +1,556 @@
|
||||
## Pack 17 — Approvals upgraded: **SBOM + Crit‑Reachable by env**, **SBOM freshness/coverage**, **Hybrid Reachability (B/I/R)**, and **Data Integrity confidence** (feeds/jobs/integrations) shown *inside* the approval flow
|
||||
|
||||
This pack does **not** add new top-level areas. It upgrades **Approvals** so approvers can make defensible decisions *without hunting* across Security/Ops/Integrations.
|
||||
|
||||
---
|
||||
|
||||
# 17.1 Approvals menu graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
APPR[Approvals] --> Q[Approvals Queue]
|
||||
Q --> AD[Approval Detail]
|
||||
|
||||
AD --> AD_OV[Overview]
|
||||
AD --> AD_G[Gate Trace]
|
||||
AD --> AD_S[Security\n(SBOM + Findings)]
|
||||
AD --> AD_R[Reachability\n(Hybrid B/I/R)]
|
||||
AD --> AD_D[Ops/Data Health\n(Data Integrity)]
|
||||
AD --> AD_E[Evidence\n(Decision Packet)]
|
||||
AD --> AD_RV[Replay/Verify]
|
||||
AD --> AD_H[History]
|
||||
|
||||
%% Cross-links (2nd-class, not duplication)
|
||||
AD_D -. "links to" .-> DI[Operations: Data Integrity]
|
||||
AD_S -. "links to" .-> FIND[Security: Findings]
|
||||
AD_S -. "links to" .-> VEX[Security: VEX Hub]
|
||||
AD_E -. "links to" .-> EXPORT[Evidence: Export Center]
|
||||
AD_G -. "links to" .-> GOV[Release Control: Governance]
|
||||
AD_R -. "links to" .-> RCENV[Release Control: Env Detail]
|
||||
AD_OV -. "links to" .-> BV[Bundle Version Detail]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 17.2 Screen — Approvals Queue (v2)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Approvals** (`/approvals`)
|
||||
Cards/rows: bundle/release, env path, policy PASS/BLOCK, approvals count, approve/reject.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
You asked for:
|
||||
|
||||
* “**X environments with critical reachable issues**” surfaced early,
|
||||
* “**nightly jobs status** when SBOM rescan/CVE feeds/integrations are broken,”
|
||||
* “**hybrid reachability** as second-class (not buried).”
|
||||
|
||||
So the queue now shows, per approval item:
|
||||
|
||||
* **Target env risk snapshot** (Crit reachable counts **in that env**)
|
||||
* **SBOM freshness/coverage** (so you can see “stale/unknown” immediately)
|
||||
* **Hybrid reachability coverage** (Build/Image/Runtime) as a compact confidence indicator
|
||||
* **Data Integrity confidence** (feeds/jobs/integrations) as a banner/badge
|
||||
|
||||
---
|
||||
|
||||
## Queue screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Q[Approvals Queue] --> F[Filters\n(region/env/status/risk/data-health)]
|
||||
Q --> AD[Open Approval Detail]
|
||||
Q --> BV[Open Bundle Version Detail]
|
||||
Q --> DI[Open Ops: Data Integrity (filtered)]
|
||||
Q --> FIND[Open Findings (filtered)]
|
||||
Q --> RCENV[Open Env Detail]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Approvals Queue (v2)
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ APPROVALS │
|
||||
│ Formerly: Approvals (/approvals) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Status [Pending] Region [All] Env [All] Risk [All] Data Health [All] │
|
||||
│ Banner: Data Integrity WARN — NVD stale 3h | SBOM rescan FAILED | Runtime ingest lagging │
|
||||
│ [Open Data Integrity] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌───────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Platform Release 1.3.0-rc1 (manifest sha256:beef...) │ │
|
||||
│ │ Target: EU-West eu-stage → eu-prod │ │
|
||||
│ │ Justification: scheduled release (rate limiting + bug fixes) │ │
|
||||
│ │ Gates: BLOCK (2/4) Approvals: 0/2 │ │
|
||||
│ │ Target-env risk: eu-prod → CritR=1 | HighR=0 | HighNR=3 | VEX=62% │ │
|
||||
│ │ SBOM status: 1 pending scan | freshness: WARN (26h) │ │
|
||||
│ │ Hybrid reach: Build 78% | Image 100% | Runtime 35% │ │
|
||||
│ │ Data health: WARN (NVD stale; rescan failed) │ │
|
||||
│ │ Actions: [View Details] [Approve]* [Reject] [Open Env] [Open Findings] │ │
|
||||
│ │ *Approve disabled until blocking gates resolved OR exception approved │ │
|
||||
│ └───────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ ┌───────────────────────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Hotfix Bundle 1.2.4 (manifest sha256:abcd...) │ │
|
||||
│ │ Target: US-East us-stage → us-prod │ │
|
||||
│ │ Justification: critical auth timeout fix │ │
|
||||
│ │ Gates: PASS (4/4) Approvals: 1/2 │ │
|
||||
│ │ Target-env risk: us-prod → clean │ │
|
||||
│ │ SBOM status: OK | freshness: OK (2h) │ │
|
||||
│ │ Hybrid reach: Build 100% | Image 100% | Runtime 80% │ │
|
||||
│ │ Data health: OK │ │
|
||||
│ │ Actions: [View Details] [Approve] [Reject] │ │
|
||||
│ └───────────────────────────────────────────────────────────────────────────────────────────┘ │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 17.3 Screen — Approval Detail: Overview (v2)
|
||||
|
||||
### Formerly
|
||||
|
||||
* “View Details” from Approvals cards (not fully structured), with some gate summary.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Approver needs a single-page decision briefing:
|
||||
|
||||
* What is being approved: **Bundle Version + manifest digest**
|
||||
* Where: **region + env path**
|
||||
* Risk: **Crit reachable in target env** + delta vs current
|
||||
* Confidence: **SBOM freshness/coverage** + **hybrid reachability coverage** + **data integrity**
|
||||
* Audit: quick link to **decision packet** and **replay/verify**
|
||||
|
||||
---
|
||||
|
||||
## Overview screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
AD[Approval Detail] --> OV[Overview]
|
||||
OV --> G[Gates tab]
|
||||
OV --> S[Security tab]
|
||||
OV --> R[Reachability tab]
|
||||
OV --> D[Ops/Data tab]
|
||||
OV --> E[Evidence tab]
|
||||
OV --> RV[Replay/Verify tab]
|
||||
OV --> H[History tab]
|
||||
|
||||
OV --> BV[Bundle Version Detail]
|
||||
OV --> RCENV[Env Detail]
|
||||
OV --> DI[Data Integrity (filtered)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Approval Detail Overview (v2)
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ APPROVAL DETAIL │
|
||||
│ Formerly: Approvals → “View Details” card (limited context) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundle Version: Platform Release 1.3.0-rc1 manifest sha256:beef... │
|
||||
│ Target: EU-West eu-stage → eu-prod Workflow: Canary 10→50→100 │
|
||||
│ Requested by: alice.johnson Requested: 36d ago │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Decision readiness │
|
||||
│ Gates: BLOCK (2/4) | Approvals: 0/2 │
|
||||
│ Target-env risk (eu-prod): CritR=1 | HighR=0 | HighNR=3 | VEX=62% │
|
||||
│ SBOM: 1 component pending scan | freshness WARN (26h) │
|
||||
│ Hybrid reach coverage: Build 78% | Image 100% | Runtime 35% │
|
||||
│ Data Integrity: WARN (NVD stale 3h; rescan job FAIL; Jenkins degraded) │
|
||||
│ │
|
||||
│ Actions: [Approve]* [Reject] [Request Exception] [Export Decision Packet] [Replay/Verify] │
|
||||
│ *Approve disabled until blocking gates resolved or exception approved │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Gates] [Security] [Reachability] [Ops/Data] [Evidence] [Replay/Verify] [History] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 17.4 Screen — Approval Detail: Gates (Trace + “why” + timestamps)
|
||||
|
||||
### Formerly
|
||||
|
||||
* PASS/BLOCK indicator, sometimes with a short reason.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Approver must see:
|
||||
|
||||
* which gate failed,
|
||||
* exactly why,
|
||||
* which datasets/timestamps were used,
|
||||
* whether results are “hard fail” vs “warn due to missing confidence”,
|
||||
* and where to fix (links to Data Integrity / Env Inputs / Findings / Exceptions).
|
||||
|
||||
---
|
||||
|
||||
## Gates screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
G[Gates tab] --> GT[Gate table (PASS/WARN/BLOCK)]
|
||||
GT --> GD[Gate detail trace (inputs, timestamps, hashes)]
|
||||
G --> GOV[Release Control: Governance baseline/rules]
|
||||
G --> DI[Ops: Data Integrity (why stale?)]
|
||||
G --> FIND[Security: Findings (blocking CVE)]
|
||||
G --> EX[Security: Exceptions (request/track)]
|
||||
G --> RV[Replay/Verify this gate evaluation]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Gates (Trace)
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Gates (Trace) │
|
||||
│ Formerly: PASS/BLOCK on approvals card, limited trace │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Baseline: Prod-EU-West Evaluated: Feb 18, 08:30 │
|
||||
│ Data snapshot: OSV 20m | NVD 3h (WARN) | SBOM rescan FAIL (stale>24h present) │
|
||||
│ Decision digest: sha256:dd77... (exported in Evidence tab) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Gate Result Why │
|
||||
│------------------------------------------------------------------------------------------------│
|
||||
│ Inputs materialized PASS Vault/Consul resolved, 0 missing bindings │
|
||||
│ SBOM completeness BLOCK worker digest pending scan (required for prod) │
|
||||
│ Critical reachable CVEs BLOCK CVE-2026-1234 reachable in eu-prod; no VEX │
|
||||
│ Feed freshness WARN NVD stale 3h (baseline threshold 2h) │
|
||||
│ Runtime reach coverage WARN runtime evidence 35% (baseline: warn) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Fix links: [Trigger SBOM Scan] [Open Finding] [Request Exception] [Open Data Integrity] │
|
||||
│ Forensics: [Replay Gate Eval] [Open Governance Rules] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 17.5 Screen — Approval Detail: Security (SBOM + Findings, by env, with delta)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Security findings were under **Security → Findings**, detached from the approval.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Approver must see:
|
||||
|
||||
* **which env** is impacted (eu-prod vs eu-stage)
|
||||
* whether the promotion **introduces** the risk or it already exists
|
||||
* SBOM status per component (missing/pending/stale)
|
||||
* VEX coverage and exceptions posture
|
||||
|
||||
Hybrid reachability remains separate tab; here we focus on “what the SBOM says + what the scanner says.”
|
||||
|
||||
---
|
||||
|
||||
## Security tab graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
S[Security tab] --> SUM[Summary by severity + reachability class]
|
||||
S --> ENV[By-environment breakdown]
|
||||
S --> DELTA[Delta vs currently deployed in target env]
|
||||
S --> CVE[Top CVEs / packages list]
|
||||
S --> VEX[VEX Hub (filtered)]
|
||||
S --> FIND[Findings (filtered)]
|
||||
S --> EX[Exceptions (filtered)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Security tab
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Security (SBOM + Findings) │
|
||||
│ Formerly: Security → Findings / Overview (manual filtering from approvals) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Target env: EU-West / eu-prod │
|
||||
│ Summary: CritR=1 | HighR=0 | HighNR=3 | VEX coverage=62% | SBOM freshness WARN (26h) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ By environment │
|
||||
│ eu-stage: CritR=0 (clean) │
|
||||
│ eu-prod : CritR=1 (CVE-2026-1234 in user-service sha256:2222...) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Delta vs currently deployed in eu-prod │
|
||||
│ +1 Critical reachable introduced by this bundle version │
|
||||
│ +2 High not reachable unchanged │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Top issues (click to open finding detail) │
|
||||
│ - CVE-2026-1234 package: openssl component: user-service reach: reachable VEX: none │
|
||||
│ - CVE-2026-9001 package: log4j component: api-gateway reach: not reachable VEX: present │
|
||||
│ Links: [Open Findings (filtered)] [Open VEX Hub] [Open Exceptions] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 17.6 Screen — Approval Detail: Reachability (Hybrid B/I/R)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Reachability referenced in approvals but not clearly broken down by evidence source.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
You require:
|
||||
|
||||
* reachability from **image (Dover)**,
|
||||
* from **build**,
|
||||
* from **running environment**.
|
||||
This tab makes it explicit and also signals **confidence** (coverage + evidence age) without being top-level.
|
||||
|
||||
---
|
||||
|
||||
## Reachability tab graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
R[Reachability tab] --> COV[Coverage: Build/Image/Runtime]
|
||||
R --> AGE[Evidence age per source]
|
||||
R --> COMP[Per-component B/I/R matrix]
|
||||
R --> POL[Policy interpretation (warn/block)]
|
||||
R --> DI[Ops: Data Integrity → Reachability ingest health]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Reachability tab
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Reachability (Hybrid B/I/R) │
|
||||
│ Formerly: referenced in approvals/gates, not clearly sourced │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Coverage: Build 78% | Image 100% | Runtime 35% │
|
||||
│ Evidence age: Build 7h | Image 1h | Runtime 26h │
|
||||
│ Policy: runtime coverage < 50% → WARN (does not block) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Component matrix │
|
||||
│ api-gateway sha256:1111... Build ✓ Image ✓ Runtime ✗ │
|
||||
│ user-service sha256:2222... Build ✗ Image ✓ Runtime ✗ │
|
||||
│ web-frontend sha256:3333... Build ✓ Image ✓ Runtime ✓ │
|
||||
│ Links: [Open Reachability Ingest Health] [Open Env Detail] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 17.7 Screen — Approval Detail: Ops/Data Health (confidence panel wired to Data Integrity)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Feed freshness and job status were outside approvals.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Approvals must clearly state when:
|
||||
|
||||
* SBOM rescans are failing,
|
||||
* feeds are stale,
|
||||
* integrations are degraded,
|
||||
because the approval is otherwise *not defensible*.
|
||||
|
||||
This tab *summarizes* and links to **Ops → Data Integrity** (single source of truth).
|
||||
|
||||
---
|
||||
|
||||
## Ops/Data tab graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
D[Ops/Data tab] --> FEED[Feeds freshness snapshot]
|
||||
D --> JOBS[Nightly jobs snapshot]
|
||||
D --> INT[Integration connectivity snapshot]
|
||||
D --> DLQ[DLQ status snapshot]
|
||||
D --> DI[Open Data Integrity (filtered)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Ops/Data tab
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Ops/Data Health │
|
||||
│ Formerly: Ops Feeds + System Jobs + Integrations (manual context switching) │
|
||||
├───────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Feeds │
|
||||
│ OSV: OK (20m) NVD: WARN (3h stale; threshold 2h) KEV: OK (3h) │
|
||||
│ Nightly jobs │
|
||||
│ sbom-nightly-rescan: FAIL (registry auth timeout) → 12 images stale > 24h │
|
||||
│ reachability-runtime-ingest: WARN (agent degraded) → runtime coverage down │
|
||||
│ Integrations │
|
||||
│ Harbor: WARN (token expiry) Jenkins: DEGRADED Vault: OK Consul: OK │
|
||||
│ DLQ │
|
||||
│ runtime-ingest bucket: 1,230 items │
|
||||
│ │
|
||||
│ Actions: [Open Data Integrity] [Open Integrations] [Open Scheduler Runs] [Open DLQ]│
|
||||
└───────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 17.8 Screen — Approval Detail: Evidence (Decision Packet)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Evidence existed in Evidence area; approvals didn’t present a consolidated “decision packet”.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Approvals should create an exportable, auditable “decision packet” that includes:
|
||||
|
||||
* bundle manifest digest,
|
||||
* gate trace,
|
||||
* data snapshot (feeds freshness + job status),
|
||||
* approver rationale,
|
||||
* signatures / transparency log receipts (if configured).
|
||||
|
||||
---
|
||||
|
||||
## Evidence tab graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
E[Evidence tab] --> PKT[Decision Packet items]
|
||||
E --> SIGN[Signature status + key]
|
||||
E --> TLOG[Transparency log receipts]
|
||||
E --> EXPORT[Export (PDF/JSON bundle)]
|
||||
E --> CHAIN[Proof chain (if sealed)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Evidence tab
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Evidence (Decision Packet) │
|
||||
│ Formerly: Evidence existed separately; approvals didn’t present a unified packet │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Decision packet │
|
||||
│ ✓ policy-decision.dsse (digest sha256:dd77...) │
|
||||
│ ✓ gate-trace.json │
|
||||
│ ✓ data-snapshot.json (feeds + jobs + integrations) │
|
||||
│ ○ proof-chain.json (sealed on promotion completion) │
|
||||
│ Signatures: policy-k1 (valid) | Transparency log: rekor receipt present │
|
||||
│ Actions: [Export Packet] [Open Export Center] [Open Proof Chain] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 17.9 Screen — Approval Detail: Replay/Verify (contextual)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Evidence → Replay/Verify** existed as standalone (“Verdict Replay”).
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Approver should be able to replay the exact gate evaluation in-place:
|
||||
|
||||
* prefilled verdict id,
|
||||
* bundle manifest digest,
|
||||
* policy baseline,
|
||||
* dataset snapshot / version lock (if used).
|
||||
|
||||
---
|
||||
|
||||
## Replay/Verify tab graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RV[Replay/Verify tab] --> REQ[Request replay (prefilled)]
|
||||
RV --> LIST[Replay requests list]
|
||||
RV --> MET[Determinism metrics]
|
||||
RV --> LINK[Link to canonical Evidence → Replay/Verify]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Replay/Verify tab
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Replay/Verify │
|
||||
│ Formerly: Evidence → Replay/Verify (standalone) │
|
||||
├───────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Prefilled replay request │
|
||||
│ Verdict ID: verdict-123 │
|
||||
│ Bundle manifest: sha256:beef... │
|
||||
│ Baseline: Prod-EU-West │
|
||||
│ Data snapshot: OSV 20m | NVD 3h | rescan FAIL │
|
||||
│ [Request Replay] │
|
||||
│ Recent replays: rr-001 COMPLETED (match) | rr-002 RUNNING │
|
||||
│ Link: [Open canonical Replay/Verify] │
|
||||
└───────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 17.10 Screen — Approval Detail: History (decision lifecycle)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Partial “age” fields existed, but not a full lifecycle ledger tied to evidence.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Auditors and incident responders need:
|
||||
|
||||
* who requested,
|
||||
* who approved/rejected,
|
||||
* when gates changed (due to new scans/feeds),
|
||||
* when exceptions were requested/applied,
|
||||
* and links to the evidence packet versions.
|
||||
|
||||
---
|
||||
|
||||
## History tab graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
H[History tab] --> EVT[Event timeline]
|
||||
H --> COM[Comments/Rationales]
|
||||
H --> PKT[Evidence packet versions]
|
||||
H --> LINK[Links to related release/promotion run]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — History tab
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||||
│ History │
|
||||
│ Formerly: limited timestamps in approvals list │
|
||||
├───────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Feb 18 08:30 Gate eval: BLOCK (CVE-2026-1234 reachable; SBOM pending) │
|
||||
│ Feb 18 08:31 Data health changed: NVD stale 3h (WARN) │
|
||||
│ Feb 18 08:32 Exception requested by alice.johnson │
|
||||
│ Feb 18 08:40 Evidence packet exported (v2) │
|
||||
│ Links: [Open Evidence Packet] [Open Promotion] [Open Exception] │
|
||||
└───────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Net effect (what you asked for, achieved here)
|
||||
|
||||
* **SBOM findings + critical reachable per environment** are **first visible** in the approval queue and detail.
|
||||
* **SBOM status** is treated as part of “environment readiness” and “decision readiness,” not an afterthought.
|
||||
* **Nightly jobs + feed freshness + integration connectivity** are shown in the approval context, but remain owned by **Ops → Data Integrity** (no duplication).
|
||||
* **Hybrid reachability** is **second-class**: summary badges + dedicated tab + links to ingest health.
|
||||
|
||||
If you want the next pack: **Pack 18** will update the **Environment Detail** screen to standardize “Deploy status + SBOM status + CritR + B/I/R + data confidence” as a single consistent header across envs (and wire it to bundles/promotions/approvals).
|
||||
554
docs/modules/ui/v2-rewire/pack-18.md
Normal file
554
docs/modules/ui/v2-rewire/pack-18.md
Normal file
@@ -0,0 +1,554 @@
|
||||
## Pack 18 — Environment Detail standardized: **Deploy + SBOM + Crit‑Reachable + Hybrid B/I/R + Data Confidence** in one header (consistent everywhere)
|
||||
|
||||
This pack makes **Environment Detail** the single place where an operator or approver can answer:
|
||||
**“Is this environment safe to promote into right now?”**
|
||||
…without bouncing across Dashboard → Security → Ops → Integrations.
|
||||
|
||||
It keeps your IA intact:
|
||||
|
||||
* **Release Control** is still a root menu
|
||||
* **Regions-first** environment organization remains
|
||||
* **Reachability stays 2nd-class** (tab + badges), not a new top-level area
|
||||
* **Data Integrity** remains owned by Ops, but is summarized here
|
||||
|
||||
---
|
||||
|
||||
# 18.1 Menu & entry graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RC[Release Control (ROOT)] --> RE[Regions & Environments]
|
||||
RE --> RD[Region Detail]
|
||||
RD --> ENV[Environment Detail]
|
||||
|
||||
%% Entry points
|
||||
DASH[Dashboard] --> ENV
|
||||
APPR[Approvals] --> ENV
|
||||
REL[Releases] --> ENV
|
||||
|
||||
%% Cross links out of env
|
||||
ENV --> BV[Bundle Version Detail]
|
||||
ENV --> RUN[Promotion Run Timeline]
|
||||
ENV --> FIND[Security Findings (filtered)]
|
||||
ENV --> DI[Ops: Data Integrity (filtered)]
|
||||
ENV --> INT[Integrations Hub]
|
||||
ENV --> GOV[Release Control: Governance]
|
||||
ENV --> EVID[Evidence Export]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 18.2 Environment Detail (shell) — the standardized “single header truth”
|
||||
|
||||
### Formerly (what it was called before)
|
||||
|
||||
* **Control Plane pipeline node** (no dedicated environment page), plus
|
||||
* **Settings → Release Control → Environments** (flat listing; not region-first)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
You asked for:
|
||||
|
||||
* per-environment status including **docker/runtime** *and* **image SBOM status**
|
||||
* dashboard surfacing of “**X envs with critical reachable issues**”
|
||||
* nightly pipeline failures (rescan / feed sync / integration connectivity)
|
||||
* hybrid reachability from **image/build/runtime**
|
||||
All of those converge at the environment boundary, so Env Detail needs a uniform “truth header”.
|
||||
|
||||
---
|
||||
|
||||
## Environment Detail shell graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
ENV[Environment Detail (shell)] --> O[Overview]
|
||||
ENV --> DEP[Deploy Status]
|
||||
ENV --> SB[SBOM & Findings]
|
||||
ENV --> RCH[Reachability (Hybrid B/I/R)]
|
||||
ENV --> INP[Inputs (Vault/Consul)]
|
||||
ENV --> PR[Promotions & Approvals]
|
||||
ENV --> DC[Data Confidence]
|
||||
ENV --> EV[Evidence & Audit]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Environment Detail shell (header + tabs)
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Environment: us-prod Region: US-East Type: Production │
|
||||
│ Formerly: Control Plane pipeline node (no dedicated page) + Settings ▸ Release Control ▸ Envs │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ STANDARD STATUS HEADER (shown consistently on every Env tab) │
|
||||
│ Deploy: DEGRADED (targets 5/6 healthy) | SBOM: STALE (26h) scanned 13/14 pending 1 │
|
||||
│ Findings (target env): CritR=2 HighR=0 HighNR=3 VEX=62% │
|
||||
│ Hybrid reach coverage: Build 78% | Image 100% | Runtime 35% (evidence age: B 7h / I 1h / R 26h)│
|
||||
│ Data Confidence: WARN (NVD stale 3h; SBOM rescan FAIL; Jenkins DEGRADED; DLQ runtime 1,230) │
|
||||
│ Policy baseline: Prod-US-East Version lock: lock-2026-02-18 │
|
||||
│ Deployed bundle: Platform Release 1.3.0-rc1 (manifest sha256:beef...) │
|
||||
│ Quick links: [Open Deployed Bundle] [Open Findings] [Open Data Integrity] [Open Promotion Run] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Tabs: [Overview] [Deploy Status] [SBOM & Findings] [Reachability] [Inputs] [Promotions] [Data] │
|
||||
│ [Evidence & Audit] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 18.3 Tab — Overview (env “situation report”)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Mixed across:
|
||||
|
||||
* **Control Plane** (pipeline + active deployments),
|
||||
* **Security Overview** (global),
|
||||
* **Platform Health** (platform-wide),
|
||||
* **Approvals** (per-promotion)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Overview becomes a decision “brief”:
|
||||
|
||||
* what is deployed,
|
||||
* what is pending,
|
||||
* what is blocking promotions,
|
||||
* what’s changed in the last 24h.
|
||||
|
||||
---
|
||||
|
||||
## Overview graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
O[Env Overview] --> CUR[Current deployed bundle + digests]
|
||||
O --> PEND[Pending approvals affecting this env]
|
||||
O --> ACT[Active/Recent promotion runs]
|
||||
O --> TOP[Top risks (CritR + stale SBOM + stale feeds)]
|
||||
O --> ACTIONS[Recommended actions (scan/rescan/rotate token/request exception)]
|
||||
O --> LINKS[Links: Findings, Data Integrity, Inputs, Run Timeline, Evidence]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Overview
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Overview │
|
||||
│ Formerly: Control Plane summary + scattered Security/Ops context │
|
||||
├───────────────────────────────────────────────────────────────────────────────┬──────────────┤
|
||||
│ Current deployment │ Actions │
|
||||
│ Bundle: Platform Release 1.3.0-rc1 (manifest sha256:beef...) │ [Trigger SBOM │
|
||||
│ Last promoted: Feb 18, 08:33 by alice.johnson │ rescan] │
|
||||
│ Components: 14 images (13 scanned, 1 pending) │ [Retry NVD │
|
||||
│ │ sync] │
|
||||
│ Promotion posture │ [Open Inputs]│
|
||||
│ Pending approvals: 1 (BLOCK) │ [Open Run] │
|
||||
│ Active runs: 0 │ [Export Env │
|
||||
│ Next scheduled: nightly hotfix window 02:00 │ Snapshot] │
|
||||
├───────────────────────────────────────────────────────────────────────────────┴──────────────┤
|
||||
│ Top risks (last 24h) │
|
||||
│ 1) Crit reachable CVE-2026-1234 (user-service) → no VEX │
|
||||
│ 2) SBOM stale 26h (nightly rescan failing) │
|
||||
│ 3) Runtime reachability evidence 35% (agent degraded) │
|
||||
│ Links: [Open Findings filtered to env] [Open Data Integrity filtered to env] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 18.4 Tab — Deploy Status (runtime / docker / targets + services)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Best approximation:
|
||||
|
||||
* **Platform Health** (platform-wide),
|
||||
* dashboard pipeline node “Deploy status”
|
||||
* and external systems.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
You explicitly want env summary to include **docker/runtime**, but it must be coupled with SBOM and risk, not isolated.
|
||||
|
||||
---
|
||||
|
||||
## Deploy Status graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
DEP[Deploy Status] --> TGT[Targets health table]
|
||||
DEP --> SVC[Services/Workloads status]
|
||||
DEP --> DRIFT[Config drift vs expected bundle manifest]
|
||||
DEP --> LOGS[Links to run logs / agent logs]
|
||||
DEP --> RUN[Open latest promotion run timeline]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Deploy Status
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Deploy Status │
|
||||
│ Formerly: Platform Health + implicit “docker status” in Control Plane pipeline │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Targets (US-East/us-prod) │
|
||||
│ ┌───────────────┬───────────┬──────────────┬───────────────┬───────────────────────────────┐ │
|
||||
│ │ Target │ Agent │ Health │ Last Heartbeat │ Notes │ │
|
||||
│ ├───────────────┼───────────┼──────────────┼───────────────┼───────────────────────────────┤ │
|
||||
│ │ docker-us-01 │ agent-01 │ ✓ HEALTHY │ 1m ago │ ok │ │
|
||||
│ │ docker-us-02 │ agent-02 │ ✓ HEALTHY │ 2m ago │ ok │ │
|
||||
│ │ docker-us-03 │ agent-03 │ ✗ DEGRADED │ 12m ago │ disk pressure │ │
|
||||
│ └───────────────┴───────────┴──────────────┴───────────────┴───────────────────────────────┘ │
|
||||
│ │
|
||||
│ Services (from deployed bundle manifest) │
|
||||
│ api-gateway RUNNING ✓ digest sha256:1111... replicas 4/4 │
|
||||
│ user-service RUNNING ✓ digest sha256:2222... replicas 3/3 │
|
||||
│ worker RUNNING ✓ digest sha256:4444... replicas 1/1 │
|
||||
│ web-frontend WARN ⚠ digest sha256:3333... error rate 1.4% │
|
||||
│ Links: [Open last Promotion Run] [Open agent logs] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 18.5 Tab — SBOM & Findings (deploy inventory + scan freshness + reachable breakdown)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Security → Overview / Findings / Vulnerabilities**
|
||||
but not env-attached and not surfaced alongside SBOM freshness.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This is where you get exactly what you asked for:
|
||||
|
||||
* “no issues” vs “env with critical reachable issues”
|
||||
* the deployed images list with **SBOM scan status** and **freshness**
|
||||
* “reachable” classification remains visible but not a new product area
|
||||
|
||||
---
|
||||
|
||||
## SBOM & Findings graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
SB[SBOM & Findings] --> INV[Deployed inventory (digests)]
|
||||
SB --> SCAN[SBOM scan status/freshness per digest]
|
||||
SB --> SUM[Findings summary CritR/HighR/HighNR + VEX]
|
||||
SB --> TOP[Top CVEs/packages (filtered)]
|
||||
SB --> DRILL[Drill: Finding detail / Component version detail]
|
||||
SB --> EX[Exceptions/VEX actions]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — SBOM & Findings
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SBOM & Findings │
|
||||
│ Formerly: Security ▸ Findings / Vulnerabilities (global, not env-attached) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Findings summary (this env) │
|
||||
│ Crit reachable: 2 High reachable: 0 High not reachable: 3 VEX coverage: 62% │
|
||||
│ SBOM freshness: WARN (26h) Missing SBOM: 0 Pending scan: 1 │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Deployed inventory (digest-first) │
|
||||
│ ┌───────────────┬───────────────┬───────────────────────┬─────────────┬─────────────────────┐ │
|
||||
│ │ Component │ Version label │ Digest │ SBOM status │ Findings (CritR) │ │
|
||||
│ ├───────────────┼───────────────┼───────────────────────┼─────────────┼─────────────────────┤ │
|
||||
│ │ api-gateway │ 2.1.0 │ sha256:1111... │ OK (2h) │ 0 │ │
|
||||
│ │ user-service │ 3.0.0-rc1 │ sha256:2222... │ OK (26h) │ 2 │ │
|
||||
│ │ worker │ 3.1.0 │ sha256:4444... │ PENDING │ — │ │
|
||||
│ └───────────────┴───────────────┴───────────────────────┴─────────────┴─────────────────────┘ │
|
||||
│ Top issues (click to drill) │
|
||||
│ - CVE-2026-1234 openssl user-service reachable (no VEX) │
|
||||
│ - CVE-2026-9001 log4j api-gateway not reachable (VEX present) │
|
||||
│ Actions: [Trigger SBOM scan/rescan] [Open Findings] [Open VEX/Exceptions] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 18.6 Tab — Reachability (Hybrid B/I/R matrix + evidence age; still 2nd-class)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Mentioned in approvals/policy but not consistently visible per environment.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
You require reachability evidence from:
|
||||
|
||||
* **image scan (Dover)**
|
||||
* **build**
|
||||
* **running environment**
|
||||
This tab makes the evidence **explicit**, shows coverage and age, and links to the ingest health (Ops) when missing.
|
||||
|
||||
---
|
||||
|
||||
## Reachability graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
RCH[Reachability] --> COV[Coverage Build/Image/Runtime]
|
||||
RCH --> AGE[Evidence age + confidence]
|
||||
RCH --> MAT[Per-component B/I/R matrix]
|
||||
RCH --> DRILL[Drill: component reachability view]
|
||||
RCH --> OPS[Link: Ops Data Integrity → Reachability ingest health]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Reachability
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Reachability (Hybrid) │
|
||||
│ Formerly: partial signal in approvals; no consistent per-env view │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Coverage: Build 78% | Image 100% | Runtime 35% │
|
||||
│ Evidence age: Build 7h | Image 1h | Runtime 26h │
|
||||
│ Policy interpretation (baseline Prod-US-East): │
|
||||
│ - Runtime coverage < 50% → WARN (reduces confidence) │
|
||||
│ - Crit reachable requires runtime evidence OR VEX override → may BLOCK │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Component matrix │
|
||||
│ api-gateway sha256:1111... Build ✓ Image ✓ Runtime ✗ │
|
||||
│ user-service sha256:2222... Build ✗ Image ✓ Runtime ✗ │
|
||||
│ web-frontend sha256:3333... Build ✓ Image ✓ Runtime ✓ │
|
||||
│ Links: [Open Reachability Ingest Health] [Open component version details] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 18.7 Tab — Inputs (Vault/Consul bindings + materialization readiness)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Split across:
|
||||
|
||||
* Integrations (Vault),
|
||||
* environment setup details (not consistently visible),
|
||||
* promotion-time failures.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This is critical for the bundle organizer workflow:
|
||||
If bindings are missing, **materialization and promotions must block early**, not fail at deploy time.
|
||||
|
||||
---
|
||||
|
||||
## Inputs graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
INP[Inputs] --> BIND[Bindings (Vault/Consul) per required var]
|
||||
INP --> MISS[Missing bindings + suggested fixes]
|
||||
INP --> OV[Overrides (env-specific)]
|
||||
INP --> MAT[Materialization readiness for bundle versions]
|
||||
INP --> INT[Link: Integrations (Vault/Consul)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Inputs
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Inputs (Vault/Consul) │
|
||||
│ Formerly: implicit env config + external Vault/Consul management │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Binding status (required vars from bundle contracts) │
|
||||
│ api-gateway │
|
||||
│ - RATE_LIMIT_MAX consul key: service/api-gw/rate_limit_max ✓ bound │
|
||||
│ - JWT_PUBLIC_KEYS vault path: secret/api-gw/jwt_keys ✓ bound (sealed) │
|
||||
│ user-service │
|
||||
│ - DB_PASSWORD vault path: secret/user/db_password ✗ MISSING binding │
|
||||
│ │
|
||||
│ Impact: promotions using this env will BLOCK at “Materialize Inputs” │
|
||||
│ Fix: [Bind missing var] (opens mapping editor) │
|
||||
│ Links: [Open Vault integration] [Open Consul integration] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 18.8 Tab — Promotions & Approvals (env-centric history + what’s pending)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Promotions were visible under Releases list, approvals under Approvals list, but env-centric “what’s pending for *this env*” wasn’t first-class.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Operators need an env-centric view:
|
||||
|
||||
* what bundle versions landed here,
|
||||
* what is currently running,
|
||||
* what approvals are blocked,
|
||||
* and what changed between deployed and proposed.
|
||||
|
||||
---
|
||||
|
||||
## Promotions & Approvals graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
PR[Promotions & Approvals] --> PEND[Pending approvals targeting this env]
|
||||
PR --> RUNS[Recent promotion runs (timeline links)]
|
||||
PR --> DIFF[Diff proposed vs deployed bundle version]
|
||||
PR --> EVID[Evidence links per run]
|
||||
PR --> REL[Link: Releases filtered to this env]
|
||||
PR --> APPR[Link: Approvals filtered to this env]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Promotions & Approvals
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Promotions & Approvals │
|
||||
│ Formerly: separate Releases list + Approvals list; env-centric view missing │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Pending approvals (this env) │
|
||||
│ - Platform Release 1.3.0-rc1 → us-prod Gates: BLOCK (CritR + SBOM pending) [Open Approval] │
|
||||
│ │
|
||||
│ Recent promotions │
|
||||
│ Feb 18 08:33 Hotfix Bundle 1.2.4 Status: DEPLOYED [Open Run] [Evidence] │
|
||||
│ Feb 11 02:10 Platform Release 1.2.3 Status: DEPLOYED [Open Run] [Evidence] │
|
||||
│ │
|
||||
│ Diff (proposed vs deployed) │
|
||||
│ Proposed: Platform 1.3.0-rc1 vs Deployed: Hotfix 1.2.4 │
|
||||
│ Changed components: user-service, api-gateway │
|
||||
│ [Open Diff] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 18.9 Tab — Data Confidence (env-scoped slice of Ops: Data Integrity)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Data issues existed, but approvers/operators had to jump out to Ops/Settings.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This tab makes the environment’s security posture honest:
|
||||
|
||||
* If feeds are stale or rescans failing, the env’s “SBOM status” is not reliable.
|
||||
* This is *not* duplicating Ops; it’s an env-scoped summary with deep links.
|
||||
|
||||
---
|
||||
|
||||
## Data Confidence graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
DC[Data Confidence] --> FEED[Feeds freshness (env/region scoped)]
|
||||
DC --> JOB[Relevant jobs (rescan, reachability ingest)]
|
||||
DC --> INT[Integrations relevant to this env]
|
||||
DC --> DLQ[DLQ counts affecting this env]
|
||||
DC --> LINK[Open Ops Data Integrity (filtered)]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Data Confidence
|
||||
|
||||
```text
|
||||
┌───────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Data Confidence │
|
||||
│ Formerly: Ops Feeds + System Jobs + Integrations (manual correlation) │
|
||||
├───────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Feeds (region: US-East) │
|
||||
│ OSV OK (20m) NVD WARN (3h) KEV OK (3h) │
|
||||
│ Jobs impacting this env │
|
||||
│ sbom-nightly-rescan: FAIL → 12 deployed digests stale > 24h │
|
||||
│ reachability-runtime-ingest: WARN → runtime evidence age 26h │
|
||||
│ Integrations │
|
||||
│ Registry WARN (token expiry soon) Jenkins DEGRADED Vault OK Consul OK │
|
||||
│ DLQ │
|
||||
│ runtime-ingest bucket: 1,230 │
|
||||
│ Link: [Open Ops → Data Integrity (US-East + us-prod filter)] │
|
||||
└───────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 18.10 Tab — Evidence & Audit (env snapshot export + last proof chain refs)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Evidence existed globally:
|
||||
|
||||
* Evidence Bundles
|
||||
* Export
|
||||
* Proof Chains
|
||||
But env-centric export (“give me the state of us-prod at time T”) wasn’t obvious.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Auditors often ask for:
|
||||
|
||||
* evidence for a release *and* the resulting deployed state in the env
|
||||
This tab provides env snapshot exports and links to the latest promotion evidence packs.
|
||||
|
||||
---
|
||||
|
||||
## Evidence & Audit graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
EV[Evidence & Audit] --> SNAP[Export Env Snapshot]
|
||||
EV --> LAST[Latest promotion evidence pack]
|
||||
EV --> CHAIN[Proof chain refs (if sealed)]
|
||||
EV --> AUDIT[Env audit trail (who changed inputs/bindings/policy)]
|
||||
EV --> EXPORT[Open Evidence Export Center]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ASCII mock — Evidence & Audit
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Evidence & Audit │
|
||||
│ Formerly: Evidence pages existed, but env-centric exports were not obvious │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Export options │
|
||||
│ [Export Env Snapshot] includes: deployed bundle manifest, digests, SBOM status, findings, │
|
||||
│ reachability summary, data confidence snapshot, timestamps │
|
||||
│ │
|
||||
│ Latest promotion evidence │
|
||||
│ Hotfix Bundle 1.2.4 → us-prod evidence-pack.tar.gz (sealed) [Open] [Download] │
|
||||
│ Proof chain refs: chain-9912 (valid) │
|
||||
│ Audit trail (env config): │
|
||||
│ - Feb 18 07:10: Vault token rotated (registry rescan recovered) │
|
||||
│ - Feb 18 06:40: baseline changed Prod-US-East (gate tightened) │
|
||||
│ Link: [Open Evidence Export Center] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What this pack accomplishes (directly matching your requirements)
|
||||
|
||||
* Every environment now shows **deploy health + image SBOM status** together (not separate worlds).
|
||||
* The environment header includes:
|
||||
|
||||
* **Crit reachable** and reachable-class breakdown
|
||||
* **Hybrid reachability B/I/R** + evidence age
|
||||
* **Data Confidence** derived from nightly jobs, feed freshness, integrations, DLQ
|
||||
* Approvals/Releases/Dashboard can link to Env Detail and always show the same standardized status strip.
|
||||
|
||||
---
|
||||
|
||||
If you want to continue, **Pack 19** can consolidate the Security area so “Findings / Vulnerabilities / SBOM Lake / SBOM Graph / VEX / Exceptions” are organized around **release decisions + audit outputs** (keeping reachability second-class and preserving all the PoC screens).
|
||||
539
docs/modules/ui/v2-rewire/pack-19.md
Normal file
539
docs/modules/ui/v2-rewire/pack-19.md
Normal file
@@ -0,0 +1,539 @@
|
||||
## Pack 19 — Security consolidated around **release decisions + audit outputs** (preserving all PoC screens; reachability stays 2nd‑class)
|
||||
|
||||
Below:
|
||||
|
||||
1. **Security menu graph (Mermaid)**
|
||||
2. For **each screen**:
|
||||
|
||||
* **Formerly** (old name/location)
|
||||
* **Why moved/reshaped**
|
||||
* **Screen navigation graph (Mermaid)**
|
||||
* **ASCII mock**
|
||||
|
||||
---
|
||||
|
||||
# 19.1 Security menu graph (Mermaid)
|
||||
|
||||
This keeps every PoC screen, but organizes them in a “Stella Ops” order: **decision‑centric first**, then exploration, then data backends, then attestations/waivers.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
SEC[Security (ROOT)] --> SEC_OV[Risk Overview]
|
||||
SEC --> SEC_FIND[Findings Explorer]
|
||||
SEC --> SEC_VULN[Vulnerabilities Explorer]
|
||||
SEC --> SEC_SBOM[SBOM Data]
|
||||
SEC_SBOM --> SEC_LAKE[SBOM Lake]
|
||||
SEC_SBOM --> SEC_GRAPH[SBOM Graph]
|
||||
SEC --> SEC_VEX[VEX & Exceptions]
|
||||
SEC_VEX --> SEC_VEXH[VEX Hub]
|
||||
SEC_VEX --> SEC_EXC[Exceptions]
|
||||
|
||||
%% Cross-links (no duplication)
|
||||
SEC_OV -. "data confidence" .-> OPS_DI[Ops: Data Integrity]
|
||||
SEC_FIND -. "open env" .-> RC_ENV[Release Control: Env Detail]
|
||||
SEC_FIND -. "open bundle version" .-> BVER[Bundles: Bundle Version Detail]
|
||||
SEC_FIND -. "export decision pack" .-> EVID[Evidence: Export Center]
|
||||
SEC_VULN -. "graph" .-> SEC_GRAPH
|
||||
SEC_EXC -. "approval gating" .-> APPR[Approvals]
|
||||
SEC_VEXH -. "issuer trust" .-> TRUST[Evidence: Trust & Signing]
|
||||
```
|
||||
|
||||
**Key consolidation rule:**
|
||||
|
||||
* **Findings** = “what is actually present in a specific env/bundle/digest, and is it reachable?”
|
||||
* **Vulnerabilities** = “the CVE/catalog view (global), then drill down to where it hits.”
|
||||
* **SBOM Lake/Graph** = storage/exploration backends (kept, but demoted under “SBOM Data”).
|
||||
* **VEX/Exceptions** = disposition/waiver layer tied to approvals and audit.
|
||||
|
||||
---
|
||||
|
||||
# 19.2 Security screen — Risk Overview
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Security → Overview** (`security overview.png`)
|
||||
(cards and summary, not tightly tied to env/bundle decision outcomes)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This becomes the security commander’s “brief”: **what blocks promotions**, **which envs have critical reachable**, **SBOM freshness/coverage**, **VEX/exceptions posture**, and **data confidence** (feeds/jobs/integrations).
|
||||
|
||||
Reachability is **not** promoted to a top-level area; it appears as:
|
||||
|
||||
* summary metrics
|
||||
* filters
|
||||
* drilldowns into Findings.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Security: Risk Overview] --> B[Critical reachable by environment]
|
||||
A --> C[Blocked approvals due to security]
|
||||
A --> D[SBOM coverage & freshness summary]
|
||||
A --> E[Top CVEs impacting deployed bundles]
|
||||
A --> F[VEX coverage / exceptions expiring soon]
|
||||
A --> G[Data Confidence banner -> Ops Data Integrity]
|
||||
A --> H[Drilldowns -> Findings Explorer]
|
||||
A --> I[Drilldowns -> Vulnerabilities Explorer]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ RISK OVERVIEW │
|
||||
│ Formerly: Security ▸ Overview (security overview.png) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Data Confidence: WARN (NVD stale 3h; SBOM rescan FAIL; Jenkins DEGRADED; DLQ runtime 1,230) │
|
||||
│ [Open Ops → Data Integrity] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Snapshot (24h) │
|
||||
│ Envs with Crit Reachable: 2 Total Crit Reachable: 3 │
|
||||
│ Envs SBOM stale/missing: 3 VEX coverage: 62% │
|
||||
│ Approvals blocked (security): 2 Exceptions expiring < 7d: 4 │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Critical Reachable by Environment │
|
||||
│ US-East/us-prod: 2 US-East/us-uat: 1 EU-West/eu-prod: 0 APAC/apac-prod: 0 │
|
||||
│ [Open Findings filtered to Crit Reachable] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Top drivers (click to drill) │
|
||||
│ CVE-2026-1234 (openssl) → affects user-service in US-East/us-prod (reachable) │
|
||||
│ CVE-2026-9001 (log4j) → affects api-gateway (not reachable; VEX present) │
|
||||
│ [Open Vulnerabilities Explorer] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ SBOM posture │
|
||||
│ Coverage: 98% digests scanned | Freshness: 3 envs > 24h | Pending scans: 1 digest │
|
||||
│ [Open Findings] [Open SBOM Lake] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ VEX & Exceptions │
|
||||
│ VEX statements imported (24h): 12 | Exceptions active: 9 | expiring soon: 4 │
|
||||
│ [Open VEX Hub] [Open Exceptions] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 19.3 Security screen — Findings Explorer
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Security → Findings** (`findings.png`)
|
||||
(global list; in PoC the table looked empty / placeholder)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Findings are what matter for release decisions. This screen becomes the primary explorer with **first-class filters**:
|
||||
|
||||
* Region / Env / Env type
|
||||
* Bundle version (manifest digest)
|
||||
* Component digest
|
||||
* Severity
|
||||
* **Reachability class** (reachable / not reachable / unknown)
|
||||
* **Hybrid evidence presence** (B/I/R) as filters/columns (2nd-class, but not buried)
|
||||
* SBOM freshness status (ok/stale/missing/pending)
|
||||
|
||||
It also shows a **Data Confidence banner** so you never misread stale results as “clean”.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Findings Explorer] --> B[Finding Detail]
|
||||
A --> C[Filter to Environment -> Env Detail]
|
||||
A --> D[Filter to Bundle Version -> Bundle Version Detail]
|
||||
A --> E[Open Vulnerability Detail]
|
||||
A --> F[Open VEX Hub (statement for CVE)]
|
||||
A --> G[Open Exceptions (waiver scope)]
|
||||
A --> H[Export filtered set -> Evidence Export]
|
||||
A --> I[Data Confidence -> Ops Data Integrity]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ FINDINGS EXPLORER │
|
||||
│ Formerly: Security ▸ Findings (findings.png) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Data Confidence: WARN (NVD stale 3h; SBOM rescan FAIL) [Open Data Integrity] │
|
||||
│ Filters: Region ▾ Env ▾ EnvType ▾ BundleVersion ▾ Severity ▾ Reachability ▾ SBOM ▾ │
|
||||
│ Hybrid evidence: Build ✓/✗ Image ✓/✗ Runtime ✓/✗ Time window ▾ (24h/7d/30d) │
|
||||
│ Actions: [Export filtered findings] [Open as Evidence Attachment] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Findings (env‑context) │
|
||||
│ ┌──────────────┬──────────────┬─────────────┬──────────────┬──────────┬─────────┬───────────┐ │
|
||||
│ │ Env │ Component │ CVE │ Package │ Severity │ Reach │ B/I/R │ │
|
||||
│ ├──────────────┼──────────────┼─────────────┼──────────────┼──────────┼─────────┼───────────┤ │
|
||||
│ │ us-prod │ user-service │ 2026-1234 │ openssl │ CRIT │ YES │ 0/1/0 │ │
|
||||
│ │ us-uat │ user-service │ 2026-2222 │ glibc │ CRIT │ YES │ 0/1/0 │ │
|
||||
│ │ us-prod │ api-gateway │ 2026-9001 │ log4j │ HIGH │ NO │ 1/1/1 │ │
|
||||
│ └──────────────┴──────────────┴─────────────┴──────────────┴──────────┴─────────┴───────────┘ │
|
||||
│ Click a row → Finding Detail │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 19.4 Security screen — Finding Detail (new, minimal but necessary)
|
||||
|
||||
### Formerly
|
||||
|
||||
* No explicit “Finding Detail” screen shown; users would pivot:
|
||||
|
||||
* Vulnerabilities list
|
||||
* SBOM Graph
|
||||
* VEX Hub
|
||||
* Exceptions
|
||||
…without a single “case file.”
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This is the decision artifact:
|
||||
|
||||
* “Is it reachable?” and **why** (and with what hybrid evidence)
|
||||
* What envs/bundles are impacted
|
||||
* Whether VEX exists / whether an exception exists
|
||||
* Links to approvals blocked by this finding
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Finding Detail] --> B[Reachability evidence (B/I/R) + age]
|
||||
A --> C[Impacted envs + bundle versions]
|
||||
A --> D[Related CVE record -> Vulnerability Detail]
|
||||
A --> E[VEX statements -> VEX Hub]
|
||||
A --> F[Exceptions -> Exceptions]
|
||||
A --> G[Blocked approvals -> Approvals]
|
||||
A --> H[Export case -> Evidence Export]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ FINDING DETAIL │
|
||||
│ Formerly: implicit drilldowns from Findings/Vulnerabilities/SBOM Graph (no unified “case file”) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ CVE: CVE-2026-1234 Package: openssl Severity: CRITICAL │
|
||||
│ Component: user-service v3.0.0-rc1 digest sha256:2222... │
|
||||
│ Environment: US-East/us-prod │
|
||||
│ Reachability: REACHABLE (confidence: MEDIUM) │
|
||||
│ Hybrid evidence: Build ✗ (missing) | Image ✓ (1h) | Runtime ✗ (26h stale) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Impact │
|
||||
│ - Environments: us-prod (crit reachable), us-uat (crit reachable) │
|
||||
│ - Bundle versions: Platform 1.3.0-rc1 (manifest sha256:beef...) │
|
||||
│ - Approvals blocked: 1 [Open approvals filtered] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Disposition │
|
||||
│ VEX: none found | Exceptions: none active │
|
||||
│ Actions: [Create Exception Request] [Search/Import VEX] [Export as Evidence] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 19.5 Security screen — Vulnerabilities Explorer
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Security → Vulnerabilities** (`vulnerabilities.png`)
|
||||
(CVE catalog list)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This remains the catalog view, but becomes **release-relevant** by adding:
|
||||
|
||||
* “impacted environments count”
|
||||
* “crit reachable envs count”
|
||||
* “affected bundle versions count”
|
||||
* quick filters: “only affecting prod”, “only reachable”, “only without VEX”, “only with expiring exception”.
|
||||
|
||||
Reachability remains **2nd-class**: it’s derived from correlated findings, not a separate domain.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Vulnerabilities Explorer] --> B[Vulnerability Detail]
|
||||
A --> C[Open Findings (filtered by CVE)]
|
||||
A --> D[Open VEX Hub (statements for CVE)]
|
||||
A --> E[Open Exceptions (scoped to CVE)]
|
||||
A --> F[Open SBOM Graph (package path)]
|
||||
A --> G[Export report -> Evidence Export]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ VULNERABILITIES EXPLORER │
|
||||
│ Formerly: Security ▸ Vulnerabilities (vulnerabilities.png) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Severity ▾ Has VEX ▾ Has Exception ▾ Reachable in Prod ▾ Window ▾ │
|
||||
│ Data Confidence banner (if stale): WARN (NVD stale 3h) [Open Data Integrity] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ ┌──────────────┬──────────┬──────────────┬───────────────┬──────────────┬───────────────────┐ │
|
||||
│ │ CVE │ Severity │ Package │ Impacted envs │ CritR envs │ Disposition │ │
|
||||
│ ├──────────────┼──────────┼──────────────┼───────────────┼──────────────┼───────────────────┤ │
|
||||
│ │ 2026-1234 │ CRIT │ openssl │ 2 │ 2 │ no VEX / no exc │ │
|
||||
│ │ 2026-9001 │ HIGH │ log4j │ 4 │ 0 │ VEX present │ │
|
||||
│ └──────────────┴──────────┴──────────────┴───────────────┴──────────────┴───────────────────┘ │
|
||||
│ Click a CVE → Vulnerability Detail │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 19.6 Security screen — Vulnerability Detail (new, minimal but necessary)
|
||||
|
||||
### Formerly
|
||||
|
||||
* No explicit detail page shown; users used SBOM graph or external CVE pages and then filtered Findings.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This is the “CVE dossier” inside Stella:
|
||||
|
||||
* shows where it hits (envs/bundles/components)
|
||||
* reachability distribution
|
||||
* VEX statements and exceptions status
|
||||
* links to SBOM Graph paths and evidence export
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Vulnerability Detail] --> B[Impacted envs/bundles/components]
|
||||
A --> C[Reachability distribution]
|
||||
A --> D[VEX statements]
|
||||
A --> E[Exceptions / waivers]
|
||||
A --> F[SBOM Graph path explorer]
|
||||
A --> G[Export as evidence report]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ VULNERABILITY DETAIL: CVE-2026-1234 │
|
||||
│ Formerly: inferred via Vulnerabilities list + Findings filters + external CVE lookup │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Package: openssl Severity: CRITICAL EPSS/KEV: (if present via feeds) │
|
||||
│ Data confidence: WARN (NVD stale 3h) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Impact summary │
|
||||
│ Impacted envs: 2 (Prod impacted: 1) │
|
||||
│ Findings: 3 total | Reachable: 3 | Not reachable: 0 | Unknown: 0 │
|
||||
│ Affected components: user-service sha256:2222... │
|
||||
│ Affected bundle versions: Platform 1.3.0-rc1 (sha256:beef...) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Disposition │
|
||||
│ VEX: none | Exceptions: none │
|
||||
│ Actions: [Open Findings] [Open SBOM Graph] [Create Exception] [Export Report] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 19.7 Security screen — SBOM Lake
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Security → SBOM Lake** (`sbom lake.png`)
|
||||
(raw SBOM index / ingestion storage view)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Keep it intact, but reframe it as **backend exploration**:
|
||||
|
||||
* clearly marked as “data plane”
|
||||
* supports filtering by digest / component / bundle version / env
|
||||
* adds a “Used in decisions” panel (which approvals/promotions reference this SBOM snapshot)
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[SBOM Lake] --> B[SBOM Record Detail (by digest)]
|
||||
A --> C[Pivot to Findings (derived)]
|
||||
A --> D[Pivot to SBOM Graph (relationships)]
|
||||
A --> E[Pivot to Bundle Version Detail]
|
||||
A --> F[Export SBOM snapshot -> Evidence]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ SBOM DATA ▸ SBOM LAKE │
|
||||
│ Formerly: Security ▸ SBOM Lake (sbom lake.png) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Purpose: raw SBOM store / index (data plane). Use Findings/Vulns for decision views. │
|
||||
│ Filters: Digest ▾ Component ▾ BundleVersion ▾ Env ▾ Freshness ▾ │
|
||||
│ Actions: [Export SBOM snapshot] [Open derived Findings] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ SBOM Records │
|
||||
│ sha256:1111... api-gateway generated: 2h ago format: SPDX status: OK │
|
||||
│ sha256:2222... user-service generated: 26h ago format: SPDX status: OK (STALE) │
|
||||
│ sha256:4444... worker generated: — format: — status: PENDING │
|
||||
│ Click record → SBOM Record Detail │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 19.8 Security screen — SBOM Graph
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Security → SBOM Graph** (`sbom graph.png`)
|
||||
(graph traversal of dependencies)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Keep intact, but make it **decision-connected**:
|
||||
|
||||
* start from **bundle version** or **env deployed digest** as entry points
|
||||
* show “paths to vulnerable package”
|
||||
* add “show reachable paths only” as an overlay (2nd-class reachability filter)
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[SBOM Graph] --> B[Select root: env/bundle/digest/package]
|
||||
A --> C[Graph view + path explorer]
|
||||
A --> D[Overlay: highlight vulnerable packages]
|
||||
A --> E[Overlay: reachable-only / evidence source]
|
||||
A --> F[Pivot: open Finding / Vulnerability detail]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ SBOM DATA ▸ SBOM GRAPH │
|
||||
│ Formerly: Security ▸ SBOM Graph (sbom graph.png) │
|
||||
├───────────────────────────────────────────────────────────────────────────────┬──────────────┤
|
||||
│ Entry point (choose one): │ Overlays │
|
||||
│ (•) Deployed env: US-East/us-prod │ [x] highlight│
|
||||
│ ( ) Bundle version: Platform 1.3.0-rc1 │ CVEs │
|
||||
│ ( ) Digest: sha256:2222... │ [ ] reachable│
|
||||
│ ( ) Package: openssl │ only │
|
||||
├───────────────────────────────────────────────────────────────────────────────┴──────────────┤
|
||||
│ Graph view (nodes: packages/components; edges: depends-on) │
|
||||
│ Path explorer: user-service → openssl → … │
|
||||
│ Click node → [Open Vulnerability] [Open Findings] [Open SBOM record] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 19.9 Security screen — VEX Hub
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Security → VEX Hub** (`vex hub.png`)
|
||||
(statement ingestion/management)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Keep intact, but align to governance:
|
||||
|
||||
* show “statements affecting blocked approvals”
|
||||
* show issuer trust status (links to Evidence → Trust & Signing)
|
||||
* provide “apply VEX to finding” workflow as a controlled action (audited)
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[VEX Hub] --> B[VEX Statement Detail]
|
||||
A --> C[Filter by CVE/package/component/env]
|
||||
A --> D[Issuer trust -> Trust & Signing]
|
||||
A --> E[Apply statement -> affects Findings]
|
||||
A --> F[Export VEX set -> Evidence]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ VEX & EXCEPTIONS ▸ VEX HUB │
|
||||
│ Formerly: Security ▸ VEX Hub (vex hub.png) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Issuer ▾ CVE ▾ Component ▾ Env ▾ Status ▾ │
|
||||
│ Summary: Statements imported (24h): 12 | affecting blocked approvals: 1 │
|
||||
│ Issuer trust: 2 trusted / 1 untrusted [Open Trust & Signing] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Statements │
|
||||
│ VendorA CVE-2026-9001 status: not affected scope: api-gateway evidence: signed ✓ │
|
||||
│ InternalSec CVE-2026-1234 status: under investigation scope: user-service signed ✓ │
|
||||
│ Actions: [Import] [Validate signatures] [Export] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 19.10 Security screen — Exceptions
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Security → Exceptions** (`exceptions.png`)
|
||||
(likely waivers, policy exceptions, risk acceptances)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Keep it intact, but force “release governance shape”:
|
||||
|
||||
* exceptions are **time-bound**, **scoped** (env/bundle/component/CVE), and **audited**
|
||||
* shows “exceptions expiring soon” prominently
|
||||
* links to approvals using this exception (so you see operational dependency)
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Exceptions] --> B[Exception Detail]
|
||||
A --> C[Create exception request]
|
||||
A --> D[Link to Approval / Promotion]
|
||||
A --> E[Link to Finding / Vulnerability]
|
||||
A --> F[Export exception ledger -> Evidence]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ SECURITY ▸ VEX & EXCEPTIONS ▸ EXCEPTIONS │
|
||||
│ Formerly: Security ▸ Exceptions (exceptions.png) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Status ▾ Expiring <7d ▾ Env ▾ BundleVersion ▾ CVE ▾ Owner ▾ │
|
||||
│ Summary: Active: 9 | Expiring soon: 4 | Used by pending approvals: 1 │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Exceptions (waivers / risk acceptance) │
|
||||
│ ┌──────────────┬───────────────┬──────────────┬───────────┬───────────────┬─────────────────┐ │
|
||||
│ │ Scope │ CVE/Issue │ Reason │ Expires │ Approvers │ Used by │ │
|
||||
│ ├──────────────┼───────────────┼──────────────┼───────────┼───────────────┼─────────────────┤ │
|
||||
│ │ us-prod │ CVE-2026-9001 │ VEX says not │ 2026-03-01│ sec+relmgr │ 0 approvals │ │
|
||||
│ │ eu-prod │ policy override│ hotfix window │ 2026-02-20│ sec+relmgr │ 1 approval │ │
|
||||
│ └──────────────┴───────────────┴──────────────┴───────────┴───────────────┴─────────────────┘ │
|
||||
│ Actions: [+ Request Exception] [Export ledger] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What this consolidation fixes (in practical terms)
|
||||
|
||||
* **Decision-first navigation**: security starts with “what blocks releases / where CritR exists”, not raw SBOM tooling.
|
||||
* **Reachability is second-class but visible**: it’s a column/filter everywhere it matters (Findings/Vulns/Detail), not a buried third-class afterthought.
|
||||
* **Audit friendliness**: each screen has explicit export hooks into Evidence (decision packets, exception ledger, filtered findings sets).
|
||||
* **No feature loss**: SBOM Lake/Graph, VEX Hub, Exceptions remain exactly as capabilities—just grouped and linked to approvals/releases/environment context.
|
||||
|
||||
---
|
||||
|
||||
If you want the next pack, **Pack 20** can do the same consolidation for **Evidence & Audit** (Evidence Bundles, Export Center, Replay/Verify, Trust & Signing) so audit outputs are “release/bundle/env centric” and still preserve all PoC screens.
|
||||
548
docs/modules/ui/v2-rewire/pack-20.md
Normal file
548
docs/modules/ui/v2-rewire/pack-20.md
Normal file
@@ -0,0 +1,548 @@
|
||||
## Pack 20 — Evidence & Audit consolidated around **who needs what evidence, when** (release/bundle/env‑centric; preserves all PoC screens)
|
||||
|
||||
Below you get:
|
||||
|
||||
1. **Evidence menu graph (Mermaid)**
|
||||
2. For **each screen**:
|
||||
|
||||
* **Formerly** (old name/location)
|
||||
* **Why moved/reshaped**
|
||||
* **Screen navigation graph (Mermaid)**
|
||||
* **ASCII mock**
|
||||
|
||||
This pack covers the PoC evidence screens you showed:
|
||||
|
||||
* **Evidence Bundles** (`evidence bundles.png`)
|
||||
* **Export Center** (`export.png`)
|
||||
* **Replay/Verify (Verdict Replay)** (`reply verify.png`)
|
||||
* **Packets / Proof Chains** (present in the left menu in earlier screenshots; you referenced them)
|
||||
* **Trust & Signing** (`trust and signing .png`)
|
||||
…and makes them decision-connected for **Release / Bundle / Env**.
|
||||
|
||||
---
|
||||
|
||||
# 20.1 Evidence & Audit menu graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
EVID[Evidence & Audit (ROOT)] --> HOME[Evidence Home]
|
||||
EVID --> PACK[Evidence Packs]
|
||||
EVID --> BUND[Evidence Bundles]
|
||||
EVID --> EXP[Export Center]
|
||||
EVID --> CHAIN[Proof Chains]
|
||||
EVID --> VERIFY[Replay & Verify]
|
||||
EVID --> TRUST[Trust & Signing]
|
||||
EVID --> AUDIT[Audit Log]
|
||||
|
||||
%% Entry points from decision areas
|
||||
REL[Releases] --> HOME
|
||||
APPR[Approvals] --> HOME
|
||||
RCENV[Env Detail] --> HOME
|
||||
BVER[Bundle Version Detail] --> HOME
|
||||
|
||||
%% Cross-links
|
||||
HOME --> EXP
|
||||
BUND --> CHAIN
|
||||
VERIFY --> CHAIN
|
||||
TRUST --> CHAIN
|
||||
EXP --> BUND
|
||||
```
|
||||
|
||||
**Design rule:** Evidence is not “a folder of files.”
|
||||
It’s **a pipeline artifact** tied to:
|
||||
|
||||
* a **Release/Hotfix**,
|
||||
* a **Bundle Version**,
|
||||
* an **Environment Promotion Run**,
|
||||
* and the **policy decision** that allowed/blocked it.
|
||||
|
||||
---
|
||||
|
||||
# 20.2 Evidence screen — Evidence Home (new “router” page)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Evidence was scattered under **Evidence** section items: Packets, Proof Chains, Replay/Verify, Export, Bundles.
|
||||
* No single “I’m an auditor / I’m an approver / I’m an operator” entry point.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Evidence Home is the **entry router**:
|
||||
|
||||
* “Give me evidence for **Release X**”
|
||||
* “Give me evidence for **Bundle Version digest**”
|
||||
* “Give me evidence for **Env us-prod today**”
|
||||
* “Give me evidence for **Approval request A**”
|
||||
|
||||
This reduces bounce across Export/Bundles/Proof Chains.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Evidence Home] --> B[Search: Release / Bundle / Env / Approval / Digest]
|
||||
A --> C[Quick tiles: Latest packs, latest bundles, failed verifies]
|
||||
A --> D[Entry: Export Center]
|
||||
A --> E[Entry: Evidence Bundles]
|
||||
A --> F[Entry: Replay & Verify]
|
||||
A --> G[Entry: Proof Chains]
|
||||
A --> H[Entry: Trust & Signing]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ EVIDENCE & AUDIT ▸ HOME │
|
||||
│ Formerly: evidence functions scattered (Packets/Proof Chains/Export/Replay/Bundles) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Find evidence for: [ Release ▾ ] [ Bundle Version ▾ ] [ Environment ▾ ] [ Approval ▾ ] │
|
||||
│ Or paste: digest / verdict-id / bundle-id │
|
||||
│ [Search] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Quick views │
|
||||
│ - Latest promotion evidence packs (24h) - Latest sealed bundles (7d) │
|
||||
│ - Failed verification / replay (7d) - Expiring trust/certs (30d) │
|
||||
│ │
|
||||
│ Shortcuts: [Export Center] [Evidence Bundles] [Replay & Verify] [Proof Chains] [Trust & Signing]│
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 20.3 Evidence screen — Evidence Packs (formerly “Packets”)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Evidence → Packets** (left nav in earlier screenshots)
|
||||
* Not shown as a main content screenshot, but it exists as PoC menu item.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
“Pack” becomes the atomic evidence artifact tied to:
|
||||
|
||||
* a **promotion run**
|
||||
* a **policy decision**
|
||||
* a **bundle version**
|
||||
* an **environment snapshot**
|
||||
It should be the default evidence object used internally and optionally exported.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Evidence Packs] --> B[Pack Detail]
|
||||
A --> C[Filter: Release / Env / Bundle Version / Time]
|
||||
A --> D[Open linked Approval / Run]
|
||||
A --> E[Export pack -> Export Center]
|
||||
B --> F[Proof Chain refs]
|
||||
B --> G[Verify signatures -> Replay & Verify]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ EVIDENCE & AUDIT ▸ EVIDENCE PACKS │
|
||||
│ Formerly: Evidence ▸ Packets │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Release ▾ Env ▾ Bundle Version ▾ Status ▾ Time window ▾ │
|
||||
│ Actions: [Export selected packs] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Packs │
|
||||
│ pack-9001 Feb 18 08:33 env us-prod bundle Hotfix 1.2.4 status: sealed ✓ [Open] │
|
||||
│ pack-9002 Feb 18 07:30 env us-uat bundle web-frontend v2 status: sealed ✓ [Open] │
|
||||
│ pack-9003 Feb 17 08:30 env us-prod bundle worker v3.1.0 status: sealed ✓ [Open] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 20.4 Evidence screen — Pack Detail (new “case file” for a pack)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Evidence details were spread across Export/Bundles/Replay.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
One place to answer:
|
||||
|
||||
* What decision was made?
|
||||
* Which bundle manifest/digests?
|
||||
* Which SBOM/finding snapshot?
|
||||
* Which signatures / proof chain refs?
|
||||
* What can I export?
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Pack Detail] --> B[Decision summary (policy gates + approvals)]
|
||||
A --> C[Artifacts list (SBOM, findings, attestations, provenance)]
|
||||
A --> D[Proof chain refs]
|
||||
A --> E[Verify / Replay]
|
||||
A --> F[Export as bundle / attach to audit report]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ EVIDENCE PACK DETAIL: pack-9001 │
|
||||
│ Formerly: no unified pack “case file” │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Context │
|
||||
│ Release: Hotfix 1.2.4 Env: us-prod Promotion Run: run-7712 │
|
||||
│ Bundle manifest: sha256:beef... Created: Feb 18 08:33 by alice.johnson │
|
||||
│ Decision: PASS policy gates 1/2 (Approval pending) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Included artifacts │
|
||||
│ [✓] SBOM snapshot (SPDX) [✓] Findings snapshot (with reachability) │
|
||||
│ [✓] Attestations (build) [✓] Provenance │
|
||||
│ [✓] VEX statements [✓] Policy decision record │
|
||||
│ [✓] Replay log / determinism result (if present) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Integrity │
|
||||
│ DSSE envelope: present ✓ Rekor entry: present ✓ Proof chain: chain-9912 │
|
||||
│ Actions: [Verify now] [Replay verdict] [Export as Audit Bundle] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 20.5 Evidence screen — Evidence Bundles
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Evidence → Bundles** (`evidence bundles.png`)
|
||||
“Download and verify sealed evidence bundles for audit and compliance.”
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Keep the screen, but make “bundle” explicitly:
|
||||
|
||||
* a **compiled export artifact**, usually for external auditors
|
||||
* built from **packs**
|
||||
* and searchable by Release/Env/Approval.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Evidence Bundles] --> B[Bundle Detail]
|
||||
A --> C[Generate bundle -> Export Center]
|
||||
A --> D[Verify bundle -> Replay & Verify]
|
||||
B --> E[Proof chain refs]
|
||||
B --> F[Download]
|
||||
```
|
||||
|
||||
### ASCII mock (aligned to your current UI, but with better routing)
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ EVIDENCE & AUDIT ▸ EVIDENCE BUNDLES │
|
||||
│ Formerly: Evidence ▸ Bundles (evidence bundles.png) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Release ▾ Env ▾ Approval ▾ Status ▾ Time window ▾ │
|
||||
│ Note: Bundles are compiled exports (from packs) for auditors / compliance teams. │
|
||||
│ [Go to Export Center] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundles │
|
||||
│ (none found) │
|
||||
│ Example rows: │
|
||||
│ bundle-2026-02-18-us-prod.zip sealed ✓ contains packs: 3 [Open] [Download] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 20.6 Evidence screen — Bundle Detail (new)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Bundle list existed, but bundle “composition” was not surfaced as a primary view.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Auditors ask “what exactly is inside” and “can I verify it independently.”
|
||||
Bundle Detail shows:
|
||||
|
||||
* included packs
|
||||
* signatures (DSSE)
|
||||
* transparency log references (Rekor)
|
||||
* verification status
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Bundle Detail] --> B[Included packs list]
|
||||
A --> C[Included artifacts inventory]
|
||||
A --> D[Signatures / DSSE / certificates]
|
||||
A --> E[Transparency log refs]
|
||||
A --> F[Verify / Replay]
|
||||
A --> G[Download]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ EVIDENCE BUNDLE DETAIL: bundle-2026-02-18-us-prod.zip │
|
||||
│ Formerly: not first-class; users downloaded without seeing composition │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Contents │
|
||||
│ Packs: pack-9001, pack-9002, pack-9003 │
|
||||
│ Includes: SBOM, Findings, Attestations, Provenance, VEX, Policy Decisions, Logs │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Integrity │
|
||||
│ DSSE: present ✓ Rekor entry: present ✓ Cert chain: valid ✓ │
|
||||
│ Verification status: VERIFIED │
|
||||
│ Actions: [Verify bundle] [Open Proof Chain] [Download] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 20.7 Evidence screen — Export Center
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Evidence → Export** (`export.png`)
|
||||
“Configure export profiles and monitor export runs.”
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Keep it intact, but:
|
||||
|
||||
* export profiles should be **release/bundle/env aware**
|
||||
* add “Export Env Snapshot” and “Export Approval Decision Pack” as standard profiles
|
||||
* export runs are auditable artifacts tied to proofs
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Export Center] --> B[Profiles]
|
||||
A --> C[Export Runs]
|
||||
B --> D[Profile Editor]
|
||||
D --> E[Scope: Release / Bundle / Env / Approval]
|
||||
D --> F[Destinations: S3/OCI/ZIP]
|
||||
A --> G[Generated bundle -> Evidence Bundles]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ EVIDENCE & AUDIT ▸ EXPORT CENTER │
|
||||
│ Formerly: Evidence ▸ Export (export.png) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Profiles (standardized) │
|
||||
│ - Approval Decision Pack (ZIP) scope: Approval ID → includes gates + findings + evidence │
|
||||
│ - Env Snapshot Export (TAR.GZ) scope: Env + time → includes deploy+sbom+reachability+data │
|
||||
│ - Audit Bundle (ZIP) scope: Release → full auditor bundle │
|
||||
│ - Daily Compliance Export (TAR) scope: org-wide nightly report │
|
||||
│ Actions: [Create Profile] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Export Runs │
|
||||
│ run-8811 Feb 18 08:40 profile: Env Snapshot (us-prod) status: COMPLETED [Open bundle] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 20.8 Evidence screen — Proof Chains
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Evidence → Proof Chains** (menu exists; you referenced proof chains repeatedly)
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Proof chains must be:
|
||||
|
||||
* searchable by release/bundle/env/pack
|
||||
* linked from every exported artifact and decision
|
||||
* verifiable with a single click trail
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Proof Chains] --> B[Chain Detail]
|
||||
A --> C[Filter by pack/bundle/release/env]
|
||||
B --> D[Linked artifacts]
|
||||
B --> E[Transparency log (Rekor) refs]
|
||||
B --> F[Verify chain]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ EVIDENCE & AUDIT ▸ PROOF CHAINS │
|
||||
│ Formerly: Evidence ▸ Proof Chains (menu only in PoC) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Release ▾ Env ▾ Pack ▾ Bundle ▾ Status ▾ │
|
||||
│ Chains │
|
||||
│ chain-9912 linked: pack-9001 bundle-2026-02-18-us-prod status: VALID [Open] │
|
||||
│ chain-9913 linked: pack-9002 status: VALID [Open] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 20.9 Evidence screen — Replay & Verify (Verdict Replay)
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Evidence → Replay/Verify** (`reply verify.png`)
|
||||
“Re-evaluate verdicts for determinism verification and audit trails.”
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Keep the screen, but integrate it into audit flows:
|
||||
|
||||
* every pack/bundle can be replayed/verified from within its detail page
|
||||
* the replay results are stored back into a pack (audit trail)
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Replay & Verify] --> B[Request Replay (verdict id / image ref)]
|
||||
A --> C[Replay Requests list]
|
||||
A --> D[Determinism overview]
|
||||
A --> E[Open pack detail (source)]
|
||||
A --> F[Write result into proof chain]
|
||||
```
|
||||
|
||||
### ASCII mock (aligned to your current one, with clearer context)
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ EVIDENCE & AUDIT ▸ REPLAY & VERIFY │
|
||||
│ Formerly: Evidence ▸ Replay/Verify (reply verify.png) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Request Replay │
|
||||
│ Verdict ID / Image Ref: [ verdict-123 or registry.example.com/app:v1.2.3 ] │
|
||||
│ Reason: [ audit verification / policy change test / determinism check ] │
|
||||
│ [Request Replay] │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Replay Requests │
|
||||
│ rr-001 api-service:v1.2.3 COMPLETED Feb 18 08:30 [Open Pack] │
|
||||
│ rr-002 web-frontend:v2.0.0 RUNNING Feb 18 07:30 [Open Pack] │
|
||||
├───────────────────────────────────────────────────────────────────────────────┬──────────────┤
|
||||
│ Determinism Overview │ Notes │
|
||||
│ total: 2 matching: 1 mismatches: 1 match rate: 50% │ mismatches │
|
||||
│ │ block exports?│
|
||||
└──────────────────────────────────────────────────────────────────────────────┴──────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 20.10 Evidence screen — Trust & Signing
|
||||
|
||||
### Formerly
|
||||
|
||||
* **Settings → Trust & Signing** (`trust and signing .png`)
|
||||
Contains: Signing Keys, Issuers, Certificates, Transparency Log, Trust Scoring, Audit Log.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
This is **evidence infrastructure**, not general “settings”.
|
||||
It should live under Evidence & Audit (root), with a pointer in Settings if needed, because:
|
||||
|
||||
* VEX verification depends on issuers/certs
|
||||
* Rekor integration depends on transparency log configuration
|
||||
* evidence packs/bundles must be verifiable independently
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Trust & Signing] --> B[Signing Keys]
|
||||
A --> C[Issuers]
|
||||
A --> D[Certificates]
|
||||
A --> E[Transparency Log (Rekor)]
|
||||
A --> F[Trust Scoring]
|
||||
A --> G[Audit Log (trust events)]
|
||||
A --> H[Link: VEX Hub issuer status]
|
||||
```
|
||||
|
||||
### ASCII mock (your card layout preserved)
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ EVIDENCE & AUDIT ▸ TRUST & SIGNING │
|
||||
│ Formerly: Settings ▸ Trust & Signing (trust and signing .png) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Signing Keys Issuers Certificates │
|
||||
│ [Manage Keys] [Manage Issuers] [Manage Certificates] │
|
||||
│ │
|
||||
│ Transparency Log Trust Scoring Audit Log │
|
||||
│ [Configure Rekor] [Edit Score Config] [View Audit Log] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 20.11 Evidence screen — Audit Log (new consolidated view)
|
||||
|
||||
### Formerly
|
||||
|
||||
* Trust & Signing had its own audit log tile.
|
||||
* Other audit events were likely scattered.
|
||||
|
||||
### Why changed like this
|
||||
|
||||
Auditors don’t want separate “trust audit” vs “export audit” vs “approval audit.”
|
||||
This creates a unified log with filters and links to artifacts.
|
||||
|
||||
### Screen graph (Mermaid)
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Audit Log] --> B[Filter: release/env/approval/user/type]
|
||||
A --> C[Event detail with links: pack/bundle/proof chain]
|
||||
A --> D[Export audit log slice -> Evidence export]
|
||||
```
|
||||
|
||||
### ASCII mock
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────────────────────┐
|
||||
│ EVIDENCE & AUDIT ▸ AUDIT LOG │
|
||||
│ Formerly: scattered audit signals (Trust & Signing / Export Runs / Approvals) │
|
||||
├──────────────────────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Filters: Event type ▾ Release ▾ Env ▾ Approval ▾ User ▾ Time ▾ │
|
||||
│ Events │
|
||||
│ Feb 18 08:40 ExportRun created run-8811 profile Env Snapshot us-prod by admin [Open] │
|
||||
│ Feb 18 08:33 Promotion decision PASS run-7712 pack-9001 by alice.johnson [Open] │
|
||||
│ Feb 18 07:10 Trust: cert rotated issuer RegistryCA by admin [Open] │
|
||||
└──────────────────────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What this pack accomplishes
|
||||
|
||||
* Evidence now has a **clear chain**:
|
||||
**Promotion/Decision → Pack → Bundle → Proof Chain → Verify/Replay**
|
||||
with exports available at each step.
|
||||
* **Trust & Signing** is treated as evidence infrastructure and tied to VEX issuer trust and proof verification.
|
||||
* Everything is searchable by **Release / Bundle / Env / Approval**, which is what auditors and release managers actually ask for.
|
||||
|
||||
---
|
||||
|
||||
If you want the next pack, **Pack 21** can consolidate **Settings** into:
|
||||
|
||||
* **Release Control** (root already)
|
||||
* **Org & Access**
|
||||
* **Integrations**
|
||||
* **Notifications**
|
||||
* **Usage & Limits**
|
||||
* **System Admin**
|
||||
…and provide Mermaid+ASCII for each of those screens with “formerly/why” mapping.
|
||||
638
docs/modules/ui/v2-rewire/pack-21.md
Normal file
638
docs/modules/ui/v2-rewire/pack-21.md
Normal file
@@ -0,0 +1,638 @@
|
||||
I’ll extend the redesign for the **remaining “Settings/Admin” screens** you just shared, keeping the **main IA reorg intact**, adding **Release Control as a root menu**, and introducing the missing **Release Bundle Organizer**. Below: **Mermaid graphs per menu**, then **per-screen: (1) where it lived before, (2) why it moved/changed, (3) ASCII mock**, and each mock includes a **“Previously called”** line for transition.
|
||||
|
||||
---
|
||||
|
||||
## 1) Updated top-level navigation (keeping the main reorg intact)
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
RC[Release Control] --- SR[Security & Risk]
|
||||
RC --- EA[Evidence & Audit]
|
||||
RC --- INT[Integrations]
|
||||
RC --- OPS[Platform Ops]
|
||||
RC --- ADM[Administration]
|
||||
|
||||
SR --- SR1[Findings & Reachability]
|
||||
SR --- SR2[VEX Hub]
|
||||
SR --- SR3[Exceptions]
|
||||
SR --- SR4[Advisory Sources]
|
||||
|
||||
EA --- EA1[Evidence Packets]
|
||||
EA --- EA2[Proof Chains]
|
||||
EA --- EA3[Replay / Verify]
|
||||
EA --- EA4[Export Center]
|
||||
|
||||
INT --- INT1[SCM]
|
||||
INT --- INT2[CI/CD]
|
||||
INT --- INT3[Registries]
|
||||
INT --- INT4[Secrets]
|
||||
INT --- INT5[Targets / Runtimes]
|
||||
INT --- INT6[Feeds]
|
||||
INT --- INT7[Notification Providers]
|
||||
|
||||
OPS --- OPS1[Platform Health]
|
||||
OPS --- OPS2[Background Jobs]
|
||||
OPS --- OPS3[Scheduler]
|
||||
OPS --- OPS4[Dead Letter]
|
||||
OPS --- OPS5[Quotas & Usage]
|
||||
OPS --- OPS6[Feed Mirror & AirGap Ops]
|
||||
OPS --- OPS7[Nightly Ops Report]
|
||||
|
||||
ADM --- ADM0[Admin Overview]
|
||||
ADM --- ADM1[Identity & Access]
|
||||
ADM --- ADM2[Tenant & Branding]
|
||||
ADM --- ADM3[Notifications]
|
||||
ADM --- ADM4[Usage & Limits]
|
||||
ADM --- ADM5[Policy Governance]
|
||||
ADM --- ADM6[Trust & Signing]
|
||||
ADM --- ADM7[System]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# PACK: Administration + Release Control Setup + Integrations
|
||||
|
||||
---
|
||||
|
||||
## 2) Administration menu → screen graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
ADM[Administration] --> A0[Admin Overview]
|
||||
ADM --> A1[Identity & Access]
|
||||
ADM --> A2[Tenant & Branding]
|
||||
ADM --> A3[Notifications]
|
||||
ADM --> A4[Usage & Limits]
|
||||
ADM --> A5[Policy Governance]
|
||||
ADM --> A6[Trust & Signing]
|
||||
ADM --> A7[System]
|
||||
|
||||
A3 -.channels live in.-> INTN[Integrations > Notification Providers]
|
||||
A4 -.operational drilldown.-> OPSQ[Platform Ops > Quotas & Usage]
|
||||
A7 -.operational drilldown.-> OPSH[Platform Ops > Platform Health]
|
||||
A7 -.jobs drilldown.-> OPSJ[Platform Ops > Background Jobs]
|
||||
A5 -.gates apply to.-> RCG[Release Control > Gates & Approvals]
|
||||
A6 -.evidence uses.-> EA[Evidence & Audit]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen A0 — Administration Overview
|
||||
|
||||
**Previously:** There was no single “admin hub”; admin functions were scattered under **Settings** (and some under **Operations**).
|
||||
**Now:** `Administration → Overview`
|
||||
**Why:** Admin users need a **single choke-point** for identity, policy governance, trust, notifications, and tenant controls—without mixing it with runtime ops dashboards.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Top bar: [Search…] [Tenant: Core ▼] [Region: All ▼] [Env: All ▼] [Status: OK] │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ NAV │ Administration — Overview │
|
||||
│ │ Previously called: (new) — consolidates legacy Settings pages │
|
||||
│ Release Ctrl │ │
|
||||
│ Security&Risk │ Quick Health │
|
||||
│ Evidence │ ┌──────────────┬──────────────┬──────────────┬────────────┐ │
|
||||
│ Integrations │ │ Integrations │ Policy Pack │ Quotas │ Jobs │ │
|
||||
│ Platform Ops │ │ 6 ok /2 warn │ Core latest │ 65% scans │ 0 failing │ │
|
||||
│ Administration│ └──────────────┴──────────────┴──────────────┴────────────┘ │
|
||||
│ ▸ Overview │ │
|
||||
│ Identity │ Admin Areas │
|
||||
│ Tenant │ ┌─────────────────────┐ ┌─────────────────────┐ │
|
||||
│ Notifications│ │ Identity & Access │ │ Policy Governance │ │
|
||||
│ Usage&Limits │ │ (Users/Roles/Keys) │ │ (Baselines/Rules) │ │
|
||||
│ Policy Gov │ │ Formerly: Settings │ │ Formerly: Settings │ │
|
||||
│ Trust&Sign │ └─────────────────────┘ └─────────────────────┘ │
|
||||
│ System │ ┌─────────────────────┐ ┌─────────────────────┐ │
|
||||
│ │ │ Notifications │ │ Trust & Signing │ │
|
||||
│ │ │ Formerly: Settings │ │ Formerly: Settings │ │
|
||||
│ │ └─────────────────────┘ └─────────────────────┘ │
|
||||
│ │ ┌─────────────────────┐ ┌─────────────────────┐ │
|
||||
│ │ │ Tenant & Branding │ │ Usage & Limits │ │
|
||||
│ │ │ Formerly: Settings │ │ Formerly: Settings │ │
|
||||
│ │ └─────────────────────┘ └─────────────────────┘ │
|
||||
│ │ ┌────────────────────────────────────────────────────────┐ │
|
||||
│ │ │ System (Admin) — diagnostics & admin tools │ │
|
||||
│ │ │ Formerly: Settings > System │ │
|
||||
│ │ └────────────────────────────────────────────────────────┘ │
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen A1 — Identity & Access
|
||||
|
||||
**Previously:** `Settings → Identity & Access`
|
||||
**Now:** `Administration → Identity & Access`
|
||||
**Why:** This is **pure admin** (RBAC, OAuth, API keys, tenants). It shouldn’t compete with release/security workflows.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Top bar: [Search…] [Tenant: Core ▼] [Admin] │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ NAV │ Identity & Access │
|
||||
│ Administration│ Previously called: Settings > Identity & Access │
|
||||
│ Overview │ │
|
||||
│ ▸ Identity │ Tabs: [Users] [Roles] [OAuth/SSO Clients] [API Tokens] [Tenants] │
|
||||
│ Tenant │ │
|
||||
│ Notifications│ [ + Add User ] [Invite] [Import] [Audit Log→] │
|
||||
│ Usage&Limits │ │
|
||||
│ Policy Gov │ Users │
|
||||
│ Trust&Sign │ ┌──────────────────────────────────────────────────────────┐ │
|
||||
│ System │ │ Name Email Role Status Actions │ │
|
||||
│ │ │ -------- ----------------- -------- ------- -------- │ │
|
||||
│ │ │ ... │
|
||||
│ │ └──────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ │ Notes: API Tokens are used by Agents/CI integrations; link to │
|
||||
│ │ Integrations → CI/CD for token scope testing. │
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen A2 — Tenant & Branding
|
||||
|
||||
**Previously:** `Settings → Tenant / Branding`
|
||||
**Now:** `Administration → Tenant & Branding`
|
||||
**Why:** Tenant configuration is **identity-adjacent** (domains, default policy pack, org metadata). Keeping it in Admin prevents accidental mixing with operational tooling.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Top bar: [Search…] [Tenant: Core ▼] │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ NAV │ Tenant & Branding │
|
||||
│ Administration│ Previously called: Settings > Tenant / Branding │
|
||||
│ Overview │ │
|
||||
│ Identity │ Tenants │
|
||||
│ ▸ Tenant │ ┌──────────────────────────────────────────────────────────┐ │
|
||||
│ Notifications│ │ Tenant Domain(s) Default Policy Status │ │
|
||||
│ Usage&Limits │ │ Core core.example.com Core Pack Active │ │
|
||||
│ Policy Gov │ │ … │ │
|
||||
│ Trust&Sign │ └──────────────────────────────────────────────────────────┘ │
|
||||
│ System │ │
|
||||
│ │ Branding (selected tenant) │
|
||||
│ │ ┌──────────────────────────────────────────────────────────┐ │
|
||||
│ │ │ Logo [Upload] App Name [Stella Ops] Support URL […] │ │
|
||||
│ │ │ Theme: Light/Dark Legal Footer Privacy/License links │ │
|
||||
│ │ └──────────────────────────────────────────────────────────┘ │
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen A3 — Notifications
|
||||
|
||||
**Previously:** `Settings → Notifications`
|
||||
**Now:** `Administration → Notifications`
|
||||
**Why:** Notification *policy* (who gets notified, on what events) is governance/admin. The channel connectivity lives in Integrations, but rules/templates remain here.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Top bar: [Search…] [Tenant: Core ▼] │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ NAV │ Notifications │
|
||||
│ Administration│ Previously called: Settings > Notifications │
|
||||
│ Overview │ │
|
||||
│ Identity │ Rules Channels (connectivity) │
|
||||
│ Tenant │ ┌──────────────────────────┐ ┌───────────────────────────┐ │
|
||||
│ ▸ Notifications││ + Add Rule │ │ Email ✅ Active │ │
|
||||
│ Usage&Limits ││ - “Critical reachable…” │ │ Slack ✅ Active │ │
|
||||
│ Policy Gov ││ - “Bundle blocked…” │ │ Webhook ⚠ Not configured │ │
|
||||
│ Trust&Sign │└──────────────────────────┘ │ [Manage in Integrations →] │ │
|
||||
│ System │ └───────────────────────────┘ │
|
||||
│ │ Templates Delivery / Activity Log │
|
||||
│ │ ┌──────────────────────────┐ ┌─────────────────────────┐ │
|
||||
│ │ │ Default templates │ │ View log Export │ │
|
||||
│ │ │ [Edit Templates] │ │ Filter: last 7d ▼ │ │
|
||||
│ │ └──────────────────────────┘ └─────────────────────────┘ │
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen A4 — Usage & Limits
|
||||
|
||||
**Previously:** `Settings → Usage & Limits`
|
||||
**Now:** `Administration → Usage & Limits` (admin-facing)
|
||||
**Why:** This becomes the **policy/contract view** (limits, entitlements, throttle settings). Operational drilldown (queues, retries, per-job usage) stays in Platform Ops.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Top bar: [Search…] [Tenant: Core ▼] [Month: Feb 2026 ▼] │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ NAV │ Usage & Limits │
|
||||
│ Administration│ Previously called: Settings > Usage & Limits │
|
||||
│ Overview │ │
|
||||
│ Identity │ Usage snapshot │
|
||||
│ Tenant │ ┌──────────────┬──────────────┬──────────────┬────────────┐ │
|
||||
│ Notifications│ │ Scans 6500/ │ Storage 42/ │ Evidence 2800│ API 15k/ │ │
|
||||
│ ▸ Usage&Limits│ │ 10k │ 100 GB │ /10k │ 100k │ │
|
||||
│ Policy Gov │ └──────────────┴──────────────┴──────────────┴────────────┘ │
|
||||
│ Trust&Sign │ │
|
||||
│ System │ Limits & throttles (tenant) │
|
||||
│ │ ┌──────────────────────────────────────────────────────────┐ │
|
||||
│ │ │ Configure Quotas | Burst rules | Per-integration caps │ │
|
||||
│ │ │ [Open Platform Ops → Quotas & Usage] (drilldown dashboard) │ │
|
||||
│ │ └──────────────────────────────────────────────────────────┘ │
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen A5 — Policy Governance
|
||||
|
||||
**Previously:** `Settings → Policy Governance`
|
||||
**Now:** `Administration → Policy Governance` (with strong cross-links to Release Control gates)
|
||||
**Why:** Policies are **organizational governance**. The effect is felt in Release Control (gates), Security (exceptions), Evidence (decision capsule), but the configuration belongs in Admin.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Top bar: [Search…] [Policy Pack: Core (latest) ▼] │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ NAV │ Policy Governance │
|
||||
│ Administration│ Previously called: Settings > Policy Governance │
|
||||
│ Overview │ │
|
||||
│ Identity │ Policy Baselines (per env/region) Governance Rules │
|
||||
│ Tenant │ ┌───────────────────────────────┐ ┌─────────────────────┐│
|
||||
│ Notifications│ │ + Create Baseline │ │ Edit Rules ││
|
||||
│ Usage&Limits │ │ Baselines: Dev/Stage/Prod │ │ Gate: Reachable crit ││
|
||||
│ ▸ Policy Gov │ └───────────────────────────────┘ └─────────────────────┘│
|
||||
│ Trust&Sign │ │
|
||||
│ System │ Simulation Exception Workflow │
|
||||
│ │ ┌───────────────────────────────┐ ┌──────────────────────┐│
|
||||
│ │ │ Run Simulation (what-if) │ │ Configure approvals ││
|
||||
│ │ │ Inputs: bundle/digest/env │ │ Links to Exceptions ││
|
||||
│ │ └───────────────────────────────┘ └──────────────────────┘│
|
||||
│ │ │
|
||||
│ │ Shortcuts: [Go to Release Control → Gates] [Go to Security → Exceptions] │
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen A6 — Trust & Signing
|
||||
|
||||
**Previously:** `Settings → Trust & Signing`
|
||||
**Now:** `Administration → Trust & Signing` (but “used by” Evidence & Audit)
|
||||
**Why:** Key material, issuers, certs, and transparency log integration are **security administration** concerns. Evidence consumes these; it shouldn’t configure them.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Top bar: [Search…] [Tenant: Core ▼] │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ NAV │ Trust & Signing │
|
||||
│ Administration│ Previously called: Settings > Trust & Signing │
|
||||
│ Overview │ │
|
||||
│ Identity │ Signing Keys Issuers Certificates │
|
||||
│ Tenant │ ┌──────────────┐ ┌─────────────┐ ┌────────────────────────┐ │
|
||||
│ Notifications│ │ Manage Keys │ │ Manage │ │ Manage Certs │ │
|
||||
│ Usage&Limits │ └──────────────┘ └─────────────┘ └────────────────────────┘ │
|
||||
│ Policy Gov │ │
|
||||
│ ▸ Trust&Sign │ Transparency Log Trust Scoring Audit Log │
|
||||
│ System │ ┌─────────────────────┐ ┌─────────────────┐ ┌─────────────┐ │
|
||||
│ │ │ Configure Rekor │ │ Edit Score cfg │ │ View log │ │
|
||||
│ │ └─────────────────────┘ └─────────────────┘ └─────────────┘ │
|
||||
│ │ │
|
||||
│ │ Used by: Evidence Packets, Proof Chains, Decision Capsules │
|
||||
│ │ [Open Evidence & Audit → Proof Chains] │
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen A7 — System (Admin)
|
||||
|
||||
**Previously:** `Settings → System`
|
||||
**Now:** `Administration → System` (admin-only controls) + links into Platform Ops for the operational views
|
||||
**Why:** This page becomes the **administrative console** (diagnostics, SLO config, admin job controls). Routine monitoring lives in Platform Ops.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Top bar: [Search…] [Tenant: Core ▼] [Admin-only tools] │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ NAV │ System │
|
||||
│ Administration│ Previously called: Settings > System │
|
||||
│ Overview │ │
|
||||
│ Identity │ Health Check Doctor / Diagnostics │
|
||||
│ Tenant │ ┌─────────────────────────┐ ┌─────────────────────────────┐│
|
||||
│ Notifications│ │ All systems operational │ │ Run Doctor Export report ││
|
||||
│ Usage&Limits │ │ [View in Platform Ops →] │ │ Last run: … ││
|
||||
│ Policy Gov │ └─────────────────────────┘ └─────────────────────────────┘│
|
||||
│ Trust&Sign │ │
|
||||
│ ▸ System │ SLO Monitoring Background Jobs (admin controls) │
|
||||
│ │ ┌─────────────────────────┐ ┌─────────────────────────────┐│
|
||||
│ │ │ View SLOs / edit targets│ │ View jobs (Platform Ops →) ││
|
||||
│ │ └─────────────────────────┘ │ Nightly Ops Report (→) ││
|
||||
│ │ └─────────────────────────────┘│
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Release Control becomes a ROOT menu (and absorbs “Settings → Release Control”)
|
||||
|
||||
## 3) Release Control setup menu → screen graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
RC[Release Control] --> RCH[Control Plane]
|
||||
RC --> RCL[Releases Ledger]
|
||||
RC --> RCB[Release Bundles]
|
||||
RC --> RCG[Gates & Approvals]
|
||||
RC --> RCD[Deployments]
|
||||
RC --> RCE[Regions & Environments]
|
||||
RC --> RCP[Promotion Graph]
|
||||
RC --> RCS[Setup]
|
||||
|
||||
RCS --> S1[Environments & Promotion Paths]
|
||||
RCS --> S2[Targets & Agents]
|
||||
RCS --> S3[Workflows]
|
||||
RCS --> S4[Bundle Templates]
|
||||
|
||||
RCB --> BO[Release Bundle Organizer]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen RC-S0 — Release Control → Setup (hub)
|
||||
|
||||
**Previously:** `Settings → Release Control` (hub with Environments/Targets/Agents/Workflows)
|
||||
**Now:** `Release Control → Setup`
|
||||
**Why:** This configuration directly governs how promotions, deployments, and gates work. It’s operationally part of release control, not general settings.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Top bar: [Search…] [Region: All ▼] [Env: All ▼] │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ NAV │ Release Control — Setup │
|
||||
│ Release Ctrl │ Previously called: Settings > Release Control │
|
||||
│ ControlPlane │ │
|
||||
│ Releases │ Setup areas │
|
||||
│ Bundles │ ┌───────────────────────┐ ┌───────────────────────┐ │
|
||||
│ Gates │ │ Environments & Paths │ │ Targets & Agents │ │
|
||||
│ Deployments │ │ (Dev→Stage→Prod) │ │ (where/how deploy) │ │
|
||||
│ Regions&Env │ │ Formerly: Environments│ │ Formerly: Targets/Agents│ │
|
||||
│ Promotion │ └───────────────────────┘ └───────────────────────┘ │
|
||||
│ ▸ Setup │ ┌───────────────────────┐ ┌───────────────────────────────┐ │
|
||||
│ │ │ Workflows │ │ Bundle Templates │ │
|
||||
│ │ │ Formerly: Workflows │ │ (for bundle organizer) │ │
|
||||
│ │ └───────────────────────┘ └───────────────────────────────┘ │
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen RC-S1 — Environments & Promotion Paths
|
||||
|
||||
**Previously:** `Settings → Release Control → Environments`
|
||||
**Now:** `Release Control → Setup → Environments & Promotion Paths` (and linked from `Regions & Environments`)
|
||||
**Why:** This is the **promotion graph definition** (pipelines, stages, gates). It must be adjacent to release visibility.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Release Control / Setup / Environments & Paths │
|
||||
│ Previously called: Settings > Release Control > Environments │
|
||||
├──────────────────────────────────────────────────────────────────────────────┤
|
||||
│ [ + Add Environment ] [ + Add Region ] [Edit Promotion Graph] [Policy Baseline→] │
|
||||
│ │
|
||||
│ Regions (left) Promotion Paths (right) │
|
||||
│ ┌───────────────────────┐ ┌───────────────────────────────────────────┐ │
|
||||
│ │ US-East │ │ Dev → Stage → Prod │ │
|
||||
│ │ EU-Sovereign │ │ Gates: SBOM OK | Reachability | Approvals │ │
|
||||
│ │ AirGap-01 │ │ Exceptions: allowed via workflow │ │
|
||||
│ └───────────────────────┘ └───────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ Environment details │
|
||||
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Env: Stage (EU-Sovereign) Targets: 3 Agents: 2 Workflow: Blue/Green │ │
|
||||
│ │ Baseline: Core Policy Pack Notifications: Stage-Release channel │ │
|
||||
│ └──────────────────────────────────────────────────────────────────────────┘ │
|
||||
└──────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen RC-S2 — Targets & Agents
|
||||
|
||||
**Previously:** `Settings → Release Control → Targets` and `Agents`
|
||||
**Now:** `Release Control → Setup → Targets & Agents`
|
||||
**Why:** These define *how* releases reach runtime. They are release-control primitives, while the *connectors* (SSH, Nomad, ECS, etc.) are Integrations.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Release Control / Setup / Targets & Agents │
|
||||
│ Previously called: Settings > Release Control > Targets + Agents │
|
||||
├──────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Targets Agents │
|
||||
│ [ + Add Target ] [ + Register Agent ] │
|
||||
│ ┌───────────────────────────────────────────────┐ ┌──────────────────────┐ │
|
||||
│ │ Name Type Region Status │ │ Agent Region Status │ │
|
||||
│ │ swarm-01 DockerSwarm EU ✅ Healthy │ │ ag-12 EU ✅ │ │
|
||||
│ │ ecs-prod AWS ECS US ⚠ Degraded │ │ ag-09 US ⚠ │ │
|
||||
│ └───────────────────────────────────────────────┘ └──────────────────────┘ │
|
||||
│ │
|
||||
│ Mapping │
|
||||
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Env: Stage → Targets: swarm-01, nomad-02 → Agents: ag-12 │ │
|
||||
│ │ Env: Prod → Targets: ecs-prod → Agents: ag-09 │ │
|
||||
│ └──────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ Notes: Connectivity lives in Integrations > Targets/Runtimes (SSH/VPN creds). │
|
||||
└──────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen RC-S3 — Workflows
|
||||
|
||||
**Previously:** `Settings → Release Control → Workflows`
|
||||
**Now:** `Release Control → Setup → Workflows`
|
||||
**Why:** Workflows are the executable “release doctrine” (blue/green, canary, rollback). They must live next to promotions and approvals.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Release Control / Setup / Workflows │
|
||||
│ Previously called: Settings > Release Control > Workflows │
|
||||
├──────────────────────────────────────────────────────────────────────────────┤
|
||||
│ [ + New Workflow ] [Import] [Validate] │
|
||||
│ │
|
||||
│ Workflow Templates │
|
||||
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Blue/Green — steps: preflight → deploy → smoke → promote → attest │ │
|
||||
│ │ Canary — steps: 5% → 25% → 50% → 100% with gates at each stage │ │
|
||||
│ │ Rollback — steps: select prior digest/bundle → deploy → verify → lock │ │
|
||||
│ └──────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ Default mapping │
|
||||
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Dev: Canary Stage: Blue/Green Prod: Blue/Green (strict gates) │ │
|
||||
│ └──────────────────────────────────────────────────────────────────────────┘ │
|
||||
└──────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Missing crucial capability added: Release Bundle Organizer
|
||||
|
||||
## Screen RC-B0 — Release Bundles (Organizer)
|
||||
|
||||
**Previously:** This capability was **missing / implicit** (digest-first releases existed, but no first-class bundling and config snapshot composition).
|
||||
**Now:** `Release Control → Bundles → Bundle Organizer`
|
||||
**Why:** You need a **bundle abstraction**: “microservice digests + env-derived variables (Vault/Consul) + changelog per repository” becoming an immutable versioned unit that can be gated, approved, exported (air-gap), and promoted.
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Release Control / Bundles / Bundle Organizer │
|
||||
│ Previously called: (new) — fills gap between Release Digest and Multi-svc ship│
|
||||
├──────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Bundle: [Repo Group: payments-platform ▼] Version: [v1.8.0 ▼] Status: Draft│
|
||||
│ [Create Bundle] [Save Draft] [Compute Bundle Digest] [Run Gates] [Request Approval]│
|
||||
│ │
|
||||
│ Included Services (digest-first → bundle version) │
|
||||
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Service Image Digest Service Ver SBOM Reachability Gate │ │
|
||||
│ │ payments-api sha256:… 1.8.0 ✅ OK ✅ runtime ✅ │ │
|
||||
│ │ billing-worker sha256:… 2.3.1 ⚠ crit ⚠ image-only ❌ │ │
|
||||
│ │ ui-gateway sha256:… 0.19.4 ✅ OK ✅ build+run ✅ │ │
|
||||
│ └──────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ Variables Snapshot (derived per env) │
|
||||
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Environment: Stage (EU) │ │
|
||||
│ │ Vault: /kv/stage/payments/* Snapshot: vaultsnap-91a2 Diff: masked │ │
|
||||
│ │ Consul: /config/stage/payments/* Snapshot: consulsnap-33f1 Diff: masked │ │
|
||||
│ │ [View resolved manifest] [Export env overlay] │ │
|
||||
│ └──────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ Changelog (per repository) │
|
||||
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ payments-api: PR#1823 Fix tax rounding | PR#1831 Upgrade openssl │ │
|
||||
│ │ billing-worker: PR#944 Retry logic | PR#951 Patch CVE-… │ │
|
||||
│ │ [Pull from SCM Integration] [Edit release notes] │ │
|
||||
│ └──────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ Evidence hooks │
|
||||
│ - Generates: Bundle Manifest, Evidence Packet, Decision Capsule, Export Kit │
|
||||
│ - Links: Security Findings, Exceptions, Approvals, Proof Chains │
|
||||
└──────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Implementation note (UI semantics):**
|
||||
|
||||
* “Bundle Version” is a **human-friendly label**; the authoritative identity remains **content-addressed** (bundle digest) + evidence.
|
||||
* Vault/Consul snapshots are explicit objects, so auditors can see “what config was used” without exposing secrets (masked diffs).
|
||||
|
||||
---
|
||||
|
||||
# Integrations is still essential, but kept clean: connectivity & sync health live here
|
||||
|
||||
## 4) Integrations menu → screen graph
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
INT[Integrations] --> I0[Overview]
|
||||
INT --> I1[SCM]
|
||||
INT --> I2[CI/CD]
|
||||
INT --> I3[Registries]
|
||||
INT --> I4[Secrets]
|
||||
INT --> I5[Targets / Runtimes]
|
||||
INT --> I6[Feeds]
|
||||
INT --> I7[Notification Providers]
|
||||
I0 --> ID[Integration Detail]
|
||||
|
||||
I6 -.advisory freshness drives.-> SR4[Security & Risk > Advisory Sources]
|
||||
I6 -.offline mirroring handled by.-> OPS6[Platform Ops > Feed Mirror & AirGap Ops]
|
||||
I4 -.config snapshots used by.-> RCB[Release Bundles]
|
||||
I1 -.changelog used by.-> RCB
|
||||
I3 -.digests & image sbom used by.-> RC[Release Control]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen I0 — Integrations Overview
|
||||
|
||||
**Previously:** `Settings → Integrations`
|
||||
**Now:** `Integrations → Overview` (root menu)
|
||||
**Why:** Integrations are cross-cutting. This page becomes the **single source of truth for connectivity + data freshness**, with clear escalation links (Nightly Ops Report, Feed Mirror, DLQ).
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Top bar: [Search…] [Tenant: Core ▼] │
|
||||
├───────────────┬──────────────────────────────────────────────────────────────┤
|
||||
│ NAV │ Integrations │
|
||||
│ Integrations │ Previously called: Settings > Integrations │
|
||||
│ ▸ Overview │ │
|
||||
│ SCM │ Status summary │
|
||||
│ CI/CD │ ┌───────────────┬───────────────┬───────────────┐ │
|
||||
│ Registries │ │ Connected: 6 │ Degraded: 1 │ Disconnected:1│ │
|
||||
│ Secrets │ └───────────────┴───────────────┴───────────────┘ │
|
||||
│ Targets │ │
|
||||
│ Feeds │ Filters: [All] [SCM] [CI/CD] [Registries] [Secrets] [Feeds] │
|
||||
│ Notify Prov │ │
|
||||
│ │ Cards │
|
||||
│ │ ┌──────────────────────────────────────────────────────────┐ │
|
||||
│ │ │ GitHub Enterprise ✅ last sync 5m scope: 42 repos │ │
|
||||
│ │ │ Jenkins ⚠ degraded last sync 1h errors: 3 │ │
|
||||
│ │ │ NVD Feed ❌ disconnected last ok: 2d (blocks rescans) │ │
|
||||
│ │ │ Vault ✅ last sync 10m paths: 18 │ │
|
||||
│ │ └──────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ │ Escalation: [Nightly Ops Report →] [Platform Ops → DLQ] │
|
||||
└───────────────┴──────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Screen ID — Integration Detail (template)
|
||||
|
||||
**Previously:** You’d click an integration card; details were inconsistent.
|
||||
**Now:** Every integration has a standardized detail page.
|
||||
**Why:** You need uniform answers to: **Is it connected? What data is stale? What is blocked downstream?**
|
||||
|
||||
```text
|
||||
┌──────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Integrations / Detail: NVD Feed │
|
||||
│ Previously called: Settings > Integrations (card detail) │
|
||||
├──────────────────────────────────────────────────────────────────────────────┤
|
||||
│ Status: ❌ Disconnected Last healthy sync: 2d ago Owner: SecOps │
|
||||
│ [Test Connection] [Reconnect] [View Errors] [Open DLQ] [Open Nightly Report] │
|
||||
│ │
|
||||
│ Sync Health │
|
||||
│ ┌──────────────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ Schedule: hourly Last attempt: 1h ago Result: timeout │ │
|
||||
│ │ Freshness SLA: 6h Current freshness: 2d (breach) │ │
|
||||
│ │ Downstream impact: CVE re-scan blocked; policy “re-evaluate on update” stale│ │
|
||||
│ └──────────────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
│ Configuration (readable, safe) │
|
||||
│ - Endpoint: … │
|
||||
│ - Auth: (masked) │
|
||||
│ - Proxy: … │
|
||||
└──────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## What happened to “Settings → Security Data”?
|
||||
|
||||
This legacy menu item typically mixed **two different concerns**:
|
||||
|
||||
1. **Connectivity & syncing** of advisory sources (NVD/OSV/etc.)
|
||||
2. **Security decisioning** (how sources are interpreted in policy gates)
|
||||
|
||||
**Redesign mapping (explicit):**
|
||||
|
||||
* **Connectivity + freshness** → `Integrations → Feeds` (and offline mirroring in `Platform Ops → Feed Mirror & AirGap Ops`)
|
||||
* **How advisories affect risk/gates** → `Security & Risk → Advisory Sources`
|
||||
|
||||
(If you want, I’ll produce the **Advisory Sources** ASCII in the next Security pack so it stays consistent with your “second class screens” requirement.)
|
||||
|
||||
---
|
||||
|
||||
## Quick confirmation against the constraints you gave
|
||||
|
||||
* **Main reorganization preserved** (same root modules, Release Control is root, Admin is last/root).
|
||||
* **Every screen includes “Previously called …”** in the mock header.
|
||||
* **Release bundle organizer added** with Vault/Consul variables + per-repo changelog.
|
||||
|
||||
If you want the next message to continue, I’ll do the **Security Data / Advisory Sources** redesign as a focused pack (since it straddles Security & Risk + Integrations + Ops), and include Mermaid + ASCII the same way.
|
||||
5
docs/modules/ui/v2-rewire/prompt.txt
Normal file
5
docs/modules/ui/v2-rewire/prompt.txt
Normal file
@@ -0,0 +1,5 @@
|
||||
|
||||
now tell me how should tell my claude opus or codex agents to read through all of these mocks packs (and which ones exactly) so he/she can create sprints for the transformation. make sure you include reference to specific pack message in latest and greatest shape you have sent me.
|
||||
there should instructions that some of the backend might be missing so the agent needs to investigate what needs to be used as endpoints if existing or what should be created and spec for it.
|
||||
also seems we have duplicated screens on following packs. make sure there is instruction what pack what screens / information contains and if updated where and why it is updated.
|
||||
also note the pack messages were dumpt to files like pack-01.md, pack-02... pack-21.md
|
||||
145
docs/modules/ui/v2-rewire/source-of-truth.md
Normal file
145
docs/modules/ui/v2-rewire/source-of-truth.md
Normal file
@@ -0,0 +1,145 @@
|
||||
# UI v2 Rewire Source of Truth
|
||||
|
||||
Status: Active
|
||||
Date: 2026-02-18
|
||||
Working directory: `docs/modules/ui/v2-rewire`
|
||||
|
||||
## 1) Hard Rules
|
||||
|
||||
1. For overlapping guidance, higher pack number wins.
|
||||
2. If a higher pack is partial, keep the latest lower-pack detail for uncovered screens.
|
||||
3. Inside one pack, interpret in this order: `Now/New location` statements, menu/screen graphs, then ASCII/rationale text.
|
||||
4. Canonical planning references must come from this file plus `authority-matrix.md`, not raw packs alone.
|
||||
|
||||
## 2) Canonical IA (v2)
|
||||
|
||||
### 2.1 Root domains
|
||||
|
||||
Canonical root domains are:
|
||||
- `Dashboard` (release mission board)
|
||||
- `Release Control`
|
||||
- `Security & Risk`
|
||||
- `Evidence & Audit`
|
||||
- `Integrations`
|
||||
- `Platform Ops`
|
||||
- `Administration`
|
||||
|
||||
Rationale:
|
||||
- `Dashboard` is last explicitly upgraded as a release-centric entrypoint in Pack 16.
|
||||
- Root domain framing is explicit in Pack 21 and remains the governing top-level grouping.
|
||||
|
||||
### 2.2 Ownership decisions resolved by higher-pack precedence
|
||||
|
||||
These are authoritative for planning and replace older conflicting placements:
|
||||
- `Policy Governance` belongs to `Administration` (Pack 21 overrides Packs 5/9/11).
|
||||
- `Trust & Signing` belongs to `Administration`, with consumption links from Evidence/Security (Pack 21 overrides Packs 9/11/20 on ownership).
|
||||
- `System` belongs to `Administration` with operational drilldowns into `Platform Ops` (Pack 21 overrides Packs 9/11 alternatives).
|
||||
- Legacy `Settings -> Security Data` is split:
|
||||
- source connectivity/freshness in `Integrations` plus `Platform Ops` mirror operations
|
||||
- advisory impact on gating in `Security & Risk` (Pack 21 mapping).
|
||||
|
||||
### 2.3 Domain ownership vs nav rendering
|
||||
|
||||
`Releases`, `Approvals`, `Deployments`, `Regions & Environments`, and `Bundles` are Release Control domain capabilities.
|
||||
|
||||
If implementation keeps direct nav shortcuts for `Releases`/`Approvals`, treat that as a rendering convenience only. Domain ownership and contracts remain Release Control-owned.
|
||||
|
||||
## 3) Canonical screen authorities
|
||||
|
||||
Use the following packs as the latest valid source per domain.
|
||||
|
||||
### 3.1 Release Control + Bundle lifecycle
|
||||
|
||||
Authoritative packs:
|
||||
- Pack 21 for `Release Control` root positioning and setup/admin migration
|
||||
- Pack 12 for full Bundle Organizer data model and flows
|
||||
- Pack 13 for release promotion flows anchored on bundle versions
|
||||
- Pack 14 for run/timeline, checkpoints, rollback, replay hooks
|
||||
- Pack 18 for standardized environment detail shell/tabs
|
||||
|
||||
Superseded for this domain:
|
||||
- Packs 1, 4, 8, 11 (historical drafts)
|
||||
|
||||
### 3.2 Dashboard
|
||||
|
||||
Authoritative pack:
|
||||
- Pack 16 (`Dashboard` mission board, env risk + SBOM + hybrid reachability + Nightly/Data signals)
|
||||
|
||||
Superseded:
|
||||
- Packs 1, 4, 8, 11 (dashboard/control-plane variants)
|
||||
|
||||
### 3.3 Approvals
|
||||
|
||||
Authoritative packs:
|
||||
- Pack 17 for upgraded approval queue/detail tabs and decision-ready context
|
||||
- Pack 13 for base release/approval flow coupling
|
||||
|
||||
Superseded:
|
||||
- Packs 1, 4, 8, 13 sections overlapped by Pack 17 detail model
|
||||
|
||||
### 3.4 Security & Risk
|
||||
|
||||
Authoritative packs:
|
||||
- Pack 19 for consolidated decision-first Security screen model
|
||||
- Pack 21 for top-level `Advisory Sources` mapping statement
|
||||
|
||||
Superseded:
|
||||
- Packs 3, 7, and earlier security layouts
|
||||
|
||||
Known gap:
|
||||
- `Advisory Sources` detailed screen spec is not fully expanded in raw packs and must be sprinted as a first planning task.
|
||||
|
||||
### 3.5 Evidence & Audit
|
||||
|
||||
Authoritative pack:
|
||||
- Pack 20 for evidence chain structure (`Evidence Home`, packs/bundles/export/proof/replay/audit)
|
||||
|
||||
Override:
|
||||
- `Trust & Signing` ownership moved to `Administration` by Pack 21. Keep bidirectional deep links.
|
||||
|
||||
Superseded:
|
||||
- Packs 3, 9, 11 evidence structures
|
||||
|
||||
### 3.6 Platform Ops and data confidence
|
||||
|
||||
Authoritative packs:
|
||||
- Pack 15 for `Data Integrity` operating model and bubble-up wiring
|
||||
- Pack 10 for feeds/airgap operational screen specifics where still needed
|
||||
- Pack 21 for top-level Platform Ops taxonomy and admin drilldown links
|
||||
|
||||
Superseded:
|
||||
- Packs 3, 6, 9, 11 operations variants
|
||||
|
||||
### 3.7 Integrations
|
||||
|
||||
Authoritative packs:
|
||||
- Pack 21 for Integrations taxonomy and settings split
|
||||
- Pack 10 for hub/detail/add + feed-source operational ties
|
||||
|
||||
Superseded:
|
||||
- Packs 2, 5, 9 integration placement drafts
|
||||
|
||||
### 3.8 Administration
|
||||
|
||||
Authoritative pack:
|
||||
- Pack 21 (`A0` ... `A7` including Policy, Trust, System)
|
||||
|
||||
Superseded:
|
||||
- Packs 2, 5, 9, 11 admin/settings decompositions
|
||||
|
||||
## 4) Normalized terminology (canonical names)
|
||||
|
||||
Use these terms in sprint tickets/specs:
|
||||
- `Control Plane` -> `Dashboard`
|
||||
- `Packets` -> `Evidence Packs`
|
||||
- `Evidence Bundles` remains `Evidence Bundles`
|
||||
- `Feed Mirror & AirGap Ops` under `Platform Ops` (connectivity still surfaced in `Integrations`)
|
||||
- `Hybrid Reachability` stays second-class (visible in context views, not a standalone product root)
|
||||
|
||||
## 5) Planning gaps to schedule first
|
||||
|
||||
Create early sprints for these spec-completion items before broad implementation starts:
|
||||
- `Security & Risk -> Advisory Sources` full screen definition and contracts
|
||||
- final nav rendering decision for Release Control-owned capabilities (direct shortcuts vs strictly nested)
|
||||
- Trust ownership transition rules between Administration and Evidence workflows (route aliases + breadcrumbs + redirects)
|
||||
- route deprecation map from legacy `Settings/*` and older aliases to final IA paths
|
||||
100
docs/modules/ui/v2-rewire/sprint-planning-guide.md
Normal file
100
docs/modules/ui/v2-rewire/sprint-planning-guide.md
Normal file
@@ -0,0 +1,100 @@
|
||||
# UI v2 Rewire Sprint Planning Guide
|
||||
|
||||
Status: Planning-only guidance
|
||||
Date: 2026-02-18
|
||||
|
||||
This guide defines how to decompose the canonical redesign into many implementation sprints.
|
||||
|
||||
## 1) Required reading order for planners
|
||||
|
||||
1. `source-of-truth.md`
|
||||
2. `authority-matrix.md`
|
||||
3. Authoritative packs for the selected capability area
|
||||
4. Current UI/backend implementation (`src/Web/**`, `src/**/WebService/**`) for feasibility and contract checks
|
||||
|
||||
Do not start sprint writing from raw pack text alone.
|
||||
|
||||
## 2) Planning constraints
|
||||
|
||||
- Higher pack number is authoritative for overlaps.
|
||||
- Keep redesign deterministic and offline-capable.
|
||||
- Treat nav placement changes and backend contract changes as separate work items.
|
||||
- Preserve migration safety with redirect/alias tasks in rollout sprints.
|
||||
|
||||
## 3) Recommended multi-sprint decomposition
|
||||
|
||||
Use independent streams so multiple teams can run in parallel.
|
||||
|
||||
| Stream | Scope | Primary packs |
|
||||
| --- | --- | --- |
|
||||
| `S0-Spec` | close spec gaps and freeze canonical IA terms | `pack-21.md`, `pack-19.md`, `pack-20.md` |
|
||||
| `S1-NavShell` | root nav structure, route aliases, breadcrumbs, migration banners | `pack-21.md`, `pack-16.md` |
|
||||
| `S2-ReleaseCore` | bundles, releases, approvals, run timeline | `pack-12.md`, `pack-13.md`, `pack-14.md`, `pack-17.md` |
|
||||
| `S3-EnvOps` | environment detail + data confidence + ops bubble-up | `pack-18.md`, `pack-15.md`, `pack-16.md` |
|
||||
| `S4-SecurityEvidence` | Security consolidation + Evidence consolidation + cross-links | `pack-19.md`, `pack-20.md` |
|
||||
| `S5-AdminIntegrations` | Administration A0-A7, Integrations taxonomy, feeds split | `pack-21.md`, `pack-10.md` |
|
||||
|
||||
## 4) Endpoint and contract investigation workflow
|
||||
|
||||
Backend coverage is incomplete in some areas. Every sprint must include an explicit endpoint contract pass.
|
||||
|
||||
### 4.1 For each planned screen, classify backend status
|
||||
|
||||
Use one of these states:
|
||||
- `EXISTS_COMPAT` - endpoint exists and contract matches target UI
|
||||
- `EXISTS_ADAPT` - endpoint exists but response/request shape or semantics must be adapted
|
||||
- `MISSING_NEW` - endpoint does not exist and must be specified/implemented
|
||||
|
||||
### 4.2 Required investigation steps
|
||||
|
||||
1. Locate current route/component wiring in UI.
|
||||
2. Locate current API client call(s) in UI client layer.
|
||||
3. Locate backend endpoint(s) across service modules.
|
||||
4. Compare current contract to target pack behavior.
|
||||
5. Record status (`EXISTS_COMPAT` / `EXISTS_ADAPT` / `MISSING_NEW`).
|
||||
6. If `MISSING_NEW`, write a contract task with request/response schema, auth scope, and evidence requirements.
|
||||
|
||||
### 4.3 Search anchors (read-only references)
|
||||
|
||||
- UI routing and nav:
|
||||
- `src/Web/StellaOps.Web/src/app/app.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/layout/app-sidebar/app-sidebar.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/**/**.routes.ts`
|
||||
- UI API clients:
|
||||
- `src/Web/StellaOps.Web/src/app/core/api/*.ts`
|
||||
- Backend endpoint surfaces:
|
||||
- `src/**/WebService/Endpoints/*.cs`
|
||||
- `src/**/Infrastructure/**` for data dependencies
|
||||
|
||||
## 5) Mandatory sprint ticket fields (for every UI feature ticket)
|
||||
|
||||
Use this minimum structure in planning docs:
|
||||
|
||||
```md
|
||||
### <Ticket ID> - <Feature>
|
||||
- Canonical source: <source-of-truth section + authority-matrix row + pack sections>
|
||||
- UI scope: <routes/components>
|
||||
- Backend contract status: EXISTS_COMPAT | EXISTS_ADAPT | MISSING_NEW
|
||||
- Endpoint(s): <current or proposed>
|
||||
- Auth scope impact: <new/changed scopes>
|
||||
- Offline/determinism impact: <none or required behavior>
|
||||
- Redirect/deprecation impact: <legacy paths>
|
||||
- Evidence required: <tests, screenshots, contract tests>
|
||||
```
|
||||
|
||||
## 6) First planning backlog (must be created before build sprints)
|
||||
|
||||
1. Spec gap sprint for `Security & Risk -> Advisory Sources` detailed screen model and contracts.
|
||||
2. Nav migration sprint defining final rendering strategy for Release Control-owned capabilities.
|
||||
3. Trust ownership transition sprint (Administration owner, Evidence consumer links and redirects).
|
||||
4. Route alias/deprecation sprint from legacy settings and historical paths.
|
||||
|
||||
## 7) Definition of ready for implementation sprint
|
||||
|
||||
A capability is ready only when:
|
||||
- authoritative pack sections are listed,
|
||||
- endpoint status is classified for each screen,
|
||||
- missing contracts are specified,
|
||||
- scope/permission changes are identified,
|
||||
- migration/redirect handling is scoped,
|
||||
- test evidence expectations are explicit.
|
||||
Reference in New Issue
Block a user