发布独立游戏聊天0.1.1并强化试玩验收

新增只能打开游戏聊天页的0.1.1独立release构建配置。
内置Runner启动、诊断日志、Windows后台进程与退出收束。
修复自动预览启动、同页版本刷新和结构化验收状态展示。
强化试玩协议、窗口末端采样与固定失败识别，允许正常输赢但拒绝无法推进。
完善旧验收回执自愈和当前场景指纹完成门。
补齐Rust、前端、真实Chrome回归测试及项目文档。

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

@@ -23,17 +23,32 @@
 - 界面边界：只显示持久消息区、输入框、必要的等待 / 错误状态、工具确认 / 用户追问卡片和设置入口；不显示 Agent picker、Session 面板、Goal 面板、完整 Runtime 面板或专业 Agent 协作栏。会话历史仍绑定 `project-supervisor` 的 active Session 持久化，不因隐藏 Session 控制面而变为临时聊天；`supervisor-chat` 窗口必须具备只读 Tauri event listen / unlisten capability，以实时接收 Runtime 更新。
 - 产品边界：正式用户 `client` 窗口、登录后首页和项目开发流程保持不变，不暴露该开发验证面。
 
-## 2026-07-27 开发态“游戏运行 + 聊天”临时入口
+## 2026-07-29 “游戏运行 + 聊天”独立构建入口
 
-- 入口例外：只有 debug 构建接受 CLI `--game-chat`，并可选接受 `--project-path <absolute-path>` 与内部验收用 `--initial-message <首条消息>`；宿主内部统一映射为 `index.html?game-chat&projectPath=...`。该 URL 必须在 Tauri 创建 `client` WebView 前写入初始 `WindowConfig`，禁止在 `.setup()` 阶段读取尚未完成首航的 `client.url()` 后二次导航。页面首屏读取初始消息后必须立即从当前 URL 删除 `initialMessage`，并以页面级闩锁绑定启动项目；React StrictMode、Runtime 终态、HMR、整页重载或项目切换都不得再次提交同一启动消息。release 构建不注册这些参数或窗口，无参数的正常启动流程不变。未传入项目路径时由页面选择目录：已有 AI 游戏项目直接打开，空目录按目录名初始化，非空且未初始化目录继续复用现有二次确认。
+- 入口例外：debug 构建接受 CLI `--game-chat`，并可选接受 `--project-path <absolute-path>` 与内部验收用 `--initial-message <首条消息>`；宿主内部统一映射为 `index.html?game-chat&projectPath=...`。独立 game-chat release flavor 使用 `npm run agc:build:game-chat-release` 构建，并由 Rust `game-chat-release` feature 在无参数启动时固定同一初始页面；前端也在编译期固定为 game-chat 页面，不能导航回普通客户端首页、项目组或开发窗口。该 URL 必须在 Tauri 创建 `client` WebView 前写入初始 `WindowConfig`，禁止在 `.setup()` 阶段读取尚未完成首航的 `client.url()` 后二次导航。页面首屏读取初始消息后必须立即从当前 URL 删除 `initialMessage`，并以页面级闩锁绑定启动项目；React StrictMode、Runtime 终态、HMR、整页重载或项目切换都不得再次提交同一启动消息。普通 dev / release 的入口、参数与页面集合保持不变，普通 release 不因该 flavor 注册 game-chat 参数或窗口。未传入项目路径时由页面选择目录：已有 AI 游戏项目直接打开，空目录按目录名初始化，非空且未初始化目录继续复用现有二次确认。
+- 独立发布身份：game-chat release 使用独立 Tauri 配置，`productName` 固定为 `Genarrative Game Chat`，`identifier` 固定为 `world.genarrative.ai-game-creator.game-chat`，当前专用 release 版本为 `0.1.1`，因此安装身份和 AppData 均与普通 `Genarrative AI Game Creator` / `world.genarrative.ai-game-creator` 隔离。该 flavor 只生成自己的 NSIS release 包，不覆盖普通客户端构建配置或已有 AppData。
+- 本地页面边界：独立 game-chat release 在前端入口直接渲染本地 `GameChatReleaseApp`，不经过平台 `AuthenticatedClient`，启动和使用本地项目工作台不依赖 `api-server` 或平台登录态。该例外只由编译期 game-chat-only 标记启用；普通 release、`npm run agc` 和 debug game-chat 继续经过既有认证包装，认证与后端依赖均不改变。
+- Windows AppData 安全迁移：首次创建客户端 AppData 时必须以进程 `TokenUser` SID 显式设置 owner，并写入当前用户私有 DACL，不能把可能为 Administrators 的 `TokenOwner` 当作用户身份。发现历史目录 owner 不属于当前 `TokenUser` 时，不在原目录上放宽权限，而是拒绝 reparse point / junction / symlink 后，将旧目录原子重命名到同级唯一 `.owner-mismatch-backup-*` 备份，再新建并验证当前用户 owner 与私有 DACL；迁移或备份失败必须失败关闭，不覆盖旧配置。
+- 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 条。这些原始事件只是 Runtime 状态投影，不写入 conversation，不伪装成用户或 assistant 消息。
 - Supervisor 进度播报：聊天消息流内保留且只保留一条当前 run 的 Runtime-owned 播报卡，由客户端从 manifest 任务图、Supervisor 结构化计划、`loopIteration`、当前动作、直接委派专业 Agent 及其持久事件确定性整理；显示当前轮次、任务 / 计划进度、活跃 Agent、最近试玩与静态检查、返工决定、代码修改和截图检查证据。同一 run 原位更新，切换 run 时替换，不调用额外模型、不追加持久 conversation，也不改变最终 assistant 回复的唯一性；任意详情必须有界且不展示绝对路径、Provider 元数据或内部指纹。
+- Provider 故障展示：Provider retry 的“是否可重试”继续使用 `upstream-5xx` 等稳定类别判断，但 durable retry record 保留安全的精确 `upstream-<HTTP status>` 身份。等待态必须从真实 record 显示 HTTP 状态、`nextAttempt/maxRetries` 与当前持久退避剩余秒数，例如“Provider 上游返回 HTTP 503，准备自动重试 1/3；预计 8 秒后重试”；不得以动画或前端自增计时伪造 attempt。重试耗尽的 Runtime 私有错误只保存 `kind/httpStatus/fingerprint/chars/retryAttempt/maxRetries/retryState`，前端和持久 conversation 仅在字段顺序、范围、状态一致且无尾随正文时派生“上游服务返回 HTTP 503；自动重试已耗尽（3/3）”；其它错误使用固定安全摘要。Provider 响应正文、URL/query、凭据、本地绝对路径、fingerprint、字符数和 `[redacted ...]` 占位符均不得进入用户可见消息。
 - 跨轮阶段记录：game-chat 确实观察过活跃态的父 run 进入 completed / failed / cancelled 等终态，且正式 Supervisor conversation 已刷新后，客户端把本轮轮次、任务 / 计划完成度、最新试玩 / 静态检查、最近返工决定和已登记成果图片路径整理成一条 `【Supervisor 阶段记录】` 项目 assistant 消息。每个“项目 + 父 run”最多追加一次，进入现有 `conversation.write` 权限与项目 conversation 持久化链路，下一轮及重载后继续保留；加载时已经终态但本窗口未观察其活跃过程的旧 run 不补写，防止每次启动重复归档。阶段记录不是 Supervisor Runtime 正式回复，不写入 Agent Session、不增加 final assistant 数量，也不逐条复制原始事件或内部正文。
 - 图片成果：当前 manifest 新增或恢复已登记的 PNG / JPEG / WebP 资源时，聊天消息流同步显示 Runtime-owned “Supervisor 成果图片”卡，最多展示最新 4 张并随 manifest 原位更新。图片必须通过现有 `read_local_project_image_preview` 读取，只允许当前授权项目中 `assets/` 下的已登记资源，继续执行 `file.read` auto 权限、真实格式、大小、尺寸、普通文件、祖先目录和项目根边界校验；前端只接受返回路径、媒体类型和 `data:` 前缀与请求完全一致的结果。缩略图点击后使用独立模态查看器，支持按钮与滚轮缩放、指针拖拽、双击 / 按钮复位、Esc / 按钮 / 遮罩关闭，移动端占满视口；不得在聊天卡下方追加展开区。图片卡不写入 conversation，不解析 assistant 文本中的任意 Markdown / 绝对路径，也不开放 `.agent` 验收截图读取。
 - Run 接管：External Runner 模式下首次提交可能返回“旧 canonical state + 新 `acceptedRunId`”；页面必须以 `acceptedRunId` 作为本轮权威身份，在 state 尚未切换时显示“已投递，正在同步 Agent Runner”，并允许该 run 的 Tauri event 或轮询结果接管。不得把旧 idle state 当作本轮结果、过滤新 run 事件，自动预览授权也必须绑定 `acceptedRunId`。
-- 运行容器：当前项目没有由共享 `PreviewRegistry` 返回的有效 `running` 预览时，页面只渲染聊天，不显示游戏区域或占位文案；预览运行后自动显示 iframe，桌面端按“游戏 2 / 聊天 1”分栏，移动端改为上下布局。预览停止、失败或切换项目后立即移除 iframe。运行容器继续只接受当前授权项目的 `http://127.0.0.1:*`，复用现有 CSP、iframe sandbox、autoplay、fullscreen 和 gamepad 约束；远程 URL、`file://`、手填地址或陈旧 manifest 状态均不得显示。
-- 一次性自动预览授权：用户在该入口成功提交本轮自主生成需求，即视为对“当前项目 + 当前 Supervisor 父 run”的一次 `preview.start` 授权。授权以仅含项目路径与 accepted parent runId 的客户端本地记录持久化，App / WebView 重启后仍可恢复，但项目或 run 身份不匹配时不得使用。对应首版代码产物完成后只能成功启动一次，并必须继续走现有权限、项目写锁、审计和 `PreviewRegistry` 链路；项目或 Agent 策略的显式 deny 始终优先，不得被此授权绕过。启动成功、显式 deny、非瞬时失败、父 run 在首版完成前终止或切换项目后授权失效；`preview.start` 恰逢项目写锁竞争属于瞬时失败，不消费授权，释放写锁后由同一轮询链路重试。
-- 系统边界：该页面是既有 AI 游戏创作工作台的临时开发态例外，不新增平台玩法入口、后端 API、会话库、Runner、预览服务或正式用户入口。原 `supervisor-chat` 继续固定使用 `standard` profile 并保持纯聊天行为，不继承本例外的自主构建、事件聚合或自动预览授权。
+- 运行容器：当前项目没有由 Tauri 客户端 `PreviewRegistry` 返回的有效 `running` 预览时，页面只渲染聊天，不显示游戏区域或占位文案，顶部运行状态必须明确显示“预览未启动”，不得再使用含义不明的“未启动”；预览运行后自动显示 iframe，桌面端按“游戏 2 / 聊天 1”分栏，移动端改为上下布局。预览停止、失败或切换项目后立即移除 iframe。运行容器继续只接受当前授权项目的 `http://127.0.0.1:*`，复用现有 CSP、iframe sandbox、autoplay、fullscreen 和 gamepad 约束；远程 URL、`file://`、手填地址或陈旧 manifest 状态均不得显示。
+- 预览进程归属：External Runner 与 Tauri 客户端位于不同进程，双方 `PreviewRegistry`、server 子进程句柄和 running 状态严格进程内隔离；Runner 为 `preview.validate` 持有或回收的预览进程不能作为用户可见预览，也不能据此伪造 Tauri registry 的 running 状态。game-chat 用户可见 preview 必须由 Tauri 客户端启动、持有和停止，iframe 只使用同一 Tauri registry 返回的 loopback URL。
+- 自动启动门禁：客户端只接受当前 accepted Supervisor 父 run 下真实 `preview-playtest` scheduler child 的结构化 `preview.validate` 事件，同 revision 采用最新事件且同时间失败优先；成功证据的 revision 必须精确等于当前项目原子 sidecar revision。客户端向 Tauri `preview.start` 传入 `expectedRevision`，后端在取得项目写锁后再次比对再启动，以闭合检查 / 启动 TOCTOU。same-run steer 的一次性授权使用带 revision / validation cursor 和唯一 generation ID 的 v2 记录，旧事件和旧异步 attempt 不得消费后续授权。旧 attempt 返回后的补偿清理按完整 preview identity 原子停止 registry server，不能让项目 stop policy 或写锁竞争造成后台 server 泄漏；若同项目新 server 已接管，则不能把其持久状态覆盖为 stopped。
+- 固定试玩契约：`generic-v1` 初始状态必须为 `ready` 且 `level > 0`；点击 start 后 sequence 必须推进、phase 必须进入 `playing`，并先持续观察 2 秒、取得至少 8 个实际样本，期间保持 `playing`，以确认玩家获得正常操作机会。随后必须点击唯一可见、启用且真实可交互的 `data-playtest-id="primary-action"` 控件；该控件必须映射游戏的真实主要玩法操作，并以 sequence 相对点击前严格推进证明操作已被接受。玩家获得这次正常操作机会之前进入 `won | lost` 属于过早结束并失败；操作被接受后的单次 `lost` 是合法游戏结局，但不能成为所有受控尝试的唯一结果；若主要操作后仍为 `playing`，则继续观察 3 秒并取得至少 12 个实际样本，`won` 可提前证明非失败推进。点击 restart 后 sequence 必须再次推进并恢复到 `ready | playing`，随后持续观察 3 秒且取得至少 12 个实际样本。若首轮结果为 `lost`，重开稳定后必须再执行一次必要的 start、2 秒 / 8 样本操作机会和真实 primary-action；第二次必须进入或保持 `playing`（再观察 3 秒 / 12 样本且不得转为 `lost`）或进入 `won`，两次都固定 `lost` 代表无法正常推进的恶性 bug，必须失败。各观察窗口内 sequence 不得回退，restart 窗口只能保持 `ready | playing`；样本数门槛不能替代时长门槛，窗口末端必须强制再读取一次有效状态，不能只在前段快速取得足够样本后提前通过。控件 selector、观察时长、最少样本数、终态边界、非失败推进、末端覆盖、sequence 单调 / 严格推进规则及完整 required assertions 都进入 scenario fingerprint。读取旧 fingerprint 回执和检查 plan liveness 时，把合同升级造成的 fingerprint 不匹配视为 stale missing，允许同一 run 重新执行 `preview.validate` 自愈；身份、路径、digest 或内容完整性篡改仍失败关闭。最终完成门每次按当前合同重算 fingerprint，并严格拒绝旧 fingerprint、旧 assertion 集或仅保存历史 `passed=true` 的证据。
+- 试玩证据展示：game-chat 的进度卡、可玩 revision 和自动预览只接受结构化 `preview.validate` detail 同时满足 `passed=true` 与 `playtestPassed=true`；工具 summary 中的 `：ok` 不能作为兜底。`image.inspect` 的 `status=ok` 只代表工具执行成功，不代表视觉验收通过；结构化 `passed=null` 或缺少布尔结论时，UI 必须以中性“截图分析完成”展示，只有显式 `passed=true` 才能显示“截图检查通过”。
+- 一次性自动预览授权：用户在该入口成功提交本轮自主生成需求，即视为对“当前项目 + 当前 Supervisor 父 run”的一次 `preview.start` 授权。授权以仅含项目路径与 accepted parent runId 的客户端本地记录持久化，App / WebView 重启后仍可恢复，但项目或 run 身份不匹配时不得使用。只有当前 accepted parent run 成功完成 `preview.validate` 且给出有效 revision 后，客户端才可消费授权，由 Tauri 首次启动并自动展示该 revision 的用户可见预览；一次授权最多成功启动一个 Tauri preview server，并必须继续走现有权限、项目写锁、审计和客户端 `PreviewRegistry` 链路。项目或 Agent 策略的显式 deny 始终优先，不得被此授权绕过。启动成功、显式 deny、非瞬时失败、父 run 在首版验证前终止或切换项目后授权失效；`preview.start` 恰逢项目写锁竞争属于瞬时失败，不消费授权，释放写锁后由同一轮询链路重试。
+- 增量预览刷新：Tauri 客户端记录当前 iframe 已展示的 validated revision；同一当前 run 后续成功 `preview.validate` 的 revision 严格高于已展示 revision 时，只在原 Tauri preview server 和原 loopback origin 上刷新 iframe，不得再次调用 `preview.start`、新增 server 或切换到 Runner registry。相同或更低 revision 不触发刷新。preview HTTP server 对 HTML、脚本、样式、资源和错误响应统一发送 `Cache-Control: no-store`，iframe 刷新必须读取新 revision，不能继续命中 WebView 缓存中的旧版本。
+- 退出与 Runner：独立 game-chat release 正常退出 Tauri 事件循环时调用仅供该 flavor 使用的认证 `runner.shutdown_for_client_exit`。Runner 先进入 draining、拒绝新的 Runtime 写请求，再无条件请求结束本 boot；已有 durable task / handoff / retry / reconciliation 状态不得伪装为 completed 或被删除，下次启动按既有 reconciliation 合同恢复。Windows game-chat 客户端以 `CREATE_SUSPENDED` 创建 Runner，在其执行用户代码前立即加入由客户端持有的 `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` Job，严格复核唯一主线程后再恢复运行；分配或恢复失败必须 kill + wait 并令客户端启动失败。Runner 的 command、MCP、Git、PTY 及其它未 breakaway 后代随客户端异常退出或 Job handle 关闭一起终止；Runner 正常退出前仍先执行既有进程会话收束。普通 dev / release 与 CLI 继续使用 `runner.shutdown_if_idle`，不改变共享 Runner 的原生命周期。
+- Windows 后台进程可见性：所有不需要交互控制台的 `command.exec / project.verify`、STDIO MCP、Repository Context Git、`git.inspect / project.git_commit` 和清理用 `taskkill` 必须使用 `CREATE_NO_WINDOW`；需要独立终止边界的命令可同时使用 `CREATE_NEW_PROCESS_GROUP`，不得使用会增加孤儿风险的 `DETACHED_PROCESS`。game-chat release 禁止再打开 launcher、workspace 或其它平行 Tauri 页面。
+- 真实浏览器回归：显式运行 `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml real_chrome_generic_playtest_ --features game-chat-release -- --ignored --nocapture --test-threads=1`，同时用真实 Chrome / Chromium / Edge 证明尚未接受真实 `primary-action` 就瞬时进入 `lost`、以及两次受控尝试都固定 `lost` 的页面必须判失败；首轮合法 `lost`、restart 恢复后第二轮进入 `playing | won` 的页面可以判通过。
+- 系统边界：该页面是既有 AI 游戏创作工作台的独立构建例外，不新增平台玩法入口、后端 API、会话库、Runner 或预览服务，也不把入口并回普通正式客户端。原 `supervisor-chat` 继续固定使用 `standard` profile 并保持纯聊天行为，不继承本例外的自主构建、事件聚合或自动预览授权。
+- 验证要求：每次修改该 flavor 至少执行壳配置门禁、AppSurface game-chat 定向测试、前端类型检查、AppData / 诊断日志 / release flavor 相关 Rust 定向测试、`npm run check:encoding` 和 `git diff --check`；正式打包必须执行 `npm run agc:build:game-chat-release`，安装或启动产物后确认首屏只能进入本地 game-chat、断开或停止 `api-server` 仍可进入工作台、普通/debug 认证未变化、AppData 使用独立 identifier，并分别 smoke“新目录 owner / DACL 正确”“历史 foreign owner 原目录被同级备份且配置不覆盖”“foreign-owner stale `agent-runner.lock` 在独占句柄下立即修复并启动”“活锁不被截断或接管”“reparse point / hardlink 失败关闭”“AppData 不可写时日志回退 TEMP”“`.setup()` 初始化失败显示日志位置对话框”“503 等待态显示真实 HTTP 状态、重试次数和退避秒数”“503 耗尽后状态卡与 conversation 只显示安全摘要”“后台命令执行期间不出现控制台窗口”“启动活跃任务后关闭主窗口，Runner、MCP、command、ConPTY 及孙进程均消失”“再次启动后 durable 状态进入正确 reconciliation”。日志检查必须同时验证 256 KiB 轮转、仅一份 previous、凭据和绝对路径零泄漏。
 
 ## Runtime 边界