plugin-first-web-dashboard

Plugin-First Web Dashboard

Use when adding a web UI to a headless, MCP-first, plugin-oriented service—especially a service deployed remotely in Docker, NAS, or a router and expected to remain online without a local game/client process.

Core approach

Treat the dashboard as a Monitor / Operate surface, not a marketing page. Start from the existing repository contracts, then build a small vertical slice that proves the data path before adding visual breadth.

1. Read the project README, agent/development rules, architecture docs, plugin API/loader docs, HTTP server, runtime context, storage API, and deployment manifest.
2. Trace the existing data sources and tool handlers to their definitions. Reuse established read-only services instead of duplicating SQL or authentication logic.
3. Keep concrete UI and dashboard routes in a plugin. Add only generic core infrastructure: route registration, authenticated dispatch, lifecycle cleanup, and narrowly scoped read-only service adapters.
4. Define an MVP around the always-on advantage: service health, authentication/WebSocket state, online friends, recent events, and plugin/backup status. Exclude local-client features such as launching VRChat, SteamVR detection, game logs, tray behavior, and desktop memory tools unless the deployment explicitly supports them.
5. Use a dark, dense, glanceable visual system with strong status hierarchy. Raycast/Linear-like precision is a useful reference, but transform the principles into an original UI rather than cloning a proprietary surface.
6. Verify the implementation with syntax checks, repository smoke tests, diff checks, and an actual authenticated endpoint probe when a running deployment is available. Report skipped checks honestly.

Core/plugin boundary

The core should expose a minimal, explicit mechanism such as:

• ctx.httpRoutes: a route registry owned by the core;
• api.http.registerRoute({ method, path, handler }): plugin-only route registration;
• authenticated dispatch before route execution;
• route cleanup on unload and hot reload;
• read-only services such as dashboard.snapshot, dashboard.friends, and dashboard.events.