Files
Genarrative/docs/technical
lhk229 deae1e08ce
Project CI / Repository checks (pull_request) Successful in 1m5s
Project CI / Frontend tests (pull_request) Successful in 2m54s
Project CI / Backend tests (pull_request) Successful in 3m59s
Project CI / Native shell tests (pull_request) Failing after 11m27s
立项策划:裁决 M1C-1 三条开工前置,前向兼容粒度另拆 M1C-0b
对 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>
2026-08-15 05:57:12 +00:00
..