保留唯一的thread manager作为direct project的状态来源 (#384)

说明: 在把工作交给段哥前还没有实现direct project聊天页面的迁移, 导致在 #375 里用很复杂的实现又做了一套事件流, 实测还有会话丢失的bug, 我在这里把数据获取的部分迁移到 #367 上

---------

Co-authored-by: 孔令弘 <ink29535@proton.me>
Reviewed-on: https://git.genarrative.world/git/GenarrativeAI/Genarrative/pulls/384
Reviewed-by: 孔令弘 <ink29535@proton.me>
Co-authored-by: 王德宇 <kvtodev@outlook.com>
Co-committed-by: 王德宇 <kvtodev@outlook.com>

docs/technical/【技术方案】AI游戏创作智能体App实施计划-2026-06-24.md

@@ -48,10 +48,6 @@
 
 ## 2026-09-16 DirectProject 回合展示唯一归属
 
-- 聊天历史使用 `read_direct_project_history_slice` 的 `messagesOnly: true` 模式，按有正文的 user/assistant 消息分页，默认 20 条；工具/推理原始记录不占聊天页名额、不进入聊天分页响应，也不从磁盘删除。接口省略该选项时维持原始 item 切片语义。响应给出明确的 `oldestItemId` 游标；消息投影不能重新发明分页位置。
-- 消息模式读取逐行过滤原始记录，不在内存中积累整份工具输出；正文、原始 ID 和信封时间原样保留。旧的无 ID 消息不能凭空生成身份，必要时向前扩展到已有消息 ID 边界；没有更早消息时结束分页。
-- 首屏和加载更早消息共用分页解析；重复点击只发一个请求，重叠消息按原始 ID 去重并保留当前显示版本。切项目、同项目重新加载及 A→B→A 的迟到响应不得覆盖当前消息、游标或加载状态；失败保留已有消息与分页位置并允许重试。
-- 历史读取来源与 Runtime 所有权分开记录；从磁盘分页读出的消息不能当作未落盘实时消息保留到新页末尾。重新读取历史时回到最新页，旧页仍可从原生游标再次向前加载；真正尚未回读到的实时消息继续保留，不改原始日志、时间或内容。
 - 交付合同：实时消息、历史回读、工具详情与最终回复先归一为按 `clientTurnId` 唯一的回合，再渲染一次。用户消息始终保留；同一回合的正文、工具和耗时不能从消息、实时尾部、未归属尾部等多个出口重复展示。
 - 归属来自 `direct-codex:{clientTurnId}:{role}`、文本流中保留的原始 item ID，以及项目历史内明确用户记录之后的 assistant 记录。先在已加载的完整消息集合中关联，再做可见分页；持久历史继续通过 canonical item 切片懒加载，`hasMore` 为真时，未加载回合的工具流不得漂到当前页尾部。禁止将第 N 个有工具回合配给第 N 条用户消息，禁止按文本长度、标点或时间窗猜测归属。缺身份的旧记录保留，不猜造其与其它回合的关联。
 - 有回合流时正文与工具位置仅来自 item 边界与 `seq`，工具详情按该回合的 `callId` 关联；没有流时同一个回合容器显示历史消息与工具。整轮累计文本仅在活动回合尚无流和持久 assistant 时作兜底，不另建实时消息出口。

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

@@ -1,6 +1,6 @@
 # DirectProject Codex 原始历史与异常恢复
 
-更新时间：`2026-09-15`
+更新时间：`2026-09-16`
 
 ## 目标
 
@@ -18,7 +18,7 @@ DirectProject 只使用 `.agent/conversations/project.jsonl` 作为对话历史
 
 `project.jsonl` 的 `payload` 必须是未经改写的 Responses item。AGC 前端 user input 先以 canonical user message item 形式写入；发送给 app-server 前由 Rust 投影为 Codex 可接受的 `message` item，AGC 私有 content part 不会穿透到 wire。Codex 返回的 `rawResponseItem/completed.params.item` 原样追加。native 工具、MCP 工具、reasoning、调用参数和调用结果都保留完整内容，不截断、不摘要、不保存运行态 delta/started 事件。
 
-Thread Manager 的运行态事件是另一份内存协议：app-server 通知先经过安全投影，再只发送 item 类型、item ID、delta 文本和 turn 终态等必要字段；不得把完整 item、工具参数或调用结果转发到前端。完整 item 仍只通过上述 JSONL 历史读取。
+Thread Manager 的运行态事件是另一份内存协议：app-server 通知先经过安全投影（挑字段、脱敏、截断、路径归一），再按与历史切片同形的脱敏原始条目（`itemType`、唯一 `itemId`、正文或工具明细）加 delta 文本与 turn 终态下发；搬运层不生成卡片形状，也不把未经脱敏的完整 item 转发到前端。注入 Codex 用的完整 item 仍只从上述 JSONL 历史读取。
 
 DirectProject 自己的写侧只写新格式：格式切换（#282）时仍会写旧行的路径已收口——显式 Codex 返回只落在自己的 journal `.agent/conversations/codex-responses.jsonl`，不再投影进 `project.jsonl`。
 
@@ -96,26 +96,54 @@ readHistory(threadId, { beforeItemId?, limit }) -> {
 
 `consume` 不接收或返回 cursor。每个 subscriber 在 Rust 内部持有自己的 cursor，并在加锁的临界区内完成过期判断、读取和 cursor 前进。前端只持有 `subscriptionId` 与 reducer state。并发 `consume` 不重复返回同一批事件。
 
-`notify` 只负责唤醒，不携带事件、cursor 或持久化状态。前端收到通知后调用 `consume`；通知可合并、重复或丢失，事件完整性由 `consume` 保证。
+`notify` 只负责唤醒，不携带事件、cursor 或持久化状态。前端收到通知后调用 `consume`；通知可合并、重复或丢失，事件完整性由 `consume` 保证——但前提是前端确实唤醒了 `consume`，见下条的回执竞态。
+
+`subscribe` 在同一个边界内先把新 subscriber 的游标钉在当时的队尾，再收集 bootstrap 的运行态事件，因此 bootstrap 返回的那批事件**就是**该 subscriber 此刻应处理的事件：前端直接 reduce 它们即可，不存在"先补一次 `consume` 才能拿到已暂存事件"的步骤。第一个例外只有回执竞态：Rust 侧一注册完 subscriber 就开始 `notify`，而前端要等回执到达才知道自己的 `subscriptionId`，这段窗口内的通知拿不到订阅身份。前端因此必须记一笔欠账，回执到达后立刻补一次 `consume` 取回那批事件；否则事件会卡在队列里等下一次通知，而一次回合的最后一个事件之后可能再也没有通知。除此之外不轮询，也不设任何定时 `consume`——唤醒只由 `notify` 负责。用定时器兜底既自举不了（判断"有活动回合"本身依赖事件），也把唤醒机制变成两套。
+
+首屏历史不通过"读取整份对话"的命令获取：`subscribe` 返回的 `lastCompletedItemId` 就是首屏锚点，前端据此调用 `readHistory` 取最近的切片，再按滚动或按钮继续向前分页。系统不提供返回整份对话历史的命令。
 
 ### 事件和顺序
 
-Thread 内所有公开事件共用一个单调递增 seq；seq 允许跳号，前端不要求连续。事件 envelope 至少包含：
+Thread 内所有公开事件共用一个单调递增 seq，但 **seq 只是 Thread Manager 的内部游标事实，不下发**：同一个 subscriber 的 `consume` 按队列顺序返回事件数组，数组顺序就是前端要处理的顺序，前端因此不需要 item 级 cursor 或第二套 reducer。
+
+线上模型是 ts-rs 导出的 tagged enum（`agent/direct_thread_wire.rs`），前端消费 `src/features/project-workspace/generated/` 里的生成绑定，改 Rust 模型后跑 `cargo test export_bindings` 重新生成；毫秒时间戳标 `#[ts(as = "f64")]`，因为 ts-rs 默认把 `u64` 映射成 `bigint`，而 Tauri 的 JSON 通道传的是 `number`。
+
+事件按 `type` 区分，条目按 `itemType` 区分：
 
 ```ts
-{
-  seq: number,
-  type: string,
-  turnId: string,
-  itemId?: string,
-  payload: unknown,
-}
+type DirectThreadEvent =
+  | { type: 'turn.started' }
+  | { type: 'turn.completed'; status: string }
+  | { type: 'item.started'; item: DirectThreadItem }
+  | { type: 'item.completed'; item: DirectThreadItem }
+  | { type: 'item.delta'; itemId: string; kind: 'message' | 'reasoning'; delta: string }
+  | { type: 'request'; kind: 'approval.requested' | 'ask.requested' | 'request.resolved'; requestId: string | null };
 ```
 
-进入 Thread Manager 的是已经完成安全过滤和协议标准化的公开 raw event，不是未经审查的 app-server JSON。事件可交错包含多个并发 item：`item.started`、`item.delta`、`item.completed`、approval/request/resolved 事件，以及 `turn.started`、`turn.completed` 生命周期事件。前端按 `turnId` / `itemId` 分发并 reduce，不需要 item 级 cursor 或第二套 reducer。
+进入 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` 布尔，历史条目也不记录回合身份。
 
 一个 thread 同时最多有一个 active turn；一个 turn 内允许多个并发 item。`turn.completed` 必须在该 turn 的完成 item 均成功持久化后进入队列，前端据此结束运行态；不能用“不存在 unfinished item”猜测 turn 是否完成。
 
+前端 reducer 的活动回合判定只有一条：事件序列中出现 `turn.started` 且其后没有 `turn.completed` 时才是活动回合，界面才允许显示忙碌态。`subscribe` bootstrap 里没有这样的序列，就表示当前没有活动回合；Thread Manager 队列随进程消失，因此进程重启后历史里留下的半截回合一律按已结束渲染，前端不发明中断态，也不从历史条目反推忙碌态。
+
+生命周期锚点独立于 replay 队列保存：`turn.started` / `turn.completed` 事件即使已被队列前缀回收，`subscribe` 仍必须把最新的一条作为 bootstrap 事件返回。因此进程内任意时刻新建订阅，都能判定最新回合是运行中还是已结束，不依赖"未完成 item 恰好还在队列里"。
+
+`item.started` 与 `item.completed` 必须携带与历史切片同形的**脱敏原始条目**（经同一套挑字段、脱敏、截断、路径归一），不得只给 item 类型或空 payload。前端不得依赖"按 `itemId` 单点取快照"补齐正文：Rust 不提供 `getItemSnapshot(itemId)`，未完成条目的正文随事件下发，已完成条目一律通过历史读取。
+
+条目形状的职责边界固定为三条：
+
+1. **搬运层不生成展示形状**。Thread Manager 只下发 Codex 原始条目（`itemType` 原样透传，正文与工具明细脱敏后带上限截断），不生成工具卡片的 `kind`、标题、折叠摘要，也不判断哪些条目要显示。
+2. **只有一个条目身份**。工具条目在 `project.jsonl` 里带两个 id（调用 id 与 response item id，同一调用的调用与输出共用前者；codex-rs `thread_history.rs` 中所有工具 item 都是 `id: payload.call_id.clone()`），所以在进队列前归一成一个 `itemId`。Thread Manager 与前端都不得再出现第二个 id 概念。
+3. **合并只在前端，且只保留"先到定形、后到补空白"**。第一次见到的快照决定卡片形状，后续快照只补输出与状态；同一调用只出现一张卡片。只有"后到信息一定更全"时才例外：正文取更长的一份、工具状态允许从 `running` 升级到终态、`updatedAt` 取较新的时间。
+
+前端不保留增量缓冲：`item.delta` 直接追加到运行态条目的正文（正文只增不减）。`turn.completed` 把当前回合的运行态条目并入历史再清空，条目既不消失也不重复；失败与中止说明只在运行期显示，不写进 `project.jsonl`。
+
+历史切片的 `firstItemId` 不是上述归一身份：分页锚点必须是 `project.jsonl` 里的原始 item id，由 Rust 从文件扫描单独算出。
+
+思考正文以 `item.delta{kind:"reasoning"}` 流式下发（来源是 app-server 的 `item/reasoning/summaryTextDelta` 与 `item/reasoning/textDelta`）。这不放宽可见文本范围：被下发的就是此前已在 `item.completed` 展示、并已落进 `project.jsonl` 的同一段文本；plan 文本与命令输出仍然只降级为活动状态，不下发正文。
+
 ### 队列、subscriber 和回收
 
 每个 thread 一个 Vec-based append-only replay queue，使用逻辑 head 偏移清理前缀，不做中间删除。完成 item 的事件在持久化成功后才可进入普通 replay 回收流程；unfinished item 的事件必须保留到 item 完成，不能被普通上限截断。

docs/technical/【技术方案】GameAgent对话工具调用卡片-2026-09-14.md

@@ -1,5 +1,14 @@
 # 【技术方案】GameAgent 对话工具调用卡片（Codex 风格）-2026-09-14
 
+## 2026-09-16 修订（当前状态）
+
+本方案的**卡片表现层**（折叠 / 展开、标题与摘要文案、耗时与时间显示、脱敏、无障碍、样式）仍然是有效契约；**数据来源层**已被 `docs/adr/【ADR】DirectProject对话历史单一事实源-2026-09-16.md` 取代，边界改为：
+
+- DirectProject 聊天框的工具卡片由**运行态事件 + 项目对话历史**在前端投影生成（`features/project-workspace/directThreadItemProjection.ts`），不再读取 `tool-calls.jsonl`；`read_direct_tool_calls` 命令与 Rust 侧 `read_direct_tool_calls_at` 回读函数已删除，该文件现在只有 DirectRuntime 的写入。
+- 报文中不再有 `toolCalls` 增量字段与 `GameCreatorDirectTurnUpdateEvent` 这条实时链路：卡片形状由前端从脱敏原始条目生成，事件里只有 `item.started` / `item.completed` / `item.delta`（线上模型见 `agent/direct_thread_wire.rs`，由 ts-rs 导出绑定）。
+- 卡片身份只有一个 `itemId`（工具条目在 `project.jsonl` 里带的两个 id 已在 Rust 边界归一），前端卡片形状是 `Omit<GameCreatorDirectToolCall, 'turnId'>`：聊天卡片不再有回合身份。
+- 下面「### 1. 工具调用条目」「### 2. 实时事件」「### 3. 回读命令」三节描述的是 DirectRuntime 自己的账本（`tool-calls.jsonl` 的写入形状与脱敏规则仍然有效，DirectRuntime 保留），**不再是 DirectProject 聊天框的读路径**；「### 4. 前端合并与渲染」中按 `turnId` 归并、按 `turn-stream.jsonl` 的 `seq` 交替的规则已作废，改为按事件顺序 + 历史文件顺序投影。
+
 ## 一句话交付
 
 把 GameAgent 右侧对话面板里的「执行命令 / 写文件 / 调工具」从一行中文进度文本，改成 Codex 桌面客户端那样的**可折叠卡片**（折叠态一行摘要，展开态看命令与文件明细），并且在**刷新页面、重开项目后仍然存在**。
@@ -47,15 +56,15 @@ toolCalls?: DirectTurnToolCall[] | null;
 - 字段**可选**：老版本事件解析路径必须保持兼容（前端拿到 `undefined` 时行为与现在一致）。
 - `DirectTurnToolCall` 与上面 payload 同形（去掉 `turnId`）。
 
-### 3. 回读命令
+### 3. 落盘契约（写侧）
 
-新增 Tauri 命令 `read_direct_tool_calls(projectPath)`，返回按时间正序的 `DirectTurnToolCall[]`。
+DirectRuntime 写 `<projectRoot>/.agent/conversations/tool-calls.jsonl`；回读命令与 Rust 侧回读函数已随聊天读路径退役删除，下面的语义约束的是**写进文件的行**。
 
 - **上限语义**：200 条是「按时间保留最新 200 条」。超出时更早回合的卡片会被**静默丢弃**（老回合卡片会消失），不做分页、不做历史回填；同一 `id` 的多条记录先按 `updatedAt` 合并，再按时间正序裁剪。
 - 历史文件缺失 → 返回空数组，不报错。
 - 单行损坏 → 逐行读字节并逐行解码，跳过该行继续，不整体失败；只有损坏字节与下一行黏成一行（例如写入被截断、缺失换行）时，被丢掉的也只是那**一行**，其后的合法记录必须继续读回（与 Codex item 流一样是"尽力而为"的展示数据，不是业务真相）。
 
-### 4. 前端合并与渲染（回合唯一归属，连续工具成块）
+### 4. 前端合并与渲染（回合唯一归属，连续工具成块）——已作废，见文首修订
 
 - 加载对话时按 `turnId` 归并为唯一回合容器，用户消息保留在该回合前部。有 `turn-stream.jsonl` 时，文本与工具按 item `seq` 交替，连续工具合为一块，遇到文本另起一块；没有流的历史回合才采用“工具块 + 历史正文”。
 - 回合完成后，中间文本及所有工具块统一收进默认关闭的“执行过程”；最终回复及失败提示留在外面。展开后仍按原顺序查看中间输出和工具详情；运行中不使用外层折叠区。用户消息的发送时间从消息自身的历史时间读取，不能拿工具起点补造。