docs: clarify Hermes dashboard roadmap

docs/hermes_dashboard_roadmap.md

@@ -1,10 +1,16 @@
-Perfect. Use this updated prompt for devn / Codex / Claude Code running inside your VM.
+# Hermes Mission Control Dashboard Roadmap
+
+This roadmap defines the production-grade Hermes Mission Control web UI for the `bytelyst-devops-tools` repo.
+
+Repo path used by the scheduled implementation job:
+`/root/bytelyst.ai/repos/bytelyst-devops-tools`
+
+Role:
+Principal Fullstack Engineer + DevOps Architect.
 
-You are a Principal Fullstack Engineer + DevOps Architect.
-Repo:
-`~/repos/bytelyst-devops-tools`
 Task:
-Build a rich, production-grade web UI called **Hermes Mission Control** inside the `bytelyst-devops-tools` repo.
+Build a rich, production-grade web UI called **Hermes Mission Control** inside the existing dashboard app, reusing existing architecture and conventions.
+
 Context:
 I am a solopreneur/founder running ByteLyst and planning to launch/manage 50+ products, apps, services, internal tools, automations, and AI agents. Hermes is my DevOps/automation/agent execution brain. I need a dashboard that clearly shows what Hermes is working on, what it completed, what failed, what is blocked, what needs my attention, and what should happen next.
 This should not be a toy logs page. Build it like an AI DevOps command center for a solo founder managing many products.
@@ -452,10 +458,11 @@ export interface HermesOverview {
   productsTouchedRecently: number;
   founderAttentionCount: number;
 }
+```
 
-⸻
+---
 
-Service layer
+# Service layer
 
 Create a clean data abstraction, for example:
 
@@ -487,9 +494,9 @@ Later this should be swappable with:
 * API endpoint
 * Hermes daemon telemetry
 
-⸻
+---
 
-UI requirements
+# UI requirements
 
 Make it beautiful and professional.
 
@@ -537,9 +544,9 @@ Suggested components:
 * ErrorState
 * LoadingSkeleton
 
-⸻
+---
 
-Founder-specific intelligence
+# Founder-specific intelligence
 
 Add computed insights:
 
@@ -582,9 +589,9 @@ Display:
 * products advanced
 * recommended next actions
 
-⸻
+---
 
-README update
+# README update
 
 Update README or create docs/hermes-dashboard.md.
 
@@ -608,9 +615,9 @@ Include real telemetry integration plan:
 6. Add GitHub/CI/CD/deployment integrations.
 7. Add notifications.
 
-⸻
+---
 
-Quality bar
+# Quality bar
 
 Before final response:
 
@@ -626,9 +633,39 @@ Before final response:
 * verify responsive layout
 * verify mock data loads
 
-⸻
+---
 
-Git workflow
+# Implementation status checklist
+
+Update this checklist only after each item has evidence from source review, tests, build output, or browser verification.
+
+- [ ] Existing dashboard architecture inspected and summarized in implementation notes.
+- [ ] Data model and mock service implemented outside UI components.
+- [ ] `/hermes` mission control route renders from the service layer.
+- [ ] `/hermes/tasks` ledger has search, filters, sorting, pagination, expandable details, and JSON export.
+- [ ] `/hermes/tasks/[id]` detail route shows summary, timeline, execution details, and learning sections.
+- [ ] `/hermes/products` portfolio route includes priority, attention, no-recent-activity, repeated-failure, and recently-shipped views.
+- [ ] `/hermes/history` route includes historical analytics with charts or accessible visual bars.
+- [ ] `/hermes/agents` route shows agent/tool/integration health.
+- [ ] `/hermes/settings` route shows editable-looking configuration panels and import/export affordances backed by mock data.
+- [ ] Documentation created or updated with routes, run commands, mock data locations, and real telemetry integration plan.
+- [ ] Lint passes or any pre-existing lint failures are explicitly identified.
+- [ ] Typecheck passes.
+- [ ] Unit/component tests pass.
+- [ ] Production build passes.
+- [ ] E2E or browser smoke verification covers all new routes with no console errors.
+- [ ] Responsive layout checked at desktop and mobile widths.
+
+Known roadmap assumptions to handle safely during implementation:
+
+- Start with read-only mock data. Do not introduce credential, deployment, notification, or write-side operations without an explicit API and authorization plan.
+- Treat telemetry integrations as documentation and service-boundary placeholders until real Hermes event sources are available.
+- Do not mark live/real-time status as production telemetry unless it is backed by an actual source; label seed data clearly as mock/demo data.
+- Avoid new third-party libraries unless existing dependencies cannot meet the UI requirement.
+
+---
+
+# Git workflow
 
 Commit incrementally:
 
@@ -641,9 +678,9 @@ Commit incrementally:
 
 Push to origin main.
 
-⸻
+---
 
-Final response format
+# Final response format
 
 When done, report:
 
@@ -662,4 +699,5 @@ cd ~/repos/bytelyst-devops-tools
 
 Then paste:
 
-Build Hermes Mission Control as described above. Inspect existing architecture first, reuse repo conventions, implement with clean TypeScript, mock service layer, rich dashboard UI, docs, lint/build verification, and incremental commits to origin main.
+Build Hermes Mission Control as described above. Inspect existing architecture first, reuse repo conventions, implement with clean TypeScript, mock service layer, rich dashboard UI, docs, lint/build verification, and incremental commits to origin main.
+```