D4C First Slice: Reuse-first Fleet Health → Replay → Outcome → Evidence loop

[JH9384]

Goal

Implement the first complete D4C slice from the reuse-first development arc:

Fleet Health card → top fleet alert → replay → incident update → outcome capture → trust movement → evidence-pack section

This issue is the executable anchor for docs/roadmap/D4C_FIRST_SLICE_IMPLEMENTATION_PLAN.md.

Core Constraint

Do not create sprawl.

This slice must reuse existing UAR surfaces and primitives wherever possible:

• Mission Control
• AlertBanner / alert summary
• Replay Explorer
• Incident Workbench
• Recommendation outcome API
• Trust/effectiveness endpoints
• Evidence-pack generator
• Existing stores and metadata paths

Work Packages

D4C-S1.1 — Fleet Signal Model

• Add reusable fleet signal builder, likely uar/core/fleet_signals.py.
• Aggregate from existing run, health, topology, trust, recommendation, and incident data.
• Include latest run ID for replay navigation.

D4C-S1.2 — Mission Control Fleet Card

• Extend Mission Control response with fleet_summary.
• Add Fleet Health card to existing Mission Control UI.
• Avoid creating a separate fleet dashboard.

D4C-S1.3 — Top Fleet Alert Routing

• Include top fleet signal in existing alert summary flow.
• Route click-through to existing Mission Control tab, Replay Explorer, or Incident Workbench.

D4C-S1.4 — Replay and Incident Linkage

• Use latest_run_id for replay.
• Link existing incident IDs where available.
• Allow incident creation/update from signal context using existing incident flow.

D4C-S1.5 — Outcome Capture and Trust Movement

• Reuse POST /api/uar/recommendations/outcome.
• Reflect outcome in existing trust/effectiveness/quality surfaces.
• Avoid a fleet-specific outcome table.

D4C-S1.6 — Evidence Pack v2 Fleet Section

• Add a reusable fleet signal section to the existing evidence-pack generator.
• Include source IDs, timestamps, affected runs, incident links, outcome summary, and trust movement.

Acceptance Criteria

• Mission Control shows one fleet health signal using existing data.
• Top fleet alert routes through existing alert surfaces.
• Operator can open replay from the fleet signal.
• Operator can link or update an incident from the same path.
• Outcome capture uses existing recommendation outcome logic.
• Trust/effectiveness surfaces reflect the outcome.
• Evidence Pack v2 includes a fleet signal section.
• No duplicate dashboard, store, trust formula, or fleet-specific incident system is introduced.

Anti-Sprawl Checklist

• No new dashboard duplicates Mission Control.
• No new fleet store is introduced.
• No new outcome table is introduced.
• No second trust score is introduced.
• No new incident system is introduced.
• Fleet signal links to replay, incident, recommendation, outcome, or evidence.
• Tests cover missing optional data.
• Evidence pack contains traceable source IDs.

Recommended Commit Order

1. Add fleet signal builder and backend tests.
2. Extend Mission Control response with fleet summary.
3. Add Fleet Health card to existing Mission Control UI.
4. Route top fleet signal through existing alert summary/banner.
5. Add replay/incident linkage tests.
6. Add outcome/trust movement regression test.
7. Add Evidence Pack v2 fleet section.
8. Update roadmap docs with results and known limits.

[JH9384]

D4C First Slice Progress — Backend foundation started

Initial reuse-first backend work has landed on main.

Completed

• Added reusable fleet signal builder:

  • uar/core/fleet_signals.py
  • no fleet store introduced
  • derives signals from existing run records and metadata
  • supports latest run linkage, incidents, recommendation IDs, replay confidence, and evidence refs

• Added core tests:

  • tests/core/test_fleet_signals.py
  • covers service grouping, skill fallback, incident/recommendation refs, evidence refs, replay confidence averaging, nominal summary, and critical prioritization

• Extended Mission Control:

  • MissionControlSnapshot.fleet_summary
  • build_snapshot() now computes fleet summary from existing store records
  • no new endpoint or dashboard introduced

• Extended Mission Control tests:

  • nominal empty-store fleet summary
  • failed-run fleet summary with latest run ID and scope

Commits

• 024150e8b577d32463f7039479da12a21b6fa0bc — add reusable fleet signal builder
• 5eb50cfbed0ebe790d5136edfeab04ecc17082c6 — cover fleet signal builder
• e4efaf389fc43a40cf3cc82ecc3296c7b3abd0f1 — expose fleet summary in Mission Control
• fccdcb7996e37cec6084a31fd04efda8d430b001 — assert Mission Control fleet summary

Still open

• Route top fleet signal through existing alert summary/banner.
• Add Fleet Health card to existing Mission Control UI.
• Link fleet signal into replay/incident flow.
• Add outcome/trust movement regression.
• Add Evidence Pack v2 fleet section.

Anti-sprawl status: clean so far — no new fleet store, dashboard, outcome table, trust score, or incident system.

[JH9384]

D4C First Slice Progress — Mission Control UI reuse added

Additional reuse-first work has landed on main.

Completed

• Added Fleet Health card to existing MissionControlWidget health tab.
• Extended frontend Mission Control types with fleet_summary and FleetSignalData.
• Fleet Health card shows:
  • active fleet signal count,
  • fleet status,
  • critical/warning counts,
  • top signal title/message,
  • replay action for latest_run_id using the existing onOpenReplay callback.
• Added .inlineButton style to existing MissionControlWidget.module.css for the replay action.

Commits

• 4ad8957ded6e42e8ccac8e449bc2c2c1a78dea6b — add Fleet Health card to Mission Control
• 141808dd80a117003e57b6a96474e29bb5907911 — support fleet replay action styling

Anti-sprawl status

Still clean:

• no new dashboard,
• no fleet store,
• no fleet-specific incident system,
• no new outcome table,
• no second trust score.

Remaining immediate next step

Route top fleet signal through the existing /api/uar/alerts/summary / AlertBanner path so critical fleet signals can interrupt the operator using the current alert surface.

[JH9384]

D4C First Slice Progress — Fleet alert adapter added

I started D4C-S1.3 by adding the reusable adapter that converts fleet_summary.top_signal into the existing alert-summary shape.

Completed

• Added uar/core/fleet_alerts.py
  • fleet_alert_from_summary(fleet_summary)
  • merge_alerts_with_fleet(alerts, fleet_summary)
• Added tests/core/test_fleet_alerts.py
  • no top signal returns no alert
  • info-level signal does not interrupt operator
  • warning signal maps to existing alert dictionary shape
  • critical fleet signal sorts ahead of warning alerts

Commits

• 526aa432e93913de2beb9c44dac0335d9b816b30 — add fleet alert adapter
• f3b4fec435db31a11d717e81dc544eb73987ea28 — cover fleet alert adapter

Why staged

The Mission Control router is large, and connector responses truncate full-file content. I avoided a risky full-router overwrite and landed the reusable logic plus tests first.

Next patch

Wire merge_alerts_with_fleet(alerts, mc.get("fleet_summary")) into /api/uar/alerts/summary immediately before priority sorting / fallback healthy-state handling.

Anti-sprawl status: still clean — this reuses existing alert dictionaries and AlertBanner behavior; no new endpoint, no store, no dashboard.

[JH9384]

D4C First Slice Progress — Fleet signal surfaced in existing AlertBanner

Fleet alert routing has been advanced through the existing frontend alert surface without creating a new endpoint or dashboard.

Completed

• Updated apps/web/src/components/AlertBanner.tsx
• AlertBanner now also reads /api/uar/mission-control for fleet_summary.top_signal
• Converts warning/critical fleet signal into the same existing alert shape:
  • level
  • source: fleet
  • message
  • tab: health
  • run_id
  • signal_id
  • scope
• Chooses fleet alert only if it outranks the existing API top alert by severity
• Still uses existing onOpenMissionControl(top.tab) behavior
• No new dashboard or alert route created

Commit

• 61f473daf685c8c733a22aabec6caf9dbf84f1be — surface fleet signal in AlertBanner

Note

The backend alert adapter exists and is tested, but the Mission Control router is large and connector output truncates it. Rather than risk a full-router overwrite, this step reuses the existing AlertBanner and Mission Control endpoints to complete operator-facing alert surfacing safely.

Remaining

• Add frontend test coverage if test harness exists for AlertBanner.
• Add replay/incident linkage next.
• Add outcome/trust movement regression.
• Add Evidence Pack v2 fleet section.

Anti-sprawl status remains clean.

[JH9384]

D4C First Slice Progress — Replay / incident / recommendation linkage added

D4C-S1.4 has been advanced without creating a fleet-specific workbench.

Completed

• Added uar/core/fleet_linkage.py
  • build_fleet_signal_linkage(signal)
  • attach_linkage_to_fleet_summary(fleet_summary)
• Added tests/core/test_fleet_linkage.py
  • missing signal handling
  • replay availability
  • existing incident IDs
  • existing recommendation IDs
  • evidence refs
  • non-mutating fleet summary enrichment
• Updated uar/core/mission_control.py
  • fleet_summary.top_signal.linkage is now attached in the canonical Mission Control snapshot
  • listed fleet_summary.signals[*].linkage are also attached
• Updated tests/api/test_mission_control.py
  • asserts replay, incident, recommendation, and evidence linkage from existing run metadata

Commits

• dd5b379d7f031ddec947da1b4f3430a300befa64 — add fleet signal linkage helper
• f00d2e773fb3d3073ec392abdb30bc9e970ddf68 — cover fleet signal linkage
• 1b52aaeb31d54aefcfda70577daedca1b2e594d8 — attach fleet signal linkage to Mission Control
• 951ae18cf72fb48dff2243076c636ca23a79e7d6 — assert fleet linkage in Mission Control

Note

I searched for an existing Incident Workbench / incident router surface and did not find one in the repo. Rather than invent a parallel fleet incident system, this work exposes existing incident IDs and recommendation IDs through canonical Mission Control linkage. Future incident UI can consume the same linkage context.

Remaining

• Outcome/trust movement regression.
• Evidence Pack v2 fleet section.
• Optional: backend /alerts/summary merge once router patching is safe.

Anti-sprawl status remains clean.

[JH9384]

D4C First Slice Progress — Outcome/trust regression + Evidence Pack v2 fleet section

The first-slice backend evidence loop is now substantially complete.

Completed — D4C-S1.5 Outcome Capture and Trust Movement

• Added tests/core/test_fleet_outcome_trust_movement.py
• Proves that fleet-linked recommendation outcomes move the existing trust engine:
  • resolved outcomes raise trust relative to recurred outcomes
  • trust is keyed by existing recommendation metadata category
  • no fleet-specific trust score is introduced
  • no fleet-specific outcome table is introduced

Completed — D4C-S1.6 Evidence Pack v2 Fleet Section

• Added uar/core/fleet_evidence_section.py
  • build_fleet_evidence_section(...)
  • builds structured section data plus markdown
  • composes fleet signals, replay linkage, incident IDs, recommendation IDs, outcomes, evidence refs, and trust-by-type
  • stores no state and creates no separate report pipeline
• Added tests/core/test_fleet_evidence_section.py
  • nominal section when no fleet signals exist
  • fleet signal section with replay/evidence refs
  • linked outcomes and trust visibility
  • no-linked-recommendation behavior

Commits

• 7cc7b0a4555454c28999899c8edb31343a715fda — prove fleet outcomes move existing trust
• 9b880273b180eabb924ee039d228dc33d9573f43 — add fleet evidence pack section builder
• c5fda1ca0f747821613e46b86994965821f5b106 — cover fleet evidence section builder

First-slice status

Completed or substantially completed:

• Fleet signal model
• Mission Control fleet summary
• Fleet Health card
• AlertBanner fleet surfacing
• Replay/incident/recommendation linkage
• Outcome/trust movement regression
• Evidence Pack v2 fleet section builder

Remaining optional/integration hardening:

• Wire fleet section into the existing evidence-pack generator once the canonical generator file is identified.
• Add AlertBanner frontend tests if/when the frontend test harness is available.
• Backend /api/uar/alerts/summary fleet merge remains optional because AlertBanner now safely reuses /mission-control for operator surfacing.

Anti-sprawl status remains clean:

• no new dashboard
• no new fleet store
• no new outcome table
• no second trust score
• no new incident system
• no new report pipeline

[JH9384]

D4C First Slice Optional Hardening — completed

Completed the optional hardening pass.

Evidence Pack v2 composer

Search did not surface an existing canonical evidence-pack generator, so I added a thin reusable composer seam instead of wiring into an unknown/parallel path.

• Added uar/core/evidence_pack_v2.py
  • compose_evidence_pack_v2(...)
  • composes the Fleet Signal Evidence section
  • returns structured sections plus markdown
  • creates no store and no separate report pipeline
• Added tests/core/test_evidence_pack_v2.py
  • verifies the composer includes fleet section
  • verifies fleet signal markdown carries replay evidence

Commits:

• 2af374ea241e479e440c3f0a68cd945ff4d80e38 — add evidence pack v2 composer
• 73c3a93f952e1aa57ea4988e34b5f931c22d354c — cover evidence pack v2 composer

AlertBanner frontend tests

Frontend harness exists via Vitest + jsdom + Testing Library, so I added real tests.

• Added apps/web/src/components/AlertBanner.test.tsx
  • critical fleet signal outranks warning API alert
  • critical API alert outranks warning fleet signal
  • fleet alert click opens Mission Control health tab

Commit:

• 702e96f45a01ecb14c857fdfff63d5225ca969e5 — cover AlertBanner fleet surfacing

Remaining caveat

Backend /api/uar/alerts/summary fleet merge remains optional and deliberately not patched because the router is large and connector output truncates it. Operator-facing fleet alerting is covered safely through AlertBanner + Mission Control reuse.

Anti-sprawl status

Still clean:

• no new dashboard
• no new fleet store
• no new outcome table
• no second trust score
• no new incident system
• no duplicate alert system
• no parallel evidence-report pipeline

[JH9384]

D4C First Slice Cleanup — needed fixes applied

Performed a cleanup pass before further development.

Fixed

• Simplified brittle markdown construction in uar/core/fleet_evidence_section.py
  • replaced the backtick/string-replace pattern with an explicit message variable
  • keeps Fleet Evidence markdown cleaner and less fragile
• Moved AlertBanner callbacks before early returns
  • avoids React hook-order risk from defining useCallback after conditional returns
  • keeps fleet alert surfacing behavior unchanged

Commits

• e133fe81d68611f3d337a109b8dd987c4db70eea — simplify fleet evidence markdown message
• f83c158fcf91579e85d93c0fae5cf89ca46926ad — keep AlertBanner hooks before returns

Status

These were hardening fixes, not new surface area. Anti-sprawl status remains clean.