Orphan Revival Batch
Purpose
- Convert the verified orphan and disconnected UI findings into execution-ready frontend sprints.
- Keep the batch parallel where possible so multiple agents can work without stepping on the same route parents or shared primitives.
- Make the merge direction explicit so later implementation does not accidentally reintroduce dead product brands, duplicate shells, or stale route aliases.
Current Position
- The preservation-map and restoration-topic work already resolved the major product-shape questions for Policy Decisioning Studio, Reachability Witnessing, Workflow Visualization, Watchlist, Triage Explainability, and the consolidated Operations and Setup shells.
- This batch covers the remaining lower-level orphaned shared components and disconnected route files that still look worth reviving after those larger product merges landed.
- These sprints are intentionally queued for review. They are not started by default.
- Follow-up remediation sprint
024already proved that some orphan adoptions need bounded rollback when the shared contract removes mounted behavior or forces fabricated data. Treat sprint015and sprint020as cautionary examples, not as proof that every orphan shared component should stay mounted wherever it first lands.
Corrections To The External Scan
EvidenceDrawerComponentis already mounted infeatures/vulnerabilities/vulnerability-detail.component.html; it is not a valid "finish the wiring" target in the current repo snapshot.WitnessStatusChipComponentis not truly isolated. It is used bywitness-comparisonandunwitnessed-advisory, which still sit inside a dormant witness chain and need separate product review.- Route-file findings must be treated as candidate disconnected routes, not auto-approved reconnects. Every route reconnection sprint below requires a fresh parent-route verification pass before implementation begins.
timeline.routes.tscannot simply be mounted at/releases/runs/:runId/timelinebecause that path is already owned by the shipped run workspace. The relevant sprint must decide whether to absorb the old timeline surface into the current run detail experience or mount it as a secondary investigation route.- Several "safe to remove" conclusions from the external scan should not be accepted without checking current consumers inside active shells first.
Batch Design Rules
- No sprint in this batch may restore an abandoned product brand as a new top-level menu.
- Shared-component revival sprints must land on mounted UI paths, not only on QA fixtures or dead route trees.
- Route reconnection sprints each own a different parent route family so they can run in parallel.
- When a sprint touches a shared primitive and consumer pages, the consumer list is frozen inside that sprint to avoid cross-agent overlap.
- Each sprint below is independently staffable. If a sprint has external prerequisites, they are already satisfied by shipped work outside this batch.
Queued Sprint Matrix
| Sprint | Theme | Primary owners | Hard dependency inside batch | Concurrency notes |
|---|---|---|---|---|
SPRINT_20260308_013_FE_orphan_domain_signal_chips_adoption.md |
Revive DigestChipComponent and ReachabilityStateChipComponent |
shared/domain, compare, change-trace, vulnerabilities, reachability |
none | Parallel with every sprint below; do not touch finding-list consumers reserved for sprint 020 |
SPRINT_20260308_014_FE_orphan_copy_inline_truncate_adoption.md |
Revive CopyToClipboardComponent, InlineCodeComponent, and TruncatePipe |
shared/ui, shared/pipes, mounted admin and operator consumers |
none | Parallel with sprint 013 and route sprints; avoid proof and evidence consumers reserved for sprint 018 |
SPRINT_20260308_015_FE_orphan_filter_bar_unification.md |
Adopt FilterBarComponent on active list pages |
shared/ui/filter-bar plus adopter pages |
none | Independent, but no other sprint should edit shared/ui/filter-bar while it is staffed |
SPRINT_20260308_016_FE_orphan_persona_visibility_directives.md |
Adopt stellaAuditorOnly and stellaOperatorOnly |
shared/directives, release, evidence, and promotion shells |
none | Parallel with all route sprints and the other shared-component sprints because it excludes findings and policy adopters |
SPRINT_20260308_017_FE_orphan_glossary_tooltips_adoption.md |
Adopt glossary tooltips on jargon-heavy mounted shells | shared/directives, policy, findings, trust, and VEX |
none | Parallel with all route sprints; avoid overlapping exact templates if the consumer set changes during staffing |
SPRINT_20260308_018_FE_orphan_evidence_proof_component_adoption.md |
Adopt proof and verification widgets | shared proof-verification components plus Evidence, Triage, and Releases consumers | none | Parallel with 013, 014, 015, 021, 022, and 023; reserve proof-chain and DSSE consumers for this sprint |
SPRINT_20260308_019_FE_orphan_policy_component_adoption.md |
Adopt policy evaluation and pack-editing widgets | shared policy components plus active policy and release-decisioning consumers | none | Parallel with all route sprints; uses the already shipped policy shell as its host |
SPRINT_20260308_020_FE_orphan_finding_list_consolidation.md |
Adopt FindingListComponent and FindingRowComponent |
shared finding-list components plus findings, triage, and release-review consumers | none | Parallel with sprint 013 because it excludes vulnerability-explorer consumers |
SPRINT_20260308_021_FE_unreachable_evidence_thread_and_persona_workspaces_routes.md |
Reconnect evidence threads and persona workspaces | evidence route family | none | Parallel with 022 and 023 because parent route ownership does not overlap |
SPRINT_20260308_022_FE_unreachable_release_investigation_routes.md |
Integrate disconnected release-investigation routes | releases and deployment-investigation route family | none | Parallel with 021 and 023 because it owns the releases route tree |
SPRINT_20260308_023_FE_unreachable_registry_admin_route.md |
Reconnect registry-admin | integration-hub route family | none | Parallel with 021 and 022 because it owns a different route family |
Dependency Summary
- Hard dependencies between queued sprints: none.
- External prerequisites that are already satisfied:
- Sprint
018assumes the current Evidence and Releases shells remain canonical hosts. - Sprint
019assumes the current/ops/policyDecisioning Studio shell remains canonical. - Sprint
021assumes the current/evidenceshell remains the canonical host for evidence-centric drill-ins. - Sprint
022assumes the current/releasesrun workspace and deployment history remain the canonical hosts for release investigation flows. - Sprint
023assumes the current integration hub remains the canonical host for registry management.
- Sprint
- Soft concurrency constraints:
- Sprint
015should be the only sprint editingshared/ui/filter-bar. - Sprint
018should be the only sprint editing proof-chain and DSSE adoption targets. - Sprint
016and sprint017remain independent as planned, but staffing should keep their final template lists disjoint.
- Sprint
Not Queued In This Batch
agents.routes.tsis not queued because topology already owns agent-fleet surfacing.issuer-trust.routes.tsis not queued because trust administration already owns that capability.policy.routes.tsis not queued because the active Policy Decisioning shell supersedes it.security.routes.tsas a disconnected consolidation shell is not queued because the sub-capabilities already live under active security routes.release-controllegacy shells are not queued because they should continue to be harvested into active products, not revived.analytics.routes.ts,control-plane.routes.ts, andvex-timeline.routes.tsare not queued because their best host shell is still ambiguous and they need a separate product-fit review before execution planning.
Review Outcome Expected From User
- Confirm the queued sprint list is the right cut of the orphan backlog.
- Drop any sprint that feels too legacy or too duplicate-heavy before staffing.
- Mark which sprints can be staffed immediately and which should wait for later product review.