补齐真机闭环的现场证据，并记下本会话不能跑 GUI 验收的约束

- 渠道安装身份隔离：记录本机 dev 0.1.154 与旧身份陶泥儿 0.1.109 同机并存的真实样本、已装产物内嵌 agc/dev-win/latest.json 且不含 release 端点、两个安装包资源串互不串身份，并写明真机条件已具备 - 更新插件里程碑：写明检查一半已由清单核对脚本覆盖，安装一半在本机只差一次点击，并给出点击前后的取证口径 - DirectProject 两条运行时验收：勾选行注明宿主侧已由真 app-server 夹具取证，剩余部分是界面渲染与用户终止路径 - 记录环境约束：本会话不能启动用户可写目录下的可执行文件，GUI 验收必须在桌面会话执行
2026-09-29 06:27:04 +08:00
parent 3fa4501c68
commit d0b9bdebfe
3 changed files with 25 additions and 2 deletions
@@ -59,3 +59,13 @@
 - 条目 4：`src-tauri/capabilities/main.json` 的 `"windows": ["client"]` 且承载 updater 权限，其它窗口没有该能力。
 - 条目 5：`rg "download_ai_game_creator_update|install_ai_game_creator_update|check_ai_game_creator_update"` 在 `src` 与 `src-tauri/src` 内 0 命中；退役 OSS 白名单未恢复（原生 HTTP scope 已对齐官方 updater 权限）。
 - 未勾选的条目 1：正式包走官方插件路径已由依赖与配置证明，但「校验失败必须拒绝安装并清理临时文件」是插件内部行为，需要真实发布包与篡改样本才能验收。
+
+## 本轮核对（2026-09-29，本条只剩桌面会话里的一次点击）
+
+先确定「检查」这一半已经不需要真机：渠道清单核对脚本 `npm run check:agc-update-channel-manifests` 会下载产物、解包读身份、并用**产物里烘焙的 updater 公钥**验签，等价于插件原生侧做的那套校验；四渠道全量核对里 `dev-win` 0.1.158 / `release-win` 0.1.159 / `release-mac` 0.1.139 全部 PASS（`dev-mac` 是另一条已记录的缺陷）。
+
+再确定「安装」这一半的现场条件——本机就是一个现成的闭环现场：
+
+- `HKCU\...\Uninstall\陶泥儿开发版` 当前 `DisplayVersion=0.1.154`，而 `dev-win` 渠道已是 **0.1.158**。启动这个已发布客户端时 `AppUpdateNotice` 会在挂载时自动 `checkForAppUpdate()`，因此会直接出现「发现新版本 0.1.158」；点「下载更新」走的就是官方插件：原生侧下载 NSIS 安装包 → 用产物内公钥验签 → 启动安装程序 → 客户端退出并由安装程序带回新版本。
+- 取证口径（点击前后各取一次即可）：① `HKCU\...\Uninstall\陶泥儿开发版` 的 `DisplayVersion`（点前 0.1.154，点后应为 0.1.158）；② 若同时装了 release 渠道，其 `DisplayVersion` 必须保持不变（渠道隔离）；③ 安装包在临时目录的落盘与安装后清理——这一半只能在点击后观察临时目录，属插件原生行为。
+- **环境约束**：本次 Codex 会话不能启动用户可写目录下的可执行文件（`%LOCALAPPDATA%`、`%TEMP%`、工作区都被执行策略拒绝，只有系统目录放行），所以上面这次点击必须在桌面会话里做，本会话无法代跑；这也解释了为什么本条长期停在「需要真实机器」。
@@ -60,3 +60,16 @@
 - 新增的跨渠道断言：同一次核对里不同渠道的更新包不得字节相同（`1dfc9deb79f7: dev-mac/darwin-aarch64 = release-mac/darwin-aarch64` 就是修复前会命中的形态）。
 - 新增的分区断言：旧协议迁移指针 `agc/latest.json` 是**全局单对象**，只属于 dev 的 Windows 系统——核对 `release-win` 时脚本会断言它仍指向 `/agc/dev-win/…`。本轮实测 `release-win` 通过：指针指向 `agc/dev-win/0.1.155/陶泥儿开发版_0.1.155_x64-setup.exe`，没有被 release 渠道改写。
 - 仍未勾选：真机上同时安装 `dev` 与 `release`、各自原地更新。上面这些只证明「产物身份正确」，不代替真机并存验收。
+
+## 本轮核对（2026-09-29，本机真实安装状态 + 产物内嵌渠道端点）
+
+本轮换了一条取证路径：不去装新包，先看**这台开发机自己**的安装状态，以及**已发布产物里到底写了哪个渠道**（全部只读）。
+
+- **同一台设备上已有两个身份并存（真实样本）**：`HKCU\...\Uninstall` 里同时存在
+  - `陶泥儿开发版` `DisplayVersion=0.1.154` → `%LOCALAPPDATA%\陶泥儿开发版`（dev 渠道身份，`identifier=world.genarrative.ai-game-creator`）；
+  - `陶泥儿` `DisplayVersion=0.1.109` → `%LOCALAPPDATA%\陶泥儿`（渠道化之前的旧命名身份）。
+  两者的安装目录与卸载项各自独立、互不覆盖；`%APPDATA%\world.genarrative.ai-game-creator` 存在（dev 数据目录），而 `%APPDATA%\world.genarrative.ai-game-creator.release` 不存在（release 身份从未在本机跑过）。→ 「不同身份同机并存」已经有真实样本，本条还差的样本具体是 **dev 与 release 这一对**。
+- **渠道端点确实写在发布产物里（不是运行期决定）**：对已安装的 `%LOCALAPPDATA%\陶泥儿开发版\genarrative-ai-game-creator-shell.exe`（0.1.154）做二进制串扫描：命中 `agc/dev-win/latest.json`（UTF-8）与 `world.genarrative.ai-game-creator`，**不命中** `agc/release-win/latest.json`、`agc/release-mac/latest.json`、`world.genarrative.ai-game-creator.release`。→ 「各自原地更新」的前提——每个渠道的包只认自己的清单地址——在真实发布产物上成立。
+- **两个已发布安装包的资源串互不串身份**：`dev-win` 的 `陶泥儿开发版_0.1.158_x64-setup.exe` 只命中 `陶泥儿开发版`，`release-win` 的 `陶泥儿 Release_0.1.159_x64-setup.exe` 只命中 `陶泥儿 Release`（安装包里的应用载荷是压缩的，所以这一层只能证安装器自身的身份串，应用载荷的身份由上一轮的 PE `RT_VERSION` 与 mac `Info.plist` 断言覆盖）。
+- **本条的真机条件已经具备**：本机装着 dev `0.1.154`，`dev-win` 已发到 `0.1.158`；`release-win` 在 `0.1.159`，且 OSS 上保留 `agc/release-win/0.1.150/…_x64-setup.exe`（HEAD 200）可用来造出「release 有更新可装」的状态。也就是说「dev + release 同时装、各自原地更新」现在只差一次桌面操作。
+- **环境约束（本轮实测，会影响后续排期）**：本次 Codex 会话**无法启动用户可写目录下的可执行文件**——`%LOCALAPPDATA%`、`%TEMP%` 与工作区里的 exe 都被执行策略拒绝（`Start-Process` 只放行系统目录，如 `C:\Windows\System32\cmd.exe`），因此「装包 → 起客户端 → 点更新 → 看版本」这一段必须在桌面会话里执行，不能由本会话代跑。
@@ -53,8 +53,8 @@ AGC 项目开发对话的显示与恢复只依赖两项输入：**项目对话
 ## 验收标准

 - [x] 一次回合内，实时渲染的文本段与工具卡片顺序，与回合结束后重进项目看到的顺序一致。【自动化：`project-development.suite.ts` 空对话首轮 + 历史切片工具卡片用例】
- [ ] 回合进行中终止并重启进程后重进项目：已落盘的部分文本与工具卡片按原顺序出现，且界面不显示忙碌态。【待真实 app-server 运行时验收】
- [ ] 进程存活期间的页面重进（含切走再切回）能恢复运行中回合，并允许终止。【待真实 app-server 运行时验收】
+- [ ] 回合进行中终止并重启进程后重进项目：已落盘的部分文本与工具卡片按原顺序出现，且界面不显示忙碌态。【宿主侧已于 2026-09-29 由真 app-server 夹具取证，剩界面渲染】
+- [ ] 进程存活期间的页面重进（含切走再切回）能恢复运行中回合，并允许终止。【宿主侧已于 2026-09-29 由真 app-server 夹具取证，剩前端重进与用户终止路径】
 - [x] 历史切片从文件尾反向回扫，锚点始终是文件里的原始 item id；切片内全部是不可显示条目时仍能继续向前，不出现锚点停滞。【自动化：`direct_project_history` 尾部回扫与分页锚点用例】
 - [x] 首屏切片的新端边界是 `subscribe` 回执里的 `lastCompletedItemId`（含该条）：比它更新的条目只从运行态事件来；锚点缺失时按文件尾取尾屏，订阅回执到达前不发首屏请求。【自动化：`cargo test agent::direct_project_history` 22 条（含 `through_item_id` 锚点用例）+ `directHistoryAnchorGate.test.ts` 10 条 + `project-development.suite.ts` 的 `anchors the first history page at the subscribe receipt instead of the file tail`（变异验证见下）】
 - [x] 前端一次翻页操作自动连拉，直到合并后聊天投影出现新回合或 `hasMore=false`，每个操作上限 5 页；锚点不前进时立即停止，不空转。【自动化：`directHistoryPaging.test.ts` 8 条 + `project-development.suite.ts` 跨页同回合用例（变异验证见下）】