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