chore(i18n): refresh uk translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
7ca450d76f
commit
2821d8a1b0
205
docs/uk/ci.md
205
docs/uk/ci.md
File diff suppressed because one or more lines are too long
File diff suppressed because it is too large
Load Diff
@ -2,14 +2,14 @@
|
||||
read_when:
|
||||
- Вам потрібен огляд журналювання OpenClaw, зрозумілий для початківців
|
||||
- Ви хочете налаштувати рівні журналювання, формати або редагування конфіденційних даних
|
||||
- Ви усуваєте несправності й вам потрібно швидко знайти журнали
|
||||
summary: Журнали файлів, вивід консолі, відстеження CLI та вкладка «Журнали» в Control UI
|
||||
- Ви усуваєте несправності й хочете швидко знайти журнали
|
||||
summary: Файлові журнали, виведення консолі, відстеження виведення CLI та вкладка «Журнали» в Control UI
|
||||
title: Журналювання
|
||||
x-i18n:
|
||||
generated_at: "2026-04-26T22:05:00Z"
|
||||
generated_at: "2026-04-27T22:51:29Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 6fb71b94a5c4fb8db9c704552f73f364b45c9d19bfb74c92abe1f22576fe1480
|
||||
source_hash: 5c6f0e325540e6daca228a2e9cc6c032ccc27a3c2a38be13a29e87a6a1227081
|
||||
source_path: logging.md
|
||||
workflow: 15
|
||||
---
|
||||
@ -17,19 +17,20 @@ x-i18n:
|
||||
OpenClaw має дві основні поверхні журналювання:
|
||||
|
||||
- **Файлові журнали** (рядки JSON), які записує Gateway.
|
||||
- **Вивід консолі**, що показується в терміналах і в Gateway Debug UI.
|
||||
- **Виведення консолі**, яке показується в терміналах і в Gateway Debug UI.
|
||||
|
||||
Вкладка **Logs** у Control UI відстежує файловий журнал gateway. На цій сторінці пояснюється, де розташовані журнали, як їх читати та як налаштовувати рівні й формати журналювання.
|
||||
Вкладка **Logs** у Control UI відстежує файловий журнал gateway. На цій сторінці
|
||||
пояснюється, де зберігаються журнали, як їх читати та як налаштовувати рівні й формати журналювання.
|
||||
|
||||
## Де розташовані журнали
|
||||
## Де зберігаються журнали
|
||||
|
||||
Типово Gateway записує ротаційний файл журналу в:
|
||||
За замовчуванням Gateway записує циклічний файл журналу в:
|
||||
|
||||
`/tmp/openclaw/openclaw-YYYY-MM-DD.log`
|
||||
|
||||
Дата використовує локальний часовий пояс хоста gateway.
|
||||
|
||||
Кожен файл ротується, коли досягає `logging.maxFileBytes` (типово: 100 MB).
|
||||
Кожен файл ротуватиметься, коли досягне `logging.maxFileBytes` (за замовчуванням: 100 MB).
|
||||
OpenClaw зберігає до п’яти нумерованих архівів поруч з активним файлом, наприклад
|
||||
`openclaw-YYYY-MM-DD.1.log`, і продовжує запис у новий активний журнал замість
|
||||
приглушення діагностичних даних.
|
||||
@ -46,9 +47,9 @@ OpenClaw зберігає до п’яти нумерованих архівів
|
||||
|
||||
## Як читати журнали
|
||||
|
||||
### CLI: відстеження в реальному часі (рекомендовано)
|
||||
### CLI: live tail (рекомендовано)
|
||||
|
||||
Використовуйте CLI для відстеження файла журналу gateway через RPC:
|
||||
Використовуйте CLI, щоб відстежувати файл журналу gateway через RPC:
|
||||
|
||||
```bash
|
||||
openclaw logs --follow
|
||||
@ -56,23 +57,23 @@ openclaw logs --follow
|
||||
|
||||
Корисні поточні параметри:
|
||||
|
||||
- `--local-time`: відображати часові мітки у вашому локальному часовому поясі
|
||||
- `--local-time`: відображати часові позначки у вашому локальному часовому поясі
|
||||
- `--url <url>` / `--token <token>` / `--timeout <ms>`: стандартні прапорці Gateway RPC
|
||||
- `--expect-final`: прапорець очікування фінальної відповіді для RPC, що працює через агента (приймається тут через спільний клієнтський шар)
|
||||
- `--expect-final`: прапорець очікування фінальної відповіді для RPC з підтримкою агента (приймається тут через спільний клієнтський шар)
|
||||
|
||||
Режими виводу:
|
||||
Режими виведення:
|
||||
|
||||
- **TTY-сеанси**: гарні, кольорові, структуровані рядки журналу.
|
||||
- **Не-TTY-сеанси**: звичайний текст.
|
||||
- `--json`: JSON з розділенням по рядках (одна подія журналу на рядок).
|
||||
- `--json`: JSON з розділенням рядками (одна подія журналу на рядок).
|
||||
- `--plain`: примусово використовувати звичайний текст у TTY-сеансах.
|
||||
- `--no-color`: вимкнути кольори ANSI.
|
||||
|
||||
Коли ви передаєте явний `--url`, CLI не застосовує автоматично конфігурацію чи
|
||||
облікові дані середовища; якщо цільовий Gateway
|
||||
вимагає автентифікацію, вкажіть `--token` самостійно.
|
||||
Коли ви передаєте явний `--url`, CLI не застосовує автоматично облікові дані з конфігурації чи
|
||||
середовища; додайте `--token` самостійно, якщо цільовий Gateway
|
||||
вимагає автентифікації.
|
||||
|
||||
У режимі JSON CLI виводить об’єкти з міткою `type`:
|
||||
У режимі JSON CLI виводить об’єкти з тегом `type`:
|
||||
|
||||
- `meta`: метадані потоку (файл, курсор, розмір)
|
||||
- `log`: розібраний запис журналу
|
||||
@ -96,7 +97,7 @@ openclaw doctor
|
||||
|
||||
### Журнали лише каналу
|
||||
|
||||
Щоб відфільтрувати активність каналу (WhatsApp/Telegram тощо), використовуйте:
|
||||
Щоб фільтрувати активність каналу (WhatsApp/Telegram тощо), використовуйте:
|
||||
|
||||
```bash
|
||||
openclaw channels logs --channel whatsapp
|
||||
@ -106,23 +107,24 @@ openclaw channels logs --channel whatsapp
|
||||
|
||||
### Файлові журнали (JSONL)
|
||||
|
||||
Кожен рядок у файлі журналу — це об’єкт JSON. CLI і Control UI розбирають ці
|
||||
записи для відображення структурованого виводу (час, рівень, підсистема, повідомлення).
|
||||
Кожен рядок у файлі журналу — це об’єкт JSON. CLI та Control UI аналізують ці
|
||||
записи, щоб відобразити структурований вивід (час, рівень, підсистема, повідомлення).
|
||||
|
||||
Записи JSONL файлового журналу також містять машинно-фільтровані поля верхнього рівня, коли вони доступні:
|
||||
Записи JSONL у файловому журналі також містять машинно-фільтровані поля верхнього рівня, коли
|
||||
вони доступні:
|
||||
|
||||
- `hostname`: ім’я хоста gateway.
|
||||
- `message`: зведений текст повідомлення журналу для повнотекстового пошуку.
|
||||
- `agent_id`: id активного агента, коли виклик журналу містить контекст агента.
|
||||
- `session_id`: id/ключ активної сесії, коли виклик журналу містить контекст сесії.
|
||||
- `message`: сплощений текст повідомлення журналу для повнотекстового пошуку.
|
||||
- `agent_id`: ідентифікатор активного агента, коли виклик журналу містить контекст агента.
|
||||
- `session_id`: ідентифікатор/ключ активного сеансу, коли виклик журналу містить контекст сеансу.
|
||||
- `channel`: активний канал, коли виклик журналу містить контекст каналу.
|
||||
|
||||
OpenClaw зберігає оригінальні структуровані аргументи журналу поряд із цими полями,
|
||||
щоб наявні парсери, які читають нумеровані ключі аргументів tslog, продовжували працювати.
|
||||
щоб наявні аналізатори, які читають нумеровані ключі аргументів tslog, і надалі працювали.
|
||||
|
||||
### Вивід консолі
|
||||
### Виведення консолі
|
||||
|
||||
Журнали консолі **з урахуванням TTY** і відформатовані для зручності читання:
|
||||
Журнали консолі **враховують TTY** і форматуються для зручності читання:
|
||||
|
||||
- Префікси підсистем (наприклад, `gateway/channels/whatsapp`)
|
||||
- Кольорове виділення рівнів (info/warn/error)
|
||||
@ -130,13 +132,13 @@ OpenClaw зберігає оригінальні структуровані ар
|
||||
|
||||
Форматування консолі керується через `logging.consoleStyle`.
|
||||
|
||||
### Журнали WebSocket Gateway
|
||||
### Журнали Gateway WebSocket
|
||||
|
||||
`openclaw gateway` також має журналювання протоколу WebSocket для RPC-трафіку:
|
||||
|
||||
- звичайний режим: лише цікаві результати (помилки, помилки розбору, повільні виклики)
|
||||
- звичайний режим: лише важливі результати (помилки, помилки розбору, повільні виклики)
|
||||
- `--verbose`: увесь трафік запитів/відповідей
|
||||
- `--ws-log auto|compact|full`: вибір стилю докладного відображення
|
||||
- `--ws-log auto|compact|full`: вибір стилю детального відображення
|
||||
- `--compact`: псевдонім для `--ws-log compact`
|
||||
|
||||
Приклади:
|
||||
@ -149,7 +151,7 @@ openclaw gateway --verbose --ws-log full
|
||||
|
||||
## Налаштування журналювання
|
||||
|
||||
Усі налаштування журналювання розміщені в `logging` у `~/.openclaw/openclaw.json`.
|
||||
Уся конфігурація журналювання зберігається в розділі `logging` у `~/.openclaw/openclaw.json`.
|
||||
|
||||
```json
|
||||
{
|
||||
@ -169,80 +171,81 @@ openclaw gateway --verbose --ws-log full
|
||||
- `logging.level`: рівень **файлових журналів** (JSONL).
|
||||
- `logging.consoleLevel`: рівень деталізації **консолі**.
|
||||
|
||||
Ви можете перевизначити обидва через змінну середовища **`OPENCLAW_LOG_LEVEL`** (наприклад, `OPENCLAW_LOG_LEVEL=debug`). Змінна середовища має вищий пріоритет за файл конфігурації, тому ви можете підвищити рівень деталізації для одного запуску без редагування `openclaw.json`. Також можна передати глобальний параметр CLI **`--log-level <level>`** (наприклад, `openclaw --log-level debug gateway run`), який перевизначає змінну середовища для цієї команди.
|
||||
Ви можете перевизначити обидва через змінну середовища **`OPENCLAW_LOG_LEVEL`** (наприклад, `OPENCLAW_LOG_LEVEL=debug`). Змінна середовища має пріоритет над файлом конфігурації, тож ви можете підвищити деталізацію для одного запуску без редагування `openclaw.json`. Ви також можете передати глобальний параметр CLI **`--log-level <level>`** (наприклад, `openclaw --log-level debug gateway run`), який перевизначає змінну середовища для цієї команди.
|
||||
|
||||
`--verbose` впливає лише на вивід консолі та рівень деталізації журналів WS; він не змінює
|
||||
рівні файлових журналів.
|
||||
`--verbose` впливає лише на виведення консолі та деталізацію журналу WS; він не змінює
|
||||
рівні файлового журналу.
|
||||
|
||||
### Кореляція трасування
|
||||
### Кореляція трасувань
|
||||
|
||||
Файлові журнали мають формат JSONL. Коли виклик журналу містить коректний контекст діагностичного трасування,
|
||||
OpenClaw записує поля трасування як JSON-ключі верхнього рівня (`traceId`, `spanId`,
|
||||
`parentSpanId`, `traceFlags`), щоб зовнішні обробники журналів могли співвідносити рядок
|
||||
із діапазонами OTEL та поширенням `traceparent` у провайдера.
|
||||
`parentSpanId`, `traceFlags`), щоб зовнішні обробники журналів могли пов’язати цей рядок
|
||||
із span OTEL і поширенням `traceparent` у провайдері.
|
||||
|
||||
HTTP-запити Gateway і кадри WebSocket Gateway створюють внутрішню область трасування запиту.
|
||||
Журнали й діагностичні події, створені в межах цієї асинхронної області, успадковують
|
||||
трасування запиту, якщо їм не передано явний контекст трасування. Трасування запуску агента й
|
||||
виклику моделі стають дочірніми для активного трасування запиту, тому локальні журнали,
|
||||
діагностичні знімки, діапазони OTEL і довірені заголовки `traceparent` провайдера можна
|
||||
об’єднати за `traceId` без журналювання сирого вмісту запиту чи моделі.
|
||||
HTTP-запити Gateway і кадри Gateway WebSocket створюють внутрішню область
|
||||
трасування запиту. Журнали й діагностичні події, створені в межах цієї асинхронної області,
|
||||
успадковують трасування запиту, якщо не передають явний контекст трасування. Трасування запуску агента й
|
||||
виклику моделі стають дочірніми до активного трасування запиту, тож локальні журнали,
|
||||
діагностичні знімки, span OTEL і заголовки `traceparent` від довірених провайдерів можна
|
||||
поєднати за `traceId` без журналювання сирого вмісту запиту чи моделі.
|
||||
|
||||
### Розмір і тривалість виклику моделі
|
||||
### Розмір і час виклику моделі
|
||||
|
||||
Діагностичні дані виклику моделі фіксують обмежені вимірювання запиту/відповіді без
|
||||
захоплення сирого вмісту запиту або відповіді:
|
||||
Діагностика виклику моделі записує обмежені вимірювання запиту/відповіді без
|
||||
збереження сирого вмісту промпту чи відповіді:
|
||||
|
||||
- `requestPayloadBytes`: розмір у байтах UTF-8 фінального корисного навантаження запиту до моделі
|
||||
- `requestPayloadBytes`: розмір у байтах UTF-8 фінального payload запиту моделі
|
||||
- `responseStreamBytes`: розмір у байтах UTF-8 подій потокової відповіді моделі
|
||||
- `timeToFirstByteMs`: минулий час до першої події потокової відповіді
|
||||
- `timeToFirstByteMs`: затримка до першої події потокової відповіді
|
||||
- `durationMs`: загальна тривалість виклику моделі
|
||||
|
||||
Ці поля доступні для діагностичних знімків, хуків Plugin виклику моделі та
|
||||
діапазонів/метрик виклику моделі OTEL, коли ввімкнено експорт діагностики.
|
||||
Ці поля доступні для діагностичних знімків, хуків Plugin для викликів моделі та
|
||||
span/метрик викликів моделі в OTEL, коли ввімкнено експорт діагностики.
|
||||
|
||||
### Стилі консолі
|
||||
|
||||
`logging.consoleStyle`:
|
||||
|
||||
- `pretty`: зручний для читання людиною, кольоровий, із часовими мітками.
|
||||
- `pretty`: зручний для читання, кольоровий, із часовими позначками.
|
||||
- `compact`: щільніший вивід (найкраще для довгих сеансів).
|
||||
- `json`: JSON на рядок (для обробників журналів).
|
||||
- `json`: JSON у кожному рядку (для обробників журналів).
|
||||
|
||||
### Редагування конфіденційних даних
|
||||
|
||||
OpenClaw може маскувати конфіденційні токени до того, як вони потраплять у вивід консолі, файлові журнали,
|
||||
записи журналів OTLP або збережений текст стенограми сесії:
|
||||
OpenClaw може редагувати конфіденційні токени до того, як вони потраплять у виведення консолі, файлові журнали, записи журналів OTLP, збережений текст стенограми сеансу або payload подій інструментів у Control UI
|
||||
(аргументи запуску інструментів, payload часткових/фінальних результатів, похідне
|
||||
виведення exec і підсумки патчів):
|
||||
|
||||
- `logging.redactSensitive`: `off` | `tools` (типово: `tools`)
|
||||
- `logging.redactPatterns`: список рядків regex для перевизначення типового набору
|
||||
- `logging.redactSensitive`: `off` | `tools` (за замовчуванням: `tools`)
|
||||
- `logging.redactPatterns`: список рядків regex для перевизначення стандартного набору. Власні шаблони застосовуються поверх вбудованих значень за замовчуванням для payload інструментів у Control UI, тож додавання шаблону ніколи не послаблює редагування значень, які вже перехоплюються стандартними шаблонами.
|
||||
|
||||
Файлові журнали й стенограми сесій залишаються у форматі JSONL, але значення секретів, які збігаються,
|
||||
маскуються до того, як рядок або повідомлення буде записано на диск. Маскування виконується за принципом best-effort:
|
||||
Файлові журнали та стенограми сеансів залишаються у форматі JSONL, але значення секретів, що збігаються,
|
||||
маскуються до того, як рядок або повідомлення буде записано на диск. Редагування — це best-effort:
|
||||
воно застосовується до текстового вмісту повідомлень і рядків журналу, але не до кожного
|
||||
ідентифікатора чи поля двійкового корисного навантаження.
|
||||
ідентифікатора чи поля бінарного payload.
|
||||
|
||||
## Діагностика та OpenTelemetry
|
||||
|
||||
Діагностичні дані — це структуровані, машинозчитувані події для запусків моделей і
|
||||
телеметрії потоку повідомлень (Webhooks, постановка в чергу, стан сесії). Вони **не**
|
||||
замінюють журнали — вони живлять метрики, трасування та експортери. Події створюються
|
||||
Діагностика — це структуровані, машиночитані події для запусків моделей і
|
||||
телеметрії потоку повідомлень (webhook, постановка в чергу, стан сеансу). Вони **не**
|
||||
замінюють журнали — вони живлять метрики, трасування й експортери. Події створюються
|
||||
в процесі незалежно від того, експортуєте ви їх чи ні.
|
||||
|
||||
Дві суміжні поверхні:
|
||||
|
||||
- **Експорт OpenTelemetry** — надсилає метрики, трасування та журнали через OTLP/HTTP до
|
||||
- **Експорт OpenTelemetry** — надсилання метрик, трасувань і журналів через OTLP/HTTP до
|
||||
будь-якого колектора або бекенда, сумісного з OpenTelemetry (Grafana, Datadog,
|
||||
Honeycomb, New Relic, Tempo тощо). Повна конфігурація, каталог сигналів,
|
||||
назви метрик/діапазонів, змінні середовища й модель конфіденційності описані на окремій сторінці:
|
||||
назви метрик/span, змінні середовища та модель конфіденційності описані на окремій сторінці:
|
||||
[Експорт OpenTelemetry](/uk/gateway/opentelemetry).
|
||||
- **Прапорці діагностики** — цільові прапорці налагоджувальних журналів, які спрямовують додаткові журнали до
|
||||
- **Прапорці діагностики** — цільові прапорці налагоджувальних журналів, які спрямовують додаткові журнали в
|
||||
`logging.file` без підвищення `logging.level`. Прапорці нечутливі до регістру
|
||||
і підтримують шаблони з підстановками (`telegram.*`, `*`). Налаштовуються в `diagnostics.flags`
|
||||
або через перевизначення змінною середовища `OPENCLAW_DIAGNOSTICS=...`. Повний посібник:
|
||||
і підтримують шаблони (`telegram.*`, `*`). Налаштовуються в `diagnostics.flags`
|
||||
або через перевизначення змінної середовища `OPENCLAW_DIAGNOSTICS=...`. Повний посібник:
|
||||
[Прапорці діагностики](/uk/diagnostics/flags).
|
||||
|
||||
Щоб увімкнути діагностичні події для Plugins або власних приймачів без експорту OTLP:
|
||||
Щоб увімкнути діагностичні події для Plugin або власних приймачів без експорту OTLP:
|
||||
|
||||
```json5
|
||||
{
|
||||
@ -255,13 +258,13 @@ OpenClaw може маскувати конфіденційні токени д
|
||||
## Поради з усунення несправностей
|
||||
|
||||
- **Gateway недоступний?** Спочатку виконайте `openclaw doctor`.
|
||||
- **Журнали порожні?** Переконайтеся, що Gateway запущено і він записує у шлях до файла,
|
||||
вказаний у `logging.file`.
|
||||
- **Журнали порожні?** Перевірте, що Gateway запущено і він записує у шлях файлу,
|
||||
указаний у `logging.file`.
|
||||
- **Потрібно більше деталей?** Встановіть `logging.level` у `debug` або `trace` і повторіть спробу.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Експорт OpenTelemetry](/uk/gateway/opentelemetry) — експорт OTLP/HTTP, каталог метрик/діапазонів, модель конфіденційності
|
||||
- [Експорт OpenTelemetry](/uk/gateway/opentelemetry) — експорт OTLP/HTTP, каталог метрик/span, модель конфіденційності
|
||||
- [Прапорці діагностики](/uk/diagnostics/flags) — цільові прапорці налагоджувальних журналів
|
||||
- [Внутрішні механізми журналювання Gateway](/uk/gateway/logging) — стилі журналів WS, префікси підсистем і захоплення консолі
|
||||
- [Довідник конфігурації](/uk/gateway/configuration-reference#diagnostics) — повний довідник полів `diagnostics.*`
|
||||
- [Внутрішня будова журналювання Gateway](/uk/gateway/logging) — стилі журналів WS, префікси підсистем і перехоплення консолі
|
||||
- [Довідник із конфігурації](/uk/gateway/configuration-reference#diagnostics) — повний довідник полів `diagnostics.*`
|
||||
|
||||
@ -1,219 +1,219 @@
|
||||
---
|
||||
read_when:
|
||||
- Вибір правильного підшляху plugin-sdk для імпорту plugin
|
||||
- Вибір правильного підшляху plugin-sdk для імпорту в plugin
|
||||
- Аудит підшляхів bundled-plugin і допоміжних поверхонь
|
||||
summary: 'Каталог підшляхів Plugin SDK: які імпорти де розміщені, згруповано за областями'
|
||||
title: Підшляхи Plugin SDK
|
||||
x-i18n:
|
||||
generated_at: "2026-04-27T22:22:42Z"
|
||||
generated_at: "2026-04-27T22:51:30Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 56f76f2371500ab77dc791ba862cb628daec596059f1f9def7227fecb2826347
|
||||
source_hash: cbe2016ada89a5738f9786cd3c31091ea7cddc3131f13e949b63cee228b44913
|
||||
source_path: plugins/sdk-subpaths.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
Plugin SDK представлений як набір вузьких підшляхів у `openclaw/plugin-sdk/`.
|
||||
На цій сторінці наведено каталог поширено вживаних підшляхів, згрупованих за призначенням. Згенерований
|
||||
Plugin SDK доступний як набір вузьких підшляхів у `openclaw/plugin-sdk/`.
|
||||
Ця сторінка каталогізує найуживаніші підшляхи, згруповані за призначенням. Згенерований
|
||||
повний список із понад 200 підшляхів міститься в `scripts/lib/plugin-sdk-entrypoints.json`;
|
||||
зарезервовані допоміжні підшляхи bundled-plugin також наведені там, але є деталями
|
||||
реалізації, якщо лише сторінка документації явно не просуває їх.
|
||||
зарезервовані допоміжні підшляхи bundled-plugin також там наведені, але є
|
||||
деталлю реалізації, якщо лише сторінка документації явно не просуває їх.
|
||||
|
||||
Посібник з розробки plugin див. у [Огляд Plugin SDK](/uk/plugins/sdk-overview).
|
||||
|
||||
## Точка входу plugin
|
||||
|
||||
| Subpath | Основні експорти |
|
||||
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `plugin-sdk/plugin-entry` | `definePluginEntry` |
|
||||
| `plugin-sdk/core` | `defineChannelPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase`, `defineSetupPluginEntry`, `buildChannelConfigSchema` |
|
||||
| `plugin-sdk/config-schema` | `OpenClawSchema` |
|
||||
| `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry` |
|
||||
| `plugin-sdk/migration` | Допоміжні засоби елементів провайдера міграції, такі як `createMigrationItem`, константи причин, маркери статусу елементів, засоби редагування та `summarizeMigrationItems` |
|
||||
| `plugin-sdk/migration-runtime` | Допоміжні засоби міграції під час виконання, такі як `copyMigrationFileItem` і `writeMigrationReport` |
|
||||
| Підшлях | Ключові експорти |
|
||||
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `plugin-sdk/plugin-entry` | `definePluginEntry` |
|
||||
| `plugin-sdk/core` | `defineChannelPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase`, `defineSetupPluginEntry`, `buildChannelConfigSchema` |
|
||||
| `plugin-sdk/config-schema` | `OpenClawSchema` |
|
||||
| `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry` |
|
||||
| `plugin-sdk/migration` | Допоміжні елементи постачальника міграції, як-от `createMigrationItem`, константи причин, маркери статусу елемента, допоміжні засоби редагування та `summarizeMigrationItems` |
|
||||
| `plugin-sdk/migration-runtime` | Допоміжні засоби міграції під час виконання, як-от `copyMigrationFileItem` і `writeMigrationReport` |
|
||||
|
||||
<AccordionGroup>
|
||||
<Accordion title="Підшляхи каналів">
|
||||
| Subpath | Основні експорти |
|
||||
<Accordion title="Підшляхи каналу">
|
||||
| Підшлях | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/channel-core` | `defineChannelPluginEntry`, `defineSetupPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase` |
|
||||
| `plugin-sdk/config-schema` | Експорт кореневої Zod-схеми `openclaw.json` (`OpenClawSchema`) |
|
||||
| `plugin-sdk/channel-setup` | `createOptionalChannelSetupSurface`, `createOptionalChannelSetupAdapter`, `createOptionalChannelSetupWizard`, а також `DEFAULT_ACCOUNT_ID`, `createTopLevelChannelDmPolicy`, `setSetupChannelEnabled`, `splitSetupEntries` |
|
||||
| `plugin-sdk/setup` | Спільні допоміжні засоби майстра налаштування, підказки allowlist, побудовники статусу налаштування |
|
||||
| `plugin-sdk/setup` | Спільні допоміжні засоби майстра налаштування, запити allowlist, побудовники статусу налаштування |
|
||||
| `plugin-sdk/setup-runtime` | `createPatchedAccountSetupAdapter`, `createEnvPatchedAccountSetupAdapter`, `createSetupInputPresenceValidator`, `noteChannelLookupFailure`, `noteChannelLookupSummary`, `promptResolvedAllowFrom`, `splitSetupEntries`, `createAllowlistSetupWizardProxy`, `createDelegatedSetupWizardProxy` |
|
||||
| `plugin-sdk/setup-adapter-runtime` | `createEnvPatchedAccountSetupAdapter` |
|
||||
| `plugin-sdk/setup-tools` | `formatCliCommand`, `detectBinary`, `extractArchive`, `resolveBrewExecutable`, `formatDocsLink`, `CONFIG_DIR` |
|
||||
| `plugin-sdk/account-core` | Допоміжні засоби багатокористувацького конфігу/керування шлюзами дій, допоміжні засоби резервного переходу до типового облікового запису |
|
||||
| `plugin-sdk/account-core` | Допоміжні засоби багатoоблікового запису для конфігурації/обмеження дій, допоміжні засоби резервного облікового запису за замовчуванням |
|
||||
| `plugin-sdk/account-id` | `DEFAULT_ACCOUNT_ID`, допоміжні засоби нормалізації account-id |
|
||||
| `plugin-sdk/account-resolution` | Допоміжні засоби пошуку облікового запису + резервного переходу до типового |
|
||||
| `plugin-sdk/account-helpers` | Вузькі допоміжні засоби для списків облікових записів/дій з обліковими записами |
|
||||
| `plugin-sdk/account-resolution` | Пошук облікового запису + допоміжні засоби резервного значення за замовчуванням |
|
||||
| `plugin-sdk/account-helpers` | Вузькі допоміжні засоби для списку облікових записів/дій з обліковим записом |
|
||||
| `plugin-sdk/channel-pairing` | `createChannelPairingController` |
|
||||
| `plugin-sdk/channel-reply-pipeline` | `createChannelReplyPipeline` |
|
||||
| `plugin-sdk/channel-config-helpers` | `createHybridChannelConfigAdapter` |
|
||||
| `plugin-sdk/channel-config-schema` | Спільні примітиви схеми конфігу каналу та узагальнений побудовник |
|
||||
| `plugin-sdk/channel-config-schema-legacy` | Застарілі схеми конфігу bundled-channel лише для сумісності з вбудованими компонентами |
|
||||
| `plugin-sdk/telegram-command-config` | Допоміжні засоби нормалізації/валідації користувацьких команд Telegram із резервною сумісністю з bundled-contract |
|
||||
| `plugin-sdk/command-gating` | Вузькі допоміжні засоби шлюзу авторизації команд |
|
||||
| `plugin-sdk/channel-config-schema` | Спільні примітиви схеми конфігурації каналу та універсальний побудовник |
|
||||
| `plugin-sdk/channel-config-schema-legacy` | Застарілі схеми конфігурації bundled-channel лише для сумісності з bundled |
|
||||
| `plugin-sdk/telegram-command-config` | Допоміжні засоби нормалізації/валідації власних команд Telegram із резервною сумісністю bundled-contract |
|
||||
| `plugin-sdk/command-gating` | Вузькі допоміжні засоби перевірки авторизації команд |
|
||||
| `plugin-sdk/channel-policy` | `resolveChannelGroupRequireMention` |
|
||||
| `plugin-sdk/channel-lifecycle` | `createAccountStatusSink`, допоміжні засоби життєвого циклу/фіналізації потоку чернеток |
|
||||
| `plugin-sdk/inbound-envelope` | Спільні допоміжні засоби побудови вхідних маршрутів і envelope |
|
||||
| `plugin-sdk/inbound-reply-dispatch` | Спільні допоміжні засоби запису й диспетчеризації вхідних повідомлень |
|
||||
| `plugin-sdk/channel-lifecycle` | `createAccountStatusSink`, допоміжні засоби життєвого циклу/фіналізації чернетки потоку |
|
||||
| `plugin-sdk/inbound-envelope` | Спільні допоміжні засоби побудови вхідного маршруту + конверта |
|
||||
| `plugin-sdk/inbound-reply-dispatch` | Спільні допоміжні засоби запису й диспетчеризації вхідних відповідей |
|
||||
| `plugin-sdk/messaging-targets` | Допоміжні засоби розбору/зіставлення цілей |
|
||||
| `plugin-sdk/outbound-media` | Спільні допоміжні засоби завантаження вихідних медіа |
|
||||
| `plugin-sdk/outbound-send-deps` | Полегшений пошук залежностей вихідного надсилання для адаптерів каналів |
|
||||
| `plugin-sdk/outbound-runtime` | Допоміжні засоби вихідної доставки, ідентичності, делегата надсилання, сесій, форматування та планування payload |
|
||||
| `plugin-sdk/outbound-send-deps` | Полегшений пошук залежностей надсилання вихідних повідомлень для адаптерів каналів |
|
||||
| `plugin-sdk/outbound-runtime` | Допоміжні засоби доставки вихідних повідомлень, ідентичності, делегата надсилання, сесії, форматування та планування навантаження |
|
||||
| `plugin-sdk/poll-runtime` | Вузькі допоміжні засоби нормалізації опитувань |
|
||||
| `plugin-sdk/thread-bindings-runtime` | Життєвий цикл прив’язок потоків та допоміжні засоби адаптерів |
|
||||
| `plugin-sdk/agent-media-payload` | Застарілий побудовник agent media payload |
|
||||
| `plugin-sdk/conversation-runtime` | Допоміжні засоби для прив’язки розмов/потоків, pairинг і налаштованих прив’язок |
|
||||
| `plugin-sdk/thread-bindings-runtime` | Допоміжні засоби життєвого циклу прив’язок потоків і адаптерів |
|
||||
| `plugin-sdk/agent-media-payload` | Застарілий побудовник медіанавантаження агента |
|
||||
| `plugin-sdk/conversation-runtime` | Допоміжні засоби прив’язки розмови/потоку, парування та налаштованих прив’язок |
|
||||
| `plugin-sdk/runtime-config-snapshot` | Допоміжний засіб знімка конфігурації під час виконання |
|
||||
| `plugin-sdk/runtime-group-policy` | Допоміжні засоби визначення групових політик під час виконання |
|
||||
| `plugin-sdk/runtime-group-policy` | Допоміжні засоби розв’язання групової політики під час виконання |
|
||||
| `plugin-sdk/channel-status` | Спільні допоміжні засоби знімка/підсумку стану каналу |
|
||||
| `plugin-sdk/channel-config-primitives` | Вузькі примітиви схеми конфігу каналу |
|
||||
| `plugin-sdk/channel-config-writes` | Допоміжні засоби авторизації запису конфігу каналу |
|
||||
| `plugin-sdk/channel-plugin-common` | Спільні prelude-експорти plugin каналу |
|
||||
| `plugin-sdk/channel-config-primitives` | Вузькі примітиви схеми конфігурації каналу |
|
||||
| `plugin-sdk/channel-config-writes` | Допоміжні засоби авторизації запису конфігурації каналу |
|
||||
| `plugin-sdk/channel-plugin-common` | Спільні преамбулні експорти plugin каналу |
|
||||
| `plugin-sdk/allowlist-config-edit` | Допоміжні засоби редагування/читання конфігурації allowlist |
|
||||
| `plugin-sdk/group-access` | Спільні допоміжні засоби для рішень щодо групового доступу |
|
||||
| `plugin-sdk/direct-dm` | Спільні допоміжні засоби авторизації/захисту прямих DM |
|
||||
| `plugin-sdk/group-access` | Спільні допоміжні засоби прийняття рішень щодо групового доступу |
|
||||
| `plugin-sdk/direct-dm` | Спільні допоміжні засоби авторизації/захисту direct-DM |
|
||||
| `plugin-sdk/interactive-runtime` | Семантичне представлення повідомлень, доставка та застарілі допоміжні засоби інтерактивних відповідей. Див. [Представлення повідомлень](/uk/plugins/message-presentation) |
|
||||
| `plugin-sdk/channel-inbound` | Сумісний barrel для debounce вхідних повідомлень, зіставлення згадок, допоміжних засобів політики згадок та допоміжних засобів envelope |
|
||||
| `plugin-sdk/channel-inbound-debounce` | Вузькі допоміжні засоби debounce для вхідних повідомлень |
|
||||
| `plugin-sdk/channel-mention-gating` | Вузькі допоміжні засоби політики згадок, маркерів згадок і тексту згадок без ширшої поверхні inbound runtime |
|
||||
| `plugin-sdk/channel-envelope` | Вузькі допоміжні засоби форматування вхідних envelope |
|
||||
| `plugin-sdk/channel-location` | Допоміжні засоби контексту розташування каналу та форматування |
|
||||
| `plugin-sdk/channel-logging` | Допоміжні засоби журналювання каналу для відкинутих вхідних повідомлень і збоїв typing/ack |
|
||||
| `plugin-sdk/channel-inbound` | Барель сумісності для вхідного debounce, зіставлення згадок, допоміжних засобів політики згадок і допоміжних засобів конверта |
|
||||
| `plugin-sdk/channel-inbound-debounce` | Вузькі допоміжні засоби вхідного debounce |
|
||||
| `plugin-sdk/channel-mention-gating` | Вузькі допоміжні засоби політики згадок, маркерів згадок і тексту згадок без ширшої поверхні вхідного runtime |
|
||||
| `plugin-sdk/channel-envelope` | Вузькі допоміжні засоби форматування вхідного конверта |
|
||||
| `plugin-sdk/channel-location` | Допоміжні засоби контексту місцезнаходження каналу та форматування |
|
||||
| `plugin-sdk/channel-logging` | Допоміжні засоби журналювання каналу для скидання вхідних повідомлень і збоїв typing/ack |
|
||||
| `plugin-sdk/channel-send-result` | Типи результатів відповіді |
|
||||
| `plugin-sdk/channel-actions` | Допоміжні засоби дій із повідомленнями каналу, а також застарілі рідні допоміжні засоби схем, збережені для сумісності plugin |
|
||||
| `plugin-sdk/channel-actions` | Допоміжні засоби дій із повідомленнями каналу, а також застарілі нативні допоміжні засоби схем, збережені для сумісності plugin |
|
||||
| `plugin-sdk/channel-targets` | Допоміжні засоби розбору/зіставлення цілей |
|
||||
| `plugin-sdk/channel-contract` | Типи контрактів каналу |
|
||||
| `plugin-sdk/channel-feedback` | Підключення зворотного зв’язку/реакцій |
|
||||
| `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні засоби контрактів секретів, такі як `collectSimpleChannelFieldAssignments`, `getChannelSurface`, `pushAssignment`, і типи цілей секретів |
|
||||
| `plugin-sdk/channel-feedback` | Підключення feedback/reaction |
|
||||
| `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні засоби secret-contract, як-от `collectSimpleChannelFieldAssignments`, `getChannelSurface`, `pushAssignment`, і типи цілей секретів |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Підшляхи провайдерів">
|
||||
| Subpath | Основні експорти |
|
||||
<Accordion title="Підшляхи постачальника">
|
||||
| Підшлях | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry` |
|
||||
| `plugin-sdk/lmstudio` | Підтримуваний фасад провайдера LM Studio для налаштування, виявлення каталогу та підготовки моделей під час виконання |
|
||||
| `plugin-sdk/lmstudio-runtime` | Підтримуваний runtime-фасад LM Studio для типових локальних серверів, виявлення моделей, заголовків запитів і допоміжних засобів завантажених моделей |
|
||||
| `plugin-sdk/provider-setup` | Кураторський набір допоміжних засобів налаштування локальних/self-hosted провайдерів |
|
||||
| `plugin-sdk/self-hosted-provider-setup` | Сфокусовані допоміжні засоби налаштування self-hosted провайдерів, сумісних з OpenAI |
|
||||
| `plugin-sdk/cli-backend` | Типові значення CLI backend + константи watchdog |
|
||||
| `plugin-sdk/provider-auth-runtime` | Допоміжні засоби визначення API-ключа під час виконання для plugin провайдерів |
|
||||
| `plugin-sdk/provider-auth-api-key` | Допоміжні засоби онбордингу API-ключів/запису профілів, такі як `upsertApiKeyProfile` |
|
||||
| `plugin-sdk/lmstudio` | Підтримуваний фасад постачальника LM Studio для налаштування, виявлення каталогу та підготовки моделей під час виконання |
|
||||
| `plugin-sdk/lmstudio-runtime` | Підтримуваний фасад runtime LM Studio для локальних типових параметрів сервера, виявлення моделей, заголовків запитів і допоміжних засобів завантажених моделей |
|
||||
| `plugin-sdk/provider-setup` | Кураторські допоміжні засоби налаштування локальних/self-hosted постачальників |
|
||||
| `plugin-sdk/self-hosted-provider-setup` | Сфокусовані допоміжні засоби налаштування self-hosted постачальника, сумісного з OpenAI |
|
||||
| `plugin-sdk/cli-backend` | Типові значення backend CLI + константи watchdog |
|
||||
| `plugin-sdk/provider-auth-runtime` | Допоміжні засоби розв’язання API-ключів під час виконання для plugin постачальника |
|
||||
| `plugin-sdk/provider-auth-api-key` | Допоміжні засоби онбордингу/запису профілю API-ключа, як-от `upsertApiKeyProfile` |
|
||||
| `plugin-sdk/provider-auth-result` | Стандартний побудовник результату OAuth-автентифікації |
|
||||
| `plugin-sdk/provider-auth-login` | Спільні допоміжні засоби інтерактивного входу для plugin провайдерів |
|
||||
| `plugin-sdk/provider-env-vars` | Допоміжні засоби пошуку env vars для автентифікації провайдерів |
|
||||
| `plugin-sdk/provider-auth-login` | Спільні допоміжні засоби інтерактивного входу для plugin постачальника |
|
||||
| `plugin-sdk/provider-env-vars` | Допоміжні засоби пошуку змінних середовища автентифікації постачальника |
|
||||
| `plugin-sdk/provider-auth` | `createProviderApiKeyAuthMethod`, `ensureApiKeyFromOptionEnvOrPrompt`, `upsertAuthProfile`, `upsertApiKeyProfile`, `writeOAuthCredentials` |
|
||||
| `plugin-sdk/provider-model-shared` | `ProviderReplayFamily`, `buildProviderReplayFamilyHooks`, `normalizeModelCompat`, спільні побудовники політик повтору, допоміжні засоби endpoint провайдерів і допоміжні засоби нормалізації model-id, такі як `normalizeNativeXaiModelId` |
|
||||
| `plugin-sdk/provider-catalog-runtime` | Хуки runtime каталогу провайдерів і шви реєстру plugin-провайдерів для тестів контрактів |
|
||||
| `plugin-sdk/provider-model-shared` | `ProviderReplayFamily`, `buildProviderReplayFamilyHooks`, `normalizeModelCompat`, спільні побудовники політик повтору, допоміжні засоби endpoint постачальника та допоміжні засоби нормалізації model-id, як-от `normalizeNativeXaiModelId` |
|
||||
| `plugin-sdk/provider-catalog-runtime` | Гуки runtime каталогу постачальника та межі реєстру plugin-постачальників для контрактних тестів |
|
||||
| `plugin-sdk/provider-catalog-shared` | `findCatalogTemplate`, `buildSingleProviderApiKeyCatalog`, `supportsNativeStreamingUsageCompat`, `applyProviderNativeStreamingUsageCompat` |
|
||||
| `plugin-sdk/provider-http` | Загальні допоміжні засоби HTTP/endpoint-можливостей провайдерів, помилки HTTP провайдерів і допоміжні засоби multipart form для аудіотранскрипції |
|
||||
| `plugin-sdk/provider-web-fetch-contract` | Вузькі допоміжні засоби контрактів конфігурації/вибору web-fetch, такі як `enablePluginInConfig` і `WebFetchProviderPlugin` |
|
||||
| `plugin-sdk/provider-web-fetch` | Допоміжні засоби реєстрації/кешування провайдерів web-fetch |
|
||||
| `plugin-sdk/provider-web-search-config-contract` | Вузькі допоміжні засоби конфігурації/облікових даних web-search для провайдерів, яким не потрібне підключення увімкнення plugin |
|
||||
| `plugin-sdk/provider-web-search-contract` | Вузькі допоміжні засоби контрактів конфігурації/облікових даних web-search, такі як `createWebSearchProviderContractFields`, `enablePluginInConfig`, `resolveProviderWebSearchPluginConfig` і scoped setter/getter для облікових даних |
|
||||
| `plugin-sdk/provider-web-search` | Допоміжні засоби реєстрації/кешування/runtime для провайдерів web-search |
|
||||
| `plugin-sdk/provider-tools` | `ProviderToolCompatFamily`, `buildProviderToolCompatFamilyHooks`, очищення схеми Gemini + діагностика та допоміжні засоби сумісності xAI, такі як `resolveXaiModelCompatPatch` / `applyXaiModelCompat` |
|
||||
| `plugin-sdk/provider-http` | Загальні допоміжні засоби HTTP/можливостей endpoint постачальника, помилки HTTP постачальника та допоміжні засоби multipart-форм для транскрипції аудіо |
|
||||
| `plugin-sdk/provider-web-fetch-contract` | Вузькі допоміжні засоби контракту конфігурації/вибору web-fetch, як-от `enablePluginInConfig` і `WebFetchProviderPlugin` |
|
||||
| `plugin-sdk/provider-web-fetch` | Допоміжні засоби реєстрації/кешування постачальника web-fetch |
|
||||
| `plugin-sdk/provider-web-search-config-contract` | Вузькі допоміжні засоби конфігурації/облікових даних web-search для постачальників, яким не потрібне підключення ввімкнення plugin |
|
||||
| `plugin-sdk/provider-web-search-contract` | Вузькі допоміжні засоби контракту конфігурації/облікових даних web-search, як-от `createWebSearchProviderContractFields`, `enablePluginInConfig`, `resolveProviderWebSearchPluginConfig` і scoped setters/getters облікових даних |
|
||||
| `plugin-sdk/provider-web-search` | Допоміжні засоби реєстрації/кешування/runtime постачальника web-search |
|
||||
| `plugin-sdk/provider-tools` | `ProviderToolCompatFamily`, `buildProviderToolCompatFamilyHooks`, очищення схем Gemini + діагностика та допоміжні засоби сумісності xAI, як-от `resolveXaiModelCompatPatch` / `applyXaiModelCompat` |
|
||||
| `plugin-sdk/provider-usage` | `fetchClaudeUsage` та подібні |
|
||||
| `plugin-sdk/provider-stream` | `ProviderStreamFamily`, `buildProviderStreamFamilyHooks`, `composeProviderStreamWrappers`, типи обгорток потоків і спільні допоміжні засоби обгорток для Anthropic/Bedrock/DeepSeek V4/Google/Kilocode/Moonshot/OpenAI/OpenRouter/Z.A.I/MiniMax/Copilot |
|
||||
| `plugin-sdk/provider-transport-runtime` | Власні допоміжні засоби транспортного рівня провайдерів, такі як guarded fetch, перетворення транспортних повідомлень і записувані потоки транспортних подій |
|
||||
| `plugin-sdk/provider-transport-runtime` | Нативні допоміжні засоби транспорту постачальника, як-от guarded fetch, перетворення повідомлень транспорту та потоки подій writable transport |
|
||||
| `plugin-sdk/provider-onboard` | Допоміжні засоби патчів конфігурації онбордингу |
|
||||
| `plugin-sdk/global-singleton` | Допоміжні засоби process-local singleton/map/cache |
|
||||
| `plugin-sdk/group-activation` | Вузькі допоміжні засоби режиму активації груп і розбору команд |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Підшляхи автентифікації та безпеки">
|
||||
| Subpath | Основні експорти |
|
||||
| Підшлях | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/command-auth` | `resolveControlCommandGate`, допоміжні засоби реєстру команд, включно з форматуванням меню динамічних аргументів, допоміжні засоби авторизації відправника |
|
||||
| `plugin-sdk/command-status` | Побудовники повідомлень команд/довідки, такі як `buildCommandsMessagePaginated` і `buildHelpMessage` |
|
||||
| `plugin-sdk/approval-auth-runtime` | Допоміжні засоби визначення затверджувача та автентифікації дій у тому ж чаті |
|
||||
| `plugin-sdk/approval-client-runtime` | Допоміжні засоби профілю/фільтра native exec approval |
|
||||
| `plugin-sdk/approval-delivery-runtime` | Native-адаптери можливостей/доставки approval |
|
||||
| `plugin-sdk/approval-gateway-runtime` | Спільний допоміжний засіб визначення gateway для approval |
|
||||
| `plugin-sdk/approval-handler-adapter-runtime` | Полегшені допоміжні засоби завантаження native-адаптерів approval для гарячих точок входу каналів |
|
||||
| `plugin-sdk/approval-handler-runtime` | Ширші runtime-допоміжні засоби для approval; віддавайте перевагу вужчим адаптерним/Gateway-швам, коли їх достатньо |
|
||||
| `plugin-sdk/approval-native-runtime` | Допоміжні засоби native approval target + прив’язки облікових записів |
|
||||
| `plugin-sdk/approval-reply-runtime` | Допоміжні засоби payload відповідей для exec/plugin approval |
|
||||
| `plugin-sdk/approval-runtime` | Допоміжні засоби payload для exec/plugin approval, native-допоміжні засоби маршрутизації/runtime approval і допоміжні засоби структурованого відображення approval, такі як `formatApprovalDisplayPath` |
|
||||
| `plugin-sdk/command-status` | Побудовники повідомлень команд/довідки, як-от `buildCommandsMessagePaginated` і `buildHelpMessage` |
|
||||
| `plugin-sdk/approval-auth-runtime` | Допоміжні засоби визначення затверджувача та автентифікації дій у межах того самого чату |
|
||||
| `plugin-sdk/approval-client-runtime` | Допоміжні засоби профілю/фільтра нативного погодження exec |
|
||||
| `plugin-sdk/approval-delivery-runtime` | Нативні адаптери можливостей/доставки погодження |
|
||||
| `plugin-sdk/approval-gateway-runtime` | Спільний допоміжний засіб визначення Gateway для погодження |
|
||||
| `plugin-sdk/approval-handler-adapter-runtime` | Полегшені допоміжні засоби завантаження нативного адаптера погодження для гарячих точок входу каналів |
|
||||
| `plugin-sdk/approval-handler-runtime` | Ширші допоміжні засоби runtime обробника погодження; надавайте перевагу вужчим adapter/gateway межам, коли їх достатньо |
|
||||
| `plugin-sdk/approval-native-runtime` | Нативні допоміжні засоби цілей погодження + прив’язки облікового запису |
|
||||
| `plugin-sdk/approval-reply-runtime` | Допоміжні засоби корисного навантаження відповіді для погодження exec/plugin |
|
||||
| `plugin-sdk/approval-runtime` | Допоміжні засоби корисного навантаження погодження exec/plugin, допоміжні засоби нативної маршрутизації/runtime погодження та допоміжні засоби структурованого відображення погодження, як-от `formatApprovalDisplayPath` |
|
||||
| `plugin-sdk/reply-dedupe` | Вузькі допоміжні засоби скидання дедуплікації вхідних відповідей |
|
||||
| `plugin-sdk/channel-contract-testing` | Вузькі допоміжні засоби тестування контрактів каналів без широкого testing barrel |
|
||||
| `plugin-sdk/command-auth-native` | Native-автентифікація команд, форматування меню динамічних аргументів і native-допоміжні засоби цілей сесій |
|
||||
| `plugin-sdk/channel-contract-testing` | Вузькі допоміжні засоби тестування контрактів каналів без широкого бареля тестування |
|
||||
| `plugin-sdk/command-auth-native` | Нативна автентифікація команд, форматування меню динамічних аргументів і нативні допоміжні засоби session-target |
|
||||
| `plugin-sdk/command-detection` | Спільні допоміжні засоби виявлення команд |
|
||||
| `plugin-sdk/command-primitives-runtime` | Полегшені предикати тексту команд для гарячих шляхів каналів |
|
||||
| `plugin-sdk/command-surface` | Нормалізація тіла команд і допоміжні засоби поверхні команд |
|
||||
| `plugin-sdk/command-surface` | Допоміжні засоби нормалізації тіла команди та поверхні команди |
|
||||
| `plugin-sdk/allow-from` | `formatAllowFromLowercase` |
|
||||
| `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні засоби збирання секретних контрактів для поверхонь секретів channel/plugin |
|
||||
| `plugin-sdk/secret-ref-runtime` | Вузькі допоміжні засоби `coerceSecretRef` і типізації SecretRef для розбору секретних контрактів/конфігурації |
|
||||
| `plugin-sdk/security-runtime` | Спільні допоміжні засоби довіри, DM gating, зовнішнього вмісту, редагування чутливого тексту, порівняння секретів у сталий час і збирання секретів |
|
||||
| `plugin-sdk/ssrf-policy` | Допоміжні засоби політики SSRF для allowlist хостів і приватних мереж |
|
||||
| `plugin-sdk/ssrf-dispatcher` | Вузькі допоміжні засоби pinned-dispatcher без широкої infra runtime-поверхні |
|
||||
| `plugin-sdk/ssrf-runtime` | Допоміжні засоби pinned-dispatcher, fetch із захистом SSRF, помилка SSRF і допоміжні засоби політики SSRF |
|
||||
| `plugin-sdk/secret-input` | Допоміжні засоби розбору секретного введення |
|
||||
| `plugin-sdk/webhook-ingress` | Допоміжні засоби запитів/цілей Webhook і приведення raw websocket/body |
|
||||
| `plugin-sdk/webhook-request-guards` | Допоміжні засоби розміру тіла запиту/тайм-аутів |
|
||||
| `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні засоби збирання secret-contract для поверхонь секретів каналів/plugin |
|
||||
| `plugin-sdk/secret-ref-runtime` | Вузькі допоміжні засоби `coerceSecretRef` і типізації SecretRef для розбору secret-contract/config |
|
||||
| `plugin-sdk/security-runtime` | Спільні допоміжні засоби довіри, обмеження DM, зовнішнього вмісту, редагування чутливого тексту, порівняння секретів за сталим часом і збирання секретів |
|
||||
| `plugin-sdk/ssrf-policy` | Допоміжні засоби політики SSRF для allowlist хостів і приватної мережі |
|
||||
| `plugin-sdk/ssrf-dispatcher` | Вузькі допоміжні засоби pinned-dispatcher без широкої поверхні infra runtime |
|
||||
| `plugin-sdk/ssrf-runtime` | Допоміжні засоби pinned-dispatcher, fetch із захистом від SSRF, помилки SSRF і політики SSRF |
|
||||
| `plugin-sdk/secret-input` | Допоміжні засоби розбору введення секретів |
|
||||
| `plugin-sdk/webhook-ingress` | Допоміжні засоби запиту/цілі Webhook і приведення сирого websocket/body |
|
||||
| `plugin-sdk/webhook-request-guards` | Допоміжні засоби розміру тіла запиту/тайм-ауту |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Підшляхи runtime і сховища">
|
||||
| Subpath | Основні експорти |
|
||||
| Підшлях | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/runtime` | Широкі runtime/логування/резервного копіювання/встановлення plugin допоміжні засоби |
|
||||
| `plugin-sdk/runtime-env` | Вузькі допоміжні засоби runtime env, logger, timeout, retry і backoff |
|
||||
| `plugin-sdk/browser-config` | Підтримуваний фасад конфігурації браузера для нормалізованого профілю/типових значень, розбору CDP URL і допоміжних засобів автентифікації browser-control |
|
||||
| `plugin-sdk/channel-runtime-context` | Загальні допоміжні засоби реєстрації та пошуку runtime-context каналу |
|
||||
| `plugin-sdk/runtime` | Широкі допоміжні засоби runtime/журналювання/резервного копіювання/встановлення plugin |
|
||||
| `plugin-sdk/runtime-env` | Вузькі допоміжні засоби середовища runtime, логера, тайм-аутів, повторних спроб і backoff |
|
||||
| `plugin-sdk/browser-config` | Підтримуваний фасад конфігурації браузера для нормалізованого профілю/типових значень, розбору URL CDP і допоміжних засобів автентифікації керування браузером |
|
||||
| `plugin-sdk/channel-runtime-context` | Загальні допоміжні засоби реєстрації та пошуку channel runtime-context |
|
||||
| `plugin-sdk/runtime-store` | `createPluginRuntimeStore` |
|
||||
| `plugin-sdk/plugin-runtime` | Спільні допоміжні засоби command/hook/http/interactive для plugin |
|
||||
| `plugin-sdk/hook-runtime` | Спільні допоміжні засоби pipeline Webhook/internal hook |
|
||||
| `plugin-sdk/lazy-runtime` | Допоміжні засоби lazy runtime import/binding, такі як `createLazyRuntimeModule`, `createLazyRuntimeMethod` і `createLazyRuntimeSurface` |
|
||||
| `plugin-sdk/plugin-runtime` | Спільні допоміжні засоби команд/хуків/http/інтерактивності plugin |
|
||||
| `plugin-sdk/hook-runtime` | Спільні допоміжні засоби конвеєра Webhook/внутрішніх хуків |
|
||||
| `plugin-sdk/lazy-runtime` | Допоміжні засоби лінивого імпорту/прив’язки runtime, як-от `createLazyRuntimeModule`, `createLazyRuntimeMethod` і `createLazyRuntimeSurface` |
|
||||
| `plugin-sdk/process-runtime` | Допоміжні засоби виконання процесів |
|
||||
| `plugin-sdk/cli-runtime` | Допоміжні засоби форматування CLI, очікування, версій, виклику аргументів і lazy command-group |
|
||||
| `plugin-sdk/gateway-runtime` | Допоміжні засоби Gateway client, Gateway CLI RPC, помилок протоколу Gateway і патчів статусу каналу |
|
||||
| `plugin-sdk/config-types` | Поверхня конфігурації лише для типів для форм конфігурації plugin, таких як `OpenClawConfig` і типи конфігурації каналів/провайдерів |
|
||||
| `plugin-sdk/plugin-config-runtime` | Runtime-допоміжні засоби пошуку plugin-config, такі як `requireRuntimeConfig`, `resolvePluginConfigObject` і `resolveLivePluginConfigObject` |
|
||||
| `plugin-sdk/config-mutation` | Допоміжні засоби транзакційної мутації конфігурації, такі як `mutateConfigFile`, `replaceConfigFile` і `logConfigUpdated` |
|
||||
| `plugin-sdk/runtime-config-snapshot` | Допоміжні засоби знімка конфігурації поточного процесу, такі як `getRuntimeConfig`, `getRuntimeConfigSnapshot` і setter-и тестових знімків |
|
||||
| `plugin-sdk/cli-runtime` | Допоміжні засоби форматування CLI, очікування, версії, виклику аргументів і лінивих груп команд |
|
||||
| `plugin-sdk/gateway-runtime` | Клієнт Gateway, CLI RPC Gateway, помилки протоколу Gateway та допоміжні засоби патчів стану каналу |
|
||||
| `plugin-sdk/config-types` | Поверхня конфігурації лише для типів для форм конфігурації plugin, як-от `OpenClawConfig` і типів конфігурації каналів/постачальників |
|
||||
| `plugin-sdk/plugin-config-runtime` | Допоміжні засоби пошуку конфігурації plugin під час виконання, як-от `requireRuntimeConfig`, `resolvePluginConfigObject` і `resolveLivePluginConfigObject` |
|
||||
| `plugin-sdk/config-mutation` | Допоміжні засоби транзакційної мутації конфігурації, як-от `mutateConfigFile`, `replaceConfigFile` і `logConfigUpdated` |
|
||||
| `plugin-sdk/runtime-config-snapshot` | Допоміжні засоби знімка конфігурації поточного процесу, як-от `getRuntimeConfig`, `getRuntimeConfigSnapshot` і сетери тестових знімків |
|
||||
| `plugin-sdk/telegram-command-config` | Допоміжні засоби нормалізації назв/описів команд Telegram і перевірки дублікатів/конфліктів, навіть коли поверхня контракту bundled Telegram недоступна |
|
||||
| `plugin-sdk/text-autolink-runtime` | Виявлення autolink посилань на файли без широкого text-runtime barrel |
|
||||
| `plugin-sdk/approval-runtime` | Допоміжні засоби exec/plugin approval, побудовники можливостей approval, допоміжні засоби auth/profile, native-допоміжні засоби routing/runtime і форматування шляху структурованого відображення approval |
|
||||
| `plugin-sdk/reply-runtime` | Спільні runtime-допоміжні засоби inbound/reply, розбиття на частини, диспетчеризація, Heartbeat, планувальник відповідей |
|
||||
| `plugin-sdk/reply-dispatch-runtime` | Вузькі допоміжні засоби диспетчеризації/фіналізації відповідей і міток розмов |
|
||||
| `plugin-sdk/reply-history` | Спільні допоміжні засоби short-window history відповідей і маркери, такі як `buildHistoryContext`, `HISTORY_CONTEXT_MARKER`, `recordPendingHistoryEntry` і `clearHistoryEntriesIfEnabled` |
|
||||
| `plugin-sdk/text-autolink-runtime` | Виявлення автопосилань на файлові посилання без широкого бареля text-runtime |
|
||||
| `plugin-sdk/approval-runtime` | Допоміжні засоби погодження exec/plugin, побудовники можливостей погодження, допоміжні засоби автентифікації/профілю, нативної маршрутизації/runtime і форматування шляху структурованого відображення погодження |
|
||||
| `plugin-sdk/reply-runtime` | Спільні допоміжні засоби runtime для вхідних повідомлень/відповідей, чанкінгу, диспетчеризації, Heartbeat, планувальника відповідей |
|
||||
| `plugin-sdk/reply-dispatch-runtime` | Вузькі допоміжні засоби диспетчеризації/фіналізації відповідей і позначок розмов |
|
||||
| `plugin-sdk/reply-history` | Спільні допоміжні засоби історії відповідей для короткого вікна та маркери, як-от `buildHistoryContext`, `HISTORY_CONTEXT_MARKER`, `recordPendingHistoryEntry` і `clearHistoryEntriesIfEnabled` |
|
||||
| `plugin-sdk/reply-reference` | `createReplyReferencePlanner` |
|
||||
| `plugin-sdk/reply-chunking` | Вузькі допоміжні засоби chunking тексту/markdown |
|
||||
| `plugin-sdk/session-store-runtime` | Допоміжні засоби шляху сховища сесій, ключа сесії, updated-at і мутацій сховища |
|
||||
| `plugin-sdk/reply-chunking` | Вузькі допоміжні засоби чанкінгу тексту/markdown |
|
||||
| `plugin-sdk/session-store-runtime` | Допоміжні засоби шляху сховища сесій, session-key, updated-at і мутації сховища |
|
||||
| `plugin-sdk/cron-store-runtime` | Допоміжні засоби шляху/завантаження/збереження сховища Cron |
|
||||
| `plugin-sdk/state-paths` | Допоміжні засоби шляхів директорій state/OAuth |
|
||||
| `plugin-sdk/routing` | Допоміжні засоби маршрутизації/ключа сесії/прив’язки облікових записів, такі як `resolveAgentRoute`, `buildAgentSessionKey` і `resolveDefaultAgentBoundAccountId` |
|
||||
| `plugin-sdk/status-helpers` | Спільні допоміжні засоби підсумку стану каналу/облікового запису, типові значення runtime-state і допоміжні засоби метаданих проблем |
|
||||
| `plugin-sdk/state-paths` | Допоміжні засоби шляхів до каталогів стану/OAuth |
|
||||
| `plugin-sdk/routing` | Допоміжні засоби маршруту/ключа сесії/прив’язки облікового запису, як-от `resolveAgentRoute`, `buildAgentSessionKey` і `resolveDefaultAgentBoundAccountId` |
|
||||
| `plugin-sdk/status-helpers` | Спільні допоміжні засоби підсумку стану каналу/облікового запису, типових значень стану runtime та метаданих проблем |
|
||||
| `plugin-sdk/target-resolver-runtime` | Спільні допоміжні засоби визначення цілей |
|
||||
| `plugin-sdk/string-normalization-runtime` | Допоміжні засоби нормалізації slug/рядків |
|
||||
| `plugin-sdk/request-url` | Витягування рядкових URL з fetch/request-подібних входів |
|
||||
| `plugin-sdk/run-command` | Запускач команд із таймуванням і нормалізованими результатами stdout/stderr |
|
||||
| `plugin-sdk/param-readers` | Поширені зчитувачі параметрів tool/CLI |
|
||||
| `plugin-sdk/tool-payload` | Витягування нормалізованих payload з об’єктів результатів tool |
|
||||
| `plugin-sdk/request-url` | Витягування рядкових URL з вхідних даних типу fetch/request |
|
||||
| `plugin-sdk/run-command` | Виконавець команд із тайм-аутом і нормалізованими результатами stdout/stderr |
|
||||
| `plugin-sdk/param-readers` | Поширені читачі параметрів tool/CLI |
|
||||
| `plugin-sdk/tool-payload` | Витягування нормалізованих корисних навантажень з об’єктів результатів tool |
|
||||
| `plugin-sdk/tool-send` | Витягування канонічних полів цілі надсилання з аргументів tool |
|
||||
| `plugin-sdk/temp-path` | Спільні допоміжні засоби шляхів тимчасового завантаження |
|
||||
| `plugin-sdk/logging-core` | Допоміжні засоби logger підсистем і редагування |
|
||||
| `plugin-sdk/markdown-table-runtime` | Допоміжні засоби режиму таблиць Markdown і перетворення |
|
||||
| `plugin-sdk/model-session-runtime` | Допоміжні засоби перевизначення model/session, такі як `applyModelOverrideToSessionEntry` і `resolveAgentMaxConcurrent` |
|
||||
| `plugin-sdk/talk-config-runtime` | Допоміжні засоби визначення конфігурації talk provider |
|
||||
| `plugin-sdk/json-store` | Невеликі допоміжні засоби читання/запису JSON state |
|
||||
| `plugin-sdk/file-lock` | Допоміжні засоби реентерабельного file-lock |
|
||||
| `plugin-sdk/persistent-dedupe` | Допоміжні засоби дедуплікаційного кешу зберігання на диску |
|
||||
| `plugin-sdk/acp-runtime` | Допоміжні засоби ACP runtime/session і диспетчеризації відповідей |
|
||||
| `plugin-sdk/acp-binding-resolve-runtime` | Розв’язання прив’язки ACP лише для читання без імпортів запуску життєвого циклу |
|
||||
| `plugin-sdk/agent-config-primitives` | Вузькі примітиви схеми конфігурації agent runtime |
|
||||
| `plugin-sdk/boolean-param` | Нестрогий зчитувач булевих параметрів |
|
||||
| `plugin-sdk/temp-path` | Спільні допоміжні засоби шляхів до тимчасових завантажень |
|
||||
| `plugin-sdk/logging-core` | Допоміжні засоби логера підсистеми та редагування |
|
||||
| `plugin-sdk/markdown-table-runtime` | Допоміжні засоби режиму та перетворення таблиць Markdown |
|
||||
| `plugin-sdk/model-session-runtime` | Допоміжні засоби перевизначення моделі/сесії, як-от `applyModelOverrideToSessionEntry` і `resolveAgentMaxConcurrent` |
|
||||
| `plugin-sdk/talk-config-runtime` | Допоміжні засоби визначення конфігурації постачальника Talk |
|
||||
| `plugin-sdk/json-store` | Невеликі допоміжні засоби читання/запису стану JSON |
|
||||
| `plugin-sdk/file-lock` | Допоміжні засоби повторно вхідного блокування файлів |
|
||||
| `plugin-sdk/persistent-dedupe` | Допоміжні засоби кешу дедуплікації з дисковою підтримкою |
|
||||
| `plugin-sdk/acp-runtime` | Допоміжні засоби runtime/сесії ACP і диспетчеризації відповідей |
|
||||
| `plugin-sdk/acp-binding-resolve-runtime` | Визначення прив’язки ACP лише для читання без імпортів запуску життєвого циклу |
|
||||
| `plugin-sdk/agent-config-primitives` | Вузькі примітиви схеми конфігурації runtime агента |
|
||||
| `plugin-sdk/boolean-param` | Читач нечітких булевих параметрів |
|
||||
| `plugin-sdk/dangerous-name-runtime` | Допоміжні засоби визначення збігів небезпечних назв |
|
||||
| `plugin-sdk/device-bootstrap` | Допоміжні засоби початкового налаштування пристрою та pairing token |
|
||||
| `plugin-sdk/extension-shared` | Спільні примітиви допоміжних засобів passive-channel, status і ambient proxy |
|
||||
| `plugin-sdk/models-provider-runtime` | Допоміжні засоби відповідей команди `/models`/провайдера |
|
||||
| `plugin-sdk/device-bootstrap` | Допоміжні засоби bootstrap пристрою та токенів парування |
|
||||
| `plugin-sdk/extension-shared` | Спільні примітиви допоміжних засобів пасивних каналів, стану й ambient proxy |
|
||||
| `plugin-sdk/models-provider-runtime` | Допоміжні засоби відповідей команди `/models`/постачальника |
|
||||
| `plugin-sdk/skill-commands-runtime` | Допоміжні засоби переліку команд Skills |
|
||||
| `plugin-sdk/native-command-registry` | Допоміжні засоби реєстру/build/serialize native-команд |
|
||||
| `plugin-sdk/agent-harness` | Експериментальна поверхня trusted-plugin для низькорівневих harness agent: типи harness, допоміжні засоби steer/abort активного запуску, допоміжні засоби мосту OpenClaw tool, допоміжні засоби політики runtime-plan tool, класифікація результатів terminal, допоміжні засоби форматування/деталізації прогресу tool і утиліти результатів спроб |
|
||||
| `plugin-sdk/provider-zai-endpoint` | Допоміжні засоби виявлення endpoint Z.AI |
|
||||
| `plugin-sdk/async-lock-runtime` | Допоміжний засіб process-local async lock для невеликих runtime state-файлів |
|
||||
| `plugin-sdk/native-command-registry` | Допоміжні засоби реєстру/побудови/серіалізації нативних команд |
|
||||
| `plugin-sdk/agent-harness` | Експериментальна поверхня trusted-plugin для низькорівневих harness агента: типи harness, допоміжні засоби керування/переривання активного запуску, допоміжні засоби мосту tools OpenClaw, допоміжні засоби політики tools плану runtime, класифікація результатів terminal, допоміжні засоби форматування/деталізації прогресу tools і утиліти результатів спроб |
|
||||
| `plugin-sdk/provider-zai-endpoint` | Допоміжні засоби виявлення endpoint Z.A.I |
|
||||
| `plugin-sdk/async-lock-runtime` | Допоміжний засіб process-local async lock для невеликих файлів стану runtime |
|
||||
| `plugin-sdk/channel-activity-runtime` | Допоміжний засіб телеметрії активності каналу |
|
||||
| `plugin-sdk/concurrency-runtime` | Допоміжний засіб обмеженої конкурентності async-завдань |
|
||||
| `plugin-sdk/dedupe-runtime` | Допоміжні засоби кешу дедуплікації в пам’яті |
|
||||
@ -224,85 +224,85 @@ x-i18n:
|
||||
| `plugin-sdk/secure-random-runtime` | Допоміжні засоби безпечних токенів/UUID |
|
||||
| `plugin-sdk/system-event-runtime` | Допоміжні засоби черги системних подій |
|
||||
| `plugin-sdk/transport-ready-runtime` | Допоміжний засіб очікування готовності транспорту |
|
||||
| `plugin-sdk/infra-runtime` | Застарілий shim сумісності; використовуйте сфокусовані runtime-підшляхи вище |
|
||||
| `plugin-sdk/infra-runtime` | Застарілий shim сумісності; використовуйте сфокусовані підшляхи runtime вище |
|
||||
| `plugin-sdk/collection-runtime` | Невеликі допоміжні засоби обмеженого кешу |
|
||||
| `plugin-sdk/diagnostic-runtime` | Допоміжні засоби діагностичних прапорців, подій і trace-context |
|
||||
| `plugin-sdk/error-runtime` | Допоміжні засоби графа помилок, форматування, спільної класифікації помилок, `isApprovalNotFoundError` |
|
||||
| `plugin-sdk/fetch-runtime` | Допоміжні засоби обгорнутого fetch, proxy і pinned lookup |
|
||||
| `plugin-sdk/runtime-fetch` | Runtime fetch з урахуванням dispatcher без імпортів proxy/guarded-fetch |
|
||||
| `plugin-sdk/response-limit-runtime` | Допоміжний засіб читання обмеженого response-body без широкої media runtime-поверхні |
|
||||
| `plugin-sdk/session-binding-runtime` | Поточний стан прив’язки розмови без routing налаштованих прив’язок або pairing stores |
|
||||
| `plugin-sdk/session-store-runtime` | Допоміжні засоби session-store без широких імпортів запису/обслуговування конфігурації |
|
||||
| `plugin-sdk/context-visibility-runtime` | Визначення видимості контексту та фільтрація додаткового контексту без широких імпортів config/security |
|
||||
| `plugin-sdk/string-coerce-runtime` | Вузькі допоміжні засоби приведення та нормалізації primitive record/string без імпортів markdown/logging |
|
||||
| `plugin-sdk/host-runtime` | Допоміжні засоби нормалізації hostname і SCP host |
|
||||
| `plugin-sdk/retry-runtime` | Допоміжні засоби конфігурації retry і запуску retry |
|
||||
| `plugin-sdk/agent-runtime` | Допоміжні засоби директорії/ідентичності/робочого простору agent |
|
||||
| `plugin-sdk/directory-runtime` | Запит/дедуплікація директорій на основі конфігурації |
|
||||
| `plugin-sdk/runtime-fetch` | Dispatcher-aware runtime fetch без імпортів proxy/guarded-fetch |
|
||||
| `plugin-sdk/response-limit-runtime` | Обмежений читач тіла відповіді без широкої поверхні media runtime |
|
||||
| `plugin-sdk/session-binding-runtime` | Поточний стан прив’язки розмови без маршрутизації налаштованої прив’язки або сховищ парування |
|
||||
| `plugin-sdk/session-store-runtime` | Допоміжні засоби сховища сесій без широких імпортів запису/обслуговування конфігурації |
|
||||
| `plugin-sdk/context-visibility-runtime` | Допоміжні засоби визначення видимості контексту та фільтрації додаткового контексту без широких імпортів config/security |
|
||||
| `plugin-sdk/string-coerce-runtime` | Вузькі допоміжні засоби приведення та нормалізації примітивних record/string без імпортів markdown/logging |
|
||||
| `plugin-sdk/host-runtime` | Допоміжні засоби нормалізації імен хостів і хостів SCP |
|
||||
| `plugin-sdk/retry-runtime` | Допоміжні засоби конфігурації повторних спроб і виконавця повторів |
|
||||
| `plugin-sdk/agent-runtime` | Допоміжні засоби каталогу/ідентичності/робочого простору агента |
|
||||
| `plugin-sdk/directory-runtime` | Запит/дедуплікація каталогів на основі конфігурації |
|
||||
| `plugin-sdk/keyed-async-queue` | `KeyedAsyncQueue` |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Підшляхи можливостей і тестування">
|
||||
| Subpath | Основні експорти |
|
||||
| Підшлях | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/media-runtime` | Спільні допоміжні засоби отримання/перетворення/збереження медіа, а також побудовники media payload |
|
||||
| `plugin-sdk/media-store` | Вузькі допоміжні засоби сховища медіа, такі як `saveMediaBuffer` |
|
||||
| `plugin-sdk/media-generation-runtime` | Спільні допоміжні засоби failover для генерації медіа, вибір кандидатів і повідомлення про відсутню модель |
|
||||
| `plugin-sdk/media-understanding` | Типи провайдерів розуміння медіа, а також експорти image/audio helper для провайдерів |
|
||||
| `plugin-sdk/text-runtime` | Спільні допоміжні засоби text/markdown/logging, такі як видалення assistant-visible-text, допоміжні засоби render/chunking/table для markdown, допоміжні засоби редагування, допоміжні засоби тегів директив і утиліти safe-text |
|
||||
| `plugin-sdk/media-runtime` | Спільні допоміжні засоби fetch/transform/store для медіа, а також побудовники медіанавантаження |
|
||||
| `plugin-sdk/media-store` | Вузькі допоміжні засоби сховища медіа, як-от `saveMediaBuffer` |
|
||||
| `plugin-sdk/media-generation-runtime` | Спільні допоміжні засоби failover генерації медіа, вибору кандидатів і повідомлень про відсутню модель |
|
||||
| `plugin-sdk/media-understanding` | Типи постачальника розуміння медіа, а також експорти допоміжних засобів для зображень/аудіо, орієнтовані на постачальника |
|
||||
| `plugin-sdk/text-runtime` | Спільні допоміжні засоби тексту/markdown/журналювання, як-от видалення тексту, видимого помічнику, допоміжні засоби рендерингу/chunking/table Markdown, допоміжні засоби редагування, допоміжні засоби тегів директив і утиліти безпечного тексту |
|
||||
| `plugin-sdk/text-chunking` | Допоміжний засіб chunking вихідного тексту |
|
||||
| `plugin-sdk/speech` | Типи speech provider, а також експорти directive, registry, validation і speech helper для провайдерів |
|
||||
| `plugin-sdk/speech-core` | Спільні типи speech provider, registry, directive, normalization і експорти speech helper |
|
||||
| `plugin-sdk/realtime-transcription` | Типи провайдерів транскрипції в реальному часі, допоміжні засоби registry і спільний допоміжний засіб WebSocket session |
|
||||
| `plugin-sdk/realtime-voice` | Типи провайдерів голосу в реальному часі та допоміжні засоби registry |
|
||||
| `plugin-sdk/image-generation` | Типи провайдерів генерації зображень |
|
||||
| `plugin-sdk/image-generation-core` | Спільні типи генерації зображень, допоміжні засоби failover, auth і registry |
|
||||
| `plugin-sdk/music-generation` | Типи провайдерів/запитів/результатів генерації музики |
|
||||
| `plugin-sdk/music-generation-core` | Спільні типи генерації музики, допоміжні засоби failover, пошук провайдерів і розбір model-ref |
|
||||
| `plugin-sdk/video-generation` | Типи провайдерів/запитів/результатів генерації відео |
|
||||
| `plugin-sdk/video-generation-core` | Спільні типи генерації відео, допоміжні засоби failover, пошук провайдерів і розбір model-ref |
|
||||
| `plugin-sdk/speech` | Типи постачальника мовлення, а також експорти допоміжних засобів директив, реєстру, валідації та мовлення, орієнтовані на постачальника |
|
||||
| `plugin-sdk/speech-core` | Спільні типи постачальника мовлення, експорти допоміжних засобів реєстру, директив, нормалізації та мовлення |
|
||||
| `plugin-sdk/realtime-transcription` | Типи постачальника транскрипції в реальному часі, допоміжні засоби реєстру та спільний допоміжний засіб сесії WebSocket |
|
||||
| `plugin-sdk/realtime-voice` | Типи постачальника голосу в реальному часі та допоміжні засоби реєстру |
|
||||
| `plugin-sdk/image-generation` | Типи постачальника генерації зображень |
|
||||
| `plugin-sdk/image-generation-core` | Спільні типи генерації зображень, допоміжні засоби failover, автентифікації та реєстру |
|
||||
| `plugin-sdk/music-generation` | Типи постачальника/запиту/результату генерації музики |
|
||||
| `plugin-sdk/music-generation-core` | Спільні типи генерації музики, допоміжні засоби failover, пошуку постачальника та розбору model-ref |
|
||||
| `plugin-sdk/video-generation` | Типи постачальника/запиту/результату генерації відео |
|
||||
| `plugin-sdk/video-generation-core` | Спільні типи генерації відео, допоміжні засоби failover, пошуку постачальника та розбору model-ref |
|
||||
| `plugin-sdk/webhook-targets` | Допоміжні засоби реєстру цілей Webhook і встановлення маршрутів |
|
||||
| `plugin-sdk/webhook-path` | Допоміжні засоби нормалізації шляху Webhook |
|
||||
| `plugin-sdk/webhook-path` | Допоміжні засоби нормалізації шляхів Webhook |
|
||||
| `plugin-sdk/web-media` | Спільні допоміжні засоби завантаження віддалених/локальних медіа |
|
||||
| `plugin-sdk/zod` | Повторно експортований `zod` для споживачів Plugin SDK |
|
||||
| `plugin-sdk/testing` | Публічні допоміжні засоби тестування extensions, включно з mock-об’єктами registry/runtime plugin, fetch/env/temp fixtures, допоміжними засобами schema/media/live-test, `installCommonResolveTargetErrorCases`, `writeSkill`, `createTestRegistry` і завантаженням env для live generation. Допоміжні засоби Extension `*.test-support.ts` мають залишатися тут або у сфокусованих підшляхах SDK, а не у внутрішніх компонентах core |
|
||||
| `plugin-sdk/zod` | Повторно експортований `zod` для користувачів Plugin SDK |
|
||||
| `plugin-sdk/testing` | Публічні допоміжні засоби тестування розширень, включно з моками реєстру/runtime plugin, захопленням реєстрації постачальника, допоміжними засобами майстра налаштування, фікстурами fetch/env/temp/time, допоміжними засобами schema/media/live-test, `installCommonResolveTargetErrorCases`, `writeSkill`, `createTestRegistry` і завантаженням env для live generation. Допоміжні засоби розширень `*.test-support.ts` мають лишатися тут або у сфокусованих підшляхах SDK, а не у внутрішніх модулях core |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Підшляхи пам’яті">
|
||||
| Subpath | Основні експорти |
|
||||
| Підшлях | Ключові експорти |
|
||||
| --- | --- |
|
||||
| `plugin-sdk/memory-core` | Поверхня допоміжних засобів bundled memory-core для manager/config/file/CLI helper |
|
||||
| `plugin-sdk/memory-core-engine-runtime` | Runtime-фасад індексу/пошуку пам’яті |
|
||||
| `plugin-sdk/memory-core-host-engine-foundation` | Експорти foundation engine host-а пам’яті |
|
||||
| `plugin-sdk/memory-core-host-engine-embeddings` | Контракти embedding host-а пам’яті, доступ до registry, локальний провайдер і загальні пакетні/віддалені helper |
|
||||
| `plugin-sdk/memory-core-host-engine-qmd` | Експорти QMD engine host-а пам’яті |
|
||||
| `plugin-sdk/memory-core-host-engine-storage` | Експорти engine сховища host-а пам’яті |
|
||||
| `plugin-sdk/memory-core-host-multimodal` | Мультимодальні helper host-а пам’яті |
|
||||
| `plugin-sdk/memory-core-host-query` | Helper запитів host-а пам’яті |
|
||||
| `plugin-sdk/memory-core-host-secret` | Helper секретів host-а пам’яті |
|
||||
| `plugin-sdk/memory-core-host-events` | Helper журналу подій host-а пам’яті |
|
||||
| `plugin-sdk/memory-core-host-status` | Helper статусу host-а пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-cli` | Runtime helper CLI host-а пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-core` | Core runtime helper host-а пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-files` | File/runtime helper host-а пам’яті |
|
||||
| `plugin-sdk/memory-host-core` | Нейтральний до вендора псевдонім для core runtime helper host-а пам’яті |
|
||||
| `plugin-sdk/memory-host-events` | Нейтральний до вендора псевдонім для helper журналу подій host-а пам’яті |
|
||||
| `plugin-sdk/memory-host-files` | Нейтральний до вендора псевдонім для file/runtime helper host-а пам’яті |
|
||||
| `plugin-sdk/memory-host-markdown` | Спільні helper керованого markdown для plugin, суміжних із пам’яттю |
|
||||
| `plugin-sdk/memory-host-search` | Runtime-фасад Active Memory для доступу до менеджера пошуку |
|
||||
| `plugin-sdk/memory-host-status` | Нейтральний до вендора псевдонім для helper статусу host-а пам’яті |
|
||||
| `plugin-sdk/memory-core` | Поверхня допоміжних засобів bundled memory-core для менеджера/конфігурації/файлів/допоміжних засобів CLI |
|
||||
| `plugin-sdk/memory-core-engine-runtime` | Фасад runtime індексу/пошуку пам’яті |
|
||||
| `plugin-sdk/memory-core-host-engine-foundation` | Експорти foundation engine хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-engine-embeddings` | Контракти embedding хоста пам’яті, доступ до реєстру, локальний постачальник і загальні допоміжні засоби batch/remote |
|
||||
| `plugin-sdk/memory-core-host-engine-qmd` | Експорти QMD engine хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-engine-storage` | Експорти storage engine хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-multimodal` | Багатомодальні допоміжні засоби хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-query` | Допоміжні засоби запитів хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-secret` | Допоміжні засоби секретів хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-events` | Допоміжні засоби журналу подій хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-status` | Допоміжні засоби стану хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-cli` | Допоміжні засоби runtime CLI хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-core` | Допоміжні засоби core runtime хоста пам’яті |
|
||||
| `plugin-sdk/memory-core-host-runtime-files` | Допоміжні засоби файлів/runtime хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-core` | Нейтральний до постачальника псевдонім для допоміжних засобів core runtime хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-events` | Нейтральний до постачальника псевдонім для допоміжних засобів журналу подій хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-files` | Нейтральний до постачальника псевдонім для допоміжних засобів файлів/runtime хоста пам’яті |
|
||||
| `plugin-sdk/memory-host-markdown` | Спільні допоміжні засоби керованого markdown для plugin, суміжних із пам’яттю |
|
||||
| `plugin-sdk/memory-host-search` | Фасад runtime Active Memory для доступу до менеджера пошуку |
|
||||
| `plugin-sdk/memory-host-status` | Нейтральний до постачальника псевдонім для допоміжних засобів стану хоста пам’яті |
|
||||
| `plugin-sdk/memory-lancedb` | Поверхня допоміжних засобів bundled memory-lancedb |
|
||||
</Accordion>
|
||||
|
||||
<Accordion title="Зарезервовані підшляхи bundled-helper">
|
||||
| Family | Поточні підшляхи | Призначення |
|
||||
| Сімейство | Поточні підшляхи | Призначення |
|
||||
| --- | --- | --- |
|
||||
| Browser | `plugin-sdk/browser-cdp`, `plugin-sdk/browser-config-runtime`, `plugin-sdk/browser-config-support`, `plugin-sdk/browser-control-auth`, `plugin-sdk/browser-node-runtime`, `plugin-sdk/browser-profiles`, `plugin-sdk/browser-security-runtime`, `plugin-sdk/browser-setup-tools`, `plugin-sdk/browser-support` | Допоміжні засоби підтримки bundled browser plugin. `browser-profiles` експортує `resolveBrowserConfig`, `resolveProfile`, `ResolvedBrowserConfig`, `ResolvedBrowserProfile` і `ResolvedBrowserTabCleanupConfig` для нормалізованої форми `browser.tabCleanup`. `browser-support` залишається compatibility barrel. |
|
||||
| Matrix | `plugin-sdk/matrix`, `plugin-sdk/matrix-helper`, `plugin-sdk/matrix-runtime-heavy`, `plugin-sdk/matrix-runtime-shared`, `plugin-sdk/matrix-runtime-surface`, `plugin-sdk/matrix-surface`, `plugin-sdk/matrix-thread-bindings` | Поверхня helper/runtime bundled Matrix |
|
||||
| Line | `plugin-sdk/line`, `plugin-sdk/line-core`, `plugin-sdk/line-runtime`, `plugin-sdk/line-surface` | Поверхня helper/runtime bundled LINE |
|
||||
| IRC | `plugin-sdk/irc`, `plugin-sdk/irc-surface` | Поверхня helper bundled IRC |
|
||||
| Специфічні для каналів helper | `plugin-sdk/googlechat`, `plugin-sdk/googlechat-runtime-shared`, `plugin-sdk/zalouser`, `plugin-sdk/bluebubbles`, `plugin-sdk/bluebubbles-policy`, `plugin-sdk/mattermost`, `plugin-sdk/mattermost-policy`, `plugin-sdk/feishu`, `plugin-sdk/feishu-conversation`, `plugin-sdk/feishu-setup`, `plugin-sdk/msteams`, `plugin-sdk/nextcloud-talk`, `plugin-sdk/nostr`, `plugin-sdk/telegram-command-ui`, `plugin-sdk/tlon`, `plugin-sdk/twitch`, `plugin-sdk/zalo`, `plugin-sdk/zalo-setup` | Застарілі шви сумісності/helper для bundled channel. Нові plugins повинні імпортувати загальні підшляхи SDK або plugin-local barrel. |
|
||||
| Helper автентифікації/специфічні для plugin | `plugin-sdk/github-copilot-login`, `plugin-sdk/github-copilot-token`, `plugin-sdk/diagnostics-otel`, `plugin-sdk/diagnostics-prometheus`, `plugin-sdk/diffs`, `plugin-sdk/llm-task`, `plugin-sdk/memory-core`, `plugin-sdk/memory-lancedb`, `plugin-sdk/opencode`, `plugin-sdk/thread-ownership`, `plugin-sdk/voice-call` | Шви helper для bundled feature/plugin; `plugin-sdk/github-copilot-token` наразі експортує `DEFAULT_COPILOT_API_BASE_URL`, `deriveCopilotApiBaseUrlFromToken` і `resolveCopilotApiToken` |
|
||||
| Browser | `plugin-sdk/browser-cdp`, `plugin-sdk/browser-config-runtime`, `plugin-sdk/browser-config-support`, `plugin-sdk/browser-control-auth`, `plugin-sdk/browser-node-runtime`, `plugin-sdk/browser-profiles`, `plugin-sdk/browser-security-runtime`, `plugin-sdk/browser-setup-tools`, `plugin-sdk/browser-support` | Допоміжні засоби підтримки bundled browser plugin. `browser-profiles` експортує `resolveBrowserConfig`, `resolveProfile`, `ResolvedBrowserConfig`, `ResolvedBrowserProfile` і `ResolvedBrowserTabCleanupConfig` для нормалізованої форми `browser.tabCleanup`. `browser-support` лишається барелем сумісності. |
|
||||
| Matrix | `plugin-sdk/matrix`, `plugin-sdk/matrix-helper`, `plugin-sdk/matrix-runtime-heavy`, `plugin-sdk/matrix-runtime-shared`, `plugin-sdk/matrix-runtime-surface`, `plugin-sdk/matrix-surface`, `plugin-sdk/matrix-thread-bindings` | Поверхня допоміжних засобів/runtime bundled Matrix |
|
||||
| Line | `plugin-sdk/line`, `plugin-sdk/line-core`, `plugin-sdk/line-runtime`, `plugin-sdk/line-surface` | Поверхня допоміжних засобів/runtime bundled LINE |
|
||||
| IRC | `plugin-sdk/irc`, `plugin-sdk/irc-surface` | Поверхня допоміжних засобів bundled IRC |
|
||||
| Допоміжні засоби для конкретних каналів | `plugin-sdk/googlechat`, `plugin-sdk/googlechat-runtime-shared`, `plugin-sdk/zalouser`, `plugin-sdk/bluebubbles`, `plugin-sdk/bluebubbles-policy`, `plugin-sdk/mattermost`, `plugin-sdk/mattermost-policy`, `plugin-sdk/feishu`, `plugin-sdk/feishu-conversation`, `plugin-sdk/feishu-setup`, `plugin-sdk/msteams`, `plugin-sdk/nextcloud-talk`, `plugin-sdk/nostr`, `plugin-sdk/telegram-command-ui`, `plugin-sdk/tlon`, `plugin-sdk/twitch`, `plugin-sdk/zalo`, `plugin-sdk/zalo-setup` | Застарілі межі сумісності/допоміжних засобів bundled channel. Нові plugins мають імпортувати загальні підшляхи SDK або локальні барелі plugin. |
|
||||
| Допоміжні засоби для автентифікації/конкретних plugin | `plugin-sdk/github-copilot-login`, `plugin-sdk/github-copilot-token`, `plugin-sdk/diagnostics-otel`, `plugin-sdk/diagnostics-prometheus`, `plugin-sdk/diffs`, `plugin-sdk/llm-task`, `plugin-sdk/memory-core`, `plugin-sdk/memory-lancedb`, `plugin-sdk/opencode`, `plugin-sdk/thread-ownership`, `plugin-sdk/voice-call` | Межі допоміжних засобів bundled feature/plugin; `plugin-sdk/github-copilot-token` наразі експортує `DEFAULT_COPILOT_API_BASE_URL`, `deriveCopilotApiBaseUrlFromToken` і `resolveCopilotApiToken` |
|
||||
</Accordion>
|
||||
</AccordionGroup>
|
||||
|
||||
|
||||
@ -2,32 +2,32 @@
|
||||
read_when:
|
||||
- Ви пишете тести для Plugin
|
||||
- Вам потрібні утиліти тестування з SDK Plugin
|
||||
- Ви хочете зрозуміти контрактні тести для вбудованих Plugin
|
||||
- Ви хочете зрозуміти контрактні тести для вбудованих плагінів
|
||||
sidebarTitle: Testing
|
||||
summary: Утиліти та шаблони тестування для Plugin OpenClaw
|
||||
summary: Утиліти та шаблони тестування для плагінів OpenClaw
|
||||
title: Тестування Plugin
|
||||
x-i18n:
|
||||
generated_at: "2026-04-27T22:22:43Z"
|
||||
generated_at: "2026-04-27T22:51:29Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 358a1e76d6a8e78ad503b040d49bab7f66fa8bfb2f1fe7dcb6088ef932e56860
|
||||
source_hash: ad2e95d9db988610931391c37f1fef12014dff717ceb1647bca241a1a438aeae
|
||||
source_path: plugins/sdk-testing.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
Довідник з утиліт тестування, шаблонів і забезпечення правил lint для Plugin OpenClaw.
|
||||
Довідник з утиліт тестування, шаблонів і примусового застосування lint для плагінів OpenClaw.
|
||||
|
||||
<Tip>
|
||||
**Шукаєте приклади тестів?** Практичні посібники містять готові приклади тестів:
|
||||
[Тести Channel Plugin](/uk/plugins/sdk-channel-plugins#step-6-test) і
|
||||
[Тести Provider Plugin](/uk/plugins/sdk-provider-plugins#step-6-test).
|
||||
[Тести плагінів каналів](/uk/plugins/sdk-channel-plugins#step-6-test) і
|
||||
[Тести плагінів провайдерів](/uk/plugins/sdk-provider-plugins#step-6-test).
|
||||
</Tip>
|
||||
|
||||
## Утиліти тестування
|
||||
|
||||
**Імпорт:** `openclaw/plugin-sdk/testing`
|
||||
|
||||
Підшлях testing експортує вузький набір допоміжних засобів для авторів Plugin:
|
||||
Підшлях testing експортує вузький набір допоміжних засобів для авторів плагінів:
|
||||
|
||||
```typescript
|
||||
import {
|
||||
@ -39,26 +39,33 @@ import {
|
||||
|
||||
### Доступні експорти
|
||||
|
||||
| Export | Purpose |
|
||||
| -------------------------------------- | ------------------------------------------------- |
|
||||
| `installCommonResolveTargetErrorCases` | Спільні тестові випадки для обробки помилок під час визначення цілі |
|
||||
| `shouldAckReaction` | Перевіряє, чи повинен канал додавати реакцію-підтвердження |
|
||||
| `removeAckReactionAfterReply` | Видаляє реакцію-підтвердження після доставки відповіді |
|
||||
| `createTestRegistry` | Створює фікстуру реєстру Channel Plugin |
|
||||
| `createEmptyPluginRegistry` | Створює порожню фікстуру реєстру Plugin |
|
||||
| `setActivePluginRegistry` | Встановлює фікстуру реєстру для runtime-тестів Plugin |
|
||||
| `createRequestCaptureJsonFetch` | Перехоплює JSON fetch-запити в тестах медіадопоміжників |
|
||||
| `withFetchPreconnect` | Запускає fetch-тести зі встановленими хуками preconnect |
|
||||
| `withEnv` / `withEnvAsync` | Тимчасово підміняє змінні середовища |
|
||||
| `createTempHomeEnv` / `withTempDir` | Створює ізольовані файлові фікстури для тестів |
|
||||
| `createMockServerResponse` | Створює мінімальний mock-відповідь HTTP-сервера |
|
||||
| `registerSingleProviderPlugin` | Реєструє один Provider Plugin у smoke-тестах завантажувача |
|
||||
| `createRuntimeTaskFlow` | Створює ізольований стан runtime TaskFlow |
|
||||
| `typedCases` | Зберігає literal-типи для табличних тестів |
|
||||
| Експорт | Призначення |
|
||||
| -------------------------------------- | ------------------------------------------------------ |
|
||||
| `installCommonResolveTargetErrorCases` | Спільні тестові випадки для обробки помилок визначення цілі |
|
||||
| `shouldAckReaction` | Перевіряє, чи повинен канал додавати реакцію підтвердження |
|
||||
| `removeAckReactionAfterReply` | Видаляє реакцію підтвердження після доставки відповіді |
|
||||
| `createTestRegistry` | Створює фікстуру реєстру плагінів каналів |
|
||||
| `createEmptyPluginRegistry` | Створює порожню фікстуру реєстру плагінів |
|
||||
| `setActivePluginRegistry` | Встановлює фікстуру реєстру для тестів часу виконання плагіна |
|
||||
| `createRequestCaptureJsonFetch` | Перехоплює запити JSON fetch у тестах допоміжних засобів для медіа |
|
||||
| `withFetchPreconnect` | Запускає тести fetch із встановленими хуками preconnect |
|
||||
| `withEnv` / `withEnvAsync` | Тимчасово змінює змінні середовища |
|
||||
| `createTempHomeEnv` / `withTempDir` | Створює ізольовані файлові фікстури для тестів |
|
||||
| `createMockServerResponse` | Створює мінімальний мок відповіді HTTP-сервера |
|
||||
| `registerSingleProviderPlugin` | Реєструє один плагін провайдера в smoke-тестах завантажувача |
|
||||
| `registerProviderPlugin` | Перехоплює всі типи провайдерів з одного плагіна |
|
||||
| `requireRegisteredProvider` | Перевіряє, що колекція провайдерів містить id |
|
||||
| `createProviderUsageFetch` | Створює фікстури fetch для використання провайдера |
|
||||
| `useFrozenTime` / `useRealTime` | Заморожує та відновлює таймери для чутливих до часу тестів |
|
||||
| `createRuntimeEnv` | Створює замокане середовище виконання CLI/плагіна |
|
||||
| `createTestWizardPrompter` | Створює замоканий prompter майстра налаштування |
|
||||
| `createPluginSetupWizardStatus` | Створює допоміжні засоби стану налаштування для плагінів каналів |
|
||||
| `createRuntimeTaskFlow` | Створює ізольований стан TaskFlow часу виконання |
|
||||
| `typedCases` | Зберігає literal-типи для таблично-керованих тестів |
|
||||
|
||||
### Типи
|
||||
|
||||
Підшлях testing також повторно експортує типи, корисні у тестових файлах:
|
||||
Підшлях testing також повторно експортує типи, корисні у файлах тестів:
|
||||
|
||||
```typescript
|
||||
import type {
|
||||
@ -79,16 +86,16 @@ import type {
|
||||
import { describe } from "vitest";
|
||||
import { installCommonResolveTargetErrorCases } from "openclaw/plugin-sdk/testing";
|
||||
|
||||
describe("my-channel target resolution", () => {
|
||||
describe("визначення цілі my-channel", () => {
|
||||
installCommonResolveTargetErrorCases({
|
||||
resolveTarget: ({ to, mode, allowFrom }) => {
|
||||
// Your channel's target resolution logic
|
||||
// Логіка визначення цілі вашого каналу
|
||||
return myChannelResolveTarget({ to, mode, allowFrom });
|
||||
},
|
||||
implicitAllowFrom: ["user1", "user2"],
|
||||
});
|
||||
|
||||
// Add channel-specific test cases
|
||||
// Додайте специфічні для каналу тестові випадки
|
||||
it("should resolve @username targets", () => {
|
||||
// ...
|
||||
});
|
||||
@ -99,20 +106,22 @@ describe("my-channel target resolution", () => {
|
||||
|
||||
### Тестування контрактів реєстрації
|
||||
|
||||
Юніт-тести, які передають вручну написаний mock `api` до `register(api)`, не перевіряють acceptance gate завантажувача OpenClaw. Додайте щонайменше один smoke-тест на основі завантажувача для кожної поверхні реєстрації, від якої залежить ваш Plugin, особливо для hook і ексклюзивних можливостей, таких як memory.
|
||||
Модульні тести, які передають вручну написаний мок `api` у `register(api)`, не перевіряють ворота прийняття завантажувача OpenClaw. Додайте принаймні один smoke-тест на основі завантажувача для кожної поверхні реєстрації, від якої залежить ваш плагін, особливо для хуків і ексклюзивних можливостей, таких як пам’ять.
|
||||
|
||||
Справжній завантажувач відхиляє реєстрацію Plugin, якщо бракує обов’язкових метаданих або якщо Plugin викликає API можливості, якою він не володіє. Наприклад, `api.registerHook(...)` вимагає назву hook, а `api.registerMemoryCapability(...)` вимагає, щоб маніфест Plugin або експортована точка входу оголошували `kind: "memory"`.
|
||||
Справжній завантажувач завершує реєстрацію плагіна помилкою, якщо відсутні обов’язкові метадані або якщо плагін викликає API можливості, якою він не володіє. Наприклад,
|
||||
`api.registerHook(...)` вимагає назву хука, а
|
||||
`api.registerMemoryCapability(...)` вимагає, щоб маніфест плагіна або експортована точка входу оголошували `kind: "memory"`.
|
||||
|
||||
### Тестування доступу до runtime-конфігурації
|
||||
### Тестування доступу до конфігурації часу виконання
|
||||
|
||||
Під час тестування вбудованих Plugin віддавайте перевагу спільному mock runtime Plugin із допоміжних засобів тестування репозиторію. Його застарілі mock `runtime.config.loadConfig()` і `runtime.config.writeConfigFile(...)` за замовчуванням викидають помилку, щоб тести виявляли нове використання API сумісності. Перевизначайте ці mock лише тоді, коли тест явно перевіряє застарілу поведінку сумісності.
|
||||
Під час тестування вбудованих плагінів віддавайте перевагу спільному моку часу виконання плагіна з допоміжних засобів тестування репозиторію. Його моки `runtime.config.loadConfig()` і `runtime.config.writeConfigFile(...)`, які є застарілими, за замовчуванням викидають помилку, щоб тести виявляли нове використання API сумісності. Перевизначайте ці моки лише тоді, коли тест явно покриває застарілу поведінку сумісності.
|
||||
|
||||
### Юніт-тестування Channel Plugin
|
||||
### Модульне тестування плагіна каналу
|
||||
|
||||
```typescript
|
||||
import { describe, it, expect, vi } from "vitest";
|
||||
|
||||
describe("my-channel plugin", () => {
|
||||
describe("плагін my-channel", () => {
|
||||
it("should resolve account from config", () => {
|
||||
const cfg = {
|
||||
channels: {
|
||||
@ -137,18 +146,18 @@ describe("my-channel plugin", () => {
|
||||
const inspection = myPlugin.setup.inspectAccount(cfg, undefined);
|
||||
expect(inspection.configured).toBe(true);
|
||||
expect(inspection.tokenStatus).toBe("available");
|
||||
// No token value exposed
|
||||
// Значення токена не розкривається
|
||||
expect(inspection).not.toHaveProperty("token");
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
### Юніт-тестування Provider Plugin
|
||||
### Модульне тестування плагіна провайдера
|
||||
|
||||
```typescript
|
||||
import { describe, it, expect } from "vitest";
|
||||
|
||||
describe("my-provider plugin", () => {
|
||||
describe("плагін my-provider", () => {
|
||||
it("should resolve dynamic models", () => {
|
||||
const model = myProvider.resolveDynamicModel({
|
||||
modelId: "custom-model-v2",
|
||||
@ -171,9 +180,9 @@ describe("my-provider plugin", () => {
|
||||
});
|
||||
```
|
||||
|
||||
### Мокування runtime Plugin
|
||||
### Мокання часу виконання плагіна
|
||||
|
||||
Для коду, який використовує `createPluginRuntimeStore`, мокайте runtime у тестах:
|
||||
Для коду, який використовує `createPluginRuntimeStore`, мокуйте runtime у тестах:
|
||||
|
||||
```typescript
|
||||
import { createPluginRuntimeStore } from "openclaw/plugin-sdk/runtime-store";
|
||||
@ -204,9 +213,9 @@ store.setRuntime(mockRuntime);
|
||||
store.clearRuntime();
|
||||
```
|
||||
|
||||
### Тестування зі стабами на рівні екземпляра
|
||||
### Тестування з використанням стабів для окремих екземплярів
|
||||
|
||||
Віддавайте перевагу стабам на рівні екземпляра замість мутації прототипу:
|
||||
Віддавайте перевагу стабам для окремих екземплярів, а не зміні prototype:
|
||||
|
||||
```typescript
|
||||
// Preferred: per-instance stub
|
||||
@ -217,9 +226,9 @@ client.sendMessage = vi.fn().mockResolvedValue({ id: "msg-1" });
|
||||
// MyChannelClient.prototype.sendMessage = vi.fn();
|
||||
```
|
||||
|
||||
## Контрактні тести (Plugin у репозиторії)
|
||||
## Контрактні тести (плагіни в репозиторії)
|
||||
|
||||
Вбудовані Plugin мають контрактні тести, які перевіряють володіння реєстрацією:
|
||||
Вбудовані плагіни мають контрактні тести, які перевіряють належність реєстрації:
|
||||
|
||||
```bash
|
||||
pnpm test -- src/plugins/contracts/
|
||||
@ -227,14 +236,14 @@ pnpm test -- src/plugins/contracts/
|
||||
|
||||
Ці тести перевіряють:
|
||||
|
||||
- Які Plugin реєструють які провайдери
|
||||
- Які Plugin реєструють які мовленнєві провайдери
|
||||
- Які плагіни реєструють які провайдери
|
||||
- Які плагіни реєструють які провайдери мовлення
|
||||
- Коректність форми реєстрації
|
||||
- Відповідність runtime-контракту
|
||||
- Відповідність контракту часу виконання
|
||||
|
||||
### Запуск тестів з обмеженою областю
|
||||
|
||||
Для конкретного Plugin:
|
||||
Для конкретного плагіна:
|
||||
|
||||
```bash
|
||||
pnpm test -- <bundled-plugin-root>/my-channel/
|
||||
@ -248,19 +257,19 @@ pnpm test -- src/plugins/contracts/auth.contract.test.ts
|
||||
pnpm test -- src/plugins/contracts/runtime.contract.test.ts
|
||||
```
|
||||
|
||||
## Забезпечення правил lint (Plugin у репозиторії)
|
||||
## Примусове застосування lint (плагіни в репозиторії)
|
||||
|
||||
`pnpm check` застосовує три правила для Plugin у репозиторії:
|
||||
Три правила примусово застосовуються через `pnpm check` для плагінів у репозиторії:
|
||||
|
||||
1. **Без монолітних імпортів із кореня** -- кореневий barrel `openclaw/plugin-sdk` відхиляється
|
||||
2. **Без прямих імпортів `src/`** -- Plugin не можуть напряму імпортувати `../../src/`
|
||||
3. **Без самоімпортів** -- Plugin не можуть імпортувати власний підшлях `plugin-sdk/<name>`
|
||||
1. **Без монолітних імпортів із кореня** -- кореневий barrel `openclaw/plugin-sdk` заборонений
|
||||
2. **Без прямих імпортів `src/`** -- плагіни не можуть напряму імпортувати `../../src/`
|
||||
3. **Без самоімпортів** -- плагіни не можуть імпортувати власний підшлях `plugin-sdk/<name>`
|
||||
|
||||
На зовнішні Plugin ці правила lint не поширюються, але дотримуватися тих самих шаблонів рекомендовано.
|
||||
Зовнішні плагіни не підпадають під ці lint-правила, але рекомендується дотримуватися тих самих шаблонів.
|
||||
|
||||
## Конфігурація тестування
|
||||
## Конфігурація тестів
|
||||
|
||||
OpenClaw використовує Vitest із порогами покриття V8. Для тестів Plugin:
|
||||
OpenClaw використовує Vitest із порогами покриття V8. Для тестів плагінів:
|
||||
|
||||
```bash
|
||||
# Run all tests
|
||||
@ -276,7 +285,7 @@ pnpm test -- <bundled-plugin-root>/my-channel/ -t "resolves account"
|
||||
pnpm test:coverage
|
||||
```
|
||||
|
||||
Якщо локальні запуски створюють тиск на пам’ять:
|
||||
Якщо локальні запуски спричиняють тиск на пам’ять:
|
||||
|
||||
```bash
|
||||
OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test
|
||||
@ -285,6 +294,6 @@ OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test
|
||||
## Пов’язане
|
||||
|
||||
- [Огляд SDK](/uk/plugins/sdk-overview) -- правила імпорту
|
||||
- [SDK Channel Plugins](/uk/plugins/sdk-channel-plugins) -- інтерфейс Channel Plugin
|
||||
- [SDK Provider Plugins](/uk/plugins/sdk-provider-plugins) -- hook Provider Plugin
|
||||
- [Створення Plugin](/uk/plugins/building-plugins) -- посібник для початку роботи
|
||||
- [Плагіни каналів SDK](/uk/plugins/sdk-channel-plugins) -- інтерфейс плагіна каналу
|
||||
- [Плагіни провайдерів SDK](/uk/plugins/sdk-provider-plugins) -- хуки плагінів провайдерів
|
||||
- [Створення плагінів](/uk/plugins/building-plugins) -- посібник із початку роботи
|
||||
|
||||
@ -1,236 +1,233 @@
|
||||
---
|
||||
read_when:
|
||||
- Шукаю визначення публічних каналів релізу
|
||||
- Запуск валідації релізу або приймання пакета
|
||||
- Шукаю іменування версій і каденс
|
||||
summary: Лейни релізу, контрольний список оператора, блоки валідації, іменування версій і каденс
|
||||
title: Політика релізу
|
||||
- Виконання валідації релізу або перевірки прийнятності пакета
|
||||
- Шукаю іменування версій і частоту випусків
|
||||
summary: Релізні напрямки, контрольний список оператора, блоки валідації, іменування версій і частота випусків
|
||||
title: Політика релізів
|
||||
x-i18n:
|
||||
generated_at: "2026-04-27T21:05:08Z"
|
||||
generated_at: "2026-04-27T22:51:29Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: f3ff3c7887c59005a977522e3a0e80ea3458e29d12f6976397b0749d8001d914
|
||||
source_hash: d007af3cf645d1dd84013e686b7a0513fa97f58a5ad1c5758b70a7c93e2458f4
|
||||
source_path: reference/RELEASING.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
OpenClaw має три публічні лейни релізу:
|
||||
OpenClaw має три публічні напрями релізу:
|
||||
|
||||
- stable: теговані релізи, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запитано
|
||||
- beta: теги передрелізів, які публікуються в npm `beta`
|
||||
- dev: рухома голова `main`
|
||||
- stable: релізи з тегами, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запитано
|
||||
- beta: теги попередніх релізів, які публікуються в npm `beta`
|
||||
- dev: рухома вершина `main`
|
||||
|
||||
## Іменування версій
|
||||
|
||||
- Версія stable-релізу: `YYYY.M.D`
|
||||
- Git-тег: `vYYYY.M.D`
|
||||
- Версія коригувального stable-релізу: `YYYY.M.D-N`
|
||||
- Версія stable-коригувального релізу: `YYYY.M.D-N`
|
||||
- Git-тег: `vYYYY.M.D-N`
|
||||
- Версія beta-передрелізу: `YYYY.M.D-beta.N`
|
||||
- Версія beta-попереднього релізу: `YYYY.M.D-beta.N`
|
||||
- Git-тег: `vYYYY.M.D-beta.N`
|
||||
- Не додавайте провідні нулі до місяця або дня
|
||||
- Не додавайте ведучі нулі до місяця або дня
|
||||
- `latest` означає поточний просунутий stable-реліз npm
|
||||
- `beta` означає поточну ціль встановлення beta
|
||||
- Stable-релізи та коригувальні stable-релізи за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно вибрати `latest` або просунути перевірену beta-збірку пізніше
|
||||
- Stable і stable-коригувальні релізи за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно націлити `latest` або пізніше просунути перевірену beta-збірку
|
||||
- Кожен stable-реліз OpenClaw постачається разом із npm-пакетом і застосунком macOS;
|
||||
beta-релізи зазвичай спочатку проходять валідацію та публікацію шляху npm/package, а
|
||||
збірка/підпис/нотаризація застосунку macOS зарезервовані для stable, якщо явно не запитано
|
||||
збірка/підпис/нотаризація застосунку macOS зарезервовані для stable, якщо інше не запитано явно
|
||||
|
||||
## Каденс релізів
|
||||
## Частота випусків релізів
|
||||
|
||||
- Релізи рухаються за схемою beta-first
|
||||
- Stable іде лише після валідації останньої beta
|
||||
- Мейнтейнери зазвичай роблять релізи з гілки `release/YYYY.M.D`, створеної
|
||||
- Релізи спочатку проходять через beta
|
||||
- Stable виходить лише після валідації останньої beta
|
||||
- Мейнтейнери зазвичай створюють релізи з гілки `release/YYYY.M.D`, створеної
|
||||
з поточної `main`, щоб валідація релізу та виправлення не блокували нову
|
||||
розробку в `main`
|
||||
- Якщо beta-тег уже було запушено або опубліковано й він потребує виправлення, мейнтейнери створюють
|
||||
наступний тег `-beta.N` замість видалення або повторного створення старого beta-тегу
|
||||
наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега
|
||||
- Детальна процедура релізу, погодження, облікові дані та примітки щодо відновлення
|
||||
доступні лише мейнтейнерам
|
||||
|
||||
## Контрольний список оператора релізу
|
||||
|
||||
Цей контрольний список — публічний контур процесу релізу. Приватні облікові дані,
|
||||
підписування, нотаризація, відновлення dist-tag і деталі аварійного відкату
|
||||
залишаються в runbook релізу лише для мейнтейнерів.
|
||||
Цей контрольний список описує публічну форму процесу релізу. Приватні облікові дані,
|
||||
підписування, нотаризація, відновлення dist-tag і деталі аварійного відкату залишаються
|
||||
в доступному лише мейнтейнерам runbook релізів.
|
||||
|
||||
1. Почніть з поточної `main`: отримайте останні зміни, підтвердьте, що цільовий коміт запушено,
|
||||
і що поточний CI для `main` достатньо зелений, щоб відгалужуватися від нього.
|
||||
1. Почніть із поточної `main`: підтягніть останні зміни, підтвердьте, що цільовий коміт запушено,
|
||||
і що поточний CI для `main` достатньо зелений, щоб від нього відгалужуватися.
|
||||
2. Перепишіть верхню секцію `CHANGELOG.md` на основі реальної історії комітів за допомогою
|
||||
`/changelog`, залишайте записи орієнтованими на користувача, закомітьте це, запуште і
|
||||
ще раз виконайте rebase/pull перед створенням гілки.
|
||||
`/changelog`, залиште записи орієнтованими на користувача, закомітьте це, запуште й ще раз виконайте rebase/pull перед створенням гілки.
|
||||
3. Перегляньте записи сумісності релізу в
|
||||
`src/plugins/compat/registry.ts` і
|
||||
`src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену
|
||||
`src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте застарілу
|
||||
сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому її
|
||||
навмисно збережено.
|
||||
4. Створіть `release/YYYY.M.D` з поточної `main`; не виконуйте звичайну роботу з релізом
|
||||
4. Створіть `release/YYYY.M.D` із поточної `main`; не виконуйте звичайну роботу над релізом
|
||||
безпосередньо в `main`.
|
||||
5. Оновіть кожне обов’язкове місце з версією для запланованого тегу, а потім виконайте
|
||||
5. Оновіть усі потрібні місця з версіями для запланованого тега, а потім виконайте
|
||||
локальний детермінований preflight:
|
||||
`pnpm check:test-types`, `pnpm check:architecture`,
|
||||
`pnpm build && pnpm ui:build`, і `pnpm release:check`.
|
||||
6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тегу
|
||||
для preflight лише з метою валідації дозволено повний 40-символьний SHA гілки релізу.
|
||||
6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. Поки тег ще не існує,
|
||||
для preflight-лише валідації дозволено використовувати повний 40-символьний SHA гілки релізу.
|
||||
Збережіть успішний `preflight_run_id`.
|
||||
7. Запустіть усі передрелізні тести через `Full Release Validation` для
|
||||
гілки релізу, тегу або повного SHA коміту. Це єдина ручна точка входу
|
||||
гілки релізу, тега або повного SHA коміту. Це єдина ручна точка входу
|
||||
для чотирьох великих блоків тестування релізу: Vitest, Docker, QA Lab і Package.
|
||||
8. Якщо валідація не пройшла, виправте проблему в гілці релізу і повторно запустіть найменший невдалий
|
||||
файл, лейн, завдання workflow, профіль пакета, allowlist провайдера або моделі, який
|
||||
підтверджує виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня
|
||||
робить попередні докази неактуальними.
|
||||
9. Для beta створіть тег `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, а потім запустіть
|
||||
post-publish package acceptance для опублікованого пакета `openclaw@YYYY.M.D-beta.N`
|
||||
8. Якщо валідація не пройшла, виправте проблему в гілці релізу й повторно запустіть найменший збійний
|
||||
файл, напрям, завдання workflow, профіль пакета, allowlist провайдера або моделі, який
|
||||
підтверджує виправлення. Повторно запускайте повну загальну перевірку лише тоді, коли змінена поверхня робить
|
||||
попередні докази застарілими.
|
||||
9. Для beta створіть тег `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, а потім виконайте
|
||||
перевірку прийнятності пакета після публікації для опублікованого пакета `openclaw@YYYY.M.D-beta.N`
|
||||
або `openclaw@beta`. Якщо запушена або опублікована beta потребує виправлення, створіть
|
||||
наступний `-beta.N`; не видаляйте і не переписуйте стару beta.
|
||||
10. Для stable продовжуйте лише після того, як перевірена beta або кандидат на реліз матиме
|
||||
необхідні докази валідації. Stable-публікація в npm повторно використовує успішний
|
||||
артефакт preflight через `preflight_run_id`; готовність stable-релізу для macOS
|
||||
також вимагає упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого
|
||||
наступний `-beta.N`; не видаляйте й не переписуйте стару beta.
|
||||
10. Для stable продовжуйте лише після того, як перевірена beta або кандидат у реліз має
|
||||
потрібні докази валідації. Stable-публікація в npm повторно використовує успішний
|
||||
preflight-артефакт через `preflight_run_id`; готовність stable-релізу для macOS
|
||||
також вимагає наявності запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого
|
||||
`appcast.xml` у `main`.
|
||||
11. Після публікації запустіть верифікатор npm після публікації, необов’язковий окремий
|
||||
Telegram E2E для опублікованого npm, коли потрібен доказ каналу після публікації,
|
||||
просування dist-tag за потреби, примітки GitHub release/prerelease з
|
||||
повної відповідної секції `CHANGELOG.md`, а також кроки
|
||||
оголошення релізу.
|
||||
11. Після публікації запустіть верифікатор npm після публікації, за потреби —
|
||||
необов’язковий окремий Telegram E2E для опублікованого npm, коли потрібне підтвердження каналу після публікації,
|
||||
просування dist-tag за потреби, нотатки GitHub release/prerelease з
|
||||
повної відповідної секції `CHANGELOG.md` і кроки оголошення релізу.
|
||||
|
||||
## Preflight релізу
|
||||
|
||||
- Запускайте `pnpm check:test-types` перед release preflight, щоб TypeScript для тестів
|
||||
залишався покритим поза швидшим локальним gate `pnpm check`
|
||||
- Запускайте `pnpm check:architecture` перед release preflight, щоб ширші перевірки
|
||||
циклів імпорту та меж архітектури були зеленими поза швидшим локальним gate
|
||||
- Запускайте `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
|
||||
артефакти релізу `dist/*` і бандл Control UI існували для кроку
|
||||
- Перед preflight релізу запускайте `pnpm check:test-types`, щоб TypeScript для тестів
|
||||
залишався покритим поза межами швидшого локального етапу `pnpm check`
|
||||
- Перед preflight релізу запускайте `pnpm check:architecture`, щоб ширші перевірки
|
||||
циклів імпорту й архітектурних меж були зеленими поза межами швидшого локального етапу
|
||||
- Перед `pnpm release:check` запускайте `pnpm build && pnpm ui:build`, щоб очікувані
|
||||
артефакти релізу `dist/*` і пакет Control UI існували для кроку
|
||||
валідації pack
|
||||
- Запускайте ручний workflow `Full Release Validation` перед погодженням релізу, щоб
|
||||
запустити всі блоки передрелізного тестування з однієї точки входу. Він приймає гілку,
|
||||
тег або повний SHA коміту, викликає вручну `CI` і викликає
|
||||
`OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker
|
||||
для шляху релізу, live/E2E, OpenWebUI, QA Lab parity, Matrix і лейнів
|
||||
Telegram. Вказуйте `npm_telegram_package_spec` лише після того, як пакет уже
|
||||
опубліковано і також має виконуватися Telegram E2E після публікації. Вказуйте
|
||||
`evidence_package_spec`, коли приватний звіт доказів має підтверджувати, що
|
||||
- Перед затвердженням релізу запускайте вручну workflow `Full Release Validation`,
|
||||
щоб запустити всі передрелізні тестові блоки з однієї точки входу. Він приймає гілку,
|
||||
тег або повний SHA коміту, вручну запускає `CI` і запускає
|
||||
`OpenClaw Release Checks` для install smoke, package acceptance, наборів
|
||||
release-path для Docker, live/E2E, OpenWebUI, паритету QA Lab, напрямів Matrix і Telegram.
|
||||
Указуйте `npm_telegram_package_spec` лише після того, як пакет уже
|
||||
опубліковано й також потрібно запустити Telegram E2E після публікації. Указуйте
|
||||
`evidence_package_spec`, коли приватний звіт про докази має підтвердити, що
|
||||
валідація відповідає опублікованому npm-пакету без примусового запуску Telegram E2E.
|
||||
Приклад:
|
||||
`gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
|
||||
- Запускайте ручний workflow `Package Acceptance`, коли потрібен побічний доказ
|
||||
- Запускайте вручну workflow `Package Acceptance`, коли потрібен побічний доказ
|
||||
для кандидата пакета, поки робота над релізом триває. Використовуйте `source=npm` для
|
||||
`openclaw@beta`, `openclaw@latest` або точної версії релізу; `source=ref`,
|
||||
щоб упакувати довірену гілку/тег/SHA `package_ref` з поточним harness
|
||||
щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним harness
|
||||
`workflow_ref`; `source=url` для HTTPS tarball з обов’язковим
|
||||
SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub
|
||||
SHA-256; або `source=artifact` для tarball, завантаженого з іншого запуску GitHub
|
||||
Actions. Workflow визначає кандидата як
|
||||
`package-under-test`, повторно використовує планувальник Docker E2E шляху релізу для цього
|
||||
tarball і може запускати Telegram QA проти того самого tarball з
|
||||
`package-under-test`, повторно використовує планувальник Docker E2E release для цього
|
||||
tarball і може запускати Telegram QA для того самого tarball з
|
||||
`telegram_mode=mock-openai` або `telegram_mode=live-frontier`.
|
||||
Приклад: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f telegram_mode=mock-openai`
|
||||
Поширені профілі:
|
||||
- `smoke`: лейни install/channel/agent, мережі Gateway і перезавантаження конфігурації
|
||||
- `package`: артефактно-нативні лейни пакета/оновлення/Plugin без OpenWebUI або live ClawHub
|
||||
Типові профілі:
|
||||
- `smoke`: напрями install/channel/agent, мережа gateway і перезавантаження конфігурації
|
||||
- `package`: нативні для артефакта напрями package/update/plugin без OpenWebUI або live ClawHub
|
||||
- `product`: профіль package плюс канали MCP, очищення cron/subagent,
|
||||
вебпошук OpenAI і OpenWebUI
|
||||
- `full`: частини Docker release-path з OpenWebUI
|
||||
- `custom`: точний вибір `docker_lanes` для цільового повторного запуску
|
||||
- Запускайте ручний workflow `CI` безпосередньо, коли потрібне лише повне звичайне покриття
|
||||
CI для кандидата на реліз. Ручний запуск CI оминає changed scoping і примусово запускає
|
||||
Linux Node shards, shards bundled-plugin, контракти каналів, сумісність Node 22, `check`,
|
||||
`check-additional`, build smoke, перевірки документації, Python Skills, Windows, macOS, Android і
|
||||
лейни i18n для Control UI.
|
||||
- Запускайте вручну workflow `CI` безпосередньо, коли потрібне лише повне покриття
|
||||
звичайного CI для кандидата релізу. Ручний запуск CI обходить змінене scope і
|
||||
примусово запускає Linux Node shards, shards bundled-plugin, channel
|
||||
contracts, сумісність з Node 22, напрями `check`, `check-additional`, build smoke,
|
||||
docs checks, Python Skills, Windows, macOS, Android і Control UI i18n.
|
||||
Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D`
|
||||
- Запускайте `pnpm qa:otel:smoke` під час валідації телеметрії релізу. Це проганяє
|
||||
QA-lab через локальний приймач OTLP/HTTP і перевіряє експортовані назви trace span,
|
||||
обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в
|
||||
Opik, Langfuse або іншому зовнішньому collector.
|
||||
- Запускайте `pnpm release:check` перед кожним тегованим релізом
|
||||
- Перевірки релізу тепер виконуються в окремому ручному workflow:
|
||||
- Запускайте `pnpm qa:otel:smoke` під час валідації телеметрії релізу. Це перевіряє
|
||||
QA-lab через локальний приймач OTLP/HTTP і валідує експортовані назви trace span,
|
||||
обмежені атрибути та редагування content/identifier без
|
||||
потреби в Opik, Langfuse чи іншому зовнішньому збирачі.
|
||||
- Перед кожним тегованим релізом запускайте `pnpm release:check`
|
||||
- Тепер перевірки релізу виконуються в окремому ручному workflow:
|
||||
`OpenClaw Release Checks`
|
||||
- `OpenClaw Release Checks` також запускає QA Lab mock parity gate разом із швидким
|
||||
live-профілем Matrix і лейном Telegram QA перед погодженням релізу. Live-лейни використовують
|
||||
середовище `qa-live-shared`; Telegram також використовує оренду облікових даних Convex CI.
|
||||
Запускайте ручний workflow `QA-Lab - All Lanes` з
|
||||
`matrix_profile=all` і `matrix_shards=true`, коли потрібен повний паралельний інвентар
|
||||
транспорту, медіа та E2EE Matrix.
|
||||
- Крос-ОС валідація встановлення та оновлення під час виконання є частиною публічних
|
||||
`OpenClaw Release Checks` і `Full Release Validation`, які викликають
|
||||
- `OpenClaw Release Checks` також запускає QA Lab mock parity gate і швидкий
|
||||
live-профіль Matrix та напрям Telegram QA перед затвердженням релізу. Live-напрями використовують середовище `qa-live-shared`; Telegram також використовує оренду CI-облікових даних Convex. Запускайте вручну workflow `QA-Lab - All Lanes` з
|
||||
`matrix_profile=all` і `matrix_shards=true`, коли потрібен повний паралельний
|
||||
інвентар транспорту, медіа й E2EE для Matrix.
|
||||
- Кросплатформна валідація встановлення й оновлення під час виконання входить до публічних
|
||||
`OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають
|
||||
reusable workflow
|
||||
`.github/workflows/openclaw-cross-os-release-checks-reusable.yml` безпосередньо
|
||||
- Цей поділ навмисний: зберігайте справжній шлях npm-релізу коротким,
|
||||
детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються
|
||||
у власному лейні, щоб не затримувати й не блокувати публікацію
|
||||
`.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
|
||||
- Такий поділ навмисний: зберігайте реальний шлях npm-релізу коротким,
|
||||
детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки лишаються у
|
||||
власному напрямі, щоб не затримувати й не блокувати публікацію
|
||||
- Перевірки релізу, що використовують секрети, слід запускати через `Full Release
|
||||
Validation` або з workflow ref `main`/release, щоб логіка workflow і
|
||||
Validation` або з workflow ref `main`/release, щоб логіка workflow та
|
||||
секрети залишалися контрольованими
|
||||
- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо
|
||||
- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, доки
|
||||
визначений коміт досяжний з гілки OpenClaw або тега релізу
|
||||
- Валідаційний preflight `OpenClaw NPM Release` також приймає поточний
|
||||
повний 40-символьний SHA коміту гілки workflow без вимоги запушеного тегу
|
||||
- Цей шлях із SHA призначений лише для валідації і не може бути підвищений до справжньої публікації
|
||||
- У режимі SHA workflow синтезує `v<package.json version>` лише для
|
||||
перевірки метаданих пакета; справжня публікація все одно вимагає реального тега релізу
|
||||
- Обидва workflows залишають справжній шлях публікації та просування на GitHub-hosted
|
||||
runners, тоді як немутуючий шлях валідації може використовувати більші
|
||||
Blacksmith Linux runners
|
||||
повний 40-символьний SHA коміту гілки workflow без потреби в запушеному тегі
|
||||
- Цей шлях через SHA призначений лише для валідації й не може бути просунутий до реальної публікації
|
||||
- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки
|
||||
метаданих пакета; реальна публікація все одно вимагає реального тега релізу
|
||||
- Обидва workflow зберігають реальний шлях публікації й просування на GitHub-hosted
|
||||
runners, тоді як шлях валідації без змін стану може використовувати більші
|
||||
Linux runners від Blacksmith
|
||||
- Цей workflow запускає
|
||||
`OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
|
||||
з використанням обох workflow secrets: `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
|
||||
- npm release preflight більше не чекає на окремий лейн перевірок релізу
|
||||
- Запускайте `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
|
||||
(або відповідний beta/correction тег) перед погодженням
|
||||
- Preflight npm-релізу більше не очікує завершення окремого напряму release checks
|
||||
- Перед затвердженням запускайте
|
||||
`RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
|
||||
(або відповідний beta/correction тег)
|
||||
- Після публікації в npm запускайте
|
||||
`node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
|
||||
(або відповідну beta/correction версію), щоб перевірити шлях встановлення з
|
||||
опублікованого реєстру в новому тимчасовому префіксі
|
||||
- Після публікації beta запускайте `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`,
|
||||
щоб перевірити onboarding встановленого пакета, налаштування Telegram і справжній Telegram E2E
|
||||
проти опублікованого npm-пакета, використовуючи спільний пул орендованих облікових даних Telegram.
|
||||
Для локальних одноразових перевірок мейнтейнера можна не вказувати змінні Convex і передати
|
||||
безпосередньо три env-облікові дані `OPENCLAW_QA_TELEGRAM_*`.
|
||||
- Мейнтейнери можуть запускати ту саму перевірку після публікації через GitHub Actions за допомогою
|
||||
ручного workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
|
||||
опублікованого реєстру в новому тимчасовому prefix
|
||||
- Після beta-публікації запускайте `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`,
|
||||
щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E
|
||||
для опублікованого npm-пакета з використанням спільного пулу орендованих Telegram-облікових даних.
|
||||
Для одноразових локальних запусків мейнтейнера можна не вказувати змінні Convex і передати напряму три
|
||||
облікові дані середовища `OPENCLAW_QA_TELEGRAM_*`.
|
||||
- Мейнтейнери можуть запускати ту саму перевірку після публікації з GitHub Actions через
|
||||
ручний workflow `NPM Telegram Beta E2E`. Він навмисно доступний лише вручну й
|
||||
не запускається після кожного merge.
|
||||
- Автоматизація релізів мейнтейнера тепер використовує схему preflight-then-promote:
|
||||
- справжня публікація в npm має пройти успішний npm `preflight_run_id`
|
||||
- справжню публікацію в npm слід запускати з тієї самої гілки `main` або
|
||||
- Автоматизація релізів для мейнтейнерів тепер використовує схему preflight-then-promote:
|
||||
- реальна публікація в npm має пройти успішний npm `preflight_run_id`
|
||||
- реальна публікація в npm має бути запущена з тієї самої гілки `main` або
|
||||
`release/YYYY.M.D`, що й успішний запуск preflight
|
||||
- stable npm-релізи за замовчуванням використовують `beta`
|
||||
- stable-публікація в npm може явно націлюватися на `latest` через вхідні дані workflow
|
||||
- мутація npm dist-tag на основі токена тепер знаходиться в
|
||||
- stable-релізи npm за замовчуванням націлені на `beta`
|
||||
- stable-публікація в npm може явно націлювати `latest` через вхідні параметри workflow
|
||||
- зміна npm dist-tag на основі токена тепер розташована в
|
||||
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
|
||||
з міркувань безпеки, оскільки `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як
|
||||
з міркувань безпеки, оскільки `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як
|
||||
публічний репозиторій зберігає публікацію лише через OIDC
|
||||
- публічний `macOS Release` призначений лише для валідації
|
||||
- справжня приватна публікація mac має пройти успішні приватні `preflight_run_id`
|
||||
і `validate_run_id` для mac
|
||||
- справжні шляхи публікації просувають підготовлені артефакти замість їх повторного збирання
|
||||
- Для коригувальних stable-релізів на кшталт `YYYY.M.D-N` верифікатор після публікації
|
||||
також перевіряє той самий шлях оновлення в тимчасовому префіксі з `YYYY.M.D` до `YYYY.M.D-N`,
|
||||
щоб корекції релізу не могли непомітно залишити старі глобальні встановлення на
|
||||
- реальна приватна mac-публікація має пройти успішні приватні mac
|
||||
`preflight_run_id` і `validate_run_id`
|
||||
- реальні шляхи публікації просувають підготовлені артефакти замість їх повторної збірки
|
||||
- Для stable-коригувальних релізів на кшталт `YYYY.M.D-N` верифікатор після публікації
|
||||
також перевіряє той самий шлях оновлення через тимчасовий prefix з `YYYY.M.D` до `YYYY.M.D-N`,
|
||||
щоб коригувальні релізи не могли непомітно залишити старі глобальні встановлення на
|
||||
базовому stable-навантаженні
|
||||
- npm release preflight завершується із закритою помилкою, якщо tarball не містить і `dist/control-ui/index.html`,
|
||||
і непорожнє навантаження `dist/control-ui/assets/`, щоб ми знову не
|
||||
випустили порожню браузерну панель керування
|
||||
- Перевірка після публікації також перевіряє, що встановлення з опублікованого реєстру
|
||||
містить непорожні runtime-залежності bundled Plugin у кореневому
|
||||
макеті `dist/*`. Реліз, який постачається з відсутнім або порожнім навантаженням
|
||||
залежностей bundled Plugin, не проходить верифікатор після публікації і не може бути просунутий
|
||||
- Preflight npm-релізу завершується з відмовою за замовчуванням, якщо tarball не містить і
|
||||
`dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`,
|
||||
щоб ми знову не випустили порожню браузерну панель
|
||||
- Верифікація після публікації також перевіряє, що встановлення з опублікованого реєстру
|
||||
містить непорожні runtime deps bundled plugin у кореневому
|
||||
layout `dist/*`. Реліз, який постачається з відсутніми або порожніми payload
|
||||
залежностей bundled plugin, не проходить postpublish verifier і не може бути просунутий
|
||||
до `latest`.
|
||||
- `pnpm test:install:smoke` також примусово перевіряє бюджет `unpackedSize` для npm pack
|
||||
у tarball кандидата на оновлення, щоб installer e2e виявляв випадкове збільшення
|
||||
пакета до шляху публікації релізу
|
||||
- Якщо робота над релізом торкалася планування CI, маніфестів часу extension або
|
||||
матриць тестів extension, перед погодженням заново згенеруйте й перегляньте
|
||||
матричні виводи `checks-node-extensions`, якими володіє planner, з `.github/workflows/ci.yml`,
|
||||
щоб примітки до релізу не описували застарілу схему CI
|
||||
- `pnpm test:install:smoke` також застосовує бюджет `unpackedSize` npm pack до
|
||||
tarball кандидата оновлення, тож installer e2e виявляє випадкове збільшення pack
|
||||
ще до шляху публікації релізу
|
||||
- Якщо робота над релізом зачіпала планування CI, маніфести часу для extension або
|
||||
матриці тестів extension, перед затвердженням регенеруйте й перегляньте керовані планувальником
|
||||
виходи матриці workflow `checks-node-extensions` з `.github/workflows/ci.yml`,
|
||||
щоб нотатки релізу не описували застарілу структуру CI
|
||||
- Готовність stable-релізу macOS також включає поверхні оновлювача:
|
||||
- GitHub release має зрештою містити упаковані `.zip`, `.dmg` і `.dSYM.zip`
|
||||
- `appcast.xml` у `main` має вказувати на новий stable zip після публікації
|
||||
- упакований застосунок має зберігати non-debug bundle id, непорожню
|
||||
Sparkle feed URL і `CFBundleVersion` на рівні або вище канонічного мінімального build-рівня Sparkle
|
||||
для цієї версії релізу
|
||||
- GitHub release має в підсумку містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
|
||||
- `appcast.xml` у `main` має після публікації вказувати на новий stable zip
|
||||
- запакований застосунок має зберігати non-debug bundle id, непорожній feed
|
||||
URL для Sparkle і `CFBundleVersion` на рівні canonical Sparkle build floor
|
||||
або вище для цієї версії релізу
|
||||
|
||||
## Блоки тестування релізу
|
||||
## Тестові блоки релізу
|
||||
|
||||
`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести
|
||||
з однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте
|
||||
@ -245,38 +242,38 @@ gh workflow run full-release-validation.yml \
|
||||
-f evidence_package_spec=openclaw@YYYY.M.D-beta.N
|
||||
```
|
||||
|
||||
Workflow визначає цільовий ref, викликає вручну `CI` з
|
||||
`target_ref=<release-ref>`, викликає `OpenClaw Release Checks` і
|
||||
за потреби викликає окремий Telegram E2E після публікації, коли
|
||||
Workflow визначає цільовий ref, запускає вручну `CI` з
|
||||
`target_ref=<release-ref>`, запускає `OpenClaw Release Checks` і
|
||||
за потреби запускає окремий Telegram E2E після публікації, коли
|
||||
встановлено `npm_telegram_package_spec`. Далі `OpenClaw Release Checks` розгалужує
|
||||
install smoke, крос-ОС перевірки релізу, live/E2E покриття Docker release-path,
|
||||
Package Acceptance із Telegram package QA, QA Lab parity, live Matrix і
|
||||
live Telegram. Повний запуск є прийнятним лише тоді, коли у підсумку `Full Release Validation`
|
||||
показано `normal_ci` і `release_checks` як успішні, а будь-який необов’язковий дочірній
|
||||
install smoke, кросплатформні перевірки релізу, live/E2E покриття Docker release-path,
|
||||
Package Acceptance з Telegram package QA, паритет QA Lab, live Matrix і
|
||||
live Telegram. Повний запуск прийнятний лише тоді, коли підсумок `Full Release Validation`
|
||||
показує `normal_ci` і `release_checks` як успішні, а будь-який необов’язковий дочірній
|
||||
`npm_telegram` або успішний, або навмисно пропущений.
|
||||
Дочірні workflows викликаються з довіреного ref, що запускає `Full Release
|
||||
Validation`, зазвичай `--ref main`, навіть якщо цільовий `ref` вказує на
|
||||
старішу гілку релізу або тег. Окремого входу workflow-ref для Full Release Validation
|
||||
немає; вибирайте довірений harness, вибираючи ref запуску workflow.
|
||||
Дочірні workflow запускаються з довіреного ref, на якому виконується `Full Release
|
||||
Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` указує на
|
||||
старішу гілку релізу або тег. Окремого параметра workflow-ref для Full Release Validation
|
||||
немає; обирайте довірений harness, обираючи ref запуску workflow.
|
||||
|
||||
Використовуйте ці варіанти залежно від етапу релізу:
|
||||
|
||||
```bash
|
||||
# Валідувати неопубліковану гілку кандидата на реліз.
|
||||
# Валідація неопублікованої гілки кандидата релізу.
|
||||
gh workflow run full-release-validation.yml \
|
||||
--ref main \
|
||||
-f ref=release/YYYY.M.D \
|
||||
-f provider=openai \
|
||||
-f mode=both
|
||||
|
||||
# Валідувати точний запушений коміт.
|
||||
# Валідація точного запушеного коміту.
|
||||
gh workflow run full-release-validation.yml \
|
||||
--ref main \
|
||||
-f ref=<40-char-sha> \
|
||||
-f provider=openai \
|
||||
-f mode=both
|
||||
|
||||
# Після публікації beta додати Telegram E2E для опублікованого пакета.
|
||||
# Після публікації beta додайте Telegram E2E для опублікованого пакета.
|
||||
gh workflow run full-release-validation.yml \
|
||||
--ref main \
|
||||
-f ref=release/YYYY.M.D \
|
||||
@ -287,33 +284,39 @@ gh workflow run full-release-validation.yml \
|
||||
-f npm_telegram_provider_mode=mock-openai
|
||||
```
|
||||
|
||||
Не використовуйте повну парасольку як перший повторний запуск після точкового виправлення. Якщо один блок
|
||||
не пройшов, використовуйте невдалий дочірній workflow, job, Docker lane, профіль пакета, модель
|
||||
провайдера або QA-лейн для наступного підтвердження. Повторно запускайте повну парасольку лише тоді, коли
|
||||
виправлення змінило спільну оркестрацію релізу або зробило попередні докази для всіх блоків
|
||||
неактуальними. Фінальний верифікатор парасольки повторно перевіряє записані run id дочірніх workflow,
|
||||
тож після успішного повторного запуску дочірнього workflow повторно запускайте лише
|
||||
невдалий батьківський job `Verify full validation`.
|
||||
Не використовуйте повну загальну перевірку як перший повторний запуск після цільового виправлення. Якщо один блок
|
||||
не проходить, використовуйте збійний дочірній workflow, job, Docker-напрям, профіль пакета, модельного
|
||||
провайдера або QA-напрям для наступного підтвердження. Повторно запускайте повну загальну перевірку лише тоді, коли
|
||||
виправлення змінило спільну оркестрацію релізу або зробило попередні докази по всіх блоках
|
||||
застарілими. Фінальний верифікатор загальної перевірки повторно перевіряє записані run id дочірніх workflow,
|
||||
тому після успішного повторного запуску дочірнього workflow повторно запускайте лише збійне
|
||||
батьківське job `Verify full validation`.
|
||||
|
||||
Для обмеженого відновлення передайте в загальний workflow `rerun_group`. `all` — це справжній
|
||||
запуск кандидата на реліз, `ci` запускає лише дочірній звичайний CI, `release-checks` запускає
|
||||
кожен блок релізу, а вужчі групи релізу — це `install-smoke`,
|
||||
`cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і
|
||||
`npm-telegram`, коли передано окремий напрям Telegram для пакета.
|
||||
|
||||
### Vitest
|
||||
|
||||
Блок Vitest — це дочірній ручний workflow `CI`. Ручний CI навмисно
|
||||
оминає changed scoping і примусово запускає звичайний тестовий граф для
|
||||
кандидата на реліз: Linux Node shards, bundled-plugin shards, channel contracts, Node 22
|
||||
Блок Vitest — це ручний дочірній workflow `CI`. Ручний CI навмисно
|
||||
обходить scope змін і примусово запускає звичайний граф тестів для кандидата на реліз:
|
||||
Linux Node shards, bundled-plugin shards, channel contracts, Node 22
|
||||
compatibility, `check`, `check-additional`, build smoke, docs checks, Python
|
||||
Skills, Windows, macOS, Android і i18n для Control UI.
|
||||
Skills, Windows, macOS, Android і Control UI i18n.
|
||||
|
||||
Використовуйте цей блок, щоб відповісти на запитання «чи пройшло дерево вихідного коду повний звичайний набір тестів?»
|
||||
Це не те саме, що валідація продукту на шляху релізу. Докази, які слід зберігати:
|
||||
Це не те саме, що валідація продукту за release-path. Докази, які слід зберігати:
|
||||
|
||||
- підсумок `Full Release Validation`, що показує URL запущеного прогону `CI`
|
||||
- зелений прогін `CI` на точному цільовому SHA
|
||||
- назви shard-ів, що впали або працювали повільно, із job-ів CI під час дослідження регресій
|
||||
- підсумок `Full Release Validation`, що показує URL запущеного `CI`
|
||||
- зелений запуск `CI` на точному цільовому SHA
|
||||
- назви shard із помилками або повільних shard із job CI під час дослідження регресій
|
||||
- артефакти часу Vitest, такі як `.artifacts/vitest-shard-timings.json`, коли
|
||||
запуск потребує аналізу продуктивності
|
||||
|
||||
Запускайте ручний CI безпосередньо лише тоді, коли релізу потрібен детермінований звичайний CI, але
|
||||
не потрібні блоки Docker, QA Lab, live, cross-OS або Package:
|
||||
Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований звичайний CI, але
|
||||
не потрібні блоки Docker, QA Lab, live, cross-OS або package:
|
||||
|
||||
```bash
|
||||
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
|
||||
@ -321,91 +324,91 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
|
||||
|
||||
### Docker
|
||||
|
||||
Блок Docker знаходиться в `OpenClaw Release Checks` через
|
||||
`openclaw-live-and-e2e-checks-reusable.yml`, а також через workflow
|
||||
`install-smoke` у режимі релізу. Він валідовує кандидата на реліз через упаковані
|
||||
середовища Docker, а не лише через тести на рівні вихідного коду.
|
||||
Блок Docker розташований у `OpenClaw Release Checks` через
|
||||
`openclaw-live-and-e2e-checks-reusable.yml`, а також у workflow
|
||||
`install-smoke` у режимі релізу. Він валідовує кандидата на реліз через запаковані
|
||||
середовища Docker, а не лише тести на рівні вихідного коду.
|
||||
|
||||
Покриття Docker для релізу включає:
|
||||
|
||||
- повний install smoke з увімкненим повільним smoke глобального встановлення Bun
|
||||
- лейни E2E для репозиторію
|
||||
- частини Docker для шляху релізу: `core`, `package-update-openai`,
|
||||
- повний install smoke з увімкненим повільним Bun global install smoke
|
||||
- напрями E2E для репозиторію
|
||||
- частини Docker release-path: `core`, `package-update-openai`,
|
||||
`package-update-anthropic`, `package-update-core`, `plugins-runtime-core`,
|
||||
`plugins-runtime-install-a`, `plugins-runtime-install-b` і
|
||||
`bundled-channels`
|
||||
`plugins-runtime-install-a`, `plugins-runtime-install-b`,
|
||||
`bundled-channels-core`, `bundled-channels-update-a`,
|
||||
`bundled-channels-update-b` і `bundled-channels-contracts`
|
||||
- покриття OpenWebUI всередині частини `plugins-runtime-core`, коли це запитано
|
||||
- розділені лейни залежностей bundled-channel у власній частині `bundled-channels`
|
||||
замість послідовного all-in-one лейна bundled-channel
|
||||
- розділені лейни встановлення/видалення bundled Plugin
|
||||
- розділені напрями залежностей bundled-channel між частинами channel-smoke, update-target
|
||||
і setup/runtime contract замість одного великого job bundled-channel
|
||||
- розділені напрями встановлення/видалення bundled plugin
|
||||
`bundled-plugin-install-uninstall-0` до
|
||||
`bundled-plugin-install-uninstall-7`
|
||||
- live/E2E набори провайдерів і покриття live-моделей Docker, коли перевірки релізу
|
||||
- набори live/E2E для провайдерів і покриття live-моделей Docker, коли перевірки релізу
|
||||
включають live-набори
|
||||
|
||||
Використовуйте артефакти Docker перед повторним запуском. Планувальник шляху релізу
|
||||
вивантажує `.artifacts/docker-tests/` з логами лейнів, `summary.json`, `failures.json`,
|
||||
часом фаз, JSON плану планувальника та командами повторного запуску. Для точкового відновлення
|
||||
Використовуйте артефакти Docker перед повторним запуском. Планувальник release-path вивантажує
|
||||
`.artifacts/docker-tests/` з логами напрямів, `summary.json`, `failures.json`,
|
||||
часом фаз, JSON плану планувальника та командами повторного запуску. Для цільового відновлення
|
||||
використовуйте `docker_lanes=<lane[,lane]>` у reusable workflow live/E2E замість
|
||||
повторного запуску всіх частин релізу. Згенеровані команди повторного запуску включають попередній
|
||||
`package_artifact_run_id` і підготовлені вхідні дані образів Docker, коли вони доступні, щоб
|
||||
лейн, що впав, міг повторно використати той самий tarball і образи GHCR.
|
||||
повторного запуску всіх частин релізу. Згенеровані команди повторного запуску включають попередні
|
||||
`package_artifact_run_id` і підготовлені вхідні параметри образів Docker, коли вони доступні, тож
|
||||
напрям із помилкою може повторно використати той самий tarball і образи GHCR.
|
||||
|
||||
### QA Lab
|
||||
|
||||
Блок QA Lab також є частиною `OpenClaw Release Checks`. Це gate
|
||||
агентної поведінки та поведінки на рівні каналів для релізу, окремий від механіки пакетів Vitest і Docker.
|
||||
Блок QA Lab також є частиною `OpenClaw Release Checks`. Це релізний gate для
|
||||
агентної поведінки та поведінки на рівні каналів, окремий від механіки пакетів Vitest і Docker.
|
||||
|
||||
Покриття QA Lab для релізу включає:
|
||||
|
||||
- mock parity gate, що порівнює кандидатний лейн OpenAI з базовим рівнем Opus 4.6
|
||||
за допомогою пакета agentic parity
|
||||
- швидкий live-профіль Matrix QA з використанням середовища `qa-live-shared`
|
||||
- live-лейн Telegram QA з орендою облікових даних Convex CI
|
||||
- mock parity gate, який порівнює напрям кандидата OpenAI з базовою лінією Opus 4.6
|
||||
за допомогою agentic parity pack
|
||||
- швидкий live-профіль QA для Matrix з середовищем `qa-live-shared`
|
||||
- live-напрям QA для Telegram з орендою облікових даних CI у Convex
|
||||
- `pnpm qa:otel:smoke`, коли телеметрія релізу потребує явного локального підтвердження
|
||||
|
||||
Використовуйте цей блок, щоб відповісти на запитання «чи правильно поводиться реліз у QA-сценаріях і
|
||||
live-потоках каналів?» Під час погодження релізу зберігайте URL артефактів для лейнів parity, Matrix і Telegram.
|
||||
Повне покриття Matrix залишається доступним як ручний шардований запуск QA-Lab, а не
|
||||
як типовий критичний для релізу лейн.
|
||||
Використовуйте цей блок, щоб відповісти на запитання «чи реліз поводиться правильно в QA-сценаріях і
|
||||
live-потоках каналів?» Під час затвердження релізу зберігайте URL артефактів для
|
||||
напрямів parity, Matrix і Telegram. Повне покриття Matrix лишається доступним як
|
||||
ручний шардований запуск QA-Lab, а не як напрям за замовчуванням, критичний для релізу.
|
||||
|
||||
### Package
|
||||
|
||||
Блок Package — це gate для встановлюваного продукту. Його підтримують
|
||||
Блок Package — це gate для встановлюваного продукту. Він базується на
|
||||
`Package Acceptance` і resolver
|
||||
`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує
|
||||
кандидата в tarball `package-under-test`, який споживає Docker E2E, валідовує
|
||||
інвентар пакета, записує версію пакета і SHA-256 та зберігає
|
||||
ref harness workflow окремо від ref джерела пакета.
|
||||
інвентар пакета, записує версію пакета й SHA-256 та зберігає ref harness workflow
|
||||
окремо від ref джерела пакета.
|
||||
|
||||
Підтримувані джерела кандидата:
|
||||
Підтримувані джерела кандидатів:
|
||||
|
||||
- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна версія релізу OpenClaw
|
||||
- `source=ref`: упакувати довірену гілку, тег або повний SHA коміту `package_ref`
|
||||
з вибраним harness `workflow_ref`
|
||||
- `source=ref`: запакувати довірену гілку, тег або повний SHA коміту `package_ref`
|
||||
із вибраним harness `workflow_ref`
|
||||
- `source=url`: завантажити HTTPS `.tgz` з обов’язковим `package_sha256`
|
||||
- `source=artifact`: повторно використати `.tgz`, вивантажений іншим запуском GitHub Actions
|
||||
|
||||
`OpenClaw Release Checks` запускає Package Acceptance з `source=ref`,
|
||||
`package_ref=<release-ref>`, `suite_profile=custom`,
|
||||
`docker_lanes=bundled-channel-deps-compat plugins-offline` і
|
||||
`telegram_mode=mock-openai`. Частини Docker для шляху релізу покривають
|
||||
лейни встановлення, оновлення та оновлення Plugin, що перетинаються; Package Acceptance
|
||||
зберігає артефактно-нативну сумісність bundled-channel, офлайн-фікстури Plugin і Telegram
|
||||
package QA проти того самого визначеного tarball. Це GitHub-native
|
||||
заміна для більшості покриття package/update, яке раніше вимагало
|
||||
Parallels. Cross-OS перевірки релізу все ще важливі для специфічної для ОС поведінки onboarding,
|
||||
інсталятора та платформи, але валідація продукту package/update має
|
||||
`telegram_mode=mock-openai`. Частини Docker release-path покривають
|
||||
перетинні напрями install, update і plugin-update; Package Acceptance зберігає
|
||||
нативну для артефакта сумісність bundled-channel, офлайн-фікстури плагінів і Telegram package QA для того самого визначеного tarball. Це нативна для GitHub
|
||||
заміна більшості покриття package/update, яке раніше вимагало
|
||||
Parallels. Кросплатформні перевірки релізу все ще важливі для специфічної для ОС
|
||||
поведінки onboarding, installer і платформи, але валідація продукту package/update повинна
|
||||
віддавати перевагу Package Acceptance.
|
||||
|
||||
Історична поблажливість package-acceptance навмисно обмежена в часі. Пакети до
|
||||
`2026.4.25` можуть використовувати шлях сумісності для прогалин у метаданих, уже опублікованих
|
||||
у npm: приватні записи інвентарю QA, відсутні в tarball; відсутній
|
||||
`gateway install --wrapper`; відсутні patch-файли у git-фікстурі, похідній від tarball;
|
||||
відсутній збережений `update.channel`; історичні розташування install-record для Plugin;
|
||||
відсутнє збереження install-record marketplace; і міграція метаданих конфігурації під час `plugins update`.
|
||||
Пакети після `2026.4.25` мають відповідати сучасним контрактам пакета;
|
||||
ті самі прогалини призводять до провалу валідації релізу.
|
||||
`2026.4.25` можуть використовувати шлях сумісності для прогалин у метаданих, уже
|
||||
опублікованих у npm: приватні записи QA inventory, відсутні в tarball,
|
||||
відсутній `gateway install --wrapper`, відсутні patch-файли у git-фікстурі, похідній від tarball,
|
||||
відсутній збережений `update.channel`, історичні розташування install-record
|
||||
для плагінів, відсутність збереження marketplace install-record і
|
||||
міграція метаданих конфігурації під час `plugins update`. Пакети після `2026.4.25` повинні відповідати
|
||||
сучасним контрактам пакета; ті самі прогалини призведуть до помилки валідації релізу.
|
||||
|
||||
Використовуйте ширші профілі Package Acceptance, коли питання релізу стосується
|
||||
реального встановлюваного пакета:
|
||||
@ -421,84 +424,84 @@ gh workflow run package-acceptance.yml \
|
||||
|
||||
Поширені профілі пакета:
|
||||
|
||||
- `smoke`: швидкі лейни package install/channel/agent, мережі Gateway і
|
||||
- `smoke`: швидкі напрями встановлення package/channel/agent, мережі gateway і
|
||||
перезавантаження конфігурації
|
||||
- `package`: контракти package install/update/plugin без live ClawHub; це типовий варіант release-check
|
||||
- `product`: `package` плюс канали MCP, очищення cron/subagent, вебпошук OpenAI
|
||||
і OpenWebUI
|
||||
- `full`: частини Docker шляху релізу з OpenWebUI
|
||||
- `custom`: точний список `docker_lanes` для точкових повторних запусків
|
||||
- `product`: `package` плюс канали MCP, очищення cron/subagent, OpenAI web
|
||||
search і OpenWebUI
|
||||
- `full`: частини Docker release-path з OpenWebUI
|
||||
- `custom`: точний список `docker_lanes` для цільових повторних запусків
|
||||
|
||||
Для доказу Telegram для кандидата пакета вмикайте `telegram_mode=mock-openai` або
|
||||
`telegram_mode=live-frontier` у Package Acceptance. Workflow передає
|
||||
визначений tarball `package-under-test` у лейн Telegram; окремий
|
||||
workflow Telegram як і раніше приймає специфікацію опублікованого npm для перевірок після публікації.
|
||||
Для підтвердження Telegram для кандидата пакета увімкніть `telegram_mode=mock-openai` або
|
||||
`telegram_mode=live-frontier` у Package Acceptance. Workflow передає tarball
|
||||
визначеного `package-under-test` у напрям Telegram; окремий workflow
|
||||
Telegram усе ще приймає специфікацію опублікованого npm для перевірок після публікації.
|
||||
|
||||
## Вхідні параметри workflow npm
|
||||
|
||||
`OpenClaw NPM Release` приймає такі вхідні параметри, контрольовані оператором:
|
||||
`OpenClaw NPM Release` приймає такі керовані оператором вхідні параметри:
|
||||
|
||||
- `tag`: обов’язковий тег релізу, наприклад `v2026.4.2`, `v2026.4.2-1` або
|
||||
`v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
|
||||
повний 40-символьний SHA коміту гілки workflow для preflight лише з метою валідації
|
||||
- `preflight_only`: `true` лише для валідації/збирання/пакета, `false` для
|
||||
повний 40-символьний SHA коміту гілки workflow для preflight, призначеного лише для валідації
|
||||
- `preflight_only`: `true` для лише валідації/збірки/пакета, `false` для
|
||||
реального шляху публікації
|
||||
- `preflight_run_id`: обов’язковий у реальному шляху публікації, щоб workflow повторно використав
|
||||
- `preflight_run_id`: обов’язковий для реального шляху публікації, щоб workflow повторно використав
|
||||
підготовлений tarball з успішного запуску preflight
|
||||
- `npm_dist_tag`: цільовий npm-тег для шляху публікації; за замовчуванням `beta`
|
||||
- `npm_dist_tag`: цільовий тег npm для шляху публікації; за замовчуванням `beta`
|
||||
|
||||
`OpenClaw Release Checks` приймає такі вхідні параметри, контрольовані оператором:
|
||||
`OpenClaw Release Checks` приймає такі керовані оператором вхідні параметри:
|
||||
|
||||
- `ref`: гілка, тег або повний SHA коміту для валідації. Перевірки, що використовують секрети,
|
||||
вимагають, щоб визначений коміт був досяжний з гілки OpenClaw або
|
||||
вимагають, щоб визначений коміт був досяжний із гілки OpenClaw або
|
||||
тега релізу.
|
||||
|
||||
Правила:
|
||||
|
||||
- Stable- і correction-теги можуть публікуватися або в `beta`, або в `latest`
|
||||
- Beta prerelease-теги можуть публікуватися лише в `beta`
|
||||
- Для `OpenClaw NPM Release` вхідний повний SHA коміту дозволено лише коли
|
||||
- Теги stable і correction можуть публікуватися як у `beta`, так і в `latest`
|
||||
- Теги beta prerelease можуть публікуватися лише в `beta`
|
||||
- Для `OpenClaw NPM Release` повний SHA коміту дозволений лише коли
|
||||
`preflight_only=true`
|
||||
- `OpenClaw Release Checks` і `Full Release Validation` завжди
|
||||
призначені лише для валідації
|
||||
- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час preflight;
|
||||
workflow перевіряє ці метадані, перш ніж публікація продовжиться
|
||||
- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
|
||||
workflow перевіряє ці метадані, перш ніж продовжити публікацію
|
||||
|
||||
## Послідовність stable npm-релізу
|
||||
|
||||
Під час випуску stable npm-релізу:
|
||||
|
||||
1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
|
||||
- До появи тегу можна використовувати поточний повний SHA коміту гілки workflow
|
||||
для dry run workflow preflight лише з метою валідації
|
||||
2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише
|
||||
коли ви навмисно хочете пряму stable-публікацію
|
||||
- Поки тег ще не існує, ви можете використовувати поточний повний SHA коміту
|
||||
гілки workflow для dry-run валідації preflight workflow
|
||||
2. Оберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише
|
||||
тоді, коли ви навмисно хочете напряму опублікувати stable
|
||||
3. Запустіть `Full Release Validation` для гілки релізу, тега релізу або повного
|
||||
SHA коміту, коли потрібні звичайний CI плюс покриття live prompt cache, Docker, QA Lab,
|
||||
Matrix і Telegram з одного ручного workflow
|
||||
4. Якщо навмисно потрібен лише детермінований звичайний тестовий граф, замість цього запустіть
|
||||
SHA коміту, коли вам потрібні звичайний CI, live prompt cache, Docker, QA Lab,
|
||||
Matrix і Telegram coverage з одного ручного workflow
|
||||
4. Якщо вам навмисно потрібен лише детермінований звичайний граф тестів, натомість запустіть
|
||||
ручний workflow `CI` для ref релізу
|
||||
5. Збережіть успішний `preflight_run_id`
|
||||
6. Знову запустіть `OpenClaw NPM Release` з `preflight_only=false`, тим самим
|
||||
`tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id`
|
||||
7. Якщо реліз потрапив у `beta`, використайте приватний
|
||||
workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
|
||||
7. Якщо реліз потрапив у `beta`, використайте приватний workflow
|
||||
`openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
|
||||
щоб просунути цю stable-версію з `beta` до `latest`
|
||||
8. Якщо реліз навмисно був опублікований безпосередньо в `latest`, а `beta`
|
||||
має одразу слідувати за тією ж stable-збіркою, використайте той самий приватний
|
||||
workflow, щоб спрямувати обидва dist-tag на stable-версію, або дозвольте його запланованій
|
||||
self-healing синхронізації перемістити `beta` пізніше
|
||||
8. Якщо реліз навмисно було одразу опубліковано в `latest`, а `beta`
|
||||
має одразу вказувати на ту саму stable-збірку, використайте той самий приватний
|
||||
workflow, щоб спрямувати обидва dist-tag на stable-версію, або дозвольте його
|
||||
запланованій self-healing синхронізації перемістити `beta` пізніше
|
||||
|
||||
Мутація dist-tag живе в приватному репозиторії з міркувань безпеки, оскільки вона все ще
|
||||
Зміна dist-tag розташована в приватному репозиторії з міркувань безпеки, оскільки вона все ще
|
||||
потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
|
||||
|
||||
Це зберігає і шлях прямої публікації, і шлях просування beta-first
|
||||
задокументованими та видимими для оператора.
|
||||
Це зберігає як шлях прямої публікації, так і шлях просування beta-first
|
||||
задокументованими й видимими для оператора.
|
||||
|
||||
Якщо мейнтейнеру доводиться повертатися до локальної npm-автентифікації, виконуйте будь-які команди
|
||||
1Password CLI (`op`) лише в окремій сесії tmux. Не викликайте `op`
|
||||
безпосередньо з основної оболонки агента; запуск усередині tmux робить prompts,
|
||||
alerts і обробку OTP спостережуваними та запобігає повторним сповіщенням на хості.
|
||||
Якщо мейнтейнеру доведеться повернутися до локальної автентифікації npm, запускайте будь-які команди
|
||||
1Password CLI (`op`) лише всередині окремої tmux-сесії. Не викликайте `op`
|
||||
напряму з основної оболонки агента; запуск усередині tmux робить запити,
|
||||
сповіщення та обробку OTP видимими й запобігає повторним сповіщенням хоста.
|
||||
|
||||
## Публічні посилання
|
||||
|
||||
@ -512,10 +515,10 @@ alerts і обробку OTP спостережуваними та запобі
|
||||
- [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
|
||||
- [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)
|
||||
|
||||
Мейнтейнери використовують приватну документацію релізу в
|
||||
Мейнтейнери використовують приватну документацію релізів у
|
||||
[`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
|
||||
як фактичний runbook.
|
||||
|
||||
## Пов’язане
|
||||
|
||||
- [Канали релізу](/uk/install/development-channels)
|
||||
- [Канали релізів](/uk/install/development-channels)
|
||||
|
||||
@ -2,125 +2,125 @@
|
||||
read_when:
|
||||
- Ви хочете зрозуміти, які інструменти надає OpenClaw
|
||||
- Вам потрібно налаштувати, дозволити або заборонити інструменти
|
||||
- 'Ви вирішуєте, що обрати: вбудовані інструменти, Skills чи Plugin'
|
||||
summary: 'Огляд інструментів і Plugin в OpenClaw: що агент може робити та як його розширити'
|
||||
title: Інструменти та Plugin
|
||||
- Ви обираєте між вбудованими інструментами, Skills і плагінами
|
||||
summary: 'Огляд інструментів і плагінів OpenClaw: що може робити агент і як його розширити'
|
||||
title: Інструменти та плагіни
|
||||
x-i18n:
|
||||
generated_at: "2026-04-26T04:25:31Z"
|
||||
generated_at: "2026-04-27T22:51:31Z"
|
||||
model: gpt-5.4
|
||||
provider: openai
|
||||
source_hash: 47cc0e2de5688328f7c11fcf86c0a2262b488c277f48416f584f5c7913f750c4
|
||||
source_hash: 62cde740188c224af03b4425c7f6dfca9a12f95603066db5925724fc6a07dcf0
|
||||
source_path: tools/index.md
|
||||
workflow: 15
|
||||
---
|
||||
|
||||
Усе, що агент робить понад генерування тексту, відбувається через **інструменти**.
|
||||
Інструменти — це спосіб, яким агент читає файли, запускає команди, переглядає веб, надсилає
|
||||
Інструменти — це спосіб, у який агент читає файли, запускає команди, переглядає веб, надсилає
|
||||
повідомлення та взаємодіє з пристроями.
|
||||
|
||||
## Інструменти, Skills і Plugin
|
||||
## Інструменти, Skills і плагіни
|
||||
|
||||
OpenClaw має три рівні, які працюють разом:
|
||||
OpenClaw має три шари, які працюють разом:
|
||||
|
||||
<Steps>
|
||||
<Step title="Інструменти — це те, що викликає агент">
|
||||
Інструмент — це типізована функція, яку агент може викликати (наприклад, `exec`, `browser`,
|
||||
`web_search`, `message`). OpenClaw постачається з набором **вбудованих інструментів**, а
|
||||
plugins можуть реєструвати додаткові.
|
||||
плагіни можуть реєструвати додаткові.
|
||||
|
||||
Агент бачить інструменти як структуровані визначення функцій, надіслані до API моделі.
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Skills навчають агента коли і як">
|
||||
Skill — це markdown-файл (`SKILL.md`), який додається до системного prompt-а.
|
||||
Skill — це markdown-файл (`SKILL.md`), який додається до системного запиту.
|
||||
Skills надають агенту контекст, обмеження та покрокові вказівки для
|
||||
ефективного використання інструментів. Skills можуть бути у вашому робочому просторі, у спільних теках
|
||||
або постачатися всередині plugins.
|
||||
ефективного використання інструментів. Skills розміщуються у вашому робочому просторі, у спільних папках
|
||||
або постачаються всередині плагінів.
|
||||
|
||||
[Довідник Skills](/uk/tools/skills) | [Створення Skills](/uk/tools/creating-skills)
|
||||
|
||||
</Step>
|
||||
|
||||
<Step title="Plugins пакують усе разом">
|
||||
Plugin — це пакет, який може реєструвати будь-яку комбінацію можливостей:
|
||||
<Step title="Плагіни пакують усе разом">
|
||||
Плагін — це пакет, який може реєструвати будь-яку комбінацію можливостей:
|
||||
канали, провайдерів моделей, інструменти, Skills, мовлення, транскрипцію в реальному часі,
|
||||
голос у реальному часі, розуміння медіа, генерацію зображень, генерацію відео,
|
||||
web fetch, web search тощо. Деякі plugins є **core** (постачаються з
|
||||
OpenClaw), інші — **external** (опубліковані в npm спільнотою).
|
||||
отримання даних із вебу, пошук у вебі тощо. Деякі плагіни є **core** (постачаються з
|
||||
OpenClaw), інші — **external** (опубліковані спільнотою в npm).
|
||||
|
||||
[Установлення та налаштування plugins](/uk/tools/plugin) | [Створіть власний](/uk/plugins/building-plugins)
|
||||
[Установлення та налаштування плагінів](/uk/tools/plugin) | [Створіть власний](/uk/plugins/building-plugins)
|
||||
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
## Вбудовані інструменти
|
||||
|
||||
Ці інструменти постачаються з OpenClaw і доступні без установлення будь-яких plugins:
|
||||
Ці інструменти постачаються з OpenClaw і доступні без установлення будь-яких плагінів:
|
||||
|
||||
| Інструмент | Що він робить | Сторінка |
|
||||
| ----------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------ |
|
||||
| `exec` / `process` | Запускає shell-команди, керує фоновими процесами | [Exec](/uk/tools/exec), [Підтвердження Exec](/uk/tools/exec-approvals) |
|
||||
| `code_execution` | Запускає ізольований віддалений аналіз Python | [Code Execution](/uk/tools/code-execution) |
|
||||
| `browser` | Керує браузером Chromium (перехід, клік, знімок екрана) | [Browser](/uk/tools/browser) |
|
||||
| `web_search` / `x_search` / `web_fetch` | Шукає у вебі, шукає дописи X, отримує вміст сторінок | [Веб](/uk/tools/web), [Web Fetch](/uk/tools/web-fetch) |
|
||||
| `read` / `write` / `edit` | Операції введення/виведення файлів у робочому просторі | |
|
||||
| `apply_patch` | Багатофрагментні патчі файлів | [Apply Patch](/uk/tools/apply-patch) |
|
||||
| `message` | Надсилає повідомлення в усіх каналах | [Надсилання агентом](/uk/tools/agent-send) |
|
||||
| `canvas` | Керує node Canvas (present, eval, snapshot) | |
|
||||
| `nodes` | Виявляє та націлює спарені пристрої | |
|
||||
| `cron` / `gateway` | Керує запланованими завданнями; перевіряє, патчить, перезапускає або оновлює Gateway | |
|
||||
| `image` / `image_generate` | Аналізує або генерує зображення | [Генерація зображень](/uk/tools/image-generation) |
|
||||
| `music_generate` | Генерує музичні треки | [Генерація музики](/uk/tools/music-generation) |
|
||||
| `video_generate` | Генерує відео | [Генерація відео](/uk/tools/video-generation) |
|
||||
| `tts` | Одноразове перетворення тексту в мовлення | [TTS](/uk/tools/tts) |
|
||||
| `sessions_*` / `subagents` / `agents_list`| Керування сесіями, станом і оркестрацією субагентів | [Субагенти](/uk/tools/subagents) |
|
||||
| `session_status` | Полегшене зчитування в стилі `/status` і перевизначення моделі для сесії | [Інструменти сесій](/uk/concepts/session-tool) |
|
||||
| Інструмент | Що він робить | Сторінка |
|
||||
| ------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------ |
|
||||
| `exec` / `process` | Запускає shell-команди, керує фоновими процесами | [Exec](/uk/tools/exec), [Погодження Exec](/uk/tools/exec-approvals) |
|
||||
| `code_execution` | Запускає ізольований віддалений аналіз Python | [Code Execution](/uk/tools/code-execution) |
|
||||
| `browser` | Керує браузером Chromium (перехід, натискання, знімок екрана) | [Browser](/uk/tools/browser) |
|
||||
| `web_search` / `x_search` / `web_fetch` | Шукає у вебі, шукає дописи в X, отримує вміст сторінок | [Веб](/uk/tools/web), [Web Fetch](/uk/tools/web-fetch) |
|
||||
| `read` / `write` / `edit` | Введення/виведення файлів у робочому просторі | |
|
||||
| `apply_patch` | Багатоблокові патчі файлів | [Apply Patch](/uk/tools/apply-patch) |
|
||||
| `message` | Надсилає повідомлення через усі канали | [Надсилання агентом](/uk/tools/agent-send) |
|
||||
| `canvas` | Керує вузловим Canvas (present, eval, snapshot) | |
|
||||
| `nodes` | Виявляє та націлюється на спарені пристрої | |
|
||||
| `cron` / `gateway` | Керує запланованими завданнями; перевіряє, патчить, перезапускає або оновлює Gateway | |
|
||||
| `image` / `image_generate` | Аналізує або генерує зображення | [Генерація зображень](/uk/tools/image-generation) |
|
||||
| `music_generate` | Генерує музичні треки | [Генерація музики](/uk/tools/music-generation) |
|
||||
| `video_generate` | Генерує відео | [Генерація відео](/uk/tools/video-generation) |
|
||||
| `tts` | Одноразове перетворення тексту на мовлення | [TTS](/uk/tools/tts) |
|
||||
| `sessions_*` / `subagents` / `agents_list` | Керування сесіями, статус і оркестрація субагентів | [Субагенти](/uk/tools/subagents) |
|
||||
| `session_status` | Полегшене зчитування у стилі `/status` і перевизначення моделі для сесії | [Інструменти сесії](/uk/concepts/session-tool) |
|
||||
|
||||
Для роботи із зображеннями використовуйте `image` для аналізу та `image_generate` для генерації або редагування. Якщо ви націлюєтеся на `openai/*`, `google/*`, `fal/*` або іншого неосновного провайдера зображень, спочатку налаштуйте автентифікацію/API-ключ цього провайдера.
|
||||
Для роботи із зображеннями використовуйте `image` для аналізу, а `image_generate` — для генерації або редагування. Якщо ви націлюєтесь на `openai/*`, `google/*`, `fal/*` або іншого не стандартного провайдера зображень, спочатку налаштуйте автентифікацію/API-ключ цього провайдера.
|
||||
|
||||
Для роботи з музикою використовуйте `music_generate`. Якщо ви націлюєтеся на `google/*`, `minimax/*` або іншого неосновного провайдера музики, спочатку налаштуйте автентифікацію/API-ключ цього провайдера.
|
||||
Для роботи з музикою використовуйте `music_generate`. Якщо ви націлюєтесь на `google/*`, `minimax/*` або іншого не стандартного музичного провайдера, спочатку налаштуйте автентифікацію/API-ключ цього провайдера.
|
||||
|
||||
Для роботи з відео використовуйте `video_generate`. Якщо ви націлюєтеся на `qwen/*` або іншого неосновного провайдера відео, спочатку налаштуйте автентифікацію/API-ключ цього провайдера.
|
||||
Для роботи з відео використовуйте `video_generate`. Якщо ви націлюєтесь на `qwen/*` або іншого не стандартного відеопровайдера, спочатку налаштуйте автентифікацію/API-ключ цього провайдера.
|
||||
|
||||
Для генерації аудіо, керованої workflow, використовуйте `music_generate`, коли plugin на кшталт
|
||||
ComfyUI реєструє його. Це окремо від `tts`, який є перетворенням тексту в мовлення.
|
||||
Для генерації аудіо на основі workflow використовуйте `music_generate`, коли плагін, наприклад
|
||||
ComfyUI, реєструє його. Це окремо від `tts`, яке є перетворенням тексту на мовлення.
|
||||
|
||||
`session_status` — це полегшений інструмент стану/зчитування в групі інструментів сесій.
|
||||
Він відповідає на запитання в стилі `/status` про поточну сесію та може
|
||||
за бажанням задавати перевизначення моделі для конкретної сесії; `model=default` очищує
|
||||
це перевизначення. Як і `/status`, він може заповнювати відсутні лічильники токенів/кешу та
|
||||
мітку активної моделі середовища виконання з останнього запису використання в транскрипті.
|
||||
`session_status` — це полегшений інструмент статусу/зчитування в групі сесій.
|
||||
Він відповідає на запитання у стилі `/status` про поточну сесію та може
|
||||
за бажанням встановлювати перевизначення моделі для окремої сесії; `model=default` скидає це
|
||||
перевизначення. Як і `/status`, він може дозаповнювати розріджені лічильники токенів/кешу та
|
||||
мітку активної моделі середовища виконання з останнього запису про використання в транскрипті.
|
||||
|
||||
`gateway` — це інструмент середовища виконання лише для власника для операцій Gateway:
|
||||
|
||||
- `config.schema.lookup` для одного піддерева конфігурації, обмеженого шляхом, перед редагуванням
|
||||
- `config.get` для поточного знімка конфігурації + hash
|
||||
- `config.get` для поточного знімка конфігурації + хешу
|
||||
- `config.patch` для часткових оновлень конфігурації з перезапуском
|
||||
- `config.apply` лише для повної заміни конфігурації
|
||||
- `update.run` для явного самооновлення + перезапуску
|
||||
|
||||
Для часткових змін надавайте перевагу `config.schema.lookup`, а потім `config.patch`. Використовуйте
|
||||
`config.apply` лише тоді, коли ви свідомо замінюєте всю конфігурацію.
|
||||
Докладніше про конфігурацію див. у [Конфігурація](/uk/gateway/configuration) та
|
||||
Для ширшої документації з конфігурації дивіться [Конфігурація](/uk/gateway/configuration) і
|
||||
[Довідник із конфігурації](/uk/gateway/configuration-reference).
|
||||
Інструмент також відмовляється змінювати `tools.exec.ask` або `tools.exec.security`;
|
||||
застарілі псевдоніми `tools.bash.*` нормалізуються до тих самих захищених шляхів exec.
|
||||
|
||||
### Інструменти, надані Plugin
|
||||
### Інструменти, надані плагінами
|
||||
|
||||
Plugins можуть реєструвати додаткові інструменти. Деякі приклади:
|
||||
Плагіни можуть реєструвати додаткові інструменти. Деякі приклади:
|
||||
|
||||
- [Diffs](/uk/tools/diffs) — переглядач і рендерер diff
|
||||
- [Diffs](/uk/tools/diffs) — засіб перегляду та візуалізації diff
|
||||
- [LLM Task](/uk/tools/llm-task) — крок LLM лише з JSON для структурованого виводу
|
||||
- [Lobster](/uk/tools/lobster) — типізоване середовище виконання workflow з підтвердженнями, які можна відновлювати
|
||||
- [Lobster](/uk/tools/lobster) — типізоване середовище виконання workflow із відновлюваними погодженнями
|
||||
- [Генерація музики](/uk/tools/music-generation) — спільний інструмент `music_generate` із провайдерами на основі workflow
|
||||
- [OpenProse](/uk/prose) — оркестрація workflow з орієнтацією на markdown
|
||||
- [Tokenjuice](/uk/tools/tokenjuice) — компактні результати інструментів `exec` і `bash` з шумним виводом
|
||||
- [OpenProse](/uk/prose) — оркестрація workflow з пріоритетом markdown
|
||||
- [Tokenjuice](/uk/tools/tokenjuice) — компактні результати інструментів `exec` і `bash` з великим шумом
|
||||
|
||||
## Налаштування інструментів
|
||||
|
||||
### Списки дозволених і заборонених
|
||||
### Списки дозволів і заборон
|
||||
|
||||
Керуйте тим, які інструменти агент може викликати, через `tools.allow` / `tools.deny` у
|
||||
конфігурації. Заборона завжди має пріоритет над дозволом.
|
||||
@ -134,63 +134,81 @@ Plugins можуть реєструвати додаткові інструме
|
||||
}
|
||||
```
|
||||
|
||||
OpenClaw працює в режимі fail-closed, коли явний список дозволених не дає жодного викличного інструмента.
|
||||
Наприклад, `tools.allow: ["query_db"]` працює лише якщо завантажений plugin справді
|
||||
реєструє `query_db`. Якщо жоден вбудований, plugin або bundled MCP-інструмент не відповідає
|
||||
списку дозволених, виконання зупиняється до виклику моделі, а не продовжується як
|
||||
запуск лише з текстом, що міг би вигадати результати інструментів.
|
||||
OpenClaw використовує заборону за замовчуванням, якщо явний список дозволів не дає жодного доступного для виклику інструмента.
|
||||
Наприклад, `tools.allow: ["query_db"]` працює, лише якщо завантажений плагін справді
|
||||
реєструє `query_db`. Якщо жоден вбудований, плагінний або вбудований у пакет MCP-інструмент не відповідає
|
||||
списку дозволів, виконання зупиняється до виклику моделі, а не продовжується як
|
||||
режим лише з текстом, який міг би галюцинувати результати інструментів.
|
||||
|
||||
### Профілі інструментів
|
||||
|
||||
`tools.profile` задає базовий список дозволених перед застосуванням `allow`/`deny`.
|
||||
Перевизначення для агента: `agents.list[].tools.profile`.
|
||||
`tools.profile` задає базовий список дозволів до застосування `allow`/`deny`.
|
||||
Перевизначення для окремого агента: `agents.list[].tools.profile`.
|
||||
|
||||
| Профіль | Що він містить |
|
||||
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `full` | Без обмежень (те саме, що не задано) |
|
||||
| Профіль | Що він містить |
|
||||
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `full` | Необмежений базовий рівень для ширшого доступу до команд/керування; те саме, що залишити `tools.profile` не заданим |
|
||||
| `coding` | `group:fs`, `group:runtime`, `group:web`, `group:sessions`, `group:memory`, `cron`, `image`, `image_generate`, `music_generate`, `video_generate` |
|
||||
| `messaging`| `group:messaging`, `sessions_list`, `sessions_history`, `sessions_send`, `session_status` |
|
||||
| `minimal` | Лише `session_status` |
|
||||
| `messaging`| `group:messaging`, `sessions_list`, `sessions_history`, `sessions_send`, `session_status` |
|
||||
| `minimal` | Лише `session_status` |
|
||||
|
||||
<Note>
|
||||
`tools.profile: "messaging"` навмисно є вузьким для
|
||||
агентів, орієнтованих на канали. Він не включає ширші інструменти команд/керування, як-от файлову систему, runtime,
|
||||
browser, canvas, nodes, Cron і керування Gateway. Використовуйте `tools.profile: "full"`
|
||||
як необмежений базовий рівень для ширшого доступу до команд/керування, а потім звужуйте
|
||||
доступ за допомогою `tools.allow` / `tools.deny`, коли це потрібно.
|
||||
</Note>
|
||||
|
||||
`coding` включає полегшені веб-інструменти (`web_search`, `web_fetch`, `x_search`),
|
||||
але не повний інструмент керування браузером. Автоматизація браузера може керувати реальними
|
||||
сесіями та профілями з входом у систему, тому додавайте її явно через
|
||||
`tools.alsoAllow: ["browser"]` або перевизначення для агента
|
||||
сесіями та профілями з виконаним входом, тому додавайте її явно через
|
||||
`tools.alsoAllow: ["browser"]` або перевизначення для окремого агента
|
||||
`agents.list[].tools.alsoAllow: ["browser"]`.
|
||||
|
||||
Профілі `coding` і `messaging` також дозволяють налаштовані bundled MCP-інструменти
|
||||
під ключем plugin `bundle-mcp`. Додайте `tools.deny: ["bundle-mcp"]`, коли ви
|
||||
хочете, щоб профіль зберіг свої звичайні вбудовані інструменти, але приховав усі налаштовані MCP-інструменти.
|
||||
під ключем плагіна `bundle-mcp`. Додайте `tools.deny: ["bundle-mcp"]`, коли
|
||||
ви хочете, щоб профіль зберіг свої звичайні вбудовані інструменти, але приховав усі налаштовані MCP-інструменти.
|
||||
Профіль `minimal` не включає bundled MCP-інструменти.
|
||||
|
||||
Приклад (найширша поверхня інструментів за замовчуванням):
|
||||
|
||||
```json5
|
||||
{
|
||||
tools: {
|
||||
profile: "full",
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
### Групи інструментів
|
||||
|
||||
Використовуйте скорочення `group:*` у списках дозволених/заборонених:
|
||||
Використовуйте скорочення `group:*` у списках дозволів/заборон:
|
||||
|
||||
| Група | Інструменти |
|
||||
| ----------------- | ----------------------------------------------------------------------------------------------------- |
|
||||
| `group:runtime` | exec, process, code_execution (`bash` приймається як псевдонім для `exec`) |
|
||||
| `group:fs` | read, write, edit, apply_patch |
|
||||
| `group:sessions` | sessions_list, sessions_history, sessions_send, sessions_spawn, sessions_yield, subagents, session_status |
|
||||
| `group:memory` | memory_search, memory_get |
|
||||
| `group:web` | web_search, x_search, web_fetch |
|
||||
| `group:ui` | browser, canvas |
|
||||
| `group:automation`| cron, gateway |
|
||||
| `group:messaging` | message |
|
||||
| `group:nodes` | nodes |
|
||||
| `group:agents` | agents_list |
|
||||
| `group:media` | image, image_generate, music_generate, video_generate, tts |
|
||||
| `group:openclaw` | Усі вбудовані інструменти OpenClaw (не включає інструменти plugins) |
|
||||
| Група | Інструменти |
|
||||
| ------------------ | -------------------------------------------------------------------------------------------------------- |
|
||||
| `group:runtime` | exec, process, code_execution (`bash` приймається як псевдонім для `exec`) |
|
||||
| `group:fs` | read, write, edit, apply_patch |
|
||||
| `group:sessions` | sessions_list, sessions_history, sessions_send, sessions_spawn, sessions_yield, subagents, session_status |
|
||||
| `group:memory` | memory_search, memory_get |
|
||||
| `group:web` | web_search, x_search, web_fetch |
|
||||
| `group:ui` | browser, canvas |
|
||||
| `group:automation` | cron, gateway |
|
||||
| `group:messaging` | message |
|
||||
| `group:nodes` | nodes |
|
||||
| `group:agents` | agents_list |
|
||||
| `group:media` | image, image_generate, music_generate, video_generate, tts |
|
||||
| `group:openclaw` | Усі вбудовані інструменти OpenClaw (не включає інструменти плагінів) |
|
||||
|
||||
`sessions_history` повертає обмежене, відфільтроване з погляду безпеки представлення для відновлення контексту. Воно видаляє
|
||||
теги thinking, каркас `<relevant-memories>`, XML-навантаження викликів інструментів у звичайному тексті
|
||||
`sessions_history` повертає обмежене, відфільтроване з погляду безпеки представлення для відтворення контексту. Воно прибирає
|
||||
теги мислення, каркас `<relevant-memories>`, XML-навантаження викликів інструментів у звичайному тексті
|
||||
(включно з `<tool_call>...</tool_call>`,
|
||||
`<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`,
|
||||
`<function_calls>...</function_calls>` і усіченими блоками викликів інструментів),
|
||||
каркас викликів інструментів у зниженому форматі, витеклі ASCII/повноширинні токени керування моделлю
|
||||
та некоректний XML викликів інструментів MiniMax з тексту асистента, а потім застосовує
|
||||
редагування/усічення й, за потреби, заповнювачі для надто великих рядків замість того, щоб
|
||||
бути сирим дампом транскрипту.
|
||||
`<function_calls>...</function_calls>` і скороченими блоками викликів інструментів),
|
||||
понижений каркас викликів інструментів, витоки ASCII/повноширинних токенів керування моделлю
|
||||
та некоректний XML викликів інструментів MiniMax з тексту помічника, а потім застосовує
|
||||
редагування/скорочення та, за потреби, заповнювачі для надто великих рядків, замість того щоб працювати
|
||||
як сирий дамп транскрипту.
|
||||
|
||||
### Обмеження для конкретних провайдерів
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user