Die regulären Einrichtungs- und Reparaturpfade sind in der Installations-, CLI- und Gateway-Dokumentation beschrieben. Plattformspezifische Windows-Pfade werden in den Zeilen „Windows über WSL2“ und „Natives Windows“ erfasst.

Kernarchitektur, Authentifizierung, Kopplung, Protokolldokumentation, Daemon-Dokumentation und CLI-Betriebshandbücher sind umfassend und aktuell.

Hauptschleife, Modelle, Provider-Routing und Tool-Streaming sind zentrale Funktionen, doch das Provider-Verhalten ändert sich wöchentlich und erfordert für jede Veröffentlichung einen Szenarionachweis.

Umfassende Dokumentation und aktive Implementierung. Der Reifegrad hängt von der Beständigkeit der Transkripte, der Qualität der Compaction und der Gleichwertigkeit über verschiedene Clients hinweg ab.

Viele Kanäle nutzen gemeinsame Gateway-Verträge für Zustellung und Routing, das Verhalten der Kanäle variiert jedoch aufgrund der jeweiligen Upstream-API und der Einschränkungen durch Kontorichtlinien.

Dokumentation zu OTel, Prometheus, Protokollierung und Diagnose ist vorhanden. Es bedarf einer öffentlich zugänglichen, ausgereifteren Übersicht darüber, worauf Betreiber zuerst achten sollten.

Die Web-Benutzeroberfläche ist mit Kopplungs-, Chat-, PWA-, Talk-, Push- und Remote-Gateway-Abläufen dokumentiert. Hochstufung nach Abschluss der Bewertungsübersichten für browserübergreifende Kompatibilität und mobile PWAs.

Für Manifeste, Erkennung, Laden, die Provider-/Tool-Architektur und Genehmigungsgrenzen sind eine umfassende Dokumentation und aussagekräftige interne Laufzeitnachweise vorhanden. Behalten Sie die Einstufung der Zeile als Beta bei, bis die Nachweise für die öffentliche SDK-API und ihre Unterpfade sowie für die externe Distribution aussagekräftiger sind.

Gute Dokumentation und Härtungsmechanismen sind vorhanden. Eine Hochstufung sollte erfolgen, nachdem regelmäßige Upgrade- und Sicherheitsszenarien nachgewiesen haben, dass keine Einrichtungsregressionen auftreten.

Dokumentiert und verwendbar, doch der Szenariennachweis sollte unbeaufsichtigte Zustellung, Wiederholungsversuche und die Sichtbarkeit von Fehlern abdecken.

Es steht ein breites Funktionsspektrum zur Verfügung, aber Unterschiede zwischen Providern, Dateibeschränkungen und die Parität zwischen Node und App verhindern derzeit noch einen stabilen Status.

Es existieren mehrere Implementierungen in der Control UI, in Apps und bei Providern. Vor der Beta sind Scorecards für Latenz, Fehlermodi und Einrichtung erforderlich.

In der Dokumentation und im Quellcode vorhanden, aber als primärer Benutzerworkflow weniger sichtbar. Eine explizite Szenariodefinition ist erforderlich.

Öffentliche Dokumentation und ein Ökosystemkonzept sind vorhanden. Benötigt Scorecards für Installation, Vertrauenswürdigkeit, Aktualisierung, Rollback und Kompatibilität.

Das OpenClaw App SDK ist ein eigenständiger Vertrag für externe Apps, der von der Gateway-Laufzeit und dem Plugin SDK getrennt ist. Die aktuelle Bewertung zeigt einen realen @openclaw/sdk-Pfad mit Lücken bei der öffentlichen Paketierung, automatischen Erkennung, Genehmigungen, Hilfsfunktionen und Kompatibilität.

Die Node-Laufzeit wird empfohlen, der systemd-Benutzerdienst ist dokumentiert und die Anleitung für VPS und Container ist umfassend.

Der LaunchAgent-Dienstpfad, lokale und entfernte Gateway-Modi, die CLI-Installation und die App-Integration sind dokumentiert.

Eine offizielle Distribution über Google Play ist verfügbar, die Dokumentation zum Erstellen und Ausführen aus dem Quellcode wird gepflegt, und die Android-App ist für Benutzer als regulärer Begleit-Node dokumentiert.

Eine offizielle Verteilung über den App Store ist verfügbar, Relay-gestützte Push-Benachrichtigungen sind dokumentiert und die iOS-App wird für Benutzer als normaler begleitender Node dokumentiert.

Installationsdokumentation ist vorhanden, und diese Bereitstellungswege sind weit verbreitet. Hochstufen, sobald wiederkehrende Smoke-Tests für Releases das Upgrade- und Volume-Verhalten erfassen.

Empfohlener Windows-Pfad mit Anleitungen für systemd/Benutzerdienste und Dokumentation zur Boot-Kette. Nach wiederholten Bewertungen für Installation und Aktualisierung hochstufen.

Plattformdokumentation ist vorhanden, und der Gateway-Pfad basiert auf Linux. Für eine höhere Einstufung ist ein hardwarespezifischer Smoke-Test als Release-Nachweis erforderlich.

Eine umfangreiche Menüleisten-App, Berechtigungen, Node-Modus, Canvas, Sprachaktivierung, WebChat und Fernzugriffsmodus sind vorhanden. Die Entwicklung schreitet jedoch noch zu schnell voran, um die Einstufung „Stabil“ zu rechtfertigen.

Die zentralen CLI-/Gateway-Abläufe funktionieren, aber die Dokumentation empfiehlt für den vollständigen Funktionsumfang weiterhin WSL2 und führt Einschränkungen bei der nativen Nutzung auf.

Kubernetes-Hosting ist ein eigenständiger, auf Kustomize basierender Bereitstellungspfad für Cluster. Die aktuelle Bewertung zeigt einen echten minimalen Bereitstellungspfad mit Lücken bei Kubernetes-spezifischer CI, der Paketierung von Ingress/TLS/NetworkPolicy, Sicherung/Wiederherstellung und der Absicherung der Produktionsbereitstellung.

Optionaler Installationsablauf. Vor der Hochstufung auf Alpha/Beta ist eine klarere Supportzusage erforderlich.

Der Quellcode enthält Oberflächen für eine Watch-App/-Erweiterung; die öffentliche Dokumentation stellt dies noch nicht als Benutzerfunktion vor.

Laut Dokumentation sind native Linux-Begleit-Apps geplant; der Gateway ist derzeit der unterstützte Weg unter Linux.

Nur geplant.

Ausführliche Dokumentation und breite Funktionsabdeckung. Sprach- und Delegationspfade sollten weiterhin separat als Beta/Alpha bewertet werden.

Der Kernkanal ist ausgereift genug für den regelmäßigen Einsatz, doch stark variierende Benutzererfahrungen und Grenzfälle bei Medien erfordern wiederkehrende Szenarionachweise.

Erstklassige Kanaldokumentation und Weiterleitungsoberfläche. Benötigt Scorecards für Szenarien zur Workspace-Installation und -Administration.

Das unterstützte iMessage wird über imsg auf einem macOS-Messages-Host mit angemeldetem Konto ausgeführt; ältere BlueBubbles-Konfigurationen müssen migriert werden. Halten Sie Hinweise zu macOS-Berechtigungen, dem SSH-Wrapper, SIP/privaten APIs und zur Migration gut sichtbar.

Der Kernpfad ist wichtig und dokumentiert; aufgrund der Volatilität von Baileys und Sitzungen bleibt er unterhalb von Stabil.

Wird über ein gebündeltes Plugin unterstützt. Benötigt Scorecards für Bridge, Authentifizierung und Raumlebenszyklus.

Dokumentierter Kanal, doch die Unternehmens-/Administratoreinrichtung erhöht das Reiferisiko.

Authentifizierungs- und Administratorabläufe für Unternehmen erfordern explizite Szenariennachweise.

Dokumentation für den unterstützten Kanal ist vorhanden; es sind aussagekräftigere Nachweise für Installation und Wiederverbindung erforderlich.

Wichtige regionale Abdeckung, die öffentliche Unterstützungsstufe sollte jedoch je nach Kontotyp, Genehmigung durch das Upstream-Projekt und Nachweis durch die Maintainer festgelegt werden.