chore(i18n): refresh uk translations

docs/uk/plugins/architecture.md

@@ -1,51 +1,51 @@
 ---
 read_when:
-    - Створення або налагодження рідних Plugin OpenClaw
+    - Збирання або налагодження нативних Plugin OpenClaw
     - Розуміння моделі можливостей Plugin або меж володіння
     - Робота над конвеєром завантаження Plugin або реєстром
-    - Реалізація runtime-хуків провайдера або плагінів каналів
+    - Реалізація гачків середовища виконання постачальника або Plugin каналів
 sidebarTitle: Internals
-summary: 'Внутрішня будова Plugin: модель можливостей, володіння, контракти, конвеєр завантаження та допоміжні засоби runtime'
-title: Внутрішня будова Plugin
+summary: 'Внутрішні компоненти Plugin: модель можливостей, володіння, контракти, конвеєр завантаження та допоміжні засоби середовища виконання'
+title: Внутрішні компоненти Plugin
 x-i18n:
-    generated_at: "2026-04-27T12:52:39Z"
+    generated_at: "2026-04-27T16:06:50Z"
     model: gpt-5.4
     provider: openai
-    source_hash: bf11e7e9098283f5a489e9843c338ef235748663580dfeaef62f6f6766b55621
+    source_hash: 846b3ec4ddd38b87c7b4f5e039556373075d058013ed568175e8fd1b6de2aa4d
     source_path: plugins/architecture.md
     workflow: 15
 ---
 
-Це **поглиблений архітектурний довідник** для системи Plugin в OpenClaw. Для практичних посібників почніть з однієї з наведених нижче спеціалізованих сторінок.
+Це **поглиблене архітектурне довідкове пояснення** системи Plugin в OpenClaw. Для практичних інструкцій почніть з однієї з наведених нижче спеціалізованих сторінок.
 
 <CardGroup cols={2}>
-  <Card title="Встановлення та використання плагінів" icon="plug" href="/uk/tools/plugin">
-    Посібник для кінцевих користувачів із додавання, увімкнення й усунення несправностей плагінів.
+  <Card title="Встановлення та використання Plugin" icon="plug" href="/uk/tools/plugin">
+    Посібник для кінцевих користувачів із додавання, увімкнення та усунення проблем із Plugin.
   </Card>
-  <Card title="Створення плагінів" icon="rocket" href="/uk/plugins/building-plugins">
-    Перший навчальний приклад плагіна з найменшим робочим manifest.
+  <Card title="Створення Plugin" icon="rocket" href="/uk/plugins/building-plugins">
+    Навчальний посібник зі створення першого Plugin з найменшим працездатним маніфестом.
   </Card>
-  <Card title="Плагіни каналів" icon="comments" href="/uk/plugins/sdk-channel-plugins">
-    Створення плагіна каналу обміну повідомленнями.
+  <Card title="Plugin каналів" icon="comments" href="/uk/plugins/sdk-channel-plugins">
+    Створіть Plugin каналу обміну повідомленнями.
   </Card>
-  <Card title="Плагіни провайдерів" icon="microchip" href="/uk/plugins/sdk-provider-plugins">
-    Створення плагіна провайдера моделей.
+  <Card title="Plugin постачальників" icon="microchip" href="/uk/plugins/sdk-provider-plugins">
+    Створіть Plugin постачальника моделей.
   </Card>
   <Card title="Огляд SDK" icon="book" href="/uk/plugins/sdk-overview">
-    Довідник з import map і API реєстрації.
+    Карта імпорту та довідник API реєстрації.
   </Card>
 </CardGroup>
 
 ## Публічна модель можливостей
 
-Можливості — це публічна модель **рідних плагінів** усередині OpenClaw. Кожен рідний Plugin OpenClaw реєструється щодо одного або кількох типів можливостей:
+Можливості — це публічна модель **нативних Plugin** усередині OpenClaw. Кожен нативний Plugin OpenClaw реєструється для одного або кількох типів можливостей:
 
-| Можливість            | Метод реєстрації                               | Приклади плагінів                    |
+| Можливість            | Метод реєстрації                               | Приклади Plugin                      |
 | --------------------- | ---------------------------------------------- | ------------------------------------ |
-| Текстовий inference   | `api.registerProvider(...)`                    | `openai`, `anthropic`                |
-| CLI-бекенд inference  | `api.registerCliBackend(...)`                  | `openai`, `anthropic`                |
+| Текстовий висновок    | `api.registerProvider(...)`                    | `openai`, `anthropic`                |
+| Backend висновку CLI  | `api.registerCliBackend(...)`                  | `openai`, `anthropic`                |
 | Мовлення              | `api.registerSpeechProvider(...)`              | `elevenlabs`, `microsoft`            |
-| Транскрибування в реальному часі | `api.registerRealtimeTranscriptionProvider(...)` | `openai`                   |
+| Транскрипція в реальному часі | `api.registerRealtimeTranscriptionProvider(...)` | `openai`                             |
 | Голос у реальному часі | `api.registerRealtimeVoiceProvider(...)`      | `openai`                             |
 | Розуміння медіа       | `api.registerMediaUnderstandingProvider(...)`  | `openai`, `google`                   |
 | Генерація зображень   | `api.registerImageGenerationProvider(...)`     | `openai`, `google`, `fal`, `minimax` |
@@ -53,152 +53,156 @@ x-i18n:
 | Генерація відео       | `api.registerVideoGenerationProvider(...)`     | `qwen`                               |
 | Отримання вебданих    | `api.registerWebFetchProvider(...)`            | `firecrawl`                          |
 | Вебпошук              | `api.registerWebSearchProvider(...)`           | `google`                             |
-| Канал / обмін повідомленнями | `api.registerChannel(...)`               | `msteams`, `matrix`                  |
+| Канал / повідомлення  | `api.registerChannel(...)`                     | `msteams`, `matrix`                  |
 | Виявлення Gateway     | `api.registerGatewayDiscoveryService(...)`     | `bonjour`                            |
 
 <Note>
-Плагін, який не реєструє жодної можливості, але надає хуки, інструменти, сервіси виявлення або фонові сервіси, є **застарілим плагіном лише з хуками**. Цей шаблон усе ще повністю підтримується.
+Plugin, який реєструє нуль можливостей, але надає hooks, інструменти, служби виявлення або фонові служби, є **застарілим Plugin лише з hooks**. Цей шаблон усе ще повністю підтримується.
 </Note>
 
 ### Позиція щодо зовнішньої сумісності
 
-Модель можливостей уже впроваджена в core і використовується сьогодні вбудованими/рідними плагінами, але сумісність зовнішніх плагінів усе ще потребує вищої планки, ніж «експортовано, отже, заморожено».
+Модель можливостей уже впроваджена в core і сьогодні використовується вбудованими/нативними Plugin, але сумісність із зовнішніми Plugin усе ще потребує суворішого критерію, ніж «якщо це експортується, значить це зафіксовано».
 
-| Ситуація з плагіном                            | Рекомендація                                                                                      |
-| ---------------------------------------------- | ------------------------------------------------------------------------------------------------- |
-| Наявні зовнішні плагіни                        | Підтримуйте роботу інтеграцій на основі хуків; це базовий рівень сумісності.                     |
-| Нові вбудовані/рідні плагіни                   | Віддавайте перевагу явній реєстрації можливостей замість vendor-specific reach-ins або нових дизайнів лише з хуками. |
-| Зовнішні плагіни, що переходять на реєстрацію можливостей | Дозволено, але вважайте допоміжні поверхні, специфічні для можливостей, такими, що еволюціонують, якщо документація не позначає їх як стабільні. |
+| Ситуація з Plugin                               | Рекомендація                                                                                   |
+| ----------------------------------------------- | ---------------------------------------------------------------------------------------------- |
+| Наявні зовнішні Plugin                          | Підтримуйте працездатність інтеграцій на основі hooks; це базовий рівень сумісності.          |
+| Нові вбудовані/нативні Plugin                   | Надавайте перевагу явній реєстрації можливостей замість специфічних для постачальника втручань або нових дизайнів лише з hooks. |
+| Зовнішні Plugin, що переходять на реєстрацію можливостей | Дозволено, але вважайте допоміжні поверхні для конкретних можливостей такими, що ще розвиваються, якщо документація не позначає їх як стабільні. |
 
-Реєстрація можливостей — це бажаний напрям. Застарілі хуки залишаються найбезпечнішим шляхом без зламів для зовнішніх плагінів під час переходу. Не всі експортовані допоміжні підшляхи однакові — надавайте перевагу вузьким документованим контрактам замість випадкових експортів допоміжних засобів.
+Реєстрація можливостей — це бажаний напрямок. Застарілі hooks залишаються найбезпечнішим шляхом без порушення сумісності для зовнішніх Plugin під час переходу. Експортовані допоміжні підшляхи не всі однакові — надавайте перевагу вузьким задокументованим контрактам замість випадкових експортів допоміжних засобів.
 
-### Форми плагінів
+### Форми Plugin
 
-OpenClaw класифікує кожен завантажений Plugin за формою на основі його фактичної поведінки реєстрації (а не лише статичних метаданих):
+OpenClaw класифікує кожен завантажений Plugin за формою на основі його фактичної поведінки під час реєстрації (а не лише статичних метаданих):
 
 <AccordionGroup>
   <Accordion title="plain-capability">
-    Реєструє рівно один тип можливості (наприклад, плагін лише провайдера, як-от `mistral`).
+    Реєструє рівно один тип можливості (наприклад, Plugin лише постачальника, як-от `mistral`).
   </Accordion>
   <Accordion title="hybrid-capability">
-    Реєструє кілька типів можливостей (наприклад, `openai` володіє текстовим inference, мовленням, розумінням медіа та генерацією зображень).
+    Реєструє кілька типів можливостей (наприклад, `openai` володіє текстовим висновком, мовленням, розумінням медіа та генерацією зображень).
   </Accordion>
   <Accordion title="hook-only">
-    Реєструє лише хуки (типізовані або власні), без можливостей, інструментів, команд чи сервісів.
+    Реєструє лише hooks (типізовані або користувацькі), без можливостей, інструментів, команд чи служб.
   </Accordion>
   <Accordion title="non-capability">
-    Реєструє інструменти, команди, сервіси або маршрути, але не можливості.
+    Реєструє інструменти, команди, служби або маршрути, але не можливості.
   </Accordion>
 </AccordionGroup>
 
-Використовуйте `openclaw plugins inspect <id>`, щоб побачити форму плагіна та розподіл можливостей. Докладніше див. у [Довіднику CLI](/uk/cli/plugins#inspect).
+Використовуйте `openclaw plugins inspect <id>`, щоб побачити форму Plugin і розподіл можливостей. Докладніше див. у [довіднику CLI](/uk/cli/plugins#inspect).
 
-### Застарілі хуки
+### Застарілі hooks
 
-Хук `before_agent_start` залишається підтримуваним як шлях сумісності для плагінів лише з хуками. Від нього досі залежать застарілі реальні плагіни.
+Hook `before_agent_start` залишається підтримуваним як шлях сумісності для Plugin лише з hooks. Реальні застарілі Plugin досі від нього залежать.
 
-Напрям:
+Напрямок:
 
-- зберігати його працездатним
+- зберігати його працездатність
 - документувати його як застарілий
-- надавати перевагу `before_model_resolve` для роботи з перевизначенням моделі/провайдера
-- надавати перевагу `before_prompt_build` для зміни промптів
-- видаляти лише після того, як реальне використання зменшиться і покриття фікстурами доведе безпечність міграції
+- для перевизначення моделі/постачальника надавати перевагу `before_model_resolve`
+- для змінювання prompt надавати перевагу `before_prompt_build`
+- видаляти лише після зниження реального використання й після того, як покриття фікстурами доведе безпечність міграції
 
 ### Сигнали сумісності
 
-Коли ви запускаєте `openclaw doctor` або `openclaw plugins inspect <id>`, ви можете побачити одну з таких міток:
+Коли ви запускаєте `openclaw doctor` або `openclaw plugins inspect <id>`, ви можете побачити одну з таких позначок:
 
-| Сигнал                   | Значення                                                     |
-| ------------------------ | ------------------------------------------------------------ |
-| **config valid**         | Конфігурація коректно парситься, а плагіни успішно розв’язуються |
-| **compatibility advisory** | Плагін використовує підтримуваний, але старіший шаблон (наприклад, `hook-only`) |
-| **legacy warning**       | Плагін використовує `before_agent_start`, який є застарілим  |
-| **hard error**           | Конфігурація невалідна або плагін не вдалося завантажити     |
+| Сигнал                     | Значення                                                   |
+| -------------------------- | ---------------------------------------------------------- |
+| **config valid**           | Конфігурація коректно розбирається, і Plugin успішно визначаються |
+| **compatibility advisory** | Plugin використовує підтримуваний, але старіший шаблон (наприклад, `hook-only`) |
+| **legacy warning**         | Plugin використовує `before_agent_start`, який є застарілим |
+| **hard error**             | Конфігурація некоректна або Plugin не вдалося завантажити  |
 
-Ні `hook-only`, ні `before_agent_start` сьогодні не зламають ваш плагін: `hook-only` є лише рекомендаційним сигналом, а `before_agent_start` викликає лише попередження. Ці сигнали також з’являються в `openclaw status --all` і `openclaw plugins doctor`.
+Ні `hook-only`, ні `before_agent_start` сьогодні не зламають ваш Plugin: `hook-only` є рекомендаційним сигналом, а `before_agent_start` лише викликає попередження. Ці сигнали також з’являються в `openclaw status --all` і `openclaw plugins doctor`.
 
 ## Огляд архітектури
 
 Система Plugin OpenClaw має чотири шари:
 
 <Steps>
-  <Step title="Manifest + виявлення">
-    OpenClaw знаходить кандидатів у плагіни у налаштованих шляхах, коренях робочих просторів, глобальних коренях плагінів і серед вбудованих плагінів. Виявлення спочатку читає рідні manifest `openclaw.plugin.json` разом із підтримуваними manifest пакетів.
+  <Step title="Маніфест + виявлення">
+    OpenClaw знаходить потенційні Plugin у налаштованих шляхах, коренях робочого простору, глобальних коренях Plugin і серед вбудованих Plugin. Виявлення спочатку читає нативні маніфести `openclaw.plugin.json` разом із підтримуваними маніфестами пакунків.
   </Step>
   <Step title="Увімкнення + валідація">
-    Core вирішує, чи виявлений плагін увімкнено, вимкнено, заблоковано або вибрано для ексклюзивного слота, такого як memory.
+    Core визначає, чи знайдений Plugin увімкнений, вимкнений, заблокований або вибраний для ексклюзивного слота, такого як пам’ять.
   </Step>
-  <Step title="Завантаження runtime">
-    Рідні Plugin OpenClaw завантажуються в межах процесу через jiti і реєструють можливості в центральному реєстрі. Сумісні пакети нормалізуються в записи реєстру без імпорту коду runtime.
+  <Step title="Завантаження середовища виконання">
+    Нативні Plugin OpenClaw завантажуються в межах процесу через jiti та реєструють можливості в центральному реєстрі. Сумісні пакунки нормалізуються в записи реєстру без імпорту коду середовища виконання.
   </Step>
-  <Step title="Споживання поверхонь">
-    Решта OpenClaw читає реєстр, щоб надавати інструменти, канали, налаштування провайдерів, хуки, HTTP-маршрути, команди CLI та сервіси.
+  <Step title="Використання поверхонь">
+    Решта OpenClaw читає реєстр, щоб надавати інструменти, канали, налаштування постачальників, hooks, HTTP-маршрути, команди CLI та служби.
   </Step>
 </Steps>
 
-Зокрема для CLI плагінів, виявлення кореневих команд розділено на дві фази:
+Саме для CLI Plugin виявлення кореневих команд поділено на дві фази:
 
-- метадані на етапі парсингу надходять із `registerCli(..., { descriptors: [...] })`
-- реальний модуль CLI плагіна може залишатися lazy і реєструватися під час першого виклику
+- метадані на етапі розбору надходять із `registerCli(..., { descriptors: [...] })`
+- справжній модуль CLI Plugin може залишатися лінивим і реєструватися під час першого виклику
 
-Це дає змогу зберігати CLI-код, яким володіє плагін, усередині плагіна, водночас дозволяючи OpenClaw резервувати імена кореневих команд до парсингу.
+Це дозволяє тримати код CLI, що належить Plugin, усередині самого Plugin, водночас даючи OpenClaw можливість резервувати імена кореневих команд ще до розбору.
 
 Важлива межа проєктування:
 
-- валідація manifest/config має працювати на основі **метаданих manifest/schema** без виконання коду плагіна
-- виявлення рідних можливостей може завантажувати код точки входу довіреного плагіна для побудови неактивуючого знімка реєстру
-- нативна поведінка runtime походить із шляху `register(api)` модуля плагіна з `api.registrationMode === "full"`
+- валідація маніфесту/конфігурації має працювати на основі **метаданих маніфесту/схеми** без виконання коду Plugin
+- виявлення нативних можливостей може завантажувати код входу довіреного Plugin, щоб побудувати знімок реєстру без активації
+- нативна поведінка середовища виконання походить із шляху `register(api)` модуля Plugin, де `api.registrationMode === "full"`
 
-Такий поділ дає OpenClaw змогу перевіряти конфігурацію, пояснювати відсутні/вимкнені плагіни й будувати підказки UI/schema до того, як повний runtime стане активним.
+Такий поділ дозволяє OpenClaw перевіряти конфігурацію, пояснювати відсутні/вимкнені Plugin і будувати підказки для UI/схеми до повної активації середовища виконання.
 
-### Таблиця пошуку плагінів
+### Знімок метаданих Plugin і таблиця пошуку
 
-Під час запуску Gateway будує `PluginLookUpTable` з індексу встановлених плагінів і реєстру manifest для поточного знімка конфігурації. Таблиця є лише метаданими: вона зберігає id плагінів, записи manifest, діагностику, мапи власників, нормалізатор id плагінів і стартовий план плагінів. Вона не містить завантажених модулів плагінів, SDK провайдерів, вмісту пакетів або експортів runtime.
+Під час запуску Gateway будується один `PluginMetadataSnapshot` для поточного знімка конфігурації. Цей знімок містить лише метадані: індекс установлених Plugin, реєстр маніфестів, діагностику маніфестів, карти власників, нормалізатор ідентифікаторів Plugin і записи маніфестів. Він не містить завантажених модулів Plugin, SDK постачальників, вмісту пакунків або експортів середовища виконання.
 
-Таблиця пошуку тримає повторні рішення під час запуску на швидкому шляху:
+Валідація конфігурації, що враховує Plugin, автоматичне ввімкнення під час запуску та bootstrap Plugin у Gateway використовують цей знімок замість того, щоб окремо перебудовувати метадані маніфестів/індексів. `PluginLookUpTable` походить із того самого знімка й додає план запуску Plugin для поточної конфігурації середовища виконання.
 
-- володіння каналами
-- відкладений запуск каналів
-- стартові id плагінів
-- володіння провайдерами та CLI-бекендами
-- володіння setup provider, aliases команд, провайдерами каталогу моделей і контрактами manifest
+Знімок і таблиця пошуку тримають повторювані рішення під час запуску на швидкому шляху:
 
-Межею безпеки є заміна знімка, а не мутація. Перебудовуйте таблицю, коли змінюються конфігурація, інвентар плагінів, записи встановлення або політика збереженого індексу. Не сприймайте її як широкий змінний глобальний реєстр і не зберігайте необмежену кількість історичних таблиць. Завантаження плагінів runtime залишається окремим від метаданих таблиці пошуку, щоб застарілий runtime-стан не міг сховатися за кешем метаданих.
+- володіння каналом
+- відкладений запуск каналу
+- ідентифікатори Plugin для запуску
+- володіння постачальником і backend CLI
+- володіння setup provider, псевдонімом команди, постачальником каталогу моделей і контрактом маніфесту
+- валідація схеми конфігурації Plugin і схеми конфігурації каналу
+- рішення щодо автоматичного ввімкнення під час запуску
 
-Деякі викликачи холодного шляху все ще реконструюють реєстри manifest безпосередньо зі збереженого індексу встановлених плагінів замість отримання Gateway `PluginLookUpTable`. Цей резервний шлях зберігає невеликий обмежений кеш у пам’яті, ключований індексом встановлення, формою запиту, політикою конфігурації, коренями runtime і сигнатурами файлів manifest/package. Це резервна страховка для повторної реконструкції індексу, а не бажаний гарячий шлях Gateway. Надавайте перевагу передаванню поточної таблиці пошуку або явного реєстру manifest через потоки runtime, коли викликач уже його має.
+Межею безпеки є заміна знімка, а не його мутація. Перебудовуйте знімок, коли змінюються конфігурація, інвентар Plugin, записи встановлення або політика збереженого індексу. Не сприймайте його як широкий змінюваний глобальний реєстр і не зберігайте необмежену кількість історичних знімків. Завантаження Plugin у середовищі виконання залишається окремим від знімків метаданих, щоб застарілий стан середовища виконання не міг бути прихований за кешем метаданих.
+
+Деякі виклики холодного шляху все ще напряму реконструюють реєстри маніфестів із збереженого індексу встановлених Plugin замість отримання `PluginLookUpTable` Gateway. Цей резервний шлях підтримує невеликий обмежений кеш у пам’яті з ключами за встановленим індексом, формою запиту, політикою конфігурації, коренями середовища виконання та сигнатурами файлів маніфесту/пакунка. Це резервний механізм безпеки для повторної реконструкції індексу, а не бажаний гарячий шлях Gateway. Надавайте перевагу передаванню поточної таблиці пошуку або явного реєстру маніфестів через потоки середовища виконання, коли викликач уже має їх.
 
 ### Планування активації
 
-Планування активації є частиною control plane. Викликачі можуть запитати, які плагіни релевантні для конкретної команди, провайдера, каналу, маршруту, agent harness або можливості, перш ніж завантажувати ширші реєстри runtime.
+Планування активації є частиною площини керування. Викликачі можуть запитувати, які Plugin стосуються конкретної команди, постачальника, каналу, маршруту, harness агента або можливості, ще до завантаження ширших реєстрів середовища виконання.
 
-Планувальник зберігає сумісність поточної поведінки manifest:
+Планувальник зберігає поточну поведінку маніфестів сумісною:
 
 - поля `activation.*` — це явні підказки для планувальника
-- `providers`, `channels`, `commandAliases`, `setup.providers`, `contracts.tools` і хуки залишаються резервним варіантом володіння manifest
+- `providers`, `channels`, `commandAliases`, `setup.providers`, `contracts.tools` і hooks залишаються резервним варіантом володіння маніфесту
 - API планувальника лише з id залишається доступним для наявних викликачів
 - API плану повідомляє мітки причин, щоб діагностика могла відрізняти явні підказки від резервного володіння
 
 <Warning>
-Не сприймайте `activation` як хук життєвого циклу або заміну для `register(...)`. Це метадані, що використовуються для звуження завантаження. Надавайте перевагу полям володіння, коли вони вже описують зв’язок; використовуйте `activation` лише для додаткових підказок планувальника.
+Не сприймайте `activation` як hook життєвого циклу або заміну для `register(...)`. Це метадані, які використовуються для звуження завантаження. Надавайте перевагу полям володіння, коли вони вже описують зв’язок; використовуйте `activation` лише для додаткових підказок планувальника.
 </Warning>
 
-### Плагіни каналів і спільний інструмент message
+### Plugin каналів і спільний інструмент повідомлень
 
-Плагінам каналів не потрібно реєструвати окремий інструмент надсилання/редагування/реакції для звичайних дій чату. OpenClaw зберігає один спільний інструмент `message` у core, а плагіни каналів володіють специфічним для каналу виявленням і виконанням за ним.
+Plugin каналів не потрібно реєструвати окремий інструмент send/edit/react для звичайних дій у чаті. OpenClaw зберігає один спільний інструмент `message` у core, а Plugin каналів володіють специфічним для каналу виявленням і виконанням за ним.
 
 Поточна межа така:
 
-- core володіє хостом спільного інструмента `message`, підключенням до промптів, обліком сесій/потоків і диспетчеризацією виконання
-- плагіни каналів володіють виявленням дій в області видимості, виявленням можливостей і будь-якими специфічними для каналу фрагментами schema
-- плагіни каналів володіють граматикою розмов сесії, специфічною для провайдера, наприклад тим, як id розмов кодують id потоків або успадковуються від батьківських розмов
-- плагіни каналів виконують фінальну дію через свій адаптер дій
+- core володіє хостом спільного інструмента `message`, wiring prompt, обліком сесій/потоків і диспетчеризацією виконання
+- Plugin каналів володіють виявленням дій в обмеженій області, виявленням можливостей і будь-якими фрагментами схеми, специфічними для каналу
+- Plugin каналів володіють граматикою розмов сесій, специфічною для постачальника, наприклад тим, як ідентифікатори розмов кодують ідентифікатори потоків або успадковуються від батьківських розмов
+- Plugin каналів виконують фінальну дію через свій адаптер дій
 
-Для плагінів каналів поверхнею SDK є `ChannelMessageActionAdapter.describeMessageTool(...)`. Цей уніфікований виклик виявлення дає плагіну змогу повертати видимі дії, можливості та внески у schema разом, щоб ці частини не розходилися.
+Для Plugin каналів поверхнею SDK є `ChannelMessageActionAdapter.describeMessageTool(...)`. Цей уніфікований виклик виявлення дає Plugin змогу повертати видимі дії, можливості та внески до схеми разом, щоб ці частини не розходилися.
 
-Коли параметр інструмента message, специфічний для каналу, містить джерело медіа, наприклад локальний шлях або віддалений URL медіа, плагін також має повертати `mediaSourceParams` з `describeMessageTool(...)`. Core використовує цей явний список для застосування нормалізації шляхів sandbox і підказок доступу до вихідних медіа без жорсткого кодування назв параметрів, якими володіє плагін. Надавайте перевагу мапам на рівні дій, а не одному плоскому списку на весь канал, щоб параметр медіа лише для профілю не нормалізувався для нерелевантних дій, таких як `send`.
+Коли параметр інструмента повідомлень, специфічний для каналу, містить джерело медіа, наприклад локальний шлях або віддалений URL медіа, Plugin також має повертати `mediaSourceParams` із `describeMessageTool(...)`. Core використовує цей явний список, щоб застосовувати нормалізацію шляхів у sandbox і підказки доступу до вихідних медіа без жорсткого кодування назв параметрів, що належать Plugin. Надавайте там перевагу картам, обмеженим дією, а не одному плоскому списку на весь канал, щоб параметр медіа лише для профілю не нормалізувався для не пов’язаних дій, як-от `send`.
 
-Core передає область runtime у цей крок виявлення. Важливі поля включають:
+Core передає область середовища виконання в цей крок виявлення. Важливі поля включають:
 
 - `accountId`
 - `currentChannelId`
@@ -209,106 +213,106 @@ Core передає область runtime у цей крок виявлення
 - `agentId`
 - довірений вхідний `requesterSenderId`
 
-Це важливо для плагінів, чутливих до контексту. Канал може приховувати або показувати дії message залежно від активного облікового запису, поточної кімнати/потоку/повідомлення або довіреної ідентичності запитувача без жорсткого кодування специфічних для каналу розгалужень у core-інструменті `message`.
+Це важливо для Plugin, чутливих до контексту. Канал може приховувати або показувати дії інструмента повідомлень залежно від активного облікового запису, поточної кімнати/потоку/повідомлення або довіреної ідентичності запитувача без жорсткого кодування специфічних для каналу гілок у core-інструменті `message`.
 
-Саме тому зміни маршрутизації embedded-runner усе ще залишаються роботою плагіна: runner відповідає за передавання поточної ідентичності чату/сесії в межу виявлення плагіна, щоб спільний інструмент `message` показував правильну поверхню, якою володіє канал, для поточного ходу.
+Саме тому зміни маршрутизації embedded-runner усе ще залишаються роботою Plugin: runner відповідає за передавання поточної ідентичності чату/сесії в межу виявлення Plugin, щоб спільний інструмент `message` показував правильну поверхню, що належить каналу, для поточного ходу.
 
-Для допоміжних засобів виконання, якими володіє канал, вбудовані плагіни мають зберігати runtime виконання всередині власних модулів extension. Core більше не володіє runtime дій повідомлень Discord, Slack, Telegram або WhatsApp у `src/agents/tools`. Ми не публікуємо окремі підшляхи `plugin-sdk/*-action-runtime`, а вбудовані плагіни мають імпортувати власний локальний runtime-код безпосередньо зі своїх модулів, якими володіє extension.
+Для допоміжних засобів виконання, що належать каналу, вбудовані Plugin мають тримати середовище виконання всередині власних модулів extension. Core більше не володіє середовищами виконання дій повідомлень Discord, Slack, Telegram або WhatsApp у `src/agents/tools`. Ми не публікуємо окремі підшляхи `plugin-sdk/*-action-runtime`, і вбудовані Plugin мають напряму імпортувати свій локальний код середовища виконання з модулів, що належать їхнім extension.
 
-Та сама межа застосовується і до SDK-seam із назвами провайдерів загалом: core не повинен імпортувати специфічні для каналу convenience-barrel для Slack, Discord, Signal, WhatsApp або подібних extension. Якщо core потрібна певна поведінка, він має або споживати власний barrel `api.ts` / `runtime-api.ts` вбудованого плагіна, або підняти цю потребу до вузької узагальненої можливості в спільному SDK.
+Та сама межа загалом застосовується і до іменованих за постачальником швів SDK: core не має імпортувати зручні barrel-модулі, специфічні для каналів Slack, Discord, Signal, WhatsApp або подібних extension. Якщо core потрібна певна поведінка, він має або споживати власний barrel `api.ts` / `runtime-api.ts` вбудованого Plugin, або підняти цю потребу до вузької узагальненої можливості в спільному SDK.
 
-Вбудовані плагіни дотримуються того самого правила. `runtime-api.ts` вбудованого плагіна не повинен повторно експортувати власний брендовий фасад `openclaw/plugin-sdk/<plugin-id>`. Такі брендові фасади залишаються shim сумісності для зовнішніх плагінів і старіших споживачів, але вбудовані плагіни мають використовувати локальні експорти плюс вузькі узагальнені підшляхи SDK, такі як `openclaw/plugin-sdk/channel-policy`, `openclaw/plugin-sdk/runtime-store` або `openclaw/plugin-sdk/webhook-ingress`. Новий код не повинен додавати SDK-фасади, специфічні для id плагіна, якщо цього не вимагає межа сумісності для наявної зовнішньої екосистеми.
+Вбудовані Plugin дотримуються того самого правила. `runtime-api.ts` вбудованого Plugin не має повторно експортувати власний фірмовий фасад `openclaw/plugin-sdk/<plugin-id>`. Такі фірмові фасади залишаються сумісними shim для зовнішніх Plugin і старіших споживачів, але вбудовані Plugin мають використовувати локальні експорти разом із вузькими узагальненими підшляхами SDK, такими як `openclaw/plugin-sdk/channel-policy`, `openclaw/plugin-sdk/runtime-store` або `openclaw/plugin-sdk/webhook-ingress`. Новий код не повинен додавати фасади SDK, специфічні для ідентифікатора Plugin, якщо цього не вимагає межа сумісності для вже наявної зовнішньої екосистеми.
 
 Зокрема для опитувань є два шляхи виконання:
 
-- `outbound.sendPoll` — спільна базова лінія для каналів, які відповідають загальній моделі опитувань
-- `actions.handleAction("poll")` — бажаний шлях для специфічної для каналу семантики опитувань або додаткових параметрів опитування
+- `outbound.sendPoll` — це спільна базова лінія для каналів, які відповідають загальній моделі опитувань
+- `actions.handleAction("poll")` — це бажаний шлях для специфічної для каналу семантики опитувань або додаткових параметрів опитування
 
-Тепер core відкладає спільний розбір опитувань до моменту, коли диспетчеризація опитування плагіна відхиляє дію, щоб обробники опитувань, якими володіє плагін, могли приймати специфічні для каналу поля опитувань і не блокувалися спочатку узагальненим парсером опитувань.
+Тепер core відкладає спільний розбір опитувань доти, доки dispatch опитування Plugin не відхилить дію, щоб обробники опитувань, що належать Plugin, могли приймати специфічні для каналу поля опитування, не будучи спочатку заблокованими узагальненим аналізатором опитувань.
 
-Повну послідовність запуску див. у [Внутрішній архітектурі плагінів](/uk/plugins/architecture-internals).
+Повну послідовність запуску див. у [внутрішній архітектурі Plugin](/uk/plugins/architecture-internals).
 
 ## Модель володіння можливостями
 
-OpenClaw розглядає рідний Plugin як межу володіння для **компанії** або **функції**, а не як набір не пов’язаних між собою інтеграцій.
+OpenClaw розглядає нативний Plugin як межу володіння для **компанії** або **функції**, а не як набір не пов’язаних між собою інтеграцій.
 
 Це означає:
 
-- плагін компанії зазвичай має володіти всіма поверхнями OpenClaw цієї компанії
-- плагін функції зазвичай має володіти всією поверхнею функції, яку він запроваджує
-- канали мають споживати спільні можливості core замість того, щоб щоразу перевпроваджувати поведінку провайдера
+- Plugin компанії зазвичай має володіти всіма поверхнями цієї компанії, видимими для OpenClaw
+- Plugin функції зазвичай має володіти повною поверхнею функції, яку він запроваджує
+- канали мають споживати спільні можливості core замість того, щоб довільно повторно реалізовувати поведінку постачальника
 
 <AccordionGroup>
-  <Accordion title="Вендор із багатьма можливостями">
-    `openai` володіє текстовим inference, мовленням, голосом у реальному часі, розумінням медіа та генерацією зображень. `google` володіє текстовим inference, а також розумінням медіа, генерацією зображень і вебпошуком. `qwen` володіє текстовим inference, а також розумінням медіа й генерацією відео.
+  <Accordion title="Vendor multi-capability">
+    `openai` володіє текстовим висновком, мовленням, голосом у реальному часі, розумінням медіа та генерацією зображень. `google` володіє текстовим висновком, а також розумінням медіа, генерацією зображень і вебпошуком. `qwen` володіє текстовим висновком, а також розумінням медіа й генерацією відео.
   </Accordion>
-  <Accordion title="Вендор з однією можливістю">
-    `elevenlabs` і `microsoft` володіють мовленням; `firecrawl` володіє web-fetch; `minimax` / `mistral` / `moonshot` / `zai` володіють бекендами розуміння медіа.
+  <Accordion title="Vendor single-capability">
+    `elevenlabs` і `microsoft` володіють мовленням; `firecrawl` володіє отриманням вебданих; `minimax` / `mistral` / `moonshot` / `zai` володіють backend-реалізаціями розуміння медіа.
   </Accordion>
-  <Accordion title="Плагін функції">
-    `voice-call` володіє транспортом викликів, інструментами, CLI, маршрутами та мостом медіапотоку Twilio, але споживає спільні можливості мовлення, транскрибування в реальному часі та голосу в реальному часі замість прямого імпорту вендорських плагінів.
+  <Accordion title="Feature plugin">
+    `voice-call` володіє транспортом викликів, інструментами, CLI, маршрутами та мостом Twilio media-stream, але споживає спільні можливості мовлення, транскрипції в реальному часі та голосу в реальному часі замість прямого імпорту Plugin постачальників.
   </Accordion>
 </AccordionGroup>
 
-Бажаний кінцевий стан:
+Бажаний кінцевий стан такий:
 
-- OpenAI живе в одному плагіні, навіть якщо він охоплює текстові моделі, мовлення, зображення та майбутнє відео
-- інший вендор може зробити те саме для власної області
-- каналам байдуже, який плагін вендора володіє провайдером; вони споживають спільний контракт можливості, який надає core
+- OpenAI міститься в одному Plugin, навіть якщо він охоплює текстові моделі, мовлення, зображення та майбутнє відео
+- інший постачальник може робити те саме для власної поверхні
+- каналам байдуже, який Plugin постачальника володіє provider; вони споживають спільний контракт можливості, який надає core
 
 Ось ключова відмінність:
 
 - **plugin** = межа володіння
-- **capability** = контракт core, який можуть реалізовувати або споживати кілька плагінів
+- **capability** = контракт core, який можуть реалізовувати або споживати кілька Plugin
 
-Тож якщо OpenClaw додає нову доменну область, наприклад відео, перше питання не таке: «який провайдер має жорстко закодувати обробку відео?» Перше питання таке: «який контракт core для можливості відео?» Щойно такий контракт з’являється, вендорські плагіни можуть реєструватися щодо нього, а плагіни каналів/функцій можуть його споживати.
+Тому якщо OpenClaw додає новий домен, наприклад відео, перше запитання — не «який provider має жорстко закодувати обробку відео?». Перше запитання — «який контракт core для можливості відео?». Щойно цей контракт з’являється, Plugin постачальників можуть реєструватися для нього, а Plugin каналів/функцій можуть його споживати.
 
-Якщо можливість ще не існує, правильний крок зазвичай такий:
+Якщо можливість ще не існує, правильним кроком зазвичай є:
 
 <Steps>
   <Step title="Визначте можливість">
     Визначте відсутню можливість у core.
   </Step>
-  <Step title="Експонуйте через SDK">
-    Експонуйте її через API/runtime плагіна в типізований спосіб.
+  <Step title="Відкрийте її через SDK">
+    Надайте її через API/runtime Plugin у типізований спосіб.
   </Step>
   <Step title="Підключіть споживачів">
     Підключіть канали/функції до цієї можливості.
   </Step>
-  <Step title="Реалізації вендорів">
-    Дозвольте вендорським плагінам реєструвати реалізації.
+  <Step title="Реалізації постачальників">
+    Дозвольте Plugin постачальників реєструвати реалізації.
   </Step>
 </Steps>
 
-Це робить володіння явним і водночас уникає поведінки core, яка залежить від одного вендора або від одноразового шляху коду, специфічного для плагіна.
+Це зберігає явне володіння та водночас уникає поведінки core, що залежить від одного постачальника або одноразового кодового шляху, специфічного для Plugin.
 
 ### Шарування можливостей
 
-Використовуйте таку ментальну модель, вирішуючи, де має належати код:
+Використовуйте цю ментальну модель, коли вирішуєте, де має належати код:
 
 <Tabs>
   <Tab title="Шар можливостей core">
     Спільна оркестрація, політика, fallback, правила злиття конфігурації, семантика доставки та типізовані контракти.
   </Tab>
-  <Tab title="Шар вендорського плагіна">
-    Специфічні для вендора API, автентифікація, каталоги моделей, синтез мовлення, генерація зображень, майбутні відеобекенди, ендпоїнти usage.
+  <Tab title="Шар Plugin постачальника">
+    API, автентифікація, каталоги моделей, синтез мовлення, генерація зображень, майбутні backend-реалізації відео, кінцеві точки використання, специфічні для постачальника.
   </Tab>
-  <Tab title="Шар плагіна каналу/функції">
-    Інтеграція Slack/Discord/voice-call тощо, яка споживає можливості core і подає їх на власній поверхні.
+  <Tab title="Шар Plugin каналу/функції">
+    Інтеграція Slack/Discord/voice-call тощо, яка споживає можливості core і представляє їх на своїй поверхні.
   </Tab>
 </Tabs>
 
 Наприклад, TTS має таку форму:
 
-- core володіє політикою TTS під час відповіді, порядком fallback, prefs і доставкою в канал
+- core володіє політикою TTS під час відповіді, порядком fallback, налаштуваннями та доставкою в канал
 - `openai`, `elevenlabs` і `microsoft` володіють реалізаціями синтезу
-- `voice-call` споживає допоміжний засіб runtime для телефонного TTS
+- `voice-call` споживає допоміжний засіб середовища виконання TTS для телефонії
 
-Того самого шаблону слід надавати перевагу і для майбутніх можливостей.
+Той самий шаблон слід надавати перевагу і для майбутніх можливостей.
 
-### Приклад плагіна компанії з багатьма можливостями
+### Приклад Plugin компанії з кількома можливостями
 
-Плагін компанії має виглядати цілісно зовні. Якщо OpenClaw має спільні контракти для моделей, мовлення, транскрибування в реальному часі, голосу в реальному часі, розуміння медіа, генерації зображень, генерації відео, web fetch і вебпошуку, вендор може володіти всіма своїми поверхнями в одному місці:
+Plugin компанії має виглядати цілісним ззовні. Якщо OpenClaw має спільні контракти для моделей, мовлення, транскрипції в реальному часі, голосу в реальному часі, розуміння медіа, генерації зображень, генерації відео, отримання вебданих і вебпошуку, постачальник може володіти всіма своїми поверхнями в одному місці:
 
 ```ts
 import type { OpenClawPluginDefinition } from "openclaw/plugin-sdk/plugin-entry";
@@ -362,58 +366,58 @@ const plugin: OpenClawPluginDefinition = {
 export default plugin;
 ```
 
-Важливими є не точні назви допоміжних засобів. Важлива форма:
+Важливі не точні назви допоміжних засобів. Важлива форма:
 
-- один плагін володіє поверхнею вендора
-- core, як і раніше, володіє контрактами можливостей
-- канали та плагіни функцій споживають допоміжні засоби `api.runtime.*`, а не код вендора
-- тести контрактів можуть перевіряти, що плагін зареєстрував можливості, якими він стверджує, що володіє
+- один Plugin володіє поверхнею постачальника
+- core усе ще володіє контрактами можливостей
+- канали та Plugin функцій споживають допоміжні засоби `api.runtime.*`, а не код постачальника
+- контрактні тести можуть перевіряти, що Plugin зареєстрував можливості, якими, як він стверджує, володіє
 
 ### Приклад можливості: розуміння відео
 
-OpenClaw уже розглядає розуміння зображень/аудіо/відео як одну спільну можливість. До неї застосовується та сама модель володіння:
+OpenClaw уже розглядає розуміння зображень/аудіо/відео як одну спільну можливість. Там застосовується та сама модель володіння:
 
 <Steps>
   <Step title="Core визначає контракт">
     Core визначає контракт розуміння медіа.
   </Step>
-  <Step title="Вендорські плагіни реєструються">
-    Вендорські плагіни реєструють `describeImage`, `transcribeAudio` і `describeVideo`, коли це застосовно.
+  <Step title="Plugin постачальників реєструються">
+    Plugin постачальників реєструють `describeImage`, `transcribeAudio` і `describeVideo`, де це застосовно.
   </Step>
   <Step title="Споживачі використовують спільну поведінку">
-    Канали та плагіни функцій споживають спільну поведінку core замість прямого підключення до коду вендора.
+    Канали та Plugin функцій споживають спільну поведінку core замість прямого підключення до коду постачальника.
   </Step>
 </Steps>
 
-Це запобігає вбудовуванню припущень щодо відео одного провайдера в core. Плагін володіє поверхнею вендора; core володіє контрактом можливості та поведінкою fallback.
+Це дає змогу уникнути вбудовування припущень одного постачальника щодо відео в core. Plugin володіє поверхнею постачальника; core володіє контрактом можливості та поведінкою fallback.
 
-Генерація відео вже використовує ту саму послідовність: core володіє типізованим контрактом можливості та допоміжним засобом runtime, а вендорські плагіни реєструють реалізації `api.registerVideoGenerationProvider(...)` щодо нього.
+Генерація відео вже використовує ту саму послідовність: core володіє типізованим контрактом можливості та допоміжним засобом середовища виконання, а Plugin постачальників реєструють для неї реалізації `api.registerVideoGenerationProvider(...)`.
 
-Потрібен конкретний контрольний список розгортання? Див. [Посібник з можливостей](/uk/plugins/architecture).
+Потрібен конкретний контрольний список упровадження? Див. [Кулінарну книгу можливостей](/uk/plugins/architecture).
 
-## Контракти та забезпечення виконання
+## Контракти та забезпечення дотримання
 
-Поверхня API плагіна навмисно типізована й централізована в `OpenClawPluginApi`. Цей контракт визначає підтримувані точки реєстрації та допоміжні засоби runtime, на які може покладатися плагін.
+Поверхня API Plugin навмисно типізована та централізована в `OpenClawPluginApi`. Цей контракт визначає підтримувані точки реєстрації та допоміжні засоби середовища виконання, на які може покладатися Plugin.
 
 Чому це важливо:
 
-- автори плагінів отримують один стабільний внутрішній стандарт
-- core може відхиляти дубльоване володіння, наприклад коли два плагіни реєструють той самий id провайдера
-- під час запуску можна показувати діагностику, придатну до дій, для некоректної реєстрації
-- тести контрактів можуть забезпечувати володіння вбудованих плагінів і запобігати тихому дрейфу
+- автори Plugin отримують один стабільний внутрішній стандарт
+- core може відхиляти дубльоване володіння, наприклад коли два Plugin реєструють однаковий id provider
+- під час запуску можна показувати діагностику з дієвими рекомендаціями для некоректної реєстрації
+- контрактні тести можуть забезпечувати володіння вбудованих Plugin і запобігати непомітному дрейфу
 
-Існує два шари забезпечення виконання:
+Є два шари забезпечення дотримання:
 
 <AccordionGroup>
-  <Accordion title="Забезпечення реєстрації під час runtime">
-    Реєстр плагінів перевіряє реєстрації під час завантаження плагінів. Приклади: дубльовані id провайдерів, дубльовані id провайдерів мовлення та некоректні реєстрації створюють діагностику плагіна замість невизначеної поведінки.
+  <Accordion title="Забезпечення дотримання під час реєстрації в runtime">
+    Реєстр Plugin перевіряє реєстрації під час завантаження Plugin. Приклади: дубльовані id provider, дубльовані id постачальників мовлення та некоректні реєстрації породжують діагностику Plugin замість невизначеної поведінки.
   </Accordion>
-  <Accordion title="Тести контрактів">
-    Вбудовані плагіни фіксуються в реєстрах контрактів під час тестових запусків, щоб OpenClaw міг явно перевіряти володіння. Сьогодні це використовується для провайдерів моделей, провайдерів мовлення, провайдерів вебпошуку та володіння реєстраціями вбудованих плагінів.
+  <Accordion title="Контрактні тести">
+    Вбудовані Plugin фіксуються в контрактних реєстрах під час тестових запусків, щоб OpenClaw міг явно перевіряти володіння. Сьогодні це використовується для постачальників моделей, постачальників мовлення, постачальників вебпошуку та володіння вбудованою реєстрацією.
   </Accordion>
 </AccordionGroup>
 
-Практичний ефект полягає в тому, що OpenClaw заздалегідь знає, який плагін володіє якою поверхнею. Це дає core і каналам змогу безшовно компонуватися, тому що володіння оголошене, типізоване й придатне до тестування, а не неявне.
+Практичний наслідок полягає в тому, що OpenClaw заздалегідь знає, який Plugin володіє якою поверхнею. Це дає core і каналам змогу безшовно поєднуватися, оскільки володіння оголошене, типізоване й придатне до тестування, а не неявне.
 
 ### Що має входити до контракту
 
@@ -421,67 +425,67 @@ OpenClaw уже розглядає розуміння зображень/ауд
   <Tab title="Хороші контракти">
     - типізовані
     - малі
-    - специфічні для можливостей
+    - специфічні для можливості
     - належать core
-    - придатні для повторного використання кількома плагінами
-    - можуть споживатися каналами/функціями без знання про вендора
+    - багаторазово використовуються кількома Plugin
+    - можуть споживатися каналами/функціями без знання про постачальника
   </Tab>
   <Tab title="Погані контракти">
-    - специфічна для вендора політика, прихована в core
-    - одноразові escape hatch плагіна, які обходять реєстр
-    - код каналу, що напряму звертається до реалізації вендора
-    - ad hoc об’єкти runtime, які не є частиною `OpenClawPluginApi` або `api.runtime`
+    - політика, специфічна для постачальника, прихована в core
+    - одноразові лазівки для Plugin, які обходять реєстр
+    - код каналу, що напряму звертається до реалізації постачальника
+    - довільні runtime-об’єкти, які не є частиною `OpenClawPluginApi` або `api.runtime`
   </Tab>
 </Tabs>
 
-Коли є сумнів, піднімайте рівень абстракції: спочатку визначте можливість, а вже потім дайте плагінам підключатися до неї.
+Коли є сумніви, піднімайте рівень абстракції: спочатку визначте можливість, а потім дозвольте Plugin підключатися до неї.
 
 ## Модель виконання
 
-Рідні Plugin OpenClaw працюють **у межах процесу** разом із Gateway. Вони не ізольовані в sandbox. Завантажений рідний плагін має ту саму межу довіри на рівні процесу, що й код core.
+Нативні Plugin OpenClaw працюють **у межах процесу** разом із Gateway. Вони не ізольовані в sandbox. Завантажений нативний Plugin має ту саму межу довіри на рівні процесу, що й код core.
 
 <Warning>
 Наслідки:
 
-- рідний Plugin може реєструвати інструменти, мережеві обробники, хуки та сервіси
-- помилка в рідному Plugin може аварійно завершити роботу gateway або дестабілізувати його
-- зловмисний рідний Plugin еквівалентний довільному виконанню коду всередині процесу OpenClaw
+- нативний Plugin може реєструвати інструменти, мережеві обробники, hooks і служби
+- помилка в нативному Plugin може призвести до збою або дестабілізації Gateway
+- зловмисний нативний Plugin еквівалентний довільному виконанню коду всередині процесу OpenClaw
   </Warning>
 
-Сумісні пакети типово безпечніші, тому що OpenClaw наразі розглядає їх як паки метаданих/контенту. У поточних релізах це переважно означає вбудовані Skills.
+Сумісні пакунки безпечніші за замовчуванням, тому що OpenClaw наразі розглядає їх як пакунки метаданих/вмісту. У поточних релізах це переважно означає вбудовані Skills.
 
-Використовуйте allowlist і явні шляхи встановлення/завантаження для невбудованих плагінів. Розглядайте плагіни робочого простору як код для часу розробки, а не як типове рішення для production.
+Для невбудованих Plugin використовуйте allowlist і явні шляхи встановлення/завантаження. Сприймайте Plugin робочого простору як код для часу розробки, а не як виробничі значення за замовчуванням.
 
-Для назв пакетів вбудованого робочого простору зберігайте id плагіна прив’язаним до назви npm: типово `@openclaw/<id>` або схвалений типізований суфікс, такий як `-provider`, `-plugin`, `-speech`, `-sandbox` чи `-media-understanding`, коли пакет навмисно надає вужчу роль плагіна.
+Для імен пакетів workspace, що є вбудованими, прив’язуйте ідентифікатор Plugin до імені npm: `@openclaw/<id>` за замовчуванням або до схваленого типізованого суфікса, такого як `-provider`, `-plugin`, `-speech`, `-sandbox` чи `-media-understanding`, коли пакет навмисно відкриває вужчу роль Plugin.
 
 <Note>
-**Примітка про довіру:**
+**Примітка щодо довіри:**
 
-- `plugins.allow` довіряє **id плагінів**, а не походженню джерела.
-- Плагін робочого простору з тим самим id, що й вбудований плагін, навмисно затіняє вбудовану копію, коли цей плагін робочого простору увімкнено/додано до allowlist.
-- Це нормально й корисно для локальної розробки, тестування патчів і hotfix.
-- Довіра до вбудованого плагіна визначається зі знімка джерела — manifest і коду на диску під час завантаження — а не з метаданих встановлення. Пошкоджений або підмінений запис встановлення не може непомітно розширити поверхню довіри вбудованого плагіна понад те, що стверджує реальне джерело.
+- `plugins.allow` довіряє **ідентифікаторам Plugin**, а не походженню джерела.
+- Plugin workspace з тим самим id, що й вбудований Plugin, навмисно затіняє вбудовану копію, коли цей Plugin workspace увімкнений/доданий до allowlist.
+- Це нормально й корисно для локальної розробки, тестування патчів і термінових виправлень.
+- Довіра до вбудованого Plugin визначається зі знімка джерела — маніфесту та коду на диску під час завантаження — а не з метаданих встановлення. Пошкоджений або підмінений запис встановлення не може непомітно розширити поверхню довіри вбудованого Plugin понад те, що заявляє фактичне джерело.
   </Note>
 
 ## Межа експорту
 
-OpenClaw експортує можливості, а не зручні реалізації.
+OpenClaw експортує можливості, а не зручності реалізації.
 
-Зберігайте реєстрацію можливостей публічною. Скорочуйте експорти допоміжних засобів, що не є контрактами:
+Залишайте публічною реєстрацію можливостей. Скорочуйте експорти допоміжних засобів, що не є частиною контракту:
 
-- підшляхи допоміжних засобів, специфічні для вбудованих плагінів
-- підшляхи plumbing runtime, не призначені як публічний API
-- зручні допоміжні засоби, специфічні для вендора
+- підшляхи допоміжних засобів, специфічні для вбудованих Plugin
+- підшляхи plumbing середовища виконання, не призначені як публічний API
+- зручні допоміжні засоби, специфічні для постачальника
 - допоміжні засоби setup/onboarding, які є деталями реалізації
 
-Деякі підшляхи допоміжних засобів вбудованих плагінів усе ще залишаються у згенерованій мапі експортів SDK для сумісності та супроводу вбудованих плагінів. Поточні приклади включають `plugin-sdk/feishu`, `plugin-sdk/feishu-setup`, `plugin-sdk/zalo`, `plugin-sdk/zalo-setup`, `plugin-sdk/channel-config-schema-legacy` і кілька seam `plugin-sdk/matrix*`. Розглядайте їх як зарезервовані застарілі експорти, а не як рекомендований шаблон SDK для нових сторонніх плагінів.
+Деякі підшляхи допоміжних засобів вбудованих Plugin усе ще залишаються в згенерованій карті експорту SDK задля сумісності та обслуговування вбудованих Plugin. Поточні приклади включають `plugin-sdk/feishu`, `plugin-sdk/feishu-setup`, `plugin-sdk/zalo`, `plugin-sdk/zalo-setup`, `plugin-sdk/channel-config-schema-legacy` і кілька швів `plugin-sdk/matrix*`. Сприймайте їх як зарезервовані застарілі експорти, а не як рекомендований шаблон SDK для нових сторонніх Plugin.
 
-## Внутрішні деталі та довідник
+## Внутрішні компоненти та довідка
 
-Щоб дізнатися про конвеєр завантаження, модель реєстру, runtime-хуки провайдера, HTTP-маршрути Gateway, schema інструмента message, розв’язання цілей каналів, каталоги провайдерів, плагіни рушія контексту та посібник із додавання нової можливості, див. [Внутрішню архітектуру Plugin](/uk/plugins/architecture-internals).
+Щодо конвеєра завантаження, моделі реєстру, гачків runtime постачальника, HTTP-маршрутів Gateway, схем інструмента повідомлень, визначення цілі каналу, каталогів постачальників, Plugin рушія контексту та посібника з додавання нової можливості див. [внутрішню архітектуру Plugin](/uk/plugins/architecture-internals).
 
-## Пов’язане
+## Пов’язані матеріали
 
-- [Створення плагінів](/uk/plugins/building-plugins)
-- [Manifest Plugin](/uk/plugins/manifest)
+- [Створення Plugin](/uk/plugins/building-plugins)
+- [Маніфест Plugin](/uk/plugins/manifest)
 - [Налаштування SDK Plugin](/uk/plugins/sdk-setup)