FN-7775: Add thinking level selection to new chat model picker
Adds a per-session thinking-level selector to the new chat model dropdown, persisting the choice through the chat store and engine session options. - Adds thinkingLevel column to chat_sessions with a db migration - Extends chat-store, chat-types, and chat.ts to read/write thinkingLevel - ChatView model selector now exposes a thinking-level control alongside model choice - useChat and register-chat-routes plumb thinkingLevel through session creation/API - engine/src/index.ts passes thinkingLevel as defaultThinkingLevel session option - Adds a minor changeset and updates settings-reference/dashboard-guide docs - Adds/updates unit tests across core and dashboard packages Files changed: .changeset/fn-7775-chat-thinking-level.md | 7 ++ docs/dashboard-guide.md | 1 + docs/settings-reference.md | 2 +- packages/core/src/__tests__/chat-store.test.ts | 15 +++- packages/core/src/__tests__/db-migrate.test.ts | 33 ++++++++ packages/core/src/chat-store.ts | 12 ++- packages/core/src/chat-types.ts | 6 ++ packages/core/src/db.ts | 14 +++- packages/dashboard/app/api/legacy.ts | 2 +- packages/dashboard/app/components/ChatView.tsx | 16 +++- .../__tests__/ChatView.core-interactions.test.tsx | 75 +++++++++++++++--- .../dashboard/app/hooks/__tests__/useChat.test.ts | 17 +++- packages/dashboard/app/hooks/useChat.ts | 6 +- .../dashboard/src/__tests__/chat-manager.test.ts | 90 ++++++++++++++++++++++ packages/dashboard/src/chat.ts | 23 ++++++ .../dashboard/src/routes/register-chat-routes.ts | 25 +++++- packages/engine/src/index.ts | 1 + 17 files changed, 318 insertions(+), 27 deletions(-) Fusion-Task-Id: FN-7775 Fusion-Task-Lineage: e16c7d3b-361e-4908-87ad-10be17a47c47 Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
This commit is contained in:
@@ -971,7 +971,7 @@ Short-lived token bounds are enforced server-side:
|
||||
|
||||
Fusion resolves task models through workflow-backed lane values first, then global lane defaults, then the project/global default model fallback. The common workflow lanes are stored as setting values on the project's default workflow and can be edited with dropdown controls from Settings -> Project Models -> Default workflow model lanes (persisted by the Settings modal's primary Save) or from workflow editor -> Settings -> Values for declared workflow lanes and fallbacks. General-scope fallback selection remains the global Fallback Model picker in Settings -> General Models.
|
||||
|
||||
Settings model lanes can also carry optional thinking/reasoning effort overrides in the same model dropdown. Primary workflow lanes declare `executionThinkingLevel`, `planningThinkingLevel`, or `validatorThinkingLevel` per `(workflow, project)`; empty thinking values inherit through the lane/global/default chain and explicit values are cleared by the lane reset action. Runtime thinking precedence is node/step `config.thinkingLevel` > task `thinkingLevel` > workflow lane thinking override > global lane thinking override > project default thinking override > global `defaultThinkingLevel`, and the value still flows through pi.ts' existing thinking/reasoning-conflict fallback (Fusion retries without the explicit level when a provider rejects conflicting thinking parameters).
|
||||
Settings model lanes can also carry optional thinking/reasoning effort overrides in the same model dropdown. Primary workflow lanes declare `executionThinkingLevel`, `planningThinkingLevel`, or `validatorThinkingLevel` per `(workflow, project)`; empty thinking values inherit through the lane/global/default chain and explicit values are cleared by the lane reset action. Runtime thinking precedence for task/workflow execution is node/step `config.thinkingLevel` > task `thinkingLevel` > workflow lane thinking override > global lane thinking override > project default thinking override > global `defaultThinkingLevel`. Model-mode Chat sessions use the same executor-lane resolver with session `thinkingLevel` in the task slot, so an empty chat-session value inherits project/global defaults while a concrete New Chat selection wins for that session. The resolved value still flows through pi.ts' existing thinking/reasoning-conflict fallback (Fusion retries without the explicit level when a provider rejects conflicting thinking parameters).
|
||||
|
||||
When the planning lane has neither `planningFallback*` nor a global `fallback*` pair configured, triage now derives an **implicit fallback** from the resolved project/global default (execution) model (FN-7719). This lets a retryable primary planner-model failure (e.g. a provider 404/429) recover via one distinct swap instead of permanently failing triage with "no fallback configured" — the operator's chosen primary planner lane is unchanged, and the implicit fallback is skipped when it would equal the primary model or when test mode is active.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user