Revert widget/dashboard architecture and clean up artifacts

.github/copilot-instructions.md

@@ -2,12 +2,12 @@
 
 ## Project Overview
 
-**Gearbox** is a general-purpose monitoring and management platform with a plugin-based architecture and composable widgets. It consists of two Go applications:
+**Gearbox** is a general-purpose monitoring and management platform with a plugin-based architecture. It consists of two Go applications:
 
 1. **gearbox** - Web dashboard (port 3000)
 2. **gearbox-agent** - Agent running on monitored servers (port 8405)
 
-**Key Principle**: This is a plugin-based architecture. The framework provides shared services, and plugins provide widgets and functionality.
+**Key Principle**: This is a plugin-based architecture. The framework provides shared services, and plugins provide functionality.
 
 ## Architecture
 
@@ -35,8 +35,7 @@ Monitored Server → gearbox-agent (collects) → API/WebSocket → gearbox (dis
 
 **Plugins** (gearbox/internal/plugins/):
 - Self-contained feature modules
-- Provide widgets (reusable UI components)
-- Optional predefined dashboards
+- Provide pages and API handlers
 - Domain-specific logic
 
 Current plugins: HAProxy, Metrics, Services, Certificates, Logs, Traffic, Alerts, OS Updates
@@ -62,7 +61,6 @@ cd gearbox && make dev
 - `internal/plugins/` - Feature plugins
 - `internal/framework/templates/` - Templ templates
 - `static/` - JavaScript, CSS, assets
-- `data/dashboards/` - YAML dashboard definitions
 
 ### Gearbox Agent (gearbox-agent/)
 
@@ -81,19 +79,12 @@ cd gearbox-agent && make deploy
 
 ## Code Guidelines
 
-### Adding New Widgets
-
-1. Create widget in appropriate plugin directory
-2. Register in plugin's widget registry
-3. Add Templ template for rendering
-4. Update plugin documentation
-
 ### Adding New Plugins
 
 1. Create directory in `internal/plugins/`
 2. Implement plugin interface
 3. Register in framework plugin system
-4. Add widgets and optional dashboards
+4. Add pages and templates
 5. Update docs/plugins.md
 
 ### Template System (Templ)
@@ -125,13 +116,6 @@ make test
 
 ## Common Tasks
 
-### Adding a Dashboard Widget
-
-1. Create widget component in plugin
-2. Add Templ template
-3. Register in widget palette
-4. Add to dashboard YAML or via UI
-
 ### Modifying API Endpoints
 
 **Agent side:**
@@ -166,7 +150,7 @@ make test
 - Keep plugins self-contained
 - Use framework services (don't duplicate functionality)
 - Follow plugin architecture patterns
-- Document new widgets in docs/plugins.md
+- Document new plugins in docs/plugins.md
 
 ## Documentation
 
@@ -207,4 +191,4 @@ make test
 - Event bus for decoupled communication
 - Database connection pooling
 - Efficient template rendering
-- Widget-level updates (not full page reloads)
+- Partial updates via HTMX (not full page reloads)

CLAUDE.md

@@ -2,32 +2,26 @@
 
 This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
 
-## Model Preference
-
-**Default Model:** Use Claude Sonnet (not Opus) for all tasks unless specifically requested otherwise by the user. Sonnet provides the optimal balance of speed, cost, and capability for typical development tasks.
-
 ## Project Overview
 
-This repository contains **Gearbox**, a general-purpose monitoring and management platform with a plugin-based architecture and composable widgets.
+This repository contains **Gearbox**, a general-purpose monitoring and management platform with a plugin-based architecture.
 
 ### What is Gearbox?
 
-A plugin-based server monitoring and management platform designed for DevOps. Provides real-time visibility into servers, services, and infrastructure through composable widgets.
+A plugin-based server monitoring and management platform designed for DevOps. Provides real-time visibility into servers, services, and infrastructure through purpose-built plugin pages.
 
 **Architecture:**
 
 - **gearbox-agent** - Go binary installed on monitored servers/workstations to gather data and expose secure API/WebSocket
-- **gearbox** - Web dashboard (port 3000) for monitoring multiple servers with widget-based dashboards
-- **Plugins** - Self-contained modules providing widgets and functionality (HAProxy, Metrics, Logs, Services, Certificates, Traffic, Alerts, OS Updates)
-- **Widgets** - Reusable UI components that display data or provide controls
-- **Dashboards** - YAML-defined pages arranging widgets in grid layouts
+- **gearbox** - Web dashboard (port 3000) for monitoring multiple servers
+- **Plugins** - Self-contained modules providing pages, API handlers, and functionality (HAProxy, Metrics, Logs, Services, Certificates, Traffic, Alerts, OS Updates)
 
 **Key Principles:**
 
-- Plugin-based with composable widgets and components
+- Plugin-based architecture with shared framework components
 - gearbox-agent can run on ANY Linux system (servers, workstations, HAProxy hosts, TrueNAS, Docker hosts)
 - Multi-server support: gearbox talks to many different gearbox-agent instances
-- Configuration via web UI or YAML files (GitOps-ready)
+- Configuration via web UI
 - HAProxy monitoring is ONE plugin, not the core purpose
 
 ## Dual-App Architecture
@@ -47,7 +41,7 @@ When troubleshooting, **ALWAYS check both codebases** and understand which serve
 
 ### Gearbox Dashboard (`gearbox/`)
 
-Web application for monitoring multiple servers. Plugin-based with widget architecture.
+Web application for monitoring multiple servers. Plugin-based architecture.
 
 **Post-Change Workflow:**
 
@@ -62,10 +56,9 @@ cd gearbox && make templ-generate && make build
 **Key directories:**
 
 - `internal/framework/` - Shared services and building blocks
-- `internal/plugins/` - 8 plugins providing 31 widgets total
+- `internal/plugins/` - 8 plugins
 - `internal/framework/templates/` - Templ templates
 - `static/` - JavaScript, CSS, assets
-- `data/dashboards/` - YAML dashboard definitions
 
 ### Gearbox Agent (`gearbox-agent/`)
 
@@ -88,7 +81,7 @@ cd gearbox-agent && make deploy
 
 ## Plugin Architecture
 
-8 plugins provide 31 widgets total: HAProxy, Metrics, Logs, Services, Certificates, Traffic, Alerts, OS Updates. Each plugin is self-contained in `internal/plugins/`. Framework provides shared services in `internal/framework/`.
+8 plugins: HAProxy, Metrics, Logs, Services, Certificates, Traffic, Alerts, OS Updates. Each plugin is self-contained in `internal/plugins/`. Framework provides shared services in `internal/framework/`.
 
 See [docs/plugins.md](docs/plugins.md) for complete plugin architecture documentation.
 
@@ -104,9 +97,10 @@ When a new feature is planned or a bug is reported:
 2. **Add to Project Board** — Add the issue to the GitHub Project board using `gh project item-add`
 3. **Create a Feature Branch** — Branch from `main` using the naming convention below
 4. **Do the Work** — Implement the feature or fix on the branch
-5. **Create a PR** — Use `gh pr create` targeting `main`, linked to the issue (use `Closes #N` in the body)
-6. **Track Progress** — Keep the project board and issues in sync
-7. **Complete** — When user confirms done: merge PR, close issue, move project card to Done
+5. **Ask Before Creating PR** — Always ask the user for confirmation before creating a PR. Do not create PRs automatically.
+6. **Create a PR** — Use `gh pr create` targeting `main`, linked to the issue (use `Closes #N` in the body)
+7. **Track Progress** — Keep the project board and issues in sync
+8. **Complete** — When user confirms done: merge PR, close issue, move project card to Done
 
 ### Branch Naming Convention
 
@@ -207,19 +201,12 @@ Store in `docs/` directory using kebab-case naming. Include TOC after main headi
 
 ## Common Development Tasks
 
-### Adding New Widgets
-
-1. Create widget in appropriate plugin directory
-2. Register in plugin's widget registry
-3. Add Templ template for rendering
-4. Update [docs/plugins.md](docs/plugins.md)
-
 ### Adding New Plugins
 
 1. Create directory in `internal/plugins/`
 2. Implement plugin interface
 3. Register in framework plugin system
-4. Add widgets and optional dashboards
+4. Add pages and templates
 5. Update [docs/plugins.md](docs/plugins.md)
 
 ### Modifying Templates (Templ)

DESIGN.md

@@ -0,0 +1,160 @@
+# Gearbox Design
+
+## What Is Gearbox?
+
+Gearbox is a universal, plugin-based monitoring and management platform for DevOps. It provides real-time visibility into servers, services, and infrastructure through a plugin-based architecture.
+
+Gearbox is **not** a single-purpose tool. HAProxy monitoring is one plugin among many. The platform monitors any Linux system: bare-metal servers, virtual machines, workstations, Docker hosts, NAS appliances, or anything else running Linux.
+
+## Design Goals
+
+- **Plugin-based extensibility** -- All monitoring capabilities live in self-contained plugins. The framework provides shared infrastructure; plugins implement features. Adding a new capability means adding a new plugin, not modifying the core.
+- **Plugin-based pages** -- Each plugin provides its own monitoring pages with purpose-built UI. Plugins use shared framework components (charts, tables, cards) for consistent presentation.
+- **Multi-server monitoring** -- A single Gearbox dashboard connects to many agents running on different servers. Every plugin page and data source is server-aware.
+- **Configuration as code** -- Server configurations and plugin settings can be managed through the web UI.
+- **Compile-time safety** -- Plugins are compiled into the binary (similar to Caddy). No runtime plugin loading, no reflection. Interfaces are checked at compile time. Templates use Templ for type-safe HTML generation.
+
+## Architecture
+
+### Dual-Application Model
+
+Gearbox consists of two Go applications:
+
+**gearbox** (Dashboard) -- Web application on port 3000. Connects to multiple agents, renders UI, and manages users. Contains 7 plugins.
+
+**gearbox-agent** (Agent) -- Lightweight service on port 8405. Runs on each monitored server. Collects data via plugin-based collectors, exposes a REST API, and publishes real-time events over WebSocket. Contains 7 data collection plugins.
+
+```text
+┌────────────────────────────────────┐
+│         Browser                    │
+│   HTTP pages, SSE, WebSocket       │
+└──────────────┬─────────────────────┘
+               │
+┌──────────────▼─────────────────────┐
+│     Gearbox Dashboard (:3000)      │
+│                                    │
+│  Plugins → Pages → UI              │
+│  Auth, Sessions, Permissions       │
+│  SQLite database                   │
+└──────┬────────────┬────────────────┘
+       │            │
+       ▼            ▼
+┌─────────────┐  ┌─────────────┐
+│  Agent :8405│  │  Agent :8405│  ...N agents
+│  Server A   │  │  Server B   │
+│             │  │             │
+│  Collectors │  │  Collectors │
+│  REST API   │  │  REST API   │
+│  WebSocket  │  │  WebSocket  │
+└─────────────┘  └─────────────┘
+```
+
+### Data Flow
+
+1. **Agent collects** -- Plugin collectors run on intervals, gathering system metrics, service stats, log data, certificate info, and more from the host.
+2. **Agent exposes** -- Collected data is available via REST API endpoints. Changes are broadcast as WebSocket events.
+3. **Dashboard fetches** -- The agent client (80+ methods) calls agent REST APIs over HTTPS with API key authentication.
+4. **Dashboard renders** -- Plugin handlers pass data to Templ components for display.
+5. **Browser updates** -- Real-time events flow from agent → dashboard → browser via WebSocket/SSE for live updates without polling.
+
+## Plugin System
+
+### How Plugins Work
+
+Plugins register themselves at compile time via `init()` functions. On startup, the framework initializes each plugin with a `Dependencies` struct containing database access, logger, event hub, authentication, agent client, and configuration.
+
+Each plugin is self-contained: it defines its own routes, handlers, templates, and permissions. Plugins cannot call each other directly; they communicate through the event bus.
+
+### Feature Flags
+
+Plugins progress through a state machine: `disabled` → `alpha` → `beta` → `production`. Alpha and beta plugins must be explicitly enabled by the user. Production plugins are enabled by default. The `disabled` state excludes the plugin from the build entirely.
+
+### Dashboard Plugins (7)
+
+| Plugin       | Purpose                                      |
+|--------------|----------------------------------------------|
+| HAProxy      | HAProxy overview, status grid, and backend/frontend/server monitoring |
+| Metrics      | Historical CPU, memory, disk, network charts |
+| Services     | Systemd service monitoring and control       |
+| Certificates | TLS certificate expiration tracking          |
+| Logs         | Real-time log viewing and search             |
+| Traffic      | Traffic analysis and GeoIP visualization     |
+| Alerts       | Alert rules, notifications, and history      |
+
+### Agent Plugins (7)
+
+| Plugin   | Purpose                                                   |
+|----------|-----------------------------------------------------------|
+| HAProxy  | Stats socket and stats URL collection                     |
+| Metrics  | System metrics (CPU, memory, disk, network, load, uptime) |
+| Logs     | Log file access and streaming                             |
+| Certs    | Certificate discovery and management                      |
+| Traffic  | Traffic data collection                                   |
+| Security | Fail2ban and firewall integration                         |
+| Updates  | OS package management (APT)                               |
+
+### Agent Facades
+
+Each dashboard plugin defines a narrow interface for the agent methods it needs, rather than depending on the full agent client. This keeps plugins decoupled and testable.
+
+```go
+type AgentClient interface {
+    GetCertificates() (*agent.CertificatesResponse, error)
+}
+var _ AgentClient = (*agent.Client)(nil)
+```
+
+## UI Architecture
+
+### Plugin Pages
+
+Each plugin provides its own pages with purpose-built UI. Plugins use shared framework components (charts, tables, cards, panels) for consistent presentation. Pages are server-side rendered with Templ and enhanced with HTMX for dynamic updates.
+
+### Shared Components
+
+The framework provides reusable UI components that plugins use to build their pages:
+
+- **Charts** -- Chart.js-based components for time-series data (CPU, memory, network, etc.)
+- **Cards** -- Status cards, metric cards for at-a-glance information
+- **Tables** -- Data tables for detailed listings
+- **Panels** -- Collapsible containers for organizing content
+
+### Data Flow to UI
+
+Plugins expose API endpoints that return HTML partials (for HTMX) or JSON (for JavaScript). Pages use HTMX polling or SSE for real-time updates without full page reloads.
+
+## Technology Stack
+
+### Backend
+
+- **Go** -- Primary language for both applications
+- **Chi** -- HTTP router
+- **Templ** -- Type-safe HTML template engine (compiles to Go)
+- **SQLite** -- Dashboard database (WAL mode)
+- **Gorilla WebSocket** -- WebSocket connections
+- **slog** -- Structured logging
+
+### Frontend
+
+- **Tailwind CSS** -- Utility-first styling
+- **Alpine.js** -- Lightweight reactivity for interactive components
+- **Chart.js** -- Data visualization
+- Server-side rendered HTML with progressive enhancement (no SPA framework)
+
+## Security Model
+
+- **Agent authentication** -- API keys generated on first run, required for all endpoints except `/health`
+- **WebSocket authentication** -- Two-step token exchange: API key → short-lived token → WebSocket connection
+- **Dashboard authentication** -- Password-based with optional WebAuthn/FIDO2
+- **Authorization** -- Component-action permission model (e.g., `certificates:view`, `alerts:manage`)
+- **Transport** -- HTTPS with TLS 1.2+ between dashboard and agents. Optional CA cert pinning.
+- **Rate limiting** -- Configurable per-endpoint rate limits
+
+## Key Patterns
+
+- **Compile-time plugin registration** via `init()` and a global registry
+- **Dependency injection** through a `Dependencies` struct passed to each plugin
+- **Interface segregation** with per-plugin agent facades
+- **Event-driven communication** between plugins via a pub/sub event hub
+- **Middleware chain** for HTTP concerns (auth, CSRF, logging, rate limiting, recovery)
+- **Server-side rendering** with Templ components, enhanced with Alpine.js for interactivity