[loopx-agent]

缺少原始交接证明时，返回事务会丢失具体原因：尚未发送的 legacy 结果只留下通用失败，Chat 原交办卡显示“回复送达尚未核验”。本变更保留已有 initial_delivery_receipt_unavailable 原因，并在原交办卡和回传状态上显示“原始交接待核验”。

这是 overall roadmap R3 与 controller/executor RFC C6/C8 的原会话结果回传诊断改进；不代表完整双 session 交互或长程收益已经验收。

• 复用 TypeScript lifecycle、sourceFailure、现有错误字段与 i18n owner；没有新状态、配置或 provider。
• 发送前仍按原退避恢复；已有 accepted attempt 保留其身份和显式未核验状态；exact profile 仍拒绝不符证明且不新增回执写入。
• 已送达或 superseded 状态不被残留错误覆盖；相似错误字符串保持原有通用提示。私有 Chat 原交办卡遵守现有受众边界。

验证

测试基线为 e9eda527afd5fcb262ee7c199e1822b1a936cc24，测试版本为 ce1563fc493ea0c88f83ede6b4e09c338bf9f994。新反例在不可变基线上，原生事务和真实 HTTP 返回路径各有 2 fail / 2 pass；最终实现各为 4 pass。早期夹具缺少原消息、对外部会话错误要求私有卡片，以及把 SSE 观测计数误作执行变化的失败均保留为设置问题，未据此放宽产品边界。

• TypeScript 全套：5864 pass、77 skip；core typecheck 通过。
• 7 个相关 Python 模块：266 pass，覆盖私有/外部回传、Goal instance、原会话 HTTP 读回和 Lark adapter 回归。
• 打包 chat-recovery 场景与 conversation-returns 检查通过：同状态仅原因变化、严格错误匹配、正常状态、残留错误、唯一结果和无额外模型 Turn。
• 实际构建 wheel，确认其中原生模块和 Chat assets 与测试源码一致；隔离的真实 Chat HTTP/store/return pump 验证退避 0 → 合法源恢复后 1 → 重启后 0，原请求/路由/结果及原 Turn response 保持不变。
• 标准 premerge 19 项、Ruff、diff/public-boundary/bilingual checks 通过；exact-diff author CQR pass。独立审查与 CI 仍由 PR 流程确认。

未执行 live 模型、真实外部消息、安装或完整长程实验。没有 authority-store 变更；本变更不重做默认 SQLite 性能资格。构建保留原有 chunk size warning。没有合并授权。

视觉证据

使用 Ego Lite 实际检查 1512×982 与 390×844。下图全部为公开安全的合成会话：before 是基线源码编译的 Chat frontend，after 是当前 wheel 的 Chat frontend；二者读取同一个隔离的真实后端失败状态。窄屏图滚动到原交办卡，中文与英文提示均已检查。长 brief 的背景、约束和验收仍在现有展开区，未横向溢出；恢复后只有一条结果并显示已送达。此证据属于 packaged/synthetic 边界，未声明已安装或真实渠道资格。

视图	Before	After
桌面
窄屏

恢复后的原会话结果：

[loopx-agent]

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

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

动机

未发现阻塞问题。本结论仅绑定 ce1563fc493ea0c88f83ede6b4e09c338bf9f994，base 为 e9eda527afd5fcb262ee7c199e1822b1a936cc24。

从原会话交办并等待结果的用户。原始交接凭据缺失时，过去只显示“回复送达尚未核验”；现在明确显示“原始交接待核验”，凭据恢复后仍沿同一请求回传一次。这使用户能区分结果已经形成与原请求是否具备回传凭据，无需重复委派来探查原因。

这是可独立交付的诊断修复。完整的双会话、已安装版本和外部通道采用仍未验证。本 PR 不关闭 R3、C6、C8 的持续接收方采用、已安装 App 或真实外部 provider 验收。

改动思路

诊断与发送资格继续由现有 TypeScript 回传 owner 管理，前端只呈现精确错误，不建立第二状态机。当前 PR 的交付边界是原会话缺证原因及既有恢复结果的可读性，不是新增发送能力或完整双会话资格。

仅改标签拿不到被后台 catch 丢失的原因；只改后台则用户仍看不出差别。现在精确传播已有 initial_delivery_unproved → initial_delivery_receipt_unavailable，两处原会话显示共用谓词；没有增加存储、开关、重试入口或人工确认轮次。

规范依据：docs/architecture/rfcs/controller-executor-unified-contract-v0.md，不可变版本 e9eda527afd5fcb262ee7c199e1822b1a936cc24；同时阅读同版本 docs/architecture/rfcs/loopx-overall-roadmap-v0.md 的 R3。C8 的本次范围是原会话失败/恢复 readback；C6 完整双会话交换与 R3 持续接收方采用保持未完成，不能由诊断字样认定通过。

具体改动

• admitReturnLifetime / prepareReturn 只在 typed reject 精确等于缺失原始证明时保留该错误；其他拒绝保留原通用处理。
• sourceFailure 继续使 exact 请求不写新收据；legacy 已接受的 attempt 保留 locator 并保持未证，不能重置成第二次发送。未发送状态沿既有 backoff 恢复。
• needsOriginalDeliveryProof 使用严格等值，明确排除 delivered / superseded；CollaborationCard 仍取当前 revision 的结论，旧错误不能覆盖已确认送达。

独立验证：58 项 TypeScript 通过；真实 HTTP/ChatSessionStore 及相关回传测试 165 项通过。相同四个新增 native 用例在 base 上 2 fail/2 pass、head 上 4 pass；相同 HTTP 用例也由 2 fail/2 pass 变为 4 pass。失败内容明确是旧版丢失具体错误码，未靠删断言改变预期。恢复后原会话只出现一个结果，重复 drain 为 0，原 request/route/result 保持。

标准 canary premerge --from-git-diff 的 19 项与 5 个 direct checks、control-plane/dashboard typecheck、Ruff、build:chat 与 conversation-returns 验证通过。检查在该源码 worktree 完成，没有运行真实模型、发送外部消息或改动安装。

对主干的风险

主要风险是把“具体诊断”误当成重新发送的许可，或覆盖原 Goal instance/受众边界。已按已发送/未发送、legacy/exact、私有/外部的相反方向核验，现有权威 owner 和终态优先保持。两显示消费者共享谓词是本次已应用的同域收敛；更大的状态类型改造不应绑在这个修复里。

CI 未查询、未轮询、未等待，状态仍未知。独立本地证据已覆盖本次改变的不变量；CI 未知不是本次 review 的阻塞项。批准结论不代表 GitHub 正式自我批准、merge readiness 或合并授权。

我的整体评价

原会话的同一张交办卡片给出更具体的缺证原因，正文与请求身份仍在原处；默认说明不增加额外操作。我独立查看了 PR 当前 head 的公开 before/after 桌面 1512×982、窄屏 390×844 及恢复原图：交办目的与接收方仍清楚，缺证原因在详情关闭时可见，窄屏正常换行，恢复结果仍在原会话下方。复用当前 head 的公开合成捕获；本次未独立跑通完整管家浏览器服务、长正文展开与已安装 App，也未验证真实外部 provider。

额外搭建的本地预览脚手架缺少管理会话/action-service 配置，未将其算作完整浏览器通过；采用的是上述 head 绑定的公开视觉证据，并由本次真实 HTTP/store 恢复对照补证。这个切片值得保留，完整 C6/C8/R3 与实际用户收益仍需原范围的独立验收。当前可给出 APPROVE；本次没有合并、撤销旧 review 或外部回信。

English verdict: APPROVE — the exact-head repair preserves return authority and replay behavior while exposing the missing original-handoff proof.