Codex/fix pr188 191 ci (#194)

Reviewed-on: http://192.168.35.82/git/GenarrativeAI/Genarrative/pulls/194
Co-authored-by: kdletters <kdletters@qq.com>
Co-committed-by: kdletters <kdletters@qq.com>

docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md

@@ -1085,7 +1085,6 @@ Runtime 只在以下客观条件同时满足时写 `contractStatus=evidence-read
 
 ### 单层 repair
 
-当前可信父 Run 只有在已认领同一父 Run 的原 delivery，且原回执为 `needs-repair` 或父 Run 明确判定语义未满足时，才能发出新的 `agent.delegate`，并把 `repairOfDelegationId` 指向该原 `delegationId`。可信父 Run 包括原 `project-supervisor`，以及通过 `project-supervisor-game-chat` 根绑定、父 binding fingerprint 和 task/session/run/delegation 身份链完整证明的唯一 `code-prototype` 主 Run；仅凭 Agent ID、task 文案或错误关键词不得获得该权限。被引用记录必须属于当前可信父 Run、状态为 `claimed-by-parent`，且自身不是 repair；返工目标必须与原 delivery 的专业 Agent 完全一致。
 
 repair 深度固定为 `1`；同一原 delivery 同时最多存在一个非 `suppressed` repair。相同 durable action/身份重放必须幂等复用已预留或已创建的 repair；不同 action 的重复或并发竞争必须在 delivery 锁内发现既有非 suppressed repair 后拒绝，不能创建第二个活跃目标 run、第二份可认领回执或 `-dup-*` repair。repair 结果继续唤醒、认领并收束到原可信父 Session/run；它不能创建第二条面向用户的 assistant。repair 再次 `needs-repair` 时不得继续嵌套委派，当前可信父 Run 只能基于现有证据裁决或由根 Supervisor 走用户输入门禁。`suppressed` repair 不视为已完成返工，原 `repairRequired` 门禁必须继续阻断 finalization；同一 durable action 可以在无终态字段时把原 delivery 恢复为 `dispatched`，若该 action 已持久失败，新 action 也只可在既有 repair 全部 suppressed 时创建替代的基础设施投递，不能形成第二轮语义返工。已 suppressed 且未形成 child task 的旧 delivery 不再参与 capability、claim 或 completion barrier 的身份验证，避免恢复入口被失败前置记录永久堵死；所有非 suppressed delivery 仍必须逐条通过完整可信链校验。
 
@@ -1095,7 +1094,6 @@ repair 深度固定为 `1`；同一原 delivery 同时最多存在一个非 `sup
 
 - 专业 Agent 的 task prompt 必须带完整委派合同：`delegationId / task / acceptanceCriteria / expectedArtifacts / repairOfDelegationId`，以及当前 Agent/Session/run 与父 Supervisor 身份；同时明确它只提交内部回执和证据，不直接回答正式用户。
 - 结构化计划 checkpoint 只有在步骤或状态真实变化时才允许单独提交。当前 `in_progress` 步骤所需事实、权限和合同已经齐全时，Agent 必须在同一 Provider 响应附带具体 action；格式修复也必须保留原本可执行的动作意图，不能连续只改 `explanation` 或反复只调用 `update_agent_plan`。Runtime 的未完成计划 observation 和 `nextStep` 使用同一口径，真实 E2E 对 repair 创建另设有界父 loop 门禁。
-- 当前可信父 Run 的 prompt 必须明确：不得把 `evidence-ready` 当作自动语义通过，不得忽略或吞掉 `needs-repair`。game-chat `code-prototype` 发现 ready delivery 时必须先以确定性 `agent.run_status(scope=self)` 认领并观察；普通失败或不合法安全默认 marker 在认领后立即失败收束，不得再发 Provider 请求。只有完整合法的 `game-chat-safe-default-repair.v1` marker 允许一次同合同返工；该返工由 Runtime 直接按原 `targetAgentId / acceptanceCriteria / expectedArtifacts / delegationId` 生成确定性 `agent.delegate`，不再请求 Provider 决策。repairRequired 存在时重复 route、读取、查询或其它计划全部由 liveness 门拒绝；第二层返工、目标 Agent 变化、合同扩大或身份漂移全部失败关闭。对无法自行裁决的冲突、缺失决策或用户偏好，只能由根 Supervisor 汇总后通过既有 `user.input_request` 向用户提问，专业 Agent 与 child 不得各自直达用户。
 - finalization 在项目锁内必须确认所有必要 static delivery 已终态、ready 已认领、claim 已 Observed、允许的单次 repair 已收束；同时要求结构化计划全部完成，并清零 verification、pending confirmation、`user.input_request`、process/reconciliation、isolated join、Goal/steer 等既有 blocker。可信 `code-prototype` 只能管理其绑定的内部 delivery 并收束自身 Run；只有根 `project-supervisor` Session/run 可以写入唯一正式用户 assistant 和根 completed 投影。
 
 ### Provider 多 action 原批次门禁

docs/technical/【技术方案】npm-workspaces统一依赖边界-2026-08-21.md

@@ -119,7 +119,7 @@ git diff --check
 干净安装验收必须在没有历史根或子 App `node_modules` 的隔离工作树执行。平台补充门禁：
 
 - Linux：根、后台、预览部署器、Spine 工具构建，Desktop/AGC Tauri release smoke。
-- Windows x64：根 `npm ci` 后执行 AGC game-chat release，核对 Codex sidecar 完整性。
+- Windows x64：根 `npm ci` 后执行 AGC Tauri release smoke，核对 Codex sidecar 完整性。
 - Android：Expo config/export，并在可用 EAS 环境执行一次本地 Android build。
 - macOS/iOS：在可用 runner 执行 simulator build；缺少 runner 时必须标记未验证。
 

docs/technical/【技术方案】客户端素材创作无限画布阶段一合同-2026-08-05.md

@@ -58,7 +58,6 @@ apps/ai-game-creator-shell/src/features/asset-canvas/tauriImageCanvasHostAdapter
 - `image-canvas-core` 只含纯 TypeScript 的画布模型、几何、选择、图层命令、历史、序列化、防御校验和状态机；不得依赖 React、DOM、Tauri、HTTP、账号、钱包或浏览器存储。
 - `image-canvas-react` 只含 React 视图、hooks、交互控制器和通用 UI，依赖 core 和注入的 Host Port；不得直接 import Tauri API、站点请求客户端、账户 store 或钱包 store。
 - 网站 adapter 可以依赖账户、钱包、现有服务端 editor project、云端素材库、OSS/asset object 和生成 API。
-- Tauri adapter 可以依赖 `invoke/listen`、本地项目上下文、受控媒体命令、manifest、项目 revision、草稿 sidecar，以及宿主进程内的陶泥儿账号会话快照。普通模式的服务 origin 由构建环境固定；网站 Access Token 延续现有 WebView 客户端存储，GUI 与 Runner 只接收当前 `userId + Token + authGeneration` 内存快照，不把 Token 写入 Rust AppData 配置、共享画布或项目事实。仅独立 standalone game-chat release 或显式高级自定义模式可以读取其隔离 AppData 中的 External v1 Developer API Key 配置。
 - 依赖方向只能是“宿主 adapter -> React/UI -> core”。core/react 不得反向 import 任一宿主。
 
 ### 3.2 禁止复制的验收门
@@ -200,7 +199,6 @@ interface ImageCanvasHostPort {
 - `hostRevision` 是宿主权威提交版本的字符串表示：Tauri 使用十进制项目 mutation revision，网站使用现有服务端 editor project revision。共享 UI 只透传/展示，不比较不同宿主的 revision。
 - `commitId/idempotencyKey` 由共享流程在第一次正式保存前生成；响应未知时两宿主都复用原完整请求。`expectedHostRevision` 由 adapter 从已加载的权威宿主快照提供，Tauri 必须无损解析为本文的安全整数 `expectedRevision`。
 - Web adapter 把草稿、导入、生成、导出和提交映射到现有服务端 editor project、云端素材库及账户/钱包链路。
-- Tauri adapter 把草稿、导入、导出和提交映射到本文第 7 至 11 节的本地合同；普通模式远端媒体编辑固定使用官方 origin 下的 `/api/editor/*`、`/api/assets/*` 与 `/api/runtime/external-generation/jobs/*`，后端从网站 Access Token 解析 owner 并进入统一生成队列与泥点预扣/退款。普通 Launcher、开发工作台和已认证 game-chat 均不显示或维护 Base URL / API Key。仅独立 standalone game-chat release 或显式高级自定义模式使用隔离 AppData 的 `editorApi.baseUrl/apiKey` 调用 `/api/external/v1/*`；两种模式的凭据都不能进入共享画布、项目 sidecar、manifest、事件或错误正文。
 
 ### 3.4 主站 UI 对齐与共享画布 chrome
 
@@ -962,7 +960,6 @@ confirmation-required
 
 ### 14.4 首版请求范围与恢复
 
-- 主站网页画布与普通 AI 游戏创作 Tauri 客户端统一使用 `POST /api/editor/images/generations`、`POST /api/editor/images/edits` 与 `GET /api/runtime/external-generation/jobs/{operationId}`。普通 AGC 使用登录后的平台 Access Token 和稳定 `Idempotency-Key`；提交同时兼容站内 `200 + queueState.operationId` 与 inline 完成响应，队列状态读取 `job` 包装。官方 origin 由构建环境固定且不可由普通用户修改。第三方 Agent/CLI、独立 standalone game-chat release 或显式高级自定义模式仍走 `/api/external/v1` 与 Developer API Key。
 - 普通模式图片生成和编辑支持相同 prompt、`1:1 | 2:3 | 3:2 | 9:16 | 16:9`、`0.5K | 1K | 2K`、合法 `assetKind` 与参考资源约束。refine 的 `sourceReferenceId` 必须是当前账号已登记的服务端项目 resourceId 或素材 assetId；`objectKey`、URL、本地 `local-asset:*` 与 `assetObjectId` 都不能冒充该业务引用。本地独有图片在用户确认后先走 `/api/assets/direct-upload-tickets` → OSS form → `/api/assets/objects/confirm`，再创建当前账号拥有的项目资源或素材记录，取得正式 ID 后才可进入编辑请求。额外参考最多 8 个。高级 External v1 模式使用同一业务引用约束，但走其独立外部路由与 Developer Key 鉴权。
 - 客户端参考媒体直传固定复用 `legacyPrefix=generated-character-drafts`，不得把内部用途目录作为新 legacy prefix，也不得扩大服务端白名单。图片画布的 `pathSegments` 固定为 `editor / asset-canvas-references / <projectId> / <draftId> / <generationId>`；全类型资源编辑的本地视频、音频等源媒体固定为 `editor / resource-editor-references / <projectId> / <operationId>`。两条路径都只持久化 confirm 后的稳定 objectKey，不持久化 ticket 或签名 URL。
 - 图片参考资源准备失败按阶段投影安全错误码：本地读取/校验为 `reference-material-invalid`，票据为 `reference-ticket-failed`，OSS 表单上传为 `reference-object-upload-failed`，对象确认为 `reference-confirm-failed`；`401` 进入当前账号代际的单飞刷新，刷新失败或重试后仍未授权才返回 `authentication-required`，`403` 直接按权限不足处理。任一阶段失败都必须保持 `operationId=null`、生成 endpoint/request body 未建立，不得进入扣费或生成提交。普通错误不得包含 ticket host、formFields、policy、signature、Token、API Key、Provider 响应正文或本机绝对路径。
@@ -993,7 +990,6 @@ confirmation-required
 - 资源聚焦态的所有现役资源均提供“编辑资源”，覆盖 manifest asset、已完成任务产物、已导入附件、Agent 文本回执和项目版本。后端必须按 manifest、任务完成态、上传登记或回执身份重新核验来源；没有唯一来源身份的本地媒体不得仅凭前端路径进入编辑。
 - 静态 PNG / JPEG / WebP 继续使用 `AssetCanvasSurface + intent=refine`，自动加载唯一源图片，并把源资源身份作为图片编辑请求的必选引用。任务产物或附件中的静态图片必须先正规化为正式 manifest asset，再进入现有图片画布。
 - refine 入口不能只在 WebView 进程内缓存 `draftId`。每次打开先在正式 draft sidecar 中按 `projectId + intent=refine + sourceAssetId + active status` 有界发现：唯一命中沿用原 `draftId` 并生成新 `sessionId`，零命中才创建，多命中进入 `reconciliation-required`；`committed/cancelled` 不属于 active 候选。
-- 普通客户端确认编辑后固定调用 `POST /api/editor/images/edits`；提示词、比例、尺寸、资源用途、泥点计费和原 operation 恢复继续复用现有生成合同，请求凭据来自当前平台登录态的 native 内存快照，不进入资源编辑账本。独立 game-chat/高级自定义模式保留 `/api/external/v1/editor/images/edits`。
 - SVG、UTF-8 文档、代码和 Agent 文本回执使用文本差异派生：把源内容当作不可信数据交给当前客户端 LLM，响应必须是完整、唯一的结构化内容 envelope；JSON、SVG 等可校验格式必须在落盘前重新校验。结果写入新的本地路径和 manifest asset，不能直接写回源文件。Agent 回执原记录不转写、不删除，新 asset 以回执资源身份登记血缘。
 - 文本、SVG 与 Agent 回执在 Provider 调用前必须先持久化 request-issued；成功响应必须先原子安装到与原 operation、请求指纹和内容摘要绑定的私有 durable handoff，再做 envelope 解析、格式校验和 staging。issued 后缺少可信 handoff 只能对账；handoff 已存在且校验通过时恢复只消费该正文，两种情况都禁止再次调用 Provider。
 - 普通客户端视频使用 `POST /api/editor/videos/generations`。有稳定远端引用时直接作为 `referenceVideoSrcs`，只有本地文件时先走 `/api/assets/direct-upload-tickets`、OSS 表单上传和 `/api/assets/objects/confirm`，再提交同一逻辑生成；结果必须下载到新的本地文件并登记远端稳定身份。

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

@@ -1,9 +1,7 @@
 # 立项策划 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 门。**`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。`M1C-2b` 已实现 planning 澄清中转、三轮确定性 session/continuation 投影、审批后修订谱系和 Provider 活跃时间预算，并已合回 `feat/five_min_design`；`M1D-1` 已提供 hydrate/read model 与审批卡，`M1D-2` 已接入新项目入口分流、阶段进度和实际项目总控页面挂载；`M1E` 已完成 submit 连续拒绝的有界收束、重启恢复边界与既有回归覆盖审计。M1 策划闭环完成；approved GDD 构建绑定与完整下游留给 M2。
 
 ## 1. 背景与目标
 
@@ -16,7 +14,6 @@
 1. 一句需求经过不超过 3 轮关键澄清，形成包含一个完整可玩闭环的 Fast GDD。
 2. 策划阶段没有构建、委派、生成、预览或通用文件写能力。
 3. GDD 版本、用户决定和构建引用都有确定提交点、强身份绑定、幂等重放和崩溃恢复合同。
-4. 老项目与“直接开建”保持现行行为；是否策划不成为 game-chat 的强制前置条件。
 5. 后续 M1 无需任何仓库外材料即可实现 source、Prompt、工具、schema、审批与恢复。
 
 非目标：
@@ -25,7 +22,6 @@
 - M0/M1 不修改现行 16 任务 DAG，不新增第 17 个任务。
 - 本期不实现知识图谱；只保留强类型可空槽，v1 必须为空且 UI 不渲染。
 - 不提供引擎选择字段。平台只有自包含 Web 运行事实，由 Runtime 注入并校验。
-- 不修改现役 game-chat 单主 `code-prototype` + 按需美术 child 结构。
 - 不修改 SpacetimeDB、HTTP API、OpenAPI 或 `shared-contracts` 中的正式作品数据合同。
 - M1 不实现 300 秒硬停；以 3 轮硬上限和 240 秒 Agent 活跃时间软提示收束。
 
@@ -61,8 +57,6 @@
 | --- | --- | --- |
 | `M0A-1` 文档基线 | **需修订**，即本工作包 `M0A-3` | 是 D6 的唯一载体 |
 | `M0A-2` owner 产物验证 | **不受影响，但不可复用** | 见下 |
-| `M0B-1` game-chat 美术边界 | **不受影响** | 只处理 game-chat 单主谱系 |
-| `M0B-2` game-chat 前端投影 | **不受影响** | 只认 game-chat root → 单主 `code-prototype` 谱系 |
 
 M0 三个代码工作包无一行按 D6 编写，**不需要为新设计回退或修改任何已合入代码**。在本次 M0A-3 文档修订时，全仓库检索 `fast_gdd`、`.agent/planning`、`project-supervisor-plan-chat`、`is_exact_supervisor_plan_run_at` 均零命中，M1 代码尚未落地，因此改文档没有迁移成本；后续 M1A 工作包的落地状态以本文当前状态行和第 23.6/23.8 节为准。
 
@@ -126,7 +120,6 @@ D9/D10 描述的「manifest ready-task 调度器在 Supervisor 下游启动策
 5. **前置依赖：D11 的“最多 3 轮问询”依赖 WP1 先落地，是强制前置，不是并行工作包。该前置已于 2026-08-13 落地，本条改为记录其成立依据与已完成状态。** WP1（澄清轮次 `clarification_round` 与返工深度 `repair_depth` 拆分，语义见下方，权威定义见 decision-log 2026-08-13 条）与其回归工作包 `WP2` 已合入本分支，完成状态与门禁见第 23.5 节。作为对照记录改造前的事实：改造前 `repair_of_delegation_id.is_some()` 即拒绝（`apps/ai-game-creator-shell/src-tauri/src/delegation.rs:1119-1121`），澄清 continuation 与质量返工共用同一条「深度最多为 1」判据，D11 描述的多轮问询实际上限只有 1 轮，且这 1 轮一旦用掉，同一条委派链就再也做不了任何质量返工；该结论由 `clarification_continuation_chain_supports_multiple_rounds` 走真实 `agent.delegate` 生产路径实证（改造后该用例的断言方向已按预期行为变更反转，见第 23.5 节）。本条不因 WP1 完成而降格：D11 的 3 轮问询能力**只在 WP1 语义生效的前提下成立**，任何回退 WP1 的改动都同时回退 D11 的问询上限。
 6. **登记机制已定稿（原「未决前置」，2026-08-13 处置完成）：`project-planning` 的编译期 agentCatalog 登记方式，不会撞上 `build.rs` 一致性校验。** `project-planning` 目前不在编译期 agentCatalog 里；`build.rs` 的 `validate_seed_task_catalog`（`apps/ai-game-creator-shell/src-tauri/build.rs:23-46`）要求编译出的 `(taskId, groupId, role)` 集合与 `shared_contracts::game_creation_app::new_game_creation_app_seed_tasks()` 逐项相等，不等直接 `panic!`；但该集合只来自 `manifest.agent_catalog.groups[].roles[]`（`build_support/runtime_prompt_bundle.rs:387-398`），不遍历 `agentCatalog` 其它顶层键。结论：`project-planning` 登记为与 `supervisor` 平级、不进 `groups` 数组的独立条目（先例即 `supervisor` 自己——它是 catalog 成员但不是种子 DAG 任务，`runtime_adapter.rs:4-38`），`new_game_creation_app_seed_tasks()` 不需要新增条目，该 catalog 本身也不需要拆分。完整机制、descriptor 元数据取值与编译链路改动清单见第 3.1 节。**但登记只解决 catalog 成员资格，不解决可执行性**——第 3.1 节调研同时发现一个新的、真正阻塞可执行的缺口：`prompt.rs` 的 `game_creator_agent_role_definition`（`prompt.rs:661-679`）硬编码「非 supervisor 即 group 角色」二分，不认识 `project-planning`，需 M1 补一个平行分支；这才是仍然待处置（M1 范围）的前置，不是本条描述的 catalog 登记方式本身。
 
-WP1 定稿的澄清轮次/返工深度语义（供 D11 依赖，权威定义见 decision-log 2026-08-13 条，不在本节重复展开）：`repair_depth` 上限维持 1 不放松，`clarification_round` 上限按 source 区分——`source == AGENT_RUNTIME_SUPERVISOR_GAME_CHAT_SOURCE`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver.rs:109`）时取 1，其它 source（含 D11 的 `project-planning` 委派链）取 3；两个维度都是运行时沿 `repair_of_delegation_id` 链上推断的派生值，不新增 `StaticDelegateDeliveryRecord` 持久字段。
 
 ## 2. 已锁定决定 D1～D11
 
@@ -136,7 +129,6 @@ WP1 定稿的澄清轮次/返工深度语义（供 D11 依赖，权威定义见
 | D2 | 仅首页“做方案”新建项目进入“立项策划”；“做游戏”和“做素材”保持直接开建，等价于当前无 GDD 基线的完整构建路径。 |
 | D3 | 阶段、source、composition、工具、schema、审批命令和 UI 名称按第 3 节注册表冻结。 |
 | D4 | M1 使用 `.agent/planning/` sidecar，不改 `shared-contracts`；是否把 `approvedGddRef` 提升进 manifest 留给 M2，不能在 M1 临时决定。 |
-| D5 | game-chat 只在 M3 可选只读消费有效批准 GDD；没有批准 GDD 时继续走现役快车道。 |
 | ~~D6~~ | **2026-08-12 作废**，由 D9 取代。原文：“立项策划 Agent”是 Project Supervisor 通道的第三 persona，以持久 source 区分，复用 `standard` profile，不注册新的 agentCatalog 身份。作废理由见第 1.1 节；其中“复用 `standard` profile”这一结论方向被 D9 继承，但成立理由完全不同。 |
 | D7 | 本期不实现知识图谱；`basis`、知识 provider trait、composition 槽位可以预留，但 v1 数据必须为 `null`，空字段不渲染。 |
 | D8 | GDD 不含引擎字段；平台事实固定由 Runtime 注入，Agent 不得向用户提问或修改。 |
@@ -153,7 +145,6 @@ WP1 定稿的澄清轮次/返工深度语义（供 D11 依赖，权威定义见
 | 策划 Agent 称呼 | `立项策划 Agent`（2026-08-12 起不再是 persona；2026-08-13 起也不再是「工作流节点」，改为 Supervisor 的静态委派子 Agent，见 D11） |
 | **策划节点 agentId** | `project-planning`（登记 agentCatalog；`project-` 前缀标明项目级、不属任何专业组，故不与 design 组的 `design-director` / `design-foundation` 混淆；登记机制定稿见第 3.1 节，本轮只冻结机制、代码留给 M1） |
 | **策划子 Agent durable source** | `agent-delegate`（**2026-08-13 按 D11 取代原值 `agent-ready-task-scheduler`**。字面量见 `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_tools/delegation.rs:1063`；不新增 source，复用现役静态委派族。该 source 同时是 `validate_user_input_action_owner` 拒绝直接提问的判据之一，见第 19 节第 2 条） |
-| **Supervisor 入口 durable source** | `project-supervisor-plan`（与 `-gui` / `-cli` / `-game-chat` 同族；2026-08-12 取代原预留值 `project-supervisor-plan-chat`，**旧字符串作废不得沿用**，避免字面未变而语义已改导致接错代码路径） |
 | 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 节） |
@@ -265,7 +256,7 @@ composition/brief 相关的强制要求：
 - **needs_change（2026-08-13 对抗性复核补记）**：`task_start.rs` 的 `collect_game_creator_agent_runtime_agent_ids`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/task_start.rs:3-28`）与 `game_creator_agent_role_definition` 是同构的二分硬编码——只显式插入 supervisor id（8 行），再无条件遍历 `GAME_CREATOR_AGENT_GROUP_DEFINITIONS` 插入全部 16 个组角色 task_id（19-23 行，不看当前是否有活跃任务），`project-planning` 既不是 supervisor、也不是组角色、也不是 `agent.spawn_isolated` 产生的动态孤立实例，天然不进入这个集合。此函数是核心 Runtime 推进/恢复驱动 `read_game_creator_agent_runtimes_at`（`entrypoints.rs:756`，被 `commands.rs`/`swarm_cli` 调用）与三处安全网的枚举来源：崩溃恢复扫描（`recovery_scan.rs:448`、`:687`）、root run 被 steer 时的级联取消（`steering.rs:800` 的 `cancel_goal_contract_root_descendants_at`）、委派回执兜底对账（`delivery.rs:1287` 的 `reconcile_game_creator_agent_delegate_receipts_at`，由 `recovery_scan.rs:1102` 触发）。经追踪 `agent.delegate` 派发路径（`delegation.rs` 里对 `start_game_creator_agent_background_task_with_link_at` 的调用），委派首轮任务是同步直接起跑的，不依赖这个集合，因此不属于「首轮即挂」的 blocking 类；但一旦应用重启、Supervisor 根 run 被 steer、或首轮结果的直接投递失败需要兜底对账，`project-planning` 的委派状态都不会被这三处安全网发现和处理，会静默变成孤儿任务，且与第 23.1 节「plan run 是否允许 steer」这条既有待裁决项直接相关（提供了其未验证交互的具体机制证据）。M1 需要给这个函数补一个与「group 角色无条件收录」对称的第三条分支；`runtime_adapter.rs` 里 `game_creator_runtime_agent_catalog_matches_the_existing_role_directory` 测试（同文件 91-121 行）断言 catalog 成员集合与 `{supervisor} ∪ 16 组角色` 精确相等，`project-planning` 登记后这条测试会立即失败，M1 需同步更新其期望集合，不能靠这条测试的失败倒逼才发现遗漏。
 - **benign（不阻塞，仅记录）**：前端 `projectProfessionalAgentLabel`（`apps/ai-game-creator-shell/src/features/agent-runtime/model.ts:1496-1529`）的关键字匹配落不到 `project-planning`，会退化成直接显示原始 `agentId`。纯展示层缺口，不影响功能，M1 顺手补一条分支即可。
 - 未来提醒（写入代码前必须核对，本轮不改）：`pass_artifacts.rs` 的 `agent_role_memory_relative_path_for_task`（`apps/ai-game-creator-shell/src-tauri/src/agent/generation/pass_artifacts.rs:335-347`）也是「先特判 supervisor、再遍历 group」的同构硬编码，若不加第三条 `project-planning` 分支，运行时对它调用会落入 346 行的 `Err("未知 Agent 任务")`。
-- 排雷提示（供未来维护者，非本轮改动项）：全仓库检索确认，当前没有任何生产代码枚举 runtime `AgentCatalog`（`.iter()` 零生产调用），前端「团队」清单（`agentPresentation.ts` 的 `groupConfigs`）与 `agent.route_manifest`（`delivery.rs`）都是硬编码字面量/精确字符串判断，结构上不会把 `project-planning` 带进「做游戏」团队清单或路由清单。但**未来如果有人写「遍历 AgentCatalog 生成 UI 团队卡片/prompt 团队成员清单/任何 route 白名单」这类代码，必须显式按 `groupId ∈ {design, balance, art, audio, code, publishing}` 六个真实组过滤，或显式排除 `project-planning`（和 `supervisor`）这两个组外单节点**——这也是坚持 `groupId` 必须自引用为 `"project-planning"`、不能复用 `"design"` 的根本原因。
+- 排雷提示（供未来维护者，非本轮改动项）：全仓库检索确认，当前没有任何生产代码枚举 runtime `AgentCatalog`（`.iter()` 零生产调用），前端「团队」清单（`agentPresentation.ts` 的 `groupConfigs`）都是硬编码字面量/精确字符串判断，结构上不会把 `project-planning` 带进「做游戏」团队清单。但**未来如果有人写「遍历 AgentCatalog 生成 UI 团队卡片/prompt 团队成员清单/任何 route 白名单」这类代码，必须显式按 `groupId ∈ {design, balance, art, audio, code, publishing}` 六个真实组过滤，或显式排除 `project-planning`（和 `supervisor`）这两个组外单节点**——这也是坚持 `groupId` 必须自引用为 `"project-planning"`、不能复用 `"design"` 的根本原因。
 
 **本轮范围声明**：以上登记机制与代码改动清单均属 **M1 实现范围**，本轮（`M0A-3` 文档工作包）只冻结机制、不落地任何代码——不改 `manifest.json`、不改 `runtime_prompt_bundle.rs`、不改 `runtime_adapter.rs`、不改任何 `.rs` 文件。理由：`project-planning` 目前没有 prompt、没有任何路径能调用它，现在就注册 catalog 而不同步处理上面的 blocking 项，等于给发布产物加死重（一个「看似已登记、实则一调用就硬失败」的 Agent 身份），注册代码应与 M1 的 prompt/source 一起落地。
 
@@ -277,7 +268,6 @@ flowchart TD
     subgraph SUP["Project Supervisor 顶层 root run（三个入口 source）"]
         SPLAN["做方案入口<br/>source=project-supervisor-plan<br/>profile=standard"]
         BUILD["完整构建 Supervisor<br/>source=project-supervisor-gui 或 project-supervisor-cli<br/>profile=autonomous-game-build"]
-        CHAT["game-chat Supervisor<br/>source=project-supervisor-game-chat<br/>profile=autonomous-game-build"]
     end
     U <-->|"唯一对话对象；问答物理落 Supervisor 会话文件"| SPLAN
     SPLAN -->|"agent.delegate 静态委派（profile 由父 run 继承）"| PLANAGENT["立项策划子 Agent<br/>agentId=project-planning<br/>source=agent-delegate<br/>profile=standard<br/>composition=runtime（复用）"]
@@ -318,7 +308,6 @@ flowchart TD
 
 **「同一条策划链路」的判定不能只看子 run 的 `agentId`。** 委派子 run 的身份权威是 `(parentAgentId, parentRunId, delegationId)` 三元组加上 delivery 记录本身；多轮 continuation 每轮都是新的 `delegationId` 与新的 `targetRunId`，靠 `repair_of_delegation_id` 串成链。判定「这是不是当前策划链路的一环」必须沿该链上溯到根 delegation 并核对根 delegation 的 `parentRunId` 等于当前 plan 根 run，不得用「`agentId=project-planning` 即认为属于本链路」这种弱判据——否则跨 run 的旧策划残留会被误纳入当前轮。
 
-M1 不能把新 source 直接塞进一个被 autonomous 语义复用的总 matcher。source predicate 必须拆成三种语义：top-level Supervisor trusted matcher 接受 gui/cli/game-chat/plan；autonomous-build trusted matcher仍只接受现役 gui/cli/game-chat；plan binding matcher只接受 top-level `project-supervisor + standard + project-supervisor-plan`。现有 run configuration、completion gate 和恢复调用点逐个改用正确 predicate，确保 `plan + autonomous-game-build` 永远非法。前端已有 `runProfile + source` 提交链只能作为请求；后端必须重新验证，不能信任页面选择。
 
 2026-08-12 复核：上述三分法在 2026-08-11 动态目标验收图合入后**已不足**。原文把 plan 归入「top-level Supervisor trusted matcher」，而该 matcher（`agent_runtime_supervisor_source_is_trusted`）如今同时是 Goal Contract 创建权限、根控制面工具授权与验收图完成门的判据，plan 一进入即被当作 Goal Contract 参与者。至少需要第四种语义「Goal Contract 参与者」，且它与 top-level trusted 的关系必须显式冻结，不能靠默认相等。此外 Goal Contract 的入口门只按 `agentId=project-supervisor` + root binding 判定，与 source predicate 无关，因此拆 matcher 本身解决不了它。完整处置见第 23.1 节待裁决项；该裁决可能反过来影响本节已冻结的 `agentId=project-supervisor`（方案 D）。
 
@@ -337,7 +326,6 @@ M1 不能把新 source 直接塞进一个被 autonomous 语义复用的总 match
 1. **Supervisor 根 run** 沿用现役 supervisor composition。做方案入口不需要专用 persona 稿：它的 Provider 不生成策划内容，只做委派、认领回执、代为提问与审批收束；这些能力现役 supervisor composition 已经具备。差异化只体现在 Prompt 的任务描述与工具面上，不体现在 composition 选择上。
 2. **策划子 Agent** 复用现役 `runtime` composition（委派/孤立子 Agent 通用模板）。其角色专属内容由 agentCatalog 条目的 brief 承载，而不是由 composition 承载——这与所有专业 Agent 的组织方式一致，见第 3.1 节。
 3. 因此本方案**不新增 Prompt Bundle 的编译期 source kind**。原 `SourceKind::SupervisorPlanChat` 不再需要。
-4. 现有 role overlay 仍只服务 autonomous 路径。策划链路的两个 run 都不伪装成 game-chat overlay，也不注入知识图谱 overlay。
 5. 策划子 Agent 的每一轮 continuation 都是**新 run、同 session**，其 Provider 请求的历史来自该 session 的既有对话，不需要也不应该由 Prompt 层去拼接「前几轮问答」。需要显式传递的只有用户的**答案**——它物理落在 Supervisor 会话文件而非子 Agent 会话文件，只能由 Supervisor 写进新一轮委派的 task 文本；该转述的保真依赖 Supervisor 侧 Provider，Runtime 只校验 `questionsSha256` / `answersSha256` 的哈希绑定，不校验转述语义（残留风险，见第 1.1 节「D11 新拓扑」第 3 条）。
 
 ### 4.3 两层工具面与两项协议控制函数
@@ -366,7 +354,7 @@ action 工具广告与执行双门都必须是 exact allowlist，MCP catalog 为
 
 `update_agent_plan` 与 `respond_to_user` 是 Runtime 协议控制函数，不计入上述清单，但仍受现有结构、轮次和终态门禁约束。
 
-明确禁止：通用写入、patch/delete、command、process、preview、canvas、asset generation、确认型副作用、`agent.delegate`、`agent.route_manifest`、isolated child、任务图调度和所有 MCP 工具。
+明确禁止：通用写入、patch/delete、command、process、preview、canvas、asset generation、确认型副作用、`agent.delegate`、isolated child、任务图调度和所有 MCP 工具。
 
 `user.input_request` **不在允许清单内**。委派子 Agent 天然带 `parent_agent_id`/`parent_run_id`，该调用被执行层 `validate_user_input_action_owner`（`apps/ai-game-creator-shell/src-tauri/src/user_input.rs:367-394`）兜底拒绝；M1A-2 同时让它从 planning 的函数目录消失，避免模型浪费轮次。广告层过滤、Provider parser 原始身份校验、batch/pending/recovery 再验证和执行层兜底必须并存，不能只测其中一层。
 
@@ -1516,15 +1504,12 @@ type PlanningBaselineInput =
 
 确定性收束与动态 Acceptance Graph 是两套证据体系，M2 不能混用。`design-director` 变成确定性 GDD 准入门后不再启动 LLM，因此**不产生任何 Provider 动作回执**；M0-3 的 Runtime 内部固定产物验证同样不产生 Provider 可见回执。而 Acceptance Graph 的 passed 节点必须引用当前根任务树中真实成功动作回执，`requiredEvidence` 只接受 `tool:<Runtime 工具名>` 且必须命中 Runtime 允许的持久证据工具集合（`agent_runtime_acceptance_evidence_tools()`，当前 18 项，既不含 Runtime 内部 owner 产物验证，也不含任何控制面或纯协调工具）。结论固定为：确定性 completed 投影与内部产物验证都不构成验收证据；涉及 GDD 落地的验收标准要么由根 Supervisor 用允许的证据工具自行取证，要么不写成 required 节点。不得为了让确定性节点“可验收”而把内部验证工具暴露成 Provider 可见工具——那会直接推翻 M0-3 已冻结的 owner 验证边界。
 
-## 17. M3 game-chat 只读复用
 
-game-chat 不强制先策划、不改变单主结构。项目存在有效 approved GDD 时，M3 可把 `title, oneLiner, coreLoop, mvpSystems 摘要, version, fingerprint` 作为只读上下文注入当前 `project-supervisor-game-chat` 根 run；没有时完全保持现状。
 
 注入前仍从不可变 GDD/receipt 验证，不能读取 index 或 Markdown 当信任源。唯一 `code-prototype` 主 Agent、按需美术 child 与 `audit-existing-first` 执行安全策略不变；后续用户要求与 GDD 冲突时由 Supervisor 明示差异，不自动产生新批准版本。
 
 2026-08-11 合入的动态目标验收图改变了本节的两条前提，M3 必须按新事实设计。
 
-第一，game-chat 根 Supervisor 现在有强制前置动作。根 Run 尚无 Goal Contract 时，本轮唯一动作必须是 `agent.goal_contract`；冻结之后才轮到 `agent.route_manifest`。`intentSummary` 的语义随之改变——它不再概括用户原话，而必须忠实概括**已冻结的 Goal Contract**。因此 M3 的 GDD 只读上下文必须在 Goal Contract 冻结**之前**就对根 Supervisor 可见，否则冻结下来的目标看不到已批准策划，后续整轮都建立在缺失前提上。
 
 第二，approved GDD 不得自动 seed Goal Contract。GDD 是一次历史批准事实，Goal Contract 是 Supervisor 对**当前这一轮用户意图**的理解；由 Runtime 用 GDD 字段直接物化合同，等于让旧策划静默冻结新一轮目标，并且绕过了「Agent 必须自行理解用户真正要做的事」这条约束。GDD 只能作为上下文进入理解过程，合同内容仍由 Supervisor 产出。
 
@@ -1682,18 +1667,12 @@ receipt 永远压过 stale pending：一旦该版本存在有效 receipt，pendi
 | 完整 16 任务 DAG | `code-prototype` | 对真实可玩入口执行 `game.static_smoke` | 代码原型写入与本人可玩静态自检 |
 | 完整 16 任务 DAG | `preview-readiness` | 以自己的 child run 对最终 project revision 执行 `game.static_smoke` | 正式最终静态验收 |
 | 完整 16 任务 DAG | `preview-playtest` | 独立执行 `preview.validate` | 正式浏览器试玩验收 |
-| game-chat 单主 | 根 `code-prototype` | source-bound 固定 smoke + desktop/mobile `preview.validate` | 对当前单主可玩 revision 负责 |
-| game-chat 动态美术 child | `art-director` / `art-asset-plan` | 只在 `assets/**` 范围交付，不得执行 command/preview | 只交付美术回执，无根最终验收权 |
 
 四个固定 owner 的 canonical 路径分别是 `memory/project.md + game/game_design.md`、`game/balance.json`、`assets/manifest.art.json`、`assets/manifest.audio.json`。同一映射必须同时驱动写入边界、完成检查与内部验证；验证要求有界读取、非空、JSON 可解析、无 incomplete marker，并相对根完成合同 baseline 已变化。内部验证不新增 Provider 可见 tool / commandId，不写 `staticSmokeVerifiedRevision`，不产生 smoke / preview trace；错误 source、delegated run、错误或终态 root、错误 parent/binding、跨 Agent/run 和非当前活跃根全部失败关闭，再次 mutation 必须使旧凭证失效。本阶段明确不扩到后置 `publish-package`；配置 Key 时的 UI 原型、透明图集、Canvas 登记和视觉验收仍是附加必需证据，不能被固定文件验证替代。
 
-Canvas 是条件外部能力，不是 M0-3 四个固定 owner 的通用前置：没有 Editor Key 时，固定 owner 仍按 canonical 文件由 Runtime 内部验证；有 Key 时，`art-director` 只获得 `canvas.asset_generate` 的规范图职责，Provider 广告与执行 policy 均拒绝 `project.verify`、`command.run_limited` 和 preview 工具。game-chat 临时 `art-asset-plan` 只有在当前根 `code-prototype -> agent-delegate`、durable delivery 与 Run Profile binding 全链一致时才可沿用 Canvas 路径，并且完成门只认本人 `canvas.asset_generate` 的通过凭证，不能借用 smoke 或 `project.verify`。完整 DAG 的 `code-prototype` 即使已经通过 `project.verify`，仍必须保留覆盖本人 `mutationRevision` 的 `staticSmokeVerifiedRevision`；后续 preview 更新 last verification tool 不删除这份 smoke 凭证。GUI/CLI 的试玩回执必须绑定确定性 `preview-playtest` child 的 agent/run/source/binding，game-chat 则继续绑定唯一主 `code-prototype`；上游代码节点、根 Supervisor 或旧 v1 回执均不能替代当前执行 owner，旧 v1 回执按缺失处理并要求重新试玩。
 
-正式任务 M0-4 的 PR 工作包 `M0B-1` 还必须让 `agent-delegate` 与 `agent-delegate-retry` 共用严格动态美术 lineage predicate；当前 retry source 不能绕过 `assets/**`。该修复不属于本文档 PR 的功能实现，但在 `M0B-2` 收敛 game-chat 前端投影前必须完成。
 
-2026-08-11 裁决进一步冻结：game-chat 动态美术 child 不允许使用通用 Agent Runtime retry。原 child 的 delivery 同时精确绑定父动作派生 delegationId 与 targetRunId；通用 retry 产生的新 run/new delegationId 没有合法 delivery，禁止通过换绑、续发、复制凭证或放宽 strict predicate 赋权。`retry_game_creator_agent_runtime_task_at` 必须在任何 successor durable 副作用前，以不要求 child 仍为 running 的结构身份识别该类终态 child，并返回稳定类型 `kind=game-chat-dynamic-art-retry-unsupported`，引导用户继续 game-chat 对话，由下一轮 main `code-prototype` 重新 `asset.list` 后按仍存在的缺口创建新的首次委派。委派去重以 parent run 为键；同一 main run 内每个缺口最多委派一次，终态失败或取消 delivery 不为同 run 开豁免，跨轮以新 parent run、新 delegationId、targetRunId 与 delivery 自然放行。遗留/伪造的 `agent-delegate-retry` 美术 run 只保留诊断性只读白名单，全部 mutation fail closed；现有 Tauri String error wire、其它 delegated retry、完整 DAG 和顶层 retry 不变。
 
-2026-08-12 裁决补充：manifest 不是 game-chat 轮次身份的权威源。`GameCreationAppManifest` / `GameCreationAppTaskState` 在 TS 与 Rust 双侧都不含 run/root/agent 身份字段，且 manifest 是项目级单例文件并跨轮复用同一份，因此任何任务状态都无法从数据本身归属到具体轮次。轮次结论的权威事实只有 Runtime lineage（`agentId + sessionId + runId + source + parentAgentId + parentRunId`）；manifest 只能作为 lineage 判定通过后的补充信号，不得单独裁定当前轮结论，也不得单独解锁阶段归档。阶段归档快照的全部写入点都必须校验被归档 root 仍是当前 root，终态会话同步中的异步捕获同样适用——该读取若在下一轮接管后才 resolve，会把掺入新轮活动的清单冻结成旧轮快照；跳过捕获不会饿死归档，因为开下一轮前的阻塞门在快照未冻结时直接失败要求重试。本阶段明确不为 manifest 或其投影新增 `statusRunId` / `statusSource` 等身份字段：补字段必须同时覆盖 `update_manifest_task_status_at` 与无秩序守卫的 `set_task_status` 两条写入路径，只改前者会让后者原样保留上一次写入的旧身份印记，制造“校验通过”的假象而比不校验更危险。
 
 2026-08-12 记录一处尚未裁决的不变量冲突。本节第 2 条（plan source 的工具广告与执行双门只有四项）与 2026-08-11 合入的动态目标验收图存在结构性冲突。现行工具面是 deny-list 模型，可信 root Supervisor 默认持有 `agent.goal_contract`；而 plan source 按 exact allowlist 设计，不持有该工具。由此卡在两道独立的门：入口门 `validate_root_goal_contract_control_plan_at` 在通用 tool-plan 解析路径上强制「合同不存在时本轮必须是唯一的 `agent.goal_contract` 动作、且无 plan/plan_update/response」，判据**既不看 source 也不看 Run Profile**；出口门 `goal_contract_acceptance_completion_blocker_at_locked` 在 root project-supervisor + 可信 source 且合同不存在时返回 `blocked`，卡住完成、finalization 与恢复。同一批判据还决定 Goal Contract 的创建权限和 `agent.goal_contract` / `agent.acceptance_update` 是否被剥离。四个处置方案与代价见第 23.1 节的待裁决项；在裁决冻结前，本节第 2 条按「设计意图」保留，不得据此认为现行代码已经满足它。
 
@@ -1733,7 +1712,6 @@ Canvas 是条件外部能力，不是 M0-3 四个固定 owner 的通用前置：
 | 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 | 首页“做方案”目录提交与 Enter 自动创建均为 `standard + project-supervisor-plan`；“做游戏/做素材”均保持 `autonomous-game-build`；项目页新建/打开不首次注入 planning；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 非回归；恢复不换稿 |
-| M3 integration | 有批准 GDD 的只读注入；无 GDD 零差异；不改变 game-chat 单主 lineage |
 
 关键强杀点逐项覆盖：
 
@@ -1756,7 +1734,6 @@ M0 文档 PR 本身最低验证：Markdown 结构与三张 Mermaid 图可解析
 | 主题 | 当前证据 | M1/M2 要点 |
 | --- | --- | --- |
 | **`project-planning` 身份登记（已落地）** | `apps/ai-game-creator-shell/src-tauri/prompts/runtime/manifest.json`（`agentCatalog.planning`）、`build_support/runtime_prompt_bundle.rs`、`src/agent/runtime_adapter.rs`、`src/agent/prompt.rs`、`src/agent/generation/pass_artifacts.rs`、`src/agent/runtime_driver/task_start.rs`、`src/agent/runtime_tools/task_ops.rs`、`src/agent/runtime_tools/delegation.rs` | **2026-08-13 已合入**。登记为与 `supervisor` 平级、不进 `groups` 的独立条目，`build.rs`／种子 DAG／`new_game_creation_app_seed_tasks()` 一行未动。同批修掉「非 supervisor 即专业组成员」二分假设的四个受害点：角色身份合成（blocking，不修则委派第一轮即硬失败）、内存路径解析、恢复枚举漏收、`task.create` 静默兜底成 Design 组；并把 `project-planning` 排除出 `agent.spawn_isolated` 的合法模板集。回归见 `project_planning_is_a_delegatable_identity_outside_the_seed_dag` |
-| Supervisor trusted source | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver.rs`（`AGENT_RUNTIME_SUPERVISOR_PLAN_SOURCE` + matcher） | **2026-08-13 `M1A-1` 已落地**：matcher 现为 gui/cli/game-chat/plan。`plan + autonomous-game-build` 由独立组合门拒绝（`kind=plan-autonomous-profile-unsupported`）。做方案链路正常参与 Goal Contract 协议（见第 23.1 节） |
 | trusted matcher 消费者 | 2026-08-12 复核为 10 个非测试文件、18 处调用：`commands.rs`(2)、`agent/runtime_actions/project_gates.rs`、`agent/runtime_protocol/acceptance_graph.rs`(2)、`agent/runtime_protocol/goal_contract.rs`(2)、`agent/runtime_protocol/run_configuration.rs`、`agent/runtime_protocol/steering.rs`、`agent/runtime_driver/lifecycle_control.rs`、`agent/runtime_driver/task_start.rs`(2)、`agent/runtime_actions/provider_request_builders.rs`、`agent/runtime_protocol/autonomous_completion.rs`(5) | 2026-08-10 记录的两个消费者已过期。`agent_runtime_supervisor_source_is_trusted` 现在同时是 run 启动门、steer 门、Goal Contract 创建权限、验收图完成门与根控制面工具授权的共同判据，**都不看 Run Profile**。M1 只拆 autonomous-only matcher 已不够。**2026-08-13 裁决：plan source 进该 matcher**；**`M1A-1` 已逐点复核并落地**：适用者保留 matcher、steer 独立否决（`kind=plan-root-steer-unsupported`）、autonomous 消费点已由 profile 挡住本包不改函数。复核表见 decision-log 2026-08-13 `M1A-1` 条。2026-08-13 复核调用数已增至 19 处，以当时源码为准 |
 | Run Profile | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_adapter.rs:48-75`、`apps/ai-game-creator-shell/src-tauri/src/main.rs:1243-1244` | 复用 `standard`，不新增 profile |
 | Supervisor start 校验 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/task_start.rs`、`apps/ai-game-creator-shell/src-tauri/src/commands.rs` | **`M1A-1` 已落地**：plan 必须 `standard`；`plan + autonomous-game-build` 拒绝 |
@@ -1783,14 +1760,10 @@ M0 文档 PR 本身最低验证：Markdown 结构与三张 Mermaid 图可解析
 | 16 任务 DAG | `server-rs/crates/shared-contracts/src/game_creation_app.rs:263-425` | 2026-08-12 复核 seed 仍是 16 个，M0/M1 不改拓扑；但固定 DAG 已不是完成语义的唯一来源，见下一行 |
 | standard 路径 owner 产物验证 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/autonomous_completion.rs:416-441` | 2026-08-12 复核：`autonomous_owner_artifact_validation_available_for_run_at` 四重绑死——owner agent 白名单、`profile == autonomous-game-build`、`source == agent-ready-task-scheduler`、**且要求 `parent_agent_id` 为 Project Supervisor**。standard ready-task 节点无 parent，第 436 行即不通过。做方案链路不能扩展该函数。**2026-08-13 按 D11 收窄结论**：策划 Agent 改为静态委派子 Agent 后，「产物是否交付」这件事已被静态委派内建的 `expectedArtifacts` 校验覆盖（存在性 + 非符号链接 + sha256），不需要再造一套；仍然缺的是**语义级**校验（JSON 可解析、非空、无 incomplete marker、相对 baseline 已变化），而 GDD 的内容正确性本就该由 `plan.submit_gdd` 的 strict schema 在落盘时把关，不由委派产物验证兜底。故本项范围收窄，不是整体另建 |
 | 问询与直投 | `apps/ai-game-creator-shell/src-tauri/src/user_input.rs:367-394,494-530,595-623,803-807`、`apps/ai-game-creator-shell/src/App.tsx` 的 `handleProjectSupervisorUserInput`、`apps/ai-game-creator-shell/src/project/conversation.rs:42` | 2026-08-12 复核：`validate_user_input_action_owner` 拒绝任何带 parent 的 run；会话文件按 `agentId` 分目录，消息归属完全由 pending owner 决定；一份 record 已经两路投影（会话消息 + observation）且有「observation 重算冲突」校验。直投只需让两路投影分别落到 Supervisor 与策划节点，**前端可直接复用现有 Supervisor 问答通道**。**2026-08-13 补记：本行「直投」是 D9/D10 旧机制记录，已被 D11 取代**（见第 1.1 节「D11 新拓扑」）——D11 不新造直投，改为复用 PR #165 已实现的 `AGC_NEEDS_USER_INPUT_V1` 终态信封 + Supervisor 中转链路；本行列出的 `validate_user_input_action_owner` 等机械证据本身仍成立，「前端复用现有问答通道」这一结论方向也不受影响，只是不再由「直投」这个已作废的机制名承载，本行未随批二重写，读者以第 1.1 节为准 |
-| Goal Contract / Acceptance Graph | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/goal_contract.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/acceptance_graph.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/tool_policy_snapshot.rs`（`agent_runtime_acceptance_evidence_tools`）、`apps/ai-game-creator-shell/src-tauri/prompts/runtime/supervisor/game-chat-routing.md` | 2026-08-11 合入。可信根 Supervisor 必须先冻结 Goal Contract 才能路由，验收图未确认则完成门 blocked；合同按 `.agent/runtime/goal-contracts/{rootAgent}/{rootRun}.json` 分 root run 存放并绑定 binding fingerprint 与 source SHA-256。M1 的待裁决项已于 **2026-08-13 全部关闭**（见第 23.1 节：plan source 进可信 matcher；验收图取自固定 Fast GDD 合格标准；plan 根 run 不允许 steer；checkpoint handoff 随 D10 作废）。M2 见第 16.1/16.2 节，M3 见第 17 节 |
 | design-director 现状 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/autonomous_completion.rs:70-85`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/task_start.rs:1480-1506` | mutation owner 清单不含 design-director，因此当前落入只读协调 Prompt；M2 才确定性化 |
 | scheduler delivery | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_tools/delivery.rs:171-185` | 下游不能依赖普通 durable delivery，必须读权威文件/ref |
 | owner 产物验证 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/autonomous_completion.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/project_gates.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_tools/file_ops.rs` | M0-3 / M0A-2 让四个 pre-code fixed owner 复用 canonical 路径映射，由 Runtime 内部验固定产物；Provider 不见验证工具，code / preview 节点继续真实 smoke |
 | approvedGddRef | 当前仓库无匹配实现 | M2 从 command 到 task/run/completion/context 全链新增 |
-| game-chat retry 边界 | `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_tools/file_ops.rs:7-39,120-134`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/lifecycle_control.rs:740-772,885-905` | M0-4 / 工作包 M0B-1 统一 delegate/retry assets-only lineage |
-| game-chat 前端投影 | `apps/ai-game-creator-shell/src/features/agent-runtime/gameChatRuntimeProjection.ts`、`src/features/agent-runtime/model.ts`、`src/features/project-workspace/SupervisorChatOnlyView.tsx`、`src/App.tsx` | M0-4 / 工作包 M0B-2 只认 root → 单主 `code-prototype` → 动态美术 child 的 source-aware lineage；进度、final-reply、可玩 revision、retry 控件与阶段归档共用该身份边界 |
-| game-chat manifest 权威性 | `packages/shared/src/contracts/gameCreationApp.ts`、`server-rs/crates/shared-contracts/src/game_creation_app.rs`、`apps/ai-game-creator-shell/src-tauri/src/project/manifest.rs`、`apps/ai-game-creator-shell/src/features/agent-runtime/gameChatRuntimeProjection.ts` | manifest 双侧均无 run/root 身份字段且跨轮复用单例文件；只能作为 lineage 判定通过后的补充信号，不得单独裁定轮次结论或解锁归档。M1 的 `.agent/planning/**` 权威事实不得走 manifest，D4 关于 `approvedGddRef` 是否进 manifest 的 M2 决策需一并考虑此约束 |
 
 ## 23. 分期门禁与完成定义
 
@@ -1809,7 +1782,6 @@ M0A-1 是 M1 详细设计与技术 spike 的输入，不是功能交付。M1 可
 
 2026-08-12 新增第二项 M1 合入前置决策：**plan source 与 Goal Contract 协议的关系**。（**2026-08-13 已裁决关闭**：`project-supervisor-plan` 进可信 matcher、正常参与 Goal Contract 协议，原阻塞理由随 D11 拓扑失效；详见本节下方「仍然保留的 M1 入口前置决策」中该条。以下段落保留作推导记录。）
 
-冲突的根源不是某处判据写错，而是两套工具模型不兼容。现行是 **deny-list 模型**：`agent_runtime_tool_policy_snapshot_at` 的 `allowed_tools` 直接等于全量 `agent_runtime_executable_tools()`，`agent.goal_contract` 天然在内，`standard` profile 在 `agent_runtime_tool_policy_snapshot_for_run_at` 里更是提前返回、不做任何裁剪；`provider_request_builders.rs` 只对 `!root_control_authority && goal_contract_participant` 的后代做剔除。因此现役可信 root Supervisor（gui / cli / game-chat）**默认就持有**这个工具，两道门对它们是「照着做」。而 M1 是第一个 **allow-list 模型**的 source（第 4.3 节 exact allowlist），Goal Contract 协议隐含的「root Supervisor 一定持有 `agent.goal_contract`」前提对它不成立。
 
 具体卡在两道**互相独立**的门，判据不同，必须分别处置：
 
@@ -1825,7 +1797,6 @@ M0A-1 是 M1 详细设计与技术 spike 的输入，不是功能交付。M1 可
 | C. plan 接纳 Goal Contract 协议 | 把 `agent.goal_contract` 纳入 plan 工具面（等价于放弃 allow-list、改用现行 deny-list 模型） | **只解除入口门，出口门在验收阶段照卡，且更难救。**`validate_goal_contract_acceptance_graph` 强制合同至少一个验收节点、至少一个 `required` 节点、每个 required 节点至少一项 `requiredEvidence`，且 evidence 必须命中 `agent_runtime_acceptance_evidence_tools()` 的 18 项；出口门再要求每个 required 节点在当前 project revision 下有真实成功动作回执。这 18 项全是项目读写/命令/预览/生成类工具，策划 Agent 按第 1 节目标 2 一项都不该有，`.agent/planning/**` 又由 Runtime 写、不产生 Agent 回执，因此合同必然带一个永不 `passed` 的节点。要救须把 plan 工具加进 evidence 集合并追加 `agent.acceptance_update`（独占一轮，与第 12 节 submit sole-action 和第 13 节决策卡流程冲突），且上游已明令禁止「用无关成功动作自证」。此外与第 4.3 节 exact allowlist、第 19 节第 2 条、第 24 节「plan source 无……」直接冲突，GDD 与 Goal Contract 语义大面积重叠。**判定为不可行，保留在表内仅作已排除记录** |
 | D. plan root 改用独立 `agentId` | 不再复用 `project-supervisor` | 入口门、创建权限与出口门三处**同时**自动不适用（三者都要求 `agent_id == project-supervisor`），是唯一一次性解耦的方案；但直接推翻第 4.1 节已冻结的 `agentId=project-supervisor`，牵动顶层通道假设、前端 hydrate、run lineage 与「每项目最多一个 active plan run」的判定口径，须先重开第 4.1 节 |
 
-「改用 deny-list」不是独立的第五方案。deny-list 的作用只是让 plan 默认持有 `agent.goal_contract`，即方案 C，代价见上；而且它在本场景还额外不成立——`agent_runtime_effective_tool_policy_at` 按 `agent_id` 取策略，plan run 与完整构建、game-chat Supervisor 共用 `project-supervisor` 这一个 `agent_id`，per-agent deny-list 区分不了它们，仍须写 source-aware 门。deny-list 与 allow-list 的实质差别只剩失败方向：往 `agent_runtime_executable_tools()` 增加工具时，deny-list 让策划 Agent 静默获得新能力（2026-08-11 的 `agent.goal_contract` / `agent.acceptance_update` 正是这样进入全部现役 Agent 的），allow-list 默认不获得。对一个以「没有构建能力」为安全前提的 source，只能取后者。
 
 因此真正的分岔不是 allow-list 与 deny-list，而是**策划 run 是否应当是一个 root `project-supervisor` run**：三处判据的唯一共同项是 `agent_id == GAME_CREATOR_PROJECT_SUPERVISOR_AGENT_ID`，方案 D 一次性解耦全部三处且不需要在他人协议里挖豁免，方案 B 需要四处豁免并随消费者增加持续维护。
 
@@ -1871,7 +1842,6 @@ D9 之后，root 是未变的 Project Supervisor，它在 `standard` 下天然
 
   *产品侧替代路径*：用户中途要改方向，走既有的两条——本轮问询里回答/自由填写来纠偏；或在 GDD 审批卡上 `revise` / `reject`。都不行时放弃本轮、重开一条 plan lineage（第 4.1 节的 `PLAN_ACTIVE_RUN_EXISTS` 约束保证同一时刻只有一条非终态 lineage）。
 
-  *连带收益*：本裁决同时消解了原条目里「父 Supervisor 被 steer 时下游委派子 Agent 如何收束」这个问题——plan 根 run 不可被 steer，该场景不存在。game-chat 路径的同类问题不受影响，仍按 decision-log 2026-08-11 条的既有结论处理。
 - ~~**`project-planning` 的编译期 agentCatalog 登记方式与 `build.rs` 一致性校验**~~——**2026-08-13 机制与 M1A 基础代码已落地**（见第 3.1 节）：`project-planning` 在 `agentCatalog` 下登记为与 `supervisor` 平级、不进 `groups` 数组的独立条目，`specialist_nodes` 只读 `manifest.agent_catalog.groups[].roles[]`（`build_support/runtime_prompt_bundle.rs:387-398`），因此 `build.rs` 的 `validate_seed_task_catalog`（`apps/ai-game-creator-shell/src-tauri/build.rs:23-46`）、16 任务种子 DAG、`new_game_creation_app_seed_tasks()` 均不需要改动。Prompt Bundle 已登记并注入 planning role brief，`prompt.rs` 已补齐 `project-planning` 角色 overlay；本段只代表身份/brief 基础可执行，不代表 `plan.submit_gdd` 或 GDD 存储/审批闭环已完成。
 
 ### 23.2 M0-3：统一 owner 产物验证与可玩验收边界（PR 工作包 `M0A-2`）
@@ -1880,9 +1850,7 @@ D9 之后，root 是未变的 Project Supervisor，它在 `standard` 下天然
 
 ### 23.3 M0-4（PR 工作包 `M0B-1` / `M0B-2`）
 
-`M0B-1` 先封闭 game-chat 动态美术 delegate/retry 的安全边界：首次 `agent-delegate` 继续按严格 delivery/route/Canvas lineage 只写 `assets/**`；该类 child 的通用 retry 在入队前返回 `kind=game-chat-dynamic-art-retry-unsupported`，遗留或伪造的 `agent-delegate-retry` 只读且全部 mutation 失败关闭。恢复只走跨轮：用户继续 game-chat 对话，由下一轮 main `code-prototype` 重新审计并按仍存在的缺口创建新的首次委派；同一 main run 对同一 target 的第二次委派继续拒绝，新一轮以新 parent run、新 delegationId、targetRunId 与 delivery 全链恢复。`M0B-2` 再以 source-aware lineage 修复单主进度、最终回复、可玩 revision 与归档投影。M0-4 不阻塞 M1 策划闭环开工，但阻塞 M3 game-chat 接入和“M0 全部完成”。M0-1～M0-4 全部合入并通过各自门禁后，才能标记“M0 全部完成”。
 
-2026-08-11 的 M0B-2 落地固定为 presentation-only：新增纯投影模块，结构身份严格限定为 `project-supervisor-game-chat` root → `agent-ready-task-scheduler` 的唯一 `code-prototype` main → 该 main 下 `agent-delegate | agent-delegate-retry` 的 `art-director | art-asset-plan`；retry source 只作遗留诊断展示，不恢复通用 retry 控件。game-chat 进度只显示主阶段 `0/1`、`1/1`、失败或待核对；final-reply 除角色 allowlist 外还必须匹配精确 run 谱系；可玩 revision 只由当前 main 成功 smoke 后的结构化双视口试玩通过建立，同 revision 后续失败优先；阶段记录须等待 root、main、动态 child 和 manifest 主任务终态且无 reconciliation，并使用 root-scoped Runtime 快照与稳定 root-run message ID 幂等归档。该工作包不修改后端 DTO/schema/delivery/route，不迁移历史 manifest，也不实现 M1～M3。
 
 2026-08-12 收敛 M0B-2 遗留的唯一挂起项——manifest 无 root/run 绑定，无法安全判定跨轮残留状态的归属。处置为三项：确立“manifest 非轮次身份权威源”的不变量（见 §19）；补齐阶段归档中终态会话同步异步捕获缺失的 root 身份校验，使四处快照写入点身份口径一致；以回归钉住“当前 main 未终态时 manifest 不参与裁定”这条既有但零覆盖的边界。明确保留并记录的残余风险是：当前 main 到达 Runtime 终态且非 failed/cancelled 后 manifest 被逐字采信，若本轮 `manifestInvalidated` 尚未落地，跨轮残留的 failed 仍可能被显示为本轮结论；该窗口实际宽度未量化，三条候选机制（时间戳新鲜度门控、root-scoped 永久缓存、manifest 补身份字段）经审查均不可安全落地——分别因跨端时间戳单位错配导致门控恒真、缓存语义与后端“每次重新校验”哲学相悖、以及漏掉第二条 status 写入路径——故本阶段只记录不实现。回归用例中该残余风险的断言即裁决锚点，改动它意味着重新裁决。重新裁决触发条件见 decision-log 2026-08-12 条。该挂起项至此已处置，不再阻塞 M0-4 收口。
 
@@ -1914,7 +1882,6 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 
 - 分类判据（唯一权威）：`parent.structured_result.contract_status == NeedsUserInput` ⟺ 该跳是澄清 continuation；否则是质量返工。
 - 传播：根节点 `(0, 0)`；澄清跳 `round += 1` 且 **`depth` 不变**；返工跳 `depth += 1` 且 **`round` 重置为 0**。
-- 上限：`repair_depth` 维持 1 不放松；`clarification_round` 按 source 区分，game-chat source 取 1、其它 source（含 `project-planning` 委派链）取 3。
 - 单链总跳数上界 `1 + 2 × 3 = 7` 跳、8 条 delivery 记录。**注意是 7 不是 6**——连接两层的返工跳本身也算一跳。
 
 **为什么不加持久字段**：给 `StaticDelegateDeliveryRecord` 新增 `repair_depth` 并用 `#[serde(default)]` 兜底，会让磁盘上已有的返工记录读出 `0`，深度门失效，「返工的返工」漏洞原样复活——方向是 fail-open，不可接受。链上推断对历史记录是**精确**而非仅保守：PR #165 之前不存在 `NeedsUserInput`，旧记录天然被正确分类为「非澄清」。
@@ -2031,7 +1998,6 @@ M0 完成不表示完整策划闭环已经上线。`M1A-1`～`M1A-4`、`M1B-1`
 | `M1C-0` | 新增 `StaticDelegateContractStatus::UserRevisionRequested` 与分类分支 | `M1A-1` | **已落地**：无审批写入方、是惰性路径；用户修订跳不增 `repair_depth` 也不重置 `clarification_round`，连续修订可通过；做游戏链路返工仍在 `depth=1` 被拒；原有三种状态与 `UserRevisionRequested` 的已知行为保持不变，未知 durable status 的前向兼容由已完成的 `M1C-0b` 显式承接，不在本包静默降级或改变 |
 | `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` | **实现与本包门禁已完成并已快进合回 `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_*` **13 passed / 0 failed**（M1C-2c 语义回归另见本包），另有 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 路径不在本包。第 4 轮信封在正常路径不可达：`agent.delegate` 已在工具边界按血缘上限硬拒并返回 failed observation；coordinator 的超三轮 reconciliation 仅用于损坏血缘纵深防御。审批 UI、hydrate、构建准入和下游完整构建不在本包范围 |
 | `M1C-2c` | 决策卡 A/B 语义（第 23.9 节，2026-08-18 实现完成并合回）：选项 → 台账映射改为 A/B 均 `confirmed/user_option`、信封 label 形状校验、planning role brief 与 Supervisor playbook/final-reply 文案（B 必须是真实岔路、第 3 项恒定且 description 须给出可执行验证方式、改口转述规则、提问纪律） | `M1C-2b` | **实现与门禁完成，已由 `6e4bd9703` 合回 `feat/five_min_design`**：Runtime 已实现 A/B/固定第三项校验、B 不再生成 `default_pending`、`answerSummary` 逐字保真；非法 C/缺项 fail-closed，A/B/自由填写回归已通过。`planning_clarification_*` 13、`project_planning` prompt 5、`planning_submit` 定向回归、prompt bundle、格式、编码、diff、offline all-targets 均通过；不含 M1D-1 前端、hydrate、构建准入或下游完整构建 |
 | `M1D-1` | 前端 hydrate 与 GDD 审批卡；决策卡按第 23.9 节实现（label 动态渲染、默认焦点 A、Other 槽不变） | `M1C-2b` | **已完成并合入 `feat/five_min_design`（落地 `0052a80da`，其后 ESLint 修正 `5b11a0530`）**：新增严格 `{projectPath}` hydrate command、`plan-gdd-state-view.v1` Rust read model、审批卡与独立 GDD 正文详情弹层；页面只消费 hydrate，决定 responseId 按审批请求/动作复用，`recoveryPending` 仅提供恢复重试；审批前置 pending 与错绑 session 继续 fail-closed。 |