mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-11 22:12:23 +00:00
rcourtman
3c0b52c11d
The trust strip on the Patrol page credits "N auto-resolved" but the Resolved tab next to it sat empty — operators could see the count but not click through to audit which findings had been resolved or by what mechanism. The /api/ai/patrol/findings endpoint only returned active findings, so the frontend filter (status === 'resolved' || 'dismissed' || 'snoozed') had nothing to render. Adds the audit-trail accessor end to end: - PatrolService.GetAllFindingsIncludingResolved returns active + resolved + dismissed + snoozed findings at warning severity or higher, sorted with active first then by severity then recency. Two separate severity orderings — filter (info=0..critical=3, used with >= against the warning floor) and sort (critical=0..info=3, used with < to surface critical first). Conflating them initially let watch findings leak through the warning floor; the test fixture catches that. - HandleGetPatrolFindings honors a new include_resolved=1 query parameter that routes to the new accessor. Default behaviour (active only) is unchanged for clients that just want the live findings list. - Frontend getPatrolFindings accepts an options object with includeResolved and loadPatrolFindings threads it through. - FindingsPanel triggers an includeResolved load whenever the Resolved filter becomes active for the Patrol-source view. Test: TestPatrolService_GetAllFindingsIncludingResolved_IncludesResolvedAndDismissedSortsActiveFirst covers active-first ordering, inclusion of resolved + dismissed, and the warning severity floor (watch-level findings must not leak through).