docs: record reasoning capability diagnosis

This commit is contained in:
2026-09-01 14:16:54 +08:00
parent 850947c092
commit a30053c30e

View File

@@ -0,0 +1,90 @@
# 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.