[loopx-agent]

原管家的旧请求用完三次 quota 恢复后，即使现有路由重新可用，也只剩失败提示，原问题长期收不到答案。现在原服务在重新核验原消息、授权、精确 native user-only 失败和当前受控路由后，可为该请求执行一次已有的 restricted answer review，读取现有产物并返回直接答案或具体缺口。

复用 Core 原 Session、队列、原受众回传与现有只读 sandbox；保留三次业务恢复、旧失败和已投递提示。补答禁止写入、联网执行和派发业务，失败后保持终止。后续原生上下文切换仍可沿同一 Session 的已记录历史核验精确失败 Turn。带附件、未知效果、停止、撤权、改源及无可用路由保持原门。

Validation: TypeScript conversation-binding suite 55 passed；相关 Python 三组回归 178 passed，新增补答路径最终 10 cases passed。旧基线重现 quota 耗尽后不再补答；覆盖改源/停止/撤权、未知 native、缺容量、受限工具、部分答案 gate、违规动作拒绝及入队回执丢失的幂等恢复。真实模型答复质量、安装采用和原消息实际送达另行验收。

[loopx-agent]

Reviewer: model_agent | GPT-6 family | OpenAI | self_reported

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

动机 / Motivation

曾向原管家发送请求的用户会遇到这一问题。旧请求三次额度重试耗尽后只留下失败提示；新路径可在原授权下核查现有结果并补回答案。提供一次受限补答，沿原消息返回直接答案或具体缺口。不恢复业务重试预算，不代办未完成业务，不覆盖附件或未知效果。安装后的真实模型内容和原消息送达仍需逐条验收。

这个缺口会让用户反复追问，且同一句问题的失败提示容易被当成已经回复。现有只读补答机制已经具备独立沙箱、原队列和原受众返回路径；这里补的是它对特定额度失败的资格判断。直接重置三次计数会重新开放业务执行，无法满足保留历史效果的要求。此次交付是可独立安装与回滚的运行时增量，不能代替所有积压业务的最终验收。

改动思路 / Approach

沿用已有受限补答、额度路由和原队列，新增资格判断归TS，原生核验归provider IO。只交付一次受限补答和精确历史定位；业务补执行及安装后实答另验。

原回复 worker 先找到原请求，再由 TypeScript 检查第三次失败与原客户端身份；provider 重新读取精确 native Turn、原消息和当前路由，通过后仍进入同一个 Core Session 队列。新回合使用现有 restricted answer review：允许范围内读取，禁止写入、联网执行和派发。发送答复继续使用原 Lark journal 和读回。执行前还要再次核验原失败记录，不能拿旧容量缓存充当新权限。

需要保留两种原生证据读取：Antigravity 提供原执行片段与可见结果；Codex 的这条新增路径只接受原生 user-only quota failure。两者共享补答沙箱、准入、队列和回传，不是两个业务重试器。历史上下文定位只在同一 Session 已记录的原生来源中搜索，并继续匹配精确失败 Turn；它没有把其他请求的答案复制到当前问题。

具体改动 / Changes

规范基线是 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md，固定版本 faab5f5c291c5359216a0f944fe63fcfbaacdedc。按规范已有要求核对：C-RETURN 对应原会话可读结果，已实现并由真实 File/Core 队列与合成 Lark provider 测试；C-AUTH 对应原权限、额度和效果 owner，已实现并验证停止、撤权、未知原生状态和动作拒绝；C-RECOVERY 对应原身份、持久回执和未知写入不重放，已实现并验证入队响应丢失后的同身份采用。规范中更广的 App 连续性和真实投递资格没有因此自动完成。

关键代码讲解

• planExhaustedStewardAnswer 只接受原第三次 quota continuation 的精确身份、失败且无回复/无增量的状态，以及原源未变化、未停止、无附件的输入。它复用已有容量 owner，生成唯一 review 客户端身份；旧 quota3 记录保留在历史中。失败的 review 不能落回业务重试。
• recover_failed_request 选择正确的 Codex user-only 证据读取，重新检查 provider 来源与当前路由，在已有 source fence 下冻结 reservation 后入队。崩溃恢复采用已准入的精确回合，不能另起一次。
• _checked_answer_review 在模型执行前核原 Turn、绑定、停止与 native inventory。容量后来变化不改写历史失败；原始执行项变化则拒绝补答。提示文字也区分“业务未执行”和“已有执行结果”，避免声称不存在的命令已经运行。

PASS：TS 完整 55 项；新增补答集成最终 10 个参数化用例；相邻三组 Python 回归 178 项，历史定位新增边界另经最终用例覆盖。旧基线用相同 TS harness 得到 54 项通过、仅新增补答断言失败；相同 File/Core 集成的正常补答用例在旧版因缺少 answer_review 失败。语法、双语 RFC 门、diff 和公开边界检查通过。按当前 Goal 的 wait_for_ci=false，没有查询或等待远端 CI。

对主干的风险 / Risks

没有发现阻塞合并的问题。主要成本是每条合格旧请求最多增加一次只读模型调用；它仍会消耗额度，也可能只返回带具体 gate 的部分答案。缺容量、改源、撤权、停止、附件及未知 native 效果维持保守等待。原业务失败、三次计数和已投递提示按字节保留；违规业务动作会被拒绝，补答失败也不会重新开启业务预算。

最强反例是第一次受限补答切换了原生上下文，使后续旧问题找不到原失败。这里已检查真实上下文历史写入 owner，并通过 TS 的历史来源用例验证精确定位及排除其他 provider；不是只看单次成功。File/Core 集成还覆盖执行前 native 变化、入队回执丢失、部分答案保留 pending，以及旧回执不变。模型、账号与消息 provider 是合成边界，这些测试不认证实际答案质量和生产投递。

普通 project、非耗尽请求及后续普通问题保留原调用路径；当前改动没有增加前端设置、手动标记或新的确认轮次。复用既有 answer_review / read_only_review 语义与权限 profile，没有新 vocabulary 或并行状态权威。生产文件虽已较大，继续共用已有容量与补答 owner 比再建 service 更小；不同原生证据的匹配条件应继续分开，不能为减少分支而合并权限。

我的整体评价 / Verdict

这是 justified_increment。long_horizon 改善体现在原问题得到一次有限、可恢复的补答机会，同时保留全部业务失败并阻断循环重试；user_experience 改善体现在不要求用户重新输入或再次确认，原消息可以收到直接结果。这里没有改渲染布局、前端控件或设置；视觉审查不适用，未验范围为真实模型内容与安装后原消息投递。

沿用已有受限补答、额度路由和原队列，新增资格判断归TS，原生核验归provider IO。只交付一次受限补答和精确历史定位；业务补执行及安装后实答另验。该范围与问题相称，现有语义得到复用，完整父目标和受保护操作继续保持原门。审阅目标为 56efc98d9bd38ee459dfc6612f1852ce89a4628f，发布前仍核远端 head，安装采用后由原服务自行补答并独立读回。

English verdict: APPROVE this exact-head restricted-answer recovery slice; live answer quality and original-message delivery remain separate acceptance.