Standardowe ścieżki konfiguracji i naprawy opisano w dokumentacji instalacji, CLI i Gateway. Ścieżki specyficzne dla platformy Windows są uwzględnione w wierszach Windows przez WSL2 i Natywny Windows.

Podstawowa architektura, uwierzytelnianie, parowanie, dokumentacja protokołu i demona oraz procedury CLI są obszerne i aktualne.

Główna pętla, modele, trasowanie dostawców i strumieniowanie narzędzi są pełnoprawnymi elementami, ale zachowanie dostawców zmienia się co tydzień i wymaga potwierdzenia scenariuszami dla każdego wydania.

Dobra dokumentacja i aktywny rozwój implementacji. Dojrzałość zależy od trwałości transkrypcji, jakości Compaction oraz spójności między klientami.

Wiele kanałów korzysta ze wspólnych umów dostarczania i routingu Gateway, ale ich działanie różni się w zależności od nadrzędnego API oraz ograniczeń zasad dotyczących kont.

Dokumentacja OTel, Prometheus, rejestrowania zdarzeń i diagnostyki jest dostępna. Wymaga publicznego dopracowania pod kątem dojrzałości, wskazującego, „na co operatorzy powinni zwrócić uwagę w pierwszej kolejności”.

Interfejs WWW jest udokumentowany wraz z procesami parowania, czatu, PWA, Talk, powiadomień push i zdalnego Gateway. Awansuj poziom dojrzałości po przygotowaniu kart wyników dla różnych przeglądarek i mobilnych aplikacji PWA.

Dostępna jest obszerna dokumentacja oraz mocne wewnętrzne dowody dotyczące działania środowiska wykonawczego w zakresie manifestów, wykrywania, ładowania, architektury dostawców i narzędzi oraz granic zatwierdzania. Należy utrzymać ten wiersz na poziomie beta, dopóki dowody dotyczące publicznego API SDK, jego podścieżek i zewnętrznej dystrybucji nie będą mocniejsze.

Dostępna jest dobra dokumentacja i mechanizmy wzmacniania zabezpieczeń. Awansuj poziom dojrzałości, gdy regularne scenariusze aktualizacji i bezpieczeństwa potwierdzą brak regresji konfiguracji.

Funkcje są udokumentowane i użyteczne, ale scenariusze testowe powinny obejmować dostarczanie bez nadzoru, ponawianie prób oraz widoczność awarii.

Dostępny jest szeroki zakres możliwości, ale różnice między dostawcami, limity plików oraz brak równoważności między Node i aplikacjami sprawiają, że rozwiązanie nie jest jeszcze stabilne.

W interfejsie Control UI, aplikacjach i u dostawców istnieje wiele implementacji. Przed wersją beta potrzebne są karty oceny opóźnień, trybów awarii i konfiguracji.

Obecne w dokumentacji i kodzie źródłowym, lecz mniej widoczne jako podstawowy przepływ pracy użytkownika. Wymaga jednoznacznego zdefiniowania scenariusza.

Istnieją publiczna dokumentacja i koncepcja ekosystemu. Potrzebne są karty ocen instalacji, zaufania, aktualizacji, wycofywania zmian i zgodności.

OpenClaw App SDK jest odrębnym kontraktem dla aplikacji zewnętrznych, niezależnym od środowiska uruchomieniowego Gateway i Plugin SDK. Obecna punktacja wskazuje na rzeczywistą ścieżkę @openclaw/sdk, ale ujawnia braki w zakresie publicznego pakietowania, automatycznego wykrywania, zatwierdzeń, funkcji pomocniczych i zgodności.

Zalecane jest środowisko uruchomieniowe Node, udokumentowano usługę użytkownika systemd, a wskazówki dotyczące VPS i kontenerów są obszerne.

Udokumentowano ścieżkę usługi LaunchAgent, lokalny i zdalny tryb Gateway, instalację CLI oraz integrację z aplikacją.

Dostępna jest oficjalna dystrybucja w Google Play, dokumentacja kompilowania i uruchamiania ze źródeł jest utrzymywana, a aplikacja na Androida jest udokumentowana jako standardowy węzeł towarzyszący dla użytkowników.

Dostępna jest oficjalna dystrybucja w App Store, udokumentowano powiadomienia push obsługiwane przez przekaźnik, a aplikację iOS opisano jako standardowy węzeł towarzyszący dla użytkowników.

Dokumentacja instalacji jest dostępna, a opisane w niej sposoby wdrażania są powszechnie stosowane. Awans po uwzględnieniu zachowania podczas aktualizacji i obsługi woluminów w cyklicznych testach dymnych wersji.

Zalecana ścieżka dla systemu Windows z wytycznymi dotyczącymi systemd/usług użytkownika i dokumentacją łańcucha rozruchowego. Awans po wielokrotnych pozytywnych ocenach instalacji i aktualizacji.

Dokumentacja platformy jest dostępna, a ścieżka Gateway opiera się na systemie Linux. Przejście na wyższy poziom wymaga testu dymnego wydania przeprowadzonego na odpowiednim sprzęcie.

Dostępne są rozbudowana aplikacja na pasku menu, uprawnienia, tryb Node, Canvas, aktywacja głosowa, WebChat i tryb zdalny. Rozwój nadal przebiega na tyle dynamicznie, że nie należy jeszcze nadawać poziomu stabilnego.

Podstawowe przepływy CLI/Gateway działają, ale dokumentacja nadal zaleca WSL2, aby uzyskać pełną funkcjonalność, i wymienia ograniczenia środowiska natywnego.

Hosting w Kubernetes jest odrębną ścieżką wdrażania klastra opartą na Kustomize. Obecna ocena wskazuje na rzeczywistą, minimalną ścieżkę wdrożenia, w której nadal występują braki dotyczące CI przeznaczonego dla Kubernetes, pakietowania ingress/TLS/NetworkPolicy, tworzenia i przywracania kopii zapasowych oraz zabezpieczenia udostępnienia w środowisku produkcyjnym.

Opcjonalny proces instalacji. Przed awansem do wersji alfa/beta wymaga jaśniejszej deklaracji zakresu wsparcia.

Kod źródłowy zawiera powierzchnie aplikacji i rozszerzenia dla Apple Watch; dokumentacja publiczna nie przedstawia ich jeszcze jako funkcji użytkowej.

Dokumentacja informuje, że natywne aplikacje towarzyszące dla systemu Linux są planowane; obecnie obsługiwaną ścieżką w systemie Linux jest Gateway.

Dopiero w planach.

Szczegółowa dokumentacja i szerokie pokrycie funkcji. Ścieżki głosowe i delegowania powinny nadal być oceniane oddzielnie jako beta/alfa.

Podstawowy kanał jest wystarczająco dojrzały do regularnego użytku, ale przypadki brzegowe związane z interfejsem użytkownika o dużej zmienności oraz multimediami wymagają cyklicznego potwierdzania za pomocą scenariuszy.

Pełnoprawna dokumentacja kanału i mechanizm trasowania. Wymaga kart oceny scenariuszy instalacji w obszarze roboczym i administracji.

Obsługiwany iMessage działa za pośrednictwem imsg na hoście macOS z zalogowaną aplikacją Messages; starsze konfiguracje BlueBubbles wymagają migracji. Należy wyraźnie informować o uprawnieniach macOS, wrapperze SSH, interfejsie SIP/prywatnym API oraz zastrzeżeniach dotyczących migracji.

Główna ścieżka jest ważna i udokumentowana; zmienność nadrzędnego rozwiązania Baileys i sesji utrzymuje ją poniżej poziomu stabilnego.

Obsługiwane za pośrednictwem dołączonego Pluginu. Wymaga kart oceny mostu, uwierzytelniania i cyklu życia pokoju.

Kanał jest udokumentowany, ale konfiguracja na poziomie przedsiębiorstwa i administratora zwiększa ryzyko związane z dojrzałością.

Przepływy uwierzytelniania i administracji w przedsiębiorstwie wymagają jednoznacznego potwierdzenia scenariuszami.

Dokumentacja obsługiwanego kanału jest dostępna; potrzebne są solidniejsze dowody instalacji i ponownego łączenia.

Istotne pokrycie regionalne, ale poziom publicznego wsparcia należy dostosować do typu konta, zatwierdzenia przez dostawcę zewnętrznego oraz dowodów przedstawionych przez opiekunów.

Obsługiwane powierzchnie są dostępne, ale poziom dojrzałości prawdopodobnie zależy od pokrycia po stronie projektów nadrzędnych i opiekunów. Później należy ocenić je indywidualnie.

Opcjonalna ścieżka/ścieżka Pluginu o złożonym działaniu w czasie rzeczywistym. Przed publiczną wersją beta wymaga karty oceny scenariuszy.

Podstawowe narzędzia są udokumentowane, ale bezpieczeństwo hosta i środowisko obsługi uprawnień powinny nadal podlegać aktywnemu przeglądowi w karcie oceny.

Szczegółowa dokumentacja, ścieżka OAuth/subskrypcji, głos w czasie rzeczywistym, obrazy oraz zachowanie zgodności. Częste zmiany dostawcy uniemożliwiają osiągnięcie poziomu stabilnego bez potwierdzenia w karcie wyników wydania.

Dostępnych jest wielu dostawców oraz dokumentacja. Wymagane jest potwierdzenie obsługi limitów, błędów i ochrony przed SSRF dla każdej rodziny dostawców.

Pełnoprawny dostawca modeli. Wymaga cyklicznego potwierdzania scenariuszy uwierzytelniania, katalogu i wywoływania narzędzi.