补充 M1C-2c 决策卡文档
更新共享决策日志，记录 A/B 平行方案、改口转述规则与提问纪律。 更新 Fast GDD 技术方案的阶段状态、工作包矩阵和 M1C-2c 设计说明。
This commit is contained in:
@@ -15,7 +15,17 @@
|
||||
- **终审修复**：完成至少一轮澄清后，审批 `revise/reject` 会保留 `appliedAnswers`，但新修订 delivery 的身份不再等于最后回答 continuation；旧纯 session 判据会把合法修订 successor 固定拒成 `PLAN_IDENTITY_CONFLICT`。现把独立 schema 校验收窄为“不得回退到已消费问题 delivery”，并在 session 新值、已有 primary/previous、发布后回读及普通读取边界读取真实 static-delivery 谱系：从 latest 回到最后回答 continuation 的**每一条边**都必须由父 delivery 的 `UserRevisionRequested` 状态授权，且 root/agent/session 身份一致、无 Unknown、缺节点或循环；质量返工边不得借路径中其它用户修订继续保留旧回答。正向回归同时覆盖 `revise/reject` 后 continuation、轮次/回答/决定保留与 Provider 注入；负向回归证明混入质量返工边时，即使重算合法 session fingerprint 仍失败关闭。
|
||||
- **门禁中修复的测试缺陷**：并发整组首次复跑时，锁序测试把“回答线程开始”误当成“已得到调度”，180ms 内未观察到 project lock 竞争而失败；同用例精确复跑通过。测试只将调度观察窗口放宽到 2 秒，断言仍要求真实 project lock 竞争发生后才释放被占用的 execution lane，未改变生产锁序或放松结果判据。
|
||||
- **保留观察**：第四轮违规澄清信封当前会在建立 pending 前失败关闭并进入 reconciliation，而方案目标是第三轮后由 planning 子 Agent 转入 submit。现有回归明确只证明“不建立第四轮 pending”，未证明强制 submit；修复会扩到更宽的 Provider/终态状态机，当前也未引起本包测试失败，按缺陷处置规则留待后续单列，不在 M1C-2b 收口中顺手扩修。
|
||||
- **最终门禁证据**：`planning_clarification_*` **11 passed / 0 failed**（原 9 条之外新增真实 main-loop 释放 execution lane 后 parent-wake 回归，以及已回答后 `revise/reject` 修订回归）；`tests::collaboration::static_deliveries::*` **44 passed**；planning storage **13 passed**（含重新计算 fingerprint 的混合质量返工谱系负例）；`planning_submit` **53 passed**；`planning_provider_usage` **4 passed**；真实末次 submit usage receipt 回归 **1 passed**；`barrier_detail_*` **3 passed**。`cargo fmt --check`、`cargo check --offline --all-targets --target-dir target-m1c2b`、`npm run check:encoding`（7810 files）及整个工作树 `git diff --check` 均通过。**M1C-2b 本包实现及门禁已完成，仍只在隔离分支，尚未合回原分支。**
|
||||
- **最终门禁证据**：`planning_clarification_*` **11 passed / 0 failed**（原 9 条之外新增真实 main-loop 释放 execution lane 后 parent-wake 回归，以及已回答后 `revise/reject` 修订回归）；`tests::collaboration::static_deliveries::*` **44 passed**；planning storage **13 passed**（含重新计算 fingerprint 的混合质量返工谱系负例）；`planning_submit` **53 passed**；`planning_provider_usage` **4 passed**；真实末次 submit usage receipt 回归 **1 passed**；`barrier_detail_*` **3 passed**。`cargo fmt --check`、`cargo check --offline --all-targets --target-dir target-m1c2b`、`npm run check:encoding`（7810 files）及整个工作树 `git diff --check` 均通过。**M1C-2b 本包实现及门禁已完成，并已快进合回 `feat/five_min_design`；审批 UI、hydrate、构建准入和下游完整构建仍后置。**
|
||||
## 2026-08-17 立项策划决策卡改为 A/B 平行方案：`default_pending` 收回为未提问默认项唯一来源，改口不改合同，立包 `M1C-2c`
|
||||
|
||||
- **裁决**：决策卡三选项从「接受推荐 / 暂按推荐 / 需要原型验证」（同一条推荐的三种采纳程度）改为「方案 A（推荐）/ 方案 B（真实可行、形状不同的平行备选）/ 可选的固定『需要原型验证』（只在体验类决定出现）」。A、B 均记 `confirmed / user_option`；`需要原型验证` 仍记 `prototype_pending` 并要求同 ID 微型原型项；自由填写仍记 `confirmed / user_freeform`。`default_pending` 不再由任何选项产生，只表示**未提问、由子 Agent 按默认建议填写**的字段（`answerSource=default, round=0`），与 `plan.submit_gdd` 校验「前缀之后只允许追加 `default_pending` 默认决定」完全一致——三个决定状态各只有一个来源。状态映射按 label（A/B 前缀 + 第 3 项固定文案）而非位置，Runtime 校验信封形状；`answerSummary` 直接落所选 label，台账自描述。
|
||||
- **依据**：以 DeepSeek v4-flash 做的本地原型多轮实测（原型不入库、只用于开发调试）：选 1 与选 2 产出的 GDD 一字不差，差别只是一个不进任何机制的标签，却消耗一轮问询名额（上限 3）；台账只落「接受推荐」三个字，用户下一轮改口推翻上一轮已确认决定时，Supervisor 转述与子 Agent 出稿只能靠改写文本消化。改为 A/B 后两轮冒烟：B 均为带独立代价说明的真实岔路，第 3 项只在体验类问题出现，模型一次擅自给出第 3 个自定义方案被信封形状校验拒回并自行改正。
|
||||
- **改口（已确认决定被后续自由填写推翻）**：M1 内不改合同——台账前缀不可变，两条 `confirmed` 并存；Supervisor 转述时必须在被推翻的那条后注明「已被第 N 轮回答推翻，以后者为准」且用户答案原文逐字保留（不得改写、拆分或搬轮次），子 Agent 按后者出稿并在新决定 topic 中写明推翻关系。实测三次改口 Supervisor 均能消化，但一次靠改写用户原文（转述保真审计报「内容缺失」），因此该规则必须写进 Supervisor prompt。`supersedes` 字段进 `plan-gdd.v1` 列为 M2 候选。
|
||||
- **提问纪律补一条**：平台事实已定的事（含移动/桌面优先级）与 MVP 规则已排除的事（多人/联机/商城/服务器）不作为问题；A/B 格式会诱使模型问"天然二选一"但无价值的问题，实测一轮 3 张卡 2 张如此。
|
||||
- **不打断 `M1C-2b`**：其合入门禁（3 轮上限、continuation 重放幂等、答案绑定冲突被拒）与选项文案无关，按现行 §5.2 映射表实现即可；映射翻转、信封形状校验与 prompt 文案由新立的 **`M1C-2c`**（依赖 `M1C-2b`）承接。**`M1D-1` 前端决策卡直接按新语义实现**（label 动态渲染、默认焦点 A、Other 槽不变），避免做两遍。§5.2、§5.1 prompt 段与 §23.6「仍冻结：固定选项」一句待 `M1C-2b` 合回后改写；本轮只在 §5.2 顶部加了指向注、新增 §23.9 与 §23.8 表 `M1C-2c` 行。
|
||||
- **顺带核对项（归 `M1E`）**：`plan.submit_gdd` 连续校验失败必须有次数上限。本地实测无界时模型对大载荷序列化出错后连续 40 余次重试、每次重放全部历史、单次 prompt 涨到 15 万 token；240/300 秒预算注入兜不住「硬超时后仍连续校验失败」。若 §12 retry 状态机没有该上限，补一个（原型取 5 次）。
|
||||
- **不改的部分**：`user.input_request` strict input 2～3 项区间、Other 槽 placeholder、`prototype_pending` 同 ID 验证项规则、第 12 节提交校验、§23.7 用户修订不计 `repair_depth`（`M1C-0`/`M1C-1` 已落地）均不变；生产代码本轮零改动。
|
||||
- **关联**：`docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md` 第 5.2 节指向注、第 23.8 节 `M1C-2c` / `M1D-1` 行、第 23.9 节。
|
||||
|
||||
## 2026-08-15 M1C-2a 隔离工作树实现：固定 Goal Contract 与审批前置门
|
||||
|
||||
|
||||
@@ -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` 已通过门禁并合入本分支**：已落地 `.agent/planning` storage module、strict schema/typed 指纹/canonical parser、GDD 版本链、session 原子恢复、Runtime 写入身份及只挡写门禁；golden vector 与 11 个定向 storage 测试通过，writer/index/recovery 门禁已完成。**2026-08-15 `M1B-2` 工作包已通过本包门禁并以 `27c3eb847` 合入本分支**：已落地 `plan.submit_gdd`、exact planning Provider binding/structured injection、专用提交点与崩溃恢复；本包不包含 `gdd-approval` planning pending、审批等待、receipt、审批命令或 UI。**2026-08-14 `M1C-0` 已合回本分支**：仅新增用户修订状态及 lineage 分类，不包含审批写入方。**2026-08-15 `M1C-0b` 已通过定向门禁并完成**：只改静态委派 durable status 的前向兼容读路径，未知字符串显式保留为 `Unknown(raw)` 并最大化阻塞；不含审批写入方。`M1C-1` 与 `M1C-2a` 已提供审批核心、固定 Goal Contract、完整分页 `file.read` evidence、claim 后三态 acceptance gate、审批 pending 恢复及 completion/finalization 门。**当前隔离 worktree 的 `M1C-2b` 已完成本包实现并通过门禁，尚未合回**：planning 澄清中转、确定性 continuation/session 投影、审批后用户修订谱系、Provider 活跃时间预算与末次 submit usage fold 已实现，11 条 `planning_clarification_*` 回归及关联 Rust 门禁通过。审批 UI、hydrate、构建准入与下游完整构建仍后置，M1 整体不可交付（见第 23.6、23.8 节）。
|
||||
- 状态：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-15 `M1B-2` 工作包已通过本包门禁并以 `27c3eb847` 合入本分支**：已落地 `plan.submit_gdd`、exact planning Provider binding/structured injection、专用提交点与崩溃恢复；本包不包含 `gdd-approval` planning pending、审批等待、receipt、审批命令或 UI。**2026-08-14 `M1C-0` 已合回本分支**：仅新增用户修订状态及 lineage 分类，不包含审批写入方。**2026-08-15 `M1C-0b` 已通过定向门禁并完成**：只改静态委派 durable status 的前向兼容读路径，未知字符串显式保留为 `Unknown(raw)` 并最大化阻塞；不含审批写入方。`M1C-1` 与 `M1C-2a` 已提供审批核心、固定 Goal Contract、完整分页 `file.read` evidence、claim 后三态 acceptance gate、审批 pending 恢复及 completion/finalization 门。**`M1C-2b` 已完成本包实现并通过门禁，现已快进合回 `feat/five_min_design`**：planning 澄清中转、确定性 continuation/session 投影、审批后用户修订谱系、Provider 活跃时间预算与末次 submit usage fold 已实现，11 条 `planning_clarification_*` 回归及关联 Rust 门禁通过。审批 UI、hydrate、构建准入与下游完整构建仍后置，M1 整体不可交付（见第 23.6、23.8 节）。
|
||||
- 适用范围：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` 提供 storage 基础与写入隔离；`M1B-2` 已提供提交点与恢复，`M1C-0b` 已补齐静态委派未知 durable status 的前向兼容读路径，`M1C-1` 已提供 receipt/审批核心、投影恢复和 plan 根完成门，`M1C-2a` 已补齐固定 Goal Contract、验收图证据与生产 acceptance gate。当前隔离 worktree 的 `M1C-2b` 已实现 planning 澄清中转、三轮确定性 session/continuation 投影、审批后修订谱系和 Provider 活跃时间预算，并通过本包 Rust 门禁；审批 UI、hydrate、构建绑定和正式入口仍不可用
|
||||
- 当前实现边界：本文件是后续详细设计与实现的仓库内阶段基线；M0 工作包冻结 Fast GDD 合同并修复现有 owner 验证、game-chat retry 与前端投影边界，`M1A-1`～`M1A-4` 已提供 plan source、两层工具面、角色 brief 与子 Agent 创建面收窄的 Runtime 基础，`M1C-0` 已提供用户修订 lineage 分类，已合入的 `M1B-1` 提供 storage 基础与写入隔离；`M1B-2` 已提供提交点与恢复，`M1C-0b` 已补齐静态委派未知 durable status 的前向兼容读路径，`M1C-1` 已提供 receipt/审批核心、投影恢复和 plan 根完成门，`M1C-2a` 已补齐固定 Goal Contract、验收图证据与生产 acceptance gate。`M1C-2b` 已实现 planning 澄清中转、三轮确定性 session/continuation 投影、审批后修订谱系和 Provider 活跃时间预算，并已合回 `feat/five_min_design`；审批 UI、hydrate、构建绑定和正式入口仍不可用
|
||||
|
||||
## 1. 背景与目标
|
||||
|
||||
@@ -417,6 +417,8 @@ Runtime 注入并强校验以下精确结构：
|
||||
|
||||
### 5.2 决策卡
|
||||
|
||||
> **2026-08-17 拟定修订（`M1C-2b` 合入后生效，见第 23.9 节）**：选项语义改为「方案 A（推荐）/ 方案 B（平行备选）/ 可选的固定『需要原型验证』」，A、B 均记 `confirmed / user_option`，`default_pending` 收回为未提问默认项的唯一来源。本节正文仍是 `M1C-2b` 实现依据，待其合回后按第 23.9 节改写；`M1D-1` 前端决策卡直接按第 23.9 节实现。
|
||||
|
||||
每次 `user.input_request` 固定只含一题：
|
||||
|
||||
- header：固定为 `第{N}轮·关键决定`，N 为 1～3，始终不超过现有 12 scalar 上限；
|
||||
@@ -1928,7 +1930,7 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
|
||||
| 三 | `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`、`M1B-1`、`M1B-2`、`M1C-0`、`M1C-0b`、`M1C-1`、`M1C-2a` 已落地**；当前隔离 worktree 的 `M1C-2b` 已实现 planning 澄清中转、三轮确定性 session/continuation 投影、审批后用户修订谱系、Provider 活跃时间 usage fact/fold 与末次 submit usage 收口，11 条 planning 澄清定向回归及关联 Rust 门禁通过，尚未合回。**审批 UI、hydrate、构建准入与下游完整构建仍未完成**，因此 M1 整体仍不可交付。合入门见第 23.8 节 |
|
||||
| 五 | M1 本体：策划闭环功能实现 | **`M1A-1`、`M1A-2`、`M1A-3`、`M1A-4`、`M1B-1`、`M1B-2`、`M1C-0`、`M1C-0b`、`M1C-1`、`M1C-2a`、`M1C-2b` 已落地**；M1C-2b 已实现 planning 澄清中转、三轮确定性 session/continuation 投影、审批后用户修订谱系、Provider 活跃时间 usage fact/fold 与末次 submit usage 收口，并已快进合回 `feat/five_min_design`，11 条 planning 澄清定向回归及关联 Rust 门禁通过。**审批 UI、hydrate、构建准入与下游完整构建仍未完成**，因此 M1 整体仍不可交付。合入门见第 23.8 节 |
|
||||
|
||||
批二在 2026-08-13 拆成两半，因为其中一半在 M1 代码存在之前**做不完**：
|
||||
|
||||
@@ -2018,8 +2020,10 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
|
||||
| `M1C-0b` | 静态委派 durable enum 的前向兼容粒度：未知 `contract_status` 解析为显式 `Unknown` 并最大化阻塞 | `M1C-0` | **已完成**：纯读路径、无写入方、审批状态、pending、receipt 或 UI（不含 `M1C-1`）。四种已知 durable 值保持原 serde；未知字符串解析为 `Unknown(raw)`，非字符串仍拒绝，`Serialize` 及读-改-写均原样保留 raw。`Unknown` 计入 completion barrier 与 waiting blocker，返工入口无条件拒绝（含 `depth=0`），lineage 按“其它”最保守分类（`depth + 1`、`round = 0`）；planning Provider、自治 liveness、终态扫描等既有读路径同步 fail closed。截断、非法 JSON、非 UTF-8、超过 128 KiB 的 sidecar 仍按整目录 fail closed，不做单条跳过。**不新增或改变 `M1B-*` 功能依赖（仅复核其既有读路径）；不包含 `M1C-1` 的审批写入、receipt、UI 或构建准入** |
|
||||
| `M1C-1` | `gdd-approval` pending、审批命令、receipt；receipt 写入上述 status 与 plan 根完成门 | `M1B-2`、`M1C-0`（前向兼容粒度另见 `M1C-0b`） | **已落地并合入**：三动作幂等、版本/指纹竞态防护、receipt 后 index/Markdown/audit/terminal observation/session 投影与恢复、generic v5/v4 anchor 精确消费、terminal summary 完整性校验，以及仅作用于 exact plan 根的只读 completion blocker；生产 acceptance-gate pending caller 与验收前置取证门按拆包纪律由 `M1C-2a` 承接。审批 UI / 澄清中转 / 构建准入仍未完成。连续修订 barrier 与 `UserRevisionRequested` 规则按第 23.7 节执行 |
|
||||
| `M1C-2a` | Goal Contract 接线：turn 1 冻结、固定验收图、审批前置门取证 | `M1C-1`、`M1A-3` | **当前隔离 worktree 已完成并通过本包门禁，尚未合回**：turn 1 的 request-scoped schema 与格式修复都只允许一个固定 `agent.goal_contract`；按项目变化的四项之外，`preferences=[]`、唯一验收节点及证据工具均冻结。Fast GDD evidence 只接受当前 Supervisor 根 run 对 `game/fast_gdd.md` 从第 1 行到 EOF 的同 hash 完整分页；无/旧证据先继续读取，显式 failed 才给原 delivery 的 `repairOfDelegationId`，passed 且 delivery 已认领才建 pending。pending/recovery/completion/finalization 均按同 identity 幂等，审批后 Markdown 改写不损坏 Graph。格式、Provider 强判据、M1C-2a、Acceptance Graph、planning submit/approval、finalization、all-targets、编码与 diff 门禁均通过；扩展 autonomous completion 整组的无关 game-chat 并行超时及精确复跑结果见 decision-log 同日条，不改该路径。不包含 `M1C-2b`、UI 或构建准入 |
|
||||
| `M1C-2b` | 澄清中转接线、轮次派生、预算注入 | `M1C-2a` | **隔离 worktree 实现与本包门禁已完成，尚未合回**：首 child 的 revision 1 session、`NeedsUserInput → awaiting_user_input`、回答绑定后 continuation 的确定性 session 投影、审批后 `revise/reject` 用户修订谱系及 Provider 活跃时间 usage fact/fold 已接线；末次 `plan.submit_gdd` usage 在 receipt/session successor 落盘且 standalone/v4 anchors 精确消费后于同一项目锁内折叠，真实 receipt 回归证明累计值恰好推进一次，重复审批与 recovery reconcile 不二次推进。`planning_clarification_*` **11 passed / 0 failed**，另有 static deliveries 44、planning storage 13、planning submit 53、Provider usage 4、末次 usage receipt 1、barrier detail 3 条定向回归通过；格式与 offline all-targets 通过，编码/diff 结果见同日 decision-log。锁序承诺只适用于 **M1C-2b 新增的 planning 澄清写投影路径**；`main_loop` 既有通用 completion blocker 的 execution→project 路径不在本包。第四轮违规信封已拒绝 pending，但拒绝后自动转 submit 尚未闭环，按同日保留观察后置。审批 UI、hydrate、构建准入和下游完整构建不在本包范围 |
|
||||
| `M1C-2b` | 澄清中转接线、轮次派生、预算注入 | `M1C-2a` | **实现与本包门禁已完成并已快进合回 `feat/five_min_design`**：首 child 的 revision 1 session、`NeedsUserInput → awaiting_user_input`、回答绑定后 continuation 的确定性 session 投影、审批后 `revise/reject` 用户修订谱系及 Provider 活跃时间 usage fact/fold 已接线；末次 `plan.submit_gdd` usage 在 receipt/session successor 落盘且 standalone/v4 anchors 精确消费后于同一项目锁内折叠，真实 receipt 回归证明累计值恰好推进一次，重复审批与 recovery reconcile 不二次推进。`planning_clarification_*` **11 passed / 0 failed**，另有 static deliveries 44、planning storage 13、planning submit 53、Provider usage 4、末次 usage receipt 1、barrier detail 3 条定向回归通过；格式、offline all-targets、编码与 diff 门禁通过。锁序承诺只适用于 **M1C-2b 新增的 planning 澄清写投影路径**；`main_loop` 既有通用 completion blocker 的 execution→project 路径不在本包。第四轮违规信封已拒绝 pending，但拒绝后自动转 submit 尚未闭环，按同日保留观察后置。审批 UI、hydrate、构建准入和下游完整构建不在本包范围 |
|
||||
| `M1D-1` | 前端 hydrate 与 GDD 审批卡 | `M1C-2b` | 前端只经 `hydrate_game_creator_plan_gdd_state` 读权威状态，不在页面侧合成批准事实 |
|
||||
| `M1C-2c` | 决策卡 A/B 语义（第 23.9 节，2026-08-17 立包）：选项 → 台账映射改为 A/B 均 `confirmed/user_option`、信封 label 形状校验、planning role brief 与 Supervisor prompt 文案（B 必须是真实岔路、体验类才给第 3 项、改口转述规则、提问纪律） | `M1C-2b` | 选 B 记 `confirmed/user_option`；第 3 项非固定文案的信封被拒并回灌；只给 A/B 两项的信封通过；未提问默认项仍只能 `default_pending/default/round=0`（第 12 节校验不变）；`answerSummary` 逐字等于所选 label；不改 `M1C-2b` 的 3 轮/幂等/绑定门禁 |
|
||||
| `M1D-1` | 前端 hydrate 与 GDD 审批卡；决策卡按第 23.9 节实现（label 动态渲染、默认焦点 A、Other 槽不变） | `M1C-2b` | 前端只经 `hydrate_game_creator_plan_gdd_state` 读权威状态，不在页面侧合成批准事实 |
|
||||
| `M1D-2` | 入口分流与阶段进度 | `M1D-1` | 「直接开建」跳过路径与现状零差异 |
|
||||
| `M1E` | 端到端与故障注入收口 | `M1D-2` | 第 21 节测试矩阵中跨层场景 |
|
||||
|
||||
@@ -2038,6 +2042,22 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
|
||||
|
||||
**`M1A-3` 的由来（2026-08-13 补列）**：本 PR 的内容原属 `M1A-1` 的消费点复核范围，被判成「已被 profile 挡住、本包不改」而漏出。漏出的机制原因是**复核方向单一**——`M1A-1` 的模板只问「plan 进可信 matcher 后会不会**误得**不该有的语义」，而 `resolve_game_creator_agent_runtime_retry_configuration_at` 既是判据也是 run 构造器，还必须反过来问「plan 落到通用兜底后会不会**丢掉**该有的语义」。后者的答案是会：plan 根 run 落 `agent-background-task` 兜底后 steer 重新放开，且 `root_control_authority` 转为 `false` 使其建不出 Goal Contract，第 13.0 节审批前置门要的取证永远收敛不了——而因为 `agent.delegate` 不受该权限影响，故障要到审批那一步才暴露。不回改已合入的 `M1A-1`，单列本 PR；详细定位见 decision-log 2026-08-13「订正 `M1A-1` 的 retry 复核结论」条。**凡「既是判据又是构造器」的调用点，后续 PR 的复核必须双向提问。**
|
||||
|
||||
### 23.9 决策卡选项语义修订：A/B 平行方案与决定状态来源唯一化（2026-08-17 拟定，`M1C-2b` 合入后生效）
|
||||
|
||||
**问题**：第 5.2 节固定的三个选项「接受推荐 / 暂按推荐 / 需要原型验证」是对**同一条推荐**的三种采纳程度，不是三个方案。以 DeepSeek v4-flash 做的本地原型多轮实测（原型不入库、只用于开发调试，本节只记结论）：选 1 与选 2 产出的 GDD 内容一字不差，差别只是一个 `default_pending` 标签；该标签不进任何机制（不锁台账、不进构建准入、不进验证环），却消耗一轮问询名额（上限 3）。同时台账 `answerSummary` 只落「接受推荐」三个字——被接受的方案内容只存在于信封问题正文与子 Agent 自己的会话里，事后审计看不出用户到底确认了什么；用户在下一轮自由填写里推翻上一轮已确认决定时，这一点让 Supervisor 转述与子 Agent 出稿都只能靠改写文本来消化。
|
||||
|
||||
**裁决**：
|
||||
|
||||
- 选项结构改为「**A / B / 可选的固定第 3 项**」：第 1 项 = 方案 A，策划子 Agent 的推荐，label 形如 `A · {方案短语}（推荐）`；第 2 项 = 方案 B，一条**真实可行、形状不同**的平行备选（另一条设计岔路，不是 A 的反面、不是稻草人、不是"先按 A 走"），label 形如 `B · {方案短语}`；第 3 项 = 固定文案 `需要原型验证`，**只在体验类决定**（手感、节奏、镜头、可读性等靠试玩才能判断）出现，其余决定只给 A/B。`user.input_request` strict input 的 2～3 项区间与 Other 输入槽（placeholder `改成：……`）不变。question 正文只说要决定什么、为什么现在决定；推荐理由写进 A 的 description；每个 description 说明选择后果与代价。
|
||||
- 映射表改为：A / B → `confirmed / user_option`；`需要原型验证` → `prototype_pending / user_option`（同 ID 30～90 分钟微型原型项的规则不变）；自由填写 → `confirmed / user_freeform`。**`default_pending` 收回为唯一来源——未提问、由子 Agent 按默认建议填写的字段**（`answerSource=default`、`round=0`，与第 12 节提交校验「前缀之后只允许追加 `default_pending` 默认决定」完全一致）。由此三个决定状态各只有一个来源：`confirmed` = 用户拍板，`prototype_pending` = 用户要求验证，`default_pending` = 没问过。
|
||||
- 状态映射按 **label** 而非位置：Runtime 校验信封第 1 项以 `A` 加分隔符开头、第 2 项以 `B` 加分隔符开头（分隔符 `·`/`:`/`-` 宽松）、第 3 项若存在必须逐字等于 `需要原型验证`，不满足按信封格式错误回灌重试（受既有未推进回合预算约束）；`answerSummary` 直接落所选 label，台账自描述。
|
||||
- **已确认决定被后续自由填写推翻（改口）**：M1 内**不改合同**。台账前缀不可变，两条 `confirmed` 并存；Supervisor 转述 continuation 时必须在被推翻的那条之后注明「已被第 N 轮回答推翻，以后者为准」，用户答案原文仍逐字保留（不得改写、拆分或搬到别的轮次），子 Agent 按后者出稿并在新决定的 topic 中写明推翻关系。`supersedes` 字段进 `plan-gdd.v1` 列为 M2 候选。原型实测三次改口 Supervisor 均能自行消化，但其中一次是靠改写用户答案原文（转述保真审计报「内容缺失」），故此规则必须写进 Supervisor prompt，不能默认它会做对。
|
||||
- 提问纪律补一条：平台事实已定的事（含"移动/桌面优先级"）与 MVP 规则已排除的事（多人/联机/商城/服务器）**不作为问题**。A/B 格式会诱使模型去问"天然二选一"但无价值的问题（实测一轮 3 张卡里 2 张是这种），必须在 prompt 里堵住。
|
||||
|
||||
**为什么现在不改第 5.2 节正文、不进 `M1C-2b`**：`M1C-2b` 正在隔离工作树进行，其合入门禁（3 轮上限、continuation 重放幂等、答案绑定冲突被拒）与选项文案无关；它按现行第 5.2 节映射表实现即可，随后由 `M1C-2c` 翻映射、加信封形状校验与 prompt 文案。**`M1D-1` 前端决策卡必须直接按本节实现**（label 动态渲染、默认焦点在 A、Other 槽不变），避免做两遍。第 5.2 节、第 5.1 节 prompt 段与第 23.6 节「仍冻结：固定选项」一句在 `M1C-2b` 合回后按本节改写。
|
||||
|
||||
**顺带核对项（归 `M1E`）**：`plan.submit_gdd` 连续校验失败必须有**次数**上限。本地实测无界时，模型对大载荷序列化出错后连续 40 余次重试，每次重放全部历史，单次 prompt 涨到 15 万 token；生产的 240/300 秒预算注入兜不住「硬超时注入后仍连续校验失败」的情形。若第 12 节 retry 状态机没有该上限，补一个（原型取 5 次）。
|
||||
|
||||
## 24. 最终不变量摘要
|
||||
|
||||
- 策划与构建是两个不同 profile/source 的 run，由用户动作连接，不由 Agent 自行升级。
|
||||
|
||||
Reference in New Issue
Block a user