# 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.

Task:
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.
Before coding:
1. `cd /root/bytelyst.ai/repos/bytelyst-devops-tools`
2. Inspect the repo structure.
3. Identify frontend/backend framework, package manager, routes, styling, existing dashboard/admin patterns, auth, API conventions, test setup, lint/build commands.
4. Reuse existing architecture wherever possible.
5. Do not rewrite the whole repo.
6. Commit incrementally to `origin main` unless repo policy says otherwise.
7. Update or create a roadmap/checklist file tracking progress.
Primary route:
Create a Hermes dashboard entry point:
- `/hermes`
- or the closest matching route based on existing app structure.
Dashboard name:
**Hermes Mission Control**
Core dashboard goals:
- Show live Hermes status.
- Show active work.
- Show completed work.
- Show failed/stuck/blocked work.
- Show historical activity.
- Show product/app/service-level progress.
- Show what needs founder attention.
- Show next best actions.
- Make Hermes accountable and observable.
Build these sections/pages.
---
# 1. `/hermes` — Executive Mission Control
Show top-level cards:
- Hermes status: Running / Idle / Degraded / Error
- Active tasks
- Completed today
- Completed this week
- Failed tasks
- Blocked tasks
- Average task duration
- Success rate
- Products touched recently
- Tasks needing founder attention
- Upcoming scheduled jobs
- Last Hermes action
- Next recommended action
Add major dashboard panels:
## A. Active Missions
Show what Hermes is currently doing:
- task title
- product/app
- status
- progress %
- current step
- started time
- estimated remaining placeholder
- assigned agent/tool
- priority
## B. Founder Attention Queue
Show items where I must act:
- approval needed
- missing credentials
- failed deployment
- failing tests
- blocked by unclear requirement
- cost/risk warning
- expired token/API key
- product inactive too long
- repeated failures
## C. What Hermes Did For Me
Summaries:
- today
- this week
- last 30 days
Examples:
- fixed bugs
- created PRs
- deployed services
- ran audits
- updated docs
- checked health
- investigated failures
- generated reports
## D. Product Health Snapshot
For 50+ products/apps/services:
- product name
- health score
- latest activity
- open tasks
- failed tasks
- last deployment
- last commit
- production status
- attention needed badge
## E. Next Best Actions
Split into:
- “Hermes can do automatically”
- “Needs Saravana’s decision”
---
# 2. `/hermes/tasks` — Task Ledger
Create a searchable/filterable task table.
Columns:
- Task
- Product
- Status
- Priority
- Type
- Source trigger
- Assigned agent
- Created
- Started
- Completed
- Duration
- Retry count
- Last action
- Next action
Statuses:
- queued
- running
- blocked
- completed
- failed
- skipped
- cancelled
Priorities:
- P0
- P1
- P2
- P3
Task types:
- build
- deploy
- bugfix
- monitoring
- audit
- refactor
- documentation
- research
- security
- cost-optimization
- release
- maintenance
- product-planning
Source triggers:
- manual
- cron
- GitHub
- monitoring alert
- email
- CLI
- webhook
- local agent
- Hermes planner
Features:
- Search
- Status filter
- Product filter
- Priority filter
- Date filter
- Sort
- Pagination
- Expandable row details
- Export JSON button if simple to implement
---
# 3. `/hermes/tasks/[id]` — Task Detail
For each task show:
## Summary
- title
- description
- product
- status
- priority
- owner
- current step
- result
- blocker reason
- final output
## Timeline
Chronological events:
- created
- planned
- tool selected
- command executed
- file changed
- test run
- error detected
- retry attempted
- PR created
- deployment completed
- task completed
## Execution Details
Show:
- commands executed
- tools called
- files modified
- Git branch
- commit SHA
- PR URL
- deployment URL
- test result
- logs
- error stack/message
- retry history
- artifacts generated
## Hermes Learning
Add section:
- lesson learned
- suggested memory update
- prevention for next time
- recurring issue detection
---
# 4. `/hermes/products` — 50-Product Portfolio View
Create product registry dashboard.
Each product card/table row should show:
- name
- slug
- category
- priority
- health score
- status
- repo URL
- production URL
- staging URL
- last Hermes activity
- last commit placeholder
- last deployment placeholder
- active tasks
- completed tasks
- failed tasks
- blocked tasks
- tags
- needs attention
Categories:
- SaaS
- AI app
- mobile app
- internal tool
- website
- API
- automation
- browser extension
- data pipeline
- DevOps tool
Add views:
- All products
- High priority
- Needs attention
- No recent activity
- Repeated failures
- Recently shipped
---
# 5. `/hermes/history` — Historical View
Show historical analytics:
- completed tasks over time
- failed tasks over time
- blocked tasks over time
- most active products
- most neglected products
- common failure categories
- average task duration trend
- weekly progress summary
- monthly progress summary
Use charts if the repo already has a chart library.
If no chart library exists, implement simple clean visual bars/cards first.
---
# 6. `/hermes/agents` — Agent & Tool Observability
Show Hermes ecosystem health:
- Hermes core
- OpenClaw integration placeholder
- GitHub integration
- local VM runner
- CLI runner
- scheduler/cron
- deployment tools
- monitoring tools
- notification tools
- model/LLM provider placeholder
- secrets/config health
For each tool/agent show:
- status
- last success
- last failure
- calls today
- failure rate
- average latency
- config issue flag
---
# 7. `/hermes/settings` — Config
Create clean settings UI for:
- products registry
- task categories
- priority rules
- notification rules
- auto-retry rules
- approval thresholds
- retention period
- import/export JSON config
- demo/mock data toggle
No need to build real persistence if backend is not present yet. Use mock service/data layer first.
---
# Data model
Create TypeScript types/interfaces in a clean location such as:
- `src/types/hermes.ts`
- `types/hermes.ts`
- or existing repo convention
Use these models:
```ts
export type HermesStatus = "running" | "idle" | "degraded" | "error";
export type HermesTaskStatus =
  | "queued"
  | "running"
  | "blocked"
  | "completed"
  | "failed"
  | "skipped"
  | "cancelled";
export type HermesPriority = "P0" | "P1" | "P2" | "P3";
export type HermesTaskType =
  | "build"
  | "deploy"
  | "bugfix"
  | "monitoring"
  | "audit"
  | "refactor"
  | "documentation"
  | "research"
  | "security"
  | "cost-optimization"
  | "release"
  | "maintenance"
  | "product-planning";
export interface HermesProduct {
  id: string;
  name: string;
  slug: string;
  description: string;
  category: string;
  repoUrl?: string;
  productionUrl?: string;
  stagingUrl?: string;
  owner: string;
  priority: HermesPriority;
  status: "active" | "paused" | "maintenance" | "archived" | "idea";
  healthScore: number;
  tags: string[];
  lastHermesActivityAt?: string;
  lastDeploymentAt?: string;
  lastCommitAt?: string;
  needsAttention: boolean;
  createdAt: string;
  updatedAt: string;
}
export interface HermesTask {
  id: string;
  title: string;
  description: string;
  productId: string;
  status: HermesTaskStatus;
  priority: HermesPriority;
  type: HermesTaskType;
  source:
    | "manual"
    | "cron"
    | "github"
    | "monitoring-alert"
    | "email"
    | "cli"
    | "webhook"
    | "local-agent"
    | "hermes-planner";
  createdAt: string;
  startedAt?: string;
  completedAt?: string;
  durationMs?: number;
  retryCount: number;
  assignedAgent: string;
  tags: string[];
  progressPercent: number;
  currentStep?: string;
  lastAction?: string;
  nextAction?: string;
  blockerReason?: string;
  summary?: string;
  result?: string;
  error?: string;
}
export interface HermesEvent {
  id: string;
  taskId: string;
  timestamp: string;
  level: "debug" | "info" | "warn" | "error" | "success";
  eventType:
    | "created"
    | "planned"
    | "started"
    | "tool-called"
    | "command-executed"
    | "file-changed"
    | "test-run"
    | "error"
    | "retry"
    | "blocked"
    | "completed"
    | "deployment"
    | "pr-created"
    | "memory-suggested";
  message: string;
  metadata?: Record<string, unknown>;
  toolName?: string;
  command?: string;
  artifactUrl?: string;
}
export interface HermesRun {
  id: string;
  taskId: string;
  startedAt: string;
  endedAt?: string;
  status: HermesTaskStatus;
  logs: string[];
  metrics?: Record<string, number>;
  commitSha?: string;
  branchName?: string;
  prUrl?: string;
  deploymentUrl?: string;
}
export interface HermesAgentStatus {
  id: string;
  name: string;
  type: "agent" | "tool" | "integration" | "runner";
  status: "healthy" | "degraded" | "offline" | "unknown";
  lastSuccessAt?: string;
  lastFailureAt?: string;
  callsToday: number;
  failureRate: number;
  averageLatencyMs?: number;
  configIssue?: string;
}
export interface HermesOverview {
  status: HermesStatus;
  activeTasks: number;
  completedToday: number;
  completedThisWeek: number;
  failedTasks: number;
  blockedTasks: number;
  averageDurationMs: number;
  successRate: number;
  productsTouchedRecently: number;
  founderAttentionCount: number;
}
```

---

# Service layer

Create a clean data abstraction, for example:

getHermesOverview()
getHermesTasks(filters)
getHermesTaskById(id)
getHermesTaskEvents(taskId)
getHermesProducts()
getHermesHistory()
getHermesAgents()
getHermesSettings()

Initially back this with seed/mock data.

Important:
Do not put mock data directly inside UI components.
Use files like:

* src/lib/hermes/mock-data.ts
* src/lib/hermes/service.ts
* or equivalent repo convention.

Later this should be swappable with:

* local JSON logs
* SQLite
* Supabase
* Postgres
* API endpoint
* Hermes daemon telemetry

---

# UI requirements

Make it beautiful and professional.

Use:

* cards
* tables
* tabs
* badges
* filters
* progress bars
* timeline
* charts or visual bars
* empty states
* loading states
* error states
* responsive layout

Style:

* modern
* dark-mode friendly
* DevOps command-center feel
* readable for founder/executive view
* not cluttered
* clear status colors
* polished spacing and typography

Suggested components:

* HermesStatusCard
* MetricCard
* ActiveTasksPanel
* FounderAttentionQueue
* ProductHealthGrid
* TaskStatusBadge
* PriorityBadge
* TaskTimeline
* AgentStatusPanel
* HistoricalActivityChart
* FailureCategoryChart
* ProductActivityTable
* FilterBar
* EmptyState
* ErrorState
* LoadingSkeleton

---

# Founder-specific intelligence

Add computed insights:

Neglected products

Products with no Hermes activity in 14+ days.

Repeated failure products

Products with 3+ failed tasks recently.

Attention needed

Tasks blocked by:

* user approval
* missing credentials
* failing tests
* deployment failure
* high cost risk
* unclear requirements

Momentum score

Simple calculated product score using:

* recent completed tasks
* active tasks
* failed tasks
* last activity age
* priority

Weekly digest summary

Display:

* shipped this week
* failed this week
* blocked this week
* products advanced
* recommended next actions

---

# README update

Update README or create docs/hermes-dashboard.md.

Document:

* routes added
* how to run
* data model
* mock data location
* service abstraction
* how to connect real Hermes telemetry later
* future integration plan

Include real telemetry integration plan:

1. Hermes writes task events as JSONL.
2. Dashboard service ingests JSONL.
3. Store in SQLite/Postgres.
4. Add API endpoints.
5. Add websocket/SSE live updates.
6. Add GitHub/CI/CD/deployment integrations.
7. Add notifications.

---

# Quality bar

Before final response:

* run install if needed
* run lint
* run typecheck
* run tests if available
* run build
* fix all issues
* verify /hermes renders
* verify all new routes work
* verify no console errors
* verify responsive layout
* verify mock data loads

---

# 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:

1. feat: add Hermes data model and mock service
2. feat: add Hermes mission control dashboard
3. feat: add Hermes task ledger and task detail views
4. feat: add Hermes product portfolio and history views
5. feat: add Hermes agents and settings views
6. docs: document Hermes dashboard

Push to origin main.

---

# Final response format

When done, report:

* Summary of what was built
* Routes added
* Key files changed
* How to run locally
* What mock data exists
* How to connect real Hermes data
* Tests/build/lint status
* Any known gaps

Use this as the shorter direct command too:
```bash
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.
```