文档：D11 条目同步 WP1 已落地，旧上限改为改造前对照

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

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

@@ -142,7 +142,7 @@ WP1 定稿的澄清轮次/返工深度语义（供 D11 依赖，权威定义见
 | D8 | GDD 不含引擎字段；平台事实固定由 Runtime 注入，Agent 不得向用户提问或修改。 |
 | ~~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」被继承但登记方式生变，登记机制已于 2026-08-13 定稿（见第 3.1 节与第 23.1 节），代码落地留给 M1。 |
 | ~~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` 一致性校验已于 2026-08-13 定稿（见第 3.1 节、第 23.1 节），代码落地留给 M1；M1 的真正前置是第 3.1 节新发现的 `prompt.rs` 角色身份合成缺口。 |
+| 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 节）先落地，是强制前置，不是并行工作包**；该前置已于 2026-08-13 落地并合入，现行上限为 3（完成状态与门禁见第 23.5 节）。作为改造前的对照记录：`WP1` 之前上限只有 1 轮，且用掉后连一次质量返工都做不了。完整支撑事实（6 条，均带 `file:line`）见第 1.1 节「D11 新拓扑」；`project-planning` 的 agentCatalog 登记方式与 `build.rs` 一致性校验已于 2026-08-13 定稿（见第 3.1 节、第 23.1 节），代码落地留给 M1；M1 的真正前置是第 3.1 节新发现的 `prompt.rs` 角色身份合成缺口。 |
 
 ## 3. 合同名称注册表
 
@@ -1628,7 +1628,7 @@ M0 文档 PR 本身最低验证：Markdown 结构与三张 Mermaid 图可解析
 | agent.db | `apps/ai-game-creator-shell/src-tauri/src/project/agent_db.rs:955-1034,1551-1605,1995-2088` | 普通 append 不满足 decision 幂等；新增专用保留入口 |
 | 16 任务 DAG | `server-rs/crates/shared-contracts/src/game_creation_app.rs:263-425` | 2026-08-12 复核 seed 仍是 16 个，M0/M1 不改拓扑；但固定 DAG 已不是完成语义的唯一来源，见下一行 |
 | standard 路径 owner 产物验证 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/autonomous_completion.rs:416-441` | 2026-08-12 复核：`autonomous_owner_artifact_validation_available_for_run_at` 四重绑死——owner agent 白名单、`profile == autonomous-game-build`、`source == agent-ready-task-scheduler`、**且要求 `parent_agent_id` 为 Project Supervisor**。standard ready-task 节点无 parent，第 436 行即不通过。做方案链路的 owner 产物验证必须**另建物理独立实现**，不能扩展该函数 |
-| 问询与直投 | `apps/ai-game-creator-shell/src-tauri/src/user_input.rs:367-394,494-530,595-623,803-807`、`apps/ai-game-creator-shell/src/App.tsx` 的 `handleProjectSupervisorUserInput`、`apps/ai-game-creator-shell/src/project/conversation.rs:42` | 2026-08-12 复核：`validate_user_input_action_owner` 拒绝任何带 parent 的 run；会话文件按 `agentId` 分目录，消息归属完全由 pending owner 决定；一份 record 已经两路投影（会话消息 + observation）且有「observation 重算冲突」校验。直投只需让两路投影分别落到 Supervisor 与策划节点，**前端可直接复用现有 Supervisor 问答通道** |
+| 问询与直投 | `apps/ai-game-creator-shell/src-tauri/src/user_input.rs:367-394,494-530,595-623,803-807`、`apps/ai-game-creator-shell/src/App.tsx` 的 `handleProjectSupervisorUserInput`、`apps/ai-game-creator-shell/src/project/conversation.rs:42` | 2026-08-12 复核：`validate_user_input_action_owner` 拒绝任何带 parent 的 run；会话文件按 `agentId` 分目录，消息归属完全由 pending owner 决定；一份 record 已经两路投影（会话消息 + observation）且有「observation 重算冲突」校验。直投只需让两路投影分别落到 Supervisor 与策划节点，**前端可直接复用现有 Supervisor 问答通道**。**2026-08-13 补记：本行「直投」是 D9/D10 旧机制记录，已被 D11 取代**（见第 1.1 节「D11 新拓扑」）——D11 不新造直投，改为复用 PR #165 已实现的 `AGC_NEEDS_USER_INPUT_V1` 终态信封 + Supervisor 中转链路；本行列出的 `validate_user_input_action_owner` 等机械证据本身仍成立，「前端复用现有问答通道」这一结论方向也不受影响，只是不再由「直投」这个已作废的机制名承载，本行未随批二重写，读者以第 1.1 节为准 |
 | Goal Contract / Acceptance Graph | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/goal_contract.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/acceptance_graph.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/tool_policy_snapshot.rs`（`agent_runtime_acceptance_evidence_tools`）、`apps/ai-game-creator-shell/src-tauri/prompts/runtime/supervisor/game-chat-routing.md` | 2026-08-11 合入。可信根 Supervisor 必须先冻结 Goal Contract 才能路由，验收图未确认则完成门 blocked；合同按 `.agent/runtime/goal-contracts/{rootAgent}/{rootRun}.json` 分 root run 存放并绑定 binding fingerprint 与 source SHA-256。M1 见第 23.1 节待裁决项，M2 见第 16.1/16.2 节，M3 见第 17 节 |
 | design-director 现状 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/autonomous_completion.rs:70-85`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/task_start.rs:1480-1506` | mutation owner 清单不含 design-director，因此当前落入只读协调 Prompt；M2 才确定性化 |
 | scheduler delivery | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_tools/delivery.rs:171-185` | 下游不能依赖普通 durable delivery，必须读权威文件/ref |
@@ -1688,6 +1688,7 @@ D9 之后，root 是未变的 Project Supervisor，它在 `standard` 下天然
 **仍然保留的 M1 入口前置决策**：
 
 - **checkpoint handoff 私有持久化**——原有待裁决项，不受拓扑变更影响，继续保留。
+- **plan source 与 Goal Contract 协议的关系**——2026-08-12 新增待裁决项，继续保留，**未被上方「2026-08-12 替换结论」解决**。上方三条约束只处置了「策划 run 是否需要豁免 root」这一支（四方案的共同前提），给出的是候选设计方向；但 decision-log 2026-08-12 条「M0 全部完成，并据动态目标验收图收敛 M2/M3 设计」逐字记录的裁决状态仍是「保留待裁决」「裁决冻结前，依赖 plan source 可信身份的 M1 代码不得合入」，且该记录未被任何后续 decision-log 条目覆盖或撤销。本文档此前在本小节未把它列入「仍然保留」，与第 23.4 节、第 23.6 节的表述相冲突（2026-08-13 对抗性复核补记并订正为一致口径）——按最保守口径，本项在正式裁决（decision-log 新条目）冻结前一律按待裁决处理。
 - ~~**策划节点 `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 机制已定稿**（见第 3.1 节）：`project-planning` 在 `agentCatalog` 下登记为与 `supervisor` 平级、不进 `groups` 数组的独立条目，`specialist_nodes` 只读 `manifest.agent_catalog.groups[].roles[]`（`build_support/runtime_prompt_bundle.rs:387-398`），因此 `build.rs` 的 `validate_seed_task_catalog`（`apps/ai-game-creator-shell/src-tauri/build.rs:23-46`）、16 任务种子 DAG、`new_game_creation_app_seed_tasks()` 均不需要改动。批二不再被 catalog 一致性问题阻塞；但登记机制定稿过程中查实了一个新的、真正的**待裁决/待处置项**（不是同一个问题的延续，是第 3.1 节调研发现的独立缺口）：`prompt.rs` 的 `game_creator_agent_role_definition`（`apps/ai-game-creator-shell/src-tauri/src/agent/prompt.rs:661-679`）是把 `agent_id` 合成出角色身份的唯一函数，目前硬编码「非 `project-supervisor` 即 group 角色」的二分，`project-planning` 落入 else 分支会返回 `None`，其两个调用方（`provider_request_builders.rs:536-539`、`prompt.rs:416-417`）都会把 `None` 转成 `Err` 中断执行，报「未知 Agent 模板：project-planning」。也就是说**仅做 catalog 登记不足以让 D11 的静态委派可执行**，还需要在 `game_creator_agent_role_definition` 里补一个平行于 supervisor 特判的 `project-planning` 分支——这是 M1 落地范围，第 3.1 节已列出完整改动清单（含另外两处 needs_change：`task_ops.rs` 的 group/role 兜底误分类、`delegation.rs` 的 `agent.spawn_isolated` 放行面），本文档不再假装这只是「登记方式未裁决」，而是明确记录为「机制已定稿、代码待 M1 落地」。