makelore/.project-docs/30-worklog/tasks/20260912-model-capabilities-c48271f9.md

Task: Inspect model capabilities across gateway server and client

Identity

• Task ID: 20260912-model-capabilities-c48271f9
• Mode: Feature
• Branch: codex/20260912-model-capabilities-c48271f9-model-capabilities
• Worktree: D:\Datas\OthersProjects.codex-worktrees\makelore\20260912-model-capabilities-c48271f9
• Base commit: 70fa916edf
• Owner: codex
• Status: Ready for Integration

Scope

• Read-only assessment of Makelore imported model capabilities, local profiles, model UI and Pi runtime capability resolution.
• Product source, test suites, main checkout and other task records remain unchanged.
• Maintain only this task record.

Intent And Constraints

• User requested independent assessment across Works Square, one-api and Makelore; no subagents were created.
• Concurrent Task Gate: Passed. Bundled check/start/status verified this task ID, feature mode, branch, exact base and owned isolated worktree. The original checkout had unrelated uncommitted task documents.
• Project Context Loaded: read entry/memory index, active task, positioning/current-state, decision index, system/module/data-flow documents, domain/success criteria, relevant evidence/reflection/commitment/stale indexes; also AGENTS.md, README and ADR-006 Pi hard cutover.
• Goal and focus: Makelore provides Code/Canvas/Robot with Main-owned providers and Pi 0.84.2.
• Planning Gate: Passed for assessment only. Proposals do not enact architecture changes or promote canonical memory.
• Peer scopes were read via registry task-record paths only. Numerous historical owners and placeholder scopes remain; these are unknown coordination state, not authority to adopt work. Assessment is confined to a fixed committed baseline and task-owned records, so there is no shared source writer or conflicting implementation decision.
• Relevant established boundary: Works already owns optional per-model reasoning metadata; client local profiles supply fallback and provider wire adaptations. Replacing this authority is a proposal requiring agreement, not a presumed accepted ADR.
• Stale/unknown context: client positioning contains placeholders, so current README/AGENTS/ADR-006 bound the assessment; historical OpenCode/gateway notes are not runtime truth. Installed/deployed state, live provider/account coverage, and one-api internals are unverified.
• Diagnosis scope: no production failure or provider response was supplied. Used real source functions to reproduce concrete contract gaps; no speculative runtime root cause, temporary instrumentation, or remediation loop is claimed.

Outcome

• Confirmed server reasoning override exists, but low/high/max normalization drops other efforts and modalities. Model labels depend on local profiles, runtime image support combines other local sources, and live effort controls use Main/Pi snapshots. No product change. Cross-project one-api inspection remains blocked pending user exception.
• Detailed evidence: D:\Datas\PythonProjects.codex-worktrees\works-square-server\20260912-model-capabilities-a7e194c2.project-docs\50-evidence\topics\20260912-model-capabilities-a7e194c2__model-capability-assessment.md
• Recommended provider/channel capability catalog -> Works business-filtered projection -> one resolved client UI/runtime capability. This remains a recommendation.
• one-api gate exception request remains pending; no inference from elapsed time.

Verification

• Bundled check_project_docs/start/status passed for this owned worktree.
• Actual shared TypeScript modules transpiled in memory and executed: low/medium/xhigh reduced to low, modality removed, gpt-4.1-mini label = text; intentional preservation assertion exited 1.
• Official Alibaba/Anthropic/OpenAI/Google docs were checked for metadata availability; no paid model/network API probe.
• No full application build or broad tests: no product behavior changed. Documentation drift and final Git boundary check are the completion checks.

Follow-ups

• Finish one-api read-only source tracing only after user permission or a functioning task gate.
• Agree capability ownership and contract, then implement coordinated server/client/gateway changes with end-to-end fixture coverage and provider serialization tests.
• Actual deployment, refresh and account-specific provider metadata coverage require later verification.

Promotion Candidates

• Target: canonical model/provider architecture and data-flow docs.
• Proposal: centralize platform-managed effective capability in a provider-aware one-api catalog and project it through Works Square to Main/Pi and UI; distinguish unknown, unsupported, switch-only, effort and budget.
• Evidence: source functions and dated official references in the assessment.
• Future impact: model onboarding, UI labels, attachments, reasoning selection and wire serialization.
• Semantic conflict: existing canonical rules currently make Works server static metadata authoritative with client local fallback; no canonical edit is made.
• Human confirmation required: yes, before accepting the architecture and implementing the cross-repository behavior.