Las rutas habituales de configuración y reparación están documentadas en la documentación de instalación, la CLI y el 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 primer nivel, 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 Compaction y la paridad entre clientes.

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

Existen documentos sobre OTel, Prometheus, registro y diagnóstico. Necesitan una revisión de madurez pública que explique «qué deben consultar primero los operadores».

La interfaz web está documentada con flujos de vinculación, chat, PWA, Talk, notificaciones push y Gateway remoto. Promuévala después de completar las tablas de evaluación para distintos navegadores y PWA móviles.

Hay 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 del SDK público, así como de la distribución externa.

Existen buena documentación y superficies de refuerzo. Promuévalo cuando las ejecuciones periódicas de escenarios de actualización y seguridad demuestren que no hay regresiones en la configuración.

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

Existe una amplia gama de capacidades, pero las diferencias entre proveedores, los límites de archivos y la paridad entre Node y las aplicaciones impiden que sea estable por ahora.

Existen varias implementaciones en la interfaz de control, las aplicaciones y los proveedores. Se necesitan tablas de evaluación de latencia, modos de fallo y configuración antes de la versión 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 fichas de evaluación para la instalación, la confianza, la actualización, la reversión y la compatibilidad.

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

Se recomienda el entorno de ejecución Node, el servicio de usuario de systemd está documentado y la orientación para VPS y contenedores es amplia.

Se documentan la ruta del servicio LaunchAgent, los modos local y remoto del Gateway, la instalación mediante 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 un relé están documentadas y la aplicación para iOS se documenta como un Node complementario normal para los usuarios.

Existe documentación de instalación y estas son rutas de implementación habituales. Promuévalo 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 los servicios de usuario, además de documentación sobre la cadena de arranque. Promover tras obtener resultados consistentes en varias evaluaciones 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 del hardware para alcanzar un nivel superior.

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

Los flujos principales de la CLI y el Gateway funcionan, pero la documentación sigue recomendando WSL2 para disfrutar de la experiencia completa y enumera las limitaciones de la ejecución nativa.

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

Flujo de instalación opcional. Requiere una promesa de soporte más clara antes de la promoción a alfa/beta.

El código fuente incluye superficies de la aplicación y la extensión de 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 opción compatible con Linux.

Solo planificada.

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

El canal principal tiene la madurez suficiente para un uso habitual, pero la experiencia de usuario con gran variabilidad y los casos límite de contenido multimedia requieren pruebas de escenarios periódicas.

Documentación de canal y superficie de enrutamiento de primera clase. Necesita cuadros de evaluación para escenarios de instalación y administración del espacio de trabajo.

La compatibilidad con iMessage funciona mediante imsg en un equipo macOS con sesión iniciada en Mensajes; las configuraciones heredadas de BlueBubbles requieren migración. Mantenga visibles las consideraciones 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 de origen impide que alcance el nivel Estable.

Compatible mediante un plugin incluido. Necesita fichas de evaluació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.

Los flujos empresariales de autenticación y administración necesitan pruebas explícitas de escenarios.

Existe documentación del canal compatible; se necesitan pruebas más sólidas de instalación y reconexión.

Cobertura regional importante, pero el nivel de soporte público debe calibrarse según el tipo de cuenta, la aprobación del proveedor y las pruebas de los responsables del mantenimiento.