diff --git a/docs/uk/plugins/architecture-internals.md b/docs/uk/plugins/architecture-internals.md
index f6804415e..649351d75 100644
--- a/docs/uk/plugins/architecture-internals.md
+++ b/docs/uk/plugins/architecture-internals.md
@@ -1,129 +1,146 @@
---
read_when:
- - Реалізація хуків середовища виконання провайдера, життєвого циклу каналу або пакетних наборів
+ - Реалізація хуків середовища виконання провайдера, життєвого циклу каналу або наборів пакетів
- Налагодження порядку завантаження Plugin або стану реєстру
- Додавання нової можливості Plugin або Plugin рушія контексту
-summary: 'Внутрішні механізми архітектури Plugin: конвеєр завантаження, реєстр, хуки часу виконання, HTTP-маршрути та довідкові таблиці'
-title: Внутрішні аспекти архітектури Plugin
+summary: 'Внутрішня будова архітектури Plugin: конвеєр завантаження, реєстр, хуки середовища виконання, маршрути HTTP і довідкові таблиці'
+title: Внутрішні механізми архітектури Plugin
x-i18n:
- generated_at: "2026-04-29T01:25:02Z"
+ generated_at: "2026-04-29T02:56:18Z"
model: gpt-5.5
provider: openai
- source_hash: 2c1167edfe84782c735fa8f22e25e14728c64289b63774a6c9730fecace7cc1a
+ source_hash: 8bf4d19b962e92580d39b45f6171d937d2d23f3491a32a304bfd62510197ab3e
source_path: plugins/architecture-internals.md
workflow: 16
---
-Для публічної моделі можливостей, форм плагінів і контрактів власності/виконання див. [архітектуру Plugin](/uk/plugins/architecture). Ця сторінка є довідником із внутрішніх механізмів: конвеєр завантаження, реєстр, runtime-хуки, HTTP-маршрути Gateway, шляхи імпорту та таблиці схем.
+Щодо публічної моделі можливостей, форм плагінів і контрактів
+володіння/виконання див. [Архітектура Plugin](/uk/plugins/architecture). Ця сторінка є
+довідником із внутрішньої механіки: конвеєр завантаження, реєстр, runtime-хуки,
+HTTP-маршрути Gateway, шляхи імпорту та таблиці схем.
## Конвеєр завантаження
Під час запуску OpenClaw приблизно виконує таке:
-1. виявляє кандидатські корені плагінів
-2. читає нативні або сумісні маніфести bundle і метадані пакета
+1. знаходить корені кандидатів плагінів
+2. читає нативні або сумісні маніфести bundle і метадані пакетів
3. відхиляє небезпечних кандидатів
4. нормалізує конфігурацію плагінів (`plugins.enabled`, `allow`, `deny`, `entries`,
`slots`, `load.paths`)
-5. визначає ввімкнення для кожного кандидата
-6. завантажує ввімкнені нативні модулі: зібрані bundled-модулі використовують нативний завантажувач;
- незібрані нативні плагіни використовують jiti
-7. викликає нативні хуки `register(api)` і збирає реєстрації в реєстрі плагінів
-8. відкриває реєстр для команд/runtime-поверхонь
+5. визначає увімкнення для кожного кандидата
+6. завантажує увімкнені нативні модулі: зібрані вбудовані модулі використовують нативний завантажувач;
+ незбірні нативні плагіни використовують jiti
+7. викликає нативні хуки `register(api)` і збирає реєстрації в реєстр плагінів
+8. надає реєстр командам і runtime-поверхням
-`activate` — це застарілий псевдонім для `register` — завантажувач визначає, що присутнє (`def.register ?? def.activate`), і викликає це в тій самій точці. Усі bundled-плагіни використовують `register`; для нових плагінів віддавайте перевагу `register`.
+`activate` — це застарілий псевдонім для `register` — завантажувач визначає, що наявне (`def.register ?? def.activate`), і викликає це в тій самій точці. Усі вбудовані плагіни використовують `register`; для нових плагінів віддавайте перевагу `register`.
-Запобіжні перевірки відбуваються **до** runtime-виконання. Кандидати блокуються,
-коли entry виходить за межі кореня плагіна, шлях доступний для запису всім або
-власність шляху виглядає підозрілою для небандлованих плагінів.
+Перевірки безпеки відбуваються **до** runtime-виконання. Кандидати блокуються,
+коли точка входу виходить за межі кореня плагіна, шлях доступний для запису всім
+або володіння шляхом виглядає підозріло для невбудованих плагінів.
-### Поведінка за пріоритетом маніфесту
+### Поведінка з пріоритетом маніфесту
-Маніфест є джерелом істини для control-plane. OpenClaw використовує його, щоб:
+Маніфест є джерелом істини для control plane. OpenClaw використовує його, щоб:
- ідентифікувати плагін
-- виявити оголошені канали/skills/схему конфігурації або можливості bundle
-- перевірити `plugins.entries..config`
-- доповнити мітки/заповнювачі Control UI
-- показати метадані встановлення/каталогу
-- зберегти дешеві дескриптори активації та налаштування без завантаження runtime плагіна
+- виявляти оголошені канали/Skills/схему конфігурації або можливості bundle
+- перевіряти `plugins.entries..config`
+- доповнювати мітки/заповнювачі Control UI
+- показувати метадані встановлення/каталогу
+- зберігати дешеві дескриптори активації та налаштування без завантаження runtime плагіна
-Для нативних плагінів runtime-модуль є data-plane частиною. Він реєструє
-фактичну поведінку, таку як хуки, інструменти, команди або provider-потоки.
+Для нативних плагінів runtime-модуль є частиною data plane. Він реєструє
+фактичну поведінку, як-от хуки, інструменти, команди або потоки провайдерів.
-Необов’язкові блоки маніфесту `activation` і `setup` залишаються на control plane.
+Необов’язкові блоки маніфесту `activation` і `setup` лишаються на control plane.
Це лише метадані-дескриптори для планування активації та виявлення налаштування;
вони не замінюють runtime-реєстрацію, `register(...)` або `setupEntry`.
-Перші живі споживачі активації тепер використовують підказки маніфесту щодо команд, каналів і providers,
+Перші споживачі живої активації тепер використовують підказки команд, каналів і провайдерів із маніфесту,
щоб звузити завантаження плагінів перед ширшою матеріалізацією реєстру:
- завантаження CLI звужується до плагінів, які володіють запитаною основною командою
-- setup/розв’язання плагіна каналу звужується до плагінів, які володіють запитаним
- id каналу
-- явне setup/runtime-розв’язання provider звужується до плагінів, які володіють
- запитаним id provider
-- планування запуску Gateway використовує `activation.onStartup` для явних startup
- imports і відмов від запуску; кожен плагін має оголошувати це, оскільки OpenClaw
- відходить від неявних startup imports, тоді як плагіни без статичних
- метаданих можливостей і без `activation.onStartup` досі використовують
- застарілий неявний sidecar fallback запуску для сумісності
+- розв’язання налаштування каналу/плагіна звужується до плагінів, які володіють запитаним
+ ідентифікатором каналу
+- явне розв’язання налаштування/runtime провайдера звужується до плагінів, які володіють запитаним
+ ідентифікатором провайдера
+- планування запуску Gateway використовує `activation.onStartup` для явних імпортів
+ під час запуску та відмов від запуску; кожен плагін має оголошувати це, оскільки OpenClaw
+ відходить від неявних імпортів під час запуску, тоді як плагіни без статичних
+ метаданих можливостей і без `activation.onStartup` усе ще використовують
+ застарілий неявний fallback startup sidecar для сумісності
-Планувальник активації відкриває і API лише з ids для наявних викликачів, і
-plan API для нової діагностики. Записи плану повідомляють, чому плагін було вибрано,
-відокремлюючи явні підказки планувальника `activation.*` від fallback на основі володіння маніфестом,
-такого як `providers`, `channels`, `commandAliases`, `setup.providers`,
+Планувальник активації надає як API лише з ідентифікаторами для наявних викликачів, так і
+API плану для нової діагностики. Записи плану повідомляють, чому плагін було вибрано,
+відокремлюючи явні підказки планувальника `activation.*` від fallback володіння з маніфесту,
+як-от `providers`, `channels`, `commandAliases`, `setup.providers`,
`contracts.tools` і хуки. Такий поділ причин є межею сумісності:
-наявні метадані плагінів продовжують працювати, а новий код може виявляти широкі підказки
+наявні метадані плагінів продовжують працювати, тоді як новий код може виявляти широкі підказки
або fallback-поведінку без зміни семантики runtime-завантаження.
-Виявлення setup тепер віддає перевагу id, якими володіє дескриптор, таким як `setup.providers` і
-`setup.cliBackends`, щоб звузити кандидатські плагіни перед fallback до
-`setup-api` для плагінів, яким досі потрібні runtime-хуки під час setup. Списки
-provider setup використовують маніфест `providerAuthChoices`, отримані з дескриптора setup
-choices і метадані install-catalog без завантаження runtime provider. Явне
-`setup.requiresRuntime: false` є descriptor-only відсіченням; пропущене
-`requiresRuntime` зберігає застарілий fallback setup-api для сумісності. Якщо більш
-ніж один виявлений плагін заявляє той самий нормалізований setup provider або id CLI
-backend, setup lookup відмовляється від неоднозначного власника замість того, щоб покладатися на
-порядок виявлення. Коли runtime setup все ж виконується, діагностика реєстру повідомляє
-розбіжності між `setup.providers` / `setup.cliBackends` і providers або CLI
+Виявлення налаштування тепер віддає перевагу ідентифікаторам, якими володіють дескриптори, як-от `setup.providers` і
+`setup.cliBackends`, щоб звузити кандидатні плагіни, перш ніж перейти до fallback
+`setup-api` для плагінів, яким досі потрібні runtime-хуки під час налаштування. Списки
+налаштування провайдерів використовують маніфест `providerAuthChoices`, варіанти налаштування,
+виведені з дескрипторів, і метадані каталогу встановлення без завантаження runtime провайдера. Явний
+`setup.requiresRuntime: false` є descriptor-only відсіканням; пропущений
+`requiresRuntime` зберігає застарілий fallback setup-api для сумісності. Якщо більше
+ніж один виявлений плагін заявляє той самий нормалізований ідентифікатор провайдера налаштування або CLI
+backend, пошук налаштування відхиляє неоднозначного власника замість того, щоб покладатися на
+порядок виявлення. Коли runtime налаштування все ж виконується, діагностика реєстру повідомляє
+розбіжності між `setup.providers` / `setup.cliBackends` і провайдерами або CLI
backends, зареєстрованими setup-api, не блокуючи застарілі плагіни.
-### Що кешує завантажувач
+### Межа кешу Plugin
-OpenClaw зберігає короткі in-process кеші для:
+OpenClaw не кешує результати виявлення плагінів або прямі дані реєстру маніфестів
+за часовими вікнами wall-clock. Встановлення, редагування маніфестів і зміни шляхів завантаження
+мають ставати видимими під час наступного явного читання метаданих або перебудови snapshot.
+
+Безпечний швидкий шлях метаданих — це явне володіння об’єктами, а не прихований кеш.
+Гарячі шляхи запуску Gateway мають передавати поточний `PluginMetadataSnapshot`,
+похідний `PluginLookUpTable` або явний реєстр маніфестів через ланцюг викликів.
+Перевірка конфігурації, автоувімкнення під час запуску, bootstrap плагінів, пошук налаштування
+та вибір провайдера можуть повторно використовувати ці об’єкти, доки вони представляють поточну
+конфігурацію й інвентар плагінів. Коли ці вхідні дані змінюються, перебудуйте та замініть
+snapshot замість того, щоб мутувати його або зберігати історичні копії.
+Представлення активного реєстру плагінів і bootstrap-помічники вбудованих каналів
+мають переобчислюватися з поточного реєстру/кореня. Короткоживучі мапи допустимі
+всередині одного виклику для дедуплікації роботи або захисту від повторного входу; вони не мають ставати процесними
+кешами метаданих.
+
+Для завантаження плагінів постійний шар кешу — це runtime-завантаження. Він може повторно використовувати
+стан завантажувача, коли код або встановлені артефакти справді завантажуються, як-от:
+
+- `PluginLoaderCacheState` і сумісні активні runtime-реєстри
+- кеші jiti/module і кеші завантажувачів публічних поверхонь, що використовуються, щоб уникати повторного імпорту
+ тієї самої runtime-поверхні
+- runtime-дзеркала залежностей і кеші файлової системи для встановлених артефактів плагінів
+- короткоживучі мапи на виклик для нормалізації шляхів або розв’язання дублікатів
+
+Ці кеші є деталями реалізації data plane. Вони не мають відповідати на
+запитання control plane, як-от "який плагін володіє цим провайдером?", якщо
+викликач навмисно не попросив runtime-завантаження.
+
+Не додавайте постійні або wall-clock кеші для:
- результатів виявлення
-- даних реєстру маніфестів
-- завантажених реєстрів плагінів
+- прямих реєстрів маніфестів
+- реєстрів маніфестів, реконструйованих із встановленого індексу плагінів
+- пошуку власника провайдера, приглушення моделей, політики провайдера або метаданих публічних артефактів
+- будь-якої іншої відповіді, виведеної з маніфесту, де змінений маніфест, встановлений індекс
+ або шлях завантаження має бути видимим під час наступного читання метаданих
-Ці кеші зменшують навантаження під час вибухових запусків і повторних команд. Їх безпечно
-розглядати як короткоживучі кеші продуктивності, а не як персистентне сховище.
-
-Гарячі шляхи запуску Gateway мають віддавати перевагу поточному `PluginMetadataSnapshot`,
-похідній `PluginLookUpTable` або явному реєстру маніфестів, переданому через
-ланцюжок викликів. Перевірка конфігурації, автоматичне ввімкнення під час запуску та bootstrap плагінів використовують
-той самий snapshot, коли він доступний. Для викликачів, які досі перебудовують метадані
-маніфестів зі збереженого індексу встановлених плагінів, OpenClaw також тримає невеликий
-обмежений fallback-кеш, ключований індексом встановлених плагінів, формою запиту, політикою
-конфігурації, runtime roots і сигнатурами файлів маніфесту/пакета. Цей кеш є лише
-fallback для повторної реконструкції installed-index; це не mutable runtime
-реєстр плагінів.
-
-Примітка щодо продуктивності:
-
-- Установіть `OPENCLAW_DISABLE_PLUGIN_DISCOVERY_CACHE=1` або
- `OPENCLAW_DISABLE_PLUGIN_MANIFEST_CACHE=1`, щоб вимкнути ці кеші.
-- Установіть `OPENCLAW_DISABLE_INSTALLED_PLUGIN_MANIFEST_REGISTRY_CACHE=1`, щоб вимкнути
- лише fallback-кеш реєстру маніфестів installed-index.
-- Налаштовуйте вікна кешу за допомогою `OPENCLAW_PLUGIN_DISCOVERY_CACHE_MS` і
- `OPENCLAW_PLUGIN_MANIFEST_CACHE_MS`.
+Викликачі, які перебудовують метадані маніфестів із збереженого встановленого індексу плагінів,
+реконструюють цей реєстр на вимогу. Встановлений індекс є durable
+станом source plane; це не прихований процесний кеш метаданих.
## Модель реєстру
-Завантажені плагіни не мутують напряму випадкові глобальні змінні core. Вони реєструються в
+Завантажені плагіни не мутують напряму випадкові глобальні об’єкти ядра. Вони реєструються в
центральному реєстрі плагінів.
Реєстр відстежує:
@@ -132,28 +149,28 @@ fallback для повторної реконструкції installed-index;
- інструменти
- застарілі хуки та типізовані хуки
- канали
-- providers
-- обробники RPC Gateway
+- провайдерів
+- gateway RPC-обробники
- HTTP-маршрути
- CLI-реєстратори
-- фонові служби
-- команди, якими володіє плагін
+- фонові сервіси
+- команди, якими володіють плагіни
-Потім core-функції читають із цього реєстру замість того, щоб напряму звертатися до модулів плагінів.
+Потім основні функції читають із цього реєстру замість прямого звернення до модулів плагінів.
Це зберігає завантаження односпрямованим:
- модуль плагіна -> реєстрація в реєстрі
-- runtime core -> споживання реєстру
+- runtime ядра -> споживання реєстру
-Це розділення важливе для підтримуваності. Воно означає, що більшості core-поверхонь потрібна лише
-одна інтеграційна точка: "прочитати реєстр", а не "обробляти кожен модуль плагіна окремим випадком".
+Такий поділ важливий для супроводу. Він означає, що більшості поверхонь ядра потрібна лише
+одна точка інтеграції: "читати реєстр", а не "обробляти кожен модуль плагіна як особливий випадок".
-## Колбеки прив’язки розмови
+## Колбеки прив’язки розмов
Плагіни, які прив’язують розмову, можуть реагувати, коли approval розв’язано.
-Використовуйте `api.onConversationBindingResolved(...)`, щоб отримати callback після схвалення
-або відхилення запиту на bind:
+Використовуйте `api.onConversationBindingResolved(...)`, щоб отримати callback після того, як запит на прив’язку
+схвалено або відхилено:
```ts
export default {
@@ -178,113 +195,114 @@ export default {
- `status`: `"approved"` або `"denied"`
- `decision`: `"allow-once"`, `"allow-always"` або `"deny"`
- `binding`: розв’язана прив’язка для схвалених запитів
-- `request`: початковий summary запиту, detach hint, sender id і
+- `request`: початковий підсумок запиту, підказка від’єднання, ідентифікатор відправника та
метадані розмови
-Цей callback є лише сповіщенням. Він не змінює, кому дозволено прив’язувати
-розмову, і виконується після завершення core-обробки approval.
+Цей callback призначений лише для сповіщення. Він не змінює, кому дозволено прив’язувати
+розмову, і запускається після завершення обробки approval у ядрі.
-## Runtime-хуки provider
+## Runtime-хуки провайдера
-Provider-плагіни мають три шари:
+Плагіни провайдерів мають три шари:
-- **Метадані маніфесту** для дешевого pre-runtime lookup:
- `setup.providers[].envVars`, застарілий сумісний `providerAuthEnvVars`,
+- **Метадані маніфесту** для дешевого pre-runtime пошуку:
+ `setup.providers[].envVars`, застаріла сумісність `providerAuthEnvVars`,
`providerAuthAliases`, `providerAuthChoices` і `channelEnvVars`.
-- **Config-time хуки**: `catalog` (застарілий `discovery`) плюс
+- **Хуки часу конфігурації**: `catalog` (застарілий `discovery`) плюс
`applyConfigDefaults`.
-- **Runtime-хуки**: понад 40 необов’язкових хуків, що охоплюють auth, model resolution,
- stream wrapping, thinking levels, replay policy і usage endpoints. Див.
+- **Runtime-хуки**: понад 40 необов’язкових хуків, що охоплюють автентифікацію, розв’язання моделей,
+ обгортання stream, рівні thinking, політику replay та endpoint-и usage. Див.
повний список у розділі [Порядок хуків і використання](#hook-order-and-usage).
-OpenClaw досі володіє generic agent loop, failover, обробкою transcript і
-tool policy. Ці хуки є extension-поверхнею для provider-specific
-поведінки без потреби в цілому custom inference transport.
+OpenClaw усе ще володіє загальним циклом агента, failover, обробкою transcript і
+політикою інструментів. Ці хуки є поверхнею розширення для специфічної для провайдера
+поведінки без потреби в повністю власному inference transport.
-Використовуйте маніфест `setup.providers[].envVars`, коли provider має облікові дані на основі env,
-які generic auth/status/model-picker шляхи мають бачити без
+Використовуйте маніфест `setup.providers[].envVars`, коли провайдер має env-based
+облікові дані, які загальні шляхи auth/status/model-picker мають бачити без
завантаження runtime плагіна. Застарілий `providerAuthEnvVars` досі читається
-compatibility adapter під час deprecation window, а небандловані плагіни,
+адаптером сумісності протягом вікна deprecation, а невбудовані плагіни,
які його використовують, отримують діагностику маніфесту. Використовуйте маніфест `providerAuthAliases`,
-коли один provider id має повторно використовувати env vars, auth profiles,
-config-backed auth і API-key onboarding choice іншого provider id. Використовуйте маніфест
-`providerAuthChoices`, коли onboarding/auth-choice CLI-поверхні мають знати
-choice id provider, group labels і просте one-flag auth wiring без
-завантаження runtime provider. Залишайте runtime provider
-`envVars` для підказок, орієнтованих на оператора, таких як onboarding labels або OAuth
-client-id/client-secret setup vars.
+коли один ідентифікатор провайдера має повторно використовувати env vars іншого ідентифікатора провайдера, профілі auth,
+auth на основі конфігурації та варіант onboarding для API key. Використовуйте маніфест
+`providerAuthChoices`, коли onboarding/auth-choice CLI surfaces мають знати
+choice id провайдера, мітки груп і просте one-flag wiring auth без
+завантаження runtime провайдера. Зберігайте runtime провайдера
+`envVars` для підказок для операторів, як-от мітки onboarding або змінні налаштування OAuth
+client-id/client-secret.
-Використовуйте маніфест `channelEnvVars`, коли канал має auth або setup на основі env, які
-generic shell-env fallback, config/status checks або setup prompts мають бачити
+Використовуйте маніфест `channelEnvVars`, коли канал має env-driven auth або setup, які
+generic shell-env fallback, перевірки config/status або prompts налаштування мають бачити
без завантаження runtime каналу.
### Порядок хуків і використання
-Для model/provider плагінів OpenClaw викликає хуки приблизно в такому порядку.
-Стовпець "Коли використовувати" — це короткий посібник із вибору.
+Для плагінів моделей/провайдерів OpenClaw викликає хуки приблизно в такому порядку.
+Стовпець "Коли використовувати" — це короткий посібник для вибору.
-| # | Хук | Що робить | Коли використовувати |
+| # | Гук | Що він робить | Коли використовувати |
| --- | --------------------------------- | -------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
-| 1 | `catalog` | Публікує конфігурацію провайдера в `models.providers` під час генерації `models.json` | Провайдер володіє каталогом або типовими значеннями базового URL |
-| 2 | `applyConfigDefaults` | Застосовує глобальні типові значення конфігурації, що належать провайдеру, під час матеріалізації конфігурації | Типові значення залежать від режиму автентифікації, середовища або семантики сімейства моделей провайдера |
-| -- | _(вбудований пошук моделі)_ | OpenClaw спершу пробує звичайний шлях реєстру/каталогу | _(не хук Plugin)_ |
-| 3 | `normalizeModelId` | Нормалізує застарілі або попередні псевдоніми ідентифікаторів моделей перед пошуком | Провайдер володіє очищенням псевдонімів перед канонічним розв’язанням моделі |
-| 4 | `normalizeTransport` | Нормалізує `api` / `baseUrl` сімейства провайдера перед загальним складанням моделі | Провайдер володіє очищенням транспорту для власних ідентифікаторів провайдерів у тому самому транспортному сімействі |
-| 5 | `normalizeConfig` | Нормалізує `models.providers.` перед розв’язанням середовища виконання/провайдера | Провайдеру потрібне очищення конфігурації, яке має жити разом із Plugin; вбудовані помічники сімейства Google також підстраховують підтримувані записи конфігурації Google |
-| 6 | `applyNativeStreamingUsageCompat` | Застосовує сумісні переписування нативного потокового використання до провайдерів конфігурації | Провайдеру потрібні виправлення метаданих нативного потокового використання, керовані кінцевою точкою |
-| 7 | `resolveConfigApiKey` | Розв’язує автентифікацію з env-маркером для провайдерів конфігурації перед завантаженням runtime-автентифікації | Провайдер має власне розв’язання API-ключа з env-маркером; `amazon-bedrock` також має тут вбудований розв’язувач env-маркера AWS |
-| 8 | `resolveSyntheticAuth` | Виводить локальну/самостійно розміщену або підтриману конфігурацією автентифікацію без збереження відкритого тексту | Провайдер може працювати із синтетичним/локальним маркером облікових даних |
-| 9 | `resolveExternalAuthProfiles` | Накладає зовнішні профілі автентифікації, що належать провайдеру; типовий `persistence` — `runtime-only` для облікових даних, що належать CLI/застосунку | Провайдер повторно використовує зовнішні облікові дані автентифікації без збереження скопійованих refresh-токенів; оголосіть `contracts.externalAuthProviders` у маніфесті |
-| 10 | `shouldDeferSyntheticProfileAuth` | Знижує пріоритет збережених синтетичних заповнювачів профілів за автентифікацією на основі середовища/конфігурації | Провайдер зберігає синтетичні профілі-заповнювачі, які не мають перемагати за пріоритетом |
-| 11 | `resolveDynamicModel` | Синхронний запасний варіант для ідентифікаторів моделей, що належать провайдеру й ще не є в локальному реєстрі | Провайдер приймає довільні ідентифікатори моделей від upstream |
-| 12 | `prepareDynamicModel` | Асинхронний прогрів, після якого `resolveDynamicModel` запускається знову | Провайдеру потрібні мережеві метадані перед розв’язанням невідомих ідентифікаторів |
-| 13 | `normalizeResolvedModel` | Фінальне переписування перед тим, як вбудований runner використає розв’язану модель | Провайдеру потрібні переписування транспорту, але він усе ще використовує core-транспорт |
-| 14 | `contributeResolvedModelCompat` | Додає прапорці сумісності для моделей постачальника за іншим сумісним транспортом | Провайдер розпізнає власні моделі на проксі-транспортах без перебрання провайдера |
-| 15 | `capabilities` | Метадані транскрипту/інструментів, що належать провайдеру й використовуються спільною core-логікою | Провайдеру потрібні особливості транскрипту/сімейства провайдера |
-| 16 | `normalizeToolSchemas` | Нормалізує схеми інструментів перед тим, як їх побачить вбудований runner | Провайдеру потрібне очищення схем транспортного сімейства |
-| 17 | `inspectToolSchemas` | Виводить діагностику схем, що належить провайдеру, після нормалізації | Провайдер хоче попередження щодо ключових слів без навчання core правилам, специфічним для провайдера |
-| 18 | `resolveReasoningOutputMode` | Вибирає нативний або тегований контракт виводу міркування | Провайдеру потрібне теговане міркування/фінальний вивід замість нативних полів |
-| 19 | `prepareExtraParams` | Нормалізація параметрів запиту перед загальними обгортками потокових опцій | Провайдеру потрібні типові параметри запиту або очищення параметрів для окремого провайдера |
-| 20 | `createStreamFn` | Повністю замінює звичайний шлях потоку власним транспортом | Провайдеру потрібен власний wire-протокол, а не лише обгортка |
-| 21 | `wrapStreamFn` | Обгортка потоку після застосування загальних обгорток | Провайдеру потрібні обгортки сумісності заголовків/тіла/моделі запиту без власного транспорту |
-| 22 | `resolveTransportTurnState` | Додає нативні транспортні заголовки або метадані для кожного ходу | Провайдер хоче, щоб загальні транспорти надсилали нативну ідентичність ходу провайдера |
-| 23 | `resolveWebSocketSessionPolicy` | Додає нативні заголовки WebSocket або політику охолодження сесії | Провайдер хоче, щоб загальні WS-транспорти налаштовували заголовки сесії або політику запасного варіанта |
-| 24 | `formatApiKey` | Форматувач профілю автентифікації: збережений профіль стає runtime-рядком `apiKey` | Провайдер зберігає додаткові метадані автентифікації й потребує власної форми runtime-токена |
-| 25 | `refreshOAuth` | Перевизначення оновлення OAuth для власних кінцевих точок оновлення або політики збоїв оновлення | Провайдер не вписується у спільні оновлювачі `pi-ai` |
-| 26 | `buildAuthDoctorHint` | Підказка з відновлення, що додається, коли оновлення OAuth завершується збоєм | Провайдеру потрібні власні настанови з відновлення автентифікації після збою оновлення |
-| 27 | `matchesContextOverflowError` | Матчер переповнення контекстного вікна, що належить провайдеру | Провайдер має сирі помилки переповнення, які загальні евристики пропустили б |
-| 28 | `classifyFailoverReason` | Класифікація причини failover, що належить провайдеру | Провайдер може зіставляти сирі помилки API/транспорту з обмеженням швидкості/перевантаженням тощо |
-| 29 | `isCacheTtlEligible` | Політика кешу підказок для проксі/backhaul-провайдерів | Провайдеру потрібне специфічне для проксі керування придатністю TTL кешу |
-| 30 | `buildMissingAuthMessage` | Заміна загального повідомлення відновлення в разі відсутньої автентифікації | Провайдеру потрібна специфічна для провайдера підказка відновлення відсутньої автентифікації |
-| 31 | `suppressBuiltInModel` | Застаріло. Runtime-хук більше не викликається; використовуйте `modelCatalog.suppressions` у маніфесті | Історичний хук для приховування застарілих upstream-рядків; зберігайте нові дані приглушення в маніфесті Plugin |
-| 32 | `augmentModelCatalog` | Синтетичні/фінальні рядки каталогу, що додаються після виявлення | Провайдеру потрібні синтетичні рядки forward-сумісності в `models list` і засобах вибору |
-| 33 | `resolveThinkingProfile` | Специфічний для моделі набір рівнів `/think`, відображувані мітки та типове значення | Провайдер відкриває власну драбину мислення або бінарну мітку для вибраних моделей |
-| 34 | `isBinaryThinking` | Хук сумісності перемикача міркування увімкнено/вимкнено | Провайдер відкриває лише бінарне мислення увімкнено/вимкнено |
-| 35 | `supportsXHighThinking` | Хук сумісності підтримки міркування `xhigh` | Провайдер хоче `xhigh` лише для підмножини моделей |
-| 36 | `resolveDefaultThinkingLevel` | Хук сумісності типового рівня `/think` | Провайдер володіє типовою політикою `/think` для сімейства моделей |
-| 37 | `isModernModelRef` | Зіставлювач сучасних моделей для фільтрів live-профілю та вибору smoke | Провайдер керує зіставленням бажаних моделей для live/smoke |
-| 38 | `prepareRuntimeAuth` | Обміняти налаштовані облікові дані на фактичний runtime-токен/ключ безпосередньо перед інференсом | Провайдеру потрібен обмін токена або короткочасні облікові дані запиту |
-| 39 | `resolveUsageAuth` | Визначити облікові дані використання/білінгу для `/usage` і пов’язаних поверхонь статусу | Провайдеру потрібен власний розбір токенів використання/квот або інші облікові дані використання |
-| 40 | `fetchUsageSnapshot` | Отримати й нормалізувати специфічні для провайдера знімки використання/квот після визначення автентифікації | Провайдеру потрібна специфічна для нього кінцева точка використання або парсер payload |
-| 41 | `createEmbeddingProvider` | Створити керований провайдером адаптер вбудовувань для пам’яті/пошуку | Поведінка вбудовувань пам’яті належить Plugin провайдера |
-| 42 | `buildReplayPolicy` | Повернути політику повторного відтворення, що керує обробкою транскрипту для провайдера | Провайдеру потрібна власна політика транскрипту (наприклад, видалення блоків міркування) |
-| 43 | `sanitizeReplayHistory` | Переписати історію повторного відтворення після загального очищення транскрипту | Провайдеру потрібні специфічні для нього переписування повторного відтворення поза спільними допоміжними засобами Compaction |
-| 44 | `validateReplayTurns` | Остаточна перевірка або переформування кроків повторного відтворення перед вбудованим runner | Транспорту провайдера потрібна суворіша перевірка кроків після загальної санітизації |
-| 45 | `onModelSelected` | Виконати керовані провайдером побічні ефекти після вибору | Провайдеру потрібна телеметрія або керований провайдером стан, коли модель стає активною |
+| 1 | `catalog` | Публікує конфігурацію постачальника в `models.providers` під час генерації `models.json` | Постачальник володіє каталогом або типовими значеннями базової URL-адреси |
+| 2 | `applyConfigDefaults` | Застосовує глобальні типові значення конфігурації, якими володіє постачальник, під час матеріалізації конфігурації | Типові значення залежать від режиму автентифікації, env або семантики сімейства моделей постачальника |
+| -- | _(вбудований пошук моделі)_ | OpenClaw спершу пробує звичайний шлях реєстру/каталогу | _(не гук Plugin)_ |
+| 3 | `normalizeModelId` | Нормалізує застарілі або preview псевдоніми ідентифікаторів моделей перед пошуком | Постачальник відповідає за очищення псевдонімів перед розв'язанням канонічної моделі |
+| 4 | `normalizeTransport` | Нормалізує `api` / `baseUrl` сімейства постачальників перед загальним складанням моделі | Постачальник відповідає за очищення транспорту для власних ідентифікаторів постачальника в тому самому транспортному сімействі |
+| 5 | `normalizeConfig` | Нормалізує `models.providers.` перед розв'язанням runtime/постачальника | Постачальнику потрібне очищення конфігурації, яке має жити разом із Plugin; вбудовані допоміжні засоби сімейства Google також підстраховують підтримувані записи конфігурації Google |
+| 6 | `applyNativeStreamingUsageCompat` | Застосовує compat-переписування нативного streaming-usage до постачальників конфігурації | Постачальнику потрібні виправлення метаданих нативного streaming usage, керовані endpoint-ами |
+| 7 | `resolveConfigApiKey` | Розв'язує автентифікацію env-marker для постачальників конфігурації перед завантаженням runtime-автентифікації | Постачальник має власне розв'язання env-marker API-ключа; `amazon-bedrock` також має тут вбудований резолвер AWS env-marker |
+| 8 | `resolveSyntheticAuth` | Відображає локальну/self-hosted або конфігураційно підкріплену автентифікацію без збереження відкритого тексту | Постачальник може працювати із синтетичним/локальним маркером облікових даних |
+| 9 | `resolveExternalAuthProfiles` | Накладає зовнішні профілі автентифікації, якими володіє постачальник; типове `persistence` — `runtime-only` для облікових даних, якими володіє CLI/застосунок | Постачальник повторно використовує зовнішні облікові дані автентифікації без збереження скопійованих refresh-токенів; оголосіть `contracts.externalAuthProviders` у маніфесті |
+| 10 | `shouldDeferSyntheticProfileAuth` | Знижує пріоритет збережених синтетичних заповнювачів профілю за автентифікацією, підкріпленою env/конфігурацією | Постачальник зберігає синтетичні профілі-заповнювачі, які не повинні мати перевагу |
+| 11 | `resolveDynamicModel` | Синхронний резервний варіант для ідентифікаторів моделей постачальника, яких ще немає в локальному реєстрі | Постачальник приймає довільні upstream-ідентифікатори моделей |
+| 12 | `prepareDynamicModel` | Асинхронний прогрів, після якого `resolveDynamicModel` запускається знову | Постачальнику потрібні мережеві метадані перед розв'язанням невідомих ідентифікаторів |
+| 13 | `normalizeResolvedModel` | Фінальне переписування перед тим, як вбудований runner використає розв'язану модель | Постачальнику потрібні переписування транспорту, але він усе ще використовує core-транспорт |
+| 14 | `contributeResolvedModelCompat` | Додає compat-прапорці для моделей вендора за іншим сумісним транспортом | Постачальник розпізнає власні моделі на proxy-транспортах, не перебираючи на себе постачальника |
+| 15 | `capabilities` | Метадані транскрипту/інструментів, якими володіє постачальник і які використовує спільна core-логіка | Постачальнику потрібні особливості транскрипту/сімейства постачальників |
+| 16 | `normalizeToolSchemas` | Нормалізує схеми інструментів до того, як їх побачить вбудований runner | Постачальнику потрібне очищення схем транспортного сімейства |
+| 17 | `inspectToolSchemas` | Відображає діагностику схем, якою володіє постачальник, після нормалізації | Постачальник хоче попередження щодо ключових слів без навчання core специфічним для постачальника правилам |
+| 18 | `resolveReasoningOutputMode` | Вибирає контракт виводу reasoning: нативний або з тегами | Постачальнику потрібен reasoning/фінальний вивід із тегами замість нативних полів |
+| 19 | `prepareExtraParams` | Нормалізація параметрів запиту перед загальними обгортками параметрів потоку | Постачальнику потрібні типові параметри запиту або очищення параметрів окремого постачальника |
+| 20 | `createStreamFn` | Повністю замінює звичайний шлях потоку власним транспортом | Постачальнику потрібен власний wire-протокол, а не лише обгортка |
+| 21 | `wrapStreamFn` | Обгортка потоку після застосування загальних обгорток | Постачальнику потрібні обгортки заголовків/тіла/сумісності моделі запиту без власного транспорту |
+| 22 | `resolveTransportTurnState` | Додає нативні транспортні заголовки або метадані для кожного turn | Постачальник хоче, щоб загальні транспорти надсилали нативну для постачальника ідентичність turn |
+| 23 | `resolveWebSocketSessionPolicy` | Додає нативні заголовки WebSocket або політику cool-down сеансу | Постачальник хоче, щоб загальні WS-транспорти налаштовували заголовки сеансу або політику резервного варіанта |
+| 24 | `formatApiKey` | Форматер профілю автентифікації: збережений профіль стає runtime-рядком `apiKey` | Постачальник зберігає додаткові метадані автентифікації й потребує власної форми runtime-токена |
+| 25 | `refreshOAuth` | Перевизначення оновлення OAuth для власних endpoint-ів оновлення або політики помилки оновлення | Постачальник не вписується у спільні refreshers `pi-ai` |
+| 26 | `buildAuthDoctorHint` | Підказка ремонту, що додається, коли оновлення OAuth не вдається | Постачальнику потрібні власні вказівки з ремонту автентифікації після помилки оновлення |
+| 27 | `matchesContextOverflowError` | Matcher переповнення вікна контексту, яким володіє постачальник | Постачальник має необроблені помилки переповнення, які загальні евристики пропустили б |
+| 28 | `classifyFailoverReason` | Класифікація причини failover, якою володіє постачальник | Постачальник може зіставляти необроблені API/транспортні помилки з rate-limit/overload/тощо |
+| 29 | `isCacheTtlEligible` | Політика кешу підказок для proxy/backhaul постачальників | Постачальнику потрібне proxy-специфічне керування cache TTL |
+| 30 | `buildMissingAuthMessage` | Заміна загального повідомлення відновлення у разі відсутньої автентифікації | Постачальнику потрібна специфічна для постачальника підказка відновлення у разі відсутньої автентифікації |
+| 31 | `suppressBuiltInModel` | Застаріло. Runtime-гук більше не викликається; використовуйте `modelCatalog.suppressions` у маніфесті | Історичний гук для приховування застарілих upstream-рядків; зберігайте нові дані придушення в маніфесті Plugin |
+| 32 | `augmentModelCatalog` | Синтетичні/фінальні рядки каталогу, додані після discovery | Постачальнику потрібні синтетичні forward-compat рядки в `models list` і picker-ах |
+| 33 | `resolveThinkingProfile` | Набір рівнів `/think` для конкретної моделі, відображувані мітки та типове значення | Постачальник надає власну шкалу thinking або бінарну мітку для вибраних моделей |
+| 34 | `isBinaryThinking` | Гук сумісності перемикача reasoning увімкнено/вимкнено | Постачальник надає лише бінарне thinking увімкнено/вимкнено |
+| 35 | `supportsXHighThinking` | Гук сумісності підтримки reasoning `xhigh` | Постачальник хоче `xhigh` лише для підмножини моделей |
+| 36 | `resolveDefaultThinkingLevel` | Гук сумісності типового рівня `/think` | Постачальник володіє типовою політикою `/think` для сімейства моделей |
+| 37 | `isModernModelRef` | Зіставник сучасних моделей для фільтрів live-профілів і вибору smoke | Провайдер володіє зіставленням бажаної моделі для live/smoke |
+| 38 | `prepareRuntimeAuth` | Обмінює налаштовані облікові дані на фактичний runtime-токен/ключ безпосередньо перед інференсом | Провайдеру потрібен обмін токена або короткострокові облікові дані запиту |
+| 39 | `resolveUsageAuth` | Визначає облікові дані використання/білінгу для `/usage` і пов’язаних поверхонь стану | Провайдеру потрібен власний розбір токена використання/квоти або інші облікові дані використання |
+| 40 | `fetchUsageSnapshot` | Отримує та нормалізує специфічні для провайдера знімки використання/квоти після визначення auth | Провайдеру потрібен специфічний для провайдера endpoint використання або parser payload |
+| 41 | `createEmbeddingProvider` | Створює адаптер embedding, яким володіє провайдер, для пам’яті/пошуку | Поведінка embedding для пам’яті належить Plugin провайдера |
+| 42 | `buildReplayPolicy` | Повертає політику replay, яка керує обробкою transcript для провайдера | Провайдеру потрібна власна політика transcript (наприклад, вилучення thinking-block) |
+| 43 | `sanitizeReplayHistory` | Переписує історію replay після загального очищення transcript | Провайдеру потрібні специфічні для провайдера перезаписи replay поза спільними helper Compaction |
+| 44 | `validateReplayTurns` | Фінальна перевірка або зміна форми replay-turn перед вбудованим runner | Транспорт провайдера потребує суворішої перевірки turn після загальної санації |
+| 45 | `onModelSelected` | Виконує побічні ефекти після вибору, якими володіє провайдер | Провайдеру потрібна телеметрія або стан, яким володіє провайдер, коли модель стає active |
-`normalizeModelId`, `normalizeTransport` і `normalizeConfig` спершу перевіряють
-відповідний provider plugin, а потім переходять до інших provider plugins із
-підтримкою хуків, доки один із них фактично не змінить model id або transport/config. Це зберігає
-працездатність alias/compat provider shims без вимоги до викликача знати, який
-вбудований plugin відповідає за переписування. Якщо жоден provider hook не переписує підтримуваний
-запис конфігурації сімейства Google, вбудований нормалізатор конфігурації Google все одно застосує
-це суміснісне очищення.
+`normalizeModelId`, `normalizeTransport` і `normalizeConfig` спочатку перевіряють
+відповідний Plugin постачальника, а потім переходять до інших Plugin постачальників,
+що підтримують хуки, доки один із них фактично не змінить ідентифікатор моделі або
+транспорт/config. Це зберігає роботу shim-шарів постачальників для псевдонімів/сумісності
+без потреби, щоб викликач знав, який вбудований Plugin відповідає за переписування.
+Якщо жоден хук постачальника не переписує підтримуваний запис config із родини
+Google, усе одно застосовується вбудований нормалізатор config Google для цього
+очищення сумісності.
-Якщо provider потребує повністю власного wire protocol або власного request executor,
-це інший клас розширення. Ці хуки призначені для поведінки provider,
-яка все ще працює у звичайному inference loop OpenClaw.
+Якщо постачальнику потрібен повністю власний дротовий протокол або власний виконавець
+запитів, це інший клас розширення. Ці хуки призначені для поведінки постачальника,
+яка все ще працює у звичайному циклі інференсу OpenClaw.
-### Приклад provider
+### Приклад постачальника
```ts
api.registerProvider({
@@ -340,45 +358,45 @@ api.registerProvider({
### Вбудовані приклади
-Вбудовані provider plugins поєднують наведені вище хуки, щоб відповідати потребам кожного постачальника щодо catalog,
-auth, thinking, replay і usage. Авторитетний набір хуків міститься в
-кожному plugin у `extensions/`; ця сторінка ілюструє форми, а не
-дзеркально відтворює список.
+Вбудовані Plugin постачальників поєднують наведені вище хуки, щоб відповідати
+потребам каталогу, автентифікації, мислення, відтворення та обліку використання
+кожного вендора. Авторитетний набір хуків міститься в кожному Plugin у `extensions/`;
+ця сторінка ілюструє форми, а не дублює список.
-
- OpenRouter, Kilocode, Z.AI, xAI реєструють `catalog` плюс
- `resolveDynamicModel` / `prepareDynamicModel`, щоб показувати upstream
- model ids раніше за статичний catalog OpenClaw.
+
+ OpenRouter, Kilocode, Z.AI, xAI реєструють `catalog` разом із
+ `resolveDynamicModel` / `prepareDynamicModel`, щоб вони могли показувати
+ upstream-ідентифікатори моделей раніше за статичний каталог OpenClaw.
-
+
GitHub Copilot, Gemini CLI, ChatGPT Codex, MiniMax, Xiaomi, z.ai поєднують
- `prepareRuntimeAuth` або `formatApiKey` із `resolveUsageAuth` +
- `fetchUsageSnapshot`, щоб володіти token exchange та інтеграцією `/usage`.
+ `prepareRuntimeAuth` або `formatApiKey` з `resolveUsageAuth` +
+ `fetchUsageSnapshot`, щоб володіти обміном токенів та інтеграцією `/usage`.
-
- Спільні іменовані сімейства (`google-gemini`, `passthrough-gemini`,
- `anthropic-by-model`, `hybrid-anthropic-openai`) дають providers змогу підключатися до
- transcript policy через `buildReplayPolicy`, замість того щоб кожен plugin
- повторно реалізовував очищення.
+
+ Спільні іменовані родини (`google-gemini`, `passthrough-gemini`,
+ `anthropic-by-model`, `hybrid-anthropic-openai`) дають постачальникам змогу
+ підключатися до політики транскриптів через `buildReplayPolicy`, замість того
+ щоб кожен Plugin повторно реалізовував очищення.
-
+
`byteplus`, `cloudflare-ai-gateway`, `huggingface`, `kimi-coding`, `nvidia`,
`qianfan`, `synthetic`, `together`, `venice`, `vercel-ai-gateway` і
- `volcengine` реєструють лише `catalog` і використовують спільний inference loop.
+ `volcengine` реєструють лише `catalog` і використовують спільний цикл інференсу.
-
- Beta headers, `/fast` / `serviceTier` і `context1m` містяться всередині
- публічної межі `api.ts` / `contract-api.ts` Anthropic plugin
+
+ Beta-заголовки, `/fast` / `serviceTier` і `context1m` містяться всередині
+ публічного шва `api.ts` / `contract-api.ts` Plugin Anthropic
(`wrapAnthropicProviderStream`, `resolveAnthropicBetas`,
`resolveAnthropicFastMode`, `resolveAnthropicServiceTier`), а не в
- generic SDK.
+ загальному SDK.
-## Runtime helpers
+## Допоміжні засоби runtime
-Plugins можуть отримувати доступ до вибраних core helpers через `api.runtime`. Для TTS:
+Plugin можуть звертатися до вибраних допоміжних засобів ядра через `api.runtime`. Для TTS:
```ts
const clip = await api.runtime.tts.textToSpeech({
@@ -399,14 +417,14 @@ const voices = await api.runtime.tts.listVoices({
Примітки:
-- `textToSpeech` повертає звичайний core TTS output payload для поверхонь файлів/голосових нотаток.
-- Використовує core-конфігурацію `messages.tts` і вибір provider.
-- Повертає PCM audio buffer + sample rate. Plugins мають виконувати resample/encode для providers.
-- `listVoices` є необов’язковим для кожного provider. Використовуйте його для vendor-owned voice pickers або setup flows.
-- Списки голосів можуть містити багатші metadata, як-от locale, gender і personality tags для provider-aware pickers.
-- OpenAI і ElevenLabs сьогодні підтримують telephony. Microsoft не підтримує.
+- `textToSpeech` повертає звичайне ядрове корисне навантаження TTS для поверхонь файлів/голосових нотаток.
+- Використовує конфігурацію ядра `messages.tts` і вибір постачальника.
+- Повертає PCM-аудіобуфер + частоту дискретизації. Plugin мають виконувати ресемплінг/кодування для постачальників.
+- `listVoices` необов’язковий для кожного постачальника. Використовуйте його для належних вендору вибирачів голосу або потоків налаштування.
+- Списки голосів можуть містити багатші метадані, як-от locale, гендер і теги особистості для вибирачів, обізнаних про постачальника.
+- OpenAI та ElevenLabs наразі підтримують телефонію. Microsoft не підтримує.
-Plugins також можуть реєструвати speech providers через `api.registerSpeechProvider(...)`.
+Plugin також можуть реєструвати постачальників мовлення через `api.registerSpeechProvider(...)`.
```ts
api.registerSpeechProvider({
@@ -426,15 +444,15 @@ api.registerSpeechProvider({
Примітки:
-- Залишайте TTS policy, fallback і reply delivery у core.
-- Використовуйте speech providers для vendor-owned synthesis behavior.
-- Legacy Microsoft `edge` input нормалізується до provider id `microsoft`.
-- Бажана модель ownership орієнтована на компанію: один vendor plugin може володіти
- text, speech, image і майбутніми media providers у міру того, як OpenClaw додає ці
- capability contracts.
+- Тримайте політику TTS, fallback і доставлення відповіді в ядрі.
+- Використовуйте постачальників мовлення для належної вендору поведінки синтезу.
+- Застарілий вхід Microsoft `edge` нормалізується до ідентифікатора постачальника `microsoft`.
+- Бажана модель володіння орієнтована на компанію: один вендорський Plugin може володіти
+ постачальниками тексту, мовлення, зображень і майбутніх медіа, коли OpenClaw додаватиме ці
+ контракти можливостей.
-Для розуміння image/audio/video plugins реєструють один типізований
-media-understanding provider замість generic key/value bag:
+Для розуміння зображень/аудіо/відео Plugin реєструють одного типізованого
+постачальника media-understanding замість загального набору ключ/значення:
```ts
api.registerMediaUnderstandingProvider({
@@ -448,16 +466,16 @@ api.registerMediaUnderstandingProvider({
Примітки:
-- Залишайте orchestration, fallback, config і channel wiring у core.
-- Залишайте vendor behavior у provider plugin.
-- Additive expansion має залишатися типізованим: нові необов’язкові methods, нові необов’язкові
- result fields, нові необов’язкові capabilities.
-- Video generation уже дотримується того самого шаблону:
- - core володіє capability contract і runtime helper
- - vendor plugins реєструють `api.registerVideoGenerationProvider(...)`
- - feature/channel plugins споживають `api.runtime.videoGeneration.*`
+- Тримайте оркестрацію, fallback, config і зв’язування каналів у ядрі.
+- Тримайте поведінку вендора в Plugin постачальника.
+- Адитивне розширення має залишатися типізованим: нові необов’язкові методи, нові необов’язкові
+ поля результату, нові необов’язкові можливості.
+- Генерація відео вже дотримується того самого патерну:
+ - ядро володіє контрактом можливості та допоміжним засобом runtime
+ - вендорські Plugin реєструють `api.registerVideoGenerationProvider(...)`
+ - Plugin функцій/каналів використовують `api.runtime.videoGeneration.*`
-Для media-understanding runtime helpers plugins можуть викликати:
+Для допоміжних засобів runtime media-understanding Plugin можуть викликати:
```ts
const image = await api.runtime.mediaUnderstanding.describeImageFile({
@@ -472,8 +490,8 @@ const video = await api.runtime.mediaUnderstanding.describeVideoFile({
});
```
-Для audio transcription plugins можуть використовувати або media-understanding runtime,
-або старіший STT alias:
+Для транскрипції аудіо Plugin можуть використовувати або runtime media-understanding,
+або старіший псевдонім STT:
```ts
const { text } = await api.runtime.mediaUnderstanding.transcribeAudioFile({
@@ -487,12 +505,12 @@ const { text } = await api.runtime.mediaUnderstanding.transcribeAudioFile({
Примітки:
- `api.runtime.mediaUnderstanding.*` є бажаною спільною поверхнею для
- image/audio/video understanding.
-- Використовує core-конфігурацію media-understanding audio (`tools.media.audio`) і порядок fallback для provider.
-- Повертає `{ text: undefined }`, коли transcription output не створено (наприклад, skipped/unsupported input).
-- `api.runtime.stt.transcribeAudioFile(...)` залишається compatibility alias.
+ розуміння зображень/аудіо/відео.
+- Використовує ядрову аудіоконфігурацію media-understanding (`tools.media.audio`) і порядок fallback постачальників.
+- Повертає `{ text: undefined }`, коли вихід транскрипції не створено (наприклад, пропущений/непідтримуваний вхід).
+- `api.runtime.stt.transcribeAudioFile(...)` залишається псевдонімом сумісності.
-Plugins також можуть запускати фонові subagent runs через `api.runtime.subagent`:
+Plugin також можуть запускати фонові виконання субагентів через `api.runtime.subagent`:
```ts
const result = await api.runtime.subagent.run({
@@ -506,15 +524,15 @@ const result = await api.runtime.subagent.run({
Примітки:
-- `provider` і `model` є необов’язковими per-run overrides, а не persistent session changes.
-- OpenClaw враховує ці override fields лише для trusted callers.
-- Для plugin-owned fallback runs operators мають увімкнути `plugins.entries..subagent.allowModelOverride: true`.
-- Використовуйте `plugins.entries..subagent.allowedModels`, щоб обмежити trusted plugins конкретними canonical targets `provider/model`, або `"*"`, щоб явно дозволити будь-яку target.
-- Untrusted plugin subagent runs усе ще працюють, але override requests відхиляються, а не мовчки falling back.
-- Створені plugin subagent sessions позначаються id plugin, який їх створив. Fallback `api.runtime.subagent.deleteSession(...)` може видаляти лише ці owned sessions; довільне видалення session все ще потребує admin-scoped Gateway request.
+- `provider` і `model` є необов’язковими перевизначеннями для окремого запуску, а не постійними змінами сеансу.
+- OpenClaw враховує ці поля перевизначення лише для довірених викликачів.
+- Для належних Plugin fallback-запусків оператори мають увімкнути `plugins.entries..subagent.allowModelOverride: true`.
+- Використовуйте `plugins.entries..subagent.allowedModels`, щоб обмежити довірені Plugin конкретними канонічними цілями `provider/model`, або `"*"`, щоб явно дозволити будь-яку ціль.
+- Запуски субагентів недовірених Plugin усе ще працюють, але запити на перевизначення відхиляються замість тихого fallback.
+- Сеанси субагентів, створені Plugin, позначаються ідентифікатором Plugin, що їх створив. Fallback `api.runtime.subagent.deleteSession(...)` може видаляти лише ці належні йому сеанси; довільне видалення сеансів усе ще потребує admin-scoped запиту Gateway.
-Для web search plugins можуть споживати спільний runtime helper замість
-звернення до agent tool wiring:
+Для вебпошуку Plugin можуть використовувати спільний допоміжний засіб runtime замість
+звернення до зв’язування інструментів агента:
```ts
const providers = api.runtime.webSearch.listProviders({
@@ -530,14 +548,14 @@ const result = await api.runtime.webSearch.search({
});
```
-Plugins також можуть реєструвати web-search providers через
+Plugin також можуть реєструвати постачальників вебпошуку через
`api.registerWebSearchProvider(...)`.
Примітки:
-- Залишайте provider selection, credential resolution і shared request semantics у core.
-- Використовуйте web-search providers для vendor-specific search transports.
-- `api.runtime.webSearch.*` є бажаною спільною поверхнею для feature/channel plugins, яким потрібна search behavior без залежності від agent tool wrapper.
+- Тримайте вибір постачальника, розв’язання облікових даних і спільну семантику запитів у ядрі.
+- Використовуйте постачальників вебпошуку для специфічних для вендора транспортів пошуку.
+- `api.runtime.webSearch.*` є бажаною спільною поверхнею для Plugin функцій/каналів, яким потрібна поведінка пошуку без залежності від wrapper інструмента агента.
### `api.runtime.imageGeneration`
@@ -552,12 +570,12 @@ const providers = api.runtime.imageGeneration.listProviders({
});
```
-- `generate(...)`: згенерувати зображення за допомогою налаштованого image-generation provider chain.
-- `listProviders(...)`: перелічити доступні image-generation providers та їхні capabilities.
+- `generate(...)`: генерує зображення за допомогою налаштованого ланцюжка постачальників image-generation.
+- `listProviders(...)`: перелічує доступних постачальників image-generation та їхні можливості.
## HTTP-маршрути Gateway
-Plugins можуть надавати HTTP endpoints через `api.registerHttpRoute(...)`.
+Plugin можуть відкривати HTTP-кінцеві точки за допомогою `api.registerHttpRoute(...)`.
```ts
api.registerHttpRoute({
@@ -572,212 +590,207 @@ api.registerHttpRoute({
});
```
-Поля route:
+Поля маршруту:
-- `path`: route path під HTTP server Gateway.
-- `auth`: обов’язкове. Використовуйте `"gateway"`, щоб вимагати звичайний gateway auth, або `"plugin"` для plugin-managed auth/webhook verification.
-- `match`: необов’язкове. `"exact"` (за замовчуванням) або `"prefix"`.
-- `replaceExisting`: необов’язкове. Дозволяє тому самому plugin замінити власну наявну route registration.
-- `handler`: поверніть `true`, коли route обробив request.
+- `path`: шлях маршруту під HTTP-сервером gateway.
+- `auth`: обов’язкове. Використовуйте `"gateway"`, щоб вимагати звичайну автентифікацію gateway, або `"plugin"` для автентифікації/перевірки webhook, керованої Plugin.
+- `match`: необов’язкове. `"exact"` (типово) або `"prefix"`.
+- `replaceExisting`: необов’язкове. Дає тому самому Plugin змогу замінити власну наявну реєстрацію маршруту.
+- `handler`: повертає `true`, коли маршрут обробив запит.
Примітки:
-- `api.registerHttpHandler(...)` було вилучено й спричинятиме помилку завантаження Plugin. Натомість використовуйте `api.registerHttpRoute(...)`.
+- `api.registerHttpHandler(...)` вилучено, і це спричинить помилку завантаження Plugin. Натомість використовуйте `api.registerHttpRoute(...)`.
- Маршрути Plugin мають явно оголошувати `auth`.
-- Конфлікти з точним `path + match` відхиляються, якщо не вказано `replaceExisting: true`, і один плагін не може замінити маршрут іншого плагіна.
-- Маршрути, що перекриваються, з різними рівнями `auth` відхиляються. Тримайте ланцюжки резервного переходу `exact`/`prefix` лише на одному рівні auth.
-- Маршрути `auth: "plugin"` **не** отримують автоматично операторські runtime-області. Вони призначені для керованих плагіном webhooks/перевірки підпису, а не для привілейованих викликів допоміжних функцій Gateway.
-- Маршрути `auth: "gateway"` виконуються в межах runtime-області запиту Gateway, але ця область навмисно консервативна:
- - автентифікація bearer за спільним секретом (`gateway.auth.mode = "token"` / `"password"`) утримує runtime-області маршрутів Plugin закріпленими за `operator.write`, навіть якщо викликач надсилає `x-openclaw-scopes`
- - довірені HTTP-режими з ідентичністю (наприклад, `trusted-proxy` або `gateway.auth.mode = "none"` на приватному ingress) враховують `x-openclaw-scopes` лише тоді, коли заголовок явно присутній
- - якщо `x-openclaw-scopes` відсутній у таких запитах до маршруту Plugin з ідентичністю, runtime-область повертається до `operator.write`
-- Практичне правило: не вважайте маршрут Plugin із gateway-auth неявною адміністративною поверхнею. Якщо вашому маршруту потрібна поведінка лише для адміністраторів, вимагайте режим auth з ідентичністю та документуйте явний контракт заголовка `x-openclaw-scopes`.
+- Точні конфлікти `path + match` відхиляються, якщо не вказано `replaceExisting: true`, і один Plugin не може замінити маршрут іншого Plugin.
+- Перекривні маршрути з різними рівнями `auth` відхиляються. Тримайте ланцюжки переходу `exact`/`prefix` лише на одному рівні auth.
+- Маршрути `auth: "plugin"` **не** отримують автоматично операторські runtime scopes. Вони призначені для керованих Plugin вебхуків/перевірки підпису, а не для привілейованих допоміжних викликів Gateway.
+- Маршрути `auth: "gateway"` виконуються всередині runtime scope запиту Gateway, але цей scope навмисно консервативний:
+ - shared-secret bearer auth (`gateway.auth.mode = "token"` / `"password"`) утримує runtime scopes маршрутів Plugin зафіксованими на `operator.write`, навіть якщо викликач надсилає `x-openclaw-scopes`
+ - довірені HTTP-режими з ідентифікацією (наприклад `trusted-proxy` або `gateway.auth.mode = "none"` на приватному ingress) враховують `x-openclaw-scopes` лише тоді, коли заголовок явно присутній
+ - якщо `x-openclaw-scopes` відсутній у таких запитах до маршрутів Plugin з ідентифікацією, runtime scope повертається до `operator.write`
+- Практичне правило: не припускайте, що gateway-auth маршрут Plugin є неявною адміністративною поверхнею. Якщо ваш маршрут потребує поведінки лише для адміністраторів, вимагайте режим auth з ідентифікацією та задокументуйте явний контракт заголовка `x-openclaw-scopes`.
## Шляхи імпорту Plugin SDK
-Використовуйте вузькі підшляхи SDK замість монолітного кореневого barrel `openclaw/plugin-sdk` під час створення нових плагінів. Основні підшляхи:
+Використовуйте вузькі підшляхи SDK замість монолітного кореневого barrel `openclaw/plugin-sdk` під час створення нових Plugin. Основні підшляхи:
| Підшлях | Призначення |
| ----------------------------------- | -------------------------------------------------- |
| `openclaw/plugin-sdk/plugin-entry` | Примітиви реєстрації Plugin |
-| `openclaw/plugin-sdk/channel-core` | Допоміжні засоби для входу/побудови каналу |
+| `openclaw/plugin-sdk/channel-core` | Допоміжні засоби входу/збірки каналу |
| `openclaw/plugin-sdk/core` | Загальні спільні допоміжні засоби та umbrella-контракт |
| `openclaw/plugin-sdk/config-schema` | Коренева Zod-схема `openclaw.json` (`OpenClawSchema`) |
-Канальні плагіни вибирають із сімейства вузьких стиків — `channel-setup`,
+Канальні Plugin вибирають із родини вузьких швів — `channel-setup`,
`setup-runtime`, `setup-adapter-runtime`, `setup-tools`, `channel-pairing`,
`channel-contract`, `channel-feedback`, `channel-inbound`, `channel-lifecycle`,
`channel-reply-pipeline`, `command-auth`, `secret-input`, `webhook-ingress`,
-`channel-targets` і `channel-actions`. Поведінку схвалення слід консолідувати
-на одному контракті `approvalCapability`, а не змішувати між непов’язаними
-полями плагіна. Див. [Канальні плагіни](/uk/plugins/sdk-channel-plugins).
+`channel-targets` і `channel-actions`. Поведінка затвердження має консолідуватися
+на одному контракті `approvalCapability`, а не змішуватися між непов’язаними
+полями Plugin. Див. [Канальні Plugin](/uk/plugins/sdk-channel-plugins).
-Runtime- і конфігураційні допоміжні засоби розміщені у відповідних сфокусованих підшляхах
+Runtime- і config-допоміжні засоби містяться у відповідних сфокусованих підшляхах
`*-runtime` (`approval-runtime`, `agent-runtime`, `lazy-runtime`, `directory-runtime`,
`text-runtime`, `runtime-store`, `system-event-runtime`, `heartbeat-runtime`,
`channel-activity-runtime` тощо). Надавайте перевагу `config-types`,
`plugin-config-runtime`, `runtime-config-snapshot` і `config-mutation`
-замість широкого сумісного barrel `config-runtime`.
+замість широкого compatibility barrel `config-runtime`.
`openclaw/plugin-sdk/channel-runtime`, `openclaw/plugin-sdk/config-runtime`
-і `openclaw/plugin-sdk/infra-runtime` є застарілими сумісними shim для
-старіших плагінів. Новий код має імпортувати натомість вужчі загальні примітиви.
+і `openclaw/plugin-sdk/infra-runtime` є застарілими compatibility shims для
+старіших Plugin. Новий код має імпортувати натомість вужчі загальні примітиви.
-Внутрішні точки входу репозиторію (для кореня кожного вбудованого пакета плагіна):
+Внутрішні точки входу репозиторію (для кореня кожного вбудованого пакета Plugin):
-- `index.js` — точка входу вбудованого плагіна
+- `index.js` — точка входу вбудованого Plugin
- `api.js` — barrel допоміжних засобів/типів
- `runtime-api.js` — barrel лише для runtime
-- `setup-entry.js` — точка входу setup-плагіна
+- `setup-entry.js` — точка входу setup Plugin
-Зовнішні плагіни мають імпортувати лише підшляхи `openclaw/plugin-sdk/*`. Ніколи
-не імпортуйте `src/*` іншого пакета плагіна з core або з іншого плагіна.
-Точки входу, завантажені через facade, надають перевагу активному runtime-знімку
-конфігурації, коли він існує, а потім повертаються до розв’язного файлу
-конфігурації на диску.
+Зовнішні Plugin мають імпортувати лише підшляхи `openclaw/plugin-sdk/*`. Ніколи
+не імпортуйте `src/*` іншого пакета Plugin з core або з іншого Plugin.
+Точки входу, завантажені через facade, надають перевагу активному runtime config snapshot, коли він
+існує, а потім повертаються до розв’язаного config-файла на диску.
-Підшляхи для конкретних capability, як-от `image-generation`, `media-understanding`
-і `speech`, існують тому, що вбудовані плагіни використовують їх сьогодні. Вони
-не є автоматично довгостроково замороженими зовнішніми контрактами — перевіряйте
-відповідну довідкову сторінку SDK, коли покладаєтеся на них.
+Підшляхи для конкретних capabilities, такі як `image-generation`, `media-understanding`
+і `speech`, існують, бо вбудовані Plugin використовують їх сьогодні. Вони не є
+автоматично довгостроково замороженими зовнішніми контрактами — перевіряйте відповідну
+довідкову сторінку SDK, коли покладаєтеся на них.
## Схеми інструментів повідомлень
-Плагіни мають володіти канально-специфічними внесками до схеми
-`describeMessageTool(...)` для непризначених для повідомлень примітивів, як-от
-реакції, прочитання й опитування. Спільне подання надсилання має використовувати
-загальний контракт `MessagePresentation` замість provider-native полів кнопок,
-компонентів, блоків або карток. Див. [Подання повідомлень](/uk/plugins/message-presentation)
-щодо контракту, правил fallback, мапінгу провайдерів і checklist автора плагіна.
+Plugin мають володіти канально-специфічними внесками схеми `describeMessageTool(...)`
+для немеседжевих примітивів, як-от реакції, прочитання та опитування.
+Спільне подання надсилання має використовувати загальний контракт `MessagePresentation`
+замість provider-native полів кнопок, компонентів, блоків або карток.
+Див. [Подання повідомлень](/uk/plugins/message-presentation) щодо контракту,
+правил fallback, зіставлення провайдерів і контрольного списку автора Plugin.
-Плагіни з можливістю надсилання оголошують, що вони можуть відтворювати, через можливості повідомлень:
+Plugin із можливістю надсилання оголошують, що вони можуть рендерити, через capabilities повідомлень:
- `presentation` для семантичних блоків подання (`text`, `context`, `divider`, `buttons`, `select`)
- `delivery-pin` для запитів закріпленої доставки
-Core вирішує, чи відтворювати подання нативно, чи деградувати його до тексту.
-Не відкривайте provider-native UI escape hatch із загального інструмента повідомлень.
-Застарілі допоміжні засоби SDK для legacy нативних схем залишаються експортованими
-для наявних сторонніх плагінів, але нові плагіни не мають їх використовувати.
+Core вирішує, чи рендерити подання нативно, чи деградувати його до тексту.
+Не відкривайте provider-native UI escape hatches із загального інструмента повідомлень.
+Застарілі допоміжні засоби SDK для legacy native схем лишаються експортованими для наявних
+сторонніх Plugin, але нові Plugin не повинні їх використовувати.
## Розв’язання цілей каналу
-Канальні плагіни мають володіти канально-специфічною семантикою цілей. Тримайте
-спільний outbound host загальним і використовуйте поверхню messaging-адаптера
-для правил провайдера:
+Канальні Plugin мають володіти канально-специфічною семантикою цілей. Тримайте спільний
+outbound host загальним і використовуйте поверхню messaging adapter для правил провайдера:
-- `messaging.inferTargetChatType({ to })` вирішує, чи нормалізовану ціль
- слід трактувати як `direct`, `group` або `channel` перед пошуком у каталозі.
-- `messaging.targetResolver.looksLikeId(raw, normalized)` повідомляє core, чи
- має вхідне значення одразу перейти до id-like розв’язання замість пошуку в каталозі.
-- `messaging.targetResolver.resolveTarget(...)` є fallback плагіна, коли
- core потребує остаточного розв’язання, яким володіє провайдер, після нормалізації
- або після промаху в каталозі.
-- `messaging.resolveOutboundSessionRoute(...)` володіє provider-specific побудовою
- маршруту сесії після розв’язання цілі.
+- `messaging.inferTargetChatType({ to })` вирішує, чи слід вважати нормалізовану ціль
+ `direct`, `group` або `channel` перед пошуком у каталозі.
+- `messaging.targetResolver.looksLikeId(raw, normalized)` повідомляє core, чи має
+ вхідне значення одразу переходити до розв’язання, схожого на id, замість пошуку в каталозі.
+- `messaging.targetResolver.resolveTarget(...)` є fallback Plugin, коли
+ core потребує остаточного розв’язання, яким володіє провайдер, після нормалізації або після
+ промаху каталогу.
+- `messaging.resolveOutboundSessionRoute(...)` володіє provider-specific побудовою маршруту
+ сесії після розв’язання цілі.
Рекомендований поділ:
-- Використовуйте `inferTargetChatType` для категорійних рішень, які мають
- відбутися перед пошуком peers/groups.
-- Використовуйте `looksLikeId` для перевірок "трактувати це як явний/нативний id цілі".
-- Використовуйте `resolveTarget` для provider-specific fallback нормалізації, а не
- для широкого пошуку в каталозі.
-- Тримайте provider-native id, як-от chat ids, thread ids, JIDs, handles і room
- ids, усередині значень `target` або provider-specific params, а не в загальних
- полях SDK.
+- Використовуйте `inferTargetChatType` для рішень щодо категорії, які мають відбуватися перед
+ пошуком peers/groups.
+- Використовуйте `looksLikeId` для перевірок "вважати це явним/native target id".
+- Використовуйте `resolveTarget` для provider-specific fallback нормалізації, а не для
+ широкого пошуку в каталозі.
+- Тримайте provider-native ids, як-от chat ids, thread ids, JIDs, handles і room
+ ids, усередині значень `target` або provider-specific params, а не в загальних полях SDK.
-## Каталоги на основі конфігурації
+## Каталоги на основі config
-Плагіни, які виводять записи каталогу з конфігурації, мають тримати цю логіку
-в плагіні й повторно використовувати спільні допоміжні засоби з
+Plugin, які виводять записи каталогу з config, мають тримати цю логіку в
+Plugin і повторно використовувати спільні допоміжні засоби з
`openclaw/plugin-sdk/directory-runtime`.
-Використовуйте це, коли каналу потрібні peers/groups на основі конфігурації, як-от:
+Використовуйте це, коли каналу потрібні peers/groups на основі config, наприклад:
-- DM peers на основі allowlist
-- налаштовані мапи channel/group
-- account-scoped статичні fallback каталогу
+- allowlist-driven DM peers
+- налаштовані карти channel/group
+- account-scoped статичні fallback записи каталогу
Спільні допоміжні засоби в `directory-runtime` обробляють лише загальні операції:
-- фільтрацію запитів
+- фільтрація запитів
- застосування ліміту
- допоміжні засоби дедуплікації/нормалізації
-- побудову `ChannelDirectoryEntry[]`
+- побудова `ChannelDirectoryEntry[]`
-Канально-специфічна інспекція облікового запису та нормалізація id мають
-залишатися в реалізації плагіна.
+Канально-специфічна перевірка account і нормалізація id мають залишатися в
+реалізації Plugin.
## Каталоги провайдерів
-Плагіни провайдерів можуть визначати каталоги моделей для inference за допомогою
+Provider Plugin можуть визначати каталоги моделей для inference за допомогою
`registerProvider({ catalog: { run(...) { ... } } })`.
`catalog.run(...)` повертає ту саму форму, яку OpenClaw записує в
`models.providers`:
- `{ provider }` для одного запису провайдера
-- `{ providers }` для кількох записів провайдерів
+- `{ providers }` для кількох записів провайдера
-Використовуйте `catalog`, коли плагін володіє provider-specific id моделей,
-типовими значеннями базового URL або auth-gated метаданими моделей.
+Використовуйте `catalog`, коли Plugin володіє provider-specific model ids, типовими значеннями base URL
+або auth-gated metadata моделей.
-`catalog.order` керує тим, коли каталог плагіна зливається відносно вбудованих
-неявних провайдерів OpenClaw:
+`catalog.order` керує тим, коли каталог Plugin зливається відносно
+вбудованих implicit providers OpenClaw:
-- `simple`: звичайні провайдери, керовані API-ключем або env
-- `profile`: провайдери, що з’являються, коли існують профілі auth
-- `paired`: провайдери, що синтезують кілька пов’язаних записів провайдерів
-- `late`: останній прохід, після інших неявних провайдерів
+- `simple`: прості провайдери, керовані API-key або env
+- `profile`: провайдери, які з’являються, коли існують auth profiles
+- `paired`: провайдери, які синтезують кілька пов’язаних записів провайдерів
+- `late`: останній прохід, після інших implicit providers
-Пізніші провайдери перемагають у разі колізії ключів, тож плагіни можуть
-навмисно перевизначати вбудований запис провайдера з тим самим provider id.
+Пізніші провайдери перемагають у разі колізії ключів, тож Plugin можуть навмисно перевизначити
+вбудований запис провайдера з тим самим provider id.
Сумісність:
-- `discovery` досі працює як legacy alias
+- `discovery` все ще працює як legacy alias
- якщо зареєстровано і `catalog`, і `discovery`, OpenClaw використовує `catalog`
-## Read-only інспекція каналу
+## Read-only перевірка каналів
-Якщо ваш плагін реєструє канал, надавайте перевагу реалізації
-`plugin.config.inspectAccount(cfg, accountId)` разом із `resolveAccount(...)`.
+Якщо ваш Plugin реєструє канал, надавайте перевагу реалізації
+`plugin.config.inspectAccount(cfg, accountId)` поряд із `resolveAccount(...)`.
Чому:
-- `resolveAccount(...)` — це runtime-шлях. Йому дозволено припускати, що облікові
- дані повністю матеріалізовані, і він може швидко завершитися з помилкою, коли
- потрібні secrets відсутні.
-- Read-only командні шляхи, як-от `openclaw status`, `openclaw status --all`,
- `openclaw channels status`, `openclaw channels resolve`, а також doctor/config
- repair flows, не повинні матеріалізувати runtime-облікові дані лише для опису
- конфігурації.
+- `resolveAccount(...)` — це runtime шлях. Йому дозволено припускати, що credentials
+ повністю матеріалізовані, і він може швидко падати, коли бракує required secrets.
+- Read-only командні шляхи, такі як `openclaw status`, `openclaw status --all`,
+ `openclaw channels status`, `openclaw channels resolve`, а також потоки doctor/config
+ repair, не повинні матеріалізувати runtime credentials лише для
+ опису конфігурації.
Рекомендована поведінка `inspectAccount(...)`:
-- Повертайте лише описовий стан облікового запису.
+- Повертайте лише описовий стан account.
- Зберігайте `enabled` і `configured`.
-- Додавайте поля джерела/статусу облікових даних, коли доречно, як-от:
+- Додавайте поля джерела/статусу credentials, коли доречно, наприклад:
- `tokenSource`, `tokenStatus`
- `botTokenSource`, `botTokenStatus`
- `appTokenSource`, `appTokenStatus`
- `signingSecretSource`, `signingSecretStatus`
-- Вам не потрібно повертати сирі значення токенів лише для повідомлення про
- read-only доступність. Повернути `tokenStatus: "available"` (і відповідне
- поле джерела) достатньо для status-style команд.
-- Використовуйте `configured_unavailable`, коли облікові дані налаштовані через SecretRef,
- але недоступні в поточному командному шляху.
+- Вам не потрібно повертати сирі значення токенів лише для повідомлення read-only
+ доступності. Повернення `tokenStatus: "available"` (і відповідного поля source)
+ достатньо для status-style команд.
+- Використовуйте `configured_unavailable`, коли credential налаштовано через SecretRef, але
+ він недоступний у поточному командному шляху.
-Це дає read-only командам змогу повідомляти "налаштовано, але недоступно в цьому
-командному шляху" замість аварійного завершення або хибного повідомлення, що
-обліковий запис не налаштований.
+Це дає змогу read-only командам повідомляти "налаштовано, але недоступно в цьому командному
+шляху" замість аварійного завершення або помилкового повідомлення, що account не налаштовано.
## Пакети пакетів
-Каталог плагіна може містити `package.json` з `openclaw.extensions`:
+Каталог Plugin може містити `package.json` з `openclaw.extensions`:
```json
{
@@ -789,60 +802,68 @@ Core вирішує, чи відтворювати подання нативно
}
```
-Кожен запис стає плагіном. Якщо pack перелічує кілька extensions, id плагіна
+Кожен запис стає Plugin. Якщо pack містить кілька extensions, id Plugin
стає `name/`.
-Якщо ваш плагін імпортує npm deps, установіть їх у цьому каталозі, щоб
+Якщо ваш Plugin імпортує npm deps, встановіть їх у цьому каталозі, щоб
`node_modules` був доступний (`npm install` / `pnpm install`).
-Захисне обмеження безпеки: кожен запис `openclaw.extensions` має залишатися
-всередині каталогу плагіна після розв’язання symlink. Записи, що виходять за
-межі каталогу пакета, відхиляються.
+Security guardrail: кожен запис `openclaw.extensions` має залишатися всередині каталогу Plugin
+після розв’язання symlink. Записи, що виходять за межі каталогу пакета,
+відхиляються.
-Примітка щодо безпеки: `openclaw plugins install` установлює залежності плагіна
-через project-local `npm install --omit=dev --ignore-scripts` (без lifecycle scripts,
+Security note: `openclaw plugins install` встановлює залежності Plugin за допомогою
+project-local `npm install --omit=dev --ignore-scripts` (без lifecycle scripts,
без dev dependencies у runtime), ігноруючи успадковані глобальні налаштування npm install.
-Тримайте дерева залежностей плагіна "pure JS/TS" і уникайте пакетів, які потребують
+Тримайте дерева залежностей Plugin "pure JS/TS" і уникайте пакетів, які потребують
`postinstall` builds.
Опційно: `openclaw.setupEntry` може вказувати на легкий setup-only модуль.
-Коли OpenClaw потребує setup-поверхонь для вимкненого канального плагіна або
-коли канальний плагін увімкнений, але ще не налаштований, він завантажує `setupEntry`
-замість повної точки входу плагіна. Це полегшує startup і setup,
-коли ваша основна точка входу плагіна також під’єднує інструменти, hooks або інший
-runtime-only код.
+Коли OpenClaw потрібні setup surfaces для вимкненого канального Plugin або
+коли канальний Plugin увімкнений, але ще не налаштований, він завантажує `setupEntry`
+замість повної точки входу Plugin. Це робить запуск і setup легшими,
+коли ваша основна точка входу Plugin також під’єднує tools, hooks або інший runtime-only
+код.
Опційно: `openclaw.startup.deferConfiguredChannelFullLoadUntilAfterListen`
-може перевести канальний плагін на той самий шлях `setupEntry` під час pre-listen
-startup-фази gateway, навіть коли канал уже налаштований.
+може підключити канальний Plugin до того самого шляху `setupEntry` під час pre-listen startup phase Gateway,
+навіть коли канал уже налаштований.
-Використовуйте це лише тоді, коли `setupEntry` повністю покриває startup-поверхню,
-яка має існувати до того, як gateway почне слухати. На практиці це означає, що
-setup entry має зареєструвати кожну capability, якою володіє канал і від якої
-залежить startup, як-от:
+Використовуйте це лише тоді, коли `setupEntry` повністю покриває startup surface, яка має існувати
+до того, як Gateway почне слухати. На практиці це означає, що setup entry
+має зареєструвати кожну capability, якою володіє канал і від якої залежить startup, наприклад:
- сама реєстрація каналу
-- будь-які HTTP-маршрути, що мають бути доступні до того, як gateway почне слухати
-- будь-які gateway methods, tools або services, що мають існувати в цьому самому вікні
+- будь-які HTTP-маршрути, які мають бути доступні до того, як Gateway почне слухати
+- будь-які методи, tools або services Gateway, які мають існувати протягом того самого вікна
-Якщо ваша повна точка входу досі володіє будь-якою потрібною startup capability,
-не вмикайте цей прапорець. Залиште плагін на типовій поведінці й дозвольте
-OpenClaw завантажити повну точку входу під час startup.
+Якщо ваша повна точка входу все ще володіє будь-якою required startup capability, не вмикайте
+цей flag. Залиште Plugin на типовій поведінці та дозвольте OpenClaw завантажувати
+повну точку входу під час startup.
-Вбудовані канали також можуть публікувати setup-only допоміжні засоби поверхні
-контракту, до яких core може звертатися до завантаження повного runtime каналу.
-Поточна поверхня promotion для setup:
+Вбудовані канали також можуть публікувати setup-only contract-surface допоміжні засоби, з якими core
+може звірятися до завантаження повного runtime каналу. Поточна setup
+promotion surface така:
- `singleAccountKeysToMove`
- `namedAccountPromotionKeys`
- `resolveSingleAccountPromotionTarget(...)`
-Core використовує цю поверхню, коли йому потрібно просунути застарілу конфігурацію каналу з одним обліковим записом до `channels..accounts.*` без завантаження повного запису Plugin.
-Matrix — поточний вбудований приклад: він переносить лише ключі автентифікації/початкового налаштування до іменованого просунутого облікового запису, коли іменовані облікові записи вже існують, і може зберегти налаштований неканонічний ключ облікового запису за замовчуванням замість того, щоб завжди створювати `accounts.default`.
+Ядро використовує цю поверхню, коли потрібно підвищити застарілу конфігурацію каналу з одним обліковим записом до
+`channels..accounts.*` без завантаження повного запису Plugin.
+Matrix є поточним вбудованим прикладом: він переносить лише ключі автентифікації/початкового завантаження до
+іменованого підвищеного облікового запису, коли іменовані облікові записи вже існують, і може зберегти
+налаштований неканонічний ключ облікового запису за замовчуванням замість того, щоб завжди створювати
+`accounts.default`.
-Ці адаптери патчів налаштування зберігають виявлення вбудованої контрактної поверхні лінивим. Час імпорту залишається легким; поверхня просування завантажується лише під час першого використання, замість повторного входу в запуск вбудованого каналу під час імпорту модуля.
+Ці адаптери патчів налаштування зберігають ліниве виявлення вбудованої контрактної поверхні. Час
+імпорту залишається малим; поверхня підвищення завантажується лише під час першого використання, а не
+повторно входить у запуск вбудованого каналу під час імпорту модуля.
-Коли ці поверхні запуску містять методи Gateway RPC, тримайте їх на префіксі, специфічному для Plugin. Простори імен адміністрування Core (`config.*`, `exec.approvals.*`, `wizard.*`, `update.*`) залишаються зарезервованими й завжди розв’язуються до `operator.admin`, навіть якщо Plugin запитує вужчу область дії.
+Коли ці стартові поверхні містять методи RPC Gateway, тримайте їх на
+префіксі, специфічному для Plugin. Простори імен адміністратора ядра (`config.*`,
+`exec.approvals.*`, `wizard.*`, `update.*`) залишаються зарезервованими й завжди зіставляються
+з `operator.admin`, навіть якщо Plugin запитує вужчу область.
Приклад:
@@ -861,7 +882,8 @@ Matrix — поточний вбудований приклад: він пере
### Метадані каталогу каналів
-Plugins каналів можуть оголошувати метадані налаштування/виявлення через `openclaw.channel` і підказки встановлення через `openclaw.install`. Це зберігає основний каталог без даних.
+Plugin каналів можуть рекламувати метадані налаштування/виявлення через `openclaw.channel` і
+підказки встановлення через `openclaw.install`. Це залишає каталог ядра без даних.
Приклад:
@@ -891,39 +913,67 @@ Plugins каналів можуть оголошувати метадані на
Корисні поля `openclaw.channel` поза мінімальним прикладом:
-- `detailLabel`: вторинна мітка для багатших поверхонь каталогу/статусу
+- `detailLabel`: вторинна мітка для багатших поверхонь каталогу/стану
- `docsLabel`: перевизначити текст посилання для посилання на документацію
- `preferOver`: ідентифікатори Plugin/каналів із нижчим пріоритетом, які цей запис каталогу має випереджати
- `selectionDocsPrefix`, `selectionDocsOmitLabel`, `selectionExtras`: елементи керування текстом поверхні вибору
-- `markdownCapable`: позначає канал як здатний до markdown для рішень щодо вихідного форматування
+- `markdownCapable`: позначає канал як здатний працювати з Markdown для рішень щодо вихідного форматування
- `exposure.configured`: приховати канал із поверхонь списку налаштованих каналів, коли встановлено `false`
- `exposure.setup`: приховати канал з інтерактивних засобів вибору налаштування/конфігурації, коли встановлено `false`
- `exposure.docs`: позначити канал як внутрішній/приватний для поверхонь навігації документації
-- `showConfigured` / `showInSetup`: застарілі псевдоніми, які все ще приймаються для сумісності; надавайте перевагу `exposure`
-- `quickstartAllowFrom`: підключити канал до стандартного потоку швидкого старту `allowFrom`
-- `forceAccountBinding`: вимагати явного прив’язування облікового запису, навіть коли існує лише один обліковий запис
-- `preferSessionLookupForAnnounceTarget`: надавати перевагу пошуку сеансу під час розв’язання цілей оголошення
+- `showConfigured` / `showInSetup`: застарілі псевдоніми, які досі приймаються для сумісності; віддавайте перевагу `exposure`
+- `quickstartAllowFrom`: увімкнути канал у стандартний потік швидкого старту `allowFrom`
+- `forceAccountBinding`: вимагати явної прив’язки облікового запису, навіть коли існує лише один обліковий запис
+- `preferSessionLookupForAnnounceTarget`: віддавати перевагу пошуку сеансу під час визначення цілей оголошення
-OpenClaw також може об’єднувати **зовнішні каталоги каналів** (наприклад, експорт реєстру MPM). Помістіть JSON-файл в одне з таких місць:
+OpenClaw також може об’єднувати **зовнішні каталоги каналів** (наприклад, експорт реєстру MPM).
+Розмістіть JSON-файл в одному з таких місць:
- `~/.openclaw/mpm/plugins.json`
- `~/.openclaw/mpm/catalog.json`
- `~/.openclaw/plugins/catalog.json`
-Або вкажіть `OPENCLAW_PLUGIN_CATALOG_PATHS` (або `OPENCLAW_MPM_CATALOG_PATHS`) на один чи кілька JSON-файлів (розділених комами/крапками з комою/`PATH`). Кожен файл має містити `{ "entries": [ { "name": "@scope/pkg", "openclaw": { "channel": {...}, "install": {...} } } ] }`. Парсер також приймає `"packages"` або `"plugins"` як застарілі псевдоніми для ключа `"entries"`.
+Або спрямуйте `OPENCLAW_PLUGIN_CATALOG_PATHS` (або `OPENCLAW_MPM_CATALOG_PATHS`) на
+один чи кілька JSON-файлів (розділених комою/крапкою з комою/`PATH`). Кожен файл має
+містити `{ "entries": [ { "name": "@scope/pkg", "openclaw": { "channel": {...}, "install": {...} } } ] }`. Парсер також приймає `"packages"` або `"plugins"` як застарілі псевдоніми для ключа `"entries"`.
-Згенеровані записи каталогу каналів і записи каталогу встановлення провайдерів надають нормалізовані факти джерела встановлення поруч із сирим блоком `openclaw.install`. Нормалізовані факти визначають, чи є специфікація npm точною версією або плаваючим селектором, чи присутні очікувані метадані цілісності, і чи також доступний локальний шлях джерела. Коли відома ідентичність каталогу/пакета, нормалізовані факти попереджають, якщо розібране ім’я npm-пакета відхиляється від цієї ідентичності. Вони також попереджають, коли `defaultChoice` недійсний або вказує на недоступне джерело, а також коли метадані цілісності npm присутні без чинного джерела npm. Споживачі мають розглядати `installSource` як додаткове необов’язкове поле, щоб записи, створені вручну, і прокладки каталогів не мусили його синтезувати.
-Це дає змогу онбордингу та діагностиці пояснювати стан площини джерел без імпорту середовища виконання Plugin.
+Згенеровані записи каталогу каналів і записи каталогу встановлення провайдерів надають
+нормалізовані факти про джерело встановлення поруч із сирим блоком `openclaw.install`. Ці
+нормалізовані факти визначають, чи є npm-специфікація точною версією або плаваючим
+селектором, чи присутні очікувані метадані цілісності, і чи також доступний локальний
+шлях джерела. Коли ідентичність каталогу/пакета відома, нормалізовані факти попереджають,
+якщо розібране ім’я npm-пакета відхиляється від цієї ідентичності.
+Вони також попереджають, коли `defaultChoice` є недійсним або вказує на джерело, яке
+недоступне, і коли метадані цілісності npm присутні без дійсного джерела npm. Споживачі мають
+розглядати `installSource` як додаткове необов’язкове поле, щоб
+створені вручну записи та прокладки каталогу не мусили його синтезувати.
+Це дає onboarding і діагностиці змогу пояснювати стан площини джерел без
+імпортування runtime Plugin.
-Офіційні зовнішні записи npm мають надавати перевагу точному `npmSpec` разом з `expectedIntegrity`. Голі імена пакетів і dist-tags усе ще працюють для сумісності, але вони показують попередження площини джерел, щоб каталог міг рухатися до закріплених встановлень із перевіркою цілісності без поломки наявних plugins.
-Коли онбординг встановлює з локального шляху каталогу, він записує керований запис індексу Plugin з `source: "path"` і відносним до робочого простору `sourcePath`, коли це можливо. Абсолютний операційний шлях завантаження залишається в `plugins.load.paths`; запис встановлення уникає дублювання локальних шляхів робочої станції в довготривалу конфігурацію. Це зберігає локальні встановлення для розробки видимими для діагностики площини джерел без додавання другої поверхні розкриття сирого шляху файлової системи. Збережений індекс Plugin `plugins/installs.json` є джерелом істини встановлення й може оновлюватися без завантаження модулів середовища виконання Plugin.
-Його мапа `installRecords` є довговічною навіть тоді, коли маніфест Plugin відсутній або недійсний; його масив `plugins` є відновлюваним поданням маніфесту/кешу.
+Офіційні зовнішні записи npm мають надавати перевагу точному `npmSpec` плюс
+`expectedIntegrity`. Голі імена пакетів і dist-tags досі працюють для
+сумісності, але вони показують попередження площини джерел, щоб каталог міг рухатися
+до закріплених встановлень із перевіркою цілісності, не ламаючи наявні plugins.
+Коли onboarding встановлює з локального шляху каталогу, він записує керований запис індексу
+Plugin із `source: "path"` і відносним до workspace
+`sourcePath`, коли це можливо. Абсолютний операційний шлях завантаження залишається в
+`plugins.load.paths`; запис встановлення уникає дублювання локальних шляхів робочої станції
+в довготривалу конфігурацію. Це робить локальні встановлення для розробки видимими для
+діагностики площини джерел без додавання другої сирої поверхні розкриття шляхів файлової системи.
+Збережений індекс Plugin `plugins/installs.json` є джерелом істини для встановлень і може
+оновлюватися без завантаження runtime-модулів Plugin.
+Його мапа `installRecords` є довговічною, навіть коли маніфест Plugin відсутній або
+недійсний; його масив `plugins` є відновлюваним поданням маніфесту.
-## Plugins рушія контексту
+## Plugins рушіїв контексту
-Plugins рушія контексту відповідають за оркестрацію контексту сеансу для приймання, складання та Compaction. Зареєструйте їх зі свого Plugin через `api.registerContextEngine(id, factory)`, а потім виберіть активний рушій за допомогою `plugins.slots.contextEngine`.
+Plugins рушіїв контексту володіють оркестрацією контексту сеансу для приймання, складання
+і Compaction. Зареєструйте їх зі свого Plugin за допомогою
+`api.registerContextEngine(id, factory)`, а потім виберіть активний рушій через
+`plugins.slots.contextEngine`.
-Використовуйте це, коли вашому Plugin потрібно замінити або розширити стандартний конвеєр контексту, а не просто додати пошук у пам’яті чи хуки.
+Використовуйте це, коли вашому Plugin потрібно замінити або розширити типовий
+конвеєр контексту, а не просто додати пошук пам’яті чи hooks.
```ts
import { buildMemorySystemPromptAddition } from "openclaw/plugin-sdk/core";
@@ -951,9 +1001,11 @@ export default function (api) {
}
```
-Фабрика `ctx` надає необов’язкові значення `config`, `agentDir` і `workspaceDir` для ініціалізації під час створення.
+Фабрика `ctx` надає необов’язкові значення `config`, `agentDir` і `workspaceDir`
+для ініціалізації під час створення.
-Якщо ваш рушій **не** володіє алгоритмом Compaction, залиште `compact()` реалізованим і явно делегуйте його:
+Якщо ваш рушій **не** володіє алгоритмом Compaction, залиште `compact()`
+реалізованим і делегуйте його явно:
```ts
import {
@@ -988,41 +1040,50 @@ export default function (api) {
}
```
-## Додавання нової можливості
+## Додавання нової capability
-Коли Plugin потребує поведінки, яка не вписується в поточний API, не обходьте систему Plugin приватним проникненням усередину. Додайте відсутню можливість.
+Коли Plugin потребує поведінки, яка не вписується в поточний API, не обходьте
+систему Plugin приватним доступом усередину. Додайте відсутню capability.
Рекомендована послідовність:
-1. визначте контракт core
- Вирішіть, якою спільною поведінкою має володіти core: політика, резервний варіант, злиття конфігурації, життєвий цикл, семантика для каналів і форма допоміжних засобів середовища виконання.
-2. додайте типізовані поверхні реєстрації/середовища виконання Plugin
- Розширте `OpenClawPluginApi` та/або `api.runtime` найменшою корисною типізованою поверхнею можливості.
-3. під’єднайте core + споживачів каналів/функцій
- Канали та функціональні plugins мають споживати нову можливість через core, а не імпортувати реалізацію постачальника напряму.
+1. визначте контракт ядра
+ Вирішіть, якою спільною поведінкою має володіти ядро: policy, fallback, злиття конфігурації,
+ lifecycle, семантика для каналів і форма runtime helper.
+2. додайте типізовані поверхні реєстрації/runtime Plugin
+ Розширте `OpenClawPluginApi` та/або `api.runtime` найменшою корисною
+ типізованою поверхнею capability.
+3. під’єднайте ядро + споживачів каналів/функцій
+ Канали та feature plugins мають споживати нову capability через ядро,
+ а не імпортувати реалізацію постачальника напряму.
4. зареєструйте реалізації постачальників
- Потім plugins постачальників реєструють свої бекенди для цієї можливості.
+ Vendor plugins потім реєструють свої backend для capability.
5. додайте покриття контракту
- Додайте тести, щоб власність і форма реєстрації з часом залишалися явними.
+ Додайте тести, щоб ownership і форма реєстрації з часом залишалися явними.
-Так OpenClaw залишається принциповим, не стаючи жорстко прив’язаним до світогляду одного провайдера. Дивіться [Кулінарну книгу можливостей](/uk/plugins/architecture) для конкретного контрольного списку файлів і опрацьованого прикладу.
+Саме так OpenClaw залишається принциповим, не стаючи жорстко прив’язаним до світогляду
+одного провайдера. Дивіться [кулінарну книгу capability](/uk/plugins/architecture)
+для конкретного контрольного списку файлів і пропрацьованого прикладу.
-### Контрольний список можливості
+### Контрольний список capability
-Коли ви додаєте нову можливість, реалізація зазвичай має охоплювати ці поверхні разом:
+Коли ви додаєте нову capability, реалізація зазвичай має торкатися цих
+поверхонь разом:
-- типи контракту core в `src//types.ts`
-- допоміжний засіб запуску/середовища виконання core в `src//runtime.ts`
-- поверхню реєстрації API Plugin в `src/plugins/types.ts`
-- підключення реєстру Plugin в `src/plugins/registry.ts`
-- експозицію середовища виконання Plugin в `src/plugins/runtime/*`, коли функціональним/канальним plugins потрібно її споживати
-- допоміжні засоби захоплення/тестування в `src/test-utils/plugin-registration.ts`
-- твердження щодо власності/контракту в `src/plugins/contracts/registry.ts`
-- документацію оператора/Plugin в `docs/`
+- типи контракту ядра в `src//types.ts`
+- runner/runtime helper ядра в `src//runtime.ts`
+- поверхня реєстрації API Plugin в `src/plugins/types.ts`
+- під’єднання реєстру Plugin в `src/plugins/registry.ts`
+- експозиція runtime Plugin в `src/plugins/runtime/*`, коли feature/channel
+ plugins мають її споживати
+- capture/test helpers у `src/test-utils/plugin-registration.ts`
+- твердження ownership/contract у `src/plugins/contracts/registry.ts`
+- документація operator/Plugin у `docs/`
-Якщо одна з цих поверхонь відсутня, це зазвичай ознака того, що можливість ще не повністю інтегрована.
+Якщо однієї з цих поверхонь бракує, це зазвичай ознака, що capability ще
+не повністю інтегрована.
-### Шаблон можливості
+### Шаблон capability
Мінімальний шаблон:
@@ -1058,14 +1119,14 @@ expect(findVideoGenerationProviderIdsForPlugin("openai")).toEqual(["openai"]);
Це зберігає правило простим:
-- core володіє контрактом можливості + оркестрацією
-- plugins постачальників володіють реалізаціями постачальників
-- функціональні/канальні plugins споживають допоміжні засоби середовища виконання
-- контрактні тести зберігають власність явною
+- ядро володіє контрактом capability + оркестрацією
+- vendor plugins володіють реалізаціями постачальників
+- feature/channel plugins споживають runtime helpers
+- контрактні тести зберігають ownership явним
## Пов’язане
-- [Архітектура Plugin](/uk/plugins/architecture) — публічна модель можливостей і форми
-- [Підшляхи Plugin SDK](/uk/plugins/sdk-subpaths)
-- [Налаштування Plugin SDK](/uk/plugins/sdk-setup)
+- [Архітектура Plugin](/uk/plugins/architecture) — публічна модель і форми capability
+- [Підшляхи SDK Plugin](/uk/plugins/sdk-subpaths)
+- [Налаштування SDK Plugin](/uk/plugins/sdk-setup)
- [Створення plugins](/uk/plugins/building-plugins)
diff --git a/docs/uk/plugins/architecture.md b/docs/uk/plugins/architecture.md
index 5c4bb40d4..820673a28 100644
--- a/docs/uk/plugins/architecture.md
+++ b/docs/uk/plugins/architecture.md
@@ -1,26 +1,26 @@
---
read_when:
- Збирання або налагодження нативних плагінів OpenClaw
- - Розуміння моделі можливостей Plugin або меж володіння
+ - Розуміння моделі можливостей Plugin або меж відповідальності
- Робота над конвеєром завантаження Plugin або реєстром
- - Реалізація хуків середовища виконання провайдера або Plugin для каналів
+ - Реалізація хуків середовища виконання провайдера або плагінів каналів
sidebarTitle: Internals
-summary: 'Внутрішня архітектура Plugin: модель можливостей, право власності, контракти, конвеєр завантаження та допоміжні засоби середовища виконання'
-title: Внутрішні механізми Plugin
+summary: 'Внутрішні механізми Plugin: модель можливостей, володіння, контракти, конвеєр завантаження та допоміжні засоби середовища виконання'
+title: Внутрішня реалізація Plugin
x-i18n:
- generated_at: "2026-04-28T11:18:49Z"
+ generated_at: "2026-04-29T02:56:30Z"
model: gpt-5.5
provider: openai
- source_hash: 6afc634508c1d623fa1caceb6b463917f5a8adbaabf42b5381974bd86d117f5d
+ source_hash: 1516e0784a005af87a6c081d8027a1e2dc10445e47b6824488e9d9987bb96975
source_path: plugins/architecture.md
workflow: 16
---
-Це **поглиблений архітектурний довідник** для системи plugins OpenClaw. Для практичних посібників почніть з однієї зі спеціалізованих сторінок нижче.
+Це **поглиблений архітектурний довідник** для системи plugins OpenClaw. Для практичних посібників почніть з однієї з наведених нижче тематичних сторінок.
-
- Посібник для кінцевих користувачів щодо додавання, увімкнення й усунення несправностей plugins.
+
+ Посібник для кінцевих користувачів із додавання, увімкнення та усунення несправностей plugins.
Посібник зі створення першого plugin з найменшим робочим маніфестом.
@@ -32,45 +32,45 @@ x-i18n:
Створіть plugin постачальника моделей.
- Довідник щодо карти імпортів і API реєстрації.
+ Довідник з карти імпортів і API реєстрації.
## Публічна модель можливостей
-Можливості є публічною моделлю **нативних plugin** в OpenClaw. Кожен нативний plugin OpenClaw реєструється для одного або кількох типів можливостей:
+Можливості є публічною моделлю **нативного plugin** всередині OpenClaw. Кожен нативний plugin OpenClaw реєструється для одного або кількох типів можливостей:
-| Можливість | Метод реєстрації | Приклади plugins |
+| Можливість | Метод реєстрації | Приклади plugins |
| ---------------------- | ------------------------------------------------ | ------------------------------------ |
-| Текстове виведення | `api.registerProvider(...)` | `openai`, `anthropic` |
-| Бекенд CLI-виведення | `api.registerCliBackend(...)` | `openai`, `anthropic` |
-| Мовлення | `api.registerSpeechProvider(...)` | `elevenlabs`, `microsoft` |
+| Текстовий inference | `api.registerProvider(...)` | `openai`, `anthropic` |
+| Backend inference CLI | `api.registerCliBackend(...)` | `openai`, `anthropic` |
+| Мовлення | `api.registerSpeechProvider(...)` | `elevenlabs`, `microsoft` |
| Транскрипція в реальному часі | `api.registerRealtimeTranscriptionProvider(...)` | `openai` |
-| Голос у реальному часі | `api.registerRealtimeVoiceProvider(...)` | `openai` |
-| Розуміння медіа | `api.registerMediaUnderstandingProvider(...)` | `openai`, `google` |
-| Генерація зображень | `api.registerImageGenerationProvider(...)` | `openai`, `google`, `fal`, `minimax` |
+| Голос у реальному часі | `api.registerRealtimeVoiceProvider(...)` | `openai` |
+| Розуміння медіа | `api.registerMediaUnderstandingProvider(...)` | `openai`, `google` |
+| Генерація зображень | `api.registerImageGenerationProvider(...)` | `openai`, `google`, `fal`, `minimax` |
| Генерація музики | `api.registerMusicGenerationProvider(...)` | `google`, `minimax` |
-| Генерація відео | `api.registerVideoGenerationProvider(...)` | `qwen` |
-| Отримання вебвмісту | `api.registerWebFetchProvider(...)` | `firecrawl` |
-| Вебпошук | `api.registerWebSearchProvider(...)` | `google` |
-| Канал / обмін повідомленнями | `api.registerChannel(...)` | `msteams`, `matrix` |
+| Генерація відео | `api.registerVideoGenerationProvider(...)` | `qwen` |
+| Веб-отримання | `api.registerWebFetchProvider(...)` | `firecrawl` |
+| Веб-пошук | `api.registerWebSearchProvider(...)` | `google` |
+| Канал / повідомлення | `api.registerChannel(...)` | `msteams`, `matrix` |
| Виявлення Gateway | `api.registerGatewayDiscoveryService(...)` | `bonjour` |
-Plugin, який реєструє нуль можливостей, але надає hooks, tools, служби виявлення або фонові служби, є **застарілим plugin лише з hooks**. Цей шаблон досі повністю підтримується.
+Plugin, який реєструє нуль можливостей, але надає hooks, tools, служби виявлення або фонові служби, є **застарілим plugin лише з hooks**. Цей шаблон і досі повністю підтримується.
### Позиція щодо зовнішньої сумісності
-Модель можливостей уже додано в core і сьогодні використовується в вбудованих/нативних plugins, але сумісність зовнішніх plugins усе ще потребує суворішої планки, ніж «це експортовано, отже це зафіксовано».
+Модель можливостей уже є в core і сьогодні використовується bundled/native plugins, але сумісність зовнішніх plugins все ще потребує суворішого критерію, ніж "це експортовано, отже це заморожено."
-| Ситуація з plugin | Рекомендації |
+| Ситуація з plugin | Настанова |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
-| Наявні зовнішні plugins | Підтримуйте працездатність інтеграцій на основі hooks; це базова лінія сумісності. |
-| Нові вбудовані/нативні plugins | Надавайте перевагу явній реєстрації можливостей замість vendor-specific reach-ins або нових дизайнів лише на hooks. |
-| Зовнішні plugins, що впроваджують реєстрацію можливостей | Дозволено, але вважайте допоміжні поверхні, специфічні для можливостей, такими, що еволюціонують, якщо документація не позначає їх стабільними. |
+| Наявні зовнішні plugins | Підтримуйте роботу інтеграцій на основі hooks; це базовий рівень сумісності. |
+| Нові bundled/native plugins | Надавайте перевагу явній реєстрації можливостей замість vendor-specific reach-ins або нових дизайнів лише з hooks. |
+| Зовнішні plugins, що впроваджують реєстрацію можливостей | Дозволено, але вважайте допоміжні поверхні для конкретних можливостей такими, що розвиваються, якщо docs не позначають їх стабільними. |
-Реєстрація можливостей є цільовим напрямком. Застарілі hooks залишаються найбезпечнішим шляхом без поломок для зовнішніх plugins під час переходу. Експортовані допоміжні підшляхи не всі рівноцінні — надавайте перевагу вузьким задокументованим контрактам над випадковими допоміжними експортами.
+Реєстрація можливостей є запланованим напрямом. Застарілі hooks залишаються найбезпечнішим шляхом без поломок для зовнішніх plugins під час переходу. Експортовані допоміжні subpaths не є однаковими — надавайте перевагу вузьким документованим контрактам, а не випадковим допоміжним експортам.
### Форми plugin
@@ -78,43 +78,43 @@ OpenClaw класифікує кожен завантажений plugin за ф
- Реєструє рівно один тип можливості (наприклад, plugin лише постачальника, як-от `mistral`).
+ Реєструє рівно один тип можливості (наприклад, plugin лише постачальника, як `mistral`).
- Реєструє кілька типів можливостей (наприклад, `openai` володіє текстовим виведенням, мовленням, розумінням медіа та генерацією зображень).
+ Реєструє кілька типів можливостей (наприклад, `openai` володіє текстовим inference, мовленням, розумінням медіа та генерацією зображень).
- Реєструє лише hooks (типізовані або користувацькі), без можливостей, tools, команд або служб.
+ Реєструє лише hooks (типізовані або користувацькі), без можливостей, tools, commands або services.
- Реєструє tools, команди, служби або маршрути, але без можливостей.
+ Реєструє tools, commands, services або routes, але без можливостей.
-Використовуйте `openclaw plugins inspect `, щоб побачити форму plugin та розбивку його можливостей. Докладніше див. [довідник CLI](/uk/cli/plugins#inspect).
+Використовуйте `openclaw plugins inspect `, щоб переглянути форму plugin і розбивку його можливостей. Докладніше див. у [довіднику CLI](/uk/cli/plugins#inspect).
### Застарілі hooks
-Hook `before_agent_start` залишається підтримуваним як шлях сумісності для plugins лише з hooks. Застарілі реальні plugins досі залежать від нього.
+Hook `before_agent_start` залишається підтримуваним як шлях сумісності для plugins лише з hooks. Застарілі реальні plugins усе ще залежать від нього.
-Напрямок:
+Напрям:
-- підтримувати його працездатність
+- підтримувати його роботу
- документувати його як застарілий
-- надавати перевагу `before_model_resolve` для роботи з перевизначенням моделі/постачальника
+- надавати перевагу `before_model_resolve` для роботи з перевизначенням model/provider
- надавати перевагу `before_prompt_build` для роботи зі зміною prompt
-- видалити лише після того, як реальне використання зменшиться, а покриття fixtures підтвердить безпеку міграції
+- видаляти лише після зменшення реального використання та коли покриття fixtures доведе безпечність міграції
### Сигнали сумісності
Коли ви запускаєте `openclaw doctor` або `openclaw plugins inspect `, ви можете побачити одну з цих міток:
-| Сигнал | Значення |
+| Сигнал | Значення |
| -------------------------- | ------------------------------------------------------------ |
-| **config valid** | Config успішно розбирається, а plugins розв’язуються |
+| **config valid** | Config успішно розбирається, а plugins resolve |
| **compatibility advisory** | Plugin використовує підтримуваний, але старіший шаблон (наприклад, `hook-only`) |
-| **legacy warning** | Plugin використовує `before_agent_start`, який застарів |
-| **hard error** | Config недійсний або plugin не вдалося завантажити |
+| **legacy warning** | Plugin використовує `before_agent_start`, який є deprecated |
+| **hard error** | Config недійсна або plugin не вдалося завантажити |
Ані `hook-only`, ані `before_agent_start` сьогодні не зламають ваш plugin: `hook-only` є рекомендаційним сигналом, а `before_agent_start` лише викликає попередження. Ці сигнали також з’являються в `openclaw status --all` і `openclaw plugins doctor`.
@@ -124,87 +124,89 @@ Hook `before_agent_start` залишається підтримуваним як
- OpenClaw знаходить кандидатні plugins із налаштованих шляхів, коренів робочих просторів, глобальних коренів plugins і вбудованих plugins. Виявлення спочатку читає нативні маніфести `openclaw.plugin.json` та підтримувані маніфести пакетів.
+ OpenClaw знаходить кандидатні plugins із налаштованих шляхів, workspace roots, глобальних коренів plugins і bundled plugins. Виявлення спочатку читає нативні маніфести `openclaw.plugin.json` плюс підтримувані bundle manifests.
-
- Core вирішує, чи виявлений plugin увімкнений, вимкнений, заблокований або вибраний для ексклюзивного слота, наприклад пам’яті.
+
+ Core вирішує, чи виявлений plugin увімкнено, вимкнено, заблоковано або вибрано для ексклюзивного слота, як-от memory.
-
- Нативні plugins OpenClaw завантажуються в процесі через jiti і реєструють можливості в центральному реєстрі. Сумісні пакети нормалізуються в записи реєстру без імпортування коду виконання.
+
+ Нативні plugins OpenClaw завантажуються in-process через jiti та реєструють можливості в центральному registry. Сумісні bundles нормалізуються в registry records без імпорту runtime code.
-
- Решта OpenClaw читає реєстр, щоб відкривати tools, канали, налаштування постачальників, hooks, HTTP-маршрути, команди CLI та служби.
+
+ Решта OpenClaw читає registry, щоб expose tools, channels, provider setup, hooks, HTTP routes, CLI commands і services.
-Саме для CLI plugins виявлення кореневих команд поділено на дві фази:
+Спеціально для plugin CLI виявлення root commands розділене на дві фази:
-- метадані часу розбору надходять із `registerCli(..., { descriptors: [...] })`
-- справжній модуль CLI plugin може залишатися ледачим і реєструватися під час першого виклику
+- метадані під час parse-time надходять із `registerCli(..., { descriptors: [...] })`
+- справжній модуль CLI plugin може залишатися lazy і реєструватися під час першого invocation
-Це утримує CLI-код, що належить plugin, всередині plugin, водночас дозволяючи OpenClaw зарезервувати назви кореневих команд до розбору.
+Це тримає CLI-код, що належить plugin, всередині plugin, але все одно дозволяє OpenClaw резервувати імена root commands до parsing.
Важлива межа дизайну:
-- перевірка маніфесту/config має працювати з **метаданих маніфесту/схеми** без виконання коду plugin
-- виявлення нативних можливостей може завантажувати довірений код входу plugin, щоб побудувати знімок реєстру без активації
-- нативна поведінка під час виконання надходить зі шляху `register(api)` модуля plugin, коли `api.registrationMode === "full"`
+- валідація manifest/config має працювати з **metadata manifest/schema** без виконання коду plugin
+- нативне виявлення можливостей може завантажувати trusted entry code plugin, щоб побудувати non-activating registry snapshot
+- нативна runtime-поведінка походить зі шляху `register(api)` модуля plugin з `api.registrationMode === "full"`
-Такий поділ дає OpenClaw змогу перевіряти config, пояснювати відсутні/вимкнені plugins і будувати підказки UI/схеми до того, як повний runtime стане активним.
+Цей поділ дозволяє OpenClaw валідувати config, пояснювати відсутні/вимкнені plugins і будувати підказки UI/schema до того, як повний runtime стане активним.
-### Знімок метаданих plugin і таблиця пошуку
+### Snapshot метаданих plugin і lookup table
-Під час запуску Gateway будує один `PluginMetadataSnapshot` для поточного знімка config. Знімок містить лише метадані: він зберігає індекс установлених plugins, реєстр маніфестів, діагностику маніфестів, карти власників, нормалізатор id plugin і записи маніфестів. Він не містить завантажених модулів plugin, SDK постачальників, вмісту пакетів або runtime-експортів.
+Під час запуску Gateway будує один `PluginMetadataSnapshot` для поточного snapshot config. Snapshot містить лише метадані: він зберігає індекс встановлених plugins, manifest registry, manifest diagnostics, owner maps, нормалізатор id plugin і manifest records. Він не містить завантажених модулів plugin, provider SDKs, package contents або runtime exports.
-Перевірка config з урахуванням plugins, автоматичне увімкнення під час запуску та bootstrap plugins Gateway споживають цей знімок замість незалежної повторної побудови метаданих маніфесту/індексу. `PluginLookUpTable` виводиться з того самого знімка й додає план plugins запуску для поточної runtime config.
+Валідація config з урахуванням plugins, startup auto-enable і bootstrap plugins Gateway споживають цей snapshot замість незалежної перебудови manifest/index metadata. `PluginLookUpTable` виводиться з того самого snapshot і додає startup plugin plan для поточного runtime config.
-Після запуску Gateway зберігає поточний знімок метаданих як замінюваний runtime-продукт. Повторне виявлення runtime-постачальників може позичати цей знімок замість реконструкції встановленого індексу та реєстру маніфестів для кожного проходу каталогу постачальників. Знімок очищується або замінюється під час завершення роботи Gateway, змін config/інвентарю plugins і записів установленого індексу; виклики повертаються до холодного шляху маніфесту/індексу, коли сумісного поточного знімка немає. Перевірки сумісності мають включати корені виявлення plugins, такі як `plugins.load.paths` і стандартний робочий простір агента, оскільки plugins робочого простору є частиною області метаданих.
+Після запуску Gateway зберігає поточний metadata snapshot як замінний runtime product. Повторне runtime provider discovery може позичати цей snapshot замість реконструювання installed index і manifest registry для кожного provider-catalog pass. Snapshot очищується або замінюється під час завершення роботи Gateway, змін config/plugin inventory і записів installed index; callers повертаються до холодного manifest/index path, коли немає сумісного поточного snapshot. Compatibility checks мають включати plugin discovery roots, як-от `plugins.load.paths`, і стандартний agent workspace, тому що workspace plugins є частиною metadata scope.
-Знімок і таблиця пошуку утримують повторні рішення запуску на швидкому шляху:
+Snapshot і lookup table тримають повторювані startup decisions на швидкому path:
-- власність каналу
-- відкладений запуск каналу
-- id plugins запуску
-- власність постачальника та бекенду CLI
-- власність постачальника налаштування, alias команди, постачальника каталогу моделей і контракту маніфесту
-- перевірка схеми config plugin і схеми config каналу
-- рішення автоматичного увімкнення під час запуску
+- channel ownership
+- deferred channel startup
+- startup plugin ids
+- provider and CLI backend ownership
+- setup provider, command alias, model catalog provider і manifest contract ownership
+- валідація plugin config schema і channel config schema
+- startup auto-enable decisions
-Межею безпеки є заміна знімка, а не мутація. Перебудовуйте знімок, коли змінюються config, інвентар plugins, записи встановлення або політика збереженого індексу. Не розглядайте його як широкий змінний глобальний реєстр і не зберігайте необмежену історію знімків. Runtime-завантаження plugins залишається окремим від знімків метаданих, щоб застарілий runtime-стан не міг бути прихований за кешем метаданих.
+Межа безпеки — це заміна snapshot, а не mutation. Перебудовуйте snapshot, коли змінюються config, plugin inventory, install records або persisted index policy. Не вважайте його широким mutable global registry і не зберігайте необмежені historical snapshots. Runtime plugin loading залишається окремим від metadata snapshots, щоб stale runtime state не міг бути прихований за metadata cache.
-Деякі виклики холодного шляху досі реконструюють реєстри маніфестів безпосередньо зі збереженого індексу встановлених plugins замість отримання Gateway `PluginLookUpTable`. Цей запасний шлях зберігає невеликий обмежений кеш у пам’яті, ключований установленим індексом, формою запиту, політикою config, runtime-коренями та сигнатурами файлів маніфесту/пакета. Це запасна сітка безпеки для повторної реконструкції індексу, а не бажаний гарячий шлях Gateway. Надавайте перевагу передаванню поточної таблиці пошуку або явного реєстру маніфестів через runtime-потоки, коли виклик уже має один із них.
+Правило cache задокументовано в [Plugin architecture internals](/uk/plugins/architecture-internals#plugin-cache-boundary): metadata manifest і discovery є свіжими, якщо caller не тримає explicit snapshot, lookup table або manifest registry для поточного flow. Hidden metadata caches і wall-clock TTLs не є частиною plugin loading. Лише runtime loader, module і dependency-artifact caches можуть зберігатися після фактичного завантаження code або installed artifacts.
+
+Деякі cold-path callers досі реконструюють manifest registries напряму з persisted installed plugin index замість отримання `PluginLookUpTable` Gateway. Цей path тепер реконструює registry on demand; надавайте перевагу передаванню current lookup table або explicit manifest registry через runtime flows, коли caller уже має один із них.
### Планування активації
-Планування активації є частиною control plane. Виклики можуть запитати, які plugins релевантні для конкретної команди, постачальника, каналу, маршруту, harness агента або можливості, перш ніж завантажувати ширші runtime-реєстри.
+Планування активації є частиною control plane. Callers можуть запитати, які plugins релевантні для конкретної command, provider, channel, route, agent harness або capability, перш ніж завантажувати ширші runtime registries.
-Планувальник зберігає сумісність із поточною поведінкою маніфесту:
+Planner зберігає сумісність поточної manifest-поведінки:
-- поля `activation.*` є явними підказками планувальника
-- `providers`, `channels`, `commandAliases`, `setup.providers`, `contracts.tools` і hooks залишаються запасним варіантом визначення власності з маніфесту
-- API планувальника лише з id залишається доступним для наявних викликів
-- API плану повідомляє мітки причин, щоб діагностика могла відрізняти явні підказки від запасного визначення власності
+- поля `activation.*` є явними підказками planner
+- `providers`, `channels`, `commandAliases`, `setup.providers`, `contracts.tools` і hooks залишаються fallback ownership manifest
+- ids-only planner API залишається доступним для наявних callers
+- plan API повідомляє reason labels, щоб diagnostics могли відрізняти explicit hints від ownership fallback
-Не розглядайте `activation` як hook життєвого циклу або заміну для `register(...)`. Це метадані, що використовуються для звуження завантаження. Надавайте перевагу полям власності, коли вони вже описують зв’язок; використовуйте `activation` лише для додаткових підказок планувальника.
+Не розглядайте `activation` як хук життєвого циклу або заміну для `register(...)`. Це метадані, які використовуються для звуження завантаження. Віддавайте перевагу полям власності, коли вони вже описують зв’язок; використовуйте `activation` лише для додаткових підказок планувальнику.
-### Channel plugins і спільний tool повідомлень
+### Канальні плагіни та спільний інструмент повідомлень
-Plugin каналів не потрібно реєструвати окремий інструмент send/edit/react для звичайних дій чату. OpenClaw зберігає один спільний інструмент `message` у ядрі, а Plugin каналів володіють специфічним для каналу виявленням і виконанням за ним.
+Канальним плагінам не потрібно реєструвати окремий інструмент надсилання/редагування/реакцій для звичайних дій у чаті. OpenClaw зберігає один спільний інструмент `message` у ядрі, а канальні плагіни володіють специфічним для каналу виявленням і виконанням за ним.
Поточна межа така:
-- ядро володіє спільним хостом інструмента `message`, підключенням prompt, обліком сесій/threads і диспетчеризацією виконання
-- Plugin каналів володіють виявленням дій у межах області, виявленням можливостей і будь-якими специфічними для каналу фрагментами schema
-- Plugin каналів володіють граматикою розмови сесії конкретного провайдера, наприклад тим, як conversation ids кодують thread ids або успадковуються від батьківських розмов
-- Plugin каналів виконують фінальну дію через свій action adapter
+- ядро володіє хостом спільного інструмента `message`, підключенням промптів, обліком сеансів/тредів і диспетчеризацією виконання
+- канальні плагіни володіють виявленням дій у межах області, виявленням можливостей і будь-якими специфічними для каналу фрагментами схеми
+- канальні плагіни володіють специфічною для провайдера граматикою розмови сеансу, наприклад тим, як ідентифікатори розмов кодують ідентифікатори тредів або успадковуються від батьківських розмов
+- канальні плагіни виконують фінальну дію через свій адаптер дій
-Для Plugin каналів поверхня SDK — це `ChannelMessageActionAdapter.describeMessageTool(...)`. Цей уніфікований виклик виявлення дає Plugin змогу повертати видимі дії, можливості та внески до schema разом, щоб ці частини не розходилися.
+Для канальних плагінів поверхня SDK — це `ChannelMessageActionAdapter.describeMessageTool(...)`. Цей уніфікований виклик виявлення дає плагіну змогу повернути свої видимі дії, можливості та внески до схеми разом, щоб ці частини не розходилися.
-Коли специфічний для каналу параметр message-tool містить джерело media, як-от локальний шлях або віддалений media URL, Plugin також має повертати `mediaSourceParams` із `describeMessageTool(...)`. Ядро використовує цей явний список, щоб застосувати нормалізацію sandbox path і підказки outbound media-access без жорстко закодованих назв параметрів, що належать Plugin. Надавайте перевагу мапам у межах дії, а не одному плоскому списку на весь канал, щоб media-параметр лише для профілю не нормалізувався для непов’язаних дій, як-от `send`.
+Коли специфічний для каналу параметр інструмента повідомлень містить джерело медіа, наприклад локальний шлях або URL віддаленого медіа, плагін також має повертати `mediaSourceParams` з `describeMessageTool(...)`. Ядро використовує цей явний список, щоб застосувати нормалізацію шляхів пісочниці та підказки доступу до вихідних медіа без жорсткого кодування назв параметрів, якими володіє плагін. Віддавайте перевагу мапам у межах дії, а не одному пласкому списку для всього каналу, щоб параметр медіа лише для профілю не нормалізувався в непов’язаних діях, як-от `send`.
-Ядро передає runtime scope у цей крок виявлення. Важливі поля включають:
+Ядро передає область виконання на цьому кроці виявлення. Важливі поля включають:
- `accountId`
- `currentChannelId`
@@ -213,108 +215,108 @@ Plugin каналів не потрібно реєструвати окреми
- `sessionKey`
- `sessionId`
- `agentId`
-- довірений inbound `requesterSenderId`
+- довірений вхідний `requesterSenderId`
-Це важливо для контекстно-залежних Plugin. Канал може приховувати або показувати message actions на основі активного облікового запису, поточної room/thread/message або довіреної ідентичності requester без жорстко закодованих специфічних для каналу гілок у ядрі інструмента `message`.
+Це важливо для контекстно-залежних плагінів. Канал може приховувати або показувати дії повідомлень залежно від активного облікового запису, поточної кімнати/треду/повідомлення або довіреної ідентичності запитувача без жорстко закодованих специфічних для каналу гілок у базовому інструменті `message`.
-Саме тому зміни маршрутизації embedded-runner все ще є роботою Plugin: runner відповідає за пересилання поточної ідентичності chat/session у межу виявлення Plugin, щоб спільний інструмент `message` відкривав правильну поверхню, що належить каналу, для поточного ходу.
+Саме тому зміни маршрутизації вбудованого раннера все ще є роботою плагіна: раннер відповідає за передавання поточної ідентичності чату/сеансу до межі виявлення плагіна, щоб спільний інструмент `message` показував правильну поверхню, якою володіє канал, для поточного ходу.
-Для execution helpers, що належать каналу, bundled plugins мають тримати execution runtime всередині власних модулів розширення. Ядро більше не володіє runtime для message-action Discord, Slack, Telegram або WhatsApp у `src/agents/tools`. Ми не публікуємо окремі subpaths `plugin-sdk/*-action-runtime`, і bundled plugins мають імпортувати власний локальний runtime code безпосередньо зі своїх модулів, що належать розширенню.
+Для допоміжних засобів виконання, якими володіє канал, вбудовані плагіни мають тримати середовище виконання всередині власних модулів розширення. Ядро більше не володіє середовищами виконання дій повідомлень Discord, Slack, Telegram або WhatsApp у `src/agents/tools`. Ми не публікуємо окремі підшляхи `plugin-sdk/*-action-runtime`, і вбудовані плагіни мають імпортувати власний локальний код середовища виконання безпосередньо зі своїх модулів, якими володіє розширення.
-Та сама межа загалом застосовується до provider-named SDK seams: ядро не має імпортувати специфічні для каналу convenience barrels для Slack, Discord, Signal, WhatsApp або подібних розширень. Якщо ядру потрібна поведінка, воно має або споживати власний barrel bundled Plugin `api.ts` / `runtime-api.ts`, або підняти потребу в вузьку generic capability у спільному SDK.
+Та сама межа загалом застосовується до названих за провайдерами швів SDK: ядро не має імпортувати специфічні для каналу зручні барелі для Slack, Discord, Signal, WhatsApp або подібних розширень. Якщо ядру потрібна поведінка, або споживайте власний барель `api.ts` / `runtime-api.ts` вбудованого плагіна, або підніміть потребу до вузької загальної можливості у спільному SDK.
-Bundled plugins дотримуються того самого правила. `runtime-api.ts` bundled Plugin не має повторно експортувати власний branded facade `openclaw/plugin-sdk/`. Ці branded facades лишаються compatibility shims для external plugins і старіших consumers, але bundled plugins мають використовувати локальні exports плюс вузькі generic SDK subpaths, як-от `openclaw/plugin-sdk/channel-policy`, `openclaw/plugin-sdk/runtime-store` або `openclaw/plugin-sdk/webhook-ingress`. Новий код не має додавати SDK facades, специфічні для plugin-id, якщо цього не вимагає compatibility boundary для наявної зовнішньої екосистеми.
+Вбудовані плагіни дотримуються того самого правила. `runtime-api.ts` вбудованого плагіна не має повторно експортувати власний брендований фасад `openclaw/plugin-sdk/`. Ці брендовані фасади залишаються сумісними shim для зовнішніх плагінів і старіших споживачів, але вбудовані плагіни мають використовувати локальні експорти плюс вузькі загальні підшляхи SDK, як-от `openclaw/plugin-sdk/channel-policy`, `openclaw/plugin-sdk/runtime-store` або `openclaw/plugin-sdk/webhook-ingress`. Новий код не має додавати специфічні для ідентифікатора плагіна фасади SDK, якщо межа сумісності для наявної зовнішньої екосистеми цього не вимагає.
-Конкретно для polls є два шляхи виконання:
+Зокрема для опитувань є два шляхи виконання:
-- `outbound.sendPoll` — спільна базова лінія для каналів, що відповідають common poll model
-- `actions.handleAction("poll")` — бажаний шлях для специфічної для каналу semantics poll або додаткових poll parameters
+- `outbound.sendPoll` — це спільна базова лінія для каналів, які відповідають спільній моделі опитування
+- `actions.handleAction("poll")` — бажаний шлях для специфічної для каналу семантики опитувань або додаткових параметрів опитування
-Тепер ядро відкладає спільний parsing poll, доки диспетчеризація poll Plugin не відхилить дію, тому poll handlers, що належать Plugin, можуть приймати специфічні для каналу poll fields без блокування generic poll parser спочатку.
+Тепер ядро відкладає спільний розбір опитування доти, доки диспетчеризація опитування плагіном не відхилить дію, тож обробники опитувань, якими володіє плагін, можуть приймати специфічні для каналу поля опитування без попереднього блокування загальним парсером опитувань.
-Див. [внутрішню архітектуру Plugin](/uk/plugins/architecture-internals), щоб переглянути повну послідовність запуску.
+Див. [Внутрішня архітектура плагінів](/uk/plugins/architecture-internals) для повної послідовності запуску.
-## Модель володіння можливостями
+## Модель власності можливостей
-OpenClaw розглядає native Plugin як межу володіння для **компанії** або **функції**, а не як випадковий набір непов’язаних інтеграцій.
+OpenClaw розглядає нативний плагін як межу власності для **компанії** або **функції**, а не як набір непов’язаних інтеграцій.
Це означає:
-- company Plugin зазвичай має володіти всіма поверхнями цієї компанії, зверненими до OpenClaw
-- feature Plugin зазвичай має володіти повною поверхнею функції, яку він вводить
-- канали мають споживати спільні можливості ядра замість повторної ad hoc реалізації provider behavior
+- плагін компанії зазвичай має володіти всіма поверхнями цієї компанії, спрямованими до OpenClaw
+- функціональний плагін зазвичай має володіти повною поверхнею функції, яку він вводить
+- канали мають споживати спільні можливості ядра замість того, щоб повторно реалізовувати поведінку провайдера ad hoc
-
- `openai` володіє text inference, speech, realtime voice, media understanding та image generation. `google` володіє text inference плюс media understanding, image generation і web search. `qwen` володіє text inference плюс media understanding і video generation.
+
+ `openai` володіє текстовим інференсом, мовленням, голосом у реальному часі, розумінням медіа та генерацією зображень. `google` володіє текстовим інференсом плюс розумінням медіа, генерацією зображень і вебпошуком. `qwen` володіє текстовим інференсом плюс розумінням медіа та генерацією відео.
-
- `elevenlabs` і `microsoft` володіють speech; `firecrawl` володіє web-fetch; `minimax` / `mistral` / `moonshot` / `zai` володіють media-understanding backends.
+
+ `elevenlabs` і `microsoft` володіють мовленням; `firecrawl` володіє web-fetch; `minimax` / `mistral` / `moonshot` / `zai` володіють бекендами розуміння медіа.
-
- `voice-call` володіє call transport, tools, CLI, routes і Twilio media-stream bridging, але споживає спільні можливості speech, realtime transcription і realtime voice замість прямого імпорту vendor plugins.
+
+ `voice-call` володіє транспортом викликів, інструментами, CLI, маршрутами та мостом медіапотоку Twilio, але споживає спільні можливості мовлення, транскрибування в реальному часі та голосу в реальному часі замість прямого імпорту плагінів постачальників.
Очікуваний кінцевий стан:
-- OpenAI живе в одному Plugin, навіть якщо охоплює text models, speech, images і майбутнє video
-- інший постачальник може зробити те саме для власної surface area
-- каналам байдуже, який vendor Plugin володіє provider; вони споживають спільний capability contract, відкритий ядром
+- OpenAI живе в одному плагіні, навіть якщо охоплює текстові моделі, мовлення, зображення та майбутнє відео
+- інший постачальник може зробити те саме для власної поверхні
+- каналам байдуже, який плагін постачальника володіє провайдером; вони споживають спільний контракт можливості, відкритий ядром
-Ключова відмінність така:
+Це ключова відмінність:
-- **Plugin** = межа володіння
-- **capability** = контракт ядра, який можуть реалізовувати або споживати кілька Plugin
+- **плагін** = межа власності
+- **можливість** = контракт ядра, який кілька плагінів можуть реалізовувати або споживати
-Тож якщо OpenClaw додає новий домен, як-от video, перше питання не "який provider має жорстко закодувати обробку video?" Перше питання — "який core video capability contract?" Коли цей контракт існує, vendor plugins можуть реєструватися для нього, а channel/feature plugins можуть його споживати.
+Отже, якщо OpenClaw додає нову доменну область, таку як відео, перше питання не "який провайдер має жорстко кодувати обробку відео?" Перше питання: "яким є контракт можливості відео в ядрі?" Коли цей контракт існує, плагіни постачальників можуть реєструватися під нього, а канальні/функціональні плагіни можуть його споживати.
-Якщо capability ще не існує, правильний крок зазвичай такий:
+Якщо можливості ще не існує, правильний крок зазвичай такий:
-
- Визначте відсутню capability у ядрі.
+
+ Визначте відсутню можливість у ядрі.
- Відкрийте її через Plugin API/runtime типізованим способом.
+ Відкрийте її через API/середовище виконання плагінів типізованим способом.
-
- Підключіть channels/features до цієї capability.
+
+ Підключіть канали/функції до цієї можливості.
- Дайте vendor plugins змогу реєструвати реалізації.
+ Дайте плагінам постачальників зареєструвати реалізації.
-Це зберігає явне володіння, водночас уникаючи поведінки ядра, що залежить від одного vendor або одноразового code path, специфічного для Plugin.
+Це зберігає явну власність і водночас уникає поведінки ядра, що залежить від одного постачальника або одноразового специфічного для плагіна шляху коду.
-### Нашарування capabilities
+### Нашарування можливостей
-Використовуйте цю ментальну модель, коли вирішуєте, де має бути код:
+Використовуйте цю ментальну модель, вирішуючи, де має бути код:
-
- Спільна оркестрація, policy, fallback, config merge rules, delivery semantics і typed contracts.
+
+ Спільна оркестрація, політика, fallback, правила злиття конфігурації, семантика доставки та типізовані контракти.
-
- Vendor-specific APIs, auth, model catalogs, speech synthesis, image generation, майбутні video backends, usage endpoints.
+
+ Специфічні для постачальника API, auth, каталоги моделей, синтез мовлення, генерація зображень, майбутні відеобекенди, ендпоінти використання.
-
- Інтеграція Slack/Discord/voice-call/тощо, яка споживає core capabilities і представляє їх на поверхні.
+
+ Інтеграція Slack/Discord/voice-call/etc., яка споживає можливості ядра та представляє їх на поверхні.
Наприклад, TTS має таку форму:
-- ядро володіє reply-time TTS policy, fallback order, prefs і channel delivery
-- `openai`, `elevenlabs` і `microsoft` володіють synthesis implementations
-- `voice-call` споживає telephony TTS runtime helper
+- ядро володіє політикою TTS під час відповіді, порядком fallback, налаштуваннями та доставкою в канал
+- `openai`, `elevenlabs` і `microsoft` володіють реалізаціями синтезу
+- `voice-call` споживає допоміжний засіб середовища виконання телефонного TTS
-Для майбутніх можливостей варто надавати перевагу тому самому шаблону.
+Тому самому шаблону слід віддавати перевагу для майбутніх можливостей.
-### Приклад company Plugin із кількома capabilities
+### Приклад багатоможливісного плагіна компанії
-Company Plugin має відчуватися цілісним ззовні. Якщо OpenClaw має спільні контракти для models, speech, realtime transcription, realtime voice, media understanding, image generation, video generation, web fetch і web search, vendor може володіти всіма своїми поверхнями в одному місці:
+Плагін компанії має сприйматися ззовні як цілісний. Якщо OpenClaw має спільні контракти для моделей, мовлення, транскрибування в реальному часі, голосу в реальному часі, розуміння медіа, генерації зображень, генерації відео, web fetch і вебпошуку, постачальник може володіти всіма своїми поверхнями в одному місці:
```ts
import type { OpenClawPluginDefinition } from "openclaw/plugin-sdk/plugin-entry";
@@ -368,119 +370,119 @@ const plugin: OpenClawPluginDefinition = {
export default plugin;
```
-Важливі не точні назви helper. Важлива форма:
+Важливі не точні назви допоміжних засобів. Важлива форма:
-- один Plugin володіє vendor surface
-- ядро все ще володіє capability contracts
-- канали та feature plugins споживають helpers `api.runtime.*`, а не vendor code
-- contract tests можуть перевіряти, що Plugin зареєстрував capabilities, якими заявляє володіння
+- один плагін володіє поверхнею постачальника
+- ядро все ще володіє контрактами можливостей
+- канали та функціональні плагіни споживають допоміжні засоби `api.runtime.*`, а не код постачальника
+- контрактні тести можуть перевіряти, що плагін зареєстрував можливості, якими заявляє володіння
-### Приклад capability: video understanding
+### Приклад можливості: розуміння відео
-OpenClaw уже розглядає image/audio/video understanding як одну спільну capability. Та сама модель володіння застосовується і там:
+OpenClaw уже розглядає розуміння зображень/аудіо/відео як одну спільну можливість. Та сама модель власності застосовується і там:
- Ядро визначає media-understanding contract.
+ Ядро визначає контракт розуміння медіа.
-
- Vendor plugins реєструють `describeImage`, `transcribeAudio` і `describeVideo`, якщо застосовно.
+
+ Плагіни постачальників реєструють `describeImage`, `transcribeAudio` і `describeVideo`, якщо застосовно.
-
- Channels і feature plugins споживають спільну core behavior замість прямого підключення до vendor code.
+
+ Канали та функціональні плагіни споживають спільну поведінку ядра замість прямого підключення до коду постачальника.
-Це уникає вбудовування припущень одного provider щодо video у ядро. Plugin володіє vendor surface; ядро володіє capability contract і fallback behavior.
+Це уникає вбудовування припущень одного провайдера про відео в ядро. Плагін володіє поверхнею постачальника; ядро володіє контрактом можливості та поведінкою fallback.
-Video generation уже використовує ту саму послідовність: ядро володіє typed capability contract і runtime helper, а vendor plugins реєструють реалізації `api.registerVideoGenerationProvider(...)` для нього.
+Генерація відео вже використовує ту саму послідовність: ядро володіє типізованим контрактом можливості та допоміжним засобом середовища виконання, а плагіни постачальників реєструють реалізації `api.registerVideoGenerationProvider(...)` під нього.
-Потрібен конкретний rollout checklist? Див. [Capability Cookbook](/uk/plugins/architecture).
+Потрібен конкретний контрольний список розгортання? Див. [Кулінарна книга можливостей](/uk/plugins/architecture).
-## Контракти та примусове застосування
+## Контракти та примусове забезпечення
-Поверхня Plugin API навмисно типізована й централізована в `OpenClawPluginApi`. Цей контракт визначає підтримувані registration points і runtime helpers, на які може покладатися Plugin.
+Поверхня API плагінів навмисно типізована й централізована в `OpenClawPluginApi`. Цей контракт визначає підтримувані точки реєстрації та допоміжні засоби середовища виконання, на які плагін може покладатися.
Чому це важливо:
-- автори Plugin отримують один стабільний внутрішній стандарт
-- ядро може відхиляти duplicate ownership, наприклад коли два Plugin реєструють той самий provider id
-- запуск може показувати actionable diagnostics для malformed registration
-- contract tests можуть забезпечувати ownership bundled-plugin і запобігати непомітному drift
+- автори плагінів отримують один стабільний внутрішній стандарт
+- ядро може відхиляти дублювання власності, наприклад коли два плагіни реєструють той самий ідентифікатор провайдера
+- запуск може показувати діагностику з конкретними діями для некоректної реєстрації
+- контрактні тести можуть забезпечувати власність вбудованих плагінів і запобігати непомітному дрейфу
-Є два рівні enforcement:
+Є два шари примусового забезпечення:
-
- Plugin registry перевіряє registrations під час завантаження Plugin. Приклади: duplicate provider ids, duplicate speech provider ids і malformed registrations створюють plugin diagnostics замість undefined behavior.
+
+ Реєстр Plugin перевіряє реєстрації під час завантаження Plugin. Приклади: дублікати ідентифікаторів провайдерів, дублікати ідентифікаторів провайдерів мовлення та некоректно сформовані реєстрації створюють діагностику Plugin замість невизначеної поведінки.
-
- Bundled plugins фіксуються в contract registries під час тестових запусків, щоб OpenClaw міг явно перевіряти ownership. Сьогодні це використовується для model providers, speech providers, web search providers і bundled registration ownership.
+
+ Вбудовані Plugin фіксуються в контрактних реєстрах під час тестових запусків, щоб OpenClaw міг явно перевіряти володіння. Нині це використовується для провайдерів моделей, провайдерів мовлення, провайдерів вебпошуку та володіння вбудованими реєстраціями.
-Практичний ефект полягає в тому, що OpenClaw заздалегідь знає, який plugin володіє якою поверхнею. Це дає змогу ядру й каналам безшовно компонуватися, тому що володіння оголошене, типізоване й придатне для тестування, а не неявне.
+Практичний ефект полягає в тому, що OpenClaw заздалегідь знає, який Plugin володіє якою поверхнею. Це дає core і каналам змогу безшовно компонуватися, оскільки володіння оголошене, типізоване й тестоване, а не неявне.
### Що належить до контракту
-
+
- типізовані
- - невеликі
- - специфічні для можливості
- - належать ядру
- - повторно використовувані кількома plugins
- - споживані каналами/функціями без знання постачальника
+ - малі
+ - прив’язані до конкретної можливості
+ - належать core
+ - повторно використовуються кількома Plugin
+ - споживаються каналами/функціями без знання постачальника
- - специфічна для постачальника політика, прихована в ядрі
- - одноразові обхідні шляхи plugin, що обходять реєстр
- - код каналу, який напряму звертається до реалізації постачальника
- - ситуативні runtime-об’єкти, які не є частиною `OpenClawPluginApi` або `api.runtime`
+ - специфічна для постачальника політика, прихована в core
+ - одноразові обхідні шляхи Plugin, що обходять реєстр
+ - код каналу, який звертається напряму до реалізації постачальника
+ - ad hoc об’єкти часу виконання, що не є частиною `OpenClawPluginApi` або `api.runtime`
-Якщо маєте сумніви, підніміть рівень абстракції: спочатку визначте можливість, а потім дозвольте plugins підключатися до неї.
+Коли є сумніви, підніміть рівень абстракції: спочатку визначте можливість, а потім дозвольте Plugin підключатися до неї.
## Модель виконання
-Нативні plugins OpenClaw працюють **у процесі** разом із Gateway. Вони не ізольовані в пісочниці. Завантажений нативний plugin має ту саму межу довіри на рівні процесу, що й код ядра.
+Нативні Plugin OpenClaw працюють **у процесі** разом із Gateway. Вони не ізольовані в пісочниці. Завантажений нативний Plugin має ту саму межу довіри на рівні процесу, що й код core.
-Наслідки нативних plugins: plugin може реєструвати інструменти, мережеві обробники, хуки й сервіси; помилка plugin може спричинити збій або дестабілізувати gateway; а зловмисний нативний plugin еквівалентний виконанню довільного коду всередині процесу OpenClaw.
+Наслідки нативного Plugin: Plugin може реєструвати інструменти, мережеві обробники, хуки й сервіси; помилка в Plugin може аварійно завершити або дестабілізувати gateway; а шкідливий нативний Plugin еквівалентний виконанню довільного коду всередині процесу OpenClaw.
-Сумісні бандли безпечніші за замовчуванням, тому що OpenClaw наразі розглядає їх як пакети метаданих/контенту. У поточних випусках це здебільшого означає вбудовані skills.
+Сумісні пакети безпечніші за замовчуванням, оскільки OpenClaw наразі розглядає їх як пакети метаданих/контенту. У поточних випусках це переважно означає вбудовані Skills.
-Використовуйте allowlists і явні шляхи встановлення/завантаження для невбудованих plugins. Розглядайте workspace plugins як код часу розробки, а не як production-стандарт.
+Використовуйте allowlist і явні шляхи встановлення/завантаження для невбудованих Plugin. Розглядайте Plugin робочої області як код для часу розробки, а не як продукційні значення за замовчуванням.
-Для імен вбудованих workspace-пакетів прив’язуйте id plugin до npm-імені: `@openclaw/` за замовчуванням або затверджений типізований суфікс, як-от `-provider`, `-plugin`, `-speech`, `-sandbox` чи `-media-understanding`, коли пакет навмисно надає вужчу роль plugin.
+Для імен вбудованих пакетів робочої області тримайте ідентифікатор Plugin прив’язаним до npm-імені: `@openclaw/` за замовчуванням або затверджений типізований суфікс, як-от `-provider`, `-plugin`, `-speech`, `-sandbox` чи `-media-understanding`, коли пакет навмисно надає вужчу роль Plugin.
-**Примітка щодо довіри:** `plugins.allow` довіряє **plugin ids**, а не походженню джерела. Workspace plugin із тим самим id, що й вбудований plugin, навмисно затіняє вбудовану копію, коли цей workspace plugin увімкнено/додано до allowlist. Це нормально й корисно для локальної розробки, тестування патчів і hotfixes. Довіра до вбудованого plugin визначається зі знімка джерела — маніфесту й коду на диску під час завантаження, — а не з метаданих встановлення. Пошкоджений або підмінений запис встановлення не може непомітно розширити поверхню довіри вбудованого plugin понад те, що фактично заявляє джерело.
+**Примітка щодо довіри:** `plugins.allow` довіряє **ідентифікаторам Plugin**, а не походженню джерела. Plugin робочої області з тим самим ідентифікатором, що й вбудований Plugin, навмисно затіняє вбудовану копію, коли цей Plugin робочої області ввімкнено/додано до allowlist. Це нормально й корисно для локальної розробки, тестування патчів і hotfix. Довіра до вбудованого Plugin визначається зі знімка джерела — маніфесту й коду на диску під час завантаження — а не з метаданих встановлення. Пошкоджений або підмінений запис встановлення не може непомітно розширити поверхню довіри вбудованого Plugin за межі того, що заявляє фактичне джерело.
## Межа експорту
OpenClaw експортує можливості, а не зручності реалізації.
-Залишайте реєстрацію можливостей публічною. Скорочуйте експорти helper-функцій, які не є контрактами:
+Залишайте реєстрацію можливостей публічною. Скоротіть експорти допоміжних елементів, що не є контрактами:
-- підшляхи helper-функцій, специфічні для вбудованого plugin
-- підшляхи runtime-інфраструктури, не призначені як публічний API
-- специфічні для постачальника helper-функції для зручності
-- helper-функції налаштування/onboarding, які є деталями реалізації
+- допоміжні subpath, специфічні для вбудованого Plugin
+- subpath інфраструктури часу виконання, не призначені як публічний API
+- зручні допоміжні елементи, специфічні для постачальника
+- допоміжні елементи налаштування/onboarding, що є деталями реалізації
-Зарезервовані підшляхи helper-функцій вбудованих plugins було вилучено зі згенерованої мапи експортів SDK. Тримайте helper-функції, специфічні для власника, всередині пакета plugin-власника; просувайте лише повторно використовувану поведінку хоста до загальних контрактів SDK, як-от `plugin-sdk/gateway-runtime`, `plugin-sdk/security-runtime` і `plugin-sdk/plugin-config-runtime`.
+Зарезервовані допоміжні subpath вбудованого Plugin було вилучено зі згенерованої карти експорту SDK. Тримайте специфічні для власника допоміжні елементи всередині пакета Plugin-власника; підвищуйте лише повторно використовувану поведінку хоста до загальних контрактів SDK, таких як `plugin-sdk/gateway-runtime`, `plugin-sdk/security-runtime` і `plugin-sdk/plugin-config-runtime`.
-## Внутрішні механізми й довідка
+## Внутрішні механізми та довідка
-Про конвеєр завантаження, модель реєстру, runtime-хуки постачальників, HTTP-маршрути Gateway, схеми інструментів повідомлень, визначення цілей каналів, каталоги постачальників, plugins рушія контексту й посібник із додавання нової можливості див. [Внутрішня архітектура plugin](/uk/plugins/architecture-internals).
+Про pipeline завантаження, модель реєстру, runtime hooks провайдерів, HTTP-маршрути Gateway, схеми інструментів повідомлень, визначення цілей каналів, каталоги провайдерів, Plugin рушія контексту та посібник із додавання нової можливості див. [Внутрішні механізми архітектури Plugin](/uk/plugins/architecture-internals).
## Пов’язане
-- [Створення plugins](/uk/plugins/building-plugins)
-- [Маніфест plugin](/uk/plugins/manifest)
+- [Створення Plugin](/uk/plugins/building-plugins)
+- [Маніфест Plugin](/uk/plugins/manifest)
- [Налаштування Plugin SDK](/uk/plugins/sdk-setup)