Plano Rust 工作区标准检查流程改动代码后必跑的 cargo fmt、clippy 与单元测试【免费下载链接】planoPlano is an AI-native proxy server and data plane for agentic apps. Smart LLM routing, observability, agent orchestration, and guardrails so you stay focused on your agents core logic.项目地址: https://gitcode.com/GitHub_Trending/ar/plano本文解析 Plano 仓库为 Rust 代码变更定义的标准本地检查技能skill按固定顺序执行cargo fmt --all -- --check、cargo clippy --locked --all-targets --all-features -- -D warnings、cargo test --lib三步验证并汇报通过/失败摘要。读完本文你能完整复现这套检查流程、理解每条命令中每个标志位对 5 个 crate 工作区的实际作用范围并确认它与 pre-commit、CI 流水线中同一套检查的对应关系。这个技能文档定义了什么问题.claude/skills/check/SKILL.md 是仓库中面向 AI 编码助手的技能文件其 frontmatter 明确了两点元信息name: check description: Run Rust fmt, clippy, and unit tests. Use after making Rust code changes.即技能名check用途是“在做出 Rust 代码改动之后”运行本地检查。技能正文规定的操作序列非常明确必须按顺序执行三条命令cd crates cargo fmt --all -- --check—— 若格式检查失败运行cargo fmt --all修复cd crates cargo clippy --locked --all-targets --all-features -- -D warnings—— 修复所有警告cd crates cargo test --lib—— 确保所有单元测试通过。执行完毕后还要“Report a summary of what passed/failed”——即给出一份逐项通过/失败的摘要而不是笼统地宣称“检查通过”。这三步正是 CLAUDE.md 中 “Build Test Commands” 一节列出的 “Rust — tests, format, lint” 三条命令的逐字对应# Rust — tests, format, lint cd crates cargo test --lib cd crates cargo fmt --all -- --check cd crates cargo clippy --locked --all-targets --all-features -- -D warnings技能文档的价值在于把“哪些命令”进一步约束成了“什么顺序、失败时如何自修复、结束时如何汇报”使其成为 AI Agent 在每次 Rust 改动后可以机械执行的闭环。为什么所有命令都必须先进入 crates/ 目录三条命令的共同前缀是cd crates。这不是随手写的Rust 工作区的清单文件 crates/Cargo.toml 声明了cargo fmt --all、cargo clippy、cargo test实际作用的对象——[workspace] resolver 2 members [llm_gateway, prompt_gateway, common, brightstaff, hermesllm]五个成员 crate 的职责分工可以在 CLAUDE.md 的 Architecture 一节找到完整说明crate形态职责prompt_gatewayWASMProxy-WASM filter负责 prompt 处理、guardrails、filter chainsllm_gatewayWASMProxy-WASM filter负责 LLM 请求/响应处理与路由brightstaff原生二进制核心服务handlers、router、signals、state、tracingcommon库共享配置、HTTP、路由、限流、tokenizer、PII、tracinghermesllm库各 LLM 供应商之间的 API 翻译因此--all/--all-targets/ 工作区级cargo test --lib会同时覆盖网关过滤器、原生服务与两个共享库任何 crate 的改动都必须经过同一套检查。第一步cargo fmt --all -- --checkcd crates cargo fmt --all -- --check--all对工作区内所有成员执行而不是仅默认包-- --check把参数传给rustfmt的--check模式只做检查、不写回文件存在格式偏差时以非零退出码结束适合作为门禁技能文档给出的修复动作是检查失败时运行cd crates cargo fmt --all不带--check自动重写为规范格式再重新检查。这一约定与 CLAUDE.md “Key Conventions” 中的 “Rust edition 2021,cargo fmt” 一致Rust 侧的格式规范完全交给rustfmt没有人工风格争论空间。第二步cargo clippy 的四个标志位cd crates cargo clippy --locked --all-targets --all-features -- -D warnings这条命令是三步中最“重”的一步四个标志位各自有明确的覆盖范围--locked强制使用现有的 Cargo.lock不重新解析依赖。检查结果的依赖版本与 CI、与本地构建完全一致避免“在我机器上警告、在 CI 上通过”的版本漂移--all-targets不仅 lint 库与二进制目标还覆盖测试代码、示例等目标。对brightstaff而言尤其重要——从 crates/brightstaff/Cargo.toml 可以看到它声明了两个可执行目标brightstaff与signals_replay--all-targets保证这些 bin 与其中的#[cfg(test)]代码都进入 lint 范围--all-features开启所有 feature 组合检查。以 crates/brightstaff/Cargo.toml 为例default [jemalloc]即默认就依赖tikv-jemallocator/tikv-jemalloc-ctl--all-features确保 feature 门控的代码路径不会被漏检-- -D warnings把rustc收到的warnings提升为deny即“任何警告 失败”。这与 CLAUDE.md 中 “cargo clippy -D warnings” 的约定完全一致也是技能文档中 “fix any warnings” 的执行依据——警告必须修掉不能靠豁免放行。第三步cargo test --lib 到底跑什么cd crates cargo test --lib--lib限定了测试范围只运行各 crate库目标内的单元测试不运行集成测试目录tests/下与文档测试。这正是“快速、无需外部依赖”的本地回归手段——仓库中面向真实 LLM 供应商的端到端测试被单独放在 tests/e2e/需要 Docker 镜像与 API Key不在这一步的范围内。从源码分布看这套--lib单元测试的规模相当可观统计各 crate 源码中的#[test]函数总数为463 个且集中在真正容易出错的模块上例如测试集中的文件测试数覆盖的核心行为crates/common/src/configuration.rs29工作区共享配置解析crates/hermesllm/src/providers/id.rs24ProviderId字符串映射crates/hermesllm/src/apis/openai_responses.rs23Responses API 请求/响应解析crates/hermesllm/src/providers/request.rs21供应商请求分发crates/brightstaff/src/handlers/llm/session_router.rs21会话路由crates/brightstaff/src/handlers/function_calling.rs15函数调用处理crates/llm_gateway/src/stream_context.rs11流式响应上下文这解释了为什么cargo test --lib被选为本地检查的第三步它覆盖了配置解析、供应商 API 翻译hermesllm是请求/响应转换的核心库、路由与流式处理这些最容易回归的内部逻辑且全部可在本地无网络、无 API Key 的环境跑完。需要说明的是llm_gateway与prompt_gateway在部署形态上编译为 WASM见 CLAUDE.md 的--targetwasm32-wasip1构建命令而cargo test --lib在宿主机目标上执行其单元测试两者互不替代。与 pre-commit、CI 的同一套检查这三条命令并非技能文档的“私人约定”而是整个仓库质量门禁的同一套标准可以从两处仓库证据交叉印证pre-commit 钩子.pre-commit-config.yaml 用三个 local hook 逐字复现了技能文档的命令- id: cargo-fmt entry: bash -c cd crates cargo fmt --all -- --check - id: cargo-clippy entry: bash -c cd crates cargo clippy --locked --offline --all-targets --all-features -- -D warnings || cargo clippy --locked --all-targets --all-features -- -D warnings - id: cargo-test entry: bash -c cd crates cargo test --lib值得注意的是 clippy 钩子加了--offline优先、失败再回退在线执行的写法用于适配无网络的前端环境技能文档中的命令则是标准在线版本。CI 流水线.github/workflows/ci.yml 的pre-commitjob 在每次 push 与 pull request 上通过pre-commit/action运行上述钩子工作流注释即 “Pre-commit (fmt, clippy, cargo test, black, yaml)”。也就是说开发者或 Agent 在本地按技能顺序跑完三步并全部通过等价于预演了 CI 的 Rust 质量门禁而 CLAUDE.md 还给出了第四条等价入口pre-commit run --all-files可一次性触发 fmt、clippy、cargo test、blackPython、yaml 校验。复现清单与失败处置综合技能文档正文一次完整的check执行应输出如下形式的结论摘要这是技能第 3 条 “Report a summary” 的要求cd crates cargo fmt --all -- --check # 失败 → cargo fmt --all 后重跑 cd crates cargo clippy --locked --all-targets --all-features -- -D warnings # 有警告 → 逐条修复 cd crates cargo test --lib # 失败 → 定位失败用例所在 crate汇报时逐项说明格式检查通过/已自动修复、clippy 零警告/已修复哪些警告、cargo test --lib的通过数量与失败用例。若任一环节失败且无法定位原因技能文档没有提供“跳过”选项——这与-D warnings的零警告策略一致门禁要么全部通过要么继续修复。适用前提该流程面向crates/下的 Rust 工作区要求本机安装 Rust 工具链--locked意味着依赖版本以仓库内 Cargo.lock 为准。Python CLIcli/用uv run pytest验证与 JS/TS 应用npm run build npm run lint npm run typecheck各有独立的检查命令不在本技能范围内参见 CLAUDE.md。【免费下载链接】planoPlano is an AI-native proxy server and data plane for agentic apps. Smart LLM routing, observability, agent orchestration, and guardrails so you stay focused on your agents core logic.项目地址: https://gitcode.com/GitHub_Trending/ar/plano创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Plano Rust 工作区标准检查流程：改动代码后必跑的 cargo fmt、clippy 与单元测试
Plano Rust 工作区标准检查流程改动代码后必跑的 cargo fmt、clippy 与单元测试【免费下载链接】planoPlano is an AI-native proxy server and data plane for agentic apps. Smart LLM routing, observability, agent orchestration, and guardrails so you stay focused on your agents core logic.项目地址: https://gitcode.com/GitHub_Trending/ar/plano本文解析 Plano 仓库为 Rust 代码变更定义的标准本地检查技能skill按固定顺序执行cargo fmt --all -- --check、cargo clippy --locked --all-targets --all-features -- -D warnings、cargo test --lib三步验证并汇报通过/失败摘要。读完本文你能完整复现这套检查流程、理解每条命令中每个标志位对 5 个 crate 工作区的实际作用范围并确认它与 pre-commit、CI 流水线中同一套检查的对应关系。这个技能文档定义了什么问题.claude/skills/check/SKILL.md 是仓库中面向 AI 编码助手的技能文件其 frontmatter 明确了两点元信息name: check description: Run Rust fmt, clippy, and unit tests. Use after making Rust code changes.即技能名check用途是“在做出 Rust 代码改动之后”运行本地检查。技能正文规定的操作序列非常明确必须按顺序执行三条命令cd crates cargo fmt --all -- --check—— 若格式检查失败运行cargo fmt --all修复cd crates cargo clippy --locked --all-targets --all-features -- -D warnings—— 修复所有警告cd crates cargo test --lib—— 确保所有单元测试通过。执行完毕后还要“Report a summary of what passed/failed”——即给出一份逐项通过/失败的摘要而不是笼统地宣称“检查通过”。这三步正是 CLAUDE.md 中 “Build Test Commands” 一节列出的 “Rust — tests, format, lint” 三条命令的逐字对应# Rust — tests, format, lint cd crates cargo test --lib cd crates cargo fmt --all -- --check cd crates cargo clippy --locked --all-targets --all-features -- -D warnings技能文档的价值在于把“哪些命令”进一步约束成了“什么顺序、失败时如何自修复、结束时如何汇报”使其成为 AI Agent 在每次 Rust 改动后可以机械执行的闭环。为什么所有命令都必须先进入 crates/ 目录三条命令的共同前缀是cd crates。这不是随手写的Rust 工作区的清单文件 crates/Cargo.toml 声明了cargo fmt --all、cargo clippy、cargo test实际作用的对象——[workspace] resolver 2 members [llm_gateway, prompt_gateway, common, brightstaff, hermesllm]五个成员 crate 的职责分工可以在 CLAUDE.md 的 Architecture 一节找到完整说明crate形态职责prompt_gatewayWASMProxy-WASM filter负责 prompt 处理、guardrails、filter chainsllm_gatewayWASMProxy-WASM filter负责 LLM 请求/响应处理与路由brightstaff原生二进制核心服务handlers、router、signals、state、tracingcommon库共享配置、HTTP、路由、限流、tokenizer、PII、tracinghermesllm库各 LLM 供应商之间的 API 翻译因此--all/--all-targets/ 工作区级cargo test --lib会同时覆盖网关过滤器、原生服务与两个共享库任何 crate 的改动都必须经过同一套检查。第一步cargo fmt --all -- --checkcd crates cargo fmt --all -- --check--all对工作区内所有成员执行而不是仅默认包-- --check把参数传给rustfmt的--check模式只做检查、不写回文件存在格式偏差时以非零退出码结束适合作为门禁技能文档给出的修复动作是检查失败时运行cd crates cargo fmt --all不带--check自动重写为规范格式再重新检查。这一约定与 CLAUDE.md “Key Conventions” 中的 “Rust edition 2021,cargo fmt” 一致Rust 侧的格式规范完全交给rustfmt没有人工风格争论空间。第二步cargo clippy 的四个标志位cd crates cargo clippy --locked --all-targets --all-features -- -D warnings这条命令是三步中最“重”的一步四个标志位各自有明确的覆盖范围--locked强制使用现有的 Cargo.lock不重新解析依赖。检查结果的依赖版本与 CI、与本地构建完全一致避免“在我机器上警告、在 CI 上通过”的版本漂移--all-targets不仅 lint 库与二进制目标还覆盖测试代码、示例等目标。对brightstaff而言尤其重要——从 crates/brightstaff/Cargo.toml 可以看到它声明了两个可执行目标brightstaff与signals_replay--all-targets保证这些 bin 与其中的#[cfg(test)]代码都进入 lint 范围--all-features开启所有 feature 组合检查。以 crates/brightstaff/Cargo.toml 为例default [jemalloc]即默认就依赖tikv-jemallocator/tikv-jemalloc-ctl--all-features确保 feature 门控的代码路径不会被漏检-- -D warnings把rustc收到的warnings提升为deny即“任何警告 失败”。这与 CLAUDE.md 中 “cargo clippy -D warnings” 的约定完全一致也是技能文档中 “fix any warnings” 的执行依据——警告必须修掉不能靠豁免放行。第三步cargo test --lib 到底跑什么cd crates cargo test --lib--lib限定了测试范围只运行各 crate库目标内的单元测试不运行集成测试目录tests/下与文档测试。这正是“快速、无需外部依赖”的本地回归手段——仓库中面向真实 LLM 供应商的端到端测试被单独放在 tests/e2e/需要 Docker 镜像与 API Key不在这一步的范围内。从源码分布看这套--lib单元测试的规模相当可观统计各 crate 源码中的#[test]函数总数为463 个且集中在真正容易出错的模块上例如测试集中的文件测试数覆盖的核心行为crates/common/src/configuration.rs29工作区共享配置解析crates/hermesllm/src/providers/id.rs24ProviderId字符串映射crates/hermesllm/src/apis/openai_responses.rs23Responses API 请求/响应解析crates/hermesllm/src/providers/request.rs21供应商请求分发crates/brightstaff/src/handlers/llm/session_router.rs21会话路由crates/brightstaff/src/handlers/function_calling.rs15函数调用处理crates/llm_gateway/src/stream_context.rs11流式响应上下文这解释了为什么cargo test --lib被选为本地检查的第三步它覆盖了配置解析、供应商 API 翻译hermesllm是请求/响应转换的核心库、路由与流式处理这些最容易回归的内部逻辑且全部可在本地无网络、无 API Key 的环境跑完。需要说明的是llm_gateway与prompt_gateway在部署形态上编译为 WASM见 CLAUDE.md 的--targetwasm32-wasip1构建命令而cargo test --lib在宿主机目标上执行其单元测试两者互不替代。与 pre-commit、CI 的同一套检查这三条命令并非技能文档的“私人约定”而是整个仓库质量门禁的同一套标准可以从两处仓库证据交叉印证pre-commit 钩子.pre-commit-config.yaml 用三个 local hook 逐字复现了技能文档的命令- id: cargo-fmt entry: bash -c cd crates cargo fmt --all -- --check - id: cargo-clippy entry: bash -c cd crates cargo clippy --locked --offline --all-targets --all-features -- -D warnings || cargo clippy --locked --all-targets --all-features -- -D warnings - id: cargo-test entry: bash -c cd crates cargo test --lib值得注意的是 clippy 钩子加了--offline优先、失败再回退在线执行的写法用于适配无网络的前端环境技能文档中的命令则是标准在线版本。CI 流水线.github/workflows/ci.yml 的pre-commitjob 在每次 push 与 pull request 上通过pre-commit/action运行上述钩子工作流注释即 “Pre-commit (fmt, clippy, cargo test, black, yaml)”。也就是说开发者或 Agent 在本地按技能顺序跑完三步并全部通过等价于预演了 CI 的 Rust 质量门禁而 CLAUDE.md 还给出了第四条等价入口pre-commit run --all-files可一次性触发 fmt、clippy、cargo test、blackPython、yaml 校验。复现清单与失败处置综合技能文档正文一次完整的check执行应输出如下形式的结论摘要这是技能第 3 条 “Report a summary” 的要求cd crates cargo fmt --all -- --check # 失败 → cargo fmt --all 后重跑 cd crates cargo clippy --locked --all-targets --all-features -- -D warnings # 有警告 → 逐条修复 cd crates cargo test --lib # 失败 → 定位失败用例所在 crate汇报时逐项说明格式检查通过/已自动修复、clippy 零警告/已修复哪些警告、cargo test --lib的通过数量与失败用例。若任一环节失败且无法定位原因技能文档没有提供“跳过”选项——这与-D warnings的零警告策略一致门禁要么全部通过要么继续修复。适用前提该流程面向crates/下的 Rust 工作区要求本机安装 Rust 工具链--locked意味着依赖版本以仓库内 Cargo.lock 为准。Python CLIcli/用uv run pytest验证与 JS/TS 应用npm run build npm run lint npm run typecheck各有独立的检查命令不在本技能范围内参见 CLAUDE.md。【免费下载链接】planoPlano is an AI-native proxy server and data plane for agentic apps. Smart LLM routing, observability, agent orchestration, and guardrails so you stay focused on your agents core logic.项目地址: https://gitcode.com/GitHub_Trending/ar/plano创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考