Aktualizacje i automatyczne odzyskiwanie

Niniejszy rozdział opisuje mechanizmy stojące za procesami opisanymi w przewodniku Aktualizacja i automatyczne odzyskiwanie w środowiskach macOS (maszyna Lima) oraz Windows (WSL2).

Maszyna stanów instalacji i uzgadniania wersji (reconciliation)

Po zatwierdzeniu aktualizacji procedura install_update_and_reconcile(expectedVersion) rejestruje aktywne projekty, bezpiecznie zatrzymuje działające kontenery, wdraża podpisane pliki binarne i restartuje aplikację. W przypadku niepowodzenia instalacji poprzedni stan aktywnych projektów zostaje automatycznie przywrócony.

Po restarcie proces porównuje identyfikator bundle_id nowej paczki ze stanem zapisanym w konfiguracji. Wykrycie różnic uruchamia idempotencją maszynę stanów:

1. Synchronizuje zasoby claude-resources do lokalnych katalogów trwałych.
2. Kompiluje obrazy kontenerów, którym brakuje deterministycznego tagu skrótu.
3. Transakcyjnie odtwarza (--force-recreate) kontenery projektów aktywnych przed aktualizacją.

Kompilacja obrazów bazuje na niezależnych skrótach kryptograficznych wyliczanych dla każdego pliku Containerfile oraz jego lokalnych źródeł:

Zdarzenie wyzwalające	Skutek architektoniczny
Brak tagu skrótu	Przebudowa wyłącznie wskazanego obrazu kontenera.
Zmiana we wspólnym module bazowym MCP	Przebudowa wszystkich zależnych kontenerów workerów.
Aktualizacja claude-resources	Synchronizacja zasobów promptów i markdown bez rekompilacji obrazów.

Haszowanie źródeł kompilacji

Tagi kryptograficzne obejmują lokalne pliki źródłowe i definicje Containerfile, umożliwiając efektywne buforowanie bez konieczności blokowania zewnętrznych obrazów bazowych.

Automatyczne odzyskiwanie sprawności kontenerów

Speedwave automatycznie naprawia nieaktualne punkty montowania po uśpieniu systemu oraz przywraca brakujące kontenery po restartach demona containerd. Przed rozpoczęciem każdej sesji interaktywnej funkcja ensure_exec_healthy wykonuje test kontenera Claude:

• Przeprowadza testową próbę wykonania polecenia.
• W przypadku błędu montowania lub braku kontenera wymusza jego odtworzenie.
• Ponawia weryfikację, a w razie trwałego błędu wyświetla jednoznaczny komunikat diagnostyczny.

W systemie Windows mechanizm diagnostyczny bezpośrednio monitoruje stan podsystemu WSL2, weryfikując demony containerd oraz buildkitd i automatycznie wznawiając ich pracę.

Na obu platformach próba wykonania polecenia oraz weryfikacja logowania (działające w tym samym kontenerze) mają 60-sekundowy limit czasu. Dzięki temu w razie zawieszenia środowiska kontenerowego interfejs wyświetla błąd z opcją ponowienia próby.

Samonaprawa silnika kontenerów

Każde polecenie compose up działa wewnątrz maszyny wirtualnej z limitem 180 sekund. Po jego upływie cała grupa procesów nerdctl zostaje zatrzymana, a generowany błąd ma postać compose up did not finish within 180s. Speedwave automatycznie radzi sobie z dwoma stanami wyścigu (race conditions) w silniku kontenerów:

• Stan wyścigu przy tworzeniu zadania: monitor restartów containerd może uruchomić kontener proxy w tej samej chwili, w której tworzy go compose up. W rezultacie jedno z żądań kończy się błędem file exists lub already exists. Speedwave po krótkiej chwili ponawia próbę; restart pojedynczej usługi korzysta wtedy z kontenera uruchomionego przez proces równoległy.
• Osierocone łańcuchy sieciowe: kontener, który uległ awarii, może pozostawić po sobie łańcuch iptables blokujący kolejny start. Speedwave usuwa łańcuch wskazany w błędzie i ponawia próbę.

Brak odpowiedzi maszyny wirtualnej jest zgłaszany jednoznacznie (Container engine did not answer the image check), a nie jako brak obrazów, więc przycisk Retry powtarza sprawdzenie bez ponownego budowania. Odczyt stanu maszyny wirtualnej ma limit 10 sekund, a nieudana próba odczytu nigdy nie jest traktowana jako brak samej maszyny. Zamknięcie aplikacji oraz reset do ustawień fabrycznych trwale zatrzymują silnik: start oczekujący w kolejce nie przywróci kontenerów w trakcie procedury wyłączania.

Transakcyjny cykl aktualizacji w CLI

Polecenie speedwave update (zobacz Polecenia CLI) realizuje pełny rygor transakcyjny:

1. Weryfikuje uprawnienia systemu plików na hoście.
2. Przeprowadza audyt bezpieczeństwa SecurityCheck.
3. Kompiluje brakujące warstwy kontenerowe.
4. Tworzy atomową migawkę konfiguracji (~/.speedwave/snapshots/<projekt>/snapshot.json).
5. Odtwarza kontenery i weryfikuje dostępność gniazd sieciowych.
6. Usuwa przestarzałe tagi obrazów, zachowując pamięć podręczną BuildKit.

W przypadku niepowodzenia aktualizacji Speedwave automatycznie przywraca środowisko z zarejestrowanej migawki.

W systemie Windows instalator NSIS rozpoczyna każdą instalację i aktualizację od oczyszczenia środowiska: jeśli Speedwave zainstalowano w domyślnym folderze, a aplikacja nie jest uruchomiona, instalator usuwa foldery build-context, mcp-os, oauth, THIRD-PARTY-LICENSES oraz host_exec, a dopiero potem kopiuje nową wersję. Dzięki temu pliki usunięte w nowym wydaniu nie trafią do nowo budowanych obrazów. Weryfikację kryptograficzną opisano w rozdziale Autentyczność plików binarnych.