[loopx-agent]

API 请求返回 HTTP 200 后，如果 Responses 流中最终报告额度错误，relay 过去仍将 Key 记为 accepted。后续请求会再次选中受限 Key；同时，管家的安全恢复只观察订阅额度，可能忽略其独立 API 主力池。

本次在现有 TypeScript 账户策略中识别结构化流错误，由 relay 有界观察并更新所选 Key 的后续可用性。当前流原样返回；下一次独立请求使用现有候选与冷却规则。管家的恢复复用既有账户路由，只在原生会话证明该原请求尚未执行时补充额度判断，继续通过原队列、原消息核对和原受众回传。

验证：真实 loopback HTTP、私有账户 store、Core/Lark 原消息恢复与独立回读回归；基线的两个流错误用例和一个管家恢复用例均复现失败，当前实现通过。重点覆盖普通输出包含错误文本、断流、池耗尽、原生效果未知、源消息修改、停止和过期容量。

TypeScript 策略测试与静态检查已通过。整组 Python 回归、服务使用的 Python 3.12 路径和仓库 premerge 结果将在 exact-head review 中记录。生产消息是否已经完成、是否实际送达，仍由升级后原服务的独立验收确认。

[loopx-agent]

Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; runtime_reported; reasoning_effort=max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机 / Motivation

管家在 API 池启用时接收原私聊问题。HTTP 200 流中报额度不足时，旧实现仍把 Key 记为 accepted；修复后只改变下一次独立请求的候选，当前流仍原样返回。原服务可使用自己当前允许的 API 池判断未执行请求的恢复资格。本 PR 不证明任何历史业务已完成，也不保证实际账户余额或全量消息已经送达。

线上三条消息的业务执行与正常回复，仍须升级后由原服务完成并独立读回；历史未知效果继续核对。这是一项有独立可用价值的修复：避免受限 Key 在后续请求中反复排第一，也避免管家的独立 API 主力池被无关订阅额度挡住。没有阻塞项；生产积压是否完成仍保留为后续现场验收。

改动思路 / Approach

线协议观察留在 Python relay，错误分类复用 TypeScript 账户策略，补办资格留在既有 Core 队列和类型化恢复决策中。本次只修正既有额度状态反馈及管家恢复容量来源，不新增消费者、任务、调度器、付费许可或消息来源。只修改提示语无法修复账户候选，只更新 Key 也无法修复恢复容量来源；两处都直接复用现有责任层。TS 判断结构化终态错误，Python 仅保留最多 64 KiB 的临时帧缓冲并转发原字节，Core 继续核验原来源、授权、停止状态和队列。原失败与已经发出的流都保留。

具体改动 / Changes

审查完整 head 0e6f19be1e571c4edbc2e88cc5b336171fe88bf5，基线 a4370d644af3932b8c6aef62f8d161aed709dfc9，共 7 文件，+269/-6，其中生产 +81/-5，测试 +188/-1。远端 patch 的邮件头说明了与普通 git diff 的封装差别；PR head 与本地提交一致。阅读了当前 PR 正文、全量文件和提交，无既有评论；并检索现有 API/原消息恢复 owner 及同类改动，未发现更新主干改变本次调用链。

接受契约：packages/loopx-codex-provider-routing/NATIVE.md，spec_revision a4370d644af3932b8c6aef62f8d161aed709dfc9。Native-consumer-role：复用独立管家 role，worker 仍订阅优先；Native-started-stream：当前流只转发、下一次独立请求才换候选；Native-private-key-owner：同一私有 store 仅保存内容无关的运行观察，余额仍不可得。这三项均由真实 HTTP/Core 回归实现并验证。GQ09 的全部历史兑现结果没有在本 PR 宣称闭环。

关键代码讲解

• apiStreamOutcome（openai_policy.ts:8）只接受 error 或 response.failed 的明确 code；后者还必须有 failed 状态。普通输出里写“quota”不能触发账户状态变更。HTTP 与流事件复用同一 quota code 集合及既有 cooldown 规则。
• _StreamOutcome.feed（openai_relay.py:30）处理分片、CRLF、多行 data 和超长帧；普通 token 不启动策略进程。临时缓冲不写盘，无法识别的错误保留原响应。
• RelayHandler.do_POST（openai_relay.py:185）将观察结果写回当前选中 Key 和 model；流已开始后没有返回 Key 循环，既不合成完成，也不重放请求。真实 loopback 测试断言完整字节和一次上游调用，再独立发起下一次请求验证第二把 Key。
• recover_failed_request（external_conversations.py:349）仅在 usageLimitExceeded、原生只包含原用户输入且为 steward context 时补充既有 account owner 的容量观察；随后仍回到原 source fence 与 TS freshness/backoff/attempt 检查。真实 Core/Lark store 路径断言原失败字节不变，新结果由原 Bot 身份投递并独立读回。

对主干的风险 / Risks

最强反例是把普通文本当额度错误，或把“有候选 Key”误当已执行/已送达。本实现分别用 typed event、原生无效果证明和原来源核验隔离。未知或部分帧、所有 Key 冷却、native tool/未知效果、原消息修改、stop、过期容量均保留原请求；普通 worker 和管家 token 不能交叉付费路径。

PASS：25 项额度/Core/Lark 测试，45 项传输/账户/history 测试，服务 Python 3.12 的 37 项选择回归，54 项原会话 TS 测试，3 项账户策略 TS 测试；Python 编译、两组 TS 静态检查及 exact-head premerge 通过。相同新测试置于基线生产代码时，3 项分别复现 accepted Key 和遗漏安全续办，12 项否定/关闭路径通过。首次混入 head Core 的探索运行已被带生产 import 路径核验的基线运行替代。初始更宽的辅助 Python 运行在 119 项通过后主动中止，没有声称全套通过。CI 按当前 Goal 的 wait_for_ci=false 未查询。

仓库 maintainability 检查在基线和当前 head 均报同一 _admitted_interaction_next_cli_actions 过大项，完整失败输出相同、责任文件 git blob 相同；premerge 保留为 inherited advisory。本 PR 不将其伪装为已修复，也不改变阈值。付费 OpenAI/Lark 网络与模型执行使用合成上游；这证明责任边界和原消息恢复路径，不能证明线上额度充足。已投产消息必须由升级后原服务另行完成独立验收。

我的整体评价 / Verdict

这是 justified_increment，long_horizon 和 user_experience 均 improved：后续请求可避开已观测受限 Key，原服务可沿既有队列恢复明确未执行的原请求，用户无需重复已提供的要求。线协议观察留在 Python relay，错误分类复用 TypeScript 账户策略，补办资格留在既有 Core 队列和类型化恢复决策中。本次只修正既有额度状态反馈及管家恢复容量来源，不新增消费者、任务、调度器、付费许可或消息来源。没有新增持久协议、手工同步状态或重试服务，生产代码量与两处实证故障相称；保留当前设计。

没有渲染层改动，visual_review 为 not_applicable；现场业务回复仍为 unverified scope。原消息吞吐延迟、历史未知效果与全量积压兑现都不以本次 green 测试或合并代替。语义保持为 provider-local typed outcome，复用现有 quota_exhausted、cooldown 与 Core no-effects 规则，语义 vocabulary 检查通过。合并仍须当前 head、讨论与单独 readiness/原授权检查。

English verdict: APPROVE 0e6f19b; no blocking finding. Typed streamed quota feedback and consumer-specific safe recovery are covered by baseline/head real-boundary tests; installed historical business completion remains separate acceptance.