diff --git a/docs/uk/concepts/qa-e2e-automation.md b/docs/uk/concepts/qa-e2e-automation.md
index cfefcf3a3..f8f3817f6 100644
--- a/docs/uk/concepts/qa-e2e-automation.md
+++ b/docs/uk/concepts/qa-e2e-automation.md
@@ -1,51 +1,50 @@
 ---
 read_when:
     - Розширення qa-lab або qa-channel
-    - Додавання QA-сценаріїв на основі репозиторію
-    - Побудова реалістичнішої QA-автоматизації навколо панелі керування Gateway
-summary: Форма приватної QA-автоматизації для qa-lab, qa-channel, початково заповнених сценаріїв і звітів протоколу
-title: QA E2E-автоматизація
+    - Додавання сценаріїв QA, що підтримуються репозиторієм
+    - Побудова більш реалістичної автоматизації QA навколо панелі керування Gateway
+summary: Приватна структура автоматизації QA для qa-lab, qa-channel, підготовлених сценаріїв і звітів протоколу
+title: Автоматизація QA E2E
 x-i18n:
-    generated_at: "2026-04-09T22:54:33Z"
+    generated_at: "2026-04-10T12:52:46Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 357d6698304ff7a8c4aa8a7be97f684d50f72b524740050aa761ac0ee68266de
+    source_hash: e416ffd285a05339a88eb749e37c4ed9448f232ca67dc0c85eba772029b5b306
     source_path: concepts/qa-e2e-automation.md
     workflow: 15
 ---
 
-# QA E2E-автоматизація
+# Автоматизація QA E2E
 
-Приватний QA-стек призначений для тестування OpenClaw у реалістичніший,
-схожий на канал спосіб, ніж це може зробити один модульний тест.
+Приватний стек QA призначений для перевірки OpenClaw у більш реалістичний,
+орієнтований на канали спосіб, ніж це може зробити один модульний тест.
 
 Поточні складові:
 
-- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями для DM, каналу, гілки,
+- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, треду,
   реакцій, редагування та видалення.
-- `extensions/qa-lab`: UI налагодження та QA-шина для спостереження за транскриптом,
-  інʼєкції вхідних повідомлень і експорту Markdown-звіту.
-- `qa/`: ресурси початкового заповнення на основі репозиторію для стартового завдання та базових QA-
-  сценаріїв.
+- `extensions/qa-lab`: UI налагодження та шина QA для спостереження за транскриптом,
+  інʼєкції вхідних повідомлень і експорту звіту у форматі Markdown.
+- `qa/`: ресурси початкових даних, що підтримуються репозиторієм, для стартового завдання та базових сценаріїв QA.
 
-Поточний робочий процес QA-оператора — це двопанельний QA-сайт:
+Поточний потік роботи оператора QA — це сайт QA із двома панелями:
 
 - Ліворуч: панель керування Gateway (Control UI) з агентом.
 - Праворуч: QA Lab, що показує транскрипт у стилі Slack і план сценарію.
 
-Запустіть його командою:
+Запустіть його так:
 
 ```bash
 pnpm qa:lab:up
 ```
 
-Це збирає QA-сайт, запускає lane Gateway на основі Docker і відкриває
-сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA-
-завдання, спостерігати реальну поведінку каналу та фіксувати, що спрацювало, що
-не спрацювало або що залишилося заблокованим.
+Це збирає сайт QA, запускає lane Gateway на основі Docker і відкриває
+сторінку QA Lab, де оператор або цикл автоматизації може дати агенту
+QA-місію, спостерігати реальну поведінку каналу й записувати, що спрацювало,
+що не спрацювало або що залишилося заблокованим.
 
-Для швидшої ітерації UI QA Lab без повторного збирання Docker-образу щоразу
-запустіть стек із bind-mount пакета QA Lab:
+Для швидшої ітерації UI QA Lab без повторного збирання образу Docker щоразу,
+запустіть стек із bind-mounted збіркою QA Lab:
 
 ```bash
 pnpm openclaw qa docker-build-image
@@ -54,29 +53,31 @@ pnpm qa:lab:up:fast
 pnpm qa:lab:watch
 ```
 
-`qa:lab:up:fast` залишає сервіси Docker на попередньо зібраному образі та монтує
-`extensions/qa-lab/web/dist` у контейнер `qa-lab` через bind-mount. `qa:lab:watch`
-перебудовує цей пакет при змінах, а браузер автоматично перезавантажується, коли
-змінюється хеш ресурсів QA Lab.
+`qa:lab:up:fast` утримує сервіси Docker на попередньо зібраному образі та bind-mount
+`extensions/qa-lab/web/dist` у контейнер `qa-lab`. `qa:lab:watch`
+перезбирає цей пакет при змінах, а браузер автоматично перезавантажується, коли змінюється хеш ресурсів QA Lab.
 
-Для одноразової lane Linux VM без додавання Docker до QA-шляху виконайте:
+Для тимчасового lane на Linux VM без залучення Docker до шляху QA виконайте:
 
 ```bash
 pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
 ```
 
-Це завантажує нову гостьову систему Multipass, встановлює залежності, збирає OpenClaw
-усередині гостьової системи, запускає `qa suite`, а потім копіює звичайний QA-звіт і
+Це завантажує свіжий гість Multipass, встановлює залежності, збирає OpenClaw
+усередині гостя, запускає `qa suite`, а потім копіює звичайний звіт QA і
 підсумок назад у `.artifacts/qa-e2e/...` на хості.
-Використовується така сама поведінка вибору сценаріїв, як і для `qa suite` на хості.
-Під час live-запусків пересилаються підтримувані вхідні дані автентифікації QA, які є практичними для
-гостьової системи: ключі провайдера на основі env, шлях до конфігурації QA live provider і
-`CODEX_HOME`, якщо він присутній. Зберігайте `--output-dir` у межах кореня репозиторію, щоб гостьова система
-могла записувати назад через змонтований workspace.
+Використовується та сама поведінка вибору сценаріїв, що й у `qa suite` на хості.
+Запуски suite на хості та в Multipass за замовчуванням виконують кілька вибраних сценаріїв паралельно
+з ізольованими працівниками gateway, до 64 працівників або до кількості вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати кількість працівників, або
+`--concurrency 1` для послідовного виконання.
+Live-запуски пересилають підтримувані вхідні дані автентифікації QA, які практичні для
+гостя: ключі провайдера на основі env, шлях до конфігурації live-провайдера QA і
+`CODEX_HOME`, якщо він присутній. Тримайте `--output-dir` у межах кореня репозиторію, щоб гість
+міг записувати результати назад через змонтований робочий простір.
 
-## Початково заповнені ресурси на основі репозиторію
+## Початкові дані, що підтримуються репозиторієм
 
-Ресурси початкового заповнення містяться в `qa/`:
+Ресурси початкових даних розташовані в `qa/`:
 
 - `qa/scenarios/index.md`
 - `qa/scenarios/*.md`
@@ -84,28 +85,28 @@ pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
 Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
 агенту. Базовий список має залишатися достатньо широким, щоб охоплювати:
 
-- чат у DM і каналі
-- поведінку в гілках
+- DM і чат у каналі
+- поведінку тредів
 - життєвий цикл дій із повідомленнями
 - cron-зворотні виклики
-- згадування памʼяті
+- відтворення памʼяті
 - перемикання моделей
-- передавання до субагента
-- читання репозиторію та читання документації
+- передачу субагенту
+- читання репозиторію та документації
 - одне невелике завдання зі збирання, наприклад Lobster Invaders
 
-## Звітування
+## Звітність
 
-`qa-lab` експортує Markdown-звіт протоколу на основі спостережуваної часової шкали шини.
-Звіт має відповідати на такі запитання:
+`qa-lab` експортує звіт протоколу у форматі Markdown зі спостережуваної часової шкали шини.
+Звіт має відповідати на запитання:
 
 - Що спрацювало
 - Що не спрацювало
 - Що залишилося заблокованим
-- Які сценарії для подальшої роботи варто додати
+- Які сценарії продовження варто додати
 
-Для перевірок характеру та стилю запустіть той самий сценарій для кількох live model
-ref і запишіть Markdown-звіт з оцінюванням:
+Для перевірок характеру та стилю запустіть той самий сценарій для кількох live-моделей
+і запишіть оцінений звіт у форматі Markdown:
 
 ```bash
 pnpm openclaw qa character-eval \
@@ -124,35 +125,34 @@ pnpm openclaw qa character-eval \
   --judge-concurrency 16
 ```
 
-Команда запускає дочірні процеси локального QA gateway, а не Docker. Сценарії character eval
-мають задавати персонажа через `SOUL.md`, а потім виконувати звичайні користувацькі ходи,
-такі як чат, допомога з workspace і невеликі файлові завдання. Моделі-кандидату
-не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
-транскрипт, записує базову статистику запуску, а потім просить моделі-оцінювачі в режимі fast з
+Ця команда запускає локальні дочірні процеси gateway QA, а не Docker. Сценарії оцінювання характеру
+мають задавати персону через `SOUL.md`, а потім виконувати звичайні ходи користувача,
+такі як чат, допомога з робочим простором і невеликі файлові завдання. Моделі-кандидату
+не слід повідомляти, що її оцінюють. Команда зберігає кожен повний транскрипт,
+записує базову статистику запуску, а потім просить моделі-судді у fast mode з
 міркуванням `xhigh` ранжувати запуски за природністю, вайбом і гумором.
-Використовуйте `--blind-judge-models` під час порівняння провайдерів: запит оцінювача все одно отримує
-кожен транскрипт і статус запуску, але ref кандидатів замінюються нейтральними
-мітками на кшталт `candidate-01`; після розбору звіт зіставляє ранжування назад із реальними ref.
-Для запусків кандидатів за замовчуванням використовується рівень thinking `high`, а для моделей OpenAI,
-які це підтримують, — `xhigh`. Перевизначте конкретного кандидата inline за допомогою
-`--model provider/model,thinking=<level>`. `--thinking <level>` як і раніше задає
-глобальний резервний варіант, а стара форма `--model-thinking <provider/model=level>` збережена
-для сумісності.
-Для ref кандидатів OpenAI за замовчуванням використовується режим fast, щоб там, де провайдер це підтримує,
-застосовувалася пріоритетна обробка. Додайте `,fast`, `,no-fast` або `,fast=false` inline, якщо
-для одного кандидата або оцінювача потрібно перевизначення. Передавайте `--fast` лише тоді, коли хочете
-примусово ввімкнути режим fast для кожної моделі-кандидата. Тривалість роботи кандидатів і оцінювачів
-записується у звіт для аналізу бенчмарків, але в запитах до оцінювачів прямо зазначено,
-що не слід ранжувати за швидкістю.
-І для запусків моделей-кандидатів, і для запусків моделей-оцінювачів за замовчуванням використовується паралелізм 16. Зменште
-`--concurrency` або `--judge-concurrency`, якщо обмеження провайдера чи навантаження на локальний gateway
+Використовуйте `--blind-judge-models` при порівнянні провайдерів: підказка для судді все одно отримує
+кожен транскрипт і статус запуску, але посилання кандидатів замінюються на нейтральні
+мітки, такі як `candidate-01`; після розбору звіт зіставляє ранжування з реальними посиланнями.
+Запуски кандидатів за замовчуванням використовують `high` thinking, а для моделей OpenAI — `xhigh`,
+якщо вони це підтримують. Перевизначте конкретного кандидата inline через
+`--model provider/model,thinking=<level>`. `--thinking <level>` усе ще задає
+глобальний резервний варіант, а старіша форма `--model-thinking <provider/model=level>` зберігається для сумісності.
+Посилання кандидатів OpenAI за замовчуванням використовують fast mode, щоб за можливості провайдера
+застосовувалася обробка з пріоритетом. Додайте inline `,fast`, `,no-fast` або `,fast=false`, якщо
+окремому кандидату чи судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
+примусово ввімкнути fast mode для кожної моделі-кандидата. Тривалість запусків кандидатів і суддів
+записується у звіті для аналізу бенчмарків, але підказки для суддів явно вказують
+не ранжувати за швидкістю.
+І запуски моделей-кандидатів, і запуски моделей-суддів за замовчуванням мають concurrency 16. Зменшуйте
+`--concurrency` або `--judge-concurrency`, якщо обмеження провайдера або навантаження на локальний gateway
 роблять запуск надто шумним.
-Якщо не передано жодного кандидата `--model`, для character eval за замовчуванням використовуються
+Якщо не передано жодного кандидатського `--model`, оцінювання характеру за замовчуванням використовує
 `openai/gpt-5.4`, `openai/gpt-5.2`, `openai/gpt-5`, `anthropic/claude-opus-4-6`,
 `anthropic/claude-sonnet-4-6`, `zai/glm-5.1`,
 `moonshot/kimi-k2.5` і
 `google/gemini-3.1-pro-preview`, якщо не передано `--model`.
-Якщо не передано `--judge-model`, то оцінювачами за замовчуванням є
+Якщо не передано жодного `--judge-model`, суддями за замовчуванням є
 `openai/gpt-5.4,thinking=xhigh,fast` і
 `anthropic/claude-opus-4-6,thinking=high`.
 
diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md
index 96a1ebbdb..6b0225981 100644
--- a/docs/uk/help/testing.md
+++ b/docs/uk/help/testing.md
@@ -2,21 +2,21 @@
 read_when:
     - Запуск тестів локально або в CI
     - Додавання регресійних тестів для помилок моделей/провайдерів
-    - Налагодження поведінки шлюзу й агента
-summary: 'Набір для тестування: набори unit/e2e/live, виконавці Docker і що охоплює кожен тест'
+    - Налагодження поведінки gateway та агента
+summary: 'Набір для тестування: модульні/e2e/live набори, ранери Docker і що охоплює кожен тест'
 title: Тестування
 x-i18n:
-    generated_at: "2026-04-10T09:54:19Z"
+    generated_at: "2026-04-10T12:52:31Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 8ab72e60eb2eea352a117b914a4da24f4dac6233d7fcfd394b7e19c3ccefd97b
+    source_hash: 40f29e8db015921a0b6a928517b28440d49b5fb63701e68cb66a1297063012ab
     source_path: help/testing.md
     workflow: 15
 ---
 
 # Тестування
 
-OpenClaw має три набори Vitest (unit/integration, e2e, live) і невеликий набір виконавців Docker.
+OpenClaw має три набори Vitest (unit/integration, e2e, live) і невеликий набір раннерів Docker.
 
 Цей документ — посібник «як ми тестуємо»:
 
@@ -30,133 +30,133 @@ 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`
-- QA-lane на основі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline`
+- Під час ітерацій над однією помилкою спочатку віддавайте перевагу цільовим запускам.
+- QA-сайт на базі Docker: `pnpm qa:lab:up`
+- QA-ланка на базі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline`
 
-Коли ви змінюєте тести або хочете більше впевненості:
+Коли ви змінюєте тести або хочете більшої впевненості:
 
-- Coverage gate: `pnpm test:coverage`
+- Gate покриття: `pnpm test:coverage`
 - Набір E2E: `pnpm test:e2e`
 
 Під час налагодження реальних провайдерів/моделей (потрібні реальні облікові дані):
 
-- Набір live (моделі + перевірки інструментів/зображень шлюзу): `pnpm test:live`
+- Live-набір (моделі + gateway tool/image probes): `pnpm test:live`
 - Тихо націлитися на один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts`
 
-Порада: якщо вам потрібен лише один збійний випадок, звужуйте live-тести через змінні середовища allowlist, описані нижче.
+Порада: коли вам потрібен лише один збійний випадок, звужуйте live-тести за допомогою змінних середовища allowlist, описаних нижче.
 
-## Виконавці, специфічні для QA
+## Спеціальні QA-раннери
 
-Ці команди використовуються поряд з основними наборами тестів, коли вам потрібна реалістичність QA-lab:
+Ці команди використовуються поряд з основними наборами тестів, коли вам потрібен реалізм qa-lab:
 
 - `pnpm openclaw qa suite`
-  - Запускає сценарії QA на основі репозиторію безпосередньо на хості.
+  - Запускає QA-сценарії з репозиторію безпосередньо на хості.
+  - За замовчуванням запускає кілька вибраних сценаріїв паралельно з ізольованими gateway workers, до 64 workers або кількості вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати кількість workers, або `--concurrency 1` для старішої послідовної ланки.
 - `pnpm openclaw qa suite --runner multipass`
-  - Запускає той самий набір QA у тимчасовій Linux VM Multipass.
+  - Запускає той самий QA-набір усередині тимчасової Linux VM Multipass.
   - Зберігає ту саму поведінку вибору сценаріїв, що й `qa suite` на хості.
   - Повторно використовує ті самі прапорці вибору провайдера/моделі, що й `qa suite`.
-  - Live-запуски передають до гостьової системи підтримувані вхідні дані автентифікації QA, які там практично використовувати:
-    ключі провайдерів через env, шлях до конфігурації QA live provider і `CODEX_HOME`,
-    якщо він присутній.
-  - Каталоги виводу мають залишатися в межах кореня репозиторію, щоб гостьова система могла записувати назад через змонтований workspace.
-  - Записує звичайний звіт і підсумок QA, а також логи Multipass у
+  - Live-запуски перенаправляють підтримувані QA auth inputs, які практичні для guest:
+    ключі провайдерів на основі env, шлях до конфігурації QA live provider і `CODEX_HOME`, якщо він присутній.
+  - Каталоги виводу мають залишатися в межах кореня репозиторію, щоб guest міг записувати назад через змонтований workspace.
+  - Записує звичайний QA-звіт і зведення, а також логи Multipass у
     `.artifacts/qa-e2e/...`.
 - `pnpm qa:lab:up`
-  - Запускає QA-сайт на основі Docker для QA-роботи в операторському стилі.
+  - Запускає QA-сайт на базі Docker для QA-роботи в операторському стилі.
 
 ## Набори тестів (що де запускається)
 
-Думайте про ці набори як про «зростання реалістичності» (і зростання нестабільності/вартості):
+Сприймайте набори як «зростаючий реалізм» (і зростаючу нестабільність/вартість):
 
 ### Unit / integration (типово)
 
 - Команда: `pnpm test`
-- Конфігурація: десять послідовних shard-запусків (`vitest.full-*.config.ts`) через наявні scoped Vitest projects
-- Файли: core/unit inventory у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і whitelisted `ui` node-тести, охоплені `vitest.unit.config.ts`
-- Охоплення:
+- Конфіг: десять послідовних shard-запусків (`vitest.full-*.config.ts`) по наявних scoped Vitest projects
+- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts`, `test/**/*.test.ts` і внесені до allowlist node-тести `ui`, що покриваються `vitest.unit.config.ts`
+- Обсяг:
   - Чисті unit-тести
-  - In-process integration-тести (автентифікація шлюзу, маршрутизація, інструменти, парсинг, конфігурація)
+  - In-process integration-тести (gateway auth, routing, tooling, parsing, config)
   - Детерміновані регресії для відомих помилок
 - Очікування:
   - Запускається в CI
   - Реальні ключі не потрібні
   - Має бути швидким і стабільним
-- Примітка про projects:
-  - Ненацілений `pnpm test` тепер запускає одинадцять менших shard-конфігурацій (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного гігантського native root-project process. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension виснажувати не пов’язані набори.
-  - `pnpm test --watch` усе ще використовує native root `vitest.config.ts` project graph, тому що цикл спостереження з кількома shard непрактичний.
-  - `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 зачіпає лише source/test-файли, які можна маршрутизувати; зміни config/setup усе ще повертаються до широкого повторного запуску root-project.
-  - Вибрані тести `plugin-sdk` і `commands` також маршрутизуються через окремі полегшені lanes, які пропускають `test/setup-openclaw-runtime.ts`; файли зі станом/важким runtime лишаються на наявних lanes.
-  - Вибрані допоміжні source-файли `plugin-sdk` і `commands` також зіставляють changed-mode запуски з явними sibling-тестами в цих полегшених lanes, щоб зміни в helper не вимагали повторного запуску всього важкого набору для цього каталогу.
-  - `auto-reply` тепер має три окремі buckets: top-level core helpers, top-level integration-тести `reply.*` і піддерево `src/auto-reply/reply/**`. Це не дає найважчій роботі harness reply навантажувати дешеві тести status/chunk/token.
+- Примітка щодо projects:
+  - Ненацілений `pnpm test` тепер запускає одинадцять менших shard-конфігів (`core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного великого native root-project процесу. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension виснажувати не пов’язані набори.
+  - `pnpm test --watch` як і раніше використовує граф projects native root `vitest.config.ts`, оскільки цикл спостереження з кількома shards непрактичний.
+  - `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 files; редагування config/setup, як і раніше, повертаються до ширшого повторного запуску root-project.
+  - Вибрані тести `plugin-sdk` і `commands` також маршрутизуються через окремі легкі lanes, які пропускають `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy files залишаються в наявних lanes.
+  - Вибрані helper source files `plugin-sdk` і `commands` також зіставляють changed-mode запуски з явними сусідніми тестами в цих легких lanes, щоб редагування helper не перезапускали повний важкий набір для цього каталогу.
+  - `auto-reply` тепер має три окремі buckets: top-level core helpers, top-level integration-тести `reply.*` і піддерево `src/auto-reply/reply/**`. Це не дає найважчій роботі harness reply перевантажувати дешеві status/chunk/token-тести.
 - Примітка про embedded runner:
-  - Коли ви змінюєте вхідні дані виявлення message-tool або runtime context ущільнення,
+  - Коли ви змінюєте inputs для виявлення message-tool або runtime context compaction,
     зберігайте обидва рівні покриття.
-  - Додавайте сфокусовані регресії helper для чистих меж маршрутизації/нормалізації.
-  - Також підтримуйте справність integration-наборів embedded runner:
+  - Додавайте сфокусовані helper-регресії для чистих меж routing/normalization.
+  - Також підтримуйте здоровими integration-набори 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 і поведінка ущільнення все ще проходять
-    через реальні шляхи `run.ts` / `compact.ts`; самих лише helper-тестів
-    недостатньо як заміни цих integration-шляхів.
-- Примітка про пул:
-  - Базова конфігурація Vitest тепер типово використовує `threads`.
-  - Спільна конфігурація Vitest також фіксує `isolate: false` і використовує non-isolated runner у root projects, e2e і live configs.
-  - 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 тепер навмисно консервативне і також зменшується, коли середнє навантаження хоста вже високе, тож кілька одночасних запусків Vitest за замовчуванням завдають менше шкоди.
-  - Базова конфігурація Vitest позначає projects/config files як `forceRerunTriggers`, щоб повторні запуски в changed-mode лишалися коректними, коли змінюється wiring тестів.
-  - Конфігурація зберігає увімкненим `OPENCLAW_VITEST_FS_MODULE_CACHE` на підтримуваних хостах; установіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете одну явну локацію кешу для прямого профілювання.
+  - Ці набори перевіряють, що scoped ids і поведінка compaction усе ще проходять
+    через реальні шляхи `run.ts` / `compact.ts`; лише helper-тести не є
+    достатньою заміною цим integration-шляхам.
+- Примітка про pool:
+  - Базовий конфіг Vitest тепер за замовчуванням використовує `threads`.
+  - Спільний конфіг Vitest також фіксує `isolate: false` і використовує non-isolated runner у root projects, e2e і live-конфігах.
+  - Root UI lane зберігає свій `jsdom` setup і 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` зберігають ту саму поведінку маршрутизації, лише з вищим лімітом workers.
+  - Автоматичне масштабування локальних workers тепер навмисно консервативне і також зменшується, коли середнє навантаження хоста вже високе, тож кілька одночасних запусків Vitest за замовчуванням завдають менше шкоди.
+  - Базовий конфіг Vitest позначає файли projects/config як `forceRerunTriggers`, щоб reruns у changed-mode залишалися коректними, коли змінюється wiring тестів.
+  - Конфіг зберігає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних хостах; установіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете одну явну локацію кешу для прямого профілювання.
 - Примітка про налагодження продуктивності:
   - `pnpm test:perf:imports` вмикає звітність Vitest про тривалість імпорту та вивід import-breakdown.
-  - `pnpm test:perf:imports:changed` обмежує той самий профілювальний перегляд файлами, зміненими відносно `origin/main`.
-- `pnpm test:perf:changed:bench -- --ref <git-ref>` порівнює маршрутизований `test:changed` з native root-project path для цього зафіксованого diff і виводить wall time та macOS max RSS.
-- `pnpm test:perf:changed:bench -- --worktree` виконує бенчмарк поточного dirty tree, маршрутизуючи список змінених файлів через `scripts/test-projects.mjs` і root Vitest config.
-  - `pnpm test:perf:profile:main` записує CPU profile головного потоку для накладних витрат запуску та трансформації Vitest/Vite.
-  - `pnpm test:perf:profile:runner` записує CPU+heap profiles runner для unit-набору з вимкненим файловим паралелізмом.
+  - `pnpm test:perf:imports:changed` обмежує той самий профільований вигляд файлами, зміненими відносно `origin/main`.
+- `pnpm test:perf:changed:bench -- --ref <git-ref>` порівнює маршрутизований `test:changed` з native root-project шляхом для цього committed diff і виводить wall time та max RSS на macOS.
+- `pnpm test:perf:changed:bench -- --worktree` вимірює поточне брудне дерево, маршрутизуючи список змінених файлів через `scripts/test-projects.mjs` і root-конфіг Vitest.
+  - `pnpm test:perf:profile:main` записує CPU-профіль main-thread для накладних витрат запуску та transform у Vitest/Vite.
+  - `pnpm test:perf:profile:runner` записує CPU+heap профілі runner для unit-набору з вимкненим file parallelism.
 
 ### E2E (gateway smoke)
 
 - Команда: `pnpm test:e2e`
-- Конфігурація: `vitest.e2e.config.ts`
+- Конфіг: `vitest.e2e.config.ts`
 - Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts`
 - Типові параметри runtime:
-  - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію.
-  - Використовує адаптивну кількість worker (CI: до 2, локально: 1 типово).
-  - Типово запускається в тихому режимі, щоб зменшити накладні витрати на I/O консолі.
+  - Використовує Vitest `threads` з `isolate: false`, узгоджено з рештою репозиторію.
+  - Використовує адаптивну кількість workers (CI: до 2, локально: 1 за замовчуванням).
+  - За замовчуванням працює в тихому режимі, щоб зменшити накладні витрати console I/O.
 - Корисні перевизначення:
-  - `OPENCLAW_E2E_WORKERS=<n>` щоб примусово задати кількість worker (обмежено 16).
-  - `OPENCLAW_E2E_VERBOSE=1` щоб знову ввімкнути докладний вивід у консоль.
-- Охоплення:
-  - End-to-end-поведінка шлюзу з кількома екземплярами
-  - Поверхні WebSocket/HTTP, сполучення вузлів і важчий мережевий стек
+  - `OPENCLAW_E2E_WORKERS=<n>` щоб примусово встановити кількість workers (обмежено 16).
+  - `OPENCLAW_E2E_VERBOSE=1` щоб знову ввімкнути докладний вивід у console.
+- Обсяг:
+  - End-to-end поведінка gateway з кількома інстансами
+  - Поверхні WebSocket/HTTP, node pairing і важче мережеве навантаження
 - Очікування:
   - Запускається в CI (коли увімкнено в pipeline)
   - Реальні ключі не потрібні
-  - Більше рухомих частин, ніж у unit-тестів (може бути повільніше)
+  - Має більше рухомих частин, ніж unit-тести (може бути повільнішим)
 
 ### E2E: smoke для backend OpenShell
 
 - Команда: `pnpm test:e2e:openshell`
 - Файл: `test/openshell-sandbox.e2e.test.ts`
-- Охоплення:
-  - Запускає ізольований шлюз OpenShell на хості через Docker
-  - Створює sandbox із тимчасового локального Dockerfile
-  - Перевіряє backend OpenShell OpenClaw через реальні `sandbox ssh-config` + SSH exec
-  - Перевіряє канонічну поведінку віддаленої файлової системи через міст fs sandbox
+- Обсяг:
+  - Запускає ізольований OpenShell gateway на хості через Docker
+  - Створює sandbox з тимчасового локального Dockerfile
+  - Перевіряє backend OpenShell у OpenClaw через реальні `sandbox ssh-config` + SSH exec
+  - Перевіряє поведінку remote-canonical filesystem через fs bridge sandbox
 - Очікування:
-  - Лише за явного ввімкнення; не входить до типового запуску `pnpm test:e2e`
-  - Потрібні локальний CLI `openshell` і робочий Docker daemon
-  - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує тестовий шлюз і sandbox
+  - Лише opt-in; не входить до типового запуску `pnpm test:e2e`
+  - Потребує локальний CLI `openshell` і працездатний Docker daemon
+  - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, після чого знищує тестовий gateway і sandbox
 - Корисні перевизначення:
   - `OPENCLAW_E2E_OPENSHELL=1` щоб увімкнути тест під час ручного запуску ширшого e2e-набору
   - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` щоб указати нестандартний бінарний файл CLI або wrapper script
@@ -164,119 +164,119 @@ OpenClaw має три набори Vitest (unit/integration, e2e, live) і не
 ### Live (реальні провайдери + реальні моделі)
 
 - Команда: `pnpm test:live`
-- Конфігурація: `vitest.live.config.ts`
+- Конфіг: `vitest.live.config.ts`
 - Файли: `src/**/*.live.test.ts`
 - Типово: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`)
-- Охоплення:
+- Обсяг:
   - «Чи справді цей провайдер/модель працює _сьогодні_ з реальними обліковими даними?»
-  - Виявлення змін форматів провайдерів, особливостей виклику інструментів, проблем автентифікації та поведінки за rate limit
+  - Виявлення змін формату провайдера, особливостей tool calling, проблем auth і поведінки rate limit
 - Очікування:
-  - Навмисно нестабільні для CI (реальні мережі, реальні політики провайдерів, квоти, відмови)
-  - Коштують грошей / споживають rate limits
+  - За задумом не є стабільним для CI (реальні мережі, реальні політики провайдерів, квоти, збої)
+  - Коштує грошей / використовує rate limits
   - Краще запускати звужені підмножини, а не «все»
-- Live-запуски завантажують `~/.profile`, щоб підхопити відсутні API-ключі.
-- Типово live-запуски все одно ізолюють `HOME` і копіюють матеріали config/auth до тимчасової домашньої теки тесту, щоб unit-fixtures не могли змінити ваш реальний `~/.openclaw`.
-- Установлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли вам навмисно потрібно, щоб live-тести використовували вашу реальну домашню теку.
-- `pnpm test:live` тепер типово використовує тихіший режим: він зберігає вивід прогресу `[live] ...`, але приховує додаткове повідомлення про `~/.profile` і приглушує логи bootstrap шлюзу/Bonjour. Установіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете знову бачити повні логи запуску.
-- Ротація API-ключів (специфічна для провайдера): установіть `*_API_KEYS` у форматі з комами/крапками з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або використайте перевизначення для конкретного live-запуску через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу у відповідь на rate limit.
+- Live-запуски підвантажують `~/.profile`, щоб отримати відсутні API-ключі.
+- За замовчуванням live-запуски все одно ізолюють `HOME` і копіюють config/auth material у тимчасовий test home, щоб unit fixtures не могли змінити ваш реальний `~/.openclaw`.
+- Установлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли вам навмисно потрібно, щоб live-тести використовували ваш реальний домашній каталог.
+- `pnpm test:live` тепер за замовчуванням працює в тихішому режимі: він зберігає вивід прогресу `[live] ...`, але приглушує додаткове повідомлення про `~/.profile` і вимикає логи bootstrap gateway/шум Bonjour. Установіть `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, щоб рядки прогресу провайдера/шлюзу транслювалися одразу під час live-запусків.
-  - Налаштувати heartbeat для прямих моделей можна через `OPENCLAW_LIVE_HEARTBEAT_MS`.
-  - Налаштувати heartbeat для шлюзу/перевірок можна через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`.
+  - Live-набори тепер виводять рядки прогресу в stderr, щоб довгі виклики провайдера було видно як активні навіть тоді, коли захоплення console у Vitest тихе.
+  - `vitest.live.config.ts` вимикає перехоплення console у Vitest, тому рядки прогресу provider/gateway транслюються негайно під час live-запусків.
+  - Налаштовуйте heartbeat для прямих викликів моделей через `OPENCLAW_LIVE_HEARTBEAT_MS`.
+  - Налаштовуйте heartbeat gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`.
 
 ## Який набір мені запускати?
 
 Використовуйте таку таблицю рішень:
 
-- Редагуєте логіку/тести: запускайте `pnpm test` (і `pnpm test:coverage`, якщо змінили багато)
-- Торкаєтеся мережевого стеку шлюзу / WS protocol / pairing: додайте `pnpm test:e2e`
-- Налагоджуєте «мій бот не працює» / збої, специфічні для провайдера / виклик інструментів: запускайте звужений `pnpm test:live`
+- Редагуєте логіку/тести: запустіть `pnpm test` (і `pnpm test:coverage`, якщо змінили багато)
+- Торкаєтесь gateway networking / WS protocol / pairing: додайте `pnpm test:e2e`
+- Налагоджуєте «мій бот не працює» / збої, специфічні для провайдера / tool calling: запустіть звужений `pnpm test:live`
 
 ## Live: перевірка можливостей Android node
 
 - Тест: `src/gateway/android-node.capabilities.live.test.ts`
 - Скрипт: `pnpm android:test:integration`
-- Мета: викликати **кожну команду, яку наразі оголошує** підключений Android node, і перевірити поведінку контракту команд.
-- Охоплення:
-  - Попередньо підготовлене/ручне налаштування (набір не встановлює, не запускає і не сполучає застосунок).
-  - Покомандна валідація gateway `node.invoke` для вибраного Android node.
-- Потрібне попереднє налаштування:
-  - Android-застосунок уже підключений і сполучений зі шлюзом.
+- Мета: викликати **кожну команду, яка наразі оголошена** підключеним Android node, і перевірити поведінку контракту команди.
+- Обсяг:
+  - Попередньо підготовлене/ручне налаштування (набір не встановлює/не запускає/не виконує pairing для застосунку).
+  - Перевірка `node.invoke` у gateway для вибраного Android node, команда за командою.
+- Обов’язкова попередня підготовка:
+  - Android app уже підключено й виконано pairing з gateway.
   - Застосунок утримується на передньому плані.
-  - Надано дозволи/згоду на захоплення для можливостей, які ви очікуєте успішно пройти.
+  - Дозволи/згода на захоплення надані для можливостей, які ви очікуєте успішно пройти.
 - Необов’язкові перевизначення цілі:
   - `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)
+- Повні відомості про налаштування Android: [Android App](/uk/platforms/android)
 
-## Live: smoke моделей (ключі профілів)
+## Live: smoke для моделей (ключі профілів)
 
-Live-тести поділено на два шари, щоб можна було ізолювати збої:
+Live-тести розділені на два рівні, щоб можна було ізолювати збої:
 
-- «Пряма модель» показує, чи може провайдер/модель узагалі відповісти з наданим ключем.
-- «Gateway smoke» показує, чи працює для цієї моделі повний конвеєр gateway+agent (сесії, історія, інструменти, політика sandbox тощо).
+- «Direct model» показує, чи може провайдер/модель взагалі відповісти з наданим ключем.
+- «Gateway smoke» показує, чи працює повний конвеєр gateway+agent для цієї моделі (сесії, історія, tools, sandbox policy тощо).
 
-### Шар 1: Пряме завершення моделі (без gateway)
+### Рівень 1: пряме завершення моделі без gateway
 
 - Тест: `src/agents/models.profiles.live.test.ts`
 - Мета:
   - Перелічити виявлені моделі
   - Використати `getApiKeyForModel` для вибору моделей, для яких у вас є облікові дані
-  - Запустити невелике завершення для кожної моделі (і таргетовані регресії там, де потрібно)
+  - Виконати невелике completion для кожної моделі (і цільові регресії, де потрібно)
 - Як увімкнути:
-  - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму)
-- Установіть `OPENCLAW_LIVE_MODELS=modern` (або `all`, псевдонім для modern), щоб справді запустити цей набір; інакше він буде пропущений, щоб `pnpm test:live` залишався зосередженим на gateway smoke
+  - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо запускати Vitest напряму)
+- Установіть `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=all` — це псевдонім для modern allowlist
+  - `OPENCLAW_LIVE_MODELS=modern` для запуску сучасного allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
+  - `OPENCLAW_LIVE_MODELS=all` — це псевдонім для сучасного allowlist
   - або `OPENCLAW_LIVE_MODELS="openai/gpt-5.4,anthropic/claude-opus-4-6,..."` (allowlist через кому)
-  - Modern/all sweeps типово мають підібрану межу з високим сигналом; установіть `OPENCLAW_LIVE_MAX_MODELS=0` для вичерпного modern sweep або додатне число для меншої межі.
+  - Перевірки modern/all за замовчуванням мають curated high-signal limit; установіть `OPENCLAW_LIVE_MAX_MODELS=0` для повної modern-перевірки або додатне число для меншого ліміту.
 - Як вибирати провайдерів:
   - `OPENCLAW_LIVE_PROVIDERS="google,google-antigravity,google-gemini-cli"` (allowlist через кому)
 - Звідки беруться ключі:
-  - Типово: сховище профілів і резервні варіанти через env
-  - Установіть `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати **лише сховище профілів**
+  - За замовчуванням: profile store і резервні значення з env
+  - Установіть `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати **лише profile store**
 - Навіщо це існує:
   - Відокремлює «API провайдера зламане / ключ недійсний» від «конвеєр gateway agent зламаний»
-  - Містить невеликі ізольовані регресії (приклад: OpenAI Responses/Codex Responses reasoning replay + потоки виклику інструментів)
+  - Містить невеликі ізольовані регресії (приклад: відтворення reasoning replay + flows tool-call у OpenAI Responses/Codex Responses)
 
-### Шар 2: Gateway + smoke dev agent (що насправді робить "@openclaw")
+### Рівень 2: smoke gateway + dev agent (що насправді робить "@openclaw")
 
 - Тест: `src/gateway/gateway-models.profiles.live.test.ts`
 - Мета:
-  - Запустити in-process gateway
-  - Створити/змінити сесію `agent:dev:*` (з перевизначенням моделі для кожного запуску)
-  - Перебрати моделі-з-ключами й перевірити:
-    - «змістовну» відповідь (без інструментів)
-    - що працює реальний виклик інструмента (перевірка `read`)
-    - необов’язкові додаткові перевірки інструментів (перевірка `exec+read`)
-    - що шляхи регресій OpenAI (лише виклик інструмента → подальший крок) і далі працюють
-- Подробиці перевірок (щоб ви могли швидко пояснити збої):
-  - перевірка `read`: тест записує nonce-файл у workspace і просить агента `read` його та повернути nonce.
-  - перевірка `exec+read`: тест просить агента через `exec` записати nonce у тимчасовий файл, а потім прочитати його назад через `read`.
-  - перевірка зображення: тест прикріплює згенерований PNG (cat + випадковий код) і очікує, що модель поверне `cat <CODE>`.
+  - Підняти in-process gateway
+  - Створити/пропатчити сесію `agent:dev:*` (перевизначення моделі для кожного запуску)
+  - Перебрати моделі з ключами й перевірити:
+    - «змістовну» відповідь (без tools)
+    - що працює реальний виклик tool (read probe)
+    - необов’язкові додаткові tool probes (exec+read probe)
+    - що шляхи регресій OpenAI (лише tool-call → follow-up) продовжують працювати
+- Деталі probe (щоб ви могли швидко пояснити збої):
+  - probe `read`: тест записує nonce-файл у workspace і просить агента `read` його та повернути nonce назад.
+  - probe `exec+read`: тест просить агента через `exec` записати nonce у тимчасовий файл, а потім через `read` зчитати його назад.
+  - image probe: тест прикріплює згенерований PNG (cat + рандомізований код) і очікує, що модель поверне `cat <CODE>`.
   - Посилання на реалізацію: `src/gateway/gateway-models.profiles.live.test.ts` і `src/gateway/live-image-probe.ts`.
 - Як увімкнути:
-  - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму)
+  - `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
+  - За замовчуванням: сучасний allowlist (Opus/Sonnet 4.6+, GPT-5.x + Codex, Gemini 3, GLM 4.7, MiniMax M2.7, Grok 4)
+  - `OPENCLAW_LIVE_GATEWAY_MODELS=all` — це псевдонім для сучасного allowlist
   - Або встановіть `OPENCLAW_LIVE_GATEWAY_MODELS="provider/model"` (або список через кому), щоб звузити вибір
-  - Modern/all gateway sweeps типово мають підібрану межу з високим сигналом; установіть `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` для вичерпного modern sweep або додатне число для меншої межі.
-- Як вибирати провайдерів (уникати «усе через OpenRouter»):
+  - Перевірки modern/all для gateway за замовчуванням мають curated high-signal limit; установіть `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=0` для повної modern-перевірки або додатне число для меншого ліміту.
+- Як вибирати провайдерів (уникайте «усе через OpenRouter»):
   - `OPENCLAW_LIVE_GATEWAY_PROVIDERS="google,google-antigravity,google-gemini-cli,openai,anthropic,zai,minimax"` (allowlist через кому)
-- Перевірки інструментів і зображень у цьому live-тесті завжди ввімкнені:
-  - перевірка `read` + перевірка `exec+read` (навантаження на інструменти)
-  - перевірка зображення запускається, коли модель оголошує підтримку вхідних зображень
+- Tool + image probes у цьому live-тесті завжди ввімкнені:
+  - probe `read` + probe `exec+read` (навантажувальна перевірка tools)
+  - image probe запускається, коли модель оголошує підтримку image input
   - Потік (на високому рівні):
-    - Тест генерує крихітний PNG із «CAT» + випадковим кодом (`src/gateway/live-image-probe.ts`)
+    - Тест генерує крихітний PNG з “CAT” + випадковим кодом (`src/gateway/live-image-probe.ts`)
     - Надсилає його через `agent` `attachments: [{ mimeType: "image/png", content: "<base64>" }]`
-    - Gateway розбирає вкладення в `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`)
-    - Embedded agent пересилає мультимодальне повідомлення користувача моделі
-    - Перевірка: відповідь містить `cat` + код (допуск OCR: незначні помилки дозволені)
+    - Gateway розбирає attachments у `images[]` (`src/gateway/server-methods/agent.ts` + `src/gateway/chat-attachments.ts`)
+    - Embedded agent пересилає мультимодальне повідомлення користувача до моделі
+    - Перевірка: відповідь містить `cat` + код (OCR tolerance: незначні помилки допустимі)
 
-Порада: щоб побачити, що саме можна протестувати на вашій машині (і точні ідентифікатори `provider/model`), виконайте:
+Порада: щоб побачити, що ви можете тестувати на своїй машині (і точні ідентифікатори `provider/model`), запустіть:
 
 ```bash
 openclaw models list
@@ -286,23 +286,23 @@ openclaw models list --json
 ## Live: smoke для CLI backend (Claude, Codex, Gemini або інші локальні CLI)
 
 - Тест: `src/gateway/gateway-cli-backend.live.test.ts`
-- Мета: перевірити конвеєр Gateway + agent за допомогою локального CLI backend, не торкаючись вашої типової конфігурації.
-- Типові параметри smoke, специфічні для backend, містяться у визначенні `cli-backend.ts` відповідного extension.
+- Мета: перевірити конвеєр Gateway + agent за допомогою локального CLI backend, не торкаючись вашого типового config.
+- Типові параметри smoke для конкретного backend зберігаються у визначенні `cli-backend.ts` extension-власника.
 - Увімкнення:
-  - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо викликаєте Vitest напряму)
+  - `pnpm test:live` (або `OPENCLAW_LIVE_TEST=1`, якщо запускати Vitest напряму)
   - `OPENCLAW_LIVE_CLI_BACKEND=1`
 - Типові значення:
-  - Типовий провайдер/модель: `claude-cli/claude-sonnet-4-6`
-  - Поведінка command/args/image береться з метаданих plugin відповідного CLI backend.
-- Перевизначення (необов’язкові):
+  - Типовий provider/model: `claude-cli/claude-sonnet-4-6`
+  - Поведінка command/args/image береться з метаданих plugin CLI backend-власника.
+- Перевизначення (необов’язково):
   - `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`, щоб надіслати реальне вкладення-зображення (шляхи підставляються в prompt).
-  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"`, щоб передавати шляхи до файлів зображень як аргументи CLI замість вбудовування в prompt.
-  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (або `"list"`), щоб керувати передаванням аргументів зображень, коли встановлено `IMAGE_ARG`.
-  - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1`, щоб надіслати другий хід і перевірити потік resume.
-  - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0`, щоб вимкнути типову перевірку безперервності тієї самої сесії Claude Sonnet -> Opus (установіть `1`, щоб примусово ввімкнути її, коли вибрана модель підтримує ціль переключення).
+  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_PROBE=1` щоб надіслати реальне image attachment (шляхи вставляються в prompt).
+  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_ARG="--image"` щоб передавати шляхи до image files як CLI args замість вставки в prompt.
+  - `OPENCLAW_LIVE_CLI_BACKEND_IMAGE_MODE="repeat"` (або `"list"`) щоб керувати тим, як передаються image args, коли встановлено `IMAGE_ARG`.
+  - `OPENCLAW_LIVE_CLI_BACKEND_RESUME_PROBE=1` щоб надіслати другий хід і перевірити flow resume.
+  - `OPENCLAW_LIVE_CLI_BACKEND_MODEL_SWITCH_PROBE=0` щоб вимкнути типову перевірку безперервності тієї самої сесії Claude Sonnet -> Opus (установіть `1`, щоб примусово ввімкнути її, коли вибрана модель підтримує ціль перемикання).
 
 Приклад:
 
@@ -318,7 +318,7 @@ OPENCLAW_LIVE_CLI_BACKEND=1 \
 pnpm test:docker:live-cli-backend
 ```
 
-Рецепти Docker для одного провайдера:
+Docker-рецепти для одного провайдера:
 
 ```bash
 pnpm test:docker:live-cli-backend:claude
@@ -329,28 +329,28 @@ pnpm test:docker:live-cli-backend:gemini
 
 Примітки:
 
-- Виконавець Docker розташований у `scripts/test-live-cli-backend-docker.sh`.
-- Він запускає live smoke CLI-backend усередині Docker-образу репозиторію як непривілейований користувач `node`.
-- Він визначає метадані CLI smoke з extension-власника, а потім встановлює відповідний Linux CLI-пакет (`@anthropic-ai/claude-code`, `@openai/codex` або `@google/gemini-cli`) у кешований записуваний префікс за адресою `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (типово: `~/.cache/openclaw/docker-cli-tools`).
-- `pnpm test:docker:live-cli-backend:claude-subscription` потребує портативної OAuth-підписки Claude Code через `~/.claude/.credentials.json` з `claudeAiOauth.subscriptionType` або `CLAUDE_CODE_OAUTH_TOKEN` з `claude setup-token`. Спочатку він доводить роботу прямого `claude -p` у Docker, а потім виконує два ходи Gateway CLI-backend без збереження env-змінних Anthropic API-key. Ця subscription-lane типово вимикає перевірки Claude MCP/tool і image, оскільки зараз Claude маршрутизує використання сторонніх застосунків через додаткове білінг-споживання, а не через звичайні ліміти тарифного плану підписки.
-- Live smoke CLI-backend тепер перевіряє однаковий end-to-end-потік для Claude, Codex і Gemini: текстовий хід, хід із класифікацією зображення, а потім виклик інструмента MCP `cron`, перевірений через gateway CLI.
-- Типовий smoke Claude також змінює сесію із Sonnet на Opus і перевіряє, що відновлена сесія досі пам’ятає попередню нотатку.
+- Docker-раннер розташований у `scripts/test-live-cli-backend-docker.sh`.
+- Він запускає live smoke для CLI-backend усередині Docker image репозиторію як непривілейований користувач `node`.
+- Він визначає метадані CLI smoke з extension-власника, а потім установлює відповідний Linux CLI package (`@anthropic-ai/claude-code`, `@openai/codex` або `@google/gemini-cli`) у кешований writable prefix за адресою `OPENCLAW_DOCKER_CLI_TOOLS_DIR` (типово: `~/.cache/openclaw/docker-cli-tools`).
+- `pnpm test:docker:live-cli-backend:claude-subscription` потребує portable Claude Code subscription OAuth через або `~/.claude/.credentials.json` з `claudeAiOauth.subscriptionType`, або `CLAUDE_CODE_OAUTH_TOKEN` з `claude setup-token`. Спочатку він перевіряє прямий `claude -p` у Docker, а потім виконує два ходи Gateway CLI-backend без збереження env vars Anthropic API-key. Ця subscription-ланка за замовчуванням вимикає Claude MCP/tool та image probes, оскільки Claude наразі маршрутизує використання сторонніх застосунків через виставлення рахунків за додаткове використання, а не через звичайні ліміти subscription plan.
+- Live smoke CLI-backend тепер перевіряє той самий наскрізний потік для Claude, Codex і Gemini: текстовий хід, хід класифікації зображення, потім виклик MCP tool `cron`, перевірений через gateway CLI.
+- Типовий smoke для Claude також патчить сесію з Sonnet на Opus і перевіряє, що відновлена сесія все ще пам’ятає попередню нотатку.
 
-## Live: smoke для ACP bind (`/acp spawn ... --bind here`)
+## Live: smoke прив’язки ACP (`/acp spawn ... --bind here`)
 
 - Тест: `src/gateway/gateway-acp-bind.live.test.ts`
-- Мета: перевірити реальний потік ACP conversation-bind із live ACP agent:
+- Мета: перевірити реальний flow conversation-bind ACP з live ACP agent:
   - надіслати `/acp spawn <agent> --bind here`
   - прив’язати синтетичну розмову message-channel на місці
-  - надіслати звичайний подальший хід у тій самій розмові
-  - перевірити, що подальший хід потрапляє в transcript прив’язаної ACP session
+  - надіслати звичайне подальше повідомлення в тій самій розмові
+  - переконатися, що подальше повідомлення потрапляє до transcript прив’язаної сесії ACP
 - Увімкнення:
   - `pnpm test:live src/gateway/gateway-acp-bind.live.test.ts`
   - `OPENCLAW_LIVE_ACP_BIND=1`
 - Типові значення:
   - ACP agents у Docker: `claude,codex,gemini`
   - ACP agent для прямого `pnpm test:live ...`: `claude`
-  - Синтетичний канал: контекст розмови в стилі Slack DM
+  - Синтетичний channel: контекст розмови у стилі Slack DM
   - ACP backend: `acpx`
 - Перевизначення:
   - `OPENCLAW_LIVE_ACP_BIND_AGENT=claude`
@@ -359,8 +359,8 @@ pnpm test:docker:live-cli-backend:gemini
   - `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude,codex,gemini`
   - `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND='npx -y @agentclientprotocol/claude-agent-acp@<version>'`
 - Примітки:
-  - Ця lane використовує поверхню gateway `chat.send` з синтетичними полями originating-route лише для адміністраторів, щоб тести могли приєднати контекст message-channel без удаваної зовнішньої доставки.
-  - Коли `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` не задано, тест використовує вбудований реєстр агентів plugin `acpx` для вибраного ACP harness agent.
+  - Ця ланка використовує поверхню gateway `chat.send` з admin-only synthetic originating-route fields, щоб тести могли прикріпити контекст message-channel без імітації зовнішньої доставки.
+  - Коли `OPENCLAW_LIVE_ACP_BIND_AGENT_COMMAND` не встановлено, тест використовує вбудований реєстр агентів plugin `acpx` для вибраного ACP harness agent.
 
 Приклад:
 
@@ -376,7 +376,7 @@ OPENCLAW_LIVE_ACP_BIND=1 \
 pnpm test:docker:live-acp-bind
 ```
 
-Рецепти Docker для окремих агентів:
+Docker-рецепти для одного агента:
 
 ```bash
 pnpm test:docker:live-acp-bind:claude
@@ -386,23 +386,23 @@ pnpm test:docker:live-acp-bind:gemini
 
 Примітки щодо Docker:
 
-- Виконавець Docker розташований у `scripts/test-live-acp-bind-docker.sh`.
-- Типово він запускає smoke ACP bind послідовно для всіх підтримуваних live CLI agents: `claude`, `codex`, потім `gemini`.
+- Docker-раннер розташований у `scripts/test-live-acp-bind-docker.sh`.
+- За замовчуванням він послідовно запускає smoke прив’язки ACP для всіх підтримуваних live CLI agents: `claude`, `codex`, а потім `gemini`.
 - Використовуйте `OPENCLAW_LIVE_ACP_BIND_AGENTS=claude`, `OPENCLAW_LIVE_ACP_BIND_AGENTS=codex` або `OPENCLAW_LIVE_ACP_BIND_AGENTS=gemini`, щоб звузити матрицю.
-- Він завантажує `~/.profile`, підготовлює відповідні матеріали автентифікації CLI у контейнері, встановлює `acpx` у записуваний npm-префікс, а потім установлює потрібний live CLI (`@anthropic-ai/claude-code`, `@openai/codex` або `@google/gemini-cli`), якщо його немає.
-- Усередині Docker виконавець установлює `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, щоб acpx зберігав env-змінні провайдера із завантаженого профілю доступними для дочірнього CLI harness.
+- Він підвантажує `~/.profile`, переносить відповідний CLI auth material у контейнер, установлює `acpx` у writable npm prefix, а потім установлює потрібний live CLI (`@anthropic-ai/claude-code`, `@openai/codex` або `@google/gemini-cli`), якщо його немає.
+- Усередині Docker раннер встановлює `OPENCLAW_LIVE_ACP_BIND_ACPX_COMMAND=$HOME/.npm-global/bin/acpx`, щоб acpx зберігав env vars провайдера із завантаженого профілю доступними для дочірнього harness CLI.
 
 ### Рекомендовані live-рецепти
 
-Найшвидші й найменш нестабільні — вузькі, явні allowlist:
+Найшвидшими та найменш нестабільними є вузькі, явні allowlist:
 
-- Одна модель, напряму (без gateway):
+- Одна модель, direct (без gateway):
   - `OPENCLAW_LIVE_MODELS="openai/gpt-5.4" pnpm test:live src/agents/models.profiles.live.test.ts`
 
 - Одна модель, gateway smoke:
   - `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`
 
-- Виклик інструментів через кількох провайдерів:
+- 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-ключ Gemini + Antigravity):
@@ -412,21 +412,21 @@ pnpm test:docker:live-acp-bind:gemini
 Примітки:
 
 - `google/...` використовує Gemini API (API-ключ).
-- `google-antigravity/...` використовує міст Antigravity OAuth (endpoint агента у стилі Cloud Code Assist).
-- `google-gemini-cli/...` використовує локальний Gemini CLI на вашій машині (окрема автентифікація + особливості інструментів).
+- `google-antigravity/...` використовує міст OAuth Antigravity (endpoint агента у стилі Cloud Code Assist).
+- `google-gemini-cli/...` використовує локальний Gemini CLI на вашій машині (окрема auth + особливості tools).
 - Gemini API проти Gemini CLI:
-  - API: OpenClaw викликає розміщений Google Gemini API через HTTP (API-ключ / автентифікація профілю); це те, що більшість користувачів мають на увазі під «Gemini».
-  - CLI: OpenClaw викликає локальний бінарний файл `gemini`; він має власну автентифікацію й може поводитися інакше (streaming/підтримка інструментів/розсинхрон версій).
+  - API: OpenClaw викликає хостований Gemini API від Google через HTTP (API-ключ / auth профілю); саме це більшість користувачів мають на увазі під «Gemini».
+  - CLI: OpenClaw виконує shell-виклик локального бінарного файла `gemini`; він має власну auth і може поводитися інакше (streaming/tool support/version skew).
 
 ## Live: матриця моделей (що ми охоплюємо)
 
-Фіксованого «списку моделей CI» немає (live — за явного ввімкнення), але ось **рекомендовані** моделі для регулярного покриття на машині розробника з ключами.
+Фіксованого «списку моделей CI» немає (live є opt-in), але це **рекомендовані** моделі, які варто регулярно покривати на dev-машині з ключами.
 
-### Сучасний набір smoke (виклик інструментів + зображення)
+### Сучасний 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)
@@ -434,12 +434,12 @@ pnpm test:docker:live-acp-bind:gemini
 - Z.AI (GLM): `zai/glm-4.7`
 - MiniMax: `minimax/MiniMax-M2.7`
 
-Запуск gateway smoke з інструментами + зображенням:
+Запускати gateway smoke з tools + image:
 `OPENCLAW_LIVE_GATEWAY_MODELS="openai/gpt-5.4,openai-codex/gpt-5.4,anthropic/claude-opus-4-6,google/gemini-3.1-pro-preview,google/gemini-3-flash-preview,google-antigravity/claude-opus-4-6-thinking,google-antigravity/gemini-3-flash,zai/glm-4.7,minimax/MiniMax-M2.7" pnpm test:live src/gateway/gateway-models.profiles.live.test.ts`
 
-### Базовий рівень: виклик інструментів (Read + необов’язковий Exec)
+### Базовий рівень: 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`)
@@ -447,152 +447,152 @@ pnpm test:docker:live-acp-bind:gemini
 - Z.AI (GLM): `zai/glm-4.7`
 - MiniMax: `minimax/MiniMax-M2.7`
 
-Необов’язкове додаткове покриття (корисно мати):
+Необов’язкове додаткове покриття (бажано мати):
 
 - xAI: `xai/grok-4` (або найновіша доступна)
-- Mistral: `mistral/`… (виберіть одну модель із підтримкою «tools», яку у вас ввімкнено)
+- Mistral: `mistral/`… (виберіть одну модель із підтримкою `tools`, яку у вас увімкнено)
 - Cerebras: `cerebras/`… (якщо у вас є доступ)
-- LM Studio: `lmstudio/`… (локально; виклик інструментів залежить від режиму API)
+- LM Studio: `lmstudio/`… (локально; tool calling залежить від режиму API)
 
-### Vision: надсилання зображення (вкладення → мультимодальне повідомлення)
+### Vision: надсилання image (attachment → мультимодальне повідомлення)
 
-Додайте щонайменше одну модель із підтримкою зображень до `OPENCLAW_LIVE_GATEWAY_MODELS` (Claude/Gemini/варіанти OpenAI з підтримкою vision тощо), щоб задіяти перевірку зображень.
+Додайте принаймні одну модель із підтримкою image до `OPENCLAW_LIVE_GATEWAY_MODELS` (варіанти Claude/Gemini/OpenAI з підтримкою vision тощо), щоб перевірити image probe.
 
-### Агрегатори / альтернативні шлюзи
+### Агрегатори / альтернативні gateways
 
 Якщо у вас увімкнені ключі, ми також підтримуємо тестування через:
 
-- OpenRouter: `openrouter/...` (сотні моделей; використовуйте `openclaw models scan`, щоб знайти кандидатів із підтримкою інструментів і зображень)
-- OpenCode: `opencode/...` для Zen і `opencode-go/...` для Go (автентифікація через `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`)
+- OpenRouter: `openrouter/...` (сотні моделей; використовуйте `openclaw models scan`, щоб знайти відповідні кандидати з підтримкою tools+image)
+- OpenCode: `opencode/...` для Zen і `opencode-go/...` для Go (auth через `OPENCODE_API_KEY` / `OPENCODE_ZEN_API_KEY`)
 
-Інші провайдери, які можна включити до live-матриці (якщо у вас є облікові дані/конфігурація):
+Більше провайдерів, які можна включити в live-матрицю (якщо у вас є creds/config):
 
 - Вбудовані: `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` (власні endpoint): `minimax` (хмара/API), а також будь-який проксі, сумісний з OpenAI/Anthropic (LM Studio, vLLM, LiteLLM тощо)
+- Через `models.providers` (власні endpoints): `minimax` (cloud/API), а також будь-який сумісний із OpenAI/Anthropic proxy (LM Studio, vLLM, LiteLLM тощо)
 
-Порада: не намагайтеся жорстко кодувати в документації «усі моделі». Авторитетний список — це те, що повертає `discoverModels(...)` на вашій машині, плюс доступні ключі.
+Порада: не намагайтеся жорстко закодувати в документації «усі моделі». Авторитетний список — це те, що повертає `discoverModels(...)` на вашій машині, плюс доступні ключі.
 
 ## Облікові дані (ніколи не комітьте)
 
-Live-тести знаходять облікові дані так само, як це робить CLI. Практичні наслідки:
+Live-тести знаходять облікові дані так само, як і CLI. Практичні наслідки:
 
 - Якщо CLI працює, live-тести мають знаходити ті самі ключі.
-- Якщо live-тест повідомляє «немає облікових даних», налагоджуйте це так само, як налагоджували б `openclaw models list` / вибір моделі.
+- Якщо live-тест каже «немає creds», налагоджуйте це так само, як налагоджували б `openclaw models list` / вибір моделі.
 
-- Профілі автентифікації для кожного агента: `~/.openclaw/agents/<agentId>/agent/auth-profiles.json` (саме це в live-тестах означає «ключі профілю»)
-- Конфігурація: `~/.openclaw/openclaw.json` (або `OPENCLAW_CONFIG_PATH`)
-- Каталог застарілого стану: `~/.openclaw/credentials/` (копіюється до staged live home, якщо присутній, але це не основне сховище ключів профілів)
-- Локальні live-запуски типово копіюють активну конфігурацію, файли `auth-profiles.json` для кожного агента, застарілий `credentials/` і підтримувані зовнішні каталоги автентифікації CLI до тимчасової домашньої теки тесту; staged live home пропускають `workspace/` і `sandboxes/`, а перевизначення шляхів `agents.*.workspace` / `agentDir` прибираються, щоб перевірки не торкалися вашого реального хостового workspace.
+- Профілі auth для кожного агента: `~/.openclaw/agents/<agentId>/agent/auth-profiles.json` (саме це означає «ключі профілів» у live-тестах)
+- Config: `~/.openclaw/openclaw.json` (або `OPENCLAW_CONFIG_PATH`)
+- Каталог застарілого стану: `~/.openclaw/credentials/` (копіюється в підготовлений live home, якщо присутній, але не є основним сховищем ключів профілів)
+- Локальні live-запуски за замовчуванням копіюють активний config, файли `auth-profiles.json` для кожного агента, застарілий `credentials/` і підтримувані зовнішні каталоги auth CLI до тимчасового test home; підготовлені live homes пропускають `workspace/` і `sandboxes/`, а перевизначення шляхів `agents.*.workspace` / `agentDir` видаляються, щоб probes не працювали у вашому реальному workspace хоста.
 
-Якщо ви хочете покладатися на env-ключі (наприклад, експортовані у вашому `~/.profile`), запускайте локальні тести після `source ~/.profile`, або використовуйте Docker-виконавці нижче (вони можуть монтувати `~/.profile` у контейнер).
+Якщо ви хочете покладатися на env keys (наприклад, експортовані у вашому `~/.profile`), запускайте локальні тести після `source ~/.profile`, або використовуйте Docker-раннери нижче (вони можуть монтувати `~/.profile` у контейнер).
 
-## Deepgram live (транскрипція аудіо)
+## Live: Deepgram (транскрипція аудіо)
 
 - Тест: `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`
 
-## BytePlus coding plan live
+## Live: BytePlus coding plan
 
 - Тест: `src/agents/byteplus.live.test.ts`
 - Увімкнення: `BYTEPLUS_API_KEY=... BYTEPLUS_LIVE_TEST=1 pnpm test:live src/agents/byteplus.live.test.ts`
 - Необов’язкове перевизначення моделі: `BYTEPLUS_CODING_MODEL=ark-code-latest`
 
-## ComfyUI workflow media live
+## Live: медіа workflow ComfyUI
 
 - Тест: `extensions/comfy/comfy.live.test.ts`
 - Увімкнення: `OPENCLAW_LIVE_TEST=1 COMFY_LIVE_TEST=1 pnpm test:live -- extensions/comfy/comfy.live.test.ts`
-- Охоплення:
-  - Перевіряє вбудовані шляхи comfy для зображень, відео та `music_generate`
+- Обсяг:
+  - Перевіряє вбудовані шляхи comfy для image, video і `music_generate`
   - Пропускає кожну можливість, якщо `models.providers.comfy.<capability>` не налаштовано
-  - Корисно після змін у надсиланні workflow comfy, опитуванні, завантаженнях або реєстрації plugin
+  - Корисно після змін у надсиланні workflow comfy, polling, downloads або реєстрації plugin
 
-## Image generation live
+## 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 генерації зображень
-  - Завантажує відсутні env-змінні провайдерів із вашої оболонки входу (`~/.profile`) перед перевіркою
-  - Типово використовує live/env API-ключі раніше за збережені профілі автентифікації, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні облікові дані оболонки
-  - Пропускає провайдерів без придатної автентифікації/профілю/моделі
+- Обсяг:
+  - Перелічує кожен зареєстрований plugin провайдера генерації зображень
+  - Завантажує відсутні env vars провайдера з вашої оболонки входу (`~/.profile`) перед перевіркою
+  - За замовчуванням використовує live/env API-ключі раніше за збережені профілі auth, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні облікові дані оболонки
+  - Пропускає провайдерів без придатних auth/profile/model
   - Запускає стандартні варіанти генерації зображень через спільну runtime capability:
     - `google:flash-generate`
     - `google:pro-generate`
     - `google:pro-edit`
     - `openai:default-generate`
-- Поточні вбудовані провайдери, що охоплюються:
+- Поточні вбудовані провайдери в покритті:
   - `openai`
   - `google`
 - Необов’язкове звуження:
   - `OPENCLAW_LIVE_IMAGE_GENERATION_PROVIDERS="openai,google"`
   - `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"`
-- Необов’язкова поведінка автентифікації:
-  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію зі сховища профілів і ігнорувати перевизначення лише через env
+- Необов’язкова поведінка auth:
+  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб примусово використовувати auth зі сховища профілів і ігнорувати перевизначення лише через env
 
-## Music generation live
+## 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`
-- Охоплення:
-  - Перевіряє спільний шлях вбудованих провайдерів генерації музики
+- Обсяг:
+  - Перевіряє спільний шлях вбудованого провайдера генерації музики
   - Наразі охоплює Google і MiniMax
-  - Завантажує env-змінні провайдерів із вашої оболонки входу (`~/.profile`) перед перевіркою
-  - Типово використовує live/env API-ключі раніше за збережені профілі автентифікації, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні облікові дані оболонки
-  - Пропускає провайдерів без придатної автентифікації/профілю/моделі
-  - Запускає обидва оголошені runtime-режими, коли вони доступні:
-    - `generate` з вхідними даними лише через prompt
+  - Завантажує env vars провайдера з вашої оболонки входу (`~/.profile`) перед перевіркою
+  - За замовчуванням використовує live/env API-ключі раніше за збережені профілі auth, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні облікові дані оболонки
+  - Пропускає провайдерів без придатних auth/profile/model
+  - Запускає обидва оголошені runtime режими, коли вони доступні:
+    - `generate` з вхідними даними лише prompt
     - `edit`, коли провайдер оголошує `capabilities.edit.enabled`
-  - Поточне покриття спільної lane:
+  - Поточне покриття спільної ланки:
     - `google`: `generate`, `edit`
     - `minimax`: `generate`
-    - `comfy`: окремий live-файл Comfy, не цей спільний sweep
+    - `comfy`: окремий live-файл Comfy, а не ця спільна перевірка
 - Необов’язкове звуження:
   - `OPENCLAW_LIVE_MUSIC_GENERATION_PROVIDERS="google,minimax"`
   - `OPENCLAW_LIVE_MUSIC_GENERATION_MODELS="google/lyria-3-clip-preview,minimax/music-2.5+"`
-- Необов’язкова поведінка автентифікації:
-  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію зі сховища профілів і ігнорувати перевизначення лише через env
+- Необов’язкова поведінка auth:
+  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб примусово використовувати auth зі сховища профілів і ігнорувати перевизначення лише через env
 
-## Video generation live
+## 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`
-- Охоплення:
-  - Перевіряє спільний шлях вбудованих провайдерів генерації відео
-  - Завантажує env-змінні провайдерів із вашої оболонки входу (`~/.profile`) перед перевіркою
-  - Типово використовує live/env API-ключі раніше за збережені профілі автентифікації, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні облікові дані оболонки
-  - Пропускає провайдерів без придатної автентифікації/профілю/моделі
-  - Запускає обидва оголошені runtime-режими, коли вони доступні:
-    - `generate` з вхідними даними лише через prompt
-    - `imageToVideo`, коли провайдер оголошує `capabilities.imageToVideo.enabled` і вибраний провайдер/модель приймає локальні вхідні дані зображень на основі buffer у спільному sweep
-    - `videoToVideo`, коли провайдер оголошує `capabilities.videoToVideo.enabled` і вибраний провайдер/модель приймає локальні вхідні дані відео на основі buffer у спільному sweep
-  - Поточні оголошені, але пропущені провайдери `imageToVideo` у спільному sweep:
-    - `vydra`, тому що вбудований `veo3` — лише текстовий, а вбудований `kling` вимагає віддалений URL зображення
-  - Специфічне для провайдера покриття Vydra:
+- Обсяг:
+  - Перевіряє спільний шлях вбудованого провайдера генерації відео
+  - Завантажує env vars провайдера з вашої оболонки входу (`~/.profile`) перед перевіркою
+  - За замовчуванням використовує live/env API-ключі раніше за збережені профілі auth, щоб застарілі тестові ключі в `auth-profiles.json` не маскували реальні облікові дані оболонки
+  - Пропускає провайдерів без придатних auth/profile/model
+  - Запускає обидва оголошені runtime режими, коли вони доступні:
+    - `generate` з вхідними даними лише prompt
+    - `imageToVideo`, коли провайдер оголошує `capabilities.imageToVideo.enabled` і вибраний провайдер/модель приймає локальний image input на основі buffer у спільній перевірці
+    - `videoToVideo`, коли провайдер оголошує `capabilities.videoToVideo.enabled` і вибраний провайдер/модель приймає локальний video input на основі buffer у спільній перевірці
+  - Поточні провайдери `imageToVideo`, оголошені, але пропущені у спільній перевірці:
+    - `vydra`, тому що вбудований `veo3` підтримує лише текст, а вбудований `kling` вимагає віддалений 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 віддаленого URL зображення
+    - цей файл запускає `veo3` text-to-video, а також ланку `kling`, яка за замовчуванням використовує фікстуру віддаленого URL зображення
   - Поточне live-покриття `videoToVideo`:
     - лише `runway`, коли вибрана модель — `runway/gen4_aleph`
-  - Поточні оголошені, але пропущені провайдери `videoToVideo` у спільному sweep:
-    - `alibaba`, `qwen`, `xai`, тому що ці шляхи наразі вимагають віддалених reference URL `http(s)` / MP4
-    - `google`, тому що поточна спільна lane Gemini/Veo використовує локальні вхідні дані на основі buffer, а цей шлях не приймається у спільному sweep
-    - `openai`, тому що поточна спільна lane не гарантує доступ до video inpaint/remix, специфічного для org
+  - Поточні провайдери `videoToVideo`, оголошені, але пропущені у спільній перевірці:
+    - `alibaba`, `qwen`, `xai`, тому що ці шляхи наразі вимагають віддалені reference URLs `http(s)` / MP4
+    - `google`, тому що поточна спільна ланка Gemini/Veo використовує локальний input на основі buffer, а цей шлях не приймається в спільній перевірці
+    - `openai`, тому що поточна спільна ланка не гарантує 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"`
-- Необов’язкова поведінка автентифікації:
-  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб примусово використовувати автентифікацію зі сховища профілів і ігнорувати перевизначення лише через env
+- Необов’язкова поведінка auth:
+  - `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб примусово використовувати auth зі сховища профілів і ігнорувати перевизначення лише через env
 
-## Media live harness
+## Harness для live-медіа
 
 - Команда: `pnpm test:live:media`
 - Призначення:
-  - Запускає спільні live-набори для зображень, музики та відео через один native entrypoint репозиторію
-  - Автоматично завантажує відсутні env-змінні провайдерів із `~/.profile`
-  - Типово автоматично звужує кожен набір до провайдерів, які наразі мають придатну автентифікацію
+  - Запускає спільні live-набори image, music і video через одну нативну для репозиторію точку входу
+  - Автоматично завантажує відсутні env vars провайдера з `~/.profile`
+  - За замовчуванням автоматично звужує кожен набір до провайдерів, які наразі мають придатну auth
   - Повторно використовує `scripts/test-live.mjs`, тому поведінка heartbeat і quiet-mode залишається узгодженою
 - Приклади:
   - `pnpm test:live:media`
@@ -600,125 +600,128 @@ Live-тести знаходять облікові дані так само, я
   - `pnpm test:live:media video --video-providers openai,runway --all-providers`
   - `pnpm test:live:media music --quiet`
 
-## Виконавці Docker (необов’язкові перевірки «працює в Linux»)
+## 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`), монтуючи ваш локальний каталог конфігурації та 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-моделей: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл з ключами профілів усередині Docker image репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують ваш локальний каталог config і workspace (та підвантажують `~/.profile`, якщо його змонтовано). Відповідні локальні точки входу: `test:live:models-profiles` і `test:live:gateway-profiles`.
+- Docker-раннери live за замовчуванням використовують менший smoke-ліміт, щоб повна 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-змінні, коли
-  вам явно потрібне ширше вичерпне сканування.
-- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, а потім повторно використовує його для двох Docker-lane live.
-- Виконавці container smoke: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` і `test:docker:plugins` запускають один або кілька реальних контейнерів і перевіряють integration-шляхи вищого рівня.
+  `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env vars, коли
+  вам явно потрібне більше, повне сканування.
+- `test:docker:all` один раз збирає Docker image для live через `test:docker:live-build`, а потім повторно використовує його для двох Docker-ланок live.
+- Контейнерні smoke-раннери: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:gateway-network`, `test:docker:mcp-channels` і `test:docker:plugins` піднімають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня.
 
-Виконавці Docker для live-model також bind-mount лише потрібні домашні каталоги автентифікації CLI (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у домашню теку контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени, не змінюючи сховище автентифікації на хості:
+Docker-раннери live-моделей також bind-mount лише потрібні каталоги auth для CLI (або всі підтримувані, якщо запуск не звужений), а потім копіюють їх до домашнього каталогу контейнера перед запуском, щоб OAuth зовнішніх CLI міг оновлювати токени без зміни сховища auth на хості:
 
 - Прямі моделі: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`)
-- Smoke ACP bind: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-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`)
-- Open WebUI live smoke: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`)
-- Wizard онбордингу (TTY, повне scaffold): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`)
+- Live smoke Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-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 (ініціалізований Gateway + stdio bridge + raw Claude notification-frame smoke): `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 (ініціалізований Gateway + stdio bridge + raw smoke notification-frame Claude): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`)
+- Plugins (smoke встановлення + псевдонім `/plugin` + семантика перезапуску пакета Claude): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`)
 
-Виконавці Docker для live-model також bind-mount поточний checkout лише для читання і
-розгортають його в тимчасовий workdir усередині контейнера. Це зберігає runtime-образ
-компактним і водночас дозволяє запускати Vitest точно проти вашого локального source/config.
-Етап розгортання пропускає великі локальні кеші та результати збирання застосунків, такі як
-`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` і локальні для застосунків каталоги
-`.build` або виводу Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання
+Docker-раннери live-моделей також bind-mount поточний checkout лише для читання і
+розгортають його у тимчасовий workdir всередині контейнера. Це зберігає runtime
+image компактним, але все одно дозволяє запускати Vitest точно на вашому
+локальному source/config.
+Під час розгортання пропускаються великі локальні кеші й результати збірки застосунків, як-от
+`.pnpm-store`, `.worktrees`, `__openclaw_vitest__` і локальні каталоги виводу `.build` або
+Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання
 артефактів, специфічних для машини.
-Вони також установлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб live-перевірки gateway не запускали
-реальні worker каналів Telegram/Discord тощо всередині контейнера.
+Вони також встановлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб gateway live probes не запускали
+реальні workers каналів Telegram/Discord тощо всередині контейнера.
 `test:docker:live-models` усе ще запускає `pnpm test:live`, тому також передавайте
-`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити live-покриття gateway у цій Docker-lane.
-`test:docker:openwebui` — це smoke сумісності вищого рівня: він запускає контейнер
-gateway OpenClaw з увімкненими OpenAI-сумісними HTTP endpoint, запускає прив’язаний контейнер Open WebUI проти
-цього gateway, виконує вхід через Open WebUI, перевіряє, що `/api/models` показує `openclaw/default`, а потім надсилає
-реальний chat-запит через проксі Open WebUI `/api/chat/completions`.
-Перший запуск може бути помітно повільнішим, тому що Docker може знадобитися витягнути
-образ Open WebUI, а самому Open WebUI — завершити власне холодне початкове налаштування.
-Ця lane очікує придатний ключ live-моделі, а `OPENCLAW_PROFILE_FILE`
-(типово `~/.profile`) — основний спосіб надати його в Docker-запусках.
+`OPENCLAW_LIVE_GATEWAY_*`, коли вам потрібно звузити або виключити покриття gateway
+live з цієї Docker-ланки.
+`test:docker:openwebui` — це compatibility smoke вищого рівня: він запускає
+контейнер gateway OpenClaw з увімкненими HTTP endpoints, сумісними з OpenAI,
+запускає контейнер Open WebUI із зафіксованою версією проти цього gateway, виконує вхід через
+Open WebUI, перевіряє, що `/api/models` показує `openclaw/default`, а потім надсилає
+реальний chat-запит через проксі `/api/chat/completions` Open WebUI.
+Перший запуск може бути помітно повільнішим, оскільки Docker може знадобитися завантажити
+image Open WebUI, а самому Open WebUI — завершити власне cold-start налаштування.
+Ця ланка очікує наявність придатного ключа live-моделі, а `OPENCLAW_PROFILE_FILE`
+(`~/.profile` за замовчуванням) — основний спосіб надати його в Dockerized-запусках.
 Успішні запуски виводять невеликий JSON payload на кшталт `{ "ok": true, "model":
 "openclaw/default", ... }`.
 `test:docker:mcp-channels` навмисно детермінований і не потребує
-реального облікового запису Telegram, Discord або iMessage. Він запускає ініціалізований контейнер Gateway,
-запускає другий контейнер, який стартує `openclaw mcp serve`, а потім
+реального облікового запису Telegram, Discord або iMessage. Він піднімає
+контейнер Gateway з початковими даними, запускає другий контейнер, який викликає `openclaw mcp serve`, а потім
 перевіряє виявлення маршрутизованих розмов, читання transcript, метадані вкладень,
-поведінку черги live-подій, маршрутизацію вихідного надсилання, а також сповіщення каналів + дозволів у стилі Claude
-через реальний stdio MCP bridge. Перевірка сповіщень
-безпосередньо аналізує сирі stdio MCP-кадри, тож smoke перевіряє те, що міст
-справді випромінює, а не лише те, що випадково показує конкретний SDK клієнта.
+поведінку черги live-подій, маршрутизацію вихідних надсилань і сповіщення про канал +
+дозволи у стилі Claude через реальний stdio MCP bridge. Перевірка сповіщень
+безпосередньо аналізує сирі stdio MCP frames, тому smoke перевіряє те, що міст
+справді виводить, а не лише те, що випадково відображає конкретний client SDK.
 
-Ручний smoke звичайномовного thread ACP (не CI):
+Ручний smoke plain-language thread ACP (не для CI):
 
 - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel <discord-channel-id> ...`
-- Зберігайте цей скрипт для робочих процесів регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації thread ACP, тож не видаляйте його.
+- Зберігайте цей скрипт для робочих процесів регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації ACP thread, тому не видаляйте його.
 
-Корисні env-змінні:
+Корисні 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
-- Зовнішні каталоги/файли автентифікації CLI в `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються в `/home/node/...` перед стартом тестів
+- `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`
   - Типові файли: `~/.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`
-  - Можна вручну перевизначити через `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або список через кому, наприклад `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex`
+  - Звужені запуски провайдерів монтують лише потрібні каталоги/файли, виведені з `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_SKIP_DOCKER_BUILD=1`, щоб повторно використати наявний образ `openclaw:local-live` для повторних запусків без потреби перебудови
-- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб гарантувати, що облікові дані походять зі сховища профілів (а не з env)
-- `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку gateway показує для smoke Open WebUI
-- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити prompt перевірки nonce, який використовує smoke Open WebUI
-- `OPENWEBUI_IMAGE=...`, щоб перевизначити прив’язаний тег образу Open WebUI
+- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` для фільтрації провайдерів усередині контейнера
+- `OPENCLAW_SKIP_DOCKER_BUILD=1` для повторного використання наявного image `openclaw:local-live` у перезапусках, яким не потрібна перебудова
+- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб гарантувати, що creds беруться зі сховища профілів, а не з env
+- `OPENCLAW_OPENWEBUI_MODEL=...` щоб вибрати модель, яку gateway показує для smoke Open WebUI
+- `OPENCLAW_OPENWEBUI_PROMPT=...` щоб перевизначити nonce-check prompt, що використовується у smoke Open WebUI
+- `OPENWEBUI_IMAGE=...` щоб перевизначити зафіксований тег image Open WebUI
 
 ## Перевірка документації
 
 Після редагування документації запускайте перевірки docs: `pnpm check:docs`.
-Запускайте повну перевірку якірних посилань Mintlify, коли також потрібні перевірки заголовків у межах сторінки: `pnpm docs:check-links:anchors`.
+Запускайте повну перевірку anchor у Mintlify, коли вам також потрібні перевірки заголовків у межах сторінки: `pnpm docs:check-links:anchors`.
 
-## Офлайн-регресія (безпечна для CI)
+## Offline-регресія (безпечна для CI)
 
 Це регресії «реального конвеєра» без реальних провайдерів:
 
-- Виклик інструментів gateway (мок OpenAI, реальний цикл gateway + agent): `src/gateway/gateway.test.ts` (випадок: "runs a mock OpenAI tool call end-to-end via gateway agent loop")
-- Wizard gateway (WS `wizard.start`/`wizard.next`, запис config + примусове застосування auth): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config")
+- Tool calling gateway (імітація 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")
 
-## Оцінювання надійності агента (Skills)
+## Оцінювання надійності агентів (Skills)
 
-У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності агента»:
+У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності агентів»:
 
-- Мокований виклик інструментів через реальний цикл gateway + agent (`src/gateway/gateway.test.ts`).
-- Наскрізні потоки wizard, які перевіряють прив’язку сесій і ефекти конфігурації (`src/gateway/gateway.test.ts`).
+- Імітований tool-calling через реальний цикл gateway + agent (`src/gateway/gateway.test.ts`).
+- Наскрізні потоки майстра, які перевіряють wiring сесій і вплив на config (`src/gateway/gateway.test.ts`).
 
-Чого ще бракує для Skills (див. [Skills](/uk/tools/skills)):
+Чого все ще бракує для Skills (див. [Skills](/uk/tools/skills)):
 
-- **Прийняття рішень:** коли Skills перелічено в prompt, чи вибирає агент правильний skill (або уникає нерелевантних)?
-- **Дотримання вимог:** чи читає агент `SKILL.md` перед використанням і чи дотримується потрібних кроків/аргументів?
-- **Контракти робочого процесу:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сесій і межі sandbox.
+- **Прийняття рішень:** коли Skills перелічені в prompt, чи вибирає агент правильний Skill (або уникає нерелевантних)?
+- **Дотримання вимог:** чи читає агент `SKILL.md` перед використанням і чи виконує потрібні кроки/args?
+- **Контракти робочих процесів:** багатокрокові сценарії, які перевіряють порядок tool calls, перенесення історії сесії та межі sandbox.
 
-Майбутні оцінювання насамперед мають залишатися детермінованими:
+Майбутні оцінювання мають залишатися насамперед детермінованими:
 
-- Виконавець сценаріїв із mock-провайдерами для перевірки викликів інструментів + їхнього порядку, читання skill-файлів і прив’язки сесій.
-- Невеликий набір сценаріїв, зосереджених на skills (використати чи уникнути, gating, prompt injection).
-- Необов’язкові live-оцінювання (за явного ввімкнення, із захистом через env) лише після того, як буде готовий набір, безпечний для CI.
+- Раннер сценаріїв із mock-провайдерами для перевірки tool calls + їх порядку, читання skill-файлів і wiring сесій.
+- Невеликий набір сценаріїв, орієнтованих на Skills (використовувати чи уникати, gating, prompt injection).
+- Необов’язкові live-оцінювання (opt-in, із керуванням через env) лише після того, як буде готовий безпечний для CI набір.
 
 ## Контрактні тести (форма plugin і channel)
 
 Контрактні тести перевіряють, що кожен зареєстрований plugin і channel відповідає своєму
-контракту інтерфейсу. Вони перебирають усі виявлені plugins і запускають набір перевірок
-форми та поведінки. Типова unit-lane `pnpm test` навмисно
-пропускає ці спільні seam- і smoke-файли; запускайте контрактні команди явно,
-коли торкаєтеся спільних поверхонь channel або provider.
+контракту інтерфейсу. Вони перебирають усі виявлені plugins і запускають набір
+перевірок форми та поведінки. Типова unit-ланка `pnpm test` навмисно
+пропускає ці спільні seam- і smoke-файли; запускайте контрактні команди окремо,
+коли торкаєтесь спільних поверхонь channel або provider.
 
 ### Команди
 
@@ -731,52 +734,52 @@ gateway OpenClaw з увімкненими OpenAI-сумісними HTTP endpoi
 Розташовані в `src/channels/plugins/contracts/*.contract.test.ts`:
 
 - **plugin** - Базова форма plugin (id, name, capabilities)
-- **setup** - Контракт wizard налаштування
+- **setup** - Контракт майстра налаштування
 - **session-binding** - Поведінка прив’язки сесії
 - **outbound-payload** - Структура payload повідомлення
 - **inbound** - Обробка вхідних повідомлень
 - **actions** - Обробники дій channel
 - **threading** - Обробка ID thread
-- **directory** - API каталогу/списку учасників
-- **group-policy** - Застосування політики груп
+- **directory** - API directory/roster
+- **group-policy** - Застосування group policy
 
-### Контракти стану provider
+### Контракти статусу provider
 
 Розташовані в `src/plugins/contracts/*.contract.test.ts`.
 
-- **status** - Перевірки стану channel
+- **status** - Перевірки status channel
 - **registry** - Форма реєстру plugin
 
 ### Контракти provider
 
 Розташовані в `src/plugins/contracts/*.contract.test.ts`:
 
-- **auth** - Контракт потоку автентифікації
-- **auth-choice** - Вибір/добір автентифікації
+- **auth** - Контракт потоку auth
+- **auth-choice** - Вибір/добір auth
 - **catalog** - API каталогу моделей
 - **discovery** - Виявлення plugin
 - **loader** - Завантаження plugin
 - **runtime** - Runtime provider
 - **shape** - Форма/інтерфейс plugin
-- **wizard** - Wizard налаштування
+- **wizard** - Майстер налаштування
 
 ### Коли запускати
 
-- Після зміни export або subpath у plugin-sdk
+- Після змін exports або subpaths у plugin-sdk
 - Після додавання або зміни plugin channel чи provider
-- Після рефакторингу реєстрації або виявлення plugin
+- Після рефакторингу реєстрації plugin або механізму виявлення
 
 Контрактні тести запускаються в CI і не потребують реальних API-ключів.
 
-## Додавання регресій (рекомендації)
+## Додавання регресійних тестів (рекомендації)
 
-Коли ви виправляєте проблему провайдера/моделі, виявлену в live:
+Коли ви виправляєте проблему provider/model, виявлену в live:
 
-- Якщо можливо, додайте безпечну для CI регресію (mock/stub provider або захопіть точну трансформацію форми запиту)
-- Якщо проблема за своєю природою лише для live (rate limits, політики автентифікації), залишайте live-тест вузьким і за явного ввімкнення через env-змінні
-- Намагайтеся націлюватися на найменший шар, який ловить помилку:
-  - помилка перетворення/повторення запиту provider → тест direct models
-  - помилка конвеєра gateway session/history/tool → gateway live smoke або безпечний для CI gateway mock test
+- За можливості додайте безпечну для CI регресію (імітація/stub провайдера або захоплення точної трансформації форми запиту)
+- Якщо проблема за своєю природою лише live (rate limits, політики auth), залишайте live-тест вузьким і opt-in через env vars
+- Віддавайте перевагу найменшому рівню, який ловить помилку:
+  - помилка конвертації/повторення запиту provider → тест прямих моделей
+  - помилка конвеєра gateway session/history/tool → gateway live smoke або безпечний для CI mock-тест gateway
 - Запобіжник обходу SecretRef:
-  - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить по одній вибірковій цілі для кожного класу SecretRef з метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id сегментів обходу відхиляються.
-  - Якщо ви додаєте нову родину цілей SecretRef з `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно завершується невдало для некласифікованих target id, щоб нові класи не можна було тихо пропустити.
+  - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль для кожного класу SecretRef з метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec ids сегментів обходу відхиляються.
+  - Якщо ви додаєте нове сімейство цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно завершується невдачею на некласифікованих target ids, щоб нові класи не можна було пропустити непомітно.