deae1e08ce
对 2026-08-14「M1C-0 合入复核」留下的三条前置逐条读实代码后定稿: ① barrier:补,且必须是独立的第六个计数 user_revision_pending_count。 不能并进 repair_required_count——它带 repair_of_delegation_id.is_none() 只算原始委派,而用户第 2 次修订的父节点自身就是 repair 节点,并进去会让 第 2 次及以后的修订全部不阻塞。判据形状照 user_input_required_count。 另有四处逐字段读 barrier 的调用点不走 is_clear(),加字段不会自动传播。 ② 正向一致性:复用 EvidenceReady 的三条客观证据约束,并把该处 if/else-if 链改成穷尽 match;但不得更严——该函数在每次读取时都跑,过严会把写入方的 一个 bug 变成 delivery 永久读不出来。同时订正:这不是既有漏洞,唯一派生点 产不出该变体,约束的是 M1C-1 引入的第二个写入方。 ③ 前向兼容粒度:订正 08-14 自己写的「二选一」——「单条跳过并告警」不安全, barrier 是计数,跳过一条损坏的 Dispatched 记录会让 Supervisor 在仍有未完成 委派时收束,把可用性故障换成正确性故障。改走第三条路(损坏仍整体锁死, 前向不兼容解析进显式 Unknown 并最大化阻塞),并另开 M1C-0b 承接——该改动 触及 master 已发布机制的所有读路径,不得塞进 M1C-1 的 diff。 另记两条比 08-14 更糟的事实:锁死半径是整个项目目录而非单个 run; .json.previous 备份只在 primary NotFound 时回退,损坏但存在的 primary 不回退。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>