Proposal: choose the execution model in the Plan Review UI

[NOirBRight]

Problem

The current Plan Review surface lets the user approve a plan or keep planning, but it does not expose model selection. After approval, execution therefore continues with the model that produced the plan.

A common workflow would benefit from separating the planner and executor. For example, a stronger reasoning model can prepare the plan, while a faster or cheaper model carries it out. Today the user has no clear place to make that transition at the approval boundary.

Proposed UX

Add an Execution model selector to the Plan Review footer:

Execution model: Model X · high [Keep planning] [Approve and execute]

The initial value should be the session's current model and reasoning effort. The UI could also make the transition explicit, for example: "Planned by Model A; execute with Model B."

Suggested semantics

1. Selecting an execution model is staged locally while the review is open; it must not change the model that continues planning.
2. Keep planning leaves the current planner model unchanged.
3. Approve and execute first validates/applies the staged session model, then resolves the existing plan approval.
4. The next step is assembled and routed with the newly selected model.
5. If model selection fails, the review remains open and the plan is not approved.
6. The selection should be session-scoped and should not silently change the global default model.

Plugin extension seam

Even if this is not added as built-in behavior, it would be valuable to expose a small extension seam so a client plugin can implement it without replacing the entire official Plan Review card.

Possible options:

• A session-scoped child slot such as plan-review.controls or plan-review.before-approve inside PlanReviewPanel.
• A public reusable model-picker interface from @deepseek-ai/dsh-client-ui-model-selection.
• Ideally, a host operation that can apply a session-only model selection before resolving approval, so the transition can be atomic.

At present, an external plugin can claim the conversation.composer chain for plan-review, but it must reimplement the whole review card because there is no inner slot. A narrow official seam would keep the core UI authoritative while allowing planner/executor workflows to be supplied by plugins.

Would this fit the intended direction of the Plan Review and client slot architecture?

[Altairpaca]

补充一个已验证的社区实现边界，供 #3297 的模型切换讨论参考：DSHelm 在 DSH host 侧把 planner / worker / reviewer 解析成同一份可序列化 Resolution Trace，并通过官方模型选择 seam 让 provider、model、reasoning effort 进入实际 request config；控制面板只消费 host projection，不维护第二套 UI 路由状态。\n\n中文优先的公开版本整理在：https://github.com/Altairpaca/dshelm/pull/5\n\n我们目前只声称：\n- 运行时 exact-model 能力检查先于软评分；\n- 用户 / 项目 / 请求策略可以显式覆盖建议；\n- 无法观测 product-managed 最终模型时标记 unknown，而不是猜测；\n- AgentTeams、桌面 runtime 和 fallback runtime 仍由对应 DSH/生态插件负责。\n\n如果官方未来提供 session-scoped 的“计划后切换执行模型”接口，DSHelm 可以把 adapter 收敛到那个公共 seam，而不是自行 patch Plan Review。