docs(ui): map restoration topics and delivery sprints
This commit is contained in:
master
@@ -78,11 +78,25 @@ Completion criteria:
|
||||
- [ ] Ambiguous components are reduced to a smaller explicit investigate set.
|
||||
- [ ] Final keep/merge/wire recommendations can be defended against current product documentation.
|
||||
|
||||
### DOCS-UCM-005 - Restoration priority backlog
|
||||
Status: DONE
|
||||
Dependency: DOCS-UCM-003
|
||||
Owners: Documentation author, Project Manager
|
||||
Task description:
|
||||
- Convert the branch-level preservation map into an ordered restoration backlog.
|
||||
- Distinguish true restoration work from merge work, wire-in work, and likely retirement.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Ordered backlog exists for dropped and weakly surfaced functionality.
|
||||
- [x] Merge candidates are grouped into product-level topics instead of raw branch names only.
|
||||
- [x] The backlog is linked from the preservation-map root index.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created for a multi-iteration preservation map of unused and weakly surfaced UI components. | Project Manager |
|
||||
| 2026-03-07 | Generated first-pass preservation map artifacts under `docs/modules/ui/component-preservation-map/`: root index, summary tree, deterministic inventory, 303 component dossiers, and 89 branch indexes. | Documentation author |
|
||||
| 2026-03-07 | Added `RESTORATION_PRIORITIES.md` to rank dropped-functionality restoration topics by confidence and to distinguish merge candidates from wire-in and retirement work. | Documentation author |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: first iteration will prioritize a complete map and first-pass judgment over exhaustive historical certainty.
|
||||
|
||||
@@ -0,0 +1,147 @@
|
||||
# Sprint 20260307-022 - Policy VEX Release Decisioning Studio
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate Policy Studio, Policy Governance, Policy Simulation, and actionable VEX decisioning into one canonical sub-product shell for the Console.
|
||||
- Ship a fully wired `/ops/policy` experience with working routes, tabs, legacy redirects, release-context deep links, and no orphan mutable policy or VEX shells.
|
||||
- Complete the usable operator workflows for packs, governance, simulation, VEX conflicts, exceptions, release gates, and audit rather than stopping at merge or routing notes.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/routes/`, `docs/modules/ui/policy-decisioning-studio`, `docs/implplan/`, `docs/modules/ui/TASKS.md`, and `docs/modules/ui/implementation_plan.md`.
|
||||
- Expected evidence: code under `src/Web/**`, routable `/ops/policy` shell, working alias redirects, release-context entry points, targeted tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/contracts/policy-studio.md`
|
||||
- `docs/security/policy-governance.md`
|
||||
- `docs/modules/release-orchestrator/ui/overview.md`
|
||||
- `docs/modules/release-orchestrator/workflow/evidence-based-release-gates.md`
|
||||
- `docs/modules/ui/component-preservation-map/README.md`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/ops.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/administration.routes.ts`
|
||||
- Safe parallelism:
|
||||
- shell scaffolding and alias wiring can proceed in parallel with tab-by-tab migration once the canonical route family is fixed
|
||||
- packs/governance and simulation/VEX work can proceed in parallel after shared shell context is in place
|
||||
- release-context entry points and docs sync can proceed in parallel with tab implementation once ownership boundaries are stable
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/policy-decisioning-studio/README.md`
|
||||
- `docs/contracts/policy-studio.md`
|
||||
- `docs/security/policy-governance.md`
|
||||
- `docs/modules/release-orchestrator/ui/overview.md`
|
||||
- `docs/modules/release-orchestrator/workflow/evidence-based-release-gates.md`
|
||||
- `docs/modules/ui/component-preservation-map/SUMMARY_TREE.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-PD-001 - Build the canonical `/ops/policy` shell
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Implement the shell component, primary tabs, shared context header, and nav entry under the canonical `/ops/policy` root.
|
||||
- Make the shell usable in global, pack, and release-context modes from the first shipped route.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] `/ops/policy` renders as the canonical shell with working top-level navigation.
|
||||
- [ ] Primary tabs and shared context header are wired in code.
|
||||
- [ ] Release-context mode can be entered without creating a separate product shell.
|
||||
|
||||
### FE-PD-002 - Migrate routes and legacy aliases into the new tree
|
||||
Status: TODO
|
||||
Dependency: FE-PD-001
|
||||
Owners: FE Architect, Documentation author
|
||||
Task description:
|
||||
- Implement the canonical route tree for packs, governance, simulation, VEX, exceptions, release gates, and audit under `/ops/policy`.
|
||||
- Wire redirects from `/policy-studio/*`, `/admin/policy/*`, and `/admin/vex-hub/*` so old entry points land on usable new pages.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Canonical child routes exist in the active router.
|
||||
- [ ] Legacy aliases redirect into working `/ops/policy` subviews.
|
||||
- [ ] No mutable policy or VEX workflow remains dependent on an orphan route.
|
||||
|
||||
### FE-PD-003 - Ship Packs and Governance functionality
|
||||
Status: TODO
|
||||
Dependency: FE-PD-002
|
||||
Owners: FE Architect, Documentation author
|
||||
Task description:
|
||||
- Migrate the policy pack workspace, editor, YAML, rule builder, approvals, explain flows, and governance controls into the new shell.
|
||||
- Ensure these flows remain usable, not just reachable, after the shell cutover.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Packs and Governance tabs are functional under `/ops/policy`.
|
||||
- [ ] Editing, approvals, governance settings, and explain flows are usable from the new shell.
|
||||
- [ ] Superseded pack and governance shells can be retired or redirected after cutover.
|
||||
|
||||
### FE-PD-004 - Ship Simulation, VEX, Exceptions, Gates, and Audit functionality
|
||||
Status: TODO
|
||||
Dependency: FE-PD-001
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Migrate simulation flows, VEX conflict handling, exceptions, release gates, and audit history into the same shell.
|
||||
- Ensure operators can complete the key workflows from the new tabs without falling back to dead or duplicate screens.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Simulation, VEX, Exceptions, Release Gates, and Audit tabs are functional under `/ops/policy`.
|
||||
- [ ] Conflict resolution, exception handling, and gate review are usable from the new shell.
|
||||
- [ ] Old mutable VEX and policy action pages are no longer required for those workflows.
|
||||
|
||||
### FE-PD-005 - Wire Release Orchestrator into Decisioning Studio
|
||||
Status: TODO
|
||||
Dependency: FE-PD-002
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement deep links from approvals, promotion requests, release detail, workflow editor, and evidence detail into release-context mode.
|
||||
- Keep Release Orchestrator as the owner of release state while Decisioning Studio owns policy and VEX actions.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Release-context entry points are wired from active release surfaces.
|
||||
- [ ] Release-context header shows the required release, environment, artifact, and gate state.
|
||||
- [ ] Operators can return to the release workflow after taking policy or VEX actions.
|
||||
|
||||
### FE-PD-006 - Verify cutover, redirects, and core operator journeys
|
||||
Status: TODO
|
||||
Dependency: FE-PD-005
|
||||
Owners: QA, Test Automation
|
||||
Task description:
|
||||
- Add targeted UI verification for global mode, pack mode, and release-context mode, including old bookmarks and alias redirects.
|
||||
- Validate that the new shell is the working owner for the core operator journeys, not just a shell around dead components.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Playwright scenarios cover all three shell modes.
|
||||
- [ ] Legacy aliases and old bookmarks land on usable new pages.
|
||||
- [ ] Scope-based visibility and the main policy/VEX operator journeys are explicitly verified.
|
||||
|
||||
### FE-PD-007 - Complete docs sync and retire superseded shells
|
||||
Status: TODO
|
||||
Dependency: FE-PD-003
|
||||
Owners: Documentation author, Project Manager
|
||||
Task description:
|
||||
- Update UI, security, and release docs to reflect the new canonical shell and the cutover state.
|
||||
- Record which legacy names remain as temporary aliases and which old product shells are fully retired after the move.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Cross-doc references are updated for the shipped shell.
|
||||
- [ ] User-facing naming and alias lifetimes are documented.
|
||||
- [ ] Retired sibling-product labels and routes are explicitly listed after cutover.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship a single Decisioning Studio shell spanning policy authoring, governance, simulation, actionable VEX resolution, and release-context gate explanation. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: the preferred product shape is one dynamic shell with deep-linkable tabs, not one giant page and not separate sibling products.
|
||||
- Decision: Release Orchestrator remains the owner of promotion state; the new shell owns policy, VEX, exception, and gate explanation workflows.
|
||||
- Decision: `/ops/policy` is the preferred canonical root because it already exists in the active route tree and best fits the "policy as an ops control plane" model.
|
||||
- Risk: moving all VEX screens under Policy could bury read-only security exploration use cases that still belong in Analyze.
|
||||
- Mitigation: allow Analyze entry points to deep-link into the same canonical VEX tab or a read-only shell mode instead of preserving a separate mutable VEX product.
|
||||
- Risk: legacy aliases across `/policy-studio/*`, `/administration/policy/*`, and `/admin/vex-hub/*` can silently fragment analytics and QA coverage.
|
||||
- Mitigation: freeze redirects and verification scenarios before implementation starts.
|
||||
- Risk: Release Orchestrator could grow duplicate gate/policy UI while this consolidation is in flight.
|
||||
- Mitigation: require release-facing FE work to deep-link into the shared shell rather than add new standalone policy/VEX pages.
|
||||
- Delivery rule: this sprint is only complete when the canonical shell is routable, usable, verified, and old mutable policy or VEX action paths are no longer required.
|
||||
- Reference design note: `docs/modules/ui/policy-decisioning-studio/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm the canonical shell name, tab set, and ownership boundary.
|
||||
- 2026-03-09: freeze the route contract and component merge matrix.
|
||||
- 2026-03-10: finalize release-context UX contract and implementation slice plan.
|
||||
@@ -0,0 +1,137 @@
|
||||
# Sprint 20260307-023 - UI Restoration Topic Shapes
|
||||
|
||||
## Topic & Scope
|
||||
- Convert the highest-confidence restoration topics after Decisioning Studio into concrete product-shape notes.
|
||||
- For each topic, define whether it should be a submenu, tabbed shell, contextual drawer, or reusable detail page.
|
||||
- Explicitly place stray pages and single actions into the active Stella Ops IA instead of reviving orphan products.
|
||||
- This is a documentation prerequisite sprint only; it does not count as shipping the restored functionality by itself.
|
||||
- Working directory: `docs/modules/ui/restoration-topics`.
|
||||
- Allowed coordination edits: `docs/implplan/`, `docs/modules/ui/TASKS.md`, `docs/modules/ui/implementation_plan.md`, and `docs/modules/ui/component-preservation-map/README.md`.
|
||||
- Expected evidence: restoration topic index, five topic notes, placement rules, and cross-links from the preservation map.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
- `docs/modules/ui/component-preservation-map/SUMMARY_TREE.md`
|
||||
- `docs/modules/ui/policy-decisioning-studio/README.md`
|
||||
- active route trees under `src/Web/StellaOps.Web/src/app/routes/`
|
||||
- Safe parallelism:
|
||||
- each restoration-topic note can be authored independently after the shared placement rules are clear
|
||||
- future implementation sprints can be split per topic once these shapes are accepted
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
- `docs/modules/ui/component-preservation-map/README.md`
|
||||
- `docs/modules/ui/policy-decisioning-studio/README.md`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/mission-control.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/security-risk.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/operations.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/releases.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/evidence.routes.ts`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### DOCS-RTS-001 - Restoration topic index and placement rules
|
||||
Status: DONE
|
||||
Dependency: none
|
||||
Owners: Documentation author, Project Manager
|
||||
Task description:
|
||||
- Create the restoration-topics doc tree with an index and shared placement rules for stray pages, actions, drawers, and submenus.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Topic index exists.
|
||||
- [x] Placement matrix exists.
|
||||
- [x] Shared placement rules are documented.
|
||||
|
||||
### DOCS-RTS-002 - Watchlist placement note
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-001
|
||||
Owners: Documentation author, Product Manager
|
||||
Task description:
|
||||
- Define whether Watchlist belongs in Mission Control, Ops, or Setup, and specify how configuration versus alerts should be surfaced.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Primary owner area is defined.
|
||||
- [x] Tabs and route sketch are defined.
|
||||
- [x] Secondary placements for alerts and notifications are documented.
|
||||
|
||||
### DOCS-RTS-003 - Reachability witnessing placement note
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-001
|
||||
Owners: Documentation author, Product Manager
|
||||
Task description:
|
||||
- Define how witness and PoE surfaces merge into Reachability, Security, and release/evidence flows.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Primary security placement is defined.
|
||||
- [x] Witness vs PoE page/drawer ownership is documented.
|
||||
- [x] Secondary deep-link entry points are listed.
|
||||
|
||||
### DOCS-RTS-004 - Platform Ops consolidation note
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-001
|
||||
Owners: Documentation author, FE Architect
|
||||
Task description:
|
||||
- Define how legacy Platform Ops pages fold into the active Ops shell and where stray tools like agent fleet should live.
|
||||
|
||||
Completion criteria:
|
||||
- [x] One-shell decision is documented.
|
||||
- [x] Grouped submenu structure is documented.
|
||||
- [x] Duplication boundaries with Setup are documented.
|
||||
|
||||
### DOCS-RTS-005 - Triage explainability placement note
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-001
|
||||
Owners: Documentation author, Product Manager
|
||||
Task description:
|
||||
- Define how quiet lane, AI recommendations, reason capsules, provenance, and audit bundles fit into the active triage flow.
|
||||
|
||||
Completion criteria:
|
||||
- [x] List-level lane placement is defined.
|
||||
- [x] Detail-level explainability placement is defined.
|
||||
- [x] Audit bundles page ownership is defined.
|
||||
|
||||
### DOCS-RTS-006 - Workflow visualization and replay placement note
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-001
|
||||
Owners: Documentation author, FE Architect
|
||||
Task description:
|
||||
- Define where runtime workflow graphing, time travel, replay, and step-detail views live in Releases, Evidence, and workflow authoring.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Primary home in release runs is documented.
|
||||
- [x] Evidence-side and workflow-editor secondary placements are documented.
|
||||
- [x] Graph/timeline/replay tab structure is defined.
|
||||
|
||||
### DOCS-RTS-007 - Deeper corroboration against module dossiers
|
||||
Status: DONE
|
||||
Dependency: DOCS-RTS-002
|
||||
Owners: Documentation author, Product Manager
|
||||
Task description:
|
||||
- Validate each topic shape against the owning module dossiers and convert accepted shapes into implementation sprints.
|
||||
|
||||
Completion criteria:
|
||||
- [x] Watchlist, reachability, ops, triage, and workflow-visualization topic notes each have corroborating module-doc links.
|
||||
- [x] Accepted topic shapes are translated into implementation-ready frontend or product sprints.
|
||||
- [x] Rejected or downgraded topics are reflected back into the restoration backlog.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to shape the next restoration topics after Decisioning Studio into concrete shell/menu/tab recommendations. | Project Manager |
|
||||
| 2026-03-07 | Authored topic-shape notes for Watchlist, Reachability Witnessing, Platform Ops Consolidation, Triage Explainability Workbench, and Workflow Visualization And Replay. | Documentation author |
|
||||
| 2026-03-07 | Added corroborating module-doc links to each restoration topic note and cut implementation-ready FE sprints plus detailed UX dossiers for the accepted topics. | Documentation author |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: these topics should be expressed as restorations of capability into existing shells, not revivals of abandoned product brands.
|
||||
- Decision: single actions and narrow supporting UX should default to tabs, drawers, right-rail panels, or submenus instead of new top-level products.
|
||||
- Decision: completion of this docs sprint is not sufficient for product delivery; the FE sprints must still ship and verify the mounted functionality.
|
||||
- Risk: some topics, especially Watchlist and Workflow Visualization, touch more than one owning domain.
|
||||
- Mitigation: document primary ownership plus secondary entry points explicitly so implementation does not fork the capability.
|
||||
- Risk: legacy route shapes may bias the placement toward old IA instead of current Stella Ops structure.
|
||||
- Mitigation: place each topic against the active route tree first and treat legacy routes as migration aliases only.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm whether the proposed placement of Watchlist under Trust & Signing is accepted.
|
||||
- 2026-03-09: decide whether Reachability Witnessing and Workflow Visualization move directly to FE implementation planning.
|
||||
- 2026-03-10: cut implementation sprints for the accepted Tier 1 and Tier 2 restoration topics.
|
||||
128
docs/implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md
Normal file
128
docs/implplan/SPRINT_20260307_024_FE_identity_watchlist_shell.md
Normal file
@@ -0,0 +1,128 @@
|
||||
# Sprint 20260307-024 - Identity Watchlist Shell
|
||||
|
||||
## Topic & Scope
|
||||
- Restore the dropped identity watchlist capability as a trust-owned operational shell under `Setup > Trust & Signing`.
|
||||
- Ship a fully usable watchlist with working entries, alerts, tuning, and deep-link behavior rather than leaving it as an unmounted page.
|
||||
- Complete route wiring, menu exposure, cross-shell alert surfacing, and operator workflows end to end.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features/watchlist`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/routes/`, `src/Web/StellaOps.Web/src/app/features/mission-control/`, `src/Web/StellaOps.Web/src/app/features/notify/`, `docs/modules/ui/watchlist-operations`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: routed and menu-visible watchlist shell, working CRUD and alert flows, cross-shell deep links, targeted tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/watchlist-operations/README.md`
|
||||
- `docs/modules/attestor/guides/identity-watchlist.md`
|
||||
- `docs/operations/watchlist-monitoring-runbook.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/watchlist/watchlist-page.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/mission-control.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/operations.routes.ts`
|
||||
- Safe parallelism:
|
||||
- route and ownership decisions should freeze before implementation starts
|
||||
- `Entries`, `Alerts`, and `Tuning` can be implemented in parallel after the shell and query-param contract are stable
|
||||
- Mission Control and Notifications deep links can proceed in parallel with shell implementation
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/watchlist-operations/README.md`
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/watchlist.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-WL-001 - Wire the canonical watchlist shell into Setup
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Add the canonical route family and menu entry under `Setup > Trust & Signing`.
|
||||
- Make the shell routable and usable with working tab navigation and scope-aware header behavior.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Watchlist is reachable from the active shell navigation.
|
||||
- [ ] Canonical routes and tab behavior are wired in code.
|
||||
- [ ] Scope-aware header behavior works from the mounted shell.
|
||||
|
||||
### FE-WL-002 - Ship the Entries workflow
|
||||
Status: TODO
|
||||
Dependency: FE-WL-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the `Entries` tab as a working list/detail experience using the existing watchlist client.
|
||||
- Ensure operators can create, edit, duplicate, enable/disable, delete, and test matching rules from the mounted shell.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Entry CRUD flows work from the mounted shell.
|
||||
- [ ] Edit/create uses a contextual panel or drawer instead of a detached page.
|
||||
- [ ] Pattern test is wired and usable within the entry-editing flow.
|
||||
|
||||
### FE-WL-003 - Ship the Alerts workflow
|
||||
Status: TODO
|
||||
Dependency: FE-WL-001
|
||||
Owners: Developer, Product Manager
|
||||
Task description:
|
||||
- Implement the `Alerts` tab with filters, ordering, alert-detail drawer behavior, and jump-to-entry actions.
|
||||
- Make alert-detail deep links work from Mission Control and back into the owning watchlist rule.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Alert listing and filtering work in the mounted shell.
|
||||
- [ ] Alert-detail drawer shows the required context and actions.
|
||||
- [ ] Operators can jump between alert detail and the owning watchlist entry.
|
||||
|
||||
### FE-WL-004 - Ship tuning and diagnostics
|
||||
Status: TODO
|
||||
Dependency: FE-WL-001
|
||||
Owners: Developer, Documentation author
|
||||
Task description:
|
||||
- Implement the `Tuning` tab with dedup controls, notification behavior, top noisy rules, and performance/volume KPIs.
|
||||
- Align the shipped tab with the operational runbook so the page is usable for real operator tuning.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Dedup and channel controls are wired into the page.
|
||||
- [ ] Operational KPI cards render in the mounted shell.
|
||||
- [ ] Tuning guidance matches the operational runbook terminology.
|
||||
|
||||
### FE-WL-005 - Wire Mission Control and Notifications entry points
|
||||
Status: TODO
|
||||
Dependency: FE-WL-003
|
||||
Owners: FE Architect, Developer
|
||||
Task description:
|
||||
- Wire watchlist-origin alert chips, links, and `returnTo` behavior from `Mission Control > Alerts` and `Ops > Notifications`.
|
||||
- Ensure those surfaces expose outcomes only and send operators into the canonical watchlist shell for action.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Mission Control links open the working watchlist alerts flow.
|
||||
- [ ] Notifications links open tuning or alert views in the canonical shell.
|
||||
- [ ] `returnTo` behavior preserves operator context across shells.
|
||||
|
||||
### FE-WL-006 - Verify, document, and cut over the feature
|
||||
Status: TODO
|
||||
Dependency: FE-WL-002
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add targeted UI verification for tenant/global/system scope, entries CRUD, alerts drill-in, tuning, and Mission Control deep links.
|
||||
- Update docs and cutover notes so Watchlist is treated as a shipped feature, not an orphan page.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Playwright scenarios cover entries, alerts, and tuning.
|
||||
- [ ] Scope-sensitive behaviors are explicitly verified.
|
||||
- [ ] Docs and rollout notes reflect the mounted and usable feature.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship Watchlist as a Trust & Signing-owned shell with working entries, alerts, tuning, and secondary surfacing in Mission Control and Notifications. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: Watchlist belongs under `Setup > Trust & Signing`, with alert visibility surfaced elsewhere.
|
||||
- Decision: configuration and alert history remain in one shell; they should not be split into separate products.
|
||||
- Risk: Mission Control may try to absorb watchlist because it already owns alerts.
|
||||
- Mitigation: freeze the ownership boundary and only allow alert-source chips and deep links from Mission Control.
|
||||
- Risk: scope handling across tenant, global, and system rules can create hidden permissions complexity.
|
||||
- Mitigation: require scope-aware header behavior and QA coverage before rollout.
|
||||
- Delivery rule: this sprint is only complete when Watchlist is visible in navigation, usable end to end, and its key alert and tuning workflows are verified.
|
||||
- Reference design note: `docs/modules/ui/watchlist-operations/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm owner shell, tab set, and deep-link behavior.
|
||||
- 2026-03-09: freeze entries, alerts, and tuning implementation slices.
|
||||
- 2026-03-10: finalize QA and rollout contract.
|
||||
@@ -0,0 +1,130 @@
|
||||
# Sprint 20260307-025 - Reachability Witnessing Merge
|
||||
|
||||
## Topic & Scope
|
||||
- Restore witness and proof-of-exposure UX as a deeper part of `Security > Reachability`.
|
||||
- Ship fully usable witness and proof flows with working routes, drawers, exports, and cross-links from findings, triage, evidence, and release contexts.
|
||||
- Complete the missing functionality so operators can actually inspect, verify, and navigate reachability proof rather than just reach routed placeholders.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features/reachability`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/routes/`, `src/Web/StellaOps.Web/src/app/features/security-risk/`, `src/Web/StellaOps.Web/src/app/features/triage/`, `docs/modules/ui/reachability-witnessing`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: mounted reachability tabs, working witness detail pages, working PoE drawer/permalink behavior, cross-shell deep links, targeted tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/reachability-witnessing/README.md`
|
||||
- `docs/contracts/witness-v1.md`
|
||||
- `docs/architecture/EVIDENCE_PIPELINE_ARCHITECTURE.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/reachability/reachability-center.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/reachability/witness-page.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/reachability/poe-drawer.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/security-risk.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/evidence.routes.ts`
|
||||
- Safe parallelism:
|
||||
- tab and route contract work should finish before FE implementation begins
|
||||
- witness list/detail and PoE drawer work can proceed in parallel once the route contract is stable
|
||||
- cross-product deep-link work can proceed in parallel with shell implementation
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/reachability-witnessing/README.md`
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/reachability-witnessing.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-RW-001 - Wire reachability witness routes and tabs into the active shell
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Add the `Coverage`, `Witnesses`, `PoE / Exposure`, and `Sensor Gaps` flows to the active reachability shell.
|
||||
- Make the canonical routes and panel behavior work in the live router.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Reachability remains the canonical owner shell in the live router.
|
||||
- [ ] Witness and PoE routes are wired and reachable.
|
||||
- [ ] Tab and panel state work in code, not only in docs.
|
||||
|
||||
### FE-RW-002 - Ship the Witnesses list and witness-detail page
|
||||
Status: TODO
|
||||
Dependency: FE-RW-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the searchable `Witnesses` tab and the full witness detail page using the existing reachability and witness APIs.
|
||||
- Ensure the detail page includes path, confidence, related evidence, and export or verify actions.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Witness listing and filters are usable from the mounted shell.
|
||||
- [ ] Witness detail renders the required investigation sections.
|
||||
- [ ] Export and verify actions work from witness detail.
|
||||
|
||||
### FE-RW-003 - Ship PoE detail as drawer-first UX with permalink support
|
||||
Status: TODO
|
||||
Dependency: FE-RW-001
|
||||
Owners: Developer, Product Manager
|
||||
Task description:
|
||||
- Implement proof-of-exposure detail as a contextual drawer by default, with a permalink route for export and audit use cases.
|
||||
- Make PoE open from witness detail and other owning workflows without creating a second proof product.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] PoE drawer is usable from witness detail and other entry points.
|
||||
- [ ] Permalink route works for direct proof access.
|
||||
- [ ] Operators can inspect proof without leaving the owning workflow unless they choose to.
|
||||
|
||||
### FE-RW-004 - Wire findings, triage, evidence, and release deep links
|
||||
Status: TODO
|
||||
Dependency: FE-RW-002
|
||||
Owners: FE Architect, Developer
|
||||
Task description:
|
||||
- Implement deep links from `Security > Findings`, `Triage > Artifact Workspace`, `Evidence > Verify & Replay`, and release-context decisioning flows.
|
||||
- Preserve `returnTo` navigation so witness and PoE inspection does not strand the operator away from the original workflow.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Findings, triage, evidence, and release entry points open the working reachability UX.
|
||||
- [ ] `returnTo` behavior preserves the original workflow context.
|
||||
- [ ] No duplicate witness pages are required outside the reachability shell.
|
||||
|
||||
### FE-RW-005 - Complete exports, evidence cards, and proof actions
|
||||
Status: TODO
|
||||
Dependency: FE-RW-003
|
||||
Owners: Developer, Documentation author
|
||||
Task description:
|
||||
- Implement DOT, Mermaid, replay verify, and evidence-chain actions in witness and PoE detail.
|
||||
- Align labels and affordances so exported proof remains understandable across security, evidence, and release workflows.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Export and verify actions are usable in the shipped UI.
|
||||
- [ ] Evidence-chain and proof summary cards render in the shipped UI.
|
||||
- [ ] Terminology is aligned across the related docs and pages.
|
||||
|
||||
### FE-RW-006 - Verify, document, and cut over the feature
|
||||
Status: TODO
|
||||
Dependency: FE-RW-004
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add Playwright scenarios for the reachability shell, witness detail, PoE drawer, export actions, and cross-shell deep links.
|
||||
- Update reachability and evidence docs so this ships as a usable feature, not a documented merge target only.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] UI verification covers shell tabs, witness detail, and PoE detail.
|
||||
- [ ] Cross-shell deep links and proof actions are included in verification.
|
||||
- [ ] Docs reflect the mounted and usable feature.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship witness and proof-of-exposure UX as deeper reachability functionality with reusable witness detail pages and PoE drawers across security, triage, evidence, and release flows. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: `Security > Reachability` remains the owner shell for witness and proof UX.
|
||||
- Decision: witness detail is a full page; PoE is a drawer first and a permalink route second.
|
||||
- Risk: evidence and release teams may create parallel proof views during implementation.
|
||||
- Mitigation: freeze deep-link and return-to-context rules before FE work begins.
|
||||
- Risk: proof terminology may drift between reachability, evidence, and decisioning docs.
|
||||
- Mitigation: align labels and actions to the reachability UX dossier before implementation starts.
|
||||
- Delivery rule: this sprint is only complete when witness and PoE flows are mounted, usable from their primary and secondary entry points, and verified end to end.
|
||||
- Reference design note: `docs/modules/ui/reachability-witnessing/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm shell tabs and witness versus PoE ownership boundaries.
|
||||
- 2026-03-09: freeze witness detail, PoE drawer, and deep-link contracts.
|
||||
- 2026-03-10: finalize QA and rollout contract.
|
||||
@@ -0,0 +1,128 @@
|
||||
# Sprint 20260307-026 - Platform Ops Consolidation
|
||||
|
||||
## Topic & Scope
|
||||
- Consolidate legacy `platform-ops` ideas into one canonical `Ops > Operations` shell.
|
||||
- Ship a fully usable consolidated Operations shell with a working overview, child routes, legacy redirects, and absorbed high-value widgets from the old surfaces.
|
||||
- Complete the missing operator functionality in the active shell instead of merely cataloging or grouping old pages.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features/platform`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/features/platform-ops/`, `src/Web/StellaOps.Web/src/app/routes/operations.routes.ts`, `src/Web/StellaOps.Web/src/app/features/aoc-compliance/`, `docs/modules/ui/platform-ops-consolidation`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: active Operations overview and child routes, absorbed legacy widgets, working redirects, targeted tests, and updated operator docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/platform-ops-consolidation/README.md`
|
||||
- `docs/UI_GUIDE.md`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/operations.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/platform/ops/platform-ops-overview-page.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/platform-ops/platform-ops-overview.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/aoc-compliance/aoc-compliance.routes.ts`
|
||||
- Safe parallelism:
|
||||
- overview taxonomy and child-route labeling should freeze before widget implementation begins
|
||||
- grouped overview cards and route cleanup can proceed in parallel once taxonomy is stable
|
||||
- Setup boundary work can proceed in parallel with legacy widget absorption
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/platform-ops-consolidation/README.md`
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/platform-ops-consolidation.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-PO-001 - Rebuild the Operations overview and submenu in the live shell
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Implement the grouped overview taxonomy and submenu structure in the active `Ops > Operations` shell.
|
||||
- Ensure the overview and submenu expose the real operator concerns rather than leaving them as a paper design.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] The live shell exposes the intended overview groups and submenu entries.
|
||||
- [ ] Overview group labels and child-route labels are wired in code.
|
||||
- [ ] No parallel `platform-ops` owner tree is required for operator access.
|
||||
|
||||
### FE-PO-002 - Ship the overview page and grouped blocking cards
|
||||
Status: TODO
|
||||
Dependency: FE-PO-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the overview page with blocking strip, grouped cards, trend summaries, and single-target drill-ins.
|
||||
- Make the overview page usable as the real operator landing page rather than a placeholder around child routes.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Blocking strip renders the required signals in the live shell.
|
||||
- [ ] Grouped cards route into working child pages.
|
||||
- [ ] Overview sections follow one consistent shipped pattern.
|
||||
|
||||
### FE-PO-003 - Absorb high-value legacy widgets and pages
|
||||
Status: TODO
|
||||
Dependency: FE-PO-001
|
||||
Owners: Developer, Documentation author
|
||||
Task description:
|
||||
- Migrate the high-value legacy `platform-ops` widgets and pages into the overview or the correct child routes.
|
||||
- Retire only the obsolete duplicates after the missing operational functionality is actually present in the live shell.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] High-value legacy widgets are visible in the active shell or child routes.
|
||||
- [ ] Missing operational views are actually shipped into target pages.
|
||||
- [ ] Only genuinely duplicated legacy routes remain candidates for retirement.
|
||||
|
||||
### FE-PO-004 - Cut over routes and legacy aliases
|
||||
Status: TODO
|
||||
Dependency: FE-PO-001
|
||||
Owners: FE Architect, Developer
|
||||
Task description:
|
||||
- Implement canonical `/ops/operations/*` paths, legacy alias redirects, and route-label consistency.
|
||||
- Ensure old bookmarks and legacy route trees redirect into working pages without reviving a second shell.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Canonical route family is active in the router.
|
||||
- [ ] Legacy aliases redirect into working operations pages.
|
||||
- [ ] Sidebar, overview cards, and breadcrumb labels match in the shipped shell.
|
||||
|
||||
### FE-PO-005 - Complete Setup boundary and topology deep links
|
||||
Status: TODO
|
||||
Dependency: FE-PO-002
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Implement the boundary between operations monitoring and setup ownership, especially for agent fleet and topology concerns.
|
||||
- Wire deep links between `Ops > Operations` and `Setup > Topology` where operators need to cross that boundary.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Agent fleet and topology ownership remain under Setup in the live UI.
|
||||
- [ ] Operations-to-Setup deep links work from shipped pages.
|
||||
- [ ] No duplicated topology management remains exposed under Ops.
|
||||
|
||||
### FE-PO-006 - Verify, document, and cut over the consolidated shell
|
||||
Status: TODO
|
||||
Dependency: FE-PO-004
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add Playwright scenarios for the operations overview, grouped cards, child-route drill-ins, and legacy alias redirects.
|
||||
- Update UI docs and operational runbooks so the consolidated shell ships as the usable owner surface.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Verification covers overview groups and target routes.
|
||||
- [ ] Legacy alias redirects are included in testing.
|
||||
- [ ] Docs reflect the consolidated and shipped owner shell.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship a consolidated Operations shell with grouped overview cards, stable child routes, legacy-widget absorption, and explicit Setup boundaries. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: `Ops > Operations` remains the one operator shell; legacy `platform-ops` becomes migration input only.
|
||||
- Decision: overview cards should be grouped by operator concern, not by backend service naming alone.
|
||||
- Risk: useful legacy widgets may be dropped if the merge matrix is shallow.
|
||||
- Mitigation: require a legacy widget absorption matrix before implementation begins.
|
||||
- Risk: topology and agent-fleet concerns may leak back into Ops ownership.
|
||||
- Mitigation: freeze Setup boundaries and cross-links explicitly.
|
||||
- Delivery rule: this sprint is only complete when the consolidated Operations shell is the usable owner surface and legacy pages are no longer needed for the restored operator workflows.
|
||||
- Reference design note: `docs/modules/ui/platform-ops-consolidation/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm one-shell decision, overview groups, and Setup boundary.
|
||||
- 2026-03-09: freeze overview card contract and legacy merge matrix.
|
||||
- 2026-03-10: finalize route cleanup and QA contract.
|
||||
@@ -0,0 +1,129 @@
|
||||
# Sprint 20260307-027 - Triage Explainability Workspace
|
||||
|
||||
## Topic & Scope
|
||||
- Merge the dropped triage workbench ideas into one canonical artifact workspace plus a sibling `Audit Bundles` page.
|
||||
- Ship a fully usable artifact workspace with lane segmentation, detail-side explainability panels, and a working `Audit Bundles` page.
|
||||
- Complete the missing triage functionality end to end so the operator can actually use quiet lane, explanation panels, and audit packaging from the active shell.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features/triage`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/routes/security-risk.routes.ts`, `src/Web/StellaOps.Web/src/app/features/security-risk/`, `src/Web/StellaOps.Web/src/app/features/evidence/`, `docs/modules/ui/triage-explainability-workspace`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: working lane tabs, working detail-side explainability panels, working audit-bundle flows, migrated supporting components, tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/triage-explainability-workspace/README.md`
|
||||
- `docs/UI_GUIDE.md`
|
||||
- `docs/ui-analysis/03_TRIAGE_POLICY_OPS_SCREENS.md`
|
||||
- `docs/ui-analysis/05_ROUTE_SUMMARY_AND_OBSERVATIONS.md`
|
||||
- `src/Web/StellaOps.Web/src/app/features/triage/triage-artifacts.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/triage/triage-workspace.component.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/triage/triage-audit-bundles.component.ts`
|
||||
- Safe parallelism:
|
||||
- route, lane, and panel contracts should freeze before FE implementation begins
|
||||
- list-lane work and detail-panel work can proceed in parallel after the contract is stable
|
||||
- audit-bundle page work can proceed in parallel with supporting component absorption
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/triage-explainability-workspace/README.md`
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/triage-explainability-workbench.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-TX-001 - Wire the canonical artifact workspace and route state
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Implement the canonical artifact workspace route family, lane query params, panel query params, and sibling `Audit Bundles` page ownership.
|
||||
- Ensure the active shell exposes the triage workspace operators should actually use.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Canonical artifact and audit-bundle routes are active in the router.
|
||||
- [ ] Lane and panel query params work in the shipped UI.
|
||||
- [ ] Separate workbench brands are no longer required for triage access.
|
||||
|
||||
### FE-TX-002 - Ship the list-lane workflows
|
||||
Status: TODO
|
||||
Dependency: FE-TX-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the list-layer experience for `Active`, `Quiet Lane`, and `Needs Review`.
|
||||
- Ensure row actions, bulk actions, and lane transitions are usable from the active artifact list.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Lane tabs or segmented controls are working in the shipped UI.
|
||||
- [ ] Row and bulk actions work from the artifact list.
|
||||
- [ ] Quiet-lane behavior is usable as queue state, not a detached page.
|
||||
|
||||
### FE-TX-003 - Ship the detail-side explainability workspace
|
||||
Status: TODO
|
||||
Dependency: FE-TX-001
|
||||
Owners: Developer, Product Manager
|
||||
Task description:
|
||||
- Implement artifact detail panels for AI recommendations, reason capsule, provenance, and decision history.
|
||||
- Make them usable beside the central artifact summary and evidence trail instead of leaving them as unmounted workbench ideas.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Detail-side panels render and open via the active workspace route state.
|
||||
- [ ] Panel actions and return-to-context behavior work in the shipped UI.
|
||||
- [ ] AI remains advisory and evidence-first in the shipped detail experience.
|
||||
|
||||
### FE-TX-004 - Ship the Audit Bundles page and create flow
|
||||
Status: TODO
|
||||
Dependency: FE-TX-001
|
||||
Owners: Developer, Documentation author
|
||||
Task description:
|
||||
- Implement the `Audit Bundles` list, create flow, and download/verify behavior as a real sibling page.
|
||||
- Ensure operators can build and retrieve audit bundles from the active triage and evidence flows.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Bundle list and create flow are usable in the shipped UI.
|
||||
- [ ] Cross-links from artifact detail and evidence open the working page.
|
||||
- [ ] Audit bundles remain a visible sibling page, not a hidden modal flow.
|
||||
|
||||
### FE-TX-005 - Migrate supporting components and retire workbench wrappers
|
||||
Status: TODO
|
||||
Dependency: FE-TX-003
|
||||
Owners: Developer, Documentation author
|
||||
Task description:
|
||||
- Migrate dropped triage components such as quiet lane workbench, AI recommendation workbench, reason capsule, snapshot viewer, unknowns list, and AI badge into the target workspace.
|
||||
- Retire wrapper shells only after their preserved behavior is working in the active artifact workspace.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Supporting components are visible in the working list or detail surfaces.
|
||||
- [ ] Wrapper shells slated for retirement are no longer needed for preserved behavior.
|
||||
- [ ] No preserved triage functionality depends on an orphan workbench route.
|
||||
|
||||
### FE-TX-006 - Verify, document, and cut over the workspace
|
||||
Status: TODO
|
||||
Dependency: FE-TX-004
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add Playwright scenarios for list-lane navigation, detail panels, cross-links to reachability and evidence, and audit-bundle creation.
|
||||
- Update triage and UI docs so the artifact workspace ships as the usable owner of these workflows.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Verification covers lane changes, detail panels, and audit bundles.
|
||||
- [ ] Cross-shell deep links are included in testing.
|
||||
- [ ] Docs reflect the shipped artifact workspace and audit-bundle flows.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship one artifact workspace with lane segmentation, detail-side explainability, and a sibling Audit Bundles page instead of keeping those capabilities in dropped workbench shells. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: triage stays one workspace with contextual explainability, not multiple workbench brands.
|
||||
- Decision: audit bundles remain a real page because they carry lifecycle, export, and audit semantics.
|
||||
- Risk: AI recommendation UI may expand beyond advisory use and obscure evidence-first operator decisions.
|
||||
- Mitigation: require explicit advisory-only copy and evidence panels in the detail contract.
|
||||
- Risk: quiet-lane behavior may get over-specialized into another shell.
|
||||
- Mitigation: freeze it as list segmentation plus row or bulk actions only.
|
||||
- Delivery rule: this sprint is only complete when the active triage workspace provides the preserved explainability and audit workflows without depending on orphan workbench pages.
|
||||
- Reference design note: `docs/modules/ui/triage-explainability-workspace/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm lane model, detail-side panel set, and Audit Bundles ownership.
|
||||
- 2026-03-09: freeze supporting component merge matrix and route/query contract.
|
||||
- 2026-03-10: finalize QA and rollout contract.
|
||||
@@ -0,0 +1,129 @@
|
||||
# Sprint 20260307-028 - Workflow Visualization Replay
|
||||
|
||||
## Topic & Scope
|
||||
- Restore workflow graphing, timeline, critical-path, and replay UX as a run-detail capability under `Releases > Runs`, with a secondary entry point from `Evidence > Verify & Replay`.
|
||||
- Ship fully usable runtime graphing, timeline, critical-path, replay, and evidence views from the active run-detail experience.
|
||||
- Complete the missing functionality end to end so operators can inspect run structure, drill into steps, replay evidence, and use legacy links without falling back to dead routes.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/features/workflow-visualization`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/routes/releases.routes.ts`, `src/Web/StellaOps.Web/src/app/routes/evidence.routes.ts`, `src/Web/StellaOps.Web/src/app/features/release-orchestrator/`, `docs/modules/ui/workflow-visualization-replay`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: working run-detail tabs, working step drawer and replay flows, evidence-side entry points, working legacy redirects, tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/workflow-visualization-replay/README.md`
|
||||
- `docs/modules/release-orchestrator/ui/overview.md`
|
||||
- `docs/modules/release-orchestrator/workflow/evidence-based-release-gates.md`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/releases.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/routes/evidence.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/workflow-visualization/workflow-visualization.routes.ts`
|
||||
- `src/Web/StellaOps.Web/src/app/features/workflow-visualization/components/workflow-visualizer/workflow-visualizer.component.ts`
|
||||
- Safe parallelism:
|
||||
- tab and route contract work should freeze before FE implementation begins
|
||||
- graph/timeline and replay/evidence work can proceed in parallel after the contract is stable
|
||||
- workflow-editor preview work can proceed in parallel with runtime integration once reuse boundaries are frozen
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/workflow-visualization-replay/README.md`
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/workflow-visualization-and-replay.md`
|
||||
- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-WV-001 - Wire run-detail tabs into Releases and Evidence
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: Product Manager, FE Architect
|
||||
Task description:
|
||||
- Implement the run-detail tab family under `Releases > Runs` and the shared replay entry point from `Evidence > Verify & Replay`.
|
||||
- Ensure operators can reach the graph and replay experience from the active shells.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Canonical run-detail tabs are active in the router.
|
||||
- [ ] Runtime graph and replay routes are mounted and reachable.
|
||||
- [ ] Evidence-side entry points open the working runtime context.
|
||||
|
||||
### FE-WV-002 - Ship the Graph, Timeline, and Critical Path tabs
|
||||
Status: TODO
|
||||
Dependency: FE-WV-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the runtime graph, timeline, and critical-path experiences with filters, node status, and drill-in behavior.
|
||||
- Ensure these tabs are usable for real run diagnosis, not just visual placeholders.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Graph, timeline, and critical-path tabs render with working filters and node metadata.
|
||||
- [ ] Operators can diagnose run state from the shipped tabs.
|
||||
- [ ] Step selection opens the working detail drawer.
|
||||
|
||||
### FE-WV-003 - Ship Replay and Evidence integration
|
||||
Status: TODO
|
||||
Dependency: FE-WV-001
|
||||
Owners: Developer, Product Manager
|
||||
Task description:
|
||||
- Implement the `Replay` tab with replay status, input hashes, drift comparison, and evidence links.
|
||||
- Integrate the existing evidence replay controls and proof replay surfaces into the active run-detail shell.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Replay tab works from the active run-detail shell.
|
||||
- [ ] Existing evidence replay controls are usable from the new tab model.
|
||||
- [ ] Evidence and Replay tabs both expose their intended workflows in the shipped UI.
|
||||
|
||||
### FE-WV-004 - Ship step-detail drill-in and deep-link behavior
|
||||
Status: TODO
|
||||
Dependency: FE-WV-002
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Implement the step-detail drawer, its fields, actions, and `step=<id>` deep-link behavior.
|
||||
- Ensure failed-step drill-ins work from graph and timeline views without losing run context.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Step-detail drawer works from graph and timeline tabs.
|
||||
- [ ] `step=<id>` deep-link behavior is usable and shareable.
|
||||
- [ ] Any required full-route escalation is implemented only where necessary.
|
||||
|
||||
### FE-WV-005 - Implement bounded workflow-editor preview reuse
|
||||
Status: TODO
|
||||
Dependency: FE-WV-001
|
||||
Owners: FE Architect, Developer
|
||||
Task description:
|
||||
- Implement the graph-only preview mode workflow editor can reuse without importing runtime replay semantics.
|
||||
- Keep authoring preview clearly separate from live run telemetry and troubleshooting.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Workflow editor can render the bounded preview mode.
|
||||
- [ ] Runtime-only behaviors are excluded from preview.
|
||||
- [ ] Shared and runtime-only graph components are separated in the shipped implementation.
|
||||
|
||||
### FE-WV-006 - Verify, redirect, and document the shipped capability
|
||||
Status: TODO
|
||||
Dependency: FE-WV-003
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add Playwright scenarios for run-detail tabs, step drawer behavior, evidence entry points, and legacy alias redirects.
|
||||
- Update release and evidence docs so workflow visualization and replay ship as a usable capability, not just a merge target.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Verification covers graph, timeline, replay, and evidence tabs.
|
||||
- [ ] Step deep links and alias redirects are included in testing.
|
||||
- [ ] Docs reflect the shipped run-detail and replay capability.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship workflow graphing and replay as a run-detail capability under Releases, with evidence-side entry points and a bounded authoring preview reuse model. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: runtime workflow visualization is owned by `Releases > Runs`, not by a standalone product.
|
||||
- Decision: `Evidence > Verify & Replay` becomes a secondary entry point into the same replay model.
|
||||
- Risk: runtime and authoring semantics may get mixed in one component tree and confuse operators.
|
||||
- Mitigation: freeze a strict preview versus runtime boundary before implementation begins.
|
||||
- Risk: replay controls already living in evidence routes may diverge from the run-detail experience.
|
||||
- Mitigation: require one shared route and tab model for replay semantics.
|
||||
- Delivery rule: this sprint is only complete when release operators can use the mounted graph, timeline, replay, and evidence flows without depending on the dead workflow-visualization branch.
|
||||
- Reference design note: `docs/modules/ui/workflow-visualization-replay/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm runtime ownership, tab model, and evidence entry-point rules.
|
||||
- 2026-03-09: freeze graph/timeline/replay slices and step-drawer contract.
|
||||
- 2026-03-10: finalize authoring preview boundary, alias migration, and QA contract.
|
||||
@@ -0,0 +1,129 @@
|
||||
# Sprint 20260307-029 - Contextual Actions And Stray Surfaces
|
||||
|
||||
## Topic & Scope
|
||||
- Define and implement the shared FE interaction contract for functionality that should become a submenu, tab, segmented queue mode, drawer, or full detail page instead of a new top-level product.
|
||||
- Build the reusable drawer, right-rail, split-view, context-header, and overview-card primitives needed by the restoration sprints.
|
||||
- Adopt those primitives into the shipped restoration features so this sprint delivers working UI infrastructure, not just another contract document.
|
||||
- Working directory: `src/Web/StellaOps.Web/src/app/shared`.
|
||||
- Allowed coordination edits: `src/Web/StellaOps.Web/src/app/layout/`, `src/Web/StellaOps.Web/src/app/routes/`, `docs/modules/ui/contextual-actions-patterns`, `docs/modules/ui/restoration-topics/README.md`, and `docs/modules/ui/TASKS.md`.
|
||||
- Expected evidence: shipped shared UI primitives in `src/Web/**`, adopted patterns in restoration features, route-state helpers, shared tests, and updated docs.
|
||||
|
||||
## Dependencies & Concurrency
|
||||
- Depends on:
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/README.md`
|
||||
- `docs/modules/ui/watchlist-operations/README.md`
|
||||
- `docs/modules/ui/reachability-witnessing/README.md`
|
||||
- `docs/modules/ui/platform-ops-consolidation/README.md`
|
||||
- `docs/modules/ui/triage-explainability-workspace/README.md`
|
||||
- `docs/modules/ui/workflow-visualization-replay/README.md`
|
||||
- Safe parallelism:
|
||||
- the decision matrix and route-state contract should freeze before topic-specific FE implementation starts
|
||||
- shared primitives can be implemented in parallel after the contract is stable
|
||||
- topic sprints can adopt the primitives in parallel once interfaces are frozen
|
||||
|
||||
## Documentation Prerequisites
|
||||
- `docs/modules/ui/contextual-actions-patterns/README.md`
|
||||
- `docs/modules/ui/restoration-topics/README.md`
|
||||
- `docs/modules/ui/architecture.md`
|
||||
- `docs/modules/ui/architecture-rework.md`
|
||||
|
||||
## Delivery Tracker
|
||||
|
||||
### FE-CA-001 - Implement the shared route-state contract
|
||||
Status: TODO
|
||||
Dependency: none
|
||||
Owners: FE Architect, Product Manager
|
||||
Task description:
|
||||
- Implement the shared route-state helpers for `tab`, `panel`, `drawer`, `returnTo`, `scope`, and `view`.
|
||||
- Make the restoration topics consume one working route-state model instead of each inventing bespoke state handling.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Shared route-state helpers exist in code.
|
||||
- [ ] Restoration topics can consume one route-state contract instead of bespoke state rules.
|
||||
- [ ] The placement hierarchy remains documented as the policy for using the new helpers.
|
||||
|
||||
### FE-CA-002 - Ship the shared contextual drawer host
|
||||
Status: TODO
|
||||
Dependency: FE-CA-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Build the shared drawer host used for edit, inspect, explain, and proof flows.
|
||||
- Standardize size, close behavior, route-state binding, keyboard handling, and history interactions in working code.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Drawer host is available for adoption in the restoration features.
|
||||
- [ ] Route-state open and close behavior works in code.
|
||||
- [ ] Accessibility and keyboard behavior are verified for the shared host.
|
||||
|
||||
### FE-CA-003 - Ship split-view, right-rail, and context-header primitives
|
||||
Status: TODO
|
||||
Dependency: FE-CA-001
|
||||
Owners: Developer, FE Architect
|
||||
Task description:
|
||||
- Build reusable split list/detail, right-rail, and context-header primitives for watchlist, triage, evidence, and reachability surfaces.
|
||||
- Ensure responsive behavior works in the shipped components rather than remaining a note in docs.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Split-view, right-rail, and context-header primitives exist in code.
|
||||
- [ ] Panel-stack behavior is usable in the shipped primitives.
|
||||
- [ ] Responsive fallback behavior works in the adopted surfaces.
|
||||
|
||||
### FE-CA-004 - Ship grouped overview-card and submenu primitives
|
||||
Status: TODO
|
||||
Dependency: FE-CA-001
|
||||
Owners: Product Manager, Developer
|
||||
Task description:
|
||||
- Build the grouped overview-card and submenu primitives used by Operations and narrow setup/admin capabilities.
|
||||
- Standardize one-card-to-one-route and one-submenu-to-one-owner patterns in working components.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Grouped overview-card primitives exist in code.
|
||||
- [ ] Submenu patterns are usable by owner shells.
|
||||
- [ ] Card-to-route and submenu-to-owner behavior is consistent in the shipped implementation.
|
||||
|
||||
### FE-CA-005 - Adopt the shared primitives into the restoration features
|
||||
Status: TODO
|
||||
Dependency: FE-CA-001
|
||||
Owners: FE Architect, Developer
|
||||
Task description:
|
||||
- Adopt the shared route-state, drawer, split-view, right-rail, context-header, and overview-card primitives into the restoration features.
|
||||
- Do not count this sprint complete until the primitives are used by the first shipped feature set rather than sitting unused in `shared`.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] At least the Watchlist, Reachability, and Triage or Workflow surfaces adopt the shared primitives.
|
||||
- [ ] Shared primitives replace bespoke implementations where the new restoration work lands.
|
||||
- [ ] Topic-specific adoption is visible in the shipped feature code.
|
||||
|
||||
### FE-CA-006 - Verify, document, and enforce shared usage
|
||||
Status: TODO
|
||||
Dependency: FE-CA-003
|
||||
Owners: QA, Documentation author
|
||||
Task description:
|
||||
- Add shared verification coverage for drawers, panels, tabs, split views, overview cards, and return-to-context behavior.
|
||||
- Update docs so future restoration work treats these primitives as required building blocks, not optional helpers.
|
||||
|
||||
Completion criteria:
|
||||
- [ ] Shared verification covers the adopted primitives.
|
||||
- [ ] Restoration sprints reference and consume the shared primitives.
|
||||
- [ ] Shared docs are updated to reflect the shipped primitive set.
|
||||
|
||||
## Execution Log
|
||||
| Date (UTC) | Update | Owner |
|
||||
| --- | --- | --- |
|
||||
| 2026-03-07 | Sprint created to ship the shared primitives that let restored but narrow functionality become usable submenus, tabs, drawers, right rails, and detail pages instead of spawning new top-level products. | Project Manager |
|
||||
|
||||
## Decisions & Risks
|
||||
- Decision: contextual placement is a shared FE concern and should not be reinvented per topic.
|
||||
- Decision: stable route-state semantics are required for drawers, panels, and return-to-context behavior.
|
||||
- Risk: individual restoration sprints may drift and invent incompatible panel patterns before the shared contract lands.
|
||||
- Mitigation: freeze the shared contract first and make topic sprints depend on it.
|
||||
- Risk: responsive behavior may differ across list/detail, drawer, and right-rail surfaces.
|
||||
- Mitigation: require responsive fallback rules in the shared primitive contract before implementation begins.
|
||||
- Delivery rule: this sprint is only complete when the shared primitives are implemented and adopted by the restoration features, not when the contract is only documented.
|
||||
- Reference design note: `docs/modules/ui/contextual-actions-patterns/README.md`.
|
||||
|
||||
## Next Checkpoints
|
||||
- 2026-03-08: confirm placement hierarchy and route-state contract.
|
||||
- 2026-03-09: freeze drawer, right-rail, split-view, and context-header primitives.
|
||||
- 2026-03-10: finalize adoption map and QA expectations for the restoration sprints.
|
||||
Reference in New Issue
Block a user