修复 Chief 执行故障与快照反馈，保留 Agent 自主恢复和路由决策 #2393

Written-by: Codex

目标分支与负责人

• 实现 / PR 目标：delivery/ai-centric-development-service。
• Assignee：@zy95-12。
• 本条记录 Owner 已确认的修复策略；本次仅落 Issue，不授权修改现场任务、凭据、资源配置或部署。
• 关联 Let Chief autonomously recover from invalid decisions with structured feedback and bounded correction #2327、Return input-receipt protocol errors to the current role for bounded correction without weakening batch scope #2338（已有 correction/收据协议）、明确重启恢复窗口与 Chief inspect 失败分类，打通中断 Attempt 的安全恢复路由 #2347 / PR Recover Chief inspections with explicit execution and verification boundaries #2366（恢复与失败分类）、完善 Chief 自主推进策略与运维个人代理协同闭环 #2342（Chief 自主推进）、Recover interrupted Chief inspections and bound scheduled execution lifecycles #2330（巡检生命周期）、Reconcile proven execution exit with durable claim retirement before integration admission #2375（可信退出后的 claim 持久退场）、Automatically enter the host merge flow after Reviewer approval of the current candidate #2331（受控合入）。

核心原则：框架增强不能牺牲 Agent 自主性

Owner 明确：不是禁止新增框架层，而是不能加入一堆写死的业务机制，替 Agent 决定下一步。

• 框架提供持久化、消息交接、权限与证据校验、真实执行状态、清晰且可操作的错误反馈。
• Chief / 角色 Agent 决定如何诊断、是否修正、续测、续审、返工、换资源、咨询、等待或结束。
• 禁止“测挂必回 Developer”“失败 N 次必转人工”“按异常类型自动选择下一角色”等固定路线；不新增固定 DAG、恢复业务调度器或另一套状态存储。
• 复用现有 Run、Task、Attempt、Session、snapshot、correction、Effects 和配置预算。预算用于限制资源消耗，不作为自动选路或转人工的业务规则。
• 自主性不授予越权、伪造验收证据、复用失效收据或跳过未知执行退出的权利。

背景与核实边界

OpenToday 报告 Chief inspect / 定时巡检反复出现 route / return / needs-human / blocked 抖动，已有 approve 的 Living Memory 仍显示 Chief execution did not complete。报告涉及项目 project-b8151e86-…、主任务 task-5f91954b…、Living Memory task-4efe68b…，以及宿主从 e6405532 到 d39e70bc 的版本变化。

现场 run / 时间线依据用户提供的记录；当前核查环境没有报告中的 /home/box/.flybot-backend，没有独立读取现场状态或 transcript。以下是对交付提交 d39e70bc35d3c88cf36b9726ccc025c6e946686f 同树代码的隔离验证结果，不将现场推测写成已证明根因：

1. **JSON correction 已存在。**把 "passed":true 改为报告中的无效 JSON 后，当前 parseChiefResponse 返回 bot/chief-protocol，实际 callback 进入 correction-pending，invocationHistory.length=1，未应用业务决策。当前 parser 不会直接把裸 V8 语法错误写入 run.failure。
2. **快照范围预检仍有整批耦合。**snapshot 仅含 Task t，却返回 t/u 两个决策时，当前整批进入 correction，t 的合法决策也未应用。
3. **Interrupted 续 Tester/Reviewer 已实现。**当前 validateRecovery / resumeVerification 在候选、同 SHA 测试、退出证明等满足时允许恢复，不应重新开发一条替代路径。相关4个恢复回归通过。
4. 执行失败会污染 Task 阻塞表达。result.ok=false 会被概括为 Chief execution did not complete，并在当前非终态 Task 的 collaboration.block 写入该原因。隔离复现中 Review 的 approve 证据仍在，并非被撤销；是否实际卡住 merge 需另查 merge Effect / policy / checks。
5. **收据 generation 漂移存在具体分类缺口。**旧收据被拒绝是正确行为，但隔离复现中被归类为 execution-failed，随后覆盖 Task block；应识别为快照过期。输入保持 accepted，未伪造 handled。
6. unmanaged 原生 Chief 专用退出证明已存在。reconcileChiefExit → priorHostProcessExited 核验 bootId、PID namespace、startTicks 和原生 Chief 边界。通用 priorScopeExited 对 unmanaged 返回 false 是安全边界，不能简单改成 PID 消失即释放任意资源。历史缺字段、独立 SDK / Docker worker 或工具子进程需要各自真实证明。

现有 Chief/process/recovery 测试42例及验证续跑测试4例通过；另做5个隔离探针。报告中大量失败 invocationHistory 为空，是后续定位重点：当前 JSON parse 前已记录响应 hash，不能把这些失败全部归因于模型 JSON typo。

实施范围与顺序

1. 先修正信息失真：执行故障、业务阻塞和已有验收分离

• Chief 调用、传输、退出、解析、协议、过期快照、业务前置条件与验收不满足，应提供可区分的原因和实际对象引用；优先复用已有错误/恢复字段，不另造通用机制。
• 执行故障归属对应 Chief Run，不应无条件覆盖当前 Task 的业务阻塞原因，更不能覆盖已经推进的新 generation / claim。
• 保留已核验的 candidate / tests / Review / merge 证据。区分 Reviewer approve、Chief Task acceptance 与真实合入，不能仅凭 approve 绕过现有合入门禁。
• 从实际接收结果/失败阶段保留必要的状态、响应 hash、证据引用与底层原因。不要把失败一律压成 did-not-complete；不把完整 transcript、私密上下文或凭据复制进状态。
• close 被拒时给出实际缺失或失效的 criteria / evidence / gate；执行器失败不能冒充验收不通过。
• 向 Chief 提供这些事实，由它判断重试、换资源、继续、咨询或等待；不因分类而自动选路。

2. 修现有反馈链路：格式、范围与过期快照

• 无效 JSON / 字段类型 / 决策范围错误走原有 correction，反馈准确字段、当前允许范围和必要上下文。
• 明确本轮 snapshot 内可裁决的 Task ID。域外决策显式拒收并反馈，不静默丢弃、不擅自扩大快照或执行其它 Task；Chief 可以修正输出或通过获准的现有入口获取更多上下文。
• Task 局部错误应明确定位；保留已经实际应用的决策和拒绝记录，不无区分报告整轮执行失败，也不重放已完成的业务动作。在现有逐 Task 处理和 correction 上最小修正，不增加通用编排层。
• generation / requirements / candidate / inbox manifest 变化要反馈为当前事实已变，供 Chief基于新快照重新判断。需要刷新时复用原有 Chief Session / snapshot / correction 入口，保留旧轮次审计。
• 禁止把旧收据直接 rebase 到新 generation，禁止丢弃后假装已读/已处理；旧输入保留真实待处理状态。foreign / revoked / changed-content 等仍保持权限与内容校验。
• Harness 已支持时优先复用结构化输出能力，并与原有 parser / correction 配合；不为统一形式放开 Chief 的通用工具权限。不做正则修补 passed 或自动推断验收结论。

3. 最后核对已有恢复能力是否可发现、可使用

• 保留并验证既有 Tester/Reviewer 续跑能力；反馈当前缺什么证据、有哪些合法能力，不规定 Agent 应选哪一个。
• 历史“必须回 Developer”等拒因保留审计，并标明历史范围/时效；不要继续作为当前硬约束注入提示，也不篡改或清空历史记录。
• 原生 Chief、宿主、SDK / Docker worker、工具子进程和 preparation 的退出证明保持分层。证据不足如实报告未知；历史记录补证走已有明确授权入口，不猜 PID namespace / generation。
• claim 退场和代次隔离复用 Reconcile proven execution exit with durable claim retirement before integration admission #2375 的统一对账，避免本条重复实现。不把 attempt.stop 的取消语义改成暂停或恢复。
• 精简 Chief 提示词：当前授权内自主推进优先、依据当前事实行动、避免无新事实的重复转交；宿主不替 Chief决定是否向个人代理/运维求助。

验收与测试

• 坏 JSON / 错字段可得到准确 correction，保留当前轮次和响应证据，不泄漏裸私密输出、不自动修改验收布尔值。
• 单 Task snapshot + 多 Task 决策有明确逐项反馈；不越界、不静默丢弃，不重放已应用动作。
• generation / batchId / 内容与权限分别变化时，错误分类准确；旧收据不确认新输入，Chief 能拿到当前事实并自主重新裁决。
• 已有 approve / tests / merge 事实不会因 Chief 执行失败被删除或改成业务失败；旧轮次失败不覆盖新 claim / generation 的业务状态。close 拒因可定位真实缺失项。
• 满足证据的 interrupted / failed 候选能沿已有入口续 Tester/Reviewer；证据不足则返回具体事实，不强制返工或转人工。
• 新旧 unmanaged 原生 Chief 与独立 SDK / Docker 的退出边界分别验证；缺失/不匹配证明不误释放。与 Reconcile proven execution exit with durable claim retirement before integration admission #2375 衔接而非建立第二套对账。
• 同样的宿主错误反馈下，Chief 可合法选择不同下一步；测试不得把“必须选择某角色/转人工”固化为验收。
• 所有真实缺口有修复前失败、修复后通过的关键回归；区分 fixture、实际 SDK/DSH 与真实现场证据，不以通过测试代替现场归因。
• 同步长期记忆、相关架构、提示词与必要的 API / OpenAPI 文档；继续遵守完整上下文预算和历史保留约束。

非目标

不重构 Control Plane / UI，不新增固定 DAG 或恢复业务调度器，不自动选择下游/升级人工，不通过重启或手改状态掩盖缺口，不扩大权限，不替代 #2365 的 PR 正式采纳或真实 App 验收，不重写已修复功能，也不把源码合入当作现场验收完成。

补充：2026-11-04 22:50 报告的已确认缺口与验收边界

目标分支仍为 delivery/ai-centric-development-service；核对基线为 d39e70bc35d3c88cf36b9726ccc025c6e946686f。Owner 同意仅按可以确认的代码缺口推进，不以现场附件为开发前置条件。

需要覆盖的回归

• 执行结果 ok=false 时，保留实际失败阶段和安全的原因/证据引用，不能只返回通用 did-not-complete；执行故障只更新所属 Run，不无条件覆盖 Task 当前业务 block、新 generation/claim 或既有 tests/approve/merge 事实。
• Chief 裁决因快照代次、候选或输入变化而失效时，继续拒绝旧动作；通过原 Session/snapshot/correction 链提供新事实和准确反馈。已经应用的动作不得重放，旧输入不得伪装成已处理。
• 区分“Chief 文本已输出”“裁决已接受”“动作已持久应用”“外部结果已确认”。中断/保存失败/重复回调时状态可查询、可恢复，不把可见文本当作路由执行成功。
• Chief closure needs explicit acceptance-criteria evidence 是正确门禁：反馈缺少的具体 criteria/evidence，不能因为 PR MERGED 就跳过逐项验收。
• 加入确定性故障注入与重启/迟到结果回归，同步长期记忆、架构和受影响 API 状态说明。是否重试、换资源、找下游或咨询仍由 Chief 决定。

暂不作为已确认根因

• 仅有 unmanaged-process 不能证明退出核验不支持；此提交已有原生 Chief 专用核验。未知退出继续保留安全屏障。
• health=overdue 是健康投影，不能据此断言定时触发缺失。先区分 occurrence 未创建、排队阻塞、执行失败和退出未确认；不在本条新增写死巡检周期或第二套补偿调度器。
• 不在缺少证据时把现场 OAuth、容器控制器丢失或 seed 输入继承认定为本条根因。