docs(ui): map restoration topics and delivery sprints
This commit is contained in:
master
@@ -78,11 +78,25 @@ Completion criteria:
|
||||
- [ ] Ambiguous components are reduced to a smaller explicit investigate set.
|
||||
- [ ] Final keep/merge/wire recommendations can be defended against current product documentation.
|
||||
|
||||
### DOCS-UCM-005 - Restoration priority backlog
|
||||
Status: DONE
|
||||
Dependency: DOCS-UCM-003
|
||||
Owners: Documentation author, Project Manager
|
||||
Task description:
|
||||
- Convert the branch-level preservation map into an ordered restoration backlog.
|
||||
- Distinguish true restoration work from merge work, wire-in work, and likely retirement.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Ordered backlog exists for dropped and weakly surfaced functionality.
|
||||
- [x] Merge candidates are grouped into product-level topics instead of raw branch names only.
|
||||
- [x] The backlog is linked from the preservation-map root index.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created for a multi-iteration preservation map of unused and weakly surfaced UI components. | Project Manager |
|
||||
| 2026-03-07 | Generated first-pass preservation map artifacts under `docs/modules/ui/component-preservation-map/`: root index, summary tree, deterministic inventory, 303 component dossiers, and 89 branch indexes. | Documentation author |
|
||||
| 2026-03-07 | Added `RESTORATION_PRIORITIES.md` to rank dropped-functionality restoration topics by confidence and to distinguish merge candidates from wire-in and retirement work. | Documentation author |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: first iteration will prioritize a complete map and first-pass judgment over exhaustive historical certainty.
|
||||
|
||||
@@ -0,0 +1,147 @@
|
||||
# Sprint 20260307-022 - Policy VEX Release Decisioning Studio
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate Policy Studio, Policy Governance, Policy Simulation, and actionable VEX decisioning into one canonical sub-product shell for the Console.
|
||||
- Ship a fully wired `/ops/policy` experience with working routes, tabs, legacy redirects, release-context deep links, and no orphan mutable policy or VEX shells.
|
||||
- Complete the usable operator workflows for packs, governance, simulation, VEX conflicts, exceptions, release gates, and audit rather than stopping at merge or routing notes.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/routes/`, `docs/modules/ui/policy-decisioning-studio`, `docs/implplan/`, `docs/modules/ui/TASKS.md`, and `docs/modules/ui/implementation_plan.md`.
|
||||
- Expected evidence: code under `src/Web/**`, routable `/ops/policy` shell, working alias redirects, release-context entry points, targeted tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/contracts/policy-studio.md`
|
||||
- `docs/security/policy-governance.md`
|
||||
- `docs/modules/release-orchestrator/ui/overview.md`
|
||||
- `docs/modules/release-orchestrator/workflow/evidence-based-release-gates.md`
|
||||
- `docs/modules/ui/component-preservation-map/README.md`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/ops.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/administration.routes.ts`
|
||||
- Safe parallelism:
|
||||
- shell scaffolding and alias wiring can proceed in parallel with tab-by-tab migration once the canonical route family is fixed
|
||||
- packs/governance and simulation/VEX work can proceed in parallel after shared shell context is in place
|
||||
- release-context entry points and docs sync can proceed in parallel with tab implementation once ownership boundaries are stable
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/policy-decisioning-studio/README.md`
|
||||
- `docs/contracts/policy-studio.md`
|
||||
- `docs/security/policy-governance.md`
|
||||
- `docs/modules/release-orchestrator/ui/overview.md`
|
||||
- `docs/modules/release-orchestrator/workflow/evidence-based-release-gates.md`
|
||||
- `docs/modules/ui/component-preservation-map/SUMMARY_TREE.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-PD-001 - Build the canonical `/ops/policy` shell
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Implement the shell component, primary tabs, shared context header, and nav entry under the canonical `/ops/policy` root.
|
||||
- Make the shell usable in global, pack, and release-context modes from the first shipped route.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] `/ops/policy` renders as the canonical shell with working top-level navigation.
|
||||
- [ ] Primary tabs and shared context header are wired in code.
|
||||
- [ ] Release-context mode can be entered without creating a separate product shell.
|
||||
|
||||
### FE-PD-002 - Migrate routes and legacy aliases into the new tree
|
||||
Status: TODO
|
||||
Dependency: FE-PD-001
|
||||
Owners: FE Architect, Documentation author
|
||||
Task description:
|
||||
- Implement the canonical route tree for packs, governance, simulation, VEX, exceptions, release gates, and audit under `/ops/policy`.
|
||||
- Wire redirects from `/policy-studio/*`, `/admin/policy/*`, and `/admin/vex-hub/*` so old entry points land on usable new pages.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Canonical child routes exist in the active router.
|
||||
- [ ] Legacy aliases redirect into working `/ops/policy` subviews.
|
||||
- [ ] No mutable policy or VEX workflow remains dependent on an orphan route.
|
||||
|
||||
### FE-PD-003 - Ship Packs and Governance functionality
|
||||
Status: TODO
|
||||
Dependency: FE-PD-002
|
||||
Owners: FE Architect, Documentation author
|
||||
Task description:
|
||||
- Migrate the policy pack workspace, editor, YAML, rule builder, approvals, explain flows, and governance controls into the new shell.
|
||||
- Ensure these flows remain usable, not just reachable, after the shell cutover.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Packs and Governance tabs are functional under `/ops/policy`.
|
||||
- [ ] Editing, approvals, governance settings, and explain flows are usable from the new shell.
|
||||
- [ ] Superseded pack and governance shells can be retired or redirected after cutover.
|
||||
|
||||
### FE-PD-004 - Ship Simulation, VEX, Exceptions, Gates, and Audit functionality
|
||||
Status: TODO
|
||||
Dependency: FE-PD-001
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Migrate simulation flows, VEX conflict handling, exceptions, release gates, and audit history into the same shell.
|
||||
- Ensure operators can complete the key workflows from the new tabs without falling back to dead or duplicate screens.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Simulation, VEX, Exceptions, Release Gates, and Audit tabs are functional under `/ops/policy`.
|
||||
- [ ] Conflict resolution, exception handling, and gate review are usable from the new shell.
|
||||
- [ ] Old mutable VEX and policy action pages are no longer required for those workflows.
|
||||
|
||||
### FE-PD-005 - Wire Release Orchestrator into Decisioning Studio
|
||||
Status: TODO
|
||||
Dependency: FE-PD-002
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement deep links from approvals, promotion requests, release detail, workflow editor, and evidence detail into release-context mode.
|
||||
- Keep Release Orchestrator as the owner of release state while Decisioning Studio owns policy and VEX actions.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Release-context entry points are wired from active release surfaces.
|
||||
- [ ] Release-context header shows the required release, environment, artifact, and gate state.
|
||||
- [ ] Operators can return to the release workflow after taking policy or VEX actions.
|
||||
|
||||
### FE-PD-006 - Verify cutover, redirects, and core operator journeys
|
||||
Status: TODO
|
||||
Dependency: FE-PD-005
|
||||
Owners: QA, Test Automation
|
||||
Task description:
|
||||
- Add targeted UI verification for global mode, pack mode, and release-context mode, including old bookmarks and alias redirects.
|
||||
- Validate that the new shell is the working owner for the core operator journeys, not just a shell around dead components.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Playwright scenarios cover all three shell modes.
|
||||
- [ ] Legacy aliases and old bookmarks land on usable new pages.
|
||||
- [ ] Scope-based visibility and the main policy/VEX operator journeys are explicitly verified.
|
||||
|
||||
### FE-PD-007 - Complete docs sync and retire superseded shells
|
||||
Status: TODO
|
||||
Dependency: FE-PD-003
|
||||
Owners: Documentation author, Project Manager
|
||||
Task description:
|
||||
- Update UI, security, and release docs to reflect the new canonical shell and the cutover state.
|
||||
- Record which legacy names remain as temporary aliases and which old product shells are fully retired after the move.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Cross-doc references are updated for the shipped shell.
|
||||
- [ ] User-facing naming and alias lifetimes are documented.
|
||||
- [ ] Retired sibling-product labels and routes are explicitly listed after cutover.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship a single Decisioning Studio shell spanning policy authoring, governance, simulation, actionable VEX resolution, and release-context gate explanation. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: the preferred product shape is one dynamic shell with deep-linkable tabs, not one giant page and not separate sibling products.
|
||||
- Decision: Release Orchestrator remains the owner of promotion state; the new shell owns policy, VEX, exception, and gate explanation workflows.
|
||||
- Decision: `/ops/policy` is the preferred canonical root because it already exists in the active route tree and best fits the "policy as an ops control plane" model.
|
||||
- Risk: moving all VEX screens under Policy could bury read-only security exploration use cases that still belong in Analyze.
|
||||
- Mitigation: allow Analyze entry points to deep-link into the same canonical VEX tab or a read-only shell mode instead of preserving a separate mutable VEX product.
|
||||
- Risk: legacy aliases across `/policy-studio/*`, `/administration/policy/*`, and `/admin/vex-hub/*` can silently fragment analytics and QA coverage.
|
||||
- Mitigation: freeze redirects and verification scenarios before implementation starts.
|
||||
- Risk: Release Orchestrator could grow duplicate gate/policy UI while this consolidation is in flight.
|
||||
- Mitigation: require release-facing FE work to deep-link into the shared shell rather than add new standalone policy/VEX pages.
|
||||
- Delivery rule: this sprint is only complete when the canonical shell is routable, usable, verified, and old mutable policy or VEX action paths are no longer required.
|
||||
- Reference design note: `docs/modules/ui/policy-decisioning-studio/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm the canonical shell name, tab set, and ownership boundary.
|
||||
- 2026-03-09: freeze the route contract and component merge matrix.
|
||||
- 2026-03-10: finalize release-context UX contract and implementation slice plan.
|
||||
@@ -0,0 +1,137 @@
|
||||
# Sprint 20260307-023 - UI Restoration Topic Shapes
|
||||
|
||||
## Topic & Scope
|
||||
- Convert the highest-confidence restoration topics after Decisioning Studio into concrete product-shape notes.
|
||||
- For each topic, define whether it should be a submenu, tabbed shell, contextual drawer, or reusable detail page.
|
||||
- Explicitly place stray pages and single actions into the active Stella Ops IA instead of reviving orphan products.
|
||||
- This is a documentation prerequisite sprint only; it does not count as shipping the restored functionality by itself.
|
||||
- Working directory: `docs/modules/ui/restoration-topics`.
|
||||
- Allowed coordination edits: `docs/implplan/`, `docs/modules/ui/TASKS.md`, `docs/modules/ui/implementation_plan.md`, and `docs/modules/ui/component-preservation-map/README.md`.
|
||||
- Expected evidence: restoration topic index, five topic notes, placement rules, and cross-links from the preservation map.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
- `docs/modules/ui/component-preservation-map/SUMMARY_TREE.md`
|
||||
- `docs/modules/ui/policy-decisioning-studio/README.md`
|
||||
- active route trees under `src/Web/StellaOps.Web/src/app/routes/`
|
||||
- Safe parallelism:
|
||||
- each restoration-topic note can be authored independently after the shared placement rules are clear
|
||||
- future implementation sprints can be split per topic once these shapes are accepted
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
- `docs/modules/ui/component-preservation-map/README.md`
|
||||
- `docs/modules/ui/policy-decisioning-studio/README.md`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/mission-control.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/security-risk.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/operations.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/releases.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/evidence.routes.ts`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### DOCS-RTS-001 - Restoration topic index and placement rules
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Documentation author, Project Manager
|
||||
Task description:
|
||||
- Create the restoration-topics doc tree with an index and shared placement rules for stray pages, actions, drawers, and submenus.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Topic index exists.
|
||||
- [x] Placement matrix exists.
|
||||
- [x] Shared placement rules are documented.
|
||||
|
||||
### DOCS-RTS-002 - Watchlist placement note
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-001
|
||||
Owners: Documentation author, Product Manager
|
||||
Task description:
|
||||
- Define whether Watchlist belongs in Mission Control, Ops, or Setup, and specify how configuration versus alerts should be surfaced.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Primary owner area is defined.
|
||||
- [x] Tabs and route sketch are defined.
|
||||
- [x] Secondary placements for alerts and notifications are documented.
|
||||
|
||||
### DOCS-RTS-003 - Reachability witnessing placement note
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-001
|
||||
Owners: Documentation author, Product Manager
|
||||
Task description:
|
||||
- Define how witness and PoE surfaces merge into Reachability, Security, and release/evidence flows.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Primary security placement is defined.
|
||||
- [x] Witness vs PoE page/drawer ownership is documented.
|
||||
- [x] Secondary deep-link entry points are listed.
|
||||
|
||||
### DOCS-RTS-004 - Platform Ops consolidation note
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-001
|
||||
Owners: Documentation author, FE Architect
|
||||
Task description:
|
||||
- Define how legacy Platform Ops pages fold into the active Ops shell and where stray tools like agent fleet should live.
|
||||
|
||||
Completion criteria:
|
||||
- [x] One-shell decision is documented.
|
||||
- [x] Grouped submenu structure is documented.
|
||||
- [x] Duplication boundaries with Setup are documented.
|
||||
|
||||
### DOCS-RTS-005 - Triage explainability placement note
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-001
|
||||
Owners: Documentation author, Product Manager
|
||||
Task description:
|
||||
- Define how quiet lane, AI recommendations, reason capsules, provenance, and audit bundles fit into the active triage flow.
|
||||
|
||||
Completion criteria:
|
||||
- [x] List-level lane placement is defined.
|
||||
- [x] Detail-level explainability placement is defined.
|
||||
- [x] Audit bundles page ownership is defined.
|
||||
|
||||
### DOCS-RTS-006 - Workflow visualization and replay placement note
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-001
|
||||
Owners: Documentation author, FE Architect
|
||||
Task description:
|
||||
- Define where runtime workflow graphing, time travel, replay, and step-detail views live in Releases, Evidence, and workflow authoring.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Primary home in release runs is documented.
|
||||
- [x] Evidence-side and workflow-editor secondary placements are documented.
|
||||
- [x] Graph/timeline/replay tab structure is defined.
|
||||
|
||||
### DOCS-RTS-007 - Deeper corroboration against module dossiers
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-002
|
||||
Owners: Documentation author, Product Manager
|
||||
Task description:
|
||||
- Validate each topic shape against the owning module dossiers and convert accepted shapes into implementation sprints.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Watchlist, reachability, ops, triage, and workflow-visualization topic notes each have corroborating module-doc links.
|
||||
- [x] Accepted topic shapes are translated into implementation-ready frontend or product sprints.
|
||||
- [x] Rejected or downgraded topics are reflected back into the restoration backlog.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to shape the next restoration topics after Decisioning Studio into concrete shell/menu/tab recommendations. | Project Manager |
|
||||
| 2026-03-07 | Authored topic-shape notes for Watchlist, Reachability Witnessing, Platform Ops Consolidation, Triage Explainability Workbench, and Workflow Visualization And Replay. | Documentation author |
|
||||
| 2026-03-07 | Added corroborating module-doc links to each restoration topic note and cut implementation-ready FE sprints plus detailed UX dossiers for the accepted topics. | Documentation author |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: these topics should be expressed as restorations of capability into existing shells, not revivals of abandoned product brands.
|
||||
- Decision: single actions and narrow supporting UX should default to tabs, drawers, right-rail panels, or submenus instead of new top-level products.
|
||||
- Decision: completion of this docs sprint is not sufficient for product delivery; the FE sprints must still ship and verify the mounted functionality.
|
||||
- Risk: some topics, especially Watchlist and Workflow Visualization, touch more than one owning domain.
|
||||
- Mitigation: document primary ownership plus secondary entry points explicitly so implementation does not fork the capability.
|
||||
- Risk: legacy route shapes may bias the placement toward old IA instead of current Stella Ops structure.
|
||||
- Mitigation: place each topic against the active route tree first and treat legacy routes as migration aliases only.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm whether the proposed placement of Watchlist under Trust & Signing is accepted.
|
||||
- 2026-03-09: decide whether Reachability Witnessing and Workflow Visualization move directly to FE implementation planning.
|
||||
- 2026-03-10: cut implementation sprints for the accepted Tier 1 and Tier 2 restoration topics.
|
||||
128
docs/implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md
Normal file
128
docs/implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md
Normal file
@@ -0,0 +1,128 @@
|
||||
# Sprint 20260307-024 - Identity Watchlist Shell
|
||||
|
||||
## Topic & Scope
|
||||
- Restore the dropped identity watchlist capability as a trust-owned operational shell under `Setup > Trust & Signing`.
|
||||
- Ship a fully usable watchlist with working entries, alerts, tuning, and deep-link behavior rather than leaving it as an unmounted page.
|
||||
- Complete route wiring, menu exposure, cross-shell alert surfacing, and operator workflows end to end.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features/watchlist`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/routes/`, `src/Web/StellaOps.Web/src/app/features/mission-control/`, `src/Web/StellaOps.Web/src/app/features/notify/`, `docs/modules/ui/watchlist-operations`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: routed and menu-visible watchlist shell, working CRUD and alert flows, cross-shell deep links, targeted tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/watchlist-operations/README.md`
|
||||
- `docs/modules/attestor/guides/identity-watchlist.md`
|
||||
- `docs/operations/watchlist-monitoring-runbook.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`
|
||||
- Safe parallelism:
|
||||
- route and ownership decisions should freeze before implementation starts
|
||||
- `Entries`, `Alerts`, and `Tuning` can be implemented in parallel after the shell and query-param contract are stable
|
||||
- Mission Control and Notifications deep links can proceed in parallel with shell implementation
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/watchlist-operations/README.md`
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/watchlist.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-WL-001 - Wire the canonical watchlist shell into Setup
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Add the canonical route family and menu entry under `Setup > Trust & Signing`.
|
||||
- Make the shell routable and usable with working tab navigation and scope-aware header behavior.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Watchlist is reachable from the active shell navigation.
|
||||
- [ ] Canonical routes and tab behavior are wired in code.
|
||||
- [ ] Scope-aware header behavior works from the mounted shell.
|
||||
|
||||
### FE-WL-002 - Ship the Entries workflow
|
||||
Status: TODO
|
||||
Dependency: FE-WL-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the `Entries` tab as a working list/detail experience using the existing watchlist client.
|
||||
- Ensure operators can create, edit, duplicate, enable/disable, delete, and test matching rules from the mounted shell.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Entry CRUD flows work from the mounted shell.
|
||||
- [ ] Edit/create uses a contextual panel or drawer instead of a detached page.
|
||||
- [ ] Pattern test is wired and usable within the entry-editing flow.
|
||||
|
||||
### FE-WL-003 - Ship the Alerts workflow
|
||||
Status: TODO
|
||||
Dependency: FE-WL-001
|
||||
Owners: Developer, Product Manager
|
||||
Task description:
|
||||
- Implement the `Alerts` tab with filters, ordering, alert-detail drawer behavior, and jump-to-entry actions.
|
||||
- Make alert-detail deep links work from Mission Control and back into the owning watchlist rule.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Alert listing and filtering work in the mounted shell.
|
||||
- [ ] Alert-detail drawer shows the required context and actions.
|
||||
- [ ] Operators can jump between alert detail and the owning watchlist entry.
|
||||
|
||||
### FE-WL-004 - Ship tuning and diagnostics
|
||||
Status: TODO
|
||||
Dependency: FE-WL-001
|
||||
Owners: Developer, Documentation author
|
||||
Task description:
|
||||
- Implement the `Tuning` tab with dedup controls, notification behavior, top noisy rules, and performance/volume KPIs.
|
||||
- Align the shipped tab with the operational runbook so the page is usable for real operator tuning.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Dedup and channel controls are wired into the page.
|
||||
- [ ] Operational KPI cards render in the mounted shell.
|
||||
- [ ] Tuning guidance matches the operational runbook terminology.
|
||||
|
||||
### FE-WL-005 - Wire Mission Control and Notifications entry points
|
||||
Status: TODO
|
||||
Dependency: FE-WL-003
|
||||
Owners: FE Architect, Developer
|
||||
Task description:
|
||||
- Wire watchlist-origin alert chips, links, and `returnTo` behavior from `Mission Control > Alerts` and `Ops > Notifications`.
|
||||
- Ensure those surfaces expose outcomes only and send operators into the canonical watchlist shell for action.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Mission Control links open the working watchlist alerts flow.
|
||||
- [ ] Notifications links open tuning or alert views in the canonical shell.
|
||||
- [ ] `returnTo` behavior preserves operator context across shells.
|
||||
|
||||
### FE-WL-006 - Verify, document, and cut over the feature
|
||||
Status: TODO
|
||||
Dependency: FE-WL-002
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add targeted UI verification for tenant/global/system scope, entries CRUD, alerts drill-in, tuning, and Mission Control deep links.
|
||||
- Update docs and cutover notes so Watchlist is treated as a shipped feature, not an orphan page.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Playwright scenarios cover entries, alerts, and tuning.
|
||||
- [ ] Scope-sensitive behaviors are explicitly verified.
|
||||
- [ ] Docs and rollout notes reflect the mounted and usable feature.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship Watchlist as a Trust & Signing-owned shell with working entries, alerts, tuning, and secondary surfacing in Mission Control and Notifications. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: Watchlist belongs under `Setup > Trust & Signing`, with alert visibility surfaced elsewhere.
|
||||
- Decision: configuration and alert history remain in one shell; they should not be split into separate products.
|
||||
- Risk: Mission Control may try to absorb watchlist because it already owns alerts.
|
||||
- Mitigation: freeze the ownership boundary and only allow alert-source chips and deep links from Mission Control.
|
||||
- Risk: scope handling across tenant, global, and system rules can create hidden permissions complexity.
|
||||
- Mitigation: require scope-aware header behavior and QA coverage before rollout.
|
||||
- Delivery rule: this sprint is only complete when Watchlist is visible in navigation, usable end to end, and its key alert and tuning workflows are verified.
|
||||
- Reference design note: `docs/modules/ui/watchlist-operations/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm owner shell, tab set, and deep-link behavior.
|
||||
- 2026-03-09: freeze entries, alerts, and tuning implementation slices.
|
||||
- 2026-03-10: finalize QA and rollout contract.
|
||||
@@ -0,0 +1,130 @@
|
||||
# Sprint 20260307-025 - Reachability Witnessing Merge
|
||||
|
||||
## Topic & Scope
|
||||
- Restore witness and proof-of-exposure UX as a deeper part of `Security > Reachability`.
|
||||
- Ship fully usable witness and proof flows with working routes, drawers, exports, and cross-links from findings, triage, evidence, and release contexts.
|
||||
- Complete the missing functionality so operators can actually inspect, verify, and navigate reachability proof rather than just reach routed placeholders.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features/reachability`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/routes/`, `src/Web/StellaOps.Web/src/app/features/security-risk/`, `src/Web/StellaOps.Web/src/app/features/triage/`, `docs/modules/ui/reachability-witnessing`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: mounted reachability tabs, working witness detail pages, working PoE drawer/permalink behavior, cross-shell deep links, targeted tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/reachability-witnessing/README.md`
|
||||
- `docs/contracts/witness-v1.md`
|
||||
- `docs/architecture/EVIDENCE_PIPELINE_ARCHITECTURE.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`
|
||||
- Safe parallelism:
|
||||
- tab and route contract work should finish before FE implementation begins
|
||||
- witness list/detail and PoE drawer work can proceed in parallel once the route contract is stable
|
||||
- cross-product deep-link work can proceed in parallel with shell implementation
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/reachability-witnessing/README.md`
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/reachability-witnessing.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-RW-001 - Wire reachability witness routes and tabs into the active shell
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Add the `Coverage`, `Witnesses`, `PoE / Exposure`, and `Sensor Gaps` flows to the active reachability shell.
|
||||
- Make the canonical routes and panel behavior work in the live router.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Reachability remains the canonical owner shell in the live router.
|
||||
- [ ] Witness and PoE routes are wired and reachable.
|
||||
- [ ] Tab and panel state work in code, not only in docs.
|
||||
|
||||
### FE-RW-002 - Ship the Witnesses list and witness-detail page
|
||||
Status: TODO
|
||||
Dependency: FE-RW-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the searchable `Witnesses` tab and the full witness detail page using the existing reachability and witness APIs.
|
||||
- Ensure the detail page includes path, confidence, related evidence, and export or verify actions.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Witness listing and filters are usable from the mounted shell.
|
||||
- [ ] Witness detail renders the required investigation sections.
|
||||
- [ ] Export and verify actions work from witness detail.
|
||||
|
||||
### FE-RW-003 - Ship PoE detail as drawer-first UX with permalink support
|
||||
Status: TODO
|
||||
Dependency: FE-RW-001
|
||||
Owners: Developer, Product Manager
|
||||
Task description:
|
||||
- Implement proof-of-exposure detail as a contextual drawer by default, with a permalink route for export and audit use cases.
|
||||
- Make PoE open from witness detail and other owning workflows without creating a second proof product.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] PoE drawer is usable from witness detail and other entry points.
|
||||
- [ ] Permalink route works for direct proof access.
|
||||
- [ ] Operators can inspect proof without leaving the owning workflow unless they choose to.
|
||||
|
||||
### FE-RW-004 - Wire findings, triage, evidence, and release deep links
|
||||
Status: TODO
|
||||
Dependency: FE-RW-002
|
||||
Owners: FE Architect, Developer
|
||||
Task description:
|
||||
- Implement deep links from `Security > Findings`, `Triage > Artifact Workspace`, `Evidence > Verify & Replay`, and release-context decisioning flows.
|
||||
- Preserve `returnTo` navigation so witness and PoE inspection does not strand the operator away from the original workflow.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Findings, triage, evidence, and release entry points open the working reachability UX.
|
||||
- [ ] `returnTo` behavior preserves the original workflow context.
|
||||
- [ ] No duplicate witness pages are required outside the reachability shell.
|
||||
|
||||
### FE-RW-005 - Complete exports, evidence cards, and proof actions
|
||||
Status: TODO
|
||||
Dependency: FE-RW-003
|
||||
Owners: Developer, Documentation author
|
||||
Task description:
|
||||
- Implement DOT, Mermaid, replay verify, and evidence-chain actions in witness and PoE detail.
|
||||
- Align labels and affordances so exported proof remains understandable across security, evidence, and release workflows.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Export and verify actions are usable in the shipped UI.
|
||||
- [ ] Evidence-chain and proof summary cards render in the shipped UI.
|
||||
- [ ] Terminology is aligned across the related docs and pages.
|
||||
|
||||
### FE-RW-006 - Verify, document, and cut over the feature
|
||||
Status: TODO
|
||||
Dependency: FE-RW-004
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add Playwright scenarios for the reachability shell, witness detail, PoE drawer, export actions, and cross-shell deep links.
|
||||
- Update reachability and evidence docs so this ships as a usable feature, not a documented merge target only.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] UI verification covers shell tabs, witness detail, and PoE detail.
|
||||
- [ ] Cross-shell deep links and proof actions are included in verification.
|
||||
- [ ] Docs reflect the mounted and usable feature.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship witness and proof-of-exposure UX as deeper reachability functionality with reusable witness detail pages and PoE drawers across security, triage, evidence, and release flows. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: `Security > Reachability` remains the owner shell for witness and proof UX.
|
||||
- Decision: witness detail is a full page; PoE is a drawer first and a permalink route second.
|
||||
- Risk: evidence and release teams may create parallel proof views during implementation.
|
||||
- Mitigation: freeze deep-link and return-to-context rules before FE work begins.
|
||||
- Risk: proof terminology may drift between reachability, evidence, and decisioning docs.
|
||||
- Mitigation: align labels and actions to the reachability UX dossier before implementation starts.
|
||||
- Delivery rule: this sprint is only complete when witness and PoE flows are mounted, usable from their primary and secondary entry points, and verified end to end.
|
||||
- Reference design note: `docs/modules/ui/reachability-witnessing/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm shell tabs and witness versus PoE ownership boundaries.
|
||||
- 2026-03-09: freeze witness detail, PoE drawer, and deep-link contracts.
|
||||
- 2026-03-10: finalize QA and rollout contract.
|
||||
@@ -0,0 +1,128 @@
|
||||
# Sprint 20260307-026 - Platform Ops Consolidation
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate legacy `platform-ops` ideas into one canonical `Ops > Operations` shell.
|
||||
- Ship a fully usable consolidated Operations shell with a working overview, child routes, legacy redirects, and absorbed high-value widgets from the old surfaces.
|
||||
- Complete the missing operator functionality in the active shell instead of merely cataloging or grouping old pages.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features/platform`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/features/platform-ops/`, `src/Web/StellaOps.Web/src/app/routes/operations.routes.ts`, `src/Web/StellaOps.Web/src/app/features/aoc-compliance/`, `docs/modules/ui/platform-ops-consolidation`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: active Operations overview and child routes, absorbed legacy widgets, working redirects, targeted tests, and updated operator docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/platform-ops-consolidation/README.md`
|
||||
- `docs/UI_GUIDE.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`
|
||||
- `src/Web/StellaOps.Web/src/app/features/aoc-compliance/aoc-compliance.routes.ts`
|
||||
- Safe parallelism:
|
||||
- overview taxonomy and child-route labeling should freeze before widget implementation begins
|
||||
- grouped overview cards and route cleanup can proceed in parallel once taxonomy is stable
|
||||
- Setup boundary work can proceed in parallel with legacy widget absorption
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/platform-ops-consolidation/README.md`
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/platform-ops-consolidation.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-PO-001 - Rebuild the Operations overview and submenu in the live shell
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Implement the grouped overview taxonomy and submenu structure in the active `Ops > Operations` shell.
|
||||
- Ensure the overview and submenu expose the real operator concerns rather than leaving them as a paper design.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] The live shell exposes the intended overview groups and submenu entries.
|
||||
- [ ] Overview group labels and child-route labels are wired in code.
|
||||
- [ ] No parallel `platform-ops` owner tree is required for operator access.
|
||||
|
||||
### FE-PO-002 - Ship the overview page and grouped blocking cards
|
||||
Status: TODO
|
||||
Dependency: FE-PO-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the overview page with blocking strip, grouped cards, trend summaries, and single-target drill-ins.
|
||||
- Make the overview page usable as the real operator landing page rather than a placeholder around child routes.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Blocking strip renders the required signals in the live shell.
|
||||
- [ ] Grouped cards route into working child pages.
|
||||
- [ ] Overview sections follow one consistent shipped pattern.
|
||||
|
||||
### FE-PO-003 - Absorb high-value legacy widgets and pages
|
||||
Status: TODO
|
||||
Dependency: FE-PO-001
|
||||
Owners: Developer, Documentation author
|
||||
Task description:
|
||||
- Migrate the high-value legacy `platform-ops` widgets and pages into the overview or the correct child routes.
|
||||
- Retire only the obsolete duplicates after the missing operational functionality is actually present in the live shell.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] High-value legacy widgets are visible in the active shell or child routes.
|
||||
- [ ] Missing operational views are actually shipped into target pages.
|
||||
- [ ] Only genuinely duplicated legacy routes remain candidates for retirement.
|
||||
|
||||
### FE-PO-004 - Cut over routes and legacy aliases
|
||||
Status: TODO
|
||||
Dependency: FE-PO-001
|
||||
Owners: FE Architect, Developer
|
||||
Task description:
|
||||
- Implement canonical `/ops/operations/*` paths, legacy alias redirects, and route-label consistency.
|
||||
- Ensure old bookmarks and legacy route trees redirect into working pages without reviving a second shell.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Canonical route family is active in the router.
|
||||
- [ ] Legacy aliases redirect into working operations pages.
|
||||
- [ ] Sidebar, overview cards, and breadcrumb labels match in the shipped shell.
|
||||
|
||||
### FE-PO-005 - Complete Setup boundary and topology deep links
|
||||
Status: TODO
|
||||
Dependency: FE-PO-002
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Implement the boundary between operations monitoring and setup ownership, especially for agent fleet and topology concerns.
|
||||
- Wire deep links between `Ops > Operations` and `Setup > Topology` where operators need to cross that boundary.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Agent fleet and topology ownership remain under Setup in the live UI.
|
||||
- [ ] Operations-to-Setup deep links work from shipped pages.
|
||||
- [ ] No duplicated topology management remains exposed under Ops.
|
||||
|
||||
### FE-PO-006 - Verify, document, and cut over the consolidated shell
|
||||
Status: TODO
|
||||
Dependency: FE-PO-004
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add Playwright scenarios for the operations overview, grouped cards, child-route drill-ins, and legacy alias redirects.
|
||||
- Update UI docs and operational runbooks so the consolidated shell ships as the usable owner surface.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Verification covers overview groups and target routes.
|
||||
- [ ] Legacy alias redirects are included in testing.
|
||||
- [ ] Docs reflect the consolidated and shipped owner shell.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship a consolidated Operations shell with grouped overview cards, stable child routes, legacy-widget absorption, and explicit Setup boundaries. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: `Ops > Operations` remains the one operator shell; legacy `platform-ops` becomes migration input only.
|
||||
- Decision: overview cards should be grouped by operator concern, not by backend service naming alone.
|
||||
- Risk: useful legacy widgets may be dropped if the merge matrix is shallow.
|
||||
- Mitigation: require a legacy widget absorption matrix before implementation begins.
|
||||
- Risk: topology and agent-fleet concerns may leak back into Ops ownership.
|
||||
- Mitigation: freeze Setup boundaries and cross-links explicitly.
|
||||
- Delivery rule: this sprint is only complete when the consolidated Operations shell is the usable owner surface and legacy pages are no longer needed for the restored operator workflows.
|
||||
- Reference design note: `docs/modules/ui/platform-ops-consolidation/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm one-shell decision, overview groups, and Setup boundary.
|
||||
- 2026-03-09: freeze overview card contract and legacy merge matrix.
|
||||
- 2026-03-10: finalize route cleanup and QA contract.
|
||||
@@ -0,0 +1,129 @@
|
||||
# Sprint 20260307-027 - Triage Explainability Workspace
|
||||
|
||||
## Topic & Scope
|
||||
- Merge the dropped triage workbench ideas into one canonical artifact workspace plus a sibling `Audit Bundles` page.
|
||||
- Ship a fully usable artifact workspace with lane segmentation, detail-side explainability panels, and a working `Audit Bundles` page.
|
||||
- Complete the missing triage functionality end to end so the operator can actually use quiet lane, explanation panels, and audit packaging from the active shell.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features/triage`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/routes/security-risk.routes.ts`, `src/Web/StellaOps.Web/src/app/features/security-risk/`, `src/Web/StellaOps.Web/src/app/features/evidence/`, `docs/modules/ui/triage-explainability-workspace`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: working lane tabs, working detail-side explainability panels, working audit-bundle flows, migrated supporting components, tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/triage-explainability-workspace/README.md`
|
||||
- `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/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`
|
||||
- Safe parallelism:
|
||||
- route, lane, and panel contracts should freeze before FE implementation begins
|
||||
- list-lane work and detail-panel work can proceed in parallel after the contract is stable
|
||||
- audit-bundle page work can proceed in parallel with supporting component absorption
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/triage-explainability-workspace/README.md`
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/triage-explainability-workbench.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-TX-001 - Wire the canonical artifact workspace and route state
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Implement the canonical artifact workspace route family, lane query params, panel query params, and sibling `Audit Bundles` page ownership.
|
||||
- Ensure the active shell exposes the triage workspace operators should actually use.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Canonical artifact and audit-bundle routes are active in the router.
|
||||
- [ ] Lane and panel query params work in the shipped UI.
|
||||
- [ ] Separate workbench brands are no longer required for triage access.
|
||||
|
||||
### FE-TX-002 - Ship the list-lane workflows
|
||||
Status: TODO
|
||||
Dependency: FE-TX-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the list-layer experience for `Active`, `Quiet Lane`, and `Needs Review`.
|
||||
- Ensure row actions, bulk actions, and lane transitions are usable from the active artifact list.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Lane tabs or segmented controls are working in the shipped UI.
|
||||
- [ ] Row and bulk actions work from the artifact list.
|
||||
- [ ] Quiet-lane behavior is usable as queue state, not a detached page.
|
||||
|
||||
### FE-TX-003 - Ship the detail-side explainability workspace
|
||||
Status: TODO
|
||||
Dependency: FE-TX-001
|
||||
Owners: Developer, Product Manager
|
||||
Task description:
|
||||
- Implement artifact detail panels for AI recommendations, reason capsule, provenance, and decision history.
|
||||
- Make them usable beside the central artifact summary and evidence trail instead of leaving them as unmounted workbench ideas.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Detail-side panels render and open via the active workspace route state.
|
||||
- [ ] Panel actions and return-to-context behavior work in the shipped UI.
|
||||
- [ ] AI remains advisory and evidence-first in the shipped detail experience.
|
||||
|
||||
### FE-TX-004 - Ship the Audit Bundles page and create flow
|
||||
Status: TODO
|
||||
Dependency: FE-TX-001
|
||||
Owners: Developer, Documentation author
|
||||
Task description:
|
||||
- Implement the `Audit Bundles` list, create flow, and download/verify behavior as a real sibling page.
|
||||
- Ensure operators can build and retrieve audit bundles from the active triage and evidence flows.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Bundle list and create flow are usable in the shipped UI.
|
||||
- [ ] Cross-links from artifact detail and evidence open the working page.
|
||||
- [ ] Audit bundles remain a visible sibling page, not a hidden modal flow.
|
||||
|
||||
### FE-TX-005 - Migrate supporting components and retire workbench wrappers
|
||||
Status: TODO
|
||||
Dependency: FE-TX-003
|
||||
Owners: Developer, Documentation author
|
||||
Task description:
|
||||
- Migrate dropped triage components such as quiet lane workbench, AI recommendation workbench, reason capsule, snapshot viewer, unknowns list, and AI badge into the target workspace.
|
||||
- Retire wrapper shells only after their preserved behavior is working in the active artifact workspace.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Supporting components are visible in the working list or detail surfaces.
|
||||
- [ ] Wrapper shells slated for retirement are no longer needed for preserved behavior.
|
||||
- [ ] No preserved triage functionality depends on an orphan workbench route.
|
||||
|
||||
### FE-TX-006 - Verify, document, and cut over the workspace
|
||||
Status: TODO
|
||||
Dependency: FE-TX-004
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add Playwright scenarios for list-lane navigation, detail panels, cross-links to reachability and evidence, and audit-bundle creation.
|
||||
- Update triage and UI docs so the artifact workspace ships as the usable owner of these workflows.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Verification covers lane changes, detail panels, and audit bundles.
|
||||
- [ ] Cross-shell deep links are included in testing.
|
||||
- [ ] Docs reflect the shipped artifact workspace and audit-bundle flows.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship one artifact workspace with lane segmentation, detail-side explainability, and a sibling Audit Bundles page instead of keeping those capabilities in dropped workbench shells. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: triage stays one workspace with contextual explainability, not multiple workbench brands.
|
||||
- Decision: audit bundles remain a real page because they carry lifecycle, export, and audit semantics.
|
||||
- Risk: AI recommendation UI may expand beyond advisory use and obscure evidence-first operator decisions.
|
||||
- Mitigation: require explicit advisory-only copy and evidence panels in the detail contract.
|
||||
- Risk: quiet-lane behavior may get over-specialized into another shell.
|
||||
- Mitigation: freeze it as list segmentation plus row or bulk actions only.
|
||||
- Delivery rule: this sprint is only complete when the active triage workspace provides the preserved explainability and audit workflows without depending on orphan workbench pages.
|
||||
- Reference design note: `docs/modules/ui/triage-explainability-workspace/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm lane model, detail-side panel set, and Audit Bundles ownership.
|
||||
- 2026-03-09: freeze supporting component merge matrix and route/query contract.
|
||||
- 2026-03-10: finalize QA and rollout contract.
|
||||
@@ -0,0 +1,129 @@
|
||||
# Sprint 20260307-028 - Workflow Visualization Replay
|
||||
|
||||
## Topic & Scope
|
||||
- Restore workflow graphing, timeline, critical-path, and replay UX as a run-detail capability under `Releases > Runs`, with a secondary entry point from `Evidence > Verify & Replay`.
|
||||
- Ship fully usable runtime graphing, timeline, critical-path, replay, and evidence views from the active run-detail experience.
|
||||
- Complete the missing functionality end to end so operators can inspect run structure, drill into steps, replay evidence, and use legacy links without falling back to dead routes.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features/workflow-visualization`.
|
||||
- Allowed coordination edits: `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/release-orchestrator/`, `docs/modules/ui/workflow-visualization-replay`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: working run-detail tabs, working step drawer and replay flows, evidence-side entry points, working legacy redirects, tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/workflow-visualization-replay/README.md`
|
||||
- `docs/modules/release-orchestrator/ui/overview.md`
|
||||
- `docs/modules/release-orchestrator/workflow/evidence-based-release-gates.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`
|
||||
- Safe parallelism:
|
||||
- tab and route contract work should freeze before FE implementation begins
|
||||
- graph/timeline and replay/evidence work can proceed in parallel after the contract is stable
|
||||
- workflow-editor preview work can proceed in parallel with runtime integration once reuse boundaries are frozen
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/workflow-visualization-replay/README.md`
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/workflow-visualization-and-replay.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-WV-001 - Wire run-detail tabs into Releases and Evidence
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Implement the run-detail tab family under `Releases > Runs` and the shared replay entry point from `Evidence > Verify & Replay`.
|
||||
- Ensure operators can reach the graph and replay experience from the active shells.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Canonical run-detail tabs are active in the router.
|
||||
- [ ] Runtime graph and replay routes are mounted and reachable.
|
||||
- [ ] Evidence-side entry points open the working runtime context.
|
||||
|
||||
### FE-WV-002 - Ship the Graph, Timeline, and Critical Path tabs
|
||||
Status: TODO
|
||||
Dependency: FE-WV-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the runtime graph, timeline, and critical-path experiences with filters, node status, and drill-in behavior.
|
||||
- Ensure these tabs are usable for real run diagnosis, not just visual placeholders.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Graph, timeline, and critical-path tabs render with working filters and node metadata.
|
||||
- [ ] Operators can diagnose run state from the shipped tabs.
|
||||
- [ ] Step selection opens the working detail drawer.
|
||||
|
||||
### FE-WV-003 - Ship Replay and Evidence integration
|
||||
Status: TODO
|
||||
Dependency: FE-WV-001
|
||||
Owners: Developer, Product Manager
|
||||
Task description:
|
||||
- Implement the `Replay` tab with replay status, input hashes, drift comparison, and evidence links.
|
||||
- Integrate the existing evidence replay controls and proof replay surfaces into the active run-detail shell.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Replay tab works from the active run-detail shell.
|
||||
- [ ] Existing evidence replay controls are usable from the new tab model.
|
||||
- [ ] Evidence and Replay tabs both expose their intended workflows in the shipped UI.
|
||||
|
||||
### FE-WV-004 - Ship step-detail drill-in and deep-link behavior
|
||||
Status: TODO
|
||||
Dependency: FE-WV-002
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the step-detail drawer, its fields, actions, and `step=<id>` deep-link behavior.
|
||||
- Ensure failed-step drill-ins work from graph and timeline views without losing run context.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Step-detail drawer works from graph and timeline tabs.
|
||||
- [ ] `step=<id>` deep-link behavior is usable and shareable.
|
||||
- [ ] Any required full-route escalation is implemented only where necessary.
|
||||
|
||||
### FE-WV-005 - Implement bounded workflow-editor preview reuse
|
||||
Status: TODO
|
||||
Dependency: FE-WV-001
|
||||
Owners: FE Architect, Developer
|
||||
Task description:
|
||||
- Implement the graph-only preview mode workflow editor can reuse without importing runtime replay semantics.
|
||||
- Keep authoring preview clearly separate from live run telemetry and troubleshooting.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Workflow editor can render the bounded preview mode.
|
||||
- [ ] Runtime-only behaviors are excluded from preview.
|
||||
- [ ] Shared and runtime-only graph components are separated in the shipped implementation.
|
||||
|
||||
### FE-WV-006 - Verify, redirect, and document the shipped capability
|
||||
Status: TODO
|
||||
Dependency: FE-WV-003
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add Playwright scenarios for run-detail tabs, step drawer behavior, evidence entry points, and legacy alias redirects.
|
||||
- Update release and evidence docs so workflow visualization and replay ship as a usable capability, not just a merge target.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Verification covers graph, timeline, replay, and evidence tabs.
|
||||
- [ ] Step deep links and alias redirects are included in testing.
|
||||
- [ ] Docs reflect the shipped run-detail and replay capability.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship workflow graphing and replay as a run-detail capability under Releases, with evidence-side entry points and a bounded authoring preview reuse model. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: runtime workflow visualization is owned by `Releases > Runs`, not by a standalone product.
|
||||
- Decision: `Evidence > Verify & Replay` becomes a secondary entry point into the same replay model.
|
||||
- Risk: runtime and authoring semantics may get mixed in one component tree and confuse operators.
|
||||
- Mitigation: freeze a strict preview versus runtime boundary before implementation begins.
|
||||
- Risk: replay controls already living in evidence routes may diverge from the run-detail experience.
|
||||
- Mitigation: require one shared route and tab model for replay semantics.
|
||||
- Delivery rule: this sprint is only complete when release operators can use the mounted graph, timeline, replay, and evidence flows without depending on the dead workflow-visualization branch.
|
||||
- Reference design note: `docs/modules/ui/workflow-visualization-replay/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm runtime ownership, tab model, and evidence entry-point rules.
|
||||
- 2026-03-09: freeze graph/timeline/replay slices and step-drawer contract.
|
||||
- 2026-03-10: finalize authoring preview boundary, alias migration, and QA contract.
|
||||
@@ -0,0 +1,129 @@
|
||||
# Sprint 20260307-029 - Contextual Actions And Stray Surfaces
|
||||
|
||||
## Topic & Scope
|
||||
- Define and implement the shared FE interaction contract for functionality that should become a submenu, tab, segmented queue mode, drawer, or full detail page instead of a new top-level product.
|
||||
- Build the reusable drawer, right-rail, split-view, context-header, and overview-card primitives needed by the restoration sprints.
|
||||
- Adopt those primitives into the shipped restoration features so this sprint delivers working UI infrastructure, not just another contract document.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/shared`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/layout/`, `src/Web/StellaOps.Web/src/app/routes/`, `docs/modules/ui/contextual-actions-patterns`, `docs/modules/ui/restoration-topics/README.md`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: shipped shared UI primitives in `src/Web/**`, adopted patterns in restoration features, route-state helpers, shared tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/README.md`
|
||||
- `docs/modules/ui/watchlist-operations/README.md`
|
||||
- `docs/modules/ui/reachability-witnessing/README.md`
|
||||
- `docs/modules/ui/platform-ops-consolidation/README.md`
|
||||
- `docs/modules/ui/triage-explainability-workspace/README.md`
|
||||
- `docs/modules/ui/workflow-visualization-replay/README.md`
|
||||
- Safe parallelism:
|
||||
- the decision matrix and route-state contract should freeze before topic-specific FE implementation starts
|
||||
- shared primitives can be implemented in parallel after the contract is stable
|
||||
- topic sprints can adopt the primitives in parallel once interfaces are frozen
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/README.md`
|
||||
- `docs/modules/ui/architecture.md`
|
||||
- `docs/modules/ui/architecture-rework.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-CA-001 - Implement the shared route-state contract
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: FE Architect, Product Manager
|
||||
Task description:
|
||||
- Implement the shared route-state helpers for `tab`, `panel`, `drawer`, `returnTo`, `scope`, and `view`.
|
||||
- Make the restoration topics consume one working route-state model instead of each inventing bespoke state handling.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Shared route-state helpers exist in code.
|
||||
- [ ] Restoration topics can consume one route-state contract instead of bespoke state rules.
|
||||
- [ ] The placement hierarchy remains documented as the policy for using the new helpers.
|
||||
|
||||
### FE-CA-002 - Ship the shared contextual drawer host
|
||||
Status: TODO
|
||||
Dependency: FE-CA-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Build the shared drawer host used for edit, inspect, explain, and proof flows.
|
||||
- Standardize size, close behavior, route-state binding, keyboard handling, and history interactions in working code.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Drawer host is available for adoption in the restoration features.
|
||||
- [ ] Route-state open and close behavior works in code.
|
||||
- [ ] Accessibility and keyboard behavior are verified for the shared host.
|
||||
|
||||
### FE-CA-003 - Ship split-view, right-rail, and context-header primitives
|
||||
Status: TODO
|
||||
Dependency: FE-CA-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Build reusable split list/detail, right-rail, and context-header primitives for watchlist, triage, evidence, and reachability surfaces.
|
||||
- Ensure responsive behavior works in the shipped components rather than remaining a note in docs.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Split-view, right-rail, and context-header primitives exist in code.
|
||||
- [ ] Panel-stack behavior is usable in the shipped primitives.
|
||||
- [ ] Responsive fallback behavior works in the adopted surfaces.
|
||||
|
||||
### FE-CA-004 - Ship grouped overview-card and submenu primitives
|
||||
Status: TODO
|
||||
Dependency: FE-CA-001
|
||||
Owners: Product Manager, Developer
|
||||
Task description:
|
||||
- Build the grouped overview-card and submenu primitives used by Operations and narrow setup/admin capabilities.
|
||||
- Standardize one-card-to-one-route and one-submenu-to-one-owner patterns in working components.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Grouped overview-card primitives exist in code.
|
||||
- [ ] Submenu patterns are usable by owner shells.
|
||||
- [ ] Card-to-route and submenu-to-owner behavior is consistent in the shipped implementation.
|
||||
|
||||
### FE-CA-005 - Adopt the shared primitives into the restoration features
|
||||
Status: TODO
|
||||
Dependency: FE-CA-001
|
||||
Owners: FE Architect, Developer
|
||||
Task description:
|
||||
- Adopt the shared route-state, drawer, split-view, right-rail, context-header, and overview-card primitives into the restoration features.
|
||||
- Do not count this sprint complete until the primitives are used by the first shipped feature set rather than sitting unused in `shared`.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] At least the Watchlist, Reachability, and Triage or Workflow surfaces adopt the shared primitives.
|
||||
- [ ] Shared primitives replace bespoke implementations where the new restoration work lands.
|
||||
- [ ] Topic-specific adoption is visible in the shipped feature code.
|
||||
|
||||
### FE-CA-006 - Verify, document, and enforce shared usage
|
||||
Status: TODO
|
||||
Dependency: FE-CA-003
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add shared verification coverage for drawers, panels, tabs, split views, overview cards, and return-to-context behavior.
|
||||
- Update docs so future restoration work treats these primitives as required building blocks, not optional helpers.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Shared verification covers the adopted primitives.
|
||||
- [ ] Restoration sprints reference and consume the shared primitives.
|
||||
- [ ] Shared docs are updated to reflect the shipped primitive set.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship the shared primitives that let restored but narrow functionality become usable submenus, tabs, drawers, right rails, and detail pages instead of spawning new top-level products. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: contextual placement is a shared FE concern and should not be reinvented per topic.
|
||||
- Decision: stable route-state semantics are required for drawers, panels, and return-to-context behavior.
|
||||
- Risk: individual restoration sprints may drift and invent incompatible panel patterns before the shared contract lands.
|
||||
- Mitigation: freeze the shared contract first and make topic sprints depend on it.
|
||||
- Risk: responsive behavior may differ across list/detail, drawer, and right-rail surfaces.
|
||||
- Mitigation: require responsive fallback rules in the shared primitive contract before implementation begins.
|
||||
- Delivery rule: this sprint is only complete when the shared primitives are implemented and adopted by the restoration features, not when the contract is only documented.
|
||||
- Reference design note: `docs/modules/ui/contextual-actions-patterns/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm placement hierarchy and route-state contract.
|
||||
- 2026-03-09: freeze drawer, right-rail, split-view, and context-header primitives.
|
||||
- 2026-03-10: finalize adoption map and QA expectations for the restoration sprints.
|
||||
@@ -12,6 +12,10 @@ The Console presents operator dashboards for scans, policies, VEX evidence, runt
|
||||
- Generated the first-pass UI component preservation map at `component-preservation-map/README.md`.
|
||||
- The preservation map currently tracks 303 candidate components: 167 high-confidence dead surfaces and 136 routed-but-weakly-surfaced surfaces.
|
||||
- Each candidate now has a stable markdown dossier so later iterations can deepen keep / merge / wire / archive decisions without rebuilding the inventory.
|
||||
- Added the Decisioning Studio proposal at `policy-decisioning-studio/README.md` to consolidate policy authoring, governance, simulation, VEX decisioning, and release-context gate explanation under one shell.
|
||||
- Added restoration topic shape notes at `restoration-topics/README.md` for Watchlist, Reachability Witnessing, Platform Ops, Triage explainability, and Workflow Visualization placement.
|
||||
- Added implementation-ready UX dossiers for Watchlist, Reachability Witnessing, Platform Ops Consolidation, Triage Explainability Workspace, Workflow Visualization and Replay, and shared contextual action patterns.
|
||||
- Added FE sprint files for the five accepted restoration topics plus a shared sprint for single actions, drawers, tabs, and stray-page placement patterns.
|
||||
|
||||
## Latest updates (2026-02-21)
|
||||
- Runtime mock cutover completed for policy simulation history/conflict/batch flows and graph explorer data loading in `src/Web/StellaOps.Web/src/app/**`.
|
||||
@@ -53,6 +57,13 @@ The Console presents operator dashboards for scans, policies, VEX evidence, runt
|
||||
- ./operations/observability.md
|
||||
- ./console-architecture.md
|
||||
- ./component-preservation-map/README.md
|
||||
- ./restoration-topics/README.md
|
||||
- ./watchlist-operations/README.md
|
||||
- ./reachability-witnessing/README.md
|
||||
- ./platform-ops-consolidation/README.md
|
||||
- ./triage-explainability-workspace/README.md
|
||||
- ./workflow-visualization-replay/README.md
|
||||
- ./contextual-actions-patterns/README.md
|
||||
|
||||
## Backlog references
|
||||
- DOCS-CONSOLE-23-001 … DOCS-CONSOLE-23-003 baseline (done).
|
||||
|
||||
@@ -7,6 +7,14 @@
|
||||
- `docs/implplan/SPRINT_20260307_004_FE_self_serve_search_answer_first.md`
|
||||
- `docs/implplan/SPRINT_20260307_006_FE_self_serve_rollout_and_gap_closure.md`
|
||||
- `docs/implplan/SPRINT_20260307_009_DOCS_ui_component_preservation_map.md`
|
||||
- `docs/implplan/SPRINT_20260307_022_FE_policy_vex_release_decisioning_studio.md`
|
||||
- `docs/implplan/SPRINT_20260307_023_DOCS_ui_restoration_topic_shapes.md`
|
||||
- `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`
|
||||
|
||||
## Delivery Tasks
|
||||
- [DONE] 041-T1 Root IA/nav rewrite (Mission Control + Ops + Setup)
|
||||
@@ -49,3 +57,54 @@
|
||||
- [DONE] DOCS-UCM-002 First-pass preservation judgments for unused and weakly surfaced UI components
|
||||
- [DONE] DOCS-UCM-003 Summary tree for keep / merge / wire / archive decisions
|
||||
- [TODO] DOCS-UCM-004 Deep enrichment against Stella Ops product and module docs
|
||||
- [DONE] DOCS-UCM-005 Ordered restoration backlog for dropped functionality topics
|
||||
- [DONE] DOCS-RTS-001 Restoration topic index and placement rules
|
||||
- [DONE] DOCS-RTS-002 Watchlist restoration placement note
|
||||
- [DONE] DOCS-RTS-003 Reachability witnessing restoration placement note
|
||||
- [DONE] DOCS-RTS-004 Platform Ops consolidation placement note
|
||||
- [DONE] DOCS-RTS-005 Triage explainability restoration placement note
|
||||
- [DONE] DOCS-RTS-006 Workflow visualization and replay placement note
|
||||
- [DONE] DOCS-RTS-007 Deeper corroboration and implementation-sprint cutover for restoration topics
|
||||
- [TODO] FE-PD-001 Freeze Policy Decisioning Studio shell shape and ownership
|
||||
- [TODO] FE-PD-002 Canonical route and alias contract for policy / VEX / release decisioning
|
||||
- [TODO] FE-PD-003 Component merge matrix for Policy Studio, Governance, Simulation, and VEX
|
||||
- [TODO] FE-PD-004 Release-context UX contract for Release Orchestrator deep links
|
||||
- [TODO] FE-PD-005 FE implementation slices for Decisioning Studio shell and cutover
|
||||
- [TODO] FE-PD-006 QA and rollout contract for Decisioning Studio
|
||||
- [TODO] FE-PD-007 Docs and deprecation plan for legacy policy / VEX product labels
|
||||
- [TODO] FE-WL-001 Freeze Watchlist shell ownership and route contract
|
||||
- [TODO] FE-WL-002 Entries tab list-detail implementation slice
|
||||
- [TODO] FE-WL-003 Alerts tab and alert-detail drill-in
|
||||
- [TODO] FE-WL-004 Tuning tab and operational diagnostics
|
||||
- [TODO] FE-WL-005 Cross-product surfacing and deep links for Watchlist
|
||||
- [TODO] FE-WL-006 QA, rollout, and docs sync for Watchlist
|
||||
- [TODO] FE-RW-001 Freeze reachability shell tabs and route contract
|
||||
- [TODO] FE-RW-002 Witnesses tab and witness-detail page slice
|
||||
- [TODO] FE-RW-003 PoE drawer and permalink route contract
|
||||
- [TODO] FE-RW-004 Cross-product deep links and release-context use for reachability proofs
|
||||
- [TODO] FE-RW-005 Supporting evidence and export surfaces for witness UX
|
||||
- [TODO] FE-RW-006 QA, rollout, and docs sync for reachability witnessing
|
||||
- [TODO] FE-PO-001 Freeze Operations overview taxonomy and submenu structure
|
||||
- [TODO] FE-PO-002 Overview page regrouping and blocking-card contract
|
||||
- [TODO] FE-PO-003 Legacy widget absorption matrix for Platform Ops
|
||||
- [TODO] FE-PO-004 Route cleanup and alias migration contract for Operations
|
||||
- [TODO] FE-PO-005 Setup boundary and deep-link contract for Operations
|
||||
- [TODO] FE-PO-006 QA, rollout, and docs sync for Platform Ops consolidation
|
||||
- [TODO] FE-TX-001 Freeze artifact workspace route, lane, and panel contract
|
||||
- [TODO] FE-TX-002 List-lane segmentation slice for Artifact Workspace
|
||||
- [TODO] FE-TX-003 Detail-side explainability rail slice
|
||||
- [TODO] FE-TX-004 Audit bundles page and create-flow slice
|
||||
- [TODO] FE-TX-005 Supporting component merge matrix for Triage explainability
|
||||
- [TODO] FE-TX-006 QA, rollout, and docs sync for Triage explainability
|
||||
- [TODO] FE-WV-001 Freeze run-detail tab and route contract for workflow visualization
|
||||
- [TODO] FE-WV-002 Graph, timeline, and critical-path slice
|
||||
- [TODO] FE-WV-003 Replay and evidence integration slice
|
||||
- [TODO] FE-WV-004 Step-detail drawer and deep-link behavior
|
||||
- [TODO] FE-WV-005 Workflow-editor preview reuse boundary
|
||||
- [TODO] FE-WV-006 QA, rollout, alias migration, and docs sync for workflow visualization
|
||||
- [TODO] FE-CA-001 Freeze contextual placement decision matrix and route-state contract
|
||||
- [TODO] FE-CA-002 Shared contextual drawer host
|
||||
- [TODO] FE-CA-003 Split list-detail and right-rail primitives
|
||||
- [TODO] FE-CA-004 Context header and return-to-context contract
|
||||
- [TODO] FE-CA-005 Grouped overview-card and submenu patterns
|
||||
- [TODO] FE-CA-006 Adoption map, QA, and docs sync for contextual action patterns
|
||||
|
||||
@@ -14,6 +14,9 @@ Generated on 2026-03-07. This map captures Angular components that currently loo
|
||||
|
||||
## Main Artifacts
|
||||
- [Summary Tree](./SUMMARY_TREE.md)
|
||||
- [Restoration Priorities](./RESTORATION_PRIORITIES.md)
|
||||
- [Restoration Topic Shapes](../restoration-topics/README.md)
|
||||
- [Detailed Restoration UX Dossiers](../restoration-topics/README.md#detailed-ux-dossiers)
|
||||
- [Inventory JSON](./inventory.json)
|
||||
|
||||
## Branch Index
|
||||
@@ -113,3 +116,4 @@ Generated on 2026-03-07. This map captures Angular components that currently loo
|
||||
## Notes
|
||||
- This is a first-pass map. The weak-route bucket especially needs follow-up review against relative tab navigation and Stella Ops product docs.
|
||||
- Per-component dossiers are intentionally stable so later iterations can deepen the judgment rather than recreate the inventory.
|
||||
- The accepted Tier 1 restoration topics now have implementation-ready UX dossiers and FE sprint files under `docs/modules/ui/` and `docs/implplan/`.
|
||||
|
||||
@@ -0,0 +1,292 @@
|
||||
# Restoration Priorities
|
||||
|
||||
Generated on 2026-03-07 from the first-pass component preservation map.
|
||||
|
||||
This is the branch-level backlog for dropped or weakly surfaced UI functionality.
|
||||
The order is by confidence that the capability should exist in the final Stella Ops product, not by implementation ease.
|
||||
|
||||
## Ordering Rules
|
||||
|
||||
- `Highest confidence`: core product capability, clear business value, clear merge target, and evidence that the idea still exists elsewhere in docs or active flows.
|
||||
- `Medium confidence`: good idea with visible overlap or design debt, but the correct home still needs confirmation.
|
||||
- `Low confidence`: mostly legacy shelling or superseded IA, with little reason to preserve as a product surface.
|
||||
|
||||
## Tier 1 - Restore Or Merge First
|
||||
|
||||
### 1. Policy Decisioning Studio
|
||||
- Type: `merge`
|
||||
- Confidence: `very high`
|
||||
- Branches to absorb:
|
||||
- `Policy Studio Legacy`
|
||||
- `Policy Governance`
|
||||
- `Policy Simulation`
|
||||
- `VEX Studio`
|
||||
- relevant `Exceptions` and `Approvals` flows
|
||||
- Why:
|
||||
- This is one end-to-end decisioning workflow split across too many sibling products.
|
||||
- Release Orchestrator consumes these decisions but should not own duplicate UI.
|
||||
- Target:
|
||||
- canonical shell at `/ops/policy`
|
||||
- Notes:
|
||||
- Detailed product proposal already captured in `docs/modules/ui/policy-decisioning-studio/README.md`.
|
||||
|
||||
### 2. Watchlist
|
||||
- Type: `wire-in`
|
||||
- Confidence: `very high`
|
||||
- Branches to absorb:
|
||||
- `Watchlist`
|
||||
- Why:
|
||||
- Looks productizable already, backed by a real client/provider, and fills an operator monitoring need that still fits Stella Ops.
|
||||
- Target:
|
||||
- `Setup > Trust & Signing > Identity Watchlist`
|
||||
- Notes:
|
||||
- Detailed UX dossier: `docs/modules/ui/watchlist-operations/README.md`
|
||||
- Implementation sprint: `docs/implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md`
|
||||
|
||||
### 3. Reachability Witnessing
|
||||
- Type: `merge`
|
||||
- Confidence: `very high`
|
||||
- Branches to absorb:
|
||||
- `Reachability Witnessing`
|
||||
- Why:
|
||||
- Reachability is a differentiator; witness/proof UX strengthens explainability, auditability, and promotion decisions.
|
||||
- Target:
|
||||
- `Security / Reachability` with evidence-side drill-down links
|
||||
- Notes:
|
||||
- Detailed UX dossier: `docs/modules/ui/reachability-witnessing/README.md`
|
||||
- Implementation sprint: `docs/implplan/SPRINT_20260307_025_FE_reachability_witnessing_merge.md`
|
||||
|
||||
### 4. Platform Ops Consolidation
|
||||
- Type: `merge`
|
||||
- Confidence: `high`
|
||||
- Branches to absorb:
|
||||
- `Platform Ops Legacy` (`dead` and `weak-route`)
|
||||
- Why:
|
||||
- The product clearly still needs these ops views; the problem is fragmentation between old and new shells.
|
||||
- Target:
|
||||
- `Ops > Operations`
|
||||
- Notes:
|
||||
- Detailed UX dossier: `docs/modules/ui/platform-ops-consolidation/README.md`
|
||||
- Implementation sprint: `docs/implplan/SPRINT_20260307_026_FE_platform_ops_consolidation.md`
|
||||
|
||||
### 5. Triage Explainability Workbench
|
||||
- Type: `merge`
|
||||
- Confidence: `high`
|
||||
- Branches to absorb:
|
||||
- `Triage Workbench`
|
||||
- Why:
|
||||
- Quiet-lane, audit-bundle, and explainability ideas are still useful, but they should live inside the main triage flow.
|
||||
- Target:
|
||||
- `/triage/artifacts` and `/triage/audit-bundles`
|
||||
- Notes:
|
||||
- Detailed UX dossier: `docs/modules/ui/triage-explainability-workspace/README.md`
|
||||
- Implementation sprint: `docs/implplan/SPRINT_20260307_027_FE_triage_explainability_workspace.md`
|
||||
|
||||
### 6. Workflow Visualization And Replay UX
|
||||
- Type: `merge`
|
||||
- Confidence: `high`
|
||||
- Branches to absorb:
|
||||
- `Workflow Visualization Prototype`
|
||||
- Why:
|
||||
- Time-travel, replay, and step-detail views fit Release Orchestrator and Evidence far better than a standalone abandoned route.
|
||||
- Target:
|
||||
- `/releases/runs`, `/evidence`, and release-context views
|
||||
- Notes:
|
||||
- Detailed UX dossier: `docs/modules/ui/workflow-visualization-replay/README.md`
|
||||
- Implementation sprint: `docs/implplan/SPRINT_20260307_028_FE_workflow_visualization_replay.md`
|
||||
|
||||
## Tier 2 - Surface Existing Capability Instead Of Rebuilding
|
||||
|
||||
These are mostly not dropped products. They are current or near-current capabilities that appear weakly surfaced and should be wired, grouped, or promoted in navigation.
|
||||
|
||||
### 7. Unified Audit Surfaces
|
||||
- Type: `wire-in / preserve`
|
||||
- Confidence: `high`
|
||||
- Branches:
|
||||
- `Audit Log`
|
||||
- Target:
|
||||
- keep under admin/security, but improve entry points and deep links
|
||||
|
||||
### 8. Offline Operations
|
||||
- Type: `wire-in / preserve`
|
||||
- Confidence: `high`
|
||||
- Branches:
|
||||
- `Offline Kit`
|
||||
- `Evidence Export`
|
||||
- `Evidence Pack`
|
||||
- Target:
|
||||
- `/ops/operations/*` with evidence links where relevant
|
||||
|
||||
### 9. Scanner And Job Operations
|
||||
- Type: `wire-in / preserve`
|
||||
- Confidence: `high`
|
||||
- Branches:
|
||||
- `Scanner Ops`
|
||||
- `Jobengine`
|
||||
- `Scheduler Ops`
|
||||
- `Deadletter`
|
||||
- `Slo Monitoring`
|
||||
- `Signals`
|
||||
- Target:
|
||||
- consolidated ops operations subtree
|
||||
|
||||
### 10. Quota, Platform Health, And AOC Operations
|
||||
- Type: `wire-in / preserve`
|
||||
- Confidence: `high`
|
||||
- Branches:
|
||||
- `Quota Dashboard`
|
||||
- `Platform Health`
|
||||
- `Aoc Compliance`
|
||||
- `Platform`
|
||||
- Target:
|
||||
- `/ops/operations/*`
|
||||
|
||||
### 11. Topology And Trust Administration
|
||||
- Type: `wire-in / preserve`
|
||||
- Confidence: `high`
|
||||
- Branches:
|
||||
- `Topology`
|
||||
- `Trust Admin`
|
||||
- `Issuer Trust`
|
||||
- `Settings`
|
||||
- `Console Admin`
|
||||
- Target:
|
||||
- `Setup` plus admin/trust routes with stronger shell linkage
|
||||
|
||||
### 12. Security Operations Leaves
|
||||
- Type: `wire-in / preserve`
|
||||
- Confidence: `high`
|
||||
- Branches:
|
||||
- `Unknowns Tracking`
|
||||
- `Security Risk`
|
||||
- `Mission Control` leaves
|
||||
- `Notify`
|
||||
- Target:
|
||||
- current `Security`, `Mission Control`, and `Notify` shells
|
||||
|
||||
## Tier 3 - Merge After Targeted Review
|
||||
|
||||
These branches probably contain valuable pieces, but the right home needs one more review pass.
|
||||
|
||||
### 13. Release Orchestrator Legacy Surfaces
|
||||
- Type: `merge`
|
||||
- Confidence: `medium-high`
|
||||
- Branches:
|
||||
- `Release Orchestrator` (`dead`)
|
||||
- `Release Orchestrator` (`weak-route`)
|
||||
- `Releases` (`dead` and `weak-route`)
|
||||
- Why:
|
||||
- Dashboard, promotion request, runs, evidence, deployments, and environment configuration still matter.
|
||||
- The issue is duplication between older release-orchestrator shells and the newer releases/evidence/setup IA.
|
||||
- Likely target:
|
||||
- `/releases`, `/evidence`, `/setup/topology`, and Decisioning Studio release-context entry points
|
||||
|
||||
### 14. Evidence And Proof Exploration
|
||||
- Type: `merge`
|
||||
- Confidence: `medium-high`
|
||||
- Branches:
|
||||
- `Evidence`
|
||||
- `Evidence Thread`
|
||||
- `Proof Chain`
|
||||
- `Proof Studio`
|
||||
- `Overlays`
|
||||
- Why:
|
||||
- Stella Ops should keep explainable, navigable evidence, but the final shape should be one evidence product, not several siblings.
|
||||
- Likely target:
|
||||
- `/evidence`
|
||||
|
||||
### 15. Lineage Extended Views
|
||||
- Type: `merge / investigate`
|
||||
- Confidence: `medium`
|
||||
- Branches:
|
||||
- `Lineage`
|
||||
- `Compare`
|
||||
- `Change Trace`
|
||||
- Why:
|
||||
- The product clearly values lineage, but the dead components may be alternate shells or unlanded subviews rather than missing capability.
|
||||
- Likely target:
|
||||
- active lineage and compare surfaces
|
||||
|
||||
### 16. Security Explorer Variants
|
||||
- Type: `merge / investigate`
|
||||
- Confidence: `medium`
|
||||
- Branches:
|
||||
- `Security`
|
||||
- `Vuln Explorer`
|
||||
- `Vulnerabilities`
|
||||
- `Graph`
|
||||
- `Binary Index`
|
||||
- `Cvss`
|
||||
- Why:
|
||||
- Some ideas are likely useful, but these areas already have active products and the dead branches may mostly be duplicate shells.
|
||||
- Likely target:
|
||||
- active `Security`, `Vulnerabilities`, `Graph`, and `Analyze` flows
|
||||
|
||||
## Tier 4 - Investigate Before Committing
|
||||
|
||||
### 17. Advisory AI Prototypes
|
||||
- Type: `investigate`
|
||||
- Confidence: `medium-low`
|
||||
- Branches:
|
||||
- `Advisory Ai`
|
||||
- `Ai Runs`
|
||||
- Why:
|
||||
- There is obvious product interest, but these specific dead components look like experiments rather than clear missing product surfaces.
|
||||
|
||||
### 18. Miscellaneous Product Experiments
|
||||
- Type: `investigate`
|
||||
- Confidence: `low-medium`
|
||||
- Branches:
|
||||
- `Snapshot`
|
||||
- `Timeline`
|
||||
- `Scores`
|
||||
- `Operations`
|
||||
- `Dashboard`
|
||||
- `Workspaces`
|
||||
- `Home`
|
||||
- `Findings`
|
||||
- `Qa`
|
||||
- `Unknowns`
|
||||
- Why:
|
||||
- These are too generic or too isolated to restore on branch name alone.
|
||||
|
||||
### 19. Shared Or Ambiguous UI Prototypes
|
||||
- Type: `investigate`
|
||||
- Confidence: `low-medium`
|
||||
- Branches:
|
||||
- `Components`
|
||||
- `Ui`
|
||||
- `Admin Notifications`
|
||||
- `Registry Admin`
|
||||
- `Aoc`
|
||||
- `Doctor`
|
||||
- `Deployments`
|
||||
- `Environments`
|
||||
- `Approvals`
|
||||
- Why:
|
||||
- Several of these may be helpers, alternates, or obsolete page shells rather than missing product capabilities.
|
||||
|
||||
## Tier 5 - Retire Unless Docs Strongly Reopen Them
|
||||
|
||||
### 20. Release Control Legacy
|
||||
- Type: `archive`
|
||||
- Confidence: `very high` that it should not be restored as-is
|
||||
- Branches:
|
||||
- `Release Control Legacy`
|
||||
- Why:
|
||||
- The current IA already superseded it with `/releases`, `/ops`, and `/setup`.
|
||||
- Any good ideas here should be harvested into the active release/setup products rather than restored as a separate branch.
|
||||
|
||||
## Recommended Next Restoration Sequence
|
||||
|
||||
1. Ship `Policy Decisioning Studio` planning to implementation.
|
||||
2. Wire in `Watchlist`.
|
||||
3. Merge `Reachability Witnessing`.
|
||||
4. Consolidate `Platform Ops Legacy` into current Ops.
|
||||
5. Merge `Triage Workbench` into active triage/evidence.
|
||||
6. Fold `Workflow Visualization` into release/evidence flows.
|
||||
7. Do a focused review of `Release Orchestrator` dead branches and absorb what still belongs in Releases/Evidence/Setup.
|
||||
8. After that, tackle the big surfacing debt bucket: audit, offline, scanner, quota, topology, trust, unknowns.
|
||||
|
||||
Detailed topic-shape notes for items 2 through 6 now live under `docs/modules/ui/restoration-topics/`.
|
||||
The shared placement contract for stray actions, drawers, tabs, and detail pages is captured in `docs/modules/ui/contextual-actions-patterns/README.md` and implementation sprint `docs/implplan/SPRINT_20260307_029_FE_contextual_actions_and_stray_surfaces.md`.
|
||||
155
docs/modules/ui/contextual-actions-patterns/README.md
Normal file
155
docs/modules/ui/contextual-actions-patterns/README.md
Normal file
@@ -0,0 +1,155 @@
|
||||
# Contextual Actions And Stray Surfaces
|
||||
|
||||
## Recommendation
|
||||
|
||||
Create one shared UI contract for dropped functionality that does not deserve its own product shell.
|
||||
|
||||
The default answer for stray functionality should be one of these placements, in order:
|
||||
|
||||
1. owner product submenu
|
||||
2. owner page tab
|
||||
3. segmented list mode
|
||||
4. right rail or drawer
|
||||
5. full detail page under the owner shell
|
||||
|
||||
This contract should guide both IA decisions and implementation primitives across watchlist, reachability, triage, workflow replay, and operations.
|
||||
|
||||
## Why This Is Needed
|
||||
|
||||
- Many dropped Stella Ops components are useful ideas but too narrow to justify a new sidebar branch.
|
||||
- Without shared rules, every restoration topic risks inventing its own panel, query-param, and deep-link behavior.
|
||||
- Operators need consistent navigation and return-to-context behavior across shells.
|
||||
- A common contract reduces FE churn and makes later restorations easier to place.
|
||||
|
||||
## Placement Hierarchy
|
||||
|
||||
### 1. Submenu
|
||||
Use when the capability is owner-owned, low-frequency, and configuration-heavy.
|
||||
|
||||
Examples:
|
||||
- watchlist under `Setup > Trust & Signing`
|
||||
- diagnostics under `Ops > Operations`
|
||||
|
||||
### 2. Page tab
|
||||
Use when the capability is a stable facet of one product shell.
|
||||
|
||||
Examples:
|
||||
- reachability `Witnesses`
|
||||
- run-detail `Replay`
|
||||
|
||||
### 3. Segmented list mode
|
||||
Use when the capability changes queue state rather than product ownership.
|
||||
|
||||
Examples:
|
||||
- triage `Quiet Lane`
|
||||
- triage `Needs Review`
|
||||
|
||||
### 4. Right rail or drawer
|
||||
Use when the surface explains, edits, or inspects an item in context.
|
||||
|
||||
Examples:
|
||||
- watchlist entry edit
|
||||
- reachability PoE detail
|
||||
- workflow step detail
|
||||
- triage reason capsule
|
||||
|
||||
### 5. Full detail page
|
||||
Use when the item needs shareable URLs, deep auditability, and enough information density to stand alone.
|
||||
|
||||
Examples:
|
||||
- reachability witness detail
|
||||
- triage artifact detail
|
||||
- audit bundle detail
|
||||
|
||||
## Decision Matrix
|
||||
|
||||
| Situation | Preferred placement | Avoid |
|
||||
| --- | --- | --- |
|
||||
| configuration-heavy, low daily traffic | submenu or setup tab | new top-level product |
|
||||
| one list with rich detail | split list/detail or drawer | separate workbench brand |
|
||||
| explanation for an active decision | right rail or drawer | isolated route tree |
|
||||
| durable investigation artifact | full detail page | modal-only access |
|
||||
| runtime facet of an existing entity | page tab | separate sidebar item |
|
||||
|
||||
## Shared Route-State Contract
|
||||
|
||||
Use stable, predictable query params and child routes instead of ad hoc local state.
|
||||
|
||||
### Preferred query params
|
||||
- `tab=<name>`
|
||||
- `panel=<name>`
|
||||
- `drawer=<name>`
|
||||
- `returnTo=<encoded route>`
|
||||
- `scope=<name>`
|
||||
- `view=<name>`
|
||||
|
||||
### Rules
|
||||
- use child routes for durable subpages
|
||||
- use query params for secondary panels and drawers
|
||||
- preserve `returnTo` whenever a user came from another owner shell
|
||||
- keep panel names short and stable for bookmarks and tests
|
||||
|
||||
## Shared Primitives To Build
|
||||
|
||||
### 1. Context header
|
||||
- pinned subject context
|
||||
- status chips
|
||||
- return-to-context action
|
||||
|
||||
### 2. Split list/detail shell
|
||||
- stable layout for list left, detail right
|
||||
- supports keyboard navigation and deep linking
|
||||
|
||||
### 3. Drawer host
|
||||
- route-aware drawers for edit, inspect, and explain flows
|
||||
- consistent size, close behavior, and history handling
|
||||
|
||||
### 4. Right-rail panel stack
|
||||
- secondary tabs for evidence, explanation, provenance, and history
|
||||
|
||||
### 5. Grouped overview cards
|
||||
- consistent card layout for ops-like overview pages
|
||||
- each card maps to exactly one child route
|
||||
|
||||
### 6. Action tray
|
||||
- row or bulk actions that preserve page context
|
||||
- confirmation only for destructive or privilege-sensitive actions
|
||||
|
||||
## Topic Mapping
|
||||
|
||||
### Watchlist
|
||||
- submenu + tabs + edit drawer
|
||||
|
||||
### Reachability Witnessing
|
||||
- tabbed shell + witness detail page + PoE drawer
|
||||
|
||||
### Platform Ops
|
||||
- grouped overview cards + stable child routes
|
||||
|
||||
### Triage Explainability
|
||||
- segmented lanes + detail-side panels + sibling audit-bundles page
|
||||
|
||||
### Workflow Visualization
|
||||
- run-detail tabs + step drawer + evidence deep links
|
||||
|
||||
## Implementation Standards
|
||||
|
||||
- Prefer contextual UX over new products.
|
||||
- Preserve deep-link stability for tabs and panels.
|
||||
- Keep actions evidence-first and operator-confirmed when risk is high.
|
||||
- Make drawers and rails testable with stable route state.
|
||||
- Reuse primitives rather than re-creating bespoke shells per topic.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not turn every contextual tool into a modal.
|
||||
- Do not allow each feature team to invent incompatible query-param contracts.
|
||||
- Do not use new top-level navigation to solve narrow discoverability problems.
|
||||
|
||||
## Source Inputs
|
||||
|
||||
- `docs/modules/ui/restoration-topics/README.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
- `docs/ui-analysis/05_ROUTE_SUMMARY_AND_OBSERVATIONS.md`
|
||||
- `docs/modules/ui/architecture.md`
|
||||
- `docs/modules/ui/architecture-rework.md`
|
||||
@@ -11,11 +11,27 @@ Provide a living plan for UI deliverables, dependencies, and evidence.
|
||||
- `SPRINT_20260307_004_FE_self_serve_search_answer_first.md` - answer-first search shell, page-owned self-serve questions, and explicit fallback states.
|
||||
- `SPRINT_20260307_006_FE_self_serve_rollout_and_gap_closure.md` - page rollout, guided handoffs, and telemetry-driven gap closure.
|
||||
- `SPRINT_20260307_009_DOCS_ui_component_preservation_map.md` - per-component preservation dossiers for unused and weakly surfaced console UI components.
|
||||
- `SPRINT_20260307_022_FE_policy_vex_release_decisioning_studio.md` - canonical Decisioning Studio shell to unify policy, simulation, VEX decisioning, and release-context gate explanation.
|
||||
- `SPRINT_20260307_023_DOCS_ui_restoration_topic_shapes.md` - documentation prerequisite for shell/menu/tab placements; not a product-delivery sprint by itself.
|
||||
- `SPRINT_20260307_024_FE_identity_watchlist_shell.md` - ship the Trust & Signing-owned identity watchlist shell with usable entries, alerts, tuning, and alert deep-link behavior.
|
||||
- `SPRINT_20260307_025_FE_reachability_witnessing_merge.md` - ship witness and proof-of-exposure UX inside Security > Reachability with working cross-shell deep links.
|
||||
- `SPRINT_20260307_026_FE_platform_ops_consolidation.md` - ship one Operations shell with grouped overview cards, legacy widget absorption, and legacy redirects.
|
||||
- `SPRINT_20260307_027_FE_triage_explainability_workspace.md` - ship the artifact workspace lane model, explainability panels, and audit-bundle flows.
|
||||
- `SPRINT_20260307_028_FE_workflow_visualization_replay.md` - ship run-detail graph, timeline, replay, and evidence tabs plus bounded workflow-editor preview reuse.
|
||||
- `SPRINT_20260307_029_FE_contextual_actions_and_stray_surfaces.md` - ship the shared tabs, drawers, right rails, split views, and contextual detail primitives adopted by the restoration features.
|
||||
|
||||
## Latest evidence
|
||||
- `docs/modules/ui/component-preservation-map/README.md` - root index for the first-pass preservation map.
|
||||
- `docs/modules/ui/component-preservation-map/SUMMARY_TREE.md` - branch-level keep / merge / wire / archive guidance.
|
||||
- `docs/modules/ui/component-preservation-map/inventory.json` - deterministic machine-readable inventory for 303 candidate components.
|
||||
- `docs/modules/ui/policy-decisioning-studio/README.md` - proposed Decisioning Studio product shape, tab model, route contract, and Release Orchestrator integration boundary.
|
||||
- `docs/modules/ui/restoration-topics/README.md` - detailed placement notes for the next restoration topics after Decisioning Studio.
|
||||
- `docs/modules/ui/watchlist-operations/README.md` - detailed watchlist UX dossier and owner-shell contract.
|
||||
- `docs/modules/ui/reachability-witnessing/README.md` - detailed witness and proof UX dossier plus cross-shell deep-link contract.
|
||||
- `docs/modules/ui/platform-ops-consolidation/README.md` - detailed Operations overview taxonomy and legacy absorption plan.
|
||||
- `docs/modules/ui/triage-explainability-workspace/README.md` - detailed artifact workspace and audit-bundle UX dossier.
|
||||
- `docs/modules/ui/workflow-visualization-replay/README.md` - detailed run-detail graph, timeline, replay, and evidence UX dossier.
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md` - shared placement contract for stray actions, pages, drawers, and tabs.
|
||||
|
||||
## Dependencies
|
||||
- `docs/modules/ui/architecture.md`
|
||||
|
||||
179
docs/modules/ui/platform-ops-consolidation/README.md
Normal file
179
docs/modules/ui/platform-ops-consolidation/README.md
Normal file
@@ -0,0 +1,179 @@
|
||||
# Platform Ops Consolidation
|
||||
|
||||
## Recommendation
|
||||
|
||||
Keep one consolidated operator shell under `Ops > Operations` and absorb the useful legacy `platform-ops` surfaces into it.
|
||||
|
||||
- Canonical mount: `/ops/operations`
|
||||
- Suggested user-facing title: `Operations`
|
||||
- Suggested overview page title: `Platform Ops`
|
||||
|
||||
This is not a restoration of an abandoned product. It is a consolidation of operator navigation, overview grouping, and missing widgets into the existing route tree.
|
||||
|
||||
## Why This Is The Right Shape
|
||||
|
||||
- The current app already routes operators through `/ops/operations`.
|
||||
- The dead and weak-route `platform-ops` pages overlap with the live ops shell rather than introducing a separate domain.
|
||||
- Restoring the old shell would recreate fragmentation between overview pages, diagnostics, quotas, AOC, and air-gap operations.
|
||||
- The correct move is to strengthen one overview and one child-route tree.
|
||||
|
||||
## Operator Modes
|
||||
|
||||
### 1. Control Room Mode
|
||||
- Used by operators scanning for blocking platform issues.
|
||||
- Focus: overview, blocking cards, and high-priority drills.
|
||||
|
||||
### 2. Subsystem Specialist Mode
|
||||
- Used by operators responsible for one area such as quotas, offline kit, job queues, or AOC.
|
||||
- Focus: a dedicated child route reached from grouped cards.
|
||||
|
||||
### 3. Triage Handoff Mode
|
||||
- Used when another shell surfaces an ops problem and links into operations.
|
||||
- Focus: deep link into the relevant child route with preserved return context.
|
||||
|
||||
## Recommended IA
|
||||
|
||||
### Overview groups
|
||||
- `Blocking`
|
||||
- data integrity
|
||||
- AOC compliance
|
||||
- critical platform alerts
|
||||
- `Execution`
|
||||
- jobs and queues
|
||||
- scheduler
|
||||
- dead-letter
|
||||
- signals
|
||||
- `Health`
|
||||
- health and SLO
|
||||
- diagnostics
|
||||
- system status
|
||||
- `Supply And Airgap`
|
||||
- feeds and airgap
|
||||
- offline kit
|
||||
- pack registry
|
||||
- `Capacity`
|
||||
- quotas and limits
|
||||
- `Communications`
|
||||
- notifications
|
||||
|
||||
### Child routes
|
||||
- `Overview`
|
||||
- `Data Integrity`
|
||||
- `Jobs & Queues`
|
||||
- `Health & SLO`
|
||||
- `Feeds & Airgap`
|
||||
- `Offline Kit`
|
||||
- `Quotas & Limits`
|
||||
- `AOC Compliance`
|
||||
- `Diagnostics`
|
||||
- `Signals`
|
||||
- `Pack Registry`
|
||||
- `Notifications`
|
||||
|
||||
## Page Anatomy
|
||||
|
||||
### Overview page
|
||||
- top blocking strip:
|
||||
- open incidents
|
||||
- highest-risk subsystem
|
||||
- degraded status count
|
||||
- grouped cards:
|
||||
- each card shows status, trend, queue depth, or freshness
|
||||
- each card links to a single child route
|
||||
- lower sections:
|
||||
- recent changes
|
||||
- pending operator actions
|
||||
- cross-links to Setup-owned topology when infra ownership is involved
|
||||
|
||||
### Child routes
|
||||
- keep a consistent subpage layout:
|
||||
- status summary cards
|
||||
- main table or chart
|
||||
- action rail
|
||||
- diagnostics or evidence side panel when relevant
|
||||
|
||||
## Route Contract
|
||||
|
||||
Prefer the current route family and tighten it rather than creating new paths.
|
||||
|
||||
### Canonical routes
|
||||
- `/ops/operations`
|
||||
- `/ops/operations/jobs-queues`
|
||||
- `/ops/operations/data-integrity`
|
||||
- `/ops/operations/health-slo`
|
||||
- `/ops/operations/feeds-airgap`
|
||||
- `/ops/operations/offline-kit`
|
||||
- `/ops/operations/quotas`
|
||||
- `/ops/operations/aoc`
|
||||
- `/ops/operations/doctor`
|
||||
- `/ops/operations/signals`
|
||||
- `/ops/operations/packs`
|
||||
- `/ops/operations/notifications`
|
||||
|
||||
### Alias and cleanup rules
|
||||
- legacy `/platform-ops/*` bookmarks should redirect into `/ops/operations/*`
|
||||
- duplicate overview routes should be retired once card parity is reached
|
||||
- child-route labels should match the sidebar and overview cards exactly
|
||||
|
||||
## What To Merge
|
||||
|
||||
### Preserve as the main shell
|
||||
- `PlatformOpsOverviewPageComponent`
|
||||
- `operations.routes.ts`
|
||||
|
||||
### Absorb from legacy Platform Ops
|
||||
- `PlatformOpsOverviewComponent`
|
||||
- federation and telemetry summary cards that still add value
|
||||
- data-integrity pages still missing from the live grouped overview
|
||||
- any distinctive capacity or compliance widgets not already surfaced
|
||||
|
||||
## Single Actions And Supporting Surfaces
|
||||
|
||||
### Agent fleet
|
||||
- primary home: `Setup > Topology`
|
||||
- operations overview may show health summary and deep-link out
|
||||
|
||||
### Diagnostics
|
||||
- keep as `Ops > Operations > Diagnostics`
|
||||
- avoid a second top-level doctor product entry
|
||||
|
||||
### AOC violations and reports
|
||||
- keep overview status on the main page
|
||||
- full detail stays in its own child route
|
||||
|
||||
### Offline import/export helpers
|
||||
- keep inside `Offline Kit` or `Feeds & Airgap`
|
||||
- do not create separate sidebar products
|
||||
|
||||
## Cross-Product Entry Points
|
||||
|
||||
- `Mission Control`
|
||||
- links to degraded subsystem routes
|
||||
- `Setup > Topology`
|
||||
- links back to operations when infra state impacts runtime operations
|
||||
- `Evidence` or `Releases`
|
||||
- links into data integrity, signals, or pack registry when evidence freshness blocks a workflow
|
||||
|
||||
## UI Standards For Implementation
|
||||
|
||||
- One shell, one overview, one submenu tree.
|
||||
- Group cards by operator concern, not by backend service name alone.
|
||||
- Preserve stable deep links from cards to subpages.
|
||||
- Keep Setup-owned infrastructure management distinct from Ops-owned runtime monitoring.
|
||||
- Treat legacy routes as migration aliases only.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not revive `/platform-ops/*` as a parallel route tree.
|
||||
- Do not duplicate topology ownership under Ops.
|
||||
- Do not create separate overview pages for each subsystem when grouped cards already solve discoverability.
|
||||
|
||||
## Source 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`
|
||||
- `src/Web/StellaOps.Web/src/app/features/aoc-compliance/aoc-compliance.routes.ts`
|
||||
172
docs/modules/ui/policy-decisioning-studio/README.md
Normal file
172
docs/modules/ui/policy-decisioning-studio/README.md
Normal file
@@ -0,0 +1,172 @@
|
||||
# Policy Decisioning Studio
|
||||
|
||||
## Recommendation
|
||||
|
||||
Create one dynamic sub-product shell, not one giant page and not three separate sibling products.
|
||||
|
||||
- Canonical mount: `/ops/policy`
|
||||
- Suggested user-facing title: `Decisioning Studio`
|
||||
- Suggested nav label for now: keep `Policy` to avoid unnecessary IA churn during rollout
|
||||
|
||||
This shell should unify the current policy workspace, policy governance, policy simulation, and the actionable parts of VEX conflict resolution into one product surface with deep-linkable tabs and a shared context model.
|
||||
|
||||
## Why This Is The Right Shape
|
||||
|
||||
- Policy authoring, governance, simulation, VEX overrides, exceptions, and release gates are all parts of one decisioning workflow.
|
||||
- Release Orchestrator is a consumer of policy/VEX decisions, not a second owner of those UIs.
|
||||
- The current split creates duplicated mental models: packs live in one branch, governance in another, simulation in another, and VEX conflicts off to the side.
|
||||
- A single shell allows one shared context header for tenant, pack, environment, artifact digest, and release.
|
||||
- Deep-linkable child routes preserve auditability and operator workflows better than a modal-heavy or single-scroll design.
|
||||
|
||||
## Product Modes
|
||||
|
||||
The shell should support three modes without forking the UI into separate apps.
|
||||
|
||||
### 1. Global Mode
|
||||
- Used by policy admins and security operators.
|
||||
- Focus: pack inventory, governance controls, simulations, trust/VEX posture, gate policy defaults.
|
||||
|
||||
### 2. Pack Mode
|
||||
- Used when the user is working on a specific policy pack.
|
||||
- Focus: editing, YAML, rule builder, approvals, explain traces, simulation for one pack.
|
||||
|
||||
### 3. Release Context Mode
|
||||
- Entered from Release Orchestrator deep links.
|
||||
- Context is pinned in the shell header: `releaseId`, `environment`, `artifactDigest`, `approvalId`, and effective policy bundle.
|
||||
- Focus: "why is this promotion blocked / allowed?" rather than general administration.
|
||||
|
||||
## Recommended IA
|
||||
|
||||
### Primary tabs
|
||||
- `Overview`
|
||||
- decision board for active packs, pending approvals, open conflicts, shadow-mode readiness, and gate health
|
||||
- `Packs`
|
||||
- policy pack inventory and pack-scoped workspace
|
||||
- `Governance`
|
||||
- risk budgets, trust weights, staleness, sealed mode, profiles, validator, governance audit
|
||||
- `Simulation`
|
||||
- shadow mode, console, coverage, effective policy, diff, merge preview, history, batch evaluation
|
||||
- `VEX & Exceptions`
|
||||
- VEX conflicts, consensus review, overrides, exception queue, exception detail, rationale capture
|
||||
- `Release Gates`
|
||||
- gate catalog, environment-specific gate policy, release-context gate evaluation, promotion readiness
|
||||
- `Audit`
|
||||
- immutable policy/VEX decision history, evidence pointers, exports, explain traces
|
||||
|
||||
### Secondary navigation
|
||||
- Use child tabs inside the active primary tab.
|
||||
- Use a contextual right rail for evidence, explain traces, or release summary.
|
||||
- Never hide critical release-decision screens behind modal-only flows.
|
||||
|
||||
## Route Contract
|
||||
|
||||
Keep `/ops/policy` as the canonical root and move the product to a single route tree.
|
||||
|
||||
### Canonical routes
|
||||
- `/ops/policy`
|
||||
- `/ops/policy/packs`
|
||||
- `/ops/policy/packs/:packId`
|
||||
- `/ops/policy/packs/:packId/edit`
|
||||
- `/ops/policy/packs/:packId/rules`
|
||||
- `/ops/policy/packs/:packId/yaml`
|
||||
- `/ops/policy/packs/:packId/approvals`
|
||||
- `/ops/policy/packs/:packId/explain/:runId`
|
||||
- `/ops/policy/governance/...`
|
||||
- `/ops/policy/simulation/...`
|
||||
- `/ops/policy/vex`
|
||||
- `/ops/policy/vex/conflicts`
|
||||
- `/ops/policy/vex/conflicts/:conflictId`
|
||||
- `/ops/policy/exceptions`
|
||||
- `/ops/policy/exceptions/:exceptionId`
|
||||
- `/ops/policy/gates`
|
||||
- `/ops/policy/gates/environments/:environment`
|
||||
- `/ops/policy/gates/releases/:releaseId`
|
||||
- `/ops/policy/audit`
|
||||
|
||||
### Alias and migration rules
|
||||
- Legacy `/policy-studio/*` routes redirect into `/ops/policy/packs/*`
|
||||
- `/admin/policy/governance` and `/admin/policy/simulation` redirect into `/ops/policy/governance/*` and `/ops/policy/simulation/*`
|
||||
- `/admin/vex-hub/*` should redirect into `/ops/policy/vex/*` for mutating and conflict-resolution flows
|
||||
- If Analyze keeps a VEX entry point, it should deep-link into the same shell in read-only context instead of owning a separate VEX product
|
||||
|
||||
## What To Merge
|
||||
|
||||
### Merge into `Packs`
|
||||
- `PolicyWorkspaceComponent`
|
||||
- `PolicyEditorComponent`
|
||||
- `PolicyYamlEditorComponent`
|
||||
- `PolicyRuleBuilderComponent`
|
||||
- `PolicyApprovalsComponent`
|
||||
- `PolicyExplainComponent`
|
||||
- `PolicyDashboardComponent`
|
||||
|
||||
### Merge into `Governance`
|
||||
- `PolicyGovernanceComponent` shell
|
||||
- risk budget, trust weighting, staleness, sealed mode, profiles, validator, audit, conflicts, schema tools
|
||||
|
||||
### Merge into `Simulation`
|
||||
- `SimulationDashboardComponent` shell
|
||||
- shadow mode, console, lint, coverage, effective policy, audit, diff, promotion, merge preview, history, batch
|
||||
|
||||
### Merge into `VEX & Exceptions`
|
||||
- `VexConflictResolutionComponent`
|
||||
- preserved ideas from `VexConflictStudioComponent`
|
||||
- exception queue and exception detail flows
|
||||
- VEX consensus and trust-weighted decision support
|
||||
|
||||
### Merge into `Release Gates`
|
||||
- promotion gate surfaces from policy simulation
|
||||
- environment gate policy editors
|
||||
- release-context verdict page used by Release Orchestrator
|
||||
|
||||
## Release Orchestrator Integration
|
||||
|
||||
Release Orchestrator should link into this shell instead of growing a parallel policy UI.
|
||||
|
||||
### Entry points from releases
|
||||
- approval detail -> open gate verdict in release context mode
|
||||
- promotion request -> open readiness checklist in release context mode
|
||||
- release detail -> open effective policy + VEX posture for this artifact
|
||||
- workflow editor -> deep link to gate catalog / policy pack used by the workflow
|
||||
- evidence detail -> deep link to policy and VEX rationale bound to the promotion
|
||||
|
||||
### Required release-context panel
|
||||
- active release / approval identifier
|
||||
- environment lane
|
||||
- artifact digest / subject digest
|
||||
- effective policy pack and version
|
||||
- gate verdict summary
|
||||
- open conflicts or missing evidence
|
||||
- CTA back to release flow
|
||||
|
||||
### Ownership rule
|
||||
- Release Orchestrator owns promotion state and workflow execution
|
||||
- Decisioning Studio owns policy authoring, governance, VEX resolution, exceptions, and gate explanation
|
||||
|
||||
## UI Standards For Implementation
|
||||
|
||||
- One shell component with child router outlets, not duplicated top-level pages
|
||||
- Page-owned context and self-serve guidance
|
||||
- Stable deep links for every tab and subview
|
||||
- Scope-aware tabs that hide or disable only what the operator cannot act on
|
||||
- Shared evidence and explain cards reused across policy, VEX, and release contexts
|
||||
- Deterministic loading order and route aliases so legacy bookmarks remain functional during rollout
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not move all security exploration into this shell; read-only security analytics can remain elsewhere if they deep-link into the same canonical decisioning routes when action is required.
|
||||
- Do not let Release Orchestrator fork its own policy editor or VEX conflict UI.
|
||||
- Do not collapse everything into one scroll page; operators need stable, bookmarkable subviews.
|
||||
|
||||
## Source Inputs
|
||||
|
||||
- `docs/contracts/policy-studio.md`
|
||||
- `docs/security/policy-governance.md`
|
||||
- `docs/modules/release-orchestrator/ui/overview.md`
|
||||
- `docs/modules/release-orchestrator/workflow/evidence-based-release-gates.md`
|
||||
- `docs/modules/ui/component-preservation-map/README.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/policy-governance/policy-governance.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/policy-simulation/policy-simulation.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/vex-hub/vex-hub.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/ops.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/administration.routes.ts`
|
||||
188
docs/modules/ui/reachability-witnessing/README.md
Normal file
188
docs/modules/ui/reachability-witnessing/README.md
Normal file
@@ -0,0 +1,188 @@
|
||||
# Reachability Witnessing
|
||||
|
||||
## Recommendation
|
||||
|
||||
Restore witness and proof-of-exposure UX as a deeper part of `Security > Reachability`, not as a standalone product.
|
||||
|
||||
- Canonical mount: `/security/reachability`
|
||||
- Suggested user-facing title: `Reachability`
|
||||
- Supporting label inside the shell: `Witnesses & Proof`
|
||||
|
||||
This capability should strengthen security investigation, release gating, and evidence review through reusable witness detail pages and proof drawers.
|
||||
|
||||
## Why This Is The Right Shape
|
||||
|
||||
- `ReachabilityCenterComponent` already owns the top-level reachability posture.
|
||||
- `WitnessPageComponent` and `PoEDrawerComponent` are evidence and explanation layers of the same capability.
|
||||
- Reachability proof matters in findings, triage, policy/VEX decisions, and release gates, so it must be reusable from multiple contexts.
|
||||
- A single shell prevents proof UX from fragmenting across security, evidence, and release flows.
|
||||
|
||||
## Operator Modes
|
||||
|
||||
### 1. Coverage Review Mode
|
||||
- Used by security operators checking graph coverage, sensor freshness, and fleet posture.
|
||||
- Focus: `Coverage` and `Sensor Gaps`.
|
||||
|
||||
### 2. Investigation Mode
|
||||
- Used by analysts validating whether a vulnerable path is reachable and why.
|
||||
- Focus: `Witnesses` and `PoE / Exposure`.
|
||||
|
||||
### 3. Release Context Mode
|
||||
- Entered from release gates, policy/VEX decisions, or evidence review.
|
||||
- Focus: witness explanation, proof verification, and return-to-release navigation.
|
||||
|
||||
## Recommended IA
|
||||
|
||||
### Primary tabs
|
||||
- `Coverage`
|
||||
- fleet and package coverage, recent graph updates, confidence overview
|
||||
- `Witnesses`
|
||||
- searchable witness list and full witness detail page
|
||||
- `PoE / Exposure`
|
||||
- proof-of-exposure artifacts, export, verify, transparency status
|
||||
- `Sensor Gaps`
|
||||
- missing sensors, stale data, unresolved evidence dependencies
|
||||
|
||||
### Witness detail sections
|
||||
- summary
|
||||
- call path and gates
|
||||
- confidence and caveats
|
||||
- related findings and releases
|
||||
- evidence chain and export actions
|
||||
|
||||
## Page Anatomy
|
||||
|
||||
### Coverage tab
|
||||
- summary cards:
|
||||
- analyzed artifacts
|
||||
- coverage confidence
|
||||
- stale witness count
|
||||
- open gaps
|
||||
- tables or cards:
|
||||
- per-environment coverage
|
||||
- hot CVEs lacking proof
|
||||
|
||||
### Witnesses tab
|
||||
- list filters:
|
||||
- artifact
|
||||
- package
|
||||
- CVE
|
||||
- verdict
|
||||
- confidence
|
||||
- environment
|
||||
- row preview:
|
||||
- witness id
|
||||
- subject
|
||||
- vulnerability
|
||||
- verdict
|
||||
- confidence
|
||||
- last observed
|
||||
- witness detail page:
|
||||
- proof summary header
|
||||
- path explorer
|
||||
- gates and confidence
|
||||
- related evidence
|
||||
- replay/verify/export actions
|
||||
|
||||
### PoE / Exposure tab
|
||||
- proof list with status chips
|
||||
- right drawer for proof detail by default
|
||||
- optional permalink route for export and audit deep links
|
||||
|
||||
### Sensor Gaps tab
|
||||
- backlog queues for:
|
||||
- missing runtime signals
|
||||
- stale graph facts
|
||||
- unresolved symbol sources
|
||||
- missing environment bindings
|
||||
|
||||
## Route Contract
|
||||
|
||||
Keep one canonical route family under security reachability.
|
||||
|
||||
### Canonical routes
|
||||
- `/security/reachability`
|
||||
- `/security/reachability/coverage`
|
||||
- `/security/reachability/witnesses`
|
||||
- `/security/reachability/witnesses/:witnessId`
|
||||
- `/security/reachability/poe`
|
||||
- `/security/reachability/poe/:artifactId`
|
||||
- `/security/reachability/gaps`
|
||||
|
||||
### Query-param state
|
||||
- `tab=coverage|witnesses|poe|gaps`
|
||||
- `panel=poe|evidence|related`
|
||||
- `returnTo=<encoded route>` for findings, triage, evidence, or releases
|
||||
|
||||
### Alias rules
|
||||
- any future `evidence` or `release` entry points should deep-link here rather than mount duplicate witness pages
|
||||
|
||||
## What To Merge
|
||||
|
||||
### Merge into `Coverage`
|
||||
- `ReachabilityCenterComponent`
|
||||
|
||||
### Merge into `Witnesses`
|
||||
- `WitnessPageComponent`
|
||||
|
||||
### Merge into `PoE / Exposure`
|
||||
- `PoEDrawerComponent`
|
||||
|
||||
### Preserve as shared behaviors
|
||||
- export DOT and Mermaid actions
|
||||
- proof verification actions
|
||||
- evidence-chain cards
|
||||
|
||||
## Single Actions And Supporting Surfaces
|
||||
|
||||
### Witness detail
|
||||
- full page under `Witnesses`
|
||||
- preserve permalink and return-to-context behavior
|
||||
|
||||
### PoE detail
|
||||
- default to a right drawer from witness detail, finding detail, triage, or release context
|
||||
- allow a standalone route for exports and audit deep links
|
||||
|
||||
### Export or replay verify
|
||||
- keep as actions on witness or PoE detail
|
||||
- do not create separate pages per export type
|
||||
|
||||
### Related finding navigation
|
||||
- keep as contextual links in the witness detail sidebar
|
||||
|
||||
## Cross-Product Entry Points
|
||||
|
||||
- `Security > Findings`
|
||||
- open witness detail for a finding
|
||||
- `Triage > Artifact Workspace`
|
||||
- open witness or PoE from artifact detail
|
||||
- `Evidence > Verify & Replay`
|
||||
- open proof verification in the same witness/PoE model
|
||||
- `Decisioning Studio` or `Releases`
|
||||
- open witness and proof for gate verdict explanation
|
||||
|
||||
## UI Standards For Implementation
|
||||
|
||||
- Keep witness detail as the canonical deep-link target.
|
||||
- Default proof detail to a drawer to preserve investigation context.
|
||||
- Preserve return-to-context links so operators can move back to findings or release flows.
|
||||
- Reuse evidence cards and path visualizations across security, evidence, and release entry points.
|
||||
- Keep graph and proof loading deterministic and evidence-first.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not create a top-level `Witnessing` product.
|
||||
- Do not split coverage, witness, and proof UX across unrelated sidebar branches.
|
||||
- Do not leave PoE as a drawer with no canonical parent route.
|
||||
|
||||
## Source Inputs
|
||||
|
||||
- `docs/contracts/witness-v1.md`
|
||||
- `docs/architecture/EVIDENCE_PIPELINE_ARCHITECTURE.md`
|
||||
- `docs/modules/scanner/reachability.md`
|
||||
- `docs/modules/ui/architecture-rework.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`
|
||||
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.
|
||||
184
docs/modules/ui/triage-explainability-workspace/README.md
Normal file
184
docs/modules/ui/triage-explainability-workspace/README.md
Normal file
@@ -0,0 +1,184 @@
|
||||
# Triage Explainability Workspace
|
||||
|
||||
## Recommendation
|
||||
|
||||
Restore the useful triage workbench ideas by folding them into one canonical artifact workspace plus a sibling `Audit Bundles` page.
|
||||
|
||||
- Canonical list route: `/triage/artifacts`
|
||||
- Canonical detail route: `/triage/artifacts/:artifactId`
|
||||
- Sibling supporting page: `/triage/audit-bundles`
|
||||
- Suggested user-facing title: `Artifact Workspace`
|
||||
|
||||
This capability should improve the active triage loop without preserving separate workbench brands.
|
||||
|
||||
## Why This Is The Right Shape
|
||||
|
||||
- Quiet lane is fundamentally a queue segmentation pattern, not a product.
|
||||
- AI recommendations and reason capsules are detail-side decision aids.
|
||||
- Provenance and decision history belong next to the current artifact under review.
|
||||
- Audit bundles are real operator workflows, but still belong beside triage rather than as an isolated product.
|
||||
|
||||
## Operator Modes
|
||||
|
||||
### 1. Queue Management Mode
|
||||
- Used by operators deciding what to review now, later, or quietly.
|
||||
- Focus: list tabs and bulk actions.
|
||||
|
||||
### 2. Decision Workbench Mode
|
||||
- Used by analysts inside artifact detail.
|
||||
- Focus: evidence, explanation, recommendations, and verdict history.
|
||||
|
||||
### 3. Audit Packaging Mode
|
||||
- Used by auditors and operators preparing evidence bundles.
|
||||
- Focus: bundle creation, export, and traceability.
|
||||
|
||||
## Recommended IA
|
||||
|
||||
### Artifact Workspace layers
|
||||
- `List layer`
|
||||
- segmented by lane
|
||||
- `Detail layer`
|
||||
- current artifact workspace with contextual explainability panels
|
||||
|
||||
### List-layer tabs
|
||||
- `Active`
|
||||
- `Quiet Lane`
|
||||
- `Needs Review`
|
||||
|
||||
### Detail-layer panels or secondary tabs
|
||||
- `AI Recommendations`
|
||||
- `Reason Capsule`
|
||||
- `Provenance`
|
||||
- `Decision History`
|
||||
|
||||
### Sibling page
|
||||
- `Audit Bundles`
|
||||
- list, create, inspect, download
|
||||
|
||||
## Page Anatomy
|
||||
|
||||
### Artifact list page
|
||||
- top controls:
|
||||
- search
|
||||
- severity
|
||||
- reachability
|
||||
- VEX state
|
||||
- policy state
|
||||
- assignee
|
||||
- lane
|
||||
- list rows:
|
||||
- key risk facts
|
||||
- quick explanation summary
|
||||
- next recommended action
|
||||
- bulk actions:
|
||||
- move to quiet lane
|
||||
- promote for review
|
||||
- assign
|
||||
- build audit bundle
|
||||
|
||||
### Artifact detail page
|
||||
- center column:
|
||||
- artifact/finding summary
|
||||
- evidence trail
|
||||
- active decision controls
|
||||
- right rail or lower secondary tabs:
|
||||
- AI recommendations
|
||||
- reason capsule
|
||||
- provenance
|
||||
- decision history
|
||||
- contextual actions:
|
||||
- apply suggestion
|
||||
- request exception
|
||||
- open witness
|
||||
- export evidence
|
||||
|
||||
### Audit Bundles page
|
||||
- bundle list with scope, owner, created time, and status
|
||||
- create flow with artifact selection and evidence inclusion choices
|
||||
- download and verify actions
|
||||
|
||||
## Route Contract
|
||||
|
||||
Keep one route family for artifact workspace and one sibling route for audit bundles.
|
||||
|
||||
### Canonical routes
|
||||
- `/triage/artifacts`
|
||||
- `/triage/artifacts/:artifactId`
|
||||
- `/triage/audit-bundles`
|
||||
- `/triage/audit-bundles/new`
|
||||
|
||||
### Query-param state
|
||||
- `lane=active|quiet|review`
|
||||
- `panel=ai|reason|provenance|history`
|
||||
- `returnTo=<encoded route>` for security, evidence, or release-context entry points
|
||||
|
||||
### Alias rules
|
||||
- `Security > Artifacts` should use the same route family instead of owning a second triage workspace
|
||||
- any future exception or findings entry points should deep-link into the same artifact detail route
|
||||
|
||||
## What To Merge
|
||||
|
||||
### Merge into list layer
|
||||
- `QuietLaneWorkbenchComponent`
|
||||
|
||||
### Merge into detail layer
|
||||
- `AiRecommendationWorkbenchComponent`
|
||||
- `ReasonCapsuleWorkbenchComponent`
|
||||
- `AiCodeGuardBadgeComponent`
|
||||
- `SnapshotViewerComponent`
|
||||
- `UnknownsListComponent`
|
||||
|
||||
### Keep as real sibling page
|
||||
- `TriageAuditBundlesComponent`
|
||||
- `TriageAuditBundleNewComponent`
|
||||
|
||||
## Single Actions And Supporting Surfaces
|
||||
|
||||
### Apply AI suggestion
|
||||
- keep inside artifact detail
|
||||
- do not create a dedicated route
|
||||
|
||||
### Reason capsule
|
||||
- keep as a contextual panel or secondary tab
|
||||
- never separate it from the active decision context
|
||||
|
||||
### Quiet-lane promote, snooze, or TTL extend
|
||||
- keep as row or bulk actions in the list view
|
||||
|
||||
### Audit-bundle creation
|
||||
- allow a dedicated new route because it has a multi-step operator flow
|
||||
|
||||
## Cross-Product Entry Points
|
||||
|
||||
- `Security > Findings`
|
||||
- deep-link into artifact detail with `panel=reason` or `panel=provenance`
|
||||
- `Evidence`
|
||||
- link to `Audit Bundles` and artifact evidence panels
|
||||
- `Reachability`
|
||||
- open witness drawers from artifact detail
|
||||
- `Decisioning Studio`
|
||||
- deep-link into the artifact decision context when a policy verdict needs human review
|
||||
|
||||
## UI Standards For Implementation
|
||||
|
||||
- Keep list and detail behaviors in one coherent workspace.
|
||||
- Use lane tabs or segmented controls rather than separate pages for queue modes.
|
||||
- Use stable query-param panel state for explainability surfaces.
|
||||
- Preserve evidence-first decision making; AI is advisory, never opaque.
|
||||
- Keep audit packaging as a real page because it has lifecycle and exports.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not preserve `AI Recommendation Workbench` or `Reason Capsule Workbench` as standalone brands.
|
||||
- Do not move quiet-lane logic to a separate product shell.
|
||||
- Do not scatter audit, evidence, and explainability flows across different owners.
|
||||
|
||||
## Source 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`
|
||||
179
docs/modules/ui/watchlist-operations/README.md
Normal file
179
docs/modules/ui/watchlist-operations/README.md
Normal file
@@ -0,0 +1,179 @@
|
||||
# Identity Watchlist
|
||||
|
||||
## Recommendation
|
||||
|
||||
Restore Watchlist as a narrow operational shell owned by `Setup > Trust & Signing`, not as a standalone top-level product.
|
||||
|
||||
- Canonical mount: `/setup/trust-signing/watchlist`
|
||||
- Suggested user-facing title: `Identity Watchlist`
|
||||
- Suggested nav label: `Watchlist`
|
||||
|
||||
This capability is primarily about trust policy administration around signer identities, with alert outcomes surfaced into `Mission Control` and `Ops > Notifications`.
|
||||
|
||||
## Why This Is The Right Shape
|
||||
|
||||
- The current implementation already supports CRUD, pattern testing, scope, severity, deduplication, and alert history.
|
||||
- Those are configuration and trust-governance behaviors, not a broad cross-product workspace.
|
||||
- The supporting runbook and Attestor guide describe watchlist as an operator control around identities and alerting hygiene.
|
||||
- The best product shape is one owned shell with secondary visibility in alert-centric surfaces.
|
||||
|
||||
## Operator Modes
|
||||
|
||||
### 1. Tenant Trust Mode
|
||||
- Used by tenant operators tuning their own issuer, SAN, or key-id watch rules.
|
||||
- Focus: entries, scopes, severity, enable/disable, and match testing.
|
||||
|
||||
### 2. Platform Trust Admin Mode
|
||||
- Used by system admins managing global and system-scoped entries.
|
||||
- Focus: global coverage, noisy patterns, dedup performance, and notification routing.
|
||||
|
||||
### 3. Incident Triage Mode
|
||||
- Entered from `Mission Control > Alerts` or `Ops > Notifications`.
|
||||
- Focus: alert detail, matched identity context, and jumping back into the owning watchlist rule.
|
||||
|
||||
## Recommended IA
|
||||
|
||||
### Primary tabs
|
||||
- `Entries`
|
||||
- list, filter, create, edit, enable/disable, delete, and test matching rules
|
||||
- `Alerts`
|
||||
- recent watchlist alerts, alert severity, tenant/source context, and jump-to-entry actions
|
||||
- `Tuning`
|
||||
- dedup windows, notification channels, alert volume controls, and performance guidance
|
||||
|
||||
### Header context
|
||||
- scope switcher: `Tenant`, `Global`, `System`
|
||||
- summary chips:
|
||||
- enabled entries
|
||||
- alerts last 24h
|
||||
- suppression ratio
|
||||
- scan latency p99
|
||||
|
||||
## Page Anatomy
|
||||
|
||||
### Entries tab
|
||||
- left: searchable/filterable table with scope, match mode, severity, enabled state, and recent-match count
|
||||
- right: split detail panel or drawer for create/edit
|
||||
- row actions:
|
||||
- enable/disable
|
||||
- edit
|
||||
- duplicate
|
||||
- delete
|
||||
- test pattern
|
||||
|
||||
### Alerts tab
|
||||
- top filters:
|
||||
- severity
|
||||
- time window
|
||||
- scope
|
||||
- tenant
|
||||
- suppression state
|
||||
- main list:
|
||||
- alert time
|
||||
- matched entry
|
||||
- signer identity
|
||||
- source channel
|
||||
- dedup status
|
||||
- detail drawer:
|
||||
- raw match context
|
||||
- related entry
|
||||
- recent similar alerts
|
||||
- jump to Mission Control or Notifications if needed
|
||||
|
||||
### Tuning tab
|
||||
- cards for:
|
||||
- dedup effectiveness
|
||||
- scan latency
|
||||
- top noisy rules
|
||||
- notification channel health
|
||||
- forms for:
|
||||
- default dedup window
|
||||
- per-severity channel overrides
|
||||
- alert storm guidance
|
||||
|
||||
## Route Contract
|
||||
|
||||
Keep one canonical route family under trust/signing setup.
|
||||
|
||||
### Canonical routes
|
||||
- `/setup/trust-signing/watchlist`
|
||||
- `/setup/trust-signing/watchlist/entries`
|
||||
- `/setup/trust-signing/watchlist/alerts`
|
||||
- `/setup/trust-signing/watchlist/tuning`
|
||||
|
||||
### Query-param state
|
||||
- `tab=entries|alerts|tuning`
|
||||
- `scope=tenant|global|system`
|
||||
- `entryId=<id>` for opening the edit drawer
|
||||
- `alertId=<id>` for opening the alert detail drawer
|
||||
- `returnTo=<encoded route>` when entered from Mission Control or Notifications
|
||||
|
||||
### Alias and entry rules
|
||||
- `Mission Control > Alerts` should deep-link into `?tab=alerts&alertId=...`
|
||||
- `Ops > Notifications` should deep-link into `?tab=tuning`
|
||||
- no separate sidebar product or parallel route family should exist
|
||||
|
||||
## What To Merge
|
||||
|
||||
### Merge into `Entries`
|
||||
- `WatchlistPageComponent` list mode
|
||||
- existing create/edit form
|
||||
- existing pattern test behavior
|
||||
|
||||
### Merge into `Alerts`
|
||||
- `WatchlistPageComponent` alert table and alert drill-down behavior
|
||||
|
||||
### Merge into `Tuning`
|
||||
- duplicate-suppression controls
|
||||
- notification behavior controls
|
||||
- runbook-driven KPIs and tuning guidance
|
||||
|
||||
## Single Actions And Supporting Surfaces
|
||||
|
||||
### Create or edit rule
|
||||
- use a drawer or split detail panel inside `Entries`
|
||||
- add a standalone route only if audit/history requires a permalink
|
||||
|
||||
### Test pattern
|
||||
- keep inside the edit experience
|
||||
- never give it a dedicated page
|
||||
|
||||
### Alert detail
|
||||
- open as a drawer from `Alerts`
|
||||
- preserve deep links via `alertId`
|
||||
|
||||
### Dedup diagnostics
|
||||
- keep in `Tuning`
|
||||
- optionally expose summary KPIs in `Ops > Notifications`
|
||||
|
||||
## Cross-Product Entry Points
|
||||
|
||||
- `Mission Control > Alerts`
|
||||
- watchlist source chip opens the `Alerts` tab
|
||||
- `Ops > Notifications`
|
||||
- channel health card links to `Tuning`
|
||||
- `Security` or `Evidence` surfaces
|
||||
- only deep-link to alert detail when a signer-identity event matters to an investigation
|
||||
|
||||
## UI Standards For Implementation
|
||||
|
||||
- Use one shell component with tabbed child routes or stable tab state.
|
||||
- Preserve scope awareness in header and filters.
|
||||
- Support list/detail without forcing route churn for every edit.
|
||||
- Keep alert outcomes visible in mission/notification surfaces without duplicating the configuration shell.
|
||||
- Preserve deterministic sort order for entries and alerts.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not make Watchlist a top-level sidebar product.
|
||||
- Do not split configuration and alert history across different owner areas.
|
||||
- Do not move trust ownership into Mission Control.
|
||||
|
||||
## Source 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`
|
||||
169
docs/modules/ui/workflow-visualization-replay/README.md
Normal file
169
docs/modules/ui/workflow-visualization-replay/README.md
Normal file
@@ -0,0 +1,169 @@
|
||||
# Workflow Visualization And Replay
|
||||
|
||||
## Recommendation
|
||||
|
||||
Restore workflow graphing, time-travel, and replay as a run-detail capability under `Releases`, with a secondary entry point from `Evidence > Verify & Replay`.
|
||||
|
||||
- Canonical mount: `/releases/runs/:runId`
|
||||
- Suggested user-facing title in the run view: `Run Graph & Replay`
|
||||
- Secondary entry point: `/evidence/verify-replay`
|
||||
|
||||
This capability should help operators understand what happened in a release run, why a run failed or slowed, and how evidence or replay confirms the outcome.
|
||||
|
||||
## Why This Is The Right Shape
|
||||
|
||||
- The abandoned visualizer models runtime concepts such as graph state, auto-refresh, step detail, critical path, and time travel.
|
||||
- Those concepts belong to a run-detail experience, not to a standalone sidebar product.
|
||||
- Evidence replay already exists as a live route, so the missing piece is a better run-context shell and shared graph vocabulary.
|
||||
- Workflow authoring still benefits from a graph preview, but runtime analysis must remain primary.
|
||||
|
||||
## Operator Modes
|
||||
|
||||
### 1. Release Operator Mode
|
||||
- Used from `Releases > Runs`.
|
||||
- Focus: graph, timeline, failure diagnosis, and replay.
|
||||
|
||||
### 2. Evidence Verification Mode
|
||||
- Used from `Evidence > Verify & Replay`.
|
||||
- Focus: deterministic replay, drift comparison, and proof verification.
|
||||
|
||||
### 3. Authoring Preview Mode
|
||||
- Used from workflow editor.
|
||||
- Focus: DAG preview only, without runtime telemetry or replay state.
|
||||
|
||||
## Recommended IA
|
||||
|
||||
### Release run detail tabs
|
||||
- `Summary`
|
||||
- `Graph`
|
||||
- `Timeline`
|
||||
- `Critical Path`
|
||||
- `Replay`
|
||||
- `Evidence`
|
||||
|
||||
### Supporting surfaces
|
||||
- step detail drawer from graph and timeline
|
||||
- replay toolbar in `Replay`
|
||||
- evidence rail in `Evidence`
|
||||
|
||||
## Page Anatomy
|
||||
|
||||
### Graph tab
|
||||
- run status header with current stage and outcome
|
||||
- DAG visualization with node status, duration, retries, and blockers
|
||||
- filters:
|
||||
- failed only
|
||||
- critical path only
|
||||
- environment
|
||||
- job type
|
||||
- step detail drawer on selection
|
||||
|
||||
### Timeline tab
|
||||
- chronological execution lane view
|
||||
- time-travel controls in the toolbar
|
||||
- jump from timeline event to graph node
|
||||
|
||||
### Critical Path tab
|
||||
- optimized read of the longest or blocking path
|
||||
- compare actual versus expected duration
|
||||
|
||||
### Replay tab
|
||||
- replay status
|
||||
- replay inputs and pinned hashes
|
||||
- drift comparison and output match
|
||||
- link to evidence export or proof replay details
|
||||
|
||||
### Evidence tab
|
||||
- attached evidence bundles
|
||||
- gate decisions
|
||||
- relevant witnesses and proofs
|
||||
- export shortcuts
|
||||
|
||||
## Route Contract
|
||||
|
||||
Keep the current `releases/runs` route family and deepen it with stable tabs.
|
||||
|
||||
### Canonical routes
|
||||
- `/releases/runs/:runId`
|
||||
- `/releases/runs/:runId/summary`
|
||||
- `/releases/runs/:runId/graph`
|
||||
- `/releases/runs/:runId/timeline`
|
||||
- `/releases/runs/:runId/critical-path`
|
||||
- `/releases/runs/:runId/replay`
|
||||
- `/releases/runs/:runId/evidence`
|
||||
- `/evidence/verify-replay?runId=:runId`
|
||||
- `/administration/workflows/:workflowId?view=preview`
|
||||
|
||||
### Query-param state
|
||||
- `step=<stepId>` to open the step drawer
|
||||
- `returnTo=<encoded route>` when entering from evidence or approvals
|
||||
|
||||
### Alias rules
|
||||
- any legacy `workflow-visualization/*` route should redirect into the run-detail tab family
|
||||
|
||||
## What To Merge
|
||||
|
||||
### Merge into runtime run detail
|
||||
- `WorkflowVisualizerComponent`
|
||||
- `TimeTravelControlsComponent`
|
||||
- `StepDetailPanelComponent`
|
||||
|
||||
### Reuse in authoring preview
|
||||
- graph-only subset of `WorkflowVisualizerComponent`
|
||||
|
||||
### Integrate with existing evidence replay
|
||||
- `ReplayControlsComponent`
|
||||
- proof replay surfaces where they overlap with deterministic verification
|
||||
|
||||
## Single Actions And Supporting Surfaces
|
||||
|
||||
### Step detail
|
||||
- right drawer by default
|
||||
- add a full route only if failed-step diagnostics need durable shareable URLs beyond `step=<id>`
|
||||
|
||||
### Time-travel controls
|
||||
- toolbar actions in `Timeline` or `Replay`
|
||||
- never a separate page
|
||||
|
||||
### Critical-path focus
|
||||
- its own tab or a persistent graph mode
|
||||
- not a sidebar product
|
||||
|
||||
### Replay verify
|
||||
- primary home in `Replay`
|
||||
- secondary entry point from `Evidence > Verify & Replay`
|
||||
|
||||
## Cross-Product Entry Points
|
||||
|
||||
- `Releases > Approvals`
|
||||
- deep-link into run detail when an approval is waiting on a blocked step
|
||||
- `Evidence > Verify & Replay`
|
||||
- open the same replay context with run id preselected
|
||||
- `Decisioning Studio`
|
||||
- open run evidence or gate proof when policy blocks a promotion
|
||||
- `Administration > Workflows`
|
||||
- show authoring-time preview without runtime state
|
||||
|
||||
## UI Standards For Implementation
|
||||
|
||||
- Treat graph, timeline, critical path, replay, and evidence as one coherent run-detail experience.
|
||||
- Preserve stable tab and step deep links.
|
||||
- Keep replay evidence visible and comparable to the original run outcome.
|
||||
- Avoid mixing authoring preview with live telemetry.
|
||||
- Reuse graph components between runtime and authoring only where the semantics stay clear.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not create a standalone `Workflow Visualization` sidebar item.
|
||||
- Do not split graph and replay into different owner shells.
|
||||
- Do not make workflow editor the primary home of runtime troubleshooting.
|
||||
|
||||
## Source 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`
|
||||
Reference in New Issue
Block a user