插件、扩展、技能、MCP 和工具测试

fn write_file(path: &Path, contents: &str)

作用：把一段文字写到指定文件里，并且会先自动创建父目录。测试里用它来省掉反复写“先建目录再写文件”的样板代码。

数据流：输入是一个文件路径和要写入的文字。它先找到这个文件所在的文件夹，把文件夹创建好；然后把文字写进文件。结果是磁盘上多了这个文件，或者原文件内容被替换。

调用关系：它是这个测试工具箱里最底层的写文件小帮手。write_curated_plugin、write_curated_marketplace 和 write_curated_plugin_sha_with 都会把具体内容准备好，再交给它真正落到磁盘上。

调用图：被 3 处调用（write_curated_marketplace, write_curated_plugin, write_curated_plugin_sha_with）；外部调用 3 个（parent, create_dir_all, write）。

fn write_curated_plugin(root: &Path, plugin_name: &str)

作用：创建一个假的“精选插件”目录。这个插件带有基本说明、一个技能文件、一个 MCP 服务配置和一个应用连接器配置，用来让测试看到完整插件长什么样。

数据流：输入是测试根目录和插件名。它会在 root/plugins/插件名 下面写出几类文件：plugin.json 说明插件是谁，SKILL.md 模拟技能，.mcp.json 模拟外部工具服务，.app.json 模拟应用连接器。结果是测试目录里出现一个可被插件系统读取的假插件。

调用关系：它通常不是单独被测试直接关心，而是由 write_curated_marketplace 调用。市场清单写好后，还需要每个插件真的有文件存在，于是这个函数负责把插件实体补齐。

调用图：调用 1 个内部函数（write_file）；被 1 处调用（write_curated_marketplace）；外部调用 2 个（join, format!）。

fn write_openai_curated_marketplace(root: &Path, plugin_names: &[&str])

作用：生成一个普通的 OpenAI 精选插件市场清单。测试可以用它模拟“系统自带的精选插件列表”。

数据流：输入是测试根目录和一组插件名。它把这些信息交给通用的 write_curated_marketplace，并指定清单文件名为 marketplace.json、市场名为普通 OpenAI 精选市场名。结果是磁盘上出现对应市场清单和插件目录。

调用关系：它是 write_curated_marketplace 的一个方便入口。调用者不用记具体文件名和市场常量，只要说要哪些插件，它就负责按普通精选市场的格式生成。

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

fn write_openai_api_curated_marketplace(root: &Path, plugin_names: &[&str])

作用：生成一个 API 场景使用的 OpenAI 精选插件市场清单。它和普通市场类似，但文件名和展示名称不同，用来测试直接走 API 鉴权时的插件回退和缓存刷新行为。

数据流：输入是测试根目录和插件名列表。它调用通用市场写入函数，指定 api_marketplace.json、API 精选市场名，并额外写入展示名 OpenAI Curated。结果是测试环境里有一份 API 专用的精选插件市场。

调用关系：它是 API 精选市场测试的快捷入口。相关测试会调用它搭好市场文件，然后后续插件加载或缓存刷新逻辑再读取这些文件，验证系统能找到正确插件。

调用图：调用 1 个内部函数（write_curated_marketplace）；被 2 处调用（returns_api_curated_fallback_plugins_for_direct_provider_auth, refresh_curated_plugin_cache_reinstalls_missing_api_curated_plugin）。

fn write_curated_marketplace(
    root: &Path,
    manifest_name: &str,
    marketplace_name: &str,
    display_name: Option<&str>,
    plugin_names: &[&str],
)

作用：按给定市场名和插件列表，写出一份完整的插件市场清单，并顺手创建清单里提到的插件。它是生成测试市场的核心函数。

数据流：输入是根目录、清单文件名、市场名、可选展示名和插件名列表。它先把每个插件名拼成 JSON 片段，说明插件来自本地路径；如果有展示名，就加上界面展示信息；然后把完整市场 JSON 写到 root/.agents/plugins/清单文件名。最后，它逐个调用 write_curated_plugin，把清单里列出的插件目录也创建出来。

调用关系：write_openai_curated_marketplace 和 write_openai_api_curated_marketplace 都把具体参数交给它。它再向下调用 write_file 写市场文件，调用 write_curated_plugin 创建每个插件，是这组测试造数函数的中间枢纽。

调用图：调用 2 个内部函数（write_curated_plugin, write_file）；被 2 处调用（write_openai_api_curated_marketplace, write_openai_curated_marketplace）；外部调用 2 个（join, format!）。

fn write_curated_plugin_sha_with(codex_home: &Path, sha: &str)

作用：写入一个假的精选插件 SHA 值。SHA 可以理解成一串版本指纹，测试用它来模拟“当前缓存对应哪个插件版本”。

数据流：输入是 Codex 主目录和一段 SHA 字符串。它把这段字符串加上换行，写到 .tmp/plugins.sha。结果是测试环境里出现一个缓存版本标记文件。

调用关系：它使用 write_file 完成实际写入。测试在需要模拟插件缓存已存在、缓存版本变化或缓存校验时，会先用它放好这个版本指纹。

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

async fn load_plugins_config(codex_home: &Path, cwd: &Path) -> PluginsConfigInput

作用：按测试方式加载插件配置，并整理成插件系统需要的输入对象。它让测试不用自己理解完整配置加载流程，也能拿到一份真实形态的配置。

数据流：输入是 Codex 主目录和当前工作目录。它先把这两个路径确认成绝对路径，也就是从磁盘根位置开始的完整路径；然后调用配置加载器读取各层配置，但关闭测试里不需要的受管配置；接着取出最终生效的配置，读取 plugins 和 remote_plugin 两个功能开关；最后创建 PluginsConfigInput，里面带着配置层信息、开关状态和固定的后端 API 地址。

调用关系：它位于测试准备阶段，通常在测试需要真正跑插件配置逻辑前调用。它把底层配置加载工作交给 load_config_layers_state，把功能开关判断交给 feature_enabled，最后组装出插件模块能直接使用的输入。

调用图：调用 5 个内部函数（load_config_layers_state, without_managed_config_for_tests, new, feature_enabled, try_from）；外部调用 1 个（as_path）。

fn feature_enabled(config: &Value, key: &str, default_enabled: bool) -> bool

作用：从配置里读取某个功能开关是否开启。如果配置没有写这个开关，就使用调用者给的默认值。

数据流：输入是一份 TOML 配置值、功能名和默认开关值。它先找配置里的 features 表，再找指定功能名，确认它是不是布尔值，也就是 true 或 false。找到就返回配置值；找不到或格式不对，就返回默认值。

调用关系：它是 load_plugins_config 里的小判断器。load_plugins_config 用它分别判断 plugins 和 remote_plugin 是否启用，从而决定测试里的插件功能应该按什么状态运行。

调用图：被 1 处调用（load_plugins_config）；外部调用 1 个（get）。

fn absolute(path: impl AsRef<std::path::Path>) -> AbsolutePathBuf

作用：这个小工具把测试里拼出来的路径变成系统认可的“绝对路径”。测试用它来保证后面的逻辑拿到的是完整路径，而不是相对路径。

数据流：进去的是一个路径对象 → 它先把路径按普通路径引用出来，再检查这个路径确实是绝对路径 → 出来的是一个 AbsolutePathBuf；如果测试传了非绝对路径，它会直接报错，让测试失败。

调用关系：两个测试都会先用 absolute 准备插件根目录和资源文件路径。它把路径准备好后，再交给 ResolvedPlugin::from_environment 去验证和包装。

调用图：调用 1 个内部函数（from_absolute_path_checked）；被 2 处调用（environment_descriptor_binds_every_manifest_resource, environment_descriptor_rejects_resources_outside_package_root）；外部调用 1 个（as_ref）。

fn resource(environment_id: &str, path: AbsolutePathBuf) -> PluginResourceLocator

作用：这个小工具用来造一个“某个环境里的某个资源”的期望值。测试用它来和真正解析出来的结果做对比。

数据流：进去的是环境编号和一个绝对路径 → 它把环境编号转成字符串，并和路径一起放进 PluginResourceLocator::Environment → 出来的是一个带环境来源的资源定位对象。

调用关系：environment_descriptor_binds_every_manifest_resource 用它生成期望答案，再用 assert_eq! 和 ResolvedPlugin::from_environment 产生的实际结果比较，确认每个资源都贴上了正确的环境编号。

fn environment_descriptor_binds_every_manifest_resource()

作用：这个测试确认：插件清单里所有能指向文件的地方，都会被正确改成“来自 executor-1 这个环境的资源”。这样后续系统不会误以为这些只是本机普通路径。

数据流：进去没有外部参数，测试自己从当前目录拼出一个插件根目录和多个资源路径 → 它构造一份带技能、MCP 配置、应用配置、钩子、图标、Logo、截图的 PluginManifest → 调用 ResolvedPlugin::from_environment 解析这份清单 → 最后检查解析后的 manifest_path 和 manifest 里每个资源都变成了带 executor-1 环境编号的 PluginResourceLocator。

调用关系：这是正常场景测试。它先借助 absolute 造绝对路径，再调用 ResolvedPlugin::from_environment 做真正的绑定工作，最后用 resource 造出期望结果并用 assert_eq! 校验。

调用图：调用 3 个内部函数（default, from_environment, absolute）；外部调用 5 个（new, assert_eq!, Paths, current_dir, vec!）。

fn environment_descriptor_rejects_resources_outside_package_root()

作用：这个测试确认：如果插件清单把资源指到了插件根目录外面，系统会拒绝它。这样可以防止插件越界读取或引用不属于自己的文件。

数据流：进去没有外部参数，测试自己准备一个插件根目录和一个位于外部目录的 .mcp.json 路径 → 它构造一份把 mcp_servers 指到外部路径的 PluginManifest → 调用 ResolvedPlugin::from_environment，并期待它失败 → 出来的是一个 ResourceOutsideRoot 错误，里面明确说明根目录是什么、越界路径是什么。

调用关系：这是异常场景测试。它用 absolute 准备根目录和越界路径，把清单交给 ResolvedPlugin::from_environment；这个函数应该发现问题并返回错误，测试再用 assert_eq! 确认错误类型和内容完全正确。

调用图：调用 2 个内部函数（from_environment, absolute）；外部调用 3 个（new, assert_eq!, current_dir）。

fn unsupported() -> FileSystemResult<T>

作用：这个小工具函数统一返回“这个文件系统操作不支持”。测试里的假文件系统只想模拟插件解析会用到的少数操作，其他操作如果被调用，就说明代码走偏了。

数据流：进去没有实际业务数据 → 它创建一个输入输出错误，错误类型是“不支持” → 出来是一个失败结果，告诉调用方这个操作不该在本测试里发生。

调用关系：它被假文件系统中大多数不用的接口方法借用，比如 canonicalize、write_file、copy 等。这样这些方法不用各写一遍错误，也能清楚表达：插件解析流程不应该依赖这些能力。

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

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

作用：这是假的“规范化路径”接口。规范化路径就是把路径整理成标准样子，但这个测试不希望插件解析用到它，所以这里直接报不支持。

数据流：进去是一个路径和可选的沙箱上下文 → 它没有真正处理路径，只把工作包装成异步结果 → 出来是 unsupported 产生的失败结果。

调用关系：它实现的是 ExecutorFileSystem 这个文件系统接口的一部分。若被插件解析流程意外调用，测试会因为“不支持”而暴露问题。

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

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

作用：这个函数模拟读取文件，主要用来假装读插件清单。它还会记录自己读过哪个路径，方便测试确认读取顺序和读取位置。

数据流：进去是一个文件路径 → 它先把路径转成绝对路径，记下一条 Read 调用记录；如果路径正好是测试预设的清单文件，就返回清单内容的字节；否则返回“找不到” → 出来要么是清单内容，要么是读取失败。

调用关系：在测试 plugin_root_resolution_uses_supplied_executor_file_system 里，resolve_plugin_root 解析插件时会通过这个假文件系统读取清单。测试最后会检查调用记录，确认它确实读的是执行器文件系统里的清单。

调用图：调用 1 个内部函数（to_abs_path）；外部调用 4 个（pin, new, Read, clone）。

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

作用：这是假的“流式读文件”接口。流式读就是一边读一边处理大文件，但插件解析不需要它，所以这里故意不支持。

数据流：进去是路径和可选沙箱上下文 → 它不读取任何内容，只返回一个异步失败 → 出来是“不支持”的错误。

调用关系：它只是为了完整实现 ExecutorFileSystem 接口。如果插件解析错误地改成用流式读取，这个测试会立刻失败。

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

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

作用：这是假的写文件接口。插件解析只应该读信息，不应该写文件，所以这里直接拒绝。

数据流：进去是目标路径、要写入的字节内容和可选沙箱上下文 → 它忽略这些输入，不做磁盘修改 → 出来是“不支持”的错误。

调用关系：它作为假文件系统的一部分存在，目的是守住测试边界：解析插件时如果开始写东西，就是异常行为。

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

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

作用：这是假的创建目录接口。测试里的插件解析流程不应该新建目录，因此这个函数总是报不支持。

数据流：进去是目录路径、创建选项和可选沙箱上下文 → 它不创建任何目录 → 出来是“不支持”的错误。

调用关系：它补齐 ExecutorFileSystem 接口。只要解析流程意外尝试创建目录，测试就会因为这个函数的错误结果而发现问题。

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

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

作用：这个函数模拟查询文件或目录的基本信息，比如“这是目录还是文件”。插件解析需要靠它判断插件根目录和清单文件是否存在。

数据流：进去是一个路径 → 它转成绝对路径，记下一条 Metadata 调用记录；如果路径是插件根目录，就返回“这是目录”；如果路径是清单文件，就返回“这是文件”；其他路径返回“找不到” → 出来是文件信息或错误。

调用关系：在 plugin_root_resolution_uses_supplied_executor_file_system 中，resolve_plugin_root 会先用它确认根目录，再确认清单文件。测试最后核对记录，确保检查顺序是根目录、清单文件、读取清单。

调用图：调用 1 个内部函数（to_abs_path）；外部调用 4 个（pin, new, Metadata, clone）。

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

作用：这是假的读取目录列表接口。插件解析不靠列目录来找东西，而是检查固定位置的清单，所以这里不支持。

数据流：进去是目录路径和可选沙箱上下文 → 它不列出任何目录内容 → 出来是“不支持”的错误。

调用关系：它用于保证插件解析不是靠扫描目录碰运气。如果未来代码改成读目录，这个测试会提醒维护者注意行为变化。

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

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

作用：这是假的删除接口。解析插件绝不应该删除文件或目录，所以它总是拒绝。

数据流：进去是路径、删除选项和可选沙箱上下文 → 它不删除任何东西 → 出来是“不支持”的错误。

调用关系：它只是为了实现文件系统接口。若解析流程误触删除操作，测试会马上失败，避免危险行为被悄悄引入。

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

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

作用：这是假的复制接口。插件解析只需要确认和读取清单，不应该复制文件，因此这里报不支持。

数据流：进去是源路径、目标路径、复制选项和可选沙箱上下文 → 它不复制任何文件 → 出来是“不支持”的错误。

调用关系：它补全假文件系统接口，并作为一条警戒线：解析插件时如果需要复制文件，就不符合这些测试假设。

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

fn write_manifest(plugin_root: &Path, relative_path: &str, contents: &str)

作用：这个辅助函数在临时测试目录里写一个插件清单文件。测试用它快速搭出“有清单”“清单坏掉”“有备用清单”等场景。

数据流：进去是插件根目录、清单的相对路径和清单文本 → 它拼出完整路径，先创建父目录，再把文本写进文件 → 出来没有返回值，但磁盘上的临时目录多了一个清单文件。

调用关系：它被 unavailable_environment_does_not_fall_back_to_host_filesystem 和 malformed_preferred_manifest_does_not_fall_through_to_alternate 使用，用来准备真实临时文件，方便测试 Provider 面对本机文件时的行为。

调用图：被 2 处调用（malformed_preferred_manifest_does_not_fall_through_to_alternate, unavailable_environment_does_not_fall_back_to_host_filesystem）；外部调用 3 个（join, create_dir_all, write）。

fn selected_root(id: &str, environment_id: &str, path: &Path) -> SelectedCapabilityRoot

作用：这个辅助函数生成一个“用户选中的能力根目录”。可以把它理解成一张地址卡：告诉系统这个目录叫什么、在哪个环境里、路径是什么。

数据流：进去是根目录 ID、环境 ID 和本机路径 → 它把路径转成字符串，包进 SelectedCapabilityRoot 结构里，并标明位置来自某个执行环境 → 出来是一份测试可直接传给解析器的选择记录。

调用关系：多个测试都用它来少写重复代码。它把测试数据整理成 resolve 或 resolve_plugin_root 需要的格式，让每个测试能专心表达自己要验证的场景。

调用图：被 4 处调用（malformed_preferred_manifest_does_not_fall_through_to_alternate, plugin_root_resolution_uses_supplied_executor_file_system, standalone_capability_root_is_not_a_plugin, unavailable_environment_does_not_fall_back_to_host_filesystem）；外部调用 1 个（to_string_lossy）。

async fn plugin_root_resolution_uses_supplied_executor_file_system()

作用：这个测试确认：解析执行器里的插件时，系统真的使用传入的执行器文件系统，而不是偷偷去读本机文件系统。它还检查读取步骤是否符合预期。

数据流：开始时创建一个临时路径，但不在本机磁盘上创建插件目录 → 它准备好期望的清单解析结果，再构造只存在于假文件系统里的插件根目录和清单 → 调用 resolve_plugin_root 后，得到一个解析出的插件描述，并检查假文件系统记录到的调用顺序。

调用关系：它直接测试底层的 resolve_plugin_root。过程中用 selected_root 做输入，用 parse_plugin_manifest 生成期望结果，最后验证 SyntheticPluginFileSystem::get_metadata 和 SyntheticPluginFileSystem::read_file 被按顺序使用。

调用图：调用 3 个内部函数（parse_plugin_manifest, selected_root, from_absolute_path_checked）；外部调用 6 个（new, new, assert!, assert_eq!, resolve_plugin_root, tempdir）。

async fn standalone_capability_root_is_not_a_plugin()

作用：这个测试确认：一个普通目录即使被用户选中，也不会自动被当成插件。只有带正确插件清单的位置才会被识别。

数据流：开始时创建一个真实临时目录，但不写插件清单 → 它用默认测试环境创建插件提供器，再把这个目录作为选中的根传进去 → 出来是 None，意思是“这里没有插件”。

调用关系：它测试 ExecutorPluginProvider::resolve 的正常否定路径。selected_root 负责构造输入，EnvironmentManager::default_for_tests 提供本地测试环境，最后断言结果不是插件。

调用图：调用 3 个内部函数（new, selected_root, default_for_tests）；外部调用 4 个（new, assert_eq!, create_dir_all, tempdir）。

async fn unavailable_environment_does_not_fall_back_to_host_filesystem()

作用：这个测试确认：如果用户选的环境不存在，系统必须报错，不能退而求其次去读本机硬盘上的同一路径。这个行为对隔离和安全很重要。

数据流：开始时在本机临时目录里真的写了一个插件清单 → 但它创建的环境管理器没有任何可用环境 → 调用解析时使用一个不存在的环境 ID → 出来是明确错误，说明这个环境不可用，而不是解析成本机插件。

调用关系：它用 write_manifest 布置一个容易误读成功的陷阱，再用 ExecutorPluginProvider::resolve 验证 Provider 不会掉进这个陷阱。selected_root 提供带缺失环境 ID 的输入。

调用图：调用 4 个内部函数（new, selected_root, write_manifest, without_environments）；外部调用 3 个（new, assert_eq!, tempdir）。

async fn malformed_preferred_manifest_does_not_fall_through_to_alternate()

作用：这个测试确认：首选位置的插件清单如果存在但格式坏了，系统要直接报错，不能悄悄改去读备用位置的清单。这样能避免隐藏真正的问题。

数据流：开始时在 .codex-plugin/plugin.json 写入坏 JSON，又在 .claude-plugin/plugin.json 写入正常清单 → 调用 Provider 解析插件 → 出来是首选清单的解析错误，并且错误里带着首选清单路径和根目录 ID。

调用关系：它用 write_manifest 同时准备坏的首选清单和好的备用清单，然后让 ExecutorPluginProvider::resolve 做判断。测试通过匹配 ExecutorPluginProviderError::ParseManifest 来确认错误没有被备用清单掩盖。

调用图：调用 5 个内部函数（new, selected_root, write_manifest, default_for_tests, from_absolute_path_checked）；外部调用 4 个（new, assert_eq!, panic!, tempdir）。

async fn executor_root_must_be_an_explicit_absolute_path()

作用：这个测试确认：执行器环境里的插件路径必须是明确的绝对路径，不能写成 ~/plugins/demo 这种依赖个人主目录展开的形式。这样可以避免不同机器或环境解释路径不一致。

数据流：进去的测试数据是一个路径字符串 ~/plugins/demo，看起来像家目录相对路径，但不是绝对路径 → 它把这份选择记录交给 Provider 解析 → 出来是错误信息，明确说执行器路径必须是绝对路径。

调用关系：它直接构造 SelectedCapabilityRoot，不用 selected_root，因为要保留这个特殊的非法路径字符串。随后调用 ExecutorPluginProvider::resolve，检查路径校验这道门是否挡住了错误输入。

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

fn write_plugin_with_version(
    root: &Path,
    dir_name: &str,
    manifest_name: &str,
    manifest_version: Option<&str>,
)

作用：这是测试用的小工具，用来在临时目录里造一个假的插件。它可以顺便给插件说明文件写入指定版本，方便后面的测试模拟不同版本的插件。

数据流：进去的是根目录、插件文件夹名、plugin.json 里的插件名，以及可选版本号；它创建插件目录、.codex-plugin 目录和 skills 目录，写入 plugin.json、SKILL.md、.mcp.json；出来没有返回值，但磁盘上多了一个可被安装逻辑识别的假插件。

调用关系：它是很多安装和版本测试的准备步骤。write_plugin 会把简单场景转交给它；需要指定版本或空版本的测试，比如 install_uses_manifest_version_when_present、install_rejects_blank_manifest_version、install_with_new_version_keeps_existing_plugin_root_and_prunes_old_versions，会直接调用它。

调用图：被 4 处调用（install_rejects_blank_manifest_version, install_uses_manifest_version_when_present, install_with_new_version_keeps_existing_plugin_root_and_prunes_old_versions, write_plugin）；外部调用 4 个（join, format!, create_dir_all, write）。

fn write_plugin(root: &Path, dir_name: &str, manifest_name: &str)

作用：这是更简单的造插件工具，用来创建没有显式版本号的假插件。大多数测试只关心名字和目录，所以用它就够了。

数据流：进去的是根目录、目录名和插件名；它把版本号留空，然后调用 write_plugin_with_version；结果是在临时目录里生成一个默认会被当成 local 版本的测试插件。

调用关系：它处在测试准备流程的最前面，给安装、路径、安全检查等测试提供样本插件。它自己不写细节，而是把真正的建目录和写文件工作交给 write_plugin_with_version。

调用图：调用 1 个内部函数（write_plugin_with_version）；被 9 处调用（active_plugin_version_compares_semver_versions_semantically, active_plugin_version_prefers_default_local_version_when_multiple_versions_exist, active_plugin_version_reads_version_directory_name, active_plugin_version_returns_latest_version_when_default_is_missing, install_copies_plugin_into_default_marketplace, install_rejects_manifest_names_that_do_not_match_marketplace_plugin_name, install_rejects_manifest_names_with_path_separators, install_uses_manifest_name_for_destination_and_key, install_with_version_uses_requested_cache_version）。

fn try_new_rejects_relative_codex_home()

作用：这个测试确认 PluginStore 不接受相对路径作为 Codex 主目录。这样可以避免程序把插件缓存建到不确定的位置。

数据流：进去的是一个写死的相对路径 relative；它调用 PluginStore::try_new，期待得到错误；最后把错误信息标准化后比对，确认错误明确指出路径不是绝对路径。

调用关系：这是初始化阶段的安全测试。它直接测试 try_new 的失败分支，不依赖假插件，也不进入安装流程。

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

fn install_copies_plugin_into_default_marketplace()

作用：这个测试确认安装一个普通本地插件时，文件会被复制到默认规则下的缓存目录。它保证安装后 plugin.json 和技能文件真的存在。

数据流：先创建临时目录和假插件，再构造插件编号 PluginId；调用 PluginStore::new 后执行 install；最后检查返回的插件编号、版本 local、安装路径，以及目标目录里的关键文件。

调用关系：它覆盖最基础的安装成功流程。准备工作由 write_plugin 完成，真正安装交给 PluginStore 的 install，测试用断言确认结果对象和磁盘文件都正确。

调用图：调用 4 个内部函数（new, write_plugin, new, try_from）；外部调用 3 个（assert!, assert_eq!, tempdir）。

fn install_uses_manifest_name_for_destination_and_key()

作用：这个测试确认插件最终存放位置用的是 plugin.json 里的名字，而不是源文件夹名字。这样即使下载目录叫 source-dir，真正登记的插件名也不会乱。

数据流：它创建一个目录名为 source-dir、清单名为 manifest-name 的插件；安装时传入对应的 PluginId；安装完成后检查返回路径是否落在 plugins/cache/market/manifest-name/local。

调用关系：它测试 install 读取插件清单后决定目标位置的行为。write_plugin 负责制造“目录名和清单名不同”的场景，install 负责解析并放置插件。

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

fn plugin_root_derives_path_from_key_and_version()

作用：这个测试确认 PluginStore 能根据插件编号和版本号算出插件安装根目录。也就是验证“这件货该放到货架哪一格”的路径规则。

数据流：进去的是临时 Codex 主目录、插件名 sample、市场名 debug、版本 local；它调用 plugin_root 计算路径；出来的结果要等于 plugins/cache/debug/sample/local。

调用关系：它不安装文件，只检查路径计算。这个路径规则会被安装、查找已安装插件等流程依赖。

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

fn plugin_data_root_derives_path_from_key()

作用：这个测试确认插件自己的数据目录按插件编号生成，而不是和安装缓存目录混在一起。这样插件代码和插件运行数据可以分开放。

数据流：进去的是临时主目录和 PluginId；它调用 plugin_data_root；结果应该是 plugins/data/sample-debug 这样的目录路径。

调用关系：它测试数据目录的命名规则。这个规则独立于安装版本，因为数据通常跟插件身份有关，而不是跟某个缓存版本强绑定。

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

fn install_with_version_uses_requested_cache_version()

作用：这个测试确认当调用方明确指定缓存版本时，安装目录会使用这个版本号。它用于模拟从市场下载到某个固定版本或哈希的插件。

数据流：它先造一个没有版本号的插件，再指定 plugin_version 为一串字符；调用 install_with_version；最后确认结果里的版本和目标目录都使用这串指定版本，并且 plugin.json 被复制过去。

调用关系：它测试 install_with_version 这条显式版本安装路线。write_plugin 只负责造源插件，版本选择不看清单，而是由调用 install_with_version 时传入的参数决定。

调用图：调用 4 个内部函数（new, write_plugin, new, try_from）；外部调用 4 个（assert!, assert_eq!, format!, tempdir）。

fn install_uses_manifest_version_when_present()

作用：这个测试确认 plugin.json 里写了版本号时，普通 install 会采用这个版本号，而不是默认 local。这样插件包自己声明的版本能被尊重。

数据流：它创建一个清单版本为 1.2.3-beta+7 的假插件；调用 install；结果应该显示插件版本是这个清单版本，安装路径也以这个版本结尾，并且文件存在。

调用关系：它覆盖 install 的版本读取逻辑。准备阶段由 write_plugin_with_version 写入版本，安装阶段读取 plugin.json 并决定缓存目录名。

调用图：调用 4 个内部函数（new, write_plugin_with_version, new, try_from）；外部调用 3 个（assert!, assert_eq!, tempdir）。

fn install_rejects_blank_manifest_version()

作用：这个测试确认 plugin.json 里的版本号不能只是空白字符。这样可以防止出现看起来有版本、实际无法管理的插件目录。

数据流：它创建一个版本字段为几个空格的插件；调用 install；期待失败，并检查错误信息是“插件版本不能为空”。

调用关系：它测试安装前的输入校验。write_plugin_with_version 制造坏清单，install 读取后必须拒绝，而不是继续复制文件。

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

fn active_plugin_version_reads_version_directory_name()

作用：这个测试确认 PluginStore 能从缓存目录里的版本文件夹名判断当前可用版本。也就是说，不需要额外数据库，也能知道装了哪个版本。

数据流：它直接在 plugins/cache/debug/sample-plugin/local 下写入一个假插件；然后调用 active_plugin_version 和 active_plugin_root；结果应分别返回 local 和对应目录。

调用关系：它测试已安装插件的发现逻辑。write_plugin 直接把目录摆成缓存结构，PluginStore 只负责扫描和推断当前生效位置。

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

fn active_plugin_version_prefers_default_local_version_when_multiple_versions_exist()

作用：这个测试确认如果 local 版本和其他版本同时存在，local 会优先生效。local 可以理解成本地开发版，系统优先让它覆盖市场缓存版本。

数据流：它在同一个插件下面创建一个哈希版本目录和一个 local 目录；调用 active_plugin_version；结果必须是 local。

调用关系：它测试版本选择的优先级。write_plugin 负责造出多个版本目录，active_plugin_version 负责按规则选出当前版本。

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

fn active_plugin_version_returns_latest_version_when_default_is_missing()

作用：这个测试确认没有 local 版本时，PluginStore 会在已有版本里选最新的那个。这样用户不会意外继续使用较旧缓存。

数据流：它创建两个非 local 的版本目录：0123456789abcdef 和 fedcba9876543210；调用 active_plugin_version；结果应该选择排序更靠后的 fedcba9876543210。

调用关系：它测试没有默认 local 时的后备选择规则。目录由 write_plugin 伪造，选择动作由 active_plugin_version 完成。

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

fn active_plugin_version_compares_semver_versions_semantically()

作用：这个测试确认语义化版本号会按版本含义比较，而不是按字符串字母顺序比较。语义化版本就是 10.0.0 这种“主版本.次版本.补丁版本”的编号规则。

数据流：它创建 9.0.0 和 10.0.0 两个版本目录；调用 active_plugin_version；结果必须是 10.0.0，避免把字符串开头较大的 9 错当成更新。

调用关系：它测试版本选择里的比较规则。write_plugin 提供两个版本目录，active_plugin_version 需要用更聪明的版本比较选出真正较新的版本。

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

fn install_with_new_version_keeps_existing_plugin_root_and_prunes_old_versions()

作用：这个测试确认安装新版本后，新版本会生效，并且可能继续抢占生效位置的旧版本会被删掉。这样缓存目录不会留下会干扰选择的旧货。

数据流：它先安装 1.0.0，再安装 2.0.0；之后检查当前版本是 2.0.0，2.0.0 目录存在，1.0.0 目录已经不存在。

调用关系：它覆盖一次插件升级的完整故事。write_plugin_with_version 分别制造两个版本，install 连续执行两次，active_plugin_version 和文件存在性检查共同确认清理逻辑生效。

调用图：调用 4 个内部函数（new, write_plugin_with_version, new, try_from）；外部调用 3 个（assert!, assert_eq!, tempdir）。

fn old_plugin_version_would_stay_active_for_local_or_later_versions()

作用：这个测试检查一个辅助判断：旧版本在某些情况下是否会继续被选为当前版本。它用来决定安装新版本时是否需要清理旧目录。

数据流：它给 old_plugin_version_would_stay_active 传入几组旧版本和新版本：local 对 1.0.0、10.0.0 对 9.0.0、1.0.0 对 2.0.0；结果分别应为真、真、假。

调用关系：它直接测试版本清理策略里的小判断函数。安装升级测试会体现这个策略的实际效果，而这里把判断规则单独拎出来确认。

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

fn plugin_root_rejects_path_separators_in_key_segments()

作用：这个测试确认插件名和市场名里不能包含路径分隔或 ../ 这类危险内容。这样可以防止插件名把安装路径“拐”到系统其他目录。

数据流：它尝试解析 ../../etc@debug 和 sample@../../etc；两次都应该失败；最后比对错误信息，确认分别指出插件名或市场名不合法。

调用关系：它测试 PluginId::parse 的安全校验。这个校验发生在生成插件路径之前，是防止路径穿越的第一道门。

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

fn install_rejects_manifest_names_with_path_separators()

作用：这个测试确认即使插件清单 plugin.json 里写了危险名字，安装时也会拒绝。不能只相信市场传来的 PluginId，也要检查插件包自己的名字。

数据流：它创建一个清单名为 ../../etc 的假插件；调用 install；期待失败，并确认错误说插件名只能包含安全字符。

调用关系：它测试 install 读取清单后的安全检查。write_plugin 制造坏清单，install 必须在决定目标路径前拦住它。

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

fn install_rejects_marketplace_names_with_path_separators()

作用：这个测试确认市场名也不能包含 ../ 这类路径内容。因为市场名会成为缓存路径的一部分，放开它会带来路径逃逸风险。

数据流：它直接用 sample-plugin 和 ../../etc 创建 PluginId；创建过程应失败；最后确认错误信息说明市场名不合法。

调用关系：它测试 PluginId::new 的输入校验。这个检查比安装更早，确保危险的插件身份根本不能被构造出来。

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

fn install_rejects_manifest_names_that_do_not_match_marketplace_plugin_name()

作用：这个测试确认 plugin.json 里的插件名必须和市场请求的插件名一致。这样可以防止下载到的包“挂羊头卖狗肉”。

数据流：它创建一个清单名为 manifest-name 的插件，但安装时传入的 PluginId 名字是 different-name；调用 install 后应失败，并返回说明两个名字不匹配的错误。

调用关系：它测试安装时的身份核对。write_plugin 准备名字不一致的插件包，install 读取清单后与 PluginId 对照，发现不一致就停止。

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

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

作用：把临时测试目录里的文件名变成一个“绝对路径”。测试里需要模拟真实用户配置文件的位置，所以先把路径整理成加载器能接受的格式。

数据流：输入是一个临时目录和文件名；它读取临时目录的实际磁盘路径，把文件名拼上去，再转换成 AbsolutePathBuf（表示确定无误的绝对路径）；输出就是这个配置文件的绝对路径，如果路径不是绝对路径会让测试直接失败。

调用关系：它是测试用的小工具，主要配合 user_layer 使用。测试在创建配置层之前，先用它生成像 config.toml、work.config.toml 这样的用户配置文件路径。

调用图：调用 1 个内部函数（from_absolute_path）；外部调用 1 个（path）。

fn user_layer(path: AbsolutePathBuf, config: &str) -> ConfigLayerEntry

作用：把一段 TOML 配置文本包装成一个“用户配置层”。TOML 是一种常见配置文件格式，长得像 ini 文件，用来写键值和表格。

数据流：输入是配置文件路径和一段 TOML 字符串；它先把字符串解析成配置数据，再标记这份数据来自用户文件；输出是 ConfigLayerEntry，也就是配置合并栈里的一层。

调用关系：它被需要构造配置栈的测试使用，尤其是配置合并和插件启用状态相关的测试。它把纯文本配置变成 ConfigLayerStack::new 能吃的材料。

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

fn configured_plugins_from_stack_merges_user_layers()

作用：确认多个用户配置层里的插件设置会合并在一起，而不是后一层把前一层全部盖掉。这样用户的基础配置和工作区配置才能同时生效。

数据流：测试先创建临时目录，再造出两层用户配置：一层启用 base 插件，另一层禁用 profile 插件；然后把它们放进配置栈，调用 configured_plugins_from_stack；最后检查输出的插件表同时包含 base 和 profile，并且启用状态正确。

调用关系：这是配置合并规则的守门测试。它用 user_config_path 和 user_layer 准备输入，再把结果交给断言比较，确保配置加载器的合并行为符合预期。

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

async fn hooks_only_scope_shares_plugin_resolution_without_loading_other_capabilities()

作用：确认“只加载钩子”的模式仍然会用同一套插件查找和校验规则，但不会顺手加载技能、MCP 服务或应用。这样启动时只需要钩子的场景可以更轻、更安全。

数据流：测试在临时目录里造出多个插件：有效插件、被禁用插件、清单坏掉的插件、缺失插件、钩子文件坏掉的插件；再写入用户配置说明哪些插件启用；随后分别执行完整加载和 HooksOnly 加载；最后比较两种加载在启用状态、根目录、错误和钩子警告上的结果一致，同时确认 HooksOnly 对有效插件没有加载 manifest 名称、技能目录、MCP 服务和应用。

调用关系：这是插件加载流程里一个重要分支的测试。它直接驱动 load_plugins_from_layer_stack 和 load_plugins_from_layer_stack_with_scope，验证二者共享插件解析结果，但 HooksOnly 会跳过其他能力的读取。

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

fn curated_plugin_cache_version_shortens_full_git_sha()

作用：确认完整的 Git 提交哈希会被缩短成前 8 位。Git 提交哈希就是代码版本的身份证，完整值很长，缓存目录用短一点更好读。

数据流：输入是一串 40 位的 Git 哈希；测试调用 curated_plugin_cache_version；输出应是前 8 个字符，测试用断言确认它等于 01234567。

调用关系：它单独检查缓存版本命名的小规则。这个规则影响精选插件下载后放在哪个缓存目录里。

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

fn curated_plugin_cache_version_preserves_non_git_sha_versions()

作用：确认不是完整 Git 哈希的版本名不会被乱改。比如 export-backup 这种人工版本名，应该原样保留。

数据流：输入是普通字符串版本名和一个长度不够的短数字串；测试分别调用 curated_plugin_cache_version；输出应与输入完全相同。

调用关系：它和 curated_plugin_cache_version_shortens_full_git_sha 配成一组，说明只有像完整 Git 哈希的字符串才会被缩短，其他版本名不会被误处理。

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

fn plugin_id() -> PluginId

作用：生成测试里统一使用的插件 ID。插件 ID 可以理解成插件的完整名字，里面包含插件名和来源市场。

数据流：它没有外部输入；内部把 demo-plugin@test-marketplace 这段文字解析成 PluginId；输出是后续加载钩子时使用的插件身份。

调用关系：它被 load_sources 调用。这样所有钩子来源都能带上同一个插件身份，assert_sources 也能用它检查结果是否一致。

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

fn plugin_root() -> (tempfile::TempDir, AbsolutePathBuf)

作用：创建一个临时插件目录，并准备好插件通常需要的子目录。这样每个测试都有干净、独立的假插件，不会互相污染。

数据流：它没有业务输入；内部创建临时目录，在里面建立 demo-plugin、.codex-plugin 和 hooks 文件夹；输出是临时目录句柄和插件根目录的绝对路径。临时目录句柄活着时，测试文件才不会被提前删除。

调用关系：多个 hooks 测试都会先调用它准备现场，然后再写清单和钩子文件。它是这些测试的共同地基。

调用图：调用 1 个内部函数（try_from）；被 6 处调用（load_plugin_hooks_discovers_default_hooks_file, load_plugin_hooks_manifest_paths_replace_default_hooks_file, load_plugin_hooks_reports_invalid_hook_file, load_plugin_hooks_supports_inline_manifest_hook_list, load_plugin_hooks_supports_inline_manifest_hooks, load_plugin_hooks_supports_manifest_hook_path）；外部调用 2 个（create_dir_all, tempdir）。

fn write_manifest(plugin_root: &AbsolutePathBuf, manifest: &str)

作用：把一段插件清单 JSON 写到标准位置。插件清单像插件的说明书，告诉加载器插件叫什么、钩子在哪里等。

数据流：输入是插件根目录和清单文本；它把文本写进 .codex-plugin/plugin.json；结果是在临时插件目录里出现一份清单文件。

调用关系：它被多个 hooks 测试调用，用来快速切换不同清单写法。写好后，load_sources 会读取这份清单并继续加载钩子。

调用图：调用 1 个内部函数（join）；被 6 处调用（load_plugin_hooks_discovers_default_hooks_file, load_plugin_hooks_manifest_paths_replace_default_hooks_file, load_plugin_hooks_reports_invalid_hook_file, load_plugin_hooks_supports_inline_manifest_hook_list, load_plugin_hooks_supports_inline_manifest_hooks, load_plugin_hooks_supports_manifest_hook_path）；外部调用 1 个（write）。

fn write_hook_file(plugin_root: &AbsolutePathBuf, relative_path: &str, event: &str, command: &str)

作用：按指定事件和命令生成一个钩子 JSON 文件。钩子就是在某个时机触发的小动作，比如运行一条命令。

数据流：输入是插件根目录、相对路径、事件名和命令；它拼出一段符合钩子格式的 JSON，然后写到指定文件；结果是磁盘上多了一个可被加载器读取的钩子文件。

调用关系：它被测试“清单指定 hooks 路径”和“清单路径替换默认 hooks 文件”时使用，帮助快速生成 one.json、two.json 这类测试文件。

调用图：调用 1 个内部函数（join）；被 2 处调用（load_plugin_hooks_manifest_paths_replace_default_hooks_file, load_plugin_hooks_supports_manifest_hook_path）；外部调用 2 个（format!, write）。

fn load_sources(plugin_root: &AbsolutePathBuf) -> (Vec<PluginHookSource>, Vec<String>)

作用：用真实加载逻辑读取一个测试插件的钩子来源。它把前面写好的清单和钩子文件送进被测函数，拿回加载结果和警告。

数据流：输入是插件根目录；它先读取 plugin.json 清单，再构造插件数据目录路径，并生成测试插件 ID；然后调用 load_plugin_hooks；输出是一组 PluginHookSource（钩子来源）和一组警告文本。

调用关系：它是多个 hooks 测试的中间桥梁：测试先用 plugin_root、write_manifest、write_hook_file 搭好文件，再通过它调用真正的加载函数，最后用 assert_sources 或直接断言检查结果。

调用图：调用 4 个内部函数（plugin_id, load_plugin_manifest, as_path, try_from）；被 6 处调用（load_plugin_hooks_discovers_default_hooks_file, load_plugin_hooks_manifest_paths_replace_default_hooks_file, load_plugin_hooks_reports_invalid_hook_file, load_plugin_hooks_supports_inline_manifest_hook_list, load_plugin_hooks_supports_inline_manifest_hooks, load_plugin_hooks_supports_manifest_hook_path）。

fn assert_sources(sources: &[PluginHookSource], expected_relative_paths: &[&str])

作用：统一检查加载出来的钩子来源是否符合预期。它避免每个测试都手写一大串重复断言。

数据流：输入是实际加载出的钩子来源列表和预期的相对路径列表；它检查每个来源的插件 ID 是否都是测试插件、来源路径是否按预期排列、每个来源是否正好有一个处理器；没有返回值，检查失败会让测试失败。

调用关系：它被大多数成功加载 hooks 的测试调用。load_sources 负责拿结果，它负责判断这些结果是不是对的。

调用图：被 5 处调用（load_plugin_hooks_discovers_default_hooks_file, load_plugin_hooks_manifest_paths_replace_default_hooks_file, load_plugin_hooks_supports_inline_manifest_hook_list, load_plugin_hooks_supports_inline_manifest_hooks, load_plugin_hooks_supports_manifest_hook_path）；外部调用 1 个（assert_eq!）。

fn load_plugin_hooks_discovers_default_hooks_file()

作用：确认如果清单没有特别指定 hooks，加载器会自动寻找默认的 hooks/hooks.json 文件。这是最常见、最省配置的插件写法。

数据流：测试先创建插件根目录，写一个只包含名字的清单，再写默认 hooks/hooks.json；然后调用 load_sources；输出应没有警告，并且只发现 hooks/hooks.json 这一份钩子来源。

调用关系：它使用 plugin_root 和 write_manifest 搭建默认结构，用 load_sources 调用真实加载逻辑，再用 assert_sources 检查默认发现规则。

调用图：调用 4 个内部函数（assert_sources, load_sources, plugin_root, write_manifest）；外部调用 2 个（assert_eq!, write）。

fn load_plugin_hooks_supports_manifest_hook_path()

作用：确认插件清单可以指定一个自定义 hooks 文件路径。这样插件作者不一定非要把钩子放在默认文件里。

数据流：测试写入一个带 hooks: ./hooks/one.json 的清单，再写对应的 one.json；调用 load_sources 后，结果应没有警告，并且来源路径是 hooks/one.json。

调用关系：它用 write_manifest 表达清单里的自定义路径，用 write_hook_file 创建文件，最后通过 load_sources 和 assert_sources 验证加载器听从清单设置。

调用图：调用 5 个内部函数（assert_sources, load_sources, plugin_root, write_hook_file, write_manifest）；外部调用 1 个（assert_eq!）。

fn load_plugin_hooks_manifest_paths_replace_default_hooks_file()

作用：确认只要清单明确列出 hooks 路径，默认的 hooks/hooks.json 就不会再被顺便加载。这样插件作者可以明确控制哪些钩子生效。

数据流：测试写入一个清单，指定 one.json 和 two.json；同时故意写一个默认 hooks/hooks.json；调用 load_sources 后，输出应只包含 one.json 和 two.json，没有默认文件，也没有警告。

调用关系：它把默认文件和清单指定文件同时放进插件目录，专门验证优先级规则：清单显式路径会替代默认发现。

调用图：调用 5 个内部函数（assert_sources, load_sources, plugin_root, write_hook_file, write_manifest）；外部调用 1 个（assert_eq!）。

fn load_plugin_hooks_supports_inline_manifest_hooks()

作用：确认 hooks 可以直接写在插件清单里，而不是单独放文件。这样小插件可以少建一个文件。

数据流：测试写入一个清单，里面直接包含 SessionStart 事件的钩子配置；调用 load_sources 后，应没有警告，并生成一个来源名为 plugin.json#hooks[0] 的钩子来源，表示它来自清单内部。

调用关系：它不写单独 hooks 文件，只靠 write_manifest 准备输入。load_sources 读取清单后，验证加载器能识别内嵌 hooks。

调用图：调用 4 个内部函数（assert_sources, load_sources, plugin_root, write_manifest）；外部调用 1 个（assert_eq!）。

fn load_plugin_hooks_reports_invalid_hook_file()

作用：确认钩子文件格式坏了时，加载器会给出清楚警告，而不是崩溃或假装成功。坏 JSON 指的是文件内容不符合 JSON 语法。

数据流：测试创建默认清单，再写一个内容为 { not-json 的坏 hooks 文件；调用 load_sources 后，输出的钩子来源应为空，警告列表里应包含具体解析错误和文件路径。

调用关系：它测试错误处理路径。和成功加载测试不同，它不调用 assert_sources，而是直接检查 sources 为空、warnings 文本准确。

调用图：调用 3 个内部函数（load_sources, plugin_root, write_manifest）；外部调用 2 个（assert_eq!, write）。

fn load_plugin_hooks_supports_inline_manifest_hook_list()

作用：确认清单里可以一次内嵌多组 hooks。这样一个插件能把不同事件的钩子分成多个块来写。

数据流：测试写入一个清单，其中 hooks 是一个列表，第一项包含 SessionStart，第二项包含 Stop；调用 load_sources 后，应没有警告，并得到 plugin.json#hooks[0] 和 plugin.json#hooks[1] 两个来源。

调用关系：它验证内嵌 hooks 的列表写法。流程仍然是 plugin_root 建目录、write_manifest 写清单、load_sources 加载、assert_sources 检查。

调用图：调用 4 个内部函数（assert_sources, load_sources, plugin_root, write_manifest）；外部调用 1 个（assert_eq!）。

fn materialize_git_subdir_uses_sparse_checkout()

作用：确认从 Git 仓库安装插件时，如果只指定仓库里的某个子目录，加载器会只取那个子目录。稀疏检出可以理解成“只拿货架上的一个盒子，不把整个仓库搬回家”。

数据流：测试先创建一个临时 Git 仓库，里面有目标插件目录、另一个插件目录和根目录文件；提交后调用 materialize_marketplace_plugin_source，要求只取 plugins/toolkit；输出的物化目录应包含目标 marker.txt，但检出根目录里不应有 root.txt，也不应有 plugins/other/marker.txt。

调用关系：它搭建真实 Git 仓库并调用插件来源物化逻辑，专门验证 Git 子目录下载路径。断言部分检查结果目录，确保实现没有偷偷完整检出整个仓库。

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

fn write_alternate_marketplace(repo_root: &Path, contents: &str) -> AbsolutePathBuf

作用：这个小工具函数用来在测试仓库里写一个备用布局的插件市场文件。测试里反复需要造这种文件，所以把重复的建目录、写文件动作收在这里。

数据流：输入一个仓库根目录和一段 JSON 字符串 → 它把路径拼成 .claude-plugin/marketplace.json，先创建父目录，再把内容写进去 → 返回这个市场文件的绝对路径，方便后面的测试拿去读取。

调用关系：它是测试辅助工具，不是正式功能。多个测试先用它搭好备用格式的市场文件，再去验证列市场或找插件的代码是否支持这种布局。

调用图：调用 1 个内部函数（try_from）；被 5 处调用（find_marketplace_plugin_supports_alternate_layout_and_string_local_source, list_marketplaces_includes_plugins_without_discoverable_manifest, list_marketplaces_keeps_remote_and_local_plugin_sources, list_marketplaces_prefers_first_supported_manifest_layout, list_marketplaces_supports_alternate_manifest_layout）；外部调用 3 个（join, create_dir_all, write）。

fn write_alternate_plugin_manifest(plugin_root: &Path, contents: &str)

作用：这个小工具函数用来给某个插件写备用布局的 plugin.json。它让测试可以模拟插件自己带有展示信息，比如显示名。

数据流：输入插件根目录和 JSON 内容 → 它拼出 .claude-plugin/plugin.json，创建目录并写入文件 → 不返回数据，但磁盘上多了一个测试用插件清单。

调用关系：它只被备用清单布局的测试使用。测试先用它放好插件清单，再用市场列表读取流程确认这些界面信息能被读出来。

调用图：被 1 处调用（list_marketplaces_supports_alternate_manifest_layout）；外部调用 3 个（join, create_dir_all, write）。

fn find_marketplace_plugin_finds_repo_marketplace_plugin()

作用：这个测试确认：仓库里的标准位置 marketplace.json 能被读取，并且本地插件路径能被正确解析。没有这个保证，最常见的仓库内插件市场就可能失效。

数据流：测试先创建临时仓库、.git 目录、市场文件和一个本地插件声明 → 调用查找插件的能力 → 期望得到插件 ID、本地绝对路径、默认安装策略等完整结果。

调用关系：测试运行器会执行它。它通过临时文件系统搭场景，最后用断言检查真正的插件查找流程有没有按标准仓库布局工作。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn find_marketplace_plugin_supports_alternate_layout_and_string_local_source()

作用：这个测试确认备用市场布局也能用，而且 source 直接写成字符串路径时也能识别成本地插件。这样旧格式或兼容格式不会突然坏掉。

数据流：测试创建临时仓库，用 write_alternate_marketplace 写入 .claude-plugin/marketplace.json → 查找指定插件 → 期望插件来源被解析成仓库内 plugins/string-source-plugin 的绝对路径。

调用关系：测试运行器调用它；它依赖 write_alternate_marketplace 先准备文件，然后检查插件查找流程对备用布局和简写 source 的兼容性。

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

fn find_marketplace_plugin_supports_git_subdir_sources()

作用：这个测试确认插件可以来自 Git 仓库里的某个子目录。很多插件不是整个仓库，而是仓库中的一个文件夹，这个规则很重要。

数据流：测试写入一个 git-subdir 来源，里面有 GitHub 简写地址、子目录、分支名和提交哈希 → 查找插件 → 期望结果变成完整 Git 地址，并保留子目录、ref 和 sha 信息。

调用关系：测试运行器执行它。它验证市场解析流程能把远程 Git 子目录插件转换成安装器后续能理解的结构。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn find_marketplace_plugin_normalizes_github_shorthand_with_dot_git_suffix()

作用：这个测试确认类似 openai/toolkit.git 这样的 GitHub 简写会被补成完整网址，而且不会重复加 .git。它防止生成错误的仓库地址。

数据流：测试写入一个带 .git 后缀的 GitHub 简写来源 → 查找插件 → 只检查解析出的 source，期望 URL 是 https://github.com/openai/toolkit.git。

调用关系：测试运行器调用它。它专门盯住 Git 地址标准化这一步，确保后续克隆代码时拿到的是正确地址。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn find_marketplace_plugin_normalizes_relative_git_source_urls_to_marketplace_root()

作用：这个测试确认相对 Git 地址会相对于市场所在仓库来解释，而不是相对于当前运行目录乱跳。这样本地测试仓库或本地镜像地址才可靠。

数据流：测试分别用 Unix 风格和 Windows 风格的相对路径写入 Git 来源 → 创建对应的本地远程仓库目录 → 查找插件 → 期望 Git URL 被解析成市场根目录下 remotes/toolkit.git 的路径字符串。

调用关系：测试运行器执行它。它覆盖跨平台路径写法，验证相对 Git 地址归一化这段逻辑不会因为斜杠不同而出错。

调用图：调用 1 个内部函数（try_from）；外部调用 5 个（assert_eq!, format!, create_dir_all, write, tempdir）。

fn normalize_relative_git_plugin_source_url_rejects_parent_traversal()

作用：这个测试确认相对 Git 地址不能用 .. 跑到市场根目录外面。.. 就像文件路径里的“上一层”，如果不拦住，配置文件可能引用不该碰的地方。

数据流：测试把多种向上跳目录的路径交给相对 Git URL 规范化函数 → 函数返回错误 → 测试确认错误信息明确说明相对地址必须留在市场根目录内。

调用关系：测试运行器调用它。它直接检查路径安全规则，是插件市场防止目录逃逸的一道测试。

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

fn find_marketplace_plugin_skips_root_equivalent_git_subdir_paths()

作用：这个测试确认 git-subdir 的 path 如果等价于仓库根目录，就不会被当成有效插件子目录。它避免“子目录插件”规则被空路径或绕法混淆。

数据流：测试用 .、./、plugins/.. 这些最终等于根目录的 path 写市场文件 → 查找插件 → 期望找不到这个插件，而不是返回一个根目录来源。

调用关系：测试运行器执行它。它把几个容易绕过检查的路径写法喂给插件查找流程，确认无效条目会被跳过。

调用图：调用 1 个内部函数（try_from）；外部调用 5 个（assert_eq!, format!, create_dir_all, write, tempdir）。

fn find_marketplace_plugin_reports_missing_plugin()

作用：这个测试确认市场里没有目标插件时，会给出清楚的“找不到”错误。这样用户或上层代码不会误以为是文件坏了。

数据流：测试写入一个没有插件的市场文件 → 查找名为 missing 的插件 → 期望返回错误，错误里带插件名和市场名。

调用关系：测试运行器调用它。它检查插件查找流程的失败提示是否友好、准确。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_supports_alternate_manifest_layout()

作用：这个测试确认列出市场时，也能读取备用布局里的市场文件和插件清单。它保证兼容格式不仅查找能用，列表展示也能用。

数据流：测试创建备用 marketplace.json 和备用 plugin.json，插件清单里有 displayName → 调用列市场流程 → 期望返回一个市场，其中插件带本地路径和读取到的显示名。

调用关系：测试运行器执行它。它先借助 write_alternate_marketplace 和 write_alternate_plugin_manifest 准备场景，再验证完整的市场列表流程。

调用图：调用 3 个内部函数（write_alternate_marketplace, write_alternate_plugin_manifest, try_from）；外部调用 3 个（assert_eq!, create_dir_all, tempdir）。

fn list_marketplaces_includes_plugins_without_discoverable_manifest()

作用：这个测试确认插件就算没有能找到的 plugin.json，也仍然会出现在市场列表里。这样一个缺少展示信息的插件不会被整个隐藏。

数据流：测试写入一个指向不存在插件目录的市场条目 → 调用列市场流程 → 期望插件仍在列表中，只是 interface 这些展示信息为空。

调用关系：测试运行器调用它。它使用 write_alternate_marketplace 准备市场文件，验证列表流程对缺失插件清单采取宽容处理。

调用图：调用 2 个内部函数（write_alternate_marketplace, try_from）；外部调用 3 个（assert_eq!, create_dir_all, tempdir）。

fn list_marketplaces_prefers_first_supported_manifest_layout()

作用：这个测试确认同一个仓库里同时存在多个支持的市场布局时，会优先使用第一个约定布局。这样结果稳定，不会一会儿读这个一会儿读那个。

数据流：测试同时写入标准位置和备用位置的市场文件 → 调用列市场流程 → 期望只返回标准位置的 agents-marketplace。

调用关系：测试运行器执行它。它用 write_alternate_marketplace 放备用文件，同时手写标准文件，检查市场发现顺序是否符合约定。

调用图：调用 2 个内部函数（write_alternate_marketplace, try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_supports_explicit_api_marketplace_manifest_path()

作用：这个测试确认如果调用方直接给的是某个 marketplace.json 文件路径，而不是仓库目录，也能正常读取。API 场景常会这样传。

数据流：测试创建一个明确命名的 api_marketplace.json → 把这个文件路径作为输入传给列市场流程 → 期望返回这个市场和其中的本地插件。

调用关系：测试运行器调用它。它检查市场列表入口不仅能发现仓库里的默认文件，也能尊重调用方指定的具体文件。

调用图：调用 1 个内部函数（try_from）；外部调用 5 个（assert_eq!, create_dir_all, write, from_ref, tempdir）。

fn list_marketplaces_returns_home_and_repo_marketplaces()

作用：这个测试确认用户主目录里的市场和当前仓库里的市场会一起返回。这样全局插件和项目专属插件可以同时出现。

数据流：测试分别在 home 和 repo 下写同名市场，各自包含共享插件和独有插件 → 调用列市场流程并传入 home_dir → 期望结果按 home 市场、repo 市场两个条目返回，路径各自解析到自己的根目录。

调用关系：测试运行器执行它。它验证市场列表流程会合并多个来源，但不会把不同位置的市场混成一个。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_keeps_distinct_entries_for_same_name()

作用：这个测试确认两个市场即使名字一样，只要文件位置不同，也会作为两个独立条目保留。否则 home 和 repo 的同名市场可能互相覆盖。

数据流：测试在 home 和 repo 写入同名市场，同名插件分别指向不同路径 → 列市场时期望得到两个市场 → 再按 repo 的市场文件查找插件，确认拿到 repo 版本的路径。

调用关系：测试运行器调用它。它既检查列表流程保留同名市场，也检查查找流程会根据传入的具体市场文件定位正确插件。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_dedupes_multiple_roots_in_same_repo()

作用：这个测试确认如果输入了同一个 Git 仓库里的多个目录，只会列一次市场。这样从仓库根目录和子目录同时启动时不会重复显示同一个市场。

数据流：测试创建仓库根目录和嵌套目录，并只在仓库根目录放一个市场文件 → 把两个目录都传给列市场流程 → 期望结果只有一个市场。

调用关系：测试运行器执行它。它检查市场发现流程会先识别共同的仓库根，再去重。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_reads_marketplace_display_name()

作用：这个测试确认市场文件里的 interface.displayName 会被读出来。这个字段通常用于界面上显示更友好的市场名称。

数据流：测试写入带 displayName 的 marketplace.json → 调用列市场流程 → 期望返回的 MarketplaceInterface 里包含 ChatGPT Official。

调用关系：测试运行器调用它。它关注市场本身的展示信息，不是插件的展示信息。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_skips_invalid_plugins_but_keeps_marketplace()

作用：这个测试确认市场里某个插件配置无效时，市场本身仍会保留，只是跳过坏插件。这样一个坏条目不会让整个市场消失。

数据流：测试准备一个有效市场和一个含无效本地路径的市场 → 调用列市场流程 → 期望两个市场都返回，但无效市场的 plugins 列表为空。

调用关系：测试运行器执行它。它检查列表流程的容错策略：市场文件能读就保留，单个插件坏了就跳过。

调用图：调用 1 个内部函数（try_from）；外部调用 5 个（assert!, assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_skips_plugins_with_invalid_names_but_keeps_marketplace()

作用：这个测试确认插件名不符合规则时，只跳过这个插件，不丢掉整个市场。比如带点号的名字在这里被视为无效。

数据流：测试写入一个市场，里面有 valid-plugin 和 invalid.plugin → 调用列市场流程 → 期望只剩有效插件，市场名称和路径仍正常。

调用关系：测试运行器调用它。它验证插件名校验失败时的处理边界，避免坏名字影响其他正常插件。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_reports_marketplace_load_errors()

作用：这个测试确认市场文件本身读不懂时，错误会被收集报告，同时其他正常市场还能返回。这样界面可以展示部分结果并提示哪里坏了。

数据流：测试准备一个合法 JSON 市场和一个内容是 {not json 的坏市场 → 调用列市场流程 → 期望返回一个正常市场，并在 errors 里记录坏文件路径和错误消息。

调用关系：测试运行器执行它。它检查市场加载层的错误汇报方式，确保不是遇到第一个坏文件就全盘失败。

调用图：调用 1 个内部函数（try_from）；外部调用 5 个（assert!, assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_keeps_remote_and_local_plugin_sources()

作用：这个测试确认列表结果能同时保留本地插件、普通远程 Git 插件、Git 子目录插件三种来源。插件市场现实中会混用这些来源。

数据流：测试写入一个包含三种 source 的市场文件 → 调用列市场流程 → 期望本地路径变成绝对路径，GitHub 地址补成完整 .git URL，子目录、ref、sha 也被保留。

调用关系：测试运行器调用它。它借助 write_alternate_marketplace 快速造市场，集中检查来源解析规则是否在列表流程里全部生效。

调用图：调用 2 个内部函数（write_alternate_marketplace, try_from）；外部调用 3 个（assert_eq!, create_dir_all, tempdir）。

fn list_marketplaces_resolves_plugin_interface_paths_to_absolute()

作用：这个测试确认插件清单里的图标、logo、截图这些相对资源路径，会被解析成绝对路径。这样后续界面加载图片时不用猜它们相对于哪里。

数据流：测试创建本地插件和 .codex-plugin/plugin.json，里面有显示名、分类、能力和 ./assets 开头的图片路径 → 调用列市场流程 → 期望界面信息被合并，图片路径都变成插件目录下的绝对路径，市场里的分类覆盖清单里的分类。

调用关系：测试运行器执行它。它验证市场列表流程会读取插件清单，并把展示资源路径整理成安全、明确的位置。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_ignores_legacy_top_level_policy_fields()

作用：这个测试确认旧的顶层 installPolicy 和 authPolicy 字段会被忽略，仍使用新的默认策略。这样旧字段不会偷偷改变当前安装规则。

数据流：测试写入含旧字段的插件声明，其中旧字段表示不可安装、使用时认证 → 调用列市场流程 → 期望实际策略仍是默认的 Available 和 OnInstall，products 为空。

调用关系：测试运行器调用它。它盯住配置兼容边界，确保只有当前支持的 policy 结构会影响安装策略。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn list_marketplaces_ignores_plugin_interface_assets_without_dot_slash()

作用：这个测试确认插件界面资源路径必须用 ./ 开头才会被接受。没有 ./ 的相对路径或绝对路径会被忽略，避免随便引用外部文件。

数据流：测试写入插件清单，其中 composerIcon 是 assets/icon.png，logo 是 /tmp/logo.png，截图也是不带 ./ 的路径 → 调用列市场流程 → 期望文字信息保留，但这些资源路径全部为空。

调用关系：测试运行器执行它。它检查插件清单资源路径的安全过滤规则，和默认安装策略是否仍保持正常。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn find_marketplace_plugin_skips_invalid_local_paths()

作用：这个测试确认本地插件路径不能用 ../ 指到市场目录外。这样的路径会被视为无效，插件查找结果等同于找不到。

数据流：测试写入一个本地 source，路径是 ../plugin-1 → 查找 local-plugin → 期望返回“插件未找到”的错误，而不是暴露或使用外部路径。

调用关系：测试运行器调用它。它验证插件查找流程里的本地路径安全限制。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn find_marketplace_plugin_uses_first_duplicate_entry()

作用：这个测试确认市场里有两个同名插件时，会使用第一个条目。这个规则让重复配置的结果可预测。

数据流：测试写入两个都叫 local-plugin 的条目，第一个指向 ./first，第二个指向 ./second → 查找插件 → 期望结果使用 first 的路径。

调用关系：测试运行器执行它。它检查插件查找流程遇到重复名称时不会随机选择，而是按文件顺序取第一个有效项。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn find_installable_marketplace_plugin_rejects_disallowed_product()

作用：这个测试确认插件如果只允许某些产品安装，就不能被其他产品安装。这里 Product 指不同宿主产品，比如 Codex、ChatGPT、Atlas。

数据流：测试写入一个只允许 CHATGPT 的插件 → 以 Atlas 产品身份请求查找可安装插件 → 期望返回“不可安装”的错误。

调用关系：测试运行器调用它。它验证可安装插件查找流程会在普通查找之外，再检查产品白名单。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn find_marketplace_plugin_allows_missing_products_field()

作用：这个测试确认 policy 里没有 products 字段时，不会因此拒绝插件。缺省值表示没有额外产品限制。

数据流：测试写入一个 policy 为空对象的插件 → 普通查找插件 → 期望成功，并得到 default-plugin@codex-curated 这个插件键。

调用关系：测试运行器执行它。它检查普通插件查找流程对缺省产品字段的宽容行为。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn find_installable_marketplace_plugin_rejects_explicit_empty_products()

作用：这个测试确认 products 明确写成空数组时，表示没有任何产品可以安装。它和“字段缺失”不同。

数据流：测试写入一个 products: [] 的插件 → 以 Codex 产品身份请求可安装插件 → 期望返回不可安装错误。

调用关系：测试运行器调用它。它检查可安装查找流程能区分“没写限制”和“明确禁止所有产品”。

调用图：调用 1 个内部函数（try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

fn build_remote_marketplace_preserves_directory_order_and_appends_installed_only_plugins()

作用：这个测试确认远程插件市场的展示顺序是稳定的：远程目录给什么顺序，就先按这个顺序显示；如果某个插件只存在于已安装列表里，也不会丢掉，而是追加到最后。

数据流：进去的是两个模拟列表：一个远程目录列表，里面有 plugin-z 和 plugin-m；一个已安装列表，里面有 plugin-a。测试把这些交给 build_remote_marketplace，拿回生成后的市场结果，再抽出每个插件的远程插件 ID。最后它断言结果顺序必须是 plugin-z、plugin-m、plugin-a，说明目录顺序被保住了，额外已安装插件也被补上了。

调用关系：这是直接验证 build_remote_marketplace 行为的测试。它自己准备测试数据，其中插件对象来自 directory_plugin；最后用 assert_eq! 做比对，确保未来有人改市场合并逻辑时不会无意打乱顺序。

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

fn directory_plugin(id: &str, name: &str) -> RemotePluginDirectoryItem

作用：这是一个测试辅助函数，用来快速造一个“远程目录里的插件”假数据。有人写测试时只需要给插件 ID 和名字，就能得到一个字段齐全、默认可用的插件对象。

数据流：进去的是 id 和 name 两个字符串。函数把它们复制成真正拥有数据的字符串，并填入 RemotePluginDirectoryItem 的各个字段；大部分不重要的字段会设成空值、空列表或默认可用状态。出来的是一个完整的远程目录插件对象，可直接塞进测试里的市场构建流程。

调用关系：它是测试里的造假数据工具，主要服务于远程市场相关测试。build_remote_marketplace_preserves_directory_order_and_appends_installed_only_plugins 用它快速生成目录插件和已安装插件里的 plugin 字段，避免测试正文被大量结构体字段淹没。

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

fn item(name: &str, display_name: &str) -> RecommendedPluginItem

作用：这是一个测试辅助函数，用来快速造一个“推荐插件接口返回的插件条目”。它让测试只关注插件名字和展示名，而不用反复手写完整结构。

数据流：进去的是 name 和 display_name。函数会把 name 变成插件安装用的 id，比如 plugin_github，并填入推荐插件条目的名字、展示名和空的应用连接器列表。出来的是一个 RecommendedPluginItem，供推荐插件规则测试继续加工或混入异常数据。

调用关系：它被 recommended_plugins_are_validated_deduplicated_sorted_and_capped 调用，用来批量生成一堆推荐插件。它把重复的造数工作封装起来，让那个测试能专心检查排序、去重和数量上限。

调用图：被 1 处调用（recommended_plugins_are_validated_deduplicated_sorted_and_capped）；外部调用 2 个（new, format!）。

fn recommended_plugins_enabled_flag_selects_endpoint_or_legacy_mode()

作用：这个测试确认推荐插件功能到底走新接口模式还是旧模式，完全取决于远程响应里的 enabled 标记。只有 enabled 明确为 true，才启用新接口返回的推荐列表。

数据流：进去的是几段模拟 JSON：enabled=false、没有 enabled、enabled=null、enabled=true。测试先把 JSON 反序列化成 RecommendedPluginsResponse，也就是把文本格式的数据变成程序里的结构体；再交给 recommended_plugins_mode 判断模式。出来的检查结果是：前三种都必须是 Legacy 旧模式，只有 enabled=true 才是 Endpoint 新接口模式，并带一个空插件列表。

调用关系：它直接测试 recommended_plugins_mode 的入口选择规则。serde_json::from_value 和 json! 只负责制造模拟远程响应，真正被验证的是推荐插件模式选择这一步。

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

fn recommended_plugins_require_remote_install_identity()

作用：这个测试确认推荐插件必须带有远程安装身份，也就是能唯一指向远程插件的 id。没有这个身份，系统不能接受它，否则后面安装时会不知道到底装哪个插件。

数据流：进去的是一段故意缺少 id 字段的模拟 JSON。测试尝试把它转成 RecommendedPluginsResponse。结果应该是失败，而不是生成一个残缺对象；测试用 assert! 确认确实报错。

调用关系：它验证的是数据入口的安全门槛：远程响应在进入推荐插件处理流程前，必须先能被正确解析。这里不继续调用 recommended_plugins_mode，因为缺少 id 的数据应当在反序列化阶段就被挡住。

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

fn recommended_plugins_are_validated_deduplicated_sorted_and_capped()

作用：这个测试确认推荐插件列表会被清洗成一份安全、整齐、数量有限的列表。它检查系统会丢掉无效插件、去掉重复项、按名字排序，并最多只保留规定数量。

数据流：进去的是一大批故意乱序的推荐插件，还额外混入重复插件、ID 格式非法的插件、被管理员禁用的插件、安装策略不可用的插件。测试把它们放进 RecommendedPluginsResponse，并交给 recommended_plugins_mode。出来必须是 Endpoint 模式，里面的插件数量等于 MAX_RECOMMENDED_PLUGINS；第一个应是 Plugin 00，最后一个应是 Plugin 49，说明列表经过了过滤、去重、排序和截断。

调用关系：这是推荐插件清洗规则的综合测试。它调用 item 批量生成正常插件，再手动加入异常插件，最后通过 recommended_plugins_mode 观察系统最终会给用户哪些推荐项。若返回的不是新接口模式，测试会直接 panic!，因为 enabled=true 时应当进入 Endpoint。

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

fn recommended_plugins_bound_model_visible_fields()

作用：这个测试确认会出现在模型或用户可见结果里的文字字段有长度限制。名字太长的插件会被丢弃，展示名太长则会被截短，避免远程数据把界面或后续处理撑坏。

数据流：进去的是两个特殊推荐插件：一个 name 超过允许长度，一个 display_name 超过允许长度。测试把它们交给 recommended_plugins_mode。出来的结果只保留 name 合法的 bounded 插件，并把它的展示名截到 MAX_RECOMMENDED_PLUGIN_DISPLAY_NAME_LEN 规定的长度。

调用关系：它专门验证 recommended_plugins_mode 里的字段边界保护。这个测试不关心排序和去重，只关心远程给来的可见文本在进入最终推荐列表前是否被限制在安全范围内。

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

fn recommended_plugins_preserve_install_identity_and_normalize_app_ids()

作用：这个测试确认推荐插件会保留真正用于安装的远程插件 ID，同时会整理它关联的应用连接器 ID。连接器 ID 里的空值和重复值会被清掉，留下干净列表。

数据流：进去的是一个推荐插件，带有 id、name、展示名，以及 app_ids 列表；这个列表里包含 connector_one、空字符串、connector_two 和重复的 connector_one。测试交给 recommended_plugins_mode 后，出来的推荐插件应保留 remote_plugin_id 为 plugin_connector_sample，config_id 来自 name，并且 app_connector_ids 只剩 connector_one 和 connector_two。

调用关系：它验证 recommended_plugins_mode 在生成最终 RecommendedPlugin 时如何处理身份字段和连接器列表。远程插件 ID 用于安装，config_id 用于本地配置标识，app_ids 则在转换时被去空、去重。

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

fn recommended_plugins_ignore_invalid_remote_plugin_ids()

作用：这个测试确认远程插件 ID 格式不合法时，该推荐项会被忽略。这样可以防止坏数据或异常数据进入安装流程。

数据流：进去的是一个 enabled=true 的推荐响应，但里面插件的 id 是 not/a/plugin，带有斜杠，属于不接受的远程插件 ID。测试交给 recommended_plugins_mode 后，出来仍是 Endpoint 模式，但 plugins 是空列表，说明这个坏插件被过滤掉了。

调用关系：它是推荐插件输入校验的一条边界测试。它直接观察 recommended_plugins_mode 的最终结果，确保无效远程 ID 不会变成 RecommendedPlugin，也不会影响整个接口模式本身。

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

fn write_file(path: &Path, contents: &str)

作用：这是测试里的小工具，用来把一段文字写进指定文件。它会先把父目录建好，避免测试因为目录不存在而失败。

数据流：输入一个文件路径和文本内容 → 它找到这个文件的上级目录并创建出来 → 再把文本写入文件；结果是磁盘上出现这个测试需要的文件。

调用关系：它是造测试数据的底层工具。write_curated_plugin、write_curated_plugin_sha 和 write_openai_curated_marketplace 都把具体内容准备好后，交给它真正落到磁盘。

调用图：被 3 处调用（write_curated_plugin, write_curated_plugin_sha, write_openai_curated_marketplace）；外部调用 3 个（parent, create_dir_all, write）。

fn write_curated_plugin(root: &Path, plugin_name: &str)

作用：这个函数造一个假的精选插件目录。它写出插件自己的 plugin.json，让测试里的仓库看起来像真的有一个插件。

数据流：输入测试仓库根目录和插件名 → 拼出 plugins/<插件名>/.codex-plugin/plugin.json 这个位置 → 写入只包含插件名的 JSON；结果是一个最小可识别的插件 manifest 文件。

调用关系：它服务于 write_openai_curated_marketplace。后者先写总市场清单，再调用它为清单里的每个插件补上对应的插件文件。

调用图：调用 1 个内部函数（write_file）；被 1 处调用（write_openai_curated_marketplace）；外部调用 2 个（join, format!）。

fn write_openai_curated_marketplace(root: &Path, plugin_names: &[&str])

作用：这个函数造一个假的 OpenAI 官方精选插件市场。测试用它快速搭出“有 gmail、linear 等插件”的本地仓库。

数据流：输入仓库根目录和一组插件名 → 生成 marketplace.json，里面列出每个插件和它的本地路径 → 再逐个创建对应插件 manifest；结果是一个结构完整的假精选插件仓库。

调用关系：多个测试用它准备已有快照或更新后的仓库。它内部把写文件交给 write_file，把每个插件目录交给 write_curated_plugin。

调用图：调用 2 个内部函数（write_curated_plugin, write_file）；被 3 处调用（sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists, sync_openai_plugins_repo_via_git_preserves_existing_snapshot_on_validation_failure, sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote）；外部调用 2 个（join, format!）。

fn write_curated_plugin_sha(codex_home: &Path)

作用：这个函数写入一个固定的测试用插件版本号。这里的 SHA 可以理解成“仓库版本身份证”。

数据流：输入 codex home 路径 → 在 .tmp/plugins.sha 写入固定 SHA 和换行 → 后续读取时应该能知道当前本地快照对应哪个版本。

调用关系：一些测试先用它伪造“本地已经同步过某个版本”。它把实际写入动作交给 write_file。

调用图：调用 1 个内部函数（write_file）；被 2 处调用（sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists, sync_openai_plugins_repo_via_git_preserves_existing_snapshot_on_validation_failure）；外部调用 2 个（join, format!）。

fn has_plugins_clone_dirs(codex_home: &Path) -> bool

作用：这个函数检查临时目录里是否还残留 plugins-clone- 开头的同步临时文件夹。它用来确认失败或成功后有没有把施工现场打扫干净。

数据流：输入 codex home 路径 → 读取 .tmp 目录 → 查找名字以 plugins-clone- 开头且确实是目录的项目；输出 true 或 false。

调用关系：它是测试断言用的检查器。同步代码会创建临时克隆目录，这个函数帮助测试确认这些目录没有在异常路径里泄漏。

调用图：外部调用 2 个（join, read_dir）。

fn write_executable_script(path: &Path, contents: &str)

作用：这个 Unix 专用工具会写出一个可执行脚本。测试用它伪造 git 命令，让同步流程以为自己在调用真实 git。

数据流：输入脚本路径和脚本文本 → 把内容写到文件 → 再把文件权限改成可执行；结果是测试可以直接运行这个脚本。

调用关系：需要模拟 git 成功、失败、卡顿或记录调用次数的测试都会用它。它让测试不用依赖真实网络上的 GitHub 行为。

调用图：被 5 处调用（concurrent_syncs_serialize_fetches_without_skipping_remote_checks, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails, sync_openai_plugins_repo_via_git_cleans_up_staged_dir_on_fetch_failure, sync_openai_plugins_repo_via_git_preserves_existing_snapshot_on_validation_failure, sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote）；外部调用 3 个（metadata, set_permissions, write）。

fn run_git(repo: &Path, args: &[&str]) -> std::process::Output

作用：这个 Unix 专用工具在指定仓库里运行真实 git 命令，并要求命令必须成功。它让测试可以搭一个真正的本地 Git 仓库。

数据流：输入仓库路径和 git 参数 → 执行 git -C <仓库> ... → 如果失败就让测试立刻报错；如果成功就返回命令输出。

调用关系：主要服务于 sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote。那个测试用它初始化仓库、提交、读取 SHA 和推送更新。

调用图：被 1 处调用（sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote）；外部调用 2 个（assert!, new）。

async fn mount_github_repo_and_ref(server: &MockServer, sha: &str)

作用：这个异步函数在假 HTTP 服务器上挂两个 GitHub 接口：一个说默认分支是 main，一个返回 main 分支的 SHA。

数据流：输入假服务器和目标 SHA → 注册 GET /repos/openai/plugins 和 GET /repos/openai/plugins/git/ref/heads/main 的假响应 → 后续同步代码访问这些地址时会拿到预设版本信息。

调用关系：HTTP 同步相关测试先调用它搭好“GitHub 元信息”。它和 mount_github_zipball 常常配套，一个给版本号，一个给压缩包内容。

调用图：被 4 处调用（sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails, sync_openai_plugins_repo_skips_archive_download_when_sha_matches, sync_openai_plugins_repo_via_http_cleans_up_staged_dir_on_extract_failure）；外部调用 5 个（given, new, format!, method, path）。

async fn mount_github_zipball(server: &MockServer, sha: &str, bytes: Vec<u8>)

作用：这个异步函数让假服务器提供某个 SHA 对应的 zip 压缩包。同步代码会把它当作 GitHub 仓库下载包。

数据流：输入假服务器、SHA 和 zip 字节 → 注册 GET /repos/openai/plugins/zipball/<sha> → 返回 content-type 为 application/zip 的字节内容。

调用关系：当测试需要走 HTTP 下载路径时，它跟 mount_github_repo_and_ref 一起布置假 GitHub。压缩包内容通常来自 curated_repo_zipball_bytes。

调用图：被 3 处调用（sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails, sync_openai_plugins_repo_via_http_cleans_up_staged_dir_on_extract_failure）；外部调用 5 个（given, new, format!, method, path）。

async fn mount_export_archive(server: &MockServer, bytes: Vec<u8>) -> String

作用：这个异步函数搭出备份归档下载流程。它模拟一个后端接口先返回下载地址，再由另一个地址返回 zip 文件。

数据流：输入假服务器和归档 zip 字节 → 注册 /backend-api/plugins/export/curated 返回 download_url → 再注册 /files/curated-plugins.zip 返回真正 zip；输出第一个接口的 URL。

调用关系：测试 GitHub 路径失败时的最后兜底方案会调用它。归档内容一般由 curated_repo_backup_archive_zip_bytes 生成。

调用图：被 2 处调用（sync_openai_plugins_repo_falls_back_to_export_archive_when_no_snapshot_exists, sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists）；外部调用 5 个（given, new, format!, method, path）。

async fn run_sync_with_transport_overrides(
    codex_home: PathBuf,
    git_binary: impl Into<String>,
    api_base_url: impl Into<String>,
    backup_archive_api_url: impl Into<String>,
) -> Result<

作用：这个异步辅助函数用指定的 git 命令路径、GitHub 地址和备份地址来跑一次完整同步。它让测试可以把真实外部依赖全部换成假的。

数据流：输入 codex home、git 可执行文件名、API 基础地址和备份归档地址 → 在线程池里运行同步函数，避免阻塞异步测试 → 返回同步得到的 SHA，或返回错误文字。

调用关系：多个异步测试通过它驱动完整同步流程。它把真正的同步工作交给 sync_openai_plugins_repo_with_transport_overrides。

调用图：被 5 处调用（sync_openai_plugins_repo_falls_back_to_export_archive_when_no_snapshot_exists, sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails, sync_openai_plugins_repo_skips_archive_download_when_sha_matches, sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists）；外部调用 2 个（into, spawn_blocking）。

async fn run_http_sync(
    codex_home: PathBuf,
    api_base_url: impl Into<String>,
) -> Result<String, String>

作用：这个异步辅助函数只跑 HTTP 方式的插件同步。它用于专门测试不用 git、只下载 zip 的那条路。

数据流：输入 codex home 和 API 基础地址 → 在线程池里调用 HTTP 同步函数 → 返回成功的 SHA 或失败原因。

调用关系：sync_openai_plugins_repo_via_http_cleans_up_staged_dir_on_extract_failure 用它触发坏 zip 的错误场景，确认临时目录会被清理。

调用图：被 1 处调用（sync_openai_plugins_repo_via_http_cleans_up_staged_dir_on_extract_failure）；外部调用 2 个（into, spawn_blocking）。

fn assert_curated_gmail_repo(repo_path: &Path)

作用：这个断言函数检查一个同步后的仓库里有没有市场清单和 gmail 插件 manifest。它是“同步结果看起来像个有效仓库”的快速验收。

数据流：输入仓库路径 → 检查 .agents/plugins/marketplace.json 是否存在 → 再检查 plugins/gmail/.codex-plugin/plugin.json 是否存在；任一缺失就让测试失败。

调用关系：很多成功路径测试最后都会调用它。它不负责同步，只负责像验收员一样确认关键文件到位。

调用图：被 6 处调用（concurrent_syncs_serialize_fetches_without_skipping_remote_checks, sync_openai_plugins_repo_falls_back_to_export_archive_when_no_snapshot_exists, sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails, sync_openai_plugins_repo_via_git_preserves_existing_snapshot_on_validation_failure, sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote）；外部调用 1 个（assert!）。

fn curated_plugins_repo_path_uses_codex_home_tmp_dir()

作用：这个测试确认精选插件仓库会放在 codex home 的 .tmp/plugins 下面。路径放对很重要，否则可能污染用户别的目录。

数据流：创建临时 codex home → 调用路径计算函数 → 比较结果是否等于 <临时目录>/.tmp/plugins；测试只产生临时目录，不保留状态。

调用关系：它直接验证 curated_plugins_repo_path 的约定。这个约定会被后面几乎所有同步测试默认依赖。

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

fn read_curated_plugins_sha_reads_trimmed_sha_file()

作用：这个测试确认读取插件 SHA 时会去掉末尾换行。版本文件通常有换行，读取出来不该把换行当成版本号的一部分。

数据流：创建 .tmp/plugins.sha，写入 abc123 加换行 → 调用读取函数 → 期望得到 Some("abc123")。

调用关系：它验证 read_curated_plugins_sha 的基础行为。后续跳过下载、判断版本是否相同都依赖这个读取结果准确。

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

fn remove_stale_curated_repo_temp_dirs_removes_only_matching_directories()

作用：这个 Unix 测试确认清理旧临时目录时只删该删的。它不能误删新目录，也不能误删无关缓存。

数据流：创建一个旧的 plugins-clone 目录、一个新的 plugins-clone 目录和一个无关目录 → 手动设置修改时间 → 调用清理函数 → 断言只有过期的匹配目录被删除。

调用关系：它验证 remove_stale_curated_repo_temp_dirs。测试里还定义了一个小的 set_dir_mtime 帮手，用系统调用改目录时间。

调用图：外部调用 4 个（from_secs, assert!, create_dir_all, tempdir）。

fn concurrent_syncs_serialize_fetches_without_skipping_remote_checks()

作用：这个 Unix 测试检查两次同步同时启动时不会互相打架。它还确认每次都会检查远端版本，但真正下载只做必要的一次。

数据流：创建假 git 脚本并记录所有调用 → 用屏障让两个线程同时开始同步 → 假 git 返回同一个 SHA 并在 reset 时造出 gmail 插件 → 最后检查两个同步都成功、仓库有效、SHA 已保存、ls-remote 调了两次而 fetch 只调了一次。

调用关系：它用 write_executable_script 伪造 git，用 assert_curated_gmail_repo 验收结果。这个测试重点覆盖同步函数里的串行化保护，也就是类似“排队进门”的锁。

调用图：调用 2 个内部函数（assert_curated_gmail_repo, write_executable_script）；外部调用 8 个（new, assert!, assert_eq!, format!, read_to_string, scope, new, tempdir）。

fn sync_openai_plugins_repo_via_git_succeeds_with_local_rewritten_remote()

作用：这个 Unix 测试走一遍真实 git 同步成功路径，并检查增量更新和无变化时的行为。它把 GitHub 地址重写成本地裸仓库，所以不用访问网络。

数据流：先创建一个真实本地仓库，提交 gmail 插件 → 配置 git 把 https://github.com/ 重写到本地路径 → 运行同步并检查 SHA、文件和临时目录 → 再提交 linear 插件并推送 → 再同步，确认新插件出现且使用 fetch 更新 → 第三次同步时远端没变，确认不会再 fetch。

调用关系：它用 run_git 搭建真实仓库，用 write_executable_script 包装 git 并记录调用，用 write_openai_curated_marketplace 制造更新内容，用 assert_curated_gmail_repo 验收同步结果。

调用图：调用 4 个内部函数（assert_curated_gmail_repo, run_git, write_executable_script, write_openai_curated_marketplace）；外部调用 10 个（from_utf8_lossy, assert!, assert_eq!, new, format!, create_dir_all, read_to_string, write, new, tempdir）。

async fn sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable()

作用：这个异步测试确认如果 git 命令根本不存在，同步会自动改走 HTTP 下载 zip 的备用路线。

数据流：启动假服务器 → 挂上 GitHub 版本接口和 zipball 接口 → 用一个不存在的 git 名字运行同步 → 期望同步成功，返回指定 SHA，并在本地生成 gmail 插件仓库。

调用关系：它用 mount_github_repo_and_ref 和 mount_github_zipball 布置假 GitHub，用 curated_repo_zipball_bytes 生成 zip，用 run_sync_with_transport_overrides 驱动完整流程。

调用图：调用 5 个内部函数（assert_curated_gmail_repo, curated_repo_zipball_bytes, mount_github_repo_and_ref, mount_github_zipball, run_sync_with_transport_overrides）；外部调用 3 个（start, assert_eq!, tempdir）。

async fn sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails()

作用：这个 Unix 异步测试确认 git 虽然存在但执行失败时，也会回退到 HTTP 下载。这样用户本机 git 配置坏了也不至于完全不能同步。

数据流：写一个永远退出失败的假 git → 启动假服务器并提供版本信息和 zip 包 → 运行同步 → 期望它忽略 git 失败，改用 HTTP 成功拿到仓库和 SHA。

调用关系：它用 write_executable_script 制造失败 git，用 mount_github_repo_and_ref、mount_github_zipball 和 curated_repo_zipball_bytes 准备 HTTP 备用内容，再通过 run_sync_with_transport_overrides 触发同步。

调用图：调用 6 个内部函数（assert_curated_gmail_repo, curated_repo_zipball_bytes, mount_github_repo_and_ref, mount_github_zipball, run_sync_with_transport_overrides, write_executable_script）；外部调用 4 个（start, assert_eq!, new, tempdir）。

fn sync_openai_plugins_repo_via_git_cleans_up_staged_dir_on_fetch_failure()

作用：这个 Unix 测试确认 git fetch 中途失败时，临时克隆目录会被删除。否则用户目录里会越积越多半成品。

数据流：写一个假 git：ls-remote 成功、init 成功、fetch 报 early EOF → 调用 git 同步 → 期望返回包含错误信息的失败结果 → 再检查没有残留 plugins-clone 临时目录。

调用关系：它用 write_executable_script 控制 git 的失败点。测试目标是 sync_openai_plugins_repo_via_git 的失败清理行为。

调用图：调用 1 个内部函数（write_executable_script）；外部调用 4 个（assert!, format!, new, tempdir）。

fn sync_openai_plugins_repo_via_git_preserves_existing_snapshot_on_validation_failure()

作用：这个 Unix 测试确认新下载内容如果校验不过，旧的可用插件快照不会被覆盖。就像更新软件失败时，不能把原来能用的版本删掉。

数据流：先写入一个已有的 gmail 仓库和旧 SHA → 假 git 声称远端有新 SHA，但 reset 出来的新内容缺少市场清单 → 调用同步后期望失败 → 检查旧 gmail 仍在、linear 没被换进去、旧 SHA 仍保留、临时目录已清理。

调用关系：它用 write_openai_curated_marketplace 和 write_curated_plugin_sha 准备旧快照，用 write_executable_script 伪造坏更新，用 assert_curated_gmail_repo 确认旧内容还活着。

调用图：调用 4 个内部函数（assert_curated_gmail_repo, write_curated_plugin_sha, write_executable_script, write_openai_curated_marketplace）；外部调用 6 个（assert!, assert_eq!, format!, create_dir_all, new, tempdir）。

async fn sync_openai_plugins_repo_via_http_cleans_up_staged_dir_on_extract_failure()

作用：这个异步测试确认 HTTP 下载到的内容不是合法 zip 时，同步会失败并清理临时目录。

数据流：假服务器返回正常 SHA，但 zipball 内容是普通文字 not a zip archive → 运行 HTTP 同步 → 期望错误提示说打不开 zip → 再确认没有残留临时克隆目录。

调用关系：它用 mount_github_repo_and_ref 设置版本，用 mount_github_zipball 提供坏包，用 run_http_sync 专门触发 HTTP 同步路径。

调用图：调用 3 个内部函数（mount_github_repo_and_ref, mount_github_zipball, run_http_sync）；外部调用 3 个（start, assert!, tempdir）。

async fn sync_openai_plugins_repo_skips_archive_download_when_sha_matches()

作用：这个异步测试确认本地已有 SHA 和远端 SHA 一样时，不需要再下载压缩包。这样能省网络，也减少出错机会。

数据流：先在本地创建一个已有仓库和 plugins.sha → 假服务器只提供远端 SHA，不提供 zipball → 运行同步 → 如果同步成功，就说明它只检查了版本，没有尝试下载缺失的 zip。

调用关系：它用 mount_github_repo_and_ref 提供远端版本，用 run_sync_with_transport_overrides 运行带替换地址的完整同步。

调用图：调用 2 个内部函数（mount_github_repo_and_ref, run_sync_with_transport_overrides）；外部调用 7 个（start, assert!, assert_eq!, format!, create_dir_all, write, tempdir）。

async fn sync_openai_plugins_repo_falls_back_to_export_archive_when_no_snapshot_exists()

作用：这个异步测试确认当 GitHub 查询失败且本地没有旧快照时，会使用后端导出的备份归档。它是最后一道兜底。

数据流：假 GitHub repo 查询返回 500 → 假后端导出接口返回一个备份 zip 下载地址 → 运行同步 → 期望从备份归档恢复出 gmail 仓库，并保存归档里的 SHA。

调用关系：它用 curated_repo_backup_archive_zip_bytes 生成带 .git 信息的备份包，用 mount_export_archive 挂到假服务器，再用 run_sync_with_transport_overrides 触发完整回退流程。

调用图：调用 4 个内部函数（assert_curated_gmail_repo, curated_repo_backup_archive_zip_bytes, mount_export_archive, run_sync_with_transport_overrides）；外部调用 7 个（given, start, new, assert_eq!, tempdir, method, path）。

async fn sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists()

作用：这个异步测试确认如果本地已经有可用快照，GitHub 失败时不会贸然用备份归档覆盖它。备份归档只在“完全没东西可用”时才用。

数据流：先写一个已有 linear 插件仓库和旧 SHA → 假 GitHub 返回失败，同时假后端提供另一个备份 zip → 运行同步 → 期望返回“跳过备份归档”的错误，并确认原来的插件文件和 SHA 没变。

调用关系：它用 write_openai_curated_marketplace 和 write_curated_plugin_sha 准备已有快照，用 mount_export_archive 提供本不该使用的备份包，用 run_sync_with_transport_overrides 检查策略是否保守。

调用图：调用 5 个内部函数（curated_repo_backup_archive_zip_bytes, mount_export_archive, run_sync_with_transport_overrides, write_curated_plugin_sha, write_openai_curated_marketplace）；外部调用 9 个（given, start, new, assert!, assert_eq!, read_to_string, tempdir, method, path）。

fn read_extracted_backup_archive_git_sha_reads_head_ref_from_extracted_repo()

作用：这个测试确认从解压后的备份仓库里能读出当前 Git SHA。备份包里不是直接给一个版本号，而是通过 .git/HEAD 指向分支引用。

数据流：创建 .git/HEAD，内容指向 refs/heads/main → 再创建 refs/heads/main 文件并写入 SHA → 调用读取函数 → 期望得到这个 SHA。

调用关系：它验证 read_extracted_backup_archive_git_sha 的正常路径。备份归档回退成功后需要靠这个函数知道应该保存哪个版本号。

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

fn read_extracted_backup_archive_git_sha_rejects_non_refs_head_target()

作用：这个测试确认备份归档里的 HEAD 不能指向 refs/ 之外的位置。这样可以避免读到不该读的文件。

数据流：创建 .git/HEAD，写入 ref: HEAD → 调用读取函数 → 期望返回错误，错误里说明目标必须留在 refs/ 下。

调用关系：它验证 read_extracted_backup_archive_git_sha 的安全检查。这个检查防止恶意或损坏归档绕过正常 Git 引用目录。

调用图：外部调用 4 个（assert!, create_dir_all, write, tempdir）。

fn read_extracted_backup_archive_git_sha_rejects_path_traversal_ref()

作用：这个测试确认 HEAD 引用里不能带 ../ 这种路径穿越写法。路径穿越就是用特殊路径跳出原本允许的目录。

数据流：创建 .git/HEAD，写入 refs/heads/../../evil → 调用读取函数 → 期望返回错误，说明路径组件不合法。

调用关系：它同样验证 read_extracted_backup_archive_git_sha 的安全边界，确保备份归档不能诱导程序访问仓库目录外的文件。

调用图：外部调用 4 个（assert!, create_dir_all, write, tempdir）。

fn curated_repo_zipball_bytes(sha: &str) -> Vec<u8>

作用：这个函数在内存里生成一个 GitHub zipball 风格的测试压缩包。里面有市场清单和 gmail 插件 manifest。

数据流：输入 SHA → 创建一个内存 zip 写入器 → 以 openai-plugins-<sha> 为根目录写入 marketplace.json 和 plugin.json → 输出整个 zip 文件的字节数组。

调用关系：HTTP 回退成功相关测试用它提供假 GitHub zip 内容。mount_github_zipball 再把这些字节挂到假服务器上。

调用图：调用 1 个内部函数（new）；被 2 处调用（sync_openai_plugins_repo_falls_back_to_http_when_git_is_unavailable, sync_openai_plugins_repo_falls_back_to_http_when_git_sync_fails）；外部调用 4 个（default, new, new, format!）。

fn curated_repo_backup_archive_zip_bytes(sha: &str) -> Vec<u8>

作用：这个函数在内存里生成一个备份归档格式的测试 zip。它比普通 zipball 多了 .git/HEAD 和分支引用，用来模拟可恢复 SHA 的备份包。

数据流：输入 SHA → 创建内存 zip → 写入 plugins/.git/HEAD、plugins/.git/refs/heads/main、市场清单和 gmail 插件 manifest → 输出 zip 字节数组。

调用关系：备份归档回退相关测试用它制造后端导出的压缩包。mount_export_archive 会把这些字节作为下载文件提供给同步流程。

调用图：调用 1 个内部函数（new）；被 2 处调用（sync_openai_plugins_repo_falls_back_to_export_archive_when_no_snapshot_exists, sync_openai_plugins_repo_skips_export_archive_when_snapshot_exists）；外部调用 4 个（default, new, new, format!）。

fn test_config(server: &MockServer) -> RemotePluginServiceConfig

作用：给测试造一个远程插件服务配置，让被测代码把请求发到假的服务器，而不是发到真正的线上服务。

数据流：输入是一个假的 MockServer；函数读取它的地址，把地址后面拼上 /backend-api；输出一个 RemotePluginServiceConfig，后续网络请求都会按这个地址走。

调用关系：多个测试在开始时都会先调用它，比如创建、更新、列出、删除分享插件的测试。它只做地址准备，真正的请求由被测的分享函数发出去。

调用图：被 5 处调用（delete_remote_plugin_share_deletes_workspace_plugin, list_remote_plugin_shares_fetches_created_workspace_plugins, save_remote_plugin_share_creates_workspace_plugin, save_remote_plugin_share_updates_existing_workspace_plugin, update_remote_plugin_share_targets_updates_targets）；外部调用 1 个（format!）。

fn test_auth() -> CodexAuth

作用：给测试准备一份假的登录信息，用来模拟已经登录的用户。

数据流：没有外部输入；它调用测试专用的认证创建函数；输出一个 CodexAuth，里面有固定的访问令牌和账号 ID，方便测试检查请求头是否正确。

调用关系：创建、更新、列出、删除等网络相关测试都会用它。它提供身份材料，被测函数随后把这些材料放进 HTTP 请求头里。

调用图：调用 1 个内部函数（create_dummy_chatgpt_auth_for_testing）；被 5 处调用（delete_remote_plugin_share_deletes_workspace_plugin, list_remote_plugin_shares_fetches_created_workspace_plugins, save_remote_plugin_share_creates_workspace_plugin, save_remote_plugin_share_updates_existing_workspace_plugin, update_remote_plugin_share_targets_updates_targets）。

fn write_file(path: &Path, contents: &str)

作用：把一段文字写进指定文件，并自动创建上级文件夹，省得每个测试重复写这些准备代码。

数据流：输入是文件路径和文件内容；它先找到父目录并创建目录，再把内容写入文件；结果是在磁盘临时目录里出现这个文件。

调用关系：它是测试造文件的小工具，被 write_test_plugin、write_plugin_share_local_path_mapping 以及几个压缩包测试调用。它不参与业务逻辑，只负责搭测试现场。

调用图：被 4 处调用（archive_plugin_for_upload_rejects_archives_over_limit, archive_plugin_for_upload_round_trips_through_plugin_bundle_archive_with_long_paths, write_plugin_share_local_path_mapping, write_test_plugin）；外部调用 3 个（parent, create_dir_all, write）。

fn write_test_plugin(root: &Path, plugin_name: &str) -> PathBuf

作用：快速造出一个最小可用的测试插件目录，里面有插件清单和一个示例技能文件。

数据流：输入是根目录和插件名；它在根目录下创建插件文件夹，再写入 .codex-plugin/plugin.json 和 skills/example/SKILL.md；输出这个插件目录的路径。

调用关系：上传分享和压缩包相关测试都会先用它准备本地插件。它把写文件的细活交给 write_file。

调用图：调用 1 个内部函数（write_file）；被 5 处调用（archive_plugin_for_upload_places_manifest_at_archive_root, archive_plugin_for_upload_rejects_archives_over_limit, archive_plugin_for_upload_round_trips_through_plugin_bundle_archive_with_long_paths, save_remote_plugin_share_creates_workspace_plugin, save_remote_plugin_share_updates_existing_workspace_plugin）；外部调用 2 个（join, format!）。

fn write_plugin_share_local_path_mapping(
    codex_home: &Path,
    remote_plugin_id: &str,
    plugin_path: &AbsolutePathBuf,
)

作用：在测试用的 Codex 主目录里写一份“远程插件 ID 对应本地插件路径”的记录。

数据流：输入是 Codex 主目录、远程插件 ID 和本地插件绝对路径；它把这些信息整理成 JSON 文件，写到 .tmp/plugin-share-local-paths-v1.json；结果是后续代码能像读真实本地缓存一样读到这条映射。

调用关系：列出分享和删除分享的测试会用它预先放入本地记录。它底层仍然通过 write_file 落盘。

调用图：调用 1 个内部函数（write_file）；被 2 处调用（delete_remote_plugin_share_deletes_workspace_plugin, list_remote_plugin_shares_fetches_created_workspace_plugins）；外部调用 2 个（join, format!）。

fn archive_file_entries(archive_bytes: &[u8]) -> BTreeMap<String, Vec<u8>>

作用：把 tar.gz 压缩包里的普通文件读出来，方便测试检查上传的压缩包里到底放了哪些文件和内容。

数据流：输入是一段压缩包字节；它先用 gzip 解压，再按 tar 归档格式逐个读条目，只保留普通文件；输出一个按文件路径排序的映射，键是压缩包内路径，值是文件内容字节。

调用关系：创建分享测试用它检查实际上传的包，压缩包结构测试也用它检查清单文件和技能文件的位置。它是测试里的“开箱验货”工具。

调用图：被 2 处调用（archive_plugin_for_upload_places_manifest_at_archive_root, save_remote_plugin_share_creates_workspace_plugin）；外部调用 2 个（new, new）。

fn remote_plugin_json(plugin_id: &str) -> serde_json::Value

作用：生成一份假的远程插件 JSON，用来模拟后端返回的插件资料。

数据流：输入是插件 ID；它填入固定的插件名、版本、描述、安装策略、认证策略和界面信息；输出一份 serde_json::Value，也就是测试里可直接当响应体用的 JSON 值。

调用关系：installed_remote_plugin_json 和 remote_plugin_json_with_share_url_and_principals 会在它的基础上加字段。它是构造各种远程插件响应的底座。

调用图：被 2 处调用（installed_remote_plugin_json, remote_plugin_json_with_share_url_and_principals）；外部调用 1 个（json!）。

fn remote_plugin_json_with_share_url_and_principals(
    plugin_id: &str,
    share_url: Option<&str>,
    share_principals: serde_json::Value,
) -> serde_json::Value

作用：在基础远程插件 JSON 上补上分享链接和分享对象，用来模拟“我创建并分享出去的插件”。

数据流：输入是插件 ID、可选分享链接、分享对象列表 JSON；它先拿 remote_plugin_json 生成基础对象，再加入 discoverability、share_url、share_principals 字段；输出扩展后的 JSON。

调用关系：它依赖 remote_plugin_json 提供基础结构，主要服务于列出远程分享插件的测试，让假服务器返回更接近真实后端的数据。

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

fn installed_remote_plugin_json(plugin_id: &str) -> serde_json::Value

作用：生成一份“已经安装”的远程插件 JSON，用来模拟后端说某个工作区插件已安装且已启用。

数据流：输入是插件 ID；它先生成基础远程插件 JSON，再加入 enabled 为 true 和 disabled_skill_names 为空数组；输出带安装状态的 JSON。

调用关系：它建立在 remote_plugin_json 之上，给列出分享的测试提供“这个插件已经安装”的对照数据。

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

fn empty_pagination_json() -> serde_json::Value

作用：生成一个表示“没有下一页”的分页 JSON。

数据流：没有输入；它创建 next_page_token: null 的 JSON；输出给假的后端响应使用，表示列表已经到头。

调用关系：它常用于列表类测试的最后一页响应。被测列表函数看到这个值后，就应该停止继续请求下一页。

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

fn expected_plugin_interface() -> PluginInterface

作用：给测试准备一份预期的插件展示信息，方便和被测代码解析出来的结果做完整比较。

数据流：没有输入；它填入插件显示名、短描述、能力列表等字段，其他没有提供的信息保持为空；输出一个 PluginInterface 结构。

调用关系：列出分享插件的测试用它和实际结果比对，确认远程 JSON 里的界面信息被正确转换成程序内部结构。

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

async fn save_remote_plugin_share_creates_workspace_plugin()

作用：测试第一次分享本地插件时，系统是否会正确打包、申请上传地址、上传压缩包、创建远程工作区插件，并保存本地路径映射。

数据流：它先造临时 Codex 主目录和测试插件，再算出压缩包大小；随后假服务器依次准备三个响应：申请上传地址、接收 PUT 上传、创建工作区插件；调用 save_remote_plugin_share 后，检查返回的远程插件 ID 和分享链接，还检查本地映射文件与上传压缩包内容。

调用关系：这是创建分享流程的主测试。它调用 test_config、test_auth、write_test_plugin 和 archive_file_entries，真正的业务动作交给 save_remote_plugin_share，被 wiremock 假服务器验证请求是否按预期发生。

调用图：调用 5 个内部函数（archive_file_entries, test_auth, test_config, write_test_plugin, try_from）；外部调用 11 个（given, start, new, new, assert_eq!, json!, vec!, body_json, header, method (+1 more)）。

fn archive_plugin_for_upload_rejects_archives_over_limit()

作用：测试插件压缩包超过大小限制时会被拒绝，避免上传过大的插件包。

数据流：它先造一个测试插件，再额外写入一个较大的文件；调用带大小限制的 archive_plugin_for_upload_with_limit，并把限制设得很小；结果应该返回 ArchiveTooLarge 错误，而不是生成压缩包。

调用关系：它使用 write_test_plugin 和 write_file 搭建超大插件现场。这个测试保护打包函数的安全边界，防止后续上传流程处理不该处理的大文件。

调用图：调用 2 个内部函数（write_file, write_test_plugin）；外部调用 2 个（new, assert!）。

fn archive_plugin_for_upload_places_manifest_at_archive_root()

作用：测试打包后的插件清单文件是否放在压缩包根目录的正确位置。

数据流：它创建一个最小测试插件，调用 archive_plugin_for_upload 得到压缩包，再用 archive_file_entries 打开检查；最后确认包里只有插件清单和示例技能文件，而且路径和内容都正确。

调用关系：它调用 write_test_plugin 准备目录，再调用 archive_file_entries 验货。这个测试保证上传包的目录结构符合远端解读插件的要求。

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

fn archive_plugin_for_upload_round_trips_through_plugin_bundle_archive_with_long_paths()

作用：测试带很长文件路径的插件，打包后还能被插件包解包工具正确解出来。

数据流：它先造测试插件，再写入一个路径很深的技能文件；调用 archive_plugin_for_upload 打包，然后用 unpack_plugin_bundle_tar_gz 解包到另一个临时目录；最后读取文件，确认清单和长路径技能文件内容都没变。

调用关系：它把打包函数和解包函数连起来做往返测试。write_test_plugin 和 write_file 负责造数据，unpack_plugin_bundle_tar_gz 负责模拟接收端解包。

调用图：调用 3 个内部函数（unpack_plugin_bundle_tar_gz, write_file, write_test_plugin）；外部调用 3 个（new, new, assert_eq!）。

async fn save_remote_plugin_share_updates_existing_workspace_plugin()

作用：测试重新分享已有远程插件时，系统是否走“更新已有插件”而不是“新建插件”。

数据流：它创建测试插件并计算压缩包大小；假服务器期待申请上传地址时带上已有 plugin_id，随后接收上传，并在指定插件地址上接收更新请求；调用 save_remote_plugin_share 后，检查返回的远程插件 ID 不变，且没有新的分享链接。

调用关系：这是更新分享流程的主测试。它复用 test_config、test_auth、write_test_plugin 准备环境，把核心动作交给 save_remote_plugin_share，并由假服务器确认请求路径和请求体正确。

调用图：调用 4 个内部函数（test_auth, test_config, write_test_plugin, try_from）；外部调用 10 个（given, start, new, new, assert_eq!, default, json!, body_json, method, path）。

async fn update_remote_plugin_share_targets_updates_targets()

作用：测试修改插件分享对象时，系统是否把用户、群组和工作区这些访问名单正确发给后端，并正确读回结果。

数据流：它启动假服务器，要求收到一个 PUT 请求，里面有可见性和目标列表；然后返回后端确认后的 principals 列表；调用 update_remote_plugin_share_targets 后，检查结果里用户、群组、角色和可见性都和响应一致。

调用关系：它调用 test_config 和 test_auth 准备网络地址与身份。真正的更新动作由 update_remote_plugin_share_targets 发出，wiremock 负责检查请求和提供响应。

调用图：调用 2 个内部函数（test_auth, test_config）；外部调用 10 个（given, start, new, assert_eq!, json!, vec!, body_json, header, method, path）。

async fn list_remote_plugin_shares_fetches_created_workspace_plugins()

作用：测试列出自己创建的工作区分享插件时，系统能翻页拉取、合并安装状态，并带上本地路径记录。

数据流：它先在本地写入一个远程 ID 到本地路径的映射；假服务器准备两页“我创建的插件”响应，再准备一份“已安装插件”响应；调用 list_remote_plugin_shares 后，检查结果里两个插件的分享信息、安装启用状态、界面信息和本地路径是否正确。

调用关系：这是列表流程的综合测试。它用 write_plugin_share_local_path_mapping 预置本地缓存，用 test_config 和 test_auth 指向假后端，核心工作交给 list_remote_plugin_shares。

调用图：调用 4 个内部函数（test_auth, test_config, write_plugin_share_local_path_mapping, try_from）；外部调用 11 个（given, start, new, new, assert_eq!, json!, header, method, path, query_param (+1 more)）。

async fn delete_remote_plugin_share_deletes_workspace_plugin()

作用：测试删除远程分享插件后，本地保存的路径映射也会被清理掉。

数据流：它先写入一条本地路径映射；假服务器期待收到 DELETE 请求并返回成功；调用 delete_remote_plugin_share 后，再读取本地映射文件，确认里面已经没有这条记录。

调用关系：这是删除流程测试。它用 write_plugin_share_local_path_mapping 搭好删除前状态，用 test_config 和 test_auth 准备网络调用，真正删除动作交给 delete_remote_plugin_share。

调用图：调用 4 个内部函数（test_auth, test_config, write_plugin_share_local_path_mapping, try_from）；外部调用 8 个（given, start, new, new, assert_eq!, header, method, path）。

fn plugins_manager_tracks_auth_mode()

作用：检查插件管理器能正确记住当前登录方式，并且只有登录方式真的变化时才说“变了”。登录方式会影响插件展示哪些能力，所以这里很关键。

数据流：先创建空的插件管理器 → 反复设置 API Key、ChatGPT 等认证模式并读取回来 → 验证返回值和保存状态是否符合预期；最后创建一个带初始认证模式的管理器，确认初始值也能保存。

调用关系：这是认证相关测试的入口之一，直接使用 PluginsManager 的构造和设置接口，不依赖本文件的辅助造插件函数。

调用图：调用 2 个内部函数（new, new_with_options）；外部调用 3 个（new, assert!, assert_eq!）。

fn write_auth_projection_plugin(codex_home: &Path, name: &str, include_app: bool)

作用：在临时目录里写一个最小插件，用来测试“不同登录方式下插件能力怎么显示”。它可以同时写 MCP 配置，也可以顺手写 App 配置。

数据流：输入 Codex 家目录、插件名和是否包含 App → 创建插件目录、写 plugin.json 和 .mcp.json → 如果要求包含 App，就调用 write_auth_projection_app 再写 .app.json。

调用关系：多个认证投影测试都会先调用它造测试插件；它把写 App 的小活交给 write_auth_projection_app。

调用图：调用 1 个内部函数（write_auth_projection_app）；被 5 处调用（plugin_auth_projection_hides_apps_without_chatgpt_auth, plugin_auth_projection_hides_dual_surface_mcp_with_agent_identity_apps_route, plugin_auth_projection_hides_matching_mcp_with_chatgpt_apps_route, plugin_auth_projection_keeps_non_conflicting_mcp_with_chatgpt_apps_route, plugin_auth_projection_reprojects_cached_plugins_when_auth_changes）；外部调用 3 个（join, write_file, format!）。

fn write_auth_projection_app(codex_home: &Path, plugin_name: &str, app_name: &str)

作用：给某个测试插件写一份 .app.json，声明一个 App 连接器。App 连接器可以理解成 ChatGPT 后端里的某个外部应用入口。

数据流：输入 Codex 家目录、插件名和 App 名 → 找到插件缓存目录 → 写入包含 connector_id 的 .app.json 文件。

调用关系：它被 write_auth_projection_plugin 和少数测试直接调用，用来制造 MCP 名和 App 名是否冲突的场景。

调用图：被 2 处调用（plugin_auth_projection_keeps_non_conflicting_mcp_with_chatgpt_apps_route, write_auth_projection_plugin）；外部调用 3 个（join, write_file, format!）。

fn app_declaration(name: &str, connector_id: &str) -> AppDeclaration

作用：快速造一个 AppDeclaration 测试对象，避免每个测试都手写重复字段。

数据流：输入 App 名和连接器 ID → 填成 AppDeclaration 结构 → 返回给断言使用。

调用关系：加载插件、列市场、读取插件详情等测试会用它组装期望值。

async fn auth_projection_config(codex_home: &Path) -> PluginsConfigInput

作用：写一份启用 sample 和 docs 两个插件的测试配置，并把它读成插件管理器能用的配置对象。

数据流：输入 Codex 家目录 → 写 config.toml，打开 plugins 功能并启用两个插件 → 调用 load_config 读取配置 → 返回 PluginsConfigInput。

调用关系：认证投影相关测试都会用它准备统一配置；它把实际读配置的事交给 load_config。

调用图：调用 1 个内部函数（load_config）；被 5 处调用（plugin_auth_projection_hides_apps_without_chatgpt_auth, plugin_auth_projection_hides_dual_surface_mcp_with_agent_identity_apps_route, plugin_auth_projection_hides_matching_mcp_with_chatgpt_apps_route, plugin_auth_projection_keeps_non_conflicting_mcp_with_chatgpt_apps_route, plugin_auth_projection_reprojects_cached_plugins_when_auth_changes）；外部调用 2 个（join, write_file）。

fn sorted_effective_mcp_server_names(outcome: &PluginLoadOutcome) -> Vec<String>

作用：把加载结果里的有效 MCP 服务器名字取出来并排序，方便测试稳定比较。

数据流：输入 PluginLoadOutcome → 读取 effective_mcp_servers 的键 → 转成列表并排序 → 返回名字列表。

调用关系：认证投影测试用它避免 HashMap 顺序不稳定导致测试偶尔失败。

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

async fn plugin_auth_projection_hides_apps_without_chatgpt_auth()

作用：验证不是 ChatGPT 类登录时，插件里的 App 能力会被隐藏，但 MCP 服务器仍然可用。

数据流：先造两个插件和配置 → 用 ApiKey 认证创建管理器 → 加载插件 → 检查 App 列表为空、MCP 服务器包含 sample 和 docs、能力摘要也不暴露 App。

调用关系：使用 write_auth_projection_plugin、auth_projection_config 和 sorted_effective_mcp_server_names，覆盖认证过滤规则的一种分支。

调用图：调用 3 个内部函数（new_with_options, auth_projection_config, write_auth_projection_plugin）；外部调用 3 个（new, assert!, assert_eq!）。

async fn plugin_auth_projection_hides_matching_mcp_with_chatgpt_apps_route()

作用：验证 ChatGPT 登录时，如果同一个名字同时有 App 和 MCP，系统会走 App 路线并隐藏对应 MCP。

数据流：造 sample 插件同时带 App 和 MCP，docs 只有 MCP → 用 ChatGPT 认证加载 → 输出中 sample 只显示 App，docs 仍显示 MCP。

调用关系：接在通用造插件辅助函数之后，专门测试 App 与 MCP 同名冲突时的取舍。

调用图：调用 3 个内部函数（new_with_options, auth_projection_config, write_auth_projection_plugin）；外部调用 3 个（new, assert!, assert_eq!）。

async fn plugin_auth_projection_hides_dual_surface_mcp_with_agent_identity_apps_route()

作用：验证 AgentIdentity 登录方式和 ChatGPT 登录类似，也会优先显示 App 并隐藏冲突的 MCP。

数据流：准备 sample 和 docs 插件 → 用 AgentIdentity 认证加载 → 得到 sample 的 App，MCP 只剩 docs。

调用关系：复用认证投影测试夹具，确认另一个认证模式走同样的投影规则。

调用图：调用 3 个内部函数（new_with_options, auth_projection_config, write_auth_projection_plugin）；外部调用 2 个（new, assert_eq!）。

async fn plugin_auth_projection_keeps_non_conflicting_mcp_with_chatgpt_apps_route()

作用：验证 ChatGPT 登录时，只有和 App 同名冲突的 MCP 会被隐藏；不冲突的 MCP 仍保留。

数据流：给 sample 写 MCP，再单独写一个不同名 App → 加载后检查 sample 的 MCP 和 App 都存在，docs 的 MCP 也存在。

调用关系：直接调用 write_auth_projection_app 制造“名字不冲突”的场景，补足上一条冲突测试。

调用图：调用 4 个内部函数（new_with_options, auth_projection_config, write_auth_projection_app, write_auth_projection_plugin）；外部调用 2 个（new, assert_eq!）。

async fn plugin_auth_projection_preserves_duplicate_connector_declaration_names()

作用：验证同一个插件里多个 App 声明指向同一个连接器时，最终只显示一次连接器，同时隐藏对应的冲突 MCP。

数据流：写一个插件，里面有 foo、foo2、other 三个 MCP，foo 和 foo2 的 App 都指向同一 connector → ChatGPT 加载 → 结果只保留一个 connector_shared，MCP 只剩 other。

调用关系：这是认证投影规则的边界测试，不走辅助造插件函数，而是手写更复杂的配置文件。

调用图：调用 2 个内部函数（new_with_options, load_config）；外部调用 3 个（new, assert_eq!, write_file）。

async fn plugin_auth_projection_reprojects_cached_plugins_when_auth_changes()

作用：验证同一批已缓存的插件，在登录方式改变后会重新按新认证方式筛选能力。

数据流：先用 ChatGPT 加载，得到 App 路线结果 → 把管理器认证改成 ApiKey → 再加载同一配置 → 结果变成不显示 App、恢复 MCP。

调用关系：它检查缓存不会把旧认证模式下的结果错误复用，是认证投影和加载缓存之间的联动测试。

调用图：调用 3 个内部函数（new_with_options, auth_projection_config, write_auth_projection_plugin）；外部调用 3 个（new, assert!, assert_eq!）。

fn write_plugin_with_version(
    root: &Path,
    dir_name: &str,
    manifest_name: &str,
    manifest_version: Option<&str>,
)

作用：在指定目录写一个带可选版本号的测试插件。版本号用于测试安装和缓存刷新时该放到哪个版本目录。

数据流：输入根目录、目录名、清单里的名字和可选版本 → 创建 .codex-plugin 与 skills 目录 → 写 plugin.json、技能文件和空 .mcp.json。

调用关系：许多安装、刷新缓存测试都靠它快速准备插件；write_plugin 是它的简化包装。

调用图：被 8 处调用（install_plugin_uses_manifest_version_for_non_curated_plugins, refresh_non_curated_plugin_cache_ignores_invalid_unconfigured_plugin_versions, refresh_non_curated_plugin_cache_refreshes_configured_git_source, refresh_non_curated_plugin_cache_reinstalls_missing_configured_plugin_with_manifest_version, refresh_non_curated_plugin_cache_replaces_existing_local_version_with_manifest_version, refresh_non_curated_plugin_cache_returns_false_when_configured_plugins_are_current, write_cached_plugin, write_plugin）；外部调用 4 个（join, format!, create_dir_all, write）。

fn write_plugin(root: &Path, dir_name: &str, manifest_name: &str)

作用：写一个没有 manifest 版本号的普通测试插件。适合测试本地插件默认使用 local 版本的场景。

数据流：输入根目录、插件目录名和插件名 → 调用 write_plugin_with_version，并把版本参数留空 → 得到一个最小可加载插件。

调用关系：被安装、卸载、市场列表、缓存刷新和 hook 测试大量复用。

调用图：调用 1 个内部函数（write_plugin_with_version）；被 13 处调用（install_plugin_supports_git_subdir_marketplace_sources, install_plugin_supports_relative_git_subdir_marketplace_sources, install_plugin_updates_config_with_relative_path_and_plugin_key, list_marketplaces_includes_enabled_state, plugin_cache_ignores_unrelated_session_overrides, plugin_hooks_for_layer_stack_loads_configured_plugin_hooks, refresh_curated_plugin_cache_migrates_full_sha_cache_version_to_short_version, refresh_curated_plugin_cache_removes_cache_for_plugin_removed_from_marketplace, refresh_curated_plugin_cache_replaces_existing_local_version_with_short_sha_version, refresh_curated_plugin_cache_returns_false_when_configured_plugins_are_current (+3 more)）。

fn init_git_repo(repo: &Path)

作用：把一个测试目录初始化成 Git 仓库，并提交当前文件。这样测试 Git 来源插件时有真实仓库可用。

数据流：输入仓库路径 → 依次运行 git init、设置用户名邮箱、add、commit → 仓库变成可克隆的测试源。

调用关系：它把具体命令执行交给 run_git，被 Git 子目录插件安装和刷新测试调用。

调用图：调用 1 个内部函数（run_git）；被 3 处调用（install_plugin_supports_git_subdir_marketplace_sources, install_plugin_supports_relative_git_subdir_marketplace_sources, refresh_non_curated_plugin_cache_refreshes_configured_git_source）。

fn run_git(repo: &Path, args: &[&str])

作用：在指定目录运行一条 git 命令，如果失败就把 stdout 和 stderr 打出来，方便定位测试问题。

数据流：输入仓库路径和 git 参数 → 启动 git -C 命令 → 成功则无返回，失败则让测试失败并显示错误信息。

调用关系：只被 init_git_repo 调用，是本测试文件里操作 Git 的底层小工具。

调用图：被 1 处调用（init_git_repo）；外部调用 2 个（assert!, new）。

fn plugin_config_toml(enabled: bool, plugins_feature_enabled: bool) -> String

作用：生成一份最常见的插件测试配置文本，可以控制插件是否启用、插件总开关是否启用。

数据流：输入插件 enabled 值和 features.plugins 值 → 拼出 TOML 表结构 → 序列化成字符串返回。

调用关系：大量加载测试用它减少重复配置文本，后续通常交给 load_plugins_from_config。

调用图：被 12 处调用（capability_summary_sanitizes_plugin_descriptions_to_one_line, capability_summary_truncates_overlong_plugin_descriptions, effective_apps_preserves_app_config_order, load_plugins_ignores_invalid_manifest_skills_shape, load_plugins_ignores_manifest_component_paths_without_dot_slash, load_plugins_ignores_project_config_files, load_plugins_loads_default_skills_and_mcp_servers, load_plugins_preserves_disabled_plugins_without_effective_contributions, load_plugins_returns_empty_when_feature_disabled, load_plugins_uses_manifest_configured_component_paths (+2 more)）；外部调用 4 个（Boolean, Table, new, to_string）。

async fn load_plugins_from_config(
    config_toml: &str,
    codex_home: &Path,
    auth_mode: Option<AuthMode>,
) -> PluginLoadOutcome

作用：把一段配置文本写入临时 Codex 家目录，然后真正调用插件管理器加载插件。

数据流：输入 config.toml 内容、Codex 家目录和认证模式 → 写配置文件 → 调 load_config 读配置 → 创建 PluginsManager → 返回 PluginLoadOutcome。

调用关系：这是多数加载类测试的统一入口，把造配置、读配置、加载插件串起来。

调用图：调用 2 个内部函数（new_with_options, load_config）；被 13 处调用（capability_summary_sanitizes_plugin_descriptions_to_one_line, capability_summary_truncates_overlong_plugin_descriptions, effective_apps_dedupes_connector_ids_across_plugins, effective_apps_preserves_app_config_order, load_plugins_applies_plugin_mcp_server_policy, load_plugins_ignores_invalid_manifest_skills_shape, load_plugins_ignores_manifest_component_paths_without_dot_slash, load_plugins_ignores_unknown_disabled_skill_names, load_plugins_loads_default_skills_and_mcp_servers, load_plugins_preserves_disabled_plugins_without_effective_contributions (+3 more)）；外部调用 3 个（join, to_path_buf, write_file）。

async fn load_config(codex_home: &Path, cwd: &Path) -> PluginsConfigInput

作用：读取测试用的插件配置，包装项目里的真实配置加载逻辑。

数据流：输入 Codex 家目录和当前工作目录 → 调用测试支持里的 load_plugins_config → 返回 PluginsConfigInput。

调用关系：几乎所有需要配置对象的测试都会调用它，是测试和真实配置加载之间的薄适配层。

调用图：被 32 处调用（auth_projection_config, featured_plugin_ids_for_config_defaults_query_param_to_codex, featured_plugin_ids_for_config_uses_restriction_product_query_param, list_marketplaces_can_skip_openai_curated_before_loading, list_marketplaces_excludes_plugins_with_explicit_empty_products, list_marketplaces_ignores_installed_roots_missing_from_config, list_marketplaces_includes_curated_repo_marketplace, list_marketplaces_includes_enabled_state, list_marketplaces_includes_installed_marketplace_roots, list_marketplaces_installed_git_source_reads_metadata_from_cache_without_cloning (+15 more)）；外部调用 1 个（load_plugins_config）。

fn remote_installed_linear_plugin() -> RemoteInstalledPlugin

作用：快速造一个名叫 linear 的远程已安装插件对象。

数据流：无输入 → 调用 remote_installed_plugin 传入 linear → 返回 RemoteInstalledPlugin。

调用关系：远程缓存元数据测试用它作为默认样本。

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

fn remote_installed_plugin(name: &str) -> RemoteInstalledPlugin

作用：快速造一个指定名字、属于全局远程市场的已安装插件对象。

数据流：输入插件名 → 调用 remote_installed_plugin_in_marketplace 并使用全局市场名 → 返回远程插件记录。

调用关系：它是远程插件测试的便利包装，底层字段由 remote_installed_plugin_in_marketplace 填。

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

fn remote_installed_plugin_in_marketplace(
    name: &str,
    marketplace_name: &str,
) -> RemoteInstalledPlugin

作用：造一个远程已安装插件对象，并允许指定它属于哪个远程市场。

数据流：输入插件名和市场名 → 填入远程 ID、启用状态、安装策略、认证策略等默认字段 → 返回 RemoteInstalledPlugin。

调用关系：被远程市场过滤和冲突处理测试使用，用来模拟后端缓存数据。

调用图：被 1 处调用（remote_installed_plugin）；外部调用 2 个（new, format!）。

fn write_cached_plugin(codex_home: &Path, marketplace_name: &str, plugin_name: &str)

作用：在插件缓存目录里写一个指定市场和名字的已缓存插件。

数据流：输入 Codex 家目录、市场名和插件名 → 组合 plugins/cache 路径 → 调 write_plugin_with_version 写 local 版本插件。

调用关系：远程/本地 curated 冲突测试和缓存刷新测试用它准备已有缓存。

调用图：调用 1 个内部函数（write_plugin_with_version）；被 3 处调用（refresh_curated_plugin_cache_leaves_api_curated_plugin_when_api_manifest_missing, remote_installed_cache_prefers_local_curated_conflicts_when_remote_plugin_disabled, remote_installed_cache_prefers_remote_curated_conflicts_when_remote_plugin_enabled）；外部调用 1 个（join）。

async fn load_plugins_loads_default_skills_and_mcp_servers()

作用：验证启用插件后，默认位置的技能、MCP 服务器和 App 声明都会被加载出来。

数据流：写 plugin.json、skills、.mcp.json、.app.json → 用配置加载 → 检查 LoadedPlugin、能力摘要、有效技能根、MCP 和 App 都符合预期。

调用关系：这是插件加载最基础的完整路径测试，通过 load_plugins_from_config 驱动真实加载逻辑。

调用图：调用 2 个内部函数（load_plugins_from_config, plugin_config_toml）；外部调用 3 个（new, assert_eq!, write_file）。

async fn load_plugins_applies_plugin_mcp_server_policy()

作用：验证用户配置可以覆盖插件自带的 MCP 服务器策略，比如禁用服务器、修改工具审批方式和工具白黑名单。

数据流：插件先声明一个 MCP 服务器及默认工具策略 → 配置里覆盖这些字段 → 加载后读取服务器配置，确认最终值来自用户配置。

调用关系：使用 load_plugins_from_config，专门检查插件声明和用户配置合并规则。

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

async fn remote_installed_cache_ignores_plugins_missing_local_cache()

作用：验证远程已安装缓存里有插件，但本地没有实际缓存文件时，加载结果不会凭空出现插件。

数据流：写配置打开远程插件 → 写远程已安装缓存 linear → 不写本地插件文件 → 加载后结果为空。

调用关系：测试 PluginsManager 读取远程缓存时仍要求本地缓存存在。

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

async fn remote_installed_cache_prefers_local_curated_conflicts_when_remote_plugin_disabled()

作用：验证关闭 remote_plugin 功能时，本地 curated 插件和远程 curated 插件重名，优先保留本地 curated。

数据流：配置启用本地 curated 插件并关闭远程插件 → 写本地和远程缓存中重名 linear → 加载后 linear 来自 openai-curated，remote-only 仍可从远程缓存出现。

调用关系：使用 write_cached_plugin 和远程缓存写入，覆盖远程功能关闭时的冲突策略。

调用图：调用 3 个内部函数（new, load_config, write_cached_plugin）；外部调用 4 个（new, assert_eq!, write_file, vec!）。

async fn remote_installed_cache_prefers_remote_curated_conflicts_when_remote_plugin_enabled()

作用：验证打开 remote_plugin 功能时，远程 curated 插件会替代同名本地 curated 插件。

数据流：配置打开远程插件并启用多个 curated 插件 → 写本地、API curated 和远程缓存 → 加载后同名 linear 选远程版本，calendar 仍保留本地版本。

调用关系：和上一条成对出现，测试远程功能开关对冲突处理的影响。

调用图：调用 3 个内部函数（new, load_config, write_cached_plugin）；外部调用 4 个（new, assert_eq!, write_file, vec!）。

async fn build_remote_installed_plugin_marketplaces_from_cache_uses_remote_metadata()

作用：验证把远程已安装缓存转换成市场列表时，会保留后端给的安装策略、认证策略、关键词和展示信息。

数据流：造一个带丰富元数据的远程 linear 插件并写入缓存 → 从缓存构建市场 → 检查市场名、插件 ID、远程 ID、展示名、描述等字段。

调用关系：直接测试 PluginsManager 的远程市场构建方法，不走完整插件加载流程。

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

async fn build_remote_installed_plugin_marketplaces_from_cache_filters_by_marketplace_name()

作用：验证从远程缓存生成市场时，只返回请求的市场，不把别的远程市场混进来。

数据流：缓存里写 workspace 和 shared-with-me 两个远程插件 → 只请求 workspace 市场 → 输出只包含 workspace 插件。

调用关系：补充上一条元数据测试，重点检查市场名过滤。

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

async fn load_plugins_resolves_disabled_skill_names_against_loaded_plugin_skills()

作用：验证配置里禁用某个技能名时，系统能把名字解析到实际 SKILL.md 路径，并让插件不再贡献技能。

数据流：写一个带 sample-search 技能的插件 → 配置禁用 sample:sample-search → 加载后 disabled_skill_paths 包含真实路径，has_enabled_skills 变成 false，摘要为空。

调用关系：使用 load_plugins_from_config 检查技能配置和插件加载结果之间的映射。

调用图：调用 1 个内部函数（load_plugins_from_config）；外部调用 5 个（new, assert!, assert_eq!, write_file, canonicalize）。

async fn load_plugins_ignores_unknown_disabled_skill_names()

作用：验证配置里禁用不存在的技能名时，不会误伤插件已有技能。

数据流：写 sample-search 技能 → 配置禁用 missing-skill → 加载后禁用路径为空，插件仍有有效技能，能力摘要仍显示有技能。

调用关系：和上一条配对，覆盖“禁用目标不存在”的安全行为。

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

async fn plugin_telemetry_metadata_uses_default_mcp_config_path()

作用：验证生成插件遥测元数据时，会读取默认的 .mcp.json 路径来总结 MCP 能力。

数据流：写 plugin.json 和默认 .mcp.json → 调 plugin_telemetry_metadata_from_root → 检查能力摘要里包含 sample MCP。

调用关系：直接测试遥测元数据读取函数，确保它和普通加载使用相同默认路径。

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

async fn capability_summary_sanitizes_plugin_descriptions_to_one_line()

作用：验证能力摘要里的插件描述会被整理成一行，去掉换行、制表和多余空格。

数据流：写带换行和多空格的 description → 加载插件 → 原始 manifest_description 保持不变，但摘要 description 变成干净的一行。

调用关系：用 load_plugins_from_config 检查面向界面展示的摘要清洗规则。

调用图：调用 2 个内部函数（load_plugins_from_config, plugin_config_toml）；外部调用 3 个（new, assert_eq!, write_file）。

async fn capability_summary_truncates_overlong_plugin_descriptions()

作用：验证过长的插件描述在能力摘要里会被截断，避免把巨大文本塞进摘要。

数据流：写超过最大长度的 description → 加载插件 → 原始描述保留完整，摘要描述只保留允许的最大长度。

调用关系：和描述清洗测试一起保护能力摘要的展示质量和大小限制。

调用图：调用 2 个内部函数（load_plugins_from_config, plugin_config_toml）；外部调用 4 个（new, assert_eq!, write_file, format!）。

async fn load_plugins_uses_manifest_configured_component_paths()

作用：验证 plugin.json 里用 ./ 开头指定自定义 skills、MCP、Apps 路径时，加载器会使用这些自定义文件。

数据流：同时写默认组件和自定义组件 → manifest 指向自定义路径 → 加载后技能根包含自定义和默认技能目录，MCP 和 App 来自自定义配置。

调用关系：测试插件清单对组件路径的影响，走 load_plugins_from_config。

调用图：调用 2 个内部函数（load_plugins_from_config, plugin_config_toml）；外部调用 3 个（new, assert_eq!, write_file）。

async fn load_plugins_ignores_manifest_component_paths_without_dot_slash()

作用：验证 manifest 里没有以 ./ 开头的组件路径会被忽略，系统回退到默认位置。

数据流：写默认和自定义组件，但 manifest 路径不带 ./ → 加载后只使用默认 skills、.mcp.json 和 .app.json。

调用关系：和上一条成对，确认路径安全规则只接受显式相对路径。

调用图：调用 2 个内部函数（load_plugins_from_config, plugin_config_toml）；外部调用 3 个（new, assert_eq!, write_file）。

async fn load_plugins_ignores_invalid_manifest_skills_shape()

作用：验证 manifest 里的 skills 字段形状不对时，不会报错炸掉，而是使用默认技能目录。

数据流：写 skills 为数组而不是字符串 → 加载插件 → error 仍为空，skill_roots 回到默认 skills 目录。

调用关系：测试加载器对格式错误 manifest 的容错能力。

调用图：调用 2 个内部函数（load_plugins_from_config, plugin_config_toml）；外部调用 3 个（new, assert_eq!, write_file）。

async fn load_plugins_preserves_disabled_plugins_without_effective_contributions()

作用：验证配置中禁用的插件仍会出现在加载结果里，但不会贡献技能、MCP 或 App。

数据流：写一个带 MCP 的插件 → 配置 enabled=false → 加载后 LoadedPlugin 记录存在且 enabled=false，但能力相关字段为空，有效集合也为空。

调用关系：检查“记录插件状态”和“启用插件能力”这两件事被清楚分开。

调用图：调用 2 个内部函数（load_plugins_from_config, plugin_config_toml）；外部调用 4 个（new, assert!, assert_eq!, write_file）。

async fn effective_apps_dedupes_connector_ids_across_plugins()

作用：验证多个插件声明同一个 App 连接器时，最终有效 App 列表会去重。

数据流：写 plugin-a 和 plugin-b，二者都声明 connector_example，plugin-b 还声明 connector_gmail → 加载后有效 App 只包含 example 一次和 gmail 一次。

调用关系：通过 load_plugins_from_config 检查跨插件 App 去重规则。

调用图：调用 1 个内部函数（load_plugins_from_config）；外部调用 7 个（new, Boolean, Table, assert_eq!, write_file, new, to_string）。

async fn effective_apps_preserves_app_config_order()

作用：验证 App 去重时保留第一次出现的顺序，不会乱排序。

数据流：一个插件依次声明 slack、github、slack-copy，其中 slack-copy 连接器重复 → 加载后输出 slack 再 github。

调用关系：补充 App 去重测试，关注输出顺序的稳定性。

调用图：调用 2 个内部函数（load_plugins_from_config, plugin_config_toml）；外部调用 3 个（new, assert_eq!, write_file）。

fn capability_index_filters_inactive_and_zero_capability_plugins()

作用：验证能力摘要只展示真正启用且有能力的插件，隐藏空插件、禁用插件和加载失败插件。

数据流：手工构造多个 LoadedPlugin：有技能、有 MCP/App、空、禁用、失败 → 调 PluginLoadOutcome::from_plugins → 检查摘要只包含有效能力插件。

调用关系：不读文件，直接测试能力摘要索引的过滤规则。

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

async fn load_plugins_returns_empty_when_feature_disabled()

作用：验证总开关 features.plugins 关闭时，即使插件配置和文件都存在，也不会加载任何插件。

数据流：写插件文件和配置，但 plugins 功能为 false → 读取配置并加载 → 得到默认空结果。

调用关系：检查插件系统的总开关优先级。

调用图：调用 3 个内部函数（new, load_config, plugin_config_toml）；外部调用 3 个（new, assert_eq!, write_file）。

async fn plugin_cache_ignores_unrelated_session_overrides()

作用：验证插件加载缓存不会因为无关的会话配置变化而失效。

数据流：第一次用 session model=first 加载并缓存插件 → 删除 .mcp.json → 第二次只改 session model=second → 仍返回第一次缓存结果，说明无关配置没有触发重载。

调用关系：测试插件缓存键只包含会影响插件的配置，而不是所有会话参数。

调用图：调用 3 个内部函数（new, plugin_config_toml, write_plugin）；外部调用 5 个（new, assert_eq!, write_file, remove_file, from_str）。

fn loaded_plugins_cache_invalidation_rejects_stale_load_completion()

作用：验证清空缓存后，旧一轮异步加载完成时不能把过期结果写回缓存。

数据流：记录旧 generation → 清空缓存让 generation 更新 → 用旧 generation 尝试写缓存 → 再读取缓存应为空。

调用关系：直接测试缓存代数机制，防止竞态条件，也就是两个异步任务先后完成导致旧结果覆盖新状态。

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

async fn load_plugins_rejects_invalid_plugin_keys()

作用：验证配置里的插件键必须是 plugin@marketplace 格式，否则加载结果会带错误且不生效。

数据流：写插件文件，但配置键只写 sample → 加载后有一个插件记录，error 提示格式错误，有效技能和 MCP 都为空。

调用关系：检查配置解析的输入校验，避免模糊插件来源。

调用图：调用 1 个内部函数（load_plugins_from_config）；外部调用 8 个（new, Boolean, Table, assert!, assert_eq!, write_file, new, to_string）。

async fn install_plugin_updates_config_with_relative_path_and_plugin_key()

作用：验证从本地市场安装插件后，会复制到缓存，并把 plugin@marketplace 写入 config.toml。

数据流：造一个市场和本地插件 → 调 install_plugin → 检查返回的安装路径、插件 ID、认证策略，并读取 config.toml 确认插件被启用。

调用关系：测试安装流程的文件复制和配置写入两部分。

调用图：调用 3 个内部函数（new, write_plugin, try_from）；外部调用 6 个（assert!, assert_eq!, create_dir_all, read_to_string, write, tempdir）。

async fn install_openai_curated_plugin_uses_short_sha_cache_version()

作用：验证安装 OpenAI curated 插件时，缓存版本目录使用短 SHA，而不是 local。

数据流：写 curated 市场和当前 SHA → 安装 slack → 检查安装结果里的版本和路径是测试用短 SHA。

调用关系：覆盖官方 curated 插件的特殊版本规则。

调用图：调用 3 个内部函数（new, curated_plugins_repo_path, try_from）；外部调用 5 个（assert_eq!, write_curated_plugin_sha_with, write_openai_curated_marketplace, format!, tempdir）。

async fn install_plugin_uses_manifest_version_for_non_curated_plugins()

作用：验证非 curated 插件安装时，会使用插件 manifest 里的 version 作为缓存目录名。

数据流：写一个 version=1.2.3-beta+7 的插件和市场 → 安装 → 返回结果和缓存路径都使用这个版本号。

调用关系：和 curated 安装测试相对，检查普通市场插件的版本来源。

调用图：调用 3 个内部函数（new, write_plugin_with_version, try_from）；外部调用 4 个（assert_eq!, create_dir_all, write, tempdir）。

async fn install_plugin_supports_git_subdir_marketplace_sources()

作用：验证市场里的插件来源可以是另一个 Git 仓库的子目录。

数据流：创建远程 Git 仓库，插件放在 plugins/toolkit → 市场声明 git-subdir 来源 → 安装后缓存里出现 toolkit 的 plugin.json。

调用关系：使用 init_git_repo 准备真实 Git 来源，测试安装器拉取子目录的能力。

调用图：调用 4 个内部函数（new, init_git_repo, write_plugin, try_from）；外部调用 7 个（assert!, assert_eq!, format!, create_dir_all, write, tempdir, from_directory_path）。

async fn install_plugin_supports_relative_git_subdir_marketplace_sources()

作用：验证 git-subdir 来源的 URL 可以是相对于市场仓库的路径。

数据流：在市场仓库旁边创建相对路径 Git 仓库 → 市场用 ./remote-plugin-repo 声明来源 → 安装后插件进入缓存。

调用关系：补充上一条，测试相对 Git URL 的解析。

调用图：调用 4 个内部函数（new, init_git_repo, write_plugin, try_from）；外部调用 5 个（assert!, assert_eq!, create_dir_all, write, tempdir）。

async fn uninstall_plugin_removes_cache_and_config_entry()

作用：验证卸载插件会删除缓存目录，并从配置文件移除对应插件项；重复卸载也不会出错。

数据流：先写缓存插件和启用配置 → 调 uninstall_plugin 两次 → 检查缓存目录不存在，config.toml 不再包含该插件段。

调用关系：测试卸载流程的幂等性，也就是重复执行结果仍安全。

调用图：调用 2 个内部函数（new, write_plugin）；外部调用 4 个（assert!, write_file, read_to_string, tempdir）。

async fn list_marketplaces_includes_enabled_state()

作用：验证列出市场时，每个插件会标明是否已安装、是否在配置中启用。

数据流：写市场、两个已缓存插件和一个启用一个禁用的配置 → 调 list_marketplaces_for_config → 检查列表里的 installed/enabled 字段准确。

调用关系：测试市场展示信息和用户配置之间的合并。

调用图：调用 4 个内部函数（new, load_config, write_plugin, try_from）；外部调用 5 个（assert_eq!, write_file, create_dir_all, write, tempdir）。

async fn list_marketplaces_returns_empty_when_feature_disabled()

作用：验证插件总开关关闭时，市场列表也直接为空。

数据流：写一个市场和插件配置，但 features.plugins=false → 列市场 → 返回空列表。

调用关系：和加载开关测试一致，确认 UI 列市场也尊重总开关。

调用图：调用 3 个内部函数（new, load_config, try_from）；外部调用 5 个（assert_eq!, write_file, create_dir_all, write, tempdir）。

async fn list_marketplaces_excludes_plugins_with_explicit_empty_products()

作用：验证市场里明确写 products=[] 的插件会被排除，默认没有 products 的插件仍显示。

数据流：市场里放 disabled-plugin 和 default-plugin，前者 policy.products 为空数组 → 列市场 → 只看到 default-plugin。

调用关系：测试产品限制过滤，避免把不适用当前产品的插件显示出来。

调用图：调用 3 个内部函数（new, load_config, try_from）；外部调用 5 个（assert_eq!, write_file, create_dir_all, write, tempdir）。

async fn read_plugin_for_config_returns_plugins_disabled_when_feature_disabled()

作用：验证插件总开关关闭时，读取某个插件详情会返回 PluginsDisabled 错误。

数据流：写市场和配置，但 features.plugins=false → 调 read_plugin_for_config → 得到 MarketplaceError::PluginsDisabled。

调用关系：检查详情读取接口也遵守总开关。

调用图：调用 3 个内部函数（new, load_config, try_from）；外部调用 5 个（assert!, write_file, create_dir_all, write, tempdir）。

async fn read_plugin_for_config_filters_mcp_servers_for_codex_backend_auth()

作用：验证读取插件详情时，也会按认证方式过滤 App 和同名 MCP。

数据流：插件同时声明 sample-mcp App 和 sample-mcp MCP，另有 other-mcp → ChatGPT 读取时 App 显示、sample-mcp 隐藏；ApiKey 读取时 App 隐藏、两个 MCP 都显示。

调用关系：把认证投影规则应用到插件详情读取接口，而不仅是加载接口。

调用图：调用 3 个内部函数（new_with_options, load_config, try_from）；外部调用 5 个（assert!, assert_eq!, write_file, create_dir_all, tempdir）。

async fn read_plugin_for_config_uses_user_layer_skill_settings_only()

作用：验证读取市场插件详情时，只用用户层的技能设置，不受项目目录 .codex/config.toml 影响。

数据流：用户配置启用插件，项目配置禁用某技能 → 读取插件详情 → disabled_skill_paths 为空，说明项目配置没有参与。

调用关系：测试配置层级边界，避免项目配置影响市场详情预览。

调用图：调用 3 个内部函数（new, load_config, try_from）；外部调用 4 个（assert!, write_file, create_dir_all, tempdir）。

async fn read_plugin_for_config_uninstalled_git_source_requires_install_without_cloning()

作用：验证未安装的 Git 来源插件，读取详情时不会去克隆远程仓库，而是提示需要先安装。

数据流：市场声明一个不存在的 Git 仓库来源 → 读取详情 → 返回安装必需的原因和说明，技能/App/MCP 为空，临时 staging 目录也没创建。

调用关系：保护详情页不做昂贵或失败的网络克隆操作。

调用图：调用 3 个内部函数（new, load_config, try_from）；外部调用 7 个（assert!, assert_eq!, write_file, format!, create_dir_all, tempdir, from_directory_path）。

async fn read_plugin_for_config_installed_git_source_reads_from_cache_without_cloning()

作用：验证 Git 来源插件如果已经安装，读取详情会直接看本地缓存，不去访问远程仓库。

数据流：市场指向不存在远程，但本地缓存里有完整插件文件 → 读取详情 → 得到描述、界面信息、技能、App、hook 和 MCP，并确认没有 staging 目录。

调用关系：和上一条配对，说明未安装不克隆、已安装读缓存。

调用图：调用 3 个内部函数（new, load_config, try_from）；外部调用 7 个（assert!, assert_eq!, write_file, format!, create_dir_all, tempdir, from_directory_path）。

async fn list_marketplaces_installed_git_source_reads_metadata_from_cache_without_cloning()

作用：验证列市场时，已安装的 Git 来源插件可以从缓存读取 manifest 展示信息，而不用克隆远程。

数据流：市场指向不存在远程，缓存 manifest 里有图标、logo、截图等界面字段 → 列市场 → 插件条目包含缓存里的展示元数据和绝对资源路径。

调用关系：测试市场列表接口的缓存读取逻辑，与插件详情读取缓存测试互补。

调用图：调用 3 个内部函数（new, load_config, try_from）；外部调用 7 个（assert!, assert_eq!, write_file, format!, create_dir_all, tempdir, from_directory_path）。

async fn list_marketplaces_includes_curated_repo_marketplace()

作用：验证本地存在 OpenAI curated 仓库时，列市场会包含这个官方市场。

数据流：写 curated 仓库的 marketplace.json 和 linear 插件 → 打开插件功能 → 列市场 → 找到 openai-curated 市场及 linear 条目。

调用关系：检查官方 curated 市场的自动发现。

调用图：调用 3 个内部函数（new, load_config, curated_plugins_repo_path）；外部调用 5 个（assert_eq!, write_file, create_dir_all, write, tempdir）。

async fn list_marketplaces_can_skip_openai_curated_before_loading()

作用：验证调用方要求不包含 OpenAI curated 时，即使 curated manifest 是坏 JSON，也不会读取它、不会报错。

数据流：写一个损坏的 curated marketplace.json → include_openai_curated=false 列市场 → errors 为空，结果里没有 openai-curated。

调用关系：测试可选跳过官方市场的开关，避免不必要的解析错误。

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

async fn list_marketplaces_uses_api_curated_manifest_when_selected()

作用：验证在 API Key 类认证下，市场列表会使用 openai-api-curated 的 manifest。

数据流：同时写普通 curated 和 API curated manifest → 管理器认证设为 ApiKey → 列市场 → 返回 openai-api-curated 及其中 api-plugin。

调用关系：测试认证模式对官方 curated 市场选择的影响。

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

async fn list_marketplaces_skips_missing_api_curated_manifest()

作用：验证需要 API curated 市场但对应 manifest 缺失时，系统安静跳过，不报错。

数据流：只写损坏的普通 curated manifest，不写 API manifest → 设置 BedrockApiKey 认证 → 列市场 → 没有错误，也没有 API curated 市场。

调用关系：补充 API curated 选择逻辑的缺文件分支。

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

async fn list_marketplaces_includes_installed_marketplace_roots()

作用：验证配置里记录过的已安装市场根目录，也会被列入市场列表。

数据流：在 installed marketplaces 根目录写 debug 市场和 sample 插件，并在 config.toml 写 marketplaces.debug → 列市场 → 找到这个安装市场和 sample 插件。

调用关系：测试除了项目里的市场，已安装市场也能被发现。

调用图：调用 3 个内部函数（marketplace_install_root, new, load_config）；外部调用 5 个（assert_eq!, write_file, create_dir_all, write, tempdir）。

async fn list_marketplaces_uses_config_when_known_registry_is_malformed()

作用：验证已知市场注册表文件损坏时，系统仍能靠 config.toml 里的市场记录发现市场。

数据流：写配置中的 debug 市场和损坏的 known_marketplaces.json → 列市场 → 仍能发现 sample@debug。

调用关系：测试注册表坏掉时的降级路径。

调用图：调用 3 个内部函数（marketplace_install_root, new, load_config）；外部调用 5 个（assert_eq!, write_file, create_dir_all, write, tempdir）。

async fn list_marketplaces_ignores_installed_roots_missing_from_config()

作用：验证安装目录里有市场文件，但配置没记录该市场时，不会自动列出。

数据流：写 installed marketplace 文件，但 config.toml 没有 marketplaces.debug → 列市场 → 结果不包含这个市场路径。

调用关系：和前两条一起确定已安装市场必须受配置记录约束。

调用图：调用 3 个内部函数（marketplace_install_root, new, load_config）；外部调用 5 个（assert!, write_file, create_dir_all, write, tempdir）。

async fn list_marketplaces_uses_first_duplicate_plugin_entry()

作用：验证多个市场文件里出现同名同市场插件时，只保留第一次看到的条目。

数据流：repo-a 和 repo-b 都有 debug 市场且都声明 dup-plugin，repo-b 另有 b-only-plugin → 按 repo-a、repo-b 顺序列市场 → dup-plugin 只来自 repo-a，repo-b 只剩 b-only-plugin。

调用关系：测试去重和搜索顺序，避免同一个 plugin@marketplace 在界面里出现两次。

调用图：调用 3 个内部函数（new, load_config, try_from）；外部调用 5 个（assert_eq!, write_file, create_dir_all, write, tempdir）。

async fn list_marketplaces_marks_configured_plugin_uninstalled_when_cache_is_missing()

作用：验证配置里启用了插件，但本地缓存缺失时，市场列表会显示 enabled=true、installed=false。

数据流：写市场和启用配置，但不写缓存插件 → 列市场 → 插件条目标记未安装但已启用。

调用关系：测试配置状态和安装状态分开表达。

调用图：调用 3 个内部函数（new, load_config, try_from）；外部调用 5 个（assert_eq!, write_file, create_dir_all, write, tempdir）。

async fn featured_plugin_ids_for_config_uses_restriction_product_query_param()

作用：验证请求精选插件时，如果管理器限制产品为 ChatGPT，会把 platform=chat 传给后端。

数据流：启动假服务器并要求 GET /plugins/featured 带 platform=chat 和认证头 → 调 featured_plugin_ids_for_config → 返回 chat-plugin。

调用关系：使用 wiremock 模拟后端，测试精选插件接口的查询参数和认证头。

调用图：调用 3 个内部函数（new_with_options, load_config, create_dummy_chatgpt_auth_for_testing）；外部调用 11 个（given, start, new, assert_eq!, write_file, format!, tempdir, header, method, path (+1 more)）。

async fn featured_plugin_ids_for_config_defaults_query_param_to_codex()

作用：验证没有指定产品限制时，请求精选插件默认使用 platform=codex。

数据流：假服务器期待 platform=codex → 管理器无 restriction_product → 调接口 → 返回 codex-plugin。

调用关系：和上一条配对，覆盖默认产品参数。

调用图：调用 2 个内部函数（new_with_options, load_config）；外部调用 10 个（given, start, new, assert_eq!, write_file, format!, tempdir, method, path, query_param）。

async fn remote_plugin_caches_refresh_warms_recommended_plugins_cache()

作用：验证启动远程插件缓存刷新后，会在后台预热推荐插件缓存。

数据流：配置打开 remote_plugin，假服务器返回 enabled=true 且插件为空 → 启动 maybe_start_remote_plugin_caches_refresh → 轮询直到缓存出现 → 检查缓存内容并测试清空缓存。

调用关系：测试后台刷新任务和 recommended_plugins_mode 缓存之间的配合。

调用图：调用 3 个内部函数（new, load_config, create_dummy_chatgpt_auth_for_testing）；外部调用 15 个（from_millis, from_secs, given, start, new, assert_eq!, write_file, json!, new, tempdir (+5 more)）。

async fn recommended_plugins_mode_deduplicates_concurrent_cache_misses()

作用：验证两个并发请求推荐插件缓存未命中时，只会向后端发一次请求，两个调用共享结果。

数据流：假服务器设置延迟并期望只被调用一次 → 同时发起两次 recommended_plugins_mode_for_config → 两边都得到同一组推荐插件，后续再调用直接走缓存。

调用关系：测试并发去重，防止多个任务同时打爆同一个后端接口。

调用图：调用 3 个内部函数（new, load_config, create_dummy_chatgpt_auth_for_testing）；外部调用 14 个（from_millis, given, start, new, assert_eq!, write_file, json!, tempdir, join!, vec! (+4 more)）。

async fn recommended_plugins_mode_caches_explicit_false()

作用：验证后端明确返回 enabled=false 时，会缓存“使用旧模式”的结果。

数据流：假服务器返回 enabled=false → 第一次调用得到 Legacy → 第二次调用仍得到 Legacy，且不会再次请求服务器。

调用关系：测试推荐插件模式的负结果缓存。

调用图：调用 3 个内部函数（new, load_config, create_dummy_chatgpt_auth_for_testing）；外部调用 9 个（given, start, new, assert_eq!, write_file, json!, tempdir, method, path）。

async fn recommended_plugins_mode_retries_after_fetch_failure()

作用：验证推荐插件请求失败时不会把失败永久缓存，后面还能重试成功。

数据流：第一次假服务器返回 500 → 调用得到 Legacy 兜底 → 重置服务器返回成功 → 再调用得到 Endpoint 空插件列表。

调用关系：测试网络失败后的恢复能力。

调用图：调用 3 个内部函数（new, load_config, create_dummy_chatgpt_auth_for_testing）；外部调用 9 个（given, start, new, assert_eq!, write_file, json!, tempdir, method, path）。

fn refresh_curated_plugin_cache_replaces_existing_local_version_with_short_sha_version()

作用：验证刷新官方 curated 插件缓存时，会把旧 local 版本替换成当前短 SHA 版本。

数据流：写 curated 市场、当前 SHA 和旧 local 缓存 → 调 refresh_curated_plugin_cache → local 目录消失，短 SHA 目录出现。

调用关系：测试官方插件缓存版本迁移的常见路径。

调用图：调用 3 个内部函数（write_plugin, curated_plugins_repo_path, new）；外部调用 4 个（assert!, write_curated_plugin_sha_with, write_openai_curated_marketplace, tempdir）。

fn refresh_curated_plugin_cache_reinstalls_missing_configured_plugin_with_current_short_version()

作用：验证配置中的官方 curated 插件如果缓存缺失，刷新时会重新安装当前版本。

数据流：写 curated 市场和 SHA，但不写插件缓存 → 刷新 → 当前短 SHA 缓存目录被创建。

调用关系：覆盖官方缓存丢失后的自修复。

调用图：调用 2 个内部函数（curated_plugins_repo_path, new）；外部调用 4 个（assert!, write_curated_plugin_sha_with, write_openai_curated_marketplace, tempdir）。

fn refresh_curated_plugin_cache_reinstalls_missing_api_curated_plugin()

作用：验证 API curated 市场里的已配置插件缓存缺失时，也能被刷新重新安装。

数据流：写普通 curated 为空、API curated 含 api-only → 刷新指定 api-only 插件 → openai-api-curated 下出现短 SHA 版本目录。

调用关系：测试 API curated 和普通 curated 使用同一刷新机制。

调用图：调用 3 个内部函数（curated_plugins_repo_path, write_openai_api_curated_marketplace, new）；外部调用 4 个（assert!, write_curated_plugin_sha_with, write_openai_curated_marketplace, tempdir）。

fn refresh_curated_plugin_cache_leaves_api_curated_plugin_when_api_manifest_missing()

作用：验证 API curated manifest 缺失时，刷新不会删除已有 API curated 插件缓存。

数据流：只写普通 curated manifest，已有 api-only 缓存 → 刷新 api-only → 返回 false，原 local 缓存仍在。

调用关系：保护已有缓存，避免因为 manifest 缺失误删插件。

调用图：调用 3 个内部函数（write_cached_plugin, curated_plugins_repo_path, new）；外部调用 3 个（assert!, write_openai_curated_marketplace, tempdir）。

fn refresh_curated_plugin_cache_removes_cache_for_plugin_removed_from_marketplace()

作用：验证官方市场已经移除的插件，在刷新时会删除对应缓存。

数据流：curated 市场不再包含 google-sheets，但缓存里有它 → 刷新 → google-sheets 缓存根目录被删除。

调用关系：测试官方市场下架插件后的缓存清理。

调用图：调用 3 个内部函数（write_plugin, curated_plugins_repo_path, new）；外部调用 4 个（assert!, write_openai_curated_marketplace, format!, tempdir）。

fn curated_plugin_ids_from_config_keys_reads_latest_codex_home_user_config()

作用：验证从用户配置里提取官方 curated 插件 ID 时，会读取当前最新的 config.toml。

数据流：先写包含 openai-curated、openai-api-curated 和普通 debug 插件的配置 → 只提取两个官方插件 → 再重写为空配置 → 提取结果为空。

调用关系：测试刷新 curated 缓存前用于找配置插件的辅助逻辑。

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

fn refresh_curated_plugin_cache_returns_false_when_configured_plugins_are_current()

作用：验证官方 curated 插件缓存已经是当前短 SHA 版本时，刷新会判断无事可做。

数据流：写 curated 市场和当前版本缓存 → 调刷新 → 返回 false，表示没有改动。

调用关系：测试缓存刷新避免无意义重装。

调用图：调用 3 个内部函数（write_plugin, curated_plugins_repo_path, new）；外部调用 4 个（assert!, write_openai_curated_marketplace, format!, tempdir）。

fn refresh_curated_plugin_cache_migrates_full_sha_cache_version_to_short_version()

作用：验证旧缓存目录如果用完整 SHA 命名，刷新会迁移到短 SHA 命名。

数据流：写完整 SHA 版本目录 → 调刷新 → 完整 SHA 目录删除，短 SHA 目录出现。

调用关系：测试历史版本命名兼容。

调用图：调用 3 个内部函数（write_plugin, curated_plugins_repo_path, new）；外部调用 4 个（assert!, write_openai_curated_marketplace, format!, tempdir）。

fn refresh_non_curated_plugin_cache_replaces_existing_local_version_with_manifest_version()

作用：验证非官方市场插件如果 manifest 有版本号，刷新会把旧 local 缓存替换成 manifest 版本。

数据流：市场插件版本为 1.2.3，本地缓存是 local → 刷新非 curated 缓存 → local 消失，1.2.3 目录出现。

调用关系：测试普通市场缓存刷新和版本识别。

调用图：调用 2 个内部函数（write_plugin, write_plugin_with_version）；外部调用 4 个（assert!, write_file, create_dir_all, tempdir）。

fn refresh_non_curated_plugin_cache_reinstalls_missing_configured_plugin_with_manifest_version()

作用：验证配置中的非官方插件缓存缺失时，刷新会按 manifest 版本重新安装。

数据流：写市场和版本 1.2.3 的源插件，但没有缓存 → 刷新 → 缓存里创建 1.2.3 目录。

调用关系：覆盖普通市场缓存丢失后的重建。

调用图：调用 1 个内部函数（write_plugin_with_version）；外部调用 4 个（assert!, write_file, create_dir_all, tempdir）。

fn refresh_non_curated_plugin_cache_refreshes_configured_git_source()

作用：验证非官方市场里的 Git 子目录来源插件，也能通过刷新缓存被拉取并安装。

数据流：创建 Git 仓库，子目录插件版本 1.2.3 → 市场声明 git-subdir 来源并配置启用 → 刷新 → 缓存中出现 1.2.3 版本。

调用关系：结合 init_git_repo，测试普通市场刷新支持 Git 来源。

调用图：调用 2 个内部函数（init_git_repo, write_plugin_with_version）；外部调用 6 个（assert!, write_file, format!, create_dir_all, tempdir, from_directory_path）。

fn refresh_non_curated_plugin_cache_returns_false_when_configured_plugins_are_current()

作用：验证非官方插件缓存已经是 manifest 当前版本时，刷新返回 false。

数据流：源插件和缓存插件都为 1.2.3 → 调 refresh_non_curated_plugin_cache → 没有改动，返回 false。

调用关系：测试普通市场刷新避免重复安装。

调用图：调用 1 个内部函数（write_plugin_with_version）；外部调用 4 个（assert!, write_file, create_dir_all, tempdir）。

fn refresh_non_curated_plugin_cache_force_reinstalls_current_local_version()

作用：验证强制刷新即使版本仍是 local，也会重新复制源插件内容。

数据流：源插件技能文件写 new skill，缓存同版本 local 里是 old skill → 调 force_reinstall → 缓存文件变成 new skill。

调用关系：测试手动强制刷新场景，适合本地开发插件更新但版本不变。

调用图：调用 1 个内部函数（write_plugin）；外部调用 6 个（assert!, assert_eq!, write_file, create_dir_all, write, tempdir）。

fn refresh_non_curated_plugin_cache_ignores_invalid_unconfigured_plugin_versions()

作用：验证市场里未配置的插件即使版本号非法，也不会影响已配置插件的刷新。

数据流：市场有 sample-plugin 版本 1.2.3 和 broken-plugin 空白版本；配置只启用 sample-plugin → 刷新 → sample-plugin 正常安装。

调用关系：测试刷新过程只关心配置中的插件，避免无关坏插件拖垮整体。

调用图：调用 1 个内部函数（write_plugin_with_version）；外部调用 4 个（assert!, write_file, create_dir_all, tempdir）。

async fn load_plugins_ignores_project_config_files()

作用：验证加载插件时会忽略项目目录里的插件配置，只信任允许的配置层。

数据流：项目配置里启用插件，但构造的配置层来源是 Project → 调 load_plugins_from_layer_stack → 返回空列表。

调用关系：测试配置层来源过滤，避免项目仓库偷偷启用插件。

调用图：调用 4 个内部函数（new, load_plugins_from_layer_stack, plugin_config_toml, new）；外部调用 7 个（new, default, assert_eq!, default, write_file, new, vec!）。

async fn plugin_hooks_for_layer_stack_loads_configured_plugin_hooks()

作用：验证已配置插件里的 hooks/hooks.json 能被加载成插件 hook 来源。

数据流：写插件和 hooks.json，配置启用插件 → 调 plugin_hooks_for_layer_stack → 输出一个 hook source，且没有加载警告。

调用关系：测试插件 hook 加载入口，确保插件不仅能提供技能和 MCP，也能提供事件 hook。

调用图：调用 4 个内部函数（new, load_config, plugin_config_toml, write_plugin）；外部调用 3 个（new, assert_eq!, write_file）。

async fn returns_fallback_plugins_without_installed_apps()

作用：测试在没有任何已安装应用时，系统会返回默认的精选插件推荐。它确认“sample”这种不该推荐的插件不会混进列表。

数据流：进去的是一个临时目录和写好的 OpenAI 精选插件市场，里面有 sample、slack、openai-developers → 测试加载插件配置，创建 PluginsManager，再请求可发现插件列表 → 出来应只剩 openai-developers 和 slack 两个推荐项，并按预期顺序返回。

调用关系：它先用 curated_plugins_repo_path 找到测试市场目录，用 write_openai_curated_marketplace 准备数据，再通过 discovery_input 组装输入，交给 list_discoverable_plugins 调用真正的插件发现逻辑，最后用断言核对结果。

调用图：调用 4 个内部函数（discovery_input, list_discoverable_plugins, new, curated_plugins_repo_path）；外部调用 4 个（assert_eq!, load_plugins_config, write_openai_curated_marketplace, tempdir）。

async fn returns_api_curated_fallback_plugins_for_direct_provider_auth()

作用：测试当用户用 API key 这种直接服务商认证方式登录时，默认推荐来自 API 专用精选市场。这样不同登录方式能看到正确来源的插件。

数据流：进去的是临时目录、API 精选市场文件，以及一个测试 API key 认证对象 → 系统加载配置后，根据认证方式列出可推荐插件 → 出来应是 openai-developers@openai-api-curated 和 slack@openai-api-curated。

调用关系：它和普通默认推荐测试很像，但额外用 from_api_key 创建认证信息，并调用 write_openai_api_curated_marketplace 写入 API 版市场，随后仍通过 discovery_input 和 list_discoverable_plugins 走同一条发现流程。

调用图：调用 6 个内部函数（discovery_input, list_discoverable_plugins, new, curated_plugins_repo_path, write_openai_api_curated_marketplace, from_api_key）；外部调用 3 个（assert_eq!, load_plugins_config, tempdir）。

async fn returns_microsoft_fallback_plugins()

作用：测试当用户已经安装了 Microsoft 相关插件里的一个时，系统会推荐同一组里剩下的 Microsoft 插件。这样用户装了 Teams 后，还能被提示安装 Outlook、SharePoint 等配套插件。

数据流：进去的是包含 teams、sharepoint、outlook-email、outlook-calendar 的精选市场，并且先安装 teams → 插件发现逻辑会排除已安装的 teams，再找同组可推荐项 → 出来是 outlook-calendar、outlook-email、sharepoint。

调用关系：测试用 install_marketplace_plugin 模拟已安装 teams，然后用 discovery_input 生成发现请求，list_discoverable_plugins 负责调用真实推荐逻辑，最后断言推荐的是剩余 Microsoft 插件。

调用图：调用 5 个内部函数（discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path）；外部调用 4 个（assert_eq!, load_plugins_config, write_openai_curated_marketplace, tempdir）。

async fn includes_openai_curated_when_remote_enabled()

作用：测试远程插件功能打开时，本地配置的捆绑市场和 OpenAI 精选市场都能出现在推荐结果里。它防止打开远程功能后把本地精选推荐意外屏蔽掉。

数据流：进去的是一个本地精选市场 slack、一个配置出来的 bundled 市场 chrome，以及打开 plugins 和 remote_plugin 的配置文件 → 系统读取配置和市场内容，合并可推荐插件 → 出来应同时包含 chrome@openai-bundled 和 slack@openai-curated。

调用关系：它用 write_file 手写配置和 marketplace.json，用 write_curated_plugin 写插件目录，再通过 load_plugins_config、discovery_input、list_discoverable_plugins 触发真实发现流程。

调用图：调用 4 个内部函数（discovery_input, list_discoverable_plugins, new, curated_plugins_repo_path）；外部调用 7 个（assert_eq!, load_plugins_config, write_curated_plugin, write_file, write_openai_curated_marketplace, format!, tempdir）。

async fn deduplicates_configured_marketplace_plugin()

作用：测试同一个插件既在配置里出现，又在市场里能被发现时，结果里只出现一次。这样用户界面不会展示重复条目。

数据流：进去的是一个 bundled 市场里的 sample 插件，以及 configured_plugin_ids 里同样的 sample@openai-bundled → 发现逻辑识别这是同一个插件并去重 → 出来列表长度是 1，唯一条目就是这个插件。

调用关系：它自己搭好市场文件和配置文件，然后通过 discovery_input 把“已配置插件 ID”传进去，list_discoverable_plugins 负责跑发现逻辑，断言用来确认去重生效。

调用图：调用 3 个内部函数（discovery_input, list_discoverable_plugins, new）；外部调用 6 个（assert_eq!, load_plugins_config, write_curated_plugin, write_file, format!, tempdir）。

async fn ignores_missing_marketplace_plugin()

作用：测试市场清单里写了某个插件，但插件实际目录或内容缺失时，系统会跳过它。这样坏掉的市场条目不会变成用户能点的假推荐。

数据流：进去的是精选市场 installed、slack，以及另一个 configured 市场里只有清单、缺少实际 sample 插件内容 → 系统读取市场时发现 sample 不完整，忽略它，同时排除已安装 installed → 出来只推荐 slack@openai-curated。

调用关系：它用 write_file 制造一个缺内容的市场，用 install_marketplace_plugin 安装 installed，再把准备好的环境交给 discovery_input 和 list_discoverable_plugins 检查真实行为。

调用图：调用 5 个内部函数（discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path）；外部调用 6 个（assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, format!, tempdir）。

async fn normalizes_description()

作用：测试插件描述里的换行、多余空格会被整理成一段干净文本。这样用户看到的插件说明不会因为文件格式乱而难读。

数据流：进去的是 slack 插件的 plugin.json，描述写成带前后空格、换行和连续空格的文本 → 发现逻辑读取插件信息并清理描述 → 出来的是 description 为 “Plugin with extra spacing” 的推荐对象，同时保留技能、MCP 服务器和应用连接器等信息。

调用关系：它先写入特殊格式的 plugin.json，再安装另一个插件用于触发排除逻辑，最后通过 list_discoverable_plugins 得到完整的 ToolSuggestDiscoverablePlugin 并精确比对。

调用图：调用 5 个内部函数（discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path）；外部调用 5 个（assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, tempdir）。

async fn omits_installed_curated_plugins()

作用：测试已经安装过的精选插件不会再被推荐。这样用户不会看到“安装你已经有的东西”这种重复提示。

数据流：进去的是一个只包含 slack 的精选市场，并且 slack 已经被安装 → 发现逻辑读取已安装状态后过滤掉 slack → 出来是空列表。

调用关系：它用 install_marketplace_plugin 模拟安装，再用 discovery_input 和 list_discoverable_plugins 走推荐流程，最后断言没有任何推荐。

调用图：调用 5 个内部函数（discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path）；外部调用 4 个（assert_eq!, load_plugins_config, write_openai_curated_marketplace, tempdir）。

async fn omits_not_available_curated_plugins()

作用：测试市场里标记为 NOT_AVAILABLE（不可安装）的插件不会被推荐。这样还没开放或被禁止安装的插件不会出现在用户面前。

数据流：进去的是一个手写市场：installed、slack、gmail，其中 gmail 的安装策略是不可用，并且 installed 已安装 → 发现逻辑排除已安装项和不可用项 → 出来只剩 slack@openai-curated。

调用关系：它用 write_file 手写带 policy 的 marketplace.json，用 write_curated_plugin 准备插件目录，用 install_marketplace_plugin 标记 installed 已安装，再交给 list_discoverable_plugins 验证过滤规则。

调用图：调用 5 个内部函数（discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path）；外部调用 5 个（assert_eq!, load_plugins_config, write_curated_plugin, write_file, tempdir）。

async fn does_not_reload_marketplace_per_plugin()

作用：测试系统不会为了每个插件都重新加载一次市场。它主要防止性能浪费，也防止同一类警告日志重复爆炸。

数据流：进去的是包含 slack、gmail、openai-developers 的市场，其中 slack 已安装，另外两个插件写了过长的默认提示，会触发警告 → 发现逻辑读取市场并处理剩余两个插件 → 出来推荐 gmail 和 openai-developers，同时日志里每个问题只按预期次数出现，没有因为反复重载而变多。

调用关系：它设置 tracing 日志收集器来抓警告，再调用 list_discoverable_plugins。测试最后检查推荐结果和日志次数，用日志侧面证明市场没有被每个插件重复读取。

调用图：调用 5 个内部函数（discovery_input, install_marketplace_plugin, list_discoverable_plugins, new, curated_plugins_repo_path）；外部调用 14 个（leak, new, new, from_utf8, new, assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, format! (+4 more)）。

async fn does_not_expand_local_plugins_by_installed_apps()

作用：测试本地精选插件不会因为某个应用连接器存在就被额外展开推荐。也就是说，本地插件推荐不能只靠“应用匹配”自动冒出来。

数据流：进去的是 sample、slack、hubspot 市场，其中 sample 写了应用连接器信息，slack 已安装 → 发现逻辑不会因为 sample 的应用信息就推荐它，也会排除已安装 slack → 出来是空列表。

调用关系：它用 write_plugin_app 给 sample 写 .app.json，再用 install_marketplace_plugin 安装 slack，之后通过 discovery_input 和 list_discoverable_plugins 验证本地插件不会按已安装应用扩展。

调用图：调用 6 个内部函数（discovery_input, install_marketplace_plugin, list_discoverable_plugins, write_plugin_app, new, curated_plugins_repo_path）；外部调用 4 个（assert_eq!, load_plugins_config, write_openai_curated_marketplace, tempdir）。

async fn does_not_read_local_plugins_for_loaded_apps()

作用：测试当系统只根据“已加载应用”判断时，不会去读取无关本地插件的 .app.json。这样可以避免无关坏文件导致警告或失败。

数据流：进去的是 hubspot、granola、sample 三个本地插件，其中 sample 的 .app.json 故意写成非法 JSON，输入里声明 hubspot 应用已加载 → 发现逻辑不扫描无关本地插件应用文件 → 出来是空推荐，并且日志里没有 sample/.app.json 的错误记录。

调用关系：它用 write_plugin_app 写两个正常应用文件，用 write_file 写一个坏文件，再设置日志收集器。list_discoverable_plugins 跑完后，测试通过日志内容确认坏文件没有被读取。

调用图：调用 5 个内部函数（discovery_input, list_discoverable_plugins, write_plugin_app, new, curated_plugins_repo_path）；外部调用 13 个（leak, new, new, from_utf8, new, assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, new (+3 more)）。

async fn does_not_expand_local_sales_apps()

作用：测试本地安装的 sales 类插件即使声明了多个应用连接器，也不会让相关本地精选插件被自动推荐。它防止本地应用关系被误当成推荐依据。

数据流：进去的是 OpenAI 精选里的 hubspot、granola、test-source，以及另一个本地 sales 市场；sales 插件已安装并声明 hubspot、granola 应用 → 发现逻辑不按这些本地应用关系扩展推荐 → 出来是空列表。

调用关系：它用 write_plugin_app 准备精选插件应用信息，又手写 sales 市场和 .app.json，安装 sales 后通过 list_discoverable_plugins 验证不会产生额外本地推荐。

调用图：调用 6 个内部函数（discovery_input, install_marketplace_plugin, list_discoverable_plugins, write_plugin_app, new, curated_plugins_repo_path）；外部调用 7 个（assert_eq!, load_plugins_config, write_curated_plugin, write_file, write_openai_curated_marketplace, format!, tempdir）。

async fn expands_cached_remote_plugins_by_loaded_apps()

作用：测试远程插件可以根据“已加载应用连接器”从缓存里被推荐出来。和本地插件不同，远程插件目录缓存里有匹配的 app_id 时，应该能补进推荐列表。

数据流：进去的是打开 remote_plugin 的配置、一个假的远程服务器返回的全局插件 remote-unlisted，以及 loaded_plugin_app_connector_ids 里的 remote-unlisted-app → 测试先抓取并缓存远程全局插件目录，再缓存远程已安装插件市场，最后运行发现逻辑 → 出来是 remote-unlisted@openai-curated-remote，带远程插件 ID、显示名、短描述、技能标记和应用连接器 ID。

调用关系：它用 wiremock 启动假服务器并设定接口响应，用 fetch_and_cache_global_remote_plugin_catalog 写入远程目录缓存，再让 PluginsManager 构建远程已安装缓存，最后通过 list_discoverable_plugins 检查远程应用匹配推荐。

调用图：调用 5 个内部函数（discovery_input, list_discoverable_plugins, new, fetch_and_cache_global_remote_plugin_catalog, create_dummy_chatgpt_auth_for_testing）；外部调用 12 个（given, start, new, assert_eq!, load_plugins_config, write_file, format!, json!, tempdir, method (+2 more)）。

fn discovery_input(
    plugins: PluginsConfigInput,
    configured_plugin_ids: &[&str],
    disabled_plugin_ids: &[&str],
    loaded_plugin_app_connector_ids: &[&str],
) -> ToolSuggestPluginDiscovery

作用：这是测试里的小帮手，用来把插件配置和几组插件 ID 包成一次“发现插件”的输入。它让每个测试不用重复写同样的结构体组装代码。

数据流：进去的是 PluginsConfigInput，以及配置过的插件 ID、禁用的插件 ID、已加载应用连接器 ID 这三组字符串切片 → 它把三组字符串都转成 HashSet，也就是不重复的字符串集合 → 出来是 ToolSuggestPluginDiscoveryInput，供插件发现函数使用。

调用关系：大多数测试都会先调用它准备输入；它内部把转换工作交给 string_set，然后这个输入通常会立刻传给 list_discoverable_plugins。

调用图：调用 1 个内部函数（string_set）；被 14 处调用（deduplicates_configured_marketplace_plugin, does_not_expand_local_plugins_by_installed_apps, does_not_expand_local_sales_apps, does_not_read_local_plugins_for_loaded_apps, does_not_reload_marketplace_per_plugin, expands_cached_remote_plugins_by_loaded_apps, ignores_missing_marketplace_plugin, includes_openai_curated_when_remote_enabled, normalizes_description, omits_installed_curated_plugins (+4 more)）。

async fn list_discoverable_plugins(
    plugins_manager: &PluginsManager,
    input: ToolSuggestPluginDiscoveryInput,
    auth: Option<&CodexAuth>,
) -> Vec<ToolSuggestDiscoverablePlugin>

作用：这是测试里的包装函数，用来调用真正的插件发现接口，并把错误处理简化掉。测试只关心结果列表，不想每次都写 expect。

数据流：进去的是 PluginsManager、发现输入和可选认证信息 → 它调用 list_tool_suggest_discoverable_plugins 等待异步结果，如果失败就让测试直接失败 → 出来是 Vec<ToolSuggestDiscoverablePlugin，也就是可推荐插件列表。

调用关系：几乎所有测试的核心一步都通过它完成；它本身不决定推荐规则，只是把测试准备好的数据交给 PluginsManager 的真实实现。

调用图：被 14 处调用（deduplicates_configured_marketplace_plugin, does_not_expand_local_plugins_by_installed_apps, does_not_expand_local_sales_apps, does_not_read_local_plugins_for_loaded_apps, does_not_reload_marketplace_per_plugin, expands_cached_remote_plugins_by_loaded_apps, ignores_missing_marketplace_plugin, includes_openai_curated_when_remote_enabled, normalizes_description, omits_installed_curated_plugins (+4 more)）；外部调用 1 个（list_tool_suggest_discoverable_plugins）。

fn string_set(values: &[&str]) -> HashSet<String>

作用：这是一个很小的转换工具，把字符串数组变成字符串集合。集合的好处是自动去重，也方便后面的发现逻辑快速判断某个 ID 是否存在。

数据流：进去的是一组 &str 字符串引用 → 它逐个复制成 String，并收集到 HashSet 里 → 出来是不重复的字符串集合。

调用关系：它只被 discovery_input 调用，专门为测试输入里的 configured_plugin_ids、disabled_plugin_ids 和 loaded_plugin_app_connector_ids 服务。

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

async fn install_marketplace_plugin(codex_home: &Path, marketplace_root: &Path, plugin_name: &str)

作用：这是测试里的安装插件帮手，用来把某个市场插件装进临时 Codex 主目录。它让测试能方便地模拟“用户已经安装过这个插件”的状态。

数据流：进去的是 Codex 主目录、市场根目录和插件名 → 它先写入测试用的精选插件版本号，再创建 PluginsManager，构造 PluginInstallRequest，指向 marketplace.json → 出来没有直接返回值，但临时目录里的插件安装状态被改变；如果安装失败，测试会立刻失败。

调用关系：很多测试在验证“已安装插件要被排除”前会调用它。它把实际安装动作交给 PluginsManager.install_plugin，因此测试用到的安装状态和真实系统保持一致。

调用图：调用 2 个内部函数（new, try_from）；被 8 处调用（does_not_expand_local_plugins_by_installed_apps, does_not_expand_local_sales_apps, does_not_reload_marketplace_per_plugin, ignores_missing_marketplace_plugin, normalizes_description, omits_installed_curated_plugins, omits_not_available_curated_plugins, returns_microsoft_fallback_plugins）；外部调用 3 个（join, to_path_buf, write_curated_plugin_sha_with）。

fn write_plugin_app(root: &Path, plugin_name: &str, app_name: &str, app_id: &str)

作用：这是测试里的文件写入帮手，用来给某个插件写一个 .app.json，声明它关联哪个应用连接器。这样测试可以模拟插件和外部应用之间的对应关系。

数据流：进去的是插件市场根目录、插件名、应用名和应用 ID → 它拼出 plugins/<插件名>/.app.json 的路径，并写入一段 JSON → 出来没有返回值，但磁盘上多了一个应用声明文件。

调用关系：涉及应用连接器匹配的测试会调用它，比如检查本地插件不会按应用自动扩展、远程和本地规则不同等；真正写文件的动作交给 write_file。

调用图：被 3 处调用（does_not_expand_local_plugins_by_installed_apps, does_not_expand_local_sales_apps, does_not_read_local_plugins_for_loaded_apps）；外部调用 3 个（join, write_file, format!）。

fn app(name: &str) -> AppDeclaration

作用：这个小帮手用一个名字快速造出一个假的应用声明，方便测试里少写重复代码。有人要测试 linear、notion 这类应用时，就用它做测试样本。

数据流：进去的是一个应用名字字符串 → 它把名字存进 AppDeclaration，并用这个名字拼出一个 connector_id，也就是连接器编号 → 出来的是一个完整的假 AppDeclaration，不会改动外部数据。

调用关系：它是测试数据工厂。几个测试在准备 apps 列表时会用它先造出应用，然后再把这些应用交给路由策略函数检查。它内部只做字符串拼接和新建编号这类简单工作。

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

fn mcp_servers(mcp_servers: impl IntoIterator<Item = (&'static str, i32)>) -> HashMap<String, i32>

作用：这个小帮手把一组“服务器名和值”的简短写法变成 HashMap，也就是按名字查值的表。这样测试里可以很快搭出假的 MCP 服务器清单。

数据流：进去的是若干个二元组，比如 “linear” 对应 1、“docs” 对应 2 → 它遍历这些项，把名字转成字符串，并收进 HashMap → 出来的是一张 MCP 服务器表，供测试函数修改和检查。

调用关系：它被三个路由策略测试调用，用来准备测试开始前的 MCP 服务器状态。准备好之后，测试会把这张表交给 apply_app_mcp_routing_policy，看策略会不会删除冲突项或保留它们。

调用图：被 3 处调用（app_mcp_routing_clears_apps_when_apps_route_is_unavailable, app_mcp_routing_preserves_apps_and_removes_conflicting_mcp_with_apps_route, app_mcp_routing_preserves_mcp_conflicts_when_plugin_is_inactive）；外部调用 1 个（into_iter）。

fn sorted_app_names(apps: &[AppDeclaration]) -> Vec<String>

作用：这个函数把应用列表里的名字拿出来并排好序，方便测试比较结果。排序是为了让测试只关心“有哪些名字”，不被列表顺序干扰。

数据流：进去的是一组 AppDeclaration 应用声明 → 它逐个读取 name 字段，复制出名字列表，然后按字母顺序排序 → 出来的是排好序的应用名列表，原来的应用列表不变。

调用关系：它在断言结果时使用，帮测试把复杂的应用对象简化成名字列表。这样 assert_eq! 比较时更直观，也更不容易因为无关字段造成干扰。

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

fn sorted_mcp_server_names(mcp_servers: &HashMap<String, i32>) -> Vec<String>

作用：这个函数把 MCP 服务器表里的所有服务器名取出来并排好序，方便测试确认最后还剩哪些服务器。

数据流：进去的是一个按名字存放的 MCP 服务器 HashMap → 它读取所有键，也就是服务器名，复制出来后排序 → 出来的是排好序的服务器名列表，不改变原来的 HashMap。

调用关系：它配合测试里的 assert_eq! 使用，把 HashMap 这种不保证顺序的表变成稳定的名字列表。这样测试能准确判断路由策略删掉了谁、保留了谁。

fn apps_route_available_tracks_auth_mode()

作用：这个测试确认“应用路由是否可用”完全跟登录方式规则一致。简单说，它检查哪些身份能用应用通道，哪些不能。

数据流：进去的是几种 AuthMode 登录方式，包括 ChatGPT、AgentIdentity、ApiKey，以及没有登录方式的情况 → 它分别调用 apps_route_available，并用 assert! 检查真假是否符合预期 → 出来没有业务数据，测试通过表示规则正确，失败就会报错。

调用关系：这是最基础的规则测试。后面的路由策略测试依赖这个前提：只有某些登录方式能走应用路由，所以这里先把“门是否打开”的判断钉住。它把具体判断交给 apps_route_available。

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

fn app_mcp_routing_clears_apps_when_apps_route_is_unavailable()

作用：这个测试确认：当应用路由不可用时，系统会清空应用列表，但不会乱删 MCP 服务器。这样可以避免把用户带到一个当前不能使用的应用入口。

数据流：开始时有一个 linear 应用，还有 linear 和 docs 两个 MCP 服务器 → 它用 ApiKey 这种不允许应用路由的登录方式调用 apply_app_mcp_routing_policy → 之后应用列表应为空，MCP 服务器仍然保留 linear 和 docs。

调用关系：它先用 app 和 mcp_servers 准备数据，然后把数据交给 apply_app_mcp_routing_policy。最后用 assert! 和 assert_eq! 检查策略结果，重点验证“应用路由关门时，只清应用，不清服务器”。

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

fn app_mcp_routing_preserves_apps_and_removes_conflicting_mcp_with_apps_route()

作用：这个测试确认：当应用路由可用且插件启用时，同名冲突要让应用优先，删掉同名 MCP 服务器。这样 linear 应用就不会被 linear MCP 服务器抢走入口。

数据流：开始时有 linear、notion 两个应用，也有 linear、docs、notion 三个 MCP 服务器 → 它用允许应用路由的 Chatgpt 登录方式，并设置插件启用，然后调用 apply_app_mcp_routing_policy → 之后应用仍保留 linear 和 notion，MCP 只剩不冲突的 docs。

调用关系：它测试的是核心冲突处理场景。mcp_servers 负责搭出初始服务器表，apply_app_mcp_routing_policy 执行真正的取舍，sorted_app_names 和 sorted_mcp_server_names 帮它把结果整理成可比较的名字列表。

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

fn app_mcp_routing_preserves_mcp_conflicts_when_plugin_is_inactive()

作用：这个测试确认：即使登录方式允许应用路由，只要插件没启用，就不要删除同名 MCP 服务器。它防止系统在插件实际不工作时过早改动服务器清单。

数据流：开始时有 linear 应用，也有 linear 和 docs 两个 MCP 服务器 → 它用允许应用路由的 Chatgpt 登录方式，但把 plugin_active 设为 false，再调用 apply_app_mcp_routing_policy → 之后应用还在，MCP 里的 linear 和 docs 也都还在。

调用关系：它覆盖了一个容易被忽略的开关条件：插件是否启用。它和前一个测试形成对照，说明不是只要登录方式允许就删除冲突 MCP，还必须插件真的处于启用状态。

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

fn write_file(path: &Path, contents: &str)

作用：这是测试里最基础的写文件助手。别人只要给它一个路径和文字内容，它就保证目录先存在，然后把文件写进去。

数据流：输入是一个文件路径和要写入的字符串。它先查看这个文件应该放在哪个父目录下，创建这些目录；然后把字符串写成文件。结果是磁盘上多了或更新了这个文件，如果目录不存在也会被一起补齐。

调用关系：它是这个测试工具箱的地基。write_curated_plugin、write_openai_curated_marketplace、write_curated_plugin_sha_with 和 write_plugins_feature_config 都把真正落盘的活交给它，这样上层函数只需要关心要写什么测试内容。

调用图：被 4 处调用（write_curated_plugin, write_curated_plugin_sha_with, write_openai_curated_marketplace, write_plugins_feature_config）；外部调用 3 个（parent, create_dir_all, write）。

fn write_curated_plugin(root: &Path, plugin_name: &str)

作用：这个函数在测试目录里造出一个假的“精选插件”。它会写出插件说明、技能文件、MCP 配置和应用连接器配置，让测试能像面对真实插件一样运行。

数据流：输入是测试根目录和插件名字。它先拼出这个插件应该所在的目录，然后依次写入 .codex-plugin/plugin.json、skills/SKILL.md、.mcp.json 和 .app.json。结果是磁盘上出现一个结构完整的测试插件目录。

调用关系：它通常不是单独写市场文件，而是被 write_openai_curated_marketplace 调用。后者先写插件市场清单，再让它为清单里的每个插件补上真实目录和文件。

调用图：调用 1 个内部函数（write_file）；被 1 处调用（write_openai_curated_marketplace）；外部调用 2 个（join, format!）。

fn write_openai_curated_marketplace(root: &Path, plugin_names: &[&str])

作用：这个函数为测试创建一个假的 OpenAI 精选插件市场。它把给定的插件名字写进市场清单，并同时把每个插件的本地文件都造出来。

数据流：输入是测试根目录和一组插件名。它把这些插件名变成 marketplace.json 里的插件列表，每个插件都指向本地 ./plugins/插件名 路径；然后写出 .agents/plugins/marketplace.json；最后逐个调用 write_curated_plugin 创建对应插件目录。结果是测试目录里同时有“市场目录”和“市场里列出的插件”。

调用关系：它是搭建完整插件市场测试场景的上层入口。它自己负责市场清单，把具体插件文件的创建交给 write_curated_plugin，而所有文件写入最终还是通过 write_file 完成。

调用图：调用 2 个内部函数（write_curated_plugin, write_file）；外部调用 2 个（join, format!）。

fn write_curated_plugin_sha(codex_home: &Path)

作用：这个函数写入测试默认使用的精选插件 SHA。SHA 可以理解成一串版本指纹，用来表示当前安装或同步到的是哪一版插件。

数据流：输入是 Codex 的测试主目录。它不自己拼内容，而是使用内置的测试 SHA 常量，再交给 write_curated_plugin_sha_with 写到指定位置。结果是临时目录中出现一个记录插件版本指纹的文件。

调用关系：它是一个省事包装函数，供测试直接使用默认指纹。调用图里它会被 verified_plugin_install_completed_requires_installed_plugin 这样的测试使用，真正写文件的工作则交给 write_curated_plugin_sha_with。

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

fn write_curated_plugin_sha_with(codex_home: &Path, sha: &str)

作用：这个函数把指定的插件 SHA 写到测试环境里。它适合测试不同版本指纹时使用，而不是只能用默认值。

数据流：输入是 Codex 的测试主目录和一段 SHA 字符串。它把 SHA 加上换行，写入 .tmp/plugins.sha。结果是磁盘上有一个版本指纹文件，后续代码可以读取它来判断插件状态。

调用关系：它是 write_curated_plugin_sha 背后的实际执行者。上层函数负责决定用哪个 SHA，它负责把这个 SHA 通过 write_file 安全地写到正确位置。

调用图：调用 1 个内部函数（write_file）；被 1 处调用（write_curated_plugin_sha）；外部调用 2 个（join, format!）。

fn write_plugins_feature_config(codex_home: &Path)

作用：这个函数给测试写一份配置文件，明确打开插件功能开关。没有这个配置，测试可能还没跑到插件逻辑，就因为功能没启用而走了别的分支。

数据流：输入是 Codex 的测试主目录。它把一段 TOML 配置写到配置文件中，内容是 [features] plugins = true。结果是后续加载配置时，系统会认为插件功能已经开启。

调用关系：它常在需要验证插件安装或插件状态的测试开始前使用，例如被 verified_plugin_install_completed_requires_installed_plugin 调用。它只负责写配置文件，实际落盘依赖 write_file。

调用图：调用 1 个内部函数（write_file）；被 1 处调用（verified_plugin_install_completed_requires_installed_plugin）；外部调用 1 个（join）。

async fn load_plugins_config(codex_home: &Path) -> crate::config::Config

作用：这个异步函数从测试目录加载一份 Codex 配置。异步的意思是它可能等待文件读取等操作完成，不一定马上返回。

数据流：输入是 Codex 的测试主目录。它创建一个默认的配置构建器，把 codex_home 和备用当前目录都设成这个测试目录，然后执行构建并等待完成。结果是一份已经加载好的 Config 配置对象；如果加载失败，测试会直接报错。

调用关系：它通常在前面那些写文件函数布置好测试环境之后使用。前面的函数负责把配置和插件材料放到磁盘上，它负责让真实配置加载流程读这些材料，从而让测试检查系统后续行为是否正确。

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

async fn list_discoverable_plugins(
    config: &crate::config::Config,
    loaded_plugin_app_connector_ids: &[String],
) -> anyhow::Result<Vec<DiscoverablePluginInfo>>

作用：这是测试里的便捷入口，用来在“没有登录凭证”的情况下列出可发现插件。测试用它少写一些重复代码。

数据流：输入是配置对象和当前已经加载的插件连接器 ID 列表；它把登录信息固定为空，然后转交给带认证参数的版本；最后返回插件发现逻辑给出的插件列表，自己不改配置也不写文件。

调用关系：几个普通测试会直接调用它，比如测试插件功能关闭、禁用推荐、配置指定推荐插件。它本身不做真正判断，只是把活儿交给 list_discoverable_plugins_with_auth。

调用图：调用 1 个内部函数（list_discoverable_plugins_with_auth）；被 3 处调用（list_tool_suggest_discoverable_plugins_includes_configured_plugin_ids, list_tool_suggest_discoverable_plugins_omits_disabled_tool_suggestions, list_tool_suggest_discoverable_plugins_returns_empty_when_plugins_feature_disabled）。

async fn list_discoverable_plugins_with_auth(
    config: &crate::config::Config,
    auth: Option<&codex_login::CodexAuth>,
    loaded_plugin_app_connector_ids: &[String],
) -> anyhow::Result<Vec<Dis

作用：这是带登录信息的测试辅助函数。它会先创建一个 PluginsManager，也就是插件系统的“办事员”，再去查询可发现插件。

数据流：输入是配置、可选的登录凭证、已加载的连接器 ID；它根据配置里的 codex_home 和产品类型创建 PluginsManager，并从登录凭证里取出 API 认证模式；然后把配置、管理器和认证信息一起交给下一层；输出是整理后的可发现插件列表。

调用关系：list_discoverable_plugins 会调用它。它负责准备 PluginsManager，然后继续调用 list_discoverable_plugins_with_manager_and_auth，让测试可以复用同一套发现流程。

调用图：调用 2 个内部函数（new_with_options, list_discoverable_plugins_with_manager_and_auth）；被 1 处调用（list_discoverable_plugins）。

async fn list_discoverable_plugins_with_manager_and_auth(
    config: &crate::config::Config,
    plugins_manager: &PluginsManager,
    auth: Option<&codex_login::CodexAuth>,
    loaded_plugin_app_con

作用：这是最贴近被测功能的包装函数。它把测试准备好的配置、插件管理器和认证信息，直接送进真正的插件推荐列表函数。

数据流：输入是配置、PluginsManager、可选登录凭证和已加载连接器 ID；它不加工数据，只调用 super::list_tool_suggest_discoverable_plugins；输出就是该真实函数返回的 DiscoverablePluginInfo 列表。

调用关系：它被 list_discoverable_plugins_with_auth 使用，也被远程插件缓存测试直接使用。这样远程测试可以先手动建立缓存，再用同一个 PluginsManager 去验证推荐结果。

调用图：被 2 处调用（list_discoverable_plugins_with_auth, list_tool_suggest_discoverable_plugins_includes_cached_remote_global_plugins）；外部调用 1 个（list_tool_suggest_discoverable_plugins）。

async fn list_tool_suggest_discoverable_plugins_includes_cached_remote_global_plugins()

作用：这个测试确认远程全局插件只有在正确缓存后，才会作为“官方精选远程插件”出现在可发现列表里，并且禁用配置能把它隐藏掉。

数据流：它先创建临时目录和配置，打开插件与远程插件功能；再启动一个假的 HTTP 服务器，模拟后端返回多个远程插件，其中有可用的 GitHub，也有不该展示的未列出、不可用或管理员禁用插件；接着用假登录凭证拉取并缓存远程插件目录。第一次查询时确认 GitHub 还不会直接出现；随后再模拟已安装插件列表为空并建立远程已安装市场缓存；第二次查询确认只出现 github@openai-curated-remote，并检查名称、描述、技能和连接器 ID 都正确；最后写入禁用配置，再确认这个远程插件被过滤掉。

调用关系：这是本文件最完整的集成式测试。它调用远程目录缓存函数 fetch_and_cache_global_remote_plugin_catalog，也调用 list_discoverable_plugins_with_manager_and_auth 去走真实发现逻辑，还用 wiremock 接住网络请求，避免测试依赖真实服务器。

调用图：调用 4 个内部函数（new, fetch_and_cache_global_remote_plugin_catalog, list_discoverable_plugins_with_manager_and_auth, create_dummy_chatgpt_auth_for_testing）；外部调用 10 个（given, start, new, assert!, assert_eq!, load_plugins_config, write_file, format!, json!, tempdir）。

async fn list_tool_suggest_discoverable_plugins_returns_empty_when_plugins_feature_disabled()

作用：这个测试确认只要插件总开关关掉，就算本地有官方精选插件清单，也不能推荐任何插件。

数据流：它创建临时 Codex 主目录，写入一个包含 slack 的官方精选插件清单，再写配置把 features.plugins 设为 false；然后加载配置并调用 list_discoverable_plugins；最后断言返回的是空列表。

调用关系：它使用 curated_plugins_repo_path 找到测试用的官方精选插件目录，用 write_openai_curated_marketplace 写假数据，再通过 list_discoverable_plugins 进入被测流程。它验证的是最外层功能开关的拦截效果。

调用图：调用 2 个内部函数（curated_plugins_repo_path, list_discoverable_plugins）；外部调用 5 个（assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, tempdir）。

async fn list_tool_suggest_discoverable_plugins_omits_disabled_tool_suggestions()

作用：这个测试确认用户在配置里明确禁用某个插件推荐后，这个插件不会再出现在推荐列表里。

数据流：它创建临时目录，放入一个 slack 官方精选插件；配置里打开插件功能，同时在 tool_suggest.disabled_tools 里写入 slack@openai-curated；加载配置后查询可发现插件；最后检查结果是空列表，说明 slack 被成功过滤。

调用关系：它通过 list_discoverable_plugins 走默认无认证路径。它和“插件功能关闭”的测试很像，但这里验证的不是总开关，而是单个工具推荐的黑名单规则。

调用图：调用 2 个内部函数（curated_plugins_repo_path, list_discoverable_plugins）；外部调用 5 个（assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, tempdir）。

async fn list_tool_suggest_discoverable_plugins_includes_configured_plugin_ids()

作用：这个测试确认配置里明确写进 discoverables 的插件，会被加入可发现列表，并且它的详细信息能正确读出来。

数据流：它创建临时目录，写入一个名为 sample 的官方精选插件清单；配置里打开插件功能，并把 sample@openai-curated 放进 tool_suggest.discoverables；加载配置后查询可发现插件；最后断言返回的插件包含正确的 ID、名称、说明、是否有技能、MCP 服务器名和应用连接器 ID。MCP 服务器可以理解成插件额外提供工具能力的本地或远程服务。

调用关系：它调用 list_discoverable_plugins 进入真实发现流程，用 assert_eq! 对完整结果做精确比较。这个测试保证配置文件里的“我要推荐这个插件”不会被忽略。

调用图：调用 2 个内部函数（curated_plugins_repo_path, list_discoverable_plugins）；外部调用 5 个（assert_eq!, load_plugins_config, write_file, write_openai_curated_marketplace, tempdir）。

fn text_input(text: &str) -> UserInput

作用：这是测试用的小帮手，用一段普通文字快速做出一个 UserInput::Text。测试里不用每次手写一大段结构体，读起来更清楚。

数据流：进去一段字符串 → 它把字符串复制成 UserInput::Text 里的 text 字段，并把 text_elements 设为空列表 → 出来一个代表“用户输入了一段文字”的测试对象。

调用关系：它服务于后面几个插件提及测试。那些测试需要模拟“用户在文字里写了链接”，就先调用 text_input 造出文本输入，再交给 collect_explicit_plugin_mentions 去识别。它内部只用到字符串创建这类基础能力。

调用图：被 4 处调用（collect_explicit_plugin_mentions_dedupes_structured_and_linked_mentions, collect_explicit_plugin_mentions_from_linked_text_mentions, collect_explicit_plugin_mentions_ignores_dollar_linked_plugin_mentions, collect_explicit_plugin_mentions_ignores_non_plugin_paths）；外部调用 1 个（new）。

fn plugin(config_name: &str, display_name: &str) -> PluginCapabilitySummary

作用：这是测试用的小帮手，用配置名和显示名快速做出一个插件摘要。这样测试可以专注看“有没有识别到正确插件”，不用每次填一堆无关字段。

数据流：进去插件的 config_name 和 display_name → 它把这两个名字放进 PluginCapabilitySummary，并给其他字段填上测试用的默认值，比如没有描述、有技能、没有服务器名和应用连接编号 → 出来一个可用于比较的插件摘要对象。

调用关系：它给插件提及相关测试准备候选插件列表和预期结果。真正被测的是 collect_explicit_plugin_mentions；plugin 只是让这些测试数据更短、更容易看懂。

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

fn collect_explicit_app_ids_from_linked_text_mentions()

作用：这个测试确认：如果用户在普通文字里写了 app://calendar 这种应用链接，系统能识别出 calendar 这个应用编号。

数据流：进去一段包含 Markdown 链接的文本输入 → 测试把它交给 collect_explicit_app_ids → 出来应该是只包含 calendar 的集合；如果不是，assert_eq! 会让测试失败。

调用关系：这是对 collect_explicit_app_ids 的基础场景检查。它模拟用户直接在文字里点名一个应用，确认收集函数能从链接里把应用编号抠出来。

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

fn collect_explicit_app_ids_dedupes_structured_and_linked_mentions()

作用：这个测试确认：同一个应用同时以文字链接和结构化 Mention 出现时，只算一次。这样后续系统不会重复处理同一个应用。

数据流：进去两个输入：一个文本里的 app://calendar 链接，一个结构化的 app://calendar Mention → collect_explicit_app_ids 收集应用编号并去重 → 出来应该仍然只有一个 calendar。

调用关系：它测试 collect_explicit_app_ids 的去重能力。场景像用户界面一边保留了结构化提及，一边文本里也带着链接；函数必须把两者合并成一个干净结果。

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

fn collect_explicit_app_ids_ignores_non_app_paths()

作用：这个测试确认：不是 app:// 开头的路径不会被当成应用。它防止系统把文档、技能或本地文件误认成应用。

数据流：进去一批非应用路径，包括 mcp://、skill:// 和普通文件路径，既有文本链接也有结构化 Mention → collect_explicit_app_ids 尝试收集应用编号 → 出来应该是空集合，表示没有发现明确应用。

调用关系：它守住 collect_explicit_app_ids 的边界。这个函数只该识别应用链接；其他类型的资源要留给别的逻辑处理，不能在这里混进来。

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

fn collect_explicit_plugin_mentions_from_structured_paths()

作用：这个测试确认：如果用户输入里已经有结构化的 plugin://sample@test Mention，系统能在已知插件列表里找到对应插件。

数据流：进去一个结构化插件 Mention 和两个候选插件摘要 → collect_explicit_plugin_mentions 按路径里的插件配置名去匹配 → 出来应该只包含 sample@test 这个插件摘要。

调用关系：它测试 collect_explicit_plugin_mentions 对结构化 Mention 的支持。结构化 Mention 像是界面提前贴好的标签，被测函数需要把这个标签转成真正可用的插件信息。

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

fn collect_explicit_plugin_mentions_from_linked_text_mentions()

作用：这个测试确认：如果用户在文字里写 @sample(plugin://sample@test)，系统能把它识别成明确提到 sample 插件。

数据流：进去一段由 text_input 造出的文本输入，以及候选插件列表 → collect_explicit_plugin_mentions 扫描文字里的 plugin:// 链接并匹配插件 → 出来应该是 sample@test 对应的插件摘要。

调用关系：它先用 text_input 模拟用户打字，再把输入交给 collect_explicit_plugin_mentions。这个场景覆盖的是“插件提及藏在普通文本链接里”的路径。

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

fn collect_explicit_plugin_mentions_dedupes_structured_and_linked_mentions()

作用：这个测试确认：同一个插件既在文字链接里出现，又在结构化 Mention 里出现时，只返回一次。这样后续不会重复启用或展示同一个插件。

数据流：进去两个指向 sample@test 的提及：一个文本链接，一个结构化 Mention，再加上候选插件列表 → collect_explicit_plugin_mentions 收集并去重 → 出来应该只有一个 sample@test 插件摘要。

调用关系：它用 text_input 造文本提及，同时手写结构化 Mention，然后一起交给 collect_explicit_plugin_mentions。它验证这个收集函数能把不同来源的同一插件合并掉。

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

fn collect_explicit_plugin_mentions_ignores_non_plugin_paths()

作用：这个测试确认：应用链接、技能链接和普通文件路径不会被当成插件。它防止插件识别逻辑太贪心，见到链接就乱匹配。

数据流：进去一段包含 app://、skill:// 和文件路径的文本输入，以及一个候选插件 → collect_explicit_plugin_mentions 扫描输入 → 出来应该是空列表，表示没有明确插件提及。

调用关系：它通过 text_input 模拟一段混杂链接的用户文字，再交给 collect_explicit_plugin_mentions。这个测试确保插件收集函数只关心 plugin:// 这类插件路径。

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

fn collect_explicit_plugin_mentions_ignores_dollar_linked_plugin_mentions()

作用：这个测试确认：即使链接地址是 plugin://sample@test，如果显示文字写成 $sample，也不算插件提及。这里的 $ 更像应用提及的写法，而插件提及要求 @ 这种写法。

数据流：进去一段文本 use $sample(plugin://sample@test) 和候选插件列表 → collect_explicit_plugin_mentions 检查链接和显示写法 → 出来应该是空列表，因为这种写法不符合插件提及规则。

调用关系：它用 text_input 造出一个容易误判的文本链接，再交给 collect_explicit_plugin_mentions。这个测试补上一个细节规则：插件不仅要有 plugin:// 路径，还要用正确的 @ 风格提及。

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

fn render_plugins_section_returns_none_for_empty_plugins()

作用：这个测试检查“没有插件”这个场景。它确保生成插件说明的函数在拿到空列表时，结果就是没有内容，而不是输出一段没必要的提示。

数据流：输入是一个空的插件列表 → 测试把它交给 render_plugins_section → 期望得到 None，也就是“没有可渲染内容” → 如果结果不是 None，测试就失败，提醒开发者这个行为被改坏了。

调用关系：它是插件说明渲染功能的边界测试，专门守住最简单也最容易被忽略的情况。它调用外部的 assert_eq! 来比较实际结果和期望结果。

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

fn render_plugins_section_keeps_plugin_usage_guidance_without_listing_plugins()

作用：这个测试检查“有插件”时生成的说明是否正确。它确认系统会输出固定的插件使用指南，但不会把具体插件逐个列出来。

数据流：输入是一个示例插件信息，里面有配置名、显示名、描述，并标记它带有技能；其他字段用默认值补齐 → 测试调用 render_plugins_section 生成文本 → 如果生成失败就直接报错 → 然后把生成文本和一整段预期说明逐字比较 → 结果必须完全一致。

调用关系：它验证插件说明文本的核心格式和内容，是防止提示词被意外改动的保护网。它用 default 填充不关心的插件字段，并用 assert_eq! 检查最终字符串是否和预期完全相同。

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

fn app(id: &str) -> AppInfo

作用：这个小工具函数用一个 id 快速造出一个默认的 AppInfo，也就是“一个应用/连接器的信息卡片”。测试里不想每次都手写一大堆字段，所以用它来省事。

数据流：进去的是一个应用 id 字符串 → 它把这个 id 同时填到应用的 id 和 name 里，其他说明、图标、安装地址等字段先留空，并默认设成“已启用但还不可访问” → 出来的是一张完整但很朴素的 AppInfo 测试数据。

调用关系：它主要服务于测试 with_app_enabled_state_preserves_unrelated_disabled_connector。那个测试需要几个应用样本来检查启用/禁用状态是否被正确保留，所以先让 app 生成基础对象，再按需要改其中的字段。

调用图：被 1 处调用（with_app_enabled_state_preserves_unrelated_disabled_connector）；外部调用 1 个（new）。

fn plugin_names(names: &[&str]) -> Vec<String>

作用：这个小工具函数把一组文本形式的插件名字转换成系统真正使用的 String 列表。它是测试数据的“格式转换器”。

数据流：进去的是字符串切片，比如 ["beta", "sample"] → 它逐个复制成拥有所有权的字符串 → 出来的是 Vec<String>，可以直接塞进 ToolInfo 或 AppInfo 的 plugin_display_names 字段。

调用关系：它被 codex_app_tool 调用。codex_app_tool 在制造假的 Codex 应用工具时，需要同时填好插件显示名，所以把这一步交给 plugin_names。

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

fn test_tool_definition(tool_name: &str) -> Tool

作用：这个函数造一个最简单的假工具定义。测试只关心工具叫什么，不关心工具真正的参数结构，所以这里用空的 JSON 对象当占位。

数据流：进去的是工具名 → 它创建一个空的 JsonObject，也就是空的 JSON 参数说明，再用这个名字和空参数说明构造 Tool → 出来的是一个可以放进 ToolInfo 的 Tool 测试对象。

调用关系：它被 codex_app_tool 调用。codex_app_tool 负责拼出完整的假工具信息，而真正的 Tool 字段由 test_tool_definition 来填。

调用图：被 1 处调用（codex_app_tool）；外部调用 3 个（new, default, new_with_raw）。

fn codex_app_tool(
    tool_name: &str,
    connector_id: &str,
    connector_name: Option<&str>,
    plugin_display_names: &[&str],
) -> ToolInfo

作用：这个函数专门造一个“来自 Codex Apps MCP 服务器的工具”。MCP 可以简单理解成让模型调用外部工具的一套接口，这里用假数据模拟真实连接器暴露出来的工具。

数据流：进去的是工具名、连接器 id、可选的连接器名称、插件显示名列表 → 它先根据连接器名称生成工具命名空间，没有名称时就用默认服务器名；再创建 ToolInfo，把连接器 id、连接器名称、插件显示名和假 Tool 都填进去 → 出来的是一条完整的 ToolInfo 测试数据。

调用关系：多个测试用它快速准备输入数据，尤其是检查 accessible_connectors_from_mcp_tools 和缓存刷新时。它内部把插件名转换交给 plugin_names，把工具定义创建交给 test_tool_definition。

调用图：调用 2 个内部函数（plugin_names, test_tool_definition）。

fn with_accessible_connectors_cache_cleared(f: impl FnOnce() -> R) -> R

作用：这个函数临时清空“可访问连接器”的全局缓存，跑完一段测试代码后再把原缓存放回去。这样测试不会被之前的缓存结果污染。

数据流：进去的是一段要执行的函数 f → 它先拿到缓存锁，保存旧缓存并清空；然后执行 f；最后再次拿锁，把旧缓存恢复 → 出来的是 f 的返回值，同时全局缓存回到测试前的状态。

调用关系：它被 refresh_accessible_connectors_cache_from_mcp_tools_writes_latest_installed_apps 使用。那个测试要确认刷新缓存真的写入了最新应用，如果不先清空缓存，旧数据可能让测试结果不可靠。

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

fn accessible_connectors_from_mcp_tools_carries_plugin_display_names()

作用：这个测试确认：从 MCP 工具列表整理出连接器列表时，插件显示名会被正确带到应用信息里，并且重复名字会被整理掉。

数据流：进去的是测试里手工创建的三条工具信息：两条属于 calendar 连接器，一条普通 sample 工具不属于连接器 → 被测逻辑会只挑出真正有 connector_id 的 Codex Apps 工具，合并成一个 calendar 应用，并使用更完整的连接器名称和插件显示名 → 最后用断言检查输出是否正好是一条 Google Calendar 应用信息。

调用关系：这是对 accessible_connectors_from_mcp_tools 这条整理流程的直接检查。它通过 codex_app_tool 准备输入，并用 assert_eq! 比较实际结果和期望结果。

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

async fn refresh_accessible_connectors_cache_from_mcp_tools_writes_latest_installed_apps()

作用：这个测试确认：系统从当前 MCP 工具刷新“可访问连接器缓存”时，缓存里会写入最新安装或可访问的应用列表。

数据流：进去的是一个临时的 Codex 主目录、一份开启 Apps 功能的配置、以及两条假的 Codex Apps 工具 → 测试先算出缓存键，再清空全局缓存，调用刷新函数写缓存，随后读取缓存内容 → 出来的是缓存里的 AppInfo 列表，测试要求它包含 calendar 和 hidden 两个连接器，并且字段都正确。

调用关系：它把缓存相关流程串起来测：先用 ConfigBuilder 建配置，再用 with_accessible_connectors_cache_cleared 隔离缓存，接着调用 refresh_accessible_connectors_cache_from_mcp_tools，最后用 read_cached_accessible_connectors 验证结果。

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

fn accessible_connectors_from_mcp_tools_preserves_description()

作用：这个测试确认：工具命名空间上的说明文字不会在转换成应用信息时丢掉。比如“Plan events”这样的描述应该显示在日历应用上。

数据流：进去的是一条带 namespace_description 的 calendar 工具信息 → 被测逻辑把它整理成可访问连接器 AppInfo → 出来的一条 AppInfo 必须保留 description 字段，同时安装地址、名称、可访问状态也要符合预期。

调用关系：它直接检查 accessible_connectors_from_mcp_tools 的字段保留行为。前面的插件名测试关注 plugin_display_names，这个测试补上 description 这个容易被漏掉的字段。

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

async fn app_approvals_reviewer_uses_app_then_default_then_global()

作用：这个测试确认应用审批人的选择顺序是对的：先看具体应用配置，再看 apps._default 默认配置，最后才看全局配置。审批人可以理解成“工具调用前由谁来把关”。

数据流：进去的是临时写出的配置文件，里面同时设置全局 approvals_reviewer、应用默认 approvals_reviewer、calendar 单独 approvals_reviewer → ConfigBuilder 读取配置后，测试分别询问 calendar、drive、没有连接器 id、以及非 Codex Apps 服务器的审批人 → 出来的结果必须符合“应用优先、默认其次、全局兜底”的规则。

调用关系：它围绕 mcp_approvals_reviewer 展开。测试通过写配置文件制造不同层级的规则，再用 assert_eq! 检查该函数在不同服务器名和连接器 id 下选出的值。

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

async fn default_app_approvals_reviewer_respects_global_reviewer_requirements()

作用：这个测试确认：即使 apps._default 里写了某种审批人，如果企业规则不允许，系统也不能采用它。企业规则在这里是更高层级的安全限制。

数据流：进去的是本地配置：全局是 auto_review，应用默认是 user；同时云端企业要求只允许 auto_review → 构建配置时会把本地配置和企业要求合并 → 出来的 mcp_approvals_reviewer 结果必须是 AutoReview，而不是本地默认写的 User。

调用关系：它测试 mcp_approvals_reviewer 和配置加载流程的配合。企业限制由 CloudConfigBundleFixture::loader_with_enterprise_requirement 提供，ConfigBuilder 负责加载，最后断言审批结果被企业规则纠正。

调用图：调用 1 个内部函数（loader_with_enterprise_requirement）；外部调用 4 个（assert_eq!, default, write, tempdir）。

async fn app_approvals_reviewer_respects_global_reviewer_requirements()

作用：这个测试和上一个类似，但它检查的是“某个具体应用”的审批配置也必须服从企业限制。也就是说，单个应用不能绕过全局安全要求。

数据流：进去的是本地配置：全局 auto_review，calendar 单独写 user；同时企业要求只允许 auto_review → 配置构建后，被测函数查询 calendar 的审批人 → 出来的结果必须仍然是 AutoReview。

调用关系：它继续验证 mcp_approvals_reviewer 在企业约束下的行为。CloudConfigBundleFixture 提供企业要求，ConfigBuilder 合并配置，测试用 assert_eq! 确认具体应用配置不会突破限制。

调用图：调用 1 个内部函数（loader_with_enterprise_requirement）；外部调用 4 个（assert_eq!, default, write, tempdir）。

async fn with_app_enabled_state_preserves_unrelated_disabled_connector()

作用：这个测试确认：给应用列表套用启用/禁用状态时，不会误伤别的已经禁用的连接器。简单说，改 drive 的配置时，不应该把 slack 的禁用状态弄丢。

数据流：进去的是临时配置和一份要求：connector_drive 被配置成 disabled；测试又准备了一个本来就 disabled 的 connector_slack，以及一个默认状态的 connector_drive → 被测函数 with_app_enabled_state 根据配置修正列表 → 出来的列表里 slack 仍然是 disabled，drive 也被设成 disabled。

调用关系：它用 app 函数快速生成 AppInfo，再手动设置状态。配置要求通过 ConfigLayerStack 和 ConfigRequirementsToml 放进 config，最后调用 with_app_enabled_state 并比较结果。

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

async fn tool_suggest_connector_ids_include_configured_tool_suggest_discoverables()

作用：这个测试确认：配置文件里写进 tool_suggest.discoverables 的连接器 id，会被工具推荐系统识别出来。空白 id 和非连接器类型不会混进去。

数据流：进去的是一份临时配置，里面有一个 connector、一个 plugin、一个只有空格的 connector → ConfigBuilder 读取配置后，tool_suggest_connector_ids 提取可推荐的连接器 id → 出来的集合只包含那个有效的 connector id。

调用关系：它直接检查 tool_suggest_connector_ids 的过滤规则。测试通过写配置制造混合输入，再用 assert_eq! 确认只留下有效连接器。

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

async fn tool_suggest_connector_ids_exclude_disabled_tool_suggestions()

作用：这个测试确认：如果某个推荐连接器同时出现在 disabled_tools 里，它就不能再被推荐。也就是“黑名单”会覆盖“可发现列表”。

数据流：进去的是配置：calendar 和 gmail 都在 discoverables 里，但 calendar 又在 disabled_tools 里 → 被测函数读取后先找出可推荐项，再排除被禁用项 → 出来的集合只剩 connector_gmail。

调用关系：它验证 tool_suggest_connector_ids 在推荐和禁用两张列表同时存在时的优先级。测试用临时配置文件提供输入，用断言检查过滤后的集合。

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

async fn tool_suggest_uses_connector_id_fallback_when_directory_cache_is_empty()

作用：这个测试确认：当连接器目录缓存是空的，但配置里已经写了连接器 id，工具推荐仍然能显示一个基于 id 生成的应用信息。这样推荐功能不会因为目录缓存缺失就完全没内容。

数据流：进去的是开启 Apps 功能的配置、一个 tool_suggest 连接器 id、假的 ChatGPT 登录信息、空的已知工具和空的已加载插件应用列表 → 被测异步函数尝试列出可推荐工具，目录缓存为空时用 connector id 兜底生成 AppInfo → 出来的是一个 DiscoverableTool，内容来自 plugin_connector_to_app_info 生成的 gmail 连接器信息。

调用关系：它测试 list_tool_suggest_discoverable_tools_with_auth 的兜底路径。PluginsManager 提供插件目录环境，CodexAuth 提供假登录身份，最终结果和 plugin_connector_to_app_info 生成的期望对象比较。

调用图：调用 2 个内部函数（new, create_dummy_chatgpt_auth_for_testing）；外部调用 4 个（assert_eq!, default, write, tempdir）。

async fn tool_suggest_includes_connectors_from_loaded_plugin_apps()

作用：这个测试确认：已经加载进来的插件应用连接器，也会进入工具推荐列表。也就是说，不只配置文件里的 discoverables 能被推荐，运行时已加载的插件应用也能被看见。

数据流：进去的是开启 Apps 功能的配置、假的登录信息、一个 loaded_plugin_app_connector_ids 列表，其中包含 databricks workspace 的连接器 id → 被测函数把这个已加载连接器转成可推荐工具 → 出来的是包含该连接器的 DiscoverableTool 列表。

调用关系：它覆盖 list_tool_suggest_discoverable_tools_with_auth 的另一条输入来源：已加载插件应用。PluginsManager 和假 auth 搭好环境，loaded_plugin_app_connector_ids 提供运行时数据，最后用 assert_eq! 验证输出。

调用图：调用 2 个内部函数（new, create_dummy_chatgpt_auth_for_testing）；外部调用 5 个（assert_eq!, default, write, tempdir, vec!）。

fn build_request_plugin_install_elicitation_request_uses_expected_shape()

作用：这个测试确认：当系统建议用户安装一个连接器时，生成出来的“请用户确认安装”的表单请求长得完全符合预期。这里的连接器可以理解成连接外部服务的入口，比如 Google Calendar。

数据流：进去的是一份假的安装参数、一份假的 Google Calendar 连接器信息、线程编号和回合编号 → 测试调用生成请求的函数，把这些信息拼成一份用户确认表单 → 出来的是一个请求对象，测试用 assert_eq! 把它和手写的标准对象比较，确保消息、工具名、安装地址、元数据等都没错。

调用关系：这个函数由 Rust 的测试运行器在跑测试时调用。它自己先准备测试材料，再检查生成请求的函数是否把连接器信息正确塞进 McpServerElicitationRequestParams 里；最后把结果交给 assert_eq! 做严格比对。

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

fn build_request_plugin_install_elicitation_request_injects_plugin_metadata()

作用：这个测试确认：当要安装的是插件而不是普通连接器时，请求里会带上插件特有的信息。比如远程插件编号，以及这个插件关联了哪些应用连接器。

数据流：进去的是一份假的插件安装参数和插件信息，里面包含插件名、远程插件 ID、MCP 服务器名和关联连接器 ID → 测试调用生成安装确认请求的函数 → 出来的是一份表单请求，测试检查它的元数据里不仅有通用字段，也正确包含 remote_plugin_id 和 app_connector_ids。

调用关系：这个函数同样由测试运行器调用。它覆盖的是插件路径，和连接器测试互补；测试中会构造 DiscoverableTool::Plugin，然后用 assert_eq! 验证生成函数没有漏掉插件专属字段。

调用图：外部调用 4 个（new, assert_eq!, Plugin, vec!）。

fn build_request_plugin_install_meta_uses_expected_shape()

作用：这个测试专门检查安装请求里的“元数据”长什么样。元数据就是藏在请求里的说明卡片，告诉接收方这是哪种批准、要安装什么、原因是什么。

数据流：进去的是连接器类型、安装动作、推荐理由，以及一份假的 Gmail 连接器信息 → 测试调用 build_request_plugin_install_meta 生成元数据 → 出来的是 RequestPluginInstallMeta，测试把它和标准答案比较，确认工具 ID、工具名、安装链接、持久化标记等字段都正确。

调用关系：这个测试比完整请求测试更聚焦，只盯住 build_request_plugin_install_meta 的输出。完整请求构建通常也会依赖这类元数据，所以这里相当于单独检查机器里的一个关键小零件。

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

fn verified_connector_install_completed_requires_accessible_connector()

作用：这个测试确认：只有当某个连接器真的出现在“可访问”的连接器列表里时，系统才认为安装完成。不能只因为名字被提到过，就误判为已经装好了。

数据流：进去的是一个只包含 calendar 的可访问连接器列表 → 测试分别询问 calendar 和 gmail 是否安装完成 → 对 calendar 期望得到 true，对 gmail 期望得到 false，确保函数按连接器 ID 查找，并且不会把不存在的连接器当成成功。

调用关系：这个函数由测试运行器调用，检查 verified_connector_install_completed 的判断规则。它用 assert! 验证两个场景：一个应该通过，一个应该失败，防止安装状态检查过于宽松。

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

fn all_requested_connectors_picked_up_requires_every_expected_connector()

作用：这个测试确认：如果一次请求里要求多个连接器，那么必须每一个都已经可访问，系统才算全部准备好。少一个都不能算完成。

数据流：进去的是一个可访问连接器列表，里面只有 calendar → 测试先要求只有 calendar，结果应该成功；再要求 calendar 加 gmail，结果应该失败 → 出来的是两个布尔判断，用来证明函数会逐个核对所有被请求的连接器。

调用关系：这个测试检查 all_requested_connectors_picked_up 的整体完成判断。它和单个连接器的测试配合：前者看“一批是否都到齐”，后者看“某一个是否到位”。

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

fn make_skill(name: &str, path: &str) -> SkillMetadata

作用：造一个测试用的技能资料。测试不想每次都手写一大堆字段，所以用它快速做出一个名字和路径都可控的假技能。

数据流：进去的是技能名和一个路径字符串；它把名字变成描述文字，把路径转成测试用的绝对路径，并填好其他默认字段；出来的是一个完整的 SkillMetadata，也就是一份技能档案。

调用关系：很多选择技能的测试都会先调用它准备样本数据。它内部借助 test_path_buf 造测试路径，也用 format! 拼出描述文字，然后把结果交给 collect_mentions 相关测试使用。

调用图：被 13 处调用（collect_explicit_skill_mentions_allows_explicit_path_with_connector_conflict, collect_explicit_skill_mentions_dedupes_by_path, collect_explicit_skill_mentions_prefers_linked_path_over_name, collect_explicit_skill_mentions_prefers_resource_path, collect_explicit_skill_mentions_prioritizes_structured_inputs, collect_explicit_skill_mentions_skips_ambiguous_name, collect_explicit_skill_mentions_skips_disabled_structured_and_blocks_plain_fallback, collect_explicit_skill_mentions_skips_invalid_structured_and_blocks_plain_fallback, collect_explicit_skill_mentions_skips_missing_path_with_no_fallback, collect_explicit_skill_mentions_skips_missing_path_without_fallback (+3 more)）；外部调用 2 个（test_path_buf, format!）。

fn set(items: &'a [&'a str]) -> HashSet<&'a str>

作用：把一串字符串变成集合，方便比较“有哪些名字”而不关心顺序。集合可以理解成一个不重复的名单。

数据流：进去的是字符串数组；它逐个取出里面的字符串引用并收进 HashSet；出来的是一个去重后的集合。

调用关系：它主要服务于 assert_mentions。assert_mentions 要比较解析结果和期望结果时，用它把期望名单变成集合，避免因为顺序不同导致测试误报。

fn assert_mentions(text: &str, expected_names: &[&str], expected_paths: &[&str])

作用：检查一段文字里解析出来的技能名和路径，是否正好等于测试预期。它是多个解析测试共用的断言小工具。

数据流：进去的是待解析文字、期望的技能名列表、期望的路径列表；它调用 extract_tool_mentions 从文字中抽取结果，再把结果和期望集合比较；如果不一致，测试就失败。

调用关系：多条 extract_tool_mentions 开头的测试都会把具体例子交给它。它把重复的“解析再比较”步骤集中起来，让每个测试只关心场景本身。

调用图：被 6 处调用（extract_tool_mentions_handles_plain_and_linked_mentions, extract_tool_mentions_keeps_plugin_skill_namespaces, extract_tool_mentions_requires_link_syntax, extract_tool_mentions_skips_common_env_vars, extract_tool_mentions_stops_at_non_name_chars, extract_tool_mentions_trims_linked_paths_and_allows_spacing）；外部调用 1 个（assert_eq!）。

fn linked_skill_mention(name: &str, unix_path: &str) -> String

作用：生成一种带路径的技能提法，比如 [$alpha](/tmp/alpha)。这种写法比只写名字更明确，因为它直接指出技能文件在哪里。

数据流：进去的是技能名和 Unix 风格路径；它把路径变成测试路径显示形式，再拼成 Markdown 链接字符串；出来的是一段可放进用户输入里的技能链接文字。

调用关系：需要测试“按路径选技能”的场景会用它造输入文本。它配合 make_skill 产生的假技能，让 collect_mentions 能验证链接路径优先、去重、缺失路径等规则。

调用图：被 1 处调用（collect_explicit_skill_mentions_dedupes_by_path）；外部调用 1 个（format!）。

fn collect_mentions(
    inputs: &[UserInput],
    skills: &[SkillMetadata],
    disabled_paths: &HashSet<AbsolutePathBuf>,
    connector_slug_counts: &HashMap<String, usize>,
) -> Vec<SkillMetadata>

作用：给真正的 collect_explicit_skill_mentions 包一层短名字，方便测试调用。它代表“从用户输入里收集被明确点名的技能”这个动作。

数据流：进去的是用户输入列表、可用技能列表、被禁用的路径集合、连接器名字计数；它直接转交给 collect_explicit_skill_mentions；出来的是系统最终认为应该选中的技能列表。

调用关系：后半部分几乎所有 collect_explicit_skill_mentions 开头的测试都会调用它。它本身不改变逻辑，只是让测试代码更短，把重点留给不同输入场景。

调用图：被 13 处调用（collect_explicit_skill_mentions_allows_explicit_path_with_connector_conflict, collect_explicit_skill_mentions_dedupes_by_path, collect_explicit_skill_mentions_prefers_linked_path_over_name, collect_explicit_skill_mentions_prefers_resource_path, collect_explicit_skill_mentions_prioritizes_structured_inputs, collect_explicit_skill_mentions_skips_ambiguous_name, collect_explicit_skill_mentions_skips_disabled_structured_and_blocks_plain_fallback, collect_explicit_skill_mentions_skips_invalid_structured_and_blocks_plain_fallback, collect_explicit_skill_mentions_skips_missing_path_with_no_fallback, collect_explicit_skill_mentions_skips_missing_path_without_fallback (+3 more)）。

fn text_mentions_skill_requires_exact_boundary()

作用：确认 $技能名 必须在名字边界上刚好匹配，不能把更长的相似词误认为目标技能。

数据流：没有外部输入；它准备几段文字，分别包含正确提法和近似但不该匹配的提法；最后用断言确认 text_mentions_skill 返回 true 或 false 符合预期。

调用关系：这是直接测试 text_mentions_skill 的基础规则。测试运行器执行它，用来守住“不要把 $notion-research-docs 误认成 $notion-research-doc”这类边界。

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

fn text_mentions_skill_handles_end_boundary_and_near_misses()

作用：检查技能名出现在文本末尾时也能识别，同时相邻多了字母的近似写法不能误识别。

数据流：它构造三种文字：刚好在末尾、名字后面多字母、后面又出现一次正确名字；调用 text_mentions_skill 后比较结果；输出只体现在测试是否通过。

调用关系：它补充上一条边界测试，覆盖“文本结尾”和“先有误导再有正确提法”的情况，帮助保证扫描逻辑不会太早或太松。

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

fn text_mentions_skill_handles_many_dollars_without_looping()

作用：确认遇到一长串 $ 符号时，查找逻辑不会卡住或陷入死循环。这里测试的是健壮性，也就是坏输入下也要稳。

数据流：它先生成 256 个 $ 加上一段无关文字；把这段文字交给 text_mentions_skill；期望结果是 false，并且测试能正常结束。

调用关系：测试运行器执行它时，会间接验证 text_mentions_skill 的扫描方式安全。它用 format! 造字符串，用断言确认没有误匹配。

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

fn extract_tool_mentions_handles_plain_and_linked_mentions()

作用：确认解析器既能认普通 $alpha，也能认带路径的 [$beta](/tmp/beta)。

数据流：它给出一段同时包含普通提法和链接提法的文字；assert_mentions 会解析出名字 alpha、beta，以及路径 /tmp/beta；如果少了或多了就失败。

调用关系：它通过 assert_mentions 间接测试 extract_tool_mentions，是解析功能最基本的混合场景。

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

fn extract_tool_mentions_skips_common_env_vars()

作用：确认 $PATH、$HOME、$XDG_CONFIG_HOME 这类常见环境变量不会被当成技能名。环境变量就是操作系统里常用的配置名字。

数据流：它准备几段含环境变量和真实技能名的文字；assert_mentions 负责解析并比较；结果应该只保留 alpha 或 beta 这种技能名，忽略环境变量。

调用关系：它通过 assert_mentions 检查 extract_tool_mentions 的过滤规则，避免用户提到系统变量时误触发技能。

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

fn extract_tool_mentions_requires_link_syntax()

作用：确认只有真正符合链接格式的写法才会产生路径。名字可以被识别，但路径不能从松散文字里乱猜。

数据流：它分别提供没有 $ 的链接、括号分开的伪链接、空路径链接；assert_mentions 检查名字和路径结果；路径只有格式完整且有效时才应出现。

调用关系：它通过 assert_mentions 约束 extract_tool_mentions 的链接识别边界，防止解析器过度聪明，把普通括号内容当路径。

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

fn extract_tool_mentions_trims_linked_paths_and_allows_spacing()

作用：确认链接里的路径前后有空格、链接名和括号之间有空格时，系统仍能读懂。

数据流：它输入 [$beta] ( /tmp/beta ) 这种带多余空格的文字；assert_mentions 解析后应得到名字 beta 和修剪干净的路径 /tmp/beta。

调用关系：它通过 assert_mentions 测试 extract_tool_mentions 的容错性，让用户写得不那么规整时也能被正确识别。

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

fn extract_tool_mentions_stops_at_non_name_chars()

作用：确认技能名遇到不属于名字的字符时会停下来，同时允许下划线这种合法字符。

数据流：它输入 $alpha.skill 和 $beta_extra；解析后应得到 alpha 和 beta_extra；点号后面的 skill 不会被并进 alpha。

调用关系：它通过 assert_mentions 检查 extract_tool_mentions 的名字切分规则，避免把标点后面的普通文字误吞进技能名。

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

fn extract_tool_mentions_keeps_plugin_skill_namespaces()

作用：确认带插件命名空间的技能名可以保留，比如 $slack:search。这里的命名空间就是用冒号说明这个技能属于哪个插件。

数据流：它输入同时含 $slack:search 和 $alpha 的文字；assert_mentions 检查解析结果包含 slack:search 和 alpha；没有路径输出。

调用关系：它通过 assert_mentions 保护插件技能的名字格式，确保 extract_tool_mentions 不会把冒号错误当成结束符。

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

fn collect_explicit_skill_mentions_text_respects_skill_order()

作用：确认从纯文字里找到多个技能时，最终结果按已有技能列表的顺序来，而不是按文字里出现的先后。

数据流：它造出 beta、alpha 两个技能，技能列表顺序是 beta 在前；输入文字先提 alpha 再提 beta；collect_mentions 返回后，断言结果仍是 beta、alpha。

调用关系：测试运行器执行它。它使用 make_skill 准备技能，调用 collect_mentions 触发真实选择逻辑，最后用断言守住旧有排序规则。

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

fn collect_explicit_skill_mentions_prioritizes_structured_inputs()

作用：确认结构化输入优先于普通文字。结构化输入就是系统已经明确给出技能名和路径的输入，比用户自由文本更可靠。

数据流：它准备文字里提到 alpha，同时另一个 UserInput::Skill 明确指定 beta；collect_mentions 应先选 beta，再补上 alpha；断言检查这个顺序。

调用关系：它用 make_skill 造样本，用 collect_mentions 调用选择逻辑，验证当文本提法和结构化提法同时存在时，结构化信息排在前面。

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

fn collect_explicit_skill_mentions_skips_invalid_structured_and_blocks_plain_fallback()

作用：确认结构化输入如果指定了错误路径，系统不会回头用同一段普通文字去凑合匹配。这样可以避免明明给错了精确信息却被系统猜成另一个结果。

数据流：它造一个真实路径为 /tmp/alpha 的技能；文本提到 alpha，但结构化输入给的是 /tmp/missing；collect_mentions 返回空列表；测试确认没有 fallback，也就是没有退回普通名字匹配。

调用关系：它调用 make_skill 和 collect_mentions，专门守住“精确信息无效时不要乱猜”的安全规则。

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

fn collect_explicit_skill_mentions_skips_disabled_structured_and_blocks_plain_fallback()

作用：确认结构化输入指向的技能如果已被禁用，也不会再通过普通文字把它选回来。

数据流：它准备 alpha 技能和同一路径的禁用集合；输入里既有文字提名，也有结构化技能；collect_mentions 应返回空；断言确认禁用状态生效。

调用关系：它使用 test_path_buf 生成禁用路径，调用 collect_mentions 测试禁用规则，保证被关掉的技能不会绕路被启用。

调用图：调用 2 个内部函数（collect_mentions, make_skill）；外部调用 5 个（new, from, assert_eq!, test_path_buf, vec!）。

fn collect_explicit_skill_mentions_dedupes_by_path()

作用：确认同一个路径的技能被提到多次时，只选一次。路径就像身份证，同一个身份证不能重复登记。

数据流：它造一个 alpha 技能，再把同一个链接提法放进文字两次；collect_mentions 最终只返回一个 alpha；断言检查没有重复项。

调用关系：它通过 linked_skill_mention 造链接输入，通过 make_skill 造技能，再交给 collect_mentions 验证按路径去重。

调用图：调用 3 个内部函数（collect_mentions, linked_skill_mention, make_skill）；外部调用 4 个（new, new, assert_eq!, vec!）。

fn collect_explicit_skill_mentions_skips_ambiguous_name()

作用：确认如果两个技能名字相同，只靠 $demo-skill 这种普通名字提法不会选任何一个。因为系统不知道用户到底指哪一个。

数据流：它造两个同名但路径不同的技能；文字两次提到同一个名字；collect_mentions 返回空列表；断言确认系统没有随便挑一个。

调用关系：它用 make_skill 制造“重名”局面，再调用 collect_mentions，保护选择逻辑在信息不够时保持保守。

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

fn collect_explicit_skill_mentions_prefers_linked_path_over_name()

作用：确认当普通名字有歧义，但链接里给了明确路径时，系统按路径选对应技能。

数据流：它造两个同名技能 alpha 路径和 beta 路径；文字既有 $demo-skill，又有指向 /tmp/beta 的链接；collect_mentions 应只返回 beta。

调用关系：它结合 make_skill、linked_skill_mention 和 collect_mentions，验证“明确路径比模糊名字更可信”的规则。

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

fn collect_explicit_skill_mentions_skips_plain_name_when_connector_matches()

作用：确认如果某个普通名字也可能是连接器名字，系统不会把 $alpha-skill 当成本地技能。连接器可以理解成外部服务入口，和技能名可能撞名。

数据流：它造一个 alpha 技能，同时设置 connector_counts 里也有 alpha-skill；输入只写普通 $alpha-skill；collect_mentions 返回空；说明名字冲突时不按技能处理。

调用关系：它调用 collect_mentions 检查连接器冲突规则，避免系统在“这是技能还是连接器”不清楚时误选技能。

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

fn collect_explicit_skill_mentions_allows_explicit_path_with_connector_conflict()

作用：确认即使名字和连接器冲突，只要用户给了明确路径，系统仍然可以选中对应技能。

数据流：它造 alpha 技能，并设置同名连接器计数；输入使用带 /tmp/alpha 路径的链接；collect_mentions 返回 alpha；断言确认明确路径能消除歧义。

调用关系：它和上一条测试成对出现：上一条禁止模糊名字，这一条允许明确路径。它用 make_skill 和 collect_mentions 验证路径优先级。

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

fn collect_explicit_skill_mentions_skips_when_linked_path_disabled()

作用：确认链接路径如果指向被禁用的技能，系统不会选择它。

数据流：它造两个同名技能，输入链接指向 /tmp/alpha，同时把 /tmp/alpha 放进禁用集合；collect_mentions 返回空列表；断言确认禁用路径被跳过。

调用关系：它使用 make_skill、test_path_buf 和 collect_mentions，测试“明确但被禁用”的情况，确保禁用规则高于路径明确性。

调用图：调用 2 个内部函数（collect_mentions, make_skill）；外部调用 5 个（new, from, assert_eq!, test_path_buf, vec!）。

fn collect_explicit_skill_mentions_prefers_resource_path()

作用：确认链接里给出的资源路径会直接决定选哪个技能，即使有同名技能存在。

数据流：它造两个同名技能，链接指向 /tmp/beta；collect_mentions 应返回 beta；断言确认没有被名字相同的 alpha 干扰。

调用关系：它通过 linked_skill_mention 造带路径提法，再调用 collect_mentions，进一步固定“路径是更强证据”的行为。

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

fn collect_explicit_skill_mentions_skips_missing_path_with_no_fallback()

作用：确认链接路径不存在时，哪怕有多个同名技能，也不会退回按名字匹配。

数据流：它造两个同名技能，但输入链接指向 /tmp/missing；collect_mentions 找不到对应路径后返回空；断言确认没有 fallback。

调用关系：它调用 make_skill 和 collect_mentions，测试缺失路径加重名的危险场景，防止系统猜错目标。

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

fn collect_explicit_skill_mentions_skips_missing_path_without_fallback()

作用：确认即使只有一个同名技能，链接路径不存在时也不会退回按名字选它。

数据流：它造一个 demo-skill，输入链接却指向 /tmp/missing；collect_mentions 返回空列表；断言确认路径错误就算失败，不再凭名字补救。

调用关系：它是缺失路径规则的单技能版本。测试运行器执行它，collect_mentions 负责跑真实逻辑，断言保证系统不做过度猜测。

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

fn test_skill_metadata(skill_doc_path: AbsolutePathBuf) -> SkillMetadata

作用：这个函数造出一份假的技能信息，供测试使用。这样每个测试不用重复写同一堆字段，也不用真的准备一个完整技能。

数据流：进去的是一个技能文档路径，也就是假的 SKILL.md 在哪里。函数把这个路径塞进一份 SkillMetadata，再填上固定的名字、描述、范围等测试用信息。出来的是一份可以被识别逻辑使用的假技能资料，不会改动外部状态。

调用关系：它是多个测试的准备工具。读文档识别测试和跑脚本识别测试都会先调用它，造出名叫 test-skill 的技能，然后把这份技能放进 SkillLoadOutcome，让被测函数有东西可以匹配。

调用图：被 4 处调用（skill_doc_read_detection_matches_absolute_path, skill_doc_read_detection_matches_shared_read_parser, skill_script_run_detection_matches_absolute_path_from_any_workdir, skill_script_run_detection_matches_relative_path_from_skill_root）。

fn test_path_display(unix_path: &str) -> String

作用：这个函数把测试用的 Unix 风格路径转成当前测试环境里显示出来的路径字符串。它让测试在不同操作系统上更稳，尤其是路径分隔符可能不一样时。

数据流：进去的是一个像 /tmp/skill-test/SKILL.md 这样的路径文本。函数先用 test_path_buf 把它变成测试用路径对象，再调用显示格式，把它转回字符串。出来的是适合放进命令参数里的路径字符串。

调用关系：它服务于需要把路径放进命令 tokens 的测试。比如测试 cat 某个文件 或 python3 某个脚本 时，测试会用它生成参数文本；它内部把路径转换工作交给 test_path_buf。

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

fn script_run_detection_matches_runner_plus_extension()

作用：这个测试确认：当命令看起来像“用脚本运行器运行一个脚本文件”时，系统能识别出来。例子是 python3 -u scripts/fetch_comments.py。

数据流：进去的是测试自己构造的一组命令片段：运行器 python3、参数 -u、脚本路径 scripts/fetch_comments.py。测试把这些交给 script_run_token，看它能不能找到脚本运行的关键片段。出来的结果应该是“找到了”，测试用断言确认这一点。

调用关系：这是对 script_run_token 的直接检查。它不搭建完整技能资料，只关心最基础的一步：命令里是否存在像脚本执行的东西；最后通过 assert_eq! 判断结果是否符合预期。

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

fn script_run_detection_excludes_python_c()

作用：这个测试确认：python3 -c print(1) 这种直接执行一小段代码的命令，不应该被误判成运行脚本文件。

数据流：进去的是一组命令片段：python3、-c、print(1)。测试把它交给 script_run_token，让它判断有没有脚本文件被运行。出来的结果应该是“没有找到”，因为这里没有 .py 脚本路径，只有一段内联代码。

调用关系：它也是直接测试 script_run_token，但检查的是反例。前一个测试证明该识别的要识别，这个测试证明不该识别的不能乱识别。

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

fn skill_doc_read_detection_matches_absolute_path()

作用：这个测试确认：如果用户用绝对路径读取某个 SKILL.md，系统能认出这是在读对应技能的说明文档。

数据流：测试先造出 /tmp/skill-test/SKILL.md 这个技能文档路径，并把它规范化，也就是转成统一可比较的路径形式。然后用 test_skill_metadata 造一份假技能，把它按文档路径放进 SkillLoadOutcome。接着构造命令片段，像 cat /tmp/skill-test/SKILL.md | head。这些信息交给 detect_skill_doc_read 后，预期出来的是这个假技能，名字是 test-skill。

调用关系：它测试的是完整的“读技能文档识别”流程。准备阶段会用 test_path_buf、canonicalize_if_exists 和 test_skill_metadata 搭好假环境；真正判断交给 detect_skill_doc_read；最后用 assert_eq! 检查识别到的技能名。

调用图：调用 1 个内部函数（test_skill_metadata）；外部调用 9 个（new, default, from, new, assert_eq!, test_path_buf, canonicalize_if_exists, detect_skill_doc_read, vec!）。

fn skill_doc_read_detection_matches_shared_read_parser()

作用：这个测试确认：系统不只认识 cat，也能通过共享的读文件解析规则，识别像 nl -ba SKILL.md 这样的读文档命令。

数据流：测试先准备同一个假的技能文档路径，并把这份技能按规范化后的文档路径登记好。然后构造命令片段：nl -ba /tmp/skill-test/SKILL.md，其中 nl 是给文件加行号显示的工具。函数把命令和当前目录交给 detect_skill_doc_read，预期输出是对应的 test-skill。

调用关系：它和绝对路径读取测试很像，但换了一个读文件工具，重点是覆盖“共享读文件解析器”的行为。它同样依赖 test_skill_metadata 准备技能资料，最后由 detect_skill_doc_read 做判断。

调用图：调用 1 个内部函数（test_skill_metadata）；外部调用 9 个（new, default, from, new, assert_eq!, test_path_buf, canonicalize_if_exists, detect_skill_doc_read, vec!）。

fn skill_script_run_detection_matches_relative_path_from_skill_root()

作用：这个测试确认：当用户站在技能根目录里，用相对路径运行 scripts 目录下的脚本时，系统能认出这是在运行该技能的脚本。

数据流：测试先准备技能文档路径和脚本目录 /tmp/skill-test/scripts，并把脚本目录规范化后登记到 SkillLoadOutcome。然后构造命令 python3 scripts/fetch_comments.py，当前工作目录设为 /tmp/skill-test。这些输入交给 detect_skill_script_run 后，预期输出是名叫 test-skill 的技能。

调用关系：它测试的是“从相对脚本路径识别技能”的流程。准备技能资料时调用 test_skill_metadata，准备路径时调用 test_path_buf 和 canonicalize_if_exists，真正匹配交给 detect_skill_script_run。

调用图：调用 1 个内部函数（test_skill_metadata）；外部调用 9 个（new, default, from, new, assert_eq!, test_path_buf, canonicalize_if_exists, detect_skill_script_run, vec!）。

fn skill_script_run_detection_matches_absolute_path_from_any_workdir()

作用：这个测试确认：即使当前目录不在技能目录里，只要命令里用了脚本的绝对路径，系统也能识别出对应技能。

数据流：测试准备同一个技能脚本目录，并把它登记为某个技能的脚本目录。然后构造命令 python3 /tmp/skill-test/scripts/fetch_comments.py，但当前工作目录故意设成 /tmp/other。这些交给 detect_skill_script_run 后，结果应该仍然是 test-skill，说明识别不依赖当前目录刚好正确。

调用关系：它补上了绝对路径场景，和相对路径测试一起保证脚本识别更可靠。它用 test_skill_metadata 和路径工具搭好假数据，再把判断交给 detect_skill_script_run，最后用断言确认匹配结果。

调用图：调用 1 个内部函数（test_skill_metadata）；外部调用 9 个（new, default, from, new, assert_eq!, test_path_buf, canonicalize_if_exists, detect_skill_script_run, vec!）。

async fn make_config(codex_home: &TempDir) -> TestConfig

作用：给测试快速做一份默认配置。测试不想每次都手写系统、用户、项目这些配置层，所以用它一键准备。

数据流：输入一个临时的 Codex 主目录 → 把当前工作目录默认设成这个临时目录 → 调用 make_config_for_cwd 生成 TestConfig，里面有绝对路径形式的 cwd 和配置层栈。

调用关系：很多测试先用它搭好干净环境，再交给 load_skills_for_test 去真正加载技能；它把细节都转交给 make_config_for_cwd。

调用图：调用 1 个内部函数（make_config_for_cwd）；被 19 处调用（accepts_icon_paths_under_assets_dir, does_not_loop_on_symlink_cycle_for_user_scope, drops_interface_when_icons_are_invalid, empty_skill_policy_defaults_to_allow_implicit_invocation, enforces_length_limits, enforces_short_description_length_limits, falls_back_to_directory_name_when_skill_name_is_missing, ignores_default_prompt_over_max_length, ignores_invalid_brand_color, ignores_symlinked_skill_file_for_user_scope (+9 more)）；外部调用 1 个（path）。

fn config_file(path: PathBuf) -> AbsolutePathBuf

作用：把普通路径转成测试里需要的绝对路径。这样后面的配置层不会因为相对路径而受运行位置影响。

数据流：输入一个 PathBuf 路径 → 调用 abs 把它变成 AbsolutePathBuf → 返回这个绝对路径。

调用关系：它是 make_config_for_cwd 里构造系统配置文件和用户配置文件位置的小帮手。

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

fn project_layers_for_cwd(cwd: &Path) -> Vec<ConfigLayerEntry>

作用：根据当前目录，模拟项目里的 .codex 配置层。它用来测试仓库技能搜索时，哪些项目目录应该参与。

数据流：输入一个当前路径，可能是目录也可能是文件 → 如果是文件就取它的父目录，再往上找 .git 作为项目根；从项目根到当前目录之间收集存在 .codex 的目录 → 输出这些项目配置层。

调用关系：make_config_for_cwd 会调用它，把项目配置层插到系统和用户配置层后面，之后技能根目录推导逻辑会使用这些层。

调用图：被 1 处调用（make_config_for_cwd）；外部调用 3 个（is_dir, parent, to_path_buf）。

async fn make_config_for_cwd(codex_home: &TempDir, cwd: PathBuf) -> TestConfig

作用：给指定当前目录做一份完整测试配置。它让测试能模拟“我现在在某个仓库、子目录或文件里运行”的情况。

数据流：输入临时 Codex 主目录和 cwd → 创建假的系统配置目录，准备系统层、用户层，再加上 project_layers_for_cwd 找到的项目层 → 输出 TestConfig。

调用关系：大量仓库相关测试直接调用它；make_config 也只是它的简化版。生成的配置随后通常会传给 load_skills_for_test。

调用图：调用 2 个内部函数（new, project_layers_for_cwd）；被 12 处调用（keeps_duplicate_names_from_nested_codex_dirs, keeps_duplicate_names_from_repo_and_user, loads_skills_from_agents_dir_without_codex_dir, loads_skills_from_all_codex_dirs_under_project_root, loads_skills_from_codex_dir_when_not_git_repo, loads_skills_from_repo_root, loads_skills_from_system_cache_when_present, loads_skills_via_symlinked_subdir_for_repo_scope, loads_skills_when_cwd_is_file_in_repo, make_config (+2 more)）；外部调用 6 个（abs, path, default, default, create_dir_all, vec!）。

async fn load_skills_for_test(config: &TestConfig) -> SkillLoadOutcome

作用：用测试配置实际跑一次技能加载。它故意不扫描真实用户家目录，避免测试被机器上的真实文件污染。

数据流：输入 TestConfig → 先根据配置层算出要扫描的技能根目录，再调用 load_skills_from_roots 读取技能 → 输出 SkillLoadOutcome，里面有成功技能和错误列表。

调用关系：多数测试在写好临时技能文件后调用它；它把测试环境和真正的加载器连接起来。

调用图：被 29 处调用（accepts_icon_paths_under_assets_dir, does_not_loop_on_symlink_cycle_for_user_scope, drops_interface_when_icons_are_invalid, empty_skill_policy_defaults_to_allow_implicit_invocation, enforces_length_limits, enforces_short_description_length_limits, falls_back_to_directory_name_when_skill_name_is_missing, ignores_default_prompt_over_max_length, ignores_invalid_brand_color, ignores_symlinked_skill_file_for_user_scope (+15 more)）；外部调用 3 个（clone, load_skills_from_roots, skill_roots_from_layer_stack）。

fn mark_as_git_repo(dir: &Path)

作用：把一个临时目录伪装成 Git 仓库。测试只需要有 .git 标记，不需要真的运行 git init。

数据流：输入目录路径 → 在里面写一个假的 .git 文件 → 后续项目根发现逻辑就会把这里当作仓库根。

调用关系：仓库技能相关测试先调用它，再用 make_config_for_cwd 和 load_skills_for_test 验证仓库范围规则。

调用图：被 8 处调用（keeps_duplicate_names_from_nested_codex_dirs, keeps_duplicate_names_from_repo_and_user, loads_skills_from_agents_dir_without_codex_dir, loads_skills_from_all_codex_dirs_under_project_root, loads_skills_from_repo_root, loads_skills_via_symlinked_subdir_for_repo_scope, loads_skills_when_cwd_is_file_in_repo, repo_skills_search_does_not_escape_repo_root）；外部调用 2 个（join, write）。

fn normalized(path: &Path) -> AbsolutePathBuf

作用：把路径整理成稳定的绝对路径，方便测试比较。这样符号链接、相对路径等差异不会让断言误判。

数据流：输入路径 → 尝试规范化；如果规范化失败就退回原路径 → 转成绝对路径并返回。

调用关系：很多断言用它生成期望的 path_to_skills_md 或图标路径，确保和加载器输出的路径格式一致。