# Task: Diagnose reasoning-effort client capability

## Identity

- Task ID: 20260901-reasoning-effort-client-diagnosis-b6c4e1a2
- Mode: Feature
- Branch: main
- Worktree: D:\Datas\OthersProjects\makelore
- Base commit: 850947c092892cb647c4191b6d8bbf37a763e1ad
- Owner: codex
- Status: Ready for integration

## Scope

- 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.

## Intent And Constraints

- 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.

## Outcome

- 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.

## Verification

- 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.

## Follow-ups

- 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.

## Promotion Candidates

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