OpenClaw Proof Chain · Guarded Admit
这一步真正做成的不是“终于敢往真实主池写回”，而是更重要的前置证明：同一条
policy_ready thread 已经能把 strict-ready preview 写进一个
沙箱 TODO-Inbox，由此验证 managed block 替换机制是真的能执行。
更关键的是，proof 跑出来以后暴露了真实约束。当前写法不是“写不进去”，而是会 直接覆盖现有 managed block。按 Peter Drucker 的标准，这说明下一步不是盲目放开写回， 而是先定义 merge / admit 语义，确保旧任务不被新 preview 粗暴冲掉。
Proof Chain
这个顺序是故意的：先 benchmark contract，再 clarify receipt，再 guarded writeback proof。
按 David Allen 的逻辑，先分清 capture 与 action；按 Charity Majors 的逻辑，下一步必须留下 receipt； 于是 writeback proof 才轮到现在，而不是更早。
这个顺序避免了一个常见误判：把“能 preview”误当成“已经能安全 admit”。沙箱 proof 证明两者之间还隔着一层 merge 风险。
Sandbox Run
主线程没有碰真实 TODO-Inbox，而是复制当前文件、改写 preview 的 target，再用受控 flag 执行 todo write。
对沙箱 data root 执行 --kind todo --json，结果是
changed = true，说明 preview 确实会替换 managed block，而不是空跑。
在加上 --write --allow-sandbox-todo-write 之后，结果变成
wrote = true。这说明 todo managed block 的实际写入机制已被证明可执行。
被推进的是同一条 single-thread receipt：minute:obcnmyi9p32245dd873ld4v6，
也是当前全局 merged run 里唯一的 policy_ready thread。
这张图最重要的不是“2 条 strict-ready”，而是最后一个数：当前写法会把已有 4 条 managed tasks 直接替换成 2 条新任务。
这个 swimlane 回答了“proof 到底写到了哪里”：不是写进真实 vault，而是先走 preview，再进 sandbox target。
风险不在 source thread，也不在 preview 文本，而是在“替换 managed block 的策略”本身。这是这轮 proof 最重要的新知识。
Critical Finding
沙箱 diff 让问题具体化了：当前 todo writeback 一旦放开，会覆盖当前 managed block，而不是把新 strict-ready 任务安全并入。
diff 很直白：写进去不是增量补入，而是整块替换。这种写法在生产环境里风险过高，所以当前结论必须是“先定义 merge”。
这张 decision tree 解释了为什么 proof 不是终点。它只是把“下一步到底该做什么”从模糊猜测收成了 merge-aware admit 设计。
现在我们知道自己所处的位置了：机制已经能跑，但 admit 语义还不安全。这比之前“感觉还没打通”要清楚得多。
当前真正的状态应该写成这样：receipt 和 sandbox write 已经证明，real admit 仍 blocked by merge，而不是 blocked by no mechanism。
Best Minds
这一步看似保守，其实是最有效的推进，因为它把真正的系统约束显影出来了。
GTD 里最重要的分界不是“有没有列表”，而是有没有先把输入收进可信系统，再判断它是不是行动。这个 proof 继续维护这个边界。
最好的 seam 不是最完整的，而是最能显影风险的。沙箱副本就是这次的 seam：它让我们看到 write path 能跑，同时不会污染真实文件。
如果没有 dry-run 和 before/after diff，这次 write 看起来像“终于能写了”。真正的收获恰恰是 diff 告诉我们当前策略会 clobber 旧 block。
真正需要设计的不是“如何替换文本”，而是 clarify item 与现有 managed tasks 应该如何并存、更新、去重、携带 evidence。
在 proof 之前，容易把问题理解成“还没写回路径”。在 proof 之后，真实约束变成了“如何 merge 才不会覆盖旧任务”。这才是该优先解决的事。
Next Step
现在真正正确的下一刀已经被显影出来了：不是直接生产 admit，而是先定义 merge-aware writeback contract。
路径已经变得非常具体：先定 merge rule，再做真实 admit；等这个完成后，再回到 DeerFlow 同题双跑。