[stephrobert]

Deux corrections venues des catalogues Bases de données et GitLab CI, où elles ont été trouvées et éprouvées le 2026-10-22. Elles sont posées à l'identique dans tous les catalogues.

1. Un verdict ne se commite pas avec ce qu'il mesure

La péremption d'un verdict se jugeait en comparant des dates : un lab était « à réattester » dès qu'un commit postérieur touchait ses fichiers. Cette comparaison répond à une autre question que celle qu'on pose, et elle s'est trompée dans les deux sens le même jour.

Faux négatif, le sens dangereux. Une correction du code partagé et les verdicts qu'elle rendait caducs ont été commités ensemble. Aucun verdict n'était postérieur à quoi que ce soit, le contrôle a conclu que tout allait bien, et vingt et un verdicts VALIDE ne valaient plus rien.

Faux positif. Des labs réattestés sur une branche sont ressortis « à réattester » après leur fusion, parce que le squash écrase la branche en un commit daté de la fusion. Contenu inchangé. Systématique dans tout dépôt qui fusionne ainsi.

Le contrôle qui fait foi compare désormais deux arbres git côté site, ce qui ne dépend plus de la façon de fusionner. Mais un cas échappe à toute mesure a posteriori : une pull request squashée qui retouche un test après sa campagne. Le commit unique porte les deux et le squash a détruit ce qui les distinguait — ni une date, ni un diff entre deux arbres, ni une empreinte inscrite ensuite ne peuvent dire lequel est venu avant.

Il ne se constate donc pas, il s'empêche. Le hook refuse un commit portant validation-labs.json à côté de ce que le cycle joue : challenge/tests/, setup.yaml, cleanup.yaml, lab.yaml d'un lab, et l'outillage partagé. L'énoncé reste autorisé : il n'est pas joué par le cycle, et l'interdire obligerait à une campagne pour une coquille d'orthographe.

2. Un contrôle Plumber qui ne contrôle plus rien

pipelineMustNotLeakSecretsInConfig a été retiré de Plumber, qui répond désormais « was removed and is now ignored: secret detection is no longer part of Plumber; remove this block ». Il était déclaré deux fois, dans les sections gitlab et github. Le garder laissait croire que la détection de secrets est couverte ici. Elle ne l'est pas, et c'est detect-private-key qui s'en approche, en hook.

Contrôles joués

• 14 tests sur le garde-fou, les deux sens couverts : ce qu'il doit refuser (relevé + commun, + outillage, + test, + setup, + cleanup, + lab.yaml) et ce qu'il doit laisser passer (chacun seul, relevé + énoncé, rien du tout).
• Éprouvé en le forçant à tout refuser : les cas légitimes tombent alors. Un contrôle qu'on n'a pas vu échouer ne mesure rien.
• Le test est lancé par son propre hook, et pas seulement présent : plusieurs catalogues ont refusé le premier jet pour cette raison exacte, et ils avaient raison — un vérificateur débranché ne protège rien en silence.
• .plumber.yaml et .pre-commit-config.yaml rechargés après modification : les deux se parsent, et le hook n'est déclaré qu'une fois.
• La chaîne de hooks de ce dépôt est passée en entier au commit, sans quoi il aurait été refusé.
• N/A Aucun lab, test de lab ni solution touché : validation-labs.json est inchangé et les verdicts restent valides.
• N/A Pas de bump : ce commit ne change rien de ce qu'un lab prouve.