文档：补记 D11 新拓扑与静态委派澄清轮次/返工深度拆分（WP1）决策

新增 2026-08-13 决策记录条目：
- D9 二次作废、D10 作废，立项策划改为 Project Supervisor 静态委派子 Agent（D11），复用 PR #165 澄清中转链路，命名裁决冻结（agentId=project-planning，source=project-supervisor-plan）。
- WP1：clarification_round 与 repair_depth 两个运行时派生维度拆分定稿——分类判据、传播规则（澄清跳不重置 depth、返工跳重置 round）、上限按 source 区分（game-chat 取 1，其余取 3）、总跳数上界 1+(1+1)x3=7 跳/8 条 delivery 记录的推导（并说明常见漏算为 6 的原因）、以及不得新增持久字段（fail-open 风险）与最脆弱回归点（返工跳漏掉 depth+1）。
- 推翻 2026-08-12"子 Agent 澄清回执由 Supervisor 中转（Issue #163）"条中"随后最多创建一次 continuation"的结论。
- 记录新增待裁决项：project-planning 的编译期 agentCatalog 登记方式与 build.rs 一致性校验。

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

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

@@ -1,5 +1,29 @@
 # 决策记录
 
+## 2026-08-13 立项策划 D9 二次作废、D10 作废：改为 Supervisor 静态委派子 Agent（D11）；静态委派澄清轮次与返工深度拆分定稿（WP1）
+
+- 背景：产品侧确认「做方案」入口不需要新增编排调度器概念，复用已有静态委派（`agent.delegate`）与 PR #165 已实现的子 Agent 澄清中转链路即可覆盖 D9/D10 试图解决的问题；同时实证发现静态委派返工深度门（`repair_of_delegation_id.is_some()` 即拒绝）对「质量返工」与「澄清 continuation」无差别拒绝，一次澄清会吃掉整条链唯一一次质量返工额度。两条问题合并处置。
+- 事实基线（均已逐处打开源码或测试核对，详见技术方案 `docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md` 第 1.1 节「D11 新拓扑」）：
+  - `delegation.rs:1119-1121` 的返工深度门对「质量返工」与「澄清 continuation」无差别拒绝；`apps/ai-game-creator-shell/src-tauri/src/tests/collaboration/static_deliveries.rs` 的 `clarification_continuation_chain_supports_multiple_rounds` 走真实 `observe_agent_runtime_agent_delegate` 生产路径证明：D1→D2 成功、D2→D3 被拒、D3 从未落盘。
+  - 委派子 Agent 天然带 `parent_agent_id`/`parent_run_id`，`user.input_request` 被执行层 `validate_user_input_action_owner`（`user_input.rs:367-394`）在落盘 pending 之前直接拒绝；但广告层不拦——`build_agent_runtime_native_function_tools`（`agent_native_tools.rs:279`）无 `agent_id` 参数，`standard` profile 下 `tool_policy_snapshot.rs:144-147` 仍把它列为 auto tool，模型看得见、会去调，只是必失败并转成一次失败的 tool observation。
+  - 委派子 Agent 的 `target_session_id` 每轮解析为同一条持久 active session（`resolve_agent_conversation_session_id_at` 传 `None` 时走 `catalog.active_session_id`，`project/conversation.rs:849-852`），prompt history 按 `(agent_id, session_id)` 组装（`context_compaction.rs:453-490`，`run_id` 只用于 observation 覆盖计数），故 continuation 子 Agent 是「新 run、同 session」，不失忆；但用户答案物理落在 Supervisor 会话，子 Agent 只能靠 Supervisor 转述，Runtime 只校验 `questionsSha256`/`answersSha256` 哈希绑定，不校验转述内容与已确认答案的语义一致性。
+  - `normalize_static_delegate_expected_artifact`（`delegation.rs:1981-1998`）拒绝首段为 `.agent` 的路径，`.agent/planning/**` 在委派发起阶段天然进不来，不需要文档层自律约束；`game/fast_gdd.md` 不受影响，定稿 `expectedArtifacts=["game/fast_gdd.md"]` + `acceptanceCriteria` 承载质性标准，`verification_required=false`。
+  - `project-planning` 目前不在编译期 agentCatalog 里；`build.rs` 的 `validate_seed_task_catalog`（`build.rs:23-46`）要求编译出的 `(taskId, groupId, role)` 集合与 `new_game_creation_app_seed_tasks()` 完全相等，不等即 `panic!`。
+- 决策（D11，取代 D9，连带作废 D10）：立项策划节点改为 Project Supervisor 通过 `agent.delegate` 发起的**静态委派子 Agent**（`agentId=project-planning`），不再由 manifest 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 续跑。命名裁决同时冻结：`agentId=project-planning`，Supervisor 侧新可信 source 为 `project-supervisor-plan`（不沿用旧预留字符串 `project-supervisor-plan-chat`）。
+- D9「立项策划是独立 `agentId` 的下游工作流节点」这一结论方向被 D11 继承，但调度机制被推翻——不再由 ready-task 调度器启动。D10「问询改走 Runtime 转发、两路投影」这一方向也被继承，但落地机制不同：D10 设想的是为 D9 拓扑新造的「直投」，D11 复用的是已经上线的 PR #165 链路，两者不是同一套代码。D10「exact allowlist 主动排除 `user.input_request`」这条论证在 D11 下失效：委派子 Agent 的 `user.input_request` 由执行层 `validate_user_input_action_owner` 兜底拒绝，是 Runtime 机制而非产品自律（但广告层仍放行，须与执行层拒绝一并回归钉死，不能只测一半）。
+- **推翻 2026-08-12「子 Agent 澄清回执由 Supervisor 中转（Issue #163）」决策记录中「随后最多创建一次绑定原 `delegationId` 的 continuation child」这一条**（该决策落地为 PR #165，对应本文件本条目下方原文见该日期条目）。实证（`clarification_continuation_chain_supports_multiple_rounds`）证明该限制来自返工深度门的误伤，不是有意设计；该条自本决策起作废，continuation 允许的次数改按下方 WP1 定稿的 `clarification_round` 语义执行，不再是「最多一次」。
+- 决策（WP1，静态委派澄清轮次与返工深度拆分）：
+  - 两个维度独立，且都是**运行时派生值，不落盘**：`repair_depth` 上限维持 1（不放松）；`clarification_round` 上限按 source 区分。
+  - **分类判据（唯一权威）**：`parent.structured_result.contract_status == NeedsUserInput` ⇔ 这一跳是澄清 continuation；否则是质量返工。
+  - **传播规则**：根节点（`repair_of` 为 `None`）`depth=0, round=0`；澄清跳 `round=parent.round+1, depth=parent.depth`（**不重置返工深度**，否则可插一次澄清洗掉返工深度、变成无限返工）；返工跳 `depth=parent.depth+1, round=0`（**重置澄清轮次**，因为返工后策划节点重新开工，不能因返工吃掉预设的 3 轮问询预算）。
+  - **上限按 source 区分**：`source == AGENT_RUNTIME_SUPERVISOR_GAME_CHAT_SOURCE`（`agent/runtime_driver.rs:109`，值 `project-supervisor-game-chat`）时 `clarification_round` 上限取 1；其它 source（含 D11 的 `project-planning` 委派链）取 3。理由：诉求只来自策划节点，game-chat 定位单主路径零打扰，PR #165 从未承诺给它 3 轮预算，不应顺带放宽一个未评估的场景。仓库已有同款 source 分支先例：`delegation.rs:295-315` 的 `may_be_game_chat` 判定、`validate_game_chat_main_art_delegation_at`（均在 `agent/runtime_tools/delegation.rs`）。
+  - **总跳数上界推导**：`repair_depth` 上限 1 意味着链上有 `repair_depth_max + 1 = 2` 个「深度段」，每段各自最多 `clarification_round_max = 3` 次澄清跳，另加 `repair_depth_max = 1` 次返工跳本身。故总跳数上界 = `repair_depth_max + (repair_depth_max + 1) × clarification_round_max = 1 + 2 × 3 = 7` 跳，加根节点共 **8 条 delivery 记录**。**注意是 7 不是 6**——容易漏算的是「连接两层的返工跳本身也算一跳」，只算两段澄清跳（`2 × 3 = 6`）会漏掉这一跳。
+  - **不得新增持久字段**：给 `StaticDelegateDeliveryRecord` 加 `repair_depth` 字段并用 `#[serde(default)]` 兜底，会让磁盘上已有的返工记录读出 `0`，深度门失效，`tests/collaboration/static_deliveries.rs:977-988` 钉的「返工的返工」漏洞原样复活。方向是 **fail-open，不可接受**。必须改用**链上推断**：每次校验时沿 `repair_of_delegation_id` 向上重放整条链现算。链上推断对历史记录是精确而非仅保守的：PR #165 之前不存在 `NeedsUserInput`，老记录天然被正确分类为「非澄清」，不会误判。
+  - **最脆弱的回归点**：不是「澄清跳误把 `depth` 清零」（已被设计明确防着），而是**「返工跳漏掉 `depth+1`」**——现有测试要么纯返工链、要么纯澄清链，从未覆盖交替链，若实现写成「有 parent 就继承 `depth`」这种自然默认，`depth` 会永远停在 0，无限乒乓原样重开，而两条现有测试全绿。回归矩阵必须新增一条交替链用例（澄清→返工→澄清→返工…）专门钉死这一路径。
+- M0/M1 影响：D11 依赖 WP1 先落地才能生效——WP1 正在另一个 worktree 并行实现，是 D11 的**强制前置**，不是并行工作包；WP1 落地前，D11 描述的「最多 3 轮问询」实际上限仍是 1 轮，且用掉后连一次质量返工都做不了。
+- 保留待裁决：`project-planning` 的编译期 agentCatalog 登记方式与 `build.rs` 一致性校验（新增，见上）；checkpoint handoff 私有持久化（原有项，不受影响）；plan run 是否允许 steer，以及 Supervisor 被 steer 时下游委派子 Agent 如何收束（问题形态随 D11 从「ready-task 工作流节点」变为「委派子 Agent」，与 game-chat 动态美术委派子 Agent 面临同类问题，但收束机制不同，不能直接照搬 2026-08-11 的 game-chat 裁决）。
+- 关联文档：`docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md`；关联决策：本文件 2026-08-12「立项策划 D6 作废」条、2026-08-12「子 Agent 澄清回执由 Supervisor 中转（Issue #163）」条（其「最多创建一次 continuation」结论已被本条推翻）。
+
 ## 2026-08-12 Repository checks 采用 CI 与本地共用的单一门禁入口
 
 - 背景：master run 1037 的 Backend/Frontend 已通过，但 `Repository checks` 因 3 个 `simple-import-sort/imports` 错误失败。原 pre-commit 只运行 Prettier，Prettier 不处理 ESLint import 排序；推送前又未运行完整仓库 lint，因此本地与 CI 的覆盖范围长期存在漂移。