真机夹具加 running 用例：进程存活期间宿主可观测到运行中回合

- direct-execution-production-fixture：新增 running 场景（工具阻塞期间进程存活），轮询宿主账本抓快照，断言 phase=working、active 里恰好一条 kind=execute 在途许可、executorStopped=false；收尾后 phase=completed、active 清空、executorStopped=true，宿主侧条目顺序不变 - 复验：completed,passes,mcp,mcp-write,native,deadline,restart,running 共 8/8 passed - 记录事实：CLI/无前端宿主既无用户消息也无最终助手回复（前端写入），夹具断言只校验宿主侧条目；宿主侧"正在跑"的可观测事实两路径一致 - 文档：DirectProject 里程碑补该轮核对；pitfalls 扩写 CLI 历史只含宿主侧条目这一坑
2026-09-28 23:38:42 +08:00
parent b0d94ed2d9
commit a59329995e
3 changed files with 111 additions and 14 deletions
@@ -6123,5 +6123,5 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
  修复：①`fail_turn()` 在 `is_closed()`（宿主自己收尾）时只把原因追加进终态说明、**不改阶段**，新增 `ExecutionSession::append_terminal_note()`（`interrupt()` 同款写法但不设 `Interrupted`）；用户主动终止（`host_stop_requested`）与真实通道故障仍保持原口径。
  复验（真 AGC CLI → 真 app-server → loopback Responses）：`node apps/ai-game-creator-shell/scripts/direct-execution-production-fixture.mjs --agc-exe apps/ai-game-creator-shell/src-tauri/target/debug/genarrative-ai-game-creator-shell.exe --cases completed,passes,mcp,mcp-write,native,deadline` → **6/6 passed**；`completed` 用例的账本从 `phase=interrupted` 变成 `phase=completed`、`executorStopped=true`，`terminalReport` 变成宿主真实交付报告（「本轮已完成宿主验收…已通过：产物 marker.txt」），不再是「执行通道已断开」。定向单测：`cargo test … codex_app_server::execution` 13 passed、`cargo test … direct_execution` 26 passed。
 - **保留的诊断开关**：关闭原因日志留在 `GENARRATIVE_AGC_DIRECT_DEBUG=1` 下（与既有的 `agent.direct_codex.stderr bytes=` 同一开关），以后排查「谁关掉的」不用再插桩。
- **顺带发现（2026-09-28）**：同一个夹具新增的 `restart` 用例证明——CLI / 无前端宿主**不会把用户消息写进 `.agent/conversations/project.jsonl`**（GUI 是前端先调 `append_direct_project_conversation_message`，所以总有至少一条用户条目）。写依赖"历史里一定有用户消息"的夹具断言前先确认是走 GUI 还是 CLI 路径，否则会得到假失败。
+- **顺带发现（2026-09-28）**：同一个夹具的 `restart` / `running` 用例证明——CLI / 无前端宿主**既不会把用户消息、也不会把最终助手回复写进 `.agent/conversations/project.jsonl`**（两者都由前端调 `append_direct_project_conversation_message` 写入，GUI 因此总有至少一条用户条目）。CLI 路径只落宿主侧条目（中间文本、工具卡片、工具回执），回复文本走 CLI 标准输出。写依赖"历史里一定有用户/助手消息"的断言前先确认是走 GUI 还是 CLI 路径，否则会得到假失败。宿主侧「正在跑」的可观测事实（`phase=working` + `active` 里的 `execute` 许可）两条路径一致，可以放心断言。
 - **顺带记一条环境陷阱（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` 被清掉、六个声明组件与清单/声明保留。