Normale Einrichtungs- und Reparaturpfade sind in den Installations-, CLI- und Gateway-Dokumenten dokumentiert. Plattformspezifische Windows-Pfade werden in den Zeilen „Windows über WSL2“ und „Natives Windows“ verfolgt.

Kernarchitektur, Auth, Kopplung, Protokolldokumentation, Daemon-Dokumentation und CLI-Runbooks sind umfassend und aktuell.

Main Loop, Modelle, Provider-Routing und Tool-Streaming sind erstklassig unterstützt, aber das Provider-Verhalten ändert sich wöchentlich und erfordert Szenario-Nachweise pro Release.

Solide Dokumentation und aktive Implementierung. Die Reife hängt von der Dauerhaftigkeit der Transkripte, der Qualität der Compaction und der Parität über Clients hinweg ab.

Viele Kanäle teilen Gateway-Zustellungs- und Routing-Verträge, aber das Kanalverhalten variiert je nach Upstream-API und Einschränkungen durch Kontorichtlinien.

Dokumentation zu OTel, Prometheus, Logging und Diagnose ist vorhanden. Benötigt einen öffentlichen Reifegrad-Durchlauf dazu, „worauf Betreiber zuerst achten sollten“.

Die Web-UI ist mit Pairing-, Chat-, PWA-, Talk-, Push- und Remote-Gateway-Flows dokumentiert. Nach Cross-Browser- und Mobil-PWA-Scorecards hochstufen.

Umfassende Dokumentation und starke interne Runtime-Nachweise liegen über Manifeste, Discovery, Laden, Provider-/Tool-Architektur und Freigabegrenzen hinweg vor. Belassen Sie die Zeile auf Beta, bis die öffentliche SDK-API/-Unterpfade und Nachweise für externe Distribution stärker sind.

Gute Dokumentation und Härtungsflächen sind vorhanden. Nach regelmäßigen Upgrade- und Sicherheitsszenario-Läufen hochstufen, wenn diese keine Setup-Regressionen nachweisen.

Dokumentiert und nutzbar, aber Szenarionachweise sollten unbeaufsichtigte Zustellung, Wiederholungen und Sichtbarkeit von Fehlern abdecken.

Eine breite Fähigkeitsoberfläche ist vorhanden, aber Provider-Unterschiede, Dateibeschränkungen und Parität zwischen Node und App machen dies noch nicht stabil.

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

In Dokumentation und Quellcode vorhanden, aber als primärer Benutzerworkflow weniger sichtbar. Benötigt eine explizite Szenariodefinition.

Öffentliche Dokumentation und Ökosystemkonzept existieren. Installation, Vertrauen, Aktualisierung, Rollback und Kompatibilitäts-Scorecards werden benötigt.

OpenClaw App SDK ist ein eigenständiger externer App-Vertrag, getrennt von Gateway-Laufzeit und Plugin SDK. Die aktuelle Bewertung zeigt einen realen @openclaw/sdk-Pfad mit Lücken bei öffentlicher Paketierung, automatischer Erkennung, Genehmigungen, Hilfsfunktionen und Kompatibilität.

Node-Laufzeit wird empfohlen, systemd-Benutzerdienst ist dokumentiert, und VPS-/Container-Anleitung ist breit angelegt.

LaunchAgent-Dienstpfad, lokale/Remote-Gateway-Modi, CLI-Installation und App-Integration sind dokumentiert.

Installationsdokumentation ist vorhanden und umfasst gängige Bereitstellungspfade. Hochstufen, nachdem wiederkehrende Release-Smokes Upgrade- und Volume-Verhalten erfassen.

Empfohlener Windows-Pfad mit systemd-/Benutzerdienst-Anleitung und Boot-Chain-Dokumentation. Nach wiederholten Installations-/Update-Scorecards hochstufen.

Plattformdokumentation ist vorhanden, und der Gateway-Pfad basiert auf Linux. Erfordert hardwarebezogenen Release-Smoke-Proof, um höher eingestuft zu werden.

Eine umfangreiche Menüleisten-App, Berechtigungen, Node-Modus, Canvas, Sprachaktivierung, WebChat und Remote-Modus sind vorhanden. Sie entwickelt sich noch schnell genug, um Stable zu vermeiden.

Öffentlicher Google Play-Pfad existiert, aber die App-Dokumentation beschreibt den Rebuild weiterhin als extrem Alpha und weist auf Arbeiten zur Release-Härtung hin.

Die zentralen CLI-/Gateway-Abläufe funktionieren, aber die Dokumentation empfiehlt weiterhin WSL2 für die vollständige Nutzung und führt native Einschränkungen auf.

Kubernetes-Hosting ist ein eigenständiger, Kustomize-basierter Deployment-Pfad für Cluster. Die aktuelle Bewertung zeigt einen echten minimalen Deployment-Pfad mit Lücken bei Kubernetes-spezifischer CI, ingress/TLS/NetworkPolicy-Paketierung, Backup/Wiederherstellung und Härtung der Produktionsfreigabe.

Interne Vorschau / Super-Alpha. TestFlight- und Relay-gestützte Push-Abläufe existieren, aber es gibt noch keine öffentliche Verteilung.

Optionaler Installationsablauf. Benötigt ein klareres Support-Versprechen vor der Hochstufung zu Alpha/Beta.

Die Quelle enthält Watch-App-/Erweiterungsoberflächen; die öffentliche Dokumentation stellt dies noch nicht als Benutzerfunktion dar.

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

Nur geplant.

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

Der Kernkanal ist ausgereift genug für die regelmäßige Nutzung, aber stark schwankende UX und Medien-Grenzfälle benötigen wiederkehrende Szenarienachweise.

Erstklassige Channel-Dokumentation und Routing-Oberfläche. Benötigt Scorecards für Szenarien zu Workspace-Installation und Administration.

Unterstütztes iMessage läuft über imsg auf einem angemeldeten macOS-Messages-Host; ältere BlueBubbles-Konfigurationen erfordern eine Migration. Halten Sie macOS-Berechtigungen, SSH-Wrapper, SIP/private API und Migrationshinweise sichtbar.

Der Kernpfad ist wichtig und dokumentiert; die Volatilität von Upstream-Baileys/Sitzungen hält ihn unter Stable.

Unterstützt über gebündeltes Plugin. Benötigt Scorecards für Bridge, Authentifizierung und Raum-Lifecycle.

Dokumentierter Kanal, aber die Einrichtung für Unternehmen/Administratoren erhöht das Reiferisiko.

Enterprise-Auth-/Admin-Abläufe benötigen expliziten Szenariennachweis.

Unterstützende Kanaldokumentation ist vorhanden; es sind stärkere Nachweise für Installation und erneute Verbindung erforderlich.

Wichtige regionale Abdeckung, aber das öffentliche Supportniveau sollte je nach Kontotyp, Upstream-Genehmigung und Maintainer-Nachweis kalibriert werden.