From e6f160c297d9dd7f790055b12c4b2bd8890c4cbb Mon Sep 17 00:00:00 2001 From: Sergio Arroutbi Date: Wed, 22 Apr 2026 10:34:24 +0200 Subject: [PATCH] Remove resolved_24h counter from alert summary The alert summary endpoint now returns only three severity counters (critical, warnings, info). The resolved_24h field and its associated KPI card are removed from SDD and SRS to match. Co-Authored-By: Claude Opus 4.6 Signed-off-by: Sergio Arroutbi --- spec/SDD-Keylime-Monitoring-Tool.md | 3 +-- spec/SRS-Keylime-Monitoring-Tool.md | 4 ++-- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/spec/SDD-Keylime-Monitoring-Tool.md b/spec/SDD-Keylime-Monitoring-Tool.md index a336507..8d932b0 100644 --- a/spec/SDD-Keylime-Monitoring-Tool.md +++ b/spec/SDD-Keylime-Monitoring-Tool.md @@ -829,7 +829,7 @@ New --> Acknowledged --> UnderInvestigation --> Resolved **Terminal States:** `Resolved` and `Dismissed` reject all further transitions. -**Summary Computation:** The `critical`, `warnings`, and `info` counters returned by `GET /api/alerts/summary` count **all** alerts of their respective severity regardless of lifecycle state (including `Resolved` and `Dismissed`), matching the totals shown in the Alert Center list. `resolved_24h` counts `Resolved` alerts created within the last 24 hours. The Dashboard "Active Alerts" KPI sums only **active** (non-terminal) `critical + warnings` to represent alerts currently needing attention. All four counters are returned by `GET /api/alerts/summary`. +**Summary Computation:** The `critical`, `warnings`, and `info` counters returned by `GET /api/alerts/summary` count **all** alerts of their respective severity regardless of lifecycle state (including `Resolved` and `Dismissed`), matching the totals shown in the Alert Center list. The Dashboard "Active Alerts" KPI sums only **active** (non-terminal) `critical + warnings` to represent alerts currently needing attention. All three severity counters are returned by `GET /api/alerts/summary`. **Trace:** Implementation -- `keylime-webtool-backend/src/models/alert_store.rs` @@ -882,7 +882,6 @@ The frontend derives attestation KPIs from agent state data when no attestation | Alert Center: Critical | From `GET /api/alerts/summary` -> `critical` (all states) | | Alert Center: Warnings | From `GET /api/alerts/summary` -> `warnings` (all states) | | Alert Center: Info | From `GET /api/alerts/summary` -> `info` (all states) | -| Alert Center: Resolved | From `GET /api/alerts/summary` -> `resolved_24h` | **Rationale:** Ensures the dashboard displays meaningful data before TimescaleDB attestation history persistence is implemented. diff --git a/spec/SRS-Keylime-Monitoring-Tool.md b/spec/SRS-Keylime-Monitoring-Tool.md index c413202..e890bdb 100644 --- a/spec/SRS-Keylime-Monitoring-Tool.md +++ b/spec/SRS-Keylime-Monitoring-Tool.md @@ -1509,9 +1509,9 @@ Feature: Alert Lifecycle Workflow And the resolution reason MUST indicate "auto-resolved on successful re-attestation" Scenario: Alert Center KPI cards use consistent summary data - Given the alert summary endpoint returns critical=2, warnings=2, info=2, resolved_24h=0 + Given the alert summary endpoint returns critical=2, warnings=2, info=2 When the user views the Alert Center page - Then all four KPI cards (Critical, Warnings, Info, Resolved) MUST display values from the summary endpoint + Then all three KPI cards (Critical, Warnings, Info) MUST display values from the summary endpoint And the KPI values MUST NOT change when table filters are applied ```