diff --git a/tickets/2026-01-07-move-status-to-footer.md b/tickets/2026-01-07-move-status-to-footer.md
deleted file mode 100644
index 184e8ab..0000000
--- a/tickets/2026-01-07-move-status-to-footer.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# 2026-01-07-move-status-to-footer
-
-**Status:** Done
-**Created:** 2026-01-07
-**Tags:** ui, layout, enhancement
-
-## 1. Context & User Story
-* **As a:** User of the Web Interface
-* **I want to:** see the system status and uptime information in the footer of every page
-* **So that:** the main content area is less cluttered and status information is globally available.
-
-## 2. Technical Requirements
-### Data Model Changes
-- [ ] N/A
-
-### API / Interface
-- [x] **Home Page:** Remove the "Status" card from the main content.
-- [x] **Layout:** Update `BaseLayout` (or `layout.ts`) to accept or calculate uptime/status information and render it in the `<footer>`.
-
-## 3. Constraints & Validations (CRITICAL)
-- **Visuals:** The footer should remain clean and not be overcrowded.
-- **Functionality:** The existing client-side uptime counter (via `#uptime-display` in `script.js`) must continue to work. Ensure the ID or data attributes it relies on are preserved in the new location.
-
-## 4. Acceptance Criteria
-1. [x] The "Status" card is removed from the Home page content.
-2. [x] The Footer displays "System Operational" and the running Uptime counter.
-3. [x] navigation to other pages (if any) still shows the status in the footer.
-
-## 5. Implementation Plan
-- [x] Edit `src/web/routes/home.ts` to remove the Status card.
-- [x] Edit `src/web/views/layout.ts` to add the Status HTML structure to the footer.
-- [x] Verify `script.js` selector targets the new element correctly.
-
-## Implementation Notes
-- Moved Status/Uptime logic from `home.ts` to `layout.ts` (footer).
-- Calculated server-side uptime for initial rendering to prevent flash.
-- Preserved `id="uptime-display"` and `data-start-timestamp` for `script.js` compatibility.
-- Updated tests to verify uptime presence in global layout.
diff --git a/tickets/2026-01-07-web-interface-feature-expansion.md b/tickets/2026-01-07-web-interface-feature-expansion.md
deleted file mode 100644
index 5cfcb6c..0000000
--- a/tickets/2026-01-07-web-interface-feature-expansion.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# 2026-01-07-web-interface-feature-expansion
-
-**Status:** Draft
-**Created:** 2026-01-07
-**Tags:** product-design, feature-request, ui
-
-## 1. Context & User Story
-* **As a:** Bot Administrator
-* **I want to:** have more useful features on the web dashboard
-* **So that:** getting insights into the bot's performance and managing it becomes easier than using text commands.
-
-## 2. Technical Requirements
-### Proposed Features
-1.  **Live Console / Activity Feed:**
-    *   Stream abbreviated logs or important events (e.g., "User X joined", "Command Y executed").
-2.  **Metrics Dashboard:**
-    *   Visual charts for command usage (Top 5 commands).
-    *   Memory usage and CPU load over time.
-    *   API Latency gauge.
-3.  **Command Palette / Control Panel:**
-    *   Buttons to clear cache, reload configuration, or restart specific services.
-4.  **Guild/User Browser:**
-    *   Read-only list of top guilds or users by activity/economy balance.
-
-### Data Model Changes
-- [ ] May require exposing existing Service data to the Web module.
-
-### API / Interface
-- [ ] `GET /api/stats` or `WS` subscription for metrics.
-- [ ] `GET /api/logs` (tail).
-
-## 3. Constraints & Validations (CRITICAL)
-- **Security:** Modifying bot state (Control Panel) requires strict authentication/authorization (Future Ticket). For now, read-only/safe actions only.
-- **Privacy:** Do not expose sensitive user PII in the web logs or dashboard without encryption/masking.
-
-## 4. Acceptance Criteria
-1. [ ] A list of prioritized features is approved.
-2. [ ] UI Mockups (code or image) for the "Dashboard" view.
-3. [ ] Data sources for these features are identified in the codebase.
-
-## 5. Implementation Plan
-- [x] **Phase 1:** Brainstorm & Mockup (This Ticket).
-- [ ] **Phase 2:** Create individual implementation tickets for selected features (e.g., "Implement Metrics Graph").
-
-## Implementation Notes
-- Created `/dashboard` route with a code-based mockup.
-- Implemented responsive CSS Grid layout for the dashboard.
-- Integrated real `AuroraClient` data for Server Count, User Count, and Command Count.
-- Added placeholder UI for "Live Activity" and "Metrics".
-- Next steps: Connect WebSocket "HEARTBEAT" to the dashboard metrics and implement real logger streaming.
diff --git a/tickets/2026-01-07-websocket-realtime-data.md b/tickets/2026-01-07-websocket-realtime-data.md
deleted file mode 100644
index 2f056a8..0000000
--- a/tickets/2026-01-07-websocket-realtime-data.md
+++ /dev/null
@@ -1,42 +0,0 @@
-# 2026-01-07-websocket-realtime-data
-
-**Status:** Done
-**Created:** 2026-01-07
-**Tags:** feature, websocket, realtime, research
-
-## 1. Context & User Story
-* **As a:** Developer
-* **I want to:** implement a WebSocket connection between the frontend and the Aurora server
-* **So that:** I can stream real-time data (profiling, logs, events) to the dashboard without manual page refreshes.
-
-## 2. Technical Requirements
-### Data Model Changes
-- [ ] N/A
-
-### API / Interface
-- [x] **Endpoint:** `/ws` (Upgrade Upgrade: websocket).
-- [x] **Protocol:** Define a simple JSON message format (e.g., `{ type: "UPDATE", data: { ... } }`).
-
-## 3. Constraints & Validations (CRITICAL)
-- **Bun Support:** Use Bun's native `Bun.serve({ websocket: { ... } })` capabilities if possible.
-- **Security:** Ensure that the WebSocket endpoint is not publicly abusable (consider simple token or origin check if necessary, though internal usage is primary context for now).
-- **Performance:** Do not flood the client. Throttle updates if necessary.
-
-## 4. Acceptance Criteria
-1. [x] Server accepts WebSocket connections on `/ws`.
-2. [x] Client (`script.js`) successfully connects to the WebSocket.
-3. [x] Server sends a "Hello" or "Ping" packet.
-4. [x] Client receives and logs the packet.
-5. [x] (Stretch) Stream basic uptime or heartbeat every 5 seconds.
-
-## 5. Implementation Plan
-- [x] Modify `src/web/server.ts` to handle `websocket` upgrade in `Bun.serve`.
-- [x] Create a message handler object/function to manage connected clients.
-- [x] Update `src/web/public/script.js` to initialize `WebSocket`.
-- [x] Test connection stability.
-
-## Implementation Notes
-- Enabled `websocket` in `Bun.serve` within `src/web/server.ts`.
-- Implemented a heartbeat mechanism broadcasting `HEARTBEAT` events every 5s.
-- Updated `script.js` to auto-connect, handle reconnects, and update a visual "online" indicator.
-- Added `src/web/websocket.test.ts` to verify protocol upgrades and messaging.