文档：标记 M0 完成并按动态目标验收图收敛 M2/M3
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 <noreply@anthropic.com>
This commit is contained in:
@@ -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 可以收口。
|
||||
|
||||
@@ -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:<Runtime 工具名>` 且必须命中 `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 读取加保护时，两条看起来最自然的路都会失效，且失效方式都是静默的——代码跑得通、测试也能编出来，但保护根本没生效。
|
||||
|
||||
Reference in New Issue
Block a user