diff --git a/docs/project-memory/shared-memory/decision-log.md b/docs/project-memory/shared-memory/decision-log.md
index f2e3133d0..8791b80a8 100644
--- a/docs/project-memory/shared-memory/decision-log.md
+++ b/docs/project-memory/shared-memory/decision-log.md
@@ -1,5 +1,17 @@
 # 决策记录
 
+## 2026-08-15 M1C-1 开工前三条裁决：barrier 独立计数、正向校验的上限、前向兼容粒度另拆 `M1C-0b`
+
+对本文件 2026-08-14「`M1C-0` 合入复核」留下的三条前置逐条裁决，全部读实代码后定稿。**其中第三条订正了 08-14 自己的表述**：原文写的「二选一：给枚举加单条容错，或接受回滚锁死」是伪二选一——「单条跳过并告警」这个选项对 delivery 不安全，已作废。
+
+- **裁决一：补 barrier，且必须是独立的第六个计数 `user_revision_pending_count`。** 不补的后果是 `M1C-1` 写入方一落地，Supervisor 就能在用户修订尚未派出时收束用户任务（收束门 `static_delegate_completion_blocker_at_locked`）。不复用现有两个计数的理由是硬的：`repair_required_count` 带 `repair_of_delegation_id.is_none()`，只算原始委派——因 depth≤1，返工的返工本就不该阻塞；而**用户第 2 次修订的父节点自身就是 repair 节点**，并进去会让第 2 次及以后的修订全部不阻塞，恰好在最需要处失效。`user_input_required_count` 的语义是「等用户回答」，与「用户已发话、等 Supervisor 派发」不同，`detail()` 文案会说反。判据形状照 `user_input_required_count`（`ClaimedByParent` + 该 status + 无活跃 child，**不带** `repair_of.is_none()`）——它正是仓库里「轮次无上限」概念的既有先例。**连带**：除 `is_clear()` 与 `detail()` 外，另有四处调用点逐字段读 barrier 而不走 `is_clear()`（`autonomous_policy.rs` 两处、`runtime_tools/delivery.rs` 两处），加字段不会自动传播，每处单独裁决。这是 `M1C-0` 那个失败模式的同构版本，载体从 enum 变体换成 struct 字段，编译器同样沉默。
+- **裁决二：正向一致性锁死在「只能从 `EvidenceReady` 改写而来」，不得更严。** 复用 `EvidenceReady` 的三条客观证据约束（终态 `completed`、无缺失产物、`verification_required` 时 `verified_revision` 存在）；产物覆盖校验与「不得携带 `user_input_questions`」已对所有状态生效，不需改。**重点是实现形状**：把 `validate_static_delegate_structured_result` 里按 `contract_status` 的 if/else-if 链改成穷尽 `match`、不留 `_`——同一失败形状在本仓库已出现两次，靠纪律没拦住。**反向风险**：该函数不是入口过滤器，`read_static_delegate_delivery_at` → `validate_static_delegate_delivery_record` 让它每次读取都跑；过严等于把写入方的一个 bug 变成「该 delivery 永久读不出来」，直接触发裁决三的锁死，故不得再加 `EvidenceReady` 自己都没有的条款（例如要求 `error` 为 `None`）。**另订正 08-14 前置二可能引起的误读**：它不是既有漏洞——专业 Agent 自证「用户要求修订」今天不可达，唯一派生点 `build_static_delegate_structured_result_at` 只能产出三个旧变体，claim 回执的 `structuredResult` 从 delivery 拷贝，均为 Runtime 侧；本条约束的是 `M1C-1` 引入的**第二个写入方**（审批命令）。
+- **裁决三：「单条跳过并告警」作废，走第三条路，并另开 `M1C-0b`。** 单条跳过不安全的原因很具体：`list_static_delegate_deliveries_at` 喂的是 barrier 的**计数**，跳过一条损坏的 `Dispatched` 记录会让 `waiting_count` 少 1、barrier 变 clear，Supervisor 在仍有未完成委派时收束——把可用性故障换成了正确性故障，比锁死更糟。对照组说明危险面很精确：谱系重放不受影响，缺节点走「上游缺失」出口返回 `(u32::MAX, u32::MAX)` 哨兵，本就 fail closed。**第三条路是把「解析失败」拆两类**：损坏（截断/非 UTF-8/超限）状态未知，维持整体锁死不动；前向不兼容（结构良好、只有一个 enum 值不认识）是已知的未知，解析进显式 `Unknown` 但最大化阻塞（进 barrier、返工门无条件拒、谱系按最保守的「其它」分类，只会拒不会放）。不违反 `M1C-0` 条里「不得静默降级为 `NeedsRepair`」——那条禁的是把记录当正常记录继续走流程，`Unknown` 是显式隔离。半径从「整个项目静态委派面不可用（做游戏链路一起挂）」降到「只冻结携带该状态的那条 lineage」。
+- **两条比 08-14 记录更糟的事实。** 锁死半径是**整个项目目录**——`list_static_delegate_deliveries_at(root)` 先读全目录再按 parent run 过滤，任何一条无关 run 的损坏记录毒化所有 run 的 barrier；`.json.previous` 备份救不了——`read_agent_runtime_json_sidecar_with_max_bytes` 只在 primary **NotFound** 时才回退，损坏但存在的 primary 不回退。
+- **实现坑。** `#[serde(other)]` 用不了：它只允许在 internally/adjacently tagged 枚举上，而 `StaticDelegateContractStatus` 是序列化成纯字符串的 unit-variant 枚举；需自定义 `Deserialize`，且 `Serialize` 必须原样回写原始字符串，否则旧版本任何一次读-改-写都会把未知值抹掉。
+- **拆包与门禁。** ①② 进 `M1C-1`（它们约束的正是 `M1C-1` 新增的写入方）；③ 拆 `M1C-0b`，与 `M1C-0` 同形状——无写入方、纯读路径、对既有记录零行为变化可证；塞进审批闭环的 diff 就是重犯第 23.8 节「拆包纪律」自己写的错。`M1C-1` 门禁因此为二选一：`M1C-0b` 先落，或直接上线并在 release note 明写「用过策划审批后回滚旧版本会让该项目静态委派面不可用」；**建议前者**，多机/版本不一致不需要用户主动回滚就会发生。`WP1` 的 depth≤1 结论仍未被推翻。
+- 关联文档：`docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md` 第 23.7 节「落地约束」裁决一/二/三与「回归必须覆盖」、第 23.8 节 `M1C-0b` / `M1C-1` 行与「拆包纪律」。
+
 ## 2026-08-14 M1C-0 合入复核：三条 M1C-1 前置、一条文档订正、一条已排除假设
 
 合入 `M1C-0`（见本文件同日条）后对该包做整组复核。**结论：包本身可合，「今天行为零变化」成立且可证**；但新变体在 `M1C-1` 写入之日会同时点亮三个默认值，而这三个默认值都不是裁决出来的，是「给用 `==` 比较（而非穷尽 `match`）的 durable enum 加变体，编译器不报，新变体静默落到作者没想过的那一侧」的结果——与本文件「修复 M1A-2 引入的回归」条同源，是同一失败模式的第二次出现。（复核完成后 `M1B-2` 已合入；其对 `delegation.rs` 的改动是 rustfmt 换行、无语义变化，本条结论不受影响。）
diff --git a/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md b/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md
index 2b86c5eb8..dffe33e29 100644
--- a/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md	
+++ b/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md	
@@ -1988,9 +1988,12 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 
 - 拆包（2026-08-13 按第 23.8 节更正）：**变体与分类分支在 `M1C-0`**——该 PR 无写入方、是惰性路径、行为零变化，便于把「做游戏链路返工额度未被误放宽」这条关键回归单独证明；**写入方与 receipt 在 `M1C-1` 同进同退**——只置 status 不写 receipt（或反之）会让链路计数与审批事实脱节。这样拆全程不产生半状态：`UserRevisionRequested` 直到 `M1C-1` 才可能被写出。
 - `StaticDelegateContractStatus` 是 durable schema 的一部分。新增变体属**前向兼容**问题（旧代码读不了新记录），非后向兼容问题：只有做方案链路会写它，做游戏链路既有记录不受影响。反序列化必须 fail closed，**不得静默降级为 `NeedsRepair`**——那会让用户修订被误计成返工，正是本裁决要消除的行为。
-- **（2026-08-14 补，`M1C-0` 合入复核）前向兼容失败的粒度是整个子系统，不是单条记录。** `list_static_delegate_deliveries_at` 对每条 sidecar 用 `?` 上抛，一条解析失败即整个目录枚举失败，barrier 计算、lineage 重放、返工校验与 run status 投影同时不可用。因此 `M1C-1` 写出该状态后，旧版本 App（回滚、或多机版本不一致）打开同一项目会**整个静态委派面不可用**。注意 bump `STATIC_DELEGATE_DELIVERY_SCHEMA_VERSION` 救不了这一条：版本号校验排在 serde parse 之后，parse 已先失败——要处置只能改枚举粒度（单条损坏跳过并告警）。**`M1C-1` 上线前必须二选一并记录裁决：给枚举加单条容错，或明确接受回滚锁死项目。**
+- **（2026-08-14 补，`M1C-0` 合入复核）前向兼容失败的粒度是整个子系统，不是单条记录。** `list_static_delegate_deliveries_at` 对每条 sidecar 用 `?` 上抛，一条解析失败即整个目录枚举失败，barrier 计算、lineage 重放、返工校验与 run status 投影同时不可用。因此 `M1C-1` 写出该状态后，旧版本 App（回滚、或多机版本不一致）打开同一项目会**整个静态委派面不可用**。注意 bump `STATIC_DELEGATE_DELIVERY_SCHEMA_VERSION` 救不了这一条：版本号校验排在 serde parse 之后，parse 已先失败。**（2026-08-15 订正）此处原写「要处置只能改枚举粒度（单条损坏跳过并告警）」并要求 `M1C-1` 上线前二选一——两者都不成立：单条跳过对 delivery 不安全，裁决见下方「裁决三」。**
+- **（2026-08-15 裁决一，落在 `M1C-1`）新变体必须进 barrier，且必须是独立的第六个计数 `user_revision_pending_count`。** 不补的后果：`repair_required_count` 与 `user_input_required_count` 都用 `==` 比具体变体，`UserRevisionRequested` 两边都不落，`is_clear()` 因此可能为真——写入方一落地就意味着 **Supervisor 可以在用户修订尚未派出时收束用户任务**（收束门是 `project_gates.rs` 的 `static_delegate_completion_blocker_at_locked`）。不复用现有两个计数的理由是硬的：`repair_required_count` 带 `repair_of_delegation_id.is_none()`，只算原始委派——因 depth≤1，返工的返工本就不该阻塞；而**用户第 2 次修订的父节点自身就是 repair 节点**，并进去会让第 2 次及以后的修订全部不阻塞，恰好在最需要处失效。`user_input_required_count` 的语义是「等用户回答」，与「用户已发话、等 Supervisor 派发」不同，且 `detail()` 文案会说反。判据形状照 `user_input_required_count`——`ClaimedByParent` + 该 status + 无活跃 child（`repair_of` 指向自身且状态属 `Dispatched|Ready|ClaimedByParent`），**不带** `repair_of.is_none()`；该字段正是仓库里「轮次无上限」概念的既有先例。**连带必须逐处裁决**：除 `is_clear()` 与 `detail()` 外，另有四处调用点逐字段读而不走 `is_clear()`（`autonomous_policy.rs` 两处、`runtime_tools/delivery.rs` 两处），加字段不会自动传播过去。这是 `M1C-0` 那个失败模式的同构版本，载体从 enum 变体换成 struct 字段，编译器同样沉默。
+- **（2026-08-15 裁决二，落在 `M1C-1`）正向一致性锁死在「只能从 `EvidenceReady` 改写而来」，不得更严。** `UserRevisionRequested` 复用 `EvidenceReady` 的三条客观证据约束：终态为 `completed`、`missing_expected_artifacts` 为空、`verification_required` 时 `verified_revision` 必须存在。依据是本节定的唯一转移——审批命令把一条既有 delivery 从 `EvidenceReady` 改写过来，且第 13.0 节审批前置门保证取证已过才会出现审批卡。产物覆盖校验本就对所有状态生效，「不得携带 `user_input_questions`」已被现有 else 分支挡住，均不需改。**实现形状是本条重点：把 `validate_static_delegate_structured_result` 里按 `contract_status` 分支的 if/else-if 链改成穷尽 `match`、不留 `_` 通配**——同一失败形状在本仓库已出现两次，靠纪律没拦住，穷尽 `match` 把它变成编译错误。**反向风险必须一并记住**：该函数不是入口过滤器，`read_static_delegate_delivery_at` → `validate_static_delegate_delivery_record` 让它**每次读取都跑**；约束定得比写入方实际产出更严，等于把写入方的一个 bug 变成「该 delivery 永久读不出来」，直接触发裁决三的锁死。故不得再加 `EvidenceReady` 自己都没有的条款（例如要求 `error` 为 `None`）。**另订正一处可能的误读**：本条不是既有漏洞——专业 Agent 自证「用户要求修订」今天不可达，唯一派生点 `build_static_delegate_structured_result_at` 只能产出三个旧变体，claim 回执的 `structuredResult` 从 delivery 拷贝，均为 Runtime 侧；本条约束的是 `M1C-1` 引入的**第二个写入方**。
+- **（2026-08-15 裁决三，另开 `M1C-0b`）「单条跳过并告警」作废，走第三条路。** 单条跳过不安全的原因很具体：`list_static_delegate_deliveries_at` 喂的是 barrier 的**计数**，跳过一条损坏的 `Dispatched` 记录会让 `waiting_count` 少 1、barrier 变 clear，Supervisor 在仍有未完成委派时收束——把可用性故障换成了正确性故障，比锁死更糟。对照可见危险面很精确：谱系重放不受影响，缺节点走「上游缺失」出口返回 `(u32::MAX, u32::MAX)` 哨兵，本就 fail closed。**第三条路是把「解析失败」拆成两类**：损坏（截断、非 UTF-8、超限）状态未知，**维持整体锁死**，今天的行为正确不动；前向不兼容（结构良好、只有一个 enum 值不认识）是**已知的未知**，让枚举有显式 `Unknown` 承接，解析成功但最大化阻塞——进 barrier、返工门无条件拒、谱系按最保守的「其它」分类（只会拒不会放）。这不违反上面「不得静默降级为 `NeedsRepair`」那条：它禁的是把记录当正常记录继续走流程，`Unknown` 是显式隔离。效果差别：旧版本打开新项目，今天是整个静态委派面不可用（做游戏链路一起挂），改后只冻结携带该状态的那条 lineage。**两条比 2026-08-14 原文更糟的事实**：锁死半径是**整个项目目录**——`list_static_delegate_deliveries_at(root)` 先读全目录再按 parent run 过滤，任何一条无关 run 的损坏记录毒化所有 run 的 barrier；`.json.previous` 备份救不了——sidecar 读取只在 primary **NotFound** 时才回退，损坏但存在的 primary 不回退。**实现坑**：`#[serde(other)]` 用不了（只允许在 internally/adjacently tagged 枚举上，而这是序列化成纯字符串的 unit-variant 枚举），需自定义 `Deserialize`，且 `Serialize` 必须原样回写原始字符串，否则旧版本任何一次读-改-写都会把未知值抹掉。**该改动触及 master 已发布机制的所有读路径，正是当初把 `M1C-0` 单独拆出的风险类别，不得塞进 `M1C-1` 的 diff**——另开 `M1C-0b`（见第 23.8 节）。`M1C-1` 的门禁因此为二选一：`M1C-0b` 先落，或 `M1C-1` 直接上线并在 release note 明写「用过策划审批后回滚旧版本会让该项目静态委派面不可用」；**建议前者**，因为多机/版本不一致不需要用户主动回滚就会发生。
 - 本裁决改的是 master 已发布的静态委派机制，须在 `decision-log.md` 补 dated 记录，写明 `WP1` 的 depth≤1 结论未被推翻。
-- 回归必须覆盖：用户修订跳不增 `depth` 也不重置 `round`；连续多次修订均可通过；做游戏链路的返工仍在 `depth=1` 被拒；无该变体的历史记录分类行为不变；链长边界仍 fail closed；**用户修订父节点下「同一静态委派最多允许一轮返工」的兄弟检查仍然生效（含并发）**——depth 门对用户修订不再适用后，兄弟检查是该路径上唯一剩下的扇出约束。
+- 回归必须覆盖：用户修订跳不增 `depth` 也不重置 `round`；连续多次修订均可通过；做游戏链路的返工仍在 `depth=1` 被拒；无该变体的历史记录分类行为不变；链长边界仍 fail closed；**用户修订父节点下「同一静态委派最多允许一轮返工」的兄弟检查仍然生效（含并发）**——depth 门对用户修订不再适用后，兄弟检查是该路径上唯一剩下的扇出约束。**（2026-08-15 补）`M1C-1` 另须覆盖**：`UserRevisionRequested` 且无活跃 child 时 barrier 不 clear 且收束门拒绝，派出续跑后 barrier 恢复 clear；**第 2 次及以后的修订同样阻塞**（父节点自身是 repair 节点，专钉裁决一里被否掉的 `repair_of.is_none()` 写法）；穷尽 `match` 下终态为 `failed` 或缺产物的 `UserRevisionRequested` 落盘被拒。**`M1C-0b` 另须覆盖**：未知 durable status 解析为 `Unknown` 后 barrier 不 clear、返工门拒、原始字符串经读-改-写后不变；损坏记录（截断/非 UTF-8/超限）仍整体锁死；既有三变体记录的行为逐条不变。
 
 ### 23.8 M1 的 PR 结构与合入门禁（2026-08-13）
 
@@ -2005,7 +2008,8 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 | `M1B-1` | `.agent/planning/` 存储层、strict schema、typed 指纹、版本链；含 `.agent/planning/**` 只挡写判据 | `M1A-2` | **2026-08-14 已通过门禁并合入本分支**：GDD / index / session strict DTO、canonical bytes、duplicate-key 与后缀门、typed 指纹、连续版本链、session 原子写入/恢复、Runtime writer identity 及 `game/fast_gdd.md` / `.agent/planning/**` 通用写入拒绝；第 9.1 节 golden vector（3857 bytes）与 11 个定向 storage 测试通过，writer 目标 schema 重验、index 权威对账与锁内 index recovery（缺失/损坏/陈旧从严格 GDD 链重建）、恢复故障矩阵、`cargo check --offline`、`npm run check:encoding` 与 `git diff --check` 均通过。合入时无 approval receipt schema，多版本 `statusCache` 只是无 receipt 的预审批投影；M1C-1 接入 receipt 后必须重建 `approved/revise/reject/superseded` 状态。create-only 与等前缀不可变 |
 | `M1B-2` | `plan.submit_gdd` 原生工具、exact planning Provider 请求绑定与 GDD 提交点 | `M1B-1` | **工作包已通过本包门禁并以 `27c3eb847` 合入本分支**。实现合同：四类 request kind 全部写 v3 lifecycle、required binding 与同一 dedicated structured-injection user message；只有 `tool-plan` 可生成 sole-submit v4 batch；提交点后只修复 index/Markdown/session successor、终止策划子 run，并保留 generic v5 standalone pending + v4 batch anchors，不创建 `gdd-approval` planning pending/审批等待。定向 Rust、`cargo check --offline`、格式、编码与 diff 门禁均已通过；完整审批链路与产品可交付仍留给后续工作包 |
 | `M1C-0` | 新增 `StaticDelegateContractStatus::UserRevisionRequested` 与分类分支 | `M1A-1` | **已落地**：无审批写入方、是惰性路径；用户修订跳不增 `repair_depth` 也不重置 `clarification_round`，连续修订可通过；做游戏链路返工仍在 `depth=1` 被拒；历史记录与未知状态均保持 fail-closed |
-| `M1C-1` | `gdd-approval` pending、审批命令、receipt；receipt 写入上述 status | `M1B-2`、`M1C-0` | 三动作全通；版本+指纹竞态防护；两窗口并发；**连续多次修订均可通过且 `repair_depth` 不变**。**另须先裁决 `M1C-0` 合入复核留下的三条**（详见第 23.7 节「落地约束」与 `decision-log.md` 同名条）：① `UserRevisionRequested` 目前不进 `repair_required_count` / `user_input_required_count` 任一 barrier，写入方一落地就意味着 Supervisor run 可在用户修订尚未派出时完成——要么补 barrier，要么明确裁决不补；② `validate_static_delegate_structured_result` 对该变体只有「不得携带 user_input_questions」这条否定约束，没有正向一致性分支，须补齐终态/产物口径；③ 前向兼容失败粒度为整个子系统，须按第 23.7 节二选一 |
+| `M1C-0b` | 静态委派 durable enum 的前向兼容粒度：未知 `contract_status` 解析为显式 `Unknown` 并最大化阻塞 | `M1C-0` | 与 `M1C-0` 同形状：无写入方、纯读路径、对既有记录行为零变化可证。`Unknown` 进 barrier、返工门无条件拒、谱系按最保守分类；损坏（截断/非 UTF-8/超限）仍整体锁死不变；`Serialize` 原样回写原始字符串。裁决与理由见第 23.7 节「落地约束」裁决三。**不依赖 `M1B-*`，可与之并行；若不落，`M1C-1` 须走 release note 兜底** |
+| `M1C-1` | `gdd-approval` pending、审批命令、receipt；receipt 写入上述 status | `M1B-2`、`M1C-0`（前向兼容粒度另见 `M1C-0b`） | 三动作全通；版本+指纹竞态防护；两窗口并发；**连续多次修订均可通过且 `repair_depth` 不变**。**`M1C-0` 合入复核留下的三条已于 2026-08-15 裁决**（全文见第 23.7 节「落地约束」裁决一/二/三与 `decision-log.md` 同日条）：① 新增独立 barrier 计数 `user_revision_pending_count`，不并进现有两个，且**不带** `repair_of.is_none()`——否则第 2 次及以后的修订不阻塞；另有四处逐字段读 barrier 的调用点需逐处裁决；② `validate_static_delegate_structured_result` 复用 `EvidenceReady` 的三条客观证据约束，并把该处 if/else-if 链改成穷尽 `match`，但**不得更严**——该函数每次读取都跑，过严会把写入方 bug 变成 delivery 永久读不出；③ 前向兼容粒度移交 `M1C-0b`，本包二选一：`M1C-0b` 先落，或直接上线并在 release note 明写「用过策划审批后回滚旧版本会让该项目静态委派面不可用」 |
 | `M1C-2a` | Goal Contract 接线：turn 1 冻结、固定验收图、审批前置门取证 | `M1C-1`、`M1A-3` | turn 1 只能是一个 `agent.goal_contract`；`acceptanceNodes` 不接受自定义；**第 13.0 节审批前置门：取证未通过时不出现审批卡、而是产生返工委派**（取证顺序是协议时序问题，归本包而非 `M1C-1`） |
 | `M1C-2b` | 澄清中转接线、轮次派生、预算注入 | `M1C-2a` | 3 轮上限；continuation 重放幂等不增加轮次；答案绑定冲突被拒 |
 | `M1D-1` | 前端 hydrate 与 GDD 审批卡 | `M1C-2b` | 前端只经 `hydrate_game_creator_plan_gdd_state` 读权威状态，不在页面侧合成批准事实 |
@@ -2021,6 +2025,7 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 **拆包纪律**：
 
 - `M1C-0` 与 `M1C-1` 拆开的理由是**风险类别不同**：前者改的是 master 已发布的静态委派机制，后者是 M1 新增功能。合并成一个 PR 会让「做游戏链路返工额度未被误放宽」这条最关键的回归淹没在审批闭环的 diff 里。拆开后 `M1C-0` 全程不产生半状态——它没有写入方，`UserRevisionRequested` 要到 `M1C-1` 才被写出。
+- `M1C-0b`（2026-08-15 新增）从 `M1C-1` 里拆出的理由与上一条同源：它改的是 master 已发布机制的**所有读路径**，而 `M1C-1` 是 M1 新增功能。混在审批闭环的 diff 里，复核者只会看审批逻辑，读路径容错对既有记录的行为等价性无人证明。`M1C-0b` 依赖 `M1C-0`（`Unknown` 的分类分支要与用户修订分支落在同一处穷尽判定里），但不依赖 `M1B-*`。
 - `M1C-2` 拆成 a/b 的理由是两者失败模式无关：Goal Contract 是协议时序问题，澄清中转是身份派生与幂等问题。
 - 顺序是依赖顺序不是优先级。`M1C-0` 只依赖 `M1A-1`，可与 `M1B-*` 并行；`M1A-3` 同样只依赖 `M1A-1`，可与 `M1A-2`、`M1B-*` 并行。