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: Граф завдань безперервної інтеграції, межі області дії, релізні парасольки та локальні еквіваленти команд
 title: Конвеєр CI
 x-i18n:
-    generated_at: "2026-05-02T17:33:52Z"
+    generated_at: "2026-05-02T18:57:59Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 9ad5c8b39c21bf3fe6124c64938768efe4b77ef640e8207ef672a80c10291137
+    source_hash: 8533e12d2ea99c6c342db46452bc448099c75e4bfc78edbb4b582118567421fd
     source_path: ci.md
     workflow: 16
 ---
 
-OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає витратні лінії, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно оминають розумне обмеження області й розгортають повний граф для кандидатів на випуск і широкої валідації. Лінії Android залишаються опціональними через `include_android`. Покриття Plugin лише для випусків міститься в окремому workflow [`Попередній випуск Plugin`](#plugin-prerelease) і запускається лише з [`Повної валідації випуску`](#full-release-validation) або явного ручного dispatch.
+OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі лінії, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області та розгортають повний граф для кандидатів на реліз і широкої валідації. Лінії Android залишаються opt-in через `include_android`. Покриття Plugin лише для релізів живе в окремому workflow [`Передреліз Plugin`](#plugin-prerelease) і запускається лише з [`Повної валідації релізу`](#full-release-validation) або явного ручного dispatch.
 
 ## Огляд pipeline
 
-| Завдання                         | Призначення                                                                                                      | Коли запускається                  |
-| -------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------- |
-| `preflight`                      | Виявляє зміни лише в документації, змінені області, змінені extensions і створює CI-маніфест                    | Завжди для 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`                  | Обов’язкова агрегація для швидких завдань безпеки                                                                | Завжди для non-draft push і PR     |
-| `check-dependencies`             | Production-перевірка Knip лише для залежностей плюс guard allowlist невикористаних файлів                       | Зміни, релевантні для Node         |
-| `build-artifacts`                | Збирання `dist/`, Control UI, перевірки зібраних артефактів і багаторазові downstream-артефакти                 | Зміни, релевантні для Node         |
-| `checks-fast-core`               | Швидкі лінії коректності Linux, як-от bundled/plugin-contract/protocol перевірки                                | Зміни, релевантні для Node         |
-| `checks-fast-contracts-channels` | Sharded перевірки контрактів каналів зі стабільним агрегованим результатом перевірки                            | Зміни, релевантні для Node         |
-| `checks-node-core-test`          | Shard-и core Node тестів, окрім ліній channel, bundled, contract і extension                                     | Зміни, релевантні для Node         |
-| `check`                          | Sharded еквівалент головного локального gate: production-типи, lint, guards, test-типи та strict smoke          | Зміни, релевантні для Node         |
-| `check-additional`               | Shard-и архітектури, меж, guards поверхні extension, package-boundary і gateway-watch                           | Зміни, релевантні для Node         |
-| `build-smoke`                    | Smoke-тести зібраного CLI і smoke запуску з пам’яттю                                                             | Зміни, релевантні для Node         |
-| `checks`                         | Верифікатор для channel-тестів зібраних артефактів                                                               | Зміни, релевантні для Node         |
-| `checks-node-compat-node22`      | Лінія збирання сумісності Node 22 і smoke                                                                        | Ручний CI dispatch для випусків    |
-| `check-docs`                     | Форматування документації, lint і перевірки битих посилань                                                       | Документацію змінено               |
-| `skills-python`                  | Ruff + pytest для skills на базі Python                                                                          | Зміни, релевантні для Python-skill |
-| `checks-windows`                 | Специфічні для Windows тести процесів/шляхів плюс regressions спільних runtime import specifier                 | Зміни, релевантні для Windows      |
-| `macos-node`                     | Лінія macOS TypeScript тестів із використанням спільних зібраних артефактів                                      | Зміни, релевантні для macOS        |
-| `macos-swift`                    | Swift lint, збирання і тести для macOS app                                                                       | Зміни, релевантні для macOS        |
-| `android`                        | Android unit-тести для обох flavors плюс одне збирання debug APK                                                | Зміни, релевантні для Android      |
-| `test-performance-agent`         | Щоденна оптимізація повільних тестів Codex після довіреної активності                                            | Успіх Main CI або ручний dispatch  |
-| `openclaw-performance`           | Щоденні/на вимогу звіти продуктивності runtime Kova з mock-provider, deep-profile і live-лініями GPT 5.4        | Запланований і ручний dispatch     |
+| Завдання                         | Призначення                                                                                               | Коли запускається                  |
+| -------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------- |
+| `preflight`                      | Виявляє зміни лише в документації, змінені області, змінені extensions і збирає маніфест CI               | Завжди для 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`                  | Обов’язковий агрегат для швидких завдань безпеки                                                          | Завжди для non-draft push і PR     |
+| `check-dependencies`             | Production-прохід Knip лише для залежностей плюс guard allowlist невикористаних файлів                    | Зміни, релевантні для Node         |
+| `build-artifacts`                | Збірка `dist/`, Control UI, перевірки зібраних артефактів і багаторазові downstream-артефакти             | Зміни, релевантні для Node         |
+| `checks-fast-core`               | Швидкі Linux-лінії коректності, як-от bundled/plugin-contract/protocol перевірки                          | Зміни, релевантні для Node         |
+| `checks-fast-contracts-channels` | Sharded перевірки контрактів каналів зі стабільним агрегованим результатом перевірки                      | Зміни, релевантні для Node         |
+| `checks-node-core-test`          | Shards основних тестів Node, без ліній каналів, bundled, contract і extension                             | Зміни, релевантні для Node         |
+| `check`                          | Sharded еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke         | Зміни, релевантні для Node         |
+| `check-additional`               | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards                 | Зміни, релевантні для Node         |
+| `build-smoke`                    | Smoke-тести зібраного CLI і startup-memory smoke                                                          | Зміни, релевантні для Node         |
+| `checks`                         | Verifier для тестів каналів зібраних артефактів                                                           | Зміни, релевантні для Node         |
+| `checks-node-compat-node22`      | Збірка сумісності з Node 22 і smoke-лінія                                                                 | Ручний CI dispatch для релізів     |
+| `check-docs`                     | Форматування документації, lint і перевірки битих посилань                                                | Документацію змінено               |
+| `skills-python`                  | Ruff + pytest для skills на базі Python                                                                   | Зміни, релевантні для Python skills |
+| `checks-windows`                 | Windows-специфічні тести process/path плюс регресії спільних runtime import specifiers                    | Зміни, релевантні для Windows      |
+| `macos-node`                     | Лінія TypeScript-тестів macOS із використанням спільних зібраних артефактів                               | Зміни, релевантні для macOS        |
+| `macos-swift`                    | Swift lint, build і tests для застосунку macOS                                                            | Зміни, релевантні для macOS        |
+| `android`                        | Android unit tests для обох flavors плюс одна debug APK build                                             | Зміни, релевантні для Android      |
+| `test-performance-agent`         | Щоденна Codex-оптимізація повільних тестів після довіреної активності                                     | Успіх Main CI або ручний dispatch  |
+| `openclaw-performance`           | Щоденні/on-demand звіти продуктивності Kova runtime з mock-provider, deep-profile і GPT 5.4 live lanes    | Запланований і ручний dispatch     |
 
 ## Порядок fail-fast
 
 1. `preflight` вирішує, які лінії взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями.
-2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою, не чекаючи важчих завдань матриці артефактів і платформ.
-3. `build-artifacts` перекривається зі швидкими Linux-лініями, щоб downstream consumers могли стартувати щойно спільне збирання буде готове.
-4. Важчі лінії платформ і runtime розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
+2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи важчих матричних завдань для артефактів і платформ.
+3. `build-artifacts` перекривається зі швидкими Linux-лініями, щоб downstream-споживачі могли стартувати одразу після готовності спільної збірки.
+4. Важчі платформні та runtime-лінії розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
 
-GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє до того самого PR або ref `main`. Вважайте це шумом CI, якщо найновіший запуск для того самого ref також не падає. Агреговані перевірки shard-ів використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні збої shard-ів, але не стають у чергу після того, як увесь workflow уже замінено. Автоматичний ключ конкурентності CI версійований (`CI-v7-*`), тому zombie на стороні GitHub у старій queue group не може нескінченно блокувати новіші main-запуски. Ручні запуски повного набору використовують `CI-manual-v1-*` і не скасовують запуски, що вже виконуються.
+GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо найновіший запуск для того самого ref також не падає. Агреговані перевірки shards використовують `!cancelled() && always()`, тому вони й далі повідомляють звичайні збої shards, але не стають у чергу після того, як весь workflow уже замінено. Автоматичний ключ concurrency CI має версію (`CI-v7-*`), тому zombie з боку GitHub у старій queue group не може безстроково блокувати новіші запуски main. Ручні запуски повного набору використовують `CI-manual-v1-*` і не скасовують запуски, що вже виконуються.
 
 ## Область і маршрутизація
 
-Логіка області міститься в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`. Ручний dispatch пропускає виявлення changed-scope і змушує preflight-маніфест поводитися так, ніби змінилася кожна scoped-ділянка.
+Логіка області живе в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Ручний dispatch пропускає виявлення changed-scope і змушує маніфест preflight діяти так, ніби кожну scoped area було змінено.
 
-- **Редагування CI workflow** валідують Node CI graph плюс workflow linting, але самі собою не примушують запускати Windows, Android або macOS native builds; ці платформні лінії залишаються обмеженими змінами platform source.
-- **Редагування лише CI routing, вибрані дешеві редагування core-test fixture і вузькі редагування plugin contract helper/test-routing** використовують швидкий Node-only шлях маніфесту: `preflight`, security і одне завдання `checks-fast-core`. Цей шлях пропускає build artifacts, сумісність Node 22, channel contracts, повні core shards, bundled-plugin shards і додаткові guard matrices, коли зміна обмежена routing або helper surfaces, які швидке завдання перевіряє напряму.
-- **Windows Node checks** обмежені специфічними для Windows wrappers процесів/шляхів, npm/pnpm/UI runner helpers, package manager config і поверхнями CI workflow, що виконують цю лінію; непов’язані зміни source, plugin, install-smoke і test-only залишаються на Linux Node lanes.
+- **Зміни CI workflow** валідують граф Node CI плюс workflow linting, але самі по собі не примушують Windows, Android або macOS native builds; ці платформні лінії залишаються прив’язаними до змін платформного source.
+- **CI routing-only edits, вибрані дешеві core-test fixture edits і вузькі plugin contract helper/test-routing edits** використовують швидкий шлях маніфесту лише для Node: `preflight`, security і одне завдання `checks-fast-core`. Цей шлях пропускає build artifacts, Node 22 compatibility, channel contracts, full core shards, bundled-plugin shards і додаткові guard matrices, коли зміна обмежена routing або helper surfaces, які fast task перевіряє напряму.
+- **Windows Node checks** прив’язані до Windows-специфічних process/path wrappers, npm/pnpm/UI runner helpers, package manager config і поверхонь CI workflow, які виконують цю лінію; непов’язані source, plugin, install-smoke і test-only зміни залишаються на Linux Node lines.
 
-Найповільніші сімейства Node тестів розділено або збалансовано, щоб кожне завдання залишалося малим без надмірного резервування 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 використовують свої виділені Vitest configs замість спільного plugin catch-all. Include-pattern shards записують timing entries із CI shard name, щоб `.artifacts/vitest-shard-timings.json` міг відрізнити цілий config від відфільтрованого shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards конкурентно всередині одного завдання. Gateway watch, channel tests і core support-boundary shard запускаються конкурентно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані.
+Найповільніші сімейства тестів Node розділені або збалансовані так, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts виконуються як три weighted shards, small 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 і різні plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries із використанням імені CI shard, тому `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; shard boundary guard запускає свої малі незалежні guards паралельно всередині одного завдання. 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 із BuildConfig flags для SMS/call-log, водночас уникаючи дубльованого 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 flags, уникаючи дублювання debug APK packaging job на кожному Android-релевантному push.
 
-Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production-перевірку Knip лише для залежностей, pinned до найновішої версії Knip, з вимкненим minimum release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip із `scripts/deadcode-unused-files.allowlist.mjs`. Guard невикористаних файлів падає, коли PR додає новий непереглянутий невикористаний файл або залишає застарілий запис allowlist, зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може розв’язати статично.
+Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, закріплений на latest Knip version, із вимкненим minimum release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий неперевірений unused file або залишає stale allowlist entry, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично resolve.
 
-## Передавання активності ClawSweeper
+## Перенаправлення активності ClawSweeper
 
-`.github/workflows/clawsweeper-dispatch.yml` — це target-side міст від активності репозиторію OpenClaw до ClawSweeper. Він не checkout-ить і не виконує недовірений код pull request. Workflow створює token GitHub App із `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім надсилає compact payloads `repository_dispatch` до `openclaw/clawsweeper`.
+`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge з активності репозиторію OpenClaw до ClawSweeper. Він не виконує checkout і не запускає недовірений код pull request. Workflow створює GitHub App token з `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім відправляє компактні payloads `repository_dispatch` до `openclaw/clawsweeper`.
 
 Workflow має чотири лінії:
 
-- `clawsweeper_item` для точних запитів на review issue і pull request;
+- `clawsweeper_item` для точних запитів review issue і pull request;
 - `clawsweeper_comment` для явних команд ClawSweeper у коментарях issue;
-- `clawsweeper_commit_review` для commit-level review requests на push до `main`;
-- `github_activity` для загальної активності GitHub, яку агент ClawSweeper може інспектувати.
+- `clawsweeper_commit_review` для запитів review на рівні commit у push до `main`;
+- `github_activity` для загальної активності GitHub, яку агент ClawSweeper може перевірити.
 
-Лінія `github_activity` передає лише нормалізовані метадані: event type, action, actor, repository, item number, URL, title, state і короткі уривки для comments або reviews, коли вони присутні. Вона навмисно уникає передавання повного webhook body. Receiving workflow у `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який публікує нормалізовану подію до OpenClaw Gateway hook для агента ClawSweeper.
+Лінія `github_activity` пересилає лише нормалізовані metadata: event type, action, actor, repository, item number, URL, title, state і короткі excerpts для comments або reviews, коли вони присутні. Вона навмисно уникає пересилання повного webhook body. Приймальний workflow у `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який надсилає нормалізовану event до OpenClaw Gateway hook для агента ClawSweeper.
 
-Загальна активність є спостереженням, а не доставленням за замовчуванням. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли подія є несподіваною, actionable, risky або operationally useful. Routine opens, edits, bot churn, duplicate webhook noise і normal review traffic мають давати результат `NO_REPLY`.
+Загальна активність є спостереженням, а не доставкою за замовчуванням. Агент ClawSweeper отримує Discord target у своєму prompt і має писати до `#clawsweeper` лише тоді, коли event є несподіваною, actionable, risky або operationally useful. Рутинні відкриття, edits, bot churn, duplicate webhook noise і звичайний review traffic мають завершуватися `NO_REPLY`.
 
-Вважайте GitHub titles, comments, bodies, review text, branch names і commit messages недовіреними даними на всьому цьому шляху. Вони є input для summarization і triage, а не інструкціями для workflow або agent runtime.
+Скрізь на цьому шляху вважайте GitHub titles, comments, bodies, review text, branch names і commit messages недовіреними даними. Це input для summarization і triage, а не instructions для workflow або agent runtime.
 
 ## Ручні dispatches
 
-Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну не-Android scoped lane: шарди Linux Node, шарди bundled-plugin, контракти каналів, сумісність Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python skills, Windows, macOS і i18n Control UI. Окремі ручні запуски CI виконують лише Android із `include_android=true`; повна релізна парасолька вмикає Android, передаючи `include_android=true`. Статичні перевірки передрелізу Plugin, релізний лише шард `agentic-plugins`, повний пакетний sweep розширень і Docker lanes передрелізу Plugin виключено з CI. Передрелізний набір Docker запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate перевірки релізу.
+Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну не-Android lane з обмеженою областю: Linux Node шарди, шарди вбудованих Plugin, контракти каналів, сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python Skills, Windows, macOS і i18n Control UI. Окремі ручні запуски CI виконують лише Android з `include_android=true`; повна релізна парасолька вмикає Android через передавання `include_android=true`. Статичні перевірки передрелізу Plugin, релізний шард `agentic-plugins`, повний пакетний sweep розширень і Docker lanes передрелізу Plugin виключені з CI. Передрелізний набір Docker запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate перевірки релізу.
 
-Ручні запуски використовують унікальну concurrency group, тому повний набір release-candidate не скасовується іншим push або запуском PR на тому самому ref. Необов'язковий ввід `target_ref` дає довіреному викликачеві змогу запускати цей граф для гілки, тега або повного commit SHA, використовуючи файл workflow з вибраного dispatch ref.
+Ручні запуски використовують унікальну групу конкурентності, щоб повний набір release-candidate не скасовувався іншим push або PR запуском на тому самому ref. Необов’язковий ввід `target_ref` дає довіреному виклику змогу запустити цей граф для гілки, тегу або повного SHA коміту, використовуючи файл workflow з вибраного dispatch ref.
 
 ```bash
 gh workflow run ci.yml --ref release/YYYY.M.D
@@ -96,19 +96,19 @@ 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-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколів/контрактів/bundled, шардовані перевірки контрактів каналів, шарди `check`, крім lint, шарди й агрегати `check-additional`, перевіряльники агрегатів тестів Node, перевірки документації, Python skills, workflow-sanity, labeler, auto-response; preflight install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла стати в чергу раніше |
+| `ubuntu-24.04`                   | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контрактів/вбудованих пакетів, шардовані перевірки контрактів каналів, шарди `check`, крім lint, шарди та агрегати `check-additional`, верифікатори агрегатів тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла стати в чергу раніше |
 | `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, легші шарди розширень, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types`                                                                                                                                                                                                                                                                                                                               |
-| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів bundled plugin, `android`                                                                                                                                                                                                                                                                                                                                                                          |
-| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (достатньо CPU-чутливий, що 8 vCPU коштували більше, ніж заощаджували); Docker builds install-smoke (час черги 32-vCPU коштував більше, ніж заощаджував)                                                                                                                                                                                                                                                                                                   |
+| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів вбудованих Plugin, `android`                                                                                                                                                                                                                                                                                                                                                                       |
+| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (достатньо чутливий до CPU, щоб 8 vCPU коштували більше, ніж заощаджували); Docker збірки install-smoke (час очікування в черзі на 32-vCPU коштував більше, ніж заощаджував)                                                                                                                                                                                                                                                                                 |
 | `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
-| `blacksmith-6vcpu-macos-latest`  | `macos-node` на `openclaw/openclaw`; forks повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                |
-| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                              |
+| `blacksmith-6vcpu-macos-latest`  | `macos-node` на `openclaw/openclaw`; форки повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                |
+| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; форки повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                               |
 
-## Локальні еквіваленти
+## Локальні відповідники
 
 ```bash
 pnpm changed:lanes                            # inspect the local changed-lane classifier for origin/main...HEAD
@@ -146,27 +146,27 @@ gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1
 
 Workflow встановлює OCM із закріпленого релізу та Kova із закріпленого вводу `kova_ref`, а потім запускає три lanes:
 
-- `mock-provider`: діагностичні сценарії Kova проти runtime локальної збірки з детермінованою фіктивною OpenAI-сумісною автентифікацією.
-- `mock-deep-profile`: CPU/heap/trace профілювання для гарячих точок startup, gateway і agent-turn.
-- `live-gpt54`: реальний agent turn OpenAI `openai/gpt-5.4`, пропускається, коли `OPENAI_API_KEY` недоступний.
+- `mock-provider`: діагностичні сценарії Kova проти runtime локальної збірки з детермінованою фейковою OpenAI-сумісною автентифікацією.
+- `mock-deep-profile`: профілювання CPU/heap/trace для гарячих точок запуску, Gateway і agent-turn.
+- `live-gpt54`: реальний agent turn OpenAI `openai/gpt-5.4`, який пропускається, коли `OPENAI_API_KEY` недоступний.
 
-Lane mock-provider також запускає нативні source probes OpenClaw після проходу Kova: час запуску Gateway і пам'ять у випадках default, hook і запуску з 50-plugin; повторювані цикли hello mock-OpenAI `channel-chat-baseline`; і команди запуску CLI проти запущеного Gateway. Markdown-зведення source probe міститься в `source/index.md` у report bundle, поруч із сирим JSON.
+Lane mock-provider також запускає source probes, рідні для OpenClaw, після проходу Kova: час завантаження Gateway і пам’ять для типових випадків startup default, hook і 50 Plugin; повторювані mock-OpenAI цикли hello `channel-chat-baseline`; і команди запуску CLI проти завантаженого Gateway. Markdown-зведення source probe міститься в `source/index.md` у report bundle, поруч із сирим JSON.
 
-Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і artifacts source-probe в `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` і artifacts source-probe в `openclaw/clawgrit-reports` під `openclaw-performance/<ref>/<run-id>-<attempt>/<lane>/`. Поточний покажчик гілки записується як `openclaw-performance/<ref>/latest-<lane>.json`.
 
 ## Повна перевірка релізу
 
-`Full Release Validation` — це ручний парасольковий workflow для "запустити все перед релізом". Він приймає гілку, тег або повний commit SHA, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного лише proof plugin/package/static/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker release-path, live/E2E, OpenWebUI, parity QA Lab, Matrix і Telegram lanes. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` з release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму package lane Telegram проти опублікованого npm package.
+`Full Release Validation` — це ручний umbrella workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного proof Plugin/пакетів/статики/Docker, а також запускає `OpenClaw Release Checks` для install smoke, package acceptance, Docker release-path наборів, 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 пакета.
 
-Див. [повну перевірку релізу](/uk/reference/full-release-validation) для
+Див. [Повна перевірка релізу](/uk/reference/full-release-validation) для
 матриці етапів, точних назв завдань workflow, відмінностей профілів, artifacts і
 цільових дескрипторів повторного запуску.
 
 `OpenClaw Release Publish` — це ручний мутувальний релізний workflow. Запускайте його
-з `release/YYYY.M.D` або `main` після того, як існує release tag, і після того, як
+з `release/YYYY.M.D` або `main` після того, як релізний тег уже існує і після того, як
 OpenClaw npm preflight успішно завершився. Він перевіряє `pnpm plugins:sync:check`,
-запускає `Plugin NPM Release` для всіх публіковних plugin packages, запускає
-`Plugin ClawHub Release` для того самого release SHA і лише потім запускає
+запускає `Plugin NPM Release` для всіх публіковних Plugin-пакетів, запускає
+`Plugin ClawHub Release` для того самого SHA релізу і лише після цього запускає
 `OpenClaw NPM Release` зі збереженим `preflight_run_id`.
 
 ```bash
@@ -177,47 +177,47 @@ gh workflow run openclaw-release-publish.yml \
   -f npm_dist_tag=beta
 ```
 
-Для pinned commit proof на швидкозмінній гілці використовуйте helper замість
+Для proof закріпленого коміту на гілці, що швидко змінюється, використовуйте helper замість
 `gh workflow run ... --ref main -f ref=<sha>`:
 
 ```bash
 pnpm ci:full-release --sha <full-sha>
 ```
 
-Dispatch refs workflow GitHub мають бути гілками або тегами, а не сирими commit SHA.
-Helper пушить тимчасову гілку `release-ci/<sha>-...` на target SHA,
-запускає `Full Release Validation` з цього pinned ref, перевіряє, що `headSha` кожного дочірнього
-workflow збігається з target, і видаляє тимчасову гілку, коли
-run завершується. Парасольковий verifier також завершується з помилкою, якщо будь-який дочірній workflow виконувався на
+GitHub workflow dispatch refs мають бути гілками або тегами, а не сирими SHA комітів. Helper
+пушить тимчасову гілку `release-ci/<sha>-...` на цільовому SHA,
+запускає `Full Release Validation` із цього закріпленого ref, перевіряє, що кожен дочірній
+workflow `headSha` збігається з ціллю, і видаляє тимчасову гілку після завершення
+запуску. Umbrella verifier також завершується помилкою, якщо будь-який дочірній workflow виконувався на
 іншому SHA.
 
-`release_profile` керує шириною live/provider, переданою в release checks. Ручні
-релізні workflows типово використовують `stable`; використовуйте `full` лише тоді, коли ви
-навмисно хочете широку advisory provider/media matrix.
+`release_profile` керує шириною live/provider, що передається в release checks. Ручні
+релізні workflows типово використовують `stable`; використовуйте `full` лише тоді, коли
+навмисно потрібна широка advisory матриця provider/media.
 
 - `minimum` залишає найшвидші критичні для релізу lanes OpenAI/core.
 - `stable` додає стабільний набір provider/backend.
-- `full` запускає широку advisory provider/media matrix.
+- `full` запускає широку advisory матрицю provider/media.
 
-Парасолька записує IDs запущених дочірніх run, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх run і додає таблиці найповільніших завдань для кожного дочірнього run. Якщо дочірній workflow повторно запущено і він став green, повторно запустіть лише батьківське verifier job, щоб оновити результат парасольки й зведення timings.
+Umbrella записує ids запущених дочірніх run, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх run і додає таблиці найповільніших завдань для кожного дочірнього run. Якщо дочірній workflow запускають повторно і він стає green, повторно запустіть лише батьківське завдання verifier, щоб оновити результат umbrella і зведення часу.
 
-Для відновлення і `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. Це утримує повторний запуск невдалого release box у межах після цільового виправлення.
+Для відновлення і `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` на парасольковому запуску. Це обмежує повторний запуск невдалого релізного бокса після цілеспрямованого виправлення.
 
-`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і до live/E2E Docker workflow release path, і до package acceptance shard. Це зберігає package bytes узгодженими між release boxes і уникає повторного пакування того самого кандидата в кількох дочірніх jobs.
+`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і до workflow Docker для live/E2E релізного шляху, і до шарда приймання пакета. Це зберігає байти пакета узгодженими між релізними боксами й уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
 
 Дублікати запусків `Full Release Validation` для `ref=main` і `rerun_group=all`
-замінюють старіший umbrella. Parent monitor скасовує будь-який дочірній workflow,
-який він уже dispatch, коли parent скасовано, тож новіша валідація main
-не чекає позаду застарілого двогодинного запуску release-check. Валідація release branch/tag
-і цільові rerun groups зберігають `cancel-in-progress: false`.
+замінюють старіший парасольковий запуск. Батьківський монітор скасовує будь-який дочірній workflow, який
+він уже запустив, коли батьківський запуск скасовано, тож новіша валідація main
+не чекає за застарілим двогодинним запуском release-check. Валідація релізної гілки/тега
+та цілеспрямовані групи повторного запуску зберігають `cancel-in-progress: false`.
 
-## Live та E2E shards
+## Live- та E2E-шарди
 
-Дочірній release live/E2E зберігає широке native покриття `pnpm test:live`, але запускає його як іменовані shards через `scripts/test-live-shard.mjs` замість одного послідовного job:
+Дочірній release live/E2E зберігає широке покриття нативного `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання:
 
 - `native-live-src-agents`
 - `native-live-src-gateway-core`
-- provider-filtered jobs `native-live-src-gateway-profiles`
+- завдання `native-live-src-gateway-profiles`, відфільтровані за провайдером
 - `native-live-src-gateway-backends`
 - `native-live-test`
 - `native-live-extensions-a-k`
@@ -225,61 +225,61 @@ run завершується. Парасольковий verifier також з
 - `native-live-extensions-openai`
 - `native-live-extensions-o-z-other`
 - `native-live-extensions-xai`
-- розділені media audio/video shards і provider-filtered music shards
+- розділені шарди медіа audio/video та музичні шарди, відфільтровані за провайдером
 
-Це зберігає те саме файлове покриття, водночас спрощуючи повторний запуск і діагностику повільних збоїв live provider. Агреговані назви shards `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків.
+Це зберігає те саме покриття файлів, водночас спрощуючи повторний запуск і діагностику повільних збоїв live-провайдерів. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` лишаються дійсними для ручних одноразових повторних запусків.
 
-Native live media shards запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media jobs лише перевіряють binaries перед setup. Тримайте Docker-backed live suites на звичайних Blacksmith runners — container jobs є неправильним місцем для запуску вкладених Docker tests.
+Нативні live-медіашарди запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. У цьому образі попередньо встановлено `ffmpeg` і `ffprobe`; медіазавдання лише перевіряють бінарні файли перед налаштуванням. Тримайте live-набори з Docker-підтримкою на звичайних раннерах Blacksmith — контейнерні завдання є неправильним місцем для запуску вкладених Docker-тестів.
 
-Docker-backed live model/backend shards використовують окремий shared image `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного commit. Live release workflow один раз збирає й публікує цей image, а потім 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 job, щоб завислий container або cleanup path швидко падав, а не споживав увесь бюджет release-check. Якщо ці shards незалежно перебудовують повний source Docker target, release run налаштовано неправильно, і він марнуватиме wall clock на дубльовані image builds.
+Live-шарди моделей/backend із Docker-підтримкою використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Release live workflow збирає й публікує цей образ один раз, після чого Docker live model, gateway із шардингом за провайдерами, CLI backend, ACP bind і шарди Codex harness запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker-шарди мають явні обмеження `timeout` на рівні скриптів нижче за timeout завдання workflow, щоб завислий контейнер або шлях очищення швидко падав замість того, щоб споживати весь бюджет release-check. Якщо ці шарди незалежно перебудовують повну Docker-ціль із вихідного коду, релізний запуск налаштовано неправильно, і він марнуватиме час на дубльовані збірки образів.
 
-## Package Acceptance
+## Приймання пакета
 
-Використовуйте `Package Acceptance`, коли питання таке: «чи працює цей installable package OpenClaw як продукт?» Він відрізняється від звичайного CI: звичайний CI перевіряє source tree, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі виконують після install або update.
+Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей встановлюваний пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як приймання пакета перевіряє один tarball через той самий Docker E2E harness, який користувачі застосовують після встановлення або оновлення.
 
-### Jobs
+### Завдання
 
-1. `resolve_package` виконує checkout `workflow_ref`, розв’язує одного package candidate, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як artifact `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 завантажує цей artifact, перевіряє tarball inventory, готує package-digest Docker images за потреби та запускає вибрані Docker lanes проти цього package замість пакування workflow checkout. Коли profile вибирає кілька цільових `docker_lanes`, reusable workflow один раз готує package і shared images, а потім розгортає ці lanes як паралельні цільові Docker jobs з унікальними artifacts.
-3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий artifact `package-under-test`, коли Package Acceptance розв’язав package; окремий Telegram dispatch усе ще може встановити опублікований npm spec.
-4. `summary` завершує workflow з помилкою, якщо package resolution, Docker acceptance або опційний Telegram lane завершився невдало.
+1. `resolve_package` отримує `workflow_ref`, розв’язує один кандидат пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і друкує джерело, workflow ref, package ref, версію, SHA-256 і профіль у підсумку кроку GitHub.
+2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker-доріжки проти цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow готує пакет і спільні образи один раз, а потім розгортає ці доріжки як паралельні цільові Docker-завдання з унікальними артефактами.
+3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance розв’язав його; автономний dispatch Telegram усе ще може встановити опубліковану npm-специфікацію.
+4. `summary` завершує workflow з помилкою, якщо розв’язання пакета, Docker acceptance або необов’язкова доріжка Telegram зазнали збою.
 
-### Candidate sources
+### Джерела кандидатів
 
-- `source=npm` приймає лише `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для acceptance опублікованого prerelease/stable.
-- `source=ref` пакує trusted branch, tag або повний commit SHA з `package_ref`. Resolver fetch OpenClaw branches/tags, перевіряє, що вибраний commit reachable з repository branch history або 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` опційний, але його слід надати для externally shared artifacts.
+- `source=npm` приймає лише `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованого попереднього/стабільного релізу.
+- `source=ref` пакує довірену гілку, тег або повний SHA коміту `package_ref`. Резолвер отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілки репозиторію або релізного тега, встановлює залежності у від’єднаному 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` — це trusted workflow/harness code, який запускає test. `package_ref` — це source commit, який пакується, коли `source=ref`. Це дає змогу поточному test harness перевіряти старіші trusted source commits без запуску старої workflow logic.
+Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає поточному тестовому harness змогу перевіряти старіші довірені коміти вихідного коду без запуску старої логіки workflow.
 
-### Suite profiles
+### Профілі наборів
 
 - `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-фрагменти релізного шляху з OpenWebUI
 - `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom`
 
-Profile `package` використовує offline plugin coverage, щоб валідація published-package не залежала від live доступності ClawHub. Опційний Telegram lane повторно використовує artifact `package-under-test` у `NPM Telegram Beta E2E`, а шлях published npm spec збережено для окремих dispatches.
+Профіль `package` використовує офлайн-покриття Plugin, щоб валідація опублікованого пакета не залежала від доступності live ClawHub. Необов’язкова доріжка Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації зберігається для автономних dispatch.
 
-Щодо спеціальної політики update і plugin testing, включно з локальними commands,
-Docker lanes, inputs Package Acceptance, release defaults і failure triage,
-див. [Тестування оновлень і plugins](/uk/help/testing-updates-plugins).
+Спеціальну політику тестування оновлень і Plugin, зокрема локальні команди,
+Docker-доріжки, вхідні дані Package Acceptance, релізні значення за замовчуванням і тріаж збоїв,
+див. у [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins).
 
-Release checks викликають Package Acceptance з `source=artifact`, підготовленим release package artifact, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це тримає package migration, update, stale-plugin-dependency cleanup, configured-plugin install repair, offline plugin, plugin-update і Telegram proof на тому самому розв’язаному package tarball. Cross-OS release checks усе ще покривають OS-specific onboarding, installer і platform behavior; package/update product validation має починатися з Package Acceptance. Docker lane `published-upgrade-survivor` перевіряє один published package baseline за запуск. У Package Acceptance розв’язаний tarball `package-under-test` завжди є candidate, а `published_upgrade_survivor_baseline` вибирає fallback published baseline, типово `openclaw@latest`; команди failed-lane rerun зберігають цей baseline. Встановіть `published_upgrade_survivor_baselines=release-history`, щоб розширити lane на deduped history matrix: останні шість stable releases, `2026.4.23` і останній stable release перед `2026-03-15`. Встановіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для Feishu config, збережених bootstrap/persona files, configured OpenClaw plugin installs, tilde log paths і stale legacy plugin dependency roots. Окремий workflow `Update Migration` використовує Docker lane `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає у вичерпному published update cleanup, а не у звичайній широті Full Release CI. Локальні 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 за допомогою вбудованого command 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 залишаються на test model GPT-5, уникаючи GPT-4.x defaults.
+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, repair встановлення налаштованого Plugin, офлайн Plugin, plugin-update і Telegram на одному й тому самому розв’язаному tarball пакета. Задайте `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму матрицю проти відвантаженого npm-пакета замість артефакта, зібраного за SHA. Cross-OS release checks усе ще покривають OS-специфічні onboarding, installer і platform behavior; продуктову валідацію пакета/оновлення слід починати з Package Acceptance. Docker-доріжка `published-upgrade-survivor` перевіряє одну baseline опублікованого пакета за запуск. У Package Acceptance розв’язаний tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback baseline опублікованого пакета, за замовчуванням `openclaw@latest`; команди повторного запуску невдалої доріжки зберігають цю baseline. Задайте `published_upgrade_survivor_baselines=all-since-2026.4.23`, щоб розширити Full Release CI на кожен стабільний npm-реліз від `2026.4.23` до `latest`; `release-history` лишається доступним для ручної ширшої вибірки зі старішим pre-date anchor. Задайте `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для конфігурації Feishu, збережених файлів bootstrap/persona, встановлень налаштованих OpenClaw Plugin, шляхів логів із тильдою та застарілих коренів залежностей legacy Plugin. Окремий workflow `Update Migration` використовує Docker-доріжку `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає у вичерпному очищенні опублікованих оновлень, а не у звичайній ширині Full Release CI. Локальні агреговані запуски можуть передавати точні специфікації пакетів через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, зберігати одну доріжку з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або задавати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для матриці сценаріїв. Опублікована доріжка налаштовує baseline за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також статус RPC після запуску Gateway. Свіжі доріжки Windows packaged та installer також перевіряють, що встановлений пакет може імпортувати перевизначення browser-control із необробленого абсолютного шляху Windows. Cross-OS smoke OpenAI agent-turn за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо його задано, інакше `openai/gpt-5.4`, тож перевірка встановлення й Gateway лишається на тестовій моделі GPT-5, уникаючи значень за замовчуванням GPT-4.x.
 
-### Legacy compatibility windows
+### Вікна сумісності з legacy
 
-Package Acceptance має обмежені legacy-compatibility windows для вже опублікованих packages. Packages до `2026.4.25` включно, включно з `2026.4.25-beta.*`, можуть використовувати compatibility path:
+Package Acceptance має обмежені вікна legacy-сумісності для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності:
 
-- відомі private QA entries у `dist/postinstall-inventory.json` можуть вказувати на файли, omit у tarball;
-- `doctor-switch` може пропустити subcase persistence `gateway install --wrapper`, коли package не expose цей flag;
-- `update-channel-switch` може prune відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і може log відсутній persisted `update.channel`;
-- plugin smokes можуть читати legacy install-record locations або приймати відсутній marketplace install-record persistence;
-- `plugin-update` може дозволяти config metadata migration, водночас усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними.
+- відомі приватні QA-записи в `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball;
+- `doctor-switch` може пропускати підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець;
+- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` із fake git fixture, похідної від tarball, і може логувати відсутній збережений `update.channel`;
+- plugin smokes можуть читати legacy-розташування install-record або приймати відсутню persistence marketplace install-record;
+- `plugin-update` може дозволяти міграцію metadata конфігурації, водночас усе ще вимагаючи, щоб install record і поведінка no-reinstall лишалися незмінними.
 
-Опублікований package `2026.4.26` також може попереджати про local build metadata stamp files, які вже були shipped. Пізніші packages мають відповідати сучасним contracts; ті самі умови fail замість warn або skip.
+Опублікований пакет `2026.4.26` також може попереджати про локальні файли штампів build metadata, які вже були відвантажені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови призводять до помилки, а не до попередження чи пропуску.
 
 ### Приклади
 
@@ -322,152 +322,152 @@ gh workflow run package-acceptance.yml \
   -f docker_lanes='install-e2e plugin-update'
 ```
 
-Під час налагодження невдалого запуску package acceptance починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lane, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes замість повторного запуску повної release validation.
+Під час налагодження невдалого запуску приймання пакета починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker-ліній замість повторного запуску повної валідації релізу.
 
 ## Інсталяційний smoke-тест
 
-Окремий workflow `Install Smoke` повторно використовує той самий scope-скрипт через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
+Окремий workflow `Install Smoke` повторно використовує той самий скрипт області через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
 
-- **Швидкий шлях** запускається для pull request, які зачіпають Docker/package surfaces, зміни пакета/маніфесту вбудованого Plugin або surfaces ядра plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише у вихідному коді вбудованого Plugin, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ root Dockerfile, перевіряє CLI, запускає CLI smoke для `agents delete shared-workspace`, запускає container gateway-network e2e, перевіряє build arg вбудованого розширення та запускає обмежений Docker-профіль вбудованого Plugin із сукупним timeout команди 240 секунд (Docker-запуск кожного сценарію обмежено окремо).
-- **Повний шлях** зберігає QR package install і installer Docker/update coverage для нічних запланованих запусків, ручних dispatch, workflow-call release checks і pull request, які справді зачіпають installer/package/Docker surfaces. У повному режимі install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий Docker E2E для вбудованого Plugin як окремі завдання, щоб installer-робота не чекала за root image smokes.
+- **Швидкий шлях** запускається для pull request, які зачіпають поверхні Docker/пакета, зміни пакета/маніфесту вбудованого Plugin або поверхні ядра Plugin/каналу/Gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише у вихідному коді вбудованого Plugin, зміни лише в тестах і зміни лише в документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє аргумент збірки вбудованого розширення та виконує обмежений Docker-профіль вбудованого Plugin з агрегованим тайм-аутом команди 240 секунд (Docker-запуск кожного сценарію обмежено окремо).
+- **Повний шлях** зберігає покриття встановлення QR-пакета та Docker/update інсталятора для нічних запланованих запусків, ручних dispatch, workflow-call перевірок релізу та pull request, які справді зачіпають поверхні інсталятора/пакета/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR smoke-образ кореневого Dockerfile для цільового SHA, а потім запускає встановлення QR-пакета, smoke-перевірки кореневого Dockerfile/Gateway, smoke-перевірки інсталятора/update і швидкий Docker E2E для вбудованого Plugin як окремі завдання, щоб робота інсталятора не чекала за smoke-перевірками кореневого образу.
 
-Пуші в `main` (включно з merge commits) не примушують повний шлях; коли changed-scope logic запитала б повне покриття під час push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічного запуску або release validation.
+Push до `main` (включно з merge commits) не примушує повний шлях; коли логіка changed-scope запитала б повне покриття під час push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або релізної валідації.
 
-Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow release checks, а ручні dispatch для `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` цього не роблять. QR і installer Docker tests зберігають власні Dockerfiles, сфокусовані на інсталяції.
+Повільний Bun global install image-provider smoke окремо контролюється через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow перевірок релізу, а ручні dispatch `Install Smoke` можуть увімкнути його, але pull request і push до `main` не запускають його. QR і Docker-тести інсталятора зберігають власні Dockerfile, зосереджені на інсталяції.
 
 ## Локальний Docker E2E
 
-`pnpm test:docker:all` попередньо збирає один спільний образ live-test, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
+`pnpm test:docker:all` попередньо збирає один спільний live-test образ, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
 
-- базовий Node/Git runner для installer/update/plugin-dependency lanes;
-- функціональний образ, який встановлює той самий tarball у `/app` для звичайних functionality lanes.
+- базовий Node/Git runner для ліній installer/update/plugin-dependency;
+- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній.
 
-Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Scheduler вибирає образ для кожної lane за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає lanes з `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              | Кількість слотів основного пулу для звичайних lanes.                                               |
-| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10             | Кількість слотів tail-пулу, чутливого до провайдерів.                                              |
-| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`      | 9               | Ліміт одночасних live lanes, щоб провайдери не застосовували throttling.                           |
-| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`       | 10              | Ліміт одночасних npm install lanes.                                                               |
-| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`   | 7               | Ліміт одночасних multi-service lanes.                                                             |
-| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000           | Затримка між стартами lanes, щоб уникати сплесків створення в Docker daemon; установіть `0`, щоб вимкнути затримку. |
-| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000         | Резервний timeout для кожної lane (120 хвилин); вибрані live/tail lanes використовують жорсткіші ліміти. |
-| `OPENCLAW_DOCKER_ALL_DRY_RUN`         | unset           | `1` друкує план scheduler без запуску lanes.                                                       |
-| `OPENCLAW_DOCKER_ALL_LANES`           | unset           | Точний список lanes, розділений комами; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу lane. |
+| Змінна                                | За замовчуванням | Призначення                                                                                  |
+| ------------------------------------- | ---------------- | -------------------------------------------------------------------------------------------- |
+| `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       | Обмеження одночасних multi-service ліній.                                                            |
+| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000    | Затримка між стартами ліній, щоб уникнути create storm у 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 могли відтворити одну невдалу лінію. |
 
-Lane, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім виконується самостійно, доки не звільнить capacity. Локальні сукупні preflights перевіряють Docker, видаляють застарілі OpenClaw E2E containers, виводять статус активних lanes, зберігають таймінги lanes для впорядкування longest-first і за замовчуванням припиняють планування нових pooled lanes після першої помилки.
+Лінія, важча за свій ефективний ліміт, все одно може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальні агреговані preflight перевіряють Docker, видаляють застарілі OpenClaw E2E контейнери, виводять статус активних ліній, зберігають таймінги ліній для впорядкування від найдовших і за замовчуванням припиняють планувати нові pooled-лінії після першої помилки.
 
 ### Повторно використовуваний live/E2E workflow
 
-Повторно використовуваний live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття package, image kind, live image, lane і credentials потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного запуску, або завантажує package artifact із `package_artifact_run_id`; перевіряє tarball inventory; збирає й пушить package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли план потребує package-installed lanes; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість повторної збірки. Pull Docker images повторюється з обмеженим 180-секундним timeout на спробу, щоб завислий registry/cache stream швидко повторювався замість споживання більшої частини критичного шляху 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; збирає та публікує bare/functional GHCR Docker E2E образи, позначені digest пакета, через кеш Docker-шарів Blacksmith, коли план потребує ліній із встановленим пакетом; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest образи замість повторної збірки. Docker image pulls повторюються з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий потік registry/cache швидко повторювався замість споживання більшої частини критичного шляху CI.
 
-### Chunks release path
+### Фрагменти release-path
 
-Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk підтягував лише потрібний image kind і виконував кілька lanes через той самий weighted scheduler:
+Релізне 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`
 
-Поточні 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` залишаються сукупними псевдонімами plugin/runtime. Псевдонім lane `install-e2e` залишається сукупним ручним rerun alias для обох provider installer lanes.
+Поточні 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 ліній.
 
-OpenWebUI включається в `plugins-runtime-services`, коли повне покриття release-path цього вимагає, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Bundled-channel update lanes повторюються один раз у разі тимчасових npm network failures.
+OpenWebUI згортається в `plugins-runtime-services`, коли це запитує повне release-path покриття, і зберігає окремий chunk `openwebui` лише для dispatch, призначених тільки для OpenWebUI. Bundled-channel update лінії повторюються один раз у разі тимчасових npm network failures.
 
-Кожен chunk завантажує `.artifacts/docker-tests/` із журналами lanes, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану scheduler, таблицями slow-lane і командами rerun для кожної lane. Input workflow `docker_lanes` запускає вибрані lanes проти підготовлених образів замість chunk jobs, що обмежує налагодження failed-lane одним targeted Docker job і готує, завантажує або повторно використовує package artifact для цього запуску; якщо вибрана lane є live Docker lane, targeted job локально збирає live-test image для цього rerun. Згенеровані GitHub rerun commands для кожної lane включають `package_artifact_run_id`, `package_artifact_name` і prepared image inputs, коли ці значення існують, щоб failed lane могла повторно використати точний package і images з failed run.
+Кожен chunk завантажує `.artifacts/docker-tests/` із журналами ліній, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість chunk-завдань, що обмежує налагодження невдалої лінії одним цільовим Docker-завданням і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана лінія є live Docker lane, цільове завдання локально збирає live-test образ для цього повторного запуску. Згенеровані GitHub-команди повторного запуску для кожної лінії містять `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, тому невдала лінія може повторно використати точний пакет і образи з невдалого запуску.
 
 ```bash
-pnpm test:docker:rerun <run-id>      # завантажити Docker-артефакти та надрукувати combined/per-lane targeted rerun commands
-pnpm test:docker:timings <summary>   # summaries slow-lane і phase critical-path
+pnpm test:docker:rerun <run-id>      # download Docker artifacts and print combined/per-lane targeted rerun commands
+pnpm test:docker:timings <summary>   # slow-lane and phase critical-path summaries
 ```
 
 Запланований live/E2E workflow щодня запускає повний release-path Docker suite.
 
-## Plugin Prerelease
+## Передреліз Plugin
 
-`Plugin Prerelease` є дорожчим product/package coverage, тому це окремий 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 групує targeted Docker lanes у невеликі групи, щоб не резервувати десятки runners для одно-трихвилинних завдань.
+`Plugin Prerelease` є дорожчим покриттям product/package, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push до `main` і standalone manual CI dispatch не запускають цей suite. Він балансує тести вбудованих Plugin між вісьмома workers розширень; ці extension shard jobs запускають до двох груп конфігурації Plugin одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy пакети Plugin не створювали додаткових CI jobs. Release-only Docker prerelease path пакетно запускає цільові Docker-лінії малими групами, щоб не резервувати десятки runners для завдань на одну-три хвилини.
 
 ## QA Lab
 
-QA Lab має виділені CI lanes поза основним smart-scoped workflow.
+QA Lab має окремі CI-лінії поза основним smart-scoped workflow.
 
-- Workflow `Parity gate` запускається на відповідних змінах PR і ручному dispatch; він збирає private QA runtime і порівнює agentic packs mock GPT-5.5 та Opus 4.6.
-- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і за ручним dispatch; він розгалужує mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують environment `qa-live-shared`, а Telegram/Discord використовують Convex leases.
+- Workflow `Parity gate` запускається на відповідних змінах PR і manual dispatch; він збирає приватний QA runtime і порівнює mock GPT-5.5 та Opus 4.6 agentic packs.
+- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і manual dispatch; він розгортає mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases.
 
-Release checks запускають Matrix і Telegram live transport lanes із deterministic mock provider і mock-qualified models (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб channel contract був ізольований від live model latency і звичайного provider-plugin startup. Live transport gateway вимикає memory search, тому що QA parity окремо покриває memory behavior; provider connectivity покривається окремими live model, native provider і Docker provider suites.
+Перевірки релізу запускають 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 вимикає memory search, тому що QA parity окремо покриває поведінку пам'яті; provider connectivity покривається окремими наборами live model, native provider і Docker provider.
 
-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`.
+Matrix використовує `--profile fast` для запланованих і release gates, додаючи `--fail-fast` лише коли checked-out CLI підтримує це. CLI default і manual workflow input залишаються `all`; manual dispatch `matrix_profile=all` завжди розбиває повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
 
-`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у невеликий report job для фінального parity comparison.
+`OpenClaw Release Checks` також запускає критичні для релізу QA Lab lanes перед схваленням релізу; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва артефакти в невелике report job для фінального parity comparison.
 
-Не ставте PR landing path за `Parity gate`, якщо зміна насправді не зачіпає QA runtime, model-pack parity або surface, яким володіє parity workflow. Для звичайних виправлень channel, config, docs або unit-test вважайте це додатковим сигналом і покладайтеся на scoped CI/check evidence.
+Не ставте шлях приземлення PR за `Parity gate`, якщо зміна фактично не торкається QA runtime, parity набору моделей або поверхні, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-тестів розглядайте його як необов’язковий сигнал і натомість спирайтеся на scoped CI/check evidence.
 
 ## CodeQL
 
-Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним sweep усього repository. Щоденні, ручні та non-draft pull request guard runs сканують Actions workflow code плюс найризикованіші JavaScript/TypeScript surfaces з high-confidence security queries, відфільтрованими до high/critical `security-severity`.
+Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним sweep репозиторію. Щоденні, ручні та guard-запуски pull request не в draft-стані сканують код Actions workflow і найризикованіші JavaScript/TypeScript surfaces із security queries високої впевненості, відфільтрованими до високої/критичної `security-severity`.
 
-Pull request guard залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security matrix, що й scheduled workflow. Android і macOS CodeQL не входять у PR defaults.
+Guard для pull request лишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму security matrix високої впевненості, що й scheduled workflow. Android і macOS CodeQL не входять у стандартні PR-запуски.
 
 ### Категорії безпеки
 
-| Категорія                                       | Поверхня                                                                                                                             |
+| Категорія                                        | Поверхня                                                                                                                            |
 | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-security-high/core-auth-secrets`         | Базовий рівень автентифікації, секретів, пісочниці, cron і gateway                                                                  |
-| `/codeql-security-high/channel-runtime-boundary`  | Контракти реалізації основного каналу плюс середовище виконання канального plugin, gateway, Plugin SDK, секрети, точки аудиту       |
-| `/codeql-security-high/network-ssrf-boundary`     | Поверхні політики SSRF для core SSRF, розбору IP, мережевого захисту, web-fetch і Plugin SDK                                        |
-| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, допоміжні засоби виконання процесів, вихідна доставка та шлюзи виконання інструментів агента                          |
-| `/codeql-security-high/plugin-trust-boundary`     | Поверхні довіри для встановлення Plugin, завантажувача, маніфесту, реєстру, встановлення менеджером пакетів, завантаження джерел і контракту пакета Plugin SDK |
+| `/codeql-security-high/core-auth-secrets`         | Auth, secrets, sandbox, cron і базова лінія gateway                                                                                 |
+| `/codeql-security-high/channel-runtime-boundary`  | Контракти реалізації core channel плюс channel Plugin runtime, gateway, Plugin SDK, secrets, audit touchpoints                      |
+| `/codeql-security-high/network-ssrf-boundary`     | Core SSRF, IP parsing, network guard, web-fetch і surfaces політики SSRF у Plugin SDK                                                |
+| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, helpers виконання процесів, outbound delivery і gates виконання agent tool                                             |
+| `/codeql-security-high/plugin-trust-boundary`     | Plugin install, loader, manifest, registry, package-manager install, source-loading і trust surfaces контракту пакета Plugin SDK |
 
-### Специфічні для платформ security shards
+### Платформо-специфічні security shards
 
-- `CodeQL Android Critical Security` — запланований Android security shard. Вручну збирає Android-застосунок для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Вивантажує в `/codeql-critical-security/android`.
-- `CodeQL macOS Critical Security` — щотижневий/ручний macOS security shard. Вручну збирає macOS-застосунок для CodeQL на Blacksmith macOS, відфільтровує результати збірки залежностей із вивантаженого SARIF і вивантажує в `/codeql-critical-security/macos`. Залишено поза щоденними стандартними запусканнями, бо збірка macOS домінує за часом виконання навіть коли все чисто.
+- `CodeQL Android Critical Security` — scheduled 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`. Тримається поза щоденними defaults, бо macOS build домінує runtime навіть коли чистий.
 
 ### Категорії Critical Quality
 
-`CodeQL Critical Quality` — відповідний несек'юріті shard. Він запускає лише запити якості JavaScript/TypeScript із severity error і без security над вузькими високовартісними поверхнями на меншому Blacksmith Linux runner. Його запобіжник для pull request навмисно менший за запланований профіль: не-draft 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` для змін у коді виконання команд/моделей/інструментів агента та диспетчеризації відповідей, коді схем/міграцій/IO конфігурації, коді auth/secrets/sandbox/security, основному каналі та середовищі виконання вбудованого канального plugin, протоколі Gateway/методі сервера, склейці memory runtime/SDK, MCP/process/outbound delivery, середовищі виконання провайдера/каталозі моделей, діагностиці сесій/чергах доставки, завантажувачі plugin, Plugin SDK/контракті пакета або середовищі виконання відповідей Plugin SDK. Зміни конфігурації CodeQL і quality workflow запускають усі дванадцять PR quality shards.
+`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries на вузьких високовартісних surfaces на меншому Blacksmith Linux runner. Його pull request guard навмисно менший за scheduled profile: non-draft PRs запускають лише відповідні 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 execution і reply dispatch code, config schema/migration/IO code, auth/secrets/sandbox/security code, core channel і bundled channel Plugin runtime, 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.
 
-Ручний запуск приймає:
+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
 ```
 
-Вузькі профілі — це хуки для навчання/ітерацій, щоб запускати один quality shard ізольовано.
+Вузькі profiles — це hooks для навчання/ітерації, щоб запускати один quality shard ізольовано.
 
-| Категорія                                              | Поверхня                                                                                                                                                           |
+| Категорія                                              | Поверхня                                                                                                                                                          |
 | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-critical-quality/core-auth-secrets`            | Код security boundary для автентифікації, секретів, пісочниці, cron і gateway                                                                                     |
-| `/codeql-critical-quality/config-boundary`              | Схема конфігурації, міграція, нормалізація та IO-контракти                                                                                                        |
-| `/codeql-critical-quality/gateway-runtime-boundary`     | Схеми протоколу Gateway і контракти методів сервера                                                                                                               |
-| `/codeql-critical-quality/channel-runtime-boundary`     | Контракти основного каналу та реалізації вбудованого канального plugin                                                                                            |
-| `/codeql-critical-quality/agent-runtime-boundary`       | Контракти виконання команд, диспетчеризації model/provider, диспетчеризації й черг auto-reply та середовища виконання ACP control-plane                          |
-| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-сервери та мости інструментів, допоміжні засоби нагляду за процесами й контракти вихідної доставки                                                           |
-| `/codeql-critical-quality/memory-runtime-boundary`      | Memory host SDK, фасади memory runtime, псевдоніми memory Plugin SDK, склейка активації memory runtime і команди memory doctor                                   |
-| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішні частини черги відповідей, черги доставки сесій, допоміжні засоби прив'язування/доставки вихідних сесій, поверхні діагностичних подій/пакетів журналів і контракти CLI session doctor |
-| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Диспетчеризація вхідних відповідей Plugin SDK, допоміжні засоби payload/chunking/runtime для відповідей, параметри відповіді каналу, черги доставки та допоміжні засоби прив'язування session/thread |
-| `/codeql-critical-quality/provider-runtime-boundary`    | Нормалізація каталогу моделей, автентифікація й виявлення провайдера, реєстрація середовища виконання провайдера, defaults/catalogs провайдера та реєстри web/search/fetch/embedding |
-| `/codeql-critical-quality/ui-control-plane`             | Завантаження Control UI, локальна персистентність, потоки керування gateway і runtime-контракти task control-plane                                                |
-| `/codeql-critical-quality/web-media-runtime-boundary`   | Контракти core web fetch/search, media IO, media understanding, image-generation і media-generation runtime                                                       |
-| `/codeql-critical-quality/plugin-boundary`              | Контракти завантажувача, реєстру, публічної поверхні та точки входу Plugin SDK                                                                                    |
-| `/codeql-critical-quality/plugin-sdk-package-contract`  | Опублікований package-side вихідний код Plugin SDK і допоміжні засоби контракту пакета plugin                                                                     |
+| `/codeql-critical-quality/core-auth-secrets`            | Auth, secrets, sandbox, cron і code межі безпеки gateway                                                                                                          |
+| `/codeql-critical-quality/config-boundary`              | Config schema, migration, normalization і IO contracts                                                                                                            |
+| `/codeql-critical-quality/gateway-runtime-boundary`     | Gateway protocol schemas і server method contracts                                                                                                                |
+| `/codeql-critical-quality/channel-runtime-boundary`     | Core channel і bundled channel Plugin implementation contracts                                                                                                    |
+| `/codeql-critical-quality/agent-runtime-boundary`       | Command execution, model/provider dispatch, auto-reply dispatch і queues, а також ACP control-plane runtime contracts                                             |
+| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP servers і tool bridges, process supervision helpers і outbound delivery contracts                                                                              |
+| `/codeql-critical-quality/memory-runtime-boundary`      | Memory host SDK, memory runtime facades, memory Plugin SDK aliases, memory runtime activation glue і memory doctor commands                                       |
+| `/codeql-critical-quality/session-diagnostics-boundary` | Reply queue internals, session delivery queues, outbound session binding/delivery helpers, diagnostic event/log bundle surfaces і session doctor CLI contracts    |
+| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Plugin SDK inbound reply dispatch, reply payload/chunking/runtime helpers, channel reply options, delivery queues і session/thread binding helpers                 |
+| `/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`             | Control UI bootstrap, local persistence, gateway control flows і task control-plane runtime contracts                                                              |
+| `/codeql-critical-quality/web-media-runtime-boundary`   | Core web fetch/search, media IO, media understanding, image-generation і media-generation runtime contracts                                                        |
+| `/codeql-critical-quality/plugin-boundary`              | Loader, registry, public-surface і Plugin SDK entrypoint contracts                                                                                                 |
+| `/codeql-critical-quality/plugin-sdk-package-contract`  | Published package-side Plugin SDK source і helpers контракту plugin package                                                                                       |
 
-Quality залишається окремо від security, щоб quality findings можна було планувати, вимірювати, вимикати або розширювати без затінення security signal. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільні runtime і signal.
+Quality тримається окремо від security, щоб quality findings можна було планувати, вимірювати, вимикати або розширювати, не затіняючи security signal. Swift, Python і bundled-plugin CodeQL expansion слід додавати назад як scoped або sharded follow-up work лише після того, як вузькі profiles матимуть стабільні runtime і signal.
 
-## Робочі процеси обслуговування
+## Maintenance workflows
 
 ### Docs Agent
 
-Workflow `Docs Agent` — це подієво-керована maintenance lane Codex для підтримання наявної документації узгодженою з нещодавно злитими змінами. Вона не має чистого розкладу: успішний non-bot push CI run на `main` може її запустити, а manual dispatch може запустити її напряму. Workflow-run invocations пропускаються, коли `main` уже просунувся далі або коли інший non-skipped Docs Agent run було створено за останню годину. Коли вона запускається, то переглядає діапазон комітів від попереднього non-skipped Docs Agent source SHA до поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені з останнього проходу docs.
+Workflow `Docs Agent` — це event-driven Codex maintenance lane для підтримання наявної документації узгодженою з нещодавно landed changes. Він не має pure schedule: успішний 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`, тож один hourly run може покрити всі main changes, накопичені з останнього docs pass.
 
 ### Test Performance Agent
 
-Workflow `Test Performance Agent` — це подієво-керована maintenance lane Codex для повільних тестів. Вона не має чистого розкладу: успішний non-bot push CI run на `main` може її запустити, але вона пропускається, якщо інший workflow-run invocation уже запускався або виконується в цей UTC-день. Manual dispatch обходить цей daily activity gate. Lane будує full-suite grouped Vitest performance report, дозволяє Codex робити лише невеликі coverage-preserving test performance fixes замість широких рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, що зменшують baseline test count, який проходить. Якщо baseline має failing tests, Codex може виправляти лише очевидні failures, а after-agent full-suite report має пройти перед будь-яким комітом. Коли `main` просувається вперед до того, як bot push потрапить у репозиторій, lane робить rebase перевіреного patch, повторно запускає `pnpm check:changed` і повторює push; stale patches із конфліктами пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб Codex action могла зберігати ту саму drop-sudo safety posture, що й docs agent.
+Workflow `Test Performance Agent` — це event-driven Codex maintenance lane для повільних tests. Він не має pure schedule: успішний non-bot push CI run на `main` може його запустити, але він пропускається, якщо інша workflow-run invocation уже запускалася або виконується цього UTC day. Manual dispatch обходить цей daily activity gate. Lane будує full-suite grouped Vitest performance report, дозволяє Codex робити лише невеликі coverage-preserving test performance fixes замість широких refactors, потім повторно запускає full-suite report і відхиляє зміни, що зменшують passing baseline test count. Якщо baseline має failing tests, Codex може виправляти лише очевидні failures, а after-agent full-suite report має пройти перед будь-яким commit. Коли `main` просувається вперед до того, як bot push landed, lane rebase’ить validated patch, повторно запускає `pnpm check:changed` і повторює push; conflicting stale patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб Codex action міг зберегти ту саму drop-sudo safety posture, що й docs agent.
 
-### Дублікати PR після злиття
+### Duplicate PRs After Merge
 
-Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для post-land очищення дублікатів. За замовчуванням він працює як dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR злитий і що кожен duplicate має або спільну referenced issue, або перекривні changed hunks.
+Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для post-land duplicate cleanup. За замовчуванням він dry-run і закриває лише явно перелічені PRs, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR merged і що кожен duplicate має або shared referenced issue, або overlapping changed hunks.
 
 ```bash
 gh workflow run duplicate-after-merge.yml \
@@ -476,29 +476,29 @@ gh workflow run duplicate-after-merge.yml \
   -f apply=true
 ```
 
-## Локальні check gates і маршрутизація змін
+## Local check gates і changed routing
 
-Local changed-lane logic живе в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж широкий CI platform scope:
+Local changed-lane logic живе в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж широкий scope CI platform:
 
-- зміни 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 запускають цільові version/config/root-dependency checks;
-- невідомі root/config changes fail safe до всіх check lanes.
+- core production changes запускають core prod і core test typecheck плюс core lint/guards;
+- core test-only changes запускають лише core test typecheck плюс core lint;
+- extension production changes запускають extension prod і extension test typecheck плюс extension lint;
+- extension test-only changes запускають extension test typecheck плюс extension lint;
+- public Plugin SDK або plugin-contract changes розширюються до extension typecheck, бо extensions залежать від цих core contracts (Vitest extension sweeps лишаються явною test work);
+- release metadata-only version bumps запускають targeted version/config/root-dependency checks;
+- unknown root/config changes fail safe до всіх check lanes.
 
-Local changed-test routing живе в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі test edits запускають самі себе, source edits надають перевагу явним 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 change зазнала failure до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна настільки harness-wide, що дешевий mapped set не є надійним proxy.
+Маршрутизація локальних тестів за змінами міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі зміни тестів запускають самі себе, зміни джерел віддають перевагу явним зіставленням, потім суміжним тестам і залежним елементам графа імпортів. Спільна конфігурація доставки для групових кімнат є одним із явних зіставлень: зміни конфігурації видимих відповідей у групі, режиму доставки відповідей із джерела або системного промпта інструмента повідомлень проходять через основні тести відповідей, а також регресії доставки Discord і Slack, щоб зміна спільного стандартного значення падала ще до першого push у PR. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна достатньо широка для всього harness, що дешевий зіставлений набір не є надійним proxy.
 
 ## Валідація Testbox
 
-Запускайте Testbox із кореня репозиторію та надавайте перевагу свіжому warmed box для broad proof. Перед тим як витрачати повільний gate на box, який reused, expired або щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` усередині box.
+Запускайте Testbox з кореня репозиторію й віддавайте перевагу свіжій прогрітій коробці для широкого підтвердження. Перш ніж витрачати повільний gate на коробку, яку було повторно використано, термін дії якої минув або яка щойно повідомила про несподівано велику синхронізацію, спочатку запустіть `pnpm testbox:sanity` всередині коробки.
 
-Sanity check швидко завершується failure, коли required root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що remote sync state не є надійною копією PR; зупиніть цей box і warmed fresh one замість налагодження product test failure. Для intentional large-deletion PR встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run.
+Перевірка sanity швидко завершується помилкою, коли зникли потрібні кореневі файли, як-от `pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 відстежуваних видалень. Зазвичай це означає, що стан віддаленої синхронізації не є надійною копією 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, який залишається у фазі синхронізації понад п’ять хвилин без виводу після синхронізації. Установіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей запобіжник, або використайте більше значення в мілісекундах для незвично великих локальних diff.
 
-Crabbox — це другий належний репозиторію шлях до віддаленого бокса для перевірки в Linux, коли Blacksmith недоступний або коли бажано використати власну хмарну потужність. Підігрійте бокс, гідратуйте його через workflow проєкту, а потім виконуйте команди через Crabbox CLI:
+Crabbox — це другий віддалений шлях коробок, яким володіє репозиторій, для підтвердження в Linux, коли Blacksmith недоступний або коли бажано використовувати власну хмарну місткість. Прогрійте коробку, гідратуйте її через workflow проєкту, а потім запускайте команди через Crabbox CLI:
 
 ```bash
 pnpm crabbox:warmup -- --idle-timeout 90m
@@ -507,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 замість синхронізації локальних для мейнтейнера remotes і сховищ об’єктів, а також виключає локальні runtime/build артефакти, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` визначає checkout, налаштування Node/pnpm, отримання `origin/main` і передавання несекретного середовища, яке згодом використовують команди `crabbox run --id <cbx_id>`.
+`.crabbox.yaml` керує стандартними значеннями provider, sync і гідратації GitHub Actions. Він виключає локальний `.git`, щоб гідратований checkout Actions зберігав власні віддалені Git-метадані замість синхронізації maintainer-local remotes і object stores, а також виключає локальні runtime/build артефакти, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` керує checkout, налаштуванням Node/pnpm, отриманням `origin/main` і передаванням несекретного середовища, яке пізніші команди `crabbox run --id <cbx_id>` підключають як source.
 
 ## Пов’язане
 

docs/uk/cli/doctor.md

@@ -5,10 +5,10 @@ read_when:
 summary: Довідник CLI для `openclaw doctor` (перевірки справності + керовані виправлення)
 title: Діагностика
 x-i18n:
-    generated_at: "2026-05-02T15:57:48Z"
+    generated_at: "2026-05-02T18:57:43Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 90da8ffd705cd517fb90367164cc6af3e551befcec15c91746aa1e1e39454f09
+    source_hash: c64cefee8f36b38657b72912271e3734411870376d2bd5a374d23a77a080035d
     source_path: cli/doctor.md
     workflow: 16
 ---
@@ -17,7 +17,7 @@ x-i18n:
 
 Перевірки справності + швидкі виправлення для Gateway і каналів.
 
-Пов’язано:
+Пов’язане:
 
 - Усунення несправностей: [Усунення несправностей](/uk/gateway/troubleshooting)
 - Аудит безпеки: [Безпека](/uk/gateway/security)
@@ -34,43 +34,44 @@ openclaw doctor --generate-gateway-token
 
 ## Параметри
 
-- `--no-workspace-suggestions`: вимкнути підказки пам’яті/пошуку робочого простору
-- `--yes`: приймати значення за замовчуванням без запитів
-- `--repair`: застосувати рекомендовані виправлення, не пов’язані із сервісом, без запитів; встановлення й перезапис сервісу Gateway все одно потребують інтерактивного підтвердження або явних команд Gateway
+- `--no-workspace-suggestions`: вимкнути пропозиції пам’яті/пошуку робочого простору
+- `--yes`: приймати типові значення без запитів
+- `--repair`: застосувати рекомендовані виправлення, не пов’язані зі службами, без запитів; встановлення та перезаписи служби Gateway усе ще потребують інтерактивного підтвердження або явних команд Gateway
 - `--fix`: псевдонім для `--repair`
-- `--force`: застосувати агресивні виправлення, зокрема перезапис власної конфігурації сервісу за потреби
-- `--non-interactive`: запускати без запитів; лише безпечні міграції та виправлення, не пов’язані із сервісом
-- `--generate-gateway-token`: згенерувати й налаштувати токен Gateway
-- `--deep`: просканувати системні сервіси на наявність додаткових встановлень Gateway
+- `--force`: застосувати агресивні виправлення, зокрема перезапис власної конфігурації служби за потреби
+- `--non-interactive`: виконати без запитів; лише безпечні міграції та виправлення, не пов’язані зі службами
+- `--generate-gateway-token`: згенерувати та налаштувати токен Gateway
+- `--deep`: просканувати системні служби на наявність додаткових встановлень Gateway
 
 Примітки:
 
-- Інтерактивні запити (наприклад, виправлення keychain/OAuth) виконуються лише тоді, коли stdin є TTY і `--non-interactive` **не** задано. Запуски без інтерфейсу (cron, Telegram, без термінала) пропускатимуть запити.
-- Продуктивність: неінтерактивні запуски `doctor` пропускають завчасне завантаження plugin, щоб перевірки справності без інтерфейсу залишалися швидкими. Інтерактивні сеанси все одно повністю завантажують plugins, коли перевірці потрібен їхній внесок.
+- Інтерактивні запити (наприклад, виправлення keychain/OAuth) виконуються лише тоді, коли stdin є TTY і **не** встановлено `--non-interactive`. Безголові запуски (cron, Telegram, без термінала) пропускатимуть запити.
+- Продуктивність: неінтерактивні запуски `doctor` пропускають завчасне завантаження Plugin, щоб безголові перевірки справності лишалися швидкими. Інтерактивні сеанси все одно повністю завантажують plugins, коли перевірці потрібен їхній внесок.
 - `--fix` (псевдонім для `--repair`) записує резервну копію в `~/.openclaw/openclaw.json.bak` і видаляє невідомі ключі конфігурації, перелічуючи кожне видалення.
-- `doctor --fix --non-interactive` повідомляє про відсутні або застарілі визначення сервісу Gateway, але не встановлює й не перезаписує їх поза режимом відновлення оновлення. Запустіть `openclaw gateway install` для відсутнього сервісу або `openclaw gateway install --force`, коли ви навмисно хочете замінити засіб запуску.
-- Перевірки цілісності стану тепер виявляють осиротілі файли транскриптів у каталозі сеансів. Архівування їх як `.deleted.<timestamp>` потребує інтерактивного підтвердження; `--fix`, `--yes` і запуски без інтерфейсу залишають їх на місці.
-- Doctor також сканує `~/.openclaw/cron/jobs.json` (або `cron.store`) на наявність застарілих форм завдань cron і може перезаписати їх на місці до того, як планувальнику доведеться автоматично нормалізувати їх під час виконання.
-- У Linux doctor попереджає, коли crontab користувача все ще запускає застарілий `~/.openclaw/bin/ensure-whatsapp.sh`; цей скрипт більше не підтримується й може журналювати хибні збої Gateway WhatsApp, коли cron не має середовища user-bus systemd.
-- Doctor очищає застарілий стан підготовки залежностей plugin, створений старішими версіями OpenClaw. Він також відновлює відсутні налаштовані завантажувані plugins, коли реєстр може їх визначити, а прохід doctor 2026.5.2 автоматично встановлює завантажувані plugins, які вже використовує старіша конфігурація, перш ніж позначати конфігурацію зміненою для цього релізу.
-- Doctor виправляє застарілу конфігурацію plugin, видаляючи відсутні ідентифікатори plugin з `plugins.allow`/`plugins.entries`, а також відповідну висячу конфігурацію каналу, цілі Heartbeat і перевизначення моделей каналів, коли виявлення plugin справне.
-- Doctor ізолює недійсну конфігурацію plugin, вимикаючи відповідний запис `plugins.entries.<id>` і видаляючи його недійсне корисне навантаження `config`. Запуск Gateway уже пропускає лише цей несправний plugin, тож інші plugins і канали можуть продовжувати працювати.
-- Установіть `OPENCLAW_SERVICE_REPAIR_POLICY=external`, коли інший супервізор керує життєвим циклом Gateway. Doctor усе одно повідомляє про справність Gateway/сервісу й застосовує виправлення, не пов’язані із сервісом, але пропускає встановлення/запуск/перезапуск/bootstrap сервісу та очищення застарілого сервісу.
-- У Linux doctor ігнорує неактивні додаткові systemd units, схожі на Gateway, і не перезаписує метадані команди/точки входу для запущеного сервісу Gateway systemd під час виправлення. Спершу зупиніть сервіс або скористайтеся `openclaw gateway install --force`, коли ви навмисно хочете замінити активний засіб запуску.
-- Doctor автоматично мігрує застарілу пласку конфігурацію Talk (`talk.voiceId`, `talk.modelId` тощо) у `talk.provider` + `talk.providers.<provider>`.
-- Повторні запуски `doctor --fix` більше не повідомляють і не застосовують нормалізацію Talk, коли єдина відмінність — порядок ключів об’єкта.
-- Doctor містить перевірку готовності пошуку в пам’яті й може рекомендувати `openclaw configure --section model`, коли облікові дані embedding відсутні.
-- Doctor попереджає, коли власника команд не налаштовано. Власник команд — це обліковий запис людини-оператора, якому дозволено запускати команди лише для власника й схвалювати небезпечні дії. Сполучення через DM лише дає комусь змогу спілкуватися з ботом; якщо ви схвалили відправника до появи bootstrap першого власника, явно задайте `commands.ownerAllowFrom`.
-- Doctor попереджає, коли налаштовано агентів у режимі Codex і в Codex home оператора існують особисті ресурси Codex CLI. Локальні запуски app-server Codex використовують ізольовані домівки для кожного агента, тож використовуйте `openclaw migrate codex --dry-run`, щоб інвентаризувати ресурси, які слід просувати свідомо.
-- Якщо режим sandbox увімкнено, але Docker недоступний, doctor повідомляє високосигнальне попередження з виправленням (`install Docker` або `openclaw config set agents.defaults.sandbox.mode off`).
-- Якщо `gateway.auth.token`/`gateway.auth.password` керуються SecretRef і недоступні в поточному шляху команди, doctor повідомляє попередження лише для читання й не записує резервні облікові дані відкритим текстом.
-- Якщо перевірка SecretRef каналу не вдається на шляху виправлення, doctor продовжує роботу й повідомляє попередження замість раннього завершення.
-- Після міграцій каталогу стану doctor попереджає, коли увімкнені типові облікові записи Telegram або Discord залежать від резервного env, а `TELEGRAM_BOT_TOKEN` або `DISCORD_BOT_TOKEN` недоступні процесу doctor.
-- Автоматичне визначення імен користувачів Telegram `allowFrom` (`doctor --fix`) потребує визначуваного токена Telegram у поточному шляху команди. Якщо перевірка токена недоступна, doctor повідомляє попередження й пропускає автоматичне визначення для цього проходу.
+- `doctor --fix --non-interactive` повідомляє про відсутні або застарілі визначення служби Gateway, але не встановлює й не перезаписує їх поза режимом виправлення оновлення. Запустіть `openclaw gateway install` для відсутньої служби або `openclaw gateway install --force`, коли ви навмисно хочете замінити launcher.
+- Перевірки цілісності стану тепер виявляють осиротілі файли transcript у каталозі sessions. Їх архівування як `.deleted.<timestamp>` потребує інтерактивного підтвердження; `--fix`, `--yes` і безголові запуски залишають їх на місці.
+- Doctor також сканує `~/.openclaw/cron/jobs.json` (або `cron.store`) на наявність застарілих форм завдань cron і може переписати їх на місці до того, як scheduler буде змушений автоматично нормалізувати їх під час виконання.
+- У Linux doctor попереджає, коли crontab користувача все ще запускає застарілий `~/.openclaw/bin/ensure-whatsapp.sh`; цей скрипт більше не підтримується і може реєструвати хибні збої WhatsApp Gateway, коли cron не має середовища systemd user-bus.
+- Doctor очищає застарілий проміжний стан залежностей Plugin, створений старішими версіями OpenClaw. Він також виправляє відсутні налаштовані завантажувані plugins, коли registry може їх розпізнати, а проходження doctor 2026.5.2 автоматично встановлює завантажувані plugins, які вже використовує старіша конфігурація, перед позначенням конфігурації як зміненої для цього випуску.
+- Doctor виправляє застарілу конфігурацію Plugin, видаляючи відсутні ідентифікатори Plugin з `plugins.allow`/`plugins.entries`, а також відповідну висячу конфігурацію каналів, цілі Heartbeat і перевизначення моделей каналів, коли виявлення Plugin справне.
+- Doctor ізолює недійсну конфігурацію Plugin, вимикаючи відповідний запис `plugins.entries.<id>` і видаляючи його недійсний payload `config`. Запуск Gateway уже пропускає лише цей несправний Plugin, тож інші plugins і канали можуть продовжувати працювати.
+- Встановіть `OPENCLAW_SERVICE_REPAIR_POLICY=external`, коли інший supervisor керує життєвим циклом Gateway. Doctor усе ще повідомляє про справність Gateway/служби та застосовує виправлення, не пов’язані зі службами, але пропускає встановлення/запуск/перезапуск/bootstrap служби та очищення застарілих служб.
+- У Linux doctor ігнорує неактивні додаткові systemd units, схожі на Gateway, і не переписує метадані команди/entrypoint для запущеної systemd-служби Gateway під час виправлення. Спочатку зупиніть службу або використайте `openclaw gateway install --force`, коли ви навмисно хочете замінити активний launcher.
+- Doctor автоматично мігрує застарілу пласку конфігурацію Talk (`talk.voiceId`, `talk.modelId` та пов’язані ключі) у `talk.provider` + `talk.providers.<provider>`.
+- Повторні запуски `doctor --fix` більше не повідомляють/застосовують нормалізацію Talk, коли єдина різниця полягає в порядку ключів об’єкта.
+- Doctor містить перевірку готовності memory-search і може рекомендувати `openclaw configure --section model`, коли облікові дані embedding відсутні.
+- Doctor попереджає, коли не налаштовано власника команд. Власник команд — це обліковий запис людини-оператора, якому дозволено виконувати команди лише для власника й схвалювати небезпечні дії. Спарювання через DM лише дає комусь змогу говорити з ботом; якщо ви схвалили відправника до появи bootstrap першого власника, явно встановіть `commands.ownerAllowFrom`.
+- Doctor попереджає, коли налаштовані агенти в режимі Codex і в Codex home оператора існують особисті ресурси Codex CLI. Локальні запуски app-server Codex використовують ізольовані home для кожного агента, тому використовуйте `openclaw migrate codex --dry-run`, щоб інвентаризувати ресурси, які слід свідомо просунути.
+- Doctor попереджає, коли skills, дозволені для типового агента, недоступні в поточному середовищі виконання, бо відсутні bins, env vars, config або вимоги ОС. `doctor --fix` може вимкнути ці недоступні skills за допомогою `skills.entries.<skill>.enabled=false`; натомість встановіть/налаштуйте відсутню вимогу, коли хочете зберегти skill активним.
+- Якщо sandbox mode увімкнено, але Docker недоступний, doctor повідомляє попередження з високим сигналом і способом виправлення (`install Docker` або `openclaw config set agents.defaults.sandbox.mode off`).
+- Якщо `gateway.auth.token`/`gateway.auth.password` керуються SecretRef і недоступні в поточному шляху команди, doctor повідомляє попередження лише для читання й не записує fallback облікові дані у plaintext.
+- Якщо перевірка SecretRef каналу завершується невдало в шляху виправлення, doctor продовжує роботу й повідомляє попередження замість раннього завершення.
+- Після міграцій каталогу стану doctor попереджає, коли ввімкнені типові облікові записи Telegram або Discord залежать від env fallback, а `TELEGRAM_BOT_TOKEN` або `DISCORD_BOT_TOKEN` недоступні процесу doctor.
+- Автоматичне розпізнавання імен користувачів Telegram `allowFrom` (`doctor --fix`) потребує розпізнаваного токена Telegram у поточному шляху команди. Якщо перевірка токена недоступна, doctor повідомляє попередження й пропускає автоматичне розпізнавання для цього проходження.
 
 ## macOS: перевизначення env `launchctl`
 
-Якщо ви раніше запускали `launchctl setenv OPENCLAW_GATEWAY_TOKEN ...` (або `...PASSWORD`), це значення перевизначає ваш файл конфігурації й може спричиняти постійні помилки “unauthorized”.
+Якщо ви раніше запускали `launchctl setenv OPENCLAW_GATEWAY_TOKEN ...` (або `...PASSWORD`), це значення перевизначає ваш файл конфігурації та може спричиняти постійні помилки “unauthorized”.
 
 ```bash
 launchctl getenv OPENCLAW_GATEWAY_TOKEN
@@ -80,7 +81,7 @@ launchctl unsetenv OPENCLAW_GATEWAY_TOKEN
 launchctl unsetenv OPENCLAW_GATEWAY_PASSWORD
 ```
 
-## Пов’язано
+## Пов’язане
 
 - [Довідник CLI](/uk/cli)
 - [Gateway doctor](/uk/gateway/doctor)

docs/uk/cli/skills.md

@@ -1,27 +1,27 @@
 ---
 read_when:
-    - Ви хочете побачити, які Skills доступні та готові до запуску
-    - Ви хочете знайти, встановити або оновити Skills з ClawHub
-    - Ви хочете налагодити відсутні бінарні файли/env/конфігурацію для Skills
-summary: Довідка CLI для `openclaw skills` (search/install/update/list/info/check)
+    - Ви хочете переглянути, які Skills доступні та готові до запуску
+    - Ви хочете шукати, встановлювати або оновлювати Skills із ClawHub
+    - Ви хочете налагодити відсутні бінарні файли, змінні середовища або конфігурацію для Skills
+summary: Довідник CLI для `openclaw skills` (search/install/update/list/info/check)
 title: Skills
 x-i18n:
-    generated_at: "2026-04-28T00:10:36Z"
-    model: gpt-5.4
+    generated_at: "2026-05-02T18:57:50Z"
+    model: gpt-5.5
     provider: openai
-    source_hash: 5059bf04c68dabe289d2c376407a52989c970e3d16e7637a2c83f4e24ad6564c
+    source_hash: d819cdc421151a0093423f57a9e974489e9cc02de644358bd5700ee75181192e
     source_path: cli/skills.md
-    workflow: 15
+    workflow: 16
 ---
 
 # `openclaw skills`
 
-Переглядайте локальні Skills та встановлюйте/оновлюйте Skills з ClawHub.
+Переглядайте локальні Skills та встановлюйте/оновлюйте Skills із ClawHub.
 
-Пов’язане:
+Пов’язано:
 
 - Система Skills: [Skills](/uk/tools/skills)
-- Конфігурація Skills: [Skills config](/uk/tools/skills-config)
+- Конфігурація Skills: [Конфігурація Skills](/uk/tools/skills-config)
 - Встановлення з ClawHub: [ClawHub](/uk/tools/clawhub)
 
 ## Команди
@@ -45,37 +45,39 @@ openclaw skills info <name>
 openclaw skills info <name> --json
 openclaw skills info <name> --agent <id>
 openclaw skills check
-openclaw skills check --json
 openclaw skills check --agent <id>
+openclaw skills check --json
 ```
 
-`search`/`install`/`update` напряму використовують ClawHub і встановлюють у активний
-каталог робочого простору `skills/`. `list`/`info`/`check` як і раніше перевіряють локальні
-Skills, видимі для поточного робочого простору та конфігурації. Команди, що
-працюють з робочим простором, визначають цільовий робочий простір через `--agent <id>`,
-потім через поточний робочий каталог, якщо він знаходиться всередині налаштованого
-робочого простору агента, а потім через агента за замовчуванням.
+`search`/`install`/`update` використовують ClawHub напряму та встановлюють у
+каталог `skills/` активного робочого простору. `list`/`info`/`check` і надалі
+перевіряють локальні Skills, видимі для поточного робочого простору та конфігурації.
+Команди, що спираються на робочий простір, визначають цільовий робочий простір
+із `--agent <id>`, потім із поточного робочого каталогу, якщо він розташований
+усередині налаштованого робочого простору агента, а потім із типового агента.
 
-Ця команда CLI `install` завантажує теки Skills з ClawHub. Встановлення залежностей
-Skills через Gateway, які запускаються під час онбордингу або з налаштувань Skills,
-замість цього використовують окремий шлях запиту `skills.install`.
+Ця команда CLI `install` завантажує папки Skills із ClawHub. Встановлення
+залежностей Skills через Gateway, запущені з onboarding або налаштувань Skills,
+натомість використовують окремий шлях запиту `skills.install`.
 
 Примітки:
 
-- `search [query...]` приймає необов’язковий запит; не вказуйте його, щоб переглянути стандартну
-  стрічку пошуку ClawHub.
+- `search [query...]` приймає необов’язковий запит; пропустіть його, щоб переглянути типовий
+  пошуковий потік ClawHub.
 - `search --limit <n>` обмежує кількість повернених результатів.
-- `install --force` перезаписує наявну теку Skills робочого простору для того самого
+- `install --force` перезаписує наявну папку Skill робочого простору для того самого
   slug.
 - `--agent <id>` націлюється на один налаштований робочий простір агента та перевизначає
-  визначення за поточним робочим каталогом.
-- `update --all` оновлює лише відстежувані встановлення з ClawHub в активному робочому просторі.
-- `list` є дією за замовчуванням, якщо не вказано підкоманду.
-- `list`, `info` і `check` записують свій відформатований вивід у stdout. З
-  `--json` це означає, що машинозчитувані дані залишаються у stdout для каналів
+  визначення з поточного робочого каталогу.
+- `update --all` оновлює лише відстежувані встановлення ClawHub в активному робочому просторі.
+- `check --agent <id>` перевіряє робочий простір вибраного агента та повідомляє, які
+  готові Skills фактично видимі для prompt або командної поверхні цього агента.
+- `list` є типовою дією, якщо підкоманду не вказано.
+- `list`, `info` і `check` записують відрендерений вивід у stdout. З
+  `--json` це означає, що машиночитне корисне навантаження залишається в stdout для каналів
   і скриптів.
 
-## Пов’язане
+## Пов’язано
 
-- [Довідка CLI](/uk/cli)
+- [Довідник CLI](/uk/cli)
 - [Skills](/uk/tools/skills)

docs/uk/gateway/doctor.md

@@ -1,20 +1,20 @@
 ---
 read_when:
     - Додавання або змінення міграцій doctor
-    - Запровадження несумісних змін конфігурації
+    - Впровадження несумісних змін конфігурації
 sidebarTitle: Doctor
 summary: 'Команда doctor: перевірки справності, міграції конфігурації та кроки відновлення'
 title: Діагностика
 x-i18n:
-    generated_at: "2026-05-02T15:57:45Z"
+    generated_at: "2026-05-02T18:57:45Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 1e8150c43662402a4dfe6eb89a804d1de3a73ad8a78f783fd0506e5976c2761f
+    source_hash: 504cf06e8457315eb1df4970a877b88fdc2e32f34974ce789875373e9e030234
     source_path: gateway/doctor.md
     workflow: 16
 ---
 
-`openclaw doctor` — це інструмент виправлення + міграції для OpenClaw. Він виправляє застарілі конфігурацію/стан, перевіряє справність і надає практичні кроки для виправлення.
+`openclaw doctor` — це інструмент відновлення + міграції для OpenClaw. Він виправляє застарілі конфігурації/стан, перевіряє працездатність і надає дієві кроки для відновлення.
 
 ## Швидкий старт
 
@@ -22,7 +22,7 @@ x-i18n:
 openclaw doctor
 ```
 
-### Режими без інтерфейсу та автоматизації
+### Безголові режими та режими автоматизації
 
 <Tabs>
   <Tab title="--yes">
@@ -30,7 +30,7 @@ openclaw doctor
     openclaw doctor --yes
     ```
 
-    Приймає стандартні варіанти без запитів (зокрема кроки перезапуску/сервісу/виправлення sandbox, коли застосовно).
+    Приймати стандартні значення без запитів (включно з кроками відновлення перезапуску/служби/пісочниці, коли застосовно).
 
   </Tab>
   <Tab title="--repair">
@@ -38,7 +38,7 @@ openclaw doctor
     openclaw doctor --repair
     ```
 
-    Застосовує рекомендовані виправлення без запитів (виправлення + перезапуски, де це безпечно).
+    Застосувати рекомендовані виправлення без запитів (виправлення + перезапуски, де це безпечно).
 
   </Tab>
   <Tab title="--repair --force">
@@ -46,7 +46,7 @@ openclaw doctor
     openclaw doctor --repair --force
     ```
 
-    Також застосовує агресивні виправлення (перезаписує користувацькі конфігурації супервізора).
+    Також застосувати агресивні виправлення (перезаписує користувацькі конфігурації супервізора).
 
   </Tab>
   <Tab title="--non-interactive">
@@ -54,7 +54,7 @@ openclaw doctor
     openclaw doctor --non-interactive
     ```
 
-    Запускається без запитів і застосовує лише безпечні міграції (нормалізація конфігурації + переміщення стану на диску). Пропускає дії перезапуску/сервісу/sandbox, які потребують підтвердження людини. Міграції застарілого стану запускаються автоматично, коли їх виявлено.
+    Запустити без запитів і застосувати лише безпечні міграції (нормалізація конфігурації + переміщення стану на диску). Пропускає дії перезапуску/служби/пісочниці, які потребують підтвердження людиною. Міграції застарілого стану запускаються автоматично після виявлення.
 
   </Tab>
   <Tab title="--deep">
@@ -62,7 +62,7 @@ openclaw doctor
     openclaw doctor --deep
     ```
 
-    Сканує системні сервіси на наявність додаткових інсталяцій Gateway (launchd/systemd/schtasks).
+    Просканувати системні служби на додаткові встановлення gateway (launchd/systemd/schtasks).
 
   </Tab>
 </Tabs>
@@ -73,112 +73,113 @@ openclaw doctor
 cat ~/.openclaw/openclaw.json
 ```
 
-## Що він робить (коротко)
+## Що він робить (зведення)
 
 <AccordionGroup>
-  <Accordion title="Справність, UI та оновлення">
-    - Необов’язкове попереднє оновлення для git-інсталяцій (лише інтерактивно).
-    - Перевірка актуальності протоколу UI (перезбирає Control UI, коли схема протоколу новіша).
-    - Перевірка справності + запит на перезапуск.
-    - Зведення стану Skills (придатні/відсутні/заблоковані) і стан Plugin.
+  <Accordion title="Health, UI, and updates">
+    - Необов’язкове попереднє оновлення для git-встановлень (лише інтерактивно).
+    - Перевірка актуальності протоколу UI (перебудовує Control UI, коли схема протоколу новіша).
+    - Перевірка працездатності + запит на перезапуск.
+    - Зведення стану Skills (доступні/відсутні/заблоковані) і стан plugin.
 
   </Accordion>
-  <Accordion title="Конфігурація та міграції">
+  <Accordion title="Config and migrations">
     - Нормалізація конфігурації для застарілих значень.
-    - Міграція конфігурації Talk із застарілих пласких полів `talk.*` у `talk.provider` + `talk.providers.<provider>`.
+    - Міграція конфігурації Talk із застарілих плоских полів `talk.*` у `talk.provider` + `talk.providers.<provider>`.
     - Перевірки міграції браузера для застарілих конфігурацій розширення Chrome і готовності Chrome MCP.
     - Попередження про перевизначення провайдера OpenCode (`models.providers.opencode` / `models.providers.opencode-go`).
     - Попередження про затінення OAuth Codex (`models.providers.openai-codex`).
-    - Перевірка передумов OAuth TLS для профілів OpenAI Codex OAuth.
-    - Попередження allowlist Plugin/інструментів, коли `plugins.allow` є обмежувальним, але політика інструментів досі запитує wildcard або інструменти, що належать Plugin.
+    - Перевірка передумов TLS OAuth для профілів OpenAI Codex OAuth.
+    - Попередження щодо списку дозволених plugin/інструментів, коли `plugins.allow` є обмежувальним, але політика інструментів усе ще запитує wildcard або інструменти, що належать plugin.
     - Міграція застарілого стану на диску (сесії/каталог агента/автентифікація WhatsApp).
-    - Міграція застарілих ключів контракту маніфесту Plugin (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders` → `contracts`).
-    - Міграція застарілого сховища cron (`jobId`, `schedule.cron`, поля доставки/корисного навантаження верхнього рівня, `provider` у корисному навантаженні, прості резервні webhook-завдання `notify: true`).
-    - Міграція застарілої політики runtime агента до `agents.defaults.agentRuntime` і `agents.list[].agentRuntime`.
-    - Очищення застарілої конфігурації Plugin, коли плагіни ввімкнені; коли `plugins.enabled=false`, застарілі посилання на Plugin розглядаються як інертна конфігурація ізоляції та зберігаються.
+    - Міграція застарілих ключів контракту маніфесту plugin (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders` → `contracts`).
+    - Міграція застарілого сховища cron (`jobId`, `schedule.cron`, поля доставки/payload верхнього рівня, payload `provider`, прості резервні webhook-завдання `notify: true`).
+    - Міграція застарілої runtime-policy агента до `agents.defaults.agentRuntime` і `agents.list[].agentRuntime`.
+    - Очищення застарілої конфігурації plugin, коли plugins увімкнені; коли `plugins.enabled=false`, застарілі посилання на plugin вважаються інертною конфігурацією стримування та зберігаються.
 
   </Accordion>
-  <Accordion title="Стан і цілісність">
-    - Перевірка файлів блокування сесій і очищення застарілих блокувань.
-    - Виправлення транскриптів сесій для дубльованих гілок переписування prompt, створених ураженими збірками 2026.4.24.
-    - Виявлення tombstone для відновлення після перезапуску завислого субагента, з підтримкою `--fix` для очищення застарілих прапорців перерваного відновлення, щоб запуск не продовжував вважати дочірній процес перерваним через перезапуск.
+  <Accordion title="State and integrity">
+    - Перевірка lock-файлів сесій і очищення застарілих lock-файлів.
+    - Відновлення транскриптів сесій для дубльованих гілок переписування промптів, створених у зачеплених збірках 2026.4.24.
+    - Виявлення tombstone для відновлення після перезапуску застряглого subagent, з підтримкою `--fix` для очищення застарілих прапорців перерваного відновлення, щоб запуск не продовжував вважати дочірній процес перерваним під час перезапуску.
     - Перевірки цілісності стану та дозволів (сесії, транскрипти, каталог стану).
     - Перевірки дозволів файлу конфігурації (chmod 600) під час локального запуску.
-    - Справність автентифікації моделей: перевіряє завершення строку дії OAuth, може оновлювати токени, що скоро спливають, і повідомляє про cooldown/вимкнені стани auth-profile.
-    - Виявлення додаткового каталогу робочого простору (`~/openclaw`).
+    - Стан автентифікації моделі: перевіряє завершення строку дії OAuth, може оновлювати токени, строк дії яких спливає, і повідомляє про стани cooldown/disabled auth-profile.
+    - Виявлення додаткового каталогу робочої області (`~/openclaw`).
 
   </Accordion>
-  <Accordion title="Gateway, сервіси та супервізори">
-    - Виправлення образу sandbox, коли sandboxing увімкнено.
-    - Міграція застарілих сервісів і виявлення додаткових Gateway.
+  <Accordion title="Gateway, services, and supervisors">
+    - Відновлення образу пісочниці, коли sandboxing увімкнено.
+    - Міграція застарілої служби та виявлення додаткових gateway.
     - Міграція застарілого стану каналу Matrix (у режимі `--fix` / `--repair`).
-    - Перевірки runtime Gateway (сервіс встановлено, але він не запущений; кешована мітка launchd).
-    - Попередження про стан каналу (зондуються із запущеного Gateway).
-    - Аудит конфігурації супервізора (launchd/systemd/schtasks) з необов’язковим виправленням.
-    - Очищення середовища вбудованого проксі для сервісів Gateway, які захопили значення shell `HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY` під час інсталяції або оновлення.
+    - Перевірки runtime Gateway (службу встановлено, але вона не запущена; кешована мітка launchd).
+    - Попередження про стан каналів (перевіряються з запущеного gateway).
+    - Аудит конфігурації супервізора (launchd/systemd/schtasks) з необов’язковим відновленням.
+    - Очищення середовища вбудованого проксі для служб gateway, які захопили значення shell `HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY` під час встановлення або оновлення.
     - Перевірки найкращих практик runtime Gateway (Node проти Bun, шляхи менеджера версій).
-    - Діагностика конфліктів порту Gateway (стандартно `18789`).
+    - Діагностика конфлікту порту Gateway (типово `18789`).
 
   </Accordion>
-  <Accordion title="Автентифікація, безпека та спарювання">
+  <Accordion title="Auth, security, and pairing">
     - Попередження безпеки для відкритих політик DM.
-    - Перевірки автентифікації Gateway для режиму локального токена (пропонує генерацію токена, коли джерела токена немає; не перезаписує конфігурації токена SecretRef).
-    - Виявлення проблем зі спарюванням пристрою (очікувані запити першого спарювання, очікувані підвищення ролі/області дії, застарілий дрейф локального кешу device-token і дрейф автентифікації paired-record).
+    - Перевірки автентифікації Gateway для режиму локального токена (пропонує генерацію токена, коли джерела токена немає; не перезаписує конфігурації SecretRef токена).
+    - Виявлення проблем зі спарюванням пристроїв (очікувані перші запити на спарювання, очікувані оновлення ролі/області, застарілий drift локального кешу device-token і drift автентифікації paired-record).
 
   </Accordion>
-  <Accordion title="Робочий простір і shell">
+  <Accordion title="Workspace and shell">
     - Перевірка systemd linger у Linux.
-    - Перевірка розміру bootstrap-файлу робочого простору (попередження про обрізання/наближення до ліміту для файлів контексту).
-    - Перевірка стану shell completion і автоінсталяція/оновлення.
-    - Перевірка готовності провайдера embedding для пошуку в пам’яті (локальна модель, ключ remote API або бінарний файл QMD).
-    - Перевірки інсталяції з джерел (невідповідність робочого простору pnpm, відсутні UI-ресурси, відсутній бінарний файл tsx).
-    - Записує оновлену конфігурацію + метадані майстра.
+    - Перевірка розміру bootstrap-файлу робочої області (попередження про обрізання/наближення до ліміту для контекстних файлів).
+    - Перевірка готовності Skills для агента за замовчуванням; повідомляє дозволені skills з відсутніми bin, env, config або вимогами ОС, а `--fix` може вимкнути недоступні skills у `skills.entries`.
+    - Перевірка стану автодоповнення shell і автоматичне встановлення/оновлення.
+    - Перевірка готовності embedding-провайдера пошуку пам’яті (локальна модель, ключ віддаленого API або бінарний файл QMD).
+    - Перевірки встановлення з джерел (невідповідність робочої області pnpm, відсутні UI-ресурси, відсутній бінарний файл tsx).
+    - Записує оновлену конфігурацію + метадані wizard.
 
   </Accordion>
 </AccordionGroup>
 
-## Заповнення й скидання Dreams UI
+## Зворотне заповнення та скидання Dreams UI
 
-Сцена Dreams у Control UI включає дії **Backfill**, **Reset** і **Clear Grounded** для робочого процесу grounded dreaming. Ці дії використовують RPC-методи в стилі gateway doctor, але вони **не** є частиною виправлення/міграції CLI `openclaw doctor`.
+Сцена Dreams у Control UI містить дії **Backfill**, **Reset** і **Clear Grounded** для workflow grounded dreaming. Ці дії використовують RPC-методи в стилі gateway doctor, але вони **не** є частиною CLI-відновлення/міграції `openclaw doctor`.
 
 Що вони роблять:
 
-- **Backfill** сканує історичні файли `memory/YYYY-MM-DD.md` в активному робочому просторі, запускає grounded REM diary pass і записує оборотні backfill-записи в `DREAMS.md`.
-- **Reset** видаляє з `DREAMS.md` лише ці позначені backfill-записи щоденника.
-- **Clear Grounded** видаляє лише staged grounded-only короткострокові записи, що походять з історичного replay і ще не накопичили live recall або daily support.
+- **Backfill** сканує історичні файли `memory/YYYY-MM-DD.md` в активній робочій області, запускає grounded REM diary pass і записує оборотні записи зворотного заповнення в `DREAMS.md`.
+- **Reset** видаляє лише ці позначені diary-записи зворотного заповнення з `DREAMS.md`.
+- **Clear Grounded** видаляє лише підготовлені короткострокові записи grounded-only, які походять з історичного replay і ще не накопичили live recall або daily support.
 
-Що вони **не** роблять самі по собі:
+Чого вони самі по собі **не** роблять:
 
 - вони не редагують `MEMORY.md`
 - вони не запускають повні міграції doctor
-- вони не додають автоматично staged grounded candidates у live short-term promotion store, якщо ви спершу явно не запустите staged CLI path
+- вони автоматично не розміщують grounded-кандидатів у live short-term promotion store, якщо ви явно спершу не запустите staged CLI path
 
-Якщо ви хочете, щоб grounded historical replay впливав на звичайний deep promotion lane, використовуйте натомість CLI-потік:
+Якщо ви хочете, щоб grounded historical replay впливав на звичайну deep promotion lane, натомість використайте CLI-flow:
 
 ```bash
 openclaw memory rem-backfill --path ./memory --stage-short-term
 ```
 
-Це додає grounded durable candidates у short-term dreaming store, залишаючи `DREAMS.md` поверхнею для перегляду.
+Це розміщує grounded durable candidates у short-term dreaming store, залишаючи `DREAMS.md` поверхнею для перегляду.
 
-## Докладна поведінка й обґрунтування
+## Детальна поведінка та обґрунтування
 
 <AccordionGroup>
-  <Accordion title="0. Необов’язкове оновлення (git-інсталяції)">
+  <Accordion title="0. Optional update (git installs)">
     Якщо це git checkout і doctor запускається інтерактивно, він пропонує оновитися (fetch/rebase/build) перед запуском doctor.
   </Accordion>
-  <Accordion title="1. Нормалізація конфігурації">
+  <Accordion title="1. Config normalization">
     Якщо конфігурація містить застарілі форми значень (наприклад, `messages.ackReaction` без перевизначення для конкретного каналу), doctor нормалізує їх до поточної схеми.
 
-    Це включає застарілі пласкі поля Talk. Поточна публічна конфігурація Talk — це `talk.provider` + `talk.providers.<provider>`. Doctor переписує старі форми `talk.voiceId` / `talk.voiceAliases` / `talk.modelId` / `talk.outputFormat` / `talk.apiKey` у мапу провайдера.
+    Це включає застарілі плоскі поля Talk. Поточна публічна конфігурація Talk — це `talk.provider` + `talk.providers.<provider>`. Doctor переписує старі форми `talk.voiceId` / `talk.voiceAliases` / `talk.modelId` / `talk.outputFormat` / `talk.apiKey` у мапу провайдерів.
 
-    Doctor також попереджає, коли `plugins.allow` не порожній, а політика інструментів використовує
-    wildcard або записи інструментів, що належать Plugin. `tools.allow: ["*"]` відповідає лише інструментам
-    із Plugin, які фактично завантажуються; він не обходить ексклюзивний allowlist Plugin.
+    Doctor також попереджає, коли `plugins.allow` не порожній і політика інструментів використовує
+    wildcard або записи інструментів, що належать plugin. `tools.allow: ["*"]` відповідає лише інструментам
+    із plugins, які фактично завантажуються; це не обходить ексклюзивний список дозволених plugin.
 
   </Accordion>
-  <Accordion title="2. Міграції застарілих ключів конфігурації">
-    Коли конфігурація містить застарілі ключі, інші команди відмовляються запускатися та просять вас виконати `openclaw doctor`.
+  <Accordion title="2. Legacy config key migrations">
+    Коли конфігурація містить застарілі ключі, інші команди відмовляються запускатися й просять вас запустити `openclaw doctor`.
 
     Doctor:
 
@@ -186,7 +187,7 @@ openclaw memory rem-backfill --path ./memory --stage-short-term
     - Покаже застосовану міграцію.
     - Перепише `~/.openclaw/openclaw.json` з оновленою схемою.
 
-    Gateway також автоматично запускає міграції doctor під час старту, коли виявляє застарілий формат конфігурації, тож застарілі конфігурації виправляються без ручного втручання. Міграції сховища cron-завдань обробляються через `openclaw doctor --fix`.
+    Gateway також автоматично запускає міграції doctor під час запуску, коли виявляє застарілий формат конфігурації, тому застарілі конфігурації відновлюються без ручного втручання. Міграції сховища Cron-завдань обробляє `openclaw doctor --fix`.
 
     Поточні міграції:
 
@@ -211,7 +212,7 @@ openclaw memory rem-backfill --path ./memory --stage-short-term
     - `plugins.entries.voice-call.config.streaming.sttProvider` → `plugins.entries.voice-call.config.streaming.provider`
     - `plugins.entries.voice-call.config.streaming.openaiApiKey|sttModel|silenceDurationMs|vadThreshold` → `plugins.entries.voice-call.config.streaming.providers.openai.*`
     - `bindings[].match.accountID` → `bindings[].match.accountId`
-    - Для каналів з іменованими `accounts`, але із залишковими верхньорівневими значеннями каналу для одного облікового запису, перемістіть ці значення з областю дії облікового запису до підвищеного облікового запису, вибраного для цього каналу (`accounts.default` для більшості каналів; Matrix може зберегти наявну відповідну іменовану/стандартну ціль)
+    - Для каналів з іменованими `accounts`, але із залишковими значеннями каналу верхнього рівня для одного облікового запису, перемістіть ці значення з областю дії облікового запису в підвищений обліковий запис, вибраний для цього каналу (`accounts.default` для більшості каналів; Matrix може зберегти наявну відповідну іменовану/типову ціль)
     - `identity` → `agents.list[].identity`
     - `agent.*` → `agents.defaults` + `tools.*` (tools/elevated/exec/sandbox/subagents)
     - `agent.model`/`allowedModels`/`modelAliases`/`modelFallbacks`/`imageModelFallbacks` → `agents.defaults.models` + `agents.defaults.model.primary/fallbacks` + `agents.defaults.imageModel.primary/fallbacks`
@@ -219,276 +220,276 @@ openclaw memory rem-backfill --path ./memory --stage-short-term
     - `browser.ssrfPolicy.allowPrivateNetwork` → `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork`
     - `browser.profiles.*.driver: "extension"` → `"existing-session"`
     - видаліть `browser.relayBindHost` (застаріле налаштування ретранслятора розширення)
-    - застаріле `models.providers.*.api: "openai"` → `"openai-completions"` (запуск Gateway також пропускає провайдерів, у яких `api` задано майбутнім або невідомим значенням enum, замість аварійно завершуватися у закритому режимі)
+    - застаріле `models.providers.*.api: "openai"` → `"openai-completions"` (запуск gateway також пропускає провайдери, у яких `api` встановлено на майбутнє або невідоме значення enum, замість аварійного завершення у закритому стані)
 
-    Попередження doctor також містять поради щодо стандартного облікового запису для багатооблікових каналів:
+    Попередження doctor також містять настанови щодо типового облікового запису для багатооблікових каналів:
 
     - Якщо налаштовано два або більше записів `channels.<channel>.accounts` без `channels.<channel>.defaultAccount` або `accounts.default`, doctor попереджає, що резервна маршрутизація може вибрати неочікуваний обліковий запис.
-    - Якщо `channels.<channel>.defaultAccount` задано як невідомий ідентифікатор облікового запису, doctor попереджає і перелічує налаштовані ідентифікатори облікових записів.
+    - Якщо `channels.<channel>.defaultAccount` встановлено на невідомий ID облікового запису, doctor попереджає і перелічує налаштовані ID облікових записів.
 
   </Accordion>
   <Accordion title="2b. Перевизначення провайдера OpenCode">
-    Якщо ви вручну додали `models.providers.opencode`, `opencode-zen` або `opencode-go`, це перевизначає вбудований каталог OpenCode з `@mariozechner/pi-ai`. Це може примусово спрямувати моделі до неправильного API або обнулити витрати. Doctor попереджає, щоб ви могли видалити перевизначення та відновити маршрутизацію API й витрати для кожної моделі.
+    Якщо ви вручну додали `models.providers.opencode`, `opencode-zen` або `opencode-go`, це перевизначає вбудований каталог OpenCode з `@mariozechner/pi-ai`. Це може примусово спрямувати моделі на неправильний API або обнулити вартість. Doctor попереджає, щоб ви могли видалити перевизначення і відновити маршрутизацію API та вартість для кожної моделі.
   </Accordion>
-  <Accordion title="2c. Міграція браузера та готовність Chrome MCP">
-    Якщо ваша конфігурація браузера досі вказує на видалений шлях розширення Chrome, doctor нормалізує її до поточної моделі локального для хоста підключення Chrome MCP:
+  <Accordion title="2c. Міграція браузера і готовність Chrome MCP">
+    Якщо ваша конфігурація браузера все ще вказує на видалений шлях розширення Chrome, doctor нормалізує її до поточної моделі підключення host-local Chrome MCP:
 
     - `browser.profiles.*.driver: "extension"` стає `"existing-session"`
     - `browser.relayBindHost` видаляється
 
-    Doctor також перевіряє локальний для хоста шлях Chrome MCP, коли ви використовуєте `defaultProfile: "user"` або налаштований профіль `existing-session`:
+    Doctor також перевіряє шлях host-local Chrome MCP, коли ви використовуєте `defaultProfile: "user"` або налаштований профіль `existing-session`:
 
-    - перевіряє, чи встановлено Google Chrome на тому самому хості для стандартних профілів автоматичного підключення
+    - перевіряє, чи Google Chrome встановлено на тому самому хості для типових профілів автоматичного підключення
     - перевіряє виявлену версію Chrome і попереджає, коли вона нижча за Chrome 144
     - нагадує увімкнути віддалене налагодження на сторінці інспектування браузера (наприклад, `chrome://inspect/#remote-debugging`, `brave://inspect/#remote-debugging` або `edge://inspect/#remote-debugging`)
 
-    Doctor не може увімкнути налаштування на боці Chrome замість вас. Локальний для хоста Chrome MCP усе ще потребує:
+    Doctor не може ввімкнути налаштування на стороні Chrome замість вас. Host-local Chrome MCP усе ще потребує:
 
-    - браузер на основі Chromium 144+ на хості gateway/node
-    - браузер, що працює локально
-    - увімкнене віддалене налагодження в цьому браузері
-    - підтвердження першого запиту згоди на підключення в браузері
+    - браузера на основі Chromium 144+ на хості gateway/node
+    - локально запущеного браузера
+    - увімкненого віддаленого налагодження в цьому браузері
+    - схвалення першого запиту згоди на підключення в браузері
 
-    Готовність тут стосується лише передумов локального підключення. Existing-session зберігає поточні обмеження маршрутів Chrome MCP; розширені маршрути на кшталт `responsebody`, експорту PDF, перехоплення завантажень і пакетних дій усе ще потребують керованого браузера або сирого профілю CDP.
+    Готовність тут стосується лише передумов локального підключення. Existing-session зберігає поточні обмеження маршрутів Chrome MCP; розширені маршрути, як-от `responsebody`, експорт PDF, перехоплення завантажень і пакетні дії, усе ще потребують керованого браузера або сирого профілю CDP.
 
-    Ця перевірка **не** застосовується до Docker, sandbox, remote-browser або інших безголових потоків. Вони й далі використовують сирий CDP.
+    Ця перевірка **не** застосовується до Docker, sandbox, remote-browser або інших headless-потоків. Вони й надалі використовують сирий CDP.
 
   </Accordion>
   <Accordion title="2d. Передумови OAuth TLS">
-    Коли налаштовано профіль OpenAI Codex OAuth, doctor перевіряє endpoint авторизації OpenAI, щоб переконатися, що локальний стек Node/OpenSSL TLS може перевірити ланцюг сертифікатів. Якщо перевірка завершується помилкою сертифіката (наприклад, `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, прострочений сертифікат або самопідписаний сертифікат), doctor виводить специфічні для платформи поради щодо виправлення. На macOS з Homebrew Node виправлення зазвичай таке: `brew postinstall ca-certificates`. З `--deep` перевірка виконується навіть тоді, коли gateway справний.
+    Коли налаштовано профіль OpenAI Codex OAuth, doctor перевіряє кінцеву точку авторизації OpenAI, щоб переконатися, що локальний стек Node/OpenSSL TLS може перевірити ланцюжок сертифікатів. Якщо перевірка завершується помилкою сертифіката (наприклад, `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, прострочений сертифікат або самопідписаний сертифікат), doctor виводить настанови з виправлення для конкретної платформи. На macOS з Homebrew Node виправленням зазвичай є `brew postinstall ca-certificates`. З `--deep` перевірка виконується навіть тоді, коли gateway справний.
   </Accordion>
   <Accordion title="2e. Перевизначення провайдера Codex OAuth">
-    Якщо раніше ви додали застарілі транспортні налаштування OpenAI у `models.providers.openai-codex`, вони можуть затіняти вбудований шлях провайдера Codex OAuth, який новіші випуски використовують автоматично. Doctor попереджає, коли бачить ці старі транспортні налаштування разом із Codex OAuth, щоб ви могли видалити або переписати застаріле транспортне перевизначення та повернути вбудовану поведінку маршрутизації/резервування. Користувацькі проксі та перевизначення лише заголовків і надалі підтримуються та не спричиняють це попередження.
+    Якщо раніше ви додали застарілі налаштування транспорту OpenAI у `models.providers.openai-codex`, вони можуть затіняти вбудований шлях провайдера Codex OAuth, який новіші випуски використовують автоматично. Doctor попереджає, коли бачить ці старі налаштування транспорту поряд із Codex OAuth, щоб ви могли видалити або переписати застаріле перевизначення транспорту і повернути вбудовану поведінку маршрутизації/резервування. Користувацькі проксі та перевизначення лише заголовків усе ще підтримуються і не запускають це попередження.
   </Accordion>
-  <Accordion title="2f. Попередження маршрутів Plugin Codex">
-    Коли ввімкнено комплектний Plugin Codex, doctor також перевіряє, чи refs первинних моделей `openai-codex/*` досі розв'язуються через стандартний runner PI. Така комбінація є дійсною, коли ви хочете використовувати Codex OAuth/автентифікацію підписки через PI, але її легко сплутати з нативним harness сервера застосунку Codex. Doctor попереджає та вказує на явну форму сервера застосунку: `openai/*` плюс `agentRuntime.id: "codex"` або `OPENCLAW_AGENT_RUNTIME=codex`.
+  <Accordion title="2f. Попередження маршрутів Codex plugin">
+    Коли вбудований Codex plugin увімкнено, doctor також перевіряє, чи посилання на первинні моделі `openai-codex/*` досі розв'язуються через типовий PI runner. Така комбінація чинна, коли ви хочете використовувати автентифікацію Codex OAuth/підписки через PI, але її легко сплутати з нативним app-server harness Codex. Doctor попереджає і вказує на явну форму app-server: `openai/*` плюс `agentRuntime.id: "codex"` або `OPENCLAW_AGENT_RUNTIME=codex`.
 
-    Doctor не виправляє це автоматично, бо обидва маршрути є дійсними:
+    Doctor не виправляє це автоматично, бо обидва маршрути чинні:
 
-    - `openai-codex/*` + PI означає «використовувати Codex OAuth/автентифікацію підписки через звичайний runner OpenClaw».
-    - `openai/*` + `agentRuntime.id: "codex"` означає «виконати вбудований turn через нативний сервер застосунку Codex».
-    - `/codex ...` означає «керувати або прив'язати нативну розмову Codex із чату».
-    - `/acp ...` або `runtime: "acp"` означає «використовувати зовнішній адаптер ACP/acpx».
+    - `openai-codex/*` + PI означає "використовувати автентифікацію Codex OAuth/підписки через звичайний runner OpenClaw."
+    - `openai/*` + `agentRuntime.id: "codex"` означає "запустити вбудований turn через нативний app-server Codex."
+    - `/codex ...` означає "керувати або прив'язати нативну розмову Codex з чату."
+    - `/acp ...` або `runtime: "acp"` означає "використовувати зовнішній адаптер ACP/acpx."
 
-    Якщо з'являється попередження, виберіть потрібний маршрут і відредагуйте конфігурацію вручну. Залиште попередження без змін, коли PI Codex OAuth є навмисним.
+    Якщо з'являється попередження, виберіть потрібний маршрут і відредагуйте конфігурацію вручну. Залиште попередження як є, коли PI Codex OAuth є навмисним.
 
   </Accordion>
   <Accordion title="3. Міграції застарілого стану (розкладка диска)">
-    Doctor може мігрувати старіші розкладки на диску до поточної структури:
+    Doctor може мігрувати старіші розкладки на диску в поточну структуру:
 
-    - Сховище сеансів + transcripts:
+    - Сховище сесій + транскрипти:
       - з `~/.openclaw/sessions/` до `~/.openclaw/agents/<agentId>/sessions/`
     - Каталог агента:
       - з `~/.openclaw/agent/` до `~/.openclaw/agents/<agentId>/agent/`
     - Стан автентифікації WhatsApp (Baileys):
       - із застарілих `~/.openclaw/credentials/*.json` (крім `oauth.json`)
-      - до `~/.openclaw/credentials/whatsapp/<accountId>/...` (стандартний ідентифікатор облікового запису: `default`)
+      - до `~/.openclaw/credentials/whatsapp/<accountId>/...` (типовий ID облікового запису: `default`)
 
-    Ці міграції виконуються за принципом найкращого зусилля та є ідемпотентними; doctor виводитиме попередження, коли залишатиме будь-які застарілі папки як резервні копії. Gateway/CLI також автоматично мігрує застарілі сеанси + каталог агента під час запуску, щоб історія/автентифікація/моделі потрапляли в шлях для конкретного агента без ручного запуску doctor. Автентифікація WhatsApp навмисно мігрується лише через `openclaw doctor`. Нормалізація провайдера talk/мапи провайдерів тепер порівнює за структурною рівністю, тому різниці лише в порядку ключів більше не спричиняють повторних змін без ефекту від `doctor --fix`.
+    Ці міграції виконуються за принципом найкращого зусилля та є ідемпотентними; doctor виводитиме попередження, коли залишає будь-які застарілі папки як резервні копії. Gateway/CLI також автоматично мігрує застарілі сесії + каталог агента під час запуску, щоб історія/автентифікація/моделі потрапили у шлях для конкретного агента без ручного запуску doctor. Нормалізація провайдера talk/мапи провайдерів тепер порівнює за структурною рівністю, тому відмінності лише в порядку ключів більше не запускають повторні no-op зміни `doctor --fix`.
 
   </Accordion>
-  <Accordion title="3a. Міграції застарілих маніфестів Plugin">
-    Doctor сканує всі встановлені маніфести Plugin на наявність застарілих верхньорівневих ключів можливостей (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders`). Коли їх знайдено, він пропонує перемістити їх до об'єкта `contracts` і переписати файл маніфесту на місці. Ця міграція є ідемпотентною; якщо ключ `contracts` уже має ті самі значення, застарілий ключ видаляється без дублювання даних.
+  <Accordion title="3a. Міграції застарілих маніфестів plugin">
+    Doctor сканує всі встановлені маніфести plugin на наявність застарілих ключів можливостей верхнього рівня (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders`). Коли їх знайдено, він пропонує перемістити їх до об'єкта `contracts` і переписати файл маніфесту на місці. Ця міграція ідемпотентна; якщо ключ `contracts` уже має ті самі значення, застарілий ключ видаляється без дублювання даних.
   </Accordion>
-  <Accordion title="3b. Міграції застарілого сховища Cron">
-    Doctor також перевіряє сховище завдань cron (`~/.openclaw/cron/jobs.json` за замовчуванням або `cron.store`, коли перевизначено) на старі форми завдань, які планувальник досі приймає для сумісності.
+  <Accordion title="3b. Міграції застарілого сховища cron">
+    Doctor також перевіряє сховище завдань cron (`~/.openclaw/cron/jobs.json` типово або `cron.store`, коли перевизначено) на наявність старих форм завдань, які планувальник усе ще приймає для сумісності.
 
     Поточні очищення cron включають:
 
     - `jobId` → `id`
     - `schedule.cron` → `schedule.expr`
-    - верхньорівневі поля payload (`message`, `model`, `thinking`, ...) → `payload`
-    - верхньорівневі поля delivery (`deliver`, `channel`, `to`, `provider`, ...) → `delivery`
-    - псевдоніми доставки payload `provider` → явний `delivery.channel`
-    - прості застарілі резервні webhook-завдання `notify: true` → явний `delivery.mode="webhook"` з `delivery.to=cron.webhook`
+    - поля payload верхнього рівня (`message`, `model`, `thinking`, ...) → `payload`
+    - поля delivery верхнього рівня (`deliver`, `channel`, `to`, `provider`, ...) → `delivery`
+    - delivery-псевдоніми `provider` у payload → явний `delivery.channel`
+    - прості застарілі резервні завдання webhook `notify: true` → явний `delivery.mode="webhook"` з `delivery.to=cron.webhook`
 
-    Doctor автоматично мігрує завдання `notify: true` лише тоді, коли може зробити це без зміни поведінки. Якщо завдання поєднує застарілий резервний notify з наявним режимом доставки не через webhook, doctor попереджає та залишає це завдання для ручного перегляду.
+    Doctor автоматично мігрує завдання `notify: true` лише тоді, коли може зробити це без зміни поведінки. Якщо завдання поєднує застарілий резервний notify з наявним режимом доставки не через webhook, doctor попереджає і залишає це завдання для ручного перегляду.
 
-    На Linux doctor також попереджає, коли crontab користувача досі викликає застарілий `~/.openclaw/bin/ensure-whatsapp.sh`. Цей локальний для хоста скрипт не підтримується поточним OpenClaw і може записувати хибні повідомлення `Gateway inactive` до `~/.openclaw/logs/whatsapp-health.log`, коли cron не може досягти користувацької шини systemd. Видаліть застарілий запис crontab за допомогою `crontab -e`; використовуйте `openclaw channels status --probe`, `openclaw doctor` і `openclaw gateway status` для поточних перевірок справності.
+    На Linux doctor також попереджає, коли crontab користувача все ще викликає застарілий `~/.openclaw/bin/ensure-whatsapp.sh`. Цей host-local скрипт не підтримується поточним OpenClaw і може записувати хибні повідомлення `Gateway inactive` до `~/.openclaw/logs/whatsapp-health.log`, коли cron не може дістатися до користувацької шини systemd. Видаліть застарілий запис crontab за допомогою `crontab -e`; використовуйте `openclaw channels status --probe`, `openclaw doctor` і `openclaw gateway status` для поточних перевірок справності.
 
   </Accordion>
   <Accordion title="3c. Очищення блокувань сеансів">
-    Засіб діагностики сканує кожен каталог сеансу агента на наявність застарілих файлів блокування запису — файлів, що залишилися після аварійного завершення сеансу. Для кожного знайденого файлу блокування він повідомляє: шлях, PID, чи PID досі активний, вік блокування та чи вважається воно застарілим (мертвий PID або старше ніж 30 хвилин). У режимі `--fix` / `--repair` він автоматично видаляє застарілі файли блокування; інакше друкує примітку та вказує повторно запустити з `--fix`.
+    Doctor сканує кожен каталог сеансів агентів на наявність застарілих файлів блокування запису — файлів, що залишилися після аварійного завершення сеансу. Для кожного знайденого файлу блокування він повідомляє: шлях, PID, чи PID досі активний, вік блокування та чи вважається воно застарілим (мертвий PID або старіше за 30 хвилин). У режимі `--fix` / `--repair` він автоматично видаляє застарілі файли блокування; інакше друкує примітку та вказує повторно запустити з `--fix`.
   </Accordion>
-  <Accordion title="3d. Відновлення гілки транскрипту сеансу">
-    Засіб діагностики сканує JSONL-файли сеансів агентів на наявність дубльованої форми гілки, створеної помилкою переписування транскрипту промпта від 2026.4.24: покинутий хід користувача з внутрішнім runtime-контекстом OpenClaw і активний сусідній хід із тим самим видимим користувацьким промптом. У режимі `--fix` / `--repair` засіб діагностики створює резервну копію кожного зачепленого файлу поруч з оригіналом і переписує транскрипт на активну гілку, щоб історія Gateway і читачі пам’яті більше не бачили дубльованих ходів.
+  <Accordion title="3d. Виправлення гілки транскрипту сеансу">
+    Doctor сканує JSONL-файли сеансів агентів на дубльовану форму гілки, створену помилкою переписування транскрипту промпта від 2026.4.24: покинутий хід користувача з внутрішнім runtime-контекстом OpenClaw плюс активний сусідній елемент із тим самим видимим промптом користувача. У режимі `--fix` / `--repair` doctor створює резервну копію кожного ураженого файлу поруч з оригіналом і переписує транскрипт до активної гілки, щоб історія gateway і читачі пам’яті більше не бачили дубльованих ходів.
   </Accordion>
   <Accordion title="4. Перевірки цілісності стану (збереження сеансів, маршрутизація та безпека)">
-    Каталог стану — це операційний мозковий стовбур. Якщо він зникне, ви втратите сеанси, облікові дані, журнали та конфігурацію (якщо не маєте резервних копій деінде).
+    Каталог стану — це операційний стовбур системи. Якщо він зникне, ви втратите сеанси, облікові дані, журнали та конфігурацію (якщо не маєте резервних копій деінде).
 
-    Засіб діагностики перевіряє:
+    Doctor перевіряє:
 
     - **Каталог стану відсутній**: попереджає про катастрофічну втрату стану, пропонує повторно створити каталог і нагадує, що не може відновити відсутні дані.
     - **Дозволи каталогу стану**: перевіряє можливість запису; пропонує виправити дозволи (і виводить підказку `chown`, коли виявлено невідповідність власника/групи).
-    - **Каталог стану macOS, синхронізований із хмарою**: попереджає, коли стан розташовано під iCloud Drive (`~/Library/Mobile Documents/com~apple~CloudDocs/...`) або `~/Library/CloudStorage/...`, бо шляхи із синхронізацією можуть спричиняти повільніше I/O та перегони блокування/синхронізації.
-    - **Каталог стану Linux на SD або eMMC**: попереджає, коли стан розташовано на джерелі монтування `mmcblk*`, бо випадкове I/O на SD або eMMC може бути повільнішим і швидше зношувати носій під час записів сеансів і облікових даних.
+    - **Синхронізований із хмарою каталог стану macOS**: попереджає, коли стан розміщується під iCloud Drive (`~/Library/Mobile Documents/com~apple~CloudDocs/...`) або `~/Library/CloudStorage/...`, оскільки шляхи з синхронізацією можуть спричиняти повільніше I/O та перегони блокування/синхронізації.
+    - **Каталог стану Linux на SD або eMMC**: попереджає, коли стан розміщується на джерелі монтування `mmcblk*`, оскільки випадкове I/O на SD або eMMC може бути повільнішим і швидше зношувати носій під час записів сеансів та облікових даних.
     - **Каталоги сеансів відсутні**: `sessions/` і каталог сховища сеансів потрібні для збереження історії та уникнення збоїв `ENOENT`.
-    - **Невідповідність транскриптів**: попереджає, коли в нещодавніх записах сеансів бракує файлів транскриптів.
-    - **Основний сеанс "1-рядковий JSONL"**: позначає випадки, коли основний транскрипт має лише один рядок (історія не накопичується).
-    - **Кілька каталогів стану**: попереджає, коли в домашніх каталогах існує кілька папок `~/.openclaw` або коли `OPENCLAW_STATE_DIR` вказує в інше місце (історія може розділитися між інсталяціями).
-    - **Нагадування про віддалений режим**: якщо `gateway.mode=remote`, засіб діагностики нагадує запустити його на віддаленому хості (стан міститься там).
+    - **Невідповідність транскрипту**: попереджає, коли в нещодавніх записах сеансів відсутні файли транскриптів.
+    - **Основний сеанс "1-line JSONL"**: позначає випадок, коли основний транскрипт має лише один рядок (історія не накопичується).
+    - **Кілька каталогів стану**: попереджає, коли в домашніх каталогах існує кілька папок `~/.openclaw` або коли `OPENCLAW_STATE_DIR` вказує в інше місце (історія може розділятися між інсталяціями).
+    - **Нагадування про віддалений режим**: якщо `gateway.mode=remote`, doctor нагадує запустити його на віддаленому хості (стан зберігається там).
     - **Дозволи файлу конфігурації**: попереджає, якщо `~/.openclaw/openclaw.json` доступний для читання групі/всім, і пропонує посилити дозволи до `600`.
 
   </Accordion>
-  <Accordion title="5. Стан автентифікації моделей (закінчення терміну дії OAuth)">
-    Засіб діагностики перевіряє OAuth-профілі в сховищі автентифікації, попереджає, коли термін дії токенів скоро спливає або вже сплив, і може безпечно оновити їх, коли це можливо. Якщо OAuth/токен-профіль Anthropic застарів, він пропонує API-ключ Anthropic або шлях setup-token Anthropic. Запити на оновлення з’являються лише під час інтерактивного запуску (TTY); `--non-interactive` пропускає спроби оновлення.
+  <Accordion title="5. Стан автентифікації моделі (закінчення строку OAuth)">
+    Doctor перевіряє профілі OAuth у сховищі автентифікації, попереджає, коли строк дії токенів минає або вже минув, і може безпечно оновити їх. Якщо профіль Anthropic OAuth/token застарів, він пропонує ключ API Anthropic або шлях setup-token Anthropic. Запити на оновлення з’являються лише під час інтерактивного запуску (TTY); `--non-interactive` пропускає спроби оновлення.
 
-    Коли оновлення OAuth остаточно не вдається (наприклад `refresh_token_reused`, `invalid_grant` або провайдер просить увійти знову), засіб діагностики повідомляє, що потрібна повторна автентифікація, і друкує точну команду `openclaw models auth login --provider ...`, яку потрібно запустити.
+    Коли оновлення OAuth остаточно не вдається (наприклад, `refresh_token_reused`, `invalid_grant` або провайдер просить увійти знову), doctor повідомляє, що потрібна повторна автентифікація, і друкує точну команду `openclaw models auth login --provider ...` для запуску.
 
-    Засіб діагностики також повідомляє про профілі автентифікації, які тимчасово непридатні через:
+    Doctor також повідомляє про профілі автентифікації, які тимчасово непридатні через:
 
-    - короткі періоди очікування (обмеження частоти/тайм-аути/помилки автентифікації)
-    - довші вимкнення (помилки білінгу/кредитів)
+    - короткі періоди очікування (обмеження швидкості/тайм-аути/збої автентифікації)
+    - довші вимкнення (збої оплати/кредитів)
 
   </Accordion>
-  <Accordion title="6. Валідація моделі хуків">
-    Якщо `hooks.gmail.model` задано, засіб діагностики перевіряє посилання на модель за каталогом і allowlist та попереджає, коли його не вдасться розв’язати або воно заборонене.
+  <Accordion title="6. Валідація моделі hooks">
+    Якщо встановлено `hooks.gmail.model`, doctor перевіряє посилання на модель за каталогом і allowlist та попереджає, коли воно не розв’яжеться або заборонене.
   </Accordion>
   <Accordion title="7. Відновлення образу пісочниці">
-    Коли пісочницю ввімкнено, засіб діагностики перевіряє Docker-образи й пропонує зібрати або перемкнутися на застарілі назви, якщо поточний образ відсутній.
+    Коли sandboxing увімкнено, doctor перевіряє образи Docker і пропонує зібрати або перейти на застарілі назви, якщо поточного образу немає.
   </Accordion>
-  <Accordion title="7b. Очищення встановлення Plugin">
-    Засіб діагностики видаляє застарілий згенерований OpenClaw стан проміжної підготовки залежностей плагінів у режимі `openclaw doctor --fix` / `openclaw doctor --repair`. Це охоплює застарілі згенеровані корені залежностей, старі каталоги етапу встановлення та локальне сміття пакетів від попереднього коду відновлення залежностей bundled-plugin.
+  <Accordion title="7b. Очищення інсталяції Plugin">
+    Doctor видаляє застарілий згенерований OpenClaw проміжний стан залежностей Plugin у режимі `openclaw doctor --fix` / `openclaw doctor --repair`. Це охоплює застарілі згенеровані корені залежностей, старі каталоги install-stage і локальні для пакета залишки від попереднього коду відновлення залежностей bundled-plugin.
 
-    Засіб діагностики також може перевстановити налаштовані завантажувані плагіни, коли конфігурація посилається на них, але локальний реєстр плагінів не може їх знайти. Для винесення bundled-plugin назовні у версії 2026.5.2 засіб діагностики автоматично встановлює завантажувані плагіни, які вже використовує наявна конфігурація, а потім покладається на `meta.lastTouchedVersion`, щоб виконати цей релізний прохід лише один раз. Запуск Gateway і перезавантаження конфігурації не запускають менеджери пакетів; встановлення плагінів залишається явною роботою doctor/install/update.
+    Doctor також може перевстановити налаштовані завантажувані plugins, коли конфігурація посилається на них, але локальний реєстр plugin не може їх знайти. Для externalization bundled-plugin у 2026.5.2 doctor автоматично встановлює завантажувані plugins, які вже використовує наявна конфігурація, а потім покладається на `meta.lastTouchedVersion`, щоб виконати цей релізний прохід лише один раз. Запуск Gateway і перезавантаження конфігурації не запускають менеджери пакетів; інсталяції plugin залишаються явною роботою doctor/install/update.
 
   </Accordion>
-  <Accordion title="8. Міграції служби Gateway і підказки з очищення">
-    Засіб діагностики виявляє застарілі служби Gateway (launchd/systemd/schtasks) і пропонує видалити їх та встановити службу OpenClaw із поточним портом Gateway. Він також може просканувати додаткові Gateway-подібні служби та надрукувати підказки з очищення. Служби Gateway OpenClaw з іменами профілів вважаються повноцінними та не позначаються як "додаткові".
+  <Accordion title="8. Міграції сервісу Gateway і підказки з очищення">
+    Doctor виявляє застарілі сервіси gateway (launchd/systemd/schtasks) і пропонує видалити їх та встановити сервіс OpenClaw з використанням поточного порту gateway. Він також може сканувати наявність додаткових сервісів, схожих на gateway, і друкувати підказки з очищення. Сервіси gateway OpenClaw з іменами профілів вважаються повноцінними та не позначаються як "додаткові."
 
-    У Linux, якщо користувацька служба Gateway відсутня, але існує системна служба Gateway OpenClaw, засіб діагностики не встановлює другу користувацьку службу автоматично. Перевірте за допомогою `openclaw gateway status --deep` або `openclaw doctor --deep`, а потім видаліть дублікат або задайте `OPENCLAW_SERVICE_REPAIR_POLICY=external`, коли життєвим циклом Gateway керує системний супервізор.
+    У Linux, якщо сервіс gateway на рівні користувача відсутній, але існує сервіс gateway OpenClaw на рівні системи, doctor не встановлює автоматично другий сервіс на рівні користувача. Перевірте за допомогою `openclaw gateway status --deep` або `openclaw doctor --deep`, а потім видаліть дублікат або встановіть `OPENCLAW_SERVICE_REPAIR_POLICY=external`, коли системний супервізор керує життєвим циклом gateway.
 
   </Accordion>
-  <Accordion title="8b. Міграція Matrix під час запуску">
-    Коли обліковий запис каналу Matrix має очікувану або придатну до дії міграцію застарілого стану, засіб діагностики (у режимі `--fix` / `--repair`) створює знімок перед міграцією, а потім виконує найкращі можливі кроки міграції: міграцію застарілого стану Matrix і підготовку застарілого зашифрованого стану. Обидва кроки не є фатальними; помилки журналюються, а запуск продовжується. У режимі лише для читання (`openclaw doctor` без `--fix`) ця перевірка повністю пропускається.
+  <Accordion title="8b. Міграція запуску Matrix">
+    Коли обліковий запис каналу Matrix має очікувану або доступну для виконання міграцію застарілого стану, doctor (у режимі `--fix` / `--repair`) створює знімок перед міграцією, а потім виконує best-effort кроки міграції: міграцію застарілого стану Matrix і підготовку застарілого зашифрованого стану. Обидва кроки не є фатальними; помилки журналюються, а запуск продовжується. У режимі лише читання (`openclaw doctor` без `--fix`) ця перевірка повністю пропускається.
   </Accordion>
-  <Accordion title="8c. Сполучення пристроїв і дрейф автентифікації">
-    Тепер засіб діагностики перевіряє стан сполучення пристроїв як частину звичайного проходу перевірки здоров’я.
+  <Accordion title="8c. Сполучення пристрою та дрейф автентифікації">
+    Doctor тепер перевіряє стан сполучення пристрою як частину звичайного проходу перевірки стану.
 
     Що він повідомляє:
 
-    - очікувані запити першого сполучення
-    - очікувані підвищення ролі для вже сполучених пристроїв
-    - очікувані підвищення scope для вже сполучених пристроїв
-    - відновлення невідповідності публічного ключа, коли ідентифікатор пристрою досі збігається, але ідентичність пристрою більше не відповідає схваленому запису
-    - сполучені записи, у яких бракує активного токена для схваленої ролі
-    - сполучені токени, чиї scope відхилилися за межі схваленої базової лінії сполучення
-    - локальні кешовані записи device-token для поточної машини, які передують ротації токена на боці Gateway або містять застарілі метадані scope
+    - запити на перше спарювання, що очікують
+    - підвищення ролі для вже спарених пристроїв, що очікують
+    - розширення області доступу для вже спарених пристроїв, що очікують
+    - виправлення невідповідності публічного ключа, коли ідентифікатор пристрою все ще збігається, але ідентичність пристрою більше не збігається із затвердженим записом
+    - спарені записи без активного токена для затвердженої ролі
+    - спарені токени, чиї області доступу відхилилися від затвердженої базової лінії спарювання
+    - локальні кешовані записи токенів пристрою для поточної машини, які передують ротації токена на боці gateway або містять застарілі метадані області доступу
 
-    Засіб діагностики не схвалює автоматично запити сполучення й не виконує автоматичну ротацію токенів пристроїв. Натомість він друкує точні наступні кроки:
+    Засіб діагностики не затверджує запити на спарювання автоматично й не виконує автоматичну ротацію токенів пристроїв. Натомість він друкує точні наступні кроки:
 
-    - перегляньте очікувані запити за допомогою `openclaw devices list`
-    - схваліть точний запит за допомогою `openclaw devices approve <requestId>`
-    - згенеруйте свіжий токен ротацією за допомогою `openclaw devices rotate --device <deviceId> --role <role>`
-    - видаліть і повторно схваліть застарілий запис за допомогою `openclaw devices remove <deviceId>`
+    - перегляньте запити, що очікують, за допомогою `openclaw devices list`
+    - затвердьте точний запит за допомогою `openclaw devices approve <requestId>`
+    - виконайте ротацію нового токена за допомогою `openclaw devices rotate --device <deviceId> --role <role>`
+    - видаліть і повторно затвердьте застарілий запис за допомогою `openclaw devices remove <deviceId>`
 
-    Це закриває поширену прогалину "вже сполучено, але все ще вимагає сполучення": тепер засіб діагностики відрізняє перше сполучення від очікуваних підвищень ролі/scope і від дрейфу застарілого токена/ідентичності пристрою.
+    Це закриває поширену прогалину "уже спарено, але все ще з'являється вимога спарювання": тепер засіб діагностики відрізняє перше спарювання від очікуваних підвищень ролі/області доступу та від дрейфу застарілого токена/ідентичності пристрою.
 
   </Accordion>
   <Accordion title="9. Попередження безпеки">
-    Засіб діагностики видає попередження, коли провайдер відкритий для DM без allowlist або коли політику налаштовано небезпечним способом.
+    Засіб діагностики видає попередження, коли провайдер відкритий для особистих повідомлень без allowlist або коли політику налаштовано небезпечним способом.
   </Accordion>
-  <Accordion title="10. Продовження роботи systemd (Linux)">
-    Якщо запуск відбувається як користувацька служба systemd, засіб діагностики забезпечує ввімкнення lingering, щоб Gateway залишався активним після виходу з системи.
+  <Accordion title="10. systemd linger (Linux)">
+    Якщо запуск відбувається як користувацька служба systemd, засіб діагностики перевіряє, що lingering увімкнено, щоб gateway залишався активним після виходу із системи.
   </Accordion>
-  <Accordion title="11. Стан робочого простору (Skills, плагіни та застарілі каталоги)">
-    Засіб діагностики друкує підсумок стану робочого простору для типового агента:
+  <Accordion title="11. Стан робочого простору (skills, plugins і застарілі каталоги)">
+    Засіб діагностики друкує зведення стану робочого простору для агента за замовчуванням:
 
-    - **Стан Skills**: рахує придатні, з відсутніми вимогами та заблоковані allowlist Skills.
-    - **Застарілі каталоги робочого простору**: попереджає, коли `~/openclaw` або інші застарілі каталоги робочого простору існують поруч із поточним робочим простором.
-    - **Стан Plugin**: рахує ввімкнені/вимкнені/помилкові плагіни; перелічує ID плагінів для всіх помилок; повідомляє можливості bundle plugin.
-    - **Попередження сумісності Plugin**: позначає плагіни, які мають проблеми сумісності з поточним runtime.
-    - **Діагностика Plugin**: показує будь-які попередження або помилки під час завантаження, видані реєстром плагінів.
+    - **Стан Skills**: підраховує skills, що відповідають вимогам, не мають вимог або заблоковані allowlist.
+    - **Застарілі каталоги робочого простору**: попереджає, коли `~/openclaw` або інші застарілі каталоги робочого простору існують поряд із поточним робочим простором.
+    - **Стан Plugin**: підраховує увімкнені/вимкнені/помилкові plugins; перелічує ідентифікатори plugins для будь-яких помилок; повідомляє про можливості пакетних plugins.
+    - **Попередження сумісності Plugin**: позначає plugins, які мають проблеми сумісності з поточним середовищем виконання.
+    - **Діагностика Plugin**: показує будь-які попередження або помилки під час завантаження, видані реєстром plugin.
 
   </Accordion>
-  <Accordion title="11b. Розмір файлів початкового контексту">
-    Засіб діагностики перевіряє, чи файли початкового контексту робочого простору (наприклад `AGENTS.md`, `CLAUDE.md` або інші ін’єктовані контекстні файли) наближаються до налаштованого бюджету символів або перевищують його. Він повідомляє для кожного файлу необроблену й ін’єктовану кількість символів, відсоток обрізання, причину обрізання (`max/file` або `max/total`) і загальну кількість ін’єктованих символів як частку від загального бюджету. Коли файли обрізані або близькі до ліміту, засіб діагностики друкує поради для налаштування `agents.defaults.bootstrapMaxChars` і `agents.defaults.bootstrapTotalMaxChars`.
+  <Accordion title="11b. Розмір bootstrap-файлу">
+    Засіб діагностики перевіряє, чи bootstrap-файли робочого простору (наприклад `AGENTS.md`, `CLAUDE.md` або інші впроваджені файли контексту) наближаються до налаштованого бюджету символів або перевищують його. Він повідомляє для кожного файлу необроблену кількість символів порівняно з впровадженою, відсоток обрізання, причину обрізання (`max/file` або `max/total`) і загальну кількість впроваджених символів як частку від загального бюджету. Коли файли обрізано або вони близькі до ліміту, засіб діагностики друкує поради щодо налаштування `agents.defaults.bootstrapMaxChars` і `agents.defaults.bootstrapTotalMaxChars`.
   </Accordion>
-  <Accordion title="11d. Очищення застарілих плагінів каналів">
-    Коли `openclaw doctor --fix` видаляє відсутній плагін каналу, він також видаляє завислу конфігурацію в області цього каналу, яка посилалася на цей плагін: записи `channels.<id>`, цілі Heartbeat, що називали канал, і перевизначення `agents.*.models["<channel>/*"]`. Це запобігає циклам завантаження Gateway, коли runtime каналу зник, але конфігурація все ще просить Gateway прив’язатися до нього.
+  <Accordion title="11d. Очищення застарілого channel plugin">
+    Коли `openclaw doctor --fix` видаляє відсутній channel plugin, він також видаляє підвішену конфігурацію з областю каналу, яка посилалася на цей plugin: записи `channels.<id>`, цілі heartbeat, що називали канал, і перевизначення `agents.*.models["<channel>/*"]`. Це запобігає циклам завантаження Gateway, коли середовище виконання каналу зникло, але конфігурація все ще просить gateway прив'язатися до нього.
   </Accordion>
   <Accordion title="11c. Автодоповнення оболонки">
-    Засіб діагностики перевіряє, чи встановлено автодоповнення Tab для поточної оболонки (zsh, bash, fish або PowerShell):
+    Засіб діагностики перевіряє, чи встановлено автодоповнення клавішею Tab для поточної оболонки (zsh, bash, fish або PowerShell):
 
-    - Якщо профіль оболонки використовує повільний динамічний шаблон автодоповнення (`source <(openclaw completion ...)`), засіб діагностики оновлює його до швидшого варіанта з кешованим файлом.
-    - Якщо автодоповнення налаштовано в профілі, але файл кешу відсутній, засіб діагностики автоматично регенерує кеш.
-    - Якщо автодоповнення взагалі не налаштовано, засіб діагностики пропонує встановити його (лише інтерактивний режим; пропускається з `--non-interactive`).
+    - Якщо профіль оболонки використовує повільний динамічний шаблон доповнення (`source <(openclaw completion ...)`), засіб діагностики оновлює його до швидшого варіанта кешованого файлу.
+    - Якщо доповнення налаштовано в профілі, але файл кешу відсутній, засіб діагностики автоматично регенерує кеш.
+    - Якщо доповнення взагалі не налаштовано, засіб діагностики пропонує встановити його (лише в інтерактивному режимі; пропускається з `--non-interactive`).
 
-    Запустіть `openclaw completion --write-state`, щоб регенерувати кеш вручну.
+    Запустіть `openclaw completion --write-state`, щоб вручну регенерувати кеш.
 
   </Accordion>
   <Accordion title="12. Перевірки автентифікації Gateway (локальний токен)">
-    Засіб діагностики перевіряє готовність автентифікації локального токена Gateway.
+    Засіб діагностики перевіряє готовність локальної токен-автентифікації gateway.
 
-    - Якщо режим токена потребує токен, а джерела токена немає, засіб діагностики пропонує згенерувати його.
-    - Якщо `gateway.auth.token` керується SecretRef, але недоступний, засіб діагностики попереджає й не перезаписує його відкритим текстом.
-    - `openclaw doctor --generate-gateway-token` примусово генерує токен лише тоді, коли не налаштовано SecretRef для токена.
+    - Якщо режим токена потребує токена, а джерела токена немає, засіб діагностики пропонує згенерувати його.
+    - Якщо `gateway.auth.token` керується SecretRef, але недоступний, засіб діагностики попереджає та не перезаписує його відкритим текстом.
+    - `openclaw doctor --generate-gateway-token` примусово генерує токен лише тоді, коли не налаштовано SecretRef токена.
 
   </Accordion>
-  <Accordion title="12b. Відновлення лише для читання з урахуванням SecretRef">
-    Деякі потоки відновлення мають перевіряти налаштовані облікові дані, не послаблюючи fail-fast поведінку runtime.
+  <Accordion title="12b. Виправлення лише для читання з урахуванням SecretRef">
+    Деякі потоки виправлення мають перевіряти налаштовані облікові дані без послаблення поведінки швидкого збою під час виконання.
 
-    - `openclaw doctor --fix` тепер використовує ту саму модель зведення SecretRef лише для читання, що й команди родини status, для цільових відновлень конфігурації.
-    - Приклад: відновлення Telegram `allowFrom` / `groupAllowFrom` `@username` намагається використати налаштовані облікові дані бота, коли вони доступні.
-    - Якщо токен бота Telegram налаштовано через SecretRef, але він недоступний у поточному шляху команди, засіб діагностики повідомляє, що облікові дані налаштовані, але недоступні, і пропускає автоматичне розв’язання замість збою або хибного повідомлення, що токен відсутній.
+    - `openclaw doctor --fix` тепер використовує ту саму модель підсумку SecretRef лише для читання, що й команди сімейства status, для цільових виправлень конфігурації.
+    - Приклад: виправлення Telegram `allowFrom` / `groupAllowFrom` `@username` намагається використовувати налаштовані облікові дані бота, коли вони доступні.
+    - Якщо токен бота Telegram налаштовано через SecretRef, але він недоступний у поточному шляху команди, засіб діагностики повідомляє, що облікові дані налаштовані, але недоступні, і пропускає автоматичне розв'язання замість аварійного завершення або помилкового повідомлення, що токен відсутній.
 
   </Accordion>
-  <Accordion title="13. Перевірка працездатності Gateway + перезапуск">
-    Діагностичний засіб виконує перевірку працездатності й пропонує перезапустити gateway, коли він виглядає непрацездатним.
+  <Accordion title="13. Перевірка справності Gateway + перезапуск">
+    Doctor виконує перевірку справності та пропонує перезапустити Gateway, коли він виглядає несправним.
   </Accordion>
-  <Accordion title="13b. Готовність пошуку в пам’яті">
-    Діагностичний засіб перевіряє, чи налаштований постачальник embedding для пошуку в пам’яті готовий для стандартного агента. Поведінка залежить від налаштованого backend і постачальника:
+  <Accordion title="13b. Готовність пошуку пам’яті">
+    Doctor перевіряє, чи налаштований постачальник ембедингів для пошуку пам’яті готовий для типового агента. Поведінка залежить від налаштованого бекенда та постачальника:
 
-    - **Backend QMD**: перевіряє, чи доступний і придатний до запуску бінарний файл `qmd`. Якщо ні, друкує вказівки з виправлення, зокрема npm-пакет і варіант ручного шляху до бінарного файла.
-    - **Явний локальний постачальник**: перевіряє наявність локального файла моделі або розпізнаного URL віддаленої/завантажуваної моделі. Якщо його немає, пропонує перейти на віддаленого постачальника.
-    - **Явний віддалений постачальник** (`openai`, `voyage` тощо): перевіряє, чи є API-ключ у середовищі або сховищі автентифікації. Друкує дієві підказки для виправлення, якщо ключ відсутній.
-    - **Автоматичний постачальник**: спочатку перевіряє доступність локальної моделі, а потім пробує кожного віддаленого постачальника в порядку автоматичного вибору.
+    - **Бекенд QMD**: перевіряє, чи доступний і придатний до запуску бінарний файл `qmd`. Якщо ні, виводить інструкції для виправлення, зокрема npm-пакет і варіант ручного шляху до бінарного файла.
+    - **Явний локальний постачальник**: перевіряє наявність локального файла моделі або розпізнаної віддаленої/завантажуваної URL-адреси моделі. Якщо її немає, пропонує перейти на віддаленого постачальника.
+    - **Явний віддалений постачальник** (`openai`, `voyage` тощо): перевіряє, чи є API-ключ у середовищі або сховищі автентифікації. Якщо його немає, виводить практичні підказки для виправлення.
+    - **Автоматичний постачальник**: спершу перевіряє доступність локальної моделі, а потім пробує кожного віддаленого постачальника в порядку автоматичного вибору.
 
-    Коли доступний кешований результат перевірки Gateway (gateway був працездатним під час перевірки), діагностичний засіб зіставляє його результат із видимою для CLI конфігурацією та зазначає будь-яку розбіжність. Діагностичний засіб не запускає новий embedding ping у стандартному шляху; використовуйте команду поглибленого статусу пам’яті, коли потрібна інтерактивна перевірка постачальника.
+    Коли доступний кешований результат зондування Gateway (Gateway був справним на момент перевірки), doctor зіставляє його результат із конфігурацією, видимою для CLI, і зазначає будь-яку розбіжність. Doctor не запускає новий ping ембедингів у типовому шляху; використовуйте команду глибокого стану пам’яті, коли потрібна жива перевірка постачальника.
 
-    Використовуйте `openclaw memory status --deep`, щоб перевірити готовність embedding під час виконання.
+    Використовуйте `openclaw memory status --deep`, щоб перевірити готовність ембедингів під час виконання.
 
   </Accordion>
-  <Accordion title="14. Попередження про статус каналу">
-    Якщо Gateway працездатний, діагностичний засіб виконує перевірку статусу каналу та повідомляє попередження із запропонованими виправленнями.
+  <Accordion title="14. Попередження про стан каналів">
+    Якщо Gateway справний, doctor виконує зондування стану каналу та повідомляє попередження із запропонованими виправленнями.
   </Accordion>
-  <Accordion title="15. Аудит і відновлення конфігурації supervisor">
-    Діагностичний засіб перевіряє встановлену конфігурацію supervisor (launchd/systemd/schtasks) на відсутні або застарілі типові значення (наприклад, залежності systemd від network-online і затримку перезапуску). Коли він знаходить невідповідність, рекомендує оновлення й може переписати файл служби/завдання до поточних типових значень.
+  <Accordion title="15. Аудит і відновлення конфігурації супервізора">
+    Doctor перевіряє встановлену конфігурацію супервізора (launchd/systemd/schtasks) на відсутні або застарілі типові параметри (наприклад, залежності systemd від network-online і затримку перезапуску). Коли він знаходить невідповідність, рекомендує оновлення та може переписати файл служби/завдання до поточних типових значень.
 
     Примітки:
 
-    - `openclaw doctor` запитує підтвердження перед переписуванням конфігурації supervisor.
-    - `openclaw doctor --yes` приймає стандартні запити на відновлення.
+    - `openclaw doctor` запитує підтвердження перед переписуванням конфігурації супервізора.
+    - `openclaw doctor --yes` приймає типові запити на відновлення.
     - `openclaw doctor --repair` застосовує рекомендовані виправлення без запитів.
-    - `openclaw doctor --repair --force` перезаписує користувацькі конфігурації supervisor.
-    - `OPENCLAW_SERVICE_REPAIR_POLICY=external` залишає діагностичний засіб у режимі лише читання для життєвого циклу служби Gateway. Він усе ще повідомляє про стан служби та виконує відновлення, не пов’язані зі службою, але пропускає встановлення/запуск/перезапуск/bootstrap служби, переписування конфігурації supervisor і очищення застарілих служб, оскільки цим життєвим циклом керує зовнішній supervisor.
-    - У Linux діагностичний засіб не переписує метадані команди/entrypoint, поки відповідний systemd unit Gateway активний. Він також ігнорує неактивні додаткові gateway-подібні units, які не є застарілими, під час сканування дубльованих служб, щоб супутні файли служб не створювали шуму очищення.
-    - Якщо token auth вимагає token і `gateway.auth.token` керується SecretRef, встановлення/відновлення служби діагностичним засобом перевіряє SecretRef, але не зберігає розв’язані значення plaintext token у метаданих середовища служби supervisor.
-    - Діагностичний засіб виявляє керовані значення середовища служби на основі `.env`/SecretRef, які старіші встановлення LaunchAgent, systemd або Windows Scheduled Task вбудовували inline, і переписує метадані служби так, щоб ці значення завантажувалися з runtime-джерела замість визначення supervisor.
-    - Діагностичний засіб виявляє, коли команда служби все ще фіксує старий `--port` після зміни `gateway.port`, і переписує метадані служби на поточний порт.
-    - Якщо token auth вимагає token, а налаштований SecretRef token не розв’язується, діагностичний засіб блокує шлях встановлення/відновлення з дієвими вказівками.
-    - Якщо налаштовано і `gateway.auth.token`, і `gateway.auth.password`, а `gateway.auth.mode` не задано, діагностичний засіб блокує встановлення/відновлення, доки mode не буде задано явно.
-    - Для Linux user-systemd units перевірки розбіжності token у діагностичному засобі тепер включають джерела як `Environment=`, так і `EnvironmentFile=` під час порівняння метаданих автентифікації служби.
-    - Відновлення служби діагностичним засобом відмовляються переписувати, зупиняти або перезапускати службу Gateway зі старішого бінарного файла OpenClaw, коли конфігурацію востаннє записала новіша версія. Див. [Усунення несправностей Gateway](/uk/gateway/troubleshooting#split-brain-installs-and-newer-config-guard).
+    - `openclaw doctor --repair --force` перезаписує власні конфігурації супервізора.
+    - `OPENCLAW_SERVICE_REPAIR_POLICY=external` залишає doctor у режимі лише читання для життєвого циклу служби Gateway. Він усе одно повідомляє про справність служби та виконує відновлення, не пов’язані зі службою, але пропускає встановлення/запуск/перезапуск/bootstrap служби, переписування конфігурації супервізора та очищення застарілих служб, оскільки цим життєвим циклом керує зовнішній супервізор.
+    - У Linux doctor не переписує метадані команди/точки входу, доки відповідний systemd unit Gateway активний. Він також ігнорує неактивні додаткові unit-и, схожі на Gateway, які не є застарілими, під час сканування дубльованих служб, щоб супровідні файли служб не створювали зайвий шум очищення.
+    - Якщо автентифікація токеном вимагає токен і `gateway.auth.token` керується SecretRef, встановлення/відновлення служби doctor перевіряє SecretRef, але не зберігає розв’язані значення токена у відкритому тексті в метадані середовища служби супервізора.
+    - Doctor виявляє керовані значення середовища служби на основі `.env`/SecretRef, які старіші встановлення LaunchAgent, systemd або Windows Scheduled Task вбудовували inline, і переписує метадані служби так, щоб ці значення завантажувалися з джерела виконання, а не з визначення супервізора.
+    - Doctor виявляє, коли команда служби все ще закріплює старий `--port` після зміни `gateway.port`, і переписує метадані служби на поточний порт.
+    - Якщо автентифікація токеном вимагає токен, а налаштований SecretRef токена не розв’язується, doctor блокує шлях встановлення/відновлення з практичними інструкціями.
+    - Якщо налаштовано і `gateway.auth.token`, і `gateway.auth.password`, а `gateway.auth.mode` не задано, doctor блокує встановлення/відновлення, доки режим не буде задано явно.
+    - Для Linux user-systemd unit-ів перевірки дрейфу токена doctor тепер охоплюють джерела і `Environment=`, і `EnvironmentFile=` під час порівняння метаданих автентифікації служби.
+    - Відновлення служби doctor відмовляються переписувати, зупиняти або перезапускати службу Gateway зі старішого бінарного файла OpenClaw, коли конфігурацію востаннє записала новіша версія. Див. [усунення несправностей Gateway](/uk/gateway/troubleshooting#split-brain-installs-and-newer-config-guard).
     - Ви завжди можете примусово виконати повне переписування через `openclaw gateway install --force`.
 
   </Accordion>
-  <Accordion title="16. Runtime Gateway + діагностика порту">
-    Діагностичний засіб перевіряє runtime служби (PID, останній exit status) і попереджає, коли службу встановлено, але вона фактично не працює. Він також перевіряє конфлікти портів на порту Gateway (типово `18789`) і повідомляє ймовірні причини (Gateway уже працює, SSH-тунель).
+  <Accordion title="16. Діагностика середовища виконання Gateway + портів">
+    Doctor перевіряє середовище виконання служби (PID, останній статус виходу) і попереджає, коли служба встановлена, але фактично не працює. Він також перевіряє конфлікти портів на порту Gateway (типово `18789`) і повідомляє ймовірні причини (Gateway уже запущено, SSH-тунель).
   </Accordion>
-  <Accordion title="17. Найкращі практики runtime Gateway">
-    Діагностичний засіб попереджає, коли служба Gateway працює на Bun або шляху Node, керованому менеджером версій (`nvm`, `fnm`, `volta`, `asdf` тощо). Канали WhatsApp + Telegram потребують Node, а шляхи менеджера версій можуть ламатися після оновлень, бо служба не завантажує вашу shell init. Діагностичний засіб пропонує перейти на системне встановлення Node, коли воно доступне (Homebrew/apt/choco).
+  <Accordion title="17. Найкращі практики середовища виконання Gateway">
+    Doctor попереджає, коли служба Gateway працює на Bun або шляху Node, керованому менеджером версій (`nvm`, `fnm`, `volta`, `asdf` тощо). Канали WhatsApp + Telegram потребують Node, а шляхи менеджера версій можуть ламатися після оновлень, бо служба не завантажує ініціалізацію вашої оболонки. Doctor пропонує перейти на системне встановлення Node, коли воно доступне (Homebrew/apt/choco).
 
-    Нововстановлені або відновлені macOS LaunchAgents використовують канонічний системний PATH (`/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin`) замість копіювання інтерактивного shell PATH, тому Volta, asdf, fnm, pnpm та інші каталоги менеджерів версій не змінюють, який Node розв’язують дочірні процеси. Служби Linux усе ще зберігають явні корені середовища (`NVM_DIR`, `FNM_DIR`, `VOLTA_HOME`, `ASDF_DATA_DIR`, `BUN_INSTALL`, `PNPM_HOME`) і стабільні каталоги user-bin, але вгадані fallback-каталоги менеджерів версій записуються до PATH служби лише тоді, коли ці каталоги існують на диску.
+    Нововстановлені або відновлені macOS LaunchAgents використовують канонічний системний PATH (`/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin`) замість копіювання PATH інтерактивної оболонки, тому Volta, asdf, fnm, pnpm та інші каталоги менеджерів версій не змінюють, який Node розв’язують дочірні процеси. Служби Linux і далі зберігають явні корені середовища (`NVM_DIR`, `FNM_DIR`, `VOLTA_HOME`, `ASDF_DATA_DIR`, `BUN_INSTALL`, `PNPM_HOME`) і стабільні каталоги user-bin, але вгадані резервні каталоги менеджерів версій записуються до PATH служби лише тоді, коли ці каталоги існують на диску.
 
   </Accordion>
   <Accordion title="18. Запис конфігурації + метадані майстра">
-    Діагностичний засіб зберігає всі зміни конфігурації та позначає метадані майстра, щоб зафіксувати запуск діагностики.
+    Doctor зберігає будь-які зміни конфігурації та ставить мітку метаданих майстра, щоб зафіксувати запуск doctor.
   </Accordion>
-  <Accordion title="19. Поради щодо робочого простору (резервна копія + система пам’яті)">
-    Діагностичний засіб пропонує систему пам’яті робочого простору, коли її немає, і друкує пораду щодо резервного копіювання, якщо робочий простір ще не перебуває під git.
+  <Accordion title="19. Поради щодо робочої області (резервна копія + система пам’яті)">
+    Doctor пропонує систему пам’яті робочої області, коли її немає, і виводить пораду щодо резервної копії, якщо робоча область ще не перебуває під git.
 
-    Див. [/concepts/agent-workspace](/uk/concepts/agent-workspace), щоб отримати повний посібник зі структури робочого простору та резервного копіювання git (рекомендовано приватний GitHub або GitLab).
+    Повний посібник зі структури робочої області та резервного копіювання git (рекомендовано приватний GitHub або GitLab) див. у [/concepts/agent-workspace](/uk/concepts/agent-workspace).
 
   </Accordion>
 </AccordionGroup>

docs/uk/help/testing-updates-plugins.md

@@ -1,34 +1,50 @@
 ---
 read_when:
-    - Зміна поведінки оновлення OpenClaw, doctor, приймання пакетів або встановлення Plugin
+    - Зміна поведінки оновлення OpenClaw, doctor, приймання пакунків або встановлення Plugin
     - Підготовка або затвердження реліз-кандидата
     - Налагодження регресій оновлення пакета, очищення залежностей Plugin або встановлення Plugin
 sidebarTitle: Update and plugin tests
 summary: Як OpenClaw перевіряє шляхи оновлення, міграції пакетів і поведінку встановлення/оновлення Plugin
 title: 'Тестування: оновлення та Plugin'
 x-i18n:
-    generated_at: "2026-05-02T15:57:59Z"
+    generated_at: "2026-05-02T18:57:57Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 7843767a4acca25ceea62633faa5f4bec954bebf7cc4eeb9f3b0b990313ff946
+    source_hash: 1a56e249f565cc23a439142b3332c0a57fd4afe9021b79f644d353946d6d2ffc
     source_path: help/testing-updates-plugins.md
     workflow: 16
 ---
 
-Це спеціальний контрольний список для перевірки оновлень і Plugin. Мета проста: довести, що інстальований пакет може оновлювати реальний стан користувача, відновлювати застарілий legacy-стан через `doctor` і надалі встановлювати, завантажувати, оновлювати та видаляти plugins з підтримуваних джерел.
+Це спеціальний контрольний список для валідації оновлення та Plugin. Мета
+проста: довести, що встановлюваний пакет може оновлювати реальний стан
+користувача, відновлювати застарілий legacy-стан через `doctor` і все ще
+встановлювати, завантажувати, оновлювати та видаляти Plugin-и з підтримуваних
+джерел.
 
-Для ширшої мапи засобу запуску тестів див. [Тестування](/uk/help/testing). Для live-ключів провайдерів і наборів, що торкаються мережі, див. [Live-тестування](/uk/help/testing-live).
+Ширшу карту засобів запуску тестів див. у [Тестуванні](/uk/help/testing). Для live-ключів
+провайдерів і наборів, що торкаються мережі, див.
+[Live-тестування](/uk/help/testing-live).
 
 ## Що ми захищаємо
 
-Тести оновлень і Plugin захищають такі контракти:
+Тести оновлення та Plugin захищають такі контракти:
 
-- Tarball пакета повний, має дійсний `dist/postinstall-inventory.json` і не залежить від розпакованих файлів репозиторію.
-- Користувач може перейти зі старішого опублікованого пакета на кандидатний пакет без втрати конфігурації, агентів, сесій, робочих просторів, списків дозволених plugins або конфігурації каналів.
-- `openclaw doctor --fix --non-interactive` відповідає за очищення legacy-стану та шляхи відновлення. Startup не має обростати прихованими міграціями сумісності для застарілого стану Plugin.
-- Встановлення Plugin працює з локальних директорій, git-репозиторіїв, npm-пакетів і шляху реєстру ClawHub.
-- npm-залежності Plugin встановлюються в керований npm-корінь, скануються перед довірою та видаляються через npm під час uninstall, щоб hoisted-залежності не залишалися.
-- Оновлення Plugin стабільне, коли нічого не змінилося: записи встановлення, вирішене джерело, розкладка встановлених залежностей і ввімкнений стан залишаються незмінними.
+- Tarball пакета є повним, має дійсний `dist/postinstall-inventory.json`
+  і не залежить від нерозпакованих файлів репозиторію.
+- Користувач може перейти зі старішого опублікованого пакета на пакет-кандидат
+  без втрати конфігурації, агентів, сесій, робочих просторів, allowlist-ів Plugin
+  або конфігурації каналу.
+- `openclaw doctor --fix --non-interactive` відповідає за очищення legacy-стану та
+  шляхи відновлення. Запуск не має обростати прихованими міграціями сумісності
+  для застарілого стану Plugin.
+- Встановлення Plugin працює з локальних директорій, git-репозиторіїв, npm-пакетів
+  і шляху реєстру ClawHub.
+- npm-залежності Plugin встановлюються в керований npm-корінь, скануються перед
+  довірою та видаляються через npm під час видалення, щоб hoisted-залежності
+  не залишалися.
+- Оновлення Plugin є стабільним, коли нічого не змінилося: записи встановлення,
+  resolved-джерело, макет встановлених залежностей і ввімкнений стан залишаються
+  незмінними.
 
 ## Локальне підтвердження під час розробки
 
@@ -40,25 +56,33 @@ pnpm check:changed
 pnpm test:changed
 ```
 
-Для змін у встановленні, видаленні, залежностях Plugin або package-inventory також запускайте сфокусовані тести, що покривають змінений seam:
+Для змін у встановленні, видаленні, залежностях Plugin або інвентарі пакета також
+запустіть сфокусовані тести, що покривають відредагований інтерфейс:
 
 ```bash
 pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts
 ```
 
-Перед тим як будь-яка package Docker lane споживатиме tarball, підтвердьте артефакт пакета:
+Перед тим як будь-яка Docker-доріжка пакета споживатиме tarball, підтвердьте
+артефакт пакета:
 
 ```bash
 pnpm release:check
 ```
 
-`release:check` запускає перевірки drift для config/docs/API, записує package dist inventory, виконує `npm pack --dry-run`, відхиляє заборонені запаковані файли, встановлює tarball у тимчасовий prefix, запускає postinstall і виконує smoke-перевірки entrypoints вбудованих каналів.
+`release:check` запускає перевірки drift-у конфігурації/документації/API, записує
+інвентар дистрибутива пакета, запускає `npm pack --dry-run`, відхиляє заборонені
+запаковані файли, встановлює tarball у тимчасовий prefix, запускає postinstall і
+smoke-перевіряє entrypoint-и bundled-каналів.
 
-## Docker lanes
+## Docker-доріжки
 
-Docker lanes є підтвердженням продуктового рівня. Вони встановлюють або оновлюють реальний пакет усередині Linux-контейнерів і перевіряють поведінку через CLI-команди, запуск Gateway, HTTP-проби, RPC-статус і стан файлової системи.
+Docker-доріжки є підтвердженням на рівні продукту. Вони встановлюють або
+оновлюють реальний пакет усередині Linux-контейнерів і перевіряють поведінку
+через CLI-команди, запуск Gateway, HTTP-проби, RPC-статус і стан файлової
+системи.
 
-Використовуйте сфокусовані lanes під час ітерацій:
+Під час ітерацій використовуйте сфокусовані доріжки:
 
 ```bash
 pnpm test:docker:plugins
@@ -68,13 +92,31 @@ pnpm test:docker:published-upgrade-survivor
 pnpm test:docker:update-migration
 ```
 
-Важливі lanes:
+Важливі доріжки:
 
-- `test:docker:plugins` перевіряє smoke встановлення Plugin, встановлення з локальної папки, поведінку пропуску оновлення локальної папки, локальні папки з попередньо встановленими залежностями, встановлення `file:` пакетів, git-встановлення з виконанням CLI, оновлення git moving-ref, встановлення з npm registry з hoisted transitive dependencies, npm update no-ops, встановлення з локальної ClawHub fixture та update no-ops, поведінку marketplace update і Claude-bundle enable/inspect. Установіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб блок ClawHub залишався hermetic/offline.
-- `test:docker:plugin-update` перевіряє, що незмінений встановлений Plugin не перевстановлюється і не втрачає install metadata під час `openclaw plugins update`.
-- `test:docker:upgrade-survivor` встановлює candidate tarball поверх dirty old-user fixture, запускає package update плюс non-interactive doctor, потім стартує loopback Gateway і перевіряє збереження стану.
-- `test:docker:published-upgrade-survivor` спочатку встановлює published baseline, налаштовує його через вбудований рецепт `openclaw config set`, оновлює до candidate tarball, запускає doctor, перевіряє legacy cleanup, стартує Gateway і пробує `/healthz`, `/readyz` та RPC status.
-- `test:docker:update-migration` є cleanup-heavy published-update lane. Він стартує з налаштованого user state у стилі Discord/Telegram, запускає baseline doctor, щоб налаштовані залежності Plugin мали шанс матеріалізуватися, seed-ить legacy plugin dependency debris для налаштованого packaged plugin, оновлює до candidate tarball і вимагає, щоб post-update doctor видалив legacy dependency roots.
+- `test:docker:plugins` валідує smoke встановлення Plugin, встановлення локальних
+  папок, поведінку пропуску оновлення локальних папок, локальні папки з попередньо
+  встановленими залежностями, встановлення `file:` пакетів, git-встановлення з
+  виконанням CLI, оновлення git moving-ref, встановлення з npm-реєстру з hoisted
+  транзитивними залежностями, npm update no-op-и, встановлення локальних ClawHub
+  fixture-ів і update no-op-и, поведінку оновлення marketplace, а також увімкнення/
+  inspect Claude-bundle. Установіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб блок
+  ClawHub залишався герметичним/offline.
+- `test:docker:plugin-update` валідує, що незмінений встановлений Plugin не
+  перевстановлюється і не втрачає метадані встановлення під час `openclaw plugins update`.
+- `test:docker:upgrade-survivor` встановлює tarball-кандидат поверх брудного
+  fixture-а старого користувача, запускає оновлення пакета плюс неінтерактивний
+  doctor, потім запускає loopback Gateway і перевіряє збереження стану.
+- `test:docker:published-upgrade-survivor` спочатку встановлює опублікований baseline,
+  конфігурує його через вбудований рецепт `openclaw config set`, оновлює до
+  tarball-кандидата, запускає doctor, перевіряє legacy-очищення, запускає Gateway
+  і зондує `/healthz`, `/readyz` та RPC-статус.
+- `test:docker:update-migration` є cleanup-heavy доріжкою опублікованого оновлення.
+  Вона стартує з налаштованого користувацького стану в стилі Discord/Telegram,
+  запускає baseline doctor, щоб налаштовані залежності Plugin отримали шанс
+  матеріалізуватися, додає legacy-сміття залежностей Plugin для налаштованого
+  packaged Plugin, оновлює до tarball-кандидата та вимагає, щоб post-update doctor
+  видалив legacy-корені залежностей.
 
 Корисні варіанти published-upgrade survivor:
 
@@ -88,9 +130,16 @@ OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=bootstrap-persona \
 pnpm test:docker:published-upgrade-survivor
 ```
 
-Доступні сценарії: `base`, `feishu-channel`, `bootstrap-persona`, `plugin-deps-cleanup`, `configured-plugin-installs`, `tilde-log-path` і `versioned-runtime-deps`. В aggregate runs `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues` розгортається в усі reported issue-shaped сценарії, включно з configured-plugin install migration.
+Доступні сценарії: `base`, `feishu-channel`, `bootstrap-persona`,
+`plugin-deps-cleanup`, `configured-plugin-installs`, `tilde-log-path` і
+`versioned-runtime-deps`. В aggregate-запусках
+`OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues` розгортається в усі
+сценарії форми reported issue, включно з міграцією встановлення configured-plugin.
 
-Повна update migration навмисно відокремлена від Full Release CI. Використовуйте ручний workflow `Update Migration`, коли release question: «чи може кожен опублікований stable release від 2026.4.23 і далі оновитися до цього кандидата та очистити plugin dependency debris?»:
+Повна міграція оновлень навмисно відокремлена від Full Release CI. Використовуйте
+ручний workflow `Update Migration`, коли release-питання таке: «чи може кожен
+опублікований stable-реліз від 2026.4.23 і далі оновитися до цього кандидата та
+прибрати сміття залежностей Plugin?»:
 
 ```bash
 gh workflow run update-migration.yml \
@@ -101,18 +150,30 @@ gh workflow run update-migration.yml \
   -f scenarios=plugin-deps-cleanup
 ```
 
-## Package Acceptance
+## Приймання пакета
 
-Package Acceptance — це GitHub-native package gate. Він resolve-ить один candidate package у tarball `package-under-test`, записує version і SHA-256, а потім запускає reusable Docker E2E lanes проти саме цього tarball. Workflow harness ref відокремлений від package source ref, тому поточна test logic може перевіряти старіші trusted releases.
+Package Acceptance є GitHub-native gate-ом пакета. Він resolves один пакет-кандидат
+у tarball `package-under-test`, записує версію та SHA-256, а потім запускає
+reusable Docker E2E-доріжки проти саме цього tarball. Ref workflow harness є
+окремим від ref джерела пакета, тому поточна тестова логіка може валідувати
+старіші довірені релізи.
 
-Джерела candidate:
+Джерела кандидатів:
 
-- `source=npm`: перевіряє `openclaw@beta`, `openclaw@latest` або точну опубліковану версію.
-- `source=ref`: пакує trusted branch, tag або commit з вибраним current harness.
-- `source=url`: перевіряє HTTPS tarball з обов’язковим `package_sha256`.
-- `source=artifact`: повторно використовує tarball, завантажений іншим Actions run.
+- `source=npm`: валідуйте `openclaw@beta`, `openclaw@latest` або точну
+  опубліковану версію.
+- `source=ref`: пакуйте довірену гілку, тег або commit із вибраним поточним
+  harness.
+- `source=url`: валідуйте HTTPS tarball з обов’язковим `package_sha256`.
+- `source=artifact`: повторно використовуйте tarball, завантажений іншим
+  Actions-запуском.
 
-Release checks викликають Package Acceptance з набором package/update/plugin:
+Full Release Validation за замовчуванням використовує `source=artifact`, зібраний
+із resolved release SHA. Для post-publish підтвердження передайте
+`package_acceptance_package_spec=openclaw@YYYY.M.D`, щоб та сама upgrade-матриця
+цілилася в shipped npm-пакет.
+
+Release checks викликають Package Acceptance з package/update/plugin набором:
 
 ```text
 doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update
@@ -121,16 +182,23 @@ doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor
 Вони також передають:
 
 ```text
-published_upgrade_survivor_baselines=release-history
+published_upgrade_survivor_baselines=all-since-2026.4.23
 published_upgrade_survivor_scenarios=reported-issues
 telegram_mode=mock-openai
 ```
 
-Це тримає package migration, update channel switching, stale plugin dependency cleanup, offline plugin coverage, поведінку plugin update і Telegram package QA на одному resolved artifact.
+Це тримає міграцію пакета, перемикання update channel, очищення застарілих
+залежностей Plugin, offline-покриття Plugin, поведінку оновлення Plugin і
+Telegram package QA на одному resolved-артефакті.
 
-`release-history` — це bounded release-check sample: останні шість stable releases, `2026.4.23` і один старіший pre-date anchor. Для exhaustive published update migration coverage використовуйте `all-since-2026.4.23` в окремому workflow Update Migration замість Full Release CI.
+`all-since-2026.4.23` є upgrade-вибіркою Full Release CI: кожен stable
+npm-published реліз від `2026.4.23` до `latest`. Для вичерпного покриття
+міграції опублікованих оновлень використовуйте `all-since-2026.4.23` в окремому
+workflow Update Migration замість Full Release CI. `release-history` залишається
+доступним для ширшого ручного sampling, коли вам також потрібен legacy pre-date
+anchor.
 
-Запускайте package profile вручну під час перевірки кандидата перед release:
+Запустіть package profile вручну під час валідації кандидата перед релізом:
 
 ```bash
 gh workflow run package-acceptance.yml \
@@ -139,54 +207,78 @@ gh workflow run package-acceptance.yml \
   -f source=npm \
   -f package_spec=openclaw@beta \
   -f suite_profile=package \
-  -f published_upgrade_survivor_baselines=release-history \
+  -f published_upgrade_survivor_baselines=all-since-2026.4.23 \
   -f published_upgrade_survivor_scenarios=reported-issues \
   -f telegram_mode=mock-openai
 ```
 
-Використовуйте `suite_profile=product`, коли release question включає MCP channels, cron/subagent cleanup, OpenAI web search або OpenWebUI. Використовуйте `suite_profile=full` лише тоді, коли потрібне повне покриття Docker release-path.
+Використовуйте `suite_profile=product`, коли release-питання охоплює MCP-канали,
+cron/subagent cleanup, OpenAI web search або OpenWebUI. Використовуйте
+`suite_profile=full` лише тоді, коли потрібне повне Docker-покриття release-path.
 
-## Типове для release
+## Типове підтвердження для релізу
 
-Для release candidates типовий stack підтвердження такий:
+Для release candidates типовий стек підтвердження такий:
 
-1. `pnpm check:changed` і `pnpm test:changed` для source-level regressions.
-2. `pnpm release:check` для integrity артефакта пакета.
-3. Package Acceptance `package` profile або release-check custom package lanes для контрактів install/update/plugin.
-4. Cross-OS release checks для OS-specific installer, onboarding і platform behavior.
-5. Live suites лише тоді, коли змінена поверхня торкається provider або hosted-service behavior.
+1. `pnpm check:changed` і `pnpm test:changed` для source-level регресій.
+2. `pnpm release:check` для цілісності артефакта пакета.
+3. Package Acceptance `package` profile або release-check custom package
+   lanes для контрактів install/update/plugin.
+4. Cross-OS release checks для OS-specific installer, onboarding і platform
+   поведінки.
+5. Live-набори лише тоді, коли змінена поверхня торкається поведінки провайдера
+   або hosted-service.
 
-На maintainer machines broad gates і Docker/package product proof мають запускатися в Testbox, якщо явно не виконується local proof.
+На maintainer-машинах broad gates і Docker/package product proof мають запускатися
+в Testbox, якщо явно не виконується локальне підтвердження.
 
 ## Legacy-сумісність
 
-Compatibility leniency є вузькою та обмеженою в часі:
+Поблажливість сумісності є вузькою та обмеженою в часі:
 
-- Пакети до `2026.4.25`, включно з `2026.4.25-beta.*`, можуть tolerate already-shipped package metadata gaps у Package Acceptance.
-- Опублікований пакет `2026.4.26` може warning для local build metadata stamp files, які вже shipped.
-- Пізніші пакети мають задовольняти сучасні контракти. Ті самі gaps fail замість warning або skipping.
+- Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть толерувати
+  вже shipped прогалини метаданих пакета в Package Acceptance.
+- Опублікований пакет `2026.4.26` може попереджати про вже shipped stamp-файли
+  метаданих локальної збірки.
+- Пізніші пакети мають відповідати сучасним контрактам. Ті самі прогалини
+  провалюються замість warning або skipping.
 
-Не додавайте нові startup migrations для цих старих shapes. Додайте або розширте doctor repair, потім підтвердьте це за допомогою `upgrade-survivor` або `published-upgrade-survivor`.
+Не додавайте нові startup-міграції для цих старих форм. Додайте або розширте
+doctor-відновлення, потім підтвердьте його через `upgrade-survivor` або
+`published-upgrade-survivor`.
 
 ## Додавання покриття
 
-Коли змінюєте поведінку update або Plugin, додавайте coverage на найнижчому шарі, який може fail з правильної причини:
+Коли змінюєте поведінку оновлення або Plugin, додавайте покриття на найнижчому
+рівні, який може впасти з правильної причини:
 
-- Pure path або metadata logic: unit test поруч із source.
-- Package inventory або packed-file behavior: `package-dist-inventory` або tarball checker test.
-- CLI install/update behavior: Docker lane assertion або fixture.
-- Published-release migration behavior: сценарій `published-upgrade-survivor`.
-- Registry/package source behavior: fixture `test:docker:plugins` або fixture server ClawHub.
-- Dependency layout або cleanup behavior: перевіряйте і runtime execution, і filesystem boundary. npm-залежності можуть бути hoisted під managed npm root, тому тести мають доводити, що root сканується/очищається, замість припущення про package-local дерево `node_modules`.
+- Чиста логіка шляхів або метаданих: unit-тест поруч із джерелом.
+- Поведінка інвентарю пакета або packed-file: `package-dist-inventory` або тест
+  tarball checker.
+- Поведінка CLI install/update: твердження або fixture Docker-доріжки.
+- Поведінка міграції published-release: сценарій `published-upgrade-survivor`.
+- Поведінка джерела registry/package: fixture `test:docker:plugins` або fixture
+  сервер ClawHub.
+- Поведінка макета залежностей або очищення: перевіряйте і runtime execution, і
+  межу файлової системи. npm-залежності можуть бути hoisted під керованим
+  npm-коренем, тому тести мають доводити, що корінь сканується/очищається, а не
+  припускати package-local дерево `node_modules`.
 
-Тримайте нові Docker fixtures hermetic за замовчуванням. Використовуйте local fixture registries і fake packages, якщо мета тесту не live registry behavior.
+Нові Docker fixture-и за замовчуванням мають бути герметичними. Використовуйте
+локальні fixture-реєстри та фейкові пакети, якщо метою тесту не є live-поведінка
+реєстру.
 
-## Failure triage
+## Тріаж збоїв
 
-Почніть з artifact identity:
+Починайте з ідентичності артефакта:
 
-- Summary Package Acceptance `resolve_package`: source, version, SHA-256 і artifact name.
-- Docker artifacts: `.artifacts/docker-tests/**/summary.json`, `failures.json`, lane logs і rerun commands.
-- Upgrade survivor summary: `.artifacts/upgrade-survivor/summary.json`, включно з baseline version, candidate version, scenario, phase timings і recipe steps.
+- Summary Package Acceptance `resolve_package`: source, version, SHA-256 і назва
+  artifact.
+- Docker artifacts: `.artifacts/docker-tests/**/summary.json`,
+  `failures.json`, lane logs і rerun commands.
+- Summary upgrade survivor: `.artifacts/upgrade-survivor/summary.json`,
+  включно з baseline version, candidate version, scenario, phase timings і
+  recipe steps.
 
-Надавайте перевагу rerun failed exact lane з тим самим package artifact, а не rerun усього release umbrella.
+Віддавайте перевагу повторному запуску exact failed lane з тим самим package
+artifact, а не повторному запуску всієї release umbrella.

docs/uk/reference/RELEASING.md

@@ -1,272 +1,274 @@
 ---
 read_when:
     - Пошук визначень публічних каналів випуску
-    - Запуск перевірки випуску або приймального тестування пакета
-    - Шукаєте інформацію про іменування версій і періодичність випусків
-summary: Канали випуску, контрольний список оператора, бокси валідації, іменування версій і ритм
-title: Політика випусків
+    - Запуск перевірки релізу або приймання пакета
+    - Шукаєте іменування версій і періодичність випусків
+summary: Лінії випуску, контрольний список оператора, середовища перевірки, іменування версій і періодичність
+title: Політика релізів
 x-i18n:
-    generated_at: "2026-05-02T17:33:47Z"
+    generated_at: "2026-05-02T18:57:49Z"
     model: gpt-5.5
     provider: openai
-    source_hash: d58ea2416a3c1e129e5167c20b1c8c55eca581c9f811efee5722b5dfd336a85d
+    source_hash: 18cee58dcad91e24c0d76622a9ed1568f93e4e2c51deae9ad06ccc7feb831d3a
     source_path: reference/RELEASING.md
     workflow: 16
 ---
 
-OpenClaw має чотири публічні гілки випусків:
+OpenClaw має чотири публічні канали релізів:
 
-- стабільна: теговані випуски, які за замовчуванням публікуються до npm `beta`, або до npm `latest`, коли це явно запитано
-- альфа: передвипускні теги, які публікуються до npm `alpha`
-- бета: передвипускні теги, які публікуються до npm `beta`
-- розробницька: рухома верхівка `main`
+- stable: позначені тегами релізи, які типово публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
+- alpha: prerelease-теги, які публікуються в npm `alpha`
+- beta: prerelease-теги, які публікуються в npm `beta`
+- dev: рухома вершина `main`
 
 ## Іменування версій
 
-- Версія стабільного випуску: `YYYY.M.D`
+- Версія стабільного релізу: `YYYY.M.D`
   - Git-тег: `vYYYY.M.D`
-- Версія стабільного коригувального випуску: `YYYY.M.D-N`
+- Версія коригувального стабільного релізу: `YYYY.M.D-N`
   - Git-тег: `vYYYY.M.D-N`
-- Версія альфа-передвипуску: `YYYY.M.D-alpha.N`
+- Версія alpha prerelease: `YYYY.M.D-alpha.N`
   - Git-тег: `vYYYY.M.D-alpha.N`
-- Версія бета-передвипуску: `YYYY.M.D-beta.N`
+- Версія beta prerelease: `YYYY.M.D-beta.N`
   - Git-тег: `vYYYY.M.D-beta.N`
 - Не доповнюйте місяць або день нулями
-- `latest` означає поточний просунутий стабільний випуск npm
+- `latest` означає поточний просунутий стабільний npm-реліз
 - `alpha` означає поточну ціль встановлення alpha
 - `beta` означає поточну ціль встановлення beta
-- Стабільні та стабільні коригувальні випуски за замовчуванням публікуються до npm `beta`; оператори випуску можуть явно вказати ціль `latest` або пізніше просунути перевірену beta-збірку
-- Кожен стабільний випуск OpenClaw постачається разом із npm-пакетом і застосунком macOS;
-  beta-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а
-  збирання/підписування/нотаризацію застосунку macOS залишають для стабільного випуску, якщо це не запитано явно
+- Стабільні та коригувальні стабільні релізи типово публікуються в npm `beta`; оператори релізу можуть явно вибрати `latest` або пізніше просунути перевірену beta-збірку
+- Кожен стабільний реліз OpenClaw постачає npm-пакет і застосунок macOS разом;
+  beta-релізи зазвичай спершу перевіряють і публікують шлях npm/package, а
+  збірку/підпис/нотаризацію застосунку mac залишають для stable, якщо це явно не запитано
 
-## Періодичність випусків
+## Частота релізів
 
-- Випуски рухаються спочатку через beta
-- Стабільний випуск виходить лише після перевірки останньої beta
-- Супровідники зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної
-  з поточного `main`, щоб перевірка випуску та виправлення не блокували нову
+- Релізи рухаються спершу через beta
+- Stable виходить лише після перевірки останньої beta
+- Мейнтейнери зазвичай створюють релізи з гілки `release/YYYY.M.D`, створеної
+  з поточної `main`, щоб перевірка релізу й виправлення не блокували нову
   розробку в `main`
-- Якщо beta-тег уже надіслано або опубліковано й він потребує виправлення, супровідники створюють
+- Якщо beta-тег уже надіслано або опубліковано й потрібне виправлення, мейнтейнери створюють
   наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега
-- Докладна процедура випуску, затвердження, облікові дані та нотатки щодо відновлення
-  доступні лише супровідникам
+- Детальна процедура релізу, затвердження, облікові дані та нотатки з відновлення
+  доступні лише мейнтейнерам
 
-## Контрольний список оператора випуску
+## Чекліст оператора релізу
 
-Цей контрольний список описує публічну форму процесу випуску. Приватні облікові дані,
-підписування, нотаризація, відновлення dist-tag і деталі екстреного відкату залишаються в
-інструкції з випусків, доступній лише супровідникам.
+Цей чекліст описує публічну форму процесу релізу. Приватні облікові дані,
+підписування, нотаризація, відновлення dist-tag і деталі аварійного відкату залишаються в
+runbook релізу лише для мейнтейнерів.
 
-1. Почніть із поточного `main`: підтягніть останні зміни, підтвердьте, що цільовий коміт надіслано,
-   і переконайтеся, що поточний CI для `main` достатньо зелений, щоб створити від нього гілку.
-2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії комітів за допомогою
-   `/changelog`, залиште записи орієнтованими на користувача, закомітьте його, надішліть його та ще раз виконайте rebase/pull
-   перед створенням гілки.
-3. Перегляньте записи сумісності випуску в
+1. Почніть із поточної `main`: отримайте найновіші зміни, підтвердьте, що цільовий коміт надіслано,
+   і підтвердьте, що поточний CI `main` достатньо зелений, щоб створювати від нього гілку.
+2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою
+   `/changelog`, залиште записи орієнтованими на користувачів, закомітьте його, надішліть і виконайте rebase/pull
+   ще раз перед створенням гілки.
+3. Перегляньте записи сумісності релізу в
    `src/plugins/compat/registry.ts` і
-   `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену
-   сумісність лише тоді, коли шлях оновлення лишається покритим, або зафіксуйте, чому її
+   `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте застарілу
+   сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому її
    навмисно збережено.
-4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском
+4. Створіть `release/YYYY.M.D` з поточної `main`; не виконуйте звичайну релізну роботу
    безпосередньо в `main`.
-5. Оновіть кожне потрібне місце з версією для запланованого тега, запустіть
-   `pnpm plugins:sync`, щоб публіковані пакети Plugin мали спільну версію випуску
-   та метадані сумісності, потім запустіть локальну детерміновану попередню перевірку:
+5. Підніміть версію в кожному потрібному місці для запланованого тега, запустіть
+   `pnpm plugins:sync`, щоб публіковні пакети Plugin мали спільну версію релізу
+   й метадані сумісності, потім запустіть локальний детермінований preflight:
    `pnpm check:test-types`, `pnpm check:architecture`,
    `pnpm build && pnpm ui:build`, `pnpm plugins:sync:check` і
    `pnpm release:check`.
-6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тега
-   для попередньої перевірки лише з метою валідації дозволено повний 40-символьний SHA гілки випуску.
+6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. Поки тега немає,
+   повний 40-символьний SHA гілки релізу дозволений для preflight лише з метою перевірки.
    Збережіть успішний `preflight_run_id`.
-7. Запустіть усі передрелізні тести через `Full Release Validation` для
-   гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу
-   для чотирьох великих тестових середовищ випуску: Vitest, Docker, QA Lab і Package.
-8. Якщо перевірка не пройшла, виправте в гілці випуску та перезапустіть найменший невдалий
-   файл, лінію, завдання workflow, профіль пакета, провайдер або allowlist моделі, який
+7. Запустіть усі pre-release тести через `Full Release Validation` для
+   гілки релізу, тега або повного SHA коміту. Це єдина ручна точка входу
+   для чотирьох великих релізних тестових наборів: Vitest, Docker, QA Lab і Package.
+8. Якщо перевірка не проходить, виправте це в гілці релізу й повторно запустіть найменший невдалий
+   файл, канал, workflow job, профіль пакета, провайдера або allowlist моделі, який
    доводить виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня робить
    попередні докази застарілими.
 9. Для alpha або beta позначте `vYYYY.M.D-alpha.N` або `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з
    відповідної гілки `release/YYYY.M.D`. Він перевіряє `pnpm plugins:sync:check`,
-   спочатку публікує всі публіковані пакети Plugin до npm, потім публікує той самий
-   набір до ClawHub, а тоді просуває підготовлений артефакт попередньої перевірки npm OpenClaw
-   з відповідним dist-tag. Після публікації запустіть післяпублікаційну перевірку прийнятності пакета
-   для опублікованого пакета `openclaw@YYYY.M.D-alpha.N`, `openclaw@alpha`,
+   спершу публікує всі публіковні пакети Plugin в npm, другим кроком публікує той самий
+   набір у ClawHub, а потім просуває підготовлений preflight-артефакт OpenClaw npm
+   з відповідним dist-tag. Після публікації запустіть post-publish package
+   acceptance для опублікованого пакета `openclaw@YYYY.M.D-alpha.N`, `openclaw@alpha`,
    `openclaw@YYYY.M.D-beta.N` або `openclaw@beta`. Якщо надісланий або
-   опублікований передвипуск потребує виправлення, створіть наступний відповідний номер передвипуску;
-   не видаляйте й не переписуйте старий передвипуск.
-10. Для стабільного випуску продовжуйте лише після того, як перевірена beta або кандидат у випуск матиме
-    потрібні докази валідації. Публікація стабільного npm також проходить через
-    `OpenClaw Release Publish`, повторно використовуючи успішний артефакт попередньої перевірки через
-    `preflight_run_id`; готовність стабільного випуску macOS також вимагає
+   опублікований prerelease потребує виправлення, створіть наступний відповідний номер prerelease;
+   не видаляйте й не переписуйте старий prerelease.
+10. Для stable продовжуйте лише після того, як перевірена beta або release candidate має
+    потрібні докази перевірки. Публікація stable в npm також проходить через
+    `OpenClaw Release Publish`, повторно використовуючи успішний preflight-артефакт через
+    `preflight_run_id`; готовність stable-релізу macOS також потребує
     упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`.
-11. Після публікації запустіть npm-перевірку після публікації, необов’язковий автономний
-    E2E опублікованого npm для Telegram, коли потрібне післяпублікаційне підтвердження каналу,
+11. Після публікації запустіть npm post-publish verifier, необов'язковий standalone
+    published-npm Telegram E2E, коли потрібен post-publish доказ каналу,
     просування dist-tag за потреби, нотатки GitHub release/prerelease з
-    повного відповідного розділу `CHANGELOG.md` і кроки оголошення
-    випуску.
+    повного відповідного розділу `CHANGELOG.md` і кроки оголошення релізу.
 
-## Попередня перевірка випуску
+## Release preflight
 
-- Запустіть `pnpm check:test-types` перед попередньою перевіркою релізу, щоб тестовий TypeScript залишався
+- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався
   покритим поза швидшим локальним шлюзом `pnpm check`
-- Запустіть `pnpm check:architecture` перед попередньою перевіркою релізу, щоб ширші перевірки циклів
-  імпортів і архітектурних меж були успішними поза швидшим локальним шлюзом
+- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів
+  імпорту та меж архітектури були зеленими поза швидшим локальним шлюзом
 - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
-  релізні артефакти `dist/*` і збірка Control UI існували для кроку
-  перевірки пакування
-- Запустіть `pnpm plugins:sync` після підвищення кореневої версії та перед тегуванням. Він
-  оновлює версії пакетів публіковних plugin, метадані сумісності
-  OpenClaw peer/API, метадані збірки та заготовки журналів змін plugin відповідно до версії
-  релізу core. `pnpm plugins:sync:check` є немодифікувальним релізним запобіжником;
-  publish workflow завершується помилкою до будь-якої зміни реєстру, якщо цей крок було
+  релізні артефакти `dist/*` і бандл Control UI існували для кроку перевірки
+  пакування
+- Запустіть `pnpm plugins:sync` після підвищення версії в корені й перед створенням тега. Він
+  оновлює версії пакетів публіковних Plugin, метадані сумісності з OpenClaw peer/API,
+  метадані збірки та заготовки журналів змін Plugin, щоб вони відповідали версії
+  релізу ядра. `pnpm plugins:sync:check` — це немутуючий релізний запобіжник;
+  workflow публікації завершується з помилкою перед будь-якою зміною реєстру, якщо цей крок було
   забуто.
-- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб
+- Запустіть ручний workflow `Full Release Validation` перед затвердженням релізу, щоб
   запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку,
-  тег або повний SHA коміту, запускає ручний `CI` і запускає
-  `OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker
-  release-path, live/E2E, OpenWebUI, parity QA Lab, Matrix і Telegram
+  тег або повний SHA коміту, диспетчеризує ручний `CI` і диспетчеризує
+  `OpenClaw Release Checks` для install smoke, package acceptance, Docker
+  release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram
   lanes. З `release_profile=full` і `rerun_group=all` він також запускає package
   Telegram E2E проти артефакту `release-package-under-test` із release
-  checks. Укажіть `npm_telegram_package_spec` після публікації, коли той самий
-  Telegram E2E також має підтвердити опублікований пакет npm. Укажіть
-  `evidence_package_spec`, коли приватний evidence report має підтвердити, що
-  валідація відповідає опублікованому пакету npm без примусового Telegram E2E.
+  checks. Надайте `npm_telegram_package_spec` після публікації, коли той самий
+  Telegram E2E має також підтвердити опублікований npm-пакет. Надайте
+  `package_acceptance_package_spec` після публікації, коли Package Acceptance
+  має запускати свою матрицю package/update проти відвантаженого npm-пакета замість
+  артефакту, зібраного з SHA. Надайте
+  `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що
+  валідація відповідає опублікованому npm-пакету без примусового Telegram E2E.
   Приклад:
   `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
-- Запустіть ручний workflow `Package Acceptance`, коли потрібне side-channel підтвердження
+- Запустіть ручний workflow `Package Acceptance`, коли потрібен доказ через побічний канал
   для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для
-  `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`
-  щоб запакувати довірену гілку/тег/SHA `package_ref` із поточним
-  harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим
-  SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub
-  Actions. Workflow розв’язує кандидата до
+  `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`,
+  щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним
+  harness `workflow_ref`; `source=url` для HTTPS-тарболу з обов’язковим
+  SHA-256; або `source=artifact` для тарболу, завантаженого іншим запуском GitHub
+  Actions. Workflow розв’язує кандидата в
   `package-under-test`, повторно використовує Docker E2E release scheduler проти цього
-  tarball і може запускати Telegram QA проти того самого tarball з
-  `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані
-  Docker lanes містять `published-upgrade-survivor`, артефакт пакета є кандидатом, а
-  `published_upgrade_survivor_baseline` вибирає опублікований baseline.
+  тарболу й може запускати Telegram QA проти того самого тарболу з
+  `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли
+  вибрані Docker lanes містять `published-upgrade-survivor`, артефакт пакета
+  є кандидатом, а `published_upgrade_survivor_baseline` вибирає опублікований baseline.
   Приклад: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai`
   Поширені профілі:
-  - `smoke`: lanes встановлення/channel/agent, gateway network і перезавантаження config
-  - `package`: package/update/plugin lanes, нативні для артефакту, без OpenWebUI або live ClawHub
-  - `product`: профіль package плюс MCP channels, cron/subagent cleanup,
-    OpenAI web search і OpenWebUI
-  - `full`: фрагменти Docker release-path з OpenWebUI
+  - `smoke`: lanes для install/channel/agent, мережі Gateway і перезавантаження конфігурації
+  - `package`: artifact-native lanes для package/update/plugin без OpenWebUI або live ClawHub
+  - `product`: профіль package плюс MCP-канали, очищення cron/subagent,
+    вебпошук OpenAI і OpenWebUI
+  - `full`: Docker release-path chunks з OpenWebUI
   - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску
 - Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI
-  для кандидата релізу. Ручні CI dispatches обходять changed
+  для релізного кандидата. Ручні dispatch CI оминають changed
   scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel
-  contracts, сумісність Node 22, `check`, `check-additional`, build smoke,
-  docs checks, Python skills, Windows, macOS, Android і Control UI i18n
+  contracts, сумісність із Node 22, `check`, `check-additional`, build smoke,
+  перевірки документації, Python skills, Windows, macOS, Android і Control UI i18n
   lanes.
   Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D`
-- Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Він проганяє
+- Запустіть `pnpm qa:otel:smoke`, коли перевіряєте релізну телеметрію. Він проганяє
   QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace
   span, обмежені атрибути та редагування вмісту/ідентифікаторів без
   потреби в Opik, Langfuse або іншому зовнішньому collector.
-- Запускайте `pnpm release:check` перед кожним тегованим релізом
-- Запустіть `OpenClaw Release Publish` для послідовності модифікувальної публікації після того, як
-  тег існує. Dispatch виконуйте з `release/YYYY.M.D` (або `main`, коли публікуєте
-  тег, досяжний з main), передайте release tag і успішний OpenClaw npm
-  `preflight_run_id`, і залишайте стандартний scope публікації plugin
-  `all-publishable`, якщо ви навмисно не запускаєте сфокусований repair. Workflow
-  серіалізує plugin npm publish, plugin ClawHub publish і OpenClaw
-  npm publish, щоб core package не було опубліковано перед його externalized
-  plugins.
-- Release checks тепер виконуються в окремому ручному workflow:
+- Запускайте `pnpm release:check` перед кожним релізом із тегом
+- Запустіть `OpenClaw Release Publish` для мутуючої послідовності публікації після того, як
+  тег існує. Dispatch його з `release/YYYY.M.D` (або `main`, коли публікуєте
+  тег, досяжний із main), передайте релізний тег і успішний OpenClaw npm
+  `preflight_run_id`, і залишайте типовий scope публікації Plugin
+  `all-publishable`, якщо тільки ви навмисно не запускаєте сфокусоване виправлення. Workflow
+  серіалізує npm-публікацію Plugin, публікацію Plugin у ClawHub і npm-публікацію OpenClaw,
+  щоб core package не було опубліковано перед його зовнішніми
+  Plugin.
+- Release checks тепер запускаються в окремому ручному workflow:
   `OpenClaw Release Checks`
-- `OpenClaw Release Checks` також запускає QA Lab mock parity gate плюс швидкий
-  live Matrix profile і Telegram QA lane перед схваленням релізу. Live
-  lanes використовують середовище `qa-live-shared`; Telegram також використовує Convex CI
-  credential leases. Запустіть ручний workflow `QA-Lab - All Lanes` з
+- `OpenClaw Release Checks` також запускає шлюз QA Lab mock parity плюс швидкий
+  live Matrix profile і Telegram QA lane перед затвердженням релізу. Live
+  lanes використовують середовище `qa-live-shared`; Telegram також використовує leases облікових даних Convex CI.
+  Запустіть ручний workflow `QA-Lab - All Lanes` з
   `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix
   transport, media та E2EE паралельно.
 - Cross-OS install і upgrade runtime validation є частиною публічних
-  `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають
+  `OpenClaw Release Checks` і `Full Release Validation`, які викликають
   reusable workflow
-  `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
-- Цей поділ навмисний: тримати реальний шлях npm release коротким,
-  детермінованим і сфокусованим на артефактах, тоді як повільніші live checks залишаються у власному
-  lane, щоб вони не затримували й не блокували publish
-- Secret-bearing release checks слід dispatch через `Full Release
-Validation` або з `main`/release workflow ref, щоб логіка workflow і
-  secrets залишалися контрольованими
+  `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` напряму
+- Це розділення навмисне: тримайте справжній npm release path коротким,
+  детермінованим і сфокусованим на артефактах, тоді як повільніші live checks залишаються у своїй
+  окремій lane, щоб вони не затримували й не блокували публікацію
+- Release checks, що містять секрети, слід dispatch через `Full Release
+Validation` або з workflow ref `main`/release, щоб логіка workflow і
+  секрети залишалися контрольованими
 - `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, доки
-  розв’язаний коміт досяжний з гілки OpenClaw або release tag
-- Validation-only preflight `OpenClaw NPM Release` також приймає поточний
-  повний 40-символьний SHA коміту workflow-branch без потреби в pushed tag
-- Цей шлях SHA призначений лише для валідації й не може бути promoted у реальний publish
+  розв’язаний коміт досяжний із гілки OpenClaw або релізного тега
+- validation-only preflight `OpenClaw NPM Release` також приймає поточний
+  повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тега
+- Цей шлях SHA призначений лише для валідації й не може бути просунутий у справжню публікацію
 - У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки
-  метаданих пакета; реальний publish усе ще потребує справжнього release tag
-- Обидва workflows зберігають реальний шлях publish і promotion на GitHub-hosted
-  runners, тоді як немодифікувальний шлях валідації може використовувати більші
+  метаданих пакета; справжня публікація все одно потребує справжнього релізного тега
+- Обидва workflow залишають справжній шлях публікації та promotion на GitHub-hosted
+  runners, тоді як немутуючий шлях валідації може використовувати більші
   Blacksmith Linux runners
 - Цей workflow запускає
   `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
-  з використанням обох workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
-- npm release preflight більше не чекає на окремий release checks lane
+  із використанням обох workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
+- npm release preflight більше не чекає на окрему lane release checks
 - Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
-  (або відповідний beta/correction tag) перед схваленням
+  (або відповідний beta/correction tag) перед затвердженням
 - Після npm publish запустіть
   `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  (або відповідну beta/correction version), щоб перевірити опублікований registry
-  install path у свіжому тимчасовому prefix
+  (або відповідну beta/correction version), щоб перевірити опублікований шлях встановлення з реєстру
+  у свіжому тимчасовому префіксі
 - Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`
-  щоб перевірити installed-package onboarding, налаштування Telegram і реальний Telegram E2E
-  проти опублікованого npm package з використанням спільного пулу leased Telegram credential.
-  Локальні разові запуски maintainers можуть пропустити Convex vars і передати три
+  щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E
+  проти опублікованого npm-пакета з використанням спільного leased Telegram credential
+  pool. Разові локальні запуски maintainer можуть опустити Convex vars і передати три
   env credentials `OPENCLAW_QA_TELEGRAM_*` напряму.
-- Maintainers можуть запускати ту саму post-publish check з GitHub Actions через
+- Maintainers можуть запускати ту саму post-publish check із GitHub Actions через
   ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
-  не запускається на кожному merge.
+  не запускається під час кожного merge.
 - Maintainer release automation тепер використовує preflight-then-promote:
-  - реальний npm publish має пройти успішний npm `preflight_run_id`
-  - реальний npm publish має бути dispatched з тієї самої гілки `main` або
+  - справжній npm publish має пройти успішний npm `preflight_run_id`
+  - справжній npm publish має бути dispatch з тієї самої гілки `main` або
     `release/YYYY.M.D`, що й успішний preflight run
-  - stable npm releases за замовчуванням спрямовуються до `beta`
+  - stable npm releases типово використовують `beta`
   - stable npm publish може явно таргетувати `latest` через workflow input
   - token-based npm dist-tag mutation тепер живе в
     `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
     з міркувань безпеки, бо `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як
     публічний repo зберігає OIDC-only publish
-  - публічний `macOS Release` є validation-only; коли тег існує лише на
-    release branch, але workflow dispatched з `main`, задайте
+  - публічний `macOS Release` призначений лише для валідації; коли тег існує лише в
+    release branch, але workflow dispatch з `main`, задайте
     `public_release_branch=release/YYYY.M.D`
-  - реальний private mac publish має пройти успішний private mac
+  - справжній private mac publish має пройти успішні private mac
     `preflight_run_id` і `validate_run_id`
-  - реальні publish paths promote підготовлені артефакти замість повторної
-    їхньої перебудови
-- Для stable correction releases на кшталт `YYYY.M.D-N`, post-publish verifier
+  - справжні publish paths просувають підготовлені артефакти замість повторної
+    їх збірки
+- Для stable correction releases на кшталт `YYYY.M.D-N` post-publish verifier
   також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`,
-  щоб release corrections не могли непомітно залишити старіші global installs на
+  щоб release corrections не могли непомітно залишити старіші глобальні встановлення на
   базовому stable payload
-- npm release preflight fails closed, якщо tarball не містить обидва
-  `dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`,
-  щоб ми знову не відправили порожній browser dashboard
-- Post-publish verification також перевіряє, що entrypoints опублікованих plugin і
-  package metadata присутні в установленому registry layout. Реліз, який
-  постачає відсутні plugin runtime payloads, провалює postpublish verifier і
-  не може бути promoted до `latest`.
-- `pnpm test:install:smoke` також застосовує бюджет npm pack `unpackedSize` до
-  candidate update tarball, щоб installer e2e ловив випадкове pack bloat
-  до release publish path
+- npm release preflight fail closed, якщо тарбол не містить і
+  `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`,
+  щоб ми знову не відвантажили порожню браузерну dashboard
+- Post-publish verification також перевіряє, що опубліковані entrypoints Plugin і
+  метадані пакета присутні в установленому layout реєстру. Реліз, який
+  відвантажує відсутні runtime payloads Plugin, провалює postpublish verifier і
+  не може бути просунутий до `latest`.
+- `pnpm test:install:smoke` також забезпечує бюджет npm pack `unpackedSize` для
+  candidate update tarball, тож installer e2e ловить випадкове роздуття пакета
+  перед release publish path
 - Якщо релізна робота торкалася CI planning, extension timing manifests або
-  extension test matrices, згенеруйте заново й перегляньте planner-owned
+  extension test matrices, регенеруйте та перегляньте planner-owned
   matrix outputs `plugin-prerelease-extension-shard` з
-  `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не
+  `.github/workflows/plugin-prerelease.yml` перед затвердженням, щоб release notes не
   описували застарілий CI layout
 - Готовність stable macOS release також включає updater surfaces:
-  - GitHub release має в підсумку містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
-  - `appcast.xml` на `main` має вказувати на новий stable zip після publish
-  - запакований app має зберігати non-debug bundle id, непорожній Sparkle feed
-    URL і `CFBundleVersion` на рівні або вище canonical Sparkle build floor
-    для цієї release version
+  - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
+  - `appcast.xml` у `main` має вказувати на новий stable zip після publish
+  - запакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed
+    URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor
+    для цієї релізної версії
 
 ## Релізні тестові бокси
 
-`Full Release Validation` — це спосіб, у який operators запускають усі передрелізні тести з
-однієї точки входу. Для pinned commit proof на швидкозмінній гілці використовуйте
+`Full Release Validation` — це спосіб, яким operators запускають усі передрелізні тести з
+однієї точки входу. Для доказу pinned commit на швидкозмінній гілці використовуйте
 helper, щоб кожен child workflow запускався з тимчасової гілки, зафіксованої на target
 SHA:
 
@@ -274,10 +276,10 @@ SHA:
 pnpm ci:full-release --sha <full-sha>
 ```
 
-Helper пушить `release-ci/<sha>-...`, запускає `Full Release Validation`
-з цієї гілки з `ref=<sha>`, перевіряє, що `headSha` кожного child workflow
-збігається з target, а потім видаляє тимчасову гілку. Це уникає випадкового підтвердження
-новішого child run з `main`.
+Helper пушить `release-ci/<sha>-...`, dispatch `Full Release Validation`
+з цієї гілки з `ref=<sha>`, перевіряє, що кожен child workflow `headSha`
+відповідає target, а потім видаляє тимчасову гілку. Це запобігає випадковому
+доведенню новішого child run `main`.
 
 Для валідації release branch або tag запускайте його з довіреного workflow
 ref `main` і передавайте release branch або tag як `ref`:
@@ -292,46 +294,45 @@ gh workflow run full-release-validation.yml \
   -f evidence_package_spec=openclaw@YYYY.M.D-beta.N
 ```
 
-Робочий процес визначає цільовий ref, запускає ручний `CI` з
+Робочий процес визначає цільовий ref, запускає вручну `CI` з
 `target_ref=<release-ref>`, запускає `OpenClaw Release Checks` і запускає
-окремий package Telegram E2E, коли `release_profile=full` з
-`rerun_group=all` або коли задано `npm_telegram_package_spec`. Далі `OpenClaw Release
-Checks` розгортається на install smoke, cross-OS release checks, live/E2E Docker
-release-path покриття, Package Acceptance з Telegram package QA, QA Lab
-parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли
-зведення `Full Release Validation`
-показує `normal_ci` і `release_checks` як успішні. У режимі full/all
-дочірній `npm_telegram` також має бути успішним; поза full/all його пропущено,
-якщо не було надано опублікований `npm_telegram_package_spec`. Фінальне
-зведення верифікатора містить таблиці найповільніших завдань для кожного
-дочірнього запуску, щоб менеджер релізу бачив поточний критичний шлях без
-завантаження логів.
-Див. [Повна валідація релізу](/uk/reference/full-release-validation) для
-повної матриці етапів, точних назв завдань workflow, відмінностей між stable і full профілями,
-артефактів і цільових механізмів повторного запуску.
-Дочірні workflow запускаються з довіреного ref, який запускає `Full Release
-Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на
-старішу релізну гілку або тег. Окремого входу Full Release Validation
-workflow-ref немає; вибирайте довірений harness, вибираючи ref запуску workflow.
-Не використовуйте `--ref main -f ref=<sha>` для доказу точного коміту на рухомій `main`;
-raw commit SHA не можуть бути workflow dispatch refs, тому використовуйте
+окремий Telegram E2E для пакета, коли `release_profile=full` з
+`rerun_group=all` або коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release
+Checks` розгалужується на install smoke, крос-ОС перевірки релізу, live/E2E Docker
+покриття release-path, Package Acceptance з Telegram package QA, паритет QA Lab,
+live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли у зведенні
+`Full Release Validation`
+показано успішні `normal_ci` і `release_checks`. У режимі full/all дочірній
+`npm_telegram` також має бути успішним; поза full/all його пропускають, якщо не
+було надано опублікований `npm_telegram_package_spec`. Підсумкове зведення
+верифікатора містить таблиці найповільніших завдань для кожного дочірнього запуску,
+щоб менеджер релізу міг бачити поточний критичний шлях без завантаження логів.
+Див. [Повна валідація релізу](/uk/reference/full-release-validation) для повної
+матриці етапів, точних назв завдань workflow, відмінностей між профілями stable і full,
+артефактів і дескрипторів для сфокусованих повторних запусків.
+Дочірні workflow запускаються з довіреного ref, який виконує `Full Release
+Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на старішу
+релізну гілку або тег. Окремого вхідного параметра workflow-ref для Full Release Validation
+немає; вибирайте довірений harness, вибираючи ref запуску workflow.
+Не використовуйте `--ref main -f ref=<sha>` для доказу точного коміту на рухомому `main`;
+сирі SHA комітів не можуть бути ref для workflow dispatch, тому використовуйте
 `pnpm ci:full-release --sha <sha>`, щоб створити закріплену тимчасову гілку.
 
 Використовуйте `release_profile`, щоб вибрати ширину live/provider:
 
-- `minimum`: найшвидший release-critical OpenAI/core live і Docker path
-- `stable`: minimum плюс stable provider/backend покриття для затвердження релізу
-- `full`: stable плюс broad advisory provider/media покриття
+- `minimum`: найшвидший критичний для релізу OpenAI/core live і Docker path
+- `stable`: minimum плюс stable provider/backend покриття для схвалення релізу
+- `full`: stable плюс широке консультативне покриття provider/media
 
-`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз
-визначити цільовий ref як `release-package-under-test`, і повторно використовує
-цей артефакт як у release-path Docker перевірках, так і в Package Acceptance.
-Це утримує всі package-facing boxes на тих самих байтах і уникає повторних збірок пакета.
-Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли
-задано repo/org змінну, інакше `openai/gpt-5.4`, бо ця lane доводить
-встановлення пакета, onboarding, запуск Gateway і один live agent turn,
+`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз визначити цільовий
+ref як `release-package-under-test`, і повторно використовує цей артефакт як у
+release-path Docker перевірках, так і в Package Acceptance. Це утримує всі
+package-facing boxes на тих самих байтах і уникає повторних збірок пакета.
+Крос-ОС OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли задано
+змінну repo/org, інакше `openai/gpt-5.4`, оскільки ця lane
+доводить встановлення пакета, onboarding, запуск Gateway і один live agent turn,
 а не бенчмарк найповільнішої моделі за замовчуванням. Ширша live provider
-matrix лишається місцем для model-specific покриття.
+матриця лишається місцем для покриття, специфічного для моделей.
 
 Використовуйте ці варіанти залежно від етапу релізу:
 
@@ -363,40 +364,40 @@ gh workflow run full-release-validation.yml \
   -f npm_telegram_provider_mode=mock-openai
 ```
 
-Не використовуйте повну парасольку як перший повторний запуск після цільового виправлення. Якщо один box
-падає, використовуйте failed child workflow, job, Docker lane, package profile, model
-provider або QA lane для наступного доказу. Запускайте повну парасольку знову лише тоді,
-коли виправлення змінило спільну release orchestration або зробило попередній all-box доказ
-застарілим. Фінальний верифікатор парасольки повторно перевіряє записані child workflow run
-ids, тому після успішного повторного запуску дочірнього workflow повторно запускайте лише невдале
+Не використовуйте повний umbrella як перший повторний запуск після сфокусованого виправлення. Якщо один box
+завершився невдало, використовуйте невдалий дочірній workflow, завдання, Docker lane, package profile, model
+provider або QA lane для наступного доказу. Запускайте повний umbrella знову лише тоді, коли
+виправлення змінило спільну оркестрацію релізу або зробило попередні all-box докази
+застарілими. Підсумковий верифікатор umbrella повторно перевіряє записані ids запусків дочірніх workflow,
+тому після успішного повторного запуску дочірнього workflow повторно запускайте лише невдале
 батьківське завдання `Verify full validation`.
 
-Для обмеженого відновлення передайте `rerun_group` до парасольки. `all` — це реальний
-запуск release-candidate, `ci` запускає лише нормальний дочірній CI, `plugin-prerelease`
-запускає лише release-only plugin child, `release-checks` запускає кожен release
-box, а вужчі release groups — `install-smoke`, `cross-os`,
+Для обмеженого відновлення передайте `rerun_group` в umbrella. `all` — це справжній
+запуск release-candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease`
+запускає лише дочірній plugin для релізу, `release-checks` запускає кожен release
+box, а вужчі release groups — це `install-smoke`, `cross-os`,
 `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`.
-Цільові повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; full/all запуски
-з `release_profile=full` використовують release-checks package artifact.
+Сфокусовані повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; full/all запуски
+з `release_profile=full` використовують артефакт пакета release-checks.
 
 ### Vitest
 
-Vitest box — це ручний дочірній workflow `CI`. Manual CI навмисно
-обходить changed scoping і примусово запускає нормальний test graph для release
+Vitest box — це дочірній workflow ручного `CI`. Ручний CI навмисно
+оминає changed scoping і примусово запускає звичайний тестовий граф для release
 candidate: Linux Node shards, bundled-plugin shards, channel contracts, Node 22
 compatibility, `check`, `check-additional`, build smoke, docs checks, Python
 skills, Windows, macOS, Android і Control UI i18n.
 
-Використовуйте цей box, щоб відповісти на запитання: "чи пройшло дерево джерел повний нормальний набір тестів?"
-Це не те саме, що release-path product validation. Докази, які слід зберігати:
+Використовуйте цей box, щоб відповісти: "чи пройшло дерево вихідного коду повний звичайний тестовий набір?"
+Це не те саме, що release-path product validation. Докази, які варто зберегти:
 
-- зведення `Full Release Validation`, що показує URL запущеного `CI` run
-- `CI` run зелений на точному target SHA
+- зведення `Full Release Validation`, яке показує URL запущеного `CI`
+- зелений запуск `CI` на точному цільовому SHA
 - назви невдалих або повільних shard із CI jobs під час розслідування регресій
-- артефакти таймінгу Vitest, такі як `.artifacts/vitest-shard-timings.json`, коли
+- артефакти таймінгів Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли
   запуск потребує аналізу продуктивності
 
-Запускайте manual CI напряму лише тоді, коли реліз потребує детермінованого normal CI, але
+Запускайте ручний CI напряму лише тоді, коли реліз потребує детермінованого звичайного CI, але
 не Docker, QA Lab, live, cross-OS або package boxes:
 
 ```bash
@@ -405,16 +406,16 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
 
 ### Docker
 
-Docker box живе в `OpenClaw Release Checks` через
+Docker box міститься в `OpenClaw Release Checks` через
 `openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode
-workflow `install-smoke`. Він валідує release candidate через упаковані
-Docker середовища, а не лише source-level tests.
+workflow `install-smoke`. Він валідує release candidate через packaged
+Docker environments, а не лише через source-level tests.
 
 Release Docker coverage включає:
 
 - повний install smoke з увімкненим повільним Bun global install smoke
-- підготовку/повторне використання root Dockerfile smoke image за target SHA, з QR,
-  root/gateway і installer/Bun smoke jobs як окремими install-smoke
+- підготовку/повторне використання root Dockerfile smoke image за цільовим SHA, із QR,
+  root/gateway та installer/Bun smoke jobs, що працюють як окремі install-smoke
   shards
 - repository E2E lanes
 - release-path Docker chunks: `core`, `package-update-openai`,
@@ -426,85 +427,88 @@ Release Docker coverage включає:
   `plugins-runtime-install-g` і `plugins-runtime-install-h`
 - OpenWebUI coverage всередині chunk `plugins-runtime-services`, коли запитано
 - розділені bundled plugin install/uninstall lanes
-  `bundled-plugin-install-uninstall-0` до
+  `bundled-plugin-install-uninstall-0` through
   `bundled-plugin-install-uninstall-23`
 - live/E2E provider suites і Docker live model coverage, коли release checks
   включають live suites
 
-Використовуйте Docker artifacts перед повторним запуском. Release-path scheduler завантажує
+Використовуйте артефакти Docker перед повторним запуском. Release-path scheduler завантажує
 `.artifacts/docker-tests/` з lane logs, `summary.json`, `failures.json`,
-phase timings, scheduler plan JSON і rerun commands. Для цільового відновлення
-використовуйте `docker_lanes=<lane[,lane]>` на reusable live/E2E workflow замість
-повторного запуску всіх release chunks. Згенеровані команди повторного запуску включають попередні
-`package_artifact_run_id` і prepared Docker image inputs, коли доступні, тому
+phase timings, scheduler plan JSON і rerun commands. Для сфокусованого відновлення
+використовуйте `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow замість
+повторного запуску всіх release chunks. Згенеровані rerun commands включають попередні
+`package_artifact_run_id` і підготовлені Docker image inputs, коли доступно, тож
 невдала lane може повторно використати той самий tarball і GHCR images.
 
 ### QA Lab
 
-QA Lab box також є частиною `OpenClaw Release Checks`. Це agentic
-behavior і channel-level release gate, окремо від Vitest і Docker
-package mechanics.
+QA Lab box також є частиною `OpenClaw Release Checks`. Це агентний
+behavior і channel-level release gate, окремий від Vitest і механіки Docker
+package.
 
 Release QA Lab coverage включає:
 
-- mock parity gate, що порівнює OpenAI candidate lane з Opus 4.6
+- mock parity gate, що порівнює кандидатну OpenAI lane з Opus 4.6
   baseline за допомогою agentic parity pack
-- швидкий live Matrix QA profile із використанням середовища `qa-live-shared`
-- live Telegram QA lane із використанням Convex CI credential leases
+- швидкий live Matrix QA profile із середовищем `qa-live-shared`
+- live Telegram QA lane з Convex CI credential leases
 - `pnpm qa:otel:smoke`, коли release telemetry потребує явного локального доказу
 
-Використовуйте цей box, щоб відповісти на запитання: "чи реліз поводиться правильно в QA scenarios і
-live channel flows?" Зберігайте artifact URLs для parity, Matrix і Telegram
-lanes під час затвердження релізу. Full Matrix coverage лишається доступним як
-ручний sharded QA-Lab run, а не default release-critical lane.
+Використовуйте цей box, щоб відповісти: "чи реліз поводиться коректно в QA scenarios і
+live channel flows?" Зберігайте URL артефактів для parity, Matrix і Telegram
+lanes під час схвалення релізу. Повне Matrix coverage лишається доступним як
+ручний sharded QA-Lab run, а не як release-critical lane за замовчуванням.
 
-### Package
+### Пакет
 
-Package box — це installable-product gate. Він підтримується
+Package box — це gate installable-product. Він підтримується
 `Package Acceptance` і resolver
 `scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує
-candidate у tarball `package-under-test`, який споживає Docker E2E, валідує
-package inventory, записує package version і SHA-256, і тримає
+кандидата в tarball `package-under-test`, який споживає Docker E2E, валідує
+package inventory, записує package version і SHA-256 та тримає
 workflow harness ref окремо від package source ref.
 
-Підтримувані джерела candidate:
+Підтримувані джерела кандидатів:
 
-- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна OpenClaw release
-  version
-- `source=ref`: запакувати довірену `package_ref` branch, tag або full commit SHA
-  з вибраним `workflow_ref` harness
-- `source=url`: завантажити HTTPS `.tgz` з обов’язковим `package_sha256`
-- `source=artifact`: повторно використати `.tgz`, завантажений іншим GitHub Actions run
+- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна release
+  version OpenClaw
+- `source=ref`: пакує довірену гілку `package_ref`, тег або повний SHA коміту
+  з вибраним harness `workflow_ref`
+- `source=url`: завантажує HTTPS `.tgz` з обов'язковим `package_sha256`
+- `source=artifact`: повторно використовує `.tgz`, завантажений іншим запуском GitHub Actions
 
 `OpenClaw Release Checks` запускає Package Acceptance з `source=artifact`,
 підготовленим release package artifact, `suite_profile=custom`,
 `docker_lanes=doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update`,
-`published_upgrade_survivor_baselines=release-history`,
+`published_upgrade_survivor_baselines=all-since-2026.4.23`,
 `published_upgrade_survivor_scenarios=reported-issues` і
-`telegram_mode=mock-openai`. Package Acceptance тримає migration, update, stale
+`telegram_mode=mock-openai`. Package Acceptance утримує migration, update, stale
 plugin dependency cleanup, offline plugin fixtures, plugin update і Telegram
-package QA проти того самого resolved tarball. Це GitHub-native
-заміна для більшості package/update coverage, що раніше потребувало
-Parallels. Cross-OS release checks досі важливі для OS-specific onboarding,
+package QA на тому самому resolved tarball. Upgrade matrix покриває кожен stable npm-published baseline від `2026.4.23` до `latest`; використовуйте
+Package Acceptance з `source=npm` для вже відвантаженого кандидата або
+`source=ref`/`source=artifact` для SHA-backed local npm tarball перед
+публікацією. Це GitHub-native
+заміна більшості package/update coverage, яке раніше вимагало
+Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding,
 installer і platform behavior, але package/update product validation має
 надавати перевагу Package Acceptance.
 
-Канонічний checklist для update і plugin validation —
+Канонічний чеклист для update і plugin validation:
 [Тестування оновлень і plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли
 вирішуєте, яка local, Docker, Package Acceptance або release-check lane доводить
 plugin install/update, doctor cleanup або published-package migration change.
-Exhaustive published update migration з кожного stable пакета `2026.4.23+` —
-це окремий ручний workflow `Update Migration`, а не частина Full Release CI.
+Вичерпна published update migration з кожного stable пакета `2026.4.23+` — це
+окремий ручний workflow `Update Migration`, а не частина Full Release CI.
 
 Legacy package-acceptance leniency навмисно обмежена в часі. Пакети до
 `2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих
-до npm: private QA inventory entries, відсутні в tarball, відсутній
+у npm: private QA inventory entries, яких немає в tarball, відсутній
 `gateway install --wrapper`, відсутні patch files у tarball-derived git
-fixture, відсутній persisted `update.channel`, legacy plugin install-record
+fixture, відсутній збережений `update.channel`, legacy plugin install-record
 locations, відсутня marketplace install-record persistence і config metadata
 migration під час `plugins update`. Опублікований пакет `2026.4.26` може попереджати
-про local build metadata stamp files, які вже були shipped. Пізніші пакети
-мають відповідати сучасним package contracts; ті самі gaps провалюють release
+про local build metadata stamp files, які вже були відвантажені. Пізніші пакети
+мають задовольняти modern package contracts; ті самі gaps провалюють release
 validation.
 
 Використовуйте ширші Package Acceptance profiles, коли release question стосується
@@ -529,25 +533,25 @@ gh workflow run package-acceptance.yml \
 - `product`: `package` плюс MCP channels, cron/subagent cleanup, OpenAI web
   search і OpenWebUI
 - `full`: Docker release-path chunks з OpenWebUI
-- `custom`: точний список `docker_lanes` для цільових повторних запусків
+- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків
 
-Для перевірки пакета-кандидата Telegram увімкніть `telegram_mode=mock-openai` або
+Для підтвердження Telegram для пакета-кандидата увімкніть `telegram_mode=mock-openai` або
 `telegram_mode=live-frontier` у Package Acceptance. Workflow передає
 розв’язаний tarball `package-under-test` у lane Telegram; окремий
-workflow Telegram досі приймає опубліковану специфікацію npm для перевірок після публікації.
+workflow Telegram і надалі приймає опубліковану npm-специфікацію для перевірок після публікації.
 
-## Автоматизація публікації випуску
+## Автоматизація публікації релізу
 
 `OpenClaw Release Publish` є звичайною мутувальною точкою входу для публікації. Він
-оркеструє workflows довіреного публікатора в порядку, потрібному для випуску:
+оркеструє workflow trusted-publisher у порядку, потрібному релізу:
 
-1. Отримати тег випуску та визначити SHA його коміту.
-2. Перевірити, що тег досяжний з `main` або `release/*`.
+1. Взяти release tag і визначити його commit SHA.
+2. Перевірити, що tag досяжний з `main` або `release/*`.
 3. Запустити `pnpm plugins:sync:check`.
 4. Запустити `Plugin NPM Release` з `publish_scope=all-publishable` і
    `ref=<release-sha>`.
-5. Запустити `Plugin ClawHub Release` з тією самою областю та SHA.
-6. Запустити `OpenClaw NPM Release` з тегом випуску, npm dist-tag і
+5. Запустити `Plugin ClawHub Release` з тією самою областю й SHA.
+6. Запустити `OpenClaw NPM Release` з release tag, npm dist-tag і
    збереженим `preflight_run_id`.
 
 Приклад публікації beta:
@@ -590,92 +594,92 @@ gh workflow run openclaw-release-publish.yml \
   -f npm_dist_tag=latest
 ```
 
-Використовуйте нижчерівневі workflows `Plugin NPM Release` і `Plugin ClawHub Release`
-лише для сфокусованого ремонту або повторної публікації. Для ремонту вибраного plugin передайте
+Використовуйте нижчорівневі workflow `Plugin NPM Release` і `Plugin ClawHub Release`
+лише для цільового ремонту або повторної публікації. Для ремонту вибраного Plugin передайте
 `plugin_publish_scope=selected` і `plugins=@openclaw/name` до
-`OpenClaw Release Publish`, або запустіть дочірній workflow напряму, коли
-пакет OpenClaw не має публікуватися.
+`OpenClaw Release Publish`, або запускайте дочірній workflow безпосередньо, коли
+пакет OpenClaw не слід публікувати.
 
 ## Вхідні дані workflow NPM
 
-`OpenClaw NPM Release` приймає такі керовані оператором вхідні дані:
+`OpenClaw NPM Release` приймає такі вхідні дані, керовані оператором:
 
-- `tag`: обов’язковий тег випуску, наприклад `v2026.4.2`, `v2026.4.2-1` або
-  `v2026.4.2-alpha.1` чи `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
-  повний 40-символьний SHA коміту гілки workflow для preflight лише з валідацією
+- `tag`: обов’язковий release tag, як-от `v2026.4.2`, `v2026.4.2-1`, або
+  `v2026.4.2-alpha.1` чи `v2026.4.2-beta.1`; коли `preflight_only=true`, ним також може бути поточний
+  повний 40-символьний commit SHA гілки workflow для preflight лише з валідацією
 - `preflight_only`: `true` лише для валідації/збірки/пакування, `false` для
   реального шляху публікації
 - `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб workflow повторно використав
   підготовлений tarball з успішного preflight-запуску
-- `npm_dist_tag`: цільовий тег npm для шляху публікації; за замовчуванням `beta`
+- `npm_dist_tag`: цільовий npm tag для шляху публікації; стандартно `beta`
 
-`OpenClaw Release Publish` приймає такі керовані оператором вхідні дані:
+`OpenClaw Release Publish` приймає такі введення, керовані оператором:
 
 - `tag`: обов’язковий тег випуску; має вже існувати
-- `preflight_run_id`: ідентифікатор успішного preflight-запуску `OpenClaw NPM Release`;
+- `preflight_run_id`: ідентифікатор успішного попереднього запуску `OpenClaw NPM Release`;
   обов’язковий, коли `publish_openclaw_npm=true`
 - `npm_dist_tag`: цільовий тег npm для пакета OpenClaw
 - `plugin_publish_scope`: за замовчуванням `all-publishable`; використовуйте `selected` лише
-  для сфокусованого ремонту
+  для цільових робіт із виправлення
 - `plugins`: розділені комами назви пакетів `@openclaw/*`, коли
   `plugin_publish_scope=selected`
-- `publish_openclaw_npm`: за замовчуванням `true`; встановлюйте `false` лише під час використання
-  workflow як оркестратора ремонту лише plugins
+- `publish_openclaw_npm`: за замовчуванням `true`; установлюйте `false` лише тоді, коли використовуєте
+  робочий процес як оркестратор виправлення лише для Plugin
 
-`OpenClaw Release Checks` приймає такі керовані оператором вхідні дані:
+`OpenClaw Release Checks` приймає такі введення, керовані оператором:
 
-- `ref`: гілка, тег або повний SHA коміту для валідації. Перевірки із секретами
+- `ref`: гілка, тег або повний SHA коміту для перевірки. Перевірки із секретами
   вимагають, щоб розв’язаний коміт був досяжний з гілки OpenClaw або
   тегу випуску.
 
 Правила:
 
-- Стабільні та коригувальні теги можуть публікуватися або до `beta`, або до `latest`
-- Теги передвипуску alpha можуть публікуватися лише до `alpha`
-- Теги передвипуску beta можуть публікуватися лише до `beta`
-- Для `OpenClaw NPM Release` вхідний повний SHA коміту дозволений лише коли
+- Стабільні та коригувальні теги можуть публікуватися або в `beta`, або в `latest`
+- Альфа-теги попередніх випусків можуть публікуватися лише в `alpha`
+- Бета-теги попередніх випусків можуть публікуватися лише в `beta`
+- Для `OpenClaw NPM Release` введення повного SHA коміту дозволене лише коли
   `preflight_only=true`
 - `OpenClaw Release Checks` і `Full Release Validation` завжди
-  призначені лише для валідації
-- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що й під час preflight;
-  workflow перевіряє ці метадані перед продовженням публікації
+  призначені лише для перевірки
+- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час попередньої перевірки;
+  робочий процес перевіряє ці метадані перед продовженням публікації
 
 ## Послідовність стабільного випуску npm
 
 Під час підготовки стабільного випуску npm:
 
 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
-   - До появи тегу можна використати поточний повний SHA коміту гілки workflow
-     для dry run preflight workflow лише з валідацією
-2. Виберіть `npm_dist_tag=beta` для звичайного потоку спершу beta, або `latest` лише
-   коли ви навмисно хочете пряму стабільну публікацію
-3. Запустіть `Full Release Validation` на гілці випуску, тегу випуску або повному
+   - До створення тегу можна використати поточний повний SHA коміту гілки робочого процесу
+     для dry run робочого процесу попередньої перевірки лише з валідацією
+2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише
+   тоді, коли навмисно потрібна пряма стабільна публікація
+3. Запустіть `Full Release Validation` для гілки випуску, тегу випуску або повного
    SHA коміту, коли потрібні звичайний CI плюс покриття live prompt cache, Docker, QA Lab,
-   Matrix і Telegram з одного ручного workflow
+   Matrix і Telegram з одного ручного робочого процесу
 4. Якщо навмисно потрібен лише детермінований звичайний граф тестів, натомість запустіть
-   ручний workflow `CI` на ref випуску
+   ручний робочий процес `CI` на ref випуску
 5. Збережіть успішний `preflight_run_id`
 6. Запустіть `OpenClaw Release Publish` з тим самим `tag`, тим самим `npm_dist_tag`
-   і збереженим `preflight_run_id`; він публікує зовнішні plugins до npm
+   і збереженим `preflight_run_id`; він публікує зовнішні Plugin в npm
    і ClawHub перед просуванням npm-пакета OpenClaw
-7. Якщо випуск потрапив на `beta`, використайте приватний
-   workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
-   для просування цієї стабільної версії з `beta` до `latest`
-8. Якщо випуск навмисно опубліковано напряму до `latest`, а `beta`
-   має негайно вказувати на ту саму стабільну збірку, використайте той самий приватний
-   workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
+7. Якщо випуск потрапив у `beta`, використайте приватний робочий процес
+   `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
+   щоб просунути цю стабільну версію з `beta` до `latest`
+8. Якщо випуск навмисно опубліковано безпосередньо в `latest`, а `beta`
+   має негайно вказувати на той самий стабільний білд, використайте той самий приватний
+   робочий процес, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
    самовідновлювальній синхронізації перемістити `beta` пізніше
 
-Мутація dist-tag розміщена у приватному репозиторії з міркувань безпеки, бо вона досі
+Зміна dist-tag живе в приватному репозиторії з міркувань безпеки, оскільки вона все ще
 потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
 
-Це зберігає і прямий шлях публікації, і шлях просування спершу beta
-задокументованими та видимими для операторів.
+Це робить як шлях прямої публікації, так і шлях просування beta-first
+задокументованими й видимими для оператора.
 
-Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди CLI 1Password (`op`)
-лише всередині окремої tmux-сесії. Не викликайте `op`
-напряму з основної оболонки агента; утримання цього в tmux робить prompts,
-alerts і обробку OTP спостережуваними та запобігає повторним alert на хості.
+Якщо супровіднику потрібно повернутися до локальної автентифікації npm, запускайте будь-які команди 1Password
+CLI (`op`) лише всередині виділеної сесії tmux. Не викликайте `op`
+безпосередньо з основної оболонки агента; утримання цього всередині tmux робить запити,
+сповіщення та обробку OTP спостережуваними й запобігає повторним сповіщенням хоста.
 
 ## Публічні посилання
 
@@ -689,7 +693,7 @@ alerts і обробку OTP спостережуваними та запобі
 - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
 - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)
 
-Maintainers використовують приватну документацію випусків у
+Супровідники використовують приватну документацію випусків у
 [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
 для фактичного runbook.
 

docs/uk/reference/full-release-validation.md

@@ -1,25 +1,24 @@
 ---
 read_when:
     - Запуск або повторний запуск повної перевірки релізу
-    - Порівняння стабільного та повного профілів перевірки випуску
+    - Порівняння стабільного та повного профілів перевірки релізу
     - Налагодження збоїв на етапі перевірки релізу
-summary: Етапи повної валідації релізу, дочірні робочі процеси, профілі релізу, ідентифікатори повторних запусків і докази
+summary: Етапи повної перевірки релізу, дочірні робочі процеси, профілі релізу, дескриптори повторного запуску та докази
 title: Повна перевірка релізу
 x-i18n:
-    generated_at: "2026-05-01T23:10:06Z"
+    generated_at: "2026-05-02T18:57:53Z"
     model: gpt-5.5
     provider: openai
-    source_hash: feb4edec850fb97405575c869547b4851bc773507321690670553e6faafc8b0b
+    source_hash: 3ce1e5a72227ca202335fe68b537491a0b68a0bb2af431aa56c41cf20989e88c
     source_path: reference/full-release-validation.md
     workflow: 16
 ---
 
 `Full Release Validation` — це парасолька релізу. Це єдина ручна
-точка входу для передрелізного підтвердження, але більшість роботи виконується
-в дочірніх workflow, щоб невдалий бокс можна було перезапустити без повторного
-запуску всього релізу.
+точка входу для дорелізного підтвердження, але більшість роботи відбувається в дочірніх workflow, щоб
+невдалу box можна було повторно запустити без перезапуску всього релізу.
 
-Запускайте її з довіреного ref workflow, зазвичай `main`, і передайте релізну гілку,
+Запускайте її з довіреного workflow ref, зазвичай `main`, і передавайте релізну гілку,
 тег або повний SHA коміту як `ref`:
 
 ```bash
@@ -31,117 +30,117 @@ gh workflow run full-release-validation.yml \
   -f release_profile=stable
 ```
 
-Дочірні workflow використовують довірений ref workflow для harness і вхідний
-`ref` для кандидата, що тестується. Це зберігає нову логіку валідації доступною
+Дочірні workflow використовують довірений workflow ref для harness і вхідний
+`ref` для кандидата, що тестується. Це робить нову логіку валідації доступною
 під час валідації старішої релізної гілки або тегу.
 
-## Верхньорівневі етапи
+Package Acceptance зазвичай збирає tarball кандидата з розв’язаного
+`ref`, включно із запусками повного SHA, dispatch виконано через `pnpm ci:full-release`. Після
+публікації передайте `package_acceptance_package_spec=openclaw@YYYY.M.D` (або
+`openclaw@beta`/`openclaw@latest`), щоб натомість запустити ту саму матрицю package/update проти
+відправленого npm-пакета.
 
-| Етап                 | Деталі                                                                                                                                                                                                                                                                                                                                                                                                                    |
-| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Визначення цілі      | **Job:** `Resolve target ref`<br />**Дочірній workflow:** немає<br />**Підтверджує:** визначає релізну гілку, тег або повний SHA коміту та записує вибрані вхідні параметри.<br />**Перезапуск:** перезапустіть парасольку, якщо це завершиться невдачею.                                                                                                                                                                  |
-| Vitest і звичайний CI | **Job:** `Run normal full CI`<br />**Дочірній workflow:** `CI`<br />**Підтверджує:** ручний повний граф CI для цільового ref, включно з Linux Node lanes, шардами вбудованих Plugin, контрактами каналів, сумісністю з Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, Control UI i18n та Android через парасольку.<br />**Перезапуск:** `rerun_group=ci`. |
-| Передреліз Plugin    | **Job:** `Run plugin prerelease validation`<br />**Дочірній workflow:** `Plugin Prerelease`<br />**Підтверджує:** релізні статичні перевірки Plugin, агентне покриття Plugin, повні batch-шарди extensions і Docker lanes передрелізу Plugin.<br />**Перезапуск:** `rerun_group=plugin-prerelease`.                                                                                                                        |
-| Релізні перевірки    | **Job:** `Run release/live/Docker/QA validation`<br />**Дочірній workflow:** `OpenClaw Release Checks`<br />**Підтверджує:** install smoke, cross-OS package checks, live/E2E suites, chunks релізного шляху Docker, Package Acceptance, паритет QA Lab, live Matrix і live Telegram.<br />**Перезапуск:** `rerun_group=release-checks` або вужчий handle release-checks.                                                   |
-| Пакет Telegram       | **Job:** `Run package Telegram E2E`<br />**Дочірній workflow:** `NPM Telegram Beta E2E`<br />**Підтверджує:** підтвердження пакета Telegram на основі артефакта для `rerun_group=all` з `release_profile=full`, або підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.<br />**Перезапуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`.                             |
-| Верифікатор парасольки | **Job:** `Verify full validation`<br />**Дочірній workflow:** немає<br />**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших job з дочірніх workflow.<br />**Перезапуск:** після успішного перезапуску невдалого дочірнього workflow перезапустіть лише цей job.                                                                                                      |
+## Етапи верхнього рівня
+
+| Етап                 | Подробиці                                                                                                                                                                                                                                                                                                                                                                                      |
+| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Розв’язання цілі     | **Job:** `Resolve target ref`<br />**Дочірній workflow:** немає<br />**Підтверджує:** розв’язує релізну гілку, тег або повний SHA коміту й записує вибрані вхідні дані.<br />**Повторний запуск:** повторно запустіть парасольку, якщо це не вдасться.                                                                                                                                       |
+| Vitest і звичайний CI | **Job:** `Run normal full CI`<br />**Дочірній workflow:** `CI`<br />**Підтверджує:** ручний повний граф CI проти цільового ref, включно з Linux Node lanes, bundled plugin shards, channel contracts, сумісністю з Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, Control UI i18n і Android через парасольку.<br />**Повторний запуск:** `rerun_group=ci`. |
+| Дореліз Plugin       | **Job:** `Run plugin prerelease validation`<br />**Дочірній workflow:** `Plugin Prerelease`<br />**Підтверджує:** релізні статичні перевірки Plugin, agentic plugin coverage, повні batch shards розширень і дорелізні Docker lanes Plugin.<br />**Повторний запуск:** `rerun_group=plugin-prerelease`.                                                                                    |
+| Релізні перевірки    | **Job:** `Run release/live/Docker/QA validation`<br />**Дочірній workflow:** `OpenClaw Release Checks`<br />**Підтверджує:** install smoke, cross-OS package checks, live/E2E suites, Docker release-path chunks, Package Acceptance, QA Lab parity, live Matrix і live Telegram.<br />**Повторний запуск:** `rerun_group=release-checks` або вужчий handle release-checks.                  |
+| Package Telegram     | **Job:** `Run package Telegram E2E`<br />**Дочірній workflow:** `NPM Telegram Beta E2E`<br />**Підтверджує:** підтвердження Telegram-пакета на основі артефакта для `rerun_group=all` з `release_profile=full` або підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.<br />**Повторний запуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`. |
+| Верифікатор парасольки | **Job:** `Verify full validation`<br />**Дочірній workflow:** немає<br />**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших job з дочірніх workflow.<br />**Повторний запуск:** повторно запустіть лише цей job після повторного запуску невдалого дочірнього запуску до зеленого стану.                                                        |
 
 Для `ref=main` і `rerun_group=all` новіша парасолька замінює старішу.
-Коли батьківський запуск скасовано, його монітор скасовує будь-який дочірній
-workflow, який він уже відправив. Запуски валідації релізної гілки й тегу
-за замовчуванням не скасовують один одного.
+Коли батьківський запуск скасовано, його монітор скасовує будь-який дочірній workflow, який він уже
+dispatch виконав. Запуски валідації релізної гілки та тегу типово не скасовують один одного.
 
 ## Етапи релізних перевірок
 
-`OpenClaw Release Checks` — найбільший дочірній workflow. Він один раз визначає
-ціль і готує спільний артефакт `release-package-under-test`, коли він потрібен
-етапам, що працюють із пакетами або Docker.
+`OpenClaw Release Checks` — найбільший дочірній workflow. Він розв’язує ціль
+один раз і готує спільний артефакт `release-package-under-test`, коли він потрібен етапам,
+пов’язаним із package або Docker.
 
-| Етап                | Деталі                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Ціль релізу         | **Job:** `Resolve target ref`<br />**Базовий workflow:** немає<br />**Тести:** вибраний ref, необов’язковий очікуваний SHA, профіль, група перезапуску та сфокусований фільтр live suite.<br />**Перезапуск:** `rerun_group=release-checks`.                                                                                                                                                                           |
-| Артефакт пакета     | **Job:** `Prepare release package artifact`<br />**Базовий workflow:** немає<br />**Тести:** пакує або визначає один tarball кандидата та завантажує `release-package-under-test` для подальших перевірок, що працюють із пакетами.<br />**Перезапуск:** відповідна група package, cross-OS або live/E2E.                                                                                                               |
-| Install smoke       | **Job:** `Run install smoke`<br />**Базовий workflow:** `Install Smoke`<br />**Тести:** повний шлях установлення з повторним використанням smoke-образу root Dockerfile, встановлення QR-пакета, root і gateway Docker smokes, Docker-тести інсталятора, Bun global install image-provider smoke та швидкий E2E install/uninstall вбудованого Plugin.<br />**Перезапуск:** `rerun_group=install-smoke`.                |
-| Cross-OS            | **Job:** `cross_os_release_checks`<br />**Базовий workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`<br />**Тести:** fresh і upgrade lanes у Linux, Windows і macOS для вибраного провайдера та режиму, з використанням tarball кандидата плюс baseline-пакета.<br />**Перезапуск:** `rerun_group=cross-os`.                                                                                                      |
-| Repo і live E2E     | **Job:** `Run repo/live E2E validation`<br />**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тести:** repository E2E, live cache, OpenAI websocket streaming, native live provider і шарди Plugin, а також Docker-backed live model/backend/gateway harnesses, вибрані `release_profile`.<br />**Перезапуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`.                   |
-| Релізний шлях Docker | **Job:** `Run Docker release-path validation`<br />**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тести:** chunks релізного шляху Docker проти спільного артефакта пакета.<br />**Перезапуск:** `rerun_group=live-e2e`.                                                                                                                                                                       |
-| Package Acceptance  | **Job:** `Run package acceptance`<br />**Базовий workflow:** `Package Acceptance`<br />**Тести:** офлайн fixtures пакетів Plugin, оновлення Plugin і mock-OpenAI Telegram package acceptance проти того самого tarball.<br />**Перезапуск:** `rerun_group=package`.                                                                                                                                                    |
-| QA parity           | **Job:** `Run QA Lab parity lane` і `Run QA Lab parity report`<br />**Базовий workflow:** прямі jobs<br />**Тести:** кандидат і baseline agentic parity packs, потім parity report.<br />**Перезапуск:** `rerun_group=qa-parity` або `rerun_group=qa`.                                                                                                                                                                  |
-| QA live Matrix      | **Job:** `Run QA Lab live Matrix lane`<br />**Базовий workflow:** прямий job<br />**Тести:** швидкий live Matrix QA profile у середовищі `qa-live-shared`.<br />**Перезапуск:** `rerun_group=qa-live` або `rerun_group=qa`.                                                                                                                                                                                             |
-| QA live Telegram    | **Job:** `Run QA Lab live Telegram lane`<br />**Базовий workflow:** прямий job<br />**Тести:** live Telegram QA з leases облікових даних Convex CI.<br />**Перезапуск:** `rerun_group=qa-live` або `rerun_group=qa`.                                                                                                                                                                                                    |
-| Верифікатор релізу  | **Job:** `Verify release checks`<br />**Базовий workflow:** немає<br />**Тести:** обов’язкові jobs release-check для вибраної групи перезапуску.<br />**Перезапуск:** перезапустіть після успішного проходження сфокусованих дочірніх jobs.                                                                                                                                                                           |
+| Етап                | Подробиці                                                                                                                                                                                                                                                                                                                                                                                       |
+| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Релізна ціль        | **Job:** `Resolve target ref`<br />**Backing workflow:** немає<br />**Тестує:** вибраний ref, необов’язковий очікуваний SHA, profile, rerun group і сфокусований фільтр live suite.<br />**Повторний запуск:** `rerun_group=release-checks`.                                                                                                                                                  |
+| Артефакт пакета     | **Job:** `Prepare release package artifact`<br />**Backing workflow:** немає<br />**Тестує:** пакує або розв’язує один tarball кандидата й завантажує `release-package-under-test` для downstream package-facing перевірок.<br />**Повторний запуск:** відповідна package, cross-OS або live/E2E group.                                                                                         |
+| Install smoke       | **Job:** `Run install smoke`<br />**Backing workflow:** `Install Smoke`<br />**Тестує:** повний шлях інсталяції з повторним використанням root Dockerfile smoke image, інсталяцію QR package, root і gateway Docker smokes, installer Docker tests, Bun global install image-provider smoke і швидкий bundled-plugin install/uninstall E2E.<br />**Повторний запуск:** `rerun_group=install-smoke`. |
+| Cross-OS            | **Job:** `cross_os_release_checks`<br />**Backing workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`<br />**Тестує:** fresh і upgrade lanes на Linux, Windows і macOS для вибраних provider і mode, використовуючи tarball кандидата плюс baseline package.<br />**Повторний запуск:** `rerun_group=cross-os`.                                                                        |
+| Repo і live E2E     | **Job:** `Run repo/live E2E validation`<br />**Backing workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тестує:** repository E2E, live cache, OpenAI websocket streaming, native live provider і plugin shards, а також Docker-backed live model/backend/gateway harnesses, вибрані `release_profile`.<br />**Повторний запуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`. |
+| Docker release path | **Job:** `Run Docker release-path validation`<br />**Backing workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тестує:** Docker chunks релізного шляху проти спільного артефакта пакета.<br />**Повторний запуск:** `rerun_group=live-e2e`.                                                                                                                                          |
+| Package Acceptance  | **Job:** `Run package acceptance`<br />**Backing workflow:** `Package Acceptance`<br />**Тестує:** offline fixtures пакетів Plugin, оновлення Plugin, package acceptance для mock-OpenAI Telegram і published-upgrade survivor checks з кожного стабільного npm-релізу на або після `2026.4.23` проти того самого tarball.<br />**Повторний запуск:** `rerun_group=package`.                   |
+| QA parity           | **Job:** `Run QA Lab parity lane` і `Run QA Lab parity report`<br />**Backing workflow:** прямі jobs<br />**Тестує:** candidate і baseline agentic parity packs, потім parity report.<br />**Повторний запуск:** `rerun_group=qa-parity` або `rerun_group=qa`.                                                                                                                                |
+| QA live Matrix      | **Job:** `Run QA Lab live Matrix lane`<br />**Backing workflow:** прямий job<br />**Тестує:** швидкий live Matrix QA profile у середовищі `qa-live-shared`.<br />**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`.                                                                                                                                                          |
+| QA live Telegram    | **Job:** `Run QA Lab live Telegram lane`<br />**Backing workflow:** прямий job<br />**Тестує:** live Telegram QA з орендами облікових даних Convex CI.<br />**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`.                                                                                                                                                                |
+| Релізний верифікатор | **Job:** `Verify release checks`<br />**Backing workflow:** немає<br />**Тестує:** обов’язкові jobs release-check для вибраної rerun group.<br />**Повторний запуск:** повторно запустіть після успішного проходження сфокусованих дочірніх jobs.                                                                                                                                             |
 
-## Chunks релізного шляху Docker
+## Docker chunks релізного шляху
 
-Етап релізного шляху Docker запускає ці chunks, коли `live_suite_filter`
+Етап Docker release-path запускає ці chunks, коли `live_suite_filter`
 порожній:
 
-| Chunk                                                           | Покриття                                                                  |
-| --------------------------------------------------------------- | ------------------------------------------------------------------------- |
-| `core`                                                          | Smoke lanes релізного шляху Core Docker.                                  |
-| `package-update-openai`                                         | Поведінка встановлення й оновлення пакета OpenAI.                         |
-| `package-update-anthropic`                                      | Поведінка встановлення й оновлення пакета Anthropic.                      |
-| `package-update-core`                                           | Провайдер-нейтральна поведінка пакета й оновлення.                        |
-| `plugins-runtime-plugins`                                       | Runtime lanes Plugin, які перевіряють поведінку Plugin.                   |
-| `plugins-runtime-services`                                      | Runtime lanes Plugin на основі сервісів; включає OpenWebUI, коли запитано. |
-| `plugins-runtime-install-a` through `plugins-runtime-install-h` | Batch-перевірки встановлення/runtime Plugin, розділені для паралельної релізної валідації. |
+| Chunk                                                           | Покриття                                                                 |
+| --------------------------------------------------------------- | ------------------------------------------------------------------------ |
+| `core`                                                          | Core Docker release-path smoke lanes.                                    |
+| `package-update-openai`                                         | Поведінка інсталяції та оновлення пакета OpenAI.                         |
+| `package-update-anthropic`                                      | Поведінка інсталяції та оновлення пакета Anthropic.                      |
+| `package-update-core`                                           | Provider-neutral поведінка пакета й оновлення.                           |
+| `plugins-runtime-plugins`                                       | Plugin runtime lanes, які перевіряють поведінку Plugin.                  |
+| `plugins-runtime-services`                                      | Service-backed Plugin runtime lanes; включає OpenWebUI, коли запитано.   |
+| `plugins-runtime-install-a` through `plugins-runtime-install-h` | Batch інсталяції/runtime Plugin, розділені для паралельної релізної валідації. |
 
-Використовуйте цільові `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow,
-коли не пройшла лише одна Docker lane. Релізні артефакти містять команди
-перезапуску для кожної lane з artifact пакета та вхідними параметрами повторного
-використання образу, коли вони доступні.
+Використовуйте цільове `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow, коли
+не вдалася лише одна Docker lane. Релізні артефакти містять команди повторного запуску для кожної lane
+з package artifact і image reuse inputs, коли вони доступні.
 
-## Релізні профілі
+## Релізні profiles
 
-`release_profile` переважно керує шириною live/provider усередині релізних перевірок.
-Він не прибирає normal full CI, Plugin Prerelease, install smoke, package
-acceptance, QA Lab або chunks релізного шляху Docker. `full` також змушує
-парасольку запускати package Telegram E2E проти артефакта релізного пакета,
-коли `rerun_group=all`, щоб повний pre-publish кандидат не пропустив мовчки
-цю lane пакета Telegram.
+`release_profile` переважно керує шириною live/provider у межах перевірок випуску.
+Він не вилучає звичайний повний CI, Plugin попередній випуск, install smoke, приймання пакета, QA Lab або фрагменти release-path Docker. `full` також змушує парасольковий запуск виконувати package Telegram E2E для артефакта пакета випуску, коли `rerun_group=all`, тож повний кандидат перед публікацією не пропускає непомітно цю Telegram-лінію пакета.
 
-| Профіль  | Призначення                         | Включене покриття live/provider                                                                                                                                                  |
-| -------- | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `minimum` | Найшвидший критичний для релізу smoke. | OpenAI/core live-шлях, Docker live-моделі для OpenAI, нативний core Gateway, нативний профіль OpenAI Gateway, нативний OpenAI Plugin і Docker live Gateway OpenAI.              |
-| `stable`  | Стандартний профіль схвалення релізу. | `minimum` плюс Anthropic, Google, MiniMax, backend, нативний live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і smoke-шард OpenCode Go.        |
-| `full`    | Широкий advisory-перегляд.          | `stable` плюс advisory-провайдери, live-шарди Plugin і медіа live-шарди.                                                                                                        |
+| Профіль  | Призначення                         | Включене live/provider-покриття                                                                                                                                                           |
+| -------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `minimum` | Найшвидший критичний smoke для випуску. | OpenAI/основний live-шлях, Docker live-моделі для OpenAI, основний native gateway, native OpenAI gateway-профіль, native OpenAI plugin і Docker live gateway OpenAI.                      |
+| `stable`  | Типовий профіль схвалення випуску. | `minimum` плюс Anthropic, Google, MiniMax, backend, native live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і один smoke-шард OpenCode Go.              |
+| `full`    | Широкий дорадчий sweep.             | `stable` плюс дорадчі провайдери, live-шарди plugin і live-шарди медіа.                                                                                                                    |
 
-## Доповнення лише для full
+## Додатки лише для full
 
 Ці набори пропускаються в `stable` і включаються в `full`:
 
-| Область                         | Покриття лише для full                                                       |
-| ------------------------------- | ---------------------------------------------------------------------------- |
-| Docker live-моделі              | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks.                              |
-| Docker live Gateway             | Advisory-шард для DeepSeek, Fireworks, OpenCode Go, OpenRouter, xAI і Z.ai.  |
-| Нативні профілі провайдерів Gateway | Fireworks, DeepSeek, повні шарди моделей OpenCode Go, OpenRouter, xAI і Z.ai. |
-| Нативні live-шарди Plugin       | Plugins A-K, L-N, O-Z other, Moonshot і xAI.                                 |
-| Нативні медіа live-шарди        | Аудіо, музика Google, музика MiniMax і відеогрупи A-D.                       |
+| Область                         | Покриття лише для full                                                         |
+| -------------------------------- | ------------------------------------------------------------------------------- |
+| Docker live-моделі              | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks.                                |
+| Docker live gateway             | Дорадчий шард для DeepSeek, Fireworks, OpenCode Go, OpenRouter, xAI і Z.ai.    |
+| Native gateway provider-профілі | Fireworks, DeepSeek, повні шарди моделей OpenCode Go, OpenRouter, xAI і Z.ai.  |
+| Native plugin live-шарди        | Plugins A-K, L-N, O-Z інші, Moonshot і xAI.                                    |
+| Native media live-шарди         | Audio, Google music, MiniMax music і video groups A-D.                         |
 
 `stable` включає `native-live-src-gateway-profiles-opencode-go-smoke`; `full`
 натомість використовує ширші шарди моделей OpenCode Go.
 
-## Фокусовані повторні запуски
+## Сфокусовані повторні запуски
 
-Використовуйте `rerun_group`, щоб не повторювати непов’язані релізні бокси:
+Використовуйте `rerun_group`, щоб не повторювати непов’язані release boxes:
 
-| Handle              | Обсяг                                                                 |
-| ------------------- | --------------------------------------------------------------------- |
-| `all`               | Усі етапи Full Release Validation.                                    |
-| `ci`                | Лише дочірній manual full CI.                                         |
-| `plugin-prerelease` | Лише дочірній Plugin Prerelease.                                      |
-| `release-checks`    | Усі етапи OpenClaw Release Checks.                                    |
-| `install-smoke`     | Install Smoke через release checks.                                   |
-| `cross-os`          | Cross-OS release checks.                                              |
-| `live-e2e`          | Repo/live E2E і валідація Docker release-path.                        |
-| `package`           | Package Acceptance.                                                   |
-| `qa`                | QA parity плюс QA live-лінії.                                         |
-| `qa-parity`         | Лише QA parity-лінії та звіт.                                         |
-| `qa-live`           | Лише QA live Matrix і Telegram.                                       |
-| `npm-telegram`      | E2E Telegram для опублікованого пакета; потребує `npm_telegram_package_spec`. |
+| Дескриптор         | Обсяг                                                                 |
+| ------------------ | --------------------------------------------------------------------- |
+| `all`              | Усі етапи повної валідації випуску.                                   |
+| `ci`               | Лише дочірній ручний повний CI.                                       |
+| `plugin-prerelease` | Лише дочірній попередній випуск Plugin.                              |
+| `release-checks`   | Усі етапи перевірок випуску OpenClaw.                                 |
+| `install-smoke`    | Install Smoke через перевірки випуску.                                |
+| `cross-os`         | Cross-OS перевірки випуску.                                           |
+| `live-e2e`         | Repo/live E2E і Docker release-path валідація.                        |
+| `package`          | Приймання пакета.                                                     |
+| `qa`               | QA parity плюс QA live-лінії.                                         |
+| `qa-parity`        | Лише QA parity-лінії та звіт.                                         |
+| `qa-live`          | Лише QA live Matrix і Telegram.                                       |
+| `npm-telegram`     | Published-package Telegram E2E; потребує `npm_telegram_package_spec`. |
 
 Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли збій стався в одному live-наборі.
-Дійсні filter ids визначені в багаторазовому workflow live/E2E, зокрема
+Дійсні ідентифікатори фільтрів визначені в reusable live/E2E workflow, зокрема
 `docker-live-models`, `live-gateway-docker`,
 `live-gateway-anthropic-docker`, `live-gateway-google-docker`,
 `live-gateway-minimax-docker`, `live-gateway-advisory-docker`,
@@ -150,17 +149,17 @@ acceptance, QA Lab або chunks релізного шляху Docker. `full` т
 
 ## Докази, які слід зберегти
 
-Зберігайте підсумок `Full Release Validation` як індекс рівня релізу. Він містить посилання
-на child run ids і включає таблиці найповільніших job. У разі збоїв спочатку перевірте дочірній
-workflow, а потім повторно запустіть найменший відповідний handle вище.
+Зберігайте summary `Full Release Validation` як індекс рівня випуску. Він містить посилання
+на child run ids і таблиці slowest-job. У разі збоїв спершу перевіряйте child workflow,
+а потім повторно запускайте найменший відповідний дескриптор вище.
 
 Корисні артефакти:
 
 - `release-package-under-test` з `OpenClaw Release Checks`
-- Артефакти Docker release-path у `.artifacts/docker-tests/`
-- `package-under-test` з Package Acceptance і артефакти Docker acceptance
-- Артефакти Cross-OS release-check для кожної OS і suite
-- Артефакти QA parity, Matrix і Telegram
+- Docker release-path артефакти в `.artifacts/docker-tests/`
+- Package Acceptance `package-under-test` і Docker acceptance артефакти
+- Cross-OS release-check артефакти для кожної ОС і набору
+- QA parity, Matrix і Telegram артефакти
 
 ## Файли workflow
 

docs/uk/tools/skills.md

@@ -1,56 +1,56 @@
 ---
 read_when:
     - Додавання або змінення Skills
-    - Зміна гейтингу Skills, списків дозволеного або правил завантаження
-    - Розуміння пріоритету Skills і поведінки знімків
+    - Зміна контролю доступу до навичок, списків дозволених або правил завантаження
+    - Розуміння пріоритетності Skills і поведінки знімків
 sidebarTitle: Skills
-summary: 'Skills: керовані та робоча область, правила гейтинг-контролю, allowlist агентів і підключення конфігурації'
+summary: 'Skills: керовані та робочої області, правила шлюзування, списки дозволених агентів і зв’язування конфігурації'
 title: Skills
 x-i18n:
-    generated_at: "2026-04-30T19:53:32Z"
+    generated_at: "2026-05-02T18:58:43Z"
     model: gpt-5.5
     provider: openai
-    source_hash: b58d690786756bd3539940aae9f2abcb8a497798ed7b6afeb5e6d6e255fcf257
+    source_hash: 85d9a5305216abd277721a9cf46404505ac6bedcad78417e10862bf7f54591ea
     source_path: tools/skills.md
     workflow: 16
 ---
 
-OpenClaw використовує **сумісні з [AgentSkills](https://agentskills.io)** папки навичок, щоб навчити агента користуватися інструментами. Кожна навичка — це каталог, що містить `SKILL.md` з YAML-frontmatter та інструкціями. OpenClaw завантажує вбудовані навички разом із необов’язковими локальними перевизначеннями та фільтрує їх під час завантаження на основі середовища, конфігурації та наявності бінарних файлів.
+OpenClaw використовує **сумісні з [AgentSkills](https://agentskills.io)** папки навичок, щоб навчити агента користуватися інструментами. Кожна навичка — це директорія, що містить `SKILL.md` з YAML frontmatter та інструкціями. OpenClaw завантажує вбудовані навички разом із необов’язковими локальними перевизначеннями та фільтрує їх під час завантаження на основі середовища, конфігурації та наявності бінарних файлів.
 
 ## Розташування та пріоритет
 
-OpenClaw завантажує навички з цих джерел, **спершу з найвищим пріоритетом**:
+OpenClaw завантажує навички з цих джерел, **від найвищого пріоритету до найнижчого**:
 
-| #   | Джерело                    | Шлях                             |
-| --- | -------------------------- | -------------------------------- |
-| 1   | Навички робочої області    | `<workspace>/skills`             |
-| 2   | Навички агента проєкту     | `<workspace>/.agents/skills`     |
-| 3   | Особисті навички агента    | `~/.agents/skills`               |
-| 4   | Керовані/локальні навички  | `~/.openclaw/skills`             |
-| 5   | Вбудовані навички          | постачаються з інсталяцією       |
-| 6   | Додаткові папки навичок    | `skills.load.extraDirs` (config) |
+| #   | Джерело                       | Шлях                             |
+| --- | ----------------------------- | -------------------------------- |
+| 1   | Навички робочої області       | `<workspace>/skills`             |
+| 2   | Навички агента проєкту        | `<workspace>/.agents/skills`     |
+| 3   | Особисті навички агента       | `~/.agents/skills`               |
+| 4   | Керовані/локальні навички     | `~/.openclaw/skills`             |
+| 5   | Вбудовані навички             | постачаються з інсталяцією       |
+| 6   | Додаткові папки навичок       | `skills.load.extraDirs` (конфігурація) |
 
 Якщо назва навички конфліктує, перемагає джерело з найвищим пріоритетом.
 
-Власний каталог Codex CLI `$CODEX_HOME/skills` не є одним із цих коренів навичок OpenClaw. У режимі Codex harness локальні запуски app-server використовують ізольовані для кожного агента домівки Codex, тому особисті навички Codex CLI не завантажуються неявно. Використайте `openclaw migrate codex --dry-run`, щоб інвентаризувати їх, і `openclaw migrate codex`, щоб вибрати каталоги навичок за допомогою інтерактивного запиту з прапорцями перед копіюванням їх у поточну робочу область агента OpenClaw. Для неінтерактивних запусків повторюйте `--skill <name>` для точних навичок, які потрібно скопіювати.
+Нативна директорія Codex CLI `$CODEX_HOME/skills` не є одним із коренів навичок OpenClaw. У режимі Codex harness локальні запуски app-server використовують ізольовані домівки Codex для кожного агента, тому особисті навички Codex CLI не завантажуються неявно. Використайте `openclaw migrate codex --dry-run`, щоб інвентаризувати їх, і `openclaw migrate codex`, щоб вибрати директорії навичок через інтерактивний запит із прапорцями перед копіюванням їх у поточну робочу область агента OpenClaw. Для неінтерактивних запусків повторюйте `--skill <name>` для точних навичок, які потрібно скопіювати.
 
-## Навички для окремого агента та спільні навички
+## Навички для окремого агента й спільні навички
 
 У налаштуваннях із **кількома агентами** кожен агент має власну робочу область:
 
-| Область                  | Шлях                                        | Видимо для                         |
-| ------------------------ | ------------------------------------------- | ---------------------------------- |
-| Для окремого агента      | `<workspace>/skills`                        | Лише цього агента                  |
-| Агент проєкту            | `<workspace>/.agents/skills`                | Лише агента цієї робочої області   |
-| Особистий агент          | `~/.agents/skills`                          | Усіх агентів на цій машині         |
-| Спільні керовані/локальні| `~/.openclaw/skills`                        | Усіх агентів на цій машині         |
-| Спільні додаткові каталоги | `skills.load.extraDirs` (найнижчий пріоритет) | Усіх агентів на цій машині      |
+| Область                       | Шлях                                        | Видима для                          |
+| ----------------------------- | ------------------------------------------- | ----------------------------------- |
+| Для окремого агента           | `<workspace>/skills`                        | Лише цього агента                   |
+| Агент проєкту                 | `<workspace>/.agents/skills`                | Лише агента цієї робочої області    |
+| Особистий агент               | `~/.agents/skills`                          | Усіх агентів на цій машині          |
+| Спільні керовані/локальні     | `~/.openclaw/skills`                        | Усіх агентів на цій машині          |
+| Спільні додаткові директорії  | `skills.load.extraDirs` (найнижчий пріоритет) | Усіх агентів на цій машині        |
 
-Та сама назва в кількох місцях → перемагає джерело з найвищим пріоритетом. Робоча область має перевагу над агентом проєкту, той — над особистим агентом, той — над керованими/локальними, ті — над вбудованими, а ті — над додатковими каталогами.
+Однакова назва в кількох місцях → перемагає джерело з найвищим пріоритетом. Робоча область має вищий пріоритет за агента проєкту, той — за особистого агента, той — за керовані/локальні, ті — за вбудовані, а ті — за додаткові директорії.
 
 ## Списки дозволених навичок агента
 
-**Розташування** навички та **видимість** навички — це окремі засоби керування. Розташування/пріоритет визначає, яка копія однойменної навички перемагає; списки дозволених для агента визначають, які навички агент фактично може використовувати.
+**Розташування** навички та **видимість** навички — це окремі елементи керування. Розташування/пріоритет визначає, яка копія однойменної навички перемагає; списки дозволених для агента визначають, які навички агент фактично може використовувати.
 
 ```json5
 {
@@ -59,68 +59,66 @@ OpenClaw завантажує навички з цих джерел, **спер
       skills: ["github", "weather"],
     },
     list: [
-      { id: "writer" }, // inherits github, weather
-      { id: "docs", skills: ["docs-search"] }, // replaces defaults
-      { id: "locked-down", skills: [] }, // no skills
+      { id: "writer" }, // успадковує github, weather
+      { id: "docs", skills: ["docs-search"] }, // замінює defaults
+      { id: "locked-down", skills: [] }, // без навичок
     ],
   },
 }
 ```
 
 <AccordionGroup>
-  <Accordion title="Правила списку дозволених">
-    - Пропустіть `agents.defaults.skills`, щоб за замовчуванням навички були без обмежень.
-    - Пропустіть `agents.list[].skills`, щоб успадкувати `agents.defaults.skills`.
-    - Установіть `agents.list[].skills: []`, щоб не було жодних навичок.
-    - Непорожній список `agents.list[].skills` є **остаточним** набором для цього агента — він не об’єднується із замовчуваннями.
-    - Ефективний список дозволених застосовується до побудови prompt, виявлення slash-команд навичок, синхронізації sandbox і знімків навичок.
-
+  <Accordion title="Правила списку дозволеного">
+    - Не вказуйте `agents.defaults.skills`, щоб навички за замовчуванням були необмеженими.
+    - Не вказуйте `agents.list[].skills`, щоб успадкувати `agents.defaults.skills`.
+    - Встановіть `agents.list[].skills: []`, щоб не було жодних навичок.
+    - Непорожній список `agents.list[].skills` є **остаточним** набором для цього агента — він не об’єднується з defaults.
+    - Ефективний список дозволеного застосовується під час побудови промпта, виявлення slash-команд навичок, синхронізації sandbox та знімків навичок.
   </Accordion>
 </AccordionGroup>
 
-## Plugins і навички
+## Плагіни та навички
 
-Plugins можуть постачати власні навички, перелічуючи каталоги `skills` в `openclaw.plugin.json` (шляхи відносно кореня Plugin). Навички Plugin завантажуються, коли Plugin увімкнено. Це правильне місце для специфічних для інструмента робочих посібників, які занадто довгі для опису інструмента, але мають бути доступні щоразу, коли Plugin інстальовано — наприклад, браузерний Plugin постачає навичку `browser-automation` для багатоетапного керування браузером.
+Плагіни можуть постачати власні навички, перелічуючи директорії `skills` в `openclaw.plugin.json` (шляхи відносно кореня Plugin). Навички Plugin завантажуються, коли Plugin увімкнено. Це правильне місце для інструкцій із роботи з конкретними інструментами, які надто довгі для опису інструмента, але мають бути доступні щоразу, коли Plugin встановлено — наприклад, браузерний Plugin постачає навичку `browser-automation` для багатокрокового керування браузером.
 
-Каталоги навичок Plugin об’єднуються в той самий шлях із низьким пріоритетом, що й `skills.load.extraDirs`, тому однойменна вбудована, керована, агентська навичка або навичка робочої області перевизначає їх. Ви можете обмежувати їх через `metadata.openclaw.requires.config` у записі конфігурації Plugin.
+Директорії навичок Plugin об’єднуються в той самий шлях із низьким пріоритетом, що й `skills.load.extraDirs`, тому однойменна вбудована, керована, агентська навичка або навичка робочої області перевизначає їх. Ви можете обмежити їх через `metadata.openclaw.requires.config` у конфігураційному записі Plugin.
 
-Див. [Plugins](/uk/tools/plugin) для виявлення/конфігурації та [Інструменти](/uk/tools) для поверхні інструментів, яких навчають ці навички.
+Див. [Плагіни](/uk/tools/plugin) для виявлення/конфігурації та [Інструменти](/uk/tools) для поверхні інструментів, якої навчають ці навички.
 
 ## Skill Workshop
 
-Необов’язковий експериментальний Plugin **Skill Workshop** може створювати або оновлювати навички робочої області з повторно використовуваних процедур, помічених під час роботи агента. Він вимкнений за замовчуванням і має бути явно ввімкнений через `plugins.entries.skill-workshop`.
+Необов’язковий експериментальний Plugin **Skill Workshop** може створювати або оновлювати навички робочої області з багаторазових процедур, спостережених під час роботи агента. Він вимкнений за замовчуванням і має бути явно ввімкнений через `plugins.entries.skill-workshop`.
 
-Skill Workshop записує лише в `<workspace>/skills`, сканує згенерований вміст, підтримує очікування схвалення або автоматичні безпечні записи, поміщає небезпечні пропозиції в карантин і оновлює знімок навичок після успішних записів, щоб нові навички ставали доступними без перезапуску Gateway.
+Skill Workshop записує лише до `<workspace>/skills`, сканує згенерований вміст, підтримує очікування затвердження або автоматичні безпечні записи, поміщає небезпечні пропозиції в карантин і оновлює знімок навичок після успішних записів, щоб нові навички стали доступними без перезапуску Gateway.
 
-Використовуйте його для виправлень на кшталт _"наступного разу перевірити атрибуцію GIF"_ або здобутих досвідом робочих процесів, як-от чеклістів QA для медіа. Починайте з очікування схвалення; використовуйте автоматичні записи лише в довірених робочих областях після перегляду його пропозицій. Повний посібник: [Plugin Skill Workshop](/uk/plugins/skill-workshop).
+Використовуйте його для виправлень на кшталт _"наступного разу перевірити атрибуцію GIF"_ або складно здобутих робочих процесів, як-от чеклісти QA для медіа. Почніть з очікування затвердження; використовуйте автоматичні записи лише в довірених робочих областях після перегляду його пропозицій. Повний посібник: [Plugin Skill Workshop](/uk/plugins/skill-workshop).
 
 ## ClawHub (інсталяція та синхронізація)
 
-[ClawHub](https://clawhub.ai) — це публічний реєстр навичок для OpenClaw. Використовуйте нативні команди `openclaw skills` для виявлення/інсталяції/оновлення або окремий CLI `clawhub` для робочих процесів публікації/синхронізації. Повний посібник: [ClawHub](/uk/tools/clawhub).
+[ClawHub](https://clawhub.ai) — це публічний реєстр навичок для OpenClaw. Використовуйте нативні команди `openclaw skills` для пошуку/інсталяції/оновлення або окремий CLI `clawhub` для робочих процесів публікації/синхронізації. Повний посібник: [ClawHub](/uk/tools/clawhub).
 
 | Дія                                      | Команда                                |
 | ---------------------------------------- | -------------------------------------- |
-| Інсталювати навичку в робочу область     | `openclaw skills install <skill-slug>` |
-| Оновити всі інстальовані навички         | `openclaw skills update --all`         |
-| Синхронізувати (сканувати + публікувати оновлення) | `clawhub sync --all`           |
+| Встановити навичку в робочу область      | `openclaw skills install <skill-slug>` |
+| Оновити всі встановлені навички          | `openclaw skills update --all`         |
+| Синхронізувати (сканувати + опублікувати оновлення) | `clawhub sync --all`          |
 
-Нативна команда `openclaw skills install` інсталює в каталог `skills/` активної робочої області. Окремий CLI `clawhub` також інсталює в `./skills` у вашому поточному робочому каталозі (або повертається до налаштованої робочої області OpenClaw). OpenClaw підхоплює це як `<workspace>/skills` у наступному сеансі.
-Налаштовані корені навичок також підтримують один рівень групування, наприклад `skills/<group>/<skill>/SKILL.md`, тож пов’язані сторонні навички можна зберігати в спільній папці без широкого рекурсивного сканування.
+Нативна команда `openclaw skills install` встановлює в директорію `skills/` активної робочої області. Окремий CLI `clawhub` також встановлює в `./skills` у вашій поточній робочій директорії (або повертається до налаштованої робочої області OpenClaw). OpenClaw підхоплює це як `<workspace>/skills` у наступній сесії. Налаштовані корені навичок також підтримують один рівень групування, наприклад `skills/<group>/<skill>/SKILL.md`, тож пов’язані сторонні навички можна тримати у спільній папці без широкого рекурсивного сканування.
 
-Сторінки навичок ClawHub показують найновіший стан сканування безпеки перед інсталяцією, зі сторінками деталей сканерів для VirusTotal, ClawScan і статичного аналізу. `openclaw skills install <slug>` залишається лише шляхом інсталяції; видавці усувають хибнопозитивні спрацювання через панель ClawHub або `clawhub skill rescan <slug>`.
+Сторінки навичок ClawHub показують найновіший стан безпекового сканування перед інсталяцією, зі сторінками деталей сканерів для VirusTotal, ClawScan і статичного аналізу. `openclaw skills install <slug>` залишається лише шляхом інсталяції; видавці усувають хибнопозитивні спрацювання через панель ClawHub або `clawhub skill rescan <slug>`.
 
 ## Безпека
 
 <Warning>
-Ставтеся до сторонніх навичок як до **недовіреного коду**. Читайте їх перед увімкненням. Надавайте перевагу sandbox-запускам для недовірених вхідних даних і ризикованих інструментів. Див. [Sandboxing](/uk/gateway/sandboxing) щодо засобів керування на боці агента.
+Ставтеся до сторонніх навичок як до **ненадійного коду**. Прочитайте їх перед увімкненням. Для ненадійних вхідних даних і ризикованих інструментів віддавайте перевагу sandbox-запускам. Див. [Sandboxing](/uk/gateway/sandboxing) для елементів керування з боку агента.
 </Warning>
 
-- Виявлення навичок робочої області та додаткових каталогів приймає лише корені навичок і файли `SKILL.md`, чий розв’язаний realpath залишається всередині налаштованого кореня.
-- Інсталяції залежностей навичок через Gateway (`skills.install`, onboarding та інтерфейс налаштувань Skills) запускають вбудований сканер небезпечного коду перед виконанням метаданих інсталятора. Знахідки `critical` блокують за замовчуванням, якщо викликач явно не встановив небезпечне перевизначення; підозрілі знахідки все одно лише попереджають.
+- Виявлення навичок робочої області та extra-dir приймає лише корені навичок і файли `SKILL.md`, чий розв’язаний realpath залишається всередині налаштованого кореня.
+- Встановлення залежностей навичок через Gateway (`skills.install`, onboarding і UI налаштувань Skills) запускають вбудований сканер небезпечного коду перед виконанням метаданих інсталятора. Знахідки `critical` блокуються за замовчуванням, якщо викликач явно не встановив небезпечне перевизначення; підозрілі знахідки все ще лише попереджають.
 - `openclaw skills install <slug>` відрізняється — він завантажує папку навички ClawHub у робочу область і не використовує наведений вище шлях метаданих інсталятора.
-- `skills.entries.*.env` і `skills.entries.*.apiKey` впроваджують секрети в процес **хоста** для цього ходу агента (не в sandbox). Не допускайте потрапляння секретів у prompt і журнали.
+- `skills.entries.*.env` і `skills.entries.*.apiKey` інжектують секрети в **host**-процес для цього ходу агента (не в sandbox). Не допускайте потрапляння секретів у промпти й журнали.
 
-Ширшу модель загроз і чеклісти див. у [Безпека](/uk/gateway/security).
+Для ширшої моделі загроз і чеклістів див. [Безпека](/uk/gateway/security).
 
 ## Формат SKILL.md
 
@@ -133,27 +131,27 @@ description: Generate or edit images via a provider-backed image workflow
 ---
 ```
 
-OpenClaw дотримується специфікації AgentSkills для макета/наміру. Парсер, який використовує вбудований агент, підтримує лише **однорядкові** ключі frontmatter; `metadata` має бути **однорядковим JSON-об’єктом**. Використовуйте `{baseDir}` в інструкціях, щоб посилатися на шлях папки навички.
+OpenClaw дотримується специфікації AgentSkills щодо компонування/наміру. Парсер, який використовується вбудованим агентом, підтримує лише **однорядкові** ключі frontmatter; `metadata` має бути **однорядковим JSON-об’єктом**. Використовуйте `{baseDir}` в інструкціях, щоб посилатися на шлях папки навички.
 
 ### Необов’язкові ключі frontmatter
 
 <ParamField path="homepage" type="string">
-  URL, що відображається як "Website" в інтерфейсі Skills у macOS. Також підтримується через `metadata.openclaw.homepage`.
+  URL, що відображається як "Вебсайт" в UI macOS Skills. Також підтримується через `metadata.openclaw.homepage`.
 </ParamField>
 <ParamField path="user-invocable" type="boolean" default="true">
   Коли `true`, навичка показується як користувацька slash-команда.
 </ParamField>
 <ParamField path="disable-model-invocation" type="boolean" default="false">
-  Коли `true`, навичка вилучається з prompt моделі (все ще доступна через користувацький виклик).
+  Коли `true`, OpenClaw не додає інструкції навички до звичайного промпта агента. Навичка все одно встановлена й усе ще може бути явно запущена як slash-команда, коли `user-invocable` також має значення `true`.
 </ParamField>
 <ParamField path="command-dispatch" type='"tool"'>
-  Коли встановлено `tool`, slash-команда обходить модель і напряму передається інструменту.
+  Коли встановлено `tool`, slash-команда оминає модель і спрямовується безпосередньо до інструмента.
 </ParamField>
 <ParamField path="command-tool" type="string">
-  Назва інструмента для виклику, коли встановлено `command-dispatch: tool`.
+  Назва інструмента, який потрібно викликати, коли встановлено `command-dispatch: tool`.
 </ParamField>
 <ParamField path="command-arg-mode" type='"raw"' default="raw">
-  Для диспетчеризації інструмента передає сирий рядок аргументів інструменту (без core-парсингу). Інструмент викликається з `{ command: "<raw args>", commandName: "<slash command>", skillName: "<skill name>" }`.
+  Для спрямування до інструмента передає сирий рядок аргументів інструменту (без парсингу ядром). Інструмент викликається з `{ command: "<raw args>", commandName: "<slash command>", skillName: "<skill name>" }`.
 </ParamField>
 
 ## Обмеження (фільтри під час завантаження)
@@ -175,19 +173,19 @@ metadata:
 ---
 ```
 
-Поля під `metadata.openclaw`:
+Поля в `metadata.openclaw`:
 
 <ParamField path="always" type="boolean">
-  Коли `true`, завжди включати навичку (пропустити інші обмеження).
+  Коли `true`, завжди включати навичку (пропускати інші обмеження).
 </ParamField>
 <ParamField path="emoji" type="string">
-  Необов’язковий emoji, який використовує інтерфейс Skills у macOS.
+  Необов’язковий emoji, який використовується UI macOS Skills.
 </ParamField>
 <ParamField path="homepage" type="string">
-  Необов’язковий URL, що відображається як "Website" в інтерфейсі Skills у macOS.
+  Необов’язковий URL, що показується як "Вебсайт" в UI macOS Skills.
 </ParamField>
 <ParamField path="os" type='"darwin" | "linux" | "win32"' >
-  Необов’язковий список платформ. Якщо встановлено, навичка придатна лише на цих ОС.
+  Необов’язковий список платформ. Якщо задано, навичка придатна лише на цих ОС.
 </ParamField>
 <ParamField path="requires.bins" type="string[]">
   Кожен має існувати в `PATH`.
@@ -196,31 +194,31 @@ metadata:
   Принаймні один має існувати в `PATH`.
 </ParamField>
 <ParamField path="requires.env" type="string[]">
-  Змінна середовища має існувати або бути надана в конфігурації.
+  Змінна середовища має існувати або бути наданою в конфігурації.
 </ParamField>
 <ParamField path="requires.config" type="string[]">
   Список шляхів `openclaw.json`, які мають бути truthy.
 </ParamField>
 <ParamField path="primaryEnv" type="string">
-  Назва змінної середовища, пов’язана з `skills.entries.<name>.apiKey`.
+  Назва змінної середовища, пов’язаної з `skills.entries.<name>.apiKey`.
 </ParamField>
 <ParamField path="install" type="object[]">
-  Необов’язкові специфікації інсталятора, які використовує інтерфейс Skills у macOS (brew/node/go/uv/download).
+  Необов’язкові специфікації інсталятора, які використовуються UI macOS Skills (brew/node/go/uv/download).
 </ParamField>
 
-Якщо `metadata.openclaw` немає, навичка завжди придатна (якщо її не вимкнено в конфігурації або не заблоковано через `skills.allowBundled` для вбудованих навичок).
+Якщо `metadata.openclaw` відсутній, навичка завжди придатна (якщо її не вимкнено в конфігурації або не заблоковано `skills.allowBundled` для вбудованих навичок).
 
 <Note>
-Застарілі блоки `metadata.clawdbot` досі приймаються, коли `metadata.openclaw` відсутній, тож старіші інстальовані навички зберігають свої обмеження залежностей і підказки інсталятора. Нові й оновлені навички мають використовувати `metadata.openclaw`.
+Застарілі блоки `metadata.clawdbot` усе ще приймаються, коли `metadata.openclaw` відсутній, тож старіші встановлені навички зберігають свої обмеження залежностей і підказки інсталятора. Нові й оновлені навички мають використовувати `metadata.openclaw`.
 </Note>
 
-### Примітки щодо Sandboxing
+### Примітки щодо sandbox
 
-- `requires.bins` перевіряється на **хості** під час завантаження навички.
-- Якщо агент працює в sandbox, бінарний файл також має існувати **всередині контейнера**. Інсталюйте його через `agents.defaults.sandbox.docker.setupCommand` (або власний образ). `setupCommand` виконується один раз після створення контейнера. Інсталяції пакетів також потребують мережевого виходу, доступної для запису кореневої FS і root-користувача в sandbox.
-- Приклад: навичці `summarize` (`skills/summarize/SKILL.md`) потрібен CLI `summarize` у sandbox-контейнері, щоб запускатися там.
+- `requires.bins` перевіряється на **host** під час завантаження навички.
+- Якщо агент працює в sandbox, бінарний файл також має існувати **всередині контейнера**. Встановіть його через `agents.defaults.sandbox.docker.setupCommand` (або користувацький образ). `setupCommand` запускається один раз після створення контейнера. Встановлення пакетів також потребують мережевого виходу, записуваної кореневої FS і користувача root у sandbox.
+- Приклад: навичці `summarize` (`skills/summarize/SKILL.md`) потрібен CLI `summarize` у sandbox-контейнері, щоб працювати там.
 
-### Специфікації інсталятора
+### Специфікації інсталяторів
 
 ```markdown
 ---
@@ -249,24 +247,24 @@ metadata:
 
 <AccordionGroup>
   <Accordion title="Правила вибору інсталятора">
-    - Якщо вказано кілька інсталяторів, gateway вибирає один пріоритетний варіант (brew, коли доступний, інакше node).
-    - Якщо всі інсталятори мають тип `download`, OpenClaw показує кожен запис, щоб ви могли побачити доступні артефакти.
-    - Специфікації інсталяторів можуть містити `os: ["darwin"|"linux"|"win32"]`, щоб фільтрувати варіанти за платформою.
-    - Інсталяції Node враховують `skills.install.nodeManager` в `openclaw.json` (типово: npm; варіанти: npm/pnpm/yarn/bun). Це впливає лише на інсталяцію skills; середовище виконання Gateway все одно має бути Node — Bun не рекомендовано для WhatsApp/Telegram.
-    - Вибір інсталятора на базі Gateway керується пріоритетами: коли специфікації інсталяції змішують типи, OpenClaw віддає перевагу Homebrew, якщо `skills.install.preferBrew` увімкнено і `brew` існує, потім `uv`, потім налаштованому менеджеру node, а тоді іншим резервним варіантам, як-от `go` або `download`.
-    - Якщо кожна специфікація інсталяції має тип `download`, OpenClaw показує всі варіанти завантаження замість того, щоб зводити їх до одного пріоритетного інсталятора.
+    - Якщо вказано кілька інсталяторів, gateway вибирає один пріоритетний варіант (brew, якщо доступний, інакше node).
+    - Якщо всі інсталятори мають тип `download`, OpenClaw показує кожен запис, щоб ви могли бачити доступні артефакти.
+    - Специфікації інсталятора можуть містити `os: ["darwin"|"linux"|"win32"]`, щоб фільтрувати варіанти за платформою.
+    - Інсталяції Node враховують `skills.install.nodeManager` в `openclaw.json` (типово: npm; варіанти: npm/pnpm/yarn/bun). Це впливає лише на встановлення Skills; середовище виконання Gateway усе одно має бути Node — Bun не рекомендовано для WhatsApp/Telegram.
+    - Вибір інсталятора через Gateway керується пріоритетами: коли специфікації інсталяції змішують типи, OpenClaw віддає перевагу Homebrew, якщо `skills.install.preferBrew` увімкнено і `brew` існує, потім `uv`, потім налаштованому менеджеру node, потім іншим резервним варіантам на кшталт `go` або `download`.
+    - Якщо кожна специфікація інсталяції має тип `download`, OpenClaw показує всі варіанти завантаження замість згортання до одного пріоритетного інсталятора.
 
   </Accordion>
   <Accordion title="Деталі для кожного інсталятора">
-    - **Інсталяції Go:** якщо `go` відсутній, а `brew` доступний, gateway спочатку встановлює Go через Homebrew і за можливості встановлює `GOBIN` на `bin` Homebrew.
-    - **Інсталяції через завантаження:** `url` (обов’язково), `archive` (`tar.gz` | `tar.bz2` | `zip`), `extract` (типово: auto, коли виявлено архів), `stripComponents`, `targetDir` (типово: `~/.openclaw/tools/<skillKey>`).
+    - **Інсталяції Go:** якщо `go` відсутній, а `brew` доступний, gateway спочатку встановлює Go через Homebrew і, коли можливо, задає `GOBIN` як `bin` Homebrew.
+    - **Інсталяції завантаженням:** `url` (обов’язково), `archive` (`tar.gz` | `tar.bz2` | `zip`), `extract` (типово: автоматично, коли виявлено архів), `stripComponents`, `targetDir` (типово: `~/.openclaw/tools/<skillKey>`).
 
   </Accordion>
 </AccordionGroup>
 
 ## Перевизначення конфігурації
 
-Вбудовані та керовані skills можна вмикати або вимикати та передавати їм значення env
+Bundled і керовані Skills можна вмикати або вимикати та передавати їм значення env
 у `skills.entries` в `~/.openclaw/openclaw.json`:
 
 ```json5
@@ -292,23 +290,23 @@ metadata:
 ```
 
 <ParamField path="enabled" type="boolean">
-  `false` вимикає skill, навіть якщо він вбудований або встановлений.
-  Вбудований skill `coding-agent` є opt-in: задайте
-  `skills.entries.coding-agent.enabled: true`, перш ніж відкривати його для агентів,
+  `false` вимикає skill, навіть якщо він bundled або встановлений.
+  Bundled skill `coding-agent` є opt-in: задайте
+  `skills.entries.coding-agent.enabled: true`, перш ніж показувати його агентам,
   а потім переконайтеся, що один із `claude`, `codex`, `opencode` або `pi` встановлений і
   автентифікований для власного CLI.
 </ParamField>
 <ParamField path="apiKey" type='string | { source, provider, id }'>
-  Зручний спосіб для skills, які оголошують `metadata.openclaw.primaryEnv`. Підтримує відкритий текст або SecretRef.
+  Зручний параметр для Skills, які оголошують `metadata.openclaw.primaryEnv`. Підтримує відкритий текст або SecretRef.
 </ParamField>
 <ParamField path="env" type="Record<string, string>">
-  Впроваджується лише якщо змінну ще не задано в процесі.
+  Впроваджується лише якщо змінна ще не задана в процесі.
 </ParamField>
 <ParamField path="config" type="object">
-  Необов’язковий контейнер для власних полів окремого skill. Власні ключі мають бути тут.
+  Необов’язковий контейнер для власних полів окремого skill. Власні ключі мають розміщуватися тут.
 </ParamField>
 <ParamField path="allowBundled" type="string[]">
-  Необов’язковий allowlist лише для **вбудованих** skills. Якщо задано, придатними є лише вбудовані skills зі списку (керовані skills і skills робочого простору не зачіпаються).
+  Необов’язковий allowlist лише для **bundled** Skills. Якщо задано, придатними є лише bundled Skills зі списку (керовані/workspace Skills не зачіпаються).
 </ParamField>
 
 Якщо назва skill містить дефіси, візьміть ключ у лапки (JSON5 дозволяє ключі
@@ -316,54 +314,54 @@ metadata:
 визначає `metadata.openclaw.skillKey`, використовуйте цей ключ у `skills.entries`.
 
 <Note>
-Для штатної генерації/редагування зображень всередині OpenClaw використовуйте основний
+Для стандартної генерації/редагування зображень усередині OpenClaw використовуйте основний
 інструмент `image_generate` з `agents.defaults.imageGenerationModel` замість
-вбудованого skill. Приклади skills тут призначені для власних або сторонніх
-робочих процесів. Для нативного аналізу зображень використовуйте інструмент `image` з
+bundled skill. Приклади Skills тут призначені для власних або сторонніх
+workflow. Для нативного аналізу зображень використовуйте інструмент `image` з
 `agents.defaults.imageModel`. Якщо ви вибираєте `openai/*`, `google/*`,
-`fal/*` або іншу модель зображень, специфічну для провайдера, додайте також
-автентифікацію/API-ключ цього провайдера.
+`fal/*` або іншу модель зображень, специфічну для провайдера, також додайте
+ключ автентифікації/API цього провайдера.
 </Note>
 
 ## Впровадження середовища
 
-Коли починається запуск агента, OpenClaw:
+Коли запускається виконання агента, OpenClaw:
 
 1. Читає метадані skill.
 2. Застосовує `skills.entries.<key>.env` і `skills.entries.<key>.apiKey` до `process.env`.
-3. Формує системний промпт із **придатними** skills.
-4. Відновлює початкове середовище після завершення запуску.
+3. Будує системний prompt із **придатними** Skills.
+4. Відновлює початкове середовище після завершення виконання.
 
-Впровадження середовища **обмежене запуском агента**, а не глобальним
-середовищем оболонки.
+Впровадження середовища **обмежене виконанням агента**, а не глобальним
+середовищем shell.
 
-Для вбудованого бекенда `claude-cli` OpenClaw також матеріалізує той самий
+Для bundled бекенда `claude-cli` OpenClaw також матеріалізує той самий
 придатний знімок як тимчасовий Plugin Claude Code і передає його з
-`--plugin-dir`. Claude Code після цього може використовувати власний resolver skills, тоді як
-OpenClaw і надалі керує пріоритетом, allowlist для кожного агента, gating і
+`--plugin-dir`. Claude Code після цього може використовувати свій нативний resolver Skills, тоді як
+OpenClaw і далі керує пріоритетом, allowlist для кожного агента, gating і
 впровадженням env/API-ключів `skills.entries.*`. Інші CLI-бекенди використовують
-лише каталог промптів.
+лише каталог prompt.
 
 ## Знімки та оновлення
 
-OpenClaw робить знімок придатних skills **коли починається сеанс** і
-повторно використовує цей список для наступних ходів у тому самому сеансі. Зміни в
-skills або конфігурації набирають чинності в наступному новому сеансі.
+OpenClaw створює знімок придатних Skills **під час старту session** і
+повторно використовує цей список для наступних turn у тій самій session. Зміни до
+Skills або конфігурації набирають чинності під час наступної нової session.
 
-Skills можуть оновлюватися посеред сеансу у двох випадках:
+Skills можуть оновлюватися посеред session у двох випадках:
 
-- Увімкнено спостерігач skills.
+- Watcher Skills увімкнено.
 - З’являється новий придатний віддалений node.
 
-Сприймайте це як **гаряче перезавантаження**: оновлений список підхоплюється під час
-наступного ходу агента. Якщо ефективний allowlist skills агента змінюється для цього
-сеансу, OpenClaw оновлює знімок, щоб видимі skills лишалися узгодженими
+Сприймайте це як **hot reload**: оновлений список підхоплюється на
+наступному turn агента. Якщо effective allowlist Skills агента змінюється для цієї
+session, OpenClaw оновлює знімок, щоб видимі Skills залишалися узгодженими
 з поточним агентом.
 
-### Спостерігач skills
+### Watcher Skills
 
-Типово OpenClaw спостерігає за папками skills і оновлює знімок skills,
-коли файли `SKILL.md` змінюються. Налаштування в `skills.load`:
+Типово OpenClaw відстежує теки Skills і збільшує знімок Skills,
+коли змінюються файли `SKILL.md`. Налаштуйте в `skills.load`:
 
 ```json5
 {
@@ -376,27 +374,27 @@ Skills можуть оновлюватися посеред сеансу у дв
 }
 ```
 
-### Віддалені вузли macOS (Linux gateway)
+### Віддалені macOS nodes (Linux gateway)
 
-Якщо Gateway працює на Linux, але підключений **вузол macOS** з дозволеним
-`system.run` (безпеку затверджень Exec не встановлено на `deny`),
-OpenClaw може вважати skills лише для macOS придатними, коли потрібні
-бінарні файли присутні на цьому вузлі. Агент має виконувати ці skills
+Якщо Gateway працює на Linux, але підключено **macOS node** з дозволеним
+`system.run` (безпека Exec approvals не встановлена в `deny`),
+OpenClaw може вважати Skills лише для macOS придатними, коли потрібні
+бінарні файли присутні на цьому node. Агент має виконувати ці Skills
 через інструмент `exec` з `host=node`.
 
-Це залежить від того, що вузол повідомляє про підтримку команд, і від перевірки bin
-через `system.which` або `system.run`. Офлайн-вузли **не** роблять
-skills лише для віддаленого виконання видимими. Якщо підключений вузол перестає відповідати на bin
-probes, OpenClaw очищає кешовані збіги bin, щоб агенти більше не бачили
-skills, які наразі не можуть там виконуватися.
+Це залежить від того, що node повідомляє про свою підтримку команд, і від bin probe
+через `system.which` або `system.run`. Offline nodes **не** роблять
+Skills, доступні лише віддалено, видимими. Якщо підключений node перестає відповідати на bin
+probes, OpenClaw очищає кешовані відповідники bin, щоб агенти більше не бачили
+Skills, які наразі не можуть там запускатися.
 
 ## Вплив на токени
 
-Коли skills придатні, OpenClaw впроваджує компактний XML-список доступних
-skills у системний промпт (через `formatSkillsForPrompt` у
+Коли Skills придатні, OpenClaw впроваджує компактний XML-список доступних
+Skills у системний prompt (через `formatSkillsForPrompt` в
 `pi-coding-agent`). Вартість детермінована:
 
-- **Базові накладні витрати** (лише коли skill ≥1): 195 символів.
+- **Базові накладні витрати** (лише коли ≥1 skill): 195 символів.
 - **На skill:** 97 символів + довжина XML-екранованих значень `<name>`, `<description>` і `<location>`.
 
 Формула (символи):
@@ -405,29 +403,29 @@ skills у системний промпт (через `formatSkillsForPrompt` у
 total = 195 + Σ (97 + len(name_escaped) + len(description_escaped) + len(location_escaped))
 ```
 
-XML-екранування розгортає `& < > " '` у сутності (`&amp;`, `&lt;` тощо),
-збільшуючи довжину. Кількість токенів залежить від токенізатора моделі. Груба
-оцінка в стилі OpenAI становить ~4 символи/токен, тож **97 символів ≈ 24 токени** на
-skill плюс фактична довжина ваших полів.
+XML-екранування розгортає `& < > " '` у entities (`&amp;`, `&lt;` тощо),
+збільшуючи довжину. Кількість токенів залежить від токенізатора моделі. Приблизна
+оцінка в стилі OpenAI — ~4 символи/токен, тож **97 символів ≈ 24 токени** на
+skill плюс фактичні довжини ваших полів.
 
-## Життєвий цикл керованих skills
+## Життєвий цикл керованих Skills
 
-OpenClaw постачає базовий набір skills як **вбудовані skills** разом з
+OpenClaw постачає базовий набір Skills як **bundled Skills** разом з
 інсталяцією (npm-пакет або OpenClaw.app). `~/.openclaw/skills` існує для
-локальних перевизначень — наприклад, щоб закріпити або виправити skill без
-зміни вбудованої копії. Skills робочого простору належать користувачу й перевизначають
-обидва джерела за конфлікту назв.
+локальних перевизначень — наприклад, щоб зафіксувати або пропатчити skill без
+зміни bundled копії. Workspace Skills належать користувачу і мають пріоритет
+над обома у разі конфліктів назв.
 
-## Шукаєте більше skills?
+## Шукаєте більше Skills?
 
-Перегляньте [https://clawhub.ai](https://clawhub.ai). Повна схема конфігурації:
+Перегляньте [https://clawhub.ai](https://clawhub.ai). Повна schema конфігурації:
 [Конфігурація Skills](/uk/tools/skills-config).
 
 ## Пов’язане
 
-- [ClawHub](/uk/tools/clawhub) — публічний реєстр skills
-- [Створення skills](/uk/tools/creating-skills) — створення власних skills
+- [ClawHub](/uk/tools/clawhub) — публічний реєстр Skills
+- [Створення Skills](/uk/tools/creating-skills) — створення власних Skills
 - [Plugins](/uk/tools/plugin) — огляд системи plugin
-- [Plugin Skill Workshop](/uk/plugins/skill-workshop) — генерування skills з роботи агента
-- [Конфігурація Skills](/uk/tools/skills-config) — довідник конфігурації skills
+- [Plugin Skill Workshop](/uk/plugins/skill-workshop) — генерування Skills з роботи агента
+- [Конфігурація Skills](/uk/tools/skills-config) — довідник конфігурації skill
 - [Команди зі скісною рискою](/uk/tools/slash-commands) — усі доступні команди зі скісною рискою