Les chemins de configuration et de réparation normaux sont documentés dans les docs d’installation, de CLI et de Gateway. Les chemins Windows propres à chaque plateforme sont suivis dans les lignes Windows via WSL2 et Windows natif.

L’architecture de base, l’authentification, l’appairage, la documentation du protocole, la documentation du daemon et les runbooks CLI sont étendus et à jour.

La boucle principale, les modèles, le routage des fournisseurs et le streaming d’outils sont des éléments de premier ordre, mais le comportement des fournisseurs change chaque semaine et nécessite une preuve par scénario pour 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 clients.

De nombreux canaux partagent les contrats de livraison et de routage du Gateway, mais le comportement des canaux varie selon les contraintes de l’API amont et de la politique de compte.

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

L’interface Web est documentée avec les flux d’association, de chat, de PWA, de Talk, de notifications push et de Gateway distant. Promouvoir après les tableaux de bord inter-navigateurs et mobile-PWA.

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

Une bonne documentation et des surfaces de durcissement existent. Promouvoir après que des exécutions régulières de scénarios de mise à niveau et de sécurité ont prouvé l'absence de régressions de configuration.

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

Une large surface de capacités existe, mais les variations selon les fournisseurs, les limites de fichiers et la parité Node/application font que cette surface n’est pas encore stable.

Plusieurs implémentations existent dans Control UI, les applications et les fournisseurs. Des tableaux de score de latence, de modes de défaillance et de configuration sont nécessaires avant la bêta.

Présent dans les docs et le source, mais moins visible comme workflow utilisateur principal. Nécessite une définition explicite des scénarios.

La documentation publique et le concept d'écosystème existent. Nécessite des fiches d'évaluation pour l'installation, la confiance, la mise à jour, la restauration et la compatibilité.

OpenClaw App SDK est un contrat d'application externe distinct, séparé du runtime Gateway et du Plugin SDK. L'évaluation actuelle montre un vrai parcours @openclaw/sdk, avec des lacunes concernant le packaging public, la découverte automatique, les approbations, les assistants et la compatibilité.

L'environnement d'exécution Node est recommandé, le service utilisateur systemd est documenté, et les recommandations pour VPS/conteneurs sont étendues.

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

La documentation d’installation existe et ces chemins de déploiement sont courants. À promouvoir après que les tests smoke de publication récurrents auront capturé le comportement de mise à niveau et des volumes.

Parcours Windows recommandé, avec indications pour systemd/service utilisateur et documentation de la chaîne de démarrage. À promouvoir après des scorecards répétées d’installation/mise à jour.

La documentation de la plateforme existe et le chemin Gateway est basé sur Linux. Une preuve de smoke test de version propre au matériel est nécessaire pour passer au niveau supérieur.

L’application riche de barre de menus, les autorisations, le mode Node, Canvas, le réveil vocal, WebChat et le mode distant existent. L’ensemble évolue encore assez rapidement pour éviter Stable.

Le parcours public Google Play existe, mais la documentation de l’application décrit encore la reconstruction comme extrêmement alpha et signale le travail de durcissement de la version.

Les flux principaux CLI/Gateway fonctionnent, mais la documentation recommande toujours WSL2 pour l’expérience complète et répertorie les réserves propres au mode natif.

L’hébergement Kubernetes est un chemin de déploiement de cluster distinct basé sur Kustomize. La notation actuelle montre un véritable chemin de déploiement minimal, avec des lacunes concernant la CI propre à Kubernetes, le packaging ingress/TLS/NetworkPolicy, la sauvegarde/restauration et le renforcement de l’exposition en production.

Aperçu interne / super-alpha. Les flux TestFlight et de push appuyés par relais existent, mais il n’y a pas encore de distribution publique.

Flux d’installation facultatif. Nécessite une promesse de support plus claire avant la promotion en alpha/bêta.

La source comporte des surfaces d’app/extension Watch ; la documentation publique ne les présente pas encore comme une fonctionnalité utilisateur.

La documentation indique que les applications d’accompagnement Linux natives sont prévues ; Gateway est aujourd’hui le chemin Linux pris en charge.

Planifié uniquement.

Documentation approfondie et large couverture fonctionnelle. Les parcours voix/délégation doivent rester évalués séparément comme bêta/alpha.

Le canal principal est suffisamment mature pour une utilisation régulière, mais les cas limites à forte variance concernant l’UX et les médias nécessitent des preuves de scénarios récurrentes.

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

Les exécutions iMessage prises en charge passent par imsg sur un hôte macOS Messages connecté ; les configurations BlueBubbles héritées nécessitent une migration. Gardez visibles les autorisations macOS, l’enveloppe SSH, l’API SIP/privée et les mises en garde relatives à la migration.

Le chemin principal est important et documenté ; la volatilité en amont de Baileys/session le maintient en dessous de Stable.

Pris en charge via le plugin groupé. Nécessite des tableaux de bord de maturité pour le pont, l’authentification et le cycle de vie des salons.

Canal documenté, mais la configuration entreprise/administrateur augmente le risque de maturité.

Les flux d’authentification et d’administration d’entreprise nécessitent une preuve de scénario explicite.

La documentation du canal pris en charge existe ; il faut des preuves plus solides d’installation et de reconnexion.

Couverture régionale importante, mais le niveau de prise en charge publique doit être calibré selon le type de compte, l’approbation en amont et les preuves des mainteneurs.