[Priority: Med] [Review] 审查 streaming completed 是否需要补最终 status.message

[liujuanjuan1984]

🔍 发现的问题 / 原始需求描述

• 审查结论：需求仍然值得审查，但核心问题需要进一步说清楚。当前主干的 streaming 路径已经不是“只有 chunks、没有最终结果”：src/opencode_a2a/execution/coordinator.py 会在 completed 前补 final text snapshot artifact，src/opencode_a2a/output_modes.py 也会把 stream artifacts 规范化并持久化到 terminal task。
• 因此，这个议题真正要审查的不是“是否补一条 completed status.message”，而是：当 A2A 下游在流式过程中只收到增量 chunks、出现中途断流、只订阅到后半段、或只在终态读取任务结果时，协议/实现是否应保证一个可直接消费的完整结果快照；如果需要，这个快照是否应落在 status.message，还是 artifact 已经足够。
• 需要结合 A2A 生态进一步判断：当前 artifact-first 的 terminal 表达是否已经符合上游协议倾向，还是仍有必要为只消费 terminal status 的客户端补充一个更直接的完整文本入口。

🛠️ 详细实施方案

• 先做 characterization tests，确认当前行为下：
  1. streaming terminal task 通过 artifact 已可重建最终文本；
  2. GetTask / terminal replay 是否已经能够覆盖“chunks 不完整”风险。
• 在此基础上，再评估是否需要额外合成一个完整结果快照入口。若决定实现，不应预设 status.message 是唯一答案；必须先比较以下几种边界是否更符合当前 A2A 契约语义：
  • 保持 artifact-first，不新增 status.message
  • 仅在存在唯一 canonical final text artifact 时补 status.message
  • 通过更明确的 terminal task snapshot/聚合规则解决，而不是引入新的输出冗余
• 需要联动检查 src/opencode_a2a/execution/coordinator.py、src/opencode_a2a/output_modes.py、src/opencode_a2a/server/application.py，确保 terminal event、持久化结果、GetTask/SubscribeToTask 返回面保持一致。
• 核心逻辑/伪代码：

final_snapshot = resolve_terminal_result_snapshot(task)
if final_snapshot is already reliably reconstructable from artifacts:
    keep artifact-first contract
elif unique_final_text_artifact exists and ecosystem expects direct terminal text:
    consider deriving status.message from that artifact
else:
    avoid adding a second ambiguous final-result channel

• 涉及文件：src/opencode_a2a/execution/coordinator.py、src/opencode_a2a/output_modes.py、src/opencode_a2a/server/application.py、tests/execution/test_streaming_output_contract_core.py、tests/server/test_output_negotiation.py。

🧪 回归测试建议

• 增加 streaming 终态场景测试，覆盖：仅 text artifact、text + tool_call、多 message_id、structured-only 输出、无 upstream message_id fallback、终态只通过 GetTask 读取结果。
• 校验 GetTask 与重新 SubscribeToTask 时，最终文本不会重复、不会丢失、也不会错误拼接 reasoning/tool_call 内容。
• 如果后续决定补 status.message，必须额外验证不会与现有 artifact replay / output negotiation 形成双份文本或语义漂移。
• 执行 bash ./scripts/doctor.sh。

[liujuanjuan1984]

开始评估。已同步最新 main，清理本地旧分支，并新建工作分支 eval/issue-455-completed-status-message。接下来会先审查主干中 #454 合入后的流式完成态行为，再对照当前 a2a-sdk 语义给出结论。

[liujuanjuan1984]

评估结论：当前不建议在流式 completed 的 TaskStatusUpdateEvent 上默认再拼接一份最终 message。\n\n依据：\n- a2a-sdk 的 ResultAggregator / TaskManager 会分别聚合 status_update 与 artifact_update；流式结果的规范承载路径本来就是 artifact，TaskStatus.message 是可选字段，不是流式最终结果的必选载体。\n- 当前主干已明确采用“流式 artifact + terminal status”模型，并在无最终文本块时补一个 final_snapshot artifact，避免结果缺失。\n- 若在 completed 再塞一份文本 message，会把同一最终答案同时放到 artifact 与 status 两条通道，造成重复消费、终态回放重复语义，以及 GetTask / terminal replay 契约膨胀。\n- 当前 CLI 也主要消费 artifact 更新来渲染文本；对现有消费路径帮助有限。\n\n建议：\n- 保持现状作为默认契约。\n- 如果确实需要“更利于消费”的视图，优先在 client/helper 层提供聚合能力，或设计显式 opt-in 扩展，而不是直接改默认 wire contract。\n\n本轮只做审查评估，未改代码。