chore(i18n): refresh uk translations

docs/uk/ci.md

@@ -1,94 +1,94 @@
 ---
 read_when:
-    - Вам потрібно зрозуміти, чому завдання CI запускалося чи ні
-    - Ви налагоджуєте перевірку GitHub Actions, що не проходить
-    - Ви координуєте виконання або повторне виконання валідації релізу
+    - Вам потрібно з’ясувати, чому завдання CI виконалося або не виконалося
+    - Ви налагоджуєте перевірку GitHub Actions, що завершується помилкою
+    - Ви координуєте запуск або повторний запуск валідації релізу
     - Ви змінюєте диспетчеризацію ClawSweeper або пересилання активності GitHub
-summary: Граф завдань CI, контрольні перевірки області дії, релізні парасольки та локальні еквіваленти команд
+summary: Граф завдань CI, контрольні перевірки за областю дії, релізні парасольки та локальні еквіваленти команд
 title: CI-конвеєр
 x-i18n:
-    generated_at: "2026-05-03T12:02:04Z"
+    generated_at: "2026-05-03T12:48:06Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 5bc5d6822809e173f4fc8efc65281d6a4639be6af939bc37dd29cc7502aa99f4
+    source_hash: b5773c2ba8032ae4e35a5e0c80a9bf1d8365bb616a5156b89670b787eaff7130
     source_path: ci.md
     workflow: 16
 ---
 
-OpenClaw CI запускається на кожному push до `main` і кожному pull request. Завдання `preflight` класифікує diff і вимикає дорогі lanes, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження scope і розгортають повний граф для release candidates і широкої валідації. Android lanes залишаються opt-in через `include_android`. Покриття Plugin, призначене лише для релізів, міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається тільки з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch.
+OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі напрями, коли змінилися лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне визначення області й розгортають повний граф для release candidates і широкої валідації. Напрями Android залишаються opt-in через `include_android`. Покриття Plugin лише для релізів міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch.
 
-## Огляд конвеєра
+## Огляд pipeline
 
 | Завдання                         | Призначення                                                                                                         | Коли запускається                  |
 | -------------------------------- | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------- |
-| `preflight`                      | Виявляє зміни лише в документації, змінені scopes, змінені extensions і будує CI manifest                           | Завжди для не-draft push і PR      |
-| `security-scm-fast`              | Виявлення приватних ключів і аудит workflow через `zizmor`                                                          | Завжди для не-draft push і PR      |
-| `security-dependency-audit`      | Production-аудит lockfile без залежностей щодо npm advisories                                                       | Завжди для не-draft push і PR      |
-| `security-fast`                  | Обов’язковий aggregate для швидких security-завдань                                                                 | Завжди для не-draft push і PR      |
-| `check-dependencies`             | Production-прохід Knip лише для залежностей плюс guard allowlist невикористаних файлів                              | Зміни, релевантні для Node         |
-| `build-artifacts`                | Збірка `dist/`, Control UI, перевірки built-artifact і повторно використовувані downstream artifacts                | Зміни, релевантні для Node         |
-| `checks-fast-core`               | Швидкі Linux correctness lanes, як-от перевірки bundled/plugin-contract/protocol                                    | Зміни, релевантні для Node         |
-| `checks-fast-contracts-channels` | Sharded перевірки channel contract зі стабільним aggregate check result                                             | Зміни, релевантні для Node         |
-| `checks-node-core-test`          | Shards тестів Core Node, крім channel, bundled, contract і extension lanes                                          | Зміни, релевантні для Node         |
-| `check`                          | Sharded еквівалент головного локального gate: prod types, lint, guards, test types і strict smoke                   | Зміни, релевантні для Node         |
-| `check-additional`               | Architecture, boundary, prompt snapshot drift, extension-surface guards, package-boundary і gateway-watch shards    | Зміни, релевантні для Node         |
-| `build-smoke`                    | Built-CLI smoke tests і startup-memory smoke                                                                        | Зміни, релевантні для Node         |
-| `checks`                         | Верифікатор для built-artifact channel tests                                                                        | Зміни, релевантні для Node         |
-| `checks-node-compat-node22`      | Збірка сумісності з Node 22 і smoke lane                                                                            | Ручний CI dispatch для релізів     |
-| `check-docs`                     | Форматування документації, lint і перевірки broken-link                                                             | Документацію змінено               |
-| `skills-python`                  | Ruff + pytest для Skills на базі Python                                                                             | Зміни, релевантні для Python Skills |
-| `checks-windows`                 | Специфічні для Windows тести process/path плюс shared runtime import specifier regressions                          | Зміни, релевантні для Windows      |
-| `macos-node`                     | macOS TypeScript test lane з використанням shared built artifacts                                                   | Зміни, релевантні для macOS        |
-| `macos-swift`                    | Swift lint, build і tests для macOS app                                                                             | Зміни, релевантні для macOS        |
-| `android`                        | Android unit tests для обох flavors плюс одна збірка debug APK                                                      | Зміни, релевантні для Android      |
-| `test-performance-agent`         | Щоденна оптимізація повільних тестів Codex після довіреної активності                                               | Успіх main CI або ручний dispatch  |
-| `openclaw-performance`           | Щоденні/on-demand звіти продуктивності Kova runtime з mock-provider, deep-profile і GPT 5.4 live lanes              | Запланований і ручний dispatch     |
+| `preflight`                      | Виявляє зміни лише в docs, змінені області, змінені extensions і будує CI manifest                                  | Завжди для non-draft push і PR     |
+| `security-scm-fast`              | Виявлення приватних ключів і аудит workflow через `zizmor`                                                          | Завжди для non-draft push і PR     |
+| `security-dependency-audit`      | Аудит production lockfile без залежностей за npm advisories                                                         | Завжди для non-draft push і PR     |
+| `security-fast`                  | Обов’язковий агрегат для швидких security-завдань                                                                   | Завжди для non-draft push і PR     |
+| `check-dependencies`             | Production Knip dependency-only pass плюс guard allowlist для невикористаних файлів                                 | Зміни, релевантні Node             |
+| `build-artifacts`                | Побудова `dist/`, Control UI, перевірки built-artifact і повторно використовувані downstream artifacts              | Зміни, релевантні Node             |
+| `checks-fast-core`               | Швидкі Linux-напрями коректності, як-от перевірки bundled/plugin-contract/protocol                                  | Зміни, релевантні Node             |
+| `checks-fast-contracts-channels` | Sharded перевірки channel contract зі стабільним aggregate check result                                             | Зміни, релевантні Node             |
+| `checks-node-core-test`          | Core Node test shards, без напрямів channel, bundled, contract і extension                                          | Зміни, релевантні Node             |
+| `check`                          | Sharded еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke                   | Зміни, релевантні Node             |
+| `check-additional`               | Architecture, boundary, prompt snapshot drift, extension-surface guards, package-boundary і gateway-watch shards    | Зміни, релевантні Node             |
+| `build-smoke`                    | Built-CLI smoke tests і startup-memory smoke                                                                        | Зміни, релевантні Node             |
+| `checks`                         | Verifier для built-artifact channel tests                                                                           | Зміни, релевантні Node             |
+| `checks-node-compat-node22`      | Напрям сумісності Node 22: build і smoke                                                                            | Ручний CI dispatch для релізів     |
+| `check-docs`                     | Форматування docs, lint і перевірки broken-link                                                                     | Docs змінено                       |
+| `skills-python`                  | Ruff + pytest для Python-backed skills                                                                              | Зміни, релевантні Python-skill     |
+| `checks-windows`                 | Windows-specific process/path tests плюс shared runtime import specifier regressions                                | Зміни, релевантні Windows          |
+| `macos-node`                     | Напрям TypeScript tests для macOS із використанням спільних built artifacts                                         | Зміни, релевантні macOS            |
+| `macos-swift`                    | Swift lint, build і tests для застосунку macOS                                                                      | Зміни, релевантні macOS            |
+| `android`                        | Android unit tests для обох flavors плюс одна debug APK build                                                       | Зміни, релевантні Android          |
+| `test-performance-agent`         | Щоденна оптимізація повільних тестів Codex після trusted activity                                                   | Успіх Main CI або ручний dispatch  |
+| `openclaw-performance`           | Щоденні/on-demand звіти Kova runtime performance з напрямами mock-provider, deep-profile і GPT 5.4 live             | Запланований і ручний dispatch     |
 
-## Порядок швидкого завершення при збоях
+## Порядок fail-fast
 
-1. `preflight` вирішує, які lanes взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями.
-2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи важчих artifact і platform matrix jobs.
-3. `build-artifacts` перекривається зі швидкими Linux lanes, щоб downstream consumers могли стартувати, щойно shared build готовий.
-4. Після цього розгортаються важчі platform і runtime lanes: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `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` швидко завершуються помилкою, не чекаючи важчих jobs матриці artifacts і platform.
+3. `build-artifacts` перекривається зі швидкими Linux-напрямами, щоб downstream consumers могли стартувати, щойно спільний build буде готовий.
+4. Важчі напрями platform і runtime розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
 
-GitHub може позначати витіснені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це CI-шумом, якщо найновіший запуск для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже витіснено. Автоматичний CI concurrency key версіонований (`CI-v7-*`), щоб zombie з боку GitHub у старій queue group не міг безкінечно блокувати новіші запуски main. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують запуски, що вже виконуються.
+GitHub може позначати замінені jobs як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють нормальні shard failures, але не стають у чергу після того, як увесь workflow уже було замінено. Automatic CI concurrency key має версію (`CI-v7-*`), тож GitHub-side zombie у старій queue group не може безстроково блокувати новіші runs main. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs.
 
-## Scope і routing
+## Область і маршрутизація
 
-Логіка scope міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Ручний dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби кожна scoped area змінилася.
+Логіка області міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби змінилася кожна scoped area.
 
-- **Редагування CI workflow** валідовують Node CI graph плюс workflow linting, але самі по собі не примушують запускати Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source.
-- **Редагування лише CI routing, вибрані дешеві редагування core-test fixture і вузькі helper/test-routing редагування plugin contract** використовують швидкий Node-only manifest path: `preflight`, security і одне завдання `checks-fast-core`. Цей path пропускає build artifacts, сумісність Node 22, channel contracts, повні core shards, bundled-plugin shards і додаткові guard matrices, коли зміна обмежена routing або helper surfaces, які швидке завдання напряму вправляє.
-- **Windows Node checks** обмежені Windows-specific process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цей lane; непов’язані source, plugin, install-smoke і test-only зміни залишаються на Linux Node lanes.
+- **Редагування CI workflow** валідують Node CI graph плюс workflow linting, але самі по собі не примушують запускати Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source.
+- **Редагування лише CI routing, вибрані дешеві редагування core-test fixture і вузькі редагування plugin contract helper/test-routing** використовують швидкий Node-only manifest path: `preflight`, security і єдине завдання `checks-fast-core`. Цей шлях пропускає build artifacts, Node 22 compatibility, channel contracts, full core shards, bundled-plugin shards і additional guard matrices, коли зміна обмежена routing або helper surfaces, які швидке завдання перевіряє напряму.
+- **Windows Node checks** scoped до Windows-specific process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цей напрям; непов’язані source, plugin, install-smoke і test-only зміни залишаються на Linux Node lanes.
 
-Найповільніші сімейства Node tests розділені або збалансовані, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, малі core unit lanes поєднані попарно, auto-reply запускається як чотири збалансовані workers (з reply subtree, розділеним на shards agent-runner, dispatch і commands/state-routing), а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість спільного plugin catch-all. Include-pattern shards записують timing entries із використанням CI shard name, тому `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі independent guards паралельно в одному job, включно з `pnpm prompt:snapshots:check`, щоб Codex runtime happy-path prompt drift був прив’язаний до PR, який його спричинив. Gateway watch, channel tests і core support-boundary shard виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані.
+Найповільніші сімейства Node tests розділено або збалансовано, щоб кожне завдання залишалося невеликим без надмірного резервування runners: channel contracts запускаються як три weighted shards, малі core unit lanes попарно об’єднані, auto-reply запускається як чотири збалансовані workers (з reply subtree, розділеним на shards agent-runner, dispatch і commands/state-routing), а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Broad browser, QA, media і miscellaneous plugin tests використовують власні dedicated Vitest configs замість спільного plugin catch-all. Include-pattern shards записують timing entries із використанням CI shard name, тому `.artifacts/vitest-shard-timings.json` може відрізнити whole config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої невеликі independent guards паралельно в одному job, включно з `pnpm prompt:snapshots:check`, щоб Codex runtime happy-path prompt drift був прив’язаний до PR, який його спричинив. Gateway watch, channel tests і core support-boundary shard запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже побудовані.
 
-Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor з SMS/call-log BuildConfig flags, уникаючи дублювання debug APK packaging job на кожному Android-релевантному push.
+Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім будує Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor з прапорцями SMS/call-log BuildConfig, водночас уникаючи дублювання debug APK packaging job під час кожного Android-relevant push.
 
-Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, зафіксований на найновішій версії Knip, з вимкненим мінімальним release age pnpm для install через `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий непереглянутий unused file або залишає stale allowlist entry, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично розв’язати.
+Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, pinned до найновішої версії Knip, з вимкненим minimum release age pnpm для інсталяції `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip із `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий unreviewed unused file або залишає stale allowlist entry, зберігаючи intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може resolve статично.
 
 ## Пересилання активності ClawSweeper
 
-`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge з активності репозиторію OpenClaw до ClawSweeper. Він не checkout і не виконує недовірений код pull request. Workflow створює GitHub App token з `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім надсилає compact `repository_dispatch` payloads до `openclaw/clawsweeper`.
+`.github/workflows/clawsweeper-dispatch.yml` — це target-side bridge з активності репозиторію OpenClaw до ClawSweeper. Він не checkout і не виконує untrusted pull request code. Workflow створює GitHub App token із `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім dispatch компактні `repository_dispatch` payloads до `openclaw/clawsweeper`.
 
-Workflow має чотири lanes:
+Workflow має чотири напрями:
 
-- `clawsweeper_item` для точних запитів review issue і pull request;
+- `clawsweeper_item` для точних issue і pull request review requests;
 - `clawsweeper_comment` для явних команд ClawSweeper у issue comments;
 - `clawsweeper_commit_review` для commit-level review requests на push до `main`;
-- `github_activity` для загальної активності GitHub, яку агент ClawSweeper може inspect.
+- `github_activity` для загальної GitHub activity, яку agent ClawSweeper може inspect.
 
-Lane `github_activity` пересилає лише нормалізовані metadata: event type, action, actor, repository, item number, URL, title, state і короткі excerpts для comments або reviews, якщо вони є. Він навмисно не пересилає повне webhook body. Receiving workflow в `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який публікує нормалізовану подію в OpenClaw Gateway hook для агента ClawSweeper.
+Напрям `github_activity` пересилає лише normalized metadata: event type, action, actor, repository, item number, URL, title, state і short excerpts для comments або reviews, коли вони є. Він навмисно уникає пересилання повного webhook body. Receiving workflow у `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який публікує normalized event до OpenClaw Gateway hook для agent ClawSweeper.
 
-Загальна активність є спостереженням, а не delivery-by-default. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли подія несподівана, actionable, ризикована або операційно корисна. Routine opens, edits, bot churn, duplicate webhook noise і normal review traffic мають завершуватися `NO_REPLY`.
+General activity — це observation, а не delivery-by-default. Agent ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли подія є surprising, actionable, risky або operationally useful. Routine opens, edits, bot churn, duplicate webhook noise і normal review traffic мають завершуватися `NO_REPLY`.
 
-Ставтеся до GitHub titles, comments, bodies, review text, branch names і commit messages як до недовірених даних у всьому цьому path. Вони є input для summarization і triage, а не інструкціями для workflow або agent runtime.
+Розглядайте GitHub titles, comments, bodies, review text, branch names і commit messages як untrusted data на всьому цьому шляху. Це input для summarization і triage, а не instructions для workflow або agent runtime.
 
 ## Ручні dispatches
 
-Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну scoped lane не для Android: Linux Node shards, shards пакетних Plugin, контракти каналів, сумісність із Node 22, `check`, `check-additional`, smoke-перевірку збірки, перевірки документації, Python skills, Windows, macOS і Control UI i18n. Окремі ручні запуски CI виконують лише Android з `include_android=true`; повна release-парасолька вмикає Android, передаючи `include_android=true`. Статичні перевірки prerelease для Plugin, release-only shard `agentic-plugins`, повний batch sweep розширень і Docker lanes prerelease для Plugin вилучені з CI. Docker prerelease suite запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate release-validation.
+Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну не-Android lane у межах області: Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python skills, Windows, macOS і Control UI i18n. Окремі ручні запуски CI виконують лише Android з `include_android=true`; повна release-парасолька вмикає Android, передаючи `include_android=true`. Статичні перевірки prerelease для Plugin, release-only shard `agentic-plugins`, повний пакетний sweep розширень і Docker lanes prerelease для Plugin виключені з CI. Docker prerelease suite запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate release-validation.
 
-Ручні запуски використовують унікальну concurrency group, щоб повний suite release-candidate не скасовувався іншим запуском push або PR на тому самому ref. Необов’язковий ввід `target_ref` дає trusted caller змогу запустити цей граф для branch, tag або повного commit SHA, використовуючи workflow file з вибраного dispatch ref.
+Ручні запуски використовують унікальну concurrency group, щоб повний suite release-candidate не скасовувався іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає змогу довіреному виклику запустити цей граф для branch, tag або повного commit SHA, використовуючи workflow file з вибраного dispatch ref.
 
 ```bash
 gh workflow run ci.yml --ref release/YYYY.M.D
@@ -96,17 +96,17 @@ gh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_andro
 gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
 ```
 
-## Runners
+## Ранери
 
-| Runner                           | Завдання                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `ubuntu-24.04`                   | `preflight`, швидкі security jobs та aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled checks, sharded channel contract checks, `check` shards, крім lint, `check-additional` shards та aggregates, Node test aggregate verifiers, перевірки документації, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла стати в чергу раніше |
-| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, менш ресурсомісткі extension shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types`                                                                                                                                                                                                                                                                                                                   |
-| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, Linux Node test shards, bundled plugin test shards, `android`                                                                                                                                                                                                                                                                                                                                                                             |
-| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (достатньо чутливий до CPU, що 8 vCPU коштували більше, ніж заощаджували); install-smoke Docker builds (час очікування черги 32-vCPU коштував більше, ніж заощаджував)                                                                                                                                                                                                                                                                                       |
-| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
-| `blacksmith-6vcpu-macos-latest`  | `macos-node` на `openclaw/openclaw`; forks fallback до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                    |
-| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks fallback до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                   |
+| Ранер                            | Завдання                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `ubuntu-24.04`                   | `preflight`, швидкі security jobs і агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled checks, sharded channel contract checks, `check` shards, крім lint, `check-additional` shards і агрегати, Node test aggregate verifiers, перевірки документації, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла ставати в чергу раніше |
+| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, легші shards розширень, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types`                                                                                                                                                                                                                                                                                                                   |
+| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, Linux Node test shards, bundled plugin test shards, `android`                                                                                                                                                                                                                                                                                                                                                                           |
+| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (достатньо чутливий до CPU, тому 8 vCPU коштували більше, ніж заощаджували); install-smoke Docker builds (час черги 32-vCPU коштував більше, ніж заощаджував)                                                                                                                                                                                                                                                                                                                     |
+| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
+| `blacksmith-6vcpu-macos-latest`  | `macos-node` на `openclaw/openclaw`; forks повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                  |
+| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                 |
 
 ## Локальні відповідники
 
@@ -135,38 +135,41 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
 pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.json --output .artifacts/kova/summary.md
 ```
 
-## OpenClaw Performance
+## Продуктивність OpenClaw
 
-`OpenClaw Performance` — це workflow продуктивності product/runtime. Він запускається щодня на `main` і може запускатися вручну:
+`OpenClaw Performance` — це workflow продуктивності продукту/runtime. Він запускається щодня на `main` і може запускатися вручну:
 
 ```bash
 gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3
 gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_gpt54=true
+gh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3
 ```
 
+Ручний dispatch зазвичай бенчмаркить workflow ref. Установіть `target_ref`, щоб бенчмаркити release tag або іншу branch з поточною реалізацією workflow. Опубліковані report paths і latest pointers ключуються tested ref, а кожен `index.md` записує tested ref/SHA, workflow ref/SHA, Kova ref, profile, lane auth mode, model, repeat count і scenario filters.
+
 Workflow встановлює OCM із pinned release і Kova з `openclaw/Kova` на pinned input `kova_ref`, а потім запускає три lanes:
 
 - `mock-provider`: діагностичні сценарії Kova проти local-build runtime з deterministic fake OpenAI-compatible auth.
 - `mock-deep-profile`: CPU/heap/trace profiling для hotspots startup, gateway і agent-turn.
 - `live-gpt54`: реальний agent turn OpenAI `openai/gpt-5.4`, пропускається, коли `OPENAI_API_KEY` недоступний.
 
-Lane mock-provider також запускає OpenClaw-native source probes після проходу Kova: gateway boot timing і memory для стандартного запуску, запуску з hook та запуску з 50 Plugin; повторювані mock-OpenAI `channel-chat-baseline` hello loops; і CLI startup commands проти запущеного gateway. Markdown-зведення source probe міститься в `source/index.md` у report bundle, поруч із raw JSON.
+Lane mock-provider також запускає native для OpenClaw source probes після проходу Kova: gateway boot timing і memory для default, hook і 50-plugin startup cases; repeated mock-OpenAI `channel-chat-baseline` hello loops; і CLI startup commands проти запущеного gateway. Markdown summary source probe розташований у `source/index.md` у report bundle, поруч із raw JSON.
 
-Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і source-probe artifacts до `openclaw/clawgrit-reports` у `openclaw-performance/<ref>/<run-id>-<attempt>/<lane>/`. Поточний branch pointer записується як `openclaw-performance/<ref>/latest-<lane>.json`.
+Кожна lane завантажує GitHub artifacts. Коли `CLAWGRIT_REPORTS_TOKEN` налаштовано, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і source-probe artifacts до `openclaw/clawgrit-reports` у `openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/`. Поточний pointer tested-ref записується як `openclaw-performance/<tested-ref>/latest-<lane>.json`.
 
-## Full Release Validation
+## Повна валідація release
 
-`Full Release Validation` — це ручний umbrella workflow для «запустити все перед release». Він приймає branch, tag або повний commit SHA, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для release-only доказів plugin/package/static/Docker, а також запускає `OpenClaw Release Checks` для install smoke, package acceptance, Docker release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram lanes. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` із release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму Telegram package lane проти опублікованого npm package.
+`Full Release Validation` — це ручний umbrella workflow для «запустити все перед release». Він приймає branch, tag або повний commit SHA, запускає ручний workflow `CI` з цією target, запускає `Plugin Prerelease` для release-only plugin/package/static/Docker proof і запускає `OpenClaw Release Checks` для install smoke, package acceptance, Docker release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram lanes. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` із release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму Telegram package lane проти опублікованого npm package.
 
-Див. [Full release validation](/uk/reference/full-release-validation) для
-stage matrix, точних назв workflow jobs, відмінностей profiles, artifacts і
+Див. [Повна валідація release](/uk/reference/full-release-validation) для
+stage matrix, точних workflow job names, відмінностей profile, artifacts і
 focused rerun handles.
 
 `OpenClaw Release Publish` — це ручний mutating release workflow. Запускайте його
-з `release/YYYY.M.D` або `main` після того, як release tag існує, і після того, як
-OpenClaw npm preflight успішно завершився. Він перевіряє `pnpm plugins:sync:check`,
+з `release/YYYY.M.D` або `main` після створення release tag і після успішного
+OpenClaw npm preflight. Він перевіряє `pnpm plugins:sync:check`,
 запускає `Plugin NPM Release` для всіх publishable plugin packages, запускає
-`Plugin ClawHub Release` для того самого release SHA, і лише потім запускає
+`Plugin ClawHub Release` для того самого release SHA і лише тоді запускає
 `OpenClaw NPM Release` зі збереженим `preflight_run_id`.
 
 ```bash
@@ -177,40 +180,45 @@ gh workflow run openclaw-release-publish.yml \
   -f npm_dist_tag=beta
 ```
 
-Для доказу pinned commit на швидкозмінній branch використовуйте helper замість
+Для pinned commit proof на fast-moving branch використовуйте helper замість
 `gh workflow run ... --ref main -f ref=<sha>`:
 
 ```bash
 pnpm ci:full-release --sha <full-sha>
 ```
 
-GitHub workflow dispatch refs мають бути branches або tags, а не raw commit SHAs. Helper пушить тимчасову branch `release-ci/<sha>-...` на target SHA, запускає `Full Release Validation` з цього pinned ref, перевіряє, що `headSha` кожного child workflow збігається з target, і видаляє тимчасову branch після завершення запуску. Umbrella verifier також завершується помилкою, якщо будь-який child workflow виконувався на іншому SHA.
+GitHub workflow dispatch refs мають бути branches або tags, а не raw commit SHAs. Цей
+helper пушить тимчасову branch `release-ci/<sha>-...` на target SHA,
+запускає `Full Release Validation` з цього pinned ref, перевіряє, що кожен child
+workflow `headSha` збігається з target, і видаляє тимчасову branch після
+завершення run. Umbrella verifier також падає, якщо будь-який child workflow запускався на
+іншому SHA.
 
-`release_profile` керує широтою live/provider, що передається в release checks. Ручні release workflows за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли навмисно потрібна широка advisory provider/media matrix.
+`release_profile` керує шириною live/provider, що передається до перевірок релізу. Ручні релізні workflows за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли ви навмисно хочете широку матрицю advisory provider/media.
 
-- `minimum` залишає найшвидші OpenAI/core release-critical lanes.
-- `stable` додає стабільний provider/backend set.
-- `full` запускає широку advisory provider/media matrix.
+- `minimum` залишає найшвидші критичні для релізу лінії OpenAI/core.
+- `stable` додає стабільний набір provider/backend.
+- `full` запускає широку матрицю advisory provider/media.
 
-Umbrella записує ids запущених child runs, а фінальне завдання `Verify full validation` повторно перевіряє поточні conclusions child runs і додає tables найповільніших jobs для кожного child run. Якщо child workflow перезапущено і він став green, перезапустіть лише parent verifier job, щоб оновити результат umbrella і timing summary.
+Umbrella записує ідентифікатори запущених дочірніх прогонів, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх прогонів і додає таблиці найповільніших завдань для кожного дочірнього прогону. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське завдання verifier, щоб оновити результат umbrella і підсумок часу.
 
-Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для реліз-кандидата, `ci` лише для звичайного дочірнього повного CI, `plugin-prerelease` лише для дочірнього попереднього випуску plugin, `release-checks` для кожного дочірнього релізного завдання або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` на парасольковому запуску. Це обмежує повторний запуск збійного релізного боксу після цільового виправлення.
+Для відновлення `Full Release Validation` і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата в реліз, `ci` лише для звичайного дочірнього повного CI, `plugin-prerelease` лише для дочірнього prerelease Plugin, `release-checks` для кожного релізного дочірнього прогону або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` або `npm-telegram` в umbrella. Це обмежує перезапуск невдалого релізного box після сфокусованого виправлення.
 
-`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і workflow Docker для релізного шляху live/E2E, і shard приймання пакета. Це зберігає байти пакета узгодженими між релізними боксами й уникає перепакування того самого кандидата в кількох дочірніх завданнях.
+`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і до live/E2E Docker workflow релізного шляху, і до package acceptance shard. Це зберігає однакові байти пакета між релізними box і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
 
-Дубльовані запуски `Full Release Validation` для `ref=main` і `rerun_group=all`
-замінюють старіший парасольковий запуск. Батьківський монітор скасовує будь-який дочірній workflow, який
-він уже відправив, коли батьківський запуск скасовано, тому новіша валідація main
-не стоїть у черзі за застарілим двогодинним запуском release-check. Валідація релізних гілок/тегів
-і цільові групи повторного запуску зберігають `cancel-in-progress: false`.
+Дублікати прогонів `Full Release Validation` для `ref=main` і `rerun_group=all`
+замінюють старіший umbrella. Батьківський monitor скасовує будь-який дочірній workflow, який
+він уже запустив, коли батьківський прогін скасовано, тож новіша валідація main
+не стоїть за застарілим двогодинним прогоном release-check. Валідація релізних branch/tag
+і сфокусовані групи перезапуску зберігають `cancel-in-progress: false`.
 
-## Live та E2E шарди
+## Live та E2E shards
 
-Дочірній release live/E2E зберігає широке покриття нативного `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs`, а не як одне послідовне завдання:
+Дочірній релізний live/E2E зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані shards через `scripts/test-live-shard.mjs`, а не як одне послідовне завдання:
 
 - `native-live-src-agents`
 - `native-live-src-gateway-core`
-- завдання `native-live-src-gateway-profiles`, відфільтровані за провайдером
+- завдання `native-live-src-gateway-profiles`, відфільтровані за provider
 - `native-live-src-gateway-backends`
 - `native-live-test`
 - `native-live-extensions-a-k`
@@ -218,61 +226,61 @@ Umbrella записує ids запущених child runs, а фінальне
 - `native-live-extensions-openai`
 - `native-live-extensions-o-z-other`
 - `native-live-extensions-xai`
-- розділені шарди audio/video для медіа й музичні шарди, відфільтровані за провайдером
+- розділені media shards для audio/video і music shards, відфільтровані за provider
 
-Це зберігає те саме файлове покриття, водночас полегшуючи повторний запуск і діагностику повільних збоїв live-провайдерів. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків.
+Це зберігає те саме файлове покриття, водночас спрощуючи перезапуск і діагностику повільних live-збоїв provider. Агреговані імена shard `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються дійсними для ручних одноразових перезапусків.
 
-Нативні live media шарди виконуються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють наявність бінарних файлів перед налаштуванням. Залишайте live-набори, що спираються на Docker, на звичайних Blacksmith runner’ах — container jobs є неправильним місцем для запуску вкладених Docker-тестів.
+Нативні live media shards виконуються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, створеному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media jobs лише перевіряють бінарні файли перед setup. Тримайте live-набори з Docker на звичайних Blacksmith runners — container jobs не підходять для запуску вкладених Docker tests.
 
-Live model/backend шарди, що спираються на Docker, використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Live release workflow збирає й публікує цей образ один раз, після чого Docker live model, provider-sharded gateway, CLI backend, ACP bind і Codex harness шарди запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker шарди мають явні обмеження `timeout` на рівні скриптів, нижчі за timeout workflow job, щоб завислий контейнер або шлях очищення швидко падав, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну source Docker target, релізний запуск налаштовано неправильно й він марнуватиме реальний час на дубльовані збірки образів.
+Live model/backend shards на базі Docker використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного commit. Live release workflow один раз збирає й публікує цей образ, після чого Docker live model, provider-sharded Gateway, CLI backend, ACP bind і Codex harness shards запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker shards мають явні script-level обмеження `timeout`, нижчі за timeout завдання workflow, щоб завислий container або шлях cleanup швидко падав, а не споживав увесь бюджет release-check. Якщо ці shards незалежно перебудовують повний source Docker target, релізний прогін налаштовано неправильно, і він марнуватиме wall clock на дублікати image builds.
 
-## Приймання пакета
+## Package Acceptance
 
-Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей інстальований пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI валідує дерево вихідного коду, тоді як приймання пакета валідує один tarball через той самий Docker E2E harness, який користувачі використовують після встановлення або оновлення.
+Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей встановлюваний пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє source tree, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі задіюють після встановлення або оновлення.
 
 ### Завдання
 
-1. `resolve_package` виконує checkout `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і друкує source, workflow ref, package ref, version, SHA-256 та profile у підсумку кроку GitHub.
-2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Багаторазовий workflow завантажує цей артефакт, валідує inventory tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker lanes проти цього пакета замість пакування checkout workflow. Коли profile вибирає кілька цільових `docker_lanes`, багаторазовий workflow готує пакет і спільні образи один раз, а потім розгортає ці lanes як паралельні цільові Docker jobs з унікальними артефактами.
-3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance розв’язав його; окремий Telegram dispatch усе ще може встановити опублікований npm spec.
-4. `summary` провалює workflow, якщо розв’язання пакета, Docker acceptance або опційний Telegram lane завершилися збоєм.
+1. `resolve_package` робить checkout `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить source, workflow ref, package ref, version, SHA-256 і profile у GitHub step summary.
+2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Reusable workflow завантажує цей артефакт, перевіряє inventory tarball, за потреби готує Docker images package-digest і запускає вибрані Docker lanes проти цього пакета замість пакування workflow checkout. Коли profile вибирає кілька цільових `docker_lanes`, reusable workflow один раз готує package і shared images, а потім розгортає ці lanes як паралельні цільові Docker jobs з унікальними артефактами.
+3. `package_telegram` за потреби викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance розв’язав його; standalone Telegram dispatch усе ще може встановлювати опублікований npm spec.
+4. `summary` провалює workflow, якщо package resolution, Docker acceptance або optional Telegram lane завершилися невдало.
 
 ### Джерела кандидатів
 
-- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих prerelease/stable версій.
-- `source=ref` пакує довірену гілку `package_ref`, тег або повний commit SHA. Resolver отримує гілки/теги OpenClaw, перевіряє, що вибраний commit досяжний з історії гілок репозиторію або релізного тегу, встановлює залежності в detached worktree і пакує його через `scripts/package-openclaw-for-docker.mjs`.
-- `source=url` завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим.
-- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` є опційним, але його варто надати для зовнішньо поширених артефактів.
+- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для acceptance опублікованого prerelease/stable.
+- `source=ref` пакує довірені branch, tag або повний commit SHA з `package_ref`. Resolver fetches OpenClaw branches/tags, перевіряє, що вибраний commit досяжний з історії branch репозиторію або release tag, встановлює deps у detached worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`.
+- `source=url` завантажує HTTPS `.tgz`; `package_sha256` обов’язковий.
+- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його варто надати для зовнішньо поширених артефактів.
 
-Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це source commit, який пакується, коли `source=ref`. Це дає змогу поточному test harness валідовувати старіші довірені source commits без запуску старої workflow-логіки.
+Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це source commit, який пакується, коли `source=ref`. Це дає поточному test harness змогу перевіряти старіші довірені source commits без запуску старої workflow logic.
 
 ### Профілі наборів
 
 - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
 - `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `published-upgrade-survivor`, `plugins-offline`, `plugin-update`
 - `product` — `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
-- `full` — повні Docker release-path chunks з OpenWebUI
+- `full` — повні Docker chunks релізного шляху з OpenWebUI
 - `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom`
 
-Профіль `package` використовує offline plugin-покриття, щоб валідація опублікованого пакета не залежала від live-доступності ClawHub. Опційний Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованого npm spec збережено для окремих dispatch-запусків.
+Profile `package` використовує offline-покриття plugin, щоб валідація опублікованого пакета не залежала від live-доступності ClawHub. Optional Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованого npm spec зберігається для standalone dispatches.
 
-Щодо спеціальної політики тестування оновлень і plugin, зокрема локальних команд,
-Docker lanes, inputs Package Acceptance, релізних значень за замовчуванням і тріажу збоїв,
-див. [Тестування оновлень і plugins](/uk/help/testing-updates-plugins).
+Для спеціальної політики тестування updates і plugins, включно з local commands,
+Docker lanes, inputs Package Acceptance, release defaults і failure triage,
+див. [Testing updates and plugins](/uk/help/testing-updates-plugins).
 
-Release checks викликає Package Acceptance з `source=artifact`, підготовленим артефактом релізного пакета, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=all-since-2026.4.23`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це зберігає докази міграції пакета, оновлення, очищення застарілих plugin dependency, ремонту встановлення налаштованого plugin, offline plugin, plugin-update і Telegram на тому самому розв’язаному package tarball. Установіть `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму матрицю проти відвантаженого npm-пакета замість артефакта, зібраного за SHA. Cross-OS release checks усе ще покривають OS-specific onboarding, installer і platform behavior; product validation для package/update має починатися з Package Acceptance. Docker lane `published-upgrade-survivor` валідує одну опубліковану baseline пакета за запуск. У Package Acceptance розв’язаний tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback published baseline, за замовчуванням `openclaw@latest`; команди повторного запуску failed-lane зберігають цю baseline. Установіть `published_upgrade_survivor_baselines=all-since-2026.4.23`, щоб розширити Full Release CI на кожен stable npm release від `2026.4.23` до `latest`; `release-history` залишається доступним для ручного ширшого семплінгу зі старішим pre-date anchor. Установіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на fixtures у формі issue для Feishu config, збережених bootstrap/persona файлів, налаштованих установлень OpenClaw plugin, tilde log paths і застарілих legacy plugin dependency roots. Окремий workflow `Update Migration` використовує Docker lane `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання стосується вичерпного очищення опублікованого оновлення, а не нормальної ширини Full Release CI. Локальні агреговані запуски можуть передавати точні package specs через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, зберігати один lane через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або встановлювати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для scenario matrix. Published lane налаштовує baseline за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також RPC status після запуску Gateway. Windows packaged і installer fresh lanes також перевіряють, що встановлений пакет може імпортувати browser-control override з raw absolute Windows path. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо його встановлено, інакше `openai/gpt-5.4`, тому докази встановлення й Gateway залишаються на тестовій моделі GPT-5, уникаючи значень за замовчуванням GPT-4.x.
+Release checks викликають Package Acceptance з `source=artifact`, підготовленим артефактом release package, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=all-since-2026.4.23`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це зберігає proof для package migration, update, cleanup stale-plugin-dependency, repair встановлення configured-plugin, offline plugin, plugin-update і Telegram на тому самому розв’язаному package tarball. Встановіть `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму matrix проти shipped npm package замість артефакта, зібраного за SHA. Cross-OS release checks і далі покривають OS-specific onboarding, installer і platform behavior; product validation для package/update має починатися з Package Acceptance. Docker lane `published-upgrade-survivor` перевіряє один опублікований package baseline за прогін. У Package Acceptance розв’язаний tarball `package-under-test` завжди є candidate, а `published_upgrade_survivor_baseline` вибирає fallback published baseline, за замовчуванням `openclaw@latest`; команди перезапуску failed-lane зберігають цей baseline. Встановіть `published_upgrade_survivor_baselines=all-since-2026.4.23`, щоб розширити Full Release CI на кожен stable npm release від `2026.4.23` до `latest`; `release-history` залишається доступним для ручного ширшого sampling зі старішим pre-date anchor. Встановіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для Feishu config, збережених bootstrap/persona files, встановлень configured OpenClaw plugin, tilde log paths і stale legacy plugin dependency roots. Окремий workflow `Update Migration` використовує Docker lane `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає в exhaustive published update cleanup, а не у звичайній ширині Full Release CI. Local aggregate runs можуть передавати точні package specs через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, зберігати одну lane з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або встановлювати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для scenario matrix. Published lane налаштовує baseline за допомогою baked recipe команди `openclaw config set`, записує recipe steps у `summary.json` і перевіряє `/healthz`, `/readyz`, а також RPC status після запуску Gateway. Windows packaged і installer fresh lanes також перевіряють, що встановлений package може імпортувати browser-control override із raw absolute Windows path. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо встановлено, інакше `openai/gpt-5.4`, тож install і gateway proof залишаються на тестовій моделі GPT-5, уникаючи defaults GPT-4.x.
 
-### Вікна сумісності зі спадковими версіями
+### Вікна legacy compatibility
 
-Package Acceptance має обмежені legacy-compatibility windows для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати compatibility path:
+Package Acceptance має обмежені вікна legacy-compatibility для вже опублікованих packages. Packages до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати compatibility path:
 
-- відомі приватні QA-записи в `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені з tarball;
-- `doctor-switch` може пропустити підвипадок persistence для `gateway install --wrapper`, коли пакет не експонує цей flag;
-- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` з fake git fixture, похідного від tarball, і може логувати відсутній persisted `update.channel`;
+- відомі private QA entries у `dist/postinstall-inventory.json` можуть указувати на файли, пропущені tarball;
+- `doctor-switch` може пропускати subcase persistence `gateway install --wrapper`, коли package не expose цей flag;
+- `update-channel-switch` може prune відсутні `pnpm.patchedDependencies` із fake git fixture, derived from tarball, і може логувати відсутній persisted `update.channel`;
 - plugin smokes можуть читати legacy install-record locations або приймати відсутню marketplace install-record persistence;
-- `plugin-update` може дозволити міграцію config metadata, водночас і далі вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними.
+- `plugin-update` може дозволяти config metadata migration, водночас і далі вимагаючи, щоб install record і no-reinstall behavior лишалися unchanged.
 
-Опублікований пакет `2026.4.26` також може попереджати про local build metadata stamp files, які вже були відвантажені. Пізніші пакети мають задовольняти сучасні contracts; ті самі умови призводять до failure, а не warning чи skip.
+Опублікований package `2026.4.26` також може попереджати про local build metadata stamp files, які вже були shipped. Пізніші packages мають відповідати modern contracts; ті самі conditions fail замість warn або skip.
 
 ### Приклади
 
@@ -317,58 +325,58 @@ gh workflow run package-acceptance.yml \
 
 Під час налагодження невдалого запуску приймання пакета починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker-ліній замість повторного запуску повної валідації релізу.
 
-## Install smoke
+## Димова перевірка встановлення
 
-Окремий workflow `Install Smoke` повторно використовує той самий скрипт визначення області через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
+Окремий workflow `Install Smoke` повторно використовує той самий скрипт області через власне завдання `preflight`. Він розділяє димове покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
 
-- **Швидкий шлях** запускається для pull request, які зачіпають Docker/package-поверхні, зміни пакетів/маніфестів вбудованих плагінів або поверхні core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише в джерельному коді вбудованих плагінів, зміни лише тестів і зміни лише документації не резервують Docker-воркери. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI smoke для `agents delete shared-workspace`, запускає container gateway-network e2e, перевіряє аргумент збирання вбудованого розширення та запускає обмежений Docker-профіль вбудованих плагінів із сукупним тайм-аутом команди 240 секунд (Docker-запуск кожного сценарію обмежується окремо).
-- **Повний шлях** зберігає встановлення QR-пакета та Docker/update-покриття інсталятора для нічних запланованих запусків, ручних dispatch-запусків, release checks через workflow-call і pull request, які справді зачіпають installer/package/Docker-поверхні. У повному режимі install-smoke готує або повторно використовує один GHCR smoke-образ кореневого Dockerfile для цільового SHA, а потім запускає встановлення QR-пакета, root Dockerfile/gateway smoke, installer/update smoke і швидкий Docker E2E для вбудованих плагінів як окремі завдання, щоб робота інсталятора не чекала за smoke-перевірками кореневого образу.
+- **Швидкий шлях** запускається для pull request, які торкаються поверхонь Docker/пакетів, змін пакета/маніфесту вбудованого Plugin або поверхонь core Plugin/каналу/Gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише у вихідному коді вбудованого Plugin, редагування лише тестів і редагування лише документації не резервують Docker-воркери. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI smoke для `agents delete shared-workspace`, запускає container gateway-network e2e, перевіряє аргумент збірки вбудованого extension і запускає обмежений Docker-профіль вбудованого Plugin із сукупним тайм-аутом команди 240 секунд (Docker-запуск кожного сценарію обмежується окремо).
+- **Повний шлях** зберігає встановлення QR-пакета та Docker/update-покриття інсталятора для нічних запланованих запусків, ручних dispatch, release-перевірок через workflow-call і pull request, які справді торкаються поверхонь інсталятора/пакета/Docker. У повному режимі install-smoke готує або повторно використовує один target-SHA GHCR smoke-образ кореневого Dockerfile, а потім запускає встановлення QR-пакета, root Dockerfile/Gateway smokes, installer/update smokes і швидкий Docker E2E вбудованого Plugin як окремі завдання, щоб робота інсталятора не чекала за root image smokes.
 
-Push-запуски в `main` (зокрема merge-коміти) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття для push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або релізної валідації.
+Пуші в `main` (включно з merge commit) не примушують повний шлях; коли логіка changed-scope запитувала б повне покриття під час push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або release validation.
 
-Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow перевірок релізу, а ручні dispatch-запуски `Install Smoke` можуть явно ввімкнути його, але pull request і push-запуски в `main` цього не роблять. QR і Docker-тести інсталятора зберігають власні Dockerfile, сфокусовані на встановленні.
+Повільний Bun global install image-provider smoke окремо керується `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow release checks, а ручні dispatch `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` - ні. Docker-тести QR та інсталятора зберігають власні Dockerfile, сфокусовані на встановленні.
 
 ## Локальний Docker E2E
 
 `pnpm test:docker:all` попередньо збирає один спільний live-test образ, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
 
-- мінімальний Node/Git runner для installer/update/plugin-dependency ліній;
+- мінімальний Node/Git runner для ліній installer/update/plugin-dependency;
 - функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній.
 
-Визначення Docker-ліній містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для кожної лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
+Визначення Docker-ліній містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для кожної лінії через `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
 
-### Налаштування
+### Параметри налаштування
 
-| Змінна                                | Типово  | Призначення                                                                                         |
-| ------------------------------------- | ------- | --------------------------------------------------------------------------------------------------- |
-| `OPENCLAW_DOCKER_ALL_PARALLELISM`     | 10      | Кількість слотів основного пулу для звичайних ліній.                                                |
-| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10      | Кількість слотів tail-пулу, чутливого до провайдерів.                                               |
-| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`      | 9       | Ліміт одночасних live-ліній, щоб провайдери не throttling.                                          |
-| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`       | 10      | Ліміт одночасних ліній npm install.                                                                 |
-| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`   | 7       | Ліміт одночасних багатосервісних ліній.                                                             |
-| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000    | Затримка між стартами ліній, щоб уникнути штормів створення в Docker daemon; задайте `0` без затримки. |
-| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний тайм-аут на лінію (120 хвилин); вибрані live/tail лінії використовують жорсткіші ліміти. |
-| `OPENCLAW_DOCKER_ALL_DRY_RUN`         | unset   | `1` друкує план планувальника без запуску ліній.                                                    |
-| `OPENCLAW_DOCKER_ALL_LANES`           | unset   | Розділений комами точний список ліній; пропускає cleanup smoke, щоб агенти могли відтворити одну невдалу лінію. |
+| Змінна                                | Типово  | Призначення                                                                                   |
+| ------------------------------------- | ------- | --------------------------------------------------------------------------------------------- |
+| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10      | Кількість слотів основного пулу для звичайних ліній.                                          |
+| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10      | Кількість слотів tail-пулу, чутливого до провайдерів.                                        |
+| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9       | Ліміт одночасних live-ліній, щоб провайдери не обмежували швидкість.                         |
+| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10      | Ліміт одночасних ліній встановлення npm.                                                      |
+| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7       | Ліміт одночасних багатосервісних ліній.                                                       |
+| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000    | Затримка між стартами ліній, щоб уникати сплесків створення в Docker daemon; встановіть `0`, щоб вимкнути затримку. |
+| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000 | Резервний тайм-аут на лінію (120 хвилин); вибрані live/tail-лінії використовують жорсткіші обмеження. |
+| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | unset   | `1` друкує план планувальника без запуску ліній.                                              |
+| `OPENCLAW_DOCKER_ALL_LANES`            | unset   | Розділений комами точний список ліній; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу лінію. |
 
-Лінія, важча за її ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальні сукупні preflight-перевірки перевіряють Docker, видаляють застарілі OpenClaw E2E-контейнери, виводять статус активних ліній, зберігають таймінги ліній для впорядкування від найдовших і за замовчуванням припиняють планувати нові pooled-лінії після першої помилки.
+Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім виконується самостійно, доки не звільнить місткість. Локальні сукупні preflight перевіряють Docker, видаляють застарілі OpenClaw E2E-контейнери, виводять статус активних ліній, зберігають таймінги ліній для впорядкування longest-first і типово припиняють планування нових pooled-ліній після першої помилки.
 
-### Повторно використовуваний live/E2E workflow
+### Багаторазовий live/E2E workflow
 
-Повторно використовуваний live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, лінії та облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і зведення. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; валідує інвентар tarball; збирає та публікує bare/functional GHCR Docker E2E образи з тегом digest пакета через Docker layer cache Blacksmith, коли план потребує ліній із встановленим пакетом; і повторно використовує надані входи `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні образи з digest пакета замість перебудови. Завантаження Docker-образів повторюються з обмеженим тайм-аутом 180 секунд на спробу, щоб завислий потік registry/cache швидко повторювався, а не споживав більшу частину критичного шляху CI.
+Багаторазовий live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, який пакет, вид образу, live-образ, лінія та покриття облікових даних потрібні. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і зведення. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета з поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає та пушить package-digest-tagged bare/functional GHCR Docker E2E образи через кеш Docker-шарів Blacksmith, коли план потребує ліній із установленим пакетом; і повторно використовує надані input `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest образи замість повторної збірки. Pull Docker-образів повторюється з обмеженим тайм-аутом 180 секунд на спробу, щоб завислий потік registry/cache швидко повторювався замість споживання більшої частини критичного шляху CI.
 
-### Фрагменти релізного шляху
+### Фрагменти release-path
 
-Релізне Docker-покриття запускає менші chunked-завдання з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний тип образу й виконував кілька ліній через той самий зважений планувальник:
+Release Docker-покриття запускає менші chunked-завдання з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk тягнув лише потрібний йому вид образу й виконував кілька ліній через той самий зважений планувальник:
 
 - `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
 - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h`
 
-Поточні релізні Docker chunks: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` і від `plugins-runtime-install-a` до `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються сукупними псевдонімами plugin/runtime. Псевдонім лінії `install-e2e` залишається сукупним ручним псевдонімом повторного запуску для обох provider installer ліній.
+Поточні release Docker chunks: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` і від `plugins-runtime-install-a` до `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються aggregate plugin/runtime alias. Alias лінії `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes.
 
-OpenWebUI включається в `plugins-runtime-services`, коли повне release-path покриття запитує його, і зберігає окремий chunk `openwebui` лише для dispatch-запусків тільки OpenWebUI. Лінії оновлення bundled-channel повторюються один раз для тимчасових мережевих збоїв npm.
+OpenWebUI входить до `plugins-runtime-services`, коли повне release-path-покриття запитує його, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Bundled-channel update lanes повторюють спробу один раз для тимчасових мережевих збоїв npm.
 
-Кожен chunk вивантажує `.artifacts/docker-tests/` із журналами ліній, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Вхід workflow `docker_lanes` запускає вибрані лінії на підготовлених образах замість chunk-завдань, що утримує налагодження невдалої лінії в межах одного цільового Docker-завдання й готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана лінія є live Docker-лінією, цільове завдання локально збирає live-test образ для цього повторного запуску. Згенеровані для кожної лінії команди повторного запуску GitHub містять `package_artifact_run_id`, `package_artifact_name` і входи підготовлених образів, коли ці значення існують, щоб невдала лінія могла повторно використати точний пакет і образи з невдалого запуску.
+Кожен chunk вивантажує `.artifacts/docker-tests/` із журналами ліній, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість chunk jobs, що обмежує налагодження невдалої лінії одним цільовим Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана лінія є live Docker lane, цільове завдання локально збирає live-test image для цього rerun. Згенеровані для кожної лінії GitHub rerun-команди містять `package_artifact_run_id`, `package_artifact_name` і prepared image inputs, коли ці значення існують, тож невдала лінія може повторно використати точний пакет і образи з невдалого запуску.
 
 ```bash
 pnpm test:docker:rerun <run-id>      # download Docker artifacts and print combined/per-lane targeted rerun commands
@@ -377,89 +385,89 @@ pnpm test:docker:timings <summary>   # slow-lane and phase critical-path summari
 
 Запланований live/E2E workflow щодня запускає повний release-path Docker suite.
 
-## Попередній випуск Plugin
+## Plugin Prerelease
 
-`Plugin Prerelease` є дорожчим product/package-покриттям, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push-запуски в `main` і автономні ручні CI dispatch-запуски тримають цей suite вимкненим. Він балансує тести вбудованих плагінів між вісьмома extension workers; ці extension shard-завдання запускають до двох груп конфігурації плагінів одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy пакети плагінів не створювали додаткові CI-завдання. Релізний Docker prerelease path групує цільові Docker-лінії в малі групи, щоб не резервувати десятки runner для завдань на одну-три хвилини.
+`Plugin Prerelease` є дорожчим product/package-покриттям, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, пуші в `main` і окремі ручні CI dispatch не вмикають цей suite. Він балансує тести вбудованих Plugin між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy plugin batches не створювали додаткові CI jobs. Release-only Docker prerelease path групує цільові Docker lanes у малі групи, щоб не резервувати десятки runners для завдань тривалістю від однієї до трьох хвилин.
 
 ## QA Lab
 
-QA Lab має виділені CI-лінії поза основним smart-scoped workflow. Agentic parity вкладена в широкі QA та release harnesses, а не є автономним PR workflow. Використовуйте `Full Release Validation` з `rerun_group=qa-parity`, коли parity має виконуватися разом із широким запуском валідації.
+QA Lab має виділені CI lanes поза основним smart-scoped workflow. Agentic parity вкладено в широкі QA та release harnesses, а не в окремий PR workflow. Використовуйте `Full Release Validation` з `rerun_group=qa-parity`, коли parity має виконуватися разом із широким validation run.
 
-- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і під час ручного dispatch; він розгалужує mock parity lane, live Matrix lane, а також live Telegram і Discord lanes як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases.
+- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і вручну через dispatch; він розгалужує mock parity lane, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases.
 
-Release checks запускають Matrix і Telegram live transport lanes із детермінованим mock provider і mock-qualified models (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live model і звичайного запуску provider-plugin. Live transport gateway вимикає пошук пам’яті, тому що QA parity окремо покриває поведінку пам’яті; підключення провайдера покривається окремими live model, native provider і Docker provider suites.
+Release checks запускають Matrix і Telegram live transport lanes із детермінованим mock provider і mock-qualified models (`mock-openai/gpt-5.5` та `mock-openai/gpt-5.5-alt`), щоб channel contract був ізольований від live model latency і звичайного запуску provider-plugin. Live transport gateway вимикає memory search, оскільки QA parity окремо покриває memory behavior; provider connectivity покривають окремі live model, native provider і Docker provider suites.
 
-Matrix використовує `--profile fast` для запланованих і релізних gate, додаючи `--fail-fast` лише тоді, коли checked-out CLI підтримує це. Стандартне значення CLI та ручний вхід workflow залишаються `all`; ручний dispatch `matrix_profile=all` завжди шардить повне Matrix-покриття на завдання `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
+Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише коли checked-out CLI підтримує це. CLI default і manual workflow input залишаються `all`; ручний dispatch `matrix_profile=all` завжди розбиває повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
 
-`OpenClaw Release Checks` також запускає критичні для релізу QA Lab lanes перед затвердженням релізу; його QA parity gate запускає candidate і baseline packs як паралельні lane-завдання, а потім завантажує обидва артефакти в невелике report-завдання для фінального parity-порівняння.
+`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у невеликий report job для остаточного parity comparison.
 
-Для звичайних PR дотримуйтеся scoped CI/check evidence замість того, щоб вважати parity обов’язковим статусом.
+Для звичайних PR дотримуйтеся scoped CI/check evidence замість того, щоб вважати parity обов'язковим status.
 
 ## CodeQL
 
-Робочий процес `CodeQL` навмисно є вузьким сканером безпеки першого проходу, а не повним переглядом репозиторію. Щоденні, ручні та захисні запуски для pull request, що не є чернетками, сканують код workflow Actions, а також найризикованіші поверхні JavaScript/TypeScript із високонадійними запитами безпеки, відфільтрованими до високого/критичного `security-severity`.
+Робочий процес `CodeQL` навмисно є вузьким сканером безпеки першого проходу, а не повним скануванням репозиторію. Щоденні, ручні та guard-запуски для нечернеткових pull request сканують код Actions workflow, а також поверхні JavaScript/TypeScript із найвищим ризиком за допомогою security queries з високою достовірністю, відфільтрованих до high/critical `security-severity`.
 
-Захист pull request лишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src` і виконує ту саму високонадійну матрицю безпеки, що й запланований workflow. Android і macOS CodeQL не входять до стандартних PR-запусків.
+Guard для pull request залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і виконує ту саму матрицю безпеки з високою достовірністю, що й запланований workflow. Android і macOS CodeQL не входять до стандартних PR-запусків.
 
 ### Категорії безпеки
 
 | Категорія                                        | Поверхня                                                                                                                            |
-| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-security-high/core-auth-secrets`         | Auth, secrets, sandbox, cron і базова лінія gateway                                                                                 |
-| `/codeql-security-high/channel-runtime-boundary`  | Контракти реалізації основних каналів плюс runtime Plugin каналу, gateway, Plugin SDK, secrets, точки дотику audit                 |
-| `/codeql-security-high/network-ssrf-boundary`     | Поверхні основного SSRF, парсингу IP, захисту мережі, web-fetch і політики SSRF у Plugin SDK                                       |
-| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, допоміжні засоби виконання процесів, outbound delivery і шлюзи виконання інструментів агентом                         |
-| `/codeql-security-high/plugin-trust-boundary`     | Поверхні довіри для встановлення Plugin, loader, manifest, registry, package-manager install, source-loading і контракту пакета Plugin SDK |
+| ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------- |
+| `/codeql-security-high/core-auth-secrets`        | Auth, secrets, sandbox, cron і базовий рівень gateway                                                                               |
+| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації основних каналів, а також runtime channel plugin, gateway, Plugin SDK, secrets і точки дотику audit           |
+| `/codeql-security-high/network-ssrf-boundary`    | Основні поверхні SSRF, IP parsing, network guard, web-fetch і політики SSRF у Plugin SDK                                            |
+| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, helpers для process execution, outbound delivery і gates для tool-execution агентів                                    |
+| `/codeql-security-high/plugin-trust-boundary`    | Поверхні довіри для Plugin install, loader, manifest, registry, package-manager install, source-loading і package contract у Plugin SDK |
 
-### Платформозалежні шарди безпеки
+### Платформозалежні security shards
 
-- `CodeQL Android Critical Security` — запланований шард безпеки Android. Збирає Android-застосунок вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує під `/codeql-critical-security/android`.
-- `CodeQL macOS Critical Security` — щотижневий/ручний шард безпеки macOS. Збирає macOS-застосунок вручну для CodeQL на Blacksmith macOS, відфільтровує результати збірки залежностей із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Залишається поза щоденними стандартними запусками, бо збірка macOS домінує в часі виконання навіть коли чиста.
+- `CodeQL Android Critical Security` — запланований Android security shard. Вручну збирає Android app для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує під `/codeql-critical-security/android`.
+- `CodeQL macOS Critical Security` — щотижневий/ручний macOS security shard. Вручну збирає macOS app для CodeQL на Blacksmith macOS, відфільтровує результати dependency build із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Залишається поза щоденними стандартними запускми, бо macOS build домінує за runtime навіть коли чистий.
 
-### Категорії критичної якості
+### Категорії Critical Quality
 
-`CodeQL Critical Quality` — відповідний небезпековий шард. Він виконує лише JavaScript/TypeScript-запити якості з severity error і без категорії security на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його захист pull request навмисно менший за запланований профіль: PR, що не є чернетками, запускають лише відповідні шарди `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для коду виконання команд/моделей/інструментів агента та dispatch відповідей, коду config schema/migration/IO, коду auth/secrets/sandbox/security, runtime основних каналів і вбудованих Plugin каналів, gateway protocol/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, Plugin SDK/package-contract або змін у runtime відповідей Plugin SDK. Зміни конфігурації CodeQL і workflow якості запускають усі дванадцять PR-шардів якості.
+`CodeQL Critical Quality` — відповідний не-security shard. Він виконує лише error-severity, non-security JavaScript/TypeScript quality queries для вузьких цінних поверхонь на меншому Blacksmith Linux runner. Його guard для pull request навмисно менший за запланований профіль: нечернеткові PR запускають лише відповідні shards `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін у коді виконання agent command/model/tool і reply dispatch, коді config schema/migration/IO, коді auth/secrets/sandbox/security, runtime основного channel і bundled channel plugin, gateway protocol/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, Plugin SDK/package-contract або Plugin SDK reply runtime. Зміни CodeQL config і quality workflow запускають усі дванадцять PR quality shards.
 
-Ручний dispatch приймає:
+Manual dispatch приймає:
 
 ```
 profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
 ```
 
-Вузькі профілі є навчальними/ітераційними hooks для запуску одного шарда якості ізольовано.
+Вузькі профілі є hooks для навчання/ітерації, щоб запускати один quality shard ізольовано.
 
 | Категорія                                              | Поверхня                                                                                                                                                           |
-| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-critical-quality/core-auth-secrets`            | Код межі безпеки auth, secrets, sandbox, cron і gateway                                                                                                           |
-| `/codeql-critical-quality/config-boundary`              | Контракти config schema, migration, normalization і IO                                                                                                            |
-| `/codeql-critical-quality/gateway-runtime-boundary`     | Схеми Gateway protocol і контракти server method                                                                                                                  |
-| `/codeql-critical-quality/channel-runtime-boundary`     | Контракти реалізації основних каналів і вбудованих Plugin каналів                                                                                                |
-| `/codeql-critical-quality/agent-runtime-boundary`       | Runtime-контракти command execution, model/provider dispatch, auto-reply dispatch і queues та ACP control-plane                                                   |
-| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-сервери та tool bridges, допоміжні засоби supervision процесів і контракти outbound delivery                                                                  |
-| `/codeql-critical-quality/memory-runtime-boundary`      | Memory host SDK, memory runtime facades, memory Plugin SDK aliases, glue активації memory runtime і команди memory doctor                                         |
-| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішні частини reply queue, session delivery queues, допоміжні засоби outbound session binding/delivery, поверхні diagnostic event/log bundle і контракти session doctor CLI |
-| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Inbound reply dispatch у Plugin SDK, допоміжні засоби reply payload/chunking/runtime, channel reply options, delivery queues і session/thread binding             |
-| `/codeql-critical-quality/provider-runtime-boundary`    | Model catalog normalization, provider auth і discovery, provider runtime registration, provider defaults/catalogs і web/search/fetch/embedding registries          |
-| `/codeql-critical-quality/ui-control-plane`             | Bootstrap Control UI, локальне збереження, керівні потоки gateway і runtime-контракти task control-plane                                                          |
-| `/codeql-critical-quality/web-media-runtime-boundary`   | Runtime-контракти основного web fetch/search, media IO, media understanding, image-generation і media-generation                                                   |
-| `/codeql-critical-quality/plugin-boundary`              | Контракти loader, registry, public-surface і entrypoint Plugin SDK                                                                                                |
-| `/codeql-critical-quality/plugin-sdk-package-contract`  | Опубліковане джерело Plugin SDK на боці пакета та допоміжні засоби контракту пакета plugin                                                                        |
+| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `/codeql-critical-quality/core-auth-secrets`           | Код межі безпеки для auth, secrets, sandbox, cron і gateway                                                                                                        |
+| `/codeql-critical-quality/config-boundary`             | Контракти config schema, migration, normalization і IO                                                                                                             |
+| `/codeql-critical-quality/gateway-runtime-boundary`    | Gateway protocol schemas і контракти server method                                                                                                                 |
+| `/codeql-critical-quality/channel-runtime-boundary`    | Контракти реалізації основного channel і bundled channel plugin                                                                                                    |
+| `/codeql-critical-quality/agent-runtime-boundary`      | Command execution, model/provider dispatch, auto-reply dispatch і queues, а також runtime contracts ACP control-plane                                              |
+| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP servers і tool bridges, helpers для process supervision, а також контракти outbound delivery                                                                   |
+| `/codeql-critical-quality/memory-runtime-boundary`     | Memory host SDK, memory runtime facades, aliases memory Plugin SDK, glue для активації memory runtime і команди memory doctor                                      |
+| `/codeql-critical-quality/session-diagnostics-boundary` | Reply queue internals, session delivery queues, helpers для outbound session binding/delivery, поверхні diagnostic event/log bundle і контракти session doctor CLI |
+| `/codeql-critical-quality/plugin-sdk-reply-runtime`    | Inbound reply dispatch у Plugin SDK, helpers для reply payload/chunking/runtime, channel reply options, delivery queues і helpers для session/thread binding       |
+| `/codeql-critical-quality/provider-runtime-boundary`   | Model catalog normalization, provider auth і discovery, provider runtime registration, provider defaults/catalogs і registries web/search/fetch/embedding          |
+| `/codeql-critical-quality/ui-control-plane`            | Bootstrap Control UI, local persistence, gateway control flows і runtime contracts task control-plane                                                              |
+| `/codeql-critical-quality/web-media-runtime-boundary`  | Основні runtime contracts для web fetch/search, media IO, media understanding, image-generation і media-generation                                                 |
+| `/codeql-critical-quality/plugin-boundary`             | Контракти loader, registry, public-surface і entrypoint у Plugin SDK                                                                                               |
+| `/codeql-critical-quality/plugin-sdk-package-contract` | Опубліковане package-side джерело Plugin SDK і helpers для plugin package contract                                                                                 |
 
-Якість залишається окремою від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і вбудованих plugin слід додавати назад як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
+Quality залишається окремо від security, щоб quality findings можна було планувати, вимірювати, вимикати або розширювати без затемнення security signal. Розширення CodeQL для Swift, Python і bundled-plugin слід повертати як scoped або sharded follow-up work лише після того, як вузькі профілі матимуть стабільний runtime і signal.
 
-## Workflow обслуговування
+## Workflow для обслуговування
 
 ### Docs Agent
 
-Workflow `Docs Agent` — це подієво керована лінія обслуговування Codex для підтримання наявної документації узгодженою з нещодавно внесеними змінами. Він не має чистого розкладу: успішний не-bot запуск CI після push на `main` може його ініціювати, а ручний dispatch може запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли інший непропущений запуск Docs Agent був створений протягом останньої години. Коли він виконується, він переглядає діапазон commit від попереднього source SHA непропущеного Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з останнього проходу документації.
+Workflow `Docs Agent` — це подієво-керована лінія обслуговування Codex для підтримання наявної документації в узгодженому стані з нещодавно злитими змінами. Вона не має чистого розкладу: успішний non-bot push CI run на `main` може її запускати, а manual dispatch може запускати її напряму. Workflow-run invocations пропускаються, коли `main` уже просунувся далі або коли інший non-skipped Docs Agent run був створений за останню годину. Коли вона запускається, вона переглядає commit range від попереднього non-skipped Docs Agent source SHA до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з часу останнього docs pass.
 
 ### Test Performance Agent
 
-Workflow `Test Performance Agent` — це подієво керована лінія обслуговування Codex для повільних тестів. Він не має чистого розкладу: успішний не-bot запуск CI після push на `main` може його ініціювати, але він пропускається, якщо інший виклик workflow-run уже запускався або виконується цього UTC-дня. Ручний dispatch обходить цей щоденний activity gate. Лінія створює grouped Vitest performance report для повного suite, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням coverage замість широких refactor, потім повторно запускає звіт повного suite і відхиляє зміни, що зменшують базову кількість passing tests. Якщо базова лінія має failing tests, Codex може виправляти лише очевидні failures, а after-agent full-suite report має пройти перед тим, як щось буде закомічено. Коли `main` просувається до того, як bot push потрапить у репозиторій, лінія rebase валідований patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patches пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб Codex action міг зберегти ту саму safety posture drop-sudo, що й docs agent.
+Workflow `Test Performance Agent` — це подієво-керована лінія обслуговування Codex для повільних тестів. Вона не має чистого розкладу: успішний non-bot push CI run на `main` може її запускати, але вона пропускається, якщо інший workflow-run invocation уже запускався або виконується в цей UTC день. Manual dispatch обходить цей daily activity gate. Лінія створює full-suite grouped Vitest performance report, дозволяє Codex робити лише невеликі test performance fixes зі збереженням coverage замість широких refactors, потім повторно запускає full-suite report і відхиляє зміни, які зменшують baseline test count, що проходить. Якщо baseline має failing tests, Codex може виправляти лише очевидні failures, а after-agent full-suite report має пройти перед тим, як щось буде закомічено. Коли `main` просувається до того, як bot push потрапить у репозиторій, лінія rebase validated patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні stale patches пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб Codex action міг зберегти ту саму drop-sudo safety posture, що й docs agent.
 
-### Дублікати PR після merge
+### Дублікати PR після злиття
 
-Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для post-land очищення дублікатів. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR merged, і що кожен duplicate має або спільну referenced issue, або overlapping changed hunks.
+Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для очищення дублікатів після landing. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR злитий і що кожен duplicate має або спільне referenced issue, або overlapping changed hunks.
 
 ```bash
 gh workflow run duplicate-after-merge.yml \
@@ -468,29 +476,29 @@ gh workflow run duplicate-after-merge.yml \
   -f apply=true
 ```
 
-## Локальні check gates і changed routing
+## Локальні check gates і routing змін
 
-Локальна логіка changed-lane живе в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широка область платформи CI:
+Локальна changed-lane logic міститься в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж широкий scope платформи CI:
 
-- зміни core production запускають typecheck core prod і core test плюс core lint/guards;
-- зміни лише core test запускають лише typecheck core test плюс core lint;
-- зміни extension production запускають typecheck extension prod і extension test плюс extension lint;
-- зміни лише extension test запускають typecheck extension test плюс extension lint;
-- зміни публічного Plugin SDK або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core contracts (sweeps Vitest extension лишаються явною test work);
-- version bumps лише release metadata запускають цільові перевірки version/config/root-dependency;
-- невідомі root/config зміни fail safe до всіх check lanes.
+- зміни core production запускають core prod і core test typecheck плюс core lint/guards;
+- зміни лише core test запускають лише core test typecheck плюс core lint;
+- зміни extension production запускають extension prod і extension test typecheck плюс extension lint;
+- зміни лише extension test запускають extension test typecheck плюс extension lint;
+- зміни public Plugin SDK або plugin-contract розширюються до extension typecheck, бо extensions залежать від цих core contracts (Vitest extension sweeps залишаються явною test work);
+- release metadata-only version bumps запускають targeted version/config/root-dependency checks;
+- невідомі root/config changes fail safe до всіх check lanes.
 
-Локальний changed-test routing живе в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі edits тестів запускають самі себе, edits source віддають перевагу явним mappings, потім sibling tests і import-graph dependents. Shared group-room delivery config є одним із явних mappings: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс Discord і Slack delivery regressions, щоб shared default change падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна достатньо harness-wide, що дешевий mapped set не є надійним proxy.
+Локальний changed-test routing міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі редагування тестів запускають самі себе, зміни source віддають перевагу explicit mappings, потім sibling tests і import-graph dependents. Shared group-room delivery config є одним із explicit mappings: зміни group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс Discord і Slack delivery regressions, щоб зміна shared default падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна достатньо harness-wide, що дешевий mapped set не є надійним proxy.
 
-## Testbox validation
+## Валідація Testbox
 
-Запускайте Testbox з кореня репозиторію й надавайте перевагу свіжому прогрітому середовищу для широкої перевірки. Перш ніж витрачати повільний gate на середовище, яке було повторно використане, протерміноване або щойно повідомило про неочікувано велику синхронізацію, спершу запустіть `pnpm testbox:sanity` всередині цього середовища.
+Запускайте Testbox з кореня репозиторію й віддавайте перевагу свіжо прогрітому середовищу для широкого підтвердження. Перш ніж витрачати повільну перевірку на середовище, яке було повторно використане, протерміноване або щойно повідомило про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` всередині цього середовища.
 
-Перевірка sanity швидко завершується з помилкою, коли зникають потрібні кореневі файли, як-от `pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 відстежуваних видалень. Зазвичай це означає, що стан віддаленої синхронізації не є надійною копією PR; зупиніть це середовище й прогрійте свіже, замість налагоджувати збій продуктового тесту. Для PR із навмисними великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього запуску sanity.
+Sanity-перевірка швидко завершується з помилкою, коли зникли потрібні кореневі файли, як-от `pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 відстежуваних видалень. Зазвичай це означає, що стан віддаленого sync не є надійною копією PR; зупиніть це середовище й прогрійте свіже замість того, щоб налагоджувати збій продуктового тесту. Для навмисних PR із великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity-запуску.
 
-`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі синхронізації понад п’ять хвилин без виводу після синхронізації. Встановіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей захист, або використайте більше значення в мілісекундах для незвично великих локальних відмінностей.
+`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі sync понад п’ять хвилин без виводу після sync. Установіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей запобіжник, або використайте більше значення в мілісекундах для незвично великих локальних diff.
 
-Crabbox — це другий, керований репозиторієм, шлях до віддаленого середовища для перевірки Linux, коли Blacksmith недоступний або коли бажаніше використати власні хмарні ресурси. Прогрійте середовище, гідруйте його через робочий процес проєкту, а потім запускайте команди через Crabbox CLI:
+Crabbox — це другий, належний репозиторію шлях віддаленого середовища для Linux-підтвердження, коли Blacksmith недоступний або коли бажано використати власну хмарну місткість. Прогрійте середовище, гідратуйте його через workflow проєкту, а потім запускайте команди через Crabbox CLI:
 
 ```bash
 pnpm crabbox:warmup -- --idle-timeout 90m
@@ -499,7 +507,7 @@ pnpm crabbox:run -- --id <cbx_id> --shell "OPENCLAW_TESTBOX=1 pnpm check:changed
 pnpm crabbox:stop -- <cbx_id>
 ```
 
-`.crabbox.yaml` визначає типові налаштування провайдера, синхронізації та гідрації GitHub Actions. Він виключає локальний `.git`, щоб гідрований checkout Actions зберігав власні віддалені метадані Git замість синхронізації локальних maintainer-remote та сховищ об’єктів, а також виключає локальні артефакти runtime/build, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` визначає checkout, налаштування Node/pnpm, fetch `origin/main` і передавання несекретного середовища, яке пізніші команди `crabbox run --id <cbx_id>` підвантажують як джерело.
+`.crabbox.yaml` відповідає за типові значення provider, sync і GitHub Actions hydration. Він виключає локальний `.git`, щоб гідратований checkout Actions зберігав власні віддалені Git-метадані замість sync maintainer-локальних remotes та object stores, а також виключає локальні runtime/build артефакти, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` відповідає за checkout, налаштування Node/pnpm, fetch `origin/main` і передавання несекретного середовища, яке пізніші команди `crabbox run --id <cbx_id>` використовують як source.
 
 ## Пов’язане
 

docs/uk/gateway/configuration.md

@@ -1,40 +1,40 @@
 ---
 read_when:
     - Перше налаштування OpenClaw
-    - Пошук типових шаблонів конфігурації
+    - Пошук поширених шаблонів конфігурації
     - Перехід до певних розділів конфігурації
 summary: 'Огляд конфігурації: типові завдання, швидке налаштування та посилання на повний довідник'
 title: Конфігурація
 x-i18n:
-    generated_at: "2026-05-01T21:15:52Z"
+    generated_at: "2026-05-03T12:47:57Z"
     model: gpt-5.5
     provider: openai
-    source_hash: d5ad1685170923f26166fb2f74891468d16c6f86af5cc5f5f1da7a6dce65eb98
+    source_hash: b17a72368bb8d178174ccd3ff401657c67911096efd5960e5a1aa8cf0d303c81
     source_path: gateway/configuration.md
     workflow: 16
 ---
 
 OpenClaw читає необов’язкову конфігурацію <Tooltip tip="JSON5 supports comments and trailing commas">**JSON5**</Tooltip> з `~/.openclaw/openclaw.json`.
 Активний шлях конфігурації має бути звичайним файлом. Макети `openclaw.json`
-із symlink не підтримуються для записів, якими володіє OpenClaw; атомарний запис може замінити
-шлях замість збереження symlink. Якщо ви зберігаєте конфігурацію поза
-стандартним каталогом стану, вкажіть `OPENCLAW_CONFIG_PATH` безпосередньо на справжній файл.
+із символьними посиланнями не підтримуються для записів, якими володіє OpenClaw; атомарний запис може замінити
+шлях замість збереження символьного посилання. Якщо ви зберігаєте конфігурацію поза
+типовим каталогом стану, укажіть `OPENCLAW_CONFIG_PATH` безпосередньо на реальний файл.
 
 Якщо файл відсутній, OpenClaw використовує безпечні стандартні значення. Поширені причини додати конфігурацію:
 
-- Під’єднати канали й керувати тим, хто може надсилати повідомлення боту
-- Налаштувати моделі, інструменти, sandboxing або автоматизацію (cron, hooks)
+- Під’єднати канали й контролювати, хто може писати боту
+- Налаштувати моделі, інструменти, ізоляцію або автоматизацію (cron, хуки)
 - Налаштувати сеанси, медіа, мережу або UI
 
-Дивіться [повний довідник](/uk/gateway/configuration-reference) для кожного доступного поля.
+Див. [повний довідник](/uk/gateway/configuration-reference) для всіх доступних полів.
 
 Агенти й автоматизація мають використовувати `config.schema.lookup` для точних
-документів на рівні полів перед редагуванням конфігурації. Використовуйте цю сторінку для орієнтованих на завдання порад і
+документів на рівні полів перед редагуванням конфігурації. Використовуйте цю сторінку для практичних настанов і
 [довідник конфігурації](/uk/gateway/configuration-reference) для ширшої
 карти полів і стандартних значень.
 
 <Tip>
-**Новачок у конфігурації?** Почніть з `openclaw onboard` для інтерактивного налаштування або перегляньте посібник [приклади конфігурації](/uk/gateway/configuration-examples) з повними конфігураціями для копіювання.
+**Вперше налаштовуєте конфігурацію?** Почніть з `openclaw onboard` для інтерактивного налаштування або перегляньте посібник [приклади конфігурації](/uk/gateway/configuration-examples) із повними конфігураціями для копіювання.
 </Tip>
 
 ## Мінімальна конфігурація
@@ -64,55 +64,55 @@ OpenClaw читає необов’язкову конфігурацію <Toolti
     ```
   </Tab>
   <Tab title="Control UI">
-    Відкрийте [http://127.0.0.1:18789](http://127.0.0.1:18789) і використовуйте вкладку **Config**.
-    Control UI рендерить форму з актуальної схеми конфігурації, зокрема метадані документації полів
-    `title` / `description`, а також схеми plugin і каналів, коли вони
-    доступні, з редактором **Raw JSON** як запасним виходом. Для детальних
+    Відкрийте [http://127.0.0.1:18789](http://127.0.0.1:18789) і скористайтеся вкладкою **Config**.
+    Control UI відтворює форму з живої схеми конфігурації, включно з метаданими документації
+    `title` / `description` для полів, а також схемами Plugin і каналів, коли вони
+    доступні, з редактором **Raw JSON** як запасним варіантом. Для деталізованих
     UI та інших інструментів gateway також надає `config.schema.lookup`, щоб
-    отримати один вузол схеми в межах шляху плюс підсумки безпосередніх дочірніх елементів.
+    отримати один вузол схеми, обмежений шляхом, разом зі зведеннями безпосередніх дочірніх елементів.
   </Tab>
   <Tab title="Direct edit">
-    Редагуйте `~/.openclaw/openclaw.json` безпосередньо. Gateway відстежує файл і застосовує зміни автоматично (дивіться [гаряче перезавантаження](#config-hot-reload)).
+    Редагуйте `~/.openclaw/openclaw.json` безпосередньо. Gateway відстежує файл і застосовує зміни автоматично (див. [гаряче перезавантаження](#config-hot-reload)).
   </Tab>
 </Tabs>
 
-## Сувора перевірка
+## Сувора валідація
 
 <Warning>
-OpenClaw приймає лише конфігурації, які повністю відповідають схемі. Невідомі ключі, неправильні типи або недійсні значення змушують Gateway **відмовитися запускатися**. Єдиний виняток на кореневому рівні — `$schema` (рядок), щоб редактори могли додавати метадані JSON Schema.
+OpenClaw приймає лише конфігурації, які повністю відповідають схемі. Невідомі ключі, неправильно сформовані типи або недійсні значення змушують Gateway **відмовитися запускатися**. Єдиний виняток на кореневому рівні — `$schema` (рядок), щоб редактори могли додавати метадані JSON Schema.
 </Warning>
 
 `openclaw config schema` виводить канонічну JSON Schema, яку використовують Control UI
-і перевірка. `config.schema.lookup` отримує один вузол у межах шляху плюс
-підсумки дочірніх елементів для інструментів деталізації. Метадані документації полів `title`/`description`
+і валідація. `config.schema.lookup` отримує один вузол, обмежений шляхом, разом зі
+зведеннями дочірніх елементів для інструментів деталізації. Метадані документації полів `title`/`description`
 передаються через вкладені об’єкти, wildcard (`*`), елементи масиву (`[]`) і гілки `anyOf`/
-`oneOf`/`allOf`. Схеми plugin і каналів часу виконання об’єднуються, коли
-завантажено реєстр manifest.
+`oneOf`/`allOf`. Схеми Plugin і каналів часу виконання об’єднуються, коли
+завантажено реєстр маніфестів.
 
-Коли перевірка не проходить:
+Коли валідація не проходить:
 
-- Gateway не завантажується
+- Gateway не запускається
 - Працюють лише діагностичні команди (`openclaw doctor`, `openclaw logs`, `openclaw health`, `openclaw status`)
 - Запустіть `openclaw doctor`, щоб побачити точні проблеми
 - Запустіть `openclaw doctor --fix` (або `--yes`), щоб застосувати виправлення
 
 Gateway зберігає довірену останню справну копію після кожного успішного запуску.
-Якщо `openclaw.json` пізніше не проходить перевірку (або втрачає `gateway.mode`, різко
+Якщо `openclaw.json` пізніше не проходить валідацію (або втрачає `gateway.mode`, різко
 зменшується чи має випадково доданий на початку рядок журналу), OpenClaw зберігає пошкоджений файл
 як `.clobbered.*`, відновлює останню справну копію й записує причину відновлення
-в журнал. Наступний хід агента також отримує попередження системної події, щоб головний
-агент не переписав відновлену конфігурацію без перевірки. Підвищення до останньої справної
-копії пропускається, коли кандидат містить замінники відредагованих секретів, як-от `***`.
-Коли кожна проблема перевірки обмежена `plugins.entries.<id>...`, OpenClaw
+до журналу. Наступний хід агента також отримує попередження системної події, щоб основний
+агент не переписав відновлену конфігурацію наосліп. Підвищення до останньої справної
+копії пропускається, коли кандидат містить відредаговані заповнювачі секретів, як-от `***`.
+Коли кожна проблема валідації обмежена `plugins.entries.<id>...`, OpenClaw
 не виконує відновлення всього файлу. Він залишає поточну конфігурацію активною й
-показує локальну помилку plugin, щоб невідповідність схеми plugin або версії host
-не могла відкотити непов’язані користувацькі налаштування.
+показує локальний збій Plugin, щоб невідповідність схеми Plugin або версії хоста
+не могла відкотити непов’язані налаштування користувача.
 
 ## Поширені завдання
 
 <AccordionGroup>
   <Accordion title="Set up a channel (WhatsApp, Telegram, Discord, etc.)">
-    Кожен канал має власний розділ конфігурації під `channels.<provider>`. Дивіться спеціальну сторінку каналу для кроків налаштування:
+    Кожен канал має власний розділ конфігурації в `channels.<provider>`. Див. окрему сторінку каналу для кроків налаштування:
 
     - [WhatsApp](/uk/channels/whatsapp) — `channels.whatsapp`
     - [Telegram](/uk/channels/telegram) — `channels.telegram`
@@ -143,7 +143,7 @@ Gateway зберігає довірену останню справну копі
   </Accordion>
 
   <Accordion title="Choose and configure models">
-    Задайте основну модель і необов’язкові резервні варіанти:
+    Установіть основну модель і необов’язкові резервні варіанти:
 
     ```json5
     {
@@ -162,31 +162,31 @@ Gateway зберігає довірену останню справну копі
     }
     ```
 
-    - `agents.defaults.models` визначає каталог моделей і працює як allowlist для `/model`.
-    - Використовуйте `openclaw config set agents.defaults.models '<json>' --strict-json --merge`, щоб додати записи allowlist без видалення наявних моделей. Звичайні заміни, які видалили б записи, відхиляються, якщо не передати `--replace`.
+    - `agents.defaults.models` визначає каталог моделей і діє як allowlist для `/model`.
+    - Використовуйте `openclaw config set agents.defaults.models '<json>' --strict-json --merge`, щоб додати записи allowlist без видалення наявних моделей. Звичайні заміни, які видалили б записи, відхиляються, якщо ви не передасте `--replace`.
     - Посилання на моделі використовують формат `provider/model` (наприклад, `anthropic/claude-opus-4-6`).
-    - `agents.defaults.imageMaxDimensionPx` керує зменшенням зображень transcript/tool (стандартно `1200`); нижчі значення зазвичай зменшують використання vision-токенів у запусках із великою кількістю скриншотів.
-    - Дивіться [CLI моделей](/uk/concepts/models) для перемикання моделей у чаті та [відмовостійкість моделей](/uk/concepts/model-failover) для ротації авторизації й поведінки резервних варіантів.
-    - Для кастомних/самостійно розміщених provider дивіться [кастомні provider](/uk/gateway/config-tools#custom-providers-and-base-urls) у довіднику.
+    - `agents.defaults.imageMaxDimensionPx` керує зменшенням зображень транскрипту/інструментів (стандартно `1200`); нижчі значення зазвичай зменшують використання vision-токенів у запусках із великою кількістю знімків екрана.
+    - Див. [CLI моделей](/uk/concepts/models) для перемикання моделей у чаті та [резервування моделей](/uk/concepts/model-failover) для ротації автентифікації й поведінки резервних варіантів.
+    - Для власних або self-hosted провайдерів див. [власні провайдери](/uk/gateway/config-tools#custom-providers-and-base-urls) у довіднику.
 
   </Accordion>
 
   <Accordion title="Control who can message the bot">
-    Доступ DM контролюється для кожного каналу через `dmPolicy`:
+    Доступ до DM керується для кожного каналу через `dmPolicy`:
 
     - `"pairing"` (стандартно): невідомі відправники отримують одноразовий код сполучення для схвалення
     - `"allowlist"`: лише відправники в `allowFrom` (або у сховищі дозволених після сполучення)
-    - `"open"`: дозволити всі вхідні DM (потрібно `allowFrom: ["*"]`)
+    - `"open"`: дозволити всі вхідні DM (потребує `allowFrom: ["*"]`)
     - `"disabled"`: ігнорувати всі DM
 
     Для груп використовуйте `groupPolicy` + `groupAllowFrom` або allowlist, специфічні для каналу.
 
-    Дивіться [повний довідник](/uk/gateway/config-channels#dm-and-group-access) для деталей за каналами.
+    Див. [повний довідник](/uk/gateway/config-channels#dm-and-group-access) для подробиць за каналами.
 
   </Accordion>
 
   <Accordion title="Set up group chat mention gating">
-    Групові повідомлення за замовчуванням **вимагають згадки**. Налаштуйте шаблони тригерів для кожного агента й залишайте видимі відповіді в кімнатах на стандартному шляху message-tool, якщо ви навмисно не хочете застарілі автоматичні фінальні відповіді:
+    Групові повідомлення стандартно **вимагають згадки**. Налаштуйте шаблони тригерів для кожного агента й залишайте видимі відповіді в кімнаті на стандартному шляху інструмента повідомлень, якщо ви навмисно не хочете застарілих автоматичних фінальних відповідей:
 
     ```json5
     {
@@ -216,13 +216,13 @@ Gateway зберігає довірену останню справну копі
 
     - **Згадки в метаданих**: нативні @-згадки (WhatsApp tap-to-mention, Telegram @bot тощо)
     - **Текстові шаблони**: безпечні regex-шаблони в `mentionPatterns`
-    - **Видимі відповіді**: `messages.visibleReplies` може вимагати надсилання через message-tool глобально; `messages.groupChat.visibleReplies` перевизначає це для груп/каналів.
-    - Дивіться [повний довідник](/uk/gateway/config-channels#group-chat-mention-gating) для режимів видимих відповідей, перевизначень за каналами й режиму self-chat.
+    - **Видимі відповіді**: `messages.visibleReplies` може вимагати надсилання через інструмент повідомлень глобально; `messages.groupChat.visibleReplies` перевизначає це для груп/каналів.
+    - Див. [повний довідник](/uk/gateway/config-channels#group-chat-mention-gating) для режимів видимих відповідей, перевизначень за каналами та режиму self-chat.
 
   </Accordion>
 
   <Accordion title="Restrict skills per agent">
-    Використовуйте `agents.defaults.skills` для спільної базової лінії, а потім перевизначайте конкретних
+    Використовуйте `agents.defaults.skills` для спільної бази, а потім перевизначайте конкретних
     агентів через `agents.list[].skills`:
 
     ```json5
@@ -242,14 +242,14 @@ Gateway зберігає довірену останню справну копі
 
     - Не вказуйте `agents.defaults.skills`, щоб Skills були необмеженими за замовчуванням.
     - Не вказуйте `agents.list[].skills`, щоб успадкувати стандартні значення.
-    - Встановіть `agents.list[].skills: []`, щоб не було Skills.
-    - Дивіться [Skills](/uk/tools/skills), [конфігурацію Skills](/uk/tools/skills-config) і
+    - Установіть `agents.list[].skills: []`, щоб вимкнути Skills.
+    - Див. [Skills](/uk/tools/skills), [конфігурація Skills](/uk/tools/skills-config) і
       [довідник конфігурації](/uk/gateway/config-agents#agents-defaults-skills).
 
   </Accordion>
 
   <Accordion title="Tune gateway channel health monitoring">
-    Керуйте тим, наскільки агресивно gateway перезапускає канали, які здаються застарілими:
+    Керуйте тим, наскільки агресивно gateway перезапускає канали, що здаються неактивними:
 
     ```json5
     {
@@ -271,16 +271,16 @@ Gateway зберігає довірену останню справну копі
     }
     ```
 
-    - Встановіть `gateway.channelHealthCheckMinutes: 0`, щоб глобально вимкнути перезапуски health-monitor.
+    - Установіть `gateway.channelHealthCheckMinutes: 0`, щоб глобально вимкнути перезапуски монітора стану.
     - `channelStaleEventThresholdMinutes` має бути більшим або дорівнювати інтервалу перевірки.
-    - Використовуйте `channels.<provider>.healthMonitor.enabled` або `channels.<provider>.accounts.<id>.healthMonitor.enabled`, щоб вимкнути автоперезапуски для одного каналу чи облікового запису без вимкнення глобального монітора.
-    - Дивіться [перевірки стану](/uk/gateway/health) для операційного налагодження та [повний довідник](/uk/gateway/configuration-reference#gateway) для всіх полів.
+    - Використовуйте `channels.<provider>.healthMonitor.enabled` або `channels.<provider>.accounts.<id>.healthMonitor.enabled`, щоб вимкнути автоматичні перезапуски для одного каналу чи облікового запису без вимкнення глобального монітора.
+    - Див. [перевірки стану](/uk/gateway/health) для операційного налагодження та [повний довідник](/uk/gateway/configuration-reference#gateway) для всіх полів.
 
   </Accordion>
 
   <Accordion title="Tune gateway WebSocket handshake timeout">
     Дайте локальним клієнтам більше часу завершити pre-auth WebSocket handshake на
-    завантажених або малопотужних host:
+    завантажених або малопотужних хостах:
 
     ```json5
     {
@@ -291,13 +291,13 @@ Gateway зберігає довірену останню справну копі
     ```
 
     - Стандартне значення — `15000` мілісекунд.
-    - `OPENCLAW_HANDSHAKE_TIMEOUT_MS` усе ще має пріоритет для одноразових перевизначень service або shell.
-    - Спочатку краще виправити зависання запуску/event-loop; цей параметр призначений для host, які справні, але повільні під час warmup.
+    - `OPENCLAW_HANDSHAKE_TIMEOUT_MS` усе ще має пріоритет для одноразових перевизначень сервісу або shell.
+    - Спочатку бажано виправити зависання запуску/циклу подій; цей параметр призначений для хостів, які справні, але повільні під час прогрівання.
 
   </Accordion>
 
   <Accordion title="Configure sessions and resets">
-    Сеанси керують безперервністю та ізоляцією розмов:
+    Сеанси керують безперервністю та ізоляцією розмови:
 
     ```json5
     {
@@ -319,12 +319,12 @@ Gateway зберігає довірену останню справну копі
 
     - `dmScope`: `main` (спільний) | `per-peer` | `per-channel-peer` | `per-account-channel-peer`
     - `threadBindings`: глобальні типові значення для маршрутизації сеансів, прив’язаних до потоків (Discord підтримує `/focus`, `/unfocus`, `/agents`, `/session idle` і `/session max-age`).
-    - Див. [Керування сеансами](/uk/concepts/session) щодо областей дії, прив’язок ідентичності та політики надсилання.
-    - Див. [повний довідник](/uk/gateway/config-agents#session) щодо всіх полів.
+    - Див. [Керування сеансами](/uk/concepts/session) щодо областей дії, зв’язків ідентичностей і політики надсилання.
+    - Див. [повний довідник](/uk/gateway/config-agents#session) для всіх полів.
 
   </Accordion>
 
-  <Accordion title="Enable sandboxing">
+  <Accordion title="Увімкнути ізоляцію">
     Запускайте сеанси агентів в ізольованих середовищах sandbox:
 
     ```json5
@@ -340,16 +340,16 @@ Gateway зберігає довірену останню справну копі
     }
     ```
 
-    Спочатку зберіть образ — з робочої копії джерельного коду запустіть `scripts/sandbox-setup.sh`, або для встановлення з npm див. вбудовану команду `docker build` у розділі [Sandboxing § Образи й налаштування](/uk/gateway/sandboxing#images-and-setup).
+    Спочатку зберіть образ — з вихідного checkout виконайте `scripts/sandbox-setup.sh`, або для встановлення з npm див. вбудовану команду `docker build` у [Sandboxing § Images and setup](/uk/gateway/sandboxing#images-and-setup).
 
-    Див. [Sandboxing](/uk/gateway/sandboxing) для повного посібника та [повний довідник](/uk/gateway/config-agents#agentsdefaultssandbox) щодо всіх параметрів.
+    Див. [Sandboxing](/uk/gateway/sandboxing) для повного посібника та [повний довідник](/uk/gateway/config-agents#agentsdefaultssandbox) для всіх параметрів.
 
   </Accordion>
 
-  <Accordion title="Enable relay-backed push for official iOS builds">
-    Push через relay налаштовується в `openclaw.json`.
+  <Accordion title="Увімкнути push через ретранслятор для офіційних збірок iOS">
+    Push через ретранслятор налаштовується в `openclaw.json`.
 
-    Установіть це в конфігурації Gateway:
+    Задайте це в конфігурації Gateway:
 
     ```json5
     {
@@ -375,35 +375,35 @@ Gateway зберігає довірену останню справну копі
 
     Що це робить:
 
-    - Дає Gateway змогу надсилати `push.test`, wake-підштовхування та reconnect wake через зовнішній relay.
-    - Використовує дозвіл на надсилання з областю дії реєстрації, пересланий спарованим застосунком iOS. Gateway не потребує relay-токена для всього розгортання.
-    - Прив’язує кожну реєстрацію через relay до ідентичності Gateway, з яким спарований застосунок iOS, тож інший Gateway не може повторно використати збережену реєстрацію.
-    - Залишає локальні/ручні збірки iOS на прямих APNs. Надсилання через relay застосовується лише до офіційних розповсюджуваних збірок, зареєстрованих через relay.
-    - Має відповідати базовій URL-адресі relay, вбудованій в офіційну/TestFlight збірку iOS, щоб трафік реєстрації та надсилання доходив до того самого розгортання relay.
+    - Дає Gateway змогу надсилати `push.test`, сигнали пробудження та пробудження для повторного підключення через зовнішній ретранслятор.
+    - Використовує дозвіл на надсилання, прив’язаний до реєстрації, який пересилає спарений застосунок iOS. Gateway не потребує токена ретранслятора для всього розгортання.
+    - Прив’язує кожну реєстрацію через ретранслятор до ідентичності Gateway, з якою спарено застосунок iOS, тому інший Gateway не може повторно використати збережену реєстрацію.
+    - Залишає локальні/ручні збірки iOS на прямих APNs. Надсилання через ретранслятор застосовується лише до офіційних розповсюджених збірок, які зареєструвалися через ретранслятор.
+    - Має збігатися з базовим URL ретранслятора, вбудованим в офіційну/TestFlight збірку iOS, щоб трафік реєстрації й надсилання потрапляв до того самого розгортання ретранслятора.
 
     Наскрізний потік:
 
-    1. Установіть офіційну/TestFlight збірку iOS, скомпільовану з тією самою базовою URL-адресою relay.
+    1. Установіть офіційну/TestFlight збірку iOS, скомпільовану з тим самим базовим URL ретранслятора.
     2. Налаштуйте `gateway.push.apns.relay.baseUrl` на Gateway.
-    3. Спаруйте застосунок iOS із Gateway і дайте сеансам вузла та оператора під’єднатися.
-    4. Застосунок iOS отримує ідентичність Gateway, реєструється в relay за допомогою App Attest і квитанції застосунку, а потім публікує payload `push.apns.register` через relay до спарованого Gateway.
-    5. Gateway зберігає relay handle і дозвіл на надсилання, а потім використовує їх для `push.test`, wake-підштовхувань і reconnect wake.
+    3. Спарте застосунок iOS із Gateway і дайте підключитися сеансам вузла та оператора.
+    4. Застосунок iOS отримує ідентичність Gateway, реєструється в ретрансляторі за допомогою App Attest і квитанції застосунку, а потім публікує payload `push.apns.register` через ретранслятор у спарений Gateway.
+    5. Gateway зберігає handle ретранслятора й дозвіл на надсилання, а потім використовує їх для `push.test`, сигналів пробудження та пробуджень для повторного підключення.
 
     Операційні примітки:
 
-    - Якщо ви перемикаєте застосунок iOS на інший Gateway, перепід’єднайте застосунок, щоб він міг опублікувати нову relay-реєстрацію, прив’язану до цього Gateway.
-    - Якщо ви випускаєте нову збірку iOS, яка вказує на інше розгортання relay, застосунок оновлює свою кешовану relay-реєстрацію замість повторного використання старого походження relay.
+    - Якщо перемкнути застосунок iOS на інший Gateway, повторно підключіть застосунок, щоб він міг опублікувати нову реєстрацію ретранслятора, прив’язану до цього Gateway.
+    - Якщо випустити нову збірку iOS, яка вказує на інше розгортання ретранслятора, застосунок оновлює кешовану реєстрацію ретранслятора замість повторного використання старого походження ретранслятора.
 
     Примітка щодо сумісності:
 
     - `OPENCLAW_APNS_RELAY_BASE_URL` і `OPENCLAW_APNS_RELAY_TIMEOUT_MS` усе ще працюють як тимчасові перевизначення env.
-    - `OPENCLAW_APNS_RELAY_ALLOW_HTTP=true` залишається аварійним варіантом розробки лише для local loopback; не зберігайте HTTP URL-адреси relay у конфігурації.
+    - `OPENCLAW_APNS_RELAY_ALLOW_HTTP=true` залишається обхідним механізмом розробки лише для local loopback; не зберігайте HTTP URL ретранслятора в конфігурації.
 
-    Див. [Застосунок iOS](/uk/platforms/ios#relay-backed-push-for-official-builds) щодо наскрізного потоку та [Автентифікація й потік довіри](/uk/platforms/ios#authentication-and-trust-flow) щодо моделі безпеки relay.
+    Див. [Застосунок iOS](/uk/platforms/ios#relay-backed-push-for-official-builds) щодо наскрізного потоку та [Автентифікація й потік довіри](/uk/platforms/ios#authentication-and-trust-flow) щодо моделі безпеки ретранслятора.
 
   </Accordion>
 
-  <Accordion title="Set up heartbeat (periodic check-ins)">
+  <Accordion title="Налаштувати Heartbeat (періодичні перевірки)">
     ```json5
     {
       agents: {
@@ -417,14 +417,14 @@ Gateway зберігає довірену останню справну копі
     }
     ```
 
-    - `every`: рядок тривалості (`30m`, `2h`). Установіть `0m`, щоб вимкнути.
+    - `every`: рядок тривалості (`30m`, `2h`). Задайте `0m`, щоб вимкнути.
     - `target`: `last` | `none` | `<channel-id>` (наприклад `discord`, `matrix`, `telegram` або `whatsapp`)
     - `directPolicy`: `allow` (типово) або `block` для цілей Heartbeat у стилі DM
     - Див. [Heartbeat](/uk/gateway/heartbeat) для повного посібника.
 
   </Accordion>
 
-  <Accordion title="Configure cron jobs">
+  <Accordion title="Налаштувати завдання Cron">
     ```json5
     {
       cron: {
@@ -439,13 +439,13 @@ Gateway зберігає довірену останню справну копі
     }
     ```
 
-    - `sessionRetention`: видаляти завершені ізольовані сеанси запусків із `sessions.json` (типово `24h`; установіть `false`, щоб вимкнути).
-    - `runLog`: обрізати `cron/runs/<jobId>.jsonl` за розміром і кількістю збережених рядків.
-    - Див. [завдання Cron](/uk/automation/cron-jobs) для огляду можливостей і прикладів CLI.
+    - `sessionRetention`: очищати завершені ізольовані сеанси запусків із `sessions.json` (типово `24h`; задайте `false`, щоб вимкнути).
+    - `runLog`: очищати `cron/runs/<jobId>.jsonl` за розміром і кількістю збережених рядків.
+    - Див. [Завдання Cron](/uk/automation/cron-jobs) для огляду можливості та прикладів CLI.
 
   </Accordion>
 
-  <Accordion title="Set up webhooks (hooks)">
+  <Accordion title="Налаштувати Webhook-и (hooks)">
     Увімкніть HTTP Webhook endpoints на Gateway:
 
     ```json5
@@ -472,17 +472,17 @@ Gateway зберігає довірену останню справну копі
     Примітка щодо безпеки:
     - Вважайте весь вміст payload hook/webhook ненадійними вхідними даними.
     - Використовуйте окремий `hooks.token`; не використовуйте повторно спільний токен Gateway.
-    - Автентифікація hook працює лише через заголовки (`Authorization: Bearer ...` або `x-openclaw-token`); токени в рядку запиту відхиляються.
-    - `hooks.path` не може бути `/`; тримайте вхід webhook на виділеному підшляху, наприклад `/hooks`.
+    - Автентифікація hook працює лише через заголовки (`Authorization: Bearer ...` або `x-openclaw-token`); токени в query string відхиляються.
+    - `hooks.path` не може бути `/`; тримайте вхідний Webhook на окремому підшляху, наприклад `/hooks`.
     - Тримайте прапорці обходу небезпечного вмісту вимкненими (`hooks.gmail.allowUnsafeExternalContent`, `hooks.mappings[].allowUnsafeExternalContent`), якщо не виконуєте вузько обмежене налагодження.
-    - Якщо ви вмикаєте `hooks.allowRequestSessionKey`, також установіть `hooks.allowedSessionKeyPrefixes`, щоб обмежити ключі сеансів, вибрані викликачем.
-    - Для агентів, керованих hook, віддавайте перевагу потужним сучасним рівням моделей і суворій політиці інструментів (наприклад, лише обмін повідомленнями плюс sandbox, де можливо).
+    - Якщо ввімкнути `hooks.allowRequestSessionKey`, також задайте `hooks.allowedSessionKeyPrefixes`, щоб обмежити ключі сеансів, вибрані викликачем.
+    - Для агентів, керованих hook, віддавайте перевагу сильним сучасним рівням моделей і суворій політиці інструментів (наприклад, лише обмін повідомленнями плюс sandboxing, де можливо).
 
-    Див. [повний довідник](/uk/gateway/configuration-reference#hooks) щодо всіх параметрів зіставлення та інтеграції Gmail.
+    Див. [повний довідник](/uk/gateway/configuration-reference#hooks) для всіх параметрів зіставлення та інтеграції Gmail.
 
   </Accordion>
 
-  <Accordion title="Configure multi-agent routing">
+  <Accordion title="Налаштувати маршрутизацію кількох агентів">
     Запускайте кілька ізольованих агентів з окремими робочими просторами та сеансами:
 
     ```json5
@@ -500,12 +500,12 @@ Gateway зберігає довірену останню справну копі
     }
     ```
 
-    Див. [Multi-Agent](/uk/concepts/multi-agent) і [повний довідник](/uk/gateway/config-agents#multi-agent-routing) щодо правил прив’язування та профілів доступу для кожного агента.
+    Див. [Multi-Agent](/uk/concepts/multi-agent) і [повний довідник](/uk/gateway/config-agents#multi-agent-routing) щодо правил прив’язки та профілів доступу для кожного агента.
 
   </Accordion>
 
-  <Accordion title="Split config into multiple files ($include)">
-    Використовуйте `$include`, щоб упорядковувати великі конфігурації:
+  <Accordion title="Розділити конфігурацію на кілька файлів ($include)">
+    Використовуйте `$include`, щоб упорядкувати великі конфігурації:
 
     ```json5
     // ~/.openclaw/openclaw.json
@@ -519,23 +519,23 @@ Gateway зберігає довірену останню справну копі
     ```
 
     - **Один файл**: замінює об’єкт, що його містить
-    - **Масив файлів**: глибоко об’єднується за порядком (пізніший має пріоритет)
+    - **Масив файлів**: глибоко об’єднується за порядком (пізніший перемагає)
     - **Сусідні ключі**: об’єднуються після include (перевизначають включені значення)
-    - **Вкладені includes**: підтримуються до 10 рівнів углиб
-    - **Відносні шляхи**: розв’язуються відносно файла, що виконує include
-    - **Записи, що належать OpenClaw**: коли запис змінює лише один розділ верхнього рівня,
-      підкріплений include одного файла, наприклад `plugins: { $include: "./plugins.json5" }`,
+    - **Вкладені include**: підтримуються до 10 рівнів углиб
+    - **Відносні шляхи**: розв’язуються відносно файлу, що виконує include
+    - **Записи, якими володіє OpenClaw**: коли запис змінює лише один розділ верхнього рівня,
+      підкріплений include одного файлу, наприклад `plugins: { $include: "./plugins.json5" }`,
       OpenClaw оновлює цей включений файл і залишає `openclaw.json` без змін
-    - **Непідтримуваний наскрізний запис**: root includes, масиви include та includes
-      із сусідніми перевизначеннями закриваються з помилкою для записів, що належать OpenClaw, замість
-      сплющення конфігурації
+    - **Непідтримуваний write-through**: кореневі include, масиви include та include
+      із сусідніми перевизначеннями відмовляють закрито для записів, якими володіє OpenClaw, замість
+      згладжування конфігурації
     - **Обмеження**: шляхи `$include` мають розв’язуватися в межах каталогу, що містить
-      `openclaw.json`. Щоб спільно використовувати дерево між машинами або користувачами, установіть
-      `OPENCLAW_INCLUDE_ROOTS` на список шляхів (`:` у POSIX, `;` у Windows) до
-      додаткових каталогів, на які можуть посилатися includes. Символічні посилання розв’язуються
-      і перевіряються повторно, тому шлях, який лексично розташований у каталозі конфігурації, але чия
-      реальна ціль виходить за межі кожного дозволеного root, усе одно відхиляється.
-    - **Обробка помилок**: зрозумілі помилки для відсутніх файлів, помилок розбору та циклічних includes
+      `openclaw.json`. Щоб спільно використовувати дерево між машинами або користувачами, задайте
+      `OPENCLAW_INCLUDE_ROOTS` як список шляхів (`:` у POSIX, `;` у Windows) до
+      додаткових каталогів, на які можуть посилатися include. Симлінки розв’язуються
+      і перевіряються повторно, тому шлях, який лексично перебуває в каталозі конфігурації, але реальна
+      ціль якого виходить за межі кожного дозволеного кореня, усе одно відхиляється.
+    - **Обробка помилок**: зрозумілі помилки для відсутніх файлів, помилок розбору та циклічних include
 
   </Accordion>
 </AccordionGroup>
@@ -544,31 +544,31 @@ Gateway зберігає довірену останню справну копі
 
 Gateway відстежує `~/.openclaw/openclaw.json` і застосовує зміни автоматично — для більшості налаштувань ручний перезапуск не потрібен.
 
-Прямі редагування файла вважаються ненадійними, доки не пройдуть перевірку. Спостерігач чекає,
-поки тимчасові записи/перейменування редактора стабілізуються, читає фінальний файл і відхиляє
-некоректні зовнішні редагування, відновлюючи останню відому справну конфігурацію. Записи конфігурації,
-що належать OpenClaw, використовують той самий schema gate перед записом; руйнівні перезаписи, як-от
-видалення `gateway.mode` або зменшення файла більш ніж наполовину, відхиляються
+Прямі редагування файлу вважаються ненадійними, доки не пройдуть перевірку. Watcher чекає,
+доки завершаться тимчасові записи/перейменування редактора, читає остаточний файл і відхиляє
+недійсні зовнішні редагування, відновлюючи останню справну конфігурацію. Записи конфігурації,
+якими володіє OpenClaw, використовують той самий schema gate перед записом; руйнівні перезаписи,
+як-от видалення `gateway.mode` або зменшення файлу більш ніж удвічі, відхиляються
 і зберігаються як `.rejected.*` для перевірки.
 
-Виняток становлять помилки локальної валідації Plugin: якщо всі проблеми розташовані під
-`plugins.entries.<id>...`, перезавантаження зберігає поточну конфігурацію та повідомляє про проблему Plugin
-замість відновлення `.last-good`.
+Помилки локальної перевірки Plugin є винятком: якщо всі проблеми перебувають під
+`plugins.entries.<id>...`, перезавантаження зберігає поточну конфігурацію й повідомляє про проблему
+Plugin замість відновлення `.last-good`.
 
-Якщо ви бачите `Config auto-restored from last-known-good` або
-`config reload restored last-known-good config` у журналах, перевірте відповідний
-файл `.clobbered.*` поруч із `openclaw.json`, виправте відхилений payload, а потім запустіть
-`openclaw config validate`. Див. [усунення несправностей Gateway](/uk/gateway/troubleshooting#gateway-restored-last-known-good-config)
+Якщо в журналах ви бачите `Config auto-restored from last-known-good` або
+`config reload restored last-known-good config`, перегляньте відповідний файл
+`.clobbered.*` поруч із `openclaw.json`, виправте відхилений payload, а потім виконайте
+`openclaw config validate`. Див. [Усунення несправностей Gateway](/uk/gateway/troubleshooting#gateway-restored-last-known-good-config)
 для контрольного списку відновлення.
 
 ### Режими перезавантаження
 
-| Режим                  | Поведінка                                                                                |
+| Режим                  | Поведінка                                                                               |
 | ---------------------- | --------------------------------------------------------------------------------------- |
-| **`hybrid`** (типово) | Миттєво гаряче застосовує безпечні зміни. Автоматично перезапускається для критичних.           |
-| **`hot`**              | Гаряче застосовує лише безпечні зміни. Записує попередження, коли потрібен перезапуск — ви виконуєте його самі. |
-| **`restart`**          | Перезапускає Gateway за будь-якої зміни конфігурації, безпечної чи ні.                                 |
-| **`off`**              | Вимикає відстеження файлів. Зміни набирають чинності під час наступного ручного перезапуску.                 |
+| **`hybrid`** (типово)  | Миттєво гаряче застосовує безпечні зміни. Автоматично перезапускається для критичних.   |
+| **`hot`**              | Гаряче застосовує лише безпечні зміни. Записує попередження, коли потрібен перезапуск — ви виконуєте його. |
+| **`restart`**          | Перезапускає Gateway за будь-якої зміни конфігурації, безпечної чи ні.                  |
+| **`off`**              | Вимикає відстеження файлів. Зміни набувають чинності під час наступного ручного перезапуску. |
 
 ```json5
 {
@@ -582,9 +582,9 @@ Gateway відстежує `~/.openclaw/openclaw.json` і застосовує
 
 Більшість полів застосовуються гаряче без простою. У режимі `hybrid` зміни, що потребують перезапуску, обробляються автоматично.
 
-| Категорія          | Поля                                                              | Потрібен перезапуск? |
+| Категорія           | Поля                                                              | Потрібен перезапуск? |
 | ------------------- | ----------------------------------------------------------------- | --------------- |
-| Канали              | `channels.*`, `web` (WhatsApp) — усі вбудовані канали та канали Plugin | Ні              |
+| Канали              | `channels.*`, `web` (WhatsApp) — усі вбудовані канали та Plugin-канали | Ні              |
 | Агент і моделі      | `agent`, `agents`, `models`, `routing`                            | Ні              |
 | Автоматизація       | `hooks`, `cron`, `agent.heartbeat`                                | Ні              |
 | Сеанси й повідомлення | `session`, `messages`                                             | Ні              |
@@ -600,36 +600,35 @@ Gateway відстежує `~/.openclaw/openclaw.json` і застосовує
 ### Планування перезавантаження
 
 Коли ви редагуєте вихідний файл, на який є посилання через `$include`, OpenClaw планує
-перезавантаження на основі макета, заданого у вихідних файлах, а не плаского подання в пам’яті.
-Це зберігає передбачуваність рішень гарячого перезавантаження (гаряче застосування чи перезапуск), навіть коли
+перезавантаження з авторського макета джерела, а не зі сплощеного подання в пам’яті.
+Це зберігає передбачуваність рішень щодо гарячого перезавантаження (гаряче застосування чи перезапуск), навіть коли
 один розділ верхнього рівня міститься у власному включеному файлі, наприклад
-`plugins: { $include: "./plugins.json5" }`. Планування перезавантаження завершується без змін, якщо
-вихідний макет неоднозначний.
+`plugins: { $include: "./plugins.json5" }`. Планування перезавантаження завершується закрито, якщо
+макет джерела неоднозначний.
 
 ## Config RPC (програмні оновлення)
 
-Для інструментів, які записують конфігурацію через Gateway API, надавайте перевагу такому потоку:
+Для інструментів, які записують конфігурацію через API Gateway, віддавайте перевагу такому потоку:
 
-- `config.schema.lookup`, щоб переглянути одне піддерево (поверхневий вузол схеми + підсумки
-  дочірніх елементів)
+- `config.schema.lookup`, щоб переглянути одне піддерево (поверхневий вузол схеми + зведення дочірніх елементів)
 - `config.get`, щоб отримати поточний знімок разом із `hash`
 - `config.patch` для часткових оновлень (JSON merge patch: об’єкти об’єднуються, `null`
   видаляє, масиви замінюються)
-- `config.apply` лише коли ви маєте намір замінити всю конфігурацію
-- `update.run` для явного самооновлення з перезапуском
-- `update.status`, щоб переглянути найновіший сторожовий маркер перезапуску оновлення й перевірити запущену версію після перезапуску
+- `config.apply` лише тоді, коли ви маєте намір замінити всю конфігурацію
+- `update.run` для явного самооновлення з перезапуском; додайте `continuationMessage`, коли після перезапуску сеанс має виконати один наступний хід
+- `update.status`, щоб переглянути останній sentinel перезапуску оновлення та перевірити запущену версію після перезапуску
 
-Агенти мають розглядати `config.schema.lookup` як перше місце для точних
+Агенти мають розглядати `config.schema.lookup` як першу точку для точних
 документів і обмежень на рівні полів. Використовуйте [Довідник конфігурації](/uk/gateway/configuration-reference),
-коли потрібна ширша мапа конфігурації, значення за замовчуванням або посилання на окремі
+коли їм потрібні ширша карта конфігурації, типові значення або посилання на окремі
 довідники підсистем.
 
 <Note>
-Записи рівня керування (`config.apply`, `config.patch`, `update.run`) мають
-обмеження частоти до 3 запитів на 60 секунд для кожної пари `deviceId+clientIp`. Запити на перезапуск
-об’єднуються, а потім застосовують 30-секундне очікування між циклами перезапуску.
-`update.status` доступний лише для читання, але обмежений адміністраторською областю, бо сторожовий маркер перезапуску може
-містити підсумки кроків оновлення та кінцеві фрагменти виводу команд.
+Записи площини керування (`config.apply`, `config.patch`, `update.run`)
+обмежені частотою до 3 запитів за 60 секунд на `deviceId+clientIp`. Запити на перезапуск
+об’єднуються, а потім застосовують 30-секундне охолодження між циклами перезапуску.
+`update.status` доступний лише для читання, але обмежений адміністративною областю, бо sentinel перезапуску може
+містити зведення кроків оновлення та хвости виводу команд.
 </Note>
 
 Приклад часткового патча:
@@ -643,17 +642,17 @@ openclaw gateway call config.patch --params '{
 ```
 
 І `config.apply`, і `config.patch` приймають `raw`, `baseHash`, `sessionKey`,
-`note` та `restartDelayMs`. `baseHash` є обов’язковим для обох методів, коли
+`note` і `restartDelayMs`. `baseHash` є обов’язковим для обох методів, коли
 конфігурація вже існує.
 
 ## Змінні середовища
 
 OpenClaw читає змінні середовища з батьківського процесу, а також із:
 
-- `.env` з поточного робочого каталогу (якщо він існує)
+- `.env` з поточного робочого каталогу (якщо є)
 - `~/.openclaw/.env` (глобальний резервний варіант)
 
-Жоден із цих файлів не перевизначає наявні змінні середовища. Ви також можете задати вбудовані змінні середовища в конфігурації:
+Жоден із файлів не перевизначає наявні змінні середовища. Ви також можете задавати вбудовані змінні середовища в конфігурації:
 
 ```json5
 {
@@ -665,7 +664,7 @@ OpenClaw читає змінні середовища з батьківсько
 ```
 
 <Accordion title="Імпорт середовища оболонки (необов’язково)">
-  Якщо ввімкнено і очікувані ключі не задані, OpenClaw запускає вашу login shell та імпортує лише відсутні ключі:
+  Якщо ввімкнено й очікувані ключі не задані, OpenClaw запускає вашу оболонку входу та імпортує лише відсутні ключі:
 
 ```json5
 {
@@ -690,9 +689,9 @@ OpenClaw читає змінні середовища з батьківсько
 
 Правила:
 
-- Збігаються лише імена у верхньому регістрі: `[A-Z_][A-Z0-9_]*`
+- Зіставляються лише імена у верхньому регістрі: `[A-Z_][A-Z0-9_]*`
 - Відсутні або порожні змінні спричиняють помилку під час завантаження
-- Екрануйте за допомогою `$${VAR}` для буквального виводу
+- Екрануйте через `$${VAR}` для буквального виводу
 - Працює всередині файлів `$include`
 - Вбудована підстановка: `"${BASE}/v1"` → `"https://api.example.com/v1"`
 
@@ -731,15 +730,15 @@ OpenClaw читає змінні середовища з батьківсько
 }
 ```
 
-Подробиці SecretRef (зокрема `secrets.providers` для `env`/`file`/`exec`) наведено в [Керуванні секретами](/uk/gateway/secrets).
-Підтримувані шляхи облікових даних перелічено в [Поверхні облікових даних SecretRef](/uk/reference/secretref-credential-surface).
+Відомості про SecretRef (зокрема `secrets.providers` для `env`/`file`/`exec`) наведено в [Керуванні секретами](/uk/gateway/secrets).
+Підтримувані шляхи облікових даних наведено в [Поверхні облікових даних SecretRef](/uk/reference/secretref-credential-surface).
 </Accordion>
 
-Див. [Середовище](/uk/help/environment), щоб отримати повний порядок пріоритету та джерела.
+Див. [Середовище](/uk/help/environment) для повного пріоритету та джерел.
 
 ## Повний довідник
 
-Повний довідник за кожним полем див. у **[Довіднику конфігурації](/uk/gateway/configuration-reference)**.
+Повний довідник по кожному полю див. у **[Довіднику конфігурації](/uk/gateway/configuration-reference)**.
 
 ---
 

docs/uk/gateway/protocol.md

@@ -1,35 +1,35 @@
 ---
 read_when:
-    - Реалізація або оновлення WS-клієнтів Gateway
+    - Реалізація або оновлення WS-клієнтів для Gateway
     - Налагодження невідповідностей протоколу або збоїв підключення
     - Повторне генерування схеми/моделей протоколу
-summary: 'Протокол WebSocket Gateway: рукостискання, кадри, версіонування'
+summary: 'Протокол WebSocket Gateway: рукостискання, фрейми, версіонування'
 title: Протокол Gateway
 x-i18n:
-    generated_at: "2026-05-03T00:43:06Z"
+    generated_at: "2026-05-03T12:48:04Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 06f6e1f2188860362bff481e646bd1c4bae4cf8f9a9ccae4fbd5ceea434d2247
+    source_hash: 238706fcecd8ca96394402714cde5b01fb296de8e7b5a5867b1b3cf5b7940689
     source_path: gateway/protocol.md
     workflow: 16
 ---
 
-Gateway WS-протокол є **єдиною площиною керування + транспортом Node** для
-OpenClaw. Усі клієнти (CLI, веб UI, застосунок macOS, iOS/Android Node,
-безголові Node) підключаються через WebSocket і оголошують свою **роль** +
-**область дії** під час handshake.
+Протокол Gateway WS є **єдиною площиною керування + транспортом вузлів** для
+OpenClaw. Усі клієнти (CLI, вебінтерфейс, застосунок macOS, вузли iOS/Android, headless
+вузли) підключаються через WebSocket і оголошують свою **роль** + **scope** під час
+handshake.
 
 ## Транспорт
 
-- WebSocket, текстові кадри з JSON-навантаженнями.
-- Перший кадр **має** бути запитом `connect`.
-- Кадри до підключення обмежені 64 KiB. Після успішного handshake клієнти
-  мають дотримуватися обмежень `hello-ok.policy.maxPayload` і
+- WebSocket, текстові фрейми з JSON-навантаженнями.
+- Перший фрейм **має** бути запитом `connect`.
+- Фрейми до підключення обмежені 64 KiB. Після успішного handshake клієнти
+  мають дотримуватися лімітів `hello-ok.policy.maxPayload` і
   `hello-ok.policy.maxBufferedBytes`. Коли діагностику ввімкнено,
-  завеликі вхідні кадри та повільні вихідні буфери створюють події `payload.large`
-  перед тим, як gateway закриє або відкине відповідний кадр. Ці події зберігають
-  розміри, обмеження, поверхні та безпечні коди причин. Вони не зберігають тіло
-  повідомлення, вміст вкладень, сире тіло кадру, токени, cookies або секретні значення.
+  завеликі вхідні фрейми та повільні вихідні буфери створюють події `payload.large`
+  до того, як Gateway закриє або відкине відповідний фрейм. Ці події зберігають
+  розміри, ліміти, поверхні та безпечні коди причин. Вони не зберігають тіло
+  повідомлення, вміст вкладень, сире тіло фрейму, токени, cookies або секретні значення.
 
 ## Handshake (connect)
 
@@ -104,17 +104,17 @@ Gateway → Клієнт:
 }
 ```
 
-Поки Gateway ще завершує запуск sidecar-компонентів, запит `connect` може
-повернути помилку `UNAVAILABLE`, яку можна повторити, з `details.reason`, заданим як
+Поки Gateway ще завершує запуск допоміжних sidecar-компонентів, запит `connect` може
+повернути повторювану помилку `UNAVAILABLE` з `details.reason`, встановленим у
 `"startup-sidecars"`, і `retryAfterMs`. Клієнти мають повторити цю відповідь
-у межах свого загального бюджету підключення, а не показувати її як кінцевий
+у межах свого загального бюджету підключення, а не показувати її як остаточний
 збій handshake.
 
-`server`, `features`, `snapshot` і `policy` є обов’язковими за схемою
+`server`, `features`, `snapshot` і `policy` усі обов’язкові за схемою
 (`src/gateway/protocol/schema/frames.ts`). `auth` також обов’язковий і повідомляє
-узгоджені роль/області дії. `canvasHostUrl` необов’язковий.
+узгоджені роль/scopes. `canvasHostUrl` необов’язковий.
 
-Коли device token не видано, `hello-ok.auth` повідомляє узгоджені
+Коли токен пристрою не видано, `hello-ok.auth` повідомляє узгоджені
 дозволи без полів токена:
 
 ```json
@@ -127,14 +127,14 @@ Gateway → Клієнт:
 ```
 
 Довірені backend-клієнти в тому самому процесі (`client.id: "gateway-client"`,
-`client.mode: "backend"`) можуть опускати `device` у прямих loopback-підключеннях, коли
-автентифікуються спільним токеном/паролем gateway. Цей шлях зарезервований
-для внутрішніх RPC площини керування й не дає застарілим базовим станам сполучення CLI/device
-блокувати локальну backend-роботу, як-от оновлення сесій subagent. Віддалені клієнти,
-клієнти з browser-origin, клієнти Node і явні клієнти device-token/device-identity
-надалі використовують звичайні перевірки сполучення та підвищення області дії.
+`client.mode: "backend"`) можуть опускати `device` у прямих підключеннях local loopback, коли
+вони автентифікуються спільним токеном/паролем Gateway. Цей шлях зарезервований
+для внутрішніх RPC площини керування й запобігає тому, щоб застарілі базові значення
+спарювання CLI/пристрою блокували локальну backend-роботу, як-от оновлення сесій subagent. Віддалені клієнти,
+клієнти з browser-origin, вузлові клієнти та явні клієнти з токеном пристрою/ідентичністю пристрою
+далі використовують звичайні перевірки спарювання та підвищення scope.
 
-Коли device token видано, `hello-ok` також містить:
+Коли токен пристрою видано, `hello-ok` також містить:
 
 ```json
 {
@@ -166,14 +166,14 @@ Gateway → Клієнт:
 }
 ```
 
-Для вбудованого bootstrap-потоку Node/operator основний токен Node залишається
-`scopes: []`, а будь-який переданий operator-токен залишається обмеженим allowlist
-bootstrap-оператора (`operator.approvals`, `operator.read`,
-`operator.talk.secrets`, `operator.write`). Bootstrap-перевірки областей дії залишаються
-префіксованими роллю: operator-записи задовольняють лише operator-запити, а ролі
-не operator надалі потребують областей дії під власним префіксом ролі.
+Для вбудованого потоку bootstrap вузла/оператора первинний токен вузла лишається
+`scopes: []`, а будь-який переданий токен оператора лишається обмеженим allowlist
+оператора bootstrap (`operator.approvals`, `operator.read`,
+`operator.talk.secrets`, `operator.write`). Перевірки scope bootstrap лишаються
+префіксованими роллю: записи оператора задовольняють лише запити оператора, а ролям не оператора
+далі потрібні scopes під власним префіксом ролі.
 
-### Приклад Node
+### Приклад вузла
 
 ```json
 {
@@ -208,7 +208,7 @@ bootstrap-оператора (`operator.approvals`, `operator.read`,
 }
 ```
 
-## Формат кадрів
+## Фреймування
 
 - **Запит**: `{type:"req", id, method, params}`
 - **Відповідь**: `{type:"res", id, ok, payload|error}`
@@ -216,19 +216,19 @@ bootstrap-оператора (`operator.approvals`, `operator.read`,
 
 Методи з побічними ефектами потребують **ключів ідемпотентності** (див. схему).
 
-## Ролі + області дії
+## Ролі + scopes
 
-Повну модель областей дії operator, перевірки під час схвалення та семантику
-спільного секрету див. у [Області дії operator](/uk/gateway/operator-scopes).
+Повну модель scope оператора, перевірки під час затвердження та семантику спільних секретів
+див. у [Scopes оператора](/uk/gateway/operator-scopes).
 
 ### Ролі
 
 - `operator` = клієнт площини керування (CLI/UI/автоматизація).
 - `node` = хост можливостей (camera/screen/canvas/system.run).
 
-### Області дії (operator)
+### Scopes (оператор)
 
-Поширені області дії:
+Поширені scopes:
 
 - `operator.read`
 - `operator.write`
@@ -240,45 +240,45 @@ bootstrap-оператора (`operator.approvals`, `operator.read`,
 `talk.config` з `includeSecrets: true` потребує `operator.talk.secrets`
 (або `operator.admin`).
 
-Зареєстровані Plugin RPC-методи gateway можуть запитувати власну operator-область дії, але
-зарезервовані префікси core admin (`config.*`, `exec.approvals.*`, `wizard.*`,
-`update.*`) завжди розв’язуються в `operator.admin`.
+RPC-методи Gateway, зареєстровані Plugin, можуть запитувати власний scope оператора, але
+зарезервовані адміністративні префікси ядра (`config.*`, `exec.approvals.*`, `wizard.*`,
+`update.*`) завжди перетворюються на `operator.admin`.
 
-Область дії методу є лише першим бар’єром. Деякі slash-команди, доступні через
-`chat.send`, застосовують суворіші перевірки рівня команди поверх нього. Наприклад, постійні
+Scope методу є лише першою перевіркою. Деякі slash-команди, доступні через
+`chat.send`, застосовують суворіші перевірки рівня команди зверху. Наприклад, постійні
 записи `/config set` і `/config unset` потребують `operator.admin`.
 
-`node.pair.approve` також має додаткову перевірку області дії під час схвалення поверх
-базової області дії методу:
+`node.pair.approve` також має додаткову перевірку scope під час затвердження поверх
+базового scope методу:
 
 - запити без команд: `operator.pairing`
-- запити з командами Node не exec: `operator.pairing` + `operator.write`
+- запити з командами вузла не exec: `operator.pairing` + `operator.write`
 - запити, що містять `system.run`, `system.run.prepare` або `system.which`:
   `operator.pairing` + `operator.admin`
 
-### Можливості/команди/дозволи (Node)
+### Caps/commands/permissions (вузол)
 
-Node оголошують твердження про можливості під час підключення:
+Вузли оголошують заявлені можливості під час підключення:
 
-- `caps`: високорівневі категорії можливостей.
+- `caps`: категорії можливостей високого рівня.
 - `commands`: allowlist команд для invoke.
-- `permissions`: granular-перемикачі (наприклад, `screen.record`, `camera.capture`).
+- `permissions`: детальні перемикачі (наприклад, `screen.record`, `camera.capture`).
 
-Gateway трактує їх як **твердження** і застосовує server-side allowlist.
+Gateway трактує це як **заяви** й застосовує allowlist на стороні сервера.
 
 ## Присутність
 
-- `system-presence` повертає записи, ключовані ідентичністю device.
-- Записи присутності містять `deviceId`, `roles` і `scopes`, щоб UI могли показувати один рядок на device
-  навіть коли він підключається і як **operator**, і як **Node**.
-- `node.list` містить необов’язкові поля `lastSeenAtMs` і `lastSeenReason`. Підключені Node повідомляють
-  свій поточний час підключення як `lastSeenAtMs` з причиною `connect`; спарені Node також можуть повідомляти
-  durable background-присутність, коли довірена подія Node оновлює їхні metadata сполучення.
+- `system-presence` повертає записи, ключовані за ідентичністю пристрою.
+- Записи присутності містять `deviceId`, `roles` і `scopes`, щоб UI могли показувати один рядок на пристрій
+  навіть коли він підключається і як **operator**, і як **node**.
+- `node.list` містить необов’язкові поля `lastSeenAtMs` і `lastSeenReason`. Підключені вузли повідомляють
+  свій поточний час підключення як `lastSeenAtMs` з причиною `connect`; спарені вузли також можуть повідомляти
+  стійку фонову присутність, коли довірена подія вузла оновлює їхні метадані спарювання.
 
-### Подія фонового alive для Node
+### Фонова подія alive вузла
 
-Node можуть викликати `node.event` з `event: "node.presence.alive"`, щоб записати, що спарений Node був
-alive під час фонового wake без позначення його підключеним.
+Вузли можуть викликати `node.event` з `event: "node.presence.alive"`, щоб записати, що спарений вузол був
+активний під час фонового пробудження, не позначаючи його як підключений.
 
 ```json
 {
@@ -288,11 +288,11 @@ alive під час фонового wake без позначення його
 ```
 
 `trigger` є закритим enum: `background`, `silent_push`, `bg_app_refresh`,
-`significant_location`, `manual` або `connect`. Невідомі рядки trigger нормалізуються gateway до
-`background` перед збереженням. Подія є durable лише для автентифікованих device-сесій Node;
-сесії без device або без сполучення повертають `handled: false`.
+`significant_location`, `manual` або `connect`. Невідомі рядки тригера нормалізуються до
+`background` Gateway перед збереженням. Подія є стійкою лише для автентифікованих сесій пристроїв
+вузла; сесії без пристрою або без спарювання повертають `handled: false`.
 
-Успішні gateway повертають структурований результат:
+Успішні Gateway повертають структурований результат:
 
 ```json
 {
@@ -303,246 +303,264 @@ alive під час фонового wake без позначення його
 }
 ```
 
-Старіші gateway все ще можуть повертати `{ "ok": true }` для `node.event`; клієнти мають трактувати це як
-підтверджений RPC, а не як durable-збереження присутності.
+Старіші Gateway можуть досі повертати `{ "ok": true }` для `node.event`; клієнти мають трактувати це як
+підтверджений RPC, а не як стійке збереження присутності.
 
-## Обмеження області дії broadcast-подій
+## Scope широкомовних подій
 
-Server-pushed WebSocket broadcast-події обмежуються областями дії, щоб pairing-scoped або node-only сесії пасивно не отримували вміст сесій.
+Широкомовні події WebSocket, що надсилаються сервером, обмежуються за scope, щоб сесії зі scope спарювання або лише вузлові сесії не отримували пасивно вміст сесій.
 
-- **Кадри chat, agent і результатів інструментів** (включно зі streamed `agent` подіями та результатами tool call) потребують щонайменше `operator.read`. Сесії без `operator.read` повністю пропускають ці кадри.
-- **Plugin-визначені broadcast-події `plugin.*`** обмежуються `operator.write` або `operator.admin`, залежно від того, як Plugin їх зареєстрував.
-- **Події статусу й транспорту** (`heartbeat`, `presence`, `tick`, життєвий цикл connect/disconnect тощо) залишаються необмеженими, щоб transport health була видимою для кожної автентифікованої сесії.
-- **Невідомі родини broadcast-подій** за замовчуванням обмежуються областями дії (fail-closed), якщо зареєстрований handler явно не послаблює їх.
+- **Фрейми чату, агента й результатів інструментів** (включно зі streaming-подіями `agent` і результатами викликів інструментів) потребують щонайменше `operator.read`. Сесії без `operator.read` повністю пропускають ці фрейми.
+- **Визначені Plugin широкомовлення `plugin.*`** обмежуються `operator.write` або `operator.admin` залежно від того, як Plugin їх зареєстрував.
+- **Події статусу й транспорту** (`heartbeat`, `presence`, `tick`, життєвий цикл connect/disconnect тощо) лишаються необмеженими, щоб стан транспорту був видимий кожній автентифікованій сесії.
+- **Невідомі сімейства широкомовних подій** за замовчуванням обмежуються за scope (fail-closed), якщо зареєстрований handler явно не послаблює їх.
 
-Кожне клієнтське підключення зберігає власний per-client порядковий номер, тож broadcasts зберігають монотонний порядок на цьому socket, навіть коли різні клієнти бачать різні scope-filtered підмножини потоку подій.
+Кожне клієнтське підключення зберігає власний порядковий номер на клієнта, щоб широкомовлення зберігали монотонний порядок на цьому сокеті, навіть коли різні клієнти бачать різні підмножини потоку подій, відфільтровані за scope.
 
 ## Поширені сімейства RPC-методів
 
-Публічна WS-поверхня ширша за наведені вище приклади handshake/auth. Це
-не згенерований dump — `hello-ok.features.methods` є консервативним
+Публічна поверхня WS ширша за наведені вище приклади handshake/auth. Це
+не згенерований дамп — `hello-ok.features.methods` є консервативним
 списком discovery, побудованим із `src/gateway/server-methods-list.ts` плюс завантажених
-експортів методів Plugin/channel. Сприймайте його як feature discovery, а не як повний
+експортів методів Plugin/channel. Трактуйте його як discovery функцій, а не як повний
 перелік `src/gateway/server-methods/*.ts`.
 
 <AccordionGroup>
   <Accordion title="Система та ідентичність">
-    - `health` повертає кешований або щойно перевірений health snapshot gateway.
-    - `diagnostics.stability` повертає нещодавній bounded diagnostic stability recorder. Він зберігає operational metadata, як-от назви подій, лічильники, розміри в байтах, показники пам’яті, стан queue/session, назви channel/plugin і ids сесій. Він не зберігає текст chat, тіла webhook, outputs інструментів, сирі тіла request або response, токени, cookies або secret values. Потрібна operator read scope.
-    - `status` повертає `/status`-style summary gateway; sensitive fields включаються лише для operator-клієнтів з admin scope.
-    - `gateway.identity.get` повертає ідентичність device gateway, що використовується потоками relay і pairing.
-    - `system-presence` повертає поточний presence snapshot для підключених operator/node devices.
-    - `system-event` додає system event і може оновлювати/broadcast presence context.
-    - `last-heartbeat` повертає останню persisted heartbeat event.
-    - `set-heartbeats` перемикає heartbeat processing на gateway.
+    - `health` повертає кешований або щойно перевірений snapshot стану Gateway.
+    - `diagnostics.stability` повертає нещодавній обмежений реєстратор діагностичної стабільності. Він зберігає операційні метадані, як-от назви подій, лічильники, розміри в байтах, показники пам’яті, стан черг/сесій, назви channel/plugin та ідентифікатори сесій. Він не зберігає текст чату, тіла webhook, вихід інструментів, сирі тіла запитів або відповідей, токени, cookies або секретні значення. Потрібен scope читання оператора.
+    - `status` повертає зведення Gateway у стилі `/status`; чутливі поля включаються лише для клієнтів operator зі scope admin.
+    - `gateway.identity.get` повертає ідентичність пристрою Gateway, яку використовують потоки relay і спарювання.
+    - `system-presence` повертає поточний snapshot присутності для підключених пристроїв operator/node.
+    - `system-event` додає системну подію та може оновлювати/транслювати контекст присутності.
+    - `last-heartbeat` повертає останню збережену подію heartbeat.
+    - `set-heartbeats` перемикає обробку heartbeat на Gateway.
 
   </Accordion>
 
   <Accordion title="Моделі та використання">
-    - `models.list` повертає каталог моделей, дозволених середовищем виконання. Передайте `{ "view": "configured" }` для налаштованих моделей розміру вибірника (спочатку `agents.defaults.models`, потім `models.providers.*.models`), або `{ "view": "all" }` для повного каталогу.
-    - `usage.status` повертає вікна використання провайдера / підсумки залишкової квоти.
-    - `usage.cost` повертає агреговані підсумки вартості використання для діапазону дат.
-    - `doctor.memory.status` повертає готовність векторної памʼяті / кешованих embedding для активного робочого простору агента за замовчуванням. Передавайте `{ "probe": true }` або `{ "deep": true }` лише коли викликач явно хоче живий ping провайдера embedding.
-    - `doctor.memory.remHarness` повертає обмежений, доступний лише для читання попередній перегляд REM harness для віддалених клієнтів control plane. Він може містити шляхи робочого простору, фрагменти памʼяті, відтворений grounded markdown і кандидатів на глибоке просування, тому викликачам потрібен `operator.read`.
-    - `sessions.usage` повертає підсумки використання за сесіями.
-    - `sessions.usage.timeseries` повертає використання часових рядів для однієї сесії.
+    - `models.list` повертає каталог моделей, дозволених середовищем виконання. Передайте `{ "view": "configured" }` для налаштованих моделей розміру picker (`agents.defaults.models` спершу, потім `models.providers.*.models`) або `{ "view": "all" }` для повного каталогу.
+    - `usage.status` повертає вікна використання провайдера / зведення залишку квоти.
+    - `usage.cost` повертає агреговані зведення витрат за діапазон дат.
+    - `doctor.memory.status` повертає готовність векторної пам'яті / кешованих embedding для робочого простору активного стандартного агента. Передавайте `{ "probe": true }` або `{ "deep": true }` лише коли викликач явно хоче живий ping провайдера embedding.
+    - `doctor.memory.remHarness` повертає обмежений, доступний лише для читання попередній перегляд REM harness для віддалених клієнтів control-plane. Він може містити шляхи робочого простору, фрагменти пам'яті, відрендерений grounded markdown і кандидатів для deep promotion, тому викликачам потрібен `operator.read`.
+    - `sessions.usage` повертає зведення використання для кожної сесії.
+    - `sessions.usage.timeseries` повертає використання у форматі часового ряду для однієї сесії.
     - `sessions.usage.logs` повертає записи журналу використання для однієї сесії.
 
   </Accordion>
 
   <Accordion title="Канали та помічники входу">
-    - `channels.status` повертає підсумки стану вбудованих і комплектних каналів/Plugin.
-    - `channels.logout` виконує вихід із конкретного каналу/облікового запису, якщо канал підтримує вихід.
-    - `web.login.start` запускає QR/web-потік входу для поточного провайдера web-каналу з підтримкою QR.
-    - `web.login.wait` очікує завершення цього QR/web-потоку входу та запускає канал у разі успіху.
-    - `push.test` надсилає тестовий APNs push зареєстрованому iOS Node.
+    - `channels.status` повертає зведення стану вбудованих + пакетних каналів/Plugin.
+    - `channels.logout` виконує вихід із певного каналу/облікового запису, якщо канал підтримує вихід.
+    - `web.login.start` запускає потік входу через QR/web для поточного провайдера web-каналу з підтримкою QR.
+    - `web.login.wait` очікує завершення цього потоку входу через QR/web і запускає канал у разі успіху.
+    - `push.test` надсилає тестовий APNs push на зареєстрований iOS Node.
     - `voicewake.get` повертає збережені тригери wake-word.
     - `voicewake.set` оновлює тригери wake-word і транслює зміну.
 
   </Accordion>
 
   <Accordion title="Повідомлення та журнали">
-    - `send` є прямим outbound-delivery RPC для надсилань поза chat runner, націлених на канал/обліковий запис/тред.
-    - `logs.tail` повертає налаштований tail файлового журналу Gateway з елементами керування cursor/limit і max-byte.
+    - `send` є прямим outbound-delivery RPC для надсилань, націлених на канал/обліковий запис/потік, поза chat runner.
+    - `logs.tail` повертає налаштований хвіст file-log Gateway з керуванням курсором/лімітом і максимальною кількістю байтів.
 
   </Accordion>
 
   <Accordion title="Talk і TTS">
-    - `talk.config` повертає ефективний payload конфігурації Talk; `includeSecrets` потребує `operator.talk.secrets` (або `operator.admin`).
-    - `talk.mode` встановлює/транслює поточний стан режиму Talk для клієнтів WebChat/Control UI.
+    - `talk.config` повертає ефективне навантаження конфігурації Talk; `includeSecrets` потребує `operator.talk.secrets` (або `operator.admin`).
+    - `talk.mode` задає/транслює поточний стан режиму Talk для клієнтів WebChat/Control UI.
     - `talk.speak` синтезує мовлення через активного провайдера мовлення Talk.
-    - `tts.status` повертає стан увімкнення TTS, активного провайдера, fallback-провайдерів і стан конфігурації провайдера.
+    - `tts.status` повертає стан увімкнення TTS, активного провайдера, резервних провайдерів і стан конфігурації провайдера.
     - `tts.providers` повертає видимий інвентар провайдерів TTS.
     - `tts.enable` і `tts.disable` перемикають стан налаштувань TTS.
     - `tts.setProvider` оновлює бажаного провайдера TTS.
-    - `tts.convert` виконує одноразове перетворення text-to-speech.
+    - `tts.convert` виконує одноразове перетворення тексту на мовлення.
 
   </Accordion>
 
   <Accordion title="Секрети, конфігурація, оновлення та майстер">
-    - `secrets.reload` повторно resolve активні SecretRefs і замінює стан секретів середовища виконання лише після повного успіху.
-    - `secrets.resolve` resolve призначення секретів для цільових команд для конкретного набору команд/цілей.
+    - `secrets.reload` повторно розв'язує активні SecretRefs і замінює runtime-стан секретів лише після повного успіху.
+    - `secrets.resolve` розв'язує призначення секретів, націлені на команду, для певного набору команд/цілей.
     - `config.get` повертає поточний знімок конфігурації та hash.
-    - `config.set` записує перевірений payload конфігурації.
-    - `config.patch` обʼєднує часткове оновлення конфігурації.
-    - `config.apply` перевіряє та замінює повний payload конфігурації.
-    - `config.schema` повертає live payload схеми конфігурації, який використовують Control UI та CLI tooling: схема, `uiHints`, версія та метадані генерації, зокрема метадані схем Plugin і каналів, коли середовище виконання може їх завантажити. Схема містить метадані полів `title` / `description`, отримані з тих самих labels і help text, що використовуються UI, зокрема гілки вкладених обʼєктів, wildcard, array-item і композиції `anyOf` / `oneOf` / `allOf`, коли існує відповідна документація полів.
-    - `config.schema.lookup` повертає path-scoped lookup payload для одного шляху конфігурації: нормалізований шлях, shallow schema node, matched hint + `hintPath` і immediate child summaries для UI/CLI drill-down. Lookup schema nodes зберігають користувацьку документацію та поширені поля валідації (`title`, `description`, `type`, `enum`, `const`, `format`, `pattern`, numeric/string/array/object bounds і flags на кшталт `additionalProperties`, `deprecated`, `readOnly`, `writeOnly`). Child summaries показують `key`, нормалізований `path`, `type`, `required`, `hasChildren`, а також matched `hint` / `hintPath`.
-    - `update.run` запускає потік оновлення Gateway і планує перезапуск лише коли саме оновлення успішне. Оновлення package-manager примусово виконують non-deferred, no-cooldown restart після заміни пакета, щоб старий процес Gateway не продовжував lazy-loading із заміненого дерева `dist`.
-    - `update.status` повертає останній кешований update restart sentinel, зокрема версію, що працює після перезапуску, коли вона доступна.
+    - `config.set` записує перевірене навантаження конфігурації.
+    - `config.patch` об'єднує часткове оновлення конфігурації.
+    - `config.apply` перевіряє + замінює повне навантаження конфігурації.
+    - `config.schema` повертає live-навантаження схеми конфігурації, яке використовують інструменти Control UI і CLI: schema, `uiHints`, version і metadata генерації, включно з metadata схем Plugin + каналів, коли середовище виконання може її завантажити. Схема містить metadata полів `title` / `description`, отримані з тих самих міток і довідкового тексту, які використовує UI, включно з вкладеними object, wildcard, array-item і гілками композиції `anyOf` / `oneOf` / `allOf`, коли існує відповідна документація поля.
+    - `config.schema.lookup` повертає path-scoped lookup payload для одного шляху конфігурації: нормалізований шлях, поверхневий вузол schema, відповідний hint + `hintPath` і зведення безпосередніх дочірніх елементів для деталізації в UI/CLI. Вузли lookup schema зберігають користувацьку документацію та спільні поля валідації (`title`, `description`, `type`, `enum`, `const`, `format`, `pattern`, межі numeric/string/array/object, а також прапорці на кшталт `additionalProperties`, `deprecated`, `readOnly`, `writeOnly`). Зведення дочірніх елементів показують `key`, нормалізований `path`, `type`, `required`, `hasChildren`, а також відповідні `hint` / `hintPath`.
+    - `update.run` запускає потік оновлення Gateway і планує перезапуск лише коли саме оновлення виконалося успішно; викликачі із сесією можуть додати `continuationMessage`, щоб запуск відновив один наступний хід агента через чергу продовження після перезапуску. Оновлення через менеджер пакетів примусово виконують невідкладений restart без cooldown після заміни пакета, щоб старий процес Gateway не продовжував lazy-loading із заміненого дерева `dist`.
+    - `update.status` повертає останній кешований sentinel перезапуску після оновлення, включно з версією, що працює після перезапуску, коли вона доступна.
     - `wizard.start`, `wizard.next`, `wizard.status` і `wizard.cancel` надають onboarding wizard через WS RPC.
 
   </Accordion>
 
   <Accordion title="Помічники агента та робочого простору">
-    - `agents.list` повертає налаштовані записи агентів, зокрема ефективну модель і метадані середовища виконання.
-    - `agents.create`, `agents.update` і `agents.delete` керують записами агентів і привʼязкою робочих просторів.
-    - `agents.files.list`, `agents.files.get` і `agents.files.set` керують bootstrap-файлами робочого простору, доступними для агента.
-    - `artifacts.list`, `artifacts.get` і `artifacts.download` надають підсумки артефактів, отриманих із транскрипта, та завантаження для явної області `sessionKey`, `runId` або `taskId`. Запити run і task resolve власну сесію на стороні сервера та повертають лише медіа транскрипта з відповідним provenance; unsafe або local URL sources повертають unsupported downloads замість server-side fetching.
+    - `agents.list` повертає налаштовані записи агентів, включно з ефективною моделлю та runtime metadata.
+    - `agents.create`, `agents.update` і `agents.delete` керують записами агентів і прив'язкою робочого простору.
+    - `agents.files.list`, `agents.files.get` і `agents.files.set` керують bootstrap-файлами робочого простору, відкритими для агента.
+    - `artifacts.list`, `artifacts.get` і `artifacts.download` відкривають transcript-derived зведення артефактів і завантаження для явної області `sessionKey`, `runId` або `taskId`. Запити run і task розв'язують власну сесію на боці сервера та повертають лише transcript media з відповідним походженням; небезпечні або локальні джерела URL повертають unsupported downloads замість server-side fetch.
     - `agent.identity.get` повертає ефективну ідентичність асистента для агента або сесії.
-    - `agent.wait` очікує завершення run і повертає terminal snapshot, коли він доступний.
+    - `agent.wait` очікує завершення запуску й повертає фінальний знімок, коли він доступний.
 
   </Accordion>
 
   <Accordion title="Керування сесіями">
-    - `sessions.list` повертає поточний індекс сесій, зокрема метадані `agentRuntime` за рядками, коли налаштовано backend середовища виконання агента.
+    - `sessions.list` повертає поточний індекс сесій, включно з metadata `agentRuntime` для кожного рядка, коли налаштовано backend runtime агента.
     - `sessions.subscribe` і `sessions.unsubscribe` перемикають підписки на події зміни сесій для поточного WS-клієнта.
-    - `sessions.messages.subscribe` і `sessions.messages.unsubscribe` перемикають підписки на події транскрипта/повідомлень для однієї сесії.
-    - `sessions.preview` повертає обмежені попередні перегляди транскриптів для конкретних ключів сесій.
+    - `sessions.messages.subscribe` і `sessions.messages.unsubscribe` перемикають підписки на transcript/message event для однієї сесії.
+    - `sessions.preview` повертає обмежені попередні перегляди transcript для певних ключів сесій.
     - `sessions.describe` повертає один рядок сесії Gateway для точного ключа сесії.
-    - `sessions.resolve` resolve або canonicalize ціль сесії.
+    - `sessions.resolve` розв'язує або канонізує ціль сесії.
     - `sessions.create` створює новий запис сесії.
     - `sessions.send` надсилає повідомлення в наявну сесію.
-    - `sessions.steer` є варіантом interrupt-and-steer для активної сесії.
-    - `sessions.abort` abort активної роботи для сесії. Викликач може передати `key` плюс необовʼязковий `runId`, або передати лише `runId` для активних runs, які Gateway може resolve до сесії.
-    - `sessions.patch` оновлює метадані/overrides сесії та повідомляє resolved canonical model плюс ефективний `agentRuntime`.
+    - `sessions.steer` є interrupt-and-steer варіантом для активної сесії.
+    - `sessions.abort` перериває активну роботу для сесії. Викликач може передати `key` плюс необов'язковий `runId` або передати лише `runId` для активних запусків, які Gateway може розв'язати до сесії.
+    - `sessions.patch` оновлює metadata/overrides сесії та повідомляє розв'язану канонічну модель плюс ефективний `agentRuntime`.
     - `sessions.reset`, `sessions.delete` і `sessions.compact` виконують обслуговування сесії.
     - `sessions.get` повертає повний збережений рядок сесії.
-    - Виконання чату все ще використовує `chat.history`, `chat.send`, `chat.abort` і `chat.inject`. `chat.history` display-normalized для UI-клієнтів: inline directive tags вилучаються з visible text, plain-text tool-call XML payloads (зокрема `<tool_call>...</tool_call>`, `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`, `<function_calls>...</function_calls>` і truncated tool-call blocks) та leaked ASCII/full-width model control tokens вилучаються, pure silent-token assistant rows на кшталт точних `NO_REPLY` / `no_reply` пропускаються, а oversized rows можуть замінюватися placeholders.
+    - Виконання чату й далі використовує `chat.history`, `chat.send`, `chat.abort` і `chat.inject`. `chat.history` display-normalized для UI-клієнтів: inline directive tags вилучаються з видимого тексту, plain-text XML payload викликів інструментів (включно з `<tool_call>...</tool_call>`, `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>`, `<function_calls>...</function_calls>` і truncated tool-call blocks) та leaked ASCII/full-width model control tokens вилучаються, чисті рядки асистента silent-token, як-от точні `NO_REPLY` / `no_reply`, пропускаються, а надмірно великі рядки можуть замінюватися placeholders.
 
   </Accordion>
 
-  <Accordion title="Сполучення пристроїв і токени пристроїв">
-    - `device.pair.list` повертає pending і approved paired devices.
-    - `device.pair.approve`, `device.pair.reject` і `device.pair.remove` керують записами сполучення пристроїв.
-    - `device.token.rotate` rotate токен paired device у межах його approved role і caller scope bounds.
-    - `device.token.revoke` відкликає токен paired device у межах його approved role і caller scope bounds.
+  <Accordion title="Спарювання пристроїв і токени пристроїв">
+    - `device.pair.list` повертає пристрої в очікуванні та схвалені спарені пристрої.
+    - `device.pair.approve`, `device.pair.reject` і `device.pair.remove` керують записами спарювання пристроїв.
+    - `device.token.rotate` ротує токен спареного пристрою в межах його схваленої ролі та області викликача.
+    - `device.token.revoke` відкликає токен спареного пристрою в межах його схваленої ролі та області викликача.
 
   </Accordion>
 
-  <Accordion title="Сполучення Node, invoke і pending work">
-    - `node.pair.request`, `node.pair.list`, `node.pair.approve`, `node.pair.reject`, `node.pair.remove` і `node.pair.verify` охоплюють сполучення Node і bootstrap verification.
+  <Accordion title="Спарювання Node, виклик і робота в очікуванні">
+    - `node.pair.request`, `node.pair.list`, `node.pair.approve`, `node.pair.reject`, `node.pair.remove` і `node.pair.verify` охоплюють спарювання Node та bootstrap verification.
     - `node.list` і `node.describe` повертають відомий/підключений стан Node.
-    - `node.rename` оновлює label paired Node.
-    - `node.invoke` forwarding команди до підключеного Node.
-    - `node.invoke.result` повертає результат для invoke request.
-    - `node.event` переносить події, що походять із Node, назад у gateway.
-    - `node.canvas.capability.refresh` refresh scoped canvas-capability tokens.
-    - `node.pending.pull` і `node.pending.ack` є API черги connected-node.
+    - `node.rename` оновлює мітку спареного Node.
+    - `node.invoke` пересилає команду на підключений Node.
+    - `node.invoke.result` повертає результат для запиту invoke.
+    - `node.event` переносить події, що походять із Node, назад у Gateway.
+    - `node.canvas.capability.refresh` оновлює scoped canvas-capability tokens.
+    - `node.pending.pull` і `node.pending.ack` є API черги підключеного Node.
     - `node.pending.enqueue` і `node.pending.drain` керують durable pending work для offline/disconnected Node.
 
   </Accordion>
 
   <Accordion title="Сімейства схвалень">
-    - `exec.approval.request`, `exec.approval.get`, `exec.approval.list` і `exec.approval.resolve` охоплюють одноразові запити exec approval плюс lookup/replay pending approvals.
-    - `exec.approval.waitDecision` очікує одне pending exec approval і повертає остаточне рішення (або `null` у разі timeout).
+    - `exec.approval.request`, `exec.approval.get`, `exec.approval.list` і `exec.approval.resolve` охоплюють одноразові запити на схвалення exec плюс lookup/replay схвалень в очікуванні.
+    - `exec.approval.waitDecision` очікує одне pending exec approval і повертає фінальне рішення (або `null` після timeout).
     - `exec.approvals.get` і `exec.approvals.set` керують знімками політики exec approval Gateway.
-    - `exec.approvals.node.get` і `exec.approvals.node.set` керують node-local політикою exec approval через команди node relay.
-    - `plugin.approval.request`, `plugin.approval.list`, `plugin.approval.waitDecision` і `plugin.approval.resolve` охоплюють визначені Plugin потоки approval.
+    - `exec.approvals.node.get` і `exec.approvals.node.set` керують node-local політикою exec approval через node relay commands.
+    - `plugin.approval.request`, `plugin.approval.list`, `plugin.approval.waitDecision` і `plugin.approval.resolve` охоплюють plugin-defined approval flows.
 
   </Accordion>
 
-  <Accordion title="Автоматизація, Skills і інструменти">
-    - Автоматизація: `wake` планує негайну або next-heartbeat інʼєкцію wake text; `cron.list`, `cron.status`, `cron.add`, `cron.update`, `cron.remove`, `cron.run`, `cron.runs` керують scheduled work.
-    - Skills і інструменти: `commands.list`, `skills.*`, `tools.catalog`, `tools.effective`, `tools.invoke`.
+  <Accordion title="Автоматизація, Skills та інструменти">
+    - Автоматизація: `wake` планує негайну або next-heartbeat вставку wake text; `cron.list`, `cron.status`, `cron.add`, `cron.update`, `cron.remove`, `cron.run`, `cron.runs` керують запланованою роботою.
+    - Skills та інструменти: `commands.list`, `skills.*`, `tools.catalog`, `tools.effective`, `tools.invoke`.
 
   </Accordion>
 </AccordionGroup>
 
 ### Поширені сімейства подій
 
-- `chat`: оновлення UI-чату, як-от `chat.inject` та інші transcript-only chat
-  events.
-- `session.message` і `session.tool`: оновлення transcript/event-stream для
-  subscribed session.
-- `sessions.changed`: індекс сесій або метадані змінено.
-- `presence`: оновлення snapshot присутності системи.
-- `tick`: періодична keepalive / liveness подія.
-- `health`: оновлення snapshot стану gateway.
-- `heartbeat`: оновлення потоку подій Heartbeat.
-- `cron`: подія зміни запуску/завдання cron.
-- `shutdown`: сповіщення про shutdown gateway.
-- `node.pair.requested` / `node.pair.resolved`: життєвий цикл сполучення Node.
+- `chat`: оновлення UI чату, як-от `chat.inject` та інші події чату лише для transcript.
+- `session.message` і `session.tool`: оновлення transcript/event-stream для підписаної сесії.
+- `sessions.changed`: індекс сесій або metadata змінилися.
+- `presence`: оновлення знімка системної присутності.
+- `tick`: періодична подія keepalive / liveness.
+- `health`: оновлення знімка стану Gateway.
+- `heartbeat`: оновлення event stream Heartbeat.
+- `cron`: подія зміни Cron run/job.
+- `shutdown`: сповіщення про завершення роботи Gateway.
+- `node.pair.requested` / `node.pair.resolved`: життєвий цикл спарювання Node.
 - `node.invoke.request`: broadcast запиту invoke Node.
-- `device.pair.requested` / `device.pair.resolved`: життєвий цикл paired-device.
-- `voicewake.changed`: конфігурацію wake-word trigger змінено.
+- `device.pair.requested` / `device.pair.resolved`: життєвий цикл спареного пристрою.
+- `voicewake.changed`: конфігурація тригерів wake-word змінилася.
 - `exec.approval.requested` / `exec.approval.resolved`: життєвий цикл exec approval.
-- `plugin.approval.requested` / `plugin.approval.resolved`: життєвий цикл Plugin approval.
+- `plugin.approval.requested` / `plugin.approval.resolved`: життєвий цикл plugin approval.
 
 ### Допоміжні методи Node
 
-- Nodes можуть викликати `skills.bins`, щоб отримати поточний список виконуваних файлів Skills
-  для auto-allow checks.
+- Node можуть викликати `skills.bins`, щоб отримати поточний список виконуваних файлів Skills для перевірок auto-allow.
 
 ### Допоміжні методи оператора
 
-- Оператори можуть викликати `commands.list` (`operator.read`), щоб отримати runtime-інвентар команд для агента.
-  - `agentId` необов’язковий; пропустіть його, щоб прочитати стандартний робочий простір агента.
-  - `scope` керує тим, на яку поверхню націлюється основний `name`:
-    - `text` повертає основний текстовий токен команди без початкового `/`
-    - `native` і стандартний шлях `both` повертають provider-aware нативні назви, коли вони доступні
-  - `textAliases` містить точні slash-псевдоніми, як-от `/model` і `/m`.
-  - `nativeName` містить provider-aware нативну назву команди, коли така існує.
-  - `provider` необов’язковий і впливає лише на нативне іменування та доступність нативних команд Plugin.
+- Оператори можуть викликати `commands.list` (`operator.read`), щоб отримати інвентар команд runtime
+  для агента.
+  - `agentId` необов’язковий; пропустіть його, щоб прочитати робочий простір агента за замовчуванням.
+  - `scope` керує тим, на яку поверхню націлено основний `name`:
+    - `text` повертає основний токен текстової команди без початкового `/`
+    - `native` і стандартний шлях `both` повертають провайдерно-обізнані нативні назви,
+      коли вони доступні
+  - `textAliases` містить точні slash-аліаси, як-от `/model` і `/m`.
+  - `nativeName` містить провайдерно-обізнану нативну назву команди, коли така існує.
+  - `provider` необов’язковий і впливає лише на нативне іменування та доступність
+    нативних команд Plugin.
   - `includeArgs=false` вилучає серіалізовані метадані аргументів із відповіді.
-- Оператори можуть викликати `tools.catalog` (`operator.read`), щоб отримати runtime-каталог інструментів для агента. Відповідь містить згруповані інструменти й метадані походження:
+- Оператори можуть викликати `tools.catalog` (`operator.read`), щоб отримати каталог runtime-інструментів для
+  агента. Відповідь містить згруповані інструменти й метадані походження:
   - `source`: `core` або `plugin`
   - `pluginId`: власник Plugin, коли `source="plugin"`
   - `optional`: чи є інструмент Plugin необов’язковим
-- Оператори можуть викликати `tools.effective` (`operator.read`), щоб отримати runtime-ефективний інвентар інструментів для сеансу.
+- Оператори можуть викликати `tools.effective` (`operator.read`), щоб отримати runtime-ефективний інвентар
+  інструментів для сесії.
   - `sessionKey` обов’язковий.
-  - Gateway виводить довірений runtime-контекст із сеансу на боці сервера замість приймання наданого викликачем контексту автентифікації або доставки.
-  - Відповідь обмежена сеансом і відображає те, що активна розмова може використовувати прямо зараз, включно з інструментами ядра, Plugin і каналу.
-- Оператори можуть викликати `tools.invoke` (`operator.write`), щоб викликати один доступний інструмент через той самий шлях політики Gateway, що й `/tools/invoke`.
-  - `name` обов’язковий. `args`, `sessionKey`, `agentId`, `confirm` і `idempotencyKey` необов’язкові.
-  - Якщо присутні і `sessionKey`, і `agentId`, визначений агент сеансу має збігатися з `agentId`.
-  - Відповідь є конвертом, орієнтованим на SDK, з полями `ok`, `toolName`, необов’язковим `output` і типізованими полями `error`. Відмови через схвалення або політику повертають `ok:false` у payload, а не обходять конвеєр політик інструментів Gateway.
-- Оператори можуть викликати `skills.status` (`operator.read`), щоб отримати видимий інвентар Skills для агента.
-  - `agentId` необов’язковий; пропустіть його, щоб прочитати стандартний робочий простір агента.
-  - Відповідь містить відповідність вимогам, відсутні вимоги, перевірки конфігурації та санітизовані параметри встановлення без розкриття сирих секретних значень.
-- Оператори можуть викликати `skills.search` і `skills.detail` (`operator.read`) для метаданих виявлення ClawHub.
+  - Gateway виводить довірений runtime-контекст із сесії на серверному боці замість приймання
+    auth- або delivery-контексту, наданого викликачем.
+  - Відповідь має сесійний scope і відображає те, що активна розмова може використовувати прямо зараз,
+    включно з core-, Plugin- і channel-інструментами.
+- Оператори можуть викликати `tools.invoke` (`operator.write`), щоб викликати один доступний інструмент через
+  той самий шлях політики Gateway, що й `/tools/invoke`.
+  - `name` обов’язковий. `args`, `sessionKey`, `agentId`, `confirm` і
+    `idempotencyKey` необов’язкові.
+  - Якщо присутні і `sessionKey`, і `agentId`, визначений агент сесії має збігатися з
+    `agentId`.
+  - Відповідь є envelope для SDK з полями `ok`, `toolName`, необов’язковим `output` і типізованими
+    полями `error`. Відмови через схвалення або політику повертають `ok:false` у payload, а не
+    обходять pipeline політики інструментів Gateway.
+- Оператори можуть викликати `skills.status` (`operator.read`), щоб отримати видимий
+  інвентар skill для агента.
+  - `agentId` необов’язковий; пропустіть його, щоб прочитати робочий простір агента за замовчуванням.
+  - Відповідь містить eligibility, відсутні вимоги, перевірки конфігурації та
+    санітизовані параметри встановлення без розкриття сирих secret-значень.
+- Оператори можуть викликати `skills.search` і `skills.detail` (`operator.read`) для
+  метаданих discovery ClawHub.
 - Оператори можуть викликати `skills.install` (`operator.admin`) у двох режимах:
-  - Режим ClawHub: `{ source: "clawhub", slug, version?, force? }` встановлює теку навички в каталог `skills/` стандартного робочого простору агента.
-  - Режим інсталятора Gateway: `{ name, installId, dangerouslyForceUnsafeInstall?, timeoutMs? }` запускає оголошену дію `metadata.openclaw.install` на хості Gateway.
+  - Режим ClawHub: `{ source: "clawhub", slug, version?, force? }` встановлює
+    теку skill у директорію `skills/` робочого простору агента за замовчуванням.
+  - Режим інсталятора Gateway: `{ name, installId, dangerouslyForceUnsafeInstall?, timeoutMs? }`
+    запускає оголошену дію `metadata.openclaw.install` на хості Gateway.
 - Оператори можуть викликати `skills.update` (`operator.admin`) у двох режимах:
-  - Режим ClawHub оновлює один відстежуваний slug або всі відстежувані встановлення ClawHub у стандартному робочому просторі агента.
-  - Режим конфігурації змінює значення `skills.entries.<skillKey>`, як-от `enabled`, `apiKey` і `env`.
+  - Режим ClawHub оновлює один відстежуваний slug або всі відстежувані встановлення ClawHub у
+    робочому просторі агента за замовчуванням.
+  - Режим конфігурації патчить значення `skills.entries.<skillKey>`, як-от `enabled`,
+    `apiKey` і `env`.
 
 ### Подання `models.list`
 
 `models.list` приймає необов’язковий параметр `view`:
 
-- Пропущено або `"default"`: поточна runtime-поведінка. Якщо `agents.defaults.models` налаштовано, відповідь є дозволеним каталогом; інакше відповідь є повним каталогом Gateway.
-- `"configured"`: поведінка розміру picker. Якщо `agents.defaults.models` налаштовано, він усе одно має пріоритет. Інакше відповідь використовує явні записи `models.providers.*.models`, повертаючись до повного каталогу лише тоді, коли немає налаштованих рядків моделей.
-- `"all"`: повний каталог Gateway, обходячи `agents.defaults.models`. Використовуйте це для діагностики та інтерфейсів виявлення, а не для звичайних picker моделей.
+- Пропущено або `"default"`: поточна поведінка runtime. Якщо `agents.defaults.models` налаштовано, відповіддю є дозволений каталог; інакше відповіддю є повний каталог Gateway.
+- `"configured"`: поведінка розміру picker. Якщо `agents.defaults.models` налаштовано, він усе одно має пріоритет. Інакше відповідь використовує явні записи `models.providers.*.models`, повертаючись до повного каталогу лише тоді, коли налаштованих рядків моделей немає.
+- `"all"`: повний каталог Gateway, в обхід `agents.defaults.models`. Використовуйте це для діагностики й discovery UI, а не для звичайних picker моделей.
 
 ## Схвалення exec
 
-- Коли запит exec потребує схвалення, Gateway транслює `exec.approval.requested`.
-- Клієнти оператора вирішують це, викликаючи `exec.approval.resolve` (потрібна область `operator.approvals`).
-- Для `host=node` `exec.approval.request` має містити `systemRunPlan` (канонічні `argv`/`cwd`/`rawCommand`/метадані сеансу). Запити без `systemRunPlan` відхиляються.
-- Після схвалення переслані виклики `node.invoke system.run` повторно використовують цей канонічний `systemRunPlan` як авторитетний контекст команди/cwd/сеансу.
-- Якщо викликач змінює `command`, `rawCommand`, `cwd`, `agentId` або `sessionKey` між підготовкою та фінальним схваленим пересиланням `system.run`, Gateway відхиляє запуск замість того, щоб довіряти зміненому payload.
+- Коли exec-запит потребує схвалення, Gateway транслює `exec.approval.requested`.
+- Клієнти оператора вирішують це викликом `exec.approval.resolve` (потребує scope `operator.approvals`).
+- Для `host=node` `exec.approval.request` має містити `systemRunPlan` (канонічні `argv`/`cwd`/`rawCommand`/метадані сесії). Запити без `systemRunPlan` відхиляються.
+- Після схвалення переслані виклики `node.invoke system.run` повторно використовують цей канонічний
+  `systemRunPlan` як авторитетний контекст команди/cwd/сесії.
+- Якщо викликач змінює `command`, `rawCommand`, `cwd`, `agentId` або
+  `sessionKey` між підготовкою та фінальним схваленим пересиланням `system.run`, Gateway відхиляє запуск замість того, щоб довіряти зміненому payload.
 
-## Резервна доставка агента
+## Резервний варіант delivery агента
 
-- Запити `agent` можуть містити `deliver=true`, щоб запросити вихідну доставку.
-- `bestEffortDeliver=false` зберігає сувору поведінку: нерозв’язані або лише внутрішні цілі доставки повертають `INVALID_REQUEST`.
-- `bestEffortDeliver=true` дозволяє резервний перехід до виконання лише в сеансі, коли неможливо визначити зовнішній доставний маршрут (наприклад, внутрішні/вебчат-сеанси або неоднозначні багатоканальні конфігурації).
+- Запити `agent` можуть містити `deliver=true`, щоб запросити outbound delivery.
+- `bestEffortDeliver=false` зберігає строгий режим: нерозв’язані або лише внутрішні цілі delivery повертають `INVALID_REQUEST`.
+- `bestEffortDeliver=true` дозволяє fallback до виконання лише в сесії, коли жоден зовнішній deliverable route не може бути розв’язаний (наприклад, внутрішні/webchat-сесії або неоднозначні multi-channel конфігурації).
 
 ## Версіонування
 
-- `PROTOCOL_VERSION` розміщено в `src/gateway/protocol/schema/protocol-schemas.ts`.
+- `PROTOCOL_VERSION` міститься в `src/gateway/protocol/schema/protocol-schemas.ts`.
 - Клієнти надсилають `minProtocol` + `maxProtocol`; сервер відхиляє невідповідності.
 - Схеми + моделі генеруються з визначень TypeBox:
   - `pnpm protocol:gen`
@@ -551,143 +569,146 @@ Server-pushed WebSocket broadcast-події обмежуються област
 
 ### Константи клієнта
 
-Еталонний клієнт у `src/gateway/client.ts` використовує ці стандартні значення. Значення стабільні в protocol v3 і є очікуваною базовою лінією для сторонніх клієнтів.
+Референсний клієнт у `src/gateway/client.ts` використовує ці значення за замовчуванням. Значення
+стабільні в межах protocol v3 і є очікуваною базовою лінією для сторонніх клієнтів.
 
-| Константа                                 | Стандартне значення                                  | Джерело                                                                                   |
-| ----------------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------ |
-| `PROTOCOL_VERSION`                        | `3`                                                   | `src/gateway/protocol/schema/protocol-schemas.ts`                                          |
-| Тайм-аут запиту (на RPC)                  | `30_000` ms                                           | `src/gateway/client.ts` (`requestTimeoutMs`)                                               |
-| Тайм-аут preauth / connect-challenge      | `15_000` ms                                           | `src/gateway/handshake-timeouts.ts` (config/env можуть збільшити парний бюджет сервера/клієнта) |
-| Початковий backoff повторного підключення | `1_000` ms                                            | `src/gateway/client.ts` (`backoffMs`)                                                      |
-| Максимальний backoff повторного підключення | `30_000` ms                                         | `src/gateway/client.ts` (`scheduleReconnect`)                                              |
-| Обмеження fast-retry після закриття device-token | `250` ms                                      | `src/gateway/client.ts`                                                                    |
-| Пільговий період force-stop перед `terminate()` | `250` ms                                      | `FORCE_STOP_TERMINATE_GRACE_MS`                                                            |
-| Стандартний тайм-аут `stopAndWait()`      | `1_000` ms                                            | `STOP_AND_WAIT_TIMEOUT_MS`                                                                 |
-| Стандартний інтервал tick (до `hello-ok`) | `30_000` ms                                           | `src/gateway/client.ts`                                                                    |
-| Закриття через tick-timeout               | code `4000`, коли мовчання перевищує `tickIntervalMs * 2` | `src/gateway/client.ts`                                                               |
-| `MAX_PAYLOAD_BYTES`                       | `25 * 1024 * 1024` (25 MB)                            | `src/gateway/server-constants.ts`                                                          |
+| Константа                                 | За замовчуванням                                      | Джерело                                                                                   |
+| ----------------------------------------- | ----------------------------------------------------- | ----------------------------------------------------------------------------------------- |
+| `PROTOCOL_VERSION`                        | `3`                                                   | `src/gateway/protocol/schema/protocol-schemas.ts`                                         |
+| Таймаут запиту (на RPC)                   | `30_000` ms                                           | `src/gateway/client.ts` (`requestTimeoutMs`)                                              |
+| Таймаут preauth / connect-challenge       | `15_000` ms                                           | `src/gateway/handshake-timeouts.ts` (config/env можуть збільшити парний бюджет server/client) |
+| Початковий backoff повторного підключення | `1_000` ms                                            | `src/gateway/client.ts` (`backoffMs`)                                                     |
+| Максимальний backoff повторного підключення | `30_000` ms                                         | `src/gateway/client.ts` (`scheduleReconnect`)                                             |
+| Обмеження швидкого повтору після закриття device-token | `250` ms                                   | `src/gateway/client.ts`                                                                   |
+| Grace force-stop перед `terminate()`      | `250` ms                                              | `FORCE_STOP_TERMINATE_GRACE_MS`                                                           |
+| Стандартний таймаут `stopAndWait()`       | `1_000` ms                                            | `STOP_AND_WAIT_TIMEOUT_MS`                                                                |
+| Стандартний інтервал tick (до `hello-ok`) | `30_000` ms                                           | `src/gateway/client.ts`                                                                   |
+| Закриття через tick-timeout               | code `4000`, коли тиша перевищує `tickIntervalMs * 2` | `src/gateway/client.ts`                                                                   |
+| `MAX_PAYLOAD_BYTES`                       | `25 * 1024 * 1024` (25 MB)                            | `src/gateway/server-constants.ts`                                                         |
 
-Сервер оголошує ефективні `policy.tickIntervalMs`, `policy.maxPayload` і `policy.maxBufferedBytes` у `hello-ok`; клієнти мають дотримуватися цих значень, а не стандартів до handshake.
+Сервер оголошує ефективні `policy.tickIntervalMs`, `policy.maxPayload`
+і `policy.maxBufferedBytes` у `hello-ok`; клієнти мають дотримуватися цих значень,
+а не стандартних значень до handshake.
 
-## Автентифікація
+## Auth
 
 - Автентифікація Gateway зі спільним секретом використовує `connect.params.auth.token` або
   `connect.params.auth.password`, залежно від налаштованого режиму автентифікації.
 - Режими з ідентифікацією, як-от Tailscale Serve
-  (`gateway.auth.allowTailscale: true`) або non-loopback
-  `gateway.auth.mode: "trusted-proxy"`, проходять перевірку автентифікації під час підключення за
-  заголовками запиту замість `connect.params.auth.*`.
-- Приватний вхідний `gateway.auth.mode: "none"` повністю пропускає автентифікацію підключення
-  зі спільним секретом; не відкривайте цей режим на публічному або ненадійному вході.
-- Після спарювання Gateway видає **токен пристрою**, обмежений роллю підключення
-  + областями доступу. Він повертається в `hello-ok.auth.deviceToken`, і клієнт має
-  зберігати його для майбутніх підключень.
+  (`gateway.auth.allowTailscale: true`) або не-loopback
+  `gateway.auth.mode: "trusted-proxy"`, задовольняють перевірку автентифікації підключення через
+  заголовки запиту замість `connect.params.auth.*`.
+- Private-ingress `gateway.auth.mode: "none"` повністю пропускає автентифікацію підключення
+  зі спільним секретом; не відкривайте цей режим на публічному/ненадійному ingress.
+- Після сполучення Gateway видає **токен пристрою**, обмежений роллю підключення
+  + scopes. Він повертається в `hello-ok.auth.deviceToken` і має
+  зберігатися клієнтом для майбутніх підключень.
 - Клієнти мають зберігати основний `hello-ok.auth.deviceToken` після будь-якого
   успішного підключення.
 - Повторне підключення з цим **збереженим** токеном пристрою також має повторно використовувати
-  збережений затверджений набір областей доступу для цього токена. Це зберігає доступ до
-  читання/перевірки/статусу, який уже було надано, і запобігає непомітному звуженню
-  повторних підключень до неявної області лише для адміністратора.
-- Складання автентифікації підключення на боці клієнта (`selectConnectAuth` у
+  збережений затверджений набір scopes для цього токена. Це зберігає доступ
+  read/probe/status, який уже було надано, і не дає повторним підключенням непомітно
+  звузитися до вужчого неявного scope лише для адміністратора.
+- Формування автентифікації підключення на боці клієнта (`selectConnectAuth` у
   `src/gateway/client.ts`):
-  - `auth.password` є незалежним і завжди передається, коли заданий.
-  - `auth.token` заповнюється в порядку пріоритету: спочатку явний спільний токен,
-    потім явний `deviceToken`, потім збережений токен для окремого пристрою (за ключем
+  - `auth.password` є ортогональним і завжди передається, коли його задано.
+  - `auth.token` заповнюється в порядку пріоритету: спершу явний спільний токен,
+    потім явний `deviceToken`, потім збережений токен окремого пристрою (ключований за
     `deviceId` + `role`).
   - `auth.bootstrapToken` надсилається лише тоді, коли жоден із наведених вище варіантів не визначив
     `auth.token`. Спільний токен або будь-який визначений токен пристрою пригнічує його.
-  - Автопідвищення збереженого токена пристрою під час одноразової
-    повторної спроби `AUTH_TOKEN_MISMATCH` дозволене **лише для довірених кінцевих точок** —
+  - Автоматичне підвищення збереженого токена пристрою під час одноразової
+    повторної спроби `AUTH_TOKEN_MISMATCH` дозволене **лише для довірених endpoints** —
     loopback або `wss://` із закріпленим `tlsFingerprint`. Публічний `wss://`
-    без закріплення не підходить.
-- Додаткові записи `hello-ok.auth.deviceTokens` є токенами передавання bootstrap.
+    без pinning не підходить.
+- Додаткові записи `hello-ok.auth.deviceTokens` є bootstrap-токенами передавання.
   Зберігайте їх лише тоді, коли підключення використовувало bootstrap-автентифікацію через довірений транспорт,
-  як-от `wss://` або loopback/local pairing.
+  як-от `wss://` або loopback/локальне сполучення.
 - Якщо клієнт надає **явний** `deviceToken` або явні `scopes`, цей
-  запитаний викликачем набір областей доступу залишається авторитетним; кешовані області доступу
-  повторно використовуються лише тоді, коли клієнт повторно використовує збережений токен для окремого пристрою.
-- Токени пристроїв можна ротувати/відкликати через `device.token.rotate` і
-  `device.token.revoke` (потрібна область доступу `operator.pairing`).
-- `device.token.rotate` повертає метадані ротації. Він дублює замінний
+  запитаний викликачем набір scopes залишається авторитетним; кешовані scopes
+  повторно використовуються лише тоді, коли клієнт повторно використовує збережений токен окремого пристрою.
+- Токени пристрою можна ротувати/відкликати через `device.token.rotate` і
+  `device.token.revoke` (потрібен scope `operator.pairing`).
+- `device.token.rotate` повертає метадані ротації. Він віддзеркалює замінний
   bearer-токен лише для викликів з того самого пристрою, які вже автентифіковані цим
-  токеном пристрою, щоб клієнти, які працюють лише з токеном, могли зберегти заміну перед
-  повторним підключенням. Ротації зі спільним/адміністративним доступом не дублюють bearer-токен.
+  токеном пристрою, щоб клієнти лише з токеном могли зберегти заміну перед
+  повторним підключенням. Ротації через спільний/адміністративний доступ не віддзеркалюють bearer-токен.
 - Видача, ротація та відкликання токенів залишаються обмеженими затвердженим набором ролей,
-  записаним у записі спарювання цього пристрою; зміна токена не може розширити або
-  націлити роль пристрою, яку затвердження спарювання ніколи не надавало.
-- Для сеансів токенів спарених пристроїв керування пристроєм обмежене власним контекстом, якщо
-  викликач також не має `operator.admin`: викликачи без прав адміністратора можуть видаляти/відкликати/ротувати
+  записаним у записі сполучення цього пристрою; мутація токена не може розширити або
+  націлитися на роль пристрою, яку схвалення сполучення ніколи не надавало.
+- Для сесій токенів сполучених пристроїв керування пристроями є самообмеженим, якщо
+  викликач також не має `operator.admin`: викликачі без прав адміністратора можуть видаляти/відкликати/ротувати
   лише запис **власного** пристрою.
-- `device.token.rotate` і `device.token.revoke` також перевіряють цільовий набір областей доступу токена оператора
-  щодо поточних областей доступу сеансу викликача. Викликачи без прав адміністратора
-  не можуть ротувати або відкликати ширший токен оператора, ніж уже мають.
+- `device.token.rotate` і `device.token.revoke` також перевіряють цільовий набір scopes
+  операторського токена щодо поточних scopes сесії викликача. Викликачі без прав адміністратора
+  не можуть ротувати або відкликати ширший операторський токен, ніж уже мають.
 - Помилки автентифікації містять `error.details.code` плюс підказки для відновлення:
-  - `error.details.canRetryWithDeviceToken` (логічне значення)
+  - `error.details.canRetryWithDeviceToken` (boolean)
   - `error.details.recommendedNextStep` (`retry_with_device_token`, `update_auth_configuration`, `update_auth_credentials`, `wait_then_retry`, `review_auth_configuration`)
 - Поведінка клієнта для `AUTH_TOKEN_MISMATCH`:
-  - Довірені клієнти можуть виконати одну обмежену повторну спробу з кешованим токеном для окремого пристрою.
-  - Якщо ця повторна спроба не вдається, клієнти мають зупинити автоматичні цикли повторного підключення й показати вказівки щодо дій оператора.
+  - Довірені клієнти можуть зробити одну обмежену повторну спробу з кешованим токеном окремого пристрою.
+  - Якщо ця повторна спроба завершується невдало, клієнти мають припинити автоматичні цикли повторного підключення та показати оператору вказівки щодо дій.
 
-## Ідентичність пристрою + спарювання
+## Ідентичність пристрою + сполучення
 
-- Вузли мають включати стабільну ідентичність пристрою (`device.id`), отриману з
-  відбитка ключової пари.
-- Gateway видають токени для кожного пристрою + ролі.
-- Для нових ідентифікаторів пристроїв потрібні затвердження спарювання, якщо не ввімкнене
-  локальне автозатвердження.
-- Автозатвердження спарювання зосереджене на прямих підключеннях local loopback.
-- OpenClaw також має вузький шлях локального самопідключення backend/container для
+- Node-и мають містити стабільну ідентичність пристрою (`device.id`), похідну від
+  відбитка keypair.
+- Gateways видають токени для кожного пристрою + ролі.
+- Схвалення сполучення потрібні для нових ідентифікаторів пристроїв, якщо локальне автоматичне схвалення
+  не ввімкнено.
+- Автоматичне схвалення сполучення зосереджене на прямих підключеннях local loopback.
+- OpenClaw також має вузький шлях backend/container-local self-connect для
   довірених допоміжних потоків зі спільним секретом.
-- Підключення того самого хоста через tailnet або LAN усе одно вважаються віддаленими для спарювання та
-  потребують затвердження.
-- WS-клієнти зазвичай включають ідентичність `device` під час `connect` (оператор +
-  вузол). Єдині винятки для оператора без пристрою — явні довірені шляхи:
-  - `gateway.controlUi.allowInsecureAuth=true` для сумісності небезпечного HTTP лише на localhost.
-  - успішна автентифікація оператора Control UI з `gateway.auth.mode: "trusted-proxy"`.
-  - `gateway.controlUi.dangerouslyDisableDeviceAuth=true` (аварійний обхід, серйозне зниження безпеки).
-  - backend RPC-и `gateway-client` через direct-loopback, автентифіковані спільним
-    токеном/паролем Gateway.
+- Підключення same-host tailnet або LAN усе одно вважаються віддаленими для сполучення та
+  потребують схвалення.
+- WS-клієнти зазвичай містять ідентичність `device` під час `connect` (operator +
+  node). Єдині винятки оператора без пристрою — явні шляхи довіри:
+  - `gateway.controlUi.allowInsecureAuth=true` для localhost-only сумісності з небезпечним HTTP.
+  - успішна автентифікація оператора Control UI через `gateway.auth.mode: "trusted-proxy"`.
+  - `gateway.controlUi.dangerouslyDisableDeviceAuth=true` (break-glass, серйозне зниження безпеки).
+  - direct-loopback backend RPC `gateway-client`, автентифіковані спільним
+    токеном/паролем gateway.
 - Усі підключення мають підписувати наданий сервером nonce `connect.challenge`.
 
-### Діагностика міграції автентифікації пристрою
+### Діагностика міграції автентифікації пристроїв
 
 Для застарілих клієнтів, які все ще використовують поведінку підписування до challenge, `connect` тепер повертає
-коди деталей `DEVICE_AUTH_*` у `error.details.code` зі стабільним `error.details.reason`.
+detail-коди `DEVICE_AUTH_*` у `error.details.code` зі стабільним `error.details.reason`.
 
-Поширені збої міграції:
+Поширені помилки міграції:
 
 | Повідомлення                | details.code                     | details.reason           | Значення                                           |
 | --------------------------- | -------------------------------- | ------------------------ | -------------------------------------------------- |
 | `device nonce required`     | `DEVICE_AUTH_NONCE_REQUIRED`     | `device-nonce-missing`   | Клієнт пропустив `device.nonce` (або надіслав порожнє значення). |
 | `device nonce mismatch`     | `DEVICE_AUTH_NONCE_MISMATCH`     | `device-nonce-mismatch`  | Клієнт підписав застарілим/неправильним nonce.     |
-| `device signature invalid`  | `DEVICE_AUTH_SIGNATURE_INVALID`  | `device-signature`       | Корисне навантаження підпису не відповідає навантаженню v2. |
-| `device signature expired`  | `DEVICE_AUTH_SIGNATURE_EXPIRED`  | `device-signature-stale` | Підписана позначка часу виходить за межі дозволеного відхилення. |
+| `device signature invalid`  | `DEVICE_AUTH_SIGNATURE_INVALID`  | `device-signature`       | Payload підпису не відповідає v2 payload.          |
+| `device signature expired`  | `DEVICE_AUTH_SIGNATURE_EXPIRED`  | `device-signature-stale` | Підписана часова позначка поза дозволеним відхиленням. |
 | `device identity mismatch`  | `DEVICE_AUTH_DEVICE_ID_MISMATCH` | `device-id-mismatch`     | `device.id` не відповідає відбитку публічного ключа. |
-| `device public key invalid` | `DEVICE_AUTH_PUBLIC_KEY_INVALID` | `device-public-key`      | Формат/канонікалізація публічного ключа не вдалися. |
+| `device public key invalid` | `DEVICE_AUTH_PUBLIC_KEY_INVALID` | `device-public-key`      | Формат/канонікалізація публічного ключа не вдалася. |
 
 Ціль міграції:
 
 - Завжди чекайте на `connect.challenge`.
-- Підписуйте навантаження v2, яке містить nonce сервера.
+- Підписуйте v2 payload, що містить серверний nonce.
 - Надсилайте той самий nonce у `connect.params.device.nonce`.
-- Бажане корисне навантаження підпису — `v3`, яке прив'язує `platform` і `deviceFamily`
-  на додачу до полів пристрою/клієнта/ролі/областей доступу/токена/nonce.
-- Застарілі підписи `v2` залишаються прийнятими для сумісності, але закріплення метаданих
-  спареного пристрою все одно керує політикою команд під час повторного підключення.
+- Бажаний payload підпису — `v3`, який прив’язує `platform` і `deviceFamily`
+  на додачу до полів device/client/role/scopes/token/nonce.
+- Застарілі підписи `v2` залишаються прийнятними для сумісності, але pinning метаданих
+  сполученого пристрою все одно керує політикою команд під час повторного підключення.
 
-## TLS + закріплення
+## TLS + pinning
 
 - TLS підтримується для WS-підключень.
-- Клієнти можуть за бажанням закріпити відбиток сертифіката Gateway (див. конфігурацію `gateway.tls`
+- Клієнти можуть необов’язково закріпити відбиток сертифіката gateway (див. конфігурацію `gateway.tls`
   плюс `gateway.remote.tlsFingerprint` або CLI `--tls-fingerprint`).
 
-## Область
+## Scope
 
-Цей протокол відкриває **повний API Gateway** (статус, канали, моделі, чат,
-агент, сеанси, вузли, затвердження тощо). Точна поверхня визначається
-схемами TypeBox у `src/gateway/protocol/schema.ts`.
+Цей протокол надає **повний API gateway** (status, channels, models, chat,
+agent, sessions, nodes, approvals тощо). Точна поверхня визначена
+TypeBox-схемами в `src/gateway/protocol/schema.ts`.
 
-## Пов'язане
+## Пов’язане
 
-- [Протокол мосту](/uk/gateway/bridge-protocol)
-- [Операційний посібник Gateway](/uk/gateway)
+- [Протокол bridge](/uk/gateway/bridge-protocol)
+- [Runbook Gateway](/uk/gateway)