用已安装包现场取证随包 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」的做法与判读口径
- 开放事项索引同步该行

docs/project-memory/shared-memory/pitfalls.md

@@ -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 的调试构建上通过，因此结论是「装着的版本旧」而不是「打包少东西」。