Specialists: expose senior-dev slot models through the crewing surfaces, and switch models inside a running task

[santoshkumarradha]

What

Delegated specialists (senior-dev) pick their models through a separate routing stack from the chat's crew: an adaptive per-slot router (internal/seniordev/router/adaptive) scoring candidates over high/low/frontier pools and switching on its own — today only the coder slot's switches surface, as model-switch stages (internal/seniordev/app/engine_router.go, "the coder moved to another model"), picks as [router] stderr lines. None of it is reachable from the surfaces a person uses:

• The chat's crewing setup — /settings → Providers pinned roles, /crew, the pinned-roles registry row (the same Pareto crewing design, docs/design/model-pool/pareto-crewing.pdf) — knows the engine roles and the crew's three seats, but not a specialist's slots. You cannot pin "what the specialist codes on" the way you pin planner.
• A specialist task's page shows one model field, and that field is not even the model doing the work — the code's own comment says "the history summary's model is not the one doing the work" (internal/tui3/taskpane.go). The slots' current models and the switch history are not shown, and nothing there lets you change a model.

Wanted

1. Same crewing exposure for specialists: each router slot (coder today, and any the router grows) appears in the pinned-roles surfaces named for the specialist — e.g. senior-dev · coder — pinnable and unpinnable like any role, via /settings, /crew, or just asking, written into the same pinned-roles registry row. Unpinned, the slot keeps its adaptive frontier behavior; pinned, the router honors the pin.
2. Model visibility inside the task: clicking a specialist's task shows each slot's current model, plus the switch history the router already records (from → to → reason).
3. Switching inside the task: from that page, open the same picker /model opens and pin or switch a slot's model on the live run — the same change-is-live rule the roles follow (a turn in flight finishes on what it started with).

Constraints

• One mechanism, not two: specialist slot pins live in the same pinned-roles registry the engine roles use; no new setting row, no second picker.
• The router's own Pareto scoring stays as the unpinned default — pins are overrides, not a replacement router.
• --high/--low/--frontier keep working; the surfaces reflect them.

Acceptance

• /settings → Providers lists a specialist's slots by name; pinning one rewrites the pinned-roles row; del unpins.
• A running specialist's task page shows each slot's current model and its switch history.
• Switching a slot's model from the task page is honored by the live run (next pick uses it) and lands in the switch history.
• Engine roles and the crew's three seats do not regress.

—

Drafted with CodeAF · reviewed and owned by the author