TUI 交互和渲染测试

fn test_path_display(path: &str) -> String

作用：把一个测试用的路径字符串变成适合显示的路径文本。有人写测试时如果需要比较“界面上显示出来的路径”，就可以用它生成稳定的结果。

数据流：输入是一个普通路径字符串 → 它交给 test_path_buf 生成测试专用的路径对象，再调用 display 把路径转成可打印的样子 → 输出是一个 String，也就是最终用于断言或展示的路径文字；它不改动外部状态。

调用关系：它是测试代码里的小助手，自己不做复杂判断，而是把核心工作交给外部的 test_path_buf。测试需要检查路径显示时会调用它，用来避免每个测试都重复写同样的路径转换步骤。

调用图：外部调用 1 个（test_path_buf）。

fn session_source_cli() -> T

作用：生成一个表示“会话来自命令行”的测试值。测试里需要模拟用户从 CLI，也就是命令行入口启动会话时，会用到它。

数据流：没有普通参数，但它知道要使用协议里的 SessionSource::Cli → 它把这个值交给 from_app_server_wire，先按 app-server 的传输格式转成 JSON 值，再转回测试需要的目标类型 T → 输出是调用者指定的类型；如果转换失败，测试会直接报错。

调用关系：它是更具体的一层包装，专门表示命令行会话来源。调用图里它会被 test_session_telemetry 这类测试使用，而真正的格式转换工作交给 from_app_server_wire。

调用图：调用 1 个内部函数（from_app_server_wire）；被 2 处调用（test_session_telemetry, test_session_telemetry）。

fn skill_scope_user() -> T

作用：生成一个表示“技能作用在用户范围”的测试值。这里的技能范围可以理解为某个功能或配置是跟着用户走，而不是只属于某个代码仓库。

数据流：没有普通参数，但它固定拿协议里的 SkillScope::User → 交给 from_app_server_wire 做一次“协议值到测试目标类型”的转换 → 输出是调用者想要的类型 T；转换不成功就让测试失败。

调用关系：它是测试里表达“用户级技能范围”的便捷入口。它不自己处理序列化细节，而是把活儿交给 from_app_server_wire，保证和其他类似测试值走同一套转换规则。

调用图：调用 1 个内部函数（from_app_server_wire）。

fn skill_scope_repo() -> T

作用：生成一个表示“技能作用在仓库范围”的测试值。也就是说，这个测试值代表某个技能或设置只跟当前项目代码仓库有关。

数据流：没有普通参数，但它固定使用协议里的 SkillScope::Repo → 调用 from_app_server_wire，把协议层的表示转换成测试需要的类型 T → 返回转换后的值；如果两边格式对不上，就 panic，让测试立刻失败。

调用关系：它是测试里表达“仓库级技能范围”的便捷入口。和 skill_scope_user 一样，它只负责选对原始协议值，真正的转换统一交给 from_app_server_wire。

调用图：调用 1 个内部函数（from_app_server_wire）。

fn from_app_server_wire(value: impl Serialize) -> T

作用：把 app-server 协议里的某个值，转换成测试里旧辅助代码想要的类型。它的作用像一个“转接头”，让新协议值和旧测试类型能接上。

数据流：输入是一个可以被序列化的值，也就是能变成 JSON 的值 → 它先用 serde_json::to_value 转成 JSON 中间格式，再用 serde_json::from_value 转成调用者指定的类型 T → 输出是转换后的 T；如果任一步失败，它会让测试 panic，并说明协议值没有成功映射到旧 helper 类型。

调用关系：它是 session_source_cli、skill_scope_user 和 skill_scope_repo 背后的公共转换工具。上层函数负责挑选具体的协议值，它负责统一走 JSON 转换流程，这样测试能顺便检查 app-server 传输格式和旧测试类型是否仍然兼容。

调用图：被 3 处调用（session_source_cli, skill_scope_repo, skill_scope_user）；外部调用 1 个（to_value）。

fn new(width: u16, height: u16) -> Self

作用：创建一个指定宽高的假终端，供测试把界面画进去。它还强制打开彩色输出，让测试里的颜色表现更接近真实终端。

数据流：输入宽度和高度 → 打开彩色输出开关，并用这些尺寸创建一个 vt100 终端模拟器，再把它交给 CrosstermBackend → 返回一个可被 ratatui 当作终端后台使用的 VT100Backend。

调用关系：很多界面快照测试一开始都会调用它来搭建测试舞台。后续渲染、清屏、移动光标等操作都会通过这个对象转给内部的 CrosstermBackend 和 vt100 模拟器。

调用图：被 61 处调用（thread_goal_ephemeral_error_message_renders_snapshot, render_footer_with_mode_indicator_and_context, chained_config_error_wraps_in_history_snapshot, approval_modal_exec_multiline_prefix_hides_execpolicy_option_snapshot, approval_modal_exec_snapshot, approval_modal_exec_without_reason_snapshot, approval_modal_patch_snapshot, app_server_guardian_review_denied_renders_denied_request_snapshot, app_server_guardian_review_timed_out_renders_timed_out_request_snapshot, guardian_approved_exec_renders_approved_request (+15 more)）；外部调用 3 个（new, force_color_output, new）。

fn vt100(&self) -> &vt100::Parser

作用：拿到内部的 vt100 终端模拟器，方便读取当前屏幕内容、光标位置和终端大小。它只给只读引用，避免外部随便改坏模拟器状态。

数据流：输入是当前 VT100Backend 本身 → 从内部 CrosstermBackend 里取出它正在写入的 vt100::Parser → 返回这个模拟器的只读视图。

调用关系：它是查询类方法的入口。get_cursor_position、size 和 window_size 都会通过它读取假终端里的状态，而不是去问真实系统终端。

调用图：被 3 处调用（get_cursor_position, size, window_size）；外部调用 1 个（writer）。

fn write(&mut self, buf: &[u8]) -> io::Result<usize>

作用：把一段原始字节写进假终端。终端控制序列、文字、颜色指令等都会先作为字节流进入这里。

数据流：输入一段字节 buf → 找到内部 vt100 模拟器的可写入口，把字节写进去 → 返回写入了多少字节，或者返回写入错误。

调用关系：这是实现标准写入接口的一部分。上层终端库需要输出内容时，可以像写真实终端一样写到这里，但实际接收者是内存里的 vt100 模拟器。

调用图：外部调用 1 个（writer_mut）。

fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result

作用：把当前假终端屏幕转换成普通字符串，方便调试或做快照对比。简单说，就是把“屏幕上现在长什么样”打印出来。

数据流：输入是格式化器和当前 VT100Backend → 从 vt100 模拟器里取当前屏幕内容 → 写入格式化器，最终变成可显示的文本。

调用关系：当测试或调试代码需要把后端直接转成文本时会用到它。它不重新渲染界面，只是读取已经被 vt100 模拟器记录下来的屏幕内容。

调用图：外部调用 1 个（write!）。

fn draw(&mut self, content: I) -> io::Result<()>

作用：把 ratatui 准备好的一个个单元格画到假终端上。单元格可以理解成终端屏幕上的一个字符格子，里面有字符和样式。

数据流：输入一串带坐标的 Cell → 交给内部 CrosstermBackend 按照正常终端绘制方式输出 → 输出结果进入 vt100 模拟器，函数返回成功或错误。

调用关系：这是界面渲染的核心通道。测试里的界面组件调用 ratatui 绘制时，最终会走到这里，再由内部 CrosstermBackend 完成实际的终端指令生成。

调用图：外部调用 1 个（draw）。

fn hide_cursor(&mut self) -> io::Result<()>

作用：隐藏假终端里的光标。这样测试出来的画面不会因为光标显示而多出不稳定的内容。

数据流：没有额外输入 → 把“隐藏光标”的请求转给内部 CrosstermBackend → vt100 模拟器记录这个终端状态变化，函数返回成功或错误。

调用关系：界面绘制流程中需要控制光标显示时会调用它。它只是转交给内部后端，不直接碰真实终端。

调用图：外部调用 1 个（hide_cursor）。

fn show_cursor(&mut self) -> io::Result<()>

作用：让假终端里的光标重新显示。通常在界面绘制结束或需要用户输入位置可见时使用。

数据流：没有额外输入 → 把“显示光标”的请求交给内部 CrosstermBackend → vt100 模拟器更新状态，函数返回成功或错误。

调用关系：它和 hide_cursor 是一对。上层 ratatui 流程决定什么时候显示光标，这里负责把这个动作安全地落到假终端里。

调用图：外部调用 1 个（show_cursor）。

fn get_cursor_position(&mut self) -> io::Result<Position>

作用：读取当前光标在假终端里的位置。它不会询问真实终端，所以测试结果不受本机控制台影响。

数据流：输入是当前后端 → 通过 VT100Backend::vt100 取得模拟器，再读取模拟屏幕中的光标坐标 → 返回 ratatui 使用的 Position。

调用关系：这是 Backend 接口要求提供的查询方法。它调用 VT100Backend::vt100，从内存模拟器取数据，避免走 crossterm 那些可能直接访问 stdout 的真实终端查询。

调用图：调用 1 个内部函数（vt100）。

fn set_cursor_position(&mut self, position: P) -> io::Result<()>

作用：把光标移动到指定位置。界面库需要在某个格子继续写字时，会用这个能力。

数据流：输入一个可转换成 Position 的位置 → 转交给内部 CrosstermBackend 生成移动光标的终端操作 → vt100 模拟器接收并更新光标位置，返回成功或错误。

调用关系：它属于绘制过程中的基础动作。上层代码只按 Backend 接口调用，VT100Backend 再把动作交给内部 CrosstermBackend。

调用图：外部调用 1 个（set_cursor_position）。

fn clear(&mut self) -> io::Result<()>

作用：清空整个假终端屏幕。测试开始新一帧或重画界面时，经常需要先把旧内容擦掉。

数据流：没有额外输入 → 调用内部 CrosstermBackend 的清屏能力 → vt100 模拟器里的屏幕内容被清掉，返回成功或错误。

调用关系：它让测试后端表现得像真实终端。界面库发起清屏时走到这里，具体清屏指令仍由内部 CrosstermBackend 处理。

调用图：外部调用 1 个（clear）。

fn clear_region(&mut self, clear_type: ClearType) -> io::Result<()>

作用：清掉屏幕上的某一类区域，比如当前行、光标之后等。它比整屏清空更精细。

数据流：输入 ClearType，也就是要清理哪种范围的说明 → 交给内部 CrosstermBackend → vt100 模拟器按这个范围更新屏幕内容，返回成功或错误。

调用关系：当界面库只想擦掉局部内容时会调用它。VT100Backend 不自己解释所有清理规则，而是让内部 CrosstermBackend 执行。

调用图：外部调用 1 个（clear_region）。

fn append_lines(&mut self, line_count: u16) -> io::Result<()>

作用：在终端底部追加若干空行，模拟真实终端滚动或扩展输出的效果。

数据流：输入要追加的行数 → 转给内部 CrosstermBackend → vt100 模拟器根据终端行为更新屏幕，返回成功或错误。

调用关系：它是 Backend 接口的一部分，主要服务于需要新增行内容的绘制场景。这个文件只负责把请求接到假终端上。

调用图：外部调用 1 个（append_lines）。

fn size(&self) -> io::Result<Size>

作用：返回假终端当前的列数和行数。测试用的是创建时设定的尺寸，而不是机器上真实窗口的尺寸。

数据流：输入是当前后端 → 通过 VT100Backend::vt100 读取模拟屏幕的 rows 和 cols → 转成 ratatui 的 Size，其中宽度是列数，高度是行数，然后返回。

调用关系：界面布局计算时会问后端屏幕有多大，这个方法就提供稳定答案。它依赖 VT100Backend::vt100，而不是调用真实终端尺寸查询。

调用图：调用 1 个内部函数（vt100）；外部调用 1 个（new）。

fn window_size(&mut self) -> io::Result<WindowSize>

作用：返回窗口大小信息，包括字符格子的列行数和一个固定的像素大小。测试主要关心列和行，像素大小只是占位。

数据流：输入是当前后端 → 从 vt100 模拟器读取字符尺寸 → 组合成 WindowSize，并填入固定的 640×480 像素值 → 返回这个窗口大小对象。

调用关系：这是 Backend 接口需要的窗口查询方法。它通过 VT100Backend::vt100 取模拟终端的大小，避免接触真实窗口；像素值在测试中不依赖，所以给了一个固定值。

调用图：调用 1 个内部函数（vt100）。

fn flush(&mut self) -> io::Result<()>

作用：把内部写入缓冲里的内容冲刷到 vt100 模拟器里。可以把它理解成“别先攒着了，现在就写进去”。

数据流：没有额外输入 → 取得内部 writer 的可写引用并调用 flush → 确保等待中的输出被提交，返回成功或错误。

调用关系：当终端库或上层绘制流程要求刷新输出时会调用它。它把刷新动作转给内部的 vt100 写入器，而不是刷新真实 stdout。

调用图：外部调用 1 个（writer_mut）。

fn scroll_region_up(&mut self, region: std::ops::Range<u16>, scroll_by: u16) -> io::Result<()>

作用：让屏幕上的某一段区域向上滚动指定行数。比如列表内容往上挪时，会需要这种终端能力。

数据流：输入一个行范围 region 和滚动行数 scroll_by → 交给内部 CrosstermBackend → vt100 模拟器更新该范围内的屏幕内容，返回成功或错误。

调用关系：它是局部滚动操作的转接点。上层界面代码通过 Backend 接口提出滚动需求，这里交给内部后端生成和执行对应终端行为。

调用图：外部调用 1 个（scroll_region_up）。

fn scroll_region_down(
        &mut self,
        region: std::ops::Range<u16>,
        scroll_by: u16,
    ) -> io::Result<()>

作用：让屏幕上的某一段区域向下滚动指定行数。它和向上滚动相反，用来模拟真实终端里的局部下移。

数据流：输入一个行范围 region 和滚动行数 scroll_by → 转给内部 CrosstermBackend → vt100 模拟器按要求移动该区域内容，返回成功或错误。

调用关系：它补齐了 Backend 接口里的向下滚动能力。需要测试界面滚动效果时，上层调用会到这里，再由内部 CrosstermBackend 和 vt100 模拟器完成实际状态变化。

调用图：外部调用 1 个（scroll_region_down）。

fn chatwidget_snapshot_dir() -> PathBuf

作用：找到 ChatWidget 快照测试文件所在的文件夹。测试做界面对比时会用它来确定“标准答案照片”放在哪里。

数据流：它不需要外部传入参数。进去的是源码里写死的一个快照文件路径；它调用资源查找工具确认这个快照文件存在，然后取这个文件的父目录。出来的是一个 PathBuf，也就是快照目录路径；如果找不到文件，或者文件没有父目录，测试会直接失败并给出明确报错。

调用关系：它主要服务于本文件里的 assert_chatwidget_snapshot 测试宏。测试要比较界面快照时，宏会先调用这个函数拿到快照目录，再交给 insta 这个快照测试库去读取或匹配对应快照。它内部把查找资源的工作交给 find_resource!。

调用图：外部调用 1 个（find_resource!）。

fn next_goal_draft(
    rx: &mut tokio::sync::mpsc::UnboundedReceiver<AppEvent>,
    expected_thread_id: ThreadId,
) -> crate::goal_files::GoalDraft

作用：从测试用的事件队列里取出下一条“设置线程目标草稿”的事件，并返回里面的草稿内容。它用来确认 ChatWidget 是否真的发出了预期的目标草稿更新。

数据流：输入是一条测试事件接收队列 rx，以及期望的线程编号 expected_thread_id。函数会不断从队列里尝试取事件；如果取到的是 SetThreadGoalDraft，就检查事件里的线程编号必须等于期望编号，然后把 draft 草稿返回。它会消耗队列中的事件；如果队列里没有可取事件，测试会失败。

调用关系：它是测试里的小助手，通常在某个操作触发 ChatWidget 发事件之后使用。测试代码先模拟用户操作或服务器消息，ChatWidget 把事件发到队列里，然后这个函数从队列中捞出目标草稿事件，并用 assert_eq! 做基本校验。它读取队列的具体动作交给 try_recv。

调用图：外部调用 2 个（try_recv, assert_eq!）。

async fn test_config() -> Config

作用：创建一份干净的测试配置。它会用临时目录代替真实用户目录，避免测试被本机配置影响。

数据流：进去没有业务输入 → 它新建临时目录，加载默认配置，再把工作目录、日志目录、数据库目录等都改到测试专用位置 → 出来一份可安全用于测试的 Config。

调用关系：make_chatwidget_manual_with_auth 在搭建测试版 ChatWidget 时会先调用它，保证后面的聊天窗口跑在隔离环境里。

调用图：被 1 处调用（make_chatwidget_manual_with_auth）；外部调用 5 个（from, new, load_default_with_cli_overrides_for_codex_home, default, new）。

fn test_project_path() -> PathBuf

作用：返回测试里统一使用的项目路径。这样测试不用到处硬编码同一个路径。

数据流：进去没有输入 → 它把测试用的 /tmp/project 按当前系统格式转成 PathBuf → 出来一个路径对象。

调用关系：它是路径小工具，供需要项目路径的测试直接拿来用。

调用图：外部调用 1 个（from）。

fn truncated_path_variants(path: &str) -> Vec<String>

作用：把一个路径拆成从短到长的前缀列表。它主要用于处理被界面截断显示的路径。

数据流：进去一个路径字符串 → 它按字符逐步截取前 1 个、前 2 个直到倒数前一个字符 → 出来一组路径前缀字符串。

调用关系：normalize_snapshot_paths 会用它来替换带省略号的 Windows 或其他平台路径，让快照测试稳定。

调用图：被 1 处调用（normalize_snapshot_paths）。

fn normalize_snapshot_paths(text: impl Into<String>) -> String

作用：把测试输出里的平台路径统一成类 Unix 的 /tmp/project 形式。这样同一份快照在不同操作系统上都能通过。

数据流：进去一段文本 → 它查找测试路径和 hooks 文件路径的系统写法，并替换成固定写法；遇到被截断的路径也会对应替换 → 出来一段路径已标准化的文本。

调用关系：normalized_backend_snapshot 和很多快照断言会依赖这种统一结果，避免 Windows 反斜杠之类差异导致测试误失败。

调用图：调用 1 个内部函数（truncated_path_variants）；外部调用 3 个（into, replace, format!）。

fn normalized_backend_snapshot(value: &T) -> String

作用：把后端渲染出来的内容转成适合快照比较的文本。它会特别保留带引号行的宽度。

数据流：进去一个能显示成字符串的值 → 它先格式化成文本，再按行标准化路径；如果一整行被引号包住，就在替换后补齐原来的显示宽度 → 出来稳定的快照字符串。

调用关系：它调用 normalize_snapshot_paths 做核心路径替换，是后端显示内容进入快照测试前的清洗步骤。

调用图：外部调用 1 个（format!）。

fn invalid_value(
    candidate: impl Into<String>,
    allowed: impl Into<String>,
) -> ConstraintError

作用：快速造一个“配置值不合法”的错误对象。测试可以用它模拟约束检查失败。

数据流：进去候选值和允许值说明 → 它把它们装进 ConstraintError::InvalidValue，并填上默认字段名和来源 → 出来一个错误对象。

调用关系：它是测试造假错误的便捷函数，不需要真的跑完整配置校验流程。

调用图：外部调用 1 个（into）。

fn snapshot(percent: f64) -> RateLimitSnapshot

作用：快速造一个限流快照。限流就是系统限制使用频率，这里只关心使用百分比。

数据流：进去一个百分比数字 → 它四舍五入成整数，放进一小时窗口的 RateLimitSnapshot → 出来一个可传给界面的限流状态。

调用关系：测试聊天界面显示配额或限流提示时，可以直接用它准备输入数据。

fn test_session_telemetry(config: &Config, model: &str) -> SessionTelemetry

作用：创建测试用的会话遥测信息。遥测就是记录这次会话用的模型、来源等元数据。

数据流：进去配置和模型名 → 它离线构造模型信息，再创建带测试来源、无账号信息的 SessionTelemetry → 出来一个会话记录对象。

调用关系：make_chatwidget_manual_with_auth 创建 ChatWidget 时会调用它，让组件内部需要的会话信息齐全。

调用图：调用 3 个内部函数（new, new, session_source_cli）；被 1 处调用（make_chatwidget_manual_with_auth）；外部调用 1 个（to_models_manager_config）。

fn test_model_catalog(_config: &Config) -> Arc<ModelCatalog>

作用：创建测试用的模型目录。模型目录就是可选模型的清单。

数据流：进去配置但实际不读取它 → 它拿测试预设模型创建 ModelCatalog，并放进 Arc（可共享引用）里 → 出来一个可共享的模型目录。

调用关系：make_chatwidget_manual_with_auth 和 set_chatgpt_auth 会用它给聊天窗口提供模型列表。

调用图：调用 1 个内部函数（new）；被 2 处调用（make_chatwidget_manual_with_auth, set_chatgpt_auth）；外部调用 1 个（new）。

async fn make_chatwidget_manual(
    model_override: Option<&str>,
) -> (
    ChatWidget,
    tokio::sync::mpsc::UnboundedReceiver<AppEvent>,
    tokio::sync::mpsc::UnboundedReceiver<Op>,
)

作用：用默认未登录状态创建一个可手动驱动的测试聊天窗口。测试可以拿到窗口本体和它发出的事件通道。

数据流：进去可选模型名 → 它转交给 make_chatwidget_manual_with_auth，并固定账号状态为未登录 → 出来 ChatWidget、应用事件接收器和操作接收器。

调用关系：很多测试从这里开始搭建场景；它把真正的初始化细节交给 make_chatwidget_manual_with_auth。

调用图：调用 1 个内部函数（make_chatwidget_manual_with_auth）；被 3 处调用（assert_hook_events_snapshot, assert_shift_left_edits_most_recent_queued_message_for_terminal, make_chatwidget_manual_with_sender）。

async fn make_chatwidget_manual_with_auth(
    model_override: Option<&str>,
    has_chatgpt_account: bool,
    has_codex_backend_auth: bool,
) -> (
    ChatWidget,
    tokio::sync::mpsc::UnboundedRec

作用：创建一个可控制登录状态的测试 ChatWidget。这是本文件最核心的搭建函数之一。

数据流：进去模型覆盖值、是否有 ChatGPT 账号、是否有后端认证 → 它创建事件通道、测试配置、模型目录、遥测信息和初始化参数，再生成 ChatWidget 并调整占位文字等测试状态 → 出来窗口和两个接收队列。

调用关系：make_chatwidget_manual 调用它；后续测试通过返回的接收器检查 ChatWidget 有没有发出用户提交、打断等操作。

调用图：调用 6 个内部函数（new, new, test_config, test_model_catalog, test_session_telemetry, test_dummy）；被 1 处调用（make_chatwidget_manual）；外部调用 4 个（new, new, new_with_op_target, Direct）。

fn next_submit_op(op_rx: &mut tokio::sync::mpsc::UnboundedReceiver<Op>) -> Op

作用：从操作队列里取出下一条“用户提交消息”的操作。它会跳过其他无关操作。

数据流：进去一个操作接收队列 → 它反复尝试读取，遇到 UserTurn 就返回；如果队列空了或关闭就直接让测试失败 → 出来一条提交操作。

调用关系：测试在模拟用户发送后会用它确认聊天窗口真的发出了提交请求。

调用图：外部调用 2 个（try_recv, panic!）。

fn next_interrupt_op(op_rx: &mut tokio::sync::mpsc::UnboundedReceiver<Op>)

作用：确认操作队列里出现了“打断当前任务”的操作。它不返回内容，只检查这件事发生了。

数据流：进去一个操作接收队列 → 它逐条读取并跳过无关操作，直到看到 Interrupt；如果没有就让测试失败 → 出来没有值，但完成时表示断言通过。

调用关系：测试按下中断键或触发停止流程后，会用它验证 ChatWidget 发出了正确指令。

调用图：外部调用 2 个（try_recv, panic!）。

fn assert_no_submit_op(op_rx: &mut tokio::sync::mpsc::UnboundedReceiver<Op>)

作用：检查队列里没有用户提交操作。用于确认某些按键或状态不应该真的发消息。

数据流：进去一个操作接收队列 → 它把当前队列里能读到的操作都看一遍，只要发现 UserTurn 就断言失败 → 出来没有值，成功代表没有误提交。

调用关系：它常用于负向测试，比如输入还不完整、任务正在限制发送时。

调用图：外部调用 2 个（try_recv, assert!）。

fn set_chatgpt_auth(chat: &mut ChatWidget)

作用：把测试聊天窗口改成“已经有 ChatGPT 账号和后端认证”的状态。

数据流：进去一个可修改的 ChatWidget → 它把两个认证标记设为 true，并刷新测试模型目录 → 出来同一个窗口，但认证状态已变化。

调用关系：需要测试登录后功能时会调用它；它内部复用 test_model_catalog。

调用图：调用 1 个内部函数（test_model_catalog）。

fn test_model_info(slug: &str, priority: i32, supports_fast_mode: bool) -> ModelInfo

作用：造一条测试模型的详细信息。可以指定模型名、排序优先级，以及是否支持快速模式。

数据流：进去模型 slug、优先级、是否支持 fast mode → 它拼出一份 JSON，再反序列化成 ModelInfo → 出来一条完整模型信息。

调用关系：set_fast_mode_test_catalog 用它构造包含快慢模式差异的模型列表。

调用图：外部调用 3 个（new, json!, from_value）。

fn set_fast_mode_test_catalog(chat: &mut ChatWidget)

作用：给聊天窗口换上一份专门测试“快速模式”的模型目录。

数据流：进去一个可修改的 ChatWidget → 它创建两个测试模型，其中一个支持 fast 服务档位，一个不支持 → 出来同一个窗口，但模型目录已替换。

调用关系：测试模型切换或快速模式显示时会调用它；它依赖 test_model_info 造模型数据。

调用图：调用 1 个内部函数（new）；外部调用 2 个（new, vec!）。

async fn make_chatwidget_manual_with_sender() -> (
    ChatWidget,
    AppEventSender,
    tokio::sync::mpsc::UnboundedReceiver<AppEvent>,
    tokio::sync::mpsc::UnboundedReceiver<Op>,
)

作用：创建测试聊天窗口，同时额外返回它的事件发送器。这样测试既能看事件，也能主动发事件。

数据流：进去没有输入 → 它先用 make_chatwidget_manual 创建窗口，再从窗口里克隆 AppEventSender → 出来窗口、发送器、事件接收器和操作接收器。

调用关系：当测试需要模拟外部组件向 ChatWidget 发应用事件时，会用这个版本。

调用图：调用 1 个内部函数（make_chatwidget_manual）。

fn drain_insert_history(
    rx: &mut tokio::sync::mpsc::UnboundedReceiver<AppEvent>,
) -> Vec<Vec<ratatui::text::Line<'static>>>

作用：从应用事件队列里取出所有“插入历史单元”的事件，并转成可读的文本行。

数据流：进去应用事件接收队列 → 它不断读取现有事件，只保留 InsertHistoryCell，把每个单元按 80 宽度渲染成行，必要时补空行 → 出来多组显示行。

调用关系：assert_hook_events_snapshot 用它检查钩子完成后写入聊天历史的内容。

调用图：被 1 处调用（assert_hook_events_snapshot）；外部调用 2 个（try_recv, new）。

fn lines_to_single_string(lines: &[ratatui::text::Line<'static>]) -> String

作用：把终端界面的多行富文本压成普通字符串。富文本里的样式会被丢掉，只保留可见文字。

数据流：进去一组 Line，每行里有多个 Span → 它逐个拼接 span 的文字，并在每行后加换行 → 出来一个普通字符串。

调用关系：active_blob 和 active_hook_blob 用它把界面单元转换成快照好比较的文本。

调用图：被 2 处调用（active_blob, active_hook_blob）；外部调用 1 个（new）。

fn status_line_text(chat: &ChatWidget) -> Option<String>

作用：取出聊天窗口当前状态栏文字。它只是给测试提供一个更短的访问入口。

数据流：进去一个 ChatWidget 引用 → 它调用窗口自己的 status_line_text 方法 → 出来可选的状态栏字符串。

调用关系：测试需要检查底部状态提示时会用它；实际逻辑仍在 ChatWidget 内部。

调用图：调用 1 个内部函数（status_line_text）。

fn make_token_info(total_tokens: i64, context_window: i64) -> TokenUsageInfo

作用：快速造一份 token 使用信息。token 可以理解成模型读写文本时的计量单位。

数据流：进去总 token 数和上下文窗口大小 → 它把总量填到 total 和 last 两份用量里，并设置模型窗口 → 出来 TokenUsageInfo。

调用关系：handle_token_count 可接收它生成的数据，模拟服务器更新 token 统计。

fn thread_id(chat: &ChatWidget) -> String

作用：取出聊天窗口当前线程 id，没有就返回空字符串。线程 id 可以理解成一段对话的编号。

数据流：进去 ChatWidget → 它查看 chat.thread_id，有值就转成字符串，没有就给空串 → 出来线程编号字符串。

调用关系：大量 handle_* 辅助函数都用它给伪造的服务器通知补齐 thread_id。

调用图：被 21 处调用（handle_agent_message_delta, handle_agent_reasoning_delta, handle_agent_reasoning_final, handle_entered_review_mode, handle_error, handle_exec_begin, handle_exec_end, handle_exited_review_mode, handle_hook_completed, handle_hook_started (+11 more)）。

fn token_usage_breakdown(usage: TokenUsage) -> codex_app_server_protocol::TokenUsageBreakdown

作用：把内部 token 用量格式转成服务器协议需要的格式。

数据流：进去 TokenUsage → 它逐项复制总量、输入、缓存输入、输出、推理输出等字段 → 出来协议层的 TokenUsageBreakdown。

调用关系：handle_token_count 在组装 ThreadTokenUsageUpdated 通知时调用它。

调用图：被 1 处调用（handle_token_count）。

fn handle_token_count(chat: &mut ChatWidget, info: Option<TokenUsageInfo>)

作用：模拟服务器告诉聊天窗口 token 用量更新，或者清空 token 信息。

数据流：进去 ChatWidget 和可选 TokenUsageInfo → 有信息时，它组装 ThreadTokenUsageUpdated 通知并交给窗口处理；没有信息时直接清空窗口 token 状态 → 出来没有返回值，但窗口显示状态会变化。

调用关系：它使用 thread_id 和 token_usage_breakdown，是测试 token 计数显示的入口。

调用图：调用 3 个内部函数（set_token_info, thread_id, token_usage_breakdown）；外部调用 2 个（ThreadTokenUsageUpdated, handle_server_notification）。

fn handle_error(
    chat: &mut ChatWidget,
    message: impl Into<String>,
    codex_error_info: Option<CodexErrorInfo>,
)

作用：模拟一次不可重试的服务器错误。测试用它看错误提示怎么显示。

数据流：进去窗口、错误消息和可选错误详情 → 它包装成 ErrorNotification，标记 will_retry 为 false，再交给 ChatWidget → 出来没有值，但聊天窗口会处理错误。

调用关系：它调用 thread_id 补对话编号，最终把事件交给 handle_server_notification。

调用图：调用 1 个内部函数（thread_id）；外部调用 3 个（into, Error, handle_server_notification）。

fn handle_stream_error(
    chat: &mut ChatWidget,
    message: impl Into<String>,
    additional_details: Option<String>,
)

作用：模拟流式回复中的可重试错误。流式回复就是文字一点点传回来。

数据流：进去窗口、错误消息和附加详情 → 它把工作转交给 handle_stream_error_with_replay，并不指定回放类型 → 出来没有值。

调用关系：这是简化入口；真正组装通知的工作在 handle_stream_error_with_replay。

调用图：调用 1 个内部函数（handle_stream_error_with_replay）。

fn handle_stream_error_with_replay(
    chat: &mut ChatWidget,
    message: impl Into<String>,
    additional_details: Option<String>,
    replay_kind: Option<ReplayKind>,
)

作用：模拟带回放标记的流式错误。回放标记用于区分这是实时收到的，还是从历史记录恢复出来的。

数据流：进去窗口、消息、附加详情、可选 ReplayKind → 它创建 will_retry 为 true 的 ErrorNotification，再交给 ChatWidget → 出来没有值，窗口状态会更新。

调用关系：handle_stream_error 调用它；它直接进入 ChatWidget 的服务器通知处理流程。

调用图：调用 1 个内部函数（thread_id）；被 1 处调用（handle_stream_error）；外部调用 3 个（into, Error, handle_server_notification）。

fn handle_warning(chat: &mut ChatWidget, message: impl Into<String>)

作用：模拟服务器发来一条警告。警告不是失败，但需要显示给用户。

数据流：进去窗口和警告文字 → 它包装成 WarningNotification 并交给 ChatWidget → 出来没有值，但界面可能出现警告内容。

调用关系：测试警告展示时会用它；它依赖 thread_id 填对话编号。

调用图：调用 1 个内部函数（thread_id）；外部调用 3 个（into, Warning, handle_server_notification）。

fn handle_model_verification(
    chat: &mut ChatWidget,
    verifications: Vec<AppServerModelVerification>,
)

作用：模拟服务器返回模型验证结果。模型验证可以理解成检查所选模型是否满足要求。

数据流：进去窗口和一组验证结果 → 它组装 ModelVerificationNotification，带上当前 turn_id → 出来没有值，但 ChatWidget 会收到验证消息。

调用关系：它直接把构造好的通知交给 handle_server_notification。

调用图：调用 1 个内部函数（thread_id）；外部调用 2 个（ModelVerification, handle_server_notification）。

fn handle_agent_message_delta(chat: &mut ChatWidget, delta: impl Into<String>)

作用：模拟助手回复新增了一小段文字。delta 就是“增量片段”。

数据流：进去窗口和文字片段 → 它创建 AgentMessageDelta 通知，固定 item_id 为 msg-1 → 出来没有值，但窗口会把片段追加到当前回复。

调用关系：测试流式回答显示时调用它；它通过 ChatWidget 的通知入口生效。

调用图：调用 1 个内部函数（thread_id）；外部调用 3 个（into, AgentMessageDelta, handle_server_notification）。

fn handle_agent_reasoning_delta(chat: &mut ChatWidget, delta: impl Into<String>)

作用：模拟助手推理摘要新增一小段文字。推理摘要是模型思考过程的简短展示。

数据流：进去窗口和文字片段 → 它包装成 ReasoningSummaryTextDeltaNotification → 出来没有值，窗口会更新推理摘要区域。

调用关系：它和 handle_agent_message_delta 类似，但目标是 reasoning-1 这个推理项。

调用图：调用 1 个内部函数（thread_id）；外部调用 3 个（into, ReasoningSummaryTextDelta, handle_server_notification）。

fn handle_agent_reasoning_final(chat: &mut ChatWidget)

作用：模拟助手的推理项结束。用于测试推理显示从进行中变成完成。

数据流：进去窗口 → 它创建一个 Reasoning 类型的完成项，内容为空但 id 固定 → 出来没有值，窗口会收到 ItemCompleted。

调用关系：它调用 thread_id 并把完成通知交给 ChatWidget。

调用图：调用 1 个内部函数（thread_id）；外部调用 3 个（ItemCompleted, new, handle_server_notification）。

fn handle_entered_review_mode(chat: &mut ChatWidget, review: impl Into<String>)

作用：模拟服务器通知聊天进入 review mode，也就是审查或复核模式。

数据流：进去窗口和 review 文本 → 它创建 EnteredReviewMode 的 ItemStarted 通知 → 出来没有值，窗口会显示进入复核状态。

调用关系：测试 review mode 现场通知时会用它；回放场景则用 replay_entered_review_mode。

调用图：调用 1 个内部函数（thread_id）；外部调用 3 个（into, ItemStarted, handle_server_notification）。

fn replay_entered_review_mode(chat: &mut ChatWidget, review: impl Into<String>)

作用：模拟从历史记录回放“进入 review mode”的事件。

数据流：进去窗口和 review 文本 → 它直接调用 replay_thread_item，传入固定 turn-1 和 ThreadSnapshot 回放类型 → 出来没有值，窗口按历史项方式恢复显示。

调用关系：它不走普通服务器通知入口，而是走 ChatWidget 的回放入口。

调用图：外部调用 2 个（into, replay_thread_item）。

fn handle_exited_review_mode(chat: &mut ChatWidget)

作用：模拟服务器通知退出 review mode。

数据流：进去窗口 → 它创建 ExitedReviewMode 的 ItemCompleted 通知 → 出来没有值，窗口会结束复核状态显示。

调用关系：它和 handle_entered_review_mode 配套，用于测试 review mode 的完整进出流程。

调用图：调用 1 个内部函数（thread_id）；外部调用 3 个（ItemCompleted, new, handle_server_notification）。

fn handle_exec_approval_request(
    chat: &mut ChatWidget,
    id: impl Into<String>,
    event: ExecApprovalRequestEvent,
)

作用：模拟服务器请求用户批准执行命令。比如工具想运行 shell 命令时需要用户点同意。

数据流：进去窗口、请求 id 和审批事件 → 它把 id 转成字符串并调用窗口的 on_exec_approval_request → 出来没有值，但窗口会显示或记录审批请求。

调用关系：它直接触发 ChatWidget 的命令审批入口，不通过通用服务器通知包装。

调用图：外部调用 2 个（into, on_exec_approval_request）。

fn handle_apply_patch_approval_request(
    chat: &mut ChatWidget,
    id: impl Into<String>,
    event: ApplyPatchApprovalRequestEvent,
)

作用：模拟服务器请求用户批准应用补丁。补丁就是对文件的修改集合。

数据流：进去窗口、请求 id 和补丁审批事件 → 它调用 on_apply_patch_approval_request → 出来没有值，窗口会进入补丁审批相关状态。

调用关系：测试补丁审批 UI 时会用它，和命令审批辅助函数结构相同。

调用图：外部调用 2 个（into, on_apply_patch_approval_request）。

fn file_update_changes_from_tui(changes: HashMap<PathBuf, FileChange>) -> Vec<FileUpdateChange>

作用：把 TUI 内部的文件变更格式转成应用服务器协议格式。TUI 是文本用户界面。

数据流：进去路径到 FileChange 的映射 → 它逐个判断是新增、删除还是更新，并把路径、类型和 diff 文本装成 FileUpdateChange → 出来一组协议层文件变更。

调用关系：handle_patch_apply_begin 和 handle_patch_apply_end 都用它来生成补丁应用通知里的 changes 字段。

调用图：被 2 处调用（handle_patch_apply_begin, handle_patch_apply_end）。

fn handle_patch_apply_begin(
    chat: &mut ChatWidget,
    call_id: impl Into<String>,
    turn_id: impl Into<String>,
    changes: HashMap<PathBuf, FileChange>,
)

作用：模拟补丁开始应用。用于测试界面如何显示正在修改文件。

数据流：进去窗口、调用 id、turn id 和文件变更 → 它把变更转成协议格式，创建状态为 InProgress 的 FileChange 项并发送 ItemStarted → 出来没有值，窗口显示补丁进行中。

调用关系：它依赖 file_update_changes_from_tui，并把通知交给 ChatWidget。

调用图：调用 2 个内部函数（file_update_changes_from_tui, thread_id）；外部调用 3 个（into, ItemStarted, handle_server_notification）。

fn handle_patch_apply_end(
    chat: &mut ChatWidget,
    call_id: impl Into<String>,
    turn_id: impl Into<String>,
    changes: HashMap<PathBuf, FileChange>,
    status: AppServerPatchApplyStatus,

作用：模拟补丁应用结束，可以是成功或失败等状态。

数据流：进去窗口、调用 id、turn id、文件变更和最终状态 → 它创建 FileChange 完成项并发送 ItemCompleted → 出来没有值，窗口更新补丁结果。

调用关系：它和 handle_patch_apply_begin 配套，共同测试补丁生命周期。

调用图：调用 2 个内部函数（file_update_changes_from_tui, thread_id）；外部调用 3 个（into, ItemCompleted, handle_server_notification）。

fn handle_view_image_tool_call(
    chat: &mut ChatWidget,
    call_id: impl Into<String>,
    path: AbsolutePathBuf,
)

作用：模拟查看图片工具调用完成。用于测试聊天里出现图片查看记录。

数据流：进去窗口、调用 id 和图片绝对路径 → 它创建 ImageView 完成项并交给 ChatWidget → 出来没有值，窗口会显示图片查看相关内容。

调用关系：它通过普通 ItemCompleted 通知进入 ChatWidget。

调用图：调用 1 个内部函数（thread_id）；外部调用 3 个（into, ItemCompleted, handle_server_notification）。

fn handle_image_generation_end(
    chat: &mut ChatWidget,
    call_id: impl Into<String>,
    status: impl Into<String>,
    revised_prompt: Option<String>,
    saved_path: Option<AbsolutePathBuf>,
)

作用：模拟图片生成任务结束。可以带上状态、改写后的提示词和保存路径。

数据流：进去窗口、调用 id、状态文本、可选 revised_prompt、可选保存路径 → 它创建 ImageGeneration 完成项 → 出来没有值，窗口显示生成结果。

调用关系：测试图片生成 UI 时用它直接注入服务器完成通知。

调用图：调用 1 个内部函数（thread_id）；外部调用 4 个（into, ItemCompleted, new, handle_server_notification）。

fn replay_user_message_inputs(
    chat: &mut ChatWidget,
    item_id: &str,
    content: Vec<AppServerUserInput>,
    replay_kind: ReplayKind,
)

作用：从历史记录里回放一条用户消息，内容可以包含多种输入。

数据流：进去窗口、消息项 id、输入内容列表和回放类型 → 它创建 UserMessage 线程项并调用 replay_thread_item → 出来没有值，窗口按历史方式显示用户消息。

调用关系：replay_user_message_text 调用它处理纯文本情况。

调用图：被 1 处调用（replay_user_message_text）；外部调用 1 个（replay_thread_item）。

fn replay_user_message_text(
    chat: &mut ChatWidget,
    item_id: &str,
    text: impl Into<String>,
    replay_kind: ReplayKind,
)

作用：从历史记录里回放一条纯文本用户消息。

数据流：进去窗口、消息项 id、文本和回放类型 → 它把文本包装成 AppServerUserInput::Text，再交给 replay_user_message_inputs → 出来没有值。

调用关系：这是 replay_user_message_inputs 的简便版本，适合大多数只测文字的场景。

调用图：调用 1 个内部函数（replay_user_message_inputs）；外部调用 1 个（vec!）。

fn replay_agent_message(
    chat: &mut ChatWidget,
    item_id: &str,
    text: impl Into<String>,
    replay_kind: ReplayKind,
)

作用：从历史记录里回放一条助手最终回答。

数据流：进去窗口、消息项 id、文本和回放类型 → 它创建 AgentMessage，phase 固定为 FinalAnswer，再调用 replay_thread_item → 出来没有值，窗口恢复助手消息。

调用关系：它用于测试历史快照或会话恢复，不模拟实时增量。

调用图：外部调用 2 个（into, replay_thread_item）。

fn replay_turn_started(chat: &mut ChatWidget, replay_kind: ReplayKind)

作用：以回放方式模拟一个 turn 开始。turn 可以理解成用户提问到助手回答的一轮交互。

数据流：进去窗口和回放类型 → 它用 app_server_turn 创建进行中的 turn，并包装成 TurnStarted 通知 → 出来没有值，窗口按回放语境处理开始事件。

调用关系：它调用 app_server_turn，并把 replay_kind 放进 handle_server_notification。

调用图：调用 2 个内部函数（app_server_turn, thread_id）；外部调用 2 个（TurnStarted, handle_server_notification）。

fn replay_agent_message_delta(
    chat: &mut ChatWidget,
    delta: impl Into<String>,
    replay_kind: ReplayKind,
)

作用：以回放方式模拟助手消息的增量片段。

数据流：进去窗口、片段文本和回放类型 → 它创建 AgentMessageDelta 通知，并带上 Some(replay_kind) → 出来没有值，窗口按历史回放处理这段文字。

调用关系：它和实时的 handle_agent_message_delta 类似，但明确告诉 ChatWidget 这是回放事件。

调用图：调用 1 个内部函数（thread_id）；外部调用 3 个（into, AgentMessageDelta, handle_server_notification）。

fn begin_exec_with_source(
    chat: &mut ChatWidget,
    call_id: &str,
    raw_cmd: &str,
    source: ExecCommandSource,
) -> AppServerThreadItem

作用：模拟一个命令执行开始，并指定命令来源。命令来源可区分是助手发起还是其他机制发起。

数据流：进去窗口、调用 id、原始命令和来源 → 它组装 bash -lc 命令，解析命令动作，创建 InProgress 的 CommandExecution 项，并发送开始通知 → 出来这条执行项，方便后续结束时复用。

调用关系：begin_exec 是它的简化包装；它内部调用 handle_exec_begin 发通知。

调用图：调用 3 个内部函数（parse_command, shlex_join, handle_exec_begin）；被 1 处调用（begin_exec）；外部调用 1 个（vec!）。

fn begin_unified_exec_startup(
    chat: &mut ChatWidget,
    call_id: &str,
    process_id: &str,
    raw_cmd: &str,
) -> AppServerThreadItem

作用：模拟统一执行器启动阶段的命令开始，并带上进程 id。

数据流：进去窗口、调用 id、进程 id 和原始命令 → 它创建来源为 UnifiedExecStartup 的 CommandExecution 项，然后发送开始通知 → 出来这条执行项。

调用关系：它和 begin_exec_with_source 类似，也把最终通知交给 handle_exec_begin。

调用图：调用 2 个内部函数（shlex_join, handle_exec_begin）；外部调用 2 个（new, vec!）。

fn handle_exec_begin(chat: &mut ChatWidget, item: AppServerThreadItem)

作用：把一个命令执行项作为“开始事件”送进 ChatWidget。

数据流：进去窗口和线程项 → 它包装成 ItemStartedNotification，补上 thread_id 和 turn_id → 出来没有值，窗口显示命令正在运行。

调用关系：begin_exec_with_source 和 begin_unified_exec_startup 都调用它。

调用图：调用 1 个内部函数（thread_id）；被 2 处调用（begin_exec_with_source, begin_unified_exec_startup）；外部调用 2 个（ItemStarted, handle_server_notification）。

fn terminal_interaction(
    chat: &mut ChatWidget,
    call_id: &str,
    process_id: &str,
    stdin: &str,
)

作用：模拟用户向正在运行的终端进程输入内容。比如给交互式命令发送 stdin。

数据流：进去窗口、调用 id、进程 id 和输入文本 → 它创建 TerminalInteractionNotification 并交给 ChatWidget → 出来没有值，窗口记录这次终端交互。

调用关系：测试统一执行器或交互式命令显示时会用它。

调用图：调用 1 个内部函数（thread_id）；外部调用 2 个（TerminalInteraction, handle_server_notification）。

fn complete_assistant_message(
    chat: &mut ChatWidget,
    item_id: &str,
    text: &str,
    phase: Option<MessagePhase>,
)

作用：模拟助手消息一次性完成，而不是一点点流式输出。

数据流：进去窗口、消息 id、文本和可选阶段 → 它创建 AgentMessage 完成项并发送 ItemCompleted → 出来没有值，窗口加入或更新助手消息。

调用关系：适合测试最终回答、阶段显示等，不需要先调用 delta。

调用图：外部调用 2 个（ItemCompleted, handle_server_notification）。

fn pending_steer(text: &str) -> PendingSteer

作用：创建一条待发送或待调整的用户指令。steer 可以理解成用户给助手的引导消息。

数据流：进去文本 → 它生成 UserMessage、历史记录类型和用于比较去重的 key → 出来 PendingSteer。

调用关系：测试输入队列或待处理用户消息时可用它造数据。

调用图：调用 1 个内部函数（from）。

fn complete_user_message(chat: &mut ChatWidget, item_id: &str, text: &str)

作用：模拟用户消息完成，内容是普通文本。

数据流：进去窗口、消息 id 和文本 → 它把文本包装成 UserInput::Text，然后交给 complete_user_message_for_inputs → 出来没有值。

调用关系：这是 complete_user_message_for_inputs 的简便入口。

调用图：调用 1 个内部函数（complete_user_message_for_inputs）；外部调用 1 个（vec!）。

fn complete_user_message_for_inputs(
    chat: &mut ChatWidget,
    item_id: &str,
    content: Vec<UserInput>,
)

作用：模拟用户消息完成，内容可以是多种输入。

数据流：进去窗口、消息 id 和输入列表 → 它创建 UserMessage 完成项，并通过 ItemCompleted 交给 ChatWidget → 出来没有值，窗口记录用户消息。

调用关系：complete_user_message 调用它处理纯文本消息。

调用图：被 1 处调用（complete_user_message）；外部调用 2 个（ItemCompleted, handle_server_notification）。

fn app_server_turn(
    turn_id: &str,
    status: AppServerTurnStatus,
    duration_ms: Option<i64>,
    error: Option<AppServerTurnError>,
) -> AppServerTurn

作用：快速创建一轮对话的服务器对象。它只填测试关心的状态、耗时和错误。

数据流：进去 turn id、状态、可选耗时、可选错误 → 它创建 items 为空、视图为 Full 的 AppServerTurn → 出来一个 turn 对象。

调用关系：handle_turn_started、handle_turn_completed、handle_turn_interrupted 和 replay_turn_started 都用它减少重复代码。

调用图：被 4 处调用（handle_turn_completed, handle_turn_interrupted, handle_turn_started, replay_turn_started）；外部调用 1 个（new）。

fn handle_turn_started(chat: &mut ChatWidget, turn_id: &str)

作用：模拟服务器通知一轮对话开始。

数据流：进去窗口和 turn id → 它用 app_server_turn 创建 InProgress 状态的 turn，再发送 TurnStarted → 出来没有值，窗口进入一轮任务进行中状态。

调用关系：它是测试 turn 生命周期开始阶段的入口。

调用图：调用 1 个内部函数（app_server_turn）；外部调用 2 个（TurnStarted, handle_server_notification）。

fn handle_turn_completed(
    chat: &mut ChatWidget,
    turn_id: &str,
    duration_ms: Option<i64>,
)

作用：模拟服务器通知一轮对话正常完成。

数据流：进去窗口、turn id 和可选耗时 → 它创建 Completed 状态的 turn，并发送 TurnCompleted → 出来没有值，窗口结束当前轮次。

调用关系：它和 handle_turn_started 配套，用于测试从开始到完成的状态变化。

调用图：调用 1 个内部函数（app_server_turn）；外部调用 2 个（TurnCompleted, handle_server_notification）。

fn handle_turn_interrupted(chat: &mut ChatWidget, turn_id: &str)

作用：模拟一轮对话被中断。中断不是正常完成，通常表示用户停止或系统停止。

数据流：进去窗口和 turn id → 它创建 Interrupted 状态的 turn，并发送 TurnCompleted 通知 → 出来没有值，窗口按中断处理。

调用关系：handle_budget_limited_turn 会先标记预算受限，再调用它完成中断通知。

调用图：调用 1 个内部函数（app_server_turn）；被 1 处调用（handle_budget_limited_turn）；外部调用 2 个（TurnCompleted, handle_server_notification）。

fn handle_budget_limited_turn(chat: &mut ChatWidget, turn_id: &str)

作用：模拟因为预算限制导致一轮对话被中断。

数据流：进去窗口和 turn id → 它先在 turn_lifecycle 里标记该 turn 受预算限制，再调用 handle_turn_interrupted → 出来没有值，窗口会带着预算限制语义处理中断。

调用关系：它复用 handle_turn_interrupted，只额外加上预算原因。

调用图：调用 1 个内部函数（handle_turn_interrupted）。

fn begin_exec(
    chat: &mut ChatWidget,
    call_id: &str,
    raw_cmd: &str,
) -> AppServerThreadItem

作用：用默认“助手发起”的来源模拟命令开始执行。

数据流：进去窗口、调用 id 和原始命令 → 它调用 begin_exec_with_source，并把来源固定为 Agent → 出来命令执行项。

调用关系：这是最常用的命令开始辅助函数，隐藏了来源参数。

调用图：调用 1 个内部函数（begin_exec_with_source）。

fn end_exec(
    chat: &mut ChatWidget,
    begin_item: AppServerThreadItem,
    stdout: &str,
    stderr: &str,
    exit_code: i32,
)

作用：模拟命令执行结束，并根据退出码决定成功还是失败。

数据流：进去窗口、开始时返回的执行项、stdout、stderr 和退出码 → 它合并输出，拆出原执行项字段，创建 Completed 或 Failed 状态的新执行项，再发送结束通知 → 出来没有值；如果传入的不是命令项会让测试失败。

调用关系：它通常接在 begin_exec 后面使用，并通过 handle_exec_end 交给 ChatWidget。

调用图：调用 1 个内部函数（handle_exec_end）；外部调用 2 个（format!, panic!）。

fn handle_exec_end(chat: &mut ChatWidget, item: AppServerThreadItem)

作用：把一个命令执行项作为“完成事件”送进 ChatWidget。

数据流：进去窗口和线程项 → 它包装成 ItemCompletedNotification，补上 thread_id 和 turn_id → 出来没有值，窗口显示命令结果。

调用关系：end_exec 调用它；它是命令结束通知的底层辅助函数。

调用图：调用 1 个内部函数（thread_id）；被 1 处调用（end_exec）；外部调用 2 个（ItemCompleted, handle_server_notification）。

fn active_blob(chat: &ChatWidget) -> String

作用：取出当前活动聊天单元的可见文本。活动单元通常是正在更新的那块内容。

数据流：进去窗口 → 它要求 active_cell 必须存在，把它按 80 宽度渲染，再转成普通字符串 → 出来可用于断言的文本。

调用关系：它依赖 lines_to_single_string，常用于快照或精确文本断言。

调用图：调用 1 个内部函数（lines_to_single_string）。

fn active_hook_blob(chat: &ChatWidget) -> String

作用：取出当前活动钩子单元的可见文本。钩子是某些事件发生时自动运行的小任务。

数据流：进去窗口 → 如果没有活动钩子单元就返回 <empty>；否则渲染成行并转成字符串 → 出来钩子区域文本。

调用关系：assert_hook_events_snapshot 用它检查正在运行的钩子是否显示在 live cell 里。

调用图：调用 1 个内部函数（lines_to_single_string）。

fn expire_quiet_hook_linger(chat: &mut ChatWidget)

作用：强制让安静钩子的停留时间过期。这样测试不用真的等待时间流逝。

数据流：进去窗口 → 如果有活动钩子单元，就调用测试专用过期方法，然后触发 pre_draw_tick → 出来没有值，但界面内部计时状态被推进。

调用关系：它用于测试钩子显示何时消失，最后通过 ChatWidget 的绘制前刷新生效。

调用图：调用 1 个内部函数（pre_draw_tick）。

fn reveal_running_hooks(chat: &mut ChatWidget)

作用：强制显示正在运行的钩子。避免测试等待正常延迟。

数据流：进去窗口 → 如果有活动钩子单元，就把运行中钩子设为立刻可见，再调用 pre_draw_tick → 出来没有值，钩子显示状态刷新。

调用关系：assert_hook_events_snapshot 调用它来确认 hook start 更新的是活动钩子单元。

调用图：调用 1 个内部函数（pre_draw_tick）；被 1 处调用（assert_hook_events_snapshot）。

fn reveal_running_hooks_after_delayed_redraw(chat: &mut ChatWidget)

作用：模拟延迟重绘之后才显示运行中钩子的情况。

数据流：进去窗口 → 它把活动钩子单元推进到“延迟重绘后可见”的测试状态，再触发 pre_draw_tick → 出来没有值。

调用关系：用于覆盖比 reveal_running_hooks 更接近真实延迟刷新的一类测试。

调用图：调用 1 个内部函数（pre_draw_tick）。

fn get_available_model(chat: &ChatWidget, model: &str) -> ModelPreset

作用：从聊天窗口的模型目录里找指定模型。找不到就让测试失败。

数据流：进去窗口和模型名 → 它读取模型目录列表，按 model 字段查找并克隆结果 → 出来 ModelPreset；如果没有找到就 panic。

调用关系：测试需要确认某个模型预设内容时会用它。

async fn assert_shift_left_edits_most_recent_queued_message_for_terminal(
    terminal_info: TerminalInfo,
)

作用：验证在特定终端里按 Shift+Left 会编辑最近排队的消息。

数据流：进去终端信息 → 它创建聊天窗口，设置快捷键提示，模拟任务运行和两条排队消息，再发送 Shift+Left 按键 → 出来没有值，但会断言输入框变成第二条消息、队列只剩第一条。

调用关系：它是一个较完整的测试辅助断言，内部用 make_chatwidget_manual 搭环境。

调用图：调用 2 个内部函数（make_chatwidget_manual, from）；外部调用 2 个（new, assert_eq!）。

fn render_bottom_first_row(chat: &ChatWidget, width: u16) -> String

作用：渲染聊天窗口底部区域，并返回第一行非空文本。

数据流：进去窗口和宽度 → 它计算需要的高度，创建缓冲区，让 ChatWidget 渲染进去，再从上到下找第一行有内容的文本 → 出来这一行字符串。

调用关系：测试底部输入区或状态条首行显示时会用它。

调用图：外部调用 5 个（empty, new, new, desired_height, render）。

fn render_bottom_popup(chat: &ChatWidget, width: u16) -> String

作用：渲染聊天窗口底部弹窗，并返回去掉上下空白后的文本。

数据流：进去窗口和宽度 → 它创建渲染区域和缓冲区，调用 ChatWidget 渲染，收集每一行并裁掉首尾空行 → 出来弹窗文本。

调用关系：render_loaded_plugins_popup 调用它获取插件弹窗内容。

调用图：被 1 处调用（render_loaded_plugins_popup）；外部调用 4 个（empty, new, desired_height, render）。

fn strip_osc8_for_snapshot(text: &str) -> String

作用：移除终端超链接转义码，只保留用户看得见的文字。OSC8 是终端里表示超链接的控制序列。

数据流：进去一段文本 → 它逐字节扫描，遇到 OSC8 超链接控制段就跳过，普通字符照常保留 → 出来没有隐藏超链接码的字符串。

调用关系：快照测试用它避免不可见控制码影响比较结果。

调用图：外部调用 1 个（with_capacity）。

fn plugins_test_absolute_path(path: &str) -> AbsolutePathBuf

作用：生成插件测试用的绝对路径。所有路径都放在系统临时目录下的固定子目录里。

数据流：进去相对路径字符串 → 它拼到 temp_dir/codex-plugin-menu-tests 后面，并转成绝对路径 → 出来 AbsolutePathBuf。

调用关系：插件摘要、市场、详情等构造函数都会用它填路径字段。

调用图：被 4 处调用（plugins_test_curated_marketplace, plugins_test_detail, plugins_test_repo_marketplace, plugins_test_summary）；外部调用 1 个（temp_dir）。

fn plugins_test_interface(
    display_name: Option<&str>,
    short_description: Option<&str>,
    long_description: Option<&str>,
) -> PluginInterface

作用：创建插件展示信息。比如显示名、短描述、长描述。

数据流：进去三个可选文本 → 它填入对应字段，其他品牌、截图、能力等字段都给空或 None → 出来 PluginInterface。

调用关系：plugins_test_summary 和 plugins_test_remote_summary 用它给插件补界面元数据。

调用图：被 2 处调用（plugins_test_remote_summary, plugins_test_summary）；外部调用 1 个（new）。

fn plugins_test_summary(
    id: &str,
    name: &str,
    display_name: Option<&str>,
    description: Option<&str>,
    installed: bool,
    enabled: bool,
    install_policy: PluginInstallPolicy,
)

作用：创建本地插件的测试摘要。摘要是插件列表里看到的那份简短信息。

数据流：进去插件 id、名称、显示名、描述、安装状态、启用状态和安装策略 → 它生成本地来源路径、接口信息和默认策略字段 → 出来 PluginSummary。

调用关系：测试插件列表、插件弹窗和市场内容时会用它造本地插件。

调用图：调用 2 个内部函数（plugins_test_absolute_path, plugins_test_interface）；外部调用 2 个（new, format!）。

fn plugins_test_remote_summary(
    remote_plugin_id: &str,
    name: &str,
    display_name: Option<&str>,
    description: Option<&str>,
    installed: bool,
) -> PluginSummary

作用：创建远程插件的测试摘要。远程插件来自市场，不是本地路径。

数据流：进去远程插件 id、名称、显示名、描述和安装状态 → 它设置 source 为 Remote、enabled 为 true，并补接口信息 → 出来 PluginSummary。

调用关系：它和 plugins_test_summary 类似，但用于远程市场插件测试。

调用图：调用 1 个内部函数（plugins_test_interface）；外部调用 1 个（new）。

fn plugins_test_curated_marketplace(
    plugins: Vec<PluginSummary>,
) -> PluginMarketplaceEntry

作用：创建 OpenAI 精选插件市场的测试对象。

数据流：进去一组插件摘要 → 它填入固定市场名、测试路径、显示名 ChatGPT Marketplace 和插件列表 → 出来 PluginMarketplaceEntry。

调用关系：plugins_test_response 可把它和其他市场一起包装成插件列表响应。

调用图：调用 1 个内部函数（plugins_test_absolute_path）。

fn plugins_test_repo_marketplace(plugins: Vec<PluginSummary>) -> PluginMarketplaceEntry

作用：创建仓库本地插件市场的测试对象。

数据流：进去一组插件摘要 → 它填入 repo 名称、测试路径、显示名 Repo Marketplace 和插件列表 → 出来 PluginMarketplaceEntry。

调用关系：用于测试多个市场来源时和 curated marketplace 搭配使用。

调用图：调用 1 个内部函数（plugins_test_absolute_path）。

fn plugins_test_response(
    marketplaces: Vec<PluginMarketplaceEntry>,
) -> PluginListResponse

作用：把多个插件市场包装成一次插件列表响应。

数据流：进去市场列表 → 它创建 PluginListResponse，并把加载错误和 featured 插件列表设为空 → 出来响应对象。

调用关系：render_loaded_plugins_popup 会接收这种响应来模拟插件加载完成。

调用图：外部调用 1 个（new）。

fn render_loaded_plugins_popup(
    chat: &mut ChatWidget,
    response: PluginListResponse,
) -> String

作用：模拟插件加载完成并渲染插件弹窗文本。

数据流：进去窗口和插件列表响应 → 它调用 on_plugins_loaded 写入结果，再让窗口添加插件输出，最后渲染底部弹窗 → 出来弹窗字符串。

调用关系：它把插件数据构造、ChatWidget 状态更新和 render_bottom_popup 串起来，方便测试直接断言显示结果。

调用图：调用 1 个内部函数（render_bottom_popup）；外部调用 2 个（add_plugins_output, on_plugins_loaded）。

fn plugins_test_detail(
    summary: PluginSummary,
    description: Option<&str>,
    skills: &[&str],
    hooks: &[(codex_app_server_protocol::HookEventName, usize)],
    apps: &[&str],
    mcp_serv

作用：创建插件详情页测试数据。详情比摘要多了技能、钩子、应用、MCP 服务器等内容。

数据流：进去插件摘要、描述、技能名列表、钩子事件和数量、应用名、MCP 服务器名 → 它逐项生成对应 summary，并填入测试路径和默认字段 → 出来 PluginDetail。

调用关系：测试插件详情弹窗或详情页排序、展示时会用它。

调用图：调用 1 个内部函数（plugins_test_absolute_path）；外部调用 2 个（new, iter）。

fn plugins_test_popup_row_position(popup: &str, needle: &str) -> usize

作用：查找某段文字在插件弹窗文本里的位置。找不到就让测试失败。

数据流：进去弹窗文本和要找的字符串 → 它调用 find，找到就返回字节位置；找不到就 panic 并带上完整弹窗 → 出来位置数字。

调用关系：测试插件弹窗内容顺序时会用它比较不同文字的位置。

fn type_plugins_search_query(chat: &mut ChatWidget, query: &str)

作用：模拟用户在插件搜索框里逐字输入查询词。

数据流：进去窗口和查询字符串 → 它把每个字符变成 KeyEvent，并交给 ChatWidget 的按键处理 → 出来没有值，窗口搜索状态会变化。

调用关系：插件搜索相关测试用它代替真实键盘输入。

调用图：外部调用 3 个（Char, from, handle_key_event）。

fn handle_hook_started(chat: &mut ChatWidget, run: AppServerHookRunSummary)

作用：模拟钩子开始运行。钩子是某些事件前后自动执行的脚本或处理器。

数据流：进去窗口和钩子运行摘要 → 它包装成 HookStarted 通知并交给 ChatWidget → 出来没有值，窗口更新钩子运行显示。

调用关系：assert_hook_events_snapshot 用它触发钩子开始场景。

调用图：调用 1 个内部函数（thread_id）；被 1 处调用（assert_hook_events_snapshot）；外部调用 2 个（HookStarted, handle_server_notification）。

fn handle_hook_completed(chat: &mut ChatWidget, run: AppServerHookRunSummary)

作用：模拟钩子运行完成。

数据流：进去窗口和钩子运行摘要 → 它包装成 HookCompleted 通知并交给 ChatWidget → 出来没有值，窗口把钩子结果写入或更新显示。

调用关系：assert_hook_events_snapshot 在钩子开始后调用它，检查完成后历史输出。

调用图：调用 1 个内部函数（thread_id）；被 1 处调用（assert_hook_events_snapshot）；外部调用 2 个（HookCompleted, handle_server_notification）。

fn hook_run(
    run_id: &str,
    event_name: codex_app_server_protocol::HookEventName,
    status: codex_app_server_protocol::HookRunStatus,
    status_message: &str,
    entries: Vec<codex_app_serv

作用：创建一条钩子运行摘要。可以指定事件名、状态、状态消息和输出条目。

数据流：进去运行 id、钩子事件名、状态、状态消息和输出列表 → 它填入命令型、同步、turn 范围、测试 hooks 路径等字段；如果状态是结束态就填完成时间和耗时 → 出来 HookRunSummary。

调用关系：assert_hook_events_snapshot 用它分别创建 running 和 completed 两种钩子数据。

调用图：被 1 处调用（assert_hook_events_snapshot）；外部调用 2 个（from, matches!）。

async fn assert_hook_events_snapshot(
    event_name: codex_app_server_protocol::HookEventName,
    run_id: &str,
    status_message: &str,
    snapshot_name: &str,
)

作用：完整测试某类钩子事件的显示快照。它验证开始时显示在活动钩子区，完成后写入历史。

数据流：进去钩子事件名、运行 id、状态消息和快照名 → 它创建聊天窗口，发送钩子开始，断言没有写历史，再强制显示运行中钩子，随后发送完成事件并收集历史文本做快照断言 → 出来没有值，失败时测试中断。

调用关系：它串起 make_chatwidget_manual、handle_hook_started、hook_run、reveal_running_hooks、handle_hook_completed 和 drain_insert_history，是钩子测试的高层编排函数。

调用图：调用 6 个内部函数（drain_insert_history, handle_hook_completed, handle_hook_started, hook_run, make_chatwidget_manual, reveal_running_hooks）；外部调用 4 个（new, assert!, assert_chatwidget_snapshot!, vec!）。

fn hook_event_label(event_name: codex_app_server_protocol::HookEventName) -> &'static str

作用：把钩子事件枚举转成固定英文标签。枚举就是一组预定义选项。

数据流：进去 HookEventName → 它按不同事件返回对应的静态字符串，比如 PreToolUse 或 SessionStart → 出来标签文本。

调用关系：assert_hook_events_snapshot 用它拼出预期的运行中钩子提示文字。

async fn make_test_app() -> App

作用：创建一个测试用的 App 实例，让 App 子模块的测试可以直接拿来用。它避免测试到处重复搭建复杂对象，也避免测试误碰真实外部服务。

数据流：进去几乎没有外部输入 → 它先创建一个测试用聊天窗口和事件发送器，再从聊天窗口拿配置；接着建立文件搜索器，找一个离线测试模型，生成测试遥测信息；最后把大量 App 字段填成测试安全的默认值、空列表、空状态或测试专用对象 → 出来的是一个完整的 App，测试可以马上拿它验证配置刷新、线程切换、历史回放等行为。

调用关系：它是很多 App 单元测试的起点。调用图显示，像配置重建、从磁盘刷新配置、关闭 agent 线程时的清单检查、自动审查 companion 规则等测试都会先调用它拿到基础 App。它内部会把造测试聊天窗口、拿离线模型、创建 SessionTelemetry、创建文件搜索器和各种默认状态这些杂活串起来。

调用图：调用 8 个内部函数（default, without_managed_config_for_tests, default_for_tests, new, get_model_offline_for_tests, test_session_telemetry, new, defaults）；被 18 处调用（mcp_inventory_omits_thread_id_for_closed_agent_thread, overridden_disabled_guardian_does_not_apply_auto_review_companions, rebuild_config_for_resume_or_fallback_errors_when_cwd_changes, rebuild_config_for_resume_or_fallback_uses_current_config_on_same_cwd_error, refresh_in_memory_config_from_disk_best_effort_keeps_current_config_on_error, refresh_in_memory_config_from_disk_keeps_cloud_requirements_for_thread_transitions, refresh_in_memory_config_from_disk_loads_latest_apps_state, refresh_in_memory_config_from_disk_updates_resize_reflow_config, refresh_in_memory_config_from_disk_uses_active_chat_widget_cwd, sync_tui_pet_disabled_updates_chat_widget_config_copy (+8 more)）；外部调用 13 个（new, new, new, new, new, default, make_chatwidget_manual_with_sender, default, default, default (+3 more)）。

fn test_session_telemetry(config: &Config, model: &str) -> SessionTelemetry

作用：生成一份测试用的会话遥测信息。遥测可以理解成“这次会话的背景记录”，比如用的模型、来源、线程编号等；这里生成的是假的、离线的、适合测试的记录。

数据流：进去的是 Config 配置和模型名字符串 → 它把 Config 转成模型管理器能看懂的配置，离线构造模型信息；然后新建一个线程编号，填入模型名、模型标识、测试来源、测试环境等固定值，不填真实账号和邮箱 → 出来的是一个 SessionTelemetry 对象，供测试 App 像真实 App 一样携带会话信息。

调用关系：它只被 make_test_app 调用，是 make_test_app 组装测试 App 时的一个小零件。它自己又会调用离线模型信息构造函数和 SessionTelemetry::new，把“模型是什么”和“会话从哪里来”这两类信息合成一份测试记录。

调用图：调用 3 个内部函数（construct_model_info_offline_for_tests, new, new）；被 1 处调用（make_test_app）；外部调用 3 个（to_models_manager_config, from_value, json!）。

fn app_enabled_in_effective_config(config: &Config, app_id: &str) -> Option<bool>

作用：从最终生效的配置里查某个 app 是否被打开。它适合测试配置合并后的结果，而不是只看某一层原始配置。

数据流：进去的是 Config 配置和 app_id → 它沿着配置里的 config_layer_stack 找到 effective_config，也就是多层配置叠加后的最终结果；然后一层层查 apps、指定 app、enabled 字段，并确认 enabled 真的是布尔值 → 出来是 Some(true) 或 Some(false)，表示明确开关；如果中间任何一层不存在或类型不对，就出来 None。

调用关系：它是测试里用来验收配置结果的小工具。调用图没有显示它再调用本项目里的其他函数，它主要靠一串安全的取值步骤读取配置表，避免测试因为字段缺失而直接崩掉。

fn test_absolute_path(path: &str) -> AbsolutePathBuf

作用：把测试里写的字符串路径变成“绝对路径”类型。这样测试可以明确表示：这里需要的是完整路径，不是相对路径。

数据流：输入一个路径字符串 → 先转成普通路径对象，再尝试转成 AbsolutePathBuf → 成功就返回绝对路径；如果传入的不是绝对路径，测试会直接失败。

调用关系：这是测试辅助函数。它被其他测试用来准备文件系统权限或线程设置相关的路径数据，避免每个测试都重复写路径转换代码。

调用图：调用 1 个内部函数（try_from）；被 2 处调用（inactive_thread_permissions_approval_preserves_file_system_permissions, inactive_thread_settings_notification_updates_cached_collaboration_mode）；外部调用 1 个（from）。

async fn next_thread_settings_updated(
    app_server: &mut AppServerSession,
    thread_id: ThreadId,
) -> ThreadSettingsUpdatedNotification

作用：从测试用 App 服务端事件流里等一个指定线程的“线程设置已更新”通知。它用来确认后台确实发出了设置更新，而且发给了正确线程。

数据流：输入 AppServerSession 和线程 ID → 最多尝试读取 20 个事件，每次最多等 2 秒 → 找到线程 ID 匹配的 ThreadSettingsUpdatedNotification 就返回；如果一直没有，就让测试失败。

调用关系：这是异步测试辅助函数。调用它的测试先触发设置覆盖或更新，然后靠它从服务端事件里捞出对应通知，验证整条通知链路没有断。

调用图：调用 1 个内部函数（next_event）；被 1 处调用（override_turn_context_sends_thread_settings_update）；外部调用 4 个（panic!, to_string, from_secs, timeout）。

async fn handle_mcp_inventory_result_respects_origin_thread()

作用：检查 MCP 清单结果只会影响它原本所属的线程。MCP 可以理解成外部工具服务清单；这个测试防止别的线程的工具列表把当前界面误清掉。

数据流：先创建测试 App，并放入一个“MCP 正在加载”的历史单元 → 传入没有线程来源的结果，确认加载单元被移除 → 再设置当前活动线程，传入另一个线程的结果，确认当前界面不被改动。

调用关系：测试直接调用 App 的 handle_mcp_inventory_result。它关注的是 App 收到后台工具清单结果时，是否先检查来源线程，再决定要不要更新当前聊天记录。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 5 个（new, new, assert_eq!, new_mcp_inventory_loading, vec!）。

fn bypass_hook_trust_startup_warning_snapshot()

作用：检查启动时的危险选项警告文案长什么样。这里的快照测试像给界面拍照片，防止警告被意外改坏或消失。

数据流：输入一段固定警告文字 → 生成 warning 历史单元并按 80 列宽渲染 → 合成单行字符串 → 和保存好的快照对比。

调用关系：它测试 history_cell 的警告渲染效果。测试框架运行它时，会确认启用绕过 hook 信任检查的提示仍然清楚可见。

调用图：调用 1 个内部函数（lines_to_single_string）；外部调用 2 个（assert_app_snapshot!, new_warning_event）。

async fn enqueue_primary_thread_session_replays_buffered_approval_after_attach() -> Result<()>

作用：确认主线程会话接上以后，之前缓存的审批请求会重新送到界面，并且用户同意后会提交到正确线程。

数据流：先造一个审批请求并记录到待处理请求表 → 在会话还没接上时把请求排进主线程 → 接上对应线程会话 → 从线程接收器里拿到缓存事件 → 用户按 y 同意 → 检查发出的操作带着正确线程 ID。

调用关系：这个测试覆盖“后台请求先到、线程稍后挂载”的流程。它把事件交给 enqueue_primary_thread_request、enqueue_primary_thread_session 和 handle_thread_event_now，再观察 AppEvent 输出。

调用图：调用 4 个内部函数（new, exec_approval_request, make_test_app_with_channels, test_thread_session）；外部调用 8 个（from_millis, Char, new, new, assert!, assert_eq!, panic!, timeout）。

async fn resolved_buffered_approval_does_not_become_actionable_after_drain() -> Result<()>

作用：确认一个已经被解决的缓存审批，即使后来从队列里被播放出来，也不会重新变成可点击、可同意的请求。

数据流：先接上线程 → 放入审批请求 → 立刻把这个请求标记为已解决并从聊天组件里移除 → 再从线程队列取出同一个旧事件 → 用户按 y → 检查没有产生新的提交操作。

调用关系：它验证 pending_app_server_requests 和 chat_widget 的配合。队列可以重放旧事件，但 App 必须记得这个请求已经处理过，不能让它复活。

调用图：调用 4 个内部函数（new, exec_approval_request, make_test_app_with_channels, test_thread_session）；外部调用 8 个（Integer, from_millis, Char, new, new, assert!, assert_eq!, timeout）。

async fn enqueue_primary_thread_session_replays_turns_before_initial_prompt_submit() -> Result<()>

作用：确认恢复已有会话时，旧对话会先显示出来，然后才提交启动时用户预填的新消息。这样用户看到的顺序不会颠倒。

数据流：创建带初始用户消息的聊天组件 → 接入一个包含旧用户消息的线程会话 → 收集 AppEvent → 确认先插入了旧历史单元，再提交了初始 prompt 作为新的用户轮次。

调用关系：它测试 enqueue_primary_thread_session 的启动顺序。这个顺序很重要：如果先提交新消息再回放旧消息，界面会像时间线错乱。

调用图：调用 7 个内部函数（new, get_model_offline_for_tests, new, lines_to_single_string, make_test_app_with_channels, test_thread_session, test_dummy）；外部调用 6 个（new, assert!, assert_eq!, create_initial_user_message, new_with_app_event, vec!）。

async fn reset_thread_event_state_aborts_listener_tasks()

作用：确认重置线程事件状态时，后台监听任务会被取消。监听任务就是一直等事件的小工作线程，不取消会造成泄漏或重复收消息。

数据流：创建一个永远不结束的异步任务，并在任务被丢弃时发送通知 → 把它登记到 App 的线程监听任务表 → 调用 reset_thread_event_state → 检查任务表清空，并收到任务被取消的通知。

调用关系：它直接测试 App 的清理动作。重置状态通常发生在切换或重建线程事件系统时，这个测试保证旧监听不会残留。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 5 个（from_millis, assert_eq!, timeout, spawn, channel）。

async fn history_lookup_response_is_routed_to_requesting_thread() -> Result<()>

作用：确认查询历史记录的响应会带回请求它的线程 ID。这样多线程同时查历史时，不会把结果塞到错误聊天里。

数据流：输入线程 ID、偏移量和日志 ID → 调用 lookup_message_history_entry → 从 AppEvent 通道取出响应 → 检查响应里的线程 ID、offset、log_id 都和请求一致，且没有找到条目时 entry 为空。

调用关系：它测试历史查询的路由。App 发起查询后，结果通过 AppEvent::ThreadHistoryEntryResponse 回来，界面靠线程 ID 决定显示在哪里。

调用图：调用 2 个内部函数（new, make_test_app_with_channels）；外部调用 5 个（from_secs, assert!, assert_eq!, panic!, timeout）。

async fn enqueue_thread_event_does_not_block_when_channel_full() -> Result<()>

作用：确认线程事件通道满了时，继续塞事件不会卡死。卡死会让整个终端界面像被堵住的水管一样不响应。

数据流：创建容量只有 1 的线程事件通道并设为活动 → 连续塞入两个线程关闭通知 → 第二次塞入用超时包住，确认没有阻塞 → 再从接收端读出两个事件。

调用关系：它测试 enqueue_thread_notification 和 ThreadEventChannel 的缓冲策略。即使通道容量小，App 也要能安全排队或转存事件。

调用图：调用 4 个内部函数（new, make_test_app, thread_closed_notification, new）；外部调用 2 个（from_millis, timeout）。

async fn replay_thread_snapshot_restores_draft_and_queued_input()

作用：确认线程快照回放能恢复用户正在编辑的草稿，但不会把只有草稿的内容自动提交出去。

数据流：先在聊天框写入草稿并排入一个后续输入 → 捕获输入状态并保存到线程快照 → 换一个新的聊天组件 → 回放快照 → 检查草稿回到输入框，排队消息为空，并且没有自动发出 UserTurn 操作。

调用关系：它测试 store_active_thread_receiver 与 replay_thread_snapshot 的配合。快照就像临时存档，回放时必须恢复用户可见输入，但不能擅自替用户发送。

调用图：调用 4 个内部函数（new, make_test_app, test_thread_session, new_with_session）；外部调用 4 个（new, assert!, assert_eq!, make_chatwidget_manual_with_sender）。

async fn active_turn_id_for_thread_uses_snapshot_turns()

作用：确认 App 能从线程快照里的轮次列表判断当前正在运行的是哪一轮。轮次可以理解成一次用户提问和助手回答的完整回合。

数据流：创建一个线程通道，里面放入状态为 InProgress 的 turn-1 → 调用 active_turn_id_for_thread → 得到 Some("turn-1")。

调用关系：它测试 App 查询活动轮次的逻辑。后续恢复排队输入时，需要知道当前是否还有任务没完成。

调用图：调用 4 个内部函数（new, make_test_app, test_thread_session, new_with_session）；外部调用 2 个（assert_eq!, vec!）。

async fn replayed_turn_complete_submits_restored_queued_follow_up()

作用：确认如果回放证明上一轮已经完成，那么恢复出来的排队追问会自动提交。这样用户之前按下 Tab 排队的消息不会丢。

数据流：先模拟 turn-1 正在流式回答，用户输入“queued follow-up”并排队 → 捕获输入状态 → 换新聊天组件 → 回放一个 turn-1 完成通知，并允许恢复队列继续执行 → 检查发出了包含该文本的 UserTurn。

调用关系：它测试 replay_thread_snapshot 对“已完成轮次 + 恢复队列”的处理。完成通知是触发排队消息继续发送的关键。

调用图：调用 6 个内部函数（new, agent_message_delta_notification, make_test_app_with_channels, next_user_turn_op, test_thread_session, turn_started_notification）；外部调用 6 个（new, new, assert_eq!, make_chatwidget_manual_with_sender, panic!, vec!）。

async fn replay_only_thread_keeps_restored_queue_visible()

作用：确认只做回放、不继续运行的线程，会把恢复出的排队消息显示出来，但不会自动提交。

数据流：先造出一个正在运行时排队的 follow-up 输入状态 → 换新聊天组件 → 回放完成通知，但 resume_restored_queue 设为 false → 检查队列里仍显示这条消息，操作通道没有收到提交。

调用关系：它测试 replay_thread_snapshot 的“只看历史”模式。这个模式适合查看旧线程，不能偷偷继续执行用户原本排队的动作。

调用图：调用 5 个内部函数（new, agent_message_delta_notification, make_test_app_with_channels, test_thread_session, turn_started_notification）；外部调用 6 个（new, new, assert!, assert_eq!, make_chatwidget_manual_with_sender, vec!）。

async fn replay_thread_snapshot_keeps_queue_when_running_state_only_comes_from_snapshot()

作用：确认如果快照没有证明最新任务已经结束，恢复出的排队消息必须继续排着，不能提前提交。

数据流：先捕获一个在运行中排队的输入状态 → 回放一个没有 turn 列表、也没有完成事件的快照 → 检查 queued follow-up 仍在队列里，并且没有提交操作。

调用关系：它保护 replay_thread_snapshot 的保守策略。系统宁可让消息继续排队，也不能在不确定任务状态时提前发出去。

调用图：调用 5 个内部函数（new, agent_message_delta_notification, make_test_app_with_channels, test_thread_session, turn_started_notification）；外部调用 6 个（new, new, assert!, assert_eq!, make_chatwidget_manual_with_sender, vec!）。

async fn replay_thread_snapshot_in_progress_turn_restores_running_queue_state()

作用：确认快照明确说当前轮次还在运行时，恢复出的排队消息会保持排队状态。

数据流：先准备一条运行中的 turn-1 和一条排队 follow-up → 回放包含 InProgress turn-1 的快照 → 检查排队文本仍可见，没有自动提交。

调用关系：它测试 replay_thread_snapshot 读取 turns 状态的分支。只要当前轮次还没结束，chat_widget 就应该保持“任务正在跑，消息在排队”。

调用图：调用 5 个内部函数（new, agent_message_delta_notification, make_test_app_with_channels, test_thread_session, turn_started_notification）；外部调用 6 个（new, new, assert!, assert_eq!, make_chatwidget_manual_with_sender, vec!）。

async fn replay_thread_snapshot_in_progress_turn_restores_running_state_without_input_state()

作用：确认即使没有保存输入框状态，只要快照里有进行中的轮次，界面也会恢复成“任务正在运行”的状态。

数据流：创建新聊天组件并挂上线程会话 → 回放一个含 InProgress turn-1、但 input_state 为空的快照 → 检查聊天组件认为任务仍在运行。

调用关系：它测试任务状态恢复不完全依赖输入状态。线程事件本身也能告诉界面：现在还有活没干完。

调用图：调用 3 个内部函数（new, make_test_app_with_channels, test_thread_session）；外部调用 4 个（new, assert!, make_chatwidget_manual_with_sender, vec!）。

async fn replay_thread_snapshot_does_not_submit_queue_before_replay_catches_up()

作用：确认回放还没追到最新运行轮次结束前，排队消息不能提前提交；等真正收到完成通知后才提交。

数据流：先捕获运行中排队的输入状态 → 回放 turn-0 完成和 turn-1 开始事件 → 检查队列保留、没有提交 → 再手动送入 turn-1 完成通知 → 检查这时才发出 UserTurn。

调用关系：它测试回放进度和实时通知的衔接。系统必须等到最新 turn 确认结束，才能释放用户排队的下一条消息。

调用图：调用 7 个内部函数（new, agent_message_delta_notification, make_test_app_with_channels, next_user_turn_op, test_thread_session, turn_completed_notification, turn_started_notification）；外部调用 7 个（new, new, assert!, assert_eq!, make_chatwidget_manual_with_sender, panic!, vec!）。

async fn replay_thread_snapshot_restores_pending_pastes_for_submit()

作用：确认大段粘贴内容在恢复线程后还能正常提交。大段粘贴通常会被特殊暂存，容易在切换线程时丢失。

数据流：向聊天框粘贴 1005 个字符 → 捕获并保存输入状态到快照 → 换新聊天组件并回放快照 → 检查输入框仍显示完整粘贴内容 → 按 Enter 后检查提交的文本完整一致。

调用关系：它测试 pending paste 这类特殊输入状态和 replay_thread_snapshot 的配合。恢复后，用户按回车应和从未切换过线程一样。

调用图：调用 5 个内部函数（new, make_test_app_with_channels, next_user_turn_op, test_thread_session, new_with_session）；外部调用 5 个（new, new, assert_eq!, make_chatwidget_manual_with_sender, panic!）。

async fn replay_thread_snapshot_restores_collaboration_mode_for_draft_submit()

作用：确认草稿恢复时，连同当时选择的协作模式、模型和推理强度一起恢复，并用于后续提交。

数据流：先设置 Plan 模式、高推理强度和模型 gpt-restored，再写草稿并捕获状态 → 换成默认模式的新组件 → 回放旧状态 → 按 Enter → 检查提交操作使用旧草稿、旧模型、旧推理强度和 Plan 协作模式。

调用关系：它测试 input_state 不只是文字，还包含提交时的上下文设置。否则用户恢复草稿后可能不知不觉用错模型或模式。

调用图：调用 4 个内部函数（new, make_test_app_with_channels, next_user_turn_op, test_thread_session）；外部调用 6 个（new, new, assert_eq!, make_chatwidget_manual_with_sender, panic!, vec!）。

async fn replay_thread_snapshot_restores_collaboration_mode_without_input()

作用：确认即使没有草稿文字，恢复线程时也能恢复协作模式、模型和推理强度。

数据流：先设置 Plan 模式、模型 gpt-restored 和高推理强度并捕获状态 → 换成默认模式的新组件 → 回放状态 → 检查当前界面已切回 Plan、gpt-restored 和 High。

调用关系：它测试协作设置可以独立于输入文字被保存和恢复。这样切换线程时，每个线程自己的工作模式不会混在一起。

调用图：调用 3 个内部函数（new, make_test_app_with_channels, test_thread_session）；外部调用 4 个（new, assert_eq!, make_chatwidget_manual_with_sender, vec!）。

async fn replayed_interrupted_turn_restores_queued_input_to_composer()

作用：确认如果上一轮是被中断的，原本排队的输入会回到输入框让用户编辑，而不是自动发出去。

数据流：先模拟 turn-1 运行中，用户输入 follow-up 并提交到队列 → 捕获状态 → 回放 turn-1 Interrupted 完成状态 → 检查文本回到输入框，队列清空，没有提交操作。

调用关系：它测试中断场景下的安全行为。任务被打断时，系统不应假装一切正常继续发下一条，而应把控制权还给用户。

调用图：调用 5 个内部函数（new, agent_message_delta_notification, make_test_app_with_channels, test_thread_session, turn_started_notification）；外部调用 6 个（new, new, assert!, assert_eq!, make_chatwidget_manual_with_sender, vec!）。

async fn token_usage_update_refreshes_status_line_with_runtime_context_window()

作用：确认收到 token 使用量通知后，底部状态栏会显示运行时上下文窗口大小。token 可以理解成模型处理文字的计量单位。

数据流：先设置状态栏显示 ContextWindowSize → 初始状态栏为空 → 送入包含 950000 窗口大小的 token usage 通知 → 检查状态栏变成“950K window”。

调用关系：它测试 handle_thread_event_now 对 ServerNotification 的 UI 更新。后台告诉界面运行时窗口大小，聊天组件负责刷新底部文字。

调用图：调用 3 个内部函数（new, make_test_app, token_usage_notification）；外部调用 3 个（assert_eq!, Notification, vec!）。

async fn collab_receiver_notification_caches_thread_without_app_server_read()

作用：确认协作工具调用里提到的接收方线程，会被缓存到代理导航列表里，即使还没有从 App 服务端读取该线程详情。

数据流：构造一个 ItemStarted 通知，里面包含一个 CollabAgentToolCall 和 receiver_thread_id → 交给 App 处理 → 检查 agent_navigation 已出现这个接收线程，且带默认空元数据。

调用关系：它测试协作通知对代理列表的即时补全。这样用户能在选择器里看到被提到的子代理线程，而不用等后台读完。

调用图：调用 3 个内部函数（from_string, new, make_test_app）；外部调用 5 个（new, ItemStarted, assert_eq!, Notification, vec!）。

async fn collab_receiver_notification_does_not_cache_not_found_thread()

作用：确认如果协作工具结果明确说接收方线程不存在，就不要把它加入代理导航列表。

数据流：构造一个 ItemCompleted 通知，工具调用状态失败，并在 agents_states 里标记 receiver_thread_id 为 NotFound → 交给 App 处理 → 检查 agent_navigation 没有这个线程。

调用关系：它测试协作通知的过滤逻辑。不是所有被提到的线程都应该显示，明确不存在的要忽略。

调用图：调用 3 个内部函数（from_string, new, make_test_app）；外部调用 5 个（from, ItemCompleted, assert_eq!, Notification, vec!）。

async fn open_agent_picker_keeps_missing_threads_for_replay() -> Result<()>

作用：确认打开代理选择器时，本地已有但服务端暂时读不到的线程不会被删掉，而是标为已关闭、可回放。

数据流：创建测试 App 和内嵌 App 服务端 → 手动放入一个线程事件通道 → 打开代理选择器 → 检查通道还在，导航条目存在，is_closed 为 true，并按顺序列出。

调用关系：它测试 open_agent_picker 的刷新策略。选择器打开时会向服务端同步线程状态，但不能因为临时读不到就丢掉本地可回放历史。

调用图：调用 3 个内部函数（new, make_test_app, new）；外部调用 3 个（pin, assert_eq!, start_embedded_app_server_for_picker）。

async fn open_agent_picker_preserves_cached_metadata_for_replay_threads() -> Result<()>

作用：确认回放线程在打开代理选择器后，原来缓存的昵称和角色不会被抹掉。

数据流：先放入线程通道，并在 agent_navigation 里写入 Robie/explorer → 打开代理选择器 → 检查线程仍在，昵称和角色仍保持，且标为关闭。

调用关系：它测试 open_agent_picker 对本地元数据的保护。服务端缺少信息时，界面应保留用户已经看到过的描述。

调用图：调用 3 个内部函数（new, make_test_app, new）；外部调用 3 个（pin, assert_eq!, start_embedded_app_server_for_picker）。

async fn open_agent_picker_clears_completed_path_backed_agent_running_state() -> Result<()>

作用：确认基于路径记录的子代理，如果快照显示任务已完成，打开选择器时要清掉“正在运行”的显示。

数据流：在线程存储里放入 turn started 和 completed 通知 → 记录一个带 agent_path 且提示正在运行的子代理活动 → 打开代理选择器 → 检查该条目的 is_running 变为 false，路径保留。

调用关系：它测试选择器刷新时会根据线程事件重新判断活跃状态，而不是永远相信旧的 running hint。

调用图：调用 5 个内部函数（new, make_test_app, turn_completed_notification, turn_started_notification, new）；外部调用 3 个（pin, assert_eq!, start_embedded_app_server_for_picker）。

async fn open_agent_picker_refreshes_replay_only_path_backed_liveness() -> Result<()>

作用：确认只用于回放的路径型子代理，打开选择器时会被标成关闭，并且不显示正在运行。

数据流：创建 replay-only 线程通道，里面只有 turn started 通知 → 记录路径型子代理活动 → 打开代理选择器 → 检查条目路径保留、is_running 为 false、is_closed 为 true。

调用关系：它测试 replay-only 通道在代理选择器里的展示规则。只能看历史的线程不应该显示成还活着。

调用图：调用 4 个内部函数（new, make_test_app, turn_started_notification, new）；外部调用 3 个（pin, assert_eq!, start_embedded_app_server_for_picker）。

async fn open_agent_picker_prunes_terminal_metadata_only_threads() -> Result<()>

作用：确认只有元数据、没有本地通道也没有服务端可读内容的终止线程，会在打开代理选择器时被清理掉。

数据流：只在 agent_navigation 里放入 Ghost/worker，没有线程通道 → 打开代理选择器 → 检查该条目被删除，导航列表为空。

调用关系：它测试 open_agent_picker 的清理规则。没有可回放内容、也无法实时连接的幽灵条目不该继续占位置。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 4 个（pin, assert!, assert_eq!, start_embedded_app_server_for_picker）。

async fn open_agent_picker_marks_terminal_read_errors_closed() -> Result<()>

作用：确认打开代理选择器时，如果线程读不到但本地有通道和元数据，就把它标为关闭，而不是删掉。

数据流：放入一个线程通道，并缓存 Robie/explorer 元数据且标为未关闭 → 打开代理选择器 → 检查条目仍在，但 is_closed 变为 true。

调用关系：它测试读服务端失败时的降级行为。只要本地还有回放资料，用户仍应该能看到它。

调用图：调用 3 个内部函数（new, make_test_app, new）；外部调用 3 个（pin, assert_eq!, start_embedded_app_server_for_picker）。

fn open_agent_picker_marks_loaded_threads_open() -> Result<()>

作用：确认服务端能正常加载到的线程，在代理选择器里会显示为未关闭。

数据流：创建 Tokio 运行时 → 启动测试 App 和内嵌服务端 → 在服务端启动一个线程，并在 App 里放入对应通道 → 打开代理选择器 → 检查该线程 is_closed 为 false。

调用关系：它用真实异步运行时测试 open_agent_picker 和内嵌服务端的配合。能 live attach 的线程应该显示成打开状态。

调用图：调用 2 个内部函数（make_test_app, new）；外部调用 4 个（pin, assert_eq!, start_embedded_app_server_for_picker, new_multi_thread）。

fn attach_live_thread_for_selection_rejects_empty_non_ephemeral_fallback_threads() -> Result<()>

作用：确认选择一个只有元数据、但没有可回放内容的普通线程时，App 不会创建一个空白的假线程。

数据流：服务端启动一个普通线程，但新 App 只缓存它的导航元数据 → 尝试 attach_live_thread_for_selection → 得到错误信息 → 检查没有创建线程事件通道。

调用关系：它测试 attach_live_thread_for_selection 的防呆逻辑。没有实际历史或实时材料时，宁可报错，也不能让用户看到空白误导页面。

调用图：调用 1 个内部函数（make_test_app）；外部调用 4 个（assert!, assert_eq!, start_embedded_app_server_for_picker, new_multi_thread）。

fn attach_live_thread_for_selection_rejects_unmaterialized_fallback_threads() -> Result<()>

作用：确认选择一个未真正落地的临时线程时，也不会附加成空白 live 线程。

数据流：用 ephemeral 配置在服务端启动临时线程 → App 只缓存它的导航元数据 → 尝试附加 → 得到“不可回放或实时附加”的错误 → 检查没有创建通道。

调用关系：它补充测试临时线程场景。attach_live_thread_for_selection 必须确认线程确实可用，不能只凭导航条目。

调用图：调用 1 个内部函数（make_test_app）；外部调用 4 个（assert!, assert_eq!, start_embedded_app_server_for_picker, new_multi_thread）。

async fn should_attach_live_thread_for_selection_skips_closed_metadata_only_threads()

作用：检查 App 判断“是否应该尝试实时附加某线程”的规则：关闭的纯元数据线程跳过，打开的可尝试，已有本地通道的也跳过。

数据流：先插入一个关闭的 metadata-only 线程 → 判断为 false → 改成未关闭 → 判断为 true → 再给它加线程通道 → 判断又变成 false。

调用关系：它测试 should_attach_live_thread_for_selection 这个小决策函数。open_agent_picker 或选择线程时会依赖这个判断，避免多余或错误的附加。

调用图：调用 3 个内部函数（new, make_test_app, new）；外部调用 1 个（assert!）。

async fn refresh_agent_picker_thread_liveness_prunes_closed_metadata_only_threads() -> Result<()>

作用：确认刷新某个代理线程活跃状态时，如果它只是无效元数据，就会被移除。

数据流：只在 agent_navigation 中插入 Ghost/worker → 调用 refresh_agent_picker_thread_liveness → 返回不可用 → 检查导航项被删，且没有线程通道。

调用关系：它测试 open_agent_picker 里更细的一步刷新逻辑。单个线程被判定不可用时，导航列表要同步清理。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 4 个（pin, assert!, assert_eq!, start_embedded_app_server_for_picker）。

async fn open_agent_picker_prompts_to_enable_multi_agent_when_disabled() -> Result<()>

作用：确认当多代理功能被关闭时，打开代理选择器会提示用户启用，而不是直接进入不可用界面。

数据流：创建带事件通道的 App → 禁用 Collab 功能 → 打开代理选择器并按 Enter → 检查发出启用 Collab 的功能开关事件，再检查历史里出现“下次会话启用子代理”的提示。

调用关系：它测试功能开关和 UI 提示的衔接。open_agent_picker 发现功能关闭后，会通过聊天组件让用户确认启用。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 6 个（pin, new, assert!, assert_matches!, start_embedded_app_server_for_picker, panic!）。

async fn update_memory_settings_persists_and_updates_widget_config() -> Result<()>

作用：确认从 TUI 菜单修改记忆设置时，会同时写入配置文件，并更新 App 和聊天组件里的当前配置。

数据流：创建临时 codex_home → 调用 update_memory_settings_with_app_server 关闭 use_memories 和 generate_memories → 检查 App 配置、聊天组件配置都变成 false → 读取 config.toml，确认只写入这两个 memories 字段，没有写外部上下文相关字段。

调用关系：它测试设置菜单、配置保存和 app_server 的配合。用户改设置后，界面和磁盘文件必须一致。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 6 个（pin, assert!, assert_eq!, start_embedded_app_server_for_picker, read_to_string, tempdir）。

fn update_memory_settings_updates_current_thread_memory_mode() -> Result<()>

作用：确认修改记忆生成设置时，当前正在使用的线程也会更新自己的记忆模式。

数据流：创建临时状态目录，并把旧设置设成 generate_memories=true → 启动服务端和线程，把该线程设为 active → 调用 update_memory_settings_with_app_server，关闭生成记忆 → 打开状态数据库读取该线程 memory_mode，确认是 disabled。

调用关系：它测试全局设置变更对当前线程状态库的影响。否则用户关掉记忆生成后，当前线程可能还继续按旧规则保存记忆。

调用图：调用 2 个内部函数（init, make_test_app_with_channels）；外部调用 5 个（pin, assert_eq!, start_embedded_app_server_for_picker, tempdir, new_multi_thread）。

async fn reset_memories_clears_local_memory_directories() -> Result<()>

作用：确认“重置记忆”会清空本地记忆目录里的旧文件和子目录内容。

数据流：在临时 codex_home 下手动创建 memories、rollout_summaries、extensions 和几个旧文件 → 启动服务端 → 调用 reset_memories_with_app_server → 检查 memories 目录已经空了。

调用关系：它测试重置记忆菜单项的磁盘清理效果。App 通过 app_server 执行重置，最后必须真的删掉本地残留。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 6 个（pin, assert_eq!, start_embedded_app_server_for_picker, create_dir_all, write, tempdir）。

async fn apply_permission_profile_selection_preserves_loader_overrides() -> Result<()>

作用：确认切换权限配置时，会保留启动加载器的覆盖项，并把新权限同步到 App、聊天组件和当前回合上下文。

数据流：创建临时配置文件，定义 locked-down 权限档案 → 设置 loader_overrides 和 harness_overrides → 调用 apply_permission_profile_selection → 检查 App 与 chat_widget 的活动权限都是 locked-down，运行时权限覆盖被更新 → 再检查发出的 OverrideTurnContext 操作和提示历史单元。

调用关系：它测试权限菜单选择后的完整链路。权限不仅要改配置，还要通知正在运行的模型回合，否则后台仍会按旧权限行动。

调用图：调用 2 个内部函数（workspace_write, make_test_app_with_channels）；外部调用 5 个（assert!, assert_eq!, panic!, write, tempdir）。

async fn update_feature_flags_enabling_guardian_selects_auto_review() -> Result<()>

作用：测试打开 GuardianApproval 功能时，应用会自动切到“自动评审”模式。这里的“自动评审”就是让系统按预设方式替用户处理权限审批，而不是继续保持原来的人工选择。

数据流：测试先创建一个假 App 和临时配置目录，再调用 update_feature_flags 打开 GuardianApproval。之后它检查内存里的配置、聊天窗口里的配置、运行时覆盖设置、发给后端的 OverrideTurnContext 操作，以及写入 config.toml 的内容，确认都从普通状态变成自动评审所需的审批策略、权限配置和 reviewer。

调用关系：这是由异步测试运行器直接执行的场景测试。它用 make_test_app_with_channels 搭好带消息通道的 App，用 start_config_write_test_app_server 提供可写配置的假服务端，然后把真正要测的动作交给 app.update_feature_flags。

调用图：调用 2 个内部函数（make_test_app_with_channels, start_config_write_test_app_server）；外部调用 6 个（assert!, assert_eq!, panic!, read_to_string, tempdir, vec!）。

async fn update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default() -> Result<()>

作用：测试关闭 GuardianApproval 时，应用会清掉 Guardian 专用的评审人设置，并恢复到默认人工审批状态。这样可以避免用户关了功能，配置文件里还残留会影响行为的旧开关。

数据流：测试先写入一份带 guardian_approval、auto review、on-request 和 workspace-write 的配置，再把 App 和聊天窗口都伪装成 Guardian 已开启。调用 update_feature_flags 关闭功能后，它检查功能标记变成关闭，reviewer 回到 User，发给后端的覆盖只保留 reviewer 恢复信息，并确认 config.toml 删除 guardian_approval 和 approvals_reviewer，但保留原有审批策略和沙箱设置。

调用关系：测试运行器启动它后，它通过 make_test_app_with_channels 和 start_config_write_test_app_server 造环境，核心行为仍由 app.update_feature_flags 完成。测试同时观察 app_event_rx 和 op_rx，确认界面提示和后端操作都符合预期。

调用图：调用 4 个内部函数（legacy, workspace_write, make_test_app_with_channels, start_config_write_test_app_server）；外部调用 7 个（assert!, assert_eq!, panic!, read_to_string, write, tempdir, vec!）。

async fn update_feature_flags_enabling_guardian_overrides_explicit_manual_review_policy() -> Result<()>

作用：测试即使用户配置里明确写了手动评审人，打开 GuardianApproval 后也会被自动评审模式覆盖。重点是确认功能开关的含义比旧的手动 reviewer 配置更优先。

数据流：测试先把 config.toml 写成 approvals_reviewer = user，并让 App 和聊天窗口也处于 User 状态。打开 GuardianApproval 后，它检查 App、聊天窗口和发给后端的上下文都改成 auto_review 对应的审批策略和权限配置，最后确认配置文件也写入了 auto_review、guardian_approval、on-request 和 workspace-write。

调用关系：它是针对 update_feature_flags 的一个优先级测试。前置状态由 make_test_app_with_channels、临时配置文件和假配置写入服务端准备，结果通过 op_rx 和磁盘配置文件一起验证。

调用图：调用 2 个内部函数（make_test_app_with_channels, start_config_write_test_app_server）；外部调用 6 个（assert!, assert_eq!, read_to_string, write, tempdir, vec!）。

async fn update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history() -> Result<()>

作用：测试关闭 GuardianApproval 时，如果实际状态本来就是默认人工评审，就不要多插一条“权限变化”的历史消息。这样界面不会因为没有实际变化而打扰用户。

数据流：测试先准备一份配置：Guardian 开着，但 reviewer 是 user。关闭功能后，它检查 Guardian 标记关闭、reviewer 仍是 User、后端收到恢复 User 的上下文覆盖，同时 app_event_rx 没有收到历史消息。最后它确认配置文件里 guardian_approval 和 approvals_reviewer 都被删掉。

调用关系：这个测试同样围绕 app.update_feature_flags，但更关注“不要发多余 UI 提示”。它通过 app_event_rx 验证没有历史更新，通过 op_rx 验证后端仍收到必要的上下文调整。

调用图：调用 2 个内部函数（make_test_app_with_channels, start_config_write_test_app_server）；外部调用 6 个（assert!, assert_eq!, read_to_string, write, tempdir, vec!）。

async fn open_agent_picker_allows_existing_agent_threads_when_feature_is_disabled() -> Result<()>

作用：测试即使某个相关功能开关关闭，已有的代理线程仍然可以从代理选择器里选中。换句话说，关闭新功能不能让用户失去回到旧线程的入口。

数据流：测试创建 App、嵌入式假服务端和一个已存在的线程通道，然后打开代理选择器并模拟按下 Enter。最后它从事件通道里读到 SelectAgentThread，确认选中的就是刚才已有的线程。

调用关系：测试运行器调用它后，它把流程交给 app.open_agent_picker，再由 chat_widget.handle_key_event 模拟用户选择。结果通过 AppEvent::SelectAgentThread 回到 app_event_rx。

调用图：调用 3 个内部函数（new, make_test_app_with_channels, new）；外部调用 4 个（pin, new, assert_matches!, start_embedded_app_server_for_picker）。

async fn refresh_pending_thread_approvals_only_lists_inactive_threads()

作用：测试“待审批线程列表”只显示非当前活动线程。当前正在看的线程不需要在旁边再挂一个提醒徽标。

数据流：测试创建主线程和代理线程，把主线程设为当前活动线程，并在代理线程里塞入一个命令审批请求。刷新待审批列表后，聊天窗口显示 Robie [explorer]。然后把活动线程切到代理线程，再刷新，列表就变空。

调用关系：它直接测试 app.refresh_pending_thread_approvals。待审批数据来自 ThreadEventChannel 的内部存储，显示名称来自 agent_navigation 中登记的代理昵称和角色。

调用图：调用 4 个内部函数（from_string, exec_approval_request, make_test_app, new）；外部调用 2 个（assert!, assert_eq!）。

async fn inactive_thread_approval_bubbles_into_active_view() -> Result<()>

作用：测试非当前线程发来的审批请求，会冒泡到当前界面里让用户能处理，同时也显示待审批线程提示。这样后台代理卡住时，用户不会完全不知道。

数据流：测试把主线程设为当前活动线程，给代理线程建立会话状态并登记名字。随后向代理线程加入一个命令审批请求。结果是聊天窗口出现活动审批视图，同时待审批列表里显示 Robie [explorer]。

调用关系：它通过 app.enqueue_thread_request 模拟服务端给后台线程发来请求。App 内部会把请求转换成交互审批，再更新 chat_widget 的活动视图和待审批提示。

调用图：调用 7 个内部函数（workspace_write, from_string, exec_approval_request, make_test_app, test_thread_session, new, new_with_session）；外部调用 2 个（new, assert_eq!）。

async fn side_defers_parent_approval_overlay_until_parent_replay() -> Result<()>

作用：测试当用户正在旁路对话里时，父线程的审批请求不会立刻覆盖当前旁路界面。它只会记录父线程“需要审批”，等用户回到父线程并重放快照时才显示审批界面。

数据流：测试创建父线程和旁路线程，把当前活动线程设为旁路线程。父线程收到审批请求后，聊天窗口没有活动审批视图，也没有普通待审批列表，但旁路线程状态标记为 NeedsApproval。之后测试移除旁路状态、切回父线程并重放父线程快照，审批视图才出现。

调用关系：它通过 app.enqueue_thread_request 模拟父线程请求，通过 ThreadEventChannel 的 snapshot 取出父线程历史，再交给 app.replay_thread_snapshot。这个测试保护的是旁路对话和父线程审批之间的切换规则。

调用图：调用 6 个内部函数（from_string, new, exec_approval_request, make_test_app, test_thread_session, new_with_session）；外部调用 3 个（new, assert!, assert_eq!）。

async fn replay_snapshot_with_pending_request_suppresses_replay_notices()

作用：测试重放线程快照时，如果快照里已经有待处理审批，就不要先显示过期警告之类的提示。这样真正需要用户操作的审批不会被旧通知挡住。

数据流：测试构造一个快照，里面先放一个 Warning 通知，再放一个审批请求。重放后聊天窗口有活动审批视图。随后它把事件通道里的历史消息都收集起来，确认没有插入那条旧 warning 的展示内容。

调用关系：它直接调用 app.replay_thread_snapshot。辅助函数 lines_to_single_string 只用来把历史单元渲染成字符串，方便确认没有不该出现的重放提示。

调用图：调用 4 个内部函数（from_string, lines_to_single_string, make_test_app_with_channels, test_thread_session）；外部调用 5 个（new, new, assert!, assert_eq!, vec!）。

async fn side_defers_subagent_approval_overlay_until_side_exits() -> Result<()>

作用：测试用户在旁路对话中时，子代理线程的审批不会立刻弹出覆盖层，但会显示待审批提示；等退出旁路后才真正弹出审批界面。这样旁路对话不会被后台代理突然打断。

数据流：测试创建主线程、旁路线程和代理线程，把当前活动线程设为旁路线程。代理线程收到审批请求后，聊天窗口没有活动审批视图，但待审批列表有 Robie [explorer]。当测试移除旁路状态、切回主线程，并调用 surface_pending_inactive_thread_interactive_requests 后，活动审批视图出现。

调用关系：它用 app.enqueue_thread_request 放入后台审批，用 app.surface_pending_inactive_thread_interactive_requests 模拟离开旁路后把挂起请求浮到前台。

调用图：调用 7 个内部函数（workspace_write, from_string, new, exec_approval_request, make_test_app, test_thread_session, new_with_session）；外部调用 2 个（new, assert_eq!）。

async fn inactive_thread_exec_approval_preserves_context()

作用：测试后台线程的命令执行审批会保留关键上下文，比如网络审批信息、额外文件权限和可选择的网络策略修改。没有这些信息，用户看到审批时就可能无法做出正确决定。

数据流：测试先造一个命令审批请求，再手动塞入 Socks5 网络上下文、读写目录权限和允许 example.com 的网络策略修正。调用 interactive_request_for_thread_request 后，它取出生成的 Exec 审批对象，检查这些上下文都原样保留，并且可选决定里包含接受、会话内接受、应用网络策略修改和取消。

调用关系：这个测试直接验证 App 把 ServerRequest 转成 ThreadInteractiveRequest 的转换逻辑。它不走完整界面，只检查 app.interactive_request_for_thread_request 的输出是否完整。

调用图：调用 3 个内部函数（new, exec_approval_request, make_test_app）；外部调用 3 个（assert_eq!, panic!, vec!）。

async fn inactive_thread_exec_approval_splits_shell_wrapped_command()

作用：测试后台线程的命令审批能把 shell 包装命令拆回用户能看懂的参数列表。比如“/bin/zsh -lc 脚本”不能变成一团难读字符串。

数据流：测试把一个 python 脚本包成 /bin/zsh -lc 的命令字符串，塞进命令审批请求。转换成交互审批后，它检查 command 被拆成三个部分：shell 路径、-lc、原始脚本。

调用关系：它调用 app.interactive_request_for_thread_request 来验证请求转换。shlex::try_join 用来构造一个符合 shell 转义规则的输入字符串。

调用图：调用 3 个内部函数（new, exec_approval_request, make_test_app）；外部调用 3 个（assert_eq!, panic!, try_join）。

async fn inactive_thread_file_change_approval_recovers_buffered_changes()

作用：测试后台线程申请批准文件改动时，App 能从之前缓存的文件变更通知里找回具体 diff。这样审批界面能展示“要改哪个文件、改了什么”，而不是只给一个空请求。

数据流：测试先给某线程加入一个 FileChange 开始通知，表示 README.md 要新增 hello。随后构造一个 FileChangeRequestApproval。转换请求后，它检查得到的是 ApplyPatch 审批，里面包含 README.md 的新增内容和失败重试原因。最后把审批推到界面，确认历史单元能显示新增文件和 diff 行。

调用关系：它先用 app.enqueue_thread_notification 缓存文件改动，再用 app.interactive_request_for_thread_request 从缓存恢复审批内容，最后用 app.push_thread_interactive_request 推进聊天界面。

调用图：调用 3 个内部函数（new, lines_to_single_string, make_test_app_with_channels）；外部调用 6 个（Integer, ItemStarted, assert!, assert_eq!, panic!, vec!）。

async fn inactive_thread_permissions_approval_preserves_file_system_permissions()

作用：测试后台线程请求额外权限时，文件系统权限不会在转换过程中丢失。这里包括哪些目录可读、哪些目录可写，以及网络是否启用。

数据流：测试构造一个 PermissionsRequestApproval，请求 remote 环境、/tmp/read-only 读权限、/tmp/write 写权限和网络开启。转换成交互审批后，它检查 environment_id 仍是 remote，权限对象也准确表达相同的读写根目录和网络设置。

调用关系：它专门覆盖 app.interactive_request_for_thread_request 对 PermissionsRequestApproval 的转换。输入是服务端协议对象，输出是界面层能展示和处理的 ApprovalRequest::Permissions。

调用图：调用 3 个内部函数（new, make_test_app, test_absolute_path）；外部调用 4 个（Integer, assert_eq!, panic!, vec!）。

async fn inactive_thread_url_elicitation_routes_to_app_link()

作用：测试后台线程发来的安全 HTTPS 链接请求会变成 AppLink，也就是界面里可点击的“需要操作”链接。这样外部服务需要用户打开网页确认时，App 能正确引导用户。

数据流：测试构造一个 MCP 服务的 Url elicitation 请求，链接是 https://payments.example。转换后，它检查标题是 Action required，描述里写了服务名 payments，URL 原样保留，并且携带 thread_id、server_name 和 request_id，方便用户操作后回传结果。

调用关系：它验证 app.interactive_request_for_thread_request 对 McpServerElicitationRequest::Url 的路由。合法 HTTPS 链接会进入 ThreadInteractiveRequest::AppLink。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 3 个（Integer, assert_eq!, panic!）。

async fn inactive_thread_invalid_url_elicitation_is_declined()

作用：测试后台线程发来的不安全 URL 会被自动拒绝。这里用的是 http 链接，不是 https，所以 App 不应该把它显示成可点击操作。

数据流：测试构造一个 http://payments.example 的 Url elicitation 请求。转换函数返回 None，表示不生成界面请求；同时事件通道收到 SubmitThreadOp，里面是 ResolveElicitation 的 Decline 决定，说明 App 已经替用户拒绝这次不安全请求。

调用关系：它通过 app.interactive_request_for_thread_request 触发校验，再通过 app_event_rx 验证拒绝操作被提交给对应线程。assert_matches 用来确认事件内容完全匹配。

调用图：调用 2 个内部函数（new, make_test_app_with_channels）；外部调用 3 个（Integer, assert!, assert_matches!）。

async fn inactive_thread_approval_badge_clears_after_turn_completion_notification() -> Result<()>

作用：测试后台线程的待审批徽标会在该轮任务结束时立刻清掉。否则用户会看到一个已经过期的“还要审批”的提醒。

数据流：测试先让代理线程收到一个命令审批请求，确认待审批列表显示 Robie [explorer]。然后给同一线程发送 turn completed 通知。之后待审批列表变空，说明结束通知清理了旧审批提示。

调用关系：它用 app.enqueue_thread_request 产生待审批状态，再用 app.enqueue_thread_notification 发送完成通知。聊天窗口的 pending_thread_approvals 是最终被验证的 UI 状态。

调用图：调用 8 个内部函数（workspace_write, from_string, exec_approval_request, make_test_app, test_thread_session, turn_completed_notification, new, new_with_session）；外部调用 3 个（new, assert!, assert_eq!）。

async fn inactive_thread_started_notification_initializes_replay_session() -> Result<()>

作用：测试后台代理线程收到 ThreadStarted 通知时，App 能为它建立可重放的会话状态。这样用户稍后切过去时，系统知道这个线程的目录、模型、权限和工作区范围。

数据流：测试先准备主线程会话，包含审批策略、workspace-write 权限和两个工作区根目录。然后写一个 rollout 文件，里面记录代理线程使用的 cwd 和模型。发送 ThreadStarted 通知后，它从代理线程通道的 store 里取出推断出的 session，检查线程名、模型、模型提供方、审批策略、cwd、工作区根目录、rollout 路径都正确，并确认 agent_navigation 登记了 Robie [explorer]。

调用关系：它通过 app.enqueue_thread_notification 模拟服务端宣布新线程。App 内部会读取 ThreadStartedNotification 和 rollout 文件，再初始化 ThreadEventChannel 的 session 与代理选择器条目。

调用图：调用 5 个内部函数（workspace_write, from_string, make_test_app, test_thread_session, new_with_session）；外部调用 8 个（ThreadStarted, new, assert_eq!, format!, json!, write, tempdir, vec!）。

async fn inactive_thread_started_notification_preserves_primary_model_when_path_missing() -> Result<()>

作用：测试后台线程启动通知里没有历史文件路径时，不要乱改模型，而是沿用主线程的模型。这样缺少 rollout 文件时也有稳定的默认设置。

数据流：测试创建一个主线程会话，并把它保存为 primary_session_configured。随后发送一个代理线程 ThreadStarted 通知，但 path 是 None。最后从代理线程 store 里取出推断 session，确认 session.model 等于主线程的 model。

调用关系：它仍然通过 app.enqueue_thread_notification 触发后台线程会话初始化。和前一个测试相比，这里重点是缺少 path 时的回退规则。

调用图：调用 5 个内部函数（workspace_write, from_string, make_test_app, test_thread_session, new_with_session）；外部调用 4 个（ThreadStarted, new, assert_eq!, vec!）。

async fn thread_read_session_state_does_not_reuse_primary_permission_profile()

作用：测试读取某个线程信息时，不会错误复用主线程缓存的权限配置。因为 thread/read 返回的信息不一定带最新权限，回退时应使用当前界面配置，而不是旧主线程会话。

数据流：测试先把 primary_session_configured 设置成 workspace-write 权限，再构造一个新的 read thread。调用 session_state_for_thread_read 后，它检查线程 id、cwd、工作区根目录来自被读取线程；权限配置则等于当前聊天窗口配置里的权限，而不是 primary_session_configured 里的权限。

调用关系：它直接测试 app.session_state_for_thread_read。这个函数处在“服务端线程信息”转换成“本地会话状态”的入口处，测试防止权限从错误来源继承。

调用图：调用 4 个内部函数（workspace_write, from_string, make_test_app, test_thread_session）；外部调用 3 个（new, assert_eq!, vec!）。

fn agent_picker_item_name_snapshot()

作用：测试代理选择器里条目的显示名字保持稳定。它用快照测试记录不同昵称、角色、主线程标记组合下应该显示成什么样。

数据流：测试固定一个线程 id，然后分别调用 format_agent_picker_item_name 生成五种名称：有昵称有角色且是主线程、有昵称有角色但不是主线程、只有昵称、只有角色、都没有。它把结果拼成多行字符串，并交给 assert_app_snapshot 与保存的快照比对。

调用关系：这是一个纯显示格式测试，不启动 App。它保护 format_agent_picker_item_name 的输出，避免以后改动让选择器里的名字意外变化。

调用图：调用 1 个内部函数（from_string）；外部调用 2 个（assert_app_snapshot!, format!）。

async fn side_fork_config_is_ephemeral_and_appends_developer_guardrails()

作用：测试创建旁路对话的配置是临时的，并且会追加开发者护栏提示。旁路对话像“临时岔路聊天”，不能误以为自己能继续执行主线程任务或随便改文件。

数据流：测试从 App 当前配置里记下原审批策略和沙箱策略，然后调用 side_fork_config。它检查 fork_config.ephemeral 为真，审批和沙箱策略继承原值，并且 developer_instructions 里包含多条约束：这是旁路对话、继承历史只作参考、不能继续任务、外部工具输出只作参考、只做非破坏性检查、不要改文件、不要请求升级权限。最后确认 App 自身 transcript_cells 没被改动。

调用关系：它直接验证 app.side_fork_config。这个函数会被创建旁路对话的流程使用，本测试确保生成配置时既继承必要设置，又加上安全边界。

调用图：调用 1 个内部函数（make_test_app）；外部调用 2 个（assert!, assert_eq!）。

async fn side_fork_config_inherits_parent_thread_runtime_settings()

作用：测试旁路对话会继承父线程当前正在用的运行时设置，而不是只拿磁盘里的默认配置。比如模型、推理强度、服务档位、审批方式和权限配置都应该跟当前父线程一致。

数据流：测试先把持久配置设成一个默认模型，再把聊天窗口当前状态改成父线程模型、高推理强度、Fast 服务档位、on-request 审批、workspace-write 权限和 AutoReview。调用 side_fork_config 后，它检查生成的 fork_config 全部使用父线程当前值。

调用关系：它验证 app.side_fork_config 对 chat_widget 当前配置的读取。旁路对话启动时会用这个配置，所以测试确保不会错误回退到旧的 app.config 默认值。

调用图：调用 3 个内部函数（legacy, workspace_write, make_test_app）；外部调用 1 个（assert_eq!）。

async fn side_start_block_message_tracks_open_side_conversation()

作用：测试 /side 命令什么时候应该被拦住，并返回清楚的提示。没有主线程时不能开旁路；已经有旁路对话时也不能再开一个。

数据流：测试一开始没有 primary_thread_id，side_start_block_message 返回“主线程未就绪”。设置 primary_thread_id 后返回 None，表示可用。再登记一个已打开旁路线程后，返回“已有旁路对话，请先 Ctrl+C 返回”。移除旁路线程后又返回 None。

调用关系：它直接测试 app.side_start_block_message。这个函数会被 /side 命令入口用来决定是否允许创建旁路对话，以及给用户显示什么阻止原因。

调用图：调用 3 个内部函数（new, new, make_test_app）；外部调用 1 个（assert_eq!）。

async fn side_parent_status_tracks_parent_turn_lifecycle() -> Result<()>

作用：测试用户在旁路对话里时，父线程的运行状态会被正确记录：完成、开始新一轮、失败。这样旁路界面可以知道父线程那边发生了什么。

数据流：测试创建父线程和旁路线程，并让当前活动线程是旁路。父线程收到 completed 通知后，旁路状态变成 Finished；收到 turn started 后，父状态清空；再收到 failed 完成通知后，父状态变成 Failed。

调用关系：它通过 app.enqueue_thread_notification 向父线程送入 turn_started 和 turn_completed 通知。App 处理通知时会更新 side_threads 里对应 SideThreadState 的 parent_status。

调用图：调用 5 个内部函数（new, new, make_test_app, turn_completed_notification, turn_started_notification）；外部调用 1 个（assert_eq!）。

async fn side_parent_status_prioritizes_input_over_approval() -> Result<()>

作用：测试父线程同时需要审批和需要用户输入时，旁路状态优先显示“需要输入”。因为用户输入通常比审批更像正在等待人的直接回复。

数据流：测试先给父线程加入审批请求，parent_status 变为 NeedsApproval。再加入用户输入请求，parent_status 变为 NeedsInput。随后模拟输入请求被解决，状态退回 NeedsApproval；再模拟审批请求被解决，状态清空。

调用关系：它用 app.enqueue_thread_request 放入两类请求，再用 ServerRequestResolved 通知逐个清除。这个测试保护 side_threads 状态汇总的优先级规则。

调用图：调用 5 个内部函数（new, new, exec_approval_request, make_test_app, request_user_input_request）；外部调用 3 个（Integer, ServerRequestResolved, assert_eq!）。

async fn side_thread_snapshot_hides_forked_parent_transcript()

作用：测试安装旁路线程快照时，会隐藏从父线程继承来的历史内容。旁路对话可以参考父线程上下文，但界面里不应该把父线程原始对话当作旁路自己的聊天记录展示。

数据流：测试创建一个 ThreadEventStore、一个标记 forked_from_id 的旁路线程 session，以及一轮父线程用户消息。调用 App::install_side_thread_snapshot 后，它检查存储里的 session 仍是旁路线程，但 forked_from_id 被清掉，turns 为空，也没有活动 turn。

调用关系：它直接测试 App::install_side_thread_snapshot。这个函数负责把旁路线程快照放进事件存储，同时过滤掉不该展示的父线程 fork 历史。

调用图：调用 4 个内部函数（new, test_thread_session, test_turn, new）；外部调用 3 个（assert_eq!, install_side_thread_snapshot, vec!）。

async fn side_thread_snapshot_does_not_refresh_from_fork_history()

作用：测试旁路线程快照不会因为 fork 历史而触发会话刷新。旁路对话的父线程历史只是参考，不应该反过来刷新当前会话配置。

数据流：测试把一个旁路线程登记到 app.side_threads，然后构造一个普通空快照。调用 should_refresh_snapshot_session 后，结果是 false，说明不需要基于这个快照刷新 session。

调用关系：它直接验证 app.should_refresh_snapshot_session。这个判断会在重放或加载快照时使用，测试确保旁路线程走特殊规则。

调用图：调用 4 个内部函数（new, new, make_test_app, test_thread_session）；外部调用 2 个（new, assert!）。

async fn side_thread_snapshot_skips_session_header_preamble()

作用：测试重放旁路线程快照时，不会插入普通会话开头说明，也不会显示活动单元。这样旁路对话打开时不会被多余的 session header 干扰。

数据流：测试先清空已有事件，再建立父线程和旁路线程关系，构造一个带 forked_from_id 的空旁路快照。调用 replay_thread_snapshot 后，它收集所有 InsertHistoryCell 事件，确认没有任何渲染内容；同时确认聊天窗口线程 id 切到旁路线程，active_cell_transcript_lines 为空。

调用关系：它通过 app.replay_thread_snapshot 走真实快照重放路径，通过 app_event_rx 观察是否插入历史单元。测试目标是旁路线程重放时的 UI 静默行为。

调用图：调用 5 个内部函数（new, new, lines_to_single_string, make_test_app_with_channels, test_thread_session）；外部调用 2 个（new, assert_eq!）。

async fn primary_thread_ignores_child_mcp_startup_notifications()

作用：测试主线程正在显示时，来自子线程的 MCP 启动失败通知不会直接插到主界面里。这样用户不会在当前主对话里看到不属于它的错误。

数据流：它创建测试 App、配置一个名叫 sentry 的 MCP 服务，再伪造一条属于子线程的失败通知。结果是主界面事件队列保持空，通知先存进子线程缓冲区；等切到子线程并回放快照后，界面才显示一次失败原因和汇总提示。

调用关系：这个测试围绕 App 接收服务器通知、缓存线程事件、刷新线程快照和回放线程内容这一整条链路，确认子线程消息只在对应线程里出现。

调用图：调用 4 个内部函数（new, lines_to_single_string, make_test_app_with_channels, test_thread_session）；外部调用 7 个（McpServerStatusUpdated, new, ServerNotification, assert!, assert_eq!, start_embedded_app_server_for_picker, from）。

async fn app_scoped_mcp_startup_notifications_do_not_render_in_active_thread()

作用：测试没有指定线程的 MCP 启动通知，不会误显示到当前活动线程里。它防止全局级别的状态消息污染用户正在看的聊天。

数据流：它创建 App 和嵌入式服务器，设置一个活动主线程，然后发送一条没有 thread_id 的 MCP 失败通知。处理后没有新的界面事件，聊天区域也没有出现活动单元内容。

调用关系：它直接检查 App 处理服务器通知的过滤规则，和上一类按线程分发通知的测试互相补充。

调用图：调用 2 个内部函数（new, make_test_app_with_channels）；外部调用 5 个（McpServerStatusUpdated, ServerNotification, assert!, assert_eq!, start_embedded_app_server_for_picker）。

async fn active_side_thread_renders_live_mcp_startup_notifications()

作用：测试当用户正在看侧边线程时，这个侧边线程自己的 MCP 启动通知会实时显示出来。也就是说，不属于主线程的消息不是丢掉，而是要送到当前正确的地方。

数据流：它创建主线程和侧边线程，把侧边线程激活，然后发送 sentry 从启动中到失败的两条通知。之后它把活动线程收到的事件交给 App 处理，并从界面事件里收集渲染文本，确认只出现一次失败详情和一次失败汇总。

调用关系：这个测试把线程通道、活动线程接收器、通知处理和历史单元渲染串起来，验证侧边对话的实时通知路径。

调用图：调用 5 个内部函数（new, new, lines_to_single_string, make_test_app_with_channels, test_thread_session）；外部调用 8 个（McpServerStatusUpdated, new, ServerNotification, assert!, assert_eq!, start_embedded_app_server_for_picker, matches!, from）。

async fn side_restore_user_message_puts_inline_question_back_in_composer()

作用：测试恢复侧边提问时，用户之前输入的问题会回到输入框里。这样用户切换或恢复侧边对话后不会丢草稿。

数据流：它创建测试 App，把一条内容为 side question 的用户消息交给恢复函数。之后输入框里的文字变成这条问题。

调用关系：它检查侧边线程草稿恢复功能，主要关系到聊天输入框的状态。

调用图：调用 2 个内部函数（make_test_app, from）；外部调用 1 个（assert_eq!）。

async fn side_discard_selection_keeps_current_side_thread()

作用：测试判断要不要丢弃侧边线程时，不会把当前正在看的侧边线程自己误删。只有从侧边线程切回它的父线程时，才会提示或选择丢弃这个侧边线程。

数据流：它设置一个父线程和一个侧边线程，并把活动线程设为侧边线程。查询以侧边线程为目标时返回空，查询以父线程为目标时返回需要丢弃的侧边线程编号。

调用关系：它验证线程切换前的清理判断，避免当前会话被错误当成待丢弃对象。

调用图：调用 3 个内部函数（new, new, make_test_app）；外部调用 1 个（assert_eq!）。

async fn discard_side_thread_removes_agent_navigation_entry() -> Result<()>

作用：测试成功丢弃侧边线程时，导航列表里的对应代理入口也会被移除。否则用户可能看到一个已经不存在的侧边任务。

数据流：它启动一个真实的测试线程，把它登记为侧边线程并加入代理导航。调用丢弃后返回成功，侧边线程表和导航表里都不再有这个线程。

调用关系：它覆盖 App、嵌入式服务器和代理导航状态之间的协作，确认服务器关闭成功后本地状态也同步清掉。

调用图：调用 3 个内部函数（new, new, make_test_app）；外部调用 4 个（pin, assert!, assert_eq!, start_embedded_app_server_for_picker）。

async fn discard_side_thread_keeps_local_state_when_server_close_fails() -> Result<()>

作用：测试如果服务器端关闭侧边线程失败，本地不要假装已经删掉。这样界面状态不会和服务器状态对不上。

数据流：它只在本地造一个侧边线程编号，没有让服务器真正拥有它，然后尝试丢弃。函数返回失败，活动线程、侧边线程记录和导航入口都保持原样。

调用关系：它验证丢弃侧边线程的失败保护逻辑，和成功删除的测试形成对照。

调用图：调用 3 个内部函数（new, new, make_test_app）；外部调用 4 个（pin, assert!, assert_eq!, start_embedded_app_server_for_picker）。

async fn discard_closed_side_thread_removes_local_state_without_server_rpc()

作用：测试已经关闭的侧边线程可以只清本地状态，不需要再找服务器关闭一次。这样能处理服务器已经通知关闭后的收尾。

数据流：它建立一个活动侧边线程、事件通道和导航入口，然后调用本地清理函数。结果活动线程被清空，侧边线程、通道和导航入口都被移除。

调用关系：它检查 ThreadClosed 之后的本地打扫流程，不走服务器远程调用。

调用图：调用 4 个内部函数（new, new, make_test_app, new）；外部调用 2 个（assert!, assert_eq!）。

async fn active_non_primary_shutdown_target_returns_none_for_non_shutdown_event() -> Result<()>

作用：测试普通通知不会触发“非主线程关闭后切回主线程”的逻辑。只有线程关闭通知才该参与这个判断。

数据流：它设置活动线程和主线程为不同编号，然后传入一个技能变化通知。判断函数返回空，表示不需要切换。

调用关系：它验证 active_non_primary_shutdown_target 的入口筛选，防止无关服务器通知造成线程切换。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 1 个（assert_eq!）。

async fn active_non_primary_shutdown_target_returns_none_for_primary_thread_shutdown() -> Result<()>

作用：测试如果关闭的是主线程，就不要按“活动非主线程关闭”来处理。主线程关闭属于另一类流程。

数据流：它把活动线程和主线程设成同一个编号，并传入这个线程的关闭通知。结果返回空。

调用关系：它确认关闭判断会区分主线程和非主线程，避免错误切换。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 1 个（assert_eq!）。

async fn active_non_primary_shutdown_target_returns_ids_for_non_primary_shutdown() -> Result<()>

作用：测试当前活动线程不是主线程、且它收到关闭通知时，系统能找出要关闭的线程和要切回的主线程。这个结果用于后续自动回到主对话。

数据流：它设置不同的活动线程和主线程，再传入活动线程关闭通知。函数返回这两个线程编号组成的结果。

调用关系：它验证非主线程关闭后的切换目标计算，是后续切回主线程流程的前置判断。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 1 个（assert_eq!）。

async fn active_non_primary_shutdown_target_returns_none_when_shutdown_exit_is_pending() -> Result<()>

作用：测试如果这个活动线程已经在等待退出处理，就不要重复触发切换逻辑。这样可以避免同一个关闭事件被处理两遍。

数据流：它设置活动线程、主线程，并把待退出线程设为活动线程。收到活动线程关闭通知后，函数返回空。

调用关系：它检查关闭流程里的去重保护，避免 pending_shutdown_exit_thread_id 引发重复动作。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 1 个（assert_eq!）。

async fn active_non_primary_shutdown_target_still_switches_for_other_pending_exit_thread() -> Result<()>

作用：测试如果等待退出的是另一个线程，当前活动非主线程关闭仍然要切回主线程。也就是说，保护逻辑只挡同一个线程。

数据流：它设置活动线程、主线程和一个无关的待退出线程。收到活动线程关闭通知后，函数返回活动线程和主线程编号。

调用关系：它补齐上一条测试的反面情况，确认关闭切换不会被无关待退出状态误拦截。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 1 个（assert_eq!）。

async fn render_clear_ui_header_after_long_transcript_for_snapshot() -> String

作用：生成清屏后页头的测试文本，并确认它不会把很长的旧聊天或启动提示重新显示出来。它是多个快照测试共用的准备函数。

数据流：它创建 App，填入模型、工作目录、推理强度和一段很长的模拟聊天记录，再调用清屏页头渲染函数。输出是一段拼好的纯文本，同时断言里面没有旧提示和旧故事内容。

调用关系：它被两个清屏快照测试调用，用同一份结果验证普通清屏和快捷键清屏显示一致。

调用图：调用 1 个内部函数（make_test_app）；被 2 处调用（clear_ui_after_long_transcript_snapshots_fresh_header_only, ctrl_l_clear_ui_after_long_transcript_reuses_clear_header_snapshot）；外部调用 2 个（assert!, vec!）。

async fn clear_ui_after_long_transcript_snapshots_fresh_header_only()

作用：测试长聊天记录清屏后，只留下新的页头快照。它防止清屏功能偷偷把旧内容又画回来。

数据流：它调用共用渲染函数拿到清屏后的文本，然后和名为 clear_ui_after_long_transcript_fresh_header_only 的快照比对。

调用关系：它依赖 render_clear_ui_header_after_long_transcript_for_snapshot 提供场景，专门检查快照内容。

调用图：调用 1 个内部函数（render_clear_ui_header_after_long_transcript_for_snapshot）；外部调用 1 个（assert_app_snapshot!）。

async fn ctrl_l_clear_ui_after_long_transcript_reuses_clear_header_snapshot()

作用：测试按 Ctrl-L 清屏时，显示效果和普通清屏使用同一份页头快照。这样两种清屏入口不会越改越不一样。

数据流：它复用清屏页头渲染结果，再和同一个快照名比较。输出没有新数据，只通过快照断言结果正确。

调用关系：它和 clear_ui_after_long_transcript_snapshots_fresh_header_only 共享同一个辅助函数和同一个期望画面。

调用图：调用 1 个内部函数（render_clear_ui_header_after_long_transcript_for_snapshot）；外部调用 1 个（assert_app_snapshot!）。

async fn clear_ui_header_shows_fast_status_for_fast_capable_models()

作用：测试支持快速模式的模型在清屏页头里会显示快速状态。快速模式可以理解成服务档位里更快的一种选择。

数据流：它创建 App，设置模型、工作目录、最高推理强度、Fast 服务档位和测试认证信息，然后渲染清屏页头。最后用快照确认显示文字符合预期。

调用关系：它检查清屏页头、模型目录、认证状态和服务档位显示之间的组合行为。

调用图：调用 1 个内部函数（make_test_app）；外部调用 3 个（assert_app_snapshot!, set_chatgpt_auth, set_fast_mode_test_catalog）。

async fn make_test_app() -> App

作用：创建一个没有外部界面通道返回值的测试 App。测试用它快速拿到一个结构完整、但不会真的连线上服务的应用对象。

数据流：它先创建测试聊天组件和发送器，复制配置，建立文件搜索、离线模型信息和测试遥测数据。最后填好 App 的各个字段，返回一个可直接操作的 App。

调用关系：它是大量测试的基础工厂函数，负责把 App 初始化到一个干净、可控的测试状态。

调用图：调用 8 个内部函数（default, without_managed_config_for_tests, default_for_tests, new, get_model_offline_for_tests, test_session_telemetry, new, defaults）；被 64 处调用（active_non_primary_shutdown_target_returns_ids_for_non_primary_shutdown, active_non_primary_shutdown_target_returns_none_for_non_shutdown_event, active_non_primary_shutdown_target_returns_none_for_primary_thread_shutdown, active_non_primary_shutdown_target_returns_none_when_shutdown_exit_is_pending, active_non_primary_shutdown_target_still_switches_for_other_pending_exit_thread, active_turn_id_for_thread_uses_snapshot_turns, attach_live_thread_for_selection_rejects_empty_non_ephemeral_fallback_threads, attach_live_thread_for_selection_rejects_unmaterialized_fallback_threads, backtrack_esc_does_not_steal_empty_vim_insert_escape, clear_only_ui_reset_allows_active_skill_warning_to_render_again (+15 more)）；外部调用 13 个（new, new, new, new, new, default, make_chatwidget_manual_with_sender, default, default, default (+3 more)）。

async fn make_test_app_with_channels() -> (
    App,
    tokio::sync::mpsc::UnboundedReceiver<AppEvent>,
    tokio::sync::mpsc::UnboundedReceiver<Op>,
)

作用：创建测试 App，并把界面事件接收器和操作接收器也一起返回。需要观察 App 发出了什么事件或命令的测试会用它。

数据流：它和 make_test_app 一样组装 App，但保留聊天组件产生的 AppEvent 接收端和 Op 接收端。返回值是 App、界面事件队列和操作队列。

调用关系：它服务于需要检查渲染事件、用户回合命令、回滚命令等输出的测试。

调用图：调用 8 个内部函数（default, without_managed_config_for_tests, default_for_tests, new, get_model_offline_for_tests, test_session_telemetry, new, defaults）；被 52 处调用（active_side_thread_renders_live_mcp_startup_notifications, app_scoped_mcp_startup_notifications_do_not_render_in_active_thread, apply_permission_profile_selection_preserves_loader_overrides, backtrack_remote_image_only_selection_clears_existing_composer_draft, backtrack_resubmit_preserves_data_image_urls_in_user_turn, backtrack_selection_with_duplicate_history_targets_unique_turn, cancelled_turn_edit_restores_prompt_and_rolls_back_latest_turn, capped_resize_reflow_renders_recent_suffix_only, enqueue_primary_thread_session_replays_buffered_approval_after_attach, enqueue_primary_thread_session_replays_turns_before_initial_prompt_submit (+15 more)）；外部调用 13 个（new, new, new, new, new, default, make_chatwidget_manual_with_sender, default, default, default (+3 more)）。

async fn set_thread_goal_draft_materializes_long_objective_and_confirms_before_paste() -> Result<()>

作用：测试设置线程目标时，长目标、粘贴内容、图片附件和替换确认都按规则处理。线程目标可以理解成这条会话接下来要完成的任务说明。

数据流：它启动测试服务器和线程，先提交超长目标，确认目标被写成受管理的文件引用；再尝试带粘贴内容的替换，确认在需要确认时不会覆盖；随后强制替换，确认粘贴文本写入文件；最后测试空白粘贴不会覆盖、图片会复制、本地和远程图片引用会写进目标。

调用关系：它覆盖 App、目标文件工具、嵌入式服务器和附件目录的完整交互，是线程目标功能的综合测试。

调用图：调用 2 个内部函数（from_app_server, make_test_app）；外部调用 9 个（default, assert!, assert_eq!, start_embedded_app_server_for_picker, format!, read_dir, write, tempdir, vec!）。

async fn replace_goal_confirmation_snapshot()

作用：测试当已有线程目标需要替换时，底部弹窗的确认界面长什么样。这样用户确认覆盖目标的提示不会意外变坏。

数据流：它创建 App，打开替换目标确认弹窗，并把底部弹窗渲染成宽度 80 的文本。最后和快照比较。

调用关系：它专门检查 show_replace_thread_goal_confirmation 产生的 UI，不涉及服务器保存。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 2 个（default, assert_app_snapshot!）。

fn test_thread_session(thread_id: ThreadId, cwd: PathBuf) -> ThreadSessionState

作用：生成一个测试用线程会话状态。它把模型、权限、工作目录等字段填成稳定的假数据，方便别的测试复用。

数据流：输入线程编号和工作目录，函数把它们连同固定模型名、只读权限、无审批等默认测试值组装成 ThreadSessionState。输出是完整会话对象。

调用关系：它被许多线程回放、通知和反馈测试调用，用来模拟服务器返回的线程会话。

调用图：调用 1 个内部函数（read_only）；被 32 处调用（active_side_thread_renders_live_mcp_startup_notifications, active_turn_id_for_thread_uses_snapshot_turns, enqueue_primary_thread_session_replays_buffered_approval_after_attach, enqueue_primary_thread_session_replays_turns_before_initial_prompt_submit, feedback_submission_for_inactive_thread_replays_into_origin_thread, inactive_thread_approval_badge_clears_after_turn_completion_notification, inactive_thread_approval_bubbles_into_active_view, inactive_thread_settings_notification_updates_cached_collaboration_mode, inactive_thread_started_notification_initializes_replay_session, inactive_thread_started_notification_preserves_primary_model_when_path_missing (+15 more)）；外部调用 3 个（abs, new, new）。

fn plain_line_cell(text: impl Into<String>) -> Arc<dyn HistoryCell>

作用：把一段普通文字包装成历史记录单元。测试重新排版时可以用它快速造出聊天记录里的简单一行。

数据流：输入任意可转成字符串的文字，函数把它变成一行 Line，再放进 PlainHistoryCell，最后用共享指针返回。

调用关系：它主要被窗口缩放和历史重排相关测试使用，提供简单可预测的历史单元。

调用图：调用 1 个内部函数（new）；外部调用 2 个（new, vec!）。

fn rendered_line_text(line: &crate::terminal_hyperlinks::HyperlinkLine) -> String

作用：从一行已经渲染好的终端内容里提取纯文字。测试用它忽略样式，只比较用户能看到的文本。

数据流：输入一个带超链接结构的渲染行，函数遍历其中所有文本片段并拼接。输出是一条普通字符串。

调用关系：它服务于重排和缓冲测试，用来把复杂渲染结构转成容易断言的文本。

async fn capped_resize_reflow_renders_recent_suffix_only()

作用：测试窗口缩放重排有行数上限时，只重新渲染最近的尾部内容。这样历史很长时不会为了重排拖慢界面。

数据流：它设置最多保留 5 行，造 20 个历史单元，然后请求重排。结果只有 5 行，并且内容来自最后几个单元。

调用关系：它检查 render_transcript_lines_for_reflow 在行数限制下的裁剪行为。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 2 个（assert_eq!, Limit）。

async fn uncapped_resize_reflow_renders_all_cells_when_row_cap_absent()

作用：测试没有行数上限时，窗口缩放重排会渲染全部历史单元。这样用户禁用限制后不会丢历史显示。

数据流：它关闭重排行数限制，造 20 个历史单元并重排。结果行数覆盖全部内容，第一行是 cell 0，最后一行是 cell 19。

调用关系：它和有上限的重排测试形成对照，确认配置开关有效。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 1 个（assert_eq!）。

async fn resize_reflow_wraps_transcript_early_when_pet_is_enabled()

作用：测试启用终端宠物图像后，聊天历史会按更窄宽度提前换行。宠物占用屏幕空间，所以文字区域不能还按原宽度计算。

数据流：它先用宽度 40 渲染一段长文本，再启用测试宠物并取得更窄的历史换行宽度。第二次重排产生更多行，说明文本更早换行。

调用关系：它检查聊天组件的宠物显示能力和历史重排宽度计算是否配合。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 3 个（assert!, Supported, vec!）。

async fn uncapped_resize_reflow_renders_all_cells_under_row_limit()

作用：测试虽然设置了行数上限，但实际内容少于上限时不会被裁掉。上限只该限制过长内容，不该影响短历史。

数据流：它设置上限 100，造 3 个历史单元并重排。输出包含 cell 0、空行、cell 1、空行、cell 2 的完整顺序。

调用关系：它补充验证重排上限的边界行为，确保短内容完整显示。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 2 个（assert_eq!, Limit）。

async fn initial_replay_buffer_keeps_recent_rows_when_row_cap_present()

作用：测试初始历史回放缓冲区在有行数上限时，只保存最新的几行。这样启动时回放很长历史也不会撑爆界面缓冲。

数据流：它开启初始回放缓冲，依次塞入 line 0 到 line 4，并设置最多 3 行。最后缓冲里只剩 line 2、line 3、line 4。

调用关系：它直接测试 App 的初始历史回放缓冲工具函数，服务于启动或恢复会话时的显示控制。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 4 个（assert_eq!, buffer_initial_history_replay_display_lines, Limit, vec!）。

async fn thread_switch_replay_buffer_uses_transcript_tail_mode_when_row_cap_present()

作用：测试在线程切换且有行数上限时，回放缓冲会进入“从历史尾部渲染”的模式。这样切换到长线程时能优先显示最近内容。

数据流：它设置上限 3，然后开始线程切换回放缓冲。缓冲被创建，标记为从 transcript 尾部渲染，并且暂时没有保留行。

调用关系：它验证线程切换回放的初始化策略，和初始回放缓冲的逐行保留模式不同。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 2 个（assert!, Limit）。

async fn thread_switch_replay_buffer_is_disabled_without_row_cap()

作用：测试没有行数上限时，线程切换不启用这类尾部缓冲。因为没有限制时可以正常渲染全部历史。

数据流：它关闭重排行数限制并开始线程切换回放缓冲。结果 App 里没有创建 initial_history_replay_buffer。

调用关系：它和有上限的线程切换测试配套，确认配置决定是否启用缓冲。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 1 个（assert!）。

async fn height_shrink_schedules_resize_reflow()

作用：测试终端高度变矮时会安排一次历史重排。高度缩小后，不重排可能导致显示区域里的内容位置不对。

数据流：它先传入相同的新旧尺寸，确认不需要重排；再把高度从 35 变成 24，函数返回需要处理，并且重排状态变成有待执行。

调用关系：它检查绘制尺寸变化处理和 transcript_reflow 状态之间的连接。

调用图：调用 2 个内部函数（make_test_app_with_channels, test_dummy）；外部调用 1 个（assert!）。

fn test_turn(turn_id: &str, status: TurnStatus, items: Vec<ThreadItem>) -> Turn

作用：生成一个测试用回合对象。回合就是用户和助手之间一次问答过程的记录。

数据流：输入回合编号、状态和条目列表，函数填入默认时间、错误和视图字段，输出完整 Turn。它不修改外部状态。

调用关系：它被开始回合和完成回合通知的辅助函数复用，避免每个测试重复拼 Turn。

调用图：被 3 处调用（side_thread_snapshot_hides_forked_parent_transcript, turn_completed_notification, turn_started_notification）。

fn turn_started_notification(thread_id: ThreadId, turn_id: &str) -> ServerNotification

作用：生成一条“某线程的某回合开始了”的测试服务器通知。它用来模拟服务器告诉界面任务正在运行。

数据流：输入线程编号和回合编号，函数创建一个进行中的 Turn，并包进 TurnStarted 类型通知。输出是 ServerNotification。

调用关系：它被回放、队列恢复和代理运行状态相关测试使用，作为模拟服务器事件。

调用图：调用 1 个内部函数（test_turn）；被 9 处调用（open_agent_picker_clears_completed_path_backed_agent_running_state, open_agent_picker_refreshes_replay_only_path_backed_liveness, replay_only_thread_keeps_restored_queue_visible, replay_thread_snapshot_does_not_submit_queue_before_replay_catches_up, replay_thread_snapshot_in_progress_turn_restores_running_queue_state, replay_thread_snapshot_keeps_queue_when_running_state_only_comes_from_snapshot, replayed_interrupted_turn_restores_queued_input_to_composer, replayed_turn_complete_submits_restored_queued_follow_up, side_parent_status_tracks_parent_turn_lifecycle）；外部调用 3 个（TurnStarted, new, to_string）。

fn turn_completed_notification(
    thread_id: ThreadId,
    turn_id: &str,
    status: TurnStatus,
) -> ServerNotification

作用：生成一条“某线程的某回合完成了”的测试服务器通知。测试可以用它模拟任务结束、成功或失败。

数据流：输入线程编号、回合编号和完成状态，函数创建带完成时间和耗时的 Turn，再包进 TurnCompleted 通知。输出是 ServerNotification。

调用关系：它服务于线程生命周期、审批徽标清理和父子线程状态跟踪测试。

调用图：调用 1 个内部函数（test_turn）；被 4 处调用（inactive_thread_approval_badge_clears_after_turn_completion_notification, open_agent_picker_clears_completed_path_backed_agent_running_state, replay_thread_snapshot_does_not_submit_queue_before_replay_catches_up, side_parent_status_tracks_parent_turn_lifecycle）；外部调用 3 个（TurnCompleted, new, to_string）。

fn thread_closed_notification(thread_id: ThreadId) -> ServerNotification

作用：生成一条线程关闭通知。测试用它模拟服务器说某个线程已经结束。

数据流：输入线程编号，函数把编号转成字符串并放入 ThreadClosedNotification，输出 ServerNotification。

调用关系：它被关闭处理、通道满时入队等测试作为标准关闭事件使用。

调用图：被 1 处调用（enqueue_thread_event_does_not_block_when_channel_full）；外部调用 2 个（ThreadClosed, to_string）。

fn token_usage_notification(
    thread_id: ThreadId,
    turn_id: &str,
    model_context_window: Option<i64>,
) -> ServerNotification

作用：生成一条 token 用量更新通知。token 可以理解成模型处理文字时使用的计量单位。

数据流：输入线程编号、回合编号和可选的模型上下文窗口大小，函数填入固定的总量、输入量、缓存输入量和输出量。输出是 ThreadTokenUsageUpdated 通知。

调用关系：它用于状态栏显示上下文窗口和用量刷新相关测试。

调用图：被 1 处调用（token_usage_update_refreshes_status_line_with_runtime_context_window）；外部调用 2 个（ThreadTokenUsageUpdated, to_string）。

fn agent_message_delta_notification(
    thread_id: ThreadId,
    turn_id: &str,
    item_id: &str,
    delta: &str,
) -> ServerNotification

作用：生成一条助手消息增量通知。增量就是助手回答还没完整结束时，一小段一小段吐出来的文字。

数据流：输入线程编号、回合编号、条目编号和文本片段，函数把它们包装成 AgentMessageDelta 通知。输出是 ServerNotification。

调用关系：它被线程回放和队列恢复测试用来模拟助手正在流式输出。

调用图：被 6 处调用（replay_only_thread_keeps_restored_queue_visible, replay_thread_snapshot_does_not_submit_queue_before_replay_catches_up, replay_thread_snapshot_in_progress_turn_restores_running_queue_state, replay_thread_snapshot_keeps_queue_when_running_state_only_comes_from_snapshot, replayed_interrupted_turn_restores_queued_input_to_composer, replayed_turn_complete_submits_restored_queued_follow_up）；外部调用 2 个（AgentMessageDelta, to_string）。

fn exec_approval_request(
    thread_id: ThreadId,
    turn_id: &str,
    item_id: &str,
    approval_id: Option<&str>,
) -> ServerRequest

作用：生成一条命令执行审批请求。审批请求就是工具想运行命令前，先问用户允不允许。

数据流：输入线程编号、回合编号、条目编号和可选审批编号，函数填入固定命令 echo hello、工作目录、原因和请求编号。输出是 ServerRequest。

调用关系：它被审批气泡、 inactive 线程审批、缓冲审批恢复等测试用来模拟服务器发来的权限请求。

调用图：被 10 处调用（enqueue_primary_thread_session_replays_buffered_approval_after_attach, inactive_thread_approval_badge_clears_after_turn_completion_notification, inactive_thread_approval_bubbles_into_active_view, inactive_thread_exec_approval_preserves_context, inactive_thread_exec_approval_splits_shell_wrapped_command, refresh_pending_thread_approvals_only_lists_inactive_threads, resolved_buffered_approval_does_not_become_actionable_after_drain, side_defers_parent_approval_overlay_until_parent_replay, side_defers_subagent_approval_overlay_until_side_exits, side_parent_status_prioritizes_input_over_approval）；外部调用 2 个（Integer, to_string）。

fn request_user_input_request(thread_id: ThreadId, turn_id: &str, item_id: &str) -> ServerRequest

作用：生成一条工具请求用户输入的测试请求。它模拟后台工具需要用户回答问题才能继续。

数据流：输入线程编号、回合编号和条目编号，函数填入空问题列表和固定请求编号。输出是 ServerRequest。

调用关系：它用于侧边父线程状态测试，特别是比较“等待用户输入”和“等待审批”哪个优先显示。

调用图：被 1 处调用（side_parent_status_prioritizes_input_over_approval）；外部调用 3 个（Integer, new, to_string）。

async fn feedback_submission_without_thread_emits_error_history_cell()

作用：测试反馈上传失败且没有来源线程时，会在当前历史里显示错误消息。这样用户能知道反馈没发出去。

数据流：它创建带事件通道的 App，调用反馈提交处理函数并传入错误 boom。随后从界面事件里取出一个历史单元，确认文本是上传失败提示。

调用关系：它检查反馈结果处理和历史消息插入之间的连接，属于无来源线程的直接显示路径。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 2 个（assert_eq!, panic!）。

async fn feedback_submission_for_inactive_thread_replays_into_origin_thread()

作用：测试从非当前线程提交的反馈成功后，提示会存回原线程，而不是插到当前活动线程。这样多线程时反馈结果不会跑错地方。

数据流：它创建来源线程和活动线程的事件通道，激活活动线程后提交来源线程的反馈成功结果。当前界面没有新事件；随后回放来源线程快照，才看到包含上传链接的反馈提示。

调用关系：它覆盖反馈处理、线程缓冲和线程快照回放，确认异步反馈按来源线程归档。

调用图：调用 5 个内部函数（new, lines_to_single_string, make_test_app_with_channels, test_thread_session, new_with_session）；外部调用 3 个（new, assert!, assert_matches!）。

fn next_user_turn_op(op_rx: &mut tokio::sync::mpsc::UnboundedReceiver<Op>) -> Op

作用：从操作队列里取出下一条用户回合操作。测试用它跳过无关操作，只关心是否真的提交了用户输入。

数据流：输入一个操作接收器，函数不断尝试读取队列；遇到 UserTurn 就返回，其他操作记录下来。如果队列里没有 UserTurn，就直接让测试失败并打印看到的操作。

调用关系：它被回放后自动提交、草稿恢复提交等测试用来验证 App 是否发出了正确的用户回合命令。

调用图：被 4 处调用（replay_thread_snapshot_does_not_submit_queue_before_replay_catches_up, replay_thread_snapshot_restores_collaboration_mode_for_draft_submit, replay_thread_snapshot_restores_pending_pastes_for_submit, replayed_turn_complete_submits_restored_queued_follow_up）；外部调用 5 个（try_recv, new, format!, matches!, panic!）。

fn lines_to_single_string(lines: &[Line<'_>]) -> String

作用：把多行终端渲染内容合成一个普通字符串。测试用它更方便地比较屏幕上实际显示的文字。

数据流：输入一组 Line，函数取出每行的所有文本片段拼成行文本，再用换行符连接。输出是纯文本字符串。

调用关系：它被许多 UI 渲染测试复用，用来把历史单元的显示结果转成断言文本。

调用图：被 9 处调用（active_side_thread_renders_live_mcp_startup_notifications, bypass_hook_trust_startup_warning_snapshot, enqueue_primary_thread_session_replays_turns_before_initial_prompt_submit, feedback_submission_for_inactive_thread_replays_into_origin_thread, inactive_thread_file_change_approval_recovers_buffered_changes, primary_thread_ignores_child_mcp_startup_notifications, replace_chat_widget_reseeds_collab_agent_metadata_for_replay, replay_snapshot_with_pending_request_suppresses_replay_notices, side_thread_snapshot_skips_session_header_preamble）；外部调用 1 个（iter）。

fn test_session_telemetry(config: &Config, model: &str) -> SessionTelemetry

作用：生成测试用会话遥测信息。遥测可以理解成记录会话来源、模型等元数据，但这里不会真的记录用户提示。

数据流：输入配置和模型名，函数离线构造模型信息，再填入固定来源、测试标识、无账号信息和不记录提示的设置。输出是 SessionTelemetry。

调用关系：它被 make_test_app 和 make_test_app_with_channels 调用，保证测试 App 也有完整的会话元数据。

调用图：调用 4 个内部函数（construct_model_info_offline_for_tests, new, new, session_source_cli）；被 2 处调用（make_test_app, make_test_app_with_channels）；外部调用 1 个（to_models_manager_config）。

fn active_turn_not_steerable_turn_error_extracts_structured_server_error()

作用：测试当服务器返回“当前回合不能被引导”的结构化错误时，客户端能把里面的详细原因解析出来。这里的引导可以理解成继续控制正在运行的回合。

数据流：它构造一个包含 Review 类型原因的服务器错误，并把它交给解析函数。结果返回原来的 AppServerTurnError，而不是只剩普通错误文字。

调用关系：它验证错误解析函数 active_turn_not_steerable_turn_error 对 JSON-RPC 错误数据的识别能力。

调用图：外部调用 2 个（assert_eq!, to_value）。

fn session_start_error_surfaces_archived_guidance_without_rollout_path()

作用：测试恢复或分叉已归档会话失败时，最终错误只显示清楚的解档提示，不暴露内部 rollout 文件路径。这样错误对用户更友好。

数据流：它构造一个指向 archived_sessions 的目标会话和包含归档提示的底层错误。对 resume 和 fork 两种动作处理后，输出错误文字都只保留“运行 codex unarchive”的提示。

调用关系：它检查 TUI 启动阶段的会话错误整理逻辑，防止内部路径泄漏到用户提示。

调用图：调用 1 个内部函数（from_string）；外部调用 4 个（assert_eq!, eyre!, format!, from）。

fn active_turn_steer_race_detects_missing_active_turn()

作用：测试当服务器说“没有可引导的活动回合”时，客户端能识别这是一次竞态情况。竞态就是两边状态变化太快，客户端以为还在，服务器已经不在了。

数据流：它构造 turn/steer 的服务器错误，消息为 no active turn to steer。解析后得到 Missing 类型，同时确认它不会被误判成不可引导回合的结构化错误。

调用关系：它验证 active_turn_steer_race 和 active_turn_not_steerable_turn_error 两个错误识别函数的边界。

调用图：外部调用 1 个（assert_eq!）。

fn active_turn_steer_race_extracts_actual_turn_id_from_mismatch()

作用：测试当引导回合时发现预期回合和实际回合不一致，客户端能提取服务器说的实际回合编号。这样后续可以按真实状态恢复。

数据流：它构造一条包含 expected 和 found 的 turn/steer 错误消息。解析函数返回 ExpectedTurnMismatch，并带上 actual_turn_id 为 turn-actual。

调用关系：它专门检查 active_turn_steer_race 对文字错误消息的解析能力。

调用图：外部调用 1 个（assert_eq!）。

fn active_turn_interrupt_race_extracts_actual_turn_id_from_mismatch()

作用：测试中断回合时如果回合编号不一致，客户端能从错误文字里找出实际活动回合编号。这样不会盲目按旧编号继续操作。

数据流：它构造 turn/interrupt 的服务器错误，消息里说明 expected 和 found。解析函数返回 turn-actual。

调用关系：它验证 active_turn_interrupt_race 对中断竞态错误的处理，和 steer 的竞态测试相对应。

调用图：外部调用 1 个（assert_eq!）。

async fn fresh_session_config_uses_current_service_tier()

作用：测试新建会话配置会使用聊天组件当前选择的服务档位。比如用户切到 Fast，新会话就应该按 Fast 创建。

数据流：它创建 App，把聊天组件服务档位设为 Fast，然后生成 fresh_session_config。结果配置里的 service_tier 也是 Fast 的请求值。

调用关系：它检查 App 从当前 UI 状态生成新会话配置的逻辑。

调用图：调用 1 个内部函数（make_test_app）；外部调用 1 个（assert_eq!）。

async fn backtrack_selection_with_duplicate_history_targets_unique_turn()

作用：测试历史里有重复对话时，回退编辑能选中真正要回退的那一次用户消息，而不是同样文字的旧消息。回退编辑就是把会话倒回某个提问，改后重来。

数据流：它造出一段包含重复问题和编辑后问题的历史，带本地图片和远程图片，再设置回退状态。确认选择结果指向第二个用户消息，保留编辑文本和附件；应用回退后，输入框保留远程图片，并向操作队列发出回滚 1 个回合。

调用关系：它覆盖历史单元统计、回退选择、附件恢复、输入框更新和 ThreadRollback 操作发送。

调用图：调用 4 个内部函数（read_only, new, make_test_app_with_channels, user_count）；外部调用 5 个（new, new, assert_eq!, format!, vec!）。

async fn backtrack_remote_image_only_selection_clears_existing_composer_draft()

作用：测试回退选择只有远程图片、没有文字时，会清掉输入框里旧草稿，但保留远程图片。这样旧文字不会和新选择的图片混在一起。

数据流：它先放入一个用户历史单元，并把输入框设成 stale draft。应用一个空文本但含远程图片的回退选择后，输入框文字变空，远程图片列表更新，并发出回滚 1 个回合的操作。

调用关系：它检查 apply_backtrack_rollback 对特殊附件场景的处理，是回退编辑功能的边界测试。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 4 个（new, new, assert_eq!, vec!）。

async fn cancelled_turn_edit_restores_prompt_and_rolls_back_latest_turn()

作用：测试用户取消编辑上一轮消息时，输入框会恢复被编辑的文字和图片链接，同时后台会收到“回退一轮对话”的请求。这样用户不会因为取消编辑而丢掉原本想改的内容。

数据流：测试先造出一个带历史消息的假 App，再准备一条要恢复的用户消息。调用取消编辑的方法后，它检查输入框文字变成“edit me”，远程图片链接还在，并且操作通道里出现了 ThreadRollback，表示要把最近一轮对话撤掉。

调用关系：这个测试由测试框架运行。它通过 make_test_app_with_channels 搭出 App 和消息通道，然后直接调用 app.apply_cancelled_turn_edit，最后用断言和快照检查界面与后台命令是否同步。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 5 个（new, assert_eq!, assert_matches!, assert_snapshot!, vec!）。

async fn first_cancelled_turn_edit_restores_prompt_without_local_history()

作用：测试第一条消息被取消编辑时，即使本地还没有历史记录，输入框也能恢复原提示词和图片链接，并请求回退。它保证新会话的第一轮编辑也不会特殊出错。

数据流：测试创建一个空历史的假 App，准备一条带文字和远程图片的用户消息。执行取消编辑后，输入框拿回这段文字，图片链接也回到输入区，同时后台队列收到回退一轮的命令。

调用关系：它和前一个测试验证同一个功能的另一种情况：没有本地历史。测试框架启动它，它用 make_test_app_with_channels 建环境，再让 apply_cancelled_turn_edit 完成恢复和回退通知。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 4 个（new, assert_eq!, assert_matches!, vec!）。

async fn backtrack_resubmit_preserves_data_image_urls_in_user_turn()

作用：测试用户回退到旧消息后重新提交时，消息里的 data:image 这种内嵌图片地址不会丢。没有这个保护，用户重发带图片的问题时，后台可能只收到文字，看不到图片。

数据流：测试先建立一个线程会话，并在历史里放入一条带 data:image/png;base64 图片地址的用户消息。然后执行回退，把旧消息放回输入区，再模拟按 Enter 重新发送。最后从操作通道里确认既发生了回退，也提交了新的用户轮次，并且提交内容里仍然包含原图片地址。

调用关系：测试框架运行它。它先用 ChatWidget 接收线程会话，再调用 app.apply_backtrack_rollback 准备回退输入，随后把按键事件交给 chat_widget，最后检查 App 发出的 Op::ThreadRollback 和 Op::UserTurn。

调用图：调用 3 个内部函数（read_only, new, make_test_app_with_channels）；外部调用 5 个（new, new, new, assert!, vec!）。

async fn replay_thread_snapshot_replays_turn_history_in_order()

作用：测试从线程快照恢复历史时，用户消息会按原来的先后顺序出现在聊天记录里。这样重新打开会话时，用户看到的历史不会颠倒或漏掉。

数据流：测试构造一个包含两个历史轮次的快照：第一轮是用户消息，第二轮包含用户消息和助手回复。调用 replay_thread_snapshot 后，它从 App 事件通道里取出插入历史单元的事件，塞回 transcript_cells，再抽取所有用户消息，确认顺序是 first prompt 后 third prompt。

调用关系：这个测试验证 app.replay_thread_snapshot。它借助 test_thread_session 准备会话信息，重放产生的 InsertHistoryCell 事件由测试手动收集，用来确认历史渲染顺序。

调用图：调用 3 个内部函数（new, make_test_app_with_channels, test_thread_session）；外部调用 3 个（new, assert_eq!, vec!）。

async fn replace_chat_widget_reseeds_collab_agent_metadata_for_replay()

作用：测试替换聊天组件后，再重放协作代理相关事件时，代理的名字和角色仍能显示出来。否则界面可能只显示一串线程 ID，用户看不懂是谁在等待。

数据流：测试先在 agent_navigation 里登记一个接收方线程，名字是 Robie，角色是 explorer。然后新建一个 ChatWidget 替换旧的，再重放一个协作代理等待事件。最后读取插入的历史单元文本，确认里面包含“Robie [explorer]”。

调用关系：测试框架运行它。它用 ChatWidget::new_with_app_event 做替换组件，调用 app.replace_chat_widget 后，再通过 app.replay_thread_snapshot 触发历史生成，最后从 AppEvent::InsertHistoryCell 里检查显示结果。

调用图：调用 4 个内部函数（from_string, lines_to_single_string, make_test_app_with_channels, test_dummy）；外部调用 4 个（new, assert!, new_with_app_event, vec!）。

async fn refreshed_snapshot_session_persists_resumed_turns()

作用：测试后台刷新线程快照时，新的会话信息和恢复出来的历史轮次会同时写回内存快照和线程事件存储。这样恢复会话后，App 不会继续拿旧目录或旧历史。

数据流：测试先给某个线程放入旧 session。然后准备一个 cwd 不同的新 session，以及一条恢复出的用户历史轮次。调用 apply_refreshed_snapshot_thread 后，它检查传入的 snapshot 被改成新 session 和新 turns，也检查线程通道内部 store 里的快照同样更新了。

调用关系：它直接测试 app.apply_refreshed_snapshot_thread。线程事件通道由 ThreadEventChannel::new_with_session 建好，函数执行后既改外部 snapshot，也改内部缓存。

调用图：调用 4 个内部函数（new, make_test_app, test_thread_session, new_with_session）；外部调用 3 个（new, assert_eq!, vec!）。

async fn queued_rollback_syncs_overlay_and_clears_deferred_history()

作用：测试当回退请求后来才生效时，聊天记录、覆盖层预览、延迟显示的历史行、以及正在显示的用量面板都会一起清理到正确状态。它防止界面出现“历史已回退，但浮层还显示旧内容”的错乱。

数据流：测试先放入两轮用户与助手历史，并打开 transcript 覆盖层，还塞入一条过期的缓冲历史行。随后模拟打开 token usage 的加载显示，再执行 apply_non_pending_thread_rollback 回退一轮。最后检查回退确实发生，延迟历史被清空，usage 临时输出消失，只剩第一条用户消息，覆盖层的单元数量也和真实历史一致。

调用关系：这个测试围绕 app.apply_non_pending_thread_rollback。前面通过 ChatWidget 的按键处理制造一个待显示的用量单元，回退函数负责同步 App 主历史和 Overlay。

调用图：调用 2 个内部函数（make_test_app, new_transcript）；外部调用 6 个（new, new, assert!, assert_eq!, panic!, vec!）。

async fn late_usage_result_can_follow_finalized_plan()

作用：测试 token 用量查询结果即使晚于计划内容完成，也还能被正常接收和插入。这样后台慢一点返回用量信息时，界面不会误以为它被计划流式输出挡住了。

数据流：测试先让聊天组件添加一个每日用量输出，并拿到刷新请求 ID。然后模拟流式内容合并：插入一个最终计划单元并标记合并完成。最后用同一个请求 ID 结束用量刷新，即使结果是错误，也确认它被接收、没有被阻塞，并且可取出完成的用量输出。

调用关系：它测试 ChatWidget 和 App 对“流式内容合并”与“用量结果”两条异步路径的协调。add_token_activity_output 发出 RefreshTokenActivity，finish_token_activity_refresh 接回结果，app.pending_usage_output_insertion_blocked 用来确认没有卡住。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 5 个（new, assert!, new_proposed_plan_stream, panic!, vec!）。

async fn thread_rollback_response_discards_queued_active_thread_events()

作用：测试线程回退响应到达后，当前活动线程里已经排队但过时的事件会被丢掉。否则回退后旧警告、旧通知还可能跳出来，污染新状态。

数据流：测试创建活动线程和一个事件接收通道，先塞入一条过时的配置警告通知。随后调用 handle_thread_rollback_response 处理回退响应。最后检查活动线程接收器还在，但里面已经没有那条旧事件。

调用关系：它直接验证 app.handle_thread_rollback_response。测试手动把 ThreadBufferedEvent 放进 active_thread_rx 对应的队列，再确认回退处理会清空这些排队事件。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 6 个（ConfigWarning, new, new, assert!, channel, Notification）。

async fn new_session_requests_shutdown_for_previous_conversation()

作用：测试开始新会话前关闭旧会话时，会走 app server 的关闭流程，而不是再往旧的操作通道提交一个 Shutdown 命令。这样旧会话不会被重复关闭或通过错误通道关闭。

数据流：测试先建立一个 App、事件通道和操作通道，再让聊天组件接收一个线程 session。清空已有事件后启动嵌入式 app server，并调用 shutdown_current_thread。最后确认 op_rx 没有收到 Op::Shutdown。

调用关系：它验证 app.shutdown_current_thread 和嵌入式 app server 的配合。make_test_app_with_channels 提供旧式操作通道，start_embedded_app_server_for_picker 提供新的后台关闭路径。

调用图：调用 3 个内部函数（read_only, new, make_test_app_with_channels）；外部调用 5 个（pin, new, new, assert!, start_embedded_app_server_for_picker）。

async fn shutdown_first_exit_returns_immediate_exit_when_shutdown_submit_fails()

作用：测试在“先关闭再退出”模式下，如果没有办法提交关闭请求，程序会直接按用户要求退出，而不是卡住等待。这样退出流程更可靠。

数据流：测试创建 App，并设置一个活动线程 ID。启动测试用 app server 后，调用 handle_exit_mode，退出模式是 ShutdownFirst。最后确认没有留下 pending_shutdown_exit_thread_id，并且返回值是用户请求退出。

调用关系：它直接测试 app.handle_exit_mode 在失败路径上的行为。嵌入式 app server 提供调用对象，AppRunControl::Exit 表示主运行循环应该立刻结束。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 4 个（pin, assert!, assert_eq!, start_embedded_app_server_for_picker）。

async fn shutdown_first_exit_uses_app_server_shutdown_without_submitting_op()

作用：测试“先关闭再退出”会使用 app server 的关闭接口，而不会往传统操作队列里塞 Op::Shutdown。它保证新退出路径不会和旧机制混用。

数据流：测试创建带操作通道的 App，设置活动线程，启动嵌入式 app server，然后调用 handle_exit_mode。结果应当是立即退出，并且操作通道里没有任何 Shutdown 操作。

调用关系：它和前一个测试一起覆盖退出流程。这里额外观察 op_rx，确认 handle_exit_mode 把工作交给 app server，而不是提交给旧的 Op 通道。

调用图：调用 2 个内部函数（new, make_test_app_with_channels）；外部调用 4 个（pin, assert!, assert_eq!, start_embedded_app_server_for_picker）。

async fn interrupt_without_active_turn_is_treated_as_handled()

作用：测试没有正在运行的回答时发送 interrupt，也会被当成“已经处理”。这样用户按中断键不会触发错误提示，只是安静地结束这个无事可做的操作。

数据流：测试启动嵌入式 app server，创建并注册一个线程，但不启动任何活跃轮次。然后构造 interrupt 命令，交给 try_submit_active_thread_op_via_app_server。最后确认返回 handled 为 true。

调用关系：它验证 AppCommand::interrupt 通过 app.try_submit_active_thread_op_via_app_server 发送到 app server 时的空闲场景。enqueue_primary_thread_session 负责先把线程登记到 App。

调用图：调用 1 个内部函数（make_test_app）；外部调用 4 个（pin, assert_eq!, interrupt, start_embedded_app_server_for_picker）。

async fn override_turn_context_sends_thread_settings_update()

作用：测试临时覆盖本轮上下文时，App 会向后台发送线程设置更新，并在收到后台通知后正确缓存新设置。这里的设置包括审批策略、模型、推理强度、协作模式、人格和权限配置。

数据流：测试先启动 app server 和线程，记录初始模型与推理强度。然后构造 override_turn_context 命令，包含新的审批规则、模型 gpt-5.4、高推理强度、快速服务档位、Plan 协作模式和 Pragmatic 人格。提交后先确认只是收到确认，缓存状态还没立刻改；接着读取后台发出的 ThreadSettingsUpdated 通知，检查通知内容正确；最后把通知交给 App 处理，再确认本地 session 缓存更新了相关设置，同时模型和默认推理字段保持预期。

调用关系：它覆盖了完整链路：AppCommand::override_turn_context 生成命令，app.try_submit_active_thread_op_via_app_server 提交给后台，next_thread_settings_updated 等后台通知，app.handle_app_server_event 再把通知合并回本地缓存。

调用图：调用 3 个内部函数（new, make_test_app, next_thread_settings_updated）；外部调用 6 个（pin, ThreadSettingsUpdated, ServerNotification, assert_eq!, override_turn_context, start_embedded_app_server_for_picker）。

async fn thread_setting_update_params_sync_model_and_default_reasoning()

作用：测试当用户修改模型或默认推理强度时，发给活动线程的设置更新参数会同步更新协作模式里的对应字段。这样主模型选择和协作模式不会显示一套、发送另一套。

数据流：测试先设置活动线程 ID，把聊天组件模型改成 gpt-5.4，然后生成模型更新参数，确认参数里的 thread_id、model 和 collaboration_mode.settings.model 都正确。接着设置推理强度和一个 Plan 协作遮罩，再调用 on_update_reasoning_effort 改成 High，生成推理更新参数，确认 effort 是 High，协作模式被同步为 Default 且推理强度也是 High。

调用关系：它直接测试 app.active_thread_model_setting_update_params 和 app.active_thread_reasoning_setting_update_params。ChatWidget 提供当前模型、推理强度和协作遮罩，App 把这些整理成发送给后台的参数。

调用图：调用 2 个内部函数（new, make_test_app）；外部调用 1 个（assert_eq!）。

async fn inactive_thread_settings_notification_updates_cached_collaboration_mode()

作用：测试不在当前界面里的线程收到设置更新通知时，App 也会更新它的缓存；等用户切回这个线程，协作模式、推理强度和人格能正确恢复。这样后台更新不会只对当前线程生效。

数据流：测试建立一个主线程和一个非活动线程，并分别放入线程事件通道。然后给非活动线程发送 ThreadSettingsUpdated 通知，里面包含 Plan 协作模式、高推理强度和 Pragmatic 人格。通知入队后，测试读取非活动线程缓存，确认模型保持原 session 的 gpt-test，但人格和协作模式已更新。最后把该缓存 session 交给 ChatWidget，确认界面显示 Plan 模式、当前模型、协作模式模型、推理强度和人格都符合预期。

调用关系：它测试 app.enqueue_thread_notification 对非活动线程的缓存更新。之后 ChatWidget.handle_thread_session 使用这份缓存，说明这些后台通知会影响用户以后切回线程时看到的状态。

调用图：调用 6 个内部函数（read_only, new, make_test_app, test_absolute_path, test_thread_session, new_with_session）；外部调用 3 个（ThreadSettingsUpdated, new, assert_eq!）。

async fn clear_only_ui_reset_preserves_chat_session_state()

作用：测试“只清界面”的重置不会清掉当前聊天会话和输入框内容。也就是说，清屏只是擦黑板，不是换教室。

数据流：测试先给聊天组件设置线程 session 和草稿输入，再放入旧历史、覆盖层、延迟历史、回退状态等界面临时数据。调用 reset_app_ui_state_after_clear 后，检查覆盖层、历史、缓冲行和回退预览都清空了，但 chat_widget 的 thread_id 还在，输入框里仍是 draft prompt。

调用关系：它直接验证 app.reset_app_ui_state_after_clear。测试把 App 的多个 UI 状态手动设成“脏”的，再确认这个函数只清 UI 临时物，不破坏 ChatWidget 持有的会话和草稿。

调用图：调用 5 个内部函数（read_only, new, make_test_app, defaults, new_transcript）；外部调用 5 个（new, new, assert!, assert_eq!, vec!）。

async fn clear_only_ui_reset_allows_active_skill_warning_to_render_again()

作用：测试清界面后，同一个当前仍存在的技能加载警告可以再次显示。否则用户清屏后，重要警告可能因为“已经显示过”而再也看不到。

数据流：测试准备一个 SkillErrorInfo。第一次查询 newly_active_errors 会返回这个错误，第二次因为已记录过而返回空。调用 reset_app_ui_state_after_clear 后，再次查询同一个错误，确认它又会作为新警告返回。

调用关系：它验证 app.reset_app_ui_state_after_clear 会重置 skill_load_warnings 的显示记忆。newly_active_errors 用来模拟界面判断哪些技能错误需要渲染。

调用图：调用 1 个内部函数（make_test_app）；外部调用 1 个（assert_eq!）。

async fn backtrack_esc_does_not_steal_empty_vim_insert_escape()

作用：测试在 Vim 输入模式下，Esc 如果应该用来退出插入模式，就不会被回退功能抢走。这样熟悉 Vim 的用户按 Esc 时，行为符合直觉。

数据流：测试先确认普通空输入框下 Esc 可以触发回退处理。然后打开 Vim 模式并进入插入模式，此时 ChatWidget 判断 Esc 应该退出插入模式，App 的回退 Esc 判断就应返回 false。实际处理 Esc 后，插入模式结束，回退未被启动，之后 Esc 又可以被回退逻辑处理。

调用关系：它测试 app.should_handle_backtrack_esc 和 chat_widget.should_handle_vim_insert_escape 的优先级关系。按键先由 ChatWidget 的 Vim 状态决定是否消费，回退逻辑只能在不抢 Vim Esc 的时候接手。

调用图：调用 1 个内部函数（make_test_app）；外部调用 3 个（assert!, Char, new）。

async fn side_conversations_reject_backtrack_esc_without_stealing_vim_insert_escape()

作用：测试在侧边会话里，回退快捷键会被拒绝，但同样不能抢走 Vim 插入模式的 Esc。这样侧边会话既不会支持不该支持的回退，也不会破坏编辑体验。

数据流：测试先把侧边会话标记为活跃，空输入框下 Esc 不应进入回退处理，而应被识别为侧边回退拒绝。随后打开 Vim 模式并进入插入模式，这时 Esc 应优先用于退出插入模式，所以既不处理回退，也不显示侧边回退拒绝。

调用关系：它同时验证 app.should_handle_backtrack_esc 和 app.should_reject_side_backtrack_esc。ChatWidget 的侧边会话状态和 Vim 插入状态共同决定 Esc 最终交给谁。

调用图：调用 1 个内部函数（make_test_app）；外部调用 3 个（assert!, Char, new）。

async fn side_backtrack_rejection_reports_unavailable_message_snapshot()

作用：测试用户在侧边会话里尝试回退时，App 会取消回退准备状态，并插入一条“此处不可用”的提示消息。这样用户知道操作为什么没发生。

数据流：测试创建带事件通道的 App，先把 backtrack.primed 设为 true。调用 reject_side_backtrack_esc 后，确认 primed 被清掉，并从事件通道取出一个 InsertHistoryCell。最后把这个提示单元渲染成文本，用快照确认提示内容稳定。

调用关系：它直接测试 app.reject_side_backtrack_esc。函数通过 app_event_tx 发出 InsertHistoryCell，测试从 app_event_rx 接收并检查显示结果。

调用图：调用 1 个内部函数（make_test_app_with_channels）；外部调用 3 个（assert!, assert_app_snapshot!, panic!）。

async fn start_config_write_test_app_server(app: &App) -> Result<AppServerSession>

作用：这是测试里的小工具函数，用当前 App 的配置启动一个嵌入式 app server。它让多条配置写入相关测试不用重复写同一段启动代码。

数据流：它接收一个 App 引用，从里面读取 config，然后调用 start_embedded_app_server_for_picker。成功时返回 AppServerSession，失败时把错误交回调用者。

调用关系：它被多条 feature flag 更新测试复用，比如开启或关闭 guardian 时检查审批策略怎么变化。它本身不做断言，只是把启动测试后台服务这件事包装成一个方便的 helper。

调用图：被 4 处调用（update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history, update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default, update_feature_flags_enabling_guardian_overrides_explicit_manual_review_policy, update_feature_flags_enabling_guardian_selects_auto_review）；外部调用 2 个（pin, start_embedded_app_server_for_picker）。

fn all_model_presets() -> Vec<ModelPreset>

作用：拿一份测试用的模型预设清单。测试会改这份清单里的字段，所以这里返回克隆出来的新副本，避免一个测试污染另一个测试。

数据流：它不接收参数，只读取项目测试支持代码里准备好的 TEST_MODEL_PRESETS → 复制一份完整列表 → 返回一个新的模型预设数组，后面的测试可以放心改。

调用关系：很多测试一开始都会调用它，先拿到一份“假装真实”的模型目录。之后测试会把这份目录交给选择新模型提示、判断迁移提示、查找升级目标等逻辑。

调用图：被 7 处调用（model_migration_prompt_shows_for_hidden_model, model_migration_prompt_skips_when_target_missing_or_hidden, prepare_startup_tooltip_override_persists_model_availability_nux_count, select_model_availability_nux_picks_only_eligible_model, select_model_availability_nux_returns_none_when_all_models_are_exhausted, select_model_availability_nux_skips_missing_and_exhausted_models, select_model_availability_nux_uses_existing_model_order_as_priority）。

fn model_availability_nux_config(shown_count: &[(&str, u32)]) -> ModelAvailabilityNuxConfig

作用：快速造一份“某个新模型提示已经显示过几次”的测试配置。这样测试不用手写一大段配置对象。

数据流：输入是一组模型名和次数，比如 gpt-5.4 显示过 3 次 → 它把模型名转成字符串，把这些键值放进 shown_count 表里 → 输出 ModelAvailabilityNuxConfig，供选择提示的逻辑判断是否还能再显示。

调用关系：几个检查新模型提示的测试会用它来模拟用户历史记录。它把简单的测试数据包装成正式配置，再交给 select_model_availability_nux 相关逻辑。

调用图：被 4 处调用（select_model_availability_nux_picks_only_eligible_model, select_model_availability_nux_returns_none_when_all_models_are_exhausted, select_model_availability_nux_skips_missing_and_exhausted_models, select_model_availability_nux_uses_existing_model_order_as_priority）。

fn model_migration_copy_to_plain_text(copy: &crate::model_migration::ModelMigrationCopy) -> String

作用：把模型迁移提示里的富文本内容转成普通文字，方便测试做快照比较。富文本就是带标题、段落、样式片段的文字；普通文字更容易看差异。

数据流：输入是一份 ModelMigrationCopy，也就是迁移提示文案 → 如果里面已经有 markdown 文本，就直接返回；否则把标题片段和正文每一行的文字片段按顺序拼起来 → 输出一整段普通字符串，不改原对象。

调用关系：隐藏模型迁移提示的测试会用它把生成出来的提示文案压平成文字，然后交给快照断言。它内部只新建字符串并拼接内容，不参与真正的界面显示。

调用图：外部调用 1 个（new）。

async fn model_migration_prompt_only_shows_for_deprecated_models()

作用：确认只有需要迁移的旧模型才会弹升级提示。当前模型已经是目标模型时，不应该再提示用户升级到自己。

数据流：它准备一份空的“已看过迁移提示”记录和测试模型清单 → 分别询问几个当前模型到目标模型的组合是否该显示迁移提示 → 用断言确认旧模型会显示、自身到自身不会显示。

调用关系：这是模型迁移判断逻辑的基础测试。它直接验证 should_show_model_migration_prompt 的决定是否符合产品预期，依赖 all_model_presets 提供完整模型目录。

调用图：外部调用 2 个（new, assert!）。

fn select_model_availability_nux_picks_only_eligible_model()

作用：确认当只有一个模型配置了“新模型可用提示”时，系统会选中它。这样启动时不会漏掉该给用户看的提示。

数据流：它先拿到测试模型清单 → 清空所有模型的提示配置，只给 gpt-5.4 填一条提示 → 构造一份没有历史显示次数的配置 → 调用选择逻辑 → 检查返回的提示模型和提示文字正好是 gpt-5.4。

调用关系：这个测试把 all_model_presets 和 model_availability_nux_config 作为准备工具，然后验证 select_model_availability_nux 的最简单成功路径。

调用图：调用 2 个内部函数（all_model_presets, model_availability_nux_config）；外部调用 1 个（assert_eq!）。

fn select_model_availability_nux_skips_missing_and_exhausted_models()

作用：确认已经显示到上限的模型会被跳过，系统会继续找下一个还能显示的新模型提示。这样用户不会被同一条提示反复打扰。

数据流：它准备两个带提示的模型：gpt-5.4 和 gpt-5.4-mini → 在配置里标记 gpt-5.4 已经达到最大显示次数 → 调用选择逻辑 → 结果应该跳过 gpt-5.4，返回 gpt-5.4-mini 的提示。

调用关系：这个测试用 model_availability_nux_config 模拟“某提示已经用完额度”。它检查 select_model_availability_nux 不只是找第一个有提示的模型，还会参考显示次数。

调用图：调用 2 个内部函数（all_model_presets, model_availability_nux_config）；外部调用 1 个（assert_eq!）。

fn select_model_availability_nux_uses_existing_model_order_as_priority()

作用：确认多个模型都能显示提示时，优先级来自现有模型列表的顺序。这样产品方只要调整模型清单顺序，就能控制先提示哪个。

数据流：它拿到测试模型清单 → 清掉所有提示，再给 gpt-5.4-mini 和 gpt-5.4 都加提示 → 用空历史配置调用选择逻辑 → 检查最终选中的是模型清单顺序里优先的那个提示。

调用关系：这个测试仍然围绕 select_model_availability_nux。all_model_presets 提供带顺序的模型表，model_availability_nux_config 提供空的显示历史，断言用来锁住优先级规则。

调用图：调用 2 个内部函数（all_model_presets, model_availability_nux_config）；外部调用 1 个（assert_eq!）。

fn select_model_availability_nux_returns_none_when_all_models_are_exhausted()

作用：确认所有可提示的模型都已经达到显示上限时，不会再返回任何启动提示。也就是说，没内容可说时就安静。

数据流：它只给 gpt-5.4 设置一条可用提示 → 配置里标记这条提示已经显示到最大次数 → 调用选择逻辑 → 输出应该是 None，表示没有要展示的提示。

调用关系：这是新模型提示选择逻辑的收尾场景测试。它通过 all_model_presets 准备模型，通过 model_availability_nux_config 模拟显示次数已耗尽。

调用图：调用 2 个内部函数（all_model_presets, model_availability_nux_config）；外部调用 1 个（assert_eq!）。

async fn prepare_startup_tooltip_override_persists_model_availability_nux_count()

作用：确认启动时如果展示了新模型提示，显示次数会立刻写进配置文件。这样下次启动时系统知道这条提示已经出现过，不会无限重复。

数据流：它创建一个临时配置目录 → 加载一份配置 → 准备只有 gpt-5.4 带提示的模型清单 → 调用 prepare_startup_tooltip_override → 检查返回给界面的提示文字，同时检查内存里的显示次数变成 1 → 再重新加载配置，确认磁盘上的配置也保存了这个次数。

调用关系：这个测试连接了提示选择逻辑和配置持久化逻辑。它用 all_model_presets 准备数据，然后通过 ConfigBuilder 重新加载配置，验证 prepare_startup_tooltip_override 不只是返回文字，还真的把次数存下来了。

调用图：调用 1 个内部函数（all_model_presets）；外部调用 2 个（assert_eq!, default）。

async fn accepted_model_migration_persists_target_default_reasoning_effort()

作用：确认用户接受模型迁移后，默认模型和默认推理强度都会改成目标模型要求的值，并且相关保存事件都会发出去。推理强度可以理解为模型回答前“多用多少脑力”。

数据流：它创建临时配置，把当前模型设成 gpt-5.2，推理强度设成 XHigh → 建一个事件通道，像邮箱一样接收应用内部通知 → 调用 apply_accepted_model_migration，把目标设为 gpt-5.4，目标推理强度设为 Medium → 检查配置已经改好 → 再从通道里逐个取事件，确认包括“已确认迁移提示”“更新模型”“更新推理强度”“保存模型选择”。

调用关系：这个测试验证接受迁移这一动作的完整后果。它使用 unbounded_channel 建立测试用事件通道，用 AppEventSender 发事件，再用断言检查 apply_accepted_model_migration 是否把配置更新和界面/保存通知都安排好了。

调用图：调用 1 个内部函数（new）；外部调用 4 个（assert_eq!, assert_matches!, default, unbounded_channel）。

async fn model_migration_prompt_respects_hide_flag_and_self_target()

作用：确认迁移提示会尊重“已经看过/不再显示”的记录，也不会在当前模型和目标模型相同的时候弹出。这样用户不会被无意义提示骚扰。

数据流：它准备一份已看过记录，表示 gpt-5.2 到 gpt-5.4 的提示已经处理过 → 调用迁移提示判断逻辑 → 检查这种情况不显示；再测试 gpt-5.4 到 gpt-5.4 → 也应该不显示。

调用关系：这个测试直接约束 should_show_model_migration_prompt 的两个拦截条件：已隐藏提示、自我迁移。它用空或简单的记录表模拟用户历史。

调用图：外部调用 2 个（new, assert!）。

async fn model_migration_prompt_skips_when_target_missing_or_hidden()

作用：确认如果升级目标模型不存在，或者目标模型被隐藏在选择器之外，就不要弹迁移提示。因为用户看到提示后却找不到目标模型，会很困惑。

数据流：它先拿测试模型清单 → 改造当前模型，让它指向一个不存在的升级目标 → 检查迁移提示不会显示，也查不到目标预设 → 接着把真实目标 gpt-5.4 标成不在选择器显示 → 再次检查迁移提示不会显示，目标查找也返回空。

调用关系：这个测试同时验证 should_show_model_migration_prompt 和 target_preset_for_upgrade。all_model_presets 给它一份可改的模型表，它通过修改目标存在性和显示状态来模拟异常配置。

调用图：调用 1 个内部函数（all_model_presets）；外部调用 1 个（assert!）。

async fn model_migration_prompt_shows_for_hidden_model()

作用：确认当前模型即使被隐藏在模型选择器里，只要它本身需要迁移、目标模型可见，仍然应该显示迁移提示。这样老用户正在用的隐藏旧模型也能被引导到新模型。

数据流：它创建临时配置并读取用户的迁移提示记录 → 拿测试模型清单，把当前模型 gpt-5.3-codex 标成隐藏 → 找到它配置的升级目标，并确保目标模型可见 → 调用判断逻辑确认应该显示提示 → 找到目标模型详情 → 用当前模型、目标模型、链接、文案、目标说明等生成迁移提示 → 把提示转成普通文字并做快照比较。

调用关系：这是一个更贴近真实用户场景的迁移测试。它用 all_model_presets 准备和改造模型目录，调用迁移判断、目标查找和文案生成逻辑，最后通过快照断言锁住最终给用户看的文字。

调用图：调用 1 个内部函数（all_model_presets）；外部调用 3 个（assert!, assert_snapshot!, default）。

async fn session_summary_skips_when_no_usage_or_resume_hint()

作用：这个测试确认：当既没有 token 用量，也没有可恢复会话信息时，程序应该什么摘要都不显示。这样用户不会看到一段空洞或误导性的结束提示。

数据流：进去的是默认的 TokenUsage，也就是各项用量都是 0；会话编号、会话名、记录文件路径也都没有。测试把这些交给 session_summary，然后检查结果是 None，意思是“没有摘要可显示”。它不改动文件，也不创建任何会话数据。

调用关系：这是 session_summary 最基础的空输入检查。测试本身只用断言来确认结果为空，用来守住一个底线：没有实质内容时，界面层不应该硬凑一条总结。

调用图：外部调用 1 个（assert!）。

async fn session_summary_skips_resume_hint_until_rollout_exists()

作用：这个测试确认：光有会话编号还不够，只有会话记录文件真的存在后，才可以提示用户恢复。这样可以避免用户按提示恢复时却发现没有东西可恢复。

数据流：进去的是零用量的 TokenUsage、一个固定格式的会话编号、没有会话名，以及一个临时目录里的 rollout.jsonl 路径。测试故意不创建这个文件，然后调用 session_summary。出来的结果应该还是 None，表示程序不会因为只有编号就贸然显示恢复命令。

调用关系：它接在空输入测试之后，检查另一个边界：有恢复线索但还没落盘。这里用 ThreadId::from_string 把字符串变成会话编号，用默认用量制造“没有 token 消耗”的场景，最后用断言确认 session_summary 没有生成摘要。

调用图：调用 1 个内部函数（from_string）；外部调用 2 个（assert!, default）。

async fn session_summary_includes_resume_hint_for_persisted_rollout()

作用：这个测试确认：当确实有 token 用量，并且会话记录文件已经存在时，摘要里应该同时显示用量和恢复命令。它保证用户结束后能看到花了多少额度，也知道下次怎么继续。

数据流：进去的是一份明确的用量数据：输入 10、输出 2、总计 12；还有一个会话编号和一个临时记录文件路径。测试先往这个路径写入一行内容，模拟会话已经保存到磁盘。然后调用 session_summary，出来的 summary 应该包含固定格式的用量行，以及 codex resume 加会话编号的恢复提示。

调用关系：这是对正常成功路径的测试。它用文件写入来制造“会话已经持久化”的条件，再用 assert_eq! 精确比较 session_summary 生成的文字，防止以后有人改坏提示格式或漏掉 token 用量。

调用图：调用 1 个内部函数（from_string）；外部调用 3 个（default, assert_eq!, write）。

async fn session_summary_names_picker_item_when_thread_has_name()

作用：这个测试确认：如果会话有名字，恢复提示应该更像给人看的说明，告诉用户恢复后选择这个名字对应的项目。这样比只显示一串长编号更友好。

数据流：进去的是同样的 token 用量、同一个会话编号、一个会话名 my-session，以及已经写好的临时记录文件。session_summary 处理后会返回摘要。测试重点检查 resume_hint：它不再是简单的 codex resume 加编号，而是提示用户运行 codex resume 后选择 my-session，并附上编号用于确认。

调用关系：它补充了有会话名时的分支。和前一个测试一样，它先写入记录文件，确保恢复条件成立；然后用 assert_eq! 锁定用户将看到的恢复提示文字，保证命名会话在选择器里的提示不会退化成难懂的编号。

调用图：调用 1 个内部函数（from_string）；外部调用 3 个（default, assert_eq!, write）。

fn startup_waiting_gate_is_only_for_fresh_or_exit_session_selection()

作用：这个测试确认：只有“新开会话”和“退出”这两种启动选择需要进入等待门。恢复旧会话或分叉旧会话时，不应该被这个等待机制挡住。

数据流：进去的是四种不同的启动选择：从头开始、退出、恢复、分叉。测试把它们交给 App::should_wait_for_initial_session 这个判断函数，看它返回 true 还是 false。出来的结果必须是：新开和退出要等，恢复和分叉不用等；否则说明启动流程会在错误场景下卡住。

调用关系：它是在测试启动前置判断的最小规则。后面的测试会继续验证这个等待门一旦打开或关闭，会不会影响线程事件处理；这个测试先保证门本身只在该出现的时候出现。

调用图：外部调用 1 个（assert_eq!）。

fn startup_paused_goal_prompt_gate_is_only_for_quiet_resume()

作用：这个测试确认：只有“安静地恢复旧会话”时，应用才需要追问用户接下来要做什么。所谓安静，是指没有预填文字，也没有启动时带入图片。

数据流：进去的是恢复或分叉的目标会话、可选的初始文字、以及启动时带入的图片列表。测试把这些组合交给 App::should_prompt_for_paused_goal_after_startup_resume。出来的结果必须是：恢复旧会话且没有文字、没有图片时才提示；只要已有文字、已有图片、不是恢复而是新开或分叉，就不提示。

调用关系：它测试的是启动后是否弹出“下一步目标”提示的开关。这个判断和等待线程不是一回事，但同样发生在应用刚进入会话时，用来避免没必要的打扰。

调用图：调用 1 个内部函数（new）；外部调用 6 个（from, new, assert!, Fork, Resume, vec!）。

fn startup_waiting_gate_holds_active_thread_events_until_primary_thread_configured()

作用：这个测试确认：新开会话时，在主线程编号还没确定前，应用不能处理活跃线程事件。这样可以防止后台事件先跑进来，导致消息挂到错误线程上。

数据流：一开始输入的是“从头开始”的启动选择，得到 wait_for_initial_session 为 true。接着测试有事件接收器时是否能处理事件，结果应为 false。然后它分别用“没有主线程编号”和“有主线程编号”去问是否该停止等待：没有编号不能停，有编号才能停。最后等待状态变成 false 后，再检查线程事件可以被处理。

调用关系：它把前面测试过的等待门放进更完整的小流程里：先挡住事件，再等主线程配置好，最后放行事件。这里会调用 should_wait_for_initial_session、should_stop_waiting_for_initial_session 和 should_handle_active_thread_events 这几个启动判断函数。

调用图：调用 1 个内部函数（new）；外部调用 3 个（assert_eq!, should_stop_waiting_for_initial_session, should_wait_for_initial_session）。

fn startup_waiting_gate_not_applied_for_resume_or_fork_session_selection()

作用：这个测试确认：恢复旧会话和分叉会话时，不应该套用“等待新主线程”的规则。因为这两种情况已经有目标线程，不需要像新会话那样等编号生成。

数据流：进去的是一个恢复目标和一个分叉目标，各自带有路径和线程编号。测试先问 App::should_wait_for_initial_session 是否需要等待，再把结果交给 App::should_handle_active_thread_events。出来的结果必须是：两种情况下都允许处理活跃线程事件。

调用关系：它补足了等待门规则的反面场景。前一个测试证明新开会话需要先挡住事件；这个测试证明恢复和分叉不能被误挡。

调用图：调用 1 个内部函数（new）；外部调用 5 个（from, assert_eq!, should_wait_for_initial_session, Fork, Resume）。

async fn startup_thread_started_submits_queued_startup_input()

作用：这个测试确认：用户在启动线程还没准备好时输入并提交的文字，不会丢掉。等线程真正启动成功后，这段文字应该自动作为用户消息发出去。

数据流：进去的是一个测试用应用、事件通道和操作通道。测试先把应用标成“正在等待启动线程”，再让聊天输入框进入排队模式，然后塞入一段文字并模拟按回车。此时文字应留在队列里。接着启动一个嵌入式应用服务器，假装新线程成功创建。处理完成后，操作通道里应该出现一次用户回合，内容正是之前排队的那段文字。

调用关系：它测试 App::handle_startup_thread_started 成功路径上的重要副作用：线程接上以后，要把 chat_widget 里暂存的用户输入提交出去。这个测试通过 next_user_turn_op 从输出通道里取结果，验证应用真的把活交给了后续执行流程。

调用图：调用 1 个内部函数（new）；外部调用 6 个（pin, new, new, assert_eq!, start_embedded_app_server_for_picker, panic!）。

async fn startup_thread_start_failure_returns_error()

作用：这个测试确认：新线程启动失败时，应用要明确返回错误，并清掉“还在启动中”的标记。这样用户不会留在一个看似可用、其实没有会话的聊天界面里。

数据流：进去的是一个处于 pending_startup_thread_start 状态的测试应用，以及一个模拟的启动失败结果 Err("boom")。测试把失败结果交给 handle_startup_thread_started。出来的应该是错误信息，里面说明通过应用服务器启动新会话失败；同时 pending 标记变成 false，primary_thread_id 仍然是 None。

调用关系：它覆盖的是 App::handle_startup_thread_started 的失败分支。和成功提交排队输入的测试相对，这个测试保证失败不会被悄悄吞掉，也不会留下半配置状态。

调用图：外部调用 4 个（pin, assert!, assert_eq!, start_embedded_app_server_for_picker）。

fn stale_startup_thread_started_removes_local_routing_state() -> Result<()>

作用：这个测试确认：如果启动线程的结果已经过时，应用要把这个旧线程的本地状态清掉。否则界面里可能残留一个不该出现的代理或事件通道，后面就容易串线。

数据流：进去的是一个已经有主线程的应用。测试先人为放入两个线程：一个当前主线程，一个过期线程；还给过期线程放入事件通道和导航条目。然后它把“过期线程启动成功”的结果交给 handle_startup_thread_started。出来的状态应该是：过期线程的事件通道被移除，导航记录被删除，当前活跃线程仍然是原来的主线程。

调用关系：它测试的是启动回调到达太晚时的清理逻辑。这里会启动测试运行时和嵌入式应用服务器，再调用 handle_startup_thread_started，确认这个函数不会把旧结果误接成当前会话。

调用图：调用 2 个内部函数（new, new）；外部调用 5 个（new, assert!, assert_eq!, start_embedded_app_server_for_picker, new_multi_thread）。

async fn ignore_same_thread_resume_reports_noop_for_current_thread()

作用：这个测试确认：如果用户想恢复的会话，其实就是当前正在看的会话，应用应该什么都不重开，只给用户一条提示。这个行为叫 noop，也就是“没有实际操作”。

数据流：进去的是一个已经显示某个线程会话的应用，并且这个线程也被设为当前活跃线程。测试清空之前的界面事件后，调用 app.ignore_same_thread_resume，传入同一个线程编号和路径。出来的结果应为 true，表示已忽略；事件通道里还应出现一条历史提示，内容类似“已经在查看这个项目”。

调用关系：它测试恢复会话前的防重复检查。ignore_same_thread_resume 被用来拦住“恢复当前会话”这种没必要的操作，并把说明文字交给界面历史区显示。

调用图：调用 2 个内部函数（new, new_with_session）；外部调用 3 个（new, assert!, panic!）。

async fn ignore_same_thread_resume_allows_reattaching_displayed_inactive_thread()

作用：这个测试确认：如果一个会话虽然显示在聊天框里，但并不是当前活跃线程，应用仍然允许重新挂接它。也就是说，不能只看画面上像不像同一个会话，还要看它是不是当前真正活跃的线程。

数据流：进去的是一个测试应用和一个线程会话。测试把这个会话交给聊天框显示，但没有把它注册成活跃线程。然后调用 ignore_same_thread_resume，传入同一个线程目标。出来的结果应为 false，表示不能忽略，后续应该允许重新连接；同时不会往历史记录里塞提示消息。

调用关系：它补充了前一个测试的边界情况。前一个测试说“当前活跃线程相同就忽略”，这个测试说明“只是显示相同但未激活”不能忽略，避免应用错过真正需要重新挂接的场景。

调用图：调用 1 个内部函数（new）；外部调用 1 个（assert!）。

fn agent_status_uses_bounded_buffered_activity()

作用：这个测试确认子代理状态界面不会显示命令执行产生的超长输出。它只应该展示“运行了什么命令”和后续简短消息，避免终端界面被大量日志淹没。

数据流：进去的是一组伪造的事件：一个已完成的命令执行事件，里面故意放了大量重复的输出；再加上一条代理消息。测试把这些事件放进 ThreadEventStore（一块有容量限制的事件存储区），再用 AgentStatusThreadPreview 把事件整理成预览，最后用 AgentStatusHistoryCell 渲染成文字。出来的是一段界面文本；测试检查它和预期快照一致，并确认里面不包含“unbounded output”这段超长输出内容。

调用关系：这个函数由测试框架在跑测试时调用。它先用 ThreadEventStore::new 准备事件容器，再通过 ServerNotification::ItemCompleted 放入完成通知，用 AbsolutePathBuf::try_from 准备命令所在目录，然后交给 AgentStatusThreadPreview::from_store 和 AgentStatusHistoryCell::new 生成可显示内容。最后它用 insta::assert_snapshot! 对比界面样子，并用 assert! 再补一刀，确保超长输出没有混进去。

调用图：调用 4 个内部函数（new, from_store, new, try_from）；外部调用 5 个（ItemCompleted, new, assert!, assert_snapshot!, vec!）。

fn agent_status_uses_reasoning_summaries_only()

作用：这个测试确认子代理状态界面只显示推理摘要，不显示原始推理内容。这样可以避免把内部思考过程或不适合展示的信息泄露到界面上。

数据流：进去的是两个伪造的推理事件：第一个有安全摘要，也有隐藏的原始推理；第二个没有摘要，只有原始推理。测试把它们放进事件存储区，再生成子代理预览并渲染成文字。出来的结果应该只包含“safe summary”这条摘要；测试还明确检查文本里没有“hidden raw reasoning”和“raw-only reasoning”。

调用关系：这个函数同样由测试框架自动运行。它用 ThreadEventStore::new 建立事件记录，用 ServerNotification::ItemCompleted 塞入推理完成事件，然后让 AgentStatusThreadPreview::from_store 从记录里提取可展示内容，再由 AgentStatusHistoryCell::new 变成界面单元。最后通过 insta::assert_snapshot! 固定正确显示效果，并通过 assert! 确认原始推理没有被显示出来。

调用图：调用 3 个内部函数（new, from_store, new）；外部调用 5 个（ItemCompleted, new, assert!, assert_snapshot!, vec!）。

fn desktop_thread_opened_history_snapshot()

作用：这个测试检查“桌面线程已打开”这条普通提示在历史记录里显示得是否正确。有人改了提示文字或排版时，它会第一时间暴露变化。

数据流：进去的是固定的成功提示文字 DESKTOP_THREAD_OPENED_MESSAGE，并且没有额外提示 hint → 它调用 new_info_event 造出一条普通信息类历史消息，再把这条消息渲染成文本 → 最后 assert_snapshot! 把渲染结果和名为 desktop_thread_opened_history 的标准快照对比，不直接返回业务结果，只通过测试通过或失败来说明显示是否一致。

调用关系：它是测试框架运行时直接调用的测试用例。它把造消息的工作交给 new_info_event，把最终对比工作交给 insta 的 assert_snapshot!；中间依赖 render_cell 把历史消息变成可比较的纯文本。

调用图：外部调用 2 个（new_info_event, assert_snapshot!）。

fn desktop_thread_open_error_history_snapshot()

作用：这个测试检查“桌面线程打开失败”这类错误消息的显示效果。它保证错误原因，比如 launch failed，会被放进历史记录里并按预期格式显示。

数据流：进去的是一段模拟失败原因 launch failed → 它先通过 desktop_thread_open_error_message 形成完整错误文案，再用 new_error_event 包成一条错误类历史消息，然后渲染成多行文本 → assert_snapshot! 把结果和 desktop_thread_open_error_history 这个标准快照比较，测试失败就表示错误显示样式变了。

调用关系：它是另一个由测试框架启动的快照测试，专门覆盖失败场景。它依赖错误消息构造函数和 new_error_event 准备测试对象，再把比对交给 insta 的 assert_snapshot!，用来补足成功提示测试没有覆盖到的错误显示路径。

调用图：外部调用 2 个（new_error_event, assert_snapshot!）。

fn render_cell(cell: &impl HistoryCell) -> String

作用：这个小工具函数把一条历史记录消息变成普通字符串，方便快照测试比较。它相当于把界面上的一格内容“抄成文本”。

数据流：进去的是一个实现了 HistoryCell 的对象，也就是一条能在历史区显示的消息 → 它要求这个对象按宽度 80 生成显示用的多行内容，然后把每一行转成字符串 → 最后用换行符拼成一个完整文本返回，不修改原来的消息对象。

调用关系：它服务于本文件里的快照测试，是测试和真实显示逻辑之间的桥。具体怎么按宽度排版，它不自己决定，而是交给 cell.display_lines；它只负责把排版结果整理成 assert_snapshot! 能比较的一整段文字。

调用图：外部调用 1 个（display_lines）。

fn app_scoped_key_path_quotes_dotted_app_ids()

作用：这个测试确认：当应用 ID 里带点号时，生成配置路径时会把整个应用 ID 用引号包起来。这样可以避免把 plugin.linear 错当成 plugin 下面的 linear。

数据流：进去的是应用 ID“plugin.linear”和配置项名“enabled” → 测试调用生成应用专属配置路径的函数 → 出来应该是 apps."plugin.linear".enabled；如果结果不是这个字符串，测试就失败。

调用关系：它直接检查 app_scoped_key_path 这个配置路径拼装工具的行为，并用 assert_eq! 做最终比对。它不参与程序运行时流程，只在测试阶段防止以后有人改代码时破坏这个路径规则。

调用图：外部调用 1 个（assert_eq!）。

fn trusted_project_edit_targets_project_trust_level()

作用：这个测试确认：把一个项目标记为可信时，程序生成的配置修改命令会指向这个项目的 trust_level 字段，并把值设成 trusted。

数据流：进去的是项目路径 /workspace/team.project → 测试调用 trusted_project_edit 生成一条配置编辑请求 → 出来应该是一份 ConfigEdit：键路径是 projects."/workspace/team.project".trust_level，值是 trusted，合并方式是 Replace（替换旧值）。

调用关系：它检查 trusted_project_edit 这个生成配置编辑内容的函数，并用 assert_eq! 对比完整结构。这个测试保护的是“信任项目”这类界面操作背后的落点，避免它写到错误的配置字段。

调用图：外部调用 1 个（assert_eq!）。

fn format_config_error_preserves_server_validation_message()

作用：这个测试确认：配置写入失败时，即使界面又包了一层错误说明，最终展示出来的文字仍然包含服务器给出的详细拒绝原因。

数据流：进去的是一个人为造出的错误：里面包含服务器说的“某个配置违反托管要求” → 测试再给它包上一层“TUI 中写配置失败”的上下文 → 调用 format_config_error 格式化错误 → 出来的字符串必须同时保留外层说明和内层服务器验证消息。

调用关系：它用 eyre! 构造测试用错误，再用 assert_eq! 检查 format_config_error 的输出。它保护的是错误展示链路：当配置服务拒绝请求时，用户不能只看到笼统失败，而要看到真正原因。

调用图：外部调用 2 个（assert_eq!, eyre!）。

fn external_agent_config_migration_messages_snapshot()

作用：这个测试函数检查外部代理配置迁移相关的所有用户提示文案是否和预期一致。有人改到这些文字时，它能提醒开发者：这是有意修改，还是不小心改坏了。

数据流：进去的是几种测试数量 0、1、2，以及当前文件上层提供的一组迁移提示文字常量和生成消息的函数。它把成功迁移消息和各种固定状态消息合并成一个文本块，中间用换行隔开。出来的是一次快照断言结果：如果文本和保存的标准快照一致，测试通过；如果不一致，测试失败并提示差异。

调用关系：这个函数在测试运行时由 Rust 的测试框架自动调用。它自己负责拼出要检查的完整文案，然后把最后的比对工作交给 insta::assert_snapshot! 这个快照测试宏；这个宏会拿当前文本和名为 external_agent_config_migration_messages 的已保存快照做比较。

调用图：外部调用 1 个（assert_snapshot!）。

fn load_local_chatgpt_auth(
    codex_home: &Path,
    auth_credentials_store_mode: AuthCredentialsStoreMode,
    forced_chatgpt_workspace_id: Option<&[String]>,
) -> Result<LocalChatgptAuth, String>

作用：读取本机保存的 ChatGPT 登录信息，并把测试真正需要的几项内容取出来。有人会用它来确认当前测试环境确实有可用的 ChatGPT 登录，而不是误用了 API Key 或错误工作区。

数据流：输入是 Codex 主目录路径、凭证保存方式，以及可选的允许工作区列表。它先读取本地 auth.json；如果没有文件、读取失败、是 API Key 登录、缺少 token，都会变成清楚的错误信息。成功时，它取出 access token、账号/工作区 ID，并把套餐类型转成小写，最后返回一个 LocalChatgptAuth；它不修改文件，只读取和校验。

调用关系：这是本文件的核心函数，被多个测试直接调用。正常路径由 tests::loads_local_chatgpt_auth_from_managed_auth、tests::prefers_managed_auth_over_external_ephemeral_tokens、tests::preserves_usage_based_plan_type_wire_name 检查；失败路径由 tests::rejects_missing_local_auth 和 tests::rejects_api_key_auth 检查。它把实际读文件的工作交给外部的 load_auth_dot_json。

调用图：调用 1 个内部函数（default）；被 5 处调用（loads_local_chatgpt_auth_from_managed_auth, prefers_managed_auth_over_external_ephemeral_tokens, preserves_usage_based_plan_type_wire_name, rejects_api_key_auth, rejects_missing_local_auth）；外部调用 3 个（load_auth_dot_json, format!, matches!）。

fn fake_jwt(email: &str, account_id: &str, plan_type: &str) -> String

作用：生成一个假的 JWT 登录票据，方便测试不用真的去登录 ChatGPT。它把邮箱、工作区 ID、套餐类型塞进票据里，让后面的读取逻辑有东西可解析。

数据流：输入是邮箱、账号/工作区 ID 和套餐类型。它组装一个 JWT 头部和一段 JSON 载荷，把它们转成 JSON 字节，再用 base64 URL 安全格式编码，最后拼成“头部.载荷.签名”这样的字符串。输出是一串假的 token；它不写文件。

调用关系：它是测试里的造数据工具。tests::write_chatgpt_auth 用它来生成 id token 和 access token；tests::prefers_managed_auth_over_external_ephemeral_tokens 也用它制造另一套外部临时 token，用来测试选择规则。

调用图：外部调用 3 个（format!, json!, to_vec）。

fn write_chatgpt_auth(codex_home: &Path, plan_type: &str)

作用：往临时目录里写一份看起来像真实 ChatGPT 登录的认证文件。测试用它先搭好“已经登录”的现场，再调用真正的读取函数。

数据流：输入是 Codex 主目录路径和套餐类型。它先用 tests::fake_jwt 造出 id token 和 access token，再解析 id token 里的声明，组装 AuthDotJson 认证对象，填入工作区 ID、刷新 token 和当前时间，最后用 save_auth 保存到文件。结果是磁盘上多了一份测试用的 ChatGPT 登录记录。

调用关系：它是多个成功路径测试的准备步骤。tests::loads_local_chatgpt_auth_from_managed_auth、tests::prefers_managed_auth_over_external_ephemeral_tokens、tests::preserves_usage_based_plan_type_wire_name 都先调用它写入认证信息，再交给 load_local_chatgpt_auth 读取验证。

调用图：调用 2 个内部函数（default, parse_chatgpt_jwt_claims）；外部调用 3 个（now, save_auth, fake_jwt）。

fn loads_local_chatgpt_auth_from_managed_auth()

作用：验证最基本的成功场景：本地有 ChatGPT 登录时，读取函数应该能拿到正确的工作区、套餐类型和访问令牌。

数据流：它先创建一个临时目录，再用 tests::write_chatgpt_auth 写入 business 套餐的 ChatGPT 登录。然后调用 load_local_chatgpt_auth，并要求工作区必须是 workspace-1。最后断言返回的账号 ID 是 workspace-1，套餐是 business，access token 不是空的。

调用关系：这是对 load_local_chatgpt_auth 的主路径测试。它依赖 tests::write_chatgpt_auth 搭建本地认证文件，然后检查核心函数读出的结果是否符合预期。

调用图：调用 1 个内部函数（load_local_chatgpt_auth）；外部调用 4 个（new, assert!, assert_eq!, write_chatgpt_auth）。

fn rejects_missing_local_auth()

作用：验证没有本地登录信息时，读取函数会明确失败，而不是假装成功或返回空数据。

数据流：它创建一个全新的临时目录，但不写任何认证文件。然后调用 load_local_chatgpt_auth。函数应该返回错误，测试再检查错误文字正好是“no local auth available”。

调用关系：这是 load_local_chatgpt_auth 的缺文件/未登录场景测试。它不需要任何辅助写入函数，只用空目录来确认核心函数能把“没有登录”说清楚。

调用图：调用 1 个内部函数（load_local_chatgpt_auth）；外部调用 2 个（new, assert_eq!）。

fn rejects_api_key_auth()

作用：验证 API Key 登录不能被当成 ChatGPT 登录使用。这样可以避免测试拿错凭证类型，导致后续逻辑误判。

数据流：它先创建临时目录，然后手动保存一份 auth.json，里面标明认证方式是 ApiKey，并带有 openai_api_key。接着调用 load_local_chatgpt_auth。预期结果是失败，并返回“local auth is not a ChatGPT login”。

调用关系：这是 load_local_chatgpt_auth 的错误类型测试。它用 save_auth 准备一份 API Key 凭证，再确认核心函数会拒绝它，而不是继续读取 token。

调用图：调用 2 个内部函数（default, load_local_chatgpt_auth）；外部调用 3 个（new, assert_eq!, save_auth）。

fn prefers_managed_auth_over_external_ephemeral_tokens()

作用：验证同时存在两类登录信息时，读取函数会优先使用本地托管的 ChatGPT 登录，而不是外部临时 token。

数据流：它先在临时目录写入 workspace-1、business 套餐的本地登录。然后又用 login_with_chatgpt_auth_tokens 写入 workspace-2、enterprise 套餐的外部临时登录。接着调用 load_local_chatgpt_auth，并允许两个工作区。最后检查读出来的是 workspace-1 和 business，说明本地托管登录胜出。

调用关系：这是选择优先级的测试。它用 tests::write_chatgpt_auth 和 tests::fake_jwt 准备两套凭证，然后通过 load_local_chatgpt_auth 的返回值确认系统没有被外部临时 token 覆盖。

调用图：调用 1 个内部函数（load_local_chatgpt_auth）；外部调用 5 个（new, assert_eq!, login_with_chatgpt_auth_tokens, fake_jwt, write_chatgpt_auth）。

fn preserves_usage_based_plan_type_wire_name()

作用：验证特殊的套餐类型名字会被原样保留下来。这里关心的是传输层使用的原始名字，不能被改成别的友好显示名。

数据流：它创建临时目录，写入套餐类型为 self_serve_business_usage_based 的 ChatGPT 登录。然后调用 load_local_chatgpt_auth 读取。最后断言返回的套餐类型仍然是同一个字符串。

调用关系：这是 load_local_chatgpt_auth 对套餐字段处理方式的测试。它通过 tests::write_chatgpt_auth 准备特定套餐名，再确认核心函数只做小写化，不乱改这个面向接口的名字。

调用图：调用 1 个内部函数（load_local_chatgpt_auth）；外部调用 3 个（new, assert_eq!, write_chatgpt_auth）。

async fn dismiss_version_creates_cache_file_when_missing()

作用：这个测试确认：当版本缓存文件不存在时，忽略某个版本会自动创建这个文件，并把忽略信息正确写进去。它保护的是第一次使用或缓存被删掉后的场景。

数据流：进去的是一个临时创建的空目录和要忽略的版本号 “999.0.0” → 测试用这个目录生成配置，找到版本缓存文件路径，然后调用忽略版本的功能 → 出来的是一个新建的缓存文件；测试读回文件后确认里面的 latest_version、dismissed_version 和 last_checked_at 都符合预期。

调用关系：这个函数是由测试框架在运行测试时自动调用的。它会用 tempdir 创建安全的临时目录，用 ConfigBuilder 的默认配置作为起点，再触发 dismiss_version 的真实写入行为，最后用 assert_eq! 比较读回来的结果和预期值。

调用图：外部调用 3 个（assert_eq!, default, tempdir）。

fn paste_burst_newline_does_not_submit_short_first_line()

作用：这个测试确认：如果用户像粘贴一样快速输入短短的第一行、马上出现换行、再接着输入第二行，输入框不能把第一个换行当成提交。它保护的是“多行粘贴不要被截断”的体验。

数据流：它先准备一个新的输入框和一个接收提交结果的通道，再按毫秒级间隔模拟输入第一行、回车、第二行。中途它检查通道里没有收到提交，输入框也没有结束。然后它模拟隔了更久之后再按一次回车，最后应该收到完整的“第一行换行第二行”，输入框也标记为完成。

调用关系：它是一个独立测试用例。开始时通过 custom_prompt_view 搭好测试用输入框，用 elapsed 造出不同的时间间隔，再把这些带时间的按键交给输入框。它不处理真正的界面显示，只验证 CustomPromptView 对“快速粘贴”和“真正提交”的判断是否正确。

调用图：调用 2 个内部函数（custom_prompt_view, elapsed）；外部调用 5 个（now, Char, from, assert!, assert_eq!）。

fn paste_burst_newline_after_tab_does_not_submit()

作用：这个测试确认：快速输入里即使夹了一个 Tab 键，紧接着的回车也不应该被误认为提交。它防止某些带缩进或特殊按键的粘贴内容把输入框提前结束。

数据流：它创建输入框后，按很短的时间间隔模拟输入 x、Tab、Enter、rest。随后检查没有任何提交发生，输入框也还没完成。等到稍后再按一次 Enter，才应该收到最终文本“x\nrest”，并且输入框进入完成状态。

调用关系：它和其他测试一样，依靠 custom_prompt_view 创建可观察的输入框，依靠 elapsed 控制按键之间的时间差。它专门补充覆盖了 Tab 参与时的场景，确保输入框的粘贴判断不会因为 Tab 这种特殊键而失效。

调用图：调用 2 个内部函数（custom_prompt_view, elapsed）；外部调用 5 个（now, Char, from, assert!, assert_eq!）。

fn delayed_enter_after_typing_submits()

作用：这个测试确认：如果用户正常打完字，然后隔了一小会儿按回车，输入框应该把它当成提交。它保证防误提交机制不会过头，不能让正常提交失灵。

数据流：它创建输入框，模拟用户以比较正常的节奏输入 foo，然后在稍后的时间点按 Enter。结果应该是通道收到“foo”，输入框也变成完成状态。

调用关系：它同样使用 custom_prompt_view 准备测试环境，用 elapsed 安排按键时间。前两个测试验证“太快的回车别提交”，这个测试验证“慢下来的回车要提交”，三者一起把这个输入框的核心判断边界夹住。

调用图：调用 2 个内部函数（custom_prompt_view, elapsed）；外部调用 5 个（now, Char, from, assert!, assert_eq!）。

fn custom_prompt_view() -> (CustomPromptView, Receiver<String>)

作用：这个辅助函数给每个测试准备一个新的 CustomPromptView 和一个用来接收提交文本的通道。这样每个测试都不用重复写一遍搭建输入框的代码。

数据流：它没有外部输入。它先创建一个发送端和接收端组成的通道，然后新建一个标题为“Edit goal”的输入框，并给输入框塞入一个回调函数：一旦输入框提交文字，就把文字发进通道。最后它把输入框和通道接收端一起交给测试用例。

调用关系：它被三个测试函数调用，是这些测试的共同准备步骤。测试函数负责模拟按键；CustomPromptView 在被提交时会调用这里传入的回调；回调再把提交内容送到通道里，让测试函数可以检查到底有没有提交、提交了什么。

调用图：调用 1 个内部函数（new）；被 3 处调用（delayed_enter_after_typing_submits, paste_burst_newline_after_tab_does_not_submit, paste_burst_newline_does_not_submit_short_first_line）；外部调用 3 个（new, new, channel）。

fn elapsed(ms: usize) -> std::time::Duration

作用：这个小工具把毫秒数字变成程序能用的时间长度。测试用它来精确模拟按键之间隔了多久。

数据流：它接收一个毫秒数，比如 20 或 200，然后把这个数字转换成 Duration，也就是 Rust 里表示“一段时间”的对象。它不改动别的东西，只返回这个时间长度。

调用关系：它被三个测试函数反复使用。测试先拿当前时间作为起点，再用 elapsed 加上几毫秒，得到每次按键发生的模拟时间。CustomPromptView 正是根据这些时间差来判断这是快速粘贴，还是用户真正停顿后按下提交。

调用图：被 3 处调用（delayed_enter_after_typing_submits, paste_burst_newline_after_tab_does_not_submit, paste_burst_newline_does_not_submit_short_first_line）；外部调用 1 个（from_millis）。

fn thread_settings_for_test(
    model: &str,
    thread_id: ThreadId,
) -> codex_app_server_protocol::ThreadSettingsUpdatedNotification

作用：这个辅助函数用来快速造一份“线程设置已更新”的假服务器通知。测试不想每次手写一大坨设置，所以把常用设置集中在这里。

数据流：进去的是模型名和线程编号 → 它把这些填进一份线程设置里，同时放入工作目录、审批方式、沙箱权限、服务档位、推理强度、协作模式和性格等固定测试值 → 出来的是一条可以直接喂给聊天窗口的设置更新通知，不改动外部状态。

调用关系：它被两个线程设置相关测试调用。那些测试先用它生成服务器通知，再交给聊天窗口处理，用来确认界面只更新目标线程的设置。

调用图：调用 1 个内部函数（read_only）；被 2 处调用（thread_settings_updated_preserves_default_settings_for_plan_mode, thread_settings_updated_updates_visible_state_without_transcript）；外部调用 1 个（to_string）。

fn configured_thread_session(thread_id: ThreadId) -> crate::session_state::ThreadSessionState

作用：这个辅助函数用来造一个已经配置好的假线程会话。它相当于给测试里的聊天窗口准备一份初始档案。

数据流：进去的是线程编号 → 它填好默认模型、服务商、权限配置、工作目录、历史记录等会话字段 → 出来的是一份线程会话状态，供测试先把聊天窗口放到某个已打开线程中。

调用关系：它被两个线程设置测试调用。测试先用它建立当前线程，再用 thread_settings_for_test 模拟服务器改设置，最后检查聊天窗口有没有正确覆盖或保留对应状态。

调用图：调用 1 个内部函数（read_only）；被 2 处调用（thread_settings_updated_preserves_default_settings_for_plan_mode, thread_settings_updated_updates_visible_state_without_transcript）；外部调用 2 个（new, vec!）。

async fn invalid_url_elicitation_is_declined()

作用：这个测试确认：如果服务器请求用户打开一个 URL 进行确认，但这个请求不属于当前可见线程，聊天界面会直接拒绝。这样可以避免用户在一个聊天里误处理另一个聊天的敏感请求。

数据流：进去的是一个假的聊天窗口、当前可见线程编号，以及另一个发起请求的线程编号 → 测试把 URL 请求交给聊天窗口 → 出来的是一条提交给对应线程的“拒绝请求”操作，内容为空，并确认目标线程是请求所属线程。

调用关系：这个测试直接调用聊天窗口的 elicitation 请求处理函数，然后从事件通道里取结果。它不依赖本文件的辅助函数，只验证这条安全边界是否成立。

调用图：调用 1 个内部函数（new）；外部调用 2 个（Integer, assert_matches!）。

async fn thread_settings_updated_updates_visible_state_without_transcript()

作用：这个测试确认：当前正在看的线程收到设置更新时，聊天窗口会更新模型、推理强度、服务档位、审批和性格等状态，但不会把历史聊天内容重新渲染一遍。

数据流：进去的是一个假聊天窗口和一个线程编号 → 测试先建立该线程会话，再发送一条线程设置更新通知 → 出来的是聊天窗口当前设置变成新值，历史插入队列保持为空；随后给另一个线程发设置更新，当前界面不变。

调用关系：它先调用 configured_thread_session 准备初始线程，再调用 thread_settings_for_test 生成更新通知，最后通过一组断言检查聊天窗口处理 ServerNotification::ThreadSettingsUpdated 的效果。

调用图：调用 3 个内部函数（new, configured_thread_session, thread_settings_for_test）；外部调用 3 个（ThreadSettingsUpdated, assert!, assert_eq!）。

async fn thread_settings_updated_preserves_default_settings_for_plan_mode()

作用：这个测试确认：进入“计划模式”时可以显示计划模式要求的模型和推理强度，但原来的默认模式设置不会被覆盖丢失。

数据流：进去的是一个带默认模型和低推理强度的假线程会话 → 测试发送计划模式的线程设置更新 → 聊天窗口暂时显示计划模型和高推理强度；当测试切回默认模式时，又回到原来的默认模型和低推理强度。

调用关系：它用 configured_thread_session 建初始会话，用 thread_settings_for_test 制造计划模式更新，再调用协作模式的 default_mask 切回默认模式，验证两套设置互不污染。

调用图：调用 4 个内部函数（new, configured_thread_session, thread_settings_for_test, default_mask）；外部调用 2 个（ThreadSettingsUpdated, assert_eq!）。

async fn collab_spawn_end_shows_requested_model_and_effort()

作用：这个测试确认：协作代理被创建完成时，历史记录里会显示创建时请求的模型和推理强度。这样用户能知道这个代理是用什么配置启动的。

数据流：进去的是假聊天窗口、发起线程编号和被创建代理线程编号 → 测试先登记代理名字和角色，再模拟创建代理的开始和完成通知 → 出来的是历史渲染文本，里面包含代理名、角色、模型 gpt-5 和 high 推理强度。

调用关系：它直接向聊天窗口发送 ItemStarted 和 ItemCompleted 通知。测试最后读取历史插入事件，确认协作代理工具调用的展示文字没有丢掉请求参数。

调用图：调用 1 个内部函数（new）；外部调用 7 个（from, new, ItemCompleted, ItemStarted, new, assert!, vec!）。

async fn live_app_server_user_message_item_completed_does_not_duplicate_rendered_prompt()

作用：这个测试确认：用户按回车发送的文字已经显示过后，服务器稍后回传同一条用户消息完成通知时，不会再显示第二遍。

数据流：进去的是一个假聊天窗口和输入框文字 → 测试模拟用户按回车，先确认界面插入了一条用户消息，并且发送操作已提交 → 再模拟服务器回传同样的用户消息 → 出来的是没有新的历史插入事件。

调用关系：它先走真实的键盘输入路径，再处理 ItemCompleted 用户消息通知。这样覆盖的是实际使用中“本地乐观显示”和“服务器确认”之间的去重关系。

调用图：调用 1 个内部函数（new）；外部调用 7 个（new, ItemCompleted, new, assert!, assert_eq!, panic!, vec!）。

async fn live_app_server_turn_completed_clears_working_status_after_answer_item()

作用：这个测试确认：模型回答出现后，界面仍然保持“工作中”，直到整个回合完成通知到达才清掉状态栏。这样不会过早让用户以为任务已经完全结束。

数据流：进去的是一个假聊天窗口 → 测试先发送回合开始通知，状态栏显示 Working；再发送最终回答条目，历史里出现回答但状态仍是运行中；最后发送回合完成通知 → 出来的是运行状态关闭，状态栏消失。

调用关系：它按服务器真实顺序发送 TurnStarted、ItemCompleted 和 TurnCompleted。测试验证聊天窗口把“回答文本完成”和“整个回合结束”区分开。

调用图：外部调用 6 个（ItemCompleted, TurnCompleted, TurnStarted, new, assert!, assert_eq!）。

async fn live_app_server_turn_started_sets_feedback_turn_id()

作用：这个测试确认：当用户在某个回合运行中提交反馈时，反馈会带上这个回合的编号。这样后台才能知道用户是在反馈哪一次回答。

数据流：进去的是假聊天窗口和一个回合开始通知 → 聊天窗口记录当前回合编号 → 测试打开反馈输入并按回车提交 → 出来的是 SubmitFeedback 事件，其中 turn_id 是刚开始的 turn-1。

调用关系：它先处理 TurnStarted，再走反馈提交流程。测试从事件通道里检查反馈事件，确认回合编号被聊天窗口正确串起来。

调用图：外部调用 4 个（new, TurnStarted, new, assert_matches!）。

async fn live_app_server_warning_notification_renders_message()

作用：这个测试确认：普通警告通知会被显示到聊天历史里，而且长警告里的主要信息不会丢。

数据流：进去的是一个包含技能上下文预算警告的服务器通知 → 聊天窗口把它转换成一条历史单元 → 出来的是一段可见文字，包含预算超限和后续处理说明。

调用关系：它直接发送 Warning 通知，然后读取历史插入结果。这个测试保护的是服务器警告到用户可见提示的展示链路。

调用图：外部调用 3 个（Warning, assert!, assert_eq!）。

async fn live_app_server_guardian_warning_notification_renders_message()

作用：这个测试确认：自动审批审查一类的安全警告会显示给用户。否则用户可能不知道为什么某个操作被挡住了。

数据流：进去的是一条 GuardianWarning 通知，里面写着自动审批审查拒绝了操作 → 聊天窗口渲染一条警告历史 → 出来的是包含原始警告文字的可见内容。

调用关系：它直接测试 GuardianWarning 通知的展示路径，确保安全审查模块发来的信息不会被聊天界面吞掉。

调用图：外部调用 3 个（GuardianWarning, assert!, assert_eq!）。

async fn live_app_server_config_warning_prefixes_summary()

作用：这个测试确认：配置文件有问题时，聊天界面会把配置警告的摘要显示出来。这样用户能知道系统正在用默认值兜底。

数据流：进去的是一条 ConfigWarning 通知，摘要为配置无效、使用默认值 → 聊天窗口把它插入历史 → 出来的是包含这句摘要的警告文本。

调用关系：它直接发送 ConfigWarning 并检查历史输出。这个测试覆盖配置加载问题传到界面的提醒路径。

调用图：外部调用 3 个（ConfigWarning, assert!, assert_eq!）。

async fn live_app_server_file_change_item_started_preserves_changes()

作用：这个测试确认：文件变更刚开始时，界面就能显示具体改了哪个文件。这样用户不会只看到一个空泛的“正在改文件”。

数据流：进去的是一个 FileChange 开始通知，里面包含新增 foo.txt 和 diff 内容 → 聊天窗口生成补丁历史展示 → 出来的是历史文本中至少能看到 foo.txt 被新增或编辑。

调用关系：它发送 ItemStarted 类型的文件变更通知。测试关注的是进行中的补丁也要保留变更明细，而不是只在完成时才知道文件名。

调用图：外部调用 3 个（ItemStarted, assert!, vec!）。

async fn live_app_server_command_execution_strips_shell_wrapper()

作用：这个测试确认：命令通过 shell 包装执行时，界面展示的是用户真正关心的脚本，而不是冗长的 /bin/zsh -lc 外壳命令。

数据流：进去的是一个被 shell 包起来的 python 命令，以及命令完成后的输出、退出码和耗时 → 聊天窗口处理开始和完成通知 → 出来的是一条命令历史单元，快照检查它的显示格式符合预期。

调用关系：它用 shlex 生成可还原的 shell 包装命令，再发送 ItemStarted 和 ItemCompleted。最后用快照测试固定界面文本，防止以后显示格式被无意改坏。

调用图：外部调用 6 个（ItemCompleted, ItemStarted, assert_chatwidget_snapshot!, assert_eq!, try_join, vec!）。

async fn live_app_server_collab_wait_items_render_history()

作用：这个测试确认：等待多个协作代理的工具调用，会把各个代理的名字、角色和状态清楚显示在历史里。

数据流：进去的是两个接收方代理线程编号及其元数据 → 测试模拟等待开始，再模拟等待完成，其中一个代理完成并带消息，另一个仍在运行 → 出来的是合并后的历史文本，并用快照确认展示内容。

调用关系：它先设置协作代理元数据，再发送 Wait 工具的 ItemStarted 和 ItemCompleted 通知。这个测试保证多代理协作状态能被用户看懂。

调用图：调用 1 个内部函数（from_string）；外部调用 6 个（from, new, ItemCompleted, ItemStarted, assert_chatwidget_snapshot!, vec!）。

async fn live_app_server_collab_spawn_completed_renders_requested_model_and_effort()

作用：这个测试确认：协作代理创建完成后的历史记录，会保留并显示请求的模型和推理强度。

数据流：进去的是发起线程编号、被创建代理编号、请求模型 gpt-5 和高推理强度 → 聊天窗口处理创建开始和完成通知 → 出来的是一段历史文本，快照验证它包含正确的创建信息。

调用关系：它和另一个 spawn 测试类似，但这里完成通知里也带着模型和推理强度。它通过快照固定 SpawnAgent 完成态的渲染效果。

调用图：调用 1 个内部函数（from_string）；外部调用 7 个（from, new, ItemCompleted, ItemStarted, new, assert_chatwidget_snapshot!, vec!）。

async fn live_app_server_failed_turn_does_not_duplicate_error_history()

作用：这个测试确认：失败回合如果已经收到过错误通知，后面的回合完成通知里再带同一个错误时，不会在历史里重复显示。

数据流：进去的是一个回合开始通知、一个 permission denied 错误通知、以及一个失败的回合完成通知 → 第一次错误会插入历史 → 完成通知到达后不再插入新错误，并且工作状态被清掉。

调用关系：它按 TurnStarted、Error、TurnCompleted 的顺序模拟失败流程。测试保护错误展示的去重逻辑，避免用户看到两条一模一样的失败消息。

调用图：外部调用 6 个（Error, TurnCompleted, TurnStarted, new, assert!, assert_eq!）。

async fn live_app_server_failed_turn_consolidates_streamed_answer()

作用：这个测试确认：如果模型答案正在流式输出时突然失败，已经输出的半截内容会先被收拢成历史，而不是直接丢掉。

数据流：进去的是一个开始的回合、一段流式追加的回答内容，以及一个断流错误 → 聊天窗口先把流式内容提交整理 → 出来的是 ConsolidateAgentMessage 事件，其中包含那段已经流出的 patch 文本。

调用关系：它使用测试辅助流程触发回合开始、消息增量、提交节拍和错误。测试重点是失败清理流控制器之前，必须先保存用户已经看到的部分回答。

调用图：外部调用 1 个（assert!）。

async fn live_app_server_stream_recovery_restores_previous_status_header()

作用：这个测试确认：网络重连提示出现后，如果又收到了模型输出，状态栏会从“重连中”恢复成原来的“工作中”。

数据流：进去的是回合开始通知、一个可重试错误通知，以及后续的消息增量 → 聊天窗口先进入重试提示状态，再在新内容到来时恢复状态栏 → 出来的是状态标题为 Working、详情为空，并且临时重试标题被清除。

调用关系：它按 TurnStarted、Error、AgentMessageDelta 的顺序模拟断线恢复。测试验证聊天窗口没有把临时错误状态永久留在底部状态栏。

调用图：外部调用 6 个（AgentMessageDelta, Error, TurnStarted, new, assert!, assert_eq!）。

async fn live_app_server_server_overloaded_error_renders_warning()

作用：这个测试确认：服务器过载错误会以简短警告显示，并且会结束当前工作状态。

数据流：进去的是回合开始通知和一个 ServerOverloaded 类型错误 → 聊天窗口把错误渲染成“ server overloaded” → 出来的是一条警告历史，任务运行标志关闭。

调用关系：它模拟正常回合中收到不可重试错误。测试覆盖特定错误类型到用户提示的映射，以及错误后状态清理。

调用图：外部调用 5 个（Error, TurnStarted, new, assert!, assert_eq!）。

async fn live_app_server_cyber_policy_error_renders_dedicated_notice()

作用：这个测试确认：网络安全策略拦截类错误不会简单显示服务器的兜底文字，而是显示专门写给用户看的安全说明。

数据流：进去的是回合开始通知和一个 CyberPolicy 类型错误，原始消息是 server fallback message → 聊天窗口识别错误类型后替换成专用说明 → 出来的是历史文本包含网络安全风险和 Trusted Access for Cyber，但不包含原始兜底消息，任务状态也结束。

调用关系：它发送 Error 通知并检查特定文案。这个测试保护安全策略错误的特殊展示逻辑，避免用户看到不清楚或不合规的泛泛报错。

调用图：外部调用 5 个（Error, TurnStarted, new, assert!, assert_eq!）。

async fn live_app_server_model_verification_renders_warning()

作用：这个测试确认：模型验证提示会显示额外安全检查的信息和相关链接。用户因此能知道为什么聊天进入了更谨慎的模式。

数据流：进去的是一条 ModelVerification 通知，验证项为 TrustedAccessForCyber → 聊天窗口插入一条警告历史 → 出来的是文本包含多次网络安全风险标记、额外安全检查、Trusted Access for Cyber 和说明链接。

调用关系：它直接测试 ModelVerification 通知的渲染路径。这个通知不是错误，但仍需要作为重要安全提示进入聊天历史。

调用图：外部调用 4 个（ModelVerification, assert!, assert_eq!, vec!）。

async fn live_app_server_invalid_thread_name_update_is_ignored()

作用：这个测试确认：线程名称更新里的线程编号如果不是合法编号，聊天窗口会忽略它，不会把当前聊天标题改坏。

数据流：进去的是当前线程编号、原始线程名，以及一条线程编号为 not-a-thread-id 的名称更新通知 → 聊天窗口尝试处理但无法识别编号 → 出来的是当前线程编号和线程名都保持原样。

调用关系：它直接发送 ThreadNameUpdated 通知。测试保护的是输入校验：服务器或网络层给到坏数据时，界面不要误更新。

调用图：调用 1 个内部函数（new）；外部调用 2 个（ThreadNameUpdated, assert_eq!）。

async fn live_app_server_thread_name_update_shows_resume_hint()

作用：这个测试确认：当前线程名称被成功更新后，聊天历史会显示一条恢复会话的提示。这样用户以后能知道如何继续这个命名线程。

数据流：进去的是一个合法线程编号和新名称 review-fix → 聊天窗口确认通知属于当前线程，更新 thread_name → 出来的是线程名变成 review-fix，并插入一条提示文本，快照固定它的样子。

调用关系：它用 from_string 构造合法线程编号，再发送 ThreadNameUpdated。测试连接了线程标题状态更新和用户可见恢复提示。

调用图：调用 1 个内部函数（from_string）；外部调用 3 个（ThreadNameUpdated, assert_chatwidget_snapshot!, assert_eq!）。

async fn live_app_server_thread_closed_requests_immediate_exit()

作用：这个测试确认：服务器通知线程已关闭时，聊天界面会立刻请求退出。这样用户不会继续停在一个已经被服务端关掉的会话里。

数据流：进去的是一条 ThreadClosed 通知 → 聊天窗口处理后向应用事件通道发送退出事件 → 出来的是 ExitMode::Immediate，表示马上退出。

调用关系：它直接发送 ThreadClosed 通知，然后检查事件通道。这个测试覆盖服务端关闭会话到前端退出动作的最后一环。

调用图：外部调用 2 个（ThreadClosed, assert_matches!）。

async fn exec_approval_emits_proposed_command_and_decision_history()

作用：测试普通命令审批的完整用户体验：请求出现时先用弹窗展示，不急着写进聊天历史；用户批准后，历史里才出现一条清楚的决定记录。

数据流：测试先创建一个假的聊天界面和事件接收器，再构造一个要执行 echo hello world 的审批请求。请求交给聊天界面后，它检查历史消息还是空的，然后把界面渲染到一个虚拟屏幕里做快照对比。最后模拟用户按下 y 表示同意，再从事件流里取出新增的历史记录，确认这条记录长得符合预期。

调用关系：这是测试运行器启动的异步测试。它把请求交给 handle_exec_approval_request，再通过 chat.render 看弹窗，通过 chat.handle_key_event 模拟用户决定，最后用 drain_insert_history 和快照断言检查聊天界面的结果。

调用图：调用 1 个内部函数（current_dir）；外部调用 7 个（Char, new, new, assert!, assert_snapshot!, empty, vec!）。

fn app_server_exec_approval_request_splits_shell_wrapped_command()

作用：测试从应用服务器传来的“被 shell 包了一层”的命令，能不能被正确拆回真正的参数列表。这样界面和后续执行逻辑不会把整串命令误当成一个参数。

数据流：测试先准备一段脚本 python3 -c ...，再用 shell 转义工具把 /bin/zsh -lc 脚本 拼成一条字符串。然后把这条字符串放进应用服务器格式的审批参数里，交给转换函数。出来的结果应该是三个清楚的命令片段：shell 路径、-lc、脚本文本。

调用关系：它主要盯住 exec_approval_request_from_params 这个转换入口。测试本身由 Rust 测试框架调用，内部用 shlex::try_join 造出接近真实服务端会发送的命令字符串，再用断言确认转换结果。

调用图：外部调用 2 个（assert_eq!, try_join）。

fn app_server_exec_approval_request_preserves_permissions_context()

作用：测试命令审批请求里的网络和额外文件权限不会在格式转换时丢失。没有这个保障，用户批准时看到或系统收到的权限范围可能就不完整。

数据流：测试先造出两个绝对路径，一个代表只读目录，一个代表可写目录，并把它们转成应用服务器使用的路径字符串。接着构造一个带网络主机、网络协议、读写权限的审批参数。转换完成后，它检查结果里的网络访问上下文和额外权限，必须和输入保持一致。

调用关系：它围绕 exec_approval_request_from_params 做检查。路径转换会用到绝对路径构造和 API 路径包装；最后由断言把转换前后信息一项项对齐，确保权限数据没有被中间层吞掉。

调用图：调用 2 个内部函数（try_from, from_abs_path）；外部调用 3 个（from, assert_eq!, vec!）。

async fn network_exec_approval_history_describes_session_host_allowance()

作用：测试用户选择“本次会话都允许访问某个网络主机”时，聊天历史里的说明是否准确。它关心的是用户以后回看时能不能明白自己放行了什么。

数据流：测试创建聊天界面，然后构造一个访问 example.com 的 HTTPS 网络审批请求，并声明可选决定里有“本会话接受”和“取消”。请求进入界面后，测试模拟用户按 a 选择本会话允许。最后从历史记录里取出决定说明，用快照确认文案写的是对这个主机的会话级放行。

调用关系：测试运行器调用它后，它通过 exec_approval_request_from_params 生成内部请求，再交给 handle_exec_approval_request。用户按键由 chat.handle_key_event 模拟，历史文案通过 drain_insert_history 取出并交给快照测试。

调用图：外部调用 4 个（Char, new, assert_snapshot!, vec!）。

async fn network_exec_approval_history_describes_one_time_host_allowance()

作用：测试用户只允许某个网络主机访问一次时，历史记录会不会写成“一次性允许”，而不是误写成长期允许。

数据流：测试构造一个 HTTP 访问 example.com 的网络审批请求，这次没有具体命令文本，但带有网络上下文和可选决定。它把请求送进聊天界面，模拟用户按 y 接受一次。随后取出新增历史记录，用快照确认文字描述的是一次性主机放行。

调用关系：它和其他网络审批测试走同一条链路：服务端参数先转成内部请求，再由聊天界面展示和处理按键。不同点是它模拟的是 Accept，用来覆盖一次性批准这条分支。

调用图：外部调用 4 个（Char, new, assert_snapshot!, vec!）。

async fn network_exec_approval_history_describes_canceled_host_request()

作用：测试用户拒绝网络访问请求时，聊天历史能不能明确写出这个主机请求被取消了。这样用户不会误以为访问已经被允许。

数据流：测试准备一个 Socks5 TCP 访问 example.com 的审批请求，并提供“接受”或“取消”两个选择。请求进入聊天界面后，测试模拟用户按 n 拒绝。最后取出历史里的决定消息，用快照确认它表达的是取消网络主机访问。

调用关系：它由测试框架运行，使用同样的请求转换和聊天界面处理流程。它专门覆盖拒绝分支，和前两个网络审批测试一起保证接受一次、接受整场会话、拒绝三种用户选择都有正确历史文案。

调用图：外部调用 4 个（Char, new, assert_snapshot!, vec!）。

fn app_server_request_permissions_preserves_file_system_permissions()

作用：测试单独的权限申请请求在转换时能保留文件系统读写范围、网络开关、当前工作目录和远程环境标识。简单说，就是外部请求什么权限，内部就应该准确记住什么权限。

数据流：测试先准备只读路径、可写路径和当前工作目录，并把读写路径转成应用服务器格式。然后构造一个权限申请参数，里面包含网络启用、文件读写权限、环境 ID 和申请理由。转换函数返回内部请求后，测试检查权限结构、当前目录和环境 ID 都符合预期。

调用关系：它主要检查 request_permissions_from_params。这个函数把应用服务器协议里的权限描述变成本地聊天界面能理解的权限描述；测试用断言确认转换没有改错路径，也没有丢掉环境信息。

调用图：调用 2 个内部函数（try_from, from_abs_path）；外部调用 3 个（from, assert_eq!, vec!）。

async fn exec_approval_uses_approval_id_when_present()

作用：测试审批请求同时带有 call_id 和 approval_id 时，真正提交决定要用 approval_id。这很重要，因为一个大的调用里可能有子命令，审批编号才是后端要认的编号。

数据流：测试创建聊天界面，构造一个命令审批请求，其中 call_id 是父调用，approval_id 是子命令审批号。它把请求交给界面后模拟用户按 y 同意，然后不断读取发出的应用事件。找到提交审批决定的事件后，确认里面的 ID 是 approval-subcommand，决定是接受。

调用关系：它从用户按键一路追到发给后端的操作事件。handle_exec_approval_request 负责把请求挂到界面上，chat.handle_key_event 触发提交，测试再从接收器里找 Op::ExecApproval，确保界面没有错误地使用 call_id。

调用图：调用 1 个内部函数（current_dir）；外部调用 6 个（Char, new, assert!, assert_eq!, assert_matches!, vec!）。

async fn exec_approval_decision_truncates_multiline_and_long_commands()

作用：测试多行命令和特别长的命令在审批历史里会被安全地缩短展示。这样历史记录不会被一大段命令刷屏，但用户仍能看出大概发生了什么。

数据流：测试先送入一个包含换行的命令审批请求，确认请求阶段仍然只用弹窗展示，并检查弹窗里能看到第一行命令。然后模拟用户按 n 拒绝，取出历史记录做快照。接着它再构造一条很长的命令，同样确认请求阶段不写历史，拒绝后检查历史里的命令摘要被截断得符合预期。

调用关系：它覆盖审批显示里比较容易出问题的边界情况：多行和超长文本。流程上仍然是请求进入 handle_exec_approval_request，界面用 render 画出来，按键由 handle_key_event 处理，最后用历史抽取和快照断言确认展示效果。

调用图：调用 1 个内部函数（current_dir）；外部调用 9 个（Char, new, new, new, assert!, assert_snapshot!, format!, empty, vec!）。

async fn submission_preserves_text_elements_and_local_images()

作用：测试提交一条带本地图片占位符的消息时，文字里的特殊片段和本地图片路径不会丢。这样可以保证用户看到的“[Image #1] submit”和真正送给模型的内容是一致的。

数据流：先创建一个聊天界面和一个线程状态，再把输入框设成带图片占位符的文字，并附上一张本地图片路径。按下 Enter 后，它检查发出的用户请求里先有本地图片，再有文字；同时检查聊天历史里也保存了同样的文字、文字标记和图片路径。

调用关系：这个测试模拟最基础的“文字加本地图片提交”流程。它通过 ChatWidget 的按键处理触发提交，再从操作通道和界面事件通道里取结果，确认提交层和显示层都没有改坏数据。

调用图：调用 2 个内部函数（read_only, new）；外部调用 9 个（new, new, default, new, assert!, assert_eq!, format!, panic!, vec!）。

async fn submission_includes_configured_active_permission_profile()

作用：测试用户提交消息时，会带上当前选中的权限配置。权限配置就是告诉后台这次对话能不能联网、能读写哪些文件的规则。

数据流：它先构造一个带自定义权限名称的线程状态，然后输入一段普通文字并按 Enter。最后从发出的用户请求里取出 active_permission_profile，确认它就是之前配置的那个。

调用关系：这个测试位于“会话配置进入提交请求”的链路上。它证明 ChatWidget 在 handle_thread_session 收到配置后，submit 时会把关键权限信息一起交给后台。

调用图：调用 2 个内部函数（new, new）；外部调用 7 个（new, new, default, new, assert_eq!, panic!, vec!）。

async fn submission_omits_active_permission_profile_for_legacy_snapshot()

作用：测试旧格式会话里如果没有“当前激活权限配置”，提交时就不要硬塞一个。这样能兼容老数据，不会把不存在的配置误传给后台。

数据流：它准备一个 active_permission_profile 为空的线程状态，提交一条消息。然后检查发出的用户请求里这个字段仍然是 None，也就是没有值。

调用关系：这个测试和权限配置测试成对出现。前一个确认有配置时要带上，这一个确认没有配置时要保持空，避免新旧会话状态混用出错。

调用图：调用 1 个内部函数（new）；外部调用 6 个（new, new, default, new, assert_eq!, panic!）。

async fn submission_with_remote_and_local_images_keeps_local_placeholder_numbering()

作用：测试一条消息同时有远程图片和本地图片时，本地图片在文字里的编号不会被远程图片打乱。用户看到的“[Image #2]”必须继续对应那张本地图片。

数据流：它先给聊天界面放入一个远程图片网址，再在输入框里放入“[Image #2] submit mixed”和一张本地图片。按 Enter 后，它确认提交内容顺序是远程图片、本地图片、文字，并且历史记录保存了同样的占位符、本地图片和远程图片网址。

调用关系：这个测试覆盖混合图片提交场景。它连接了远程图片列表、输入框本地图片列表、用户请求组装和历史显示四个环节，确保编号映射没有被重新洗牌。

调用图：调用 2 个内部函数（read_only, new）；外部调用 8 个（new, new, default, new, assert_eq!, format!, panic!, vec!）。

async fn enter_with_only_remote_images_submits_user_turn()

作用：测试输入框没有文字、只有远程图片时，按 Enter 也应该提交。因为用户可能只想发一张网络图片给模型看。

数据流：它把远程图片网址放进聊天界面，确认输入框文字为空，然后按 Enter。结果应该发出只包含远程图片的用户请求，并且提交后远程图片列表被清空，历史记录里也记录这张远程图片。

调用关系：这个测试专门保护“纯图片消息”入口。它验证提交逻辑不是只看文字是否为空，而是也会看是否存在待发送的远程图片。

调用图：调用 2 个内部函数（read_only, new）；外部调用 8 个（new, new, default, new, assert!, assert_eq!, panic!, vec!）。

async fn shift_enter_with_only_remote_images_does_not_submit_user_turn()

作用：测试只有远程图片时，Shift+Enter 不会提交。Shift+Enter 通常表示换行或特殊输入，不应该等同于发送。

数据流：它放入一个远程图片网址，然后模拟 Shift+Enter。结果是不发出用户请求，远程图片仍然留在待提交列表里。

调用关系：这个测试约束按键行为。它和普通 Enter 的测试形成对照，确认提交只发生在真正的发送按键上。

调用图：调用 2 个内部函数（read_only, new）；外部调用 6 个（new, new, default, new, assert_eq!, vec!）。

async fn enter_with_only_remote_images_does_not_submit_when_modal_is_active()

作用：测试弹窗打开时，即使按 Enter 且有远程图片，也不会提交消息。弹窗就像当前盖在界面上的对话框，按键应先由弹窗处理。

数据流：它放入远程图片，打开审核弹窗，再按 Enter。之后检查远程图片还在，且没有发出提交请求。

调用关系：这个测试保护界面焦点规则。它说明 ChatWidget 在提交前会尊重当前是否有弹窗，避免用户在弹窗里按确认时误发聊天消息。

调用图：调用 2 个内部函数（read_only, new）；外部调用 6 个（new, new, default, new, assert_eq!, vec!）。

async fn enter_with_only_remote_images_does_not_submit_when_input_disabled()

作用：测试输入框被禁用时，只有远程图片也不能提交。输入禁用通常表示系统暂时不允许用户发送，例如正在等待某个状态。

数据流：它放入远程图片，然后把输入框设为不可输入，并按 Enter。结果远程图片保留，没有任何提交操作发出去。

调用关系：这个测试保护输入禁用状态。它确认提交逻辑会先问输入框“现在能不能发”，而不是只根据内容直接发送。

调用图：调用 2 个内部函数（read_only, new）；外部调用 6 个（new, new, default, new, assert_eq!, vec!）。

async fn submission_prefers_selected_duplicate_skill_path()

作用：测试当有两个同名技能时，提交会使用用户实际选中的那个路径。技能可以理解成可被聊天调用的外部能力说明文件。

数据流：它准备两个都叫 figma 的技能，一个来自仓库，一个来自用户目录。输入框里的 $figma 绑定到用户目录路径后提交，最后检查发出的 UserInput::Skill 只包含用户选中的路径。

调用关系：这个测试覆盖“提及绑定”比“名字匹配”更可靠的规则。它保证 ChatWidget 不会因为技能重名而选错技能文件。

调用图：调用 2 个内部函数（read_only, new）；外部调用 7 个（new, new, default, new, assert_eq!, panic!, vec!）。

async fn blocked_image_restore_preserves_mention_bindings()

作用：测试如果模型不支持图片，系统把被拦截的消息恢复回输入框时，不会丢掉里面的提及绑定。也就是图片发不了，但用户写的 $file 仍然保持可识别。

数据流：它构造一条带图片占位符和 $file 提及的消息，然后调用恢复函数。恢复后检查输入框文字、文字标记、本地图片路径和提及绑定都回来了，并且历史里出现“不支持图片输入”的警告。

调用关系：这个测试位于图片提交失败后的补救流程。它确认 restore_blocked_image_submission 不只是把文字塞回去，还会恢复用户选择过的提及信息。

调用图：外部调用 5 个（new, assert!, assert_eq!, format!, vec!）。

async fn blocked_image_restore_with_remote_images_keeps_local_placeholder_mapping()

作用：测试图片提交被拦截后恢复输入框时，远程图片存在也不会打乱本地图片占位符和路径的对应关系。

数据流：它准备两个本地图片占位符、两个本地图片路径和一个远程图片网址，然后执行被拦截消息恢复。恢复后检查输入框文字、文字标记、本地图片列表和远程图片列表都保持原样。

调用关系：这个测试关注失败恢复时的图片编号稳定性。它补充了正常提交场景，确保出错回退也不会把用户图片配错。

调用图：外部调用 4 个（new, assert_eq!, format!, vec!）。

async fn queued_restore_with_remote_images_keeps_local_placeholder_mapping()

作用：测试把排队中的用户消息恢复到输入框时，本地图片占位符和远程图片都能原样回来。排队消息就是任务正在跑时，用户提前写好的下一条消息。

数据流：它构造一条包含本地图片、远程图片和文字标记的 UserMessage，然后调用恢复到输入框的函数。结果输入框文字、光标位置、文字标记、本地图片和远程图片都与原消息一致。

调用关系：这个测试覆盖队列消息编辑或中断恢复流程。它确认 restore_user_message_to_composer 是完整恢复，而不是只恢复纯文本。

调用图：外部调用 4 个（new, assert_eq!, format!, vec!）。

async fn interrupted_turn_restore_keeps_active_mode_for_resubmission()

作用：测试一次任务被打断后，把排队消息恢复到输入框再提交时，仍然保留之前选中的协作模式。协作模式可以理解成模型工作的不同姿态，比如“计划模式”。

数据流：它启用协作模式，选择计划模式，模拟任务运行并放入一条排队消息。打断后消息回到输入框，队列清空；再次按 Enter 时，发出的用户请求仍带着同一个协作模式。

调用关系：这个测试串起任务开始、消息排队、任务中断、恢复输入框、重新提交的完整流程。它防止中断恢复时把用户当前工作模式弄丢。

调用图：调用 2 个内部函数（new, plan_mask）；外部调用 5 个（from, new, assert!, assert_eq!, panic!）。

async fn remap_placeholders_uses_attachment_labels()

作用：测试重新编号图片占位符时，会优先使用附件自己记录的原始标签来判断对应关系。这样即使图片在文字里的出现顺序和附件列表顺序不同，也能配对正确。

数据流：它准备文字“[Image #2] before [Image #1]”，附件列表里记录 #1 和 #2 各自路径，并设置下一个编号从 3 开始。重映射后，附件得到新标签 #3、#4，文字也变成对应的新占位符。

调用关系：这个测试直接验证 remap_placeholders_for_message 的核心规则。它服务于多条消息合并或恢复时的图片编号刷新流程。

调用图：外部调用 4 个（new, assert_eq!, format!, vec!）。

async fn remap_placeholders_uses_byte_ranges_when_placeholder_missing()

作用：测试如果文字标记里没有保存占位符文本，系统还能靠字节范围找到旧占位符并重新编号。字节范围就是这段文字在整条字符串里的起止位置。

数据流：它准备同样的两张图片和文字，但 TextElement 里不带 placeholder 值，只带位置范围。重映射后，文字、文字标记和附件标签仍然被正确改成新的编号。

调用关系：这个测试覆盖数据不完整时的兜底路径。它保证 remap_placeholders_for_message 不依赖单一字段，旧数据或简化数据也能处理。

调用图：外部调用 4 个（new, assert_eq!, format!, vec!）。

async fn empty_enter_during_task_does_not_queue()

作用：测试任务运行中按 Enter，但输入框是空的，不会产生一条空的排队消息。否则队列里会出现没有意义的空请求。

数据流：它把底部输入区设置成任务运行状态，然后在空输入框下按 Enter。最后检查 queued_user_messages 仍然为空。

调用关系：这个测试保护任务运行时的排队逻辑。它确保“可以排队”不等于“空内容也排队”。

调用图：外部调用 2 个（new, assert!）。

async fn output_free_interrupted_turn_requests_prompt_restore()

作用：测试如果一次被取消的任务还没有产生可见输出，打断后应该恢复用户原来的提示词。这样用户可以继续编辑刚才那句话，而不是白白丢掉。

数据流：它先记录一个可恢复的用户提示词，模拟任务开始，再提交“如果无输出就恢复提示词”的打断命令。任务中断后，事件通道里应该收到 RestoreCancelledTurn，内容就是原提示词。

调用关系：这个测试覆盖取消编辑的理想恢复路径。它连接 AppCommand 的打断意图、Op::Interrupt 的发送，以及中断事件后的恢复通知。

调用图：调用 1 个内部函数（from）；外部调用 2 个（assert_matches!, interrupt_and_restore_prompt_if_no_output）。

async fn visible_output_prevents_cancelled_turn_prompt_restore()

作用：测试如果模型已经产生了可见回答，取消后就不要再恢复原提示词。因为这时用户已经看到结果，恢复旧输入可能反而造成混乱。

数据流：它记录一个可恢复提示词，模拟任务开始，并注入一段可见输出。随后触发打断和中断处理，最后确认没有 RestoreCancelledTurn 事件出现。

调用关系：这个测试是上一条恢复测试的反面场景。它说明恢复提示词的条件不是“只要取消就恢复”，而是“没有实际输出才恢复”。

调用图：调用 1 个内部函数（from）；外部调用 2 个（assert!, interrupt_and_restore_prompt_if_no_output）。

async fn thinking_status_keeps_cancelled_turn_prompt_restore_eligible()

作用：测试只有“正在思考”这类状态文字时，仍然允许取消后恢复提示词。因为思考状态不算真正给用户的回答。

数据流：它记录提示词，模拟任务开始，再注入 reasoning delta，也就是模型内部推理/思考状态。打断并中断后，检查恢复事件仍然发出，并带回原提示词。

调用关系：这个测试细分“输出”的含义。它保证 ChatWidget 不会把思考提示误当成可见回答，从而错误阻止恢复。

调用图：调用 1 个内部函数（from）；外部调用 2 个（assert_matches!, interrupt_and_restore_prompt_if_no_output）。

async fn patch_activity_prevents_cancelled_turn_prompt_restore()

作用：测试如果任务已经开始应用补丁，取消后不恢复提示词。补丁活动说明系统已经对文件做了实质动作，不能简单当作“无输出”。

数据流：它记录可恢复提示词，模拟任务开始，然后触发补丁应用开始事件。打断和中断后，它遍历事件通道，确认没有恢复提示词事件。

调用关系：这个测试保护文件修改场景。它告诉取消恢复逻辑：只要有补丁动作发生，就不能把这轮当作完全没发生过。

调用图：调用 1 个内部函数（from）；外部调用 3 个（new, assert!, interrupt_and_restore_prompt_if_no_output）。

async fn pending_steer_esc_does_not_steal_vim_insert_escape()

作用：测试在 Vim 输入模式下，第一次 Esc 应该先退出插入模式，而不是被“待发送引导消息”的中断逻辑抢走。Vim 模式是一种仿照 Vim 编辑器的键盘操作方式。

数据流：它让任务处于运行中，并放入一个 pending steer（任务运行时用户准备追加的引导消息）。开启 Vim 模式并进入插入状态后按 Esc，第一次只退出插入模式、不发中断；第二次 Esc 才触发中断并标记中断后发送 pending steer。

调用关系：这个测试处理两个按键系统抢同一个 Esc 的冲突。它确认 ChatWidget 会先尊重编辑器模式，再处理任务中断。

调用图：外部调用 5 个（Char, new, assert!, assert_eq!, panic!）。

async fn pending_steer_interrupt_uses_remapped_binding()

作用：测试如果用户把“中断任务”的快捷键改成 F12，那么 pending steer 的中断也必须使用 F12，而不是固定用 Esc。

数据流：它修改运行时快捷键，把 interrupt_turn 设为 F12，并让任务运行、放入 pending steer。按 Esc 不触发中断；按 F12 才发出 Op::Interrupt，并标记中断后提交 pending steer。

调用关系：这个测试覆盖可配置按键。它保证 ChatWidget、底部输入区和 pending steer 中断逻辑使用同一份 keymap（快捷键表）。

调用图：调用 1 个内部函数（defaults）；外部调用 5 个（F, new, assert!, panic!, vec!）。

async fn restore_thread_input_state_syncs_sleep_inhibitor_state()

作用：测试恢复线程输入状态时，防止电脑休眠的状态也会同步更新。sleep inhibitor 可以理解成“任务运行时别让电脑睡着”的开关。

数据流：它启用防休眠功能，然后恢复一个表示任务正在运行的 ThreadInputState。检查任务运行标记、sleep_inhibitor 和底部面板都变成运行中；再恢复 None，三者都变回未运行。

调用关系：这个测试覆盖线程切换或状态恢复流程。它确保界面状态、生命周期状态和系统防休眠状态不会彼此不一致。

调用图：外部调用 2 个（new, assert!）。

async fn alt_up_edits_most_recent_queued_message()

作用：测试按 Alt+Up 可以编辑最近一条排队消息。用户在任务运行时排了多条消息，应该能把最后一条拿回输入框修改。

数据流：它设定 Alt+Up 为编辑排队消息快捷键，让任务运行，并放入两条排队消息。按 Alt+Up 后，输入框变成第二条消息，队列里只剩第一条。

调用关系：这个测试覆盖排队消息的快捷编辑入口。它确认 refresh_pending_input_preview 后，按键处理会从队尾取出最新消息恢复到输入框。

调用图：调用 2 个内部函数（from, alt）；外部调用 3 个（new, assert_eq!, vec!）。

async fn unbound_queued_message_edit_does_not_fall_back_to_alt_up()

作用：测试如果用户没有绑定“编辑排队消息”快捷键，Alt+Up 不会偷偷变成默认行为。这样可以尊重用户明确取消快捷键的设置。

数据流：它清空编辑排队消息的快捷键配置，任务运行并放入一条排队消息。按 Alt+Up 后，输入框仍为空，队列消息仍在。

调用关系：这个测试和 Alt+Up 编辑测试互为补充。它保证快捷键系统不会在解绑后回退到隐藏默认值。

调用图：调用 1 个内部函数（from）；外部调用 4 个（new, new, assert!, assert_eq!）。

async fn shift_left_edits_most_recent_queued_message_in_apple_terminal()

作用：测试在 Apple Terminal 里，Shift+Left 能用来编辑最近一条排队消息。某些终端对 Alt+Up 支持不好，所以需要替代快捷键。

数据流：它把终端信息设为 Apple Terminal，然后调用共享断言函数。共享函数会模拟排队消息并确认 Shift+Left 能把最新消息拿回输入框。

调用关系：这个测试是终端兼容性测试之一。它把具体终端信息交给通用测试逻辑，验证快捷键映射适合 Apple Terminal。

async fn shift_left_edits_most_recent_queued_message_in_warp_terminal()

作用：测试在 Warp 终端里，Shift+Left 能编辑最近排队消息。这样 Warp 用户也能用可靠的快捷键改队列内容。

数据流：它构造 Warp 终端信息，并交给共享测试函数。共享函数负责设置聊天界面、排队消息、按键并检查结果。

调用关系：这个测试属于特殊终端快捷键覆盖。它复用同一套断言，专门确认 Warp 的映射没有遗漏。

async fn shift_left_edits_most_recent_queued_message_in_vscode_terminal()

作用：测试在 VS Code 内置终端里，Shift+Left 能编辑最近排队消息。VS Code 终端的按键表现也需要单独照顾。

数据流：它把终端名称设为 VsCode，然后运行共享的“Shift+Left 编辑队列”检查。预期是最新排队消息进入输入框，队列减少一条。

调用关系：这个测试保证 VS Code 终端走特殊快捷键路径。它和 Apple Terminal、Warp、tmux 的测试一起覆盖常见终端差异。

async fn shift_left_edits_most_recent_queued_message_in_tmux()

作用：测试在 tmux 里，Shift+Left 能编辑最近排队消息。tmux 是终端复用器，可以把一个终端分成多个会话，按键传递常有差异。

数据流：它构造一个带 tmux 标记的终端信息，然后运行共享断言。共享断言检查 Shift+Left 是否能把最新排队消息恢复到输入框。

调用关系：这个测试覆盖终端复用器场景。它确认即使底层终端是 iTerm2，只要外面包了 tmux，也使用更兼容的 Shift+Left。

fn queued_message_edit_binding_mapping_covers_special_terminals_and_tmux()

作用：测试不同终端应该使用哪个“编辑排队消息”快捷键。特殊终端和 tmux 用 Shift+Left，普通 iTerm2 用 Alt+Up。

数据流：它分别构造 Apple Terminal、Warp、VS Code、iTerm2+tmux、普通 iTerm2 的终端信息，调用映射函数并比较返回的快捷键。结果必须符合预期表。

调用关系：这个测试直接检查快捷键选择规则。前面几个实际按键测试验证行为，这里验证映射表本身。

调用图：外部调用 1 个（assert_eq!）。

async fn enqueueing_history_prompt_multiple_times_is_stable()

作用：测试从历史记录召回同一条提示词并多次排队时，每次排进去的文字都稳定一致。这样用户反复复用历史命令不会出现内容变形。

数据流：它先提交一条“repeat me”作为历史记录，然后模拟任务运行。循环三次：按 Up 召回历史，确认输入框是 repeat me，再按 Tab 排队。最后检查队列里有三条，且每条文本都一样。

调用关系：这个测试覆盖历史召回和任务排队的组合。它防止输入框在重复召回、提交、清空之间留下脏状态。

调用图：调用 1 个内部函数（new）；外部调用 3 个（new, new, assert_eq!）。

async fn submit_user_message_ignores_inaccessible_app_mentions_from_bindings()

作用：测试用户消息里绑定了不可访问的应用提及时，提交时不要把它当成有效 Mention 发送。不可访问应用可能只是目录里看得到，但当前账号不能用。

数据流：它启用 Apps 功能，加载一个不可访问但已启用的应用，然后提交带 $arabica-uae 绑定的消息。最后检查发出的内容只有普通文本，没有额外的 UserInput::Mention。

调用关系：这个测试保护应用提及过滤逻辑。它说明 submit_user_message 会结合连接器加载结果判断应用是否真的可用，而不是盲目信任输入框绑定。

调用图：调用 1 个内部函数（new）；外部调用 4 个（new, assert_eq!, panic!, vec!）。

fn user_message_display_from_inputs_matches_flattened_user_message_shape()

作用：测试把多个 UserInput 合成用户历史显示时，结果和“扁平化后的用户消息”形状一致。扁平化就是把分散的文字、图片、技能、提及整理成一条可显示消息。

数据流：它准备一组输入：两段文字、远程图片、本地图片、技能和应用提及。调用 user_message_display_from_inputs 后，检查显示结果只拼接文字、保留文字标记、收集图片，并与 user_message_display_from_parts 的结果相同。

调用关系：这个测试直接验证 ChatWidget 的显示转换函数。它保证后台请求里的多种输入项，最终能变成历史区可理解的用户消息。

调用图：外部调用 4 个（from, assert_eq!, user_message_display_from_inputs, vec!）。

fn user_message_display_from_inputs_hides_prompt_context()

作用：测试用户历史显示会隐藏 IDE 注入的上下文，只显示真正的用户请求。IDE 上下文是编辑器自动附带的信息，比如当前文件名，不一定应显示给用户当作消息正文。

数据流：它构造一段包含“Context from my IDE setup”和“My request for Codex”的原始文本，并带一个 $figma 标记。转换显示后，结果只剩“Ask $figma”，而且文字标记位置也重新对齐。

调用关系：这个测试覆盖显示层的清理规则。它确保 user_message_display_from_inputs 在渲染历史时会剥掉隐藏上下文，同时保留用户真正输入里的提及标记。

调用图：外部调用 3 个（assert_eq!, user_message_display_from_inputs, vec!）。

async fn committed_user_message_with_hidden_prompt_context_renders_local_images()

作用：测试已提交消息如果文字部分全是隐藏的 IDE 上下文，本地图片仍然会显示出来。不能因为正文被隐藏，就把图片也漏掉。

数据流：它构造一个只有 IDE 上下文文本加一张本地图片的提交结果，然后模拟用户消息完成。随后从历史事件里取用户消息单元，确认显示文字为空，但本地图片路径仍存在。

调用关系：这个测试连接“提交完成事件”和“历史显示”。它补充隐藏上下文测试，保证图片附件不依赖可见文字才能渲染。

调用图：外部调用 3 个（from, assert_eq!, vec!）。

async fn interrupt_restores_queued_messages_into_composer()

作用：测试任务被打断时，已经排队的用户消息会回到输入框里，方便用户重新编辑或发送。否则排队内容可能在中断后消失。

数据流：它模拟任务运行，并放入两条排队消息。触发任务中断后，输入框内容变成两条消息按顺序用换行连接，队列被清空，也没有自动发出新的用户请求。

调用关系：这个测试覆盖中断后的队列恢复流程。它确认 handle_turn_interrupted 的职责是把待发内容还给用户，而不是继续悄悄发送。

调用图：调用 1 个内部函数（from）；外部调用 2 个（assert!, assert_eq!）。

async fn interrupt_prepends_queued_messages_before_existing_composer_text()

作用：测试任务中断时，如果输入框里已经有草稿，排队消息会放在草稿前面一起恢复。这样既不丢队列，也不覆盖用户当前正在写的内容。

数据流：它让任务运行，输入框已有“current draft”，队列里有两条消息。中断后输入框变成“first queued\nsecond queued\ncurrent draft”，队列清空，没有额外提交操作。

调用关系：这个测试是队列恢复测试的扩展场景。它确认中断恢复会合并两类未发送内容，并保持排队消息在前、当前草稿在后的顺序。

调用图：调用 1 个内部函数（from）；外部调用 3 个（new, assert!, assert_eq!）。

async fn exec_approval_emits_proposed_command_and_decision_history()

作用：检查当系统请求用户批准一条命令时，界面先弹出审批窗口，而不是直接把请求写进聊天历史；用户按下同意后，才写入一条简短的决定记录。

数据流：输入是一条假的执行审批请求，里面有命令、目录和理由；测试把它交给聊天组件，读取历史输出并渲染界面；最后模拟用户按 y，同意结果会变成一条历史记录，并被拿去和快照标准答案比较。

调用关系：它验证审批流程的前半段：handle_exec_approval_request 把请求放进界面状态，chat.render 显示弹窗，chat.handle_key_event 处理用户决定，drain_insert_history 收集最终写入历史的内容。

调用图：调用 1 个内部函数（current_dir）；外部调用 7 个（Char, new, new, assert!, assert_chatwidget_snapshot!, empty, vec!）。

fn app_server_exec_approval_request_splits_shell_wrapped_command()

作用：检查从应用服务器来的命令字符串，如果是“shell 外壳包了一层”的形式，能被正确拆回命令数组。

数据流：输入是一段像 /bin/zsh -lc '脚本' 的命令字符串和工作目录；转换函数把字符串解析成多个参数；输出应该是 shell 路径、-lc、原始脚本这三个部分，而不是一整坨字符串。

调用关系：它保护 exec_approval_request_from_params 这个转换入口，确保后端协议里的命令到前端审批事件时不会丢失参数边界。

调用图：外部调用 2 个（assert_eq!, try_join）。

async fn exec_approval_uses_approval_id_when_present()

作用：确认审批请求里如果有单独的 approval_id，用户批准时发回去的就是这个 id，而不是父级 call_id。

数据流：输入是一条 call_id 和 approval_id 不同的审批请求；测试模拟用户按 y；输出通道里应该出现一个 ExecApproval 操作，里面的 id 是 approval_id，决定是接受。

调用关系：它覆盖用户按键到提交操作这条链路，防止后端需要用 approval_id 对账时，前端错用了 call_id。

调用图：调用 1 个内部函数（current_dir）；外部调用 6 个（Char, new, assert!, assert_eq!, assert_matches!, vec!）。

async fn exec_approval_decision_truncates_multiline_and_long_commands()

作用：检查审批决定写入历史时，命令摘要不会太长，也不会把多行命令原样塞进一行历史里。

数据流：输入分别是多行命令和超长单行命令；界面先用弹窗展示审批请求，用户按 n 拒绝；输出历史里只保留被压短的单行摘要，并用快照确认格式。

调用关系：它连接审批弹窗、拒绝按键和历史摘要渲染，确保详细命令留在弹窗里，历史记录保持干净好读。

调用图：调用 1 个内部函数（current_dir）；外部调用 9 个（Char, new, new, new, assert!, assert_chatwidget_snapshot!, format!, empty, vec!）。

async fn preamble_keeps_working_status_snapshot()

作用：检查模型先输出一段开场白后，界面底部的“正在工作”状态仍然能恢复显示。

数据流：输入是一次任务开始、模型流式输出一行文字、提交到历史、再完成一条 commentary 消息；测试渲染整个聊天组件；输出是快照，用来确认开场白和状态栏同时存在。

调用关系：它覆盖任务开始、消息增量、提交 tick、助手消息完成和最终渲染之间的配合，防止开场白把工作状态挤没。

调用图：调用 1 个内部函数（new）；外部调用 3 个（assert_chatwidget_snapshot!, new, new）。

async fn unified_exec_begin_restores_status_indicator_after_preamble()

作用：检查后台统一执行开始时，如果状态指示器之前被隐藏了，会重新显示出来。

数据流：输入是一个正在运行但状态栏被手动隐藏的聊天组件；测试触发统一执行启动；输出是状态指示器重新变为可见。

调用关系：它专门保护 begin_unified_exec_startup 对底部状态栏的修复行为，避免后台命令开始后用户看不到系统还在忙。

调用图：外部调用 1 个（assert_eq!）。

async fn unified_exec_begin_restores_working_status_snapshot()

作用：检查在已有开场白历史后，启动统一执行命令会把“正在工作”的界面状态恢复到正确样子。

数据流：输入是任务开始和一段已提交的开场白；测试启动后台命令并渲染组件；输出快照确认历史和工作状态的组合显示正确。

调用关系：它和前一个测试类似，但更关注真实渲染结果，确保 begin_unified_exec_startup 后 chat.render 的画面没坏。

调用图：外部调用 4 个（new, assert_chatwidget_snapshot!, new, new）。

async fn exec_history_cell_shows_working_then_completed()

作用：检查普通命令从开始到成功结束时，历史记录只在结束后写入，并显示命令内容。

数据流：输入是一条 echo done 命令的开始事件和成功结束事件；开始时历史输出为空；结束后输出一条已完成的历史单元，里面包含“Ran”和命令文本。

调用关系：它验证 begin_exec 与 end_exec 的基本配合：开始先留在活动区，结束才刷进历史。

调用图：外部调用 2 个（assert!, assert_eq!）。

async fn exec_history_cell_shows_working_then_failed()

作用：检查命令失败时也会立刻生成历史记录，并显示错误输出。

数据流：输入是一条 false 命令的开始事件和带错误文本的失败结束事件；输出是一条历史单元，包含命令和错误信息。

调用关系：它补齐成功路径之外的失败路径，保证 end_exec 不会因为退出码非零而漏掉记录。

调用图：外部调用 2 个（assert!, assert_eq!）。

async fn exec_end_without_begin_uses_event_command()

作用：检查如果收到命令结束事件时没见过对应开始事件，界面仍能用结束事件里的命令内容生成历史记录。

数据流：输入是一条只有结束信息的命令执行事件，里面带完整命令、输出、状态和工作目录；测试处理后读取历史；输出应显示 echo orphaned，而不是显示内部 call id。

调用关系：它保护 handle_exec_end 的兜底能力：即使事件顺序不完整，也尽量给用户一个可读的结果。

调用图：调用 2 个内部函数（parse_command, shlex_join）；外部调用 3 个（assert!, assert_eq!, vec!）。

async fn exec_end_without_begin_does_not_flush_unrelated_running_exploring_cell()

作用：检查一个陌生命令结束时，不会错误地把另一个还在运行的“探索文件”记录刷进历史。

数据流：输入是一个正在运行的读取命令，以及另一个孤立后台命令的开始和结束；输出历史只包含孤立命令，活动区仍保留原来的探索命令。

调用关系：它防止 end_exec 处理孤立结束事件时误伤 transcript.active_cell 中无关的运行中内容。

调用图：外部调用 2 个（assert!, assert_eq!）。

async fn exec_end_without_begin_flushes_completed_unrelated_exploring_cell()

作用：检查如果活动区里已有一个完成但尚未刷新的探索记录，新的孤立命令完成时会先把旧记录刷出去，再写新记录。

数据流：输入是一个已完成的 ls 探索记录和一个后来的孤立 echo 命令；输出历史有两条，先是探索记录，后是 echo after，活动区清空。

调用关系：它验证历史顺序和活动单元收尾逻辑，避免旧完成项被新事件覆盖。