Merge remote-tracking branch 'origin/master' into feat/ui-editor-v3

# Conflicts:
#	docs/project-memory/shared-memory/decision-log.md

docs/README.md

@@ -21,6 +21,7 @@
 - [当前产品与工程约束](./【项目基线】当前产品与工程约束-2026-05-15.md)：现役入口、账号钱包、UI 和后端分层。
 - [平台入口与玩法链路](./【玩法创作】平台入口与玩法链路-2026-05-15.md)：只描述现役平台壳与图片画布编辑器链路。
 - [外部 OpenAPI 与 API Key 接入方案](./【后端架构】外部OpenAPI与APIKey接入方案-2026-06-19.md)
+- [外部 MCP 语义工具说明与参数设计](./technical/【技术方案】外部MCP语义工具说明与参数设计-2026-09-23.md)：15 个新增语义工具与全部原工具并存，复用现有 External API；包含工具说明、action、参数、幂等和兼容合同。
 - [External v1 OpenAPI](./openapi/genarrative-external-v1.openapi.json)：公开 HTTP 契约唯一机器可读来源。
 
 ## AI 游戏创作与 Agent Runtime
@@ -45,6 +46,8 @@
 - [UI 工作流检查点用追加式 JSONL 日志](./adr/【ADR】UI工作流检查点用追加式JSONL日志-2026-09-23.md)：UI 设计文档的 Agent 工作流用文档旁追加式 JSONL 记录步骤完成，替代每步一个 sidecar 状态机。
 - [退役 AGC 项目对话斜杠命令](./adr/【ADR】退役AGC项目对话斜杠命令与终端swarm chat入口-2026-09-22.md)：AGC 项目对话与终端 swarm chat 均不再解析斜杠命令，终端聊天入口一并退役；实现、测试、门禁与文档承诺全部删除，命令 id 与权限位作为项目策略词汇表保留。
 - [引用候选由宿主注入](./adr/【ADR】引用候选由宿主注入-2026-09-22.md)：引用输入区只接受宿主注入的引用 provider，素材选择面板独立成组件，附件芯片成为本轮附件唯一事实源。
+- [DirectProject 命令接单化](./adr/【ADR】DirectProject命令接单化-2026-09-23.md)：命令只负责接单、事件流回答整轮结果；拒单前置、失败后置。
+- [DirectProject 命令接单化实施计划](./technical/【实施计划】DirectProject命令接单化-2026-09-23.md)：四步落地顺序、每步不变式与验收；四步均已落地。
 - [GameAgent 对话工具调用卡片](./technical/【技术方案】GameAgent对话工具调用卡片-2026-09-14.md)：把右侧对话里的执行命令 / 写文件投影成 Codex 风格可折叠卡片，含采集、独立历史文件、事件字段与回读契约。
 - [DirectProject 客户端 Skill 与 MCP 扩展导入方案](./technical/【技术方案】DirectProject客户端Skill与MCP扩展导入方案-2026-08-31.md)：客户端扩展导入、按独立 Skill/MCP 拆分、命名、启用和启动时注入边界。
 - [AGC 通用插件宿主与编辑器适配](./technical/【技术方案】AGC通用插件宿主与编辑器适配-2026-09-09.md)：通用插件宿主、SDK、权限审计、UI 挂载和 Cocos 编辑器适配边界。

docs/adr/【ADR】DirectProject命令接单化-2026-09-23.md

@@ -0,0 +1,185 @@
+# 【ADR】DirectProject命令接单化
+
+状态：已接受（2026-09-23 落地，实施顺序与验收见
+[`【实施计划】DirectProject命令接单化-2026-09-23`](../technical/【实施计划】DirectProject命令接单化-2026-09-23.md)）
+
+## 背景
+
+`chat_with_game_creator_direct_codex` 现在从校验一路 await 到交付验证结束，一个命令调用覆盖整轮。
+于是命令边界承担了两件不属于它的事：
+
+1. **回合失败的可见文案有两条来源。** 事件载荷 `turn.completed.failure.message` 是聊天里那条失败说明的
+   来源，命令 Err 是横幅与 `详情：` 引用的来源。两者各有分工，但都由"这一轮结束"这个时刻触发，
+   前端 `runTurn` 的 catch 因此同时兼职"接单被拒"与"回合失败"两种回执。
+2. **认证失败重试只能挂在这条 Err 上。** `withDirectCodexSessionRefresh` 在登录态失效后刷新会话并
+   **重跑整个 operation**。重跑会再写一条用户消息：单飞锁随命令返回就已经释放，所以这条重跑路径今天
+   会往历史里写第二条一样的用户消息。
+
+还有一个先天的洞：回合边界今天**镜像 Codex 原生回合**——开始事件只在 `turn/start` 成功应答之后才进队列
+（`direct_runtime/user_input.rs:81` 之后要一路走到 app-server），于是"接单到 `turn/start` 之间"的失败
+（连不上 app-server、配置未就绪、历史注入失败、`turn/start` 被拒）没有任何事件可以解释，只能靠命令 Err。
+命令一旦不再 await，这些路径就会静默。
+
+## 决策
+
+### 1. 命令 = 接单 / 拒单
+
+命令只做：`clientTurnId` 校验 → 占用调用身份（并发拒单）→ 工作流恢复 → 用户条目校验 → 工程准备
+→ 接单成立 → 用户条目落盘 → 起 codex。成功后立刻返回，不在命令里等回合。
+
+这里的"占用调用身份"只挡并发（早于工程准备，避免两个请求同时做准备），与 §2 的"登记逻辑回合占用"
+不是同一件事：后者拥有这一轮的终态出口。
+
+**接单成立之前的任何失败都是拒单**：不产生回合事件、不写用户条目、不写失败诊断。
+
+### 2. 逻辑回合由 Thread Manager 拥有
+
+- 接单动作在 Thread Manager 内**原子地**完成"拒绝并发 / 登记占用 / 发出逻辑回合开始事件"。
+- 这条生命周期**不是** Codex 原生回合的镜像：发点在接单时，不在 `turn/start` 应答后；Codex 原生回合事件
+  留在适配器内部，不再进事件队列。线上仍然只有**一对** `turn.started` / `turn.completed`。
+- 这一轮的**占用对象是唯一终态出口**，并且幂等：正常 / 失败 / 中断 / 取消 / 连接断开谁先到谁写；任务
+  panic 或被取消时由它兜底补一条终态（保留 `host-dropped` 分类，只给"说不出原因"的这一种）。终态写出后
+  占用才释放。
+- 因此"接单成功 ⇔ 事件流里有开始且有结束"是结构性成立，不依赖实现者记得给每条"接单后提前收场"
+  （早退：回合内任何没走到正常终态的收口点，比如 `turn/start` 被拒、注入失败、panic）的路径补事件。
+- **终态的写点在整轮真正结束之后**（执行结果收集、历史落盘、structured output 解析都定型）：解析失败
+  也是这一轮的失败，落进同一份失败载荷。终态一旦先写成 `completed`，后面再失败的步骤就没有出口——
+  占用对象只兜"早退"，解释不了"终态之后又失败"。
+- **封口返修要求不是回合失败**：`HostOutcome::RepairRequired` 走独立的 typed 控制流变体
+  （`DirectTurnRunFailure::RepairRequired` → `DirectTurnError::RepairRequired`），不写终态、不进载荷、
+  不上报，由返修循环写回提示词继续跑。
+
+### 3. 通道判据从"错误种类"改成"发生位置"
+
+- **接单前发生的 = 拒单**：目录、权限、输入、并发、工程准备未就绪、宿主状态取不到。
+- **接单后发生的 = 回合失败**：连接、配置、历史注入、`turn/start` 被拒，以及回合过程中的一切。
+- `DirectTurnError::EnvironmentNotReady` 作为公共错误保留，接单前后都可能出现；它需要自己的失败分类
+  （`environment-not-ready`），否则回合失败投影会把它写成 `model-failed`，界面语气就错了。
+
+### 4. 拒单载荷 = 现有 typed 错误
+
+命令返回类型改成结构化的 `DirectTurnError`（ts-rs 导出到 `chat/generated/`，与 `DirectThreadEvent` 同一套
+`cargo test export_bindings` 流程），并随载荷带一条由 `Display` 生成的用户文案（文案仍只在一处生成）。
+前端按变体分流：
+
+- 认得的"前置条件不满足 / 用户参数无效"→ 与用户消息同级的提示，不上报；
+- 认不出的变体或非结构化错误 → 抛出，走既有捕获上报链路。
+
+### 5. 回合身份由 `clientTurnId` 推导
+
+`turn.started` / `turn.completed` 的 `userItemId` 由 `clientTurnId` 按现有规则算出
+（`direct-codex:{clientTurnId}:user`，与前端 `directCodexConversationMessageId` 同规则），**不读盘回填**：
+开始事件发生在用户条目落盘之前，落盘本身也可能失败。
+
+### 6. 诊断留痕与错误上报都在宿主侧
+
+`.agent/runtime/errors` + 应用日志 + 错误上报池由宿主投影写出；回合失败进池的责任从前端 catch 移到宿主。
+命令边界不再负责回合失败的文本。
+
+### 7. 界面：同级提示，删除 `详情：`
+
+- 失败说明与接单被拒提示都与用户消息**同级**，按事件顺序排在它后面，不嵌在这条用户消息里。
+- 删除 `详情：`：用户可见文案里不再出现该引用，前端删除解析与对应的第二次 IPC。
+- 顶部状态行只显示回合状态，不再承载错误文本。
+
+### 8. 队列与埋点
+
+- 前端发送队列的放行改为监听"回合完成"（收到终态事件，或接单被拒），不再由命令返回驱动。加 TODO：
+  以后这条队列挪到 Rust 端，落点就是 Thread Manager 的接单动作。
+- 埋点结算挂在"回合完成"；不能在接单返回时结算——成绩是回合末才入 `pending_runs` 的，提前结算会变成空操作。
+- 首页"运行中的项目"快照由 Thread Manager 的逻辑回合导出，任务侧不再单独维护一张表。
+
+### 9. 认证失败不再重跑整轮
+
+删掉 `withDirectCodexSessionRefresh` 的"刷新 + 重跑整轮"；登录态失效按普通回合失败呈现。
+`cancel_direct_codex_turn` 用的是同一个包装，一并去掉。
+
+### 10. 回合失败原因本轮不落历史
+
+失败原因只走事件载荷与宿主诊断，不写进 `project.jsonl`——重进项目只会看到那条没有回复的用户消息。
+加 TODO：以后要做"进历史但不喂模型"的失败条目（暂定做法见「备选方案」第 3 条）。
+
+## 影响与代价
+
+- 命令返回后不再有 Err 兜底：回合一侧只剩事件流，宿主的占用对象必须真的兜住所有路径。
+- **落盘即接单**：接单成功但回合失败时，历史里会留下一条没有回复的用户消息，而且失败原因不在历史里
+  （只在当轮界面与诊断文件里）。
+- 前端可以删掉的东西：`markTurnStopped()`（取消成功但事件未到时手动放掉忙碌态）、`turn.started` 的
+  "重复开始保留第一次起点"分支、`详情：` 正则与 `read_agent_runtime_error_detail` 调用。
+- `kill -9` 的自愈变好：Thread Manager 随进程消失，新进程的订阅 bootstrap 不会出现"有开始没结束"，
+  界面不会卡在忙碌态。
+- 必须同步的注释：`chat/controller/useDirectProjectChatController.ts`（catch 的职责）、
+  `chat/conversation/directTurnPresentation.ts`（"`invoke` 直到整轮结束才返回"这句会变成错的）。
+- CLI 保持 await（它要那段回复文本），两个入口的分工在命令模块里写清楚。
+
+## 备选方案与取舍
+
+1. **保留"刷新 + 重跑整轮"**：省掉用户重新登录，但重跑会重复落盘用户消息（现状即有），且重试语义与
+   "命令在飞"绑死。已作废。
+2. **让 Codex 原生回合事件继续进队列**：等于线上有两对生命周期，接单后的前置失败仍然只能靠人工补事件。
+   已作废。
+3. **"可见但不喂模型"的条目**：(a) 按条目 id 前缀在注入侧过滤；(b) 条目上挂显式标记（如 `agcLocal`）；
+   (c) 新增一种行结构。注意 `project.jsonl` 是项目主对话与 DirectProject **共用**的文件，信封类型两侧共用，
+   改新行结构要连带改共享合同与读取侧（非 `response_item` 行现在是"失败关闭"）。本轮不做，TODO 记 (b)
+   为暂定做法。
+
+## 明确不做
+
+- 不给失败载荷加字段（不加 `detailRef`）：横幅不再展开详情，诊断引用只留在宿主侧。
+- 不恢复 invoke 拒绝通道，也不为"接单后的前置失败"新增事件类型——它们走同一对逻辑回合事件。
+- 本轮不做"失败条目进历史但不喂模型"（TODO），不做 Rust 端发送队列（TODO）。
+
+## 落地时要同步的文档与注释（已同步 2026-09-23）
+
+- `docs/technical/【技术方案】DirectProject Codex原始历史与异常恢复-2026-09-04.md`：事件带 `userItemId` 的事实、
+  失败原因的通道、"`turn.started` 之前的早退不产生终态事件"（作废）、失败说明是否落历史。
+- `docs/adr/【ADR】DirectProject对话历史单一事实源-2026-09-16.md`：影响里的两条已知边界与"事件不带回合身份"
+  "宿主侧 Drop 守卫兜底"两条决策形状被本 ADR 取代。
+- `docs/technical/【实施计划】DirectProject命令接单化-2026-09-23.md`：四步标记落地，补验收证据与已知坑。
+- `docs/project-memory/shared-memory/decision-log.md`：`host-dropped` 的两条口径加取代注，并追加一条
+  2026-09-23 的接单化决策。
+- `docs/README.md`：索引行去掉"未实施"。
+- 代码注释：`direct_runtime/user_input.rs` 的 `TODO`（分工改成 CLI 保持 await）、
+  `chat/controller/useDirectProjectChatController.ts` 的 catch TODO（队列挪 Rust）、
+  `direct_thread_wire.rs` 里 `userItemId`"由原生从已落盘条目上读取"的说明。
+
+后续更新（2026-09-24，接单化 review 收口）：§2 补"终态的写点在整轮结束之后"与"封口返修要求不是回合
+失败"两条不变式；`docs/technical/【技术方案】DirectProject Codex原始历史与异常恢复-2026-09-04.md` 的
+"终态由事实判定"一段同步改写；`docs/project-memory/shared-memory/decision-log.md` 追加同日条目。
+
+后续更新（2026-09-24，接单化 review 收口第二轮）：§4 的拒单载荷 `kind` 收成 typed 枚举
+（`DirectTurnFailureKind`，线上形状与取值不变）、并发拒单的两个身份改成回合身份；§5 的"回合身份由
+`clientTurnId` 推导"补上"命令边界的拒单载荷也不例外"；§6 的可留痕判据收掉 `ProjectRootUnanchored`
+（它与 `ProjectRootUnusable` 同类，是用户自己就能修的文件系统事实）；§7 的"同级提示"补上认不出的
+拒单（拒单不产生终态事件，聊天里必须由命令边界补一条说明）。失败说明的可见文案口径记在
+`docs/project-memory/shared-memory/decision-log.md` 同日第二条。
+
+后续更新（2026-09-24，接单化 review 收口第二轮续）：§1 的"命令 = 接单 / 拒单"补上"接单成立之后的一切
+失败都回 `Ok(())`"——终态由占用对象写、命令返回值只表示接单或拒单，否则同一个失败会从"事件里的说明"
+和"命令 `Err` 的横幅"两条通道下发，前端还会把已经开始的回合读成"没开始"（历史落盘失败即这一类，且
+**不继续起整轮**：`project.jsonl` 是这条对话的单一事实源，用户消息没落盘时继续跑只会得到一条没有开口
+用户消息的助手回复）；§2 的"谁先到谁写"旁边补上"失败事实先于看门狗可见"——连接死亡的收口路径必须在
+失败事实写进执行适配器**之后**才让"连接已死"对看门狗可见（`closed` 不再兼作去重标志，去重改用私有的
+`connection_end_claimed`），否则 200ms 看门狗可能抢先把它收束成 `Interrupted`，那一轮退化成"本轮已结束、
+没有原因"；失败事实是在模型终态那一刻被快照进终态上下文的，晚补记无用。
+后续更新（2026-09-24，回合顺序修复：开口用户条目先于整轮里的一切失败）：§2 补一条**顺序不变式**——
+本轮的开口用户条目是这一轮的**第一条运行态条目**，发点在"接单成立、用户条目落盘成功、起 codex 之前"
+（`emit_direct_thread_user_item`，调用点在 `direct_runtime/user_input.rs` 的命令主体），不再等 `turn/start`
+应答。它以前在 `turn/start` 之后才下发，于是"接单到 `turn/start` 之间"的失败（连不上 app-server、执行器
+未通过验收、历史注入失败）没有用户条目可挂：界面把失败说明按位置落进**上一轮**的分区，显示成"错误
+在用户消息上面"，上一轮还顶替本轮显示耗时（现场：17:22:46 发的那条消息下面显示上一轮的 15.6 秒），
+本轮的用户气泡再自成一个 0.0 秒的假回合；下一条消息同样看不到自己的失败说明。§7 的界面口径据此补上
+"回合归属只认身份"：失败说明条目带 `turnUserItemId`，投影层按开口条目身份分组，本地乐观气泡按身份挂回
+自己的回合；reducer 的收口早退也不再吞掉"订阅重建只回放生命周期锚点"时那条还没写进界面的失败说明。
+
+后续更新（2026-09-24，删掉本地乐观用户气泡）：§7 的"同级提示"再收一层——**本地不再造用户消息**。
+前端把乐观气泡、`awaiting-start` 展示态、`pendingUserItemId` / `messageAppended` / `messageText`
+这一整套一起删掉，用户气泡**只**来自宿主条目（发点＝接单成立、落盘成功、起 codex 之前）。三条口径
+随之固定：① 接单窗口（按下发送到 `turn.started` 落进 reducer）与订阅重建窗口里聊天区没有这一轮的
+任何条目，反馈只有 composer 忙态、状态行与「陶泥儿正在处理」卡片（卡片这一段不读秒：起点要等宿主的
+`turn.started.at` 到）；② 回合起点只认 `turn.started.at`、终点只认
+`turn.completed.at`，用户气泡显示的时钟是宿主落盘 / 观测时间（不再有更早的本地发送时间），两边都
+拿不到（重进项目读回来的历史回合）时整条「本轮结束于 … 」隐藏，不再兜出 0.0 秒；③ 拒单提示带自己
+的身份（`…:rejected`），投影据此在会话末尾自成一组，不挂进上一轮。§7 里"排在用户消息后面"在没有
+用户消息的回合里指"这一组提示自己"。代价（已知并接受）：条目下发之前用户看不到自己那句话，
+`project.jsonl` 里的用户条目也依旧只在首屏 / 翻页时读进前端。

docs/adr/【ADR】DirectProject对话历史单一事实源-2026-09-16.md

@@ -2,6 +2,12 @@
 
 状态：已接受
 
+> 注：本文件下列口径已被 [`【ADR】DirectProject命令接单化-2026-09-23`](./【ADR】DirectProject命令接单化-2026-09-23.md)
+> 重新决策并已落地，本文件不再作为它们的依据：「影响」一节里的两条已知边界（① `kill -9` 后前端停在运行态
+> ——队列随进程消失，订阅 bootstrap 不会留下"有开始没结束"；② `turn.started` 之前的早退不产生终态事件
+> ——"早退"被拆成接单前的拒单，接单后由占用对象统一收口），以及「决策」里"事件不带回合身份"与
+> "宿主侧 Drop 守卫兜底"两条的实现形状（见下）。
+
 ## 背景
 
 AGC 项目开发聊天框当前同时从三处取数据：Direct 回合事件（实时）、`turn-stream.jsonl`（文本段与工具交替顺序）、`tool-calls.jsonl`（已脱敏工具卡片），重进页面时还要额外接管活动回合快照。同一段文本和同一张工具卡片因此存在多个来源，实时与回读会互相覆盖，恢复路径也只能靠"哪个源先到"决定。
@@ -20,10 +26,15 @@ AGC 项目开发聊天框当前同时从三处取数据：Direct 回合事件（
 - 两侧的过滤口径必须完全一致，包含「哪些条目根本不是本项目的聊天条目」：Codex app-server 回显的用户消息（`userMessage` / 非 AGC 的 `role=user`）在落盘侧被过滤，在运行态事件侧也必须被过滤（`direct_thread_visible_item`）。少一侧就会出现「实时比历史多出两条同文本用户条目、各自开出一个耗时 0 秒的假回合，重进页面又正常」这类只有其中一侧的事实源缺陷。
 - 搬运层不生成展示形状：Thread Manager 只下发脱敏原始条目（`itemType` 原样透传），工具卡片的 `kind`、标题、折叠摘要都由前端生成。
 - 条目身份只有一套：进队列前归一成一个 `itemId`。工具条目在 `project.jsonl` 里带两个 id（调用 id 与 response item id，调用与输出共用前者），归一只在 Rust 边界做一次，Thread Manager 与前端都不暴露第二个 id 概念。
-- 事件不带回合身份：DirectProject 同一时刻只有一个回合在跑，`turn.started` 无载荷、`turn.completed` 只带 `status`；前端 state 里只有一个 `turnRunning` 布尔，没有 `turnId`。`subscribe` 返回的条目、增量、请求与队列锚点都不带 turn id。
+- 事件不带回合身份：DirectProject 同一时刻只有一个回合在跑，`turn.started` 无载荷、`turn.completed` 只带 `status`；前端 state 里只有一个 `turnRunning` 布尔，没有 `turnId`。`subscribe` 返回的条目、增量、请求与队列锚点都不带 turn id。（**按 2026-09-23 ADR §5 补充**：`turn.started` / `turn.completed` 现在带 `userItemId`，由 `clientTurnId` 推导、不读盘回填；事件仍不带 turn id，判据仍是"只有一对逻辑回合事件"。）
 - 合并只在前端，规则只保留「先到定形、后到补空白」：第一次见到的快照决定卡片形状，后续快照只补输出与状态，不做逐字段优先级表。只有"后到信息一定更全"时才例外：正文取更长的一份、工具状态允许从 `running` 升级到终态、`updatedAt` 取较新的时间。
 - 前端不保留增量缓冲：`item.delta` 直接追加到运行态条目的正文（正文只增不减）。`turn.completed` 把当前回合的运行态条目并入历史再清空，条目既不消失也不重复。
 - 活动回合的唯一判据是「出现过 `turn.started` 且未出现 `turn.completed`」；进程重启后队列消失，历史里的半截回合一律按已结束渲染。
+- 终态事件只有 `turn.completed` 一种，它同时承载三种语义：`status !== "failed"` 是正常结束 / 中断 / 终止，`status === "failed"` 是**失败**，且必须再带 `failure { kind, message }`（`message` 已脱敏截断）。失败原因只走这一条通道：前端不再从命令返回或另一条 IPC 里另造失败文案，聊天里那条失败说明仍落在同一个展示位上（本轮最后一条助手气泡、只在运行期显示），只是数据来源换成事件载荷；命令返回只用于运行错误横幅与诊断留痕。
+- 宿主侧兜底：`turn.started` 发出之后才武装 Drop 守卫，正常写完终态即解除；panic、future 被丢弃、终态之前的早退由守卫补一条 `status="failed"` + `failure.kind="host-dropped"` 的终态，避免前端永远停在"还在跑"。已知边界见「影响」一节。（**按 2026-09-23 ADR §2 改写**：守卫换成"接单即登记"的占用对象，终态写出后占用才释放。）
+- 执行通道断开同样是失败终态，也必须带 `failure`：连接级故障（app-server 进程退出 / stdout 流断 / JSON 行越界）与回合事件通道关闭都算，`kind="transport-failed"`、`message` 用宿主当场写下的那份诊断（含 `exitStatus` 与 stderr 摘要，已脱敏截断）。宿主在检测到连接终止的第一时间把这条事实记到本回合的执行适配器上，终态判定再从适配器读：执行适配器的看门狗盯着同一个 `closed` 标志，用调用点局部变量会输给这场调度竞争，失败原因就只剩日志、界面只会看到"本轮已结束"。判据是"适配器是否已由宿主主动关闭"——宿主自己收束（正常终态 / 用户主动停止 / 预算与交付收尾）走的是同一个 `TransportClosed` 事件，但这些不算失败。
+- 终态由**事实**判定，不由收尾阶段反推：判定按优先级取「宿主当场记下的失败（通道断开 / 等待超时 / app-server 单方面中断）→ 本回合的错误结果是 Err → 只有收尾阶段的账本读不出来时才用交付报告」，**有载荷一定写 `status="failed"`**，没载荷才用收尾阶段推出来的 `status`。收尾会把 ledger 阶段推成 `Interrupted`，让阶段决定终态就会把已经失败的一轮讲成"已结束"。模型自报失败（原生 `turn/completed.status="failed"` 的 `error`，带 `codexErrorInfo` 分类）不为载荷新增输入字段：宿主把原生 `error` 的 `codexErrorInfo` 解析成 typed 分类后当作本回合的错误结果，走同一条通道进载荷；交付报告只说明"收束到哪一步"，不得顶掉原因。
+- 回合失败在宿主内部是 **typed** 的：`agent/direct_turn_error.rs` 的 `DirectTurnError` 每个变体自带字段（并发拒绝带两个 invocation id、模型失败带分类、超时带撞的是哪条上限、通道断开带宿主诊断），**调用级拒绝**（这一轮没有开始）与**回合级失败**（这一轮已开始并被判失败）不共用判据，分流只认 `is_turn_failure()`。判据不再对原因文本做子串匹配，`LlmError` 只在平台层入口出现一次（`DirectTurnError::from_model_call`）。线上载荷 `{kind, message}`、命令边界字符串与 CLI 返回值都由这一个出口投影出来，Rust 侧任何地方都不再解析它们。
 - 分页锚点取原始条目 id；一次翻页操作在前端自动连拉，直到出现可显示条目或 `hasMore=false`，上限 5 页。
 - `notify` 是唯一唤醒来源：`subscribe` 的 bootstrap 事件本身就是该 subscriber 此刻要处理的事件（游标已在队尾），前端直接 reduce 它们，不需要为了取这批事件再补一次 `consume`，之后完全由 `notify` 驱动，不设低频 tick 或任何轮询兜底。唯一例外是回执竞态：Rust 侧一注册完 subscriber 就开始 `notify`，前端却要等回执才知道自己的 `subscriptionId`，这段窗口内的通知只能记成欠账，回执到达后立刻补一次 `consume` 取回，否则该回合的尾部事件会卡在队列里等一个可能永不出现的下一次通知。
 - 迁移按一次干净切换落地：不做灰度、不做运行时开关、不双跑；允许提交序列里存在「新源已启用、旧代码尚未删除」的中间窗口，禁止反向的「新源未启用、旧源已删」。
@@ -50,7 +61,12 @@ AGC 项目开发聊天框当前同时从三处取数据：Direct 回合事件（
 
 - 旧项目磁盘上遗留的 `turn-stream.jsonl` / `tool-calls.jsonl` 保留不动，不迁移、不清理、不再由 DirectProject 聊天框读取。
 - 工具卡片的脱敏与截断必须在读取期执行一次，不能因为"原始条目已在磁盘"就把未脱敏内容直接渲染到界面。
-- 回合结束语义务必由 `turn.completed` 判定；缺少该事件的残留回合不得被渲染成运行中。
+- 回合结束语义务必由 `turn.completed` 判定（失败时同一事件带 `failure` 载荷，不新增事件类型）；缺少该事件的残留回合不得被渲染成运行中。
+- 两条已知边界，都**不**在本次补路径，且已被 [`【ADR】DirectProject命令接单化-2026-09-23`](./【ADR】DirectProject命令接单化-2026-09-23.md) 取代（§3、§2）：① 宿主进程被强杀（`kill -9`）时没有任何 `Drop` 会执行，但队列随进程消失，新进程的订阅 bootstrap 因此不会看到"有开始没结束"，界面不会卡在忙碌态；② `turn.started` 之前的失败按发生位置分流——接单**之前**的是拒单，根本不产生回合（不写用户条目、不写失败诊断），接单**之后**的由这一轮的占用对象统一收口成 `turn.completed`，不存在"有回合却没有事件解释"的路径。
+- 失败原因里的 `message` 是宿主侧脱敏 + 截断后的可展示文本，前端仍按既有口径做一次可见文案映射（`projectRuntimeVisibleError`），映射规则不因这次改动改变。
+- 执行通道断开时用户看到的仍是既有映射结果（诊断命中不了专门规则，落到通用兜底），真实诊断在事件载荷、宿主交付报告与运行日志里；把"连接断开"改成专门文案属于映射规则变更，不在本 ADR 范围内。
+- 模型自报失败时用户看到的也仍是既有映射结果（`codex-app-server-error:<kind>` 那张中文表），区别只是原因现在从事件载荷来、同时命令返回带出运行错误横幅——这就是"事件出聊天文案、命令返回出横幅"的既有分工；前端可见文案的映射规则不因这次改动改变。
+- **调用级拒绝**（同一 `clientTurnId` 并发复用 / 项目已有另一条回合在跑 / 权限策略拒绝 / 目录锚不定 / 输入校验 / 环境与凭据未就绪）不属于回合失败：这一轮没有开始，只把原因回给命令边界（界面出运行错误横幅），不写失败诊断、不发 `failed` 事件、不进交付报告。此前它们与回合失败混在同一层、共用同一份错误文本，现在分流只认 typed 判据。
 - 「活动回合的唯一判据」约束的是**原生回合**：界面上的「本地已发出、原生还没认领」是投影的展示态（`DirectChatTurn.state = 'awaiting-start'`），由本地在途用户条目身份派生，不构成第二套原生生命周期，也不参与 `turnRunning` 的判定。
 - 三层数据流、变量归属与一次发送的时序写在代码里：`apps/ai-game-creator-shell/src/view/project-development/chat/controller/useDirectProjectChatController.ts` 的模块注释；回合三态的定义与判据真值表在 `apps/ai-game-creator-shell/src/view/project-development/chat/conversation/directTurnPresentation.ts` 的 `DirectChatTurnState`。改判据时同步这两处与对应测试。
 - 验收证据是端到端行为，不是单元测试：回合进行中杀掉应用进程后重开项目，应看到部分文本与工具卡片按原顺序出现且不显示忙碌；正常结束后重进应与实时渲染一致；文件系统不得再新增 `turn-stream.jsonl` / `tool-calls.jsonl`。

docs/project-memory/plans/【实施计划】AGC模型目录上游同步-2026-09-24.md

@@ -0,0 +1,36 @@
+# AGC 模型目录上游同步实施计划
+
+| 字段 | 值 |
+| --- | --- |
+| Version | 1.0 |
+| Status | in-progress |
+| Date | 2026-09-24 |
+| Parent Milestone | `docs/project-memory/plans/【里程碑】AGC模型目录上游同步-2026-09-24.md` |
+
+## 修改边界与顺序
+
+1. **领域模型（`module-runtime/src/agc_models.rs`）**：删除写死的 `Default` 实现（原 `quality → gpt-6-astra`、`fast → gpt-5.6-luna`），新增 `from_upstream_models`：按上游模型名排序去重后生成目录项（`modelId`/`alias` = 上游原名，`id` = 模型名 slug，`enabled = true`），默认项取排序后第一项；新增 `resolve_requested`（未选或 `platform-default` 用默认项）。字段、校验规则（32 项上限、id/alias/model_id 约束）与 `resolve` 保持原样。
+2. **procedure（`spacetime-module/src/agc_models.rs`）**：`read_agc_model_catalog` 缺行返回 `AGC_MODEL_CATALOG_NOT_INITIALIZED`，不再返回内置目录；`save_agc_model_catalog` 不变。无表结构变化，不改 `migration.rs`。
+3. **api-server 目录模块（`src/agc_models.rs`）**：新增启动期 `ensure_agc_model_catalog_initialized`（读 → 解析/校验 → 缺行或非法则 `GET {控制面}/api/pricing?group=taonier` → 生成目录 → 按存量 revision 写回；冲突后重读确认可用）；上游请求 10s 超时、1 MiB 流式上限、禁止重定向、不带凭据；未初始化统一 `503` 文案；后台 PUT 增加未初始化门禁。
+4. **api-server 接线（`src/main.rs`、`src/external_api_keys.rs`）**：`try_restore_app_state_for_startup` 按 HTTP 角色调用初始化，失败只 `error!` 记录；抽出 `ensure_llm_router_url_allowed`（只校验地址/scheme，避免被已下线的固定模型哨兵挡住），`LLM_ROUTER_TOKEN_GROUP` / `router_control_origin` 供同步复用。
+5. **客户端与后台**：不改。`GET /api/llm/models` 形状、admin DTO、后台「AGC 模型」页、客户端 `select_game_creator_model` 校验全部保持原样。
+
+## 不改的部分
+
+目录字段语义、后台 DTO 与页面、公开 DTO 形状、客户端模型标识校验、`/api/external/v1` 与 OpenAPI、SpacetimeDB 表结构、Router provisioning/额度。
+
+## 验证命令
+
+- `cargo test --locked -p module-runtime --lib agc_models::`
+- `cargo test --locked -p api-server --bin api-server agc`、`... llm::`
+- `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml --bins configuration::`
+- `cargo fmt --all -- --check`（两套 workspace）、`npx vitest run apps/ai-game-creator-shell/tests/conversationModelSelect.test.tsx`、admin-web 页面定向 Vitest 与 typecheck
+- `npm run check:encoding`、`npm run check:doc-index`、`npm run check:spacetime-schema`、`git diff --check`
+- 运行时 smoke：本地 dev 栈清空 `agc_model_catalog` 后启动 api-server，确认日志 `已按上游模型列表初始化 AGC 模型目录`、库中 `catalog_json` 为「slug id + 上游原名 alias/modelId」、`GET /api/llm/models` 返回原名；再把上游地址指向不可达端口验证 `503` 与「无替代目录」。
+
+## 风险与回滚点
+
+- **上游端点与鉴权**：分组定价列表端点为实测确认的公开只读接口；若上游改版，同步失败只会让目录保持未初始化（接口 503 + 启动 error），不会写入错误模型。
+- **混合版本**：module 的缺行语义变化要求 module 与 api-server 同批发布/回滚；未升级的 api-server 会把自己的 AGC 接口打到 `503`（后台 DTO 未变，admin-web 可独立发布）。回滚点必须同时覆盖 module 与 api-server。
+- **存量目录**：结构合法的旧目录（含 `quality/fast`）不会自动重建，需要 owner 在后台修改或清空该行后重启。
+- **目录规模**：目录项上限仍是 32；上游在售模型超过 32 条时同步会失败并记录原因，需要 owner 在后台维护子集。

docs/project-memory/plans/【里程碑】AGC模型目录上游同步-2026-09-24.md

@@ -0,0 +1,56 @@
+# AGC 模型目录初始值改为上游同步
+
+| 字段 | 值 |
+| --- | --- |
+| Version | 1.0 |
+| Status | in-progress（实现与本地真实上游验证完成；生产发布未执行） |
+| Date | 2026-09-24 |
+| Parent Spec | `docs/technical/【技术方案】AGC后台模型别名与对话选择-2026-09-05.md` |
+
+## 背景与触发
+
+`agc_model_catalog` 缺行时，`read_agc_model_catalog` 兜底返回写死的初始目录（`高质量 → gpt-6-astra`、`快速 → gpt-5.6-luna`）。这两个模型已从上游 Router 移除，于是从未配置过目录的环境（新库、清库、本地调试）会把两个不存在的模型下发给客户端，选中后上游 `model_not_found`，必须人工在后台保存一次目录才恢复。
+
+## 目标
+
+1. 初始目录不再写死：api-server 启动期从上游分组定价列表生成，`alias` 与 `modelId` 都用上游原始模型名（不再填“高质量/快速”这类人工别名）。
+2. 拉不到就报错、不写替代目录，并在下一次启动继续重试，直到目录里有数据。
+3. **保持既有格式与契约不变**：目录字段（`id`/`alias`/`modelId`/`defaultModelId`）、后台页面与 DTO、`GET /api/llm/models` 形状、客户端模型标识校验都不变，不引入不兼容变更。
+
+## 不在本里程碑内
+
+- 不改目录字段语义与后台维护方式，不删别名/稳定标识概念。
+- 不做上游变化的自动跟随同步（由 owner 在后台维护）。
+- 不改 Router provisioning、额度与计费链路。
+- 不改 `/api/external/v1` 与 OpenAPI，不改 SpacetimeDB 表结构。
+
+## 合同要点
+
+- **初始化**：api-server（API/All 角色）启动时目录缺失、结构与当前定义不符或校验不通过即视为未初始化；此时请求 `GET {Router 控制面}/api/pricing?group=taonier`（公开只读、不带凭据），取 `data[].model_name`，按模型名排序生成目录：`modelId` 与 `alias` 为上游原名、`id` 为模型名 slug（小写字母/数字/`-`/`_`，同名冲突追加 `-2`）、全部 enabled、默认项取排序后第一项，并以存量 revision 写回自增。
+- **失败关闭**：拉取失败、空列表、响应超过 1 MiB、缺可解析 revision、写回失败都只记录 error，不写替代目录；未初始化期间 AGC 目录/对话接口与后台目录接口返回 `503`“模型目录未初始化”。
+- **重试口径**：只启动期尝试一次；失败不阻塞启动，下次启动重试，直到目录里有数据。请求侧无法触发同步。
+- **幂等与并发**：目录只取决于模型集合（排序后生成），重复同步一致；多实例并发只有一个写入成功，冲突方接受既有目录并校验其可用性。
+- **存量目录**：结构合法的目录不会被自动重建（包括旧版写死的 `quality/fast`），需要 owner 在后台改掉或清空该行后重启。
+
+## 依赖
+
+- `module-runtime`：`AgcModelCatalog::from_upstream_models`（slug 生成 + 默认项 + 校验），删除写死的 `Default` 实现。
+- `spacetime-module`：`read_agc_model_catalog` 缺行返回 `AGC_MODEL_CATALOG_NOT_INITIALIZED`。
+- `api-server`：启动期 `ensure_agc_model_catalog_initialized`；上游请求硬化（10s 超时、1 MiB 流式上限、禁止重定向、不带凭据）；`ensure_llm_router_url_allowed`（只校验地址，不绑定已下线的固定模型）。
+- 文档：主规范、后端数据契约、运维文档、decision-log。
+
+## 验收标准
+
+1. 空目录 + 上游可达：启动后目录自动生成（别名即上游原名），`revision` 自增一次，`GET /api/llm/models` 的 `displayName` 是上游原名，界面不出现内置模型名。
+2. 空目录 + 上游不可达/非 2xx/空列表：启动只记录 error、不写替代目录；AGC 与后台目录接口 `503`；上游恢复后重启即同步成功。
+3. 幂等：同一模型集合重复同步得到一致的目录与默认项。
+4. 目录领域校验（id/alias/model_id、32 项上限、默认项必须启用）与请求侧 `422`/`409` 行为与改动前一致。
+5. 回归：Rust 定向测试、AGC/admin-web 类型检查与定向测试、`npm run check:encoding`、`check:doc-index`、`check:spacetime-schema`、`git diff --check`。
+
+## 已决与待决
+
+- 已决：上游来源用分组定价列表（2026-09-24 实测：`/v1/models` 用管理 token 返回 401；管理面注册表会带出已下线、无路由绑定的模型）。
+- 已决：`id` 用模型名 slug，保持客户端标识校验契约不变。
+- 已决：初始化失败不阻塞启动，只在下次启动重试。
+- 已决：目录结构与既有 DTO/页面保持不变，本变更不引入不兼容改动。
+- 待决：是否需要“上游自动跟随同步”（当前不做）。

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

@@ -8,6 +8,124 @@
 - 代价与取舍：右键从"按下即弹菜单"变成"抬起才弹"（与 Windows 自身右键菜单一致）；预览内空白处的浏览器原生菜单被永久抑制；右键平移与节点菜单互斥（越过阈值后抬起不再弹菜单）；`grabbing` 光标在悬停到节点上时仍会被节点自身的 `cursor-move` 覆盖，与共享画布现状一致。本次只改 UI 编辑器预览：AGC 美术画布仍只有空格/中键平移，资源画布保留自己的右键平移实现，都不动，也不抽 `packages/shared`。
 - 验证方式：新增 `previewRightPanGesture` 纯状态机单测（阈值跨越、起点全量 delta、拖拽吞菜单 / 干净抬起开菜单、取消与失焦清理），并在 `previewRightPanDrag.test.tsx`、`previewRightPanGesture.test.ts` 补右键回归（含键盘菜单键 `button: -1` 不被拦截的用例）；运行 `npx vitest run`（定向文件）、`apps/ai-game-creator-shell` `npm run typecheck`、`npm run lint:eslint`、`npm run check:encoding`、`git diff --check`。
 
+## 2026-09-24 接单化 review 收口（第二轮）：失败载荷分类、拒单身份与提示口径
+
+- 决策（失败载荷的 `kind` 收成 typed 枚举）：新增 `DirectTurnFailureKind`（`Serialize + Deserialize + TS`，
+  `kebab-case`，7 个变体，含先前两份名单都漏登记的 `turn-interrupted`），`DirectTurnError::wire_kind`
+  返回 `Option<DirectTurnFailureKind>`。线上仍是 `{kind, message}`、取值不变，只有 TS 侧从裸 `string`
+  变成可穷尽收窄的联合类型；全仓没有按 `failure.kind` 分流的代码，它只给界面选语气。
+- 决策（并发拒单的两个身份是回合身份）：`DirectThreadManager::accept_turn` 冲突时返回占用对象的
+  `turn_id`，`DirectTurnReservation::accept` 把这一轮请求的 `clientTurnId` 传成
+  `incoming_invocation_id`。改动前这两项是进程内 UUID，`TurnAlreadyRunning` 的"同一轮仍在处理中"
+  分支永远命中不了，也与"回合身份由 `clientTurnId` 推导"的口径冲突。占用对象自己的 `token` 仍是
+  UUID（`complete_direct_thread_turn_if_reserved` 靠它配对），只换错误载荷里的两项。
+- 决策（目录锚不定的拒单不再写诊断）：`DirectTurnError::ProjectRootUnanchored` 从 `is_reportable()`
+  拿掉，与 `ProjectRootUnusable` 同类——符号链接 / 权限 / 目录被删都是用户自己就能修的文件系统事实。
+  改动前它被命令边界覆写成 `direct-codex-failure:v2` 收口文案，界面上那句"无法锚定 Direct 调用项目
+  目录：{cause}"被内部诊断串顶掉；现在界面按 `Display` 显示，也不再进 `.agent/runtime/errors`。
+  可留痕的拒单只剩 `environmentNotReady` / `hostStateUnavailable`。
+- 决策（认不出的拒单也要在聊天里有同级提示）：`environmentNotReady` / `hostStateUnavailable` 除上报 +
+  横幅外，再补一条与用户消息同级的提示——拒单没有接单、不产生 `turn.completed`，否则那条乐观用户
+  气泡后面永远没有解释（改动前的注释"宿主已经把它放进了 `turn.completed.failure`"对拒单不成立）。
+  文案走 `projectRuntimeVisibleRejectionError`：取宿主收口文案里已脱敏的摘要与建议，**不套阶段标签**
+  （拒单这一轮没有开始，阶段只会是默认值）；非结构化错误仍只走横幅（它可能发生在接单之后）。
+- 决策（失败说明的文案口径）：`projectRuntimeVisibleError` 补上宿主 `Display` 事实句的模式
+  （`执行通道已断开` / `等待模型回合结束达到硬上限` / `宿主任务提前结束` / `收尾历史失败` 一族），
+  并给落盘那档补上不带"失败"二字的事实句；不回落宿主原文（`TransportClosed` 的原文带 `exitStatus=` /
+  `stderrClass=`）。同时修掉收口文案的版本口径：解析只认 `v1`、宿主发的是多一段 `code=` 的 `v2`，
+  脱敏摘要一直命中不了。口径定为"不加模式就只会看到通用文案"，写在 `directTurnFailure.ts` 的注释里。
+- 明确不做：不改线上载荷形状与 `kind` 取值；不加新的失败阶段取值（拒单仍落默认阶段）；不动
+  `ProjectRootUnanchored` 之外的拒单分类。
+- 决策（连接死亡的失败事实先于看门狗可见）：`CodexAppServerInner::closed` 的语义定为"这一段已经收束 /
+  失败事实已经记下"，看门狗就盯着它，所以它不能再兼作死亡收口的去重标志——去重改用私有的
+  `connection_end_claimed`，`fail_game_creator_codex_app_server_connection` 不再置 `closed`，
+  `closed` 只在 `shutdown_game_creator_codex_app_server_inner` 里、`record_execution_turn_failure` **之后**
+  置位。改动前收口路径先置 `closed` 再做"两次加锁 + 一次日志写"，200ms 看门狗可能在这一段里抢跑，把
+  这一轮收束成 `Interrupted`，typed `TransportClosed` 记不进去，终态退化成"本轮已结束、没有原因"
+  （失败事实是在模型终态那一刻被快照的，晚补记无用，所以只能保证"事实先于可见性"）。代价是其它读
+  `closed` 的地方会晚几十微秒看到"连接已死"，两个并发的死亡观察者仍会各自走到幂等的收束函数。回归用例
+  `connection_death_records_the_failure_fact_before_the_watchdog_seals_the_turn` 卡住 stderr 摘要锁把窗口
+  拉成确定性，把看门狗真正跑起来钉这条（顺序反了就红）。
+- 决策（接单之后的失败不回命令返回值）：`chat_with_game_creator_direct_codex_typed` 在接单后的历史追加
+  写失败时仍然写 `turn.completed` 失败终态，但 `return Ok(())`——命令的 `Err` 只表示**拒单**。改动前同一
+  个失败从"事件里的说明"和"命令 `Err` 的横幅"两条通道下发（且 `EnvironmentNotReady` 会写诊断 + 上报），
+  前端又把 `Err` 当"这一轮没开始"，于是忙态与出队同时被事件和返回值两条路推。**不继续起整轮**：
+  `project.jsonl` 是这条对话的单一事实源，用户消息没落盘时继续跑只会得到一条没有开口用户消息的助手回复，
+  失败还会被静默。用例：Rust `a_history_write_failure_after_accept_closes_the_turn_instead_of_rejecting`
+  （恰好一条失败终态、不带拒单收口文案、占用释放）、前端 appSurface 的落盘失败用例（说明只来自事件且
+  恰好一条、忙态放掉、下一条能发）。
+- 影响范围：Rust `apps/ai-game-creator-shell/src-tauri/src/agent/{codex_app_server/mod.rs,direct_turn_error.rs,direct_turn_failure.rs,direct_turn_accept.rs,direct_thread_manager.rs,direct_runtime/user_input.rs}`；
+  前端 `src/features/agent-runtime/model.ts`、`src/view/project-development/chat/{conversation/directCodexConversation.ts,conversation/directTurnFailure.ts,controller/useDirectProjectChatController.ts}`、
+  `src/view/project-development/chat/generated/DirectTurnFailureKind.ts` 与
+  `tests/{agentRuntimeModel.test.ts,directThreadChat.test.ts,appSurface/chat-composer.suite.ts,appSurface/project-conversation.suite.ts}`；
+  文档 `docs/adr/【ADR】DirectProject命令接单化-2026-09-23.md`、`docs/technical/【实施计划】DirectProject命令接单化-2026-09-23.md`。
+- 验证：Rust `cargo test --bins "agent::"`（902 passed / 5 ignored）、定向
+  `cargo test --bins "agent::direct_turn_error"`（15 passed）、`cargo fmt`；前端
+  `npx vitest run tests/{appSurface.test.ts,directRunAnalytics.test.ts,directProjectTurn.test.tsx,agentRuntimeModel.test.ts,directThreadChat.test.ts}`
+  （277 passed / 9 skipped）、`npm --prefix apps/ai-game-creator-shell run typecheck`、`npm run check:encoding`、
+  `git diff --check`。真实客户端观感未复核。
+
+## 2026-09-24 接单化 review 收口：终态写点、返修控制流、终止判据与失败投影
+
+- 决策（终态的写点在整轮真正结束之后）：Direct 回合先固定终态判定的上下文，`turn.completed` 的写出
+  挪到执行结果收集、历史落盘、structured output 解析都定型之后，成功与失败共用一个写点。解析失败也是
+  这一轮的失败，落进同一份失败载荷；改动前终态先写、再解析，解析失败时终态已是 `completed`，占用对象
+  的兜底变成空操作，用户看到"本轮结束、没有回复、没有任何解释"。收尾结果因此拆成
+  `DirectTurnReport`（报告正文 + 解析结果），占用解除与终态事件一起走 `DirectTurnTerminalContext::write`。
+- 决策（封口返修要求是控制流，不是失败）：`HostOutcome::RepairRequired` 不再伪装成
+  `LlmError::InvalidRequest("validation-source-changed: …")`，改为 typed 的
+  `DirectTurnRunFailure::RepairRequired` → `DirectTurnError::RepairRequired`：不写终态、不进载荷、不上报，
+  由 `direct_runtime` 的返修循环写回提示词继续跑（与 `ReviewRequired` 同一族，次数上限仍留在产生侧）。
+  改动前它被判成 `failed` 终态、界面收到一条假失败，还会让同一个逻辑回合写出第二条终态。
+- 决策（用户按下的终止不算通道失败，判据收进 `fail_turn`）：失败事实的判据是
+  `!is_closed() && !host_stop_requested()`，不再由各调用点各写一遍 `!is_host_ending()`。用户点「终止」时
+  标志先置位、阶段后变，原来的窗口里到达的 `TransportClosed` 会把用户自己的终止记成 `transport-failed`。
+- 决策（登录态失效的两条分类路径统一可重试）：认证失败不再按"重跑整轮"处理，刷新失败与重试失败都按
+  可重试的回合失败呈现（用户可见文案可能多一句"可直接重试"，真实客户端观感未复核）。
+- 决策（失败载荷的健壮性）：前端 reducer 对 `failure.message` 做运行时判据（缺字段 / `null` 不再抛错，
+  与 `directTurnFailureNoticeText` 同口径）；交付报告兜底只读一次 `terminal_report`（两次读取之间状态可能
+  变化，`None` 不再被 `unwrap_or_default()` 变成空回复）；失败说明条目在无身份无时间时会撞成同一条
+  （已知边界，仅补注释）。
+- 明确不做：不改线上载荷形状（仍是 `{kind, message}`）；不给 DirectProject 回合补端到端集成用例（缺轻型
+  假 app-server 夹具），判据落在策略函数与适配器单测；不持久化"可见但不喂模型"的失败条目（TODO）。
+- 影响范围：`apps/ai-game-creator-shell/src-tauri/src/agent/{codex_app_server/{mod.rs,execution.rs},direct_runtime/{mod.rs,user_input.rs},direct_turn_error.rs}`、前端
+  `chat/{conversation/directThreadChat.ts,generated/DirectTurnError.ts}` 与 `tests/directThreadChat.test.ts`；
+  文档 `docs/adr/【ADR】DirectProject命令接单化-2026-09-23.md`、`docs/technical/【技术方案】DirectProject Codex原始历史与异常恢复-2026-09-04.md`。
+- 验证：`cargo test --bins "agent::"`（952 passed）、`cargo test --bins "direct_"`（475 passed）、定向
+  `codex_app_server`（102 passed）、前端 `directThreadChat.test.ts`（36 passed）与
+  `npm run ai-game-creator-shell:typecheck`、`npm run check:encoding`、`git diff --check` 通过。真实客户端观感未复核
+  （终态写点与终止竞态落在真实宿主收尾上，单测盖不住）。
+
+## 2026-09-23 Direct 回合错误改 typed：调用级拒绝与回合级失败分开
+
+- 回合失败在宿主内部改成 typed 的 `DirectTurnError`（`apps/ai-game-creator-shell/src-tauri/src/agent/direct_turn_error.rs`）：每个变体自带字段，调用级拒绝（并发复用同一 `clientTurnId`、另一条回合在跑、权限策略拒绝、目录锚不定、输入校验、环境/凭据未就绪）与回合级失败（模型调用失败、通道断开、等待超时、app-server 单方面中断、阶段失败）不共用判据，分流只认 `is_turn_failure()`。
+- 根因：改造前两层错误混在同一份字符串里，靠对原因文本做子串匹配决定"算不算失败""要不要反馈给模型""怎么给建议"，任何文案改动都可能静默改变分流；并发拒绝还只靠一个前缀字面量给前端识别。
+- 分类不再做文本匹配：原生失败分类只解析 app-server 写下的 `codex-app-server-error:<kind>` 结构化前缀，转成 `DirectCodexNativeKind` 后再 `match`。
+- 明确不做：不改线上载荷（仍是 `{kind, message}`）、不改命令边界签名（仍是 `Result<String, String>`）、不改前端可见文案映射与 `wire_kind` 取值；Rust 侧不再解析那份字符串，字符串只在 `Display` 一处生成。不给深层尚未 typed 的事实补 typed 出口，只留一个显式的桥变体并在注释里写明新分类必须先加 typed 变体。
+- 影响范围：`apps/ai-game-creator-shell/src-tauri/src/agent/{direct_turn_error.rs,direct_turn_failure.rs,direct_delivery.rs,direct_runtime/mod.rs,direct_runtime/user_input.rs,codex_app_server/mod.rs,codex_app_server/execution.rs}` 与 `apps/ai-game-creator-shell/src-tauri/src/cli.rs`；文档 `docs/adr/【ADR】DirectProject对话历史单一事实源-2026-09-16.md`。
+- 验证：`cargo test --bins -- direct_`（460 passed）、`cargo test --bins -- codex_app_server`（100 passed）、`cargo fmt --check`、`npm run check:encoding`、定向 `git diff --check`。整包 `cargo test --bins` 在本机被既有 `tests::provider` / `tests::project` 重型用例挂住（并发跑测试时另有一条锁竞争用例会假失败），非本次改动引入。真实客户端观感未复核。
+
+## 2026-09-23 ACL 提权修复按目标做 single-flight
+
+- 背景：`windows_acl_repair_target` 对 Managed 作用域返回的是「第一个读取被拒的祖先」，同一祖先下的多个项目会解析到**同一个** repair target；而唯一的去重只是单次调用内的局部 `attempted_targets`。于是启动页一次挂载（≤8 个最近项目并发检查）会启动同样多次 `powershell -Verb RunAs`，用户看到叠在一起的 UAC 弹窗（issue #498）。
+- 决策：新增进程级闸门 `acl_repair_gate`，key = `(规范化 repair target, scope)`。并发调用只允许一次真实提权，其余等待并复用**同一结果**；结果在冷却窗口内直接复用（成功 30s / 失败 15s / 用户取消 120s），等待窗口 60s 超时按失败关闭。leader 异常退出由 RAII 兜底记为失败并唤醒全部等待者，避免等待者被永久挂住。
+- 决策补充（key 归一化）：key 的路径半边经 `windows_acl_repair_gate_key` 归一化——去掉 `\\?\` / `\\?\UNC\` 前缀并统一小写。最近项目列表里同一项目实测同时存在 `\\?\C:\...` 与 `C:\...` 两种写法（客户端 localStorage 实测），不归一化就是两个 key，同一个目录仍会弹两次 UAC。这里刻意只做前缀与大小写归一而不 `canonicalize`：待修复目标恰恰是「读不动的目录」，解析不可靠。
+- 决策补充（冷却基准）：冷却从**结果落库**时刻算起，不是 leader 起跑时刻。UAC 弹窗会被挂着几十秒到两分钟，用起跑时刻会让 120s 拒绝冷却在用户应答前就过期，前端 15s/45s/120s 的整表重查紧跟着再弹一次。
+- 决策补充（leader 失效接管）：`leader_deadline`（默认 5 分钟）之后，新调用可以接管仍是 `running` 的 key；每个 leader 带令牌，被接管后旧 leader 迟到的结果直接丢弃，不会覆盖接管者的结果。真机上无人应答的 UAC 约 2 分钟自然超时，所以这个上限只兜「提权子进程真挂死」——否则该目标会永久按失败关闭（`clear_denials` 不清理 running，只能重启客户端）。
+- 错误类型化：用户取消 UAC 的错误统一带稳定标记 `AGC_ACL_ELEVATION_DENIED`，前端据此判定「不可自动重试」，不再依赖中文文案匹配。
+- 用户主动操作（打开/新建项目、文件选择器选择目录、重命名刷新）会调用 `clear_game_creator_acl_elevation_denials` 清除拒绝记忆，保证显式重试仍能再次请求提权。前端唯一入口是 `features/app-shell/aclElevation.ts` 的 `clearAclElevationDenials()`：最近项目 hook（`rememberRecentWorkspace` / `refreshRecentWorkspace`）与打开/新建链路（`useHomeProjectCreation.openProject`，覆盖行内打开与 picker）共用它；漏挂入口会让用户「点了打开立即失败、也不问授权」。
+- 未做：给提权子进程加有界等待（`Start-Process -Wait` 目前无超时）。理由：中断挂起的 UAC 流程比等待更糟，single-flight 已把并发弹窗收成一个，follower 的等待由 60s 窗口兜底。
+
+## 2026-09-24 DirectProject 状态条口径翻转、几何约束与对话 Markdown 容错
+
+- 背景：AGC DirectProject 对话区底部的「陶泥儿正在处理 / 已耗时 12.4秒」状态条同时退化三处：① 读秒 1 秒一跳（耗时文案不足一分钟显示一位小数，小数位却一秒才动一格）；② 窗口压矮时被挤扁（300px 高压到 33px、240px 时 24px，文字被 `overflow: hidden` 裁掉）；③ `turn.started` 之前（模型首 token 前，实测约十秒）整条卡片不出现，界面没有任何「正在处理」的交代。同批还修了对话 Markdown 的两处代码块问题（不换行把消息拉宽、粘在正文行里的围栏导致代码块解析错位）。
+- 决策（卡片口径翻转，**更正** 2026-09-22「卡片口径取保守」）：卡片与已耗时起点改读 `displayBusy`（本地命令在飞 ∪ 原生已确认在跑）与「最新一个**未结束**回合的用户发送时间」。理由：`turn.started` 要等宿主应答返回才发出，只认原生真相会让首 token 之前那段没有交代；窗口期这一轮确实已经交给宿主（本地命令在飞），文案不虚报「宿主已在跑」之外的东西。（**再更正** 同日：本地乐观气泡已删，已耗时起点改读该轮的 `turn.started.at`——运行中读实时值、收口后读盖在条目上的值；接单窗口里还没有这一轮的条目，卡片只报「正在处理」、这一段不读秒。卡片口径本身不变：仍读 `displayBusy`。）
+- 决策（那条预言的处置）：2026-09-22 那条写「若将来改成窗口期也显示卡片，`running` 在渲染层就没有消费者了，应把投影压成 `unfinished: boolean`」。本次改完后投影三态**仍有**消费者（**再更正** 同日：投影已压成两态 `running` / `finished`，`awaiting-start` 随本地乐观气泡一起删除；下面这两条消费者读的判据不变）——`DirectProjectTurn` 用 `state !== 'finished'` 做否定式判断、`state === 'running'` 挑流式正文，状态条也用 `state !== 'finished'` 定起点——所以不动 `DirectChatTurnState`，也不压缩成布尔。
+- 决策（状态条几何）：卡片在 `.project-chat-conversation` 这条定高 flex 列里必须 `flex: 0 0 auto`。它带 `overflow: hidden`，按 flex 规范该项的自动最小尺寸归零，是这条链上唯一还能被压缩的项；压缩只能由消息列表吸收。同一选择器只保留一条规则（几何 + 不可压缩），不留两份。
+- 决策（对话 Markdown 对模型输出的容错）：解析前先 `normalizeMarkdownFences` 再压缩空行；代码块 `pre` 与块内 `code` 各自都给 `whitespace-pre-wrap` + `break-words`。细则与判据见 `pitfalls.md` 同日两条。
+- 影响面：`apps/ai-game-creator-shell/src/{styles.css,components/ChatMarkdownMessage/index.tsx,view/project-development/chat/{DirectProjectChatView.tsx,components/DirectProjectConversation/DirectProjectConversation.tsx,controller/useDirectProjectTurnStatus.ts}}`；用例 `tests/{ChatMarkdownMessage.test.tsx,directProjectProcessStatus.test.tsx,appSurface/{chat-composer.suite.ts,project-development.suite.ts}}`。
+- 验证：`npx vitest run apps/ai-game-creator-shell/tests` 186 passed / 1 skipped（1874 条里 1860 passed / 14 skipped）；真实 Chromium 夹具复核读秒 100ms、窗口 900→220px 高度下卡片恒为 36px 不被裁、代码块换行与两类粘住围栏；变异验证（读秒改回 1000ms、删 `flex: 0 0 auto`、卡片退回 `nativeRunning`、停掉围栏归一化、换行类名退回）逐条变红。
+
 ## 策划 V1/V2 退役的现行边界
 
 - 旧策划 V1 和 Runtime V2 均已删除，当前策划入口统一使用独立 Design Agent。V1 被 V2 接替只描述历史过程，不表示 V2 仍在使用。
@@ -9332,14 +9450,52 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
 - 边界（A 仍未修）：`DirectProjectTurnUsage` 的 `Math.max(turn.endedAt, turn.startedAt)` 兜底没动，所以两类 `finished` 回合仍显示「耗时 0.0秒」——① 页面重进后读回来的历史回合（`turnEndedAt` 只是会话内展示缓存）；② 发送后没有产生任何原生事件 / 发送失败的本地回合。为什么会有这两类、修法与要产品确认的口径都写在代码里（`DirectProjectTurn.tsx` 的 `DirectProjectTurnUsage` 注释与 `directTurnPresentation.ts` 的 `DirectChatTurnState` 注释），改完删掉那段注释。
 - 验证：`tests/directProjectTurn.test.tsx`（新增 3 条渲染契约：`awaiting-start` 与 `running` 不显示终态文案且不折叠、`finished` 有终态时显示结束时间与耗时）；`tests/appSurface/chat-composer.suite.ts` 新增 `does not report a finished turn while the host has not acknowledged the send yet`（invoke 挂起、无任何原生事件时断言不出现「本轮结束于」）；变异验证：把 `state !== 'finished'` 退回 `state === 'running'` 后渲染契约用例变红，恢复即绿。定向 vitest、`appSurface.test.ts`（203 passed / 13 skipped）、`tsc`、ESLint、Prettier、`check:encoding`、`check:doc-index`、`git diff --check` 通过。真实客户端观感未复核。
 
-## 2026-09-22 宿主崩掉不再留下永远开着的回合：本地命令失败时按身份兜底收口
+## 2026-09-22 失败回合的终态：`turn.completed` 带 `failure` 载荷 + 宿主 Drop 守卫兜底
 
-- 背景：`turn.started` / `turn.completed` 是原生回合唯一的开闭配对，界面上的「正在处理」卡片与输入盒忙态都读 reducer 的 `turnRunning`。但 app-server 崩了、回合任务被中止或 panic 时没人补终态事件，事件流里就留一条永远开着的 `turn.started`：界面一直显示「陶泥儿正在处理」、输入盒一直排队（用户现场反馈）。
-- 决策（本地命令返回即这一轮在宿主那边收场）：`chat_with_game_creator_direct_codex` 以真失败返回时，controller 按本轮身份调用 `stopDirectThreadTurn`，只放掉「是否在跑」，**不写终态时间**——命令返回不等于知道这一轮真正的结束时刻，编一个只会让耗时变成假数。用户主动终止与「正在跑的是另一轮」两条不适用：前者宿主必然补终态，后者不是这一轮（不能顺手抹掉别人的回合）。
-- 决策（身份作用域 + 不复活）：`stopDirectThreadTurn` 只在 reducer 里的运行身份相同或为空时生效；收口记进 `commandClosedTurnUserItemId`，同身份迟到的 `turn.started` 不再把这一轮拉回运行态（迟到的 `turn.completed` 例外放行，仍要拿它补上真正的结束时间）。身份按 clientTurnId 唯一，所以这条记忆只挡它自己那一轮。
-- 影响面：`apps/ai-game-creator-shell/src/view/project-development/chat/{conversation/directThreadChat.ts,controller/useDirectThreadChatSubscription.ts,controller/useDirectProjectChatController.ts}` 与 `apps/ai-game-creator-shell/tests/{directThreadChat.test.ts,appSurface/chat-composer.suite.ts}`。
-- 验证：reducer 新增 2 条用例（兜底收口后同名 `turn.started` 不复活且真终态仍能补上结束时间；身份不同的回合不动），appSurface 新增 `stops claiming the turn is running when a failed send left turn.started open`；变异验证：拿掉 controller 里的兜底收口调用后该用例变红（界面仍显示「陶泥儿正在处理」），恢复即绿。
-- 边界（未做）：根因仍在宿主侧——要在进程内保证开闭配对，应由 Rust 在回合函数退出（含 panic / 任务中止）时补一条终态事件（drop 守卫）；本次只做到前端不再跟着说谎。另：兜底收口的回合没有终态时间，仍会落进「`finished` 但拿不到终态时间」那个已知缺口（终态文案要不要藏，见 `DirectProjectTurn.tsx` 与 `DirectChatTurnState` 注释里的 A 项）。
+- 背景：宿主崩在 `turn.started` 之后时没有任何终态事件，前端 `turnRunning` 永远为真，界面停在「陶泥儿正在处理」；同时失败在事件流里与正常结束同形（`turn.completed(status="failed")`，前端根本不读 `status`），失败文案只能从命令返回那条通道另造，同一次失败因此有两条通道、两份文案，而"这一轮结束了没有"只有事件说了算。
+- 决策（协议形状：复用，不新增事件类型）：终态事件仍只有 `turn.completed`。`status !== "failed"` 表示正常结束 / 中断 / 终止，不带载荷；`status === "failed"` 是失败终态，**必须**带 `failure { kind, message }` —— `kind` 为稳定分类（`timeout` / `model-failed` / `transport-failed` / `request-rejected` / `host-dropped`，只给界面选语气；**2026-09-23 追加 `environment-not-ready`**），`message` 为宿主脱敏 + 截断后的可展示原因。"是不是失败"只看两件事：`collect_result` 是 Err 就用错误本身当原因；`collect_result` 是交付报告但状态已判成 `failed` 就用那份报告当原因。
+- 决策（兜底覆盖全部收场路径）：`turn.started` 进入队列之后武装 Drop 守卫，正常写完终态即解除；panic、回合 future 被丢弃、终态之前的早退由守卫补一条 `host-dropped` 失败终态。Thread Manager 不改一行：`turn.completed` 本来就是 `lifecycle_anchor` 成员，失败终态天然顶替更早的 `turn.started`，重放不会把已收口的回合看成"还在跑"。（**已由 2026-09-23「DirectProject 命令接单化」取代**：守卫换成接单时登记的占用对象，接单前的早退改判为拒单、不再产生回合，`host-dropped` 只保留给"说不出原因"的一类。）
+- 决策（失败文案只有一条通道）：聊天里那条失败说明仍落在原来的展示位（本轮最后一条助手气泡、只在运行期显示、不写进 `project.jsonl`），数据来源换成事件载荷；命令返回只保留运行错误横幅（含 `read_agent_runtime_error_detail` 的长 detail）与诊断留痕，不再写聊天气泡。可见文案映射仍走既有 `projectRuntimeVisibleError` 规则，只是执行点从 controller 移到 reducer。
+- 明确不做：不为 `turn.started` 之前的早退（`turn/start` 请求失败、响应缺 `turn.id`、缺稳定 `clientTurnId`、历史注入参数构建失败）补事件或兜底路径 —— 它们不产生回合、也不会留下永远开着的回合；不为进程被强杀（`kill -9`）补前端判据。（**已由 2026-09-23「DirectProject 命令接单化」取代**：接单前的失败改判为拒单、由命令边界返回 typed 错误；接单后的这类失败由占用对象收口成 `turn.completed`；`kill -9` 的界面表现在新 ADR §2。）
+- 同日被取代的还有本条目里的另一条：命令返回只保留"运行错误横幅 + 长 detail"——`详情：` 引用与 `read_agent_runtime_error_detail` 已删除，失败说明也不再落命令边界（改由宿主投影写事件载荷与诊断池）。
+- 影响范围：`apps/ai-game-creator-shell/src-tauri/src/agent/{direct_thread_wire.rs,direct_turn_failure.rs,direct_thread_manager.rs,codex_app_server/mod.rs}`、`apps/ai-game-creator-shell/src/view/project-development/chat/{conversation/directThreadChat.ts,conversation/directTurnFailure.ts,controller/useDirectProjectChatController.ts}`、生成绑定与两侧用例；文档 `docs/adr/【ADR】DirectProject对话历史单一事实源-2026-09-16.md` 与 `docs/technical/【技术方案】DirectProject Codex原始历史与异常恢复-2026-09-04.md`。
+- 验证：见本条决策对应的提交记录（Rust 定向测试、reducer 与 appSurface 用例、`cargo test export_bindings` 后的生成绑定、`npm run check:encoding`、`git diff --check`）。
+
+## 2026-09-22 执行通道断开也是失败终态：诊断记在执行适配器上，不与看门狗抢时序
+
+- 背景：手工杀掉 codex app-server（`kill -9`）验证上一条修复时，回合确实收口了（界面不再停在"还在处理"），但**没有任何失败说明**：连接级故障走的是 `TransportClosed` 分支，那里用一句策略文案 `adapter.interrupt(...)` 收束成 `ExecutionPhase::Interrupted`，`lifecycle_status` 把 `Interrupted` 映射成 `status="interrupted"`，`direct_turn_failure` 因此返回 `None`，事件不带载荷、reducer 也就不落说明条目；真实诊断（`Codex app-server 已退出；exitStatus=signal: 9 (SIGKILL)；stderrClass=...`）只进了 `app_log!`。
+- 决策（失败事实记在执行适配器上）：新增 `ExecutionAdapter::transport_failed(diagnostic)` 与只读的 `transport_failure()`。连接级故障（`fail_game_creator_codex_app_server_connection`）与回合事件通道关闭（`TransportClosed` / 事件通道 `None`）都调它：先同步记下"本轮以传输失败收口"与原因，再把同一份原因补进宿主交付报告（`interrupt` 对已有终态不覆盖，报告只作旁证）。`lifecycle_status` 见到这条事实一律返回 `failed`，`direct_turn_failure` 因此产出 `kind="transport-failed"`、`message=诊断` 的载荷。原因不能存在调用点局部变量里：执行适配器的看门狗盯着同一个 `inner.closed` 标志，它可能先把回合收束成 `Interrupted`，而终态判定发生在收束之后。
+- 决策（区分"连接自己断了"与"宿主关的连接"，判据收在适配器里）：`transport_failed` 先看 `is_closed`——宿主自己收束（正常终态 / 用户主动停止 / 预算与交付收尾）时适配器先于连接置位 `closed`，那种情况下只按既有口径中断收口（原因照样写进报告），不记失败事实；调用点两条分支的判据保持原样（`!is_host_ending()`），不动它们的控制流。
+- 决策（载荷取诊断而不是交付报告）：`direct_turn_failure` 增加第三来源且优先级最高——通道断开时原因用宿主诊断（含 `exitStatus` / stderr 摘要），不用 `collect_result` 里那份只说"收束到哪一步"的交付报告；报告与载荷同源的说法只对"原因写进报告"这一步成立，事件载荷才是失败原因的唯一权威。
+- 明确不做：不改前端可见文案映射（诊断命中不了专门规则，仍落到通用兜底文案）；不给连接级故障补端到端集成用例（判据落在策略函数与适配器两层单测，DirectProject 回合路径缺轻型假 app-server 夹具）；`kill -9` 掉宿主进程本身仍没有 `Drop`，不在本次范围。
+- 影响范围：`apps/ai-game-creator-shell/src-tauri/src/agent/codex_app_server/{mod.rs,execution.rs}`、`apps/ai-game-creator-shell/src-tauri/src/agent/direct_turn_failure.rs` 与其单测；文档 `docs/adr/【ADR】DirectProject对话历史单一事实源-2026-09-16.md` 与 `docs/technical/【技术方案】DirectProject Codex原始历史与异常恢复-2026-09-04.md`。
+- 验证：`cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml direct_`（439 passed）、定向 `transport_failure` / `direct_turn_failure::`（10 passed，含新增三条：适配器把诊断记成失败终态且只认第一份原因、宿主自己关的连接不算失败、失败载荷优先取宿主诊断）、`cargo fmt --check`、`npm run check:encoding`、`git diff --check`。真实客户端观感未复核。
+
+## 2026-09-23 终态由事实判定：模型自报失败的原生错误投影进既有错误通道
+
+- 背景：app-server 老实报了 `turn/completed{status:"failed", error:{message, additionalDetails, codexErrorInfo}}`，界面却没有任何原因。两条通道同时哑：① 事件侧 `lifecycle_status` 拿收尾阶段当终态口径（执行适配器 `drain()` → `interrupt()` 把 ledger 推成 `Interrupted`），把模型报的 `failed` 改写成 `interrupted`，失败载荷因此永远产不出来；② 命令侧有执行许可时 `finish_model_attempt` 先返回交付报告，命令变成 Ok，运行错误横幅的前提也消失。原生 `turn.error`（带 `codexErrorInfo` 分类，前端 `projectRuntimeVisibleError` 有现成中文映射表）只在"没有执行许可"的 `Err` 分支里被读一次。
+- 决策（终态由事实判定，有载荷必 `failed`）：`direct_turn_terminal` 去掉 `model_status` 入参，判定按「宿主当场记下的失败（通道断开 / 等待超时 / app-server 单方面中断）→ 本回合的错误结果是 Err → 只有收尾阶段账本读不出来时才用交付报告」取原因；**有载荷一定写 `status="failed"`**，没载荷才用收尾阶段推出来的 `status`。收尾阶段的中断不再有终态否决权——这是本次修复的根因。
+- 决策（原生失败用投影，不扩载荷、不加入参）：`turn.error` 由既有的 `game_creator_codex_app_server_failed_turn_error` 投影成 `LlmError`，在 `"failed"` 分支里作为本回合的错误结果返回，于是走已有的错误槽位产出 `{kind, message}` 载荷；`RepairRequired`（返修请求）保持原语义优先。前端零改动——`projectRuntimeVisibleError` 现有映射直接命中 `codex-app-server-error:<kind>`；命令返回同时回到 Err，运行错误横幅恢复。
+- 明确不做：不新增事件类型、不给失败载荷加字段、不改前端可见文案映射；不给回合路径补轻型假 app-server 夹具（判据落在 `direct_turn_terminal` 与执行适配器两层单测）。
+- 影响范围：`apps/ai-game-creator-shell/src-tauri/src/agent/codex_app_server/{mod.rs,execution.rs}`、`apps/ai-game-creator-shell/src-tauri/src/agent/direct_turn_failure.rs` 与其单测；文档 `docs/adr/【ADR】DirectProject对话历史单一事实源-2026-09-16.md` 与 `docs/technical/【技术方案】DirectProject Codex原始历史与异常恢复-2026-09-04.md`。
+- 验证：`cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml --bins direct_`（442 passed）、`codex_app_server`（100 passed）、`cargo fmt --check`、`npm run check:encoding`、`npm run check:doc-index`、`git diff --check`。真实客户端观感未复核。
+
+## 2026-09-23 DirectProject 命令接单化：命令只接单，逻辑回合归 Thread Manager
+
+- 背景：`chat_with_game_creator_direct_codex` 一个命令调用覆盖整轮（校验 → 跑 → 交付验证），于是命令边界同时兼职"接单被拒"与"回合失败"两种回执：失败文案有事件载荷与命令 Err 两条来源，`withDirectCodexSessionRefresh` 的"刷新会话 + 重跑整轮"会重复落盘一条用户消息，认证重试只能挂在 Err 上；而回合边界又镜像 Codex 原生回合（`turn/start` 成功应答后才发 `turn.started`），"接单到 `turn/start` 之间"的失败（连不上 app-server、配置未就绪、历史注入失败、`turn/start` 被拒）没有任何事件可解释，命令一旦不 await 就会静默。
+- 决策（命令 = 接单 / 拒单）：命令只做 `clientTurnId` 校验 → 占用调用身份（只挡并发，早于工程准备）→ 工作流恢复 → 用户条目校验 → 工程准备 → 接单成立 → 用户条目落盘 → 起 codex，成功后立刻返回、不等回合。命令返回类型改成结构化的 `DirectTurnError`（ts-rs 已导出到 `chat/generated/`，与 `DirectThreadEvent` 同一套 `cargo test export_bindings` 流程）。
+- 决策（分流判据从"错误种类"改成"发生位置"）：**接单之前**的失败（目录、权限、输入、并发、工程准备未就绪、宿主状态取不到）是拒单——不产生回合事件、不写用户条目、不写失败诊断；**接单之后**的失败（连接、配置、历史注入、`turn/start` 被拒以及回合过程中的一切）是回合失败，只走 `turn.completed` 带 `failure` 载荷一条通道。`DirectTurnError::EnvironmentNotReady` 接单前后都可能出现，因此新增自己的失败分类 `environment-not-ready`（否则投影会写成 `model-failed`、界面语气就错了）。这条位置判据取代原先"调用级拒绝直通"的分支。
+- 决策（逻辑回合由 Thread Manager 拥有）：新模块 `agent/direct_turn_accept.rs` 按 thread 维护占用登记，`accept(thread, user_item_id, client_turn_id)` 在同一个临界区里完成"拒绝并发 + 登记占用 + 追加逻辑回合开始事件"；`DirectTurnReservation::finish(terminal)` 幂等写出 `turn.completed` 并释放占用，`Drop` 兜底补 `host-dropped` 终态。发点在接单时、不再镜像 Codex 原生回合（原生事件留在适配器内部，不再进事件队列），线上仍只有一对 `turn.started` / `turn.completed`。因此"接单成功 ⇔ 事件流里有开始且有结束"是结构性成立，不依赖实现者给每条早退路径补事件。并发锁与首页快照的口径：`DirectTaonierActiveInvocation` 退回纯单飞锁，首页"运行中的项目"改由 `list_direct_active_turns` 从 TM 的逻辑回合导出（`ActiveDirectTurn` 带快照字段，`DirectActiveTurnSnapshot` 移入 `direct_thread_manager.rs`），不再留两处事实。
+- 决策（回合身份由 `clientTurnId` 推导）：`turn.started` / `turn.completed` 的 `userItemId` 按 `direct-codex:{clientTurnId}:user` 算出（与前端 `directCodexConversationMessageId` 同规则），**不读盘回填**——开始事件发生在用户条目落盘之前，落盘本身也可能失败。
+- 决策（界面：同级提示、删除 `详情：`）：失败说明与接单被拒提示都与用户消息**同级**、按事件顺序排在它后面，不嵌在这条用户消息里；删掉 `详情：` 引用、它的正则解析与只服务详情展开的第二次 IPC `read_agent_runtime_error_detail`；顶部状态行只显示回合状态，不承载错误文本。前端按 typed 变体分流：认得的"前置条件不满足 / 用户参数无效"（`clientTurnIdMissing` / `clientTurnIdMalformed` / `turnAlreadyRunning` / `projectRootUnanchored` / `projectRootUnusable` / `permissionRejected` / `inputRejected` / `contentEmpty`）→ 出同级提示、不走 `captureAgentRuntimeError`；认不出的变体（`environmentNotReady` / `hostStateUnavailable`）以及非结构化错误 → 抛出，走既有捕获上报链路。
+- 决策（队列与埋点听回合终态，不听命令返回）：前端发送队列的放行改由"回合完成（终态事件）或接单被拒"驱动，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` 文案，不各写一套判据。
+- 明确不做：不给失败载荷加字段（不加 `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::"` 之类过滤跑。
+- 验证：Rust 定向 `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml --bins "agent::"`（949 passed）；前端 `NODE_OPTIONS=--localstorage-file=/tmp/ls-gen.json npm test`（4473 passed）；`npm run ai-game-creator-shell:typecheck`、`cargo fmt --check`、`npm run check:encoding`、`git diff --check` 通过。真实客户端观感未复核。
 
 ## 2026-09-23 后台 Dashboard「消耗泥点」改为对冲退还后的净消耗
 
@@ -9388,3 +9544,37 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
 - 影响面：`server-rs/crates/api-server/src/{config.rs,modules/game_distribution.rs}`、`server-rs/crates/shared-contracts/src/game_distribution.rs`、`packages/shared/src/contracts/gameDistribution.ts`、`src/components/game-distribution/gameDistributionGuards.ts`（含新增测试）、`deploy/{nginx,container,env}`、`scripts/check-game-distribution-media-e2e.mjs`、`package.json`、平台与运维主规范。
 - 边界：SpacetimeDB 表结构与公开契约字段不变（`entryUrl` 仍是 string），只是取值从绝对 URL 变为相对路径；历史版本已冻结的绝对值不改写，admin 页与详情页展示口径不变。线上 dev / release 的 nginx 已按同源路径改动并 reload，`/etc/genarrative/api-server.env` 已删除模板变量；api-server 未重启，新写入要等下次重启。
 - 验证：`cargo check -p api-server --tests`、`cargo test -p api-server game_distribution`（27 passed）、`cargo fmt --all --check`、`npx vitest run src/components/game-distribution`（57 passed）、`npm run check:nginx-spa-routes`、`npm run check:encoding`（5060 文件）、`npm run check:doc-index`、`git diff --check` 全部通过；三份 nginx 模板渲染后 `nginx -t` 语法通过；dev 线上实测 `/games/game_2dcd…4955/` 与 `./assets/index-2Ws3zHlS.js` 均 200。
+
+## 2026-09-24 DirectProject 失败说明按回合身份归位：开口用户条目发点提前到接单之后
+
+- 背景：用户在同一个项目里连发消息，每条都在**连接获取阶段**就失败（执行器版本未通过逐次审批协议验收），界面上"错误显示在用户消息上面"，上一轮还顶替本轮显示耗时（现场 15.6 秒），本轮气泡自成一轮显示 0.0 秒；后面再发一条，说明落进更早的分区里，用户以为"这条没报错"。区分两个 `turn/start`：逻辑回合的 `turn.started` 由接单动作发出（成对、一定有）；app-server 协议的 `turn/start` 请求在连接拿到之后才发。失败发生在后者之前。
+- 根因：本轮的**开口用户条目**（`item_completed`，身份 `direct-codex:{clientTurnId}:user`）原来在 app-server `turn/start` 应答之后才下发，于是"接单到 `turn/start` 之间"的失败没有用户条目可挂；前端 `buildDirectChatTurns` 按**条目顺序**分回合，失败说明只能落在上一轮末尾，而本轮的乐观气泡被排在所有正式条目之后 → 渲染成"错误在用户消息之上"。
+- 决策（宿主）：开口用户条目的**发点**提前到"接单成立、用户条目落盘成功、起 codex 之前"（`emit_direct_thread_user_item`，调用点 `direct_runtime/user_input.rs` 的命令主体），删掉 `turn/start` 之后那一处；线上仍然只有一处下发，不变式变成 `接单 → 开口用户条目 → 整轮里其余一切`。
+- 决策（前端）：回合归属只认**身份**——失败说明条目带 `turnUserItemId`（reducer 写），`buildDirectChatTurns` 按开口条目身份分组（同一身份的条目永远同一轮），本地乐观气泡按身份挂回自己的回合而不是另开一轮；reducer 的收口早退只挡重复终态，不再吞掉"订阅重建只回放生命周期锚点"时那条还没写进界面的失败说明（`direct_thread_manager.rs` 的 `lifecycle_anchor`）。
+- 影响面：`apps/ai-game-creator-shell/src-tauri/src/agent/codex_app_server/mod.rs`、`.../agent/direct_runtime/user_input.rs`、`.../chat/conversation/{directThreadChat.ts,directTurnPresentation.ts}`。
+- 边界：`project.jsonl` 里的用户条目依旧只在首屏 / 翻页时读进前端，本轮不改读取时机——开口条目的运行态下发 + 身份归位已经让"说明挂错回合"不成立。
+- 验证：宿主 `cargo test --bins "agent::"`、`the_opening_user_item_is_emitted_before_anything_that_can_fail_in_the_turn`、`direct_project_turn_does_not_forward_codex_user_echo_as_chat_items`（补上同一发点）；前端 `directTurnPresentation.test.ts` 的"本轮用户条目没到时，失败说明按身份挂回自己那一轮，本地气泡不再自成假回合"、`directThreadChat.test.ts` 的两条（身份字段、收口早退不吞说明）。
+
+## 2026-09-24 DirectProject 删掉本地乐观用户气泡：用户气泡只来自宿主条目
+
+- 背景：接单化之后，"接单窗口期"只服务本地乐观气泡（`awaiting-start` 展示态 + `pendingUserItemId` 身份）。上一轮把开口用户条目的发点提前到接单之后，"说明挂错回合"已不再需要气泡兜底；用户确认按"这条消息就像从来没存在过"处理，直接删干净。
+- 决策（不造用户消息）：删 `pendingUserItemId` / `beginTurnCommand` / `endTurnCommand`（忙态改由 `beginTurnBusy` / `endTurnBusy` 持有，宿主认领判据 = `turnRunning` 或收口计数变过）、权限确认重跑的 `messageAppended` 参数、`DirectProjectTurnInput.messageText`（含首轮 `directInitialTurnText`）、投影里的 `awaiting-start` 与本地用户气泡路径（展示态只剩 `running` / `finished`）；controller 不再需要 `assets`。
+- 决策（时间口径）：回合起点只认 `turn.started.at`、终点只认 `turn.completed.at`；用户气泡的时钟是宿主落盘 / 观测时间，不再有"本地更早的真实发送时刻"（`sameIdentitySentAt` 删除）。两边都拿不到（重进项目读回来的历史回合）时整条「本轮结束于 … 」隐藏，不再兜出 0.0 秒。
+- 决策（本地说明）：拒单提示带自己的身份（`…:rejected`），投影据此在会话末尾自成一组，不挂进上一轮；壳层 `announce`（无身份）照旧挂当前回合末尾。带身份的本地说明不开运行态标记，避免把真正在跑的那一轮读成已结束。
+- 代价（已知并接受）：接单窗口与订阅重建窗口里聊天区没有这一轮的显示，反馈只有 composer 忙态、状态行与「陶泥儿正在处理」卡片（卡片这一段还读不出「已耗时」——起点是宿主的 `turn.started.at`，开始事件到了才开始读秒）；`project.jsonl` 用户条目依旧只在首屏 / 翻页读进前端。
+- 影响面：`apps/ai-game-creator-shell/src/view/project-development/chat/conversation/{directTurnPresentation.ts,directCodexConversation.ts}`、`.../chat/controller/{useDirectProjectChatController.ts,useDirectProjectTurnStatus.ts}`、`.../chat/DirectProjectChatView.tsx`、`.../chat/components/DirectProjectConversation/DirectProjectTurn.tsx`、`src-tauri/src/agent/codex_app_server/mod.rs`（用户条目时间的注释口径）、对应 ADR 与实施计划。
+- 验证：`npx vitest run tests/directTurnPresentation.test.ts tests/directProjectTurn.test.tsx tests/directProjectTurnStatus.test.ts tests/directThreadChat.test.ts tests/chatComposerAttachmentCap.test.tsx`、`tests/appSurface.test.ts`（213 passed / 9 skipped）、`npx tsc -p tsconfig.json --noEmit`、`eslint`、`prettier --check`、`npm run check:encoding`、`git diff --check` 全绿。真实客户端观感未复核。
+
+## 2026-09-24 AGC 模型目录初始值改为上游同步：不再回退写死的 gpt-6-astra/gpt-5.6-luna
+
+- 背景：`agc_model_catalog` 缺行时 procedure 兜底返回内置目录（`quality → gpt-6-astra`、`fast → gpt-5.6-luna`），两个模型都已从上游移除；从未配置过目录的环境（新库、清库、本地调试）会把不存在的模型下发给客户端，选中后上游 `model_not_found`。
+- 决策（范围）：本次只改目录初始值的来源，保持既有格式与契约不变 —— 目录字段仍是 `id`/`alias`/`modelId`/`defaultModelId`，后台页面与 admin DTO、`GET /api/llm/models` 形状、客户端 `select_game_creator_model` 的标识校验都不动，因此没有不兼容变更。
+- 决策（初始化）：api-server（API/All 角色）启动时目录缺失、结构与当前定义不符或校验不通过即视为未初始化；此时请求上游 Router 控制面的分组定价列表 `GET {控制面}/api/pricing?group=taonier`（公开只读、不带凭据），按 `data[].model_name` 排序生成目录：`modelId` 与 `alias` 用上游原名（不再填“高质量/快速”），`id` 用模型名 slug（小写字母/数字/`-`/`_`，同名冲突追加 `-2`，因此客户端标识校验无需放宽），全部 enabled，默认项取排序后第一项，并按存量 revision 写回自增。
+- 决策（来源选择，2026-09-24 实测后确定）：不用管理面模型注册表 `/api/models/`（会带出已下线、没有路由绑定的 `gpt-6-astra`/`gpt-6-luna`），也不用 `/v1/models`（要求 Router 用户 Key，用管理 token 实测 401）。当日 `group=taonier` 在售 6 个：`deepseek-flash`、`deepseek-v4-pro`、`glm-5.3`、`glm-5.3-flash`、`qwen-image-3.0`、`qwen3.8-flash`。
+- 决策（失败关闭与重试）：拉取失败、空列表、响应超 1 MiB、缺可解析 revision 或写回失败都只记录 error，不写替代目录；未初始化期间 `GET /api/llm/models`、`/api/llm/responses`、`/api/llm/chat/completions` 与后台 `GET/PUT /admin/api/agc-models` 返回 `503`“模型目录未初始化”；只在启动期尝试一次，下一次启动重试，直到目录里有数据。启动本身不因同步失败而失败，避免 Router 短时不可用放大成 api-server 起不来。
+- 决策（幂等与并发）：目录只取决于模型集合（排序后生成），重复同步结果一致；多实例并发启动只有一个写入成功，冲突方重读并校验既有目录可用性。目录只在未初始化时重建，上游变化不自动跟随。
+- 决策（存量目录）：结构合法的目录不会被自动重建，包括旧版写死的 `quality/fast` —— 需要 owner 在后台改掉，或清空该行后重启重新同步。
+- 影响范围：`module-runtime`（`from_upstream_models` + slug 生成，删除写死的 `Default`）、`spacetime-module`（缺行返回 `AGC_MODEL_CATALOG_NOT_INITIALIZED`）、`api-server`（启动期同步、上游请求硬化、只校验地址的目标校验、后台 PUT 未初始化门禁）、AGC 客户端（默认模型占位改为 `platform-default`）、AGC 模型弹层 CSS、主规范/后端契约/运维文档。
+- 验证：`cargo test -p module-runtime --lib agc_models::`（4 passed）、`cargo test -p api-server --bin api-server agc` 与 `llm::`、AGC 客户端 `configuration::`、admin-web 页面定向 Vitest 与 typecheck、两套 workspace 的 `cargo fmt -- --check`、`check:encoding`/`check:doc-index`/`check:spacetime-schema`/`git diff --check`。
+- 验证（真实上游 smoke，本地 dev DB）：清空 `agc_model_catalog` 后启动 api-server → 日志 `已按上游模型列表初始化 AGC 模型目录 revision=1 model_count=6`；登录后 `GET /api/llm/models` 返回同一批模型、`displayName` 即上游原名、默认项为排序后第一项；上游不可达/非 2xx 时启动只记录 error、AGC 接口 `503` 且目录保持未初始化；目录已存在时重启不重写。
+- 边界（未验证/残留）：上游在售模型超过 32 条时同步会失败（目录项上限未改）；`qwen-image-3.0` 这类图像模型会一起进入目录，是否对 AGC 隐藏由 owner 在后台停用；混合版本期间未升级的 api-server 会把自己的 AGC 接口打到 `503`，module 与 api-server 必须同批发布/回滚。

docs/project-memory/shared-memory/document-map.md

@@ -21,6 +21,11 @@
 3. `server-rs/crates/api-server/src/app.rs`、`server-rs/crates/api-server/src/modules.rs` 与对应 crate README / 源码
 4. `docs/openapi/genarrative-external-v1.openapi.json`（涉及 External v1 时）
 
+外部 MCP 语义工具设计：
+
+1. [外部 OpenAPI 与 API Key 接入方案](../../【后端架构】外部OpenAPI与APIKey接入方案-2026-06-19.md)：现役托管 MCP 与 External API 合同。
+2. [外部 MCP 语义工具说明与参数设计](../../technical/【技术方案】外部MCP语义工具说明与参数设计-2026-09-23.md)：15 个语义工具与全部旧工具并存，复用现有 API 分派和 schema；多功能入口使用 action/input，结果不裁剪，可选幂等只扩展新入口。语义工具按 operation 显式声明 destructive 风险，并汇总各 action；上传确认包含已有元数据更新风险。instructions 与 resources 已同步当前工具选择、调用流程及结果说明；资源 URI 保留，Skill 文档源与下载包共用，线上状态按实际部署核对。
+
 AI 游戏创作 / DirectProject / UI workflow：
 
 1. `docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md`

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

@@ -1,7 +1,25 @@
 # 踩坑与排障记录
 
+## 同一祖先下的多个项目会各自弹一次 UAC
+
+- **现象**：AGC 启动页一次挂载出现多个叠在一起的 UAC 提权弹窗；用户点「否」后仍会被再问一次。
+- **原因**：`windows_acl_repair_target`（`src-tauri/src/config.rs`）对 Managed 作用域返回「第一个读取被拒的祖先」——同一祖先下的多个项目解析到**同一个** repair target；而唯一的去重是单次调用内的局部 `attempted_targets`，跨调用、跨线程都没有记忆。启动页一次并发检查 ≤8 个最近项目，就会并发启动同样多次 `powershell -Verb RunAs`。
+- **处理**：进程级 single-flight（key = `(规范化 repair target, scope)`）+ 结果冷却（成功 30s / 失败 15s / 用户取消 120s）+ 等待窗口 60s 超时按失败关闭；leader 异常退出由 RAII 兜底唤醒等待者。用户取消带稳定标记 `AGC_ACL_ELEVATION_DENIED`，前端据此不自动重试；用户主动操作会清除拒绝记忆。
+- **不要踩的坑**：① 闸门 key 必须归一化 `\\?\` / `\\?\UNC\` 前缀——最近项目列表里同一项目实测同时存在 `\\?\C:\...` 与 `C:\...` 两种写法，按原始字符串做 key 会让同一个目录弹两次 UAC（`windows_acl_repair_gate_key`）；② 冷却必须从**结果落库**时刻算起，用 leader 起跑时刻会让 120s 拒绝冷却在 UAC 被挂着两分钟时提前过期，紧接着的自动重查立刻再弹一次；③ 复现「多个项目共用同一 target」时，DENY 要写在祖先的**父目录**上靠继承落入祖先——`icacls` 直接加在容器自身实测只影响子项（容器自身 `GetFileAttributes` 仍成功），target 会退化成每个项目自己，repro 不出并发弹窗；④ 夹具路径必须落在 `game_creator_private_path_allows_auto_elevation` 放行范围内（runtime config dir / `.config/genarrative` / 打包 AppData / 带 `.agent/manifest.json` 的项目根），因为提权子进程会按 **repair target** 再校验一次 `scope.allows_path`，否则失败关闭。
+- **验证**：`src-tauri/src/tests/acl_repair_gate.rs`（并发只执行一次、冷却复用、拒绝冷却、清除后可重试、follower 超时、leader panic 唤醒等待者、冷却基准、路径写法归一、leader 卡死接管与迟到结果丢弃）。真机复现（无需提权交互即可计数）：在 Managed 放行范围内建 8 个带 `.agent/manifest.json` 的假项目 → 对共同祖先的**父目录** `icacls <父目录> /deny *<sid>:(OI)(CI)(RX)` → 挂载启动页，同时数 `powershell.exe` 里命令行带 `RunAs` 的进程数（`Start-Process -Wait` 会让它一直存活到用户应答）与 `consent.exe` 峰值：修复前 8 个并发请求，修复后 1 个；把同一目录的 `\\?\C:\...` 与 `C:\...` 两种写法一起塞进最近项目，还能验证 key 归一化是否生效（修复前 2 个、修复后 1 个）。
+- **leader 卡死的兜底**：闸门只有 follower 的有界等待（60s），若提权子进程真的挂死（`Start-Process -Wait` 无超时），`leader_deadline`（5 分钟）之前该 key 一直被占住，之后新调用会接管并按新 leader 执行；被接管后旧 leader 迟到的结果按令牌丢弃，不会覆盖接管者。`clear_game_creator_acl_elevation_denials` 只清「被拒绝」记忆，不清理 running。
+- **关联**：`src-tauri/src/acl_repair_gate.rs`、`src-tauri/src/config.rs`、issue #498。
+
 > 策划历史条目边界：旧策划 V1/V2 已全部退役，当前入口仅使用 Design Agent。下文带日期的旧 Planning V2、Fast GDD、`plan.submit_gdd`、旧 IPC/模块记录仅用于追溯，不能作为恢复旧代码、身份门禁或专属测试的依据；共享问题需在现役调用上核查。现行合同见[策划 Agent 生产迁移与工作区浏览](../../technical/【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md)。
 
+## 2026-09-24 模型输出的围栏会粘在正文行里：聊天 Markdown 必须先归一化再解析
+
+- **现象**：AGC 对话里代码块解析错位——引言行被当成代码渲染（`…实现细节（game.js）：```js`），或者代码块收不住、把后面的正文一起吞进去（`… return centerOn(projection); }````）。文本本身「看起来没问题」，容易被当成渲染器坏了。
+- **原因**：CommonMark 只认**整行**的围栏（最多 3 个空格缩进）。模型经常把 ``` 直接粘在上一行末尾，那个 ``` 退化成行内文本：开场围栏不成立（后面的正文被当成代码）、收场围栏不生效（代码块不闭合，吞掉剩余内容）。`ChatMarkdownMessage` 原先只做空行压缩，没有这一步归一化。
+- **处理（现行口径）**：`normalizeMarkdownFences` 在解析前把「围栏前是非空白字符、围栏到行尾只剩语言标识（可空）」的行拆成两行。判据刻意收窄：整行 / 缩进围栏、行内代码（单个反引号）、代码里出现的 ``` （`const s = "```";`）、引用块 / 列表项开头的合法围栏（`> ```js`、`- ```js`）以及同一行里出现第二段围栏串的行内代码（``文本 ```x``` ``）都不动——后三者拆开只会把围栏从引用块 / 列表项里挪出来，或者凭空造出一个开场围栏。归一化对 `preserveBlankLines`（文件预览）同样生效。
+- **同时**：块级 `pre` 与块内 `code` 都要给 `whitespace-pre-wrap` + `break-words`（两处各写过 `white-space`，只改一处不换行），否则窄面板里长行会把消息拉宽、顶出横向滚动条。
+- **验证**：`npx vitest run apps/ai-game-creator-shell/tests/ChatMarkdownMessage.test.tsx`（去掉归一化或换行类名即红）；真实 Chromium 夹具里长代码行 `horizontalOverflow: false`、粘住的开场 / 收场围栏都渲染成正确结构。
+
 ## 2026-09-24 对话过程卡的读秒退回 1 秒一跳：刷新粒度必须与显示精度同格
 
 - **现象**：AGC DirectProject 对话区底部那条「陶泥儿正在处理 / 已耗时 12.4秒」的状态条，小数位一秒才动一格，看着像读数卡住；同一屏里工具卡片的耗时与资源生成侧栏的读秒都在正常走 0.1 秒，只有这一处不动。
@@ -5966,3 +5984,19 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 - **处理（现行口径）**：`createChannelConfig()` 从基线 `src-tauri/tauri.conf.json` 读完整 client 窗口对象后展开、只覆盖 `title`（`readBaseClientWindow()`），渠道配置不得再出现"只写 `title`"的窗口对象。新增守卫：`build-release.test.mjs` 用同语义的 merge patch 复现 Tauri 合并并断言 `label=client` / `decorations=false` / 1280x800 / min 1280x720 且承载 `http:default` 的 capability 必须包含该 label；`check-config.mjs` 增补基线 `decorations !== false` 失败关闭。
 - **验证**：`node --test apps/ai-game-creator-shell/scripts/build-release.test.mjs scripts/cargo-features.test.mjs scripts/release-oss.test.mjs scripts/prepare-macos-codex.test.mjs`（60/60）、`node apps/ai-game-creator-shell/scripts/check-config.mjs` 通过；`createChannelConfig('dev', …)` 实测输出含 `label: client` 与 `decorations: false`。修复后的安装包尚未重新构建与安装，真机观感与登录链未复核。
 - **关联**：`apps/ai-game-creator-shell/scripts/build-release.mjs`、`apps/ai-game-creator-shell/scripts/build-release.test.mjs`、`apps/ai-game-creator-shell/scripts/check-config.mjs`、`apps/ai-game-creator-shell/src-tauri/capabilities/main.json`、`docs/technical/【技术方案】AGC客户端更新检查与下载-2026-08-31.md`。
+
+## 2026-09-24 DirectProject 失败说明显示在用户消息之上、下一条消息看起来"没报错"
+
+- **现象**：连发几条消息，每条都在连接阶段失败（执行器版本未通过验收）时，界面上"错误出现在自己消息的上面"，上一轮底下显示"本轮结束于 <本轮结束时刻> · 耗时 15.6秒"，自己这条底下显示"耗时 0.0秒"；再发一条，失败说明落进更早的分区，用户以为这条没有报错。
+- **原因**：① 本轮的开口用户条目（`item_completed`）原来在 app-server `turn/start` 应答之后才下发，连接阶段失败走不到那一步 → 事件流里只有逻辑回合的一对事件，没有开口条目；② 前端 `buildDirectChatTurns` 按条目顺序分回合，失败说明（assistant 条目）只能挂在"当前回合"（上一轮）末尾；③ 本地乐观气泡被排在所有正式条目之后，于是自成一轮（无边界 → `Math.max(endedAt, startedAt)` 兜底出 0.0 秒），上一轮则借用了本轮的终点（15.6 秒）。另一条独立漏洞：reducer 的收口早退（`!turnRunning && live 为空`）会整条吞掉"订阅重建只回放生命周期锚点"时那条失败说明。
+- **处理（现行口径）**：开口用户条目的发点提前到"接单 + 落盘成功、起 codex 之前"（`emit_direct_thread_user_item`），线上仍只有一处下发；回合归属改成按身份（失败说明带 `turnUserItemId`，同一身份的条目永远同一轮），本地气泡按身份挂回自己的回合；收口早退改为"说明还没写进界面就不早退"（只补说明与终点，不重开回合、不抬高冻结终点）。
+- **排查提示**：先分清两层 —— 逻辑回合的 `turn.started` / `turn.completed`（Thread Manager，一定有、成对）vs app-server 协议的 `turn/start` 请求（连接拿到之后才发）。"失败说明挂错回合"永远先看这条顺序，不要先怀疑事件丢了。
+- **验证**：宿主 `the_opening_user_item_is_emitted_before_anything_that_can_fail_in_the_turn`、前端 `本轮用户条目没到时，失败说明按身份挂回自己那一轮，本地气泡不再自成假回合` 与 `收口早退不吞掉还没写进界面的失败说明（订阅重建只回放生命周期锚点）`。
+- **关联**：`apps/ai-game-creator-shell/src-tauri/src/agent/codex_app_server/mod.rs`、`.../agent/direct_runtime/user_input.rs`、`.../chat/conversation/{directThreadChat.ts,directTurnPresentation.ts}`、`docs/adr/【ADR】DirectProject命令接单化-2026-09-23.md`。
+
+## 2026-09-24 DirectProject「接单窗口里看不到自己刚发的话」是设计，不是丢消息
+
+- **现象**：按下发送后聊天区里不会立刻出现自己那句话；宿主还在接单 / 落盘的那段时间只能看到 composer 忙态、状态行与「陶泥儿正在处理」卡片（卡片这一段不读秒——起点要等宿主的 `turn.started.at`），滚动也停在原地。订阅重建的窗口同理。容易被读成"消息丢了 / 没发出去"。
+- **原因**：本地乐观用户气泡已删（ADR「DirectProject命令接单化」后续更新 2026-09-24）。用户气泡的唯一来源是宿主下发的开口条目（发点＝接单成立 + 用户条目落盘成功 + 起 codex 之前）。删它的收益是"回合归属只认身份"不再需要给本地消息一份同名身份，投影也少一个展示态（`awaiting-start`）。
+- **排查提示**：窗口期不要拿"有没有本地气泡"当发送成功的证据；证据是 `invoke` 返回 `Ok`（接单成立）与随后到达的 `turn.started` / 开口条目。显示时间与耗时也全以宿主事件为准：起点 `turn.started.at`、终点 `turn.completed.at`；重进项目读回来的历史回合两边都空，整条「本轮结束于 … 」直接隐藏（不再出现 0.0 秒）。
+- **关联**：`apps/ai-game-creator-shell/src/view/project-development/chat/conversation/directTurnPresentation.ts`、`.../chat/controller/useDirectProjectChatController.ts`、`.../chat/components/DirectProjectConversation/DirectProjectTurn.tsx`、`docs/adr/【ADR】DirectProject命令接单化-2026-09-23.md`。

docs/technical/【实施计划】DirectProject命令接单化-2026-09-23.md

@@ -0,0 +1,146 @@
+# DirectProject 命令接单化实施计划
+
+更新时间：`2026-09-23`
+
+状态：**四步全部落地**。
+
+设计口径见 [`【ADR】DirectProject命令接单化-2026-09-23`](../adr/【ADR】DirectProject命令接单化-2026-09-23.md)。
+本文件只排实施顺序、不变式与验收，不重复设计理由。
+
+## 第 0 步：文档与既有缺陷清理（已落地）
+
+- 设计定稿：ADR、`CONTEXT.md` 术语（逻辑回合 / 接单 / 拒单 / 在途回合）、两处旧文档的取代注。
+- 前端删除由 invoke 拒绝驱动的认证重试（`directCodexSessionKeepalive.ts` 只留会话保活）。
+- 用户可见文案不再带 `详情：` 引用、失败进错误上报池、失败说明不再写进项目历史，
+  只服务详情展开的 IPC `read_agent_runtime_error_detail` 已删除。
+
+## 第 1 步：Thread Manager 拥有逻辑回合（Rust，一个原子提交）——已落地
+
+改动点：
+
+- 新模块 `agent/direct_turn_accept.rs`：按 thread 维护占用登记。`accept(thread, user_item_id, client_turn_id)`
+  在同一个临界区里完成"拒绝并发 + 登记占用 + 追加逻辑回合开始事件"；`AcceptedTurn::finish(terminal)`
+  幂等写出 `turn.completed` 并解除占用；`Drop` 兜底补 `host-dropped` 终态。终态写出后占用才释放。
+- `direct_thread_manager.rs`：登记与事件追加共用同一把锁（没有第二张静态表）。
+- 删除了 `codex_app_server/mod.rs` 里镜像 Codex 原生回合的开始事件与终态追加，以及 app-server 侧
+  武装的 `DirectTurnFailureGuard`；终态统一交给 `AcceptedTurn::finish`。
+- `direct_thread_wire.rs`：`userItemId` 的说明由"从已落盘条目读取"改成"由 `clientTurnId` 推导"。
+
+不变式（已验证）：线上仍只有一对生命周期事件；同一 thread 任意时刻至多一个占用；`turn.completed`
+必带 `userItemId`。
+
+## 第 2 步：命令改接单 + 后台跑整轮（Rust）——已落地
+
+- 顺序固定为：`clientTurnId` 校验 → 占用调用身份 → 工作流恢复 → 用户条目校验 → 工程准备 →
+  `accept` → 落盘用户条目 → spawn 整轮。
+- 接单前的检查从 `run_..._and_emitter` 上移到命令；分流判据改成位置（接单后一律回合失败），
+  `EnvironmentNotReady` 增加 `wire_kind() = "environment-not-ready"`，"调用级拒绝直通"的分支作废。
+- spawn 出的任务在正常 / 失败 / 提前收场（早退：回合内任何没走到正常终态的收口点，如 `turn/start`
+  被拒、注入失败、panic）三条路径上都走 `AcceptedTurn::finish`；任务 panic 或被取消时由占用对象的
+  `Drop` 兜底。
+- 落盘即接单：接单成功后落盘用户条目，再起 codex；落盘失败仍是接单后的回合失败（有回合事件解释）。
+
+## 第 3 步：拒单返回 typed 错误（Rust + TS）——已落地
+
+- `DirectTurnError` 加 `Serialize + TS`（含嵌套枚举）并导出到 `chat/generated/`；命令返回
+  `Result<(), DirectTurnError>`，文案仍由 `Display` 生成一次随载荷带出。
+- 前端 catch 按变体分流（`readDirectTurnRejection` / `directTurnRejectionNotice`）：认得的
+  前置 / 参数类 → 与用户消息同级的提示、不走 `captureAgentRuntimeError`；认不出的 → 抛出；
+  状态行只显示回合状态。
+- 认可名单：`clientTurnIdMissing` / `clientTurnIdMalformed` / `turnAlreadyRunning` /
+  `projectRootUnanchored` / `projectRootUnusable` / `permissionRejected` / `inputRejected` /
+  `contentEmpty`；`environmentNotReady` / `hostStateUnavailable` 返回 `null`（抛出上报）。
+- 拒单**不结算埋点**（埋点句柄只清不发）。
+
+## 第 4 步：队列、埋点、快照、reducer（TS + Rust）——已落地
+
+- 前端队列放行改听"回合完成或拒单"：reducer 新增 `completedTurnCount`，作为放行与埋点结算的唯一
+  判据（不能用 `turnRunning` 的下降沿，一轮可能同批开始 + 结束）。**TODO（已写在代码里）**：这条
+  队列整体挪到 Rust 端，放行点就是 Thread Manager 的接单动作。
+- 埋点结算挂到回合终态事件：句柄活过命令返回，接单成功才在终态结算，接单被拒不结算。
+- 首页"运行中的项目"改由 TM 的逻辑回合导出（`list_direct_active_turns`）；`DirectActiveTurnSnapshot`
+  移入 `direct_thread_manager.rs`，`DirectTaonierActiveInvocation` 退回纯单飞锁，不留两处事实。
+- 删除取消占位的本地收口 `markTurnStopped()` 与 `turn.started` 的"重复起点保留第一次"兼容分支。
+- 本地在途标签（`awaiting-start`）活到宿主认领，认领三判据：`turnUserItemId === pendingUserItemId`
+  （身份认领）、`currentTurnRunning`、`completedTurnCount > pendingTurnBaselineRef.current`。
+
+## 验收证据
+
+- Rust 定向：`cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml --bins "agent::"`
+  （949 passed）；TM 单测覆盖并发接单被拒 / finish 幂等 / Drop 兜底 / 收口后可再次接单。
+- 前端：`NODE_OPTIONS=--localstorage-file=/tmp/ls-gen.json npm test`（4473 passed）、
+  `npm run ai-game-creator-shell:typecheck`。
+- 仓库门禁：`cargo fmt --check`、`npm run check:encoding`、`git diff --check`。
+- 手工：连发两条确认第二条不被丢；重进页面忙碌态正确；真实客户端观感未复核。
+
+## 已知坑
+
+- `project.jsonl` 与项目主对话共用信封类型，不要为了"可见但不喂模型"新增行结构。
+- 埋点 `settle` 早于成绩入库会静默丢事件（未来"进历史但不喂模型"的条目同理要落在注入侧，不在读取侧）。
+- `cargo test export_bindings` 会重写全部 `chat/generated/`（引号风格漂移），跑完要 `git checkout --`
+  掉不是本次新增的文件。
+- 本机 rust 全量 `--bins` 测试会挂在 mock server 的 `inet_csk_accept` 上，用 `--bins "agent::"` 之类过滤跑。
+
+## review 收口第二轮（2026-09-24）
+
+第 3 步的拒单表与第 4 步的界面口径按 review 收口后的状态为准：
+
+- 失败载荷的 `kind` 从裸 `string` 收成 typed `DirectTurnFailureKind`（7 个变体，含先前漏登记的
+  `turn-interrupted`）；线上形状与取值不变，TS 侧只是变成可穷尽收窄的联合类型。
+- 并发拒单（`TurnAlreadyRunning`）的两个身份改成回合身份：`existingInvocationId` 是占用对象的
+  `turnId`、`incomingInvocationId` 是这一轮请求的 `clientTurnId`；占用对象自己的 `token` 仍是 UUID。
+- 可留痕的拒单只剩 `environmentNotReady` / `hostStateUnavailable`：`projectRootUnanchored` 归到
+  "用户自己就能修"那一档，不再写诊断、界面按 `Display` 显示。
+- 聊天里的提示分两条通道：认得的拒单给 `Display` 原文；认不出的拒单（宿主 / 环境事实）除上报 + 横幅
+  外也补一条同级提示，文案取宿主收口文案里的脱敏摘要与建议（不带阶段标签）。失败说明的文案映射
+  口径见 `docs/project-memory/shared-memory/decision-log.md` 与 `conversation/directTurnFailure.ts`。
+- 第 1 步的命令返回值只剩"接单 / 拒单"两种含义：接单成立之后的一切失败（含接单后的历史落盘失败）由
+  占用对象收口成 `turn.completed`，命令一律返回 `Ok(())`；落盘失败**不继续起整轮**。
+- 第 2 步的"谁先到谁写"加一条前提：连接死亡的**失败事实必须先于看门狗可见**
+  （`CodexAppServerInner::closed` 不再兼作去重标志，去重改用私有的 `connection_end_claimed`，
+  `closed` 在 `record_execution_turn_failure` 之后才置位）；回归用例
+  `connection_death_records_the_failure_fact_before_the_watchdog_seals_the_turn` 把看门狗真正跑起来钉这条。
+## 回合顺序修复（2026-09-24）
+
+现场：用户在同一个项目里连发几条消息，每条都在 `turn/start` 之前失败（执行器版本未通过验收），
+界面上"错误显示在用户消息上面"，上一轮还显示出本轮的耗时（15.6 秒），本轮气泡自成一轮显示 0.0 秒；
+后面再发一条，失败说明落进更早的分区里，用户以为"这条没报错"。
+
+根因是**一条顺序**：本轮的开口用户条目原来在 `turn/start` 应答之后才下发，而失败说明按"当前回合"
+归位（前端按条目顺序分回合），于是接单后、`turn/start` 前的失败没有用户条目可挂。
+
+- 宿主：用户条目改成"落盘成功、起 codex 之前"下发（`emit_direct_thread_user_item`），删掉 `turn/start`
+  之后那一次；不变式：`接单 → 开口用户条目 → 整轮里其余一切`。
+- 前端：失败说明带 `turnUserItemId`，`buildDirectChatTurns` 按身份分组（同一身份的条目永远同一轮），
+  本地乐观气泡按身份挂回自己的回合而不是另开一轮；收口早退只挡重复终态，不再吞掉还没写进界面的失败说明。
+- 回归用例：宿主 `the_opening_user_item_is_emitted_before_anything_that_can_fail_in_the_turn`、
+  `direct_project_turn_does_not_forward_codex_user_echo_as_chat_items`（补上同一发点）；
+  前端 `本轮用户条目没到时，失败说明按身份挂回自己那一轮，本地气泡不再自成假回合`、
+  `失败说明带上它所属回合的身份，用户条目没到时投影层也能归位`、
+  `收口早退不吞掉还没写进界面的失败说明（订阅重建只回放生命周期锚点）`。
+- 已知边界：`project.jsonl` 里的用户条目依旧只在首屏 / 翻页时读进前端，本次不改这条读取时机——
+  开口条目的运行态下发与身份归位已经让"说明挂错回合"不再成立。
+
+## 删掉本地乐观用户气泡（2026-09-24）
+
+上一节的"按身份归位"落地后，本地乐观气泡只剩一个作用：把"接单窗口期"变成一种展示态
+（`awaiting-start`），并给投影多带一份与宿主条目同身份的本地用户消息。用户确认按"这条消息就像从来
+没存在过"处理，于是整套删掉。
+
+- controller：删 `pendingUserItemId`、`beginTurnCommand` / `endTurnCommand`；忙态保留（改叫
+  `beginTurnBusy` / `endTurnBusy`），宿主认领判据 = `turnRunning` 或收口计数变过（一轮在同一次
+  consume 里开始并结束）。同时删掉 `startTurn` 的乐观追加、权限确认重跑的 `messageAppended` 参数、
+  `DirectProjectTurnInput.messageText` 与首轮的 `directInitialTurnText`；controller 不再需要 `assets`。
+- 投影 / 渲染：`DirectChatTurnState` 只剩 `running` / `finished`；删 `localSentTimes` /
+  `sameIdentitySentAt`、本地用户气泡与它开回合的那条路径。本地说明保留：带身份的拒单提示在会话末尾
+  自成一组（不挂上一轮，也不造耗时文案），不带头身份的壳层 `announce` 照旧挂当前回合末尾。
+- 时间口径：起点只认 `turn.started.at`（运行中读实时值、收口后读盖在条目上的值），终点只认
+  `turn.completed.at`；用户气泡的时钟就是宿主落盘 / 观测时间。历史回合两边都是 0 → 整条
+  「本轮结束于 … 」隐藏，不再出现 0.0 秒。
+- 回归用例：`directTurnPresentation.test.ts`（本地用户消息不进回合、带身份的本地说明自成一组、
+  两态判据、失败说明按身份归位）、`directProjectTurn.test.tsx`（`running` 不显示终态文案；无边界的
+  历史回合整条隐藏）、`directProjectTurnStatus.test.ts`、`appSurface` 的
+  `keeps the accept window silent in the chat and busy in the composer`。
+- 已知边界：条目下发之前（接单窗口、订阅重建窗口）聊天区里没有这一轮的任何显示，只有 composer 忙态、
+  状态行与「陶泥儿正在处理」卡片（卡片这一段不读秒：起点要等宿主的 `turn.started.at` 到）；
+  `project.jsonl` 里的用户条目依旧只在首屏 / 翻页时读进前端。

docs/technical/【技术方案】AGC后台模型别名与对话选择-2026-09-05.md

@@ -1,5 +1,7 @@
 # AGC 后台模型别名与对话选择
 
+更新时间：`2026-09-24`。本次只改“目录初始值从哪来”：缺配置时不再回退写死的 `高质量 → gpt-6-astra`、`快速 → gpt-5.6-luna`，改为启动期从上游同步（这两条初始目录里的模型已从上游移除）。目录结构、后台维护字段和客户端契约都保持不变。
+
 ## 本地自定义 LLM
 
 - 本地 `game-creator.config.json` 的 `llm.customEnabled` 默认 `false`；显式设为 `true` 后，常用设置展示 API 地址、API Key、读取模型列表与勾选区域。DirectProject 沿用 OpenAI Responses 协议，地址填写 API 根地址（例如 `https://provider.example/v1`）。开关只由配置文件控制。
@@ -33,7 +35,11 @@
 ## 官方路由契约
 
 - 后台 owner 在“AGC 模型”维护列表；每项包含稳定 `id`、必填 `alias`、服务端 `modelId`、`enabled`。默认项必须启用。标识唯一，别名唯一，列表最多 32 项。
-- 配置保存到私有 `agc_model_catalog` 单例表，使用 revision 乐观锁，重启及多 api-server 实例共享同一事实。缺少配置时使用初始目录，高质量对应 `gpt-6-astra`，快速对应 `gpt-5.6-luna`。
+- 配置保存到私有 `agc_model_catalog` 单例表，使用 revision 乐观锁，重启及多 api-server 实例共享同一事实。
+- 目录初始值来自上游同步：api-server（API/All 角色）启动时检查目录，缺失、结构与当前定义不符或校验不通过都算“未初始化”；此时调用上游 Router 控制面的分组定价列表 `GET {Router 控制面}/api/pricing?group=taonier`（控制面地址由 `{LLM Router 地址}` 去掉 `/v1` 得到；公开只读接口，不带凭据），读取 `data[].model_name` 作为“该分组可见的在售模型”，按模型名排序后生成目录：每项 `modelId` 与 `alias` 都用上游原始模型名（不再填“高质量/快速”这类人工别名），`id` 是模型名的稳定 slug（小写字母、数字、`-`、`_`，同名冲突追加 `-2`），`enabled = true`，默认项取排序后第一项，并以存量 revision 写回（`revision` 自增）。不使用管理面模型注册表 `/api/models/`——它会残留已下线、没有路由绑定的条目；也不使用 `/v1/models`——它要求 Router 用户 Key，平台没有服务级 Key。并发启动的多个实例里只有一个写入成功，其余接受既有目录。
+- 同步失败（网络、非 2xx、空列表、响应超过 1 MiB、缺少目录行 revision、写回失败）只记录 error 日志，不写任何替代目录、不使用任何内置模型名；本次启动保持未初始化，下一次启动继续重试，直到目录里有数据。
+- 目录未初始化时 `GET /api/llm/models`、`/api/llm/responses`、`/api/llm/chat/completions` 与后台 `GET/PUT /admin/api/agc-models` 一律失败关闭（`503`），错误文案指向“模型目录未初始化”。恢复路径是修好上游可达性后重启 api-server，或由运维清空 `agc_model_catalog` 该行后再重启。
+- 上游变化不自动跟随：目录只在未初始化时重建；上游新增或移除模型由 owner 在后台增删条目或调整启用、默认项。
 - `GET/PUT /admin/api/agc-models` 仅 owner 可用，返回完整配置；PUT 携带上次读取的 revision，冲突拒绝覆盖。
 - `GET /api/llm/models` 返回启用项的 `id/displayName`、`defaultModelId` 和目录 `revision`，不返回实际模型名、Router 目录、凭据或能力原始数据。
 - 客户端缓存最近 `revision`，在项目切换 / 对话表面挂载 / 下拉展开 / 窗口聚焦时条件刷新：`revision` 未变化不更新界面，同一时刻只保留一个在途请求，刷新失败保留上一次有效目录与本地选择。发起对话前用同一份快照校验所选模型仍启用，已停用或删除则回退默认模型并提示。
@@ -48,6 +54,9 @@
 
 ## 验收
 
+- 空目录 + 上游可达：启动后目录自动生成（`id` 为模型名 slug、`alias`/`modelId` 为上游原名、`enabled` 全为真、默认项为排序后第一项），`revision` 自增一次，`GET /api/llm/models` 的 `displayName` 就是上游原名，界面不出现任何内置模型名。
+- 空目录 + 上游不可达/空列表/非 2xx：启动只记录 error，不生成替代目录；AGC 接口与后台目录接口返回 `503`“模型目录未初始化”；下游可恢复后重启即同步成功（不需要人工造目录）。
+- 同一模型集合重复同步结果一致（上游返回顺序不影响目录与默认项）。
 - 目录领域校验、未知/停用模型拒绝、客户端响应不包含实际模型名。
 - 后台鉴权、持久化 revision 冲突处理；客户端选择保存后重新读取，设置保存不覆盖选择。
 - 目录 `revision` 条件刷新与并发触发去重、发送前回退默认模型、刷新失败可恢复。

docs/technical/【技术方案】DirectProject Codex原始历史与异常恢复-2026-09-04.md

@@ -1,6 +1,12 @@
 # DirectProject Codex 原始历史与异常恢复
 
-更新时间：`2026-09-16`
+更新时间：`2026-09-23`
+
+> 注：本文件里"事件不带回合身份"、"`turn.started` 之前的早退不产生终态事件"这两条结论已被
+> [`【ADR】DirectProject命令接单化-2026-09-23`](../adr/【ADR】DirectProject命令接单化-2026-09-23.md)
+> 取代并落地：生命周期事件带可选的 `userItemId`，逻辑回合在**接单**时成对发出，接单之前的失败一律
+> 是拒单（不产生回合事件）。下文相关段落已按该 ADR 修订；"失败说明不写进 `project.jsonl`"仍是
+> 当前口径。
 
 ## 目标
 
@@ -27,13 +33,13 @@ DirectProject 自己的写侧只写新格式：格式切换（#282）时仍会
 ## 正常回合
 
 1. 启动 `ephemeral: true` 线程，并启用 `experimentalRawEvents: true`。
-2. 新线程先把历史 item 数组逐项投影为 Codex 可接受 item 后一次注入；注入成功后执行新的 `turn/start`。本轮 canonical user item 在发送前完成同样的投影校验，再写入项目历史。
+2. 命令**接单**后先写本轮 canonical user item（发送前完成同样的投影校验），再在后台起 codex；新线程把历史 item 数组逐项投影为 Codex 可接受 item 后一次注入，注入成功后执行新的 `turn/start`。这一轮的逻辑回合在接单那一刻就已开始，落盘与注入、`turn/start` 都在回合内，失败由这一轮的终态事件解释（见「异常回合收尾」）。
 3. 收到 `rawResponseItem/completed` 后立即追加其 `params.item` 并 flush。
 4. 正常 `turn/completed: completed` 不生成额外记录。
 
 ## 异常回合收尾
 
-AGC 判定本轮不会再产生新事件时收尾：用户中断、turn failed、无响应/idle timeout、硬超时、transport closed、stdout EOF 或 app-server 卡死终止均属于异常终态；正常 completed 不收尾。
+AGC 判定本轮不会再产生新事件时收尾：用户中断、turn failed、无响应/idle timeout、硬超时、transport closed、stdout EOF 或 app-server 卡死终止均属于异常终态；正常 completed 不收尾。终态出口只有接单时登记的占用对象一个：正常 / 失败 / 中断 / 取消谁先算出来谁写 `turn.completed`，都写不出时由它的 `Drop` 补 `host-dropped`。
 
 `item/agentMessage/delta` 正常带有 `itemId`；若协议异常缺失，AGC 记录 warning 并按当前 turn 生成稳定回退 id。AGC 在内存中按该 id 累计 assistant 文本，不实时写 delta。异常终态时，对仍有累计文本的 item 合成普通 Responses assistant `message` item：
 
@@ -55,7 +61,7 @@ Codex 启动时注入的 `host_skills.instructions`、`permissions.instructions`
 
 聊天界面只从 message item 提取 user/assistant 内容；工具 item 不再拼成 `tool: ...` 假文本。
 
-DirectProject 的浏览器层只负责显示和乐观状态，不再调用通用对话写入器。历史读写与回合累计分别位于 `agent/direct_project_history.rs` 和 `agent/direct_project_turn_history.rs`。
+DirectProject 的浏览器层只负责显示与本地忙态，不再调用通用对话写入器，也不再造用户消息（本地乐观气泡已删，见 [`【ADR】DirectProject命令接单化-2026-09-23`](../adr/【ADR】DirectProject命令接单化-2026-09-23.md) 的后续更新）。历史读写与回合累计分别位于 `agent/direct_project_history.rs` 和 `agent/direct_project_turn_history.rs`。
 
 `project.jsonl` 的 DirectProject 现行合同只允许 `response_item` envelope。其它模式产生的旧 conversation 行不属于本合同，不得注入 DirectProject。
 
@@ -112,8 +118,8 @@ Thread 内所有公开事件共用一个单调递增 seq，但 **seq 只是 Thre
 
 ```ts
 type DirectThreadEvent =
-  | { type: 'turn.started' }
-  | { type: 'turn.completed'; status: string }
+  | { type: 'turn.started'; at?: number; userItemId?: string }
+  | { type: 'turn.completed'; status: string; at?: number; userItemId?: string; failure?: { kind: string; message: string } }
   | { type: 'item.started'; item: DirectThreadItem }
   | { type: 'item.completed'; item: DirectThreadItem }
   | { type: 'item.delta'; itemId: string; kind: 'message' | 'reasoning'; delta: string }
@@ -122,12 +128,42 @@ type DirectThreadEvent =
 
 进入 Thread Manager 的是已经完成安全过滤和协议标准化的公开 raw event，不是未经审查的 app-server JSON。事件可交错包含多个并发 item：`item.started`、`item.delta`、`item.completed`、approval/request/resolved 事件，以及 `turn.started`、`turn.completed` 生命周期事件。前端按事件顺序 reduce，只用一个 reducer。
 
-**事件不带回合身份。** DirectProject 同一时刻只有一个回合在跑，`turn.started` 无载荷、`turn.completed` 只带 `status`；条目、增量、请求与生命周期锚点都不带 turn id。前端 state 里只有一个 `turnRunning` 布尔，历史条目也不记录回合身份。
+**回合身份只挂在生命周期事件上，且由 `clientTurnId` 现算。** DirectProject 同一时刻只有一个回合在跑；
+`turn.started` / `turn.completed` 各带一个可选的 `userItemId`（本轮开口用户条目的 canonical id，
+`direct-codex:{clientTurnId}:user`），`turn.completed` 另外带 `status` 与失败时必有的 `failure`。
+条目、增量、请求与生命周期锚点仍不带 turn id：这个字段只把"这一轮的边界属于哪条用户消息"讲清楚，
+不新增一套回合身份，**不读盘回填**（开始事件发生在用户条目落盘之前，落盘本身也可能失败）。前端 state
+里的 `turnRunning` 仍是唯一的活动判定，历史条目不记录回合身份；身份缺失时不猜历史归属。
+
+**终态只有 `turn.completed` 一种，失败靠 `failure` 载荷区分。** `status !== "failed"` 表示正常结束 / 中断 / 终止，事件不带 `failure`；`status === "failed"` 是失败终态，**必须**带 `failure { kind, message }`：`kind` 是稳定分类（`timeout` / `model-failed` / `transport-failed` / `request-rejected` / `environment-not-ready` / `host-dropped`，只给界面选语气，界面不拿它做流程分支），`message` 是脱敏截断后的失败原因。失败原因只走这一条通道——前端不从命令返回或另一条 IPC 里另造失败文案；`status="failed"` 却没有载荷视为协议违规。
+
+**接单之前发生的不是回合失败，是拒单。** 判据是**发生位置**而不是错误种类：目录、权限、输入、
+并发、工程准备未就绪这类"接单前就能判定"的失败由命令以结构化的 `DirectTurnError`（ts-rs 导出，
+载荷 = 变体 + `Display` 生成的一句文案）返回，不产生任何回合事件、不写用户条目、不写失败诊断；
+接单之后的连接、配置、历史注入、`turn/start` 被拒以及回合过程中的一切，都只走 `turn.completed`
+带失败载荷这一条通道。`EnvironmentNotReady` 接单前后都可能出现，因此它有自己的失败分类
+（`environment-not-ready`），不会被投影成 `model-failed`。
+
+执行通道断开（app-server 进程退出、stdout 流断、回合事件通道关闭）也走同一条终态：`kind="transport-failed"`，`message` 是宿主当场记下的诊断（`exitStatus` + stderr 摘要，脱敏截断）。宿主在检测到连接终止时**第一时间**把这条事实记到本回合的执行适配器上，终态判定再从适配器读——执行适配器的看门狗盯着同一个 `closed` 标志，若只在调用点用局部变量记录，会与看门狗的收束竞争，输掉时就只剩 `status="interrupted"` 加一句收尾说明，界面只显示"本轮已结束"、看不到原因。判据是"适配器是否已由宿主主动关闭"：宿主自己收束（正常终态 / 用户主动停止 / 预算与交付收尾）同样会发 `TransportClosed`，但那些不算失败。
+
+宿主的异常收场同样靠这条事件：**接单**时登记占用对象并发出 `turn.started`，占用对象持有这一轮唯一的
+终态出口——正常 / 失败 / 中断 / 取消谁先算出来谁写终态，都写不出时由它的 `Drop` 补一条
+`status="failed"` + `failure.kind="host-dropped"`，因此"接单成功 ⇔ 事件流里有开始且有结束"是结构性
+成立的，不依赖实现者记得给每条"接单后提前收场"（早退：回合内任何没走到正常终态的收口点，比如
+`turn/start` 被拒、注入失败、panic）的路径补事件。唯一的已知边界是宿主进程被强杀（`kill -9`）：没有任何
+`Drop` 执行，队列随进程消失，新进程的订阅 bootstrap 因此不会看到"有开始没结束"，界面不会卡在忙碌态。
+接单**之前**的失败根本不产生回合（见上一条：那是拒单），所以不存在"没有事件可解释的回合"。
+
+**终态由事实判定，不由收尾阶段反推。** `turn.completed.status` 不是收尾阶段的口径（`lifecycle_status` 只描述 ledger 阶段，没有终态否决权）：判定按「宿主当场记下的失败（通道断开 / 等待超时 / app-server 单方面中断）→ 本回合的错误结果是 Err → 只有账本读不出来时才用交付报告」取原因，有载荷一定写 `status="failed"`。模型自报失败（原生 `turn/completed` 的 `error`，含 `codexErrorInfo`）复用同一条通道：宿主把它投影成 `LlmError` 后当作本回合的错误结果返回，原因文本里带着 `codex-app-server-error:<kind>` 前缀（前端 `projectRuntimeVisibleError` 已有对应中文映射），既不为载荷新增输入字段，也不让交付报告顶掉原因。`RepairRequired`（封口复核要求继续当前返修批次）**不是失败**：它是控制流，有独立的 typed 变体（宿主侧 `DirectTurnRunFailure::RepairRequired`，跨界后是 `DirectTurnError::RepairRequired`），不写终态、不进失败载荷、不上报，由返修循环把它写回提示词继续跑；伪装成 `LlmError` 会让"继续返修"被讲成一次用户可见的失败，还会让同一个逻辑回合写出第二条终态。
+
+**终态的写点在整轮真正结束之后。** 执行结果收集（含执行器收尾）、历史落盘、structured output 解析都定型了才写 `turn.completed`，成功与失败共用这一个写点：解析失败也是这一轮的失败，必须落进同一份失败载荷。反过来（先写终态、再解析）会让"终态写完又失败"的回合在协议上无解——终态已经是 `completed`，占用对象的兜底变成空操作，用户看到的是"本轮结束、没有回复、没有任何解释"。
 
 一个 thread 同时最多有一个 active turn；一个 turn 内允许多个并发 item。`turn.completed` 必须在该 turn 的完成 item 均成功持久化后进入队列，前端据此结束运行态；不能用“不存在 unfinished item”猜测 turn 是否完成。
 
 前端 reducer 的活动回合判定只有一条：事件序列中出现 `turn.started` 且其后没有 `turn.completed` 时才是活动回合，界面才允许显示忙碌态。`subscribe` bootstrap 里没有这样的序列，就表示当前没有活动回合；Thread Manager 队列随进程消失，因此进程重启后历史里留下的半截回合一律按已结束渲染，前端不发明中断态，也不从历史条目反推忙碌态。
 
+失败终态与正常终态同权：`turn.completed`（无论 `status`）都顶替更早的 `turn.started` 成为队列锚点，重放时新订阅既不会把已收口的回合看成"还在跑"，也不会看到已经过期的失败原因。
+
 生命周期锚点独立于 replay 队列保存：`turn.started` / `turn.completed` 事件即使已被队列前缀回收，`subscribe` 仍必须把最新的一条作为 bootstrap 事件返回。因此进程内任意时刻新建订阅，都能判定最新回合是运行中还是已结束，不依赖"未完成 item 恰好还在队列里"。
 
 `item.started` 与 `item.completed` 必须携带与历史切片同形的**脱敏原始条目**（经同一套挑字段、脱敏、截断、路径归一），不得只给 item 类型或空 payload。前端不得依赖"按 `itemId` 单点取快照"补齐正文：Rust 不提供 `getItemSnapshot(itemId)`，未完成条目的正文随事件下发，已完成条目一律通过历史读取。

docs/technical/【技术方案】外部MCP语义工具说明与参数设计-2026-09-23.md

@@ -0,0 +1,387 @@
+# 外部 MCP 语义工具说明与参数设计
+
+更新时间：`2026-09-24`
+
+> 文档状态：`current`（工程实现合同；仓库已增加语义工具，线上可用性以实际部署版本为准）。
+>
+> 父规范：[外部 OpenAPI 与 API Key 接入方案](../【后端架构】外部OpenAPI与APIKey接入方案-2026-06-19.md)。
+>
+> 当前字段契约：[External v1 OpenAPI](../openapi/genarrative-external-v1.openapi.json)。本文记录工具划分、说明和参数合同；英文工具名、schema 构造、结果与兼容方式见第 5 节。
+
+## 1. 目标与范围
+
+在现有 API server 的托管 MCP 层增加按用户任务组织的工具。仅使用现有 External v1 已开放的能力，不直接接入尚未公开的画布功能。
+
+工具可以存在自然的功能交集：例如参考图快速变体同时属于生成图片和修改图片，读取画布同时服务于项目查找和布局编辑。不以工具数量或 API 唯一归属为目标，不把不相关任务硬合成一个工具。
+
+本文约定工具说明、操作选择、参数和业务边界，以及与当前工具配套的 instructions 和 resources。开发者发布页、文档存储与独立发布、CLI 改造不属于本轮范围。现有 REST 路由、DTO 和运行行为保持不变，新语义工具与全部原有工具并存。
+
+## 2. 当前实现与目标调用链
+
+当前 [external_mcp.rs](../../server-rs/crates/api-server/src/external_mcp.rs) 从 OpenAPI 自动建立原子工具：工具名由 `operationId` 转为 snake_case；description 优先读取 operation 的 `description`，缺省读取 `summary`，附加 HTTP 方法和路径；参数 schema 来自 OpenAPI。服务级 instructions 提供通用工作流，resources 提供详细说明。
+
+新工具继续部署在同一个 API server 内，复用现有分派和 External REST router：
+
+```text
+Agent 调用语义工具
+  → MCP 层选择对应 operation，并转换参数位置
+  → 进程内调用现有 External REST router
+  → 复用鉴权、scope、owner、校验、幂等、计费和业务处理
+  → MCP 返回业务结果或结构化错误
+```
+
+多功能工具的一次调用只选择一个操作。工具聚合不意味着批量执行、自动连续写入或新增跨操作事务。文件上传仍由调用方完成二进制传输。
+
+## 3. 说明与参数的共同设计
+
+### 3.1 工具说明
+
+每份说明包含：
+
+1. 用途：用户希望完成什么任务时选择本工具。
+2. 操作选择：多功能工具列出各 action 的用途，解释容易混淆的选择。
+3. 结果：立即返回业务结果，还是返回异步任务 ID；有哪些重要的降级或结果边界。
+
+字段格式、枚举、必填关系放入参数 schema 和字段说明，避免把全部接口校验细节堆进工具 description。付费、删除等重要影响应明确表达，但 description 和风险注解不替代后端权限校验；宿主负责结合用户已给出的授权作调用决策。
+
+### 3.2 多功能与单功能工具
+
+多功能工具采用 `action + input`，input 必须提供对应 action 的明确字段、类型、必填条件和枚举，不能只是任意 JSON 对象。服务端在分派前校验所选操作，避免不相干分支的参数混入底层请求。
+
+示意调用（示例 ID 仅为说明）：
+
+```json
+{
+  "action": "edit",
+  "input": {
+    "sourceReferenceId": "<resourceId-or-assetId>",
+    "prompt": "把衣服改成红色",
+    "projectId": "<projectId>"
+  },
+  "idempotencyKey": "<stable-logical-request-key>"
+}
+```
+
+单功能工具直接声明业务字段，不强行添加 action 或 input 包装。`kind`、`sliceMode`、视频 `mode` 等原有业务选择保留原名，它们与工具级 action 职责不同。
+
+工具参数中的 ID 由 MCP 层放入 REST 路径或查询，业务输入放入请求体，`idempotencyKey` 转为 `Idempotency-Key` header。具体参数保留现有命名、类型和条件；下表列的是关键字段，并非完整 schema 或排他白名单。未逐项列出的可选字段按对应 OpenAPI operation 核对，不把站内 DTO 的内部字段顺带开放。
+
+### 3.3 共用行为
+
+- 九类生成 POST 继续要求稳定幂等键，并返回 `202 + operationId`；工具不能把受理当成生成完成。
+- 项目创建、项目资源登记、文件夹创建的 REST API 支持可选幂等键，新语义入口提供并转发这些可选 header；原工具继续保持仅按 required header 推导幂等参数的行为。素材记录创建 API 不在该可选幂等合同中。
+- 相同 API 能力出现在不同语义入口时，参数约束、底层请求和结果语义保持一致。重试或切换入口恢复同一逻辑请求时，保留原 API 操作、规范请求和幂等键，不因换工具名创建新任务。
+- `projectId`、`assetFolderId`、`assetLabel`、`canvasCompletion` 等目标参数只在对应 API 支持时提供。UI 素材提取使用 `spritesheetLabel`；各生成族不共享未经核对的字段全集。
+- owner 由 API Key 确定，不让 Agent 指定身份，不把 API Key 放进工具参数。
+- 业务结果继续使用结构化返回；业务失败沿用安全错误语义，不把失败包装成成功。生成成功、素材登记、画布落位、切片成功分别按实际结果判断。
+- 读取、写入、付费与删除应在说明和注解中准确表达。注解作用于整个工具，因此将删除独立成工具；`openWorldHint` 不等同于付费标记。
+
+## 4. 工具说明与操作映射
+
+以下共 15 个新增工具。删除从项目管理、素材库整理中移出，统一放入 XV。本节说明仓库实现合同，不表示线上已部署。
+
+### I. 查找画布项目
+
+**说明：** 查找已有画布项目，或读取指定项目的完整内容。先通过列表或最近项目确定目标，再读取详情获取画布、图层和资源。
+
+| action | 关键参数 | 现有 operationId |
+| --- | --- | --- |
+| `list` | 无 | `listEditorProjects`，固定 `view=summary` |
+| `recent` | 无 | `loadRecentEditorProject` |
+| `get` | 必填 `projectId` | `getEditorProject` |
+
+列表使用既有摘要视图，不能退回全量项目快照。当前接口没有分页、limit 或名称搜索参数，工具不虚构这些字段。名称匹配基于读取结果；有歧义时向用户明确候选，不静默创建替代项目。
+
+### II. 管理画布项目
+
+**说明：** 创建新的画布项目，或修改已有项目的名称。
+
+| action | 关键参数 | 现有 operationId |
+| --- | --- | --- |
+| `create` | 可选 `title`；可选幂等键 | `createEditorProject` |
+| `rename` | 必填 `projectId`、`title` | `renameEditorProject` |
+
+一次创建仅创建项目，不默认追加创建同名素材文件夹。删除使用 XV。
+
+### III. 查找与读取素材
+
+**说明：** 查看账号素材库或指定项目中的资源，并为已有素材获取临时下载地址。
+
+| action | 关键参数 | 现有 operationId |
+| --- | --- | --- |
+| `list_library` | 无 | `getEditorAssetLibrary` |
+| `get_project_resources` | 必填 `projectId` | `getEditorProject` |
+| `get_download_url` | `objectKey` 或兼容的 `legacyPublicPath`；可选 `expireSeconds` | `getExternalAssetReadUrl` |
+
+项目资源查询复用项目详情，不新增资源查询 API。本次返回完整项目详情，资源位于其中的 resources；保持与项目读取相同的结构，不新增裁剪投影。
+
+读取素材记录、获取文件地址与查看媒体内容是不同操作。工具不提供本地下载、关键词检索或相似素材搜索。临时签名 URL 用于访问媒体，不作为持久化生成引用。语义入口保留 REST 的 `legacyPublicPath` 可选查询字段；优先使用稳定 objectKey，至少提供一种来源，由现有 API 校验来源，不改 REST 契约。
+
+### IV. 办理素材上传
+
+**说明：** 获取文件直传凭证，并在调用方完成上传后确认素材对象。文件传输由调用方执行。
+
+| action | 必填参数 | 常用可选参数 | 现有 operationId |
+| --- | --- | --- | --- |
+| `create_upload_ticket` | `legacyPrefix`、`fileName` | `contentType`、`pathSegments`、`maxSizeBytes` 等 | `createExternalDirectUploadTicket` |
+| `confirm_upload` | `objectKey`、`assetKind` | `bucket`、`contentType`、`contentLength`、`contentHash` 等 | `confirmExternalAssetObject` |
+
+流程为“申请凭证 → 调用方按返回的 OSS 表单直传参数上传 → 确认对象”。不把上传协议笼统写成固定 PUT。工具不接受本地路径或 base64，不代上传。对象确认后若需要项目资源或素材库记录，再调用相应登记操作；确认对象不等于完成这些登记。
+
+`ownerUserId` 由后端账号身份决定，不作为 Agent 可选参数。
+
+### V. 生成图片
+
+**说明：** 根据文字和可选参考图生成图片，支持普通图片、视觉规范、角色、UI 设计、宣发素材和快速参考变体。提交后通过任务 ID 查询结果。
+
+映射 `generateExternalEditorImage`，无需 action。
+
+| 参数 | 约束与用途 |
+| --- | --- |
+| `prompt` | 必填，生成内容描述 |
+| `kind` | 可选；省略表示普通图，其他用途为 `spec`、`character`、`quick-edit`、`ui-design`、`publication-material` |
+| `referenceImageSrcs` | 可选参考图；具体引用和组合约束沿用 API |
+| `model`、`aspectRatio`、`imageSize`、`size` | 可选输出配置，枚举及组合以当前 schema 为准 |
+| `style` | 可选风格；适用范围沿用对应 kind 的现有处理 |
+| `screenColor` | 可选纯色抠像背景色，见下文 |
+| 目标与落位字段 | 按当前接口支持提供项目、素材库和画布目标 |
+
+**背景色已经通过 API 开放。** screenColor 可传画布支持的颜色 hex，例如 `#CFEFFF`；传 `"auto"`、null 或省略，由服务端自动选择。它描述生成及后续抠图流程的纯色背景，不保证最终产物保留该底色；不能据此承诺“最终图片指定底色”或通用背景替换能力。
+
+不额外引入与 kind 重复的 action；不添加未开放的 `scene` 生成入口。
+
+### VI. 修改图片
+
+**说明：** 对已有图片做定向修改、生成参考变体或移除背景。定向修改使用已登记资源；快速变体通过参考图生成新版本。提交后通过任务 ID 查询结果。
+
+| action | 关键参数 | 现有 operationId |
+| --- | --- | --- |
+| `edit` | 必填 `sourceReferenceId`、`prompt`；其余为编辑 API 的可选字段 | `editExternalEditorImage` |
+| `variation` | 必填 `prompt`；参考输入使用 `referenceImageSrcs`；其他字段复用图片生成 | `generateExternalEditorImage`，适配层固定 `kind=quick-edit` |
+| `remove_background` | 必填 `sourceImageSrc`；可选 `backgroundMode`、条件允许的 `screenColor` 及目标字段 | `removeExternalEditorImageBackground` |
+
+来源参数保留真实差异：
+
+- edit 的 sourceReferenceId 只接受当前账号已登记的项目资源 ID 或素材 ID，不能用 objectKey 或 URL 代替。
+- 去背景的 sourceImageSrc 支持当前账号拥有的稳定 objectKey、项目资源 ID 或素材 ID，只处理允许的静态图片。
+- 变体的参考来源沿用生成 API；不新造含糊的统一 source 字段。其参考输入必填性、有效引用等条件沿用 quick-edit 的现有契约，不从图片生成 schema 只有 prompt 必填就推断所有用途无需前置条件。
+
+去背景 backgroundMode 省略或 null 时默认为 `complex`。complex 做语义分割；`flat` 用于纯色背景。screenColor 仅在 flat 下可传非 null 值，支持 `auto`、`#RRGGBB`，省略或 null 自动检测；complex 下传非 null screenColor 会被拒绝。不能直接照搬图片生成的全部背景色组合规则。
+
+需要原位替换时，编辑和去背景沿用各自 API 的 `projectId + targetLayerId` 来源绑定要求；不能用目标图层 ID 绕过账号归属与对象一致性校验。变体入口不额外承诺原位替换。
+
+variation 与 V 的 kind=quick-edit 是合理交集，复用同一输入定义、底层请求和结果语义，不让调用方重复提供固定 kind。
+
+### VII. 生成图标图集
+
+**说明：** 根据已登记的参考规范和图标清单生成图集，并按指定方式尝试拆分独立图标。
+
+映射 `generateExternalEditorIconSpritesheet`，无需 action。
+
+- 必填：`referenceId`、`iconDescriptions`、`sliceMode`。
+- referenceId 为当前账号已登记为 `icon-spec` 的项目资源或素材 ID，不接受 objectKey 或 URL 代替。
+- `sliceMode=grid`：提供需求对应的 `gridX`、`gridY`，各为 1–32，不传 sliceCount。
+- `sliceMode=connected-components`：可用 `sliceCount`（1–256）约束张数，不提供 gridX/gridY。
+- 可选：`referenceImageSrcs`、`screenColor`、`style`、模型、比例、尺寸及目标字段。
+
+sliceMode 没有默认值。主规范引用使用 referenceId，不用辅助 referenceImageSrcs 替代。此工具包含生成步骤，不是任意已有图片的通用裁切工具。切片未完成时可能仍有完整图集，结果必须保留 sliceWarning。
+
+### VIII. 提取 UI 素材
+
+**说明：** 以已有 UI 设计图为参考，生成组件素材图集并尝试拆分，供后续界面制作使用。
+
+映射 `extractExternalEditorUiDesignAssets`，无需 action。
+
+- 必填：`sourceImageSrc`、`aspectRatio`、`imageSize`。
+- 可选：`model`、`referenceImageSrcs`、`screenColor`、`spritesheetLabel` 和对应目标字段。
+- 结果命名沿用 spritesheetLabel，不强行改成其他生成接口的 assetLabel。
+
+接口包含生成过程，不保证把原图中的组件逐像素原样裁出。与 VII 的区别是：VII 以规范和明确图标清单生成，VIII 以已有 UI 设计图提取组件语义。两者都须分别判断图集与切片结果。
+
+### IX. 生成角色动画
+
+**说明：** 根据角色源图和动作描述，生成角色动画预览与帧序列。
+
+映射 `generateExternalEditorCharacterAnimation`，无需 action。
+
+- 来源必填：`sourceLayerId`、`sourceImageSrc`、`sourceWidth`、`sourceHeight`。
+- 动作必填：`promptText`。
+- 输出必填：`resolution`、`ratio`、`frameCount`、`durationSeconds`、`model`。
+- 可选：`screenColor`、`sourceResourceId`、目标与落位字段等。
+
+来源与尺寸先从真实资源中取得，不为简化调用伪造图层 ID 或源图尺寸。此工具不提供已有动画文件编辑。正式动画结果按现有帧序列合同消费，不重复用第一帧手工登记一份动画。
+
+### X. 生成视频
+
+**说明：** 根据文字和模型支持的参考图片、视频或音频生成视频片段。
+
+映射 `generateExternalEditorVideo`，无需 action。
+
+- 必填：`prompt`、`model`、`aspectRatio`、`durationSeconds`、`resolution`、`mode`、`sound`。
+- 可选参考：`referenceImageSrcs`、`referenceVideoSrcs`、`referenceAudioSrcs`。
+- 其他可选项：当前 API 支持的 `webSearchEnabled`、目标与落位字段等。
+
+保留 mode 作为视频业务模式，与工具级 action 无关。参考媒体、时长、分辨率、声音和其他选项的组合以所选模型的当前契约为准，不暗示每个模型支持所有组合。
+
+### XI. 生成音频
+
+**说明：** 生成音效或背景音乐。短声音、环境声和交互反馈选择音效；配乐选择背景音乐。
+
+| action | 必填参数 | 常用可选参数 | 现有 operationId |
+| --- | --- | --- | --- |
+| `sound_effect` | `prompt` | `duration`、`loop`、`model`、目标字段 | `generateExternalEditorSoundEffect` |
+| `background_music` | `gptDescriptionPrompt`、`makeInstrumental` | 目标与落位字段 | `generateExternalEditorBackgroundMusic` |
+
+当前音效 duration 是可选字段，省略或 null 表示自动，手动时长范围为 0.5–30 秒。不沿用“必须填写时长”的过期说法。两个分支保留各自提示词字段，不另外实现一套提示词翻译协议。两者均异步受理。
+
+### XII. 编辑画布
+
+**说明：** 读取画布、保存完整布局，或登记供图层引用的项目资源。保存布局需要基于最新画布版本。
+
+| action | 关键参数 | 现有 operationId |
+| --- | --- | --- |
+| `get` | 必填 `projectId` | `getEditorProject` |
+| `save_layout` | 必填 `projectId`、`viewport`、`layers`、`expectedRevision` | `saveEditorProjectCanvas` |
+| `register_resource` | 必填 `projectId`、`imageSrc`、`width`、`height`、`sourceType`；支持可选幂等键 | `createEditorProjectResource` |
+
+save_layout 保存完整默认画布布局，不提供只传一个图层的局部 patch 语义；expectedRevision 来自最新读取，版本冲突按现有 API 处理。
+
+register_resource 只登记资源，并不自动创建画布图层。正常生成结果落画布优先使用生成接口的 canvasCompletion。可选 objectKey、assetObjectId、assetKind、帧序列等字段按资源登记 schema 提供，不从临时 UI 状态推导正式来源。
+
+### XIII. 整理素材库
+
+**说明：** 管理素材文件夹和素材记录，包括新建、改名、移动以及登记已有媒体。
+
+| action | 关键参数 | 现有 operationId |
+| --- | --- | --- |
+| `create_folder` | 必填 `label`；可选 `sortOrder`、幂等键 | `createEditorAssetFolder` |
+| `update_folder` | 必填 `folderId`；可选 `label`、`collapsed` | `updateEditorAssetFolder` |
+| `create_asset` | 必填 `folderId`、`label`、`imageSrc`、`width`、`height`、`sourceType` | `createEditorAsset` |
+| `update_asset` | 必填 `assetId`；可选 `label`、`folderId` | `updateEditorAsset` |
+
+移动素材复用 update_asset 的 folderId，不额外拆一个重复操作。可选更新字段的有效性按现有 API 处理。create_asset 只登记元数据，不上传文件、不触发生成；生成接口已经完成入库时不重复登记。删除使用 XV。
+
+### XIV. 查看生成进度与结果
+
+**说明：** 查询一次已提交生成任务的当前状态。完成时返回结果，失败时返回错误；尚未完成时按建议间隔再次查询。
+
+映射 `getExternalEditorGenerationJob`，无需 action；必填 `operationId`。
+
+- 每次调用只查询一次，不在 MCP 服务端长时间阻塞到任务完成。
+- `queued/running`：读取进度和 pollAfterMs，继续等待。
+- `completed`：消费 result，并保留 warning 与 sliceWarning 等真实降级信息。
+- `failed`：返回已有脱敏错误。
+- 跨账号任务与不存在任务沿用同一不可见语义。
+
+收到 operationId 后优先直接查询。若提交响应丢失、尚未取得 operationId，不能靠查询工具凭空恢复：按现有幂等合同，复用原 API 操作、原请求和原幂等键重试以取得受理结果；不能换键重提。查询超时不改变服务端任务状态。
+
+### XV. 删除资源
+
+**说明：** 删除指定项目、素材文件夹或素材记录。按精确 ID 操作，调用前明确目标及删除范围，并取得对应用户授权。
+
+| action | 必填参数 | 现有 operationId |
+| --- | --- | --- |
+| `delete_project` | `projectId` | `deleteEditorProject` |
+| `delete_folder` | `folderId` | `deleteEditorAssetFolder` |
+| `delete_asset` | `assetId` | `deleteEditorAsset` |
+
+工具统一标记删除风险。项目删除沿用默认画布与项目资源元数据级联清理语义。文件夹删除将其素材记录移到默认文件夹，默认文件夹不能删除；素材删除删除记录并处理关联精选审核状态。文件夹和素材记录删除不等于删除底层 OSS 媒体。
+
+不增加批量、按名称或模糊匹配删除，不用一个可伪造的 confirm 参数替代真实用户授权和后端鉴权。
+
+## 5. 实现合同与验收
+
+### 5.1 工具名与兼容
+
+| 编号 | 工具名 |
+| --- | --- |
+| I | `find_canvas_projects` |
+| II | `manage_canvas_projects` |
+| III | `find_assets` |
+| IV | `prepare_asset_upload` |
+| V | `generate_image` |
+| VI | `modify_image` |
+| VII | `generate_icon_spritesheet` |
+| VIII | `extract_ui_assets` |
+| IX | `generate_character_animation` |
+| X | `generate_video` |
+| XI | `generate_audio` |
+| XII | `edit_canvas` |
+| XIII | `organize_asset_library` |
+| XIV | `check_generation` |
+| XV | `delete_resources` |
+
+现有 MCP 工具和 REST API 全部保留；旧工具名称、schema、注解、调用行为和可见性不变。新工具直接追加进同一个 tools/list，不加开关、不改旧工具前缀、不设隐藏目录。本轮包括工具说明和参数、instructions、resources 及其共用的下载 Skill 文档；独立配套 Skill、CLI、发布页与部署不属于本轮。
+
+### 5.2 参数与结果
+
+- 字段 schema 从对应现有 OpenAPI operation 构造，展开本地引用并保留嵌套类型、枚举、条件和字段说明。路径、查询与 body 字段平铺到单功能工具顶层或多功能工具的 input；不另写一份业务字段全集。
+- 多功能工具以顶层 object 加 oneOf 表达互斥 action，每个分支含 action 常量和完整 input schema。input 必填，无业务参数时传 `{}`。idempotencyKey 仅放在工具顶层：九类生成必填，项目创建、资源登记、文件夹创建可选，其它 action 不接受。
+- MCP 适配层在分派前校验 action、信封字段、所选分支允许的字段、必填参数及直接字段的类型/枚举/常量；嵌套字段值和业务组合继续由现有 REST DTO/校验处理，不创建第二套业务验证器。协议 schema 与分派校验共同限制错分支参数；未知顶层或 input 字段不能被静默丢弃。
+- variation 不暴露 kind，固定注入 `quick-edit`；对象确认不暴露或接受 ownerUserId。其余公开字段全部保留。稳定 key、原 API 与规范请求保持一致，重复语义入口不新增幂等命名空间。
+- 项目列表固定 summary。get_project_resources 返回完整项目响应，不裁剪；下载地址保留 objectKey、legacyPublicPath 与 expireSeconds。所有结果复用现有成功解包与结构化错误处理，不裁剪告警、revision 冲突或异步结果。
+- 读取工具标记 readOnly；含删除、覆盖或移动已有状态的工具标记 destructive；生成类说明付费及异步语义，可能替换已有图层的生成工具也按潜在破坏性标记。openWorld 仅用于会访问外部服务的能力，不作为付费标志。注解不替代用户授权或后端校验。
+- 语义工具的 destructive 按 API operation 显式声明，并取各 action 风险的并集，不根据 HTTP 方法或参数字段名推断。`prepare_asset_upload/confirm_upload` 可以更新同一 owner 的已有对象元数据，因此整个上传工具标记 destructive；申请上传票据本身仍属于新增操作。新增 operation 必须补充风险声明，原有工具的注解保持兼容。
+
+### 5.3 验收
+
+验证工具目录追加与旧定义一致、全部 action 路由与字段位置、必填和错分支拒绝、可选/必填幂等头、quick-edit 与普通生成入口等价、原 owner/scope 边界、结构化结果/告警和 revision 冲突透传。运行 api-server 定向测试与本地 healthz smoke；真实账号、付费 Provider 和具体 MCP 客户端尚未验证时明确记录，不能将单元测试当作线上验收。
+
+### 5.4 实现与验收结果（截至 2026-09-24）
+
+本轮工具、instructions 和 resources 更新完成。新增 15 个语义工具与原有 29 个工具同时可见，7 个资源 URI 保持不变。自动回归与本地业务主路径验证通过；真实生成测试发现的两项既有合同问题已独立记录在 [Issue #495](https://git.genarrative.world/git/GenarrativeAI/Genarrative/issues/495)，不在本轮修复，不能将主路径通过表述为全部合同验收通过。已完成的里程碑和实施计划收口到本节。
+
+| 验证范围 | 证据与结果 |
+| --- | --- |
+| 工具与参数合同 | `external_` 回归中的 25 项 `external_mcp` 测试通过，覆盖 44 个工具、31 个 action、旧定义保留、schema 展开、参数映射、错分支拒绝、必填/可选幂等、等价入口及 15 个语义工具的风险注解 |
+| 认证与既有 API 回归 | 2026-09-24 在包含最新 master、instructions、resources 和风险注解修复的分支上运行 `cargo test --locked -p api-server external_`：156 项通过，含 MCP 内外认证、scope 拒绝、跨 owner 隔离、异步及 OpenAPI 回归 |
+| 编译与文本检查 | `cargo check --locked -p api-server`、定向 rustfmt、文档索引、编码和 diff 检查通过 |
+| 本地服务启动 | 先通过 `npm run dev:spacetime` 启动 SpacetimeDB 2.8.3 并发布隔离数据库，再通过 `npm run dev:api-server` 启动同一目标的 API 和 worker；`/v1/ping`、`/healthz`、`/readyz` 均返回 200 |
+| MCP 真实 HTTP 链路 | 未认证返回 401；使用隔离数据库中的临时测试 API Key，initialize 成功，tools/list 返回 44 个工具且包含全部 29 个旧工具，resources/list 返回原有 7 个资源 |
+| 本地数据库读写 | 新工具创建/列表/重命名/读取/删除成功；同键重复创建返回同一项目；旧工具读写与新工具互通；重复语义读取保留完整项目；ownerUserId 额外字段被拒绝且未产生写入 |
+
+补充验证：
+
+| 验证范围 | 证据与结果 |
+| --- | --- |
+| 全工具业务主路径 | 2026-09-23 通过本地 MCP HTTP 实测 44 个工具，全部至少一次主路径成功；15 个语义工具及其 action 均执行，含实际 OSS 上传/确认/下载、资源登记、素材整理和画布 revision 保存 |
+| 真实付费生成 | 11 个任务全部 completed，覆盖普通图、编辑、变体、抠图、图标图集、UI 提取、角色动画、视频、音效、背景音乐及旧抠图入口；验证下载、媒体解码和持久化，无 warning/sliceWarning。动画持久化为 32 帧、4000ms；图集与 UI 用例分别产生 2 张和 1 张切片。两项额外合同检查失败另见 Issue #495 |
+| instructions/resources 与下载包 | 更新后 24 项 MCP 测试、2 项 Skill 归档及 manifest 摘要测试通过；10 个 JSON 示例可解析，其中 6 个业务请求示例通过现有 OpenAPI schema 校验；Skill 格式、编码、文档索引和 diff 检查通过 |
+
+运行核验使用独立测试身份和数据库，不经过真实用户登录或外部账号开通流程。初次 CRUD smoke 的测试项目和凭证已清理；后续付费全工具测试使用另一组独立凭证与产物，并在该轮结束时保留供复核，凭证不进入仓库。付费测试基于工具实现版本 `23b2a3325`；随后更新说明文档并完成合并后自动回归，未再次触发付费生成。服务当前是否运行需另行检查，本文不作为进程状态记录。
+
+未验证：真实用户登录/发放 API Key 全流程、外部 MCP 客户端对 oneOf 参数的展示与使用、远端部署、多模型和全部参数组合、容量压测与完整视觉质量。UI 提取使用简单测试图片，不代表复杂 UI 多组件质量验收。合并后仍需部署 API server，并通过实际 MCP 客户端核验工具发现、调用和资源读取。
+
+### 5.5 instructions 更新（2026-09-24）
+
+初始化响应的 instructions 只描述服务能力和跨工具共同约定，不引入“语义工具 / 原有工具”分类，也不重复单个工具的参数分支。具体参数以工具 schema 和说明为准，详细流程由 resources 提供。
+
+当前说明覆盖：按任务需要创建项目和素材文件夹、通过生成目标字段落画布或素材库且避免重复登记、付费异步提交与稳定幂等键、使用 `check_generation` 按返回间隔轮询、本地文件上传票据与实际传输分工、稳定媒体引用、按真实结果和告警判断完成情况。
+
+不再要求所有任务先创建同名素材文件夹或同时写入画布与素材库。查询超时不代表生成失败，不应因此重新提交或更换幂等键。
+
+权威文案位于 `external_mcp.rs` 的 `MCP_INSTRUCTIONS`，初始化响应与 `genarrative://external-editor/usage` 共用同一内容。该步骤只更新说明，不改变工具和 API；其它 resources 的内容更新见下一节。
+
+### 5.6 resources 内容更新（2026-09-24）
+
+沿用现有 7 个资源 URI。usage 共用 instructions，OpenAPI 继续提供现有 REST 契约；Skill 主入口和四份 references 按当前工具能力更新，不改变工具、路由、鉴权或 DTO。
+
+- 主入口：服务能力、必要共同约定和按需阅读导航；不要求固定项目、同名文件夹或双重落库。
+- capability-routing：按意图选择工具与 action，说明上传、登记、生成、落画布之间的边界。
+- api-operations：工具到现有 REST 操作的映射，保留直接 REST 调用所需信息。
+- authentication-and-safety：MCP 与 REST 凭证配置、上传分工、幂等键位置、重试与删除范围。
+- requests-and-outputs：单功能及多功能 MCP 参数示例、异步轮询、按需指定生成目标、完整布局保存和结果/告警读取。
+
+文档源位于 `.codex/skills/genarrative-external-editor-api/`，由 MCP resources 与下载的 Skill 包共用；本次不修改 Python helper、独立 CLI 或附件中的配套 Skill。说明仍随 API server 编译发布，不新增独立文档托管机制。验收覆盖资源读取、Skill 归档内容及 manifest 摘要一致性，并检查示例与当前 schema。
+
+## 6. 核对入口
+
+- [External v1 OpenAPI](../openapi/genarrative-external-v1.openapi.json)：operation、参数、请求体、响应与公开字段权威。
+- [External API 路由](../../server-rs/crates/api-server/src/modules/external_api.rs)：实际路由挂载。
+- [MCP 实现](../../server-rs/crates/api-server/src/external_mcp.rs)：工具生成、schema、资源和进程内分派。
+- [语义工具适配](../../server-rs/crates/api-server/src/external_mcp/semantic.rs)：新增工具、action、同源 schema 与参数映射。
+- [工具说明](../../server-rs/crates/api-server/prompts/external_mcp/semantic_tools.json)：新增工具的中文用途、操作和结果说明。
+- [External 编辑器接口](../../server-rs/crates/api-server/src/external_editor_api.rs)：鉴权、请求处理与生成受理。
+- [AGC 抠图模式与背景色透传](./【技术方案】AGC抠图模式与背景色透传-2026-09-16.md)：去背景模式与背景色已有合同。
+
+参数合同按 2026-09-23 的实现核对，说明与验收状态于 2026-09-24 收口；后续变更仍以代码与 OpenAPI 为准，并同步修订本文，不维护第二份脱离 API 的字段真相。

docs/【后端架构】server-rs与SpacetimeDB数据契约-2026-05-15.md

@@ -507,7 +507,8 @@ Responses 的终态载荷既是工具调用的恢复源，也是正文的恢复
 ### `agc_model_catalog`
 
 - 私有单例表，主键 `id=0`，保存 `catalog_json`、`revision`、`updated_at`；不存凭据。
-- `read_agc_model_catalog` / `save_agc_model_catalog` 只接受已登记的 runtime service identity，保存使用 revision 乐观锁。
+- `read_agc_model_catalog` / `save_agc_model_catalog` 只接受已登记的 runtime service identity，保存使用 revision 乐观锁；缺行时读取返回 `AGC_MODEL_CATALOG_NOT_INITIALIZED`，不返回任何内置目录。
+- 目录初始值来自上游同步：api-server（API/All 角色）启动时若目录缺失、结构与当前定义不符或校验不通过，就用分组定价列表 `GET {Router 控制面}/api/pricing?group=taonier`（公开只读、不带凭据）的 `data[].model_name` 生成目录（`id` 为模型名 slug，`alias`/`modelId` 为上游原名），失败只记录 error、不写替代目录，由下一次启动重试；未初始化期间 AGC 目录与对话接口、后台目录接口都失败关闭（`503`）。
 - 后台 owner 通过 `GET/PUT /admin/api/agc-models` 管理稳定标识、必填别名、实际模型名、启用状态和默认项；客户端 `GET /api/llm/models` 仅返回启用项的稳定标识、别名和目录 `revision`（供条件刷新，不暴露实际模型名）。
 - Responses / Chat 请求按目录解析模型；未知或停用项拒绝。AGC 的 `platform-default` 请求标识使用目录默认项。详细契约见 `technical/【技术方案】AGC后台模型别名与对话选择-2026-09-05.md`。
 

docs/【后端架构】外部OpenAPI与APIKey接入方案-2026-06-19.md

@@ -78,6 +78,8 @@ provider 原图已保存但透明背景处理最终失败时，worker 保留原
 
 ## 托管远程 MCP
 
+新增语义工具的合同见 [外部 MCP 语义工具说明与参数设计](./technical/【技术方案】外部MCP语义工具说明与参数设计-2026-09-23.md)。15 个语义工具与原有 OpenAPI 自动映射工具同时可见；旧工具名称、schema、注解和行为保持不变，不删除、隐藏或加前缀。新工具按 action 选择一个既有 operation，平铺业务字段后复用下述 REST 分派；创建项目、项目资源、素材文件夹的新入口额外保留对应 API 的可选幂等键。所有结果沿用相同解包与错误处理，不裁剪告警或项目快照。resources 与 instructions 的内容更新另行处理，REST 契约不变。
+
 `/api/external/v1/mcp` 是 Genarrative 托管的远程端点，Agent 只需配置 URL 和现有 API Key，不安装本地 MCP server。首版兼容 MCP `2025-11-25` initialize 生命周期，使用 JSON-RPC 2.0 和 Streamable HTTP，支持 `initialize`、`notifications/initialized`、`ping`、`tools/list`、`tools/call`、`resources/list`、`resources/read`。服务端使用无协议 session 的 JSON direct 模式，不依赖 sticky session，也不把 `Mcp-Session-Id` 作为业务身份。
 
 MCP transport 的 DNS rebinding 防护必须同时允许正式入口 `www.genarrative.world` / `genarrative.world`、开发入口 `dev.genarrative.world` 和本机开发入口；对应 HTTPS Origin 也必须与公开环境同步登记。新增公开环境域名时，必须在发布前使用该域名的真实 `Host` 和 `Origin` 执行 `initialize` 回归，不能只用 `localhost` 单测证明端点可用。

docs/【开发运维】本地开发验证与生产运维-2026-05-15.md

@@ -589,6 +589,14 @@ curl -fsS --max-time 5 http://127.0.0.1/api/editor/showcase/resources >/dev/null
 
 本地联调使用 `dev`，且 `GENARRATIVE_ENV` 为 `development`（默认）、`test` 或 `container` 时，允许规范 HTTP(S) loopback 地址及可变端口，无需配置独立埋点变量。客户端登录时使用实际 API 入口，容器使用宿主机映射入口。线上部署设置 `GENARRATIVE_ENV=production`，不接受 loopback 例外；详细合同见[客户端本地埋点与主站入库契约](./technical/【技术方案】客户端本地埋点与主站入库契约-2026-09-21.md)第 13 节。
 
+### AGC 模型目录上游同步
+
+`api-server`（API/All 角色）启动时检查 `agc_model_catalog`：缺失、结构与当前定义不符或校验不通过都算未初始化，此时请求上游 Router 控制面的分组定价列表 `GET {GENARRATIVE_LLM_ROUTER_BASE_URL 去掉 /v1}/api/pricing?group=taonier`（公开只读接口，不带凭据），按返回的 `data[].model_name` 排序生成目录并写回（revision 自增）：`modelId` 与 `alias` 都是上游原始模型名，`id` 是模型名的 slug，默认项为排序后第一项。目录结构、后台字段与客户端契约都保持不变。
+
+上游不可达、返回非 2xx、列表为空或响应超过 1 MiB 时，启动日志打印 `AGC 模型目录未初始化：本次启动未从上游同步到模型列表…`，`GET /api/llm/models`、`/api/llm/responses` 与后台 `GET/PUT /admin/api/agc-models` 返回 `503`，不返回任何内置模型；修好上游可达性后重启 `api-server` 即会重试成功。目录只在未初始化时重建，上游新增或移除模型由后台「AGC 模型」页维护，不会自动跟随。存量目录（含旧版写死的 `高质量 → gpt-6-astra`、`快速 → gpt-5.6-luna`）结构合法时不会被自动重建，需要 owner 在后台改掉，或清空 `agc_model_catalog` 该行后重启让其重新同步。
+
+发布与回滚注意：本变更改的是 module 的缺行语义（由“返回内置目录”改为报错）与 api-server 的启动期同步，**module 与 api-server 必须同批发布、同批回滚**；混合版本期间未升级的 api-server 会把自己的 AGC 目录与对话接口打到 `503`（不会崩，但 AGC 不可用）。后台 DTO 与 admin-web 未改动，可独立发布。
+
 ### AGC 项目快照上传目标
 
 后台“项目工程”（`/admin/#project-snapshots`）按项目列出远端快照，默认只看本部署渠道，顶部“渠道”选择框可切换远端已存在的其它渠道；列表按游标分页（每页 20/50/100，上一页复用已取得的游标，远端不给总数所以只显示当前页）。完整快照提供“下载完整工程”，按原始目录返回 ZIP；未完成同步的项目暂不可下载，旧清单缺少完整性声明时显示“完整性未知”，只能“下载已存文件”。“用户”列与“素材查询”同口径展示昵称与陶泥号，并可点开用户详情；不要直接把 OSS 的 `files/{size}-{digest}/` 目录下载当成工程。