Task: Diagnose reasoning-effort client capability

Identity

Diagnose why the current AI Programming model menu exposes only one reasoning strength for a model that is expected to support multiple strengths.
Trace the committed Makelore chain from model/provider capability metadata through Conversation state, Pi runtime mapping, Snapshot projection, and Renderer options.
Build and run a deterministic focused reproduction for the exact menu symptom.
Report the verified boundary and the smallest coordinated repair scope; do not modify product behavior unless the user separately asks for a fix.

Treat the current Pi 0.84.2 hard-cutover architecture and Main-owned Provider boundary as authoritative; do not restore OpenCode or add a compatibility layer.
Distinguish committed source behavior, deployed/model-provider behavior, and unverified assumptions. The screenshot proves the visible symptom only.
Keep credentials, real user data, and upstream payloads out of diagnostics.
Preserve concurrent task ownership. The potentially related historical model-parity peer has no defined scope, so this task remains read-only outside its own record.
The one-api repository is separately gated; do not inspect its occupied worktree or initialize missing project-doc assets without authorization.

Confirmed the direct cause in shared/imported-model-profile.ts: the deepseek-v4-pro profile marks off, minimal, low, and medium as unsupported (null) and maps only product high to provider high.
Confirmed Pi 0.84.2 filters every null level and exposes xhigh/max only when those keys exist. The committed profile therefore deterministically projects the single level ['high'].
Confirmed the Main/runtime and Renderer chain is behaving as designed: provider config copies the profile map, the Pi session reports its supported levels, and the composer renders only levels in that runtime list. The Renderer is not dropping additional options.
Confirmed the local AI proxy forwards the original JSON request body to one-api; it does not remove reasoning_effort.
A one-variable diagnostic map exposed off, low, medium, and high, and the real Pi serializer emitted provider values low, high, and max for product low, medium, and high respectively. This proves the repair seam without changing production behavior.
The product contract currently has only off|minimal|low|medium|high; literal xhigh/max menu labels require a separate contract/UI expansion. Mapping the existing product high to provider max avoids that expansion if those product semantics are accepted.
No product code or canonical project documentation was changed. Temporary diagnostic tests were removed after use.

Deterministic red reproduction, run three times: pnpm exec vitest run tests/unit/diagnostic-deepseek-v4-reasoning.test.ts --maxWorkers=1 -> each run failed with expected ['off','low','medium','high'] versus actual ['high'].
One-variable causal test using only a replacement level map -> passed and returned ['off','low','medium','high'].
Real Pi payload serialization diagnostic -> 3 passed; product low -> low, medium -> high, and high -> max, with thinking enabled.
Focused proxy diagnostic with reasoning_effort: 'max' -> passed; the temporary assertion was reverted.
Final existing-suite check: pnpm exec vitest run tests/unit/imported-model-profile.test.ts tests/unit/pi-provider-config.test.ts tests/unit/coding-feature-ui.test.tsx tests/unit/ai-proxy-routes.test.ts --maxWorkers=1 -> 4 files and 50 tests passed.

Update the deepseek-v4-pro profile and its focused tests after confirming the desired product labels. The smallest compatible map is expected to expose product low/medium/high while translating to provider low/high/max.
If the UI must display literal max (or xhigh) rather than translating the existing high, extend ThinkingLevel, IPC/runtime contracts, labels, and tests as one coordinated change.
A server-owned capability descriptor can reduce future profile staleness, but is a larger ownership change and is not needed for the immediate fix.

None. Promote a durable capability-ownership rule only with an implemented repair or accepted server/client contract design.