完善自主 Swarm 无干预可玩交付

固定首批程序实现与质量只读职责，并在计划执行前阻断质量 Agent 项目写入
要求非只读专业 Agent 完成本人修改和对应 revision 验证后再交付
补齐 Provider 瞬态重试、最终回复和 Swarm CLI 终态收敛
升级 Provider action batch v3 并兼容 v2/v1 持久恢复
扩展确定性与真实外部 Provider 塔防验收、前端状态和项目文档

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

@@ -82,6 +82,10 @@ V1.11 的受保护仓库控制目录同时包含 `.git / .agent / .agents / .cod
 
 终局 pending / confirmation / user-input / provider batch / retry / handoff / tool-plan handoff / finalization 残留 / reconciliation / duplicate 全为 `0`；Provider payload / private body / API Key / project path / config path / log / browser report leak 全为 `0`；人工 approve / answer / steer 全为 `0`。Runner 与 AppData 已清理，项目因 `--keep-project` 暂留后由主线程清理。此前 `114` identity 与 `105` identity 两个 **FAIL** 继续保留为独立历史失败，证据未与本轮拼接；最终 PASS 是这个单个新轮次的完整证据，当前外部 Provider 全链路状态现已 **PASS**。
 
+2026-07-22 V1.47 收紧自主构建首批职责与专业交付：`project-supervisor` 的 initial wave 必须同时且各一次委派 `code-prototype` 与 `quality-review`。程序委派必须是非只读实现任务，`expectedArtifacts` 包含 `game/index.html`；质量委派必须显式只读、不得修改项目且 `expectedArtifacts=[]`。合同在 Provider 计划解析、batch prepare 和 durable batch 恢复三处重验；新批次使用 `game-creator-provider-action-batch.v3`，只有 v3 按新职责失败关闭，升级前已持久化的 v2 collaboration batch 与 v1 contractless batch 继续按原 fingerprint 和合同恢复。只读专业 Agent 的 Provider 计划只允许纯读取与状态观察动作，任何文件、revision、命令、任务、记忆、黑板、资产或委派副作用都在执行前拒绝，并把格式修复目录收窄为仅 `respond_to_user`。非只读专业 Agent 只有在本人 run 产生 project mutation 且当前 mutation revision 已验证通过后才能回复；ready 未认领或 claim 尚未 observed 时，父 Supervisor 必须先只调用 `agent.run_status` 收束回执，再决定 repair。只读判定只接受明确的只读审查/验收或不得修改指令，`非只读 / 不要只读 / not read-only` 等否定式标签不得因子串命中而误判。
+
+V1.47 在只读工具边界和 batch v3/v2/v1 恢复终审修复后的最新独立真实外部轮次已完整 **PASS**：用户只输入一次任务后 stdin 立即 EOF，人工 approve / answer / steer 均为 `0`；一个原始专业任务失败后由唯一 repair 自行恢复，父 Supervisor 为 `idle / completed`，`turn.report=settled` 且只有 `1` 条 `44` 字符 assistant。项目 revision `0 -> 6`，`game/index.html` 为 `8080` bytes 且已变化，两次静态检查通过，desktop / mobile 的 `lane-defense-v1` 真实 Chrome 试玩为 `37/37`。`88` 个 Provider identity 全部 terminal，其中 `75 completed / 13 failed`，`12` 条 durable retry audit 与专业 repair 均自行恢复；open lifecycle、pending、confirmation、user-input、provider batch/retry/handoff/tool-plan handoff、finalization、reconciliation、duplicate 与各类泄漏终局均为 `0`，Runner、disposable 项目和隔离 AppData 已自动清理。该轮证明失败 attempt 可保留真实证据而循环仍能零人工干预收束，不能把它改写成 Provider 零失败。
+
 2026-07-15 起，Runtime V1.1 文档的“V1.17 单 Agent 持久计划”作为后台工具规划进度的新事实源。`submit_agent_tool_plan` 新增 nullable `planUpdate={explanation,steps[{step,status}]}`；步骤只接受 `pending / in_progress / completed`，最多 8 步且至多一个 `in_progress`。结构化计划一旦建立，legacy `plan` 只作旧协议 fallback；终态步骤必须保留，`planRevision` 只在真实变化时单调递增，工具 action 下标不得自动完成结构化步骤，存在未完成步骤时不得写最终回复或 completed。
 
 V1.17 计划快照随 `game-creator-runtime-context-bundle.v3` 持久化，v2 在通过原身份、revision 和 verification gate 校验后从当前 Runtime state 补齐计划字段继续恢复；计划元数据本身不推进项目 revision、不改变 verification gate，也不触发项目权限确认。开发 UI 和 CLI 有界展示 revision、说明与完整 8 步；正式用户的 Supervisor 只展示完成数、当前步骤、等待对象、下一步和协作数量的紧凑摘要。恢复、same-run steer 和真实 Provider 的完整验收矩阵以 Runtime V1.17 章节为准；2026-07-16 已在当前 v5 context 上完成正式 `openai_chat / gpt-5.5` 的同 run steer + Runner 强杀恢复专项，门禁状态为 PASS。