Repository navigation
Verification
Abalassembly est un mono-fichier de 2,8 Mo : rien ne signalait une régression
avant l'ouverture dans un navigateur. Trois contrôles tournent maintenant à
chaque poussée, en une trentaine de secondes.
Workflow : .github/workflows/verify.yml · introduit en v1.25.
tools/check-scripts.js passe chaque bloc <script> inline au parseur de Node.
Une erreur dans n'importe lequel des 4 blocs casse toute l'application.
Le contrôle distingue le JavaScript des données embarquées : un bloc
application/ld+json contient du JSON, le passer au parseur JS produirait une
fausse alerte — ce qui s'est effectivement produit lors de la mise au point, et a
été corrigé. Les blocs JSON sont donc validés comme JSON.
tools/check-embedded.js décode le base64 des tablebases embarquées dans
index.html et le compare entrée par entrée aux JSON sources :
| Table | Entrées vérifiées |
|---|---|
| 2v2 | 6 264 |
| 3v2 | 17 596 |
| Arbre d'ouverture | 90 clés posRef |
Rien n'empêchait la copie inline et la donnée de référence de diverger après une édition manuelle. Désormais, si.
tablebase/audit-puzzles.js rejoue chaque puzzle avec le solveur et le classe :
offensif certifié, défensif certifié, sans solution, solution fausse, trivial.
L'audit avait révélé 6 puzzles cassés (v1.23). Brancher le contrôle tel quel
aurait rendu la CI rouge dès le premier jour — et une CI toujours rouge finit par
être ignorée. Les 6 cas ont donc été figés dans tablebase/puzzles-baseline.json,
le temps de les réparer.
C'est fait. En v1.26, les 6 ont été remplacés par des puzzles défensifs minés dans les 2 589 parties MIGS et certifiés par le solveur : menace d'éjection réelle, et seulement 1 à 3 coups sur une cinquantaine qui la parent. L'audit donne maintenant 66 offensifs certifiés, 11 défensifs certifiés, 1 trivial, zéro à corriger.
La référence est vide : la CI échoue désormais dès qu'un puzzle casse, sans aucune exception tolérée. Elle reste en place pour le cas où un futur lot de puzzles devrait être introduit progressivement.
node tablebase/audit-puzzles.js index.html --baseline tablebase/puzzles-baseline.jsonUn garde-fou qui ne casse jamais ne protège de rien. Avant la mise en ligne, les trois contrôles ont été simulés localement, dont un test négatif : en retirant deux cas de la référence, l'audit sort bien en code 1 et nomme les puzzles fautifs. Les codes de sortie ont été contrôlés un à un.
Plusieurs tests extraient un segment de rendu du vrai fichier une fois, l'écrivent dans /tmp/render_snippet*.js, puis le relisent à chaque exécution — pour éviter de re-parser le fichier de 3 Mo à chaque lancement. Mais ces fichiers /tmp survivent d'un tour de conversation à l'autre, alors que le vrai fichier continue de changer. Deux segments extraits avant l'ajout des textures de thème (v1.44) sont restés en place après : les tests qui les relisaient passaient au vert, mais contre du code qui n'existait déjà plus dans work.html — une fausse confiance totale, sans qu'aucune assertion n'échoue puisque le code testé lui-même était périmé.
Un test qui relit un fichier
/tmpextrait à un tour précédent doit être regénéré avant d'être considéré comme une preuve — surtout après une modification du code source qu'il est censé vérifier. Une extraction fraîche à chaque lancement coûte un peu de temps ; une extraction périmée ne coûte rien mais ne prouve rien non plus.
Repéré en corrigeant des tests en ricochet après l'ajout des textures de thème (v1.44) : un test passait au vert de façon suspecte alors que d'autres, plus récents, échouaient sur la même fonction — le signal qui a mené à vérifier l'âge du fichier /tmp plutôt que la logique du test lui-même.