标注
AI 提交（由用户授权的 AI 助手根据本机日志与 run 记录整理）。
问题描述
Always-On 某次 run 的 discovery、execute 和测试验证都成功，但最终 run 被标记为 failed，原因是 report 阶段没有调用 always_on_report 工具。
这会把“执行成功但报告收尾失败”的情况误报为整个 Always-On 任务失败，容易污染 run history，也会让用户误以为代码修改或测试失败。
观察到的 run 情况
runId：
09a71061-0aa2-474c-94d7-bee1d837f5f9
实际执行情况：
- discovery 成功生成计划；
- execute 成功修改了 snapshot-copy 隔离工作区中的目标项目；
- 验证通过；
- 测试结果为：
但最终报告文件显示：
outcome: failed
reason: report_tool_not_invoked
报告内容中也出现类似信息：
Plan Reference
(unavailable: report tool was not invoked)
Verification Results
- [ ] (unverified) - report tool was not invoked
Follow-ups
- Investigate why AlwaysOnReportTool was not called.
关键现象
report session 本身看起来是 completed/success 状态，但：
finalMessage.content 为空；- 没有调用
always_on_report；
- Always-On 收尾逻辑将该 run 判为 failed；
- fallback report 被写入，但 outcome 仍是 failed。
影响
- 实际执行成功的 Always-On run 被标记为失败；
- run history / 日志中的失败率被污染；
- 用户需要进一步追 jsonl 才能发现执行和测试其实成功；
- 容易误导排障方向，把 report/tool 协议问题误判为 execute 阶段失败；
- 如果上层调度依赖 outcome，可能导致不必要的重试或错误处理。
期望行为
如果 execute 阶段成功且验证通过，但 report 阶段未调用 always_on_report，希望状态能区分：
execution succeeded, report failed
而不是直接将整个 run 标记为 failed。
例如至少应在 outcome/reason 上区分执行失败和报告收尾失败，避免把成功执行的任务误报为失败。
环境信息
- OS: Linux 6.17.0-35-generic x64
- Node.js: v24.15.0
- PilotDeck 启动方式：systemd user service
- 相关功能：Always-On / report phase / always_on_report tool
备注
本 issue 只报告问题和证据，不提交修复代码。
标注
AI 提交（由用户授权的 AI 助手根据本机日志与 run 记录整理）。
问题描述
Always-On 某次 run 的 discovery、execute 和测试验证都成功，但最终 run 被标记为
failed，原因是 report 阶段没有调用always_on_report工具。这会把“执行成功但报告收尾失败”的情况误报为整个 Always-On 任务失败，容易污染 run history，也会让用户误以为代码修改或测试失败。
观察到的 run 情况
runId：
实际执行情况：
但最终报告文件显示：
报告内容中也出现类似信息：
关键现象
report session 本身看起来是 completed/success 状态，但：
finalMessage.content为空；always_on_report；影响
期望行为
如果 execute 阶段成功且验证通过，但 report 阶段未调用
always_on_report，希望状态能区分：而不是直接将整个 run 标记为 failed。
例如至少应在 outcome/reason 上区分执行失败和报告收尾失败，避免把成功执行的任务误报为失败。
环境信息
备注
本 issue 只报告问题和证据，不提交修复代码。