文档：裁决 plan source 进可信 matcher，验收图取自固定 Fast GDD 合格标准

裁决一：project-supervisor-plan 进 agent_runtime_supervisor_source_is_trusted，
做方案链路正常参与 Goal Contract 协议。原阻塞理由（策划 Agent 无证据工具、
必然留下永不 passed 的节点）写于 D6/D9 拓扑，D11 拆两层后失效：策划子 Agent 的
allowlist 含 file.read/file.list，且 validate_acceptance_evidence_identity_at 只要求
证据属于同一根任务树、不要求是根 Agent 自己的回执。原「依赖 plan source 可信身份
的 M1 代码不得合入」硬门解除。落地前须逐点复核该 matcher 约 19 处消费点。

裁决二：验收图取自固定的 Fast GDD 合格标准，不由 Supervisor 每轮自由发挥。
GDD 是否合格与它描述的是什么游戏无关，因此「验收标准须在产物不存在的 turn 1
冻结且不可改」不构成矛盾。plan.submit_gdd 的 strict schema 承担字段与约束硬校验；
Goal Contract 验收图承担「产物确实服务了本次意图」。Goal Contract 中按项目变化的
只有 outcome/nonNegotiables/forbiddenAssumptions/openQuestions 四项。
不改变 D1（支柱 2～4 条按项目生成）与 D8（不含引擎字段）已冻结的口径。

同批更正第 4.3 节一处失真：此前称「Supervisor 不得自行提问」靠机制保证，实为
不成立——该校验唯一生产调用点外层套着 run_profile == autonomous-game-build，
做方案链路跑 standard，不触发。改为如实记录为产品约束、缺机制兜底。

M1 入口前置决策至此剩 checkpoint handoff 私有持久化一项。

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

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

@@ -1,5 +1,16 @@
 # 决策记录
 
+## 2026-08-13 plan source 进可信 matcher；做方案验收图取自固定 Fast GDD 合格标准
+
+- 裁决一：`project-supervisor-plan` **进** `agent_runtime_supervisor_source_is_trusted`（`agent/runtime_driver.rs:113`），做方案链路正常参与 Goal Contract 协议，不做豁免。2026-08-12 条记录的硬门「裁决冻结前，依赖 plan source 可信身份的 M1 代码不得合入」随本条解除。
+- 原阻塞理由已失效：2026-08-12 排除该方向的依据是「策划 Agent 按设计一项证据工具都不该有，必然留下永不 passed 的节点」。该推理写于 D6/D9 拓扑（当时 plan run 就是策划 Agent 本身）。D11 拆成两层后两个前提都不成立：① 策划子 Agent 的 exact allowlist 恰好含 `file.read`/`file.list`，均在 `agent_runtime_acceptance_evidence_tools()` 白名单内；② 更根本的是证据不必由它出——`validate_acceptance_evidence_identity_at`（`agent/runtime_protocol/acceptance_graph.rs:152`）对证据来源只要求 `binding.root_agent_id/root_run_id` 等于合同的根，**不要求是根 Agent 自己的回执**，而委派子 Agent 的 binding 根就是 Supervisor。
+- 入口门不是阻塞，只是时序：合同不存在时本轮必须且只能是一个 `agent.goal_contract`，故 turn 1 冻结合同、turn 2 才发委派，代价是多一次 Provider 调用。
+- 落地前必须补的功课：该 matcher 约 19 处生产消费点，同时承担 run 启动门、steer 门、Goal Contract 创建权限、根控制面工具授权与验收图完成门等多种语义。本裁决只确定「plan 进入 matcher」，不等于每个消费点对 plan 语义都正确，M1 落地前须逐点复核并对不适用者单独收窄。steer 门已由同日裁决单独否决，且要求实现为独立于本 matcher 的显式否决。
+- 裁决二：做方案链路的验收图**取自固定的 Fast GDD 合格标准，不由 Supervisor 每轮自由发挥**。理由：GDD 是否合格与它描述的是什么游戏无关——变的是游戏概念，不变的是字段与字段约束。因此「验收标准必须在产物不存在的 turn 1 冻结且不可改」不构成矛盾。分工：`plan.submit_gdd` 的 strict schema 承担机器可判的字段存在性与约束（硬校验）；Goal Contract 验收图承担「产物确实服务了用户这次的意图」，由 Supervisor 以 `tool:file.read` 对 `game/fast_gdd.md` 取证后确认。Goal Contract 中按项目变化的只有 `outcome`/`nonNegotiables`/`forbiddenAssumptions`/`openQuestions` 四项，`acceptanceNodes` 近乎固定——这不算入口门 Prompt 所禁的「照抄固定信号代替理解」，因为「什么算一份合格 GDD」本就不是本轮要理解的东西。
+- 本条不改变 D1（游戏支柱按项目生成 2～4 条）与 D8（GDD 不含引擎字段）已冻结的口径。
+- 同批更正一处失真表述：技术方案第 4.3 节此前称「Supervisor 不得自行发起策划性提问」这一条「靠机制保证」。经核实不成立——做该校验的 `static_delegate_clarification_pending_matches_delivery_at` 全仓库唯一生产调用点（`agent/runtime_driver/pending_recovery.rs:791`）外层套着 `run_profile == autonomous-game-build`，而做方案链路跑 `standard`，校验不触发。该链路上 Supervisor 既可自行提问也可改写子 Agent 问题原文，Runtime 都不拦。这是产品约束不是机制约束；要变成机制约束须为 standard 下的 plan 根 run 单独接一道等价校验，属 M1 范围。
+- M1 入口前置决策至此剩一项：checkpoint handoff 私有持久化。
+
 ## 2026-08-13 立项策划 plan 根 run 不允许 steer
 
 - 裁决：plan 根 run（`source=project-supervisor-plan`）**不接受 steer 替换协议**。原「plan run 是否允许 steer」待裁决项就此关闭。

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

@@ -347,7 +347,9 @@ M1 不能把新 source 直接塞进一个被 autonomous 语义复用的总 match
 
 工具面按现役 `standard` deny-list 模型，不改为 allow-list。它需要且必须持有：`agent.delegate`（发起与续跑策划委派，这是做方案链路的主动作）、`user.input_request`（代策划子 Agent 向用户提问）、以及现役 standard Supervisor 既有的读取与审批相关能力。
 
-关键约束不是「不许持有」，而是「持有但不得这样用」：**其 Provider 不得自行发起策划性提问**。`user.input_request` 的合法用法只有一种——认领策划子 Agent 的 `AGC_NEEDS_USER_INPUT_V1` 终态信封后代为创建 pending，且问题正文必须与信封逐字一致（由 `static_delegate_clarification_pending_matches_delivery_at` 做结构相等 + `questionsSha256` 双重校验，Supervisor 改不了子 Agent 的问题原文）。这一条靠机制保证，不靠 Prompt 劝阻。
+关键约束不是「不许持有」，而是「持有但不得这样用」：**其 Provider 不得自行发起策划性提问**。`user.input_request` 的合法用法只有一种——认领策划子 Agent 的 `AGC_NEEDS_USER_INPUT_V1` 终态信封后代为创建 pending，且问题正文应与信封逐字一致。
+
+> **2026-08-13 更正（此前本节声称该约束「靠机制保证，不靠 Prompt 劝阻」，该说法不成立）**：做校验的 `static_delegate_clarification_pending_matches_delivery_at`（结构相等 + `questionsSha256`）全仓库只有一个生产调用点——`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/pending_recovery.rs:791`，而它外层套着 `runtime.run_profile == AGENT_RUNTIME_RUN_PROFILE_AUTONOMOUS_GAME_BUILD`。做方案链路跑的是 `standard`，**该校验根本不触发**。因此在本链路上：Supervisor 既可以自行发起提问，也可以改写子 Agent 的问题原文再问，Runtime 都不拦（`validate_user_input_action_owner` 只拦有 parent 的 Agent，根 Supervisor 不在其列）。这是**产品约束，不是机制约束**，目前只有 Prompt 兜底。若要把它变成机制约束，须为 `standard` 下的 plan 根 run 单独接一道等价校验——属 M1 范围，本文档不假装它已存在。
 
 **第二层：策划子 Agent（`agentId=project-planning`，`source=agent-delegate`）**
 
@@ -1705,7 +1707,7 @@ M0A-1 是 M1 详细设计与技术 spike 的输入，不是功能交付。M1 可
 
 > **⚠️ 以下四方案分析已于 2026-08-12 随 D6 作废，保留仅作推导记录，不再是待裁决项。** 四方案的共同前提是「策划 run 自己就是那个需要豁免的 root `project-supervisor` run」；D9 之后 root 是未变的 Supervisor，策划是独立 `agentId` 的下游节点，四选一问题消解（方案 D 的方向被 D9 实质采纳）。**现行结论见本小节末尾「2026-08-12 替换结论」与第 1.1 节。** 其中方案 C 不可行的论证（验收图强制 required 节点 + evidence 必须命中 18 项工具集）仍然有效，是理解第 1.1 节第 2 条约束的背景。
 
-2026-08-12 新增第二项 M1 合入前置决策：**plan source 与 Goal Contract 协议的关系**。
+2026-08-12 新增第二项 M1 合入前置决策：**plan source 与 Goal Contract 协议的关系**。（**2026-08-13 已裁决关闭**：`project-supervisor-plan` 进可信 matcher、正常参与 Goal Contract 协议，原阻塞理由随 D11 拓扑失效；详见本节下方「仍然保留的 M1 入口前置决策」中该条。以下段落保留作推导记录。）
 
 冲突的根源不是某处判据写错，而是两套工具模型不兼容。现行是 **deny-list 模型**：`agent_runtime_tool_policy_snapshot_at` 的 `allowed_tools` 直接等于全量 `agent_runtime_executable_tools()`，`agent.goal_contract` 天然在内，`standard` profile 在 `agent_runtime_tool_policy_snapshot_for_run_at` 里更是提前返回、不做任何裁剪；`provider_request_builders.rs` 只对 `!root_control_authority && goal_contract_participant` 的后代做剔除。因此现役可信 root Supervisor（gui / cli / game-chat）**默认就持有**这个工具，两道门对它们是「照着做」。而 M1 是第一个 **allow-list 模型**的 source（第 4.3 节 exact allowlist），Goal Contract 协议隐含的「root Supervisor 一定持有 `agent.goal_contract`」前提对它不成立。
 
@@ -1740,7 +1742,22 @@ 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 新条目）冻结前一律按待裁决处理。
+- ~~**plan source 与 Goal Contract 协议的关系**~~——**2026-08-13 已裁决**：`project-supervisor-plan` **进** `agent_runtime_supervisor_source_is_trusted`；做方案链路正常参与 Goal Contract 协议，不做豁免。原「裁决冻结前依赖 plan source 可信身份的 M1 代码不得合入」的硬门随本裁决解除。
+
+  *原阻塞理由已失效*：2026-08-12 排除该方向的依据是「出口门在验收阶段照卡且更难救——合同强制至少一个带 `requiredEvidence` 的 required 节点，而**策划 Agent 按设计一项证据工具都不该有**，`.agent/planning/**` 由 Runtime 写、不产生 Agent 回执，必然留下永不 `passed` 的节点」。该推理写于 D6/D9 拓扑，当时「plan run」就是策划 Agent 本身。D11 拆成两层后两个前提都不成立：① 策划子 Agent 的 exact allowlist 恰好含 `file.read` / `file.list`，二者都在 `agent_runtime_acceptance_evidence_tools()` 白名单内；② 更根本的是证据**不必由它出**——`validate_acceptance_evidence_identity_at`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/acceptance_graph.rs:152`）对证据来源的唯一要求是 `binding.root_agent_id/root_run_id` 等于合同的根，**不要求是根 Agent 自己的回执**；委派子 Agent 的 binding 根就是 Supervisor，因此两层的 `file.read` 回执都是合法验收证据。
+
+  *三道门逐一可满足*：入口门只规定时序——合同不存在时本轮必须且只能是一个 `agent.goal_contract`，因此做方案链路的 turn 1 冻结合同、turn 2 才发委派，多一次 Provider 调用而已，不是阻塞；内容门要求 ≥1 个 required 节点且 `requiredEvidence` 命中白名单，`tool:file.read` 满足；出口门要求合同已冻结且验收图收敛，两者都能达成。
+
+  *落地前必须补的功课*：`agent_runtime_supervisor_source_is_trusted` 现有约 19 处生产消费点，同时承担 run 启动门、steer 门、Goal Contract 创建权限、根控制面工具授权与验收图完成门等多种语义。本裁决只确定「plan 进入该 matcher」，**不等于每个消费点对 plan 的语义都正确**——M1 落地前须逐点复核，凡语义不适用的必须单独收窄，而不是靠 matcher 一刀切。其中 steer 门已由同日「plan 根 run 不允许 steer」裁决单独否决，且明确要求实现为独立于本 matcher 的显式否决。
+
+- **做方案链路的验收图取自固定的 Fast GDD 合格标准，不由 Supervisor 每轮自由发挥**（2026-08-13 同批裁决）。理由：一份 GDD 是否合格与它描述的是什么游戏**无关**——变的是游戏概念，不变的是「要有哪些字段、每个字段什么约束」。因此「验收标准必须在产物不存在的 turn 1 冻结且不可改」不构成矛盾。分工固定为：
+
+  - **`plan.submit_gdd` 的 strict schema** 承担机器可判的字段存在性与字段约束（`oneLiner` 长度、`pillars` 条数、MVP 系统条数等，见第 8.2 / 8.3 节），这是硬校验；
+  - **Goal Contract 验收图**承担「产物确实服务了用户这次的意图」，由 Supervisor 以 `tool:file.read` 对 `game/fast_gdd.md` 取证后确认节点。
+
+  Goal Contract 中**按项目变化**的只有 `outcome` / `nonNegotiables` / `forbiddenAssumptions` / `openQuestions` 四项——它们承载入口门 Prompt 要求的「自行理解用户真正要做的事」；`acceptanceNodes` 近乎固定，不算「照抄固定信号代替理解」，因为「什么算一份合格 GDD」本就不是本轮需要理解的东西。
+
+  本条**不改变** D1（游戏支柱按项目生成 2～4 条，四个候选不固定套用）与 D8（GDD 不含引擎字段，平台事实由 Runtime 注入）已冻结的口径；验收图据以生成的合格标准以本文档第 5.3、8.2、8.3 节为准。
 - ~~**策划节点 `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**~~——**2026-08-13 已裁决：不允许。** plan 根 run 不接受 steer 替换协议。
 
@@ -1777,7 +1794,7 @@ M0 收口时的三项已知残留，均已定性且不阻塞后续阶段：
 
 - 第 23.3 节记录的 manifest 新鲜度残余风险，只记录不实现，回归用例中的断言即裁决锚点。
 - `set_task_status` 无秩序守卫的无条件覆盖，属 master 既有问题，另行提 issue，不在 M0 范围内修。
-- 第 23.1 节两项 M1 入口前置决策（checkpoint handoff 私有持久化、plan source 与 Goal Contract 协议的关系）保持待裁决；它们是 M1 的合入门，不是 M0 的完成门。
+- 第 23.1 节的 M1 入口前置决策：**2026-08-13 后只剩 checkpoint handoff 私有持久化一项待裁决**（「plan source 与 Goal Contract 协议的关系」已裁决为进可信 matcher，「plan run 是否允许 steer」已裁决为不允许）。它是 M1 的合入门，不是 M0 的完成门。
 
 M0 完成不表示任何策划功能已上线。M1 的功能实现仍未开始，第 19 节第 2 条等 plan source 不变量目前只是设计意图。
 
@@ -1833,7 +1850,9 @@ M0 完成不表示任何策划功能已上线。M1 的功能实现仍未开始
 
 *一、身份可执行性缺口*（第 3.1 节「登记前必须先处理的代码改动」，仅 catalog 登记不足以让静态委派跑起来）——其中角色身份合成缺口为 blocking，另有若干 needs_change 项与一条既有测试的期望集合需同步更新。清单以第 3.1 节为准，本节不重复。
 
-*二、既有待裁决项*（第 23.1 节）——checkpoint handoff 私有持久化；plan source 与 Goal Contract 协议的关系。二者是 M1 的合入门，不是 M0 或本节前三步的完成门。其中后者带硬门：**裁决冻结前，依赖 plan source 可信身份的 M1 代码不得合入**（2026-08-13 已合入的 `project-planning` 身份登记不触碰该门——它登记的是子 Agent 的 `agentId`，未引入 `project-supervisor-plan` 这个 source）。原第三项「plan run 是否允许 steer」已于 2026-08-13 裁决为**不允许**，不再是待裁决项。
+*二、既有待裁决项*（第 23.1 节）——**只剩 `checkpoint handoff` 私有持久化一项**，它是 M1 的合入门，不是 M0 或本节前三步的完成门。另两项已于 2026-08-13 关闭：「plan run 是否允许 steer」裁决为**不允许**；「plan source 与 Goal Contract 协议的关系」裁决为 `project-supervisor-plan` **进**可信 matcher、正常参与 Goal Contract 协议，原「依赖 plan source 可信身份的 M1 代码不得合入」硬门随之解除。
+
+后者虽已裁决，但留下一项**落地前必须完成的复核**（不是待裁决，是待执行）：`agent_runtime_supervisor_source_is_trusted` 的约 19 处生产消费点须逐点确认对 plan 语义正确，不适用者单独收窄；这项复核连同第 4.3 节记录的「Supervisor 自行提问目前只有 Prompt 兜底、缺机制约束」一并属 M1 范围。
 
 以下为已识别但**明确后置**、不阻塞上述任何一步的工作项：