插桩排除 DirectProject 宿主收尾的两个候选原因

- 在 Drop for ExecutionBinding 分支插桩后一次都没打印：账本 interrupted 不是它补的 cancel_from_host - 临时打印 app-server stderr 分段原文：1242 字节全是 ProgramData/模型元数据/PowerShell shell snapshot 告警，没有 panic/error，说明子进程是被优雅关掉的 - 结合上一轮的「不是 codex 版本漂移、不是 stdin 被忽略」，记录下一步插桩点应落在宿主侧关闭 stdin / kill 子进程的代码；所有插桩已回滚，工作树保持干净 - DirectProject 里程碑与 pitfalls 同步该结论，两条运行时验收继续未勾选（本质要真实客户端窗口）
2026-09-28 23:04:26 +08:00
parent 90a414ebf3
commit a18a6e84b0
2 changed files with 2 additions and 2 deletions
@@ -6113,5 +6113,5 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 - **根因**：`codex_app_server/mod.rs` 在 `thread_created` 时无条件调用 `thread/inject_items`，载荷由 `build_direct_project_history_injection_params()` 从 `.agent/conversations/project.jsonl` 构造；**全新项目该文件不存在 → `items: []`**，而 codex app-server 0.155.1 起把空数组当协议错误拒绝。GUI 路径之所以没暴露：前端会先调 `append_direct_project_conversation_message` 把用户消息写进历史，注入时至少有 1 条；`--direct-codex-chat` 这类无前端宿主（以及任何直接调用 `run_direct_game_creator_turn_at` 的夹具/CLI）没有这一步。
 - **处理（2026-09-28 已修）**：`build_direct_project_history_injection_params()` 在历史为空时返回 `Ok(None)`，调用方跳过 `thread/inject_items`；新增两条单测（空历史不得构造载荷、有历史仍构造 1 条）。
 - **复验**：同一条夹具命令下，AGC 进程从「4 秒失败、`requests=[]`」变成「走到 loopback Provider、`requests=3`、`markers.ready=true`、exit=0」——第一层缺陷确实修掉了。
- **仍未解决（第二层，另一个问题）**：同一个夹具的全部 6 个用例（`completed/passes/mcp/mcp-write/native/deadline`）在修好第一层后都走到 loopback Provider，但**统一**失败在账本阶段：`phase=interrupted`（期望 `completed`/`exhausted`），stderr 为 `agent.runner.failed: Codex app-server 连接终止 … exitStatus=unknown；stderrBytes=1242`，CLI 回执文本为「执行通道已断开，不能自动重放未确认操作」。本轮已排除两种可能：① 不是 codex 版本漂移——把 `resources/codex/win-x64/bin/codex.exe` 换成 0.147.0（仓库里那份 root 残留）后结果完全相同；② 不是 stdin 被忽略——把夹具的 `stdio[0]` 从 `ignore` 改成 `pipe` 后同样 `interrupted`。定位到的可疑路径是主机收尾竞态：`agent/codex_app_server/execution.rs:70` 的 `Drop for ExecutionBinding` 在 `!background_done && !closed` 时补一次 `cancel_from_host()`，而该函数（`execution.rs:706-716`）会写「本轮已由宿主终止；正在收束执行器，未完成项保留。」——账本里的 `terminalReport` 正是这句；同文件 `execution.rs:750` 的通道断开处置又会先记一条 transport 失败事实。下一步要动它得先做插桩（抓 app-server 的 stderr 原文、给 Drop 与 transport 记账加时序日志），不要在没插桩前猜着改守卫。
+- **仍未解决（第二层，另一个问题）**：同一个夹具的全部 6 个用例（`completed/passes/mcp/mcp-write/native/deadline`）在修好第一层后都走到 loopback Provider，但**统一**失败在账本阶段：`phase=interrupted`（期望 `completed`/`exhausted`），stderr 为 `agent.runner.failed: Codex app-server 连接终止 … exitStatus=unknown；stderrBytes=1242`，CLI 回执文本为「执行通道已断开，不能自动重放未确认操作」。已排除：① 不是 codex 版本漂移（换成 0.147.0 结果相同）；② 不是 stdin 被忽略（`stdio[0]` 改 `pipe` 结果相同）；③ **不是 `Drop for ExecutionBinding`**——在该分支插桩（打印 phase/background_done/closed）后一次都没打印，说明账本 `interrupted` 不是它补的 `cancel_from_host()`；④ **app-server 也不是崩溃退出**——临时把 stderr 分段原文打印出来后，1242 字节全是良性告警：`Failed to resolve ProgramData known folder … HRESULT 0x80070003`、`Unknown model gpt-5.1-codex is used`、`Failed to create shell snapshot for powershell`，没有任何 panic 或 error。所以现象是「app-server 被宿主优雅关掉/主动退出，而回合收尾却按连接断开处理」。下一步的插桩点应该落在**宿主侧谁关掉子进程 stdin / 谁 kill 子进程**（`shutdown_game_creator_codex_app_servers`、prefetch「项目预取」收尾、runner 生命周期），不要在 Drop 或协议层继续猜。以上插桩都已回滚，工作树保持干净。
 - **顺带记一条环境陷阱（2026-09-28 已修）**：`apps/ai-game-creator-shell/src-tauri/resources/codex/win-x64/` 下曾有两个 codex 二进制——`bin/codex.exe` 是**真正被解析**的那份（0.155.1），而包根目录那份 `codex.exe` 是 0.147.0 的旧残留（tauri 的 Windows 资源映射只引用 `bin/` 等路径），检查都查不出来，却会让本地核对误判「应用跑的是 0.147.0」。根因是 `src-tauri/build.rs` 的 `stage_codex_target()` 只按布局拷贝、从不清理目录，旧布局的组件会永久留在随包资源目录里。现在加了 `prune_stale_codex_components()`：拷贝前删掉不在本轮布局、也不在 `manifest.json`/`NOTICE.md` 白名单里的文件并收掉空目录；实测重建后根目录 `codex.exe` 被清掉、六个声明组件与清单/声明保留。