Звичайні шляхи налаштування та відновлення задокументовано в документації зі встановлення, CLI та Gateway. Специфічні для платформи шляхи Windows відстежуються в рядках Windows через WSL2 і нативної Windows.

Основна архітектура, автентифікація, сполучення, документація протоколу, документація демона та runbook-и CLI широкі й актуальні.

Основний цикл, моделі, маршрутизація постачальників і потокова передача інструментів є першокласними можливостями, але поведінка постачальників змінюється щотижня й потребує сценарного підтвердження для кожного випуску.

Сильна документація й активна реалізація. Зрілість залежить від надійності збереження транскриптів, якості Compaction і паритету між клієнтами.

Багато каналів спільно використовують контракти доставки та маршрутизації Gateway, але поведінка каналів відрізняється залежно від upstream API та обмежень політики облікового запису.

Документація для OTel, Prometheus, журналювання та діагностики існує. Потребує публічного перегляду зрілості щодо того, "на що операторам слід дивитися насамперед".

Вебінтерфейс задокументовано з потоками сполучення, чату, PWA, Talk, push і віддаленого Gateway. Просувайте після оцінок за картками показників для різних браузерів і мобільних PWA.

Широка документація та переконливі внутрішні докази роботи середовища виконання існують для маніфестів, виявлення, завантаження, архітектури провайдерів/інструментів і меж схвалення. Залишайте рядок на рівні бета, доки докази щодо публічних API/підшляхів SDK і зовнішнього розповсюдження не стануть сильнішими.

Існують якісні документація та поверхні посилення безпеки. Просувайте після того, як регулярні запуски сценаріїв оновлення й безпеки доведуть відсутність регресій налаштування.

Задокументовано й придатно до використання, але підтвердження сценаріями має охоплювати доставку без нагляду, повторні спроби та видимість збоїв.

Існує широка поверхня можливостей, але відмінності між провайдерами, обмеження файлів і паритет між Node та застосунком роблять її ще нестабільною.

Існує кілька реалізацій у Control UI, застосунках і провайдерах. Перед бета-версією потрібні оцінювальні карти для затримки, режимів відмови та налаштування.

Присутній у документації та вихідному коді, але менш помітний як основний користувацький робочий процес. Потребує явного визначення сценарію.

Публічна документація та концепція екосистеми існують. Потрібні таблиці оцінки встановлення, довіри, оновлення, відкоту та сумісності.

OpenClaw App SDK — це окремий контракт зовнішнього застосунку, відмінний від середовища виконання Gateway і Plugin SDK. Поточне оцінювання показує реальний шлях @openclaw/sdk із прогалинами щодо публічного пакування, автоматичного виявлення, затверджень, допоміжних засобів і сумісності.

Рекомендовано середовище виконання Node, задокументовано користувацький сервіс systemd, а настанови для VPS/контейнерів є широкими.

Документовано шлях сервісу LaunchAgent, локальні/віддалені режими Gateway, встановлення CLI та інтеграцію з застосунком.

Документація зі встановлення існує й охоплює поширені шляхи розгортання. Підвищуйте рівень після того, як регулярні перевірки релізів зафіксують поведінку оновлення та томів.

Рекомендований шлях Windows із настановами щодо systemd/служби користувача та документацією ланцюжка завантаження. Просувайте після повторних scorecards встановлення/оновлення.

Документація платформи існує, а шлях Gateway базується на Linux. Потрібне апаратно-специфічне smoke-підтвердження випуску, щоб перейти вище.

Багатофункціональний застосунок рядка меню, дозволи, режим Node, Canvas, голосова активація, WebChat і віддалений режим уже існують. Він усе ще розвивається достатньо швидко, щоб уникати стабільного рівня.

Публічний шлях Google Play існує, але документація застосунку досі описує перезбірку як вкрай альфа-версію та зазначає роботу з посилення релізу.

Основні потоки CLI/Gateway працюють, але документація досі рекомендує WSL2 для повного досвіду та перелічує застереження щодо нативного запуску.

Хостинг Kubernetes — це окремий шлях розгортання кластера на основі Kustomize. Поточна оцінка показує реальний мінімальний шлях розгортання з прогалинами щодо специфічного для Kubernetes CI, пакування ingress/TLS/NetworkPolicy, резервного копіювання й відновлення, а також посилення захисту виробничого доступу.

Внутрішній попередній перегляд / супер-альфа. Потоки push-сповіщень TestFlight і через ретранслятор існують, але публічного розповсюдження ще немає.

Необов’язковий процес встановлення. Потребує чіткішої гарантії підтримки перед просуванням до alpha/beta.

Джерело містить поверхні застосунку/розширення Watch; публічна документація ще не подає це як користувацьку функцію.

У документації зазначено, що нативні супровідні застосунки Linux заплановано; Gateway є підтримуваним шляхом Linux на сьогодні.

Лише заплановано.

Докладна документація та широке покриття функцій. Шляхи голосу/делегування мають і надалі оцінюватися окремо як beta/alpha.

Основний канал достатньо зрілий для регулярного використання, але UX із високою варіативністю та граничні випадки з медіа потребують регулярного підтвердження сценаріями.

Повноцінна документація каналу та поверхня маршрутизації. Потрібні оціночні карти сценаріїв встановлення робочого простору й адміністрування.

Підтримуваний iMessage працює через imsg на хості macOS Messages із виконаним входом; застарілі конфігурації BlueBubbles потребують міграції. Залишайте видимими дозволи macOS, SSH-обгортку, SIP/приватний API та застереження щодо міграції.

Основний шлях важливий і задокументований; нестабільність upstream Baileys/сесій утримує його нижче за Stable.

Підтримується через вбудований plugin. Потрібні міст, автентифікація та scorecard-и життєвого циклу кімнат.

Задокументований канал, але корпоративне/адміністративне налаштування підвищує ризик зрілості.

Потоки корпоративної автентифікації та адміністрування потребують явного підтвердження сценаріями.

Документація підтримуваного каналу існує; потрібні переконливіші докази встановлення та повторного підключення.

Важливе регіональне покриття, але рівень публічної підтримки слід калібрувати за типом облікового запису, затвердженням upstream і підтвердженням від супровідників.