立项策划：落地 M1C-0 合入复核结论，三条 M1C-1 前置与一条哨兵订正

生产代码零改动（delegation.rs 三个 hunk 全在 mod tests 内），本次只补回归与文档。

复核确认「今天行为零变化」成立且可证：contract_status 生产赋值点只有两处且都从
客观事实派生；StaticDelegateClaimRecord 全仓库唯一构造点是运行时构造，不是 agent
提交的 JSON；durable sidecar 在 .agent/runtime/** 下被 file_ops 与 filesystem 各
三处拒写；前端无 contractStatus 消费者。lineage 三个 fail-closed 出口全部返回
(u32::MAX, u32::MAX)，新分支的哨兵检查接得住。

三条 M1C-1 前置写进技术方案第 23.7、23.8 节与 decision-log：
① UserRevisionRequested 不进 repair_required_count / user_input_required_count
   任一 barrier，写入方落地即意味着 Supervisor run 可在用户修订未派出时完成；
② validate_static_delegate_structured_result 对该变体只有否定约束，缺正向一致性
   分支，UserRevisionRequested + failed + 缺产物 能通过校验落盘；
③ 前向兼容失败粒度是整个子系统——list_static_delegate_deliveries_at 逐条 ? 上抛，
   一条解析失败即整个目录枚举失败。bump schema version 救不了（版本校验在 parse 之后）。

文档订正：STATIC_DELEGATE_LINEAGE_MAX_HOPS = 32 限的是链上节点数不是跳数
（判据排在入链之前），真实跳数上限 31，第 23.7 节原写 32 跳已订正。

测试：
- static_delegate_user_revision_preserves_existing_clarification_round 名不副实，
  它把 UserRevisionRequested 放在目标位置，而计数循环只遍历父节点集合，新分支
  从未被执行。改名为 ..._parent_hop_preserves_depth_and_clarification_round，补
  一跳真正以用户修订为父的续跑并加反证；原断言留作对照组并注明性质。
- 新增 concurrent_user_revision_dispatch_creates_exactly_one_delivery，父节点为
  UserRevisionRequested 且 depth 已为 1，两侧同时钉住并发下恰好放行一条。
- user_revision_continuation_... 补兄弟检查断言（depth 门对用户修订失效后，它是
  该路径上唯一剩下的扇出约束）。

变异测试：摘掉 counters 分支 4 条变红（含新增反证 left (2,0) / right (1,1)）；
摘掉 gate 分支 3 条变红（并发用例 left 0 / right 1）。两处守卫各自有回归覆盖。

验证：定向 41 passed / 0 failed；npm run check:encoding 通过（5374 files）；
git diff --check 干净。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md

@@ -1979,17 +1979,18 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 
 | 硬边界 | 值 | 性质 |
 | --- | --- | --- |
-| `STATIC_DELEGATE_LINEAGE_MAX_HOPS` | 32 | 链上推断每次走完整条链，超限 fail closed 返回 `(u32::MAX, u32::MAX)`；防环/防越界兜底，不是可调参数 |
+| `STATIC_DELEGATE_LINEAGE_MAX_HOPS` | 32 | 链上推断每次走完整条链，超限 fail closed 返回 `(u32::MAX, u32::MAX)`；防环/防越界兜底，不是可调参数。**该常量限的是链上节点数，不是跳数**：判据 `chain.len() >= MAX_HOPS` 排在入链之前，故链最多 32 个节点 = **31 跳**（2026-08-14 订正，此前本节把它写成 32 跳） |
 | 单 lineage 版本数（第 8.8 节） | 128 | 版本链只增不改 |
 
-只要修订挂在同一条链上，真实上限就是 **32 跳**。让修订不挂链（`repair_of=None` 另起）可绕开，但会丢失谱系关联并重置澄清预算，等于绕开整套约束，不采纳。产品阈值定为 **16 次修订且为软提示**：远低于机制边界、又高到用户实际碰不到；超过时不拒绝，提示「已修订 16 次，建议退回重做重新梳理需求」——每次修订都是一次完整 Provider 调用加一个新版本，改到十几次仍不满意时问题多半在需求本身，此时应走退回重做（新 lineage、重新问询）而非无限微调。
+只要修订挂在同一条链上，真实上限就是 **31 跳**。让修订不挂链（`repair_of=None` 另起）可绕开，但会丢失谱系关联并重置澄清预算，等于绕开整套约束，不采纳。产品阈值定为 **16 次修订且为软提示**：远低于机制边界、又高到用户实际碰不到；超过时不拒绝，提示「已修订 16 次，建议退回重做重新梳理需求」——每次修订都是一次完整 Provider 调用加一个新版本，改到十几次仍不满意时问题多半在需求本身，此时应走退回重做（新 lineage、重新问询）而非无限微调。
 
 **落地约束**：
 
 - 拆包（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` 上线前必须二选一并记录裁决：给枚举加单条容错，或明确接受回滚锁死项目。**
 - 本裁决改的是 master 已发布的静态委派机制，须在 `decision-log.md` 补 dated 记录，写明 `WP1` 的 depth≤1 结论未被推翻。
-- 回归必须覆盖：用户修订跳不增 `depth` 也不重置 `round`；连续多次修订均可通过；做游戏链路的返工仍在 `depth=1` 被拒；无该变体的历史记录分类行为不变；32 跳边界仍 fail closed。
+- 回归必须覆盖：用户修订跳不增 `depth` 也不重置 `round`；连续多次修订均可通过；做游戏链路的返工仍在 `depth=1` 被拒；无该变体的历史记录分类行为不变；链长边界仍 fail closed；**用户修订父节点下「同一静态委派最多允许一轮返工」的兄弟检查仍然生效（含并发）**——depth 门对用户修订不再适用后，兄弟检查是该路径上唯一剩下的扇出约束。
 
 ### 23.8 M1 的 PR 结构与合入门禁（2026-08-13）
 
@@ -2004,7 +2005,7 @@ 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-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-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` 读权威状态，不在页面侧合成批准事实 |