合并主分支

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

@@ -79,6 +79,17 @@
 
 ---
 
+## 2026-08-06 AGC 根长任务启动与终态失败采用 Runtime 公开消息硬门
+
+- 背景：AGC 已有模型 final-reply、Runtime `eventId/publicText` 和进度卡，但根任务“已入队”没有后端持久公开回执；失败消息又散落在 main loop 多个 `let _ = append conversation` 分支。Provider 或 Runtime 在首条公开事件前失败时可能零消息，同一次失败也可能被 `turn.failed` 和 conversation 重复播报。
+- 决策：Supervisor / 专业 Agent 继续负责业务语义，Runtime 只增加两项不依赖模型的最低可观测性。用户直接投递的 Project Supervisor 根后台任务先落为不可执行的 `preparing / public-status-pending`，再以 run 绑定的 `runtime-public-status-*` message ID 幂等写入启动确认，成功后才转为 `pending / queued`；恢复预检只验证业务状态且不改写 task/conversation，仅真实 resume 持有 Agent 锁后才能把已验证的 accepted 任务持久提升为 `pending / queued`，写入失败则把 task 落为 `failed / public-status-write-failed`。根 Supervisor 通过正式失败 / 预算耗尽收束或 game-chat 绝对硬期限进入 reconciliation 时，在其它终态投影前先写一条脱敏失败消息；专业 Agent 命中同一全局硬期限时，必须通过权威 Run Profile 与根 task 在项目 conversation 幂等写根终态，同时只在精确匹配 agent/run/session、两个 parent 和 binding 的专业 Agent Session 保留 child 终态。自称根 agent/run 但 session 或两个 parent 不符的 Runtime 必须失败关闭，不得生成第二条项目终态。该前缀的 Runtime 公开状态只供 UI 展示，不合入任何 Agent prompt。前端把它视为 Runtime-owned，同秒时排在触发它的 Supervisor 用户消息之后，并仅过滤重复的根 `turn.started / turn.failed / turn.budget_exhausted`，专业 Agent 启动事件仍可见。
+- 恢复补充（以本条为准）：`preparing` 只要同 run 的用户消息或 accepted 任一已完整持久即属可恢复；preflight 不改写业务文件，resume 才在 Agent 锁内补写 accepted 并入队。用户消息或 accepted conversation 已存在而审计补写失败不得把任务改判为启动失败。根终态首次公开写入遇到瞬时失败时，完成终态投影后必须用同 message ID 再幂等写一次。带 parent 的 Supervisor receipt / isolated-join 续跑只保留一份 Runtime 公开终态，不再追加 Session 重复消息；`runtime-task-*` 与 `runtime-public-status-*` 共享同 run 的不透明关联摘要，多个同秒任务在 UI 中按实际 run 关联的 `user -> accepted -> terminal` 交错排序。
+- 边界：不改变 Supervisor 条件 Graph、`agent.route_manifest`、美术路由、Provider tool-plan / final-reply 协议、response stream 或最终 assistant 唯一性；不把 tool 参数、原始错误、路径、fingerprint、凭据和专业 Agent 私有失败诊断公开。Runtime 也不根据工具事件推断业务进展，后续若引入模型 `commentary/final` phase 应沿独立消息协议扩展。
+- 验证方式：覆盖 `preparing -> accepted -> pending` 顺序与崩溃恢复、启动确认幂等、启动确认无法持久化时任务零执行、公开状态不进入实际 Agent prompt、状态文件写入本身失败时仍先产生公开失败、根终态事件不重复进聊天、专业 Agent 启动事件仍可见、普通项目消息不被误标 Runtime-owned，并运行 Runtime 定向 Rust、AppSurface、模型测试、typecheck、编码和 diff 门禁。
+- 关联文档：`docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`、`docs/project-memory/shared-memory/development-workflow.md`、`docs/project-memory/shared-memory/pitfalls.md`。
+
+---
+
 ## 2026-08-05 game-chat 当前 ready child 对 manifest Pending 漂移保持活性
 
 > 本条只保留 ready child 的 Pending 漂移处理；历史试玩类型继承与旧三 Director 首波验收已由 `2026-08-06 game-chat 固定规则只提供上下文，Supervisor 决定条件 Graph` 取代。

docs/project-memory/shared-memory/development-workflow.md

@@ -83,6 +83,16 @@ cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml real_
 
 game-chat 迭代还必须确认以下行为：Supervisor ready 输出、本轮实际启动的 `design-director / art-director / art-asset-plan / code-director / code-prototype / preview-readiness / preview-playtest` 专业 Agent 各自产生 durable `final-reply`，条件路由跳过的节点只要求 manifest 正确投影为 completed，不伪造 Agent 回复；Rust 明确生成 `eventId + publicText` 的每条公开 Runtime 输出都作为独立 assistant 消息逐条固化在项目聊天。消息通过顶层 `messageId` 幂等追加，事件 / 轮询 / hydration 重放不重复。前端禁止从原始 `summary / detail`、tool plan、Provider / Runner 元数据、命令输出或路径自行拼接持久消息；UI 把一个父 Run 统一显示为“本轮生成进度”，最新状态也不得暴露内部“第 N 轮”，完整 GUI / CLI 任务图可显示 `x/14`，首版快车道显示 `x/7`，终态不保留运行中进度卡；可信 `project-supervisor-game-chat` 一轮完成 `preview-playtest` 后直接收束，不请求下一次 Provider tool-plan；所有调度入口均不得暴露或启动 `publish-strategy` / `publish-package`。固定关键词与资产探测只进入 Supervisor 的 advisory context；没有持久 Supervisor 路由时不得启动任何 child。只有程序侧审计判定存在真实缺口或 Supervisor 明确选择整体重做时才要求可用 External Editor API，并按 `art-spec.png -> icon-spritesheet -> art-spritesheet.png + iconImageSrcs 本地切片 -> code-prototype Canvas 使用四类切片` 补齐；`use-existing-art` 不得重复生成或扣费，但仍须通过相同正式资产和代码可见使用门禁。
 
+Project Supervisor 根后台任务还必须验证公开消息硬门：任务先落为不可执行的 `preparing / public-status-pending`，项目 conversation 中存在且仅存在一条同 run 的 `runtime-public-status-* / accepted` 后才能转为 `pending / queued`；恢复 preflight 只验证并临时分类可恢复状态，不改写 task/conversation，真实 resume 持有 Agent 锁后才可把 accepted preparing 持久提升为 `pending / queued`；否则不得执行。若该消息无法持久化，task 必须进入 `failed / public-status-write-failed` 且 Provider、工具与 child 调度均为零。这类 Runtime 公开状态不得合入 Agent prompt。根 Supervisor 通过正式失败 / 预算耗尽收束或 game-chat 绝对硬期限进入 reconciliation 时，即使后续 task/event/state 写入失败，也必须已经存在一条脱敏终态失败消息；专业 Agent 命中全局硬期限时，项目 conversation 仍必须幂等保留根终态，但 child 终态只能写入与权威 task 的 agent/run/session、两个 parent 和 binding 全部一致的私有 Session；自称根 agent/run 却 session 或 parent 不符时失败关闭。只有根 Supervisor 的 `turn.started / turn.failed / turn.budget_exhausted` 不得再形成第二条聊天消息，专业 Agent 的公开启动事件仍应显示。非 Supervisor 专业 Agent 的失败状态留在对应 Agent Session，不得把私有诊断送进项目 conversation。定向复验至少运行：
+
+提交前还要覆盖启动崩溃窗口：仅 `preparing` 时 preflight/resume 均不执行；用户消息已持久但 accepted 缺失时，preflight 只报可恢复且 task/conversation 不变，resume 才补写 accepted 并转为 `pending / queued`。还要验证用户消息或 accepted 已落盘但审计失败均继续入队、根终态首次公开写入瞬时失败会用同 ID 重试、receipt / isolated-join 失败只有一条公开结果，以及同秒连续任务通过共享的 run 关联摘要按 `user -> accepted -> terminal` 逐任务展示。
+
+```bash
+cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml public_start_status -- --test-threads=1
+cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml structured_plan_state_write_failure_stops_before_context_and_audit -- --test-threads=1
+npm run test -- apps/ai-game-creator-shell/tests/agentRuntimeModel.test.ts apps/ai-game-creator-shell/tests/appSurface.test.ts
+```
+
 game-chat 条件快车道仍采用七任务口径，但执行顺序由持久合同控制。父 Run 与全部 child Run 共用 4200 秒软预算和 4500 秒累计硬上限；Supervisor 首轮先调用 `agent.route_manifest`，决策前零 child。`audit-existing-first` 的首波仅为 `design-director + code-director`，已登记但无效的旧派生视觉不得阻断这两项审计启动；code-director 必须先 `asset.list`，读取 Supervisor 已持久化的 authoritative 决策，再提交正式资产覆盖合同。覆盖完整时跳过图片生成，存在缺口时只开放缺口对应 owner，`regenerate-art` 才强制重新开放两个美术 owner；已登记但校验失败的固定资产只允许当前路由绑定的 canonical owner 原位替换。新生成仍按 `art-spec.png -> art-spritesheet.png + 独立切片` 推进，最后才允许 code-prototype 写入或局部修复入口。软预算后只允许使用已登记图集、当前 resourceId 对应切片清单的确定性本地 fallback、`game.static_smoke` 和 `preview.validate`；不得退回普通生图、猜测 atlas 网格或纯代码核心画面。完成门要求活动 Canvas 分别绘制 player、blocks-and-targets、obstacles-and-scene、feedback-effects 四类不同切片；整图 `<img>`、CSS background、完整图集直绘、单个猜测裁切和路径诱饵均失败。对应定向测试至少包括：决策前零 child、旧无效视觉不阻断首波、首波无美术 child、code-director 收到真实持久策略、完整覆盖零生成、仅缺图集只运行 `art-asset-plan`、无效已登记资产由 owner 原位替换、art spec 缺失导致引用合同失效时同时补齐两个槽位、显式重做原位替换两个正式资产、旧 root/fingerprint/缺口或重复路由失败关闭，以及补齐后恢复 code-prototype。
 
 失败续跑还必须覆盖同 Session 同 source 继承、跨 Session / 跨 source 不继承、首次与连续 successor 的 effective task / contract / scheduler 一致性，以及中英文纯继续短语使用同一识别函数。非占位入口的新 `code-prototype` 必须先产生本人 mutation 再 smoke；连续只读 smoke 不得收束。占位 fallback 只允许显式支持的真实玩法模板，俄罗斯方块必须验证棋盘、下落、旋转、锁定和消行语义，未知玩法必须失败关闭。

docs/project-memory/shared-memory/pitfalls.md

@@ -14,6 +14,15 @@
 - 关联：相关文件、文档、提交或 Issue
 ```
 
+## Runtime 状态写失败不能发生在公开失败消息之前
+
+- 现象：用户提交长任务后只看到运行失败或任务直接消失，聊天里一条有用消息都没有；另一些失败又同时出现 Runtime event 和 conversation 两条近似提示。
+- 原因：启动确认依赖实际 `turn.started`，任务只入队或 Runner 在 start transition 前失败时没有公开回执；终态失败先写 task/event/state，最后才由各 main-loop 分支尽力追加 assistant。坏掉的若正是状态文件，流程会在公开消息前返回；散落的 `let _` 又无法提供幂等身份。
+- 处理：用户直接投递的 Project Supervisor 根任务先落为不可执行的 `preparing / public-status-pending`，持久化同 run 的 `runtime-public-status-* / accepted` 后才转为 `pending / queued`；恢复 preflight 只验证业务状态，不改写 task/conversation，仅 resume 持有 Agent 锁后才可持久提升。根 Supervisor 通过正式失败 / 预算耗尽收束或 game-chat 绝对硬期限进入 reconciliation 时，先写相同协议的终态消息，再处理 Runtime 其它投影。专业 Agent 命中全局硬期限时，应由权威根 task 在项目 conversation 中幂等写根终态，child 仅在身份完整匹配时写私有 Session；根 agent/run 的 session 或两个 parent 冲突时必须失败关闭。消息正文只能来自封闭脱敏映射，prompt 构建必须按稳定前缀排除；前端按前缀标记 Runtime-owned，只过滤根 Supervisor 的 `turn.started / turn.failed / turn.budget_exhausted`，不吞掉专业 Agent 启动进度。模型仍负责业务 commentary/final，Runtime 的两条硬门不扩展成业务判断器。
+- 恢复补充：不能把“accepted 还没写完”等同于“用户从未投递”。用户消息已持久时，真实 resume 必须补写 accepted 后才入队；用户消息或 accepted conversation 已存在时，后续审计失败不得留下“正在启动”但永不执行的假状态，但同 message ID 的 role/content 冲突必须把 task 明确收束为 `conversation-write-failed`。根终态首次公开写入的瞬时失败必须在终态投影后用相同 message ID 重试。带 parent 的 Supervisor continuation 不得同时产生 Session 终态和 Runtime 事件两条公开消息；秒级时间戳下必须以 task/status message ID 共享的 run 关联摘要排序，不能用不同消息类别的计数猜测顺序。
+- 验证：任务 journal 必须显示 `preparing -> pending`，仅有 accepted 时恢复才可提升；破坏项目 conversation 时断言任务为 `public-status-write-failed` 且无可运行 pending；破坏 Runtime state 路径时断言公开失败已经存在；重复写同一 run/status 只有一条 message ID；渲染实际 prompt 断言不包含 Runtime 公开状态；AppSurface 证明根启动/失败事件不重复，专业 Agent 启动仍可见。
+- 关联：`apps/ai-game-creator-shell/src-tauri/src/agent/runtime_state.rs`、`agent/runtime_driver/task_start.rs`、`src/features/agent-runtime/model.ts`、`src/features/project-workspace/SupervisorChatOnlyView.tsx`。
+
 ## manifest 被旧快照写回 Pending 时不能让父 Run 抛下真实运行中的 child
 
 - 现象：`code-prototype` 已有确定性 child run、running journal 和工具事件，父 Supervisor 却在几秒后以 fixed graph stalled 失败；child 随后完成代码与静态检查，但 completion gate 持续报告 `task=code-prototype status=pending`，最后 `loop-budget-exhausted`。

docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md

@@ -32,6 +32,8 @@
 - Windows Runner 私有文件初始化：父 AppData 已归当前 `TokenUser` 后，新建 `agent-runner.lock`、endpoint 临时文件、project-owner 诊断临时文件与 real-E2E 私有文件的 owner 仍可能采用 token 默认 owner `Administrators`。固定 stale lock 只有在父目录已验证为当前用户 protected 私有 DACL、Windows 不共享独占句柄已取得、且句柄确认普通文件、非 reparse point、链接数为一时才允许修复；其它三类文件只允许在本进程 `create_new` 成功且仍持有同一独占句柄时初始化 `TokenUser` owner / DACL，再写入、原子安装并严格复核，初始化失败必须清理刚创建的文件。既有 durable endpoint / diagnostic 读取不得自动接管；活锁不得截断，只有 sharing / lock violation `32/33` 表示占用，access denied 等其它错误立即返回。父进程观察到 Runner 子进程退出后立即返回错误，不等待完整 30 秒 deadline。
 - 启动诊断：独立 release 的 `startup.log` 和 `agent-runner.log` 只记录有界、脱敏的阶段与 stdout / stderr 摘要，凭据、AppData 路径和其它绝对路径不得原样落盘；单文件达到 256 KiB 后只轮转保留一份 `.previous.log`。`startup.log` 优先写独立 AppData，目录不可写时回退到系统 TEMP 下的 `Genarrative-Game-Chat-Diagnostics`；Tauri context、窗口 URL、AppData、Runner 或 `.setup()` / `.build()` 初始化失败时，Windows 必须显示可见错误对话框并给出诊断日志位置，不能只在无控制台 release 中静默退出。
 - 对话与事件：窗口固定使用 `project-supervisor + autonomous-game-build`，继续复用 active Session、External Runner、持久 conversation、流式回复、same-run steer、工具确认与用户追问。以 `/` 开头的输入必须继续走现有内置命令解析，例如 `/preview` 只能生成 `preview.start` 确认卡，不得作为自主构建任务投递给 Supervisor。界面聚合当前 Supervisor 父 run 及其直接委派专业 Agent 的最新原始事件，按时间倒序稳定去重并标注 Agent；默认显示 4 条，可展开至最新 20 条。原始 `summary / detail` 仍只作 Runtime 状态投影，不直接写入 conversation。需要进入聊天的事件必须由 Rust 同步生成唯一 `eventId` 与安全 `publicText`；前端只按这两个字段形成独立 assistant 消息，无 `eventId`、空 `publicText`、legacy 事件和内部 tool / Provider / Runner 协议一律忽略。
+- 公开消息硬门：模型仍负责 Supervisor / 专业 Agent 回复的业务语义，Runtime 不根据 tool 或 Provider 事件自行补写业务结论；但用户直接投递的 Project Supervisor 根后台任务必须先落为不可执行的 `preparing / public-status-pending`，再以 `runtime-public-status-*` 稳定 message ID 把“任务已接收，正在启动处理”写入项目 conversation，成功后才转为 `pending / queued`；恢复预检只读，只能在验证到同 run accepted 消息后把该任务临时分类为可恢复，真实 resume 持有 Agent 锁后才可持久提升为 `pending / queued`；写入失败则落为 `failed / public-status-write-failed`，不得继续执行。这些 Runtime 公开状态只供 UI 展示，prompt 构建器必须按稳定前缀排除。根 Supervisor 通过正式失败 / 预算耗尽收束或 game-chat 绝对硬期限进入 reconciliation 时，必须在 task、event、state 等其它终态投影之前先幂等写入一条脱敏、用户可理解的失败消息；专业 Agent 命中该全局硬期限时，也必须通过权威 Run Profile 和根 task 将同一根终态写入项目 conversation，同时保留 child 私有 Session 状态；状态文件本身写坏也不能导致零公开结果。当前 Runtime 自称根 agent/run 时，其 session 和两个 parent 字段必须与权威根 task 一致；任一身份冲突必须失败关闭，不得以另一 session 派生第二条项目终态。前端把该前缀识别为 Runtime-owned，同秒时排在触发它的 Supervisor 用户消息之后，不二次持久化；仅根 Supervisor 的 `turn.started / turn.failed / turn.budget_exhausted` 只保留在 Runtime 详情和进度投影中，不能再生成第二条聊天消息，专业 Agent 的公开启动事件仍可见。该硬门不改变 final-reply 的唯一性；非 Supervisor 专业 Agent 的失败消息继续留在对应 Agent Session，不把私有诊断写进项目 conversation。
+- 启动恢复和续跑边界：本条取代上一条中“只有 accepted 才可恢复”的窄口径。若进程在 Supervisor 用户消息已持久、accepted 未持久之间崩溃，只读 preflight 可以把该 `preparing` 识别为可恢复，但不改写 task/conversation；真实 resume 持有 Agent 锁后必须先幂等补写 accepted，再提升为 `pending / queued`。用户消息或 accepted conversation 已落盘而辅助审计失败时，以 conversation 为公开真相继续入队，不留下“已接收但永不执行”的任务；根终态首次公开写入的瞬时失败必须在终态投影后用相同 message ID 重试。receipt / isolated-join 等带 parent 的 Supervisor continuation 不再另写 Session 终态，只保留单一后端公开事件；`runtime-task-*` 与 `runtime-public-status-*` 共享同 run 的不透明关联摘要，秒级时间戳下多个连续任务必须按实际 run 对应的 `user -> accepted -> terminal` 顺序交错展示。
 - Supervisor 进度播报：聊天消息流内保留且只保留一条当前 run 的 Runtime-owned 播报卡，由客户端从 manifest 任务图、Supervisor 结构化计划、`loopIteration`、当前动作、直接委派专业 Agent 及其持久事件确定性整理；显示当前轮次、任务 / 计划进度、活跃 Agent、最近试玩与静态检查、返工决定、代码修改和截图检查证据。同一 run 原位更新，切换 run 时替换，不调用额外模型、不追加持久 conversation，也不改变最终 assistant 回复的唯一性；任意详情必须有界且不展示绝对路径、Provider 元数据或内部指纹。
 - ready-task 启动活性：`background_task.queued`、`autonomous_ready_task.scheduled`、Runner heartbeat 或执行锁已移交都不等于 child 已启动。实际持有执行权的 Runner 必须在释放项目写锁后同步写入 child 的 running task、`turn.started` 与 started journal，再把已启动 state 和 per-Agent 执行锁交给已确认开始轮询的独立 execution worker；同步启动或 worker 接管失败时，要在仍持有执行锁期间依次把 child 和 manifest Graph 节点明确落为 failed，再释放锁并让 parent 收到调度错误。`autonomous_ready_task.scheduled` 只作诊断审计，其写入失败不能阻断 durable child 启动；external client 只 wake Runner，不在客户端抢占执行。Supervisor 进度卡通过 durable `startedAt`（旧 Run 从完整 task journal 恢复，最新 task-record fallback 保持 0）显示真实持续时间，并以父 Run 与当前关联专业 Agent 的最大事件时间计算运行态活跃度：运行超过 5 分钟无新事件时显示“运行中 · 疑似停滞”和静默时长；等待用户、等待确认、Provider retry、视觉资产、进程会话、pausing 与 paused 不误报。父 Run terminal 后，持续时间冻结在父 Run 自身最后活动，不随 child 晚到收口事件增长。消息时间统一校验为 JavaScript 可表示的 Date；越界值显示“时间未知”且不写无效 `datetime`。实时回复只显示 response stream 自己的 `updatedAt`，缺失时同样显示“时间未知”，不能借用其它 Runtime 活动时间或随前端时钟漂移。该提示只提供可观测性，不改变 Runtime/manifest 正式状态。
 - ready-task manifest 漂移：父 Supervisor 必须分别判断“能否调度新节点”和“是否存在必须等待的工作”。派生视觉需要父规划修复时不再调度新 child，但当前最新且活跃的根 Run 下，只要存在确定性 runId、scheduler source、正确父绑定且 durable journal 为 queued/running 的 ready child，父 Run 就保持 `waiting-for-manifest-tasks`，不能因旧 hydration 快照把 manifest running 覆盖成 pending 而提前 fixed-graph-stalled。game-chat child 可在相同严格身份下容忍 pending 漂移；正式产物、Canvas、revision、`game.static_smoke` 与 `preview.validate` 门禁不放宽。GUI/CLI、旧父 Run、终态、确认/用户输入/reconciliation、伪造绑定或非确定性 runId 全部失败关闭；更新根 Run 后旧 child 不得继续维持新 DAG 或投影完成。
@@ -58,6 +60,7 @@
 ## 2026-07-31 game-chat 输出、单轮预览与平台美术资源
 
 - 对话输出：game-chat 的 Supervisor `ready` response stream 继续以稳定身份显示；七任务目录中本轮实际启动的专业 Agent，其 `requestKind=final-reply` 且 `status=ready|committed` 的非空安全回复分别以 Agent、Session、run、request slot 和 response revision 形成 durable message ID，并带 Agent 标签逐条追加到项目聊天。条件路由跳过的美术节点只要求 manifest 正确投影为 completed，不伪造 Agent 回复。每条 Rust `eventId + publicText` 公开输出同样形成独立 durable 消息。所有这些消息通过 `append_local_conversation_message` 的顶层 `messageId` 幂等写入，事件、轮询、React StrictMode 和 hydration 重放不重复；tool-plan、半成品 stream、原始事件 detail、命令正文、绝对路径、Provider / Runner 元数据、哈希和凭据不得进入聊天。普通 `supervisor-chat` 保持原有 transient response 行为。
+- 对话输出中的 `eventId + publicText` 只指需要独立进入聊天的进度事件；`turn.started` 和根 Run 终态失败事件由上一条 `runtime-public-status-*` 硬门覆盖，不得同时转成事件消息。专业 Agent child 的失败消息继续留在其 Agent Session，根项目聊天只接收 Supervisor 终态失败、明确公开进度和安全 final-reply，避免一项失败被 Runtime event 与 conversation 各播报一次。
 - 单轮收束：game-chat source 只生成至 `preview-playtest` 的 manifest seed task，试玩完成后父 Run 直接进入完成门，不再调度 `publish-strategy` / `publish-package`；`agent.schedule_ready` 必须按当前 Supervisor Run 的持久 source/profile 选择同一 source-aware scheduler，不能绕过该边界。`task.list` 对同一 root source 必须从任务行、readyTaskIds 和统计中排除两个发布节点，`agent.delegate` 也必须按 root binding 拒绝直接委派这两个节点，不能让 Provider 用“读取完整 DAG 后手工委派”恢复已裁掉的发布阶段。完成门满足且 collaboration、Provider batch、进程会话、视觉资源等非验证屏障全部清零后，Runtime 必须用确定性回复直接收束结构化计划并结束父 Run，不再请求下一次 Provider 工具计划。普通 GUI / CLI 仍执行完整发布 DAG。
 - 轮次展示：`loopIteration` 只是同一父 Run 内的 Provider / 工具规划循环，用于委派、回执、返工和验收，不是用户发起的游戏生成轮次。game-chat 的进度卡、当前工作和“最新状态”事件统一显示“本轮”，整个页面不向用户显示“第 N 轮”；完整 GUI / CLI pre-publish 任务图仍可显示 `x/14`，但首版只按七项任务显示 `x/7`（详见 2026-08-03 小节），不得把两个发布节点计入任一分母。父 Run 终态后移除运行中进度卡，只保留终态阶段记录与预览。
 - 平台美术资源：game-chat 保留正式视觉 DAG，但是否进入生成节点由 2026-08-06 的持久条件路由决定。现有正式资源覆盖完整时直接复用；存在真实缺口或 Supervisor 明确选择整体重做时，`art-director` 才通过平台 `images/generations(kind=spec)` 生成并登记 `assets/art-spec.png`，`art-asset-plan` 再以该规范图的稳定 resourceId 调用 `icon-spritesheets/generations` 生成真实透明 `assets/art-spritesheet.png`，并把响应中的 `iconImageSrcs` 下载为本地独立切片，写入 `assets/art-spritesheet-slices/manifest.json`。`code-prototype` 必须等待复用或补齐后的图集与切片清单，并在活动 Canvas 中分别绘制玩家、方块/目标、障碍/场景与反馈四类切片；规范图只作 reference，纯代码核心画面、猜测图集等分网格、整图 `<img>` / CSS 背景、完整图集直绘或只出现路径均不得完成。