文档：D9 二次作废、D10 作废，立项策划改为 Supervisor 静态委派子 Agent（D11）

- 第 2 节决定表：D9 标注二次作废（保留原文，说明哪些结论被 D11 继承、哪些被推翻）；D10 一并作废（其存在前提"ready-task 节点无 parent、Runtime 拦不住"在新拓扑下不成立）；新增 D11，表头改为 D1～D11。
- 第 1.1 节新增"D11 新拓扑"小节：立项策划节点改为 Project Supervisor 通过 agent.delegate 发起的静态委派子 Agent（agentId=project-planning），问询复用 PR #165 中转链路；列出六条已验证支撑事实（均带 file:line），并注明 D11 依赖 WP1（澄清轮次/返工深度拆分）为强制前置。同步标注旧"新拓扑（替代 D6）"小节已被取代，更新"分两批执行"：命名裁决已完成，批二改由 build.rs agentCatalog 一致性裁决阻塞。
- 第 19 节第 2 条、第 24 节第 8 条：改写为"执行层由 Runtime 兜底拒绝、广告层仍可见"的准确表述，替换失效的"排除是产品自律"旧表述。
- 第 4.3 节：修正与第 19 节第 2 条矛盾的 plan source 四工具清单（其中列着 user.input_request）。
- 第 23.1 节：策划节点命名裁决标记已冻结；新增 project-planning 的 build.rs 一致性待裁决项；plan run steer 待裁决项按 D11 拓扑更新。
- 文首状态行、第 1 节开篇段同步更新为 D11 现状。

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

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

@@ -1,7 +1,7 @@
 # 立项策划 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 节）。M1～M3 功能尚未实现，全仓库零代码
+- 状态：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（静态委派澄清轮次与返工深度拆分）为强制前置，WP1 落地前问询上限仍是 1 轮。M1～M3 功能尚未实现，全仓库零代码
 - 适用范围：AI 游戏创作独立 App、Project Supervisor、Agent Runtime、本地项目策划 sidecar 与后续完整构建准入
 - 当前实现边界：本文件是后续详细设计与实现的仓库内阶段基线；M0 工作包只冻结 Fast GDD 合同并修复现有 owner 验证、game-chat retry 与前端投影边界，不代表立项策划入口、审批 UI、Runtime 持久化或构建绑定已经可用
 
@@ -9,7 +9,7 @@
 
 当前普通完整构建会从简短需求直接进入 `autonomous-game-build`，用户在消耗完整构建成本前没有正式确认玩法方向、MVP 范围和原型验证项的环节。现有完整构建中的 `design-director` 是只读协调任务，`design-foundation` 又会自行补齐玩法定位；用户意图与后续实现之间缺少可版本化、可审批、可恢复的策划基线。
 
-本方案新增“立项策划”阶段：用户给出一句需求后，由 Project Supervisor 顶层 run 调度一个独立 `agentId` 的下游策划工作流节点（2026-08-12 起，取代原“同一通道切换 persona”的表述，见第 1.1 节与 D9），在最多 3 轮决策卡内形成 Fast GDD；Runtime 校验并提交不可变版本，用户通过审批卡批准、修改或退回。只有不可变 GDD 与对应 approve receipt 同时有效时，后续完整构建才能取得 `approvedGddRef`。
+本方案新增“立项策划”阶段：用户给出一句需求后，由 Project Supervisor 顶层 root run 通过 `agent.delegate` 发起一个独立 `agentId` 的静态委派子 Agent（`agentId=project-planning`；2026-08-13 起取代原“下游工作流节点由 manifest ready-task 调度器启动”的表述，见第 1.1 节「D11 新拓扑」与 D11），在最多 3 轮决策卡内形成 Fast GDD（该 3 轮上限依赖 WP1——静态委派澄清轮次与返工深度拆分——先落地，见第 1.1 节；落地前实际上限仍是 1 轮）；Runtime 校验并提交不可变版本，用户通过审批卡批准、修改或退回。只有不可变 GDD 与对应 approve receipt 同时有效时，后续完整构建才能取得 `approvedGddRef`。
 
 目标：
 
@@ -46,6 +46,8 @@
 
 #### 新拓扑（替代 D6）
 
+> **2026-08-13 起已被取代**：本小节描述的是 D9 拓扑（ready-task 调度器启动下游工作流节点 + Runtime 直投），已被 D11 取代——见本节末尾「2026-08-13 D11 新拓扑」。保留本小节仅作 D6→D9 推导记录，其中「Supervisor 仍是唯一顶层 root run」「用户侧只有一个对话对象、对话内容必须物理存在于 Supervisor 会话」两条方向性结论被 D11 继承；「manifest ready-task 调度器启动」「Runtime 直投」两条机制性结论被 D11 推翻，不要把本小节当作现行设计。
+
 - **Supervisor 仍是唯一顶层 root run**，以新的可信 source 承载「做方案」入口，run profile 固定 `standard`。
 - **策划 Agent 是独立 `agentId` 的下游工作流节点**，由 manifest ready-task 调度器在 Supervisor 下游启动，profile 随父固定为 `standard`。本版工作流只有这一个节点，但框架按将来可加节点搭建。
 - **问询改为「Runtime 直投」**：策划节点提交结构化决策字段，Runtime 据此创建 **owner 是 Supervisor** 的 `user.input_request` pending（`agentId` 为 Project Supervisor、Supervisor 的 session 与 run），用户在 Supervisor 对话里回答。Supervisor 的 Provider 完全不参与提问，是纯函数搬运。
@@ -76,7 +78,7 @@ M0 三个代码工作包无一行按 D6 编写，**不需要为新设计回退
 - 第 22 节证据表：`trusted matcher 消费者`行结论句改写；新增 standard 路径 owner 验证、Runtime 直投两行
 - 第 23.4 节：M0 完成状态改为「代码完成、文档待修订」
 
-**批二（被「策划节点 `agentId` / source 命名」裁决阻塞）**
+**批二（原被「策划节点 `agentId` / source 命名」裁决阻塞；2026-08-13 命名裁决已完成，批二不再被命名阻塞，改由下方「D11 新拓扑」第 6 条 `build.rs` 一致性待裁决项阻塞）**
 
 - 第 3 节注册表全部身份常量、第 4 节拓扑图、第 4.1 / 4.2 节（整节作废后重写）、第 4.3 节工具清单
 - 第 5.1 / 5.2 节 checkpoint 触发点、第 6 节 Prompt 权威稿
@@ -84,7 +86,7 @@ M0 三个代码工作包无一行按 D6 编写，**不需要为新设计回退
 - 第 12 节 submit dispatch 段、第 13.1 / 13.3 节 `agentId` 常量、第 14 节 activeQuestion 相关五行恢复语义
 - 第 18.1 节前端入口
 
-命名未定前批二一个字都无法落笔，因此该裁决是 `M0A-3` 的首要前置。
+2026-08-13 更新：命名裁决已冻结——策划子 Agent `agentId=project-planning`，Supervisor 侧承载「做方案」入口的新可信 source 为 `project-supervisor-plan`。批二不再被命名阻塞。但 D11 把策划节点从「ready-task 工作流节点」改成「静态委派子 Agent」，批二这些小节的具体写法（尤其第 3 节注册表、第 4 节拓扑图）必须按 D11 新拓扑而非 D9 旧拓扑重写，且新增了「D11 新拓扑」第 6 条列出的 `build.rs` agentCatalog 一致性前置——`project-planning` 如何登记进编译期 seed task catalog 而不触发 `validate_seed_task_catalog`（`apps/ai-game-creator-shell/src-tauri/build.rs:23-46`）panic 尚未裁决，批二涉及注册表落笔前必须先冻结这一点。本轮文档修订范围不含批二，此处只记录状态变化。
 
 #### Goal Contract：四方案作废，替换为三条已验证约束
 
@@ -97,8 +99,8 @@ M0 三个代码工作包无一行按 D6 编写，**不需要为新设计回退
 #### `M0A-3` 门禁与完成定义
 
 - 批一全部合入，且本文不再存在自相矛盾的表述（同一事实在两处给出不同结论即视为未完成）。
-- 命名裁决冻结并写入决策记录后，批二全部合入。
-- decision log 与 pitfalls 同步补记：D6 作废理由、autonomous 下父子皆不可提问且硬闯会瘫痪整条工作流、`M0A-2` owner 验证不可复用。
+- 命名裁决冻结并写入决策记录后（2026-08-13 已完成），批二全部合入——**但改由 `build.rs` agentCatalog 一致性裁决阻塞**（见第 1.1 节「D11 新拓扑」第 6 条与第 23.1 节待裁决项），该裁决冻结前批二仍不得落笔。
+- decision log 与 pitfalls 同步补记：D6 作废理由、autonomous 下父子皆不可提问且硬闯会瘫痪整条工作流、`M0A-2` owner 验证不可复用；2026-08-13 起还需同步补记 D9 二次作废、D10 作废、D11 新拓扑与 WP1 澄清轮次/返工深度拆分定稿（已完成，见 decision-log 2026-08-13 条）。
 - **仅文档工作包，不含任何代码改动**；合入只表示设计基线恢复自洽，不表示任何功能可用。
 
 #### `M0A-3` 明确不做
@@ -107,7 +109,22 @@ M0 三个代码工作包无一行按 D6 编写，**不需要为新设计回退
 - 不删 `design-director`、不动 `design-foundation`、不改 16 任务 DAG——这些论证已成立（`design-director` 不在 owner 产物清单、产物无人读），但属于「做游戏」路径改造，等 GDD 真正被完整构建消费时另开工作包。
 - 不实现 M1～M3 任何功能。
 
-## 2. 已锁定决定 D1～D10
+#### 2026-08-13 D11 新拓扑：立项策划改为 Supervisor 静态委派子 Agent（取代 D9，连带作废 D10）
+
+D9/D10 描述的「manifest ready-task 调度器在 Supervisor 下游启动策划节点」+「Runtime 直投创建 owner=Supervisor 的 pending」拓扑作废，改为：**立项策划节点是 Project Supervisor 通过 `agent.delegate` 发起的静态委派子 Agent（`agentId=project-planning`）**，不再由 ready-task 调度器启动；问询不再新造「直投」机制，改为复用 PR #165（Issue #163 决策，见 `docs/project-memory/shared-memory/decision-log.md` 2026-08-12 条「子 Agent 澄清回执由 Supervisor 中转」）已实现的中转链路：子 Agent 以 `AGC_NEEDS_USER_INPUT_V1` 终态信封退出 → Supervisor 认领回执 → Supervisor 在自己的 runtime/session 上建 `waiting-for-user-input` pending → 用户在 Supervisor 会话内作答 → 答案经 `questionsSha256`/`answersSha256` 原子绑回 delivery → Supervisor 发起 continuation 子 Agent 续跑。命名裁决已冻结：`agentId=project-planning`，Supervisor 侧新可信 source 为 `project-supervisor-plan`。
+
+支撑 D11 的六条已验证事实：
+
+1. **执行层拦截，广告层不拦。** 委派子 Agent 天然带 `parent_agent_id`/`parent_run_id`，其 `user.input_request` 在落盘 pending 之前被执行层 `validate_user_input_action_owner`（`apps/ai-game-creator-shell/src-tauri/src/user_input.rs:367-394`）拒绝——只要 task 存在 `parent_agent_id`、`parent_run_id` 或 `delegation_id` 中任一项即失败，不再依赖 D10 那种 exact allowlist 自律。但**广告层不拦**：`build_agent_runtime_native_function_tools`（`apps/ai-game-creator-shell/src-tauri/src/agent_native_tools.rs:279`）没有 `agent_id` 参数，无法按身份裁剪；`standard` profile 下 `tool_policy_snapshot.rs:144-147`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/tool_policy_snapshot.rs`）仍无条件把 `user.input_request` 归入 `auto_tools`。模型看得见这个工具、会去调用，只是调用必失败并转成一次失败的 tool observation，不是零可见。
+2. **约束二（答案物理落 Supervisor 会话）成立，有完整机械证据链。** `ensure_static_delegate_user_input_wait_at`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/provider_recovery.rs:327-408`）→ `build_game_creator_agent_runtime_pending_tool_action`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/provider_action_batch.rs:219-251`，`agent_id`/`session_id`/`run_id` 直接抄 Supervisor 自身的 `runtime` 参数）→ `build_new_user_input_record`（`user_input.rs:396-411`，`agent_id`/`session_id` 从 pending 原样继承）→ `append_user_input_question_message` / `append_user_input_answer_message`（`user_input.rs:494-532`）→ `conversation_file_path_for_resolved_session`（`apps/ai-game-creator-shell/src-tauri/src/project/conversation.rs:48-59`）。问答消息物理写进 Supervisor 自己的会话 `.jsonl` 文件，是后端持久化事实，不是前端把多个 Agent 的会话拼接显示。
+3. **多轮不失忆，但转述保真不由 Runtime 校验。** 委派的 `target_session_id` 每轮都解析为 `resolve_agent_conversation_session_id_at(root, target_agent_id, None, true)`（`apps/ai-game-creator-shell/src-tauri/src/project/conversation.rs:860-875`），传 `None` 时走 `catalog.active_session_id`（`conversation.rs:849-850`）——即每一轮委派都落在同一条持久 active session 上；而 prompt history 按 `(agent_id, session_id)` 组装（`apps/ai-game-creator-shell/src-tauri/src/context_compaction.rs:453-490` 的 `prepare_game_creator_agent_runtime_prompt_history`），`run_id` 只用于 `observation_start` 的覆盖计数过滤。因此 continuation 子 Agent 是「新 run、同 session」，能看到自己前几轮的完整对话。**但残留风险如实记录**：用户的答案本身不在子 Agent 的 session 里（物理落在 Supervisor 那边），子 Agent 只能依赖 Supervisor 把已确认答案重新组织进新的委派 task 文本；Runtime 只校验 `questionsSha256`/`answersSha256` 的哈希绑定，**不校验转述内容与已确认答案的语义一致性**，转述保真完全依赖 Supervisor 侧 LLM 的行为质量。委派 task 有硬上限 `AGENT_RUNTIME_TASK_MAX_CHARS = 4_000`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver.rs:147`），超限直接 `Err`，不会静默截断丢失内容。
+4. **产物路径与 `.agent/planning/**` 不冲突，且有结构性保证而非文档层自律。** `normalize_static_delegate_expected_artifact`（`apps/ai-game-creator-shell/src-tauri/src/delegation.rs:1981-1998`）拒绝首段为 `.agent` 的相对路径，因此 `.agent/planning/**` 在委派发起阶段就无法进入 `expectedArtifacts`，不需要额外的文档层面约束。`game/fast_gdd.md` 不在 `.agent` 下，可以正常登记。定稿：`expectedArtifacts=["game/fast_gdd.md"]`，质性标准写进 `acceptanceCriteria`，`verification_required=false`——策划节点没有 verify/smoke 类工具，无法产生可供 Runtime 复核的验证凭证。
+5. **前置依赖：D11 的“最多 3 轮问询”依赖 WP1 先落地，是强制前置，不是并行工作包。** WP1（澄清轮次 `clarification_round` 与返工深度 `repair_depth` 拆分，详见下方及 decision-log 2026-08-13 条）正在另一个 worktree 并行实现。在 WP1 落地前，`repair_of_delegation_id.is_some()` 即拒绝（`apps/ai-game-creator-shell/src-tauri/src/delegation.rs:1119-1121`），澄清 continuation 与质量返工共用同一条「深度最多为 1」判据，D11 描述的多轮问询实际上限只有 1 轮，且这 1 轮一旦用掉，同一条委派链就再也做不了任何质量返工。本文档把 WP1 列为 D11 生效的强制前置条件，不得默认「等 WP1 完成再补上限」这种弱化表述。
+6. **未决前置：`project-planning` 的编译期 agentCatalog 登记方式，会撞上 `build.rs` 一致性校验。** `project-planning` 目前不在编译期 agentCatalog 里；而 `build.rs` 的 `validate_seed_task_catalog`（`apps/ai-game-creator-shell/src-tauri/build.rs:23-46`）要求编译出的 `(taskId, groupId, role)` 集合与 `shared_contracts::game_creation_app::new_game_creation_app_seed_tasks()` 逐项相等，不等直接 `panic!`。如何登记 `project-planning` 而不破坏这条一致性校验——是否需要给 `new_game_creation_app_seed_tasks()` 新增一条不落入 16 任务 DAG 的条目、还是该 catalog 本身需要拆分——是 D11 的**未决前置**，本文档只挂为待裁决项（见第 23 节），不假装已有结论。
+
+WP1 定稿的澄清轮次/返工深度语义（供 D11 依赖，权威定义见 decision-log 2026-08-13 条，不在本节重复展开）：`repair_depth` 上限维持 1 不放松，`clarification_round` 上限按 source 区分——`source == AGENT_RUNTIME_SUPERVISOR_GAME_CHAT_SOURCE`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver.rs:109`）时取 1，其它 source（含 D11 的 `project-planning` 委派链）取 3；两个维度都是运行时沿 `repair_of_delegation_id` 链上推断的派生值，不新增 `StaticDelegateDeliveryRecord` 持久字段。
+
+## 2. 已锁定决定 D1～D11
 
 | 编号 | 冻结结论 |
 | --- | --- |
@@ -119,8 +136,9 @@ M0 三个代码工作包无一行按 D6 编写，**不需要为新设计回退
 | ~~D6~~ | **2026-08-12 作废**，由 D9 取代。原文：“立项策划 Agent”是 Project Supervisor 通道的第三 persona，以持久 source 区分，复用 `standard` profile，不注册新的 agentCatalog 身份。作废理由见第 1.1 节；其中“复用 `standard` profile”这一结论方向被 D9 继承，但成立理由完全不同。 |
 | D7 | 本期不实现知识图谱；`basis`、知识 provider trait、composition 槽位可以预留，但 v1 数据必须为 `null`，空字段不渲染。 |
 | D8 | GDD 不含引擎字段；平台事实固定由 Runtime 注入，Agent 不得向用户提问或修改。 |
-| D9 | **取代 D6。** 立项策划是独立 `agentId` 的下游工作流节点，由 manifest ready-task 调度器在 Supervisor 下游启动，需登记 agentCatalog；Project Supervisor 以新的可信 source 承载「做方案」入口并保持唯一顶层 root；父子 run profile 必须同为 `standard`——不是为了复用顶层通道，而是因为 `autonomous-game-build` 对 `user.input_request` 的禁令按 profile 生效、父子皆不可提问，且子 Run 不能切换父 Run 的 profile。 |
-| D10 | 策划节点**不得**直接调用 `user.input_request`——注意这不是 Runtime 拦得住的：standard ready-task 调度器不写 parent，该调用会被放行，因此必须由 exact allowlist 主动排除并以回归钉死。禁止的理由是产品约束：直接提问会把问答落进策划节点自己的会话，Supervisor 上下文里什么都没有。问询改走「Runtime 直投」：策划节点提交结构化决策字段，Runtime 创建 **owner 为 Project Supervisor** 的 pending，会话消息落 Supervisor 会话、结构化 observation 落策划节点，二者是同一 `AgentRuntimeUserInputRecord` 的两路投影。Supervisor 的 Provider 不参与提问。 |
+| ~~D9~~ | **2026-08-13 二次作废**，由 D11 取代。原文：“取代 D6。立项策划是独立 `agentId` 的下游工作流节点，由 manifest ready-task 调度器在 Supervisor 下游启动，需登记 agentCatalog；Project Supervisor 以新的可信 source 承载「做方案」入口并保持唯一顶层 root；父子 run profile 必须同为 `standard`——不是为了复用顶层通道，而是因为 `autonomous-game-build` 对 `user.input_request` 的禁令按 profile 生效、父子皆不可提问，且子 Run 不能切换父 Run 的 profile。” 作废理由见第 1.1 节「D11 新拓扑」。**“立项策划是独立 `agentId` 的下游工作流节点”这一结论方向被 D11 继承**，但调度机制被 D11 推翻：不再由 manifest ready-task 调度器启动，改为 Project Supervisor 通过 `agent.delegate` 发起的静态委派子 Agent；「父子 run profile 必须同为 `standard`」这条论证随之失效——D11 拓扑下策划节点天然带 `parent_agent_id`/`parent_run_id`，其 `user.input_request` 直接被执行层 `validate_user_input_action_owner`（`user_input.rs:367-394`）拒绝，不再依赖“父子皆不可提问、子 Run 不能切换父 Run profile”这条 profile 层面的间接论证；「需登记 agentCatalog」被继承但登记方式生变，仍是待裁决项（见第 23 节）。 |
+| ~~D10~~ | **2026-08-13 作废**，由 D11 取代。原文：“策划节点**不得**直接调用 `user.input_request`——注意这不是 Runtime 拦得住的：standard ready-task 调度器不写 parent，该调用会被放行，因此必须由 exact allowlist 主动排除并以回归钉死。禁止的理由是产品约束：直接提问会把问答落进策划节点自己的会话，Supervisor 上下文里什么都没有。问询改走「Runtime 直投」：策划节点提交结构化决策字段，Runtime 创建 **owner 为 Project Supervisor** 的 pending，会话消息落 Supervisor 会话、结构化 observation 落策划节点，二者是同一 `AgentRuntimeUserInputRecord` 的两路投影。Supervisor 的 Provider 不参与提问。” 作废理由：D10 存在的唯一前提——「ready-task 节点无 parent，Runtime 拦不住，必须靠 exact allowlist 自律排除」——在 D11 新拓扑下不成立。策划节点改为委派子 Agent 后天然带 `parent_agent_id`/`parent_run_id`，`user.input_request` 被执行层 `validate_user_input_action_owner`（`user_input.rs:367-394`）直接拒绝，是 Runtime 兜底而非产品自律（但广告层仍放行，模型看得见、会去调，只是必失败，见第 19 节第 2 条改写）。「问询改走 Runtime 转发、Supervisor 会话与结构化 observation 两路投影」这一方向被 D11 继承，但落地机制不是同一套代码：D10 设想的是为 D9 拓扑新造的「Runtime 直投」，D11 复用的是 PR #165 已实现的 `AGC_NEEDS_USER_INPUT_V1` 终态信封 + Supervisor 中转链路，两者实现路径不同。 |
+| D11 | **取代 D9，并连带作废 D10。** 立项策划节点改为 Project Supervisor 通过 `agent.delegate` 发起的**静态委派子 Agent**（`agentId=project-planning`），不再由 ready-task 调度器启动；问询改为复用 PR #165 已实现的中转链路：子 Agent 以 `AGC_NEEDS_USER_INPUT_V1` 终态信封退出 → Supervisor 认领 → Supervisor 在自己的 runtime/session 上建 `waiting-for-user-input` pending → 用户在 Supervisor 会话内作答 → 答案经 `questionsSha256`/`answersSha256` 绑回 delivery → Supervisor 发起 continuation 子 Agent 续跑。**最多 3 轮问询依赖 WP1（澄清轮次与返工深度拆分，见第 1.1 节）先落地，是强制前置，不是并行工作包**；WP1 落地前上限只有 1 轮，且用掉后连一次质量返工都做不了。完整支撑事实（6 条，均带 `file:line`）见第 1.1 节「D11 新拓扑」；未决前置（`project-planning` 的 agentCatalog 登记方式与 `build.rs` 一致性校验）见第 23 节。 |
 
 ## 3. 合同名称注册表
 
@@ -233,6 +251,8 @@ plan source 对 Provider 可见且执行可通过的 action tool 恰好是：
 - `user.input_request`
 - `plan.submit_gdd`
 
+> **2026-08-13 按 D11 更正，避免与第 19 节第 2 条矛盾**：以上四工具清单是 D6/D9 时代「单一 plan source 自己直接持有 `user.input_request`」旧模型下的表述，本节其余段落仍待第 1.1 节批二随 `build.rs` 一致性裁决整体重写，但这一条必须先更正，不能放任两节结论互相冲突：**D11 现行拓扑下 `user.input_request` 不在策划子 Agent（`agentId=project-planning`）的工具面里**，也不依赖 exact allowlist 主动排除——委派子 Agent 天然带 `parent_agent_id`/`parent_run_id`，该调用被执行层 `validate_user_input_action_owner`（`user_input.rs:367-394`）直接兜底拒绝（广告层仍可见，模型会调但必失败，见第 19 节第 2 条）。Supervisor 根 run（新可信 source `project-supervisor-plan`）继续持有 `user.input_request`，但其 Provider 不用它直接向用户提问，而是在认领策划子 Agent 的 `AGC_NEEDS_USER_INPUT_V1` 终态信封后代为创建 pending。四工具清单中 `file.read`/`file.list`/`plan.submit_gdd` 三项，以及本节 exact allowlist、MCP 为空、collaboration 六类入口冻结等结构性约束方向不受此更正影响，具体归属哪一层（Supervisor 根 run 还是策划子 Agent）随第 1.1 节批二重写。
+
 `update_agent_plan` 与 `respond_to_user` 是 Runtime 协议控制函数，不计入“四个 action tool”，但仍受现有结构、轮次和终态门禁约束。plan source 的 MCP catalog 必须为空，Provider request 的 `webSearchEnabled` 固定为 false；广告层不得暴露其它 native action、内建搜索或 MCP，也不得只靠 Prompt 劝阻。执行 policy 必须按同一 durable source 再做 exact allowlist，伪造 tool call 一律拒绝。
 
 明确禁止：通用写入、patch/delete、command、process、preview、canvas、asset generation、确认型副作用、`agent.delegate`、`agent.route_manifest`、isolated child、任务图调度和所有 MCP 工具。
@@ -1424,7 +1444,7 @@ receipt 永远压过 stale pending：一旦该版本存在有效 receipt，pendi
 ## 19. 安全不变量与构建验证边界
 
 1. 不放松 `autonomous-game-build` 对 `user.input_request` 的现行禁等待防线；多轮策划只发生在 top-level standard plan run。
-2. **（2026-08-12 按 D9 拆写，取代原「plan source 四项工具、跳过 collaboration 强制委派」）** 做方案链路的工具边界分两层：**Supervisor 根 run** 以新可信 source 承载入口，工具面按现役 `standard` deny-list 模型，但其 Provider 不参与向用户提问（问询由 Runtime 直投创建 owner 为 Supervisor 的 pending）；**策划工作流节点**的 action 工具广告与执行双门都必须是 exact allowlist，MCP 为空，且**必须主动排除 `user.input_request`**——standard ready-task 节点无 parent，`validate_user_input_action_owner` 不会拦它，排除是产品约束的自律要求而非 Runtime 兜底，须以回归用例钉死；改以 `plan.request_decision` 提交结构化决策字段。原表述中的「跳过 Supervisor collaboration 强制委派」被直接反转——策划节点恰恰是被 Supervisor 调度的下游，具体清单待第 1.1 节批二随命名裁决落笔。
+2. **（2026-08-13 按 D11 二次拆写，取代 2026-08-12 按 D9 的拆写）** 做方案链路的工具边界分两层：**Supervisor 根 run** 以新可信 source `project-supervisor-plan` 承载入口，工具面按现役 `standard` deny-list 模型，其 Provider 不直接向用户提问，而是在认领策划子 Agent 的 `AGC_NEEDS_USER_INPUT_V1` 终态信封后，在自己的 runtime/session 上创建 `waiting-for-user-input` pending（复用 PR #165 中转链路，见第 1.1 节「D11 新拓扑」，不是 D9/D10 设想的「Runtime 直投」）；**策划子 Agent**（`agentId=project-planning`，由 Project Supervisor 通过 `agent.delegate` 静态委派，不再由 ready-task 调度器启动）的 action 工具广告与执行双门都必须是 exact allowlist，MCP 为空。**`user.input_request` 在此拓扑下由执行层 Runtime 兜底拒绝，不是产品自律要求**——委派子 Agent 天然带 `parent_agent_id`/`parent_run_id`，`validate_user_input_action_owner`（`apps/ai-game-creator-shell/src-tauri/src/user_input.rs:367-394`）在落盘 pending 之前直接判定失败并拒绝。但**广告层仍可见**：`build_agent_runtime_native_function_tools`（`apps/ai-game-creator-shell/src-tauri/src/agent_native_tools.rs:279`）没有 `agent_id` 参数、无法按身份裁剪；`standard` profile 下 `tool_policy_snapshot.rs:144-147`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/tool_policy_snapshot.rs`）仍无条件把 `user.input_request` 列入 `auto_tools`，模型看得见、会去调用，只是调用必然失败并转成一次失败的 tool observation。回归用例须同时钉死「执行层拒绝」与「广告层仍放行」这两半，不能只测其中一半就当作已覆盖。原 D10「排除是产品约束的自律要求而非 Runtime 兜底」的表述在新拓扑下已失效，见第 2 节 D10 作废条目。
 3. `.agent/planning/**` 与 `game/fast_gdd.md` 唯一写者是 Runtime；任何 Agent 通用写工具都不能触达。
 4. GDD、receipt 追加不可变；index、session、Markdown 和 UI 只作有限投影，不能反写权威事实。
 5. approve receipt 是构建信任根；Agent 文本、“已批准”状态缓存、Markdown 徽标或 UI 内存都无批准权。
@@ -1590,8 +1610,9 @@ D9 之后，root 是未变的 Project Supervisor，它在 `standard` 下天然
 **仍然保留的 M1 入口前置决策**：
 
 - **checkpoint handoff 私有持久化**——原有待裁决项，不受拓扑变更影响，继续保留。
-- **策划节点 `agentId` / source 命名**——新增，是第 1.1 节批二的共同阻塞点；同时需决定 Supervisor 侧新可信 source 是沿用 `project-supervisor-plan-chat` 字符串（历史示例字面不变但语义改变，易接错代码路径）还是取全新常量名（示例需全部重生成）。
-- **plan run 是否允许 steer**——`steering.rs` 的 steer 门按可信 source 判定，steer 替换协议会终止旧根并另起 replacement root run，与第 5.1 节的 session CAS、`roundsUsed` 与 `activeQuestion` 存在未验证交互，第 14 节恢复矩阵没有这条路径。新拓扑下还要额外确认：Supervisor 被 steer 时其下游策划节点如何收束。
+- ~~**策划节点 `agentId` / source 命名**~~——**2026-08-13 已裁决冻结**：策划子 Agent `agentId=project-planning`；Supervisor 侧承载「做方案」入口的新可信 source 取全新常量名 `project-supervisor-plan`（不沿用历史 `project-supervisor-plan-chat` 字面，避免语义改变后接错旧代码路径）。第 1.1 节批二不再被本项阻塞，改由下方新增的 `build.rs` 一致性待裁决项阻塞。
+- **plan run 是否允许 steer**——`steering.rs` 的 steer 门按可信 source 判定，steer 替换协议会终止旧根并另起 replacement root run，与第 5.1 节的 session CAS、`roundsUsed` 与 `activeQuestion` 存在未验证交互，第 14 节恢复矩阵没有这条路径。**D11 新拓扑下问题形态变化但未消解**：策划节点不再是 ready-task 工作流节点，而是 Supervisor 的委派子 Agent，与 game-chat 动态美术委派子 Agent 面临同一类「父 Supervisor 被 steer 时下游委派子 Agent 如何收束」问题（参见 2026-08-11 game-chat 动态美术 child 通用 retry 失败关闭的裁决，decision-log 同日条），但委派子 Agent 的收束机制（静态委派 delivery/claim 生命周期）与 ready-task 工作流节点的收束机制并不相同，不能直接照搬旧结论，需重新验证。
+- **`project-planning` 的编译期 agentCatalog 登记方式与 `build.rs` 一致性校验（2026-08-13 新增）**——`project-planning` 目前不在编译期 agentCatalog 里；`build.rs` 的 `validate_seed_task_catalog`（`apps/ai-game-creator-shell/src-tauri/build.rs:23-46`）要求编译出的 `(taskId, groupId, role)` 集合与 `shared_contracts::game_creation_app::new_game_creation_app_seed_tasks()` 完全相等，不等即 `panic!`。如何登记 `project-planning` 而不破坏这条一致性校验——是否需要 `new_game_creation_app_seed_tasks()` 新增一条不落入 16 任务 DAG 的独立条目，还是该一致性校验本身需要按「是否属于 16 任务 DAG」拆分——尚未裁决，是第 1.1 节批二（尤其第 3 节注册表）的新阻塞点，本文档只记录问题，不假装已有结论。
 
 ### 23.2 M0-3：统一 owner 产物验证与可玩验收边界（PR 工作包 `M0A-2`）
 
@@ -1630,7 +1651,7 @@ M0 完成不表示任何策划功能已上线。M1 的功能实现仍未开始
 - 不可变事实只增不改；其它内容都能从事实或 session checkpoint 有界恢复。
 - approvalRequestId 属于不可变 GDD，approval receipt 的 responseId 属于一次审批决定，两者都不可在重试中漂移；user-input answer/checkpoint 的同名 responseId 属于独立回答幂等域，不能跨域复用或恢复。
 - decisionFingerprint 解决意图幂等，receiptFingerprint 保护完整信任根。
-- **（2026-08-12 按 D9 拆写）** 策划工作流节点无 command/smoke/preview/再委派/MCP，其工具面是 exact allowlist 且不含 `user.input_request`；Supervisor 根 run 保持现役 `standard` 工具面并负责调度下游，但其 Provider 不参与向用户提问。内部 Markdown 投影不推进代码 revision。
+- **（2026-08-13 按 D11 二次拆写，取代 2026-08-12 按 D9 的拆写）** 策划子 Agent（`agentId=project-planning`，由 Supervisor 静态委派而非 ready-task 调度启动）无 command/smoke/preview/再委派/MCP，其工具面是 exact allowlist 且不含 `user.input_request`——该排除由执行层 `validate_user_input_action_owner` 兜底，广告层仍可见；Supervisor 根 run 保持现役 `standard` 工具面，其 Provider 不直接向用户提问，而是认领子 Agent 的 `AGC_NEEDS_USER_INPUT_V1` 终态信封后代为创建 pending（详见第 19 节第 2 条）。内部 Markdown 投影不推进代码 revision。
 - 用户侧只有一个对话对象；所有呈现给用户的对话内容必须物理存在于 Supervisor 的会话文件中，不得由前端把多个 Agent 的会话拼接成单一视图。
 - 前端只通过 `hydrate_game_creator_plan_gdd_state` 读取策划权威状态；文件、Markdown 和 runtime polling 不能在页面侧合成批准事实。
 - 完整构建只认后端在项目锁内重算并冻结的 approvedGddRef；直接开建必须显式声明，不能由缺字段降级。根 Run 被 steer 替换时，replacement root run 必须重新冻结同一 ref，不换稿、不降级、不留空窗。