docs: record reasoning capability diagnosis
This commit is contained in:
@@ -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.
|
||||||
Reference in New Issue
Block a user