# 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.