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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступне офіційне розповсюдження через App Store, задокументовано push-сповіщення через ретранслятор, а застосунок iOS описано як звичайний супутній Node для користувачів.

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

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

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

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

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

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

Необов’язковий процес встановлення. Перед переведенням до альфа- або бета-версії потрібно чіткіше визначити рівень підтримки.

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

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

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

Докладна документація та широке охоплення функцій. Шляхи голосового зв’язку й делегування слід і надалі оцінювати окремо як бета- та альфа-версії.

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

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

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

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

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

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

Для корпоративних процесів автентифікації та адміністрування потрібне явне підтвердження сценаріями.

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

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

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

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

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

Докладна документація, шлях OAuth/підписки, голосовий зв’язок у реальному часі, зображення та поведінка сумісності. Через часті зміни провайдера цей напрям не може отримати статус стабільного без підтвердження за карткою оцінювання випуску.

Існують кілька постачальників і відповідна документація. Для кожної групи постачальників потрібні підтвердження щодо квот, помилок і SSRF.