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

Vous vous apprêtez à lancer la barrière qualité du projet — lint, vérification de types, tests — et à en rapporter le résultat comme preuve qu'un changement est sûr. La tentation est de la restreindre (« je n'ai touché qu'à chimera/ ») ou de la durcir (« --strict est sûrement mieux »).

Cela ne s'applique pas à l'exploration. Lancer pytest tests/test_governed_surfaces.py -x pendant qu'on itère sur un fichier est exactement ce qu'il faut faire ; la règle porte sur ce que vous avez ensuite le droit d'appeler la barrière. Une exécution restreinte est une aide au débogage, jamais la vérification.

1. Trouvez où la commande est écrite, et désignez UNE source comme canonique. Dans Chimera, c'est la cible check du Makefile — make check — parce qu'une cible est exécutable alors qu'une ligne en prose n'en est qu'une copie. Les trois vérifications qu'elle lance sont ruff check ., mypy chimera et pytest -q.
2. Lancez la forme canonique octet pour octet. Pas d'argument de chemin ajouté, pas de flag ajouté, pas de lanceur substitué. Attention : une copie en prose peut différer de façons qui semblent cosmétiques et ne le sont pas : Makefile:21 l'enveloppe en uv run --no-sync, CONTRIBUTING.md:105 en uv run --extra dev --extra desktop. Même outil, environnements différents — ce qui est précisément pourquoi l'une des deux doit être la source.
3. Si deux sources divergent, considérez le workflow de CI comme faisant autorité, lancez celui-là, et corrigez le document obsolète dans la même PR — CONTRIBUTING.md a porté une ligne mypy --strict erronée pendant un temps, et une instruction obsolète se propage à tous ceux qui la lisent.
4. Si la commande canonique ne peut pas s'exécuter dans votre environnement, dites que la barrière n'a pas été passée. Sous Windows, le .venv local est cassé (litellm réclame Rust/MSVC), la barrière tourne donc dans WSL — déplacer le shell est permis, modifier la commande ne l'est pas.
5. Rapportez la commande et sa sortie telles quelles, pas un résumé de la façon dont ça s'est passé.

La commande canonique est en général la plus lente, et une règle qui interdit la variante rapide pousse à ne rien lancer du tout. C'est un résultat pire qu'une exécution restreinte honnêtement étiquetée.

Mesurez le coût avant de décider que la règle est bon marché, et remesurez à mesure que la suite grossit. Le premier jet de cette carte affirmait que la suite complète de Chimera prenait « une quinzaine de secondes » — un chiffre vrai à un moment donné, qui avait dérivé vers environ 100 secondes sur quatre exécutions mesurées au moment où la carte a été écrite. Une carte sur le fait de ne pas improviser les commandes est un mauvais endroit pour publier un chiffre qui ne survit pas à l'exécution de la commande.

Et la recette elle-même peut être fausse. La suivre à la lettre, c'est hériter de ses angles morts : make check ne vous dira pas qu'un test lit un bench/local_lift/results/paired.json ignoré par git qu'un clone frais n'a pas. Le remède à une mauvaise barrière est de changer la recette dans une PR, pas de faire tourner discrètement une meilleure version privée — une amélioration privée protège exactement une personne et laisse la CI, et tous les autres, sur l'ancienne commande.