docs(ui): map restoration topics and delivery sprints
This commit is contained in:
master
75
docs/modules/ui/restoration-topics/README.md
Normal file
75
docs/modules/ui/restoration-topics/README.md
Normal file
@@ -0,0 +1,75 @@
|
||||
# Restoration Topic Shapes
|
||||
|
||||
This directory turns the top restoration candidates into concrete product shapes.
|
||||
|
||||
It answers four questions for each topic:
|
||||
- Is this a standalone product, a submenu, a tabbed area, or a contextual tool?
|
||||
- Where should it live in the current Stella Ops IA?
|
||||
- Which dropped or weakly surfaced components should be merged into it?
|
||||
- Where do single actions, panels, and stray pages go if they do not deserve their own product?
|
||||
|
||||
## Topic Index
|
||||
|
||||
- [Watchlist](./watchlist.md)
|
||||
- [Reachability Witnessing](./reachability-witnessing.md)
|
||||
- [Platform Ops Consolidation](./platform-ops-consolidation.md)
|
||||
- [Triage Explainability Workbench](./triage-explainability-workbench.md)
|
||||
- [Workflow Visualization And Replay](./workflow-visualization-and-replay.md)
|
||||
|
||||
## Detailed UX Dossiers
|
||||
|
||||
- [Identity Watchlist](../watchlist-operations/README.md)
|
||||
- [Reachability Witnessing](../reachability-witnessing/README.md)
|
||||
- [Platform Ops Consolidation](../platform-ops-consolidation/README.md)
|
||||
- [Triage Explainability Workspace](../triage-explainability-workspace/README.md)
|
||||
- [Workflow Visualization And Replay](../workflow-visualization-replay/README.md)
|
||||
- [Contextual Actions And Stray Surfaces](../contextual-actions-patterns/README.md)
|
||||
|
||||
## Implementation Sprint Set
|
||||
|
||||
- `docs/implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md`
|
||||
- `docs/implplan/SPRINT_20260307_025_FE_reachability_witnessing_merge.md`
|
||||
- `docs/implplan/SPRINT_20260307_026_FE_platform_ops_consolidation.md`
|
||||
- `docs/implplan/SPRINT_20260307_027_FE_triage_explainability_workspace.md`
|
||||
- `docs/implplan/SPRINT_20260307_028_FE_workflow_visualization_replay.md`
|
||||
- `docs/implplan/SPRINT_20260307_029_FE_contextual_actions_and_stray_surfaces.md`
|
||||
|
||||
## Placement Matrix
|
||||
|
||||
| Topic | Recommended shape | Primary menu placement | Primary tabs / submenus |
|
||||
| --- | --- | --- | --- |
|
||||
| Watchlist | Narrow operational shell, not standalone product | `Setup > Trust & Signing` | `Entries`, `Alerts`, `Tuning` |
|
||||
| Reachability Witnessing | Merge into existing security feature | `Security > Reachability` | `Coverage`, `Witnesses`, `PoE / Exposure`, `Sensor Gaps` |
|
||||
| Platform Ops Consolidation | Consolidated ops shell | `Ops > Operations` | `Data Integrity`, `Jobs & Queues`, `Health & SLO`, `Feeds & Airgap`, `Quotas`, `AOC`, `Diagnostics` |
|
||||
| Triage Explainability Workbench | Merge into triage workspace | `Triage > Artifact Workspace` and `Triage > Audit Bundles` | list tabs for lanes; right-rail explainability tabs in detail view |
|
||||
| Workflow Visualization And Replay | Contextual runtime view, not standalone product | `Releases > Runs` and `Evidence > Verify & Replay` | `Summary`, `Graph`, `Timeline`, `Replay`, `Evidence` |
|
||||
|
||||
## Placement Rules For Stray Pages And Single Actions
|
||||
|
||||
Use these rules when a dropped surface has value but does not deserve its own top-level product.
|
||||
|
||||
### 1. Configurable capability with low daily traffic
|
||||
- Put it under the owning admin/setup area as a submenu or tab.
|
||||
- Example: watchlist entry management belongs under trust/signing setup, not as a top-level product.
|
||||
|
||||
### 2. Operator workflow with one dominant list/detail loop
|
||||
- Put the list in the parent product and make advanced tools tabs, drawers, or right-rail panels.
|
||||
- Example: quiet-lane and AI recommendation flows belong inside triage list/detail pages.
|
||||
|
||||
### 3. Explanation or evidence for an existing decision
|
||||
- Make it contextual to the owning workflow, usually a detail tab or drawer.
|
||||
- Example: witness view and PoE belong under reachability, findings, or release-context evidence.
|
||||
|
||||
### 4. Runtime graph or replay view
|
||||
- Put it on the run detail page first, with optional evidence-side entry points.
|
||||
- Example: workflow visualization should be a run-detail tab, not a separate sidebar product.
|
||||
|
||||
### 5. Cross-cutting operational utilities
|
||||
- Keep one consolidated ops overview and route tree.
|
||||
- Do not create a second ops product when grouped cards and subroutes are enough.
|
||||
|
||||
## Related Inputs
|
||||
|
||||
- [Restoration Priorities](../component-preservation-map/RESTORATION_PRIORITIES.md)
|
||||
- [Policy Decisioning Studio](../policy-decisioning-studio/README.md)
|
||||
- [Contextual Actions And Stray Surfaces](../contextual-actions-patterns/README.md)
|
||||
109
docs/modules/ui/restoration-topics/platform-ops-consolidation.md
Normal file
109
docs/modules/ui/restoration-topics/platform-ops-consolidation.md
Normal file
@@ -0,0 +1,109 @@
|
||||
# Platform Ops Consolidation
|
||||
|
||||
## Recommendation
|
||||
|
||||
Do not restore old Platform Ops as a second ops product.
|
||||
|
||||
Merge the legacy overview and legacy leaves into the active `Ops > Operations` shell and keep one consolidated operator surface.
|
||||
|
||||
## Why
|
||||
|
||||
- The current app already has an `Ops > Operations` route tree.
|
||||
- The old `platform-ops` pages and the newer `platform/ops` pages describe the same operator concerns with different shells.
|
||||
- Duplicating ops navigation would recreate the same fragmentation that dropped the original branch.
|
||||
|
||||
## Primary Placement
|
||||
|
||||
- Menu group: `Ops`
|
||||
- Section: `Operations`
|
||||
|
||||
Canonical root:
|
||||
- `/ops/operations`
|
||||
|
||||
## Product Shape
|
||||
|
||||
One overview page plus grouped subroutes is enough.
|
||||
|
||||
### Core groups on the overview
|
||||
- `Blocking`
|
||||
- Data Integrity, AOC Compliance, critical platform alerts
|
||||
- `Execution`
|
||||
- Jobs & Queues, Scheduler, Dead-Letter, Signals
|
||||
- `Health`
|
||||
- Health & SLO, Diagnostics, system status
|
||||
- `Supply And Airgap`
|
||||
- Feeds & Airgap, Offline Kit, Pack Registry
|
||||
- `Capacity`
|
||||
- Quotas & Limits
|
||||
|
||||
## Merge Map
|
||||
|
||||
### Keep as the main shell
|
||||
- current `PlatformOpsOverviewPageComponent`
|
||||
- current `operations.routes.ts`
|
||||
|
||||
### Absorb from legacy Platform Ops
|
||||
- old overview cards and descriptive grouping
|
||||
- telemetry and federation-style operational snapshots where still useful
|
||||
- any platform-state widgets missing from the newer overview
|
||||
|
||||
## Placement For Single Actions And Stray Pages
|
||||
|
||||
### Agent fleet
|
||||
- Do not duplicate under Ops as a first-class page
|
||||
- Primary home should be `Setup > Topology`
|
||||
- Ops overview may deep-link to topology health when operator context requires it
|
||||
|
||||
### Security data freshness / data trust details
|
||||
- Put under `Data Integrity`
|
||||
- Not as a standalone ops product page
|
||||
|
||||
### Diagnostics
|
||||
- Keep as a submenu under `Ops > Operations`
|
||||
- Do not split it into a second “doctor-style” product entry if the route already exists
|
||||
|
||||
### AOC compliance
|
||||
- Keep under `Ops > Operations`
|
||||
- Surface blocking status cards on overview, full detail in its own child route
|
||||
|
||||
### Quotas, offline kit, feeds, health
|
||||
- Keep as child routes under `Ops > Operations`
|
||||
- Use grouped cards on the overview page, not new sidebar branches
|
||||
|
||||
## Suggested Submenu Structure
|
||||
|
||||
- `Ops > Operations > Overview`
|
||||
- `Ops > Operations > Data Integrity`
|
||||
- `Ops > Operations > Jobs & Queues`
|
||||
- `Ops > Operations > Health & SLO`
|
||||
- `Ops > Operations > Feeds & Airgap`
|
||||
- `Ops > Operations > Offline Kit`
|
||||
- `Ops > Operations > Quotas & Limits`
|
||||
- `Ops > Operations > AOC Compliance`
|
||||
- `Ops > Operations > Diagnostics`
|
||||
- `Ops > Operations > Signals`
|
||||
- `Ops > Operations > Pack Registry`
|
||||
|
||||
## What Not To Do
|
||||
|
||||
- Do not revive `/platform-ops/*` as a parallel route tree.
|
||||
- Do not keep both a legacy ops overview and a current ops overview.
|
||||
- Do not put topology ownership under Ops when Setup already owns it.
|
||||
|
||||
## Detailed UX And Sprint
|
||||
|
||||
- Detailed UX dossier: `../platform-ops-consolidation/README.md`
|
||||
- Implementation sprint: `../../../implplan/SPRINT_20260307_026_FE_platform_ops_consolidation.md`
|
||||
|
||||
## Corroborating Inputs
|
||||
|
||||
- `docs/UI_GUIDE.md`
|
||||
- `docs/modules/ui/operations/observability-guide.md`
|
||||
- `docs/modules/notify/operations/observability.md`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/operations.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/platform/ops/platform-ops-overview-page.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/platform-ops/platform-ops-overview.component.ts`
|
||||
|
||||
## Final Call
|
||||
|
||||
This is a consolidation job, not a restoration of a separate product. Keep one `Ops > Operations` shell, absorb the missing legacy widgets and grouping logic, and deep-link out to Setup-owned topology where needed.
|
||||
115
docs/modules/ui/restoration-topics/reachability-witnessing.md
Normal file
115
docs/modules/ui/restoration-topics/reachability-witnessing.md
Normal file
@@ -0,0 +1,115 @@
|
||||
# Reachability Witnessing
|
||||
|
||||
## Recommendation
|
||||
|
||||
Do not restore Witnessing as a separate product.
|
||||
|
||||
Merge it into the existing `Security > Reachability` area as deeper tabs and contextual detail views.
|
||||
|
||||
## Why
|
||||
|
||||
- `ReachabilityCenterComponent` already owns the top-level coverage-first posture.
|
||||
- `WitnessPageComponent` and `PoEDrawerComponent` are explanation and proof surfaces for the same capability.
|
||||
- Reachability evidence also matters to findings, triage, and release gates, so the detailed views must be reusable from those contexts.
|
||||
|
||||
## Primary Placement
|
||||
|
||||
- Menu group: `Security`
|
||||
- Section: `Reachability`
|
||||
|
||||
Suggested canonical root:
|
||||
- `/security/reachability`
|
||||
|
||||
## Product Shape
|
||||
|
||||
Keep one reachability shell and add tabs.
|
||||
|
||||
### Tabs
|
||||
- `Coverage`
|
||||
- current fleet/sensor coverage view
|
||||
- `Witnesses`
|
||||
- searchable list of witness records and witness detail pages
|
||||
- `PoE / Exposure`
|
||||
- proof-of-exposure artifacts, export/verify actions, and DSSE/Rekor state
|
||||
- `Sensor Gaps`
|
||||
- missing sensors, stale facts, and remediation queues
|
||||
|
||||
## Merge Map
|
||||
|
||||
### Into `Coverage`
|
||||
- `ReachabilityCenterComponent`
|
||||
|
||||
### Into `Witnesses`
|
||||
- `WitnessPageComponent`
|
||||
- becomes the full detail page for a selected witness
|
||||
|
||||
### Into `PoE / Exposure`
|
||||
- `PoEDrawerComponent`
|
||||
- becomes a reusable evidence drawer plus an optional tabbed detail route when permalink is needed
|
||||
|
||||
## Placement For Single Actions And Small Surfaces
|
||||
|
||||
### Witness detail
|
||||
- Full page under `Witnesses`
|
||||
- Suggested route:
|
||||
- `/security/reachability/witnesses/:witnessId`
|
||||
|
||||
### PoE detail
|
||||
- Default to a right drawer from witness detail, finding detail, triage, or release-context views
|
||||
- Only create a standalone route for deep-link/export cases:
|
||||
- `/security/reachability/poe/:artifactId`
|
||||
|
||||
### Export DOT / Mermaid
|
||||
- Keep as witness-detail actions
|
||||
- Do not turn export formats into their own pages
|
||||
|
||||
### Replay verify
|
||||
- Keep as an action button on witness and PoE detail
|
||||
- Also expose the same action from release-context evidence pages
|
||||
|
||||
## Secondary Entry Points
|
||||
|
||||
These should deep-link into the same reachability surfaces:
|
||||
|
||||
- `Security > Findings`
|
||||
- open witness detail for a finding
|
||||
- `Triage > Artifact Workspace`
|
||||
- open witness drawer from artifact detail
|
||||
- `Releases` or Decisioning Studio release context
|
||||
- open witness/PoE evidence when a gate uses reachability proof
|
||||
|
||||
## What Not To Do
|
||||
|
||||
- Do not create a separate sidebar product called `Witnessing` or `Proof of Exposure`.
|
||||
- Do not leave PoE only as a detached drawer with no canonical parent route.
|
||||
- Do not split coverage, witness detail, and proof detail across different top-level sections.
|
||||
|
||||
## Route Sketch
|
||||
|
||||
- `/security/reachability`
|
||||
- `/security/reachability/coverage`
|
||||
- `/security/reachability/witnesses`
|
||||
- `/security/reachability/witnesses/:witnessId`
|
||||
- `/security/reachability/poe`
|
||||
- `/security/reachability/poe/:artifactId`
|
||||
- `/security/reachability/gaps`
|
||||
|
||||
## Detailed UX And Sprint
|
||||
|
||||
- Detailed UX dossier: `../reachability-witnessing/README.md`
|
||||
- Implementation sprint: `../../../implplan/SPRINT_20260307_025_FE_reachability_witnessing_merge.md`
|
||||
|
||||
## Corroborating Inputs
|
||||
|
||||
- `docs/contracts/witness-v1.md`
|
||||
- `docs/architecture/EVIDENCE_PIPELINE_ARCHITECTURE.md`
|
||||
- `docs/modules/scanner/reachability.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/reachability/reachability-center.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/reachability/witness-page.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/reachability/poe-drawer.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/security-risk.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/evidence.routes.ts`
|
||||
|
||||
## Final Call
|
||||
|
||||
This should be restored as deeper reachability UX: one security submenu, four tabs, witness as the full detail page, and PoE as a reusable evidence drawer with an optional permalink route.
|
||||
@@ -0,0 +1,125 @@
|
||||
# Triage Explainability Workbench
|
||||
|
||||
## Recommendation
|
||||
|
||||
Do not restore the triage workbenches as separate products.
|
||||
|
||||
Merge them into the active triage list/detail loop, with lane controls at the list level and explainability tools in the artifact detail workspace.
|
||||
|
||||
## Why
|
||||
|
||||
- `QuietLaneWorkbenchComponent` is really a list-state and queue-management concept.
|
||||
- `AiRecommendationWorkbenchComponent` is a detail-side decision aid.
|
||||
- `ReasonCapsuleWorkbenchComponent` is a provenance/explanation panel.
|
||||
- `TriageAuditBundlesComponent` is a real supporting page, but it belongs beside triage, not as a separate workbench brand.
|
||||
|
||||
## Primary Placement
|
||||
|
||||
- Menu group: `Triage`
|
||||
|
||||
Recommended submenu structure:
|
||||
- `Triage > Artifact Workspace`
|
||||
- `Triage > Audit Bundles`
|
||||
|
||||
## Product Shape
|
||||
|
||||
Use one triage workspace with two layers:
|
||||
|
||||
### 1. List layer
|
||||
- manages queues and lanes
|
||||
|
||||
### 2. Detail layer
|
||||
- manages the current artifact/finding decision workspace
|
||||
|
||||
## List-Layer Tabs
|
||||
|
||||
Inside `Artifact Workspace`, use tabs or segmented controls:
|
||||
- `Active`
|
||||
- `Quiet Lane`
|
||||
- `Needs Review`
|
||||
|
||||
This is where the quiet-lane behavior belongs.
|
||||
|
||||
## Detail-Layer Right Rail Or Secondary Tabs
|
||||
|
||||
In artifact detail, add contextual explainability surfaces:
|
||||
- `AI Recommendations`
|
||||
- `Reason Capsule`
|
||||
- `Provenance`
|
||||
- `Decision History`
|
||||
|
||||
These should be secondary tabs or a right-rail stack, not standalone routes.
|
||||
|
||||
## Merge Map
|
||||
|
||||
### Into list layer
|
||||
- `QuietLaneWorkbenchComponent`
|
||||
|
||||
### Into detail layer
|
||||
- `AiRecommendationWorkbenchComponent`
|
||||
- `ReasonCapsuleWorkbenchComponent`
|
||||
|
||||
### Keep as sibling page
|
||||
- `TriageAuditBundlesComponent`
|
||||
- keep as `Triage > Audit Bundles`
|
||||
- also deep-link from `Evidence` when useful
|
||||
|
||||
## Placement For Single Actions And Stray Pages
|
||||
|
||||
### AI suggestion apply / use VEX suggestion
|
||||
- Keep inside artifact detail
|
||||
- It is an action panel, not a page
|
||||
|
||||
### Reason capsule
|
||||
- Keep as expandable card or tab inside artifact detail
|
||||
- It answers “why did this verdict happen?”, so it belongs next to the active decision
|
||||
|
||||
### Provenance breadcrumb
|
||||
- Keep in the detail right rail
|
||||
- It is supporting context, not a route
|
||||
|
||||
### Quiet lane recheck / extend TTL / promote
|
||||
- Keep as list-row or bulk actions inside the `Quiet Lane` tab
|
||||
|
||||
### Audit bundles
|
||||
- Keep as a real page because it has its own list, download flow, and operator lifecycle
|
||||
- Best home:
|
||||
- primary: `Triage > Audit Bundles`
|
||||
- secondary link: `Evidence > Capsules / Exports`
|
||||
|
||||
## Suggested Route Sketch
|
||||
|
||||
- `/triage/artifacts`
|
||||
- `/triage/artifacts?lane=active`
|
||||
- `/triage/artifacts?lane=quiet`
|
||||
- `/triage/artifacts?lane=review`
|
||||
- `/triage/artifacts/:artifactId`
|
||||
- `/triage/artifacts/:artifactId?panel=ai`
|
||||
- `/triage/artifacts/:artifactId?panel=reason`
|
||||
- `/triage/artifacts/:artifactId?panel=provenance`
|
||||
- `/triage/audit-bundles`
|
||||
|
||||
## What Not To Do
|
||||
|
||||
- Do not keep `AI Recommendation Workbench` or `Reason Capsule Workbench` as standalone brands.
|
||||
- Do not turn every decision aid into its own route.
|
||||
- Do not put quiet-lane logic on a separate page when it is fundamentally a list segmentation mode.
|
||||
|
||||
## Detailed UX And Sprint
|
||||
|
||||
- Detailed UX dossier: `../triage-explainability-workspace/README.md`
|
||||
- Implementation sprint: `../../../implplan/SPRINT_20260307_027_FE_triage_explainability_workspace.md`
|
||||
|
||||
## Corroborating Inputs
|
||||
|
||||
- `docs/UI_GUIDE.md`
|
||||
- `docs/ui-analysis/03_TRIAGE_POLICY_OPS_SCREENS.md`
|
||||
- `docs/ui-analysis/05_ROUTE_SUMMARY_AND_OBSERVATIONS.md`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/security-risk.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/triage/triage-artifacts.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/triage/triage-workspace.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/triage/triage-audit-bundles.component.ts`
|
||||
|
||||
## Final Call
|
||||
|
||||
Restore the capability, not the workbench branding. Triage should own one artifact workspace with lane tabs on the list view and explainability panels in the detail view, plus a sibling `Audit Bundles` page.
|
||||
100
docs/modules/ui/restoration-topics/watchlist.md
Normal file
100
docs/modules/ui/restoration-topics/watchlist.md
Normal file
@@ -0,0 +1,100 @@
|
||||
# Watchlist
|
||||
|
||||
## Recommendation
|
||||
|
||||
Do not restore Watchlist as a standalone top-level product.
|
||||
|
||||
Restore it as a narrow operational shell owned by `Trust & Signing`, with alert visibility surfaced into `Mission Control` and `Notifications`.
|
||||
|
||||
## Why
|
||||
|
||||
- The current page is not just a dashboard; it edits identity-matching rules, severities, scopes, dedup windows, and alert behavior.
|
||||
- That makes it closer to trust/security configuration than to a general dashboard.
|
||||
- The runbook frames it as an operational control around signer identities and alert triage, not a broad end-user workspace.
|
||||
|
||||
## Primary Placement
|
||||
|
||||
- Menu group: `Setup`
|
||||
- Section: `Trust & Signing`
|
||||
- New submenu item: `Identity Watchlist`
|
||||
|
||||
Suggested canonical route:
|
||||
- `/setup/trust-signing/watchlist`
|
||||
|
||||
## Secondary Placement
|
||||
|
||||
- `Mission Control > Alerts`
|
||||
- add a filter or alert source chip for watchlist alerts
|
||||
- `Ops > Notifications`
|
||||
- show watchlist channel health, recent emissions, and dedup effectiveness
|
||||
|
||||
These should surface outcomes, not duplicate the configuration shell.
|
||||
|
||||
## Product Shape
|
||||
|
||||
One tabbed page is enough.
|
||||
|
||||
### Tabs
|
||||
- `Entries`
|
||||
- list, create, edit, enable/disable, delete, and test matching rules
|
||||
- `Alerts`
|
||||
- recent watchlist alerts, severity filters, matched identities, and alert triage shortcuts
|
||||
- `Tuning`
|
||||
- dedup windows, channel overrides, pattern guidance, and performance/volume hints
|
||||
|
||||
## Merge Map
|
||||
|
||||
Merge these current behaviors into the new shell:
|
||||
- `WatchlistPageComponent`
|
||||
- `list` mode -> `Entries`
|
||||
- `edit` mode -> create/edit drawer or inline detail panel inside `Entries`
|
||||
- `alerts` mode -> `Alerts`
|
||||
|
||||
## Placement For Single Actions And Small Surfaces
|
||||
|
||||
### Create / edit entry
|
||||
- Use a drawer or split detail panel inside `Entries`
|
||||
- Do not create a separate route unless audit history requires a permalink
|
||||
|
||||
### Test pattern
|
||||
- Keep it in the create/edit panel
|
||||
- It is a supporting action, not its own page
|
||||
|
||||
### Alert detail
|
||||
- Open as a drawer from `Alerts`
|
||||
- From Mission Control, deep-link back into `/setup/trust-signing/watchlist?tab=alerts&alertId=...`
|
||||
|
||||
### Channel health or dedup diagnostics
|
||||
- Keep as cards in `Tuning`
|
||||
- Also surface summary KPIs in `Ops > Notifications`
|
||||
|
||||
## What Not To Do
|
||||
|
||||
- Do not put watchlist configuration directly under `Mission Control`; that is the wrong ownership boundary.
|
||||
- Do not create a top-level `Watchlist` product in the sidebar; the scope is too narrow.
|
||||
- Do not split configuration and alert history into unrelated shells; they are part of one operational control.
|
||||
|
||||
## Route Sketch
|
||||
|
||||
- `/setup/trust-signing/watchlist`
|
||||
- `/setup/trust-signing/watchlist/entries`
|
||||
- `/setup/trust-signing/watchlist/alerts`
|
||||
- `/setup/trust-signing/watchlist/tuning`
|
||||
|
||||
## Detailed UX And Sprint
|
||||
|
||||
- Detailed UX dossier: `../watchlist-operations/README.md`
|
||||
- Implementation sprint: `../../../implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md`
|
||||
|
||||
## Corroborating Inputs
|
||||
|
||||
- `docs/modules/attestor/guides/identity-watchlist.md`
|
||||
- `docs/operations/watchlist-monitoring-runbook.md`
|
||||
- `docs/features/checked/web/identity-watchlist-management-ui.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/watchlist/watchlist-page.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/mission-control.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/operations.routes.ts`
|
||||
|
||||
## Final Call
|
||||
|
||||
This should be restored, but as a `Trust & Signing` submenu with three tabs, plus alert visibility hooks in `Mission Control` and `Notifications`.
|
||||
@@ -0,0 +1,113 @@
|
||||
# Workflow Visualization And Replay
|
||||
|
||||
## Recommendation
|
||||
|
||||
Do not restore workflow visualization as a standalone sidebar product.
|
||||
|
||||
Restore it as a runtime run-detail capability under `Releases`, with a secondary entry point from `Evidence > Verify & Replay`, and a smaller design-time preview inside the workflow editor.
|
||||
|
||||
## Why
|
||||
|
||||
- The visualizer is about understanding a run, not browsing a separate product area.
|
||||
- The feature already has runtime concepts like critical path, timeline, node states, and auto-refresh.
|
||||
- Those belong closest to release runs, replay, and evidence.
|
||||
|
||||
## Primary Placement
|
||||
|
||||
- Menu group: `Releases`
|
||||
- Section: `Runs`
|
||||
|
||||
Primary route family:
|
||||
- `/releases/runs/:runId/*`
|
||||
|
||||
## Secondary Placement
|
||||
|
||||
- `Evidence > Verify & Replay`
|
||||
- link into the same run graph/replay context
|
||||
|
||||
### Design-time secondary placement
|
||||
- `Administration > Workflows`
|
||||
- workflow editor gets a `Preview DAG` mode or tab
|
||||
- this is authoring-time preview, not runtime run analysis
|
||||
|
||||
## Product Shape
|
||||
|
||||
### Release run detail tabs
|
||||
- `Summary`
|
||||
- `Graph`
|
||||
- `Timeline`
|
||||
- `Critical Path`
|
||||
- `Replay`
|
||||
- `Evidence`
|
||||
|
||||
The graph/timeline/critical-path experiences should be facets of the same run detail, not separate products.
|
||||
|
||||
## Merge Map
|
||||
|
||||
### Into runtime run detail
|
||||
- `WorkflowVisualizerComponent`
|
||||
- `TimeTravelControlsComponent`
|
||||
- `StepDetailPanelComponent`
|
||||
|
||||
### Into design-time authoring
|
||||
- reusable graph-preview subset of `WorkflowVisualizerComponent`
|
||||
- only for `Workflow Editor`
|
||||
- without runtime replay state
|
||||
|
||||
## Placement For Single Actions And Stray Pages
|
||||
|
||||
### Step detail
|
||||
- Right drawer from the `Graph` tab
|
||||
- Not a full route unless deep-linking to failed step diagnostics becomes necessary
|
||||
|
||||
### Time-travel controls
|
||||
- Toolbar in the `Timeline` or `Replay` tab
|
||||
- Not its own page
|
||||
|
||||
### Critical path
|
||||
- Toggle or subtab inside `Graph`
|
||||
- Not a separate sidebar item
|
||||
|
||||
### Replay verify
|
||||
- Primary home in `Replay`
|
||||
- Secondary deep link from `Evidence > Verify & Replay`
|
||||
|
||||
### Workflow authoring preview
|
||||
- Add a `Preview DAG` tab or toggle in the workflow editor
|
||||
- Do not mix authoring preview with live runtime telemetry
|
||||
|
||||
## Suggested Route Sketch
|
||||
|
||||
- `/releases/runs/:runId`
|
||||
- `/releases/runs/:runId/summary`
|
||||
- `/releases/runs/:runId/graph`
|
||||
- `/releases/runs/:runId/timeline`
|
||||
- `/releases/runs/:runId/replay`
|
||||
- `/releases/runs/:runId/evidence`
|
||||
- `/evidence/verify-replay?runId=:runId`
|
||||
- `/administration/workflows/:workflowId?view=preview`
|
||||
|
||||
## What Not To Do
|
||||
|
||||
- Do not create a standalone `Workflow Visualization` sidebar item.
|
||||
- Do not separate graph, replay, and run evidence into unrelated shells.
|
||||
- Do not put runtime graph tooling only in workflow authoring; runtime operators need it on run detail first.
|
||||
|
||||
## Detailed UX And Sprint
|
||||
|
||||
- Detailed UX dossier: `../workflow-visualization-replay/README.md`
|
||||
- Implementation sprint: `../../../implplan/SPRINT_20260307_028_FE_workflow_visualization_replay.md`
|
||||
|
||||
## Corroborating Inputs
|
||||
|
||||
- `docs/modules/release-orchestrator/ui/overview.md`
|
||||
- `docs/modules/release-orchestrator/workflow/evidence-based-release-gates.md`
|
||||
- `docs/modules/ui/architecture-rework.md`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/releases.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/evidence.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/workflow-visualization/workflow-visualization.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/workflow-visualization/components/workflow-visualizer/workflow-visualizer.component.ts`
|
||||
|
||||
## Final Call
|
||||
|
||||
This should become a `Release Runs` detail capability with graph, timeline, replay, and step-detail views, plus an evidence-side entry point and a smaller workflow-editor preview.
|
||||
Reference in New Issue
Block a user