合并 master：运行页入口收口并入 DirectProject 重构

- 保留 master 的 DirectProject / ProjectChat 重构与测试重组：原 appSurface 的 project-commands / project-preview / supervisor-runtime 三个 suite 已被 master 删除，接受删除并把相关断言重写到 tests/previewActivation.test.tsx 等新用例
- 本分支改动重放到 master 结构：运行与预览成功的反馈改走 onRunNotice toast（带 tone），对话区不再写过程提示
- 运行页顶栏统一：预览地址改成「在浏览器打开」按钮，版本入口搬进同一动作区复用同一套按钮皮，状态行与预览地址小字退役
- 生成任务入口、面板与锚点不在运行页渲染，placement 里的 run 档一并删除
- 手工合并 App.tsx / WorkspaceLauncher.tsx / model.ts / check-config.mjs / decision-log / pitfalls，并把两条决策记录与一条排障记录补进 master 版本文档

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

@@ -1,5 +1,21 @@
 # 踩坑与排障记录
 
+## 客户端图标素材描述不能先包装再截断
+
+- 现象：资源画布填写了具体图标需求，平台实际收到的 `iconDescriptions` 却只包含泛化的小游戏美术指令，生成结果不遵循输入。
+- 原因：客户端先给用户描述套“Web 小游戏首版原型、核心美术素材”和默认 brief 模板，再把包装后的文本压入单项 `200` 字符；固定前缀已占满额度，用户描述在发给 API Server 之前就被丢弃。服务端校验只能看到被截短的文本，无法恢复原需求。
+- 处理：客户端画布图标生成只 trim 描述并以单项 `iconDescriptions` 原样提交，保留内部换行；面板与原生入口按 `200` 个 Unicode 码点校验并拒绝空白或超限输入，不静默截断、不机械拆条。服务端共用的提示词流程负责规范图、背景与排布要求；其它图片生成的 `32000` 字符上限保持不变。
+- 验证：检查实际请求体与 trim 后的原文一致，并覆盖 `200/201` 码点、补充平面字符、换行和空白输入；不能只断言“请求长度未超限”。完整合同见 [画板图标素材生成入口设计](../../【编辑器】画板图标素材生成入口设计-2026-06-15.md)。
+
+## 2026-09-21 不同渠道的包体在同一台设备安装会互相顶掉
+
+- **现象**：在一台已经装了某个渠道 AGC 客户端的设备上安装另一个渠道的安装包，装完后旧客户端直接消失（安装目录被覆盖、卸载项被接管），更新端点、平台服务器与本地登录态一起换成新渠道的；两个渠道的客户端无法共存。
+- **原因**：渠道此前只烘焙了 `plugins.updater.endpoints` 与 `VITE_AGC_PLATFORM_CHANNEL`（`apps/ai-game-creator-shell/scripts/build-release.mjs` 的 `createChannelConfig`），`productName` / `identifier` 用的是渠道无关的基线值。Tauri 的 Windows 安装目录与卸载项由 `productName` 决定，WebView2 数据目录与客户端数据目录由 `identifier` 决定，于是所有渠道落到 `%LOCALAPPDATA%\陶泥儿`、`HKCU\...\Uninstall\陶泥儿` 与 `%APPDATA%\world.genarrative.ai-game-creator`。
+- **处理（现行口径）**：渠道进入安装身份，默认渠道保持基线身份不变，其它渠道派生 `<产品名> <渠道显示名>` 与 `<基线>.<渠道>`；身份与端点在同一次构建期 `--config` 注入。见决策记录 2026-09-21 条目。
+- **核对方式**：装完任渠道的包后看 `HKCU\Software\Microsoft\Windows\CurrentVersion\Uninstall\<产品名>` 的 `InstallLocation`、`%APPDATA%\<identifier>` 与主程序窗口标题是否按渠道分开；同名安装目录或同名数据目录说明身份没有生效。
+- **易错点**：只改安装包文件名或快捷方式名而不改 `identifier`，两个渠道仍会抢同一份 Agent Runner / 项目锁与登录态；反过来把渠道后缀加在默认渠道上，既有安装的升级链会断（客户端认不出旧安装）。相似前缀目录（如 `world.genarrative.ai-game-creator-backup`）不得进入提权 ACL 的 managed 范围。
+- **关联**：`apps/ai-game-creator-shell/scripts/channel-identity.mjs`、`build-release.mjs`、`build-macos-ci.mjs`、`src-tauri/src/config.rs`。
+
 ## 发布器守卫拒绝时不要把 process.exit 用在 fetch 句柄未关闭处
 
 - 现象：`agc-template-library-publish.mjs --dry-run` 撞上「同一 `templateVersion` 的 ZIP 不得变」门禁时，终端只剩一句 `Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c`，看不到任何拒绝原因，看起来像脚本崩溃而不是被拒绝。
@@ -4143,6 +4159,14 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 - 验证：活会话下 finalization 和 `runner.shutdown_if_idle` 必须失败关闭；分别验证 graceful handler 尾部输出、宽限超时后的 force、忽略 SIGHUP 的 npm 孙进程和 Windows Job 路径，只有 child 已终态、同组残留已处理且 PTY 尾部排空才出现唯一 terminal record。另用允许程序证明代理和固定 cwd 不是文件系统 / 网络沙箱，不得把该现象误写成测试失败或安全能力。
 - 关联：`docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md`、`apps/ai-game-creator-shell/src-tauri/src/runner.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent.rs`。
 
+## 一次性命令不能把孤儿僵尸误判为仍在执行的进程组
+
+- 现象：Linux CI 的命令已退出，但 `command.exec` 返回 `needs-reconciliation`，后续修复计划或输出读取请求一直等不到；普通 WSL 下相同命令可通过。
+- 原因：容器 PID 1 未回收孤儿 `bwrap` 僵尸，`kill(-pgid, 0)` 仍返回成功；主进程已被 wait 回收，后续 leader 启动身份核对必然失败，掩盖了真实退出结果与原本应触发的日志审计错误。
+- 处理：确认 target 终态且回收主进程后扫描 `/proc/<pid>/stat`，空组或仅含 `Z / X` 成员无需发送信号；有存活成员仍保留 leader 身份门禁，读取失败保守进入 reconciliation，不放宽未知进程组的信号权限。
+- 验证：隔离 subreaper 夹具覆盖 leader 已回收时的存活后代拒绝、孤儿僵尸接受和空组接受；原有诊断命令、审计失败、命令修复与长输出/历史读取测试在不回收孤儿的 PID namespace 下验证。
+- 关联：`apps/ai-game-creator-shell/src-tauri/src/command_exec.rs`、`apps/ai-game-creator-shell/src-tauri/src/tests/command_runtime.rs`。
+
 ## 命令环境变量、代理和进程组不能冒充 OS 沙箱
 
 - 现象：命令看似使用隔离 HOME / TMP、离线包管理器和不可达代理，仍能直接读取宿主用户文件、用原始 socket 联网，或由 `project.verify` 的平行 npm spawn 绕开 `command.exec` 限制。
@@ -5829,6 +5853,23 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 - Vitest 的 `toHaveBeenCalledWith` 匹配任意一次调用，失败输出会列出其它命令；应先定位相同命令的真实参数差异，不能由其它调用的序号推断时序故障。
 - 存在后台轮询的 IPC mock 不应要求目标命令占据全局最后一次调用。验证刷新时先记录调用边界，再筛选该边界之后的目标命令，严格核对其最后一次参数，避免后台查询影响断言，也避免旧调用掩盖刷新未执行。
 
+## 2026-09-16 Lexical 投影丢掉引用后的换行：`@素材` 和下一段粘成一个词
+
+- **现象**：聊天输入区里先 `@` 一个素材、回车换段再写文字，提交出去的 canonical content 里没有任何分隔，直接读成 `@hero把这一版改成夜景`；同一个字符串还会进 agent 输入、队列 chip 文案与润色判据。
+- **原因**：`3c7b02b9f`（2026-09-15）为了让 content 通过 Rust 的「空 `input_text`」校验，在投影层加了 `appendInputText`（`if (text.trim())` 才落 part，并与相邻文本合并）。root 子节点之间补的段落分隔符与 `LineBreakNode` 传进来的都是 `'\n'`，`trim()` 为空 ⇒ 整段丢掉；chip 后那一段文字随后另起一个 part，派生文本用 `''` 直接拼接，于是粘成 `@hero把这一版改成夜景`。`41366dd71` 又把消息正文 / 队列 chip / 快速编辑的文本派生切到这条投影上，缺陷扩散到界面与出站 prompt。
+- **处理（最终口径）**：不保留任何前端过滤，而是去掉规则和它的成因——Rust `validate_direct_codex_user_item` 改成只判整条 content（`content_has_meaningful_input`：有一段非空白文本或任意非文本 part 即有效），单个纯空白 `input_text` 合法；`ResourceReferenceInput` 的投影原样透传编辑器节点，既不丢空白也不与相邻 part 合并。中间版本（把待写文本「向前合并」到下一个 part）已随之删除：它仍会丢掉尾随换行与「两个 chip 之间只隔一个换行」的分隔，也仍要让前端替用户改写内容。
+- **验证**：Rust `validation.rs` / `wire.rs` 新增「单个纯空白 part 通过校验、整条全空白拒绝」用例；`apps/ai-game-creator-shell/tests/resourceReferenceInput.test.tsx`「引用后面的段落分隔原样落进 content」断言 `[ref, { type: 'input_text', text: '\n' }, { type: 'input_text', text: '…' }]` 与派生文本逐字一致；`tests/appSurface/project-development.suite.ts` 的 Godot 用例断言 Shift+Enter 的两个换行各自成 part。
+- **关联**：`apps/ai-game-creator-shell/src/features/project-workspace/ResourceReferenceInput.tsx`（`collectDraftParts`）、`apps/ai-game-creator-shell/src-tauri/src/agent/direct_codex_user_item/validation.rs`、`docs/project-memory/plans/【里程碑】DirectProject canonical content严格边界-2026-09-16.md`。
+
+## 2026-09-16 派生文本漏传 `manifest.assets`：`@引用` 从显示名退化成内部 id
+
+- **现象**：快速编辑面板里 `@` 插了素材再点「修改」，出站 `derive_local_project_resource` 的 `prompt` 是 `把夜色改成星空@source-rules`，而界面 chip 与聊天输入区显示的是 `@rules`；仓库自带的 `projectResourceLiveIntegration` 用例因此长期是红的（`expected '把夜色改成星空@rules' to be '把夜色改成星空@source-rules'`）。同一根因还让排队消息 chip 显示 `@asset:…`。
+- **原因**：`directCodexContentToPromptText(content, assets)` 的 `assets` 有默认值 `[]`，漏传不报错、只是把 `agc_resource_reference` 退化成 `${resourceId}`。`ResourceReferenceInput` 自己读草稿的四处都带了 `manifest.assets`，而它的三个消费方漏传：`chatComposerQueue.queuedChatTurnLabel`（宿主 `ComposerTurnQueue` 也没接素材清单）、`project-development/index.tsx` 的 `applyResourceQuickEditPrompt` 与 `applyResourceQuickEditDraft`；后两个的 `useCallback` 依赖里同样没有 `manifest.assets`，改完还会读到旧清单。
+- **处理**：三个消费方全部补上素材清单并进依赖数组——`queuedChatTurnLabel(turn, assets)` + `ComposerTurnQueue` 新增 `assets` 属性（由 `ProjectSupervisorView` 传 `chatProjectAssets`）、快速编辑的两处改用 `manifest.assets`。改「比较用的草稿文本」与「落进面板的文本」必须同一个口径，否则 `replaceText` 会每次输入都重跑一遍。
+- **加固**：`directCodexContentToPromptText(content, assets)` 与 `queuedChatTurnLabel(turn, assets)` 的 `assets` 改为**必填**（删掉 `= []` 默认值），测试里刻意不传 manifest 的地方显式写 `[]`。理由：默认值把「漏传素材清单」从编译期错误降级成运行期文案退化，正是本条缺陷的入口；队列 chip 与消息正文从此共用同一个派生（`queuedChatTurnLabel` 只多做「压成单行 + 限长」）。
+- **验证**：`apps/ai-game-creator-shell/tests/projectResourceLiveIntegration.test.tsx` 的「快速编辑提示词里能 @ 出资源选择器」由红转绿（该文件 29 passed）；`tests/appSurface/chat-composer.suite.ts` 新增「队列 chip 的 @ 引用按 manifest 显示名展开」；`appSurface.test.ts` 467 passed、定向 51 passed、`npm run ai-game-creator-shell:typecheck`、`npm run check:encoding` 通过。
+- **关联**：`apps/ai-game-creator-shell/src/features/project-workspace/chatComposerQueue.ts`、`ComposerControls.tsx`、`ProjectSupervisorView.tsx`、`apps/ai-game-creator-shell/src/view/project-development/index.tsx`、`apps/ai-game-creator-shell/tests/projectResourceLiveIntegration.test.tsx`。
+
 ## 2026-09-16 并发生图遇到“登录态冲突”：身份代次与凭据轮换混用
 
 - **现象**：DirectProject 长回合里并发派发的生图 / 素材生成请求中途报 `authentication-required: 陶泥儿登录态已变化，旧账号请求已停止，请使用当前账号重试`，或平台工具返回 `HTTP 401 invalid-token`；账号并没有切换，重新登录后短时间内可复现。
@@ -5848,8 +5889,8 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 ## 2026-09-16 AGC 壳跑过 `cargo test` 后前端 typecheck 必红：ts-rs 导出把 `generated/*.ts` 重写成另一种形状
 
 - **现象**：在 `apps/ai-game-creator-shell/src-tauri` 跑过 `cargo test` 之后，`npm run ai-game-creator-shell:typecheck` 报 10 条类型错（`src/features/project-workspace/resourceReferences.ts:106-112` 的 `string | undefined` 不能赋给 `string | null`；同文件 134 行的对象字面量带 `type: 'message'`，而 `DirectCodexUserMessageItem` 里没有该字段），`npm run ai-game-creator-shell:build` 也死在 `beforeBuildCommand` 的同一条 typecheck 上。
-- **原因**：crate 里的 ts-rs 导出会按**本机依赖版本**重写 `src/features/project-workspace/generated/DirectCodexUser*.ts`：注释头变成 "This file was generated…"、字符串改双引号、`DirectCodexUserMessageItem` 丢掉 `type: 'message'` 判别字段、并多出一个 `DirectCodexUserMessageEnvelope.ts`。仓库里提交的那份是前端真正依赖的形状（前端按带 `type` 的判别联合写），重写后两边就对不上——错在生成器版本漂移，不在前端。
-- **处理（现行口径）**：不要把重写结果当改动提交。跑过 `cargo test` 或构建后只恢复 `apps/ai-game-creator-shell/src/features/project-workspace/generated/DirectCodexUser*.ts` 的仓库版本，再删掉多出来的 `DirectCodexUserMessageEnvelope.ts`；不要恢复整个 `generated/` 目录，以免误删 DirectThread 的现役绑定。绑定与前端形状冲突时以**已提交的 DirectCodexUser 绑定 + 前端**为基准排查。
+- **原因**：crate 里的 ts-rs 导出会按**本机依赖版本**重写 `src/view/project-development/chat/generated/DirectCodexUser*.ts`：注释头变成 "This file was generated…"、字符串改双引号、`DirectCodexUserMessageItem` 丢掉 `type: 'message'` 判别字段、并多出一个 `DirectCodexUserMessageEnvelope.ts`。仓库里提交的那份是前端真正依赖的形状（前端按带 `type` 的判别联合写），重写后两边就对不上——错在生成器版本漂移，不在前端。
+- **处理（现行口径）**：不要把重写结果当改动提交。跑过 `cargo test` 或构建后只恢复 `apps/ai-game-creator-shell/src/view/project-development/chat/generated/DirectCodexUser*.ts` 的仓库版本，再删掉多出来的 `DirectCodexUserMessageEnvelope.ts`；不要恢复整个 `generated/` 目录，以免误删 DirectThread 的现役绑定。绑定与前端形状冲突时以**已提交的 DirectCodexUser 绑定 + 前端**为基准排查。
 - **验证**：恢复仓库版本后 `npm run ai-game-creator-shell:typecheck` exit 0（`[skill-pack] OK`）；保留重写结果时同一条命令 exit 2。release 构建本身还会在 `src/features/ui-editor/types/` 落下 `BindingChange.ts` / `BindingDTO.ts` 两个无人引用的生成产物；它们不属于前端契约，发现后直接删除，不提交。
 - **关联**：`apps/ai-game-creator-shell/src-tauri/src/agent/direct_codex_user_item/`（ts-rs 导出源）、`apps/ai-game-creator-shell/src/features/project-workspace/resourceReferences.ts`、`apps/ai-game-creator-shell/scripts/build-release.mjs`（`beforeBuildCommand`）。
 
@@ -5868,17 +5909,44 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 - **验证**：修复后同一台机器、同一路径下 35 秒内新增 `Maximum update depth` **0 条**，renderer 工作集 **254 MB**（修复前 4.2–4.4 GB）；`apps/ai-game-creator-shell/tests/directActiveTurns.test.tsx` 断言轮询返回值不变时快照引用不变。
 - **关联**：`apps/ai-game-creator-shell/src/features/app-shell/WorkspaceLauncher.tsx`、`apps/ai-game-creator-shell/src/features/agent-runtime/directActiveTurns.ts`、`apps/ai-game-creator-shell/src/components/WindowChrome.tsx`、`apps/ai-game-creator-shell/src/features/app-shell/useHomeProjectCreation.ts`。
 
+## 2026-09-21 受控 Lexical 输入区的回写用被动 effect：滞后渲染的 props 会把用户草稿清空
+
+- **现象**：DirectProject 输入盒里粘贴（或连续输入）长文本，提交时 `chat_with_game_creator_direct_codex` 根本没发出去，界面停在空输入盒；`chat-composer` 用例里表现为「队列/终止/语音追加」五条一起红，但手工操作只在快速输入后偶发。
+- **原因**：`ResourceReferenceInput` 的受控回写写在 `useEffect` 里，判据是「`value`/`references` 与编辑器当前草稿不一致就重建 root」。宿主对草稿的回显（`chatInput`/`chatReferences`）永远晚于编辑器的 Lexical 提交：一次渲染提交后它的被动 effect 可能排在用户下一次输入之后才执行，于是它读到的是**旧 `value` 加新编辑器状态**，判定不一致→`applyDraftToRoot` 整份重建→编辑器 `onChange` 把空草稿写回宿主→宿主再回显空值，来回清空。`references` 每次 `handleComposerDraft` 都换数组身份，进一步保证这段 effect 每次都跑。
+- **处理**：受控回写改成 `useLayoutEffect`，与本次提交同帧执行，读到的 props 与编辑器状态属于同一次提交；被动 effect 的滞后回调不再可能出现。旧 `value`+`references` 双轨语义本身仍是待收口的债务（见 canonical content 里程碑）。
+- **验证**：`apps/ai-game-creator-shell/tests/appSurface/chat-composer.suite.ts` 的队列、终止×2、恢复回合、语音追加五条用例转绿；`tests/resourceReferenceInput.test.tsx` 全绿。
+- **关联**：`apps/ai-game-creator-shell/src/features/project-workspace/ResourceReferenceInput.tsx`、`docs/project-memory/plans/【里程碑】DirectProject composer canonical content闭环-2026-09-21.md`。
+
+## 2026-09-21 删链路只删订阅、没删它喂的 state：留下恒为默认值的死 prop
+
+- **现象**：`876529e66` 之后策划 Agent 一轮里再也看不到流式正文和「思考过程」，`planningV2Reasoning` 恒为 `''`、`designReasoning` 这个 prop 永远传空；对应用例只在 `appSurface` 里红一条，很容易被当成「测试过期」删掉。
+- **原因**：该提交目的是删除 Project Supervisor，但把 App 里唯一订阅 `design-agent-update` 的 effect 一并删了；Rust 侧 `design_*` 三个命令仍在 `app.emit("design-agent-update", …)`（含 `reasoning_text`/`text`/`view`），前端却无人监听。判断线索是残留的 `designAgentEventSubscriptionReady()`——它在发起回合前被 await，但没有任何代码再创建这个 promise，说明订阅被误删而不是有意退役。
+- **处理**：恢复订阅（正文/工具提示 → transient reply，`reasoningText` → `planningV2Reasoning`，`view` → `applyDesignAgentViewAfterTransient`），补回订阅就绪 promise 的建/解函数；新增 `designAgentReasoningTurnRef` 让回合结束后仍认本轮 reasoning。
+- **验证**：`tests/appSurface/design-agent.suite.ts`「keeps the current turn reasoning after completion and supports collapse/expand」与「renders historical reasoning as independent collapsed sections」同时通过。
+- **关联**：`apps/ai-game-creator-shell/src/App.tsx`、`apps/ai-game-creator-shell/src-tauri/src/agent/design_runtime.rs`。
+
+## 2026-09-21 DirectProject 聊天 IPC 里的「可读 prompt 投影」是死参数，接回模型输入就污染标签
+
+- **现象**：`chat_with_game_creator_direct_codex` 的 Tauri 入参曾并列带一个 `prompt: String`（前端把 canonical content 渲染成 `@显示名` 文本），Rust 侧从不读取——`cargo check` 直接报 `src/agent/direct_runtime/user_input.rs` 的 `unused variable: prompt`；前端每次提交仍要算一遍，界面测试也钉着这份投影文本。
+- **成因**：DirectProject 回合真正的输入只来自 canonical `userItem`。`direct_codex_user_item_to_codex_turn_input`（`agent/direct_codex_user_item/wire.rs`）在 DirectProject 分支重建 `turn/start.input`，`LlmRunRequest` 里那份 `user_prompt` 会被覆盖；客户端投影走的是另一套口径（素材被删或改名时退化成裸 resourceId），一旦有人把它接回 Codex，就把 `@显示名` 标签污染了模型输入。
+- **现行口径**：IPC 只传 `projectPath`、`clientTurnId`、`userItem` 与可选 `creationType`；Rust 只从 `userItem` 派生回合输入（空判定与三维契约探测用的派生 prompt 仍在 Rust 内部生成）。前端那份 `@显示名` 投影只服务本地的 `/history` 识别与队列 chip 文案，不出 IPC；界面断言只能读 `userItem.content`。
+- **关联**：`apps/ai-game-creator-shell/src-tauri/src/agent/direct_runtime/user_input.rs`、`apps/ai-game-creator-shell/src-tauri/src/agent/direct_codex_user_item/wire.rs`、`apps/ai-game-creator-shell/src/view/project-development/chat/controller/useDirectProjectChatController.ts`、`apps/ai-game-creator-shell/tests/appSurface/chat-composer.suite.ts`。
+
 ## 2026-09-21 DirectProject 结构化消息不能逐个拒绝空白文本片段
 
 - **现象**：多行正文、末尾空段落或合法引用前后的分隔空格会让有内容的消息报错；编辑器为了保持结构产生的空白文本片段被误判为“聊天内容为空”。
 - **原因**：校验器对每个 `input_text` 单独执行 `trim().is_empty()` 并立即拒绝，混淆了结构化片段合法性和整条消息是否有实际内容。
-- **处理（现行口径）**：`input_text` 允许空字符串、空格和换行，校验过程保持全部片段的原文、分段与顺序，不做合并或删除；遍历完整条消息后，只在既没有非空白文字、也没有合法 `agc_resource_reference` / `agc_runtime_region_reference` 时返回“聊天内容不能为空”。两类引用仍逐个执行原有校验，消息带正文也不能绕过非法引用。
+- **处理（现行口径）**：`input_text` 允许空字符串、空格和换行，校验过程保持全部片段的原文、分段与顺序，不做合并或删除；遍历完整条消息后，只在既没有非空白文字、也没有任意非文本 part（素材引用 / 运行画面引用 / Skill 引用 / 附件引用）时返回“聊天内容不能为空”。各类引用仍逐个执行原有校验，消息带正文也不能绕过非法引用。
 - **关联**：`apps/ai-game-creator-shell/src-tauri/src/agent/direct_codex_user_item/validation.rs`、`docs/【功能说明】AGC聊天素材引用-2026-09-08.md`。
 
-## 2026-09-21 本地 node_modules 里的内置 Codex 原生包过旧会让 AGC build script panic
+## 2026-09-21 应用日志整行凭据脱敏会吃掉整条结构化诊断
 
-- **现象**：`npm run agc` 编到壳 crate 的 build script 时中止，stderr 是 `panicked at build.rs:103: Codex 原生包版本、布局或架构不匹配目标 x86_64-pc-windows-msvc`，stdout 只打印了 `cargo:rustc-env=AGC_BUILD_TARGET=...`。
-- **原因**：`build_support/codex_bundle.rs` 把随包 Codex CLI 钉在 `0.155.1`（随 #439 升级），而本地 `node_modules/@openai/codex-win32-x64/vendor/x86_64-pc-windows-msvc/codex-package.json` 仍是 `0.147.0`。`package-lock.json` 早就是 `0.155.1`，缺的只是本地安装；这条判据只看版本元数据，文件齐全、架构正确也照样拦。
-- **处理（现行口径）**：在仓库根目录执行 `npm ci`（不要改成子目录或单包安装），随后 `node_modules/@openai/codex/package.json` 与 vendor 的 `codex-package.json` 都应为 `0.155.1`。Windows 上 `npm ci` 会先 unlink 整个 `node_modules`：RustRover 的 Tailwind language server / `oxide-helper` 进程会占住 `@tailwindcss/oxide-*.node`，报 `EPERM: operation not permitted, unlink ...` 时先结束这些 helper 再重试，否则会停在半装状态。
-- **验证**：`npm ci` 后 `cargo build --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml` 输出 `Finished dev profile ... in 1m 26s`，不再触发该 panic。
+`append_application_log_line` 在落盘前对整行做 `sanitize_diagnostic_message`：行内只要出现 `token=`、`bearer `、`authorization`、`credential`、`api key` / `apikey` / `api_key` 这类标记，**整行**就被换成 `<sensitive diagnostic details redacted>`，只留下时间戳与 `RUST module:` 前缀；同时每行还会被截到 2048 字符。于是把“身份字段 + 诊断正文”拼成一行 `app_log!` 时，正文里一个凭据词就可能让整条记录连 `eventId`、`code` 一起消失（2026-09-21 加统一错误事件的日志投影时按两行落：身份行只放程序生成与调用方常量字段，summary / hint / detail 等自由文本一律只放详情行，且自由文本先自行压平换行——裸词标记脱敏消不掉，自由文本放错行会把 eventId、code 一起带走）。
+
+## 2026-09-22 本地 node_modules 里的内置 Codex 原生包过旧会让 AGC build script panic
+
+- **现象**：`npm run agc` 编到壳 crate 的 build script 时中止，stderr 是 `panicked at build.rs:103: Codex 原生包版本、布局或架构不匹配目标 x86_64-pc-windows-msvc`，stdout 只有 `cargo:rustc-env=AGC_BUILD_TARGET=...`。
+- **原因**：`build_support/codex_bundle.rs` 把随包 Codex CLI 钉在一个固定版本，而本地 `node_modules/@openai/codex-win32-x64/vendor/<target>/codex-package.json` 还停在上一次安装的旧版本。`package-lock.json` 早就升到新版本，缺的只是本地安装；这条判据只看版本元数据，文件齐全、架构正确也照样拦。
+- **处理（现行口径）**：在仓库根目录执行 `npm ci`（不要改成子目录或单包安装），随后 `node_modules/@openai/codex/package.json` 与 vendor 的 `codex-package.json` 版本应当一致。Windows 上 `npm ci` 会先 unlink 整个 `node_modules`：RustRover 的 Tailwind language server / `oxide-helper` 进程会占住 `@tailwindcss/oxide-*.node`，报 `EPERM: operation not permitted, unlink ...` 时先结束这些 helper 再重试，否则会停在半装状态。
+- **验证**：`npm ci` 后 `cargo build --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml` 通过，不再触发该 panic。
 - **关联**：`apps/ai-game-creator-shell/src-tauri/build.rs`、`apps/ai-game-creator-shell/src-tauri/build_support/codex_bundle.rs`、`package-lock.json`。