补齐自主可玩项目确定性门禁

- 新增确定性 OpenAI Chat Provider 与安全 E2E wrapper
- 修复成功试玩后历史失败 observation 仍阻断收束的问题
- 覆盖塔防专业返工、双视口和 37 条试玩断言并同步文档

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

@@ -5194,3 +5194,11 @@
 - 当前 run 状态与项目历史成果是两个投影：前者继续按当前 `parentRunId` 过滤，后者只从专业 Agent 持久对话中合法 `agent-finalization-<32 lower hex>` assistant 恢复。新 run 失败或待确认不清除旧成果，普通失败 assistant 不得进入资源管理。
 - 历史成果读取采用项目内单调合并：新的合法 finalization 可以替换同 Agent 的旧回执，但 Runtime 轮询引发的持久对话瞬时读取失败、空结果或新 run 普通失败消息都不得清空已恢复成果。资源卡必须明确标记“历史成果”，继续与 manifest 正式资产和项目文件区分。
 - Tauri `read_local_conversation` 的公开消息 DTO 必须把持久 JSONL 的可选 `messageId` 原样投影给前端；否则真实 finalization 在客户端边界丢失身份，前端只能看到普通 assistant 并把资源区错误显示为 0。旧消息缺少 ID 时保持 `null`，不按正文或时间猜测成果。
+
+## 2026-07-21 AI 游戏创作自主可玩项目确定性真实门禁
+
+- 决策：新增独立 loopback OpenAI Chat Provider 与 `supervisor-autonomous-playable-lane-defense-deterministic` wrapper，复用正式自主构建 suite、真实 Runner、真实 Runtime 工具、真实 Chrome 双视口和 disposable 项目。Provider 只能返回原生 function calls，不能直接写项目或伪造验证结果；临时配置必须位于仓库外并由 sentinel 约束清理。
+- 协作顺序：Supervisor 首轮并行委派程序与只读验收；验收回复因并行写入变成 stale 时必须基于最新 revision 再规划。首轮浏览器失败后，Supervisor 直接 mutation 必须被 orchestrator-only 策略拒绝，再创建后续程序委派；新 revision 的静态复验和浏览器复验必须放在同一 planning 批次，成功后再认领后续回执，最后才允许唯一 Supervisor 回复。
+- liveness 语义：observation 兜底只判断最新一条 `preview.validate`。最新成功结果会取代同一 run 更早的失败 observation，不能在成功试玩后因历史失败再次强制委派；最新结果仍为失败时继续阻断收束。持久 verification gate 的 `failedPlaytestRevision` 仍是优先事实源，不因本次修正放宽。
+- 验收证据：本轮确定性 wrapper 与正式子 suite 同轮 PASS。Provider `17` 次 planning、异常 `0`；项目 revision `0 -> 2`，`game.static_smoke` 与桌面/移动浏览器通过，`lane-defense-v1` 固定试玩 `37/37`；三份委派回执全部认领，唯一 Supervisor assistant，pending、sidecar、reconciliation、重复、密钥/正文/路径泄漏均为 `0`，隔离 Runner、AppData、配置和项目全部清理。
+- 边界：本门禁证明本地确定性 OpenAI-compatible 路由可以驱动完整正式链路，不代表任何外部 Provider 已通过。外部 Provider 的鉴权、网络与模型行为必须用独立同轮 E2E 记录，不能与本结果拼接。