配置、策略和环境测试

fn enterprise_requirement(contents: impl Into<String>) -> Self

作用：快速做出一个只包含一条企业要求的测试夹具。测试想模拟“企业下发了一条要求”时，可以直接用它，不用自己一步步搭结构。

数据流：输入是一段文字内容 → 它先从一个默认的空 CloudConfigBundleFixture 开始 → 再把这段内容作为企业要求加进去 → 输出一个已经带有这条要求的 CloudConfigBundleFixture。

调用关系：它是 add_enterprise_requirement 的便捷入口。测试 adds_enterprise_requirements_in_order 会用它来从第一条企业要求开始搭测试数据；内部先调用默认构造，再把真正添加要求的活儿交给 add_enterprise_requirement。

调用图：被 1 处调用（adds_enterprise_requirements_in_order）；外部调用 1 个（default）。

fn enterprise_config(contents: impl Into<String>) -> Self

作用：快速做出一个只包含一条企业配置的测试夹具。测试想模拟“企业下发了一段配置”时，可以直接调用它。

数据流：输入是一段配置文字 → 它创建一个默认的空夹具 → 把这段文字作为企业配置片段放进去 → 输出一个带有这条配置的 CloudConfigBundleFixture。

调用关系：它是 add_enterprise_config 的便捷入口。别的代码不用关心内部配置包怎么摆放，只要给内容；这个函数负责从空包起步，并把添加配置的细节交给 add_enterprise_config。

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

fn loader_with_enterprise_requirement(
        contents: impl Into<String>,
    ) -> CloudConfigBundleLoader

作用：快速做出一个假的云配置加载器，里面预装了一条企业要求。很多测试用它来模拟“加载配置时，从云端拿到了企业要求”。

数据流：输入是一段企业要求内容 → 它先做出带这条要求的 CloudConfigBundleFixture → 再把这个夹具转换成 CloudConfigBundleLoader → 输出一个测试用加载器；之后别人调用加载器时，会拿到这份假的配置包。

调用关系：它把 enterprise_requirement 和 into_loader 串起来，是很多配置加载测试的常用入口。调用它的测试包括检查冲突拒绝、云配置是否插入、企业要求优先级、是否忽略托管要求等场景；它让这些测试专注于结果，而不是搭建假云端数据。

调用图：被 36 处调用（write_value_rejects_feature_requirement_conflict, load_config_layers_applies_matching_remote_sandbox_config, load_config_layers_can_ignore_managed_requirements, load_config_layers_includes_cloud_config_bundle, load_config_layers_includes_cloud_hook_requirements, load_config_layers_resolves_relative_bundle_requirements_paths_against_codex_home, mdm_requirements_take_precedence_over_cloud_config_bundle, active_profile_is_cleared_when_requirements_force_fallback, approvals_reviewer_preserves_valid_user_choice_when_allowed_by_requirements, browser_feature_requirements_are_valid (+15 more)）；外部调用 1 个（enterprise_requirement）。

fn loader_with_enterprise_config(contents: impl Into<String>) -> CloudConfigBundleLoader

作用：快速做出一个假的云配置加载器，里面预装了一条企业配置。测试可以用它检查系统拿到企业配置后会不会正确合并、校验或拒绝。

数据流：输入是一段企业配置内容 → 它先做出带这条配置的 CloudConfigBundleFixture → 再转换成 CloudConfigBundleLoader → 输出一个会返回该配置包的测试加载器。

调用关系：它把 enterprise_config 和 into_loader 组合成一步。配置分层相关测试会调用它，比如检查云配置是否插在系统配置和用户配置之间，或者严格配置模式是否拒绝未知的云配置键。

调用图：被 2 处调用（load_config_layers_inserts_cloud_config_between_system_and_user, strict_config_rejects_unknown_cloud_config_key）；外部调用 1 个（enterprise_config）。

fn add_enterprise_requirement(mut self, contents: impl Into<String>) -> Self

作用：往现有测试夹具里再加一条企业要求。它适合用来连续添加多条要求，并自动保持编号和名字有顺序。

数据流：输入是已有的 CloudConfigBundleFixture 和一段要求内容 → 它查看当前已经有几条企业要求，算出下一条编号 → 生成类似 req_1、req_2 的 id，以及 Base requirements 或 Requirements 2 这样的名字 → 把新片段塞进 bundle.requirements_toml.enterprise_managed → 输出更新后的夹具。

调用关系：它是企业要求测试数据真正落到配置包里的地方。enterprise_requirement 会调用它来添加第一条；测试也可以链式调用它来添加多条，从而检查系统是否按顺序处理这些要求。

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

fn add_enterprise_config(mut self, contents: impl Into<String>) -> Self

作用：往现有测试夹具里再加一条企业配置。它让测试可以很方便地构造一组按顺序排列的企业配置片段。

数据流：输入是已有的 CloudConfigBundleFixture 和一段配置内容 → 它数一数当前已有多少条企业配置，得到下一条编号 → 生成类似 cfg_1、cfg_2 的 id，以及 Base config 或 Config 2 这样的名字 → 把新片段放进 bundle.config_toml.enterprise_managed → 输出更新后的夹具。

调用关系：它是企业配置片段真正被加入配置包的函数。enterprise_config 会通过它添加第一条配置；需要多条配置的测试也可以反复调用它，构造更复杂的云端配置样本。

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

fn into_bundle(self) -> CloudConfigBundle

作用：把测试夹具拆开，取出里面真正的 CloudConfigBundle。测试如果只需要配置包本身，而不需要加载器，就会用这一步。

数据流：输入是一个 CloudConfigBundleFixture → 它取出内部保存的 bundle → 输出 CloudConfigBundle；原来的夹具被消耗掉，不能再继续用。

调用关系：它是从“制作器”到“成品配置包”的出口。into_loader 会先调用它拿到配置包，再把配置包包装成一个测试用加载器。

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

fn into_loader(self) -> CloudConfigBundleLoader

作用：把测试夹具变成一个假的 CloudConfigBundleLoader。这个加载器不会真的去网络或云端取东西，而是固定返回夹具里的配置包。

数据流：输入是一个 CloudConfigBundleFixture → 它先通过 into_bundle 取出 CloudConfigBundle → 再创建一个异步返回结果的加载器：被调用时返回 Ok(Some(bundle)) → 输出 CloudConfigBundleLoader。

调用关系：它是测试接入正式配置加载流程的桥。loader_with_enterprise_requirement 和 loader_with_enterprise_config 最终都会走到这里；它再调用 CloudConfigBundleLoader::new，把假数据包装成系统平时期待的加载器形状。

调用图：调用 2 个内部函数（new, into_bundle）。

fn adds_enterprise_requirements_in_order()

作用：这个测试函数确认：用测试夹具创建和追加企业要求时，生成出来的要求列表会保持添加顺序，并且自动生成的编号和名称符合预期。有人修改测试辅助代码后，跑这个测试就能发现是否破坏了这个约定。

数据流：进入时没有外部输入；它先调用 enterprise_requirement，用字符串“first”做出一份基础配置，再追加字符串“second”作为第二条要求，然后转成 bundle。最后它读取 bundle.requirements_toml.enterprise_managed，把实际生成的列表和手写的期望列表比较；如果完全一样，测试通过；如果顺序、编号、名称或内容有任何不同，测试失败。

调用关系：这个函数由 Rust 的测试运行器在执行测试时自动调用。它把创建测试配置的工作交给 enterprise_requirement 和后续链式方法完成，再用 assert_eq! 这个断言工具做最终核对；它本身就是一道保险，确保配置测试工具生成的数据稳定可靠。

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

async fn shared_future_runs_once()

作用：这个测试确认共享的云配置加载任务即使被同时请求两次，也只真正执行一次。这样可以避免两个地方同时要配置时，程序重复去加载同一份东西。

数据流：测试先准备一个计数器，加载动作每执行一次就把计数器加一；然后创建一个 CloudConfigBundleLoader，并用 tokio::join! 同时调用两次 get；最后检查两次拿到的结果一样，而且计数器只变成 1。也就是说，进去的是两个并发请求，经过共享加载器合并后，出来的是同一份结果，底层加载只发生一次。

调用关系：它直接测试 CloudConfigBundleLoader::new 创建出来的加载器行为。测试里两个 get 调用同时发生，用来模拟真实运行中多个地方一起等待云配置的情况；如果共享机制坏了，这个测试会通过计数器立刻发现。

调用图：调用 1 个内部函数（new）；外部调用 6 个（clone, new, new, assert_eq!, default, join!）。

fn bundle_layers_preserve_enterprise_managed_bucket_order()

作用：这个测试确认企业管理的云端配置片段转换成本地配置层时，优先级顺序是对的。顺序很重要，因为后面的规则可能覆盖前面的规则，弄反了就可能让低优先级配置压过高优先级配置。

数据流：测试先创建一个临时目录，作为配置转换时需要的基础路径；再手写一个云端配置包，里面有两段配置和两段要求，名字分别代表高优先级和低优先级；然后调用 CloudConfigBundleLayers::from_bundle 把云端包变成本地层；最后检查配置层的排列顺序，以及要求合并后的结果。最终期望是配置层按正确顺序保存，而要求合并后只允许 on-request 这种审批策略。

调用关系：它主要覆盖 CloudConfigBundleLayers::from_bundle 的转换行为，并进一步用 compose_requirements 检查要求文件合并后的效果。这个测试站在“云配置进入本地配置系统”的入口处，确认转换和合并这两个环节能配合正确。

调用图：调用 2 个内部函数（from_bundle, from_absolute_path）；外部调用 3 个（assert_eq!, tempdir, vec!）。

fn bundle_layers_can_strict_validate_enterprise_managed_config()

作用：这个测试确认严格模式会拒绝云端配置里的未知字段。这样配置写错时会直接暴露问题，而不是让错误配置悄悄被忽略。

数据流：测试先创建临时目录和基础路径；再构造一个云端配置包，其中配置内容故意写入 unknown_key = true 这个程序不认识的字段；接着调用 CloudConfigBundleLayers::from_bundle_strict_config 做严格转换；最后确认它没有成功，而是返回一个明确错误，错误里包含是哪段配置出错，以及提示 unknown_key 是未知配置字段。

调用关系：它专门测试 CloudConfigBundleLayers::from_bundle_strict_config 这条更严格的转换路径。和普通转换相比，这个测试关心的是校验失败时错误是否准确，方便上层在加载企业配置时给出清楚的诊断信息。

调用图：调用 2 个内部函数（from_bundle_strict_config, from_absolute_path）；外部调用 4 个（new, assert_eq!, tempdir, vec!）。

fn fragment(id: &str, name: &str, contents: &str) -> CloudConfigFragment

作用：这个小工具用来快速造一个“云端配置片段”。测试里不用每次手写完整结构，只要给编号、名字和配置文本就行。

数据流：输入一个片段编号、一个人能看懂的名字、一段配置文本 → 它把这三样东西分别转成字符串，塞进 CloudConfigFragment 这个测试用数据包里 → 输出一个可以交给配置转换函数使用的云端配置片段，不改动别的东西。

调用关系：它是这些测试的造数据帮手。各个测试先用它拼出不同的云端配置场景，再把结果交给 cloud_config_layers_from_fragments 或严格版本去验证后续行为。

fn toml(contents: &str) -> TomlValue

作用：这个小工具把一段 TOML 配置文字变成程序里可比较的配置值。测试要比较最终配置时，用它来写出期望结果。

数据流：输入一段 TOML 字符串 → 它调用 toml::from_str 解析文本，如果测试里写的 TOML 本身不合法就直接失败 → 输出一个 TomlValue，也就是程序内部表示的配置值。

调用关系：它被 enterprise_layers_precede_user_and_override_system 使用。那个测试需要同时造系统配置、用户配置和最终期望配置，所以把文字形式的 TOML 先交给这个函数转换，之后再用 assert_eq! 比较。

调用图：被 1 处调用（enterprise_layers_precede_user_and_override_system）；外部调用 1 个（from_str）。

fn base_dir() -> AbsolutePathBuf

作用：这个小工具提供一个固定的测试基础目录：/var/lib/codex。测试相对路径解析时，需要一个稳定的参照点。

数据流：它不接收外部输入 → 调用 test_path_buf 造出测试路径，再转成 AbsolutePathBuf，也就是程序认为已经是绝对路径的路径类型 → 输出这个固定基础目录。

调用关系：它被多个测试调用。凡是云端配置需要知道“相对路径从哪里算起”，或者只是要传入配置片段转换函数时，测试都会先向它要同一个基础目录，避免每个测试各写一份路径。

调用图：被 6 处调用（enterprise_layers_precede_user_and_override_system, home_relative_path_fields_are_allowed_and_resolved, layers_are_returned_in_stack_order, raw_toml_diagnostics_use_enterprise_layer_name, relative_absolute_path_fields_resolve_against_base_dir, strict_layers_reject_unknown_config_fields）；外部调用 1 个（test_path_buf）。

fn layers_are_returned_in_stack_order()

作用：这个测试确认云端配置片段变成配置层以后，返回顺序是配置栈真正使用的顺序，而不是简单照输入顺序来。这样后续合并配置时，谁先谁后才不会乱。

数据流：它先取得固定基础目录，再造两个云端片段：一个叫 high，一个叫 low → 把它们交给 cloud_config_layers_from_fragments 转成配置层 → 取出每层的来源名字来比较，确认结果顺序是 low 在前、high 在后。

调用关系：它使用 base_dir 准备路径参照，用 fragment 准备测试片段，最后用 assert_eq! 检查结果。它站在配置层生成流程的出口，专门盯住“层的顺序”这个容易出错的约定。

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

fn strict_layers_reject_unknown_config_fields()

作用：这个测试确认严格模式下，云端配置里出现不认识的字段会被拒绝，而不是被悄悄忽略。这样企业下发错配置时能尽早发现。

数据流：它先取得固定基础目录，再造一个包含 unknown_key 的云端片段 → 调用 cloud_config_layers_from_fragments_strict，期待它返回错误 → 把实际错误和预期错误比较，确认错误里带着片段编号、片段名字和清楚的提示信息。

调用关系：它使用 base_dir 和 fragment 准备输入，然后把输入交给严格版配置转换函数。这个测试保护的是“严格校验”这道门，防止未知配置项漏进系统。

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

fn enterprise_layers_precede_user_and_override_system()

作用：这个测试确认系统配置、企业云端配置、用户配置三者叠在一起时，优先级符合预期：企业配置能盖过系统配置，但用户配置还能盖过企业配置。没有这个保证，最终生效配置可能和管理员或用户想的不一样。

数据流：它先造一层系统配置，再追加两层云端企业配置，最后追加一层用户配置 → 用 ConfigLayerStack::new 建成配置栈 → 一方面检查层顺序是系统、企业 low、企业 high、用户；另一方面检查最终合并结果里 model 来自用户，model_provider 来自 high 企业层，review_model 来自 low 企业层。

调用关系：它使用 base_dir 提供云端配置的路径参照，使用 toml 把文字配置转成可比较的值，也使用 ConfigLayerEntry::new 和 ConfigLayerStack::new 搭出完整配置栈。它是本文件里最像真实运行场景的测试，把系统、企业、用户三类配置放在一起验收。

调用图：调用 4 个内部函数（base_dir, toml, new, new）；外部调用 5 个（default, assert_eq!, test_path_buf, default, vec!）。

fn relative_absolute_path_fields_resolve_against_base_dir()

作用：这个测试确认云端配置里的相对路径，比如 instructions.md，会按照云端配置的基础目录补成绝对路径。这样程序后面打开文件时，不会因为当前工作目录不同而找错地方。

数据流：它取得固定基础目录，再造一个包含 model_instructions_file = "instructions.md" 的云端片段 → 转成配置层后，从结果里取出这个路径字段 → 用 resolve_path_against_base 算出预期路径，并和实际路径比较。

调用关系：它使用 base_dir 和 fragment 准备场景，把片段交给 cloud_config_layers_from_fragments，再借助 AbsolutePathBuf::resolve_path_against_base 得到标准答案。它专门守住路径解析规则，保证相对路径不是随便按运行位置解释。

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

fn home_relative_path_fields_are_allowed_and_resolved()

作用：这个测试确认以 ~/ 开头的路径也能被云端配置接受并解析。~/ 通常表示“用户家目录”风格的路径，测试确保这种写法不会被误判为非法。

数据流：它取得固定基础目录，再造一个包含 model_instructions_file = "~/instructions.md" 的云端片段 → 转成配置层后，读取解析后的路径字符串 → 用 resolve_path_against_base 按同样规则算出期望值，再比较两者是否一致。

调用关系：它和 relative_absolute_path_fields_resolve_against_base_dir 很像，但专门覆盖 ~/ 这种路径写法。它使用 base_dir 准备参照点，并验证云端配置转换函数对家目录相对路径的行为。

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

async fn raw_toml_diagnostics_use_enterprise_layer_name()

作用：这个异步测试确认当云端配置的原始 TOML 内容有类型错误时，报错信息会指向“企业管理配置”的名字和编号，而不是显示一个含糊的文件名。这样用户或管理员才能知道是哪条云端策略出问题。

数据流：它先造一个云端片段，里面有一个路径字段和一个错误的 model = 1，因为 model 应该不是整数 → 片段先能被转成配置层，然后交给 first_layer_config_error_from_entries 做更深的配置解析诊断 → 输出一个错误诊断，测试检查它的路径名、行号、列号和错误文字都符合预期。

调用关系：它使用 base_dir 准备基础目录，先通过 cloud_config_layers_from_fragments 得到配置层，再把这些层交给 first_layer_config_error_from_entries。这个测试站在错误报告流程上，确保底层解析错误最终能用企业配置的可读名称呈现出来。

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

fn layer(id: &str, name: &str, contents: &str) -> RequirementsLayerEntry

作用：把测试里写的一小段 TOML 配置，包装成一个带来源信息的配置层。这样测试不用每次都手写完整结构，只要给一个编号、名字和内容就行。

数据流：输入是配置层的 id、显示名称和 TOML 文本；它把 id 和名称做成企业管理来源，再调用 from_toml 解析内容；输出是一个 RequirementsLayerEntry，后面的合并测试会把它当作一层配置使用。

调用关系：这是很多测试的准备工具。测试函数先用它造出低优先级层和高优先级层，再交给 compose 或底层合并函数检查结果。

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

fn compose(
    layers: Vec<RequirementsLayerEntry>,
) -> Result<Option<ConfigRequirementsToml>, RequirementsCompositionError>

作用：这是测试用的简化合并入口。它把多层配置交给真正的合并逻辑，并把带来源信息的结果转成普通 TOML 结果，方便做相等比较。

数据流：输入是一组 RequirementsLayerEntry；它调用 compose_requirements_for_hostname，并且这里不指定主机名；如果合并成功，就把 ConfigRequirementsWithSources 转成 ConfigRequirementsToml；输出是可能为空的最终配置，或者合并错误。

调用关系：很多测试都通过它走默认合并路径，比如空层、普通 TOML 合并、网络映射、权限、解析错误等。它本身不决定规则，只是把测试数据送进真正的 compose_requirements_for_hostname。

调用图：被 10 处调用（deny_read_only_layers_do_not_leave_empty_permissions_tables, empty_layers_compose_to_none, mcp_requirements_use_regular_toml_merge, network_maps_use_regular_toml_merge, parse_error_names_layer, permissions_deny_read_unions_while_profiles_use_regular_toml_merge, regular_toml_merge_recurses_into_tables, rules_are_appended_in_priority_order, top_level_values_use_toml_priority, windows_requirements_use_regular_toml_merge）；外部调用 1 个（compose_requirements_for_hostname）。

fn compose_with_hook_directory_field(
    layers: Vec<RequirementsLayerEntry>,
    hook_directory_field: HookDirectoryField,
) -> Result<Option<ConfigRequirementsToml>, RequirementsCompositionError>

作用：这是专门测试钩子目录合并规则的辅助入口。钩子可以理解为“某些动作发生前后自动执行的小脚本”，这个函数允许测试指定当前平台要看哪个钩子目录字段。

数据流：输入是多层配置和一个 HookDirectoryField；它调用 compose_requirements_for_hostname_and_hook_directory，同样不指定主机名；成功后转成普通 TOML，失败就返回错误；输出是最终配置或冲突错误。

调用关系：钩子相关测试会调用它，尤其是检查 managed_dir 和 windows_managed_dir 哪个算“当前生效字段”。真正判断冲突的工作交给 compose_requirements_for_hostname_and_hook_directory。

调用图：被 3 处调用（active_windows_managed_dir_conflicts_fail_closed, hooks_append_groups_and_reject_conflicting_managed_dirs, inactive_hook_dir_conflicts_do_not_fail_composition）；外部调用 1 个（compose_requirements_for_hostname_and_hook_directory）。

fn expected_requirements(contents: impl AsRef<str>) -> ConfigRequirementsToml

作用：把测试里写的预期 TOML 文本解析成配置对象。这样断言时比较的是结构化配置，而不是容易受空格和顺序影响的纯文本。

数据流：输入是一段可转成字符串的 TOML；它读取字符串内容，用 toml::from_str 解析；输出是 ConfigRequirementsToml，如果预期文本本身写错就直接让测试失败。

调用关系：各个测试在 assert_eq! 前常用它生成“标准答案”。它不参与产品逻辑，只是让测试对比更可靠。

调用图：外部调用 2 个（as_ref, from_str）。

fn empty_layers_compose_to_none()

作用：确认没有任何配置层时，合并结果就是没有配置，而不是生成一个空壳配置。这样调用方能清楚地区分“真的没有要求”和“有一份空要求”。

数据流：输入是空的配置层列表；它通过 compose 合并；得到的结果应为 None；测试用 assert_eq! 验证这一点。

调用关系：这个测试走 compose 辅助函数，间接检查 compose_requirements_for_hostname 对空输入的处理。

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

fn top_level_values_use_toml_priority()

作用：确认顶层字段冲突时，高优先级配置会覆盖低优先级配置。同时也检查没有被高层覆盖的条目能保留下来。

数据流：输入是低、高两层配置，里面都有审批策略、沙箱模式、默认权限、远程控制开关和权限档案；合并后，高层字段取胜，低层独有的只读档案仍保留；输出结果和预期 TOML 做比较。

调用关系：它调用 compose 来走默认合并流程，再用 expected_requirements 给出标准答案，验证普通字段的优先级规则。

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

fn composition_strategy_applies_to_non_cloud_layers()

作用：确认同一套合并策略不只适用于企业云下发的配置，也适用于系统文件、MDM 等本地管理来源。MDM 可以理解为公司设备管理系统下发的设置。

数据流：输入是系统配置层和 MDM 配置层；系统层给一些低优先级规则，MDM 层给高优先级规则；合并后，高层普通字段覆盖低层，功能表递归合并，规则按优先级排列，deny_read 路径合并成并集；同时检查字段来源记录来自正确来源。

调用关系：这个测试直接调用 compose_requirements_for_hostname，因为它还要检查带来源的结果，而不是只看普通 TOML。它也用 from_absolute_path 构造系统文件来源。

调用图：调用 1 个内部函数（from_absolute_path）；外部调用 4 个（assert_eq!, cfg!, compose_requirements_for_hostname, vec!）。

fn single_regular_layer_keeps_enterprise_managed_source()

作用：确认只有一层企业管理配置时，合并结果仍然记得这条设置来自哪一个企业策略。这个来源信息对报错、审计和解释配置很重要。

数据流：输入是一层包含 allow_managed_hooks_only 的企业配置；合并后得到带来源的配置；测试检查这个字段的值是 true，并且来源里的 id 和名称没有丢。

调用关系：它直接调用 compose_requirements_for_hostname，以便检查 Sourced 这种“值加来源”的结果。

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

fn regular_toml_merge_recurses_into_tables()

作用：确认普通 TOML 表格会一层层往里合并，而不是遇到高层表格就把低层整个表格丢掉。这样低层里没冲突的子配置还能继续生效。

数据流：输入是两层 features 和 apps 配置；高层改 shared、connector enabled 和 search 工具，低层提供 beta 和 list 工具；合并后既有高层覆盖项，也有低层保留项；输出和预期结构比较。

调用关系：它通过 compose 调用默认合并逻辑，用来守住“递归合并表格”这条基础规则。

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

fn merged_table_source_is_composite_in_priority_order()

作用：确认一个表格由多层共同合成时，来源信息会记录成组合来源，并且顺序体现优先级。这样以后解释配置时能说清楚它是由哪些策略拼出来的。

数据流：输入是高、低两层各自给 features 表的一部分；合并后 features 里同时有 alpha 和 beta；来源不是单一来源，而是按高优先级到低优先级组合起来的来源。

调用关系：它直接调用 compose_requirements_for_hostname，因为需要看带来源的 feature_requirements，而不是只看最终 TOML。

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

fn mcp_requirements_use_regular_toml_merge()

作用：确认 MCP 服务器配置也按普通 TOML 表格规则合并。MCP 是一种让程序连接外部工具或服务的协议，这里关注的是它的配置别被整块覆盖错。

数据流：输入是低层定义 low 服务器和 shared 服务器，高层改 shared 服务器的命令；合并后 low 服务器保留，shared 服务器采用高层命令；结果和预期比较。

调用关系：它调用 compose，借默认合并路径验证 mcp_servers 这类嵌套表没有特殊误处理。

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

fn network_maps_use_regular_toml_merge()

作用：确认网络域名和 Unix 套接字的允许/拒绝表会按普通映射规则合并。Unix 套接字可以理解为同一台机器上程序互相通信的本地“插口”。

数据流：输入是两层网络配置，部分键相同、部分键不同；相同键由高层覆盖，不同键都保留；输出包含合并后的域名规则和套接字规则。

调用关系：它通过 compose 检查 experimental_network 下的映射表，防止安全网络规则被错误丢弃。

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

fn windows_requirements_use_regular_toml_merge()

作用：确认 Windows 专用配置也按普通 TOML 合并规则走。这里检查允许使用哪种 Windows 沙箱实现时，高优先级值会覆盖低优先级值。

数据流：输入是低层允许 unelevated，高层允许 elevated；合并后 windows 表中的 allowed_sandbox_implementations 采用高层的 elevated；结果和预期比较。

调用关系：它调用 compose，覆盖 Windows 配置分支的基础合并行为。

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

fn remote_sandbox_config_is_applied_per_layer()

作用：确认远程沙箱配置会根据当前主机名逐层生效。沙箱就是限制程序能做什么的隔离环境，远程沙箱配置则允许不同机器用不同限制。

数据流：输入是低层默认只读沙箱，以及高层只对 build-*.example.com 生效的工作区写入沙箱；测试传入匹配的主机名 BUILD-01.EXAMPLE.COM.；合并后采用高层远程配置里的 workspace-write。

调用关系：它直接调用 compose_requirements_for_hostname，因为要传入指定主机名来测试主机名匹配逻辑。

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

fn unmatched_remote_sandbox_config_does_not_shadow_lower_layers()

作用：确认高优先级的远程沙箱配置如果主机名不匹配，不会挡住低优先级的普通配置。也就是说，不适用的规则不应该产生影响。

数据流：输入是低层 read-only，以及高层只匹配 mac-*.example.com 的远程配置；测试传入 linux-01.example.com；高层远程配置被跳过，最终保留低层 read-only。

调用关系：它直接调用 compose_requirements_for_hostname，用明确主机名验证“未匹配就不覆盖”的规则。

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

fn hostname_resolver_is_not_called_without_remote_sandbox_config()

作用：确认如果配置里根本没有远程沙箱选择规则，就不会去获取主机名。这样可以避免不必要的系统调用，也减少测试和运行时的不确定性。

数据流：输入是一层普通沙箱配置和一个会记录调用次数的主机名获取函数；合并时没有远程沙箱配置，所以获取函数不应被调用；输出仍是 read-only，调用次数是 0。

调用关系：它调用 compose_requirements_with_hostname_resolver，把一个计数闭包交进去，专门检查合并逻辑是否懒得刚刚好：需要时才问主机名。

调用图：外部调用 4 个（default, assert_eq!, compose_requirements_with_hostname_resolver, vec!）。

fn hostname_resolver_is_called_once_for_multiple_remote_sandbox_layers()

作用：确认即使多层配置都需要按主机名选择，也只获取一次主机名。这样避免重复工作，也保证所有层用的是同一个判断依据。

数据流：输入是两层都带远程沙箱规则的配置，以及一个计数的主机名获取函数；合并时主机名函数被调用一次，两个层都用这个结果匹配；最终高层 workspace-write 覆盖低层 read-only。

调用关系：它调用 compose_requirements_with_hostname_resolver，测试主机名解析在多层远程配置中的缓存或复用行为。

调用图：外部调用 4 个（default, assert_eq!, compose_requirements_with_hostname_resolver, vec!）。

fn rules_are_appended_in_priority_order()

作用：确认命令规则列表不是简单覆盖，而是按优先级顺序追加。这样高优先级规则会先被看到，低优先级规则仍作为后备存在。

数据流：输入是低层 npm 规则和高层 git 规则；合并后列表中 git 规则排在前面，npm 规则排在后面；输出和预期 TOML 比较。

调用关系：它通过 compose 验证 rules.prefix_rules 的特殊合并策略，不同于普通字段覆盖。

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

fn hooks_append_groups_and_reject_conflicting_managed_dirs()

作用：确认钩子分组会按优先级追加，同时同一个生效的托管钩子目录如果冲突就必须失败。失败是更安全的做法，叫“fail closed”，意思是不确定时宁可拒绝也不放行。

数据流：第一部分输入两层使用相同 managed_dir、不同钩子组的配置；合并后目录保留，钩子组高层在前低层在后。第二部分输入两个不同 managed_dir；合并返回错误，错误信息应指出字段名和两个冲突来源。

调用关系：它调用 compose_with_hook_directory_field，并指定 ManagedDir 是当前要检查的目录字段，用来验证钩子合并和冲突报错。

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

fn active_windows_managed_dir_conflicts_fail_closed()

作用：确认 Windows 平台生效的钩子目录字段如果冲突，也会直接合并失败。这避免程序在两个不同托管目录之间猜测，造成安全漏洞。

数据流：输入是两层 windows_managed_dir 不同的钩子配置，并指定当前检查 WindowsManagedDir；合并结果应为错误；测试检查错误文字包含字段名和两个来源。

调用关系：它调用 compose_with_hook_directory_field，把焦点切到 WindowsManagedDir，补上 Windows 钩子目录冲突场景。

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

fn inactive_hook_dir_conflicts_do_not_fail_composition()

作用：确认不是当前生效的钩子目录字段即使冲突，也不会让合并失败。换句话说，只对当前平台真正会用到的目录做严格冲突检查。

数据流：第一组输入 managed_dir 相同但 windows_managed_dir 不同，并指定检查 ManagedDir，合并成功；第二组输入 windows_managed_dir 相同但 managed_dir 不同，并指定检查 WindowsManagedDir，也成功；两次结果都保留高层目录值并追加钩子组。

调用关系：它两次调用 compose_with_hook_directory_field，分别模拟非 Windows 和 Windows 关注的目录字段，确保只检查活跃字段的冲突。

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

fn permissions_deny_read_unions_while_profiles_use_regular_toml_merge()

作用：确认文件系统的 deny_read 列表会取并集，而权限档案表仍按普通 TOML 规则合并。deny_read 是“禁止读取这些路径”，安全上不能因为高层少写一个路径就把低层禁令取消。

数据流：输入是低层禁止两个路径并定义权限档案，高层禁止其中一个路径并修改档案描述；合并后 deny_read 保留两个路径，档案 description 用高层值，extends 保留低层值；输出和预期比较。

调用关系：它调用 compose，专门覆盖权限合并中“列表取并集”和“表格递归合并”同时存在的情况。

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

fn deny_read_only_layers_do_not_leave_empty_permissions_tables()

作用：确认只有 deny_read 的配置不会额外留下空的权限表。这样最终配置干净，不会出现让人误解的空结构。

数据流：输入是一层只包含 permissions.filesystem.deny_read 的配置；合并后输出也只包含这个禁止读取路径；测试确认没有多余空表被生成。

调用关系：它通过 compose 检查权限合并后的清理行为，避免特殊处理 deny_read 时留下无用配置。

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

fn parse_error_names_layer()

作用：确认某一层 TOML 内容写错时，错误信息会点名是哪一层出问题。这样管理员排查配置时不用在多层策略里盲找。

数据流：输入是一层故意写错类型的配置，比如审批策略数组里放了数字；compose 尝试解析并失败；测试检查错误文字包含层名称、层 id 和出错字段名。

调用关系：它调用 compose 触发解析路径，验证 from_toml 或后续解析错误会被包装成带来源的可读错误。

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

fn deserialize_skill_config_with_name_selector()

作用：这个测试确认：当技能配置里写的是技能名字时，程序能正确读出这个名字，并且不会误以为用户提供了路径。它还检查 enabled=false 这种开关值会被正确保留下来。

数据流：进去的是一段 TOML 文本，里面有 name = "github:yeet" 和 enabled = false。测试用 toml::from_str 把文本转换成 SkillConfig，然后检查转换后的结果：name 是指定的字符串，path 是空的，enabled 是 false。出来的不是给业务代码用的结果，而是测试通过或失败；如果读错字段，断言就会失败。

调用关系：它是测试框架在跑单元测试时调用的独立检查项。它把解析工作交给外部的 toml::from_str，再用 assert_eq! 和 assert! 对结果做核对，证明 SkillConfig 的“按名字选择技能”这条路是通的。

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

fn deserialize_skill_config_with_path_selector()

作用：这个测试确认：当技能配置里写的是本地文件路径时，程序能把它读成一个绝对路径，并且不会同时填入技能名字。它保证“按路径选择技能”的配置方式可用。

数据流：进去的是测试临时创建的目录位置，以及拼出来的 skills/demo/SKILL.md 路径。测试把这个路径塞进一段 TOML 文本，用 toml::from_str 转成 SkillConfig，然后和手工构造的期望配置比较：path 有值，name 是空的，enabled 是 false。它还通过 AbsolutePathBuf::from_absolute_path 表达“这里应该是绝对路径”的要求。

调用关系：它由测试框架运行，先借助 tempfile::tempdir 创建一个安全的临时目录，再用 format! 拼出配置文本，随后把解析交给 toml::from_str。最后用 assert_eq! 把实际结果和期望结果对齐，验证路径选择器没有被解析坏。

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

fn memories_config_clamps_count_limits_to_nonzero_values()

作用：这个测试确认：记忆配置里的某些数量上限不能被设置成 0。哪怕用户写了 0，程序也会自动改成 1，避免后续流程因为“允许处理 0 条”而卡住或失效。

数据流：进去的是一个 MemoriesToml 原始配置，其中 max_raw_memories_for_consolidation 和 max_rollouts_per_startup 都被故意设成 Some(0)。测试调用 MemoriesConfig::from，把原始配置转换成正式配置；转换后，这两个值应该都变成 1，其它字段保持默认值。出来的是一次比较结果：实际配置必须等于期望配置，否则测试失败。

调用关系：它在测试阶段直接检查 MemoriesToml 到 MemoriesConfig 的转换规则。它调用 from 执行真正的配置整理，再用 default(ext) 取得默认配置作为参照，最后通过 assert_eq! 确认“最小值保护”确实生效。

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

fn memories_config_clamps_rate_limit_remaining_threshold()

作用：这个测试确认：记忆配置里的剩余额度百分比会被限制在 0 到 100 之间。用户写 101 会变成 100，写 -1 会变成 0，避免出现不可能的百分比。

数据流：第一次进去的是 min_rate_limit_remaining_percent = Some(101) 的原始配置，转换成 MemoriesConfig 后应该得到 100。第二次进去的是 min_rate_limit_remaining_percent = Some(-1)，转换后应该得到 0。每次都会把转换结果和带默认值的期望配置比较；如果没有正确夹到范围内，测试就会失败。

调用关系：它由测试框架运行，专门盯住 MemoriesConfig::from 里的百分比清洗规则。它不自己实现清洗，只提供两个越界例子，把转换交给 from，再用 default(ext) 和 assert_eq! 检查结果，确保配置系统不会接受荒唐的百分比。

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

fn parse_toml(value: &str) -> TomlValue

作用：这是测试里用的小帮手，把一段 TOML 配置文字变成程序能比较和合并的数据。这样每个测试不用重复写解析代码。

数据流：进去的是一段配置文本 → 它调用 TOML 解析器把文字读成结构化的 TomlValue → 出来的是可供 merge_toml_values 合并、也可供 assert_eq! 比较的配置值；如果文字本身写错了，测试会直接失败。

调用关系：四个测试都会先用它准备基础配置、覆盖配置或期望结果。它把“人能读的配置文字”转换成“测试能操作的数据”，后面的测试函数再拿这些数据去调用合并逻辑并检查结果。

调用图：被 4 处调用（merge_toml_values_normalizes_legacy_key_from_base_layer, merge_toml_values_normalizes_legacy_key_from_overlay_layer, merge_toml_values_normalizes_permission_network_domains_before_overlaying, merge_toml_values_prefers_canonical_key_when_one_layer_has_both_names）；外部调用 1 个（from_str）。

fn merge_toml_values_normalizes_legacy_key_from_base_layer()

作用：这个测试确认：如果底层配置还在用旧配置名，而上层配置用了新配置名，合并后只留下新配置名，并且值是上层配置的值。

数据流：进去的是两层配置：base 里有旧名字 no_memories_if_mcp_or_web_search=false，overlay 里有新名字 disable_on_external_context=true → 测试调用 merge_toml_values 把 overlay 盖到 base 上 → 出来的 base 应该只剩 disable_on_external_context=true；随后它还把结果转成 ConfigToml，确认真实配置结构也能读出这个值。

调用关系：它用 parse_toml 准备输入和期望结果，然后检查 merge_toml_values 的行为。这个场景模拟老用户的旧配置作为底层配置、新配置作为覆盖层时，系统应该如何兼容。

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

fn merge_toml_values_normalizes_legacy_key_from_overlay_layer()

作用：这个测试确认：如果覆盖层配置还在用旧配置名，程序也会把它当成新配置名处理，并正确覆盖底层配置。

数据流：进去的是 base 中的新名字 disable_on_external_context=false，以及 overlay 中的旧名字 no_memories_if_mcp_or_web_search=true → 合并时旧名字先被归一成新名字，再覆盖 base → 出来的配置应该是 disable_on_external_context=true；最后同样转成 ConfigToml，确认正式配置读取也没问题。

调用关系：它依赖 parse_toml 构造两层配置，然后通过断言检查 merge_toml_values 的兼容逻辑。这个测试覆盖的是“用户把旧写法放在更高优先级配置里”的情况。

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

fn merge_toml_values_prefers_canonical_key_when_one_layer_has_both_names()

作用：这个测试确认：同一层配置里如果新旧两个名字同时出现，程序会优先采用标准的新名字，而不是被旧名字反过来覆盖。

数据流：进去的是一个空的 base，以及一个 overlay；overlay 的 memories 段里同时写了 disable_on_external_context=true 和旧名字 no_memories_if_mcp_or_web_search=false → 合并时程序清理旧名字，并保留标准名字的值 → 出来的结果只应有 disable_on_external_context=true。

调用关系：它先创建一个空 TOML 表作为 base，再用 parse_toml 准备带冲突键名的 overlay。它测试的是 merge_toml_values 在同一层内部遇到新旧名字冲突时的取舍规则。

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

fn merge_toml_values_normalizes_permission_network_domains_before_overlaying()

作用：这个测试确认：网络权限里的域名在合并前会统一成小写，所以同一个域名不会因为大小写不同而变成两条规则。

数据流：进去的是 base 中 example.com=deny，以及 overlay 中 EXAMPLE.COM=allow → 合并前域名键会被统一成 example.com → overlay 的 allow 覆盖 base 的 deny，最后结果只有 example.com=allow。

调用关系：它用 parse_toml 准备基础权限和覆盖权限，然后检查 merge_toml_values 是否先规范域名再覆盖。这个测试保护的是权限配置的安全和一致性，避免同一网站因为大小写不同出现两份互相打架的规则。

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

fn ignored_toml_field_errors_accept_non_file_source_names()

作用：这个测试确认：配置来源不一定是普通文件路径，也可以是像“com.openai.codex:...”这样的名字；即便如此，发现未知配置项时也要正常报错。这样可以支持从特殊渠道加载配置，比如内嵌文本或编码后的配置。

数据流：进去的是一个来源名字、一段 TOML 配置文本，以及把文本解析出来的 TOML 值；测试把这些交给“检查未知字段”的函数。函数发现 unknown_key 不是合法配置项后，返回一个配置错误；测试再拿这个错误和预期错误比较，确认路径名、行列范围、错误文字都对。

调用关系：它在测试阶段单独运行，重点盯住“非文件来源名”这个边角场景。最后通过 assert_eq! 做精确比较，确保报错结果没有偏差。

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

fn type_errors_take_precedence_over_ignored_fields()

作用：这个测试确认：如果配置里同时有“字段类型写错”和“多写了未知字段”，系统应该先报告类型错误。这样用户会先看到真正阻止配置被理解的关键问题。

数据流：进去的是一个假配置文件路径和一段配置文本，其中 model_context_window 本该是数字，却写成了字符串 wide，后面还多了 unknown_key。检查函数读取文本后先撞上类型错误，于是输出这个类型错误；测试用预期的 ConfigError 和实际结果比较，确认没有先报未知字段。

调用关系：它验证严格配置检查的错误优先级。函数里会构造预期错误对象，并用 assert_eq! 检查实际返回值，保证上层以后展示给用户的第一条错误是最有用的那条。

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

fn strict_config_rejects_unknown_feature_key()

作用：这个测试确认：在全局 features 功能开关区域里，不能写系统不认识的开关名。否则用户拼错一个功能名时，系统必须及时指出来。

数据流：进去的是路径和一段包含 [features] 的 TOML 文本，里面写了 foo = true。检查函数发现 features.foo 不是合法字段，就返回一个错误，位置指向 foo 这个键；测试把它和预期错误做完全一致的比较。

调用关系：它覆盖的是普通 features 区块的严格校验。测试通过 ConfigError::new 准备标准答案，再用 assert_eq! 确认配置检查函数真的拒绝未知功能键。

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

fn strict_config_rejects_unknown_profile_feature_key()

作用：这个测试确认：不仅全局功能开关要严格，某个 profile（配置档，比如 work 工作档）里的 features 也要严格。这样不同配置档里拼错的功能名也不会被静默放过。

数据流：进去的是路径和一段 [profiles.work.features] 配置文本，其中写了 foo = true。检查函数沿着 profiles.work.features 这条层级去看，发现 foo 不认识，于是返回带完整字段名 profiles.work.features.foo 的错误；测试确认错误位置和信息符合预期。

调用关系：它补上了“配置档内部功能开关”的测试场景。它构造预期错误对象，并用 assert_eq! 对比结果，保证嵌套配置里的未知字段也能被准确定位。

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

fn strict_config_accepts_opaque_desktop_keys()

作用：这个测试确认：desktop 这一段配置可以放一些主程序不认识、但桌面端可能需要的键，不应该被严格配置检查当成错误。也就是说，这里是一个有意保留的“自由区域”。

数据流：进去的是路径和一段包含 [desktop]、[desktop.workspace] 的 TOML 文本，里面有 appearanceTheme 和 collapsed。检查函数读取后没有把这些 desktop 下的键当成未知字段，所以返回 None；测试确认结果确实是没有错误。

调用关系：它保护 desktop 配置的特殊规则，避免以后有人把严格检查改得太死，导致桌面端专用配置被误杀。最后用 assert_eq! 确认检查结果为空。

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

fn hooks_file_deserializes_existing_json_shape()

作用：这个测试确认旧有的 hooks.json 写法仍然能被读懂。它防止项目升级后，把用户已经存在的 JSON 配置文件弄坏。

数据流：进去的是一段 JSON 字符串，里面的事件放在最外层的 hooks 对象里，并包含一个命令型 hook。测试用 JSON 解析函数把它变成 HooksFile 结构，然后拿这个结果和手写出来的期望结构做比较。出来的结果不是业务输出，而是测试通过或失败；如果字段名、默认值或层级解析错了，断言就会失败。

调用关系：它在测试运行时由 Rust 测试框架调用。函数自己把解析工作交给 serde_json::from_str，最后用 assert_eq! 比较实际结果和预期结果，证明 HooksFile 这套反序列化规则没有破坏旧格式。

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

fn hooks_file_rejects_events_outside_hooks_object()

作用：这个测试确认配置不能把事件直接写在 JSON 最外层。这样做是为了避免用户写错位置时程序还假装接受，最后产生难以排查的行为。

数据流：进去的是一段错误形状的 JSON：SessionStart 事件直接写在根部，没有包在 hooks 对象里。测试尝试把它解析成 HooksFile，并期待解析失败。随后检查错误信息里确实提到了未知字段 SessionStart。出来的结果是测试通过或失败；它验证程序会明确拒绝这种错误格式。

调用关系：它由测试框架调用，用解析失败这件事来检查配置入口的边界。它主要依赖 serde_json 的解析错误，再用 assert! 确认错误原因符合预期。

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

fn hook_events_deserialize_from_toml_arrays_of_tables()

作用：这个测试确认 TOML 里常见的“数组表”写法可以正确表达 hook 事件。数组表可以理解成 TOML 里用双中括号写多条同类配置的方式。

数据流：进去的是一段 TOML 字符串，包含一个 PreToolUse 事件、一个匹配器 matcher，以及一个命令型 hook。测试用 TOML 解析函数把它变成 HookEventsToml，再和预期结构比较。解析后，timeout、statusMessage 等字段应落到正确位置，没写的字段应使用默认值。

调用关系：它在测试阶段运行，专门检查 HookEventsToml 这层事件集合的解析。它把读取 TOML 的工作交给 toml::from_str，再用 assert_eq! 确认解析器、字段重命名规则和默认值一起配合正确。

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

fn hooks_toml_deserializes_inline_events_and_state_map()

作用：这个测试确认完整的 hooks TOML 文件既能写事件配置，也能写每个 hook 的状态记录。状态记录比如是否启用、信任过的哈希值，用来记住用户或系统对某个 hook 的选择。

数据流：进去的是一段 TOML：上半部分是 state 映射，记录某个 hook 的 enabled 和 trusted_hash；下半部分是 PreToolUse 事件及其命令。测试把它解析成 HooksToml，并比较 events 和 state 两块内容是否都正确。出来的是测试结果；如果事件和状态不能同时读，或者 key、布尔值、哈希字符串解析错了，就会失败。

调用关系：它由测试框架触发，覆盖比单独 HookEventsToml 更完整的配置文件形态。它调用 toml::from_str 完成文本到结构体的转换，再用 assert_eq! 证明 HooksToml 能把事件和状态两套信息放到各自正确的位置。

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

fn managed_hooks_requirements_flatten_hook_events()

作用：这个测试确认“托管 hooks 要求”文件可以把管理目录和 hook 事件写在同一层。托管 hooks 通常是公司或团队统一下发的脚本位置和规则。

数据流：进去的是一段 TOML，包含 managed_dir，也包含 PreToolUse 事件和命令型 hook。测试把它解析成 ManagedHooksRequirementsToml，期望 managed_dir 变成路径对象，事件配置则进入 hooks 字段。出来的是测试是否通过；它保证这种比较扁平、好写的配置格式能被程序正确收纳进内部结构。

调用关系：它在自动测试中运行，验证企业托管配置的解析入口。它把解析交给 toml::from_str，再用 assert_eq! 检查 managed_dir、windows_managed_dir 默认值，以及 hooks 事件内容是否都符合预期。

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

fn hook_events_deserialize_windows_override_from_toml()

作用：这个测试确认 TOML 里可以为 Windows 单独指定一条命令。这样同一个 hook 在 Linux/macOS 上用 shell 脚本，在 Windows 上用 PowerShell 脚本，互不冲突。

数据流：进去的是一段 TOML，其中 command 是默认命令，command_windows 是 Windows 专用命令。测试解析成 HookEventsToml 后，检查默认命令和 Windows 命令都被放进同一个 HookHandlerConfig::Command 里。出来的是测试结果；它保护跨平台配置不会丢掉 Windows 覆盖项。

调用关系：它由测试框架调用，专门覆盖 command_windows 这种下划线字段名。它依赖 toml::from_str 完成解析，再用 assert_eq! 确认字段别名、路径反斜杠和默认字段值都处理正确。

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

fn hook_events_deserialize_camel_case_windows_override_from_toml()

作用：这个测试确认 Windows 专用命令也支持 commandWindows 这种驼峰写法。驼峰写法就是中间不用下划线、后一个单词首字母大写，很多 JSON 或前端配置里常见。

数据流：进去的是一段 TOML，内容和 Windows 覆盖命令测试类似，但字段名写成 commandWindows。测试把它解析成 HookEventsToml，并检查内部仍然得到 command_windows 这个统一字段。出来的是测试通过或失败；它保证用户用另一种常见命名风格时也不会配置失效。

调用关系：它在测试运行时由测试框架执行，是前一个 Windows 覆盖测试的兼容性补充。它把文本解析交给 toml::from_str，再用 assert_eq! 验证驼峰字段名能被识别并转成同一个内部配置位置。

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

fn deserialize_stdio_command_server_config()

作用：测试最简单的 stdio MCP 配置：只写一个 command 命令时，程序能不能把它读成“启动这个命令”的配置。它还确认一些默认开关是合理的。

数据流：输入是一段只包含 command = "echo" 的 TOML 文本；测试把它解析成 McpServerConfig；结果应该是 stdio 传输方式，命令为 echo，参数、环境变量、工作目录为空，并且默认启用、不强制、没有工具过滤。

调用关系：这是 stdio 配置测试的基础样例。它直接调用 TOML 解析，然后用断言检查结果，为后面带参数、带环境变量、带目录的测试提供基准。

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

fn deserialize_stdio_command_server_config_with_args()

作用：测试 stdio 配置里带 args 参数列表时，参数会不会被原样读进去。这样用户写的命令行参数才不会丢。

数据流：输入是一段包含 command 和 args 的 TOML；测试解析后检查传输配置；输出结果应是命令 echo，参数列表变成 hello 和 world，并且服务仍然默认启用。

调用关系：它接在最简单 command 测试之后，验证同一条 stdio 配置通道能继续承载命令参数。它不把工作交给项目内其他函数，而是通过 TOML 反序列化触发配置代码。

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

fn deserialize_remote_stdio_server_requires_absolute_cwd()

作用：测试远程环境里的 stdio 服务必须写绝对工作目录。绝对路径就是从根目录开始的完整地址，避免远程机器不知道相对路径该从哪里算。

数据流：它先输入一个有 environment_id = "remote" 但没有 cwd 的配置，应该得到错误；再输入 cwd = "relative" 这种相对路径，也应该得到错误；最后检查错误信息里说明了原因。

调用关系：这是配置安全边界测试。它验证解析阶段就拦住不明确的远程启动目录，避免后面的启动流程拿到一个无法可靠执行的配置。

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

fn deserialize_remote_stdio_server_accepts_absolute_cwd()

作用：测试远程 stdio 服务在提供绝对 cwd 时可以通过。它证明上一个测试里的限制不是“一律禁止”，而是只禁止不明确的目录。

数据流：输入先来自系统临时目录，也就是一个绝对路径；测试把这个路径写进 TOML，再解析成配置；结果应该包含同一个 cwd，并且其它 stdio 默认项保持为空或默认值。

调用关系：它和“必须是绝对 cwd”的拒绝测试成对出现。一个测坏情况，一个测好情况，保证规则既严格又不会误伤合法配置。

调用图：外部调用 5 个（assert_eq!, format!, panic!, temp_dir, from_str）。

fn deserialize_stdio_command_server_config_with_arg_with_args_and_env()

作用：测试 stdio 配置同时带命令参数和固定环境变量时能正确读取。环境变量可以理解成启动程序时附带的小纸条，比如 FOO=BAR。

数据流：输入包含 command、args 和 env 表；解析后应该得到 stdio 配置，命令是 echo，参数是 hello/world，env 里有 FOO 到 BAR 的映射，服务默认启用。

调用关系：它扩展了 stdio 的参数测试，把环境变量也放进同一次解析中，确认多个字段组合起来不会互相干扰。

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

fn deserialize_stdio_command_server_config_with_env_vars()

作用：测试 env_vars 这种“从外部继承环境变量名”的写法能被读取。它和 env 不同，env 是直接写值，env_vars 是说运行时去拿这些名字对应的值。

数据流：输入是一段 command 加 env_vars = ["FOO", "BAR"] 的 TOML；解析后 env 仍为空，但 env_vars 列表里应该有 FOO 和 BAR。

调用关系：它验证 stdio 启动配置里第二种环境变量来源。配置解析代码需要同时支持直接给值和只给变量名，这个测试覆盖后者。

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

fn deserialize_stdio_command_server_config_with_env_var_sources()

作用：测试 env_vars 里既能写老式字符串，也能写带 source 来源的对象。source 表示这个环境变量应该从本地还是远程环境取。

数据流：输入里有一个普通字符串 LEGACY_TOKEN，还有两个带 name/source 的配置；解析后列表应保留三项：一个简单名字，以及两个带 local、remote 来源的结构。

调用关系：它保证新旧两种 env_vars 写法可以共存。这样老用户的配置不会坏，新用户又能明确指定变量来源。

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

fn deserialize_stdio_command_server_config_rejects_unknown_env_var_source()

作用：测试 env_vars 的 source 如果写成不支持的值，会被拒绝。这样拼错来源时不会悄悄变成错误行为。

数据流：输入是 source = "elsewhere" 的配置；解析应该失败；测试再检查错误信息里明确提到 unsupported env_vars source elsewhere。

调用关系：它是 env_vars 来源测试的反面案例。前一个测试确认 local/remote 能用，这个测试确认未知来源不能混进去。

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

fn deserialize_stdio_command_server_config_with_cwd()

作用：测试 stdio 配置可以指定 cwd，也就是启动命令前先切到哪个工作目录。很多命令依赖当前目录，读错会导致找不到文件。

数据流：输入包含 command = "echo" 和 cwd = "/tmp"；解析后 stdio 配置里的 cwd 应该是 /tmp，其它字段保持默认。

调用关系：它覆盖本地 stdio 的工作目录字段，并与远程 cwd 的绝对路径规则测试互相补充。

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

fn deserialize_disabled_server_config()

作用：测试用户可以通过 enabled = false 关闭某个 MCP 服务器配置。这样配置可以保留在文件里，但暂时不启动。

数据流：输入包含 command 和 enabled = false；解析后 cfg.enabled 应该是 false，同时 required 默认仍是 false。

调用关系：它验证服务器级别的开关字段。后续真正启动服务的代码会看这个值决定是否跳过该服务器。

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

fn deserialize_required_server_config()

作用：测试 required = true 能正确读取。required 表示这个服务很重要，启动失败时不能当作可有可无。

数据流：输入包含 command 和 required = true；解析后 cfg.required 应该为 true。

调用关系：它覆盖另一个服务器级别的控制开关。启动流程之后可以根据 required 决定失败时是继续还是报错停下。

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

fn deserialize_streamable_http_server_config()

作用：测试最简单的 HTTP MCP 配置：只写 url 时，程序能把它识别成通过网络地址连接的服务。

数据流：输入是一段 url = "https://example.com/mcp" 的 TOML；解析后 transport 应该是 StreamableHttp，里面有这个网址，令牌环境变量和请求头都为空，并且服务默认启用。

调用关系：这是 HTTP 配置测试的基础样例，对应 stdio 的最小 command 测试。它确认 url 字段会选择 HTTP 传输方式。

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

fn deserialize_streamable_http_server_config_with_env_var()

作用：测试 HTTP 配置可以指定 bearer_token_env_var。它表示认证令牌不直接写在配置里，而是从某个环境变量读取，更安全。

数据流：输入包含 url 和 bearer_token_env_var = "GITHUB_TOKEN"；解析后 HTTP 配置里应记录这个环境变量名，其它 HTTP 附加字段为空，服务默认启用。

调用关系：它扩展最简单的 HTTP 测试，覆盖认证令牌的安全写法。后续发 HTTP 请求的代码会按这个名字去取真实令牌。

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

fn deserialize_streamable_http_server_config_with_headers()

作用：测试 HTTP 配置可以携带请求头。请求头可以理解成每次发网络请求时附带的标签或凭证。

数据流：输入包含 url、http_headers 和 env_http_headers；解析后固定请求头 X-Foo 应该等于 bar，另一个请求头 X-Token 的值则应该标记为从 TOKEN_ENV 环境变量取得。

调用关系：它验证 HTTP 专属字段能正常进入配置。之后网络请求层会用这些字段组装真正发出去的 HTTP 请求。

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

fn deserialize_streamable_http_server_config_with_oauth_resource()

作用：测试 HTTP MCP 配置可以读取 oauth_resource。OAuth 是一种常见登录授权方式，resource 用来说明要访问哪个受保护资源。

数据流：输入包含 url 和 oauth_resource；解析后 cfg.oauth_resource 应该保存为 https://api.example.com。

调用关系：它覆盖 HTTP 授权相关的资源字段。这个字段只对 HTTP 有意义，后面的拒绝测试会确认 stdio 不能乱用它。

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

fn deserialize_streamable_http_server_config_with_oauth_client_id()

作用：测试 HTTP 配置里的 [oauth] 小节可以读取 client_id。client_id 是 OAuth 登录时用来表明“我是哪个客户端”的公开标识。

数据流：输入包含 url 和 oauth.client_id；解析后 cfg.oauth 应该变成一个带 client_id 的 McpServerOAuthConfig。

调用关系：它测试 OAuth 配置块的读取，和 oauth_resource 测试一起覆盖 HTTP 授权配置的主要入口。

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

fn deserialize_server_config_with_tool_filters()

作用：测试可以给某个 MCP 服务器设置工具白名单和黑名单。白名单是只允许哪些工具，黑名单是禁止哪些工具。

数据流：输入包含 command、enabled_tools = ["allowed"] 和 disabled_tools = ["blocked"]；解析后两个字段应该分别保存对应的工具名列表。

调用关系：它覆盖服务内工具过滤配置。后续调用工具前，运行逻辑可以根据这些列表判断某个工具能不能用。

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

fn deserialize_server_config_with_parallel_tool_calls()

作用：测试 supports_parallel_tool_calls = true 能被读取。这个开关表示该服务器是否支持同时跑多个工具调用。

数据流：输入包含 command 和 supports_parallel_tool_calls = true；解析后 cfg.supports_parallel_tool_calls 应该为 true。

调用关系：它为并发工具调用能力做读取测试。调度工具调用的代码之后会依赖这个值决定能不能并行发送请求。

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

fn deserialize_server_config_with_default_tool_approval_mode()

作用：测试默认工具审批模式和单个工具的审批模式都能读写。审批模式就是工具执行前要不要自动同意、还是先问用户。

数据流：输入包含 default_tools_approval_mode = "approve"，并给 tools.search 单独设置 approval_mode = "prompt"；解析后默认值应是 Approve，search 工具应是 Prompt；接着再序列化成 TOML 并读回来，结果必须和原配置相同。

调用关系：它不只测读取，还测写回再读取的往返过程。这样可以保证配置编辑、保存、再加载时不会丢掉审批设置。

调用图：外部调用 4 个（assert!, assert_eq!, from_str, to_string）。

fn serialize_round_trips_server_config_with_parallel_tool_calls()

作用：测试支持并行工具调用和工具超时设置在写回 TOML 后不会丢。往返测试能发现“读得进但写不出”的隐藏问题。

数据流：输入包含 command、supports_parallel_tool_calls = true 和 tool_timeout_sec = 2.0；解析后再序列化成字符串；测试确认字符串里有并行开关，再读回 McpServerConfig，最终应与原配置完全相等。

调用关系：它和审批模式的往返测试一样，验证配置的保存能力。配置管理界面或自动修改配置的代码会依赖这种稳定的序列化行为。

调用图：外部调用 4 个（assert!, assert_eq!, from_str, to_string）。

fn deserialize_ignores_unknown_server_fields()

作用：测试配置里出现未知字段时会被忽略，而不是直接失败。这样旧版本或新版本之间多出来的小字段不一定会把整个配置弄坏。

数据流：输入包含 command 和未知字段 trust_level；解析后应该得到一个标准默认的 stdio 配置，trust_level 不进入结果，其它默认值都明确保持为预期状态。

调用关系：它验证配置格式的兼容性策略。用户配置里有程序暂时不认识的字段时，这条规则能让基本功能继续工作。

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

fn deserialize_rejects_command_and_url()

作用：测试同一个 MCP 服务器不能同时写 command 和 url。因为这两个字段分别代表本地命令和 HTTP 地址，二选一才说得清怎么连接。

数据流：输入同时包含 command = "echo" 和 url = "https://example.com"；解析应该失败，不应该生成一个含糊的配置。

调用关系：它守住传输方式选择的边界。前面的 stdio 和 HTTP 测试分别证明单独写能用，这里证明混着写会被拦下。

fn deserialize_rejects_env_for_http_transport()

作用：测试 HTTP 传输不能使用 stdio 专用的 env 字段。env 是启动本地命令时给进程的环境变量，HTTP 网址没有这个启动过程。

数据流：输入包含 url 和 env；解析应该失败，避免把本地进程字段错误套到网络服务上。

调用关系：它是传输方式字段隔离测试的一部分。HTTP 能用请求头和令牌环境变量，但不能用 stdio 的进程环境变量配置。

fn deserialize_rejects_headers_for_stdio()

作用：测试 stdio 传输不能使用 HTTP 专用字段，比如请求头、环境请求头、OAuth 配置和 OAuth 资源。这样配置不会把两种连接方式混在一起。

数据流：它依次输入几段 command 配置，并分别附加 http_headers、env_http_headers、oauth、oauth_resource；每段都应该解析失败；对 oauth 和 oauth_resource，还检查错误文字明确说明 stdio 不支持。

调用关系：它和 HTTP 拒绝 env 的测试互为镜像。两者一起保证 stdio 字段和 HTTP 字段各归各位，解析阶段就发现写错位置的问题。

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

fn deserialize_rejects_inline_bearer_token_field()

作用：测试配置里不能直接写 bearer_token = "secret"。这是为了避免把敏感令牌明文放进配置文件，降低泄露风险。

数据流：输入包含 url 和 bearer_token 明文值；解析应该失败；测试检查错误信息里包含 bearer_token is not supported，提示用户这种写法不被支持。

调用关系：它补充 HTTP 认证配置的安全规则。前面允许 bearer_token_env_var，是因为只保存环境变量名；这里禁止直接保存真正密钥。

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

async fn replace_mcp_servers_serializes_per_tool_approval_overrides() -> anyhow::Result<()>

作用：这个测试确认：当某个 MCP 服务器下面的不同工具有各自的审批规则时，程序会把这些规则正确写进配置文件。也就是说，“默认自动批准”和“某个工具必须询问/批准”不会在保存时丢掉。

数据流：进去的是测试临时创建的一个配置目录，以及一份名叫 docs 的 MCP 服务器配置；这份配置里有启动命令、并行调用开关、默认工具审批模式，还有 search 和 read 两个工具各自的审批模式。测试把这些配置交给 ConfigEditsBuilder 写入 config.toml，然后读取磁盘上的文本，和预先写好的标准答案逐字比较。接着它再调用加载函数把配置读回内存，确认读回来的结构和原始配置完全一致。最后，它删除临时目录，测试成功时返回 Ok。

调用关系：它是 Tokio 异步测试运行器在测试阶段直接调用的用例。流程上，它先通过 ConfigEditsBuilder::new 创建一个配置编辑器，再让编辑器替换 MCP 服务器配置并写入文件；随后用标准文件读取函数检查落盘内容，并用 load_global_mcp_servers 验证正式读取路径也能理解这些内容。pretty_assertions 的 assert_eq! 用来在失败时给出更清楚的差异。

调用图：调用 1 个内部函数（new）；外部调用 9 个（from, from, now, new, assert_eq!, format!, temp_dir, read_to_string, remove_dir_all）。

async fn replace_mcp_servers_serializes_oauth_client_id() -> anyhow::Result<()>

作用：这个测试确认：带 OAuth 客户端编号的 MCP 服务器配置，在保存成配置文件时会写到正确的位置。它保护的是登录授权相关配置，避免用户授权信息因为保存格式错误而失效。

数据流：进去的是一个新建的临时配置目录，以及一份名叫 maas_outlook 的 MCP 服务器配置；这个服务器通过 HTTP 地址连接，并带有 oauth.client_id。测试让 ConfigEditsBuilder 把它写进 config.toml，然后读取生成的文件，检查里面是否有服务器 URL 和单独的 oauth 小节，并且 client_id 完全正确。之后再用 load_global_mcp_servers 从磁盘读回配置，和最初的配置做整体比较。最后清理临时目录并返回 Ok。

调用关系：它同样由 Tokio 的异步测试框架在跑测试时触发。它把主要工作交给 ConfigEditsBuilder::new 创建的编辑器来写配置，再用文件读取和 assert_eq! 做结果核对；最后用 load_global_mcp_servers 走一遍真实加载流程，确保写入方和读取方对 OAuth 配置的格式理解一致。

调用图：调用 1 个内部函数（new）；外部调用 8 个（from, new, now, assert_eq!, format!, temp_dir, read_to_string, remove_dir_all）。

fn test_user_config_path(temp_dir: &TempDir, file_name: &str) -> AbsolutePathBuf

作用：这个小工具函数给测试用的临时目录拼出一个“绝对路径”的配置文件名。这样测试不用碰真实用户的配置文件，也能模拟真实配置文件路径。

数据流：进去的是一个临时目录和一个文件名 → 它把两者拼成完整路径，并确认这个路径是绝对路径 → 出来的是一个 AbsolutePathBuf，也就是被系统认可的绝对配置文件路径；它不改动文件内容，只准备测试用路径。

调用关系：它是两个用户配置相关测试的辅助零件。active_user_layer_is_highest_precedence_user_layer 和 with_user_config_updates_matching_user_layer_without_replacing_active_profile 会先调用它造出 base 配置和 profile 配置的假路径，再用这些路径搭建配置层。

调用图：调用 1 个内部函数（from_absolute_path）；被 2 处调用（active_user_layer_is_highest_precedence_user_layer, with_user_config_updates_matching_user_layer_without_replacing_active_profile）；外部调用 1 个（path）。

fn origins_use_canonical_key_aliases()

作用：这个测试确认：如果配置里用了旧名字，系统记录“这个配置从哪里来”时，会先换成新的标准名字。这样之后查来源时不会被新旧两个名字弄乱。

数据流：进去的是一段 TOML 配置文本，里面写了旧键名 memories.no_memories_if_mcp_or_web_search → 测试把它放进一个配置层，再创建配置层栈，并取出来源记录 origins → 最后检查来源里有新键名 memories.disable_on_external_context，没有旧键名；如果结果不对，测试失败。

调用关系：这个测试直接使用 ConfigLayerEntry::new 创建配置层，再用 ConfigLayerStack::new 触发配置标准化和来源记录。它主要保护“旧配置键名兼容新配置键名”这条规则，避免后续改配置合并逻辑时破坏兼容性。

调用图：调用 2 个内部函数（new, new）；外部调用 6 个（default, assert!, assert_eq!, default, from_str, vec!）。

fn active_user_layer_is_highest_precedence_user_layer()

作用：这个测试确认：当有多个用户配置层时，当前活跃的用户配置文件应该是优先级最高的那个，比如某个 profile 的配置文件。它还确认合并后的用户配置既包含 profile 覆盖的值，也保留基础配置里的值。

数据流：进去的是测试临时目录中模拟出来的两个配置文件路径，以及两段 TOML 配置：基础配置写 model 和 approval_policy，profile 配置只写 model → 测试把它们做成两个用户配置层并组成配置层栈 → 出来要看到当前用户配置文件是 profile 文件，合并后的 model 来自 profile，approval_policy 仍来自基础配置。

调用关系：它调用 test_user_config_path 准备假文件路径，用 ConfigLayerEntry::new 包装每一层配置，再交给 ConfigLayerStack::new 合并。这个测试位于用户配置选择流程的验证端，专门防止系统误把基础配置文件当成当前活跃文件。

调用图：调用 3 个内部函数（new, new, test_user_config_path）；外部调用 6 个（new, default, assert_eq!, default, from_str, vec!）。

fn with_user_config_updates_matching_user_layer_without_replacing_active_profile()

作用：这个测试确认：更新某个指定的用户配置文件时，只改匹配的那一层，不会把当前激活的 profile 配置文件换掉。它保护的是“改一个文件，不要牵连另一个文件”的行为。

数据流：进去的是基础配置文件路径、profile 配置文件路径、原始两层配置，以及一段新的基础配置 TOML → 测试先建好配置层栈，再调用 with_user_config 用新内容替换基础配置那一层 → 出来要看到当前用户配置文件仍然是 profile 文件，同时合并结果里的 model 变成 updated-base，profile 里的 approval_policy 仍然保留。

调用关系：它和前一个测试一样先借助 test_user_config_path 造路径，再创建配置层栈；不同的是它接着调用 stack.with_user_config 模拟“用户保存了某个配置文件”。这个测试保护更新流程，确保更新基础配置不会破坏 profile 的激活状态。

调用图：调用 3 个内部函数（new, new, test_user_config_path）；外部调用 6 个（new, default, assert_eq!, default, from_str, vec!）。

fn canonicalize(
        &'a self,
        path: &'a PathUri,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, PathUri>

作用：这个函数把测试里传进来的路径变成操作系统认可的真实绝对路径。配置加载器需要确认文件位置时，会用它来模拟真实文件系统的行为。

数据流：输入是一个 PathUri 路径和一个这里不用的沙箱参数 → 它先把 PathUri 转成普通绝对路径，再调用系统的路径规范化能力，处理掉符号链接、相对片段等 → 输出一个新的 PathUri，指向规范化后的真实路径；它不改动文件内容。

调用关系：它是 TestFileSystem 给配置加载器提供的读文件环境的一部分。加载流程需要确认配置文件位置时会走到这里；它内部把活交给路径转换和系统 canonicalize，再把结果包装回 PathUri。

调用图：调用 2 个内部函数（from_abs_path, to_abs_path）；外部调用 2 个（pin, canonicalize）。

fn read_file(
        &'a self,
        path: &'a PathUri,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, Vec<u8>>

作用：这个函数负责在测试中读取配置文件内容。测试写好的 config.toml 和 work.config.toml，最后就是靠它被配置加载器读进去。

数据流：输入是一个 PathUri 路径和一个这里不用的沙箱参数 → 它把路径转成普通绝对路径，再交给 tokio 的异步读文件功能读取字节 → 输出文件的原始字节内容；如果文件不存在或读不了，就返回系统错误。

调用关系：它是测试文件系统里真正被大量需要的能力。配置加载流程要读用户配置时会通过这个接口拿内容；它自己不解析配置，只负责把磁盘上的字节交出去。

调用图：调用 1 个内部函数（to_abs_path）；外部调用 3 个（pin, read, as_path）。

fn read_file_stream(
        &'a self,
        _path: &'a PathUri,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, FileSystemReadStream>

作用：这个函数表示“流式读取文件”在这个测试文件系统里不支持。流式读取就是一点一点读大文件，但这些测试只需要一次性读小配置文件。

数据流：输入是路径和沙箱参数，但都不会真正使用 → 它直接构造一个“不支持”的输入输出错误 → 输出失败结果，不返回文件流，也不改动任何东西。

调用关系：它只是为了满足 ExecutorFileSystem 这个接口必须提供的函数。当前这些配置加载测试不应该依赖流式读取；如果误用了它，测试会立刻得到明确错误。

调用图：外部调用 2 个（pin, new）。

fn write_file(
        &'a self,
        _path: &'a PathUri,
        _contents: Vec<u8>,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, ()>

作用：这个函数故意不提供写文件能力。测试里的文件是直接用标准库先写好的，配置加载器在这里不应该写文件。

数据流：输入是目标路径、要写入的字节和沙箱参数 → 函数进入后直接触发 unimplemented，也就是“这里不该被调用”的占位错误 → 没有正常输出，也不会写任何文件。

调用关系：它是为了凑齐文件系统接口而存在的防护栏。配置加载测试只应该读取配置；如果加载流程意外想写文件，就会在这里暴露问题。

调用图：外部调用 2 个（pin, unimplemented!）。

fn create_directory(
        &'a self,
        _path: &'a PathUri,
        _create_directory_options: CreateDirectoryOptions,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorF

作用：这个函数故意不支持创建目录。因为这些测试只验证读取和解析配置，不需要配置加载器帮忙建目录。

数据流：输入是目录路径、创建选项和沙箱参数 → 它不做实际创建，直接触发“未实现”的错误 → 没有正常结果，磁盘目录不会被改动。

调用关系：它和其他未实现函数一样，是测试替身的一部分。若配置加载器在这个测试场景里错误地尝试创建目录，测试会马上失败，提醒开发者行为跑偏了。

调用图：外部调用 2 个（pin, unimplemented!）。

fn get_metadata(
        &'a self,
        _path: &'a PathUri,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, FileMetadata>

作用：这个函数故意不支持读取文件元数据。元数据就是文件大小、类型、修改时间这类信息；本测试不需要这些。

数据流：输入是路径和沙箱参数 → 它不访问磁盘，也不返回文件大小或类型 → 直接以未实现方式失败。

调用关系：它只是实现文件系统接口所需的占位。当前配置加载测试应该只关心文件内容；如果以后流程开始依赖元数据，这里会让测试显式失败，促使开发者更新测试文件系统。

调用图：外部调用 2 个（pin, unimplemented!）。

fn read_directory(
        &'a self,
        _path: &'a PathUri,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, Vec<ReadDirectoryEntry>>

作用：这个函数故意不支持列目录。列目录就是看看某个文件夹里有哪些文件；这些测试已经明确指定了配置文件路径，不需要扫描文件夹。

数据流：输入是目录路径和沙箱参数 → 它不读取目录项 → 直接触发未实现错误，没有正常输出。

调用关系：它是测试文件系统的接口占位。配置加载流程在这些测试中不该去枚举目录；如果发生了，测试会失败并暴露这个多余依赖。

调用图：外部调用 2 个（pin, unimplemented!）。

fn remove(
        &'a self,
        _path: &'a PathUri,
        _remove_options: RemoveOptions,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    ) -> ExecutorFileSystemFuture<'a, ()>

作用：这个函数故意不支持删除文件或目录。配置加载器在读取配置时不应该清理用户文件。

数据流：输入是要删除的路径、删除选项和沙箱参数 → 它不碰磁盘 → 直接以未实现方式失败，不会删除任何东西。

调用关系：它是接口要求下的安全占位。这个测试场景只允许读，如果加载流程意外做删除操作，会在这里被拦住。

调用图：外部调用 2 个（pin, unimplemented!）。

fn copy(
        &'a self,
        _source_path: &'a PathUri,
        _destination_path: &'a PathUri,
        _copy_options: CopyOptions,
        _sandbox: Option<&'a FileSystemSandboxContext>,
    )

作用：这个函数故意不支持复制文件。配置读取测试不需要把配置文件从一个地方复制到另一个地方。

数据流：输入是来源路径、目标路径、复制选项和沙箱参数 → 它不执行复制 → 直接触发未实现错误，没有正常输出，也不改变文件系统。

调用关系：它补齐了 ExecutorFileSystem 接口，但不参与正常测试路径。它的存在像一个报警器：如果配置加载过程突然开始复制文件，测试会立刻告诉开发者。

调用图：外部调用 2 个（pin, unimplemented!）。

async fn profile_v2_rejects_matching_legacy_profile_in_base_user_config()

作用：这个测试确认：如果用户用新版 profile 文件 work.config.toml，同时基础 config.toml 里又有旧版 [profiles.work]，加载器必须报错。这样可以避免同名配置有两套来源，导致结果说不清。

数据流：开始时它创建临时目录 → 写入一个基础 config.toml，里面有 model 和旧版 [profiles.work]，再写入一个新版 work.config.toml → 设置覆盖参数，让加载器选择 work 这个新版 profile → 调用配置加载后期待失败 → 最后检查错误类型和错误文字，确认提示里讲清了 --profile work 不能这样用、问题来自 config.toml 和 [profiles.work]，并给出文档链接。

调用关系：它是直接驱动配置加载器的测试用例。它用 TestFileSystem 提供读取能力，用 without_managed_config_for_tests 关掉托管配置干扰，用 resolve_path_against_base 指定测试配置文件位置，然后把结果交给断言检查。

调用图：调用 2 个内部函数（without_managed_config_for_tests, resolve_path_against_base）；外部调用 4 个（assert!, assert_eq!, write, tempdir）。

async fn profile_v2_rejects_matching_legacy_profile_selector_in_base_user_config()

作用：这个测试确认：如果基础 config.toml 里写了旧版的 profile = "work"，而用户又用新版方式选择 work.config.toml，也必须报错。原因同样是避免新旧两套选择规则指向同一个名字。

数据流：它先创建临时目录 → 写入基础 config.toml，其中包含 profile = "work" 和默认 model，再写入 work.config.toml → 设置加载覆盖项，让当前用户配置路径指向 work.config.toml，并指定 profile 名为 work → 调用配置加载并期待错误 → 最后检查错误类型是 InvalidData，错误信息里包含 --profile work、profile = "work" 和 work.config.toml。

调用关系：它覆盖的是另一种旧版冲突写法：不是 [profiles.work] 小节，而是 profile 字段。它和上一个测试一起保证配置加载器不会在新版 profile-v2 场景下接受同名旧规则。

调用图：调用 2 个内部函数（without_managed_config_for_tests, resolve_path_against_base）；外部调用 4 个（assert!, assert_eq!, write, tempdir）。

async fn profile_v2_allows_unrelated_legacy_profiles_in_base_user_config()

作用：这个测试确认：基础 config.toml 里有旧版 profile 也不一定错，只要名字和当前新版 profile 不冲突就可以。比如当前选 work，而旧配置里只有 dev，就应该正常加载。

数据流：它创建临时目录 → 写入基础 config.toml，其中有默认 model 和旧版 [profiles.dev]，再写入 work.config.toml → 设置覆盖项选择新版 work 配置 → 调用配置加载 → 期待成功，不做额外错误检查。

调用关系：它是前两个拒绝测试的平衡项，防止规则做得太严。它告诉配置加载器：真正要拦的是“同名冲突”，不是看到任何旧版 profile 都报错。

调用图：调用 2 个内部函数（without_managed_config_for_tests, resolve_path_against_base）；外部调用 2 个（write, tempdir）。

fn blocking_set_model_top_level()

作用：检查直接设置顶层模型名和推理力度时，配置文件会写成最基本、正确的两行。

数据流：进去的是一个临时用户目录，以及要设置的模型 gpt-5.4 和 high 力度；测试执行配置写入；出来的是 config.toml 文件，内容必须正好包含 model 和 model_reasoning_effort 两项。

调用关系：这是配置编辑器最基础的用例之一，由测试运行器启动；它通过临时目录隔离真实用户文件，再用读取文件和断言确认写入结果。

调用图：外部调用 3 个（assert_eq!, read_to_string, tempdir）。

fn set_service_tier_saves_default_as_default()

作用：检查把服务档位设成默认请求值时，文件里保存的是清楚的 default。

数据流：进去的是临时目录和默认服务档位字符串；构建器把它变成一次配置修改并落盘；出来的 config.toml 应该只有 service_tier = "default"。

调用关系：测试运行器调用它；它走 ConfigEditsBuilder 这条更接近日常使用的入口，确认服务档位写入没有绕错格式。

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

fn set_service_tier_saves_priority_as_fast()

作用：检查“快速/优先”服务档位会按系统约定写成 fast。

数据流：进去的是临时目录和 ServiceTier::Fast 对应的请求值；配置构建器写入文件；出来的文本必须是 service_tier = "fast"。

调用关系：它验证服务档位枚举值和配置文件文字之间的转换，由测试运行器在测试阶段自动执行。

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

fn set_service_tier_preserves_unknown_service_tier()

作用：检查遇到程序暂时不认识的服务档位时，不会自作主张改掉它。

数据流：进去的是 experimental-tier-id 这样的未知字符串；配置编辑器原样保存；出来的 config.toml 也必须原样写着这个值。

调用关系：这个测试保护向前兼容性：如果服务端以后新增档位，旧客户端也不应该把用户选择弄丢。

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

fn builder_with_edits_applies_custom_paths()

作用：检查构建器能接受一组自定义配置修改，并按指定路径写入。

数据流：进去的是路径 enabled 和布尔值 true；构建器收下这条 SetPath 修改并保存；出来的配置文件包含 enabled = true。

调用关系：它覆盖 ConfigEditsBuilder 的通用入口 with_edits，说明除了专门方法，也能直接塞入底层编辑动作。

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

fn session_picker_view_edit_writes_root_tui_setting()

作用：检查会话选择器的显示模式会写到根部的 tui 表里，而不是别的配置分支。

数据流：进去的是 Dense 显示模式；辅助函数生成一次配置编辑；出来的文件有 [tui] 表和 session_picker_view = "dense"。

调用关系：测试运行器触发它；它验证 UI 设置相关的辅助编辑函数和实际落盘格式能对上。

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

fn keymap_binding_edit_writes_root_action_binding()

作用：检查单个快捷键绑定会写到正确的 TUI 键位表下面。

数据流：进去的是区域 composer、动作 submit、按键 ctrl-enter；编辑器写入嵌套表；出来是 [tui.keymap.composer] 里的 submit = "ctrl-enter"。

调用关系：它测试快捷键编辑辅助函数，确保根配置里的键位改动不会走偏。

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

fn keymap_bindings_edit_writes_single_binding_as_string()

作用：检查只有一个快捷键时，配置保存成简单字符串，而不是数组。

数据流：进去的是只包含 ctrl-enter 的按键列表；编辑器判断只有一项并写成字符串；出来的 TOML 更简洁，submit 等于一个字符串。

调用关系：它和多快捷键测试配套，保证同一个接口在不同数量输入下写出符合约定的格式。

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

fn keymap_bindings_edit_writes_multiple_bindings_as_array()

作用：检查一个动作有多个快捷键时，会保存成数组，也就是一串值的列表。

数据流：进去的是 enter 和 ctrl-enter 两个按键；编辑器写入配置；测试再把 TOML 解析回来，确认 submit 是包含这两个字符串的数组。

调用关系：它补齐快捷键列表场景，调用 TOML 解析来避免只靠文本格式判断。

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

fn keymap_binding_edit_replaces_existing_binding_without_touching_profile()

作用：检查替换根快捷键时，不会误改某个 profile 里的快捷键。

数据流：进去的是一份已有根快捷键和 team profile 快捷键的配置；编辑器只把根 submit 改成 ctrl-enter；出来时 profile 里的 shift-enter 仍然保留。

调用关系：它保护“根配置”和“个人配置方案”之间的边界，防止一次普通设置影响团队或个人专用配置。

调用图：调用 1 个内部函数（new）；外部调用 5 个（assert_eq!, read_to_string, write, tempdir, from_str）。

fn keymap_binding_clear_edit_removes_root_action_binding_without_touching_profile()

作用：检查清除根快捷键时，只删根部那一项，不碰 profile 里的同名项。

数据流：进去的是同时有根快捷键和 profile 快捷键的配置；清除动作移除根 submit；出来时根部查不到 submit，但 profile 里的 submit 仍是 shift-enter。

调用关系：它和替换快捷键测试互相补充，确认删除操作也遵守同样的边界。

调用图：调用 1 个内部函数（new）；外部调用 5 个（assert_eq!, read_to_string, write, tempdir, from_str）。

fn set_model_availability_nux_count_writes_shown_count()

作用：检查模型可用性提示已经展示过几次，会写进 TUI 配置。

数据流：进去的是一个映射表，记录 gpt-foo 显示次数为 4；构建器写入配置；出来是 [tui.model_availability_nux] 下 gpt-foo = 4。

调用关系：它验证新手提示类状态可以被保存，避免界面重复打扰用户。

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

fn set_skill_config_writes_disabled_entry()

作用：检查按文件路径禁用某个 skill 时，会写入一条 disabled 配置。

数据流：进去的是 SKILL.md 的路径和 enabled = false；编辑器写入 skills.config 数组表；出来的配置记录这个路径被禁用。

调用关系：它测试技能开关的持久化格式，让后续加载配置时能知道某个技能被用户关掉了。

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

fn set_skill_config_removes_entry_when_enabled()

作用：检查把某个按路径禁用的 skill 重新启用时，会删掉那条特殊配置。

数据流：进去的是一份已禁用某 skill 的配置，再传入 enabled = true；编辑器移除这条覆盖记录；出来的 config.toml 为空。

调用关系：它说明默认状态是启用，所以启用时不需要留下多余记录；测试保护配置文件不被无意义内容堆满。

调用图：调用 1 个内部函数（new）；外部调用 5 个（from, assert_eq!, read_to_string, write, tempdir）。

fn set_skill_config_writes_name_selector_entry()

作用：检查也可以按 skill 名称而不是文件路径来写禁用配置。

数据流：进去的是名称 github:yeet 和 enabled = false；编辑器写入 skills.config 数组表；出来的配置用 name 字段标识被禁用的技能。

调用关系：它覆盖另一种选择 skill 的方式，确保路径选择和名称选择都能保存。

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

fn blocking_set_model_ignores_inline_legacy_profile_contents()

作用：检查设置根模型时，不会钻进旧式内联 profile 里改内容。

数据流：进去的是带 profile = fast 和内联 profiles 表的旧配置；编辑器只在根部写 model = o4-mini；出来时 profiles.fast 里的旧 model 和 sandbox_mode 都没变。

调用关系：它保护旧配置兼容性，防止用户历史 profile 被新的根级设置意外覆盖。

调用图：外部调用 5 个（assert_eq!, read_to_string, write, tempdir, from_str）。

fn blocking_set_model_writes_through_symlink_chain()

作用：在 Unix 系统上检查 config.toml 如果是符号链接链，正常情况下会写到最终目标文件。

数据流：进去的是 config.toml 指向另一个链接、再指向真实目标文件的结构；编辑器写入模型配置；出来时 config.toml 仍是链接，而真实目标文件有新内容。

调用关系：它测试磁盘写入层的安全行为，确保用户用链接管理配置时不会被破坏。

调用图：外部调用 6 个（assert!, assert_eq!, read_to_string, symlink_metadata, symlink, tempdir）。

fn blocking_set_model_replaces_symlink_on_cycle()

作用：在 Unix 系统上检查符号链接形成死循环时，程序不会卡住，而是把 config.toml 换成普通文件。

数据流：进去的是 a.toml 和 b.toml 互相指向、config.toml 又指向其中一个的循环；编辑器尝试写入模型；出来时 config.toml 不再是链接，并包含正确模型配置。

调用关系：它是异常文件系统场景的防护测试，保证配置保存遇到坏链接时仍能恢复。

调用图：外部调用 6 个（assert!, assert_eq!, read_to_string, symlink_metadata, symlink, tempdir）。

fn batch_write_table_upsert_preserves_inline_comments()

作用：检查一次批量更新多个表里的值时，原来的注释不会丢。

数据流：进去的是带注释的 MCP 服务器和沙箱配置；编辑器更新 url 和 network_access；出来的文本值变了，但 # ok 这类注释仍在原处。

调用关系：它验证批量写入不是粗暴重写整个文件，而是尽量尊重用户手写配置。

调用图：外部调用 5 个（assert_eq!, read_to_string, write, tempdir, vec!）。

fn blocking_clear_model_does_not_follow_legacy_active_profile()

作用：检查清除根模型时，不会因为当前 profile 指向 fast 就去改 fast 的旧配置。

数据流：进去的是旧式 profile 配置和一次 model = None、effort = high 的修改；编辑器不动 profile，只在根部增加 model_reasoning_effort；出来的旧 profiles 内容保持原样。

调用关系：它继续保护根设置和旧 profile 的隔离，尤其覆盖“清除模型”这种容易误判的情况。

调用图：外部调用 4 个（assert_eq!, read_to_string, write, tempdir）。

fn blocking_set_model_does_not_follow_legacy_active_profile()

作用：检查设置模型和推理力度时，只写根部，不跟随当前激活的 legacy profile。

数据流：进去的是 profile = team 且 team 里已有 low 力度的配置；编辑器在根部写 o5-preview 和 minimal；出来时 profile 里的 low 不变。

调用关系：它和前一个测试一起说明：无论设置还是清除，根级编辑都不能偷偷改 profile。

调用图：外部调用 4 个（assert_eq!, read_to_string, write, tempdir）。

fn blocking_set_hide_full_access_warning_preserves_table()

作用：检查隐藏“完全访问权限警告”的标记会加进 notice 表，同时保留原表内容和注释。

数据流：进去的是已有 [notice] 表、注释和 existing 值的配置；编辑器加入 hide_full_access_warning = true；出来时旧内容仍在，新标记追加进去。

调用关系：它测试通知类设置的写入，重点是不要为了加一个开关而重建整张表。

调用图：外部调用 5 个（SetNoticeHideFullAccessWarning, assert_eq!, read_to_string, write, tempdir）。

fn blocking_set_hide_rate_limit_model_nudge_preserves_table()

作用：检查隐藏“速率限制模型提示”的开关会正确追加到 notice 表。

数据流：进去的是已有 notice.existing 的配置；编辑器写入 hide_rate_limit_model_nudge = true；出来时 existing 还在，新开关也在。

调用关系：它覆盖 notice 表里的另一个布尔开关，保证同类提示状态都能安全保存。

调用图：外部调用 5 个（SetNoticeHideRateLimitModelNudge, assert_eq!, read_to_string, write, tempdir）。

fn blocking_set_hide_gpt5_1_migration_prompt_preserves_table()

作用：检查隐藏某个模型迁移提示的开关会写入 notice 表，普通键名不用加引号。

数据流：进去的是已有 notice 表和键名 hide_gpt5_1_migration_prompt；编辑器把它设为 true；出来时 notice 表保留旧值并新增这个布尔项。

调用关系：它验证模型迁移提示的记录方式，确保简单键名输出成常规 TOML 写法。

调用图：外部调用 5 个（SetNoticeHideModelMigrationPrompt, assert_eq!, read_to_string, write, tempdir）。

fn blocking_set_hide_gpt_5_1_codex_max_migration_prompt_preserves_table()

作用：检查键名里带点号和横线时，写 TOML 会自动加引号，避免被误解成多层路径。

数据流：进去的是特殊键名 hide_gpt-5.1-codex-max_migration_prompt 和 true；编辑器写入 notice 表；出来时键名被引号包住，表示它是一个完整名字。

调用关系：它保护 TOML 语法细节：带特殊字符的提示开关不能被拆错层级。

调用图：外部调用 5 个（SetNoticeHideModelMigrationPrompt, assert_eq!, read_to_string, write, tempdir）。

fn blocking_record_model_migration_seen_preserves_table()

作用：检查记录“用户已经看过从某模型迁移到某模型”的信息时，会放进 notice.model_migrations 表。

数据流：进去的是 from = gpt-5.2、to = gpt-5.4 和已有 notice 表；编辑器新增子表记录；出来时 existing 保留，并多出 "gpt-5.2" = "gpt-5.4"。

调用关系：它服务于迁移提示去重，避免用户反复看到同一条模型迁移提醒。

调用图：外部调用 4 个（assert_eq!, read_to_string, write, tempdir）。

fn blocking_set_hide_external_config_migration_prompt_home_preserves_table()

作用：检查隐藏“主目录外部配置迁移提示”的状态会写到专门的 notice 子表。

数据流：进去的是已有 notice 表和 home = true 的意图；编辑器创建 notice.external_config_migration_prompts；出来时 home 标记在这个子表里。

调用关系：它测试外部配置迁移提示的首页级别状态，确保不污染 notice 表的其他字段。

调用图：外部调用 5 个（SetNoticeHideExternalConfigMigrationPromptHome, assert_eq!, read_to_string, write, tempdir）。

fn blocking_set_hide_external_config_migration_prompt_project_preserves_table()

作用：检查按项目路径隐藏外部配置迁移提示时，路径会作为键保存。

数据流：进去的是一个项目路径和 true；编辑器写入 notice.external_config_migration_prompts.projects；出来时该路径对应 true。

调用关系：它覆盖项目级提示状态，让不同项目可以分别记住是否已经不再提醒。

调用图：外部调用 5 个（SetNoticeHideExternalConfigMigrationPromptProject, assert_eq!, read_to_string, write, tempdir）。

fn blocking_set_external_config_migration_prompt_home_last_prompted_at_preserves_table()

作用：检查记录主目录迁移提示上次弹出的时间戳时，会写到正确位置。

数据流：进去的是时间戳 1760000000；编辑器写入 notice.external_config_migration_prompts.home_last_prompted_at；出来时旧 notice 内容还在，新时间也在。

调用关系：它用于控制提醒频率，避免同一个提示太频繁出现。

调用图：外部调用 5 个（SetNoticeExternalConfigMigrationPromptHomeLastPromptedAt, assert_eq!, read_to_string, write, tempdir）。

fn blocking_set_external_config_migration_prompt_project_last_prompted_at_preserves_table()

作用：检查每个项目的外部配置迁移提示上次弹出时间可以单独保存。

数据流：进去的是项目路径和时间戳；编辑器写入 project_last_prompted_at 子表；出来时该路径对应这个时间值。

调用关系：它配合项目级隐藏状态使用，让提醒节奏可以按项目分别计算。

调用图：外部调用 5 个（SetNoticeExternalConfigMigrationPromptProjectLastPromptedAt, assert_eq!, read_to_string, write, tempdir）。

fn blocking_replace_mcp_servers_round_trips()

作用：检查整批替换 MCP 服务器配置时，各种字段都能按约定写成 TOML。

数据流：进去的是两个服务器配置：一个 stdio 类型、一个 HTTP 类型，包含环境变量、请求头、超时、工具白名单/黑名单、OAuth 等；编辑器写入文件；出来的文本必须和预期完全一致。

调用关系：它是 MCP 配置序列化的主测试，覆盖字段最多，保证复杂服务器设置保存后不会变形。

调用图：外部调用 8 个（new, new, ReplaceMcpServers, assert_eq!, read_to_string, from_secs, tempdir, vec!）。

fn blocking_replace_mcp_servers_serializes_tool_approval_overrides()

作用：检查 MCP 服务器的工具审批规则能保存，包括默认规则和单个工具覆盖规则。

数据流：进去的是 docs 服务器配置，默认工具审批为 prompt，search 工具审批为 approve；编辑器写入 TOML；出来时对应字段位于服务器表和 tools.search 子表中。

调用关系：它补充 MCP 的权限控制场景，保证细粒度工具审批不会在保存时丢失。

调用图：外部调用 7 个（new, from, new, ReplaceMcpServers, assert_eq!, read_to_string, tempdir）。

fn blocking_replace_mcp_servers_preserves_inline_comments()

作用：检查替换 MCP 服务器时，如果配置内容本来等价，表里的注释会被保留下来。

数据流：进去的是带 # keep me 注释和内联 foo 服务器的配置；新服务器配置内容相同；出来的文件应保持原样，包括注释。

调用关系：它防止配置编辑器为了重写 MCP 而破坏用户注释，是“少动无关内容”的测试。

调用图：外部调用 8 个（new, new, new, ReplaceMcpServers, assert_eq!, read_to_string, write, tempdir）。

fn blocking_replace_mcp_servers_preserves_inline_comment_suffix()

作用：检查 MCP 服务器内联表行尾注释在更新字段后仍然保留。

数据流：进去的是 foo = { command = "cmd" } # keep me；新配置把 enabled 改成 false；出来时内联表增加 enabled = false，行尾 # keep me 还在。

调用关系：它覆盖注释在同一行末尾的情况，确保更新值时不会截掉后面的说明文字。

调用图：外部调用 8 个（new, new, new, ReplaceMcpServers, assert_eq!, read_to_string, write, tempdir）。

fn blocking_replace_mcp_servers_preserves_inline_comment_after_removing_keys()

作用：检查从 MCP 内联表删除字段时，行尾注释仍然不会丢。

数据流：进去的是带 args 字段和行尾注释的内联服务器配置；新配置没有 args；编辑器移除 args；出来时注释 # keep me 仍跟在这一行后面。

调用关系：它测试更难的编辑场景：不仅加字段，还要删字段，同时保住用户注释。

调用图：外部调用 8 个（new, new, new, ReplaceMcpServers, assert_eq!, read_to_string, write, tempdir）。

fn blocking_replace_mcp_servers_preserves_inline_comment_prefix_on_update()

作用：检查 MCP 内联表前一行的注释，在更新服务器字段后还能留在原处。

数据流：进去的是 # keep me 后面跟 foo 内联服务器；新配置把 enabled 设为 false；出来时注释仍在 foo 前面，foo 行被正确更新。

调用关系：它和行尾注释测试一起，覆盖注释在字段前后的两种常见写法。

调用图：外部调用 8 个（new, new, new, ReplaceMcpServers, assert_eq!, read_to_string, write, tempdir）。

fn blocking_clear_path_noop_when_missing()

作用：检查清除一个不存在的配置路径时，什么都不做，也不凭空创建 config.toml。

数据流：进去的是空临时目录和要清除的 missing 路径；编辑器发现没有可删内容；出来时 config.toml 文件不存在。

调用关系：它保护无操作场景，避免用户只是清一个不存在的设置，却多出一个空配置文件。

调用图：外部调用 3 个（assert!, tempdir, vec!）。

fn blocking_set_path_updates_notifications()

作用：检查通用 SetPath 能写入 tui.notifications 这样的嵌套布尔值。

数据流：进去的是路径 tui -> notifications 和 false；编辑器创建或更新对应表；出来的 TOML 解析后能读到 notifications 为 false。

调用关系：它验证通用路径写入能力，说明不只是专门接口能改配置。

调用图：外部调用 5 个（assert_eq!, read_to_string, tempdir, from_str, vec!）。

async fn async_builder_set_model_persists()

作用：检查异步版本的构建器也能正确保存模型设置。异步就是任务可以等待磁盘操作，不一定堵住当前执行线程。

数据流：进去的是模型 gpt-5.4 和 high 力度；调用 apply().await 等待保存完成；出来的配置文件包含对应两行。

调用关系：它由 Tokio 异步测试运行器执行，确认异步入口和阻塞入口写出的结果一致。

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

fn blocking_builder_set_model_round_trips_back_and_forth()

作用：检查阻塞式构建器反复切换模型设置时，每次都能写成当前最新值。

数据流：先写 o4-mini/low，再改成 gpt-5.4/high，最后改回 o4-mini/low；每一步都读取文件核对；出来的文件总是匹配最后一次设置。

调用关系：它测试连续编辑的稳定性，模拟用户来回切换设置的真实操作。

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

async fn blocking_set_asynchronous_helpers_available()

作用：检查那些辅助设置方法在异步 apply 流程里也能使用。

数据流：进去的是 hide_full_access_warning = true；构建器用异步保存；出来的 TOML 解析后，notice.hide_full_access_warning 为 true。

调用关系：它连接“便捷方法”和“异步落盘”两条路径，确保组合使用时不会漏掉编辑。

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

fn blocking_builder_set_realtime_audio_persists_and_clears()

作用：检查实时音频的麦克风和扬声器设置能保存，也能单独清除其中一项。

数据流：先输入麦克风 USB Mic 和扬声器 Desk Speakers；编辑器写入 audio 表；再把麦克风设为 None；出来时 microphone 被删掉，speaker 仍保留。

调用关系：它测试实时音频设备偏好的保存和清理，尤其确认清一个字段不会误删同表里的另一个字段。

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

fn blocking_builder_set_realtime_voice_persists_and_clears()

作用：检查实时语音的 voice 设置能保存，也能清空。

数据流：先输入 voice = cedar；编辑器写入 realtime 表；再把 voice 设为 None；出来时 realtime 表里不再有 voice。

调用关系：它覆盖实时会话相关配置的另一个字段，确认设置和清除路径都正常。

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

fn replace_mcp_servers_blocking_clears_table_when_empty()

作用：检查用空服务器列表替换 MCP 配置时，旧的 mcp_servers 表会被删掉。

数据流：进去的是已有 foo MCP 服务器的配置，以及一个空的服务器映射；编辑器执行替换；出来的文件内容不再包含 mcp_servers。

调用关系：它验证“清空全部 MCP 服务器”的行为，防止旧服务器配置残留导致程序以后还会加载它们。

调用图：外部调用 6 个（new, ReplaceMcpServers, assert!, read_to_string, write, tempdir）。

fn trim_single_trailing_newline(contents: &str) -> &str

作用：这个小工具函数用来去掉字符串末尾一个多余的换行符。它的作用是让测试比较文件内容时，不会因为最后一行有没有换行这种小差别而误报失败。

数据流：进去的是一段文字 → 它检查最后是不是正好有一个换行符 → 如果有就去掉这个换行符，如果没有就原样返回；它不修改原文字，只返回一个可比较的文字片段。

调用关系：它被 config_schema_matches_fixture 用在最后的精确内容比较里。这个测试已经检查了主要结构是否一致，最后再借它把末尾换行这种无关紧要的差异排除掉。

fn config_schema_matches_fixture()

作用：这个测试确认当前代码生成的配置 schema 和仓库里保存的标准版本一致。它像是在检查“说明书模板”和“现场重新打印出来的说明书”是不是同一本。

数据流：进去的是仓库里的 config.schema.json 文件，以及 config_schema_json 现场生成的新 schema → 它把两边都读成 JSON 数据，先做规范化处理，再比较结构是否一样；如果不一样，就生成一份清楚的差异文本并让测试失败 → 接着它还把 schema 写到临时文件，再读回来和仓库文件做接近逐字的比较，最后确认生成文件和提交在仓库里的文件完全对得上。

调用关系：这是配置 schema 的主验收测试。它会调用 find_resource! 找到仓库里的参考文件，调用 config_schema_json 生成当前 schema，调用 canonicalize 消除 JSON 顺序等无关差异，发现不同时用 TextDiff 做人能看懂的差异报告；后半段再调用 write_config_schema，验证真正写文件的结果也和仓库内容一致。

调用图：外部调用 12 个（new, from_lines, assert_eq!, find_resource!, panic!, from_slice, from_str, to_string_pretty, read_to_string, canonicalize (+2 more)）。

fn config_schema_hides_unsupported_inline_mcp_bearer_token()

作用：这个测试确认 schema 不会告诉用户可以直接在配置里写 bearer_token。这样做是为了避免把访问令牌这类敏感信息写进普通配置文件，推荐改用环境变量名 bearer_token_env_var。

数据流：进去的是 config_schema_json 生成的 schema JSON → 它把 JSON 解码成可查询的数据结构，找到 RawMcpServerConfig 的 properties 字段 → 然后检查里面没有 bearer_token，但有 bearer_token_env_var；如果结果不符合，测试就失败。

调用关系：它是一个针对安全和用户暴露面的专门测试。它依赖 config_schema_json 生成完整 schema，然后只检查 MCP 服务器配置这一小块，保证主 schema 生成逻辑以后改动时，不会意外把暂不支持或不安全的内联令牌字段公开出去。

调用图：外部调用 3 个（assert_eq!, from_slice, config_schema_json）。

fn stdio_mcp(command: &str) -> McpServerConfig

作用：这是测试里用的小帮手，用一个命令名快速造出一个“标准输入输出型 MCP 服务器配置”。MCP 可以理解成让程序连接外部工具服务器的一套接口，这里是为了少写重复的测试配置。

数据流：进去一个命令字符串 → 它把这个命令放进 Stdio 传输配置里，并填好一堆测试用默认值，比如启用、非必需、无超时、无工具限制 → 出来一个完整的 McpServerConfig，不改外部状态。

调用关系：它被多个 MCP allowlist 测试调用，用来快速准备被过滤的服务器样本。它只负责造数据，不做过滤；真正的检查发生在调用它的测试里。

调用图：被 5 处调用（filter_mcp_servers_by_allowlist_allows_all_when_unset, filter_mcp_servers_by_allowlist_blocks_all_when_empty, filter_mcp_servers_by_allowlist_enforces_identity_rules, filter_plugin_mcp_servers_by_allowlist_blocks_unlisted_plugin, filter_plugin_mcp_servers_by_allowlist_enforces_plugin_and_identity_rules）；外部调用 2 个（new, new）。

fn http_mcp(url: &str) -> McpServerConfig

作用：这是测试里另一个 MCP 配置小帮手，用一个网址快速造出一个 HTTP 型 MCP 服务器配置。它让测试能专心验证规则，而不是反复手写配置结构。

数据流：进去一个 URL 字符串 → 它把 URL 放进 StreamableHttp 传输配置，并补齐默认环境、启用状态、工具列表等字段 → 出来一个 McpServerConfig。

调用关系：它被 MCP 服务器 allowlist 和插件选择相关测试使用。它只提供测试样本，后续是否允许、阻止或覆盖，由调用它的测试流程去判断。

调用图：被 5 处调用（filter_mcp_servers_by_allowlist_allows_all_when_unset, filter_mcp_servers_by_allowlist_blocks_all_when_empty, filter_mcp_servers_by_allowlist_enforces_identity_rules, filter_plugin_mcp_servers_by_allowlist_enforces_plugin_and_identity_rules, selected_plugin_wins_after_discovered_plugin_requirements）；外部调用 1 个（new）。

async fn derive_legacy_sandbox_policy_for_test(
    cfg: &ConfigToml,
    sandbox_mode_override: Option<SandboxMode>,
    windows_sandbox_level: WindowsSandboxLevel,
    active_project: Option<&Projec

作用：这个测试帮手把新的权限档案推导成旧版沙箱策略。沙箱策略就是限制程序能访问哪些文件、能不能联网的一组规则。

数据流：进去基础配置、沙箱模式覆盖、Windows 沙箱级别、当前项目和权限约束 → 它先调用配置里的权限推导逻辑，得到 PermissionProfile，再尝试转成旧版 SandboxPolicy → 成功就返回旧策略；失败就记录警告并退回只读策略。

调用关系：它被多个沙箱兼容性测试调用，用来验证新权限系统和旧沙箱表示之间的衔接。它把核心工作交给 derive_permission_profile 和 to_legacy_sandbox_policy。

调用图：调用 1 个内部函数（derive_permission_profile）；被 4 处调用（derive_sandbox_policy_falls_back_to_read_only_for_implicit_defaults, derive_sandbox_policy_preserves_windows_downgrade_for_unsupported_fallback, test_sandbox_config_parsing, test_untrusted_project_gets_workspace_write_sandbox）；外部调用 1 个（new）。

async fn load_config_normalizes_relative_cwd_override() -> std::io::Result<()>

作用：这个测试确认：如果命令行传进来的当前工作目录是相对路径，配置加载后会变成绝对路径。这样后面代码不会因为路径基准不同而找错地方。

数据流：进去一个相对 cwd 覆盖值 nested 和临时 codex_home → 配置加载器把 nested 按当前目录转换成绝对路径 → 测试比较 config.cwd 是否等于预期绝对路径。

调用关系：它直接调用 Config::load_from_base_config_with_overrides，验证配置加载阶段的路径整理行为。

调用图：调用 1 个内部函数（relative_to_current_dir）；外部调用 6 个（default, from, load_from_base_config_with_overrides, assert_eq!, default, tempdir）。

async fn test_toml_parsing()

作用：这个测试检查几类 TOML 配置能不能正确读进内存，特别是 history 和 memories 设置。它也验证旧字段还能按新含义工作。

数据流：进去多段 TOML 字符串 → toml 解析器把它们变成 ConfigToml，再通过配置加载器变成运行时 Config → 测试逐项比较解析结果和最终运行时 memories 配置。

调用关系：它覆盖从文本解析到运行时配置成型的完整小流程，主要依赖 toml::from_str 和 Config::load_from_base_config_with_overrides。

调用图：外部调用 5 个（load_from_base_config_with_overrides, assert!, assert_eq!, default, tempdir）。

fn parses_bundled_skills_config()

作用：这个测试确认 skills 配置里的 bundled 开关和 include_instructions 开关能被正确读出来。skills 可以理解成内置能力包的配置。

数据流：进去一段包含 [skills] 和 [skills.bundled] 的 TOML → 解析成 ConfigToml → 测试确认 bundled.enabled 是 false，include_instructions 也是 false。

调用关系：它只检查 TOML 反序列化这一层，不启动完整配置加载流程。

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

fn tools_web_search_true_deserializes_to_none()

作用：这个测试确认旧的 tools.web_search = true 写法会被解析成 None。这里的 None 表示这个旧开关不再直接形成新配置值。

数据流：进去一段 web_search = true 的 TOML → 解析成 ConfigToml → 测试确认 tools.web_search 没有实际值，其他工具配置也为空。

调用关系：它验证兼容旧配置的解析规则，避免旧字段误触发新的工具配置。

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

fn tools_web_search_false_deserializes_to_none()

作用：这个测试确认旧的 tools.web_search = false 也会被解析成 None。也就是说，无论旧值真假，都不会变成新的 web_search 配置。

数据流：进去一段 web_search = false 的 TOML → 解析成 ConfigToml → 出来时 tools.web_search 为 None。

调用关系：它和 true 版本的测试成对存在，保证旧 web_search 字段的两种写法行为一致。

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

fn tools_experimental_request_user_input_defaults_to_enabled()

作用：这个测试确认只写出 experimental_request_user_input 配置表但不写 enabled 时，默认是开启。这个功能名表示实验性的“请求用户输入”工具。

数据流：进去一个空的 [tools.experimental_request_user_input] TOML 表 → 解析后自动填 enabled = true → 测试比较结果。

调用关系：它只验证解析默认值，后续运行时是否启用由加载配置的测试继续检查。

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

fn tools_experimental_request_user_input_can_be_disabled()

作用：这个测试确认用户可以明确关掉 experimental_request_user_input。这样默认开启不代表不能关闭。

数据流：进去 enabled = false 的 TOML → 解析成 ConfigToml → 测试确认 experimental_request_user_input.enabled 是 false。

调用关系：它和默认开启测试配套，覆盖该工具配置的两种关键状态。

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

async fn load_config_resolves_experimental_request_user_input_enabled() -> std::io::Result<()>

作用：这个测试确认解析到的 experimental_request_user_input 开关会真正影响运行时 Config。也就是不只会读，还会生效。

数据流：进去一个把该功能 enabled 设为 false 的 ConfigToml → 配置加载器合并默认值和覆盖项 → 出来的 config.experimental_request_user_input_enabled 为 false。

调用关系：它接在 TOML 解析测试之后，检查 Config::load_from_base_config_with_overrides 是否把解析结果落到运行时字段。

调用图：外部调用 5 个（load_from_base_config_with_overrides, assert!, default, default, tempdir）。

async fn load_config_resolves_code_mode_config() -> std::io::Result<()>

作用：这个测试确认 code_mode 功能开关和排除的工具命名空间会进入运行时配置。命名空间可以理解成一组工具的分类名。

数据流：进去带 [features.code_mode] 的 TOML → 加载成 Config → 测试确认功能已启用，并且 excluded_tool_namespaces 保存了两个指定名字。

调用关系：它验证功能开关系统和 code_mode 专属配置的衔接。

调用图：外部调用 6 个（load_from_base_config_with_overrides, assert!, assert_eq!, default, tempdir, from_str）。

fn rejects_provider_auth_with_env_key()

作用：这个测试确认模型供应商配置不能同时写 env_key 和 auth 命令。因为两套认证方式同时存在会让凭据来源变得含糊。

数据流：进去一段冲突的模型供应商 TOML → 解析失败并返回错误 → 测试确认错误信息明确指出 provider auth 不能和 env_key 一起用。

调用关系：它只走 TOML 解析层，验证配置校验能尽早挡住不安全或不清楚的写法。

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

fn rejects_provider_aws_for_custom_provider()

作用：这个测试确认 AWS 配置只能用于 amazon-bedrock 这个供应商，不能随便挂到自定义供应商上。AWS 是亚马逊云服务。

数据流：进去一个 custom provider 却带 [aws] 的 TOML → 解析失败 → 测试确认错误说明 AWS 只支持 amazon-bedrock。

调用关系：它验证模型供应商配置的边界，避免用户写出看似有效但实际不支持的组合。

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

fn accepts_amazon_bedrock_aws_profile_override()

作用：这个测试确认 amazon-bedrock 允许覆盖 AWS profile 和 region。profile 是本机 AWS 凭据配置名，region 是云服务区域。

数据流：进去包含 profile 和 region 的 Bedrock TOML → 解析成 ConfigToml → 测试从 model_providers 里取出 AWS 配置并确认值正确。

调用关系：它验证 Bedrock 的特例：普通供应商不能乱配 AWS，但 Bedrock 可以配置这两个字段。

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

async fn load_config_applies_amazon_bedrock_aws_profile_override()

作用：这个测试确认 Bedrock 的 AWS profile 和 region 不只会解析，还会出现在最终运行时模型供应商配置里。

数据流：进去选择 amazon-bedrock 并设置 AWS profile、region 的 TOML → 配置加载器生成运行时 Config → 测试确认当前 provider 是 amazon-bedrock，且 AWS 字段保留下来。

调用关系：它把上一条解析测试推进到完整加载流程，检查最终 Config.model_provider。

调用图：外部调用 4 个（load_from_base_config_with_overrides, assert_eq!, default, tempdir）。

async fn load_config_rejects_unsupported_amazon_bedrock_overrides()

作用：这个测试确认 amazon-bedrock 只能改 AWS profile 和 region，不能改名字、base_url 等其他供应商字段。这样可以避免内置供应商被半改坏。

数据流：进去一段带多个不支持覆盖字段的 Bedrock TOML → 加载配置时失败 → 测试确认错误类型是 InvalidData，并且错误信息说明只支持改 aws.profile 和 aws.region。

调用关系：它检查完整配置加载阶段的校验，因为有些限制需要在合并默认供应商后才能判断。

调用图：外部调用 5 个（load_from_base_config_with_overrides, assert!, assert_eq!, default, tempdir）。

fn config_toml_deserializes_model_availability_nux()

作用：这个测试确认 TUI 里“模型可用性新手提示”的显示次数表能被读出来。TUI 是终端用户界面，就是命令行里的交互界面。

数据流：进去 [tui.model_availability_nux] 的 TOML 映射 → 解析成 ConfigToml → 测试确认不同模型名对应的 shown_count 数字正确，其他 TUI 字段使用默认值。

调用关系：它只验证 TUI 配置的文本解析和默认值填充。

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

fn config_toml_status_line_use_colors_defaults_to_enabled()

作用：这个测试确认状态栏颜色默认开启。状态栏就是终端界面底部或顶部显示状态信息的区域。

数据流：进去一个空的 [tui] 表 → 解析时填入默认值 → 测试确认 status_line_use_colors 为 true。

调用关系：它验证 TUI 默认体验，不涉及完整配置加载。

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

fn config_toml_deserializes_status_line_use_colors_disabled()

作用：这个测试确认用户可以关闭状态栏颜色。这样在不支持颜色或不喜欢颜色的终端里能按配置生效。

数据流：进去 status_line_use_colors = false 的 TOML → 解析成 ConfigToml → 测试确认该字段为 false。

调用关系：它和默认开启测试配对，覆盖颜色开关的可配置性。

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

fn config_toml_deserializes_terminal_resize_reflow_config()

作用：这个测试确认终端尺寸变化时重新排版的最大行数能被配置。重新排版就是窗口变宽变窄后重新整理显示文本。

数据流：进去 terminal_resize_reflow_max_rows = 9000 的 TOML → 解析成 ConfigToml → 测试确认 TUI 配置里保存了 Some(9000)。

调用关系：它验证一个具体 TUI 数值选项的解析。

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

async fn runtime_config_defaults_model_availability_nux()

作用：这个测试确认如果用户没写模型可用性提示配置，运行时会使用默认值。这样程序不会因为缺配置而出现空洞状态。

数据流：进去默认 ConfigToml 和默认覆盖项 → 配置加载器生成运行时 Config → 测试确认 model_availability_nux 等于默认配置。

调用关系：它检查完整加载后的默认值，而不是单纯 TOML 解析。

调用图：外部调用 5 个（load_from_base_config_with_overrides, assert_eq!, default, default, tempdir）。

fn test_tui_vim_mode_default_defaults_to_false()

作用：这个测试确认 TUI 的 Vim 模式默认关闭。Vim 模式是类似 Vim 编辑器的一套键盘操作习惯。

数据流：进去空 [tui] TOML → 解析后填默认值 → 测试确认 vim_mode_default 是 false。

调用关系：它验证界面键位习惯不会在用户没要求时自动启用。

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

fn test_tui_vim_mode_default_true()

作用：这个测试确认用户可以把 TUI 的 Vim 模式默认打开。

数据流：进去 vim_mode_default = true 的 TOML → 解析成 ConfigToml → 测试确认字段为 true。

调用关系：它和默认关闭测试一起覆盖 Vim 模式开关。

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

fn test_tui_raw_output_mode_defaults_to_false()

作用：这个测试确认原始输出模式默认关闭。原始输出模式通常表示少做界面美化或加工，更接近原始文本。

数据流：进去空 [tui] TOML → 解析后填默认值 → 测试确认 raw_output_mode 是 false。

调用关系：它验证默认界面行为保持正常加工显示。

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

fn test_tui_raw_output_mode_true()

作用：这个测试确认用户可以打开 TUI 原始输出模式。

数据流：进去 raw_output_mode = true 的 TOML → 解析成 ConfigToml → 测试确认字段为 true。

调用关系：它检查 TOML 层的开关解析，后面还有运行时加载测试确认它会生效。

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

async fn runtime_config_uses_tui_raw_output_mode()

作用：这个测试确认 raw_output_mode 解析后会进入最终运行时配置。也就是说界面真正会看到这个开关。

数据流：进去 raw_output_mode = true 的 ConfigToml → 配置加载器生成 Config → 测试确认 cfg.tui_raw_output_mode 为 true。

调用关系：它承接解析测试，验证 Config::load_from_base_config_with_overrides 的合并和落地。

调用图：外部调用 5 个（load_from_base_config_with_overrides, assert!, default, tempdir, from_str）。

fn config_toml_deserializes_permission_profiles()

作用：这个测试确认复杂的权限档案能被 TOML 正确读出来。权限档案是一套预设规则，说明文件哪里能读写、网络哪里能连。

数据流：进去一大段 permissions TOML，里面有默认档案、工作区根目录、文件权限、网络代理、域名规则和 MITM 规则 → 解析成 ConfigToml → 测试逐项比较所有嵌套结构和值。

调用关系：它是权限配置解析的基础测试，后续运行时权限测试都建立在这些结构能正确解析之上。

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

fn config_toml_rejects_empty_mitm_action_reference_list()

作用：这个测试确认 MITM hook 的 action 列表不能为空。MITM hook 是匹配某些网络请求后执行改写动作的规则，空动作容易造成误解。

数据流：进去 action = [] 的 TOML → 解析失败 → 测试确认错误提示 action must not be empty。

调用关系：它验证网络改写规则采用“失败关闭”的安全思路：写错就拒绝，而不是默默放行。

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

fn config_toml_rejects_empty_mitm_action_definition()

作用：这个测试确认 MITM action 本身必须至少定义一个操作，比如删请求头或加请求头。空定义没有实际意义，也可能隐藏配置错误。

数据流：进去一个空的 actions.strip_auth TOML 表 → 解析失败 → 测试确认错误说明必须至少定义一个 operation。

调用关系：它和空 action 引用列表测试一起，守住 MITM 配置的安全边界。

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

fn permissions_profile_network_to_proxy_config_preserves_mitm_hooks()

作用：这个测试确认权限档案里的网络 MITM 规则转换成代理配置时不会丢失。代理配置就是真正控制网络代理如何工作的运行时设置。

数据流：进去手工构造的 NetworkToml，里面有一个 hook 和一个 action → 调用 to_network_proxy_config → 测试确认网络模式、MITM 开关、hook 主机、方法和删请求头动作都还在。

调用关系：它检查从配置模型到代理运行配置的转换函数，确保安全检查规则能被带到实际代理里。

调用图：外部调用 7 个（from, new, assert!, assert_eq!, default, default, vec!）。

fn permissions_profile_network_to_proxy_config_preserves_mitm_hook_declaration_order()

作用：这个测试确认多个 MITM hook 转成代理配置后仍按用户声明顺序排列。顺序重要，因为更具体的规则可能需要先匹配。

数据流：进去两个 hook 的 TOML，名字顺序不是字母排序意图 → 解析后取出 network，再转换成 proxy config → 测试确认第一个 hook 仍是更具体的 /repos/openai/，第二个是 /repos/。

调用关系：它验证配置解析使用能保序的数据结构，并且 to_network_proxy_config 转换时不打乱顺序。

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

async fn permissions_profiles_proxy_policy_does_not_start_managed_network_proxy_without_feature() -> std::io::Result<()>

作用：这个测试确认只在权限档案里写 network.enabled，不会自动启动托管网络代理。托管代理是程序自己启动的本地网络管道。

数据流：进去一个启用网络但没开启 network_proxy 功能的权限档案 → 加载配置 → 测试确认网络沙箱策略是 Enabled，但 config.permissions.network 仍是 None。

调用关系：它验证“允许联网”和“启动代理”是两件事，启动代理还需要额外功能开关。

调用图：外部调用 8 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access, write）。

async fn permissions_profiles_proxy_policy_starts_managed_network_proxy() -> std::io::Result<()>

作用：这个测试名字看似说会启动代理，但当前断言确认：没有 network_proxy 功能时，即使配置了 proxy_url，也不会启动托管代理。它守住功能开关的边界。

数据流：进去启用网络并写了 proxy_url、enable_socks5=false 的权限档案，但没开功能开关 → 加载配置 → 网络沙箱为 Enabled，实际托管代理配置仍为空。

调用关系：它和上一条测试一起说明：权限档案可表达代理策略，但是否真正启动代理由 feature 控制。

调用图：外部调用 8 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access, write）。

async fn network_proxy_feature_is_no_op_without_sandbox_network() -> std::io::Result<()>

作用：这个测试确认只打开 network_proxy 功能，但沙箱网络本身没放开时，不会启动代理。因为没有联网权限，代理也不该绕过限制。

数据流：进去 features.network_proxy = true，但没有开启网络访问 → 加载配置 → 测试确认网络策略仍是 Restricted，托管代理仍为空。

调用关系：它验证 network_proxy 功能不会单独改变网络权限，只在网络已允许时才可能工作。

调用图：外部调用 6 个（default, new, load_from_base_config_with_overrides, assert!, assert_eq!, from_str）。

async fn network_proxy_feature_matrix_preserves_sandbox_network_semantics() -> std::io::Result<()>

作用：这个测试用一张小矩阵确认：无论用新权限档案还是旧 workspace-write 配置，network_proxy 开关都不能改变“网络是否允许”的语义。

数据流：进去多组组合：配置来源、新旧写法、network_enabled 真或假、proxy_enabled 真或假 → 每组加载一次 Config → 测试确认网络沙箱策略只跟 network_enabled 有关，而托管代理只在 network_enabled 和 proxy_enabled 都为真时出现。

调用关系：它集中覆盖新旧两套配置入口，确保功能开关只控制代理启动，不偷偷放宽沙箱。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert_eq!, Access, write）。

async fn network_proxy_cli_overrides_merge_toggle_with_proxy_config() -> std::io::Result<()>

作用：这个测试确认命令行覆盖项能同时打开 network_proxy，并覆盖代理细节，比如关闭 SOCKS5。SOCKS5 是一种代理协议。

数据流：先在临时配置文件里写 workspace-write 且允许网络 → 再通过 CLI 覆盖打开 features.network_proxy.enabled，并设置 enable_socks5=false → 构建 Config → 测试确认网络允许、代理地址为默认 127.0.0.1:3128、SOCKS5 关闭。

调用关系：它使用 ConfigBuilder 而不是直接加载基础配置，专门验证文件配置和命令行覆盖的合并行为。

调用图：调用 1 个内部函数（without_managed_config_for_tests）；外部调用 6 个（default, new, assert!, assert_eq!, write, vec!）。

async fn experimental_network_requirements_enable_proxy_without_feature() -> std::io::Result<()>

作用：这个测试确认企业下发的 experimental_network 要求可以配置托管代理，即使普通 network_proxy 功能开关没开。企业要求可以理解成管理员强制配置。

数据流：进去一个带 experimental_network.enabled = true 的云端配置包 → ConfigBuilder 加载 → 测试确认 Feature::NetworkProxy 没开，但 managed_network_requirements_enabled 为真，而且 permissions.network 里代理已启用。

调用关系：它验证企业/云端要求走的是独立通道，不依赖普通用户功能开关。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 2 个（new, assert!）。

async fn network_proxy_feature_uses_profile_network_proxy_settings() -> std::io::Result<()>

作用：这个测试确认当 network_proxy 功能开启时，会使用权限档案里写的代理地址和 SOCKS5 设置。

数据流：进去开启 network_proxy、默认权限档案启用网络、proxy_url 为 127.0.0.1:43128、enable_socks5=false 的配置 → 加载 Config → 测试确认网络允许，托管代理存在，地址和 SOCKS5 状态都按档案设置。

调用关系：它验证功能开关打开后，权限档案里的代理细节会被转成运行时网络代理配置。

调用图：外部调用 8 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access, from_str）。

async fn disabled_network_proxy_feature_does_not_start_profile_proxy_policy() -> std::io::Result<()>

作用：这个测试确认显式关闭 network_proxy 时，即使权限档案里写了代理配置，也不会启动托管代理。

数据流：进去 features.network_proxy.enabled=false，同时权限档案启用网络并配置 proxy_url → 加载 Config → 测试确认功能未启用，permissions.network 为空。

调用关系：它和开启功能的测试成对，证明功能开关优先控制代理是否启动。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert!, Access, from_str）。

async fn permissions_profiles_network_disabled_by_default_does_not_start_proxy() -> std::io::Result<()>

作用：这个测试确认权限档案只写域名规则但没显式启用网络时，默认不会启动代理。默认关闭更安全。

数据流：进去一个网络部分只包含 openai.com allow 规则、没有 enabled=true 的权限档案 → 加载 Config → 测试确认 permissions.network 是 None。

调用关系：它验证网络配置里出现规则不等于打开网络或代理，必须有明确启用信号。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert!, Access, write）。

async fn default_permissions_profile_populates_runtime_sandbox_policy() -> std::io::Result<()>

作用：这个测试确认默认权限档案会生成运行时文件系统和网络沙箱规则。它重点检查哪些路径能读写，以及旧版沙箱投影是否合理。

数据流：进去一个 dev 权限档案：最小路径只读、工作区根可写、docs 只读 → 加载 Config → 测试确认运行时文件系统策略包含这些规则，旧版策略是 workspace-write 但没有额外 writable_roots，.git 不能写，网络受限，活动档案是 dev。

调用关系：它是权限档案从配置变成实际沙箱政策的核心测试，连接 Config 加载、文件系统权限判断和旧版 SandboxPolicy 投影。

调用图：外部调用 10 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access, Scoped, create_dir_all, write）。

async fn default_permissions_extended_profile_preserves_parent_metadata() -> std::io::Result<()>

作用：这个测试确认权限档案继承时，运行时仍记得当前档案继承自哪个父档案。继承就是 dev 可以复用 base 的规则。

数据流：进去两个权限档案：base 定义文件权限，dev extends base → 加载 Config → 测试确认 active_permission_profile 的 id 是 dev，extends 是 base。

调用关系：它验证合并父档案规则时不会丢掉元信息，方便界面或诊断显示当前权限来源。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert_eq!, Access, write）。

async fn permission_profile_override_populates_runtime_permissions() -> std::io::Result<()>

作用：这个测试确认测试/命令行覆盖的 PermissionProfile 会直接成为运行时有效权限。这里使用 Disabled，表示不启用沙箱限制。

数据流：进去默认配置，但覆盖项里指定 permission_profile = Disabled → 加载 Config → 测试确认有效权限就是 Disabled，没有活动命名档案，旧版沙箱是 DangerFullAccess。

调用关系：它验证 ConfigOverrides.permission_profile 的优先级高于普通配置档案。

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

fn permission_snapshot_setter_preserves_permission_constraints()

作用：这个测试确认从会话快照恢复权限时，不能突破已有约束。约束就像上级规定的边界，比如只能使用只读权限。

数据流：先创建一个只能使用 read_only 档案的 Permissions → 尝试从会话快照设置成 workspace_write → 设置失败，返回 ConstraintError，原来的只读权限和活动档案状态保持不变。

调用关系：它直接测试 Permissions 的快照恢复入口，确保会话恢复不会把受管限制绕过去。

调用图：调用 7 个内部函数（new, allow_any, allow_only, from_approval_and_profile, active, read_only, workspace_write）；外部调用 2 个（assert!, assert_eq!）。

async fn permission_profile_override_preserves_managed_unrestricted_filesystem() -> std::io::Result<()>

作用：这个测试确认托管权限档案里的“不限制文件系统，但限制网络”能保留下来。托管表示这些权限可能来自外部管理策略。

数据流：进去一个 Managed 权限：文件系统 Unrestricted，网络 Restricted → 加载 Config → 测试确认有效权限没变，旧版沙箱投影成 ExternalSandbox 且网络受限。

调用关系：它验证新权限模型里较细的表达，转换到旧沙箱时仍尽量保留关键安全含义。

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

async fn managed_unrestricted_permission_profile_still_enables_network_requirements() -> std::io::Result<()>

作用：这个测试确认即使托管权限在旧版投影里看起来像完全开放，网络管理要求仍能被识别。它防止旧表示丢失新策略的重要信息。

数据流：先加载一个 Managed 权限：文件系统不限制、网络允许 → 旧版沙箱显示 DangerFullAccess → 测试再手工把配置层里的网络要求设为 enabled → 重建 ConfigLayerStack → 确认 managed_network_requirements_enabled 为真。

调用关系：它测试配置层栈和托管网络要求的交互，说明不能只看 legacy_sandbox_policy 来判断全部安全策略。

调用图：调用 2 个内部函数（new, new）；外部调用 6 个（default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default）。

async fn permission_profile_override_keeps_memories_root_out_of_legacy_projection() -> std::io::Result<()>

作用：这个测试确认覆盖权限档案时，不会把 memories 目录错误地加入旧版可写路径。memories 目录是程序保存记忆数据的地方。

数据流：进去一个运行时权限：根目录只读、项目根可写、网络受限 → 加载 Config → 测试确认 codex_home/memories 不能写，旧版沙箱投影仍是 workspace-write 且 writable_roots 为空。

调用关系：它防止新权限到旧策略转换时意外扩大可写范围，尤其是用户数据目录。

调用图：调用 2 个内部函数（from_runtime_permissions, restricted）；外部调用 7 个（default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default, vec!）。

async fn permission_profile_override_preserves_configured_network_policy_without_starting_proxy() -> std::io::Result<()>

作用：这个测试确认当权限被覆盖成 Disabled 时，配置里的网络代理策略不会因此自动启动代理。也就是说覆盖权限不该意外激活另一套网络组件。

数据流：进去一个权限档案，里面启用网络、写了 proxy_url、域名规则等；同时覆盖 permission_profile 为 Disabled → 加载 Config → 测试确认托管网络代理为空，有效权限是 Disabled。

调用关系：它验证权限覆盖和网络代理启动之间的边界，避免因为配置里有代理字段就越过覆盖后的权限选择。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access）。

async fn workspace_root_glob_none_compiles_to_filesystem_pattern_entry() -> std::io::Result<()>

作用：测试在工作区根目录规则里写通配符时，系统会把它当成真正的文件匹配规则，而不是普通的字面路径。这样像 **/*.env 这种“所有 env 文件”的规则才会真的生效。

数据流：输入是一个临时配置：默认权限档案叫 dev，工作区根目录里允许写当前目录，但拒绝 **/*.env。测试还提供当前目录和额外工作区目录 → 配置加载器把这些规则展开到每个工作区根目录，并生成文件系统沙盒策略 → 输出是配置对象；测试确认扫描深度保留为 2，两个根目录下都出现了拒绝 env 文件的通配符规则，并且没有被误存成普通的特殊路径子项。

调用关系：测试运行器调用它；它把主要工作交给 Config::load_from_base_config_with_overrides 来加载配置，再用路径解析和断言检查权限策略是否按预期生成。

调用图：调用 1 个内部函数（resolve_path_against_base）；外部调用 9 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Scoped, write, vec!）。

async fn permissions_profiles_require_default_permissions() -> std::io::Result<()>

作用：测试如果配置里声明了权限档案，就必须同时指定默认使用哪一个。否则系统不知道该拿哪套门禁规则上岗，应该直接报错。

数据流：输入是一个有 [permissions] 档案但没有 default_permissions 的配置 → 配置加载器尝试解析时发现缺少默认档案 → 输出是一个 InvalidInput 错误；测试确认错误信息明确说明定义了权限档案却没有设置默认权限。

调用关系：测试运行器调用它；它专门验证 Config::load_from_base_config_with_overrides 的错误路径，防止配置加载器默默选择错误默认值。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert_eq!, Access, write）。

async fn default_permissions_can_select_builtin_profile_without_permissions_table() -> std::io::Result<()>

作用：测试不用自定义权限表，也可以直接用内置权限档案。这里检查内置的工作区权限档案能让项目根目录可写，同时保护 .git 这类项目元数据。

数据流：输入是只设置 default_permissions 为内置 :workspace 的配置 → 配置加载器选择内置档案，生成文件系统沙盒策略 → 输出是配置对象；测试确认这是显式选择的权限档案、没有自定义档案，并且当前项目根目录可写但 .git 不可写。

调用关系：测试运行器调用它；它通过配置加载器进入真实的权限解析流程，再询问生成的策略能不能写指定路径。

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

async fn default_permissions_read_only_keeps_add_dir_read_only() -> std::io::Result<()>

作用：测试选择内置只读档案时，即使运行时额外传入“可写根目录”，也不能变成可写。只读就是只读，不能被附加目录悄悄放宽。

数据流：输入是默认权限为内置 :read-only，并带一个额外可写目录的覆盖参数 → 配置加载器生成只读策略 → 输出是配置对象；测试确认额外目录仍然不可写，并且当前激活的权限档案确实是只读档案。

调用关系：测试运行器调用它；它用配置加载器合并配置和运行时覆盖项，然后检查权限策略没有被覆盖项错误放宽。

调用图：外部调用 6 个（default, new, load_from_base_config_with_overrides, assert!, assert_eq!, vec!）。

async fn workspace_profile_applies_rules_to_runtime_and_profile_workspace_roots() -> std::io::Result<()>

作用：测试工作区规则会同时作用在运行时传入的工作区根目录，以及权限档案自己声明的工作区根目录上。这样多目录项目不会只有一部分目录被正确保护。

数据流：输入是三个临时目录：当前目录、运行时额外根目录、档案里声明的根目录；配置要求工作区根可写，但 .git 和 .codex 只读 → 配置加载器合并这些根目录并生成沙盒规则 → 输出是配置对象；测试确认运行时根目录列表、有效根目录列表、档案根目录列表分别正确，并且每个根目录本身可写，元数据目录不可写。

调用关系：测试运行器调用它；它依赖配置加载器把配置档案和运行时参数拼在一起，再用策略查询函数检查每个目录的最终权限。

调用图：外部调用 9 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Scoped, create_dir_all, vec!）。

async fn explicit_builtin_workspace_profile_ignores_legacy_workspace_write_settings() -> std::io::Result<()>

作用：测试当用户明确选择新版内置 :workspace 权限档案时，旧版 sandbox_workspace_write 设置不会再混进来。这样新旧配置不会叠加出意外的额外写权限或网络权限。

数据流：输入是显式默认权限 :workspace，同时旧版沙盒配置里写了额外可写目录和网络访问 → 配置加载器优先采用新版权限档案 → 输出是配置对象；测试确认网络仍是受限的，旧版额外目录没有变成直接放行项。

调用关系：测试运行器调用它；它检查配置加载器在新版显式权限档案和旧版沙盒字段冲突时，选择新版规则而不是混用。

调用图：外部调用 6 个（default, new, load_from_base_config_with_overrides, assert!, assert_eq!, vec!）。

async fn default_permissions_profile_can_extend_builtin_workspace() -> std::io::Result<()>

作用：测试自定义权限档案可以继承内置工作区档案，并在此基础上改一部分规则，比如打开网络、把临时目录从可写改成只读。

数据流：输入是自定义档案 workspace-with-network，它继承 :workspace，额外设置 :tmpdir 只读并启用网络 → 配置加载器先拿到父档案规则，再用子档案规则覆盖对应项 → 输出是配置对象；测试确认项目根目录仍可写、.git 仍受保护、继承的 /tmp 写权限保留、tmpdir 写权限被只读替换、网络已启用，并记录了激活档案及其父档案。

调用关系：测试运行器调用它；它验证配置加载器的“继承加覆盖”逻辑，尤其是子档案能替换父档案同一路径规则。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access）。

async fn default_permissions_profile_can_extend_builtin_read_only() -> std::io::Result<()>

作用：测试自定义权限档案可以继承内置只读档案，同时只打开网络，不会顺手获得写文件能力。

数据流：输入是自定义档案 read-only-with-network，继承 :read-only 并启用网络 → 配置加载器生成继承后的权限策略 → 输出是配置对象；测试确认当前目录可读但不可写，网络策略为启用，并记录了激活档案和继承来源。

调用关系：测试运行器调用它；它通过配置加载器检查只读父档案的文件限制会保留，网络设置可以单独被子档案改变。

调用图：外部调用 6 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!）。

async fn empty_config_defaults_to_builtin_profile_for_trusted_project() -> std::io::Result<()>

作用：测试没有显式权限配置时，受信任项目会自动落到合理的内置权限档案。非 Windows 下通常是工作区可写；Windows 因沙盒支持限制会保持只读。

数据流：输入是一个只标记当前项目为 Trusted 的配置 → 配置加载器根据项目信任等级和操作系统选择默认权限 → 输出是配置对象；测试确认激活档案名符合平台预期，并检查非 Windows 下项目根可写且 .codex 受保护，Windows 下保持不可写。

调用关系：测试运行器调用它；它验证配置加载器在“用户没写权限档案”时的自动兜底选择。

调用图：外部调用 7 个（default, from, new, load_from_base_config_with_overrides, assert!, assert_eq!, cfg!）。

async fn empty_config_defaults_to_builtin_profile_for_untrusted_project() -> std::io::Result<()>

作用：测试没有显式权限配置时，未受信任项目也会得到安全的默认权限。它至少允许读取项目，但平台不同会影响是否允许工作区写入。

数据流：输入是一个只标记当前项目为 Untrusted 的配置 → 配置加载器根据默认策略和操作系统生成权限 → 输出是配置对象；测试确认档案名符合平台预期、当前目录可读，并按平台检查是否可写及元数据保护。

调用关系：测试运行器调用它；它覆盖未受信任项目的默认权限路径，确保默认值不会变成完全开放。

调用图：外部调用 7 个（default, from, new, load_from_base_config_with_overrides, assert!, assert_eq!, cfg!）。

async fn implicit_builtin_workspace_profile_preserves_sandbox_workspace_write_settings() -> std::io::Result<()>

作用：测试当系统隐式选择工作区权限时，旧版沙盒里的额外可写目录和网络设置仍会被保留下来。这样老用户不显式迁移配置，也不会突然丢权限。

数据流：输入是受信任项目配置、旧版 sandbox_workspace_write 设置、Windows 沙盒提升配置和一个额外可写目录 → 配置加载器走隐式工作区兼容路径 → 输出是配置对象；测试确认额外目录可写、网络启用、不能简单标记为某个纯内置激活档案，并且旧版沙盒投影里保留了原来的可写目录和排除选项。

调用关系：测试运行器调用它；它检查新权限系统对旧版沙盒配置的兼容桥接，失败时会直接 panic! 暴露结果类型不对。

调用图：外部调用 8 个（default, from, new, load_from_base_config_with_overrides, assert!, assert_eq!, panic!, vec!）。

async fn implicit_builtin_workspace_profile_preserves_add_dir_metadata_carveouts() -> std::io::Result<()>

作用：测试隐式工作区权限处理额外可写目录时，仍会保护 .git、.agents、.codex 这些元数据目录。也就是说目录可以写，但里面的关键控制区不能随便改。

数据流：输入是受信任项目和运行时额外可写根目录，额外目录里事先建好几个元数据子目录 → 配置加载器生成兼容的工作区写策略 → 输出是配置对象；测试确认额外根目录本身可写，但这些元数据子目录都不可写。

调用关系：测试运行器调用它；它验证配置加载器在处理运行时追加目录时，会继续应用旧版元数据保护规则。

调用图：外部调用 7 个（default, from, new, load_from_base_config_with_overrides, assert!, create_dir_all, vec!）。

async fn empty_config_defaults_to_builtin_read_only_without_trust_decision() -> std::io::Result<()>

作用：测试完全没有项目信任判断时，默认应该是只读。这样系统在不知道项目是否安全时，不会贸然给写权限。

数据流：输入是空配置和当前目录 → 配置加载器选择默认只读权限 → 输出是配置对象；测试确认当前目录可读但不可写。

调用关系：测试运行器调用它；它覆盖最保守的默认配置路径，确保没有信任信息时不会放宽权限。

调用图：外部调用 5 个（default, new, load_from_base_config_with_overrides, assert!, default）。

async fn default_permissions_can_select_builtin_full_access_profile() -> std::io::Result<()>

作用：测试可以通过新版内置权限名选择完全访问档案。这个档案相当于关闭沙盒，所以必须确认名字和结果都明确对应。

数据流：输入是 default_permissions 设为内置危险全访问档案 → 配置加载器生成禁用权限限制的档案 → 输出是配置对象；测试确认有效权限档案是 Disabled，并且激活档案名是危险全访问档案。

调用关系：测试运行器调用它；它检查配置加载器能识别当前支持的全访问内置档案名。

调用图：外部调用 4 个（default, new, load_from_base_config_with_overrides, assert_eq!）。

async fn legacy_danger_no_sandbox_is_rejected() -> std::io::Result<()>

作用：测试旧的 :danger-no-sandbox 名字不再被接受。这样用户不会继续使用已经废弃或语义不清的危险别名。

数据流：输入是 default_permissions = ":danger-no-sandbox" → 配置加载器查找内置档案名失败 → 输出是错误；测试确认错误信息说这是未知内置档案。

调用关系：测试运行器调用它；它验证配置加载器拒绝旧别名，而不是悄悄映射到全访问。

调用图：外部调用 4 个（default, new, load_from_base_config_with_overrides, assert_eq!）。

async fn user_defined_permission_profile_names_cannot_use_builtin_prefix() -> std::io::Result<()>

作用：测试用户自定义权限档案不能用冒号开头的内置前缀。这样自定义名字不会和系统保留名字混在一起。

数据流：输入是名为 :custom 的用户档案，并把它设为默认 → 配置加载器发现名字用了保留前缀 → 输出是 InvalidInput 错误；测试确认错误信息指出这个档案名占用了内置前缀。

调用关系：测试运行器调用它；它检查配置加载器在读取自定义权限表时会先做命名规则校验。

调用图：外部调用 6 个（from, default, new, load_from_base_config_with_overrides, assert_eq!, default）。

async fn unknown_builtin_permission_profile_name_is_rejected() -> std::io::Result<()>

作用：测试冒号开头但系统不认识的内置权限名会被拒绝。这样拼错的权限名不会被默默当成别的配置。

数据流：输入是 default_permissions = ":unknown" → 配置加载器尝试按内置档案解析但找不到 → 输出是 InvalidInput 错误；测试确认错误信息包含未知档案名。

调用关系：测试运行器调用它；它验证配置加载器对内置档案名的白名单检查。

调用图：外部调用 4 个（default, new, load_from_base_config_with_overrides, assert_eq!）。

async fn permissions_profiles_allow_direct_write_roots_outside_workspace_root() -> std::io::Result<()>

作用：测试权限档案可以直接给工作区外的绝对目录写权限。这个能力用于明确允许某些外部目录，但必须只在用户写明时发生。

数据流：输入是自定义 dev 档案，文件系统规则里直接写了一个工作区外的绝对路径并给写权限 → 配置加载器把这个路径加入沙盒策略 → 输出是配置对象；测试确认自定义档案摘要正确、外部目录可写，并且旧版沙盒投影也包含这个可写根目录且网络关闭。

调用关系：测试运行器调用它；它通过配置加载器验证显式绝对路径授权能同时反映到新版权限策略和旧版沙盒表示。

调用图：调用 1 个内部函数（from_absolute_path）；外部调用 9 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, Access, canonicalize, write）。

async fn permissions_profiles_reject_nested_entries_for_non_workspace_roots() -> std::io::Result<()>

作用：测试只有支持“子规则”的特殊路径才能写嵌套规则。像 :minimal 这种不支持子项的路径，如果再写 docs 子规则，应该报错。

数据流：输入是 dev 权限档案，给 :minimal 配了一个嵌套的 docs 只读规则 → 配置加载器发现这个特殊路径不支持嵌套项 → 输出是 InvalidInput 错误；测试确认错误信息准确指出 :minimal 不支持嵌套。

调用关系：测试运行器调用它；它验证配置加载器对权限配置结构的合法性检查，避免用户写出看似生效其实无法解释的规则。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert_eq!, Scoped, write）。

async fn load_workspace_permission_profile(
    profile: PermissionProfileToml,
) -> std::io::Result<Config>

作用：这是本测试文件里的小帮手，用来快速加载一个名为 dev 的权限档案。它减少重复代码，让后面的几个测试只关心档案内容本身。

数据流：输入是一个 PermissionProfileToml 权限档案对象 → 函数创建临时 Codex 主目录和当前目录，并在当前目录放一个 .git 标记，然后把这个档案包装成完整配置 → 输出是 Config::load_from_base_config_with_overrides 返回的配置加载结果，可能成功也可能报错。

调用关系：它被 permissions_profiles_allow_empty_filesystem_with_warning、permissions_profiles_allow_missing_filesystem_with_warning、permissions_profiles_allow_unknown_special_paths、permissions_profiles_allow_unknown_special_paths_with_nested_entries 调用；这些测试把不同档案交给它，再检查加载后的策略和警告。

调用图：被 4 处调用（permissions_profiles_allow_empty_filesystem_with_warning, permissions_profiles_allow_missing_filesystem_with_warning, permissions_profiles_allow_unknown_special_paths, permissions_profiles_allow_unknown_special_paths_with_nested_entries）；外部调用 5 个（from, default, new, load_from_base_config_with_overrides, write）。

async fn permissions_profiles_allow_unknown_special_paths() -> std::io::Result<()>

作用：测试遇到当前版本不认识的特殊路径时，配置加载不会崩溃，而是保留为未知项并给出启动警告。这样新版本写出的配置在旧版本里至少能被温和处理。

数据流：输入是一个包含 :future_special_path 只读规则的 dev 档案 → helper 加载配置，配置加载器把它记为未知特殊路径 → 输出是配置对象；测试确认沙盒策略里有未知特殊路径项、旧版沙盒投影退成只读，并且启动警告提示这个路径当前版本不认识会被忽略。

调用关系：测试运行器调用它；它把配置准备工作交给 load_workspace_permission_profile，重点检查未知特殊路径的兼容行为。

调用图：调用 1 个内部函数（load_workspace_permission_profile）；外部调用 4 个（from, assert!, assert_eq!, Access）。

async fn permissions_profiles_allow_unknown_special_paths_with_nested_entries() -> std::io::Result<()>

作用：测试未知特殊路径即使带了子路径规则，也不会让配置加载失败，而是带着子路径一起标成未知并警告。这样未来配置格式更容易向前兼容。

数据流：输入是 :future_special_path 下嵌套 docs 只读的 dev 档案 → helper 加载配置，配置加载器把未知特殊路径和子路径一起记录 → 输出是配置对象；测试确认沙盒策略里有带 docs 子路径的未知项，并且启动警告说明这个组合当前版本不认识。

调用关系：测试运行器调用它；它依赖 load_workspace_permission_profile 建好标准测试环境，再验证未知嵌套路径的处理方式。

调用图：调用 1 个内部函数（load_workspace_permission_profile）；外部调用 4 个（from, assert!, assert_eq!, Scoped）。

async fn permissions_profiles_allow_missing_filesystem_with_warning() -> std::io::Result<()>

作用：测试权限档案完全没写文件系统规则时，加载仍然成功，但会警告用户这套档案没有任何当前版本认识的文件规则。

数据流：输入是 dev 档案，filesystem 字段为空 → helper 加载配置，配置加载器生成空的受限文件系统策略 → 输出是配置对象；测试确认策略为空、旧版沙盒投影为只读且网络关闭，并出现缺少有效文件系统条目的警告。

调用关系：测试运行器调用它；它通过 load_workspace_permission_profile 走正常加载流程，验证“空文件权限”是可接受但会提醒的状态。

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

async fn permissions_profiles_allow_empty_filesystem_with_warning() -> std::io::Result<()>

作用：测试文件系统规则表存在但为空时，行为和没写规则类似：不报错，但给出警告。这样用户能发现自己写了一个实际上没有放行任何路径的档案。

数据流：输入是 dev 档案，filesystem.entries 是空表 → helper 加载配置，配置加载器生成空的受限策略 → 输出是配置对象；测试确认策略为空，并且启动警告提示 dev 档案没有当前版本认识的文件系统条目。

调用关系：测试运行器调用它；它复用 load_workspace_permission_profile，专门覆盖“空表”和“字段缺失”之间的细微差别。

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

async fn permissions_profiles_reject_workspace_root_parent_traversal() -> std::io::Result<()>

作用：测试工作区根目录的子路径规则不能用 .. 跳到父目录或兄弟目录。这样配置不能借“工作区子路径”的名义越界访问外部位置。

数据流：输入是 dev 权限档案，在 :workspace_roots 下写了 ../sibling 只读 → 配置加载器检查子路径时发现包含父目录跳转 → 输出是 InvalidInput 错误；测试确认错误信息要求子路径必须是干净的后代路径，不能含 . 或 ..。

调用关系：测试运行器调用它；它验证配置加载器的路径安全检查，防止权限规则通过相对路径逃出工作区。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert_eq!, Scoped, write）。

async fn permissions_profiles_allow_network_enablement() -> std::io::Result<()>

作用：测试自定义权限档案可以明确打开网络访问。网络权限是高风险开关，所以需要确认只有配置写明时才会启用。

数据流：输入是 dev 档案，文件系统只有最小只读规则，网络字段 enabled = true → 配置加载器生成权限策略 → 输出是配置对象；测试确认网络沙盒策略处于启用状态，旧版沙盒投影也显示有完整网络访问。

调用关系：测试运行器调用它；它通过配置加载器验证新版网络权限会正确同步到旧版沙盒表示。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert!, Access, write）。

fn tui_theme_deserializes_from_toml()

作用：测试 TUI 的主题字段能从 TOML 配置里读出来。TUI 是终端用户界面，这里确保用户写的主题名不会被丢掉。

数据流：输入是一段 TOML：[tui] theme = "dracula" → TOML 解析器把文本反序列化成 ConfigToml 结构 → 输出是解析后的配置；测试确认主题值是 dracula。

调用关系：测试运行器调用它；它直接测试 TOML 反序列化，不经过完整运行时配置加载流程。

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

fn tui_theme_defaults_to_none()

作用：测试 TUI 配置块存在但没写主题时，主题保持为空。这样系统不会凭空套用用户没选择的主题。

数据流：输入是一段只有 [tui] 的 TOML → TOML 解析器生成配置对象 → 输出是解析后的配置；测试确认主题字段是 None，也就是没有设置。

调用关系：测试运行器调用它；它只验证配置文本到数据结构的默认值行为。

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

fn tui_session_picker_view_deserializes_from_toml()

作用：测试会话选择器视图模式能从 TOML 里的字符串读成内部枚举值。这里的枚举值可以理解为“只能在几个固定选项里选一个”。

数据流：输入是 [tui] session_picker_view = "dense" → TOML 解析器把字符串转换为 SessionPickerViewMode::Dense → 输出是解析后的配置；测试确认字段值是 Dense。

调用关系：测试运行器调用它；它检查 TUI 子配置的反序列化映射是否正确。

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

fn tui_pet_deserializes_from_toml()

作用：测试 TUI 的 pet 字段能从配置里读出来。这个字段表示终端界面里选择的“小宠物”样式或名字。

数据流：输入是 [tui] pet = "chefito" → TOML 解析器生成配置对象 → 输出是解析后的配置；测试确认 pet 字段保存为 chefito。

调用关系：测试运行器调用它；它直接覆盖 TUI pet 字段的配置解析。

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

fn tui_session_picker_view_defaults_to_none()

作用：测试 TUI 配置块没写会话选择器视图时，原始配置结构里这个字段是空的。后续运行时默认值会在别处决定。

数据流：输入是只有 [tui] 的 TOML → TOML 解析器生成 ConfigToml → 输出是解析后的配置；测试确认 session_picker_view 没有值。

调用关系：测试运行器调用它；它验证反序列化层不会提前填入运行时默认视图。

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

fn tui_pet_defaults_to_none()

作用：测试 TUI 配置块没写 pet 时，不会默认选择某个宠物。用户没设置就保持为空。

数据流：输入是只有 [tui] 的 TOML → TOML 解析器生成配置对象 → 输出是解析后的配置；测试确认 pet 字段是 None。

调用关系：测试运行器调用它；它专注检查 pet 字段的默认空值。

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

fn tui_pet_anchor_deserializes_from_toml()

作用：测试 pet 的显示位置字段能从 TOML 读出来。比如 screen-bottom 表示把它固定在屏幕底部。

数据流：输入是 [tui] pet_anchor = "screen-bottom" → TOML 解析器把字符串转换为 TuiPetAnchor::ScreenBottom → 输出是解析后的配置；测试确认位置枚举值正确。

调用关系：测试运行器调用它；它验证 TUI pet 位置字符串和内部固定选项之间的对应关系。

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

fn tui_pet_anchor_defaults_to_composer()

作用：测试 pet 位置没写时，默认挂在 composer，也就是输入区附近。这样界面行为有一个稳定默认值。

数据流：输入是只有 [tui] 的 TOML → TOML 解析器生成配置对象，并给 pet_anchor 填默认值 → 输出是解析后的配置；测试确认默认值是 TuiPetAnchor::Composer。

调用关系：测试运行器调用它；它检查反序列化默认值，而不是完整运行时加载。

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

fn tui_pet_anchor_rejects_unknown_value()

作用：测试 pet 位置如果写了不支持的值，会被拒绝，并在错误里提示可用选项。这样用户拼错配置时能马上知道问题在哪。

数据流：输入是 [tui] pet_anchor = "bottom"，这是未知值 → TOML 解析器尝试转换枚举失败 → 输出是解析错误；测试确认错误信息包含未知值 bottom，也包含允许的 composer 和 screen-bottom。

调用关系：测试运行器调用它；它直接检查 TOML 解析层对非法枚举值的报错质量。

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

fn tui_config_missing_notifications_field_defaults_to_enabled()

作用：测试 TUI 配置里没写通知字段时，通知相关设置会使用默认启用配置，同时其他 TUI 字段也有稳定默认值。

数据流：输入是只有 [tui] 的 TOML → TOML 解析器生成完整的 Tui 子配置并填默认值 → 输出是解析后的 TUI 对象；测试把它和预期的默认 TUI 配置逐项比较，包括动画、提示、备用屏幕、颜色、pet 位置、按键映射等。

调用关系：测试运行器调用它；它是 TUI 默认值的整体快照测试，能在默认值被意外改动时及时失败。

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

async fn runtime_config_resolves_terminal_resize_reflow_defaults_and_overrides()

作用：测试运行时配置会正确决定终端 resize 后重排内容时最多处理多少行。默认是自动，正数表示限制行数，0 表示关闭这个限制。

数据流：输入先是空配置 → 配置加载器生成默认运行时配置，最大行数为 Auto；再输入 TUI 里设置 9000 → 输出变为 Limit(9000)；最后输入 0 → 输出变为 Disabled。测试逐次确认这三种结果。

调用关系：测试运行器调用它；它通过 Config::load_from_base_config_with_overrides 检查原始 TOML 字段如何被提升成真正运行时使用的 terminal_resize_reflow 配置。

调用图：外部调用 6 个（default, load_from_base_config_with_overrides, assert_eq!, default, default, tempdir）。

async fn forced_chatgpt_workspace_id_empty_values_disable_runtime_restriction() -> std::io::Result<()>

作用：测试强制 ChatGPT 工作区 ID 的配置在空值、空字符串、空列表时会被视为未启用限制；只有真正非空的 ID 才会留下来。

数据流：输入是一组 TOML 案例：未设置、空字符串、空白字符串、空列表、空白列表项、混合有效 ID → 每个案例先解析成 ConfigToml，再走配置加载器清洗字段 → 输出是运行时配置里的 forced_chatgpt_workspace_id；测试确认空值都变成 None，混合列表只保留去掉空白后的有效 ID。

调用关系：测试运行器调用它；它把多个小场景放在循环里，验证配置加载器对这个运行时限制字段的清理逻辑。

调用图：外部调用 6 个（load_from_base_config_with_overrides, assert_eq!, default, tempdir, from_str, vec!）。

async fn legacy_remote_thread_store_endpoint_is_rejected()

作用：测试旧的远程 thread-store endpoint 配置虽然还能被 TOML 解析出来，但在加载阶段会被拒绝。这样旧字段不会继续悄悄生效。

数据流：输入是 experimental_thread_store_endpoint = "https://example.com" → TOML 解析成功，说明旧字段仍可识别；随后配置加载器检查到它已不受支持 → 输出是加载错误；测试确认错误信息提到该字段并说明不再支持。

调用关系：测试运行器调用它；它区分“能解析旧字段”和“运行时拒绝旧字段”这两个阶段。

调用图：外部调用 5 个（load_from_base_config_with_overrides, assert!, default, tempdir, from_str）。

fn profile_tui_rejects_unsupported_settings()

作用：测试 profile 里的 TUI 配置不能随便写根级 TUI 字段。比如在某个 profile 下设置 theme 应该被拒绝，避免用户以为它会按 profile 生效。

数据流：输入是一段 TOML，选择 profile work，并在 [profiles.work.tui] 下写 theme = "dark" → TOML 解析器按 profile TUI 支持字段校验时失败 → 输出是解析错误；测试确认错误里有 unknown field 和 theme。

调用关系：测试运行器调用它；它直接验证配置 schema，也就是配置格式规则，对 profile 作用域里的 TUI 字段有限制。

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

async fn runtime_config_resolves_session_picker_view_default_and_override()

作用：测试运行时会话选择器视图的默认值和用户覆盖值。原始配置没写时默认是 dense，用户写 comfortable 时就改成 comfortable。

数据流：输入先是空配置 → 配置加载器生成运行时配置，tui_session_picker_view 为 Dense；再输入 TUI 覆盖为 Comfortable → 输出变为 Comfortable。测试分别确认两个结果。

调用关系：测试运行器调用它；它检查从原始 TUI 配置到运行时字段的默认填充和覆盖流程。

调用图：外部调用 6 个（default, load_from_base_config_with_overrides, assert_eq!, default, default, tempdir）。

async fn test_sandbox_config_parsing()

作用：测试旧版沙盒配置会被解析成正确的沙盒策略。它覆盖全访问、只读、工作区可写，以及 Windows 平台下的特殊降级行为。

数据流：输入是多段 TOML：危险全访问、只读、带可写根目录的工作区写入配置，还分别测试有无受信任项目记录 → 每段先解析成 ConfigToml，再交给测试用的沙盒策略推导函数 → 输出是 SandboxPolicy；测试确认全访问会忽略工作区网络设置，只读会忽略工作区网络设置，工作区写入在非 Windows 下保留可写根目录和排除选项，在 Windows 下退为只读。

调用关系：测试运行器调用它；它把具体推导工作交给 derive_legacy_sandbox_policy_for_test，用于守住旧版沙盒配置到内部策略之间的兼容规则。

调用图：调用 1 个内部函数（derive_legacy_sandbox_policy_for_test）；外部调用 4 个（assert_eq!, cfg!, test_absolute_path, format!）。

async fn legacy_sandbox_mode_builds_profiles_with_compatible_projection() -> std::io::Result<()>

作用：验证旧的 sandbox_mode 配置还能被正确转换成新的权限配置。这样老用户升级后，原来的读写限制和网络限制不会突然变味。

数据流：输入是几种旧格式的 TOML 配置、临时的 Codex 主目录和当前工作目录；测试把它们加载成 Config，再取出旧沙箱策略、新文件系统策略和网络策略互相比对；结果是确认它们能来回转换，并且 workspace-write 会把工作目录和额外目录正确放进可写范围，Windows 上则保持降级为只读的旧行为。

调用关系：测试运行器调用它；它主要把配置交给 Config::load_from_base_config_with_overrides，再检查 legacy_sandbox_policy、permissions 这些配置转换结果，防止新旧权限模型之间的兼容层出错。

调用图：外部调用 9 个（default, new, load_from_base_config_with_overrides, assert!, assert_eq!, cfg!, test_absolute_path, unreachable!, vec!）。

fn filter_mcp_servers_by_allowlist_enforces_identity_rules()

作用：验证普通 MCP 服务器必须同时“名字在名单里”和“身份匹配”才会被允许。身份可以是启动命令，也可以是 URL。

数据流：输入是一组服务器和一份带来源的要求名单；测试调用 filter_mcp_servers_by_requirements 过滤；输出是匹配命令或 URL 的服务器仍启用，不匹配或没有列名的服务器被禁用，并记录禁用原因。

调用关系：测试运行器调用它；它直接检查 MCP 允许名单过滤函数，确保企业或托管配置不能只靠同名服务器被冒充。

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

fn filter_mcp_servers_by_allowlist_allows_all_when_unset()

作用：验证没有设置 MCP 要求名单时，现有服务器不会被莫名禁用。也就是说，限制没开就不该默认拦截。

数据流：输入是两个 MCP 服务器和 None 表示没有要求名单；过滤函数执行后；输出是两个服务器都保持启用，禁用原因为空。

调用关系：测试运行器调用它；它补足 filter_mcp_servers_by_requirements 的默认分支，说明只有明确给了名单才会开始限制。

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

fn filter_mcp_servers_by_allowlist_blocks_all_when_empty()

作用：验证一份“空的要求名单”不是等于没限制，而是表示一个都不允许。这个区别对企业管控很重要。

数据流：输入是两个服务器和一份空的要求表；过滤函数看到名单存在但没有任何允许项；输出是所有服务器都被禁用，并带上来自该要求来源的禁用原因。

调用关系：测试运行器调用它；它和“名单未设置时全放行”的测试配对，确认 None 和空表的含义不会混淆。

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

fn filter_plugin_mcp_servers_by_allowlist_enforces_plugin_and_identity_rules()

作用：验证插件提供的 MCP 服务器也必须符合对应插件下的允许名单。不能因为服务器来自插件，就绕过命令或 URL 身份检查。

数据流：输入是某个插件的三个服务器和一份只给 sample@test 插件写的要求；调用 filter_plugin_mcp_servers_by_requirements 后；输出是名字和命令都匹配的服务器保留，命令不匹配或没在名单里的服务器禁用。

调用关系：测试运行器调用它；它检查插件专用过滤路径，配合普通 MCP 过滤规则，保证插件导入的工具同样受管控。

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

fn filter_plugin_mcp_servers_by_allowlist_blocks_unlisted_plugin()

作用：验证如果要求名单里根本没有当前插件，这个插件的 MCP 服务器会被全部禁用。这样未获批准的插件不能偷偷带工具进来。

数据流：输入是 sample@test 插件的服务器，但要求名单只写了 other@test；过滤后；输出是 sample@test 的服务器被禁用，并记录要求来源。

调用关系：测试运行器调用它；它覆盖 filter_plugin_mcp_servers_by_requirements 的“插件没被列出”场景。

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

async fn rebuild_preserving_session_layers_refreshes_requirements() -> std::io::Result<()>

作用：验证重建配置时，会保留会话里的临时设置，同时刷新最新的 MCP 要求名单。它防止“旧会话配置”把新的企业限制盖掉。

数据流：输入是两套配置层：一套代表刷新后的用户/项目/托管配置和要求名单，另一套代表当前线程里带会话层的旧配置；测试分别加载成 Config，再调用 rebuild_preserving_session_layers；输出是会话层该保留的仍保留，托管要求该覆盖的会覆盖，未满足新要求的会话服务器被禁用。

调用关系：测试运行器调用它；它通过 ConfigLayerStack 和 Config::load_config_with_layer_stack 搭环境，最后检查 Config::rebuild_preserving_session_layers 的合并结果。

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

async fn rebuild_preserving_session_layers_refreshes_plugin_derived_mcp_config() -> anyhow::Result<()>

作用：验证重建配置后，插件派生出来的 MCP 配置也会按最新功能开关刷新。尤其是原会话里插件关闭，刷新后插件开启时，插件服务器要能出现。

数据流：输入是一个临时插件目录和两套配置层：刷新配置开启 plugins，线程旧配置关闭 plugins；重建后再转换成 MCP 配置；输出是插件 .mcp.json 里的 sample 服务器被加载，并带有插件归属信息。

调用关系：测试运行器调用它；它串起 Config::rebuild_preserving_session_layers、PluginsManager 和 Config::to_mcp_config，确认插件发现结果不会停留在旧配置状态。

调用图：调用 3 个内部函数（new, new, resolve_path_against_base）；外部调用 7 个（default, new, load_config_with_layer_stack, assert_eq!, create_dir_all, write, vec!）。

async fn to_mcp_config_omits_plugin_id_when_user_server_shadows_plugin_mcp() -> anyhow::Result<()>

作用：验证用户自己配置的 MCP 服务器如果和插件服务器同名，会覆盖插件版本，并且不会被标记成插件提供。这样归属不会误导后续逻辑。

数据流：输入是一个同名插件 MCP 服务器和用户 config.toml 里的同名服务器；加载配置后转换成 MCP 配置；输出是最终服务器使用用户写的 URL，插件归属表为空。

调用关系：测试运行器调用它；它检查 ConfigBuilder、PluginsManager 和 to_mcp_config 合成服务器目录时的“用户配置优先”规则。

调用图：调用 1 个内部函数（new）；外部调用 6 个（new, assert!, assert_eq!, default, create_dir_all, write）。

async fn selected_plugin_wins_after_discovered_plugin_requirements() -> anyhow::Result<()>

作用：验证手动选中的插件 MCP 注册项可以覆盖被发现插件的要求限制。也就是说，用户明确选中的来源在最终目录里有更高优先级。

数据流：输入是一个插件自带的两个服务器、企业要求只允许其中一个，以及一个后来传入的 selected plugin 注册；第一次生成 MCP 配置时，未列入要求的服务器被禁用；第二次带 selected 注册生成时，该服务器以选中插件来源启用，并使用选中配置。

调用关系：测试运行器调用它；它先检查 to_mcp_config 的企业要求过滤，再检查 to_mcp_config_with_plugin_registrations 能让显式选择的插件条目胜出。

调用图：调用 5 个内部函数（new, from_selected_plugin, loader_with_enterprise_requirement, new, http_mcp）；外部调用 5 个（new, assert_eq!, default, create_dir_all, write）。

async fn to_mcp_config_empty_mcp_requirements_disable_plugin_mcps() -> anyhow::Result<()>

作用：验证企业配置里写了空的 MCP 要求表时，插件带来的 MCP 服务器会被禁用。空表在这里表示“没有任何服务器被批准”。

数据流：输入是一个启用的插件和企业要求中的空 [mcp_servers] 表；配置加载后转换成 MCP 配置；输出是插件里的 sample 服务器存在但 disabled，并带企业要求来源作为原因。

调用关系：测试运行器调用它；它覆盖 ConfigBuilder 加载云端企业要求后，to_mcp_config 对插件 MCP 做限制的路径。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, new）；外部调用 5 个（new, assert_eq!, default, create_dir_all, write）。

async fn add_dir_override_extends_workspace_writable_roots() -> std::io::Result<()>

作用：验证命令行或运行时传入的额外可写目录，会加入 workspace-write 沙箱的可写范围，而且重复路径不会重复出现。

数据流：输入是 frontend 作为当前目录、backend 作为额外可写目录，包含相对路径和绝对路径两种写法；加载配置后查看旧沙箱策略；输出是在非 Windows 上 backend 只出现一次，Windows 上保持只读降级。

调用关系：测试运行器调用它；它检查 ConfigOverrides.additional_writable_roots 如何影响 Config::load_from_base_config_with_overrides 生成的 sandbox policy。

调用图：外部调用 9 个（default, new, load_from_base_config_with_overrides, assert_eq!, cfg!, default, panic!, create_dir_all, vec!）。

async fn default_zsh_path_sets_runtime_zsh_path() -> std::io::Result<()>

作用：验证外部传入的默认 zsh 路径会进入运行时配置。zsh 是一种命令行 shell，这里通常用于指定打包自带的 shell。

数据流：输入是 ConfigOverrides 里的 default_zsh_path；配置加载后；输出是 config.zsh_path 等于这个路径。

调用关系：测试运行器调用它；它检查 Config::load_from_base_config_with_overrides 是否把覆盖项正确落到最终 Config 字段。

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

async fn sqlite_home_defaults_to_codex_home_for_workspace_write() -> std::io::Result<()>

作用：验证在 workspace-write 沙箱模式下，SQLite 数据库默认放在 Codex 主目录。SQLite 是一个本地小数据库文件。

数据流：输入是开启 workspace-write 的覆盖配置和临时 Codex 主目录；加载配置后；输出是 config.sqlite_home 指向该 Codex 主目录。

调用关系：测试运行器调用它；它检查配置默认值选择，避免数据库路径跑到不该写的位置。

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

async fn workspace_write_includes_configured_writable_root_once_without_memories_root() -> std::io::Result<()>

作用：验证 workspace-write 会接收配置里的可写目录，但不会因为加载配置就创建 memories 目录，也不会把 memories 目录自动加入可写范围。

数据流：输入是重复写了两次的 writable_root 和 workspace-write 模式；配置加载后；输出是在非 Windows 上该目录只出现一次，memories 目录不存在且不可写，Windows 上仍是只读降级。

调用关系：测试运行器调用它；它检查沙箱可写目录去重，以及 memory 相关目录不会被无意扩大权限。

调用图：外部调用 8 个（default, new, load_from_base_config_with_overrides, assert!, assert_eq!, cfg!, panic!, vec!）。

async fn memory_tool_makes_memories_root_readable_without_creating_or_widening_writes() -> std::io::Result<()>

作用：验证开启 memories 功能后，memories 目录只变成可读，不会被创建，也不会变成可写。这样记忆工具能读取需要的位置，但不会扩大写权限。

数据流：输入是启用 memories 功能的配置、当前工作目录和 workspace-write 模式；加载后取文件系统权限策略；输出是 memories 路径可读、不可写，目录本身没有被创建，旧沙箱可写根里也不包含它。

调用关系：测试运行器调用它；它检查 features、permissions 和 legacy_sandbox_policy 三者对 memory 功能的权限处理是否一致。

调用图：调用 1 个内部函数（from）；外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert!, cfg!, panic!）。

async fn config_defaults_to_file_cli_auth_store_mode() -> std::io::Result<()>

作用：验证 CLI 登录凭据默认保存在文件里。凭据就是登录令牌一类的认证信息。

数据流：输入是空配置；加载后；输出是 config.cli_auth_credentials_store_mode 为 File。

调用关系：测试运行器调用它；它检查 Config::load_from_base_config_with_overrides 的默认认证存储策略。

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

async fn config_resolves_explicit_keyring_auth_store_mode() -> std::io::Result<()>

作用：验证用户明确选择 keyring 时，会按当前版本规则解析最终的 CLI 凭据存储方式。keyring 是系统提供的安全凭据库。

数据流：输入是 cli_auth_credentials_store = Keyring；配置加载后；输出等于 resolve_cli_auth_credentials_store_mode 根据包版本算出的结果。

调用关系：测试运行器调用它；它把 Config 加载结果和解析函数对齐，确保配置字段没有绕过版本兼容逻辑。

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

async fn config_resolves_default_oauth_store_mode() -> std::io::Result<()>

作用：验证 MCP OAuth 凭据默认使用 Auto，并会按版本解析成真正的存储方式。OAuth 是常见的网页登录授权机制。

数据流：输入是空配置；加载后；输出是 config.mcp_oauth_credentials_store_mode 等于 resolve_mcp_oauth_credentials_store_mode 的结果。

调用关系：测试运行器调用它；它检查 MCP OAuth 的默认值不是硬编码错的，而是走统一解析函数。

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

fn local_dev_builds_force_file_cli_auth_store_modes()

作用：验证本地开发版本会强制把 CLI 凭据存储改为文件，除非用户选择临时模式。这样开发环境不会依赖系统 keyring。

数据流：输入是不同的 CLI 凭据存储选项和 LOCAL_DEV_BUILD_VERSION；解析函数处理后；输出是 Keyring 和 Auto 都变 File，Ephemeral 仍保持临时，正式版本仍可用 Keyring。

调用关系：测试运行器调用它；它直接测试 resolve_cli_auth_credentials_store_mode 的版本分支。

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

fn local_dev_builds_force_file_mcp_oauth_store_modes()

作用：验证本地开发版本会强制 MCP OAuth 凭据走文件存储。这样开发构建在没有系统凭据库时也能稳定运行。

数据流：输入是 OAuth 存储模式和版本号；解析函数处理后；输出是本地开发版本的 Keyring 和 Auto 变成 File，正式版本的 Keyring 保持 Keyring。

调用关系：测试运行器调用它；它直接测试 resolve_mcp_oauth_credentials_store_mode 的本地开发兼容规则。

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

async fn feedback_enabled_defaults_to_true() -> std::io::Result<()>

作用：验证 feedback 配置表存在但没写 enabled 时，反馈功能默认开启。这样空表不会被误解成关闭。

数据流：输入是 feedback 默认表；加载配置后；输出是 config.feedback_enabled 为 true。

调用关系：测试运行器调用它；它检查 FeedbackConfigToml 的默认值如何进入最终 Config。

调用图：外部调用 6 个（default, new, load_from_base_config_with_overrides, assert_eq!, default, default）。

fn web_search_mode_defaults_to_none_if_unset()

作用：验证没有任何网页搜索配置时，解析结果为空。也就是系统不会凭空选择一种搜索模式。

数据流：输入是默认 ConfigToml 和默认 Features；resolve_web_search_mode 处理后；输出是 None。

调用关系：测试运行器调用它；它检查网页搜索配置解析的最基础默认分支。

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

fn web_search_mode_prefers_config_over_legacy_flags()

作用：验证新的 web_search 配置优先于旧功能开关。这样用户明确写的新配置不会被老开关盖掉。

数据流：输入是 web_search = Live，同时旧的 cached 功能开关也打开；解析后；输出是 Live。

调用关系：测试运行器调用它；它检查 resolve_web_search_mode 在新旧配置同时存在时的优先级。

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

fn web_search_mode_disabled_overrides_legacy_request()

作用：验证用户明确禁用网页搜索时，即使旧开关请求搜索，也会保持禁用。

数据流：输入是 web_search = Disabled 和旧的 request 功能开关；解析后；输出是 Disabled。

调用关系：测试运行器调用它；它保护 resolve_web_search_mode 的安全优先级，避免旧开关意外打开搜索。

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

fn web_search_mode_for_turn_uses_preference_for_read_only()

作用：验证在只读权限配置下，每一轮对话会使用用户偏好的网页搜索模式。只读权限不需要强行改成 live。

数据流：输入是偏好 Cached 的受约束值和只读权限档案；解析当前轮次模式；输出是 Cached。

调用关系：测试运行器调用它；它检查 resolve_web_search_mode_for_turn 面对 PermissionProfile::read_only 的行为。

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

fn web_search_mode_for_turn_prefers_live_for_disabled_permissions()

作用：验证当权限档案是 Disabled 时，如果允许 live，当前轮次会偏向 Live 搜索。这里 Disabled 指工具权限关闭，不是网页搜索关闭。

数据流：输入是偏好 Cached 但允许任意值的网页搜索设置，以及 Disabled 权限档案；解析后；输出是 Live。

调用关系：测试运行器调用它；它检查 resolve_web_search_mode_for_turn 在无工具权限时的默认选择。

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

fn web_search_mode_for_turn_respects_disabled_for_disabled_permissions()

作用：验证用户明确把网页搜索设为 Disabled 时，权限档案不会把它改成 Live。

数据流：输入是允许任意值但当前值为 Disabled 的设置，以及 Disabled 权限档案；解析后；输出仍是 Disabled。

调用关系：测试运行器调用它；它和偏向 Live 的测试配对，确认显式禁用具有最高优先级。

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

fn web_search_mode_for_turn_falls_back_when_live_is_disallowed() -> anyhow::Result<()>

作用：验证如果策略不允许 Live 搜索，系统会退回到允许的偏好值，而不是硬切到 Live。

数据流：输入是一个受约束的网页搜索设置，只允许 Disabled 和 Cached；当前权限档案会尝试偏向 Live；解析后；输出回到 Cached。

调用关系：测试运行器调用它；它通过 Constrained 约束对象检查 resolve_web_search_mode_for_turn 是否尊重外部要求。

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

async fn project_profiles_are_ignored() -> std::io::Result<()>

作用：验证项目本地 .codex/config.toml 里的 profile 和 profiles 设置会被忽略，并给出启动警告。这样项目仓库不能偷偷切换用户模型配置。

数据流：输入是用户配置里信任某工作区，项目配置里写 profile 和 profiles；ConfigBuilder 加载后；输出是 config.model 没有被项目 profile 改掉，并且 startup_warnings 里有提示用户把这些设置放到用户级配置。

调用关系：测试运行器调用它；它通过 ConfigBuilder::without_managed_config_for_tests 模拟真实加载流程，检查项目配置的安全边界。

调用图：调用 1 个内部函数（without_managed_config_for_tests）；外部调用 7 个（default, new, assert!, assert_eq!, format!, create_dir_all, write）。

async fn feature_table_overrides_legacy_flags() -> std::io::Result<()>

作用：验证新的 [features] 表可以覆盖旧功能开关的默认行为。这样功能开关迁移后，用户写的新表是准的。

数据流：输入是 features.apply_patch_freeform = false；加载配置后；输出是 Feature::ApplyPatchFreeform 未启用。

调用关系：测试运行器调用它；它检查 FeaturesToml 进入最终 config.features 的优先级。

调用图：调用 1 个内部函数（from）；外部调用 6 个（new, default, new, load_from_base_config_with_overrides, assert!, default）。

async fn legacy_toggles_map_to_features() -> std::io::Result<()>

作用：验证旧的 experimental_use_unified_exec_tool 开关仍会映射到新的 Feature::UnifiedExec。这样老配置不会失效。

数据流：输入是旧字段 experimental_use_unified_exec_tool = true；加载后；输出是新 features 里 UnifiedExec 启用，同时旧兼容字段也为 true。

调用关系：测试运行器调用它；它保护旧配置字段到新功能系统的兼容映射。

调用图：外部调用 5 个（default, new, load_from_base_config_with_overrides, assert!, default）。

async fn responses_websocket_features_do_not_change_wire_api() -> std::io::Result<()>

作用：验证 responses_websockets 相关功能开关不会改变底层 wire API。wire API 可以理解为客户端和模型服务说话的协议格式。

数据流：输入是分别开启 responses_websockets 和 responses_websockets_v2 的配置；加载后；输出是 model_provider.wire_api 仍为 Responses。

调用关系：测试运行器调用它；它防止实验性 websocket 开关误改模型供应商协议类型。

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

async fn config_honors_explicit_file_oauth_store_mode() -> std::io::Result<()>

作用：验证用户明确把 MCP OAuth 凭据存储设为 file 时，最终配置会照做。

数据流：输入是 mcp_oauth_credentials_store = File；加载配置后；输出是 config.mcp_oauth_credentials_store_mode 为 File。

调用关系：测试运行器调用它；它检查显式配置不会被默认解析逻辑覆盖。

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

async fn managed_config_overrides_oauth_store_mode() -> anyhow::Result<()>

作用：验证托管配置可以覆盖用户配置里的 OAuth 凭据存储方式。托管配置通常来自企业管理，优先级更高。

数据流：输入是用户 config.toml 写 file、托管配置写 keyring；加载配置层并反序列化后；输出是中间 TOML 和最终 Config 都采用 keyring，并按版本解析最终模式。

调用关系：测试运行器调用它；它使用 load_config_layers_state、deserialize_config_toml_with_base 和 Config 加载，检查配置层优先级链条。

调用图：调用 1 个内部函数（with_managed_config_path_for_tests）；外部调用 6 个（new, new, load_from_base_config_with_overrides, assert_eq!, default, write）。

async fn load_global_mcp_servers_returns_empty_if_missing() -> anyhow::Result<()>

作用：验证没有全局配置文件时，读取全局 MCP 服务器会返回空表，而不是报错。

数据流：输入是一个没有 config.toml 的临时 Codex 主目录；调用 load_global_mcp_servers；输出是空集合。

调用关系：测试运行器调用它；它检查读取全局 MCP 配置的容错默认行为。

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

async fn replace_mcp_servers_round_trips_entries() -> anyhow::Result<()>

作用：验证用配置编辑操作替换 MCP 服务器后，再读回来内容不丢不变。这个测试保证写配置和读配置是一套兼容格式。

数据流：输入是一个完整的 docs MCP 服务器配置，包括命令、参数、工作目录、超时、环境等；apply_blocking 写入后 load_global_mcp_servers 读回；输出是所有关键字段匹配。随后写入空表，再读回确认服务器被清空。

调用关系：测试运行器调用它；它串起 ConfigEdit::ReplaceMcpServers、apply_blocking 和 load_global_mcp_servers，检查配置文件的读写闭环。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 10 个（new, from_secs, new, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, vec!）。

async fn managed_config_wins_over_cli_overrides() -> anyhow::Result<()>

作用：验证托管配置的优先级高于命令行覆盖项。企业指定的模型不应被用户启动参数轻易改掉。

数据流：输入是用户配置 model=base、CLI 覆盖 model=cli、托管配置 model=managed_config；加载配置层后反序列化；输出是最终 cfg.model 为 managed_config。

调用关系：测试运行器调用它；它检查 load_config_layers_state 合并配置层时的优先级顺序。

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

async fn load_global_mcp_servers_accepts_legacy_ms_field() -> anyhow::Result<()>

作用：验证读取 MCP 服务器时还能接受旧字段 startup_timeout_ms。这样旧配置里的毫秒单位超时不会坏掉。

数据流：输入是 config.toml 里写 command 和 startup_timeout_ms = 2500；读取全局 MCP 服务器后；输出是 startup_timeout_sec 等于 2500 毫秒对应的 Duration。

调用关系：测试运行器调用它；它检查 load_global_mcp_servers 的旧字段兼容解析。

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

fn mcp_servers_toml_parses_per_tool_approval_overrides()

作用：验证 MCP 服务器可以给单个工具单独设置审批模式。比如服务器默认要询问，但某个工具可以直接批准。

数据流：输入是一段 TOML，包含服务器默认审批模式和 docs.tools.search 的审批模式；反序列化成 ConfigToml；输出是服务器默认值为 Prompt，search 工具配置为 Approve。

调用关系：测试运行器调用它；它直接测试 ConfigToml 的 TOML 解析结构，确保 per-tool 配置能进内存模型。

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

fn mcp_servers_toml_ignores_unknown_server_fields()

作用：验证 MCP 服务器配置里出现未知字段时会被忽略，而不是导致整个配置失败。这样向前兼容性更好。

数据流：输入是带 trust_level 这个未知字段的 MCP 服务器 TOML；反序列化后；输出仍得到正常的 stdio MCP 配置。

调用关系：测试运行器调用它；它检查 ConfigToml 的反序列化策略，防止旧客户端遇到新字段就崩。

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

fn mcp_servers_toml_parses_tool_approval_override_for_reserved_name()

作用：验证即使工具名叫 command 这种容易和服务器字段混淆的名字，也能作为工具配置被正确解析。

数据流：输入是 mcp_servers.docs.tools.command.approval_mode；反序列化后查找 docs 服务器的 command 工具；输出是该工具审批模式为 Approve。

调用关系：测试运行器调用它；它保护 TOML 层级解析，避免保留字段名影响工具名。

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

fn desktop_toml_round_trips_opaque_nested_values() -> anyhow::Result<()>

作用：验证 desktop 配置可以保存前端需要的任意嵌套值，并且序列化再读回来不变。这里 opaque 表示后端不理解内容，只负责原样保存。

数据流：输入是包含字符串、数组、嵌套表和内联对象的 desktop TOML；解析后检查它们变成对应 JSON 值；再转回 TOML 并重新解析；输出是 reparsed.desktop 与原值一致。

调用关系：测试运行器调用它；它检查 ConfigToml.desktop 作为“透明盒子”的读写往返能力。

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

async fn to_mcp_config_preserves_apps_feature_from_config() -> std::io::Result<()>

作用：验证转换成 MCP 配置时，会保留 Apps 功能开关和产品 SKU。SKU 可以理解为产品套餐或版本标识。

数据流：输入是一个 Config，并手动设置 apps_mcp_product_sku；转换成 MCP 配置后；输出 apps_enabled 随 Feature::Apps 的启用或禁用变化，SKU 仍传过去。

调用关系：测试运行器调用它；它检查 Config::to_mcp_config 从通用配置传递 Apps 相关字段到 MCP 运行配置。

调用图：调用 1 个内部函数（new）；外部调用 6 个（new, load_from_base_config_with_overrides, assert!, assert_eq!, default, default）。

async fn to_mcp_config_flows_mcp_tool_prefix_from_feature() -> std::io::Result<()>

作用：验证 MCP 工具名前缀策略会从功能开关流入 MCP 配置。默认加前缀，开启 NonPrefixedMcpToolNames 后不加。

数据流：输入是默认 Config；第一次转换输出 prefix_mcp_tool_names 为 true；启用 Feature::NonPrefixedMcpToolNames 后再转换；输出变为 false。

调用关系：测试运行器调用它；它检查 Config::to_mcp_config 是否正确读取 features 来决定工具命名方式。

调用图：调用 1 个内部函数（new）；外部调用 5 个（new, load_from_base_config_with_overrides, assert!, default, default）。

async fn to_mcp_config_preserves_auth_elicitation_feature_from_config() -> std::io::Result<()>

作用：验证开启 AuthElicitation 功能后，MCP 客户端会声明自己支持认证引导能力。认证引导就是服务端可以要求客户端弹表单或打开链接让用户授权。

数据流：输入是默认 Config；第一次转换得到默认 elicitation 能力；启用 Feature::AuthElicitation 后再转换；输出包含表单和 URL 两种引导能力。

调用关系：测试运行器调用它；它检查 Config::to_mcp_config 是否把认证交互能力从功能开关传给 MCP 客户端配置。

调用图：调用 1 个内部函数（new）；外部调用 5 个（new, load_from_base_config_with_overrides, assert_eq!, default, default）。

async fn load_global_mcp_servers_rejects_inline_bearer_token() -> anyhow::Result<()>

作用：验证全局 MCP 配置不允许直接写 bearer_token 明文密钥，而是要求使用 bearer_token_env_var 这类环境变量方式。这样可以避免把秘密写进配置文件。

数据流：输入是一个 HTTP MCP 服务器配置，里面直接写 bearer_token = secret；调用 load_global_mcp_servers；输出是 InvalidData 错误，错误信息同时提到 bearer_token 和 bearer_token_env_var。

调用关系：测试运行器调用它；它检查全局 MCP 配置读取时的安全校验，防止敏感令牌被明文接受。

调用图：外部调用 4 个（new, assert!, assert_eq!, write）。

async fn replace_mcp_servers_serializes_env_sorted() -> anyhow::Result<()>

作用：测试写入 MCP 标准输入输出服务器时，普通环境变量会被保存下来，而且在文件里按固定顺序排列。这样配置文件每次生成都稳定，不会因为哈希表顺序不同而忽左忽右。

数据流：它先创建一个临时 Codex 主目录，准备一个名叫 docs 的 MCP 服务器配置，里面有命令、参数和两个环境变量。然后调用 apply_blocking 把配置写进 config.toml，读取文件确认 ALPHA_VAR 排在 ZIG_VAR 前面。最后再用 load_global_mcp_servers 读回来，确认命令、参数、环境变量都还在，env_vars 为空，cwd 没有被误填。

调用关系：这个测试由测试运行器触发，核心是在模拟用户替换 MCP 服务器配置时走一遍真实写入流程。它把工作交给 apply_blocking 写文件，再交给 load_global_mcp_servers 验证读取结果，确保写和读两头能对上。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 11 个（from, from, new, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, read_to_string (+1 more)）。

async fn replace_mcp_servers_serializes_env_vars() -> anyhow::Result<()>

作用：测试 MCP 服务器可以保存 env_vars 这种“从外部环境继承哪些变量名”的配置。它防止这些变量名写入后丢失。

数据流：它创建临时目录和 docs 服务器配置，env 为空，但 env_vars 里有 ALPHA 和 BETA。写入 config.toml 后，它检查文件里出现 env_vars = ["ALPHA", "BETA"]。再读回配置，确认 docs 的 env_vars 仍然是这两个名字。

调用关系：测试运行器执行它时，它会通过 apply_blocking 走配置编辑写入路径，再通过 load_global_mcp_servers 走读取路径，用来保护 env_vars 的序列化和反序列化。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 10 个（from, new, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, read_to_string, vec!）。

async fn replace_mcp_servers_serializes_sourced_env_vars() -> anyhow::Result<()>

作用：测试 env_vars 不只支持简单变量名，也支持带来源说明的变量。比如 REMOTE_TOKEN 可以标明来自 remote。

数据流：它准备一个 MCP 服务器，其中 env_vars 同时包含旧式字符串 LEGACY 和带 name、source 的结构化变量 REMOTE_TOKEN。写入文件后，它检查 TOML 里既有字符串也有内联表。随后读回全部 MCP 服务器配置，并直接确认读回结果和原始 servers 完全一致。

调用关系：它覆盖的是 MCP 环境变量格式的兼容性：旧写法和新写法要能混用。apply_blocking 负责写，load_global_mcp_servers 负责读，测试把两者连起来验证。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 9 个（from, new, new, new, ReplaceMcpServers, assert!, assert_eq!, read_to_string, vec!）。

async fn replace_mcp_servers_serializes_cwd() -> anyhow::Result<()>

作用：测试 MCP 标准输入输出服务器的工作目录 cwd 会被正确保存和读回。cwd 就是启动这个外部服务器时所在的文件夹。

数据流：它创建 docs 服务器配置，并把 cwd 设为 /tmp/codex-mcp。写入 config.toml 后，它检查文件包含 cwd = "/tmp/codex-mcp"。再读回配置，确认 docs 的 cwd 确实是这个路径。

调用关系：这个测试保护的是启动外部 MCP 进程时的重要路径设置。测试流程仍然是 apply_blocking 写入，再由 load_global_mcp_servers 读取确认。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 10 个（from, new, from, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, read_to_string）。

async fn replace_mcp_servers_streamable_http_serializes_bearer_token() -> anyhow::Result<()>

作用：测试使用 Streamable HTTP 连接方式的 MCP 服务器，可以保存 bearer_token_env_var。它表示认证令牌不直接写进配置，而是从某个环境变量里取，更安全。

数据流：它创建一个 HTTP 型 MCP 服务器，设置 url、bearer_token_env_var 和启动超时时间。写入后，它要求 config.toml 精确等于预期文本。再读回配置，确认 URL、令牌环境变量名、空的请求头配置，以及 startup_timeout_sec 都正确。

调用关系：它测试的是 HTTP 型 MCP 服务器的写入格式。apply_blocking 负责把结构体变成 TOML，load_global_mcp_servers 再把 TOML 变回结构体。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 9 个（from, from_secs, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, read_to_string）。

async fn replace_mcp_servers_streamable_http_serializes_custom_headers() -> anyhow::Result<()>

作用：测试 HTTP 型 MCP 服务器可以保存自定义请求头。请求头可以理解成发 HTTP 请求时附带的小标签，用来传认证或额外信息。

数据流：它准备 docs 服务器，里面有 URL、令牌环境变量、自定义 http_headers，以及从环境变量取值的 env_http_headers。写入后，它要求文件内容精确包含两个独立的小节。再读回来，确认 X-Doc 和 X-Auth 两类头都没有丢。

调用关系：这个测试覆盖 HTTP MCP 的额外认证信息保存。它通过 apply_blocking 写出嵌套 TOML 小节，再通过 load_global_mcp_servers 检查这些小节能回到正确字段。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 9 个（from, from_secs, from, new, new, ReplaceMcpServers, assert_eq!, panic!, read_to_string）。

async fn replace_mcp_servers_streamable_http_removes_optional_sections() -> anyhow::Result<()>

作用：测试当 HTTP MCP 服务器的可选字段被清空时，旧的配置小节会从文件里删除。这样不会留下已经不用的令牌或请求头。

数据流：它先写入一个带 bearer token、普通请求头、环境请求头和超时的 docs 配置，并确认这些内容存在。然后把同一个服务器改成只剩 URL，再次写入。最后检查 config.toml 只剩 URL，并确认读回时令牌、请求头和启动超时都为空。

调用关系：这是防止“旧配置残留”的测试。它连续调用两次 apply_blocking，模拟用户先设置再删除可选项，然后用 load_global_mcp_servers 证明删除真的生效。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 10 个（from, from_secs, from, new, new, ReplaceMcpServers, assert!, assert_eq!, panic!, read_to_string）。

async fn replace_mcp_servers_streamable_http_isolates_headers_between_servers() -> anyhow::Result<()>

作用：测试一个 MCP 服务器的 HTTP 请求头不会误写到另一个服务器身上。多服务器配置里，这一点很重要。

数据流：它准备两个服务器：docs 是 HTTP 型并带请求头，logs 是标准输入输出型且不带请求头。写入文件后，它检查 docs 有 headers 小节，但 logs 没有 headers、env_headers 或 bearer token。再读回配置，确认 docs 的头还在，logs 没有被污染。

调用关系：它保护的是多服务器配置之间的边界。apply_blocking 写出整个服务器列表，load_global_mcp_servers 读回后，测试确认每个服务器只拿到属于自己的字段。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 12 个（from, from_secs, from, new, new, new, ReplaceMcpServers, assert!, assert_eq!, panic! (+2 more)）。

async fn replace_mcp_servers_serializes_disabled_flag() -> anyhow::Result<()>

作用：测试 MCP 服务器被禁用时，enabled = false 会写进配置文件，并且读回来仍然是禁用状态。

数据流：它创建一个 enabled 为 false 的 docs 服务器，写入 config.toml。然后读取文件确认包含 enabled = false，再加载 MCP 服务器配置，确认 docs.enabled 是 false。

调用关系：它验证用户关闭某个 MCP 服务器的选择不会丢失。写入由 apply_blocking 完成，读取由 load_global_mcp_servers 完成。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 7 个（from, new, new, new, ReplaceMcpServers, assert!, read_to_string）。

async fn replace_mcp_servers_serializes_required_flag() -> anyhow::Result<()>

作用：测试 MCP 服务器标记为 required 时会被保存。required 可以理解成“这个服务器是必须的”。

数据流：它创建一个 required 为 true 的 docs 服务器，写入配置文件。随后检查文件包含 required = true，再读回配置，确认 docs.required 为 true。

调用关系：它覆盖 MCP 服务器的必需标记。测试运行时通过真实写读流程，防止这个布尔开关在保存时被忽略。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 7 个（from, new, new, new, ReplaceMcpServers, assert!, read_to_string）。

async fn replace_mcp_servers_serializes_tool_filters() -> anyhow::Result<()>

作用：测试 MCP 服务器的工具白名单和黑名单会保存下来。enabled_tools 是允许的工具，disabled_tools 是禁用的工具。

数据流：它创建 docs 服务器，设置 enabled_tools 为 allowed，disabled_tools 为 blocked。写入后检查 TOML 中包含这两个数组。再读回来，确认配置对象里两个列表也保持原样。

调用关系：它验证工具过滤规则能穿过配置写入和读取两道关。apply_blocking 写入，load_global_mcp_servers 读取，断言负责比较结果。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 9 个（from, new, new, new, ReplaceMcpServers, assert!, assert_eq!, read_to_string, vec!）。

async fn replace_mcp_servers_streamable_http_serializes_oauth_resource() -> anyhow::Result<()>

作用：测试 HTTP MCP 服务器的 OAuth 配置能保存。OAuth 是一种常见登录授权机制，这里要保存客户端编号和资源地址。

数据流：它准备一个 HTTP 型 docs 服务器，带 oauth.client_id 和 oauth_resource。写入文件后，确认有 oauth 小节、client_id 和 oauth_resource。再读回配置，确认资源地址和客户端编号都能取到。

调用关系：它保护 MCP 服务器认证配置的读写。apply_blocking 负责落盘，load_global_mcp_servers 负责加载，oauth_client_id 方法负责从读回的配置中取客户端编号。

调用图：调用 1 个内部函数（apply_blocking）；外部调用 7 个（from, new, new, ReplaceMcpServers, assert!, assert_eq!, read_to_string）。

async fn set_model_updates_defaults() -> anyhow::Result<()>

作用：测试通过配置编辑器设置默认模型时，模型名和推理强度都会写进默认配置。推理强度可以理解成模型回答前“思考得多不多”的档位。

数据流：它创建临时 Codex 主目录，用 ConfigEditsBuilder 设置模型为 gpt-5.4、推理强度为 High，并应用修改。然后读取 config.toml，解析成 ConfigToml，确认 model 和 model_reasoning_effort 都是新值。

调用关系：它测试 ConfigEditsBuilder 的普通写配置路径。测试运行器调用它，它再通过 builder 的 set_model 和 apply 完成实际修改。

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

async fn for_config_writes_selected_user_config_file() -> anyhow::Result<()>

作用：测试当用户选择了某个单独的配置文件时，修改会写到这个文件，而不是默认 config.toml。这样多套配置不会互相覆盖。

数据流：它先写一个基础 config.toml 和一个 work.config.toml。然后构造 Config，把 user_config_path 指向 work.config.toml。接着用 ConfigEditsBuilder::for_config 设置新模型。最后确认 selected_config 被改成新模型和 High 推理强度，而 base_config 仍保持原文。

调用关系：这个测试模拟用户使用指定 profile 配置文件的场景。ConfigBuilder 先加载带覆盖项的配置，ConfigEditsBuilder::for_config 再根据这个配置决定要写哪个文件。

调用图：调用 2 个内部函数（without_managed_config_for_tests, without_managed_config_for_tests）；外部调用 6 个（new, assert_eq!, for_config, read_to_string, write, from_str）。

fn profile_v2_config_path_resolves_validated_names() -> anyhow::Result<()>

作用：测试新版 profile 名称会解析成正确的配置文件路径。比如 work 会对应 work.config.toml。

数据流：它创建临时 Codex 主目录，把字符串 work 解析成经过校验的 ProfileV2Name。然后调用 resolve_profile_v2_config_path，确认结果是临时目录下的 work.config.toml 绝对路径。

调用关系：它专门验证 profile 文件命名规则。其他加载和编辑配置的流程会依赖这个规则找到正确文件。

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

async fn set_model_overwrites_existing_model() -> anyhow::Result<()>

作用：测试设置默认模型会覆盖已有默认模型，但不会改动某个 profile 里的模型。profile 可以理解成一套单独的使用场景配置。

数据流：它先写入一个已有 model、model_reasoning_effort 和 profiles.dev.model 的配置文件。然后用 ConfigEditsBuilder 把默认模型改成 o4-mini，推理强度改成 High。读回后确认顶层默认值变了，但 profiles.dev.model 仍是 gpt-4.1。

调用关系：它验证配置编辑器只改该改的层级。set_model 面向顶层默认配置，不能误伤 profiles 下的局部配置。

调用图：调用 1 个内部函数（new）；外部调用 5 个（new, assert_eq!, read_to_string, write, from_str）。

fn cwd_path(&self) -> PathBuf

作用：这个小工具函数返回测试夹具里的当前工作目录路径。它让测试代码不用直接碰内部字段。

数据流：它读取 self.cwd 这个临时目录对象，取出路径，并转换成 PathBuf 返回。它不修改任何状态。

调用关系：它属于测试夹具的辅助方法，其他优先级相关测试可以用它拿到模拟的当前目录。

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

fn codex_home(&self) -> AbsolutePathBuf

作用：这个小工具函数返回测试夹具里的 Codex 主目录绝对路径。Codex 主目录就是放用户配置的地方。

数据流：它读取 self.codex_home，并调用 abs 把路径变成绝对路径返回。它只提供路径，不改文件。

调用关系：它为测试中的配置加载流程提供 codex_home 参数，避免每个测试重复写路径转换。

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

async fn cli_override_sets_compact_prompt() -> std::io::Result<()>

作用：测试命令行覆盖项可以设置 compact_prompt。compact_prompt 是用于“压缩/总结上下文”时的提示词。

数据流：它创建临时 Codex 主目录，构造 ConfigOverrides，把 compact_prompt 设置成一段文字。然后用默认 ConfigToml 加这些覆盖项加载 Config，最后确认 config.compact_prompt 就是覆盖值。

调用关系：它验证命令行参数的优先级能进入最终配置。Config::load_from_base_config_with_overrides 是被测试的主要入口。

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

async fn loads_compact_prompt_from_file() -> std::io::Result<()>

作用：测试 compact_prompt 可以从文件读取，并且会去掉前后空白。这样长提示词可以放在单独文本文件里。

数据流：它创建 workspace 和 compact_prompt.txt，文件内容前后有空格。ConfigToml 指向这个文件，ConfigOverrides 指定当前工作目录。加载配置后，确认 compact_prompt 是去掉空格后的 summarize differently。

调用关系：它覆盖配置加载时读取外部提示词文件的路径。Config::load_from_base_config_with_overrides 负责把 TOML 和覆盖项合成最终 Config。

调用图：外部调用 6 个（default, new, load_from_base_config_with_overrides, assert_eq!, create_dir_all, write）。

async fn load_config_uses_requirements_guardian_policy_config() -> std::io::Result<()>

作用：测试托管的 requirements 配置里可以提供 guardian_policy_config。guardian policy 可以理解成自动审查或安全规则说明。

数据流：它创建 ConfigLayerStack，并在 requirements 层放入带前后空格的 guardian_policy_config。然后调用 Config::load_config_with_layer_stack 加载配置。最终确认 config.guardian_policy_config 被设置，并且前后空格被去掉。

调用关系：它验证配置层堆叠中的托管要求能影响最终配置。ConfigLayerStack 提供上层规则，load_config_with_layer_stack 合并这些规则。

调用图：调用 1 个内部函数（new）；外部调用 6 个（default, new, new, load_config_with_layer_stack, assert_eq!, default）。

fn config_toml_deserializes_auto_review_policy()

作用：测试 config.toml 里的 [auto_review] policy 字段可以被正确解析。也就是文件文本能变成程序里的 ConfigToml 结构。

数据流：它把一段 TOML 字符串交给 toml::from_str 解析成 ConfigToml。然后检查 auto_review.policy 的值等于用户写入的策略文本。

调用关系：这是配置格式本身的解析测试。它不走完整加载流程，只验证 TOML 字段名和结构体字段能对应上。

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

async fn load_config_uses_auto_review_guardian_policy_config() -> std::io::Result<()>

作用：测试用户配置里的 auto_review.policy 会变成最终的 guardian_policy_config，并且会去掉前后空白。

数据流：它构造一个 ConfigToml，其中 auto_review.policy 带前后空格。加载配置后，确认 config.guardian_policy_config 是修剪后的文本。

调用关系：它验证旧一点或用户侧的 auto_review 配置能接到最终配置字段上。主要被测入口是 Config::load_from_base_config_with_overrides。

调用图：外部调用 4 个（default, new, load_from_base_config_with_overrides, assert_eq!）。

async fn requirements_guardian_policy_beats_auto_review() -> std::io::Result<()>

作用：测试当托管 requirements 和用户 auto_review 都提供策略时，托管 requirements 的策略优先。这样组织或工作区强制规则不会被个人配置覆盖。

数据流：它创建一个带托管 guardian_policy_config 的 ConfigLayerStack，同时基础 ConfigToml 里也有 auto_review.policy。加载后，确认最终 guardian_policy_config 使用托管文本，而不是用户文本。

调用关系：它验证配置优先级。Config::load_config_with_layer_stack 合并各层时，requirements 层应该压过普通用户配置。

调用图：调用 1 个内部函数（new）；外部调用 5 个（default, new, new, load_config_with_layer_stack, assert_eq!）。

async fn load_config_ignores_empty_auto_review_guardian_policy_config() -> std::io::Result<()>

作用：测试 auto_review.policy 如果只有空格，就会被当成没配置。这样不会把一段空白当成有效规则。

数据流：它构造 auto_review.policy 为几个空格的 ConfigToml。加载配置后，确认 config.guardian_policy_config 是 None，也就是没有策略。

调用关系：它保护配置清洗逻辑。Config::load_from_base_config_with_overrides 在合成最终配置时应忽略空白字符串。

调用图：外部调用 4 个（default, new, load_from_base_config_with_overrides, assert_eq!）。

async fn load_config_ignores_empty_requirements_guardian_policy_config() -> std::io::Result<()>

作用：测试托管 requirements 里的 guardian_policy_config 如果只有空格，也会被忽略。即使来源更高优先级，空内容也不算有效规则。

数据流：它创建一个 requirements 层，其中 guardian_policy_config 是空白字符串。加载配置后，确认最终 config.guardian_policy_config 为 None。

调用关系：它和用户 auto_review 的空白测试对应，验证高优先级配置也要经过同样的有效性检查。

调用图：调用 1 个内部函数（new）；外部调用 6 个（default, new, new, load_config_with_layer_stack, assert_eq!, default）。

async fn load_config_rejects_missing_agent_role_config_file() -> std::io::Result<()>

作用：测试 Agent 角色引用的 config_file 不存在时，配置加载会报错。这样用户不会以为某个角色已经配置好，实际却缺文件。

数据流：它构造一个 agents.researcher 配置，config_file 指向不存在的 researcher.toml。调用配置加载后期待失败，并检查错误类型是 InvalidInput，错误信息提到 agents.researcher.config_file 和必须指向已有文件。

调用关系：它验证 Config::load_from_base_config_with_overrides 的输入校验。角色配置文件路径必须真实存在，否则加载阶段就阻止继续。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default）。

async fn agent_role_relative_config_file_resolves_against_config_toml() -> std::io::Result<()>

作用：测试 Agent 角色里的相对 config_file 路径，会相对于 config.toml 所在目录解析。这样用户写 ./agents/researcher.toml 会符合直觉。

数据流：它在临时 Codex 主目录下创建 agents/researcher.toml，并在 config.toml 里写相对路径和昵称候选。加载配置后，确认 researcher 角色的 config_file 是实际绝对路径，nickname_candidates 也读出来。

调用关系：它通过 ConfigBuilder 加载真实文件布局，验证角色文件路径解析规则和角色元数据读取。

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

async fn agent_role_relative_config_file_resolves_from_config_layer() -> std::io::Result<()>

作用：测试如果 Agent 角色来自某个配置层，相对 config_file 也会按该层来源文件的位置解析。

数据流：它创建 researcher.toml 文件，再构造一个 ConfigLayerEntry，来源标记为用户 config.toml，内容里写 ./agents/researcher.toml。加载配置层堆叠后，确认最终角色的 config_file 指向真实文件。

调用关系：它验证不只是磁盘上的 config.toml，分层配置来源也带有“基准目录”。ConfigLayerStack 提供来源信息，load_config_with_layer_stack 负责解析。

调用图：调用 1 个内部函数（new）；外部调用 10 个（default, new, load_config_with_layer_stack, assert_eq!, default, default, create_dir_all, write, from_str, vec!）。

async fn agent_role_file_metadata_overrides_config_toml_metadata() -> std::io::Result<()>

作用：测试 Agent 角色文件里的元数据会覆盖 config.toml 里的同名元数据。角色自己的说明文件更具体，所以优先。

数据流：它创建 researcher.toml，里面写 description、nickname_candidates、developer_instructions 和 model；config.toml 里也给 researcher 写了不同的 description 和 nickname_candidates。加载后，确认最终 description 和昵称来自角色文件，config_file 路径正确。

调用关系：它验证角色配置合并顺序。ConfigBuilder 加载 config.toml 后还会读取角色文件，文件内元数据应覆盖外层声明。

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

async fn agent_role_file_without_developer_instructions_is_dropped_with_warning() -> std::io::Result<()>

作用：测试自动发现的独立 Agent 角色文件如果没有 developer_instructions，会被丢弃并给出警告。developer_instructions 是告诉这个角色该怎么工作的核心说明。

数据流：它创建一个模拟 Git 仓库和受信任项目配置，再放两个独立角色文件：researcher 缺 developer_instructions，reviewer 有完整说明。加载配置后，确认 researcher 不在 agent_roles，reviewer 保留，并且 startup_warnings 里有必须定义 developer_instructions 的提示。

调用关系：它覆盖工作区 .codex/agents 自动发现角色的校验。ConfigBuilder 会根据 cwd 找仓库和角色文件，并把不合格文件转成启动警告。

调用图：调用 1 个内部函数（without_managed_config_for_tests）；外部调用 8 个（default, new, assert!, assert_eq!, format!, create_dir_all, create_dir_all, write）。

async fn legacy_agent_role_config_file_allows_missing_developer_instructions() -> std::io::Result<()>

作用：测试旧式通过 config.toml 明确引用的 Agent 角色文件，可以没有 developer_instructions。这样旧用户配置不会突然坏掉。

数据流：它创建一个 researcher.toml，里面只有模型相关配置，没有 developer_instructions。config.toml 里用 [agents.researcher] 明确引用这个文件并提供 description。加载后，确认 researcher 角色仍然存在，description 和 config_file 正确。

调用关系：它体现兼容旧配置的规则：自动发现的角色要求更严格，旧式显式引用的角色更宽松。ConfigBuilder 负责区分这两种来源。

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

async fn agent_role_without_description_after_merge_is_dropped_with_warning() -> std::io::Result<()>

作用：测试 Agent 角色合并完后如果仍然没有 description，会被丢弃并警告。description 是给用户看的角色说明，没有它就不该展示。

数据流：它创建 researcher.toml，里面有 developer_instructions 但没有 description；config.toml 里 researcher 也没有 description，同时还有一个 reviewer 带 description。加载后，确认 researcher 被移除，reviewer 保留，并且启动警告提到 researcher 必须定义 description。

调用关系：它验证角色配置合并后的最终校验。ConfigBuilder 先合并文件和 config.toml，再决定哪些角色可用。

调用图：调用 1 个内部函数（without_managed_config_for_tests）；外部调用 5 个（new, assert!, assert_eq!, create_dir_all, write）。

async fn discovered_agent_role_file_without_name_is_dropped_with_warning() -> std::io::Result<()>

作用：测试自动发现的 Agent 角色文件如果没有非空 name，会被丢弃并警告。name 是角色在系统里的标识。

数据流：它创建受信任仓库和 .codex/agents 目录，放一个缺 name 的 researcher 文件和一个完整 reviewer 文件。加载后，确认 researcher 不存在，reviewer 存在，并且警告里提到必须定义非空 name。

调用关系：它覆盖自动发现角色文件的必填字段检查。ConfigBuilder 扫描工作区角色文件时，会过滤掉缺少 name 的文件。

调用图：调用 1 个内部函数（without_managed_config_for_tests）；外部调用 8 个（default, new, assert!, assert_eq!, format!, create_dir_all, create_dir_all, write）。

async fn agent_role_file_name_takes_precedence_over_config_key() -> std::io::Result<()>

作用：测试角色文件里的 name 会优先于 config.toml 里的配置键。也就是说文件说自己叫 archivist，就不会按 researcher 存。

数据流：它让 config.toml 以 [agents.researcher] 引用 researcher.toml，但文件内部写 name = "archivist"。加载后，确认 agent_roles 里没有 researcher，而有 archivist，并且 description 和 config_file 来自文件。

调用关系：它验证角色身份命名的优先级。ConfigBuilder 读取角色文件后，会用文件内部 name 作为最终键。

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

async fn loads_legacy_split_agent_roles_from_config_toml() -> std::io::Result<()>

作用：测试旧式“config.toml 里列角色、每个角色再指向单独文件”的写法还能正常加载多个角色。

数据流：它创建 researcher.toml 和 reviewer.toml，再在 config.toml 里分别声明两个角色的 description、config_file 和昵称候选。加载后，逐一确认两个角色的说明、配置文件路径和昵称候选都正确。

调用关系：它保护老用户的分离式 Agent 角色配置。ConfigBuilder 要同时读主配置和每个角色文件，并把结果合成 agent_roles。

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

async fn discovers_multiple_standalone_agent_role_files() -> std::io::Result<()>

作用：测试系统能在工作区里发现多个独立 Agent 角色文件，包括仓库根目录和更深层目录中的文件。

数据流：它创建一个受信任的模拟 Git 仓库，当前目录在 packages/app。然后分别在根目录 .codex/agents、packages/.codex/agents 的不同位置放 researcher、reviewer、writer 三个角色文件。加载配置后，确认三个角色都被发现，description 和昵称候选都正确。

调用关系：它验证自动发现 Agent 角色的扫描范围。ConfigBuilder 根据 cwd 和仓库结构查找 .codex/agents，把合格的角色文件加入最终配置。

调用图：调用 1 个内部函数（without_managed_config_for_tests）；外部调用 6 个（default, new, assert_eq!, format!, create_dir_all, write）。

async fn mixed_legacy_and_standalone_agent_role_sources_merge_with_precedence() -> std::io::Result<()>

作用：测试 agent 角色同时写在旧式全局配置和项目里的独立角色文件时，系统会正确合并，并且项目里的文件优先。这样可以避免用户以为项目配置生效了，实际却被旧配置覆盖。

数据流：输入是临时的 codex_home、一个假的 Git 项目、全局 config.toml、全局 agents 文件夹和项目 .codex/agents 文件夹。测试把 researcher、critic、writer 三种角色分别放在不同来源里，再加载配置。输出是断言：researcher 采用项目文件里的说明和昵称，critic 保留全局配置，writer 从项目文件新增进来。

调用关系：它通过 ConfigBuilder::without_managed_config_for_tests 构造测试用配置加载器，并把目录和当前工作目录交给加载流程。最后不再把活交给别的测试，而是用断言验证 agent_roles 的最终结果。

调用图：调用 1 个内部函数（without_managed_config_for_tests）；外部调用 7 个（default, new, assert_eq!, format!, create_dir_all, create_dir_all, write）。

async fn higher_precedence_agent_role_can_inherit_description_from_lower_layer() -> std::io::Result<()>

作用：测试高优先级的 agent 角色文件如果没有写 description，能不能从低优先级配置里继承说明文字。这样用户只改少数字段时，不会把原本有用的描述弄丢。

数据流：输入是一个全局配置里的 researcher 描述和一个项目独立 researcher 文件，项目文件没有 description 但有昵称和模型。加载后，结果应该是 config_file 指向项目文件，昵称来自项目文件，description 则沿用全局配置。

调用关系：它同样使用 ConfigBuilder::without_managed_config_for_tests 走完整配置加载流程，专门验证“优先级覆盖”和“字段继承”这两个规则能一起工作。

调用图：调用 1 个内部函数（without_managed_config_for_tests）；外部调用 7 个（default, new, assert_eq!, format!, create_dir_all, create_dir_all, write）。

async fn load_config_resolves_agent_interrupt_message() -> std::io::Result<()>

作用：测试 agents.interrupt_message 这个开关能从配置里正确读出来。这个开关决定 agent 被打断时是否显示提示消息。

数据流：输入是一个内存里的 ConfigToml，其中 interrupt_message 设置为 false。配置加载后，输出的 config.agent_interrupt_message_enabled 应该也是 false。

调用关系：它直接调用 Config::load_from_base_config_with_overrides，不经过真实 config.toml 文件，专注检查基础配置字段到运行时 Config 字段的转换。

调用图：外部调用 5 个（default, new, load_from_base_config_with_overrides, assert!, default）。

async fn load_config_normalizes_agent_role_nickname_candidates() -> std::io::Result<()>

作用：测试 agent 昵称候选列表会被清理前后空格。这样用户写成 " Hypatia " 时，系统实际使用的是干净的 "Hypatia"。

数据流：输入是一个 researcher 角色，nickname_candidates 里有带空格和不带空格的名字。加载配置后，输出的昵称列表应变成 ["Hypatia", "Noether"]。

调用关系：它调用 Config::load_from_base_config_with_overrides 来走正式的配置解析和校验流程，验证昵称规范化发生在加载阶段。

调用图：外部调用 7 个（from, default, new, load_from_base_config_with_overrides, assert_eq!, default, vec!）。

async fn load_config_rejects_empty_agent_role_nickname_candidates() -> std::io::Result<()>

作用：测试空的 agent 昵称候选列表会被拒绝。空列表没有实际意义，允许它会让后续选择昵称的逻辑变得含糊。

数据流：输入是 nickname_candidates = [] 的 researcher 配置。加载配置不会成功，而是返回 InvalidInput 错误，并且错误文字指出 agents.researcher.nickname_candidates 有问题。

调用关系：它调用 Config::load_from_base_config_with_overrides 并期待失败，用来保护配置校验层：坏配置应该尽早报错，而不是等运行时才出问题。

调用图：外部调用 8 个（from, default, new, new, load_from_base_config_with_overrides, assert!, assert_eq!, default）。

async fn load_config_rejects_duplicate_agent_role_nickname_candidates() -> std::io::Result<()>

作用：测试重复昵称会被拒绝，即使只是前后多了空格也算重复。这样可以避免同一个候选名在列表里出现两次，造成选择或展示混乱。

数据流：输入是 ["Hypatia", " Hypatia "]。加载时先会按规则去空格，然后发现重复，输出 InvalidInput 错误，并说明 nickname_candidates cannot contain duplicates。

调用关系：它依赖 Config::load_from_base_config_with_overrides 的真实校验流程，和昵称清理测试一起覆盖“先清理、再查重”的行为。

调用图：外部调用 8 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default, vec!）。

async fn load_config_rejects_unsafe_agent_role_nickname_candidates() -> std::io::Result<()>

作用：测试昵称里有不安全字符时会被拒绝。这里的“不安全”指尖括号这类可能影响显示或命令拼接的字符。

数据流：输入是昵称 "Agent <One>"。加载配置后得到 InvalidInput 错误，错误说明昵称只能包含 ASCII 字母、数字、空格、连字符和下划线。

调用关系：它调用正式配置加载函数，确认安全字符限制不是只写在文档里，而是真的会阻止配置生效。

调用图：外部调用 8 个（from, default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default, vec!）。

async fn model_catalog_json_loads_from_path() -> std::io::Result<()>

作用：测试用户指定的模型目录 JSON 文件可以被读取。模型目录就是一份“有哪些模型可用、模型信息是什么”的清单。

数据流：输入是一个临时 catalog.json，内容来自内置模型目录但只保留一个模型。配置里指定 model_catalog_json 指向这个文件。加载后，config.model_catalog 应该等于这个 JSON 里的目录对象。

调用关系：它先用 bundled_models_response 拿到合法样例，再通过 Config::load_from_base_config_with_overrides 验证自定义路径的加载逻辑。

调用图：外部调用 8 个（default, new, load_from_base_config_with_overrides, assert_eq!, bundled_models_response, default, to_string, write）。

async fn model_catalog_json_rejects_empty_catalog() -> std::io::Result<()>

作用：测试自定义模型目录不能为空。空目录会让系统不知道能用哪个模型，所以应该在加载配置时直接报错。

数据流：输入是一个内容为 {"models":[]} 的 catalog.json。配置加载失败，输出 InvalidData 错误，并提示目录至少要包含一个模型。

调用关系：它调用 Config::load_from_base_config_with_overrides，验证模型目录读取后还有内容校验，而不是只要 JSON 格式正确就接受。

调用图：外部调用 7 个（default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default, write）。

fn create_test_fixture() -> std::io::Result<PrecedenceTestFixture>

作用：创建一套很多测试共用的假配置环境。它像测试里的“样板房”，里面有基础 TOML、临时当前目录和临时 codex_home。

数据流：输入为空。函数把一段固定 TOML 解析成 ConfigToml，创建临时工作目录，并写一个假的 .git 标记防止向父目录查找 AGENTS.md。输出是 PrecedenceTestFixture，里面装着 cwd、codex_home 和 cfg。

调用关系：它被多个服务等级、profile、遥测配置相关测试调用，让这些测试不用重复搭建基础环境，只需要改自己关心的字段。

调用图：被 13 处调用（config_toml_legacy_fast_service_tier_uses_priority_request_value, config_toml_priority_service_tier_uses_priority_request_value, config_toml_service_tier_accepts_arbitrary_string, default_service_tier_override_uses_default_request_value, explicit_null_service_tier_override_maps_to_default_service_tier, fast_default_opt_out_notice_config_is_respected, legacy_fast_service_tier_override_uses_priority_request_value, legacy_profile_selection_is_rejected, load_config_applies_otel_trace_metadata, load_config_drops_invalid_otel_trace_metadata_entries (+3 more)）；外部调用 3 个（new, write, from_str）。

async fn legacy_profile_selection_is_rejected() -> std::io::Result<()>

作用：测试旧式的 profile = "gpt3" 顶层写法会被拒绝。这样可以避免已经废弃的配置方式继续悄悄影响运行结果。

数据流：输入来自 create_test_fixture，然后把 fixture.cfg.profile 设为 gpt3。加载配置后应失败，输出 InvalidData 错误，并提示 legacy profile selection 不再支持。

调用关系：它先借 create_test_fixture 得到基础配置，再调用 Config::load_from_base_config_with_overrides，专门检查旧配置入口被拦住。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 4 个（default, load_from_base_config_with_overrides, assert!, assert_eq!）。

async fn metrics_exporter_defaults_to_statsig_when_missing() -> std::io::Result<()>

作用：测试没有明确配置指标导出器时，默认使用 Statsig。指标导出器就是把运行指标送到哪里去的设置。

数据流：输入是 create_test_fixture 生成的基础配置，没有额外设置 metrics_exporter。加载后，config.otel.metrics_exporter 应等于 Statsig。

调用关系：它使用通用 fixture 和 Config::load_from_base_config_with_overrides，验证遥测配置的默认值规则。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 3 个（default, load_from_base_config_with_overrides, assert_eq!）。

async fn trace_exporter_defaults_to_none_when_log_exporter_is_set() -> std::io::Result<()>

作用：测试只设置日志导出器时，链路追踪导出器默认是 None。链路追踪是记录一次请求经过哪些步骤的遥测数据。

数据流：输入是一个 otel.exporter，指向 OTLP HTTP 日志端点，同时 metrics_exporter 显式为 None。加载后，otel.exporter 保持 HTTP 导出器，otel.trace_exporter 自动为 None。

调用关系：它在 create_test_fixture 的基础上改 otel 字段，再通过配置加载器验证日志导出和追踪导出不会被错误混用。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 5 个（default, new, load_from_base_config_with_overrides, assert!, assert_eq!）。

async fn load_config_applies_otel_trace_metadata() -> std::io::Result<()>

作用：测试配置里的 OpenTelemetry span_attributes 和 tracestate 能被正确读入。span_attributes 是给追踪片段附加的键值标签，tracestate 是跨系统传递的追踪状态。

数据流：输入是一段 TOML，包含 otel.span_attributes 和 otel.tracestate.example。加载后，config.otel.span_attributes 和 config.otel.tracestate 应精确等于配置里的键值。

调用关系：它借 create_test_fixture 提供目录环境，再调用 Config::load_from_base_config_with_overrides 验证遥测元数据的正常路径。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 4 个（default, load_from_base_config_with_overrides, assert_eq!, from_str）。

async fn load_config_drops_invalid_otel_trace_metadata_entries() -> std::io::Result<()>

作用：测试无效的遥测追踪元数据会被丢弃，并留下启动警告。这样坏条目不会污染遥测数据，用户也能知道哪里写错了。

数据流：输入包含一个空的 span attribute 键、几个带换行的 tracestate 值，以及一些合法条目。加载后，合法条目留下，无效条目被去掉，startup_warnings 里出现对应警告。

调用关系：它调用 Config::load_from_base_config_with_overrides，覆盖遥测配置的“宽容但提醒”策略：不是整份配置失败，而是忽略坏项并警告。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 5 个（default, load_from_base_config_with_overrides, assert!, assert_eq!, from_str）。

async fn explicit_null_service_tier_override_maps_to_default_service_tier() -> std::io::Result<()>

作用：测试命令行或测试覆盖项里显式传入空的 service_tier，会被当成默认服务等级请求值。service_tier 可以理解为请求走哪种服务档位。

数据流：输入是 ConfigOverrides.service_tier = Some(None)。加载后，config.service_tier 变成 SERVICE_TIER_DEFAULT_REQUEST_VALUE，同时 fast_default_opt_out 通知为空。

调用关系：它用 create_test_fixture 建环境，再调用配置加载器，验证覆盖参数里的特殊空值如何映射。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 3 个（default, load_from_base_config_with_overrides, assert_eq!）。

async fn default_service_tier_override_uses_default_request_value() -> std::io::Result<()>

作用：测试 service_tier 覆盖为字符串 "default" 时，会转换成系统真正发送请求用的默认值。这样用户写人类可读的 default，也能得到协议需要的值。

数据流：输入是 ConfigOverrides.service_tier = Some(Some("default"))。加载后，输出的 config.service_tier 是 SERVICE_TIER_DEFAULT_REQUEST_VALUE。

调用关系：它基于 create_test_fixture，检查覆盖参数优先级中的 service_tier 归一化规则。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 3 个（default, load_from_base_config_with_overrides, assert_eq!）。

async fn legacy_fast_service_tier_override_uses_priority_request_value() -> std::io::Result<()>

作用：测试旧名字 "fast" 仍会映射到新的 priority/fast 请求值。这样老用户的命令行参数不会突然失效。

数据流：输入是 service_tier 覆盖值 "fast"。加载后，config.service_tier 等于 ServiceTier::Fast.request_value()。

调用关系：它通过 create_test_fixture 和 Config::load_from_base_config_with_overrides 验证兼容旧写法的转换层。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 3 个（default, load_from_base_config_with_overrides, assert_eq!）。

async fn config_toml_priority_service_tier_uses_priority_request_value() -> std::io::Result<()>

作用：测试 config.toml 里写入新的 fast/priority 请求值时，会原样作为服务等级生效。

数据流：输入是 fixture.cfg.service_tier 设为 ServiceTier::Fast.request_value()。加载后，config.service_tier 保持同一个请求值。

调用关系：它使用 create_test_fixture 搭环境，验证来自配置文件的 service_tier 路径，而不是覆盖参数路径。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 3 个（default, load_from_base_config_with_overrides, assert_eq!）。

async fn config_toml_service_tier_accepts_arbitrary_string() -> std::io::Result<()>

作用：测试 config.toml 允许未知的服务等级字符串。这样实验性服务档位可以先通过配置传下去，不必代码提前枚举所有名字。

数据流：输入是 service_tier = "experimental-tier-id"。加载后，config.service_tier 仍是这个字符串。

调用关系：它用基础 fixture 调用配置加载器，确认 service_tier 对配置文件值是开放字符串，而不是严格枚举。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 3 个（default, load_from_base_config_with_overrides, assert_eq!）。

async fn config_toml_legacy_fast_service_tier_uses_priority_request_value() -> std::io::Result<()>

作用：测试 config.toml 里的旧值 "fast" 会转换成新的 fast 请求值。这样旧配置文件继续可用。

数据流：输入是 fixture.cfg.service_tier = "fast"。加载后，config.service_tier 变成 ServiceTier::Fast.request_value()。

调用关系：它和命令行覆盖的 fast 测试相互补充，确保旧 service_tier 在两个来源里都兼容。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 3 个（default, load_from_base_config_with_overrides, assert_eq!）。

async fn fast_default_opt_out_notice_config_is_respected() -> std::io::Result<()>

作用：测试用户设置 fast_default_opt_out 通知开关时，配置加载后会保留这个设置，并且不会自动设置 service_tier。

数据流：输入是在基础配置上加 notice.fast_default_opt_out = true。加载后，config.service_tier 为 None，config.notices.fast_default_opt_out 为 Some(true)。

调用关系：它借 create_test_fixture 并调用配置加载器，验证 notice 配置不会被服务等级默认值逻辑覆盖。

调用图：调用 1 个内部函数（create_test_fixture）；外部调用 3 个（default, load_from_base_config_with_overrides, assert_eq!）。

async fn test_requirements_web_search_mode_allowlist_does_not_warn_when_unset() -> anyhow::Result<()>

作用：测试当企业要求允许 cached 网页搜索，但用户没有显式配置冲突值时，不应该产生警告。这样正常默认值不会吓到用户。

数据流：输入是一个要求层：允许 Disabled 和 Cached，默认 constrained 值为 Cached；用户配置本身没有 web_search_mode。加载后，startup_warnings 中不应出现 web_search_mode 被要求限制的警告。

调用关系：它先手动构造 ConfigLayerStack，再调用 Config::load_config_with_layer_stack，验证“要求层”和“用户配置层”合并时的警告逻辑。

调用图：调用 4 个内部函数（new, new, new, create_test_fixture）；外部调用 5 个（default, new, load_config_with_layer_stack, assert!, vec!）。

fn test_set_project_trusted_writes_explicit_tables() -> anyhow::Result<()>

作用：测试把项目标记为 trusted 时，会用清晰的 TOML 显式表写法。显式表就是 [projects."路径"] 这种更容易追加字段的格式。

数据流：输入是空的 DocumentMut 和项目路径 /some/path。调用 set_project_trust_level_inner 后，输出文本应正好是一个 projects 子表，trust_level = "trusted"。

调用关系：它直接测试写配置的底层函数 set_project_trust_level_inner，关注写出来的 TOML 形状是否稳定。

调用图：外部调用 4 个（new, new, assert_eq!, format!）。

fn test_set_project_trusted_converts_inline_to_explicit() -> anyhow::Result<()>

作用：测试已有内联项目配置会被转换成显式表。内联配置像一行里的小对象，显式表更适合后续维护。

数据流：输入 TOML 是 [projects] 下的一行内联项目，原本 trust_level 是 untrusted。调用后，输出变成 [projects."路径"] 显式表，并把 trust_level 改成 trusted。

调用关系：它直接调用 set_project_trust_level_inner，验证迁移旧写法时不会只改值，还会改成新的推荐结构。

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

fn test_set_project_trusted_migrates_top_level_inline_projects_preserving_entries() -> anyhow::Result<()>

作用：测试顶层 inline 的 projects 大对象会被迁移成多个显式项目表，并保留已有字段。这样旧配置升级时不会丢用户额外写的内容。

数据流：输入 TOML 里有 toplevel、model 和顶层 projects = { ... }，其中一个项目还有 foo = "bar"。调用后，输出保留 toplevel 和 model，把原项目拆成表，并追加新项目的 trusted 条目。

调用关系：它调用 set_project_trust_level_inner，并用 project_trust_key 生成期望的新项目 key，专门覆盖最复杂的写回迁移场景。

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

async fn active_project_does_not_match_configured_alias_for_canonical_cwd() -> anyhow::Result<()>

作用：测试当前项目路径不会因为符号链接别名而误匹配。符号链接可以理解为文件夹的“快捷方式”，但这里不能把快捷方式当成真实路径混用。

数据流：输入是真实 project_root 和指向它的 alias_root，配置只信任 alias_root。调用 get_active_project 时传入真实 project_root，结果应为 None。

调用关系：它直接测试 ConfigToml::get_active_project 的路径匹配规则，防止通过别名路径绕过项目信任配置。

调用图：外部调用 6 个（default, from, assert_eq!, create_dir_all, symlink, tempdir）。

fn test_set_default_oss_provider() -> std::io::Result<()>

作用：测试默认 OSS 提供方的写入、更新、覆盖和错误处理。OSS 提供方这里指本地或开源模型服务来源，比如 ollama、lmstudio。

数据流：输入是临时 codex_home。函数先在空配置里写 ollama，再在已有 model 的配置里写 lmstudio，再覆盖回 ollama，最后传入 invalid_provider。输出是文件内容符合预期，非法 provider 返回 InvalidInput。

调用关系：它直接调用 set_default_oss_provider，验证这个写配置工具既能保留已有字段，也能拒绝未知提供方。

调用图：外部调用 5 个（new, assert!, assert_eq!, read_to_string, write）。

fn test_set_default_oss_provider_rejects_legacy_ollama_chat_provider() -> std::io::Result<()>

作用：测试已经移除的旧 ollama-chat 提供方不能再被设置。这样用户会得到明确迁移提示，而不是写入一个以后无法使用的配置。

数据流：输入是 LEGACY_OLLAMA_CHAT_PROVIDER_ID。set_default_oss_provider 返回错误，错误类型是 InvalidInput，文字包含 OLLAMA_CHAT_PROVIDER_REMOVED_ERROR。

调用关系：它直接测试 set_default_oss_provider 的特殊拒绝分支，补充普通非法 provider 的测试。

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

async fn test_load_config_rejects_legacy_ollama_chat_provider_with_helpful_error() -> std::io::Result<()>

作用：测试配置加载时遇到旧 ollama-chat provider 会失败，并给出有帮助的错误。这样不是只有写入工具会拦，已有旧配置也会被发现。

数据流：输入是 ConfigToml.model_provider = legacy ollama-chat。加载配置返回 NotFound 错误，错误文字包含移除说明。

调用关系：它调用 Config::load_from_base_config_with_overrides，验证读取已有配置时也复用 provider 校验规则。

调用图：外部调用 6 个（default, new, load_from_base_config_with_overrides, assert!, assert_eq!, default）。

async fn test_untrusted_project_gets_workspace_write_sandbox() -> anyhow::Result<()>

作用：测试不受信任项目默认得到有限写入沙箱。沙箱就是给程序圈出活动范围，防止它随便改系统文件。

数据流：输入是一个 trust_level = untrusted 的项目配置和 active_project。derive_legacy_sandbox_policy_for_test 返回的策略在非 Windows 上应是 WorkspaceWrite，在 Windows 上因为能力限制降为 ReadOnly。

调用关系：它调用 derive_legacy_sandbox_policy_for_test，专门验证旧沙箱策略推导里“不受信任项目”的默认安全边界。

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

async fn derive_sandbox_policy_falls_back_to_read_only_for_implicit_defaults() -> anyhow::Result<()>

作用：测试默认沙箱模式如果不符合要求，会回退到要求允许的只读模式。只读表示可以看文件，但不能写文件。

数据流：输入是一个受信任项目和一个只允许 PermissionProfile::read_only 的约束。推导沙箱策略后，输出应是 SandboxPolicy::new_read_only_policy()。

调用关系：它手动构造 Constrained 约束，再调用 derive_legacy_sandbox_policy_for_test，验证企业或管理要求能压过隐式默认值。

调用图：调用 3 个内部函数（new, derive_legacy_sandbox_policy_for_test, read_only）；外部调用 4 个（default, from, new, assert_eq!）。

async fn derive_sandbox_policy_preserves_windows_downgrade_for_unsupported_fallback() -> anyhow::Result<()>

作用：测试要求允许 workspace-write 时，Windows 上仍会保留降级到只读的行为。因为某些沙箱能力在 Windows 上不一定支持。

数据流：输入是受信任项目和一个允许带写权限的 workspace-write 约束。非 Windows 输出 WorkspaceWrite；Windows 输出 ReadOnly。

调用关系：它通过 derive_legacy_sandbox_policy_for_test 验证两套规则能叠加：先按要求选 fallback，再按平台能力降级。

调用图：调用 3 个内部函数（new, derive_legacy_sandbox_policy_for_test, workspace_write）；外部调用 5 个（default, from, new, assert_eq!, cfg!）。

fn test_resolve_oss_provider_explicit_override()

作用：测试显式传入的 OSS provider 会被直接采用。显式参数通常代表用户这次运行的明确选择。

数据流：输入是 explicit_provider = "custom-provider" 和默认 ConfigToml。resolve_oss_provider 输出 Some("custom-provider")。

调用关系：它直接测试 resolve_oss_provider 的最高优先级分支，不涉及完整配置加载。

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

fn test_resolve_oss_provider_from_global_config()

作用：测试没有显式 provider 时，会从全局配置 oss_provider 读取。这样用户写在 config.toml 里的默认选择能生效。

数据流：输入是 ConfigToml.oss_provider = "global-provider"，显式参数为空。输出 Some("global-provider")。

调用关系：它直接调用 resolve_oss_provider，验证显式参数缺席时的第二优先级来源。

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

fn test_resolve_oss_provider_none_when_not_configured()

作用：测试既没有显式 provider，也没有全局配置时，结果就是 None。这样系统不会凭空猜一个提供方。

数据流：输入是默认 ConfigToml 和 None 显式参数。resolve_oss_provider 输出 None。

调用关系：它直接覆盖 resolve_oss_provider 的空配置分支，和另外几个 OSS provider 优先级测试组成完整规则。

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

fn test_resolve_oss_provider_explicit_overrides_global()

作用：测试显式 provider 会覆盖全局 provider。这样一次性命令参数可以临时改掉默认设置。

数据流：输入是全局 oss_provider = "global-provider"，同时 explicit_provider = "explicit-provider"。输出是 explicit-provider。

调用关系：它直接调用 resolve_oss_provider，确认 OSS provider 的优先级顺序是显式参数高于配置文件。

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

fn config_toml_deserializes_mcp_oauth_callback_port()

作用：测试 TOML 里的 mcp_oauth_callback_port 能被解析到 ConfigToml。MCP OAuth 回调端口是登录授权完成后本地接收回调用的端口。

数据流：输入是一行 TOML：mcp_oauth_callback_port = 4321。toml::from_str 解析后，cfg.mcp_oauth_callback_port 应为 Some(4321)。

调用关系：它只测试反序列化，也就是从文本配置到 ConfigToml 结构的第一步。

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

fn config_toml_deserializes_mcp_oauth_callback_url()

作用：测试 TOML 里的 mcp_oauth_callback_url 能被解析。这个 URL 是 OAuth 登录完成后跳回来的地址。

数据流：输入是一行 TOML，值为 https://example.com/callback。解析后，cfg.mcp_oauth_callback_url 应保存这个字符串。

调用关系：它直接用 toml::from_str 测试 ConfigToml 字段映射，不走完整加载流程。

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

async fn config_loads_mcp_oauth_callback_port_from_toml() -> std::io::Result<()>

作用：测试 MCP OAuth 回调端口不仅能解析，还能进入最终运行时 Config。最终 Config 才是程序运行时真正使用的配置。

数据流：输入是带 model 和 mcp_oauth_callback_port = 5678 的 TOML。解析成 ConfigToml 后加载，输出 config.mcp_oauth_callback_port = Some(5678)。

调用关系：它先 toml::from_str，再调用 Config::load_from_base_config_with_overrides，覆盖从文本到最终配置的完整路径。

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

async fn config_loads_allow_login_shell_from_toml() -> std::io::Result<()>

作用：测试 allow_login_shell = false 会进入权限配置。login shell 是带登录环境的命令行外壳，是否允许会影响命令执行环境。

数据流：输入是 TOML 中 allow_login_shell = false。加载后，config.permissions.allow_login_shell 应为 false。

调用关系：它通过完整配置加载器检查权限字段是否从 TOML 正确搬到运行时 permissions。

调用图：外部调用 5 个（new, load_from_base_config_with_overrides, assert!, default, from_str）。

async fn config_loads_apps_mcp_product_sku_from_toml() -> std::io::Result<()>

作用：测试 apps_mcp_product_sku 字段能从 TOML 进入最终配置。SKU 可以理解为产品或套餐标识。

数据流：输入 TOML 里 apps_mcp_product_sku = "tpp"。加载后，config.apps_mcp_product_sku 应为 Some("tpp")。

调用关系：它使用 Config::load_from_base_config_with_overrides 验证这个应用/MCP 相关字段没有在加载过程中丢失。

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

async fn config_loads_mcp_oauth_callback_url_from_toml() -> std::io::Result<()>

作用：测试 MCP OAuth 回调 URL 能进入最终运行配置。这样授权流程可以使用用户指定的回调地址。

数据流：输入是带 mcp_oauth_callback_url 的 TOML。解析并加载后，config.mcp_oauth_callback_url 应等于该 URL。

调用关系：它和端口加载测试对应，覆盖 OAuth 回调配置的 URL 分支。

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

async fn test_untrusted_project_gets_unless_trusted_approval_policy() -> anyhow::Result<()>

作用：测试不受信任项目会得到 UnlessTrusted 审批策略，并保持安全沙箱。审批策略决定执行敏感操作前是否要问用户。

数据流：输入是把当前临时项目标记为 untrusted 的 ConfigToml。加载后，approval_policy 应为 UnlessTrusted；沙箱在非 Windows 上是 WorkspaceWrite，在 Windows 上是 ReadOnly。

调用关系：它调用完整配置加载器，然后检查 permissions 和 legacy_sandbox_policy，验证项目信任级别同时影响审批和沙箱。

调用图：外部调用 7 个（default, from, new, load_from_base_config_with_overrides, assert!, assert_eq!, cfg!）。

async fn requirements_disallowing_default_sandbox_falls_back_to_required_default() -> std::io::Result<()>

作用：测试企业要求只允许 read-only 沙箱时，默认沙箱会回退到只读。企业要求就是外部管理策略，对用户配置有约束力。

数据流：输入是一个 cloud_config_bundle，内容为 allowed_sandbox_modes = ["read-only"]。ConfigBuilder 构建后，legacy_sandbox_policy 应是只读策略。

调用关系：它使用 ConfigBuilder::without_managed_config_for_tests 加载带企业要求的配置，验证没有用户显式配置时也要遵守要求。

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

async fn explicit_sandbox_mode_falls_back_when_disallowed_by_requirements() -> std::io::Result<()>

作用：测试用户显式写了 danger-full-access，但企业只允许 read-only 时，会回退到只读。danger-full-access 是几乎不设限制的危险模式。

数据流：输入是 config.toml 中 sandbox_mode = "danger-full-access"，以及企业要求只允许 read-only。构建配置后，legacy_sandbox_policy 是只读。

调用关系：它写真实临时 config.toml，再通过 ConfigBuilder 加载，验证企业要求会压过用户文件配置。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 3 个（new, assert_eq!, write）。

async fn windows_sandbox_mode_falls_back_when_disallowed_by_requirements() -> std::io::Result<()>

作用：测试 Windows 沙箱实现如果被企业要求禁止，会回退到允许的实现并产生警告。

数据流：输入是用户配置 windows.sandbox = "unelevated"，企业要求只允许 elevated。加载后，permissions.windows_sandbox_mode 变成 Elevated，并在 startup_warnings 里说明原配置被要求拒绝。

调用关系：它通过 ConfigBuilder 和 CloudConfigBundleFixture 组合用户配置与企业要求，验证 Windows 专属沙箱字段的 fallback 和警告。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 4 个（new, assert!, assert_eq!, write）。

async fn danger_full_access_with_never_is_rejected_when_requirements_force_read_only() -> std::io::Result<()>

作用：测试当用户同时设置 approval_policy = never 和 danger-full-access，但企业强制只读时，配置会被拒绝。never 表示不再询问用户，这和权限被降级后的行为组合起来很危险。

数据流：输入是 config.toml 里的 approval_policy = "never" 和 sandbox_mode = "danger-full-access"，企业只允许 read-only。构建配置失败，输出 InvalidInput，并给出完整解释。

调用关系：它用 ConfigBuilder 走真实加载流程，验证不是所有被要求拦下的危险配置都能静默 fallback；有些组合必须让用户改配置。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 3 个（new, assert_eq!, write）。

async fn named_full_access_profile_with_never_is_rejected_when_requirements_force_read_only() -> std::io::Result<()>

作用：测试通过命名权限 profile 获得全写权限、同时审批策略为 never 时，在企业强制只读下也会被拒绝。

数据流：输入是 approval_policy = "never"、default_permissions = "dev"，并定义 dev.filesystem 的 root 写权限；企业只允许 read-only。构建失败，错误和 danger-full-access 场景一致。

调用关系：它验证同一安全规则不只检查 sandbox_mode 字段，也会识别命名权限 profile 带来的全访问效果。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 3 个（new, assert_eq!, write）。

async fn permission_profile_override_falls_back_when_disallowed_by_requirements() -> std::io::Result<()>

作用：测试通过覆盖参数传入禁用沙箱的权限 profile 时，如果企业只允许只读，会回退到只读。覆盖参数通常来自命令行或测试 harness。

数据流：输入是 ConfigOverrides.permission_profile = PermissionProfile::Disabled，企业要求 allowed_sandbox_modes = ["read-only"]。加载后，legacy_sandbox_policy 和 effective_permission_profile 都是只读。

调用关系：它使用 ConfigBuilder 的 harness_overrides 和 cloud_config_bundle，验证企业要求也能约束运行时覆盖项。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 4 个（default, new, new_read_only_policy, assert_eq!）。

async fn active_profile_is_cleared_when_requirements_force_fallback() -> std::io::Result<()>

作用：测试当默认权限 profile 被企业要求强制回退后，active profile 名称会被清空。这样界面不会误报还在使用原来的危险 profile。

数据流：输入是 default_permissions 覆盖为内置 danger-full-access，企业只允许 read-only。加载后，有效权限是 read_only，active_permission_profile 为 None，并产生对应警告。

调用关系：它用 ConfigBuilder 组合覆盖参数和企业要求，验证 fallback 后状态展示也要同步更新。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 4 个（default, new, assert!, assert_eq!）。

async fn bypass_hook_trust_adds_startup_warning() -> std::io::Result<()>

作用：测试启用危险的绕过 hook 信任检查参数时，会添加启动警告。hook 是自动运行的小脚本，绕过审查可能带来风险。

数据流：输入是 ConfigOverrides.bypass_hook_trust = true。加载后，startup_warnings 中应包含精确警告：启用的 hook 这次运行可能未经审查就执行。

调用关系：它通过 ConfigBuilder 的 harness_overrides 测试一次性危险开关，确保用户启动时会被提醒。

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

async fn permission_profile_override_preserves_split_write_roots() -> std::io::Result<()>

作用：测试自定义权限 profile 里“根目录只读、某个外部目录可写”的拆分写权限不会丢失。

数据流：输入是一个 FileSystemSandboxPolicy：Root 为 Read，outside_root 为 Write，网络为 Restricted。加载后，系统确认 outside_root 可写，旧沙箱视图是 WorkspaceWrite，网络沙箱仍是 Restricted。

调用关系：它先用 PermissionProfile::from_runtime_permissions_with_enforcement 构造复杂权限，再交给 ConfigBuilder，验证新权限模型转成旧沙箱视图时不会把额外写目录抹掉。

调用图：调用 4 个内部函数（without_managed_config_for_tests, from_runtime_permissions_with_enforcement, restricted, from_absolute_path）；外部调用 6 个（default, new, assert!, assert_eq!, create_dir_all, vec!）。

async fn requirements_web_search_mode_overrides_danger_full_access_default() -> std::io::Result<()>

作用：测试企业要求 cached 网页搜索时，即使用户配置了 danger-full-access，最终网页搜索模式也会是 cached。

数据流：输入是 config.toml 中 sandbox_mode = "danger-full-access"，企业要求 allowed_web_search_modes = ["cached"]。加载后，config.web_search_mode 和每轮实际解析值都是 Cached。

调用关系：它通过 ConfigBuilder 加载企业要求，并调用 resolve_web_search_mode_for_turn 检查运行一轮对话时实际会用的搜索模式。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 3 个（new, assert_eq!, write）。

async fn requirements_disallowing_default_approval_falls_back_to_required_default() -> std::io::Result<()>

作用：测试企业要求只允许 on-request 审批时，默认审批策略会回退到 on-request。on-request 表示需要时向用户请求批准。

数据流：输入是一个 untrusted 项目配置，以及企业 allowed_approval_policies = ["on-request"]。加载后，config.permissions.approval_policy.value() 是 OnRequest。

调用关系：它用 ConfigBuilder 加载真实临时配置文件和企业要求，验证项目默认审批策略也受要求约束。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 4 个（new, assert_eq!, format!, write）。

async fn explicit_approval_policy_falls_back_when_disallowed_by_requirements() -> std::io::Result<()>

作用：测试用户显式写了不被允许的 approval_policy 时，会回退到企业允许的 on-request。

数据流：输入是 config.toml 中 approval_policy = "untrusted"，企业只允许 on-request。加载后，审批策略值为 OnRequest。

调用关系：它通过 ConfigBuilder 检查审批策略字段的要求约束逻辑，和沙箱模式 fallback 测试相对应。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 3 个（new, assert_eq!, write）。

async fn feature_requirements_normalize_effective_feature_values() -> std::io::Result<()>

作用：测试企业 feature 要求会正确变成最终功能开关。feature 是程序里的功能开关，比如 personality、shell_tool。

数据流：输入是企业要求 personality = true、shell_tool = false。加载后，Personality 开启，ShellTool 关闭，并且没有“features 被要求覆盖”的无意义警告。

调用关系：它通过 ConfigBuilder 加载 feature_requirements，验证要求层能直接规范最终 feature 状态。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 2 个（new, assert!）。

async fn feature_requirements_auto_review_disables_guardian_approval() -> std::io::Result<()>

作用：测试企业关闭 auto_review 时，也会关闭 GuardianApproval。这里 GuardianApproval 是依赖自动审查能力的相关功能。

数据流：输入是企业要求 auto_review = false。加载后，config.features.enabled(Feature::GuardianApproval) 为 false。

调用关系：它通过 ConfigBuilder 验证 feature 之间的联动规则：一个上游功能被关，下游依赖功能也要关。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 2 个（new, assert!）。

async fn browser_feature_requirements_are_valid() -> std::io::Result<()>

作用：测试浏览器相关 feature 要求可以被正常加载并关闭。这里包括内置浏览器和浏览器使用能力。

数据流：输入是企业要求 in_app_browser = false、browser_use = false。加载后，这两个 Feature 都是关闭状态。

调用关系：它通过 ConfigBuilder 覆盖浏览器功能开关，确认这些 feature 名称和要求解析都是合法的。

调用图：调用 2 个内部函数（loader_with_enterprise_requirement, without_managed_config_for_tests）；外部调用 2 个（new, assert!）。

async fn debug_config_lockfile_export_settings_load_from_nested_table() -> std::io::Result<()>

作用：测试 debug.config_lockfile 这个嵌套表里的导出设置能被读取。config lockfile 是把配置锁定下来方便复现问题的调试文件。

数据流：输入是 config.toml 里的 [debug.config_lockfile]，包含 export_dir、allow_codex_version_mismatch、save_fields_resolved_from_model_catalog。加载后，导出目录被解析成绝对路径，两个布尔开关按配置生效。

调用关系：它用 ConfigBuilder 加载真实临时 config.toml，验证调试锁文件配置从嵌套表进入最终 Config。

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

async fn debug_config_lockfile_load_path_loads_lock_from_nested_table() -> std::io::Result<()>

作用：测试 debug.config_lockfile.load_path 能从指定路径加载配置锁文件。这样调试时可以强制使用某份锁定配置。

数据流：输入是一份临时 session.config.lock.toml，以及 config.toml 里指向它的 load_path 和相关开关。加载后，config.config_lock_toml 有值，并且版本不匹配允许、保存模型目录解析字段关闭。

调用关系：它先写锁文件，再让 ConfigBuilder 读取嵌套 debug 配置，验证加载路径和锁文件读取流程能串起来。

调用图：调用 1 个内部函数（without_managed_config_for_tests）；外部调用 4 个（new, assert!, format!, write）。

async fn explicit_feature_config_is_normalized_by_requirements() -> std::io::Result<()>

作用：确认企业下发的功能要求会压过用户自己写的功能开关，而且不会把这种正常覆盖误报成警告。

数据流：进去的是一个临时配置文件，用户写着 personality 关、shell_tool 开；同时还有一份企业要求，写着 personality 开、shell_tool 关。测试加载配置后，检查出来的结果变成企业要求的样子，并确认启动警告里没有把 features 配置说成有问题。

调用关系：测试运行器执行它；它先用 CloudConfigBundleFixture::loader_with_enterprise_requirement 准备企业要求，再交给 ConfigBuilder::without_managed_config_for_tests 构造配置，最后用断言检查加载结果。