Files
git.stella-ops.org/docs/modules/ui/component-preservation-map/RESTORATION_PRIORITIES.md
2026-03-08 00:02:02 +02:00

9.7 KiB

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-archived/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-archived/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-archived/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-archived/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-archived/implplan/SPRINT_20260307_028_FE_workflow_visualization_replay.md
    • Shipped verification note: docs/features/checked/web/workflow-visualization-replay-ui.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.
  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, shipped implementation sprint docs-archived/implplan/SPRINT_20260307_029_FE_contextual_actions_and_stray_surfaces.md, and verification note docs/features/checked/web/contextual-actions-patterns-ui.md.