diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md
index 087c631dd..c83f32710 100644
--- a/docs/uk/help/testing.md
+++ b/docs/uk/help/testing.md
@@ -1,15 +1,15 @@
 ---
 read_when:
     - Запуск тестів локально або в CI
-    - Додавання регресій для багів моделей/провайдерів
-    - Налагодження поведінки gateway та агента
-summary: 'Набір для тестування: unit/e2e/live набори, Docker-ранери та те, що покриває кожен тест'
+    - Додавання регресій для помилок моделей/провайдерів
+    - Налагодження поведінки gateway та агентів
+summary: 'Набір для тестування: набори unit/e2e/live, Docker-ранери та що покриває кожен тест'
 title: Тестування
 x-i18n:
-    generated_at: "2026-04-06T18:35:13Z"
+    generated_at: "2026-04-06T18:52:08Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 002dba63f29e764e7f0cb91a71b7755022973278ee06e642c0a8f160825bdb2b
+    source_hash: 6c3497652c060ebbf6be6c742cc2fba708b5c7cce22220db7e67c0849dae11d6
     source_path: help/testing.md
     workflow: 15
 ---
@@ -20,7 +20,7 @@ OpenClaw має три набори Vitest (unit/integration, e2e, live) і не
 
 Цей документ — посібник «як ми тестуємо»:
 
-- Що покриває кожен набір (і чого він навмисно _не_ покриває)
+- Що покриває кожен набір (і що він навмисно _не_ покриває)
 - Які команди запускати для поширених сценаріїв (локально, перед push, налагодження)
 - Як live-тести знаходять облікові дані та вибирають моделі/провайдерів
 - Як додавати регресії для реальних проблем моделей/провайдерів
@@ -30,230 +30,230 @@ OpenClaw має три набори Vitest (unit/integration, e2e, live) і не
 У більшості випадків:
 
 - Повний gate (очікується перед push): `pnpm build && pnpm check && pnpm test`
-- Швидший локальний запуск усього набору на потужній машині: `pnpm test:max`
+- Швидший локальний запуск повного набору на потужній машині: `pnpm test:max`
 - Прямий цикл спостереження Vitest: `pnpm test:watch`
-- Пряме націлювання на файл тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts`
-- QA-сайт на базі Docker: `pnpm qa:lab:up`
+- Пряме націлювання на файл тепер також маршрутизує шляхи extensions/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts`
+- QA-сайт на основі Docker: `pnpm qa:lab:up`
 
-Коли ви змінюєте тести або хочете більше впевненості:
+Коли ви торкаєтеся тестів або хочете більше впевненості:
 
 - Gate покриття: `pnpm test:coverage`
 - Набір E2E: `pnpm test:e2e`
 
-Коли налагоджуєте реальні провайдери/моделі (потрібні справжні облікові дані):
+Коли налагоджуєте реальні провайдери/моделі (потрібні реальні облікові дані):
 
 - Live-набір (моделі + gateway tool/image probes): `pnpm test:live`
 - Тихо націлитися на один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts`
 
-Порада: коли потрібен лише один збійний випадок, краще звузити live-тести через env var allowlist, описані нижче.
+Порада: коли вам потрібен лише один збійний випадок, краще звузити live-тести через змінні середовища allowlist, описані нижче.
 
 ## Набори тестів (що де запускається)
 
-Думайте про ці набори як про «зростання реалістичності» (і зростання нестабільності/вартості):
+Думайте про набори як про «зростання реалістичності» (і зростання нестабільності/вартості):
 
 ### Unit / integration (типово)
 
 - Команда: `pnpm test`
-- Конфігурація: п’ять послідовних shard-запусків (`vitest.full-*.config.ts`) по наявних scoped-проєктах Vitest
-- Файли: core/unit inventory у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і дозволені node-тести `ui`, які покриває `vitest.unit.config.ts`
+- Конфігурація: п’ять послідовних запусків shard (`vitest.full-*.config.ts`) поверх наявних scoped-проєктів Vitest
+- Файли: core/unit inventories у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і whitelisted `ui` node-тести, які покриває `vitest.unit.config.ts`
 - Обсяг:
   - Чисті unit-тести
-  - Внутрішньопроцесні integration-тести (gateway auth, routing, tooling, parsing, config)
-  - Детерміновані регресії для відомих багів
+  - In-process integration-тести (gateway auth, routing, tooling, parsing, config)
+  - Детерміновані регресії для відомих помилок
 - Очікування:
   - Запускається в CI
   - Реальні ключі не потрібні
   - Має бути швидким і стабільним
-- Примітка щодо проєктів:
-  - Ненаправлений `pnpm test` тепер запускає вісім менших shard-конфігурацій (`core-unit-src`, `core-unit-security`, `core-unit-support`, `core-contracts`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного великого нативного root-project процесу. Це зменшує пікове RSS на завантажених машинах і не дає роботі `auto-reply`/extension виснажувати не пов’язані набори.
-  - `pnpm test --watch` усе ще використовує нативний граф проєктів root `vitest.config.ts`, тому що цикл спостереження з багатьма shard непрактичний.
-  - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спочатку маршрутизують явні цілі файлів/каталогів через scoped-лінії, тому `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає повної вартості старту root project.
-  - `pnpm test:changed` розгортає змінені git-шляхи в ті самі scoped-лінії, коли diff торкається лише маршрутизованих source/test-файлів; редагування config/setup усе ще повертаються до широкого повторного запуску root project.
-  - Окремі тести `plugin-sdk` і `commands` також маршрутизуються через спеціальні легкі лінії, які пропускають `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних лініях.
-  - Вибрані helper source-файли `plugin-sdk` і `commands` також зіставляють запуски в changed-режимі з явними сусідніми тестами в цих легких лініях, тож редагування helper-файлів не змушують перезапускати весь важкий набір для цього каталогу.
-  - `auto-reply` тепер має три окремі кошики: top-level core helper-и, top-level integration-тести `reply.*` і піддерево `src/auto-reply/reply/**`. Це не дає найважчій роботі harness відповіді потрапляти в дешеві тести status/chunk/token.
-- Примітка щодо embedded runner:
-  - Коли ви змінюєте вхідні дані виявлення message-tool або runtime context компактизації,
+- Примітка про проєкти:
+  - Ненацілений `pnpm test` тепер запускає вісім менших shard-конфігурацій (`core-unit-src`, `core-unit-security`, `core-unit-support`, `core-contracts`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного великого native root-project процесу. Це знижує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension блокувати не пов’язані набори.
+  - `pnpm test --watch` і далі використовує native root `vitest.config.ts` project graph, оскільки багатошардовий watch-цикл непрактичний.
+  - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спочатку маршрутизують явні цілі файл/каталог через scoped lanes, тому `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` не оплачує повний податок на запуск root project.
+  - `pnpm test:changed` розгортає змінені git-шляхи в ті самі scoped lanes, коли diff торкається лише routable source/test файлів; зміни config/setup усе ще повертаються до ширшого перезапуску root-project.
+  - Вибрані тести `plugin-sdk` і `commands` також маршрутизуються через окремі легкі lanes, що пропускають `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються в наявних lanes.
+  - Вибрані helper source-файли `plugin-sdk` і `commands` також зіставляють запуски в режимі changed із явними sibling-тестами в цих легких lanes, щоб зміни helper-файлів не змушували перезапускати весь важкий набір для цього каталогу.
+  - `auto-reply` тепер має три окремі buckets: top-level core helpers, top-level `reply.*` integration-тести та піддерево `src/auto-reply/reply/**`. Це не дає найважчій роботі harness reply заважати дешевим тестам status/chunk/token.
+- Примітка про embedded runner:
+  - Коли ви змінюєте вхідні дані для виявлення message-tool або runtime context compaction,
     зберігайте обидва рівні покриття.
   - Додавайте сфокусовані helper-регресії для чистих меж routing/normalization.
-  - Також підтримуйте здоровими integration-набори embedded runner:
+  - Також підтримуйте інтеграційні набори embedded runner у здоровому стані:
     `src/agents/pi-embedded-runner/compact.hooks.test.ts`,
     `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts`, і
     `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`.
-  - Ці набори перевіряють, що scoped id та поведінка компактизації все ще проходять
+  - Ці набори перевіряють, що scoped ids і поведінка compaction усе ще проходять
     через реальні шляхи `run.ts` / `compact.ts`; лише helper-тести не є
-    достатньою заміною для цих integration-шляхів.
-- Примітка щодо pool:
+    достатньою заміною для цих інтеграційних шляхів.
+- Примітка про pool:
   - Базова конфігурація Vitest тепер типово використовує `threads`.
-  - Спільна конфігурація Vitest також фіксує `isolate: false` і використовує неізольований runner у root projects, а також у конфігураціях e2e і live.
-  - Коренева лінія UI зберігає свій `jsdom` setup та optimizer, але тепер теж працює на спільному неізольованому runner.
-  - Кожен shard `pnpm test` успадковує ті самі типові значення `threads` + `isolate: false` зі спільної конфігурації Vitest.
-  - Спільний launcher `scripts/run-vitest.mjs` тепер також типово додає `--no-maglev` для дочірніх Node-процесів Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. Встановіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, якщо вам потрібно порівняти зі стандартною поведінкою V8.
-- Примітка щодо швидкої локальної ітерації:
-  - `pnpm test:changed` маршрутизує через scoped-лінії, коли змінені шляхи чисто мапляться на менший набір.
-  - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, лише з вищим лімітом воркерів.
-  - Автомасштабування локальних воркерів тепер навмисно консервативніше і також зменшується, коли середнє навантаження хоста вже високе, тож кілька одночасних запусків Vitest за замовчуванням завдають менше шкоди.
-  - Базова конфігурація Vitest позначає проєкти/конфігураційні файли як `forceRerunTriggers`, щоб повторні запуски в changed-режимі залишалися коректними, коли змінюється wiring тестів.
-  - Конфігурація зберігає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних хостах; встановіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете одну явну локацію кешу для прямого профілювання.
-- Примітка щодо perf-debug:
-  - `pnpm test:perf:imports` вмикає звітність Vitest про тривалість імпорту та вивід деталізації імпортів.
-  - `pnpm test:perf:imports:changed` звужує той самий профілювальний вигляд до файлів, змінених відносно `origin/main`.
-- `pnpm test:perf:changed:bench -- --ref <git-ref>` порівнює маршрутизований `test:changed` з нативним шляхом root project для цього committed diff і виводить wall time та macOS max RSS.
-- `pnpm test:perf:changed:bench -- --worktree` вимірює поточне dirty tree, маршрутизуючи список змінених файлів через `scripts/test-projects.mjs` і кореневу конфігурацію Vitest.
-  - `pnpm test:perf:profile:main` записує CPU-профіль main thread для накладних витрат старту та transform у Vitest/Vite.
-  - `pnpm test:perf:profile:runner` записує CPU+heap профілі runner для unit-набору з вимкненим file parallelism.
+  - Спільна конфігурація Vitest також фіксує `isolate: false` і використовує non-isolated runner для root projects, e2e та live конфігурацій.
+  - Root UI lane зберігає своє `jsdom`-налаштування й optimizer, але тепер також працює на спільному non-isolated runner.
+  - Кожен shard `pnpm test` успадковує ті самі типові `threads` + `isolate: false` зі спільної конфігурації Vitest.
+  - Спільний launcher `scripts/run-vitest.mjs` тепер також типово додає `--no-maglev` для дочірніх Node-процесів Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. Установіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, якщо потрібно порівняти зі стандартною поведінкою V8.
+- Примітка про швидку локальну ітерацію:
+  - `pnpm test:changed` маршрутизує через scoped lanes, коли змінені шляхи чітко зіставляються з меншим набором.
+  - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, лише з вищим лімітом worker-ів.
+  - Автомасштабування локальних worker-ів тепер навмисно консервативне й також відступає, коли середнє навантаження host уже високе, тому кілька одночасних запусків Vitest типово завдають менше шкоди.
+  - Базова конфігурація Vitest позначає проєкти/конфігураційні файли як `forceRerunTriggers`, щоб перезапуски в режимі changed залишалися коректними, коли змінюється тестова обв’язка.
+  - Конфігурація зберігає увімкненим `OPENCLAW_VITEST_FS_MODULE_CACHE` на підтримуваних host; установіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете одну явну локацію кешу для прямого профілювання.
+- Примітка про налагодження продуктивності:
+  - `pnpm test:perf:imports` вмикає звітність Vitest про тривалість import, а також вивід import-breakdown.
+  - `pnpm test:perf:imports:changed` обмежує той самий вигляд профілювання файлами, зміненими відносно `origin/main`.
+- `pnpm test:perf:changed:bench -- --ref <git-ref>` порівнює маршрутизований `test:changed` із native root-project шляхом для цього зафіксованого diff і виводить wall time та macOS max RSS.
+- `pnpm test:perf:changed:bench -- --worktree` вимірює поточне брудне дерево, маршрутизуючи список змінених файлів через `scripts/test-projects.mjs` і root Vitest config.
+  - `pnpm test:perf:profile:main` записує профіль CPU головного потоку для накладних витрат запуску і transform у Vitest/Vite.
+  - `pnpm test:perf:profile:runner` записує профілі CPU+heap runner-а для unit-набору з вимкненим файловим паралелізмом.
 
 ### E2E (gateway smoke)
 
 - Команда: `pnpm test:e2e`
 - Конфігурація: `vitest.e2e.config.ts`
 - Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts`
-- Типові налаштування runtime:
+- Типові параметри runtime:
   - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію.
-  - Використовує адаптивну кількість воркерів (CI: до 2, локально: 1 за замовчуванням).
-  - Типово запускається в silent-режимі, щоб зменшити накладні витрати console I/O.
-- Корисні override:
-  - `OPENCLAW_E2E_WORKERS=<n>` щоб примусово задати кількість воркерів (обмежено 16).
-  - `OPENCLAW_E2E_VERBOSE=1` щоб знову ввімкнути докладний вивід консолі.
+  - Використовує adaptive workers (CI: до 2, локально: 1 типово).
+  - Типово запускається в тихому режимі, щоб зменшити накладні витрати на консольний I/O.
+- Корисні перевизначення:
+  - `OPENCLAW_E2E_WORKERS=<n>` щоб примусово задати кількість worker-ів (обмежено 16).
+  - `OPENCLAW_E2E_VERBOSE=1` щоб знову ввімкнути докладний консольний вивід.
 - Обсяг:
-  - Наскрізна поведінка багатьох екземплярів gateway
-  - Поверхні WebSocket/HTTP, pairing вузлів і важче мережеве навантаження
+  - Наскрізна поведінка gateway з кількома екземплярами
+  - Поверхні WebSocket/HTTP, pairing вузлів і важча робота з мережею
 - Очікування:
-  - Запускається в CI (коли ввімкнено в pipeline)
+  - Запускається в CI (коли це ввімкнено в pipeline)
   - Реальні ключі не потрібні
   - Більше рухомих частин, ніж у unit-тестах (може бути повільніше)
 
-### E2E: OpenShell backend smoke
+### E2E: smoke бекенда OpenShell
 
 - Команда: `pnpm test:e2e:openshell`
 - Файл: `test/openshell-sandbox.e2e.test.ts`
 - Обсяг:
-  - Запускає ізольований OpenShell gateway на хості через Docker
-  - Створює sandbox з тимчасового локального Dockerfile
-  - Перевіряє backend OpenShell в OpenClaw через реальні `sandbox ssh-config` + SSH exec
+  - Запускає ізольований gateway OpenShell на host через Docker
+  - Створює sandbox із тимчасового локального Dockerfile
+  - Перевіряє бекенд OpenShell у OpenClaw через реальні `sandbox ssh-config` + SSH exec
   - Перевіряє remote-canonical поведінку файлової системи через sandbox fs bridge
 - Очікування:
-  - Лише opt-in; не входить до типового запуску `pnpm test:e2e`
-  - Потрібен локальний `openshell` CLI і робочий Docker daemon
-  - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, потім знищує тестовий gateway і sandbox
-- Корисні override:
+  - Лише opt-in; не входить у типовий запуск `pnpm test:e2e`
+  - Потрібен локальний CLI `openshell` і працездатний Docker daemon
+  - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує test gateway і sandbox
+- Корисні перевизначення:
   - `OPENCLAW_E2E_OPENSHELL=1` щоб увімкнути тест при ручному запуску ширшого e2e-набору
-  - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` щоб вказати нестандартний CLI binary або wrapper script
+  - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` щоб указати нестандартний CLI binary або wrapper script
 
 ### Live (реальні провайдери + реальні моделі)
 
 - Команда: `pnpm test:live`
 - Конфігурація: `vitest.live.config.ts`
 - Файли: `src/**/*.live.test.ts`
-- Типово: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`)
+- Типово: **увімкнено** командою `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`)
 - Обсяг:
   - «Чи справді цей провайдер/модель працює _сьогодні_ з реальними обліковими даними?»
   - Виявлення змін формату провайдера, особливостей tool calling, проблем auth і поведінки rate limit
 - Очікування:
-  - Навмисно нестабільний для CI (реальні мережі, реальні політики провайдерів, квоти, збої)
-  - Коштує грошей / використовує ліміти запитів
+  - За задумом не є стабільним для CI (реальні мережі, реальні політики провайдерів, квоти, збої)
+  - Коштує грошей / використовує rate limits
   - Краще запускати звужені підмножини, а не «все»
-- Live-запуски підвантажують `~/.profile`, щоб підхопити відсутні API-ключі.
-- Типово live-запуски все одно ізолюють `HOME` і копіюють config/auth-матеріали до тимчасового тестового home, щоб unit-fixture-и не могли змінити ваш реальний `~/.openclaw`.
-- Встановлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли свідомо хочете, щоб live-тести використовували ваш реальний home directory.
-- `pnpm test:live` тепер типово працює в тихішому режимі: він зберігає вивід прогресу `[live] ...`, але приглушує додаткове повідомлення про `~/.profile` і вимикає логи bootstrap gateway/шум Bonjour. Встановіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні стартові логи.
-- Ротація API-ключів (залежно від провайдера): встановіть `*_API_KEYS` у форматі через кому/крапку з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) чи per-live override через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу при відповідях із rate limit.
+- Live-запуски використовують `~/.profile`, щоб підхопити відсутні API-ключі.
+- Типово live-запуски все одно ізолюють `HOME` і копіюють config/auth-матеріали в тимчасовий test home, щоб unit-fixtures не могли змінити ваш реальний `~/.openclaw`.
+- Установлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли навмисно хочете, щоб live-тести використовували ваш реальний домашній каталог.
+- `pnpm test:live` тепер типово працює в тихішому режимі: він зберігає вивід прогресу `[live] ...`, але пригнічує додаткове повідомлення про `~/.profile` і вимикає gateway bootstrap logs/Bonjour chatter. Установіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні startup logs.
+- Ротація API-ключів (специфічно для провайдера): задавайте `*_API_KEYS` у форматі з комами/крапками з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або специфічне перевизначення для live через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу при відповідях з rate limit.
 - Вивід прогресу/heartbeat:
-  - Live-набори тепер виводять рядки прогресу в stderr, щоб під час довгих викликів провайдера було видно активність, навіть коли перехоплення консолі Vitest тихе.
-  - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, тож рядки прогресу провайдера/gateway одразу транслюються під час live-запусків.
-  - Налаштовуйте heartbeat direct-model через `OPENCLAW_LIVE_HEARTBEAT_MS`.
-  - Налаштовуйте heartbeat gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`.
+  - Live-набори тепер виводять рядки прогресу в stderr, тому тривалі виклики провайдерів помітно активні навіть коли захоплення консолі Vitest тихе.
+  - `vitest.live.config.ts` вимикає перехоплення консолі у Vitest, щоб рядки прогресу провайдера/gateway відразу транслювалися під час live-запусків.
+  - Налаштувати heartbeat для прямих моделей можна через `OPENCLAW_LIVE_HEARTBEAT_MS`.
+  - Налаштувати heartbeat для gateway/probe можна через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`.
 
 ## Який набір мені запускати?
 
-Скористайтеся цією таблицею рішень:
+Використовуйте цю таблицю рішень:
 
 - Редагуєте логіку/тести: запускайте `pnpm test` (і `pnpm test:coverage`, якщо змінили багато)
-- Торкаєтесь мережевої взаємодії gateway / WS protocol / pairing: додайте `pnpm test:e2e`
+- Торкаєтесь gateway networking / WS protocol / pairing: додайте `pnpm test:e2e`
 - Налагоджуєте «мій бот не працює» / специфічні для провайдера збої / tool calling: запускайте звужений `pnpm test:live`
 
-## Live: перевірка можливостей Android node
+## Live: sweep capability вузла Android
 
 - Тест: `src/gateway/android-node.capabilities.live.test.ts`
 - Скрипт: `pnpm android:test:integration`
-- Мета: викликати **кожну команду, яка наразі рекламується** підключеним Android node, і перевірити поведінку контракту команди.
+- Мета: викликати **кожну команду, яка зараз оголошується** підключеним Android-вузлом, і перевірити поведінку контракту команди.
 - Обсяг:
-  - Налаштований вручну попередній стан (набір не встановлює/не запускає/не pair-ить застосунок).
-  - Перевірка `node.invoke` gateway команда за командою для вибраного Android node.
+  - Попередньо підготовлене/ручне налаштування (набір не встановлює, не запускає і не pair-ить застосунок).
+  - Перевірка `node.invoke` gateway для вибраного Android-вузла, команда за командою.
 - Обов’язкова попередня підготовка:
-  - Android-застосунок уже підключений і paired із gateway.
-  - Застосунок залишається на передньому плані.
-  - Надано дозволи/згоду на захоплення для можливостей, які ви очікуєте успішно пройти.
-- Необов’язкові override цілі:
+  - Android-застосунок уже підключено і pair-ено до gateway.
+  - Застосунок утримується на передньому плані.
+  - Для capability, які мають пройти, надані дозволи/consent на захоплення.
+- Необов’язкові перевизначення цілі:
   - `OPENCLAW_ANDROID_NODE_ID` або `OPENCLAW_ANDROID_NODE_NAME`.
   - `OPENCLAW_ANDROID_GATEWAY_URL` / `OPENCLAW_ANDROID_GATEWAY_TOKEN` / `OPENCLAW_ANDROID_GATEWAY_PASSWORD`.
 - Повні деталі налаштування Android: [Android App](/uk/platforms/android)
 
-## Live: smoke моделі (ключі профілів)
+## Live: smoke моделей (profile keys)
 
 Live-тести поділено на два шари, щоб можна було ізолювати збої:
 
-- «Direct model» показує, чи може провайдер/модель взагалі відповісти з даним ключем.
+- «Direct model» показує, чи взагалі може відповісти провайдер/модель із заданим ключем.
 - «Gateway smoke» показує, чи працює повний pipeline gateway+agent для цієї моделі (sessions, history, tools, sandbox policy тощо).
 
-### Шар 1: Direct model completion (без gateway)
+### Шар 1: пряме завершення моделі (без gateway)
 
 - Тест: `src/agents/models.profiles.live.test.ts`
 - Мета:
-  - Перелічити знайдені моделі
-  - Використати `getApiKeyForModel`, щоб вибрати моделі, для яких у вас є облікові дані
-  - Виконати маленьке completion для кожної моделі (і цільові регресії там, де потрібно)
+  - Перерахувати виявлені моделі
+  - Використати `getApiKeyForModel` для вибору моделей, для яких у вас є облікові дані
+  - Виконати невелике completion для кожної моделі (і targeted-регресії там, де потрібно)
 - Як увімкнути:
   - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму)
-- Встановіть `OPENCLAW_LIVE_MODELS=modern` (або `all`, псевдонім для modern), щоб цей набір справді запускався; інакше він буде пропущений, щоб `pnpm test:live` залишався зосередженим на gateway smoke
+- Установіть `OPENCLAW_LIVE_MODELS=modern` (або `all`, псевдонім для modern), щоб дійсно запустити цей набір; інакше він пропуститься, щоб `pnpm test:live` залишався сфокусованим на gateway smoke
 - Як вибирати моделі:
-  - `OPENCLAW_LIVE_MODELS=modern` щоб запустити modern allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
+  - `OPENCLAW_LIVE_MODELS=modern`, щоб запустити modern allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
   - `OPENCLAW_LIVE_MODELS=all` — це псевдонім для modern allowlist
   - або `OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..."` (allowlist через кому)
 - Як вибирати провайдерів:
   - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (allowlist через кому)
 - Звідки беруться ключі:
-  - Типово: profile store і env fallback-и
-  - Встановіть `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати **лише profile store**
+  - Типово: profile store і резервні варіанти з env
+  - Установіть `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати **лише profile store**
 - Навіщо це існує:
-  - Відокремлює «API провайдера зламане / ключ невалідний» від «pipeline gateway agent зламаний»
-  - Містить малі, ізольовані регресії (приклад: OpenAI Responses/Codex Responses reasoning replay + потоки tool-call)
+  - Відділяє «API провайдера зламане / ключ недійсний» від «pipeline gateway agent зламаний»
+  - Містить малі, ізольовані регресії (приклад: reasoning replay + tool-call flows у OpenAI Responses/Codex Responses)
 
-### Шар 2: Gateway + smoke dev agent (те, що насправді робить "@openclaw")
+### Шар 2: Gateway + smoke dev agent (що насправді робить "@openclaw")
 
 - Тест: `src/gateway/gateway-models.profiles.live.test.ts`
 - Мета:
-  - Підняти внутрішньопроцесний gateway
-  - Створити/оновити session `agent:dev:*` (override моделі для кожного запуску)
-  - Перебрати моделі-із-ключами й перевірити:
+  - Підняти in-process gateway
+  - Створити/оновити session `agent:dev:*` (із перевизначенням моделі для кожного запуску)
+  - Перебрати моделі з ключами і перевірити:
     - «змістовну» відповідь (без tools)
     - що працює реальний виклик tool (read probe)
-    - необов’язкові додаткові tool-probe (exec+read probe)
-    - що регресійні шляхи OpenAI (лише tool-call → follow-up) продовжують працювати
-- Деталі probe (щоб можна було швидко пояснювати збої):
-  - `read` probe: тест записує nonce-файл у workspace і просить агента `read` його та повернути nonce.
-  - `exec+read` probe: тест просить агента через `exec` записати nonce у тимчасовий файл, а потім через `read` прочитати його назад.
-  - image probe: тест додає згенерований PNG (cat + випадковий код) і очікує, що модель поверне `cat <CODE>`.
+    - необов’язкові додаткові tool probes (exec+read probe)
+    - що регресійні шляхи OpenAI (лише tool-call → follow-up) і далі працюють
+- Деталі probe (щоб ви могли швидко пояснювати збої):
+  - `read` probe: тест записує файл із nonce у workspace і просить агента `read` його та повторити nonce у відповіді.
+  - `exec+read` probe: тест просить агента записати nonce у тимчасовий файл через `exec`, а потім прочитати його через `read`.
+  - image probe: тест прикріплює згенерований PNG (cat + випадковий code) і очікує, що модель поверне `cat <CODE>`.
   - Посилання на реалізацію: `src/gateway/gateway-models.profiles.live.test.ts` і `src/gateway/live-image-probe.ts`.
 - Як увімкнути:
   - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму)
 - Як вибирати моделі:
   - Типово: modern allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
   - `OPENCLAW_LIVE_GATEWAY_MODELS=all` — це псевдонім для modern allowlist
-  - Або встановіть `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (або список через кому), щоб звузити
-- Як вибирати провайдерів (уникати «все з OpenRouter»):
+  - Або задайте `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (або список через кому), щоб звузити
+- Як вибирати провайдерів (уникнути «всього OpenRouter»):
   - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (allowlist через кому)
-- Tool + image probes у цьому live-тесті завжди увімкнені:
-  - `read` probe + `exec+read` probe (навантаження на tools)
-  - image probe запускається, коли модель заявляє підтримку image input
-  - Потік (високий рівень):
-    - Тест генерує маленький PNG з «CAT» + випадковим кодом (`src/gateway/live-image-probe.ts`)
+- Tool + image probes у цьому live-тесті завжди ввімкнені:
+  - `read` probe + `exec+read` probe (stress tool)
+  - image probe запускається, коли модель оголошує підтримку image input
+  - Потік (високорівнево):
+    - Тест генерує крихітний PNG із “CAT” + випадковим code (`src/gateway/live-image-probe.ts`)
     - Надсилає його через `agent` `attachments: [{ mimeType: "image/png", content: "<base64>" }]`
     - Gateway розбирає attachments у `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`)
-    - Embedded agent пересилає multimodal user message моделі
-    - Перевірка: відповідь містить `cat` + код (допускається OCR-похибка: невеликі помилки дозволені)
+    - Embedded agent передає моделі multimodal user message
+    - Перевірка: відповідь містить `cat` + code (допускаються незначні OCR-помилки)
 
-Порада: щоб побачити, що можна тестувати на вашій машині (і точні ідентифікатори `provider/model`), виконайте:
+Порада: щоб побачити, що саме можна тестувати на вашій машині (і точні ідентифікатори `provider/model`), виконайте:
 
 ```bash
 openclaw models list
@@ -263,7 +263,7 @@ openclaw models list --json
 ## Live: smoke CLI backend (Codex CLI або інші локальні CLI)
 
 - Тест: `src/gateway/gateway-cli-backend.live.test.ts`
-- Мета: перевірити pipeline Gateway + agent, використовуючи локальний CLI backend, не торкаючись вашого типового config.
+- Мета: перевірити pipeline Gateway + agent за допомогою локального CLI backend, не торкаючись вашої типової конфігурації.
 - Увімкнення:
   - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму)
   - `OPENCLAW_LIVE_CLI_BACKEND=1`
@@ -271,14 +271,14 @@ openclaw models list --json
   - Модель: `codex-cli/gpt-5.4`
   - Команда: `codex`
   - Аргументи: `["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]`
-- Override-и (необов’язково):
+- Перевизначення (необов’язково):
   - `OPENCLAW_LIVE_CLI_BACKEND_MODEL="codex-cli/gpt-5.4"`
   - `OPENCLAW_LIVE_CLI_BACKEND_COMMAND="/full/path/to/codex"`
   - `OPENCLAW_LIVE_CLI_BACKEND_ARGS='["exec","--json","--color","never","--sandbox","read-only","--skip-git-repo-check"]'`
-  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` щоб надіслати реальний image attachment (шляхи ін’єктуються в prompt).
-  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` щоб передавати шляхи до image-файлів як CLI args замість ін’єкції в prompt.
-  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (або `"list"`) щоб керувати передаванням image args, коли задано `IMAGE_ARG`.
-  - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1` щоб надіслати другий turn і перевірити потік resume.
+  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1`, щоб надіслати реальне image-attachment (шляхи вставляються в prompt).
+  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, щоб передавати шляхи до image-файлів як CLI args замість вставки в prompt.
+  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (або `"list"`), щоб керувати способом передавання image args, коли встановлено `IMAGE_ARG`.
+  - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, щоб надіслати другий хід і перевірити flow відновлення.
 
 Приклад:
 
@@ -288,7 +288,7 @@ OPENCLAW_LIVE_CLI_BACKEND=1 \
   pnpm test:live src/gateway/gateway-cli-backend.live.test.ts
 ```
 
-Docker-рецепт:
+Рецепт для Docker:
 
 ```bash
 pnpm test:docker:live-cli-backend
@@ -296,32 +296,32 @@ pnpm test:docker:live-cli-backend
 
 Примітки:
 
-- Docker-ранер розташований у `scripts/test-live-cli-backend-docker.sh`.
+- Docker-ранер знаходиться в `scripts/test-live-cli-backend-docker.sh`.
 - Він запускає live smoke CLI-backend усередині Docker-образу репозиторію як непривілейований користувач `node`.
-- Для `codex-cli` він встановлює Linux-пакет `@openai/codex` у кешований доступний для запису префікс за адресою `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (типово: `~/.cache/openclaw/docker-cli-tools`).
+- Для `codex-cli` він встановлює Linux-пакет `@openai/codex` у кешований записуваний префікс за адресою `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (типово: `~/.cache/openclaw/docker-cli-tools`).
 
-## Live: ACP bind smoke (`/acp spawn ... --bind here`)
+## Live: smoke прив’язки ACP (`/acp spawn ... --bind here`)
 
 - Тест: `src/gateway/gateway-acp-bind.live.test.ts`
-- Мета: перевірити реальний потік conversation-bind ACP з live ACP agent:
+- Мета: перевірити реальний flow conversation-bind ACP із live ACP-агентом:
   - надіслати `/acp spawn <agent> --bind here`
-  - прив’язати synthetic message-channel conversation на місці
-  - надіслати звичайний follow-up у тій самій conversation
-  - перевірити, що follow-up потрапляє в transcript прив’язаної ACP session
+  - прив’язати синтетичну conversation message-channel на місці
+  - надіслати звичайний follow-up у цій самій conversation
+  - перевірити, що follow-up потрапляє в transcript прив’язаної ACP-сесії
 - Увімкнення:
   - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts`
   - `OPENCLAW_LIVE_ACP_BIND=1`
 - Типові значення:
-  - ACP agent: `claude`
-  - Synthetic channel: Slack DM-style context conversation
+  - ACP-агент: `claude`
+  - Синтетичний channel: контекст conversation у стилі Slack DM
   - ACP backend: `acpx`
-- Override-и:
+- Перевизначення:
   - `OPENCLAW_LIVE_ACP_BIND_AGENT=claude`
   - `OPENCLAW_LIVE_ACP_BIND_AGENT=codex`
   - `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@<version>'`
 - Примітки:
-  - Ця лінія використовує поверхню gateway `chat.send` з synthetic originating-route fields лише для admin, щоб тести могли додавати context message-channel без удавання зовнішньої доставки.
-  - Коли `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` не встановлено, тест використовує вбудований реєстр агентів плагіна `acpx` для вибраного ACP harness agent.
+  - Ця lane використовує поверхню gateway `chat.send` з admin-only synthetic originating-route fields, щоб тести могли додавати контекст message-channel без удавання зовнішньої доставки.
+  - Коли `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` не задано, тест використовує вбудований registry агентів плагіна `acpx` для вибраного ACP harness-агента.
 
 Приклад:
 
@@ -331,21 +331,21 @@ OPENCLAW_LIVE_ACP_BIND=1 \
   pnpm test:live src/gateway/gateway-acp-bind.live.test.ts
 ```
 
-Docker-рецепт:
+Рецепт для Docker:
 
 ```bash
 pnpm test:docker:live-acp-bind
 ```
 
-Примітки щодо Docker:
+Примітки для Docker:
 
-- Docker-ранер розташований у `scripts/test-live-acp-bind-docker.sh`.
-- Він підвантажує `~/.profile`, переносить відповідний CLI auth-material у контейнер, встановлює `acpx` у доступний для запису npm-префікс, а потім встановлює запитуваний live CLI (`@anthropic-ai/claude-code` або `@openai/codex`), якщо він відсутній.
-- Усередині Docker раннер встановлює `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, щоб `acpx` зберігав provider env vars із завантаженого профілю доступними для дочірнього harness CLI.
+- Docker-ранер знаходиться в `scripts/test-live-acp-bind-docker.sh`.
+- Він виконує `source ~/.profile`, підкладає відповідні CLI auth-матеріали в контейнер, встановлює `acpx` у записуваний npm-префікс, а потім встановлює потрібний live CLI (`@anthropic-ai/claude-code` або `@openai/codex`), якщо його немає.
+- Усередині Docker раннер установлює `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, щоб acpx зберігав змінні середовища провайдера з підключеного profile доступними для дочірнього harness CLI.
 
 ### Рекомендовані live-рецепти
 
-Вузькі, явні allowlist-и — найшвидші й найменш нестабільні:
+Звужені, явні allowlist-и — найшвидші та найменш нестабільні:
 
 - Одна модель, direct (без gateway):
   - `OPENCLAW_LIVE_MODELS="openai/gpt-5.4" pnpm test:live src/agents/models.profiles.live.test.ts`
@@ -356,31 +356,31 @@ pnpm test:docker:live-acp-bind
 - Tool calling у кількох провайдерів:
   - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3-flash-preview,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`
 
-- Фокус на Google (API key Gemini + Antigravity):
+- Фокус на Google (API-ключ Gemini + Antigravity):
   - Gemini (API key): `OPENCLAW_LIVE_GATEWAY_MODELS="google/gemini-3-flash-preview" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`
   - Antigravity (OAuth): `OPENCLAW_LIVE_GATEWAY_MODELS="google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-pro-high" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`
 
 Примітки:
 
 - `google/...` використовує Gemini API (API key).
-- `google-antigravity/...` використовує Antigravity OAuth bridge (Cloud Code Assist-style endpoint агента).
+- `google-antigravity/...` використовує міст Antigravity OAuth (endpoint агента в стилі Cloud Code Assist).
 - `google-gemini-cli/...` використовує локальний Gemini CLI на вашій машині (окрема auth + особливості tooling).
 - Gemini API проти Gemini CLI:
-  - API: OpenClaw викликає хостований Google Gemini API через HTTP (API key / profile auth); це те, що більшість користувачів мають на увазі під «Gemini».
-  - CLI: OpenClaw виконує локальний binary `gemini`; він має власну auth і може поводитися інакше (streaming/tool support/version skew).
+  - API: OpenClaw викликає хостований Gemini API від Google через HTTP (auth через API key / profile); саме це більшість користувачів мають на увазі під “Gemini”.
+  - CLI: OpenClaw викликає локальний binary `gemini`; він має власну auth і може поводитися інакше (streaming/tool support/version skew).
 
 ## Live: матриця моделей (що ми покриваємо)
 
-Фіксованого «списку моделей CI» немає (live — opt-in), але це **рекомендовані** моделі для регулярного покриття на dev-машині з ключами.
+Фіксованого «списку моделей CI» немає (live — це opt-in), але це **рекомендовані** моделі для регулярного покриття на dev-машині з ключами.
 
 ### Сучасний smoke-набір (tool calling + image)
 
-Це запуск «поширених моделей», який ми очікуємо підтримувати працездатним:
+Це запуск «поширених моделей», який ми очікуємо зберігати працездатним:
 
-- OpenAI (не-Codex): `openai/gpt-5.4` (необов’язково: `openai/gpt-5.4-mini`)
+- OpenAI (не Codex): `openai/gpt-5.4` (необов’язково: `openai/gpt-5.4-mini`)
 - OpenAI Codex: `openai-codex/gpt-5.4`
 - Anthropic: `anthropic/claude-opus-4-6` (або `anthropic/claude-sonnet-4-6`)
-- Google (Gemini API): `google/gemini-3.1-pro-preview` і `google/gemini-3-flash-preview` (уникайте старих моделей Gemini 2.x)
+- Google (Gemini API): `google/gemini-3.1-pro-preview` і `google/gemini-3-flash-preview` (уникайте старіших моделей Gemini 2.x)
 - Google (Antigravity): `google-antigravity/claude-opus-4-6-thinking` і `google-antigravity/gemini-3-flash`
 - Z.AI (GLM): `zai/glm-4.7`
 - MiniMax: `minimax/MiniMax-M2.7`
@@ -390,7 +390,7 @@ pnpm test:docker:live-acp-bind
 
 ### Базовий рівень: tool calling (Read + необов’язковий Exec)
 
-Виберіть щонайменше одну модель для кожного сімейства провайдерів:
+Виберіть щонайменше по одній моделі на сімейство провайдерів:
 
 - OpenAI: `openai/gpt-5.4` (або `openai/gpt-5.4-mini`)
 - Anthropic: `anthropic/claude-opus-4-6` (або `anthropic/claude-sonnet-4-6`)
@@ -398,46 +398,46 @@ pnpm test:docker:live-acp-bind
 - Z.AI (GLM): `zai/glm-4.7`
 - MiniMax: `minimax/MiniMax-M2.7`
 
-Необов’язкове додаткове покриття (було б добре мати):
+Необов’язкове додаткове покриття (приємно мати):
 
-- xAI: `xai/grok-4` (або найновіша доступна)
-- Mistral: `mistral/`… (виберіть одну модель із підтримкою `tools`, яку у вас увімкнено)
-- Cerebras: `cerebras/`… (якщо у вас є доступ)
+- xAI: `xai/grok-4` (або найновішу доступну)
+- Mistral: `mistral/`… (виберіть одну модель із підтримкою “tools”, яку у вас ввімкнено)
+- Cerebras: `cerebras/`… (якщо маєте доступ)
 - LM Studio: `lmstudio/`… (локально; tool calling залежить від режиму API)
 
 ### Vision: надсилання image (attachment → multimodal message)
 
-Додайте щонайменше одну image-capable модель у `OPENCLAW_LIVE_GATEWAY_MODELS` (Claude/Gemini/варіанти OpenAI з підтримкою vision тощо), щоб перевірити image probe.
+Додайте щонайменше одну модель із підтримкою image у `OPENCLAW_LIVE_GATEWAY_MODELS` (Claude/Gemini/варіанти OpenAI із підтримкою vision тощо), щоб перевірити image probe.
 
 ### Агрегатори / альтернативні gateway
 
 Якщо у вас увімкнені ключі, ми також підтримуємо тестування через:
 
-- OpenRouter: `openrouter/...` (сотні моделей; використовуйте `openclaw models scan`, щоб знайти кандидатів із підтримкою tool+image)
+- OpenRouter: `openrouter/...` (сотні моделей; використовуйте `openclaw models scan`, щоб знайти придатні candidates з tool+image)
 - OpenCode: `opencode/...` для Zen і `opencode-go/...` для Go (auth через `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`)
 
-Інші провайдери, які можна включити в live-матрицю (якщо у вас є облікові дані/config):
+Інші провайдери, які можна включити до live-матриці (якщо у вас є облікові дані/конфігурація):
 
 - Вбудовані: `openai`, `openai-codex`, `anthropic`, `google`, `google-vertex`, `google-antigravity`, `google-gemini-cli`, `zai`, `openrouter`, `opencode`, `opencode-go`, `xai`, `groq`, `cerebras`, `mistral`, `github-copilot`
-- Через `models.providers` (custom endpoints): `minimax` (cloud/API), а також будь-який проксі, сумісний з OpenAI/Anthropic (LM Studio, vLLM, LiteLLM тощо)
+- Через `models.providers` (custom endpoints): `minimax` (cloud/API), а також будь-який сумісний із OpenAI/Anthropic proxy (LM Studio, vLLM, LiteLLM тощо)
 
-Порада: не намагайтеся жорстко зашивати в документацію «всі моделі». Авторитетний список — це те, що повертає `discoverModels(...)` на вашій машині + які ключі доступні.
+Порада: не намагайтеся жорстко зафіксувати «усі моделі» в документації. Авторитетний список — це те, що повертає `discoverModels(...)` на вашій машині, плюс доступні ключі.
 
 ## Облікові дані (ніколи не комітьте)
 
-Live-тести знаходять облікові дані так само, як це робить CLI. Практичні наслідки:
+Live-тести знаходять облікові дані так само, як і CLI. Практичні наслідки:
 
-- Якщо CLI працює, live-тести мають знайти ті самі ключі.
+- Якщо CLI працює, live-тести мають знаходити ті самі ключі.
 - Якщо live-тест каже «немає облікових даних», налагоджуйте це так само, як налагоджували б `openclaw models list` / вибір моделі.
 
-- Auth-профілі per-agent: `~/.openclaw/agents/<agentId>/agent/auth-profiles.json` (саме це означає «profile keys» у live-тестах)
-- Config: `~/.openclaw/openclaw.json` (або `OPENCLAW_CONFIG_PATH`)
-- Директорія legacy state: `~/.openclaw/credentials/` (копіюється в staged live home, якщо присутня, але не є основним сховищем ключів профілів)
-- Локальні live-запуски типово копіюють активний config, файли per-agent `auth-profiles.json`, legacy `credentials/` і підтримувані external CLI auth dirs у тимчасовий test home; override-и шляхів `agents.*.workspace` / `agentDir` прибираються з цього staged config, щоб probe-и не торкалися вашого реального host workspace.
+- Профілі auth на рівні агента: `~/.openclaw/agents/<agentId>/agent/auth-profiles.json` (саме це означає “profile keys” у live-тестах)
+- Конфігурація: `~/.openclaw/openclaw.json` (або `OPENCLAW_CONFIG_PATH`)
+- Застарілий state dir: `~/.openclaw/credentials/` (копіюється в staged live home, якщо існує, але це не основне сховище profile-key)
+- Локальні live-запуски типово копіюють активний config, файли `auth-profiles.json` для кожного агента, застарілий `credentials/` і підтримувані external CLI auth dirs у тимчасовий test home; перевизначення шляхів `agents.*.workspace` / `agentDir` прибираються в staged config, щоб probes не працювали у вашому реальному host workspace.
 
-Якщо хочете покладатися на env keys (наприклад, експортовані у вашому `~/.profile`), запускайте локальні тести після `source ~/.profile` або використовуйте Docker-ранери нижче (вони можуть монтувати `~/.profile` у контейнер).
+Якщо ви хочете покладатися на env-ключі (наприклад, експортовані у ваш `~/.profile`), запускайте локальні тести після `source ~/.profile`, або використовуйте Docker-ранери нижче (вони можуть монтувати `~/.profile` у контейнер).
 
-## Deepgram live (транскрибування аудіо)
+## Deepgram live (транскрипція аудіо)
 
 - Тест: `src/media-understanding/providers/deepgram/audio.live.test.ts`
 - Увімкнення: `DEEPGRAM_API_KEY=... DEEPGRAM_LIVE_TEST=1 pnpm test:live src/media-understanding/providers/deepgram/audio.live.test.ts`
@@ -446,28 +446,28 @@ Live-тести знаходять облікові дані так само, я
 
 - Тест: `src/agents/byteplus.live.test.ts`
 - Увімкнення: `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live src/agents/byteplus.live.test.ts`
-- Необов’язковий override моделі: `BYTEPLUS_CODING_MODEL=ark-code-latest`
+- Необов’язкове перевизначення моделі: `BYTEPLUS_CODING_MODEL=ark-code-latest`
 
 ## ComfyUI workflow media live
 
 - Тест: `extensions/comfy/comfy.live.test.ts`
 - Увімкнення: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts`
 - Обсяг:
-  - Перевіряє вбудовані шляхи comfy для image, video та `music_generate`
-  - Пропускає кожну можливість, якщо `models.providers.comfy.<capability>` не налаштовано
-  - Корисно після змін у поданні comfy workflow, polling, downloads або реєстрації plugin
+  - Перевіряє вбудовані шляхи comfy image, video і `music_generate`
+  - Пропускає кожну capability, якщо `models.providers.comfy.<capability>` не налаштовано
+  - Корисно після змін у comfy workflow submission, polling, downloads або реєстрації плагіна
 
-## Live генерації зображень
+## Image generation live
 
 - Тест: `src/image-generation/runtime.live.test.ts`
 - Команда: `pnpm test:live src/image-generation/runtime.live.test.ts`
 - Harness: `pnpm test:live:media image`
 - Обсяг:
-  - Перелічує кожен зареєстрований provider plugin генерації зображень
-  - Завантажує відсутні provider env vars із вашого login shell (`~/.profile`) перед probe
+  - Перераховує кожен зареєстрований provider plugin для image generation
+  - Завантажує відсутні provider env vars з вашого login shell (`~/.profile`) перед probe
   - Типово використовує live/env API keys раніше за збережені auth profiles, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні shell credentials
-  - Пропускає провайдерів без придатних auth/profile/model
-  - Проганяє стандартні варіанти генерації зображень через спільну runtime capability:
+  - Пропускає провайдерів без придатного auth/profile/model
+  - Запускає стандартні варіанти image generation через shared runtime capability:
     - `google:flash-generate`
     - `google:pro-generate`
     - `google:pro-edit`
@@ -480,68 +480,71 @@ Live-тести знаходять облікові дані так само, я
   - `OPENCLAW_LIVE_IMAGE_GENERATION_MODELS="openai/gpt-image-1,google/gemini-3.1-flash-image-preview"`
   - `OPENCLAW_LIVE_IMAGE_GENERATION_CASES="google:flash-generate,google:pro-edit"`
 - Необов’язкова поведінка auth:
-  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб примусово використовувати auth зі сховища профілів і ігнорувати override-и лише з env
+  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати auth із profile store та ігнорувати env-only перевизначення
 
-## Live генерації музики
+## Music generation live
 
 - Тест: `extensions/music-generation-providers.live.test.ts`
 - Увімкнення: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/music-generation-providers.live.test.ts`
 - Harness: `pnpm test:live:media music`
 - Обсяг:
-  - Перевіряє спільний шлях bundled music-generation provider
+  - Перевіряє спільний вбудований шлях provider-а для music generation
   - Наразі покриває Google і MiniMax
   - Завантажує provider env vars із вашого login shell (`~/.profile`) перед probe
   - Типово використовує live/env API keys раніше за збережені auth profiles, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні shell credentials
-  - Пропускає провайдерів без придатних auth/profile/model
-  - Запускає обидва заявлені runtime-режими, коли вони доступні:
-    - `generate` із вхідними даними лише prompt
+  - Пропускає провайдерів без придатного auth/profile/model
+  - Запускає обидва оголошені runtime-режими, коли вони доступні:
+    - `generate` із вводом лише prompt
     - `edit`, коли провайдер оголошує `capabilities.edit.enabled`
-  - Поточне покриття спільної лінії:
+  - Поточне покриття в shared lane:
     - `google`: `generate`, `edit`
     - `minimax`: `generate`
-    - `comfy`: окремий live-файл Comfy, не ця спільна перевірка
+    - `comfy`: окремий live-файл Comfy, не цей shared sweep
 - Необов’язкове звуження:
   - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"`
   - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.5+"`
 - Необов’язкова поведінка auth:
-  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб примусово використовувати auth зі сховища профілів і ігнорувати override-и лише з env
+  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати auth із profile store та ігнорувати env-only перевизначення
 
-## Live генерації відео
+## Video generation live
 
 - Тест: `extensions/video-generation-providers.live.test.ts`
 - Увімкнення: `OPENCLAW_LIVE_TEST=1 pnpm test:live -- extensions/video-generation-providers.live.test.ts`
 - Harness: `pnpm test:live:media video`
 - Обсяг:
-  - Перевіряє спільний шлях bundled video-generation provider
+  - Перевіряє спільний вбудований шлях provider-а для video generation
   - Завантажує provider env vars із вашого login shell (`~/.profile`) перед probe
   - Типово використовує live/env API keys раніше за збережені auth profiles, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні shell credentials
-  - Пропускає провайдерів без придатних auth/profile/model
-  - Запускає обидва заявлені runtime-режими, коли вони доступні:
-    - `generate` із вхідними даними лише prompt
-    - `imageToVideo`, коли провайдер оголошує `capabilities.imageToVideo.enabled` і вибраний провайдер/модель приймає локальні image input на основі буфера в межах спільної перевірки
-    - `videoToVideo`, коли провайдер оголошує `capabilities.videoToVideo.enabled` і вибраний провайдер/модель приймає локальні video input на основі буфера в межах спільної перевірки
-  - Поточні оголошені, але пропущені провайдери `imageToVideo` у спільній перевірці:
-    - `vydra`, тому що bundled `veo3` працює лише з текстом, а bundled `kling` вимагає віддалену image URL
+  - Пропускає провайдерів без придатного auth/profile/model
+  - Запускає обидва оголошені runtime-режими, коли вони доступні:
+    - `generate` із вводом лише prompt
+    - `imageToVideo`, коли провайдер оголошує `capabilities.imageToVideo.enabled`, а вибраний провайдер/модель приймає локальний image input із backing buffer у shared sweep
+    - `videoToVideo`, коли провайдер оголошує `capabilities.videoToVideo.enabled`, а вибраний провайдер/модель приймає локальний video input із backing buffer у shared sweep
+  - Поточні оголошені, але пропущені провайдери `imageToVideo` у shared sweep:
+    - `vydra`, тому що вбудований `veo3` є лише текстовим, а вбудований `kling` вимагає віддалений image URL
+  - Специфічне покриття Vydra:
+    - `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_VYDRA_VIDEO=1 pnpm test:live -- extensions/vydra/vydra.live.test.ts`
+    - цей файл запускає `veo3` text-to-video плюс lane `kling`, яка типово використовує fixture з віддаленим image URL
   - Поточне live-покриття `videoToVideo`:
-    - лише `runway`, коли вибраною моделлю є `runway/gen4_aleph`
-  - Поточні оголошені, але пропущені провайдери `videoToVideo` у спільній перевірці:
-    - `alibaba`, `qwen`, `xai`, тому що ці шляхи наразі вимагають віддалені reference URL `http(s)` / MP4
-    - `google`, тому що поточна спільна лінія Gemini/Veo використовує локальний вхід на основі буфера, і цей шлях не приймається в межах спільної перевірки
-    - `openai`, тому що поточна спільна лінія не гарантує org-specific доступ до video inpaint/remix
+    - лише `runway`, коли вибрана модель — `runway/gen4_aleph`
+  - Поточні оголошені, але пропущені провайдери `videoToVideo` у shared sweep:
+    - `alibaba`, `qwen`, `xai`, оскільки ці шляхи наразі вимагають віддалені reference URL `http(s)` / MP4
+    - `google`, оскільки поточна спільна lane Gemini/Veo використовує локальний input із backing buffer, а цей шлях не приймається в shared sweep
+    - `openai`, оскільки поточна shared lane не гарантує доступність org-specific video inpaint/remix
 - Необов’язкове звуження:
   - `OPENCLAW_LIVE_VIDEO_GENERATION_PROVIDERS="google,openai,runway"`
   - `OPENCLAW_LIVE_VIDEO_GENERATION_MODELS="google/veo-3.1-fast-generate-preview,openai/sora-2,runway/gen4_aleph"`
 - Необов’язкова поведінка auth:
-  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб примусово використовувати auth зі сховища профілів і ігнорувати override-и лише з env
+  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати auth із profile store та ігнорувати env-only перевизначення
 
 ## Media live harness
 
 - Команда: `pnpm test:live:media`
 - Призначення:
-  - Запускає спільні live-набори image, music і video через один нативний entrypoint репозиторію
+  - Запускає спільні live-набори image, music і video через один native entrypoint репозиторію
   - Автоматично завантажує відсутні provider env vars із `~/.profile`
-  - Типово автоматично звужує кожен набір до провайдерів, які наразі мають придатну auth
-  - Повторно використовує `scripts/test-live.mjs`, тож поведінка heartbeat і quiet-mode залишається узгодженою
+  - Типово автоматично звужує кожен набір до провайдерів, які зараз мають придатну auth
+  - Повторно використовує `scripts/test-live.mjs`, тож heartbeat і quiet-mode поводяться узгоджено
 - Приклади:
   - `pnpm test:live:media`
   - `pnpm test:live:media image video --providers openai,google,minimax`
@@ -550,182 +553,182 @@ Live-тести знаходять облікові дані так само, я
 
 ## Docker-ранери (необов’язкові перевірки «працює в Linux»)
 
-Ці Docker-ранери поділено на дві групи:
+Ці Docker-ранери поділяються на дві групи:
 
-- Live-model ранери: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл із profile keys усередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують вашу локальну директорію config і workspace (і підвантажують `~/.profile`, якщо його змонтовано). Відповідні локальні entrypoint-и: `test:live:models-profiles` і `test:live:gateway-profiles`.
-- Docker live ранери типово мають меншу межу smoke, щоб повний Docker sweep залишався практичним:
-  `test:docker:live-models` типово використовує `OPENCLAW_LIVE_MAX_MODELS=12`, а
-  `test:docker:live-gateway` типово використовує `OPENCLAW_LIVE_GATEWAY_SMOKE=1`,
+- Live-model runners: `test:docker:live-models` і `test:docker:live-gateway` запускають лише свій відповідний profile-key live-файл усередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують ваш локальний config dir і workspace (і виконують `source ~/.profile`, якщо його змонтовано). Відповідні локальні entrypoint-и: `test:live:models-profiles` і `test:live:gateway-profiles`.
+- Docker live runners типово мають менший ліміт smoke, щоб повний sweep у Docker залишався практичним:
+  `test:docker:live-models` типово встановлює `OPENCLAW_LIVE_MAX_MODELS=12`, а
+  `test:docker:live-gateway` типово встановлює `OPENCLAW_LIVE_GATEWAY_SMOKE=1`,
   `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`,
   `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000`, і
-  `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначте ці env vars, коли
-  свідомо хочете більший вичерпний прогін.
-- `test:docker:all` один раз збирає live Docker image через `test:docker:live-build`, а потім повторно використовує його для двох live Docker lanes.
-- Container smoke ранери: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` і `test:docker:plugins` запускають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня.
+  `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env vars, коли
+  навмисно хочете більший вичерпний прогін.
+- `test:docker:all` один раз збирає live Docker image через `test:docker:live-build`, а потім повторно використовує його для двох Docker-lane live.
+- Container smoke runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` і `test:docker:plugins` підіймають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня.
 
-Live-model Docker-ранери також bind-mount-ять лише потрібні CLI auth homes (або всі підтримувані, якщо запуск не звужений), а потім копіюють їх у home контейнера перед запуском, щоб OAuth зовнішніх CLI міг оновлювати токени без змін у host auth store:
+Live-model Docker-ранери також bind-mount-ять лише потрібні домівки CLI auth (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у home контейнера перед запуском, щоб OAuth зовнішніх CLI міг оновлювати токени без змін у host auth store:
 
-- Direct models: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`)
-- ACP bind smoke: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`)
-- CLI backend smoke: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`)
+- Прямі моделі: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`)
+- Smoke прив’язки ACP: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`)
+- Smoke CLI backend: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`)
 - Gateway + dev agent: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`)
 - Live smoke Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`)
-- Майстер onboarding (TTY, повне scaffold-налаштування): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`)
+- Майстер onboarding (TTY, повне scaffolding): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`)
 - Мережева взаємодія gateway (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`)
-- MCP channel bridge (seeded Gateway + stdio bridge + raw smoke notification-frame Claude): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`)
-- Plugins (smoke встановлення + псевдонім `/plugin` + семантика перезапуску Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`)
+- Міст каналів MCP (seeded Gateway + stdio bridge + raw Claude notification-frame smoke): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`)
+- Плагіни (install smoke + псевдонім `/plugin` + семантика перезапуску Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`)
 
-Live-model Docker-ранери також bind-mount-ять поточний checkout лише для читання і
-стейджать його в тимчасову workdir усередині контейнера. Це зберігає runtime
-image компактним, але все одно запускає Vitest точно по вашому локальному source/config.
-Крок staging пропускає великі локальні кеші та результати збірки застосунків, такі як
-`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` і локальні для застосунків каталоги `.build` або
-виводу Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання
-артефактів, специфічних для машини.
-Вони також встановлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб gateway live probes не запускали
-реальні воркери каналів Telegram/Discord/etc. усередині контейнера.
+Live-model Docker-ранери також монтують поточний checkout тільки для читання і
+переносять його в тимчасовий workdir усередині контейнера. Це дозволяє тримати runtime
+image компактним і водночас запускати Vitest точно на вашому локальному source/config.
+Крок staging пропускає великі локальні кеші та локальні артефакти збірки застосунків,
+такі як `.pnpm-store`, `.worktrees`, `__openclaw_vitest__` і локальні для застосунків
+каталоги `.build` або вихідні каталоги Gradle, щоб live-запуски Docker не витрачали
+хвилини на копіювання машинозалежних артефактів.
+Вони також встановлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб live-probes gateway не запускали
+реальні worker-и каналів Telegram/Discord тощо всередині контейнера.
 `test:docker:live-models` усе ще запускає `pnpm test:live`, тому також передавайте
-`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити gateway
-live-покриття з цієї Docker lane.
-`test:docker:openwebui` — це compatibility smoke вищого рівня: він запускає
+`OPENCLAW_LIVE_GATEWAY_*`, коли вам потрібно звузити або виключити gateway
+live-покриття з цієї Docker-lane.
+`test:docker:openwebui` — це smoke сумісності вищого рівня: він запускає
 контейнер gateway OpenClaw з увімкненими HTTP endpoint-ами, сумісними з OpenAI,
-запускає pinned контейнер Open WebUI проти цього gateway, входить через
+запускає pinned контейнер Open WebUI проти цього gateway, виконує вхід через
 Open WebUI, перевіряє, що `/api/models` показує `openclaw/default`, а потім надсилає
-реальний chat-запит через проксі Open WebUI `/api/chat/completions`.
-Перший запуск може бути помітно повільнішим, тому що Docker може знадобитися витягнути
-image Open WebUI, а самому Open WebUI — завершити власне cold-start налаштування.
-Ця лінія очікує придатний live key моделі, а `OPENCLAW_PROFILE_FILE`
-(типово `~/.profile`) є основним способом передати його в Dockerized-запусках.
+реальний chat-запит через проксі `/api/chat/completions` Open WebUI.
+Перший запуск може бути помітно повільнішим, оскільки Docker може потребувати завантаження
+image Open WebUI, а самому Open WebUI може знадобитися завершити власне cold-start налаштування.
+Ця lane очікує придатний live model key, а `OPENCLAW_PROFILE_FILE`
+(типово `~/.profile`) є основним способом надати його в Docker-ізольованих запусках.
 Успішні запуски виводять невеликий JSON payload на кшталт `{ "ok": true, "model":
 "openclaw/default", ... }`.
 `test:docker:mcp-channels` навмисно детермінований і не потребує
-реального облікового запису Telegram, Discord або iMessage. Він піднімає seeded Gateway
-контейнер, запускає другий контейнер, який викликає `openclaw mcp serve`, а потім
-перевіряє виявлення маршрутизованих conversation, читання transcript-ів, метадані attachment,
-поведінку черги live events, маршрутизацію outbound send, а також сповіщення у стилі Claude про channel +
-permissions через реальний stdio MCP bridge. Перевірка notification
-безпосередньо аналізує raw stdio MCP frames, тож smoke перевіряє, що
-міст реально емінує, а не лише те, що випадково показує конкретний client SDK.
+реального облікового запису Telegram, Discord або iMessage. Він підіймає seeded контейнер Gateway,
+запускає другий контейнер, який піднімає `openclaw mcp serve`, а потім
+перевіряє виявлення conversation з маршрутизацією, читання transcript,
+метадані attachment, поведінку черги live-подій, маршрутизацію outbound send, а також
+сповіщення в стилі Claude про channel + permission через реальний stdio MCP bridge. Перевірка
+сповіщень інспектує raw stdio MCP frames безпосередньо, щоб smoke перевіряв те, що
+міст насправді випромінює, а не лише те, що виводить якийсь конкретний client SDK.
 
-Ручний smoke ACP plain-language thread (не CI):
+Ручний smoke plain-language thread ACP (не CI):
 
 - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel <discord-channel-id> ...`
-- Зберігайте цей скрипт для сценаріїв регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації ACP thread, тому не видаляйте його.
+- Зберігайте цей скрипт для сценаріїв регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації thread ACP, тому не видаляйте його.
 
 Корисні env vars:
 
-- `OPENCLAW_CONFIG_DIR=...` (типово: `~/.openclaw`), монтується в `/home/node/.openclaw`
-- `OPENCLAW_WORKSPACE_DIR=...` (типово: `~/.openclaw/workspace`), монтується в `/home/node/.openclaw/workspace`
-- `OPENCLAW_PROFILE_FILE=...` (типово: `~/.profile`), монтується в `/home/node/.profile` і підвантажується перед запуском тестів
-- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (типово: `~/.cache/openclaw/docker-cli-tools`), монтується в `/home/node/.npm-global` для кешованих встановлень CLI всередині Docker
-- Директорії/файли auth зовнішніх CLI під `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються в `/home/node/...` перед стартом тестів
-  - Типові директорії: `.minimax`
+- `OPENCLAW_CONFIG_DIR=...` (типово: `~/.openclaw`) монтується в `/home/node/.openclaw`
+- `OPENCLAW_WORKSPACE_DIR=...` (типово: `~/.openclaw/workspace`) монтується в `/home/node/.openclaw/workspace`
+- `OPENCLAW_PROFILE_FILE=...` (типово: `~/.profile`) монтується в `/home/node/.profile` і підключається через `source` перед запуском тестів
+- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (типово: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих встановлень CLI усередині Docker
+- Зовнішні CLI auth dirs/files під `$HOME` монтуються тільки для читання під `/host-auth...`, а потім копіюються в `/home/node/...` перед початком тестів
+  - Типові каталоги: `.minimax`
   - Типові файли: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json`
-  - Звужені запуски провайдерів монтують лише потрібні директорії/файли, визначені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS`
-  - Ручне override: `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або список через кому, наприклад `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex`
+  - Для звужених запусків провайдерів монтуються лише потрібні dirs/files, виведені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS`
+  - Ручне перевизначення: `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none`, або список через кому на кшталт `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex`
 - `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...` щоб звузити запуск
-- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` щоб відфільтрувати провайдерів у контейнері
-- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб гарантувати, що облікові дані беруться зі сховища профілів (а не з env)
-- `OPENCLAW_OPENWEBUI_MODEL=...` щоб вибрати модель, яку gateway показує для smoke Open WebUI
-- `OPENCLAW_OPENWEBUI_PROMPT=...` щоб override-нути prompt із перевіркою nonce, який використовується в smoke Open WebUI
-- `OPENWEBUI_IMAGE=...` щоб override-нути pinned tag image Open WebUI
+- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` щоб відфільтрувати провайдерів усередині контейнера
+- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб гарантувати надходження облікових даних із profile store (а не env)
+- `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку gateway показуватиме для smoke Open WebUI
+- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити prompt із перевіркою nonce, який використовує smoke Open WebUI
+- `OPENWEBUI_IMAGE=...`, щоб перевизначити pinned tag image Open WebUI
 
 ## Перевірка документації
 
-Після редагування документації запускайте перевірки docs: `pnpm check:docs`.
-Запускайте повну перевірку anchor у Mintlify, коли вам також потрібна перевірка заголовків у межах сторінки: `pnpm docs:check-links:anchors`.
+Запускайте перевірки docs після змін у документації: `pnpm check:docs`.
+Запускайте повну перевірку anchors у Mintlify, коли також потрібна перевірка заголовків у межах сторінки: `pnpm docs:check-links:anchors`.
 
 ## Офлайн-регресія (безпечна для CI)
 
 Це регресії «реального pipeline» без реальних провайдерів:
 
-- Tool calling gateway (mock OpenAI, реальний цикл gateway + agent): `src/gateway/gateway.test.ts` (випадок: "runs a mock OpenAI tool call end-to-end via gateway agent loop")
-- Майстер gateway (WS `wizard.start`/`wizard.next`, запис config + примусовий auth): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config")
+- Gateway tool calling (mock OpenAI, реальний gateway + agent loop): `src/gateway/gateway.test.ts` (випадок: "runs a mock OpenAI tool call end-to-end via gateway agent loop")
+- Майстер gateway (WS `wizard.start`/`wizard.next`, записує config + примусова auth): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config")
 
-## Оцінювання надійності агента (Skills)
+## Evals надійності агента (Skills)
 
-У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності агента»:
+У нас уже є кілька безпечних для CI тестів, які поводяться як «evals надійності агента»:
 
-- Mock tool-calling через реальний цикл gateway + agent (`src/gateway/gateway.test.ts`).
-- Наскрізні потоки wizard, які перевіряють wiring session та ефекти config (`src/gateway/gateway.test.ts`).
+- Mock tool-calling через реальний gateway + agent loop (`src/gateway/gateway.test.ts`).
+- Наскрізні потоки wizard, які перевіряють wiring сесій і ефекти конфігурації (`src/gateway/gateway.test.ts`).
 
-Чого ще бракує для Skills (див. [Skills](/uk/tools/skills)):
+Що ще відсутнє для skills (див. [Skills](/uk/tools/skills)):
 
-- **Прийняття рішень:** коли Skills перелічено в prompt, чи вибирає агент правильний skill (або уникає нерелевантних)?
-- **Відповідність вимогам:** чи читає агент `SKILL.md` перед використанням і чи дотримується потрібних кроків/args?
-- **Контракти workflow:** багатокрокові сценарії, що перевіряють порядок tools, перенесення history session і межі sandbox.
+- **Прийняття рішень:** коли skills перелічено в prompt, чи вибирає агент правильний skill (або уникає нерелевантних)?
+- **Відповідність:** чи читає агент `SKILL.md` перед використанням і чи дотримується обов’язкових кроків/args?
+- **Контракти workflow:** багатокрокові сценарії, які перевіряють порядок tools, перенесення історії сесій і межі sandbox.
 
-Майбутні eval-и мають спочатку залишатися детермінованими:
+Майбутні evals мають спочатку залишатися детермінованими:
 
-- Scenario runner з mock-провайдерами для перевірки tool calls + порядку, читання skill-файлів і wiring session.
-- Невеликий набір сценаріїв, орієнтованих на skills (використати чи уникнути, gate-інг, ін’єкція в prompt).
-- Необов’язкові live eval-и (opt-in, керовані через env) лише після того, як безпечний для CI набір буде готовий.
+- Scenario runner з mock-провайдерами для перевірки викликів tools + їх порядку, читання skill-файлів і wiring сесій.
+- Невеликий набір сценаріїв, сфокусованих на skills (використовувати vs уникати, gating, prompt injection).
+- Необов’язкові live evals (opt-in, керовані env) лише після появи безпечного для CI набору.
 
-## Contract-тести (форма plugin і channel)
+## Contract tests (форма плагінів і каналів)
 
-Contract-тести перевіряють, що кожен зареєстрований plugin і channel відповідає
-своєму interface contract. Вони перебирають усі знайдені plugins і запускають набір
-перевірок форми та поведінки. Типова unit-лінія `pnpm test` навмисно
+Contract tests перевіряють, що кожен зареєстрований плагін і канал відповідає
+своєму interface contract. Вони проходять по всіх виявлених плагінах і запускають набір
+перевірок форми та поведінки. Типова unit lane `pnpm test` навмисно
 пропускає ці shared seam і smoke-файли; запускайте contract-команди явно,
 коли торкаєтесь спільних поверхонь channel або provider.
 
 ### Команди
 
-- Усі контракти: `pnpm test:contracts`
+- Усі contracts: `pnpm test:contracts`
 - Лише channel contracts: `pnpm test:contracts:channels`
 - Лише provider contracts: `pnpm test:contracts:plugins`
 
-### Контракти channel
+### Channel contracts
 
-Розташовані в `src/channels/plugins/contracts/*.contract.test.ts`:
+Розміщені в `src/channels/plugins/contracts/*.contract.test.ts`:
 
-- **plugin** - Базова форма plugin (id, name, capabilities)
+- **plugin** - Базова форма плагіна (id, name, capabilities)
 - **setup** - Контракт майстра налаштування
-- **session-binding** - Поведінка прив’язування session
+- **session-binding** - Поведінка прив’язки сесії
 - **outbound-payload** - Структура payload повідомлення
 - **inbound** - Обробка вхідних повідомлень
-- **actions** - Обробники дій channel
-- **threading** - Обробка ID thread
-- **directory** - API directory/roster
-- **group-policy** - Застосування group policy
+- **actions** - Обробники дій каналу
+- **threading** - Обробка ID тредів
+- **directory** - API каталогу/списку учасників
+- **group-policy** - Забезпечення групової політики
 
-### Контракти status провайдера
+### Contracts статусу провайдера
 
-Розташовані в `src/plugins/contracts/*.contract.test.ts`.
+Розміщені в `src/plugins/contracts/*.contract.test.ts`.
 
-- **status** - Перевірки status channel
-- **registry** - Форма registry plugin
+- **status** - Проби статусу каналу
+- **registry** - Форма registry плагінів
 
-### Контракти провайдера
+### Provider contracts
 
-Розташовані в `src/plugins/contracts/*.contract.test.ts`:
+Розміщені в `src/plugins/contracts/*.contract.test.ts`:
 
 - **auth** - Контракт потоку auth
 - **auth-choice** - Вибір/selection auth
 - **catalog** - API каталогу моделей
-- **discovery** - Виявлення plugin
-- **loader** - Завантаження plugin
+- **discovery** - Виявлення плагінів
+- **loader** - Завантаження плагінів
 - **runtime** - Runtime провайдера
-- **shape** - Форма/interface plugin
+- **shape** - Форма/інтерфейс плагіна
 - **wizard** - Майстер налаштування
 
 ### Коли запускати
 
-- Після зміни export-ів або subpath-ів `plugin-sdk`
+- Після змін у `plugin-sdk` exports або subpaths
 - Після додавання або зміни channel чи provider plugin
-- Після рефакторингу реєстрації plugin або discovery
+- Після рефакторингу реєстрації або виявлення плагінів
 
-Contract-тести запускаються в CI і не потребують реальних API-ключів.
+Contract tests запускаються в CI і не потребують реальних API-ключів.
 
-## Додавання регресій (поради)
+## Додавання регресій (рекомендації)
 
-Коли ви виправляєте проблему провайдера/моделі, виявлену в live:
+Коли ви виправляєте проблему провайдера/моделі, виявлену у live:
 
-- Додайте безпечну для CI регресію, якщо це можливо (mock/stub провайдера або фіксація точного перетворення форми запиту)
-- Якщо проблема за своєю природою можлива лише в live (rate limits, політики auth), залишайте live-тест вузьким і opt-in через env vars
-- Намагайтеся націлюватися на найменший шар, який спіймає баг:
-  - баг перетворення/повторного програвання запиту провайдера → direct models test
-  - баг pipeline gateway session/history/tool → gateway live smoke або безпечний для CI mock-тест gateway
-- Захисне обмеження обходу SecretRef:
-  - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль на клас SecretRef з метаданих registry (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id сегментів traversal відхиляються.
-  - Якщо ви додаєте нове сімейство цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target id, щоб нові класи не могли бути тихо пропущені.
+- Додайте безпечну для CI регресію, якщо це можливо (mock/stub провайдера або захоплення точного перетворення форми запиту)
+- Якщо проблема за своєю природою лише live (rate limits, політики auth), залишайте live-тест вузьким і opt-in через env vars
+- Краще націлюватися на найменший шар, який ловить помилку:
+  - помилка конвертації/повторного програвання запиту провайдера → direct models test
+  - помилка gateway session/history/tool pipeline → gateway live smoke або безпечний для CI gateway mock test
+- Захисне правило обходу SecretRef:
+  - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить один sampled target для кожного класу SecretRef з метаданих registry (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec ids сегментів обходу відхиляються.
+  - Якщо ви додаєте нову родину цілей SecretRef з `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target id, щоб нові класи не можна було тихо пропустити.
diff --git a/docs/uk/providers/vydra.md b/docs/uk/providers/vydra.md
index c1a7f9ac3..f23cbd640 100644
--- a/docs/uk/providers/vydra.md
+++ b/docs/uk/providers/vydra.md
@@ -1,14 +1,14 @@
 ---
 read_when:
     - Ви хочете генерацію медіа Vydra в OpenClaw
-    - Вам потрібні вказівки з налаштування API-ключа Vydra
+    - Вам потрібні вказівки з налаштування ключа API Vydra
 summary: Використовуйте зображення, відео та мовлення Vydra в OpenClaw
 title: Vydra
 x-i18n:
-    generated_at: "2026-04-06T01:23:32Z"
+    generated_at: "2026-04-06T18:49:50Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 0fe999e8a5414b8a31a6d7d127bc6bcfc3b4492b8f438ab17dfa9680c5b079b7
+    source_hash: 24006a687ed6f9792e7b2b10927cc7ad71c735462a92ce03d5fa7c2b2ee2fcc2
     source_path: providers/vydra.md
     workflow: 15
 ---
@@ -21,13 +21,13 @@ x-i18n:
 - генерацію відео через `vydra/veo3` і `vydra/kling`
 - синтез мовлення через маршрут TTS Vydra на базі ElevenLabs
 
-OpenClaw використовує той самий `VYDRA_API_KEY` для всіх трьох можливостей.
+OpenClaw використовує один і той самий `VYDRA_API_KEY` для всіх трьох можливостей.
 
 ## Важлива базова URL-адреса
 
 Використовуйте `https://www.vydra.ai/api/v1`.
 
-Апекс-хост Vydra (`https://vydra.ai/api/v1`) наразі перенаправляє на `www`. Деякі HTTP-клієнти скидають `Authorization` під час такого перенаправлення між хостами, через що дійсний API-ключ перетворюється на оманливу помилку автентифікації. Щоб уникнути цього, вбудований плагін безпосередньо використовує базову URL-адресу `www`.
+Аpex-хост Vydra (`https://vydra.ai/api/v1`) наразі перенаправляє на `www`. Деякі HTTP-клієнти скидають `Authorization` під час такого перенаправлення між хостами, через що дійсний ключ API перетворюється на оманливу помилку автентифікації. Вбудований плагін використовує базову URL-адресу `www` напряму, щоб уникнути цього.
 
 ## Налаштування
 
@@ -45,11 +45,11 @@ export VYDRA_API_KEY="vydra_live_..."
 
 ## Генерація зображень
 
-Модель зображень за замовчуванням:
+Типова модель зображень:
 
 - `vydra/grok-imagine`
 
-Зробіть її стандартним провайдером зображень:
+Зробіть її типовим постачальником зображень:
 
 ```json5
 {
@@ -63,18 +63,18 @@ export VYDRA_API_KEY="vydra_live_..."
 }
 ```
 
-Поточна вбудована підтримка охоплює лише генерацію з тексту в зображення. Розміщені у Vydra маршрути редагування очікують віддалені URL-адреси зображень, а OpenClaw поки що не додає у вбудованому плагіні міст завантаження, специфічний для Vydra.
+Поточна вбудована підтримка охоплює лише генерацію зображень із тексту. Хостовані маршрути редагування Vydra очікують віддалені URL-адреси зображень, а OpenClaw поки що не додає у вбудований плагін місток завантаження, специфічний для Vydra.
 
-Див. [Генерація зображень](/uk/tools/image-generation), щоб дізнатися про спільну поведінку інструмента.
+Див. [Генерація зображень](/uk/tools/image-generation) для спільної поведінки інструмента.
 
 ## Генерація відео
 
-Зареєстровані відеомоделі:
+Зареєстровані моделі відео:
 
 - `vydra/veo3` для генерації відео з тексту
 - `vydra/kling` для генерації відео із зображення
 
-Зробіть Vydra стандартним провайдером відео:
+Зробіть Vydra типовим постачальником відео:
 
 ```json5
 {
@@ -90,11 +90,31 @@ export VYDRA_API_KEY="vydra_live_..."
 
 Примітки:
 
-- `vydra/veo3` у вбудованому варіанті підтримує лише генерацію відео з тексту.
+- `vydra/veo3` у вбудованому вигляді підтримує лише генерацію відео з тексту.
 - `vydra/kling` наразі вимагає посилання на віддалену URL-адресу зображення. Завантаження локальних файлів одразу відхиляються.
-- Вбудований плагін дотримується консервативного підходу й не передає недокументовані параметри стилю, як-от співвідношення сторін, роздільна здатність, водяний знак або згенероване аудіо.
+- Поточний HTTP-маршрут `kling` у Vydra працює непослідовно щодо того, чи вимагає він `image_url` або `video_url`; вбудований провайдер підставляє ту саму віддалену URL-адресу зображення в обидва поля.
+- Вбудований плагін дотримується консервативного підходу й не передає недокументовані параметри стилю, як-от співвідношення сторін, роздільна здатність, водяний знак або згенерований звук.
 
-Див. [Генерація відео](/uk/tools/video-generation), щоб дізнатися про спільну поведінку інструмента.
+Специфічне для провайдера live-покриття:
+
+```bash
+OPENCLAW_LIVE_TEST=1 \
+OPENCLAW_LIVE_VYDRA_VIDEO=1 \
+pnpm test:live -- extensions/vydra/vydra.live.test.ts
+```
+
+Тепер вбудований live-файл Vydra охоплює:
+
+- `vydra/veo3` для генерації відео з тексту
+- `vydra/kling` для генерації відео із зображення з використанням віддаленої URL-адреси зображення
+
+За потреби перевизначте фікстуру віддаленого зображення:
+
+```bash
+export OPENCLAW_LIVE_VYDRA_KLING_IMAGE_URL="https://example.com/reference.png"
+```
+
+Див. [Генерація відео](/uk/tools/video-generation) для спільної поведінки інструмента.
 
 ## Синтез мовлення
 
@@ -118,10 +138,10 @@ export VYDRA_API_KEY="vydra_live_..."
 
 Типові значення:
 
-- модель: `elevenlabs/tts`
-- ID голосу: `21m00Tcm4TlvDq8ikWAM`
+- model: `elevenlabs/tts`
+- voice id: `21m00Tcm4TlvDq8ikWAM`
 
-Наразі вбудований плагін надає один перевірений стандартний голос і повертає аудіофайли MP3.
+Вбудований плагін наразі надає один перевірений типовий голос і повертає аудіофайли MP3.
 
 ## Пов’язане