# 踩坑与排障记录 > 当前口径：本文件保留可复用的排障经验；历史条目的旧路由、旧版本和已删除文档仅作根因背景，不得据此恢复退役入口。当前命令、路由和 schema 以代码与 `docs/README.md` 为准。 ## 2026-09-02 Tauri 事件桥在浏览器预览中必须 fail-safe - **现象**：Vitest/jsdom 挂载 AGC 客户端时，错误报告通知调用 `@tauri-apps/api/event.listen`，因缺少 `window.__TAURI_INTERNALS__` 产生未处理拒绝；测试断言虽通过，CI 仍以 unhandled errors 失败。 - **原因**：错误报告订阅是非阻塞唤醒通道，不能假定所有渲染环境都已初始化 Tauri IPC；模块级 `listen` 在 API 调用前就会访问 `transformCallback`，仅在调用方包一层 `.then` 无法消除该环境差异。 - **处理**：订阅桥先复用 `window.__TAURI__.event.listen`（含 globalTauri/native shim），其次仅在 `__TAURI_INTERNALS__` 存在时调用模块 API；浏览器预览或订阅失败统一返回 no-op，并在消费层收口 rejection。错误快照读取、焦点和可见性刷新仍是权威路径。 - **验证**：`errorReporting.test.ts` 覆盖无 Tauri 环境无未处理拒绝；`appSurface.test.ts` 全部 385 条用例通过且无 Vitest unhandled errors。 ## 2026-08-27 Provider 成功 handoff 失败时需要保留本地私有原始响应 - **现象**：Provider 已返回响应，但 tool-plan handoff 因绝对路径或其它内容安全校验失败，Runtime 只留下 `failureKind`、哈希和被压平的 JSON pointer；排障时无法确认实际工具名和完整 arguments。 - **处理**：项目 `.agent`、Agent DB 和公共 event 继续只写安全摘要；额外在应用私有配置目录的 `diagnostics/provider-reconciliation//.json` 保存本次响应、tool calls 和校验错误，供本机人工排障。该文件不参与恢复/重试、不复制到项目、不进入 Git，单文件限制 1 MiB，写入失败不改变 reconciliation 语义。 - **排查顺序**：先读 Runtime 状态里的 `localDiagnostic` 相对引用，再在应用私有目录读取诊断，核对 requestId、requestSlot、tool name 和失败 pointer；不要为了取得原文而放宽 handoff 的安全门。 ## 2026-08-27 阶段判定不能在持锁的 Provider builder 中再次获取项目锁 - **现象**：GDD 修订取证阶段新增后，重新启动策划时前两步表面成功，但父 Supervisor 在收到 `project-planning` 回执、生成下一轮工具计划时失败：`项目正在被其他写操作占用：$PROJECT_ROOT\\.agent\\project.lock`。 - **原因**：`provider_tool_plan` 在构建请求前已持有 `.agent/project.lock`；`plan_root_supervisor_stage_at` 又调用会自行取锁的 Acceptance Evidence 包装入口。同一进程的文件锁不可重入，持锁调用被误判为外部竞争，等待约 10 秒后失败。问题与 Provider、代理端口或 GDD 内容无关。 - **处理**：所有需要一致快照的状态读取保留在项目锁内；阶段判定提供明确的 `*_locked` 内部入口，外层入口仅供未持锁调用方取得一次锁。Provider builder 显式接收并校验当前锁后调用 locked 阶段判定，不引入可重入锁，也不移除 Acceptance Evidence 门禁。 - **排查顺序**：先看失败 Run 的事件顺序是否为 `delegate receipt ready → 生成工具计划 → 阶段判定项目锁失败`，再检查调用方是否已持有 Provider plan project lock；不要因为错误文案包含“其他写操作”就先扩大锁等待或放宽 Provider usage。 - **验证**：`cargo check`、`cargo fmt --check`、planning submit 68 passed、Provider request builder 17 passed；阶段测试同时覆盖未持锁包装入口和持锁 locked 入口。 ## 2026-08-26 GDD 新版本提交后不能沿用“已有委派”工具面 - **现象**：`plan_root_supervisor_stage_at` 只按是否存在 delivery 判定 `Delegated`。用户修订产生的新 GDD 仍未完成当前根 Run 的 `file.read → agent.acceptance_update` 取证时，模型会看到 `agent.delegate`，可能重复派发同一条策划链。 - **原因**：自然语言 playbook 已规定“证据不足先取证、用户修改后才返工”，但阶段工具白名单没有把这条 durable 状态固化。 - **处理**：阶段判定复用现有 acceptance gate 的 GDD/session/delivery/graph identity 检查，增加无副作用的 `AwaitingAcceptanceEvidence` 阶段；`PLAN_PROVIDER_USAGE_DEFERRED` 保持 fail-closed，不通过放宽 Provider 使用量门禁解决。 - **排查顺序**：先看最新 `gdd.vN.json`、`session.latestSubmittedRef`、delivery 是否 `ClaimedByParent`，再看 Acceptance Graph 是否 `NeedsEvidence`；若仍可见 `agent.delegate`，优先检查 plan root 阶段快照，而不是修改 acceptance gate 或 Provider 门禁。 ## 2026-08-15 把校验往链路前面挪，改的不是严格程度而是作用域 - 现象：CI 全量 5 条失败，看上去毫不相干（两条 Goal 续跑停在 `needs-reconciliation`、一条交接用例断言错误文案、一条恢复用例把不可读 state 的错误抛了出来、一条 Linux-only 用例错误码对不上），实际只有 3 个根因，且三者是**同一个形状**：新增或既有的检查被放在了链路更靠前的位置，于是它的语义作用域被悄悄放大或提前，而不是「变严」。 - 形状一（判据上提 → 作用域从同 loop 变成跨 loop）：`tool_plan_handoff/identity_order_validation.rs` 的 `same_tool_plan_repair_chain` 含 steer cursor、goal revision/快照与 planning session binding 这些**本轮量**，只在同 loop 的 repair 之间才必须逐位相等。`M1B-2`（`27c3eb847`）把它提到 `loop_iteration` 分支之外后，`loop-N → loop-N+1` 的正常续跑必然被判成「身份冲突」，整个 run 进 `needs-reconciliation`。**同一次上提还把分支内那句同名检查变成了死代码**——编译器不报，测试拿到的是外层文案，于是表现成「断言的错误文案不对」这种看起来无关的症状。模块内本来就有反例可对照：`ledger.rs` 的 `is_later_repair_identity` 一直把这条判据显式限定在 `current_loop == candidate_loop`。 - 形状二（探测器的前置条件变成整条链路的 gate）：`recovery_scan.rs` 的 `missing_plan_submit_anchor_candidate_at` 用 `?` 强读 runtime state，而它被挂在每个 Agent resume 循环的**最前面**。真正负责处置「state 不可读」的是它下游的 `resume_game_creator_agent_finalization_at`——那里会从 task record 重建并 fail-closed 到 `needs-reconciliation`。前面这一 `?` 把整轮 resume 打断，**恰好绕过了专门为这种情况写的兜底**。这个探测器甚至不适用于出事的 Agent（它只认 planning agent + `agent-delegate`），读失败纯属前置成本。 - 形状三（通用解析器排在专用校验之前，错误码被压平）：`planning_storage.rs` 把 `resolve_local_project_path` 的失败整体映射成 `PLAN_INVALID_PATH`，但该解析器会先于 planning 自己的校验逐组件拒绝符号链接。于是「不可信路径」被报成「非法路径」，与同模块 `ensure_planning_parent`、`verify_regular_planning_file` 的分类自相矛盾。这条自 `M1B-1`（`f453c2ca2`）写下就没绿过——用例是 `#[cfg(unix)]`，Windows 上编译都不参与（`0 tests`），只有 Linux CI 能看见。 - 处理：形状一改回 loop 分支内，并补一条正向回归（跨 loop 且 steer cursor / goal revision 已前进必须被接受），把边界钉住而不是只钉拒绝；跨 loop 身份由 `same_durable_tool_plan_run` 守，binding 漂移另有 `provider_retry.rs` 的 per-request 判据兜底，去掉上提不留缺口。形状二把强读改成「读不到就 `Ok(None)`」，让处置权回到下游兜底。形状三新增 `resolve_planning_path`，先用模块自己的 `planning_metadata_is_link_or_reparse` 判链接/重解析点并返回 `PLAN_UNTRUSTED_PATH`，再交给通用解析器；模块内 13 处解析全部改走它，分类统一。 - 定位手法（比二分快得多）：失败用例的临时项目目录在 panic 后不会被清理（`fs::remove_dir_all` 写在用例末尾），直接读里面的 `.agent/agent.db` 与 `.agent/runtime/agents/*.json`。本次两条 Goal 失败在 db 里留下 `failureKind=tool-plan-integrity`、`errorChars=55`、`errorSha256=0750f609…`，把候选错误文案逐条算 SHA-256 一比即命中，`requestSlot` 从 `loop-1-repair-0` 到 `loop-2-repair-0` 直接指出是跨 loop 那一跳。**错误只留指纹不留原文时，指纹就是可检索的**。 - 验证：4 条可在 Windows 复现的用例全部转绿（含新增回归）；Linux-only 用例在 WSL 的独立 Linux clone 中验证。Windows worktree 的 `.git` 文件可能记录 Windows 路径，WSL 内应从可访问的主仓库 clone 或真实路径 fetch，不要直接复用不可解析的 worktree 元数据。 - 关联：`apps/ai-game-creator-shell/src-tauri/src/tool_plan_handoff/identity_order_validation.rs`、`.../agent/runtime_driver/recovery_scan.rs`、`.../agent/runtime_protocol/planning_storage.rs`；decision-log 同日条。 ## 2026-08-15 `#[cfg(windows)]` 里的代码不参与 Linux CI 编译，CI 绿不代表能构建 - 现象：把 master（`9f5c84ee7`）合进 `feat/five_min_design` 后，`cargo check --all-targets` 在 Windows 上直接 `error[E0658]: use of unstable library feature 'windows_by_handle'`，位置是 `apps/ai-game-creator-shell/src-tauri/src/project/manifest.rs` 的 `metadata.number_of_links()`。该文件与 `origin/master` **逐字节相同**，即 master 自身在 Windows 上就构建不过。 - 原因：`std::os::windows::fs::MetadataExt::number_of_links` 至今未稳定（rust-lang#63010），而 `rust-toolchain.toml` 锁的是 stable `1.96.0`。引入它的提交是 `578f8019f`（优化 AGC 项目入口并识别 Godot 工作区），其中 unix 分支用 `MetadataExt::nlink()`（已稳定）、windows 分支用了未稳定的对应物。**Linux CI 上 `#[cfg(windows)]` 整块不参与编译，所以 CI 全绿。** - 更普遍的形状：只要一段代码只在某个 `#[cfg(target_os)]` 下编译，它就完全绕过了其它平台的 CI——不只是 unstable feature，还包括类型错误、借用错误、缺失 import。跨平台分支是「双写」，两侧都得有人真的编译过。 - 处理：本仓库对「文件是不是无硬链接普通文件」统一自行声明 `ByHandleFileInformation` 并调用 `GetFileInformationByHandle`，见 `runner/endpoint.rs`、`tool_plan_handoff/storage_windows.rs`、`project/agent_db.rs`、`git_inspect.rs`、`image_inspect.rs`、`agent/generation/canvas_generation.rs`。`manifest.rs` 当前已采用同一实现，并保留 fail-closed 语义：无法取得句柄信息或确认存在硬链接时均拒绝，同时拒绝 directory / reparse point。 - 验证：改后 `cargo check --offline --all-targets` 通过、`cargo fmt --check` 通过、`project::manifest` 与 godot 相关定向测试 65 passed / 0 failed。判断「是不是本次合并引入」的通用手法：`git diff origin/master -- ` 为空即说明该文件就是 master 原样，问题不在合并。 - 关联：`apps/ai-game-creator-shell/src-tauri/src/project/manifest.rs`；`rust-toolchain.toml`；master 提交 `578f8019f`。 ## 2026-08-14 planning sidecar 必须区分“可读”与“可写”，canonical bytes 也不等于 typed 指纹 - 现象：如果为了保护 Runtime-owned 事实，直接把 `.agent/planning/**` 加进现有 private-control **读**门，planning 子 Agent 的 `file.read` / `file.list` 会一起失败；反过来若只依赖工具面约束，通用 `file.write`、`file.patch`、`file.delete`、`project.patchset` 或 checkpoint restore 仍可能覆盖 GDD/session。另一个常见误判是把“能反序列化且语义相同”的 JSON 当成已提交文件，导致尾换行、字段重排或重复键绕过不可变事实的字节身份。 - 原因：`.agent/planning/**` 是 Runtime 专用 durable sidecar，但 planning Agent 需要只读观察；`game/fast_gdd.md` 又是 Runtime renderer 的人读投影，二者都不能复用“读写一体”的旧 private path 判据。存储 bytes 与 typed fingerprint 是两个门：前者约束磁盘 canonical serialization（Rust struct 字段顺序、compact UTF-8、无 BOM/尾空白、无重复键），后者约束 domain-separated 业务 payload 的完整性；只过其中一门都不能视为 authoritative。 - 处理：保持现有 private-control **读**门不含 planning，新增只挡写 predicate；所有通用 mutation 与 restore 路径在推进 revision 前先拒绝 `.agent/planning/**` / `game/fast_gdd.md`，专用 writer 再校验 `project-planning + agent-delegate + standard + project-supervisor` 身份。GDD/index 等不可变文件走项目锁、同目录临时文件、`sync_all`、回读与 no-replace 发布；相同 canonical bytes 才是 replay，任何其它内容都是 identity conflict。session 只保留一个 `.session.json.previous`，primary 损坏时 fail closed，不得拿 previous 猜测新旧。 - 验证：先用 planning Agent 的只读 action 验证 sidecar 可列出/读取，再逐项证明 `file.write`、`file.patch`、`file.delete`、`project.patchset` 与 checkpoint restore 均拒绝；storage 测试应覆盖 duplicate key、BOM/尾空白、字段顺序、symlink/目录/硬链接、create-only replay/conflict、session 缺 primary 提升、primary 损坏和合法 successor。第 9.1 节 golden vector 当前为 3857 bytes / `sha256-serde-json-v2:a59856de7ef134cf2f49c4dedd2ba10ae4ab2340a9634d402eb792b6ee5458f0`。 - 关联：`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/planning_storage.rs`、`apps/ai-game-creator-shell/src-tauri/src/project/filesystem.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_tools/file_ops.rs`、`apps/ai-game-creator-shell/src-tauri/src/patchset.rs`、`docs/technical/【技术方案】立项策划Agent（Fast GDD）-2026-08-10.md` 第 8.3～10.2 节。 ## 2026-08-12 在 autonomous-game-build 下试图向用户提问，会让整条工作流永久瘫痪 - 现象：给自主构建链路加「问用户一句」的需求时，最自然的两个想法——让 DAG 节点自己问、或让父 Supervisor 代问——**都不成立**，而且第二个的失败方式是灾难性的。 - 拦截一（节点自己问）：`apps/ai-game-creator-shell/src-tauri/src/user_input.rs:367-394` 的 `validate_user_input_action_owner` 三路 OR 拒绝任何带 `parent_agent_id / parent_run_id / delegation_id` 的 run。autonomous 的 ready-task 调度器在 `apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/task_start.rs:905-907` **显式**给每个 DAG 子节点写 parent，因此必然命中。 - 拦截二（父代问）：`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/tool_policy_snapshot.rs:198-215` 只要 `run_profile == autonomous-game-build` 就把 `user.input_request` 从 `auto_tools` / `confirm_tools` 移除并推进 `denied_tools`；`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/main_loop.rs:2604-2616` 在执行层再拒一次。**两处判据都只看 profile、不看 `agent_id`，所以 root Supervisor 自己也在禁令内**——「父能问、子不能问」这个中转赖以成立的不对称，在 autonomous 下根本不存在。 - 真正的坑（后果放大）：硬闯不是「这次失败」，而是**整条流水线停摆**。执行层拒绝会走 `mark_game_creator_agent_runtime_needs_reconciliation_at`，`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/pending_execution.rs:1157` 把 `runtime.status` 直接写成 `failed`；此后每次调度 ready task 必经的 `autonomous_game_build_root_task_is_active`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/task_start.rs:685-693`）只认 `pending | running | waiting-for-confirmation | waiting-for-user-input`，`failed` 不在其中，于是报「父 Run 已不再活跃」，**剩余节点一个都起不来，须人工核对才能恢复**。同一类故障本仓库已踩过一次，见下方「自主模式不能保留任何 RequiresConfirmation 漏口」条。 - 也别想着换 profile 绕开：`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/run_configuration.rs:264-266` 明文「子 Run 不能切换父 Run 的 Run Profile」，且 profile 是 run 绑定时 CAS 锁死的终身属性。 - 处理：需要与用户往返的链路必须整体跑在 `standard` profile 下。`standard` 的 ready-task 调度器（`task_start.rs:566-580`，走 `..._with_source_at` 而非 `..._with_link_at`）不写 parent，节点是自己的 root run，上述拦截一并不适用。这是 2026-08-12 立项策划 D9 改用「Supervisor + standard 下游工作流节点」的直接原因，见 decision-log 同日条。 - 附带结论：`autonomous_owner_artifact_validation_available_for_run_at`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/autonomous_completion.rs:416-441`）同样四重绑死 owner 白名单、profile、source，且**要求 `parent_agent_id` 为 Project Supervisor**——standard 节点无 parent，第 436 行即不通过。想给 standard 路径加 owner 产物验证的人不要试图扩展它，必须另建。 ## 2026-08-12 往 trusted supervisor source 里加新 source，等于同时授予 Goal Contract 参与者身份 - 现象：`agent_runtime_supervisor_source_is_trusted`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver.rs:113`）读起来像一个「谁能启动 Project Supervisor」的入口白名单，实际早已是多条互不相干的授权判据的共同开关。2026-08-11 合入动态目标验收图后，它的非测试消费者从 2 个文件涨到 10 个文件 18 处调用：run 启动（`commands.rs:698`）、steer（`commands.rs:876`、`steering.rs:763`）、Goal Contract 创建权限（`goal_contract.rs:496`）、根控制面工具是否被剥离（`provider_request_builders.rs:134` 的 `root_control_authority`）、验收图完成门（`acceptance_graph.rs:595`）、run configuration、lifecycle_control、task_start、project_gates、autonomous_completion。 - 陷阱：这些判据**全都不看 Run Profile**。`goal_contract_acceptance_completion_blocker_at_locked`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_protocol/acceptance_graph.rs:568-611`）只要求「`agent_id` 是 `project-supervisor` + binding 是无 parent 的 root + source 可信」，未冻结 Goal Contract 就返回 `blocked`，并被 `main_loop.rs:213`、`main_loop.rs:1803`、`finalization.rs:398` 消费。因此给一个**用途完全不同**的新 source（例如立项策划的 plan chat）加进白名单，会让它的根 Run 立刻背上「必须先调 `agent.goal_contract`」的义务；如果该 source 的工具面按 exact allowlist 设计、不含这个工具，根 Run 就永远无法完成——而且症状是 run 卡在完成门，不是启动失败，排查方向容易跑偏。 - 更坏的一半：把新 source 排除出白名单**并不能**脱身。同一协议还有一道入口门 `validate_root_goal_contract_control_plan_at`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/autonomous_policy.rs:171`），由 `provider_tool_plan.rs:434` 在通用 tool-plan 解析路径上无条件调用，判据只有「`agent_id` 是 `project-supervisor` + binding 的 root 是自己 + 存在 run profile binding」——**连 source 都不看**。合同不存在时它强制本轮恰好一个 `agent.goal_contract` 动作且 `plan_update`/legacy plan/`response` 全为空，于是「第一轮先问用户一个问题」或「第一轮先回复」的 Agent 会被直接判协议错误。三处判据里只有 `agent_id == GAME_CREATOR_PROJECT_SUPERVISOR_AGENT_ID` 是共同项，改 `agent_id` 是唯一能一次性解耦的做法。 - 处理：新增 trusted source 前，先逐个确认这些调用对新 source 的语义是否成立，尤其是 Goal Contract 创建、验收图完成门与 steer 三处，再单独确认不看 source 的入口门；需要区分时，应当拆出「可信入口」与「Goal Contract 参与者」两条判据，而不是继续复用同一个函数。立项策划已按第 23.1 节裁决进 matcher 并参与 Goal Contract；steer 用独立于 matcher 的显式否决（`reject_supervisor_plan_root_steer`），不得用「不进 matcher」实现。复核结论见 decision-log 2026-08-13 `M1A-1` 条。 - 双向提问：调用点**既是判据又是构造器**时，只问「会不会误得不该有的语义」不够，还要问「落到通用兜底会不会丢掉该有的语义」。`resolve_game_creator_agent_runtime_retry_configuration_at` 因此在 `M1A-1` 漏出，由 `M1A-3` 补强判据与保源；拒绝继续用弱判据，授予必须用强判据。 - 相关：`requiredEvidence` 只接受 `tool:` 且必须命中 `agent_runtime_acceptance_evidence_tools()`（`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_actions/tool_policy_snapshot.rs:74-96`，当前 18 项）。确定性收束的任务和 Runtime 内部产物验证都不产生 Provider 回执，因此无法为验收节点提供证据——不要指望「让 Runtime 自己验一下」能满足验收图。 ## 2026-08-12 给 manifest 加"新鲜度门控"或身份字段的两个陷阱 - 陷阱二（补身份字段只堵一条路）：改写 `task.status` 的写入路径有两条互相独立的。除 `update_manifest_task_status_at`（`apps/ai-game-creator-shell/src-tauri/src/project/manifest.rs:590-608`）外，还有毫无秩序守卫的 `set_task_status`（同文件 `580-588`，直接 `task.status = status`），其调用方 `record_draft_task_progress`（同文件 `387-413`）把 `code-prototype` 列进批量置 `Completed` 的清单，由用户可随时触发的 `game.generate_draft` 命令调用。只给前者补 `statusRunId` / `statusSource`，后者会原样保留上一次写入的旧身份印记，于是污染写入反而通过校验，比不校验更危险。对照组是 `apps/ai-game-creator-shell/src-tauri/src/agent/generation/trace.rs:613-637` 的 `set_task_status_if_current`，它有 `should_replace_task_status` 秩序判定——两者的不对称本身也是一个待处理项。 - 处理：本阶段不加机制，manifest 明确降级为 lineage 判定通过后的补充信号（见 decision-log 2026-08-12 条）。将来要做，必须同时覆盖两条写入路径，并统一走毫秒换算 helper。 - 验证：`apps/ai-game-creator-shell/tests/agentRuntimeModel.test.ts` 的「keeps an unbound manifest out of the verdict until the current main is terminal」钉住了现有边界与残余风险；该用例最后一条断言即为已记录的残余风险，改动它就意味着重新裁决，必须同步更新决策记录。 - 现象：前端 Runtime map 以 Agent ID 保存当前记录。新一轮仍会复用 `code-prototype`、`art-director`、`art-asset-plan` 这些 Agent ID；若旧 root 已终态但 main/美术 child 或 manifest 仍在收口，直接从 live map 归档会在新 root 接管后丢失旧后代，或把新轮证据误接到旧阶段记录。 - 修复：根进入终态时按完整 `agent/session/run` 身份保存 root-scoped Runtime 快照，后续只合并同一稳定身份的更新；manifest 快照只在该 root 仍为当前 root 时捕获。归档前重新执行严格 lineage、全终态、单 main/单 active art 与 reconciliation 门禁，并用 root run 派生稳定 message ID。 > 用途：记录已验证、未来很可能再次遇到的问题。每条都应包含现象、原因、处理方式和验证方式。 ## 记录格式 ```md ## 问题标题 - 现象：看到什么错误或异常行为 - 原因：确认后的根因 - 处理：具体修复步骤 - 验证：如何确认修复有效 - 关联：相关文件、文档、提交或 Issue ``` ## 严格 delegated 授权失败不能把 retry 回落为普通美术权限 - 原因：代码混用了“是否声称动态美术 lineage”和“是否已证明当前首次委派授权”两个事实。retry 使用新 run 和新 delegationId，但没有与之绑定的 durable delivery，结构上无法满足现行 exact lineage；授权失败应表示不可信候选，而不是普通 Agent。 - 验证：覆盖 failed/cancelled child 重试零 successor run、遗留 retry 的 file/patchset/Canvas/command/preview/再委派拒绝、失败回执认领后同 run 同 target 重委派拒绝、下一轮 main 重新审计后同 target 新委派放行且 delivery 全链一致并恢复 `assets/**`，同时对完整 DAG 与非美术 retry 做非回归。 - 关联：`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_driver/lifecycle_control.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_tools/file_ops.rs`、`docs/project-memory/shared-memory/decision-log.md`。 ## 不能用可玩游戏 smoke 验证 code-prototype 上游的固定文档产物 - 现象：真实新项目的 `design-foundation`、`balance-seed`、`art-asset-plan` 或 `audio-asset-plan` 已写完自己的固定文件，却始终无法收束；`project.verify` 因项目没有 `package.json` 不可用，`game.static_smoke` 又报告缺少活动 `