Merge branch 'master' into codex/fix-web-preflight-home

docs/project-memory/plans/【里程碑】DirectProject聊天真相源收敛-2026-09-16.md

@@ -81,4 +81,13 @@ 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」，说明第一层已经修通。
-- **仍未完成（第二层）——已定位到 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` 下）外，临时插桩已全部回滚。
+- **第二层已修：CLI / 单回合宿主的收尾不再被记成本轮未完成**。定位过程（都靠插桩，不是推测）：① 不是 codex 版本漂移（换 0.147.0 相同）；② 不是 stdin 被忽略（改 `pipe` 相同）；③ 不是 `Drop for ExecutionBinding`（插桩后一次没打印）；④ app-server 不是崩溃（1242 字节 stderr 全是 ProgramData/模型元数据/PowerShell snapshot 之类 WARN）；⑤ **是宿主自己关的**——关闭原因日志显示 `reason=宿主执行预算或交付收尾`（`execution.rs:938` 的 `shutdown_and_report()` 先置 `closed` 再关 app-server，关进程会给在途回合发 `TransportClosed`）。消费端（`mod.rs:4015`）只看 session 阶段、没看 `closed`，而 `fail_turn()` 内部无论如何都会 `session.interrupt(reason)`，于是正常收尾被改写成 `interrupted`、回执换成「执行通道已断开」。
+  修复：`fail_turn()` 在 `is_closed()` 时只把原因追加进终态说明（新增 `ExecutionSession::append_terminal_note()`），**不改阶段**；用户主动终止与真实通道故障保持原口径。
+  **复验（本里程碑现在有了可复跑的真机证路）**：`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**（真 AGC CLI → 真 app-server → loopback Responses，无账号无付费）；`completed` 的账本 `phase=completed`、`executorStopped=true`，`terminalReport` 变成宿主真实交付报告。定向单测 `codex_app_server::execution` 13 passed、`direct_execution` 26 passed。
+- **再次核对（2026-09-28，同一夹具加 `restart` 用例）**：给 `direct-execution-production-fixture.mjs` 新增 `restart` 场景——受控契约注册 → 一轮里同时下发**部分助手文本**与一个**阻塞的原生工具** → 等工具真的开始（`started.txt` 落盘）后 `SIGTERM` 杀掉 AGC 进程。判据（全部实跑通过，`--cases completed,passes,mcp,mcp-write,native,deadline,restart` → **7/7 passed**）：
+  - 进程确实死在回合进行中：`exit={code:null, signal:'SIGTERM'}`；
+  - `.agent/conversations/project.jsonl` 里 `RESTART-PARTIAL-TEXT` 与工具卡片（`exec_command`）**按原顺序**保留，且被杀的工具卡片是**最后一行**、没有对应回执行（说明它没跑到工具结束之后）；
+  - 宿主没有伪造终态：账本 `phase=working`（不是 `completed`）、`executorStopped=false`；
+  - **变异验证**：把"等 400ms 再杀"改成"等 20s 再杀"（让这一轮自然跑完）后，同一条用例立刻以 `restart: AGC must be killed mid-turn, got {"code":0,"signal":null}` 变红，证明这些断言确实在区分「进行中终止」和「已完成」。
+  - 顺带记录一个事实：CLI / 无前端宿主**不写用户消息**（GUI 是前端先调 `append_direct_project_conversation_message`），所以用例只断言部分文本与工具卡片的顺序；用户消息的持久化属于 GUI 路径。
+- **两条运行时验收仍继续未勾选**：上面这条覆盖了「已落盘的部分文本与工具卡片按原顺序出现、且宿主不假装完成」的宿主侧证据；但判据里的「**界面不显示忙碌态**」「页面重进（含切走再切回）能恢复运行中回合并允许终止」仍要真实客户端窗口，夹具证不了 UI 投影。

docs/project-memory/shared-memory/decision-log.md

@@ -9718,6 +9718,14 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
 - 决策：`build_direct_project_history_injection_params()` 在历史为空时返回 `Ok(None)`，调用方跳过注入（空历史本来就没有可注入内容）；有历史时行为不变（仍按原载荷、原大小前置校验）。
 - 验证：`cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml direct_project_history_wire` → 3 passed（新增「空历史不得构造载荷」「有历史仍构造 1 条」）；同一条夹具命令从「4 秒失败、`requests=[]`」变成「`requests=3`、`markers.ready=true`、AGC exit=0」——但账本仍落 `interrupted`（app-server 收尾连接终止，`stderrBytes=1242`），是另一层问题，未在本次一并修。
 - 影响范围：`apps/ai-game-creator-shell/src-tauri/src/agent/codex_app_server/{direct_project_history_wire.rs,mod.rs}`、`docs/project-memory/shared-memory/pitfalls.md`、DirectProject 里程碑。
+
+## 2026-09-28 宿主自己关掉的连接不能把回合改写成 `interrupted`
+
+- 背景：修掉 DirectProject 空历史注入后，真机夹具（真 AGC CLI → 真 app-server → loopback Responses）6/6 都走到 Provider，但仍统一失败在账本阶段：`phase=interrupted`、CLI 回执是「执行通道已断开，不能自动重放未确认操作」。插桩排除 codex 版本漂移、stdin、`Drop for ExecutionBinding`、app-server 崩溃之后，关闭原因日志给出结论：`reason=宿主执行预算或交付收尾`，来自 `shutdown_and_report()`（`execution.rs:938`）——宿主收尾先置 `closed` 再关 app-server，关进程会给在途回合发 `TransportClosed`；消费端（`mod.rs:4015`）只看 session 阶段、没看 `closed`，而 `fail_turn()` 内部无论如何都调 `session.interrupt(reason)`，于是把正常收尾改写成了失败。
+- 决策：`fail_turn()` 在 `is_closed()`（宿主自己收尾：正常终态、预算与交付收尾）时**只把原因追加进终态说明、不改阶段**，新增 `ExecutionSession::append_terminal_note()`（与 `interrupt()` 同款留痕，但不设 `Interrupted`）；用户主动终止（`host_stop_requested`）与真实通道故障仍按原口径记失败并中断。判据用标志而不是"事件到达先后"，与既有 `fail_turn` 守卫保持一致。
+- 验证：`node apps/ai-game-creator-shell/scripts/direct-execution-production-fixture.mjs --agc-exe <debug exe> --cases completed,passes,mcp,mcp-write,native,deadline` → **6/6 passed**；`completed` 用例账本 `phase=completed`、`executorStopped=true`，`terminalReport` 为宿主真实交付报告（不再是通道断开文案）。`cargo test … codex_app_server::execution` 13 passed（含 `host_ended_turn_is_not_a_failure`、`user_requested_stop_is_not_recorded_as_a_failure`）、`cargo test … direct_execution` 26 passed、`cargo fmt --check`、`cargo build` 通过。
+- 影响范围：`apps/ai-game-creator-shell/src-tauri/src/agent/{direct_execution.rs,codex_app_server/execution.rs,codex_app_server/mod.rs}`、pitfalls、DirectProject 里程碑。GUI 常驻 app-server 不走这条每轮关闭路径，受影响的是 CLI / 单回合宿主（`--direct-codex-chat` 及依赖它的夹具）。
+- 边界：这修的是"宿主收尾被记成失败"，不改变两条 DirectProject 运行时验收仍需真实客户端窗口（UI 忙碌态与页面重进）。
 - 决策（口径回归）：macOS 现行契约是 arm64 单架构（2026-09-21 决策），里程碑里「两个 macOS 平台键指向 universal 产物」的旧文字按现行决策改写；不得据此重新切回 universal，除非按该决策给出的恢复路径补齐按架构的 Node 运行时。
 - 影响范围：`apps/ai-game-creator-shell/scripts/build-macos-ci.mjs`、新增 `apps/ai-game-creator-shell/scripts/macos-release-identity.mjs` 与其 `.test.mjs`、`apps/ai-game-creator-shell/scripts/prepare-macos-codex.test.mjs`、`jenkins/Jenkinsfile.ai-game-creator-shell-macos-build`、`scripts/check-agc-update-channel-manifests.mjs`、两份里程碑与本文件、pitfalls。
 - 验证：`node --test apps/ai-game-creator-shell/scripts/*.test.mjs` → **110 passed / 0 failed**（其中定向批次 `macos-release-identity / prepare-macos-codex / verify-updater-signature / build-release / cargo-features` 60 passed；新增的 mac 身份回归用例直接喂线上那份 0.1.139 release 身份 plist，必须抛错；新增的产物版本守卫用例喂 `_0.1.153_` 残留安装包，必须抛错）；`npm run check:production-ops`、`check:encoding`、`check:doc-index`、prettier、eslint、`git diff --check` 通过；只读核对对线上 `dev-win` 全 PASS（含 158 MiB 产物下载验签与旧协议 sha256 一致），对线上 `dev-mac` 精确报出上面两条 FAIL。

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

@@ -6117,8 +6117,11 @@ 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 回执文本为「执行通道已断开，不能自动重放未确认操作」。
+- **第二层（已修）**：修好第一层后，夹具的全部 6 个用例都走到 loopback Provider，但**统一**失败在账本阶段：`phase=interrupted`（期望 `completed`/`exhausted`），CLI 回执文本是「执行通道已断开，不能自动重放未确认操作」。
 - **已排除的四层**（都靠插桩，不是推测）：① 不是 codex 版本漂移（换成 0.147.0 结果相同）；② 不是 stdin 被忽略（`stdio[0]` 改 `pipe` 结果相同）；③ **不是 `Drop for ExecutionBinding`**（在该分支插桩打印 phase/`background_done`/`closed`，一次都没打印）；④ **app-server 也不是崩溃**（分段打印 stderr 原文，1242 字节全是 `ProgramData known folder 0x80070003`、`Unknown model gpt-5.1-codex`、`powershell shell snapshot` 之类 WARN，没有 panic/error）。
-- **定位到的真正 Killer**：给 `shutdown_game_creator_codex_app_server_inner` 加一行关闭原因日志后，夹具里依次出现 `agent.direct_codex.shutdown reason=宿主执行预算或交付收尾` → `agent.runner.failed: … 连接终止` → （CLI 自己的两次 `shutdown`）。也就是**宿主收尾主动关掉 app-server**：`codex_app_server/execution.rs:938` 的 `shutdown_and_report()` 先 `self.closed.store(true)`、再 `shutdown_game_creator_codex_app_server_inner(inner, "宿主执行预算或交付收尾")`，而后者会给所有在途回合通道发 `CodexTurnEvent::TransportClosed(reason)`（`mod.rs:5207`）。于是**等待中的那一轮**（CLI 单回合宿主就是 CLI 自己的 await）拿到的是「连接断开」，回执变成失败文案、账本落 `interrupted`，尽管这是宿主自己收的尾。修复方向：宿主主动收尾时**先交付回合结果、不要向它发 `TransportClosed`**（或让等待方把「宿主收尾」识别为终态而不是 transport 失败）；注意 GUI 常驻 app-server，不会每轮走这条路径，所以影响面是 CLI / 单回合宿主（`--direct-codex-chat` 与依赖它的夹具），不是用户日常对话。
-- **保留的诊断开关**：关闭原因日志留在 `GENARRATIVE_AGC_DIRECT_DEBUG=1` 下（与既有的 `agent.direct_codex.stderr bytes=` 同一开关），以后排查这类「谁关掉的」问题不用再插桩；其余临时插桩都已回滚。
+- **Killer 定位 + 修复（2026-09-28）**：给 `shutdown_game_creator_codex_app_server_inner` 加关闭原因日志后，夹具里依次出现 `agent.direct_codex.shutdown reason=宿主执行预算或交付收尾` → `agent.runner.failed: … 连接终止`。机制是：`shutdown_and_report()`（`execution.rs:938`）先 `self.closed.store(true)` 再关 app-server，而关进程会给在途回合通道发 `CodexTurnEvent::TransportClosed(reason)`；消费这段事件的 `mod.rs:4015` 只看 `adapter.is_host_ending()`（**看的是 session 阶段，不是 `closed`**），阶段还在 Working 时就调了 `fail_turn()`；而 `fail_turn()` 内部**不管 `closed` 与否都会 `session.interrupt(reason)`**，于是正常的宿主收尾被改写成 `Interrupted`、回执文案变成「执行通道已断开」。
+  修复：①`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 已修）**：`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` 被清掉、六个声明组件与清单/声明保留。