Pick a kanban task's model and thinking depth from the board

[OutThisLife]

A kanban task ran on whatever model the profile you assigned it to happened to be configured with. The desktop board had no model control at all, and reasoning effort had no per-task storage anywhere — so pairing a small model with high effort, or running one card on a different backend, meant editing the worker profile itself.

This adds that control to the board, and makes the picker the composer's own rather than a second one that drifts.

The picker is now shared, not copied

ModelCatalogMenu is the chat composer's menu, extracted: search, provider grouping, -fast family collapse, keyboard selection, and the per-row thinking/effort submenu. Rendering is split from meaning — a ModelMenuController decides what a selection does, so the composer keeps writing through to its session while the board just holds a value. It's exported through the plugin SDK, so the kanban plugin renders the real component instead of a fork.

ModelEditSubmenu had to become pure as part of this: it previously called setCurrentReasoningEffort and config.set inline, so picking an effort for a kanban card would have reached over and changed the user's live chat session. It now reports edits and lets its host decide.

Thinking depth needed a home

model_override shipped without a matching reasoning column, so effort was unreachable per-task even from the CLI. Adds tasks.reasoning_effort (migrated, NULL = inherit the profile) and a --reasoning spawn flag — new on hermes / hermes chat too, since the level was only reachable through the /reasoning slash command and the dispatcher had no flag to pass.

Depth is deliberately independent of the model override: a task may run the profile's own model at a different depth, and clearing a model no longer resets the depth the operator chose. "none" is a value (thinking off), not a clear.

On the board

A Model row in New Task and in the task drawer. Unset reads "Profile default" and changes nothing; a pin reads provider: model · High with an inline clear. Presets are read-only — picking a model seeds the depth from what you last used for it, but a per-task choice never rewrites what your composer opens at. Fast mode is omitted rather than shown-and-ignored: it's a live-session request parameter with no worker-spawn equivalent.

Notes for review

• The New Task dialog opts out of DialogContent's clip locally. The dialog publishes itself as the portal container for popovers opened inside it, so its overflow-y-auto cropped the menu at the dialog's edge. The general fix is already in flight as #75600 — this override is scoped to one dialog to avoid conflicting with that work, and becomes a no-op when it lands.
• The composer's full existing behaviour suite passes unchanged against the extracted menu, which is the regression guard that matters most here.
• New coverage: normalization and rejection, the depth-survives-a-model-clear invariant, both spawn-argv branches, the REST round-trip, and the override field driving the real shared menu. One test asserts the worker CLI actually accepts the --reasoning flag the dispatcher emits — a spawn arg no parser accepts would fail every dispatch while every unit test stayed green.

[github-actions]

૮ >ﻌ< ა ci review

_{ran on defee93}

ℹ️ Info

Desktop E2E visual evidence · View test artifacts · View job

3 visual diffs.

_{inline evidence is publishing...}

[xiaoyaner0201]

Thanks for making the Kanban model picker intentionally omit Fast rather than exposing a control the worker spawn path could not honor.

I’m going to prepare a narrow follow-up that adds an optional Kanban-scoped service-tier default:

agent:
  service_tier: fast
kanban:
  service_tier: normal

Proposed semantics:

• kanban.service_tier absent/empty: preserve current behavior and inherit the assignee profile’s agent.service_tier;
• fast / normal: override the dispatched worker only;
• no worker_ prefix because the kanban namespace already establishes the scope;
• no inheritance from a transient chat-session /fast override, since tasks may originate from Desktop, CLI, cron, orchestrators, or another worker without a unique parent conversation.

The first PR will stay config-level and worker-spawn-only; it will not add a per-card Fast control to the board UI. That keeps the change bounded while closing the gap this PR documented.

[xiaoyaner0201]

Follow-up implementation is now open as #77986.

It adds optional kanban.service_tier with the compatibility contract discussed above: absent/empty inherits the assignee profile's agent.service_tier; explicit fast or normal applies only to the spawned Kanban worker (including assignee=default) and does not change reasoning effort or ordinary chat sessions.

The PR includes config/CLI propagation tests and Kanban documentation.