Las rutas normales de configuración y reparación están documentadas en la documentación de instalación, CLI y Gateway. Las rutas específicas de Windows se registran en las filas de Windows mediante WSL2 y Windows nativo.

La arquitectura central, la autenticación, el emparejamiento, la documentación del protocolo, la documentación del daemon y las guías operativas de la CLI son amplias y están actualizadas.

El bucle principal, los modelos, el enrutamiento de proveedores y la transmisión de herramientas son elementos de primera clase, pero el comportamiento de los proveedores cambia semanalmente y requiere pruebas de escenarios en cada versión.

Documentación sólida e implementación activa. La madurez depende de la durabilidad de las transcripciones, la calidad de la Compaction y la paridad entre clientes.

Muchos canales comparten los contratos de entrega y enrutamiento del Gateway, pero el comportamiento de los canales varía según la API de origen y las restricciones de las políticas de las cuentas.

Existen documentos sobre OTel, Prometheus, registro y diagnóstico. Se necesita una revisión pública de madurez sobre «qué deberían consultar primero los operadores».

La interfaz web está documentada con flujos de emparejamiento, chat, PWA, Talk, notificaciones push y Gateway remoto. Promover después de completar las evaluaciones para varios navegadores y PWA móviles.

Existen documentación amplia y pruebas internas sólidas del entorno de ejecución en manifiestos, detección, carga, arquitectura de proveedores y herramientas, y límites de aprobación. Mantenga la fila en beta hasta que sean más sólidas las pruebas de la API y las subrutas públicas del SDK, así como de la distribución externa.

Existen buena documentación y superficies de protección. Promuévalo después de que las ejecuciones periódicas de escenarios de actualización y seguridad demuestren que no hay regresiones de configuración.

Está documentada y se puede usar, pero las pruebas de escenarios deben abarcar la entrega desatendida, los reintentos y la visibilidad de los fallos.

Existe una amplia superficie de capacidades, pero la variación entre proveedores, los límites de archivos y la paridad entre Node y la aplicación hacen que todavía no sea estable.

Existen varias implementaciones en la interfaz de control, las aplicaciones y los proveedores. Se necesitan cuadros de evaluación de latencia, modos de fallo y configuración antes de la fase beta.

Presente en la documentación y el código fuente, pero menos visible como flujo de trabajo principal para el usuario. Necesita una definición explícita de los escenarios.

Existen documentación pública y un concepto de ecosistema. Se necesitan tablas de evaluación para la instalación, la confianza, las actualizaciones, la reversión y la compatibilidad.

El SDK de aplicaciones de OpenClaw es un contrato diferenciado para aplicaciones externas, independiente del entorno de ejecución de Gateway y del SDK de plugins. La puntuación actual muestra una ruta @openclaw/sdk real con carencias en el empaquetado público, el descubrimiento automático, las aprobaciones, las funciones auxiliares y la compatibilidad.

Se recomienda el entorno de ejecución Node, se documenta el servicio de usuario de systemd y la orientación sobre VPS/contenedores es amplia.

Se documentan la ruta del servicio LaunchAgent, los modos local y remoto del Gateway, la instalación de la CLI y la integración con la aplicación.

Existe una distribución oficial en Google Play, se mantiene la documentación para compilar y ejecutar desde el código fuente, y la aplicación para Android está documentada como un Node complementario normal para los usuarios.

Existe una distribución oficial en la App Store, las notificaciones push respaldadas por retransmisión están documentadas y la aplicación para iOS se documenta como un nodo complementario normal para los usuarios.

Existe documentación de instalación y estas son rutas de despliegue habituales. Promover cuando las pruebas de humo periódicas de cada versión registren el comportamiento de las actualizaciones y los volúmenes.

Ruta recomendada para Windows con orientación sobre systemd y servicios de usuario, además de documentación sobre la cadena de arranque. Promover después de evaluaciones repetidas de instalación y actualización.

Existe documentación de la plataforma y la ruta del Gateway se basa en Linux. Se necesitan pruebas de humo de la versión específicas para el hardware para avanzar a un nivel superior.

Existe una completa aplicación para la barra de menús, con permisos, modo Node, Canvas, activación por voz, WebChat y modo remoto. Sigue evolucionando con demasiada rapidez como para considerarla estable.

Los flujos principales de la CLI y el Gateway funcionan, pero la documentación aún recomienda WSL2 para disfrutar de la experiencia completa y enumera las salvedades del uso nativo.

El alojamiento en Kubernetes es una ruta diferenciada de despliegue en clúster basada en Kustomize. La puntuación actual muestra una ruta de despliegue mínima real, con carencias en torno a la CI específica de Kubernetes, el empaquetado de ingress/TLS/NetworkPolicy, la copia de seguridad y restauración, y el refuerzo de la exposición en producción.

Flujo de instalación opcional. Necesita una promesa de soporte más clara antes de ascender a alfa/beta.

El código fuente incluye superficies de aplicación/extensión para Watch; la documentación pública aún no las presenta como una función para el usuario.

La documentación indica que están previstas aplicaciones complementarias nativas para Linux; actualmente, Gateway es la vía compatible con Linux.

Solo está planificada.

Documentación detallada y amplia cobertura de funcionalidades. Las rutas de voz/delegación deben seguir puntuándose por separado como beta/alfa.

El canal principal tiene la madurez suficiente para su uso habitual, pero la experiencia de usuario altamente variable y los casos extremos con contenido multimedia necesitan pruebas periódicas de escenarios.

Documentación de canal y superficie de enrutamiento de primera clase. Necesita tablas de puntuación de escenarios de instalación y administración del espacio de trabajo.

La compatibilidad con iMessage funciona mediante imsg en un host de Mensajes de macOS con una sesión iniciada; las configuraciones heredadas de BlueBubbles requieren migración. Mantenga visibles las advertencias sobre los permisos de macOS, el contenedor SSH, SIP/API privada y la migración.

La ruta principal es importante y está documentada; la volatilidad de Baileys y de las sesiones en el proyecto upstream la mantiene por debajo de Estable.

Compatible mediante un plugin incluido. Necesita tablas de puntuación para el puente, la autenticación y el ciclo de vida de las salas.

Canal documentado, pero la configuración empresarial y administrativa aumenta el riesgo de madurez.