diff --git a/docs/project-memory/shared-memory/decision-log.md b/docs/project-memory/shared-memory/decision-log.md
index 78b37aae6..8054ae067 100644
--- a/docs/project-memory/shared-memory/decision-log.md
+++ b/docs/project-memory/shared-memory/decision-log.md
@@ -9,7 +9,7 @@
 - M2 裁决一：确定性收束与 Runtime 内部产物验证**都不构成验收证据**。`design-director` 确定性化后不产生 Provider 回执，M0-3 的内部 owner 验证同样不产生；而 passed 节点必须引用真实成功动作回执且 `requiredEvidence` 须命中 `agent_runtime_acceptance_evidence_tools()`。涉及 GDD 落地的验收标准要么由根 Supervisor 用允许的证据工具自行取证，要么不写成 required 节点。**不得**为使确定性节点可验收而把内部验证工具暴露给 Provider——那会推翻 M0-3 已冻结的 owner 验证边界。
 - M2 裁决二：planning baseline 不是「一次冻结永久有效」。steer 替换协议会终止旧根树并另起 replacement root run，该 run 必须在自己的锁/CAS 边界内重新冻结与被替换根**完全相同**的 `approvedGddRef`，即使期间已有更新的 approved 版本也不换稿；无法证明同一 ref 时失败关闭，不得降级为 `mode=direct-build`。
 - M2 附带证据：Goal Contract 落在 `.agent/runtime/goal-contracts/{rootAgent}/{rootRun}.json`，按 root run 分文件并绑定 binding fingerprint 与 source SHA-256。这是「自带 root/run 身份」的正面先例，D4 关于 `approvedGddRef` 是否进 manifest 的决策应参照此形态，而非项目级单例。
-- 保留待裁决：**plan source 与 Goal Contract 协议的关系**（M1 入口前置，与 checkpoint handoff 私有持久化决策并列）。根源是两套工具模型不兼容：现行 deny-list 模型下 `allowed_tools` 直接等于全量执行工具目录，可信 root Supervisor 默认持有 `agent.goal_contract`，两道门对现役 gui/cli/game-chat 是「照着做」；plan source 是首个 allow-list 模型的 source，不持有该工具。卡点是两道**互相独立**的门：入口门 `validate_root_goal_contract_control_plan_at` 在通用 tool-plan 解析路径上强制「合同不存在时本轮必须是唯一的 `agent.goal_contract` 动作」，判据既不看 source 也不看 Run Profile；出口门 `goal_contract_acceptance_completion_blocker_at_locked` 判据含可信 source，未冻结合同即完成门永久 blocked。四方案与代价见技术方案第 23.1 节，其中「plan root 改用独立 `agentId`」是唯一一次性解耦三处判据的方案，但会推翻第 4.1 节已冻结的 `agentId=project-supervisor`。裁决冻结前，依赖 plan source 可信身份的 M1 代码不得合入。陷阱细节见 pitfalls 2026-08-12「往 trusted supervisor source 里加新 source」条。
+- 保留待裁决：**plan source 与 Goal Contract 协议的关系**（M1 入口前置，与 checkpoint handoff 私有持久化决策并列）。根源是两套工具模型不兼容：现行 deny-list 模型下 `allowed_tools` 直接等于全量执行工具目录，可信 root Supervisor 默认持有 `agent.goal_contract`，两道门对现役 gui/cli/game-chat 是「照着做」；plan source 是首个 allow-list 模型的 source，不持有该工具。卡点是两道**互相独立**的门：入口门 `validate_root_goal_contract_control_plan_at` 在通用 tool-plan 解析路径上强制「合同不存在时本轮必须是唯一的 `agent.goal_contract` 动作」，判据既不看 source 也不看 Run Profile；出口门 `goal_contract_acceptance_completion_blocker_at_locked` 判据含可信 source，未冻结合同即完成门永久 blocked。四方案与代价见技术方案第 23.1 节。已排除「改用 deny-list / 让 plan 持有 `agent.goal_contract`」：它只解除入口门，出口门在验收阶段照卡且更难救——合同强制至少一个带 `requiredEvidence` 的 required 节点，evidence 必须命中 `agent_runtime_acceptance_evidence_tools()` 的 18 项项目读写/命令/预览/生成类工具，而策划 Agent 按设计一项都不该有，`.agent/planning/**` 由 Runtime 写、不产生 Agent 回执，必然留下永不 `passed` 的节点。deny-list 在本场景还额外不成立（策略按 `agent_id` 取，plan 与构建、game-chat Supervisor 共用 `project-supervisor`），其与 allow-list 的实质差别只剩失败方向：往全局工具目录加工具时 deny-list 让策划 Agent 静默获得新能力。真正的分岔是「策划 run 是否应当是 root `project-supervisor` run」——「plan root 改用独立 `agentId`」是唯一一次性解耦三处判据的方案，但会推翻第 4.1 节已冻结的 `agentId=project-supervisor`。裁决冻结前，依赖 plan source 可信身份的 M1 代码不得合入。陷阱细节见 pitfalls 2026-08-12「往 trusted supervisor source 里加新 source」条。
 
 ## 2026-08-12 manifest 不是 game-chat 轮次身份的权威源（M0B-2 挂起项收敛）
 
diff --git a/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md b/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md
index 9f6e93e73..ca31cd1cd 100644
--- a/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md	
+++ b/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md	
@@ -1480,9 +1480,13 @@ M0A-1 是 M1 详细设计与技术 spike 的输入，不是功能交付。M1 可
 | --- | --- | --- |
 | A. plan source 不进可信集合 | 为 plan 另开平行的启动/steer 门 | **只解除出口门，入口门照卡**——入口门不看 source。仍须额外改 `validate_root_goal_contract_control_plan_at` 或让 plan 完全绕开通用 tool-plan 解析路径（但该 validator 位于 `parse` 的 `and_then` 里，是最通用的位置）。另外 `commands.rs` 的启动与 steer 两处都要改，从此存在两套 source 信任判据，后续新增可信消费者容易只接一套 |
 | B. 进可信集合但按 profile 豁免 | 在入口门、Goal Contract 创建、出口门、steer **四处**加 `standard + plan source` 豁免 | 豁免点分散且会继续增加；必须同时冻结「可信 root ≠ Goal Contract 参与者」这条新不变量，否则下一个消费者默认把 plan 当参与者 |
-| C. plan 接纳 Goal Contract 协议 | 把 `agent.goal_contract` 纳入 plan 工具面 | 两道门都自然满足，但与第 4.3 节 exact allowlist、第 19 节第 2 条和第 24 节「plan source 无……」直接冲突；且 GDD 与 Goal Contract 语义大面积重叠，等于让同一轮策划冻结两份目标事实，还要额外裁决二者的权威关系 |
+| C. plan 接纳 Goal Contract 协议 | 把 `agent.goal_contract` 纳入 plan 工具面（等价于放弃 allow-list、改用现行 deny-list 模型） | **只解除入口门，出口门在验收阶段照卡，且更难救。**`validate_goal_contract_acceptance_graph` 强制合同至少一个验收节点、至少一个 `required` 节点、每个 required 节点至少一项 `requiredEvidence`，且 evidence 必须命中 `agent_runtime_acceptance_evidence_tools()` 的 18 项；出口门再要求每个 required 节点在当前 project revision 下有真实成功动作回执。这 18 项全是项目读写/命令/预览/生成类工具，策划 Agent 按第 1 节目标 2 一项都不该有，`.agent/planning/**` 又由 Runtime 写、不产生 Agent 回执，因此合同必然带一个永不 `passed` 的节点。要救须把 plan 工具加进 evidence 集合并追加 `agent.acceptance_update`（独占一轮，与第 12 节 submit sole-action 和第 13 节决策卡流程冲突），且上游已明令禁止「用无关成功动作自证」。此外与第 4.3 节 exact allowlist、第 19 节第 2 条、第 24 节「plan source 无……」直接冲突，GDD 与 Goal Contract 语义大面积重叠。**判定为不可行，保留在表内仅作已排除记录** |
 | D. plan root 改用独立 `agentId` | 不再复用 `project-supervisor` | 入口门、创建权限与出口门三处**同时**自动不适用（三者都要求 `agent_id == project-supervisor`），是唯一一次性解耦的方案；但直接推翻第 4.1 节已冻结的 `agentId=project-supervisor`，牵动顶层通道假设、前端 hydrate、run lineage 与「每项目最多一个 active plan run」的判定口径，须先重开第 4.1 节 |
 
+「改用 deny-list」不是独立的第五方案。deny-list 的作用只是让 plan 默认持有 `agent.goal_contract`，即方案 C，代价见上；而且它在本场景还额外不成立——`agent_runtime_effective_tool_policy_at` 按 `agent_id` 取策略，plan run 与完整构建、game-chat Supervisor 共用 `project-supervisor` 这一个 `agent_id`，per-agent deny-list 区分不了它们，仍须写 source-aware 门。deny-list 与 allow-list 的实质差别只剩失败方向：往 `agent_runtime_executable_tools()` 增加工具时，deny-list 让策划 Agent 静默获得新能力（2026-08-11 的 `agent.goal_contract` / `agent.acceptance_update` 正是这样进入全部现役 Agent 的），allow-list 默认不获得。对一个以「没有构建能力」为安全前提的 source，只能取后者。
+
+因此真正的分岔不是 allow-list 与 deny-list，而是**策划 run 是否应当是一个 root `project-supervisor` run**：三处判据的唯一共同项是 `agent_id == GAME_CREATOR_PROJECT_SUPERVISOR_AGENT_ID`，方案 D 一次性解耦全部三处且不需要在他人协议里挖豁免，方案 B 需要四处豁免并随消费者增加持续维护。
+
 裁决冻结前，依赖 plan source 可信身份的 M1 代码不得合入主线；该决策与 checkpoint handoff 私有持久化决策并列，均属 M1 入口前置。此外需一并确认：plan run 是否允许 steer——`steering.rs` 的 steer 门同样只按可信 source 判定，而 steer 替换协议会终止旧根并另起 replacement root run，与第 5.1 节的 session CAS、`roundsUsed` 与 `activeQuestion` 语义存在未验证的交互，第 14 节恢复矩阵目前没有这条路径。
 
 ### 23.2 M0-3：统一 owner 产物验证与可玩验收边界（PR 工作包 `M0A-2`）