接手核对与漂移判定

接手核对与漂移判定

Handover 是上一个 agent 在离开时对世界的判断。判断会过期，代码不会。接手的第一动作不是执行下一步，而是确认下一步还成立。

1. 四种 claim 状态

状态	含义	处理
verified	有当前证据支持	可直接依赖
stale	曾经成立，现在不成立	以现实为准，更新 handover
unknown	没有足够证据	标 unknown；影响下一步才去查
contradicted	文档与代码/测试直接冲突	先判断是 bug 还是有意中间态

「已完成」只有在能指出文件、commit、测试或产物时才算 verified。指不出证据的完成，一律降级为 unknown。

2. 权威顺序

1. 运行中的代码、测试、产物
2. git 历史与工作区状态
3. 交接文档
4. 计划、路线图、Blueprint
5. 会话记忆与 Wiki 摘要

顺序不是「谁更新」，是「谁更难被误写」。代码可能写错，但它至少是实际运行的东西；handover 可能把「打算做」写成「已经做」。

例外：交接里明确标注的有意中间态、临时绕过、已知破例，按 decisions / do_not_redo 处理。不要把它当 bug 修掉。

3. 最小核对清单

先做这五项，再决定是否继续读：

• 当前目录是预期项目根。
• 当前 branch 与 handover 的 branch 一致，或差异已被解释。
• 当前 head 与 handover 的 head 一致；不一致时看中间提交。
• 工作区脏状态与 handover 的 dirty 一致；不一致时先看 diff。
• next action 涉及的文件、命令、依赖、权限仍然存在。

只有影响下一步的 claim 才需要深查。与下一步无关的过期信息，记一笔即可。

4. 常见漂移

4.1 head 前进，但 handover 没更新

上一个 agent 在写完 handover 后又提交了东西。先看 git log <handover-head>..HEAD --oneline；如果新提交就是下一步的一部分，handover 的 next action 可能已经完成。

4.2 分支不同

handover 写的是另一个分支的进度。不要直接在当前分支执行；先确认用户要接哪条线。多工作流时，一份 handover 对应一个 branch / workstream。

4.3 工作区有未提交改动

handover 说「干净」，但 git status 有改动。先看 diff：可能是上一个 agent 的未收尾工作，也可能是用户手动改的。不要 stash 或 checkout 掉别人的工作。

4.4 计划优先级变了

handover 的 next action 仍可执行，但 roadmap 已经把当前 milestone 换了。默认先看计划：如果旧 next action 不再服务于当前 milestone，降级为候选，不直接开工。

4.5 测试结果不可复现

handover 说「全绿」，当前基线是红的。先定位红的来源：是 handover 之后的新改动，还是环境差异。基线不清零就开新工作，会把旧故障算到新改动头上。

5. 非代码项目

没有 git、测试、构建时，用项目自己的证据替换：

项目类型	可接受的验证
写作	读回最近一章、对照大纲与设定、检查字数与断点
游戏设计	跑当前构建、对照关卡/系统表、检查资源清单
文档站	构建、链接检查、页面抽样
研究	来源清单、引用回查、结论与原始材料对照

仍然遵守同一条原则：先确认「下一步还成立」，再执行。

6. 预算与停止

• L0：≤10 次文件读取，≤2 分钟；能说清下一步即停。
• L1：≤25 次读取；完成核对表即停。
• L2：按用户要求深入，但仍要先给简报，不边读边改。

读得更多不等于接得更好。目标是 time-to-first-verification，不是阅读覆盖率。

7. 简报里必须出现的三件事

1. 哪些 claim 被验证，哪些过期。
2. 下一步是什么，为什么是它。
3. 有没有需要用户拍板的冲突；最多一个。