Les parcours normaux de configuration et de réparation sont documentés dans la documentation relative à l'installation, à la CLI et au Gateway. Les parcours propres à la plateforme Windows sont suivis dans les lignes Windows via WSL2 et Windows natif.

La documentation de l’architecture principale, de l’authentification, de l’appairage, du protocole et du démon, ainsi que les guides opérationnels de la CLI, est étendue et à jour.

La boucle principale, les modèles, le routage des fournisseurs et la diffusion en continu des outils sont des fonctionnalités de premier plan, mais le comportement des fournisseurs évolue chaque semaine et nécessite une validation par scénario à chaque version.

Documentation solide et implémentation active. La maturité dépend de la durabilité des transcriptions, de la qualité de la Compaction et de la parité entre les clients.

De nombreux canaux partagent les contrats de distribution et de routage du Gateway, mais leur comportement varie selon les contraintes de l’API en amont et de la politique des comptes.

La documentation sur OTel, Prometheus, la journalisation et les diagnostics existe. Elle nécessite une révision de maturité publique indiquant « ce que les opérateurs doivent examiner en premier ».

L’interface Web est documentée avec les flux d’association, de discussion, de PWA, de conversation vocale, de notifications push et de Gateway distant. À promouvoir après l’établissement des grilles d’évaluation multinavigateurs et PWA mobiles.

Une documentation étendue et de solides preuves internes d’exécution existent pour les manifestes, la découverte, le chargement, l’architecture des fournisseurs et des outils, ainsi que les limites d’approbation. Maintenez cette ligne au niveau bêta jusqu’à ce que les preuves concernant l’API et les sous-chemins publics du SDK, ainsi que la distribution externe, soient plus solides.

Une bonne documentation et des surfaces de durcissement existent. À promouvoir lorsque des exécutions régulières de scénarios de mise à niveau et de sécurité auront démontré l'absence de régressions de configuration.

Documenté et utilisable, mais les preuves par scénario doivent couvrir la livraison sans surveillance, les nouvelles tentatives et la visibilité des échecs.

Un large éventail de fonctionnalités existe, mais les différences entre fournisseurs, les limites de fichiers et la parité entre Node et les applications ne permettent pas encore de considérer cet ensemble comme stable.

Plusieurs implémentations existent dans l’interface de contrôle, les applications et les fournisseurs. Des grilles d’évaluation de la latence, des modes de défaillance et de la configuration sont nécessaires avant la version bêta.

Présente dans la documentation et le code source, mais moins visible en tant que flux de travail principal pour les utilisateurs. Nécessite une définition explicite des scénarios.

La documentation publique et le concept d’écosystème existent. Des tableaux de bord sont nécessaires pour l’installation, la confiance, les mises à jour, la restauration et la compatibilité.

Le SDK d’application OpenClaw constitue un contrat distinct pour les applications externes, séparé de l’environnement d’exécution du Gateway et du SDK de Plugin. L’évaluation actuelle révèle une véritable voie @openclaw/sdk, avec des lacunes concernant la distribution publique, la découverte automatique, les approbations, les fonctions auxiliaires et la compatibilité.

L’environnement d’exécution Node est recommandé, le service utilisateur systemd est documenté et les indications concernant les VPS et les conteneurs sont détaillées.

Le chemin du service LaunchAgent, les modes local et distant du Gateway, l’installation de la CLI et l’intégration à l’application sont documentés.

Une distribution officielle sur Google Play est disponible, la documentation sur la compilation et l’exécution depuis les sources est tenue à jour, et l’application Android est présentée comme un Node compagnon standard pour les utilisateurs.

Une distribution officielle sur l’App Store existe, les notifications push relayées sont documentées et l’application iOS est présentée comme un Node compagnon standard pour les utilisateurs.

La documentation d’installation existe et couvre des modes de déploiement courants. Promouvoir une fois que les tests de fumée récurrents des versions auront capturé le comportement des mises à niveau et des volumes.

Méthode recommandée sous Windows, avec des conseils sur systemd et les services utilisateur ainsi qu’une documentation sur la chaîne de démarrage. À promouvoir après plusieurs évaluations réussies des installations et des mises à jour.

La documentation de la plateforme existe et le parcours du Gateway repose sur Linux. Une validation de fonctionnement de la version sur du matériel spécifique est nécessaire pour atteindre un niveau supérieur.

Une application riche dans la barre des menus, les autorisations, le mode Node, Canvas, l’activation vocale, WebChat et le mode à distance sont disponibles. Son évolution reste toutefois trop rapide pour atteindre le niveau Stable.

Les principaux flux de la CLI et du Gateway fonctionnent, mais la documentation recommande toujours WSL2 pour une expérience complète et répertorie les limitations de l’exécution native.

L’hébergement Kubernetes constitue une voie de déploiement en cluster distincte fondée sur Kustomize. L’évaluation actuelle révèle une véritable voie de déploiement minimale, avec des lacunes concernant la CI propre à Kubernetes, la configuration de l’ingress, de TLS et de NetworkPolicy, la sauvegarde et la restauration, ainsi que le renforcement de l’exposition en production.

Parcours d’installation facultatif. Nécessite un engagement de prise en charge plus clair avant le passage en alpha/bêta.

Le code source comporte des surfaces d’application et d’extension Watch ; la documentation publique ne les présente pas encore comme une fonctionnalité destinée aux utilisateurs.

La documentation indique que des applications compagnons Linux natives sont prévues ; le Gateway est actuellement la solution Linux prise en charge.

Uniquement planifié.

Documentation approfondie et large couverture fonctionnelle. Les parcours vocaux et de délégation doivent continuer à être évalués séparément en tant que bêta/alpha.

Le canal principal est suffisamment mature pour une utilisation régulière, mais les cas limites liés à l'expérience utilisateur et aux médias, qui présentent une forte variabilité, nécessitent une validation régulière par scénarios.

Documentation de canal et surface de routage de premier ordre. Nécessite des grilles d’évaluation pour les scénarios d’installation et d’administration de l’espace de travail.

La prise en charge d’iMessage passe par imsg sur un hôte Messages macOS connecté ; les configurations BlueBubbles héritées nécessitent une migration. Veillez à ce que les avertissements concernant les autorisations macOS, l’enveloppe SSH, SIP et l’API privée, ainsi que la migration, restent visibles.

Le parcours principal est important et documenté ; la volatilité de Baileys et des sessions en amont empêche toutefois d’atteindre le niveau Stable.

Pris en charge par un Plugin intégré. Nécessite des fiches d’évaluation pour le pont, l’authentification et le cycle de vie des salons.

Canal documenté, mais la configuration en entreprise et par les administrateurs accroît le risque lié à la maturité.

Les flux d’authentification et d’administration d’entreprise nécessitent une validation explicite des scénarios.

La documentation du canal pris en charge existe ; des preuves plus solides de l’installation et de la reconnexion sont nécessaires.

La couverture régionale est importante, mais le niveau de prise en charge publique doit être évalué selon le type de compte, l’approbation en amont et les preuves fournies par les mainteneurs.