feat: improvements to web dashboard

tickets/2026-01-07-replace-mock-dashboard-data.md

@@ -1,52 +0,0 @@
-
-# 2026-01-07-replace-mock-dashboard-data.md: Replace Mock Dashboard Data with Live Telemetry
-
-**Status:** Done
-**Created:** 2026-01-07
-**Tags:** dashboard, telemetry, logging, database
-
-## 1. Context & User Story
-* **As a:** Bot Administrator
-* **I want to:** see actual system logs, real-time resource usage, and accurate database statistics on the web dashboard
-* **So that:** I can monitor the true health and activity of the Aurora application without checking the terminal or database manually.
-
-## 2. Technical Requirements
-### Data Model Changes
-- [ ] No strict database schema changes required, but may need a cohesive `LogService` or in-memory buffer to store recent "Activity" events for the dashboard history.
-
-### API / Interface
-- **Dashboard Route (`src/web/routes/dashboard.ts`):**
-    - [x] Replace `mockedActivity` array with a fetch from a real log buffer/source.
-    - [x] Replace `userCount` approximation with a precise count from `UserService` or `AuroraClient`.
-    - [x] Replace "System Metrics" mock bars with real values (RAM usage, Uptime, CPU load if possible).
-- **Log Source:**
-    - [x] Implement a mechanism (e.g., specific `Logger` transport or `WebServer` static buffer) to capture the last ~50 distinct application events (commands, errors, warnings) for display.
-    - [ ] (Optional) If "Docker Compose Logs" are strictly required, implement a file reader for the standard output log file if accessible, otherwise rely on internal application logging.
-
-### Real Data Integration
-- **Activity Feed:** Must show actual commands executed, system errors, and startup events.
-- **Top Stats:** Ensure `Servers`, `Users`, `Commands`, and `Ping` come from the live `AuroraClient` instance.
-- **Metrics:** Display `process.memoryUsage().heapUsed` converted to MB. Display `process.uptime()`.
-
-## 3. Constraints & Validations (CRITICAL)
-- **Performance:** Fetching logs or stats must not block the event loop. Avoid heavy DB queries on every dashboard refresh; cache stats if necessary (e.g., via `setInterval` in background).
-- **Security:** Do not expose sensitive data (tokens, raw SQL) in the activity feed.
-- **Fallbacks:** If data is unavailable (e.g., client not ready), show "Loading..." or a neutral placeholder, not fake data.
-
-## 4. Acceptance Criteria
-1. [x] The "Activity Feed" on the dashboard displays real, recent events that occurred in the application (e.g., "Bot started", "Command /ping executed").
-2. [x] The "System Metrics" section displays a visual representation (or text) of **actual** memory usage and uptime.
-3. [x] The hardcoded `mockedActivity` array is removed from `dashboard.ts`.
-4. [x] Refreshing the dashboard page updates the metrics and feed with the latest data.
-
-## 5. Implementation Plan
-- [x] Step 1: Create a simple in-memory `LogBuffer` in `src/lib/logger.ts` (or similar) to keep the last 50 logs.
-- [x] Step 2: Hook this buffer into the existing logging system (or add manual pushes in `command.handler.ts` etc).
-- [x] Step 3: Implement `getSystemMetrics()` helper to return formatted RAM/CPU data.
-- [x] Step 4: Update `src/web/routes/dashboard.ts` to import the log buffer and metrics helper.
-- [x] Step 5: Replace the HTML template variables with these real data sources.
-
-## Implementation Notes
-- **Log Buffer**: Added a 50-item rolling buffer in `src/lib/logger.ts` exposing `getRecentLogs()`.
-- **Dashboard Update**: `src/web/routes/dashboard.ts` now uses `AuroraClient` stats and `process` metrics (Uptime, Memory) directly.
-- **Tests**: Added `src/lib/logger.test.ts` to verify buffer logic.