给 app-server 关闭原因加可观测日志并定位 DirectProject 收尾 Killer

- codex_app_server：shutdown_game_creator_codex_app_server_inner 在 GENARRATIVE_AGC_DIRECT_DEBUG=1 下打印关闭原因，避免以后再靠插桩区分「宿主收尾」与「通道自己断了」 - 用该日志定位到：夹具里是宿主自己的 shutdown_and_report（execution.rs:938，reason=宿主执行预算或交付收尾）先置 closed 再关 app-server，关进程给在途回合发 TransportClosed，于是 CLI 回合拿到「连接断开」、账本落 interrupted - 记录修复方向（宿主主动收尾时先交付结果、不向该回合发 TransportClosed）与影响面（CLI / 单回合宿主，GUI 常驻不走这条路） - DirectProject 里程碑与 pitfalls 同步：四层排除结论 + Killer 定位；两条运行时验收继续未勾选
2026-09-28 23:10:59 +08:00
parent a18a6e84b0
commit 8b67efbcff
3 changed files with 10 additions and 2 deletions
@@ -81,4 +81,4 @@ AGC 项目开发对话的显示与恢复只依赖两项输入：**项目对话
 - **缺陷**：全新项目的第一次对话直接失败。夹具 `--cases completed` 下 AGC 进程 4 秒退出、`requests=[]`，stderr 只有 `Codex app-server JSON-RPC 失败：items must not be empty`。根因是 `thread_created` 时无条件发 `thread/inject_items`，而空项目没有 `.agent/conversations/project.jsonl`，载荷成了 `items: []`；codex app-server 0.155.1 起把空数组当协议错误。GUI 路径没暴露是因为前端会先写用户消息，CLI / 无前端宿主是裸的。
 - **修复**：`build_direct_project_history_injection_params()` 在历史为空时返回 `Ok(None)`，调用方跳过注入；新增单测「空历史不得构造载荷」「有历史仍构造 1 条」。`cargo test … direct_project_history_wire`（3 passed）与 `cargo fmt --check` 通过。
 - **复验**：同一条命令下夹具从「4 秒失败」变成「走到 loopback Provider：`requests=3`、`markers.ready=true`、AGC exit=0」，说明第一层已经修通。
- **仍未完成（第二层）**：修好第一层后，夹具的**全部 6 个用例**都走到 loopback Provider（`requests=3`、`markers.ready=true`、exit=0），但统一失败在账本阶段——`phase=interrupted`（期望 `completed`/`exhausted`），stderr 为 `agent.runner.failed: Codex app-server 连接终止 … stderrBytes=1242`，CLI 回执是「执行通道已断开，不能自动重放未确认操作」。本轮用插桩排除三层：① 不是 codex 版本漂移（换 0.147.0 结果相同）；② 不是 stdin 被忽略（改 `pipe` 结果相同）；③ 不是 `Drop for ExecutionBinding` 的补刀（插桩后一次都没打印）；④ app-server 也不是崩溃（打印出来的 1242 字节全是 ProgramData/模型元数据/PowerShell shell snapshot 之类 WARN，没有 panic/error）。结论：现象是「app-server 被宿主优雅关掉，回合收尾却按连接断开处理」，下一步插桩点应在宿主侧关闭 stdin / kill 子进程的代码（`shutdown_game_creator_codex_app_servers`、prefetch 收尾、runner 生命周期）。**两条运行时验收本质上要真实客户端窗口**（夹具只能证历史持久化，证不了「界面不显示忙碌态」），因此继续未勾选；插桩代码已全部回滚。
+- **仍未完成（第二层）——已定位到 Killer**：修好第一层后夹具的**全部 6 个用例**都走到 loopback Provider（`requests=3`、`markers.ready=true`、exit=0），但统一失败在账本阶段（`phase=interrupted`，期望 `completed`/`exhausted`；CLI 回执是「执行通道已断开，不能自动重放未确认操作」）。排查结论：① 不是 codex 版本漂移（换 0.147.0 相同）；② 不是 stdin 被忽略（改 `pipe` 相同）；③ 不是 `Drop for ExecutionBinding`（插桩后一次没打印）；④ app-server 不是崩溃（1242 字节 stderr 全是 ProgramData/模型元数据/PowerShell snapshot 之类 WARN）；⑤ **是宿主自己关的**——关闭原因日志显示 `reason=宿主执行预算或交付收尾`，来自 `codex_app_server/execution.rs:938` 的 `shutdown_and_report()`：它先置 `closed` 再关 app-server，而关进程会给在途回合通道发 `TransportClosed`，于是等待中的 CLI 回合拿到"连接断开"、账本落 `interrupted`。修复方向：宿主主动收尾时先交付回合结果、不向该回合发 `TransportClosed`（GUI 常驻 app-server，不走这条路径，影响面是 CLI / 单回合宿主与依赖它的夹具）。**两条运行时验收本质上要真实客户端窗口**（夹具只能证历史持久化，证不了「界面不显示忙碌态」），因此继续未勾选；除关闭原因日志（留在 `GENARRATIVE_AGC_DIRECT_DEBUG=1` 下）外，临时插桩已全部回滚。