前阵子把我跑多 agent 编排的那套流程写成了两个可安装的 skill ，中英各一份。发出去之后，有人在讨论区问了我一个问题，我没答好，因为那个情况确实没覆盖。
收件器把 ack 延后到整批消息处理完才发，这样一批里只要还有一条没处理完，就不会把后面的消息冲掉。但如果某个动作已经执行完了，合并了 PR 、回了消息、改了文件，而进程在「记下它已完成」之前就死了呢。
这一批仍然是未 ack 的。可它的效果可能已经落地。
我看到这条的第一反应是「这算不算问题」。因为脚本那层我已经做了原子落盘，临时文件 fsync 完再 rename ，觉得风吹不动。
想了一会儿才承认：落盘保证的是不丢，他问的是不重复，这两件事在崩溃窗口里根本不是一回事。我原来给了什么，没给什么 脚本做的是 at-least-once 投递。
批次原子落盘，按 message ID 去重，只自动 ack 全是心跳的批次，真批次到达时结束进程来唤醒 coordinator ，因为磁盘上的文件没办法启动一个 turn 。它管的是不丢、不重复唤醒、不丢证据。
效果只发生一次这件事，它不管。而旧文档的写法让人以为它管。
问题不在设计取舍，在于没写清楚，也没覆盖到。改了三处 一，台账里 processing 这条要写在它所描述的动作之前，并写明是什么动作、第几次 attempt 。
原来只写了「维护 received → processing → handled 台账」，没说什么时候写。顺序在这里是全部要害：事后补写的台账，分不清「动作已经生效、记录丢了」和「动作根本没跑」。
二，恢复时，一条卡在 processing 的记录意味着先查真实状态，再决定要不要重放。合并就去 pr view ，回复就看回执，文件改动就读文件本身。
据证据判断，不据台账判断。三，效果无法从证据确立的，交给人类，不盲目重跑。
另外补了一个评测场景，让这条规则有测试兜着。光写在文档里，下次还会漏。
为什么这比「加个重试」难 因为重放安全的前提是动作本身幂等，而不同动作的重做代价完全不一样。 merge 重放的话，PR 已经合了，第二次会直接报错，基本无害。
send 重放就是真的发两遍。文件改动取决于改了什么。
这三种的代价对比，我是从接口语义上推出来的，不是真在这三种上踩过。真踩过的是另一件事：有个内部状态文件被并发写坏过一次，我花了一晚上才定位到是有一处没走原子写。
那次之后我才把 fsync 加 rename 变成不用讨论的默认。顺便说三条其他判据 这套东西一共写了十几条，基本都是真出过事之后补的。
挑三条可能对别人有用的。把 state: ready 当成「 agent 已经开始干」的证据，是最容易犯的一个。
它只说明字节写进去了。得读终端标题、跟那个 agent 的 idle banner 对一下，才叫证明 turn 开始了。
而且如果没开始，修法是一个裸的 Enter ，不是把整段 prompt 重发一遍。 worker 问「顺手把那个没人用的组件也删了吧」，我一开始直接采纳了。
那是 scope 变更，本该问我。 worker 的建议是输入，不是答案。
还有一个四万行的 diff ，其实是编辑器把宽行文件重排到 80 列。差点把真实工作一起 revert 掉。
现在的规则是先留证，再判断。一个我到现在最没底的问题 验收我分了四级：implemented 、integrated 、merged 、tracker-closed 。
判据是「集成 PR 上 CI 全绿，加上票图里的票关了或明确标成下一轮」。但有两种情况处理不了。
一张票跨两个 PR ，第一个合了、第二个还 open 。是等它，还是把票拆成两张。
spike 类票，产出本来就不会合并。它在票图里永远是「未完成」，于是 run 永远不算完，只能手动标一下，那判据就不成立了。
这两种之外，我在 issue #20 里还列了两个我觉得会出错的：tracker 靠 merge 关键字自动关票时，后两级会塌成一级；合并之后又 revert 时，级别该不该往回退。跑过长程 implement-spec 的话，欢迎直接说哪里错了。
项目 /ai-market-guide/ 中英两份、语义一致，91 个测试（ 90 通过、1 跳过），每种语言 30 个评测场景，其中就有上面那个洞对应的场景。它是 Orca 专用的，驱动 orca orchestration 的 verb ，README 里把这条边界写清楚了，没有假装通用。
判断规则可以迁移，命令不行。我自己主要拿它跑自己那几个仓库，没有公开的跑量数据。
所以上面这些是实践里出来的判据，不是统计意义上的验证。