chore(i18n): refresh uk translations

docs/uk/ci.md

@@ -1,27 +1,27 @@
 ---
 read_when:
     - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося.
-    - Ви налагоджуєте збої в перевірках GitHub Actions.
-summary: Граф завдань CI, обмежувачі охоплення та локальні еквіваленти команд
-title: конвеєр CI
+    - Ви налагоджуєте збої перевірок GitHub Actions.
+summary: Граф завдань CI, шлюзи області дії та локальні еквіваленти команд
+title: пайплайн CI
 x-i18n:
-    generated_at: "2026-04-24T05:03:58Z"
+    generated_at: "2026-04-24T07:42:13Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 8e24efec145ff144b007e248ef0f9c56287619eb9af204d45d49984909a6136b
+    source_hash: 489ac05725a316b25f56f7f754d6a8652abbd60481fbe6e692572b81581fe405
     source_path: ci.md
     workflow: 15
 ---
 
-CI запускається для кожного push до `main` і кожного pull request. Він використовує розумне обмеження охоплення, щоб пропускати дорогі завдання, коли змінено лише не пов’язані ділянки.
+CI запускається для кожного push у `main` і кожного pull request. Він використовує розумне визначення області дії, щоб пропускати дорогі завдання, коли змінено лише не пов’язані ділянки.
 
-QA Lab має окремі доріжки CI поза основним workflow із розумним обмеженням охоплення. Workflow `Parity gate` запускається для відповідних змін у PR і через ручний dispatch; він збирає приватне середовище виконання QA та порівнює agentic-пакети mock GPT-5.4 і Opus 4.6. Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і через ручний dispatch; він розгалужує mock parity gate, live-доріжку Matrix і live-доріжку Telegram як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а доріжка Telegram використовує оренди Convex. `OpenClaw Release Checks` також запускає ті самі доріжки QA Lab перед затвердженням релізу.
+QA Lab має окремі доріжки CI поза основним workflow з розумною областю дії. Workflow `Parity gate` запускається для відповідних змін у PR і при ручному запуску; він збирає приватне середовище виконання QA і порівнює агентні набори mock GPT-5.4 та Opus 4.6. Workflow `QA-Lab - All Lanes` запускається щоночі для `main` і при ручному запуску; він розгалужує mock parity gate, live доріжку Matrix і live доріжку Telegram як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а доріжка Telegram використовує оренди Convex. `OpenClaw Release Checks` також запускає ті самі доріжки QA Lab перед затвердженням релізу.
 
-Workflow `Duplicate PRs After Merge` — це ручний workflow для супроводу після злиття, призначений для очищення дублікатів. За замовчуванням він працює в режимі dry-run і закриває лише явно вказані PR, коли `apply=true`. Перед внесенням змін у GitHub він перевіряє, що злитий PR справді merged і що кожен дублікат має або спільну згадану issue, або перетин змінених hunk-ів.
+Workflow `Duplicate PRs After Merge` — це ручний workflow для супровідників для очищення дублікатів після злиття. За замовчуванням він працює в режимі dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перш ніж змінювати GitHub, він перевіряє, що злитий PR справді об’єднано, і що кожен дублікат має або спільне згадане issue, або перетин змінених фрагментів.
 
-Workflow `Docs Agent` — це Codex-доріжка супроводу, що запускається за подіями, щоб підтримувати наявну документацію узгодженою з нещодавно злитими змінами. Вона не має окремого запуску за розкладом: її може запустити успішний небоговий запуск push CI на `main`, а ручний dispatch може запускати її безпосередньо. Виклики через workflow-run пропускаються, якщо `main` уже просунувся далі або якщо інший непропущений запуск Docs Agent був створений протягом останньої години. Коли вона запускається, вона переглядає діапазон комітів від попереднього source SHA непропущеного Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни в main, накопичені з часу останнього проходу документації.
+Workflow `Docs Agent` — це керована подіями доріжка обслуговування Codex для підтримання наявної документації у відповідності до нещодавно внесених змін. У неї немає окремого запуску за розкладом: її може запустити успішний CI-запуск для небота після push у `main`, а також її можна запустити вручну. Виклики через workflow-run пропускаються, якщо `main` уже просунувся далі або якщо інший непропущений запуск Docs Agent був створений протягом останньої години. Під час виконання він переглядає діапазон комітів від SHA джерела попереднього непропущеного Docs Agent до поточного `main`, тому один щогодинний запуск може охопити всі зміни в main, накопичені з часу останнього проходу документації.
 
-Workflow `Test Performance Agent` — це Codex-доріжка супроводу для повільних тестів, що запускається за подіями. Вона не має окремого запуску за розкладом: її може запустити успішний небоговий запуск push CI на `main`, але вона пропускається, якщо інший виклик через workflow-run уже виконувався або виконується в цю UTC-добу. Ручний dispatch обходить це денне обмеження активності. Доріжка збирає згрупований звіт про продуктивність Vitest для повного набору тестів, дозволяє Codex вносити лише невеликі виправлення продуктивності тестів без втрати покриття замість широких рефакторингів, потім повторно запускає звіт для повного набору та відхиляє зміни, які зменшують кількість тестів, що проходять у базовому стані. Якщо в базовому стані є тести, що падають, Codex може виправляти лише очевидні збої, а звіт для повного набору після роботи агента має проходити, перш ніж щось буде закомічено. Коли `main` просувається до того, як бот устигне запушити зміни, доріжка робить rebase перевіреного патча, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі патчі пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму безпечну модель drop-sudo, що й docs agent.
+Workflow `Test Performance Agent` — це керована подіями доріжка обслуговування Codex для повільних тестів. У нього немає окремого запуску за розкладом: його може запустити успішний CI-запуск для небота після push у `main`, але він пропускається, якщо інший виклик через workflow-run уже виконався або виконується цього дня за UTC. Ручний запуск обходить цю щоденну перевірку активності. Доріжка будує згрупований звіт про продуктивність Vitest для повного набору, дозволяє Codex робити лише невеликі виправлення продуктивності тестів без втрати покриття замість масштабних рефакторингів, потім повторно запускає звіт для повного набору і відхиляє зміни, які зменшують базову кількість тестів, що проходять. Якщо в базовому стані є тести, що падають, Codex може виправляти лише очевидні збої, а повний звіт після роботи агента має пройти до будь-якого коміту. Коли `main` просувається вперед до того, як push бота потрапляє в репозиторій, доріжка перебазовує перевірений патч, повторно запускає `pnpm check:changed` і повторює push; застарілі патчі з конфліктами пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму безпечну політику drop-sudo, що й агент документації.
 
 ```bash
 gh workflow run duplicate-after-merge.yml \
@@ -34,83 +34,83 @@ gh workflow run duplicate-after-merge.yml \
 
 | Завдання                         | Призначення                                                                                  | Коли запускається                    |
 | -------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------ |
-| `preflight`                      | Визначає зміни лише в docs, змінені області охоплення, змінені extensions і будує маніфест CI | Завжди для non-draft push і PR       |
-| `security-scm-fast`              | Виявлення приватних ключів і аудит workflow через `zizmor`                                   | Завжди для non-draft push і PR       |
-| `security-dependency-audit`      | Аудит production lockfile без залежностей щодо advisory npm                                  | Завжди для non-draft push і PR       |
-| `security-fast`                  | Обов’язковий агрегат для швидких завдань безпеки                                             | Завжди для non-draft push і PR       |
-| `build-artifacts`                | Збирає `dist/`, Control UI, перевірки built-artifact і повторно використовувані downstream artifacts | Зміни, релевантні для Node           |
-| `checks-fast-core`               | Швидкі Linux-доріжки коректності, як-от bundled/plugin-contract/protocol checks              | Зміни, релевантні для Node           |
-| `checks-fast-contracts-channels` | Шардовані перевірки channel contract зі стабільним агрегованим результатом                   | Зміни, релевантні для Node           |
-| `checks-node-extensions`         | Повні шарди тестів bundled-plugin для всього набору extensions                               | Зміни, релевантні для Node           |
-| `checks-node-core-test`          | Шарди core Node tests, за винятком доріжок channel, bundled, contract і extension            | Зміни, релевантні для Node           |
-| `extension-fast`                 | Точкові тести лише для змінених bundled plugins                                              | Pull request із змінами в extension  |
-| `check`                          | Шардований еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Зміни, релевантні для Node           |
-| `check-additional`               | Шарди архітектури, меж, guards поверхні extension, меж пакетів і gateway-watch               | Зміни, релевантні для Node           |
-| `build-smoke`                    | Smoke-тести built-CLI і smoke перевірка пам’яті під час запуску                              | Зміни, релевантні для Node           |
-| `checks`                         | Верифікатор для built-artifact channel tests плюс сумісність Node 22 лише для push           | Зміни, релевантні для Node           |
-| `check-docs`                     | Форматування docs, lint і перевірки на биті посилання                                        | Docs змінено                         |
-| `skills-python`                  | Ruff + pytest для Skills на базі Python                                                      | Зміни, релевантні для Python Skills  |
-| `checks-windows`                 | Специфічні для Windows тестові доріжки                                                       | Зміни, релевантні для Windows        |
-| `macos-node`                     | Доріжка тестів TypeScript на macOS з використанням спільних built artifacts                  | Зміни, релевантні для macOS          |
-| `macos-swift`                    | Swift lint, build і тести для застосунку macOS                                               | Зміни, релевантні для macOS          |
-| `android`                        | Android unit tests для обох flavor-ів плюс одна збірка debug APK                             | Зміни, релевантні для Android        |
-| `test-performance-agent`         | Щоденна Codex-оптимізація повільних тестів після довіреної активності                        | Успіх main CI або ручний dispatch    |
+| `preflight`                      | Виявлення змін лише в документації, змінених областей, змінених extensions і побудова CI-маніфесту | Завжди для push і PR не в режимі draft |
+| `security-scm-fast`              | Виявлення приватних ключів і аудит workflow через `zizmor`                                   | Завжди для push і PR не в режимі draft |
+| `security-dependency-audit`      | Аудит production lockfile без залежностей за advisory npm                                    | Завжди для push і PR не в режимі draft |
+| `security-fast`                  | Обов’язковий агрегатор для швидких завдань безпеки                                           | Завжди для push і PR не в режимі draft |
+| `build-artifacts`                | Збірка `dist/`, Control UI, перевірки зібраних артефактів і повторно використовуваних downstream-артефактів | Зміни, пов’язані з Node              |
+| `checks-fast-core`               | Швидкі Linux-доріжки коректності, такі як перевірки bundled/plugin-contract/protocol         | Зміни, пов’язані з Node              |
+| `checks-fast-contracts-channels` | Шардовані перевірки контрактів channel зі стабільним агрегованим результатом                 | Зміни, пов’язані з Node              |
+| `checks-node-extensions`         | Повні шарди тестів bundled-plugin для всього набору extension                                | Зміни, пов’язані з Node              |
+| `checks-node-core-test`          | Шарди тестів ядра Node, без доріжок channel, bundled, contract і extension                   | Зміни, пов’язані з Node              |
+| `extension-fast`                 | Сфокусовані тести лише для змінених bundled plugins                                          | Pull request зі змінами в extension  |
+| `check`                          | Шардований еквівалент основного локального шлюзу: production-типи, lint, guards, test types і strict smoke | Зміни, пов’язані з Node              |
+| `check-additional`               | Архітектурні перевірки, перевірки меж, guards поверхні extension, меж пакетів і шарди gateway-watch | Зміни, пов’язані з Node              |
+| `build-smoke`                    | Smoke-тести зібраного CLI і smoke перевірка стартової пам’яті                                | Зміни, пов’язані з Node              |
+| `checks`                         | Верифікатор для тестів channel на зібраних артефактах плюс сумісність Node 22 лише для push  | Зміни, пов’язані з Node              |
+| `check-docs`                     | Форматування документації, lint і перевірки зламаних посилань                                | Змінено документацію                 |
+| `skills-python`                  | Ruff + pytest для Skills на базі Python                                                      | Зміни, релевантні Python Skills      |
+| `checks-windows`                 | Специфічні для Windows тестові доріжки                                                       | Зміни, релевантні Windows            |
+| `macos-node`                     | Доріжка тестів TypeScript для macOS з використанням спільних зібраних артефактів             | Зміни, релевантні macOS              |
+| `macos-swift`                    | Lint, збірка і тести Swift для застосунку macOS                                              | Зміни, релевантні macOS              |
+| `android`                        | Юніт-тести Android для обох варіантів плюс одна збірка debug APK                             | Зміни, релевантні Android            |
+| `test-performance-agent`         | Щоденна оптимізація повільних тестів Codex після довіреної активності                        | Успішний main CI або ручний запуск   |
 
 ## Порядок Fail-Fast
 
 Завдання впорядковані так, щоб дешеві перевірки падали раніше, ніж запускаються дорогі:
 
-1. `preflight` вирішує, які доріжки взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
-2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` падають швидко, не чекаючи важчих завдань матриці artifacts і платформ.
-3. `build-artifacts` перекривається з швидкими Linux-доріжками, щоб downstream-споживачі могли стартувати, щойно буде готова спільна збірка.
-4. Після цього розгалужуються важчі платформні та runtime-доріжки: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, PR-only `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
+1. `preflight` визначає, які доріжки взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
+2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` падають швидко, не чекаючи важчих завдань із артефактами та платформенних матриць.
+3. `build-artifacts` перекривається з швидкими Linux-доріжками, щоб downstream-споживачі могли стартувати, щойно спільна збірка готова.
+4. Після цього розгалужуються важчі платформенні й runtime-доріжки: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, лише-PR `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
 
-Логіка охоплення міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`.
-Редагування workflow CI перевіряє граф Node CI плюс lint workflow, але саме по собі не змушує виконувати нативні збірки Windows, Android або macOS; ці платформні доріжки залишаються обмеженими змінами у вихідному коді відповідних платформ.
-Перевірки Windows Node обмежені Windows-специфічними wrappers для process/path, допоміжними засобами npm/pnpm/UI runner, конфігурацією package manager і поверхнями workflow CI, які запускають цю доріжку; не пов’язані зміни у source, plugin, install-smoke і зміни лише в tests залишаються на Linux Node-доріжках, щоб не резервувати Windows worker із 16 vCPU для покриття, яке вже перевіряється звичайними test shards.
-Окремий workflow `install-smoke` повторно використовує той самий скрипт охоплення через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. Pull request запускають швидкий шлях для поверхонь Docker/package, змін package/manifest bundled plugin і поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише в source bundled plugin, лише в tests і лише в docs не резервують Docker workers. Швидкий шлях один раз збирає образ root Dockerfile, перевіряє CLI, запускає container gateway-network e2e, перевіряє аргумент збірки bundled extension і запускає обмежений Docker profile bundled-plugin з тайм-аутом команди 120 секунд. Повний шлях зберігає покриття QR package install і installer Docker/update для нічних запусків за розкладом, ручних dispatch-ів, workflow-call перевірок релізу і pull request, які справді торкаються поверхонь installer/package/Docker. Push у `main`, включно з merge commits, не змушують повний шлях; коли логіка changed-scope вимагала б повного покриття для push, workflow залишає швидкий Docker smoke, а повний install smoke переносить на нічну або релізну валідацію. Повільний smoke для image-provider із глобальним встановленням Bun окремо обмежується через `run_bun_global_install_smoke`; він запускається за нічним розкладом і з workflow перевірок релізу, а ручні dispatch-и `install-smoke` можуть його ввімкнути, але pull request і push у `main` його не запускають. Тести QR і installer Docker зберігають власні Dockerfile, орієнтовані на встановлення. Локальний `test:docker:all` попередньо збирає один спільний live-test image і один спільний built-app image `scripts/e2e/Dockerfile`, а потім запускає live/E2E smoke-доріжки паралельно з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте типову паралельність основного пулу 8 через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а паралельність tail-pool, чутливого до provider, теж 8 — через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Локальний агрегат за замовчуванням перестає планувати нові доріжки пулу після першого збою, а кожна доріжка має тайм-аут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Повторно використовуваний workflow live/E2E відтворює шаблон спільного image, збираючи й публікуючи один Docker E2E image із тегом SHA в GHCR перед Docker matrix, а потім запускаючи matrix з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Запланований workflow live/E2E щодня запускає повний Docker suite для релізного шляху. Повна матриця bundled update/channel залишається ручною/full-suite, оскільки виконує повторні реальні проходи npm update і doctor repair.
+Логіка області дії міститься в `scripts/ci-changed-scope.mjs` і покривається юніт-тестами в `src/scripts/ci-changed-scope.test.ts`.
+Зміни в CI workflow перевіряють граф Node CI плюс lint workflow, але самі по собі не змушують запускати нативні збірки Windows, Android або macOS; ці платформенні доріжки й далі залишаються прив’язаними до змін у вихідному коді відповідної платформи.
+Перевірки Windows Node обмежуються специфічними для Windows обгортками process/path, допоміжними засобами npm/pnpm/UI runner, конфігурацією менеджера пакетів і поверхнями CI workflow, які виконують цю доріжку; не пов’язані зміни у вихідному коді, plugins, install-smoke і зміни лише в тестах залишаються на Linux Node-доріжках, щоб не резервувати Windows worker із 16 vCPU для покриття, яке вже перевіряється звичайними шардами тестів.
+Окремий workflow `install-smoke` повторно використовує той самий скрипт області дії через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. Pull request запускають швидкий шлях для поверхонь Docker/package, змін у package/manifest bundled plugins і поверхонь core plugin/channel/gateway/Plugin SDK, які використовують Docker smoke-завдання. Зміни лише у вихідному коді bundled plugins, зміни лише в тестах і зміни лише в документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений Docker-профіль bundled-plugin з тайм-аутом команди 120 секунд. Повний шлях зберігає покриття встановлення QR package і встановлювача Docker/update для нічних запусків за розкладом, ручних запусків, release checks через workflow-call і pull request, які справді зачіпають поверхні installer/package/Docker. Push у `main`, включно з merge-комітами, не примушують повний шлях; коли логіка changed-scope запитує повне покриття під час push, workflow залишає швидкий Docker smoke, а повний install smoke відкладає до нічної або релізної валідації. Повільний smoke глобального встановлення Bun image-provider окремо керується `run_bun_global_install_smoke`; він запускається за нічним розкладом і з workflow перевірок релізу, а ручні запуски `install-smoke` можуть явно його увімкнути, але pull request і push у `main` його не запускають. Тести QR і installer Docker зберігають власні Dockerfile, зосереджені на встановленні. Локальний `test:docker:all` попередньо збирає один спільний образ live-test і один спільний образ зібраного застосунку `scripts/e2e/Dockerfile`, а потім запускає доріжки live/E2E smoke паралельно з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте стандартний паралелізм основного пулу 8 через `OPENCLAW_DOCKER_ALL_PARALLELISM` і паралелізм tail-пулу 8, чутливого до провайдерів, через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Запуски доріжок за замовчуванням зсунуті на 2 секунди, щоб уникати локальних штормів створення в Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний агрегат за замовчуванням припиняє планувати нові pooled-доріжки після першого збою, а кожна доріжка має тайм-аут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Повторно використовуваний workflow live/E2E віддзеркалює шаблон спільного образу, збираючи й публікуючи один Docker E2E-образ GHCR із тегом SHA до запуску матриці Docker, а потім запускає матрицю з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Запланований workflow live/E2E щодня запускає повний Docker-набір релізного шляху. Повна матриця bundled update/channel залишається ручною/full-suite, бо виконує повторні реальні проходи npm update і doctor repair.
 
-Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний gate суворіше ставиться до архітектурних меж, ніж широке платформне охоплення CI: зміни у production core запускають typecheck prod core плюс core tests, зміни лише в tests core запускають лише typecheck/tests для test-коду core, зміни у production extension запускають typecheck prod extension плюс extension tests, а зміни лише в tests extension запускають лише typecheck/tests для test-коду extension. Зміни в публічному Plugin SDK або plugin-contract розширюють валідацію на extension, тому що extension залежать від цих контрактів core. Зміни лише в release metadata version bump запускають точкові перевірки version/config/root-dependency. Невідомі зміни root/config безпечно переводять виконання на всі доріжки.
+Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний шлюз суворіший щодо архітектурних меж, ніж широка платформенна область дії CI: зміни у production-коді ядра запускають typecheck core prod плюс тести ядра, зміни лише в тестах ядра запускають лише typecheck/tests core test, зміни у production-коді extension запускають typecheck extension prod плюс тести extension, а зміни лише в тестах extension запускають лише typecheck/tests extension test. Зміни в публічному Plugin SDK або plugin-contract розширюють валідацію на extension, бо extension залежать від цих контрактів ядра. Підвищення версії лише в метаданих релізу запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config для безпеки запускають усі доріжки.
 
-Для push матриця `checks` додає доріжку `compat-node22`, що запускається лише для push. Для pull request ця доріжка пропускається, і матриця зосереджується на звичайних test/channel-доріжках.
+Для push матриця `checks` додає доріжку `compat-node22`, яка запускається лише для push. Для pull request цю доріжку пропускають, і матриця залишається зосередженою на звичайних доріжках тестів/channel.
 
-Найповільніші сімейства Node tests розділені або збалансовані так, щоб кожне завдання залишалося невеликим без надмірного резервування runner-ів: channel contracts виконуються у трьох зважених shards, bundled plugin tests балансуються між шістьма worker-ами extension, малі core unit lanes об’єднані в пари, auto-reply працює у трьох збалансованих worker-ах замість шести крихітних worker-ів, а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media та різні plugin tests використовують свої окремі конфігурації Vitest замість спільного універсального plugin catch-all. Завдання shard для extension запускають групи конфігурацій plugin послідовно з одним worker-ом Vitest і більшим Node heap, щоб batch-і plugin з великим обсягом імпортів не перевантажували малі CI runner-и. Широка доріжка agents використовує спільний планувальник файлового паралелізму Vitest, оскільки в ній домінують імпорти/планування, а не один повільний test file. `runtime-config` запускається разом із shard `infra core-runtime`, щоб спільний shard runtime не замикався на хвості. `check-additional` тримає compile/canary-роботи для меж пакетів разом і відокремлює архітектуру топології runtime від покриття gateway watch; shard boundary guard виконує свої малі незалежні guards паралельно всередині одного завдання. Gateway watch, channel tests і shard support-boundary core виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрано, зберігаючи свої старі назви check як легковагі verifier-завдання й водночас уникаючи двох додаткових Blacksmith worker-ів і другої черги споживачів artifacts.
+Найповільніші сімейства тестів Node розділені або збалансовані так, щоб кожне завдання залишалося невеликим без надмірного резервування runner-ів: контракти channel запускаються у трьох зважених шардах, тести bundled plugin балансуються між шістьма worker-ами extension, невеликі core unit-доріжки об’єднані в пари, auto-reply виконується у трьох збалансованих worker-ах замість шести дрібних worker-ів, а агентні конфігурації gateway/plugin розподіляються між наявними source-only агентними Node-завданнями замість очікування на зібрані артефакти. Широкі тести browser, QA, media і різних plugins використовують свої окремі конфігурації Vitest замість спільної універсальної конфігурації plugin. Завдання шард extension запускають групи конфігурацій plugin послідовно з одним worker-ом Vitest і більшим heap Node, щоб пакети plugin з великим імпортом не перевантажували невеликі CI runner-и. Широка доріжка agents використовує спільний file-parallel scheduler Vitest, тому що в ній домінують імпорт/планування, а не один повільний тестовий файл. `runtime-config` запускається разом із шардом infra core-runtime, щоб спільний runtime-шард не залишався найповільнішим. `check-additional` тримає compile/canary-роботи меж пакетів разом і відокремлює архітектуру topology runtime від покриття gateway watch; шард boundary guard запускає свої невеликі незалежні guards паралельно в межах одного завдання. Gateway watch, тести channel і core support-boundary shard виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі імена перевірок як легковагі завдання-верифікатори, водночас уникаючи двох додаткових Blacksmith worker-ів і другої черги споживачів артефактів.
 
-Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Flavor third-party не має окремого набору source або manifest; його доріжка unit tests усе одно компілює цей flavor з прапорцями BuildConfig для SMS/call-log, водночас уникаючи дубльованого завдання пакування debug APK на кожному push, релевантному для Android.
-`extension-fast` є лише для PR, тому що push-запуски вже виконують повні shard-и bundled plugin. Це зберігає швидкий зворотний зв’язок щодо змінених plugin для рев’ю, не резервуючи додатковий Blacksmith worker на `main` для покриття, яке вже є в `checks-node-extensions`.
+Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Варіант third-party не має окремого source set або manifest; його доріжка юніт-тестів усе одно компілює цей варіант із прапорцями BuildConfig для SMS/call-log, водночас уникаючи дубльованого завдання пакування debug APK для кожного push, релевантного Android.
+`extension-fast` доступний лише для PR, оскільки push-запуски вже виконують повні шарди bundled plugin. Це зберігає швидкий зворотний зв’язок для змінених plugins під час review, не резервуючи додатковий Blacksmith worker у `main` для покриття, яке вже є в `checks-node-extensions`.
 
-GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Сприймайте це як шум CI, якщо лише найновіший запуск для того самого ref також не падає. Агреговані shard checks використовують `!cancelled() && always()`, тож вони все ще повідомляють про звичайні збої shard-ів, але не стають у чергу після того, як увесь workflow уже було замінено.
-Ключ concurrency у CI має версіонування (`CI-v7-*`), щоб zombie на боці GitHub у старій групі черги не міг безстроково блокувати новіші запуски main.
+GitHub може позначати замінені новішими завдання як `cancelled`, коли новіший push потрапляє в той самий ref PR або `main`. Сприймайте це як шум CI, якщо тільки найновіший запуск для того самого ref також не падає. Агреговані shard-перевірки використовують `!cancelled() && always()`, тому вони все одно повідомляють про звичайні збої shard-ів, але не стають у чергу після того, як увесь workflow уже був замінений новішим.
+Ключ паралельності CI має версіонування (`CI-v7-*`), щоб zombie-процес на боці GitHub у старій групі черги не міг безстроково блокувати новіші запуски main.
 
 ## Runner-и
 
-| Runner                           | Завдання                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
-| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ubuntu-24.04`                   | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled checks, шардовані перевірки channel contract, shard-и `check`, крім lint, shard-и та агрегати `check-additional`, aggregate verifier-и Node tests, перевірки docs, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла ставати в чергу раніше |
-| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, shard-и Linux Node tests, shard-и bundled plugin tests, `android`                                                                                                                                                                                                                                                                                                                                                                     |
-| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint`, який залишається достатньо чутливим до CPU, так що 8 vCPU коштували більше, ніж дали вигоди; Docker builds для install-smoke, де час очікування в черзі для 32 vCPU коштував більше, ніж давав вигоди                                                                                                                                                                                                                                                |
-| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
-| `blacksmith-6vcpu-macos-latest`  | `macos-node` у `openclaw/openclaw`; fork-и повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                             |
-| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; fork-и повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                            |
+| Runner                           | Завдання                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `ubuntu-24.04`                   | `preflight`, швидкі завдання безпеки й агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки контрактів channel, шарди `check`, крім lint, шарди й агрегати `check-additional`, агреговані верифікатори тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла ставати в чергу раніше |
+| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів bundled plugin, `android`                                                                                                                                                                                                                                                                                                                                                                       |
+| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint`, який і далі достатньо чутливий до CPU, тож 8 vCPU коштували дорожче, ніж дали користі; Docker-збірки install-smoke, де вартість часу очікування в черзі для 32 vCPU була вищою, ніж користь                                                                                                                                                                                                                                                         |
+| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| `blacksmith-6vcpu-macos-latest`  | `macos-node` у `openclaw/openclaw`; fork-репозиторії повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                   |
+| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; fork-репозиторії повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                  |
 
 ## Локальні еквіваленти
 
 ```bash
 pnpm changed:lanes   # переглянути локальний класифікатор changed-lane для origin/main...HEAD
-pnpm check:changed   # розумний локальний gate: changed typecheck/lint/tests за boundary lane
-pnpm check          # швидкий локальний gate: production tsgo + шардований lint + паралельні швидкі guards
+pnpm check:changed   # розумний локальний шлюз: змінені typecheck/lint/tests за доріжкою меж
+pnpm check          # швидкий локальний шлюз: production tsgo + шардований lint + паралельні швидкі guards
 pnpm check:test-types
-pnpm check:timed    # той самий gate з таймінгами для кожного етапу
+pnpm check:timed    # той самий шлюз із таймінгами для кожного етапу
 pnpm build:strict-smoke
 pnpm check:architecture
 pnpm test:gateway:watch-regression
 pnpm test           # тести vitest
 pnpm test:channels
 pnpm test:contracts:channels
-pnpm check:docs     # форматування docs + lint + биті посилання
-pnpm build          # збірка dist, коли мають значення доріжки CI artifact/build-smoke
-node scripts/ci-run-timings.mjs <run-id>      # зведення wall time, queue time і найповільніших завдань
-node scripts/ci-run-timings.mjs --recent 10   # порівняння недавніх успішних запусків main CI
+pnpm check:docs     # форматування документації + lint + зламані посилання
+pnpm build          # зібрати dist, коли важливі доріжки CI artifact/build-smoke
+node scripts/ci-run-timings.mjs <run-id>      # підсумувати загальний час, час у черзі та найповільніші завдання
+node scripts/ci-run-timings.mjs --recent 10   # порівняти нещодавні успішні main CI-запуски
 pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json
 pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json
 ```

docs/uk/gateway/troubleshooting.md

@@ -1,26 +1,26 @@
 ---
 read_when:
-    - Центр усунення проблем направив вас сюди для глибшої діагностики
-    - Вам потрібні стабільні розділи runbook на основі симптомів із точними командами
-summary: Докладний runbook з усунення проблем для gateway, каналів, автоматизації, Node і браузера
-title: Усунення проблем
+    - Центр усунення несправностей направив вас сюди для глибшої діагностики
+    - Вам потрібні стабільні розділи посібника з усунення несправностей, побудовані за симптомами, з точними командами
+summary: Поглиблений посібник з усунення несправностей для Gateway, каналів, автоматизації, Node і браузера
+title: Усунення несправностей
 x-i18n:
-    generated_at: "2026-04-24T03:44:54Z"
+    generated_at: "2026-04-24T07:42:15Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 32c4cbbbe8b1cd5eaca34503f4a363d3fa2650e491f83455958eb5725f9d50c5
+    source_hash: 20066bdab03f05304b3a620fbadc38e4dc74b740da151c58673dcf5196e5f1e1
     source_path: gateway/troubleshooting.md
     workflow: 15
 ---
 
-# Усунення проблем Gateway
+# Усунення несправностей Gateway
 
-Ця сторінка — докладний runbook.
-Почніть із [/help/troubleshooting](/uk/help/troubleshooting), якщо спершу хочете швидкий потік triage.
+Ця сторінка — поглиблений посібник з усунення несправностей.
+Почніть із [/help/troubleshooting](/uk/help/troubleshooting), якщо спочатку хочете пройти швидкий потік тріажу.
 
-## Послідовність команд
+## Сходинки команд
 
-Запустіть спочатку їх, у такому порядку:
+Спочатку виконайте ці команди в такому порядку:
 
 ```bash
 openclaw status
@@ -30,14 +30,14 @@ openclaw doctor
 openclaw channels status --probe
 ```
 
-Очікувані ознаки здорового стану:
+Очікувані ознаки справного стану:
 
 - `openclaw gateway status` показує `Runtime: running`, `Connectivity probe: ok` і рядок `Capability: ...`.
-- `openclaw doctor` не повідомляє про блокувальні проблеми config/сервісу.
+- `openclaw doctor` не повідомляє про блокувальні проблеми конфігурації/сервісу.
 - `openclaw channels status --probe` показує живий стан транспорту для кожного облікового запису і,
   де це підтримується, результати probe/audit, як-от `works` або `audit ok`.
 
-## Anthropic 429: extra usage required for long context
+## Додаткове використання Anthropic 429 потрібне для довгого контексту
 
 Використовуйте це, коли журнали/помилки містять:
 `HTTP 429: rate_limit_error: Extra usage is required for long context requests`.
@@ -48,17 +48,17 @@ openclaw models status
 openclaw config get agents.defaults.models
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
 - Вибрана модель Anthropic Opus/Sonnet має `params.context1m: true`.
-- Поточні облікові дані Anthropic не мають права на long-context usage.
-- Запити завершуються помилкою лише в довгих сесіях/запусках моделей, яким потрібен шлях 1M beta.
+- Поточні облікові дані Anthropic не мають права на використання довгого контексту.
+- Запити падають лише під час довгих сесій/запусків моделі, яким потрібен бета-шлях 1M.
 
 Варіанти виправлення:
 
-1. Вимкніть `context1m` для цієї моделі, щоб перейти до звичайного вікна контексту.
-2. Використайте облікові дані Anthropic, які мають право на long-context requests, або перейдіть на API key Anthropic.
-3. Налаштуйте fallback models, щоб запуски тривали, коли Anthropic відхиляє long-context requests.
+1. Вимкніть `context1m` для цієї моделі, щоб повернутися до звичайного вікна контексту.
+2. Використайте облікові дані Anthropic, які мають право на запити з довгим контекстом, або перейдіть на Anthropic API key.
+3. Налаштуйте резервні моделі, щоб запуски тривали, коли Anthropic відхиляє запити з довгим контекстом.
 
 Пов’язане:
 
@@ -66,13 +66,13 @@ openclaw config get agents.defaults.models
 - [/reference/token-use](/uk/reference/token-use)
 - [/help/faq-first-run#why-am-i-seeing-http-429-ratelimiterror-from-anthropic](/uk/help/faq-first-run#why-am-i-seeing-http-429-ratelimiterror-from-anthropic)
 
-## Локальний OpenAI-compatible backend проходить прямі probes, але запуски агента завершуються помилкою
+## Локальний OpenAI-сумісний backend проходить прямі probe, але запуски агентів падають
 
 Використовуйте це, коли:
 
 - `curl ... /v1/models` працює
 - малі прямі виклики `/v1/chat/completions` працюють
-- запуски моделей OpenClaw завершуються помилкою лише на звичайних ходах агента
+- запуски моделей OpenClaw падають лише під час звичайних ходів агента
 
 ```bash
 curl http://127.0.0.1:1234/v1/models
@@ -83,35 +83,36 @@ openclaw infer model run --model <provider/model> --prompt "hi" --json
 openclaw logs --follow
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
-- прямі малі виклики успішні, але запуски OpenClaw завершуються помилкою лише на більших prompt
+- прямі малі виклики успішні, але запуски OpenClaw падають лише на більших запитах
 - помилки backend про те, що `messages[].content` очікує рядок
-- збої backend, які з’являються лише з більшими значеннями prompt-token або з повними
-  prompt runtime агента
+- збої backend, які з’являються лише з більшою кількістю токенів у запиті або з повними
+  запитами середовища виконання агента
 
 Поширені ознаки:
 
 - `messages[...].content: invalid type: sequence, expected a string` → backend
-  відхиляє структуровані частини content у Chat Completions. Виправлення: задайте
+  відхиляє структуровані частини вмісту Chat Completions. Виправлення: встановіть
   `models.providers.<provider>.models[].compat.requiresStringContent: true`.
-- прямі малі запити успішні, але запуски агента OpenClaw завершуються збоями backend/model
+- прямі малі запити успішні, але запуски агентів OpenClaw падають через збої backend/моделі
   (наприклад, Gemma у деяких збірках `inferrs`) → транспорт OpenClaw,
-  імовірно, уже налаштовано правильно; збій відбувається через більшу форму
-  prompt runtime агента.
-- збої зменшуються після вимкнення tools, але не зникають → схеми tools були
-  частиною навантаження, але решта проблеми все ще є upstream-обмеженням моделі/сервера
-  або помилкою backend.
+  імовірно, уже налаштований правильно; backend падає через форму більшого
+  запиту середовища виконання агента.
+- після вимкнення інструментів збоїв меншає, але вони не зникають → схеми інструментів
+  були частиною навантаження, але решта проблеми все ще лежить у вищестоячій
+  місткості моделі/сервера або в помилці backend.
 
 Варіанти виправлення:
 
-1. Задайте `compat.requiresStringContent: true` для backend Chat Completions, які підтримують лише рядки.
-2. Задайте `compat.supportsTools: false` для моделей/backend, які не можуть надійно
-   обробляти поверхню схеми tools OpenClaw.
-3. Де можливо, зменште навантаження prompt: менший bootstrap workspace, коротша
-   історія сесії, легша локальна модель або backend із кращою підтримкою long-context.
-4. Якщо малі прямі запити й далі проходять, а ходи агента OpenClaw все ще спричиняють збій
-   усередині backend, вважайте це upstream-обмеженням сервера/моделі й подайте туди repro з прийнятою формою payload.
+1. Встановіть `compat.requiresStringContent: true` для backend Chat Completions, які підтримують лише рядки.
+2. Встановіть `compat.supportsTools: false` для моделей/backend, які не можуть
+   надійно обробляти поверхню схем інструментів OpenClaw.
+3. За можливості зменште навантаження запиту: менший bootstrap робочого простору, коротша
+   історія сесії, легша локальна модель або backend із кращою підтримкою довгого контексту.
+4. Якщо малі прямі запити й далі проходять, а ходи агентів OpenClaw все ще падають
+   усередині backend, розглядайте це як обмеження вищестоячого сервера/моделі й
+   подайте туди відтворюваний приклад із прийнятою формою payload.
 
 Пов’язане:
 
@@ -121,7 +122,7 @@ openclaw logs --follow
 
 ## Немає відповідей
 
-Якщо канали працюють, але нічого не відповідає, перевірте маршрутизацію та політику, перш ніж щось перепідключати.
+Якщо канали підняті, але ніхто не відповідає, перевірте маршрутизацію та політики, перш ніж щось перепідключати.
 
 ```bash
 openclaw status
@@ -131,16 +132,16 @@ openclaw config get channels
 openclaw logs --follow
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
-- Для відправників DM очікується pairing.
-- Обмеження згадками в групах (`requireMention`, `mentionPatterns`).
+- Pairing у стані очікування для відправників у DM.
+- Вимогу згадки в групі (`requireMention`, `mentionPatterns`).
 - Невідповідності allowlist каналу/групи.
 
 Поширені ознаки:
 
-- `drop guild message (mention required` → групове повідомлення ігнорується, доки немає згадки.
-- `pairing request` → відправник потребує підтвердження.
+- `drop guild message (mention required` → повідомлення групи ігнорується, доки немає згадки.
+- `pairing request` → відправнику потрібне схвалення.
 - `blocked` / `allowlist` → відправника/канал було відфільтровано політикою.
 
 Пов’язане:
@@ -151,7 +152,7 @@ openclaw logs --follow
 
 ## Підключення dashboard/control UI
 
-Коли dashboard/control UI не підключається, перевірте URL, режим auth і припущення щодо secure context.
+Коли dashboard/control UI не може підключитися, перевірте URL, режим автентифікації та припущення щодо безпечного контексту.
 
 ```bash
 openclaw gateway status
@@ -161,48 +162,49 @@ openclaw doctor
 openclaw gateway status --json
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
-- Правильний probe URL і dashboard URL.
-- Невідповідність режиму auth/token між клієнтом і gateway.
-- Використання HTTP там, де потрібна device identity.
+- Правильний URL probe і URL dashboard.
+- Невідповідність режиму автентифікації/токена між клієнтом і Gateway.
+- Використання HTTP там, де потрібна ідентичність пристрою.
 
 Поширені ознаки:
 
-- `device identity required` → non-secure context або відсутня device auth.
+- `device identity required` → небезпечний контекст або відсутня автентифікація пристрою.
 - `origin not allowed` → `Origin` браузера відсутній у `gateway.controlUi.allowedOrigins`
-  (або ви підключаєтесь із non-loopback browser origin без явного
+  (або ви підключаєтеся з не-loopback browser origin без явного
   allowlist).
 - `device nonce required` / `device nonce mismatch` → клієнт не завершує
-  challenge-based потік device auth (`connect.challenge` + `device.nonce`).
+  challenge-based потік автентифікації пристрою (`connect.challenge` + `device.nonce`).
 - `device signature invalid` / `device signature expired` → клієнт підписав неправильний
-  payload (або з застарілим timestamp) для поточного handshake.
-- `AUTH_TOKEN_MISMATCH` з `canRetryWithDeviceToken=true` → клієнт може виконати одну довірену повторну спробу з кешованим device token.
-- Ця повторна спроба з кешованим token повторно використовує кешований набір scope, збережений разом із paired
-  device token. Виклики з явним `deviceToken` / явними `scopes` зберігають свій
+  payload (або використав застарілу часову мітку) для поточного рукостискання.
+- `AUTH_TOKEN_MISMATCH` з `canRetryWithDeviceToken=true` → клієнт може виконати одну довірену повторну спробу з кешованим токеном пристрою.
+- Ця повторна спроба з кешованим токеном повторно використовує кешований набір scope, збережений разом
+  із paired device token. Виклики з явними `deviceToken` / явними `scopes` зберігають свій
   запитаний набір scope.
-- Поза цим шляхом повторної спроби пріоритет connect auth такий: спочатку явний shared
-  token/password, потім явний `deviceToken`, потім збережений device token,
+- Поза цим шляхом повторної спроби пріоритет автентифікації під час підключення такий: спочатку явний shared
+  token/password, потім явний `deviceToken`, потім збережений токен пристрою,
   потім bootstrap token.
 - На асинхронному шляху Tailscale Serve Control UI невдалі спроби для того самого
-  `{scope, ip}` серіалізуються до того, як лімітер зафіксує невдачу. Тому дві некоректні
+  `{scope, ip}` серіалізуються до того, як обмежувач зафіксує невдачу. Тому дві некоректні
   одночасні повторні спроби від того самого клієнта можуть дати `retry later`
   на другій спробі замість двох звичайних невідповідностей.
 - `too many failed authentication attempts (retry later)` від loopback-клієнта з browser-origin
-  → повторні невдачі від того самого нормалізованого `Origin` тимчасово блокуються; інший localhost origin використовує окремий bucket.
-- повторюване `unauthorized` після такої повторної спроби → розсинхронізація shared token/device token; оновіть config token і повторно підтвердьте/перевипустіть device token за потреби.
-- `gateway connect failed:` → неправильний host/port/url цілі.
+  → повторні невдалі спроби з того самого нормалізованого `Origin` тимчасово
+  блокуються; інший localhost origin використовує окремий bucket.
+- повторюваний `unauthorized` після цієї повторної спроби → розсинхронізація shared token/device token; оновіть конфігурацію токена та за потреби знову схваліть/перевипустіть токен пристрою.
+- `gateway connect failed:` → неправильний хост/порт/url призначення.
 
-### Швидка мапа кодів деталей auth
+### Швидка мапа кодів деталей автентифікації
 
-Використовуйте `error.details.code` з невдалої відповіді `connect`, щоб вибрати наступну дію:
+Використовуйте `error.details.code` із невдалої відповіді `connect`, щоб вибрати наступну дію:
 
-| Код деталей                  | Значення                                                                                                                                                                                       | Рекомендована дія                                                                                                                                                                                                                                                                       |
-| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `AUTH_TOKEN_MISSING`         | Клієнт не надіслав обов’язковий shared token.                                                                                                                                                  | Вставте/задайте token у клієнті й повторіть спробу. Для шляхів dashboard: `openclaw config get gateway.auth.token`, потім вставте його в налаштуваннях Control UI.                                                                                                                    |
-| `AUTH_TOKEN_MISMATCH`        | Shared token не збігся з token auth gateway.                                                                                                                                                   | Якщо `canRetryWithDeviceToken=true`, дозвольте одну довірену повторну спробу. Повторні спроби з кешованим token повторно використовують збережені підтверджені scopes; виклики з явним `deviceToken` / `scopes` зберігають запитаний набір scopes. Якщо збій лишається, виконайте [контрольний список відновлення після розсинхронізації token](/uk/cli/devices#token-drift-recovery-checklist). |
-| `AUTH_DEVICE_TOKEN_MISMATCH` | Кешований token на пристрої застарів або відкликаний.                                                                                                                                          | Перевипустіть/повторно підтвердьте device token через [CLI devices](/uk/cli/devices), потім підключіться знову.                                                                                                                                                                           |
-| `PAIRING_REQUIRED`           | Device identity потребує підтвердження. Перевірте `error.details.reason` на `not-paired`, `scope-upgrade`, `role-upgrade` або `metadata-upgrade` і використовуйте `requestId` / `remediationHint`, якщо вони присутні. | Підтвердьте очікуваний запит: `openclaw devices list`, потім `openclaw devices approve <requestId>`. Оновлення scope/role використовують той самий потік після того, як ви переглянете запитаний доступ.                                                                            |
+| Код деталей                  | Значення                                                                                                                                                                                     | Рекомендована дія                                                                                                                                                                                                                                                                         |
+| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `AUTH_TOKEN_MISSING`         | Клієнт не надіслав обов’язковий shared token.                                                                                                                                                | Вставте/задайте токен у клієнті та повторіть спробу. Для шляхів dashboard: `openclaw config get gateway.auth.token`, а потім вставте його в налаштуваннях Control UI.                                                                                                                  |
+| `AUTH_TOKEN_MISMATCH`        | Shared token не збігся з токеном автентифікації Gateway.                                                                                                                                     | Якщо `canRetryWithDeviceToken=true`, дозвольте одну довірену повторну спробу. Повторні спроби з кешованим токеном повторно використовують збережені схвалені scope; виклики з явними `deviceToken` / `scopes` зберігають запитаний scope. Якщо все одно не працює, виконайте [контрольний список відновлення після розсинхронізації токена](/uk/cli/devices#token-drift-recovery-checklist). |
+| `AUTH_DEVICE_TOKEN_MISMATCH` | Кешований токен для конкретного пристрою застарів або був відкликаний.                                                                                                                       | Перевипустіть/повторно схваліть токен пристрою за допомогою [CLI пристроїв](/uk/cli/devices), а потім перепідключіться.                                                                                                                                                                    |
+| `PAIRING_REQUIRED`           | Ідентичність пристрою потребує схвалення. Перевірте `error.details.reason` для `not-paired`, `scope-upgrade`, `role-upgrade` або `metadata-upgrade`, і використовуйте `requestId` / `remediationHint`, якщо вони є. | Схваліть запит, що очікує: `openclaw devices list`, потім `openclaw devices approve <requestId>`. Оновлення scope/ролей використовують той самий потік після того, як ви перевірите запитаний доступ.                                                                                   |
 
 Перевірка міграції device auth v2:
 
@@ -216,24 +218,24 @@ openclaw gateway status
 
 1. чекає на `connect.challenge`
 2. підписує payload, прив’язаний до challenge
-3. надсилає `connect.params.device.nonce` з тим самим challenge nonce
+3. надсилає `connect.params.device.nonce` з тим самим nonce challenge
 
-Якщо `openclaw devices rotate` / `revoke` / `remove` неочікувано відхиляється:
+Якщо `openclaw devices rotate` / `revoke` / `remove` неочікувано заборонено:
 
 - сесії paired-device token можуть керувати лише **власним** пристроєм, якщо
-  виклик також не має `operator.admin`
-- `openclaw devices rotate --scope ...` може запитувати лише ті operator scopes,
-  які сесія виклику вже має
+  викликальник також не має `operator.admin`
+- `openclaw devices rotate --scope ...` може запитувати лише ті operator scope,
+  які сесія викликальника вже має
 
 Пов’язане:
 
 - [/web/control-ui](/uk/web/control-ui)
-- [/gateway/configuration](/uk/gateway/configuration) (режими auth gateway)
+- [/gateway/configuration](/uk/gateway/configuration) (режими автентифікації gateway)
 - [/gateway/trusted-proxy-auth](/uk/gateway/trusted-proxy-auth)
 - [/gateway/remote](/uk/gateway/remote)
 - [/cli/devices](/uk/cli/devices)
 
-## Сервіс Gateway не працює
+## Сервіс Gateway не запущено
 
 Використовуйте це, коли сервіс установлено, але процес не залишається запущеним.
 
@@ -242,23 +244,23 @@ openclaw gateway status
 openclaw status
 openclaw logs --follow
 openclaw doctor
-openclaw gateway status --deep   # також сканувати системні сервіси
+openclaw gateway status --deep   # also scan system-level services
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
-- `Runtime: stopped` з підказками щодо виходу.
-- Невідповідність config сервісу (`Config (cli)` vs `Config (service)`).
-- Конфлікти port/listener.
+- `Runtime: stopped` із підказками щодо завершення.
+- Невідповідність конфігурації сервісу (`Config (cli)` vs `Config (service)`).
+- Конфлікти портів/слухачів.
 - Додаткові встановлення launchd/systemd/schtasks, коли використовується `--deep`.
 - Підказки очищення `Other gateway-like services detected (best effort)`.
 
 Поширені ознаки:
 
-- `Gateway start blocked: set gateway.mode=local` або `existing config is missing gateway.mode` → локальний режим gateway не ввімкнено, або файл config було пошкоджено й він втратив `gateway.mode`. Виправлення: задайте `gateway.mode="local"` у вашому config або повторно запустіть `openclaw onboard --mode local` / `openclaw setup`, щоб знову проставити очікуваний config локального режиму. Якщо ви запускаєте OpenClaw через Podman, типовий шлях до config — `~/.openclaw/openclaw.json`.
-- `refusing to bind gateway ... without auth` → прив’язка до non-loopback без коректного шляху auth gateway (token/password або trusted-proxy, де налаштовано).
+- `Gateway start blocked: set gateway.mode=local` або `existing config is missing gateway.mode` → локальний режим Gateway не ввімкнено, або файл конфігурації було пошкоджено і він утратив `gateway.mode`. Виправлення: установіть `gateway.mode="local"` у своїй конфігурації або повторно запустіть `openclaw onboard --mode local` / `openclaw setup`, щоб повторно проставити очікувану конфігурацію локального режиму. Якщо ви запускаєте OpenClaw через Podman, типовий шлях до конфігурації — `~/.openclaw/openclaw.json`.
+- `refusing to bind gateway ... without auth` → прив’язка не-loopback адреси без дійсного шляху автентифікації gateway (token/password або trusted-proxy, якщо налаштовано).
 - `another gateway instance is already listening` / `EADDRINUSE` → конфлікт порту.
-- `Other gateway-like services detected (best effort)` → існують застарілі або паралельні units launchd/systemd/schtasks. У більшості налаштувань має бути один gateway на машину; якщо вам справді потрібно більше одного, ізолюйте порти + config/state/workspace. Див. [/gateway#multiple-gateways-same-host](/uk/gateway#multiple-gateways-same-host).
+- `Other gateway-like services detected (best effort)` → існують застарілі або паралельні launchd/systemd/schtasks units. У більшості конфігурацій слід мати один Gateway на машину; якщо вам справді потрібно більше одного, ізолюйте порти + config/state/workspace. Див. [/gateway#multiple-gateways-same-host](/uk/gateway#multiple-gateways-same-host).
 
 Пов’язане:
 
@@ -266,9 +268,9 @@ openclaw gateway status --deep   # також сканувати системн
 - [/gateway/configuration](/uk/gateway/configuration)
 - [/gateway/doctor](/uk/gateway/doctor)
 
-## Gateway відновив last-known-good config
+## Gateway відновив останню відому справну конфігурацію
 
-Використовуйте це, коли Gateway запускається, але журнали повідомляють, що він відновив `openclaw.json`.
+Використовуйте це, коли Gateway запускається, але в журналах сказано, що він відновив `openclaw.json`.
 
 ```bash
 openclaw logs --follow
@@ -277,22 +279,22 @@ openclaw config validate
 openclaw doctor
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
 - `Config auto-restored from last-known-good`
 - `gateway: invalid config was restored from last-known-good backup`
 - `config reload restored last-known-good config after invalid-config`
-- файл `openclaw.json.clobbered.*` з часовою позначкою поруч з активним config
-- системна подія головного агента, що починається з `Config recovery warning`
+- Файл `openclaw.json.clobbered.*` із часовою міткою поруч з активною конфігурацією
+- Системну подію головного агента, що починається з `Config recovery warning`
 
 Що сталося:
 
-- Відхилений config не пройшов validate під час запуску або hot reload.
+- Відхилена конфігурація не пройшла валідацію під час запуску або гарячого перезавантаження.
 - OpenClaw зберіг відхилений payload як `.clobbered.*`.
-- Активний config було відновлено з останньої перевіреної last-known-good копії.
-- Наступний хід головного агента отримає попередження не перезаписувати відхилений config бездумно.
+- Активну конфігурацію було відновлено з останньої перевіреної справної копії.
+- На наступному ході головного агента з’явиться попередження не переписувати відхилену конфігурацію навмання.
 
-Перевірка й виправлення:
+Перевірка та виправлення:
 
 ```bash
 CONFIG="$(openclaw config file)"
@@ -304,18 +306,18 @@ openclaw doctor
 
 Поширені ознаки:
 
-- існує `.clobbered.*` → було відновлено зовнішнє пряме редагування або читання під час запуску.
-- існує `.rejected.*` → запис config, ініційований OpenClaw, не пройшов перевірки schema або clobber перед commit.
-- `Config write rejected:` → запис намагався прибрати обов’язкову структуру, різко зменшити файл або зберегти невалідний config.
-- `missing-meta-vs-last-good`, `gateway-mode-missing-vs-last-good` або `size-drop-vs-last-good:*` → під час запуску поточний файл було розцінено як clobbered, бо він втратив поля або розмір порівняно з резервною last-known-good копією.
-- `Config last-known-good promotion skipped` → кандидат містив замасковані placeholders секретів, як-от `***`.
+- існує `.clobbered.*` → зовнішнє пряме редагування або читання під час запуску було відновлено.
+- існує `.rejected.*` → запис конфігурації, що належав OpenClaw, не пройшов перевірку схеми або clobber-перевірки перед фіксацією.
+- `Config write rejected:` → запис намагався прибрати обов’язкову структуру, різко зменшити файл або зберегти недійсну конфігурацію.
+- `missing-meta-vs-last-good`, `gateway-mode-missing-vs-last-good` або `size-drop-vs-last-good:*` → під час запуску поточний файл було визнано пошкодженим, оскільки він утратив поля або розмір порівняно з останньою відомою справною резервною копією.
+- `Config last-known-good promotion skipped` → кандидат містив замасковані плейсхолдери секретів, як-от `***`.
 
 Варіанти виправлення:
 
-1. Залиште відновлений активний config, якщо він правильний.
+1. Залиште відновлену активну конфігурацію, якщо вона правильна.
 2. Скопіюйте лише потрібні ключі з `.clobbered.*` або `.rejected.*`, а потім застосуйте їх через `openclaw config set` або `config.patch`.
 3. Запустіть `openclaw config validate` перед перезапуском.
-4. Якщо ви редагуєте вручну, зберігайте повний JSON5 config, а не лише частковий об’єкт, який хотіли змінити.
+4. Якщо редагуєте вручну, зберігайте повний JSON5 config, а не лише частковий об’єкт, який хотіли змінити.
 
 Пов’язане:
 
@@ -326,7 +328,7 @@ openclaw doctor
 
 ## Попередження probe Gateway
 
-Використовуйте це, коли `openclaw gateway probe` до чогось дістається, але все одно друкує блок попередження.
+Використовуйте це, коли `openclaw gateway probe` до чогось достукується, але все одно виводить блок попереджень.
 
 ```bash
 openclaw gateway probe
@@ -334,18 +336,18 @@ openclaw gateway probe --json
 openclaw gateway probe --ssh user@gateway-host
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
-- `warnings[].code` і `primaryTargetId` у виводі JSON.
-- Чи стосується попередження SSH fallback, кількох gateways, відсутніх scopes або невизначених auth refs.
+- `warnings[].code` і `primaryTargetId` у JSON-виводі.
+- Чи стосується попередження резервного переходу на SSH, кількох Gateway, відсутніх scope або нерозв’язаних auth refs.
 
 Поширені ознаки:
 
-- `SSH tunnel failed to start; falling back to direct probes.` → налаштування SSH не вдалося, але команда все одно спробувала прямі налаштовані/loopback targets.
-- `multiple reachable gateways detected` → відповіло більше однієї цілі. Зазвичай це означає навмисне налаштування з кількома gateways або застарілі/дубльовані listeners.
-- `Read-probe diagnostics are limited by gateway scopes (missing operator.read)` → підключення спрацювало, але detail RPC обмежено scopes; підключіть device identity або використайте облікові дані з `operator.read`.
-- `Capability: pairing-pending` або `gateway closed (1008): pairing required` → gateway відповів, але цьому клієнту все ще потрібні pairing/підтвердження перед звичайним доступом оператора.
-- текст попередження про невизначені `gateway.auth.*` / `gateway.remote.*` SecretRef → auth material був недоступний у цьому шляху команди для цілі, що не вдалася.
+- `SSH tunnel failed to start; falling back to direct probes.` → налаштування SSH не вдалося, але команда все одно спробувала прямі налаштовані/loopback цілі.
+- `multiple reachable gateways detected` → відповіла більше ніж одна ціль. Зазвичай це означає навмисну конфігурацію з кількома Gateway або застарілі/дубльовані listeners.
+- `Read-probe diagnostics are limited by gateway scopes (missing operator.read)` → підключення спрацювало, але detail RPC обмежений scope; виконайте pair device identity або використайте облікові дані з `operator.read`.
+- `Capability: pairing-pending` або `gateway closed (1008): pairing required` → Gateway відповів, але цьому клієнту все ще потрібне pairing/схвалення перед звичайним operator access.
+- нерозв’язаний текст попередження `gateway.auth.*` / `gateway.remote.*` SecretRef → auth material був недоступний у цьому шляху команди для цілі, що не вдалася.
 
 Пов’язане:
 
@@ -355,7 +357,7 @@ openclaw gateway probe --ssh user@gateway-host
 
 ## Канал підключений, але повідомлення не проходять
 
-Якщо стан каналу — connected, але потік повідомлень не працює, зосередьтеся на політиці, дозволах і правилах доставки, специфічних для каналу.
+Якщо стан каналу — connected, але потік повідомлень не працює, зосередьтеся на політиці, дозволах і специфічних для каналу правилах доставки.
 
 ```bash
 openclaw channels status --probe
@@ -365,17 +367,17 @@ openclaw logs --follow
 openclaw config get channels
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
-- Політика DM (`pairing`, `allowlist`, `open`, `disabled`).
-- Allowlist груп і вимоги до згадок.
+- Політику DM (`pairing`, `allowlist`, `open`, `disabled`).
+- Allowlist групи та вимоги щодо згадки.
 - Відсутні дозволи/scopes API каналу.
 
 Поширені ознаки:
 
-- `mention required` → повідомлення ігнорується через політику згадок у групі.
-- `pairing` / сліди очікуваного підтвердження → відправника не підтверджено.
-- `missing_scope`, `not_in_channel`, `Forbidden`, `401/403` → проблема auth/дозволів каналу.
+- `mention required` → повідомлення проігноровано політикою згадок у групі.
+- `pairing` / сліди очікування схвалення → відправника не схвалено.
+- `missing_scope`, `not_in_channel`, `Forbidden`, `401/403` → проблема автентифікації/дозволів каналу.
 
 Пов’язане:
 
@@ -386,7 +388,7 @@ openclaw config get channels
 
 ## Доставка Cron і Heartbeat
 
-Якщо Cron або Heartbeat не запустився чи не доставився, спершу перевірте стан scheduler, а потім ціль доставки.
+Якщо Cron або Heartbeat не запустився чи не доставився, спочатку перевірте стан планувальника, а потім ціль доставки.
 
 ```bash
 openclaw cron status
@@ -396,21 +398,21 @@ openclaw system heartbeat last
 openclaw logs --follow
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
-- Cron увімкнено і присутній наступний wake.
-- Статус історії запусків job (`ok`, `skipped`, `error`).
+- Чи ввімкнено Cron і чи є наступне пробудження.
+- Стан історії запусків завдання (`ok`, `skipped`, `error`).
 - Причини пропуску Heartbeat (`quiet-hours`, `requests-in-flight`, `alerts-disabled`, `empty-heartbeat-file`, `no-tasks-due`).
 
 Поширені ознаки:
 
 - `cron: scheduler disabled; jobs will not run automatically` → Cron вимкнено.
-- `cron: timer tick failed` → збій tick scheduler; перевірте помилки file/log/runtime.
+- `cron: timer tick failed` → збій тіку планувальника; перевірте помилки файлів/журналів/runtime.
 - `heartbeat skipped` з `reason=quiet-hours` → поза вікном активних годин.
 - `heartbeat skipped` з `reason=empty-heartbeat-file` → `HEARTBEAT.md` існує, але містить лише порожні рядки / заголовки markdown, тому OpenClaw пропускає виклик моделі.
-- `heartbeat skipped` з `reason=no-tasks-due` → `HEARTBEAT.md` містить блок `tasks:`, але жодне із завдань не має виконуватися під час цього tick.
-- `heartbeat: unknown accountId` → невалідний account id для цілі доставки Heartbeat.
-- `heartbeat skipped` з `reason=dm-blocked` → ціль Heartbeat визначилася як призначення у стилі DM, тоді як `agents.defaults.heartbeat.directPolicy` (або перевизначення для окремого агента) має значення `block`.
+- `heartbeat skipped` з `reason=no-tasks-due` → `HEARTBEAT.md` містить блок `tasks:`, але жодне із завдань не має бути виконане на цьому тіку.
+- `heartbeat: unknown accountId` → недійсний id облікового запису для цілі доставки Heartbeat.
+- `heartbeat skipped` з `reason=dm-blocked` → ціль Heartbeat була визначена як пункт призначення у стилі DM, тоді як `agents.defaults.heartbeat.directPolicy` (або перевизначення для конкретного агента) встановлено в `block`.
 
 Пов’язане:
 
@@ -418,9 +420,9 @@ openclaw logs --follow
 - [/automation/cron-jobs](/uk/automation/cron-jobs)
 - [/gateway/heartbeat](/uk/gateway/heartbeat)
 
-## Інструмент paired Node завершується помилкою
+## Збій інструмента спареного Node
 
-Якщо Node підключений, але tools не працюють, ізолюйте стан foreground, дозволів і підтверджень.
+Якщо Node спарено, але інструменти не працюють, ізолюйте стан foreground, дозволів і схвалення.
 
 ```bash
 openclaw nodes status
@@ -430,17 +432,17 @@ openclaw logs --follow
 openclaw status
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
-- Node online з очікуваними capabilities.
-- Надані дозволи ОС для camera/mic/location/screen.
-- Стан exec approvals і allowlist.
+- Node онлайн з очікуваними capability.
+- Надані на рівні ОС дозволи для camera/mic/location/screen.
+- Стан схвалень exec і allowlist.
 
 Поширені ознаки:
 
-- `NODE_BACKGROUND_UNAVAILABLE` → застосунок Node має бути на передньому плані.
+- `NODE_BACKGROUND_UNAVAILABLE` → застосунок Node має бути у foreground.
 - `*_PERMISSION_REQUIRED` / `LOCATION_PERMISSION_REQUIRED` → бракує дозволу ОС.
-- `SYSTEM_RUN_DENIED: approval required` → очікується exec approval.
+- `SYSTEM_RUN_DENIED: approval required` → очікується схвалення exec.
 - `SYSTEM_RUN_DENIED: allowlist miss` → команду заблоковано через allowlist.
 
 Пов’язане:
@@ -449,9 +451,9 @@ openclaw status
 - [/nodes/index](/uk/nodes/index)
 - [/tools/exec-approvals](/uk/tools/exec-approvals)
 
-## Помилка browser tool
+## Збій інструмента браузера
 
-Використовуйте це, коли дії browser tool завершуються помилкою, хоча сам gateway працює нормально.
+Використовуйте це, коли дії browser tool не працюють, хоча сам Gateway справний.
 
 ```bash
 openclaw browser status
@@ -461,33 +463,35 @@ openclaw logs --follow
 openclaw doctor
 ```
 
-Звертайте увагу на таке:
+Шукайте:
 
-- Чи задано `plugins.allow` і чи містить він `browser`.
-- Коректний шлях до виконуваного файла браузера.
+- Чи встановлено `plugins.allow` і чи містить він `browser`.
+- Чинний шлях до виконуваного файла браузера.
 - Досяжність профілю CDP.
 - Доступність локального Chrome для профілів `existing-session` / `user`.
 
 Поширені ознаки:
 
-- `unknown command "browser"` або `unknown command 'browser'` → вбудований Plugin browser виключено через `plugins.allow`.
-- browser tool відсутній / недоступний, хоча `browser.enabled=true` → `plugins.allow` виключає `browser`, тому Plugin ніколи не завантажився.
-- `Failed to start Chrome CDP on port` → процес браузера не вдалося запустити.
-- `browser.executablePath not found` → заданий шлях невалідний.
-- `browser.cdpUrl must be http(s) or ws(s)` → заданий URL CDP використовує непідтримувану схему, наприклад `file:` або `ftp:`.
-- `browser.cdpUrl has invalid port` → заданий URL CDP має некоректний або вихідний за межі діапазону порт.
-- `Could not find DevToolsActivePort for chrome` → Chrome MCP existing-session ще не зміг приєднатися до вибраного каталогу даних браузера. Відкрийте сторінку inspect браузера, увімкніть remote debugging, залиште браузер відкритим, підтвердьте перший запит на приєднання, а потім повторіть спробу. Якщо стан входу не потрібен, віддавайте перевагу керованому профілю `openclaw`.
+- `unknown command "browser"` або `unknown command 'browser'` → вбудований browser Plugin виключено через `plugins.allow`.
+- browser tool відсутній / недоступний, хоча `browser.enabled=true` → `plugins.allow` виключає `browser`, тому Plugin ніколи не завантажувався.
+- `Failed to start Chrome CDP on port` → не вдалося запустити процес браузера.
+- `browser.executablePath not found` → налаштований шлях недійсний.
+- `browser.cdpUrl must be http(s) or ws(s)` → налаштований URL CDP використовує непідтримувану схему, наприклад `file:` або `ftp:`.
+- `browser.cdpUrl has invalid port` → налаштований URL CDP має некоректний або позадіапазонний порт.
+- `Could not find DevToolsActivePort for chrome` → Chrome MCP existing-session ще не зміг приєднатися до вибраного каталогу даних браузера. Відкрийте сторінку inspect браузера, увімкніть remote debugging, залиште браузер відкритим, схваліть перший запит на приєднання, а потім повторіть спробу. Якщо стан входу в обліковий запис не потрібен, віддайте перевагу керованому профілю `openclaw`.
 - `No Chrome tabs found for profile="user"` → профіль приєднання Chrome MCP не має відкритих локальних вкладок Chrome.
-- `Remote CDP for profile "<name>" is not reachable` → налаштований віддалений endpoint CDP недосяжний із хоста gateway.
-- `Browser attachOnly is enabled ... not reachable` або `Browser attachOnly is enabled and CDP websocket ... is not reachable` → для профілю attach-only немає досяжної цілі, або HTTP endpoint відповів, але Webhook CDP усе одно не вдалося відкрити.
-- `Playwright is not available in this gateway build; '<feature>' is unsupported.` → поточне встановлення gateway не має залежності runtime `playwright-core` вбудованого browser Plugin; запустіть `openclaw doctor --fix`, а потім перезапустіть gateway. Знімки ARIA і базові screenshot сторінки все ще можуть працювати, але навігація, AI snapshots, screenshot елементів за CSS-селекторами й експорт PDF залишаться недоступними.
-- `fullPage is not supported for element screenshots` → запит screenshot поєднав `--full-page` з `--ref` або `--element`.
-- `element screenshots are not supported for existing-session profiles; use ref from snapshot.` → виклики screenshot Chrome MCP / `existing-session` мають використовувати захоплення сторінки або snapshot `--ref`, а не CSS `--element`.
-- `existing-session file uploads do not support element selectors; use ref/inputRef.` → hooks завантаження файлів Chrome MCP потребують snapshot refs, а не CSS selectors.
-- `existing-session file uploads currently support one file at a time.` → надсилайте одне завантаження за виклик у профілях Chrome MCP.
-- `existing-session dialog handling does not support timeoutMs.` → hooks діалогів у профілях Chrome MCP не підтримують перевизначення timeout.
-- `response body is not supported for existing-session profiles yet.` → `responsebody` усе ще потребує керованого браузера або профілю raw CDP.
-- застарілі перевизначення viewport / dark-mode / locale / offline у профілях attach-only або remote CDP → запустіть `openclaw browser stop --browser-profile <name>`, щоб закрити активну сесію керування й звільнити стан емуляції Playwright/CDP без перезапуску всього gateway.
+- `Remote CDP for profile "<name>" is not reachable` → налаштований віддалений endpoint CDP недоступний з хоста gateway.
+- `Browser attachOnly is enabled ... not reachable` або `Browser attachOnly is enabled and CDP websocket ... is not reachable` → профіль лише для приєднання не має досяжної цілі, або HTTP endpoint відповів, але CDP WebSocket усе одно не вдалося відкрити.
+- `Playwright is not available in this gateway build; '<feature>' is unsupported.` → у поточному встановленні gateway бракує залежності середовища виконання `playwright-core` для вбудованого browser Plugin; виконайте `openclaw doctor --fix`, а потім перезапустіть gateway. Знімки ARIA та базові знімки сторінок усе ще можуть працювати, але навігація, AI snapshots, знімки елементів за CSS-селекторами та експорт PDF залишаться недоступними.
+- `fullPage is not supported for element screenshots` → запит на знімок екрана поєднав `--full-page` з `--ref` або `--element`.
+- `element screenshots are not supported for existing-session profiles; use ref from snapshot.` → виклики знімків екрана Chrome MCP / `existing-session` мають використовувати захоплення сторінки або `--ref` зі snapshot, а не CSS `--element`.
+- `existing-session file uploads do not support element selectors; use ref/inputRef.` → хуки завантаження файлів Chrome MCP потребують snapshot refs, а не CSS-селекторів.
+- `existing-session file uploads currently support one file at a time.` → для профілів Chrome MCP надсилайте одне завантаження за виклик.
+- `existing-session dialog handling does not support timeoutMs.` → хуки діалогів у профілях Chrome MCP не підтримують перевизначення timeout.
+- `existing-session type does not support timeoutMs overrides.` → не вказуйте `timeoutMs` для `act:type` у профілях `profile="user"` / Chrome MCP existing-session, або використайте керований/CDP профіль браузера, коли потрібен власний timeout.
+- `existing-session evaluate does not support timeoutMs overrides.` → не вказуйте `timeoutMs` для `act:evaluate` у профілях `profile="user"` / Chrome MCP existing-session, або використайте керований/CDP профіль браузера, коли потрібен власний timeout.
+- `response body is not supported for existing-session profiles yet.` → `responsebody` поки що потребує керованого браузера або сирого профілю CDP.
+- застарілі перевизначення viewport / dark-mode / locale / offline у профілях attach-only або remote CDP → виконайте `openclaw browser stop --browser-profile <name>`, щоб закрити активну керувальну сесію та звільнити стан емуляції Playwright/CDP без перезапуску всього gateway.
 
 Пов’язане:
 
@@ -496,9 +500,9 @@ openclaw doctor
 
 ## Якщо ви оновилися і щось раптово зламалося
 
-Більшість проблем після оновлення — це дрейф config або застосування суворіших значень за замовчуванням.
+Більшість збоїв після оновлення — це розсинхронізація конфігурації або суворіші типові значення, які тепер примусово застосовуються.
 
-### 1) Змінилася поведінка auth і перевизначення URL
+### 1) Змінилася поведінка перевизначення auth і URL
 
 ```bash
 openclaw gateway status
@@ -509,15 +513,15 @@ openclaw config get gateway.auth.mode
 
 Що перевірити:
 
-- Якщо `gateway.mode=remote`, виклики CLI можуть звертатися до remote, тоді як ваш локальний сервіс працює нормально.
-- Явні виклики `--url` не використовують резервні збережені облікові дані.
+- Якщо `gateway.mode=remote`, виклики CLI можуть бути спрямовані на віддалену ціль, тоді як локальний сервіс працює нормально.
+- Явні виклики `--url` не використовують збережені облікові дані як резервний варіант.
 
 Поширені ознаки:
 
-- `gateway connect failed:` → неправильна URL-ціль.
-- `unauthorized` → endpoint досяжний, але auth неправильна.
+- `gateway connect failed:` → неправильний URL цілі.
+- `unauthorized` → endpoint досяжний, але auth неправильний.
 
-### 2) Обмеження bind і auth стали суворішими
+### 2) Захисні обмеження для bind і auth стали суворішими
 
 ```bash
 openclaw config get gateway.bind
@@ -529,15 +533,15 @@ openclaw logs --follow
 
 Що перевірити:
 
-- Прив’язки non-loopback (`lan`, `tailnet`, `custom`) потребують коректного шляху auth gateway: auth зі спільним token/password або правильно налаштованого non-loopback розгортання `trusted-proxy`.
-- Старі ключі, як-от `gateway.token`, не замінюють `gateway.auth.token`.
+- Прив’язки не-loopback (`lan`, `tailnet`, `custom`) потребують дійсного шляху автентифікації gateway: auth за shared token/password або правильно налаштоване розгортання `trusted-proxy` не-loopback.
+- Старі ключі на кшталт `gateway.token` не замінюють `gateway.auth.token`.
 
 Поширені ознаки:
 
-- `refusing to bind gateway ... without auth` → прив’язка non-loopback без коректного шляху auth gateway.
-- `Connectivity probe: failed` while runtime is running → gateway активний, але недоступний з поточними auth/url.
+- `refusing to bind gateway ... without auth` → прив’язка не-loopback без дійсного шляху автентифікації gateway.
+- `Connectivity probe: failed` коли runtime запущено → gateway працює, але недоступний із поточними auth/url.
 
-### 3) Змінився стан pairing і device identity
+### 3) Змінився стан pairing та ідентичності пристрою
 
 ```bash
 openclaw devices list
@@ -548,15 +552,15 @@ openclaw doctor
 
 Що перевірити:
 
-- Очікувані підтвердження пристроїв для dashboard/nodes.
-- Очікувані підтвердження pairing у DM після змін політики або identity.
+- Очікують схвалення пристрої для dashboard/nodes.
+- Очікують схвалення pairings у DM після змін політики або ідентичності.
 
 Поширені ознаки:
 
 - `device identity required` → вимоги device auth не виконано.
-- `pairing required` → відправника/пристрій потрібно підтвердити.
+- `pairing required` → відправника/пристрій потрібно схвалити.
 
-Якщо config сервісу і runtime після перевірок усе ще не збігаються, перевстановіть метадані сервісу з того самого каталогу profile/state:
+Якщо після перевірок конфігурація сервісу та runtime все ще не збігаються, перевстановіть метадані сервісу з того самого каталогу профілю/стану:
 
 ```bash
 openclaw gateway install --force
@@ -571,6 +575,6 @@ openclaw gateway restart
 
 ## Пов’язане
 
-- [Gateway runbook](/uk/gateway)
+- [Посібник для Gateway](/uk/gateway)
 - [Doctor](/uk/gateway/doctor)
 - [FAQ](/uk/help/faq)

docs/uk/reference/test.md

@@ -1,51 +1,51 @@
 ---
 read_when:
     - Запуск або виправлення тестів
-summary: Як запускати тести локально (vitest) і коли використовувати режими force/coverage
+summary: Як запускати тести локально (`vitest`) і коли використовувати режими force/coverage
 title: Тести
 x-i18n:
-    generated_at: "2026-04-24T05:03:56Z"
+    generated_at: "2026-04-24T07:42:14Z"
     model: gpt-5.4
     provider: openai
-    source_hash: df4ad5808ddbc06c704c9bcf9f780b06f9be94ac213ed22e79d880dedcaa6d3b
+    source_hash: 26cdb5fe005e738ddd00b183e91ccebe08c709bd64eed377d573a37b76e3a3bf
     source_path: reference/test.md
     workflow: 15
 ---
 
-- Повний набір для тестування (набори, live, Docker): [Тестування](/uk/help/testing)
+- Повний набір для тестування (набори тестів, live, Docker): [Тестування](/uk/help/testing)
 
-- `pnpm test:force`: завершує будь-який завислий процес gateway, що утримує типовий порт керування, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб серверні тести не конфліктували з уже запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив порт 18789 зайнятим.
-- `pnpm test:coverage`: запускає набір unit-тестів із покриттям V8 (через `vitest.unit.config.ts`). Це перевірка покриття unit-тестів для завантажених файлів, а не покриття всіх файлів у всьому репозиторії. Порогові значення: 70% для lines/functions/statements і 55% для branches. Оскільки `coverage.all` має значення false, перевірка оцінює файли, завантажені набором unit coverage, замість того щоб вважати всі файли вихідного коду в розділених lane-ах непокритими.
+- `pnpm test:force`: завершує будь-який завислий процес gateway, який утримує типовий порт керування, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб тести сервера не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789.
+- `pnpm test:coverage`: запускає набір unit-тестів із покриттям V8 (через `vitest.unit.config.ts`). Це поріг покриття unit-тестів для завантажених файлів, а не покриття всіх файлів у всьому репозиторії. Пороги становлять 70% для lines/functions/statements і 55% для branches. Оскільки `coverage.all` має значення false, поріг вимірює файли, завантажені набором unit coverage, замість того щоб вважати кожен файл вихідного коду з розділених lane непокритим.
 - `pnpm test:coverage:changed`: запускає unit coverage лише для файлів, змінених відносно `origin/main`.
-- `pnpm test:changed`: розгортає змінені git-шляхи в scoped Vitest lane-и, коли diff зачіпає лише routable файли коду/тестів. Зміни конфігурації/налаштування все одно повертаються до нативного запуску кореневих проєктів, щоб зміни wiring за потреби повторно запускали ширший набір.
-- `pnpm changed:lanes`: показує архітектурні lane-и, які активує diff відносно `origin/main`.
-- `pnpm check:changed`: запускає розумну перевірку змін для diff відносно `origin/main`. Вона запускає core-роботи з core test lane-ами, роботу розширень — з extension test lane-ами, зміни лише в тестах — лише з test typecheck/tests, розширює зміни публічного Plugin SDK або plugin-contract до одного проходу валідації розширень, і залишає зміни лише в release metadata version bumps на цільових перевірках version/config/root-dependency.
-- `pnpm test`: спрямовує явні цілі файлів/каталогів через scoped Vitest lane-и. Запуски без цілей використовують фіксовані групи shard-ів і розгортаються до leaf config-ів для локального паралельного виконання; група extension завжди розгортається до per-extension shard config-ів замість одного великого процесу root-project.
-- Повні запуски та запуски shard-ів розширень оновлюють локальні дані таймінгів у `.artifacts/vitest-shard-timings.json`; наступні запуски використовують ці таймінги, щоб збалансувати повільні й швидкі shard-и. Встановіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний артефакт таймінгів.
-- Вибрані тестові файли `plugin-sdk` і `commands` тепер маршрутизуються через виділені легкі lane-и, у яких залишається лише `test/setup.ts`, а важкі runtime-кейси залишаються на своїх наявних lane-ах.
-- Вибрані допоміжні файли коду `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` із явними сусідніми тестами в цих легких lane-ах, тому невеликі зміни хелперів не змушують повторно запускати важкі набори, що залежать від runtime.
-- `auto-reply` тепер також розділяється на три окремі конфігурації (`core`, `top-level`, `reply`), щоб harness reply не домінував над легшими top-level тестами status/token/helper.
+- `pnpm test:changed`: розгортає змінені git-шляхи в scoped Vitest lanes, коли diff торкається лише routable файлів вихідного коду/тестів. Зміни в config/setup усе одно повертаються до нативного запуску кореневих проєктів, щоб зміни в підключенні запускали ширший повторний прогін там, де це потрібно.
+- `pnpm changed:lanes`: показує архітектурні lanes, активовані diff відносно `origin/main`.
+- `pnpm check:changed`: запускає розумну перевірку changed для diff відносно `origin/main`. Вона запускає core-роботи разом із core test lanes, роботу розширень — разом із extension test lanes, зміни лише в тестах — лише з test typecheck/tests, розгортає зміни в публічному Plugin SDK або plugin-contract до одного проходу валідації розширень і залишає підвищення версій лише в release metadata націленими перевірками version/config/root-dependency.
+- `pnpm test`: спрямовує явні цілі file/directory через scoped Vitest lanes. Запуски без цілі використовують фіксовані shard-групи та розгортаються до leaf config для локального паралельного виконання; група extension завжди розгортається до shard config окремих extension/plugin, а не до одного великого процесу root-project.
+- Повні запуски та запуски extension shard оновлюють локальні дані таймінгу в `.artifacts/vitest-shard-timings.json`; наступні запуски використовують ці таймінги, щоб збалансувати повільні й швидкі shard. Установіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний артефакт таймінгу.
+- Вибрані тестові файли `plugin-sdk` і `commands` тепер спрямовуються через спеціальні легкі lanes, які зберігають лише `test/setup.ts`, залишаючи runtime-heavy випадки на їхніх наявних lanes.
+- Вибрані допоміжні вихідні файли `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами в цих легких lanes, щоб малі зміни в helper не примушували повторно запускати важкі набори тестів із підтримкою runtime.
+- `auto-reply` тепер також розбивається на три спеціальні config (`core`, `top-level`, `reply`), щоб harness reply не домінував над легшими top-level тестами status/token/helper.
 - Базова конфігурація Vitest тепер типово використовує `pool: "threads"` і `isolate: false`, а спільний неізольований runner увімкнено в конфігураціях усього репозиторію.
 - `pnpm test:channels` запускає `vitest.channels.config.ts`.
-- `pnpm test:extensions` і `pnpm test extensions` запускають усі shard-и extension/plugin. Важкі channel plugin-и, browser plugin і OpenAI запускаються як окремі shard-и; інші групи plugin-ів залишаються згрупованими. Використовуйте `pnpm test extensions/<id>` для одного lane bundled plugin.
-- `pnpm test:perf:imports`: вмикає звітування Vitest про тривалість імпортів і їх розбивку, водночас усе ще використовуючи маршрутизацію scoped lane-ів для явних цілей файлів/каталогів.
-- `pnpm test:perf:imports:changed`: такий самий профайлінг імпортів, але лише для файлів, змінених відносно `origin/main`.
-- `pnpm test:perf:changed:bench -- --ref <git-ref>` порівнює в режимі benchmark маршрут changed-mode із нативним запуском root-project для того самого закоміченого git diff.
-- `pnpm test:perf:changed:bench -- --worktree` порівнює поточний набір змін у worktree без попереднього коміту.
-- `pnpm test:perf:profile:main`: записує CPU profile для головного потоку Vitest (`.artifacts/vitest-main-profile`).
+- `pnpm test:extensions` і `pnpm test extensions` запускають усі shard extension/plugin. Важкі channel plugins, browser plugin і OpenAI запускаються як окремі shard; інші групи plugin залишаються згрупованими. Використовуйте `pnpm test extensions/<id>` для одного lane bundled plugin.
+- `pnpm test:perf:imports`: вмикає звітність Vitest про тривалість імпорту та деталізацію імпорту, водночас і далі використовуючи scoped lane routing для явних цілей file/directory.
+- `pnpm test:perf:imports:changed`: те саме профілювання імпорту, але лише для файлів, змінених відносно `origin/main`.
+- `pnpm test:perf:changed:bench -- --ref <git-ref>` порівнює за бенчмарком routed changed-mode path із нативним запуском root-project для того самого закоміченого git diff.
+- `pnpm test:perf:changed:bench -- --worktree` порівнює за бенчмарком поточний набір змін у worktree без попереднього коміту.
+- `pnpm test:perf:profile:main`: записує CPU profile для основного потоку Vitest (`.artifacts/vitest-main-profile`).
 - `pnpm test:perf:profile:runner`: записує CPU + heap profiles для unit runner (`.artifacts/vitest-runner-profile`).
-- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: послідовно запускає кожну leaf config повного набору Vitest і записує згруповані дані тривалості разом із JSON/лог-артефактами для кожної конфігурації. Test Performance Agent використовує це як базову лінію перед спробами виправити повільні тести.
-- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: порівнює згруповані звіти після зміни, зосередженої на продуктивності.
-- Інтеграція Gateway: вмикається явно через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
-- `pnpm test:e2e`: запускає наскрізні smoke-тести gateway (парування multi-instance WS/HTTP/node). Типово використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=<n>` і встановлюйте `OPENCLAW_E2E_VERBOSE=1` для докладних логів.
-- `pnpm test:live`: запускає live-тести провайдерів (minimax/zai). Потрібні API-ключі та `LIVE=1` (або специфічний для провайдера `*_LIVE_TEST=1`) для зняття skip.
-- `pnpm test:docker:all`: один раз збирає спільний образ live-тестів і Docker E2E image, а потім запускає Docker smoke lane-и з `OPENCLAW_SKIP_DOCKER_BUILD=1` із типовим рівнем паралелізму 8. Налаштовуйте основний пул через `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>`, а хвостовий пул, чутливий до провайдера, через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>`; обидва типово мають значення 8. Runner припиняє планувати нові lane-и в пулі після першої помилки, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, а для кожного lane діє тайм-аут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Логи для кожного lane записуються в `.artifacts/docker-tests/<run-id>/`.
-- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, входить через Open WebUI, перевіряє `/api/models`, а потім виконує реальний проксійований чат через `/api/chat/completions`. Потрібен робочий ключ live model (наприклад, OpenAI у `~/.profile`), завантажується зовнішній образ Open WebUI, і цей сценарій не очікується стабільним у CI так, як звичайні набори unit/e2e.
-- `pnpm test:docker:mcp-channels`: запускає контейнер Gateway із попереднім заповненням і другий клієнтський контейнер, який піднімає `openclaw mcp serve`, а потім перевіряє виявлення маршрутизованих розмов, читання transcript, метадані вкладень, поведінку черги live-подій, маршрутизацію outbound send, а також сповіщення про channel і permission у стилі Claude через реальний stdio bridge. Перевірка сповіщень Claude читає сирі stdio MCP frames безпосередньо, щоб smoke-тест відображав те, що міст насправді надсилає.
+- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: послідовно запускає кожну leaf config повного набору Vitest і записує згруповані дані тривалості плюс JSON/log артефакти для кожної config. Агент продуктивності тестів використовує це як baseline перед спробами виправити повільні тести.
+- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: порівнює згруповані звіти після змін, спрямованих на продуктивність.
+- Інтеграція Gateway: вмикається через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
+- `pnpm test:e2e`: запускає smoke-тести end-to-end для gateway (парування кількох екземплярів WS/HTTP/node). Типово використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовується через `OPENCLAW_E2E_WORKERS=<n>`, а для докладних логів установіть `OPENCLAW_E2E_VERBOSE=1`.
+- `pnpm test:live`: запускає live-тести провайдерів (minimax/zai). Потрібні API-ключі та `LIVE=1` (або специфічний для провайдера `*_LIVE_TEST=1`), щоб зняти пропуск.
+- `pnpm test:docker:all`: один раз збирає спільний образ live-test і образ Docker E2E, а потім запускає Docker smoke lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1` з типовим рівнем паралелізму 8. Налаштовуйте основний пул через `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` і чутливий до провайдера хвостовий пул через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>`; обидва типово дорівнюють 8. Запуски lanes типово зміщуються на 2 секунди, щоб уникнути локальних штормів створення в Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. Runner припиняє планувати нові pooled lanes після першої помилки, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, і кожен lane має тайм-аут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`. Логи для кожного lane записуються в `.artifacts/docker-tests/<run-id>/`.
+- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, входить через Open WebUI, перевіряє `/api/models`, а потім запускає реальний проксійований чат через `/api/chat/completions`. Потрібен придатний ключ live model (наприклад, OpenAI у `~/.profile`), завантажується зовнішній образ Open WebUI, і стабільність у CI тут не очікується такою самою, як для звичайних unit/e2e наборів.
+- `pnpm test:docker:mcp-channels`: запускає контейнер Gateway із підготовленими даними та другий клієнтський контейнер, який запускає `openclaw mcp serve`, а потім перевіряє виявлення routed conversation, читання transcript, метадані вкладень, поведінку черги live events, маршрутизацію outbound send, а також сповіщення про channel і permissions у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає сирі stdio MCP frames безпосередньо, тож smoke відображає те, що міст фактично надсилає.
 
 ## Локальна PR-перевірка
 
-Для локальних перевірок перед злиттям/gate PR запускайте:
+Для локальних перевірок перед злиттям/проходженням PR виконайте:
 
 - `pnpm check:changed`
 - `pnpm check`
@@ -54,7 +54,7 @@ x-i18n:
 - `pnpm test`
 - `pnpm check:docs`
 
-Якщо `pnpm test` дає flaky-результат на навантаженому хості, повторіть запуск один раз, перш ніж вважати це регресією, а потім ізолюйте через `pnpm test <path/to/test>`. Для хостів з обмеженою пам’яттю використовуйте:
+Якщо `pnpm test` дає flaky-результат на завантаженій машині, перезапустіть один раз, перш ніж вважати це регресією, а потім ізолюйте через `pnpm test <path/to/test>`. Для машин з обмеженнями пам’яті використовуйте:
 
 - `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test`
 - `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed`
@@ -66,10 +66,10 @@ x-i18n:
 Використання:
 
 - `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
-- Необов’язкові змінні середовища: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
-- Типовий prompt: “Reply with a single word: ok. No punctuation or extra text.”
+- Необов’язкові env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
+- Типовий prompt: “Відповідай одним словом: ok. Без розділових знаків або додаткового тексту.”
 
-Останній запуск (2025-12-31, 20 runs):
+Останній запуск (2025-12-31, 20 запусків):
 
 - minimax median 1279ms (min 1114, max 2431)
 - opus median 2454ms (min 1224, max 3170)
@@ -95,41 +95,41 @@ x-i18n:
 - `pnpm tsx scripts/bench-cli-startup.ts --preset real --cpu-prof-dir .artifacts/cli-cpu`
 - `pnpm tsx scripts/bench-cli-startup.ts --json`
 
-Presets:
+Набори preset:
 
 - `startup`: `--version`, `--help`, `health`, `health --json`, `status --json`, `status`
 - `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port`
-- `all`: обидва presets
+- `all`: обидва preset
 
-Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують V8 profiles для кожного запуску, тож вимірювання часу й захоплення профілів використовують той самий harness.
+Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують V8 profiles для кожного запуску, тож вимірювання часу й збирання profiles використовують один і той самий harness.
 
-Умовні позначення для збереженого виводу:
+Угоди щодо збережених результатів:
 
-- `pnpm test:startup:bench:smoke` записує артефакт цільового smoke у `.artifacts/cli-startup-bench-smoke.json`
-- `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json` з `runs=5` і `warmup=1`
-- `pnpm test:startup:bench:update` оновлює закомічений baseline fixture у `test/fixtures/cli-startup-bench.json` з `runs=5` і `warmup=1`
+- `pnpm test:startup:bench:smoke` записує цільовий smoke artifact у `.artifacts/cli-startup-bench-smoke.json`
+- `pnpm test:startup:bench:save` записує artifact повного набору в `.artifacts/cli-startup-bench-all.json` з `runs=5` і `warmup=1`
+- `pnpm test:startup:bench:update` оновлює зафіксований у репозиторії baseline fixture у `test/fixtures/cli-startup-bench.json` з `runs=5` і `warmup=1`
 
-Закомічений fixture:
+Зафіксований у репозиторії fixture:
 
 - `test/fixtures/cli-startup-bench.json`
-- Оновлення: `pnpm test:startup:bench:update`
-- Порівняння поточних результатів із fixture: `pnpm test:startup:bench:check`
+- Оновлення через `pnpm test:startup:bench:update`
+- Порівняння поточних результатів із fixture через `pnpm test:startup:bench:check`
 
 ## Onboarding E2E (Docker)
 
-Docker необов’язковий; це потрібно лише для контейнеризованих onboarding smoke-тестів.
+Docker не є обов’язковим; це потрібно лише для контейнеризованих smoke-тестів onboarding.
 
-Повний cold-start flow у чистому Linux-контейнері:
+Повний cold-start сценарій у чистому Linux-контейнері:
 
 ```bash
 scripts/e2e/onboard-docker.sh
 ```
 
-Цей скрипт керує інтерактивним майстром через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`.
+Цей скрипт проходить інтерактивний майстер через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`.
 
-## Smoke-тест QR-імпорту (Docker)
+## Smoke-тест імпорту QR (Docker)
 
-Гарантує, що підтримуваний допоміжний QR runtime коректно завантажується в підтримуваних Docker Node runtime-ах (типово Node 24, сумісний Node 22):
+Гарантує, що підтримуваний QR runtime helper завантажується в підтримуваних Node runtime у Docker (типово Node 24, сумісність із Node 22):
 
 ```bash
 pnpm test:docker:qr

docs/uk/tools/browser.md

@@ -1,15 +1,15 @@
 ---
 read_when:
     - Додавання автоматизації браузера, керованої агентом
-    - Налагодження того, чому openclaw заважає роботі вашого власного Chrome
+    - Налагодження, чому openclaw заважає вашому власному Chrome
     - Реалізація налаштувань браузера + життєвого циклу в застосунку macOS
-summary: Інтегрований сервіс керування браузером + команди дій
+summary: Інтегрована служба керування браузером + команди дій
 title: Браузер (керований OpenClaw)
 x-i18n:
-    generated_at: "2026-04-24T02:43:43Z"
+    generated_at: "2026-04-24T07:42:12Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 2fb0fc0b6235fa8a0324b754e247e015d5ca19d114d324d565ed4a19f9313f7e
+    source_hash: 80805676213ef5195093163874a848955b3c25364b20045a8d759d03ac088e14
     source_path: tools/browser.md
     workflow: 15
 ---
@@ -21,19 +21,19 @@ OpenClaw може запускати **виділений профіль Chrome/
 Погляд для початківців:
 
 - Думайте про це як про **окремий браузер лише для агента**.
-- Профіль `openclaw` **не** торкається вашого особистого профілю браузера.
+- Профіль `openclaw` **не** торкається профілю вашого особистого браузера.
 - Агент може **відкривати вкладки, читати сторінки, натискати й вводити текст** у безпечному середовищі.
-- Вбудований профіль `user` підключається до вашої справжньої сесії Chrome із входом через Chrome MCP.
+- Вбудований профіль `user` підключається до вашої реальної сесії Chrome з входом через Chrome MCP.
 
 ## Що ви отримуєте
 
-- Окремий профіль браузера з назвою **openclaw** (помаранчевий акцент за замовчуванням).
-- Детерміноване керування вкладками (список/відкрити/перемкнути/закрити).
-- Дії агента (натискання/введення/перетягування/вибір), знімки, знімки екрана, PDF.
+- Окремий профіль браузера з назвою **openclaw** (типово з помаранчевим акцентом).
+- Детерміноване керування вкладками (перелік/відкриття/фокус/закриття).
+- Дії агента (клік/введення/перетягування/вибір), знімки стану, скриншоти, PDF.
 - Необов’язкову підтримку кількох профілів (`openclaw`, `work`, `remote`, ...).
 
-Цей браузер **не** є вашим щоденним браузером. Це безпечне, ізольоване середовище для
-автоматизації та перевірки агентом.
+Цей браузер **не** є вашим основним щоденним браузером. Це безпечна, ізольована поверхня для
+автоматизації та перевірки з боку агента.
 
 ## Швидкий старт
 
@@ -47,12 +47,12 @@ openclaw browser --browser-profile openclaw snapshot
 Якщо ви бачите “Browser disabled”, увімкніть це в конфігурації (див. нижче) і перезапустіть
 Gateway.
 
-Якщо `openclaw browser` повністю відсутній або агент повідомляє, що інструмент браузера
+Якщо `openclaw browser` взагалі відсутній або агент каже, що інструмент браузера
 недоступний, перейдіть до [Відсутня команда браузера або інструмент](/uk/tools/browser#missing-browser-command-or-tool).
 
 ## Керування Plugin
 
-Інструмент `browser` за замовчуванням є вбудованим Plugin. Вимкніть його, щоб замінити іншим Plugin, який реєструє ту саму назву інструмента `browser`:
+Типовий інструмент `browser` — це вбудований Plugin. Вимкніть його, щоб замінити іншим Plugin, який реєструє ту саму назву інструмента `browser`:
 
 ```json5
 {
@@ -66,13 +66,13 @@ Gateway.
 }
 ```
 
-Для значень за замовчуванням потрібні і `plugins.entries.browser.enabled`, і `browser.enabled=true`. Вимкнення лише Plugin прибирає CLI `openclaw browser`, метод Gateway `browser.request`, інструмент агента та сервіс керування як єдиний блок; ваша конфігурація `browser.*` залишається недоторканою для заміни.
+Для типових значень потрібні і `plugins.entries.browser.enabled`, і `browser.enabled=true`. Вимкнення лише Plugin прибирає CLI `openclaw browser`, метод Gateway `browser.request`, інструмент агента та сервіс керування як єдине ціле; ваш конфіг `browser.*` залишається недоторканим для заміни.
 
-Зміни конфігурації браузера вимагають перезапуску Gateway, щоб Plugin міг повторно зареєструвати свій сервіс.
+Зміни конфігурації браузера потребують перезапуску Gateway, щоб Plugin міг повторно зареєструвати свій сервіс.
 
 ## Відсутня команда браузера або інструмент
 
-Якщо `openclaw browser` невідомий після оновлення, відсутній `browser.request` або агент повідомляє, що інструмент браузера недоступний, типовою причиною є список `plugins.allow`, у якому немає `browser`. Додайте його:
+Якщо `openclaw browser` невідомий після оновлення, `browser.request` відсутній або агент повідомляє, що інструмент браузера недоступний, зазвичай причина — список `plugins.allow`, у якому немає `browser`. Додайте його:
 
 ```json5
 {
@@ -82,26 +82,26 @@ Gateway.
 }
 ```
 
-`browser.enabled=true`, `plugins.entries.browser.enabled=true` і `tools.alsoAllow: ["browser"]` не замінюють членство в allowlist — allowlist контролює завантаження Plugin, а політика інструментів застосовується лише після завантаження. Повне видалення `plugins.allow` також відновлює значення за замовчуванням.
+`browser.enabled=true`, `plugins.entries.browser.enabled=true` і `tools.alsoAllow: ["browser"]` не замінюють членство в allowlist — allowlist керує завантаженням Plugin, а політика інструментів застосовується лише після завантаження. Видалення `plugins.allow` повністю також відновлює типову поведінку.
 
-## Профілі: `openclaw` проти `user`
+## Профілі: `openclaw` vs `user`
 
 - `openclaw`: керований, ізольований браузер (розширення не потрібне).
-- `user`: вбудований профіль підключення Chrome MCP для вашої **справжньої сесії Chrome**
-  із входом.
+- `user`: вбудований профіль підключення Chrome MCP до вашої **реальної сесії Chrome**
+  з входом.
 
 Для викликів інструмента браузера агентом:
 
-- За замовчуванням: використовується ізольований браузер `openclaw`.
-- Віддавайте перевагу `profile="user"`, коли важливі наявні сеанси з входом і користувач
-  перебуває за комп’ютером, щоб натиснути/схвалити будь-який запит на підключення.
+- Типово: використовувати ізольований браузер `openclaw`.
+- Віддавайте перевагу `profile="user"`, коли важливі наявні сесії з входом і користувач
+  знаходиться за комп’ютером, щоб натиснути/підтвердити будь-який запит на підключення.
 - `profile` — це явне перевизначення, коли вам потрібен конкретний режим браузера.
 
-Встановіть `browser.defaultProfile: "openclaw"`, якщо хочете, щоб керований режим був типовим.
+Установіть `browser.defaultProfile: "openclaw"`, якщо хочете, щоб керований режим був типовим.
 
 ## Конфігурація
 
-Налаштування браузера зберігаються в `~/.openclaw/openclaw.json`.
+Налаштування браузера містяться в `~/.openclaw/openclaw.json`.
 
 ```json5
 {
@@ -146,45 +146,45 @@ Gateway.
 
 <Accordion title="Порти та доступність">
 
-- Сервіс керування прив’язується до loopback на порту, похідному від `gateway.port` (за замовчуванням `18791` = gateway + 2). Перевизначення `gateway.port` або `OPENCLAW_GATEWAY_PORT` зміщує похідні порти в тій самій групі.
-- Локальні профілі `openclaw` автоматично призначають `cdpPort`/`cdpUrl`; задавайте їх лише для віддаленого CDP. Якщо `cdpUrl` не задано, за замовчуванням використовується керований локальний порт CDP.
-- `remoteCdpTimeoutMs` застосовується до перевірок доступності HTTP віддаленого (не-loopback) CDP; `remoteCdpHandshakeTimeoutMs` застосовується до рукопотискань WebSocket віддаленого CDP.
+- Сервіс керування прив’язується до loopback на порту, похідному від `gateway.port` (типово `18791` = gateway + 2). Перевизначення `gateway.port` або `OPENCLAW_GATEWAY_PORT` зсуває похідні порти в тій самій групі.
+- Локальні профілі `openclaw` автоматично призначають `cdpPort`/`cdpUrl`; задавайте їх лише для віддаленого CDP. Якщо `cdpUrl` не задано, типово використовується керований локальний CDP-порт.
+- `remoteCdpTimeoutMs` застосовується до перевірок доступності HTTP для віддаленого (не-loopback) CDP; `remoteCdpHandshakeTimeoutMs` застосовується до WebSocket handshake віддаленого CDP.
 
 </Accordion>
 
 <Accordion title="Політика SSRF">
 
-- Навігація браузера та відкриття вкладок захищені від SSRF перед навігацією і повторно перевіряються, наскільки це можливо, на фінальному URL `http(s)` після неї.
-- У строгому режимі SSRF також перевіряються виявлення кінцевих точок віддаленого CDP і запити `/json/version` (`cdpUrl`).
-- `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` вимкнено за замовчуванням; вмикайте лише тоді, коли доступ браузера до приватної мережі навмисно вважається довіреним.
-- `browser.ssrfPolicy.allowPrivateNetwork` залишається підтримуваним як застарілий псевдонім.
+- Навігація браузера та відкриття вкладок захищені від SSRF перед навігацією та, наскільки можливо, повторно перевіряються на фінальному URL `http(s)` після неї.
+- У строгому режимі SSRF також перевіряються виявлення віддалених CDP-ендпойнтів і запити `/json/version` (`cdpUrl`).
+- `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` типово вимкнено; вмикайте лише тоді, коли доступ браузера до приватної мережі свідомо вважається довіреним.
+- `browser.ssrfPolicy.allowPrivateNetwork` залишається підтримуваним як застарілий синонім.
 
 </Accordion>
 
-<Accordion title="Поведінка профілю">
+<Accordion title="Поведінка профілів">
 
-- `attachOnly: true` означає ніколи не запускати локальний браузер; лише підключатися, якщо він уже запущений.
+- `attachOnly: true` означає ніколи не запускати локальний браузер; лише підключатися, якщо він уже працює.
 - `color` (на верхньому рівні та для кожного профілю) тонує інтерфейс браузера, щоб ви могли бачити, який профіль активний.
-- Профіль за замовчуванням — `openclaw` (керований автономний). Використайте `defaultProfile: "user"`, щоб перейти на браузер користувача з входом.
-- Порядок автовиявлення: системний браузер за замовчуванням, якщо він заснований на Chromium; інакше Chrome → Brave → Edge → Chromium → Chrome Canary.
+- Типовий профіль — `openclaw` (керований автономний). Використовуйте `defaultProfile: "user"`, щоб вибрати браузер користувача з входом.
+- Порядок автовиявлення: системний браузер за замовчуванням, якщо він на базі Chromium; інакше Chrome → Brave → Edge → Chromium → Chrome Canary.
 - `driver: "existing-session"` використовує Chrome DevTools MCP замість сирого CDP. Не задавайте `cdpUrl` для цього драйвера.
-- Задайте `browser.profiles.<name>.userDataDir`, коли профіль existing-session має підключатися до нестандартного профілю користувача Chromium (Brave, Edge тощо).
+- Установіть `browser.profiles.<name>.userDataDir`, коли профіль existing-session має підключатися до нестандартного профілю користувача Chromium (Brave, Edge тощо).
 
 </Accordion>
 
 </AccordionGroup>
 
-## Використання Brave (або іншого браузера на основі Chromium)
+## Використання Brave (або іншого браузера на базі Chromium)
 
-Якщо вашим **системним браузером за замовчуванням** є браузер на основі Chromium (Chrome/Brave/Edge тощо),
-OpenClaw використовує його автоматично. Задайте `browser.executablePath`, щоб перевизначити
+Якщо вашим **системним браузером за замовчуванням** є браузер на базі Chromium (Chrome/Brave/Edge тощо),
+OpenClaw автоматично використовує його. Установіть `browser.executablePath`, щоб перевизначити
 автовиявлення:
 
 ```bash
 openclaw config set browser.executablePath "/usr/bin/google-chrome"
 ```
 
-Або задайте його в конфігурації, для кожної платформи окремо:
+Або задайте це в конфігурації для кожної платформи:
 
 <Tabs>
   <Tab title="macOS">
@@ -218,41 +218,41 @@ openclaw config set browser.executablePath "/usr/bin/google-chrome"
 
 ## Локальне та віддалене керування
 
-- **Локальне керування (за замовчуванням):** Gateway запускає loopback-сервіс керування і може запустити локальний браузер.
-- **Віддалене керування (вузол-host):** запустіть вузол-host на машині, де є браузер; Gateway проксуватиме до нього дії браузера.
-- **Віддалений CDP:** задайте `browser.profiles.<name>.cdpUrl` (або `browser.cdpUrl`), щоб
-  підключитися до віддаленого браузера на основі Chromium. У цьому випадку OpenClaw не запускатиме локальний браузер.
+- **Локальне керування (типово):** Gateway запускає loopback-сервіс керування і може запускати локальний браузер.
+- **Віддалене керування (хост вузла):** запустіть хост вузла на машині, де є браузер; Gateway проксіює до нього дії браузера.
+- **Віддалений CDP:** установіть `browser.profiles.<name>.cdpUrl` (або `browser.cdpUrl`), щоб
+  підключитися до віддаленого браузера на базі Chromium. У такому разі OpenClaw не запускатиме локальний браузер.
 
-Поведінка під час зупинки відрізняється залежно від режиму профілю:
+Поведінка зупинки відрізняється залежно від режиму профілю:
 
 - локальні керовані профілі: `openclaw browser stop` зупиняє процес браузера, який
   запустив OpenClaw
-- профілі лише для підключення та профілі віддаленого CDP: `openclaw browser stop` закриває активний
-  сеанс керування та скидає перевизначення емуляції Playwright/CDP (viewport,
+- профілі лише для підключення та профілі віддаленого CDP: `openclaw browser stop` закриває активну
+  сесію керування і скидає перевизначення емуляції Playwright/CDP (viewport,
   колірну схему, локаль, часовий пояс, офлайн-режим та подібний стан), навіть
-  якщо жоден процес браузера не був запущений OpenClaw
+  якщо OpenClaw не запускав жодного процесу браузера
 
 URL віддаленого CDP можуть містити автентифікацію:
 
 - Токени запиту (наприклад, `https://provider.example?token=<token>`)
 - HTTP Basic auth (наприклад, `https://user:pass@provider.example`)
 
-OpenClaw зберігає автентифікацію під час виклику кінцевих точок `/json/*` і під час підключення
-до CDP WebSocket. Для токенів краще використовувати змінні середовища або менеджери секретів,
-а не зберігати їх у файлах конфігурації.
+OpenClaw зберігає автентифікацію під час виклику ендпойнтів `/json/*` і під час підключення
+до CDP WebSocket. Для токенів віддавайте перевагу змінним середовища або менеджерам секретів
+замість коміту їх у конфігураційні файли.
 
-## Проксі браузера вузла (zero-config за замовчуванням)
+## Node browser proxy (типово без додаткової конфігурації)
 
-Якщо ви запускаєте **вузол-host** на машині, де є ваш браузер, OpenClaw може
-автоматично маршрутизувати виклики інструмента браузера до цього вузла без додаткової конфігурації браузера.
-Це типовий шлях для віддалених Gateway.
+Якщо ви запускаєте **хост вузла** на машині, де є ваш браузер, OpenClaw може
+автоматично маршрутизувати виклики інструмента браузера до цього вузла без жодної додаткової конфігурації браузера.
+Це типовий шлях для віддалених gateway.
 
-Примітки:
+Нотатки:
 
-- Вузол-host надає доступ до свого локального сервера керування браузером через **команду проксі**.
+- Хост вузла надає доступ до свого локального сервера керування браузером через **proxy command**.
 - Профілі беруться з власної конфігурації `browser.profiles` вузла (так само, як локально).
-- `nodeHost.browserProxy.allowProfiles` є необов’язковим. Залиште його порожнім для застарілої/типової поведінки: усі налаштовані профілі залишаються доступними через проксі, включно з маршрутами створення/видалення профілів.
-- Якщо ви задаєте `nodeHost.browserProxy.allowProfiles`, OpenClaw розглядає це як межу мінімальних привілеїв: можна адресувати лише профілі з allowlist, а маршрути створення/видалення постійних профілів блокуються на поверхні проксі.
+- `nodeHost.browserProxy.allowProfiles` — необов’язковий параметр. Залиште його порожнім для застарілої/типової поведінки: усі налаштовані профілі залишаються доступними через proxy, включно з маршрутами створення/видалення профілів.
+- Якщо ви задаєте `nodeHost.browserProxy.allowProfiles`, OpenClaw розглядає це як межу мінімальних привілеїв: можна адресувати лише профілі з allowlist, а маршрути створення/видалення постійних профілів блокуються на поверхні proxy.
 - Вимкніть це, якщо воно вам не потрібне:
   - На вузлі: `nodeHost.browserProxy.enabled=false`
   - На gateway: `gateway.nodes.browser.mode="off"`
@@ -283,41 +283,41 @@ URL підключення CDP через HTTPS і WebSocket. OpenClaw може
 }
 ```
 
-Примітки:
+Нотатки:
 
-- Замініть `<BROWSERLESS_API_KEY>` на ваш справжній токен Browserless.
-- Виберіть кінцеву точку регіону, яка відповідає вашому обліковому запису Browserless (див. їхню документацію).
+- Замініть `<BROWSERLESS_API_KEY>` на ваш реальний токен Browserless.
+- Виберіть регіональний ендпойнт, який відповідає вашому обліковому запису Browserless (див. їхню документацію).
 - Якщо Browserless надає вам базовий URL HTTPS, ви можете або перетворити його на
   `wss://` для прямого підключення CDP, або залишити URL HTTPS і дозволити OpenClaw
   виявити `/json/version`.
 
-## Постачальники прямого WebSocket CDP
+## Провайдери прямого WebSocket CDP
 
-Деякі хостингові сервіси браузерів надають **пряму кінцеву точку WebSocket**, а не
-стандартне HTTP-виявлення CDP (`/json/version`). OpenClaw приймає три форми
-URL CDP і автоматично вибирає правильну стратегію підключення:
+Деякі хостингові браузерні сервіси надають **прямий ендпойнт WebSocket** замість
+стандартного виявлення CDP на основі HTTP (`/json/version`). OpenClaw приймає три
+форми URL CDP і автоматично вибирає правильну стратегію підключення:
 
-- **HTTP(S)-виявлення** — `http://host[:port]` або `https://host[:port]`.
+- **Виявлення HTTP(S)** — `http://host[:port]` або `https://host[:port]`.
   OpenClaw викликає `/json/version`, щоб виявити URL WebSocket debugger, а потім
-  підключається. Без резервного варіанта WebSocket.
-- **Прямі кінцеві точки WebSocket** — `ws://host[:port]/devtools/<kind>/<id>` або
+  підключається. Резервного переходу на WebSocket немає.
+- **Прямі ендпойнти WebSocket** — `ws://host[:port]/devtools/<kind>/<id>` або
   `wss://...` зі шляхом `/devtools/browser|page|worker|shared_worker|service_worker/<id>`.
-  OpenClaw підключається напряму через рукопотискання WebSocket і повністю пропускає
+  OpenClaw підключається безпосередньо через WebSocket handshake і повністю пропускає
   `/json/version`.
-- **Кореневі bare WebSocket** — `ws://host[:port]` або `wss://host[:port]` без
+- **Кореневі URL WebSocket без шляху** — `ws://host[:port]` або `wss://host[:port]` без
   шляху `/devtools/...` (наприклад, [Browserless](https://browserless.io),
-  [Browserbase](https://www.browserbase.com)). OpenClaw спочатку намагається
-  виконати HTTP-виявлення `/json/version` (нормалізуючи схему до `http`/`https`);
+  [Browserbase](https://www.browserbase.com)). OpenClaw спочатку пробує HTTP
+  виявлення через `/json/version` (нормалізуючи схему до `http`/`https`);
   якщо виявлення повертає `webSocketDebuggerUrl`, він використовується, інакше OpenClaw
-  повертається до прямого рукопотискання WebSocket на bare-корені. Це дозволяє
-  bare `ws://`, спрямованому на локальний Chrome, усе одно підключатися, оскільки Chrome
-  приймає оновлення WebSocket лише на конкретному шляху для цілі з
+  переходить до прямого WebSocket handshake на корені без шляху. Це дозволяє
+  підключатися навіть bare `ws://`, спрямованому на локальний Chrome, оскільки Chrome приймає
+  WebSocket upgrade лише на конкретному шляху для цілі з
   `/json/version`.
 
 ### Browserbase
 
 [Browserbase](https://www.browserbase.com) — це хмарна платформа для запуску
-headless-браузерів із вбудованим розв’язанням CAPTCHA, stealth mode і residential
+headless-браузерів із вбудованим розв’язанням CAPTCHA, stealth mode та residential
 proxy.
 
 ```json5
@@ -337,82 +337,81 @@ proxy.
 }
 ```
 
-Примітки:
+Нотатки:
 
 - [Зареєструйтеся](https://www.browserbase.com/sign-up) і скопіюйте свій **API Key**
   з [панелі Overview](https://www.browserbase.com/overview).
-- Замініть `<BROWSERBASE_API_KEY>` на свій справжній API key Browserbase.
-- Browserbase автоматично створює сеанс браузера під час WebSocket-підключення, тому
-  окремий крок ручного створення сеансу не потрібен.
-- Безкоштовний тариф дозволяє один одночасний сеанс і одну браузерну годину на місяць.
-  Обмеження платних планів дивіться в [pricing](https://www.browserbase.com/pricing).
-- Повну довідку щодо API,
-  посібники SDK та приклади інтеграції дивіться в [документації Browserbase](https://docs.browserbase.com).
+- Замініть `<BROWSERBASE_API_KEY>` на ваш реальний API key Browserbase.
+- Browserbase автоматично створює сесію браузера під час підключення WebSocket, тому
+  крок ручного створення сесії не потрібен.
+- Безкоштовний тариф дозволяє одну одночасну сесію та одну годину браузера на місяць.
+  Ліміти платних планів дивіться в [pricing](https://www.browserbase.com/pricing).
+- Повний довідник API, посібники з SDK та приклади інтеграції дивіться в [документації Browserbase](https://docs.browserbase.com).
 
 ## Безпека
 
 Ключові ідеї:
 
-- Керування браузером доступне лише через loopback; доступ проходить через автентифікацію Gateway або сполучення вузлів.
+- Керування браузером доступне лише через loopback; доступ проходить через автентифікацію Gateway або pairing з вузлом.
 - Автономний loopback HTTP API браузера використовує **лише автентифікацію зі спільним секретом**:
-  bearer-автентифікацію токеном gateway, `x-openclaw-password` або HTTP Basic auth із
+  bearer auth через токен gateway, `x-openclaw-password` або HTTP Basic auth із
   налаштованим паролем gateway.
-- Заголовки ідентифікації Tailscale Serve і `gateway.auth.mode: "trusted-proxy"`
+- Заголовки ідентичності Tailscale Serve та `gateway.auth.mode: "trusted-proxy"`
   **не** автентифікують цей автономний loopback API браузера.
-- Якщо керування браузером увімкнено, але автентифікацію зі спільним секретом не налаштовано, OpenClaw
-  автоматично генерує `gateway.auth.token` під час запуску й зберігає його в конфігурації.
-- OpenClaw **не** генерує цей токен автоматично, якщо `gateway.auth.mode` уже має значення
+- Якщо керування браузером увімкнене й не налаштовано автентифікацію зі спільним секретом, OpenClaw
+  автоматично генерує `gateway.auth.token` під час запуску та зберігає його в конфігурації.
+- OpenClaw **не** генерує цей токен автоматично, коли `gateway.auth.mode` уже має значення
   `password`, `none` або `trusted-proxy`.
-- Тримайте Gateway і будь-які вузли-host у приватній мережі (Tailscale); уникайте публічного доступу.
-- Вважайте URL/токени віддаленого CDP секретами; віддавайте перевагу змінним середовища або менеджеру секретів.
+- Тримайте Gateway та всі хости вузлів у приватній мережі (Tailscale); уникайте публічного доступу.
+- Ставтеся до URL/токенів віддаленого CDP як до секретів; віддавайте перевагу env vars або менеджеру секретів.
 
 Поради щодо віддаленого CDP:
 
-- За можливості віддавайте перевагу зашифрованим кінцевим точкам (HTTPS або WSS) і короткоживучим токенам.
-- Уникайте вбудовування довгоживучих токенів безпосередньо у файли конфігурації.
+- За можливості віддавайте перевагу зашифрованим ендпойнтам (HTTPS або WSS) і короткоживучим токенам.
+- Уникайте вбудовування довгоживучих токенів безпосередньо в конфігураційні файли.
 
 ## Профілі (кілька браузерів)
 
-OpenClaw підтримує кілька іменованих профілів (конфігурацій маршрутизації). Профілі можуть бути:
+OpenClaw підтримує кілька іменованих профілів (конфігурації маршрутизації). Профілі можуть бути:
 
-- **керовані OpenClaw**: виділений екземпляр браузера на основі Chromium із власним каталогом користувацьких даних + портом CDP
-- **віддалені**: явний URL CDP (браузер на основі Chromium, що працює в іншому місці)
-- **наявний сеанс**: ваш наявний профіль Chrome через автоматичне підключення Chrome DevTools MCP
+- **керовані OpenClaw**: виділений екземпляр браузера на базі Chromium із власним каталогом даних користувача + портом CDP
+- **віддалені**: явний URL CDP (браузер на базі Chromium, що працює деінде)
+- **наявна сесія**: ваш наявний профіль Chrome через автопідключення Chrome DevTools MCP
 
-Значення за замовчуванням:
+Типові значення:
 
-- Профіль `openclaw` автоматично створюється, якщо його немає.
+- Профіль `openclaw` створюється автоматично, якщо його немає.
 - Профіль `user` вбудований для підключення existing-session через Chrome MCP.
-- Профілі existing-session, крім `user`, потрібно вмикати явно; створюйте їх за допомогою `--driver existing-session`.
-- Локальні порти CDP за замовчуванням виділяються з діапазону **18800–18899**.
-- Видалення профілю переміщує його локальний каталог даних до кошика.
+- Профілі existing-session, окрім `user`, вмикаються явно; створюйте їх через `--driver existing-session`.
+- Локальні порти CDP типово виділяються з діапазону **18800–18899**.
+- Видалення профілю переміщує його локальний каталог даних до Trash.
 
-Усі кінцеві точки керування приймають `?profile=<name>`; CLI використовує `--browser-profile`.
+Усі ендпойнти керування приймають `?profile=<name>`; CLI використовує `--browser-profile`.
 
 ## Existing-session через Chrome DevTools MCP
 
-OpenClaw також може підключатися до запущеного профілю браузера на основі Chromium через
+OpenClaw також може підключатися до запущеного профілю браузера на базі Chromium через
 офіційний сервер Chrome DevTools MCP. Це повторно використовує вкладки та стан входу,
 які вже відкриті в цьому профілі браузера.
 
-Офіційні матеріали з поясненням і налаштуванням:
+Офіційні довідкові матеріали та налаштування:
 
-- [Chrome for Developers: Use Chrome DevTools MCP with your browser session](https://developer.chrome.com/blog/chrome-devtools-mcp-debug-your-browser-session)
-- [Chrome DevTools MCP README](https://github.com/ChromeDevTools/chrome-devtools-mcp)
+- [Chrome for Developers: Використання Chrome DevTools MCP із вашою сесією браузера](https://developer.chrome.com/blog/chrome-devtools-mcp-debug-your-browser-session)
+- [README Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp)
 
 Вбудований профіль:
 
 - `user`
 
-Необов’язково: створіть власний користувацький профіль existing-session, якщо хочете
-іншу назву, колір або каталог даних браузера.
+Необов’язково: створіть власний користувацький профіль existing-session, якщо вам потрібні
+інша назва, колір або каталог даних браузера.
 
-Поведінка за замовчуванням:
+Типова поведінка:
 
-- Вбудований профіль `user` використовує авто-підключення Chrome MCP, яке націлюється на
-  локальний профіль Google Chrome за замовчуванням.
+- Вбудований профіль `user` використовує автопідключення Chrome MCP, яке націлюється на
+  типовий локальний профіль Google Chrome.
 
-Використовуйте `userDataDir` для Brave, Edge, Chromium або профілю Chrome, що не є типовим:
+Використовуйте `userDataDir` для Brave, Edge, Chromium або нетипового профілю Chrome:
 
 ```json5
 {
@@ -433,7 +432,7 @@ OpenClaw також може підключатися до запущеного
 
 1. Відкрийте сторінку inspect цього браузера для віддаленого налагодження.
 2. Увімкніть віддалене налагодження.
-3. Залиште браузер запущеним і схваліть запит на підключення, коли OpenClaw підключатиметься.
+3. Залиште браузер запущеним і підтвердьте запит на підключення, коли OpenClaw під’єднається.
 
 Поширені сторінки inspect:
 
@@ -441,7 +440,7 @@ OpenClaw також може підключатися до запущеного
 - Brave: `brave://inspect/#remote-debugging`
 - Edge: `edge://inspect/#remote-debugging`
 
-Smoke-тест live attach:
+Live attach smoke test:
 
 ```bash
 openclaw browser --browser-profile user start
@@ -450,58 +449,58 @@ openclaw browser --browser-profile user tabs
 openclaw browser --browser-profile user snapshot --format ai
 ```
 
-Ознаки успіху:
+Як виглядає успіх:
 
 - `status` показує `driver: existing-session`
 - `status` показує `transport: chrome-mcp`
 - `status` показує `running: true`
-- `tabs` показує список ваших уже відкритих вкладок браузера
-- `snapshot` повертає ref із вибраної живої вкладки
+- `tabs` перелічує вже відкриті вкладки браузера
+- `snapshot` повертає ref з вибраної live-вкладки
 
 Що перевірити, якщо підключення не працює:
 
-- цільовий браузер на основі Chromium має версію `144+`
-- у сторінці inspect цього браузера ввімкнено віддалене налагодження
-- браузер показав запит на згоду на підключення, і ви його прийняли
-- `openclaw doctor` переносить стару конфігурацію браузера на основі розширення та перевіряє,
-  що Chrome локально встановлено для типових профілів авто-підключення, але він не може
-  увімкнути віддалене налагодження на боці браузера за вас
+- цільовий браузер на базі Chromium має версію `144+`
+- віддалене налагодження увімкнене на сторінці inspect цього браузера
+- браузер показав запит на підключення, і ви його підтвердили
+- `openclaw doctor` переносить стару конфігурацію браузера на основі розширення та перевіряє, що
+  Chrome встановлено локально для типових профілів автопідключення, але він не може
+  увімкнути віддалене налагодження в браузері за вас
 
 Використання агентом:
 
-- Використовуйте `profile="user"`, коли вам потрібен браузер користувача зі станом входу.
-- Якщо ви використовуєте власний профіль existing-session, передайте явну назву цього профілю.
-- Обирайте цей режим лише тоді, коли користувач перебуває за комп’ютером, щоб схвалити
+- Використовуйте `profile="user"`, коли вам потрібен стан браузера користувача з виконаним входом.
+- Якщо ви використовуєте власний профіль existing-session, передайте його явну назву профілю.
+- Обирайте цей режим лише тоді, коли користувач перебуває за комп’ютером, щоб підтвердити
   запит на підключення.
-- Gateway або вузол-host можуть запускати `npx chrome-devtools-mcp@latest --autoConnect`
+- Gateway або хост вузла може запускати `npx chrome-devtools-mcp@latest --autoConnect`
 
-Примітки:
+Нотатки:
 
-- Цей шлях є ризикованішим за ізольований профіль `openclaw`, оскільки він може
-  працювати всередині вашої сесії браузера з виконаним входом.
+- Цей шлях є ризикованішим, ніж ізольований профіль `openclaw`, оскільки він може
+  виконувати дії у вашій сесії браузера з виконаним входом.
 - OpenClaw не запускає браузер для цього драйвера; він лише підключається.
 - Тут OpenClaw використовує офіційний потік Chrome DevTools MCP `--autoConnect`. Якщо
-  задано `userDataDir`, його буде передано далі для націлювання на цей каталог користувацьких даних.
-- Existing-session може підключатися на вибраному host або через підключений
-  вузол браузера. Якщо Chrome розміщено в іншому місці й вузол браузера не підключено, використовуйте
-  натомість віддалений CDP або вузол-host.
+  встановлено `userDataDir`, його буде передано далі для націлювання на цей каталог даних користувача.
+- Existing-session може підключатися на вибраному хості або через підключений
+  browser node. Якщо Chrome розташований деінде й browser node не підключений, використовуйте
+  натомість віддалений CDP або хост вузла.
 
 <Accordion title="Обмеження функції existing-session">
 
 Порівняно з керованим профілем `openclaw`, драйвери existing-session мають більше обмежень:
 
-- **Знімки екрана** — працюють захоплення сторінки та захоплення елемента через `--ref`; CSS-селектори `--element` не підтримуються. `--full-page` не можна поєднувати з `--ref` або `--element`. Для знімків сторінки або елемента на основі ref Playwright не потрібен.
-- **Дії** — `click`, `type`, `hover`, `scrollIntoView`, `drag` і `select` вимагають ref зі snapshot (без CSS-селекторів). `click` підтримує лише ліву кнопку. `type` не підтримує `slowly=true`; використовуйте `fill` або `press`. `press` не підтримує `delayMs`. `hover`, `scrollIntoView`, `drag`, `select`, `fill` і `evaluate` не підтримують окремі тайм-аути на виклик. `select` приймає одне значення.
-- **Очікування / завантаження файлів / діалоги** — `wait --url` підтримує точні, підрядкові та glob-шаблони; `wait --load networkidle` не підтримується. Хуки завантаження файлів вимагають `ref` або `inputRef`, по одному файлу за раз, без CSS `element`. Хуки діалогів не підтримують перевизначення тайм-ауту.
-- **Функції лише для керованого режиму** — пакетні дії, експорт PDF, перехоплення завантажень і `responsebody` усе ще вимагають шляху керованого браузера.
+- **Скриншоти** — працюють знімки сторінки та знімки елементів через `--ref`; CSS-селектори `--element` не підтримуються. `--full-page` не можна поєднувати з `--ref` або `--element`. Для скриншотів сторінки або елементів на основі ref Playwright не потрібен.
+- **Дії** — `click`, `type`, `hover`, `scrollIntoView`, `drag` і `select` потребують ref зі snapshot (без CSS-селекторів). `click` підтримує лише ліву кнопку. `type` не підтримує `slowly=true`; використовуйте `fill` або `press`. `press` не підтримує `delayMs`. `type`, `hover`, `scrollIntoView`, `drag`, `select`, `fill` та `evaluate` не підтримують тайм-аути для окремих викликів. `select` приймає одне значення.
+- **Очікування / upload / dialog** — `wait --url` підтримує точні, часткові та glob-шаблони; `wait --load networkidle` не підтримується. Хуки upload потребують `ref` або `inputRef`, по одному файлу за раз, без CSS `element`. Хуки dialog не підтримують перевизначення тайм-аутів.
+- **Функції лише для керованого режиму** — пакетні дії, експорт PDF, перехоплення завантажень і `responsebody` як і раніше потребують шляху керованого браузера.
 
 </Accordion>
 
 ## Гарантії ізоляції
 
-- **Виділений каталог користувацьких даних**: ніколи не торкається вашого особистого профілю браузера.
-- **Виділені порти**: уникає `9222`, щоб не створювати конфліктів із робочими процесами розробки.
-- **Детерміноване керування вкладками**: націлювання на вкладки за `targetId`, а не за принципом «остання вкладка».
+- **Виділений каталог даних користувача**: ніколи не торкається профілю вашого особистого браузера.
+- **Виділені порти**: уникає `9222`, щоб запобігти конфліктам із dev-процесами.
+- **Детерміноване керування вкладками**: націлювання на вкладки через `targetId`, а не через “last tab”.
 
 ## Вибір браузера
 
@@ -517,41 +516,41 @@ openclaw browser --browser-profile user snapshot --format ai
 
 Платформи:
 
-- macOS: перевіряються `/Applications` і `~/Applications`.
-- Linux: шукаються `google-chrome`, `brave`, `microsoft-edge`, `chromium` тощо.
-- Windows: перевіряються типові місця встановлення.
+- macOS: перевіряє `/Applications` і `~/Applications`.
+- Linux: шукає `google-chrome`, `brave`, `microsoft-edge`, `chromium` тощо.
+- Windows: перевіряє типові місця встановлення.
 
-## API керування (необов’язково)
+## Control API (необов’язково)
 
-Для сценаріїв і налагодження Gateway надає невеликий **HTTP API керування, доступний лише через loopback**,
-а також відповідний CLI `openclaw browser` (знімки, ref, розширені можливості wait,
-JSON-вивід, сценарії налагодження). Повну довідку дивіться в
-[API керування браузером](/uk/tools/browser-control).
+Для сценаріїв і налагодження Gateway надає невеликий **HTTP Control API лише для loopback**
+разом із відповідним CLI `openclaw browser` (знімки стану, ref, розширені можливості wait,
+вивід JSON, сценарії налагодження). Повний довідник див. у
+[Browser control API](/uk/tools/browser-control).
 
 ## Усунення несправностей
 
-Для проблем, специфічних для Linux (особливо snap Chromium), дивіться
+Для проблем, специфічних для Linux (особливо snap Chromium), див.
 [Усунення несправностей браузера](/uk/tools/browser-linux-troubleshooting).
 
-Для конфігурацій із розділеними host WSL2 Gateway + Windows Chrome дивіться
+Для конфігурацій із розділеними хостами WSL2 Gateway + Windows Chrome див.
 [WSL2 + Windows + усунення несправностей віддаленого Chrome CDP](/uk/tools/browser-wsl2-windows-remote-cdp-troubleshooting).
 
-### Помилка запуску CDP проти блокування SSRF навігації
+### Помилка запуску CDP vs блокування SSRF під час навігації
 
-Це різні класи помилок, і вони вказують на різні шляхи в коді.
+Це різні класи помилок, і вони вказують на різні шляхи виконання коду.
 
 - **Помилка запуску або готовності CDP** означає, що OpenClaw не може підтвердити, що площина керування браузером працює справно.
-- **Блокування SSRF навігації** означає, що площина керування браузером справна, але ціль навігації сторінки відхиляється політикою.
+- **Блокування SSRF під час навігації** означає, що площина керування браузером працює справно, але ціль переходу сторінки відхилена політикою.
 
 Поширені приклади:
 
 - Помилка запуску або готовності CDP:
   - `Chrome CDP websocket for profile "openclaw" is not reachable after start`
   - `Remote CDP for profile "<name>" is not reachable at <cdpUrl>`
-- Блокування SSRF навігації:
+- Блокування SSRF під час навігації:
   - потоки `open`, `navigate`, snapshot або відкриття вкладок завершуються помилкою політики браузера/мережі, тоді як `start` і `tabs` усе ще працюють
 
-Використайте цю мінімальну послідовність, щоб відрізнити одне від іншого:
+Використовуйте цю мінімальну послідовність, щоб розрізнити ці випадки:
 
 ```bash
 openclaw browser --browser-profile openclaw start
@@ -561,21 +560,21 @@ openclaw browser --browser-profile openclaw open https://example.com
 
 Як читати результати:
 
-- Якщо `start` завершується помилкою `not reachable after start`, спочатку усувайте проблему готовності CDP.
+- Якщо `start` завершується помилкою `not reachable after start`, спочатку усувайте проблеми готовності CDP.
 - Якщо `start` успішний, але `tabs` завершується помилкою, площина керування все ще несправна. Розглядайте це як проблему доступності CDP, а не проблему навігації сторінки.
 - Якщо `start` і `tabs` успішні, але `open` або `navigate` завершуються помилкою, площина керування браузером працює, а проблема в політиці навігації або цільовій сторінці.
-- Якщо `start`, `tabs` і `open` усі успішні, базовий шлях керування керованим браузером справний.
+- Якщо `start`, `tabs` і `open` усі успішні, базовий шлях керування керованим браузером працює справно.
 
 Важливі деталі поведінки:
 
-- Конфігурація браузера за замовчуванням використовує fail-closed об’єкт політики SSRF, навіть якщо ви не налаштовуєте `browser.ssrfPolicy`.
-- Для локального керованого профілю loopback `openclaw` перевірки справності CDP навмисно пропускають застосування SSRF-перевірки доступності браузера до власної локальної площини керування OpenClaw.
-- Захист навігації є окремим. Успішний результат `start` або `tabs` не означає, що пізніша ціль `open` або `navigate` буде дозволена.
+- Конфігурація браузера типово використовує fail-closed об’єкт політики SSRF, навіть якщо ви не налаштовуєте `browser.ssrfPolicy`.
+- Для локального керованого профілю `openclaw` на loopback перевірки справності CDP навмисно пропускають перевірку доступності SSRF браузера для власної локальної площини керування OpenClaw.
+- Захист навігації є окремим. Успішний результат `start` або `tabs` не означає, що подальша ціль `open` або `navigate` буде дозволена.
 
-Рекомендації щодо безпеки:
+Рекомендації з безпеки:
 
-- **Не** послаблюйте політику SSRF браузера за замовчуванням.
-- Віддавайте перевагу вузьким виняткам для host, як-от `hostnameAllowlist` або `allowedHostnames`, замість широкого доступу до приватної мережі.
+- **Не** послаблюйте політику SSRF браузера типово.
+- Віддавайте перевагу вузьким виняткам для хостів, таким як `hostnameAllowlist` або `allowedHostnames`, замість широкого доступу до приватної мережі.
 - Використовуйте `dangerouslyAllowPrivateNetwork: true` лише в навмисно довірених середовищах, де доступ браузера до приватної мережі потрібен і перевірений.
 
 ## Інструменти агента + як працює керування
@@ -584,22 +583,22 @@ openclaw browser --browser-profile openclaw open https://example.com
 
 - `browser` — status/start/stop/tabs/open/focus/close/snapshot/screenshot/navigate/act
 
-Як це зіставляється:
+Як це відображається:
 
-- `browser snapshot` повертає стабільне дерево UI (AI або ARIA).
-- `browser act` використовує ідентифікатори `ref` зі snapshot для click/type/drag/select.
+- `browser snapshot` повертає стабільне дерево інтерфейсу (AI або ARIA).
+- `browser act` використовує ID `ref` зі snapshot для click/type/drag/select.
 - `browser screenshot` захоплює пікселі (усю сторінку або елемент).
 - `browser` приймає:
-  - `profile`, щоб вибрати іменований профіль браузера (openclaw, chrome або remote CDP).
-  - `target` (`sandbox` | `host` | `node`), щоб вибрати, де знаходиться браузер.
-  - У sandbox-сеансах `target: "host"` вимагає `agents.defaults.sandbox.browser.allowHostControl=true`.
-  - Якщо `target` не задано: sandbox-сеанси за замовчуванням використовують `sandbox`, не-sandbox сеанси — `host`.
+  - `profile` для вибору іменованого профілю браузера (openclaw, chrome або віддалений CDP).
+  - `target` (`sandbox` | `host` | `node`) для вибору місця розташування браузера.
+  - У sandbox-сесіях `target: "host"` потребує `agents.defaults.sandbox.browser.allowHostControl=true`.
+  - Якщо `target` не вказано: sandbox-сесії типово використовують `sandbox`, сесії без sandbox типово використовують `host`.
   - Якщо підключено вузол із підтримкою браузера, інструмент може автоматично маршрутизуватися до нього, якщо ви явно не зафіксуєте `target="host"` або `target="node"`.
 
-Це зберігає детермінованість агента й дозволяє уникати крихких селекторів.
+Це зберігає детермінованість агента й допомагає уникати крихких селекторів.
 
 ## Пов’язане
 
 - [Огляд інструментів](/uk/tools) — усі доступні інструменти агента
-- [Ізоляція](/uk/gateway/sandboxing) — керування браузером в ізольованих середовищах
+- [Пісочниця](/uk/gateway/sandboxing) — керування браузером у sandbox-середовищах
 - [Безпека](/uk/gateway/security) — ризики керування браузером і посилення захисту