协议 schema 和线格式验证

fn client_response_payload_returns_jsonrpc_parts_and_client_response() -> Result<()>

作用：这个测试确认“线程归档”这种响应在转成 JSON-RPC 结果后，还能再变成一个带请求编号的客户端响应。它防止归档响应在转换过程中丢掉请求编号，或者被错误地当成普通结果处理完就结束。

数据流：输入是一个 ThreadArchive 响应和请求编号 7。测试把它交给转换函数，得到三个东西：返回用的请求编号、JSON-RPC 的 result、以及可能存在的额外载荷。然后它检查编号仍然是 7，result 是空 JSON 对象，再把额外载荷转成 ClientResponse，确认它确实是 ThreadArchive 类型，并且里面的请求编号也还是 7；如果不是，就直接让测试失败。

调用关系：这个函数在测试运行时由测试框架自动调用。它主要把样例数据送进 ClientResponsePayload 的转换流程，然后用断言检查结果；如果转换出来的额外载荷不是预期的 ThreadArchive 客户端响应，它会触发 panic，让开发者知道协议转换被改坏了。

调用图：外部调用 4 个（ThreadArchive, Integer, assert_eq!, panic!）。

fn interrupt_conversation_payload_stays_jsonrpc_only() -> Result<()>

作用：这个测试确认“中断对话”响应只作为 JSON-RPC 的普通返回值出现，不会再生成额外的客户端响应。它防止同一个中断消息被系统重复处理两次。

数据流：输入是一个 InterruptConversation 响应，里面带有中断原因 Interrupted，以及请求编号 8。测试把它转换成 JSON-RPC 相关结果后，检查返回编号还是 8，result 里正确写着 abortReason 为 interrupted，并且额外载荷是空的。最终没有额外消息被留下，说明这类响应只走 JSON-RPC 返回通道。

调用关系：这个函数同样由测试框架自动执行。它覆盖的是和线程归档相反的分支：转换流程只该产出标准 JSON-RPC 结果，不该再交给 into_client_response 之类的后续客户端响应流程。断言失败时，就说明中断响应的协议边界被破坏了。

调用图：外部调用 4 个（InterruptConversation, Integer, assert!, assert_eq!）。

fn remote_control_clients_list_params_serialize_nullable_optional_fields()

作用：这个测试确认“列出远程控制客户端”的请求参数转成 JSON 时，字段名和值长得对。特别是那些没有填的可选字段，必须变成 JSON 里的 null。

数据流：进去的是一个 RemoteControlClientsListParams 参数对象，里面有 environment_id，其他 cursor、limit、order 都是 None，也就是“没填”。测试把它交给 serde_json 转成 JSON 值，然后和预期 JSON 对比。结果应该是 environment_id 变成 environmentId，三个没填的字段都明确变成 null；测试本身不改系统数据，只是在不符合预期时失败。

调用关系：它是独立的单元测试，由测试框架在跑测试时调用。它主要依赖 serde_json 完成对象到 JSON 的转换，再用 assert_eq! 这类断言工具检查实际结果和预期是否一模一样。

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

fn remote_control_clients_list_params_deserialize_camel_case_fields()

作用：这个测试确认从外部收到的 JSON 能正确读成 Rust 里的查询参数对象。它重点检查接口里常见的驼峰字段名 environmentId，能不能变回代码里的 environment_id。

数据流：进去的是一段 JSON，包含 environmentId、cursor、limit、order。测试用 serde_json 把这段 JSON 解析成 RemoteControlClientsListParams。出来的结果应该是 environment_id 等于 env-123，cursor 和 limit 被放进 Some 里，order 的字符串 asc 被识别成 RemoteControlClientsListOrder::Asc；如果任何字段读错，断言就会失败。

调用关系：它也是由测试框架自动执行的格式兼容性检查。它站在“收到外部请求”的角度，验证协议层定义是否能吃下接口约定的 JSON，然后用 assert_eq! 把解析结果和手写的正确对象做比较。

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

fn remote_control_clients_revoke_response_serializes_as_empty_object()

作用：这个测试确认“撤销远程控制客户端”的响应即使没有字段，也要转成空 JSON 对象 {}。这样调用方能收到一个稳定、明确的响应形状。

数据流：进去的是一个没有任何字段的 RemoteControlClientsRevokeResponse 对象。测试把它序列化成 JSON，然后检查结果是不是 {}。出来的结果不是业务数据，而是一个测试结论：如果序列化成 null、数组或带多余字段的对象，测试就会失败。

调用关系：它在测试阶段由测试框架调用，覆盖的是响应格式这一小块协议约定。它把实际序列化工作交给 serde_json，再用 assert_eq! 确认响应空对象的约定没有被破坏。

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

fn absolute_path_string(path: &str) -> String

作用：把一个测试用路径整理成绝对路径字符串。这样测试里不用关心当前系统具体怎么显示路径。

数据流：输入一个路径片段 → 先确保它前面有斜杠，再交给测试路径工具生成路径 → 输出这个路径的字符串形式。

调用关系：这是测试辅助函数，会被测试代码间接或直接用来拼 JSON 里的路径；它把实际造路径的活交给 test_path_buf。

调用图：外部调用 2 个（test_path_buf, format!）。

fn absolute_path(path: &str) -> AbsolutePathBuf

作用：把一个测试用路径整理成 AbsolutePathBuf，也就是“确认是绝对路径”的路径对象。它让权限、文件系统、沙箱相关测试能拿到合法路径。

数据流：输入路径片段 → 补成绝对路径写法 → 用测试路径工具转换成绝对路径对象 → 返回给测试使用。

调用关系：很多测试需要绝对路径时会调用它，比如文件读写、权限根目录、沙箱 writableRoots；它依赖 test_path_buf 造出跨平台测试路径。

调用图：被 8 处调用（additional_file_system_permissions_populates_entries_for_legacy_roots, fs_copy_params_round_trip_with_recursive_directory_copy, fs_create_directory_params_round_trip_with_default_recursive, fs_read_file_params_round_trip, fs_write_file_params_round_trip_with_base64_data, sandbox_policy_deserializes_legacy_workspace_write_full_access_field, test_absolute_path, thread_resume_response_round_trips_initial_turns_page）；外部调用 2 个（test_path_buf, format!）。

fn test_absolute_path() -> AbsolutePathBuf

作用：提供一个固定的测试绝对路径，省得每个测试重复写同样的路径名。

数据流：没有外部输入 → 调用 absolute_path("readable") → 返回一个名为 readable 的绝对路径对象。

调用关系：进程启动参数测试会用它当 cwd；它只是 absolute_path 的小包装。

调用图：调用 1 个内部函数（absolute_path）；被 2 处调用（process_spawn_params_distinguish_omitted_null_and_value_limits, process_spawn_params_round_trips_without_sandbox_policy）。

fn thread_sources_round_trip_as_scalar_labels()

作用：确认线程来源会被写成简单字符串，并且能从字符串读回原来的值。这样 API JSON 更简洁，也能和核心协议互转。

数据流：准备多种 ThreadSource → 转成 JSON 字符串标签，再读回类型，并和核心协议类型互转 → 检查结果没有变。

调用关系：由测试框架运行；它主要检查 serde_json 序列化和 ThreadSource 与核心协议类型之间的转换。

调用图：外部调用 3 个（Feature, assert_eq!, to_value）。

fn approvals_reviewer_serializes_auto_review_and_accepts_legacy_guardian_subagent()

作用：确认审批评审者字段能写出新名字，也能读懂旧名字 guardian_subagent。这样老客户端发来的数据不会突然失效。

数据流：输入 user、auto_review、guardian_subagent 这些 JSON 字符串 → 反序列化成枚举 → guardian_subagent 被当成 AutoReview。

调用关系：测试框架调用它；它把检查交给 serde_json，并用断言确认兼容逻辑。

调用图：外部调用 3 个（assert_eq!, format!, from_str）。

fn turn_defaults_legacy_missing_items_view_to_full()

作用：确认旧版 turn 数据没有 itemsView 字段时，默认按完整加载处理。没有这个默认值，老记录可能读不出来或显示不完整。

数据流：输入缺少 itemsView 的旧 JSON → 读成 Turn → 检查 items_view 自动变成 Full。

调用关系：测试框架运行；它验证 Turn 的反序列化默认值。

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

fn thread_turns_list_params_accepts_items_view()

作用：确认列出线程回合的请求能接收 itemsView 参数，比如只拿占位信息而不加载完整内容。

数据流：输入包含 threadId、分页和 itemsView 的 JSON → 读成 ThreadTurnsListParams → 检查线程 ID 和视图选项正确。

调用关系：测试框架调用；它专门覆盖线程回合列表参数的 JSON 输入。

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

fn thread_resume_params_accept_turns_page_bootstrap()

作用：确认恢复线程时可以顺便带上“初始回合页”的加载设置。这样客户端打开线程时能一次说明要先取多少历史回合。

数据流：输入带 initialTurnsPage 的 JSON → 读成 ThreadResumeParams → 输出包含 limit、排序方向、itemsView 的结构。

调用关系：测试框架调用；它检查 ThreadResumeParams 对嵌套分页参数的解析。

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

fn thread_resume_response_round_trips_initial_turns_page()

作用：确认恢复线程响应里的初始回合页能写成 JSON，再读回来不丢信息。

数据流：构造一个 ThreadResumeResponse → 转成 JSON 检查 initialTurnsPage 字段 → 再读回结构并和原值比较。

调用关系：测试框架运行；它使用 absolute_path 造 cwd，并验证 ThreadResumeResponse 的完整往返。

调用图：调用 1 个内部函数（absolute_path）；外部调用 4 个（new, new, assert_eq!, to_value）。

fn thread_turns_items_list_round_trips()

作用：确认列出某个回合内项目的请求和响应 JSON 格式稳定。它覆盖分页游标和项目数组这类容易拼错的字段。

数据流：构造请求参数和响应对象 → 分别转 JSON → 检查字段名、游标和值都符合约定。

调用关系：测试框架调用；它只依赖序列化和断言，不调用项目内部流程。

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

fn thread_list_params_accepts_single_cwd()

作用：确认线程列表过滤条件可以接收单个工作目录字符串。

数据流：输入 {cwd:"/workspace"} → 读成 ThreadListParams → cwd 变成 One，useStateDbOnly 保持默认 false。

调用关系：测试框架运行；它验证 ThreadListParams 的兼容输入形式。

调用图：外部调用 3 个（assert!, assert_eq!, json!）。

fn thread_list_params_accepts_multiple_cwds()

作用：确认线程列表过滤条件也可以接收多个工作目录数组。

数据流：输入 cwd 数组 → 读成 ThreadListParams → cwd 变成 Many 并保存两个路径字符串。

调用关系：测试框架运行；它和单 cwd 测试一起保证过滤参数灵活。

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

fn thread_list_params_accepts_state_db_only_flag()

作用：确认线程列表请求能识别 useStateDbOnly 开关，表示只查状态数据库。

数据流：输入带 useStateDbOnly:true 的 JSON → 读成参数 → 输出对象里的布尔值为 true。

调用关系：测试框架调用；它覆盖一个简单但影响查询来源的标志位。

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

fn collab_agent_state_maps_interrupted_status()

作用：确认核心协议里的“被中断”代理状态能正确映射到 v2 协议状态。

数据流：输入 CoreAgentStatus::Interrupted → 转成 CollabAgentState → 得到 Interrupted 且没有消息。

调用关系：测试框架运行；它验证核心协议到 v2 类型的转换。

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

fn external_agent_config_plugins_details_round_trip()

作用：确认外部代理配置迁移里的插件详情可以从 JSON 正确读出来。

数据流：输入包含插件市场名和插件名列表的迁移 JSON → 读成迁移项 → 检查类型、说明、cwd、details 都保留。

调用关系：测试框架运行；它覆盖外部代理配置迁移的插件字段。

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

fn external_agent_config_import_params_accept_legacy_plugin_details()

作用：确认导入外部代理配置时，旧版插件详情格式仍然能被接受。

数据流：输入 migrationItems 数组 JSON → 读成 ExternalAgentConfigImportParams → 得到包含插件迁移详情的参数。

调用关系：测试框架调用；它保证导入入口能复用上一个迁移项的兼容解析。

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

fn command_execution_request_approval_localization_rejects_relative_additional_permission_paths()

作用：确认命令审批里额外文件权限不能用相对路径。权限路径必须明确，否则可能把访问范围解释错。

数据流：输入带 relative/path 的审批 JSON → 先读成 API 参数 → 再转核心权限时失败，并返回 InvalidInput。

调用关系：测试框架运行；它先验证 API 层能读入，再把校验交给 CoreAdditionalPermissionProfile::try_from。

调用图：外部调用 3 个（try_from, assert_eq!, json!）。

fn permissions_request_approval_uses_request_permission_profile()

作用：确认权限申请使用的是“请求权限配置”，并能转成核心协议里的网络和文件权限。

数据流：输入带网络开关、读写路径、环境 ID 的 JSON → 读成 v2 参数 → 再转换成核心 RequestPermissionProfile。

调用关系：测试框架运行；它连接 v2 权限结构和核心权限结构，路径按操作系统选择。

调用图：外部调用 3 个（assert_eq!, cfg!, json!）。

fn permissions_request_approval_rejects_macos_permissions()

作用：确认权限申请不接受 macos 这个旧的或不属于此协议的字段。

数据流：输入带 macos 权限的 JSON → 尝试读成 PermissionsRequestApprovalParams → 失败并提示未知字段。

调用关系：测试框架调用；它确保协议不会悄悄吞掉不支持的权限字段。

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

fn additional_file_system_permissions_preserves_canonical_entries()

作用：确认新的文件系统权限 entries 格式在 v2 和核心协议之间转换时不会丢。

数据流：输入核心权限 entries，包括根路径写权限和 glob 拒绝规则 → 转 v2 → 再转回核心 → 和原始值一致。

调用关系：测试框架运行；它验证 AdditionalFileSystemPermissions::from 和 CoreFileSystemPermissions::try_from 配合正确。

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

fn additional_file_system_permissions_populates_entries_for_legacy_roots()

作用：确认旧的 read/write 根目录字段会同时补出新的 entries 字段。这样新旧客户端都能看懂同一份权限。

数据流：输入核心读根和写根权限 → 转成 v2 权限 → read/write 和 entries 都被填好 → 再转回核心仍一致。

调用关系：测试框架运行；它调用 absolute_path、from_read_write_roots 和 from_abs_path 来构造路径和兼容字段。

调用图：调用 3 个内部函数（from, absolute_path, from_abs_path）；外部调用 3 个（from_read_write_roots, assert_eq!, vec!）。

fn additional_file_system_permissions_rejects_zero_glob_scan_depth()

作用：确认 glob 扫描深度不能是 0。glob 是通配匹配文件名的规则，深度为 0 没有实际意义也容易误用。

数据流：输入 globScanMaxDepth:0 的 JSON → 尝试读成权限对象 → 反序列化失败。

调用关系：测试框架运行；它验证 NonZeroUsize 这类“必须大于零”的约束被 JSON 层执行。

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

fn legacy_current_working_directory_special_path_deserializes_as_project_roots()

作用：确认旧名字 current_working_directory 会被读成新名字 project_roots。

数据流：输入旧特殊路径 JSON → 读成 FileSystemSpecialPath::ProjectRoots → 再写 JSON 时输出新格式。

调用关系：测试框架运行；它保证特殊路径字段改名后仍兼容旧数据。

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

fn permissions_request_approval_response_uses_granted_permission_profile_without_macos()

作用：确认权限审批响应使用“授予权限配置”，并且不包含 macOS 专用权限。

数据流：输入网络和文件读写权限 JSON → 读成响应 → 再转换成核心 AdditionalPermissionProfile。

调用关系：测试框架运行；它和请求权限测试相对，覆盖用户批准后返回的权限形状。

调用图：外部调用 3 个（assert_eq!, cfg!, json!）。

fn permissions_request_approval_response_defaults_scope_to_turn()

作用：确认权限审批响应没写 scope 时，默认只对当前回合有效。

数据流：输入只有 permissions 的 JSON → 读成响应 → scope 自动变成 Turn，strict_auto_review 为空。

调用关系：测试框架调用；它验证安全默认值，避免权限默认变成更大范围。

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

fn permissions_request_approval_response_accepts_strict_auto_review()

作用：确认权限审批响应能携带 strictAutoReview 开关。

数据流：输入 strictAutoReview:true → 读成响应 → 输出字段为 Some(true)。

调用关系：测试框架调用；它覆盖审批响应里的可选自动审查标志。

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

fn permission_profile_selection_uses_id_string()

作用：确认线程启动、回合启动、命令执行、恢复和分叉都用权限配置的 ID 字符串来选择权限。

数据流：分别输入多个请求 JSON → 读成对应参数 → permissions 或 permissionProfile 都保存为字符串。

调用关系：测试框架运行；它把多个入口放在一个测试里，保证权限配置选择方式一致。

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

fn thread_path_params_deserialize_empty_path_as_none()

作用：确认恢复或分叉线程时，空字符串路径会被当成没有路径。

数据流：输入 path:"" → 读成参数 → path 为 None；输入真实路径 → path 为 Some(PathBuf)。

调用关系：测试框架调用；它防止空路径被误当成有效文件路径。

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

fn fs_get_metadata_response_round_trips_minimal_fields()

作用：确认文件元数据响应的基础字段能稳定转 JSON 再读回。

数据流：构造是否目录、是否文件、时间戳等字段 → 转 JSON → 再读回响应对象。

调用关系：测试框架运行；它覆盖 fs/getMetadata 响应格式。

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

fn fs_read_file_response_round_trips_base64_data()

作用：确认读文件响应用 base64 字符串传文件内容。base64 是把二进制安全塞进文本 JSON 的常见编码。

数据流：构造 dataBase64 为 aGVsbG8= 的响应 → 转 JSON → 再读回对象。

调用关系：测试框架运行；它覆盖 fs/readFile 的响应格式。

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

fn fs_read_file_params_round_trip()

作用：确认读文件请求里的路径能正确写入 JSON 并读回。

数据流：输入测试绝对路径 → 构造 FsReadFileParams → 转 JSON 检查 path → 再读回参数。

调用关系：测试框架运行；它调用 absolute_path 来生成合法路径。

调用图：调用 1 个内部函数（absolute_path）；外部调用 2 个（assert_eq!, to_value）。

fn fs_create_directory_params_round_trip_with_default_recursive()

作用：确认创建目录请求中 recursive 没设置时会以 null 形式稳定表示。

数据流：构造路径和 recursive:None → 转 JSON → 再读回相同参数。

调用关系：测试框架运行；它覆盖 fs/createDirectory 参数格式，并用 absolute_path 造路径。

调用图：调用 1 个内部函数（absolute_path）；外部调用 2 个（assert_eq!, to_value）。

fn fs_write_file_params_round_trip_with_base64_data()

作用：确认写文件请求能带路径和 base64 编码的数据。

数据流：输入绝对路径和 AAE= 数据 → 转 JSON → 再读回 FsWriteFileParams。

调用关系：测试框架运行；它覆盖 fs/writeFile 参数格式。

调用图：调用 1 个内部函数（absolute_path）；外部调用 2 个（assert_eq!, to_value）。

fn fs_copy_params_round_trip_with_recursive_directory_copy()

作用：确认复制文件或目录的请求能表示源路径、目标路径和递归复制开关。

数据流：输入源、目标绝对路径和 recursive:true → 转 JSON → 再读回相同参数。

调用关系：测试框架运行；它调用 absolute_path 生成两个路径。

调用图：调用 1 个内部函数（absolute_path）；外部调用 2 个（assert_eq!, to_value）。

fn thread_shell_command_params_round_trip()

作用：确认向线程发送 shell 命令的参数格式稳定。

数据流：构造 threadId 和命令字符串 → 转 JSON → 再读回 ThreadShellCommandParams。

调用关系：测试框架运行；它覆盖 thread/shellCommand 请求参数。

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

fn thread_shell_command_response_round_trip()

作用：确认 shell 命令响应即使是空对象，也能稳定序列化和反序列化。

数据流：构造空响应 → 转成 {} → 再读回响应对象。

调用关系：测试框架运行；它覆盖 thread/shellCommand 的空响应约定。

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

fn fs_changed_notification_round_trips()

作用：确认文件变化通知能带 watchId 和变化路径列表。

数据流：构造通知对象和两个变更路径 → 转 JSON → 再读回通知对象。

调用关系：测试框架运行；它覆盖文件监听通知格式。

调用图：外部调用 3 个（assert_eq!, to_value, vec!）。

fn command_exec_params_default_optional_streaming_flags()

作用：确认命令执行参数没写流式输入输出开关时，默认都为 false。

数据流：输入只含 command、timeoutMs、cwd 的 JSON → 读成 CommandExecParams → 补齐默认的 tty、stream 等字段。

调用关系：测试框架运行；它验证 command/exec 请求的默认值。

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

fn command_exec_params_round_trips_disable_timeout()

作用：确认命令执行请求可以明确关闭超时限制。

数据流：构造 disableTimeout:true 的参数 → 转 JSON → 再读回对象，保持 timeoutMs:null。

调用关系：测试框架运行；它覆盖 command/exec 中超时控制字段。

调用图：外部调用 3 个（assert_eq!, to_value, vec!）。

fn process_spawn_params_round_trips_without_sandbox_policy()

作用：确认底层进程启动参数不包含沙箱策略字段，并且格式能往返。

数据流：构造 process/spawn 参数 → 转 JSON 检查没有 sandboxPolicy → 再读回同样对象。

调用关系：测试框架运行；它调用 test_absolute_path 提供 cwd。

调用图：调用 1 个内部函数（test_absolute_path）；外部调用 3 个（assert_eq!, to_value, vec!）。

fn process_spawn_params_distinguish_omitted_null_and_value_limits()

作用：确认进程启动限制字段能区分“没写”、“写了 null”、“写了具体值”。这三种含义不同。

数据流：分别输入省略限制、null 限制、具体数字限制的 JSON → 读成参数 → 得到 None、Some(None)、Some(Some 值)。

调用关系：测试框架运行；它覆盖 process/spawn 对输出上限和超时上限的三态解析。

调用图：调用 1 个内部函数（test_absolute_path）；外部调用 3 个（assert_eq!, json!, vec!）。

fn command_exec_params_round_trips_disable_output_cap()

作用：确认命令执行请求可以明确关闭输出大小限制。

数据流：构造 disableOutputCap:true 的命令参数 → 转 JSON → 再读回保持该开关。

调用关系：测试框架运行；它覆盖 command/exec 的输出截断控制。

调用图：外部调用 3 个（assert_eq!, to_value, vec!）。

fn command_exec_params_round_trips_env_overrides_and_unsets()

作用：确认命令执行时环境变量既能覆盖、添加，也能通过 null 删除。

数据流：构造 env 映射，FOO/BAR 有值，BAZ 为 null → 转 JSON → 再读回保持每个变量的意图。

调用关系：测试框架运行；它验证环境变量字段的 HashMap 表示。

调用图：外部调用 4 个（from, assert_eq!, to_value, vec!）。

fn command_exec_write_round_trips_close_only_payload()

作用：确认给运行中命令写 stdin 时，可以只发送“关闭输入”而不发送数据。

数据流：构造 processId、deltaBase64:null、closeStdin:true → 转 JSON → 再读回。

调用关系：测试框架运行；它覆盖 command/exec/write 请求格式。

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

fn command_exec_terminate_round_trips()

作用：确认终止命令执行的请求只需要进程 ID，并能稳定往返。

数据流：输入 process_id → 转成 JSON 的 processId → 再读回参数。

调用关系：测试框架运行；它覆盖 command/exec/terminate 参数。

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

fn command_exec_params_round_trip_with_size()

作用：确认命令执行使用伪终端时，可以携带终端行列大小。

数据流：构造 tty:true 和 size rows/cols → 转 JSON → 再读回参数。

调用关系：测试框架运行；它覆盖 command/exec 的终端尺寸字段。

调用图：外部调用 3 个（assert_eq!, to_value, vec!）。

fn command_exec_resize_round_trips()

作用：确认运行中的命令终端可以发送新的窗口大小。

数据流：构造 processId 和 rows/cols → 转 JSON → 再读回 CommandExecResizeParams。

调用关系：测试框架运行；它覆盖 command/exec/resize 请求。

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

fn command_exec_output_delta_round_trips()

作用：确认命令执行的输出增量通知能携带 stdout/stderr、base64 数据和是否触顶。

数据流：构造 stdout 增量通知 → 转 JSON → 再读回通知对象。

调用关系：测试框架运行；它覆盖 command/exec/outputDelta 通知。

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

fn process_control_params_round_trip()

作用：确认底层进程控制的写输入、调整终端、杀进程三种请求格式稳定。

数据流：分别构造 writeStdin、resizePty、kill 参数 → 各自转 JSON → 再读回。

调用关系：测试框架运行；它集中覆盖 process 控制类 API。

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

fn process_notifications_round_trip()

作用：确认底层进程输出和退出通知的 JSON 格式稳定。

数据流：构造输出增量通知和退出通知 → 分别转 JSON → 再读回并比较。

调用关系：测试框架运行；它覆盖 process/outputDelta 和 process/exited 通知。

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

fn command_execution_output_delta_round_trips()

作用：确认某个线程项目里的命令输出增量能直接以文本 delta 表示。

数据流：构造 threadId、turnId、itemId 和文本增量 → 转 JSON → 再读回通知。

调用关系：测试框架运行；它覆盖 item/commandExecution/outputDelta 通知。

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

fn sandbox_policy_round_trips_external_sandbox_network_access()

作用：确认外部沙箱策略里的网络权限能和核心协议互转。

数据流：构造 v2 ExternalSandbox 且网络启用 → 转核心策略 → 再从核心转回 v2。

调用关系：测试框架运行；它验证 SandboxPolicy::to_core 和 from 的配合。

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

fn sandbox_policy_round_trips_read_only_network_access()

作用：确认只读沙箱策略里的网络访问布尔值能和核心协议互转。

数据流：构造 v2 ReadOnly network_access:true → 转核心 → 再转回 v2。

调用关系：测试框架运行；它覆盖 SandboxPolicy 只读分支。

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

fn ask_for_approval_granular_round_trips_request_permissions_flag()

作用：确认细粒度审批策略里的 request_permissions 开关不会在核心协议互转时丢失。

数据流：构造 Granular 审批策略 → 转核心 CoreGranularApprovalConfig → 再转回 v2。

调用关系：测试框架运行；它验证 AskForApproval 与核心审批配置的映射。

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

fn ask_for_approval_granular_defaults_missing_optional_flags_to_false()

作用：确认细粒度审批 JSON 缺少某些开关时，默认是 false。

数据流：输入只含部分 granular 字段的 JSON → 读成 AskForApproval → skill_approval 和 request_permissions 自动为 false。

调用关系：测试框架运行；它覆盖审批策略的兼容默认值。

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

fn ask_for_approval_granular_is_marked_experimental()

作用：确认细粒度审批被标为实验功能，而普通审批不标记。

数据流：输入 Granular 和 OnRequest 两种策略 → 调 experimental_reason → 分别得到原因字符串和 None。

调用关系：测试框架运行；它验证 experimental_api 对 AskForApproval 的识别。

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

fn config_granular_approval_policy_is_marked_experimental()

作用：确认配置文件里使用细粒度审批时，会触发实验功能标记。

数据流：构造 Config，approval_policy 为 Granular → 调 experimental_reason → 得到 askForApproval.granular。

调用关系：测试框架运行；它把实验标记检查放到 Config 层。

调用图：外部调用 3 个（new, experimental_reason, assert_eq!）。

fn config_approvals_reviewer_is_marked_experimental()

作用：确认配置里的自动审批评审者 AutoReview 会被标为实验功能。

数据流：构造 approvals_reviewer 为 AutoReview 的 Config → 调 experimental_reason → 得到 config/read.approvalsReviewer。

调用关系：测试框架运行；它覆盖 Config 中另一个实验字段。

调用图：外部调用 3 个（new, experimental_reason, assert_eq!）。

fn config_requirements_granular_allowed_approval_policy_is_marked_experimental()

作用：确认配置要求中允许细粒度审批策略时，也会被标为实验功能。

数据流：构造 ConfigRequirements，allowed_approval_policies 包含 Granular → 调 experimental_reason → 得到实验原因。

调用关系：测试框架运行；它验证限制清单里的实验功能也能被发现。

调用图：外部调用 3 个（experimental_reason, assert_eq!, vec!）。

fn client_request_thread_start_granular_approval_policy_is_marked_experimental()

作用：确认 thread/start 请求里使用细粒度审批会触发实验标记。

数据流：构造 ClientRequest::ThreadStart → 参数里放 Granular 审批 → experimental_reason 返回对应原因。

调用关系：测试框架运行；它覆盖客户端请求入口的实验功能检查。

调用图：外部调用 4 个（default, experimental_reason, Integer, assert_eq!）。

fn client_request_thread_resume_granular_approval_policy_is_marked_experimental()

作用：确认 thread/resume 请求里使用细粒度审批会触发实验标记。

数据流：构造 ClientRequest::ThreadResume → 放入 Granular 审批参数 → 得到实验原因字符串。

调用关系：测试框架运行；它和启动、分叉、回合启动请求一起保证入口检查一致。

调用图：外部调用 4 个（default, experimental_reason, Integer, assert_eq!）。

fn client_request_thread_fork_granular_approval_policy_is_marked_experimental()

作用：确认 thread/fork 请求里使用细粒度审批会触发实验标记。

数据流：构造 ClientRequest::ThreadFork → approval_policy 为 Granular → experimental_reason 返回 askForApproval.granular。

调用关系：测试框架运行；它覆盖线程分叉入口。

调用图：外部调用 4 个（default, experimental_reason, Integer, assert_eq!）。

fn client_request_turn_start_granular_approval_policy_is_marked_experimental()

作用：确认 turn/start 请求里使用细粒度审批会触发实验标记。

数据流：构造 ClientRequest::TurnStart → 参数里放 Granular 审批 → 得到实验原因。

调用关系：测试框架运行；它覆盖启动新一轮对话的请求入口。

调用图：外部调用 5 个（default, new, experimental_reason, Integer, assert_eq!）。

fn mcp_server_elicitation_response_round_trips_rmcp_result()

作用：确认 MCP 服务器的询问响应能和 rmcp 库的结果类型互转。MCP 是让模型调用外部工具的一套协议。

数据流：构造 rmcp 的接受响应和内容 JSON → 转成 v2 响应 → 再转回 rmcp 类型。

调用关系：测试框架运行；它验证 v2 协议和 rmcp 库类型之间的桥接。

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

fn mcp_server_elicitation_request_from_core_url_request()

作用：确认核心协议里的 URL 型 MCP 询问请求能转成 v2 请求。

数据流：输入 CoreElicitationRequest::Url → try_from 转换 → 输出包含消息、URL、elicitation_id 的 v2 Url 请求。

调用关系：测试框架运行；它覆盖 MCP 询问请求的 URL 分支。

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

fn mcp_server_elicitation_request_from_core_form_request()

作用：确认核心协议里的表单型 MCP 询问请求能转成 v2 请求，并解析表单 schema。

数据流：输入包含 JSON schema 的核心 Form 请求 → 转成 v2 Form → schema 读成 McpElicitationSchema。

调用关系：测试框架运行；它调用 try_from 和 serde_json::from_value 来验证 schema 转换。

调用图：调用 1 个内部函数（try_from）；外部调用 3 个（assert_eq!, json!, from_value）。

fn mcp_elicitation_schema_matches_mcp_2025_11_25_primitives()

作用：确认 MCP 询问表单 schema 支持规定版本里的字符串、整数、布尔和枚举等基础字段。

数据流：输入一份完整 JSON schema → 读成 McpElicitationSchema → 检查每个属性、默认值、必填列表都正确。

调用关系：测试框架运行；它覆盖 MCP schema 解析的主要形状。

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

fn mcp_server_elicitation_request_rejects_null_core_form_schema()

作用：确认表单型 MCP 询问不能接受 null schema。

数据流：输入 requested_schema 为 Null 的核心 Form 请求 → try_from 转换 → 返回错误。

调用关系：测试框架运行；它验证 MCP 表单请求的基本有效性检查。

调用图：调用 1 个内部函数（try_from）；外部调用 2 个（assert!, json!）。

fn mcp_server_elicitation_request_rejects_invalid_core_form_schema()

作用：确认表单型 MCP 询问会拒绝不支持的 schema，比如属性本身又是 object。

数据流：输入含无效 object 属性的 schema → try_from 转换 → 返回错误。

调用关系：测试框架运行；它补充验证 schema 不会随便接受未知结构。

调用图：调用 1 个内部函数（try_from）；外部调用 2 个（assert!, json!）。

fn mcp_server_elicitation_response_serializes_nullable_content()

作用：确认 MCP 询问响应的 content 为空时，会明确写成 null。

数据流：构造 Decline 且 content/meta 都为空的响应 → 转 JSON → 得到 content:null 和 _meta:null。

调用关系：测试框架运行；它覆盖响应里可空字段的 JSON 约定。

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

fn mcp_server_status_serializes_absent_server_info_as_null()

作用：确认 MCP 服务器状态里没有 serverInfo 时，会序列化为 null。

数据流：构造一个没有 server_info 的服务器状态列表响应 → 转 JSON → serverInfo 字段为 null。

调用关系：测试框架运行；它覆盖 MCP 状态列表响应的空值表示。

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

fn mcp_server_status_updated_accepts_missing_thread_id()

作用：确认 MCP 服务器状态更新通知可以没有 threadId。

数据流：输入缺少 threadId 的失败通知 JSON → 读成 thread_id:None → 再序列化时输出 threadId:null。

调用关系：测试框架运行；它保证通知能兼容没有线程上下文的情况。

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

fn mcp_server_status_serializes_absent_server_info_metadata_as_null()

作用：确认 serverInfo 里的可选元数据缺失时，会写成 null。

数据流：构造带 server_info 但 title、description 等为空的状态响应 → 转 JSON → 可选字段都是 null。

调用关系：测试框架运行；它细化检查 MCP 服务器信息对象的空值表示。

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

fn sandbox_policy_round_trips_workspace_write_access()

作用：确认工作区可写沙箱策略能和核心协议互转。

数据流：构造 WorkspaceWrite 策略 → 转核心策略 → 再转回 v2 → 保持 writable_roots、网络和排除选项。

调用关系：测试框架运行；它覆盖 SandboxPolicy 的 workspaceWrite 分支。

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

fn sandbox_policy_deserializes_legacy_read_only_full_access_field()

作用：确认只读沙箱里旧的 fullAccess 字段会被忽略，而不是导致失败。

数据流：输入 readOnly 加 legacy access fullAccess 的 JSON → 读成 ReadOnly 策略 → 保留 networkAccess。

调用关系：测试框架运行；它保证旧客户端多发的无害字段仍可兼容。

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

fn sandbox_policy_deserializes_legacy_workspace_write_full_access_field()

作用：确认 workspaceWrite 沙箱里旧的 readOnlyAccess fullAccess 字段会被忽略。

数据流：输入含 writableRoots、readOnlyAccess fullAccess 的 JSON → 读成 WorkspaceWrite → 路径和开关保留。

调用关系：测试框架运行；它调用 absolute_path 构造 writableRoots。

调用图：调用 1 个内部函数（absolute_path）；外部调用 2 个（assert_eq!, json!）。

fn sandbox_policy_rejects_legacy_read_only_restricted_access_field()

作用：确认已移除的 readOnly.access restricted 字段会被拒绝。这个旧格式含义复杂，不能默默接受。

数据流：输入 restricted access JSON → 尝试读 SandboxPolicy → 返回错误，错误里提到 readOnly.access。

调用关系：测试框架运行；它验证旧字段兼容也有边界。

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

fn sandbox_policy_rejects_legacy_workspace_write_restricted_read_access_field()

作用：确认 workspaceWrite 里旧的 restricted readOnlyAccess 会被拒绝。

数据流：输入 readOnlyAccess restricted 的 JSON → 反序列化 SandboxPolicy 失败 → 错误提到 workspaceWrite.readOnlyAccess。

调用关系：测试框架运行；它和 readOnly restricted 测试一起防止危险旧配置混入。

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

fn automatic_approval_review_deserializes_aborted_status()

作用：确认自动审批评审能读懂 aborted 状态。

数据流：输入 status:"aborted" 且其他字段为空的 JSON → 读成 GuardianApprovalReview → 状态为 Aborted。

调用关系：测试框架运行；它覆盖自动审批评审结果的一种结束状态。

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

fn guardian_approval_review_action_round_trips_command_shape()

作用：确认 Guardian 审批评审动作里的命令形状能稳定往返。

数据流：输入 type:command、source:shell、command、cwd 的 JSON → 读成命令动作 → 再转回同样 JSON。

调用关系：测试框架运行；它验证自动审批系统描述命令动作的格式。

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

fn network_requirements_deserializes_legacy_fields()

作用：确认网络要求还能读懂旧字段 allowedDomains、deniedDomains、allowUnixSockets。

数据流：输入旧字段 JSON → 读成 NetworkRequirements → 旧字段对应的选项被保留，新字段为空。

调用关系：测试框架运行；它保证网络配置迁移期间兼容旧客户端。

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

fn network_requirements_serializes_canonical_and_legacy_fields()

作用：确认网络要求序列化时能同时包含新字段和旧字段。

数据流：构造包含端口、代理、域名权限、Unix socket 权限的新旧字段 → 转 JSON → 检查所有字段名和值。

调用关系：测试框架运行；它覆盖 NetworkRequirements 的完整输出形状。

调用图：外部调用 3 个（from, assert_eq!, vec!）。

fn core_turn_item_into_thread_item_converts_supported_variants()

作用：确认核心协议里的各种回合项目能转换成 v2 的 ThreadItem。回合项目包括用户消息、助手消息、推理、搜索、图片查看、文件改动和 MCP 工具调用。

数据流：逐个构造核心 TurnItem 变体 → 调 ThreadItem::from → 检查 v2 项目的字段、文本合并、持续时间毫秒、引用信息都正确。

调用关系：测试框架运行；它是本文件里覆盖面很大的转换测试，连接 codex_protocol 的核心项目和 v2 API 项目。

调用图：外部调用 14 个（from_millis, from, new, assert_eq!, AgentMessage, FileChange, ImageView, McpToolCall, Reasoning, UserMessage (+4 more)）。

fn user_input_into_core_preserves_image_detail()

作用：确认 v2 用户输入转核心输入时，图片清晰度/detail 信息不会丢。

数据流：构造网络图片和本地图片输入，detail 为 Original → 调 into_core → 得到核心 Image 和 LocalImage，detail 保持不变。

调用关系：测试框架运行；它覆盖 UserInput 到 CoreUserInput 的转换。

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

fn skills_list_params_serialization_uses_force_reload()

作用：确认技能列表参数只有在需要时才写出 cwds 和 forceReload。

数据流：先构造空 cwd 且 force_reload:false → 输出空 JSON；再构造 cwd 和 true → 输出对应字段。

调用关系：测试框架运行；它覆盖 skills/list 请求参数的省略规则。

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

fn skills_extra_roots_set_params_serialization_uses_extra_roots()

作用：确认设置额外技能根目录时，字段名使用 extraRoots。

数据流：输入一个绝对路径列表 → 转 JSON → 得到 extraRoots 数组。

调用关系：测试框架运行；它覆盖 skills/extraRoots/set 参数输出。

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

fn skills_extra_roots_set_params_rejects_relative_roots()

作用：确认额外技能根目录不能是相对路径。

数据流：输入 extraRoots:["relative/path"] → 尝试读参数 → 返回错误。

调用关系：测试框架运行；它保证技能搜索范围必须是明确的绝对路径。

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

fn plugin_source_serializes_local_git_and_remote_variants()

作用：确认插件来源的三种形态：本地、Git 仓库、远程，都能写成规定 JSON。

数据流：分别构造 Local、Git、Remote 来源 → 转 JSON → 检查 type 和相关字段。

调用关系：测试框架运行；它覆盖插件系统最基础的来源描述。

调用图：调用 1 个内部函数（try_from）；外部调用 3 个（from, assert_eq!, cfg!）。

fn marketplace_add_params_serialization_uses_optional_ref_name_and_sparse_paths()

作用：确认添加插件市场时，refName 和 sparsePaths 是可选字段，并按 camelCase 输出。

数据流：构造没有选项和带选项的 MarketplaceAddParams → 转 JSON → 检查 null 或具体数组。

调用关系：测试框架运行；它覆盖 marketplace/add 参数格式。

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

fn marketplace_upgrade_params_serialization_uses_optional_marketplace_name()

作用：确认升级插件市场时 marketplaceName 可省略，也可指定。

数据流：构造 None、空 JSON、Some("debug") 三种情况 → 序列化或反序列化 → 都得到预期对象。

调用关系：测试框架运行；它覆盖 marketplace/upgrade 参数的可选市场名。

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

fn plugin_marketplace_entry_serializes_remote_only_path_as_null()

作用：确认远程-only 插件市场没有本地路径时，path 会写成 null。

数据流：构造 path:None 的 PluginMarketplaceEntry → 转 JSON → path 和 interface 为 null，plugins 为空数组。

调用关系：测试框架运行；它覆盖插件市场条目的空路径情况。

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

fn plugin_interface_serializes_local_paths_and_remote_urls_separately()

作用：确认插件界面信息里，本地图标路径和远程图标 URL 会分别放在不同字段。

数据流：构造带 composerIcon 本地路径、composerIconUrl、logoUrl、screenshotUrls 的接口对象 → 转 JSON → 检查字段分开保存。

调用关系：测试框架运行；它覆盖 PluginInterface 的展示信息序列化。

调用图：调用 1 个内部函数（try_from）；外部调用 5 个（from, new, assert_eq!, cfg!, vec!）。

fn plugin_list_params_ignore_removed_force_remote_sync_field()

作用：确认插件列表请求会忽略已移除的 forceRemoteSync 字段。

数据流：输入带 forceRemoteSync:true 的 JSON → 读成 PluginListParams → 只保留 cwds 和 marketplace_kinds 的默认值。

调用关系：测试框架运行；它保证旧客户端多发字段不会破坏列表请求。

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

fn plugin_list_params_serializes_marketplace_kind_filter()

作用：确认插件列表可以按市场类型过滤，并用规定字符串输出。

数据流：构造多个 marketplaceKinds → 转 JSON → 得到 local、vertical、workspace-directory 等字符串数组。

调用关系：测试框架运行；它覆盖 PluginListParams 的过滤字段。

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

fn plugin_installed_params_serializes_install_suggestion_names()

作用：确认查询已安装插件时，可以带上安装建议插件名列表。

数据流：构造 installSuggestionPluginNames 两个名字 → 转 JSON → cwds 为 null，建议名数组保留。

调用关系：测试框架运行；它覆盖 plugin/installed 参数。

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

fn plugin_read_params_serialization_uses_install_source_fields()

作用：确认读取插件详情时，用 marketplacePath 或 remoteMarketplaceName 表示来源，并忽略旧 forceRemoteSync。

数据流：分别构造本地市场路径和远程市场名输入 → 序列化或反序列化 → 得到正确 PluginReadParams。

调用关系：测试框架运行；它覆盖 plugin/read 的来源选择字段。

调用图：调用 1 个内部函数（try_from）；外部调用 3 个（from, assert_eq!, cfg!）。

fn plugin_install_params_serialization_omits_force_remote_sync()

作用：确认安装插件参数不再输出 forceRemoteSync，但仍能读懂旧请求里带的这个字段。

数据流：构造本地市场路径安装参数 → 转 JSON 不含 forceRemoteSync；再读带旧字段的 JSON → 字段被忽略。

调用关系：测试框架运行；它覆盖 plugin/install 的兼容行为。

调用图：调用 1 个内部函数（try_from）；外部调用 3 个（from, assert_eq!, cfg!）。

fn plugin_skill_read_params_serialization_uses_remote_plugin_id()

作用：确认读取远程插件里的技能时，使用 remotePluginId 字段。

数据流：构造远程市场名、远程插件 ID、技能名 → 转 JSON → 检查三个 camelCase 字段。

调用关系：测试框架运行；它覆盖 plugin/skill/read 参数格式。

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

fn plugin_share_params_and_response_serialization_use_camel_case_fields()

作用：确认插件分享相关的保存、更新、列出、签出、删除请求和响应都使用 camelCase 字段名。

数据流：构造多种分享参数和响应，包括分享目标、发现性、远程插件 ID、本地路径 → 转 JSON 或读 JSON → 检查字段和值。

调用关系：测试框架运行；它集中覆盖插件分享 API 的多种消息形状。

调用图：调用 1 个内部函数（try_from）；外部调用 3 个（from, assert_eq!, cfg!）。

fn plugin_share_list_response_serializes_share_items()

作用：确认插件分享列表响应能正确写出分享条目和嵌套插件摘要。

数据流：构造包含一个远程插件摘要的列表响应 → 转 JSON → 检查 plugin 和 localPluginPath 字段。

调用关系：测试框架运行；它覆盖 plugin/share/list 响应格式。

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

fn plugin_summary_defaults_missing_availability_to_available()

作用：确认旧插件摘要缺少 availability、localVersion、shareContext 时，会使用合理默认值。

数据流：输入缺少这些字段的 PluginSummary JSON → 读成对象 → availability 为 Available，其余为空。

调用关系：测试框架运行；它保证旧插件数据仍能读。

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

fn plugin_availability_deserializes_enabled_alias()

作用：确认旧的 availability 值 ENABLED 会被当成 AVAILABLE。

数据流：输入 JSON 字符串 ENABLED → 读成 PluginAvailability::Available → 再写出为 AVAILABLE。

调用关系：测试框架运行；它覆盖插件可用状态的旧别名兼容。

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

fn plugin_uninstall_params_serialization_omits_force_remote_sync()

作用：确认卸载插件参数只需要 pluginId，并忽略旧 forceRemoteSync 字段。

数据流：构造或输入带 pluginId 的参数 → 转 JSON 不含旧字段；读带旧字段的 JSON 时得到同样参数。

调用关系：测试框架运行；它覆盖 plugin/uninstall 参数兼容。

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

fn marketplace_remove_response_serializes_nullable_installed_root()

作用：确认移除插件市场的响应里 installedRoot 可以是路径，也可以是 null。

数据流：构造 installed_root 为 Some 和 None 的响应 → 分别转 JSON → 检查路径字符串或 null。

调用关系：测试框架运行；它覆盖 marketplace/remove 响应格式。

调用图：调用 1 个内部函数（try_from）；外部调用 3 个（from, assert_eq!, cfg!）。

fn marketplace_upgrade_response_serializes_camel_case_fields()

作用：确认插件市场升级响应的 selectedMarketplaces、upgradedRoots、errors 都用 camelCase。

数据流：构造升级成功市场、升级路径和错误列表 → 转 JSON → 检查字段名和值。

调用关系：测试框架运行；它覆盖 marketplace/upgrade 响应输出。

调用图：调用 1 个内部函数（try_from）；外部调用 3 个（from, assert_eq!, cfg!）。

fn codex_error_info_serializes_http_status_code_in_camel_case()

作用：确认错误信息里的 HTTP 状态码字段写成 httpStatusCode。

数据流：构造 ResponseTooManyFailedAttempts 且状态码为 401 → 转 JSON → 检查嵌套字段名。

调用关系：测试框架运行；它覆盖 CodexErrorInfo 的一个带参数错误形状。

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

fn codex_error_info_serializes_cyber_policy_in_camel_case()

作用：确认 CyberPolicy 错误会写成 cyberPolicy 字符串。

数据流：输入 CodexErrorInfo::CyberPolicy → 转 JSON → 输出 "cyberPolicy"。

调用关系：测试框架运行；它覆盖 CodexErrorInfo 的简单字符串错误形状。

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

fn codex_error_info_serializes_active_turn_not_steerable_turn_kind_in_camel_case()

作用：确认“当前回合不可操控”错误里的 turnKind 字段使用 camelCase。

数据流：构造 ActiveTurnNotSteerable 且 turn_kind 为 Review → 转 JSON → 输出 turnKind:"review"。

调用关系：测试框架运行；它覆盖 CodexErrorInfo 的另一种嵌套错误形状。

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

fn dynamic_tool_response_serializes_content_items()

作用：确认动态工具响应能输出文本内容项。

数据流：构造一个 InputText 内容项和 success:true → 转 JSON → 得到 contentItems 数组。

调用关系：测试框架运行；它覆盖 DynamicToolCallResponse 的基础输出。

调用图：外部调用 3 个（assert_eq!, to_value, vec!）。

fn dynamic_tool_response_serializes_text_and_image_content_items()

作用：确认动态工具响应能同时输出文本和图片内容项。

数据流：构造 InputText 和 InputImage 两项 → 转 JSON → 文本用 text，图片用 imageUrl。

调用关系：测试框架运行；它扩展检查动态工具输出的多媒体格式。

调用图：外部调用 3 个（assert_eq!, to_value, vec!）。

fn thread_start_params_preserve_explicit_null_service_tier()

作用：确认 thread/start 里 serviceTier 显式写 null 时会被保留下来，而不是当成没写。

数据流：输入 serviceTier:null → 读成 Some(None) → 再序列化仍有 serviceTier:null；默认参数则不输出该字段。

调用关系：测试框架运行；它验证双层 Option 表示“没写”和“写了 null”的区别。

调用图：外部调用 5 个（default, assert_eq!, json!, from_value, to_value）。

fn thread_lifecycle_responses_default_missing_optional_fields()

作用：确认线程启动、恢复、分叉响应缺少一些新增可选字段时，会自动补默认值。

数据流：输入一份少了 instructionSources、parentThreadId、activePermissionProfile 等字段的响应 JSON → 分别读成三种响应 → 检查默认值。

调用关系：测试框架运行；它保证旧服务端响应仍能被新类型读懂。

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

fn turn_start_params_preserve_explicit_null_service_tier()

作用：确认 turn/start 里 serviceTier:null 会被保留，而省略字段则不输出。

数据流：输入带 serviceTier:null 的 JSON → 读成 Some(None) → 序列化保留 null；手工构造 None 时不输出。

调用关系：测试框架运行；它和 thread_start 的同类测试保持行为一致。

调用图：外部调用 5 个（assert_eq!, json!, from_value, to_value, vec!）。

fn thread_settings_update_params_preserve_explicit_null_service_tier()

作用：确认更新线程设置时，serviceTier 显式 null 和没写能区分。

数据流：输入 serviceTier:null → 读成 Some(None) 并写回 null；默认 None 则序列化时没有 serviceTier。

调用关系：测试框架运行；它覆盖 thread/settings/update 参数的三态字段。

调用图：外部调用 5 个（default, assert_eq!, json!, from_value, to_value）。

fn thread_settings_update_params_preserve_field_level_experimental_gates()

作用：确认线程设置更新里的实验字段会各自触发正确的实验功能标记。

数据流：分别构造 permissions、granular approval、collaborationMode 三种更新参数 → 调 experimental_reason → 得到对应原因。

调用关系：测试框架运行；它验证字段级实验门禁，不只是整个请求级别。

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

fn turn_start_params_round_trip_environments()

作用：确认 turn/start 可以携带 environments 环境列表，并且这个字段被标为实验功能。

数据流：输入带 environmentId 和 cwd 的 JSON → 读成 TurnStartParams → experimental_reason 返回 turn/start.environments → 再序列化保留列表。

调用关系：测试框架运行；它覆盖多环境回合启动参数，并特意使用异平台路径字符串测试语法保留。

调用图：外部调用 4 个（assert_eq!, json!, from_value, to_value）。

fn turn_start_params_preserve_empty_environments()

作用：确认 environments 写成空数组时会被保留，而不是当成没写。

数据流：输入 environments:[] → 读成 Some(Vec::new()) → 实验标记存在 → 再序列化仍是空数组。

调用关系：测试框架运行；它补充检查 environments 字段的空列表语义。

调用图：外部调用 4 个（assert_eq!, json!, from_value, to_value）。

fn turn_start_params_treat_null_or_omitted_environments_as_default()

作用：确认 environments 为 null 或省略时，都按默认没有环境处理，也不触发实验标记。

数据流：分别输入 environments:null 和缺少 environments 的 JSON → 读成 TurnStartParams → environments 都是 None，experimental_reason 为 None。

调用关系：测试框架运行；它和前两个 environments 测试一起区分空数组、null、省略三种情况。

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

fn realtime_append_text_defaults_role_to_user()

作用：确认实时追加文本请求没写 role 时，默认角色是用户。

数据流：输入 threadId 和 text 的 JSON → 读成 ThreadRealtimeAppendTextParams → role 自动为 ConversationTextRole::User。

调用关系：测试框架运行；它覆盖 realtime append text 请求的默认角色。

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

fn typescript_schema_fixtures_match_generated() -> Result<()>

作用：这是 TypeScript schema 的测试入口。它确认仓库里保存的 TypeScript 接口说明文件，和当前代码现场生成出来的一模一样。

数据流：进去时没有外部参数；它先通过 schema_root 找到 schema 文件所在的根目录，再用 read_tree 读取已保存的 typescript 文件树；接着调用生成函数在内存里生成新的 TypeScript schema 文件树；最后把旧的和新的交给 assert_schema_trees_match 比较。比较通过就返回成功；如果不同，测试会失败并显示差异。

调用关系：测试框架运行测试时会直接调用它。它自己不做细节比较，而是把“找目录”交给 schema_root，把“读文件树”交给 read_tree，把“生成新文件树”交给外部生成函数，最后把“判定是否一致”交给 assert_schema_trees_match。

调用图：调用 3 个内部函数（assert_schema_trees_match, read_tree, schema_root）；外部调用 1 个（generate_typescript_schema_fixture_subtree_for_tests）。

fn json_schema_fixtures_match_generated() -> Result<()>

作用：这是 JSON schema 的测试入口。它确认仓库里保存的 JSON 接口说明文件，和当前代码重新生成出来的结果一致。

数据流：进去时没有外部参数；它把标签 json 和一个“如何生成 JSON schema”的小函数交给 assert_schema_fixtures_match_generated。后者会读取旧文件、生成新文件、比较两边。这个函数本身只负责启动 JSON 版本的通用检查流程。

调用关系：测试框架运行测试时会直接调用它。它复用 assert_schema_fixtures_match_generated，因为 JSON schema 需要先生成到临时目录再读取，和 TypeScript 的内存生成方式不完全一样。

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

fn assert_schema_fixtures_match_generated(
    label: &'static str,
    generate: impl FnOnce(&Path) -> Result<()>,
) -> Result<()>

作用：这是“读取旧 schema、生成新 schema、比较两者”的通用流程。JSON 测试用它来避免把同一套步骤重复写一遍。

数据流：输入是一个标签，比如 json，以及一个生成函数；它先找 schema 根目录，再读出这个标签对应的已保存文件树；然后创建一个临时目录，让生成函数把新 schema 写进去；再从临时目录把新生成的文件树读回来；最后调用 assert_schema_trees_match 比较两棵文件树。成功时返回成功；任何一步失败都会带上更清楚的错误说明。

调用关系：它由 json_schema_fixtures_match_generated 调用，是 JSON schema 测试的主干流程。它把路径查找交给 schema_root，把文件读取交给 read_tree，把最终比较交给 assert_schema_trees_match，自己负责把这些步骤串起来。

调用图：调用 3 个内部函数（assert_schema_trees_match, read_tree, schema_root）；被 1 处调用（json_schema_fixtures_match_generated）；外部调用 1 个（tempdir）。

fn assert_schema_trees_match(
    label: &str,
    fixture_tree: &BTreeMap<PathBuf, Vec<u8>>,
    generated_tree: &BTreeMap<PathBuf, Vec<u8>>,
) -> Result<()>

作用：这个函数负责真正判断两份 schema 文件树是不是完全一样。它不仅看文件内容，也先看文件名列表，避免少文件、多文件这类问题被漏掉。

数据流：输入是一个标签，以及两棵文件树：一棵是仓库里保存的 fixture，一棵是刚生成的结果。它先把两边的路径列表排出来比较；如果文件集合不同，就生成一份差异对照并让测试失败。文件集合相同后，它再逐个文件比较字节内容；发现内容不同，也会把内容差异做成 diff 并让测试失败。全部一致才返回成功。

调用关系：它被 TypeScript 测试和通用 JSON 测试流程共同调用，是最后的“验货员”。前面的函数负责准备两份货，它负责开箱检查，并在不合格时给出开发者能直接看懂的差异和修复提示。

调用图：被 2 处调用（assert_schema_fixtures_match_generated, typescript_schema_fixtures_match_generated）；外部调用 3 个（from_utf8_lossy, from_lines, panic!）。

fn schema_root() -> Result<PathBuf>

作用：这个函数负责找到 schema fixture 所在的根目录。它不靠硬编码路径，而是先定位几个已知文件，再反推出根目录，这样在不同测试环境里更稳。

数据流：进去时没有参数；它先用资源查找工具找到 schema/typescript/index.ts，从这个文件的位置往上走两层得到 schema 根目录；再找到 JSON schema 的已知文件，也往上走两层得到另一个根目录；然后确认这两个根目录必须相同。最后输出这个可靠的 schema 根路径；如果找不到文件或两个根目录不一致，就返回错误。

调用关系：它被 TypeScript 测试和 JSON 通用检查流程调用，是整个测试的第一步。后面的 read_tree 需要它给出的目录，才能知道该从哪里读取已提交的 schema fixture。

调用图：被 2 处调用（assert_schema_fixtures_match_generated, typescript_schema_fixtures_match_generated）；外部调用 2 个（ensure!, find_resource!）。

fn read_tree(root: &Path, label: &str) -> Result<BTreeMap<PathBuf, Vec<u8>>>

作用：这个函数把某个 schema 子目录读成一棵“文件路径到文件内容”的树。这样后面比较时，就不用关心真实磁盘上的目录细节，只看整理好的文件清单和内容。

数据流：输入是根目录路径和标签，比如 typescript 或 json；它调用底层读取函数，从对应子目录里收集所有 schema fixture 文件；输出是一个有序映射，里面每一项都是相对路径和该文件的原始字节内容。如果读取失败，它会补上一句说明，告诉人是从哪个目录读哪个标签时出了问题。

调用关系：它被 TypeScript 测试和 JSON 通用检查流程调用。它负责把磁盘上的 fixture 变成 assert_schema_trees_match 能比较的数据结构，是“读文件”和“比较文件”之间的转换层。

调用图：被 2 处调用（assert_schema_fixtures_match_generated, typescript_schema_fixtures_match_generated）；外部调用 1 个（read_schema_fixture_subtree）。