[stephrobert]

Ce que sept catalogues neufs ont révélé

Créés le 2026-10-17 par new catalog 0.5.1, ils portaient deux appels au moteur, aucun borné :

.github/workflows/ci.yml      uv tool install dsoxlab
.pre-commit-config.yaml       entry: dsoxlab validate-structure

Le second est le pire : il emploie le dsoxlab du PATH, c'est-à-dire ce qui traîne sur la machine du contributeur.

Les douze catalogues établis venaient d'être alignés sur uvx 'dsoxlab>=0.5.0' le même jour. Tout catalogue neuf naissait donc avec la dette qu'on venait de solder, et sous une forme que la correction ne couvrait pas : elle cherchait uvx dsoxlab, pas uv tool install ni entry:.

Quelle borne, et pourquoi celle-là

La version qui écrit le catalogue : la seule affirmable sans analyser son contenu. Un socle produit par la 0.5.2 suppose au moins la 0.5.2. Une valeur figée dans le gabarit se périmerait au premier contrat qui gagne un champ, ce qui est exactement le défaut corrigé.

C'est la version installée qui est lue, par importlib.metadata, et non celle du pyproject.toml. Juste après ce bump, le socle borne donc encore à 0.5.1 jusqu'à réinstallation du tool. C'est voulu : la borne doit nommer un moteur qui existe sur PyPI, pas un numéro qu'aucun uvx ne saurait satisfaire.

Les uv tool install dsoxlab des README et des CONTRIBUTING restent nus à dessein : ils s'adressent à un apprenant, qui doit prendre la dernière version. Ce sont des instructions, pas des appels.

Le garde-fou annonçait un accord en écartant un tiers du disque

scripts/gen-catalogues.py --mesurer répondait « manifeste en accord avec le disque (12 catalogues) » quand le disque en portait dix-neuf. Une seule ligne, if labs:, sautait en silence tout catalogue sans lab.

Le filtre se défend : dsoxlab catalog list n'a rien à proposer d'un catalogue vide. Le message, non. Et c'est le défaut même que ce script existait pour empêcher : la liste avait déjà été écrite une fois avec six entrées quand le disque en portait douze, et 901 messages avaient été sautés sans qu'aucun contrôle le dise. Partir du disque ne suffit pas, il faut dire ce qu'on en écarte.

Un second défaut se cachait derrière le premier : un catalogue inscrit au manifeste qui tombait à zéro lab était signalé « introuvable sur le disque : vérifie qu'il n'a pas été renommé », envoyant chercher un renommage qui n'avait pas eu lieu.

Deux cliquets, prouvés par trois mutations

tests/test_socle_du_catalogue.py refuse tout appel non borné dans ce que le socle exécute, et vérifie que la borne vaut la version du moteur et non une valeur figée. Les commentaires qui citent uvx dsoxlab pour expliquer pourquoi on ne l'emploie pas sont exemptés, sans quoi la justification serait impossible à écrire.

mutation	effet
le CI revient à l'appel nu	rouge
le hook revient au moteur du PATH	rouge
une borne figée au gabarit	rouge

Les deux premières sont les défauts exactement observés sur les sept catalogues.

Vérifié

pytest tests/                    1611 passed
tests du socle                   19 passed, dont 2 nouveaux
ruff check src/ tests/ scripts/  All checks passed
mypy src/dsoxlab/                97 fichiers, aucune erreur
complexite / code-mort / écran   les trois cliquets verts
gen-catalogues.py --mesurer      nomme les 7, compare les 12
uv lock                          0.5.1 → 0.5.2

🤖 Generated with Claude Code