From 91888bfd9e961ed78aea21820a08f9333de87cee Mon Sep 17 00:00:00 2001 From: Linghong Date: Thu, 13 Aug 2026 12:46:50 +0000 Subject: [PATCH] =?UTF-8?q?=E6=96=87=E6=A1=A3=EF=BC=9A=E4=BC=A0=E5=AF=BC?= =?UTF-8?q?=E6=8B=86=E5=8C=85=E4=B8=8E=E5=B9=BF=E5=91=8A=E5=B1=82=E6=9B=B4?= =?UTF-8?q?=E6=AD=A3=EF=BC=8C=E4=BF=AE=E5=9B=9B=E5=A4=84=E8=87=AA=E7=9B=B8?= =?UTF-8?q?=E7=9F=9B=E7=9B=BE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 均为上一轮拆包与第 19 节改写后未传导到位所致。 第 23.7 节：原写「变体、判据、receipt 写入必须同一个 PR」，与第 23.8 节 拆出 M1C-0 矛盾。改为判据在 M1C-0（惰性、无写入方、行为零变化）， 写入方与 receipt 在 M1C-1 同进同退；这样拆全程不产生半状态。 第 24 节第 8 条：不变量摘要仍写「广告层仍可见」，而第 19 节第 2 条已改为 目标态两层都拒。第 24 节是终态合同，留旧目标态会把 M1A-2 带偏。 第 23.8 节：审批前置门的门禁原挂在 M1C-1，但取证顺序是协议时序问题， 归 M1C-2a；M1C-1 只做 receipt。门禁随之对调。 第 12 节：原写 submit 分支「随后把顶层 run 投影为 waiting-for-user-input」， 与第 13.0 节冲突。这是 D9/D10 单 run 拓扑残留——D11 下调用 submit 的是 策划子 run，提交完即终态结束；审批等待属 Supervisor 根 run 且必须等 取证通过后才创建。提交分支现只负责校验、定版、写 GDD、追加 index、渲染。 第 4.3 节与 D10 作废条目的「广告层仍放行」保留但标注为 M1A-2 之前的现状。 Co-Authored-By: Claude Opus 5 --- ...术方案】立项策划Agent（Fast GDD）-2026-08-10.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md b/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md index 5d9c50689..860edba81 100644 --- a/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md +++ b/docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md @@ -141,7 +141,7 @@ WP1 定稿的澄清轮次/返工深度语义（供 D11 依赖，权威定义见 | D7 | 本期不实现知识图谱；`basis`、知识 provider trait、composition 槽位可以预留，但 v1 数据必须为 `null`，空字段不渲染。 | | D8 | GDD 不含引擎字段；平台事实固定由 Runtime 注入，Agent 不得向用户提问或修改。 | | ~~D9~~ | **2026-08-13 二次作废**，由 D11 取代。原文：“取代 D6。立项策划是独立 `agentId` 的下游工作流节点，由 manifest ready-task 调度器在 Supervisor 下游启动，需登记 agentCatalog；Project Supervisor 以新的可信 source 承载「做方案」入口并保持唯一顶层 root；父子 run profile 必须同为 `standard`——不是为了复用顶层通道，而是因为 `autonomous-game-build` 对 `user.input_request` 的禁令按 profile 生效、父子皆不可提问，且子 Run 不能切换父 Run 的 profile。” 作废理由见第 1.1 节「D11 新拓扑」。**“立项策划是独立 `agentId` 的下游工作流节点”这一结论方向被 D11 继承**，但调度机制被 D11 推翻：不再由 manifest ready-task 调度器启动，改为 Project Supervisor 通过 `agent.delegate` 发起的静态委派子 Agent；「父子 run profile 必须同为 `standard`」这条论证随之失效——D11 拓扑下策划节点天然带 `parent_agent_id`/`parent_run_id`，其 `user.input_request` 直接被执行层 `validate_user_input_action_owner`（`user_input.rs:367-394`）拒绝，不再依赖“父子皆不可提问、子 Run 不能切换父 Run profile”这条 profile 层面的间接论证；「需登记 agentCatalog」被继承但登记方式生变，登记机制已于 2026-08-13 定稿（见第 3.1 节与第 23.1 节），代码落地留给 M1。 | -| ~~D10~~ | **2026-08-13 作废**，由 D11 取代。原文：“策划节点**不得**直接调用 `user.input_request`——注意这不是 Runtime 拦得住的：standard ready-task 调度器不写 parent，该调用会被放行，因此必须由 exact allowlist 主动排除并以回归钉死。禁止的理由是产品约束：直接提问会把问答落进策划节点自己的会话，Supervisor 上下文里什么都没有。问询改走「Runtime 直投」：策划节点提交结构化决策字段，Runtime 创建 **owner 为 Project Supervisor** 的 pending，会话消息落 Supervisor 会话、结构化 observation 落策划节点，二者是同一 `AgentRuntimeUserInputRecord` 的两路投影。Supervisor 的 Provider 不参与提问。” 作废理由：D10 存在的唯一前提——「ready-task 节点无 parent，Runtime 拦不住，必须靠 exact allowlist 自律排除」——在 D11 新拓扑下不成立。策划节点改为委派子 Agent 后天然带 `parent_agent_id`/`parent_run_id`，`user.input_request` 被执行层 `validate_user_input_action_owner`（`user_input.rs:367-394`）直接拒绝，是 Runtime 兜底而非产品自律（但广告层仍放行，模型看得见、会去调，只是必失败，见第 19 节第 2 条改写）。「问询改走 Runtime 转发、Supervisor 会话与结构化 observation 两路投影」这一方向被 D11 继承，但落地机制不是同一套代码：D10 设想的是为 D9 拓扑新造的「Runtime 直投」，D11 复用的是 PR #165 已实现的 `AGC_NEEDS_USER_INPUT_V1` 终态信封 + Supervisor 中转链路，两者实现路径不同。 | +| ~~D10~~ | **2026-08-13 作废**，由 D11 取代。原文：“策划节点**不得**直接调用 `user.input_request`——注意这不是 Runtime 拦得住的：standard ready-task 调度器不写 parent，该调用会被放行，因此必须由 exact allowlist 主动排除并以回归钉死。禁止的理由是产品约束：直接提问会把问答落进策划节点自己的会话，Supervisor 上下文里什么都没有。问询改走「Runtime 直投」：策划节点提交结构化决策字段，Runtime 创建 **owner 为 Project Supervisor** 的 pending，会话消息落 Supervisor 会话、结构化 observation 落策划节点，二者是同一 `AgentRuntimeUserInputRecord` 的两路投影。Supervisor 的 Provider 不参与提问。” 作废理由：D10 存在的唯一前提——「ready-task 节点无 parent，Runtime 拦不住，必须靠 exact allowlist 自律排除」——在 D11 新拓扑下不成立。策划节点改为委派子 Agent 后天然带 `parent_agent_id`/`parent_run_id`，`user.input_request` 被执行层 `validate_user_input_action_owner`（`user_input.rs:367-394`）直接拒绝，是 Runtime 兜底而非产品自律（但**在 `M1A-2` 之前**广告层仍放行，模型看得见、会去调，只是必失败；`M1A-2` 后两层都拒，见第 19 节第 2 条）。「问询改走 Runtime 转发、Supervisor 会话与结构化 observation 两路投影」这一方向被 D11 继承，但落地机制不是同一套代码：D10 设想的是为 D9 拓扑新造的「Runtime 直投」，D11 复用的是 PR #165 已实现的 `AGC_NEEDS_USER_INPUT_V1` 终态信封 + Supervisor 中转链路，两者实现路径不同。 | | D11 | **取代 D9，并连带作废 D10。** 立项策划节点改为 Project Supervisor 通过 `agent.delegate` 发起的**静态委派子 Agent**（`agentId=project-planning`），不再由 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 续跑。**最多 3 轮问询依赖 WP1（澄清轮次与返工深度拆分，见第 1.1 节）先落地，是强制前置，不是并行工作包**；该前置已于 2026-08-13 落地并合入，现行上限为 3（完成状态与门禁见第 23.5 节）。作为改造前的对照记录：`WP1` 之前上限只有 1 轮，且用掉后连一次质量返工都做不了。完整支撑事实（6 条，均带 `file:line`）见第 1.1 节「D11 新拓扑」；`project-planning` 的 agentCatalog 登记方式与 `build.rs` 一致性校验已于 2026-08-13 定稿（见第 3.1 节、第 23.1 节），代码落地留给 M1；M1 的真正前置是第 3.1 节新发现的 `prompt.rs` 角色身份合成缺口。 | ## 3. 合同名称注册表 @@ -363,7 +363,7 @@ action 工具广告与执行双门都必须是 exact allowlist，MCP catalog 为 明确禁止：通用写入、patch/delete、command、process、preview、canvas、asset generation、确认型副作用、`agent.delegate`、`agent.route_manifest`、isolated child、任务图调度和所有 MCP 工具。 -`user.input_request` **不在允许清单内**，但要如实记录它的排除性质：这不是 exact allowlist 独力保证的——委派子 Agent 天然带 `parent_agent_id`/`parent_run_id`，该调用被执行层 `validate_user_input_action_owner`（`apps/ai-game-creator-shell/src-tauri/src/user_input.rs:367-394`）兜底拒绝；**广告层仍会把它列进函数目录**，模型看得见、会去调，只是调用必失败并转成一次失败的 tool observation。allowlist 的作用是让它在广告层就消失、避免模型浪费轮次，兜底则由 Runtime 提供。两者都要有，不可互相替代（见第 19 节第 2 条）。 +`user.input_request` **不在允许清单内**，但要如实记录它的排除性质：这不是 exact allowlist 独力保证的——委派子 Agent 天然带 `parent_agent_id`/`parent_run_id`，该调用被执行层 `validate_user_input_action_owner`（`apps/ai-game-creator-shell/src-tauri/src/user_input.rs:367-394`）兜底拒绝；**广告层仍会把它列进函数目录**（**这是 `M1A-2` 之前的现状**；`M1A-2` 落地后它不再出现在函数目录，见第 19 节第 2 条），模型看得见、会去调，只是调用必失败并转成一次失败的 tool observation。allowlist 的作用是让它在广告层就消失、避免模型浪费轮次，兜底则由 Runtime 提供。两者都要有，不可互相替代（见第 19 节第 2 条）。 **collaboration policy 的处置（原「六类入口冻结」按 D11 修订）** @@ -1120,7 +1120,7 @@ GDD handler 只能从已验证 batch binding 复制 `sourceSessionRevision/sourc **（2026-08-13 删除）**原此处一整段规定 `plan-decision-checkpoint` 的 stale/repair/superseded 状态机（`repair-{K+1}` 转换、传递闭包数组、handoff 与 successor 的应用边界）。该请求 kind 随 D10 作废，整段无对应物：D11 下续跑是「新 run、同 session」，其 stale 判据就是普通 tool-plan 的那一套（本节第 1～5 项），不需要第二套。 -main loop 不能把 submit 当成普通 action dispatch：在 durable action identity 建立后、生成普通 command ID 或进入 action executor 前，必须进入 `plan.submit_gdd` 专用分支。该分支重验 exact plan identity，执行下列提交与投影，随后把顶层 run 投影为 `waiting-for-user-input` 同族状态并返回现有 `WaitingForUserInput` outcome；planning pending 的 `kind=gdd-approval` 区分审批等待，不新增第二个 queue outcome 或 run status。GDD create 成功不等于该 action 已 observed；只有 receipt 产生的确定性 terminal observation 才能完成原 action并让精确原 run 继续。 +main loop 不能把 submit 当成普通 action dispatch：在 durable action identity 建立后、生成普通 command ID 或进入 action executor 前，必须进入 `plan.submit_gdd` 专用分支。该分支重验 exact plan identity，执行下列提交与投影。**（2026-08-13 按 D11 与第 13.0 节更正）** 提交分支只负责校验、定版、写不可变 GDD、追加 index 与渲染 `game/fast_gdd.md`，**不创建 `gdd-approval` pending、也不把任何 run 投影为审批等待**——原文写的「随后把顶层 run 投影为 `waiting-for-user-input`」是 D9/D10 单 run 拓扑的残留：D11 下调用 submit 的是**策划子 run**，它提交完即终态结束；审批等待属于 Supervisor 根 run，且必须等第 13.0 节的验收取证通过后才创建。planning pending 的 `kind=gdd-approval` 仍用于区分审批等待，不新增第二个 queue outcome 或 run status。GDD create 成功不等于该 action 已 observed；只有 receipt 产生的确定性 terminal observation 才能完成原 action并让精确原 run 继续。 1. 解析第 8.2 节 strict input；在项目锁内重读 project identity、active plan run、Provider request 所绑定的 session CAS、canonical GDD/receipt 与独立 planning pending。不信任 Provider payload 中不存在也不允许出现的版本、时间、平台事实或身份。 2. 验证文本上限、轮次、决定状态和 prototype item 一一对应；Runtime 注入固定 platformFacts 和所有 `basis:null`，以当前 durable actionId/裸 action fingerprint 作为 submission identity。 @@ -1943,7 +1943,7 @@ M0 完成不表示任何策划功能已上线。M1 的功能实现仍未开始 **落地约束**： -- 变体新增、判据分支与 receipt 写入必须**同一个 PR 同进同退**——只置 status 不写 receipt（或反之）会让链路计数与审批事实脱节。 +- 拆包（2026-08-13 按第 23.8 节更正）：**变体与分类分支在 `M1C-0`**——该 PR 无写入方、是惰性路径、行为零变化，便于把「做游戏链路返工额度未被误放宽」这条关键回归单独证明；**写入方与 receipt 在 `M1C-1` 同进同退**——只置 status 不写 receipt（或反之）会让链路计数与审批事实脱节。这样拆全程不产生半状态：`UserRevisionRequested` 直到 `M1C-1` 才可能被写出。 - `StaticDelegateContractStatus` 是 durable schema 的一部分。新增变体属**前向兼容**问题（旧代码读不了新记录），非后向兼容问题：只有做方案链路会写它，做游戏链路既有记录不受影响。反序列化必须 fail closed，**不得静默降级为 `NeedsRepair`**——那会让用户修订被误计成返工，正是本裁决要消除的行为。 - 本裁决改的是 master 已发布的静态委派机制，须在 `decision-log.md` 补 dated 记录，写明 `WP1` 的 depth≤1 结论未被推翻。 - 回归必须覆盖：用户修订跳不增 `depth` 也不重置 `round`；连续多次修订均可通过；做游戏链路的返工仍在 `depth=1` 被拒；无该变体的历史记录分类行为不变；32 跳边界仍 fail closed。 @@ -1959,8 +1959,8 @@ M0 完成不表示任何策划功能已上线。M1 的功能实现仍未开始 | `M1B-1` | `.agent/planning/` 存储层、strict schema、typed 指纹、版本链；含 `.agent/planning/**` 只挡写判据 | `M1A-2` | **第 9.1 节 golden vector 逐字节相等且指纹相等**（先于其它测试）；create-only 与等前缀不可变 | | `M1B-2` | `plan.submit_gdd` 原生工具与提交点 | `M1B-1` | 全部拒绝分支；提交点前后强杀恢复；同 submissionId replay 不产生 vN+1 | | `M1C-0` | 新增 `StaticDelegateContractStatus::UserRevisionRequested` 与分类分支 | `M1A-1` | **本 PR 无写入方、是惰性路径，行为零变化**；做游戏链路返工仍在 `depth=1` 被拒；无该变体的历史记录分类不变 | -| `M1C-1` | `gdd-approval` pending、审批命令、receipt；receipt 写入上述 status | `M1B-2`、`M1C-0` | 第 13.0 节审批前置门：取证未通过时不出现审批卡；连续多次修订均可通过且 `repair_depth` 不变 | -| `M1C-2a` | Goal Contract 接线：turn 1 冻结、固定验收图、审批前置门取证 | `M1C-1` | turn 1 只能是一个 `agent.goal_contract`；`acceptanceNodes` 不接受自定义 | +| `M1C-1` | `gdd-approval` pending、审批命令、receipt；receipt 写入上述 status | `M1B-2`、`M1C-0` | 三动作全通；版本+指纹竞态防护；两窗口并发；**连续多次修订均可通过且 `repair_depth` 不变** | +| `M1C-2a` | Goal Contract 接线：turn 1 冻结、固定验收图、审批前置门取证 | `M1C-1` | turn 1 只能是一个 `agent.goal_contract`；`acceptanceNodes` 不接受自定义；**第 13.0 节审批前置门：取证未通过时不出现审批卡、而是产生返工委派**（取证顺序是协议时序问题，归本包而非 `M1C-1`） | | `M1C-2b` | 澄清中转接线、轮次派生、预算注入 | `M1C-2a` | 3 轮上限；continuation 重放幂等不增加轮次；答案绑定冲突被拒 | | `M1D-1` | 前端 hydrate 与 GDD 审批卡 | `M1C-2b` | 前端只经 `hydrate_game_creator_plan_gdd_state` 读权威状态，不在页面侧合成批准事实 | | `M1D-2` | 入口分流与阶段进度 | `M1D-1` | 「直接开建」跳过路径与现状零差异 | @@ -1981,7 +1981,7 @@ M0 完成不表示任何策划功能已上线。M1 的功能实现仍未开始 - 不可变事实只增不改；其它内容都能从事实或 session checkpoint 有界恢复。 - approvalRequestId 属于不可变 GDD，approval receipt 的 responseId 属于一次审批决定，两者都不可在重试中漂移；user-input answer/checkpoint 的同名 responseId 属于独立回答幂等域，不能跨域复用或恢复。 - decisionFingerprint 解决意图幂等，receiptFingerprint 保护完整信任根。 -- **（2026-08-13 按 D11 二次拆写，取代 2026-08-12 按 D9 的拆写）** 策划子 Agent（`agentId=project-planning`，由 Supervisor 静态委派而非 ready-task 调度启动）无 command/smoke/preview/再委派/MCP，其工具面是 exact allowlist 且不含 `user.input_request`——该排除由执行层 `validate_user_input_action_owner` 兜底，广告层仍可见；Supervisor 根 run 保持现役 `standard` 工具面，其 Provider 不直接向用户提问，而是认领子 Agent 的 `AGC_NEEDS_USER_INPUT_V1` 终态信封后代为创建 pending（详见第 19 节第 2 条）。内部 Markdown 投影不推进代码 revision。 +- **（2026-08-13 按 D11 二次拆写，取代 2026-08-12 按 D9 的拆写）** 策划子 Agent（`agentId=project-planning`，由 Supervisor 静态委派而非 ready-task 调度启动）无 command/smoke/preview/再委派/MCP，其工具面是 exact allowlist 且不含 `user.input_request`——**目标态是广告层与执行层都拒**：allowlist 让它不出现在函数目录，执行层 `validate_user_input_action_owner` 兜底（2026-08-13 按第 19 节第 2 条更正；原文「广告层仍可见」描述的是 M1 之前的现状，不是终态合同）；Supervisor 根 run 保持现役 `standard` 工具面，其 Provider 不直接向用户提问，而是认领子 Agent 的 `AGC_NEEDS_USER_INPUT_V1` 终态信封后代为创建 pending（详见第 19 节第 2 条）。内部 Markdown 投影不推进代码 revision。 - 用户侧只有一个对话对象；所有呈现给用户的对话内容必须物理存在于 Supervisor 的会话文件中，不得由前端把多个 Agent 的会话拼接成单一视图。 - 前端只通过 `hydrate_game_creator_plan_gdd_state` 读取策划权威状态；文件、Markdown 和 runtime polling 不能在页面侧合成批准事实。 - 完整构建只认后端在项目锁内重算并冻结的 approvedGddRef；直接开建必须显式声明，不能由缺字段降级。根 Run 被 steer 替换时，replacement root run 必须重新冻结同一 ref，不换稿、不降级、不留空窗。