文档：订正 M1A-1 的 retry 复核结论，plan 根 run 保源单列为 M1A-3

M1A-1 把 resolve_game_creator_agent_runtime_retry_configuration_at 判成
「已被 profile 挡住、本包不改函数」。该结论只对了一半：它确实不会让 plan
误得 autonomous 语义，但复核模板只问了「plan 进 matcher 后会不会误得不该
有的语义」，没问「plan 落到通用兜底后会不会丢掉该有的语义」。这个调用点
既是判据也是 run 构造器，两个方向都要问。

缺陷：plan 根 run 是 standard + 顶层无 parent，两个特例分支都不命中，落
agent-background-task 兜底。run_profile 由 agent_runtime_run_profile_identity_at
原样返回，实际只丢 source——第 22 节证据表原写「保留 source/profile」会
误导实现者去修一个没坏的东西，一并订正。

降级无声：retry 走 start_game_creator_agent_background_task_with_link_in_
session_lane_at，该路径对 source 无门禁；validate_agent_runtime_run_profile_
binding_record 也只在 autonomous-game-build 档要求可信 source。于是造出一个
正规启动路径造不出来的状态。

后果分两类。放行类：reject_supervisor_plan_root_steer 只认精确 source，
重试后不再命中，steer 重新放开，违反第 4.1 / 23.1 节裁决。死路类：
root_control_authority 转 false 后广告层删掉 agent.goal_contract 与
agent.acceptance_update，validate_goal_contract_record 也拒绝建约，重试后
的根 run 建不出 Goal Contract，第 13.0 节审批前置门的取证永远收敛不了。
agent.delegate 不受该权限影响、委派照发，所以故障要到审批那一步才暴露。

处置：不回改已合入的 M1A-1，第 23.8 节新列 M1A-3，一并交付第 4.1 节要求的
强判据函数与 generic fallback 前的 exact plan root 分支；M1C-2a 依赖随之改为
M1C-1、M1A-3。修法边界写死：gui/cli 根 run 的现役降级行为不在范围，只能在
兜底之前插分支、不得改兜底默认值。

decision-log 原条目对应半句加删除线并挂指针，避免后续 PR 沿用旧结论。

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

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

@@ -1713,7 +1713,7 @@ M0 文档 PR 本身最低验证：Markdown 结构与三张 Mermaid 图可解析
 | 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 状态 |
-| plan retry | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/lifecycle_control.rs:740-772,775-907` | generic standard fallback 前保留 exact plan source/profile/session lineage |
+| plan retry | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/lifecycle_control.rs:740-772,775-907` | generic standard fallback 前保留 exact plan source/profile/session lineage。**2026-08-13 复核归属**：本项属工作包 `M1A-3`（第 23.8 节），不属已合入的 `M1A-1`——后者的消费点复核只覆盖了「plan 是否误得 autonomous 语义」这一半。现役实现里 `run_profile` 由 `agent_runtime_run_profile_identity_at` 原样返回、并未丢失，**实际只丢 source**；降级无声是因为 retry 走的 `start_game_creator_agent_background_task_with_link_in_session_lane_at` 对 source 无门禁，而 `validate_agent_runtime_run_profile_binding_record` 只在 `autonomous-game-build` 档要求可信 source |
 | planning hydrate command | `apps/ai-game-creator-shell/src-tauri/src/commands.rs:856-875`、`apps/ai-game-creator-shell/src-tauri/src/main.rs:2178-2180`、`apps/ai-game-creator-shell/src/App.tsx:1550,1650,2957,3364,3702` | 新增单一 hydrate command/注册与前端生命周期调用；不把 runtime polling 当 GDD authority |
 | agent.db | `apps/ai-game-creator-shell/src-tauri/src/project/agent_db.rs:955-1034,1551-1605,1995-2088` | 普通 append 不满足 decision 幂等；新增专用保留入口 |
 | 16 任务 DAG | `server-rs/crates/shared-contracts/src/game_creation_app.rs:263-425` | 2026-08-12 复核 seed 仍是 16 个，M0/M1 不改拓扑；但固定 DAG 已不是完成语义的唯一来源，见下一行 |
@@ -1956,11 +1956,12 @@ M0 完成不表示任何策划功能已上线。M1 的功能实现仍未开始
 | --- | --- | --- | --- |
 | `M1A-1` | source 常量 `project-supervisor-plan` + 进可信 matcher + steer 独立否决 | — | **已落地**。消费点复核见 decision-log 2026-08-13 `M1A-1` 条；steer `kind=plan-root-steer-unsupported`，独立于 matcher |
 | `M1A-2` | 两层工具面 + `project-planning` 角色 brief | `M1A-1` | 两层工具面快照；`user.input_request` 在广告层不出现且执行层仍拒（第 19 节第 2 条两半） |
+| `M1A-3` | plan 根 run 强判据函数 + retry 保源（本节下方「`M1A-3` 的由来」，规格见第 4.1 节第 5、7 段） | `M1A-1` | 强判据须核 durable binding 并逐项相等，**不得只比较内存中的 `runtime.source`**；retry 命中 plan 根 run 时保留 `project-supervisor-plan` 并在项目锁内写 session revision+1 successor，身份校验失败**直接拒绝 retry 而非降级**；`project-supervisor-gui/cli` 的现役 retry 行为逐字节不变。**必须早于 `M1C-2a`** |
 | `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` | 三动作全通；版本+指纹竞态防护；两窗口并发；**连续多次修订均可通过且 `repair_depth` 不变** |
-| `M1C-2a` | Goal Contract 接线：turn 1 冻结、固定验收图、审批前置门取证 | `M1C-1` | turn 1 只能是一个 `agent.goal_contract`；`acceptanceNodes` 不接受自定义；**第 13.0 节审批前置门：取证未通过时不出现审批卡、而是产生返工委派**（取证顺序是协议时序问题，归本包而非 `M1C-1`） |
+| `M1C-2a` | Goal Contract 接线：turn 1 冻结、固定验收图、审批前置门取证 | `M1C-1`、`M1A-3` | 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` | 「直接开建」跳过路径与现状零差异 |
@@ -1970,7 +1971,9 @@ M0 完成不表示任何策划功能已上线。M1 的功能实现仍未开始
 
 - `M1C-0` 与 `M1C-1` 拆开的理由是**风险类别不同**：前者改的是 master 已发布的静态委派机制，后者是 M1 新增功能。合并成一个 PR 会让「做游戏链路返工额度未被误放宽」这条最关键的回归淹没在审批闭环的 diff 里。拆开后 `M1C-0` 全程不产生半状态——它没有写入方，`UserRevisionRequested` 要到 `M1C-1` 才被写出。
 - `M1C-2` 拆成 a/b 的理由是两者失败模式无关：Goal Contract 是协议时序问题，澄清中转是身份派生与幂等问题。
-- 顺序是依赖顺序不是优先级。`M1C-0` 只依赖 `M1A-1`，可与 `M1B-*` 并行。
+- 顺序是依赖顺序不是优先级。`M1C-0` 只依赖 `M1A-1`，可与 `M1B-*` 并行；`M1A-3` 同样只依赖 `M1A-1`，可与 `M1A-2`、`M1B-*` 并行。
+
+**`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 的复核必须双向提问。**
 
 ## 24. 最终不变量摘要