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

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

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

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

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

@@ -1,9 +1,9 @@
 # 立项策划 Agent（Fast GDD）技术方案
 
 - 日期：2026-08-10
-- 状态：2026-08-12 **M0 代码工作包全部完成**（`M0A-2`、`M0B-1`、`M0B-2` 已合入 M0 集成分支并通过各自门禁，见第 23.4 节）；同日 **D6 作废、拓扑改变**，`M0A-1` 交付的文档基线随之失效，需以工作包 `M0A-3` 修订，**修订完成前 M0 不计完整完成**（见第 1.1 节）。2026-08-13 **D9 二次作废、D10 作废，由 D11 取代**：立项策划节点改为 Project Supervisor 通过 `agent.delegate` 发起的静态委派子 Agent，问询复用 PR #165 中转链路（见第 1.1 节「D11 新拓扑」）；D11 依赖 WP1（静态委派澄清轮次与返工深度拆分）为强制前置，**该前置已于 2026-08-13 落地并合入**（`WP1` 生产代码 + `WP2` 回归，完成状态与门禁见第 23.5 节），澄清轮次上限现为 3（game-chat source 仍为 1）。随后 `M1A-1`、`M1A-2`、`M1A-3`、`M1A-4` 已分别落地：`M1A-2` 仅收口两层工具面、`project-planning` role brief 注入和 fail-closed 拒绝边界，`M1A-4` 收窄 plan 根 run 的子 Agent 创建面。**2026-08-14 `M1B-1` 已通过门禁并合入本分支**：已落地 `.agent/planning` storage module、strict schema/typed 指纹/canonical parser、GDD 版本链、session 原子恢复、Runtime 写入身份及只挡写门禁；golden vector 与 11 个定向 storage 测试通过，writer/index/recovery 门禁已完成。**2026-08-15 `M1B-2` 工作包已通过本包门禁并以 `27c3eb847` 合入本分支**：已落地 `plan.submit_gdd`、exact planning Provider binding/structured injection、专用提交点与崩溃恢复；本包不包含 `gdd-approval` planning pending、审批等待、receipt、审批命令或 UI。**2026-08-14 `M1C-0` 已合回本分支**：仅新增用户修订状态及 lineage 分类，不包含审批写入方。当前仅表示 M1B-2 工作包完成，完整审批闭环、UI、构建准入仍未实现，见第 23.6、23.8 节。后续执行计划见第 23.6 节。
+- 状态：2026-08-12 **M0 代码工作包全部完成**（`M0A-2`、`M0B-1`、`M0B-2` 已合入 M0 集成分支并通过各自门禁，见第 23.4 节）；同日 **D6 作废、拓扑改变**，`M0A-1` 交付的文档基线随之失效，需以工作包 `M0A-3` 修订，**修订完成前 M0 不计完整完成**（见第 1.1 节）。2026-08-13 **D9 二次作废、D10 作废，由 D11 取代**：立项策划节点改为 Project Supervisor 通过 `agent.delegate` 发起的静态委派子 Agent，问询复用 PR #165 中转链路（见第 1.1 节「D11 新拓扑」）；D11 依赖 WP1（静态委派澄清轮次与返工深度拆分）为强制前置，**该前置已于 2026-08-13 落地并合入**（`WP1` 生产代码 + `WP2` 回归，完成状态与门禁见第 23.5 节），澄清轮次上限现为 3（game-chat source 仍为 1）。随后 `M1A-1`、`M1A-2`、`M1A-3`、`M1A-4` 已分别落地：`M1A-2` 仅收口两层工具面、`project-planning` role brief 注入和 fail-closed 拒绝边界，`M1A-4` 收窄 plan 根 run 的子 Agent 创建面。**2026-08-14 `M1B-1` 已通过门禁并合入本分支**：已落地 `.agent/planning` storage module、strict schema/typed 指纹/canonical parser、GDD 版本链、session 原子恢复、Runtime 写入身份及只挡写门禁；golden vector 与 11 个定向 storage 测试通过，writer/index/recovery 门禁已完成。**2026-08-15 `M1B-2` 工作包已通过本包门禁并以 `27c3eb847` 合入本分支**：已落地 `plan.submit_gdd`、exact planning Provider binding/structured injection、专用提交点与崩溃恢复；本包不包含 `gdd-approval` planning pending、审批等待、receipt、审批命令或 UI。**2026-08-14 `M1C-0` 已合回本分支**：仅新增用户修订状态及 lineage 分类，不包含审批写入方。**2026-08-15 `M1C-0b` 已通过定向门禁并完成**：只改静态委派 durable status 的前向兼容读路径，未知字符串显式保留为 `Unknown(raw)` 并最大化阻塞；不含审批写入方。当前仍未实现完整审批闭环、UI、构建准入，见第 23.6、23.8 节。后续执行计划见第 23.6 节。
 - 适用范围：AI 游戏创作独立 App、Project Supervisor、Agent Runtime、本地项目策划 sidecar 与后续完整构建准入
-- 当前实现边界：本文件是后续详细设计与实现的仓库内阶段基线；M0 工作包冻结 Fast GDD 合同并修复现有 owner 验证、game-chat retry 与前端投影边界，`M1A-1`～`M1A-4` 已提供 plan source、两层工具面、角色 brief 与子 Agent 创建面收窄的 Runtime 基础，`M1C-0` 已提供用户修订 lineage 分类，已合入的 `M1B-1` 提供 storage 基础与写入隔离；`M1B-2` 工作包已通过本包门禁并合入，但不构成完整可交付：审批 UI、receipt、审批等待、构建绑定和正式入口仍不可用
+- 当前实现边界：本文件是后续详细设计与实现的仓库内阶段基线；M0 工作包冻结 Fast GDD 合同并修复现有 owner 验证、game-chat retry 与前端投影边界，`M1A-1`～`M1A-4` 已提供 plan source、两层工具面、角色 brief 与子 Agent 创建面收窄的 Runtime 基础，`M1C-0` 已提供用户修订 lineage 分类，已合入的 `M1B-1` 提供 storage 基础与写入隔离；`M1B-2` 工作包已提供提交点与恢复，`M1C-0b` 已补齐静态委派未知 durable status 的前向兼容读路径（包括既有 Provider/终态消费点的 fail-closed guard），但不构成完整可交付：审批 UI、receipt、审批等待、构建绑定和正式入口仍不可用
 
 ## 1. 背景与目标
 
@@ -1881,7 +1881,7 @@ M0 收口时的三项已知残留，均已定性且不阻塞后续阶段：
 - `set_task_status` 无秩序守卫的无条件覆盖，属 master 既有问题，另行提 issue，不在 M0 范围内修。
 - 第 23.1 节的 M1 入口前置决策：**2026-08-13 起为空**。三项当日全部关闭——「plan source 与 Goal Contract 协议的关系」裁决为进可信 matcher；「plan run 是否允许 steer」裁决为不允许；「checkpoint handoff 私有持久化」随 D10 一并作废、无需裁决。M1 不再有未决的合入前置决策。
 
-M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`、`M1B-2` 与 `M1C-0` 已合入，其中 `.agent/planning` strict schema/版本链已由 M1B-1 提供；M1B-2 已提供 `plan.submit_gdd`、exact planning Provider binding/structured injection、专用提交点与崩溃恢复，审批 pending/receipt、前端入口和构建准入仍待后续 M1C～M1E 工作包。第 19 节第 2 条中关于工具面与执行拒绝的目标不变量已由 M1A-2/M1A-4 覆盖，其余 GDD 审批不变量仍按第 23.8 节推进。
+M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`、`M1B-2`、`M1C-0` 与 `M1C-0b` 已合入，其中 `.agent/planning` strict schema/版本链已由 M1B-1 提供；M1B-2 已提供 `plan.submit_gdd`、exact planning Provider binding/structured injection、专用提交点与崩溃恢复，M1C-0b 已为既有静态委派读路径补未知 durable status 的显式保留与保守阻塞，审批 pending/receipt、前端入口和构建准入仍待后续 M1C～M1E 工作包。第 19 节第 2 条中关于工具面与执行拒绝的目标不变量已由 M1A-2/M1A-4 覆盖，其余 GDD 审批不变量仍按第 23.8 节推进。
 
 ### 23.5 `WP1` / `WP2`：静态委派澄清轮次与返工深度拆分（2026-08-13 完成）
 
@@ -1910,7 +1910,7 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 
 **完成状态**：上述门禁全部通过，`WP1` 生产代码与 `WP2` 回归已合入本分支。已知遗留：`project_supervisor_concurrent_repair_dispatch_creates_exactly_one_delivery` 是 Barrier 同步的并发用例，在本机 Windows 上间歇失败；经与改造前基线对照（同一用例各跑 6 次，改造前后同为 1 次失败）确认为既有抖动，不是本工作包引入，不作为回归处理。
 
-### 23.6 后续执行计划（2026-08-13 起；2026-08-14 状态更新）
+### 23.6 后续执行计划（2026-08-13 起；2026-08-15 状态更新）
 
 本节记录 D11 之后的执行顺序与各步状态，避免「设计结论持续更新、但做到哪了无人维护」。
 
@@ -1921,7 +1921,7 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 | 三 | `project-planning` 的 agentCatalog 登记 | **已完成**（机制冻结见第 3.1 节；**代码亦已落地**，2026-08-13：manifest、prompt bundle、runtime adapter、`prompt.rs` 角色合成分支及四处 needs_change 全部合入） |
 | 四 | `M0A-3` 批二：拓扑与工具面部分 | **已完成**（2026-08-13），拆解见下 |
 | 四之余 | schema 与 golden vector 收口 | **已完成**（2026-08-13），拆解见下 |
-| 五 | M1 本体：策划闭环功能实现 | **`M1A-1`、`M1A-2`、`M1A-3`、`M1A-4`、`M1B-1`、`M1B-2`、`M1C-0` 已落地并合入**；其中 `M1B-1` 的 storage 基础、strict schema、typed 指纹、版本链、session 原子恢复、只挡写门禁及 writer/index/recovery 验证均已完成，golden vector 与 11 个定向 storage 测试通过。**`M1B-2` 工作包已通过本包门禁并合入**：已接入 `plan.submit_gdd`、四类 exact planning v3 binding/structured injection、v4 sole-submit batch、create-only 提交点、index/Markdown/session successor、策划子 run 终止及 generic v5/v4 anchor 恢复；不创建 `gdd-approval` planning pending 或审批等待。`M1C-1` 及之后仍未实现。合入门见第 23.8 节 |
+| 五 | M1 本体：策划闭环功能实现 | **`M1A-1`、`M1A-2`、`M1A-3`、`M1A-4`、`M1B-1`、`M1B-2`、`M1C-0`、`M1C-0b` 已落地并合入**；其中 `M1B-1` 的 storage 基础、strict schema、typed 指纹、版本链、session 原子恢复、只挡写门禁及 writer/index/recovery 验证均已完成，golden vector 与 11 个定向 storage 测试通过。**`M1B-2` 工作包已通过本包门禁并合入**：已接入 `plan.submit_gdd`、四类 exact planning v3 binding/structured injection、v4 sole-submit batch、create-only 提交点、index/Markdown/session successor、策划子 run 终止及 generic v5/v4 anchor 恢复；不创建 `gdd-approval` planning pending 或审批等待。**`M1C-0b` 工作包已通过定向门禁并合入**：未知 durable status 解析为 `Unknown(raw)`，进入 completion barrier/waiting blocker，返工/Provider/终态消费点 fail closed，读-改-写保留 raw，损坏 sidecar 仍整目录锁死。`M1C-1` 及之后仍未实现。合入门见第 23.8 节 |
 
 批二在 2026-08-13 拆成两半，因为其中一半在 M1 代码存在之前**做不完**：
 
@@ -1987,7 +1987,7 @@ 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`**——那会让用户修订被误计成返工，正是本裁决要消除的行为。
+- `StaticDelegateContractStatus` 是 durable schema 的一部分。新增 `UserRevisionRequested` 属**前向兼容**问题（旧代码读不了新记录），非后向兼容问题：只有做方案链路会写它，做游戏链路既有记录不受影响。`M1C-0` 本包不处理未知 durable status，但不得把未知值静默降级为 `NeedsRepair`；未知值的前向兼容由 `M1C-0b` 单独收口为显式 `Unknown`（并原样回写），损坏输入仍整体 fail closed。
 - **（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` 引入的**第二个写入方**。
@@ -2007,8 +2007,8 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 | `M1A-4` | plan 根 run 的子 Agent 创建面收窄：`agent.delegate` 目标必须是 `project-planning`、`agent.spawn_isolated` 一律拒；plan source 下不拼 `supervisorIntro` 与 `$visualContract` | `M1A-2` | 执行层与上下文层**都要做且不可互相替代**（同第 19 节第 2 条纪律）；`agent.spawn_isolated` 是第二条造子 Agent 的通道，只堵 `agent.delegate` 视为未完成；强判据 `Err` 必须落进拒绝分支而非当作「不是 plan 根」；`project-supervisor-gui/cli` 的委派与 spawn 行为正常路径不变。**必须早于 `M1D-2` 与 `M1E`** |
 | `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-0b` | 静态委派 durable enum 的前向兼容粒度：未知 `contract_status` 解析为显式 `Unknown` 并最大化阻塞 | `M1C-0` | 与 `M1C-0` 同形状：无写入方、纯读路径、对既有记录行为零变化可证。`Unknown` 进 barrier、返工门无条件拒、谱系按最保守分类；损坏（截断/非 UTF-8/超限）仍整体锁死不变；`Serialize` 原样回写原始字符串。裁决与理由见第 23.7 节「落地约束」裁决三。**不依赖 `M1B-*`，可与之并行；若不落，`M1C-1` 须走 release note 兜底** |
+| `M1C-0` | 新增 `StaticDelegateContractStatus::UserRevisionRequested` 与分类分支 | `M1A-1` | **已落地**：无审批写入方、是惰性路径；用户修订跳不增 `repair_depth` 也不重置 `clarification_round`，连续修订可通过；做游戏链路返工仍在 `depth=1` 被拒；原有三种状态与 `UserRevisionRequested` 的已知行为保持不变，未知 durable status 的前向兼容由已完成的 `M1C-0b` 显式承接，不在本包静默降级或改变 |
+| `M1C-0b` | 静态委派 durable enum 的前向兼容粒度：未知 `contract_status` 解析为显式 `Unknown` 并最大化阻塞 | `M1C-0` | **已完成**：纯读路径、无写入方、审批状态、pending、receipt 或 UI（不含 `M1C-1`）。四种已知 durable 值保持原 serde；未知字符串解析为 `Unknown(raw)`，非字符串仍拒绝，`Serialize` 及读-改-写均原样保留 raw。`Unknown` 计入 completion barrier 与 waiting blocker，返工入口无条件拒绝（含 `depth=0`），lineage 按“其它”最保守分类（`depth + 1`、`round = 0`）；planning Provider、自治 liveness、终态扫描等既有读路径同步 fail closed。截断、非法 JSON、非 UTF-8、超过 128 KiB 的 sidecar 仍按整目录 fail closed，不做单条跳过。**不新增或改变 `M1B-*` 功能依赖（仅复核其既有读路径）；不包含 `M1C-1` 的审批写入、receipt、UI 或构建准入** |
 | `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 重放幂等不增加轮次；答案绑定冲突被拒 |