I normali percorsi di configurazione e riparazione sono documentati nella documentazione di installazione, CLI e Gateway. I percorsi Windows specifici della piattaforma sono tracciati nelle righe Windows tramite WSL2 e Windows nativo.

L'architettura di base, l'autenticazione, l'abbinamento, la documentazione del protocollo, la documentazione del demone e i runbook CLI sono ampi e aggiornati.

Il loop principale, i modelli, l'instradamento dei provider e lo streaming degli strumenti sono elementi di prima classe, ma il comportamento dei provider cambia settimanalmente e richiede prove di scenario per ogni rilascio.

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

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

Esiste documentazione su OTel, Prometheus, logging e diagnostica. Serve una revisione pubblica della maturità su "cosa gli operatori dovrebbero controllare per primo".

L'interfaccia utente web è documentata con flussi di pairing, chat, PWA, Talk, push e Gateway remoto. Promuovere dopo le scorecard cross-browser e mobile-PWA.

Esistono documentazione ampia e solide prove di runtime interno per manifest, discovery, caricamento, architettura di provider/strumenti e confini di approvazione. Mantieni la riga in beta finché la prova dell'API SDK pubblica/dei sottopercorsi e della distribuzione esterna non sarà più solida.

Esistono buone superfici di documentazione e hardening. Promuovere dopo che esecuzioni regolari di scenari di upgrade e sicurezza dimostrano l'assenza di regressioni nella configurazione.

Documentato e utilizzabile, ma la prova degli scenari dovrebbe coprire consegna non presidiata, nuovi tentativi e visibilità degli errori.

Esiste un'ampia superficie di capacità, ma la variabilità dei provider, i limiti dei file e la parità tra Node e app la rendono non ancora stabile.

Esistono più implementazioni tra Control UI, app e provider. Sono necessarie scorecard su latenza, modalità di errore e configurazione prima della beta.

Presente nella documentazione e nel sorgente, ma meno visibile come workflow utente principale. Richiede una definizione esplicita degli scenari.

Esistono documentazione pubblica e concetto di ecosistema. Servono scorecard per installazione, attendibilità, aggiornamento, rollback e compatibilità.

OpenClaw App SDK è un contratto distinto per app esterne, separato dal runtime Gateway e dal Plugin SDK. La valutazione attuale mostra un percorso @openclaw/sdk reale, con lacune relative a pacchettizzazione pubblica, scoperta automatica, approvazioni, helper e compatibilità.

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

Il percorso del servizio LaunchAgent, le modalità Gateway locale/remota, l'installazione della CLI e l'integrazione dell'app sono documentati.

La documentazione di installazione esiste e questi sono percorsi di distribuzione comuni. Promuovi dopo che gli smoke test ricorrenti di rilascio avranno acquisito il comportamento di aggiornamento e dei volumi.

Percorso Windows consigliato con indicazioni su systemd/servizio utente e documentazione della catena di avvio. Promuovere dopo scorecard ripetute di installazione/aggiornamento.

La documentazione della piattaforma esiste e il percorso Gateway è basato su Linux. Richiede una prova smoke di rilascio specifica per l'hardware per passare a un livello superiore.

Esistono un'app ricca per la barra dei menu, permessi, modalità Node, Canvas, attivazione vocale, WebChat e modalità remota. È ancora abbastanza in rapida evoluzione da evitare lo stato stabile.

Il percorso pubblico su Google Play esiste, ma la documentazione dell'app descrive ancora la ricostruzione come estremamente alpha e richiama il lavoro di irrobustimento della release.

I flussi principali di CLI/Gateway funzionano, ma la documentazione consiglia ancora WSL2 per l'esperienza completa ed elenca le avvertenze native.

L'hosting Kubernetes è un percorso distinto di distribuzione cluster basato su Kustomize. La valutazione attuale mostra un percorso reale di distribuzione minimale con lacune relative a CI specifica per Kubernetes, pacchettizzazione di ingress/TLS/NetworkPolicy, backup/ripristino e rafforzamento dell'esposizione in produzione.

Anteprima interna / super-alpha. Esistono flussi push supportati da TestFlight e relay, ma non ancora una distribuzione pubblica.

Flusso di installazione opzionale. Richiede un impegno di supporto più chiaro prima della promozione ad alpha/beta.

Il sorgente contiene superfici per app/estensione Watch; la documentazione pubblica non presenta ancora questa funzionalità per gli utenti.

La documentazione indica che le app complementari native per Linux sono pianificate; Gateway è oggi il percorso Linux supportato.

Solo pianificato.

Documentazione approfondita e ampia copertura delle funzionalità. I percorsi voce/delega dovrebbero restare valutati separatamente come beta/alpha.

Il canale core è abbastanza maturo per l'uso regolare, ma la UX ad alta variabilità e i casi limite dei contenuti multimediali richiedono prove di scenario ricorrenti.

Documentazione del canale di prima classe e superficie di instradamento. Richiede scorecard per scenari di installazione/amministrazione dello spazio di lavoro.

iMessage supportato funziona tramite imsg su un host macOS Messages con accesso effettuato; le configurazioni BlueBubbles legacy richiedono una migrazione. Mantieni visibili le avvertenze su autorizzazioni macOS, wrapper SSH, SIP/API private e migrazione.

Il percorso principale è importante e documentato; la volatilità upstream di Baileys/sessione lo mantiene sotto Stable.

Supportato tramite Plugin in bundle. Richiede scorecard per bridge, autenticazione e ciclo di vita delle stanze.

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

I flussi di autenticazione/amministrazione aziendali richiedono prove di scenario esplicite.

La documentazione dei canali supportati esiste; servono prove più solide di installazione e riconnessione.

Copertura regionale importante, ma il livello di supporto pubblico dovrebbe essere calibrato in base al tipo di account, all'approvazione upstream e alla prova del maintainer.