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 por plataforma se controlan en las filas 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 los runbooks de CLI son amplios y actuales.

El bucle principal, los modelos, el enrutamiento de proveedores y la transmisión de herramientas son capacidades de primer nivel, pero el comportamiento de los proveedores cambia semanalmente y requiere pruebas de escenarios en cada lanzamiento.

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

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

Existen documentos de OTel, Prometheus, registro y diagnóstico. Necesita una revisión de madurez pública sobre "lo que los operadores deben mirar primero".

La interfaz web está documentada con flujos de emparejamiento, chat, PWA, Talk, push y Gateway remoto. Promocionar después de las tarjetas de puntuación entre navegadores y de PWA móvil.

Existen documentación amplia y evidencia interna sólida del runtime en manifiestos, descubrimiento, carga, arquitectura de proveedores/herramientas y límites de aprobación. Mantén la fila en beta hasta que la prueba de la API/subrutas del SDK público y la distribución externa sea más sólida.

Existen buena documentación y superficies de endurecimiento. Promover después de que las ejecuciones regulares de escenarios de actualización/seguridad demuestren que no hay regresiones de configuración.

Documentado y utilizable, pero la prueba de escenarios debería cubrir 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 aún no sea estable.

Existen varias implementaciones en Control UI, aplicaciones y proveedores. Necesita tablas de puntuación de latencia, modos de fallo y configuración antes de la beta.

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

Existen documentación pública y concepto de ecosistema. Necesita cuadros de mando de instalación, confianza, actualización, reversión y compatibilidad.

OpenClaw App SDK es un contrato de app externa distinto, separado del tiempo de ejecución de Gateway y de Plugin SDK. La puntuación actual muestra una ruta @openclaw/sdk real con brechas en el empaquetado público, el autodescubrimiento, las aprobaciones, las utilidades y la compatibilidad.

Se recomienda el runtime de Node, el servicio de usuario de systemd está documentado y la guía para VPS/contenedores es amplia.

La ruta del servicio LaunchAgent, los modos de Gateway local/remoto, la instalación de la CLI y la integración de la aplicación están documentados.

Existen documentos de instalación y son rutas de implementación habituales. Promocionar después de que las pruebas de humo recurrentes de lanzamiento capturen el comportamiento de actualización y volúmenes.

Ruta recomendada para Windows con orientación sobre systemd/servicios de usuario y documentación de la cadena de arranque. Promocionar después de scorecards repetidos de instalación/actualización.

Existen documentos de plataforma y la ruta del Gateway está basada en Linux. Necesita prueba de smoke de lanzamiento específica de hardware para avanzar más.

Existen una aplicación completa de barra de menús, permisos, modo Node, Canvas, activación por voz, WebChat y modo remoto. Aún cambia lo bastante rápido como para evitar Stable.

Existe una ruta pública de Google Play, pero la documentación de la aplicación todavía describe la reconstrucción como extremadamente alfa y señala trabajo de robustecimiento para el lanzamiento.

Los flujos principales de CLI/Gateway funcionan, pero la documentación todavía recomienda WSL2 para la experiencia completa y enumera advertencias nativas.

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

Vista previa interna / super-alfa. Existen flujos de TestFlight y de notificaciones push respaldadas por retransmisión, pero aún no hay distribución pública.

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

La fuente tiene superficies de app/extensión Watch; la documentación pública aún no presenta esto como una función para usuarios.

La documentación indica que las aplicaciones complementarias nativas de Linux están planificadas; Gateway es la vía compatible de Linux actualmente.

Solo planificada.

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

El canal principal es lo bastante maduro para uso regular, pero la UX de alta variabilidad y los casos límite de medios necesitan pruebas de escenarios recurrentes.

Documentación de canal de primera clase y superficie de enrutamiento. Necesita scorecards de escenarios de instalación/administración de workspace.

iMessage compatible se ejecuta mediante imsg en un host de Mensajes de macOS con sesión iniciada; las configuraciones heredadas de BlueBubbles requieren migración. Mantén visibles los permisos de macOS, el wrapper SSH, la API SIP/privada y las advertencias de migración.

La ruta principal es importante y está documentada; la volatilidad de Baileys/sesiones upstream la mantiene por debajo de estable.

Compatible mediante Plugin incluido. Necesita cuadros de puntuación para puente, autenticación y ciclo de vida de salas.

Canal documentado, pero la configuración empresarial/de administración aumenta el riesgo de madurez.

Los flujos empresariales de autenticación y administración necesitan prueba explícita de escenarios.

Existe documentación del canal compatible; necesita 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 upstream y la prueba de mantenedores.