chimera-run-the-projects-own-gate-command

你正准备运行项目的质量门禁（gate）——lint、类型检查、测试——并把结果当作这次改动是安全的证据报出来。诱惑在于把它收窄（"我只动了 chimera/"）或者把它收紧（"--strict 肯定更好"）。

这条对探索不适用。在一个文件上反复迭代时跑 pytest tests/test_governed_surfaces.py -x 是正确的做法；这条规则说的是你之后可以把什么称作门禁。一次收窄的运行是调试辅助手段，永远不是验证。

1. 找到这条命令被写下来的地方，并指定其中一处为权威来源。在 Chimera 里那是 Makefile 里的 check 目标——make check——因为一个 target 是可执行的，而一行文字描述只是它的一份拷贝。它跑的三项检查是 ruff check .、mypy chimera 和 pytest -q。
2. 逐字节地跑那个权威形式。不加路径参数，不加命令行选项，不换执行器。要注意，一份文字拷贝可能在看起来像是无关紧要、实际上并非如此的地方有出入：Makefile:21 把它包成 uv run --no-sync，CONTRIBUTING.md:105 包成 uv run --extra dev --extra desktop。同样的工具，不同的环境——这恰恰就是为什么必须有一处作为源头。
3. 如果两处来源不一致，就以 CI 工作流为准，跑那个，并在同一个 PR 里把过时的文档修掉——CONTRIBUTING.md 曾经有一阵子带着一行错误的 mypy --strict，而一条过时的指示会传播给每一个读到它的人。
4. 如果这条权威命令在你的环境里跑不起来，那就说门禁没有跑。在 Windows 上本地的 .venv 是坏的（litellm 需要 Rust/MSVC），所以门禁在 WSL 里跑——换 shell 是允许的，改命令不允许。
5. 把命令和它的输出原样报出来，而不是报一份"跑得怎么样"的总结。

权威命令通常是最慢的那一条，而一条禁止用快速变体的规则，会把人推向干脆什么都不跑。那比一次被诚实标注过的收窄运行更糟。

在断定这条规则很廉价之前先测量它的成本，并随着测试套件变大重新测量。这张卡片的第一稿说 Chimera 的完整套件"大约十五秒"——这个数字曾经是真的，而到写这张卡片的时候，四次测量下来已经漂移到大约 100 秒。一张讲不要临时编命令的卡片，是一个很不适合发布经不起真跑一遍的数字的地方。

而且那条 recipe 本身也可能是错的。逐字遵循它，就意味着继承它的盲区：make check 不会告诉你某个测试读取了一个被 gitignore 掉的 bench/local_lift/results/paired.json，而新克隆出来的仓库里并没有这个文件。修一个糟糕的门禁，办法是在一个 PR 里改那条 recipe，而不是私底下悄悄跑一条更好的——私下的改进只保护得了一个人，把 CI 和其他所有人都留在旧命令上。