Spec Kit + UI: converge 0→1 with a beautiful DAGOS interface

Goal

Finish the 0→1 implementation by running the remaining Spec Kit quality/convergence pass and delivering the first genuinely polished DAGOS UI.

This is not a separate demo. The UI is the human inspection and control surface for the runtime already defined by issues #1-#20.

Reconcile the constitution, specification, research, plan, data model, contracts, and implementation.
Run the equivalent of clarify/analyze/converge checks against the completed implementation.
Verify every functional requirement has an implementation path and acceptance test.
Verify the Jev classification-only boundary is preserved.
Verify providers receive compiled versioned IR, never raw DAG records.
Verify structured response validation happens before canonical DAG mutation.
Remove accidental complexity or duplicated abstractions discovered during implementation.
Update the Spec Kit artifacts when implementation decisions legitimately changed.
Record unresolved tradeoffs explicitly rather than hiding them in implementation details.

Build a polished local-first inspector/control surface around the real DAGOS runtime.

The UI should make the architecture visually obvious:

Project/DAG overview with nodes and typed relationships.
Active context view showing what is currently projected into inference and why.
Jev classification view showing additions/removals without implying that Jev is an autonomous agent.
Run timeline showing user message, classification, context changes, IR compilation, provider streaming, response validation, DAG emissions, and completion/errors.
IR inspector showing the exact versioned machine-readable payload sent to the provider.
Structured response/emission inspector showing what became durable state.
Provider/model/system-prompt controls.
Streaming conversation/output view with presentation prose clearly separated from canonical state.
Useful empty, loading, error, and restart states.
Clear visual hierarchy, responsive layout, keyboard-friendly interactions, and sensible dark/light presentation.
No fake data in the production path. The UI should consume the actual DAGOS runtime APIs/events.
Keep the UI thin. Do not move DAG semantics, Jev policy, provider logic, or canonical state into frontend code.

The visual target is a small, coherent developer tool rather than an enterprise dashboard. It should feel intentional, fast, inspectable, and calm.

A fresh local project can launch DAGOS and reach the inspector without network access when using the fake adapters.
A complete fake-provider run is visible end-to-end in the UI.
The DAG, active context, Jev result, IR, events, and final structured response can be inspected without reading raw database tables.
A user can distinguish durable DAG state from temporary active context at a glance.
Provider/model/system-prompt selection is visible and changes the subsequent run configuration.
Provider streaming is rendered separately from canonical structured emissions.
Errors and invalid responses are surfaced as explicit runtime state.
UI tests cover the core inspection flow and critical state transitions.
Spec Kit artifacts and implementation agree at the end of the issue.
No new autonomous-agent, routing, vector-memory, or provider-framework behavior is introduced.

Depends on #15, #18, and #20. The UI should expose the real contracts established by #7-#14 rather than inventing parallel ones.