Os caminhos normais de configuração e reparo estão documentados na documentação de instalação, da CLI e do Gateway. Os caminhos específicos da plataforma Windows são acompanhados nas linhas Windows via WSL2 e Windows nativo.

A documentação da arquitetura principal, autenticação, pareamento, protocolo e daemon, além dos guias operacionais da CLI, é abrangente e atualizada.

O loop principal, os modelos, o roteamento de provedores e o streaming de ferramentas são recursos de primeira classe, mas o comportamento dos provedores muda semanalmente e exige comprovação por cenário a cada versão.

Documentação sólida e implementação ativa. A maturidade depende da durabilidade das transcrições, da qualidade da Compaction e da paridade entre clientes.

Muitos canais compartilham contratos de entrega e roteamento do Gateway, mas o comportamento dos canais varia conforme as restrições da API upstream e das políticas de conta.

Há documentação sobre OTel, Prometheus, registro de logs e diagnóstico. É necessária uma revisão de maturidade pública que explique “o que os operadores devem verificar primeiro”.

A interface web está documentada com fluxos de pareamento, chat, PWA, Talk, notificações push e Gateway remoto. Promova após as avaliações de compatibilidade entre navegadores e de PWA em dispositivos móveis.

Há documentação abrangente e fortes evidências internas de tempo de execução em manifestos, descoberta, carregamento, arquitetura de provedores e ferramentas e limites de aprovação. Mantenha a linha em beta até que haja evidências mais sólidas da API e dos subcaminhos públicos do SDK e da distribuição externa.

Há boa documentação e superfícies de proteção. Promova após execuções regulares de cenários de atualização e segurança comprovarem que não há regressões na configuração.

Documentada e utilizável, mas a comprovação por cenários deve abranger entrega não assistida, novas tentativas e visibilidade de falhas.

Há uma ampla variedade de recursos, mas as diferenças entre provedores, os limites de arquivos e a paridade entre Node e aplicativo ainda impedem que isso seja considerado estável.

Existem várias implementações na interface de controle, em aplicativos e em provedores. São necessários indicadores de latência, modos de falha e configuração antes da versão beta.

Presente na documentação e no código-fonte, mas menos visível como um fluxo de trabalho principal do usuário. Precisa de uma definição explícita de cenário.

A documentação pública e o conceito de ecossistema existem. São necessários indicadores de instalação, confiança, atualização, reversão e compatibilidade.

O OpenClaw App SDK é um contrato distinto para aplicativos externos, separado do runtime do Gateway e do Plugin SDK. A pontuação atual mostra um caminho @openclaw/sdk real, com lacunas relacionadas a empacotamento público, descoberta automática, aprovações, utilitários e compatibilidade.

O runtime Node é recomendado, o serviço de usuário do systemd está documentado e as orientações para VPS/contêineres são abrangentes.

O caminho do serviço LaunchAgent, os modos local/remoto do Gateway, a instalação da CLI e a integração com o aplicativo estão documentados.

Há uma distribuição oficial no Google Play, a documentação para compilar e executar a partir do código-fonte é mantida, e o aplicativo Android é documentado como um Node complementar comum para os usuários.

Há distribuição oficial pela App Store, as notificações push com suporte de retransmissão estão documentadas, e o aplicativo para iOS é documentado como um Node complementar comum para os usuários.

A documentação de instalação existe, e esses são caminhos comuns de implantação. Promova após testes de fumaça recorrentes de lançamento registrarem o comportamento de atualização e dos volumes.

Caminho recomendado para Windows, com orientações sobre systemd/serviço de usuário e documentação da cadeia de inicialização. Promova após avaliações repetidas de instalação e atualização.

Há documentação da plataforma, e o caminho do Gateway é baseado em Linux. São necessárias evidências de testes rápidos de lançamento específicos para o hardware para avançar a um nível superior.

O aplicativo completo na barra de menus, as permissões, o modo Node, o Canvas, a ativação por voz, o WebChat e o modo remoto já existem. Ainda evoluem rápido demais para alcançar o nível Estável.

Os fluxos principais da CLI e do Gateway funcionam, mas a documentação ainda recomenda o WSL2 para uma experiência completa e lista ressalvas sobre o uso nativo.

A hospedagem no Kubernetes é um caminho distinto de implantação em cluster baseado no Kustomize. A pontuação atual indica um caminho mínimo real de implantação, com lacunas relacionadas a CI específica para Kubernetes, empacotamento de ingresso/TLS/NetworkPolicy, backup/restauração e reforço da segurança da exposição em produção.

Fluxo de instalação opcional. Precisa de uma definição mais clara do compromisso de suporte antes da promoção para alfa/beta.

O código-fonte contém superfícies do aplicativo e da extensão para Watch; a documentação pública ainda não apresenta isso como um recurso para o usuário.

A documentação informa que aplicativos complementares nativos para Linux estão planejados; atualmente, o Gateway é o caminho compatível com Linux.

Apenas planejado.

Documentação aprofundada e ampla cobertura de recursos. Os caminhos de voz/delegação devem continuar sendo avaliados separadamente como beta/alfa.

O canal principal está maduro o suficiente para uso regular, mas casos extremos de mídia e de experiência do usuário com alta variabilidade exigem comprovação recorrente por cenários.

Documentação de canal e superfície de roteamento de primeira classe. Precisa de scorecards para cenários de instalação e administração do espaço de trabalho.

O iMessage compatível funciona por meio do imsg em um host do Mensagens do macOS com uma sessão iniciada; configurações legadas do BlueBubbles exigem migração. Mantenha visíveis as ressalvas sobre permissões do macOS, wrapper SSH, SIP/API privada e migração.

O caminho principal é importante e está documentado; a volatilidade do Baileys e das sessões no upstream o mantém abaixo do nível Estável.

Compatível por meio do plugin incluído. Precisa de pontuações de maturidade para a ponte, a autenticação e o ciclo de vida das salas.

Canal documentado, mas a configuração empresarial/administrativa aumenta o risco de maturidade.

Os fluxos empresariais de autenticação e administração precisam de comprovação explícita por cenários.

Existe documentação do canal compatível; são necessárias evidências mais sólidas de instalação e reconexão.

Cobertura regional importante, mas o nível de suporte público deve ser ajustado conforme o tipo de conta, a aprovação do serviço upstream e as comprovações dos mantenedores.

Há superfícies compatíveis, mas a maturidade provavelmente varia conforme o projeto de origem e a cobertura dos mantenedores. Avalie-as individualmente mais tarde.

Caminho opcional/de Plugin com comportamento complexo em tempo real. Precisa de um quadro de avaliação de cenários antes da versão beta pública.

As ferramentas principais estão documentadas, mas a segurança do host e a experiência do usuário com permissões devem permanecer sob análise ativa no quadro de avaliação.

Documentação aprofundada, caminho de OAuth/assinatura, voz em tempo real, imagem e comportamento de compatibilidade. As mudanças frequentes nos provedores impedem que isto seja considerado Estável sem comprovação no quadro de avaliação da versão.

Existem vários provedores e documentos. São necessárias evidências de cotas, erros e SSRF para cada família de provedores.

Provedor de modelos de primeira classe. Precisa de comprovação recorrente de cenários de autenticação, catálogo e chamadas de ferramentas.