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

プロジェクトの品質ゲート——lint、型チェック、テスト——をこれから実行し、その結果を、ある変更が安全であることの証拠として報告しようとしている場合に当てはまる。誘惑は、それを絞り込むこと(「触ったのは chimera/ だけだ」)か、厳しくすること(「--strict の方がきっと良いはずだ」)である。

探索には当てはまらない。1つのファイルを反復している最中に pytest tests/test_governed_surfaces.py -x を実行するのは正しいことだ。このルールが対象とするのは、その後それをゲートと呼んでよいかである。絞り込んだ実行はデバッグの補助であって、検証では決してない。

1. そのコマンドがどこに書き留められているかを見つけ、正典とする情報源を1つだけ指名する。Chimera ではそれは Makefile の check ターゲット——make check——である。ターゲットは実行可能であり、文章中の1行はそのコピーにすぎないからだ。それが実行する3つのチェックは ruff check .、mypy chimera、pytest -q である。
2. 正典の形をバイト単位でそのまま実行する。パス引数を足さない、フラグを足さない、ランナーを置き換えない。文章によるコピーは、見た目は些細でも実際にはそうでない差異を含みうることに注意すること。Makefile:21 はそれを uv run --no-sync で包み、CONTRIBUTING.md:105 は uv run --extra dev --extra desktop で包んでいる。同じツール、異なる環境——だからこそ、どちらか一方を情報源に定める必要がある。
3. 2つの情報源が食い違う場合は、CI のワークフローを権威として扱い、それを実行し、古くなったドキュメントを同じ PR で直すこと——CONTRIBUTING.md はしばらく誤った mypy --strict の行を抱えていた。そして古い指示は、それを読むすべての人に伝播する。
4. 正典のコマンドが自分の環境で実行できないなら、ゲートは実行されなかったと述べる。Windows ではローカルの .venv が壊れている(litellm が Rust/MSVC を要求する)ため、ゲートは WSL で実行する。シェルを移すことは許されるが、コマンドを編集することは許されない。
5. コマンドとその出力を、どうだったかの要約ではなく、そのまま報告する。

正典のコマンドはたいてい最も遅いものであり、速い変種を禁じるルールは、結局何も実行しない方へ人を押しやる。それは、絞り込んだ実行を正直にそう表示することより悪い結果だ。

ルールが安上がりだと決める前にコストを測り、スイートが育つにつれて測り直すこと。このカードの最初の草稿は、Chimera のフルスイートを「およそ15秒」と書いていた——かつては真実だった数字であり、このカードが書かれた時点では、測定した4回の実行を通じておよそ100秒まで漂流していた。コマンドをその場で作るなというカードは、コマンドを実行すれば生き残らない数字を載せるには不向きな場所である。

そしてレシピ自体が間違っていることもある。それを忠実に守ることは、その盲点も引き継ぐということだ。make check は、あるテストが、新規クローンには存在しない gitignore 済みの bench/local_lift/results/paired.json を読んでいることを教えてはくれない。悪いゲートに対する修正は、PR でレシピを変えることであって、より良いものを自分だけこっそり実行することではない——個人的な改善はたった1人を守るだけで、CI と他のみんなを古いコマンドに残す。