From 003e6c1b16c513adb4eff6c0aa80711ff1616b8f Mon Sep 17 00:00:00 2001 From: Sergio Arroutbi Date: Tue, 21 Apr 2026 19:13:31 +0200 Subject: [PATCH] Add info field to AlertSummary, require consistent KPI sourcing The backend AlertSummary was missing the info severity count, causing the Alert Center Info KPI card to fall back to the filtered alert list while Critical/Warnings/Resolved used the unfiltered summary endpoint. This adds the info field to the SDD data model and a Gherkin scenario to FR-047 requiring all four KPI cards to source from the summary endpoint consistently. Co-Authored-By: Claude Opus 4.6 Signed-off-by: Sergio Arroutbi --- spec/SDD-Keylime-Monitoring-Tool.md | 8 ++++++-- spec/SRS-Keylime-Monitoring-Tool.md | 6 ++++++ 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/spec/SDD-Keylime-Monitoring-Tool.md b/spec/SDD-Keylime-Monitoring-Tool.md index 1cb06e0..73803db 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:** Active alerts (not `Resolved` or `Dismissed`) are counted by severity. Resolved alerts within the last 24 hours are counted separately for the dashboard KPI. +**Summary Computation:** Active alerts (not `Resolved` or `Dismissed`) are counted by severity (`critical`, `warnings`, `info`). Resolved alerts within the last 24 hours are counted separately (`resolved_24h`). All four counters are returned by `GET /api/alerts/summary` and used consistently by both the Dashboard and the Alert Center KPI cards. **Trace:** Implementation -- `keylime-webtool-backend/src/models/alert_store.rs` @@ -878,7 +878,11 @@ The frontend derives attestation KPIs from agent state data when no attestation | Total Agents | `paginated_response.total_items` or `agents.length` | | Failed Attestations | Count of agents in `failed`, `invalid_quote`, `tenant_failed` (pull) or `fail`, `timeout` (push) state | | Success Rate | `((total - failed) / total) * 100` | -| Active Alerts | From `GET /api/alerts/summary` -> `critical` count | +| Active Alerts | From `GET /api/alerts/summary` -> `critical + warnings` count | +| Alert Center: Critical | From `GET /api/alerts/summary` -> `critical` | +| Alert Center: Warnings | From `GET /api/alerts/summary` -> `warnings` | +| Alert Center: Info | From `GET /api/alerts/summary` -> `info` | +| 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 ec54c39..c413202 100644 --- a/spec/SRS-Keylime-Monitoring-Tool.md +++ b/spec/SRS-Keylime-Monitoring-Tool.md @@ -1507,6 +1507,12 @@ Feature: Alert Lifecycle Workflow When agent "agent-042" passes a subsequent attestation cycle Then the System SHOULD automatically resolve the alert 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 + When the user views the Alert Center page + Then all four KPI cards (Critical, Warnings, Info, Resolved) MUST display values from the summary endpoint + And the KPI values MUST NOT change when table filters are applied ``` ### FR-048: Alert Auto-Escalation