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

Architettura core, autenticazione, associazione, documentazione del protocollo, documentazione del daemon e runbook CLI sono ampi e aggiornati.

Loop principale, modelli, routing dei provider e streaming degli strumenti sono di prima classe, ma il comportamento dei provider cambia settimanalmente e richiede prove di scenario per ogni release.

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 ai vincoli dell'API upstream e delle policy dell'account.

Esistono documenti su OTel, Prometheus, logging e diagnostica. Serve un passaggio pubblico di maturità su "cosa dovrebbero controllare per prima cosa gli operatori".

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

Esistono documentazione ampia e solide prove interne del runtime per manifesti, individuazione, caricamento, architettura di provider/strumenti e confini di approvazione. Mantieni la riga in beta finché le prove relative all'API/ai sottopercorsi dell'SDK pubblico e alla distribuzione esterna non saranno più solide.

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

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

Esiste un'ampia superficie di capacità, ma la varianza tra 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. Richiede scorecard su latenza, modalità di errore e configurazione prima della beta.

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

Esistono documentazione pubblica e concetto di ecosistema. Richiede 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. Il punteggio attuale mostra un percorso @openclaw/sdk reale con lacune relative a pacchettizzazione pubblica, rilevamento automatico, 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 con l'app sono documentati.

Esiste una distribuzione ufficiale su Google Play, la documentazione per compilare ed eseguire dal sorgente è mantenuta e l'app Android è documentata come normale nodo complementare per gli utenti.

Esiste una distribuzione ufficiale su App Store, le notifiche push basate su relay sono documentate e l'app iOS è documentata come un normale nodo companion per gli utenti.

La documentazione di installazione esiste e copre percorsi di distribuzione comuni. Promuovere dopo che smoke test di rilascio ricorrenti avranno acquisito il comportamento di aggiornamento e dei volumi.

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

Esiste la documentazione della piattaforma e il percorso Gateway è basato su Linux. È necessaria una prova smoke di rilascio specifica per l'hardware per salire di livello.

Esistono un'app completa per la barra dei menu, autorizzazioni, modalità nodo, Canvas, attivazione vocale, WebChat e modalità remota. È ancora abbastanza in rapida evoluzione da evitare Stable.

I flussi principali 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. Il punteggio attuale mostra un vero percorso di distribuzione minimo, con lacune relative a CI specifica per Kubernetes, pacchettizzazione di ingress/TLS/NetworkPolicy, backup/ripristino e hardening dell'esposizione in produzione.

Flusso di installazione facoltativo. Richiede una promessa di supporto più chiara prima della promozione ad alpha/beta.

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

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

Solo pianificata.

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

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

Documentazione dei canali e superficie di instradamento di prima classe. Richiede schede di valutazione degli scenari di installazione/amministrazione dell'area di lavoro.

Le esecuzioni iMessage supportate passano tramite imsg su un host macOS Messages con accesso effettuato; le configurazioni BlueBubbles legacy richiedono la migrazione. Mantieni visibili le avvertenze su permessi macOS, wrapper SSH, SIP/API private e migrazione.

Il percorso principale è importante e documentato; la volatilità a monte di Baileys/sessione lo mantiene al di sotto di Stabile.

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 aziendale richiedono una prova esplicita dello scenario.

La documentazione del canale supportato esiste; servono prove più solide per 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 alle prove dei maintainer.