PR #77144: [AI-assisted] fix(deepseek): export resolveThinkingProfile from provider policy surface

• Repository: openclaw/openclaw
• Author: luyao618
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/77144

Description (problem / solution / changelog)

Summary

Fixes #77139 — DeepSeek V4 /think picker in the Control UI omits xhigh and max thinking levels for native deepseek/deepseek-v4-pro.

Root Cause

resolveThinkingProfile was registered at runtime via extensions/deepseek/index.ts but was not exported from the lightweight bundled provider policy surface (extensions/deepseek/provider-policy-api.ts). When the Control UI hits the fallback path in src/plugins/provider-thinking.ts:85 — which calls resolveBundledProviderPolicySurface("deepseek")?.resolveThinkingProfile?.(...) — it found no resolveThinkingProfile export and fell back to the default five-level profile, missing xhigh and max.

For comparison, extensions/anthropic/provider-policy-api.ts already exports resolveThinkingProfile, which is why Anthropic models work correctly through the same fallback path.

Changes

1. extensions/deepseek/thinking-profile.ts (new) — Extracts the V4 thinking profile constant and resolveDeepSeekV4ThinkingProfile() into a shared module so both the runtime entry and the policy surface can import it without duplication.

2. extensions/deepseek/index.ts — Imports resolveDeepSeekV4ThinkingProfile from the new shared module instead of defining it inline.

3. extensions/deepseek/provider-policy-api.ts — Exports resolveThinkingProfile that delegates to resolveDeepSeekV4ThinkingProfile, making xhigh and max available through the bundled policy surface fallback path.

Regression Test Plan

• Existing extensions/deepseek/index.test.ts (10 tests) — pass ✅
• Existing extensions/deepseek/provider-policy-api.test.ts (10 tests) — pass ✅
• Manual: open Control UI for a deepseek/deepseek-v4-pro session, type /think, and confirm xhigh and max appear in the picker.

Security Impact

None. This change only wires an existing thinking profile through an additional code path. No new permissions, no auth changes, no data flow changes.

Changed files

• extensions/deepseek/index.ts (modified, +1/-16)
• extensions/deepseek/provider-policy-api.ts (modified, +8/-0)
• extensions/deepseek/thinking-profile.ts (added, +19/-0)

PR #77151: fix(channels): do not mark optional-with-default fields as required in channel config json schema

• Repository: openclaw/openclaw
• Author: ai-hpc
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/77151

Description (problem / solution / changelog)

Summary

• Problem: Pre-existing channel configs (Feishu, Bluebubbles, IRC, Line, Nextcloud Talk, Zalouser) crash the gateway in a restart loop after upgrading to 2026.5.x because the bundled JSON schema marks .optional().default(X) fields as required. Existing configs that omit these defaulted fields fail validation with "must have required property" errors.
• Why it matters: Users on 2026.4.22 with valid Feishu configs hit a ~80x restart loop after upgrading to 2026.5.2; only workaround was downgrading. Affects all six channels listed above.
• What changed: Pass io: 'input' to schema.toJSONSchema() in buildChannelConfigSchema so the generated JSON schema reflects user input requirements (not Zod's output type). Regenerated bundled-channel-config-metadata.generated.ts. Added a regression unit test.
• What did NOT change (scope boundary): No plugin schema changes, no validator changes, no defaults removed — defaults still apply at runtime via Zod's safeParse. Only the JSON schema's required array shrinks to truly mandatory fields.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Integrations
• API / contracts

Linked Issue/PR

• Closes #77116
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: Zod 4's toJSONSchema() defaults to io: 'output'. With .optional().default(X), the output type is always X (never undefined), so the converter marks the field as required in the generated JSON schema. The runtime config validator validates user input via Ajv with useDefaults: false against this generated schema, so any pre-existing config that omits a defaulted field is rejected.
• Missing detection / guardrail: buildChannelConfigSchema did not specify io, so it used Zod's default. No test covered the input-vs-output JSON schema distinction.
• Contributing context: Six bundled channels use the .optional().default() pattern (Feishu has 8 such fields, the others have 1-2 each). Issue #77116 surfaced via Feishu because it has the most fields, but the same class of bug exists in Bluebubbles, IRC, Line, Nextcloud Talk, Zalouser.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
• Target test or file: src/channels/plugins/config-schema.test.ts — new test does not mark optional-with-default fields as required (#77116).
• Scenario the test should lock in: A schema with one mandatory field, one .optional().default() field, and one .optional() field generates required: ["mandatory"] only.
• Why this is the smallest reliable guardrail: Asserts the exact required shape that the runtime validator consumes. If a future change reverts to io: 'output' or removes the option, the test fails immediately.
• Existing test that already covers this (if any): None — passes draft-07 compatibility options to toJSONSchema was updated to also assert io: 'input'.

User-visible / Behavior Changes

Pre-existing Feishu/Bluebubbles/IRC/Line/Nextcloud-Talk/Zalouser configs that omit fields like domain, connectionMode, webhookPath, dmPolicy, groupPolicy, reactionNotifications, typingIndicator, resolveSenderNames are accepted again. Defaults still apply at runtime via the Zod safeParse path. No new permissions or surfaces.

Diagram (if applicable)

Before:
[user config: {accounts: {...}}] -> [JSON schema with required:[domain, ...]] -> [Ajv reject: missing required] -> [gateway crash loop]

After:
[user config: {accounts: {...}}] -> [JSON schema with required:[]] -> [Ajv ok] -> [Zod safeParse applies defaults] -> [gateway ready]

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: macOS (Darwin 25.2.0, arm64)
• Runtime: Node 24, gateway via node dist/index.js gateway --port 18789
• Integration/channel: Feishu (with 6+ named accounts)
• Relevant config (redacted): see #77116 — channels.feishu with enabled, dmPolicy: "allowlist", groupPolicy: "allowlist", allowFrom: ["*"], accounts.{main,finance,...,default} with appId/appSecret.

Steps

1. Use the redacted config from #77116 at ~/.openclaw/openclaw.json.
2. Run gateway under stock 2026.5.2: gateway crashes in restart loop with must NOT have additional properties (paraphrased) / must have required property "domain" etc.
3. Apply this PR's commit, regenerate, restart: gateway starts cleanly.

Expected

• Gateway boots, Feishu plugin loads, no validation errors.

Actual (after fix)

• Verified with the user's exact config from #77116 against the regenerated bundled-channel-config-metadata.generated.ts via Ajv: validates ok.

Evidence

• Failing-before / passing-after via 1 new test in src/channels/plugins/config-schema.test.ts
• Updated existing passes draft-07 compatibility options test to assert io: 'input'
• Re-ran user's exact reported config through Ajv → validates ok

Human Verification (required)

• Verified scenarios: Validated user's reported config from #77116 against the regenerated schema via Ajv — passes. Ran pnpm vitest run src/channels/plugins/config-schema.test.ts src/config/validation.channel-metadata.test.ts extensions/feishu/src/config-schema.test.ts — 36/36 pass. Ran pnpm vitest run src/config/ — 1231/1232 pass (1 unrelated pre-existing bun fallback test failure that fails on stock main too).
• Edge cases checked (in tests): mandatory-only field stays in required; .optional() only stays out of required; .optional().default() stays out of required.
• What I did not verify manually: End-to-end gateway restart on the user's exact config — relied on Ajv-level validation since the gateway pipeline uses the same generated schema.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes — only relaxes input validation; no semantics change at runtime.
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Other consumers of the JSON schema (UI pickers, doc generators) may have implicitly relied on required reflecting the output type rather than input requirements.
  • Mitigation: required for .optional().default() fields is widely considered a Zod 4 footgun; the input-shape semantics is the canonical interpretation for runtime input validation. UI consumers that need the output shape can use the Zod schema directly (still exported by each plugin).

Changed files

• src/channels/plugins/config-schema-input-mode.test.ts (added, +45/-0)
• src/channels/plugins/config-schema-input-mode.ts (added, +37/-0)
• src/channels/plugins/config-schema.test.ts (modified, +21/-0)
• src/channels/plugins/config-schema.ts (modified, +4/-10)
• src/config/bundled-channel-config-metadata.generated.ts (modified, +152/-192)

PR #77166: fix(deepseek): expose v4 max thinking levels in policy

• Repository: openclaw/openclaw
• Author: Thiagocsoaresbh
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/77166

Description (problem / solution / changelog)

Summary

• Problem: The Control UI /think picker could omit xhigh and max for native DeepSeek V4 models when thinking resolution used the bundled provider policy surface.
• Why it matters: Users selecting deepseek/deepseek-v4-pro or deepseek/deepseek-v4-flash should be able to choose the documented maximum reasoning levels from the UI.
• What changed: Added resolveThinkingProfile to DeepSeek's provider policy API and covered the V4/non-V4 behavior with unit tests.
• What did NOT change (scope boundary): Did not change the runtime DeepSeek provider hook, which already exposed the correct V4 thinking profile.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #77139
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: DeepSeek's runtime provider hook exposed the V4 thinking profile, but the lightweight bundled provider policy API did not export resolveThinkingProfile.
• Missing detection / guardrail: There was no provider-policy unit test verifying that DeepSeek V4 policy resolution exposes xhigh and max.
• Contributing context (if known): Non-runtime thinking resolution can fall back to resolveBundledProviderPolicySurface(...).resolveThinkingProfile, so missing policy support caused callers to see only the base thinking levels.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/deepseek/provider-policy-api.test.ts
• Scenario the test should lock in: DeepSeek V4 policy resolution exposes off, minimal, low, medium, high, xhigh, and max; non-V4 models do not get the V4 thinking profile.
• Why this is the smallest reliable guardrail: The bug is isolated to the lightweight provider policy surface, so a focused provider-policy unit test covers the failing path.
• Existing test that already covers this (if any): N/A
• If no new test is added, why not: N/A

User-visible / Behavior Changes

The Control UI /think picker can surface xhigh and max for native DeepSeek V4 models when it resolves thinking options through the bundled provider policy surface.

Diagram (if applicable)

Before:
[/think picker] -> [bundled DeepSeek provider policy] -> [no resolveThinkingProfile] -> [base levels only]

After:
[/think picker] -> [bundled DeepSeek provider policy] -> [DeepSeek V4 thinking profile] -> [xhigh and max available]

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: WSL
• Runtime/container: Node.js 22.22.2, pnpm 10.33.2
• Model/provider: deepseek/deepseek-v4-pro
• Integration/channel (if any): Control UI /think picker
• Relevant config (redacted): N/A

Steps

1. Resolve the bundled DeepSeek provider policy surface for a DeepSeek V4 model.
2. Request the thinking profile for deepseek-v4-pro.
3. Verify the returned levels include xhigh and max.

Expected

• DeepSeek V4 thinking profile includes off, minimal, low, medium, high, xhigh, and max.

Actual

• Before this fix, the policy artifact did not export resolveThinkingProfile, so fallback callers could only see the base levels.
• After this fix, the provider-policy test verifies all expected V4 levels.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

pnpm exec vitest run extensions/deepseek/provider-policy-api.test.ts --reporter=verbose

Test Files  1 passed (1)
Tests       12 passed (12)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • DeepSeek V4 policy profile exposes xhigh and max.
  • DeepSeek V4 policy profile keeps high as the default level.
  • Non-V4 DeepSeek models do not receive the V4 thinking profile.
  • Existing DeepSeek provider policy metadata hydration tests still pass.
• Edge cases checked:
  • deepseek-chat returns no V4 thinking profile.
• What you did not verify:
  • Live Control UI browser autocomplete was not manually replayed.
  • Full repository test suite was not run.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: The provider policy surface could drift from the runtime DeepSeek thinking profile in the future.
  • Mitigation: Added provider-policy unit coverage for the expected DeepSeek V4 thinking levels.

Changed files

• CHANGELOG.md (modified, +3/-0)
• extensions/deepseek/index.ts (modified, +1/-16)
• extensions/deepseek/provider-policy-api.test.ts (modified, +28/-1)
• extensions/deepseek/provider-policy-api.ts (modified, +5/-0)
• extensions/deepseek/thinking.ts (added, +27/-0)

PR #77235: fix(deepseek): expose V4 thinking profile via lightweight policy artifact

• Repository: openclaw/openclaw
• Author: adhirajhangal
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/77235

Description (problem / solution / changelog)

Problem

The DeepSeek plugin's runtime resolveThinkingProfile hook correctly exposes xhigh|max for V4 models (index.ts line 11), but the lightweight provider-policy artifact (provider-policy-api.ts) has no resolveThinkingProfile export.

Fallback callers that reach resolveBundledProviderPolicySurface("deepseek") instead of the active runtime registry — including the Control UI /think picker during session setup — therefore get no V4 profile and fall back to base levels only (off/minimal/low/medium/high), reproducing #77139.

Fix

• Export resolveThinkingProfile from provider-policy-api.ts using isDeepSeekV4ModelId from models.ts
• Export DEEPSEEK_V4_THINKING_PROFILE as the single shared definition
• Update index.ts to import both from provider-policy-api.ts instead of redefining them, so the two surfaces cannot drift

Tests

Added four cases to provider-policy-api.test.ts covering:

• deepseek-v4-pro returns all seven levels including xhigh and max
• deepseek-v4-flash returns all seven levels including xhigh and max
• Non-V4 DeepSeek models (deepseek-chat) return null
• Non-DeepSeek providers with a V4 model id return null

Fixes #77139.

Changed files

• extensions/deepseek/index.ts (modified, +7/-17)
• extensions/deepseek/provider-policy-api.test.ts (modified, +29/-1)
• extensions/deepseek/provider-policy-api.ts (modified, +25/-1)