Set up Core Hub framework planning

docs/specs/ui-operator-console.md

@@ -0,0 +1,31 @@
+# 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.