|
|
4174310421
|
fix(channels): 渠道鉴权头三修 + 源名契约 + 夹具形状判据
P1-1 anthropic 基座补 build_headers（x-api-key + anthropic-version）
根因：基座只有静态 anthropic-version、没有 build_headers ⇒ 内核兜底发
Authorization: Bearer，而 Anthropic 协议要 x-api-key。
★ 证据冲突（计划 P1-1 原文一半有误）：zcode 的
/zcode-plan/anthropic/v1/messages 虽然**说 Anthropic 协议**，鉴权却是
Bearer <zcode_jwt>（参考 zcode-transport.ts:121-125；全仓 grep x-api-key
= 0 次命中）。故 zcode 必须**显式覆盖** build_headers 回到 Bearer，
否则基座的正向修复会把它从"对"改成"错"。
内核改动：internal/provider/provider.go —— 兜底 Bearer 让位给 x-api-key，
避免同一请求带两套鉴权（部分 Anthropic 兼容上游对歧义鉴权直接 401）。
P1-2 channels-cline 的 build_headers 补 workos: 前缀
根因：参考 cline.ts 发 `Bearer workos:<jwt>`，而池里存的是第二步 register
换回的裸 token ⇒ 之前无 build_headers，内核兜底发裸 Bearer。
幂等：已带前缀（含大小写变体）不重复拼。
P1-3 channels-gemini 只确认不改
参考 gemini.ts:353-366 同样是 OAuth Bearer + 身份五头、刻意不发
x-goog-api-key ⇒ 我们现状本来就对。加判据把这个结论钉住，防下轮照
P1-1 的模子把它改坏。
P2 源名契约：仅 [A-Za-z0-9_-]，禁 : 与 /
根因：: 与 / 是限定名分隔符，出现在源名里会让 `源名:模型名` 有两种都
自圆其说的切法，同一请求串在不同部署下可能路由到不同源，且**不报错**。
校验加在写入口 core.normalizeSource（硬拒，API 400）；启动时只告警，
避免存量带 : 的源名让升级 brick 掉整个网关。
解析入口 splitPinned 不做校验（解析不该拒绝已有数据）。
P3 夹具形状判据（本轮最重要的一条）
根因：trae 的 Result 信封缺陷在扁平夹具下所有判据全绿，真实登录却报
「缺少 Token」—— 夹具形状错 ⇒ 判据必然虚假通过。
通用形状层：shapeFamilies 登记表，每族给 real/naive/fact/eval/assert，
断言 fact(real) 且 !fact(naive) 且 assert(eval(real))。
刻意**不比较 eval 输出形状**：trae 余额实现合法保留顶层兼容路径，
拿输出比对会把合法兼容判成错误；能区分真假的是 fact（额度在哪一层）。
另有仓库扫描：对特征明确的退化形状静态反查，需退化夹具时写 SHAPE-OK 豁免。
判据：11 个文件 / 30 用例。全部变异已验证会报红（9 处）。
|
2026-10-18 00:38:49 +08:00 |
|
