epic: an iterion assistant — ubiquitous, context-aware, iterion-literate, model-selectable

[Viczei]

Umbrella issue for the four tickets below. Each is independently shippable; this one holds the end state they add up to, so the whole is readable in one place.

The feature

An iterion assistant that is always there, knows iterion, knows what you are looking at, and runs on a model you chose.

Concretely, from anywhere in the studio:

I am on /pipelines, a card is red. I open the chat from the bottom of the screen — same button on every page. It already knows I am on that card; I did not retype an id. I ask why it failed. It reads the run itself, tells me the node and the diagnostic, and explains what C083 means because it knows the DSL. I drag a second run onto the composer to compare. Before all that, in settings, I picked which model answers me — and I can see what it costs and what it can do.

Four things have to be true for that paragraph to work, and none of them is true today:

#	What it takes	Issue
1	The chat is reachable from every page, not one route	#338
2	It receives iterion context — implicitly from the page, explicitly by drag & drop — and the surface is not hard-wired to one bot	#333
3	Something on the other end knows iterion — the DSL, the diagnostics, the run semantics	#334
4	The operator sees and chooses the model behind it	#339

Today: one route (/whats-next), one hard-coded bot, an assistant whose expertise is a target repo rather than iterion, and a model pinned in a .bot behind an env var.

How the pieces fit

• The surface (studio: ubiquitous chat dock — extract FloatingChatPanel into a global surface with route context #338) — extract the existing FloatingChatPanel (already a non-modal floating panel with a bottom bubble and a right dock) into a ChatDock mounted once at shell level, so it survives navigation and hosts any conversational session.
• The context (studio: manifest-driven first-class chat surface + drag & drop of iterion context into the composer #333 + studio: ubiquitous chat dock — extract FloatingChatPanel into a global surface with route context #338) — one typed-reference vocabulary (run/<id>, card/<id>, bot/<path>, …) fed by two paths: explicit (you dropped it) and implicit (you are on it). References are resolved by the assistant through its own tools, never inlined into the prompt — a reference stays live as the run advances, a blob does not. This vocabulary is the coupling point between studio: manifest-driven first-class chat surface + drag & drop of iterion context into the composer #333 and studio: ubiquitous chat dock — extract FloatingChatPanel into a global surface with route context #338: design it once, in whichever lands first.
• The brain (bots: iterion copilot — a conversational assistant that knows iterion (bot + skills) #334) — a catalog bot + skills whose subject is iterion itself. Bot and skills only, no engine code.
• The model (models: expose a model registry (GET /api/models) + let the operator choose the assistant's model #339) — a real registry (GET /api/models: known × usable-with-my-credentials × capabilities × price) plus a persisted choice, replacing today's free-text field fed by heuristics.

Suggested order

1. models: expose a model registry (GET /api/models) + let the operator choose the assistant's model #339 (a) — wire the existing model_overrides into the session launch. Few lines, no engine code, immediately useful.
2. studio: ubiquitous chat dock — extract FloatingChatPanel into a global surface with route context #338 (A) — extract the dock. Unblocks everything else: without a chat on the page, there is nowhere to drop and little point in a smarter bot.
3. studio: manifest-driven first-class chat surface + drag & drop of iterion context into the composer #333 — manifest-driven registry + the reference protocol.
4. studio: ubiquitous chat dock — extract FloatingChatPanel into a global surface with route context #338 (B/C/D) — implicit route context, session continuity, assistant-vs-steering disambiguation.
5. bots: iterion copilot — a conversational assistant that knows iterion (bot + skills) #334 — the copilot bot. Usable from the CLI before any of the above, but this is what makes ubiquity worth having.
6. models: expose a model registry (GET /api/models) + let the operator choose the assistant's model #339 (b–d) — the registry endpoint, persisted preference, capability guard.

Invariants across all four

• The engine stays bot-agnostic (CLAUDE.md): no bot id in pkg//cmd/, and no if bot == "whats-next" in the studio either. The chat surface and the model preference are generic seams; a second conversational bot must need zero product code.
• References, not blobs — context is passed by typed reference and resolved on demand.
• Visible context — whatever the assistant is assumed to be looking at is shown as a dismissible chip. No invisible injection.
• Verify, don't assert — anything the assistant produces that iterion can check (a .bot it wrote) goes through iterion validate before being presented as working.
• The model choice is not neutral — a model without tool-calling breaks the assistant outright, and ultracode only holds on claude-opus-4-8. Free choice, recommended default kept visible, capability gaps surfaced before launch rather than discovered mid-run.

Done when

• the assistant opens from the same control on every authenticated route, and keeps its session across navigation
• it knows what page you are on without you typing an id, and you can drop a run / card / node / bot onto it
• it answers iterion questions — DSL, diagnostics, run triage — and validates the workflows it writes
• you can see and change which model answers you, with what it can do and roughly what it costs
• adding a second conversational bot requires a bundle, not a studio or engine change