pikasTech-unidesk/docs/MDTODO/details/sub2api-upstream-reliability/R2.2.13_Task_Report.md

R2.2.13 任务报告

下发结果

已向PK01当前全部非 lyon9801 OpenAI账号精准批量下发 codex-upstream-failover：显式selector为19、27、28、29、30、31、32、33、34。

• selected：9
• changed：8
• succeeded：8
• failed：0
• noop：账号27已提前匹配模板
• lyon9801（15）：未进入selector，保持0条规则、无模板

最终账号19、27、28、29、30、31、32、33、34均为7条规则，状态码集合400、429、500、502、503、504、524，模板均为 codex-upstream-failover。账号29、30仍保持余额不足导致的error与schedulable=false；模板下发未恢复账号状态。

CLI修复

原CLI文档声明支持 --accounts，但parser实际拒绝。已恢复通用精准批量入口：

• 支持1至100个逗号分隔ID或精确名称；
• --account与--accounts互斥；
• 仅apply/delete接受批量selector；
• 先解析全部selector并校验账号类型，再进行任何写入；
• 默认Kubernetes风格批量计划与结果表；
• 参数解析拆到 runtime-options.ts，runtime.ts收敛到2915行。

Artificer后续任务R2.2.14 / issue #1998负责把确认写入后的自动批量回读对账内建到CLI，消除外部逐账号get。

真实效果

下发后首个5分钟窗口：

• 约85请求；
• 5个上游错误；
• 0客户错误；
• unidesk-codex-pool：5次临时不可调度、3次failover、3次全部恢复；
• 自用：2次failover、2次全部恢复。

请求 290215cf-e32b-44df-b2d6-842298c7e690 证明新400规则真实命中：账号27收到上游400，规则1将其冷却1分钟，当前请求切到账号33，4.055秒后最终HTTP 200，错误未暴露给客户。

10分钟窗口出现的请求 68cd320a-4d2b-482e-93ed-284625096d8f 是模板下发前开始的旧长请求：等待约719秒后502，切号时context canceled，不能据此判定新模板失效。

Skill固化

账号排障reference已固化：

• 非auth错误优先使用状态码加稳定短语的通用模板；
• 先确认响应提交前能触发当前请求failover；
• 禁止账号、ID、provider URL或分组硬编码；
• 禁止通用400或宽泛invalid request；
• auth/token/余额/凭据状态保留专门路径。

验证

• 批量dry-run：9个selector全部解析，8 update、1 noop。
• 批量confirm：8 succeeded、0 failed。
• 再次批量dry-run：9/9 noop。
• 逐账号运行态对账完成；后续由R2.2.14把该过程内建到CLI。
• bun --check通过。
• git diff --check通过。
• skill quick validate通过。