chore(i18n): refresh uk translations

docs/uk/cli/gateway.md

@@ -2,27 +2,27 @@
 read_when:
     - Запуск Gateway з CLI (розробка або сервери)
     - Налагодження автентифікації Gateway, режимів прив’язки та підключення
-    - Виявлення шлюзів через Bonjour (локально + DNS-SD широкої зони)
+    - Виявлення шлюзів через Bonjour (локально + DNS-SD широкої області)
 sidebarTitle: Gateway
-summary: CLI шлюзу OpenClaw (`openclaw gateway`) — запуск, запити та виявлення шлюзів
+summary: OpenClaw Gateway CLI (`openclaw gateway`) — запуск, запит і виявлення шлюзів
 title: Gateway
 x-i18n:
-    generated_at: "2026-04-27T04:26:19Z"
+    generated_at: "2026-04-27T08:07:53Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 795d30511ad7a98093edfcfb862869349e1454d3e01f18dec7912cc2128934de
+    source_hash: 9c909e8f6e1fb56b612eb1a0826cd993626c9f65b1736924b33c95a37dc60d14
     source_path: cli/gateway.md
     workflow: 15
 ---
 
-Gateway — це WebSocket-сервер OpenClaw (канали, вузли, сесії, хуки). Підкоманди на цій сторінці доступні через `openclaw gateway …`.
+Gateway — це сервер WebSocket OpenClaw (канали, вузли, сесії, хуки). Підкоманди на цій сторінці використовуються під `openclaw gateway …`.
 
 <CardGroup cols={3}>
-  <Card title="Виявлення через Bonjour" href="/uk/gateway/bonjour">
-    Налаштування локального mDNS + DNS-SD широкої зони.
+  <Card title="Виявлення Bonjour" href="/uk/gateway/bonjour">
+    Налаштування локального mDNS + DNS-SD широкої області.
   </Card>
   <Card title="Огляд виявлення" href="/uk/gateway/discovery">
-    Як OpenClaw оголошує шлюзи та знаходить їх.
+    Як OpenClaw рекламує та знаходить шлюзи.
   </Card>
   <Card title="Конфігурація" href="/uk/gateway/configuration">
     Ключі конфігурації Gateway верхнього рівня.
@@ -37,20 +37,20 @@ Gateway — це WebSocket-сервер OpenClaw (канали, вузли, се
 openclaw gateway
 ```
 
-Псевдонім для запуску у передньому плані:
+Псевдонім для запуску на передньому плані:
 
 ```bash
 openclaw gateway run
 ```
 
 <AccordionGroup>
-  <Accordion title="Поведінка запуску">
-    - За замовчуванням Gateway відмовляється запускатися, якщо в `~/.openclaw/openclaw.json` не встановлено `gateway.mode=local`. Використовуйте `--allow-unconfigured` для ad-hoc/dev запусків.
-    - Очікується, що `openclaw onboard --mode local` і `openclaw setup` записують `gateway.mode=local`. Якщо файл існує, але `gateway.mode` відсутній, вважайте це пошкодженою або перезаписаною конфігурацією та виправте її, а не припускайте неявно локальний режим.
-    - Якщо файл існує і `gateway.mode` відсутній, Gateway вважає це підозрілим пошкодженням конфігурації та відмовляється «вгадувати local» за вас.
-    - Прив’язка поза межами loopback без автентифікації блокується (захисне обмеження).
-    - `SIGUSR1` запускає перезапуск у межах процесу, якщо це дозволено (`commands.restart` увімкнено за замовчуванням; установіть `commands.restart: false`, щоб заборонити ручний перезапуск, водночас `gateway tool/config apply/update` залишаться дозволеними).
-    - Обробники `SIGINT`/`SIGTERM` зупиняють процес gateway, але не відновлюють жодний нестандартний стан термінала. Якщо ви обгортаєте CLI через TUI або raw-mode ввід, відновіть термінал перед виходом.
+  <Accordion title="Поведінка під час запуску">
+    - За замовчуванням Gateway відмовляється запускатися, якщо в `~/.openclaw/openclaw.json` не встановлено `gateway.mode=local`. Використовуйте `--allow-unconfigured` для одноразових/розробницьких запусків.
+    - Очікується, що `openclaw onboard --mode local` і `openclaw setup` запишуть `gateway.mode=local`. Якщо файл існує, але `gateway.mode` відсутній, вважайте це пошкодженою або перезаписаною конфігурацією та відновіть її замість неявного припущення локального режиму.
+    - Якщо файл існує, а `gateway.mode` відсутній, Gateway вважає це підозрілим пошкодженням конфігурації й відмовляється «вгадувати local» за вас.
+    - Прив’язка поза межами loopback без автентифікації заблокована (захисний механізм безпеки).
+    - `SIGUSR1` запускає перезапуск у межах процесу, якщо це дозволено (`commands.restart` увімкнено за замовчуванням; встановіть `commands.restart: false`, щоб заблокувати ручний перезапуск, тоді як застосування gateway tool/config apply/update залишиться дозволеним).
+    - Обробники `SIGINT`/`SIGTERM` зупиняють процес gateway, але не відновлюють жоден спеціальний стан термінала. Якщо ви обгортаєте CLI у TUI або введення в raw mode, відновіть термінал перед виходом.
   </Accordion>
 </AccordionGroup>
 
@@ -66,37 +66,37 @@ openclaw gateway run
   Перевизначення режиму автентифікації.
 </ParamField>
 <ParamField path="--token <token>" type="string">
-  Перевизначення токена (також встановлює `OPENCLAW_GATEWAY_TOKEN` для процесу).
+  Перевизначення токена (також установлює `OPENCLAW_GATEWAY_TOKEN` для процесу).
 </ParamField>
 <ParamField path="--password <password>" type="string">
   Перевизначення пароля.
 </ParamField>
 <ParamField path="--password-file <path>" type="string">
-  Зчитати пароль gateway з файлу.
+  Прочитати пароль gateway з файлу.
 </ParamField>
 <ParamField path="--tailscale <off|serve|funnel>" type="string">
   Відкрити Gateway через Tailscale.
 </ParamField>
 <ParamField path="--tailscale-reset-on-exit" type="boolean">
-  Скинути конфігурацію Tailscale serve/funnel під час завершення.
+  Скинути конфігурацію serve/funnel Tailscale під час завершення роботи.
 </ParamField>
 <ParamField path="--allow-unconfigured" type="boolean">
-  Дозволити запуск gateway без `gateway.mode=local` у конфігурації. Обходить захист запуску лише для ad-hoc/dev початкового запуску; не записує та не виправляє файл конфігурації.
+  Дозволити запуск gateway без `gateway.mode=local` у конфігурації. Обходить захист запуску лише для одноразового/розробницького початкового налаштування; не записує і не відновлює файл конфігурації.
 </ParamField>
 <ParamField path="--dev" type="boolean">
   Створити dev-конфігурацію + робочий простір, якщо вони відсутні (пропускає BOOTSTRAP.md).
 </ParamField>
 <ParamField path="--reset" type="boolean">
-  Скинути dev-конфігурацію + облікові дані + сесії + робочий простір (потрібен `--dev`).
+  Скинути dev-конфігурацію + облікові дані + сесії + робочий простір (потребує `--dev`).
 </ParamField>
 <ParamField path="--force" type="boolean">
-  Перед запуском завершити будь-який наявний listener на вибраному порту.
+  Завершити будь-який наявний слухач на вибраному порту перед запуском.
 </ParamField>
 <ParamField path="--verbose" type="boolean">
   Докладні журнали.
 </ParamField>
 <ParamField path="--cli-backend-logs" type="boolean">
-  Показувати в консолі лише журнали бекенду CLI (і ввімкнути stdout/stderr).
+  Показувати в консолі лише журнали бекенда CLI (і ввімкнути stdout/stderr).
 </ParamField>
 <ParamField path="--ws-log <auto|full|compact>" type="string" default="auto">
   Стиль журналу WebSocket.
@@ -105,10 +105,10 @@ openclaw gateway run
   Псевдонім для `--ws-log compact`.
 </ParamField>
 <ParamField path="--raw-stream" type="boolean">
-  Записувати необроблені події потоку моделі в jsonl.
+  Записувати сирі події потоку моделі в jsonl.
 </ParamField>
 <ParamField path="--raw-stream-path <path>" type="string">
-  Шлях до jsonl необробленого потоку.
+  Шлях до jsonl сирого потоку.
 </ParamField>
 
 <Warning>
@@ -117,30 +117,30 @@ openclaw gateway run
 
 ### Профілювання запуску
 
-- Установіть `OPENCLAW_GATEWAY_STARTUP_TRACE=1`, щоб журналювати тривалість етапів під час запуску Gateway.
-- Запустіть `pnpm test:startup:gateway -- --runs 5 --warmup 1`, щоб виміряти запуск Gateway. Бенчмарк фіксує перший вивід процесу, `/healthz`, `/readyz` і часові показники трасування запуску.
+- Установіть `OPENCLAW_GATEWAY_STARTUP_TRACE=1`, щоб журналювати час фаз під час запуску Gateway, включно із затримкою `eventLoopMax` для кожної фази та часом таблиці пошуку Plugin для installed-index, реєстру маніфестів, планування запуску та роботи owner-map.
+- Запустіть `pnpm test:startup:gateway -- --runs 5 --warmup 1`, щоб виміряти швидкодію запуску Gateway. Бенчмарк фіксує перший вивід процесу, `/healthz`, `/readyz`, час трасування запуску, затримку event loop і деталі часу таблиці пошуку Plugin.
 
 ## Запит до запущеного Gateway
 
-Усі команди запитів використовують WebSocket RPC.
+Усі команди запиту використовують WebSocket RPC.
 
 <Tabs>
   <Tab title="Режими виводу">
-    - За замовчуванням: читабельний для людини (кольоровий у TTY).
-    - `--json`: JSON для машинного читання (без стилізації/спінера).
+    - За замовчуванням: зручний для читання людиною формат (з кольором у TTY).
+    - `--json`: машинозчитуваний JSON (без стилізації/індикатора).
     - `--no-color` (або `NO_COLOR=1`): вимкнути ANSI, зберігши людський макет.
   </Tab>
   <Tab title="Спільні параметри">
     - `--url <url>`: URL WebSocket Gateway.
     - `--token <token>`: токен Gateway.
     - `--password <password>`: пароль Gateway.
-    - `--timeout <ms>`: тайм-аут/бюджет (залежить від команди).
+    - `--timeout <ms>`: тайм-аут/бюджет часу (залежить від команди).
     - `--expect-final`: чекати на «final» відповідь (виклики агента).
   </Tab>
 </Tabs>
 
 <Note>
-Коли ви встановлюєте `--url`, CLI не використовує облікові дані з конфігурації або середовища як резервні. Явно передайте `--token` або `--password`. Відсутність явно вказаних облікових даних є помилкою.
+Коли ви задаєте `--url`, CLI не повертається до облікових даних із конфігурації чи середовища. Передайте `--token` або `--password` явно. Відсутність явно заданих облікових даних є помилкою.
 </Note>
 
 ### `gateway health`
@@ -149,11 +149,11 @@ openclaw gateway run
 openclaw gateway health --url ws://127.0.0.1:18789
 ```
 
-HTTP-ендпоінт `/healthz` є перевіркою життєздатності: він повертає відповідь, щойно сервер може відповідати по HTTP. HTTP-ендпоінт `/readyz` є суворішим і залишається червоним, поки стартові sidecar-компоненти, канали або налаштовані хуки ще завершують ініціалізацію.
+HTTP-ендпоінт `/healthz` — це перевірка життєздатності: він відповідає, щойно сервер може обробляти HTTP. HTTP-ендпоінт `/readyz` суворіший і лишається неготовим, поки побічні процеси запуску, канали або налаштовані хуки ще завершують ініціалізацію.
 
 ### `gateway usage-cost`
 
-Отримати зведення вартості використання з журналів сесій.
+Отримати зведення usage-cost із журналів сесій.
 
 ```bash
 openclaw gateway usage-cost
@@ -167,7 +167,7 @@ openclaw gateway usage-cost --json
 
 ### `gateway stability`
 
-Отримати нещодавній діагностичний журнал стабільності із запущеного Gateway.
+Отримати нещодавній записувач діагностичної стабільності із запущеного Gateway.
 
 ```bash
 openclaw gateway stability
@@ -184,28 +184,28 @@ openclaw gateway stability --json
   Фільтрувати за типом діагностичної події, наприклад `payload.large` або `diagnostic.memory.pressure`.
 </ParamField>
 <ParamField path="--since-seq <seq>" type="number">
-  Включати лише події після діагностичного номера послідовності.
+  Включати лише події після номера послідовності діагностики.
 </ParamField>
 <ParamField path="--bundle [path]" type="string">
-  Зчитати збережений пакет стабільності замість виклику запущеного Gateway. Використовуйте `--bundle latest` (або просто `--bundle`) для найновішого пакета в каталозі стану або передайте шлях до JSON пакета безпосередньо.
+  Прочитати збережений пакет стабільності замість звернення до запущеного Gateway. Використовуйте `--bundle latest` (або просто `--bundle`) для найновішого пакета в каталозі стану, або передайте шлях до JSON пакета безпосередньо.
 </ParamField>
 <ParamField path="--export" type="boolean">
-  Записати zip-файл діагностики підтримки, яким можна поділитися, замість виведення подробиць стабільності.
+  Записати zip-файл із діагностикою підтримки, придатний для поширення, замість виведення деталей стабільності.
 </ParamField>
 <ParamField path="--output <path>" type="string">
   Шлях виводу для `--export`.
 </ParamField>
 
 <AccordionGroup>
-  <Accordion title="Конфіденційність і поведінка пакета">
-    - Записи зберігають операційні метадані: назви подій, кількості, розміри в байтах, показники пам’яті, стан черги/сесії, назви каналів/плагінів і відредаговані зведення сесій. Вони не зберігають текст чату, тіла webhook, виводи інструментів, необроблені тіла запитів або відповідей, токени, cookie, секретні значення, імена хостів або необроблені ідентифікатори сесій. Установіть `diagnostics.enabled: false`, щоб повністю вимкнути реєстратор.
-    - Під час аварійного завершення Gateway, тайм-аутів завершення роботи та збоїв запуску після перезапуску OpenClaw записує той самий діагностичний знімок до `~/.openclaw/logs/stability/openclaw-stability-*.json`, якщо реєстратор має події. Перегляньте найновіший пакет за допомогою `openclaw gateway stability --bundle latest`; `--limit`, `--type` і `--since-seq` також застосовуються до виводу пакета.
+  <Accordion title="Конфіденційність і поведінка пакетів">
+    - Записи зберігають операційні метадані: назви подій, лічильники, розміри в байтах, показники пам’яті, стан черги/сесії, назви каналів/плагінів і відредаговані зведення сесій. Вони не зберігають текст чату, тіла Webhook, результати інструментів, сирі тіла запитів або відповідей, токени, cookies, секретні значення, імена хостів чи сирі id сесій. Установіть `diagnostics.enabled: false`, щоб повністю вимкнути записувач.
+    - У разі фатального завершення Gateway, тайм-аутів завершення роботи й помилок запуску під час перезапуску OpenClaw записує той самий діагностичний знімок у `~/.openclaw/logs/stability/openclaw-stability-*.json`, якщо записувач має події. Перегляньте найновіший пакет за допомогою `openclaw gateway stability --bundle latest`; `--limit`, `--type` і `--since-seq` також застосовуються до виводу пакета.
   </Accordion>
 </AccordionGroup>
 
 ### `gateway diagnostics export`
 
-Записати локальний zip-файл діагностики, призначений для прикріплення до звітів про помилки. Модель конфіденційності та вміст пакета дивіться в [Експорт діагностики](/uk/gateway/diagnostics).
+Записати локальний zip-файл діагностики, призначений для додавання до звітів про помилки. Модель конфіденційності та вміст пакета див. у [Експорт діагностики](/uk/gateway/diagnostics).
 
 ```bash
 openclaw gateway diagnostics export
@@ -214,13 +214,13 @@ openclaw gateway diagnostics export --json
 ```
 
 <ParamField path="--output <path>" type="string">
-  Шлях до вихідного zip-файлу. За замовчуванням — експорт підтримки в каталозі стану.
+  Шлях до вихідного zip-файлу. За замовчуванням — export для підтримки в каталозі стану.
 </ParamField>
 <ParamField path="--log-lines <count>" type="number" default="5000">
   Максимальна кількість очищених рядків журналу для включення.
 </ParamField>
 <ParamField path="--log-bytes <bytes>" type="number" default="1000000">
-  Максимальна кількість байтів журналу для аналізу.
+  Максимальна кількість байтів журналу для перевірки.
 </ParamField>
 <ParamField path="--url <url>" type="string">
   URL WebSocket Gateway для знімка health.
@@ -238,12 +238,12 @@ openclaw gateway diagnostics export --json
   Пропустити пошук збереженого пакета стабільності.
 </ParamField>
 <ParamField path="--json" type="boolean">
-  Вивести записаний шлях, розмір і маніфест у форматі JSON.
+  Вивести записаний шлях, розмір і маніфест як JSON.
 </ParamField>
 
-Експорт містить маніфест, зведення у Markdown, форму конфігурації, очищені деталі конфігурації, очищені зведення журналів, очищені знімки status/health Gateway та найновіший пакет стабільності, якщо він існує.
+Експорт містить маніфест, зведення у Markdown, форму конфігурації, очищені деталі конфігурації, очищені зведення журналів, очищені знімки status/health Gateway і найновіший пакет стабільності, якщо він існує.
 
-Його призначено для спільного використання. Він зберігає операційні деталі, які допомагають під час налагодження, наприклад безпечні поля журналів OpenClaw, назви підсистем, коди стану, тривалості, налаштовані режими, порти, ідентифікатори плагінів, ідентифікатори провайдерів, несекретні налаштування функцій і відредаговані операційні повідомлення журналів. Він пропускає або редагує текст чату, тіла webhook, виводи інструментів, облікові дані, cookie, ідентифікатори облікових записів/повідомлень, текст prompt/інструкцій, імена хостів і секретні значення. Якщо повідомлення у стилі LogTape схоже на текст корисного навантаження користувача/чату/інструмента, експорт зберігає лише факт пропуску повідомлення та кількість його байтів.
+Він призначений для поширення. Він зберігає операційні деталі, що допомагають у налагодженні, як-от безпечні поля журналів OpenClaw, назви підсистем, коди стану, тривалості, налаштовані режими, порти, id плагінів, id провайдерів, несекретні налаштування функцій і відредаговані повідомлення операційних журналів. Він пропускає або редагує текст чату, тіла Webhook, результати інструментів, облікові дані, cookies, ідентифікатори облікових записів/повідомлень, текст prompt/інструкцій, імена хостів і секретні значення. Коли повідомлення у стилі LogTape схоже на текст корисного навантаження користувача/чату/інструмента, експорт зберігає лише позначку про те, що повідомлення пропущено, і кількість його байтів.
 
 ### `gateway status`
 
@@ -256,7 +256,7 @@ openclaw gateway status --require-rpc
 ```
 
 <ParamField path="--url <url>" type="string">
-  Додати явну ціль перевірки. Налаштовані remote + localhost також перевіряються.
+  Додати явну ціль перевірки. Налаштований віддалений хост + localhost усе одно перевіряються.
 </ParamField>
 <ParamField path="--token <token>" type="string">
   Автентифікація токеном для перевірки.
@@ -274,25 +274,25 @@ openclaw gateway status --require-rpc
   Також сканувати служби системного рівня.
 </ParamField>
 <ParamField path="--require-rpc" type="boolean">
-  Підвищити стандартну перевірку підключення до перевірки читання та завершуватися з ненульовим кодом, якщо ця перевірка читання не вдається. Не можна поєднувати з `--no-probe`.
+  Підвищити стандартну перевірку підключення до перевірки читання й завершуватися з ненульовим кодом, якщо ця перевірка читання не вдалася. Не можна поєднувати з `--no-probe`.
 </ParamField>
 
 <AccordionGroup>
-  <Accordion title="Семантика status">
-    - `gateway status` залишається доступною для діагностики, навіть якщо локальна конфігурація CLI відсутня або невалідна.
-    - Стандартна `gateway status` підтверджує стан служби, підключення WebSocket і можливість автентифікації, видиму під час handshake. Вона не підтверджує операції читання/запису/адміністрування.
-    - Діагностичні перевірки не змінюють стан для первинної автентифікації пристрою: вони повторно використовують наявний кешований токен пристрою, якщо він існує, але не створюють нову ідентичність CLI-пристрою або запис pairing для пристрою лише з правом читання лише для перевірки status.
-    - `gateway status` за можливості розв’язує налаштовані SecretRef автентифікації для автентифікації перевірки.
-    - Якщо потрібний SecretRef автентифікації не розв’язується в цьому шляху команди, `gateway status --json` повідомляє `rpc.authWarning`, коли перевірка підключення/автентифікації RPC не вдається; явно передайте `--token`/`--password` або спочатку виправте джерело секрету.
-    - Якщо перевірка успішна, попередження про нерозв’язані auth-ref пригнічуються, щоб уникнути хибнопозитивних спрацювань.
-    - Використовуйте `--require-rpc` у скриптах та автоматизації, коли недостатньо лише служби, що слухає, і потрібно, щоб RPC-виклики з областю читання також були справними.
-    - `--deep` додає best-effort сканування додаткових установок launchd/systemd/schtasks. Коли виявлено кілька служб, схожих на gateway, вивід для людини показує підказки з очищення й попереджає, що в більшості конфігурацій на одній машині має працювати один gateway.
-    - Вивід для людини містить розв’язаний шлях до файлового журналу, а також знімок шляхів/валідності конфігурації CLI та служби, щоб допомогти діагностувати розходження профілю або каталогу стану.
+  <Accordion title="Семантика статусу">
+    - `gateway status` залишається доступним для діагностики, навіть коли локальна конфігурація CLI відсутня або недійсна.
+    - Типовий `gateway status` підтверджує стан служби, WebSocket-з’єднання та можливість автентифікації, видиму під час handshake. Він не підтверджує операції читання/запису/адміністрування.
+    - Діагностичні проби не змінюють стан для першої автентифікації пристрою: вони повторно використовують наявний кешований токен пристрою, якщо він існує, але не створюють нову ідентичність пристрою CLI або запис pairing read-only пристрою лише для перевірки статусу.
+    - `gateway status` за можливості розв’язує налаштовані SecretRef автентифікації для probe auth.
+    - Якщо потрібний SecretRef автентифікації не розв’язується в цьому шляху команди, `gateway status --json` повідомляє `rpc.authWarning`, коли не вдається probe підключення/автентифікації; явно передайте `--token`/`--password` або спочатку виправте джерело секрету.
+    - Якщо probe успішний, попередження про нерозв’язані auth-ref пригнічуються, щоб уникнути хибнопозитивних спрацьовувань.
+    - Використовуйте `--require-rpc` у скриптах і автоматизації, коли недостатньо лише служби, що слухає, і потрібно, щоб також були працездатними виклики RPC з областю читання.
+    - `--deep` додає best-effort-сканування додаткових інсталяцій launchd/systemd/schtasks. Коли виявлено кілька служб, схожих на gateway, людиночитаний вивід показує підказки з очищення та попереджає, що в більшості налаштувань на машині має працювати один gateway.
+    - Людиночитаний вивід містить розв’язаний шлях до файлового журналу, а також знімок шляхів/дійсності конфігурації CLI-порівняно-зі-службою, щоб допомогти діагностувати дрейф профілю або каталогу стану.
   </Accordion>
-  <Accordion title="Перевірки розходження автентифікації Linux systemd">
-    - В установках Linux systemd перевірки розходження автентифікації служби читають значення `Environment=` і `EnvironmentFile=` з unit-файлу (включно з `%h`, шляхами в лапках, кількома файлами та необов’язковими файлами з `-`).
-    - Перевірки розходження розв’язують SecretRef `gateway.auth.token`, використовуючи об’єднане середовище виконання (спочатку середовище команди служби, потім резервне середовище процесу).
-    - Якщо автентифікація токеном фактично не активна (явний `gateway.auth.mode` зі значенням `password`/`none`/`trusted-proxy`, або режим не задано, де може перемогти пароль і жоден кандидат токена не може перемогти), перевірки розходження токена пропускають розв’язання токена конфігурації.
+  <Accordion title="Перевірки дрейфу автентифікації systemd у Linux">
+    - В інсталяціях Linux systemd перевірки дрейфу автентифікації служби читають значення `Environment=` і `EnvironmentFile=` з unit-файлу (включно з `%h`, шляхами в лапках, кількома файлами й необов’язковими файлами з `-`).
+    - Перевірки дрейфу розв’язують SecretRef `gateway.auth.token`, використовуючи об’єднане runtime env (спочатку env команди служби, потім резервне env процесу).
+    - Якщо автентифікація токеном фактично не активна (явний `gateway.auth.mode` зі значенням `password`/`none`/`trusted-proxy`, або mode не задано там, де може перемогти password і жоден кандидат токена не може перемогти), перевірки дрейфу токена пропускають розв’язання токена конфігурації.
   </Accordion>
 </AccordionGroup>
 
@@ -301,16 +301,16 @@ openclaw gateway status --require-rpc
 `gateway probe` — це команда «налагодити все». Вона завжди перевіряє:
 
 - ваш налаштований віддалений gateway (якщо задано), і
-- localhost (loopback) **навіть якщо налаштовано remote**.
+- localhost (loopback) **навіть якщо налаштовано віддалений**.
 
-Якщо ви передаєте `--url`, ця явна ціль додається перед обома. Вивід для людини позначає цілі так:
+Якщо ви передасте `--url`, ця явна ціль додається перед обома. Людиночитаний вивід позначає цілі так:
 
 - `URL (explicit)`
 - `Remote (configured)` або `Remote (configured, inactive)`
 - `Local loopback`
 
 <Note>
-Якщо доступні кілька gateway, команда виведе всі. Кілька gateway підтримуються, коли ви використовуєте ізольовані профілі/порти (наприклад, rescue bot), але в більшості установок усе одно працює один gateway.
+Якщо доступно кілька gateway, буде виведено їх усі. Кілька gateway підтримуються, коли ви використовуєте ізольовані профілі/порти (наприклад, rescue bot), але в більшості інсталяцій усе ще працює один gateway.
 </Note>
 
 ```bash
@@ -320,73 +320,73 @@ openclaw gateway probe --json
 
 <AccordionGroup>
   <Accordion title="Інтерпретація">
-    - `Reachable: yes` означає, що принаймні одна ціль прийняла WebSocket-підключення.
-    - `Capability: read-only|write-capable|admin-capable|pairing-pending|connect-only` повідомляє, що перевірка змогла підтвердити щодо автентифікації. Це окремо від доступності.
-    - `Read probe: ok` означає, що RPC-виклики деталей з областю читання (`health`/`status`/`system-presence`/`config.get`) також успішні.
-    - `Read probe: limited - missing scope: operator.read` означає, що підключення успішне, але RPC із областю читання обмежено. Це повідомляється як **degraded** доступність, а не як повна помилка.
-    - Як і `gateway status`, probe повторно використовує наявну кешовану автентифікацію пристрою, але не створює первинну ідентичність пристрою або стан pairing.
-    - Код виходу є ненульовим лише тоді, коли жодна перевірена ціль не є доступною.
+    - `Reachable: yes` означає, що принаймні одна ціль прийняла WebSocket-з’єднання.
+    - `Capability: read-only|write-capable|admin-capable|pairing-pending|connect-only` показує, що probe зміг підтвердити щодо автентифікації. Це окремо від досяжності.
+    - `Read probe: ok` означає, що також успішно виконалися докладні виклики RPC з областю читання (`health`/`status`/`system-presence`/`config.get`).
+    - `Read probe: limited - missing scope: operator.read` означає, що з’єднання встановлено успішно, але RPC з областю читання обмежений. Це повідомляється як **погіршена** досяжність, а не повний збій.
+    - Як і `gateway status`, probe повторно використовує наявну кешовану автентифікацію пристрою, але не створює стан першої ідентичності пристрою чи pairing.
+    - Код виходу є ненульовим лише тоді, коли жодна перевірена ціль не є досяжною.
   </Accordion>
   <Accordion title="Вивід JSON">
     Верхній рівень:
 
-    - `ok`: принаймні одна ціль доступна.
-    - `degraded`: принаймні одна ціль мала RPC деталей, обмежений областю.
-    - `capability`: найкраща можливість, виявлена серед доступних цілей (`read_only`, `write_capable`, `admin_capable`, `pairing_pending`, `connected_no_operator_scope` або `unknown`).
-    - `primaryTargetId`: найкраща ціль, яку слід вважати активним переможцем, у такому порядку: явний URL, SSH-тунель, налаштований remote, потім local loopback.
-    - `warnings[]`: записи попереджень best-effort з `code`, `message` та необов’язковими `targetIds`.
-    - `network`: підказки URL local loopback/tailnet, виведені з поточної конфігурації та мережі хоста.
+    - `ok`: принаймні одна ціль є досяжною.
+    - `degraded`: принаймні для однієї цілі детальний RPC був обмежений за scope.
+    - `capability`: найкраща можливість, виявлена серед досяжних цілей (`read_only`, `write_capable`, `admin_capable`, `pairing_pending`, `connected_no_operator_scope` або `unknown`).
+    - `primaryTargetId`: найкраща ціль, яку слід вважати активним переможцем, у такому порядку: явний URL, SSH-тунель, налаштований віддалений хост, потім локальний loopback.
+    - `warnings[]`: записи попереджень best-effort з `code`, `message` і необов’язковими `targetIds`.
+    - `network`: підказки URL локального loopback/tailnet, виведені з поточної конфігурації та мережі хоста.
     - `discovery.timeoutMs` і `discovery.count`: фактичний бюджет/кількість результатів виявлення, використані для цього проходу probe.
 
     Для кожної цілі (`targets[].connect`):
 
-    - `ok`: доступність після підключення + класифікація degraded.
-    - `rpcOk`: повний успіх RPC деталей.
-    - `scopeLimited`: RPC деталей не вдалося через відсутню область operator.
+    - `ok`: досяжність після з’єднання + класифікація degraded.
+    - `rpcOk`: повний успіх детального RPC.
+    - `scopeLimited`: детальний RPC не вдався через відсутню operator scope.
 
     Для кожної цілі (`targets[].auth`):
 
-    - `role`: роль автентифікації, повідомлена в `hello-ok`, коли доступно.
-    - `scopes`: надані області, повідомлені в `hello-ok`, коли доступно.
-    - `capability`: класифікація видимої можливості автентифікації для цієї цілі.
+    - `role`: роль автентифікації, повідомлена в `hello-ok`, якщо доступна.
+    - `scopes`: надані scope, повідомлені в `hello-ok`, якщо доступні.
+    - `capability`: показана класифікація можливостей автентифікації для цієї цілі.
 
   </Accordion>
   <Accordion title="Поширені коди попереджень">
-    - `ssh_tunnel_failed`: не вдалося налаштувати SSH-тунель; команда повернулася до прямих перевірок.
-    - `multiple_gateways`: була доступна більше ніж одна ціль; це нетипово, якщо ви навмисно не запускаєте ізольовані профілі, наприклад rescue bot.
-    - `auth_secretref_unresolved`: налаштований SecretRef автентифікації не вдалося розв’язати для цілі, що завершилася помилкою.
-    - `probe_scope_limited`: WebSocket-підключення успішне, але перевірка читання була обмежена через відсутність `operator.read`.
+    - `ssh_tunnel_failed`: не вдалося налаштувати SSH-тунель; команда переключилася на прямі probe.
+    - `multiple_gateways`: було досяжно більше ніж одну ціль; це незвично, якщо тільки ви навмисно не запускаєте ізольовані профілі, наприклад rescue bot.
+    - `auth_secretref_unresolved`: налаштований auth SecretRef не вдалося розв’язати для цілі, що завершилася невдачею.
+    - `probe_scope_limited`: WebSocket-з’єднання встановлено успішно, але read probe був обмежений через відсутність `operator.read`.
   </Accordion>
 </AccordionGroup>
 
-#### Віддалений доступ через SSH (паритет із застосунком Mac)
+#### Віддалено через SSH (паритет із Mac app)
 
-Режим застосунку macOS «Remote over SSH» використовує локальне переадресування порту, щоб віддалений gateway (який може бути прив’язаний лише до loopback) став доступним за адресою `ws://127.0.0.1:<port>`.
+Режим macOS app «Remote over SSH» використовує локальне переспрямування порту, тому віддалений gateway (який може бути прив’язаний лише до loopback) стає досяжним за адресою `ws://127.0.0.1:<port>`.
 
-Еквівалент CLI:
+Еквівалент у CLI:
 
 ```bash
 openclaw gateway probe --ssh user@gateway-host
 ```
 
 <ParamField path="--ssh <target>" type="string">
-  `user@host` або `user@host:port` (порт за замовчуванням — `22`).
+  `user@host` або `user@host:port` (порт за замовчуванням `22`).
 </ParamField>
 <ParamField path="--ssh-identity <path>" type="string">
   Файл ідентичності.
 </ParamField>
 <ParamField path="--ssh-auto" type="boolean">
-  Вибрати перший виявлений хост gateway як ціль SSH із розв’язаного ендпоінта виявлення (`local.` плюс налаштований домен широкої зони, якщо він є). Підказки лише з TXT ігноруються.
+  Вибрати перший виявлений хост gateway як SSH-ціль із розв’язаного endpoint виявлення (`local.` плюс налаштований wide-area domain, якщо є). Підказки лише з TXT ігноруються.
 </ParamField>
 
-Конфігурація (необов’язкова, використовується як типове значення):
+Конфігурація (необов’язково, використовується як значення за замовчуванням):
 
 - `gateway.remote.sshTarget`
 - `gateway.remote.sshIdentity`
 
 ### `gateway call <method>`
 
-Низькорівневий помічник RPC.
+Низькорівневий допоміжний засіб RPC.
 
 ```bash
 openclaw gateway call status
@@ -409,14 +409,14 @@ openclaw gateway call logs.tail --params '{"sinceMs": 60000}'
   Бюджет тайм-ауту.
 </ParamField>
 <ParamField path="--expect-final" type="boolean">
-  Переважно для RPC у стилі агента, які передають проміжні події потоком перед фінальним корисним навантаженням.
+  Головним чином для RPC у стилі агентів, які передають проміжні події потоком перед фінальним корисним навантаженням.
 </ParamField>
 <ParamField path="--json" type="boolean">
-  JSON-вивід для машинного читання.
+  Машинозчитуваний вивід JSON.
 </ParamField>
 
 <Note>
-`--params` має бути валідним JSON.
+`--params` має бути коректним JSON.
 </Note>
 
 ## Керування службою Gateway
@@ -429,9 +429,11 @@ openclaw gateway restart
 openclaw gateway uninstall
 ```
 
-### Установлення з обгорткою
+### Інсталяція з wrapper
 
-Використовуйте `--wrapper`, коли керована служба має запускатися через інший виконуваний файл, наприклад shim менеджера секретів або допоміжну програму run-as. Обгортка отримує звичайні аргументи Gateway і відповідає за те, щоб зрештою виконати `openclaw` або Node з цими аргументами.
+Використовуйте `--wrapper`, коли керована служба має запускатися через інший виконуваний файл, наприклад
+shim менеджера секретів або допоміжний засіб запуску від іншого користувача. Wrapper отримує звичайні аргументи Gateway і
+відповідає за те, щоб зрештою виконати `openclaw` або Node з цими аргументами.
 
 ```bash
 cat > ~/.local/bin/openclaw-doppler <<'EOF'
@@ -445,14 +447,16 @@ openclaw gateway install --wrapper ~/.local/bin/openclaw-doppler --force
 openclaw gateway restart
 ```
 
-Ви також можете задати обгортку через середовище. `gateway install` перевіряє, що шлях указує на виконуваний файл, записує обгортку в `ProgramArguments` служби та зберігає `OPENCLAW_WRAPPER` у середовищі служби для подальших примусових перевстановлень, оновлень і виправлень doctor.
+Ви також можете задати wrapper через середовище. `gateway install` перевіряє, що шлях
+вказує на виконуваний файл, записує wrapper у `ProgramArguments` служби та зберігає
+`OPENCLAW_WRAPPER` у середовищі служби для подальших примусових перевстановлень, оновлень і виправлень через doctor.
 
 ```bash
 OPENCLAW_WRAPPER="$HOME/.local/bin/openclaw-doppler" openclaw gateway install --force
 openclaw doctor
 ```
 
-Щоб видалити збережену обгортку, очистьте `OPENCLAW_WRAPPER` під час перевстановлення:
+Щоб видалити збережений wrapper, очистьте `OPENCLAW_WRAPPER` під час перевстановлення:
 
 ```bash
 OPENCLAW_WRAPPER= openclaw gateway install --force
@@ -466,36 +470,36 @@ openclaw gateway restart
     - `gateway uninstall|start|stop|restart`: `--json`
   </Accordion>
   <Accordion title="Поведінка життєвого циклу">
-    - Використовуйте `gateway restart`, щоб перезапустити керовану службу. Не об’єднуйте `gateway stop` і `gateway start` як заміну перезапуску; у macOS `gateway stop` навмисно вимикає LaunchAgent перед його зупиненням.
-    - Команди життєвого циклу приймають `--json` для скриптів.
+    - Використовуйте `gateway restart`, щоб перезапустити керовану службу. Не поєднуйте `gateway stop` і `gateway start` як заміну перезапуску; у macOS `gateway stop` навмисно вимикає LaunchAgent перед його зупинкою.
+    - Команди життєвого циклу підтримують `--json` для скриптів.
   </Accordion>
-  <Accordion title="Автентифікація та SecretRefs під час установлення">
-    - Коли автентифікація токеном вимагає токен, а `gateway.auth.token` керується через SecretRef, `gateway install` перевіряє, що SecretRef можна розв’язати, але не зберігає розв’язаний токен у метаданих середовища служби.
-    - Якщо автентифікація токеном вимагає токен, а налаштований SecretRef токена не розв’язується, установлення завершується в закритому режимі замість збереження резервного відкритого тексту.
+  <Accordion title="Автентифікація і SecretRefs під час інсталяції">
+    - Коли для автентифікації токеном потрібен токен і `gateway.auth.token` керується через SecretRef, `gateway install` перевіряє, що SecretRef можна розв’язати, але не зберігає розв’язаний токен у метаданих середовища служби.
+    - Якщо для автентифікації токеном потрібен токен, а налаштований SecretRef токена не розв’язується, інсталяція завершується в безпечному режимі замість збереження резервного відкритого тексту.
     - Для автентифікації паролем у `gateway run` надавайте перевагу `OPENCLAW_GATEWAY_PASSWORD`, `--password-file` або `gateway.auth.password` на основі SecretRef замість вбудованого `--password`.
-    - У режимі автентифікації, що визначається автоматично, лише shell-змінна `OPENCLAW_GATEWAY_PASSWORD` не послаблює вимоги до токена під час установлення; використовуйте стійку конфігурацію (`gateway.auth.password` або config `env`) під час установлення керованої служби.
-    - Якщо налаштовано і `gateway.auth.token`, і `gateway.auth.password`, а `gateway.auth.mode` не задано, установлення блокується, доки режим не буде задано явно.
+    - У режимі виведеної автентифікації лише shell-змінна `OPENCLAW_GATEWAY_PASSWORD` не послаблює вимоги до токена під час інсталяції; використовуйте стійку конфігурацію (`gateway.auth.password` або config `env`) під час інсталяції керованої служби.
+    - Якщо налаштовано і `gateway.auth.token`, і `gateway.auth.password`, а `gateway.auth.mode` не задано, інсталяцію буде заблоковано, доки режим не буде задано явно.
   </Accordion>
 </AccordionGroup>
 
-## Виявлення шлюзів (Bonjour)
+## Виявлення gateway (Bonjour)
 
 `gateway discover` сканує маяки Gateway (`_openclaw-gw._tcp`).
 
-- Multicast DNS-SD: `local.`
-- Unicast DNS-SD (Wide-Area Bonjour): виберіть домен (приклад: `openclaw.internal.`) і налаштуйте split DNS + DNS-сервер; див. [Bonjour](/uk/gateway/bonjour).
+- Багатоадресний DNS-SD: `local.`
+- Одноадресний DNS-SD (Wide-Area Bonjour): виберіть домен (приклад: `openclaw.internal.`) і налаштуйте split DNS + DNS-сервер; див. [Bonjour](/uk/gateway/bonjour).
 
-Лише шлюзи з увімкненим виявленням Bonjour (типово ввімкнено) оголошують маяк.
+Лише gateway з увімкненим виявленням Bonjour (типово ввімкнено) рекламують маяк.
 
 Записи виявлення Wide-Area містять (TXT):
 
 - `role` (підказка ролі gateway)
 - `transport` (підказка транспорту, наприклад `gateway`)
 - `gatewayPort` (порт WebSocket, зазвичай `18789`)
-- `sshPort` (необов’язково; клієнти за замовчуванням використовують для SSH-цілей `22`, якщо він відсутній)
+- `sshPort` (необов’язково; клієнти за замовчуванням використовують `22` для SSH-цілей, якщо його немає)
 - `tailnetDns` (ім’я хоста MagicDNS, якщо доступне)
 - `gatewayTls` / `gatewayTlsSha256` (TLS увімкнено + відбиток сертифіката)
-- `cliPath` (підказка віддаленого встановлення, записана до зони wide-area)
+- `cliPath` (підказка віддаленої інсталяції, записана в wide-area zone)
 
 ### `gateway discover`
 
@@ -504,10 +508,10 @@ openclaw gateway discover
 ```
 
 <ParamField path="--timeout <ms>" type="number" default="2000">
-  Тайм-аут на команду (browse/resolve).
+  Тайм-аут для кожної команди (browse/resolve).
 </ParamField>
 <ParamField path="--json" type="boolean">
-  Вивід для машинного читання (також вимикає стилізацію/spinner).
+  Машинозчитуваний вивід (також вимикає стилізацію/індикатор).
 </ParamField>
 
 Приклади:
@@ -518,12 +522,12 @@ openclaw gateway discover --json | jq '.beacons[].wsUrl'
 ```
 
 <Note>
-- CLI сканує `local.` плюс налаштований домен широкої зони, коли його увімкнено.
-- `wsUrl` у JSON-виводі виводиться з розв’язаного ендпоінта служби, а не з підказок лише TXT, таких як `lanHost` або `tailnetDns`.
-- У `local.` mDNS `sshPort` і `cliPath` транслюються лише коли `discovery.mdns.mode` має значення `full`. Wide-Area DNS-SD усе одно записує `cliPath`; `sshPort` там також залишається необов’язковим.
+- CLI сканує `local.` плюс налаштований wide-area domain, коли його увімкнено.
+- `wsUrl` у JSON-виводі виводиться з розв’язаного endpoint служби, а не з підказок лише з TXT, таких як `lanHost` або `tailnetDns`.
+- Для mDNS у `local.` `sshPort` і `cliPath` транслюються лише тоді, коли `discovery.mdns.mode` має значення `full`. Wide-area DNS-SD усе одно записує `cliPath`; `sshPort` там також залишається необов’язковим.
 </Note>
 
 ## Пов’язане
 
 - [Довідник CLI](/uk/cli)
-- [Операційний посібник Gateway](/uk/gateway)
+- [Runbook Gateway](/uk/gateway)

docs/uk/cli/migrate.md

@@ -0,0 +1,152 @@
+---
+read_when:
+    - Ви хочете мігрувати з Hermes або іншої агентної системи до OpenClaw
+    - Ви додаєте provider міграції, що належить Plugin
+summary: Довідник CLI для `openclaw migrate` (імпорт стану з іншої агентної системи)
+title: Міграція
+x-i18n:
+    generated_at: "2026-04-27T08:07:52Z"
+    model: gpt-5.4
+    provider: openai
+    source_hash: 8bb986558e2ce09e7fecbfc78beb149890965df8b6d82924cbfbcadb74b9f3c1
+    source_path: cli/migrate.md
+    workflow: 15
+---
+
+# `openclaw migrate`
+
+Імпортуйте стан з іншої агентної системи через provider міграції, що належить Plugin.
+
+<Tip>
+Щоб переглянути орієнтований на користувача покроковий посібник з переходу з Hermes, див. [Міграція з Hermes](/uk/install/migrating-hermes).
+</Tip>
+
+## Команди
+
+```bash
+openclaw migrate list
+openclaw migrate hermes --dry-run
+openclaw migrate hermes
+openclaw migrate apply hermes --yes
+openclaw migrate apply hermes --include-secrets --yes
+openclaw onboard --flow import
+openclaw onboard --import-from hermes --import-source ~/.hermes
+```
+
+<ParamField path="<provider>" type="string">
+  Назва зареєстрованого provider міграції, наприклад `hermes`. Запустіть `openclaw migrate list`, щоб побачити встановлені provider-и.
+</ParamField>
+<ParamField path="--dry-run" type="boolean">
+  Побудувати план і завершити роботу без зміни стану.
+</ParamField>
+<ParamField path="--from <path>" type="string">
+  Перевизначити каталог вихідного стану. Для Hermes типовим є `~/.hermes`.
+</ParamField>
+<ParamField path="--include-secrets" type="boolean">
+  Імпортувати підтримувані облікові дані. За замовчуванням вимкнено.
+</ParamField>
+<ParamField path="--overwrite" type="boolean">
+  Дозволити apply замінювати наявні цілі, коли план повідомляє про конфлікти.
+</ParamField>
+<ParamField path="--yes" type="boolean">
+  Пропустити запит на підтвердження. Обов’язково в неінтерактивному режимі.
+</ParamField>
+<ParamField path="--no-backup" type="boolean">
+  Пропустити резервне копіювання перед apply. Потребує `--force`, коли існує локальний стан OpenClaw.
+</ParamField>
+<ParamField path="--force" type="boolean">
+  Обов’язково разом із `--no-backup`, коли apply інакше відмовився б пропускати резервне копіювання.
+</ParamField>
+<ParamField path="--json" type="boolean">
+  Вивести план або результат apply у форматі JSON. Якщо вказано `--json` без `--yes`, apply виводить план і не змінює стан.
+</ParamField>
+
+## Модель безпеки
+
+`openclaw migrate` спочатку показує попередній перегляд.
+
+<AccordionGroup>
+  <Accordion title="Попередній перегляд перед apply">
+    Provider повертає деталізований план до внесення будь-яких змін, зокрема конфлікти, пропущені елементи та чутливі елементи. Плани JSON, вивід apply і звіти про міграцію маскують вкладені ключі, схожі на секрети, як-от API-ключі, токени, заголовки авторизації, cookies і паролі.
+
+    `openclaw migrate apply <provider>` показує попередній перегляд плану й запитує підтвердження перед зміною стану, якщо не вказано `--yes`. У неінтерактивному режимі apply потребує `--yes`.
+  </Accordion>
+  <Accordion title="Резервні копії">
+    Apply створює та перевіряє резервну копію OpenClaw перед застосуванням міграції. Якщо локального стану OpenClaw ще немає, крок резервного копіювання пропускається, і міграція може продовжитися. Щоб пропустити резервне копіювання, коли стан існує, передайте одночасно `--no-backup` і `--force`.
+  </Accordion>
+  <Accordion title="Конфлікти">
+    Apply відмовляється продовжувати, якщо в плані є конфлікти. Перегляньте план, а потім повторно запустіть із `--overwrite`, якщо заміна наявних цілей є навмисною. Provider-и все одно можуть записувати резервні копії окремих елементів для перезаписаних файлів у каталог звіту про міграцію.
+  </Accordion>
+  <Accordion title="Секрети">
+    Секрети ніколи не імпортуються за замовчуванням. Використовуйте `--include-secrets`, щоб імпортувати підтримувані облікові дані.
+  </Accordion>
+</AccordionGroup>
+
+## Provider Hermes
+
+Вбудований provider Hermes за замовчуванням виявляє стан у `~/.hermes`. Використовуйте `--from <path>`, якщо Hermes розташований в іншому місці.
+
+### Що імпортується
+
+- Типова конфігурація моделі з `config.yaml`.
+- Налаштовані provider-и моделей і користувацькі OpenAI-сумісні кінцеві точки з `providers` і `custom_providers`.
+- Визначення MCP-серверів з `mcp_servers` або `mcp.servers`.
+- `SOUL.md` і `AGENTS.md` у робочий простір агента OpenClaw.
+- `memories/MEMORY.md` і `memories/USER.md`, додані до файлів пам’яті робочого простору.
+- Типові налаштування пам’яті для файлової пам’яті OpenClaw, а також елементи архіву або ручної перевірки для зовнішніх provider-ів пам’яті, таких як Honcho.
+- Skills, які містять файл `SKILL.md` у `skills/<name>/`.
+- Значення конфігурації для кожного Skill з `skills.config`.
+- Підтримувані API-ключі з `.env`, лише з `--include-secrets`.
+
+### Підтримувані ключі `.env`
+
+`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `OPENROUTER_API_KEY`, `GOOGLE_API_KEY`, `GEMINI_API_KEY`, `GROQ_API_KEY`, `XAI_API_KEY`, `MISTRAL_API_KEY`, `DEEPSEEK_API_KEY`.
+
+### Стан лише для архіву
+
+Стан Hermes, який OpenClaw не може безпечно інтерпретувати, копіюється до звіту про міграцію для ручної перевірки, але не завантажується в активну конфігурацію чи облікові дані OpenClaw. Це дає змогу зберегти непрозорий або потенційно небезпечний стан без удавання, що OpenClaw може автоматично виконувати або довіряти йому:
+
+- `plugins/`
+- `sessions/`
+- `logs/`
+- `cron/`
+- `mcp-tokens/`
+- `auth.json`
+- `state.db`
+
+### Після застосування
+
+```bash
+openclaw doctor
+```
+
+## Контракт Plugin
+
+Джерела міграції — це plugins. Plugin оголошує ідентифікатори своїх provider-ів у `openclaw.plugin.json`:
+
+```json
+{
+  "contracts": {
+    "migrationProviders": ["hermes"]
+  }
+}
+```
+
+Під час виконання Plugin викликає `api.registerMigrationProvider(...)`. Provider реалізує `detect`, `plan` і `apply`. Core відповідає за оркестрацію CLI, політику резервного копіювання, запити підтвердження, вивід JSON і попередню перевірку конфліктів. Core передає перевірений план до `apply(ctx, plan)`, а provider-и можуть перебудовувати план лише тоді, коли цей аргумент відсутній, для сумісності.
+
+Plugins provider-ів можуть використовувати `openclaw/plugin-sdk/migration` для побудови елементів і підсумкових підрахунків, а також `openclaw/plugin-sdk/migration-runtime` для копіювання файлів з урахуванням конфліктів, копіювання звітів лише для архіву та звітів про міграцію.
+
+## Інтеграція з онбордингом
+
+Під час онбордингу можна запропонувати міграцію, коли provider виявляє відоме джерело. І `openclaw onboard --flow import`, і `openclaw setup --wizard --import-from hermes` використовують той самий plugin provider міграції та все одно показують попередній перегляд перед застосуванням.
+
+<Note>
+Імпорт під час онбордингу потребує свіжого налаштування OpenClaw. Спочатку скиньте конфігурацію, облікові дані, сесії та робочий простір, якщо у вас уже є локальний стан. Імпорт із резервним копіюванням і перезаписом або злиттям для наявних налаштувань доступний лише за feature gate.
+</Note>
+
+## Пов’язане
+
+- [Міграція з Hermes](/uk/install/migrating-hermes): орієнтований на користувача покроковий посібник.
+- [Міграція](/uk/install/migrating): переміщення OpenClaw на нову машину.
+- [Doctor](/uk/gateway/doctor): перевірка стану після застосування міграції.
+- [Plugins](/uk/tools/plugin): встановлення та реєстрація Plugin.

docs/uk/cli/onboard.md

@@ -1,38 +1,38 @@
 ---
 read_when:
-    - Ви хочете покрокове налаштування Gateway, робочого простору, автентифікації, каналів і Skills
-summary: Довідник CLI для `openclaw onboard` (інтерактивне початкове налаштування)
-title: Початкове налаштування
+    - Ви хочете покрокове налаштування для Gateway, робочого простору, автентифікації, каналів і Skills
+summary: Довідник CLI для `openclaw onboard` (інтерактивне налаштування)
+title: Налаштування
 x-i18n:
-    generated_at: "2026-04-27T04:37:17Z"
+    generated_at: "2026-04-27T08:07:54Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 98985c119f64ba41ed1a74fbb0bf1feb78b3c5daa4844e66f3aa1ae73ef6d0f5
+    source_hash: 041063bce6616ed32225cb411f385dcbfd750c0bb2779ec17bc58e1aa9ada254
     source_path: cli/onboard.md
     workflow: 15
 ---
 
 # `openclaw onboard`
 
-Інтерактивне початкове налаштування для локального або віддаленого налаштування Gateway.
+Інтерактивне налаштування для локальної або віддаленої конфігурації Gateway.
 
 ## Пов’язані посібники
 
 <CardGroup cols={2}>
-  <Card title="Центр CLI для початкового налаштування" href="/uk/start/wizard" icon="rocket">
-    Покроковий огляд інтерактивного процесу в CLI.
+  <Card title="Центр налаштування CLI" href="/uk/start/wizard" icon="rocket">
+    Покроковий огляд інтерактивного процесу CLI.
   </Card>
-  <Card title="Огляд початкового налаштування" href="/uk/start/onboarding-overview" icon="map">
-    Як організовано початкове налаштування OpenClaw.
+  <Card title="Огляд налаштування" href="/uk/start/onboarding-overview" icon="map">
+    Як поєднуються етапи налаштування OpenClaw.
   </Card>
-  <Card title="Довідник налаштування CLI" href="/uk/start/wizard-cli-reference" icon="book">
-    Вивід, внутрішня логіка та поведінка на кожному кроці.
+  <Card title="Довідник із налаштування CLI" href="/uk/start/wizard-cli-reference" icon="book">
+    Виводи, внутрішня логіка та поведінка на кожному кроці.
   </Card>
   <Card title="Автоматизація CLI" href="/uk/start/wizard-cli-automation" icon="terminal">
-    Неінтерактивні прапорці та налаштування через сценарії.
+    Неінтерактивні прапорці та сценарії налаштування.
   </Card>
-  <Card title="Початкове налаштування застосунку macOS" href="/uk/start/onboarding" icon="apple">
-    Процес початкового налаштування для застосунку macOS у рядку меню.
+  <Card title="Налаштування програми macOS" href="/uk/start/onboarding" icon="apple">
+    Процес налаштування для програми macOS у рядку меню.
   </Card>
 </CardGroup>
 
@@ -43,19 +43,23 @@ openclaw onboard
 openclaw onboard --modern
 openclaw onboard --flow quickstart
 openclaw onboard --flow manual
+openclaw onboard --flow import
+openclaw onboard --import-from hermes --import-source ~/.hermes
 openclaw onboard --skip-bootstrap
 openclaw onboard --mode remote --remote-url wss://gateway-host:18789
 ```
 
-`--modern` запускає попередній перегляд розмовного початкового налаштування Crestodian. Без
-`--modern` команда `openclaw onboard` використовує класичний процес початкового налаштування.
+`--flow import` використовує провайдери міграції, що належать Plugin, як-от Hermes. Він запускається лише для нової конфігурації OpenClaw; якщо вже існують файли конфігурації, облікові дані, сесії або файли пам’яті/ідентичності робочого простору, перед імпортом виконайте скидання або виберіть нове налаштування.
+
+`--modern` запускає попередню версію розмовного налаштування Crestodian. Без
+`--modern` команда `openclaw onboard` використовує класичний процес налаштування.
 
 Для цілей `ws://` у приватній мережі без шифрування (лише для довірених мереж) установіть
-`OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` у середовищі процесу початкового налаштування.
-Еквівалента `openclaw.json` для цього аварійного обходу клієнтського транспорту
-немає.
+`OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1` у середовищі процесу налаштування.
+Еквівалента в `openclaw.json` для цього аварійного клієнтського
+обходу транспортного захисту немає.
 
-Неінтерактивний власний провайдер:
+Неінтерактивний користувацький провайдер:
 
 ```bash
 openclaw onboard --non-interactive \
@@ -67,7 +71,7 @@ openclaw onboard --non-interactive \
   --custom-compatibility openai
 ```
 
-`--custom-api-key` є необов’язковим у неінтерактивному режимі. Якщо його не вказано, початкове налаштування перевіряє `CUSTOM_API_KEY`.
+`--custom-api-key` є необов’язковим у неінтерактивному режимі. Якщо його не вказано, налаштування перевіряє `CUSTOM_API_KEY`.
 
 LM Studio також підтримує прапорець ключа, специфічний для провайдера, у неінтерактивному режимі:
 
@@ -90,9 +94,9 @@ openclaw onboard --non-interactive \
   --accept-risk
 ```
 
-`--custom-base-url` типово має значення `http://127.0.0.1:11434`. `--custom-model-id` є необов’язковим; якщо його не вказано, початкове налаштування використовує рекомендовані типові значення Ollama. Ідентифікатори хмарних моделей, як-от `kimi-k2.5:cloud`, також тут працюють.
+`--custom-base-url` типово має значення `http://127.0.0.1:11434`. `--custom-model-id` є необов’язковим; якщо його не вказано, налаштування використовує рекомендовані типові значення Ollama. Ідентифікатори хмарних моделей, як-от `kimi-k2.5:cloud`, тут також працюють.
 
-Зберігайте ключі провайдера як посилання, а не як відкритий текст:
+Зберігайте ключі провайдера як посилання, а не у відкритому вигляді:
 
 ```bash
 openclaw onboard --non-interactive \
@@ -101,26 +105,26 @@ openclaw onboard --non-interactive \
   --accept-risk
 ```
 
-З `--secret-input-mode ref` початкове налаштування записує посилання, підкріплені змінними середовища, замість значень ключів у відкритому тексті.
-Для провайдерів на основі auth-profile це записує записи `keyRef`; для власних провайдерів це записує `models.providers.<id>.apiKey` як посилання env (наприклад, `{ source: "env", provider: "default", id: "CUSTOM_API_KEY" }`).
+З `--secret-input-mode ref` налаштування записує посилання, що використовують змінні середовища, замість значень ключів у відкритому вигляді.
+Для провайдерів на основі auth-profile це записує записи `keyRef`; для користувацьких провайдерів це записує `models.providers.<id>.apiKey` як env ref (наприклад, `{ source: "env", provider: "default", id: "CUSTOM_API_KEY" }`).
 
-Контракт неінтерактивного режиму `ref`:
+Умови неінтерактивного режиму `ref`:
 
-- Установіть змінну середовища провайдера в середовищі процесу початкового налаштування (наприклад, `OPENAI_API_KEY`).
+- Установіть змінну середовища провайдера в середовищі процесу налаштування (наприклад, `OPENAI_API_KEY`).
 - Не передавайте вбудовані прапорці ключів (наприклад, `--openai-api-key`), якщо цю змінну середовища також не встановлено.
-- Якщо вбудований прапорець ключа передано без обов’язкової змінної середовища, початкове налаштування негайно завершується з помилкою та підказкою.
+- Якщо вбудований прапорець ключа передано без потрібної змінної середовища, налаштування негайно завершується з підказками.
 
 Параметри токена Gateway у неінтерактивному режимі:
 
-- `--gateway-auth token --gateway-token <token>` зберігає токен у відкритому тексті.
+- `--gateway-auth token --gateway-token <token>` зберігає токен у відкритому вигляді.
 - `--gateway-auth token --gateway-token-ref-env <name>` зберігає `gateway.auth.token` як env SecretRef.
 - `--gateway-token` і `--gateway-token-ref-env` є взаємовиключними.
-- `--gateway-token-ref-env` потребує непорожньої змінної середовища в середовищі процесу початкового налаштування.
-- З `--install-daemon`, коли автентифікація токеном потребує токен, токени Gateway під керуванням SecretRef проходять перевірку, але не зберігаються як розв’язаний відкритий текст у метаданих середовища служби супервізора.
-- З `--install-daemon`, якщо режим токена потребує токен, а налаштований SecretRef токена не розв’язується, початкове налаштування завершується за принципом fail closed з інструкціями щодо усунення проблеми.
-- З `--install-daemon`, якщо налаштовано і `gateway.auth.token`, і `gateway.auth.password`, але `gateway.auth.mode` не задано, початкове налаштування блокує інсталяцію, доки режим не буде явно встановлено.
-- Локальне початкове налаштування записує `gateway.mode="local"` у конфігурацію. Якщо в пізнішому файлі конфігурації відсутній `gateway.mode`, вважайте це пошкодженням конфігурації або неповним ручним редагуванням, а не коректним скороченням для локального режиму.
-- `--allow-unconfigured` — це окремий аварійний обхід для середовища виконання Gateway. Це не означає, що під час початкового налаштування можна пропустити `gateway.mode`.
+- `--gateway-token-ref-env` потребує непорожньої змінної середовища в середовищі процесу налаштування.
+- Із `--install-daemon`, коли автентифікація токеном вимагає токен, токени Gateway під керуванням SecretRef перевіряються, але не зберігаються як розв’язаний відкритий текст у метаданих середовища служби supervisor.
+- Із `--install-daemon`, якщо режим токена вимагає токен, а налаштований токен SecretRef не розв’язується, налаштування блокує виконання з підказками щодо усунення проблеми.
+- Із `--install-daemon`, якщо налаштовано і `gateway.auth.token`, і `gateway.auth.password`, але `gateway.auth.mode` не задано, налаштування блокує встановлення, доки режим не буде вказано явно.
+- Локальне налаштування записує `gateway.mode="local"` у конфігурацію. Якщо в пізнішому файлі конфігурації бракує `gateway.mode`, вважайте це пошкодженням конфігурації або неповним ручним редагуванням, а не коректним скороченням для локального режиму.
+- `--allow-unconfigured` — це окремий аварійний механізм середовища виконання Gateway. Це не означає, що під час налаштування можна пропустити `gateway.mode`.
 
 Приклад:
 
@@ -136,22 +140,22 @@ openclaw onboard --non-interactive \
 
 Стан локального Gateway у неінтерактивному режимі:
 
-- Якщо не передано `--skip-health`, початкове налаштування чекає, доки локальний Gateway стане доступним, перш ніж успішно завершитися.
-- `--install-daemon` спочатку запускає керований шлях інсталяції Gateway. Без нього у вас уже має працювати локальний Gateway, наприклад `openclaw gateway run`.
+- Якщо ви не передасте `--skip-health`, налаштування чекатиме доступності локального Gateway перед успішним завершенням.
+- `--install-daemon` спочатку запускає шлях установленого керованого Gateway. Без нього локальний Gateway уже має працювати, наприклад через `openclaw gateway run`.
 - Якщо в автоматизації вам потрібні лише записи конфігурації/робочого простору/bootstrap, використовуйте `--skip-health`.
-- Якщо ви самі керуєте файлами робочого простору, передайте `--skip-bootstrap`, щоб установити `agents.defaults.skipBootstrap: true` і пропустити створення `AGENTS.md`, `SOUL.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` і `BOOTSTRAP.md`.
-- У нативному Windows `--install-daemon` спочатку намагається використати Scheduled Tasks і переходить до елемента входу в систему в папці Startup для поточного користувача, якщо створення завдання заборонено.
+- Якщо ви самостійно керуєте файлами робочого простору, передайте `--skip-bootstrap`, щоб установити `agents.defaults.skipBootstrap: true` і пропустити створення `AGENTS.md`, `SOUL.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` і `BOOTSTRAP.md`.
+- У рідному Windows `--install-daemon` спочатку пробує Scheduled Tasks, а якщо створення завдання заборонено — переходить до елемента входу в систему для поточного користувача в папці Startup.
 
-Поведінка інтерактивного початкового налаштування в режимі посилань:
+Поведінка інтерактивного налаштування з режимом посилань:
 
 - Коли з’явиться запит, виберіть **Use secret reference**.
 - Потім виберіть один із варіантів:
   - Змінна середовища
   - Налаштований провайдер секретів (`file` або `exec`)
-- Початкове налаштування виконує швидку попередню перевірку перед збереженням посилання.
-  - Якщо перевірка не пройде, початкове налаштування покаже помилку й дозволить повторити спробу.
+- Перед збереженням посилання налаштування виконує швидку попередню перевірку.
+  - Якщо перевірка не проходить, налаштування покаже помилку й дозволить повторити спробу.
 
-### Варіанти кінцевих точок Z.AI у неінтерактивному режимі
+### Неінтерактивні варіанти кінцевих точок Z.AI
 
 <Note>
 `--auth-choice zai-api-key` автоматично визначає найкращу кінцеву точку Z.AI для вашого ключа (надає перевагу загальному API з `zai/glm-5.1`). Якщо вам потрібні саме кінцеві точки GLM Coding Plan, виберіть `zai-coding-global` або `zai-coding-cn`.
@@ -181,26 +185,28 @@ openclaw onboard --non-interactive \
 
 <AccordionGroup>
   <Accordion title="Типи процесів">
-    - `quickstart`: мінімум запитів, автоматично генерує токен Gateway.
-    - `manual`: повні запити для порту, bind і автентифікації (псевдонім для `advanced`).
+    - `quickstart`: мінімум запитів, автоматично створює токен Gateway.
+    - `manual`: повні запити для порту, прив’язки та автентифікації (псевдонім для `advanced`).
+    - `import`: запускає виявлений провайдер міграції, показує попередній план, а потім застосовує його після підтвердження.
   </Accordion>
   <Accordion title="Попередня фільтрація провайдерів">
-    Коли вибір автентифікації передбачає бажаного провайдера, початкове налаштування попередньо фільтрує засоби вибору моделі за замовчуванням і allowlist до цього провайдера. Для Volcengine і BytePlus це також охоплює варіанти coding-plan (`volcengine-plan/*`, `byteplus-plan/*`).
+    Коли варіант автентифікації передбачає бажаного провайдера, налаштування попередньо фільтрує засоби вибору типової моделі та списку дозволених моделей до цього провайдера. Для Volcengine і BytePlus це також охоплює варіанти coding-plan (`volcengine-plan/*`, `byteplus-plan/*`).
 
-    Якщо фільтр бажаного провайдера ще не дає жодної завантаженої моделі, початкове налаштування повертається до нефільтрованого каталогу замість того, щоб залишати засіб вибору порожнім.
+    Якщо фільтр бажаного провайдера ще не дає жодної завантаженої моделі, налаштування повертається до нефільтрованого каталогу, а не залишає засіб вибору порожнім.
 
   </Accordion>
   <Accordion title="Додаткові запити для вебпошуку">
     Деякі провайдери вебпошуку запускають додаткові запити, специфічні для провайдера:
 
     - **Grok** може запропонувати необов’язкове налаштування `x_search` з тим самим `XAI_API_KEY` і вибором моделі `x_search`.
-    - **Kimi** може запитати регіон Moonshot API (`api.moonshot.ai` чи `api.moonshot.cn`) і модель вебпошуку Kimi за замовчуванням.
+    - **Kimi** може запитати регіон Moonshot API (`api.moonshot.ai` чи `api.moonshot.cn`) і типову модель вебпошуку Kimi.
 
   </Accordion>
-  <Accordion title="Інші особливості">
-    - Поведінка області DM під час локального початкового налаштування: [Довідник налаштування CLI](/uk/start/wizard-cli-reference#outputs-and-internals).
-    - Найшвидший спосіб почати перший чат: `openclaw dashboard` (Control UI, без налаштування каналів).
-    - Власний провайдер: підключення до будь-якої сумісної кінцевої точки OpenAI або Anthropic, зокрема розміщених провайдерів, яких немає в списку. Використовуйте Unknown для автоматичного визначення.
+  <Accordion title="Інша поведінка">
+    - Поведінка області DM під час локального налаштування: [Довідник із налаштування CLI](/uk/start/wizard-cli-reference#outputs-and-internals).
+    - Найшвидший шлях до першого чату: `openclaw dashboard` (Control UI, без налаштування каналу).
+    - Користувацький провайдер: підключайте будь-яку кінцеву точку, сумісну з OpenAI або Anthropic, включно з розміщеними провайдерами, яких немає в списку. Використовуйте Unknown для автоматичного визначення.
+    - Якщо виявлено стан Hermes, налаштування запропонує процес міграції. Використовуйте [Migrate](/uk/cli/migrate) для планів dry-run, режиму перезапису, звітів і точних відповідностей.
   </Accordion>
 </AccordionGroup>
 

docs/uk/cli/setup.md

@@ -2,22 +2,22 @@
 read_when:
     - Ви виконуєте початкове налаштування без повного онбордингу CLI
     - Ви хочете встановити типовий шлях до робочого простору
-summary: Довідка CLI для `openclaw setup` (ініціалізація конфігурації + робочого простору)
+summary: Довідник CLI для `openclaw setup` (ініціалізація конфігурації та робочого простору)
 title: Налаштування
 x-i18n:
-    generated_at: "2026-04-24T04:12:58Z"
+    generated_at: "2026-04-27T08:07:52Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 650b0faf99ef1bc24ec6514661093a9a2ba7edead2e2622b863d51553c44f267
+    source_hash: 68e5c07a6b1769420c2125677f3eda9bd4841c938b4fc62583c5bed2a2596250
     source_path: cli/setup.md
     workflow: 15
 ---
 
 # `openclaw setup`
 
-Ініціалізуйте `~/.openclaw/openclaw.json` і робочий простір агента.
+Ініціалізує `~/.openclaw/openclaw.json` і робочий простір агента.
 
-Пов’язане:
+Пов’язано:
 
 - Початок роботи: [Початок роботи](/uk/start/getting-started)
 - Онбординг CLI: [Онбординг (CLI)](/uk/start/wizard)
@@ -28,6 +28,7 @@ x-i18n:
 openclaw setup
 openclaw setup --workspace ~/.openclaw/workspace
 openclaw setup --wizard
+openclaw setup --wizard --import-from hermes --import-source ~/.hermes
 openclaw setup --non-interactive --mode remote --remote-url wss://gateway-host:18789 --remote-token <token>
 ```
 
@@ -37,6 +38,9 @@ openclaw setup --non-interactive --mode remote --remote-url wss://gateway-host:1
 - `--wizard`: запустити онбординг
 - `--non-interactive`: запустити онбординг без запитів
 - `--mode <local|remote>`: режим онбордингу
+- `--import-from <provider>`: провайдер міграції, який слід запустити під час онбордингу
+- `--import-source <path>`: вихідний домашній каталог агента для `--import-from`
+- `--import-secrets`: імпортувати підтримувані секрети під час міграції в онбордингу
 - `--remote-url <url>`: URL WebSocket віддаленого Gateway
 - `--remote-token <token>`: токен віддаленого Gateway
 
@@ -48,10 +52,11 @@ openclaw setup --wizard
 
 Примітки:
 
-- Звичайний `openclaw setup` ініціалізує конфігурацію + робочий простір без повного потоку онбордингу.
-- Онбординг запускається автоматично, коли присутні будь-які прапорці онбордингу (`--wizard`, `--non-interactive`, `--mode`, `--remote-url`, `--remote-token`).
+- Звичайний `openclaw setup` ініціалізує конфігурацію та робочий простір без повного процесу онбордингу.
+- Онбординг запускається автоматично, якщо присутні будь-які прапорці онбордингу (`--wizard`, `--non-interactive`, `--mode`, `--import-from`, `--import-source`, `--import-secrets`, `--remote-url`, `--remote-token`).
+- Якщо виявлено стан Hermes, інтерактивний онбординг може автоматично запропонувати міграцію. Онбординг імпорту потребує нового налаштування; використовуйте [Міграція](/uk/cli/migrate) для планів dry-run, резервних копій і режиму перезапису поза межами онбордингу.
 
-## Пов’язане
+## Пов’язано
 
-- [Довідка CLI](/uk/cli)
+- [Довідник CLI](/uk/cli)
 - [Огляд встановлення](/uk/install)

docs/uk/gateway/local-models.md

@@ -1,26 +1,26 @@
 ---
 read_when:
-    - Ви хочете обслуговувати моделі зі свого власного GPU-сервера
-    - Ви налаштовуєте LM Studio або сумісний з OpenAI proxy
-    - Вам потрібні найбезпечніші рекомендації щодо локальних моделей
-summary: Запуск OpenClaw на локальних LLM (LM Studio, vLLM, LiteLLM, користувацькі OpenAI endpoint-и)
+    - Ви хочете обслуговувати моделі з власного GPU-сервера
+    - Ви налаштовуєте LM Studio або проксі, сумісний з OpenAI
+    - Вам потрібні найнадійніші рекомендації щодо локальних моделей
+summary: Запустіть OpenClaw на локальних LLM (LM Studio, vLLM, LiteLLM, власні кінцеві точки OpenAI)
 title: Локальні моделі
 x-i18n:
-    generated_at: "2026-04-27T06:25:14Z"
+    generated_at: "2026-04-27T08:07:53Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 1fe9f5f7e3fc4f5660769fddef1f524b303d309f77551880cd74f3395286816c
+    source_hash: 4a42076e542448018eaf8633c18dfd290c822be502d78a135d03d138e9713668
     source_path: gateway/local-models.md
     workflow: 15
 ---
 
-Локальний запуск можливий, але OpenClaw очікує великий контекст і сильний захист від prompt injection. Невеликі карти обрізають контекст і послаблюють безпеку. Орієнтуйтеся на високий рівень: **≥2 повністю укомплектовані Mac Studio або еквівалентний GPU-стенд (~$30k+)**. Одна GPU на **24 GB** підходить лише для легших промптів із вищою затримкою. Використовуйте **найбільший / повнорозмірний варіант моделі, який ви можете запустити**; агресивно квантизовані або «малі» checkpoints підвищують ризик prompt injection (див. [Безпека](/uk/gateway/security)).
+Локальний запуск можливий, але OpenClaw очікує великий контекст + сильний захист від інʼєкцій у підказки. Малі карти обрізають контекст і послаблюють безпеку. Орієнтуйтеся на високий рівень: **≥2 Mac Studio з максимальною конфігурацією або еквівалентна GPU-установка (~$30k+)**. Одна GPU на **24 GB** підходить лише для легших підказок із вищою затримкою. Використовуйте **найбільший / повнорозмірний варіант моделі, який можете запустити**; агресивно квантизовані або “small” чекпойнти підвищують ризик інʼєкцій у підказки (див. [Security](/uk/gateway/security)).
 
-Якщо вам потрібне найпростіше локальне налаштування, почніть із [LM Studio](/uk/providers/lmstudio) або [Ollama](/uk/providers/ollama) та `openclaw onboard`. Ця сторінка — практичний посібник для потужніших локальних стеків і користувацьких локальних серверів, сумісних з OpenAI.
+Якщо вам потрібне локальне налаштування з найменшими труднощами, почніть із [LM Studio](/uk/providers/lmstudio) або [Ollama](/uk/providers/ollama) і `openclaw onboard`. Ця сторінка — це практичний посібник для продуктивніших локальних стеків і власних локальних серверів, сумісних з OpenAI.
 
 ## Рекомендовано: LM Studio + велика локальна модель (Responses API)
 
-Найкращий поточний локальний стек. Завантажте велику модель у LM Studio (наприклад, повнорозмірну збірку Qwen, DeepSeek або Llama), увімкніть локальний сервер (типово `http://127.0.0.1:1234`) і використовуйте Responses API, щоб тримати міркування окремо від фінального тексту.
+Найкращий поточний локальний стек. Завантажте велику модель у LM Studio (наприклад, повнорозмірну збірку Qwen, DeepSeek або Llama), увімкніть локальний сервер (типово `http://127.0.0.1:1234`) і використовуйте Responses API, щоб відокремити міркування від фінального тексту.
 
 ```json5
 {
@@ -60,15 +60,15 @@ x-i18n:
 **Контрольний список налаштування**
 
 - Встановіть LM Studio: [https://lmstudio.ai](https://lmstudio.ai)
-- У LM Studio завантажте **найбільшу доступну збірку моделі** (уникайте «малих»/сильно квантизованих варіантів), запустіть сервер, переконайтеся, що `http://127.0.0.1:1234/v1/models` показує її.
-- Замініть `my-local-model` на фактичний ID моделі, показаний у LM Studio.
+- У LM Studio завантажте **найбільшу доступну збірку моделі** (уникайте варіантів “small” / сильно квантизованих), запустіть сервер, переконайтеся, що `http://127.0.0.1:1234/v1/models` її показує.
+- Замініть `my-local-model` на фактичний ідентифікатор моделі, показаний у LM Studio.
 - Тримайте модель завантаженою; холодне завантаження додає затримку запуску.
 - Скоригуйте `contextWindow`/`maxTokens`, якщо ваша збірка LM Studio відрізняється.
 - Для WhatsApp дотримуйтеся Responses API, щоб надсилався лише фінальний текст.
 
-Тримайте хостингові моделі налаштованими навіть під час локального запуску; використовуйте `models.mode: "merge"`, щоб запасні варіанти лишалися доступними.
+Навіть під час локального запуску залишайте налаштованими хостовані моделі; використовуйте `models.mode: "merge"`, щоб резервні варіанти залишалися доступними.
 
-### Гібридна конфігурація: хостингова primary, локальна fallback
+### Гібридна конфігурація: хостована основна модель, локальна резервна
 
 ```json5
 {
@@ -109,18 +109,18 @@ x-i18n:
 }
 ```
 
-### Спочатку локально, із хостинговою страховкою
+### Спочатку локально, із хостованим запасним варіантом
 
-Поміняйте місцями порядок primary і fallback; залиште той самий блок providers і `models.mode: "merge"`, щоб можна було перейти на Sonnet або Opus, коли локальний сервер недоступний.
+Поміняйте місцями основну модель і порядок резервних; залиште той самий блок providers і `models.mode: "merge"`, щоб мати змогу переключитися на Sonnet або Opus, коли локальний сервер недоступний.
 
 ### Регіональний хостинг / маршрутизація даних
 
-- Хостингові варіанти MiniMax/Kimi/GLM також існують в OpenRouter з endpoint-ами, прив’язаними до регіону (наприклад, розміщеними в США). Виберіть там регіональний варіант, щоб зберігати трафік у вибраній юрисдикції, і водночас використовуйте `models.mode: "merge"` для fallback на Anthropic/OpenAI.
-- Повністю локальний режим лишається найсильнішим варіантом приватності; регіональна хостингова маршрутизація — це компроміс, коли вам потрібні можливості провайдера, але ви хочете контролювати потік даних.
+- Хостовані варіанти MiniMax/Kimi/GLM також доступні в OpenRouter з кінцевими точками, прив’язаними до регіону (наприклад, хостинг у США). Виберіть там регіональний варіант, щоб трафік залишався у вибраній вами юрисдикції, і водночас використовуйте `models.mode: "merge"` для резервних варіантів Anthropic/OpenAI.
+- Лише локальний запуск залишається найсильнішим варіантом щодо приватності; регіональна маршрутизація при хостингу — це компромісний варіант, коли вам потрібні можливості провайдера, але ви хочете контролювати потік даних.
 
-## Інші локальні proxy, сумісні з OpenAI
+## Інші локальні проксі, сумісні з OpenAI
 
-vLLM, LiteLLM, OAI-proxy або користувацькі Gateway працюють, якщо вони надають endpoint `/v1` у стилі OpenAI. Замініть блок provider вище на свій endpoint та ID моделі:
+vLLM, LiteLLM, OAI-proxy або власні шлюзи працюють, якщо вони надають кінцеву точку `/v1` у стилі OpenAI. Замініть блок provider вище на свою кінцеву точку та ідентифікатор моделі:
 
 ```json5
 {
@@ -149,33 +149,37 @@ vLLM, LiteLLM, OAI-proxy або користувацькі Gateway працюю
 }
 ```
 
-Залишайте `models.mode: "merge"`, щоб хостингові моделі лишалися доступними як fallback.
-Використовуйте `models.providers.<id>.timeoutSeconds` для повільних локальних або віддалених серверів моделей перед тим, як збільшувати `agents.defaults.timeoutSeconds`. Таймаут provider застосовується лише до HTTP-запитів до моделі, включно з підключенням, заголовками, потоковою передачею тіла й загальним abort у guarded-fetch.
+Залишайте `models.mode: "merge"`, щоб хостовані моделі були доступні як резервні.
+Використовуйте `models.providers.<id>.timeoutSeconds` для повільних локальних або віддалених серверів моделей, перш ніж збільшувати `agents.defaults.timeoutSeconds`. Тайм-аут провайдера застосовується лише до HTTP-запитів до моделей, включно зі зʼєднанням, заголовками, потоковою передачею тіла відповіді та загальним перериванням guarded-fetch.
 
-Примітка щодо поведінки локальних/proxy `/v1` backend-ів:
+Примітка щодо поведінки для локальних / проксійованих бекендів `/v1`:
 
-- OpenClaw обробляє їх як proxy-маршрути, сумісні з OpenAI, а не як нативні endpoint-и OpenAI
-- нативне формування запитів лише для OpenAI тут не застосовується: без `service_tier`, без Responses `store`, без формування payload для сумісності reasoning OpenAI і без підказок prompt-cache
-- приховані заголовки атрибуції OpenClaw (`originator`, `version`, `User-Agent`) не додаються до цих користувацьких proxy URL
+- OpenClaw розглядає їх як проксі-маршрути, сумісні з OpenAI, а не як нативні кінцеві точки OpenAI
+- формування запитів, яке застосовується лише до нативного OpenAI, тут не використовується: немає `service_tier`, немає `store` для Responses, немає формування payload для сумісності міркування OpenAI і немає підказок для кешу підказок
+- приховані службові заголовки OpenClaw (`originator`, `version`, `User-Agent`) не додаються до цих користувацьких URL проксі
 
-Примітки щодо сумісності для суворіших backend-ів, сумісних з OpenAI:
+Примітки щодо сумісності для суворіших бекендів, сумісних з OpenAI:
 
-- Деякі сервери приймають у Chat Completions лише рядковий `messages[].content`, а не структуровані масиви частин контенту. Для таких endpoint-ів установіть `models.providers.<provider>.models[].compat.requiresStringContent: true`.
-- Деякі менші або суворіші локальні backend-и нестабільні з повною формою промпта runtime агента OpenClaw, особливо коли включено схеми інструментів. Якщо backend працює для крихітних прямих викликів `/v1/chat/completions`, але не проходить на звичайних ходах агента OpenClaw, спочатку спробуйте `agents.defaults.experimental.localModelLean: true`, щоб прибрати важкі типові інструменти, як-от `browser`, `cron` і `message`; це експериментальний прапорець, а не стабільне типове налаштування режиму. Див. [Експериментальні можливості](/uk/concepts/experimental-features). Якщо це не допоможе, спробуйте `models.providers.<provider>.models[].compat.supportsTools: false`.
-- Якщо backend усе ще не працює лише на більших запусках OpenClaw, то решта проблеми зазвичай полягає у потужності моделі/сервера на боці upstream або в помилці backend-а, а не в транспортному шарі OpenClaw.
+- Деякі сервери приймають у Chat Completions лише рядковий `messages[].content`, а не структуровані масиви частин контенту. Для таких кінцевих точок установіть `models.providers.<provider>.models[].compat.requiresStringContent: true`.
+- Деякі локальні моделі виводять окремі запити до інструментів у дужках як текст, наприклад `[tool_name]`, далі JSON і `[END_TOOL_REQUEST]`. OpenClaw перетворює їх на справжні виклики інструментів лише тоді, коли назва точно збігається з зареєстрованим інструментом для цього ходу; інакше блок вважається непідтримуваним текстом і приховується з видимих для користувача відповідей.
+- Деякі менші або суворіші локальні бекенди нестабільно працюють із повною формою підказки runtime агента OpenClaw, особливо коли включені схеми інструментів. Якщо бекенд працює для крихітних прямих викликів `/v1/chat/completions`, але не працює у звичайних ходах агента OpenClaw, спочатку спробуйте `agents.defaults.experimental.localModelLean: true`, щоб прибрати важкі типові інструменти на кшталт `browser`, `cron` і `message`; це експериментальний прапорець, а не стабільне налаштування режиму за замовчуванням. Див. [Experimental Features](/uk/concepts/experimental-features). Якщо це не допоможе, спробуйте `models.providers.<provider>.models[].compat.supportsTools: false`.
+- Якщо бекенд усе ще не працює лише на більших запусках OpenClaw, то проблема зазвичай полягає у можливостях моделі/сервера на боці апстриму або в помилці бекенда, а не в транспортному шарі OpenClaw.
 
-## Усунення несправностей
+## Усунення проблем
 
-- Gateway може дістатися до proxy? `curl http://127.0.0.1:1234/v1/models`.
-- Модель LM Studio вивантажена? Завантажте знову; холодний старт — поширена причина «зависання».
-- OpenClaw попереджає, коли виявлене вікно контексту менше за **32k**, і блокує роботу нижче **16k**. Якщо ви натрапили на цей preflight, збільште ліміт контексту сервера/моделі або виберіть більшу модель.
-- Помилки контексту? Зменште `contextWindow` або збільште ліміт вашого сервера.
+- Gateway може дістатися до проксі? `curl http://127.0.0.1:1234/v1/models`.
+- Модель LM Studio вивантажена? Завантажте її знову; холодний старт — часта причина “зависання”.
+- OpenClaw попереджає, коли виявлене вікно контексту менше за **32k**, і блокує запуск, якщо воно менше за **16k**. Якщо ви впираєтеся в цю попередню перевірку, збільште ліміт контексту сервера/моделі або виберіть більшу модель.
+- Помилки контексту? Зменште `contextWindow` або збільшіть ліміт сервера.
 - Сервер, сумісний з OpenAI, повертає `messages[].content ... expected a string`?
-  Додайте `compat.requiresStringContent: true` у запис цієї моделі.
-- Прямі маленькі виклики `/v1/chat/completions` працюють, але `openclaw infer model run` падає на Gemma або іншій локальній моделі? Спочатку вимкніть схеми інструментів через `compat.supportsTools: false`, а потім перевірте знову. Якщо сервер усе ще падає лише на більших промптах OpenClaw, вважайте це обмеженням моделі/сервера на боці upstream.
-- Безпека: локальні моделі обходять фільтри провайдера; тримайте агентів вузькоспрямованими, а Compaction увімкненим, щоб обмежити радіус ураження prompt injection.
+  Додайте `compat.requiresStringContent: true` до цього запису моделі.
+- Прямі крихітні виклики `/v1/chat/completions` працюють, але `openclaw infer model run`
+  не працює на Gemma або іншій локальній моделі? Спочатку вимкніть схеми інструментів через
+  `compat.supportsTools: false`, а потім перевірте знову. Якщо сервер і далі аварійно завершується лише
+  на більших підказках OpenClaw, вважайте це обмеженням сервера/моделі на боці апстриму.
+- Безпека: локальні моделі оминають фільтри на боці провайдера; звужуйте агентів і тримайте увімкненим Compaction, щоб обмежити радіус ураження від інʼєкцій у підказки.
 
 ## Пов’язане
 
 - [Довідник із конфігурації](/uk/gateway/configuration-reference)
-- [Перемикання моделей при збої](/uk/concepts/model-failover)
+- [Відмовостійкість моделей](/uk/concepts/model-failover)

docs/uk/install/docker.md

@@ -1,46 +1,46 @@
 ---
 read_when:
-    - Вам потрібен контейнеризований Gateway замість локальних установок
+    - Ви хочете контейнеризований Gateway замість локальних встановлень
     - Ви перевіряєте потік Docker
-summary: Необов’язкове налаштування та онбординг OpenClaw на основі Docker
+summary: Необов’язкове налаштування та початок роботи з OpenClaw на основі Docker
 title: Docker
 x-i18n:
-    generated_at: "2026-04-27T07:08:09Z"
+    generated_at: "2026-04-27T08:07:53Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 56766c90b2751d186b0e9a7b55241fb45f05a37c2e8d7c0d0155b41eefc2177a
+    source_hash: 434d11db92060c20902db626f48e79077d24446450dd186af820c0a08a773c47
     source_path: install/docker.md
     workflow: 15
 ---
 
-Docker **необов’язковий**. Використовуйте його лише якщо вам потрібен контейнеризований Gateway або ви хочете перевірити потік Docker.
+Docker **необов’язковий**. Використовуйте його лише якщо вам потрібен контейнеризований Gateway або якщо ви хочете перевірити потік Docker.
 
 ## Чи підходить мені Docker?
 
-- **Так**: вам потрібне ізольоване, тимчасове середовище Gateway або ви хочете запускати OpenClaw на хості без локальних установок.
-- **Ні**: ви запускаєте його на власному комп’ютері й просто хочете найшвидший цикл розробки. Натомість використовуйте звичайний потік встановлення.
-- **Примітка щодо ізоляції**: типовий бекенд ізоляції використовує Docker, коли ізоляцію ввімкнено, але ізоляція за замовчуванням вимкнена і **не** вимагає запуску всього Gateway у Docker. Також доступні бекенди ізоляції SSH і OpenShell. Див. [Ізоляція](/uk/gateway/sandboxing).
+- **Так**: вам потрібне ізольоване, тимчасове середовище Gateway або ви хочете запускати OpenClaw на хості без локальних встановлень.
+- **Ні**: ви запускаєте на власній машині й просто хочете найшвидший цикл розробки. Натомість скористайтеся звичайним потоком встановлення.
+- **Примітка щодо ізоляції**: типовий бекенд ізоляції використовує Docker, коли ізоляцію увімкнено, але ізоляція вимкнена типово й **не** вимагає запуску повного Gateway у Docker. Також доступні бекенди ізоляції SSH і OpenShell. Див. [Ізоляція](/uk/gateway/sandboxing).
 
 ## Передумови
 
 - Docker Desktop (або Docker Engine) + Docker Compose v2
-- Щонайменше 2 ГБ RAM для збирання образу (`pnpm install` може бути примусово завершено через OOM на хостах із 1 ГБ із кодом виходу 137)
-- Достатньо дискового простору для образів і журналів
-- Якщо запуск відбувається на VPS/публічному хості, перегляньте
-  [Посилення безпеки для мережевого доступу](/uk/gateway/security),
-  особливо політику фаєрвола Docker `DOCKER-USER`.
+- Щонайменше 2 ГБ RAM для збирання образу (`pnpm install` може бути примусово завершено через OOM на хостах із 1 ГБ з кодом виходу 137)
+- Достатньо місця на диску для образів і журналів
+- Якщо запускаєте на VPS/публічному хості, перегляньте
+  [Посилення безпеки для мережевої доступності](/uk/gateway/security),
+  особливо політику брандмауера Docker `DOCKER-USER`.
 
 ## Контейнеризований Gateway
 
 <Steps>
   <Step title="Зберіть образ">
-    Із кореня репозиторію запустіть скрипт налаштування:
+    З кореня репозиторію запустіть скрипт налаштування:
 
     ```bash
     ./scripts/docker/setup.sh
     ```
 
-    Це локально збере образ Gateway. Щоб замість цього використовувати попередньо зібраний образ:
+    Це локально збере образ Gateway. Щоб натомість використовувати попередньо зібраний образ:
 
     ```bash
     export OPENCLAW_IMAGE="ghcr.io/openclaw/openclaw:latest"
@@ -53,23 +53,23 @@ Docker **необов’язковий**. Використовуйте його
 
   </Step>
 
-  <Step title="Завершіть онбординг">
-    Скрипт налаштування запускає онбординг автоматично. Він:
+  <Step title="Завершіть початкове налаштування">
+    Скрипт налаштування запускає початкове налаштування автоматично. Він:
 
-    - запросить API-ключі провайдера
-    - згенерує токен Gateway і запише його до `.env`
+    - запросить API-ключі провайдерів
+    - згенерує токен Gateway і запише його в `.env`
     - запустить Gateway через Docker Compose
 
-    Під час налаштування онбординг до запуску й запис конфігурації виконуються
-    безпосередньо через `openclaw-gateway`. `openclaw-cli` призначений для команд, які ви запускаєте після того, як контейнер Gateway уже існує.
+    Під час налаштування передстартове початкове налаштування та запис конфігурації виконуються безпосередньо через
+    `openclaw-gateway`. `openclaw-cli` призначений для команд, які ви запускаєте вже після того, як контейнер Gateway існує.
 
   </Step>
 
   <Step title="Відкрийте Control UI">
-    Відкрийте `http://127.0.0.1:18789/` у браузері й вставте налаштований
-    спільний секрет у Settings. Скрипт налаштування за замовчуванням записує токен у `.env`; якщо ви перемкнете конфігурацію контейнера на автентифікацію паролем, використовуйте натомість цей пароль.
+    Відкрийте `http://127.0.0.1:18789/` у браузері та вставте налаштований
+    спільний секрет у Settings. Скрипт налаштування типово записує токен у `.env`; якщо ви перемкнете конфігурацію контейнера на автентифікацію за паролем, використовуйте натомість цей пароль.
 
-    Потрібна URL-адреса ще раз?
+    Потрібна URL-адреса знову?
 
     ```bash
     docker compose run --rm openclaw-cli dashboard --no-open
@@ -98,7 +98,7 @@ Docker **необов’язковий**. Використовуйте його
 
 ### Ручний потік
 
-Якщо ви віддаєте перевагу запуску кожного кроку вручну замість використання скрипта налаштування:
+Якщо ви надаєте перевагу запуску кожного кроку самостійно замість використання скрипта налаштування:
 
 ```bash
 docker build -t openclaw:local -f Dockerfile .
@@ -112,12 +112,13 @@ docker compose up -d openclaw-gateway
 <Note>
 Запускайте `docker compose` з кореня репозиторію. Якщо ви ввімкнули `OPENCLAW_EXTRA_MOUNTS`
 або `OPENCLAW_HOME_VOLUME`, скрипт налаштування записує `docker-compose.extra.yml`;
-додайте його за допомогою `-f docker-compose.yml -f docker-compose.extra.yml`.
+додавайте його через `-f docker-compose.yml -f docker-compose.extra.yml`.
 </Note>
 
 <Note>
-Оскільки `openclaw-cli` використовує спільний простір імен мережі з `openclaw-gateway`, це інструмент для використання після запуску. До `docker compose up -d openclaw-gateway` виконуйте онбординг
-і записи конфігурації під час налаштування через `openclaw-gateway` з
+Оскільки `openclaw-cli` спільно використовує простір назв мережі `openclaw-gateway`, це
+інструмент для використання після запуску. До `docker compose up -d openclaw-gateway` виконуйте початкове налаштування
+та записи конфігурації під час налаштування через `openclaw-gateway` з
 `--no-deps --entrypoint node`.
 </Note>
 
@@ -128,32 +129,32 @@ docker compose up -d openclaw-gateway
 | Variable                                   | Purpose                                                         |
 | ------------------------------------------ | --------------------------------------------------------------- |
 | `OPENCLAW_IMAGE`                           | Використовувати віддалений образ замість локального збирання    |
-| `OPENCLAW_DOCKER_APT_PACKAGES`             | Встановити додаткові пакети apt під час збирання (імена через пробіл) |
-| `OPENCLAW_EXTENSIONS`                      | Попередньо встановити залежності plugin під час збирання (імена через пробіл) |
-| `OPENCLAW_EXTRA_MOUNTS`                    | Додаткові bind mounts хоста (через кому у форматі `source:target[:opts]`) |
+| `OPENCLAW_DOCKER_APT_PACKAGES`             | Установити додаткові apt-пакети під час збирання (назви через пробіл) |
+| `OPENCLAW_EXTENSIONS`                      | Попередньо встановити залежності plugin під час збирання (назви через пробіл) |
+| `OPENCLAW_EXTRA_MOUNTS`                    | Додаткові bind mount хоста (через кому `source:target[:opts]`) |
 | `OPENCLAW_HOME_VOLUME`                     | Зберігати `/home/node` в іменованому томі Docker                |
 | `OPENCLAW_SANDBOX`                         | Увімкнути початкове налаштування ізоляції (`1`, `true`, `yes`, `on`) |
 | `OPENCLAW_DOCKER_SOCKET`                   | Перевизначити шлях до сокета Docker                             |
-| `OPENCLAW_DISABLE_BONJOUR`                 | Вимкнути рекламу Bonjour/mDNS (для Docker за замовчуванням `1`) |
-| `OPENCLAW_DISABLE_BUNDLED_SOURCE_OVERLAYS` | Вимкнути bind-mount overlays для вихідного коду вбудованих plugin |
-| `OTEL_EXPORTER_OTLP_ENDPOINT`              | Спільна кінцева точка колектора OTLP/HTTP для експорту OpenTelemetry |
-| `OTEL_EXPORTER_OTLP_*_ENDPOINT`            | Кінцеві точки OTLP для traces, metrics або logs, специфічні для сигналу |
+| `OPENCLAW_DISABLE_BONJOUR`                 | Вимкнути рекламу Bonjour/mDNS (типово `1` для Docker)           |
+| `OPENCLAW_DISABLE_BUNDLED_SOURCE_OVERLAYS` | Вимкнути bind-mount overlays для вбудованих джерел plugin       |
+| `OTEL_EXPORTER_OTLP_ENDPOINT`              | Спільна кінцева точка OTLP/HTTP collector для експорту OpenTelemetry |
+| `OTEL_EXPORTER_OTLP_*_ENDPOINT`            | Кінцеві точки OTLP для певних сигналів: traces, metrics або logs |
 | `OTEL_EXPORTER_OTLP_PROTOCOL`              | Перевизначення протоколу OTLP. Наразі підтримується лише `http/protobuf` |
 | `OTEL_SERVICE_NAME`                        | Назва сервісу, що використовується для ресурсів OpenTelemetry   |
-| `OTEL_SEMCONV_STABILITY_OPT_IN`            | Увімкнути новітні експериментальні семантичні атрибути GenAI    |
-| `OPENCLAW_OTEL_PRELOADED`                  | Пропустити запуск другого SDK OpenTelemetry, якщо один уже попередньо завантажено |
+| `OTEL_SEMCONV_STABILITY_OPT_IN`            | Увімкнути найновіші експериментальні семантичні атрибути GenAI  |
+| `OPENCLAW_OTEL_PRELOADED`                  | Не запускати другий SDK OpenTelemetry, якщо один уже попередньо завантажений |
 
-Супровідники можуть тестувати вихідний код вбудованого plugin із запакованим образом, змонтувавши
-один каталог вихідного коду plugin поверх його шляху запакованого вихідного коду, наприклад
+Супроводжувачі можуть тестувати вбудований код plugin з упакованим образом, змонтувавши
+один каталог вихідного коду plugin поверх його шляху до упакованого коду, наприклад
 `OPENCLAW_EXTRA_MOUNTS=/path/to/fork/extensions/synology-chat:/app/extensions/synology-chat:ro`.
 Цей змонтований каталог вихідного коду перевизначає відповідний скомпільований
-бандл `/app/dist/extensions/synology-chat` для того самого ідентифікатора plugin.
+bundle `/app/dist/extensions/synology-chat` для того самого ідентифікатора plugin.
 
 ### Спостережуваність
 
-Експорт OpenTelemetry є вихідним із контейнера Gateway до вашого колектора OTLP.
-Для нього не потрібен опублікований порт Docker. Якщо ви локально збираєте образ і хочете, щоб вбудований експортер OpenTelemetry був доступний усередині образу,
-додайте його залежності часу виконання:
+Експорт OpenTelemetry є вихідним трафіком із контейнера Gateway до вашого OTLP
+collector. Для цього не потрібен опублікований порт Docker. Якщо ви локально збираєте образ і хочете, щоб вбудований експортер OpenTelemetry був доступний усередині образу,
+додайте його залежності виконання:
 
 ```bash
 export OPENCLAW_EXTENSIONS="diagnostics-otel"
@@ -162,93 +163,118 @@ export OTEL_SERVICE_NAME="openclaw-gateway"
 ./scripts/docker/setup.sh
 ```
 
-Офіційний релізний Docker-образ OpenClaw містить вихідний код вбудованого
-plugin `diagnostics-otel`. Залежно від стану образу й кешу,
-Gateway може все одно підготувати локальні залежності OpenTelemetry для plugin
-під час першого ввімкнення plugin, тому дозвольте цьому першому запуску мати доступ до реєстру пакетів
-або попередньо прогрійте образ у вашому релізному потоці. Щоб увімкнути експорт, дозвольте й
+Офіційний Docker-образ релізу OpenClaw містить вбудований вихідний код plugin
+`diagnostics-otel`. Залежно від образу та стану кешу,
+Gateway усе ще може підготувати локальні залежності виконання OpenTelemetry plugin
+під час першого ввімкнення plugin, тому дозвольте цьому першому запуску доступ до реєстру пакетів
+або попередньо прогрійте образ у вашому релізному конвеєрі. Щоб увімкнути експорт, дозвольте та
 увімкніть plugin `diagnostics-otel` у конфігурації, а потім установіть
-`diagnostics.otel.enabled=true` або скористайтеся прикладом конфігурації з
-[Експорт OpenTelemetry](/uk/gateway/opentelemetry). Заголовки автентифікації колектора
-налаштовуються через `diagnostics.otel.headers`, а не через змінні середовища Docker.
+`diagnostics.otel.enabled=true` або скористайтеся прикладом конфігурації в
+[Експорт OpenTelemetry](/uk/gateway/opentelemetry). Заголовки автентифікації collector налаштовуються через
+`diagnostics.otel.headers`, а не через змінні середовища Docker.
 
 Метрики Prometheus використовують уже опублікований порт Gateway. Увімкніть
-plugin `diagnostics-prometheus`, а потім виконуйте збирання:
+plugin `diagnostics-prometheus`, а потім збирайте:
 
 ```text
 http://<gateway-host>:18789/api/diagnostics/prometheus
 ```
 
 Маршрут захищено автентифікацією Gateway. Не відкривайте окремий
-публічний порт `/metrics` або неавтентифікований шлях зворотного проксі. Див.
+публічний порт `/metrics` або неавтентифікований шлях через reverse proxy. Див.
 [Метрики Prometheus](/uk/gateway/prometheus).
 
-### Перевірки стану
+### Перевірки працездатності
 
 Кінцеві точки probe контейнера (автентифікація не потрібна):
 
 ```bash
-curl -fsS http://127.0.0.1:18789/healthz   # liveness
-curl -fsS http://127.0.0.1:18789/readyz     # readiness
+curl -fsS http://127.0.0.1:18789/healthz   # live
+curl -fsS http://127.0.0.1:18789/readyz     # готовність
 ```
 
 Docker-образ містить вбудований `HEALTHCHECK`, який опитує `/healthz`.
-Якщо перевірки продовжують завершуватися помилкою, Docker позначає контейнер як `unhealthy`, і
+Якщо перевірки продовжують провалюватися, Docker позначає контейнер як `unhealthy`, і
 системи оркестрації можуть перезапустити або замінити його.
 
-Автентифікований докладний знімок стану:
+Автентифікований глибокий знімок стану:
 
 ```bash
 docker compose exec openclaw-gateway node dist/index.js health --token "$OPENCLAW_GATEWAY_TOKEN"
 ```
 
-### LAN чи loopback
+### LAN проти loopback
 
-`scripts/docker/setup.sh` за замовчуванням встановлює `OPENCLAW_GATEWAY_BIND=lan`, щоб доступ хоста до
-`http://127.0.0.1:18789` працював із публікацією портів Docker.
+`scripts/docker/setup.sh` типово використовує `OPENCLAW_GATEWAY_BIND=lan`, щоб доступ хоста до
+`http://127.0.0.1:18789` працював із публікацією порту Docker.
 
-- `lan` (типово): браузер і CLI на хості можуть отримати доступ до опублікованого порту Gateway.
-- `loopback`: лише процеси всередині простору імен мережі контейнера можуть
-  напряму отримати доступ до Gateway.
+- `lan` (типово): браузер хоста та CLI хоста можуть досягати опублікованого порту Gateway.
+- `loopback`: лише процеси всередині простору назв мережі контейнера можуть
+  напряму досягати Gateway.
 
 <Note>
 Використовуйте значення режиму прив’язки в `gateway.bind` (`lan` / `loopback` / `custom` /
 `tailnet` / `auto`), а не псевдоніми хоста на кшталт `0.0.0.0` або `127.0.0.1`.
 </Note>
 
+### Локальні провайдери хоста
+
+Коли OpenClaw працює в Docker, `127.0.0.1` всередині контейнера — це сам контейнер,
+а не ваша хост-машина. Для провайдерів AI, які працюють на хості, використовуйте `host.docker.internal`:
+
+| Provider  | Host default URL         | Docker setup URL                    |
+| --------- | ------------------------ | ----------------------------------- |
+| LM Studio | `http://127.0.0.1:1234`  | `http://host.docker.internal:1234`  |
+| Ollama    | `http://127.0.0.1:11434` | `http://host.docker.internal:11434` |
+
+Вбудоване налаштування Docker використовує ці URL хоста як типові значення для LM Studio та Ollama
+під час початкового налаштування, а `docker-compose.yml` відображає `host.docker.internal` на
+шлюз хоста Docker для Linux Docker Engine. Docker Desktop уже надає
+те саме ім’я хоста на macOS і Windows.
+
+Служби хоста також мають слухати на адресі, досяжній із Docker:
+
+```bash
+lms server start --port 1234 --bind 0.0.0.0
+OLLAMA_HOST=0.0.0.0:11434 ollama serve
+```
+
+Якщо ви використовуєте власний файл Compose або команду `docker run`, додайте те саме
+відображення хоста самостійно, наприклад
+`--add-host=host.docker.internal:host-gateway`.
+
 ### Bonjour / mDNS
 
-Мережа Docker bridge зазвичай ненадійно пересилає мультикаст Bonjour/mDNS
-(`224.0.0.251:5353`). Тому вбудоване налаштування Compose типово встановлює
-`OPENCLAW_DISABLE_BONJOUR=1`, щоб Gateway не потрапляв у цикл аварійних перезапусків і
-не перезапускав рекламу знову й знову, коли bridge втрачає мультикаст-трафік.
+Мережа Docker bridge зазвичай не пересилає multicast Bonjour/mDNS
+(`224.0.0.251:5353`) надійно. Тому вбудоване налаштування Compose типово використовує
+`OPENCLAW_DISABLE_BONJOUR=1`, щоб Gateway не потрапляв у цикл аварійних перезапусків і не
+перезапускав рекламу повторно, коли bridge втрачає multicast-трафік.
 
 Для Docker-хостів використовуйте опубліковану URL-адресу Gateway, Tailscale або wide-area DNS-SD.
-Установлюйте `OPENCLAW_DISABLE_BONJOUR=0` лише під час роботи з host networking, macvlan
-або іншою мережею, де мультикаст mDNS гарантовано працює.
+Установлюйте `OPENCLAW_DISABLE_BONJOUR=0` лише під час запуску з host networking, macvlan
+або іншою мережею, де multicast mDNS гарантовано працює.
 
-Про типові проблеми та усунення несправностей див.
-[Виявлення Bonjour](/uk/gateway/bonjour).
+Щоб дізнатися про типові проблеми та способи усунення несправностей, див. [Виявлення Bonjour](/uk/gateway/bonjour).
 
 ### Сховище та збереження даних
 
-Docker Compose монтує через bind `OPENCLAW_CONFIG_DIR` до `/home/node/.openclaw` і
-`OPENCLAW_WORKSPACE_DIR` до `/home/node/.openclaw/workspace`, тож ці шляхи
+Docker Compose монтує `OPENCLAW_CONFIG_DIR` у `/home/node/.openclaw` і
+`OPENCLAW_WORKSPACE_DIR` у `/home/node/.openclaw/workspace`, тому ці шляхи
 зберігаються після заміни контейнера.
 
 У цьому змонтованому каталозі конфігурації OpenClaw зберігає:
 
 - `openclaw.json` для конфігурації поведінки
-- `agents/<agentId>/agent/auth-profiles.json` для збереженої OAuth/API-key автентифікації провайдера
-- `.env` для секретів часу виконання на основі змінних середовища, таких як `OPENCLAW_GATEWAY_TOKEN`
+- `agents/<agentId>/agent/auth-profiles.json` для збереженої OAuth/API-key автентифікації провайдерів
+- `.env` для секретів виконання на основі змінних середовища, таких як `OPENCLAW_GATEWAY_TOKEN`
 
-Повні відомості про збереження даних у розгортаннях на VM див. у
-[Середовище виконання Docker VM — що і де зберігається](/uk/install/docker-vm-runtime#what-persists-where).
+Повні відомості про збереження даних у розгортаннях VM див. у
+[Docker VM Runtime - Що зберігається де](/uk/install/docker-vm-runtime#what-persists-where).
 
-**Точки зростання диска:** стежте за `media/`, файлами JSONL сеансів, `cron/runs/*.jsonl`,
-і файлами циклічних журналів у `/tmp/openclaw/`.
+**Точки зростання диска:** стежте за `media/`, JSONL-файлами сесій, `cron/runs/*.jsonl`,
+і журналами rolling file у `/tmp/openclaw/`.
 
-### Допоміжні команди оболонки (необов’язково)
+### Допоміжні команди shell (необов’язково)
 
 Для зручнішого повсякденного керування Docker установіть `ClawDock`:
 
@@ -257,11 +283,11 @@ mkdir -p ~/.clawdock && curl -sL https://raw.githubusercontent.com/openclaw/open
 echo 'source ~/.clawdock/clawdock-helpers.sh' >> ~/.zshrc && source ~/.zshrc
 ```
 
-Якщо ви встановлювали ClawDock зі старого шляху raw `scripts/shell-helpers/clawdock-helpers.sh`, повторно виконайте команду встановлення вище, щоб ваш локальний файл helper відстежував нове розташування.
+Якщо ви встановили `ClawDock` зі старого raw-шляху `scripts/shell-helpers/clawdock-helpers.sh`, повторно виконайте наведену вище команду встановлення, щоб ваш локальний файл помічника відстежував нове розташування.
 
-Потім використовуйте `clawdock-start`, `clawdock-stop`, `clawdock-dashboard` тощо. Виконайте
+Потім використовуйте `clawdock-start`, `clawdock-stop`, `clawdock-dashboard` тощо. Запустіть
 `clawdock-help`, щоб побачити всі команди.
-Див. [ClawDock](/uk/install/clawdock), щоб ознайомитися з повним посібником з helper.
+Повний посібник щодо помічника див. у [ClawDock](/uk/install/clawdock).
 
 <AccordionGroup>
   <Accordion title="Увімкнути ізоляцію агента для Docker Gateway">
@@ -270,7 +296,7 @@ echo 'source ~/.clawdock/clawdock-helpers.sh' >> ~/.zshrc && source ~/.zshrc
     ./scripts/docker/setup.sh
     ```
 
-    Нестандартний шлях до сокета (наприклад, rootless Docker):
+    Власний шлях до сокета (наприклад, rootless Docker):
 
     ```bash
     export OPENCLAW_SANDBOX=1
@@ -278,7 +304,7 @@ echo 'source ~/.clawdock/clawdock-helpers.sh' >> ~/.zshrc && source ~/.zshrc
     ./scripts/docker/setup.sh
     ```
 
-    Скрипт монтує `docker.sock` лише після успішного проходження передумов ізоляції. Якщо
+    Скрипт монтує `docker.sock` лише після того, як передумови ізоляції успішно пройдено. Якщо
     налаштування ізоляції не вдається завершити, скрипт скидає `agents.defaults.sandbox.mode`
     до `off`.
 
@@ -295,15 +321,15 @@ echo 'source ~/.clawdock/clawdock-helpers.sh' >> ~/.zshrc && source ~/.zshrc
   </Accordion>
 
   <Accordion title="Примітка щодо безпеки спільної мережі">
-    `openclaw-cli` використовує `network_mode: "service:openclaw-gateway"`, тож команди CLI
-    можуть звертатися до Gateway через `127.0.0.1`. Розглядайте це як спільну
-    межу довіри. Конфігурація compose прибирає `NET_RAW`/`NET_ADMIN` і вмикає
+    `openclaw-cli` використовує `network_mode: "service:openclaw-gateway"`, тому команди CLI
+    можуть досягати gateway через `127.0.0.1`. Розглядайте це як спільну
+    межу довіри. Конфігурація compose скидає `NET_RAW`/`NET_ADMIN` і вмикає
     `no-new-privileges` для `openclaw-cli`.
   </Accordion>
 
-  <Accordion title="Права доступу та EACCES">
-    Образ працює від імені `node` (uid 1000). Якщо ви бачите помилки прав доступу на
-    `/home/node/.openclaw`, переконайтеся, що bind mounts на хості належать uid 1000:
+  <Accordion title="Дозволи та EACCES">
+    Образ запускається як `node` (uid 1000). Якщо ви бачите помилки дозволів для
+    `/home/node/.openclaw`, переконайтеся, що ваші bind mount хоста належать uid 1000:
 
     ```bash
     sudo chown -R 1000:1000 /path/to/openclaw-config /path/to/openclaw-workspace
@@ -313,7 +339,7 @@ echo 'source ~/.clawdock/clawdock-helpers.sh' >> ~/.zshrc && source ~/.zshrc
 
   <Accordion title="Швидші перебудови">
     Упорядкуйте Dockerfile так, щоб шари залежностей кешувалися. Це дозволяє уникнути повторного запуску
-    `pnpm install`, якщо lockfiles не змінювалися:
+    `pnpm install`, якщо lockfile не змінювалися:
 
     ```dockerfile
     FROM node:24-bookworm
@@ -335,13 +361,13 @@ echo 'source ~/.clawdock/clawdock-helpers.sh' >> ~/.zshrc && source ~/.zshrc
 
   </Accordion>
 
-  <Accordion title="Розширені параметри контейнера">
-    Типовий образ насамперед орієнтований на безпеку й працює від імені непривілейованого `node`. Для більш
+  <Accordion title="Параметри контейнера для досвідчених користувачів">
+    Типовий образ орієнтований насамперед на безпеку і працює як непривілейований `node`. Для більш
     функціонального контейнера:
 
     1. **Зберігайте `/home/node`**: `export OPENCLAW_HOME_VOLUME="openclaw_home"`
     2. **Вбудуйте системні залежності**: `export OPENCLAW_DOCKER_APT_PACKAGES="git curl jq"`
-    3. **Встановіть браузери Playwright**:
+    3. **Установіть браузери Playwright**:
        ```bash
        docker compose run --rm openclaw-cli \
          node /app/node_modules/playwright-core/cli.js install chromium
@@ -354,44 +380,44 @@ echo 'source ~/.clawdock/clawdock-helpers.sh' >> ~/.zshrc && source ~/.zshrc
 
   <Accordion title="OpenAI Codex OAuth (headless Docker)">
     Якщо у майстрі ви виберете OpenAI Codex OAuth, він відкриє URL-адресу в браузері. У
-    Docker або headless-середовищах скопіюйте повну URL-адресу перенаправлення, на яку ви потрапите, і вставте
+    Docker або headless-налаштуваннях скопіюйте повну URL-адресу перенаправлення, на яку ви потрапите, і вставте
     її назад у майстер, щоб завершити автентифікацію.
   </Accordion>
 
   <Accordion title="Метадані базового образу">
-    Основний Docker-образ середовища виконання використовує `node:24-bookworm-slim` і публікує OCI
+    Основний runtime-образ Docker використовує `node:24-bookworm-slim` і публікує OCI
     анотації базового образу, зокрема `org.opencontainers.image.base.name`,
     `org.opencontainers.image.source` та інші. Digest базового образу Node
-    оновлюється через PR Dependabot для базових Docker-образів; релізні збірки не виконують
+    оновлюється через PR Dependabot для базових Docker-образів; релізні збірки не запускають
     шар оновлення дистрибутива. Див.
-    [Анотації образів OCI](https://github.com/opencontainers/image-spec/blob/main/annotations.md).
+    [OCI image annotations](https://github.com/opencontainers/image-spec/blob/main/annotations.md).
   </Accordion>
 </AccordionGroup>
 
-### Запуск на VPS?
+### Запускаєте на VPS?
 
 Див. [Hetzner (Docker VPS)](/uk/install/hetzner) і
-[Docker VM Runtime](/uk/install/docker-vm-runtime), щоб переглянути кроки розгортання на спільних VM
-включно з вбудовуванням бінарних файлів, збереженням даних і оновленнями.
+[Docker VM Runtime](/uk/install/docker-vm-runtime), щоб ознайомитися з кроками розгортання на спільній VM,
+включно з вбудовуванням бінарників, збереженням даних і оновленнями.
 
 ## Ізоляція агента
 
-Коли `agents.defaults.sandbox` увімкнено з Docker-бекендом, Gateway
-виконує інструменти агента (shell, читання/запис файлів тощо) в ізольованих Docker-
-контейнерах, тоді як сам Gateway залишається на хості. Це створює жорстку межу
-навколо недовірених або мультитенантних сеансів агентів без контейнеризації всього
-Gateway.
+Коли `agents.defaults.sandbox` увімкнено з Docker-бекендом, gateway
+виконує інструменти агента (shell, читання/запис файлів тощо) в ізольованих Docker
+контейнерах, тоді як сам gateway залишається на хості. Це створює жорстку межу
+навколо недовірених або багатокористувацьких сеансів агентів без контейнеризації всього
+gateway.
 
-Область ізоляції може бути для кожного агента окремо (типово), для кожного сеансу або спільною. Кожна область
+Область ізоляції може бути для агента (типово), для сеансу або спільною. Кожна область
 отримує власний workspace, змонтований у `/workspace`. Ви також можете налаштувати
-політики дозволу/заборони інструментів, ізоляцію мережі, обмеження ресурсів і
-контейнери браузера.
+політики дозволу/заборони інструментів, ізоляцію мережі, обмеження ресурсів і браузерні
+контейнери.
 
-Повну інформацію про конфігурацію, образи, примітки щодо безпеки й профілі з кількома агентами див. у:
+Повну інформацію про конфігурацію, образи, примітки щодо безпеки та профілі для кількох агентів див. тут:
 
 - [Ізоляція](/uk/gateway/sandboxing) -- повний довідник з ізоляції
-- [OpenShell](/uk/gateway/openshell) -- інтерактивний доступ shell до контейнерів ізоляції
-- [Ізоляція й інструменти для кількох агентів](/uk/tools/multi-agent-sandbox-tools) -- перевизначення для окремих агентів
+- [OpenShell](/uk/gateway/openshell) -- інтерактивний shell-доступ до контейнерів ізоляції
+- [Multi-Agent Sandbox and Tools](/uk/tools/multi-agent-sandbox-tools) -- перевизначення для окремих агентів
 
 ### Швидке ввімкнення
 
@@ -420,27 +446,27 @@ scripts/sandbox-setup.sh
   <Accordion title="Образ відсутній або контейнер ізоляції не запускається">
     Зберіть образ ізоляції за допомогою
     [`scripts/sandbox-setup.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/sandbox-setup.sh)
-    або встановіть `agents.defaults.sandbox.docker.image` на ваш власний образ.
+    або встановіть `agents.defaults.sandbox.docker.image` на власний образ.
     Контейнери автоматично створюються за потреби для кожного сеансу.
   </Accordion>
 
-  <Accordion title="Помилки прав доступу в ізоляції">
+  <Accordion title="Помилки дозволів в ізоляції">
     Установіть `docker.user` на UID:GID, що відповідає власнику змонтованого workspace,
-    або змініть власника папки workspace через chown.
+    або змініть власника теки workspace за допомогою chown.
   </Accordion>
 
   <Accordion title="Власні інструменти не знайдено в ізоляції">
-    OpenClaw запускає команди через `sh -lc` (login shell), який завантажує
-    `/etc/profile` і може скинути PATH. Установіть `docker.env.PATH`, щоб додати
-    ваші власні шляхи до інструментів на початок, або додайте скрипт до `/etc/profile.d/` у вашому Dockerfile.
+    OpenClaw запускає команди через `sh -lc` (login shell), який зчитує
+    `/etc/profile` і може скидати PATH. Установіть `docker.env.PATH`, щоб додати
+    ваші шляхи до власних інструментів на початок, або додайте скрипт у `/etc/profile.d/` у вашому Dockerfile.
   </Accordion>
 
   <Accordion title="Примусове завершення через OOM під час збирання образу (код виходу 137)">
-    VM потребує щонайменше 2 ГБ RAM. Використайте більший клас машини та повторіть спробу.
+    VM потребує щонайменше 2 ГБ RAM. Використайте більший клас машини й повторіть спробу.
   </Accordion>
 
-  <Accordion title="Unauthorized або потрібне сполучення в Control UI">
-    Отримайте нове посилання на dashboard і схваліть пристрій браузера:
+  <Accordion title="Unauthorized або потрібне pairування в Control UI">
+    Отримайте нове посилання dashboard і схваліть браузерний пристрій:
 
     ```bash
     docker compose run --rm openclaw-cli dashboard --no-open
@@ -448,12 +474,12 @@ scripts/sandbox-setup.sh
     docker compose run --rm openclaw-cli devices approve <requestId>
     ```
 
-    Докладніше: [Dashboard](/uk/web/dashboard), [Пристрої](/uk/cli/devices).
+    Докладніше: [Dashboard](/uk/web/dashboard), [Devices](/uk/cli/devices).
 
   </Accordion>
 
-  <Accordion title="Ціль Gateway показує ws://172.x.x.x або помилки сполучення з Docker CLI">
-    Скиньте режим Gateway і прив’язку:
+  <Accordion title="Ціль gateway показує ws://172.x.x.x або помилки pairування з Docker CLI">
+    Скиньте mode і bind gateway:
 
     ```bash
     docker compose run --rm openclaw-cli config set --batch-json '[{"path":"gateway.mode","value":"local"},{"path":"gateway.bind","value":"lan"}]'
@@ -463,10 +489,10 @@ scripts/sandbox-setup.sh
   </Accordion>
 </AccordionGroup>
 
-## Пов’язане
+## Пов’язані матеріали
 
-- [Огляд встановлення](/uk/install) — усі способи встановлення
+- [Огляд установлення](/uk/install) — усі способи встановлення
 - [Podman](/uk/install/podman) — альтернатива Docker у вигляді Podman
 - [ClawDock](/uk/install/clawdock) — спільнотне налаштування Docker Compose
-- [Оновлення](/uk/install/updating) — як підтримувати OpenClaw в актуальному стані
-- [Конфігурація](/uk/gateway/configuration) — конфігурація Gateway після встановлення
+- [Оновлення](/uk/install/updating) — підтримання OpenClaw в актуальному стані
+- [Конфігурація](/uk/gateway/configuration) — конфігурація gateway після встановлення

docs/uk/install/migrating-hermes.md

@@ -0,0 +1,174 @@
+---
+read_when:
+    - Ви переходите з Hermes і хочете зберегти конфігурацію моделі, підказки, пам’ять і Skills
+    - Ви хочете знати, що OpenClaw імпортує автоматично, а що залишається лише в архіві
+    - Вам потрібен чистий, скриптований шлях міграції (CI, новий ноутбук, автоматизація)
+summary: Перейдіть із Hermes до OpenClaw за допомогою попередньо переглянутого імпорту з можливістю скасування
+title: Міграція з Hermes
+x-i18n:
+    generated_at: "2026-04-27T08:08:07Z"
+    model: gpt-5.4
+    provider: openai
+    source_hash: 2fdf09f21398d10a8cdf8e98237fbdfb3c56ade5b56e73a6e6ae01b5c201440d
+    source_path: install/migrating-hermes.md
+    workflow: 15
+---
+
+OpenClaw імпортує стан Hermes через вбудований провайдер міграції. Провайдер попередньо показує все перед зміною стану, редагує секрети в планах і звітах та створює перевірену резервну копію перед застосуванням.
+
+<Note>
+Імпорт потребує нового налаштування OpenClaw. Якщо у вас уже є локальний стан OpenClaw, спочатку скиньте конфігурацію, облікові дані, сесії та робочий простір або використайте `openclaw migrate` безпосередньо з `--overwrite` після перегляду плану.
+</Note>
+
+## Два способи імпорту
+
+<Tabs>
+  <Tab title="Майстер онбордингу">
+    Найшвидший шлях. Майстер виявляє Hermes у `~/.hermes` і показує попередній перегляд перед застосуванням.
+
+    ```bash
+    openclaw onboard --flow import
+    ```
+
+    Або вкажіть конкретне джерело:
+
+    ```bash
+    openclaw onboard --import-from hermes --import-source ~/.hermes
+    ```
+  </Tab>
+  <Tab title="CLI">
+    Використовуйте `openclaw migrate` для скриптованих або повторюваних запусків. Див. [`openclaw migrate`](/uk/cli/migrate) для повного довідника.
+
+    ```bash
+    openclaw migrate hermes --dry-run    # лише попередній перегляд
+    openclaw migrate apply hermes --yes  # застосувати без підтвердження
+    ```
+
+    Додайте `--from <path>`, якщо Hermes розташований поза `~/.hermes`.
+  </Tab>
+</Tabs>
+
+## Що імпортується
+
+<AccordionGroup>
+  <Accordion title="Конфігурація моделі">
+    - Вибір типової моделі з Hermes `config.yaml`.
+    - Налаштовані провайдери моделей і власні OpenAI-сумісні кінцеві точки з `providers` і `custom_providers`.
+  </Accordion>
+  <Accordion title="Сервери MCP">
+    Визначення серверів MCP з `mcp_servers` або `mcp.servers`.
+  </Accordion>
+  <Accordion title="Файли робочого простору">
+    - `SOUL.md` і `AGENTS.md` копіюються до робочого простору агента OpenClaw.
+    - `memories/MEMORY.md` і `memories/USER.md` **додаються** до відповідних файлів пам’яті OpenClaw замість перезапису.
+  </Accordion>
+  <Accordion title="Конфігурація пам’яті">
+    Типові налаштування пам’яті для файлової пам’яті OpenClaw. Зовнішні провайдери пам’яті, такі як Honcho, записуються як архівні елементи або елементи для ручної перевірки, щоб ви могли перенести їх свідомо.
+  </Accordion>
+  <Accordion title="Skills">
+    Skills із файлом `SKILL.md` у `skills/<name>/` копіюються разом зі значеннями конфігурації для кожної Skill з `skills.config`.
+  </Accordion>
+  <Accordion title="Ключі API (за бажанням)">
+    Встановіть `--include-secrets`, щоб імпортувати підтримувані ключі `.env`: `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `OPENROUTER_API_KEY`, `GOOGLE_API_KEY`, `GEMINI_API_KEY`, `GROQ_API_KEY`, `XAI_API_KEY`, `MISTRAL_API_KEY`, `DEEPSEEK_API_KEY`. Без цього прапорця секрети ніколи не копіюються.
+  </Accordion>
+</AccordionGroup>
+
+## Що залишається лише в архіві
+
+Провайдер копіює це до каталогу звіту про міграцію для ручної перевірки, але **не** завантажує до активної конфігурації чи облікових даних OpenClaw:
+
+- `plugins/`
+- `sessions/`
+- `logs/`
+- `cron/`
+- `mcp-tokens/`
+- `auth.json`
+- `state.db`
+
+OpenClaw відмовляється автоматично виконувати або вважати цей стан довіреним, оскільки формати та припущення про довіру можуть відрізнятися між системами. Перенесіть потрібне вручну після перегляду архіву.
+
+## Рекомендований процес
+
+<Steps>
+  <Step title="Переглянути план">
+    ```bash
+    openclaw migrate hermes --dry-run
+    ```
+
+    У плані перелічено все, що буде змінено, включно з конфліктами, пропущеними елементами та будь-якими чутливими елементами. Вивід плану редагує вкладені ключі, схожі на секрети.
+  </Step>
+  <Step title="Застосувати з резервною копією">
+    ```bash
+    openclaw migrate apply hermes --yes
+    ```
+
+    OpenClaw створює та перевіряє резервну копію перед застосуванням. Якщо вам потрібно імпортувати ключі API, додайте `--include-secrets`.
+  </Step>
+  <Step title="Запустити doctor">
+    ```bash
+    openclaw doctor
+    ```
+
+    [Doctor](/uk/gateway/doctor) повторно застосовує всі незавершені міграції конфігурації та перевіряє наявність проблем, які могли з’явитися під час імпорту.
+  </Step>
+  <Step title="Перезапустити та перевірити">
+    ```bash
+    openclaw gateway restart
+    openclaw status
+    ```
+
+    Підтвердьте, що Gateway працює справно і що ваші імпортовані модель, пам’ять і Skills завантажені.
+  </Step>
+</Steps>
+
+## Обробка конфліктів
+
+Застосування відмовляється продовжувати, якщо план повідомляє про конфлікти (файл або значення конфігурації вже існує в цільовому місці).
+
+<Warning>
+Повторно запускайте з `--overwrite` лише тоді, коли заміна наявної цілі справді є навмисною. Провайдери все одно можуть записувати резервні копії окремих елементів для перезаписаних файлів до каталогу звіту про міграцію.
+</Warning>
+
+Для нового встановлення OpenClaw конфлікти трапляються рідко. Зазвичай вони з’являються, коли ви повторно запускаєте імпорт у налаштуванні, де вже є користувацькі зміни.
+
+## Секрети
+
+Секрети ніколи не імпортуються типово.
+
+- Спочатку запустіть `openclaw migrate apply hermes --yes`, щоб імпортувати стан без секретів.
+- Якщо ви також хочете скопіювати підтримувані ключі `.env`, повторіть запуск із `--include-secrets`.
+- Для облікових даних, якими керує SecretRef, налаштуйте джерело SecretRef після завершення імпорту.
+
+## Вивід JSON для автоматизації
+
+```bash
+openclaw migrate hermes --dry-run --json
+openclaw migrate apply hermes --json --yes
+```
+
+З `--json` і без `--yes` застосування виводить план і не змінює стан. Це найбезпечніший режим для CI та спільних скриптів.
+
+## Усунення проблем
+
+<AccordionGroup>
+  <Accordion title="Застосування відмовляється через конфлікти">
+    Перегляньте вивід плану. Кожен конфлікт визначає вихідний шлях і наявну ціль. Для кожного елемента вирішіть, чи пропустити його, змінити ціль або повторно запустити з `--overwrite`.
+  </Accordion>
+  <Accordion title="Hermes розташований поза ~/.hermes">
+    Передайте `--from /actual/path` (CLI) або `--import-source /actual/path` (онбординг).
+  </Accordion>
+  <Accordion title="Онбординг відмовляється імпортувати в наявному налаштуванні">
+    Імпорт через онбординг потребує нового налаштування. Або скиньте стан і пройдіть онбординг знову, або використайте `openclaw migrate apply hermes` безпосередньо, що підтримує `--overwrite` і явне керування резервними копіями.
+  </Accordion>
+  <Accordion title="Ключі API не було імпортовано">
+    Потрібен `--include-secrets`, і розпізнаються лише перелічені вище ключі. Інші змінні в `.env` ігноруються.
+  </Accordion>
+</AccordionGroup>
+
+## Пов’язано
+
+- [`openclaw migrate`](/uk/cli/migrate): повний довідник CLI, контракт Plugin і форми JSON.
+- [Онбординг](/uk/cli/onboard): процес майстра та неінтерактивні прапорці.
+- [Міграція](/uk/install/migrating): перенесення встановлення OpenClaw між машинами.
+- [Doctor](/uk/gateway/doctor): перевірка стану після міграції.
+- [Робочий простір агента](/uk/concepts/agent-workspace): де розташовані `SOUL.md`, `AGENTS.md` і файли пам’яті.

docs/uk/plugins/architecture.md

@@ -1,188 +1,202 @@
 ---
 read_when:
-    - Створення або налагодження нативних Plugins OpenClaw
+    - Створення або налагодження власних plugins OpenClaw
     - Розуміння моделі можливостей Plugin або меж володіння
     - Робота над конвеєром завантаження Plugin або реєстром
-    - Реалізація хуків runtime постачальника або каналів Plugins
+    - Реалізація runtime hooks provider-а або plugins каналів
 sidebarTitle: Internals
-summary: 'Внутрішні компоненти Plugin: модель можливостей, володіння, контракти, конвеєр завантаження та допоміжні засоби runtime'
+summary: 'Внутрішні компоненти Plugin: модель можливостей, володіння, контракти, конвеєр завантаження та допоміжні засоби середовища виконання'
 title: Внутрішні компоненти Plugin
 x-i18n:
-    generated_at: "2026-04-26T07:49:37Z"
+    generated_at: "2026-04-27T08:08:26Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 16664d284a8bfbfcb9914bb012d1f36dfdd60406636d6bf4b011f76e886cb518
+    source_hash: 5b7622b361c6d19069106785f2b80cb3155e58f9a27a2fac9733e976d7c27f13
     source_path: plugins/architecture.md
     workflow: 15
 ---
 
-Це **поглиблений довідник з архітектури** системи Plugin в OpenClaw. Для практичних посібників почніть з однієї з наведених нижче сторінок.
+Це **детальний довідник з архітектури** системи Plugin в OpenClaw. Для практичних посібників почніть з однієї з наведених нижче спеціалізованих сторінок.
 
 <CardGroup cols={2}>
-  <Card title="Install and use plugins" icon="plug" href="/uk/tools/plugin">
-    Посібник для кінцевих користувачів щодо додавання, увімкнення та усунення несправностей Plugins.
+  <Card title="Встановлення та використання plugins" icon="plug" href="/uk/tools/plugin">
+    Посібник для кінцевих користувачів з додавання, увімкнення та усунення проблем із plugins.
   </Card>
-  <Card title="Building plugins" icon="rocket" href="/uk/plugins/building-plugins">
-    Навчальний посібник зі створення першого Plugin з найменшим працездатним manifest.
+  <Card title="Створення plugins" icon="rocket" href="/uk/plugins/building-plugins">
+    Навчальний посібник зі створення першого plugin з найменшим робочим маніфестом.
   </Card>
-  <Card title="Channel plugins" icon="comments" href="/uk/plugins/sdk-channel-plugins">
-    Створіть Plugin каналу обміну повідомленнями.
+  <Card title="Plugins каналів" icon="comments" href="/uk/plugins/sdk-channel-plugins">
+    Створіть plugin каналу обміну повідомленнями.
   </Card>
-  <Card title="Provider plugins" icon="microchip" href="/uk/plugins/sdk-provider-plugins">
-    Створіть Plugin постачальника моделей.
+  <Card title="Plugins provider-ів" icon="microchip" href="/uk/plugins/sdk-provider-plugins">
+    Створіть plugin provider-а моделей.
   </Card>
-  <Card title="SDK overview" icon="book" href="/uk/plugins/sdk-overview">
-    Довідник щодо import map і API реєстрації.
+  <Card title="Огляд SDK" icon="book" href="/uk/plugins/sdk-overview">
+    Довідник з мапи імпортів і API реєстрації.
   </Card>
 </CardGroup>
 
 ## Публічна модель можливостей
 
-Можливості — це публічна модель **нативних Plugins** всередині OpenClaw. Кожен нативний Plugin OpenClaw реєструється для одного або кількох типів можливостей:
+Можливості — це публічна модель **власних plugins** у межах OpenClaw. Кожен власний plugin OpenClaw реєструється для одного або кількох типів можливостей:
 
-| Можливість             | Метод реєстрації                                | Приклади Plugins                      |
-| ---------------------- | ----------------------------------------------- | ------------------------------------- |
-| Text inference         | `api.registerProvider(...)`                     | `openai`, `anthropic`                 |
-| Бекенд CLI inference   | `api.registerCliBackend(...)`                   | `openai`, `anthropic`                 |
-| Мовлення               | `api.registerSpeechProvider(...)`               | `elevenlabs`, `microsoft`             |
-| Realtime transcription | `api.registerRealtimeTranscriptionProvider(...)` | `openai`                              |
-| Realtime voice         | `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`                   |
-| Виявлення Gateway      | `api.registerGatewayDiscoveryService(...)`      | `bonjour`                             |
+| Можливість             | Метод реєстрації                              | Приклади plugins                    |
+| ---------------------- | --------------------------------------------- | ----------------------------------- |
+| Текстовий inference    | `api.registerProvider(...)`                   | `openai`, `anthropic`               |
+| CLI backend inference  | `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`                 |
+| Виявлення Gateway      | `api.registerGatewayDiscoveryService(...)`    | `bonjour`                           |
 
 <Note>
-Plugin, який реєструє нуль можливостей, але надає hooks, tools, служби виявлення або фонові служби, є **застарілим Plugin лише з hooks**. Цей шаблон усе ще повністю підтримується.
+Plugin, який реєструє нуль можливостей, але надає hooks, tools, служби виявлення або фонові служби, є **застарілим plugin лише з hooks**. Цей шаблон усе ще повністю підтримується.
 </Note>
 
 ### Позиція щодо зовнішньої сумісності
 
-Модель можливостей уже впроваджена в core і сьогодні використовується вбудованими/нативними Plugins, але сумісність із зовнішніми Plugins усе ще потребує вищої планки, ніж «це експортується, отже, це зафіксовано».
+Модель можливостей реалізована в core і вже сьогодні використовується вбудованими/власними plugins, але сумісність із зовнішніми plugins усе ще потребує вищої планки, ніж «це експортується, отже це незмінне».
 
-| Ситуація Plugin                                  | Рекомендація                                                                                     |
-| ------------------------------------------------ | ------------------------------------------------------------------------------------------------ |
-| Наявні зовнішні Plugins                          | Підтримуйте працездатність інтеграцій на основі hooks; це базовий рівень сумісності.            |
-| Нові вбудовані/нативні Plugins                   | Віддавайте перевагу явній реєстрації можливостей замість специфічних для постачальника втручань або нових дизайнів лише з hooks. |
-| Зовнішні Plugins, що переходять на реєстрацію можливостей | Дозволено, але вважайте допоміжні поверхні, специфічні для можливостей, такими, що розвиваються, якщо документація не позначає їх як стабільні. |
+| Ситуація з plugin                                | Рекомендація                                                                                    |
+| ------------------------------------------------ | ----------------------------------------------------------------------------------------------- |
+| Наявні зовнішні plugins                          | Підтримуйте інтеграції на основі hooks; це базовий рівень сумісності.                          |
+| Нові вбудовані/власні plugins                    | Віддавайте перевагу явній реєстрації можливостей замість vendor-специфічних звернень або нових дизайнів лише з hooks. |
+| Зовнішні plugins, що впроваджують реєстрацію можливостей | Дозволено, але вважайте допоміжні surface-и для конкретних можливостей такими, що еволюціонують, якщо документація не позначає їх як стабільні. |
 
-Реєстрація можливостей — це цільовий напрямок. Застарілі hooks залишаються найбезпечнішим шляхом без ламання для зовнішніх Plugins під час переходу. Експортовані допоміжні subpath не всі однакові — віддавайте перевагу вузьким задокументованим контрактам, а не випадковим допоміжним експортам.
+Реєстрація можливостей — це бажаний напрям розвитку. Застарілі hooks залишаються найбезпечнішим шляхом без порушення сумісності для зовнішніх plugins під час переходу. Експортовані допоміжні підшляхи не всі однакові — надавайте перевагу вузьким задокументованим контрактам, а не побічним експортам helper-ів.
 
 ### Форми Plugin
 
-OpenClaw класифікує кожен завантажений Plugin за формою на основі його фактичної поведінки реєстрації (а не лише статичних метаданих):
+OpenClaw класифікує кожен завантажений plugin за формою на основі його фактичної поведінки під час реєстрації, а не лише статичних метаданих:
 
 <AccordionGroup>
   <Accordion title="plain-capability">
-    Реєструє рівно один тип можливостей (наприклад, Plugin лише постачальника, як-от `mistral`).
+    Реєструє рівно один тип можливості (наприклад, plugin лише provider-а, як-от `mistral`).
   </Accordion>
   <Accordion title="hybrid-capability">
-    Реєструє кілька типів можливостей (наприклад, `openai` володіє text inference, speech, media understanding і image generation).
+    Реєструє кілька типів можливостей (наприклад, `openai` володіє текстовим inference, мовленням, розумінням медіа та генерацією зображень).
   </Accordion>
   <Accordion title="hook-only">
-    Реєструє лише hooks (типізовані або власні), без capabilities, tools, команд чи служб.
+    Реєструє лише hooks (типізовані або користувацькі), без можливостей, tools, команд або служб.
   </Accordion>
   <Accordion title="non-capability">
-    Реєструє tools, команди, служби або routes, але не capabilities.
+    Реєструє tools, команди, служби або routes, але не можливості.
   </Accordion>
 </AccordionGroup>
 
-Використовуйте `openclaw plugins inspect <id>`, щоб побачити форму Plugin і розкладку можливостей. Докладніше див. у [CLI reference](/uk/cli/plugins#inspect).
+Використовуйте `openclaw plugins inspect <id>`, щоб побачити форму plugin та розбивку за можливостями. Докладніше див. у [довіднику CLI](/uk/cli/plugins#inspect).
 
 ### Застарілі hooks
 
-Hook `before_agent_start` залишається підтримуваним шляхом сумісності для Plugins лише з hooks. Застарілі реальні Plugins усе ще від нього залежать.
+Hook `before_agent_start` залишається підтримуваним як шлях сумісності для plugins лише з hooks. Реальні застарілі plugins і далі від нього залежать.
 
-Напрямок:
+Напрям:
 
-- зберігати його працездатним
-- документувати як застарілий
-- для перевизначення моделі/постачальника віддавати перевагу `before_model_resolve`
-- для змінювання prompt віддавати перевагу `before_prompt_build`
-- видаляти лише після падіння реального використання й коли покриття фікстурами доведе безпечність міграції
+- зберігати його працездатність
+- документувати його як застарілий
+- для перевизначення моделі/provider-а віддавати перевагу `before_model_resolve`
+- для зміни prompt віддавати перевагу `before_prompt_build`
+- видаляти лише після зменшення реального використання й підтвердження безпеки міграції покриттям fixtures
 
 ### Сигнали сумісності
 
-Коли ви запускаєте `openclaw doctor` або `openclaw plugins inspect <id>`, ви можете побачити одну з таких позначок:
+Під час запуску `openclaw doctor` або `openclaw plugins inspect <id>` ви можете побачити одну з таких міток:
 
-| Сигнал                     | Значення                                                     |
-| -------------------------- | ------------------------------------------------------------ |
-| **config valid**           | Конфігурація коректно розбирається, і Plugins успішно визначаються |
+| Сигнал                    | Значення                                                     |
+| ------------------------- | ------------------------------------------------------------ |
+| **config valid**          | Config успішно парситься, а plugins успішно визначаються     |
 | **compatibility advisory** | Plugin використовує підтримуваний, але старіший шаблон (наприклад, `hook-only`) |
-| **legacy warning**         | Plugin використовує `before_agent_start`, який є застарілим  |
-| **hard error**             | Конфігурація недійсна або Plugin не вдалося завантажити      |
+| **legacy warning**        | Plugin використовує `before_agent_start`, який є застарілим  |
+| **hard error**            | Config недійсний або plugin не вдалося завантажити           |
 
-Ані `hook-only`, ані `before_agent_start` сьогодні не зламають ваш Plugin: `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 + discovery">
-    OpenClaw знаходить кандидатів у Plugins зі сконфігурованих шляхів, коренів workspace, глобальних коренів Plugins і вбудованих Plugins. Виявлення спочатку читає нативні manifests `openclaw.plugin.json` і manifests підтримуваних bundle.
+  <Step title="Маніфест + виявлення">
+    OpenClaw знаходить кандидатів у plugins у налаштованих шляхах, коренях робочого простору, глобальних коренях plugins і серед вбудованих plugins. Під час виявлення спочатку зчитуються власні маніфести `openclaw.plugin.json`, а потім підтримувані маніфести bundles.
   </Step>
-  <Step title="Enablement + validation">
-    Core вирішує, чи є виявлений Plugin увімкненим, вимкненим, заблокованим або вибраним для ексклюзивного слота, наприклад пам’яті.
+  <Step title="Увімкнення + валідація">
+    Core вирішує, чи є виявлений plugin увімкненим, вимкненим, заблокованим або вибраним для ексклюзивного слота, наприклад пам’яті.
   </Step>
-  <Step title="Runtime loading">
-    Нативні Plugins OpenClaw завантажуються в процесі через jiti і реєструють можливості в центральному реєстрі. Сумісні bundles нормалізуються в записи реєстру без імпорту коду runtime.
+  <Step title="Runtime-завантаження">
+    Власні plugins OpenClaw завантажуються в тому ж процесі через jiti і реєструють можливості в центральному реєстрі. Сумісні bundles нормалізуються в записи реєстру без імпортування runtime-коду.
   </Step>
-  <Step title="Surface consumption">
-    Решта OpenClaw читає реєстр, щоб відкрити tools, канали, налаштування постачальників, hooks, HTTP routes, CLI-команди та служби.
+  <Step title="Використання поверхонь">
+    Решта OpenClaw читає реєстр, щоб надавати tools, канали, налаштування provider-ів, hooks, HTTP-routes, CLI-команди та служби.
   </Step>
 </Steps>
 
-Зокрема для CLI Plugin виявлення кореневої команди поділено на дві фази:
+Зокрема для CLI plugins, виявлення кореневих команд поділено на дві фази:
 
-- метадані на етапі розбору походять з `registerCli(..., { descriptors: [...] })`
-- реальний модуль CLI Plugin може залишатися лінивим і реєструватися під час першого виклику
+- метадані на етапі парсингу надходять із `registerCli(..., { descriptors: [...] })`
+- справжній CLI-модуль plugin може залишатися лінивим і реєструватися під час першого виклику
 
-Це дає змогу тримати CLI-код, яким володіє Plugin, усередині Plugin, водночас дозволяючи OpenClaw резервувати імена кореневих команд до розбору.
+Це дає змогу зберігати код CLI, що належить plugin, усередині plugin, водночас дозволяючи OpenClaw резервувати імена кореневих команд до парсингу.
 
-Важлива межа дизайну:
+Важлива межа проєктування:
 
-- перевірка manifest/config має працювати на основі **метаданих manifest/schema** без виконання коду Plugin
-- виявлення нативних можливостей може завантажувати код входу довіреного Plugin, щоб побудувати знімок реєстру без активації
-- нативна поведінка runtime походить зі шляху модуля Plugin `register(api)` з `api.registrationMode === "full"`
+- валідація маніфесту/config має працювати на основі **метаданих маніфесту/схеми** без виконання коду plugin
+- виявлення власних можливостей може завантажувати код входу довіреного plugin для побудови знімка реєстру без активації
+- власна runtime-поведінка надходить із шляху `register(api)` модуля plugin, коли `api.registrationMode === "full"`
 
-Це розділення дозволяє OpenClaw перевіряти config, пояснювати відсутні/вимкнені Plugins і будувати підказки UI/schema до повної активації runtime.
+Цей поділ дозволяє OpenClaw перевіряти config, пояснювати відсутні/вимкнені plugins і будувати підказки для UI/схем до повної активації runtime.
+
+### Таблиця пошуку Plugin
+
+Під час запуску Gateway створюється `PluginLookUpTable` з індексу встановлених plugins і реєстру маніфестів для поточного знімка config. Ця таблиця містить лише метадані: вона зберігає ідентифікатори plugins, записи маніфестів, діагностику, мапи володіння, нормалізатор ідентифікаторів plugins і стартовий план plugins. Вона не містить завантажених модулів plugins, SDK provider-ів, вмісту package чи runtime-експортів.
+
+Таблиця пошуку утримує повторювані рішення під час запуску на швидкому шляху:
+
+- володіння каналами
+- відкладений запуск каналів
+- ідентифікатори plugins для запуску
+- володіння provider-ами та CLI backend-ами
+- володіння setup provider-ами, псевдонімами команд, provider-ами каталогів моделей і контрактами маніфестів
+
+Межа безпеки — це заміна знімка, а не мутація. Перебудовуйте таблицю, коли змінюються config, інвентар plugins, записи встановлення або політика збереженого індексу. Не сприймайте її як широкий змінний глобальний реєстр і не зберігайте необмежену кількість історичних таблиць. Runtime-завантаження plugins залишається окремим від метаданих таблиці пошуку, щоб застарілий runtime-стан не міг бути прихований за кешем метаданих.
 
 ### Планування активації
 
-Планування активації є частиною control plane. Викликачі можуть запитати, які Plugins стосуються конкретної команди, постачальника, каналу, route, harness агента або можливості, до завантаження ширших реєстрів runtime.
+Планування активації є частиною control plane. Викликаючі сторони можуть запитати, які plugins релевантні для конкретної команди, provider-а, каналу, route, harness агента або можливості, до завантаження ширших runtime-реєстрів.
 
-Планувальник зберігає сумісність із поточною поведінкою manifest:
+Планувальник зберігає сумісність із поточною поведінкою маніфестів:
 
-- поля `activation.*` є явними підказками для планувальника
-- `providers`, `channels`, `commandAliases`, `setup.providers`, `contracts.tools` і hooks залишаються запасним варіантом володіння в manifest
-- API планувальника лише з id залишається доступним для наявних викликачів
-- API плану повідомляє мітки причин, щоб діагностика могла відрізняти явні підказки від запасного варіанта володіння
+- поля `activation.*` — це явні підказки для планувальника
+- `providers`, `channels`, `commandAliases`, `setup.providers`, `contracts.tools` і hooks залишаються резервним варіантом володіння з боку маніфесту
+- API планувальника лише з ідентифікаторами залишається доступним для наявних викликачів
+- API плану повідомляє мітки причин, щоб діагностика могла відрізняти явні підказки від резервного визначення володіння
 
 <Warning>
-Не сприймайте `activation` як lifecycle hook або заміну `register(...)`. Це метадані, які використовуються для звуження завантаження. Віддавайте перевагу полям володіння, коли вони вже описують цей зв’язок; використовуйте `activation` лише для додаткових підказок планувальника.
+Не сприймайте `activation` як hook життєвого циклу або як заміну `register(...)`. Це метадані, які використовуються для звуження завантаження. Віддавайте перевагу полям володіння, коли вони вже описують зв’язок; використовуйте `activation` лише для додаткових підказок планувальнику.
 </Warning>
 
 ### Plugins каналів і спільний tool повідомлень
 
-Plugins каналів не повинні реєструвати окремий tool надсилання/редагування/реакції для звичайних дій чату. OpenClaw зберігає один спільний tool `message` у core, а Plugins каналів володіють специфічним для каналу виявленням і виконанням за ним.
+Plugins каналів не потрібно реєструвати окремий tool для send/edit/react для звичайних дій чату. OpenClaw зберігає один спільний tool `message` у core, а plugins каналів відповідають за специфічне для каналу виявлення та виконання за ним.
 
 Поточна межа така:
 
-- core володіє спільним host tool `message`, wiring prompt, веденням session/thread і диспетчеризацією виконання
-- Plugins каналів володіють scoped виявленням дій, виявленням можливостей і будь-якими фрагментами schema, специфічними для каналу
-- Plugins каналів володіють граматикою conversation сесії, специфічною для постачальника, наприклад тим, як id conversation кодують id thread або успадковуються від батьківських conversations
-- Plugins каналів виконують фінальну дію через свій adapter дій
+- core володіє хостом спільного tool `message`, wiring prompt-ів, обліком сесій/гілок і диспетчеризацією виконання
+- plugins каналів володіють виявленням scoped actions, виявленням можливостей і будь-якими фрагментами схеми, специфічними для каналу
+- plugins каналів володіють специфічною для provider-а граматикою розмов у сесіях, наприклад тим, як conversation id кодують thread id або успадковуються від батьківських conversations
+- plugins каналів виконують фінальну дію через свій action adapter
 
-Для Plugins каналів поверхнею SDK є `ChannelMessageActionAdapter.describeMessageTool(...)`. Цей уніфікований виклик виявлення дає Plugin змогу повертати видимі дії, можливості та внески у schema разом, щоб ці частини не розходилися.
+Для plugins каналів поверхнею SDK є `ChannelMessageActionAdapter.describeMessageTool(...)`. Цей уніфікований виклик виявлення дає plugin змогу повертати видимі actions, можливості та внески до схеми разом, щоб ці частини не розходилися.
 
-Коли параметр tool повідомлення, специфічний для каналу, містить джерело медіа, таке як локальний шлях або віддалена URL-адреса медіа, Plugin також має повертати `mediaSourceParams` з `describeMessageTool(...)`. Core використовує цей явний список для застосування нормалізації шляхів sandbox і підказок доступу до вихідних медіа без жорсткого кодування назв параметрів, якими володіє Plugin. Там варто віддавати перевагу картам у межах дії, а не одному плоскому списку на весь канал, щоб параметр медіа лише для профілю не нормалізувався для не пов’язаних дій, як-от `send`.
+Коли параметр специфічного для каналу tool повідомлень містить джерело медіа, наприклад локальний шлях або віддалений URL медіа, plugin також має повертати `mediaSourceParams` із `describeMessageTool(...)`. Core використовує цей явний список, щоб застосовувати нормалізацію шляхів sandbox і підказки доступу до вихідних медіа без жорсткого кодування назв параметрів, що належать plugin. Там слід віддавати перевагу мапам на рівні action, а не одному плоскому списку на весь канал, щоб параметр медіа лише для профілю не нормалізувався для не пов’язаних actions, таких як `send`.
 
-Core передає область runtime на цьому етапі виявлення. Важливі поля:
+Core передає runtime-scope до цього кроку виявлення. Важливі поля включають:
 
 - `accountId`
 - `currentChannelId`
@@ -193,57 +207,57 @@ Core передає область runtime на цьому етапі виявл
 - `agentId`
 - довірений вхідний `requesterSenderId`
 
-Це важливо для Plugins, чутливих до контексту. Канал може приховувати або відкривати дії повідомлень залежно від активного облікового запису, поточної кімнати/thread/message або довіреної особи-відправника запиту без жорсткого кодування специфічних для каналу гілок у core tool `message`.
+Це важливо для plugins, чутливих до контексту. Канал може приховувати або показувати дії повідомлень залежно від активного облікового запису, поточної кімнати/гілки/повідомлення або довіреної ідентичності запитувача без жорстко закодованих специфічних для каналу гілок у core tool `message`.
 
-Ось чому зміни маршрутизації embedded-runner усе ще є роботою Plugin: runner відповідає за передавання поточної ідентичності chat/session у межу виявлення Plugin, щоб спільний tool `message` відкривав правильну поверхню, якою володіє канал, для поточного ходу.
+Саме тому зміни маршрутизації embedded-runner усе ще належать до роботи plugin: runner відповідає за пересилання поточної ідентичності чату/сесії до межі виявлення plugin, щоб спільний tool `message` показував правильну поверхню, що належить каналу, для поточного ходу.
 
-Для допоміжних засобів виконання, якими володіє канал, вбудовані Plugins мають зберігати runtime виконання у своїх власних модулях extension. Core більше не володіє runtime дій повідомлень Discord, Slack, Telegram або WhatsApp у `src/agents/tools`. Ми не публікуємо окремі subpath `plugin-sdk/*-action-runtime`, і вбудовані Plugins мають імпортувати свій власний локальний код runtime безпосередньо зі своїх модулів extension.
+Для допоміжних засобів виконання, що належать каналу, вбудовані plugins мають зберігати runtime виконання у власних модулях extension. Core більше не володіє runtime-реалізаціями дій повідомлень для Discord, Slack, Telegram або WhatsApp у `src/agents/tools`. Ми не публікуємо окремі підшляхи `plugin-sdk/*-action-runtime`, а вбудовані plugins мають імпортувати власний локальний runtime-код безпосередньо зі своїх модулів, що належать extension.
 
-Та сама межа застосовується і до загальних швів SDK, названих на честь постачальників: core не повинен імпортувати специфічні для каналу зручні barrels для Slack, Discord, Signal, WhatsApp або подібних extensions. Якщо core потрібна певна поведінка, слід або використовувати власний barrel `api.ts` / `runtime-api.ts` вбудованого Plugin, або підняти цю потребу до вузької загальної можливості в спільному SDK.
+Та сама межа застосовується й до named SDK seams provider-ів загалом: core не повинен імпортувати специфічні для каналів convenience barrels для Slack, Discord, Signal, WhatsApp або подібних extensions. Якщо core потрібна певна поведінка, він має або використовувати власний barrel `api.ts` / `runtime-api.ts` вбудованого plugin, або підняти цю потребу до вузької узагальненої можливості в спільному SDK.
 
-Зокрема для опитувань є два шляхи виконання:
+Зокрема для опитувань існують два шляхи виконання:
 
 - `outbound.sendPoll` — це спільна базова лінія для каналів, які відповідають загальній моделі опитувань
-- `actions.handleAction("poll")` — це бажаний шлях для специфічної для каналу семантики опитувань або додаткових параметрів опитування
+- `actions.handleAction("poll")` — це бажаний шлях для специфічної семантики опитувань каналу або додаткових параметрів опитувань
 
-Тепер core відкладає спільний розбір опитувань до моменту, коли dispatch опитування через Plugin відхилить дію, щоб обробники опитувань, якими володіє Plugin, могли приймати специфічні для каналу поля опитування без блокування з боку загального парсера опитувань.
+Тепер Core відкладає спільний парсинг опитувань до моменту, коли dispatch plugin опитувань відхиляє дію, щоб обробники опитувань, що належать plugin, могли приймати специфічні для каналу поля опитувань без блокування загальним парсером опитувань на початку.
 
-Повну послідовність запуску див. у [Plugin architecture internals](/uk/plugins/architecture-internals).
+Див. [Внутрішні компоненти архітектури Plugin](/uk/plugins/architecture-internals), щоб переглянути повну послідовність запуску.
 
 ## Модель володіння можливостями
 
-OpenClaw розглядає нативний Plugin як межу володіння для **компанії** або **можливості**, а не як випадковий набір не пов’язаних інтеграцій.
+OpenClaw розглядає власний plugin як межу володіння для **компанії** або **функції**, а не як набір не пов’язаних інтеграцій.
 
 Це означає:
 
-- Plugin компанії зазвичай має володіти всіма поверхнями цієї компанії в OpenClaw
-- Plugin можливості зазвичай має володіти повною поверхнею можливості, яку він додає
-- канали мають споживати спільні можливості core замість того, щоб спеціальним чином повторно реалізовувати поведінку постачальника
+- plugin компанії зазвичай повинен володіти всіма поверхнями цієї компанії, орієнтованими на OpenClaw
+- plugin функції зазвичай повинен володіти повною поверхнею функції, яку він додає
+- канали повинні використовувати спільні можливості core замість того, щоб щоразу заново реалізовувати поведінку provider-а
 
 <AccordionGroup>
-  <Accordion title="Постачальник із кількома можливостями">
-    `openai` володіє text inference, speech, realtime voice, media understanding і image generation. `google` володіє text inference, а також media understanding, image generation і web search. `qwen` володіє text inference, а також media understanding і video generation.
+  <Accordion title="Vendor multi-capability">
+    `openai` володіє текстовим inference, мовленням, голосом у реальному часі, розумінням медіа та генерацією зображень. `google` володіє текстовим inference, а також розумінням медіа, генерацією зображень і вебпошуком. `qwen` володіє текстовим inference, а також розумінням медіа й генерацією відео.
   </Accordion>
-  <Accordion title="Постачальник з однією можливістю">
-    `elevenlabs` і `microsoft` володіють speech; `firecrawl` володіє web-fetch; `minimax` / `mistral` / `moonshot` / `zai` володіють бекендами media-understanding.
+  <Accordion title="Vendor single-capability">
+    `elevenlabs` і `microsoft` володіють мовленням; `firecrawl` володіє web-fetch; `minimax` / `mistral` / `moonshot` / `zai` володіють backends розуміння медіа.
   </Accordion>
-  <Accordion title="Plugin можливості">
-    `voice-call` володіє transport викликів, tools, CLI, routes і мостом медіапотоків Twilio, але споживає спільні можливості speech, realtime transcription і realtime voice замість прямого імпорту Plugins постачальників.
+  <Accordion title="Feature plugin">
+    `voice-call` володіє transport викликів, tools, CLI, routes і мостом медіапотоків Twilio, але використовує спільні можливості мовлення, транскрибування в реальному часі та голосу в реальному часі замість прямого імпорту plugins vendor-ів.
   </Accordion>
 </AccordionGroup>
 
-Цільовий кінцевий стан такий:
+Бажаний кінцевий стан:
 
-- OpenAI живе в одному Plugin, навіть якщо він охоплює текстові моделі, speech, зображення та майбутнє відео
-- інший постачальник може так само зробити це для власної області
-- канали не повинні зважати, який Plugin постачальника володіє provider; вони споживають спільний контракт можливостей, який відкриває core
+- OpenAI знаходиться в одному plugin, навіть якщо він охоплює текстові моделі, мовлення, зображення та майбутнє відео
+- інший vendor може робити те саме для власної області
+- каналам не важливо, який plugin vendor-а володіє provider-ом; вони використовують спільний контракт можливостей, який надає core
 
 Ось ключова відмінність:
 
 - **plugin** = межа володіння
-- **capability** = контракт core, який можуть реалізовувати або споживати кілька Plugins
+- **capability** = контракт core, який кілька plugins можуть реалізовувати або використовувати
 
-Тому якщо OpenClaw додає нову область, як-от відео, перше питання не таке: «який постачальник має жорстко закодувати обробку відео?» Перше питання таке: «який контракт можливостей відео в core?» Щойно такий контракт з’явиться, Plugins постачальників зможуть реєструватися щодо нього, а Plugins каналів/можливостей — споживати його.
+Тому якщо OpenClaw додає нову доменну область, наприклад відео, перше запитання не таке: «який provider має жорстко закодувати обробку відео?» Перше запитання таке: «який контракт можливості відео в core?» Після появи цього контракту plugins vendor-ів можуть реєструватися для нього, а plugins каналів/функцій можуть його використовувати.
 
 Якщо можливість ще не існує, правильний крок зазвичай такий:
 
@@ -251,46 +265,46 @@ OpenClaw розглядає нативний Plugin як межу володін
   <Step title="Визначте можливість">
     Визначте відсутню можливість у core.
   </Step>
-  <Step title="Відкрийте її через SDK">
-    Відкрийте її через API/runtime Plugin у типізованому вигляді.
+  <Step title="Експортуйте через SDK">
+    Надайте її через plugin API/runtime у типізований спосіб.
   </Step>
-  <Step title="Під’єднайте споживачів">
-    Під’єднайте канали/можливості до цієї можливості.
+  <Step title="Підключіть споживачів">
+    Підключіть канали/функції до цієї можливості.
   </Step>
-  <Step title="Реалізації постачальників">
-    Дозвольте Plugins постачальників реєструвати реалізації.
+  <Step title="Реалізації vendor-ів">
+    Дозвольте plugins vendor-ів реєструвати реалізації.
   </Step>
 </Steps>
 
-Це зберігає явне володіння й водночас уникає поведінки core, яка залежить від одного постачальника або одноразового специфічного для Plugin шляху коду.
+Це зберігає явне володіння й водночас уникає поведінки core, що залежить від одного vendor-а або одноразового специфічного шляху коду plugin.
 
 ### Шарування можливостей
 
-Використовуйте таку ментальну модель, коли вирішуєте, де має розміщуватися код:
+Використовуйте цю ментальну модель, коли вирішуєте, де має розміщуватися код:
 
 <Tabs>
   <Tab title="Шар можливостей core">
     Спільна оркестрація, політика, fallback, правила злиття config, семантика доставки та типізовані контракти.
   </Tab>
-  <Tab title="Шар Plugin постачальника">
-    Специфічні для постачальника API, auth, каталоги моделей, синтез мовлення, генерація зображень, майбутні відеобекенди, endpoint-и використання.
+  <Tab title="Шар plugin vendor-а">
+    Специфічні для vendor-а API, автентифікація, каталоги моделей, синтез мовлення, генерація зображень, майбутні backends відео, endpoints використання.
   </Tab>
-  <Tab title="Шар Plugin каналу/можливості">
-    Інтеграція Slack/Discord/voice-call/тощо, яка споживає можливості core і представляє їх на певній поверхні.
+  <Tab title="Шар plugin каналу/функції">
+    Інтеграція Slack/Discord/voice-call тощо, яка використовує можливості core і представляє їх на певній поверхні.
   </Tab>
 </Tabs>
 
 Наприклад, TTS має таку форму:
 
-- core володіє політикою TTS під час відповіді, порядком fallback, prefs і доставкою в канал
+- core володіє політикою TTS під час відповіді, порядком fallback, prefs і доставкою в канали
 - `openai`, `elevenlabs` і `microsoft` володіють реалізаціями синтезу
-- `voice-call` споживає допоміжний засіб runtime телекомунікаційного TTS
+- `voice-call` використовує helper runtime TTS для телефонії
 
-Тому ж шаблону слід віддавати перевагу і для майбутніх можливостей.
+Тому самому шаблону слід надавати перевагу й для майбутніх можливостей.
 
-### Приклад Plugin компанії з кількома можливостями
+### Приклад plugin компанії з кількома можливостями
 
-Plugin компанії має виглядати цілісно ззовні. Якщо OpenClaw має спільні контракти для моделей, speech, realtime transcription, realtime voice, media understanding, image generation, video generation, web fetch і web search, постачальник може володіти всіма своїми поверхнями в одному місці:
+Plugin компанії має виглядати цілісно ззовні. Якщо OpenClaw має спільні контракти для моделей, мовлення, транскрибування в реальному часі, голосу в реальному часі, розуміння медіа, генерації зображень, генерації відео, web fetch і вебпошуку, vendor може володіти всіма своїми поверхнями в одному місці:
 
 ```ts
 import type { OpenClawPluginDefinition } from "openclaw/plugin-sdk/plugin-entry";
@@ -344,126 +358,126 @@ const plugin: OpenClawPluginDefinition = {
 export default plugin;
 ```
 
-Важливі не точні назви допоміжних засобів. Важлива форма:
+Важливі не точні назви helper-ів. Важлива форма:
 
-- один Plugin володіє поверхнею постачальника
+- один plugin володіє поверхнею vendor-а
 - core усе ще володіє контрактами можливостей
-- канали й Plugins можливостей споживають допоміжні засоби `api.runtime.*`, а не код постачальника
-- контрактні тести можуть перевіряти, що Plugin зареєстрував можливості, якими він заявляє, що володіє
+- plugins каналів і функцій використовують helper-и `api.runtime.*`, а не код vendor-а
+- contract tests можуть перевіряти, що plugin зареєстрував можливості, якими він заявляє володіти
 
 ### Приклад можливості: розуміння відео
 
-OpenClaw уже розглядає розуміння зображень/аудіо/відео як одну спільну можливість. Та сама модель володіння застосовується і тут:
+OpenClaw уже розглядає розуміння зображень/аудіо/відео як одну спільну можливість. Та сама модель володіння застосовується й тут:
 
 <Steps>
   <Step title="Core визначає контракт">
     Core визначає контракт media-understanding.
   </Step>
-  <Step title="Plugins постачальників реєструються">
-    Plugins постачальників реєструють `describeImage`, `transcribeAudio` і `describeVideo`, де це застосовно.
+  <Step title="Plugins vendor-ів реєструються">
+    Plugins vendor-ів реєструють `describeImage`, `transcribeAudio` і `describeVideo`, де це доречно.
   </Step>
   <Step title="Споживачі використовують спільну поведінку">
-    Канали й Plugins можливостей споживають спільну поведінку core замість прямого під’єднання до коду постачальника.
+    Plugins каналів і функцій використовують спільну поведінку core замість прямого підключення до коду vendor-а.
   </Step>
 </Steps>
 
-Це дозволяє не вшивати в core припущення одного постачальника щодо відео. Plugin володіє поверхнею постачальника; core володіє контрактом можливостей і поведінкою fallback.
+Це не дозволяє вбудовувати припущення одного provider-а про відео в core. Plugin володіє поверхнею vendor-а; core володіє контрактом можливості та fallback-поведінкою.
 
-Генерація відео вже використовує ту саму послідовність: core володіє типізованим контрактом можливостей і допоміжним засобом runtime, а Plugins постачальників реєструють щодо нього реалізації `api.registerVideoGenerationProvider(...)`.
+Генерація відео вже використовує ту саму послідовність: core володіє типізованим контрактом можливості та helper-ом runtime, а plugins vendor-ів реєструють для нього реалізації `api.registerVideoGenerationProvider(...)`.
 
 Потрібен конкретний контрольний список розгортання? Див. [Capability Cookbook](/uk/plugins/architecture).
 
-## Контракти та примусове дотримання
+## Контракти та забезпечення виконання
 
-Поверхня API Plugin навмисно типізована й централізована в `OpenClawPluginApi`. Цей контракт визначає підтримувані точки реєстрації та допоміжні засоби runtime, на які може покладатися Plugin.
+Поверхня plugin API навмисно типізована й централізована в `OpenClawPluginApi`. Цей контракт визначає підтримувані точки реєстрації та helper-и runtime, на які може покладатися plugin.
 
 Чому це важливо:
 
-- автори Plugins отримують один стабільний внутрішній стандарт
-- core може відхиляти дублювання володіння, наприклад коли два Plugins реєструють той самий id постачальника
-- під час запуску можна показувати практичні діагностичні повідомлення для некоректної реєстрації
-- контрактні тести можуть забезпечувати володіння вбудованих Plugins і запобігати непомітному дрейфу
+- автори plugins отримують єдиний стабільний внутрішній стандарт
+- core може відхиляти дубльоване володіння, наприклад коли два plugins реєструють той самий ідентифікатор provider-а
+- під час запуску можна показувати діагностику з конкретними діями для некоректної реєстрації
+- contract tests можуть забезпечувати володіння вбудованими plugins і запобігати непомітному дрейфу
 
-Є два шари примусового дотримання:
+Існує два рівні забезпечення виконання:
 
 <AccordionGroup>
-  <Accordion title="Примусове дотримання реєстрації під час runtime">
-    Реєстр Plugins перевіряє реєстрації під час завантаження Plugins. Приклади: дубльовані id постачальників, дубльовані id постачальників speech і некоректні реєстрації призводять до діагностики Plugins замість невизначеної поведінки.
+  <Accordion title="Забезпечення виконання реєстрації під час runtime">
+    Реєстр plugin перевіряє реєстрації під час завантаження plugins. Наприклад, дубльовані ідентифікатори provider-ів, дубльовані ідентифікатори provider-ів мовлення й некоректні реєстрації породжують діагностику plugin замість невизначеної поведінки.
   </Accordion>
-  <Accordion title="Контрактні тести">
-    Вбудовані Plugins фіксуються в контрактних реєстрах під час тестових запусків, щоб OpenClaw міг явно перевіряти володіння. Сьогодні це використовується для постачальників моделей, постачальників speech, постачальників web search і володіння вбудованою реєстрацією.
+  <Accordion title="Contract tests">
+    Вбудовані plugins фіксуються в contract registries під час виконання тестів, щоб OpenClaw міг явно перевіряти володіння. Сьогодні це використовується для provider-ів моделей, provider-ів мовлення, provider-ів вебпошуку та володіння реєстрацією вбудованих компонентів.
   </Accordion>
 </AccordionGroup>
 
-Практичний ефект полягає в тому, що OpenClaw заздалегідь знає, який Plugin якою поверхнею володіє. Це дає змогу core і каналам безшовно поєднуватися, тому що володіння оголошене, типізоване й придатне до тестування, а не неявне.
+Практичний ефект полягає в тому, що OpenClaw заздалегідь знає, який plugin володіє якою поверхнею. Це дозволяє core і каналам безшовно компонуватися, оскільки володіння оголошене, типізоване й придатне для тестування, а не неявне.
 
-### Що належить до контракту
+### Що має належати до контракту
 
 <Tabs>
   <Tab title="Хороші контракти">
     - типізовані
-    - малі
-    - специфічні для можливостей
+    - невеликі
+    - специфічні для можливості
     - належать core
-    - повторно використовуються кількома Plugins
-    - можуть споживатися каналами/можливостями без знання постачальника
+    - повторно використовуються кількома plugins
+    - можуть використовуватися каналами/функціями без знання про vendor-а
   </Tab>
   <Tab title="Погані контракти">
-    - специфічна для постачальника політика, прихована в core
-    - одноразові аварійні виходи Plugin, які оминають реєстр
-    - код каналу, який напряму звертається до реалізації постачальника
-    - ad hoc об’єкти runtime, які не є частиною `OpenClawPluginApi` або `api.runtime`
+    - специфічна для vendor-а політика, прихована в core
+    - одноразові обхідні шляхи plugin, що обходять реєстр
+    - код каналу, який напряму звертається до реалізації vendor-а
+    - ad hoc runtime-об’єкти, які не є частиною `OpenClawPluginApi` або `api.runtime`
   </Tab>
 </Tabs>
 
-Якщо є сумніви, піднімайте рівень абстракції: спочатку визначте можливість, а вже потім дозвольте Plugins підключатися до неї.
+Якщо є сумніви, піднімайте рівень абстракції: спочатку визначте можливість, а потім дозвольте plugins підключатися до неї.
 
 ## Модель виконання
 
-Нативні Plugins OpenClaw виконуються **в процесі** разом із Gateway. Вони не ізольовані. Завантажений нативний Plugin має ту саму межу довіри на рівні процесу, що й код core.
+Власні plugins OpenClaw працюють **у межах того самого процесу** разом із Gateway. Вони не ізольовані. Завантажений власний plugin має ту саму межу довіри на рівні процесу, що й код core.
 
 <Warning>
 Наслідки:
 
-- нативний Plugin може реєструвати tools, обробники мережі, hooks і служби
-- помилка в нативному Plugin може призвести до збою або дестабілізації gateway
-- зловмисний нативний Plugin еквівалентний довільному виконанню коду всередині процесу OpenClaw
+- власний plugin може реєструвати tools, мережеві handlers, hooks і служби
+- помилка власного plugin може зламати або дестабілізувати gateway
+- зловмисний власний plugin еквівалентний довільному виконанню коду всередині процесу OpenClaw
   </Warning>
 
-Сумісні bundles за замовчуванням безпечніші, тому що зараз OpenClaw розглядає їх як пакети метаданих/вмісту. У поточних релізах це переважно означає вбудовані Skills.
+Сумісні bundles за замовчуванням безпечніші, оскільки наразі OpenClaw розглядає їх як пакети метаданих/контенту. У поточних релізах це здебільшого означає вбудовані Skills.
 
-Для невбудованих Plugins використовуйте allowlist-и й явні шляхи встановлення/завантаження. Сприймайте Plugins workspace як код для часу розробки, а не як типові production-налаштування.
+Використовуйте allowlists і явні шляхи встановлення/завантаження для невбудованих plugins. Розглядайте plugins робочого простору як код для часу розробки, а не як типові виробничі налаштування.
 
-Для імен пакетів вбудованого workspace зберігайте id Plugin прив’язаним до npm-імені: типово `@openclaw/<id>` або із затвердженим типізованим суфіксом, як-от `-provider`, `-plugin`, `-speech`, `-sandbox` чи `-media-understanding`, коли пакет навмисно відкриває вужчу роль Plugin.
+Для назв package у вбудованому робочому просторі зберігайте прив’язку ідентифікатора plugin до npm-імені: `@openclaw/<id>` за замовчуванням або затверджений типізований суфікс, такий як `-provider`, `-plugin`, `-speech`, `-sandbox` чи `-media-understanding`, коли package навмисно надає вужчу роль plugin.
 
 <Note>
 **Примітка щодо довіри:**
 
-- `plugins.allow` довіряє **id Plugin**, а не походженню джерела.
-- Plugin workspace з тим самим id, що й у вбудованого Plugin, навмисно затіняє вбудовану копію, коли такий Plugin workspace увімкнено/додано до allowlist.
+- `plugins.allow` довіряє **ідентифікаторам plugin**, а не походженню джерела.
+- Plugin робочого простору з тим самим ідентифікатором, що й у вбудованого plugin, навмисно затіняє вбудовану копію, коли цей plugin робочого простору увімкнений/доданий до allowlist.
 - Це нормально й корисно для локальної розробки, тестування патчів і hotfix-ів.
-- Довіра до вбудованого Plugin визначається зі знімка джерела — manifest і коду на диску під час завантаження — а не з метаданих встановлення. Пошкоджений або підмінений запис встановлення не може непомітно розширити поверхню довіри вбудованого Plugin понад те, що заявляє фактичне джерело.
+- Довіра до вбудованого plugin визначається зі знімка джерела — маніфесту й коду на диску під час завантаження — а не з метаданих встановлення. Пошкоджений або підмінений запис встановлення не може непомітно розширити поверхню довіри вбудованого plugin понад те, що фактично заявляє джерело.
   </Note>
 
 ## Межа експорту
 
-OpenClaw експортує можливості, а не зручні засоби реалізації.
+OpenClaw експортує можливості, а не зручні реалізації.
 
-Зберігайте публічною реєстрацію можливостей. Скорочуйте експорти допоміжних засобів, що не є частиною контракту:
+Зберігайте публічною реєстрацію можливостей. Скорочуйте експорти helper-ів, які не є частиною контракту:
 
-- subpath допоміжних засобів, специфічних для вбудованих Plugins
-- subpath plumbing runtime, які не призначені бути публічним API
-- специфічні для постачальника зручні допоміжні засоби
-- допоміжні засоби setup/onboarding, які є деталями реалізації
+- підшляхи helper-ів, специфічних для вбудованих plugins
+- підшляхи runtime plumbing, не призначені як публічний API
+- специфічні для vendor-а convenience helper-и
+- helper-и setup/onboarding, які є деталями реалізації
 
-Деякі subpath допоміжних засобів вбудованих Plugins усе ще залишаються в згенерованій export map SDK для сумісності й підтримки вбудованих Plugins. Поточні приклади включають `plugin-sdk/feishu`, `plugin-sdk/feishu-setup`, `plugin-sdk/zalo`, `plugin-sdk/zalo-setup` і кілька швів `plugin-sdk/matrix*`. Сприймайте їх як зарезервовані експорти деталей реалізації, а не як рекомендований шаблон SDK для нових сторонніх Plugins.
+Деякі підшляхи helper-ів вбудованих plugins усе ще залишаються в згенерованій мапі експорту SDK для сумісності та супроводу вбудованих plugins. Поточні приклади: `plugin-sdk/feishu`, `plugin-sdk/feishu-setup`, `plugin-sdk/zalo`, `plugin-sdk/zalo-setup` і кілька seams `plugin-sdk/matrix*`. Розглядайте їх як зарезервовані експорти деталей реалізації, а не як рекомендований шаблон SDK для нових сторонніх plugins.
 
 ## Внутрішні компоненти та довідка
 
-Щодо конвеєра завантаження, моделі реєстру, хуків runtime постачальника, HTTP routes Gateway, schema tool повідомлень, визначення цілі каналу, каталогів постачальників, Plugins context engine і посібника з додавання нової можливості див. [Plugin architecture internals](/uk/plugins/architecture-internals).
+Щоб дізнатися про конвеєр завантаження, модель реєстру, runtime hooks provider-ів, HTTP-routes Gateway, схеми tool повідомлень, визначення цілей каналів, каталоги provider-ів, plugins рушія контексту та посібник з додавання нової можливості, див. [Внутрішні компоненти архітектури Plugin](/uk/plugins/architecture-internals).
 
 ## Пов’язане
 
-- [Building plugins](/uk/plugins/building-plugins)
-- [Plugin manifest](/uk/plugins/manifest)
-- [Plugin SDK setup](/uk/plugins/sdk-setup)
+- [Створення plugins](/uk/plugins/building-plugins)
+- [Маніфест Plugin](/uk/plugins/manifest)
+- [Налаштування SDK Plugin](/uk/plugins/sdk-setup)

docs/uk/plugins/sdk-subpaths.md

@@ -1,245 +1,247 @@
 ---
 read_when:
-    - Вибір правильного підшляху plugin-sdk для імпорту плагіна
-    - Аудит підшляхів bundled-plugin і допоміжних поверхонь
-summary: 'Каталог підшляхів Plugin SDK: які імпорти де знаходяться, згруповано за областями'
+    - Вибір правильного підшляху plugin-sdk для імпорту Plugin
+    - Аудит підшляхів вбудованих Plugin і допоміжних поверхонь
+summary: 'Каталог підшляхів Plugin SDK: які імпорти де розміщені, згруповано за областями'
 title: Підшляхи Plugin SDK
 x-i18n:
-    generated_at: "2026-04-26T09:19:30Z"
+    generated_at: "2026-04-27T08:08:42Z"
     model: gpt-5.4
     provider: openai
-    source_hash: fcb49ee51301b79985d43470cd8c149c858e79d685908605317de253121d4736
+    source_hash: 7ab23b42341d981e4ad85027682be603048a0a57d19604fe9024767ffbb78c50
     source_path: plugins/sdk-subpaths.md
     workflow: 15
 ---
 
   Plugin SDK доступний як набір вузьких підшляхів у `openclaw/plugin-sdk/`.
-  Ця сторінка містить каталог найуживаніших підшляхів, згрупованих за призначенням. Згенерований
-  повний список із понад 200 підшляхів знаходиться в `scripts/lib/plugin-sdk-entrypoints.json`;
-  зарезервовані допоміжні підшляхи bundled-plugin також наведені там, але є деталлю
-  реалізації, якщо лише сторінка документації явно не просуває їх.
+  На цій сторінці наведено каталог найуживаніших підшляхів, згрупованих за призначенням. Згенерований
+  повний список із понад 200 підшляхів розміщено в `scripts/lib/plugin-sdk-entrypoints.json`;
+  зарезервовані допоміжні підшляхи для вбудованих Plugin також наведено там, але вони є
+  деталями реалізації, якщо лише якась сторінка документації прямо не рекомендує їх.
 
-  Посібник з розробки плагінів дивіться в [Огляд Plugin SDK](/uk/plugins/sdk-overview).
+  Посібник з розробки Plugin див. у [Огляд Plugin SDK](/uk/plugins/sdk-overview).
 
-  ## Точка входу плагіна
+  ## Точка входу Plugin
 
-  | Підшлях                    | Ключові експорти                                                                                                                      |
-  | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
-  | `plugin-sdk/plugin-entry`   | `definePluginEntry`                                                                                                                   |
-  | `plugin-sdk/core`           | `defineChannelPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase`, `defineSetupPluginEntry`, `buildChannelConfigSchema` |
-  | `plugin-sdk/config-schema`  | `OpenClawSchema`                                                                                                                      |
-  | `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry`                                                                                                     |
+  | Підшлях                       | Ключові експорти                                                                                                                                       |
+  | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
+  | `plugin-sdk/plugin-entry`     | `definePluginEntry`                                                                                                                                    |
+  | `plugin-sdk/core`             | `defineChannelPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase`, `defineSetupPluginEntry`, `buildChannelConfigSchema`                 |
+  | `plugin-sdk/config-schema`    | `OpenClawSchema`                                                                                                                                       |
+  | `plugin-sdk/provider-entry`   | `defineSingleProviderPluginEntry`                                                                                                                      |
+  | `plugin-sdk/migration`        | Допоміжні функції елементів провайдера міграції, такі як `createMigrationItem`, константи причин, маркери статусу елементів, допоміжні функції редагування та `summarizeMigrationItems` |
+  | `plugin-sdk/migration-runtime` | Допоміжні функції міграції для середовища виконання, такі як `copyMigrationFileItem` і `writeMigrationReport`                                         |
 
   <AccordionGroup>
   <Accordion title="Підшляхи каналів">
     | Підшлях | Ключові експорти |
     | --- | --- |
     | `plugin-sdk/channel-core` | `defineChannelPluginEntry`, `defineSetupPluginEntry`, `createChatChannelPlugin`, `createChannelPluginBase` |
-    | `plugin-sdk/config-schema` | Експорт кореневої Zod-схеми `openclaw.json` (`OpenClawSchema`) |
+    | `plugin-sdk/config-schema` | Експорт кореневої схеми Zod для `openclaw.json` (`OpenClawSchema`) |
     | `plugin-sdk/channel-setup` | `createOptionalChannelSetupSurface`, `createOptionalChannelSetupAdapter`, `createOptionalChannelSetupWizard`, а також `DEFAULT_ACCOUNT_ID`, `createTopLevelChannelDmPolicy`, `setSetupChannelEnabled`, `splitSetupEntries` |
-    | `plugin-sdk/setup` | Спільні допоміжні засоби майстра налаштування, підказки allowlist, будівники статусу налаштування |
+    | `plugin-sdk/setup` | Спільні допоміжні функції майстра налаштування, запити allowlist, побудовники статусу налаштування |
     | `plugin-sdk/setup-runtime` | `createPatchedAccountSetupAdapter`, `createEnvPatchedAccountSetupAdapter`, `createSetupInputPresenceValidator`, `noteChannelLookupFailure`, `noteChannelLookupSummary`, `promptResolvedAllowFrom`, `splitSetupEntries`, `createAllowlistSetupWizardProxy`, `createDelegatedSetupWizardProxy` |
     | `plugin-sdk/setup-adapter-runtime` | `createEnvPatchedAccountSetupAdapter` |
     | `plugin-sdk/setup-tools` | `formatCliCommand`, `detectBinary`, `extractArchive`, `resolveBrewExecutable`, `formatDocsLink`, `CONFIG_DIR` |
-    | `plugin-sdk/account-core` | Допоміжні засоби для багатокористувацької конфігурації/керування шлюзами дій, допоміжні засоби резервного переходу до облікового запису за замовчуванням |
-    | `plugin-sdk/account-id` | `DEFAULT_ACCOUNT_ID`, допоміжні засоби нормалізації ID облікового запису |
-    | `plugin-sdk/account-resolution` | Допоміжні засоби пошуку облікового запису + резервного переходу за замовчуванням |
-    | `plugin-sdk/account-helpers` | Вузькі допоміжні засоби для списку облікових записів/дій з обліковими записами |
+    | `plugin-sdk/account-core` | Допоміжні функції для конфігурації/шлюзу дій мультиакаунтів, допоміжні функції резервного типового акаунта |
+    | `plugin-sdk/account-id` | `DEFAULT_ACCOUNT_ID`, допоміжні функції нормалізації ID акаунта |
+    | `plugin-sdk/account-resolution` | Допоміжні функції пошуку акаунта та резервного типового значення |
+    | `plugin-sdk/account-helpers` | Вузькі допоміжні функції для списку акаунтів/дій акаунтів |
     | `plugin-sdk/channel-pairing` | `createChannelPairingController` |
     | `plugin-sdk/channel-reply-pipeline` | `createChannelReplyPipeline` |
     | `plugin-sdk/channel-config-helpers` | `createHybridChannelConfigAdapter` |
     | `plugin-sdk/channel-config-schema` | Типи схеми конфігурації каналу |
-    | `plugin-sdk/telegram-command-config` | Допоміжні засоби нормалізації/валідації користувацьких команд Telegram з резервним переходом до bundled-contract |
-    | `plugin-sdk/command-gating` | Вузькі допоміжні засоби шлюзу авторизації команд |
+    | `plugin-sdk/telegram-command-config` | Допоміжні функції нормалізації/валідації користувацьких команд Telegram із резервною підтримкою контракту вбудованих компонентів |
+    | `plugin-sdk/command-gating` | Вузькі допоміжні функції шлюзу авторизації команд |
     | `plugin-sdk/channel-policy` | `resolveChannelGroupRequireMention` |
-    | `plugin-sdk/channel-lifecycle` | `createAccountStatusSink`, допоміжні засоби життєвого циклу/фіналізації потоків чернеток |
-    | `plugin-sdk/inbound-envelope` | Спільні допоміжні засоби для маршрутів вхідних повідомлень + побудови envelope |
-    | `plugin-sdk/inbound-reply-dispatch` | Спільні допоміжні засоби запису та диспетчеризації вхідних відповідей |
-    | `plugin-sdk/messaging-targets` | Допоміжні засоби розбору/зіставлення цілей |
-    | `plugin-sdk/outbound-media` | Спільні допоміжні засоби завантаження вихідних медіа |
-    | `plugin-sdk/outbound-send-deps` | Полегшений пошук залежностей надсилання вихідних повідомлень для адаптерів каналів |
-    | `plugin-sdk/outbound-runtime` | Допоміжні засоби доставки вихідних повідомлень, ідентифікації, делегування надсилання, сесій, форматування та планування payload |
-    | `plugin-sdk/poll-runtime` | Вузькі допоміжні засоби нормалізації опитувань |
-    | `plugin-sdk/thread-bindings-runtime` | Допоміжні засоби життєвого циклу прив’язок потоків і адаптерів |
-    | `plugin-sdk/agent-media-payload` | Застарілий будівник payload медіа агента |
-    | `plugin-sdk/conversation-runtime` | Допоміжні засоби для прив’язок розмов/потоків, pairing і налаштованих прив’язок |
-    | `plugin-sdk/runtime-config-snapshot` | Допоміжний засіб знімка конфігурації runtime |
-    | `plugin-sdk/runtime-group-policy` | Допоміжні засоби визначення групової політики runtime |
-    | `plugin-sdk/channel-status` | Спільні допоміжні засоби знімка/підсумку статусу каналу |
+    | `plugin-sdk/channel-lifecycle` | `createAccountStatusSink`, допоміжні функції життєвого циклу/фіналізації потоку чернеток |
+    | `plugin-sdk/inbound-envelope` | Спільні допоміжні функції маршрутизації вхідних даних і побудови конвертів |
+    | `plugin-sdk/inbound-reply-dispatch` | Спільні допоміжні функції запису та диспетчеризації вхідних відповідей |
+    | `plugin-sdk/messaging-targets` | Допоміжні функції розбору/зіставлення цілей |
+    | `plugin-sdk/outbound-media` | Спільні допоміжні функції завантаження вихідних медіа |
+    | `plugin-sdk/outbound-send-deps` | Полегшений пошук залежностей надсилання вихідних даних для адаптерів каналів |
+    | `plugin-sdk/outbound-runtime` | Допоміжні функції доставки вихідних даних, ідентичності, делегата надсилання, сесій, форматування та планування payload |
+    | `plugin-sdk/poll-runtime` | Вузькі допоміжні функції нормалізації опитувань |
+    | `plugin-sdk/thread-bindings-runtime` | Допоміжні функції життєвого циклу прив’язок потоків і адаптерів |
+    | `plugin-sdk/agent-media-payload` | Застарілий побудовник медіа-payload агента |
+    | `plugin-sdk/conversation-runtime` | Допоміжні функції прив’язки розмов/потоків, спарювання та налаштованих прив’язок |
+    | `plugin-sdk/runtime-config-snapshot` | Допоміжна функція знімка конфігурації середовища виконання |
+    | `plugin-sdk/runtime-group-policy` | Допоміжні функції визначення групової політики в середовищі виконання |
+    | `plugin-sdk/channel-status` | Спільні допоміжні функції знімка/підсумку стану каналу |
     | `plugin-sdk/channel-config-primitives` | Вузькі примітиви схеми конфігурації каналу |
-    | `plugin-sdk/channel-config-writes` | Допоміжні засоби авторизації запису конфігурації каналу |
-    | `plugin-sdk/channel-plugin-common` | Спільні prelude-експорти плагіна каналу |
-    | `plugin-sdk/allowlist-config-edit` | Допоміжні засоби редагування/читання конфігурації allowlist |
-    | `plugin-sdk/group-access` | Спільні допоміжні засоби визначення доступу до груп |
-    | `plugin-sdk/direct-dm` | Спільні допоміжні засоби авторизації/захисту прямих DM |
-    | `plugin-sdk/interactive-runtime` | Семантичне представлення повідомлень, доставка та застарілі допоміжні засоби інтерактивних відповідей. Див. [Представлення повідомлень](/uk/plugins/message-presentation) |
-    | `plugin-sdk/channel-inbound` | Сумісний barrel для debounce вхідних повідомлень, зіставлення згадок, допоміжних засобів політики згадок і допоміжних засобів envelope |
-    | `plugin-sdk/channel-inbound-debounce` | Вузькі допоміжні засоби debounce вхідних повідомлень |
-    | `plugin-sdk/channel-mention-gating` | Вузькі допоміжні засоби політики згадок і тексту згадок без ширшої поверхні inbound runtime |
-    | `plugin-sdk/channel-envelope` | Вузькі допоміжні засоби форматування вхідного envelope |
-    | `plugin-sdk/channel-location` | Допоміжні засоби контексту розташування каналу та форматування |
-    | `plugin-sdk/channel-logging` | Допоміжні засоби логування каналу для відкидання вхідних повідомлень і збоїв typing/ack |
+    | `plugin-sdk/channel-config-writes` | Допоміжні функції авторизації запису конфігурації каналу |
+    | `plugin-sdk/channel-plugin-common` | Спільні прелюдійні експорти Plugin каналу |
+    | `plugin-sdk/allowlist-config-edit` | Допоміжні функції читання/редагування конфігурації allowlist |
+    | `plugin-sdk/group-access` | Спільні допоміжні функції рішень щодо доступу до груп |
+    | `plugin-sdk/direct-dm` | Спільні допоміжні функції авторизації/захисту прямих DM |
+    | `plugin-sdk/interactive-runtime` | Семантичне представлення повідомлень, доставка та застарілі допоміжні функції інтерактивних відповідей. Див. [Представлення повідомлень](/uk/plugins/message-presentation) |
+    | `plugin-sdk/channel-inbound` | Сумісний barrel для debounce вхідних даних, зіставлення згадок, допоміжних функцій політики згадок і допоміжних функцій конвертів |
+    | `plugin-sdk/channel-inbound-debounce` | Вузькі допоміжні функції debounce вхідних даних |
+    | `plugin-sdk/channel-mention-gating` | Вузькі допоміжні функції політики згадок і тексту згадок без ширшої поверхні середовища виконання вхідних даних |
+    | `plugin-sdk/channel-envelope` | Вузькі допоміжні функції форматування конвертів вхідних даних |
+    | `plugin-sdk/channel-location` | Допоміжні функції контексту та форматування розташування каналу |
+    | `plugin-sdk/channel-logging` | Допоміжні функції журналювання каналу для відкинутих вхідних даних і помилок typing/ack |
     | `plugin-sdk/channel-send-result` | Типи результатів відповіді |
-    | `plugin-sdk/channel-actions` | Допоміжні засоби дій із повідомленнями каналу, а також застарілі нативні допоміжні засоби схем, збережені для сумісності з плагінами |
-    | `plugin-sdk/channel-targets` | Допоміжні засоби розбору/зіставлення цілей |
+    | `plugin-sdk/channel-actions` | Допоміжні функції дій із повідомленнями каналу, а також застарілі допоміжні функції нативної схеми, збережені для сумісності Plugin |
+    | `plugin-sdk/channel-targets` | Допоміжні функції розбору/зіставлення цілей |
     | `plugin-sdk/channel-contract` | Типи контрактів каналу |
-    | `plugin-sdk/channel-feedback` | Підключення feedback/reaction |
-    | `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні засоби секретних контрактів, такі як `collectSimpleChannelFieldAssignments`, `getChannelSurface`, `pushAssignment`, і типи secret target |
+    | `plugin-sdk/channel-feedback` | Зв’язування відгуків/реакцій |
+    | `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні функції контрактів секретів, такі як `collectSimpleChannelFieldAssignments`, `getChannelSurface`, `pushAssignment`, і типи цілей секретів |
   </Accordion>
 
   <Accordion title="Підшляхи провайдерів">
     | Підшлях | Ключові експорти |
     | --- | --- |
     | `plugin-sdk/provider-entry` | `defineSingleProviderPluginEntry` |
-    | `plugin-sdk/provider-setup` | Кураторські допоміжні засоби налаштування локальних/self-hosted провайдерів |
-    | `plugin-sdk/self-hosted-provider-setup` | Сфокусовані допоміжні засоби налаштування self-hosted провайдерів, сумісних з OpenAI |
-    | `plugin-sdk/cli-backend` | Значення за замовчуванням для CLI backend + константи watchdog |
-    | `plugin-sdk/provider-auth-runtime` | Допоміжні засоби визначення API-ключів у runtime для плагінів провайдерів |
-    | `plugin-sdk/provider-auth-api-key` | Допоміжні засоби онбордингу/запису профілів API-ключів, такі як `upsertApiKeyProfile` |
-    | `plugin-sdk/provider-auth-result` | Стандартний будівник результатів OAuth-автентифікації |
-    | `plugin-sdk/provider-auth-login` | Спільні допоміжні засоби інтерактивного входу для плагінів провайдерів |
-    | `plugin-sdk/provider-env-vars` | Допоміжні засоби пошуку env var для автентифікації провайдерів |
+    | `plugin-sdk/provider-setup` | Кураторські допоміжні функції налаштування локальних/self-hosted провайдерів |
+    | `plugin-sdk/self-hosted-provider-setup` | Цільові допоміжні функції налаштування self-hosted провайдерів, сумісних з OpenAI |
+    | `plugin-sdk/cli-backend` | Типові значення бекенда CLI та константи watchdog |
+    | `plugin-sdk/provider-auth-runtime` | Допоміжні функції визначення API-ключів у середовищі виконання для Plugin провайдерів |
+    | `plugin-sdk/provider-auth-api-key` | Допоміжні функції онбордингу/запису профілю API-ключа, такі як `upsertApiKeyProfile` |
+    | `plugin-sdk/provider-auth-result` | Стандартний побудовник результату OAuth-автентифікації |
+    | `plugin-sdk/provider-auth-login` | Спільні допоміжні функції інтерактивного входу для Plugin провайдерів |
+    | `plugin-sdk/provider-env-vars` | Допоміжні функції пошуку змінних середовища автентифікації провайдера |
     | `plugin-sdk/provider-auth` | `createProviderApiKeyAuthMethod`, `ensureApiKeyFromOptionEnvOrPrompt`, `upsertAuthProfile`, `upsertApiKeyProfile`, `writeOAuthCredentials` |
-    | `plugin-sdk/provider-model-shared` | `ProviderReplayFamily`, `buildProviderReplayFamilyHooks`, `normalizeModelCompat`, спільні будівники політики replay, допоміжні засоби endpoint провайдерів і допоміжні засоби нормалізації model-id, такі як `normalizeNativeXaiModelId` |
+    | `plugin-sdk/provider-model-shared` | `ProviderReplayFamily`, `buildProviderReplayFamilyHooks`, `normalizeModelCompat`, спільні побудовники політики повторення, допоміжні функції кінцевих точок провайдера та допоміжні функції нормалізації ID моделей, такі як `normalizeNativeXaiModelId` |
     | `plugin-sdk/provider-catalog-shared` | `findCatalogTemplate`, `buildSingleProviderApiKeyCatalog`, `supportsNativeStreamingUsageCompat`, `applyProviderNativeStreamingUsageCompat` |
-    | `plugin-sdk/provider-http` | Загальні допоміжні засоби HTTP/можливостей endpoint провайдерів, HTTP-помилки провайдерів і допоміжні засоби multipart form для аудіотранскрипції |
-    | `plugin-sdk/provider-web-fetch-contract` | Вузькі допоміжні засоби контрактів конфігурації/вибору web-fetch, такі як `enablePluginInConfig` і `WebFetchProviderPlugin` |
-    | `plugin-sdk/provider-web-fetch` | Допоміжні засоби реєстрації/кешування web-fetch провайдерів |
-    | `plugin-sdk/provider-web-search-config-contract` | Вузькі допоміжні засоби конфігурації/облікових даних web-search для провайдерів, яким не потрібне підключення ввімкнення плагіна |
-    | `plugin-sdk/provider-web-search-contract` | Вузькі допоміжні засоби контрактів конфігурації/облікових даних web-search, такі як `createWebSearchProviderContractFields`, `enablePluginInConfig`, `resolveProviderWebSearchPluginConfig` і scoped setters/getters облікових даних |
-    | `plugin-sdk/provider-web-search` | Допоміжні засоби реєстрації/кешування/runtime для web-search провайдерів |
-    | `plugin-sdk/provider-tools` | `ProviderToolCompatFamily`, `buildProviderToolCompatFamilyHooks`, очищення схем Gemini + діагностика, а також допоміжні засоби сумісності xAI, такі як `resolveXaiModelCompatPatch` / `applyXaiModelCompat` |
+    | `plugin-sdk/provider-http` | Загальні допоміжні функції HTTP/можливостей кінцевих точок провайдера, помилки HTTP провайдера та допоміжні функції multipart form для транскрипції аудіо |
+    | `plugin-sdk/provider-web-fetch-contract` | Вузькі допоміжні функції контракту конфігурації/вибору web-fetch, такі як `enablePluginInConfig` і `WebFetchProviderPlugin` |
+    | `plugin-sdk/provider-web-fetch` | Допоміжні функції реєстрації/кешування провайдера web-fetch |
+    | `plugin-sdk/provider-web-search-config-contract` | Вузькі допоміжні функції конфігурації/облікових даних web-search для провайдерів, яким не потрібне вмикання Plugin у конфігурації |
+    | `plugin-sdk/provider-web-search-contract` | Вузькі допоміжні функції контракту конфігурації/облікових даних web-search, такі як `createWebSearchProviderContractFields`, `enablePluginInConfig`, `resolveProviderWebSearchPluginConfig` і scoped сетери/гетери облікових даних |
+    | `plugin-sdk/provider-web-search` | Допоміжні функції реєстрації/кешування/середовища виконання провайдера web-search |
+    | `plugin-sdk/provider-tools` | `ProviderToolCompatFamily`, `buildProviderToolCompatFamilyHooks`, очищення схем Gemini та діагностика, а також допоміжні функції сумісності xAI, такі як `resolveXaiModelCompatPatch` / `applyXaiModelCompat` |
     | `plugin-sdk/provider-usage` | `fetchClaudeUsage` та подібні |
-    | `plugin-sdk/provider-stream` | `ProviderStreamFamily`, `buildProviderStreamFamilyHooks`, `composeProviderStreamWrappers`, типи обгорток потоків і спільні допоміжні засоби обгорток для Anthropic/Bedrock/DeepSeek V4/Google/Kilocode/Moonshot/OpenAI/OpenRouter/Z.A.I/MiniMax/Copilot |
-    | `plugin-sdk/provider-transport-runtime` | Нативні допоміжні засоби транспорту провайдерів, такі як guarded fetch, перетворення транспортних повідомлень і потоки записуваних транспортних подій |
-    | `plugin-sdk/provider-onboard` | Допоміжні засоби виправлення конфігурації онбордингу |
-    | `plugin-sdk/global-singleton` | Допоміжні засоби process-local singleton/map/cache |
-    | `plugin-sdk/group-activation` | Вузькі допоміжні засоби режиму активації груп і розбору команд |
+    | `plugin-sdk/provider-stream` | `ProviderStreamFamily`, `buildProviderStreamFamilyHooks`, `composeProviderStreamWrappers`, типи обгорток потоків і спільні допоміжні функції обгорток для Anthropic/Bedrock/DeepSeek V4/Google/Kilocode/Moonshot/OpenAI/OpenRouter/Z.A.I/MiniMax/Copilot |
+    | `plugin-sdk/provider-transport-runtime` | Допоміжні функції нативного транспорту провайдера, такі як guarded fetch, трансформації транспортних повідомлень і потоки подій транспорту з можливістю запису |
+    | `plugin-sdk/provider-onboard` | Допоміжні функції патчів конфігурації онбордингу |
+    | `plugin-sdk/global-singleton` | Допоміжні функції локальних для процесу singleton/map/cache |
+    | `plugin-sdk/group-activation` | Вузькі допоміжні функції режиму активації групи та розбору команд |
   </Accordion>
 
   <Accordion title="Підшляхи автентифікації та безпеки">
     | Підшлях | Ключові експорти |
     | --- | --- |
-    | `plugin-sdk/command-auth` | `resolveControlCommandGate`, допоміжні засоби реєстру команд, зокрема форматування меню динамічних аргументів, допоміжні засоби авторизації відправника |
-    | `plugin-sdk/command-status` | Будівники повідомлень команд/довідки, такі як `buildCommandsMessagePaginated` і `buildHelpMessage` |
-    | `plugin-sdk/approval-auth-runtime` | Допоміжні засоби визначення затверджувача й автентифікації дій у тому самому чаті |
-    | `plugin-sdk/approval-client-runtime` | Допоміжні засоби профілю/фільтра нативного затвердження exec |
-    | `plugin-sdk/approval-delivery-runtime` | Нативні адаптери можливостей/доставки затверджень |
-    | `plugin-sdk/approval-gateway-runtime` | Спільний допоміжний засіб визначення approval Gateway |
-    | `plugin-sdk/approval-handler-adapter-runtime` | Полегшені допоміжні засоби завантаження нативного адаптера затвердження для гарячих точок входу каналів |
-    | `plugin-sdk/approval-handler-runtime` | Ширші допоміжні засоби runtime обробника затверджень; віддавайте перевагу вужчим поверхням adapter/gateway, коли їх достатньо |
-    | `plugin-sdk/approval-native-runtime` | Нативні допоміжні засоби для цілей затвердження + прив’язки облікових записів |
-    | `plugin-sdk/approval-reply-runtime` | Допоміжні засоби payload відповіді на затвердження exec/plugin |
-    | `plugin-sdk/approval-runtime` | Допоміжні засоби payload затвердження exec/plugin, нативні допоміжні засоби маршрутизації/runtime затверджень і допоміжні засоби структурованого відображення затверджень, такі як `formatApprovalDisplayPath` |
-    | `plugin-sdk/reply-dedupe` | Вузькі допоміжні засоби скидання дедуплікації вхідних відповідей |
-    | `plugin-sdk/channel-contract-testing` | Вузькі допоміжні засоби тестування контрактів каналів без широкого testing barrel |
-    | `plugin-sdk/command-auth-native` | Нативна автентифікація команд, форматування меню динамічних аргументів і нативні допоміжні засоби цілей сесій |
-    | `plugin-sdk/command-detection` | Спільні допоміжні засоби виявлення команд |
+    | `plugin-sdk/command-auth` | `resolveControlCommandGate`, допоміжні функції реєстру команд, включно з форматуванням меню динамічних аргументів, допоміжні функції авторизації відправника |
+    | `plugin-sdk/command-status` | Побудовники повідомлень команд/довідки, такі як `buildCommandsMessagePaginated` і `buildHelpMessage` |
+    | `plugin-sdk/approval-auth-runtime` | Допоміжні функції визначення затверджувача та автентифікації дій у тому самому чаті |
+    | `plugin-sdk/approval-client-runtime` | Допоміжні функції профілю/фільтра нативного затвердження exec |
+    | `plugin-sdk/approval-delivery-runtime` | Адаптери можливостей/доставки нативного затвердження |
+    | `plugin-sdk/approval-gateway-runtime` | Спільна допоміжна функція визначення Gateway для затвердження |
+    | `plugin-sdk/approval-handler-adapter-runtime` | Полегшені допоміжні функції завантаження адаптера нативного затвердження для гарячих точок входу каналів |
+    | `plugin-sdk/approval-handler-runtime` | Ширші допоміжні функції середовища виконання обробника затвердження; надавайте перевагу вужчим швам adapter/gateway, коли їх достатньо |
+    | `plugin-sdk/approval-native-runtime` | Допоміжні функції цілі нативного затвердження та прив’язки акаунта |
+    | `plugin-sdk/approval-reply-runtime` | Допоміжні функції payload відповіді для затвердження exec/Plugin |
+    | `plugin-sdk/approval-runtime` | Допоміжні функції payload затвердження exec/Plugin, допоміжні функції маршрутизації/середовища виконання нативного затвердження та структуровані допоміжні функції відображення затвердження, такі як `formatApprovalDisplayPath` |
+    | `plugin-sdk/reply-dedupe` | Вузькі допоміжні функції скидання дедуплікації вхідних відповідей |
+    | `plugin-sdk/channel-contract-testing` | Вузькі допоміжні функції тестування контракту каналу без широкого testing barrel |
+    | `plugin-sdk/command-auth-native` | Нативна автентифікація команд, форматування меню динамічних аргументів і допоміжні функції цілі нативної сесії |
+    | `plugin-sdk/command-detection` | Спільні допоміжні функції виявлення команд |
     | `plugin-sdk/command-primitives-runtime` | Полегшені предикати тексту команд для гарячих шляхів каналів |
-    | `plugin-sdk/command-surface` | Допоміжні засоби нормалізації тіла команди й поверхні команд |
+    | `plugin-sdk/command-surface` | Нормалізація тіла команди та допоміжні функції поверхні команди |
     | `plugin-sdk/allow-from` | `formatAllowFromLowercase` |
-    | `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні засоби збирання секретних контрактів для секретних поверхонь каналів/плагінів |
-    | `plugin-sdk/secret-ref-runtime` | Вузькі допоміжні засоби `coerceSecretRef` і типізації SecretRef для розбору секретних контрактів/конфігурації |
-    | `plugin-sdk/security-runtime` | Спільні допоміжні засоби довіри, DM gating, зовнішнього вмісту та збирання секретів |
-    | `plugin-sdk/ssrf-policy` | Допоміжні засоби політики SSRF для allowlist хостів і приватних мереж |
-    | `plugin-sdk/ssrf-dispatcher` | Вузькі допоміжні засоби pinned-dispatcher без широкої поверхні infra runtime |
-    | `plugin-sdk/ssrf-runtime` | Допоміжні засоби pinned-dispatcher, fetch із захистом SSRF і політики SSRF |
-    | `plugin-sdk/secret-input` | Допоміжні засоби розбору секретного вводу |
-    | `plugin-sdk/webhook-ingress` | Допоміжні засоби запитів/цілей Webhook |
-    | `plugin-sdk/webhook-request-guards` | Допоміжні засоби обмеження розміру body/timeout запитів |
+    | `plugin-sdk/channel-secret-runtime` | Вузькі допоміжні функції збору секретних контрактів для поверхонь секретів каналу/Plugin |
+    | `plugin-sdk/secret-ref-runtime` | Вузькі допоміжні функції `coerceSecretRef` і типізації SecretRef для розбору секретних контрактів/конфігурації |
+    | `plugin-sdk/security-runtime` | Спільні допоміжні функції довіри, шлюзу DM, зовнішнього вмісту та збору секретів |
+    | `plugin-sdk/ssrf-policy` | Допоміжні функції allowlist хостів і політики SSRF для приватної мережі |
+    | `plugin-sdk/ssrf-dispatcher` | Вузькі допоміжні функції pinned-dispatcher без широкої поверхні infra runtime |
+    | `plugin-sdk/ssrf-runtime` | Допоміжні функції pinned-dispatcher, fetch із захистом SSRF та політики SSRF |
+    | `plugin-sdk/secret-input` | Допоміжні функції розбору введення секретів |
+    | `plugin-sdk/webhook-ingress` | Допоміжні функції запиту/цілі Webhook |
+    | `plugin-sdk/webhook-request-guards` | Допоміжні функції розміру тіла запиту/тайм-ауту |
   </Accordion>
 
-  <Accordion title="Підшляхи runtime і сховища">
+  <Accordion title="Підшляхи середовища виконання та сховища">
     | Підшлях | Ключові експорти |
     | --- | --- |
-    | `plugin-sdk/runtime` | Широкі допоміжні засоби runtime/логування/резервного копіювання/встановлення плагінів |
-    | `plugin-sdk/runtime-env` | Вузькі допоміжні засоби env runtime, logger, timeout, retry і backoff |
-    | `plugin-sdk/channel-runtime-context` | Загальні допоміжні засоби реєстрації та пошуку runtime-context каналу |
+    | `plugin-sdk/runtime` | Широкі допоміжні функції середовища виконання/журналювання/резервного копіювання/встановлення Plugin |
+    | `plugin-sdk/runtime-env` | Вузькі допоміжні функції env середовища виконання, logger, timeout, retry і backoff |
+    | `plugin-sdk/channel-runtime-context` | Загальні допоміжні функції реєстрації та пошуку контексту середовища виконання каналу |
     | `plugin-sdk/runtime-store` | `createPluginRuntimeStore` |
-    | `plugin-sdk/plugin-runtime` | Спільні допоміжні засоби команд/hook/http/interactive для плагінів |
-    | `plugin-sdk/hook-runtime` | Спільні допоміжні засоби pipeline для Webhook/внутрішніх hook |
-    | `plugin-sdk/lazy-runtime` | Допоміжні засоби lazy-імпорту/прив’язки runtime, такі як `createLazyRuntimeModule`, `createLazyRuntimeMethod` і `createLazyRuntimeSurface` |
-    | `plugin-sdk/process-runtime` | Допоміжні засоби виконання процесів |
-    | `plugin-sdk/cli-runtime` | Допоміжні засоби форматування CLI, wait, version, виклику аргументів і lazy command-group |
-    | `plugin-sdk/gateway-runtime` | Допоміжні засоби клієнта Gateway і патчів status каналу |
-    | `plugin-sdk/config-runtime` | Допоміжні засоби завантаження/запису конфігурації та пошуку конфігурації плагіна |
-    | `plugin-sdk/telegram-command-config` | Допоміжні засоби нормалізації назв/описів команд Telegram і перевірки дублікатів/конфліктів, навіть коли поверхня bundled контракту Telegram недоступна |
-    | `plugin-sdk/text-autolink-runtime` | Виявлення autolink для посилань на файли без широкого text-runtime barrel |
-    | `plugin-sdk/approval-runtime` | Допоміжні засоби затвердження exec/plugin, будівники можливостей затвердження, допоміжні засоби auth/profile, нативні допоміжні засоби маршрутизації/runtime та форматування шляхів структурованого відображення затверджень |
-    | `plugin-sdk/reply-runtime` | Спільні допоміжні засоби runtime для inbound/reply, chunking, dispatch, Heartbeat, планувальник відповідей |
-    | `plugin-sdk/reply-dispatch-runtime` | Вузькі допоміжні засоби dispatch/finalize відповідей і підписів розмов |
-    | `plugin-sdk/reply-history` | Спільні допоміжні засоби short-window історії відповідей, такі як `buildHistoryContext`, `recordPendingHistoryEntry` і `clearHistoryEntriesIfEnabled` |
+    | `plugin-sdk/plugin-runtime` | Спільні допоміжні функції команд/hook/http/interactive для Plugin |
+    | `plugin-sdk/hook-runtime` | Спільні допоміжні функції pipeline Webhook/внутрішніх hook |
+    | `plugin-sdk/lazy-runtime` | Допоміжні функції лінивого імпорту/прив’язки середовища виконання, такі як `createLazyRuntimeModule`, `createLazyRuntimeMethod` і `createLazyRuntimeSurface` |
+    | `plugin-sdk/process-runtime` | Допоміжні функції виконання процесів |
+    | `plugin-sdk/cli-runtime` | Допоміжні функції форматування CLI, очікування, версії, виклику аргументів і лінивих груп команд |
+    | `plugin-sdk/gateway-runtime` | Допоміжні функції клієнта Gateway і патчів статусу каналу |
+    | `plugin-sdk/config-runtime` | Допоміжні функції завантаження/запису конфігурації та пошуку конфігурації Plugin |
+    | `plugin-sdk/telegram-command-config` | Нормалізація назв/описів команд Telegram і перевірки дублікатів/конфліктів, навіть коли поверхня контракту вбудованого Telegram недоступна |
+    | `plugin-sdk/text-autolink-runtime` | Виявлення autolink посилань на файли без широкого text-runtime barrel |
+    | `plugin-sdk/approval-runtime` | Допоміжні функції затвердження exec/Plugin, побудовники можливостей затвердження, допоміжні функції auth/profile, допоміжні функції нативної маршрутизації/середовища виконання та форматування шляху структурованого відображення затвердження |
+    | `plugin-sdk/reply-runtime` | Спільні допоміжні функції середовища виконання вхідних даних/відповідей, chunking, dispatch, Heartbeat, планувальник відповідей |
+    | `plugin-sdk/reply-dispatch-runtime` | Вузькі допоміжні функції dispatch/finalize відповідей і міток розмов |
+    | `plugin-sdk/reply-history` | Спільні допоміжні функції історії відповідей у короткому вікні, такі як `buildHistoryContext`, `recordPendingHistoryEntry` і `clearHistoryEntriesIfEnabled` |
     | `plugin-sdk/reply-reference` | `createReplyReferencePlanner` |
-    | `plugin-sdk/reply-chunking` | Вузькі допоміжні засоби chunking тексту/Markdown |
-    | `plugin-sdk/session-store-runtime` | Допоміжні засоби шляху сховища сесій + `updated-at` |
-    | `plugin-sdk/state-paths` | Допоміжні засоби шляхів каталогів state/OAuth |
-    | `plugin-sdk/routing` | Допоміжні засоби маршруту/ключа сесії/прив’язки облікового запису, такі як `resolveAgentRoute`, `buildAgentSessionKey` і `resolveDefaultAgentBoundAccountId` |
-    | `plugin-sdk/status-helpers` | Спільні допоміжні засоби підсумку status каналу/облікового запису, значення runtime-state за замовчуванням і допоміжні засоби метаданих issue |
-    | `plugin-sdk/target-resolver-runtime` | Спільні допоміжні засоби визначення цілей |
-    | `plugin-sdk/string-normalization-runtime` | Допоміжні засоби нормалізації slug/рядків |
-    | `plugin-sdk/request-url` | Витягування рядкових URL із fetch/request-подібних входів |
-    | `plugin-sdk/run-command` | Виконавець команд із таймером і нормалізованими результатами stdout/stderr |
+    | `plugin-sdk/reply-chunking` | Вузькі допоміжні функції chunking тексту/markdown |
+    | `plugin-sdk/session-store-runtime` | Допоміжні функції шляху сховища сесій і `updated-at` |
+    | `plugin-sdk/state-paths` | Допоміжні функції шляхів каталогів state/OAuth |
+    | `plugin-sdk/routing` | Допоміжні функції прив’язки маршруту/ключа сесії/акаунта, такі як `resolveAgentRoute`, `buildAgentSessionKey` і `resolveDefaultAgentBoundAccountId` |
+    | `plugin-sdk/status-helpers` | Спільні допоміжні функції підсумку стану каналу/акаунта, типові значення стану середовища виконання та допоміжні функції метаданих проблем |
+    | `plugin-sdk/target-resolver-runtime` | Спільні допоміжні функції визначення цілі |
+    | `plugin-sdk/string-normalization-runtime` | Допоміжні функції нормалізації slug/рядків |
+    | `plugin-sdk/request-url` | Витягування рядкових URL з fetch/request-подібних вхідних даних |
+    | `plugin-sdk/run-command` | Виконавець команд із таймінгом і нормалізованими результатами stdout/stderr |
     | `plugin-sdk/param-readers` | Загальні зчитувачі параметрів tool/CLI |
-    | `plugin-sdk/tool-payload` | Витягування нормалізованих payload із об’єктів результатів tool |
+    | `plugin-sdk/tool-payload` | Витягування нормалізованих payload з об’єктів результатів tool |
     | `plugin-sdk/tool-send` | Витягування канонічних полів цілі надсилання з аргументів tool |
-    | `plugin-sdk/temp-path` | Спільні допоміжні засоби шляхів тимчасового завантаження |
-    | `plugin-sdk/logging-core` | Допоміжні засоби logger підсистем і редагування чутливих даних |
-    | `plugin-sdk/markdown-table-runtime` | Допоміжні засоби режимів і перетворення таблиць Markdown |
-    | `plugin-sdk/json-store` | Невеликі допоміжні засоби читання/запису стану JSON |
-    | `plugin-sdk/file-lock` | Допоміжні засоби повторного входу до file-lock |
-    | `plugin-sdk/persistent-dedupe` | Допоміжні засоби кешу дедуплікації з опорою на диск |
-    | `plugin-sdk/acp-runtime` | Допоміжні засоби runtime/сесій ACP і dispatch відповідей |
-    | `plugin-sdk/acp-binding-resolve-runtime` | Розв’язання прив’язок ACP тільки для читання без імпортів запуску життєвого циклу |
-    | `plugin-sdk/agent-config-primitives` | Вузькі примітиви схеми конфігурації runtime агента |
-    | `plugin-sdk/boolean-param` | Нестрогий зчитувач булевих параметрів |
-    | `plugin-sdk/dangerous-name-runtime` | Допоміжні засоби визначення збігів небезпечних імен |
-    | `plugin-sdk/device-bootstrap` | Допоміжні засоби bootstrap пристрою й токенів pairing |
-    | `plugin-sdk/extension-shared` | Спільні примітиви допоміжних засобів passive-channel, status і ambient proxy |
-    | `plugin-sdk/models-provider-runtime` | Допоміжні засоби відповідей для команди `/models`/провайдерів |
-    | `plugin-sdk/skill-commands-runtime` | Допоміжні засоби списку команд Skills |
-    | `plugin-sdk/native-command-registry` | Допоміжні засоби реєстру/побудови/серіалізації нативних команд |
-    | `plugin-sdk/agent-harness` | Експериментальна поверхня trusted-plugin для низькорівневих agent harness: типи harness, допоміжні засоби steer/abort для active-run, міст tools OpenClaw, допоміжні засоби політики tools runtime-plan, класифікація результатів terminal, допоміжні засоби форматування/деталізації прогресу tools і утиліти результатів спроб |
-    | `plugin-sdk/provider-zai-endpoint` | Допоміжні засоби виявлення endpoint Z.A.I |
-    | `plugin-sdk/infra-runtime` | Допоміжні засоби системних подій/Heartbeat |
-    | `plugin-sdk/collection-runtime` | Невеликі допоміжні засоби обмеженого кешу |
-    | `plugin-sdk/diagnostic-runtime` | Допоміжні засоби діагностичних прапорців і подій |
-    | `plugin-sdk/error-runtime` | Граф помилок, форматування, спільні допоміжні засоби класифікації помилок, `isApprovalNotFoundError` |
-    | `plugin-sdk/fetch-runtime` | Допоміжні засоби обгорнутого fetch, proxy і pinned lookup |
-    | `plugin-sdk/runtime-fetch` | Runtime fetch з урахуванням dispatcher без імпортів proxy/guarded-fetch |
-    | `plugin-sdk/response-limit-runtime` | Зчитувач обмеженого body відповіді без широкої поверхні media runtime |
+    | `plugin-sdk/temp-path` | Спільні допоміжні функції шляхів тимчасового завантаження |
+    | `plugin-sdk/logging-core` | Допоміжні функції logger підсистеми та редагування |
+    | `plugin-sdk/markdown-table-runtime` | Допоміжні функції режиму та перетворення таблиць Markdown |
+    | `plugin-sdk/json-store` | Невеликі допоміжні функції читання/запису стану JSON |
+    | `plugin-sdk/file-lock` | Допоміжні функції повторно вхідного блокування файлів |
+    | `plugin-sdk/persistent-dedupe` | Допоміжні функції кешу дедуплікації з підтримкою диска |
+    | `plugin-sdk/acp-runtime` | Допоміжні функції середовища виконання/сесії ACP і dispatch відповідей |
+    | `plugin-sdk/acp-binding-resolve-runtime` | Розв’язання прив’язки ACP лише для читання без імпортів запуску життєвого циклу |
+    | `plugin-sdk/agent-config-primitives` | Вузькі примітиви схеми конфігурації середовища виконання агента |
+    | `plugin-sdk/boolean-param` | Гнучкий зчитувач boolean-параметрів |
+    | `plugin-sdk/dangerous-name-runtime` | Допоміжні функції визначення збігів небезпечних імен |
+    | `plugin-sdk/device-bootstrap` | Допоміжні функції початкового налаштування пристрою та токенів pairing |
+    | `plugin-sdk/extension-shared` | Спільні примітиви пасивного каналу, стану та ambient proxy helper |
+    | `plugin-sdk/models-provider-runtime` | Допоміжні функції відповіді команди `/models`/провайдера |
+    | `plugin-sdk/skill-commands-runtime` | Допоміжні функції списку команд Skill |
+    | `plugin-sdk/native-command-registry` | Допоміжні функції реєстру/побудови/серіалізації нативних команд |
+    | `plugin-sdk/agent-harness` | Експериментальна поверхня trusted-plugin для низькорівневих agent harness: типи harness, допоміжні функції steer/abort активного запуску, допоміжні функції bridge tool OpenClaw, допоміжні функції політики tool плану середовища виконання, класифікація результатів terminal, форматування/деталізація прогресу tool і утиліти результатів спроб |
+    | `plugin-sdk/provider-zai-endpoint` | Допоміжні функції виявлення кінцевих точок Z.AI |
+    | `plugin-sdk/infra-runtime` | Допоміжні функції системних подій/Heartbeat |
+    | `plugin-sdk/collection-runtime` | Невеликі допоміжні функції обмеженого кешу |
+    | `plugin-sdk/diagnostic-runtime` | Допоміжні функції діагностичних прапорців і подій |
+    | `plugin-sdk/error-runtime` | Допоміжні функції графа помилок, форматування, спільної класифікації помилок, `isApprovalNotFoundError` |
+    | `plugin-sdk/fetch-runtime` | Допоміжні функції обгорнутого fetch, proxy і pinned lookup |
+    | `plugin-sdk/runtime-fetch` | Dispatcher-aware fetch середовища виконання без імпортів proxy/guarded-fetch |
+    | `plugin-sdk/response-limit-runtime` | Зчитувач обмеженого тіла відповіді без широкої поверхні media runtime |
     | `plugin-sdk/session-binding-runtime` | Поточний стан прив’язки розмови без маршрутизації налаштованих прив’язок або сховищ pairing |
-    | `plugin-sdk/session-store-runtime` | Допоміжні засоби читання сховища сесій без широких імпортів запису/обслуговування конфігурації |
-    | `plugin-sdk/context-visibility-runtime` | Допоміжні засоби визначення видимості контексту та фільтрації додаткового контексту без широких імпортів config/security |
-    | `plugin-sdk/string-coerce-runtime` | Вузькі допоміжні засоби приведення й нормалізації примітивних record/string без імпортів markdown/logging |
-    | `plugin-sdk/host-runtime` | Допоміжні засоби нормалізації імен хостів і SCP host |
-    | `plugin-sdk/retry-runtime` | Допоміжні засоби конфігурації retry і виконавця retry |
-    | `plugin-sdk/agent-runtime` | Допоміжні засоби директорії/ідентичності/робочого простору агента |
-    | `plugin-sdk/directory-runtime` | Запити директорій із конфігурації/dedup |
+    | `plugin-sdk/session-store-runtime` | Допоміжні функції читання сховища сесій без широких імпортів запису/обслуговування конфігурації |
+    | `plugin-sdk/context-visibility-runtime` | Допоміжні функції визначення видимості контексту та фільтрації додаткового контексту без широких імпортів config/security |
+    | `plugin-sdk/string-coerce-runtime` | Вузькі допоміжні функції приведення та нормалізації primitive record/string без імпортів markdown/logging |
+    | `plugin-sdk/host-runtime` | Допоміжні функції нормалізації hostname і SCP host |
+    | `plugin-sdk/retry-runtime` | Допоміжні функції конфігурації retry та виконавця retry |
+    | `plugin-sdk/agent-runtime` | Допоміжні функції каталогу/ідентичності/робочого простору агента |
+    | `plugin-sdk/directory-runtime` | Запит/dedup каталогів із підтримкою конфігурації |
     | `plugin-sdk/keyed-async-queue` | `KeyedAsyncQueue` |
   </Accordion>
 
   <Accordion title="Підшляхи можливостей і тестування">
     | Підшлях | Ключові експорти |
     | --- | --- |
-    | `plugin-sdk/media-runtime` | Спільні допоміжні засоби fetch/transform/store для медіа, а також будівники payload медіа |
-    | `plugin-sdk/media-store` | Вузькі допоміжні засоби сховища медіа, такі як `saveMediaBuffer` |
-    | `plugin-sdk/media-generation-runtime` | Спільні допоміжні засоби failover генерації медіа, вибору кандидатів і повідомлень про відсутню модель |
-    | `plugin-sdk/media-understanding` | Типи провайдерів розуміння медіа, а також орієнтовані на провайдерів експорти допоміжних засобів для зображень/аудіо |
-    | `plugin-sdk/text-runtime` | Спільні допоміжні засоби text/Markdown/logging, такі як видалення тексту, видимого асистенту, допоміжні засоби рендерингу/chunking/таблиць Markdown, допоміжні засоби редагування чутливих даних, допоміжні засоби тегів директив і утиліти безпечного тексту |
-    | `plugin-sdk/text-chunking` | Допоміжний засіб chunking вихідного тексту |
-    | `plugin-sdk/speech` | Типи провайдерів мовлення, а також орієнтовані на провайдерів експорти директив, реєстру, валідації та допоміжних засобів мовлення |
-    | `plugin-sdk/speech-core` | Спільні типи провайдерів мовлення, реєстр, директиви, нормалізація та експорти допоміжних засобів мовлення |
-    | `plugin-sdk/realtime-transcription` | Типи провайдерів транскрипції в реальному часі, допоміжні засоби реєстру та спільний допоміжний засіб сесії WebSocket |
-    | `plugin-sdk/realtime-voice` | Типи провайдерів голосу в реальному часі та допоміжні засоби реєстру |
-    | `plugin-sdk/image-generation` | Типи провайдерів генерації зображень |
-    | `plugin-sdk/image-generation-core` | Спільні типи генерації зображень, failover, auth і допоміжні засоби реєстру |
-    | `plugin-sdk/music-generation` | Типи провайдерів/запитів/результатів генерації музики |
-    | `plugin-sdk/music-generation-core` | Спільні типи генерації музики, допоміжні засоби failover, пошуку провайдерів і розбору model-ref |
-    | `plugin-sdk/video-generation` | Типи провайдерів/запитів/результатів генерації відео |
-    | `plugin-sdk/video-generation-core` | Спільні типи генерації відео, допоміжні засоби failover, пошуку провайдерів і розбору model-ref |
-    | `plugin-sdk/webhook-targets` | Допоміжні засоби реєстру цілей Webhook і встановлення маршрутів |
-    | `plugin-sdk/webhook-path` | Допоміжні засоби нормалізації шляху Webhook |
-    | `plugin-sdk/web-media` | Спільні допоміжні засоби завантаження віддалених/локальних медіа |
+    | `plugin-sdk/media-runtime` | Спільні допоміжні функції отримання/перетворення/збереження медіа, а також побудовники media payload |
+    | `plugin-sdk/media-store` | Вузькі допоміжні функції сховища медіа, такі як `saveMediaBuffer` |
+    | `plugin-sdk/media-generation-runtime` | Спільні допоміжні функції failover генерації медіа, вибору кандидатів і повідомлень про відсутню модель |
+    | `plugin-sdk/media-understanding` | Типи провайдера розуміння медіа та провайдер-орієнтовані експорти допоміжних функцій для зображень/аудіо |
+    | `plugin-sdk/text-runtime` | Спільні допоміжні функції тексту/markdown/журналювання, такі як вилучення тексту, видимого асистенту, допоміжні функції render/chunking/table для markdown, допоміжні функції редагування, directive-tag helper і утиліти безпечного тексту |
+    | `plugin-sdk/text-chunking` | Допоміжна функція chunking вихідного тексту |
+    | `plugin-sdk/speech` | Типи провайдера мовлення та провайдер-орієнтовані експорти directive, registry, validation і speech helper |
+    | `plugin-sdk/speech-core` | Спільні типи провайдера мовлення, registry, directive, normalizaton і speech helper exports |
+    | `plugin-sdk/realtime-transcription` | Типи провайдера транскрипції в реальному часі, допоміжні функції registry і спільна допоміжна функція сесії WebSocket |
+    | `plugin-sdk/realtime-voice` | Типи провайдера голосу в реальному часі та допоміжні функції registry |
+    | `plugin-sdk/image-generation` | Типи провайдера генерації зображень |
+    | `plugin-sdk/image-generation-core` | Спільні типи генерації зображень, failover, auth і registry helper |
+    | `plugin-sdk/music-generation` | Типи провайдера/запиту/результату генерації музики |
+    | `plugin-sdk/music-generation-core` | Спільні типи генерації музики, допоміжні функції failover, lookup провайдера та розбору model-ref |
+    | `plugin-sdk/video-generation` | Типи провайдера/запиту/результату генерації відео |
+    | `plugin-sdk/video-generation-core` | Спільні типи генерації відео, допоміжні функції failover, lookup провайдера та розбору model-ref |
+    | `plugin-sdk/webhook-targets` | Допоміжні функції реєстру цілей Webhook і встановлення маршрутів |
+    | `plugin-sdk/webhook-path` | Допоміжні функції нормалізації шляху Webhook |
+    | `plugin-sdk/web-media` | Спільні допоміжні функції завантаження віддалених/локальних медіа |
     | `plugin-sdk/zod` | Повторно експортований `zod` для споживачів Plugin SDK |
     | `plugin-sdk/testing` | `installCommonResolveTargetErrorCases`, `shouldAckReaction` |
   </Accordion>
@@ -247,43 +249,43 @@ x-i18n:
   <Accordion title="Підшляхи пам’яті">
     | Підшлях | Ключові експорти |
     | --- | --- |
-    | `plugin-sdk/memory-core` | Поверхня допоміжних засобів bundled memory-core для менеджера/конфігурації/файлів/допоміжних засобів CLI |
-    | `plugin-sdk/memory-core-engine-runtime` | Runtime-фасад індексації/пошуку пам’яті |
+    | `plugin-sdk/memory-core` | Поверхня допоміжних функцій bundled memory-core для допоміжних функцій manager/config/file/CLI |
+    | `plugin-sdk/memory-core-engine-runtime` | Фасад середовища виконання індексу/пошуку пам’яті |
     | `plugin-sdk/memory-core-host-engine-foundation` | Експорти foundation engine хоста пам’яті |
-    | `plugin-sdk/memory-core-host-engine-embeddings` | Контракти embedding хоста пам’яті, доступ до реєстру, локальний провайдер і загальні допоміжні засоби batch/remote |
+    | `plugin-sdk/memory-core-host-engine-embeddings` | Контракти embedding хоста пам’яті, доступ до registry, локальний провайдер і загальні допоміжні функції batch/remote |
     | `plugin-sdk/memory-core-host-engine-qmd` | Експорти QMD engine хоста пам’яті |
     | `plugin-sdk/memory-core-host-engine-storage` | Експорти storage engine хоста пам’яті |
-    | `plugin-sdk/memory-core-host-multimodal` | Допоміжні засоби multimodal хоста пам’яті |
-    | `plugin-sdk/memory-core-host-query` | Допоміжні засоби запитів хоста пам’яті |
-    | `plugin-sdk/memory-core-host-secret` | Допоміжні засоби секретів хоста пам’яті |
-    | `plugin-sdk/memory-core-host-events` | Допоміжні засоби журналу подій хоста пам’яті |
-    | `plugin-sdk/memory-core-host-status` | Допоміжні засоби status хоста пам’яті |
-    | `plugin-sdk/memory-core-host-runtime-cli` | Допоміжні засоби runtime CLI хоста пам’яті |
-    | `plugin-sdk/memory-core-host-runtime-core` | Допоміжні засоби core runtime хоста пам’яті |
-    | `plugin-sdk/memory-core-host-runtime-files` | Допоміжні засоби файлів/runtime хоста пам’яті |
-    | `plugin-sdk/memory-host-core` | Нейтральний до вендора псевдонім для допоміжних засобів core runtime хоста пам’яті |
-    | `plugin-sdk/memory-host-events` | Нейтральний до вендора псевдонім для допоміжних засобів журналу подій хоста пам’яті |
-    | `plugin-sdk/memory-host-files` | Нейтральний до вендора псевдонім для допоміжних засобів файлів/runtime хоста пам’яті |
-    | `plugin-sdk/memory-host-markdown` | Спільні допоміжні засоби керованого Markdown для плагінів, суміжних із пам’яттю |
-    | `plugin-sdk/memory-host-search` | Runtime-фасад Active Memory для доступу до менеджера пошуку |
-    | `plugin-sdk/memory-host-status` | Нейтральний до вендора псевдонім для допоміжних засобів status хоста пам’яті |
-    | `plugin-sdk/memory-lancedb` | Поверхня допоміжних засобів bundled memory-lancedb |
+    | `plugin-sdk/memory-core-host-multimodal` | Допоміжні функції multimodal хоста пам’яті |
+    | `plugin-sdk/memory-core-host-query` | Допоміжні функції запитів хоста пам’яті |
+    | `plugin-sdk/memory-core-host-secret` | Допоміжні функції секретів хоста пам’яті |
+    | `plugin-sdk/memory-core-host-events` | Допоміжні функції журналу подій хоста пам’яті |
+    | `plugin-sdk/memory-core-host-status` | Допоміжні функції стану хоста пам’яті |
+    | `plugin-sdk/memory-core-host-runtime-cli` | Допоміжні функції середовища виконання CLI хоста пам’яті |
+    | `plugin-sdk/memory-core-host-runtime-core` | Основні допоміжні функції середовища виконання хоста пам’яті |
+    | `plugin-sdk/memory-core-host-runtime-files` | Допоміжні функції файлів/середовища виконання хоста пам’яті |
+    | `plugin-sdk/memory-host-core` | Нейтральний щодо вендора псевдонім для основних допоміжних функцій середовища виконання хоста пам’яті |
+    | `plugin-sdk/memory-host-events` | Нейтральний щодо вендора псевдонім для допоміжних функцій журналу подій хоста пам’яті |
+    | `plugin-sdk/memory-host-files` | Нейтральний щодо вендора псевдонім для допоміжних функцій файлів/середовища виконання хоста пам’яті |
+    | `plugin-sdk/memory-host-markdown` | Спільні допоміжні функції керованого markdown для Plugin, пов’язаних із пам’яттю |
+    | `plugin-sdk/memory-host-search` | Фасад середовища виконання Active Memory для доступу до менеджера пошуку |
+    | `plugin-sdk/memory-host-status` | Нейтральний щодо вендора псевдонім для допоміжних функцій стану хоста пам’яті |
+    | `plugin-sdk/memory-lancedb` | Поверхня допоміжних функцій bundled memory-lancedb |
   </Accordion>
 
-  <Accordion title="Зарезервовані підшляхи bundled-helper">
-    | Сімейство | Поточні підшляхи | Призначене використання |
+  <Accordion title="Зарезервовані підшляхи вбудованих допоміжних функцій">
+    | Сімейство | Поточні підшляхи | Призначення |
     | --- | --- | --- |
-    | Browser | `plugin-sdk/browser-cdp`, `plugin-sdk/browser-config-runtime`, `plugin-sdk/browser-config-support`, `plugin-sdk/browser-control-auth`, `plugin-sdk/browser-node-runtime`, `plugin-sdk/browser-profiles`, `plugin-sdk/browser-security-runtime`, `plugin-sdk/browser-setup-tools`, `plugin-sdk/browser-support` | Допоміжні засоби підтримки bundled browser plugin. `browser-profiles` експортує `resolveBrowserConfig`, `resolveProfile`, `ResolvedBrowserConfig`, `ResolvedBrowserProfile` і `ResolvedBrowserTabCleanupConfig` для нормалізованої форми `browser.tabCleanup`. `browser-support` залишається compatibility barrel. |
-    | Matrix | `plugin-sdk/matrix`, `plugin-sdk/matrix-helper`, `plugin-sdk/matrix-runtime-heavy`, `plugin-sdk/matrix-runtime-shared`, `plugin-sdk/matrix-runtime-surface`, `plugin-sdk/matrix-surface`, `plugin-sdk/matrix-thread-bindings` | Поверхня допоміжних засобів/runtime bundled Matrix |
-    | Line | `plugin-sdk/line`, `plugin-sdk/line-core`, `plugin-sdk/line-runtime`, `plugin-sdk/line-surface` | Поверхня допоміжних засобів/runtime bundled LINE |
-    | IRC | `plugin-sdk/irc`, `plugin-sdk/irc-surface` | Поверхня допоміжних засобів bundled IRC |
-    | Допоміжні засоби, специфічні для каналів | `plugin-sdk/googlechat`, `plugin-sdk/zalouser`, `plugin-sdk/bluebubbles`, `plugin-sdk/bluebubbles-policy`, `plugin-sdk/mattermost`, `plugin-sdk/mattermost-policy`, `plugin-sdk/feishu-conversation`, `plugin-sdk/msteams`, `plugin-sdk/nextcloud-talk`, `plugin-sdk/nostr`, `plugin-sdk/tlon`, `plugin-sdk/twitch` | Поверхні сумісності/допоміжних засобів bundled каналів |
-    | Допоміжні засоби, специфічні для auth/plugin | `plugin-sdk/github-copilot-login`, `plugin-sdk/github-copilot-token`, `plugin-sdk/diagnostics-otel`, `plugin-sdk/diagnostics-prometheus`, `plugin-sdk/diffs`, `plugin-sdk/llm-task`, `plugin-sdk/thread-ownership`, `plugin-sdk/voice-call` | Поверхні допоміжних засобів bundled функцій/плагінів; `plugin-sdk/github-copilot-token` наразі експортує `DEFAULT_COPILOT_API_BASE_URL`, `deriveCopilotApiBaseUrlFromToken` і `resolveCopilotApiToken` |
+    | Browser | `plugin-sdk/browser-cdp`, `plugin-sdk/browser-config-runtime`, `plugin-sdk/browser-config-support`, `plugin-sdk/browser-control-auth`, `plugin-sdk/browser-node-runtime`, `plugin-sdk/browser-profiles`, `plugin-sdk/browser-security-runtime`, `plugin-sdk/browser-setup-tools`, `plugin-sdk/browser-support` | Допоміжні функції підтримки вбудованого Browser Plugin. `browser-profiles` експортує `resolveBrowserConfig`, `resolveProfile`, `ResolvedBrowserConfig`, `ResolvedBrowserProfile` і `ResolvedBrowserTabCleanupConfig` для нормалізованої форми `browser.tabCleanup`. `browser-support` залишається compatibility barrel. |
+    | Matrix | `plugin-sdk/matrix`, `plugin-sdk/matrix-helper`, `plugin-sdk/matrix-runtime-heavy`, `plugin-sdk/matrix-runtime-shared`, `plugin-sdk/matrix-runtime-surface`, `plugin-sdk/matrix-surface`, `plugin-sdk/matrix-thread-bindings` | Поверхня допоміжних функцій/середовища виконання вбудованого Matrix |
+    | Line | `plugin-sdk/line`, `plugin-sdk/line-core`, `plugin-sdk/line-runtime`, `plugin-sdk/line-surface` | Поверхня допоміжних функцій/середовища виконання вбудованого LINE |
+    | IRC | `plugin-sdk/irc`, `plugin-sdk/irc-surface` | Поверхня допоміжних функцій вбудованого IRC |
+    | Допоміжні функції, специфічні для каналів | `plugin-sdk/googlechat`, `plugin-sdk/zalouser`, `plugin-sdk/bluebubbles`, `plugin-sdk/bluebubbles-policy`, `plugin-sdk/mattermost`, `plugin-sdk/mattermost-policy`, `plugin-sdk/feishu-conversation`, `plugin-sdk/msteams`, `plugin-sdk/nextcloud-talk`, `plugin-sdk/nostr`, `plugin-sdk/tlon`, `plugin-sdk/twitch` | Шви сумісності/допоміжних функцій вбудованих каналів |
+    | Допоміжні функції, специфічні для auth/Plugin | `plugin-sdk/github-copilot-login`, `plugin-sdk/github-copilot-token`, `plugin-sdk/diagnostics-otel`, `plugin-sdk/diagnostics-prometheus`, `plugin-sdk/diffs`, `plugin-sdk/llm-task`, `plugin-sdk/thread-ownership`, `plugin-sdk/voice-call` | Шви допоміжних функцій вбудованих можливостей/Plugin; `plugin-sdk/github-copilot-token` наразі експортує `DEFAULT_COPILOT_API_BASE_URL`, `deriveCopilotApiBaseUrlFromToken` і `resolveCopilotApiToken` |
   </Accordion>
 </AccordionGroup>
 
-## Пов’язане
+## Пов’язано
 
 - [Огляд Plugin SDK](/uk/plugins/sdk-overview)
 - [Налаштування Plugin SDK](/uk/plugins/sdk-setup)
-- [Створення плагінів](/uk/plugins/building-plugins)
+- [Створення Plugin](/uk/plugins/building-plugins)

docs/uk/providers/lmstudio.md

@@ -2,18 +2,18 @@
 read_when:
     - Ви хочете запускати OpenClaw з моделями з відкритим кодом через LM Studio
     - Ви хочете налаштувати та сконфігурувати LM Studio
-summary: Запустіть OpenClaw за допомогою LM Studio
+summary: Запустіть OpenClaw з LM Studio
 title: LM Studio
 x-i18n:
-    generated_at: "2026-04-27T07:19:09Z"
+    generated_at: "2026-04-27T08:09:15Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 0077108b7ab3171084f89234e25f5f5e8b68239a6fa6c11fa70c65f52d56670f
+    source_hash: 98edefa8b57ab2a89d1c4405827335a421c3157f51c5d23ac5f83c1cbeab20a9
     source_path: providers/lmstudio.md
     workflow: 15
 ---
 
-LM Studio — це дружній, але водночас потужний застосунок для запуску моделей з відкритими вагами на вашому власному обладнанні. Він дає змогу запускати моделі llama.cpp (GGUF) або MLX (Apple Silicon). Доступний як GUI-пакет або безголовий демон (`llmster`). Докладніше про продукт і налаштування дивіться в [lmstudio.ai](https://lmstudio.ai/).
+LM Studio — це зручна, але водночас потужна програма для запуску моделей з відкритими вагами на власному обладнанні. Вона дає змогу запускати моделі llama.cpp (GGUF) або MLX (Apple Silicon). Доступна як GUI-застосунок або headless-демон (`llmster`). Документацію про продукт і налаштування див. на [lmstudio.ai](https://lmstudio.ai/).
 
 ## Швидкий старт
 
@@ -25,7 +25,7 @@ curl -fsSL https://lmstudio.ai/install.sh | bash
 
 2. Запустіть сервер
 
-Переконайтеся, що ви або запустили desktop-застосунок, або запустили демон за допомогою такої команди:
+Переконайтеся, що ви або запускаєте desktop-застосунок, або запускаєте демон такою командою:
 
 ```bash
 lms daemon up
@@ -35,7 +35,7 @@ lms daemon up
 lms server start --port 1234
 ```
 
-Якщо ви використовуєте застосунок, переконайтеся, що у вас увімкнено JIT для комфортної роботи. Докладніше в [посібнику LM Studio щодо JIT і TTL](https://lmstudio.ai/docs/developer/core/ttl-and-auto-evict).
+Якщо ви використовуєте застосунок, переконайтеся, що у вас увімкнено JIT для комфортної роботи. Докладніше див. у [посібнику LM Studio про JIT і TTL](https://lmstudio.ai/docs/developer/core/ttl-and-auto-evict).
 
 3. Якщо в LM Studio увімкнено автентифікацію, установіть `LM_API_TOKEN`:
 
@@ -43,31 +43,31 @@ lms server start --port 1234
 export LM_API_TOKEN="your-lm-studio-api-token"
 ```
 
-Якщо автентифікацію LM Studio вимкнено, під час інтерактивного налаштування OpenClaw можна залишити ключ API порожнім.
+Якщо автентифікацію LM Studio вимкнено, під час інтерактивного налаштування OpenClaw можна залишити API-ключ порожнім.
 
-Докладніше про налаштування автентифікації LM Studio дивіться в [LM Studio Authentication](https://lmstudio.ai/docs/developer/core/authentication).
+Докладніше про налаштування автентифікації LM Studio див. у [LM Studio Authentication](https://lmstudio.ai/docs/developer/core/authentication).
 
-4. Запустіть початкове налаштування й виберіть `LM Studio`:
+4. Запустіть початкове налаштування та виберіть `LM Studio`:
 
 ```bash
 openclaw onboard
 ```
 
-5. Під час початкового налаштування використайте запит `Default model`, щоб вибрати свою модель LM Studio.
+5. Під час початкового налаштування використайте запит `Default model`, щоб вибрати вашу модель LM Studio.
 
-Також ви можете встановити або змінити її пізніше:
+Ви також можете встановити або змінити її пізніше:
 
 ```bash
 openclaw models set lmstudio/qwen/qwen3.5-9b
 ```
 
-Ключі моделей LM Studio мають формат `author/model-name` (наприклад, `qwen/qwen3.5-9b`). У OpenClaw
-посилання на моделі додають префікс провайдера: `lmstudio/qwen/qwen3.5-9b`. Точний ключ
+Ключі моделей LM Studio мають формат `author/model-name` (наприклад, `qwen/qwen3.5-9b`). OpenClaw
+додає до посилань на моделі префікс назви провайдера: `lmstudio/qwen/qwen3.5-9b`. Точний ключ
 моделі можна знайти, виконавши `curl http://localhost:1234/api/v1/models` і переглянувши поле `key`.
 
 ## Неінтерактивне початкове налаштування
 
-Використовуйте неінтерактивне початкове налаштування, якщо хочете автоматизувати налаштування (CI, підготовка середовища, віддалений bootstrap):
+Використовуйте неінтерактивне початкове налаштування, якщо хочете автоматизувати встановлення (CI, підготовка, віддалений bootstrap):
 
 ```bash
 openclaw onboard \
@@ -76,7 +76,7 @@ openclaw onboard \
   --auth-choice lmstudio
 ```
 
-Або вкажіть базову URL-адресу, модель і необов’язковий ключ API:
+Або вкажіть базову URL-адресу, модель і необов’язковий API-ключ:
 
 ```bash
 openclaw onboard \
@@ -94,20 +94,21 @@ openclaw onboard \
 Для автентифікованих серверів LM Studio передайте `--lmstudio-api-key` або встановіть `LM_API_TOKEN`.
 Для серверів LM Studio без автентифікації не вказуйте ключ; OpenClaw збереже локальний несекретний маркер.
 
-`--custom-api-key` і надалі підтримується для сумісності, але для LM Studio рекомендовано `--lmstudio-api-key`.
+`--custom-api-key` і надалі підтримується для сумісності, але для LM Studio бажано використовувати `--lmstudio-api-key`.
 
-Це записує `models.providers.lmstudio` і встановлює типову модель на
-`lmstudio/<custom-model-id>`. Якщо ви надаєте ключ API, налаштування також записує
+Це записує `models.providers.lmstudio` і встановлює типовою модель
+`lmstudio/<custom-model-id>`. Якщо ви надаєте API-ключ, налаштування також записує
 профіль автентифікації `lmstudio:default`.
 
 Інтерактивне налаштування може запропонувати вказати необов’язкову бажану довжину контексту завантаження та застосовує її до виявлених моделей LM Studio, які зберігає в конфігурації.
+Конфігурація plugin LM Studio довіряє налаштованій кінцевій точці LM Studio для запитів моделей, зокрема на хостах loopback, LAN і tailnet. Ви можете відмовитися від цього, встановивши `models.providers.lmstudio.request.allowPrivateNetwork: false`.
 
 ## Конфігурація
 
-### Сумісність із використанням streaming
+### Сумісність із використанням потокової передачі
 
-LM Studio сумісний із використанням streaming. Якщо він не повертає об’єкт
-`usage` у форматі OpenAI, OpenClaw відновлює кількість токенів із метаданих
+LM Studio сумісний із використанням потокової передачі. Якщо він не повертає
+об’єкт `usage` у форматі OpenAI, OpenClaw відновлює кількість токенів із метаданих
 `timings.prompt_n` / `timings.predicted_n` у стилі llama.cpp.
 
 Така сама поведінка застосовується до цих локальних бекендів, сумісних з OpenAI:
@@ -147,18 +148,18 @@ LM Studio сумісний із використанням streaming. Якщо
 }
 ```
 
-## Усунення проблем
+## Усунення несправностей
 
 ### LM Studio не виявлено
 
-Переконайтеся, що LM Studio запущено. Якщо автентифікацію ввімкнено, також установіть `LM_API_TOKEN`:
+Переконайтеся, що LM Studio запущено. Якщо автентифікацію увімкнено, також установіть `LM_API_TOKEN`:
 
 ```bash
 # Запуск через desktop-застосунок або в headless-режимі:
 lms server start --port 1234
 ```
 
-Перевірте, що API доступний:
+Переконайтеся, що API доступне:
 
 ```bash
 curl http://localhost:1234/api/v1/models
@@ -166,17 +167,38 @@ curl http://localhost:1234/api/v1/models
 
 ### Помилки автентифікації (HTTP 401)
 
-Якщо під час налаштування повідомляється про HTTP 401, перевірте свій ключ API:
+Якщо під час налаштування повідомляється про HTTP 401, перевірте ваш API-ключ:
 
 - Переконайтеся, що `LM_API_TOKEN` збігається з ключем, налаштованим у LM Studio.
-- Докладніше про налаштування автентифікації LM Studio дивіться в [LM Studio Authentication](https://lmstudio.ai/docs/developer/core/authentication).
+- Докладніше про налаштування автентифікації LM Studio див. у [LM Studio Authentication](https://lmstudio.ai/docs/developer/core/authentication).
 - Якщо ваш сервер не вимагає автентифікації, залиште ключ порожнім під час налаштування.
 
 ### Завантаження моделі just-in-time
 
-LM Studio підтримує завантаження моделей just-in-time (JIT), коли моделі завантажуються під час першого запиту. Переконайтеся, що це ввімкнено, щоб уникнути помилок «Model not loaded».
+LM Studio підтримує завантаження моделей just-in-time (JIT), коли моделі завантажуються під час першого запиту. Переконайтеся, що цю функцію увімкнено, щоб уникнути помилок на кшталт "Model not loaded".
 
-## Пов’язане
+### Хост LM Studio у LAN або tailnet
+
+Використовуйте досяжну адресу хоста LM Studio, зберігайте `/v1` і переконайтеся, що LM Studio на цій машині прив’язано не лише до loopback:
+
+```json5
+{
+  models: {
+    providers: {
+      lmstudio: {
+        baseUrl: "http://gpu-box.local:1234/v1",
+        apiKey: "lmstudio",
+        api: "openai-completions",
+        models: [{ id: "qwen/qwen3.5-9b" }],
+      },
+    },
+  },
+}
+```
+
+На відміну від загальних провайдерів, сумісних з OpenAI, `lmstudio` автоматично довіряє своїй налаштованій локальній/приватній кінцевій точці для захищених запитів моделей. Якщо ви використовуєте власний ідентифікатор провайдера замість `lmstudio`, явно встановіть `models.providers.<id>.request.allowPrivateNetwork: true`.
+
+## Пов’язані матеріали
 
 - [Вибір моделі](/uk/concepts/model-providers)
 - [Ollama](/uk/providers/ollama)