决策卡 A/B 修订改回恒定三项，标注 M1C-2b 已合回、M1C-2c 可开工

- 技术方案 §5.2 指向注 / §23.8 M1C-2c 行 / §23.9：第 3 项「需要原型验证」每张卡固定给出，
  description 须给出可执行的验证方式；信封形状校验改为恰好三项
- §23.9 与 decision-log 条目：M1C-2b 已快进合回并把固定三选项的校验与映射冻结在
  planning coordinator，映射翻转/形状校验/prompt 文案由 M1C-2c 承接，现在即可开工
- decision-log：补 M1C-2b 条目与本条之间缺失的空行

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/project-memory/shared-memory/decision-log.md

@@ -16,13 +16,14 @@
 - **门禁中修复的测试缺陷**：并发整组首次复跑时，锁序测试把“回答线程开始”误当成“已得到调度”，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 本包实现及门禁已完成，并已快进合回 `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 个自定义方案被信封形状校验拒回并自行改正。
+- **裁决**：决策卡三选项从「接受推荐 / 暂按推荐 / 需要原型验证」（同一条推荐的三种采纳程度）改为「方案 A（推荐）/ 方案 B（真实可行、形状不同的平行备选）/ 固定『需要原型验证』」，仍恒定三项，第 3 项的 description 须给出这一题可执行的验证方式。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 项换成自定义方案 C，被信封形状校验拒回并自行改正。（首版曾允许第 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` 行。
+- **与 `M1C-2b` 的关系**：拟定本条时 `M1C-2b` 尚在隔离工作树，其合入门禁（3 轮上限、continuation 重放幂等、答案绑定冲突被拒）与选项文案无关，故按当时的 §5.2 映射表实现，并已于同日快进合回（见上一条）——它把「单题、`第N轮·关键决定`、固定三选项」的校验与「三个固定选项/自由填写 → state、answerSource、answerSummary」的确定性派生冻结在 planning coordinator 里。映射翻转、信封形状校验与 prompt 文案由新立的 **`M1C-2c`**（依赖 `M1C-2b`，现在即可开工）承接。**`M1D-1` 前端决策卡直接按新语义实现**（label 动态渲染、默认焦点 A、Other 槽不变），避免做两遍。§5.2 正文、§5.1 prompt 段与 §23.6「仍冻结：固定选项」一句由 `M1C-2c` 一并改写；本轮只在 §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 节。

docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md

@@ -417,7 +417,7 @@ 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 节实现。
+> **2026-08-17 拟定修订（见第 23.9 节，由 `M1C-2c` 落地）**：选项语义改为「方案 A（推荐）/ 方案 B（平行备选）/ 固定『需要原型验证』」（仍恒定三项），A、B 均记 `confirmed / user_option`，`default_pending` 收回为未提问默认项的唯一来源。本节正文是已合回的 `M1C-2b` 的实现依据（固定三选项的校验与映射已冻结在其 planning coordinator 里）；`M1C-2c` 落地时按第 23.9 节改写本节，`M1D-1` 前端决策卡直接按第 23.9 节实现。
 
 每次 `user.input_request` 固定只含一题：
 
@@ -2022,7 +2022,7 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 | `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` | **实现与本包门禁已完成并已快进合回 `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 轮/幂等/绑定门禁 |
+| `M1C-2c` | 决策卡 A/B 语义（第 23.9 节，2026-08-17 立包）：选项 → 台账映射改为 A/B 均 `confirmed/user_option`、信封 label 形状校验、planning role brief 与 Supervisor prompt 文案（B 必须是真实岔路、第 3 项恒定且 description 须给出可执行验证方式、改口转述规则、提问纪律） | `M1C-2b` | 选 B 记 `confirmed/user_option`；缺第 3 项或第 3 项非固定文案的信封被拒并回灌；未提问默认项仍只能 `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 节测试矩阵中跨层场景 |
@@ -2042,19 +2042,19 @@ 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` 合入后生效）
+### 23.9 决策卡选项语义修订：A/B 平行方案与决定状态来源唯一化（2026-08-17 拟定，由 `M1C-2c` 落地）
 
 **问题**：第 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 / 固定第 3 项**」，仍恒定三项：第 1 项 = 方案 A，策划子 Agent 的推荐，label 形如 `A · {方案短语}（推荐）`；第 2 项 = 方案 B，一条**真实可行、形状不同**的平行备选（另一条设计岔路，不是 A 的反面、不是稻草人、不是"先按 A 走"），label 形如 `B · {方案短语}`；第 3 项 = 固定文案 `需要原型验证`，**每张卡都给**，description 写清这一题做原型要验证什么、怎么做（30～90 分钟占位资产微型原型、让谁试玩、观察什么），对方向性问题也要给出可执行的验证方式。`user.input_request` strict input 与 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，台账自描述。
+- 状态映射按 **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` 合回后按本节改写。
+**为什么不进 `M1C-2b`、由 `M1C-2c` 落地**：拟定本节时 `M1C-2b` 尚在隔离工作树，其合入门禁（3 轮上限、continuation 重放幂等、答案绑定冲突被拒）与选项文案无关；它按当时的第 5.2 节映射表实现并已于 2026-08-17 快进合回，把「单题、`第N轮·关键决定`、固定三选项」的校验与「三个固定选项/自由填写 → state、answerSource、answerSummary」的确定性派生冻结在 planning coordinator 里。随后由 `M1C-2c` 翻映射、改信封形状校验、换 prompt 文案，现在即可开工。**`M1D-1` 前端决策卡必须直接按本节实现**（label 动态渲染、默认焦点在 A、Other 槽不变），避免做两遍。第 5.2 节、第 5.1 节 prompt 段与第 23.6 节「仍冻结：固定选项」一句由 `M1C-2c` 按本节改写。
 
 **顺带核对项（归 `M1E`）**：`plan.submit_gdd` 连续校验失败必须有**次数**上限。本地实测无界时，模型对大载荷序列化出错后连续 40 余次重试，每次重放全部历史，单次 prompt 涨到 15 万 token；生产的 240/300 秒预算注入兜不住「硬超时注入后仍连续校验失败」的情形。若第 12 节 retry 状态机没有该上限，补一个（原型取 5 次）。