diff --git a/docs/uk/plugins/architecture.md b/docs/uk/plugins/architecture.md
index cd25a87a8..529c55808 100644
--- a/docs/uk/plugins/architecture.md
+++ b/docs/uk/plugins/architecture.md
@@ -1,6 +1,6 @@
 ---
 read_when:
-    - Створення або налагодження нативних плагінів OpenClaw
+    - Створення або налагодження власних плагінів OpenClaw
     - Розуміння моделі можливостей плагінів або меж володіння
     - Робота над конвеєром завантаження плагінів або реєстром
     - Реалізація хуків середовища виконання провайдера або плагінів каналів
@@ -8,10 +8,10 @@ sidebarTitle: Internals
 summary: 'Внутрішні компоненти плагінів: модель можливостей, володіння, контракти, конвеєр завантаження та допоміжні засоби середовища виконання'
 title: Внутрішні компоненти плагінів
 x-i18n:
-    generated_at: "2026-04-12T02:30:58Z"
+    generated_at: "2026-04-12T08:09:15Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 6165a9da8b40de3bb7334fcb16023da5515deb83c4897ca1df1726f4a97db9e0
+    source_hash: 6f4f8e6bcb14358b3aaa698d03faf456bbeebc04a6d70d1ae6451b02ab17cf09
     source_path: plugins/architecture.md
     workflow: 15
 ---
@@ -20,8 +20,8 @@ x-i18n:
 
 <Info>
   Це **поглиблений довідник з архітектури**. Практичні посібники дивіться тут:
-  - [Встановлення та використання плагінів](/uk/tools/plugin) — посібник для користувачів
-  - [Початок роботи](/uk/plugins/building-plugins) — перший навчальний матеріал зі створення плагіна
+  - [Встановлення та використання плагінів](/uk/tools/plugin) — посібник користувача
+  - [Початок роботи](/uk/plugins/building-plugins) — перший навчальний посібник зі створення плагіна
   - [Плагіни каналів](/uk/plugins/sdk-channel-plugins) — створення каналу обміну повідомленнями
   - [Плагіни провайдерів](/uk/plugins/sdk-provider-plugins) — створення провайдера моделей
   - [Огляд SDK](/uk/plugins/sdk-overview) — карта імпорту та API реєстрації
@@ -31,145 +31,156 @@ x-i18n:
 
 ## Публічна модель можливостей
 
-Можливості — це публічна модель **нативних плагінів** всередині OpenClaw. Кожен
-нативний плагін OpenClaw реєструється для одного або кількох типів можливостей:
+Можливості — це публічна модель **власних плагінів** усередині OpenClaw. Кожен
+власний плагін OpenClaw реєструється для одного або кількох типів можливостей:
 
-| Можливість             | Метод реєстрації                              | Приклади плагінів                    |
-| ---------------------- | --------------------------------------------- | ------------------------------------ |
-| Текстовий висновок     | `api.registerProvider(...)`                   | `openai`, `anthropic`                |
-| Серверна частина висновку 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.registerMusicGenerationProvider(...)`    | `google`, `minimax`                  |
-| Генерація відео        | `api.registerVideoGenerationProvider(...)`    | `qwen`                               |
-| Отримання вебданих     | `api.registerWebFetchProvider(...)`           | `firecrawl`                          |
-| Вебпошук               | `api.registerWebSearchProvider(...)`          | `google`                             |
-| Канал / обмін повідомленнями | `api.registerChannel(...)`              | `msteams`, `matrix`                  |
+| Можливість            | Метод реєстрації                                | Приклади плагінів                    |
+| --------------------- | ----------------------------------------------- | ------------------------------------ |
+| Текстовий висновок    | `api.registerProvider(...)`                     | `openai`, `anthropic`                |
+| Серверна частина 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.registerMusicGenerationProvider(...)`      | `google`, `minimax`                  |
+| Генерація відео       | `api.registerVideoGenerationProvider(...)`      | `qwen`                               |
+| Веботримання          | `api.registerWebFetchProvider(...)`             | `firecrawl`                          |
+| Вебпошук              | `api.registerWebSearchProvider(...)`            | `google`                             |
+| Канал / обмін повідомленнями | `api.registerChannel(...)`                | `msteams`, `matrix`                  |
 
 Плагін, який не реєструє жодної можливості, але надає хуки, інструменти або
-сервіси, є **застарілим плагіном лише з хуками**. Цей шаблон і далі повністю підтримується.
+сервіси, є **застарілим плагіном лише з хуками**. Цей шаблон досі повністю
+підтримується.
 
 ### Позиція щодо зовнішньої сумісності
 
-Модель можливостей уже впроваджена в ядрі та сьогодні використовується
-вбудованими/нативними плагінами, але сумісність із зовнішніми плагінами все ще
-потребує вищої планки, ніж «це експортується, отже це вже незмінний контракт».
+Модель можливостей уже інтегрована в ядро та сьогодні використовується
+вбудованими/власними плагінами, але сумісність зовнішніх плагінів усе ще
+потребує вищої планки, ніж «це експортується, отже це незмінне».
 
 Поточні рекомендації:
 
 - **наявні зовнішні плагіни:** зберігайте працездатність інтеграцій на основі хуків; вважайте це базовим рівнем сумісності
-- **нові вбудовані/нативні плагіни:** надавайте перевагу явній реєстрації можливостей замість vendor-специфічних проникнень усередину або нових дизайнів лише з хуками
-- **зовнішні плагіни, що переходять на реєстрацію можливостей:** це дозволено, але вважайте допоміжні поверхні, специфічні для можливостей, такими, що ще розвиваються, якщо в документації контракт не позначено явно як стабільний
+- **нові вбудовані/власні плагіни:** надавайте перевагу явній реєстрації можливостей замість vendor-specific звернень усередину або нових рішень лише з хуками
+- **зовнішні плагіни, що переходять на реєстрацію можливостей:** це дозволено, але вважайте допоміжні поверхні, специфічні для можливостей, такими, що еволюціонують, якщо в документації контракт явно не позначено як стабільний
 
 Практичне правило:
 
-- API реєстрації можливостей — це бажаний напрям
+- API реєстрації можливостей — це бажаний напрям розвитку
 - застарілі хуки залишаються найбезпечнішим шляхом без порушення сумісності для зовнішніх плагінів під час переходу
-- не всі експортовані допоміжні підшляхи однаково важливі; віддавайте перевагу вузькому задокументованому контракту, а не випадковим допоміжним експортам
+- не всі експортовані допоміжні підшляхи однаково важливі; надавайте перевагу вузькому документованому контракту, а не випадковим експортам допоміжних засобів
 
 ### Форми плагінів
 
-OpenClaw класифікує кожен завантажений плагін за формою на основі його фактичної
-поведінки реєстрації (а не лише статичних метаданих):
+OpenClaw класифікує кожен завантажений плагін за формою на основі його
+фактичної поведінки під час реєстрації (а не лише статичних метаданих):
 
-- **plain-capability** -- реєструє рівно один тип можливості (наприклад, плагін лише провайдера, такий як `mistral`)
-- **hybrid-capability** -- реєструє кілька типів можливостей (наприклад, `openai` володіє текстовим висновком, мовленням, розумінням медіа та генерацією зображень)
-- **hook-only** -- реєструє лише хуки (типізовані або користувацькі), без можливостей, інструментів, команд чи сервісів
-- **non-capability** -- реєструє інструменти, команди, сервіси або маршрути, але не можливості
+- **plain-capability** -- реєструє рівно один тип можливості (наприклад,
+  плагін лише провайдера, як-от `mistral`)
+- **hybrid-capability** -- реєструє кілька типів можливостей (наприклад,
+  `openai` володіє текстовим висновком, мовленням, розумінням медіа та
+  генерацією зображень)
+- **hook-only** -- реєструє лише хуки (типізовані або користувацькі), без
+  можливостей, інструментів, команд або сервісів
+- **non-capability** -- реєструє інструменти, команди, сервіси або маршрути,
+  але не можливості
 
-Використовуйте `openclaw plugins inspect <id>`, щоб побачити форму плагіна та
-розподіл за можливостями. Докладніше дивіться у [довідці CLI](/cli/plugins#inspect).
+Скористайтеся `openclaw plugins inspect <id>`, щоб побачити форму плагіна та
+розподіл його можливостей. Докладніше дивіться в [довіднику CLI](/cli/plugins#inspect).
 
 ### Застарілі хуки
 
-Хук `before_agent_start` і далі підтримується як шлях сумісності для плагінів
-лише з хуками. Від нього все ще залежать застарілі реальні плагіни.
+Хук `before_agent_start` залишається підтримуваним як шлях сумісності для
+плагінів лише з хуками. Реальні застарілі плагіни все ще залежать від нього.
 
 Напрямок:
 
 - зберігати його працездатність
 - документувати його як застарілий
-- надавати перевагу `before_model_resolve` для роботи з перевизначенням моделі/провайдера
-- надавати перевагу `before_prompt_build` для роботи з мутацією промпта
-- видаляти лише після зниження реального використання та підтвердження безпечності міграції покриттям через фікстури
+- для перевизначення моделі/провайдера надавати перевагу `before_model_resolve`
+- для модифікації запиту надавати перевагу `before_prompt_build`
+- видаляти лише після зниження реального використання та коли покриття фікстурами підтвердить безпечність міграції
 
 ### Сигнали сумісності
 
-Коли ви запускаєте `openclaw doctor` або `openclaw plugins inspect <id>`, ви можете побачити
-одну з таких міток:
+Коли ви запускаєте `openclaw doctor` або `openclaw plugins inspect <id>`, ви
+можете побачити одну з цих позначок:
 
-| Сигнал                     | Значення                                                     |
-| -------------------------- | ------------------------------------------------------------ |
-| **config valid**           | Конфігурація успішно розбирається, а плагіни коректно визначаються |
+| Сигнал                    | Значення                                                     |
+| ------------------------- | ------------------------------------------------------------ |
+| **config valid**          | Конфігурація коректно розбирається, і плагіни успішно визначаються |
 | **compatibility advisory** | Плагін використовує підтримуваний, але старіший шаблон (наприклад, `hook-only`) |
-| **legacy warning**         | Плагін використовує `before_agent_start`, який є застарілим  |
-| **hard error**             | Конфігурація недійсна або не вдалося завантажити плагін      |
+| **legacy warning**        | Плагін використовує `before_agent_start`, який є застарілим  |
+| **hard error**            | Конфігурація недійсна або плагін не вдалося завантажити      |
 
-Ані `hook-only`, ані `before_agent_start` сьогодні не зламають ваш плагін --
-`hook-only` є рекомендаційним сигналом, а `before_agent_start` лише спричиняє попередження. Ці
-сигнали також з’являються в `openclaw status --all` і `openclaw plugins doctor`.
+Ні `hook-only`, ні `before_agent_start` сьогодні не зламають ваш плагін --
+`hook-only` має рекомендаційний характер, а `before_agent_start` лише
+спричиняє попередження. Ці сигнали також відображаються в
+`openclaw status --all` і `openclaw plugins doctor`.
 
 ## Огляд архітектури
 
 Система плагінів OpenClaw має чотири шари:
 
 1. **Маніфест + виявлення**
-   OpenClaw знаходить потенційні плагіни в налаштованих шляхах, коренях робочих просторів,
-   глобальних коренях розширень і вбудованих розширеннях. Виявлення спочатку зчитує
-   нативні маніфести `openclaw.plugin.json` разом із підтримуваними маніфестами збірок.
+   OpenClaw знаходить кандидатів у плагіни в налаштованих шляхах, коренях
+   робочих просторів, глобальних коренях розширень і вбудованих розширеннях.
+   Під час виявлення спочатку зчитуються власні маніфести
+   `openclaw.plugin.json` і підтримувані маніфести пакетів.
 2. **Увімкнення + валідація**
-   Ядро визначає, чи виявлений плагін увімкнено, вимкнено, заблоковано, чи
+   Ядро визначає, чи виявлений плагін увімкнено, вимкнено, заблоковано або
    вибрано для ексклюзивного слота, наприклад пам’яті.
-3. **Завантаження під час виконання**
-   Нативні плагіни OpenClaw завантажуються в межах процесу через jiti і реєструють
-   можливості в центральному реєстрі. Сумісні збірки нормалізуються в записи
-   реєстру без імпорту коду середовища виконання.
-4. **Споживання поверхонь**
-   Решта OpenClaw читає реєстр, щоб надавати інструменти, канали, налаштування провайдерів,
-   хуки, HTTP-маршрути, команди CLI та сервіси.
+3. **Завантаження середовища виконання**
+   Власні плагіни OpenClaw завантажуються в межах процесу через jiti і
+   реєструють можливості в центральному реєстрі. Сумісні пакети
+   нормалізуються в записи реєстру без імпорту коду середовища виконання.
+4. **Використання поверхонь**
+   Решта OpenClaw зчитує реєстр, щоб надавати інструменти, канали,
+   налаштування провайдерів, хуки, HTTP-маршрути, команди CLI та сервіси.
 
-Спеціально для CLI плагінів виявлення кореневих команд розділено на дві фази:
+Зокрема для CLI плагінів, виявлення кореневих команд поділяється на дві фази:
 
 - метадані під час розбору надходять із `registerCli(..., { descriptors: [...] })`
 - реальний модуль CLI плагіна може залишатися лінивим і реєструватися під час першого виклику
 
-Це дозволяє зберігати код CLI, що належить плагіну, всередині самого плагіна,
-водночас даючи змогу OpenClaw резервувати імена кореневих команд до початку розбору.
+Це дозволяє зберігати код CLI, що належить плагіну, всередині плагіна, і
+водночас дає OpenClaw змогу резервувати імена кореневих команд до початку
+розбору.
 
-Важлива межа проєктування:
+Важлива межа дизайну:
 
-- виявлення та валідація конфігурації мають працювати з **метаданих маніфесту/схеми**
-  без виконання коду плагіна
-- нативна поведінка під час виконання надходить зі шляху `register(api)` модуля плагіна
+- виявлення + валідація конфігурації мають працювати на основі **метаданих маніфесту/схеми** без виконання коду плагіна
+- власна поведінка середовища виконання походить зі шляху `register(api)` модуля плагіна
 
-Такий поділ дає OpenClaw змогу перевіряти конфігурацію, пояснювати відсутні/вимкнені плагіни та
-будувати підказки для UI/схеми до активації повного середовища виконання.
+Цей поділ дозволяє OpenClaw перевіряти конфігурацію, пояснювати відсутні/вимкнені
+плагіни та будувати підказки для UI/схеми до того, як повне середовище
+виконання стане активним.
 
 ### Плагіни каналів і спільний інструмент повідомлень
 
-Плагінам каналів не потрібно реєструвати окремий інструмент send/edit/react для
-звичайних дій у чаті. OpenClaw підтримує один спільний інструмент `message` у ядрі,
-а плагіни каналів володіють специфічним для каналу виявленням і виконанням за ним.
+Плагінам каналів не потрібно реєструвати окремий інструмент надсилання /
+редагування / реакцій для звичайних дій у чаті. OpenClaw зберігає один спільний
+інструмент `message` у ядрі, а плагіни каналів володіють виявленням і
+виконанням, специфічними для каналу, за його межами.
 
 Поточна межа така:
 
-- ядро володіє хостом спільного інструмента `message`, прив’язкою до промпта, обліком сесій/гілок
-  і диспетчеризацією виконання
-- плагіни каналів володіють виявленням дій в обмеженій області, виявленням можливостей і будь-якими
-  фрагментами схеми, специфічними для каналу
-- плагіни каналів володіють граматикою сесійної розмови, специфічною для провайдера, наприклад тим,
-  як ідентифікатори розмов кодують ідентифікатори гілок або успадковуються від батьківських розмов
-- плагіни каналів виконують кінцеву дію через свій адаптер дій
+- ядро володіє хостом спільного інструмента `message`, підключенням до запитів,
+  обліком сесій/потоків і диспетчеризацією виконання
+- плагіни каналів володіють виявленням дій з урахуванням області видимості,
+  виявленням можливостей і будь-якими фрагментами схеми, специфічними для каналу
+- плагіни каналів володіють граматикою розмов сесій, специфічною для провайдера,
+  наприклад тим, як ідентифікатори розмов кодують ідентифікатори потоків або
+  успадковуються від батьківських розмов
+- плагіни каналів виконують остаточну дію через свій адаптер дій
 
-Для плагінів каналів поверхня SDK — це
+Для плагінів каналів поверхнею SDK є
 `ChannelMessageActionAdapter.describeMessageTool(...)`. Цей уніфікований виклик
-виявлення дає плагіну змогу повертати його видимі дії, можливості та внески в схему
-разом, щоб ці частини не розходилися.
+виявлення дозволяє плагіну повернути видимі дії, можливості та внески у схему
+разом, щоб ці частини не розходилися між собою.
 
-Ядро передає область виконання в цей крок виявлення. Важливі поля включають:
+Ядро передає область виконання в цей крок виявлення. Важливі поля:
 
 - `accountId`
 - `currentChannelId`
@@ -180,124 +191,129 @@ OpenClaw класифікує кожен завантажений плагін 
 - `agentId`
 - довірений вхідний `requesterSenderId`
 
-Це важливо для контекстно-залежних плагінів. Канал може приховувати або показувати
-дії з повідомленнями залежно від активного облікового запису, поточної кімнати/гілки/повідомлення або
-довіреної ідентичності запитувача без жорстко закодованих розгалужень, специфічних для каналу,
-в основному інструменті `message`.
+Це важливо для контекстно-чутливих плагінів. Канал може приховувати або
+показувати дії з повідомленнями залежно від активного облікового запису,
+поточної кімнати/потоку/повідомлення або довіреної ідентичності запитувача без
+жорстко закодованих гілок, специфічних для каналу, в основному інструменті
+`message`.
 
-Саме тому зміни маршрутизації embedded-runner усе ще є роботою плагінів: виконавець
-відповідає за пересилання поточної ідентичності чату/сесії до межі виявлення плагіна, щоб
-спільний інструмент `message` надавав правильну поверхню, що належить каналу,
-для поточного кроку.
+Саме тому зміни маршрутизації embedded-runner усе ще залишаються роботою
+плагіна: runner відповідає за передавання поточної ідентичності чату/сесії до
+межі виявлення плагіна, щоб спільний інструмент `message` відкривав правильну
+поверхню, що належить каналу, для поточного ходу.
 
-Для допоміжних засобів виконання, що належать каналу, вбудовані плагіни мають
-тримати середовище виконання всередині власних модулів розширення. Ядро більше не володіє
-середовищами виконання дій з повідомленнями Discord, Slack, Telegram або WhatsApp у `src/agents/tools`.
-Ми не публікуємо окремі підшляхи `plugin-sdk/*-action-runtime`, і вбудовані
-плагіни мають імпортувати свій локальний код середовища виконання безпосередньо зі своїх
-модулів, що належать розширенню.
+Щодо допоміжних засобів виконання, які належать каналу, вбудовані плагіни мають
+зберігати середовище виконання всередині власних модулів розширення. Ядро більше
+не володіє середовищами виконання дій із повідомленнями Discord, Slack, Telegram
+чи WhatsApp у `src/agents/tools`. Ми не публікуємо окремі підшляхи
+`plugin-sdk/*-action-runtime`, і вбудовані плагіни мають імпортувати власний
+локальний код середовища виконання безпосередньо зі своїх модулів, що належать
+розширенню.
 
-Та сама межа застосовується до іменованих за провайдерами поверхонь SDK загалом: ядро не повинно
-імпортувати зручні барелі, специфічні для каналу, для Slack, Discord, Signal,
-WhatsApp або подібних розширень. Якщо ядру потрібна певна поведінка, воно має або
-використовувати власний барель `api.ts` / `runtime-api.ts` вбудованого плагіна, або
-підняти цю потребу до вузької загальної можливості в спільному SDK.
+Та сама межа застосовується і до іменованих за провайдером швів SDK загалом:
+ядро не повинно імпортувати зручні панелі, специфічні для каналів, для Slack,
+Discord, Signal, WhatsApp або подібних розширень. Якщо ядру потрібна певна
+поведінка, воно має або споживати власну панель `api.ts` / `runtime-api.ts`
+вбудованого плагіна, або винести потребу у вузьку загальну можливість у
+спільному SDK.
 
-Спеціально для опитувань є два шляхи виконання:
+Зокрема для опитувань існують два шляхи виконання:
 
-- `outbound.sendPoll` — це спільна базова лінія для каналів, які відповідають загальній
-  моделі опитувань
-- `actions.handleAction("poll")` — це бажаний шлях для семантики опитувань,
-  специфічної для каналу, або додаткових параметрів опитувань
+- `outbound.sendPoll` — це спільна базова лінія для каналів, які відповідають загальній моделі опитувань
+- `actions.handleAction("poll")` — це бажаний шлях для семантики опитувань, специфічної для каналу, або додаткових параметрів опитування
 
-Тепер ядро відкладає спільний розбір опитувань доти, доки диспетчеризація опитувань плагіна
-не відхилить дію, щоб обробники опитувань, що належать плагіну, могли приймати
-специфічні для каналу поля опитувань без блокування з боку загального розбірника опитувань.
+Тепер ядро відкладає спільний розбір опитувань до моменту, коли диспетчеризація
+опитування плагіна відхилить дію, щоб обробники опитувань, що належать плагіну,
+могли приймати поля опитувань, специфічні для каналу, не блокуючись спочатку
+загальним парсером опитувань.
 
 Повну послідовність запуску дивіться в [Конвеєрі завантаження](#load-pipeline).
 
 ## Модель володіння можливостями
 
-OpenClaw розглядає нативний плагін як межу володіння для **компанії** або
-**функціональності**, а не як набір не пов’язаних між собою інтеграцій.
+OpenClaw розглядає власний плагін як межу володіння для **компанії** або
+**функції**, а не як набір не пов’язаних між собою інтеграцій.
 
-Це означає, що:
+Це означає:
 
 - плагін компанії зазвичай має володіти всіма поверхнями OpenClaw, що стосуються цієї компанії
-- плагін функціональності зазвичай має володіти всією поверхнею цієї функціональності, яку він вводить
-- канали мають споживати спільні можливості ядра, а не довільно повторно реалізовувати
-  поведінку провайдера
+- плагін функції зазвичай має володіти всією поверхнею функції, яку він додає
+- канали мають споживати спільні можливості ядра замість того, щоб наново реалізовувати поведінку провайдера довільним чином
 
 Приклади:
 
-- вбудований плагін `openai` володіє поведінкою провайдера моделей OpenAI та поведінкою OpenAI
-  для мовлення + голосу в реальному часі + розуміння медіа + генерації зображень
-- вбудований плагін `elevenlabs` володіє поведінкою ElevenLabs для мовлення
-- вбудований плагін `microsoft` володіє поведінкою Microsoft для мовлення
-- вбудований плагін `google` володіє поведінкою провайдера моделей Google, а також поведінкою Google
-  для розуміння медіа + генерації зображень + вебпошуку
-- вбудований плагін `firecrawl` володіє поведінкою Firecrawl для отримання вебданих
+- вбудований плагін `openai` володіє поведінкою провайдера моделей OpenAI, а
+  також поведінкою OpenAI для мовлення + голосу в реальному часі + розуміння
+  медіа + генерації зображень
+- вбудований плагін `elevenlabs` володіє поведінкою мовлення ElevenLabs
+- вбудований плагін `microsoft` володіє поведінкою мовлення Microsoft
+- вбудований плагін `google` володіє поведінкою провайдера моделей Google, а
+  також поведінкою Google для розуміння медіа + генерації зображень + вебпошуку
+- вбудований плагін `firecrawl` володіє поведінкою Firecrawl для веботримання
 - вбудовані плагіни `minimax`, `mistral`, `moonshot` і `zai` володіють своїми
   серверними частинами розуміння медіа
-- вбудований плагін `qwen` володіє поведінкою текстового провайдера Qwen, а також
-  поведінкою для розуміння медіа та генерації відео
-- плагін `voice-call` — це плагін функціональності: він володіє транспортом викликів, інструментами,
-  CLI, маршрутами та мостом Twilio media-stream, але споживає спільні можливості мовлення,
-  а також транскрипції в реальному часі і голосу в реальному часі замість прямого імпорту vendor-плагінів
+- вбудований плагін `qwen` володіє поведінкою текстового провайдера Qwen, а
+  також поведінкою розуміння медіа та генерації відео
+- плагін `voice-call` є плагіном функції: він володіє транспортом викликів,
+  інструментами, CLI, маршрутами та мостом медіапотоку Twilio, але споживає
+  спільні можливості мовлення, а також транскрипції в реальному часі і голосу
+  в реальному часі замість безпосереднього імпорту плагінів постачальників
 
 Бажаний кінцевий стан:
 
-- OpenAI розміщується в одному плагіні, навіть якщо він охоплює текстові моделі, мовлення, зображення та
-  майбутнє відео
-- інший постачальник може зробити те саме для своєї власної поверхні
-- канали не зважають на те, який плагін постачальника володіє провайдером; вони споживають
-  спільний контракт можливості, який надає ядро
+- OpenAI розміщується в одному плагіні, навіть якщо він охоплює текстові моделі, мовлення, зображення та майбутнє відео
+- інший постачальник може робити те саме для власної області поверхонь
+- канали не повинні зважати, який плагін постачальника володіє провайдером; вони споживають спільний контракт можливостей, який надає ядро
 
-Ось ключова відмінність:
+Це ключове розрізнення:
 
 - **plugin** = межа володіння
-- **capability** = контракт ядра, який можуть реалізовувати або споживати кілька плагінів
+- **capability** = контракт ядра, який кілька плагінів можуть реалізовувати або споживати
 
-Тому якщо OpenClaw додає нову область, наприклад відео, перше запитання не
-«який провайдер має жорстко закодувати обробку відео?» Перше запитання таке: «який
-контракт можливості відео в ядрі?» Щойно такий контракт з’являється, плагіни постачальників
-можуть реєструватися для нього, а плагіни каналів/функцій можуть його споживати.
+Тож якщо OpenClaw додає нову область, наприклад відео, перше питання не таке:
+«який провайдер має жорстко закодувати обробку відео?» Перше питання таке:
+«який контракт можливості відео має бути в ядрі?» Щойно такий контракт
+з’являється, плагіни постачальників можуть реєструватися для нього, а плагіни
+каналів/функцій можуть його споживати.
 
-Якщо можливість ще не існує, правильний крок зазвичай такий:
+Якщо можливості ще не існує, правильний крок зазвичай такий:
 
 1. визначити відсутню можливість у ядрі
-2. відкрити її через API/середовище виконання плагінів у типізований спосіб
+2. типізовано відкрити її через API/середовище виконання плагінів
 3. під’єднати канали/функції до цієї можливості
-4. дозволити плагінам постачальників реєструвати реалізації
+4. дати плагінам постачальників зареєструвати реалізації
 
-Це робить володіння явним і водночас уникає поведінки ядра, яка залежить від
+Це зберігає явне володіння та водночас уникає поведінки ядра, яка залежить від
 одного постачальника або одноразового шляху коду, специфічного для плагіна.
 
-### Шарування можливостей
+### Нашарування можливостей
 
-Використовуйте цю ментальну модель, коли вирішуєте, де має бути код:
+Використовуйте таку ментальну модель, коли вирішуєте, де має бути код:
 
-- **шар можливостей ядра**: спільна оркестрація, політики, резервні механізми, правила
-  об’єднання конфігурації, семантика доставки та типізовані контракти
-- **шар плагіна постачальника**: API постачальника, автентифікація, каталоги моделей, синтез мовлення,
-  генерація зображень, майбутні серверні частини відео, кінцеві точки використання
-- **шар плагіна каналу/функції**: інтеграція Slack/Discord/voice-call тощо,
-  яка споживає можливості ядра та відображає їх на певній поверхні
+- **рівень можливостей ядра**: спільна оркестрація, політика, резервні
+  варіанти, правила злиття конфігурації, семантика доставки та типізовані
+  контракти
+- **рівень плагінів постачальника**: API, автентифікація, каталоги моделей,
+  синтез мовлення, генерація зображень, майбутні серверні частини для відео,
+  кінцеві точки використання, специфічні для постачальника
+- **рівень плагінів каналів/функцій**: інтеграції Slack/Discord/voice-call
+  тощо, які споживають можливості ядра та подають їх на своїй поверхні
 
 Наприклад, TTS має таку форму:
 
-- ядро володіє політикою TTS під час відповіді, порядком резервування, налаштуваннями та доставкою в канали
+- ядро володіє політикою TTS під час відповіді, порядком резервних варіантів, налаштуваннями та доставкою в канал
 - `openai`, `elevenlabs` і `microsoft` володіють реалізаціями синтезу
-- `voice-call` споживає допоміжний засіб середовища виконання телефонного TTS
+- `voice-call` споживає допоміжний засіб середовища виконання TTS для телефонії
 
-Того самого шаблону слід надавати перевагу й для майбутніх можливостей.
+Для майбутніх можливостей слід надавати перевагу саме такому шаблону.
 
 ### Приклад плагіна компанії з кількома можливостями
 
 Плагін компанії має виглядати цілісно ззовні. Якщо OpenClaw має спільні
-контракти для моделей, мовлення, транскрипції в реальному часі, голосу в реальному часі, розуміння медіа,
-генерації зображень, генерації відео, отримання вебданих і вебпошуку,
-постачальник може володіти всіма своїми поверхнями в одному місці:
+контракти для моделей, мовлення, транскрипції в реальному часі, голосу в
+реальному часі, розуміння медіа, генерації зображень, генерації відео,
+веботримання та вебпошуку, постачальник може володіти всіма своїми поверхнями
+в одному місці:
 
 ```ts
 import type { OpenClawPluginDefinition } from "openclaw/plugin-sdk/plugin-entry";
@@ -356,61 +372,61 @@ export default plugin;
 - один плагін володіє поверхнею постачальника
 - ядро, як і раніше, володіє контрактами можливостей
 - канали та плагіни функцій споживають допоміжні засоби `api.runtime.*`, а не код постачальника
-- контрактні тести можуть перевіряти, що плагін зареєстрував можливості, якими
-  він стверджує, що володіє
+- тести контрактів можуть підтвердити, що плагін зареєстрував можливості, якими, за його твердженням, він володіє
 
 ### Приклад можливості: розуміння відео
 
 OpenClaw уже розглядає розуміння зображень/аудіо/відео як одну спільну
-можливість. Та сама модель володіння застосовується й тут:
+можливість. Тут застосовується та сама модель володіння:
 
-1. ядро визначає контракт media-understanding
+1. ядро визначає контракт розуміння медіа
 2. плагіни постачальників реєструють `describeImage`, `transcribeAudio` і
-   `describeVideo`, де це застосовно
+   `describeVideo`, де це доречно
 3. канали та плагіни функцій споживають спільну поведінку ядра замість
    прямого підключення до коду постачальника
 
-Це не дає вбудувати в ядро припущення одного провайдера щодо відео. Плагін володіє
-поверхнею постачальника; ядро володіє контрактом можливості та резервною поведінкою.
+Це запобігає вбудовуванню в ядро припущень одного провайдера щодо відео.
+Плагін володіє поверхнею постачальника; ядро володіє контрактом можливості та
+поведінкою резервних варіантів.
 
-Генерація відео вже використовує ту саму послідовність: ядро володіє типізованим
-контрактом можливості та допоміжним засобом середовища виконання, а плагіни постачальників реєструють
-реалізації `api.registerVideoGenerationProvider(...)` для цього контракту.
+Генерація відео вже використовує таку саму послідовність: ядро володіє
+типізованим контрактом можливості та допоміжним засобом середовища виконання, а
+плагіни постачальників реєструють реалізації
+`api.registerVideoGenerationProvider(...)` для нього.
 
 Потрібен конкретний контрольний список розгортання? Дивіться
-[Збірник рецептів можливостей](/uk/plugins/architecture).
+[Практичний посібник із можливостей](/uk/plugins/architecture).
 
-## Контракти та контроль
+## Контракти та забезпечення виконання
 
 Поверхня API плагінів навмисно типізована та централізована в
 `OpenClawPluginApi`. Цей контракт визначає підтримувані точки реєстрації та
-допоміжні засоби середовища виконання, на які може покладатися плагін.
+допоміжні засоби середовища виконання, на які може спиратися плагін.
 
 Чому це важливо:
 
 - автори плагінів отримують один стабільний внутрішній стандарт
-- ядро може відхиляти дублювання володіння, наприклад коли два плагіни реєструють однаковий
-  id провайдера
-- під час запуску можна показувати придатні до дії діагностичні повідомлення для хибної реєстрації
-- контрактні тести можуть забезпечувати володіння вбудованих плагінів і запобігати тихому дрейфу
+- ядро може відхиляти дубльоване володіння, наприклад коли два плагіни
+  реєструють один і той самий id провайдера
+- під час запуску можна показати діагностику з чіткими діями для некоректної реєстрації
+- тести контрактів можуть забезпечувати володіння вбудованими плагінами та запобігати тихому дрейфу
 
-Є два рівні контролю:
+Є два рівні забезпечення виконання:
 
-1. **контроль реєстрації під час виконання**
+1. **забезпечення виконання реєстрації під час виконання**
    Реєстр плагінів перевіряє реєстрації під час завантаження плагінів. Приклади:
-   дубльовані id провайдерів, дубльовані id провайдерів мовлення та хибні
-   реєстрації спричиняють діагностику плагінів замість невизначеної поведінки.
-2. **контрактні тести**
-   Вбудовані плагіни фіксуються в контрактних реєстрах під час виконання тестів, щоб
-   OpenClaw міг явно перевіряти володіння. Сьогодні це використовується для
-   провайдерів моделей, провайдерів мовлення, провайдерів вебпошуку та володіння
-   реєстрацією вбудованих плагінів.
+   дубльовані id провайдерів, дубльовані id провайдерів мовлення та
+   некоректні реєстрації створюють діагностику плагіна замість невизначеної поведінки.
+2. **тести контрактів**
+   Вбудовані плагіни фіксуються в реєстрах контрактів під час тестових запусків,
+   щоб OpenClaw міг явно перевіряти володіння. Сьогодні це використовується для
+   провайдерів моделей, провайдерів мовлення, провайдерів вебпошуку та володіння реєстрацією вбудованих плагінів.
 
-Практичний ефект полягає в тому, що OpenClaw наперед знає, який плагін якою
-поверхнею володіє. Це дозволяє ядру та каналам безшовно компонуватися, адже
-володіння оголошене, типізоване й придатне до перевірки, а не неявне.
+Практичний ефект полягає в тому, що OpenClaw заздалегідь знає, який плагін якою
+поверхнею володіє. Це дозволяє ядру й каналам безшовно компонуватися, оскільки
+володіння оголошене, типізоване й придатне до тестування, а не неявне.
 
-### Що має належати контракту
+### Що має входити до контракту
 
 Хороші контракти плагінів:
 
@@ -418,166 +434,179 @@ OpenClaw уже розглядає розуміння зображень/ауд
 - невеликі
 - специфічні для можливості
 - належать ядру
-- придатні до повторного використання кількома плагінами
-- можуть споживатися каналами/функціями без знання постачальника
+- повторно використовуються кількома плагінами
+- споживаються каналами/функціями без знання про постачальника
 
 Погані контракти плагінів:
 
 - політика, специфічна для постачальника, прихована в ядрі
-- одноразові аварійні виходи для плагіна, які обходять реєстр
-- код каналу, який напряму звертається до реалізації постачальника
-- довільні об’єкти середовища виконання, які не є частиною `OpenClawPluginApi` або
-  `api.runtime`
+- одноразові лазівки для плагіна, які обходять реєстр
+- код каналу, що напряму звертається до реалізації постачальника
+- довільні об’єкти середовища виконання, які не є частиною `OpenClawPluginApi` або `api.runtime`
 
-Якщо сумніваєтеся, підніміть рівень абстракції: спочатку визначте можливість, а вже потім
-дозвольте плагінам підключатися до неї.
+Якщо є сумніви, підніміть рівень абстракції: спочатку визначте можливість, а
+потім дайте плагінам підключатися до неї.
 
 ## Модель виконання
 
-Нативні плагіни OpenClaw працюють **у межах процесу** разом із Gateway. Вони не
-ізольовані. Завантажений нативний плагін має ту саму межу довіри на рівні процесу, що
-й код ядра.
+Власні плагіни OpenClaw працюють **у межах процесу** разом із Gateway. Вони не
+ізольовані. Завантажений власний плагін має ту саму межу довіри на рівні
+процесу, що й код ядра.
 
 Наслідки:
 
-- нативний плагін може реєструвати інструменти, мережеві обробники, хуки та сервіси
-- помилка нативного плагіна може аварійно завершити роботу gateway або дестабілізувати його
-- зловмисний нативний плагін еквівалентний довільному виконанню коду всередині
-  процесу OpenClaw
+- власний плагін може реєструвати інструменти, мережеві обробники, хуки та сервіси
+- помилка у власному плагіні може призвести до збою або дестабілізації gateway
+- зловмисний власний плагін еквівалентний довільному виконанню коду всередині процесу OpenClaw
 
-Сумісні збірки безпечніші за замовчуванням, оскільки OpenClaw наразі розглядає їх
-як пакети метаданих/контенту. У поточних випусках це здебільшого означає
+Сумісні пакети за замовчуванням безпечніші, оскільки OpenClaw наразі розглядає
+їх як пакети метаданих/контенту. У поточних випусках це здебільшого означає
 вбудовані Skills.
 
-Використовуйте списки дозволу та явні шляхи встановлення/завантаження для невбудованих плагінів. Розглядайте
-плагіни робочого простору як код для часу розробки, а не як типовий варіант для продакшну.
+Для невбудованих плагінів використовуйте allowlist-и та явні шляхи
+встановлення/завантаження. Розглядайте плагіни робочого простору як код для
+етапу розробки, а не як виробничі значення за замовчуванням.
 
-Для назв пакетів вбудованого робочого простору тримайте id плагіна прив’язаним у npm-назві:
-`@openclaw/<id>` за замовчуванням або схвалений типізований суфікс, такий як
-`-provider`, `-plugin`, `-speech`, `-sandbox` чи `-media-understanding`, коли
-пакет навмисно відкриває вужчу роль плагіна.
+Для імен пакетів вбудованого робочого простору тримайте id плагіна прив’язаним
+до імені npm: за замовчуванням `@openclaw/<id>` або зі схваленим типізованим
+суфіксом, таким як `-provider`, `-plugin`, `-speech`, `-sandbox` або
+`-media-understanding`, коли пакет навмисно відкриває вужчу роль плагіна.
 
-Важлива примітка про довіру:
+Важлива примітка щодо довіри:
 
 - `plugins.allow` довіряє **id плагінів**, а не походженню джерела.
-- Плагін робочого простору з тим самим id, що й у вбудованого плагіна, навмисно затіняє
-  вбудовану копію, коли цей плагін робочого простору увімкнено/додано до списку дозволу.
-- Це нормально й корисно для локальної розробки, тестування патчів та термінових виправлень.
+- Плагін робочого простору з тим самим id, що й у вбудованого плагіна,
+  навмисно затіняє вбудовану копію, коли цей плагін робочого простору увімкнено/додано до allowlist.
+- Це нормально та корисно для локальної розробки, тестування виправлень і hotfix-ів.
 
 ## Межа експорту
 
-OpenClaw експортує можливості, а не зручні засоби реалізації.
+OpenClaw експортує можливості, а не зручні реалізації.
 
-Тримайте реєстрацію можливостей публічною. Скорочуйте експорти допоміжних засобів, які не є контрактами:
+Зберігайте реєстрацію можливостей публічною. Скорочуйте експорти допоміжних
+засобів, які не є контрактними:
 
-- підшляхи допоміжних засобів, специфічні для вбудованих плагінів
+- підшляхи допоміжних засобів, специфічні для вбудованого плагіна
 - підшляхи інфраструктури середовища виконання, не призначені як публічний API
-- зручні засоби, специфічні для постачальника
+- зручні допоміжні засоби, специфічні для постачальника
 - допоміжні засоби налаштування/онбордингу, які є деталями реалізації
 
-Деякі підшляхи допоміжних засобів вбудованих плагінів усе ще залишаються в згенерованій
-карті експорту SDK задля сумісності та підтримки вбудованих плагінів. Поточні приклади:
-`plugin-sdk/feishu`, `plugin-sdk/feishu-setup`, `plugin-sdk/zalo`,
-`plugin-sdk/zalo-setup` і кілька меж `plugin-sdk/matrix*`. Розглядайте їх як
-зарезервовані експорти деталей реалізації, а не як рекомендований шаблон SDK для
-нових сторонніх плагінів.
+Деякі підшляхи допоміжних засобів вбудованих плагінів усе ще залишаються в
+згенерованій карті експорту SDK для сумісності та супроводу вбудованих
+плагінів. Поточні приклади включають `plugin-sdk/feishu`,
+`plugin-sdk/feishu-setup`, `plugin-sdk/zalo`, `plugin-sdk/zalo-setup` і
+кілька швів `plugin-sdk/matrix*`. Розглядайте їх як зарезервовані експорти
+деталей реалізації, а не як рекомендований шаблон SDK для нових сторонніх
+плагінів.
 
 ## Конвеєр завантаження
 
 Під час запуску OpenClaw приблизно робить таке:
 
 1. виявляє корені кандидатів у плагіни
-2. читає нативні маніфести або маніфести сумісних збірок і метадані пакетів
+2. зчитує власні маніфести або маніфести сумісних пакетів і метадані пакетів
 3. відхиляє небезпечних кандидатів
 4. нормалізує конфігурацію плагінів (`plugins.enabled`, `allow`, `deny`, `entries`,
    `slots`, `load.paths`)
-5. вирішує питання увімкнення для кожного кандидата
-6. завантажує увімкнені нативні модулі через jiti
-7. викликає нативні хуки `register(api)` (або `activate(api)` — застарілий псевдонім) і збирає реєстрації в реєстр плагінів
-8. відкриває реєстр для поверхонь команд/середовища виконання
+5. визначає стан увімкнення для кожного кандидата
+6. завантажує увімкнені власні модулі через jiti
+7. викликає власні хуки `register(api)` (або `activate(api)` — застарілий псевдонім) і збирає реєстрації до реєстру плагінів
+8. відкриває реєстр для команд/поверхонь середовища виконання
 
 <Note>
-`activate` — це застарілий псевдонім для `register` — завантажувач визначає, який із них присутній (`def.register ?? def.activate`), і викликає його в тій самій точці. Усі вбудовані плагіни використовують `register`; для нових плагінів надавайте перевагу `register`.
+`activate` — це застарілий псевдонім для `register` — завантажувач визначає, що саме присутнє (`def.register ?? def.activate`), і викликає це в тій самій точці. Усі вбудовані плагіни використовують `register`; для нових плагінів надавайте перевагу `register`.
 </Note>
 
-Перевірки безпеки відбуваються **до** виконання коду під час виконання. Кандидати блокуються,
-коли точка входу виходить за межі кореня плагіна, шлях доступний на запис для всіх або
-право власності на шлях виглядає підозрілим для невбудованих плагінів.
+Перевірки безпеки відбуваються **до** виконання середовища виконання. Кандидати
+блокуються, якщо точка входу виходить за межі кореня плагіна, шлях доступний
+для запису всім користувачам або володіння шляхом виглядає підозрілим для
+невбудованих плагінів.
 
 ### Поведінка з пріоритетом маніфесту
 
-Маніфест є джерелом істини для керівної площини. OpenClaw використовує його, щоб:
+Маніфест — це джерело істини для control plane. OpenClaw використовує його, щоб:
 
 - ідентифікувати плагін
-- виявляти оголошені канали/Skills/схему конфігурації або можливості збірки
+- виявляти оголошені канали/Skills/схему конфігурації або можливості пакетів
 - перевіряти `plugins.entries.<id>.config`
-- доповнювати мітки/заповнювачі в Control UI
+- доповнювати мітки/заповнювачі Control UI
 - показувати метадані встановлення/каталогу
-- зберігати легкі дескриптори активації та налаштування без завантаження середовища виконання плагіна
+- зберігати дешеві дескриптори активації та налаштування без завантаження середовища виконання плагіна
 
-Для нативних плагінів модуль середовища виконання є частиною площини даних. Він реєструє
-фактичну поведінку, таку як хуки, інструменти, команди або потоки провайдера.
+Для власних плагінів модуль середовища виконання є частиною data plane. Він
+реєструє фактичну поведінку, таку як хуки, інструменти, команди або потоки
+провайдерів.
 
-Необов’язкові блоки маніфесту `activation` і `setup` залишаються в керівній площині.
-Це лише дескриптори метаданих для планування активації та виявлення налаштування;
-вони не замінюють реєстрацію під час виконання, `register(...)` або `setupEntry`.
+Необов’язкові блоки маніфесту `activation` і `setup` залишаються в control plane.
+Це дескриптори лише з метаданими для планування активації та виявлення
+налаштування; вони не замінюють реєстрацію середовища виконання,
+`register(...)` або `setupEntry`.
+Перший споживач активації тепер використовує підказки команд із маніфесту, щоб
+звузити завантаження плагінів CLI, коли відома основна команда, замість того,
+щоб завжди наперед завантажувати кожен плагін із підтримкою CLI.
 
-Тепер виявлення налаштування віддає перевагу id, що належать дескрипторам, таким як
-`setup.providers` і `setup.cliBackends`, щоб звузити коло кандидатів у плагіни до того, як воно повернеться до
-`setup-api` для плагінів, яким усе ще потрібні хуки середовища виконання на етапі налаштування. Якщо більше
-ніж один виявлений плагін заявляє той самий нормалізований id провайдера налаштування або серверної частини CLI,
-пошук налаштування відхиляє неоднозначного власника замість того, щоб покладатися на порядок виявлення.
+Виявлення налаштування тепер надає перевагу id, що належать дескрипторам, як-от
+`setup.providers` і `setup.cliBackends`, щоб звузити коло кандидатів у плагіни,
+перш ніж повертатися до `setup-api` для плагінів, яким усе ще потрібні хуки
+середовища виконання під час налаштування. Якщо більше ніж один виявлений
+плагін заявляє про один і той самий нормалізований id провайдера налаштування
+або серверної частини CLI, пошук налаштування відмовляється від неоднозначного
+власника замість того, щоб покладатися на порядок виявлення.
 
 ### Що кешує завантажувач
 
-OpenClaw підтримує короткоживучі кеші в межах процесу для:
+OpenClaw зберігає короткоживучі кеші в межах процесу для:
 
 - результатів виявлення
 - даних реєстру маніфестів
-- реєстрів завантажених плагінів
+- завантажених реєстрів плагінів
 
-Ці кеші зменшують стрибкоподібне навантаження під час запуску та накладні витрати від повторних команд. Їх безпечно
-розглядати як короткоживучі кеші продуктивності, а не як механізм збереження стану.
+Ці кеші зменшують навантаження від імпульсних запусків і повторних команд. Їх
+можна безпечно сприймати як короткоживучі кеші продуктивності, а не як
+постійне сховище.
 
 Примітка щодо продуктивності:
 
 - Установіть `OPENCLAW_DISABLE_PLUGIN_DISCOVERY_CACHE=1` або
   `OPENCLAW_DISABLE_PLUGIN_MANIFEST_CACHE=1`, щоб вимкнути ці кеші.
-- Налаштовуйте вікна кешу через `OPENCLAW_PLUGIN_DISCOVERY_CACHE_MS` і
+- Налаштовуйте вікна кешування за допомогою `OPENCLAW_PLUGIN_DISCOVERY_CACHE_MS` і
   `OPENCLAW_PLUGIN_MANIFEST_CACHE_MS`.
 
 ## Модель реєстру
 
-Завантажені плагіни не змінюють напряму випадкові глобальні об’єкти ядра. Вони реєструються в
-центральному реєстрі плагінів.
+Завантажені плагіни не змінюють напряму довільні глобальні об’єкти ядра. Вони
+реєструються в центральному реєстрі плагінів.
 
 Реєстр відстежує:
 
-- записи плагінів (ідентичність, джерело, походження, статус, діагностика)
+- записи плагінів (ідентичність, джерело, походження, стан, діагностика)
 - інструменти
 - застарілі хуки та типізовані хуки
 - канали
-- провайдерів
+- провайдери
 - обробники Gateway RPC
 - HTTP-маршрути
 - реєстратори CLI
 - фонові сервіси
-- команди, що належать плагіну
+- команди, що належать плагінам
 
-Після цього можливості ядра читають із цього реєстру замість прямої взаємодії з модулями плагінів.
-Це зберігає завантаження односпрямованим:
+Потім функції ядра зчитують дані з цього реєстру замість безпосереднього
+звернення до модулів плагінів. Це зберігає завантаження односпрямованим:
 
 - модуль плагіна -> реєстрація в реєстрі
-- середовище виконання ядра -> споживання з реєстру
+- середовище виконання ядра -> споживання реєстру
 
-Це розділення важливе для підтримуваності. Воно означає, що більшості поверхонь ядра
-потрібна лише одна точка інтеграції: «читати реєстр», а не «робити окремий випадок для кожного модуля плагіна».
+Це розділення важливе для підтримуваності. Воно означає, що більшості поверхонь
+ядра потрібна лише одна точка інтеграції: «зчитати реєстр», а не
+«створити спеціальний випадок для кожного модуля плагіна».
 
-## Зворотні виклики прив’язки розмови
+## Колбеки прив’язування розмов
 
-Плагіни, які прив’язують розмову, можуть реагувати, коли схвалення вирішено.
+Плагіни, які прив’язують розмову, можуть реагувати, коли погодження
+врегульовано.
 
-Використовуйте `api.onConversationBindingResolved(...)`, щоб отримувати зворотний виклик після того, як запит на прив’язку схвалено або відхилено:
+Використовуйте `api.onConversationBindingResolved(...)`, щоб отримати колбек
+після схвалення або відхилення запиту на прив’язування:
 
 ```ts
 export default {
@@ -597,27 +626,28 @@ export default {
 };
 ```
 
-Поля корисного навантаження зворотного виклику:
+Поля корисного навантаження колбека:
 
 - `status`: `"approved"` або `"denied"`
 - `decision`: `"allow-once"`, `"allow-always"` або `"deny"`
-- `binding`: визначена прив’язка для схвалених запитів
-- `request`: підсумок початкового запиту, підказка від’єднання, id відправника та
-  метадані розмови
+- `binding`: визначене прив’язування для схвалених запитів
+- `request`: підсумок початкового запиту, підказка від’єднання, id відправника
+  та метадані розмови
 
-Цей зворотний виклик є лише сповіщенням. Він не змінює того, кому дозволено прив’язувати
-розмову, і виконується після завершення обробки схвалення ядром.
+Цей колбек призначений лише для сповіщення. Він не змінює того, кому дозволено
+прив’язувати розмову, і виконується після завершення обробки схвалення ядром.
 
 ## Хуки середовища виконання провайдера
 
 Плагіни провайдерів тепер мають два шари:
 
 - метадані маніфесту: `providerAuthEnvVars` для дешевого пошуку env-автентифікації провайдера
-  до завантаження середовища виконання, `providerAuthAliases` для варіантів провайдера, які спільно використовують
-  автентифікацію, `channelEnvVars` для дешевого пошуку env/налаштування каналу до
-  завантаження середовища виконання, а також `providerAuthChoices` для дешевих міток вибору онбордингу/автентифікації та
-  метаданих прапорців CLI до завантаження середовища виконання
-- хуки часу конфігурації: `catalog` / застарілий `discovery` плюс `applyConfigDefaults`
+  до завантаження середовища виконання, `providerAuthAliases` для варіантів
+  провайдера, які використовують спільну автентифікацію, `channelEnvVars` для
+  дешевого пошуку env/налаштування каналу до завантаження середовища виконання,
+  а також `providerAuthChoices` для дешевих міток онбордингу/вибору
+  автентифікації та метаданих прапорців CLI до завантаження середовища виконання
+- хуки під час налаштування конфігурації: `catalog` / застарілий `discovery` та `applyConfigDefaults`
 - хуки середовища виконання: `normalizeModelId`, `normalizeTransport`,
   `normalizeConfig`,
   `applyNativeStreamingUsageCompat`, `resolveConfigApiKey`,
@@ -638,88 +668,96 @@ export default {
   `buildReplayPolicy`,
   `sanitizeReplayHistory`, `validateReplayTurns`, `onModelSelected`
 
-OpenClaw, як і раніше, володіє загальним циклом агента, failover, обробкою транскриптів і
-політикою інструментів. Ці хуки є поверхнею розширення для специфічної для провайдера поведінки без
-потреби в повністю власному транспорті висновку.
+OpenClaw, як і раніше, володіє загальним циклом агента, перемиканням на
+резервний варіант, обробкою транскриптів і політикою інструментів. Ці хуки є
+поверхнею розширення для поведінки, специфічної для провайдера, без потреби в
+повністю власному транспорті висновку.
 
-Використовуйте `providerAuthEnvVars` у маніфесті, коли провайдер має облікові дані на основі env,
-які загальні шляхи автентифікації/стану/вибору моделі мають бачити без завантаження середовища виконання плагіна.
-Використовуйте `providerAuthAliases` у маніфесті, коли один id провайдера має повторно використовувати
-env-змінні, профілі автентифікації, автентифікацію на основі конфігурації та варіант онбордингу API-ключа
-іншого id провайдера. Використовуйте `providerAuthChoices` у маніфесті, коли поверхні CLI
-для онбордингу/вибору автентифікації мають знати id вибору провайдера, мітки груп і просту
-схему автентифікації з одним прапорцем без завантаження середовища виконання провайдера. Зберігайте
-`envVars` у середовищі виконання провайдера для підказок, орієнтованих на оператора, таких як мітки онбордингу або
-змінні налаштування `client-id`/`client-secret` для OAuth.
+Використовуйте `providerAuthEnvVars` у маніфесті, коли провайдер має облікові
+дані на основі env, які загальні шляхи автентифікації/статусу/вибору моделі
+повинні бачити без завантаження середовища виконання плагіна. Використовуйте
+`providerAuthAliases` у маніфесті, коли один id провайдера має повторно
+використовувати env-змінні, профілі автентифікації, автентифікацію на основі
+конфігурації та варіант онбордингу API-ключа іншого id провайдера.
+Використовуйте `providerAuthChoices` у маніфесті, коли поверхні CLI для
+онбордингу/вибору автентифікації мають знати id варіанта провайдера, мітки
+груп і просту схему автентифікації з одним прапорцем без завантаження
+середовища виконання провайдера. Зберігайте `envVars` у середовищі виконання
+провайдера для підказок для операторів, таких як мітки онбордингу або змінні
+налаштування OAuth client-id/client-secret.
 
-Використовуйте `channelEnvVars` у маніфесті, коли канал має автентифікацію або налаштування, керовані env,
-які загальний резервний механізм shell-env, перевірки конфігурації/стану або запити налаштування
-мають бачити без завантаження середовища виконання каналу.
+Використовуйте `channelEnvVars` у маніфесті, коли канал має автентифікацію або
+налаштування, керовані через env, які загальний резервний механізм shell-env,
+перевірки config/status або підказки налаштування повинні бачити без
+завантаження середовища виконання каналу.
 
 ### Порядок хуків і використання
 
-Для плагінів моделей/провайдерів OpenClaw викликає хуки приблизно в такому порядку.
-Стовпець «Коли використовувати» — це короткий посібник для вибору.
+Для плагінів моделі/провайдера OpenClaw викликає хуки приблизно в такому
+порядку.
+Стовпець «Коли використовувати» — це короткий посібник для прийняття рішень.
 
-| #   | Хук                               | Що він робить                                                                                                  | Коли використовувати                                                                                                                        |
-| --- | --------------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
-| 1   | `catalog`                         | Публікує конфігурацію провайдера в `models.providers` під час генерації `models.json`                          | Провайдер володіє каталогом або стандартними значеннями `base URL`                                                                          |
-| 2   | `applyConfigDefaults`             | Застосовує глобальні стандартні значення конфігурації, що належать провайдеру, під час матеріалізації конфігурації | Стандартні значення залежать від режиму автентифікації, env або семантики сімейства моделей провайдера                                    |
-| --  | _(пошук вбудованої моделі)_       | OpenClaw спочатку намагається використати звичайний шлях реєстру/каталогу                                      | _(це не хук плагіна)_                                                                                                                       |
-| 3   | `normalizeModelId`                | Нормалізує застарілі або preview-псевдоніми `model-id` перед пошуком                                           | Провайдер володіє очищенням псевдонімів до канонічного визначення моделі                                                                    |
-| 4   | `normalizeTransport`              | Нормалізує `api` / `baseUrl` сімейства провайдера перед загальним збиранням моделі                             | Провайдер володіє очищенням транспорту для користувацьких id провайдерів у тій самій транспортній сім’ї                                    |
-| 5   | `normalizeConfig`                 | Нормалізує `models.providers.<id>` перед визначенням середовища виконання/провайдера                           | Провайдеру потрібне очищення конфігурації, яке має жити разом із плагіном; вбудовані допоміжні засоби сімейства Google також страхують підтримувані записи конфігурації Google |
-| 6   | `applyNativeStreamingUsageCompat` | Застосовує сумісні переписування native streaming-usage до конфігурації провайдерів                            | Провайдеру потрібні виправлення метаданих native streaming usage, керовані кінцевими точками                                                |
-| 7   | `resolveConfigApiKey`             | Визначає env-marker-автентифікацію для конфігураційних провайдерів до завантаження автентифікації середовища виконання | Провайдер має власне визначення API-ключа через env-marker; `amazon-bedrock` також має тут вбудований визначник AWS env-marker            |
-| 8   | `resolveSyntheticAuth`            | Виводить локальну/self-hosted або основану на конфігурації автентифікацію без збереження відкритого тексту     | Провайдер може працювати із синтетичним/локальним маркером облікових даних                                                                   |
-| 9   | `resolveExternalAuthProfiles`     | Накладає зовнішні профілі автентифікації, що належать провайдеру; стандартне `persistence` — `runtime-only` для облікових даних, що належать CLI/застосунку | Провайдер повторно використовує облікові дані зовнішньої автентифікації без збереження скопійованих refresh token                         |
-| 10  | `shouldDeferSyntheticProfileAuth` | Знижує пріоритет збережених синтетичних заповнювачів профілів порівняно з env/конфігураційною автентифікацією  | Провайдер зберігає синтетичні профілі-заповнювачі, які не повинні мати вищий пріоритет                                                     |
-| 11  | `resolveDynamicModel`             | Синхронний резервний механізм для id моделей, що належать провайдеру, яких ще немає в локальному реєстрі       | Провайдер приймає довільні id моделей верхнього рівня                                                                                        |
-| 12  | `prepareDynamicModel`             | Асинхронний прогрів, після чого `resolveDynamicModel` запускається знову                                        | Провайдеру потрібні мережеві метадані перед визначенням невідомих id                                                                         |
-| 13  | `normalizeResolvedModel`          | Остаточне переписування перед тим, як embedded runner використовує визначену модель                             | Провайдеру потрібні переписування транспорту, але він усе ще використовує транспорт ядра                                                   |
-| 14  | `contributeResolvedModelCompat`   | Додає прапорці сумісності для моделей постачальника за іншим сумісним транспортом                              | Провайдер розпізнає власні моделі на проксі-транспорті, не перехоплюючи самого провайдера                                                  |
-| 15  | `capabilities`                    | Метадані транскриптів/інструментів, що належать провайдеру та використовуються спільною логікою ядра           | Провайдеру потрібні особливості транскриптів/сімейства провайдера                                                                            |
-| 16  | `normalizeToolSchemas`            | Нормалізує схеми інструментів перед тим, як їх побачить embedded runner                                         | Провайдеру потрібне очищення схем для транспортної сім’ї                                                                                     |
-| 17  | `inspectToolSchemas`              | Виводить діагностику схем, що належить провайдеру, після нормалізації                                           | Провайдер хоче отримувати попередження щодо ключових слів без навчання ядра правилам, специфічним для провайдера                          |
-| 18  | `resolveReasoningOutputMode`      | Вибирає native або tagged-контракт виводу reasoning                                                            | Провайдеру потрібен tagged reasoning/final output замість native-полів                                                                       |
-| 19  | `prepareExtraParams`              | Нормалізація параметрів запиту перед загальними обгортками параметрів потоку                                    | Провайдеру потрібні стандартні параметри запиту або очищення параметрів для конкретного провайдера                                         |
-| 20  | `createStreamFn`                  | Повністю замінює звичайний шлях потоку власним транспортом                                                     | Провайдеру потрібен власний wire protocol, а не просто обгортка                                                                              |
-| 21  | `wrapStreamFn`                    | Обгортка потоку після застосування загальних обгорток                                                          | Провайдеру потрібні обгортки сумісності для заголовків/тіла/моделі запиту без власного транспорту                                          |
-| 22  | `resolveTransportTurnState`       | Прикріплює native-заголовки або метадані транспорту для кожного кроку                                          | Провайдер хоче, щоб загальні транспорти надсилали native-ідентичність кроку провайдера                                                     |
-| 23  | `resolveWebSocketSessionPolicy`   | Прикріплює native-заголовки WebSocket або політику охолодження сесії                                           | Провайдер хоче, щоб загальні WS-транспорти налаштовували заголовки сесії або резервну політику                                            |
-| 24  | `formatApiKey`                    | Форматувальник профілю автентифікації: збережений профіль стає рядком `apiKey` у середовищі виконання         | Провайдер зберігає додаткові метадані автентифікації та потребує власної форми токена під час виконання                                    |
-| 25  | `refreshOAuth`                    | Перевизначення оновлення OAuth для користувацьких кінцевих точок оновлення або політики помилки оновлення      | Провайдер не відповідає спільним засобам оновлення `pi-ai`                                                                                  |
-| 26  | `buildAuthDoctorHint`             | Підказка виправлення, яка додається, коли оновлення OAuth завершується помилкою                                 | Провайдеру потрібні власні вказівки щодо виправлення автентифікації після збою оновлення                                                   |
-| 27  | `matchesContextOverflowError`     | Засіб зіставлення переповнення вікна контексту, що належить провайдеру                                         | Провайдер має сирі помилки переповнення, які не помітять загальні евристики                                                                 |
-| 28  | `classifyFailoverReason`          | Класифікація причин failover, що належить провайдеру                                                           | Провайдер може зіставляти сирі помилки API/транспорту з rate-limit/перевантаженням тощо                                                   |
-| 29  | `isCacheTtlEligible`              | Політика prompt-cache для проксі/backhaul-провайдерів                                                          | Провайдеру потрібне керування TTL кешу, специфічне для проксі                                                                               |
-| 30  | `buildMissingAuthMessage`         | Заміна загального повідомлення відновлення для відсутньої автентифікації                                       | Провайдеру потрібна власна підказка відновлення для відсутньої автентифікації                                                               |
-| 31  | `suppressBuiltInModel`            | Приховування застарілих моделей верхнього рівня плюс необов’язкова підказка помилки для користувача           | Провайдеру потрібно приховати застарілі рядки верхнього рівня або замінити їх підказкою постачальника                                      |
-| 32  | `augmentModelCatalog`             | Синтетичні/підсумкові рядки каталогу, додані після виявлення                                                   | Провайдеру потрібні синтетичні рядки прямої сумісності в `models list` і засобах вибору                                                   |
-| 33  | `isBinaryThinking`                | Перемикач reasoning увімк./вимк. для провайдерів із двійковим thinking                                         | Провайдер надає лише двійковий режим thinking увімк./вимк.                                                                                  |
-| 34  | `supportsXHighThinking`           | Підтримка reasoning `xhigh` для вибраних моделей                                                               | Провайдер хоче `xhigh` лише для підмножини моделей                                                                                          |
-| 35  | `resolveDefaultThinkingLevel`     | Стандартний рівень `/think` для конкретного сімейства моделей                                                  | Провайдер володіє стандартною політикою `/think` для сімейства моделей                                                                      |
-| 36  | `isModernModelRef`                | Засіб зіставлення modern-model для фільтрів live profile і вибору smoke                                        | Провайдер володіє зіставленням бажаних моделей для live/smoke                                                                               |
-| 37  | `prepareRuntimeAuth`              | Обмінює налаштовані облікові дані на фактичний токен/ключ середовища виконання безпосередньо перед висновком  | Провайдеру потрібен обмін токена або короткоживучі облікові дані запиту                                                                     |
+| #   | Хук                               | Що він робить                                                                                                   | Коли використовувати                                                                                                                        |
+| --- | --------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
+| 1   | `catalog`                         | Публікує конфігурацію провайдера в `models.providers` під час генерації `models.json`                           | Провайдер володіє каталогом або базовими значеннями `base URL`                                                                              |
+| 2   | `applyConfigDefaults`             | Застосовує глобальні значення конфігурації за замовчуванням, що належать провайдеру, під час матеріалізації конфігурації | Значення за замовчуванням залежать від режиму автентифікації, env або семантики сімейства моделей провайдера                               |
+| --  | _(built-in model lookup)_         | OpenClaw спочатку намагається використати звичайний шлях через реєстр/каталог                                   | _(не є хуком плагіна)_                                                                                                                      |
+| 3   | `normalizeModelId`                | Нормалізує застарілі або preview-псевдоніми id моделей перед пошуком                                            | Провайдер володіє очищенням псевдонімів до канонічного визначення моделі                                                                    |
+| 4   | `normalizeTransport`              | Нормалізує `api` / `baseUrl` для сімейства провайдера перед загальним складанням моделі                         | Провайдер володіє очищенням транспорту для власних id провайдерів у межах того самого сімейства транспорту                                 |
+| 5   | `normalizeConfig`                 | Нормалізує `models.providers.<id>` перед визначенням середовища виконання/провайдера                            | Провайдеру потрібне очищення конфігурації, яке має жити разом із плагіном; вбудовані допоміжні засоби сімейства Google також страхують підтримувані записи конфігурації Google |
+| 6   | `applyNativeStreamingUsageCompat` | Застосовує переписування сумісності використання нативного потокового режиму до провайдерів конфігурації        | Провайдеру потрібні виправлення метаданих використання нативного потокового режиму, що залежать від кінцевої точки                         |
+| 7   | `resolveConfigApiKey`             | Визначає автентифікацію env-marker для провайдерів конфігурації до завантаження автентифікації середовища виконання | Провайдер має власне визначення API-ключа env-marker; `amazon-bedrock` також має тут вбудований резолвер AWS env-marker                   |
+| 8   | `resolveSyntheticAuth`            | Виводить локальну/self-hosted або засновану на конфігурації автентифікацію без збереження відкритого тексту    | Провайдер може працювати із синтетичним/локальним маркером облікових даних                                                                 |
+| 9   | `resolveExternalAuthProfiles`     | Накладає зовнішні профілі автентифікації, що належать провайдеру; значення `persistence` за замовчуванням — `runtime-only` для облікових даних, що належать CLI/застосунку | Провайдер повторно використовує облікові дані зовнішньої автентифікації без збереження скопійованих refresh token-ів                      |
+| 10  | `shouldDeferSyntheticProfileAuth` | Знижує пріоритет збережених синтетичних заповнювачів профілю порівняно з автентифікацією на основі env/конфігурації | Провайдер зберігає синтетичні профілі-заповнювачі, які не повинні мати вищий пріоритет                                                     |
+| 11  | `resolveDynamicModel`             | Синхронний резервний варіант для id моделей, що належать провайдеру, яких ще немає в локальному реєстрі         | Провайдер приймає довільні upstream id моделей                                                                                              |
+| 12  | `prepareDynamicModel`             | Асинхронний розігрів, після чого `resolveDynamicModel` запускається знову                                        | Провайдеру потрібні мережеві метадані перед визначенням невідомих id                                                                        |
+| 13  | `normalizeResolvedModel`          | Остаточне переписування до того, як embedded runner використає визначену модель                                  | Провайдеру потрібні переписування транспорту, але він усе ще використовує транспорт ядра                                                   |
+| 14  | `contributeResolvedModelCompat`   | Додає прапорці сумісності для моделей постачальника за іншим сумісним транспортом                                | Провайдер розпізнає власні моделі на проксі-транспортах, не перехоплюючи контроль над провайдером                                         |
+| 15  | `capabilities`                    | Метадані транскриптів/інструментів, що належать провайдеру й використовуються спільною логікою ядра             | Провайдеру потрібні особливості транскриптів/сімейства провайдерів                                                                          |
+| 16  | `normalizeToolSchemas`            | Нормалізує схеми інструментів до того, як їх побачить embedded runner                                            | Провайдеру потрібне очищення схем для сімейства транспорту                                                                                  |
+| 17  | `inspectToolSchemas`              | Виводить діагностику схем, що належить провайдеру, після нормалізації                                            | Провайдер хоче мати попередження про ключові слова, не навчаючи ядро правилам, специфічним для провайдера                                 |
+| 18  | `resolveReasoningOutputMode`      | Вибирає нативний або тегований контракт виводу reasoning                                                         | Провайдеру потрібен тегований reasoning/кінцевий вивід замість нативних полів                                                              |
+| 19  | `prepareExtraParams`              | Нормалізація параметрів запиту перед загальними обгортками параметрів потоку                                     | Провайдеру потрібні параметри запиту за замовчуванням або очищення параметрів для конкретного провайдера                                   |
+| 20  | `createStreamFn`                  | Повністю замінює звичайний шлях потоку власним транспортом                                                       | Провайдеру потрібен власний wire protocol, а не просто обгортка                                                                             |
+| 21  | `wrapStreamFn`                    | Обгортка потоку після застосування загальних обгорток                                                            | Провайдеру потрібні обгортки сумісності заголовків/тіла запиту/моделі без власного транспорту                                             |
+| 22  | `resolveTransportTurnState`       | Додає нативні заголовки транспорту на хід або метадані                                                           | Провайдер хоче, щоб загальні транспорти надсилали нативну для провайдера ідентичність ходу                                                |
+| 23  | `resolveWebSocketSessionPolicy`   | Додає нативні заголовки WebSocket або політику охолодження сесії                                                 | Провайдер хоче, щоб загальні WS-транспорти налаштовували заголовки сесії або політику резервного варіанта                                 |
+| 24  | `formatApiKey`                    | Форматер профілю автентифікації: збережений профіль стає рядком `apiKey` середовища виконання                   | Провайдер зберігає додаткові метадані автентифікації і потребує власної форми токена середовища виконання                                  |
+| 25  | `refreshOAuth`                    | Перевизначення оновлення OAuth для власних кінцевих точок оновлення або політики збоїв оновлення                | Провайдер не відповідає спільним refresher-ам `pi-ai`                                                                                       |
+| 26  | `buildAuthDoctorHint`             | Підказка виправлення, що додається, коли оновлення OAuth завершується з помилкою                                 | Провайдеру потрібні власні рекомендації щодо відновлення автентифікації після помилки оновлення                                            |
+| 27  | `matchesContextOverflowError`     | Засіб зіставлення переповнення контекстного вікна, що належить провайдеру                                        | Провайдер має сирі помилки переповнення, які загальні евристики не виявлять                                                                |
+| 28  | `classifyFailoverReason`          | Класифікація причин перемикання на резервний варіант, що належить провайдеру                                     | Провайдер може зіставляти сирі помилки API/транспорту з rate-limit/перевантаженням тощо                                                    |
+| 29  | `isCacheTtlEligible`              | Політика prompt-cache для проксі/backhaul-провайдерів                                                            | Провайдеру потрібне обмеження TTL кешу, специфічне для проксі                                                                               |
+| 30  | `buildMissingAuthMessage`         | Заміна загального повідомлення про відновлення після відсутності автентифікації                                  | Провайдеру потрібна власна підказка відновлення після відсутності автентифікації                                                           |
+| 31  | `suppressBuiltInModel`            | Приховування застарілої upstream-моделі плюс необов’язкова підказка про помилку для користувача                  | Провайдеру потрібно приховати застарілі upstream-рядки або замінити їх підказкою постачальника                                             |
+| 32  | `augmentModelCatalog`             | Синтетичні/фінальні рядки каталогу, що додаються після виявлення                                                 | Провайдеру потрібні синтетичні рядки прямої сумісності в майбутньому в `models list` і засобах вибору                                      |
+| 33  | `isBinaryThinking`                | Перемикач reasoning увімк./вимк. для провайдерів із двійковим thinking                                           | Провайдер відкриває лише двійковий режим thinking увімк./вимк.                                                                              |
+| 34  | `supportsXHighThinking`           | Підтримка reasoning `xhigh` для вибраних моделей                                                                 | Провайдер хоче `xhigh` лише для підмножини моделей                                                                                          |
+| 35  | `resolveDefaultThinkingLevel`     | Рівень `/think` за замовчуванням для конкретного сімейства моделей                                               | Провайдер володіє політикою `/think` за замовчуванням для сімейства моделей                                                                 |
+| 36  | `isModernModelRef`                | Засіб зіставлення сучасної моделі для фільтрів live-профілів і вибору smoke                                      | Провайдер володіє зіставленням бажаної моделі для live/smoke                                                                                |
+| 37  | `prepareRuntimeAuth`              | Обмінює налаштовані облікові дані на фактичний токен/ключ середовища виконання безпосередньо перед висновком    | Провайдеру потрібен обмін токенів або короткоживучі облікові дані запиту                                                                    |
 | 38  | `resolveUsageAuth`                | Визначає облікові дані використання/білінгу для `/usage` та пов’язаних поверхонь статусу                       | Провайдеру потрібен власний розбір токена використання/квоти або інші облікові дані використання                                           |
-| 39  | `fetchUsageSnapshot`              | Отримує та нормалізує знімки використання/квоти, специфічні для провайдера, після визначення автентифікації   | Провайдеру потрібна кінцева точка використання або аналізатор корисного навантаження, специфічні для провайдера                            |
-| 40  | `createEmbeddingProvider`         | Створює адаптер embedding, що належить провайдеру, для пам’яті/пошуку                                          | Поведінка embedding для пам’яті має належати плагіну провайдера                                                                             |
-| 41  | `buildReplayPolicy`               | Повертає політику повторного відтворення, що керує обробкою транскриптів для провайдера                       | Провайдеру потрібна власна політика транскриптів (наприклад, видалення блоків thinking)                                                    |
-| 42  | `sanitizeReplayHistory`           | Переписує історію повторного відтворення після загального очищення транскрипту                                 | Провайдеру потрібні переписування повторного відтворення, специфічні для провайдера, понад спільні допоміжні засоби ущільнення            |
-| 43  | `validateReplayTurns`             | Остаточна перевірка або переформування кроків повторного відтворення перед embedded runner                     | Транспорт провайдера потребує суворішої перевірки кроків після загального очищення                                                         |
-| 44  | `onModelSelected`                 | Виконує побічні ефекти після вибору моделі, що належать провайдеру                                             | Провайдеру потрібна телеметрія або стан, що належить провайдеру, коли модель стає активною                                                 |
+| 39  | `fetchUsageSnapshot`              | Отримує та нормалізує знімки використання/квоти, специфічні для провайдера, після визначення автентифікації    | Провайдеру потрібна кінцева точка використання або парсер корисного навантаження, специфічні для провайдера                               |
+| 40  | `createEmbeddingProvider`         | Створює адаптер embedding, що належить провайдеру, для пам’яті/пошуку                                           | Поведінка embedding для пам’яті має належати плагіну провайдера                                                                             |
+| 41  | `buildReplayPolicy`               | Повертає політику replay, яка керує обробкою транскрипту для провайдера                                         | Провайдеру потрібна власна політика транскрипту (наприклад, видалення блоків thinking)                                                     |
+| 42  | `sanitizeReplayHistory`           | Переписує історію replay після загального очищення транскрипту                                                  | Провайдеру потрібні переписування replay, специфічні для провайдера, понад спільні допоміжні засоби компакції                             |
+| 43  | `validateReplayTurns`             | Виконує остаточну перевірку або зміну форми ходів replay перед embedded runner                                  | Транспорту провайдера потрібна суворіша перевірка ходів після загального очищення                                                           |
+| 44  | `onModelSelected`                 | Виконує побічні ефекти після вибору моделі, що належать провайдеру                                              | Провайдеру потрібні телеметрія або стан, що належать провайдеру, коли модель стає активною                                                 |
 
-`normalizeModelId`, `normalizeTransport` і `normalizeConfig` спочатку перевіряють
-плагін провайдера, що збігся, а потім переходять до інших плагінів провайдерів, здатних до хуків,
-доки один із них фактично не змінить id моделі або транспорт/конфігурацію. Це зберігає
-працездатність shim-провайдерів для псевдонімів/сумісності без вимоги до виклику знати, який
-вбудований плагін володіє переписуванням. Якщо жоден хук провайдера не переписує підтримуваний
-запис конфігурації сімейства Google, вбудований нормалізатор конфігурації Google все одно
-застосовує це очищення сумісності.
+`normalizeModelId`, `normalizeTransport` і `normalizeConfig` спочатку
+перевіряють відповідний плагін провайдера, а потім переходять до інших
+плагінів провайдерів, які підтримують хуки, доки один із них справді не змінить
+id моделі або транспорт/конфігурацію. Це дозволяє shim-рішенням для
+псевдонімів/сумісності провайдерів працювати без вимоги, щоб викликач знав,
+який саме вбудований плагін володіє цим переписуванням. Якщо жоден хук
+провайдера не переписує підтримуваний запис конфігурації сімейства Google, усе
+одно застосовується вбудований нормалізатор конфігурації Google для цього
+очищення сумісності.
 
-Якщо провайдеру потрібен повністю власний wire protocol або власний виконавець запитів,
-це вже інший клас розширення. Ці хуки призначені для поведінки провайдера, яка все ще
-працює в межах звичайного циклу висновку OpenClaw.
+Якщо провайдеру потрібен повністю власний wire protocol або власний виконавець
+запитів, це вже інший клас розширення. Ці хуки призначені для поведінки
+провайдера, яка все ще працює в межах звичайного циклу висновку OpenClaw.
 
 ### Приклад провайдера
 
@@ -780,113 +818,131 @@ api.registerProvider({
 - Anthropic використовує `resolveDynamicModel`, `capabilities`, `buildAuthDoctorHint`,
   `resolveUsageAuth`, `fetchUsageSnapshot`, `isCacheTtlEligible`,
   `resolveDefaultThinkingLevel`, `applyConfigDefaults`, `isModernModelRef`
-  і `wrapStreamFn`, оскільки він володіє прямою сумісністю Claude 4.6,
-  підказками сімейства провайдера, вказівками щодо відновлення автентифікації, інтеграцією
-  кінцевої точки використання, придатністю prompt-cache, стандартними значеннями конфігурації з урахуванням автентифікації, стандартною/адаптивною політикою thinking
-  для Claude та специфічним для Anthropic формуванням потоку для
-  beta-заголовків, `/fast` / `serviceTier` і `context1m`.
-- Допоміжні засоби потоку Anthropic, специфічні для Claude, наразі залишаються у
-  власній публічній межі `api.ts` / `contract-api.ts` вбудованого плагіна. Ця поверхня пакета
-  експортує `wrapAnthropicProviderStream`, `resolveAnthropicBetas`,
-  `resolveAnthropicFastMode`, `resolveAnthropicServiceTier` і нижчорівневі
-  конструктори обгорток Anthropic замість розширення загального SDK навколо правил
-  beta-заголовків одного провайдера.
+  і `wrapStreamFn`, оскільки він володіє прямою сумісністю вперед для Claude 4.6,
+  підказками сімейства провайдера, рекомендаціями з відновлення
+  автентифікації, інтеграцією кінцевої точки використання, правом на
+  використання prompt-cache, значеннями конфігурації за замовчуванням з
+  урахуванням автентифікації, політикою default/adaptive thinking для Claude
+  та Anthropic-специфічним формуванням потоку для beta-заголовків,
+  `/fast` / `serviceTier` і `context1m`.
+- Допоміжні засоби потоку Anthropic, специфічні для Claude, поки що
+  залишаються у власному публічному шві `api.ts` / `contract-api.ts`
+  вбудованого плагіна. Ця поверхня пакета експортує
+  `wrapAnthropicProviderStream`, `resolveAnthropicBetas`,
+  `resolveAnthropicFastMode`, `resolveAnthropicServiceTier` і допоміжні
+  побудовники обгорток Anthropic нижчого рівня замість розширення загального
+  SDK навколо правил beta-заголовків одного провайдера.
 - OpenAI використовує `resolveDynamicModel`, `normalizeResolvedModel` і
   `capabilities`, а також `buildMissingAuthMessage`, `suppressBuiltInModel`,
   `augmentModelCatalog`, `supportsXHighThinking` і `isModernModelRef`,
-  оскільки він володіє прямою сумісністю GPT-5.4, прямою нормалізацією OpenAI
-  `openai-completions` -> `openai-responses`, підказками автентифікації з урахуванням Codex,
-  приховуванням Spark, синтетичними рядками списку OpenAI і політикою GPT-5 thinking /
-  live-model; сімейство потоків `openai-responses-defaults` володіє
-  спільними native-обгортками OpenAI Responses для заголовків атрибуції,
-  `/fast`/`serviceTier`, деталізації тексту, native-вебпошуку Codex,
+  оскільки він володіє прямою сумісністю вперед для GPT-5.4, прямою
+  нормалізацією OpenAI `openai-completions` -> `openai-responses`,
+  підказками автентифікації з урахуванням Codex, приховуванням Spark,
+  синтетичними рядками списку OpenAI та політикою thinking / live-model для
+  GPT-5; сімейство потоків `openai-responses-defaults` володіє спільними
+  нативними обгортками OpenAI Responses для заголовків атрибуції,
+  `/fast`/`serviceTier`, детальності тексту, нативного вебпошуку Codex,
   формуванням корисного навантаження reasoning-compat і керуванням контекстом Responses.
 - OpenRouter використовує `catalog`, а також `resolveDynamicModel` і
-  `prepareDynamicModel`, оскільки цей провайдер є наскрізним і може відкривати нові
+  `prepareDynamicModel`, оскільки провайдер є наскрізним і може відкривати нові
   id моделей до оновлення статичного каталогу OpenClaw; він також використовує
-  `capabilities`, `wrapStreamFn` і `isCacheTtlEligible`, щоб утримувати
-  специфічні для провайдера заголовки запиту, метадані маршрутизації, патчі reasoning і
-  політику prompt-cache поза ядром. Його політика повторного відтворення походить із
-  сімейства `passthrough-gemini`, тоді як сімейство потоків `openrouter-thinking`
-  володіє ін’єкцією reasoning проксі та пропусками unsupported-model / `auto`.
+  `capabilities`, `wrapStreamFn` і `isCacheTtlEligible`, щоб заголовки
+  запитів, метадані маршрутизації, патчі reasoning та політика prompt-cache,
+  специфічні для провайдера, не потрапляли в ядро. Його політика replay
+  походить із сімейства `passthrough-gemini`, тоді як сімейство потоків
+  `openrouter-thinking` володіє ін’єкцією proxy reasoning і пропусками для
+  непідтримуваних моделей / `auto`.
 - GitHub Copilot використовує `catalog`, `auth`, `resolveDynamicModel` і
-  `capabilities`, а також `prepareRuntimeAuth` і `fetchUsageSnapshot`, оскільки йому
-  потрібні device login, що належать провайдеру, поведінка резервування моделі, особливості транскриптів Claude,
-  обмін токена GitHub на токен Copilot і кінцева точка використання, що належить провайдеру.
+  `capabilities`, а також `prepareRuntimeAuth` і `fetchUsageSnapshot`,
+  оскільки йому потрібні device login, що належить провайдеру, поведінка
+  резервного вибору моделі, особливості транскриптів Claude, обмін токена
+  GitHub на токен Copilot і кінцева точка використання, що належить провайдеру.
 - OpenAI Codex використовує `catalog`, `resolveDynamicModel`,
   `normalizeResolvedModel`, `refreshOAuth` і `augmentModelCatalog`, а також
-  `prepareExtraParams`, `resolveUsageAuth` і `fetchUsageSnapshot`, оскільки він
-  усе ще працює на транспорті OpenAI ядра, але володіє нормалізацією свого
-  транспорту/`base URL`, резервною політикою оновлення OAuth, стандартним вибором транспорту,
-  синтетичними рядками каталогу Codex і інтеграцією кінцевої точки використання ChatGPT; він
-  використовує те саме сімейство потоків `openai-responses-defaults`, що й прямий OpenAI.
+  `prepareExtraParams`, `resolveUsageAuth` і `fetchUsageSnapshot`, оскільки
+  він усе ще працює на транспорті ядра OpenAI, але володіє нормалізацією
+  транспорту/base URL, резервною політикою оновлення OAuth, вибором
+  транспорту за замовчуванням, синтетичними рядками каталогу Codex та
+  інтеграцією кінцевої точки використання ChatGPT; він використовує те саме
+  сімейство потоків `openai-responses-defaults`, що й прямий OpenAI.
 - Google AI Studio і Gemini CLI OAuth використовують `resolveDynamicModel`,
   `buildReplayPolicy`, `sanitizeReplayHistory`,
   `resolveReasoningOutputMode`, `wrapStreamFn` і `isModernModelRef`, оскільки
-  сімейство повторного відтворення `google-gemini` володіє резервним механізмом прямої сумісності Gemini 3.1,
-  native-перевіркою повторного відтворення Gemini, очищенням bootstrap replay,
-  tagged-режимом виводу reasoning і зіставленням modern-model, тоді як
-  сімейство потоків `google-thinking` володіє нормалізацією payload thinking для Gemini;
-  Gemini CLI OAuth також використовує `formatApiKey`, `resolveUsageAuth` і
-  `fetchUsageSnapshot` для форматування токенів, розбору токенів і
-  підключення кінцевої точки квот.
-- Anthropic Vertex використовує `buildReplayPolicy` через
-  сімейство повторного відтворення `anthropic-by-model`, щоб очищення replay, специфічне для Claude, залишалося
-  обмеженим id Claude, а не кожним транспортом `anthropic-messages`.
+  сімейство replay `google-gemini` володіє резервним механізмом прямої
+  сумісності вперед для Gemini 3.1, нативною перевіркою replay Gemini,
+  очищенням bootstrap replay, режимом тегованого виводу reasoning і
+  зіставленням сучасних моделей, тоді як сімейство потоків
+  `google-thinking` володіє нормалізацією корисного навантаження thinking для
+  Gemini; Gemini CLI OAuth також використовує `formatApiKey`,
+  `resolveUsageAuth` і `fetchUsageSnapshot` для форматування токенів,
+  розбору токенів і підключення кінцевої точки квот.
+- Anthropic Vertex використовує `buildReplayPolicy` через сімейство replay
+  `anthropic-by-model`, щоб очищення replay, специфічне для Claude,
+  залишалося обмеженим id Claude, а не кожним транспортом `anthropic-messages`.
 - Amazon Bedrock використовує `buildReplayPolicy`, `matchesContextOverflowError`,
-  `classifyFailoverReason` і `resolveDefaultThinkingLevel`, оскільки він володіє
-  специфічною для Bedrock класифікацією помилок throttle/not-ready/context-overflow
-  для трафіку Anthropic-on-Bedrock; його політика повторного відтворення все ще використовує той самий
-  захист `anthropic-by-model`, що стосується лише Claude.
+  `classifyFailoverReason` і `resolveDefaultThinkingLevel`, оскільки він
+  володіє класифікацією помилок throttle/not-ready/context-overflow,
+  специфічною для Bedrock, для трафіку Anthropic-on-Bedrock; його політика
+  replay усе ще використовує той самий захист `anthropic-by-model` лише для Claude.
 - OpenRouter, Kilocode, Opencode і Opencode Go використовують `buildReplayPolicy`
-  через сімейство повторного відтворення `passthrough-gemini`, оскільки вони проксіюють моделі Gemini
-  через транспорти, сумісні з OpenAI, і потребують очищення thought-signature
-  Gemini без native-перевірки replay Gemini або bootstrap-переписувань.
-- MiniMax використовує `buildReplayPolicy` через
-  сімейство повторного відтворення `hybrid-anthropic-openai`, оскільки один провайдер володіє і семантикою
-  повідомлень Anthropic, і семантикою, сумісною з OpenAI; він зберігає видалення
-  блоків thinking лише для Claude на стороні Anthropic, одночасно перевизначаючи режим виводу reasoning назад на native, а сімейство потоків `minimax-fast-mode` володіє
-  переписуваннями моделей fast-mode на спільному шляху потоку.
-- Moonshot використовує `catalog` і `wrapStreamFn`, оскільки він усе ще використовує спільний
-  транспорт OpenAI, але потребує нормалізації payload thinking, що належить провайдеру; сімейство
-  потоків `moonshot-thinking` відображає конфігурацію та стан `/think` на його
-  native-бінарний payload thinking.
+  через сімейство replay `passthrough-gemini`, оскільки вони проксіюють моделі
+  Gemini через транспорти, сумісні з OpenAI, і потребують очищення
+  thought-signature Gemini без нативної перевірки replay Gemini або
+  переписувань bootstrap.
+- MiniMax використовує `buildReplayPolicy` через сімейство replay
+  `hybrid-anthropic-openai`, оскільки один провайдер володіє як семантикою
+  повідомлень Anthropic, так і семантикою, сумісною з OpenAI; він зберігає
+  видалення блоків thinking лише для Claude на боці Anthropic, водночас
+  перевизначаючи режим виводу reasoning назад на нативний, а сімейство потоків
+  `minimax-fast-mode` володіє переписуваннями моделей fast-mode на спільному
+  шляху потоку.
+- Moonshot використовує `catalog` і `wrapStreamFn`, оскільки він усе ще
+  використовує спільний транспорт OpenAI, але потребує нормалізації корисного
+  навантаження thinking, що належить провайдеру; сімейство потоків
+  `moonshot-thinking` зіставляє конфігурацію та стан `/think` із його
+  нативним двійковим корисним навантаженням thinking.
 - Kilocode використовує `catalog`, `capabilities`, `wrapStreamFn` і
-  `isCacheTtlEligible`, оскільки йому потрібні заголовки запиту, що належать провайдеру,
-  нормалізація payload reasoning, підказки транскриптів Gemini та керування
-  TTL кешу Anthropic; сімейство потоків `kilocode-thinking` зберігає ін’єкцію thinking Kilo
-  на спільному шляху проксі-потоку, водночас пропускаючи `kilo/auto` та
-  інші id проксі-моделей, які не підтримують явні payload reasoning.
+  `isCacheTtlEligible`, оскільки йому потрібні заголовки запитів, що належать
+  провайдеру, нормалізація корисного навантаження reasoning, підказки для
+  транскриптів Gemini та обмеження cache-TTL для Anthropic; сімейство потоків
+  `kilocode-thinking` зберігає ін’єкцію Kilo thinking на спільному шляху
+  proxy-потоку, пропускаючи `kilo/auto` та інші proxy id моделей, які не
+  підтримують явне корисне навантаження reasoning.
 - Z.AI використовує `resolveDynamicModel`, `prepareExtraParams`, `wrapStreamFn`,
   `isCacheTtlEligible`, `isBinaryThinking`, `isModernModelRef`,
-  `resolveUsageAuth` і `fetchUsageSnapshot`, оскільки він володіє резервуванням GLM-5,
-  стандартними значеннями `tool_stream`, UX двійкового thinking, зіставленням modern-model
-  і як автентифікацією використання, так і отриманням квот; сімейство потоків `tool-stream-default-on`
-  утримує обгортку `tool_stream`, увімкнену за замовчуванням, поза рукописним glue-кодом
-  окремих провайдерів.
+  `resolveUsageAuth` і `fetchUsageSnapshot`, оскільки він володіє резервним
+  механізмом GLM-5, значеннями `tool_stream` за замовчуванням, UX двійкового
+  thinking, зіставленням сучасних моделей, а також автентифікацією
+  використання + отриманням квот; сімейство потоків `tool-stream-default-on`
+  тримає обгортку `tool_stream`, увімкнену за замовчуванням, поза ручним клеєм
+  для кожного окремого провайдера.
 - xAI використовує `normalizeResolvedModel`, `normalizeTransport`,
   `contributeResolvedModelCompat`, `prepareExtraParams`, `wrapStreamFn`,
   `resolveSyntheticAuth`, `resolveDynamicModel` і `isModernModelRef`,
-  оскільки він володіє нормалізацією native-транспорту xAI Responses, переписуванням
-  псевдонімів fast-mode для Grok, стандартним `tool_stream`, очищенням
-  strict-tool / payload reasoning, повторним використанням резервної автентифікації для інструментів, що належать плагіну,
-  визначенням моделей Grok із прямою сумісністю та патчами сумісності, що належать провайдеру, такими як профіль схем інструментів xAI,
-  непідтримувані ключові слова схеми, native `web_search` і декодування аргументів
-  виклику інструментів у HTML-сутностях.
+  оскільки він володіє нативною нормалізацією транспорту xAI Responses,
+  переписуванням псевдонімів fast-mode для Grok, значенням `tool_stream` за
+  замовчуванням, очищенням strict-tool / reasoning-payload, повторним
+  використанням резервної автентифікації для інструментів, що належать
+  плагіну, визначенням моделей Grok із прямою сумісністю вперед і
+  патчами сумісності, що належать провайдеру, такими як профіль схеми
+  інструментів xAI, непідтримувані ключові слова схеми, нативний `web_search`
+  та декодування аргументів виклику інструментів з HTML-сутностей.
 - Mistral, OpenCode Zen і OpenCode Go використовують лише `capabilities`, щоб
   винести особливості транскриптів/інструментів за межі ядра.
-- Вбудовані провайдери лише з каталогом, такі як `byteplus`, `cloudflare-ai-gateway`,
-  `huggingface`, `kimi-coding`, `nvidia`, `qianfan`,
-  `synthetic`, `together`, `venice`, `vercel-ai-gateway` і `volcengine`, використовують
-  лише `catalog`.
-- Qwen використовує `catalog` для свого текстового провайдера, а також спільні реєстрації
-  media-understanding і video-generation для своїх мультимодальних поверхонь.
-- MiniMax і Xiaomi використовують `catalog`, а також хуки використання, оскільки їхня поведінка `/usage`
-  належить плагіну, навіть якщо висновок усе ще проходить через спільні транспорти.
+- Вбудовані провайдери лише з каталогом, такі як `byteplus`,
+  `cloudflare-ai-gateway`, `huggingface`, `kimi-coding`, `nvidia`, `qianfan`,
+  `synthetic`, `together`, `venice`, `vercel-ai-gateway` і `volcengine`,
+  використовують лише `catalog`.
+- Qwen використовує `catalog` для свого текстового провайдера, а також спільні
+  реєстрації розуміння медіа та генерації відео для своїх мультимодальних поверхонь.
+- MiniMax і Xiaomi використовують `catalog` разом із хуками використання,
+  оскільки їхня поведінка `/usage` належить плагіну, хоча висновок усе ще
+  виконується через спільні транспорти.
 
 ## Допоміжні засоби середовища виконання
 
-Плагіни можуть отримувати доступ до вибраних допоміжних засобів ядра через `api.runtime`. Для TTS:
+Плагіни можуть отримувати доступ до вибраних допоміжних засобів ядра через
+`api.runtime`. Для TTS:
 
 ```ts
 const clip = await api.runtime.tts.textToSpeech({
@@ -907,11 +963,11 @@ const voices = await api.runtime.tts.listVoices({
 
 Примітки:
 
-- `textToSpeech` повертає звичайний payload виводу TTS ядра для поверхонь файлів/голосових нотаток.
-- Використовує конфігурацію `messages.tts` ядра та вибір провайдера.
-- Повертає буфер аудіо PCM + частоту дискретизації. Плагіни мають виконувати повторну дискретизацію/кодування для провайдерів.
+- `textToSpeech` повертає звичайне корисне навантаження виводу TTS ядра для поверхонь файлів/голосових нотаток.
+- Використовує конфігурацію ядра `messages.tts` і вибір провайдера.
+- Повертає буфер PCM-аудіо + частоту дискретизації. Плагіни мають виконувати ресемплінг/кодування для провайдерів.
 - `listVoices` є необов’язковим для кожного провайдера. Використовуйте його для засобів вибору голосу або потоків налаштування, що належать постачальнику.
-- Списки голосів можуть містити розширені метадані, такі як локаль, стать і теги характеру для засобів вибору з урахуванням провайдера.
+- Списки голосів можуть містити багатші метадані, як-от локаль, стать і теги характеру для засобів вибору з урахуванням провайдера.
 - OpenAI і ElevenLabs сьогодні підтримують телефонію. Microsoft — ні.
 
 Плагіни також можуть реєструвати провайдерів мовлення через `api.registerSpeechProvider(...)`.
@@ -934,15 +990,15 @@ api.registerSpeechProvider({
 
 Примітки:
 
-- Зберігайте політику TTS, резервування та доставку відповідей у ядрі.
+- Зберігайте політику TTS, резервні варіанти та доставку відповідей у ядрі.
 - Використовуйте провайдерів мовлення для поведінки синтезу, що належить постачальнику.
 - Застарілий вхід Microsoft `edge` нормалізується до id провайдера `microsoft`.
-- Бажана модель володіння орієнтована на компанію: один плагін постачальника може володіти
-  текстовими, мовленнєвими, графічними та майбутніми медіапровайдерами, коли OpenClaw додає
-  ці контракти можливостей.
+- Бажана модель володіння є орієнтованою на компанію: один плагін постачальника
+  може володіти текстом, мовленням, зображенням і майбутніми медіапровайдерами,
+  коли OpenClaw додає ці контракти можливостей.
 
 Для розуміння зображень/аудіо/відео плагіни реєструють один типізований
-провайдер media-understanding замість загального набору key/value:
+провайдер розуміння медіа замість універсального набору ключ/значення:
 
 ```ts
 api.registerMediaUnderstandingProvider({
@@ -956,10 +1012,9 @@ api.registerMediaUnderstandingProvider({
 
 Примітки:
 
-- Зберігайте оркестрацію, резервні механізми, конфігурацію та підключення каналів у ядрі.
+- Зберігайте оркестрацію, резервні варіанти, конфігурацію та підключення каналів у ядрі.
 - Зберігайте поведінку постачальника в плагіні провайдера.
-- Адитивне розширення має залишатися типізованим: нові необов’язкові методи, нові необов’язкові
-  поля результату, нові необов’язкові можливості.
+- Розширення мають залишатися типізованими та додатковими: нові необов’язкові методи, нові необов’язкові поля результату, нові необов’язкові можливості.
 - Генерація відео вже дотримується того самого шаблону:
   - ядро володіє контрактом можливості та допоміжним засобом середовища виконання
   - плагіни постачальників реєструють `api.registerVideoGenerationProvider(...)`
@@ -980,8 +1035,8 @@ const video = await api.runtime.mediaUnderstanding.describeVideoFile({
 });
 ```
 
-Для транскрипції аудіо плагіни можуть використовувати або середовище виконання media-understanding,
-або старіший псевдонім STT:
+Для транскрипції аудіо плагіни можуть використовувати або середовище виконання
+media-understanding, або старіший псевдонім STT:
 
 ```ts
 const { text } = await api.runtime.mediaUnderstanding.transcribeAudioFile({
@@ -996,11 +1051,11 @@ const { text } = await api.runtime.mediaUnderstanding.transcribeAudioFile({
 
 - `api.runtime.mediaUnderstanding.*` — це бажана спільна поверхня для
   розуміння зображень/аудіо/відео.
-- Використовує конфігурацію аудіо media-understanding ядра (`tools.media.audio`) і порядок резервування провайдерів.
-- Повертає `{ text: undefined }`, коли вихід транскрипції не створено (наприклад, для пропущеного/непідтримуваного вводу).
-- `api.runtime.stt.transcribeAudioFile(...)` залишається псевдонімом для сумісності.
+- Використовує конфігурацію аудіо media-understanding ядра (`tools.media.audio`) і порядок резервних варіантів провайдерів.
+- Повертає `{ text: undefined }`, коли вивід транскрипції не створено (наприклад, для пропущеного/непідтримуваного вводу).
+- `api.runtime.stt.transcribeAudioFile(...)` залишається як псевдонім сумісності.
 
-Плагіни також можуть запускати фонові виконання підлеглих агентів через `api.runtime.subagent`:
+Плагіни також можуть запускати фонові запуски підлеглих агентів через `api.runtime.subagent`:
 
 ```ts
 const result = await api.runtime.subagent.run({
@@ -1015,13 +1070,13 @@ const result = await api.runtime.subagent.run({
 Примітки:
 
 - `provider` і `model` — це необов’язкові перевизначення для окремого запуску, а не постійні зміни сесії.
-- OpenClaw враховує ці поля перевизначення лише для довірених викликів.
-- Для резервних запусків, що належать плагіну, оператори мають явно дозволити це через `plugins.entries.<id>.subagent.allowModelOverride: true`.
+- OpenClaw враховує ці поля перевизначення лише для довірених викликачів.
+- Для резервних запусків, що належать плагіну, оператори мають явно надати згоду через `plugins.entries.<id>.subagent.allowModelOverride: true`.
 - Використовуйте `plugins.entries.<id>.subagent.allowedModels`, щоб обмежити довірені плагіни конкретними канонічними цілями `provider/model`, або `"*"`, щоб явно дозволити будь-яку ціль.
-- Запуски підлеглих агентів із недовірених плагінів також працюють, але запити на перевизначення відхиляються замість тихого переходу до резервного варіанта.
+- Запуски підлеглих агентів із недовірених плагінів усе одно працюють, але запити на перевизначення відхиляються замість тихого переходу на резервний варіант.
 
-Для вебпошуку плагіни можуть споживати спільний допоміжний засіб середовища виконання замість
-звернення до підключення інструмента агента:
+Для вебпошуку плагіни можуть споживати спільний допоміжний засіб середовища
+виконання замість звернення безпосередньо до підключення інструмента агента:
 
 ```ts
 const providers = api.runtime.webSearch.listProviders({
@@ -1059,8 +1114,8 @@ const providers = api.runtime.imageGeneration.listProviders({
 });
 ```
 
-- `generate(...)`: генерує зображення за допомогою налаштованого ланцюжка провайдерів генерації зображень.
-- `listProviders(...)`: виводить список доступних провайдерів генерації зображень та їхніх можливостей.
+- `generate(...)`: генерує зображення з використанням налаштованого ланцюжка провайдерів генерації зображень.
+- `listProviders(...)`: показує доступних провайдерів генерації зображень і їхні можливості.
 
 ## HTTP-маршрути Gateway
 
@@ -1082,32 +1137,33 @@ api.registerHttpRoute({
 Поля маршруту:
 
 - `path`: шлях маршруту під HTTP-сервером gateway.
-- `auth`: обов’язкове поле. Використовуйте `"gateway"`, щоб вимагати звичайну автентифікацію gateway, або `"plugin"` для автентифікації/перевірки вебхуків, якими керує плагін.
+- `auth`: обов’язкове поле. Використовуйте `"gateway"` для звичайної автентифікації gateway або `"plugin"` для керованої плагіном автентифікації/перевірки webhook.
 - `match`: необов’язкове поле. `"exact"` (типово) або `"prefix"`.
-- `replaceExisting`: необов’язкове поле. Дозволяє тому самому плагіну замінювати власну наявну реєстрацію маршруту.
-- `handler`: повертайте `true`, коли маршрут обробив запит.
+- `replaceExisting`: необов’язкове поле. Дозволяє тому самому плагіну замінити власну наявну реєстрацію маршруту.
+- `handler`: має повертати `true`, коли маршрут обробив запит.
 
 Примітки:
 
-- `api.registerHttpHandler(...)` було видалено, і його використання спричинить помилку завантаження плагіна. Натомість використовуйте `api.registerHttpRoute(...)`.
+- `api.registerHttpHandler(...)` видалено, і його використання спричинить помилку завантаження плагіна. Натомість використовуйте `api.registerHttpRoute(...)`.
 - Маршрути плагінів мають явно оголошувати `auth`.
-- Конфлікти точних `path + match` відхиляються, якщо не вказано `replaceExisting: true`, і один плагін не може замінити маршрут іншого плагіна.
-- Перекривні маршрути з різними рівнями `auth` відхиляються. Тримайте ланцюги переходу `exact`/`prefix` лише в межах одного рівня auth.
-- Маршрути з `auth: "plugin"` **не** отримують автоматично операторські області середовища виконання. Вони призначені для вебхуків/перевірки підписів, якими керує плагін, а не для привілейованих викликів допоміжних засобів Gateway.
-- Маршрути з `auth: "gateway"` працюють усередині області середовища виконання запиту Gateway, але ця область навмисно консервативна:
-  - bearer-автентифікація через спільний секрет (`gateway.auth.mode = "token"` / `"password"`) утримує області середовища виконання маршруту плагіна на рівні `operator.write`, навіть якщо викликач надсилає `x-openclaw-scopes`
-  - довірені HTTP-режими з носієм ідентичності (наприклад, `trusted-proxy` або `gateway.auth.mode = "none"` на приватному ingress) враховують `x-openclaw-scopes` лише тоді, коли цей заголовок явно присутній
-  - якщо `x-openclaw-scopes` відсутній у таких запитах маршруту плагіна з носієм ідентичності, область середовища виконання повертається до `operator.write`
-- Практичне правило: не припускайте, що маршрут плагіна з автентифікацією gateway автоматично є поверхнею адміністратора. Якщо вашому маршруту потрібна поведінка лише для адміністратора, вимагайте режим автентифікації з носієм ідентичності та задокументуйте явний контракт заголовка `x-openclaw-scopes`.
+- Конфлікти точних `path + match` відхиляються, якщо тільки не вказано `replaceExisting: true`, і один плагін не може замінити маршрут іншого плагіна.
+- Перекривні маршрути з різними рівнями `auth` відхиляються. Ланцюжки переходу `exact`/`prefix` мають бути лише на одному рівні `auth`.
+- Маршрути `auth: "plugin"` **не** отримують автоматично області середовища виконання оператора. Вони призначені для webhook-ів/перевірки підписів, якими керує плагін, а не для привілейованих допоміжних викликів Gateway.
+- Маршрути `auth: "gateway"` виконуються в межах області середовища виконання запиту Gateway, але ця область навмисно консервативна:
+  - bearer-автентифікація зі спільним секретом (`gateway.auth.mode = "token"` / `"password"`) утримує області середовища виконання маршрутів плагіна на рівні `operator.write`, навіть якщо викликач надсилає `x-openclaw-scopes`
+  - довірені HTTP-режими з ідентичністю (наприклад, `trusted-proxy` або `gateway.auth.mode = "none"` на приватному вході) враховують `x-openclaw-scopes` лише тоді, коли цей заголовок явно присутній
+  - якщо `x-openclaw-scopes` відсутній у таких запитах маршрутів плагіна з ідентичністю, область середовища виконання повертається до `operator.write`
+- Практичне правило: не припускайте, що маршрут плагіна з gateway-auth є неявною поверхнею адміністратора. Якщо вашому маршруту потрібна поведінка лише для адміністраторів, вимагайте режим автентифікації з ідентичністю та документуйте явний контракт заголовка `x-openclaw-scopes`.
 
 ## Шляхи імпорту Plugin SDK
 
-Під час створення плагінів використовуйте підшляхи SDK замість монолітного імпорту `openclaw/plugin-sdk`:
+Під час створення плагінів використовуйте підшляхи SDK замість монолітного
+імпорту `openclaw/plugin-sdk`:
 
 - `openclaw/plugin-sdk/plugin-entry` для примітивів реєстрації плагінів.
-- `openclaw/plugin-sdk/core` для загального спільного контракту, орієнтованого на плагіни.
-- `openclaw/plugin-sdk/config-schema` для експорту кореневої схеми Zod `openclaw.json`
-  (`OpenClawSchema`).
+- `openclaw/plugin-sdk/core` для загального спільного контракту для плагінів.
+- `openclaw/plugin-sdk/config-schema` для експорту кореневої Zod-схеми
+  `openclaw.json` (`OpenClawSchema`).
 - Стабільні примітиви каналів, такі як `openclaw/plugin-sdk/channel-setup`,
   `openclaw/plugin-sdk/setup-runtime`,
   `openclaw/plugin-sdk/setup-adapter-runtime`,
@@ -1121,14 +1177,18 @@ api.registerHttpRoute({
   `openclaw/plugin-sdk/command-auth`,
   `openclaw/plugin-sdk/secret-input` і
   `openclaw/plugin-sdk/webhook-ingress` для спільного підключення
-  налаштування/автентифікації/відповідей/вебхуків. `channel-inbound` — це спільне місце для debounce, зіставлення згадок,
-  допоміжних засобів політики вхідних згадок, форматування конвертів і допоміжних засобів
-  контексту вхідних конвертів.
-  `channel-setup` — це вузька межа налаштування для необов’язкового встановлення.
-  `setup-runtime` — це безпечна для середовища виконання поверхня налаштування, яку використовують `setupEntry` /
-  відкладений запуск, включно з безпечними для імпорту адаптерами патчів налаштування.
-  `setup-adapter-runtime` — це межа адаптера налаштування облікового запису з урахуванням env.
-  `setup-tools` — це мала межа допоміжних засобів для CLI/архівів/документації (`formatCliCommand`,
+  налаштування/автентифікації/відповідей/webhook. `channel-inbound` — це
+  спільне місце для debounce, зіставлення згадок, допоміжних засобів політики
+  вхідних згадок, форматування envelope та допоміжних засобів контексту
+  вхідного envelope.
+  `channel-setup` — це вузький шов налаштування з необов’язковим встановленням.
+  `setup-runtime` — це безпечна для середовища виконання поверхня налаштування,
+  яка використовується `setupEntry` / відкладеним запуском, включно з безпечними
+  для імпорту адаптерами патчів налаштування.
+  `setup-adapter-runtime` — це шов адаптера налаштування облікового запису з
+  урахуванням env.
+  `setup-tools` — це малий шов для допоміжних засобів CLI/архіву/документації
+  (`formatCliCommand`,
   `detectBinary`, `extractArchive`, `resolveBrewExecutable`, `formatDocsLink`,
   `CONFIG_DIR`).
 - Підшляхи доменів, такі як `openclaw/plugin-sdk/channel-config-helpers`,
@@ -1149,117 +1209,132 @@ api.registerHttpRoute({
   `openclaw/plugin-sdk/status-helpers`,
   `openclaw/plugin-sdk/text-runtime`,
   `openclaw/plugin-sdk/runtime-store` і
-  `openclaw/plugin-sdk/directory-runtime` для спільних допоміжних засобів середовища виконання/конфігурації.
-  `telegram-command-config` — це вузька публічна межа для нормалізації/валідації користувацьких
-  команд Telegram і залишається доступною навіть якщо поверхня контракту вбудованого
-  Telegram тимчасово недоступна.
-  `text-runtime` — це спільна межа тексту/markdown/логування, включно з
-  видаленням тексту, видимого асистенту, допоміжними засобами рендерингу/розбиття markdown, допоміжними засобами редагування,
-  допоміжними засобами тегів директив і утилітами безпечного тексту.
-- Для меж каналів, специфічних для погодження, слід надавати перевагу одному контракту
-  `approvalCapability` на плагіні. Тоді ядро читає auth, доставку, рендеринг,
-  native-routing і поведінку lazy native-handler для погодження через одну цю можливість
-  замість змішування поведінки погодження з не пов’язаними полями плагіна.
-- `openclaw/plugin-sdk/channel-runtime` є застарілим і залишається лише як
-  shim сумісності для старіших плагінів. Новий код має імпортувати вужчі
+  `openclaw/plugin-sdk/directory-runtime` для спільних допоміжних засобів
+  середовища виконання/конфігурації.
+  `telegram-command-config` — це вузький публічний шов для нормалізації/
+  перевірки користувацьких команд Telegram і залишається доступним, навіть якщо
+  поверхня контракту вбудованого Telegram тимчасово недоступна.
+  `text-runtime` — це спільний шов тексту/markdown/журналювання, включно з
+  видаленням тексту, видимого асистенту, допоміжними засобами рендерингу/
+  розбиття markdown, допоміжними засобами редагування, допоміжними засобами
+  тегів директив і утилітами безпечного тексту.
+- Специфічні для погодження шви каналів мають надавати перевагу одному
+  контракту `approvalCapability` у плагіні. Потім ядро зчитує автентифікацію
+  погодження, доставку, рендеринг, нативну маршрутизацію та поведінку лінивого
+  нативного обробника через цю одну можливість замість змішування поведінки
+  погодження з іншими полями плагіна.
+- `openclaw/plugin-sdk/channel-runtime` застарів і залишається лише як
+  shim сумісності для старих плагінів. Новий код має імпортувати вужчі
   загальні примітиви, а код репозиторію не повинен додавати нові імпорти цього shim.
-- Внутрішні компоненти вбудованих розширень залишаються приватними. Зовнішні плагіни мають використовувати лише
-  підшляхи `openclaw/plugin-sdk/*`. Код ядра/тестів OpenClaw може використовувати
-  публічні точки входу репозиторію під коренем пакета плагіна, такі як `index.js`, `api.js`,
-  `runtime-api.js`, `setup-entry.js` і вузькоспрямовані файли, наприклад
-  `login-qr-api.js`. Ніколи не імпортуйте `src/*` пакета плагіна з ядра або з
-  іншого розширення.
+- Внутрішні компоненти вбудованих розширень залишаються приватними. Зовнішні
+  плагіни мають використовувати лише підшляхи `openclaw/plugin-sdk/*`. Ядро/тести
+  OpenClaw можуть використовувати публічні точки входу репозиторію в корені
+  пакета плагіна, такі як `index.js`, `api.js`, `runtime-api.js`, `setup-entry.js`
+  і вузькоспрямовані файли, такі як `login-qr-api.js`. Ніколи не імпортуйте
+  `src/*` пакета плагіна з ядра або з іншого розширення.
 - Розділення точок входу репозиторію:
-  `<plugin-package-root>/api.js` — це барель допоміжних засобів/типів,
-  `<plugin-package-root>/runtime-api.js` — це барель лише для середовища виконання,
+  `<plugin-package-root>/api.js` — це панель допоміжних засобів/типів,
+  `<plugin-package-root>/runtime-api.js` — це панель лише для середовища виконання,
   `<plugin-package-root>/index.js` — це точка входу вбудованого плагіна,
   а `<plugin-package-root>/setup-entry.js` — це точка входу плагіна налаштування.
 - Поточні приклади вбудованих провайдерів:
-  - Anthropic використовує `api.js` / `contract-api.js` для допоміжних засобів потоку Claude, таких
-    як `wrapAnthropicProviderStream`, допоміжні засоби beta-заголовків і розбір `service_tier`.
-  - OpenAI використовує `api.js` для конструкторів провайдера, допоміжних засобів стандартних моделей і
-    конструкторів провайдерів реального часу.
-  - OpenRouter використовує `api.js` для свого конструктора провайдера та допоміжних засобів
-    онбордингу/конфігурації, тоді як `register.runtime.js` усе ще може повторно експортувати загальні
-    допоміжні засоби `plugin-sdk/provider-stream` для локального використання в репозиторії.
-- Публічні точки входу, завантажені через фасад, віддають перевагу активному знімку конфігурації середовища виконання,
-  якщо він існує, а потім повертаються до визначеного файла конфігурації на диску, коли
-  OpenClaw ще не обслуговує знімок середовища виконання.
-- Загальні спільні примітиви залишаються бажаним публічним контрактом SDK. Невеликий
-  зарезервований набір меж допоміжних засобів із брендингом вбудованих каналів усе ще існує. Розглядайте їх як межі для підтримки вбудованих компонентів/сумісності, а не як нові цілі імпорту для сторонніх рішень; нові міжканальні контракти й надалі мають потрапляти до
-  загальних підшляхів `plugin-sdk/*` або до локальних барелів плагіна `api.js` /
+  - Anthropic використовує `api.js` / `contract-api.js` для допоміжних засобів
+    потоку Claude, таких як `wrapAnthropicProviderStream`, допоміжні засоби
+    beta-заголовків і розбір `service_tier`.
+  - OpenAI використовує `api.js` для побудовників провайдерів, допоміжних
+    засобів моделей за замовчуванням і побудовників провайдерів реального часу.
+  - OpenRouter використовує `api.js` для свого побудовника провайдера разом із
+    допоміжними засобами онбордингу/конфігурації, тоді як `register.runtime.js`
+    усе ще може повторно експортувати загальні допоміжні засоби
+    `plugin-sdk/provider-stream` для локального використання в репозиторії.
+- Публічні точки входу, завантажені через фасад, надають перевагу активному
+  знімку конфігурації середовища виконання, якщо він існує, а потім
+  повертаються до визначеного файлу конфігурації на диску, коли OpenClaw ще не
+  обслуговує знімок середовища виконання.
+- Загальні спільні примітиви залишаються бажаним публічним контрактом SDK.
+  Невеликий зарезервований набір допоміжних швів із брендингом вбудованих
+  каналів усе ще існує. Розглядайте їх як шви для супроводу вбудованих рішень/
+  сумісності, а не як нові цілі імпорту для сторонніх рішень; нові
+  міжканальні контракти, як і раніше, мають потрапляти до загальних підшляхів
+  `plugin-sdk/*` або до локальних панелей плагіна `api.js` /
   `runtime-api.js`.
 
 Примітка щодо сумісності:
 
-- Уникайте кореневого бареля `openclaw/plugin-sdk` у новому коді.
+- Уникайте кореневої панелі `openclaw/plugin-sdk` у новому коді.
 - Спочатку надавайте перевагу вузьким стабільним примітивам. Новіші підшляхи setup/pairing/reply/
   feedback/contract/inbound/threading/command/secret-input/webhook/infra/
   allowlist/status/message-tool є бажаним контрактом для нової роботи з
   вбудованими та зовнішніми плагінами.
-  Розбір/зіставлення цілей має розміщуватися в `openclaw/plugin-sdk/channel-targets`.
-  Обмеження дій повідомлень і допоміжні засоби для id повідомлень реакцій мають розміщуватися в
-  `openclaw/plugin-sdk/channel-actions`.
-- Барелі допоміжних засобів, специфічні для вбудованих розширень, не є стабільними за замовчуванням. Якщо
-  допоміжний засіб потрібен лише вбудованому розширенню, тримайте його за локальною
-  межею `api.js` або `runtime-api.js` цього розширення замість просування його до
+  Розбір/зіставлення цілей має належати до `openclaw/plugin-sdk/channel-targets`.
+  Обмежувачі дій повідомлень і допоміжні засоби для id повідомлень реакцій мають
+  належати до `openclaw/plugin-sdk/channel-actions`.
+- Панелі допоміжних засобів, специфічні для вбудованих розширень, за
+  замовчуванням не є стабільними. Якщо допоміжний засіб потрібен лише
+  вбудованому розширенню, тримайте його за локальним швом `api.js` або
+  `runtime-api.js` цього розширення замість просування до
   `openclaw/plugin-sdk/<extension>`.
-- Нові спільні межі допоміжних засобів мають бути загальними, а не брендованими під канал. Спільний розбір
-  цілей має належати `openclaw/plugin-sdk/channel-targets`; внутрішні компоненти, специфічні для каналу,
-  мають залишатися за локальною межею `api.js` або `runtime-api.js` плагіна-власника.
+- Нові спільні шви допоміжних засобів мають бути загальними, а не брендованими
+  під канал. Спільний розбір цілей має належати до
+  `openclaw/plugin-sdk/channel-targets`; внутрішні компоненти, специфічні для
+  каналу, залишаються за локальним швом `api.js` або `runtime-api.js` плагіна-власника.
 - Підшляхи, специфічні для можливостей, такі як `image-generation`,
-  `media-understanding` і `speech`, існують, оскільки вбудовані/нативні плагіни використовують
-  їх сьогодні. Їхня наявність сама по собі не означає, що кожен експортований допоміжний засіб є
-  довгостроковим замороженим зовнішнім контрактом.
+  `media-understanding` і `speech`, існують, оскільки вбудовані/власні плагіни
+  вже використовують їх сьогодні. Їхня наявність сама по собі не означає, що
+  кожен експортований допоміжний засіб є довгостроковим замороженим зовнішнім контрактом.
 
 ## Схеми інструмента повідомлень
 
-Плагіни мають володіти внесками в схему `describeMessageTool(...)`, специфічними для каналу.
-Тримайте поля, специфічні для провайдера, у плагіні, а не в спільному ядрі.
+Плагіни мають володіти внесками в схему `describeMessageTool(...)`, специфічними
+для каналу. Тримайте поля, специфічні для провайдера, у плагіні, а не в
+спільному ядрі.
 
-Для спільних переносимих фрагментів схеми повторно використовуйте загальні допоміжні засоби,
-експортовані через `openclaw/plugin-sdk/channel-actions`:
+Для спільних переносимих фрагментів схеми повторно використовуйте загальні
+допоміжні засоби, експортовані через `openclaw/plugin-sdk/channel-actions`:
 
-- `createMessageToolButtonsSchema()` для payload у стилі сітки кнопок
-- `createMessageToolCardSchema()` для payload структурованих карток
+- `createMessageToolButtonsSchema()` для корисного навантаження у стилі сітки кнопок
+- `createMessageToolCardSchema()` для структурованого корисного навантаження карток
 
 Якщо форма схеми має сенс лише для одного провайдера, визначайте її у власному
-вихідному коді цього плагіна замість просування до спільного SDK.
+джерелі цього плагіна замість просування до спільного SDK.
 
 ## Визначення цілей каналу
 
-Плагіни каналів мають володіти семантикою цілей, специфічною для каналу. Тримайте спільний
-вихідний хост загальним і використовуйте поверхню адаптера обміну повідомленнями для правил провайдера:
+Плагіни каналів мають володіти семантикою цілей, специфічною для каналу.
+Тримайте спільний outbound host загальним і використовуйте поверхню адаптера
+обміну повідомленнями для правил провайдера:
 
-- `messaging.inferTargetChatType({ to })` визначає, чи слід трактувати нормалізовану ціль
-  як `direct`, `group` або `channel` до пошуку в каталозі.
-- `messaging.targetResolver.looksLikeId(raw, normalized)` повідомляє ядру, чи
-  слід для вводу одразу перейти до визначення за схожістю з id замість пошуку в каталозі.
-- `messaging.targetResolver.resolveTarget(...)` — це резервний механізм плагіна, коли
-  ядру потрібне остаточне визначення, що належить провайдеру, після нормалізації або
-  після промаху пошуку в каталозі.
-- `messaging.resolveOutboundSessionRoute(...)` володіє побудовою маршруту вихідної сесії, специфічною для провайдера,
-  після того як ціль визначено.
+- `messaging.inferTargetChatType({ to })` визначає, чи слід розглядати
+  нормалізовану ціль як `direct`, `group` або `channel` до пошуку в каталозі.
+- `messaging.targetResolver.looksLikeId(raw, normalized)` повідомляє ядру,
+  чи слід вводу відразу перейти до визначення за схожістю з id замість пошуку
+  в каталозі.
+- `messaging.targetResolver.resolveTarget(...)` — це резервний варіант
+  плагіна, коли ядру потрібне остаточне визначення, що належить провайдеру,
+  після нормалізації або після промаху в каталозі.
+- `messaging.resolveOutboundSessionRoute(...)` володіє побудовою маршруту сесії,
+  специфічною для провайдера, щойно ціль визначено.
 
 Рекомендований поділ:
 
-- Використовуйте `inferTargetChatType` для рішень щодо категорій, які мають відбуватися до
-  пошуку серед співрозмовників/груп.
-- Використовуйте `looksLikeId` для перевірок «трактувати це як явний/native id цілі».
-- Використовуйте `resolveTarget` для резервної нормалізації, специфічної для провайдера, а не для
-  широкого пошуку в каталозі.
-- Тримайте native id провайдера, такі як chat id, thread id, JID, handles і room
-  ids, усередині значень `target` або параметрів, специфічних для провайдера, а не в загальних полях SDK.
+- Використовуйте `inferTargetChatType` для рішень щодо категорій, які мають
+  прийматися до пошуку серед контактів/груп.
+- Використовуйте `looksLikeId` для перевірок типу «розглядати це як явний/нативний id цілі».
+- Використовуйте `resolveTarget` для резервної нормалізації, специфічної для провайдера, а не для широкого пошуку в каталозі.
+- Тримайте нативні для провайдера id, такі як chat id, thread id, JID, handle
+  і room id, усередині значень `target` або параметрів, специфічних для
+  провайдера, а не в загальних полях SDK.
 
 ## Каталоги на основі конфігурації
 
-Плагіни, які виводять записи каталогу з конфігурації, мають тримати цю логіку в
-плагіні та повторно використовувати спільні допоміжні засоби з
+Плагіни, які формують записи каталогу з конфігурації, мають тримати цю логіку
+в плагіні та повторно використовувати спільні допоміжні засоби з
 `openclaw/plugin-sdk/directory-runtime`.
 
-Використовуйте це, коли каналу потрібні каталоги співрозмовників/груп на основі конфігурації, такі як:
+Використовуйте це, коли каналу потрібні каталоги контактів/груп на основі
+конфігурації, наприклад:
 
-- DM-співрозмовники, керовані списком дозволу
+- контакти DM, керовані allowlist
 - налаштовані відображення каналів/груп
 - статичні резервні варіанти каталогу в межах облікового запису
 
@@ -1267,71 +1342,76 @@ api.registerHttpRoute({
 
 - фільтрацію запитів
 - застосування обмежень
-- допоміжні засоби усунення дублікатів/нормалізації
+- допоміжні засоби дедуплікації/нормалізації
 - побудову `ChannelDirectoryEntry[]`
 
-Інспекція облікових записів і нормалізація id, специфічні для каналу, мають залишатися
-в реалізації плагіна.
+Перевірка облікового запису та нормалізація id, специфічні для каналу, мають
+залишатися в реалізації плагіна.
 
 ## Каталоги провайдерів
 
-Плагіни провайдерів можуть визначати каталоги моделей для висновку через
-`registerProvider({ catalog: { run(...) { ... } } })`.
+Плагіни провайдерів можуть визначати каталоги моделей для висновку за
+допомогою `registerProvider({ catalog: { run(...) { ... } } })`.
 
 `catalog.run(...)` повертає ту саму форму, яку OpenClaw записує в
 `models.providers`:
 
 - `{ provider }` для одного запису провайдера
-- `{ providers }` для кількох записів провайдера
+- `{ providers }` для кількох записів провайдерів
 
-Використовуйте `catalog`, коли плагін володіє id моделей, специфічними для провайдера, стандартними значеннями base URL або метаданими моделей, обмеженими автентифікацією.
+Використовуйте `catalog`, коли плагін володіє id моделей, значеннями `base URL`
+за замовчуванням або метаданими моделей, обмеженими автентифікацією.
 
-`catalog.order` контролює, коли каталог плагіна об’єднується відносно
-вбудованих неявних провайдерів OpenClaw:
+`catalog.order` керує тим, коли каталог плагіна зливається відносно вбудованих
+неявних провайдерів OpenClaw:
 
-- `simple`: звичайні провайдери з API-ключем або керовані env
-- `profile`: провайдери, які з’являються, коли існують профілі автентифікації
-- `paired`: провайдери, які синтезують кілька пов’язаних записів провайдера
-- `late`: останній прохід, після інших неявних провайдерів
+- `simple`: прості провайдери на основі API-ключа або env
+- `profile`: провайдери, які з’являються за наявності профілів автентифікації
+- `paired`: провайдери, які синтезують кілька пов’язаних записів провайдерів
+- `late`: останній прохід після інших неявних провайдерів
 
-Пізніші провайдери перемагають у разі колізії ключів, тому плагіни можуть навмисно
-перевизначати вбудований запис провайдера з тим самим id провайдера.
+Пізніші провайдери перемагають при конфлікті ключів, тому плагіни можуть
+свідомо перевизначати вбудований запис провайдера з тим самим id провайдера.
 
 Сумісність:
 
 - `discovery` усе ще працює як застарілий псевдонім
 - якщо зареєстровано і `catalog`, і `discovery`, OpenClaw використовує `catalog`
 
-## Інспекція каналу лише для читання
+## Канали лише для читання
 
 Якщо ваш плагін реєструє канал, надавайте перевагу реалізації
 `plugin.config.inspectAccount(cfg, accountId)` поряд із `resolveAccount(...)`.
 
 Чому:
 
-- `resolveAccount(...)` — це шлях середовища виконання. Він може припускати, що облікові дані
-  повністю матеріалізовані, і швидко завершуватися з помилкою, коли бракує потрібних секретів.
-- Шляхи команд лише для читання, такі як `openclaw status`, `openclaw status --all`,
-  `openclaw channels status`, `openclaw channels resolve` і потоки виправлення doctor/config,
-  не повинні потребувати матеріалізації облікових даних середовища виконання лише для опису конфігурації.
+- `resolveAccount(...)` — це шлях середовища виконання. Він може припускати,
+  що облікові дані повністю матеріалізовані, і швидко завершуватися помилкою,
+  якщо потрібних секретів бракує.
+- Шляхи команд лише для читання, такі як `openclaw status`,
+  `openclaw status --all`, `openclaw channels status`,
+  `openclaw channels resolve` і потоки відновлення doctor/config, не повинні
+  матеріалізувати облікові дані середовища виконання лише для опису конфігурації.
 
 Рекомендована поведінка `inspectAccount(...)`:
 
 - Повертайте лише описовий стан облікового запису.
 - Зберігайте `enabled` і `configured`.
-- Додавайте поля джерела/статусу облікових даних, коли це доречно, наприклад:
+- За потреби включайте поля джерела/стану облікових даних, наприклад:
   - `tokenSource`, `tokenStatus`
   - `botTokenSource`, `botTokenStatus`
   - `appTokenSource`, `appTokenStatus`
   - `signingSecretSource`, `signingSecretStatus`
-- Вам не потрібно повертати сирі значення токенів лише для повідомлення про доступність у режимі тільки читання. Достатньо повернути `tokenStatus: "available"` (і відповідне поле джерела).
-- Використовуйте `configured_unavailable`, коли облікові дані налаштовано через SecretRef, але
-  вони недоступні в поточному шляху команди.
+- Вам не потрібно повертати сирі значення токенів лише для повідомлення про
+  доступність у режимі лише читання. Повернення `tokenStatus: "available"`
+  (і відповідного поля джерела) достатньо для команд на кшталт status.
+- Використовуйте `configured_unavailable`, коли облікові дані налаштовані через SecretRef, але недоступні в поточному шляху команди.
 
-Це дозволяє командам лише для читання повідомляти «налаштовано, але недоступно в цьому шляху команди»
-замість аварійного завершення або хибного повідомлення, що обліковий запис не налаштовано.
+Це дозволяє командам лише для читання повідомляти «налаштовано, але недоступно
+в цьому шляху команди» замість аварійного завершення або хибного повідомлення,
+що обліковий запис не налаштовано.
 
-## Набори пакетів
+## Package packs
 
 Каталог плагіна може містити `package.json` з `openclaw.extensions`:
 
@@ -1345,63 +1425,71 @@ api.registerHttpRoute({
 }
 ```
 
-Кожен запис стає плагіном. Якщо набір перелічує кілька розширень, id плагіна
+Кожен запис стає плагіном. Якщо пакет перераховує кілька розширень, id плагіна
 стає `name/<fileBase>`.
 
-Якщо ваш плагін імпортує npm-залежності, встановіть їх у цьому каталозі, щоб
+Якщо ваш плагін імпортує залежності npm, установіть їх у цьому каталозі, щоб
 `node_modules` був доступний (`npm install` / `pnpm install`).
 
-Захисне обмеження безпеки: кожен запис `openclaw.extensions` має залишатися в межах каталогу плагіна
-після визначення символьних посилань. Записи, які виходять за межі каталогу пакета, відхиляються.
+Захисне обмеження безпеки: кожен запис `openclaw.extensions` має залишатися
+всередині каталогу плагіна після визначення символічних посилань. Записи, що
+виходять за межі каталогу пакета, відхиляються.
 
-Примітка щодо безпеки: `openclaw plugins install` встановлює залежності плагіна через
-`npm install --omit=dev --ignore-scripts` (без lifecycle scripts, без dev-залежностей під час виконання). Тримайте дерева залежностей плагіна «чистими JS/TS» і уникайте пакетів, які потребують збирання через `postinstall`.
+Примітка щодо безпеки: `openclaw plugins install` встановлює залежності плагіна
+за допомогою `npm install --omit=dev --ignore-scripts` (без lifecycle scripts і
+без dev-залежностей у середовищі виконання). Зберігайте дерева залежностей
+плагінів «чистими JS/TS» і уникайте пакетів, які потребують збірок `postinstall`.
 
-Необов’язково: `openclaw.setupEntry` може вказувати на легкий модуль лише для налаштування.
-Коли OpenClaw потребує поверхонь налаштування для вимкненого плагіна каналу, або
-коли плагін каналу увімкнено, але він усе ще не налаштований, він завантажує `setupEntry`
-замість повної точки входу плагіна. Це зберігає запуск і налаштування легшими,
-коли ваша основна точка входу плагіна також підключає інструменти, хуки або інший код,
-призначений лише для середовища виконання.
+Необов’язково: `openclaw.setupEntry` може вказувати на легкий модуль лише для
+налаштування. Коли OpenClaw потребує поверхонь налаштування для вимкненого
+плагіна каналу або коли плагін каналу увімкнено, але ще не налаштовано, він
+завантажує `setupEntry` замість повної точки входу плагіна. Це робить запуск і
+налаштування легшими, коли основна точка входу плагіна також підключає
+інструменти, хуки чи інший код лише для середовища виконання.
 
 Необов’язково: `openclaw.startup.deferConfiguredChannelFullLoadUntilAfterListen`
-може перевести плагін каналу на той самий шлях `setupEntry` під час фази запуску gateway
-до початку прослуховування, навіть коли канал уже налаштовано.
+може перевести плагін каналу на той самий шлях `setupEntry` під час передслухової
+фази запуску gateway, навіть якщо канал уже налаштовано.
 
-Використовуйте це лише тоді, коли `setupEntry` повністю покриває поверхню запуску, яка має існувати
-до того, як gateway почне прослуховування. На практиці це означає, що точка входу налаштування
-має зареєструвати всі можливості, що належать каналу та від яких залежить запуск, зокрема:
+Використовуйте це лише тоді, коли `setupEntry` повністю покриває поверхню
+запуску, яка має існувати до того, як gateway почне слухати. На практиці це
+означає, що точка входу налаштування має реєструвати кожну можливість каналу,
+від якої залежить запуск, зокрема:
 
 - саму реєстрацію каналу
-- будь-які HTTP-маршрути, які мають бути доступні до початку прослуховування gateway
-- будь-які методи gateway, інструменти або сервіси, які мають існувати протягом цього самого вікна
+- будь-які HTTP-маршрути, які мають бути доступні до того, як gateway почне слухати
+- будь-які методи gateway, інструменти або сервіси, які мають існувати в цей самий проміжок часу
 
-Якщо ваша повна точка входу все ще володіє будь-якою необхідною можливістю запуску, не вмикайте
-цей прапорець. Залишайте плагін на стандартній поведінці та дозвольте OpenClaw завантажити
-повну точку входу під час запуску.
+Якщо ваша повна точка входу все ще володіє будь-якою потрібною можливістю
+запуску, не вмикайте цей прапорець. Залиште плагін на типовій поведінці й
+дозвольте OpenClaw завантажити повну точку входу під час запуску.
 
-Вбудовані канали також можуть публікувати допоміжні засоби поверхні контракту лише для налаштування, з якими ядро
-може консультуватися до завантаження повного середовища виконання каналу. Поточна поверхня
-просування налаштування така:
+Вбудовані канали також можуть публікувати допоміжні засоби поверхні контракту
+лише для налаштування, з якими ядро може звірятися до завантаження повного
+середовища виконання каналу. Поточна поверхня просування налаштування така:
 
 - `singleAccountKeysToMove`
 - `namedAccountPromotionKeys`
 - `resolveSingleAccountPromotionTarget(...)`
 
-Ядро використовує цю поверхню, коли йому потрібно просунути застарілу конфігурацію каналу з одним обліковим записом до
-`channels.<id>.accounts.*` без завантаження повної точки входу плагіна.
-Matrix є поточним вбудованим прикладом: він переносить лише ключі auth/bootstrap у
-іменований просунутий обліковий запис, коли іменовані облікові записи вже існують, і може
-зберігати налаштований неканонічний ключ default-account замість того, щоб завжди створювати
-`accounts.default`.
+Ядро використовує цю поверхню, коли йому потрібно просунути застарілу
+конфігурацію каналу з одним обліковим записом у `channels.<id>.accounts.*`
+без завантаження повної точки входу плагіна. Поточний вбудований приклад —
+Matrix: він переносить лише ключі auth/bootstrap до іменованого просунутого
+облікового запису, коли іменовані облікові записи вже існують, і може
+зберегти налаштований неканонічний ключ облікового запису за замовчуванням
+замість того, щоб завжди створювати `accounts.default`.
 
-Ці адаптери патчів налаштування зберігають ледаче виявлення поверхні контракту вбудованих компонентів. Час
-імпорту залишається малим; поверхня просування завантажується лише під час першого використання, а не через повторний вхід у запуск вбудованого каналу під час імпорту модуля.
+Ці адаптери патчів налаштування зберігають ліниве виявлення поверхні контракту
+вбудованих рішень. Час імпорту залишається малим; поверхня просування
+завантажується лише під час першого використання замість повторного входу в
+запуск вбудованого каналу під час імпорту модуля.
 
-Коли ці поверхні запуску включають методи Gateway RPC, тримайте їх на
-префіксі, специфічному для плагіна. Простори імен адміністратора ядра (`config.*`,
-`exec.approvals.*`, `wizard.*`, `update.*`) залишаються зарезервованими та завжди визначаються
-як `operator.admin`, навіть якщо плагін запитує вужчу область.
+Коли ці поверхні запуску включають методи Gateway RPC, тримайте їх під
+префіксом, специфічним для плагіна. Простори імен адміністратора ядра
+(`config.*`, `exec.approvals.*`, `wizard.*`, `update.*`) залишаються
+зарезервованими й завжди визначаються як `operator.admin`, навіть якщо плагін
+запитує вужчу область.
 
 Приклад:
 
@@ -1420,8 +1508,8 @@ Matrix є поточним вбудованим прикладом: він пе
 
 ### Метадані каталогу каналів
 
-Плагіни каналів можуть рекламувати метадані налаштування/виявлення через `openclaw.channel` і
-підказки встановлення через `openclaw.install`. Це дозволяє ядру не містити даних каталогу.
+Плагіни каналів можуть оголошувати метадані налаштування/виявлення через `openclaw.channel`, а
+підказки встановлення — через `openclaw.install`. Це дозволяє ядру не містити даних каталогу.
 
 Приклад:
 
@@ -1436,7 +1524,7 @@ Matrix є поточним вбудованим прикладом: він пе
       "selectionLabel": "Nextcloud Talk (self-hosted)",
       "docsPath": "/channels/nextcloud-talk",
       "docsLabel": "nextcloud-talk",
-      "blurb": "Самостійно розгорнутий чат через ботів вебхуків Nextcloud Talk.",
+      "blurb": "Self-hosted chat via Nextcloud Talk webhook bots.",
       "order": 65,
       "aliases": ["nc-talk", "nc"]
     },
@@ -1452,37 +1540,40 @@ Matrix є поточним вбудованим прикладом: він пе
 Корисні поля `openclaw.channel` понад мінімальний приклад:
 
 - `detailLabel`: вторинна мітка для багатших поверхонь каталогу/статусу
-- `docsLabel`: перевизначення тексту посилання для посилання на документацію
-- `preferOver`: id плагінів/каналів із нижчим пріоритетом, які цей запис каталогу має випереджати
+- `docsLabel`: перевизначає текст посилання на документацію
+- `preferOver`: id плагінів/каналів з нижчим пріоритетом, які цей запис каталогу має випереджати
 - `selectionDocsPrefix`, `selectionDocsOmitLabel`, `selectionExtras`: елементи керування текстом поверхні вибору
-- `markdownCapable`: позначає канал як сумісний із markdown для рішень щодо вихідного форматування
+- `markdownCapable`: позначає канал як здатний працювати з markdown для рішень щодо форматування вихідних даних
 - `exposure.configured`: приховує канал із поверхонь списку налаштованих каналів, якщо встановлено `false`
 - `exposure.setup`: приховує канал з інтерактивних засобів вибору налаштування/конфігурації, якщо встановлено `false`
 - `exposure.docs`: позначає канал як внутрішній/приватний для поверхонь навігації документації
 - `showConfigured` / `showInSetup`: застарілі псевдоніми, які все ще приймаються для сумісності; надавайте перевагу `exposure`
-- `quickstartAllowFrom`: додає канал до стандартного потоку `allowFrom` для швидкого старту
+- `quickstartAllowFrom`: додає канал до стандартного потоку quickstart `allowFrom`
 - `forceAccountBinding`: вимагає явного прив’язування облікового запису, навіть якщо існує лише один обліковий запис
-- `preferSessionLookupForAnnounceTarget`: надає перевагу пошуку сесії під час визначення цілей оголошення
+- `preferSessionLookupForAnnounceTarget`: надає перевагу пошуку сесії під час визначення announce target
 
 OpenClaw також може об’єднувати **зовнішні каталоги каналів** (наприклад, експорт
-реєстру MPM). Помістіть JSON-файл в одне з таких місць:
+реєстру 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"`.
+один або кілька JSON-файлів (розділених комою/крапкою з комою/роздільником `PATH`).
+Кожен файл має містити
+`{ "entries": [ { "name": "@scope/pkg", "openclaw": { "channel": {...}, "install": {...} } } ] }`.
+Парсер також приймає `"packages"` або `"plugins"` як застарілі псевдоніми для
+ключа `"entries"`.
 
-## Плагіни механізму контексту
+## Плагіни рушія контексту
 
-Плагіни механізму контексту володіють оркестрацією контексту сесії для поглинання, збирання
-та ущільнення. Реєструйте їх із вашого плагіна через
-`api.registerContextEngine(id, factory)`, а потім вибирайте активний механізм через
+Плагіни рушія контексту володіють оркестрацією контексту сесії для поглинання,
+збирання та компакції. Реєструйте їх із вашого плагіна через
+`api.registerContextEngine(id, factory)`, а потім вибирайте активний рушій через
 `plugins.slots.contextEngine`.
 
-Використовуйте це, коли вашому плагіну потрібно замінити або розширити стандартний
+Використовуйте це, коли вашому плагіну потрібно замінити або розширити типовий
 конвеєр контексту, а не просто додати пошук у пам’яті або хуки.
 
 ```ts
@@ -1511,8 +1602,8 @@ export default function (api) {
 }
 ```
 
-Якщо ваш механізм **не** володіє алгоритмом ущільнення, залишайте `compact()`
-реалізованим і явно делегуйте його:
+Якщо ваш рушій **не** володіє алгоритмом компакції, залиште `compact()`
+реалізованим і явно делегуйте її:
 
 ```ts
 import {
@@ -1550,45 +1641,47 @@ export default function (api) {
 ## Додавання нової можливості
 
 Коли плагіну потрібна поведінка, яка не вписується в поточний API, не обходьте
-систему плагінів через приватне проникнення всередину. Додайте відсутню можливість.
+систему плагінів через приватне звернення всередину. Додайте відсутню
+можливість.
 
 Рекомендована послідовність:
 
 1. визначте контракт ядра
-   Вирішіть, якою спільною поведінкою має володіти ядро: політика, резервні механізми, об’єднання конфігурації,
-   життєвий цикл, семантика, орієнтована на канали, і форма допоміжних засобів середовища виконання.
+   Визначте, якою спільною поведінкою має володіти ядро: політикою, резервними
+   варіантами, злиттям конфігурації, життєвим циклом, семантикою для каналів і
+   формою допоміжних засобів середовища виконання.
 2. додайте типізовані поверхні реєстрації/середовища виконання плагінів
-   Розширте `OpenClawPluginApi` і/або `api.runtime` найменшою корисною
+   Розширте `OpenClawPluginApi` та/або `api.runtime` найменшою корисною
    типізованою поверхнею можливості.
-3. під’єднайте споживачів ядра + каналів/функцій
-   Канали та плагіни функцій мають споживати нову можливість через ядро,
-   а не шляхом прямого імпорту реалізації постачальника.
+3. під’єднайте споживачів із ядра + каналів/функцій
+   Канали та плагіни функцій мають споживати нову можливість через ядро, а не
+   через прямий імпорт реалізації постачальника.
 4. зареєструйте реалізації постачальників
    Потім плагіни постачальників реєструють свої серверні частини для цієї можливості.
-5. додайте покриття контракту
-   Додайте тести, щоб володіння і форма реєстрації з часом залишалися явними.
+5. додайте покриття контрактів
+   Додайте тести, щоб володіння та форма реєстрації з часом залишалися явними.
 
-Саме так OpenClaw зберігає визначеність, не стаючи жорстко прив’язаним до
-світогляду одного провайдера. Дивіться [Збірник рецептів можливостей](/uk/plugins/architecture)
-для конкретного контрольного списку файлів і готового прикладу.
+Саме так OpenClaw зберігає чіткий підхід, не стаючи жорстко прив’язаним до
+світогляду одного провайдера. Конкретний контрольний список файлів і
+покроковий приклад дивіться в [Практичному посібнику із можливостей](/uk/plugins/architecture).
 
 ### Контрольний список можливостей
 
-Коли ви додаєте нову можливість, реалізація зазвичай має торкатися цих
-поверхонь разом:
+Коли ви додаєте нову можливість, реалізація зазвичай має одночасно торкатися
+цих поверхонь:
 
-- типи контракту ядра в `src/<capability>/types.ts`
-- засіб виконання/допоміжний засіб ядра в `src/<capability>/runtime.ts`
-- поверхня реєстрації API плагінів у `src/plugins/types.ts`
+- типів контракту ядра в `src/<capability>/types.ts`
+- runner-а/допоміжного засобу середовища виконання ядра в `src/<capability>/runtime.ts`
+- поверхні реєстрації API плагінів у `src/plugins/types.ts`
 - підключення реєстру плагінів у `src/plugins/registry.ts`
-- відкриття середовища виконання плагінів у `src/plugins/runtime/*`, коли плагіни функцій/каналів
-  мають це споживати
-- допоміжні засоби захоплення/тестування в `src/test-utils/plugin-registration.ts`
-- перевірки володіння/контракту в `src/plugins/contracts/registry.ts`
-- документація для операторів/плагінів у `docs/`
+- відкриття середовища виконання плагінів у `src/plugins/runtime/*`, коли
+  плагінам функцій/каналів потрібно це споживати
+- допоміжних засобів capture/test у `src/test-utils/plugin-registration.ts`
+- перевірок володіння/контрактів у `src/plugins/contracts/registry.ts`
+- документації для операторів/плагінів у `docs/`
 
-Якщо однієї з цих поверхонь бракує, це зазвичай ознака того, що можливість
-ще не повністю інтегрована.
+Якщо одна з цих поверхонь відсутня, це зазвичай ознака того, що можливість ще
+не повністю інтегрована.
 
 ### Шаблон можливості
 
@@ -1618,7 +1711,7 @@ const clip = await api.runtime.videoGeneration.generate({
 });
 ```
 
-Шаблон контрактного тесту:
+Шаблон тесту контракту:
 
 ```ts
 expect(findVideoGenerationProviderIdsForPlugin("openai")).toEqual(["openai"]);
@@ -1629,4 +1722,4 @@ expect(findVideoGenerationProviderIdsForPlugin("openai")).toEqual(["openai"]);
 - ядро володіє контрактом можливості + оркестрацією
 - плагіни постачальників володіють реалізаціями постачальників
 - плагіни функцій/каналів споживають допоміжні засоби середовища виконання
-- контрактні тести зберігають володіння явним
+- тести контрактів зберігають володіння явним
diff --git a/docs/uk/plugins/manifest.md b/docs/uk/plugins/manifest.md
index a253ce2e5..0f8b21b42 100644
--- a/docs/uk/plugins/manifest.md
+++ b/docs/uk/plugins/manifest.md
@@ -2,13 +2,13 @@
 read_when:
     - Ви створюєте плагін OpenClaw
     - Вам потрібно постачати схему конфігурації плагіна або налагоджувати помилки валідації плагіна
-summary: Вимоги до маніфесту плагіна + JSON schema (сувора валідація конфігурації)
+summary: Маніфест плагіна + вимоги до JSON schema (сувора валідація конфігурації)
 title: Маніфест плагіна
 x-i18n:
-    generated_at: "2026-04-12T02:30:56Z"
+    generated_at: "2026-04-12T08:09:11Z"
     model: gpt-5.4
     provider: openai
-    source_hash: bf666b0f41f07641375a248f52e29ba6a68c3ec20404bedb6b52a20a5cd92e91
+    source_hash: 4074b3639bf24606d6087597f28e29afc85f4ea628a713e9d984b441a16f1c13
     source_path: plugins/manifest.md
     workflow: 15
 ---
@@ -17,62 +17,57 @@ x-i18n:
 
 Ця сторінка стосується лише **власного маніфесту плагіна OpenClaw**.
 
-Сумісні макети пакунків описано в [Пакунки плагінів](/uk/plugins/bundles).
+Щоб дізнатися про сумісні макети пакетів, див. [Пакети плагінів](/uk/plugins/bundles).
 
-Сумісні формати пакунків використовують інші файли маніфесту:
+Сумісні формати пакетів використовують інші файли маніфесту:
 
-- Пакунок Codex: `.codex-plugin/plugin.json`
-- Пакунок Claude: `.claude-plugin/plugin.json` або типовий макет компонентів Claude
+- Пакет Codex: `.codex-plugin/plugin.json`
+- Пакет Claude: `.claude-plugin/plugin.json` або стандартний макет компонента Claude
   без маніфесту
-- Пакунок Cursor: `.cursor-plugin/plugin.json`
+- Пакет Cursor: `.cursor-plugin/plugin.json`
 
-OpenClaw також автоматично виявляє ці макети пакунків, але вони не проходять валідацію
+OpenClaw також автоматично виявляє ці макети пакетів, але вони не проходять валідацію
 за схемою `openclaw.plugin.json`, описаною тут.
 
-Для сумісних пакунків OpenClaw наразі зчитує метадані пакунка, а також оголошені
-кореневі каталоги skill, кореневі каталоги команд Claude, типові значення `settings.json` у пакунку Claude,
-типові значення LSP у пакунку Claude та підтримувані набори hooks, якщо макет відповідає
+Для сумісних пакетів OpenClaw наразі читає метадані пакета, а також оголошені
+кореневі каталоги skills, кореневі каталоги команд Claude, стандартні значення `settings.json` пакета Claude,
+стандартні значення LSP пакета Claude та підтримувані набори hooks, коли макет відповідає
 очікуванням середовища виконання OpenClaw.
 
-Кожен власний плагін OpenClaw **має** постачатися з файлом `openclaw.plugin.json` у
+Кожен власний плагін OpenClaw **повинен** постачатися з файлом `openclaw.plugin.json` у
 **корені плагіна**. OpenClaw використовує цей маніфест для валідації конфігурації
-**без виконання коду плагіна**. Відсутні або невалідні маніфести вважаються
-помилками плагіна та блокують валідацію конфігурації.
+**без виконання коду плагіна**. Відсутні або недійсні маніфести вважаються
+помилками плагіна й блокують валідацію конфігурації.
 
-Дивіться повний посібник із системи плагінів: [Плагіни](/uk/tools/plugin).
-Щодо власної моделі можливостей і поточних рекомендацій щодо зовнішньої сумісності:
+Див. повний посібник із системи плагінів: [Плагіни](/uk/tools/plugin).
+Щодо власної моделі можливостей і поточних вказівок щодо зовнішньої сумісності:
 [Модель можливостей](/uk/plugins/architecture#public-capability-model).
 
 ## Що робить цей файл
 
-`openclaw.plugin.json` — це метадані, які OpenClaw зчитує перед завантаженням коду
+`openclaw.plugin.json` — це метадані, які OpenClaw читає до завантаження коду
 вашого плагіна.
 
 Використовуйте його для:
 
 - ідентичності плагіна
 - валідації конфігурації
-- метаданих автентифікації та онбордингу, які мають бути доступні без запуску
-  середовища виконання плагіна
-- легковагих підказок активації, які поверхні control plane можуть перевіряти до завантаження runtime
-- легковагих дескрипторів налаштування, які поверхні setup/onboarding можуть перевіряти до завантаження
-  runtime
-- метаданих псевдонімів і автоувімкнення, які мають визначатися до завантаження runtime плагіна
-- скорочених метаданих належності до сімейств моделей, які мають автоматично активувати
-  плагін до завантаження runtime
-- статичних знімків належності можливостей, які використовуються для bundled compat wiring і
-  покриття контрактів
-- метаданих конфігурації каналу, специфічних для каналу, які мають об’єднуватися в поверхні каталогу та валідації
-  без завантаження runtime
+- метаданих автентифікації та онбордингу, які мають бути доступні без запуску середовища виконання плагіна
+- легких підказок активації, які поверхні control-plane можуть перевіряти до завантаження середовища виконання
+- легких дескрипторів налаштування, які поверхні налаштування/онбордингу можуть перевіряти до завантаження середовища виконання
+- метаданих псевдонімів і автоувімкнення, які мають визначатися до завантаження середовища виконання плагіна
+- скорочених метаданих володіння сімействами моделей, які мають автоматично активувати плагін до завантаження середовища виконання
+- статичних знімків володіння можливостями, що використовуються для wiring сумісності пакетів і покриття контрактів
+- метаданих конфігурації каналів, які мають об’єднуватися з поверхнями каталогу та валідації без завантаження середовища виконання
 - підказок UI для конфігурації
 
 Не використовуйте його для:
 
-- реєстрації поведінки runtime
-- оголошення entrypoint коду
+- реєстрації поведінки середовища виконання
+- оголошення кодових entrypoint
 - метаданих встановлення npm
 
-Це належить вашому коду плагіна та `package.json`.
+Це належить коду вашого плагіна та `package.json`.
 
 ## Мінімальний приклад
 
@@ -93,7 +88,7 @@ OpenClaw також автоматично виявляє ці макети па
 {
   "id": "openrouter",
   "name": "OpenRouter",
-  "description": "OpenRouter provider plugin",
+  "description": "Плагін провайдера OpenRouter",
   "version": "1.0.0",
   "providers": ["openrouter"],
   "modelSupport": {
@@ -114,19 +109,19 @@ OpenClaw також автоматично виявляє ці макети па
       "provider": "openrouter",
       "method": "api-key",
       "choiceId": "openrouter-api-key",
-      "choiceLabel": "OpenRouter API key",
+      "choiceLabel": "Ключ API OpenRouter",
       "groupId": "openrouter",
       "groupLabel": "OpenRouter",
       "optionKey": "openrouterApiKey",
       "cliFlag": "--openrouter-api-key",
       "cliOption": "--openrouter-api-key <key>",
-      "cliDescription": "OpenRouter API key",
+      "cliDescription": "Ключ API OpenRouter",
       "onboardingScopes": ["text-inference"]
     }
   ],
   "uiHints": {
     "apiKey": {
-      "label": "API key",
+      "label": "Ключ API",
       "placeholder": "sk-or-v1-...",
       "sensitive": true
     }
@@ -147,60 +142,60 @@ OpenClaw також автоматично виявляє ці макети па
 
 | Поле                                | Обов’язкове | Тип                              | Що воно означає                                                                                                                                                                                              |
 | ----------------------------------- | ----------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `id`                                | Так         | `string`                         | Канонічний id плагіна. Це id, який використовується в `plugins.entries.<id>`.                                                                                                                               |
+| `id`                                | Так         | `string`                         | Канонічний ідентифікатор плагіна. Це ідентифікатор, який використовується в `plugins.entries.<id>`.                                                                                                        |
 | `configSchema`                      | Так         | `object`                         | Вбудована JSON Schema для конфігурації цього плагіна.                                                                                                                                                        |
-| `enabledByDefault`                  | Ні          | `true`                           | Позначає bundled plugin як увімкнений за замовчуванням. Опустіть це поле або встановіть будь-яке значення, відмінне від `true`, щоб плагін залишався вимкненим за замовчуванням.                          |
-| `legacyPluginIds`                   | Ні          | `string[]`                       | Застарілі id, які нормалізуються до цього канонічного id плагіна.                                                                                                                                            |
-| `autoEnableWhenConfiguredProviders` | Ні          | `string[]`                       | Id провайдерів, які мають автоматично вмикати цей плагін, коли на них посилаються auth, config або model refs.                                                                                              |
-| `kind`                              | Ні          | `"memory"` \| `"context-engine"` | Оголошує виключний тип плагіна, який використовується `plugins.slots.*`.                                                                                                                                     |
-| `channels`                          | Ні          | `string[]`                       | Id каналів, якими володіє цей плагін. Використовуються для виявлення та валідації конфігурації.                                                                                                             |
-| `providers`                         | Ні          | `string[]`                       | Id провайдерів, якими володіє цей плагін.                                                                                                                                                                     |
-| `modelSupport`                      | Ні          | `object`                         | Скорочені метадані сімейств моделей, якими володіє маніфест, що використовуються для автоматичного завантаження плагіна до runtime.                                                                        |
-| `cliBackends`                       | Ні          | `string[]`                       | Id backend для висновування в CLI, якими володіє цей плагін. Використовуються для автоматичної активації під час запуску з явних посилань у config.                                                        |
-| `commandAliases`                    | Ні          | `object[]`                       | Назви команд, якими володіє цей плагін, і які мають створювати діагностику конфігурації та CLI з урахуванням плагіна до завантаження runtime.                                                              |
-| `providerAuthEnvVars`               | Ні          | `Record<string, string[]>`       | Легковагі метадані env для auth провайдера, які OpenClaw може перевіряти без завантаження коду плагіна.                                                                                                     |
-| `providerAuthAliases`               | Ні          | `Record<string, string>`         | Id провайдерів, які мають повторно використовувати інший id провайдера для пошуку auth, наприклад coding provider, що спільно використовує API key базового провайдера та профілі auth.                  |
-| `channelEnvVars`                    | Ні          | `Record<string, string[]>`       | Легковагі метадані env каналу, які OpenClaw може перевіряти без завантаження коду плагіна. Використовуйте це для налаштування каналів через env або поверхонь auth, які мають бачити загальні helpers запуску/config. |
-| `providerAuthChoices`               | Ні          | `object[]`                       | Легковагі метадані вибору auth для picker-ів онбордингу, визначення preferred provider і простого зв’язування прапорців CLI.                                                                                |
-| `activation`                        | Ні          | `object`                         | Легковагі підказки активації для завантаження, що запускається провайдером, командою, каналом, маршрутом або можливістю. Лише метадані; фактичною поведінкою як і раніше володіє runtime плагіна.        |
-| `setup`                             | Ні          | `object`                         | Легковагі дескриптори setup/onboarding, які поверхні виявлення та налаштування можуть перевіряти без завантаження runtime плагіна.                                                                          |
-| `contracts`                         | Ні          | `object`                         | Статичний знімок bundled capability для speech, realtime transcription, realtime voice, media-understanding, image-generation, music-generation, video-generation, web-fetch, web search і належності tool. |
-| `channelConfigs`                    | Ні          | `Record<string, object>`         | Метадані конфігурації каналу, якими володіє маніфест, що об’єднуються в поверхні виявлення та валідації до завантаження runtime.                                                                            |
+| `enabledByDefault`                  | Ні          | `true`                           | Позначає пакетний плагін як увімкнений за замовчуванням. Пропустіть це поле або встановіть будь-яке значення, відмінне від `true`, щоб залишити плагін вимкненим за замовчуванням.                        |
+| `legacyPluginIds`                   | Ні          | `string[]`                       | Застарілі ідентифікатори, які нормалізуються до цього канонічного ідентифікатора плагіна.                                                                                                                   |
+| `autoEnableWhenConfiguredProviders` | Ні          | `string[]`                       | Ідентифікатори провайдерів, які мають автоматично вмикати цей плагін, коли автентифікація, конфігурація або посилання на моделі згадують їх.                                                              |
+| `kind`                              | Ні          | `"memory"` \| `"context-engine"` | Оголошує ексклюзивний тип плагіна, що використовується в `plugins.slots.*`.                                                                                                                                 |
+| `channels`                          | Ні          | `string[]`                       | Ідентифікатори каналів, якими володіє цей плагін. Використовується для виявлення та валідації конфігурації.                                                                                                |
+| `providers`                         | Ні          | `string[]`                       | Ідентифікатори провайдерів, якими володіє цей плагін.                                                                                                                                                        |
+| `modelSupport`                      | Ні          | `object`                         | Скорочені метадані сімейств моделей, що належать маніфесту та використовуються для автоматичного завантаження плагіна до запуску середовища виконання.                                                    |
+| `cliBackends`                       | Ні          | `string[]`                       | Ідентифікатори backend виведення CLI, якими володіє цей плагін. Використовуються для автоматичної активації під час запуску з явних посилань конфігурації.                                                |
+| `commandAliases`                    | Ні          | `object[]`                       | Назви команд, якими володіє цей плагін і які мають створювати діагностику конфігурації та CLI з урахуванням плагіна до завантаження середовища виконання.                                                 |
+| `providerAuthEnvVars`               | Ні          | `Record<string, string[]>`       | Легкі метадані змінних середовища для автентифікації провайдера, які OpenClaw може перевіряти без завантаження коду плагіна.                                                                              |
+| `providerAuthAliases`               | Ні          | `Record<string, string>`         | Ідентифікатори провайдерів, які мають повторно використовувати інший ідентифікатор провайдера для пошуку автентифікації, наприклад провайдер кодування, що спільно використовує ключ API базового провайдера та профілі автентифікації. |
+| `channelEnvVars`                    | Ні          | `Record<string, string[]>`       | Легкі метадані змінних середовища каналу, які OpenClaw може перевіряти без завантаження коду плагіна. Використовуйте це для поверхонь налаштування або автентифікації каналів через змінні середовища, які мають бачити загальні допоміжні засоби запуску/конфігурації. |
+| `providerAuthChoices`               | Ні          | `object[]`                       | Легкі метадані варіантів автентифікації для селекторів онбордингу, визначення пріоритетного провайдера та простого wiring прапорців CLI.                                                                   |
+| `activation`                        | Ні          | `object`                         | Легкі підказки активації для завантаження, яке запускається провайдером, командою, каналом, маршрутом і можливістю. Лише метадані; фактичною поведінкою все одно володіє середовище виконання плагіна. |
+| `setup`                             | Ні          | `object`                         | Легкі дескриптори налаштування/онбордингу, які поверхні виявлення та налаштування можуть перевіряти без завантаження середовища виконання плагіна.                                                         |
+| `contracts`                         | Ні          | `object`                         | Статичний знімок можливостей пакетного плагіна для speech, realtime transcription, realtime voice, media-understanding, image-generation, music-generation, video-generation, web-fetch, web search і володіння інструментами. |
+| `channelConfigs`                    | Ні          | `Record<string, object>`         | Метадані конфігурації каналів, що належать маніфесту та об’єднуються з поверхнями виявлення та валідації до завантаження середовища виконання.                                                            |
 | `skills`                            | Ні          | `string[]`                       | Каталоги Skills для завантаження, відносно кореня плагіна.                                                                                                                                                   |
-| `name`                              | Ні          | `string`                         | Людинозрозуміла назва плагіна.                                                                                                                                                                                |
-| `description`                       | Ні          | `string`                         | Короткий опис, що показується в поверхнях плагіна.                                                                                                                                                           |
+| `name`                              | Ні          | `string`                         | Людинозрозуміла назва плагіна.                                                                                                                                                                               |
+| `description`                       | Ні          | `string`                         | Короткий опис, що показується на поверхнях плагіна.                                                                                                                                                          |
 | `version`                           | Ні          | `string`                         | Інформаційна версія плагіна.                                                                                                                                                                                 |
-| `uiHints`                           | Ні          | `Record<string, object>`         | Мітки UI, placeholders і підказки щодо чутливості для полів конфігурації.                                                                                                                                    |
+| `uiHints`                           | Ні          | `Record<string, object>`         | Підписи UI, заповнювачі та підказки щодо чутливості для полів конфігурації.                                                                                                                                  |
 
 ## Довідник `providerAuthChoices`
 
-Кожен запис `providerAuthChoices` описує один варіант онбордингу або auth.
-OpenClaw зчитує це до завантаження runtime провайдера.
+Кожен запис `providerAuthChoices` описує один варіант онбордингу або автентифікації.
+OpenClaw читає це до завантаження середовища виконання провайдера.
 
-| Поле                  | Обов’язкове | Тип                                             | Що воно означає                                                                                           |
-| --------------------- | ----------- | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
-| `provider`            | Так         | `string`                                        | Id провайдера, до якого належить цей варіант.                                                             |
-| `method`              | Так         | `string`                                        | Id методу auth, до якого слід диспетчеризувати.                                                           |
-| `choiceId`            | Так         | `string`                                        | Стабільний id варіанта auth, який використовується в потоках онбордингу та CLI.                          |
-| `choiceLabel`         | Ні          | `string`                                        | Мітка для користувача. Якщо її не вказано, OpenClaw використовує `choiceId`.                             |
-| `choiceHint`          | Ні          | `string`                                        | Короткий допоміжний текст для picker-а.                                                                   |
-| `assistantPriority`   | Ні          | `number`                                        | Менші значення сортуються раніше в інтерактивних picker-ах, керованих асистентом.                        |
-| `assistantVisibility` | Ні          | `"visible"` \| `"manual-only"`                  | Приховує варіант із picker-ів асистента, але все ще дозволяє ручний вибір через CLI.                     |
-| `deprecatedChoiceIds` | Ні          | `string[]`                                      | Застарілі id варіантів, які мають перенаправляти користувачів на цей варіант-заміну.                     |
-| `groupId`             | Ні          | `string`                                        | Необов’язковий id групи для групування пов’язаних варіантів.                                              |
-| `groupLabel`          | Ні          | `string`                                        | Мітка для користувача для цієї групи.                                                                     |
-| `groupHint`           | Ні          | `string`                                        | Короткий допоміжний текст для групи.                                                                      |
-| `optionKey`           | Ні          | `string`                                        | Внутрішній ключ параметра для простих потоків auth з одним прапорцем.                                    |
-| `cliFlag`             | Ні          | `string`                                        | Назва прапорця CLI, наприклад `--openrouter-api-key`.                                                     |
-| `cliOption`           | Ні          | `string`                                        | Повна форма параметра CLI, наприклад `--openrouter-api-key <key>`.                                       |
-| `cliDescription`      | Ні          | `string`                                        | Опис, який використовується в довідці CLI.                                                                |
-| `onboardingScopes`    | Ні          | `Array<"text-inference" \| "image-generation">` | У яких поверхнях онбордингу має з’являтися цей варіант. Якщо не вказано, використовується `["text-inference"]`. |
+| Поле                  | Обов’язкове | Тип                                             | Що воно означає                                                                                         |
+| --------------------- | ----------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
+| `provider`            | Так         | `string`                                        | Ідентифікатор провайдера, до якого належить цей варіант.                                                |
+| `method`              | Так         | `string`                                        | Ідентифікатор методу автентифікації, до якого слід диспетчеризувати.                                    |
+| `choiceId`            | Так         | `string`                                        | Стабільний ідентифікатор варіанта автентифікації, який використовується в потоках онбордингу та CLI.   |
+| `choiceLabel`         | Ні          | `string`                                        | Підпис для користувача. Якщо пропущено, OpenClaw використовує `choiceId`.                               |
+| `choiceHint`          | Ні          | `string`                                        | Короткий допоміжний текст для селектора.                                                                |
+| `assistantPriority`   | Ні          | `number`                                        | Менші значення сортуються раніше в інтерактивних селекторах, керованих асистентом.                     |
+| `assistantVisibility` | Ні          | `"visible"` \| `"manual-only"`                  | Приховує варіант у селекторах асистента, але все ще дозволяє ручний вибір через CLI.                   |
+| `deprecatedChoiceIds` | Ні          | `string[]`                                      | Застарілі ідентифікатори варіантів, які мають перенаправляти користувачів на цей варіант-заміну.       |
+| `groupId`             | Ні          | `string`                                        | Необов’язковий ідентифікатор групи для групування пов’язаних варіантів.                                 |
+| `groupLabel`          | Ні          | `string`                                        | Підпис цієї групи для користувача.                                                                      |
+| `groupHint`           | Ні          | `string`                                        | Короткий допоміжний текст для групи.                                                                    |
+| `optionKey`           | Ні          | `string`                                        | Внутрішній ключ параметра для простих потоків автентифікації з одним прапорцем.                         |
+| `cliFlag`             | Ні          | `string`                                        | Назва прапорця CLI, наприклад `--openrouter-api-key`.                                                   |
+| `cliOption`           | Ні          | `string`                                        | Повна форма параметра CLI, наприклад `--openrouter-api-key <key>`.                                      |
+| `cliDescription`      | Ні          | `string`                                        | Опис, що використовується в довідці CLI.                                                                |
+| `onboardingScopes`    | Ні          | `Array<"text-inference" \| "image-generation">` | На яких поверхнях онбордингу має з’являтися цей варіант. Якщо пропущено, за замовчуванням це `["text-inference"]`. |
 
 ## Довідник `commandAliases`
 
-Використовуйте `commandAliases`, коли плагін володіє назвою runtime-команди, яку користувачі можуть
-помилково помістити в `plugins.allow` або спробувати запустити як кореневу команду CLI. OpenClaw
-використовує ці метадані для діагностики без імпорту коду runtime плагіна.
+Використовуйте `commandAliases`, коли плагін володіє назвою команди середовища виконання, яку користувачі можуть
+помилково додати до `plugins.allow` або спробувати запустити як кореневу команду CLI. OpenClaw
+використовує ці метадані для діагностики без імпорту коду середовища виконання плагіна.
 
 ```json
 {
@@ -214,19 +209,22 @@ OpenClaw зчитує це до завантаження runtime провайд
 }
 ```
 
-| Поле         | Обов’язкове | Тип               | Що воно означає                                                             |
-| ------------ | ----------- | ----------------- | --------------------------------------------------------------------------- |
-| `name`       | Так         | `string`          | Назва команди, яка належить цьому плагіну.                                  |
-| `kind`       | Ні          | `"runtime-slash"` | Позначає псевдонім як slash-команду чату, а не кореневу команду CLI.        |
+| Поле         | Обов’язкове | Тип               | Що воно означає                                                              |
+| ------------ | ----------- | ----------------- | ---------------------------------------------------------------------------- |
+| `name`       | Так         | `string`          | Назва команди, яка належить цьому плагіну.                                   |
+| `kind`       | Ні          | `"runtime-slash"` | Позначає псевдонім як slash-команду чату, а не як кореневу команду CLI.      |
 | `cliCommand` | Ні          | `string`          | Пов’язана коренева команда CLI, яку слід рекомендувати для операцій CLI, якщо вона існує. |
 
 ## Довідник `activation`
 
-Використовуйте `activation`, коли плагін може дешево оголосити, які події control plane
+Використовуйте `activation`, коли плагін може з невеликими витратами оголосити, які події control-plane
 мають активувати його пізніше.
 
-Цей блок містить лише метадані. Він не реєструє поведінку runtime і не
-замінює `register(...)`, `setupEntry` або інші runtime/plugin entrypoint-и.
+Цей блок містить лише метадані. Він не реєструє поведінку середовища виконання і не
+замінює `register(...)`, `setupEntry` або інші entrypoint середовища виконання/плагіна.
+Поточні споживачі використовують його як підказку для звуження перед ширшим завантаженням плагіна, тому
+відсутність метаданих активації лише впливає на продуктивність; це не повинно змінювати
+коректність.
 
 ```json
 {
@@ -240,18 +238,22 @@ OpenClaw зчитує це до завантаження runtime провайд
 }
 ```
 
-| Поле             | Обов’язкове | Тип                                                  | Що воно означає                                                 |
-| ---------------- | ----------- | ---------------------------------------------------- | --------------------------------------------------------------- |
-| `onProviders`    | Ні          | `string[]`                                           | Id провайдерів, які мають активувати цей плагін за запитом.     |
-| `onCommands`     | Ні          | `string[]`                                           | Id команд, які мають активувати цей плагін.                     |
-| `onChannels`     | Ні          | `string[]`                                           | Id каналів, які мають активувати цей плагін.                    |
-| `onRoutes`       | Ні          | `string[]`                                           | Типи маршрутів, які мають активувати цей плагін.                |
-| `onCapabilities` | Ні          | `Array<"provider" \| "channel" \| "tool" \| "hook">` | Загальні підказки можливостей, що використовуються в плануванні активації control plane. |
+| Поле             | Обов’язкове | Тип                                                  | Що воно означає                                                    |
+| ---------------- | ----------- | ---------------------------------------------------- | ------------------------------------------------------------------ |
+| `onProviders`    | Ні          | `string[]`                                           | Ідентифікатори провайдерів, які мають активувати цей плагін на запит. |
+| `onCommands`     | Ні          | `string[]`                                           | Ідентифікатори команд, які мають активувати цей плагін.            |
+| `onChannels`     | Ні          | `string[]`                                           | Ідентифікатори каналів, які мають активувати цей плагін.           |
+| `onRoutes`       | Ні          | `string[]`                                           | Типи маршрутів, які мають активувати цей плагін.                   |
+| `onCapabilities` | Ні          | `Array<"provider" \| "channel" \| "tool" \| "hook">` | Загальні підказки щодо можливостей, які використовуються в плануванні активації control-plane. |
+
+Зокрема для планування, що запускається командами, OpenClaw усе ще повертається до
+застарілих `commandAliases[].cliCommand` або `commandAliases[].name`, коли плагін
+ще не додав явні метадані `activation.onCommands`.
 
 ## Довідник `setup`
 
-Використовуйте `setup`, коли поверхням setup та онбордингу потрібні дешеві метадані,
-якими володіє плагін, до завантаження runtime.
+Використовуйте `setup`, коли поверхням налаштування та онбордингу потрібні легкі метадані, що належать плагіну,
+до завантаження середовища виконання.
 
 ```json
 {
@@ -270,40 +272,40 @@ OpenClaw зчитує це до завантаження runtime провайд
 }
 ```
 
-`cliBackends` верхнього рівня залишається валідним і надалі описує backend-и
-висновування CLI. `setup.cliBackends` — це поверхня дескрипторів, специфічна для setup,
-для потоків control plane/setup, яка має залишатися лише метаданими.
+Верхньорівневе `cliBackends` залишається дійсним і далі описує backend виведення CLI.
+`setup.cliBackends` — це поверхня дескрипторів, специфічна для налаштування, для
+потоків control-plane/налаштування, які мають залишатися лише метаданими.
 
-Якщо вони присутні, `setup.providers` і `setup.cliBackends` є бажаною
-поверхнею пошуку на основі дескрипторів для виявлення setup. Якщо дескриптор лише
-звужує коло плагінів-кандидатів, а setup все ще потребує багатших runtime hooks під час setup,
-встановіть `requiresRuntime: true` і залиште `setup-api` як резервний шлях виконання.
+Якщо присутні, `setup.providers` і `setup.cliBackends` є бажаною
+поверхнею пошуку на основі дескрипторів для виявлення налаштування. Якщо дескриптор лише
+звужує кандидатний плагін, а налаштуванню все ще потрібні багатші хуки середовища виконання під час налаштування,
+установіть `requiresRuntime: true` і залиште `setup-api` як резервний шлях виконання.
 
-Оскільки пошук setup може виконувати код `setup-api`, яким володіє плагін, нормалізовані
-значення `setup.providers[].id` і `setup.cliBackends[]` мають залишатися унікальними серед
-виявлених плагінів. Неоднозначна належність завершується без вибору замість того, щоб
-обирати переможця за порядком виявлення.
+Оскільки пошук налаштування може виконувати код `setup-api`, що належить плагіну,
+нормалізовані значення `setup.providers[].id` і `setup.cliBackends[]` повинні залишатися унікальними серед
+виявлених плагінів. Неоднозначне володіння призводить до безпечної відмови замість вибору
+переможця за порядком виявлення.
 
 ### Довідник `setup.providers`
 
-| Поле          | Обов’язкове | Тип        | Що воно означає                                                                        |
-| ------------- | ----------- | ---------- | -------------------------------------------------------------------------------------- |
-| `id`          | Так         | `string`   | Id провайдера, який надається під час setup або онбордингу. Нормалізовані id мають бути глобально унікальними. |
-| `authMethods` | Ні          | `string[]` | Id методів setup/auth, які цей провайдер підтримує без завантаження повного runtime.   |
-| `envVars`     | Ні          | `string[]` | Env vars, які загальні поверхні setup/status можуть перевіряти до завантаження runtime плагіна. |
+| Поле          | Обов’язкове | Тип        | Що воно означає                                                                         |
+| ------------- | ----------- | ---------- | --------------------------------------------------------------------------------------- |
+| `id`          | Так         | `string`   | Ідентифікатор провайдера, доступний під час налаштування або онбордингу. Зберігайте нормалізовані ідентифікатори глобально унікальними. |
+| `authMethods` | Ні          | `string[]` | Ідентифікатори методів налаштування/автентифікації, які цей провайдер підтримує без завантаження повного середовища виконання. |
+| `envVars`     | Ні          | `string[]` | Змінні середовища, які загальні поверхні налаштування/статусу можуть перевіряти до завантаження середовища виконання плагіна. |
 
 ### Поля `setup`
 
-| Поле               | Обов’язкове | Тип        | Що воно означає                                                                                       |
-| ------------------ | ----------- | ---------- | ----------------------------------------------------------------------------------------------------- |
-| `providers`        | Ні          | `object[]` | Дескриптори setup провайдерів, доступні під час setup та онбордингу.                                 |
-| `cliBackends`      | Ні          | `string[]` | Id backend-ів для часу setup, які використовуються для пошуку setup за принципом descriptor-first. Нормалізовані id мають бути глобально унікальними. |
-| `configMigrations` | Ні          | `string[]` | Id міграцій конфігурації, якими володіє поверхня setup цього плагіна.                                |
-| `requiresRuntime`  | Ні          | `boolean`  | Чи потребує setup виконання `setup-api` після пошуку за дескриптором.                                |
+| Поле               | Обов’язкове | Тип        | Що воно означає                                                                                  |
+| ------------------ | ----------- | ---------- | ------------------------------------------------------------------------------------------------ |
+| `providers`        | Ні          | `object[]` | Дескриптори налаштування провайдерів, доступні під час налаштування та онбордингу.               |
+| `cliBackends`      | Ні          | `string[]` | Ідентифікатори backend часу налаштування, що використовуються для пошуку налаштування на основі дескрипторів. Зберігайте нормалізовані ідентифікатори глобально унікальними. |
+| `configMigrations` | Ні          | `string[]` | Ідентифікатори міграцій конфігурації, якими володіє поверхня налаштування цього плагіна.         |
+| `requiresRuntime`  | Ні          | `boolean`  | Чи потребує налаштування виконання `setup-api` після пошуку за дескриптором.                     |
 
 ## Довідник `uiHints`
 
-`uiHints` — це мапа від назв полів конфігурації до невеликих підказок для відображення.
+`uiHints` — це мапа від назв полів конфігурації до невеликих підказок рендерингу.
 
 ```json
 {
@@ -318,21 +320,21 @@ OpenClaw зчитує це до завантаження runtime провайд
 }
 ```
 
-Кожна підказка для поля може містити:
+Кожна підказка поля може містити:
 
-| Поле          | Тип        | Що воно означає                         |
-| ------------- | ---------- | --------------------------------------- |
-| `label`       | `string`   | Мітка поля для користувача.             |
-| `help`        | `string`   | Короткий допоміжний текст.              |
-| `tags`        | `string[]` | Необов’язкові теги UI.                  |
-| `advanced`    | `boolean`  | Позначає поле як розширене.             |
-| `sensitive`   | `boolean`  | Позначає поле як секретне або чутливе.  |
-| `placeholder` | `string`   | Текст placeholder для полів форми.      |
+| Поле          | Тип        | Що воно означає                        |
+| ------------- | ---------- | -------------------------------------- |
+| `label`       | `string`   | Підпис поля для користувача.           |
+| `help`        | `string`   | Короткий допоміжний текст.             |
+| `tags`        | `string[]` | Необов’язкові теги UI.                 |
+| `advanced`    | `boolean`  | Позначає поле як розширене.            |
+| `sensitive`   | `boolean`  | Позначає поле як секретне або чутливе. |
+| `placeholder` | `string`   | Текст-заповнювач для полів форми.      |
 
 ## Довідник `contracts`
 
-Використовуйте `contracts` лише для статичних метаданих належності можливостей, які OpenClaw може
-зчитувати без імпорту runtime плагіна.
+Використовуйте `contracts` лише для статичних метаданих володіння можливостями, які OpenClaw може
+читати без імпорту середовища виконання плагіна.
 
 ```json
 {
@@ -352,22 +354,22 @@ OpenClaw зчитує це до завантаження runtime провайд
 
 Кожен список є необов’язковим:
 
-| Поле                             | Тип        | Що воно означає                                               |
-| -------------------------------- | ---------- | ------------------------------------------------------------- |
-| `speechProviders`                | `string[]` | Id speech-провайдерів, якими володіє цей плагін.              |
-| `realtimeTranscriptionProviders` | `string[]` | Id провайдерів realtime-transcription, якими володіє цей плагін. |
-| `realtimeVoiceProviders`         | `string[]` | Id провайдерів realtime-voice, якими володіє цей плагін.      |
-| `mediaUnderstandingProviders`    | `string[]` | Id провайдерів media-understanding, якими володіє цей плагін. |
-| `imageGenerationProviders`       | `string[]` | Id провайдерів image-generation, якими володіє цей плагін.    |
-| `videoGenerationProviders`       | `string[]` | Id провайдерів video-generation, якими володіє цей плагін.    |
-| `webFetchProviders`              | `string[]` | Id провайдерів web-fetch, якими володіє цей плагін.           |
-| `webSearchProviders`             | `string[]` | Id провайдерів web-search, якими володіє цей плагін.          |
-| `tools`                          | `string[]` | Назви agent tool, якими володіє цей плагін, для bundled перевірок контрактів. |
+| Поле                             | Тип        | Що воно означає                                                |
+| -------------------------------- | ---------- | -------------------------------------------------------------- |
+| `speechProviders`                | `string[]` | Ідентифікатори speech-провайдерів, якими володіє цей плагін.   |
+| `realtimeTranscriptionProviders` | `string[]` | Ідентифікатори провайдерів realtime transcription, якими володіє цей плагін. |
+| `realtimeVoiceProviders`         | `string[]` | Ідентифікатори провайдерів realtime voice, якими володіє цей плагін. |
+| `mediaUnderstandingProviders`    | `string[]` | Ідентифікатори провайдерів media-understanding, якими володіє цей плагін. |
+| `imageGenerationProviders`       | `string[]` | Ідентифікатори провайдерів image-generation, якими володіє цей плагін. |
+| `videoGenerationProviders`       | `string[]` | Ідентифікатори провайдерів video-generation, якими володіє цей плагін. |
+| `webFetchProviders`              | `string[]` | Ідентифікатори провайдерів web-fetch, якими володіє цей плагін. |
+| `webSearchProviders`             | `string[]` | Ідентифікатори провайдерів web search, якими володіє цей плагін. |
+| `tools`                          | `string[]` | Назви інструментів агента, якими володіє цей плагін, для перевірок контрактів пакетів. |
 
 ## Довідник `channelConfigs`
 
-Використовуйте `channelConfigs`, коли плагіну каналу потрібні дешеві метадані конфігурації до
-завантаження runtime.
+Використовуйте `channelConfigs`, коли плагіну каналу потрібні легкі метадані конфігурації до
+завантаження середовища виконання.
 
 ```json
 {
@@ -387,7 +389,7 @@ OpenClaw зчитує це до завантаження runtime провайд
         }
       },
       "label": "Matrix",
-      "description": "Matrix homeserver connection",
+      "description": "Підключення до homeserver Matrix",
       "preferOver": ["matrix-legacy"]
     }
   }
@@ -396,19 +398,19 @@ OpenClaw зчитує це до завантаження runtime провайд
 
 Кожен запис каналу може містити:
 
-| Поле          | Тип                      | Що воно означає                                                                                 |
-| ------------- | ------------------------ | ----------------------------------------------------------------------------------------------- |
+| Поле          | Тип                      | Що воно означає                                                                          |
+| ------------- | ------------------------ | ---------------------------------------------------------------------------------------- |
 | `schema`      | `object`                 | JSON Schema для `channels.<id>`. Обов’язкова для кожного оголошеного запису конфігурації каналу. |
-| `uiHints`     | `Record<string, object>` | Необов’язкові мітки UI/placeholders/підказки чутливості для цього розділу конфігурації каналу. |
-| `label`       | `string`                 | Мітка каналу, що об’єднується в picker та inspect surfaces, коли метадані runtime ще не готові. |
-| `description` | `string`                 | Короткий опис каналу для поверхонь inspect і catalog.                                          |
-| `preferOver`  | `string[]`               | Застарілі або нижчопріоритетні id плагінів, які цей канал має випереджати в поверхнях вибору.  |
+| `uiHints`     | `Record<string, object>` | Необов’язкові підписи UI/заповнювачі/підказки чутливості для цього розділу конфігурації каналу. |
+| `label`       | `string`                 | Підпис каналу, що об’єднується з поверхнями селектора та інспектування, коли метадані середовища виконання ще не готові. |
+| `description` | `string`                 | Короткий опис каналу для поверхонь інспектування та каталогу.                            |
+| `preferOver`  | `string[]`               | Застарілі або менш пріоритетні ідентифікатори плагінів, які цей канал має випереджати на поверхнях вибору. |
 
 ## Довідник `modelSupport`
 
-Використовуйте `modelSupport`, коли OpenClaw має визначати ваш плагін провайдера з
-коротких id моделей, таких як `gpt-5.4` або `claude-sonnet-4.6`, до завантаження runtime
-плагіна.
+Використовуйте `modelSupport`, коли OpenClaw має визначати ваш плагін провайдера за
+скороченими ідентифікаторами моделей, як-от `gpt-5.4` або `claude-sonnet-4.6`, до завантаження
+середовища виконання плагіна.
 
 ```json
 {
@@ -419,75 +421,75 @@ OpenClaw зчитує це до завантаження runtime провайд
 }
 ```
 
-OpenClaw застосовує таку пріоритетність:
+OpenClaw застосовує такий пріоритет:
 
-- явні посилання `provider/model` використовують метадані маніфесту `providers`, якими володіє плагін
+- явні посилання `provider/model` використовують метадані маніфесту `providers`, що належать власнику
 - `modelPatterns` мають вищий пріоритет за `modelPrefixes`
-- якщо збігаються один небандлований плагін і один bundled plugin, перемагає небандлований
+- якщо збігаються один непакетний плагін і один пакетний плагін, перемагає непакетний
   плагін
-- решта неоднозначностей ігноруються, доки користувач або config не вкаже провайдера
+- решта неоднозначностей ігноруються, доки користувач або конфігурація не вкажуть провайдера
 
 Поля:
 
-| Поле            | Тип        | Що воно означає                                                                       |
-| --------------- | ---------- | ------------------------------------------------------------------------------------- |
-| `modelPrefixes` | `string[]` | Префікси, що зіставляються через `startsWith` із короткими id моделей.               |
-| `modelPatterns` | `string[]` | Джерела regex, які зіставляються з короткими id моделей після видалення суфікса профілю. |
+| Поле            | Тип        | Що воно означає                                                                  |
+| --------------- | ---------- | -------------------------------------------------------------------------------- |
+| `modelPrefixes` | `string[]` | Префікси, які зіставляються через `startsWith` зі скороченими ідентифікаторами моделей. |
+| `modelPatterns` | `string[]` | Джерела regex, які зіставляються зі скороченими ідентифікаторами моделей після видалення суфікса профілю. |
 
-Застарілі ключі можливостей верхнього рівня не рекомендуються. Використовуйте `openclaw doctor --fix`, щоб
+Застарілі ключі можливостей верхнього рівня не рекомендовані. Використовуйте `openclaw doctor --fix`, щоб
 перемістити `speechProviders`, `realtimeTranscriptionProviders`,
 `realtimeVoiceProviders`, `mediaUnderstandingProviders`,
 `imageGenerationProviders`, `videoGenerationProviders`,
 `webFetchProviders` і `webSearchProviders` до `contracts`; звичайне
-завантаження маніфесту більше не трактує ці поля верхнього рівня як
-належність можливостей.
+завантаження маніфесту більше не розглядає ці поля верхнього рівня як
+володіння можливостями.
 
-## Маніфест проти package.json
+## Маніфест порівняно з package.json
 
-Ці два файли виконують різні ролі:
+Ці два файли виконують різні завдання:
 
-| Файл                   | Використовуйте його для                                                                                                            |
+| Файл                   | Для чого його використовувати                                                                                                      |
 | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
-| `openclaw.plugin.json` | Виявлення, валідація конфігурації, метадані вибору auth і підказки UI, які мають існувати до запуску коду плагіна                |
-| `package.json`         | Метадані npm, встановлення залежностей і блок `openclaw`, який використовується для entrypoint-ів, обмежень установлення, setup або метаданих каталогу |
+| `openclaw.plugin.json` | Виявлення, валідація конфігурації, метадані варіантів автентифікації та підказки UI, які мають існувати до запуску коду плагіна |
+| `package.json`         | Метадані npm, встановлення залежностей і блок `openclaw`, що використовується для entrypoint, обмежень встановлення, налаштування або метаданих каталогу |
 
-Якщо ви не впевнені, куди має належати певний фрагмент метаданих, користуйтеся таким правилом:
+Якщо ви не впевнені, куди належить певний фрагмент метаданих, використовуйте таке правило:
 
-- якщо OpenClaw має знати це до завантаження коду плагіна, помістіть це в `openclaw.plugin.json`
-- якщо це стосується пакування, файлів входу або поведінки встановлення npm, помістіть це в `package.json`
+- якщо OpenClaw повинен знати це до завантаження коду плагіна, помістіть це в `openclaw.plugin.json`
+- якщо це стосується пакування, файлів entrypoint або поведінки встановлення npm, помістіть це в `package.json`
 
 ### Поля package.json, які впливають на виявлення
 
-Частина метаданих плагіна до runtime навмисно зберігається в `package.json` у блоці
+Деякі метадані плагіна до запуску середовища виконання навмисно зберігаються в `package.json` у блоці
 `openclaw`, а не в `openclaw.plugin.json`.
 
 Важливі приклади:
 
-| Поле                                                              | Що воно означає                                                                                                                                  |
-| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `openclaw.extensions`                                             | Оголошує entrypoint-и власних плагінів.                                                                                                          |
-| `openclaw.setupEntry`                                             | Легковагий entrypoint лише для setup, який використовується під час онбордингу та відкладеного запуску каналу.                                 |
-| `openclaw.channel`                                                | Легковагі метадані каталогу каналів, як-от мітки, шляхи до документації, псевдоніми та текст для вибору.                                       |
-| `openclaw.channel.configuredState`                                | Легковагі метадані перевірки configured-state, які можуть відповісти на запитання «чи вже існує налаштування лише через env?» без завантаження повного runtime каналу. |
-| `openclaw.channel.persistedAuthState`                             | Легковагі метадані перевірки persisted-auth, які можуть відповісти на запитання «чи вже десь виконано вхід?» без завантаження повного runtime каналу. |
-| `openclaw.install.npmSpec` / `openclaw.install.localPath`         | Підказки встановлення/оновлення для bundled і зовнішньо опублікованих плагінів.                                                                 |
-| `openclaw.install.defaultChoice`                                  | Бажаний шлях встановлення, коли доступно кілька джерел встановлення.                                                                             |
-| `openclaw.install.minHostVersion`                                 | Мінімальна підтримувана версія хоста OpenClaw, із нижньою межею semver на кшталт `>=2026.3.22`.                                                 |
-| `openclaw.install.allowInvalidConfigRecovery`                     | Дозволяє вузький шлях відновлення перевстановлення bundled plugin, коли конфігурація невалідна.                                                 |
-| `openclaw.startup.deferConfiguredChannelFullLoadUntilAfterListen` | Дозволяє поверхням каналу лише для setup завантажуватися до повного плагіна каналу під час запуску.                                             |
+| Поле                                                              | Що воно означає                                                                                                                            |
+| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
+| `openclaw.extensions`                                             | Оголошує власні entrypoint плагіна.                                                                                                        |
+| `openclaw.setupEntry`                                             | Легкий entrypoint лише для налаштування, який використовується під час онбордингу та відкладеного запуску каналу.                        |
+| `openclaw.channel`                                                | Легкі метадані каталогу каналів, як-от підписи, шляхи до документації, псевдоніми та текст для вибору.                                   |
+| `openclaw.channel.configuredState`                                | Легкі метадані перевірки налаштованого стану, які можуть відповісти на запитання «чи вже існує налаштування лише через env?» без завантаження повного середовища виконання каналу. |
+| `openclaw.channel.persistedAuthState`                             | Легкі метадані перевірки збереженого стану автентифікації, які можуть відповісти на запитання «чи вже є хоч один активний вхід?» без завантаження повного середовища виконання каналу. |
+| `openclaw.install.npmSpec` / `openclaw.install.localPath`         | Підказки для встановлення/оновлення пакетних і зовнішньо опублікованих плагінів.                                                          |
+| `openclaw.install.defaultChoice`                                  | Бажаний шлях встановлення, коли доступно кілька джерел встановлення.                                                                       |
+| `openclaw.install.minHostVersion`                                 | Мінімальна підтримувана версія хоста OpenClaw, із semver-нижньою межею на кшталт `>=2026.3.22`.                                          |
+| `openclaw.install.allowInvalidConfigRecovery`                     | Дозволяє вузький шлях відновлення перевстановлення пакетного плагіна, коли конфігурація недійсна.                                         |
+| `openclaw.startup.deferConfiguredChannelFullLoadUntilAfterListen` | Дозволяє поверхням каналу лише для налаштування завантажуватися до повного плагіна каналу під час запуску.                               |
 
 `openclaw.install.minHostVersion` застосовується під час встановлення та
-завантаження реєстру маніфестів. Невалідні значення відхиляються; новіші, але валідні значення пропускають
+завантаження реєстру маніфестів. Недійсні значення відхиляються; новіші, але дійсні значення пропускають
 плагін на старіших хостах.
 
-`openclaw.install.allowInvalidConfigRecovery` навмисно має вузьке застосування. Воно
-не робить довільні зламані конфігурації придатними до встановлення. Наразі воно лише дозволяє потокам встановлення
-відновлюватися після певних застарілих збоїв оновлення bundled plugin, наприклад
-відсутнього шляху bundled plugin або застарілого запису `channels.<id>` для того самого
-bundled plugin. Непов’язані помилки конфігурації все одно блокують встановлення та спрямовують операторів
+`openclaw.install.allowInvalidConfigRecovery` навмисно має вузьке призначення. Воно
+не робить довільно зламані конфігурації придатними до встановлення. Наразі воно лише дозволяє потокам встановлення
+відновлюватися після певних застарілих збоїв оновлення пакетних плагінів, наприклад
+відсутнього шляху до пакетного плагіна або застарілого запису `channels.<id>` для того самого
+пакетного плагіна. Непов’язані помилки конфігурації все одно блокують встановлення та спрямовують операторів
 до `openclaw doctor --fix`.
 
-`openclaw.channel.persistedAuthState` — це метадані пакунка для маленького модуля перевірки:
+`openclaw.channel.persistedAuthState` — це метадані пакета для крихітного модуля перевірки:
 
 ```json
 {
@@ -503,11 +505,13 @@ bundled plugin. Непов’язані помилки конфігурації
 }
 ```
 
-Використовуйте це, коли потокам setup, doctor або configured-state потрібна дешева перевірка auth
-типу так/ні до завантаження повного плагіна каналу. Цільовий export має бути невеликою
-функцією, яка лише читає збережений стан; не спрямовуйте її через повний barrel runtime каналу.
+Використовуйте це, коли потокам налаштування, doctor або configured-state потрібна легка
+перевірка автентифікації «так/ні» до завантаження повного плагіна каналу. Цільовий експорт має бути невеликою
+функцією, яка читає лише збережений стан; не спрямовуйте його через повний barrel середовища виконання
+каналу.
 
-`openclaw.channel.configuredState` має ту саму форму для дешевих перевірок configured-state лише через env:
+`openclaw.channel.configuredState` має ту саму форму для легких перевірок
+налаштованого стану лише через env:
 
 ```json
 {
@@ -523,63 +527,64 @@ bundled plugin. Непов’язані помилки конфігурації
 }
 ```
 
-Використовуйте це, коли канал може визначити configured-state через env або інші невеликі
-входи, не пов’язані з runtime. Якщо перевірка потребує повного розв’язання config або справжнього
-runtime каналу, залиште цю логіку в hook `config.hasConfiguredState` плагіна.
+Використовуйте це, коли канал може визначити налаштований стан за env або іншими невеликими
+вхідними даними, що не належать середовищу виконання. Якщо перевірка потребує повного визначення конфігурації або реального
+середовища виконання каналу, залиште цю логіку в hook `config.hasConfiguredState`
+плагіна.
 
 ## Вимоги до JSON Schema
 
-- **Кожен плагін має постачатися з JSON Schema**, навіть якщо він не приймає конфігурації.
-- Порожня схема припустима (наприклад, `{ "type": "object", "additionalProperties": false }`).
-- Схеми проходять валідацію під час читання/запису config, а не під час runtime.
+- **Кожен плагін повинен постачатися з JSON Schema**, навіть якщо він не приймає конфігурацію.
+- Порожня схема є допустимою (наприклад, `{ "type": "object", "additionalProperties": false }`).
+- Схеми проходять валідацію під час читання/запису конфігурації, а не під час виконання.
 
 ## Поведінка валідації
 
-- Невідомі ключі `channels.*` є **помилками**, якщо тільки id каналу не оголошений
-  у маніфесті плагіна.
+- Невідомі ключі `channels.*` є **помилками**, якщо тільки ідентифікатор каналу не оголошено
+  в маніфесті плагіна.
 - `plugins.entries.<id>`, `plugins.allow`, `plugins.deny` і `plugins.slots.*`
-  мають посилатися на id плагінів, які **можна виявити**. Невідомі id є **помилками**.
+  повинні посилатися на **доступні для виявлення** ідентифікатори плагінів. Невідомі ідентифікатори є **помилками**.
 - Якщо плагін установлено, але він має зламаний або відсутній маніфест чи схему,
   валідація завершується помилкою, а Doctor повідомляє про помилку плагіна.
-- Якщо конфігурація плагіна існує, але сам плагін **вимкнено**, конфігурація зберігається, і
-  у Doctor + logs відображається **попередження**.
+- Якщо конфігурація плагіна існує, але сам плагін **вимкнений**, конфігурація зберігається, і
+  попередження **відображається** в Doctor та журналах.
 
-Дивіться [Довідник конфігурації](/uk/gateway/configuration) для повної схеми `plugins.*`.
+Повну схему `plugins.*` див. у [Довіднику з конфігурації](/uk/gateway/configuration).
 
 ## Примітки
 
-- Маніфест **обов’язковий для власних плагінів OpenClaw**, включно із завантаженням із локальної файлової системи.
-- Runtime, як і раніше, завантажує модуль плагіна окремо; маніфест призначений лише для
+- Маніфест **обов’язковий для власних плагінів OpenClaw**, зокрема для локальних завантажень із файлової системи.
+- Середовище виконання все одно завантажує модуль плагіна окремо; маніфест використовується лише для
   виявлення + валідації.
 - Власні маніфести розбираються за допомогою JSON5, тому коментарі, кінцеві коми та
-  ключі без лапок допускаються, якщо кінцеве значення все ще є об’єктом.
+  ключі без лапок дозволені, якщо кінцеве значення все одно є об’єктом.
 - Завантажувач маніфестів читає лише задокументовані поля маніфесту. Уникайте додавання
-  власних ключів верхнього рівня сюди.
-- `providerAuthEnvVars` — це дешевий шлях метаданих для перевірок auth, валідації
-  env-marker та подібних поверхонь auth провайдера, які не повинні запускати runtime плагіна
+  власних ключів верхнього рівня тут.
+- `providerAuthEnvVars` — це легкий шлях метаданих для перевірок автентифікації, валідації
+  env-маркерів та подібних поверхонь автентифікації провайдерів, які не повинні запускати середовище виконання плагіна
   лише для перевірки назв env.
-- `providerAuthAliases` дозволяє варіантам провайдерів повторно використовувати auth
-  env vars, auth profiles, auth на основі config та варіант онбордингу API key іншого провайдера
-  без жорсткого кодування цього зв’язку в core.
-- `channelEnvVars` — це дешевий шлях метаданих для резервного використання shell-env, підказок setup
-  та подібних поверхонь каналів, які не повинні запускати runtime плагіна
+- `providerAuthAliases` дозволяє варіантам провайдерів повторно використовувати env vars автентифікації іншого провайдера,
+  профілі автентифікації, автентифікацію на основі конфігурації та варіант
+  онбордингу з API-ключем без жорсткого кодування цього зв’язку в core.
+- `channelEnvVars` — це легкий шлях метаданих для резервного використання shell-env, підказок
+  налаштування та подібних поверхонь каналів, які не повинні запускати середовище виконання плагіна
   лише для перевірки назв env.
-- `providerAuthChoices` — це дешевий шлях метаданих для picker-ів вибору auth,
-  розв’язання `--auth-choice`, мапінгу preferred provider і простої реєстрації прапорців CLI
-  під час онбордингу до завантаження runtime провайдера. Для метаданих wizard runtime,
-  які потребують коду провайдера, дивіться
-  [Runtime hooks провайдера](/uk/plugins/architecture#provider-runtime-hooks).
-- Виключні типи плагінів вибираються через `plugins.slots.*`.
+- `providerAuthChoices` — це легкий шлях метаданих для селекторів варіантів автентифікації,
+  визначення `--auth-choice`, зіставлення пріоритетного провайдера та простої реєстрації
+  прапорців CLI онбордингу до завантаження середовища виконання провайдера. Щодо метаданих
+  майстра середовища виконання, які потребують коду провайдера, див.
+  [Хуки середовища виконання провайдера](/uk/plugins/architecture#provider-runtime-hooks).
+- Ексклюзивні типи плагінів вибираються через `plugins.slots.*`.
   - `kind: "memory"` вибирається через `plugins.slots.memory`.
   - `kind: "context-engine"` вибирається через `plugins.slots.contextEngine`
-    (типове значення: вбудований `legacy`).
-- `channels`, `providers`, `cliBackends` і `skills` можна не вказувати, якщо
+    (типово: вбудований `legacy`).
+- `channels`, `providers`, `cliBackends` і `skills` можна не вказувати, коли
   плагіну вони не потрібні.
-- Якщо ваш плагін залежить від native modules, задокументуйте кроки збірки та всі
-  вимоги до allowlist менеджера пакунків (наприклад, pnpm `allow-build-scripts`
+- Якщо ваш плагін залежить від власних модулів, задокументуйте кроки збирання та всі
+  вимоги до allowlist менеджера пакетів (наприклад, pnpm `allow-build-scripts`
   - `pnpm rebuild <package>`).
 
-## Пов’язані матеріали
+## Пов’язане
 
 - [Створення плагінів](/uk/plugins/building-plugins) — початок роботи з плагінами
 - [Архітектура плагінів](/uk/plugins/architecture) — внутрішня архітектура