用已安装包现场取证随包 Codex，并收窄 Windows 验收边界

- Mac 客户端随包运行依赖补齐：记录已安装陶泥儿开发版 0.1.154 的载荷完整性（coding-agent/win-x64 六个组件 SHA-256 与 manifest.json 6/6 一致、codex-cli 0.155.1）与随包 app-server 能在 Windows 起来的现场证据 - 说明该包在第一条 direct 回合报 items must not be empty 是 7ec984d0d 已修缺陷的现场复现（0.1.154 源码不含、0.1.158 源码包含，master 同用例通过），剩余验收收窄为安装器实跑 + GUI/Cocos 回归 - pitfalls 新增「用夹具 --agc-exe 直接验证已安装渠道包里的随包 Codex」的做法与判读口径 - 开放事项索引同步该行
2026-09-29 06:42:08 +08:00
parent fdb09db8a3
commit 198c208172
3 changed files with 23 additions and 1 deletions
@@ -40,3 +40,14 @@
 - 类型与配置、编码、文档索引、定向脚本 lint 和 diff 检查通过；139 MiB DMG 完整性通过。
 - 随包 zsh 的原生最低系统为 macOS 15.0；macOS Tauri 最低版本声明随之对齐，不能仅按主程序的 macOS 11.0 下限宣称整包兼容性。
 - Windows NSIS 构建、安装、随包 Codex 与 Cocos 原有能力回归尚待用户测试；其它 Mac、Intel、正式签名/公证和更新签名未验收。保持草稿，不推进合并或发布。
+
+## 本轮核对（2026-09-29，Windows 侧随包依赖现场取证）
+
+有 Jenkins 只读凭据后先确认了一件事：**Windows NSIS 构建本身由 CI 持续产出**（`Genarrative-Agc-Windows-Build` 每次发布都产出 `陶泥儿开发版_<版本>_x64-setup.exe`，并已被渠道清单核对脚本验签、读 PE 身份），所以这一条真正缺的是「装到真机后随包依赖能不能跑」。本机恰好装着 `陶泥儿开发版 0.1.154`（`%LOCALAPPDATA%\陶泥儿开发版`），可以直接取现场证据：
+
+- **随包载荷完整**：安装目录 `coding-agent/win-x64/` 下 6 个声明组件全部在位（`bin/codex.exe`、`bin/codex-code-mode-host.exe`、`codex-path/rg.exe`、`codex-resources/codex-command-runner.exe`、`codex-resources/codex-windows-sandbox-setup.exe`、`codex-package.json`），且**逐文件 SHA-256 与 `manifest.json` 全部一致（6/6）**；`codex-package.json` 声明 `codex-cli 0.155.1` / `layoutVersion=1` / `target=x86_64-pc-windows-msvc`。
+- **随包 Codex 确实能起来**：把已安装的 exe 直接交给仓库夹具当被测对象
+  （`npm run check:agc-direct-execution-fixture -- --agc-exe "%LOCALAPPDATA%\陶泥儿开发版\genarrative-ai-game-creator-shell.exe" --cases completed`），
+  结果是随包 app-server **启动并回了一个 JSON-RPC 错误**：`Codex app-server JSON-RPC 失败：items must not be empty`。也就是说缺的不是随包依赖，而是客户端请求体（`agent.codex_app_server.remote_control disabled reason=provider-proxy-auth` 是夹具本地回环模式的预期行为）。
+- **这是已修缺陷的现场复现，不是新问题**：该报错对应的修复是 `7ec984d0d`（2026-09-28 22:45「修复 DirectProject 空历史注入导致新项目第一条消息失败」）。`0.1.154` 的源码是 `76cdb96c5`（20:52），`git merge-base --is-ancestor 7ec984d0d 76cdb96c5` 不成立；`dev-win` 当前 `0.1.158` 的源码 `e1dacccec5` 包含它。同一条 `completed` 用例在**当前 master 的调试构建**上 PASS，所以差异来自版本而不是构建配置。
+- **对本条验收的含义**：①「随包 Codex 在 Windows 上能起来」已有现场证据；②本机这份 0.1.154 在执行链路上是坏的，**更新到 `dev-win` 当前的 0.1.158 才会恢复**（这次更新同时是「AGC 客户端更新切换到官方更新插件」那条的验收动作）；③仍只能由用户在桌面会话完成的：**NSIS 安装器实跑**（安装 / 卸载 / 覆盖升级）与 **GUI 登录对话 + Cocos 编辑器回归**。
@@ -6153,3 +6153,14 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 - **不能远程拉起的形态**：`genarrative-agc-macos-01` 是 `JNLPLauncher`（inbound WebSocket，`remoteFS=/Users/suzmii/Library/Jenkins/agents/genarrative-agc-macos-local`），只能在那台 Mac 本机把 agent 起回来；Jenkins 侧没有可用入口。所以「macOS 渠道一直没有新版本」这类问题的第一问是：那台 Mac 是否开机、agent 是否在跑。（该节点 2026-09-24 19:54:51 +08:00 起因 `ChannelTermination` 离线，`dev-mac` 的 `latest.json` 因此一直停在 0.1.142。）
 - **离线期间不会产生半成品**：mac 构建在 `// node` 之前就被中止，Post Action 明确「未走到归档阶段时不会有任何产物，也不会写 OSS」；`Jenkinsfile.scheduled-release-trigger` 里给 mac 分支传 `SKIP_IF_SUPERSEDED=true`，节点回来后排队中的旧构建会自行让位。
 - **同时在查的东西**：`dev-mac/0.1.142` 清单指向的是 `0.1.139` 的 release 身份包（构建目录里上一轮的 `<产品名>.app.tar.gz` 残留被扫描式产物选择器挑走）。修复已在 `build-macos-ci.mjs` + `macos-release-identity.mjs` 落地；`npm run check:agc-update-channel-manifests` 现在会自动报出 `bundle=0.1.139 manifest=0.1.142`、身份 release 以及「渠道隔离」下的 `dev-mac = release-mac`（同一 sha256），不需要人工比对。
+
+## 2026-09-29 用夹具直接验证「已安装渠道包里的随包 Codex 能不能跑」（不用开 GUI）
+
+- **做法**：仓库夹具支持把被测对象换成任意 exe，所以可以直接审问某个已安装的渠道包：
+  `npm run check:agc-direct-execution-fixture -- --agc-exe "<%LOCALAPPDATA%\<产品名>\genarrative-ai-game-creator-shell.exe>" --cases completed`
+  它只在临时目录里造项目、起 loopback Provider，跑的是 CLI/执行链路，不改被装的包、不碰 GUI。
+- **判读口径**（把「包坏了」和「客户端逻辑旧了」分开）：
+  - stderr 里出现 `Codex app-server JSON-RPC 失败：…` → 随包 sidecar **已经起来并回了错**，问题在请求体/客户端逻辑，不在随包依赖；`agent.codex_app_server.remote_control disabled reason=provider-proxy-auth` 是夹具本地模式的预期行，不是故障。
+  - 安装目录 `coding-agent/win-x64/manifest.json` 的 6 个 SHA-256 用来证明载荷本身没坏（Windows 侧还有 `codex-package.json` 声明 `codex-cli` 版本）。
+  - 只有在 sidecar 根本起不来时，才会看到缺组件/版本不匹配类报错。
+- **实例**：2026-09-29 用这招查出本机已装 `陶泥儿开发版 0.1.154`（源码 `76cdb96c5`）会在第一条 direct 回合报 `items must not be empty`——那是 `7ec984d0d` 已修、`0.1.158`（`e1dacccec5`）才包含的缺陷；同一条 `completed` 用例在当前 master 的调试构建上通过，因此结论是「装着的版本旧」而不是「打包少东西」。
@@ -13,7 +13,7 @@
 | 需要什么 | 计划 | 未勾选或未验证内容 |
 | --- | --- | --- |
 | macOS 构建节点 | `【里程碑】Mac本机构建节点接入-2026-09-18.md`、`【实施计划】Mac本机构建节点接入-2026-09-18.md` | 本机 Mac 节点接入与网络前置；状态 `accepted-with-open-items` / `preparing-network-required` |
-| Windows 真机 | `【里程碑】Mac客户端随包运行依赖补齐-2026-09-18.md`、`【实施计划】Mac客户端随包运行依赖补齐-2026-09-18.md` | `awaiting-windows-acceptance`：随包依赖在 Windows 侧的安装与运行验收 |
+| Windows 真机（2026-09-29 更新） | `【里程碑】Mac客户端随包运行依赖补齐-2026-09-18.md`、`【实施计划】Mac客户端随包运行依赖补齐-2026-09-18.md` | `awaiting-windows-acceptance` 收窄为：**NSIS 安装器实跑（安装/卸载/覆盖升级）+ GUI 登录对话 + Cocos 编辑器回归**。随包载荷与随包 Codex 运行已于 2026-09-29 用已安装的 `陶泥儿开发版 0.1.154` 现场取证（安装目录 `coding-agent/win-x64` 6 个组件 SHA-256 与 `manifest.json` 全部一致；夹具 `--agc-exe` 指向已安装 exe 证明随包 app-server 能起来并回 JSON-RPC）；同一轮还查出这份 0.1.154 会在第一条 direct 回合报 `items must not be empty`——`7ec984d0d` 已修、`0.1.158` 起包含，需更新客户端才能恢复该链路 |
 | 用户签收 | `【里程碑】Mac通用安装包与构建管线-2026-09-18.md`、`【实施计划】Mac通用安装包-2026-09-18.md` | `awaiting-user-acceptance`：通用安装包与构建管线签收 |
 | macOS 节点 + 真机升级 | `【里程碑】AGC macOS渠道更新落地-2026-09-17.md` | 4 条：`dev-mac` 清单两平台键与可下载一致性、macOS 客户端真实更新（检查/下载/安装/重启）、旧版本升级、未签名或未公证失败关闭 |
 | 真实发布与流水线 | `【里程碑】AGC更新发布管线渠道化-2026-09-17.md`、`【里程碑】AGC客户端更新切换到官方更新插件-2026-09-17.md` | 渠道化：发布后 OSS 三者一致、Jenkins 日志与归档不含私钥；官方插件：篡改包必须拒绝安装并清理临时文件 |