congde/codexfde/state-handoff-review

状态移交审查

读取任务 Spec、状态与转移表、实际执行入口、候选、报告、审核记录及相关业务数据。区分研发交付状态、业务单据状态与工具调用状态，不把一种完成代替另一种。

核对移交

• 每条边有什么条件，实际动作在哪里执行，输出如何验证。记录轨迹不等于校验允许边，进入 develop 不等于已经修改代码。
• 检查报告是否完整有效并属于审核候选。零阻断数或空结果不能单独支持审核。
• 等待、批准和打回由谁决定，身份如何取得，决定批准哪份对象。非空姓名字段不是身份认证。候选或必要输入改变后，旧批准是否失效。
• 区分轮数、执行次数和检查次数。上限应约束真实动作，停止时保留最后已验证结果与待办。

核对恢复与副作用

追踪动作提交和状态保存的时点，检查二者间退出会留下什么。分别审查读取、执行、检查、审核和保存异常；保存失败不能声称已有可靠持久化记录。

比较业务单据、库存与流水。事务一致性和重试幂等分别验证；恢复成功不能倒推首次动作原子化。同一幂等键必须对应同一业务身份和约定内容，不能借用其他事件的成功。

从阶段快照核对恢复

有运行快照时，先核对实验模式和同一次运行身份，再比较动作前、故障后、重试后。不要把不同数据库中的正常与故障结果拼成一次时间线。采购至少对账目标单据、数量和归属于它的事件；总库存正确不代表目标事件存在。返回结论时引用阶段和原始文件，并说明首次失败与后续恢复各证明什么。

结论与复用

按“已验证、与约定冲突、证据缺失”给出结论，每项关联实际文件或原始报告。不要自动批准交付、签署人的决定或删除失败证据。

声称工作台跨事项闭环时，另查来源经验、适用边界、有效状态、后续召回与采用理由、明确流程版本、本次 Harness 和具名审核。复用失败应推动修订或停用；状态保存与资产登记不足以证明采用。

用反例观察真实响应，保存漏判与修订，迁移时重新核对业务对象与不可重复动作。