feat(dash): Revamp dashboard UI with glassmorphism and real bot data

tickets/2026-01-08-dashboard-activity-charts.md

@@ -0,0 +1,38 @@
+# DASH-003: Visual Analytics & Activity Charts
+
+**Status:** Draft
+**Created:** 2026-01-08
+**Tags:** dashboard, analytics, charts, frontend
+
+## 1. Context & User Story
+* **As a:** Bot Administrator
+* **I want to:** View a graphical representation of bot usage over the last 24 hours.
+* **So that:** I can identify peak usage times and trends in command execution.
+
+## 2. Technical Requirements
+### Data Model Changes
+- [ ] No new tables.
+- [ ] Requires complex aggregation queries on the `transactions` table.
+
+### API / Interface
+- [ ] `GET /api/stats/activity`: Returns an array of data points for the last 24 hours (hourly granularity).
+- [ ] Response Structure: `Array<{ hour: string, commands: number, transactions: number }>`.
+
+## 3. Constraints & Validations (CRITICAL)
+- **Input Validation:** Hourly buckets must be strictly validated for the 24h window.
+- **System Constraints:** 
+    - Database query must be cached for at least 5 minutes as it involves heavy aggregation.
+    - Chart must be responsive and handle mobile viewports.
+- **Business Logic Guardrails:** 
+    - If no data exists for an hour, it must return 0 rather than skipping the point.
+
+## 4. Acceptance Criteria
+1. [ ] **Given** a 24-hour history of transactions, **When** the dashboard loads, **Then** a line or area chart displays the command volume over time.
+2. [ ] **Given** the premium glassmorphic theme, **When** the chart is rendered, **Then** it must use the primary brand colors and gradients to match the UI.
+3. [ ] **Given** a mouse hover on the chart, **When** hovering over a point, **Then** a glassmorphic tooltip shows exact counts for that hour.
+
+## 5. Implementation Plan
+- [ ] Step 1: Add an aggregation method to `dashboard.service.ts` to fetch hourly counts from the `transactions` table.
+- [ ] Step 2: Create the `/api/stats/activity` endpoint.
+- [ ] Step 3: Install a charting library (e.g., `recharts` or `lucide-react` compatible library).
+- [ ] Step 4: Implement the `ActivityChart` component into the middle column of the dashboard.

tickets/2026-01-08-dashboard-control-panel.md

@@ -0,0 +1,38 @@
+# DASH-004: Administrative Control Panel
+
+**Status:** Draft
+**Created:** 2026-01-08
+**Tags:** dashboard, control-panel, bot-actions, operations
+
+## 1. Context & User Story
+* **As a:** Bot Administrator
+* **I want to:** Execute common maintenance tasks directly from the dashboard buttons.
+* **So that:** I don't have to use terminal commands or Discord slash commands for system-level operations.
+
+## 2. Technical Requirements
+### Data Model Changes
+- [ ] N/A.
+
+### API / Interface
+- [ ] `POST /api/actions/reload-commands`: Triggers the bot's command loader.
+- [ ] `POST /api/actions/clear-cache`: Clears internal bot caches.
+- [ ] `POST /api/actions/maintenance-mode`: Toggles a maintenance flag for the bot.
+
+## 3. Constraints & Validations (CRITICAL)
+- **Input Validation:** Standard JSON body with optional `reason` field.
+- **System Constraints:** 
+    - Actions must be idempotent where possible.
+    - Actions must provide a response within 10 seconds.
+- **Business Logic Guardrails:** 
+    - **SECURITY**: This endpoint MUST require high-privilege authentication (currently we have single admin assumption, but token-based check should be planned).
+    - Maintenance mode toggle must be logged to the event feed.
+
+## 4. Acceptance Criteria
+1. [ ] **Given** a "Quick Actions" card, **When** the "Reload Commands" button is clicked, **Then** the bot reloads its local command files and posts a "Success" event to the feed.
+2. [ ] **Given** a running bot, **When** the "Clear Cache" button is pushed, **Then** the bot flushes its internal memory maps and the memory usage metric reflects the drop.
+
+## 5. Implementation Plan
+- [ ] Step 1: Create an `action.service.ts` to handle the logic of triggering bot-specific functions.
+- [ ] Step 2: Implement the `/api/actions` route group.
+- [ ] Step 3: Design a "Quick Actions" card with premium styled buttons in `Dashboard.tsx`.
+- [ ] Step 4: Add loading states to buttons to show when an operation is "In Progress."

tickets/2026-01-08-real-time-dashboard-updates.md

@@ -0,0 +1,43 @@
+# DASH-002: Real-time Live Updates via WebSockets
+
+**Status:** Draft
+**Created:** 2026-01-08
+**Tags:** dashboard, websocket, real-time, performance
+
+## 1. Context & User Story
+* **As a:** Bot Administrator
+* **I want to:** See metrics and events update instantly on my screen without refreshing or waiting for polling intervals.
+* **So that:** I can react immediately to errors or spikes in latency and have a dashboard that feels "alive."
+
+## 2. Technical Requirements
+### Data Model Changes
+- [ ] No database schema changes required.
+- [ ] Redis or an in-memory event emitter might be useful for broadcasting events.
+
+### API / Interface
+- [ ] Establish a WebSocket endpoint at `/ws/stats`.
+- [ ] Define the message protocol:
+    - `HEARTBEAT`: Client to server to keep connection alive.
+    - `STATS_UPDATE`: Server to client containing partial or full `DashboardStats`.
+    - `NEW_EVENT`: Server to client when a transaction or moderation case occurs.
+
+## 3. Constraints & Validations (CRITICAL)
+- **Input Validation:** WS messages must be validated using Zod.
+- **System Constraints:** 
+    - Limit to 10 concurrent WS connections to prevent server strain.
+    - Maximum message size: 16KB.
+    - Connection timeout: 60s of inactivity triggers a disconnect.
+- **Business Logic Guardrails:** 
+    - Websocket updates should not exceed 1 update per second for metrics.
+    - Events are pushed immediately as they occur.
+
+## 4. Acceptance Criteria
+1. [ ] **Given** the dashboard is open, **When** a command is run in Discord, **Then** the "Recent Events" list updates instantly on the web UI.
+2. [ ] **Given** a changing network environment, **When** the bot's ping fluctuates, **Then** the "Avg Latency" card updates in real-time.
+3. [ ] **Given** a connection loss, **When** the network returns, **Then** the client automatically reconnects to the WS room.
+
+## 5. Implementation Plan
+- [ ] Step 1: Integrate a WebSocket library (e.g., `bun`'s native `ws` or `socket.io`) into `web/src/server.ts`.
+- [ ] Step 2: Implement a broadcast system in `dashboard.service.ts` to push events to the WS handler.
+- [ ] Step 3: Create a `useDashboardSocket` hook in the frontend to handle connection lifecycle.
+- [ ] Step 4: Refactor `Dashboard.tsx` to prefer WebSocket data over periodic polling.