fix(providers): inherit reasoning metadata for renamed key destinations

[lidge-jun]

Summary

A renamed API-key preset such as CommandCode now inherits missing reasoning-effort tables from its existing fixed destination match. Explicit per-model lists, including empty arrays, and explicit provider-wide lists are preserved. Unknown models retain the preset's default policy.

Refs #4308. This fixes missing destination metadata independently of the already-landed #4282 table row. It does not change provider identity, routing, OAuth matching or unrelated capability axes. Regression coverage follows gathered rows into DSH and ZCode exports.

Verification

• Independent source-plan review PASS; Arendt final source review PASS at a2fb378.
• Static manifest owner coverage and git diff --check passed.
• Local suites of every size, build, typecheck and install: NOT RUN by explicit maintainer instruction. GitHub-hosted final-head CI is required after publication.
• Independent dev PR; no merge or source issue closure performed.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed.
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

✅ Deterministic PR hygiene checks passed.

[lidge-jun]

리뷰 · 우선순위 56 / 80

이 PR은 CommandCode처럼 이름이 바뀐 API-key preset이, fixed destination matcher에 걸릴 때 비어 있는 reasoning-effort 메타를 registry에서 상속하게 합니다 (#4308). 이미 올라간 #4282 table row와 별개로 “destination metadata 공백”만 고칩니다. provider identity·routing·OAuth matching·다른 capability 축은 건드리지 않는다고 본문에 명시되어 있습니다.

현재 checkout src/providers/derive.ts에는 enrichReasoningSummariesByDestination만 있고 summary map만 채웁니다. 이 PR은 함수를 enrichReasoningMetadataByDestination로 넓혀 modelReasoningEfforts를 fillRecordOfArrays로 채우고, provider-wide reasoningEfforts는 undefined일 때만 복사합니다. 명시적 per-model 리스트(빈 배열 포함)와 명시적 provider-wide 리스트는 유지됩니다. 테스트는 provider-registry-parity.test.ts에서 CommandCode known/newer/unknown/empty/non-match를 고정하고, client-config-export.test.ts에서 DSH/ZCode export까지 gathered row가 전달되는지 봅니다.

draft·base dev이지만 CONFLICTING/DIRTY입니다. +116/-3으로 작지만 derive.ts는 자주 충돌합니다. #4374 capability map이나 #4346 models-reasoning과 이웃 개념이라, 큰 capability PR에 흡수될지 독립 픽스로 살릴지 선택이 필요합니다. types/config split 본체는 거의 안 건드립니다(docs/structure와 derive·tests 중심).

CommandCode 같은 renamed key destination은 사용자 설정에 자주 남고, reasoning ladder가 비면 클라이언트 export(DSH/ZCode)와 Codex inbound reasoning drop으로 이어집니다. 변경이 derive 한 함수와 테스트·문서에 묶여 있어 리스크 대비 효과가 큽니다. 충돌만 아니면 READY 후보에 가깝습니다.

경로 enrichReasoningMetadataByDestination - summary와 effort를 한 함수에 묶은 것은 읽기 좋습니다. 다만 destination match가 adapter/authMode/baseUrl에 엄격하므로, 사용자가 baseUrl을 살짝 바꾼 CommandCode 클론은 계속 비어 있습니다. 문서의 “fixed key destination only”와 일치하니 괜찮지만, #4308 재현 환경이 그 제약을 만족하는지 확인하세요.

테스트 unknown-model - registry empty picker policy([]) vs provider-wide medium override 시나리오가 나뉘어 있어 좋습니다. export 테스트의 모델 id가 현재 catalog와 어긋나도 fixture로는 충분해 보입니다.

충돌 - 현 브랜치 그대로 머지 불가.

메인테이너의 판단이 필요한 지점

• 작은 destination fix를 conflict 해소 후 단독 land할지, feat(providers): persist exact per-model capability declarations #4374/#4346에 흡수할지
• draft를 READY로 올릴 CI 게이트
• [Bug]: renamed Command Code key provider does not inherit COMMAND_CODE_MODEL_REASONING_EFFORTS #4308 close 조건 (본문은 독립 fix 주장)

너의 추천
conflict만 풀면 land 가치가 있는 작은 픽스입니다. #4374가 close/지연되면 이 PR을 먼저 살리는 편이 사용자-visible export/reasoning ladder에 바로 도움이 됩니다. draft 유지한 채 rebase(또는 새 최소 PR) 후 CI 녹색으로 승격하세요.

이 댓글은 grok-bot이 작성했습니다