docs(ui): map restoration topics and delivery sprints

2026-03-07 17:48:12 +02:00
parent b689146785
commit 601d6f24be
27 changed files with 3316 additions and 0 deletions
--- 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).
--- 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
--- 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/`.
--- a/docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md
+++ 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`.
--- a/docs/modules/ui/contextual-actions-patterns/README.md
+++ 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=<name>`
+- `panel=<name>`
+- `drawer=<name>`
+- `returnTo=<encoded route>`
+- `scope=<name>`
+- `view=<name>`
+
+### Rules
+- use child routes for durable subpages
+- use query params for secondary panels and drawers
+- preserve `returnTo` whenever a user came from another owner shell
+- keep panel names short and stable for bookmarks and tests
+
+## Shared Primitives To Build
+
+### 1. Context header
+- pinned subject context
+- status chips
+- return-to-context action
+
+### 2. Split list/detail shell
+- stable layout for list left, detail right
+- supports keyboard navigation and deep linking
+
+### 3. Drawer host
+- route-aware drawers for edit, inspect, and explain flows
+- consistent size, close behavior, and history handling
+
+### 4. Right-rail panel stack
+- secondary tabs for evidence, explanation, provenance, and history
+
+### 5. Grouped overview cards
+- consistent card layout for ops-like overview pages
+- each card maps to exactly one child route
+
+### 6. Action tray
+- row or bulk actions that preserve page context
+- confirmation only for destructive or privilege-sensitive actions
+
+## Topic Mapping
+
+### Watchlist
+- submenu + tabs + edit drawer
+
+### Reachability Witnessing
+- tabbed shell + witness detail page + PoE drawer
+
+### Platform Ops
+- grouped overview cards + stable child routes
+
+### Triage Explainability
+- segmented lanes + detail-side panels + sibling audit-bundles page
+
+### Workflow Visualization
+- run-detail tabs + step drawer + evidence deep links
+
+## Implementation Standards
+
+- Prefer contextual UX over new products.
+- Preserve deep-link stability for tabs and panels.
+- Keep actions evidence-first and operator-confirmed when risk is high.
+- Make drawers and rails testable with stable route state.
+- Reuse primitives rather than re-creating bespoke shells per topic.
+
+## Non-Goals
+
+- Do not turn every contextual tool into a modal.
+- Do not allow each feature team to invent incompatible query-param contracts.
+- Do not use new top-level navigation to solve narrow discoverability problems.
+
+## Source Inputs
+
+- `docs/modules/ui/restoration-topics/README.md`
+- `docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md`
+- `docs/ui-analysis/05_ROUTE_SUMMARY_AND_OBSERVATIONS.md`
+- `docs/modules/ui/architecture.md`
+- `docs/modules/ui/architecture-rework.md`
--- 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`
--- a/docs/modules/ui/platform-ops-consolidation/README.md
+++ 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`
--- a/docs/modules/ui/policy-decisioning-studio/README.md
+++ 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`
--- a/docs/modules/ui/reachability-witnessing/README.md
+++ 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=<encoded route>` for findings, triage, evidence, or releases
+
+### Alias rules
+- any future `evidence` or `release` entry points should deep-link here rather than mount duplicate witness pages
+
+## What To Merge
+
+### Merge into `Coverage`
+- `ReachabilityCenterComponent`
+
+### Merge into `Witnesses`
+- `WitnessPageComponent`
+
+### Merge into `PoE / Exposure`
+- `PoEDrawerComponent`
+
+### Preserve as shared behaviors
+- export DOT and Mermaid actions
+- proof verification actions
+- evidence-chain cards
+
+## Single Actions And Supporting Surfaces
+
+### Witness detail
+- full page under `Witnesses`
+- preserve permalink and return-to-context behavior
+
+### PoE detail
+- default to a right drawer from witness detail, finding detail, triage, or release context
+- allow a standalone route for exports and audit deep links
+
+### Export or replay verify
+- keep as actions on witness or PoE detail
+- do not create separate pages per export type
+
+### Related finding navigation
+- keep as contextual links in the witness detail sidebar
+
+## Cross-Product Entry Points
+
+- `Security > Findings`
+  - open witness detail for a finding
+- `Triage > Artifact Workspace`
+  - open witness or PoE from artifact detail
+- `Evidence > Verify & Replay`
+  - open proof verification in the same witness/PoE model
+- `Decisioning Studio` or `Releases`
+  - open witness and proof for gate verdict explanation
+
+## UI Standards For Implementation
+
+- Keep witness detail as the canonical deep-link target.
+- Default proof detail to a drawer to preserve investigation context.
+- Preserve return-to-context links so operators can move back to findings or release flows.
+- Reuse evidence cards and path visualizations across security, evidence, and release entry points.
+- Keep graph and proof loading deterministic and evidence-first.
+
+## Non-Goals
+
+- Do not create a top-level `Witnessing` product.
+- Do not split coverage, witness, and proof UX across unrelated sidebar branches.
+- Do not leave PoE as a drawer with no canonical parent route.
+
+## Source Inputs
+
+- `docs/contracts/witness-v1.md`
+- `docs/architecture/EVIDENCE_PIPELINE_ARCHITECTURE.md`
+- `docs/modules/scanner/reachability.md`
+- `docs/modules/ui/architecture-rework.md`
+- `src/Web/StellaOps.Web/src/app/features/reachability/reachability-center.component.ts`
+- `src/Web/StellaOps.Web/src/app/features/reachability/witness-page.component.ts`
+- `src/Web/StellaOps.Web/src/app/features/reachability/poe-drawer.component.ts`
+- `src/Web/StellaOps.Web/src/app/routes/security-risk.routes.ts`
+- `src/Web/StellaOps.Web/src/app/routes/evidence.routes.ts`
--- a/docs/modules/ui/restoration-topics/README.md
+++ 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)
--- a/docs/modules/ui/restoration-topics/platform-ops-consolidation.md
+++ 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.
--- a/docs/modules/ui/restoration-topics/reachability-witnessing.md
+++ 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.
--- a/docs/modules/ui/restoration-topics/triage-explainability-workbench.md
+++ 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.
--- a/docs/modules/ui/restoration-topics/watchlist.md
+++ 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`.
--- a/docs/modules/ui/restoration-topics/workflow-visualization-and-replay.md
+++ 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.
--- a/docs/modules/ui/triage-explainability-workspace/README.md
+++ 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=<encoded route>` for security, evidence, or release-context entry points
+
+### Alias rules
+- `Security > Artifacts` should use the same route family instead of owning a second triage workspace
+- any future exception or findings entry points should deep-link into the same artifact detail route
+
+## What To Merge
+
+### Merge into list layer
+- `QuietLaneWorkbenchComponent`
+
+### Merge into detail layer
+- `AiRecommendationWorkbenchComponent`
+- `ReasonCapsuleWorkbenchComponent`
+- `AiCodeGuardBadgeComponent`
+- `SnapshotViewerComponent`
+- `UnknownsListComponent`
+
+### Keep as real sibling page
+- `TriageAuditBundlesComponent`
+- `TriageAuditBundleNewComponent`
+
+## Single Actions And Supporting Surfaces
+
+### Apply AI suggestion
+- keep inside artifact detail
+- do not create a dedicated route
+
+### Reason capsule
+- keep as a contextual panel or secondary tab
+- never separate it from the active decision context
+
+### Quiet-lane promote, snooze, or TTL extend
+- keep as row or bulk actions in the list view
+
+### Audit-bundle creation
+- allow a dedicated new route because it has a multi-step operator flow
+
+## Cross-Product Entry Points
+
+- `Security > Findings`
+  - deep-link into artifact detail with `panel=reason` or `panel=provenance`
+- `Evidence`
+  - link to `Audit Bundles` and artifact evidence panels
+- `Reachability`
+  - open witness drawers from artifact detail
+- `Decisioning Studio`
+  - deep-link into the artifact decision context when a policy verdict needs human review
+
+## UI Standards For Implementation
+
+- Keep list and detail behaviors in one coherent workspace.
+- Use lane tabs or segmented controls rather than separate pages for queue modes.
+- Use stable query-param panel state for explainability surfaces.
+- Preserve evidence-first decision making; AI is advisory, never opaque.
+- Keep audit packaging as a real page because it has lifecycle and exports.
+
+## Non-Goals
+
+- Do not preserve `AI Recommendation Workbench` or `Reason Capsule Workbench` as standalone brands.
+- Do not move quiet-lane logic to a separate product shell.
+- Do not scatter audit, evidence, and explainability flows across different owners.
+
+## Source Inputs
+
+- `docs/UI_GUIDE.md`
+- `docs/ui-analysis/03_TRIAGE_POLICY_OPS_SCREENS.md`
+- `docs/ui-analysis/05_ROUTE_SUMMARY_AND_OBSERVATIONS.md`
+- `src/Web/StellaOps.Web/src/app/routes/security-risk.routes.ts`
+- `src/Web/StellaOps.Web/src/app/features/triage/triage-artifacts.component.ts`
+- `src/Web/StellaOps.Web/src/app/features/triage/triage-workspace.component.ts`
+- `src/Web/StellaOps.Web/src/app/features/triage/triage-audit-bundles.component.ts`
--- a/docs/modules/ui/watchlist-operations/README.md
+++ 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=<id>` for opening the edit drawer
+- `alertId=<id>` for opening the alert detail drawer
+- `returnTo=<encoded route>` when entered from Mission Control or Notifications
+
+### Alias and entry rules
+- `Mission Control > Alerts` should deep-link into `?tab=alerts&alertId=...`
+- `Ops > Notifications` should deep-link into `?tab=tuning`
+- no separate sidebar product or parallel route family should exist
+
+## What To Merge
+
+### Merge into `Entries`
+- `WatchlistPageComponent` list mode
+- existing create/edit form
+- existing pattern test behavior
+
+### Merge into `Alerts`
+- `WatchlistPageComponent` alert table and alert drill-down behavior
+
+### Merge into `Tuning`
+- duplicate-suppression controls
+- notification behavior controls
+- runbook-driven KPIs and tuning guidance
+
+## Single Actions And Supporting Surfaces
+
+### Create or edit rule
+- use a drawer or split detail panel inside `Entries`
+- add a standalone route only if audit/history requires a permalink
+
+### Test pattern
+- keep inside the edit experience
+- never give it a dedicated page
+
+### Alert detail
+- open as a drawer from `Alerts`
+- preserve deep links via `alertId`
+
+### Dedup diagnostics
+- keep in `Tuning`
+- optionally expose summary KPIs in `Ops > Notifications`
+
+## Cross-Product Entry Points
+
+- `Mission Control > Alerts`
+  - watchlist source chip opens the `Alerts` tab
+- `Ops > Notifications`
+  - channel health card links to `Tuning`
+- `Security` or `Evidence` surfaces
+  - only deep-link to alert detail when a signer-identity event matters to an investigation
+
+## UI Standards For Implementation
+
+- Use one shell component with tabbed child routes or stable tab state.
+- Preserve scope awareness in header and filters.
+- Support list/detail without forcing route churn for every edit.
+- Keep alert outcomes visible in mission/notification surfaces without duplicating the configuration shell.
+- Preserve deterministic sort order for entries and alerts.
+
+## Non-Goals
+
+- Do not make Watchlist a top-level sidebar product.
+- Do not split configuration and alert history across different owner areas.
+- Do not move trust ownership into Mission Control.
+
+## Source Inputs
+
+- `docs/modules/attestor/guides/identity-watchlist.md`
+- `docs/operations/watchlist-monitoring-runbook.md`
+- `docs/features/checked/web/identity-watchlist-management-ui.md`
+- `src/Web/StellaOps.Web/src/app/features/watchlist/watchlist-page.component.ts`
+- `src/Web/StellaOps.Web/src/app/routes/mission-control.routes.ts`
+- `src/Web/StellaOps.Web/src/app/routes/operations.routes.ts`
--- a/docs/modules/ui/workflow-visualization-replay/README.md
+++ 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=<stepId>` to open the step drawer
+- `returnTo=<encoded route>` when entering from evidence or approvals
+
+### Alias rules
+- any legacy `workflow-visualization/*` route should redirect into the run-detail tab family
+
+## What To Merge
+
+### Merge into runtime run detail
+- `WorkflowVisualizerComponent`
+- `TimeTravelControlsComponent`
+- `StepDetailPanelComponent`
+
+### Reuse in authoring preview
+- graph-only subset of `WorkflowVisualizerComponent`
+
+### Integrate with existing evidence replay
+- `ReplayControlsComponent`
+- proof replay surfaces where they overlap with deterministic verification
+
+## Single Actions And Supporting Surfaces
+
+### Step detail
+- right drawer by default
+- add a full route only if failed-step diagnostics need durable shareable URLs beyond `step=<id>`
+
+### Time-travel controls
+- toolbar actions in `Timeline` or `Replay`
+- never a separate page
+
+### Critical-path focus
+- its own tab or a persistent graph mode
+- not a sidebar product
+
+### Replay verify
+- primary home in `Replay`
+- secondary entry point from `Evidence > Verify & Replay`
+
+## Cross-Product Entry Points
+
+- `Releases > Approvals`
+  - deep-link into run detail when an approval is waiting on a blocked step
+- `Evidence > Verify & Replay`
+  - open the same replay context with run id preselected
+- `Decisioning Studio`
+  - open run evidence or gate proof when policy blocks a promotion
+- `Administration > Workflows`
+  - show authoring-time preview without runtime state
+
+## UI Standards For Implementation
+
+- Treat graph, timeline, critical path, replay, and evidence as one coherent run-detail experience.
+- Preserve stable tab and step deep links.
+- Keep replay evidence visible and comparable to the original run outcome.
+- Avoid mixing authoring preview with live telemetry.
+- Reuse graph components between runtime and authoring only where the semantics stay clear.
+
+## Non-Goals
+
+- Do not create a standalone `Workflow Visualization` sidebar item.
+- Do not split graph and replay into different owner shells.
+- Do not make workflow editor the primary home of runtime troubleshooting.
+
+## Source Inputs
+
+- `docs/modules/release-orchestrator/ui/overview.md`
+- `docs/modules/release-orchestrator/workflow/evidence-based-release-gates.md`
+- `docs/modules/ui/architecture-rework.md`
+- `src/Web/StellaOps.Web/src/app/routes/releases.routes.ts`
+- `src/Web/StellaOps.Web/src/app/routes/evidence.routes.ts`
+- `src/Web/StellaOps.Web/src/app/features/workflow-visualization/workflow-visualization.routes.ts`
+- `src/Web/StellaOps.Web/src/app/features/workflow-visualization/components/workflow-visualizer/workflow-visualizer.component.ts`