I normali percorsi di configurazione e riparazione sono documentati nella documentazione relativa all'installazione, alla CLI e al Gateway. I percorsi specifici per la piattaforma Windows sono monitorati nelle righe Windows tramite WSL2 e Windows nativo.

L'architettura di base, l'autenticazione, l'associazione, la documentazione del protocollo, la documentazione del demone e le procedure operative della CLI sono ampie e aggiornate.

Il ciclo principale, i modelli, l'instradamento dei provider e lo streaming degli strumenti sono funzionalità di primo livello, ma il comportamento dei provider cambia ogni settimana e richiede prove basate su scenari per ogni versione.

Documentazione solida e implementazione attiva. La maturità dipende dalla persistenza delle trascrizioni, dalla qualità della Compaction e dalla parità tra i client.

Molti canali condividono i contratti di consegna e instradamento del Gateway, ma il comportamento dei canali varia in base all'API upstream e ai vincoli delle politiche degli account.

Esiste documentazione su OTel, Prometheus, registrazione e diagnostica. Serve una revisione pubblica più matura su «cosa dovrebbero controllare per prima cosa gli operatori».

L'interfaccia web è documentata con i flussi di associazione, chat, PWA, Talk, notifiche push e Gateway remoto. Passare al livello successivo dopo le valutazioni di compatibilità tra browser e PWA mobile.

Sono disponibili un'ampia documentazione e solide evidenze sul runtime interno per manifesti, individuazione, caricamento, architettura di provider e strumenti e limiti di approvazione. Mantenere la riga al livello beta finché le prove relative alle API e ai sottopercorsi dell'SDK pubblico e alla distribuzione esterna non saranno più solide.

Sono disponibili una buona documentazione e superfici di protezione. Promuovere dopo che l'esecuzione regolare di scenari di aggiornamento e sicurezza avrà dimostrato l'assenza di regressioni nella configurazione.

Documentata e utilizzabile, ma la verifica degli scenari dovrebbe includere la consegna non presidiata, i nuovi tentativi e la visibilità degli errori.

È disponibile un'ampia gamma di funzionalità, ma le differenze tra i provider, i limiti dei file e la parità tra Node e app non consentono ancora di considerarla stabile.

Esistono molteplici implementazioni nell'interfaccia di controllo, nelle applicazioni e nei provider. Prima della versione beta sono necessarie schede di valutazione per latenza, modalità di errore e configurazione.

Presente nella documentazione e nel codice sorgente, ma meno visibile come flusso di lavoro principale per l'utente. Richiede una definizione esplicita degli scenari.

Esistono la documentazione pubblica e il concetto di ecosistema. Sono necessarie schede di valutazione per installazione, attendibilità, aggiornamento, rollback e compatibilità.

OpenClaw App SDK è un contratto distinto per applicazioni esterne, separato dal runtime del Gateway e dal Plugin SDK. La valutazione attuale mostra un percorso @openclaw/sdk concreto, con lacune relative alla distribuzione pubblica dei pacchetti, al rilevamento automatico, alle approvazioni, alle funzioni ausiliarie e alla compatibilità.

È consigliato il runtime Node, il servizio utente systemd è documentato e le indicazioni per VPS e container sono ampie.

Sono documentati il percorso del servizio LaunchAgent, le modalità locale/remota del Gateway, l'installazione tramite CLI e l'integrazione con l'app.

È disponibile la distribuzione ufficiale tramite Google Play, la documentazione per compilare ed eseguire il codice sorgente viene mantenuta e l'app Android è documentata come un normale nodo complementare per gli utenti.

È disponibile una distribuzione ufficiale tramite App Store, le notifiche push supportate da relay sono documentate e l'app iOS è descritta come un normale nodo complementare per gli utenti.

La documentazione per l'installazione è disponibile e descrive percorsi di distribuzione comuni. Passare al livello successivo dopo che verifiche smoke ricorrenti delle versioni avranno acquisito il comportamento degli aggiornamenti e dei volumi.

Percorso consigliato per Windows con indicazioni su systemd/servizi utente e documentazione sulla catena di avvio. Promuovere dopo ripetute valutazioni dell'installazione e dell'aggiornamento.

La documentazione della piattaforma è disponibile e il percorso del Gateway è basato su Linux. Per raggiungere un livello superiore sono necessarie prove di smoke test della release su hardware specifico.

Sono disponibili una completa app per la barra dei menu, le autorizzazioni, la modalità Node, Canvas, l'attivazione vocale, WebChat e la modalità remota. Il progetto è ancora in evoluzione troppo rapida per essere considerato stabile.

I flussi principali di CLI/Gateway funzionano, ma la documentazione consiglia ancora WSL2 per un'esperienza completa ed elenca le limitazioni dell'esecuzione nativa.

L'hosting Kubernetes è un percorso distinto per la distribuzione su cluster basato su Kustomize. Il punteggio attuale indica un percorso di distribuzione minimo concreto, con lacune relative a CI specifica per Kubernetes, pacchettizzazione di ingress/TLS/NetworkPolicy, backup/ripristino e rafforzamento della sicurezza per l'esposizione in produzione.

Flusso di installazione facoltativo. Richiede una dichiarazione di supporto più chiara prima della promozione alle fasi alfa/beta.

Il codice sorgente include superfici per l'app e l'estensione Watch; la documentazione pubblica non le presenta ancora come funzionalità per l'utente.

La documentazione indica che sono previste app complementari native per Linux; attualmente Gateway è il percorso Linux supportato.

Solo pianificata.

Documentazione approfondita e ampia copertura delle funzionalità. I percorsi vocali e di delega devono continuare a essere valutati separatamente come beta/alfa.

Il canale principale è sufficientemente maturo per l'uso regolare, ma l'esperienza utente altamente variabile e i casi limite relativi ai contenuti multimediali richiedono verifiche ricorrenti basate su scenari.

Documentazione completa del canale e superficie di instradamento. Richiede schede di valutazione per gli scenari di installazione e amministrazione dell'area di lavoro.

Il supporto di iMessage viene eseguito tramite imsg su un host macOS con accesso effettuato a Messaggi; le configurazioni legacy di BlueBubbles richiedono la migrazione. Mantieni visibili le avvertenze relative alle autorizzazioni di macOS, al wrapper SSH, a SIP/API private e alla migrazione.

Il percorso principale è importante e documentato; la variabilità a monte di Baileys e delle sessioni impedisce di raggiungere il livello Stabile.

Supportato tramite Plugin incluso. Richiede schede di valutazione per bridge, autenticazione e ciclo di vita delle stanze.

Canale documentato, ma la configurazione aziendale/amministrativa aumenta il rischio relativo alla maturità.

I flussi aziendali di autenticazione e amministrazione richiedono prove esplicite degli scenari.

È disponibile la documentazione del canale supportato; sono necessarie prove più solide dell'installazione e della riconnessione.

Copertura regionale importante, ma il livello di supporto pubblico deve essere calibrato in base al tipo di account, all'approvazione a monte e alle prove fornite dai manutentori.

Esistono superfici supportate, ma il livello di maturità probabilmente varia in base alla copertura dei progetti upstream e dei manutentori. Valutarle singolarmente in seguito.

Percorso opzionale/Plugin con un comportamento complesso in tempo reale. Richiede una scheda di valutazione degli scenari prima della beta pubblica.

Gli strumenti principali sono documentati, ma la sicurezza dell'host e l'esperienza utente relativa alle autorizzazioni devono rimanere sottoposte a revisione attiva nella scheda di valutazione.

Documentazione approfondita, percorso OAuth/abbonamento, voce in tempo reale, immagini e comportamento di compatibilità. I frequenti cambiamenti dei provider impediscono il passaggio allo stato Stabile senza prove nella scheda di valutazione della release.

Sono disponibili più provider e relativa documentazione. Sono necessarie prove relative a quote, errori e SSRF per ogni famiglia di provider.

Provider di modelli di prima classe. Richiede prove ricorrenti degli scenari di autenticazione, catalogo e chiamata degli strumenti.