feat(claude-code): add ClaudeCodeSettingsSchema with effort, thinking, and thinkingBudgetTokens

[aaight]

Summary

• Creates src/backends/claude-code/settings.ts with ClaudeCodeSettingsSchema (effort, thinking, thinkingBudgetTokens) following the codex/settings.ts pattern
• Adds settings block to CLAUDE_CODE_ENGINE_DEFINITION in catalog.ts with field descriptors for effort (select), thinking (select), and thinkingBudgetTokens (number, with TODO for frontend)
• Adds 'number' variant to AgentEngineSettingField union type in types.ts (with TODO comment for Story chore: add .nvmrc for Node.js 22 #2 frontend support)
• Re-exports ClaudeCodeSettingsSchema and ClaudeCodeSettings from src/config/engineSettings.ts for backward compatibility
• Implements getSettingsSchema() on ClaudeCodeEngine so the schema auto-registers during bootstrap
• Unit tests for resolveClaudeCodeSettings() covering defaults, effort modes, thinking modes, thinkingBudgetTokens, and schema registration

Fixes: https://trello.com/c/69b6cf0cdc3be1473abad02c

Test plan

• npm test — all 5035 unit tests pass
• npm run lint — no lint errors
• npm run typecheck — no type errors
• resolveClaudeCodeSettings() returns { effort: 'high', thinking: 'adaptive' } defaults
• Explicit effort modes (low/medium/high/max) applied from engineSettings
• Explicit thinking modes (adaptive/enabled/disabled) applied from engineSettings
• thinkingBudgetTokens passed through when configured
• ClaudeCodeEngine.getSettingsSchema() returns the schema and it validates correctly

🤖 Generated with Claude Code

🕵️ claude-code · claude-sonnet-4-6 · run details

[aaight]

CI Failures Resolved

Root Cause

The frontend EngineSettingField type in web/src/components/settings/engine-settings-fields.tsx only defined 'select' and 'boolean' variants, but the PR added a 'number' type to the backend's AgentEngineSettingField union (for thinkingBudgetTokens). This caused a TypeScript error during the Build frontend CI step.

Fix Applied

• Added 'number' variant to the frontend EngineSettingField union type for type compatibility with the backend catalog
• Added a guard in the fields render loop to skip 'number' fields (returning null) until Story chore: add .nvmrc for Node.js 22 #2 implements numeric field rendering in the dashboard

Verification

• ✅ npm run build:web — frontend builds successfully (0 TypeScript errors)
• ✅ npm run build — backend builds successfully
• ✅ npm run typecheck — no type errors
• ✅ npm run lint — no lint errors
• ✅ npm test — all 5035 unit tests pass
• Changes pushed to branch feature/claude-code-engine-settings-schema

🕵️ claude-code · claude-sonnet-4-6 · run details

[nhopeatall]

Summary

Clean, well-structured PR that follows established patterns (Codex/OpenCode settings). Schema, type definitions, catalog registration, re-exports, frontend type stub, and tests all align correctly. CI passes.

Should Fix (non-blocking)

• resolveClaudeCodeSettings is defined but not called in production code. Both resolveCodexSettings (codex/index.ts:605) and resolveOpenCodeSettings (opencode/index.ts:820) are called in their respective execute() methods, but resolveClaudeCodeSettings is not imported or used in claude-code/index.ts. The settings schema is registered and validated, but the resolved settings (effort, thinking, thinkingBudgetTokens) are never passed to the Claude Code SDK query() call. This means configuring these settings in the dashboard will have no runtime effect until a follow-up PR wires them into execute(). This is acceptable as a phased approach, but worth calling out explicitly — perhaps a TODO in execute() near the query() call would make this clear to future contributors.

• Missing acceptance test for claude-code engine settings in schema.test.ts. The Codex and OpenCode engines each have explicit acceptance tests for engine settings in schema.test.ts. A parallel test for claude-code settings (e.g., verifying effort/thinking parses correctly through ProjectConfigSchema) would complete the pattern and catch regressions in schema registration.

Notes

• The claude-code to unknown-engine change in schema.test.ts is correct — claude-code is now a registered engine with a valid schema.
• The number type stub in types/catalog/frontend is clean — return null for unimplemented field types is the right approach, and the TODO comments consistently reference Story #2.
• The re-export pattern in engineSettings.ts matches Codex/OpenCode exactly.

🕵️ claude-code · claude-opus-4-6 · run details