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