Merge branch 'master' into feat/external-scene-generation
Project CI / AI game creator shell Rust crates (pull_request) Successful in 1m31s
Project CI / AI game creator shell Rust smoke (pull_request) Successful in 1m56s
Project CI / Backend tests (pull_request) Successful in 3m53s
Project CI / Frontend tests (pull_request) Successful in 2m9s
Project CI / Native shell tests (pull_request) Successful in 5m58s
Project CI / AI game creator shell Rust lane 2/2 (pull_request) Successful in 9m6s
Project CI / Repository checks (pull_request) Successful in 1m54s
Project CI / AI game creator shell Rust lane 1/2 (pull_request) Successful in 9m58s
Project CI / AI game creator shell web tests (pull_request) Successful in 1m32s
Project CI / AI game creator shell Rust crates (pull_request) Successful in 1m31s
Project CI / AI game creator shell Rust smoke (pull_request) Successful in 1m56s
Project CI / Backend tests (pull_request) Successful in 3m53s
Project CI / Frontend tests (pull_request) Successful in 2m9s
Project CI / Native shell tests (pull_request) Successful in 5m58s
Project CI / AI game creator shell Rust lane 2/2 (pull_request) Successful in 9m6s
Project CI / Repository checks (pull_request) Successful in 1m54s
Project CI / AI game creator shell Rust lane 1/2 (pull_request) Successful in 9m58s
Project CI / AI game creator shell web tests (pull_request) Successful in 1m32s
This commit is contained in:
+5
-1
@@ -44,8 +44,11 @@
|
||||
- [DirectProject Codex 原始历史与异常恢复](<./technical/【技术方案】DirectProject Codex原始历史与异常恢复-2026-09-04.md>):原始 Responses item 持久化、线程注入与异常回合收尾。
|
||||
- [DirectProject 对话历史单一事实源](./adr/【ADR】DirectProject对话历史单一事实源-2026-09-16.md):AGC 项目开发对话只以项目对话历史与运行态事件为真相源,聊天投影不落盘。
|
||||
- [DirectProject 独立聊天容器与工作台钱包布局](./adr/【ADR】DirectProject独立聊天容器与工作台钱包布局-2026-09-18.md):DirectProject 与 Supervisor 等路径分容器,钱包入口由项目工作台布局独立承载。
|
||||
- [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 编辑器适配边界。
|
||||
@@ -66,7 +69,8 @@
|
||||
- [AGC 资源派生与非破坏性编辑合同](./technical/【技术方案】AGC资源派生与非破坏性编辑合同-2026-09-09.md):AGC 全类型现有资源非破坏性编辑的权威合同,约束资源派生、替换与写回边界。
|
||||
- [AGC 聊天素材引用](./【功能说明】AGC聊天素材引用-2026-09-08.md):聊天输入框 @ 引用项目素材的入口、引用模型与「当前版本素材」口径。
|
||||
- [AGC 聊天 AI 润色与发送前提醒](./【功能说明】AGC聊天AI润色与发送前提醒-2026-09-10.md):提示词润色与发送前提醒的交互、失败与取消口径。
|
||||
- [UI 工作流资源桥接与 Runtime 执行](./【技术方案】UI工作流资源桥接与Runtime执行-2026-08-24.md)
|
||||
- [UI 编辑器代码地图与模块职责](./technical/【技术方案】UI编辑器代码地图与模块职责-2026-09-23.md):Rust `ui_editor` 模块、`features/ui-editor` 语义层与 `view/ui-editor` 视图层的职责划分与扩展指引。
|
||||
- [UI 编辑器 Agent 工具化重写](./technical/【技术方案】UI编辑器Agent工具化重写-2026-09-23.md):三个工具(建文档 / 跑工作流 / 出 JS)的契约、两步工作流、JSONL 检查点与模块布局。
|
||||
- [UI 编辑器 Godot 容器布局](./technical/【技术方案】UI编辑器Godot容器布局模型-2026-08-18.md)
|
||||
- [UI 编辑器变换角点偏移编辑器](./technical/【设计】UI编辑器变换角点偏移编辑器-2026-09-03.md)
|
||||
- [UI 编辑器子节点显示规则](./technical/【技术方案】UI编辑器子节点显示规则-2026-08-18.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` 里的用户条目也依旧只在首屏 / 翻页时读进前端。
|
||||
@@ -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`。
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
# UI 工作流检查点用追加式 JSONL 日志
|
||||
|
||||
UI 设计文档的工作流由 Agent 工具驱动、跨多次外部调用,崩溃后需要能续跑。检查点定为**文档旁一条按行追加的 JSONL 日志**:每一步做完就追加一行——起始一轮记原始 State 快照,识别与切分各记自己的 DTO **以及该步应用完之后的那份 State 快照**,最后一行是回写标记——"某步是否完成"只看日志里有没有对应的行,没有就是没完成。恢复只做两件事:读回已完成步骤留下的 State 快照,然后从第一个没有快照的步骤继续。
|
||||
|
||||
## 考虑过的方案
|
||||
|
||||
- 每步一个 sidecar 状态机(步骤状态 + sealedAtRevision + evidence 清单):要额外维护状态迁移、封条判据和证据校验,等于给每一步发明一套小协议。
|
||||
- 把切分专用的 `SeparationState` 泛化成通用检查点:切分需要"每个批次、每个节点"的细粒度恢复语义,其它步骤不需要,泛化会把这份复杂度摊给所有步骤。
|
||||
|
||||
追加式日志只需要"存在即完成"这一条判据,新增步骤类型等于新增一种行,天然可扩展。每步应用完的 State 快照随该步行一同落下,恢复就只是"读回最新快照",不必再维护一份"照 DTO 重算一遍"的镜像逻辑。
|
||||
|
||||
## 后果
|
||||
|
||||
- 日志是恢复用的派生信息,不是项目内容:不登记为 manifest 资产,不推进项目 revision。
|
||||
- 每行必须一次性原子追加;崩溃时可能留下写了一半的最后一行,未形成完整行的步骤一律视为未完成。
|
||||
- 同一份文档可以被多次运行,日志必须能区分轮次:每一轮以一行原始 State 快照开头,该轮的第一行回写标记即为这一轮结束;恢复只针对最后一个没有回写标记的轮次。
|
||||
- 恢复只看快照、不重放步骤:已完成步骤在日志里带着"那一步应用完"的 State,恢复直接采纳并整步跳过。若照 DTO 再跑一遍,会重复登记切图、把同一条回填出错原因重复累加。只有带 State 快照的行才算已完成,旧格式(只有 DTO)按未完成重跑。
|
||||
- 切分 op 内部的细粒度恢复仍由 `SeparationState` 承担,日志只记录工作流层面的步骤完成,不顺带复制它的进度。
|
||||
@@ -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 在后台维护子集。
|
||||
@@ -0,0 +1,35 @@
|
||||
# 【实施计划】UI编辑器多树预览与独立显示开关
|
||||
|
||||
| 字段 | 值 |
|
||||
| --- | --- |
|
||||
| Milestone | `docs/project-memory/plans/【里程碑】UI编辑器多树预览与独立显示开关-2026-09-14.md` |
|
||||
| Status | ready |
|
||||
| Owner | Codex |
|
||||
|
||||
## 修改边界
|
||||
|
||||
- 允许修改:AGC UI editor Rust Node/UITree DTO、前端 UI editor state/session、preview 组件、相关测试与当前专题文档。
|
||||
- 明确不修改:SpacetimeDB、External v1、代码生成 runtime 语义、用户 `.env`。
|
||||
|
||||
## 实现顺序
|
||||
|
||||
1. 更新 Rust Node 与生成的 TS 类型;补齐所有 Node 构造器。
|
||||
2. 在状态层集中实现 createTree 与 root offset 更新。
|
||||
3. 将 session canvas projection 改为全树投影并提供按 treeId 的节点/根操作。
|
||||
4. 重构 preview 为联合画布、多树 wrapper、独立三个显示开关和树级拖动。
|
||||
5. 修正左侧选择与 Inspector 的 tree 反查,不让预览选择修改 activeImageId。
|
||||
6. 增加/更新定向测试与文档。
|
||||
|
||||
## 验证命令
|
||||
|
||||
1. `npm --prefix apps/ai-game-creator-shell test -- --run`
|
||||
2. `npm --prefix apps/ai-game-creator-shell run typecheck`
|
||||
3. `cargo test --manifest-path apps/ai-game-creator-shell/src-tauri/Cargo.toml`
|
||||
4. `npm run check:encoding`
|
||||
5. `git diff --check`
|
||||
|
||||
## 风险与回滚点
|
||||
|
||||
- Node DTO 是生成绑定,Rust 与 TS 不一致会阻断编译;每次结构变更后立即生成并检查 diff。
|
||||
- 预览选择与 activeImageId 解耦可能暴露 Inspector 当前依赖;通过 treeId 反查补齐。
|
||||
- root 拖动需与画布平移和子节点拖动区分;若命中冲突,优先保留现有子节点手势。
|
||||
@@ -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/页面保持不变,本变更不引入不兼容改动。
|
||||
- 待决:是否需要“上游自动跟随同步”(当前不做)。
|
||||
@@ -0,0 +1,47 @@
|
||||
# 【里程碑】UI编辑器多树预览与独立显示开关
|
||||
|
||||
| 字段 | 值 |
|
||||
| --- | --- |
|
||||
| Version | 1.0 |
|
||||
| Status | approved |
|
||||
| Date | 2026-09-14 |
|
||||
| Parent Spec | `docs/technical/【前端架构】UI编辑会话模块边界-2026-08-19.md` |
|
||||
|
||||
## 目标
|
||||
|
||||
UI 编辑器预览同时展示全部界面树。每棵树使用 root.offset 的 min 作为树级画布位置,支持整树拖动持久化;显示原图、组件和普通框线拆成三个独立开关。
|
||||
|
||||
## 范围
|
||||
|
||||
- `Node` 增加包含 min/max 的 offset 数据,读取只使用 min,max 由 min 与源图 logical size 派生。
|
||||
- 所有新树统一由 createTree 入口创建,并按现有树最右边界加 padding 横向排列。
|
||||
- 首次进入预览和手动适配使用全部树联合边界。
|
||||
- 左侧图片选择继续维护 activeImageId;预览选择不改变它,不因选择或拖动自动 fit。
|
||||
- root 可拖动但不可 resize;子节点维持现有选择、拖动和 resize 行为。
|
||||
|
||||
## 不在范围内
|
||||
|
||||
- 旧数据 migration、offset fallback、自动 revision 修复。
|
||||
- 删除/排序后的自动重排。
|
||||
- 代码生成 runtime 的树级布局语义。
|
||||
- root/max 的独立编辑控件。
|
||||
|
||||
## 依赖与前置条件
|
||||
|
||||
- 当前资源均符合最新 Node/UITree schema。
|
||||
- 对应界面图提供合法 pixel_size 与 pixels_per_unit。
|
||||
|
||||
## 验收标准
|
||||
|
||||
- [ ] 新树默认位于所有现有树右侧并与最小 top 对齐。
|
||||
- [ ] 原图与组件随 root 一起移动,拖动结束进入 undo/redo 并可保存恢复。
|
||||
- [ ] root 不显示 resize handles,子节点 resize 不回归。
|
||||
- [ ] 三个开关默认 showFrame=true、showOriginImage=true、showComponent=false,且互相独立。
|
||||
- [ ] 预览选择不修改 activeImageId;左侧图片选择和 Inspector 既有切换保持。
|
||||
- [ ] 仅首次进入和手动适配触发联合 fit。
|
||||
|
||||
## 证据要求
|
||||
|
||||
- 自动化:UI editor preview、state、transform 相关 Vitest;Tauri Rust 单元测试;类型检查。
|
||||
- 运行时:必要时执行 AGC UI 编辑器页面 smoke。
|
||||
- 边界:非法缺失 offset 不兜底;树重叠命中顺序;root 禁止 resize。
|
||||
@@ -1,10 +1,126 @@
|
||||
# 决策记录
|
||||
|
||||
## 2026-09-22 UI 编辑器预览画布补上右键拖拽平移,节点菜单改为右键抬起弹出
|
||||
|
||||
- 背景:预览画布此前只有中键与空格+左键平移,右键整段留给节点操作菜单(`UiTreeRenderer.onContextMenu` 直接弹 `UiNodeContextMenu`)。这次要补右键拖拽平移,并要求"拖拽过就不许再触发右键菜单"。实测(Linux Chromium 151 / Firefox 151,真实 X11 输入)确认 `contextmenu` 在**按下**瞬间触发,且原生菜单一旦弹出,页面之后收不到任何 `pointermove` / `pointerup` / `mouseup` / `auxclick`,所以"先让菜单弹、拖拽时再关"在浏览器层面不可行;headless 没有原生菜单,Playwright 复现不出该行为。macOS 的 `contextmenu` 在 mouseup 触发(本容器无法实测),但同一条实现路径对两种时序都成立。同一次实测:键盘菜单键触发的是 `button: -1`,所以"只认按钮 2"的拦截天然把键盘菜单留给原有节点菜单路径。
|
||||
- 决策:预览视口在捕获阶段拦截按钮 2 的 `contextmenu`(`preventDefault` + `stopPropagation`),右键手势改由预览自己裁决:按下时记录起点、`setPointerCapture` 并交焦点;移动越过与左键拖拽共用的 `DRAG_THRESHOLD_SCREEN_PX`(2px)后本次手势定死为平移,按"按下点全量 delta"更新视口(光标复用共享 `CanvasViewport` 的 `isPanning` → `cursor: grabbing`,三个平移绑定一起生效);未越阈值且在预览内抬起时,用 `[data-node-id]` 加树容器 `data-tree-id` 命中节点并打开 `UiNodeContextMenu`,保留"右键即选中该节点"的既有语义;空白处干净右键不做事(原生菜单已被抑制)。中键、空格+左键平移不变,macOS ctrl+左键与键盘菜单键继续走原有即时菜单路径;平移是纯视图操作,不写 State、不进历史、不受 `isLocked` 与空格按住态限制。
|
||||
- 原因:右键同时承载菜单与视图平移,只能等到手势结束再裁决;把判定放进预览,是因为树、节点命中、预览边界与拖动阈值都在预览手里,而 `useNodeTransformInteraction` 应保持左键变换的单一职责;`[data-node-id]` 命中也已是 `resolveHitNodeId` 的既有模式。
|
||||
- 代价与取舍:右键从"按下即弹菜单"变成"抬起才弹"(与 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 之前那段没有交代;窗口期这一轮确实已经交给宿主(本地命令在飞),文案不虚报「宿主已在跑」之外的东西。
|
||||
- 决策(那条预言的处置):2026-09-22 那条写「若将来改成窗口期也显示卡片,`running` 在渲染层就没有消费者了,应把投影压成 `unfinished: boolean`」。本次改完后投影三态**仍有**消费者——`DirectProjectTurn` 用 `state !== 'finished'` 做否定式判断、`state === 'running'` 挑流式正文,状态条也用 `state !== 'finished'` 定起点——所以不动 `DirectChatTurnState`,也不压缩成布尔。
|
||||
- 决策(卡片口径翻转,**更正** 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}}`。
|
||||
@@ -9260,6 +9376,51 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
|
||||
- 影响面:`apps/ai-game-creator-shell/src/features/{project-workspace/resourceReferences.ts,project-workspace/ResourceReferenceInput.tsx,resource-canvas/ResourceCanvasAssetGenerationPanelView.tsx,resource-canvas/resourceCanvasAssetGenerationTaskModel.ts,resource-canvas/resourceCanvasAssetGenerationReferenceModel.ts}`、`apps/ai-game-creator-shell/src/view/project-development/index.tsx` 与对应 6 个定向测试文件。
|
||||
- 验证:定向 `resourceCanvasAssetGenerationReferences` / `resourceCanvasAssetGenerationBackgroundClose` / `resourceCanvasBottomToolbar` / `resourceCanvasGenerationFloatingPanel(Chrome)` / `resourceReferenceInput` / `resourceReferences` / `resourceCanvasAssetGenerationTasksPanel` 全绿;全量 `npm run test -- apps/ai-game-creator-shell/tests` 只剩 `clientHttp` / `clientApi` / `clientAuthStorage` / `projectCreationDirectory` / `recentProjectsHook` 五个 jsdom `localStorage` 环境用例红(与本次改动无调用关系);TS typecheck、`check:encoding`、`git diff --check` 通过。未复核真实客户端观感。
|
||||
|
||||
## 2026-09-18 UI 编辑器深模块 seam 收敛
|
||||
|
||||
- 决策:UI 编辑器的语义状态写入通过 React-free `stateTransition` seam;页面 hook 继续负责 React/history/lock adapter。保存前增加 `stateInvariants` projection,Rust 持久化规则仍是最终权威。
|
||||
- 决策:节点几何新增 State 级 `findStateNodePageContext`,页面选择、预览和状态迁移共享同一坐标递归入口;四类异步操作的 running/status 由 `operationLifecycle` adapter 承接。
|
||||
- 决策:结构化 LLM action 共用 `commands::utils::required_tool_arguments`,仅统一必需 tool-call 定位与有界 JSON 解析,不合并 prompt、schema 或 materializer。
|
||||
- 验证:AGC typecheck、UI State 定向 Vitest、编码检查、doc-index、diff 检查和 Tauri Rust fmt 通过;Tauri 全量 cargo check 仍受现有 platform-llm API 漂移错误阻断,与本次 UI editor 改动无关。
|
||||
|
||||
## 2026-09-23 UI 编辑器退役界面图参考语义建议
|
||||
|
||||
- 背景:UI 编辑器的“分析参考图”步骤只用一次 LLM 调用给界面图补 `name` / `description` / `role` / `slave_to`,四个字段又反过来决定结构识别的上下文分组、合并的树优先级和 Inspector 的可选项;这条链路的价值不足以支撑它引入的跨层耦合。
|
||||
- 决策:`commands/ui_design_suggestion.rs`、`suggest_ui_design_semantic` 命令与 `UIDesignImage.metadata`(含 `UIDesignImageRole`、`UIDesignImageMetadata`)整体退役,`UIDesignImage` 只剩 `path` / `pixel_size` / `pixels_per_unit`;前端从三步工作流收敛为“识别界面结构 / 自动切分素材”两步,`model.ts`、`WorkflowActionCard`、`WorkflowChecks`、完成通知、`InputSidebar`、`InspectorSidebar` 与 `ImportOverview` 同步删减。不保留兼容字段、回退路径、旧文档迁移或写回。
|
||||
- 决策:界面图之间不再有持久化关系,结构识别按“每张界面图各自一棵树、各自一个上下文”执行(删掉 `recognition_root_image_ids` / `slave_image_ids`);界面图显示名统一取 `path` 的 basename(复用 `view/project-development/resourceAssetDisplayName.ts`)。
|
||||
- 决策:多树合并暂时没有优先级来源(原优先级由 `slave_to` 祖先链计数得出),`merge` 现在把所有输入树优先级恒置 0 并留 `TODO`,合并冲突取 `merged_from` 首位成员;`ui-workflow.*` 阶段与页面级工作流不在本次范围,后续整体重写。
|
||||
- 代价与取舍:删掉 `name` / `description` 后界面图在 UI 上只能用文件名标识;合并冲突的代表节点选择不再有“优先级”依据;`role` / `slave_to` 曾承担的“主页面 + 子界面”语义彻底消失。旧 `ui_design.json` 里的 `metadata` 由 serde 默认忽略、下次保存后自然消失(`State` / `UIDesignImage` 都没有 `deny_unknown_fields`),已生成的 `ui_trees` 不受影响。
|
||||
- 影响面:`apps/ai-game-creator-shell/src-tauri/src/{main.rs,ui_editor/**}`、`src/features/ui-editor/**`、`src/view/ui-editor/**`、`src/view/project-development/index.tsx`、`tests/{uiEditorPage,uiEditorState,previewWorkspaceZoom}.test.*`、`docs/technical/【技术方案】UI编辑器代码地图与模块职责-2026-09-23.md`、`docs/【技术方案】UI工作流资源桥接与Runtime执行-2026-08-24.md`、`docs/technical/【设计】UI编辑器工作流完成通知弹窗-2026-09-04.md`、`docs/technical/【前端架构】UI编辑会话模块边界-2026-08-19.md`。
|
||||
- 验证:`cargo check` 与 `cargo test --bin genarrative-ai-game-creator-shell ui_editor`(160 passed)通过,ts-rs 重新导出 `types/UIDesignImage.ts` 并删除三个已退役类型;`npx vitest run` 定向 `uiEditorPage` / `uiEditorState` / `uiDesignStateStore` / `previewWorkspaceZoom` / `appSurface` 全绿;AGC `tsc --noEmit`、改动文件 eslint、`cargo fmt --check`、`check:encoding`、`git diff --check` 通过。整套 Rust 测试在本容器仍有 60 条环境性失败(`/sbin -> usr/bin` 让 `command.exec` 沙箱 merged-usr 预检失败),与本次改动无关。
|
||||
|
||||
## 2026-09-24 UI 设计文档三个工具的持久回执明细与入参摘要改为可读白名单
|
||||
|
||||
- 背景:动作回执的"安全明细"是一份白名单——只有认识的工具才把明细整理成安全字段。`ui.workflow.run` 退役时删掉了它那段分支,接管的 `ui-design-doc.*` 三个工具没补,于是统一落到兜底:明细整块变成 `detailUnavailable`,模型与审计都看不到;入参那一栏也只剩哈希。原始明细既不落盘也不给模型,所以**没有宿主路径泄露**,丢的是可用性(例如切分没登记上的素材清单)。
|
||||
- 决策:按既有白名单口径给三个工具各补一条分支。`from-images` 放 `assetId` / `relativePath` / `imageIds` / `revisionAdvanceCount`;`run-workflow` 再放文档 `revision`、恢复标记、识别与绑定计数、`backfillErrors` 与总数;`into-js` 只放相对路径与计数(导出名清单只用来核对数量,不逐项外传)。
|
||||
- 决策(校验口径):身份字段走 `agent_runtime_action_receipt_identity_text`(禁控制字符、限长、含 file URI 或绝对路径即失败关闭);相对路径必须归一化后落在 `ui/` 下;回填说明是自由文本,按既有口径把绝对路径脱敏成占位符,含控制字符或超长则整条明细失败关闭。
|
||||
- 决策(体积):回执明细总长仍受 `AGENT_RUNTIME_ACTION_RECEIPT_SAFE_DETAIL_MAX_CHARS`(500)约束。设计图身份与回填说明按长度上限能放多少放多少,放不下的部分用 `backfillErrorCount` 表达总数;必需字段本身就超限时整条明细不可用。
|
||||
- 决策(入参摘要):`agent_runtime_tool_action_input_summary` 为三个工具产出可读摘要(设计图逐张身份或目标文档 id),并把工具名加进 `agent_runtime_public_action_input_summary` 的可读名单,不再退化成只报哈希。
|
||||
- 验证方式:`tests::runtime_actions::action_execution::ui_design_doc_receipts_*` 两条用例(三个工具都能留下可用明细且不超长;宿主路径被脱敏;`ui/` 之外与宿主路径身份失败关闭)与 `action_audit::ui_design_doc_public_input_summary_tests` 两条用例;`cargo test --bin genarrative-ai-game-creator-shell receipt` 55 条全绿。
|
||||
|
||||
## 2026-09-24 UI 设计文档三个工具纳入项目变更门禁(成功返回即算改过项目)
|
||||
|
||||
- 背景:`ui.workflow.run` 退役时,项目变更门禁的两处工具名单(`agent/runtime_actions/project_gates.rs` 的 `is_agent_runtime_project_mutation_observation` 与 `agent_runtime_observation_advances_project_revision`)只删未补,新接管的 `ui-design-doc.from-images` / `ui-design-doc.run-workflow` / `ui-design-doc.into-js` 都没登记。后果:改完项目可能被判定"没改过",于是不要求验证就判完成、自动模式的 liveness 判据看不到进展;`agent_runtime_pending_expected_project_revision` 少算推进量又会误报 `pending_project_revision_drift`("并行项目变更使旧动作过期")。
|
||||
- 口径(产品确认):三个工具都在**成功返回时**改项目——`from-images` 登记设计图与文档、`run-workflow` 登记切图并保存文档、`into-js` 重写 `ui/generated-*.js`;调用中途不产生需要门禁额外追踪的中间态。
|
||||
- 决策:门禁按"工具名 + 成功返回"判定三者都算项目变更;其中 `into-js` 只重写派生产物、**不推进 revision**,所以不进 revision 推进名单——进去会虚报推进量,正好把要修的误报再造出来。
|
||||
- 决策(真实推进量):`from-images` / `run-workflow` 的观察明细带上 `revisionAdvanceCount`(沿用 `canvas.asset_import` 的既有字段),失败路径也带——切图素材先登记、后面步骤才失败时按约定不回滚,仍要如实计数,避免门禁把真实推进当成"别处改动"。
|
||||
- 代价与取舍:失败路径要多读一次项目 revision;`into-js` 属于"改了东西但项目 revision 没动"的少数派,与写文件类工具口径一致。
|
||||
- 验证方式:新增 `project_gates::ui_design_doc_project_mutation_gate_tests` 六条用例(成功即算变更、`into-js` 不推进 revision、登记类兜底推进量为 1、明细里的真实推进量优先、失败但已推进才算、无关工具不受影响)。
|
||||
|
||||
## 2026-09-23 UI 编辑器 Agent 工具化重写
|
||||
|
||||
- 背景:UI 编辑器的 Agent 链路原本只有一个 `ui.workflow.run`,把发现页面、桥接设计图、结构识别、多树合并、组件绑定、finalize 全塞进一个工具,工具参数本身就是工作流状态;识别与切分的产物由前端 `useUiEditorPage.ts` 落 State 再保存,Agent 侧没有任何恢复点,任一步失败只能整轮重来。
|
||||
- 决策:拆成三个各自只做一件事的工具——`ui-design-doc.from-images`(一至四张设计图新建并登记文档,返回 `assetId` 与 `relativePath`)、`ui-design-doc.run-workflow`(`recognize → separate → write-back`)、`ui-design-doc.into-js`(渲染 `ui/generated-<stem>-<digest>.js`,不推进 revision)。只有 `run-workflow` 带崩溃恢复,粒度到子步骤。
|
||||
- 决策(检查点):恢复判据只有「这一步有没有对应、且带着 State 快照的检查点行」。检查点是文档旁追加式 JSONL `ui/.<文档名>-workflow.jsonl`(不进 manifest、不推进 revision),行类型 `run` / `recognize` / `separate` / `write-back` / `outdated`;`run` 行带这一轮开始时的 State 快照,`recognize` / `separate` 行带该步应用完之后的 State 快照。恢复只读快照:逐级取回已完成步骤留下的 State,只把新完成那一步的改动应用到文档,已完成步骤整步跳过、绝不照 DTO 重跑(重跑会重复登记切图、把同一条回填出错原因重复报一遍)。只有 DTO、没有 State 快照的旧行按未完成处理,由主流程重跑该步。一轮以 `run` 开头、以首个 `write-back` 或 `outdated` 结束,只有最后一轮没有结束行时才恢复。追加前截断崩溃留下的半行;文档中途漂移(当前 State 既不是 `run` 行快照、也不是切分后那份快照)时追加 `outdated` 并返回错误,由下一次调用显式开新一轮,不在同一次调用里自动重启;写回按「切分后那份 State 快照与文档当前 State 相等」判幂等并补 `write-back` 行。
|
||||
- 决策(边界):文档内设计图身份直接采用该图在 manifest 里的 `assetId`,输入给相对路径时先登记再用它的 `assetId`;每次调用都新建文档,不做「原型 → 已存在文档」的幂等查找。切图资源失败不回滚,重放靠 by-path 复用接上;切分 op 内部更细粒度的恢复仍由 `SeparationState` sidecar 承担,日志不复制它的进度。前端 `useUiEditorPage.ts` 的人工链路保留同语义,Rust 只是第二份实现,不把编排搬进 Rust。
|
||||
- 退役:`ui.workflow.run`、`ui_editor/commands/{merge.rs,binding.rs}`、`ui_editor/workflow.rs`、`ensure_ui_design_resource_for_prototype`、`ui/ui-workflow-<sha256前24>.json` 命名与 `ui-workflow.*` manifest 阶段全部删除,不保留迁移、兼容与 fallback。
|
||||
- 代价与取舍:不接受跨语言 fixture 比对(四个 seam 都是简单变换,靠同语义实现与各自单测覆盖);`run-workflow` 每次调用都推进一轮,调用方重复调用会重新识别而不是被幂等短路(除「保存成功但缺 `write-back` 行」这一种重放)。工具名 `ui-design-doc.*` 含连字符,Function Calling 的函数名归一同时处理 `.` 与 `-`。
|
||||
- 验证方式:`cargo test --bin genarrative-ai-game-creator-shell agent_tools` 覆盖检查点、识别/切分镜像与切图登记;`ui_design_doc` 与 `native_ui_design_doc_tools` 用例覆盖工具入参和函数名;`npm run check:encoding`、`npm run check:doc-index`、`git diff --check` 通过。整套 Rust 用例在本容器仍有 9 条既有环境性失败(本地 HTTP 资源编辑器与 LLM 超时,改动前同样失败)。
|
||||
|
||||
## 2026-09-22 运行页收口:过程提示退出对话区,顶栏统一承载运行入口
|
||||
|
||||
- 背景:点播放(以及历史上 `/preview`、`/open-preview`、生成后自动启动预览)都会往对话区写一条 assistant 提示(`运行通过,已载入客户端运行视图:http://127.0.0.1:63155/` 这类)。它常驻对话底部遮挡运行画面,也让对话区混进非对话内容;运行页本身还有三处遮挡与两套皮:预览地址是一行常驻小字(不可点)、版本入口是绝对定位压在画面右上角的浮层、右上角还叠着「生成任务」开关。
|
||||
@@ -9289,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「消耗泥点」改为对冲退还后的净消耗
|
||||
|
||||
@@ -9345,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 必须同批发布/回滚。
|
||||
|
||||
@@ -1,5 +1,15 @@
|
||||
# 踩坑与排障记录
|
||||
|
||||
## 同一祖先下的多个项目会各自弹一次 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 必须先归一化再解析
|
||||
@@ -308,6 +318,12 @@ Direct 工具桥会 canonicalize 项目根,事件中的路径可能带 `\\?\`
|
||||
- 成功 JSON 与错误响应体均复用 `readClientHttpResponseText` 的 15 秒上限;超时后保留最后一次有效目录并释放在途请求,手动重试重新发起请求。迟到的响应不得覆盖重试获得的新目录。
|
||||
- 排查时区分接口未挂载(404)、未授权(401)、网络或响应体超时以及刷新无变化但缺少反馈;不能仅凭客户端启动 IPC 回退警告判断刷新失败原因。
|
||||
|
||||
## 2026-09-14 未知 JS 异常必须继续进入 error report
|
||||
|
||||
- **原则**:任何 JS 边界只要无法确认异常属于已知、已解决且有契约的业务失败,就必须保留原始异常并继续抛出,由全局 error report 链路采集;范围不限于 UI 编辑器、生成路径、剪贴板,也包括文件系统、权限、网络、插件和其它宿主调用。用户界面的 fallback(例如显示“复制失败,请手动复制”)只是附加的可继续操作提示,不代表异常已经被处理。
|
||||
- **易错点**:不要在 `catch` 中只设置 UI 文案然后结束,也不要把未知异常替换成新的泛化错误。需要用户 fallback 时,先更新提示,再重新抛出原始对象;只有已知且契约化的业务失败才可以在边界处转换为稳定的用户文案。
|
||||
- **关联**:`apps/ai-game-creator-shell/src/view/ui-editor/components/UiEditorCopyPathButton.tsx`、`docs/technical/【前端架构】UI编辑会话模块边界-2026-08-19.md`。
|
||||
|
||||
## 2026-09-14 AGC 壳 Rust 套件按「一片一 job」拆分,且分片必须自校验覆盖
|
||||
|
||||
- **现象**:`AI game creator shell Rust tests` 一直是客户端 CI 的关键路径。run 2097 实测 15 分 27 秒,其中 `apps/ai-game-creator-shell/src-tauri` 的 bin target 单测(2466 条)一条 `cargo test -- --test-threads=1` 串行占 507 秒。
|
||||
@@ -5968,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`。
|
||||
|
||||
@@ -67,7 +67,7 @@ SpacetimeDB crate、SDK、CLI / standalone 与生成 bindings 按 `2.8.3` 对齐
|
||||
- 2026-09-09 起,AGC 已新增遵循 OpenAI Agent Plugins 组合模型的通用 Plugin Host/SDK:Plugin、Skill 和 MCP 进入统一扩展 catalog;插件生命周期、行分隔 JSON-RPC、UI 面板、Capability Registry、权限和审计由 `plugin_host` 统一承接,Skill/MCP 仍分别交给各自现有 loader/transport;目标编辑器只通过通用 `EditorAdapter` 扩展点接入。详见 `docs/technical/【技术方案】AGC通用插件宿主与编辑器适配-2026-09-09.md`。
|
||||
- Unity 编辑器能力以 `plugins/agc-unity-editor` 内置插件提供,固定复用 Apache-2.0 的 DotCraft Attach 核心;Windows x64 / Unity Mono 接入不安装项目包。GUI、Runtime 与 DirectProject 通过现有 Runner 统一执行归属,跨进程回执与持久不确定阻断统一处理。首次打开 Unity 工程只初始化 AGC `.agent` 元数据,保留原引擎工程;详见 `docs/technical/【技术方案】AGC Unity编辑器插件接入-2026-09-18.md`。
|
||||
- DirectProject 的 Codex 原生文件、搜索、命令、图片查看和 Skill 仅在用户项目 cwd 与 `workspaceWrite(writableRoots=[project])` 内可用;原生命令允许联网以支持 npm 安装,npm 缓存位于项目内 `.npm-cache/`。多 Agent、Apps、插件、hooks、图片生成、Goals、Workspace Dependencies、Tool Suggestion 和原生浏览器/电脑控制保持关闭。app-server 使用隔离 `CODEX_HOME`,provider 凭据只由 AGC 客户端代理持有,不能进入模型上下文或 shell 环境。
|
||||
- `ui-prototype`(设计图片)与 UI 编辑器 `UI` JSON 是不同资源。白名单 `ui.workflow.run` 按页面执行 `prepare → recognize → status → finalize`,由 provider-backed 识别、合并和组件绑定持久化 State/revision,并把 `reference-ready → structure-ready → merge-ready → binding-ready → application-ready → completed` 投影到 manifest。Provider 缺失、请求失败、工具缺失、结果不匹配或仍有待审节点时保留真实阶段并返回 blocker,不得用 deterministic seed 伪造完成。
|
||||
- `ui-prototype`(设计图片)与 UI 编辑器 `ui-design-doc` JSON 是不同资源。Agent 只通过三个工具驱动:`ui-design-doc.from-images` 由一至四张已登记设计图新建并登记文档(文档内设计图身份即图片 assetId),`ui-design-doc.run-workflow` 在 Rust 内跑 `recognize → separate → write-back` 并写回 State/revision,`ui-design-doc.into-js` 产出 `ui/generated-*.js`(不推进 revision);三个工具都算项目变更观察(成功返回即算改过项目),其中只有前两个推进项目 revision;工具名与入参文案在 `prompts/runtime/texts/ui-design-doc.json`。Provider 缺失、请求失败、工具缺失或结果不匹配时保留真实 State 并返回错误,不得用 deterministic seed 伪造完成;旧 `ui.workflow.run`、多树合并、组件绑定与原型幂等桥接已退役,不保留兼容入口。
|
||||
- UI workflow 的资源桥接与 Runtime 边界以 `docs/【技术方案】UI工作流资源桥接与Runtime执行-2026-08-24.md` 和 AGC 实施计划的 2026-08-24 覆盖段为准;只生成图片、登记空 JSON 或进入普通图片画布都不构成 workflow 完成。
|
||||
|
||||
## 当前产品边界
|
||||
|
||||
@@ -4,6 +4,8 @@
|
||||
|
||||
`apps/ai-game-creator-shell` 的 UI 编辑器以 `useUiEditorSession` 作为视图与 adapter 的唯一协调边界。会话持有资源加载、revision、预览请求、选择、节点可见性、步骤 gate、异步操作和保存意图;`UiDesignStateStore` 与 Tauri 调用仍由该模块注入,不进入视图组件。
|
||||
|
||||
实现层的深模块 seam 固定为:`features/ui-editor/stateTransition.ts`(React-free 语义 State transition)、`stateInvariants.ts`(保存前不变量 projection)、`nodeTransformGeometry.ts`(State 级节点几何)以及 `view/ui-editor/operationLifecycle.ts`(异步操作 adapter)。`useUiEditorState` 和 `useUiEditorSession` 只负责 React/history/lock 与平台 adapter 编排,不在视图中复制树遍历或几何反演。
|
||||
|
||||
页面与子视图不得再传递完整 controller。它们按职责读取以下小 projection:
|
||||
|
||||
- `input`:资源输入、节点树及调试操作。
|
||||
@@ -19,6 +21,18 @@
|
||||
|
||||
保存与代码生成共享同一份持久化 State/revision。会话层在保存或生成进行期间互斥拦截,且代码生成必须基于已加载的持久化 revision;视图层的保存按钮和“保存并返回”按钮同步遵守该互斥状态。
|
||||
|
||||
Rust UI workflow 的结构化 LLM 动作共享 `commands::utils::required_tool_arguments` seam:它只负责必需 tool-call 定位与有界 JSON 解析;prompt、schema、领域校验和 materializer 继续留在 recognition/binding/merge 各自 command。
|
||||
|
||||
UI 编辑器的普通“保存”和“保存并生成代码”结果使用独立结果弹窗呈现,不在编辑器内容区追加状态条。普通保存成功仅提示保存成功;保存并生成成功展示生成器返回的项目相对路径(例如 `ui/generated-xxx.js`),复制按钮通过 Tauri clipboard manager 的 `writeText` 写入剪贴板。复制失败时保留可选中文本并提示手动复制;设置用户 fallback 后仍必须重新抛出原始错误,让 error report 链路收到未知 / 未处理的异常,不能把异常静默吞掉。此异常传播原则适用于所有 JS 边界,不限于生成路径或剪贴板。两类操作失败均在弹窗中展示;组合操作若保存成功但生成失败,明确提示项目已保存,重试动作仍复用原操作。保存并返回成功后直接返回,不打开结果弹窗;结果弹窗关闭后不保留路径状态。
|
||||
|
||||
## 2026-09-14 多树预览与树级偏移
|
||||
|
||||
UI 编辑器预览同时渲染 State 中全部 `ui_trees`。每棵树的 `root.offset` 包含 `min` / `max`;当前仅读取 `min` 作为树 wrapper 的左上角,`max` 由 `min + 对应界面图 pixel_size / pixels_per_unit` 派生。所有新树必须经 `createTree` 创建:首棵树位置为 `[0, 0]`,后续树按现有树实际右边界最大值加固定 padding 横向排列,并与现有树最小 top 对齐。删除或排序不重排已有树。
|
||||
|
||||
预览中原图与树 root 共享同一空间,root 空白区域可拖动整树,拖动结束一次性写回 root offset 并进入撤销/重做;root 不提供 resize,子节点沿用既有手势。预览选中节点不改变左侧图片面板的 `activeImageId`,Inspector 通过节点所属树反查编辑目标。只有首次进入预览和用户手动点击“适配画布”使用全部树联合边界进行 fit。
|
||||
|
||||
原有 render mode 已拆为三个会话级临时开关:`showFrame=true`、`showOriginImage=true`、`showComponent=false`。普通节点框线/名称受 `showFrame` 控制,选中节点强调始终保留;原图和组件显示互不耦合。
|
||||
|
||||
`UiDesignStateStore` 的 `generateCode(assetId)` 是必需能力,返回成功结果时不得为 nullable;所有注入的 adapter 与测试替身都必须实现该方法。
|
||||
|
||||
资源切换时,会话必须清理上一资源的保存/生成错误和生成中状态;普通保存开始时也清理代码生成错误。生成请求若因加载、锁定或 revision 等前置条件被拦截,必须向视图提供可见错误,而不是静默返回。
|
||||
|
||||
@@ -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` 里的用户条目依旧只在首屏 / 翻页时读进前端。
|
||||
@@ -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` 条件刷新与并发触发去重、发送前回退默认模型、刷新失败可恢复。
|
||||
|
||||
@@ -1,5 +1,19 @@
|
||||
# AI 游戏创作智能体 App 实施计划
|
||||
|
||||
## 2026-09-23 UI 编辑器退役界面图参考语义建议
|
||||
|
||||
本节覆盖下文“2026-08-18 UI Editor 从属页面、手势与保存失败边界”中的 `UIDesignImage.metadata.slave_to` 口径,以及“界面语义建议”相关描述。
|
||||
|
||||
UI 编辑器的“分析参考图”步骤、Rust 命令 `suggest_ui_design_semantic` 与 `UIDesignImage` 的 `metadata`(`name` / `description` / `role` / `slave_to`)整体退役,不保留兼容字段、回退路径或旧文档迁移:界面图只剩 `path`、`pixel_size`、`pixels_per_unit`;界面图之间不再存在持久化归属关系,结构识别按“每张界面图各自一棵树”执行;界面图在 UI 上的显示名统一取 `path` basename(`view/project-development/resourceAssetDisplayName.ts`),没有可选主页面过滤器、角色选择器和归属选择器。
|
||||
|
||||
多树合并当前不产生有效优先级:`merge` 的所有输入树优先级恒为 0(代码内留 `TODO`,等待重新设计),因此合并冲突时的代表节点取 `merged_from` 首位成员。旧的 `ui_design.json` 里残留的 `metadata` 字段由 serde 默认忽略,读取后不再写回;不新增拒绝或迁移逻辑。
|
||||
|
||||
| 要求 | 必须成立的行为 | 完成证据 |
|
||||
| --- | --- | --- |
|
||||
| 权威层收敛 | `resource/ui_design_image.rs` 只保留 `path` / `pixel_size` / `pixels_per_unit`;`commands/ui_design_suggestion.rs` 与 `suggest_ui_design_semantic` 注册删除;持久化校验不再有 `slave_to` 引用与环校验 | `cargo check`、`cargo test --bin genarrative-ai-game-creator-shell ui_editor`(160 passed) |
|
||||
| 前端两步工作流 | `model.ts` 只保留“识别界面结构”“自动切分素材”;`ToolNavigation` 渲染两格;suggestion 操作、结果通知分支、role/slave_to 编辑器与 `ImportOverview`(原“分析参考图”步骤概览)全部删除 | `npx vitest run uiEditorPage/uiEditorState/uiDesignStateStore/previewWorkspaceZoom/appSurface` |
|
||||
| 无迁移 | 旧文档中的 `metadata` 被静默忽略并在下次保存时消失,`ui_trees` 不受影响;不做迁移脚本或写入回填 | `persistence.rs` 既有加载/保存用例 |
|
||||
|
||||
## 当前策划入口与退役边界
|
||||
|
||||
策划 V1、策划会话 Runtime V2 均已删除,当前“做方案”只使用独立 Design Agent,现行合同见[策划 Agent 生产迁移与工作区浏览](./【技术方案】策划Agent生产迁移与工作区浏览-2026-09-10.md)。旧 V1/V2 Runtime、命令、会话、审批卡、身份白名单和专属测试不作为兼容或恢复目标;历史方案中的 lifecycle v3、planning binding 等要求不能作为孤立代码的保留依据。共享能力按现役调用判断,不因名称相似删除当前 Design Agent 或通用 Runtime。
|
||||
@@ -1739,3 +1753,10 @@ Direct 回合的所有权属于进程内项目身份锁,不属于当前页面
|
||||
`AgentRuntimeErrorEvent` 把失败投影到用户消息、运行面板和项目内 `.agent/runtime/errors/<eventId>.json` 时,同一份已脱敏诊断还要投影成 AppData `diagnostics/application.log` 的两行:`agent.runtime.error`(身份行:`eventId / source / stage / code / retryable / clientTurnId / elapsedMs / detailRef`)与 `agent.runtime.error.detail`(详情行:`hint / summary / detail / metadata`)。原因是项目内 sidecar 只在项目目录可见,而“报告问题”只上传应用级日志:没有这两行时,用户提交的失败消息里只剩一个 `详情:.agent/runtime/errors/...json` 路径,团队拿不到诊断正文。
|
||||
|
||||
口径:两行都由 `agent/runtime_error.rs` 从同一份 diagnosis 生成,字段不退化成第二份来源;`summary` 按 320 字符、`detail` 与 `metadata` 按(1200 / 200 字符)预算先脱敏再截断,落盘前还会被 `sanitize_diagnostic_message` 二次脱敏并按行截断,因此自由文本字段在行内先压平换行。拆两行是因为整行一旦出现凭据标记会被整体替换成脱敏占位:所以**自由文本(summary / hint / detail)只放详情行**,身份行只留程序生成与调用方常量字段,详情行被整体脱敏时事件仍能按 eventId / detailRef 定位。写日志先于写 sidecar:sidecar 失败不能连日志一起丢。
|
||||
|
||||
## 2026-09-23 AGC UI 设计文档 Agent 工具化重写
|
||||
|
||||
- `ui.workflow.run` 单工具(`discover → prepare → recognize → merge → binding → status → finalize`)整体退役:它的参数就是工作流状态,任一步失败只能整轮重来,步骤产物又由前端会话落盘,Agent 侧没有任何恢复点。同时退役 `merge.rs`、`binding.rs`、`workflow.rs`、`ensure_ui_design_resource_for_prototype`(原型 → 文档的幂等查找)、`ui/ui-workflow-<sha256前24>.json` 命名与 `ui-workflow.*` manifest 阶段,均不保留兼容、迁移或 fallback。
|
||||
- 当前只保留三个工具:`ui-design-doc.from-images`(一至四张设计图 → 新建并登记文档,返回 `assetId` 与 `relativePath`,无状态)、`ui-design-doc.run-workflow`(`recognize → separate → write-back`,唯一带崩溃恢复的工具)、`ui-design-doc.into-js`(渲染 `ui/generated-<stem>-<digest>.js`,无状态、不推进 revision)。项目根目录、项目 ID 与 provider 身份由 Runtime 注入,模型只给设计图引用或文档 `assetId`。
|
||||
- `run-workflow` 的恢复判据只有一条:这一步有没有对应、且带着 State 快照的检查点行。检查点是文档旁追加式 JSONL(`ui/.<文档名>-workflow.jsonl`),行类型为 `run` / `recognize` / `separate` / `write-back` / `outdated`,`run` 行带本轮起始 State,`recognize` / `separate` 行带该步应用完之后的 State。恢复只读快照、整步跳过已完成步骤,只把新完成那一步的改动应用到文档,绝不照 DTO 重放(重放会重复登记切图、重复累加回填出错说明);只有 DTO 的旧行按未完成重跑。一轮以 `run` 开头、以首个 `write-back` 或 `outdated` 结束;只有最后一轮没有结束行时才恢复。追加前先截断崩溃留下的半行,文档中途漂移(当前 State 既不是 `run` 行快照、也不是切分后那份快照)时追加 `outdated` 并返回错误,由下一次调用显式开新一轮,不在同一次调用里自动重启。切图资源失败不回滚,靠 manifest 的 by-path 复用接上;切分 op 内部更细粒度的恢复仍由 `SeparationState` sidecar 承担,检查点日志不复制它的进度。
|
||||
- 三个工具的描述与参数文案都在 `prompts/runtime/texts/ui-design-doc.json`(目录 ID `uiDesignDoc`),Rust 侧不得硬编码面向模型的长文案。策划 `design-foundation` 的自主构建白名单同步登记这三个工具,命令映射复用 `asset.register` / `file.write`。
|
||||
|
||||
@@ -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)`,未完成条目的正文随事件下发,已完成条目一律通过历史读取。
|
||||
|
||||
@@ -0,0 +1,111 @@
|
||||
# UI 编辑器 Agent 工具化重写
|
||||
|
||||
更新时间:`2026-09-23`
|
||||
|
||||
一句话定位:把 UI 编辑器今天由前端会话编排、由单个 `ui.workflow.run` 驱动的 Agent 链路,重写成三个各自只做一件事的工具——建文档、跑工作流、出 JS——且只有工作流工具带逐步骤崩溃恢复。
|
||||
|
||||
## 现状与问题
|
||||
|
||||
- `ui.workflow.run`(已退役)把发现页面、桥接设计图、结构识别、多树合并、组件绑定、回读、finalize 全塞进一个工具,工具参数本身就是工作流状态:模型不能只做其中一步,任何一步失败都只能整轮重来。
|
||||
- 步骤产物由前端 `useUiEditorPage.ts` 落 State 再保存,Agent 侧没有任何恢复点。
|
||||
- `merge` / `binding` 两条实验链路无现役价值,已随工具一起退役(`ui_editor/commands/merge.rs`、`binding.rs`、`ui_editor/workflow.rs` 已删除)。
|
||||
|
||||
## 工具契约
|
||||
|
||||
| 工具 | 输入 | 输出 | 恢复 |
|
||||
| --- | --- | --- | --- |
|
||||
| `ui-design-doc.from-images` | 1–4 张设计图,每张给 manifest `assetId` 或项目内相对路径 | 新建文档的 `assetId` 与 `relativePath` | 无状态 |
|
||||
| `ui-design-doc.run-workflow` | 文档 `assetId` | 各步骤摘要与文档新 `revision` | 逐步骤 JSONL 检查点 |
|
||||
| `ui-design-doc.into-js` | 文档 `assetId` | `ui/generated-<stem>-<digest>.js` 路径与导出树 | 无状态 |
|
||||
|
||||
工具名用 `<域>.<动作>` 形式,域内动作保留连字符(`from-images`、`run-workflow`、`into-js`);调用这些工具时项目根目录仍由 Runtime 注入,模型不得传入宿主路径。
|
||||
|
||||
### 建文档:`ui-design-doc.from-images`
|
||||
|
||||
- 文档内设计图 id 直接采用该图在 manifest 里的 `assetId`;输入给相对路径时先登记成资源再用它的 `assetId`,不额外发明文档内身份。
|
||||
- 文档文件名沿用 `ui/UI 设计 N.json` 取号,不登记半成品命名(旧 `ui/ui-workflow-<sha256前24>.json` 口径废弃)。
|
||||
- 每次调用都新建一份文档并登记:不做「原型 → 已存在文档」的幂等查找,原 `ensure_ui_design_resource_for_prototype` 的复用分支随之删除。
|
||||
- 建项与登记在项目写锁内完成;写盘失败要回滚已登记的 manifest 条目,不留半成品。
|
||||
|
||||
### 工作流:`ui-design-doc.run-workflow`
|
||||
|
||||
只做三步,全部在 Rust 内完成,结果不回传前端编排:
|
||||
|
||||
| 步骤 | 实现 | 产物 |
|
||||
| --- | --- | --- |
|
||||
| `recognize` | `recognize_ui_impl_with_provider` | `ui_trees`(每棵树的 `src_ui_design` 指向文档内设计图) |
|
||||
| `separate` | `separate_ui_impl` | 切分图落盘 → 登记 asset → 转 `SpriteAsset` → 写入 State → 回填 `target_graphic`、清 `component_status`、写 `NeedReview` |
|
||||
| `write-back` | `save_ui_design_state_at` | 文档新 `revision`;没有回填问题且没有问题节点时再 `finalize_separation` 清理 sidecar |
|
||||
|
||||
不再有合并、组件绑定与页面级 profile/finalize 阶段;`recognize` 之前不做任何前置发现。
|
||||
|
||||
`NeedReview` 与 `component_status` 的清理是 `separation` DTO 的一部分:问题节点由 DTO 的
|
||||
`problematic_nodes` 给出,编排阶段统一回写,重放时不需要模型再判一次;文案与判据镜像
|
||||
前端 `features/ui-editor/separationStatus.ts`。
|
||||
|
||||
## 崩溃恢复
|
||||
|
||||
检查点是文档旁一条追加式 JSONL 日志,方案与被否方案见 [ADR:UI 工作流检查点用追加式 JSONL 日志](../adr/【ADR】UI工作流检查点用追加式JSONL日志-2026-09-23.md)。
|
||||
|
||||
- 位置:`ui/.<文档文件名去扩展名>-workflow.jsonl`,与文档同级,不进 manifest、不推进项目 revision。
|
||||
- 行格式:`run`(原始 State 快照 + 起始 revision)、`recognize`(DTO + 该步应用完的 State 快照)、`separate`(DTO + 该步应用完的 State 快照 + 回填说明)、`write-back`(新 revision)、`outdated`(本轮作废原因);行内另带 `at` 时间戳。
|
||||
- 判据只有一条:「本步有没有对应的行」。每行必须一次性原子追加,崩溃留下的半行一律视为该步未完成。
|
||||
- 恢复只看快照、不重放步骤:已完成的步骤在检查点里带着那一步应用完之后的 State 快照,恢复时直接读回这份 State 并整步跳过,不按记录下来的 DTO 重放该步 delta——重放会重复登记切图、重复累加回填说明,把同一份错误报两遍。只有带状态快照的行才算已完成,旧格式(只有 DTO)的行按未完成重跑。
|
||||
- 轮次:一轮以 `run` 行开头,以该轮第一行 `write-back` 或 `outdated` 结束;只有最后一轮没有结束行时才需要恢复。`outdated` 只作废未完成的那一轮,不删除既有行。
|
||||
- 半行:追加前先把日志截断到最后一个换行,丢掉崩溃留下的半行,避免它夹在日志中间。
|
||||
- 漂移:文档在轮次中途被改动(当前 State 既不是 `run` 行快照、也不是切分后那份快照)时,追加一行 `outdated` 并**返回错误**,不在同一次调用里自动重开新一轮;下一次调用看到 `outdated` 才从头开新一轮,且以当前文档为基准。
|
||||
- 写回幂等:`save` 成功但 `write-back` 行没追加时,恢复读回的切分后 State 与文档当前 State 相等,即判为已写完,直接补 `write-back` 行并返回成功。这条判据成立的前提是工作流这条路不产生随机身份:识别树的根节点 id 来自 DTO,切图资源 id 走 manifest 的 by-path 复用。
|
||||
- 切图资源不回滚:切分产出的图片与已登记资源在失败后保留,重放靠 by-path 复用接上,不做回滚清理。
|
||||
- 写回成功后才清理 sidecar:与前端切分链路一致,`backfill_errors` 为空且 `problematic_nodes` 为空时调用
|
||||
`finalize_separation`;有回填问题或问题节点时保留 sidecar,交给编辑器显示恢复入口。
|
||||
- 切分 op 内部的细粒度恢复仍由 `SeparationState` 承担(`ui-editor-separation-state.v2` sidecar),日志只记录工作流层面的步骤完成,不复制它的进度。
|
||||
- 不引入跨语言 fixture 比对:镜像的四个 seam 都是简单变换,靠同语义实现与各自单测覆盖,不为它们额外维护一套 golden。
|
||||
|
||||
## 模块布局
|
||||
|
||||
### Rust
|
||||
|
||||
```text
|
||||
src/ui_editor/agent_tools/
|
||||
├─ mod.rs 模块声明与三个工具的对外导出
|
||||
├─ creation.rs from-images:登记图片、建文档、manifest 注册、命名取号
|
||||
├─ checkpoint.rs JSONL 追加、读取、轮次判定
|
||||
├─ run_workflow.rs recognize → separate → write-back 编排与恢复
|
||||
├─ steps/
|
||||
│ ├─ mod.rs 步骤子模块声明
|
||||
│ ├─ recognize.rs 识别 DTO 落 State
|
||||
│ ├─ separate/
|
||||
│ │ ├─ mod.rs 切分 DTO 落 State(回填、清状态、写 NeedReview)
|
||||
│ │ └─ cut_images.rs 切图图片登记与 SpriteAsset 构造
|
||||
│ └─ write_back.rs 保存 State、记 write-back / outdated 行、漂移文案
|
||||
└─ test_support.rs agent_tools 单测共用夹具
|
||||
src/agent/runtime_tools/ui_design_doc.rs 工具参数解析与 Runtime 侧调用
|
||||
```
|
||||
|
||||
`into-js` 不需要独立模块:它直接复用 `persistence.rs` 的 `generate_ui_design_code_at`,
|
||||
该入口本来就只渲染 `ui/generated-<stem>-<digest>.js` 且不推进项目 revision。
|
||||
|
||||
每个文件只承担一件事;`checkpoint.rs` 不感知切分,`creation.rs` 不感知识别。
|
||||
|
||||
### 提示词目录模块
|
||||
|
||||
工具描述与参数文案一律进 `src-tauri/prompts/runtime/`,不在 Rust 里硬编码面向模型的中文长文案:
|
||||
|
||||
- 新增文本目录 `texts/ui-design-doc.json`,在 `manifest.json` 的 `textCatalogs` 登记为 `uiDesignDoc`。
|
||||
- 键名规则 `<工具名>.<字段>`,工具名用下划线形式:`from_images.description`、`run_workflow.parameters.designDocAssetId` 等;Rust 侧用 `prompt_text!("uiDesignDoc.from_images.description")` 引用。
|
||||
- 构建期 `build_support/runtime_prompt_bundle.rs` 会校验目录已登记、key 非空、bundle 内没有未登记的 `.md`/`.json`,因此新增文件必须同步 `manifest.json`。
|
||||
|
||||
## 落地顺序(全部已完成)
|
||||
|
||||
1. 清理 legacy:`ui.workflow.run`、`merge`、`binding` 与前端合并调用。
|
||||
2. 术语与 ADR:`CONTEXT.md` 四个词条、检查点 ADR。
|
||||
3. 本文档。
|
||||
4. 提示词目录模块 + 两个无状态工具(`from-images`、`into-js`)。
|
||||
5. `run-workflow` 与 JSONL 检查点(`agent_tools/{checkpoint,run_workflow}.rs` + `steps/separate/`)。
|
||||
6. 前端收口:删 `uiDesignResourceBridge` 的 `ui-workflow.*` 优先级与 `project-development` 的自动打开分支。
|
||||
7. 三个工具注册进 Runtime(`agent_native_tools`、`runtime_tools/ui_design_doc.rs`、可执行工具目录、并行账本映射、design-foundation 白名单)。
|
||||
|
||||
## 关联文档
|
||||
|
||||
- [UI 编辑器代码地图与模块职责](./【技术方案】UI编辑器代码地图与模块职责-2026-09-23.md)
|
||||
- [UI 编辑器自动切分素材工作流](./【技术方案】UI编辑器自动切分素材工作流-2026-09-08.md)
|
||||
@@ -0,0 +1,74 @@
|
||||
# UI 编辑器代码地图与模块职责
|
||||
|
||||
更新时间:`2026-09-23`
|
||||
|
||||
一句话定位:`apps/ai-game-creator-shell` 的 UI 编辑器由「Rust/Tauri 权威层 + React 会话层 + 视图层」三段组成;Rust 持有可持久化 State、校验、LLM 工具链、预览渲染与代码生成,前端只负责语义编辑、会话编排和表现。
|
||||
|
||||
## 分层与数据流
|
||||
|
||||
```text
|
||||
view/ui-editor (页面/组件)
|
||||
└─ useUiEditorSession ← features/ui-editor (语义 + adapter)
|
||||
├─ useUiEditorState / stateTransition / nodeTransformGeometry
|
||||
├─ uiDesignStateStore → Tauri command
|
||||
└─ invoke: recognize_ui / separate_ui / ...
|
||||
└─ src-tauri/src/ui_editor (权威 State、校验、持久化、切分)
|
||||
```
|
||||
|
||||
- 唯一事实来源是项目内的 `ui_design` JSON 文档(含 `revision`),前端 State 只是它的编辑副本。
|
||||
- 所有跨进程类型由 Rust 经 `ts_rs` 生成到 `features/ui-editor/types/`(当前 53 个文件),前端不得手改。
|
||||
|
||||
## Rust 侧:`src-tauri/src/ui_editor`
|
||||
|
||||
| 模块 | 职责 |
|
||||
| --- | --- |
|
||||
| `state/mod.rs` | 权威 State 根类型:`State`(`ui_trees` + 界面图/sprite/字体三张资源表)、`UITree`;ts-rs 导出源 |
|
||||
| `layout/` | 节点模型:`Node`、`NodeMetadata`/`StageStatus`、`ControlLayout`、`Container`、`NodeOffset`、`transform`、`ChildrenDisplayMode`(`Stack`/`Exclusive`) |
|
||||
| `component/` | 组件枚举 `Component::{Image, Text}`、`NodeComponent`(LLM 工具载荷的 `PureNode`/`WithComponent` 判别式) |
|
||||
| `resource/` | 界面图(`path` / `pixel_size` / `pixels_per_unit`)、sprite(含 `SpriteBorder` 九宫格)、字体(格式/媒体类型/CSS format)资源描述 |
|
||||
| `persistence.rs` | 文档读写、`revision` 乐观并发保存、领域校验(重复 ID、树/资源引用、组件状态)、代码生成写盘 |
|
||||
| `agent_tools/` | Agent 工具链路:`creation.rs` 用一至四张设计图新建文档(登记未登记图片、按 `ui/UI 设计 N.json` 取号、持项目写锁装 revision 0、失败回滚)、`checkpoint.rs` JSONL 检查点日志、`run_workflow.rs` 三步编排与崩溃恢复(恢复只读检查点里的 State 快照、整步跳过已完成步骤,不按 DTO 重放)、`steps/` 逐步落 State(`mod.rs` 步骤子模块声明、`recognize.rs` 识别、`separate/` 切分:`cut_images.rs` 登记切图与 `SpriteAsset` 构造、`mod.rs` 回填与问题状态、`write_back.rs` 保存与漂移文案) |
|
||||
| `html_renderer/` | 由 State 生成 HTML 片段与 JS(maud + 布局/组件 CSS 映射),供预览与 `ui/generated-*.js` |
|
||||
| `commands/` | LLM 工具链:`recognition`(结构识别)、`separation/`(自动切分素材)、`utils.rs`(LLM 请求、重试、`required_tool_arguments`) |
|
||||
| `commands/separation/` | 切分批处理、截图/预切、sidecar 恢复(inspect / finalize / discard)、patch 回写 |
|
||||
|
||||
Agent 工具(`agent_native_tools.rs` + `agent/runtime_tools/ui_design_doc.rs`):`ui-design-doc.from-images` 新建文档并登记;`ui-design-doc.run-workflow` 在 Rust 内跑 `recognize → separate → write-back`,按文档旁 JSONL 检查点恢复;`ui-design-doc.into-js` 复用 `generate_ui_design_code_at` 产出 `ui/generated-*.js`,不推进 revision。旧 `ui.workflow.run` 与 `ensure_ui_design_resource_for_prototype` 已退役。
|
||||
|
||||
关键命令(`main.rs` 注册):`load_ui_design_state`、`save_ui_design_state`、`generate_ui_design_code`、`create_ui_design_doc_from_images`、`recognize_ui`、`separate_ui`、`inspect_separation_recovery`、`finalize_separation`、`discard_separation_recovery`。
|
||||
|
||||
保存语义(`save_ui_design_state_at`):`Saved` / `Unchanged` / `Conflict`(返回当前快照)三态;先 `validate_state` 再持锁重读比对 `expected_revision`,成功后推进项目 revision。代码生成只接受已保存的 revision,产物路径为 `ui/generated-<stem>-<digest>.js`。
|
||||
|
||||
## 前端:`src/features/ui-editor`(无视图依赖的语义层)
|
||||
|
||||
- `useUiEditorState.ts`:State reducer + 撤销/重做(`undo/redo/resetHistory`)、`isLocked` 与 `runWithStateLocked`、节点/资源/树偏移的语义写操作、`createTree`(新树横向排布 + `UI_TREE_PADDING`)、删除影响 projection。
|
||||
- `stateTransition.ts`:React-free 的命令 → State 语义 transition(`set-tree-offset`、`set-node-metadata`、`set-node-component`)。
|
||||
- `nodeTransformGeometry.ts`:State 级节点几何(页面矩形、父矩形、resize 手柄反演),预览/Inspector 共用。
|
||||
- `stateInvariants.ts`:保存前不变量 projection,给视图稳定的中文失败信息;Rust 仍是权威校验。
|
||||
- `uiDesignStateStore.ts`:`IUiDesignStateStore`(`load`/`save`/`generateCode`)+ Tauri 实现 + 内存替身。
|
||||
- 结果应用 seam:`recognition.ts`、`separationStatus.ts`(问题节点 → `NeedReview`)。
|
||||
- 概览 projection:`stageStatusOverview.ts`、`separationOverview.ts`。
|
||||
- 前置校验:`requisites.ts` 在发起 LLM 操作前检查必需资源与结果完整性。
|
||||
- 适配器:`importAdapter.ts`(图片解码、批量导入、字体准备)、`uiDesignResourceBridge.ts`(调用 `create_ui_design_doc_from_images` 新建文档)、`useUiEditorFontFaces.ts`(私有字体族加载)、`spriteBorder.ts`。
|
||||
- `utils/`:State → CSS 映射(`componentToCss`、`controlLayoutToCss`、`textStyleToCss`、`transform/tf2css`)、`treeUtils`。
|
||||
|
||||
## 前端:`src/view/ui-editor`(表现与编排)
|
||||
|
||||
- `useUiEditorPage.ts`:`useUiEditorSession` 是视图与 adapter 的唯一协调边界,产出 `input` / `canvas` / `inspector` / `workflow` / `dialogs` / `save` 六个小 projection;视图不接收完整 controller。
|
||||
- `index.tsx`:页面骨架(输入侧栏、预览、Inspector、工具栏、保存/生成结果弹窗、键盘快捷键绑定),由 `view/project-development` 挂载。
|
||||
- `model.ts`:两步工作流(识别界面结构 / 自动切分素材)、导入种类、操作失败文案。
|
||||
- `operationLifecycle.ts`:recognition/separation 共用的异步操作 adapter。
|
||||
- `components/`:`InputSidebar`、`UiTreePanel`、`Inspector/*`(Transform、Components Text/Image、SpriteBorder)、`preview/*`(`PreviewWorkspace`、`UiTreeRenderer`、组件视图、排他子节点 tab、缩放/平移/拖拽手势)、工作流与结果弹窗。界面图没有独立显示名字段,列表与 Inspector 的统一显示名取 `path` basename(`view/project-development/resourceAssetDisplayName.ts`)。
|
||||
- 已退役的 render mode 由会话级开关 `showFrame` / `showOriginImage` / `showComponent` 取代。
|
||||
|
||||
## 扩展指引
|
||||
|
||||
- 新增节点/组件字段:先改 `layout/`(或 `component/`)并让 ts-rs 重新导出,再补 `stateTransition`、`stateInvariants`、`persistence::validate_node`、Inspector 与预览映射。
|
||||
- 新增 LLM 步骤:在 `commands/` 内自成 command(prompt + schema + 领域校验 + materializer),共用 `commands::utils` 的请求、重试与 tool-call 解析 seam。
|
||||
- 新增界面图字段:改 `resource/ui_design_image.rs` 后让 ts-rs 重新导出,再补 `persistence::validate_state`、导入 adapter(`features/ui-editor/importAdapter.ts`)与 Inspector / 预览展示。
|
||||
|
||||
## 关联文档
|
||||
|
||||
- [UI 编辑会话模块边界](./【前端架构】UI编辑会话模块边界-2026-08-19.md)
|
||||
- [UI 编辑器 Godot 容器布局模型](./【技术方案】UI编辑器Godot容器布局模型-2026-08-18.md)
|
||||
- [UI 编辑器子节点显示规则](./【技术方案】UI编辑器子节点显示规则-2026-08-18.md)
|
||||
- [UI 编辑器自动切分素材工作流](./【技术方案】UI编辑器自动切分素材工作流-2026-09-08.md)
|
||||
@@ -2,11 +2,11 @@
|
||||
|
||||
## 目标
|
||||
|
||||
UI 编辑器的“分析参考图”“识别界面结构”“自动切分素材”三个工作流动作在每次运行结束后,用独立的阻塞通知弹窗明确反馈结果,避免仅依赖卡片内一行状态文本而被忽略。
|
||||
UI 编辑器的“识别界面结构”“自动切分素材”两个工作流动作在每次运行结束后,用独立的阻塞通知弹窗明确反馈结果,避免仅依赖卡片内一行状态文本而被忽略。
|
||||
|
||||
## 交互约定
|
||||
|
||||
- 三个动作的每次运行在终态(成功或失败)时自动弹出一次通知。
|
||||
- 两个动作的每次运行在终态(成功或失败)时自动弹出一次通知。
|
||||
- 弹窗打开期间遮挡并阻塞工作台底层交互;关闭后恢复当前步骤,不自动切换步骤、不自动重跑。
|
||||
- 使用现有 `ThemedModal` 的普通关闭行为(遮罩、Esc 和关闭按钮均可关闭)。
|
||||
- 弹窗仅承载通知,不提供“继续”“重试”或其他业务操作。
|
||||
@@ -19,7 +19,6 @@ UI 编辑器的“分析参考图”“识别界面结构”“自动切分素
|
||||
|
||||
成功状态的基线文案:
|
||||
|
||||
- 分析参考图:保留已应用的语义建议数量;若现有状态可可靠取得问题/待确认数量,则一并展示。
|
||||
- 识别界面结构:保留替换的界面树数量,并展示识别结果中的待检查/必须修复数量(若可取得)。
|
||||
- 自动切分素材:保留现有 `B/B` 批次计数,改为用户可读的切分结果。
|
||||
|
||||
@@ -28,12 +27,12 @@ UI 编辑器的“分析参考图”“识别界面结构”“自动切分素
|
||||
## 实现边界
|
||||
|
||||
- 新增独立的工作流通知弹窗组件文件,组件只负责展示和关闭,不包含工作流领域规则或后端副作用。
|
||||
- 在 UI 编辑器页面/会话投影中维护临时通知状态,并在三个异步动作的成功与失败终态写入。
|
||||
- 在 UI 编辑器页面/会话投影中维护临时通知状态,并在两个异步动作的成功与失败终态写入。
|
||||
- 不新增后端字段或公开契约;数量只能使用当前前端已有且可靠的数据。
|
||||
|
||||
## 验收
|
||||
|
||||
1. 三个动作成功和失败终态各弹出一次通知;绑定批次只弹最终一次。
|
||||
1. 两个动作成功和失败终态各弹出一次通知;绑定批次只弹最终一次。
|
||||
2. 弹窗打开时底层工作台不可操作,且无继续/重试等业务按钮。
|
||||
3. 弹窗可通过标准关闭方式退出;关闭后卡片状态仍可见。
|
||||
4. 每条成功文案保留原有数量信息并增加可用的检查数量,所有文案包含“请检查”。
|
||||
|
||||
@@ -6,9 +6,13 @@ UI 编辑器预览中的节点拖动和缩放在指针移动期间只更新预
|
||||
|
||||
指针取消、页面切换、树切换、组件卸载或没有超过拖动阈值时,不提交变换,并清理临时预览值。指针松开后的最终变换属于正常 State 修改,会参与脏状态、保存和后端持久化;仅拖动期间的临时变换不会进入这些流程。资产文件也不会因该交互被删除。
|
||||
|
||||
画布视口平移(空格+左键、中键、右键拖拽)属于视图操作:只改前端视口,不写编辑器 State,也不进撤销重做历史。右键同时承载节点菜单,两者按同一个拖动阈值互斥——按下后越过阈值即判定为平移,抬起时不再弹菜单;未越阈值且在预览内抬起才弹节点菜单。预览内按钮 2 的 `contextmenu` 由预览拦截(按下即触发,不能等到手势结束),因此右键菜单在指针抬起时才出现。
|
||||
|
||||
## 实现边界
|
||||
|
||||
- `useNodeTransformInteraction` 保存手势起始变换和最后一次有效变换。
|
||||
- `UiTreeRenderer` 通过 `previewTransforms` 渲染临时变换。
|
||||
- `canvas.updateNodeTransform` 仅在 `pointerup` 提交,`pointercancel` 不提交。
|
||||
- 拖动和缩放继续共用单指针捕获与有限数校验。
|
||||
- 拖动阈值抽到 `previewDragThreshold.ts`,左键拖动与右键平移共用同一个 `DRAG_THRESHOLD_SCREEN_PX`。
|
||||
- 右键平移与菜单裁决放在预览的 `previewRightPanGesture.ts` 纯状态机里,`useNodeTransformInteraction` 只负责左键拖动与缩放。
|
||||
|
||||
@@ -20,6 +20,7 @@
|
||||
- 仅在存在可缩放视口且确认命中快捷键时调用 `preventDefault()` 与 `stopPropagation()`,防止浏览器页面同时缩放。
|
||||
- 保留现有 `Ctrl/Cmd+0` 适配画布与 `Ctrl/Cmd+1` 恢复 100% 行为,不增加其他重置快捷键。缩放仍是当前预览实例的临时 UI 状态。
|
||||
- 快捷键和百分比使用逻辑 `viewport.scale` 作为缩放真相;共享 `CanvasWorld` 的渲染 transform 可能包含超采样换算,验证时不得直接把 CSS transform 值当作用户可见比例。
|
||||
- 预览画布背景继续使用圆点网格,并按 `14/28/56/112…` 世界步长的 2 倍档位自适应缩放;屏幕间距目标约为 20–40px,缩放过小时自动加倍步长、放大时自动减半步长。网格背景位置继续跟随 `viewport.x/y`,保持世界原点对齐,不改变圆点样式。
|
||||
- 保留快捷键与缩放焦点边界的组件级回归测试,不扩展端到端测试。
|
||||
|
||||
## 验收
|
||||
|
||||
@@ -66,6 +66,7 @@
|
||||
- `docs/technical/【技术方案】AI游戏创作Agent Runtime V1.1-2026-07-12.md`
|
||||
- `docs/technical/【技术说明】AGC接第三方Provider的兼容性缺陷-2026-08-19.md`
|
||||
- `docs/technical/【测试用例】AIWeb工程静态预览MVP验收清单-2026-06-13.md`
|
||||
- `docs/【技术方案】UI工作流资源桥接与Runtime执行-2026-08-24.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`。
|
||||
|
||||
|
||||
@@ -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}/` 目录下载当成工程。
|
||||
|
||||
@@ -1,4 +1,9 @@
|
||||
# UI 工作流资源桥接与 Runtime 执行
|
||||
> 文档状态:`historical`
|
||||
本方案描述的 `ui.workflow.run` 单工具、`discover → prepare → recognize → merge → binding → status → finalize` 阶段、
|
||||
`ensure_ui_design_resource_for_prototype` 幂等桥接与 `.agent/ui-workflows/<hash>.json` 回执均已退役,
|
||||
仅用于追溯。当前 Agent 链路见 [`【技术方案】UI编辑器Agent工具化重写-2026-09-23.md`](./technical/【技术方案】UI编辑器Agent工具化重写-2026-09-23.md):
|
||||
三个工具分别为 `ui-design-doc.from-images`、`ui-design-doc.run-workflow`、`ui-design-doc.into-js`。
|
||||
|
||||
## 目标
|
||||
|
||||
@@ -87,9 +92,9 @@ JSON 文档读取、State 校验或 renderer 失败时,在同一引用后追
|
||||
|
||||
- 按 manifest asset id、`source.resourceId`、`source.assetObjectId` 识别已有关联,避免重复创建。
|
||||
- 没有关联时原子创建 `ui/UI 设计 N.json`,登记 `kind=ui-design-doc`、`application/json`,并把原型图作为首张页面设计图载入 State。
|
||||
- 成功后通过 `onManifestChange` 更新客户端资源投影,再打开 UI 编辑器;普通桥接从 `reference-analysis` 开始。
|
||||
- 成功后通过 `onManifestChange` 更新客户端资源投影,再打开 UI 编辑器;普通桥接从 `structure-recognition` 开始。
|
||||
|
||||
点击已有 `ui-design-doc` 资源直接打开 UI 编辑器。若 manifest 阶段为 `ui-workflow.completed`,工作台自动打开该资源的 `asset-separation` 阶段(最远步骤为 2),交给用户做最终检查和手动调整。
|
||||
点击已有 `ui-design-doc` 资源直接打开 UI 编辑器。若 manifest 阶段为 `ui-workflow.completed`,工作台自动打开该资源的 `asset-separation` 阶段(最远步骤为 `asset-separation`),交给用户做最终检查和手动调整。
|
||||
|
||||
自动切分达到返工上限的 problematic 节点会随分离 DTO 返回每节点的 `problem_history`,并由编辑器回写为 `component_status = NeedReview(...)`。`SeparationOverview` 只读取 UI State 中的状态来计数和定位;该结果仍按“已尽力完成”报告成功并执行既有 finalize,剩余节点由用户在概览定位后手动处理或再次发起分离。
|
||||
|
||||
|
||||
Reference in New Issue
Block a user