立项策划：完成 M1B-2 GDD 提交与恢复
接入 plan.submit_gdd 原生工具及 exact planning Provider 绑定与结构化注入 实现 create-only GDD 提交点、索引 Markdown session 恢复与策划子 run 收口 补齐定向门禁与阶段文档记录，审批 receipt UI 和构建准入留待后续
This commit is contained in:
@@ -1,5 +1,16 @@
|
||||
# 决策记录
|
||||
|
||||
## 2026-08-14 M1B-2 实现合同收口：Provider binding、结构化注入与提交恢复边界
|
||||
|
||||
- **状态与基线**：`M1B-1` 已通过门禁并合入，作为 `.agent/planning/` storage 基线；`M1B-2` 工作包已在隔离分支通过本包门禁，当前待合回原分支。当前包接 `plan.submit_gdd`、exact planning Provider 请求身份、提交点和恢复；`gdd-approval` planning pending、审批等待、receipt、审批命令与 UI 继续属于 `M1C-1` 及之后。本状态只表示 M1B-2 工作包完成，不表示完整产品可交付。
|
||||
- **binding 是有自指纹的 exact v1，不是可扩展 map**：`plan-provider-session-binding.v1` 在 `runId` 后固定包含 `rootAgentId`，并在 `requestContextFingerprint` 后以 required typed `fingerprint` 收尾；typed value 排除自身 fingerprint 但覆盖 `rootAgentId`，base Provider request ID value 同样在 `runId` 后覆盖 `rootAgentId`。`rootAgentId` 与末尾 fingerprint 是本次实现对委派根身份和 binding 自完整性的有意加固，不再称“额外字段”；缺失、重排、未知字段、重算不等或从当前状态补默认值都失败关闭。无 Goal 的唯一合法三元组是 `goalId=null / goalRevision=0 / goalSnapshotFingerprint=""`；Agent DB validator 不能先用通用非空 identity 门把这个合法空 fingerprint 拒掉。
|
||||
- **四类请求共用同一 captured context**：exact planning 的 `tool-plan | final-reply | context-compaction | final-reply-context-compaction` 全部写 `game-creator-provider-request-lifecycle.v3`、同一 required binding 和同一 structured injection；只有 `tool-plan` 能产生 action、`game-creator-provider-action-batch.v4` 与 `plan.submit_gdd`，其余三类无 action batch。planning idle context compaction 因没有 active run/session captured context 而明确不支持、fail-closed。request-context 的 `composition` 与 `sourceKind` 都固定为现役 Prompt Bundle 值 `runtime`，不得把 durable source `agent-delegate` 复制进 `sourceKind`；MCP 固定为空且 planning builder 不读取项目 MCP catalog，避免“先读后清空”制造额外依赖或漂移。
|
||||
- **structured injection 的 wire 冻结**：`plan-provider-structured-injections.v1` 顶层顺序为 `schemaVersion, clarificationRound, accumulatedAgentMillis, session, platformFacts, approvalObservation`；session 顺序为 `phase, decisionsSummary, prototypeValidationItems, latestSubmittedRef, lastDecisionRef`；平台事实复用固定 `PlanPlatformFacts`；approval observation 只能为 `null` 或现役 `tool, status, summary, detail` 四字段 strict 对象。canonical compact JSON 最大 64 KiB，以 dedicated user message 真正进入最终 `LlmRunRequest`：第一行 `AGC_PLAN_PROVIDER_STRUCTURED_INJECTIONS_V1`，第二行 JSON，无第三行与尾换行。同一第二行 JSON bytes 同时生成 `structuredInjections.wireBytes/wireSha256`，禁止重建另一份“语义相同”对象再摘要。
|
||||
- **submit 的包内 policy 与 session 真相**：`plan.submit_gdd` 配为 `confirm` 时按 deny 失败关闭，不创建 M1B-2 无法消费的 generic confirmation；显式 deny 同样拒绝。输入的 decisions 先逐项严格匹配 source session 的完整前缀，之后只允许追加 `default_pending/default/round=0` 的默认决定，不能把未提问项伪造成用户已确认。
|
||||
- **提交点不等于审批等待**：M1B-2 在 create-only GDD 提交点之后只重建 index、`game/fast_gdd.md` 与 session successor，再终止策划子 run/delivery；不创建 planning pending 或 waiting 投影。child terminal ensure 按原 action identity 可重入，task/event/delivery/Agent DB audit 各自幂等；delivery 必须发布后 exact 回读，未 durable 前不能先写 `recoveryPending=false` 的 committed audit。原 submit 在提交前已经建立的 generic `game-creator-pending-action.v5` standalone pending 与 v4 action batch 继续保留，供 M1C-1 receipt/terminal observation 按同 action identity 消费。standalone pending 保存 `providerBatchPlanUpdate`，使 pending-only 能精确重建完整 plan/planUpdate/batchId；batch-only 则补回同 identity pending。两枚 anchor 都在时严格对账；恰缺一枚且另一枚与 immutable GDD/frozen binding 严格匹配时确定性重建缺失投影；两枚都缺失、任一损坏或 identity 漂移时进入 reconciliation，不能只凭 GDD 猜完整 action/batch wire。双缺扫描覆盖 GDD commit 后、child finish 前且 Runtime `pendingToolAction=null` 的真实窗口，重复扫描不重复写 audit；已提交事实优先于其后的 repository/steer 漂移，同 action 只收口原投影、不生成新版本。
|
||||
- **本包门禁结果**：四类 request 的 binding/lifecycle/wire、structured DTO 字段与 64 KiB 边界、`composition/sourceKind=runtime`、idle compaction 拒绝、submit 业务/身份拒绝、提交点前后恢复、同 submission replay 不增版本、index/Markdown/session/child terminal 断点，以及 generic anchors 双在/单缺/双缺/漂移矩阵均已有定向证据；范围匹配的 Rust 门禁、`cargo check --offline`、`cargo fmt --check`、`npm run check:encoding` 与 `git diff --check` 已通过。隔离分支尚待合入；审批 pending/receipt/UI/构建准入仍不在本包。
|
||||
- 关联文档：`docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md` 第 3、8.1、9、12、21、23.6、23.8 节。
|
||||
|
||||
## 2026-08-14 M1C-0：用户修订状态进入静态委派 lineage 分类
|
||||
|
||||
- 落地：`StaticDelegateContractStatus` 新增 `UserRevisionRequested`（serde durable 值为 `user-revision-requested`）。`static_delegate_lineage_counters` 现在按三类传播：`NeedsUserInput` 只增加 `clarification_round`；`UserRevisionRequested` 原样继承 `repair_depth` 与 `clarification_round`；其它状态继续按质量返工增加 `repair_depth` 并重置 `clarification_round`。
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# 立项策划 Agent（Fast GDD）技术方案
|
||||
|
||||
- 日期：2026-08-10
|
||||
- 状态：2026-08-12 **M0 代码工作包全部完成**（`M0A-2`、`M0B-1`、`M0B-2` 已合入 M0 集成分支并通过各自门禁，见第 23.4 节）；同日 **D6 作废、拓扑改变**，`M0A-1` 交付的文档基线随之失效，需以工作包 `M0A-3` 修订，**修订完成前 M0 不计完整完成**（见第 1.1 节）。2026-08-13 **D9 二次作废、D10 作废，由 D11 取代**：立项策划节点改为 Project Supervisor 通过 `agent.delegate` 发起的静态委派子 Agent，问询复用 PR #165 中转链路（见第 1.1 节「D11 新拓扑」）；D11 依赖 WP1（静态委派澄清轮次与返工深度拆分）为强制前置，**该前置已于 2026-08-13 落地并合入**（`WP1` 生产代码 + `WP2` 回归，完成状态与门禁见第 23.5 节），澄清轮次上限现为 3（game-chat source 仍为 1）。随后 `M1A-1`、`M1A-2`、`M1A-3`、`M1A-4` 已分别落地：`M1A-2` 仅收口两层工具面、`project-planning` role brief 注入和 fail-closed 拒绝边界，`M1A-4` 收窄 plan 根 run 的子 Agent 创建面。**2026-08-14 M1B-1 已在隔离 worktree 完成并通过本包验收门禁，已提交于隔离分支 `f453c2ca2`，待合回原分支**：已落地 `.agent/planning` storage module、strict schema/typed 指纹/canonical parser、GDD 版本链、session 原子恢复、Runtime 写入身份及只挡写门禁；golden vector 与 11 个定向 storage 测试通过，writer/index/recovery 及全仓库门禁已完成。**2026-08-14 `M1C-0` 亦已在隔离 worktree 完成并合回本分支**：仅新增用户修订状态及 lineage 分类，不包含审批写入方。`plan.submit_gdd`、审批闭环和 UI 仍未实现，见第 23.6、23.8 节。后续执行计划见第 23.6 节。
|
||||
- 状态：2026-08-12 **M0 代码工作包全部完成**（`M0A-2`、`M0B-1`、`M0B-2` 已合入 M0 集成分支并通过各自门禁，见第 23.4 节）；同日 **D6 作废、拓扑改变**，`M0A-1` 交付的文档基线随之失效，需以工作包 `M0A-3` 修订，**修订完成前 M0 不计完整完成**（见第 1.1 节）。2026-08-13 **D9 二次作废、D10 作废，由 D11 取代**：立项策划节点改为 Project Supervisor 通过 `agent.delegate` 发起的静态委派子 Agent，问询复用 PR #165 中转链路（见第 1.1 节「D11 新拓扑」）；D11 依赖 WP1（静态委派澄清轮次与返工深度拆分）为强制前置，**该前置已于 2026-08-13 落地并合入**（`WP1` 生产代码 + `WP2` 回归，完成状态与门禁见第 23.5 节），澄清轮次上限现为 3（game-chat source 仍为 1）。随后 `M1A-1`、`M1A-2`、`M1A-3`、`M1A-4` 已分别落地：`M1A-2` 仅收口两层工具面、`project-planning` role brief 注入和 fail-closed 拒绝边界，`M1A-4` 收窄 plan 根 run 的子 Agent 创建面。**2026-08-14 `M1B-1` 已通过门禁并合入本分支**：已落地 `.agent/planning` storage module、strict schema/typed 指纹/canonical parser、GDD 版本链、session 原子恢复、Runtime 写入身份及只挡写门禁；golden vector 与 11 个定向 storage 测试通过，writer/index/recovery 门禁已完成。**2026-08-14 `M1B-2` 工作包已在隔离分支通过本包门禁，待合回原分支**：已落地 `plan.submit_gdd`、exact planning Provider binding/structured injection、专用提交点与崩溃恢复；本包不包含 `gdd-approval` planning pending、审批等待、receipt、审批命令或 UI。**2026-08-14 `M1C-0` 已合回本分支**：仅新增用户修订状态及 lineage 分类，不包含审批写入方。当前仅表示 M1B-2 工作包完成，完整审批闭环、UI、构建准入仍未实现，见第 23.6、23.8 节。后续执行计划见第 23.6 节。
|
||||
- 适用范围：AI 游戏创作独立 App、Project Supervisor、Agent Runtime、本地项目策划 sidecar 与后续完整构建准入
|
||||
- 当前实现边界：本文件是后续详细设计与实现的仓库内阶段基线；M0 工作包冻结 Fast GDD 合同并修复现有 owner 验证、game-chat retry 与前端投影边界，`M1A-1`～`M1A-4` 已提供 plan source、两层工具面、角色 brief 与子 Agent 创建面收窄的 Runtime 基础，`M1C-0` 已提供用户修订 lineage 分类，`M1B-1` 当前 worktree 已提供 storage 基础与写入隔离，但尚未宣称最终合入完成；立项策划入口、`plan.submit_gdd` 提交、审批 UI 或构建绑定仍不可用
|
||||
- 当前实现边界：本文件是后续详细设计与实现的仓库内阶段基线；M0 工作包冻结 Fast GDD 合同并修复现有 owner 验证、game-chat retry 与前端投影边界，`M1A-1`～`M1A-4` 已提供 plan source、两层工具面、角色 brief 与子 Agent 创建面收窄的 Runtime 基础，`M1C-0` 已提供用户修订 lineage 分类，已合入的 `M1B-1` 提供 storage 基础与写入隔离；`M1B-2` 工作包已在隔离分支通过本包门禁、待合入，但不构成完整可交付：审批 UI、receipt、审批等待、构建绑定和正式入口仍不可用
|
||||
|
||||
## 1. 背景与目标
|
||||
|
||||
@@ -157,7 +157,7 @@ WP1 定稿的澄清轮次/返工深度语义（供 D11 依赖，权威定义见
|
||||
| Rust source 常量 | `AGENT_RUNTIME_SUPERVISOR_PLAN_SOURCE` |
|
||||
| run profile | `standard`（Supervisor 根 run 与策划子 Agent 必须同为此值。**2026-08-13 按 D11 更正成立理由**：不是 ready-task 调度的约定，而是委派通用的父子继承——`bind_game_creator_agent_runtime_run_profile_at` 强制子 Run 等于父 Run 已绑定的 profile，「子 Run 不能切换父 Run 的 Run Profile」） |
|
||||
| Prompt composition | **不新增**。策划子 Agent 复用现役 `runtime` composition（委派/孤立子 Agent 通用模板），Supervisor 入口沿用现役 supervisor composition。**2026-08-13 按 D11 取代原冻结值 `projectPlanning`**：`manifest.json` 的 `compositions` 只有 `runtime`/`supervisor`/`supervisorChat` 三个固定字段，校验不遍历 `agentCatalog`，新增子 Agent 不需要也不能配第四套（依据见第 3.1 节） |
|
||||
| Prompt source kind | `ProjectPlanning` |
|
||||
| Prompt source kind | **不新增**；策划子 Agent 的 exact planning Provider request 固定使用现役 `runtime`，不得把 durable source `agent-delegate` 复制进 sourceKind |
|
||||
| 原生 action tool | `plan.submit_gdd`。**2026-08-13 按 D11 删除 `plan.request_decision`**：该工具是 D10「Runtime 直投」的配套，其存在的唯一理由是「standard ready-task 节点无 parent、Runtime 拦不住直接提问，只能另造工具绕开」；D11 下策划 Agent 是委派子 Agent、天然带 parent，问询改走 `AGC_NEEDS_USER_INPUT_V1` 终态信封 + Supervisor 中转，该工具连同 D10 一并作废，从未实现，全仓库零命中 |
|
||||
| 问询载体 | `AGC_NEEDS_USER_INPUT_V1` 终态信封（复用 PR #165 已实现的静态委派澄清中转，非本方案新增合同），单次信封 1～3 题 |
|
||||
| pending kind | `gdd-approval` |
|
||||
@@ -166,7 +166,8 @@ WP1 定稿的澄清轮次/返工深度语义（供 D11 依赖，权威定义见
|
||||
| submit input schema | `plan-submit-gdd-input.v1` |
|
||||
| ~~回答解释 checkpoint schema~~ | **2026-08-13 随 D10 删除**（原值 `plan-decision-checkpoint.v1`）。D11 下解释由 continuation 子 Agent 的第一个普通 tool-plan turn 产生，走现役 handoff 通道，不需要专用 schema |
|
||||
| Provider session binding schema | `plan-provider-session-binding.v1`（durable lifecycle/batch 嵌套对象） |
|
||||
| plan Provider request kinds | `tool-plan \| final-reply`（**2026-08-13 按 D11 移除 `plan-decision-checkpoint`**） |
|
||||
| Provider structured injections schema | `plan-provider-structured-injections.v1`（作为 dedicated user message 进入实际 `LlmRunRequest`，精确 wire 见第 12 节） |
|
||||
| plan Provider request kinds | `tool-plan \| final-reply \| context-compaction \| final-reply-context-compaction`（**2026-08-13 按 D11 移除 `plan-decision-checkpoint`**；2026-08-14 将 exact planning 的两类 context compaction 纳入同一 v3 binding） |
|
||||
| plan Provider request lifecycle schema | `game-creator-provider-request-lifecycle.v3` |
|
||||
| plan Provider action batch schema | `game-creator-provider-action-batch.v4` |
|
||||
| GDD schema | `plan-gdd.v1` |
|
||||
@@ -453,7 +454,7 @@ exact plan source 的 `user.input_request` 仍是四个 action tool 之一，不
|
||||
}
|
||||
```
|
||||
|
||||
三个 option 的标签与顺序必须逐字等于上表；plan question ID 在现役 snake_case 规则上进一步限制为最多 32 个 ASCII 字符，并且不能映射成 `initial-request`。Runtime 确定性令 `decisionId = questionId.replace('_', '-')`，因此该 ID 必然满足第 8.3 节 GDD decision ID 合同，Provider 不能另选身份。Provider batch 仍须满足 `user.input_request` sole-action 规则；exact plan 的普通 tool-plan 只要产生 action，即使仅一项也必须强制 durable 写 v4 batch，不能走现役“少于两项则 NotNeeded”的优化。`user.input_request` 与 `plan.submit_gdd` 因此都有唯一 v4 member；decision-checkpoint/final-reply 无 action 才不创建 batch。非 plan source 的 input wire、数量和校验保持现状，任何额外 plan metadata 都因 unknown field 失败。
|
||||
三个 option 的标签与顺序必须逐字等于上表；plan question ID 在现役 snake_case 规则上进一步限制为最多 32 个 ASCII 字符，并且不能映射成 `initial-request`。Runtime 确定性令 `decisionId = questionId.replace('_', '-')`，因此该 ID 必然满足第 8.3 节 GDD decision ID 合同，Provider 不能另选身份。Provider batch 仍须满足 `user.input_request` sole-action 规则；exact plan 的普通 tool-plan 只要产生 action，即使仅一项也必须强制 durable 写 v4 batch，不能走现役“少于两项则 NotNeeded”的优化。Supervisor 的 `user.input_request` 与策划子 Agent 的 `plan.submit_gdd` 因此各有唯一 v4 member；exact planning 的 `final-reply`、`context-compaction`、`final-reply-context-compaction` 无 action、不创建 batch，但仍写第 12 节 v3 lifecycle/binding。非 plan source 的 input wire、数量和校验保持现状，任何额外 plan metadata 都因 unknown field 失败。
|
||||
|
||||
> **2026-08-13 按 D11 重写本节后半（原 D10「Runtime 直投」状态机整段作废）。** 原文描述的链路是：策划节点持续存活于同一 run，自己调 `user.input_request`，Runtime 在同一 run 内截获、写 `activeQuestion` session checkpoint，回答后再发一次 `plan-decision-checkpoint` 专用 Provider 请求取得设计解释，并以新 session primary 作为线性化点。D11 下这条链路的每一环都换了承载物，且**不是换实现是换机制**——用的是 PR #165 已发布、已有回归覆盖的静态委派澄清中转，不再自造状态机。
|
||||
|
||||
@@ -478,7 +479,7 @@ exact plan source 的 `user.input_request` 仍是四个 action tool 之一，不
|
||||
|
||||
**轮次计数。** 本轮是第几轮由委派链上的 `clarification_round` 派生值决定（沿 `repair_of_delegation_id` 上溯推断，语义见第 23.5 节），上限 3；session 不再自累加 `roundsUsed`。达到上限后 Runtime 在下一轮子 run 的上下文里注入「必须出稿」，若子 Agent 仍输出信封则拒绝该信封并要求改为 `plan.submit_gdd`。
|
||||
|
||||
**Provider batch 规则。** exact plan 的普通 tool-plan 只要产生 action，即使仅一项也必须强制 durable 写 v4 batch，不走现役「少于两项则 NotNeeded」的优化。Supervisor 侧的 `user.input_request` 与策划子 Agent 侧的 `plan.submit_gdd` 因此各有唯一 v4 member；final-reply 无 action 才不创建 batch。非 plan source 的 input wire、数量和校验保持现状，任何额外 plan metadata 都因 unknown field 失败。
|
||||
**Provider batch 规则。** exact plan 的普通 tool-plan 只要产生 action，即使仅一项也必须强制 durable 写 v4 batch，不走现役「少于两项则 NotNeeded」的优化。Supervisor 侧的 `user.input_request` 与策划子 Agent 侧的 `plan.submit_gdd` 因此各有唯一 v4 member；exact planning 的 `final-reply`、`context-compaction`、`final-reply-context-compaction` 均无 action batch但仍写 v3 lifecycle/binding，planning idle compaction 不支持。非 plan source 的 input wire、数量和校验保持现状，任何额外 plan metadata 都因 unknown field 失败。
|
||||
|
||||
### 5.3 Fast GDD 固定内容
|
||||
|
||||
@@ -539,7 +540,7 @@ MVP 明确排除多人、商城、服务器、开放世界、赛季、复杂社
|
||||
|
||||
【输出模式】
|
||||
- 澄清模式：只提交当前决策卡，不输出完整 GDD。
|
||||
- 成稿模式：调用 plan.submit_gdd，等待审批；不展示内部思考过程。
|
||||
- 成稿模式：调用 plan.submit_gdd 后结束当前策划子 Run；审批由 Supervisor 承接，不展示内部思考过程。
|
||||
- 收到 revise/reject observation 后，在同一 gddId 下修订并提交下一版本；收到 approve 后只做一句收尾确认。
|
||||
```
|
||||
|
||||
@@ -580,8 +581,8 @@ Runtime 还必须提供三类结构化注入，而不是让 Prompt 猜测：当
|
||||
- 拒绝 NUL、DEL，以及除 LF/TAB 外的 C0 控制字符。长度按 Unicode scalar count；另执行 serialized UTF-8 byte 上限。不得静默截断。
|
||||
- 一般 opaque Runtime ID 满足 `[A-Za-z0-9][A-Za-z0-9._:-]{0,127}`；现役 actionId 另固定为 `action-[0-9a-f]{24}`。`gddId` 为 `gdd-` 加小写 RFC 4122 UUID；`approvalRequestId` 为 `gdd-approval-` 加小写 UUID；approval command/receipt 的 responseId 为 `gdd-response-` 加小写 UUID。user-input answerResponseId 是明确例外：继续按现役 trim 后 1～160 scalar、无控制字符合同读取，UI 继续生成 `app-user-input-*`，不套用 GDD 审批前缀或一般 opaque ID 的 128 字符上限。
|
||||
- 时间统一为 UTC、固定毫秒精度 `YYYY-MM-DDTHH:mm:ss.SSSZ`，由 Runtime 生成；输入时间不接受时区偏移或更高精度。
|
||||
- planning typed fingerprint（GDD、decision、receipt、session、pending、comment）完整匹配 `sha256-serde-json-v2:[0-9a-f]{64}`。现役 `actionFingerprint` 与 `runProfileBindingFingerprint` 保持已有 `[0-9a-f]{64}` 裸 digest，M1 不做全局格式迁移；两类字段不得互相比较。
|
||||
- submit input 与 GDD 最大 64 KiB，单个 plan decision checkpoint 4 KiB，Provider session binding 8 KiB，session 64 KiB，approval/pending 各 16 KiB，index 256 KiB，Markdown 128 KiB，hydrate view 512 KiB；限制按最终 UTF-8 bytes 计算。
|
||||
- planning typed fingerprint（GDD、decision、receipt、session、pending、comment、Provider session binding）完整匹配 `sha256-serde-json-v2:[0-9a-f]{64}`。现役 `actionFingerprint` 与 `runProfileBindingFingerprint` 保持已有 `[0-9a-f]{64}` 裸 digest，M1 不做全局格式迁移；两类字段不得互相比较。
|
||||
- submit input 与 GDD 最大 64 KiB，Provider session binding 8 KiB，Provider structured injections 64 KiB，session 64 KiB，approval/pending 各 16 KiB，index 256 KiB，Markdown 128 KiB，hydrate view 512 KiB；限制按最终 UTF-8 bytes 计算。（随 D10 作废的 plan decision checkpoint 不再分配容量。）
|
||||
- 一个 lineage 最多 128 个版本；版本是 `u32` 且只能为 `1..=128`。到达上限返回 `PLAN_VERSION_LIMIT_REACHED`，不能绕回、删除或另建 lineage。
|
||||
- v1 所有 `basis` 必须为 `null`；非空值返回 `PLAN_UNSUPPORTED_KNOWLEDGE_BASIS`。
|
||||
|
||||
@@ -969,6 +970,7 @@ domain 固定为：
|
||||
| session | `genarrative.plan.session.v1` | `sessionFingerprint` |
|
||||
| approval pending | `genarrative.plan.gdd-approval-pending.v1` | `pendingFingerprint` |
|
||||
| decision comment | `genarrative.plan.gdd-comment.v1` | 无 |
|
||||
| Provider session binding | `genarrative.plan.provider-session-binding.v1` | 末尾 `fingerprint` |
|
||||
| Provider request context | `genarrative.plan.provider-request-context.v1` | 无 |
|
||||
|
||||
（**2026-08-13 删除**：原此处规定「回答解释 checkpoint 的字段声明顺序固定为第 5.2 节 `decisionCheckpoint` 内显示顺序」。该 payload 随 D10 的 `plan-decision-checkpoint` 请求 kind 一并作废，其 domain 也已从上表移除。D11 下这一轮的设计解释由 continuation 子 Agent 的第一个普通 tool-plan turn 产生，走现役 `tool_plan_handoff` 通道，不需要专用 typed 指纹。）
|
||||
@@ -977,7 +979,9 @@ domain 固定为：
|
||||
|
||||
receipt fingerprint payload 的字段声明顺序固定为第 8.5 节除 `receiptFingerprint` 外的显示顺序。它包含 Runtime 生成的 `decidedAtUtc`，读取、恢复和构建准入时必须重算。
|
||||
|
||||
exact plan 的 base Provider request ID 不复用现役换行拼接算法，也不改变非 plan request identity。它对 domain `genarrative.plan.provider-request-id.v1` 的 canonical envelope bytes 直接取 SHA-256，输出仍保持 `provider-request-<64 位小写 hex>`。value 字段声明顺序固定为 `projectId, gddId, agentId, taskId, sessionId, runId, rootRunId, delegationId, source, runProfile, runProfileBindingFingerprint, goalId, goalRevision, goalSnapshotFingerprint, sessionRevision, sessionFingerprint, appliedSteerCursor, requestKind, requestSlot, webSearchEnabled, requestContextFingerprint`；所有字段来自同一 captured context/lifecycle binding。（**2026-08-13 按 D11 更正**：移除随 D10 作废的 `supersededCheckpointProviderRequestIds`——它只服务 checkpoint 协议修复的传递闭包；补入 `rootRunId` / `delegationId`，因为 D11 下同一 gddId 会跨多个策划子 run，request identity 必须能定位到具体是哪一跳。）attempt 0 等于 base ID；attempt N>0 对 domain `genarrative.plan.provider-request-attempt.v1` 与 strict value `{baseProviderRequestId, attempt}` 的 canonical envelope bytes 取 SHA-256，并保持相同外形。合法 session/context 前滚会改变 base ID 并从 attempt 0 开始；只有同一 session/context 的 transient retry 或物理 interrupted retry 可增加 attempt。
|
||||
`plan-provider-session-binding.v1` 的 typed fingerprint value 字段声明顺序固定为 `schemaVersion, projectId, gddId, agentId, taskId, providerRequestId, sessionId, runId, rootAgentId, rootRunId, delegationId, goalId, goalRevision, goalSnapshotFingerprint, source, runProfile, runProfileBindingFingerprint, sessionRevision, sessionFingerprint, appliedSteerCursor, requestKind, requestSlot, webSearchEnabled, requestContextFingerprint`。durable JSON 在这些字段之后还必须以 `fingerprint` 收尾；该字段排除在自身 typed value 之外，但读取时必须按上述 domain 重算并逐字相等。`rootAgentId` 与末尾 required `fingerprint` 是 M1B-2 实现对委派根身份和 binding 自完整性的有意加固，属于 v1 当前 exact 合同，不得再称为“额外字段”或在恢复时补默认值；缺失、重排或夹带其它字段都失败关闭。
|
||||
|
||||
exact plan 的 base Provider request ID 不复用现役换行拼接算法，也不改变非 plan request identity。它对 domain `genarrative.plan.provider-request-id.v1` 的 canonical envelope bytes 直接取 SHA-256，输出仍保持 `provider-request-<64 位小写 hex>`。value 字段声明顺序固定为 `projectId, gddId, agentId, taskId, sessionId, runId, rootAgentId, rootRunId, delegationId, source, runProfile, runProfileBindingFingerprint, goalId, goalRevision, goalSnapshotFingerprint, sessionRevision, sessionFingerprint, appliedSteerCursor, requestKind, requestSlot, webSearchEnabled, requestContextFingerprint`；所有字段来自同一 captured context/lifecycle binding。（**2026-08-14 按当前实现收口**：在 D11 已补入的 `rootRunId` / `delegationId` 前进一步补入 `rootAgentId`，避免只凭 run 字符串猜根 Agent；随 D10 作废的 `supersededCheckpointProviderRequestIds` 继续不存在。）attempt 0 等于 base ID；attempt N>0 对 domain `genarrative.plan.provider-request-attempt.v1` 与 strict value `{baseProviderRequestId, attempt}` 的 canonical envelope bytes 取 SHA-256，并保持相同外形。合法 session/context 前滚会改变 base ID 并从 attempt 0 开始；只有同一 session/context 的 transient retry 或物理 interrupted retry 可增加 attempt。
|
||||
|
||||
### 9.1 GDD golden vector
|
||||
|
||||
@@ -1049,11 +1053,11 @@ flowchart LR
|
||||
|
||||
## 12. GDD 提交合同
|
||||
|
||||
> **2026-08-13 按 D11 更正。** 提交者由「唯一那个 plan run」改为**策划子 Agent**（`agentId=project-planning`，`source=agent-delegate`）；binding 补 `rootRunId` / `delegationId`；随 D10 作废的 `plan-decision-checkpoint` request kind 与 `supersededCheckpointProviderRequestIds` 数组一并移除。提交点、幂等域与 create-only 发布语义**未变**。
|
||||
> **2026-08-13 按 D11 更正。** 提交者由「唯一那个 plan run」改为**策划子 Agent**（`agentId=project-planning`，`source=agent-delegate`）；binding 补 `rootRunId` / `delegationId`；随 D10 作废的 `plan-decision-checkpoint` request kind 与 `supersededCheckpointProviderRequestIds` 数组一并移除。**2026-08-14 再按 M1B-2 实现加固**：binding 与 typed/base request identity 补 `rootAgentId`，binding 末尾加入 required typed `fingerprint`。提交点、幂等域与 create-only 发布语义**未变**。
|
||||
|
||||
`plan.submit_gdd` 由策划子 Agent 调用，但只有 Runtime 写文件。它必须是一次 Provider 响应中的唯一 action tool；同一响应可以更新 `update_agent_plan`，但不得把 submit 与 `file.read`、`file.list` 或第二次 submit 混入同一 action batch。（`user.input_request` 不在策划子 Agent 的工具面内，故不存在与它混批的情形；Supervisor 侧则不持有 `plan.submit_gdd`。）Runtime 在 batch 建立 durable actionId 之前拒绝混批，避免审批等待落在 generic multi-action cursor 中间。
|
||||
`plan.submit_gdd` 由策划子 Agent 调用，但只有 Runtime 写文件。它必须是一次 Provider 响应中的唯一 action tool；同一响应可以更新 `update_agent_plan`，但不得把 submit 与 `file.read`、`file.list` 或第二次 submit 混入同一 action batch。（`user.input_request` 不在策划子 Agent 的工具面内，故不存在与它混批的情形；Supervisor 侧则不持有 `plan.submit_gdd`。）Runtime 在 batch 建立 durable actionId 之前拒绝混批，避免 Runtime-owned commit 落在 generic multi-action cursor 中间。
|
||||
|
||||
产生 submit 的 Provider request 必须先冻结 durable source-session binding，不能只放在内存：
|
||||
每个 exact planning Provider request 都必须先冻结 durable source-session binding，不能只放在内存：
|
||||
|
||||
```jsonc
|
||||
{
|
||||
@@ -1065,6 +1069,7 @@ flowchart LR
|
||||
"providerRequestId": "provider-request-<64 位小写 hex>",
|
||||
"sessionId": "...",
|
||||
"runId": "...",
|
||||
"rootAgentId": "project-supervisor",
|
||||
"rootRunId": "...",
|
||||
"delegationId": "...",
|
||||
"goalId": "...",
|
||||
@@ -1076,18 +1081,49 @@ flowchart LR
|
||||
"sessionRevision": 3,
|
||||
"sessionFingerprint": "sha256-serde-json-v2:<hex>",
|
||||
"appliedSteerCursor": 0,
|
||||
"requestKind": "tool-plan",
|
||||
"requestKind": "<tool-plan|final-reply|context-compaction|final-reply-context-compaction>",
|
||||
"requestSlot": "loop-2-repair-0",
|
||||
"webSearchEnabled": false,
|
||||
"requestContextFingerprint": "sha256-serde-json-v2:<hex>"
|
||||
"requestContextFingerprint": "sha256-serde-json-v2:<hex>",
|
||||
"fingerprint": "sha256-serde-json-v2:<hex>"
|
||||
}
|
||||
```
|
||||
|
||||
`requestContextFingerprint` 使用第 9 节 helper 与 domain `genarrative.plan.provider-request-context.v1`。canonical value 的字段声明顺序固定为 `effectiveModel, apiKind, stream, officialFallback, anthropicStrictToolSupport, openAiChatTokenBudgetField, maxOutputTokens, responseReasoningEffort, responseTextVerbosity, toolChoice, composition, sourceKind, webSearchEnabled, messages, nativeTools, mcpTools, structuredInjections`。前十项必须取最终不可变 `LlmRunRequest` 与同一 captured `LlmConfig`/adapter wire 配置的实际语义值：effectiveModel 是显式 model 或 Provider 默认值解析后的非空模型名；apiKind 只取 `openai_responses | openai_chat | anthropic`；stream 是实际请求体 boolean；officialFallback 对 `openai_chat/openai_responses` 为实际 boolean、对 anthropic 必须为 `null`；anthropicStrictToolSupport 只在 anthropic 为实际 boolean、其它 apiKind 必须为 `null`；openAiChatTokenBudgetField 只在 `openai_chat` 取 `max_completion_tokens | legacy_max_tokens`、其它 apiKind 必须为 `null`；maxOutputTokens 为 `null` 或正 `u32`；reasoning/verbosity 为 `null | low | medium | high`；toolChoice 为 `null | auto | required`。只有会改变当前 apiKind 实际 wire 的配置进入非空值，避免无关 adapter 配置制造假 context/base 漂移。composition/sourceKind 按第 4.2 节：策划子 Agent 复用现役 `runtime` composition，Supervisor 沿用现役 supervisor composition，**不新增第四套**（原此处写死的 `supervisorPlanChat` / `SupervisorPlanChat` 随 D6/D11 作废）；webSearchEnabled 固定为 false；mcpTools 必须是显式空数组；structuredInjections 只含链路现算的澄清轮次/活跃毫秒、上述 Provider-facing session 语义投影、平台事实，以及存在时的审批业务 observation。`providerRequestId`、lifecycle/handoff ID、action/binding fingerprint 及其它 Provider/Runtime 控制元数据不得进入 messages、工具描述或 structured injection；它们只存在于 durable binding/base identity、session 私有 checkpoint 与恢复校验。
|
||||
binding 的 durable 字段顺序与上方 JSON 完全一致；第 9 节另行冻结排除末尾 `fingerprint` 后的 typed value 顺序，以及不含 `schemaVersion/providerRequestId/fingerprint` 的 base request ID value 顺序。`rootAgentId` 与末尾 required `fingerprint` 都是 v1 当前合同的一部分，不是 reader 可忽略的扩展字段。
|
||||
|
||||
每个 exact planning Provider request 都必须携带同一个 `plan-provider-structured-injections.v1` strict DTO；顶层字段顺序固定为 `schemaVersion, clarificationRound, accumulatedAgentMillis, session, platformFacts, approvalObservation`：
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"schemaVersion": "plan-provider-structured-injections.v1",
|
||||
"clarificationRound": 0,
|
||||
"accumulatedAgentMillis": 0,
|
||||
"session": {
|
||||
"phase": "collecting",
|
||||
"decisionsSummary": [],
|
||||
"prototypeValidationItems": [],
|
||||
"latestSubmittedRef": null,
|
||||
"lastDecisionRef": null
|
||||
},
|
||||
"platformFacts": {
|
||||
"runtime": "self-contained-web",
|
||||
"viewports": ["desktop", "mobile"],
|
||||
"inputs": ["keyboard", "touch"],
|
||||
"preview": "local-http"
|
||||
},
|
||||
"approvalObservation": null
|
||||
}
|
||||
```
|
||||
|
||||
`session` 的字段顺序固定为 `phase, decisionsSummary, prototypeValidationItems, latestSubmittedRef, lastDecisionRef`，逐项复用当前 `plan-session.v1` 的 Provider-facing 语义类型；不得把 session identity、revision、fingerprint 或 Runtime 控制元数据带入。`platformFacts` 直接复用固定 `PlanPlatformFacts`，字段顺序与值均为上方所示。`approvalObservation` 只能是 `null`，或当前 observations 中最后一条 `tool=plan.submit_gdd + status=ok` 的现役 strict 四字段对象，字段顺序固定为 `tool, status, summary, detail`，其中 `detail` 必须显式为字符串或 `null`。DTO 的 canonical compact UTF-8 JSON 最大 64 KiB，不得 pretty print、追加空白、静默截断或省略 `null`/空数组。
|
||||
|
||||
上述 canonical JSON bytes 必须以一条 dedicated `user` message **实际进入最终 `LlmRunRequest`**，wire 精确为：第一行 `AGC_PLAN_PROVIDER_STRUCTURED_INJECTIONS_V1`，第二行该 compact JSON；两行之间只有一个 LF，不存在第三行，也没有尾换行。同一份第二行 JSON bytes 不经重建地同时生成 request-context 中 `structuredInjections.wireBytes` 与 `structuredInjections.wireSha256`；前者是该 JSON 的 `u32` UTF-8 byte 长度，后者是同一 bytes 的裸 64 位小写 SHA-256。消息摘要则继续覆盖实际发送的完整 user message，因此 header、LF 或 JSON 任一字节变化也会改变 `messages` 摘要。
|
||||
|
||||
`requestContextFingerprint` 使用第 9 节 helper 与 domain `genarrative.plan.provider-request-context.v1`。canonical value 的字段声明顺序固定为 `effectiveModel, apiKind, stream, officialFallback, anthropicStrictToolSupport, openAiChatTokenBudgetField, maxOutputTokens, responseReasoningEffort, responseTextVerbosity, toolChoice, composition, sourceKind, webSearchEnabled, messages, nativeTools, mcpTools, structuredInjections`。前十项必须取最终不可变 `LlmRunRequest` 与同一 captured `LlmConfig`/adapter wire 配置的实际语义值：effectiveModel 是显式 model 或 Provider 默认值解析后的非空模型名；apiKind 只取 `openai_responses | openai_chat | anthropic`；stream 是实际请求体 boolean；officialFallback 对 `openai_chat/openai_responses` 为实际 boolean、对 anthropic 必须为 `null`；anthropicStrictToolSupport 只在 anthropic 为实际 boolean、其它 apiKind 必须为 `null`；`openAiChatTokenBudgetField` 只在 `openai_chat` 取 `max_completion_tokens | legacy_max_tokens`、其它 apiKind 必须为 `null`；maxOutputTokens 为 `null` 或正 `u32`；reasoning/verbosity 为 `null | low | medium | high`；toolChoice 为 `null | auto | required`。只有会改变当前 apiKind 实际 wire 的配置进入非空值，避免无关 adapter 配置制造假 context/base 漂移。exact planning 四类请求的 `composition` 与 `sourceKind` 都固定为现役 Prompt Bundle 值 `runtime`，**不得把 durable Runtime source `agent-delegate` 复制进 `sourceKind`**，也不新增第四套 composition/source kind（原 `supervisorPlanChat` / `SupervisorPlanChat` 随 D6/D11 作废）；webSearchEnabled 固定为 false；mcpTools 必须是显式空数组，且 `project-planning` 请求构建器直接使用空 catalog，**不得先读取项目 MCP catalog 再清空**；structuredInjections 只使用上方冻结的 DTO。`providerRequestId`、lifecycle/handoff ID、action/binding fingerprint 及其它 Provider/Runtime 控制元数据不得进入 messages、工具描述或 structured injection；它们只存在于 durable binding/base identity、session 私有 checkpoint 与恢复校验。
|
||||
|
||||
为遵守第 9 节“canonical payload 禁止 map/任意 Value”，messages 不是原始 JSON map，而是按实际发送顺序排列的 strict `{role, wireBytes, wireSha256}`；nativeTools 是按实际广告顺序排列的 strict `{name, kind, wireBytes, wireSha256}`，kind 只取 `action | control`；structuredInjections 固定为单个 strict `{wireBytes, wireSha256}`。`wireBytes` 是最终交给 provider-independent client 的单项 compact UTF-8 DTO `u32` byte 长度，`wireSha256` 是同一字节串的裸 64-hex SHA-256；消息顺序/正文、当前请求实际广告的工具名称/描述/参数 schema，以及注入对象的字段/null/空数组/正文任一字节变化都会改变它。策划子 Agent 的 tool-plan 按第 4.3 节广告恰好三个 action tool（`file.read` / `file.list` / `plan.submit_gdd`）与两个 control function；Supervisor 侧按现役 standard 工具面广告。（原此处的「四 action tool」计入了 `user.input_request`，随 D11 该工具不再属于策划子 Agent；「checkpoint 请求只广告 plan 专用 strict `update_agent_plan`」随 D10 作废。）Runtime 在内存中先完成 model/default、stream mode、adapter wire 配置与全部输出参数解析，再对实际 DTO 生成这些摘要并计算外层 typed fingerprint；lifecycle/batch 只持久化外层 fingerprint，不写 messages、Prompt、工具 schema 或注入正文。`requestTimeoutMs`、maxRetries、retryBackoffMs、rawLogDir、API Key、base URL 与 transport header 属于传输/诊断配置，不进入 fingerprint，也不得被用来改变请求正文、模型或输出语义；除这些明确排除项外，Provider client 实际收到的任一请求语义变化都必须改变 fingerprint 和 base providerRequestId。
|
||||
|
||||
Goal 三元组沿用现役精确空值合同：没有 Goal 时必须是 `goalId=null + goalRevision=0 + goalSnapshotFingerprint=""`；存在 Goal 时 goalId 为合法 opaque ID、goalRevision 大于 0、goalSnapshotFingerprint 为该 durable Goal strict snapshot 的裸 64-hex SHA-256。其它组合失败关闭。该三元组进入 binding 与 base request ID，恢复不能从当前 Goal 补写旧请求。
|
||||
Goal 三元组沿用现役精确空值合同：没有 Goal 时必须是 `goalId=null + goalRevision=0 + goalSnapshotFingerprint=""`；存在 Goal 时 goalId 为合法 opaque ID、goalRevision 大于 0、goalSnapshotFingerprint 为该 durable Goal strict snapshot 的裸 64-hex SHA-256。其它组合失败关闭。Agent DB v3 validator 必须把空 fingerprint 只留给前一种显式无 Goal 组合，不能先用通用“非空 identity”校验把合法无 Goal binding 拒掉。该三元组进入 binding 与 base request ID，恢复不能从当前 Goal 补写旧请求。
|
||||
|
||||
同快照构建算法固定如下：
|
||||
|
||||
@@ -1096,9 +1132,9 @@ Goal 三元组沿用现役精确空值合同：没有 Goal 时必须是 `goalId=
|
||||
3. 发送前重新取得项目锁，逐项重读 session revision/fingerprint、appliedSteerCursor、run/profile/Goal identity 与 captured context。任一变化都丢弃整个已构建 object，回到第 1 步；不能局部替换 binding 或 messages。
|
||||
4. 仍持锁时，从第 9 节规定的 plan request identity 生成稳定 base providerRequestId，解析本次 attempt，把上述 strict binding 先 durable 写入 lifecycle `started`；释放锁后发送的必须是第 2 步同一个 object，不能再次调用 builder。
|
||||
|
||||
成功 response handoff 创建 provider batch 时，batch 必须持久化完全相同的 `providerRequestId + planningSessionBinding`，且 batch identity 计算覆盖两者；batch 自身的 runId 与 actionId/actionFingerprint 完成 request → context → session → run → action 关联。exact plan 的 final-reply 等无 action batch 请求仍写 v3 lifecycle 和同一 binding。（原此处描述的 `plan-decision-checkpoint` 特例随 D10 作废：D11 下不存在这种「有 handoff 无 batch」的专用请求 kind。）非 plan lifecycle/batch 不伪造该 binding。
|
||||
四种 exact planning request kind 都写 `game-creator-provider-request-lifecycle.v3`、同一 strict binding 与同一 structured-injection message。只有 `tool-plan` 能产生 action，因而也只有它能产生 `game-creator-provider-action-batch.v4` 或执行 `plan.submit_gdd`；`final-reply`、`context-compaction`、`final-reply-context-compaction` 一律没有 action batch。planning 的 idle context compaction 不具备 active run/session captured context，必须 fail-closed，不得借通用 idle compaction 伪造 binding。成功 `tool-plan` response handoff 创建 provider batch 时，batch 必须持久化完全相同的 `providerRequestId + planningSessionBinding`，且 batch identity 计算覆盖两者；batch 自身的 runId 与 actionId/actionFingerprint 完成 request → context → session → run → action 关联。若项目或 Agent policy 把 `plan.submit_gdd` 配为 `confirm`，M1B-2 必须把它按 deny 失败关闭，不能创建本包没有消费路径的 generic confirmation sidecar；显式 deny 同样拒绝。（原此处描述的 `plan-decision-checkpoint` 特例随 D10 作废：D11 下不存在这种「有 handoff 无 batch」的专用请求 kind。）非 plan lifecycle/batch 不伪造该 binding。
|
||||
|
||||
外层 wire 同时冻结版本与兼容边界：exact plan 的新 lifecycle 必须使用 `game-creator-provider-request-lifecycle.v3`，在 v2 字段白名单后唯一增加 required `planningSessionBinding`；exact plan 的新 batch 必须使用 `game-creator-provider-action-batch.v4`，在 v3 字段白名单后唯一增加 required `providerRequestId` 与 `planningSessionBinding`，batch ID v4 覆盖新增字段。binding.providerRequestId 必须精确等于 lifecycle/batch 外层 request ID；agent/task/session/run/source/requestKind/requestSlot/webSearchEnabled 与存在于外层的同名字段也必须逐项相等。（**2026-08-13 删除** binding v1 的 `supersededCheckpointProviderRequestIds` 数组：它唯一的用途是维护「同一 session 内多次 checkpoint 协议修复」的传递闭包，而 D11 下每轮都是独立的新 run、上一轮已终态，不存在需要跨请求累积 superseded 闭包的情形。binding 改为携带 `rootRunId` 与 `delegationId`，把请求锚到具体委派跳。）非 plan 路径继续写现役 lifecycle v2 / batch v3。reader 继续按原合同双读既有 lifecycle v1/v2 与 batch v1/v2/v3，不原地升级或重写；这些旧记录只能按非 plan 语义恢复。任何记录声称 `source=project-supervisor-plan-chat`（作废字面量，全仓库零命中）或 `composition=supervisorPlanChat`，以及新 plan schema 缺 binding/夹带额外字段，都失败关闭并进入 reconciliation，不能用默认值补齐。
|
||||
外层 wire 同时冻结版本与兼容边界：exact plan 的新 lifecycle 必须使用 `game-creator-provider-request-lifecycle.v3`，在 v2 字段白名单后唯一增加 required `planningSessionBinding`；exact plan 的新 batch 必须使用 `game-creator-provider-action-batch.v4`，在 v3 字段白名单后唯一增加 required `providerRequestId` 与 `planningSessionBinding`，batch ID v4 覆盖新增字段。binding.providerRequestId 必须精确等于 lifecycle/batch 外层 request ID；agent/task/session/run/source/requestKind/requestSlot/webSearchEnabled 与存在于外层的同名字段也必须逐项相等。（**2026-08-14 按当前实现收口**：binding v1 携带 `rootAgentId` / `rootRunId` / `delegationId` 与末尾 required `fingerprint`，共同把请求锚到具体委派根和委派跳；随 D10 作废的 `supersededCheckpointProviderRequestIds` 数组继续不存在。）非 plan 路径继续写现役 lifecycle v2 / batch v3。reader 继续按原合同双读既有 lifecycle v1/v2 与 batch v1/v2/v3，不原地升级或重写；这些旧记录只能按非 plan 语义恢复。任何记录声称 `source=project-supervisor-plan-chat`（作废字面量，全仓库零命中）或 `composition=supervisorPlanChat`，以及新 plan schema 缺 binding/夹带合同外字段，都失败关闭并进入 reconciliation，不能用默认值补齐。
|
||||
|
||||
GDD handler 只能从已验证 batch binding 复制 `sourceSessionRevision/sourceSessionFingerprint`，并要求它与 started lifecycle 记录、request context 和 current session primary 逐项相等。GDD 已存在的同 submission replay 才按第 8.3/10.1 节复用既有 historical binding；已提交事实不因 session 后续前滚而被判 stale。
|
||||
|
||||
@@ -1124,18 +1160,18 @@ 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，执行下列提交与投影。**（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 继续。
|
||||
main loop 不能把 submit 当成普通 action dispatch：在 durable action identity 建立后、生成普通 command ID 或进入 action executor 前，必须进入 `plan.submit_gdd` 专用分支。该分支重验 exact plan identity，执行下列提交与投影。**（2026-08-14 按 M1B-2 实现边界收口）** 本包只负责校验、定版、写不可变 GDD、重建 index、渲染 `game/fast_gdd.md`、安装 session successor 并终止策划子 run；**不创建 `.agent/planning/pending.json` / `gdd-approval` planning pending，不创建审批卡，也不把 Supervisor 或策划子 run 投影为审批等待**。`gdd-approval` pending 与 Supervisor 等待态属于 `M1C-1`，还要受第 13.0 节 `M1C-2a` 验收取证门约束。原 submit 在进入专用分支前已经建立的 generic `game-creator-pending-action.v5` standalone pending 与 `game-creator-provider-action-batch.v4` action batch 必须原样保留，作为后续 receipt/terminal observation 的同 action 恢复锚点；GDD create 成功不等于该 action 已 observed。
|
||||
|
||||
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。
|
||||
3. 若已有无 receipt 的 GDD，新的不同 submissionId 返回 `PLAN_PENDING_GDD_EXISTS`。最新 GDD 已有任一有效 approve/revise/reject receipt 后才允许分配下一版本：revise/reject 由精确原 run 的 observation continuation 继续；approve 后只允许用户显式发起第 14 节恢复矩阵所述新 plan continuation。旧 approved 在新版本提交和 revise/reject 期间仍有效，只有新版本 approve 才被 supersede。
|
||||
4. 版本取最后一个连续有效版本加一；版本 1～128，不允许缺号或扫描任意文件补号。
|
||||
1. 解析第 8.2 节 strict input；在项目锁内重读 project identity、策划子 run 与委派根身份、Provider request 所绑定的 session CAS、canonical GDD 链及原 submit 的 generic v5 standalone pending / v4 batch anchors。不信任 Provider payload 中不存在也不允许出现的版本、时间、平台事实或身份；M1B-2 不读取或创建尚未实现的 approval receipt / planning pending。
|
||||
2. 验证文本上限、轮次、决定状态和 prototype item 一一对应；`decisions` 必须先逐项等于 source session 的完整决定前缀，前缀之后只允许追加 `state=default_pending + answerSource=default + round=0` 的未提问默认决定，任何伪造为用户已确认的额外决定都按 session CAS 冲突拒绝。Runtime 注入固定 platformFacts 和所有 `basis:null`，以当前 durable actionId/裸 action fingerprint 作为 submission identity。
|
||||
3. M1B-2 尚无 receipt writer：只要已有任一 GDD，新的不同 submissionId 就返回 `PLAN_PENDING_GDD_EXISTS`；同 submissionId 只允许按历史 binding replay。`M1C-1` 接入有效 approve/revise/reject receipt 后，才把边界扩为“最新版本已有 receipt 才允许下一版本”。
|
||||
4. 当前 M1B-2 的首次版本固定为 1；未来版本仍只能取最后一个连续有效版本加一，范围 1～128，不允许缺号或扫描任意文件补号。
|
||||
5. 新提交由 Runtime 生成并冻结 `approvalRequestId/createdAtUtc`，填充全部 durable identity、source session binding 和时间，计算 GDD fingerprint，以第 10.1 节算法 create-only 发布 `gdd.v{N}.json`。同 submissionId replay 必须先找到并严格读取既有 GDD，复用其中 Runtime 生成的版本、request/time 与 identity 后再比较，不能用新时间制造假冲突。
|
||||
6. GDD target 完整发布并完成父目录同步是唯一提交点。提交点前失败不产生版本；提交点后任何投影失败都仍是已提交。
|
||||
7. 提交点后按固定顺序修复：重建 index/status → 按第 7.1 节渲染 Markdown → 创建/恢复独立 planning pending 与稳定 `approvalRequestId` → checkpoint session → task/state/event 与 waiting 投影。
|
||||
7. 提交点后按固定顺序修复：从严格 GDD 链重建 index/status → 按第 7.1 节渲染 Markdown → 以原 source session CAS 安装或确认精确的 `awaiting_gdd_approval` session successor → 将策划子 run 与 delivery 投影为已提交终态。child terminal ensure 必须可重入：task projection、action-scoped event、action-scoped Agent DB audit 和 delivery 都按原 action identity 幂等；delivery 发布后必须 exact 回读同 agent/session/run/delegation 的 `completed` 终态，未 durable 前不得写 `recoveryPending=false` 的 committed audit，重复恢复不得增加第二条逻辑投影。不得在这一步创建 planning pending 或任何 waiting 投影；completed 子 run 的 `waitingOn/nextStep/lastResponse` 也不得伪装成审批等待。原 generic v5 standalone pending 与 v4 batch anchors 也不得被 terminal cleanup 删除、标为 observed 或推进 cursor。
|
||||
8. 同 submissionId + 同 canonical payload 返回同一 ref 并补投影；同 ID + 不同 payload 返回 `PLAN_SUBMISSION_IDENTITY_CONFLICT`，不得生成 vN+1。
|
||||
|
||||
等待审批由 planning pending 专用恢复路径负责，不复用通用确认 pending 的 action re-execution。main loop 恢复时若 GDD 已提交而 batch sidecar 缺失，仍从不可变 GDD和独立 pending 恢复同一 waiting action；若遗留 batch 存在，只能核对其 actionId/fingerprint/source/profile 与 GDD 相等后作为普通投影清理，不能让 submit 再次落入 generic dispatch。receipt 后，专用 continuation 把第 13.1 节 observation 幂等写回原 run/action：approve 回到 final-reply，只允许一句收尾；revise/reject 回到 tool-plan/成稿循环并继续提交同一 gddId 的下一版本。receipt、observation、session 或 recovery 状态未收口，以及 revise/reject 后尚无下一待审版本时，`plan_gdd_completion_blocker` 必须阻止最终回复。
|
||||
M1B-2 的恢复只处理提交事实及其现役 generic anchors，不恢复审批等待。若 v5 standalone pending 与 v4 batch 都存在，必须逐项核对两者、binding 与 immutable GDD 的 `submissionId/actionFingerprint/agent/task/session/run/source/profile/root/delegation` 等身份并保持原状；standalone pending 还必须携带 v4 batch 独有但重建必需的 `providerBatchPlanUpdate` recovery material，使 pending-only 能逐字恢复原完整 plan、planUpdate 与 batchId。若恰有一个缺失，而另一个与 immutable GDD 严格匹配，则从“存活 anchor + immutable GDD + frozen binding”确定性重建缺失投影，重建后回读全等，不能重新调用 Provider 或重新分配 action/GDD identity；pending-only 补原 v4 batch，batch-only 补原 standalone pending。**两者同时缺失时即使 GDD 已提交也必须 fail-closed 进入 reconciliation**，因为只靠 GDD 不能无歧义恢复完整 action/batch wire；恢复扫描必须覆盖真实的“GDD 已 create、child 尚未 finish、Runtime `pendingToolAction=null`”窗口，并且重复扫描不得重复写 reconciliation audit。任一存活 anchor 损坏或与 GDD 不匹配同样 reconciliation，不得拿另一个覆盖。已提交 GDD 是先于当前 repository/steer 漂移的业务线性化证明，同 action replay 的 `recoveryPending` 必须能穿过通用 drift barrier 收口原投影，不能误开新请求或新 GDD 版本。`M1C-1` 后续才创建 Supervisor 的 planning pending，并在 receipt 后把第 13.1 节 terminal observation 幂等写回这些原 submit anchors，再按固定顺序完成与清理；M1B-2 不提前实现该消费路径。
|
||||
|
||||
结果 DTO：
|
||||
|
||||
@@ -1149,12 +1185,14 @@ type PlanSubmitGddResult = {
|
||||
}
|
||||
```
|
||||
|
||||
只有所有提交后投影都 durable 时 `recoveryPending=false`。已越过提交点但投影未齐时仍按首次提交或重放返回 `submitted/replayed`，并以 `recoveryPending=true` 表示未收口；页面不得重新提交新版本，只能用同 action identity 触发恢复。outcome 只表达权威事实是首次创建还是重放，投影恢复状态只由 boolean 表达。
|
||||
只有 index、Markdown、session successor、策划子 run 终态及两枚 generic anchors 全部 durable 且 identity 对账通过时 `recoveryPending=false`。已越过提交点但这些投影未齐时仍按首次提交或重放返回 `submitted/replayed`，并以 `recoveryPending=true` 表示未收口；页面不得重新提交新版本，只能用同 action identity 触发恢复。outcome 只表达权威事实是首次创建还是重放，投影恢复状态只由 boolean 表达。
|
||||
|
||||
## 13. 审批 pending、提交点与幂等
|
||||
|
||||
> **2026-08-13 按 D11 更正。** `gdd-approval` pending 建在 **Supervisor 根 run** 上（`source=project-supervisor-plan`），因为审批卡是给用户看的、而用户只跟 Supervisor 对话；提交 GDD 的策划子 run 在 `plan.submit_gdd` 返回后即终态，不等待审批。receipt、幂等域、`decisionFingerprint` / `receiptFingerprint` 与投影顺序**未变**。
|
||||
|
||||
> **分包边界（2026-08-14）**：本节的 planning pending、审批等待、command 与 receipt 均从 `M1C-1` 起实现，不属于当前 `M1B-2`。M1B-2 只保留原 submit 的 generic v5 standalone pending + v4 batch anchors，二者不是审批 pending，也不得被改名或迁移为审批 pending。
|
||||
|
||||
### 13.0 审批前置门：验收取证必须先于审批卡（2026-08-13 补充）
|
||||
|
||||
原文只规定了「取证必须在 GDD 落盘之后」，**没有规定取证在用户审批之前还是之后**，第 13.3 节的 receipt 后投影顺序里也没有验收图这一步。该空白必须补上，因为反序会产生一个无回退路径的死角：
|
||||
@@ -1661,16 +1699,16 @@ Canvas 是条件外部能力，不是 M0-3 四个固定 owner 的通用前置：
|
||||
|
||||
| 层 | 必测合同 |
|
||||
| --- | --- |
|
||||
| schema | submit input + Provider session binding + hydrate view + 五个 durable/projection strict v1 struct；binding required superseded ID 数组与 session superseded handoff 摘要的 0/1/16/17 边界及逐项映射；unknown field/schema/enum；Agent 注入 Runtime 字段拒绝；ID/time/各类指纹形状；所有长度、数量、bytes 与 128 版本上限 |
|
||||
| fingerprint | 本文 golden；中文/null/空数组/数组顺序；domain separation；任一 durable identity 变化；GDD/decision/receipt/session/pending/comment/request context；裸 action/profile/answers digest 不得带 typed 前缀 |
|
||||
| schema | submit input + Provider session binding + Provider structured injections + hydrate view + 五个 durable/projection strict v1 struct；binding 的 `rootAgentId` 与末尾 `fingerprint` required，缺失/未知/重排失败关闭；structured injections 顶层、session、固定 `PlanPlatformFacts` 与四字段 observation 的 exact 顺序，`null`/空数组不省略，64 KiB 边界；unknown field/schema/enum；Agent 注入 Runtime 字段拒绝；ID/time/各类指纹形状；所有长度、数量、bytes 与 128 版本上限 |
|
||||
| fingerprint | 本文 golden；中文/null/空数组/数组顺序；domain separation；任一 durable identity 变化；GDD/decision/receipt/session/pending/comment/Provider session binding/request context；typed binding 与 base request ID 都覆盖 `rootAgentId`；裸 action/profile/answers digest 不得带 typed 前缀 |
|
||||
| create-only storage | temp 强杀无半 primary；no-replace 竞态；父目录同步；existing same replay/different conflict；symlink/reparse/目录/硬链接/路径逃逸 |
|
||||
| session | revision/hash 合法 successor；missing primary 提升；primary corrupt fail closed；分叉 reconciliation；plan question strict mapping；sidecar absent/exact pending 的前置窗口；**delivery 问题落盘后才展示**；session `appliedAnswers` 与链路现算 `clarification_round` 不一致时以 delivery 为准并进 reconciliation、不得反写链路；pre-wait 的 v4 ready/0/单 approved member + sidecar pending + standalone absent 与 waiting 的 standalone exact 状态；answer-prepared 必须重验 waiting anchor；其它状态 fail closed；delivery 问题落盘 + waiting successor 不判 stale；答案绑回 delivery 即线性化（`answersSha256` 首次或逐字相同幂等、不同答案拒绝）；不同 request 合法复用 answerResponseId；prototypeValidationItems/appliedAnswers 同异 replay；session 已落而 sidecar/observation 落后的恢复 |
|
||||
| Provider binding | effective model/api kind/stream/当前 apiKind 生效的 official fallback/Anthropic strict/OpenAI Chat token field/output tokens/reasoning/verbosity/tool choice、messages/structured injection/实际工具目录与 binding 来自同 captured session；不适用 adapter 字段为 null；Provider 元数据不得注入；任一实际语义字段变化均改变 requestContextFingerprint/base ID；plan base ID/attempt vector；旧 started 必须先 failed/interrupted 再开下一 attempt；普通 tool-plan 的 started/ready/superseded；started + ready 先补 completed；GDD/activeQuestion/appliedAnswers 三类消费证明先于 stale；checkpoint same-session repair 原样继承数组、successor replacement 传递闭包、session 摘要在 handoff 清理后的 H1…Hn 稳定收口与分叉拒绝；checkpoint raw handoff 的超限/敏感键/绝对路径/容量/identity/durable write failure 只写安全诊断并 reconciliation、零自动 repair/retry；损坏 binding 只 reconciliation |
|
||||
| submit | durable request/context/session/batch/action binding；缺失 binding 时丢弃旧响应；sole-action batch；main-loop 专用 waiting 分支；同 submission + 同/异 payload；复用既有 Runtime ID/time；session CAS；决定元数据与 session 真相逐项一致；已有未决版本；并发版本分配；版本到顶；GDD 提交点前后强杀 |
|
||||
| Provider binding | effective model/api kind/stream/当前 apiKind 生效的 official fallback/Anthropic strict/OpenAI Chat token field/output tokens/reasoning/verbosity/tool choice、messages/实际工具目录与 binding 来自同 captured session；`composition=runtime`、`sourceKind=runtime`，不得复制 `agent-delegate`；dedicated user message 精确两行且无尾换行，同一第二行 JSON bytes 生成 structuredInjections wire 摘要；tool-plan/final-reply/context-compaction/final-reply-context-compaction 均写 v3 binding，只有 tool-plan 可写 v4 batch，planning idle compaction fail-closed；不适用 adapter 字段为 null；任一实际语义字段变化均改变 requestContextFingerprint/base ID；plan base ID/attempt vector；旧 started 必须先 failed/interrupted 再开下一 attempt；损坏 binding 只 reconciliation |
|
||||
| submit | durable request/context/session/batch/action binding；缺失 binding 时丢弃旧响应；sole-action v4 batch；main-loop 专用 commit 分支且零 approval waiting；同 submission + 同/异 payload；复用既有 Runtime ID/time；session CAS；决定元数据与 session 真相逐项一致；M1B-2 已有 GDD 时拒绝不同 submission；GDD 提交点前后强杀；提交后 index/Markdown/session successor/child terminal；generic v5/v4 anchors 都在时严格对账、单缺时确定性重建、双缺或漂移时 reconciliation |
|
||||
| approval | 同 response 同/异决定；不同 response 同版本；不同版本合法复用 responseId；两个窗口并发；旧卡决定新版本；approve/revise/reject comment；approve 后显式 continuation 提交并批准新版本；响应丢失重试 |
|
||||
| projection recovery | index/Markdown/audit/observation/session/独立 pending 每个断点恢复；现役 global pending v5 零迁移；恰一逻辑 audit/observation；无永久 stale 卡 |
|
||||
| projection recovery | M1B-2 覆盖 index/Markdown/session successor/child terminal/generic v5+v4 anchors 每个断点恢复且零 planning pending；M1C-1 才覆盖独立 planning pending/audit/terminal observation/receipt 后 cleanup；现役 global pending v5 零迁移；恰一逻辑 audit/observation；无永久 stale 卡 |
|
||||
| agent.db | 专用幂等 helper；same key conflict；日志达到普通容量、尾部截断与压缩后仍能补齐并保留决定记录 |
|
||||
| source/security | durable exact identity；四 action tool 广告与执行；MCP 空且 webSearchEnabled=false；control functions 单列；tool-plan/batch/ledger/context/repair/completion 全部跳过 collaboration；plan retry 保留 source/profile；所有副作用工具拒绝 |
|
||||
| source/security | durable exact identity；三个 action tool（`file.read` / `file.list` / `plan.submit_gdd`）广告与执行；MCP 空且 webSearchEnabled=false；control functions 单列；tool-plan/batch/ledger/context/repair/completion 全部跳过 collaboration；plan retry 保留 source/profile；除 Runtime-owned submit 外的副作用工具拒绝 |
|
||||
| Prompt | **2026-08-13 按 D11 改写**：不新增 composition，Supervisor 根 run 沿用现役 supervisor composition、策划子 Agent 复用 `runtime` composition（见第 4.2 节）；`decision-checkpoint` 请求 kind 随 D10 作废（见第 5.1 节）。仍冻结：3 轮/单题/固定选项；回答后设计解释与 prototype item；平台事实；恢复摘要；direct-out 条件 |
|
||||
| frontend | 默认入口与直接开建；stable approvalRequestId/responseId；busy；stale card；hydrate strict input/view；无目录空态；receipt 隐藏 stale pending；corrupt authority typed error；project open/reload/resume/submit/decision 刷新；recovery pending；批准并开建两命令顺序 |
|
||||
| M2 integration | explicit approved/direct mode；锁内重验 receipt；ref 贯穿 task/run/completion/context；无 ref 非回归；恢复不换稿 |
|
||||
@@ -1713,7 +1751,7 @@ M0 文档 PR 本身最低验证：Markdown 结构与三张 Mermaid 图可解析
|
||||
| provider batch ledger | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/provider_batch_ledger.rs:130-230,319-372,432-464,545-598` | validate/write/recovery 都不得为 plan 绑定或恢复 collaboration snapshot；submit sole action |
|
||||
| user.input_request / 静态委派澄清中转 | `apps/ai-game-creator-shell/src-tauri/src/user_input.rs:21-43,209-307,534-623,765-778,835-898`、`apps/ai-game-creator-shell/src/features/agent-runtime/model.ts:1164-1169`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/interaction.rs:444-548`、`apps/ai-game-creator-shell/src-tauri/src/tool_plan_handoff/model.rs:86-157`、`apps/ai-game-creator-shell/src-tauri/src/tool_plan_handoff/ledger.rs:126-205` | 现役 input 只有 questions；M1 保持 wire 与 answer responseId 兼容合同，plan 额外限制单题/固定选项/32 字符 ID，非 plan 行为不变。**2026-08-13 作废后半段**：「answer-prepared 后发起只含 strict `update_agent_plan` 的 checkpoint turn，success handoff 后 session CAS」是 D10「Runtime 直投」机制，D11 下该请求 kind 不存在——问题落 delivery、线性化点是答案绑回 delivery、解释与下一步由 continuation 子 Agent 的第一个普通 tool-plan turn 完成（见第 5.1 节）；其专用 handoff 契约随之作废（见第 23.1 节） |
|
||||
| 现役 pending wire | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver.rs:26-27`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/provider_action_batch.rs:3-46,219-270`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/pending_confirmation_ledger.rs:290-520` | 保持 `game-creator-pending-action.v5`；M1 另建 planning pending，不升级全局 wire |
|
||||
| submit 等待分支 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/models.rs:5-21`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/main_loop.rs:2547-2626`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/task_queue.rs:347-408`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/action_projection.rs:3-90` | 参照 user-input special case，在普通 dispatch 前处理 submit，并复用现有 WaitingForUserInput outcome/queue 消费语义 |
|
||||
| submit 专用提交/恢复分支 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/main_loop.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/pending_recovery.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/recovery_scan.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/provider_action_batch.rs` | **2026-08-14 按 M1B-2 收口**：在普通 dispatch 前处理 Runtime-owned submit；提交后终止策划子 run，并保留 generic v5 standalone pending + v4 batch anchors，不复用 `WaitingForUserInput`，不创建 planning pending。审批等待属于 M1C-1 |
|
||||
| JSON sidecar | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/json_sidecar.rs:44-104,122-250` | 现有 writer 可覆盖；不可变文件必须新增 no-replace helper |
|
||||
| 项目锁 | `apps/ai-game-creator-shell/src-tauri/src/project/filesystem.rs:85-138`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/project_gates.rs:1467-1505` | 所有 planning mutation 在同一项目锁内重读事实 |
|
||||
| completion blocker | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/project_gates.rs:808-860,934-948`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/main_loop.rs:1792-1832` | **2026-08-13 收窄**：现役 collaboration blocker 对**策划子 Agent**返回不适用；Supervisor 根 run 侧不再整体豁免（见第 4.3 节）。仍需新增 plan GDD 专用完成门，检查提问/审批等待、receipt、observation、session 与 recovery 状态 |
|
||||
@@ -1843,7 +1881,7 @@ M0 收口时的三项已知残留，均已定性且不阻塞后续阶段：
|
||||
- `set_task_status` 无秩序守卫的无条件覆盖，属 master 既有问题，另行提 issue，不在 M0 范围内修。
|
||||
- 第 23.1 节的 M1 入口前置决策：**2026-08-13 起为空**。三项当日全部关闭——「plan source 与 Goal Contract 协议的关系」裁决为进可信 matcher；「plan run 是否允许 steer」裁决为不允许；「checkpoint handoff 私有持久化」随 D10 一并作废、无需裁决。M1 不再有未决的合入前置决策。
|
||||
|
||||
M0 完成不表示完整策划闭环已经上线。`M1A-1`、`M1A-2`、`M1A-3` 已落地 plan source、两层工具面/角色 brief 以及根 run retry 身份保源；`plan.submit_gdd`、`.agent/planning` strict schema/版本链、审批 pending/receipt、前端入口和构建准入仍待后续 M1B～M1E 工作包。第 19 节第 2 条中关于工具面与执行拒绝的目标不变量已由 M1A-2 覆盖，其余 GDD 事实与审批不变量仍是后续实现目标。
|
||||
M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1` 与 `M1C-0` 已合入，其中 `.agent/planning` strict schema/版本链已由 M1B-1 提供；`M1B-2` 工作包已在隔离分支通过本包门禁、待合入，审批 pending/receipt、前端入口和构建准入仍待后续 M1C～M1E 工作包。第 19 节第 2 条中关于工具面与执行拒绝的目标不变量已由 M1A-2/M1A-4 覆盖，其余 GDD 审批不变量仍按第 23.8 节推进。
|
||||
|
||||
### 23.5 `WP1` / `WP2`：静态委派澄清轮次与返工深度拆分（2026-08-13 完成）
|
||||
|
||||
@@ -1883,7 +1921,7 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`、`M1A-2`、`M1A-3`
|
||||
| 三 | `project-planning` 的 agentCatalog 登记 | **已完成**（机制冻结见第 3.1 节；**代码亦已落地**，2026-08-13：manifest、prompt bundle、runtime adapter、`prompt.rs` 角色合成分支及四处 needs_change 全部合入） |
|
||||
| 四 | `M0A-3` 批二：拓扑与工具面部分 | **已完成**（2026-08-13），拆解见下 |
|
||||
| 四之余 | schema 与 golden vector 收口 | **已完成**（2026-08-13），拆解见下 |
|
||||
| 五 | M1 本体：策划闭环功能实现 | **`M1A-1`、`M1A-2`、`M1A-3`、`M1A-4`、`M1C-0` 已落地**；`M1B-1` 已于 2026-08-14 在隔离 worktree 完成并通过本包验收门禁，已提交于隔离分支 `f453c2ca2`，待合回原分支：storage 基础、strict schema、typed 指纹、版本链、session 原子恢复、只挡写门禁及 writer/index/recovery 验证均已完成，golden vector 与 11 个定向 storage 测试通过。`M1A-2` 只交付工具面、brief 注入和拒绝边界，`M1C-0` 只交付用户修订 lineage 分类，均不包含 GDD 提交/审批；`M1B-2` 及之后未开始。合入门见第 23.8 节 |
|
||||
| 五 | M1 本体：策划闭环功能实现 | **`M1A-1`、`M1A-2`、`M1A-3`、`M1A-4`、`M1B-1`、`M1C-0` 已落地并合入**；其中 `M1B-1` 的 storage 基础、strict schema、typed 指纹、版本链、session 原子恢复、只挡写门禁及 writer/index/recovery 验证均已完成，golden vector 与 11 个定向 storage 测试通过。**`M1B-2` 工作包已在隔离分支通过本包门禁、待合入**：已接入 `plan.submit_gdd`、四类 exact planning v3 binding/structured injection、v4 sole-submit batch、create-only 提交点、index/Markdown/session successor、策划子 run 终止及 generic v5/v4 anchor 恢复；不创建 `gdd-approval` planning pending 或审批等待。`M1C-1` 及之后仍未实现。合入门见第 23.8 节 |
|
||||
|
||||
批二在 2026-08-13 拆成两半，因为其中一半在 M1 代码存在之前**做不完**：
|
||||
|
||||
@@ -1963,8 +2001,8 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`、`M1A-2`、`M1A-3`
|
||||
| `M1A-2` | 两层工具面 + `project-planning` 角色 brief | `M1A-1` | **已落地**：Supervisor 根 run 保持 standard 工具面；planning 子 Agent 按 `agent-delegate`/`standard`/Supervisor parent 身份构建 exact native allowlist（`file.read`、`file.list` 与两个协议控制函数），MCP 为空、web search 关闭、collaboration policy 为 `null`；Prompt Bundle brief 只注入 `project-planning`，repair/rebuild 与初始请求一致；伪造写入、命令、MCP、`project.search` alias、`user.input_request` 等原始工具在广告/解析/执行/恢复路径均 fail-closed。**不包含 `plan.submit_gdd` 注册或 GDD 提交/审批。** |
|
||||
| `M1A-3` | plan 根 run 强判据函数 + retry 保源（本节下方「`M1A-3` 的由来」，规格见第 4.1 节第 5、7 段） | `M1A-1` | **已落地**（source 保源与强判据）。`kind=plan-root-retry-identity-unsupported`；gui/cli 兜底不变。第 4.1 节第 7 段里依赖 plan-session / `gddId` / `gdd-approval` kind 的部分仍后置。必须早于 `M1C-2a` |
|
||||
| `M1A-4` | plan 根 run 的子 Agent 创建面收窄：`agent.delegate` 目标必须是 `project-planning`、`agent.spawn_isolated` 一律拒；plan source 下不拼 `supervisorIntro` 与 `$visualContract` | `M1A-2` | 执行层与上下文层**都要做且不可互相替代**（同第 19 节第 2 条纪律）；`agent.spawn_isolated` 是第二条造子 Agent 的通道，只堵 `agent.delegate` 视为未完成；强判据 `Err` 必须落进拒绝分支而非当作「不是 plan 根」；`project-supervisor-gui/cli` 的委派与 spawn 行为正常路径不变。**必须早于 `M1D-2` 与 `M1E`** |
|
||||
| `M1B-1` | `.agent/planning/` 存储层、strict schema、typed 指纹、版本链；含 `.agent/planning/**` 只挡写判据 | `M1A-2` | **2026-08-14 已在隔离 worktree 完成并通过本包验收门禁，已提交于隔离分支 `f453c2ca2`，待合回原分支**：GDD / index / session strict DTO、canonical bytes、duplicate-key 与后缀门、typed 指纹、连续版本链、session 原子写入/恢复、Runtime writer identity 及 `game/fast_gdd.md` / `.agent/planning/**` 通用写入拒绝；第 9.1 节 golden vector（3857 bytes）与 11 个定向 storage 测试通过，writer 目标 schema 重验、index 权威对账与锁内 index recovery（缺失/损坏/陈旧从严格 GDD 链重建）、恢复故障矩阵、`cargo check --offline`、`npm run check:encoding` 与 `git diff --check` 均通过。当前无 approval receipt schema，多版本 `statusCache` 只是无 receipt 的预审批投影（最新版本 `ready_for_approval`、旧版本 `superseded`）；M1C-1 接入 receipt 后必须重建 `approved/revise/reject/superseded` 状态。`plan.submit_gdd`、审批闭环仍留给 `M1B-2` 及后续包；create-only 与等前缀不可变 |
|
||||
| `M1B-2` | `plan.submit_gdd` 原生工具与提交点 | `M1B-1` | 全部拒绝分支；提交点前后强杀恢复；同 submissionId replay 不产生 vN+1 |
|
||||
| `M1B-1` | `.agent/planning/` 存储层、strict schema、typed 指纹、版本链；含 `.agent/planning/**` 只挡写判据 | `M1A-2` | **2026-08-14 已通过门禁并合入本分支**：GDD / index / session strict DTO、canonical bytes、duplicate-key 与后缀门、typed 指纹、连续版本链、session 原子写入/恢复、Runtime writer identity 及 `game/fast_gdd.md` / `.agent/planning/**` 通用写入拒绝；第 9.1 节 golden vector（3857 bytes）与 11 个定向 storage 测试通过，writer 目标 schema 重验、index 权威对账与锁内 index recovery（缺失/损坏/陈旧从严格 GDD 链重建）、恢复故障矩阵、`cargo check --offline`、`npm run check:encoding` 与 `git diff --check` 均通过。合入时无 approval receipt schema，多版本 `statusCache` 只是无 receipt 的预审批投影；M1C-1 接入 receipt 后必须重建 `approved/revise/reject/superseded` 状态。create-only 与等前缀不可变 |
|
||||
| `M1B-2` | `plan.submit_gdd` 原生工具、exact planning Provider 请求绑定与 GDD 提交点 | `M1B-1` | **工作包已在隔离分支通过本包门禁、待合入**。实现合同：四类 request kind 全部写 v3 lifecycle、required binding 与同一 dedicated structured-injection user message；只有 `tool-plan` 可生成 sole-submit v4 batch；提交点后只修复 index/Markdown/session successor、终止策划子 run，并保留 generic v5 standalone pending + v4 batch anchors，不创建 `gdd-approval` planning pending/审批等待。定向 Rust、`cargo check --offline`、格式、编码与 diff 门禁均已通过；完整审批链路与产品可交付仍留给后续工作包 |
|
||||
| `M1C-0` | 新增 `StaticDelegateContractStatus::UserRevisionRequested` 与分类分支 | `M1A-1` | **已落地**：无审批写入方、是惰性路径；用户修订跳不增 `repair_depth` 也不重置 `clarification_round`，连续修订可通过；做游戏链路返工仍在 `depth=1` 被拒；历史记录与未知状态均保持 fail-closed |
|
||||
| `M1C-1` | `gdd-approval` pending、审批命令、receipt；receipt 写入上述 status | `M1B-2`、`M1C-0` | 三动作全通；版本+指纹竞态防护；两窗口并发；**连续多次修订均可通过且 `repair_depth` 不变** |
|
||||
| `M1C-2a` | Goal Contract 接线：turn 1 冻结、固定验收图、审批前置门取证 | `M1C-1`、`M1A-3` | turn 1 只能是一个 `agent.goal_contract`；`acceptanceNodes` 不接受自定义；**第 13.0 节审批前置门：取证未通过时不出现审批卡、而是产生返工委派**（取证顺序是协议时序问题，归本包而非 `M1C-1`） |
|
||||
@@ -1973,9 +2011,11 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`、`M1A-2`、`M1A-3`
|
||||
| `M1D-2` | 入口分流与阶段进度 | `M1D-1` | 「直接开建」跳过路径与现状零差异 |
|
||||
| `M1E` | 端到端与故障注入收口 | `M1D-2` | 第 21 节测试矩阵中跨层场景 |
|
||||
|
||||
**2026-08-14 `M1B-1` 实现验收快照（已提交，待合回原分支）**：当前隔离 worktree 的实现集中在 `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_storage.rs`，并由 `runtime_protocol.rs` 注册。已具备 `plan-gdd.v1`、`plan-gdd-index.v1`、`plan-session.v1` 及 `plan.submit_gdd` input 的 strict serde 形状校验、文本/ID/时间/枚举边界、typed serde fingerprint、canonical JSON（重复键、BOM、尾空白、字段顺序）解析、GDD 连续版本链、session `revision + 1` / `previousFingerprint` 链、create-only durable writer、session 原子替换与受限 recovery，以及 `project-planning / agent-delegate / standard / project-supervisor` writer identity。通用 `file.write`、`file.patch`、`file.delete`、`project.patchset` 与 checkpoint restore 对 `.agent/planning/**` 和 `game/fast_gdd.md` 只挡写，planning 的 `file.read` / `file.list` 仍可读；本包没有注册或执行 `plan.submit_gdd`，也没有实现 approval pending、receipt、UI 或构建准入。
|
||||
**2026-08-14 `M1B-1` 合入验收快照**：已合入实现集中在 `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_storage.rs`，并由 `runtime_protocol.rs` 注册。已具备 `plan-gdd.v1`、`plan-gdd-index.v1`、`plan-session.v1` 及 `plan.submit_gdd` input 的 strict serde 形状校验、文本/ID/时间/枚举边界、typed serde fingerprint、canonical JSON（重复键、BOM、尾空白、字段顺序）解析、GDD 连续版本链、session `revision + 1` / `previousFingerprint` 链、create-only durable writer、session 原子替换与受限 recovery，以及 `project-planning / agent-delegate / standard / project-supervisor` writer identity。通用 `file.write`、`file.patch`、`file.delete`、`project.patchset` 与 checkpoint restore 对 `.agent/planning/**` 和 `game/fast_gdd.md` 只挡写，planning 的 `file.read` / `file.list` 仍可读；M1B-1 合入时没有注册或执行 `plan.submit_gdd`，也没有实现 approval pending、receipt、UI 或构建准入。
|
||||
|
||||
当前已验证第 9.1 节 golden vector（canonical envelope 3857 bytes 与指纹 `sha256-serde-json-v2:a59856de7ef134cf2f49c4dedd2ba10ae4ab2340a9634d402eb792b6ee5458f0`）及 11 个定向 storage 测试；durable writer 的目标 schema 重解析与文件名/版本核对、index 与权威 GDD 对账、缺失/损坏/陈旧 index 的锁内链重建、`(requestId,responseId)` / decision/ref / active run/phase 等 session 约束、GDD 文件枚举/链读取及 primary 损坏/previous 提升/分叉 recovery 矩阵均已覆盖。M1B-1 尚无 approval receipt schema，因此多版本 `statusCache` 只表达无 receipt 的预审批投影；M1C-1 接入 receipt 后重建真实 approved/revise/reject/superseded 状态。`clarification_round` 与完整 root/session identity 绑定留给后续 `M1B-2` / `M1C-2b` 接线。`cargo check --offline`、`npm run check:encoding`、`git diff --check` 均通过；本包已提交于隔离分支 `f453c2ca2`，待合回原分支，不把 `plan.submit_gdd`、审批闭环、UI 或 renderer 误报为已实现。
|
||||
已验证第 9.1 节 golden vector（canonical envelope 3857 bytes 与指纹 `sha256-serde-json-v2:a59856de7ef134cf2f49c4dedd2ba10ae4ab2340a9634d402eb792b6ee5458f0`）及 11 个定向 storage 测试；durable writer 的目标 schema 重解析与文件名/版本核对、index 与权威 GDD 对账、缺失/损坏/陈旧 index 的锁内链重建、`(requestId,responseId)` / decision/ref / active run/phase 等 session 约束、GDD 文件枚举/链读取及 primary 损坏/previous 提升/分叉 recovery 矩阵均已覆盖。M1B-1 尚无 approval receipt schema，因此多版本 `statusCache` 只表达无 receipt 的预审批投影；M1C-1 接入 receipt 后重建真实 approved/revise/reject/superseded 状态。`cargo check --offline`、`npm run check:encoding`、`git diff --check` 均通过；该包现已合入本分支，这一历史快照不把后续 `plan.submit_gdd`、审批闭环、UI 或 renderer 误报为 M1B-1 已实现。
|
||||
|
||||
**2026-08-14 `M1B-2` 本包验收快照（隔离分支，待合入）**：代码已把 `plan.submit_gdd` 接到原生工具目录、Provider 请求、v3 lifecycle/v4 batch、main-loop 专用提交分支与恢复扫描；同时以 required `rootAgentId + fingerprint` 加固 `plan-provider-session-binding.v1`，冻结并实际注入 `plan-provider-structured-injections.v1` dedicated user message。tool-plan、final-reply、context-compaction、final-reply-context-compaction 四类 exact planning 请求共享 v3 binding 和 structured injection，只有 tool-plan 能生成 v4 batch，planning idle compaction 失败关闭。提交点后的 M1B-2 投影仅为 index、Markdown、session successor、策划子 run 终态以及原 generic v5/v4 anchors 的保留/重建；`gdd-approval` planning pending、审批等待、receipt、审批命令和 UI 明确留给 `M1C-1` 及之后。本包定向 Rust、`cargo check --offline`、格式、编码与 diff 门禁已通过；这只表示 M1B-2 工作包完成，不表示完整产品或审批闭环可交付。
|
||||
|
||||
**拆包纪律**：
|
||||
|
||||
|
||||
Reference in New Issue
Block a user