diff --git a/docs/implplan/SPRINT_20260307_009_DOCS_ui_component_preservation_map.md b/docs/implplan/SPRINT_20260307_009_DOCS_ui_component_preservation_map.md index 5e8539fd9..0c206b9da 100644 --- a/docs/implplan/SPRINT_20260307_009_DOCS_ui_component_preservation_map.md +++ b/docs/implplan/SPRINT_20260307_009_DOCS_ui_component_preservation_map.md @@ -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. diff --git a/docs/implplan/SPRINT_20260307_022_FE_policy_vex_release_decisioning_studio.md b/docs/implplan/SPRINT_20260307_022_FE_policy_vex_release_decisioning_studio.md new file mode 100644 index 000000000..dafe8a1b8 --- /dev/null +++ b/docs/implplan/SPRINT_20260307_022_FE_policy_vex_release_decisioning_studio.md @@ -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. diff --git a/docs/implplan/SPRINT_20260307_023_DOCS_ui_restoration_topic_shapes.md b/docs/implplan/SPRINT_20260307_023_DOCS_ui_restoration_topic_shapes.md new file mode 100644 index 000000000..e8374e760 --- /dev/null +++ b/docs/implplan/SPRINT_20260307_023_DOCS_ui_restoration_topic_shapes.md @@ -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. diff --git a/docs/implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md b/docs/implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md new file mode 100644 index 000000000..c85168b18 --- /dev/null +++ b/docs/implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md @@ -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. diff --git a/docs/implplan/SPRINT_20260307_025_FE_reachability_witnessing_merge.md b/docs/implplan/SPRINT_20260307_025_FE_reachability_witnessing_merge.md new file mode 100644 index 000000000..e4caadd7d --- /dev/null +++ b/docs/implplan/SPRINT_20260307_025_FE_reachability_witnessing_merge.md @@ -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. diff --git a/docs/implplan/SPRINT_20260307_026_FE_platform_ops_consolidation.md b/docs/implplan/SPRINT_20260307_026_FE_platform_ops_consolidation.md new file mode 100644 index 000000000..99deb8379 --- /dev/null +++ b/docs/implplan/SPRINT_20260307_026_FE_platform_ops_consolidation.md @@ -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. diff --git a/docs/implplan/SPRINT_20260307_027_FE_triage_explainability_workspace.md b/docs/implplan/SPRINT_20260307_027_FE_triage_explainability_workspace.md new file mode 100644 index 000000000..d27ac9a9c --- /dev/null +++ b/docs/implplan/SPRINT_20260307_027_FE_triage_explainability_workspace.md @@ -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. diff --git a/docs/implplan/SPRINT_20260307_028_FE_workflow_visualization_replay.md b/docs/implplan/SPRINT_20260307_028_FE_workflow_visualization_replay.md new file mode 100644 index 000000000..f2a291a25 --- /dev/null +++ b/docs/implplan/SPRINT_20260307_028_FE_workflow_visualization_replay.md @@ -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=` 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=` 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. diff --git a/docs/implplan/SPRINT_20260307_029_FE_contextual_actions_and_stray_surfaces.md b/docs/implplan/SPRINT_20260307_029_FE_contextual_actions_and_stray_surfaces.md new file mode 100644 index 000000000..7415169ef --- /dev/null +++ b/docs/implplan/SPRINT_20260307_029_FE_contextual_actions_and_stray_surfaces.md @@ -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. diff --git a/docs/modules/ui/README.md b/docs/modules/ui/README.md index 49c77ddef..59e5ae2ae 100644 --- a/docs/modules/ui/README.md +++ b/docs/modules/ui/README.md @@ -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). diff --git a/docs/modules/ui/TASKS.md b/docs/modules/ui/TASKS.md index 9c8dea7f2..8561fa03b 100644 --- a/docs/modules/ui/TASKS.md +++ b/docs/modules/ui/TASKS.md @@ -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 diff --git a/docs/modules/ui/component-preservation-map/README.md b/docs/modules/ui/component-preservation-map/README.md index 3a7849e44..1e88fc43e 100644 --- a/docs/modules/ui/component-preservation-map/README.md +++ b/docs/modules/ui/component-preservation-map/README.md @@ -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/`. diff --git a/docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md b/docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md new file mode 100644 index 000000000..feb5718be --- /dev/null +++ b/docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md @@ -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`. diff --git a/docs/modules/ui/contextual-actions-patterns/README.md b/docs/modules/ui/contextual-actions-patterns/README.md new file mode 100644 index 000000000..636ff388f --- /dev/null +++ b/docs/modules/ui/contextual-actions-patterns/README.md @@ -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=` +- `panel=` +- `drawer=` +- `returnTo=` +- `scope=` +- `view=` + +### 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` diff --git a/docs/modules/ui/implementation_plan.md b/docs/modules/ui/implementation_plan.md index 3bc2bc6c1..f9d635bb9 100644 --- a/docs/modules/ui/implementation_plan.md +++ b/docs/modules/ui/implementation_plan.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` diff --git a/docs/modules/ui/platform-ops-consolidation/README.md b/docs/modules/ui/platform-ops-consolidation/README.md new file mode 100644 index 000000000..56b2531d7 --- /dev/null +++ b/docs/modules/ui/platform-ops-consolidation/README.md @@ -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` diff --git a/docs/modules/ui/policy-decisioning-studio/README.md b/docs/modules/ui/policy-decisioning-studio/README.md new file mode 100644 index 000000000..15fda3c33 --- /dev/null +++ b/docs/modules/ui/policy-decisioning-studio/README.md @@ -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` diff --git a/docs/modules/ui/reachability-witnessing/README.md b/docs/modules/ui/reachability-witnessing/README.md new file mode 100644 index 000000000..783806d01 --- /dev/null +++ b/docs/modules/ui/reachability-witnessing/README.md @@ -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=` 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` diff --git a/docs/modules/ui/restoration-topics/README.md b/docs/modules/ui/restoration-topics/README.md new file mode 100644 index 000000000..6e965b3ff --- /dev/null +++ b/docs/modules/ui/restoration-topics/README.md @@ -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) diff --git a/docs/modules/ui/restoration-topics/platform-ops-consolidation.md b/docs/modules/ui/restoration-topics/platform-ops-consolidation.md new file mode 100644 index 000000000..c355ca8bf --- /dev/null +++ b/docs/modules/ui/restoration-topics/platform-ops-consolidation.md @@ -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. diff --git a/docs/modules/ui/restoration-topics/reachability-witnessing.md b/docs/modules/ui/restoration-topics/reachability-witnessing.md new file mode 100644 index 000000000..72ac2823e --- /dev/null +++ b/docs/modules/ui/restoration-topics/reachability-witnessing.md @@ -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. diff --git a/docs/modules/ui/restoration-topics/triage-explainability-workbench.md b/docs/modules/ui/restoration-topics/triage-explainability-workbench.md new file mode 100644 index 000000000..601ee4cb9 --- /dev/null +++ b/docs/modules/ui/restoration-topics/triage-explainability-workbench.md @@ -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. diff --git a/docs/modules/ui/restoration-topics/watchlist.md b/docs/modules/ui/restoration-topics/watchlist.md new file mode 100644 index 000000000..9da385aef --- /dev/null +++ b/docs/modules/ui/restoration-topics/watchlist.md @@ -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`. diff --git a/docs/modules/ui/restoration-topics/workflow-visualization-and-replay.md b/docs/modules/ui/restoration-topics/workflow-visualization-and-replay.md new file mode 100644 index 000000000..38aaf365d --- /dev/null +++ b/docs/modules/ui/restoration-topics/workflow-visualization-and-replay.md @@ -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. diff --git a/docs/modules/ui/triage-explainability-workspace/README.md b/docs/modules/ui/triage-explainability-workspace/README.md new file mode 100644 index 000000000..169147f06 --- /dev/null +++ b/docs/modules/ui/triage-explainability-workspace/README.md @@ -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=` 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` diff --git a/docs/modules/ui/watchlist-operations/README.md b/docs/modules/ui/watchlist-operations/README.md new file mode 100644 index 000000000..cae404773 --- /dev/null +++ b/docs/modules/ui/watchlist-operations/README.md @@ -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=` for opening the edit drawer +- `alertId=` for opening the alert detail drawer +- `returnTo=` 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` diff --git a/docs/modules/ui/workflow-visualization-replay/README.md b/docs/modules/ui/workflow-visualization-replay/README.md new file mode 100644 index 000000000..7791d29c1 --- /dev/null +++ b/docs/modules/ui/workflow-visualization-replay/README.md @@ -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=` to open the step drawer +- `returnTo=` 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=` + +### 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`