Worktrunk PR 审查数据安全红线、Rust 代码规范与仓库专属审查清单【免费下载链接】worktrunkWorktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows项目地址: https://gitcode.com/GitHub_Trending/wo/worktrunk导读Worktrunk 是一个用 Rust 编写的 Git worktree 管理 CLI专为并行 AI Agent 工作流设计。当 AI Agent 或维护者在 CI 环境中审查合并请求PR时最高优先级不是代码风格而是防止静默销毁用户数据——一个看似无害的 force 标志绕过可能让已提交的工作彻底丢失。本文基于仓库内 review-pr.md 的核心规范结合 remove.rs 等源码与测试证据系统讲解如何识别删除风险面、执行 Rust 惯用与文档准确性审查、追踪 flaky 测试并给出可直接套用的审查清单与命令。一、为什么 Worktrunk 的审查必须从数据丢失面开始Worktrunk 的核心职责是管理多个并行 worktree——它本身就是围绕wt remove、wt merge --remove、wt step prune等删除操作构建的工具。这意味着它的最严重故障模式不是崩溃而是静默销毁用户的工作一次 worktree 删除、一次分支删除、一次reset --hard都可能带走无法恢复的提交或未提交内容。因此review-pr.md 明确要求任何触及删除表面的变更都不属于 Agent 可以自行合并的范畴——即使它看起来无害。force 标志绕过可能读起来无足轻重却仍可能丢弃已提交的工作。这一原则与源码中的设计哲学完全一致。src/git/remove.rs 的stage_worktree_removal函数在注释中直接写明将脏工作区门禁、fsmonitor 停止、trash 暂存三步保持在一起正是因为这个顺序容易在细节上出错而搞错顺序会销毁未提交的工作getting it wrong destroys uncommitted work。审查者必须把同样的警觉带入 PR 审查。二、删除风险面清单命中即暂停合并2.1 需要标记的危险变更当 PR 的 diff 出现以下任一情况或扩大了现有删除能力的范围或修改了包含这些内容的文件时必须标记类别具体模式Worktrunk 命令wt remove尤其是-D/--force-delete或-f/--forceGit 命令git branch -D/-d、git worktree remove --forceGit 破坏性操作git reset --hard、git checkout -f、带-f/-d/-x的git clean文件系统删除rm -rf、std::fs::remove_dir_all、std::fs::remove_file随附自动化plugins/*/hooks/hooks.json、hooks/hooks.json、hooks/wt.sh以及用户会复制的 skill 或 alias 示例以hooks/hooks.json为例它本身虽然只包含config state marker set/clear这类无害调用但它是随附自动化文件——若有人向其中加入删除命令就会在用户毫无察觉的情况下于 Agent 会话边界执行。仓库中真实的 hooks 自动化见 plugins/worktrunk/hooks/hooks.json其命令行通过 plugins/worktrunk/hooks/wt.sh 解析到真实的wt二进制。2.2 判定标准看内容能否再生而非目录新旧Hold暂停合并针对的是用户无法找回的东西一个 worktree一个仓库一个分支未提交的工作由 worktrunk 代表用户写入的文件它自己的配置与状态、rc 文件、其他工具的设置当满足以下条件时删除不构成风险目标下的一切都可以重新生成删除被限定在一次性 CI 或开发环境中。判断依据是内容而不是目录存在的时间长短。文档给出了一个精妙的反例wt step promote在同一操作内创建其 staging 目录并删除它——在两次操作之间该目录保存着两个 worktree 的 ignored 文件的唯一副本。一个临时目录很快会被删除的假设在这里会直接导致用户 ignored 文件丢失。这正是不能只看目录年龄的原因。2.3 判定范围以 diff 能触达的范围为准而非代码相邻位置源码中即使破坏性代码行本身不在 diff 中只要变更位于 force-delete 路径附近就要 Hold。结构化配置中对于条目相互独立的配置只有 diff 真正触及破坏性条目本身时才 Hold。比如 src/commands/remove.rs 中的校验逻辑--force-delete与delete-branchfalse冲突时报错。若某个 PR 只是重排了这个校验附近的代码即便没有改动git branch -D那一行也必须 Hold——因为重排可能改变校验顺序破坏数据安全语义。2.4 命中后的处理流程命中删除风险面后必须按以下三步执行在审查意见中点名命令与文件例如src/git/remove.rs中的-D路径请求max-sixty进行审查不得批准或授权合并即使它看起来可接受。三、审查标准Rust 惯用法与项目约定3.1 代码风格与类型使用审查时对照以下问题代码是否遵循 Rust 惯用法用 Iterator 链代替手写循环、用?代替 match-on-error、正确使用 Option/Result是否存在不必要的分配、clone或在借用够用的情况下使用 owned 类型在返回Result的函数中新代码是否使用了.expect()或.unwrap()这些应改用?或bail!。Worktrunk 源码本身就是这些规范的样板。例如 src/git/remove.rs 的BranchDeletionMode::from_flags用一个小型 match 表达式将三个布尔状态映射为显式枚举而不是用多个if——这正是用显式类型表达状态的惯用做法。该枚举Keep/SafeDelete/ForceDelete的存在本身就说明两个布尔标志keep/force会允许keepforce这类非法组合而枚举从类型层面消除了它。3.2 测试约定测试是否符合项目的测试规范见 tests/CLAUDE.mdtests/CLAUDE.md 中与删除路径直接相关的关键约定包括运行全套测试cargo run -- hook pre-merge --yes单测cargo test --lib --bins集成测试cargo test --test integration使用repo.wt_command()或wt_command()保证子进程隔离防止读取/写入开发者真实配置绝不通过运行时可用性检查跳过测试一律用 Cargo feature flag如shell-integration-tests计时测试遵循长超时 快速轮询与固定窗口断言缺席的原则禁止重试No Retries通过的测试必须意味着代码真的通过。删除路径的测试覆盖非常充分tests/integration_tests/remove.rs 中有大量与删除安全直接相关的用例例如test_remove_locked_worktree、test_remove_force_with_untracked_files、test_remove_force_with_force_delete、test_remove_force_delete_refused_while_branch_is_shared、test_remove_sweeps_stale_trash_entries。审查删除相关 PR 时应要求新行为至少达到同样的测试密度。3.3 CLAUDE.md 合规审查与变更代码相关的 CLAUDE.md 章节根目录与 tests/CLAUDE.md标记偏差——包括代码质量、错误处理、命令执行、数据安全、system docstrings 等。3.4 文档准确性行为变更必须同步文档当 PR 改变行为时必须检查相关文档是否仍然匹配src/cli/mod.rs 与 src/cli/config.rs 中的after_long_help是否仍能描述代码的实际行为这些是文档页面的主要来源配置示例中的内联 TOML 注释是否与实际行为一致如果添加了新功能相关帮助文本是否提到了它这个检查点有测试兜底test_docs_are_in_sync会验证帮助文本与其生成的镜像文档保持同步相关机制在 tests/integration_tests/help.rs 中。四、重复实现搜索模式避免平行实现针对 Rust 项目特有的重复实现风险文档给出了直接可用的搜索命令# 新函数搜索已有实现 rg fn detect.*provider|fn get.*platform|fn .*_provider --type rust # 遍历 remotes 并解析 URL 的代码 rg all_remote_urls|remote_url|GitRemoteUrl::parse --type rust这类搜索的目的是防止平行实现——同样的逻辑在不同模块中出现两份随后各自漂移。例如 src/git/remove.rs 的delete_branch_if_safe注释明确指出其集成检查与wt list状态列共用同一套integration_reason逻辑。审查时若发现新的分支状态计算应先搜索是否已有integration_reason可复用而不是另写一份。五、Flake 追踪worktrunk-bot 登录名约定报告 flaky 测试时必须使用worktrunk-bot作为机器人登录名以实现评论去重。文档给出的命令LAST_COMMENT$(gh issue view issue-number --json comments \ --jq [.comments[] | select(.author.login worktrunk-bot)] | last | {id: .url, createdAt: .createdAt})这条命令从 issue 的所有评论中筛选出worktrunk-bot的评论取最新一条的 URL 与创建时间用于判断是否已经报告过该 flake避免同一问题被重复刷屏。结合 .claude/skills/running-tend/SKILL.md 中的 CI 约定还有两点与审查直接相关不要因为无关的测试 flake 而撤销自己的批准。如果批准 PR 后一个明显无关的测试失败保留批准并评论说明该 flake 即可不要撤销批准去等待重跑。codecov/patch 失败时的撤销模式是例外且是正确的CLAUDE.md 要求合并前必须显式用户批准因此覆盖率缺口解决前撤销批准是故意的。六、给审查者的实践清单综合文档与仓库实现一份可复用的 Worktrunk PR 审查清单如下扫描 diff是否新增或扩大了wt remove-D/-f、git branch -D、git reset --hard、git checkout -f、git clean -f、rm -rf、remove_dir_all、remove_file或修改了 hooks 自动化与用户可复制示例评估不可再生性删除目标是否包含无法重新生成的内容worktree、分支、未提交工作、wt 写入的配置文件是否限定在一次性 CI 环境触达范围判定破坏性代码行虽不在 diff但其所在路径被改动结构化配置中是否真正触及破坏性条目命中即 Hold点名命令与文件、请求 max-sixty 审查、不批准不合并不授权。Rust 惯用检查Iterator 链、?传播、无多余 clone、Result函数中无.expect()/.unwrap()。测试检查是否符合 tests/CLAUDE.md 的隔离、feature flag、无重试、计时测试约定文档同步after_long_help、内联 TOML 注释、新功能帮助文本是否更新去重搜索用rg搜索 provider/platform/remote-url 相关实现避免平行实现。Flake 报告用worktrunk-bot登录名 去重命令不因无关 flake 撤销已批准的 PR。结语Worktrunk 的 PR 审查之所以把数据丢失面放在最前面是因为这个项目用 Rust 管理的是用户最珍贵的资产——并行开发中的工作现场。审查者把删除风险面清单、Rust 惯用法、文档同步与去重搜索四件事做扎实就能既守住数据安全的红线又保持代码库长期可维护。上述所有规范与源码证据都可以在 review-pr.md、src/git/remove.rs、src/commands/remove.rs 与 tests/integration_tests/remove.rs 中进一步核对。【免费下载链接】worktrunkWorktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows项目地址: https://gitcode.com/GitHub_Trending/wo/worktrunk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/16 22:22:14 · 阅读 1.2k Worktrunk PR 审查：数据安全红线、Rust 代码规范与仓库专属审查清单
Worktrunk PR 审查数据安全红线、Rust 代码规范与仓库专属审查清单【免费下载链接】worktrunkWorktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows项目地址: https://gitcode.com/GitHub_Trending/wo/worktrunk导读Worktrunk 是一个用 Rust 编写的 Git worktree 管理 CLI专为并行 AI Agent 工作流设计。当 AI Agent 或维护者在 CI 环境中审查合并请求PR时最高优先级不是代码风格而是防止静默销毁用户数据——一个看似无害的 force 标志绕过可能让已提交的工作彻底丢失。本文基于仓库内 review-pr.md 的核心规范结合 remove.rs 等源码与测试证据系统讲解如何识别删除风险面、执行 Rust 惯用与文档准确性审查、追踪 flaky 测试并给出可直接套用的审查清单与命令。一、为什么 Worktrunk 的审查必须从数据丢失面开始Worktrunk 的核心职责是管理多个并行 worktree——它本身就是围绕wt remove、wt merge --remove、wt step prune等删除操作构建的工具。这意味着它的最严重故障模式不是崩溃而是静默销毁用户的工作一次 worktree 删除、一次分支删除、一次reset --hard都可能带走无法恢复的提交或未提交内容。因此review-pr.md 明确要求任何触及删除表面的变更都不属于 Agent 可以自行合并的范畴——即使它看起来无害。force 标志绕过可能读起来无足轻重却仍可能丢弃已提交的工作。这一原则与源码中的设计哲学完全一致。src/git/remove.rs 的stage_worktree_removal函数在注释中直接写明将脏工作区门禁、fsmonitor 停止、trash 暂存三步保持在一起正是因为这个顺序容易在细节上出错而搞错顺序会销毁未提交的工作getting it wrong destroys uncommitted work。审查者必须把同样的警觉带入 PR 审查。二、删除风险面清单命中即暂停合并2.1 需要标记的危险变更当 PR 的 diff 出现以下任一情况或扩大了现有删除能力的范围或修改了包含这些内容的文件时必须标记类别具体模式Worktrunk 命令wt remove尤其是-D/--force-delete或-f/--forceGit 命令git branch -D/-d、git worktree remove --forceGit 破坏性操作git reset --hard、git checkout -f、带-f/-d/-x的git clean文件系统删除rm -rf、std::fs::remove_dir_all、std::fs::remove_file随附自动化plugins/*/hooks/hooks.json、hooks/hooks.json、hooks/wt.sh以及用户会复制的 skill 或 alias 示例以hooks/hooks.json为例它本身虽然只包含config state marker set/clear这类无害调用但它是随附自动化文件——若有人向其中加入删除命令就会在用户毫无察觉的情况下于 Agent 会话边界执行。仓库中真实的 hooks 自动化见 plugins/worktrunk/hooks/hooks.json其命令行通过 plugins/worktrunk/hooks/wt.sh 解析到真实的wt二进制。2.2 判定标准看内容能否再生而非目录新旧Hold暂停合并针对的是用户无法找回的东西一个 worktree一个仓库一个分支未提交的工作由 worktrunk 代表用户写入的文件它自己的配置与状态、rc 文件、其他工具的设置当满足以下条件时删除不构成风险目标下的一切都可以重新生成删除被限定在一次性 CI 或开发环境中。判断依据是内容而不是目录存在的时间长短。文档给出了一个精妙的反例wt step promote在同一操作内创建其 staging 目录并删除它——在两次操作之间该目录保存着两个 worktree 的 ignored 文件的唯一副本。一个临时目录很快会被删除的假设在这里会直接导致用户 ignored 文件丢失。这正是不能只看目录年龄的原因。2.3 判定范围以 diff 能触达的范围为准而非代码相邻位置源码中即使破坏性代码行本身不在 diff 中只要变更位于 force-delete 路径附近就要 Hold。结构化配置中对于条目相互独立的配置只有 diff 真正触及破坏性条目本身时才 Hold。比如 src/commands/remove.rs 中的校验逻辑--force-delete与delete-branchfalse冲突时报错。若某个 PR 只是重排了这个校验附近的代码即便没有改动git branch -D那一行也必须 Hold——因为重排可能改变校验顺序破坏数据安全语义。2.4 命中后的处理流程命中删除风险面后必须按以下三步执行在审查意见中点名命令与文件例如src/git/remove.rs中的-D路径请求max-sixty进行审查不得批准或授权合并即使它看起来可接受。三、审查标准Rust 惯用法与项目约定3.1 代码风格与类型使用审查时对照以下问题代码是否遵循 Rust 惯用法用 Iterator 链代替手写循环、用?代替 match-on-error、正确使用 Option/Result是否存在不必要的分配、clone或在借用够用的情况下使用 owned 类型在返回Result的函数中新代码是否使用了.expect()或.unwrap()这些应改用?或bail!。Worktrunk 源码本身就是这些规范的样板。例如 src/git/remove.rs 的BranchDeletionMode::from_flags用一个小型 match 表达式将三个布尔状态映射为显式枚举而不是用多个if——这正是用显式类型表达状态的惯用做法。该枚举Keep/SafeDelete/ForceDelete的存在本身就说明两个布尔标志keep/force会允许keepforce这类非法组合而枚举从类型层面消除了它。3.2 测试约定测试是否符合项目的测试规范见 tests/CLAUDE.mdtests/CLAUDE.md 中与删除路径直接相关的关键约定包括运行全套测试cargo run -- hook pre-merge --yes单测cargo test --lib --bins集成测试cargo test --test integration使用repo.wt_command()或wt_command()保证子进程隔离防止读取/写入开发者真实配置绝不通过运行时可用性检查跳过测试一律用 Cargo feature flag如shell-integration-tests计时测试遵循长超时 快速轮询与固定窗口断言缺席的原则禁止重试No Retries通过的测试必须意味着代码真的通过。删除路径的测试覆盖非常充分tests/integration_tests/remove.rs 中有大量与删除安全直接相关的用例例如test_remove_locked_worktree、test_remove_force_with_untracked_files、test_remove_force_with_force_delete、test_remove_force_delete_refused_while_branch_is_shared、test_remove_sweeps_stale_trash_entries。审查删除相关 PR 时应要求新行为至少达到同样的测试密度。3.3 CLAUDE.md 合规审查与变更代码相关的 CLAUDE.md 章节根目录与 tests/CLAUDE.md标记偏差——包括代码质量、错误处理、命令执行、数据安全、system docstrings 等。3.4 文档准确性行为变更必须同步文档当 PR 改变行为时必须检查相关文档是否仍然匹配src/cli/mod.rs 与 src/cli/config.rs 中的after_long_help是否仍能描述代码的实际行为这些是文档页面的主要来源配置示例中的内联 TOML 注释是否与实际行为一致如果添加了新功能相关帮助文本是否提到了它这个检查点有测试兜底test_docs_are_in_sync会验证帮助文本与其生成的镜像文档保持同步相关机制在 tests/integration_tests/help.rs 中。四、重复实现搜索模式避免平行实现针对 Rust 项目特有的重复实现风险文档给出了直接可用的搜索命令# 新函数搜索已有实现 rg fn detect.*provider|fn get.*platform|fn .*_provider --type rust # 遍历 remotes 并解析 URL 的代码 rg all_remote_urls|remote_url|GitRemoteUrl::parse --type rust这类搜索的目的是防止平行实现——同样的逻辑在不同模块中出现两份随后各自漂移。例如 src/git/remove.rs 的delete_branch_if_safe注释明确指出其集成检查与wt list状态列共用同一套integration_reason逻辑。审查时若发现新的分支状态计算应先搜索是否已有integration_reason可复用而不是另写一份。五、Flake 追踪worktrunk-bot 登录名约定报告 flaky 测试时必须使用worktrunk-bot作为机器人登录名以实现评论去重。文档给出的命令LAST_COMMENT$(gh issue view issue-number --json comments \ --jq [.comments[] | select(.author.login worktrunk-bot)] | last | {id: .url, createdAt: .createdAt})这条命令从 issue 的所有评论中筛选出worktrunk-bot的评论取最新一条的 URL 与创建时间用于判断是否已经报告过该 flake避免同一问题被重复刷屏。结合 .claude/skills/running-tend/SKILL.md 中的 CI 约定还有两点与审查直接相关不要因为无关的测试 flake 而撤销自己的批准。如果批准 PR 后一个明显无关的测试失败保留批准并评论说明该 flake 即可不要撤销批准去等待重跑。codecov/patch 失败时的撤销模式是例外且是正确的CLAUDE.md 要求合并前必须显式用户批准因此覆盖率缺口解决前撤销批准是故意的。六、给审查者的实践清单综合文档与仓库实现一份可复用的 Worktrunk PR 审查清单如下扫描 diff是否新增或扩大了wt remove-D/-f、git branch -D、git reset --hard、git checkout -f、git clean -f、rm -rf、remove_dir_all、remove_file或修改了 hooks 自动化与用户可复制示例评估不可再生性删除目标是否包含无法重新生成的内容worktree、分支、未提交工作、wt 写入的配置文件是否限定在一次性 CI 环境触达范围判定破坏性代码行虽不在 diff但其所在路径被改动结构化配置中是否真正触及破坏性条目命中即 Hold点名命令与文件、请求 max-sixty 审查、不批准不合并不授权。Rust 惯用检查Iterator 链、?传播、无多余 clone、Result函数中无.expect()/.unwrap()。测试检查是否符合 tests/CLAUDE.md 的隔离、feature flag、无重试、计时测试约定文档同步after_long_help、内联 TOML 注释、新功能帮助文本是否更新去重搜索用rg搜索 provider/platform/remote-url 相关实现避免平行实现。Flake 报告用worktrunk-bot登录名 去重命令不因无关 flake 撤销已批准的 PR。结语Worktrunk 的 PR 审查之所以把数据丢失面放在最前面是因为这个项目用 Rust 管理的是用户最珍贵的资产——并行开发中的工作现场。审查者把删除风险面清单、Rust 惯用法、文档同步与去重搜索四件事做扎实就能既守住数据安全的红线又保持代码库长期可维护。上述所有规范与源码证据都可以在 review-pr.md、src/git/remove.rs、src/commands/remove.rs 与 tests/integration_tests/remove.rs 中进一步核对。【免费下载链接】worktrunkWorktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows项目地址: https://gitcode.com/GitHub_Trending/wo/worktrunk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考