合并 origin/master（33 个提交）：DirectProject 入队化与事件投影

- 合并 origin/master（425fbcf63..9ee34809b），唯一冲突是共享决策日志两侧各插条目，取「两侧并存」 - 本轮 master 未触及随包资源声明、准备步骤与三份 tauri 配置，build.rs 只读校验保持不变 - 决策日志与踩坑记录同步两侧条目；docs/README.md 与项目索引按 master 收敛 - 构建期重新生成的 ts-rs 绑定经 prettier 归一后与 master 逐字节一致（合并未丢类型） - 校验：cargo test --no-run 全 target 通过、AGC 应用 vitest 191 files / 1889 tests passed、check-package-layout、prepare-bundled-resources 18 passed、check-config、check:encoding、prettier、cargo fmt --check 全绿
2026-09-30 17:38:35 +08:00
parent b5a143c04f 9ee34809be
commit 8be75e8e15
90 changed files with 5473 additions and 5291 deletions
@@ -95,4 +95,4 @@ AGC 项目开发对话的显示与恢复只依赖两项输入：**项目对话
  - 宿主确实对外发布「这一轮正在跑」：快照 `phase=working`、`active` 里恰好一条 `kind=execute` 的在途许可、`executorStopped=false` —— 这正是界面重进时判断「有运行中回合可恢复/可终止」读的事实；
  - 收尾后账本落 `completed`、`active` 清空、`executorStopped=true`；宿主侧落的条目（中间文本 → 工具卡片 → 工具回执）顺序不变。
  - 顺带记实：CLI / 无前端宿主的历史里**既没有用户消息、也没有最终助手回复**（两者都由前端 `append_direct_project_conversation_message` 写），CLI 只有宿主侧条目与回执文本；夹具断言据此只校验宿主侧条目。
- **可复跑入口（2026-09-29）**：新增 `npm run check:agc-direct-execution-fixture`（`scripts/run-agc-direct-execution-fixture.mjs`）——默认用工作区 `src-tauri/target/debug` 里的 AGC 二进制跑**全部 11 个用例**（`completed / passes / mcp / mcp-write / native / native-resources / patch / deadline / native-session / restart / running`），也支持 `-- --cases <子集>` 与 `-- --agc-exe <path>` 透传。本轮实跑：**11/11 passed**（修复前这些用例要么根本到不了 Provider，要么统一卡在账本阶段）。这样这条真机证路不再需要手打长命令，后续改 DirectProject/执行许可链路可以直接拿它当判据。
+- **可复跑入口（2026-09-29）**：新增 `npm run check:agc-direct-execution-fixture`（`scripts/run-agc-direct-execution-fixture.mjs`）——默认用工作区 `src-tauri/target/debug` 里的 AGC 二进制跑**全部 11 个用例**（`completed / passes / mcp / mcp-write / native / native-resources / patch / deadline / native-session / restart / running`），也支持 `-- --cases <子集>` 与 `-- --agc-exe <path>` 透传。本轮实跑：**11/11 passed**（修复前这些用例要么根本到不了 Provider，要么统一卡在账本阶段）。这样这条真机证路不再需要手打长命令，后续改 DirectProject/执行许可链路可以直接拿它当判据。**（该入口与它服务的夹具已随 `--direct-codex-chat` CLI 退役一并删除，见 09-24 实施计划第 4 步；本段记的是当时的原命令与结果。）**
@@ -47,7 +47,8 @@

 - **随包载荷完整**：安装目录 `coding-agent/win-x64/` 下 6 个声明组件全部在位（`bin/codex.exe`、`bin/codex-code-mode-host.exe`、`codex-path/rg.exe`、`codex-resources/codex-command-runner.exe`、`codex-resources/codex-windows-sandbox-setup.exe`、`codex-package.json`），且**逐文件 SHA-256 与 `manifest.json` 全部一致（6/6）**；`codex-package.json` 声明 `codex-cli 0.155.1` / `layoutVersion=1` / `target=x86_64-pc-windows-msvc`。
 - **随包 Codex 确实能起来**：把已安装的 exe 直接交给仓库夹具当被测对象
-  （`npm run check:agc-direct-execution-fixture -- --agc-exe "%LOCALAPPDATA%\陶泥儿开发版\genarrative-ai-game-creator-shell.exe" --cases completed`），
+  （当时的命令是 `npm run check:agc-direct-execution-fixture -- --agc-exe "%LOCALAPPDATA%\陶泥儿开发版\genarrative-ai-game-creator-shell.exe" --cases completed`；
+  该入口与夹具已随 `--direct-codex-chat` CLI 退役删除，见 09-24 实施计划第 4 步），
  结果是随包 app-server **启动并回了一个 JSON-RPC 错误**：`Codex app-server JSON-RPC 失败：items must not be empty`。也就是说缺的不是随包依赖，而是客户端请求体（`agent.codex_app_server.remote_control disabled reason=provider-proxy-auth` 是夹具本地回环模式的预期行为）。
 - **这是已修缺陷的现场复现，不是新问题**：该报错对应的修复是 `7ec984d0d`（2026-09-28 22:45「修复 DirectProject 空历史注入导致新项目第一条消息失败」）。`0.1.154` 的源码是 `76cdb96c5`（20:52），`git merge-base --is-ancestor 7ec984d0d 76cdb96c5` 不成立；`dev-win` 当前 `0.1.158` 的源码 `e1dacccec5` 包含它。同一条 `completed` 用例在**当前 master 的调试构建**上 PASS，所以差异来自版本而不是构建配置。
 - **对本条验收的含义**：①「随包 Codex 在 Windows 上能起来」已有现场证据；②本机这份 0.1.154 在执行链路上是坏的，**更新到 `dev-win` 当前的 0.1.158 才会恢复**（这次更新同时是「AGC 客户端更新切换到官方更新插件」那条的验收动作）；③仍只能由用户在桌面会话完成的：**NSIS 安装器实跑**（安装 / 卸载 / 覆盖升级）与 **GUI 登录对话 + Cocos 编辑器回归**。
@@ -8972,7 +8972,7 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
 - 决策（队列与埋点听回合终态，不听命令返回）：前端发送队列的放行改由"回合完成（终态事件）或接单被拒"驱动，reducer 新增 `completedTurnCount` 作为唯一判据——不能用 `turnRunning` 的下降沿，一轮可能同批开始 + 结束。埋点结算同样挂到回合终态：不能在接单返回时结算，成绩是回合末才入 `pending_runs`，提前结算会变成空操作；`runTurn` 返回"是否接单"，接单失败的路径只清句柄、不结算。**加 TODO：这条队列以后挪到 Rust 端，落点就是 Thread Manager 的接单动作。** 首页"运行中的项目"快照改由 TM 的逻辑回合导出，任务侧不再单独维护一张表。
 - 决策（认证失败不再重跑整轮）：删掉 `withDirectCodexSessionRefresh` 的"刷新 + 重跑整轮"（重跑会重复落盘用户消息），登录态失效按普通回合失败呈现；用同一个包装的 `cancel_direct_codex_turn` 一并去掉。
 - 决策（失败原因本轮不落历史）：失败原因只走事件载荷与宿主诊断（`.agent/runtime/errors` + 应用日志 + 错误上报池由宿主投影写出，进池责任从前端 catch 移到宿主），不写进 `project.jsonl`——重进项目只会看到那条没有回复的用户消息。**加 TODO（暂定做法见 ADR 备选方案第 3 条 (b)）：以后要做"进历史但不喂模型"的失败条目，本轮明确不持久化。**
- 决策（CLI 保持 await）：CLI 入口（`cli.rs` 的 `direct-codex.chat`）继续 await 整轮，因为它要把回复文本打到终端、没有事件订阅可用；两个入口共用同一份接单前检查、同一个命令主体和同一份 `Display` 文案，不各写一套判据。
+- 决策（CLI 保持 await）：CLI 入口（`cli.rs` 的 `direct-codex.chat`）继续 await 整轮，因为它要把回复文本打到终端、没有事件订阅可用；两个入口共用同一份接单前检查、同一个命令主体和同一份 `Display` 文案，不各写一套判据。**（口径修正：本条已作废——2026-09-24 的 `--direct-codex-chat` 退役把 CLI 入口整个删掉，DirectProject 只剩「入队」一个命令入口；见本文件同日「命令入队化」那条与 `【ADR】DirectProject命令入队化与待发消息队列归宿主-2026-09-24`。）**
 - 明确不做：不给失败载荷加字段（不加 `detailRef`）；不恢复 invoke 拒绝通道，也不为"接单后的前置失败"新增事件类型；本轮不做"失败条目进历史但不喂模型"（TODO）、不做 Rust 端发送队列（TODO）。
 - 影响范围：`apps/ai-game-creator-shell/src-tauri/src/agent/{direct_turn_accept.rs,direct_thread_manager.rs,direct_thread_wire.rs,direct_turn_error.rs,direct_turn_failure.rs,direct_project_context.rs,direct_runtime/{mod.rs,user_input.rs},codex_app_server/mod.rs,runtime_driver/entrypoints.rs,cli.rs}`、前端 `chat/{controller/useDirectProjectChatController.ts,controller/useDirectProjectTurnStatus.ts,controller/useDirectThreadChatSubscription.ts,conversation/directCodexConversation.ts,conversation/directThreadChat.ts,conversation/directTurnPresentation.ts}`、`chat/generated/{DirectTurnError,DirectTurnRejection,DirectThreadEvent,...}.ts` 与 `tests/{directThreadChat.test.ts,appSurface/*.suite.ts}`；文档 `docs/adr/【ADR】DirectProject命令接单化-2026-09-23.md`、`docs/technical/【实施计划】DirectProject命令接单化-2026-09-23.md`、`docs/technical/【技术方案】DirectProject Codex原始历史与异常恢复-2026-09-04.md` 与 `docs/adr/【ADR】DirectProject对话历史单一事实源-2026-09-16.md`。
 - 已知坑：`cargo test export_bindings` 会重写全部 `chat/generated/`（引号风格漂移），跑完要 `git checkout --` 掉不是本次新增的文件；本机 rust 全量 `--bins` 测试会挂在 mock server 的 `inet_csk_accept` 上，用 `--bins "agent::"` 之类过滤跑。
@@ -9108,6 +9108,105 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
 - 影响面：`apps/ai-game-creator-shell/src-tauri/build_support/{package-layout.json,package-layout.generated.rs,package_layout.rs,godot_bundle.rs}`、`src-tauri/build.rs`、`scripts/{prepare-bundled-resources.mjs,prepare-bundled-resources.test.mjs,check-package-layout.mjs,build-release.mjs}`、两份 `.taurignore`、技术方案 §4.9/§8、M3 里程碑、运维文档、决策日志与排障经验。
 - 验证：准备步骤 13 条用例通过（含三类准备步骤调度、指纹跳过、缺产物失败关闭、幂等与失败关闭）；`npm run agc:bundled-resources:check` 通过；`cargo check --no-default-features` 通过（构建脚本仅剩只读校验，且不再出现在随包资源的写入路径上）。
 - 边界（未验证）：Windows 真机未验证——powershell/cargo 两条命令路径、Unity/Godot/Cocos 产物归位、包内容一致性与客户端加载，需按 M3 里程碑的验收清单在 Windows 上确认。
+## 2026-09-24 命令入队化与待发消息队列归宿主：放行归 Thread Manager，CLI 直连入口退役
+
+- 决策（词表）：「接单 / 拒单」退役，命令边界的成功与失败改叫「入队 / 入队失败」；旧「接单」的语义角色
+  （这一轮真正成立的那一刻）改叫「放行」。所以旧句"接单成立 ⇔ 事件流里有开始有结束"改成"放行成立 ⇔ …"，
+  逐处按角色改、不做字面替换；`features/agent-runtime` 的"拒单文案"属另一个域，改"请求被拒"。
+- 决策（命令 = 入队）：`chat_with_game_creator_direct_codex` 改义改名（暂定 `enqueue_direct_codex_turn`），
+  把今天"接单前"那条检查链原样跑完（身份 → 工作流恢复 → 用户条目校验 → prompt 投影 → 前置条件 → 工程准备），
+  通过后只入队：不登记占用、不落盘用户条目、不发回合事件、不起 codex；失败走命令返回的 typed 载荷
+  （`DirectTurnRejection` → `DirectTurnEnqueueFailure`）。入队按 `clientTurnId` 幂等（判重范围 = 在队 ∪ 在跑）。
+- 决策（队列归 Thread Manager）：每项目一条 FIFO，只支持按顺序追加与按身份移除；队列的成员与顺序就是事件列表本身
+  （`queue.enqueued` 在队期间不可回收、离开队列后可回收），`subscribe` 的 live-set bootstrap 因此天然把当前队列
+  交给中途加入的订阅者；上限 5 只数在队条目，由 Rust 持有。
+- 决策（线上形状）：`queue.enqueued{clientTurnId,userItem,creationType?,at}` + `queue.removed{clientTurnId,reason}`，
+  `reason` 是 ts-rs 导出的 typed 枚举（`cancelled|dispatched`），不用字符串；事件不带 prompt——
+  prompt 是入队检查的产物，只留在宿主的队列条目里。
+- 决策（放行）：Thread Manager 在回合收口之后原子地「取队首 → 登记占用 → `turn.started` + `queue.removed{dispatched}`」，
+  再落盘用户条目、下发用户条目、起整轮。**放行不重跑检查、不存在放行失败**，放行之后的一切失败都是回合失败，
+  走既有 `turn.completed.failure`，不新增通道。kick 点 = 回合任务收尾（含 drop 守卫盖 panic）+ 中止路径 + 入队之后，
+  幂等且在临界区里认领队首；入队不取 `DirectTaonierActiveInvocationGuard`（它必须整轮持有，是这一轮的调用身份）。
+- 决策（前端）：不再持有队列副本，chip 只由事件投影，入队失败只由命令返回值给反馈（保留提示文案与"不丢草稿"）。
+  **（落地修正，2026-09-24）**：埋点句柄仍由前端在入队那一刻生成并随命令交给宿主（放行不重算，与其它入队检查产物一起
+  存进队列条目），前端把句柄按 `clientTurnId` 存成一张表、回合终态按本轮开口条目的 canonical 身份认领结算；
+  "不丢草稿"由「提交等命令的入队结果、只有用户自己能改的入队失败才返回 false」实现（不再是"宿主在放行时开句柄"）。
+- 决策（顺带退役）：`--direct-codex-chat` 整个退役——它唯一的实际消费者是手工夹具
+  `scripts/direct-execution-production-fixture.mjs`（PR #439 引入、不在 CI、无 npm/harness 注册、无测试钉它），
+  夹具一并退役。**（落地修正，2026-09-24）**：`TurnAlreadyRunning` 的最后一个生产点在调用身份守卫里
+  （占用登记那条早已随入队化消失），所以它连同前端"同一轮消息仍在处理中"分支一起放到**守卫清理那一步**再删。
+  `DirectTaonierActiveInvocationGuard` 的身份与 Thread Manager 的 `active_turn.turn_id` 是同一件事的两份记录，
+  CLI 退役后让那五个读者改读 Thread Manager，再在第二步删掉守卫与它的 60 秒卡死兜底
+  （删前必须保住"回合卡死可被取消解开"这条由 `d833ca9d3` 事故换来的保证）。
+  **（落地，2026-09-30）**：见下方 09-30 条，守卫已删、`TurnAlreadyRunning` 已删，60 秒闸门改挂
+  Thread Manager 的占用登记年龄。夹具的一键入口 `scripts/run-agc-direct-execution-fixture.mjs` 与
+  `npm run check:agc-direct-execution-fixture`（09-29 新增，只把 `--agc-exe` 默认成工作区 debug 二进制）
+  同样没有任何现役消费者，随夹具一并摘掉。
+- 代价：入队即写盘（引用 UI 设计文档的条目会生成 `ui/generated-<stem>.js`，取消不撤）；检查是时间点事实、
+  放行不重跑（manifest / 权限 / 目录变化后照旧放行，偏差落到回合失败）；队列随进程消失，不做跨进程持久化；
+  失去"真实二进制驱动执行层生产验证"这条手工路径。
+- 验证方式：设计见 `docs/adr/【ADR】DirectProject命令入队化与待发消息队列归宿主-2026-09-24.md` 与
+  `docs/technical/【实施计划】DirectProject命令入队化与待发消息队列归宿主-2026-09-24.md`；落地提交与验证证据
+  见下方 2026-09-30 三条，以及该实施计划的「落地进度」与「2026-09-30 收口记录」。
+
+## 2026-09-30 守卫清理前置判据核实：取消兜底不需要新增无条件终态，60 秒闸门改挂占用登记年龄
+
+- 背景：按 09-24 ADR §9 的计划，删 `DirectTaonierActiveInvocationGuard` 前必须确认"回合任务 park / 泄漏时，
+  取消仍能清空占用并让队列继续放行"。查 git 历史（`d833ca9d3` / `ab970b9fd`）与当前实现后确认：
+  `cancel_direct_codex_turn_at` 的兜底路径本来就同时做三件事——释放占用、往事件流补一条
+  `turn.completed{aborted}`（否则前端会永远停在运行中）、调 `complete_direct_thread_turn` 解除占用并踢队列。
+  所以删守卫**不需要**新增"取消路径补无条件终态"，那是当时就有的东西，不是守卫带来的。
+- 决策：守卫只在两件事上是独有的——(1) 它是"这一轮是谁"的第二份进程内记录（与 Thread Manager 的
+  `active_turn.turn_id` 同源），CLI 退役后已无第二个入口，按"同一件事只许有一处真相"删；
+  (2) 它的 60 秒启动窗口闸门（防"刚放行、还在本地准备的回合被终止误伤"）保留，改挂在 Thread Manager
+  的占用登记年龄上：`direct_stale_turn_for_release(root, expected, reason)` 只在
+  `NeverReachedExecutor` 时校验年龄（`DIRECT_STALE_TURN_RELEASE_MIN_AGE_MS`），返回身份；释放本身仍由
+  既有的 `complete_direct_thread_turn` + `kick_direct_queue_dispatch` 完成（天然幂等）。
+- 决策：连接死亡的失败事实由 app-server 连接层自己落地（`ab970b9fd`），与守卫无关，删除守卫不动那条链路。
+- 落地（`direct_runtime/mod.rs` 删守卫表与只读探测，改 `direct_active_turn_id_at`；`direct_thread_manager.rs`
+  补 `DirectTurnIdentity` + `read_direct_turn_identity`；`codex_app_server/mod.rs` 兜底目标改
+  `DirectStaleTurnReleaseReason` 并接 `direct_stale_turn_for_release`；五个身份读者与相关测试改写；
+  `direct_turn_dispatch.rs` 不再另取调用身份；删 `DirectTurnError::TurnAlreadyRunning` 与前端分支 / 生成绑定）。
+- 验证：`cargo test --bin genarrative-ai-game-creator-shell -- agent::direct`（370 passed）；新增
+  `stale_cancel_releases_the_occupancy_and_dispatches_the_next_pending_turn` 与两条 `direct_stale_turn_for_release`
+  单测；`npx vitest run tests/appSurface.test.ts`（214 passed / 9 skipped）、`directThreadChat` /
+  `directTurnPresentation` / `project-conversation` 定向用例、`npm --workspace apps/ai-game-creator-shell run typecheck`、
+  `npm run check:encoding`、`git diff --check`。
+
+## 2026-09-30 待发消息条目不再另存产物：队列成员由事件折出，prompt 改为条目重投影
+
+- 背景：09-24 落地时给 `StoredEvent` 加了一个"挂着的队列条目"字段（`Option<PendingDirectTurn>`，
+  归位后是 `agent/thread_manager/mod.rs` 的 `StoredEvent.pending: Option<PendingTurn>`），条目上带七个字段。
+  复核发现其中 `client_turn_id` / `user_item` / `creation_type` / `at` 与 `queue.enqueued` 的载荷是同一份事实的第二份拷贝，
+  `canonical_user_item` 是 `serde_json::to_value(user_item)`（第三份），而这两项在构造事件之后再没被读过；
+  `Some/None` 同时兼着"宿主产物袋"与"在队标记"两职，于是取消 / 放行要写两处事实、回收规则还要加"产物还在就不许回收"的防御。
+  与该 ADR §3 写的"队列的成员与顺序就是事件列表本身"已经不一致。
+- 决策（队列成员）：删掉 `StoredEvent.pending`（`append_inner` 并入 `append`）；在队条目 = 事件窗口里"有 `queue.enqueued`、
+  且还没有配对 `queue.removed`"的那些事件，按事件顺序即队首到队尾。判重、容量、取消、认领、bootstrap 全部改读这一次折叠，
+  `mark_queue_events_cleanable` 删掉产物防御。
+- 决策（prompt）：不另存整条 prompt。引用 part 的解析文本（素材摘要 + 引用 UI 设计文档时要展开的代码上下文，
+  后者渲染会往项目里写 `ui/generated-*.js`）由入队检查写进该 part 自己的 `resolved_text`，**随条目持久化**：
+  放行、历史回读、turn input 三个读点共用这一份，历史因此回放出当初那条消息（字段缺省合法、旧历史照样解析，
+  只是在缺省时才退回按当前 manifest 现算）。投影拆成两半：入队侧的 `freeze`（校验 + 算片段 + 写盘 + 冻结 + 判空）
+  与放行侧的纯折叠（零 IO、零校验、无失败出口），于是"放行不重跑任何检查、没有放行失败"这条不变式对新形状仍然成立。
+  `canonical_user_item` 同理改为放行时 `serde_json::to_value(user_item)` 重投影。
+  副作用：引用的代码上下文片段不再统一追加在 prompt 末尾，而是跟在它所属的引用片段里，单条引用时逐字节不变。
+- 决策（埋点成绩）：`analyticsAttemptId` 那条链整条退役，不换字段存。入队化之后一次发送只有一次尝试，
+  "哪一次算数"不再是渲染侧才知道的事；宿主在**放行**那一刻读一次 `platform_session` 的 `identity_generation`、
+  回合终态再读一次，变了就整条不记，成绩直接写终态（不再先写候选、等渲染侧 `settle`）。
+  于是 `analyticsAttemptId` 命令参数、候选表 `pending_runs`、`settle_direct_run_analytics`、前端
+  `beginDirectRunAnalytics` 与句柄表一起删，`queue.enqueued` 也不需要埋点字段。判据口径随放行搬家：
+  从"发送时与终态同代"改成"放行时与终态同代"——入队后、放行前发生的账号切换不再丢弃这一轮的成绩。
+- 落地（`2b98b022c` 文档 → `15a495dc2` `resolved_text` 与 prompt 拆 freeze / 纯折叠 → `0270cd601` 埋点归宿主
+  → `28b64cf25` 条目改事件投影）：`PendingTurn` 只留 `client_turn_id` / `user_item` / `creation_type` / `at` 并配
+  `from_event` / `enqueued_event` 往返；`StoredEvent` 上没有队列字段，`pending_turns` 一次折叠出成员与顺序；
+  `freeze_direct_codex_user_item` 是入队侧唯一算片段 / 写盘处，`direct_codex_user_item_to_prompt(&item)` 变纯折叠；
+  `direct_finished` 收放行代次并直写 `Request::Terminal`。
+- 验证：`cargo test -- thread_manager::`（62 passed，进程级计数器用例单线程）、`-- agent::`（948 passed）、
+  `-- direct_runtime:: analytics:: direct_codex_user_item`（182 passed）；`analytics::store_tests` 换成"终态直写"
+  与"放行后代际变化不记"两条用例；`npx vitest run tests/appSurface.test.ts`（194 passed）与 chat / direct 定向套件
+  （249 passed）；`npm --workspace apps/ai-game-creator-shell run typecheck`、`npm run check:encoding`、`git diff --check`。
+
 ## 2026-09-28 渲染层下沉分支与最新 master 对齐：活动回合事实源、维护态出口与诊断详情

 - 背景：`codex/agc-renderer-io-downshift` 把 AGC 渲染层的网络与状态下沉 Rust 之后，要重新落到 master 已经演进出的新形状上。29 处冲突里 25 处是机械取舍，真正的分歧只有三处需要定口径。
@@ -6139,7 +6139,7 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`

 ## 2026-09-29 用夹具直接验证「已安装渠道包里的随包 Codex 能不能跑」（不用开 GUI）

- **做法**：`npm run check:agc-direct-execution-fixture -- --agc-exe "<已安装渠道包的主程序绝对路径>" --cases completed`。夹具在临时项目和 loopback Provider 上跑 CLI 执行链路，可直接核对已安装包的随包 Codex。
+- **做法**：`npm run check:agc-direct-execution-fixture -- --agc-exe "<已安装渠道包的主程序绝对路径>" --cases completed`。夹具在临时项目和 loopback Provider 上跑 CLI 执行链路，可直接核对已安装包的随包 Codex。（该入口、夹具与 `--direct-codex-chat` CLI 已随入队化退役删除，见 09-24 实施计划第 4 步；这里记的是当时的做法。）
 - **判读**：若报 `Codex app-server JSON-RPC 失败`，sidecar 已启动并返回协议错误，应先检查请求体及已安装包的源码版本；若根本无法启动，再查安装目录 `coding-agent/win-x64/manifest.json` 的组件哈希、`codex-package.json` 的版本和缺失组件。夹具模式中的 `remote_control disabled reason=provider-proxy-auth` 是预期诊断行。

 ## 2026-09-30 居中溢出叠加内部滚动，会把顶部内容裁到滚不到的地方（游玩页启动面板）