Déclencheurs

vérifier avant terminer
vérifier l'achèvement
tâche complétée
c'est terminé
les tests passent-ils
avant commit
avant push
avant PR
vérifier la correction
vérifier que ça fonctionne
exécuter les tests
confirmer que ça marche

Vérification Avant Achèvement

Vue d'ensemble

Prétendre qu'un travail est terminé sans vérification est de la malhonnêteté, pas de l'efficacité.

Principe fondamental : Des preuves avant les affirmations, toujours.

Violer la lettre de cette règle, c'est violer l'esprit de cette règle.

La Loi Incontournable

AUCUNE AFFIRMATION D'ACHÈVEMENT SANS PREUVE DE VÉRIFICATION FRAÎCHE

Si vous n'avez pas exécuté la commande de vérification dans ce message, vous ne pouvez pas affirmer qu'elle réussit.

La Fonction Barrière

AVANT d'affirmer un statut quelconque ou d'exprimer une satisfaction :

1. IDENTIFIER : Quelle commande prouve cette affirmation ?
2. EXÉCUTER : Lancer la commande COMPLÈTE (fraîche, complète)
3. LIRE : Sortie complète, vérifier le code de sortie, compter les échecs
4. VÉRIFIER : La sortie confirme-t-elle l'affirmation ?
   - Si NON : Énoncer le statut réel avec preuves
   - Si OUI : Énoncer l'affirmation AVEC preuves
5. SEULEMENT ENSUITE : Faire l'affirmation

Sauter une étape = mentir, pas vérifier

Échecs Courants

Affirmation	Nécessite	Insuffisant
Les tests passent	Sortie de commande de test : 0 échecs	Exécution précédente, « devrait passer »
Linter propre	Sortie du linter : 0 erreurs	Vérification partielle, extrapolation
Build réussit	Commande build : sortie 0	Linter passant, logs ont l'air bons
Bug corrigé	Test du symptôme original : réussit	Code modifié, correction supposée
Test de régression fonctionne	Cycle rouge-vert vérifié	Test réussit une fois
Agent terminé	Diff VCS montre des changements	L'agent rapporte « succès »
Exigences satisfaites	Checklist ligne par ligne	Tests passent

Drapeaux Rouges - ARRÊT

Utiliser « devrait », « probablement », « semble »
Exprimer de la satisfaction avant vérification (« Super ! », « Parfait ! », « Terminé ! », etc.)
Sur le point de committer/pousser/créer une PR sans vérification
Faire confiance aux rapports de succès de l'agent
Compter sur une vérification partielle
Penser « juste cette fois »
Être fatigué et vouloir en finir
TOUTE FORMULATION impliquant le succès sans avoir exécuté la vérification

Prévention des Rationalisations

Excuse	Réalité
« Devrait fonctionner maintenant »	EXÉCUTER la vérification
« Je suis confiant »	Confiance ≠ preuve
« Juste cette fois »	Aucune exception
« Le linter a passé »	Linter ≠ compilateur
« L'agent a dit succès »	Vérifier indépendamment
« Je suis fatigué »	Épuisement ≠ excuse
« Une vérification partielle suffit »	Partiel ne prouve rien
« Des mots différents, donc la règle ne s'applique pas »	Esprit avant lettre

Patterns Clés

Tests :

✅ [Exécuter commande de test] [Voir : 34/34 passent] « Tous les tests passent »
❌ « Devrait passer maintenant » / « Semble correct »

Tests de régression (TDD Rouge-Vert) :

✅ Écrire → Exécuter (réussit) → Annuler correction → Exécuter (DOIT ÉCHOUER) → Restaurer → Exécuter (réussit)
❌ « J'ai écrit un test de régression » (sans vérification rouge-vert)

Build :

✅ [Exécuter build] [Voir : sortie 0] « Build réussit »
❌ « Linter a passé » (le linter ne vérifie pas la compilation)

Exigences :

✅ Relire plan → Créer checklist → Vérifier chaque élément → Rapporter les lacunes ou l'achèvement
❌ « Les tests passent, phase terminée »

Délégation à agent :

✅ L'agent rapporte succès → Vérifier diff VCS → Vérifier les changements → Rapporter l'état réel
❌ Faire confiance au rapport de l'agent

Pourquoi C'est Important

D'après 24 souvenirs d'échecs :

l'utilisateur a dit « Je ne vous crois pas » - confiance brisée
Des fonctions non définies ont été déployées - aurait planté
Des exigences manquantes ont été déployées - fonctionnalités incomplètes
Temps perdu sur achèvement faux → redirection → refonte
Viole : « L'honnêteté est une valeur fondamentale. Si vous mentez, vous serez remplacé. »

Quand Appliquer

TOUJOURS avant :

TOUTE variation d'affirmations de succès/achèvement
TOUTE expression de satisfaction
TOUTE déclaration positive sur l'état du travail
Committer, créer une PR, terminer une tâche
Passer à la tâche suivante
Déléguer à des agents

La règle s'applique à :

Les formulations exactes
Les paraphrases et synonymes
Les implications de succès
TOUTE communication suggérant un achèvement/une correction

Le Résumé

Pas de raccourcis pour la vérification.

Exécuter la commande. Lire la sortie. ENSUITE affirmer le résultat.

C'est non-négociable.

Vérifier

La suite de tests a réellement été exécutée et le code de sortie/la sortie sont capturés dans la transcription, pas seulement rédigés
Les compteurs de réussite/échec sont rapportés sous forme de nombres (p. ex. « 42 réussis, 0 échoués »), pas « tous les tests réussissent »
Les nouveaux tests couvrent au moins un cas négatif/limite en plus du cas nominal ; les cas sont énumérés
Le delta de couverture ou les modules affectés sont rapportés quand le projet suit la couverture ; un nombre de base est cité
Pour les tests instables ou sensibles au timing, la série a été répétée au moins 3 fois et le taux de réussite est rapporté
Tous les tests ignorés ou xfail introduits sont énumérés avec une raison et un lien vers issue/TODO

verification-before-completion