generated from coulomb/repo-seed
32 lines
1.0 KiB
Markdown
32 lines
1.0 KiB
Markdown
# UI and Operator Console Spec
|
|
|
|
## Purpose
|
|
|
|
Define the Core Hub operator interface without coupling the framework to one UI runtime.
|
|
|
|
## UI Direction
|
|
|
|
- Use whynot-design tokens and component semantics where possible.
|
|
- Prefer custom-element/Lit adapters for framework-neutral surfaces.
|
|
- Keep the canonical UI contract separate from generated or hand-authored implementation code.
|
|
- Use Playwright visual checks once UI components exist.
|
|
|
|
## Initial Console Areas
|
|
|
|
- hub registry and health
|
|
- active workplans and blocked tasks
|
|
- progress/event stream
|
|
- messages and agent coordination
|
|
- decisions and deployment records
|
|
- API consumers and non-secret access metadata
|
|
- compatibility/migration dashboard
|
|
|
|
## Design Constraint
|
|
|
|
The operator console is an operational tool. It should be dense, readable, and stable, not a marketing surface.
|
|
|
|
## Open Questions
|
|
|
|
- Whether initial UI is server-rendered, Lit/custom-element, or a thin static frontend consuming FastAPI.
|
|
- Which Inter-Hub admin screens should be preserved as compatibility views vs. redesigned.
|