bytelyst/bytelyst-devops-tools

Fork 0

Saravana Kumar 8f522e3505 Add Hermes dashboard improvement backlog

2026-05-27 21:02:23 +00:00

16 KiB

Raw Blame History

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:

cd /root/bytelyst.ai/repos/bytelyst-devops-tools
Inspect the repo structure.
Identify frontend/backend framework, package manager, routes, styling, existing dashboard/admin patterns, auth, API conventions, test setup, lint/build commands.
Reuse existing architecture wherever possible.
Do not rewrite the whole repo.
Commit incrementally to origin main unless repo policy says otherwise.
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:

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:

Hermes writes task events as JSONL.
Dashboard service ingests JSONL.
Store in SQLite/Postgres.
Add API endpoints.
Add websocket/SSE live updates.
Add GitHub/CI/CD/deployment integrations.
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.

Next Dashboard Improvements

Potential follow-up work for Hermes Mission Control:

snapshot diff view that shows what changed since the last refresh
per-instance action row with copy-link and open-dashboard shortcuts
warning severity filters for the live ops panel
compact trend cards for recent alert volume and backup freshness
task-ledger deep links from the ops panel into the most recent Hermes work
optional dark/light theme toggle if the broader dashboard shell eventually supports it

Git workflow

Commit incrementally:

feat: add Hermes data model and mock service
feat: add Hermes mission control dashboard
feat: add Hermes task ledger and task detail views
feat: add Hermes product portfolio and history views
feat: add Hermes agents and settings views
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:

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.

16 KiB Raw Blame History Unescape Escape