Merge remote-tracking branch 'origin/codex/ai-game-creator-app' into ai-game-creator-app-home-sidebar

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

@@ -1021,7 +1021,7 @@ V1.27 在 V1.26 一次最多三个原生 action 的基础上，让同一 Agent
 
 V1.28 收紧 V1.16 的静态专业 Agent 协作协议：`project-supervisor` 是正式用户唯一默认对话 Agent，也是唯一可以向正式用户提交最终回复的 Agent；静态专业 Agent 与 isolated child 只向父 run 交付内部回执、摘要和证据。开发窗口仍可直调单个专业 Agent，`agc:swarm` 仍可显式指定其它父 Agent 做调试，但这些入口不构成正式用户对话或第二条用户回复。若本节与 V1.16 或实施计划中的旧表述冲突，以本节为准。
 
-**状态：合同委派、结构化回执、单层 repair 和 Supervisor finalization 门禁已进入 Runtime；正式用户 GUI 已把项目开发页的普通主聊天接入 `project-supervisor` active Session，当前实现切片与前端定向回归已通过。但 Runner 强杀恢复和真实 `gpt-5.5` 双 Agent swarm 加恰好一次 repair 尚未完成验收，因此 V1.28 整体仍为 NOT PASS。**
+**状态：PASS。合同委派、结构化回执、单层 repair、Supervisor finalization、正式用户 GUI 接入和 Runtime 显式瞬时重试均已落地；2026-07-17 正式 `openai_chat / gpt-5.5` `supervisor-swarm` 已完成双专业 Agent 真并行、唯一 repair、pidfd Runner 强杀恢复、唯一 Supervisor assistant、零重复与零泄漏的完整验收。**
 
 ### 正式 GUI 接入边界
 
@@ -1081,21 +1081,52 @@ Supervisor 只有在同一父 run 已认领原 delivery，且原回执为 `needs
 
 repair 深度固定为 `1`；同一原 delivery 同时最多存在一个非 `suppressed` repair。相同 durable action/身份重放必须幂等复用已预留或已创建的 repair；不同 action 的重复或并发竞争必须在 delivery 锁内发现既有非 suppressed repair 后拒绝，不能创建第二个活跃目标 run、第二份可认领回执或 `-dup-*` repair。repair 结果继续唤醒、认领并收束到原 Supervisor Session/run；它不能创建第二条面向用户的 assistant。repair 再次 `needs-repair` 时不得继续嵌套委派，Supervisor 只能基于现有证据裁决或走用户输入门禁。`suppressed` repair 不视为已完成返工，原 `repairRequired` 门禁必须继续阻断 finalization；同一 durable action 可以在无终态字段时把原 delivery 恢复为 `dispatched`，若该 action 已持久失败，新 action 也只可在既有 repair 全部 suppressed 时创建替代的基础设施投递，不能形成第二轮语义返工。
 
+Supervisor 认领回执后必须能够再次从 durable delivery 取回权威返工合同，不能依赖首次 `agent.run_status` observation 或模型记忆。普通 `agent.run_status` 要返回有界的 `claimedDelegateContracts` 目录，至少包含 `delegationId / targetAgentId / repairOfDelegationId / contractStatus / acceptanceCriteriaCount / expectedArtifactsCount`；带可选 `delegationId` 查询时，只允许原 `project-supervisor` 父 run 读取属于自己且已 `claimed-by-parent` 的 delivery，并返回未截断的 `delegationId / targetAgentId / acceptanceCriteria / expectedArtifacts / repairOfDelegationId / deliveryStatus / terminalStatus / contractStatus`。该查询是只读、可幂等重放的私有 observation，不返回 task 正文、Provider payload、凭据或绝对路径；合同超过明确有界输出上限时失败关闭，不能截断后让模型猜测。返工被“合同未完整继承”拒绝时，失败 observation 必须携带同一 durable delivery 的完整 `claimedDelegateContract` 权威快照，Supervisor 可直接逐字段据此修正；该字段缺失或身份不确定时才必须按原 `delegationId` 重读，不得重复无目标地轮询状态或从 action history 的摘要反推。
+
 ### Prompt 与完成门禁
 
 - 专业 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 门禁。
 - Supervisor prompt 必须明确：不得把 `evidence-ready` 当作自动语义通过，不得忽略或吞掉 `needs-repair`；对无法自行裁决的冲突、缺失决策或用户偏好，只能汇总后通过既有 `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。只有原 `project-supervisor` Session/run 可以随后写入唯一正式用户 assistant 和 completed 投影。
 
+### Provider 多 action 原批次门禁
+
+为了让 Supervisor 在同一原生 planning 中提交两个专业委派，同时保持确认顺序和崩溃恢复，Provider 一轮返回 `2-3` 个 action 时必须先建立私有 durable action batch，再允许任何成员产生工具副作用。批次绑定 project、Agent、task、Session、run、loop、steer cursor、完整计划、项目 revision、仓库上下文指纹及全部稳定 actionId；不能在恢复时重新请求 Provider 或重建新身份。
+
+- Runtime 必须先对整批 action 完成本地策略和 MCP policy preflight。任一成员被拒绝时整批进入 `aborted`，所有成员保持零工具执行，只投影一份稳定拒绝 observation；存在确认成员时整批进入 `waiting-confirmation`，收集完全部精确确认之前，位于确认动作前后的 auto 成员都不得执行。
+- 全部确认完成后批次进入 `ready`，从 `nextActionIndex=0` 按 Provider 顺序执行。连续安全只读成员仍可复用 V1.27 parallel-read batch；两个 `agent.delegate` 虽按顺序完成 durable dispatch，但 child lane 可在第二个 dispatch 后并行运行。任一成员返回非 `ok`、same-run steer 或仓库上下文漂移时，剩余后缀先持久标记为 `superseded`，不得继续执行。
+- cursor 只能在成员的 observation、公共投影、receipt、Agent DB 和 context bundle 全部持久化后推进。Runner 重启必须分别恢复缺失的 confirmation sidecar、尚未首次 dispatch 的 `ready` 批次，以及“cursor 已推进但 observed pending 尚未删除”的窗口；相同 actionId 的恢复只补缺失投影，不增加物理副作用、receipt 或 action event。
+- `waiting-confirmation / ready / aborted / superseded / completed` sidecar 未完成幂等收束前，空 action 完成分支和 finalization 都必须由 `runtime.provider_action_batch` blocker 阻断。Goal pause/resume 不得把 `ready` 批次降级成普通 `planning`，而要保留原 loop、steer 与 action cursor 并投影 `provider-action-batch`。
+
+### Provider 瞬态失败显式重试
+
+真实 Swarm 会同时放大多个长 tool-plan 请求，上游连接在尚未返回任何可解析响应时可能出现 timeout、connectivity 或 transport 失败。Runtime 不得把 `LlmClient.maxRetries` 恢复成单 lifecycle 内部的隐式 HTTP 重放；已有 `agentLlm.<agent>.maxRetries / retryBackoffMs` 改由 Runtime 解释为可审计的物理请求重试上限和基础退避。
+
+- 每个物理尝试继续使用单次请求 client，并写自己唯一的 `started -> completed | failed | interrupted` Provider lifecycle。首次 slot 保持原值；第 `N` 次瞬态重试使用稳定后缀 `-transient-N`，因此 requestId、slot 和 lifecycle 都可区分，不能把两次物理请求伪装成同一条 lifecycle，也不能覆盖失败终态。
+- 只允许 `timeout / connectivity / transport` 进入显式重试。Provider 已返回但工具协议格式无效时继续走既有 `repair-N` 请求；HTTP 业务错误、配置错误、非法请求、反序列化、空回复和重试耗尽仍按当前 run 失败。重试发生在响应被解析和任何工具副作用之前，不创建 action、pending、receipt、delivery、conversation assistant 或项目 revision。
+- 每次重试前重新构建无自动重试的 LLM client，按 `retryBackoffMs * 2^(N-1)` 有界等待；等待结束后重新经过 Provider snapshot 的 Goal、steer、cancel、task/run 和 orphan lifecycle 门禁。期间收到控制请求时不得启动下一次物理请求；Runner 强杀后只有 `started` 无可信终态仍进入 reconciliation，不因配置了重试而自动补发。
+- 公共重试审计只保存 Agent/task/Session/run、request kind、原 request slot、重试序号、最大次数、错误 kind、错误指纹和字符数，不保存 URL、请求/响应正文、function arguments、凭据或绝对路径。验收必须逐 requestId 证明 lifecycle 无重复、全部已终态，并把失败物理尝试与 retry audit 一一对应；最终成功允许此前存在已闭合的瞬态失败，但不允许孤立 `started`、同 requestId 双终态或副作用重放。
+
 ### 验收口径
 
 确定性测试至少覆盖 strict native schema、路径与数量边界、旧 action 空合同恢复且 sidecar 字节不迁移、合同字段跨 Runner 重启保持、客观 `evidence-ready / needs-repair` 判定、artifact SHA-256、verificationRequired、claim 快照、语义不自动通过、单层 repair、同原 delivery 并发 repair 幂等/拒绝、repair 后 final barrier，以及专业 Agent/child 无用户 assistant。
 
 真实 `gpt-5.5` swarm 验收必须在无固定工具顺序和修复配方的任务中，由同一 `project-supervisor` 父 run 并行委派两个专业 Agent；其中一份弱交付必须形成可解释的 `needs-repair` 或被 Supervisor 判为语义不满足，并恰好触发一次 repair。验收期间强杀并重启 Runner，证明合同、delivery/claim/repair 身份和原父 Session/run 不丢失；最终正式用户 conversation 只有一条由 `project-supervisor` 写入的 assistant。全量 task/event/action/delivery/claim/receipt/conversation/Provider lifecycle 交叉检查必须得到重复 action、receipt、message 均为 `0`，且凭据、私有正文、绝对路径、诱饵和 Provider payload 泄漏均为 `0`。
 
-2026-07-16 本地确定性回归已完成当前实现切片：`project_supervisor_` 30/30 PASS，另有 native `agent.delegate` 合同从 function call parser 到执行器和 durable delivery 的贯通测试 1/1 PASS。覆盖真实 artifact SHA-256、缺失产物与 verification gate、旧 Ready sidecar 字节不迁移、同原 delivery 双线程 repair 竞争只产生一个活跃 delivery/task/audit、错误目标与 repair-of-repair 拒绝、`suppressed` repair 持续阻断且同 action/新 action 基础设施恢复、父 lane 忙时损坏 verification 持续重试并在释放后进入 reconciliation、规范字段和别名的显式空合同执行器拒绝，以及 repair 前零 assistant、repair 后唯一 Supervisor assistant/completed。正式 GUI 接入后的 `appSurface.test.ts` 当前为 279/279 PASS，覆盖首页首条需求只投递 active Supervisor Session、已有项目恢复、非终态 run same-run steer、专业 Agent 只读状态、开发入口隔离、legacy 项目对话零新增双写和唯一终态 assistant。Runner 重启扫描会再次发布终态 child 并重新挂接 reconciliation 重试，但本轮尚未完成强杀验收。
+2026-07-16 本地确定性回归已完成当前实现切片：`project_supervisor_` 30/30、`provider_action_batch_` 12/12、`parallel_read_batch_` 8/8、终态 receipt reconciliation 1/1 PASS，另有 native `agent.delegate` 合同从 function call parser 到执行器和 durable delivery 的贯通测试 1/1 PASS。覆盖真实 artifact SHA-256、缺失产物与 verification gate、旧 Ready sidecar 字节不迁移、同原 delivery 双线程 repair 竞争只产生一个活跃 delivery/task/audit、错误目标与 repair-of-repair 拒绝、`suppressed` repair 持续阻断且同 action/新 action 基础设施恢复、父 lane 忙时损坏 verification 持续重试并在释放后进入 reconciliation、多 action 整批预检、零副作用拒绝、确认聚合、修改后验证 gate 滚动、稳定 cursor 恢复、Agent DB 终态先于 cursor 推进、steer 作废后缀及 Goal resume 不回退 cursor、规范字段和别名的显式空合同执行器拒绝，以及 repair 前零 assistant、repair 后唯一 Supervisor assistant/completed。正式 GUI 接入后的 `appSurface.test.ts` 当前为 280/280 PASS，覆盖首页首条需求只投递 active Supervisor Session、已有项目恢复、非终态 run same-run steer、专业 Agent 只读状态、开发入口隔离、legacy 项目对话零新增双写和唯一终态 assistant。Runner 重启扫描会再次发布终态 child 并重新挂接 reconciliation 重试，但本轮尚未完成强杀验收。
 
-同日真实 Provider 验收未通过。第一次隔离运行的测试驱动误把多行任务拆成多个 steer，不能作为并行结论；修正为单条输入并移除逐个确认后，正式 `openai_chat / gpt-5.5` 在 Supervisor 首轮 planning 即返回 transport failure，尚未创建 delivery。此前那次较长运行也以同类 transport failure 终止，且只形成一个专业委派。因此当前没有“双专业 Agent 真并行、一次弱交付恰好一次 repair、Runner 强杀恢复、唯一最终回复”的真实证据，不得记录 V1.28 PASS。
+2026-07-17 正式 `openai_chat / gpt-5.5` `supervisor-swarm` 完整 PASS：同一 native Provider 批次产生 2 个初始 `agent.delegate`，design/quality 两个专业 Agent 的物理 Provider 区间真实重叠；2 份初始 delivery 经 1 个 Observed claim 的 2 条 receipt 认领，质量弱交付经 1 次 targeted contract read 创建唯一继承原合同的 repair，repair 再由第二个 Observed claim 的 1 条 receipt 认领。repair 待确认动作前后完成 Linux pidfd Runner 强杀、boot 变化、恢复扫描和同一父 Session/run 身份保持；最终只有 1 条 `project-supervisor` 用户 assistant，3 条专业 assistant 只留在内部 Session。
+
+正式报告包含 46 个 Provider request identity，`46 started / 46 terminal / 46 completed / 0 failed`；成功计划 `24/24`、格式修复 `20/20` 均使用 `native_runtime_tools`，wrapper/text fallback 为 `0`。父计划 5 步全部 completed，2 个公开项目文件通过宿主验证；4 个 run 共 16 个 finalization stage。delivery、message、action lifecycle、executing action、receipt、Provider lifecycle 的重复计数均为 `0`，pending/batch/finalization/confirmation/user-input sidecar 均为 `0`，steer、Provider payload、私有正文、API Key、项目绝对路径、正式配置路径、报告、secret 和 lure 泄漏均为 `0`。suite 只使用 sentinel 管理的隔离 AppData，正式配置 CLI 调用为 `0`，源 Runner endpoint 未变化，隔离 Runner/AppData 已清理。
+
+## V1.29 Project Supervisor 受控瞬态重试真实门禁
+
+2026-07-17 新增独立 `supervisor-swarm-transient-retry` 真实门禁，补足上述 `0 failed` 报告未触发显式重试的证据缺口。suite 在正式 AppData 的同级目录创建 sentinel 管理的一次性 AppData，只把 `design-director` 配置指向本地回环 fail-first 代理，并把该 Agent 设为 `maxRetries=1 / retryBackoffMs=100`；正式 AppData 目录和文件只读，其他 Agent 保留源配置。代理在首个 POST 向真实 upstream 转发正文前主动断开，第二个请求先停在 forwarding gate；验收器在放行前交叉读取 lifecycle、retry audit、action、pending、receipt、delivery、claim、conversation、project revision 和目标产物，随后才让同一重试请求进入真实 Provider。代理只保留计数，不保存或输出 upstream URL、headers、Authorization、请求/响应正文或凭据；E2E 启动 CLI/Runner 时把 `127.0.0.1 / localhost / ::1` 合并进 `NO_PROXY` 和 `no_proxy`，防止继承的系统 HTTP 代理先接触凭据或正文。源配置副本和临时 overlay 均为 `0600`，source-dir guard 必须证明源目录未出现本 suite 前缀的事件或残留项，配置 inode/内容和 Runner endpoint 身份保持不变，并由 sentinel 清理隔离目录。源目录 mtime/ctime 不能作为归因证据，因为并发正式 Runner 会合法刷新 endpoint heartbeat。
+
+最终加强版正式 `openai_chat / gpt-5.5` 复验 PASS：46 个 Provider request identity 全部形成唯一终态，`46 started / 46 terminal / 45 completed / 1 failed`，恰好 1 条 retry audit；失败 attempt 与后继 `-transient-1` 使用不同 request identity，Agent/task/Session/run/source/request kind 保持一致。forwarding gate 放行前 action、receipt、专业子委派、claim、assistant、pending、project revision 和 upstream forwarding 均为 `0`。代理观察到的 10 个目标 Agent 请求与该 Agent lifecycle 数量一致，其中 1 个注入失败、1 个暂停、9 个转发。放行后仍完成 2 个初始专业 Agent 真重叠、2+1 delivery、2 个 Observed claim、1 次 targeted contract read、唯一 repair、pidfd Runner 强杀/boot 恢复、5 步父计划、唯一 Supervisor assistant 与 3 条内部专业 assistant；27/27 成功计划和 14/14 repair 均为 `native_runtime_tools`。重复、残留 sidecar、Provider payload、私有正文、API Key、项目/正式配置路径、报告、secret 与 lure 泄漏均为 `0`；source-dir suite-prefix guard 与 `sourceAppDataDirectoryUntouched` 证明正式 AppData 未被写入，物理请求/lifecycle 一一对应和失败 partial checkpoint 门禁均通过，代理、隔离 Runner/AppData/项目全部清理。
+
+该受控 suite 是 V1.28 协议与恢复的故障注入门禁，不替代后续自主 Swarm 验收。现有 fixture 明确给出两个专业方向、同轮要求和一次 repair 上限；“Supervisor 在不提供 Agent ID、并行配方或 repair 次数时自主选择编排”仍需独立 `supervisor-swarm-autonomous` 真实 suite 证明。真实 `--swarm-chat`、同一 run 的 static delivery + isolated all-join 组合以及 Tauri/WebView 宿主级 Supervisor GUI 也仍是单独完成项。
 
 ## 验收命令
 
@@ -1104,6 +1135,7 @@ repair 深度固定为 `1`；同一原 delivery 同时最多存在一个非 `sup
 - `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml goal_context_bundle_v4_migrates_v3_and_v2_then_rejects_plan_mismatch -- --nocapture`
 - `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml response_stream_ -- --nocapture`
 - `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml mcp_ -- --nocapture`
+- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml provider_action_batch_ -- --nocapture`
 - `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml parallel_read_batch_ -- --nocapture`
 - `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml swarm_cli::tests -- --nocapture`
 - `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml typed_goal_pause_and_cancel_require_durable_intent_and_keep_exact_run -- --nocapture`
@@ -1123,6 +1155,8 @@ repair 深度固定为 `1`；同一原 delivery 同时最多存在一个非 `sup
 - `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite scoped-agents`
 - `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite project-skill`
 - `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite parallel-read`
+- `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite supervisor-swarm`
+- `npm run ai-game-creator-shell:agent-runtime:supervisor-swarm-transient-retry-real-e2e -- --config-dir <AppData>`
 - `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite full`
 - `npm run check:encoding`
 - `git diff --check`

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

@@ -584,5 +584,7 @@ game-project/
 - V1.28 的新 native `agent.delegate` 必须同时携带 `agentId / task / acceptanceCriteria / expectedArtifacts / repairOfDelegationId / runId`，其中 `acceptanceCriteria` 为 1-8 项，`expectedArtifacts` 为 0-16 个精确项目内非私有相对文件，两个引用字段可为 `null`。旧持久 action 缺字段只按空合同恢复，已有 pending/delivery/claim sidecar 不迁移。durable delivery 与 claim receipt 原样保存合同和 `structuredResult`，后者包含 `evidence-ready | needs-repair`、artifact path/SHA-256、缺失产物、验证要求与 revision、安全 evidence/error。
 - Runtime 只按 child completed、预期产物齐全和必要 verification passed 判定 `evidence-ready`；Supervisor 仍须按 `acceptanceCriteria` 结合摘要与证据做语义验收，不能把 evidence-ready 自动视为通过，也不能忽略 needs-repair。专业 Agent prompt 带完整合同；无法自行裁决的问题由 Supervisor 汇总后通过 `user.input_request` 向用户提问。
 - Supervisor 认领原 delivery 后可为 needs-repair 或语义未通过创建一个 `repairOfDelegationId=<原 delegationId>` 的新委派。repair 必须完整继承原合同并交回原专业 Agent，只能留在同一父 run、深度为 1、同一原 delivery 同时最多一个非 suppressed 投递；相同重放幂等复用，不同重复/并发请求拒绝。`suppressed` repair 继续阻断，同一 action 可原地恢复；该 action 已持久失败时，新 action 只可在全部既有 repair 均 suppressed 时重做基础设施投递。所有必要 delivery/claim/repair、结构化计划、verification、确认、用户输入和其它既有 blocker 清零后，原 Supervisor run 才能写唯一用户回复。
-- V1.28 Runtime 当前实现切片及其定向本地回归已完成：`project_supervisor_` 30/30、native 合同 parser→executor→delivery 1/1 PASS，覆盖合同证据、旧 sidecar 不迁移、双线程 repair 唯一活跃投递、suppressed repair 阻断与同 action/新 action 基础设施恢复、父 lane 忙时证据损坏持续重试 reconciliation、规范字段和别名空合同拒绝及唯一 Supervisor assistant/completed；正式 GUI 接入后的 `appSurface.test.ts` 当前为 279/279 PASS，覆盖 active Supervisor Session、已有项目恢复、same-run steer、专业 Agent 只读状态、开发入口隔离和 legacy 零新增双写。这不代表完整 V1.28 验收清单已通过：Runner 强杀恢复仍未验收；真实 `gpt-5.5` 隔离复测在修正测试驱动后于 Supervisor 首轮 planning 发生 transport failure，未创建 delivery。两个专业 Agent 真并行、一份弱交付恰好一次 repair、零重复与零泄漏的真实门禁仍未通过，V1.28 整体保持 NOT PASS。
+- V1.28 对 Provider 瞬态失败采用 Runtime 显式重试：`agentLlm.<agent>.maxRetries / retryBackoffMs` 表示独立物理尝试及其有界指数退避，不得恢复为 `LlmClient` 在单 lifecycle 内隐式重放。每次尝试都重建禁用自动重试的 client，并写独立单次 lifecycle；首次 request slot 不变，第 `N` 次重试稳定使用 `-transient-N` 后缀。只有 `timeout / connectivity / transport` 可重试；工具协议无效仍进入独立 `repair-N` 格式修复，其他错误与重试耗尽按原失败路径收束。重试前必须重新检查 Goal、steer、cancel、task/run 与 orphan 门禁；控制请求可阻止下一次尝试，Runner 强杀后无可信终态的 `started` 仍进入 reconciliation，不能自动补发。重试发生在解析和副作用之前，不创建 action、pending、receipt、delivery、assistant 或 revision；既有 Runner、orphan、finalization 和隐私边界均不放宽，公共审计不得保存请求/响应正文、arguments、凭据或绝对路径。
+- V1.28 已于 2026-07-17 完成正式 `openai_chat / gpt-5.5` `supervisor-swarm` PASS：同一 native 批次双专业委派、真实 Provider 重叠、2 份初始 delivery、1 次 targeted contract read、1 份唯一 repair、pidfd Runner 强杀/boot 恢复、同一父 Session/run、唯一 Supervisor assistant 和 3 条内部专业 assistant 全部成立。报告包含 46/46 闭合且 completed 的 Provider lifecycle，成功计划 24/24、格式修复 20/20 全为原生工具协议；重复、残留 sidecar、Provider payload、私有正文、API Key、项目/正式配置绝对路径、报告、secret 与 lure 泄漏均为 0。正式 AppData 零 CLI 调用且源 Runner endpoint 未变化；规范复验命令为 `npm run ai-game-creator-shell:agent-runtime:real-e2e -- --config-dir <AppData> --suite supervisor-swarm`。
+- 2026-07-17 追加 `supervisor-swarm-transient-retry` 受控故障门禁：一次性本地回环代理只让 `design-director` 首个请求在正文转发前断线，并暂停后继请求，直到验收器确认唯一 failed lifecycle、唯一 retry audit、新 `-transient-1` identity，以及 action/receipt/子委派/claim/assistant/pending/revision/upstream forwarding 全为 0。E2E 启动 CLI/Runner 时会把 loopback 合并进 `NO_PROXY / no_proxy`，避免继承的系统 HTTP 代理接触故障门禁请求中的凭据和正文。最终加强版正式 `gpt-5.5` 报告为 46/46 lifecycle 闭合、45 completed/1 failed/1 retry；代理观察到的 10 个目标 Agent 请求与该 Agent lifecycle 数量一致，放行后完整双 Agent、唯一 repair、Runner 强杀恢复、唯一 Supervisor assistant、零重复/残留/泄漏继续 PASS。隔离 AppData 创建在正式目录同级，source-dir guard 与 `sourceAppDataDirectoryUntouched` 证明正式 AppData 未被写入，源配置与 endpoint 身份保持只读，失败 partial report 保留已取得的 retry checkpoint，代理与隔离现场全部清理。该 suite 只证明显式重试和既有协作链可组合，不把预置双 Agent fixture 扩大解释为自主编排；无 Agent ID/并行/repair 配方的自主 suite、真实 `agc:chat`、static+isolated 组合和 Tauri 宿主 E2E 仍待单独验收。
 - 开发模式可通过本地项目文件面板执行 `file.list/read/write/delete`，普通用户界面不暴露文件面板。