From fe4c35e918eac89f833f4a9bf9f9bf73ed984594 Mon Sep 17 00:00:00 2001 From: Linghong Date: Wed, 12 Aug 2026 04:37:58 +0000 Subject: [PATCH] =?UTF-8?q?=E6=96=87=E6=A1=A3=EF=BC=9A=E6=A0=87=E8=AE=B0?= =?UTF-8?q?=20M0=20=E5=AE=8C=E6=88=90=E5=B9=B6=E6=8C=89=E5=8A=A8=E6=80=81?= =?UTF-8?q?=E7=9B=AE=E6=A0=87=E9=AA=8C=E6=94=B6=E5=9B=BE=E6=94=B6=E6=95=9B?= =?UTF-8?q?=20M2/M3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit M0-1～M0-4 四个工作包全部通过门禁并合入 M0 集成分支，标记 M0 全部完成，并说明此处「合入」指集成分支而非 master。 M0 期间合入的上游动态目标验收图对所有可信 root Supervisor 生效 且不看 Run Profile，与本方案多条前提冲突，一并收敛： - M3 第 17 节：game-chat 根 Supervisor 现在必须先冻结 Goal Contract 才能路由，intentSummary 语义随之改变。裁定已批准 GDD 只能作为上下文进入目标理解，不得由 Runtime 直接物化成合同； GDD 身份也不是验收图的合法证据取值。 - M2 第 16.1 节：steer 替换会另起 replacement root run，该 run 必须重新冻结同一 approvedGddRef，不换稿不降级。 - M2 第 16.2 节：确定性收束与 Runtime 内部产物验证都不产生 Provider 回执，因此不构成验收证据；不得为此暴露内部验证工具。 - 第 22 节：trusted matcher 消费者从 2 个文件更正为 10 个文件 18 处调用，并新增 Goal Contract / Acceptance Graph 证据行。 M1 的 plan source 与 Goal Contract 协议关系保留为待裁决项，与 checkpoint handoff 私有持久化决策并列为 M1 入口前置；裁决冻结前 依赖 plan source 可信身份的 M1 代码不得合入。 Co-Authored-By: Claude Opus 5 --- .../shared-memory/decision-log.md | 11 ++++ docs/project-memory/shared-memory/pitfalls.md | 7 +++ ...方案】立项策划Agent（Fast GDD）-2026-08-10.md | 57 ++++++++++++++++--- 3 files changed, 68 insertions(+), 7 deletions(-) diff --git a/docs/project-memory/shared-memory/decision-log.md b/docs/project-memory/shared-memory/decision-log.md index 871795067..1e0e684a3 100644 --- a/docs/project-memory/shared-memory/decision-log.md +++ b/docs/project-memory/shared-memory/decision-log.md @@ -1,5 +1,16 @@ # 决策记录 +## 2026-08-12 M0 全部完成，并据动态目标验收图收敛 M2 / M3 设计（M1 裁决保留） + +- 背景：M0-1～M0-4 及 `M0A-1` / `M0A-2` / `M0B-1` / `M0B-2` 四个工作包全部通过门禁并合入 M0 集成分支 `feat/five_min_design`（已推送）。M0 按整体切片交付，不逐工作包直接进 master，因此「未进 master」不作为 M0 未完成的依据。 +- 裁决：**M0 全部完成**。M0 期间该分支两次合入上游 master（`03a441027` 无限画布、`1363b9374` 动态目标验收图、`51e35468a` 自主构建测试锁竞态修复），`origin/master` 已是分支祖先。M0 完成不表示任何策划功能上线；M1 功能实现尚未开始。 +- 触发复审的上游事实：`1363b9374` 引入的 Goal Contract / Acceptance Graph 对**所有可信 root Supervisor**生效且不看 Run Profile，与本方案 M1～M3 的多条前提冲突，故一并收敛下列三条。 +- M3 裁决：已批准 GDD 只能作为上下文进入 Supervisor 的目标理解，**不得由 Runtime 直接物化成 Goal Contract**——GDD 是历史批准事实，Goal Contract 是本轮意图，自动 seed 等于让旧策划静默冻结新一轮目标并绕过「Agent 必须自行理解用户真正要做的事」。GDD 只读上下文必须在 Goal Contract 冻结**之前**可见。`approvedGddRef` / fingerprint / 版本号都不是 `requiredEvidence` 的合法取值；GDD 与后续要求的差异记入 `openQuestions` / `forbiddenAssumptions`，记录差异不产生新批准版本。game-chat 的 `intentSummary` 语义随上游改为「忠实概括已冻结的 Goal Contract」，本方案第 17 节原「intentSummary 语义不变」的表述作废。 +- 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 私有持久化决策并列）。触发事实是 `agent_runtime_supervisor_source_is_trusted` 已成为 run 启动、steer、Goal Contract 创建权限、根控制面工具授权与验收图完成门的共同判据且全部不看 Run Profile；plan source 一旦进入该集合，未冻结 Goal Contract 即完成门永久 blocked，而四项 exact allowlist 无解除手段。三方案与代价见技术方案第 23.1 节。裁决冻结前，依赖 plan source 可信身份的 M1 代码不得合入。陷阱细节见 pitfalls 2026-08-12「往 trusted supervisor source 里加新 source」条。 + ## 2026-08-12 manifest 不是 game-chat 轮次身份的权威源（M0B-2 挂起项收敛） - 背景：M0B-2 遗留一条挂起项——manifest 没有 root/run 绑定，不能安全决定 cached failed manifest 是否应覆盖活跃 main 状态。本条对该项作出处置，使 M0-4 可以收口。 diff --git a/docs/project-memory/shared-memory/pitfalls.md b/docs/project-memory/shared-memory/pitfalls.md index 4548941c7..d0ed44258 100644 --- a/docs/project-memory/shared-memory/pitfalls.md +++ b/docs/project-memory/shared-memory/pitfalls.md @@ -1,5 +1,12 @@ # 踩坑与排障记录 +## 2026-08-12 往 trusted supervisor source 里加新 source，等于同时授予 Goal Contract 参与者身份 + +- 现象：`agent_runtime_supervisor_source_is_trusted`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver.rs:113`）读起来像一个「谁能启动 Project Supervisor」的入口白名单，实际早已是多条互不相干的授权判据的共同开关。2026-08-11 合入动态目标验收图后，它的非测试消费者从 2 个文件涨到 10 个文件 18 处调用：run 启动（`commands.rs:698`）、steer（`commands.rs:876`、`steering.rs:763`）、Goal Contract 创建权限（`goal_contract.rs:496`）、根控制面工具是否被剥离（`provider_request_builders.rs:134` 的 `root_control_authority`）、验收图完成门（`acceptance_graph.rs:595`）、run configuration、lifecycle_control、task_start、project_gates、autonomous_completion。 +- 陷阱：这些判据**全都不看 Run Profile**。`goal_contract_acceptance_completion_blocker_at_locked`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/acceptance_graph.rs:568-611`）只要求「`agent_id` 是 `project-supervisor` + binding 是无 parent 的 root + source 可信」，未冻结 Goal Contract 就返回 `blocked`，并被 `main_loop.rs:213`、`main_loop.rs:1803`、`finalization.rs:398` 消费。因此给一个**用途完全不同**的新 source（例如立项策划的 plan chat）加进白名单，会让它的根 Run 立刻背上「必须先调 `agent.goal_contract`」的义务；如果该 source 的工具面按 exact allowlist 设计、不含这个工具，根 Run 就永远无法完成——而且症状是 run 卡在完成门，不是启动失败，排查方向容易跑偏。 +- 处理：新增 trusted source 前，先逐个确认这 18 处调用对新 source 的语义是否成立，尤其是 Goal Contract 创建、验收图完成门与 steer 三处；需要区分时，应当拆出「可信入口」与「Goal Contract 参与者」两条判据，而不是继续复用同一个函数。立项策划的对应裁决见《【技术方案】立项策划Agent（Fast GDD）-2026-08-10》第 23.1 节，尚未冻结。 +- 相关：`requiredEvidence` 只接受 `tool:` 且必须命中 `agent_runtime_acceptance_evidence_tools()`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/tool_policy_snapshot.rs:74-96`，当前 18 项）。确定性收束的任务和 Runtime 内部产物验证都不产生 Provider 回执，因此无法为验收节点提供证据——不要指望「让 Runtime 自己验一下」能满足验收图。 + ## 2026-08-12 给 manifest 加"新鲜度门控"或身份字段的两个陷阱 - 现象：想给 game-chat 投影里的 manifest 读取加保护时，两条看起来最自然的路都会失效，且失效方式都是静默的——代码跑得通、测试也能编出来，但保护根本没生效。 diff --git a/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md b/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md index 89b2b729e..c78882677 100644 --- a/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md +++ b/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md @@ -1,7 +1,7 @@ # 立项策划 Agent（Fast GDD）技术方案 - 日期：2026-08-10 -- 状态：M0A-1、M0A-2、M0B-1、M0B-2 均已形成独立提交；合入状态以 Git / PR 为准，M1～M3 功能尚未实现 +- 状态：2026-08-12 起 **M0 全部完成**（M0-1～M0-4 / `M0A-1`、`M0A-2`、`M0B-1`、`M0B-2` 均已合入 M0 集成分支并通过各自门禁，见第 23.4 节）；M1～M3 功能尚未实现，且 M1 有两项入口前置决策待裁决（见第 23.1 节） - 适用范围：AI 游戏创作独立 App、Project Supervisor、Agent Runtime、本地项目策划 sidecar 与后续完整构建准入 - 当前实现边界：本文件是后续详细设计与实现的仓库内阶段基线；M0 工作包只冻结 Fast GDD 合同并修复现有 owner 验证、game-chat retry 与前端投影边界，不代表立项策划入口、审批 UI、Runtime 持久化或构建绑定已经可用 @@ -1170,7 +1170,9 @@ type PlanningBaselineInput = 3. 在同一个锁/CAS 边界内把 planning baseline 写入 root task record、durable run configuration binding 和 autonomous completion contract，再允许任务入队。当前在 completion contract 创建前释放项目锁的顺序必须调整或增加等价的可恢复提交标记，不能留下“task 已启动但基线未冻结”的窗口。 4. Provider context bundle 持久携带 `planningBaseline`、权威相对路径与有界 GDD 摘要；恢复、retry、child 调度和 final completion 都核对相同 ref，不因后来批准新版本而换稿。 -是否把 ref 写入 `.agent/manifest.json` 由 M2 结合迁移成本另行决策；但 task/run/completion identity 的贯穿是本方案已冻结的最低要求，不能省略。 +2026-08-11 合入的动态目标验收图给可信根 Run 增加了 steer 替换协议：根 Run 收到 steer 后整棵旧根任务树先写取消栅栏并逐个收束，停稳后才在同一 Session、source 和 Run Profile 启动 replacement root run。因此 planning baseline 不是「一次冻结永久有效」。replacement root run 必须在自己的项目锁/CAS 边界内重新冻结与被替换根**完全相同**的 `approvedGddRef`，即使期间已经产生更新的 approved 版本也不换稿；无法从 canonical GDD/receipt 证明同一 ref 时失败关闭，不得降级为 `mode=direct-build`，也不得让 replacement run 以「缺基线」重新开始。旧根的 completion contract 终结与新根的基线冻结之间不允许出现「已启动但基线未冻结」的窗口，这与上面第 3 条是同一条要求。 + +是否把 ref 写入 `.agent/manifest.json` 由 M2 结合迁移成本另行决策；但 task/run/completion identity 的贯穿是本方案已冻结的最低要求，不能省略。第 19 节的 manifest 非权威源不变量对这条决策是负面证据，而 Goal Contract 提供了正面先例：它落在 `.agent/runtime/goal-contracts/{rootAgent}/{rootRun}.json`，天然按 root run 分文件，并绑定根 Run Profile binding fingerprint 与 source SHA-256。`approvedGddRef` 若要落盘，应当照这个形态而不是塞进项目级单例。 `mode=direct-build` 不读取 planning sidecar，保持老项目行为。两种模式都继续使用现行 `project-supervisor-gui|cli + autonomous-game-build`，不把 plan source 带进 DAG。 @@ -1184,11 +1186,23 @@ type PlanningBaselineInput = - `quality-review` 检查核心循环、MVP 系统和支柱承诺是否偏离；`preview-playtest` 把 prototype validation items 转为观察清单；`publish-strategy` 可复用标题、一句话描述、目标用户和支柱。 - 试玩发现只形成实现证据或下一版本建议，不回写、覆盖或“自动修正”已批准 GDD。 +确定性收束与动态 Acceptance Graph 是两套证据体系，M2 不能混用。`design-director` 变成确定性 GDD 准入门后不再启动 LLM，因此**不产生任何 Provider 动作回执**；M0-3 的 Runtime 内部固定产物验证同样不产生 Provider 可见回执。而 Acceptance Graph 的 passed 节点必须引用当前根任务树中真实成功动作回执，`requiredEvidence` 只接受 `tool:` 且必须命中 Runtime 允许的持久证据工具集合（`agent_runtime_acceptance_evidence_tools()`，当前 18 项，既不含 Runtime 内部 owner 产物验证，也不含任何控制面或纯协调工具）。结论固定为：确定性 completed 投影与内部产物验证都不构成验收证据；涉及 GDD 落地的验收标准要么由根 Supervisor 用允许的证据工具自行取证，要么不写成 required 节点。不得为了让确定性节点“可验收”而把内部验证工具暴露成 Provider 可见工具——那会直接推翻 M0-3 已冻结的 owner 验证边界。 + ## 17. M3 game-chat 只读复用 game-chat 不强制先策划、不改变单主结构。项目存在有效 approved GDD 时，M3 可把 `title, oneLiner, coreLoop, mvpSystems 摘要, version, fingerprint` 作为只读上下文注入当前 `project-supervisor-game-chat` 根 run；没有时完全保持现状。 -注入前仍从不可变 GDD/receipt 验证，不能读取 index 或 Markdown 当信任源。game-chat 的 `intentSummary` 语义、`audit-existing-first` 决策、唯一 `code-prototype` 主 Agent 与按需美术 child 不变；后续用户要求与 GDD 冲突时由 Supervisor 明示差异，不自动产生新批准版本。 +注入前仍从不可变 GDD/receipt 验证，不能读取 index 或 Markdown 当信任源。唯一 `code-prototype` 主 Agent、按需美术 child 与 `audit-existing-first` 执行安全策略不变；后续用户要求与 GDD 冲突时由 Supervisor 明示差异，不自动产生新批准版本。 + +2026-08-11 合入的动态目标验收图改变了本节的两条前提，M3 必须按新事实设计。 + +第一，game-chat 根 Supervisor 现在有强制前置动作。根 Run 尚无 Goal Contract 时，本轮唯一动作必须是 `agent.goal_contract`；冻结之后才轮到 `agent.route_manifest`。`intentSummary` 的语义随之改变——它不再概括用户原话，而必须忠实概括**已冻结的 Goal Contract**。因此 M3 的 GDD 只读上下文必须在 Goal Contract 冻结**之前**就对根 Supervisor 可见，否则冻结下来的目标看不到已批准策划，后续整轮都建立在缺失前提上。 + +第二，approved GDD 不得自动 seed Goal Contract。GDD 是一次历史批准事实，Goal Contract 是 Supervisor 对**当前这一轮用户意图**的理解；由 Runtime 用 GDD 字段直接物化合同，等于让旧策划静默冻结新一轮目标，并且绕过了「Agent 必须自行理解用户真正要做的事」这条约束。GDD 只能作为上下文进入理解过程，合同内容仍由 Supervisor 产出。 + +第三，GDD 身份不能进 Acceptance Graph 的证据面。`requiredEvidence` 只接受 `tool:`，`approvedGddRef`、fingerprint、版本号与任何自然语言证据描述都不是合法取值；「与已批准 GDD 一致」这类标准无法用回执证明，不得写成 required 节点。GDD 与后续用户要求的差异可以记进 Goal Contract 的 `openQuestions` 或 `forbiddenAssumptions`，但记录差异不产生新的批准版本，也不改变 `.agent/planning/**` 的任何权威事实。 + +第四，`goal_contract_acceptance_completion_blocker_at_locked` 会阻断根 Run 的普通完成、finalization 与恢复。M0B-2 的前端投影按「root、main、动态 child 与 manifest 主任务全部终态且无 reconciliation」才归档阶段记录，验收图 blocker 只会推迟根终态、不会伪造终态，因此归档门本身不需要改；但 M3 接入时必须确认进度展示对「根 Run 长时间停在待核对」有合理呈现，不能让用户看到停滞而无解释。 ## 18. 前端入口与交互合同 @@ -1352,6 +1366,8 @@ Canvas 是条件外部能力，不是 M0-3 四个固定 owner 的通用前置： 2026-08-12 裁决补充：manifest 不是 game-chat 轮次身份的权威源。`GameCreationAppManifest` / `GameCreationAppTaskState` 在 TS 与 Rust 双侧都不含 run/root/agent 身份字段，且 manifest 是项目级单例文件并跨轮复用同一份，因此任何任务状态都无法从数据本身归属到具体轮次。轮次结论的权威事实只有 Runtime lineage（`agentId + sessionId + runId + source + parentAgentId + parentRunId`）；manifest 只能作为 lineage 判定通过后的补充信号，不得单独裁定当前轮结论，也不得单独解锁阶段归档。阶段归档快照的全部写入点都必须校验被归档 root 仍是当前 root，终态会话同步中的异步捕获同样适用——该读取若在下一轮接管后才 resolve，会把掺入新轮活动的清单冻结成旧轮快照；跳过捕获不会饿死归档，因为开下一轮前的阻塞门在快照未冻结时直接失败要求重试。本阶段明确不为 manifest 或其投影新增 `statusRunId` / `statusSource` 等身份字段：补字段必须同时覆盖 `update_manifest_task_status_at` 与无秩序守卫的 `set_task_status` 两条写入路径，只改前者会让后者原样保留上一次写入的旧身份印记，制造“校验通过”的假象而比不校验更危险。 +2026-08-12 记录一处尚未裁决的不变量冲突。本节第 2 条（plan source 的工具广告与执行双门只有四项）与 2026-08-11 合入的动态目标验收图存在结构性冲突：`goal_contract_acceptance_completion_blocker_at_locked` 只按「`agent_id` 是 `project-supervisor` + binding 是无 parent 的 root + source 可信」三条判定，**不看 Run Profile**；同一判据也决定 Goal Contract 的创建权限和 `agent.goal_contract` / `agent.acceptance_update` 是否被剥离。M1 一旦按第 22 节把 plan source 加入可信集合，plan root 就同时满足三条，未提交 Goal Contract 即完成门永久 blocked，而四项 exact allowlist 里没有解除该 blocker 的工具。处置方案见第 23.1 节的待裁决项；在裁决冻结前，本节第 2 条按「设计意图」保留，不得据此认为现行代码已经满足它。 + ## 20. rollout、停用与回滚 - M1 以 AppData/Runtime capability 开关启用，不把 feature flag 写进用户项目。 @@ -1397,12 +1413,12 @@ M0 文档 PR 本身最低验证：Markdown 结构与三张 Mermaid 图可解析 ## 22. 当前代码证据与 M1 接入点 -以下行号基于 2026-08-10 当前基线；实施时必须打开源文件复核，不能只复制行号。 +以下行号基于 2026-08-10 当时基线；实施时必须打开源文件复核，不能只复制行号。M0 期间已合入 `03a441027` 无限画布、`1363b9374` 动态目标验收图与四个 M0 工作包，大部分行号已漂移，仅逐行标注 2026-08-12 复核的条目为准。 | 主题 | 当前证据 | M1/M2 要点 | | --- | --- | --- | | Supervisor trusted source | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver.rs:107-120` | 当前只有 gui/cli/game-chat；M1 新增 plan 常量与 matcher | -| autonomous matcher 消费者 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/run_configuration.rs:112-116`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/autonomous_completion.rs:37-68,6848-6861,6982-7007,14396-14408` | 当前多处复用 trusted matcher；M1 必须拆出 autonomous-only matcher，不能因加入 plan 污染完成/恢复 | +| trusted matcher 消费者 | 2026-08-12 复核为 10 个非测试文件、18 处调用：`commands.rs`(2)、`agent/runtime_actions/project_gates.rs`、`agent/runtime_protocol/acceptance_graph.rs`(2)、`agent/runtime_protocol/goal_contract.rs`(2)、`agent/runtime_protocol/run_configuration.rs`、`agent/runtime_protocol/steering.rs`、`agent/runtime_driver/lifecycle_control.rs`、`agent/runtime_driver/task_start.rs`(2)、`agent/runtime_actions/provider_request_builders.rs`、`agent/runtime_protocol/autonomous_completion.rs`(5) | 2026-08-10 记录的两个消费者已过期。`agent_runtime_supervisor_source_is_trusted` 现在同时是 run 启动门、steer 门、Goal Contract 创建权限、验收图完成门与根控制面工具授权的共同判据，**都不看 Run Profile**。M1 只拆 autonomous-only matcher 已不够；必须先按第 23.1 节裁决 plan source 与 Goal Contract 协议的关系 | | Run Profile | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_adapter.rs:48-75`、`apps/ai-game-creator-shell/src-tauri/src/main.rs:1243-1244` | 复用 `standard`，不新增 profile | | Supervisor start 校验 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/task_start.rs:114-134`、`apps/ai-game-creator-shell/src-tauri/src/commands.rs:497-529` | 增加 top-level plan source/profile 组合门 | | durable run binding | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/run_configuration.rs:72-125,226-374` | source/profile/root/parent CAS 与恢复必须贯穿 | @@ -1424,7 +1440,8 @@ M0 文档 PR 本身最低验证：Markdown 结构与三张 Mermaid 图可解析 | plan retry | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/lifecycle_control.rs:740-772,775-907` | generic standard fallback 前保留 exact plan source/profile/session lineage | | planning hydrate command | `apps/ai-game-creator-shell/src-tauri/src/commands.rs:856-875`、`apps/ai-game-creator-shell/src-tauri/src/main.rs:2178-2180`、`apps/ai-game-creator-shell/src/App.tsx:1550,1650,2957,3364,3702` | 新增单一 hydrate command/注册与前端生命周期调用；不把 runtime polling 当 GDD authority | | 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` | M0/M1 不改拓扑 | +| 16 任务 DAG | `server-rs/crates/shared-contracts/src/game_creation_app.rs:263-425` | 2026-08-12 复核 seed 仍是 16 个，M0/M1 不改拓扑；但固定 DAG 已不是完成语义的唯一来源，见下一行 | +| 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 | | owner 产物验证 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/autonomous_completion.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/project_gates.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_tools/file_ops.rs` | M0-3 / M0A-2 让四个 pre-code fixed owner 复用 canonical 路径映射，由 Runtime 内部验固定产物；Provider 不见验证工具，code / preview 节点继续真实 smoke | @@ -1446,6 +1463,16 @@ M0 文档 PR 本身最低验证：Markdown 结构与三张 Mermaid 图可解析 M0A-1 是 M1 详细设计与技术 spike 的输入，不是功能交付。M1 可以与 M0-3 并行准备；但 checkpoint handoff 私有持久化决策未冻结前，对应 checkpoint 代码不得合入，M0-3 的 dated 决策、Prompt、source/tool policy 与测试未全部合入前，依赖 Fast GDD source/tool policy 的 M1 代码也不得合入主线。M0-3 采用 Runtime 内部 owner 验证，不为未来 plan source 暴露 command、smoke 或替代验证工具。M0-4 不阻塞 M1/M2，仅阻塞 M3-4 和“M0 全部完成”；不得因为并行关系把工作包标签误报为阶段完成。 +2026-08-12 新增第二项 M1 合入前置决策：**plan source 与 Goal Contract 协议的关系**。触发事实见第 19 节与第 22 节 trusted matcher 行——`agent_runtime_supervisor_source_is_trusted` 现在同时决定 run 启动、steer、Goal Contract 创建权限、根控制面工具授权与验收图完成门，且全部不看 Run Profile。三个候选方案与已知代价： + +| 方案 | 做法 | 已知代价 | +| --- | --- | --- | +| A. plan source 不进可信集合 | 为 plan 另开平行的启动/steer 门 | `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 在语义上大面积重叠，等于让同一轮策划冻结两份目标事实 | + +裁决冻结前，依赖 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`） 以 2026-08-11 dated 决策确认四个 pre-code fixed owner 由 Runtime 内部验证 canonical 正式产物，Provider 不获得新工具或 commandId；`code-prototype / preview-readiness` 保留真实 `game.static_smoke`，`preview-playtest` 保留独立浏览器验收，后置 `publish-package` 不在本阶段扩展。实现与回归必须覆盖真实新项目占位入口、canonical owner 路径矩阵、mutation 后凭证失效、恢复和错误 source/run/root/parent 失败关闭，以及 `art-director` 有/无 Editor Key 的条件 Canvas owner 分类。只有文档、Prompt、工具广告、执行 policy、完成门与上述测试全部通过并合入，才可把 M0-3 计入“M1 入口门完成”；M1 plan source 本身仍属于后续功能实现。 @@ -1458,6 +1485,20 @@ M0A-1 是 M1 详细设计与技术 spike 的输入，不是功能交付。M1 可 2026-08-12 收敛 M0B-2 遗留的唯一挂起项——manifest 无 root/run 绑定，无法安全判定跨轮残留状态的归属。处置为三项：确立“manifest 非轮次身份权威源”的不变量（见 §19）；补齐阶段归档中终态会话同步异步捕获缺失的 root 身份校验，使四处快照写入点身份口径一致；以回归钉住“当前 main 未终态时 manifest 不参与裁定”这条既有但零覆盖的边界。明确保留并记录的残余风险是：当前 main 到达 Runtime 终态且非 failed/cancelled 后 manifest 被逐字采信，若本轮 `manifestInvalidated` 尚未落地，跨轮残留的 failed 仍可能被显示为本轮结论；该窗口实际宽度未量化，三条候选机制（时间戳新鲜度门控、root-scoped 永久缓存、manifest 补身份字段）经审查均不可安全落地——分别因跨端时间戳单位错配导致门控恒真、缓存语义与后端“每次重新校验”哲学相悖、以及漏掉第二条 status 写入路径——故本阶段只记录不实现。回归用例中该残余风险的断言即裁决锚点，改动它意味着重新裁决。重新裁决触发条件见 decision-log 2026-08-12 条。该挂起项至此已处置，不再阻塞 M0-4 收口。 +### 23.4 M0 完成状态（2026-08-12） + +**M0 全部完成。** M0-1～M0-4 四个正式任务、对应的 `M0A-1` / `M0A-2` / `M0B-1` / `M0B-2` 四个工作包及各自门禁均已通过，全部落在 M0 集成分支 `feat/five_min_design` 并已推送。 + +此处「合入」指合入 M0 集成分支，不是合入 `master`：M0 按整体切片交付，不逐工作包直接进 master，因此不得把「未进 master」当作 M0 未完成。M0 期间该分支已两次合入上游 master（含 `03a441027` 无限画布、`1363b9374` 动态目标验收图、`51e35468a` 自主构建测试锁竞态修复），`origin/master` 已是分支祖先。 + +M0 收口时的三项已知残留，均已定性且不阻塞后续阶段： + +- 第 23.3 节记录的 manifest 新鲜度残余风险，只记录不实现，回归用例中的断言即裁决锚点。 +- `set_task_status` 无秩序守卫的无条件覆盖，属 master 既有问题，另行提 issue，不在 M0 范围内修。 +- 第 23.1 节两项 M1 入口前置决策（checkpoint handoff 私有持久化、plan source 与 Goal Contract 协议的关系）保持待裁决；它们是 M1 的合入门，不是 M0 的完成门。 + +M0 完成不表示任何策划功能已上线。M1 的功能实现仍未开始，第 19 节第 2 条等 plan source 不变量目前只是设计意图。 + ## 24. 最终不变量摘要 - 策划与构建是两个不同 profile/source 的 run，由用户动作连接，不由 Agent 自行升级。 @@ -1469,6 +1510,8 @@ M0A-1 是 M1 详细设计与技术 spike 的输入，不是功能交付。M1 可 - decisionFingerprint 解决意图幂等，receiptFingerprint 保护完整信任根。 - plan source 无 command/smoke/preview/委派/MCP；内部 Markdown 投影不推进代码 revision。 - 前端只通过 `hydrate_game_creator_plan_gdd_state` 读取策划权威状态；文件、Markdown 和 runtime polling 不能在页面侧合成批准事实。 -- 完整构建只认后端在项目锁内重算并冻结的 approvedGddRef；直接开建必须显式声明，不能由缺字段降级。 +- 完整构建只认后端在项目锁内重算并冻结的 approvedGddRef；直接开建必须显式声明，不能由缺字段降级。根 Run 被 steer 替换时，replacement root run 必须重新冻结同一 ref，不换稿、不降级、不留空窗。 +- 已批准 GDD 只能作为上下文进入 Supervisor 的目标理解，不能被 Runtime 直接物化成 Goal Contract；GDD 身份也不是 Acceptance Graph 的合法证据取值。 +- 确定性收束与 Runtime 内部产物验证都不产生验收证据；不得为了让确定性节点可验收而把内部验证工具暴露给 Provider。 - 任何无法证明 project/source/profile/session/run/action/ref 身份的恢复或 mutation 都失败关闭。 - 不携带 run/root 身份的项目级单例文件（当前为 `.agent/manifest.json`）永远不是轮次身份的权威源，只能作为身份判定通过后的补充信号。