10.采纳交接：记录、认领、撤销和恢复

1.为什么需要一份受控采纳记录

负责人在dots里真实采纳了一项需求，Codex需要知道这条决定准确对应谁批准的配置、哪个Issue、哪个时间和哪次执行。

Issue正文里的“已采纳”只表达评审事实，无法单独承担这次实施关联。HiveFlow因此使用固定私有位置的一份JSON记录，让生产方和消费方围绕同一决定交接。

本书称它为单槽：固定位置一次承载一个事项。它不等于可任意追加命令的队列，也不允许任务结束后自动清空并循环覆盖历史。

生产方在负责人本人主对话核验真实决定、唯一事项、原决定时间和有效配置，准备记录，并通过真实文件工具写入和独立读回。

消费方从本人批准的原生配置取得预期范围，再读取固定记录，与真实GitHub Issue和已有交付核对。只有待认领状态且全部条件满足，才用当前实际运行身份认领。

认领写入成功还不够，需要独立读回完整内容，确认记录中的运行身份确实属于本次运行。确认之前不开始开发、测试、提交或部署。

首次初始化的合法空闲记录只含固定版本、空闲状态、执行关闭和初始修订号。它不需要伪造Issue、负责人决定、运行身份或批准配置。

读到合法空闲时，只报告没有可消费事项，不认领、不运行测试，也不向外部写入。不存在可撤销事项时，不生成一条虚假的取消记录。

缺文件和无权限都可能表现为读取失败或找不到。不能因此自行创建分支、补建文件或把已有未知记录清空。初始化是已经明确获准的单独动作。

来源引用是可在私有记录回查的不透明标识，记录中不保存私人聊天原文、群身份或凭据。JSON字段完整，也不证明它来自可信本人。

文件更新携带刚读到的旧blob SHA，也就是Git文件内容对象的版本标识。服务端按这个旧版本条件决定更新能否成功；内容已被别人改变时，原提案不能无条件覆盖。

两个消费者即使读到相同旧版本，也只有实际成功写入并读回自己认领的那一个，才可以首次继续。只比较两个本地字符串，不等于服务端实施了这一条件。

这提供单文件更新的保护，不是业务操作锁，也不是多步骤事务。更新单项评审字段和写采纳记录是两个动作，第一步成功、第二步失败时，应明确报告“已采纳，尚未入选”。

这些状态属于采纳交接记录，不是第6章的Issue八态。PR待审模式的completed只表示该模式完成，不能据此宣布已经部署。

认领前撤销，可以把待认领记录转为取消；认领后撤销，保留原认领并写入取消请求，不通过清空身份释放占用。

执行者在每次新的修改或外部操作前检查取消与配置状态。已发出的调用可能正在执行，取消请求与调用返回存在先后交错，因此只能在安全边界阻断后续动作，不能承诺撤回在途部署或消息。

暂停原生任务、请求取消记录和实际运行已停止也是三个事实。每一项都要根据真实结果报告，不因其中一项成功就声称另外两项已经完成。

写入超时后，先读取原固定位置并核验原调用终态。内容与完整提案一致，才能确认该次写入；一次读到旧内容，也不能证明稍后永远不会写入成功。

无法确定时停止，不发第二份写入，不换决定或运行标识，也不按等待时间释放占用。已确认认领但业务结果未知时，在原权限内补记未知；连记录也无法读写时，在原任务保留事实并报告。

blocked、unknown和已结束记录不自动重领或重置。恢复要先人工核实原运行和实际发生的变化，再给明确处理指令。

当前方案采用负责人接受的dots受控流程背书：dots核验真实本人决定并生产记录，Codex信任该生产过程，再核对配置、事项和文件更新事实。

同一GitHub账号下的本人、dots或其他代理，仅靠Git作者名字无法技术区分。因此不能把文件存在、签名显示或JSON中自称身份写成独立认证原聊天的证明。

实际文件权限、条件更新、原生运行身份、撤销与恢复还需要对应现场证据。离线辅助只输出纯数据提案和检查结果，不访问平台，也不授予实施许可。