通常のセットアップおよび修復手順は、インストール、CLI、Gatewayの各ドキュメントに記載されています。Windows固有の手順は、「WSL2経由のWindows」と「ネイティブWindows」の行で追跡されています。

コアアーキテクチャ、認証、ペアリング、プロトコルのドキュメント、デーモンのドキュメント、CLI ランブックは幅広く、最新の状態です。

メインループ、モデル、プロバイダーのルーティング、ツールのストリーミングは主要機能として扱われていますが、プロバイダーの動作は毎週変化するため、リリースごとにシナリオによる検証が必要です。

ドキュメントは充実しており、実装も活発です。成熟度は、トランスクリプトの耐久性、Compactionの品質、クライアント間の同等性に左右されます。

多くのチャネルは Gateway の配信およびルーティング契約を共有していますが、チャネルの動作は上流 API とアカウントポリシーの制約によって異なります。

OTel、Prometheus、ログ、診断に関するドキュメントは存在します。公開向けに「運用担当者が最初に確認すべき事項」を示す、成熟度向上のための見直しが必要です。

Web UIについて、ペアリング、チャット、PWA、Talk、プッシュ通知、リモートGatewayのフローを文書化しています。ブラウザー間およびモバイルPWAのスコアカード評価後に昇格します。

マニフェスト、検出、読み込み、プロバイダー／ツールのアーキテクチャ、承認境界にわたり、幅広いドキュメントと強力な内部ランタイム証拠が存在します。公開SDKのAPI／サブパスと外部配布の証拠がさらに強化されるまでは、この行をベータのまま維持します。

優れたドキュメントと堅牢化のための機能面が整っています。定期的なアップグレードおよびセキュリティシナリオの実行によって、セットアップのリグレッションがないことを証明した後に昇格します。

ドキュメントが整備され利用可能ですが、シナリオによる証明では、無人配信、再試行、障害の可視性を網羅する必要があります。

幅広い機能が存在しますが、プロバイダー間の差異、ファイル制限、Node とアプリ間の機能差により、まだ安定していません。

Control UI、アプリ、プロバイダーに複数の実装が存在します。ベータ版に進む前に、レイテンシー、障害モード、セットアップのスコアカードが必要です。

ドキュメントとソースには存在しますが、主要なユーザーワークフローとしてはあまり目立ちません。明確なシナリオ定義が必要です。

公開ドキュメントとエコシステムの概念は存在します。インストール、信頼性、更新、ロールバック、互換性のスコアカードが必要です。

OpenClaw App SDKは、GatewayランタイムおよびPlugin SDKとは別個の外部アプリ向けコントラクトです。現在のスコアリングでは、実際に利用可能な@openclaw/sdkの経路が存在する一方で、公開パッケージ化、自動検出、承認、ヘルパー、互換性には不足があります。

Node ランタイムを推奨し、systemd ユーザーサービスについて文書化されており、VPS/コンテナに関するガイダンスも幅広く提供されています。

LaunchAgentのサービスパス、ローカル/リモートGatewayモード、CLIのインストール、アプリ統合について説明しています。

Google Playによる公式配布が提供され、ソースからのビルドおよび実行に関するドキュメントが保守されており、Android アプリはユーザー向けの標準的なコンパニオン Node として文書化されています。

App Storeによる公式配布が存在し、リレー経由のプッシュ通知が文書化されており、iOSアプリはユーザー向けの標準的なコンパニオンNodeとして文書化されています。

インストールに関するドキュメントがあり、一般的なデプロイ方法として利用されています。定期的なリリーススモークテストでアップグレードとボリュームの動作を確認できるようになった後に昇格します。

systemd/ユーザーサービスのガイダンスとブートチェーンのドキュメントを備えた、推奨されるWindows向けの方法です。インストールと更新のスコアカードで繰り返し評価した後に昇格します。

プラットフォームのドキュメントは存在し、Gateway のパスは Linux ベースです。さらに高い成熟度へ移行するには、ハードウェア固有のリリーススモークテストによる証明が必要です。

高機能なメニューバーアプリ、権限、Node モード、Canvas、音声ウェイク、WebChat、リモートモードが実装されています。まだ変更が速いため、安定版には分類されません。

コアの CLI/Gateway フローは動作しますが、完全な利用体験のためにドキュメントでは引き続き WSL2 を推奨しており、ネイティブ環境に関する注意事項も記載しています。

Kubernetesホスティングは、Kustomizeを基盤とする独立したクラスターデプロイ経路です。現在の評価では、実用的な最小限のデプロイ経路が存在する一方、Kubernetes固有のCI、イングレス/TLS/NetworkPolicyのパッケージ化、バックアップ/復元、本番環境への公開に関する堅牢化に不足があります。

オプションのインストールフロー。アルファ／ベータへの昇格前に、サポート方針をより明確にする必要があります。

ソースにはWatchアプリ／拡張機能の画面がありますが、公開ドキュメントではまだユーザー向け機能として紹介されていません。

ドキュメントではネイティブLinuxコンパニオンアプリは計画中とされています。現在Linuxでサポートされている経路はGatewayです。

計画のみです。

詳細なドキュメントと幅広い機能カバレッジ。音声および委任の経路は、ベータ版またはアルファ版として個別に評価し続ける必要があります。

コアチャネルは通常利用に十分な成熟度に達していますが、変動の大きいUXとメディアのエッジケースには、シナリオによる継続的な検証が必要です。

ファーストクラスのチャンネルドキュメントとルーティング機能。ワークスペースのインストールおよび管理者向けシナリオのスコアカードが必要です。

サポート対象のiMessageは、サインイン済みのmacOS Messagesホスト上のimsgを通じて動作します。従来のBlueBubbles設定には移行が必要です。macOSの権限、SSHラッパー、SIP/プライベートAPI、および移行に関する注意事項を明示しておいてください。

コアパスは重要で、ドキュメントも整備されていますが、上流の Baileys とセッションの不安定性により、安定版には達していません。

バンドルされたPluginを介してサポートされます。ブリッジ、認証、ルームのライフサイクルに関するスコアカードが必要です。

ドキュメント化されたチャネルですが、エンタープライズおよび管理者向けのセットアップにより、成熟度のリスクが高まっています。

エンタープライズの認証および管理者フローには、明示的なシナリオによる検証が必要です。

対応チャンネルのドキュメントは存在しますが、インストールと再接続について、より確かな実証が必要です。

地域別の対応範囲として重要ですが、公開するサポートレベルは、アカウント種別、上流での承認、メンテナーによる検証結果に応じて調整する必要があります。