M1C-0b：补齐静态委派状态前向兼容

- 未知 contractStatus 保留为 Unknown(raw) 并接入完成屏障、等待、返工与谱系门禁

- 补齐 planning Provider、自治 liveness 与终态扫描的 fail-closed 消费路径及回归

- 保持已知状态和损坏 sidecar 行为不变，更新技术方案与共享决策记录

docs/project-memory/shared-memory/decision-log.md

@@ -12,6 +12,15 @@
 - **拆包与门禁。** ①② 进 `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-15 M1C-0b：静态委派 durable status 前向兼容实现完成
+
+- **落地**：`StaticDelegateContractStatus` 采用手写 serde。四个已知 durable 值保持原有字符串；结构良好的未知字符串解析为 `Unknown(raw)`，并在再次序列化及读-改-写时原样保留 raw；非字符串输入仍拒绝。该包只改读路径，不新增状态写入方。
+- **门禁**：`Unknown` 进入 completion barrier 的独立计数与 waiting blocker，不能让 Supervisor 在未知状态未处理时收束；返工入口遇到 `Unknown` 无条件拒绝，即使 lineage depth 为 0；lineage 将其按“其它”质量返工分支保守计数（`depth + 1`、`round = 0`），只会拒绝、不会放宽额度。
+- **损坏边界**：截断、非法 JSON、非 UTF-8 或超过 128 KiB 的 sidecar 仍维持整目录 fail closed，不改成单条跳过或告警，以免 barrier 少计数而错误放行。
+- **范围与依赖**：不包含 `M1C-1` 的审批写入、`gdd-approval` pending、receipt、UI 或构建准入；不 bump durable schema 版本。为覆盖所有既有读路径，补了 planning Provider、自治 liveness 与终态扫描的 fail-closed 消费门，但没有新增或改变 `M1B-*` 功能依赖；该包仍可在 `M1C-0` 基础上独立验证。既有三种状态及历史记录行为保持不变。
+- **结论**：`WP1` 的 `repair_depth≤1` 结论未被推翻；Unknown 只增加前向不兼容时的保守阻塞，不会放宽普通做游戏链路的返工深度门。
+- **验收门禁与关联**：定向回归须覆盖未知 raw round-trip、barrier/waiting、无条件返工拒绝、保守 lineage 分类，以及损坏 sidecar 整体锁死；详见技术方案第 23.7 节裁决三与第 23.8 节 `M1C-0b` 门禁。
+
 ## 2026-08-14 M1C-0 合入复核：三条 M1C-1 前置、一条文档订正、一条已排除假设
 
 合入 `M1C-0`（见本文件同日条）后对该包做整组复核。**结论：包本身可合，「今天行为零变化」成立且可证**；但新变体在 `M1C-1` 写入之日会同时点亮三个默认值，而这三个默认值都不是裁决出来的，是「给用 `==` 比较（而非穷尽 `match`）的 durable enum 加变体，编译器不报，新变体静默落到作者没想过的那一侧」的结果——与本文件「修复 M1A-2 引入的回归」条同源，是同一失败模式的第二次出现。（复核完成后 `M1B-2` 已合入；其对 `delegation.rs` 的改动是 rustfmt 换行、无语义变化，本条结论不受影响。）
@@ -19,7 +28,7 @@
 - **不可达性已实证，不是靠注释。** `contract_status` 的生产赋值点只有两处（终态回执构造与 `build_static_delegate_structured_result_at`），都从客观事实派生（终态、缺失产物、verification、问题数），模型选不了；`StaticDelegateClaimRecord` 全仓库**唯一**构造点在 `delegation.rs` 的 claim 准备路径，是运行时构造而非 agent 提交的 JSON，所以「claim payload 自带 `contractStatus`」这条路不存在；durable sidecar 位于 `.agent/runtime/delegation-deliveries/`，被 `is_agent_runtime_private_control_path` 覆盖，`file_ops.rs` 与 `project/filesystem.rs` 各三处拒绝写入；前端无 `contractStatus` 消费者。哨兵侧同样成立：`static_delegate_lineage_counters` 的三个 fail-closed 出口（成环、超长、上游缺失）**全部**返回 `(u32::MAX, u32::MAX)`，两个分量都是 MAX，新分支的 `== u32::MAX` 检查全接得住；合法累加上限 31，不会误触。
 - **前置一：新变体不进任何 barrier。** `repair_required_count` 的判据是 `== NeedsRepair || (== NeedsUserInput && 有澄清答案)`，`user_input_required_count` 要求 `== NeedsUserInput`，`UserRevisionRequested` 两边都不落，因此 `barrier.is_clear()` 可能为真——`M1C-1` 写入方一落地就意味着 **Supervisor run 可以在用户修订尚未派出时完成**。同源的还有 `swarm_cli/terminal_classification.rs` 的 `static_delegate_delivery_has_repairable_contract`（`is_none_or(|r| == NeedsRepair)` → 新变体判为不可返工，影响面小但同样是默认选的）。`M1C-1` 须显式裁决补或不补。
 - **前置二：`validate_static_delegate_structured_result` 缺正向一致性分支。** `EvidenceReady` 有（终态/产物/verification 对账），`NeedsUserInput` 有（问题数 + 指纹），`UserRevisionRequested` 只继承了「不得携带 `user_input_questions`」这条否定约束，于是 `UserRevisionRequested + terminal_status="failed" + 缺产物` 能通过校验落盘。`M1C-0` 新增的 real-gate 回归恰好依赖这一点才能构造 fixture。
-- **前置三：前向兼容失败的粒度是整个子系统，不是单条记录。** `list_static_delegate_deliveries_at` 对每条 sidecar 用 `?` 上抛，一条解析失败即整个目录枚举失败，barrier、lineage、返工校验、run status 投影同时不可用。`M1C-0` 有意不 bump `STATIC_DELEGATE_DELIVERY_SCHEMA_VERSION` 且把「未知状态 serde 直接报错」记为安全属性——该性质成立，但**粒度当时没写**。注意 bump 版本号救不了：版本号校验排在 serde parse 之后。三条均已写进技术方案第 23.7 节「落地约束」与第 23.8 节 `M1C-1` 行。
+- **前置三：前向兼容失败的粒度是整个子系统，不是单条记录。** `list_static_delegate_deliveries_at` 对每条 sidecar 用 `?` 上抛，一条解析失败即整个目录枚举失败，barrier、lineage、返工校验、run status 投影同时不可用。`M1C-0` 当时有意不 bump `STATIC_DELEGATE_DELIVERY_SCHEMA_VERSION`，并在自身范围内把「未知状态 serde 直接报错」记为安全属性；**该前向兼容语义现由 `M1C-0b` 改为显式 `Unknown`，损坏输入仍整体锁死**。注意 bump 版本号救不了损坏输入：版本号校验排在 serde parse 之后。三条均已写进技术方案第 23.7 节「落地约束」与第 23.8 节 `M1C-1` 行。
 - **文档订正：`STATIC_DELEGATE_LINEAGE_MAX_HOPS = 32` 限的是链上节点数，不是跳数。** 判据 `chain.len() >= MAX_HOPS` 排在入链之前，故链最多 32 个节点 = **31 跳**。第 23.7 节原写「真实上限就是 32 跳」，已订正为 31。产品阈值 16 远低于两者，不受影响；`M1C-0` 自己的测试注释（「32 条 delivery（31 跳）」）一直是对的。之所以要订正：`M1C-0` 之前 `depth=1` 才是主刹车，用户修订路径上现在只剩这个哨兵，写错的数字从此是承重的。
 - **已排除的假设，后续不要重走。** 怀疑过「派一个子委派 → 抑制 → 再派一个」可绕开兄弟检查、在用户修订父节点下无限扩宽度。打不通：`suppress_static_delegate_delivery_at` 对 `ClaimedByParent` 直接原样返回、拒绝抑制，且生产侧唯一调用者是 `suppress_static_delegate_deliveries_for_parent_terminal_at`（父 run 终态清理），彼时同一 `parent_run_id` 已不能再派委派。另确认新分支**没有**跳过兄弟检查：if/else-if 链在前、兄弟检查在后且无提前返回，扇出仍是一条。
 - **测试侧本次一并处置。** ① `static_delegate_user_revision_preserves_existing_clarification_round` 名不副实：计数循环只遍历 `chain[..len-1]`（父节点集合），目标自身 status 从不参与判定，而该用例把 `UserRevisionRequested` 放在了**目标**位置，新分支根本没被执行。已改名为 `static_delegate_user_revision_parent_hop_preserves_depth_and_clarification_round`，补一跳真正以用户修订为父的续跑，并加反证（同一条链只把该父节点改回 `NeedsRepair`，结果必须变成 `(2, 0)`）；原断言保留为对照组并注明其性质。② `user_revision_continuation_passes_real_gate_at_depth_one_but_stays_single_child`（原 `static_delegate_user_revision_requested_continuation_...`）补兄弟检查断言。③ 新增 `concurrent_user_revision_dispatch_creates_exactly_one_delivery`，与既有 `project_supervisor_concurrent_repair_dispatch_creates_exactly_one_delivery` 同构但父节点为 `UserRevisionRequested` 且链上 depth 已为 1，两侧同时钉住：并发下恰好放行一条，且不是零条（新分支被删则两条都会被 depth 门拒，用例变红）。
@@ -40,8 +49,8 @@
 
 - 落地：`StaticDelegateContractStatus` 新增 `UserRevisionRequested`（serde durable 值为 `user-revision-requested`）。`static_delegate_lineage_counters` 现在按三类传播：`NeedsUserInput` 只增加 `clarification_round`；`UserRevisionRequested` 原样继承 `repair_depth` 与 `clarification_round`；其它状态继续按质量返工增加 `repair_depth` 并重置 `clarification_round`。
 - 门禁：父 delivery 为 `UserRevisionRequested` 时，后续同链续跑不再被 `repair_depth=1` 的质量返工门误拒，因此连续用户修订可以继续通过；链上 `(u32::MAX, u32::MAX)` fail-closed 哨兵仍拒绝，不得借用户修订分支绕过 32-hop、成环或缺失上游保护。普通做游戏链路没有该状态，`repair_depth≤1` 结论未被推翻。
-- 范围：本包没有任何审批状态写入方、`gdd-approval` pending、receipt 或前端状态；`UserRevisionRequested` 仍由后续 `M1C-1` 的审批命令与 receipt 同步写入。本包不 bump `STATIC_DELEGATE_DELIVERY_SCHEMA_VERSION`，未知 durable status 由 serde 直接报错，禁止静默降级为 `NeedsRepair`。
-- 回归：新增连续用户修订、保留已有澄清轮次、普通 depth=1 拒绝、32-hop fail-closed、`user-revision-requested` serde round-trip 与未知 variant fail-closed 覆盖；无新状态的历史记录继续按原质量返工分类。
+- 范围：本包没有任何审批状态写入方、`gdd-approval` pending、receipt 或前端状态；`UserRevisionRequested` 仍由后续 `M1C-1` 的审批命令与 receipt 同步写入。本包不 bump `STATIC_DELEGATE_DELIVERY_SCHEMA_VERSION`，也不处理未知 durable status；禁止将未知值静默降级为 `NeedsRepair`，其显式 `Unknown` 前向兼容由后续 `M1C-0b` 收口。
+- 回归：新增连续用户修订、保留已有澄清轮次、普通 depth=1 拒绝、32-hop fail-closed 与 `user-revision-requested` serde round-trip；未知 durable variant 的显式 `Unknown` 前向兼容与损坏输入锁死由 `M1C-0b` 单独覆盖，无新状态的历史记录继续按原质量返工分类。
 - 关联文档：`docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md` 第 23.7、23.8 节；后续审批写入依赖 `M1B-2`、`M1C-1`。
 - 合入说明：本包在隔离 worktree 上以 `09c7d7af8`（`M1A-2` 收口）为基线开发，未包含 `M1A-4`、M1A 残余收口、`M1A-2` 回归修复与 `M1B-1`。合回时代码零冲突（本包改的是顶层 `src-tauri/src/delegation.rs`，`M1A-4` 改的是 `src-tauri/src/agent/runtime_tools/delegation.rs`，同名不同文件），仅两份文档的状态句冲突：合并时以原分支为准保留 `M1A-4` / `M1B-1` 的已落地事实，删去本包基线上「`.agent/planning` 存储仍未实现」「`M1B-1` 及之后仍未开始」两句已被 `M1B-1` 推翻的表述。