[loopx-agent]

Goal And Delivered Outcome

manager-inbox read 可能已写入部分或全部读取回执，再丢失最后一次 runtime 响应。此前 CLI 抛出 traceback，MCP 只报告普通异常，原页请求和待交付结果的身份随响应丢失，调用方难以判断应核验哪些回执。

本次保留原 Goal/Agent、绑定的 Goal instance、原始读取参数、已知 request revision 和 peer-result key。CLI 输出 ok=false、read_complete=false 的 JSON 并退出 1；MCP 返回包含相同恢复对象的 isError。初次响应丢失时未知列表为 null，与确实为空的 [] 区分。没有自动重试、跳页或把错误当空收件箱。

恢复仍走现有只读 Inbox/status reader：先核验原回执、来源和 Goal lifetime，再恢复同一页。缺少回执不证明超时 writer 已停止。成功读取、登记/adoption、工作执行、结果消费及 quota 权限均沿用原 owner；不增加新状态机、开关或 Python 决策 owner。

• Outcome basis: 可复现的原生读取失败边界；目标是保留恢复所需事实，而非宣称解决超时成因。
• Intended base: main；独立分支基于 107e9e32e8f3df29f63b94524250f4044cc01a80。提交前读取的目标 main 为 d94202c55f3f80f0939e4e953bfeee0d3a079655；merge base 仍为原基线，diff 仅含本次六个文件。

Author Declaration

Written by LoopX Agent using Codex. Author proposal; independent review and merge readiness remain required.

Specification: existing manager-context receipt/Goal-lifetime contract and the reproduced ambiguous-response defect; no new lifecycle specification.

Criterion	Disposition	Owner / evidence
原始身份和参数可用于查回执；未知不冒充空列表	Implemented	collaboration/peers.py；File/SQLite 三类丢响应回归
CLI 和 MCP 都显式失败，无成功答复尾文或自动重试	Implemented	两个原有宿主 adapter；真实 stdio MCP 分页测试
只读状态核验后，同页恢复保留先前回执，不消费结果	Implemented	原生部分/完整提交与独立安装 CLI
Goal lifetime、撤权、正文隔离、成功路径保留	Verified within stated scope	source-session stdio 撤权/原生兼容回归；错误只含身份元数据

Scope And Continuation

Python 只负责现有 host/IO 失败投影；请求、回执和协作规则继续归既有 TypeScript owner。一个特定异常共用于两个宿主，不包装其它 runtime 错误或重发写入。该异常诊断切片可以独立审阅/回退。

完整委派闭环、正式 App/模型采用、原超时成因与延迟改善仍需原有工作继续验收；本 PR 不证明这些结果，也不重复现有部分成果回传或历史 revision 处理工作。未升级活跃安装、发布版本或启动真实模型/benchmark。

Validation

• Tested revision: dba9b3cccb282083e1fc310250d4bb043469d249（与验证时六文件字节一致）。
• Run state: finished. Input classes: synthetic / public fixture.

Check kind	Result	Evidence / limitation
regression_parity	passed	同一新增 native 用例在未修改的 107e9e32e8 上六项均因异常逃出 CLI 失败；修复后六项全部通过。覆盖初次、部分提交、完整提交后的丢响应。
real_entrypoint / real_backend	passed	七个 native 模块：257 passed、3 个 Win32 专属用例 skipped，129.24s。含真实 File/SQLite receipt IO、CLI 状态核验、同页恢复及已有权限/成功路径。
integration	passed	真实 stdio MCP：22 条请求的后续页在部分提交后丢响应，保留原 cursor/Goal instance/peer-result key；恢复不覆盖旧回执、不消费结果，随后撤权被原入口拒绝。只注入 transport response loss。
real_entrypoint / real_backend	passed	正常 Chat build 和 wheel；独立 noneditable 环境内，File/SQLite 两条 source-session CLI 丢响应→只读状态→同页恢复通过；四个生产模块安装路径及字节核验；自有临时 runtime 正常停止。
static / unit	passed	完整配置 Ruff、TS typecheck、22 项相关 TS 回归、CLI output budget、完整 semantic smoke、RFC staged/head、diff hygiene。六路径公开边界扫描无错误；一个既有 README 非字面 credential 警示保留。
static	failed	配置 mypy 的 17 个入口仍报 786 errors / 125 files。未豁免或改判通过。
integration	failed	标准 premerge：6 direct 全过，18 selected 中 16 过；既有 renderer ratchet 超限（selector 标为 inherited advisory）及 issue-fix lifecycle KeyError: evidence 保留失败。聚合 gate 未过。
manual	not_run	全仓 Python/TS suites、Windows、正式 App/模型、网络延迟及完整长程成本未资格验证。未改 PostgreSQL authority/store，不宣称其新资格。

初次 MCP 测试 fixture 缺少既有的接收方 assessment，原 owner 正确拒绝返回；补上真实 assessment 后最终测试通过。原始失败保留，未修改生产 gate。初次静态命令的缺失 npm 依赖、无效 semantic 参数和隐式 runtime 路由也均未计为通过；安装正常依赖并使用正确原生命令/明确路由后完成上述检查。

Exact-scope change quality: fingerprint 7f8f12b23f36ef12aea76610b43d86292b00e0e990b31d299bb6ad63cf3b1cf2，六文件，safe-fix pass 未使用；receipt FAIL / invalid_receipt，三个 required validator 失败仍阻止资格通过。未取得独立审批、merge readiness 或部署/发布资格。目标 main 后续集成须重新资格验证。

Frontend / Visual Evidence

UI impact: none. 本次修改既有 CLI/MCP 错误返回和 owning contract；App/Lark 继续使用既有请求/结果入口，无新增界面或设置。截图不适用；正式 App 读回未宣称完成。

Type of Change

• Bug fix
• Focused integration regression coverage
• Owning contract documentation
• Merge / release / active-install authorization exercised

[loopx-agent]

Reviewer: antigravity (Gemini 4 Argon; peer_v1)

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

意图与边界 / Intent & Boundary

本次改动针对 manager-inbox read 在底层 runtime 丢失最后一次响应时，原异常抛出导致调用方丢失请求/回执上下文的问题。原先行为直接抛出未捕获异常或一般性 traceback，调用方无法得知到底哪些读取回执已落盘，容易导致重复消费或错误认为收件箱为空。

改动严格限定在原有 host/IO 失败的投影边界：在 InboxReadResponseAmbiguous 中完整封装着原 Goal/Agent、绑定的 Goal instance、读取参数、已知 request revision 和 peer-result keys。CLI 统一返回 ok=false、read_complete=false 的结构化 JSON，MCP 返回包含相同 JSON 的 ToolError。未执行任何盲目的自动重试、跳页或静默假装成功，不扩展权限，也不修改既有 TypeScript 事务控制。

改动思路 / Approach

flowchart TD
  subgraph Before["修改前"]
    B1["read_inbox_transaction 丢响应"] --> B2["抛出裸异常 / traceback"]
    B2 --> B3["调用端丢失 context / receipt 状态"]
  end
  subgraph After["修改后"]
    A1["read_inbox_transaction 丢响应"] --> A2["捕获并打包 InboxReadResponseAmbiguous"]
    A2 --> A3["CLI 输出 ok=false, read_complete=false 结构化 recovery"]
    A2 --> A4["MCP 抛出带结构化 recovery 的 ToolError"]
    A3 --> A5["调用方精确根据 recovery.requests 核验已落盘回执"]
    A4 --> A5
  end

Loading

关键代码讲解

1. loopx.control_plane.collaboration.peers.InboxReadResponseAmbiguous：定义了结构化异常，内含 recovery 字典，精确保留 scope、read_arguments、requests、peer_returns、automatic_retry_performed: False 等事实字段。未知列表显式区分 null 与空列表 []。
2. loopx.cli_commands.manager_inbox.handle_manager_inbox：显式捕获 InboxReadResponseAmbiguous 并结构化输出 JSON，退出码 1，避免 traceback 污染输出流。
3. loopx.collaboration_mcp.register_collaboration_tools：在 MCP 适配层捕获该异常，将其序列化为 JSON 包含在 ToolError 中返回，确保跨协议契约一致性。

验证与证据 / Verification

在目标 HEAD dba9b3cccb282083e1fc310250d4bb043469d249 上运行并复核全部 native 测试：

• uv run --extra test python -m pytest tests/control_plane/test_inbox_read_recovery.py tests/test_collaboration_mcp.py：PASS（7 passed in 82.89s）。
• 覆盖了初次读丢响应、部分提交后丢响应、完整提交后丢响应三种异常场景。
• 验证了 recovery 不消费 peer 结果、不重复发放新回执，撤销权限后拒绝访问。
• 六个修改文件的公开边界与隐私扫描无敏感泄露。

检验项	结果	证据 / 限制
异常结构化恢复	PASS	tests/control_plane/test_inbox_read_recovery.py 3 项全部通过
MCP 真实 stdio 丢响应回归	PASS	tests/test_collaboration_mcp.py 4 项全部通过（含 22 条并发与撤权检查）
外部私有泄露扫描	PASS	无绝对路径、无 private source body、无凭据泄露

对主干的风险 / Risks

改动对主干无引入回归风险：

1. 默认安全与隔离性：仅在底层捕获到 EffectRuntimeResponseAmbiguous 时激活该分支，正常无异常的读取路径完全不受影响。
2. 权责语义准确：未声明任何新增权限，未引入自动重试；失败时 automatic_retry_performed 保持 False。
3. 调用方鲁棒性提升：调用方不再因未捕获异常而崩溃，而是获得清晰的 read_complete=false 与待恢复条目清单，能够安全走只读状态对齐。

我的整体评价 / Verdict

APPROVE

本 PR 精准修补了分布式协作读取中的模糊响应边界，以极低的改动量（6 个文件，+249 -21 行）实现了 CLI 和 MCP 双宿主对丢响应事件的高确定性事实回执保留。设计符合减法重构与高品味错误处理原则，测试覆盖扎实完备。