dominds 1.3.1 → 1.4.2

package/dist/docs/dominds-agent-priming.zh.md

@@ -1,196 +0,0 @@
-# Dominds 智能体启动（Priming）：引导祂做给自己看
-
-英文版：[English](./dominds-agent-priming.md)
-
-## 摘要
-
-Dominds 的诉请（Tellask，`tellask* function call`）与扪心自问（FBR，`freshBootsReasoning`）并不是“写在系统提示里的约定”，而是**后端真实可驱动、可执行、可回传、可持久化**的机制。
-
-问题在于：即使系统提示把这些机制写得再细，大多数基础模型也并未在“真的可以随时拉一个队友去跑 shell 命令并把结果带回来”的世界里被训练过，因此容易把提示当成“说说而已 / 仅供参考”。这会直接削弱诉请与 FBR 的可用性。
-
-因此引入 **智能体启动（Agent Priming）**：在一个对话创建之初，运行一段极短、极拟真的“真实诉请 + 真实回传 + 真实 FBR + 真实综合提炼”，让智能体产生明确的体感。
-
-更贴切地说，这是在**引导祂做给自己看**：让智能体亲身走一遍（诉请→回传→FBR→综合提炼），从“听说有这个机制”变成“我刚刚用过它”。
-
-这与心理学的**启动效应（priming effect）**在“机制形态”上相似：一次早期、具体、可感的刺激，会显著影响后续的期待与行为模式。在 Dominds 里，我们把这种“启动”落在**可验证的真实交互**上，而不是落在更长更复杂的宣告式系统提示上。
-
-体感建立后，系统提示可以**大幅简化**：只保留“短而准确”的契约说明即可，把“这在本环境里真实可用”的可信度交给一次真实启动来完成。
-
-相关文档：
-
-- 诉请机制与对话系统：[`dialog-system.zh.md`](./dialog-system.zh.md)
-- 术语约定（主线/支线；诉请方/应答方）：[`dominds-terminology.md`](./dominds-terminology.md)
-- FBR（`freshBootsReasoning`）：[`fbr.zh.md`](./fbr.zh.md)
-- 工作语言 vs UI 语言：[`i18n.zh.md`](./i18n.zh.md)
-
----
-
-## 目标
-
-- 在对话一开始就建立“诉请/回传/持久化都是真的”的信任。
-- 在对话一开始就跑通一次 `freshBootsReasoning` 的 FBR 回路。
-- 把“发起 FBR 后先等待回贴，再做综合决策”的时序固化为肌肉记忆。
-- 把多份 FBR 草稿做一次**综合提炼**，把“取精华、去糟粕”的动作也变成体感的一部分。
-- 过程足够小、可控、低风险（默认只执行 `uname -a`）。
-- 记录从多角度都高度拟真：后端存档 + 前端可见的对话转录。
-
-## 非目标
-
-- 不在创建对话时执行任意用户输入的命令。
-- 不收集敏感信息（默认只采集最小的 OS/Kernel 识别信息）。
-- 不替代系统提示/设计文档：这是“启动与体感补强”，不是完整规范的主载体。
-
----
-
-## 概念（用户视角）
-
-- **主线对话**：用户与主要智能体交互的那条线。
-- **支线对话**：由诉请 / FBR 触发的临时工作线，产出结果回传主线。
-- **诉请（Tellask）**：以 `tellask({ targetAgentId: "<memberId>", sessionSlug: "<slug>", tellaskContent: "..." })` 向队友/对话发起的结构化请求。
-- **Shell 专员（shell specialist）**：被允许执行 shell 命令并回传结果的队友（由 `shell_specialists` 配置指定）。
-- **FBR（扪心自问）**：以 `freshBootsReasoning` 触发的“无工具支线推理”，产出报告回传主线。
-
----
-
-## 运行流程（对话创建时）
-
-智能体启动发生在**第一条用户消息被处理之前**，除非用户在创建对话时明确选择跳过。
-
-### 1）选择执行路径
-
-1. 如果 team 配置里存在 `shell_specialists`，选择一个 shell 专员（建议确定性选择：列表第一个）。
-2. 否则，由 **Dominds 运行时**直接执行基线命令（不通过智能体工具）。
-
-基线命令（默认）：
-
-- `uname -a`
-
-`uname -a` 失败时（例如非 POSIX 环境），可以改用平台等价命令；但默认肌肉记忆路径保留 `uname -a`，因为它低风险、快、且信息量刚好够用。
-
-### 2）真实队友诉请：让 shell 专员执行 `uname -a`
-
-若存在 shell 专员，则主线智能体（诉请方）以**工作语言**向 shell 专员（应答方）发起真实诉请，要求：
-
-- 执行 `uname -a`（只执行这一条）
-- 原样返回输出（不要改写/解释）
-- 若命令不可用/失败：返回错误信息，并给出一个安全的替代命令
-
-结果必须以正常对话转录的方式落盘并展示，至少清晰体现：
-
-- 诉请的 headline + body
-- shell 专员实际执行了命令
-- 返回的原始输出
-
-### 3）真实 FBR：基于环境信息做一次“扪心自问”
-
-拿到环境快照后，主线智能体触发一次 `freshBootsReasoning` FBR，并在 FBR 的诉请正文里带上：
-
-- 命令 `uname -a` 的完整输出（明确注明命令名，未来可能更换命令，不能靠猜）
-- FBR 的工具约束（FBR 无工具；主线工具另论）
-- 问题：在这个环境里要注意什么？优先用哪些命令行工具，为什么？
-
-并发草稿（可选）：
-
-- 若团队成员配置启用了 `fbr_effort`（默认值为 `3`），运行时会并发创建多份 `freshBootsReasoning` FBR 支线对话，让“初心自我”从不同角度独立推理，形成多份草稿供主线对话综合提炼。
-- 这些草稿之间**没有稳定身份映射**，也没有必须遵循的先后顺序；主线对话应当把它们当作“多份匿名草稿”，而不是“固定的三个角色”。
-- 若 `fbr_effort` 为 `0`，则跳过 FBR。
-- 若 `fbr_effort` 大于 `100`，运行时会报错并终止启动流程（配置错误）。
-
-阶段边界（关键）：
-
-- `freshBootsReasoning` 只是**发起动作**，不是“已完成决策”。
-- 主线对话必须先进入等待态，直到该次 FBR 的回贴返回。
-- 若 `fbr_effort = N`，主线必须等待全部 N 条回贴后再进入综合提炼；不得基于部分草稿提前定稿。
-
-### 4）综合提炼成“智能体启动（Priming）”笔记
-
-在确认该次 FBR 回贴已收齐后，主线智能体以一次**正常生成**在主线对话里追加一条短笔记（Agent Priming），让关键信息显性化、可检索，并体现“综合提炼”（去重/消冲突/抽取最有用的要点）。
-
-实现约束（与运行时一致）：
-
-- “综合提炼”阶段**不应**通过拼装/拼接一段新的 system prompt 或引入一条独立的 system-prompt 组装路径。
-- 运行时可以使用一条**internal prompt** 来锚定“本次生成就是综合提炼”。internal prompt 必须不落盘、不展示。
-- FBR 草稿与 shell 回传等“证据材料”可以通过 internal prompt 一并提供给模型（仅用于本次 drive 的上下文，不写入对话历史），从而避免依赖“支线回复注入队列”的时序与并发细节。
-- Agent Priming 生命周期（从序幕开始到 priming 笔记产出完成）内，运行时必须禁止注入 diligence-push（鞭策）消息；待 priming 结束后再恢复常规机制。
-
-实现补充（internal prompt）：
-
-- 运行时可以向 driver 提供一个**不落盘/不展示**的 internal prompt（仅用于本次 drive 的 LLM 上下文），用于把本次生成明确锚定为“综合提炼”。
-- internal prompt 不得写入对话历史与持久化存储（避免污染转录与后续 course）。
-- internal prompt 的语义等价于“本次生成要做的任务指令”，而不是替代系统提示或拼装新的 system prompt。
-
-实现补充（避免 Taskdoc 浸染）：
-
-- “综合提炼”应当与具体差遣牒内容解耦：同一个智能体的 Agent Priming 前缀会被用于不同差遣牒的对话。
-- 因此运行时在触发 distillation 的那一次 drive 中可以选择**不注入 Taskdoc**，避免 Taskdoc 的进度/实现细节影响“环境结论”的提炼。
-
----
-
-## 持久化、缓存与复用（仅进程内）
-
-### 1）记录必须“像真的一样”
-
-智能体启动的每一步都必须作为标准对话记录落盘（消息 + 事件），并在 WebUI 中可见：
-
-- 可 debug（日志/存储都有迹可循）
-- 可回放（对话历史导航时不丢信息）
-
-### 2）按智能体维度进程内缓存
-
-为避免每次新对话都重复跑 `uname -a` + FBR + 综合提炼，后端进程维护一个**进程内缓存**（重启失效），按主线智能体 id 做 key。
-
-复用策略：
-
-- 若命中缓存，新对话可直接复用首次的转录与“Agent Priming”笔记，不再重复执行。
-- 复用的记录在新对话里仍应可见，并清楚标记“来自缓存复用”。
-
-### 2.5）主线选择向支线继承（必须）
-
-主线对话在创建时选择的 Priming 选项，必须传递给其所属所有支线对话（Sideline dialog）。
-
-继承语义：
-
-- 主线选“无感”（`skip`）：所有支线都必须“无感”（`skip`）。
-- 主线在“有缓存”前提下选“再做一次”（`do`）：所有支线都必须“再做一次”（`do`）。
-- 主线在“无缓存”前提下选“做给祂看”（`do`，首次体验语义）或选“复用缓存”（`reuse`）：
-  支线统一按“可复用则复用，否则现做”（`reuse`）执行。
-
-说明：
-
-- 不同支线智能体的缓存状态可能不同；`reuse` 的含义是“按该支线智能体自己的缓存判断”。
-- priming 不允许后台悄悄执行；必须以标准对话记录（消息 + 事件）对用户可见。
-
-### 3）跨 `clear_mind` 携带
-
-每次 `clear_mind` 进入下一程时，不要依赖 reminder 来承载这件事。
-
-改为：在每一程对话的上下文里注入一段小而稳定的 **course prefix**（可理解为“历史消息区最开头的几条 msg”），内容是从首次启动中提炼出的压缩转录（shell 快照 + FBR 摘要 + Priming 笔记）。这样智能体能持续保留“体感”和环境约束，而无需重复执行启动流程。
-
----
-
-## WebUI 需求
-
-### 展示
-
-- 智能体启动应以真实对话转录展示，用户可展开查看细节。
-- 建议在对话顶部提供一个可折叠区域，并带上清晰标签：
-  - “队友诉请（shell）”
-  - “FBR（`freshBootsReasoning`）”
-  - “智能体启动（Agent Priming）”
-
-### 创建对话时可选择跳过（opt-out）
-
-创建对话框上提供明确开关，跳过这一安排（不执行启动流程，也不生成启动转录）。
-
-补充约定：
-
-- 当对话主理人选择为（隐藏的）影子智能体时，“智能体启动（Priming）”选项默认应为“无感”。
-- 影子智能体的“启动”选项应与显在智能体的“启动”选项分开记忆（互不影响）。
-
----
-
-## 安全注意事项
-
-- 默认只执行 `uname -a`（低风险、只读、快）。
-- 启动阶段禁止任何会改写文件/网络/系统状态的操作。
-- 由于启动默认用户可见，严禁输出密钥/敏感信息。

package/dist/docs/drive-logic-context-refactor-plan.zh.md

@@ -1,338 +0,0 @@
-# Drive 逻辑上下文拼装现状与重构计划（2026-02）
-
-状态：Draft  
-语义基线：以 `dominds/main/llm/driver.ts` 与 `dominds/main/persistence.ts` 当前实现为准。
-测试基线（2026-02-09 更新）：drive 相关脚本统一通过 `main/llm/driver-entry.ts` 调用，可用 `DOMINDS_DRIVER_ENGINE=v1|v2` 进行引擎切换验证。
-
-## 1. 背景与目标
-
-近期在对话 `@ux (39/12/417f4a49)` 中暴露出一个上下文一致性问题：同一主线对话内已经收到了 `@cmdr/@browser_tester` 的回贴并据此更新 Taskdoc，但后续回复仍声称“没看到原始回贴文本”。
-
-这类问题的根因不是单条提示词，而是 **drive 内多轮生成的上下文来源语义不统一**：有的上下文是持久消息（`dlg.msgs`），有的是一次性注入（仅首轮），还有的是消费队列（take/commit/rollback）。
-
-本文目标：
-
-1. 固化“当前代码结构现状”的可审计视图。
-2. 记录本轮已做的修补。
-3. 制定一次更大范围的 drive logic 重构计划，使后续维护更清晰、不易回归。
-
-## 2. 当前结构（代码现状）
-
-### 2.1 核心文件与职责
-
-- `main/llm/driver.ts`
-  - `_driveDialogStream()`：单次 drive 主循环，负责 prompt 处理、上下文拼装、LLM 调用、工具调用、suspend/continue。
-  - `supplyResponseToSupdialog()`：子对话回贴写入父对话响应队列、更新 pending、触发 auto-revive。
-- `main/persistence.ts`
-  - `takeSubdialogResponses()/commitTakenSubdialogResponses()/rollbackTakenSubdialogResponses()`：子对话回贴队列的“取走-提交/回滚”机制。
-  - `rebuildFromEvents()`：重建 `dlg.msgs`（包含 `teammate_response_record -> tellask_result_msg` 映射）。
-- `main/dialog.ts`
-  - `addChatMessages()`：运行时消息容器（in-memory）。
-
-### 2.2 当前上下文来源（进入 LLM 的入口）
-
-在 `_driveDialogStream()` 中，每轮 gen 的 `ctxMsgs` 由以下部分拼装：
-
-1. `prependedContextMessages`（策略注入）
-2. `memories`
-3. `taskDocMsg`
-4. `coursePrefixMsgs`
-5. `dialogMsgsForContext`（来自 `dlg.msgs`）
-6. `subdialogResponseContextMsgs`（来自 `takeSubdialogResponses` 的注入）
-7. `internalDrivePromptMsg`（internal prompt 注入）
-8. reminders + language guide（末尾插入）
-
-要点：`dlg.msgs` 是“稳定上下文”；队列/内部 prompt 属于“drive 级上下文”。
-
-## 3. 本轮修补（已落地）
-
-### 3.1 已修问题
-
-1. **同一 drive 多轮丢失 teammate response 上下文**
-   - 修复：把 `takeSubdialogResponses` 生成的 `subdialogResponseContextMsgs` 在同一 drive 内跨迭代保留，而非仅 `genIterNo===1` 注入。
-
-2. **中断时误 commit 已 take 队列**
-   - 修复：在 interrupted 分支标记 `generationHadError = true`，确保 finally 走 rollback，不会把未稳定消费的队列当作已消费。
-
-3. **internal prompt 语义收敛为 drive 级 priming**
-   - 修复：移除生命周期分支；`persistMode='internal'` 统一为 drive-scoped priming 注入。
-   - 语义：仅在当前 drive 生效、不入 `dlg.msgs`、不持久化、不渲染 UI。
-   - 依据：当前唯一使用场景是 Agent Priming，且明确要求 loop 迭代中持续可见。
-
-4. **teammate response 稳定化到 `dlg.msgs`（与工具结果语义对齐）**
-   - 修复：当 take/commit 成功后，把该批回贴镜像为 `tellask_result_msg` 写入 `dlg.msgs`，让后续 drive 不依赖一次性队列注入。
-
-5. **队列记录补齐状态字段**
-   - 修复：`subdialog-responses` 记录新增可选 `status`（`completed|failed`），并在镜像消息时使用该状态（默认 `completed`）。
-
-## 4. 仍存在的结构债务
-
-### 4.1 状态语义分散
-
-同一类“队友回贴事实”同时存在于：
-
-- `teammate_response_record`（事件持久层）
-- `subdialog-responses.json`（消费队列）
-- `dlg.msgs`（运行时上下文）
-
-缺少单一“源事实 -> 视图派生”的规范，维护成本高。
-
-### 4.2 拼装流程耦合过深
-
-`_driveDialogStream()` 同时承担：
-
-- prompt 生命周期管理
-- 上下文装配
-- policy 校验
-- 流式/非流式分支
-- 工具调用循环
-- suspend/revive 与队列提交事务
-
-单函数职责过重，不利于做语义回归验证。
-
-### 4.3 缺少针对性回归测试矩阵
-
-现有 tellask 测试覆盖“auto-revive 能跑通”，但对以下关键边界覆盖不足：
-
-- 同一 drive 的多轮迭代上下文一致性
-- interrupted + take queue 的 rollback 语义
-- committed queue 镜像到 `dlg.msgs` 后的去重/恢复语义
-
-## 5. 语义决策记录（本轮确认）
-
-1. `persistMode='internal'` 不是“下一轮临时补丁”，而是 **drive 级 priming 通道**。
-2. 当前无 `next_gen` 真实业务需求，先不保留该分支，避免语义包袱。
-3. 如未来出现单轮内部提示需求，新增能力应基于明确场景和回归测试，不提前抽象。
-
-## 6. Priming 重点支持目标
-
-本次重构把 Agent Priming 作为第一优先级目标，不再作为“顺带兼容”。
-
-### 6.1 Priming 对 drive 的硬需求
-
-1. Priming 使用的临时引导 prompt 只作用于当前 drive。
-2. 在同一 drive 的多轮迭代中（工具调用、context remediation、continue）必须持续可见。
-3. 该 prompt 不进入 `dlg.msgs`，不写事件，不落盘，不渲染 UI。
-4. drive 中断/失败后不得残留到下一次 drive。
-
-### 6.2 Priming 支持实现（简化方案）
-
-核心原则：**不做通用“多生命周期临时 prompt 框架”，只保留 drive 级 priming 通道**。
-
-1. 在新 driver 中把 priming 输入建模为单一字段：`internalDrivePrimingMsg?: ChatMessage`。
-2. 上下文装配时固定规则：每轮迭代都在末尾注入 `internalDrivePrimingMsg`。
-3. 通过 driver 生命周期自然回收：drive 结束即销毁，不做额外状态机。
-4. 仅保留 `persistMode='internal'` 这一种 priming 入口，不再引入 `next_gen`/scope 分叉。
-
-这样可以把 priming 需求落实为“一个字段 + 一条注入规则”，实现面最小化。
-
-## 7. 两阶段重构计划（按新模块重写）
-
-### 阶段 1：新建并上线 `driver-v2`，旧模块原样保留
-
-目标：在新模块里重写 drive 逻辑，旧 `driver.ts` 保持原样，便于并排对比与问题定位。
-
-交付物：
-
-1. 新模块（建议）：
-   - `main/llm/driver-v2/index.ts`（对外入口）
-   - `main/llm/driver-v2/orchestrator.ts`（drive 级编排入口）
-   - `main/llm/driver-v2/types.ts`（v2 内部类型与运行态）
-   - `main/llm/driver-v2/context.ts`（上下文装配，含 priming 注入）
-   - `main/llm/driver-v2/policy.ts`（策略模型骨架）
-   - `main/llm/driver-v2/context-health.ts`（context-health 决策骨架）
-   - `main/llm/driver-v2/subdialog-txn.ts`（take/commit/rollback 事务）
-   - `main/llm/driver-v2/supdialog-response.ts`（subdialog 回贴与 auto-revive 编排）
-   - `main/llm/driver-v2/round.ts`（单轮生成与 side effects）
-   - 当前状态（2026-02-09 最新）：`orchestrator` 已去除 `emitSayingEvents / supplyResponseToSupdialog / runBackendDriver` 的 v1 passthrough；`round` 已接管 lock/dead-check/upNext/subdialog-reply 收尾流程；核心循环已切换到 `driver-v2/core.ts:driveDialogStreamCoreV2`，不再调用 `_driveDialogStream/driveDialogStreamCoreV1`。
-   - 仍保留的过渡 bridge（2026-02-09）：`coreV2` 已把重试、diligence、参数校验、saying-event 处理迁入 `driver-v2/`（`runtime-utils.ts`、`saying-events.ts`）；当前仅 `tellask` 执行链仍通过 `driver-v2/tellask-bridge.ts -> driver.ts` 过渡调用，属于阶段 1 末尾需继续收敛的技术债。
-2. 保持旧模块文件不动：
-   - `main/llm/driver.ts` 继续存在，作为对照基线。
-3. 切换方式：
-   - 通过单点入口切换到 v2（建议配置开关或固定切换点），避免多处散改 import。
-   - 当前状态（2026-02-09）：`main/llm/driver-entry.ts` 已支持 `DOMINDS_DRIVER_ENGINE=v1|v2`（默认 `v2`）。
-4. Priming 专项支持：
-   - v2 内置 `internalDrivePrimingMsg` 注入规则（每轮注入、drive 内有效、绝不持久化）。
-5. 关键回归与复放：
-   - `multi-iter subdialog response`
-   - `interrupt rollback`
-   - `commit mirror to dlg.msgs`
-   - `no duplicate after restore`
-   - `internal drive priming persists across iterations`
-   - 复放 `39/12/417f4a49` 风格样本
-
-阶段 1 验收门槛：
-
-1. `pnpm -C dominds run lint:types` 通过。
-2. tellask 相关回归通过。
-3. priming 专项回归通过。
-4. 对比旧 driver，关键语义一致且已知 bug 被修复。
-
-### 阶段 2：v2 稳定后删除旧模块并清理
-
-目标：确认 v2 可稳定替代后，删除旧逻辑，收敛维护面。
-
-交付物：
-
-1. 删除旧 `driver.ts` 中被 v2 覆盖的实现（或将其瘦身为转发壳并最终移除）。
-2. 清理迁移期开关、对照代码、过渡注释和 dead code。
-3. 固化最终文档：
-   - 新 driver 模块边界
-   - priming 通道语义
-   - 事务边界与错误处理约束
-
-阶段 2 验收门槛：
-
-1. 全量类型检查与回归通过。
-2. 无旧模块引用残留（import/调用链清零）。
-3. 行为与阶段 1 上线结果一致。
-
-## 8. 目标接口草案（v2，简化版）
-
-```ts
-type DriveV2Input = {
-  persistedPrompt?: HumanPrompt; // 常规用户输入（会持久化）
-  internalDrivePrimingMsg?: ChatMessage; // 仅 drive 内可见
-  skipTaskdoc?: boolean;
-};
-
-type DriveV2Runtime = {
-  takenSubdialogResponses: TakenSubdialogResponse[];
-  generationAttempted: boolean;
-};
-```
-
-说明：
-
-1. priming 只保留 `internalDrivePrimingMsg` 一条路径。
-2. 不提供“下一轮临时注入”接口，避免再次引入语义分叉。
-3. 所有持久化副作用统一在编排层执行，不放进上下文纯函数。
-
-## 9. 重构约束（必须保持）
-
-1. 不改变现有 wire 协议事件名与基础语义（除非显式版本升级）。
-2. 不引入 silent fallback；上下文事务异常需 loud 日志与可见错误信号。
-3. 保持 TypeScript strict 与可静态验证属性；禁止 `any`。
-4. 旧模块在阶段 1 必须原样保留，便于对照和回滚。
-
-## 10. 现有测试合理性评估（针对 dlg drive）
-
-结论（2026-02-09 更新）：**覆盖面已明显提升，足以支撑阶段 1 的持续迁移；但仍有未完成的对照/复放用例，尚未达到“可删除旧模块”的阶段 2 门槛**。
-
-### 10.1 现有测试的合理性（优点）
-
-1. 以脚本方式在临时 rtws 跑通关键链路，具备真实文件系统与持久化路径，能抓到不少“运行态”问题。
-2. 已覆盖部分核心行为：
-   - tellask 解析/流式解析稳定性
-   - root auto-revive 基础路径
-   - type B 注册去重基础路径
-   - diligence push/Q4H 的部分事件行为
-3. 执行成本低，适合快速 smoke。
-
-### 10.2 仍存关键缺口（阶段 2 前需补齐）
-
-1. `v1-v2-parity-diligence-q4h.ts` 仍未实现（当前只有 switch-smoke 级别验证，不是逐断言 parity）。
-2. `replay-39-12-417f4a49-style.ts` 仍未实现（尚未形成稳定复放门禁）。
-3. 旧模块仍保留；v2 已激活入口与外围编排，且核心生成循环已独立到 `coreV2`，但仍存在 bridge 依赖（tellask/重试/diligence 等辅助函数），尚未进入“删除旧模块”收敛阶段。
-
-## 11. v2 测试设计与上线门禁
-
-### 11.1 分层策略
-
-1. L0 单元层（纯逻辑，零 I/O）
-   - 目标：验证 v2 新模块内部规则和数据变换。
-   - 关注：context 装配顺序、priming 注入规则、txn 状态机。
-2. L1 集成层（临时 rtws + mock provider）
-   - 目标：验证 drive 主链路和持久化副作用。
-   - 关注：take/commit/rollback、auto-revive、runState、event 语义。
-3. L2 对照/复放层（v1 vs v2）
-   - 目标：验证重写后与既有正确语义一致，且已知 bug 被修复。
-   - 关注：同输入下关键输出等价、上下文可见性不回退。
-
-### 11.2 v2 必做用例（最小集）
-
-1. `driver-v2/context-assembly-order.ts`
-   - 断言：`base -> ephemeral -> tail` 装配顺序稳定，且 reminders/language guide 插入点与现有语义一致。
-   - v1 状态：可跑；已实现并通过（2026-02-09）。
-2. `driver-v2/internal-drive-priming-multi-iter.ts`
-   - 断言：priming 提示在同一 drive 第 1/2/3 轮均可见。
-   - v1 状态：可跑；已实现并通过（2026-02-09）。
-3. `driver-v2/internal-drive-priming-not-persisted.ts`
-   - 断言：priming 不进入 `dlg.msgs`、不写 events、不落盘。
-   - v1 状态：可跑；已实现并通过（2026-02-09）。
-4. `driver-v2/internal-drive-priming-no-leak-next-drive.ts`
-   - 断言：drive 结束后 priming 不泄漏到下一次 drive。
-   - v1 状态：可跑；已实现并通过（2026-02-09）。
-5. `driver-v2/subdialog-queue-interrupt-rollback.ts`
-   - 断言：take 后 interrupted/error 必 rollback，下一次 drive 可重见。
-   - v1 状态：可跑；已实现并通过（2026-02-09）。
-6. `driver-v2/subdialog-queue-commit-mirror.ts`
-   - 断言：成功 commit 后镜像到 `dlg.msgs`，后续不依赖队列注入。
-   - v1 状态：可跑；已实现并通过（2026-02-09）。
-7. `driver-v2/subdialog-restore-live-equivalence.ts`
-   - 断言：restore 路径与 live 路径对 teammate response 的上下文等价。
-   - v1 状态：可跑；已实现并通过（2026-02-09）。`restoreDialogHierarchy(rootId, status)` 需由调用方显式传入状态。
-8. `driver-v2/multi-iter-tool-round-context-continuity.ts`
-   - 断言：工具回合 continue 后，前序关键上下文不丢失。
-   - v1 状态：可跑；已实现并通过（2026-02-09）。
-9. `driver-v2/v1-v2-parity-basic-tellask.ts`
-   - 断言：同 mock 输入下，v1/v2 在可观察语义上等价（除已知 bug 修复差异）。
-   - v1 状态：可跑；已实现并通过（2026-02-09）。
-10. `driver-v2/v1-v2-parity-diligence-q4h.ts`
-    - 断言：diligence/Q4H 关键事件与 runState 语义一致。
-    - v1 状态：尚未实现专门 parity 用例；但已通过 `driver-v2:switch-smoke:engine-v1|v2` 覆盖该链路的切换可用性验证（2026-02-09）。
-
-11. `driver-v2/replay-39-12-417f4a49-style.ts`
-    - 断言：复放样本不再出现“已收到回贴却声称没看到”的语义回归。
-    - v1 状态：可先做“现状复放”脚本；v2 需要转为门禁回归。当前未实现。
-
-### 11.3 阶段 1/2 的测试门禁
-
-阶段 1（v2 上线前）必须通过：
-
-1. `lint:types`
-2. 全部 L0 用例
-3. 全部 L1 最小集（上面 1~7）
-4. 至少 2 个 L2 对照用例（上面 8~9）
-5. priming 专项 3 条（上面 1~3）全部通过
-
-阶段 2（删除旧模块前）必须通过：
-
-1. 阶段 1 全部门禁
-2. 全部 L2 用例（含复放样本）
-3. old-driver 引用清零后再跑一次全套，确保无隐性依赖
-
-### 11.4 执行组织建议
-
-在 `tests/package.json` 里新增独立脚本分组（阶段 1 即可开始）：
-
-1. `driver-v2:unit`
-2. `driver-v2:integration`
-3. `driver-v2:parity`
-4. `driver-v2:replay`
-5. `driver-v2:gate`（汇总门禁脚本）
-
-目的：把“能跑”与“可上线”分开，避免只凭单条 smoke 测试判断重写完成。
-
-当前已落地脚本（2026-02-09）：
-
-1. `driver-v2:integration:engine-v1`
-2. `driver-v2:integration:engine-v2`
-3. `driver-v2:switch-smoke:engine-v1`
-4. `driver-v2:switch-smoke:engine-v2`
-5. `driver-v2:parity`
-
-### 11.5 测试基座约定（script-rtws + mock provider）
-
-1. 阶段 1 的集成测试默认基于 `tests/script-rtws` 运行，避免污染真实 rtws。
-   - 执行约束：统一通过 `tests/cli.ts` 入口传 `-C script-rtws`；不允许其它 rtws。
-   - 并发约束：同一时刻只允许一个 `tests/cli.ts` 进程使用 `script-rtws`，禁止并发执行多个脚本（会互相污染快照与恢复过程）。
-   - 运行收尾：`tests/cli.ts` 默认会在脚本结束后将 `tests/script-rtws` 恢复到“测试前快照”（可通过 `DOMINDS_TEST_RTWS_RESTORE_MODE=head` 改为恢复到 git HEAD；`DOMINDS_TEST_RTWS_RESTORE=0` 可禁用自动恢复用于调试）。
-2. 默认使用 `apiType: mock`，通过 `mock-db/<model>.yaml` 驱动可重复测试。
-   - driver 入口切换统一走 `main/llm/driver-entry.ts`，通过环境变量 `DOMINDS_DRIVER_ENGINE=v1|v2` 选择引擎；测试代码避免直接调用 `driveDialogStream` 的 v1 直连入口。
-3. mock 响应可使用：
-   - `delayMs`：整次响应前延迟（用于中断/rollback窗口）
-   - `chunkDelayMs`：流式分块延迟（用于流顺序与 stop 时序）
-   - `funcCalls`：响应后追加函数调用序列（用于工具回合/continue 测试）
-   - `contextContains`：要求上下文中必须包含指定片段（用于上下文连续性断言）
-4. 需要“慢速请求”场景时，优先在 mock 数据层配置，不依赖真实外部 provider。