Day 6: Live Badges

Day 6 is a Build day: wire the Console sidebar badges to live Gateway counts. The UI already had the Badge component and the TanStack Query hooks. App.tsx was still rendering <Sidebar /> with both counts defaulted to zero.

That is the whole job. Connect what already existed.

What shipped

The sidebar now calls useAlerts() and useApprovals() itself. Same cache as the panels. Alerts refetch every 30 seconds. Approvals every 5 seconds. No page refresh.

Counts follow the spec:

• Alerts: unacknowledged alerts whose severity is critical or high
• Approvals: items with status pending

I pulled those rules into plain functions (countUnacknowledgedCriticalHigh, countPendingApprovals) so they can be tested without rendering React. Property 16 generates random alert and approval arrays and checks the badge number equals those rules. Two tests, both passing.

Unfiltered alert fetches share a query key, ['alerts', 'latest'], so the sidebar and the Alerts panel do not each hammer the Gateway for the same list.

What I am not claiming

At ship time the Gateway still returned raw Wazuh affected_items; the Console typed them as SOCAlert. That map landed early as Day 11 (also checked as Day 32). Until then the alerts badge was live in the sense that it fetched — and showed 0 even if Wazuh had events.

Approvals are closer. The Gateway already proxies GET /api/v1/approvals?status=pending to athena-agents. If that list is populated, the badge moves. Typed ApprovalAction + Property 8 are still Day 12.

Day 6 is wiring. It is not detection coverage. It is not a SOC watching the Juice Shop run from Day 4. Act was still a stub on this day (real tool execution came later in athena-agents).

Day 6 stats

• 1 sidebar wired to two Gateway queries
• 1 property test (badge count accuracy)
• 0 Wazuh-shaped alerts mapped to SOCAlert (at the time — Day 11 closed this)
• Next: Day 7, CORS and Console → Gateway → MinIO end-to-end