fix(chat): preserve substantive answers after context handoff

[loopx-agent]

Chat could stream a substantive Markdown answer and then replace it with a handoff acknowledgment before saving the final response. Preserve the audience-processed answer and append delivery/dispatch status from the existing receipts. Empty answers retain the compact brief preview.

The change stays in the manager-context presentation adapter: execution grants, operation identity, acceptance and original-conversation routing retain their existing owners. The README documents the changed acknowledgment; regressions cover refusal, revocation, stop, retry and stream/final/restart parity.

Validation: 292 affected/adjacent source tests passed, including real disposable File/SQLite delegation and original-return paths; the wheel qualification and native canary results are recorded in the exact-head review. The old implementation failed five new preservation regressions. Mypy and semantic validation passed. Live model/Lark delivery and installed maintainer adoption remain outside this deterministic fix; no CI was queried under the managed review policy. Runtime change: leave for protected maintainer merge.

[loopx-agent]

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

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

Exact head: be5e82549abafcb9952ecf0a6e2aa03ee17b6244

动机

Chat 用户在要求转交已有结论时会遇到答复丢失。例如先看到一段包含纠正结论和 Markdown 列表的流式答复，交接后最终记录却只剩“已送达”；重新打开对话也找不回原结论。现在最终记录保留原答复，再追加真实交接状态。真实 Chat 入口、持久化和重启读回已验证答复保留一次，重试复用原操作；空答复仍显示紧凑预览。本 PR 修复交接后答复的展示和落盘，不扩展执行权限，不证明真实模型路由、飞书投递或整个 SQLite 发布资格。受保护合并后的维护者本机采用和真实模型/飞书完整旅程仍需原验收接续。

改动思路

复用现有 Chat 后处理和回执投影即可修复信息丢失；新增状态机、权限开关或另一套摘要 owner 会增加维护成本且无助于这个问题。当前 PR 只改变 handoff_response 的答复组合、文档默认说明和既有回归；接收方简报、dispatch、权限和原对话返回继续使用现有 owner。入口仍是 ChatRuntimeController._run_started_turn → apply_context_handoff：原有 audience 处理负责 Markdown 与隐私，投递与 dispatch 负责权限和实际执行。后处理只组合已处理的答复和回执说明，不增加额外模型调用、收件请求、状态字段或权限开关。有实质答复时不再重复完整简报；没有答复时保留旧的紧凑预览。

具体改动

关键代码讲解

• handoff_response（execution.py:164）保留非空字符串原文，局部 present 只追加状态。成功路径仍先核来源权限、投递，再调用原 dispatch；失败路径追加原拒绝说明。source_store 增加 type-only 注解，避免运行时循环导入。
• handoff_message（execution.py:118）本身未改状态规则：送达、提交执行和确认完成继续分开。调用方有答复时不传重复 brief，空答复时仍传原 brief。
• 原执行测试改名并补充三类空答复、撤权/投递失败/停止、同操作重放、正常隐私处理和模型完成声称不改变 receipt 的回归。项目 Chat 测试直接比较流式正文、最终保存值和重启读回，并继续走真实 CLI 接收/返回。
• README 明确披露原来的覆盖默认改为保留答复加状态；完整接收简报、历史、权限和回传要求不被删减。

规范基线：loopx/capabilities/manager_context/README.md，spec_revision 95868b661045b00f85d8ff6049c331dff9268a1e，已先阅读旧版 Semantic delegation and peer review，未用新文档自证兼容。Receipt separation：implemented，模型声称不升级 prepared 状态；Durable replay：implemented，同一操作和原对话返回保留一次；Complete brief：implemented，真实 File/SQLite 合法长简报交付未变，空答复兼容预览。上述是原文要求的映射标签，不是新 RFC 里程碑。

对主干的风险

最大的风险是保留模型“已完成”文字后让调用方误把它当成执行证据。当前结构化 context_execution 始终来自原 dispatch，测试证明正文声称不会把 prepared 变成 accepted；撤权、停止和投递异常不会因此启动工作。原隐私处理链未迁移，经过正常 normalizer 的受保护路径在失败答复中仍被遮蔽。重试仍用原请求/操作，最终读回没有重复正文或重复返回。

主干旧 adapter 注入真实 Chat 入口后，新的保留断言失败（1 failed/3 deselected）；之前五项保留回归也在旧实现失败。最终 head 的六组源码测试 292 passed，完整 wheel 的三组 60 passed，覆盖真实可丢弃 File/SQLite、原回传和重启。mypy、语义检查、严格 CQR 与原生 canary 均通过；canary 有 5 个直接检查、15 个选定检查，零失败/手动 hold，四文件公共边界干净。打包早期缺 test extra、fixture 相对 TS 路径及重建前的 bundle manifest 均已定位为构建环境问题，按正常安装/构建恢复后完整原测试通过，未删断言或放宽预算。

语义与 CI 对齐

复用已有回执 vocabulary，无新协议、状态分类或平行 Python 决策源；本地非空判断只控制展示。默认行为改变已在 README 和重命名回归披露。没有新增 opt-in 能力、自动加载指导或 quota/scheduler 强制义务，非 handoff 旁路保留。依 managed policy wait_for_ci=false 未查询、轮询或等待 CI。#6125 修的是此前的流式生成/解析，不能覆盖这个后处理丢失点。

我的整体评价

没有发现此有界变更的阻塞问题，APPROVE。long_horizon 改善：重试、持久化和重启保留已有有效结论；user_experience 改善：用户在原对话直接读到正文和真实状态，无新增导航、重复输入或确认。该增量有独立可验证价值，维护成本局限于既有展示 owner，撤回不需数据迁移。原简报/receipt 兼容保留，相关精简已通过局部组合和 type-only 注解完成；无需新框架。真实模型/飞书完整旅程、本机采用与独立维护者批准仍未被这些合成测试证明。运行时 PR 交受保护 maintainer 合并，自评不授予合并权限。

English verdict: APPROVE - be5e825; preserves the processed answer and appends receipt-backed status, retaining blank-preview and authority/replay boundaries. Source 292 and installed wheel 60 passed, with real disposable File/SQLite and original-conversation readback; mypy, semantic checks, strict CQR and risk canary passed. Live model/Lark and maintainer installation adoption remain separate.