docs: clarify Hermes dashboard roadmap
This commit is contained in:
root
parent
62089a11cc
commit
1ee9c54a54
@ -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:
|
||||
|
||||
@ -663,3 +700,4 @@ 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.
|
||||
```
|
||||
|
||||
Loading…
Reference in New Issue
Block a user