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

docs/uk/reference/RELEASING.md

@@ -1,289 +1,284 @@
 ---
 read_when:
-    - Шукаємо визначення публічних каналів випуску
+    - Пошук визначень публічних каналів випуску
     - Запуск валідації релізу або приймання пакета
-    - Шукаємо правила іменування версій і періодичність випусків
-summary: Канали релізів, контрольний список оператора, валідаційні середовища, іменування версій і періодичність
-title: Політика релізів
+    - Шукаєте інформацію про іменування версій і періодичність випусків
+summary: Релізні доріжки, контрольний список оператора, валідаційні бокси, іменування версій і ритм
+title: Політика випусків
 x-i18n:
-    generated_at: "2026-05-02T20:01:31Z"
+    generated_at: "2026-05-02T22:44:57Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 493cb8b42f0e15f3bf5f8fb9be7d01fd626f4f16db9ac0a85e6efa747ef12d12
+    source_hash: ba316d1736eae8edd2fb0a71b9a3da345f8895c3b536e9a1f619718ea12fc851
     source_path: reference/RELEASING.md
     workflow: 16
 ---
 
-OpenClaw має чотири публічні канали випусків:
+OpenClaw має три публічні канали випусків:
 
-- stable: позначені тегами випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
-- alpha: теги попередніх випусків, які публікуються в npm `alpha`
-- beta: теги попередніх випусків, які публікуються в npm `beta`
-- dev: рухома вершина `main`
+- стабільний: теговані випуски, які типово публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
+- бета: теги попередніх випусків, які публікуються в npm `beta`
+- розробницький: рухома голова `main`
 
 ## Іменування версій
 
 - Версія стабільного випуску: `YYYY.M.D`
   - Git-тег: `vYYYY.M.D`
-- Версія коригувального стабільного випуску: `YYYY.M.D-N`
+- Версія стабільного коригувального випуску: `YYYY.M.D-N`
   - Git-тег: `vYYYY.M.D-N`
-- Версія попереднього alpha-випуску: `YYYY.M.D-alpha.N`
-  - Git-тег: `vYYYY.M.D-alpha.N`
-- Версія попереднього beta-випуску: `YYYY.M.D-beta.N`
+- Версія бета-попереднього випуску: `YYYY.M.D-beta.N`
   - Git-тег: `vYYYY.M.D-beta.N`
 - Не доповнюйте місяць або день нулями
-- `latest` означає поточний просунутий стабільний випуск npm
-- `alpha` означає поточну ціль встановлення alpha
-- `beta` означає поточну ціль встановлення beta
-- Стабільні та коригувальні стабільні випуски за замовчуванням публікуються в npm `beta`; оператори випуску можуть явно вибрати `latest` або пізніше просунути перевірену beta-збірку
-- Кожен стабільний випуск OpenClaw постачається разом із npm-пакетом і застосунком macOS;
-  beta-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а
-  збирання/підписування/нотаризацію застосунку Mac залишають для стабільного випуску, якщо це не запитано явно
+- `latest` означає поточний підвищений стабільний npm-випуск
+- `beta` означає поточну ціль встановлення бета-версії
+- Стабільні та стабільні коригувальні випуски типово публікуються в npm `beta`; оператори випуску можуть явно націлити `latest` або пізніше підвищити перевірену бета-збірку
+- Кожен стабільний випуск OpenClaw постачається разом із npm-пакетом і застосунком для macOS;
+  бета-випуски зазвичай спершу перевіряють і публікують шлях npm/пакета, а
+  збирання/підписування/нотаризацію застосунку для Mac залишають для стабільного випуску, якщо це не запитано явно
 
-## Періодичність випусків
+## Каденція випусків
 
-- Випуски рухаються спочатку через beta
-- Стабільний випуск іде лише після перевірки останньої beta
-- Мейнтейнери зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної
-  з поточної `main`, щоб перевірка випуску й виправлення не блокували нову
+- Випуски рухаються спершу через бета-версію
+- Стабільний випуск виходить лише після перевірки останньої бета-версії
+- Супровідники зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної
+  з поточної `main`, щоб перевірка випуску та виправлення не блокували нову
   розробку в `main`
-- Якщо beta-тег уже надіслано або опубліковано й він потребує виправлення, мейнтейнери створюють
-  наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега
-- Докладна процедура випуску, затвердження, облікові дані та нотатки щодо відновлення
-  доступні лише мейнтейнерам
+- Якщо бета-тег уже було надіслано або опубліковано й він потребує виправлення, супровідники створюють
+  наступний тег `-beta.N` замість видалення або повторного створення старого бета-тега
+- Детальна процедура випуску, затвердження, облікові дані та примітки щодо відновлення
+  призначені лише для супровідників
 
 ## Контрольний список оператора випуску
 
-Цей контрольний список є публічною формою процесу випуску. Приватні облікові дані,
+Цей контрольний список описує публічну форму процесу випуску. Приватні облікові дані,
 підписування, нотаризація, відновлення dist-tag і деталі аварійного відкату залишаються в
-інструкції з випуску, доступній лише мейнтейнерам.
+інструкції з випуску лише для супровідників.
 
 1. Почніть із поточної `main`: отримайте останні зміни, підтвердьте, що цільовий коміт надіслано,
-   і підтвердьте, що поточний CI `main` достатньо зелений, щоб створити від нього гілку.
+   і підтвердьте, що поточний CI для `main` достатньо зелений, щоб створювати від нього гілку.
 2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою
-   `/changelog`, залишайте записи орієнтованими на користувача, закомітьте його, надішліть його та виконайте rebase/pull
-   ще раз перед створенням гілки.
+   `/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 мали спільну версію випуску
-   й метадані сумісності, потім запустіть локальну детерміновану попередню перевірку:
+   `pnpm plugins:sync`, щоб опубліковані пакети Plugin мали спільну версію випуску
+   та метадані сумісності, а потім запустіть локальну детерміновану попередню перевірку:
    `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 гілки випуску дозволено для попередньої перевірки лише з метою
-   валідації. Збережіть успішний `preflight_run_id`.
-7. Запустіть усі передрелізні тести за допомогою `Full Release Validation` для
+6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До існування тега
+   повний 40-символьний SHA гілки випуску дозволено для попередньої перевірки лише з метою валідації.
+   Збережіть успішний `preflight_run_id`.
+7. Запустіть усі передрелізні тести через `Full Release Validation` для
    гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу
-   для чотирьох великих тестових боксів випуску: Vitest, Docker, QA Lab і Package.
-8. Якщо перевірка не проходить, виправте в гілці випуску й повторно запустіть найменший невдалий
-   файл, канал, завдання workflow, профіль пакета, провайдера або allowlist моделей, який
-   доводить виправлення. Повторно запускайте повну обгортку лише тоді, коли змінена поверхня робить
+   для чотирьох великих тестових середовищ випуску: Vitest, Docker, QA Lab і Package.
+8. Якщо валідація не проходить, виправте в гілці випуску та повторно запустіть найменший невдалий
+   файл, канал, завдання workflow, профіль пакета, провайдера або allowlist моделі, що
+   доводить виправлення. Повторно запускайте весь umbrella лише тоді, коли змінена поверхня робить
    попередні докази застарілими.
-9. Для alpha або beta позначте тегом `vYYYY.M.D-alpha.N` або `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з
+9. Для бета-версії створіть тег `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з
    відповідної гілки `release/YYYY.M.D`. Він перевіряє `pnpm plugins:sync:check`,
-   спочатку публікує всі придатні до публікації пакети Plugin в npm, другим кроком публікує той самий
-   набір у ClawHub, а потім просуває підготовлений артефакт попередньої перевірки OpenClaw npm
+   спершу публікує всі опубліковані пакети Plugin в npm, потім публікує той самий
+   набір у ClawHub, а далі підвищує підготовлений артефакт попередньої перевірки OpenClaw npm
    з відповідним dist-tag. Після публікації запустіть післяпублікаційне приймання пакета
-   для опублікованого пакета `openclaw@YYYY.M.D-alpha.N`, `openclaw@alpha`,
-   `openclaw@YYYY.M.D-beta.N` або `openclaw@beta`. Якщо надісланий або
-   опублікований попередній випуск потребує виправлення, створіть наступний відповідний номер попереднього випуску;
-   не видаляйте й не переписуйте старий попередній випуск.
-10. Для stable продовжуйте лише після того, як перевірена beta або реліз-кандидат матиме
-    потрібні докази перевірки. Публікація стабільного npm також проходить через
+   для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або
+   `openclaw@beta`. Якщо надісланий або опублікований попередній випуск потребує виправлення,
+   створіть наступний відповідний номер попереднього випуску; не видаляйте й не переписуйте старий
+   попередній випуск.
+10. Для стабільного випуску продовжуйте лише після того, як перевірена бета-версія або реліз-кандидат матиме
+    потрібні докази валідації. Публікація стабільного npm також проходить через
     `OpenClaw Release Publish`, повторно використовуючи успішний артефакт попередньої перевірки через
-    `preflight_run_id`; готовність стабільного випуску macOS також потребує
+    `preflight_run_id`; готовність стабільного випуску для macOS також вимагає наявності
     упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`.
-11. Після публікації запустіть післяпублікаційний перевірник npm, необов’язковий окремий
-    E2E Telegram для опублікованого npm, коли потрібен післяпублікаційний доказ каналу,
-    просування dist-tag за потреби, нотатки GitHub release/prerelease з
+11. Після публікації запустіть післяпублікаційний перевіряльник npm, необов’язковий автономний
+    E2E для опублікованого npm Telegram, коли потрібен післяпублікаційний доказ каналу,
+    підвищення dist-tag за потреби, нотатки GitHub release/prerelease з
     повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску.
 
 ## Попередня перевірка випуску
 
-- Запустіть `pnpm check:test-types` перед release preflight, щоб тестовий TypeScript залишався
-  покритим поза швидшим локальним gate `pnpm check`
-- Запустіть `pnpm check:architecture` перед release preflight, щоб ширші перевірки циклів
-  імпорту та архітектурних меж були зеленими поза швидшим локальним gate
+- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався
+  покритим поза швидшим локальним шлюзом `pnpm check`
+- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів
+  імпорту та архітектурних меж були зеленими поза швидшим локальним шлюзом
 - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
-  release-артефакти `dist/*` і bundle Control UI існували для кроку
-  перевірки пакування
-- Запустіть `pnpm plugins:sync` після підняття root-версії та перед тегуванням. Він
-  оновлює версії publishable пакетів Plugin, metadata сумісності peer/API
-  OpenClaw, build metadata і заглушки changelog Plugin, щоб вони відповідали core
-  release version. `pnpm plugins:sync:check` є немутуючим release guard;
-  publish workflow завершується помилкою перед будь-якою мутацією registry, якщо цей крок
-  забули.
-- Запустіть ручний workflow `Full Release Validation` перед release approval, щоб
-  запустити всі pre-release test boxes з одного entrypoint. Він приймає branch,
-  tag або повний commit SHA, dispatch-ить ручний `CI` і dispatch-ить
-  `OpenClaw Release Checks` для install smoke, package acceptance, Docker
-  release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram
+  артефакти релізу `dist/*` і пакет Control UI існували для кроку перевірки
+  пакування
+- Запустіть `pnpm plugins:sync` після підняття версії в корені та перед тегуванням. Він
+  оновлює версії пакетів публіковних plugin, метадані сумісності OpenClaw peer/API,
+  метадані збірки та заготовки журналів змін plugin відповідно до версії основного
+  релізу. `pnpm plugins:sync:check` є незмінювальним релізним запобіжником;
+  workflow публікації завершується помилкою перед будь-якою зміною реєстру, якщо цей крок було
+  забуто.
+- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб
+  запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку,
+  тег або повний SHA коміту, запускає ручний `CI` і запускає
+  `OpenClaw Release Checks` для smoke-перевірки встановлення, приймання пакета, наборів
+  release-path Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram
   lanes. З `release_profile=full` і `rerun_group=all` він також запускає package
-  Telegram E2E проти артефакту `release-package-under-test` з release
-  checks. Надайте `npm_telegram_package_spec` після publishing, коли той самий
-  Telegram E2E має також довести опублікований npm package. Надайте
-  `package_acceptance_package_spec` після publishing, коли Package Acceptance
-  має запускати свою package/update matrix проти shipped npm package замість
-  SHA-built artifact. Надайте
-  `evidence_package_spec`, коли приватний evidence report має довести, що
-  validation відповідає published npm package, не примушуючи Telegram E2E.
+  Telegram E2E проти артефакту `release-package-under-test` із перевірок релізу.
+  Надайте `npm_telegram_package_spec` після публікації, коли той самий
+  Telegram E2E також має підтвердити опублікований npm-пакет. Надайте
+  `package_acceptance_package_spec` після публікації, коли Package Acceptance
+  має запускати свою матрицю пакетів/оновлень проти доставленого 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 proof
-  для package candidate, поки release work триває. Використовуйте `source=npm` для
-  `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` або точної release version; `source=ref`
-  щоб запакувати довірену `package_ref` branch/tag/SHA з поточним
-  `workflow_ref` harness; `source=url` для HTTPS tarball з обов’язковим
-  SHA-256; або `source=artifact` для tarball, завантаженого іншим GitHub
-  Actions run. Workflow resolved candidate до
-  `package-under-test`, повторно використовує Docker E2E release scheduler проти цього
+- Запустіть ручний workflow `Package Acceptance`, коли потрібен доказ стороннім каналом
+  для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для
+  `openclaw@beta`, `openclaw@latest` або точної версії релізу; `source=ref`
+  для пакування довіреної гілки/тега/SHA `package_ref` з поточним
+  каркасом `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим
+  SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском
+  GitHub Actions. Workflow зіставляє кандидата з
+  `package-under-test`, повторно використовує планувальник Docker E2E release проти цього
   tarball і може запускати Telegram QA проти того самого tarball з
-  `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли
-  вибрані Docker lanes містять `published-upgrade-survivor`, package
-  artifact є candidate, а `published_upgrade_survivor_baseline` вибирає
-  published baseline.
+  `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані
+  Docker lanes містять `published-upgrade-survivor`, артефакт пакета є кандидатом, а
+  `published_upgrade_survivor_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`
-  Поширені profiles:
-  - `smoke`: lanes install/channel/agent, gateway network і config reload
-  - `package`: package/update/plugin lanes, нативні для artifact, без OpenWebUI або live ClawHub
-  - `product`: package profile плюс MCP channels, cron/subagent cleanup,
-    OpenAI web search і OpenWebUI
-  - `full`: Docker release-path chunks з OpenWebUI
-  - `custom`: точний вибір `docker_lanes` для focused rerun
-- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI
-  coverage для release candidate. Ручні CI dispatches bypass-ять 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
-  lanes.
+  Поширені профілі:
+  - `smoke`: lanes встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації
+  - `package`: lanes пакета/оновлення/plugin, нативні для артефакту, без OpenWebUI або live ClawHub
+  - `product`: профіль package плюс MCP-канали, очищення cron/subagent,
+    вебпошук OpenAI і OpenWebUI
+  - `full`: фрагменти Docker release-path з OpenWebUI
+  - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску
+- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI
+  для кандидата релізу. Ручні запуски CI обходять changed scoping і примусово запускають
+  Linux Node shards, shards bundled-plugin, контрактні перевірки каналів,
+  сумісність Node 22, `check`, `check-additional`, smoke-збірку,
+  перевірки документації, Python skills, Windows, macOS, Android і lanes i18n
+  Control UI.
   Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D`
-- Запустіть `pnpm qa:otel:smoke` під час validation release telemetry. Він перевіряє
-  QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані trace
-  span names, bounded attributes і redaction content/identifier без
-  потреби в Opik, Langfuse або іншому external collector.
-- Запускайте `pnpm release:check` перед кожним tagged release
-- Запустіть `OpenClaw Release Publish` для мутуючої publish sequence після того, як
-  tag існує. Dispatch-те його з `release/YYYY.M.D` (або `main`, коли publishing
-  main-reachable tag), передайте release tag і successful OpenClaw npm
-  `preflight_run_id`, і залишайте default Plugin publish scope
-  `all-publishable`, якщо ви навмисно не запускаєте focused repair. Workflow
-  серіалізує Plugin npm publish, Plugin ClawHub publish і OpenClaw
-  npm publish, щоб core package не було опубліковано перед його externalized
-  plugins.
-- Release checks тепер запускаються в окремому ручному workflow:
+- Запустіть `pnpm qa:otel:smoke` під час перевірки релізної телеметрії. Він проганяє
+  QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace
+  span, обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в
+  Opik, Langfuse або іншому зовнішньому collector.
+- Запускайте `pnpm release:check` перед кожним тегованим релізом
+- Запустіть `OpenClaw Release Publish` для послідовності змінювальної публікації після того, як
+  тег існує. Запускайте його з `release/YYYY.M.D` (або `main`, коли публікується
+  тег, досяжний з main), передайте тег релізу та успішний OpenClaw npm
+  `preflight_run_id`, і залишайте типовий обсяг публікації plugin
+  `all-publishable`, якщо навмисно не запускаєте сфокусоване виправлення. Workflow
+  серіалізує публікацію plugin npm, публікацію plugin ClawHub і публікацію OpenClaw
+  npm, щоб основний пакет не було опубліковано раніше за його зовнішні
+  plugin.
+- Перевірки релізу тепер виконуються в окремому ручному workflow:
   `OpenClaw Release Checks`
-- `OpenClaw Release Checks` також запускає QA Lab mock parity lane плюс швидкий
-  live Matrix profile і Telegram QA lane перед release approval. Live
-  lanes використовують environment `qa-live-shared`; Telegram також використовує Convex CI
-  credential leases. Запустіть ручний workflow `QA-Lab - All Lanes` з
-  `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний Matrix
-  transport, media та E2EE inventory паралельно.
-- Cross-OS install і upgrade runtime validation є частиною public
-  `OpenClaw Release Checks` і `Full Release Validation`, які викликають
-  reusable workflow
-  `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` напряму
-- Цей поділ навмисний: тримайте реальний npm release path коротким,
-  deterministic і artifact-focused, тоді як повільніші live checks залишаються у своїй
-  власній lane, щоб вони не затримували або не блокували publish
-- Release checks із secret слід dispatch-ити через `Full Release
-Validation` або з workflow ref `main`/release, щоб workflow logic і
-  secrets залишалися контрольованими
-- `OpenClaw Release Checks` приймає branch, tag або повний commit SHA, доки
-  resolved commit reachable з OpenClaw branch або release tag
-- validation-only preflight `OpenClaw NPM Release` також приймає поточний
-  повний 40-символьний workflow-branch commit SHA без вимоги pushed tag
-- Цей SHA path є лише validation-only і не може бути promoted у реальний publish
-- У SHA mode workflow синтезує `v<package.json version>` лише для
-  перевірки package metadata; реальний publish усе ще потребує реального release tag
-- Обидва workflows тримають реальний publish і promotion path на GitHub-hosted
-  runners, тоді як немутуючий validation path може використовувати більші
+- `OpenClaw Release Checks` також запускає lane паритету QA Lab mock плюс швидкий
+  live-профіль Matrix і lane Telegram QA перед схваленням релізу. Live
+  lanes використовують середовище `qa-live-shared`; Telegram також використовує оренди облікових даних Convex CI.
+  Запустіть ручний workflow `QA-Lab - All Lanes` з
+  `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix
+  transport, media та E2EE паралельно.
+- Cross-OS перевірка встановлення та оновлення runtime є частиною публічних
+  `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають
+  повторно використовуваний workflow
+  `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
+- Цей поділ навмисний: тримайте справжній шлях npm-релізу коротким,
+  детермінованим і сфокусованим на артефактах, тоді як повільніші live-перевірки залишаються у власному
+  lane, щоб вони не затримували й не блокували публікацію
+- Релізні перевірки з секретами слід запускати через `Full Release
+Validation` або з workflow ref `main`/release, щоб логіка workflow і
+  секрети залишалися контрольованими
+- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, доки
+  зіставлений коміт досяжний з гілки OpenClaw або релізного тега
+- Передрелізна перевірка лише для валідації `OpenClaw NPM Release` також приймає поточний
+  повний 40-символьний SHA коміту workflow-branch без вимоги надісланого тега
+- Цей шлях SHA призначений лише для валідації та не може бути підвищений до реальної публікації
+- У режимі SHA workflow синтезує `v<package.json version>` лише для
+  перевірки метаданих пакета; реальна публікація все ще потребує справжнього релізного тега
+- Обидва workflow залишають шлях реальної публікації та просування на 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
+- Передрелізна перевірка npm-релізу більше не чекає на окремий lane release checks
 - Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
-  (або відповідний beta/correction tag) перед approval
-- Після npm publish запустіть
+  (або відповідний beta/correction tag) перед схваленням
+- Після публікації npm запустіть
   `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  (або відповідну beta/correction version), щоб перевірити published registry
-  install path у свіжому temp prefix
+  (або відповідну beta/correction version), щоб перевірити шлях встановлення з опублікованого реєстру
+  у свіжому тимчасовому prefix
 - Після 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 setup і реальний Telegram E2E
-  проти published npm package із використанням shared leased Telegram credential
-  pool. Локальні одноразові maintainer-запуски можуть omit-ити Convex vars і передати три
+  щоб перевірити onboarding встановленого пакета, налаштування Telegram і справжній Telegram E2E
+  проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних Telegram.
+  Локальні одноразові запуски maintainer можуть опускати Convex vars і передавати три
   env credentials `OPENCLAW_QA_TELEGRAM_*` напряму.
-- Maintainers можуть запускати той самий post-publish check з GitHub Actions через
-  ручний workflow `NPM Telegram Beta E2E`. Він навмисно manual-only і
-  не запускається на кожному merge.
-- Maintainer release automation тепер використовує preflight-then-promote:
-  - реальний npm publish має пройти successful npm `preflight_run_id`
-  - реальний npm publish має бути dispatched з тієї самої branch `main` або
-    `release/YYYY.M.D`, що й successful preflight run
-  - stable npm releases за замовчуванням використовують `beta`
-  - stable npm publish може target-ити `latest` явно через workflow input
-  - token-based npm dist-tag mutation тепер живе в
+- Maintainer можуть запускати ту саму післяпублікаційну перевірку з GitHub Actions через
+  ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
+  не запускається під час кожного merge.
+- Автоматизація релізів maintainer тепер використовує preflight-then-promote:
+  - реальна npm-публікація має пройти успішний npm `preflight_run_id`
+  - реальна npm-публікація має бути запущена з тієї самої гілки `main` або
+    `release/YYYY.M.D`, що й успішний preflight run
+  - стабільні npm-релізи типово йдуть у `beta`
+  - стабільна npm-публікація може явно націлюватися на `latest` через workflow input
+  - token-based зміна npm dist-tag тепер живе в
     `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
-    для безпеки, тому що `npm dist-tag add` все ще потребує `NPM_TOKEN`, тоді як
-    public repo зберігає OIDC-only publish
-  - public `macOS Release` є validation-only; коли tag існує лише на
-    release branch, але workflow dispatched з `main`, встановіть
+    з міркувань безпеки, бо `npm dist-tag add` все ще потребує `NPM_TOKEN`, тоді як
+    публічний репозиторій зберігає публікацію лише через OIDC
+  - публічний `macOS Release` призначений лише для валідації; коли тег існує лише в
+    release branch, але workflow запускається з `main`, встановіть
     `public_release_branch=release/YYYY.M.D`
-  - реальний private mac publish має пройти successful private mac
+  - справжня приватна публікація mac має пройти успішні private mac
     `preflight_run_id` і `validate_run_id`
-  - реальні publish paths promote-ять prepared artifacts замість повторного
-    rebuild
-- Для stable correction releases на кшталт `YYYY.M.D-N`, post-publish verifier
-  також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`,
-  щоб release corrections не могли непомітно залишити older global installs на
-  base stable payload
-- npm release preflight fails closed, якщо tarball не містить одночасно
-  `dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`,
-  щоб ми знову не shipped порожній browser dashboard
-- Post-publish verification також перевіряє, що published Plugin entrypoints і
-  package metadata присутні в installed registry layout. Release, який
-  ships missing Plugin runtime payloads, провалює postpublish verifier і
-  не може бути promoted до `latest`.
-- `pnpm test:install:smoke` також примусово перевіряє npm pack `unpackedSize` budget на
-  candidate update tarball, тому installer e2e ловить accidental pack bloat
-  перед release publish path
-- Якщо release work зачепила CI planning, extension timing manifests або
-  extension test matrices, regenerate і review planner-owned
-  `plugin-prerelease-extension-shard` matrix outputs з
-  `.github/workflows/plugin-prerelease.yml` перед approval, щоб release notes не
-  описували stale CI layout
-- Stable macOS release readiness також включає updater surfaces:
-  - GitHub release має врешті містити packaged `.zip`, `.dmg` і `.dSYM.zip`
-  - `appcast.xml` на `main` має вказувати на новий stable zip після publish
-  - packaged app має зберігати non-debug bundle id, non-empty Sparkle feed
-    URL і `CFBundleVersion` на рівні або вище canonical Sparkle build floor
-    для цієї release version
+  - шляхи реальної публікації просувають підготовлені артефакти замість повторної
+    їх збірки
+- Для стабільних корекційних релізів на кшталт `YYYY.M.D-N` післяпублікаційний verifier
+  також перевіряє той самий шлях оновлення temp-prefix з `YYYY.M.D` до `YYYY.M.D-N`,
+  щоб корекції релізу не могли непомітно залишити старіші глобальні встановлення на
+  базовому стабільному payload
+- Передрелізна перевірка npm-релізу завершується помилкою за замовчуванням, якщо tarball не містить і
+  `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`,
+  щоб ми знову не доставили порожню browser dashboard
+- Післяпублікаційна перевірка також перевіряє, що опубліковані entrypoints plugin і
+  метадані пакета присутні в установленому макеті реєстру. Реліз, який
+  доставляє відсутні runtime payloads plugin, провалює postpublish verifier і
+  не може бути просунутий до `latest`.
+- `pnpm test:install:smoke` також забезпечує бюджет npm pack `unpackedSize` для
+  кандидатного tarball оновлення, щоб installer e2e ловив випадкове роздуття пакета
+  перед шляхом публікації релізу
+- Якщо релізна робота зачепила планування CI, timing manifests plugin або
+  матриці тестів plugin, перегенеруйте та перегляньте outputs матриці
+  `plugin-prerelease-extension-shard`, що належить planner, з
+  `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не
+  описували застарілий макет CI
+- Готовність стабільного macOS-релізу також включає поверхні updater:
+  - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
+  - `appcast.xml` на `main` має вказувати на новий stable zip після публікації
+  - запакований app має зберігати non-debug bundle id, непорожній Sparkle feed
+    URL і `CFBundleVersion` на рівні або вище канонічного нижнього порога Sparkle build
+    для цієї версії релізу
 
-## Release test boxes
+## Релізні тестові бокси
 
-`Full Release Validation` — це спосіб, яким operators запускають усі pre-release tests з
-одного entrypoint. Для pinned commit proof на швидко змінюваній branch використовуйте
-helper, щоб кожен child workflow запускався з тимчасової branch, зафіксованої на target
+`Full Release Validation` — це спосіб, яким operators запускають усі передрелізні тести з
+однієї точки входу. Для доказу pinned commit на гілці, що швидко рухається, використовуйте
+helper, щоб кожен дочірній workflow запускався з тимчасової гілки, зафіксованої на цільовому
 SHA:
 
 ```bash
 pnpm ci:full-release --sha <full-sha>
 ```
 
-Helper pushes `release-ci/<sha>-...`, dispatch-ить `Full Release Validation`
-з цієї branch з `ref=<sha>`, перевіряє, що кожен child workflow `headSha`
-відповідає target, а потім видаляє тимчасову branch. Це запобігає випадковому доведенню
-новішого child run `main`.
+Helper надсилає `release-ci/<sha>-...`, запускає `Full Release Validation`
+з цієї гілки з `ref=<sha>`, перевіряє, що кожен дочірній workflow `headSha`
+збігається з цільовим, а потім видаляє тимчасову гілку. Це запобігає випадковому
+доведенню новішого дочірнього запуску `main`.
 
-Для validation release branch або tag запустіть його з trusted workflow
-ref `main` і передайте release branch або tag як `ref`:
+Для валідації release branch або tag запускайте його з довіреного workflow
+ref `main` і передавайте release branch або tag як `ref`:
 
 ```bash
 gh workflow run full-release-validation.yml \
@@ -295,44 +290,44 @@ gh workflow run full-release-validation.yml \
   -f evidence_package_spec=openclaw@YYYY.M.D-beta.N
 ```
 
-Робочий процес визначає цільовий ref, запускає вручну `CI` з
+Робочий процес визначає цільовий ref, запускає manual `CI` з
 `target_ref=<release-ref>`, запускає `OpenClaw Release Checks` і запускає
-окремий пакетний Telegram E2E, коли `release_profile=full` з
-`rerun_group=all` або коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release
-Checks` розгалужується на install smoke, кросплатформні перевірки релізу, live/E2E Docker
-покриття release-path, Package Acceptance з QA пакета Telegram, QA Lab
+окремий 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` також має бути успішним; поза full/all він пропускається,
 якщо не було надано опублікований `npm_telegram_package_spec`. Фінальне
-зведення verifier містить таблиці найповільніших jobs для кожного дочірнього запуску,
-щоб менеджер релізу міг бачити поточний критичний шлях без завантаження логів.
-Див. [Повна перевірка релізу](/uk/reference/full-release-validation), щоб переглянути
-повну матрицю етапів, точні назви workflow jobs, відмінності між профілями stable і full,
-артефакти та handles для сфокусованого повторного запуску.
-Дочірні workflows запускаються з довіреного ref, який виконує `Full Release
-Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` указує на
-старішу release branch або tag. Окремого workflow-ref input для Full Release Validation
+зведення verifier містить таблиці найповільніших job для кожного дочірнього запуску, щоб release
+manager міг бачити поточний критичний шлях без завантаження журналів.
+Див. [Повна валідація релізу](/uk/reference/full-release-validation) для
+повної матриці етапів, точних назв workflow job, відмінностей між stable і full profile,
+артефактів і ручок для focused rerun.
+Дочірні workflow запускаються з довіреного ref, який виконує `Full Release
+Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на
+старішу release branch або tag. Окремого input для workflow-ref Full Release Validation
 немає; вибирайте довірений harness, вибираючи ref запуску workflow.
-Не використовуйте `--ref main -f ref=<sha>` для exact commit proof на рухомому `main`;
-сирі commit SHA не можуть бути refs для workflow dispatch, тому використовуйте
+Не використовуйте `--ref main -f ref=<sha>` для доказу exact commit на рухомій `main`;
+raw commit SHA не можуть бути workflow dispatch refs, тому використовуйте
 `pnpm ci:full-release --sha <sha>`, щоб створити закріплену тимчасову branch.
 
 Використовуйте `release_profile`, щоб вибрати ширину live/provider:
 
 - `minimum`: найшвидший release-critical OpenAI/core live і Docker path
-- `stable`: minimum плюс stable provider/backend coverage для затвердження релізу
-- `full`: stable плюс широке advisory provider/media coverage
+- `stable`: minimum плюс stable provider/backend coverage для схвалення релізу
+- `full`: stable плюс broad advisory provider/media coverage
 
-`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз визначити цільовий
-ref як `release-package-under-test`, і повторно використовує цей artifact як у
-release-path Docker checks, так і в Package Acceptance. Це тримає всі
-package-facing boxes на тих самих байтах і уникає повторних package builds.
-Кросплатформний OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли
-задано repo/org variable, інакше `openai/gpt-5.4`, бо цей lane
-перевіряє package install, onboarding, запуск gateway і один live agent turn,
-а не вимірює продуктивність найповільнішої default model. Ширша live provider
+`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз визначити target
+ref як `release-package-under-test`, і повторно використовує цей артефакт у
+release-path Docker checks і Package Acceptance. Це тримає всі
+package-facing boxes на тих самих bytes і уникає повторних package builds.
+Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли
+задано repo/org variable, інакше `openai/gpt-5.4`, тому що ця lane
+доводить package install, onboarding, gateway startup і один live agent turn,
+а не benchmark найповільнішої default model. Ширша live provider
 matrix залишається місцем для model-specific coverage.
 
 Використовуйте ці варіанти залежно від етапу релізу:
@@ -365,40 +360,40 @@ gh workflow run full-release-validation.yml \
   -f npm_telegram_provider_mode=mock-openai
 ```
 
-Не використовуйте повну umbrella як перший повторний запуск після сфокусованого виправлення. Якщо один box
+Не використовуйте повну umbrella як перший rerun після focused fix. Якщо один box
 падає, використовуйте failed child workflow, job, Docker lane, package profile, model
-provider або QA lane для наступного proof. Запускайте повну umbrella знову лише тоді,
-коли виправлення змінило спільну release orchestration або зробило попередній all-box evidence
-застарілим. Фінальний verifier umbrella повторно перевіряє записані child workflow run
-ids, тому після успішного повторного запуску child workflow повторно запускайте лише failed
-батьківський job `Verify full validation`.
+provider або QA lane для наступного proof. Запускайте повну umbrella знову лише тоді, коли
+fix змінив спільну release orchestration або зробив попередні all-box evidence
+застарілими. Фінальний verifier umbrella повторно перевіряє записані child workflow run
+ids, тому після успішного rerun дочірнього workflow повторно запускайте лише failed
+parent job `Verify full validation`.
 
-Для обмеженого відновлення передайте `rerun_group` в umbrella. `all` — це справжній
+Для обмеженого recovery передайте `rerun_group` в umbrella. `all` — це справжній
 release-candidate run, `ci` запускає лише normal CI child, `plugin-prerelease`
 запускає лише release-only plugin child, `release-checks` запускає кожен release
 box, а вужчі release groups — це `install-smoke`, `cross-os`,
 `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`.
-Сфокусовані `npm-telegram` reruns потребують `npm_telegram_package_spec`; full/all runs
-з `release_profile=full` використовують package artifact з release-checks.
+Focused `npm-telegram` reruns потребують `npm_telegram_package_spec`; full/all runs
+з `release_profile=full` використовують release-checks package artifact.
 
 ### Vitest
 
-Vitest box — це дочірній workflow ручного `CI`. Ручний CI навмисно
-оминає changed scoping і примусово запускає звичайний test graph для release
+Vitest box — це manual `CI` child workflow. Manual CI навмисно
+обходить changed scoping і примусово запускає normal test graph для 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, щоб відповісти на питання: «чи пройшло source tree повний звичайний test suite?»
-Це не те саме, що release-path product validation. Evidence, який варто зберегти:
+Використовуйте цей box, щоб відповісти: "чи source tree пройшов full normal test suite?"
+Це не те саме, що release-path product validation. Evidence, які слід зберегти:
 
 - зведення `Full Release Validation`, що показує URL запущеного `CI` run
 - зелений `CI` run на точному target SHA
-- назви failed або slow shards з CI jobs під час розслідування regressions
+- назви failed або slow shard з CI jobs під час розслідування regressions
 - Vitest timing artifacts, як-от `.artifacts/vitest-shard-timings.json`, коли
   run потребує performance analysis
 
-Запускайте ручний CI напряму лише тоді, коли релізу потрібен deterministic normal CI, але
+Запускайте manual CI напряму лише тоді, коли релізу потрібен deterministic normal CI, але
 не Docker, QA Lab, live, cross-OS або package boxes:
 
 ```bash
@@ -409,14 +404,14 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
 
 Docker box живе в `OpenClaw Release Checks` через
 `openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode
-workflow `install-smoke`. Він перевіряє release candidate через packaged
+`install-smoke` workflow. Він валідує 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
+- full install smoke з увімкненим повільним Bun global install smoke
+- підготовку/повторне використання root Dockerfile smoke image за target SHA, із QR,
+  root/gateway та installer/Bun smoke jobs, що запускаються як окремі install-smoke
   shards
 - repository E2E lanes
 - release-path Docker chunks: `core`, `package-update-openai`,
@@ -426,60 +421,60 @@ Release Docker coverage включає:
   `plugins-runtime-install-c`, `plugins-runtime-install-d`,
   `plugins-runtime-install-e`, `plugins-runtime-install-f`,
   `plugins-runtime-install-g` і `plugins-runtime-install-h`
-- OpenWebUI coverage всередині chunk `plugins-runtime-services`, коли запитано
+- 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 artifacts перед rerun. Release-path scheduler завантажує
 `.artifacts/docker-tests/` з lane logs, `summary.json`, `failures.json`,
-phase timings, scheduler plan JSON і rerun commands. Для сфокусованого відновлення
+phase timings, scheduler plan JSON і rerun commands. Для focused recovery
 використовуйте `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow замість
-повторного запуску всіх release chunks. Згенеровані rerun commands містять попередні
-`package_artifact_run_id` і prepared Docker image inputs, коли доступні, щоб
-failed lane міг повторно використати той самий tarball і GHCR images.
+повторного запуску всіх release chunks. Generated rerun commands включають попередні
+`package_artifact_run_id` і prepared Docker image inputs, коли вони доступні, щоб
+failed lane могла повторно використати той самий tarball і GHCR images.
 
 ### QA Lab
 
-QA Lab box також є частиною `OpenClaw Release Checks`. Це агентний
+QA Lab box також є частиною `OpenClaw Release Checks`. Це agentic
 behavior і channel-level release gate, окремий від Vitest і Docker
 package mechanics.
 
 Release QA Lab coverage включає:
 
 - mock parity lane, що порівнює OpenAI candidate lane з Opus 4.6
-  baseline за допомогою agentic parity pack
-- fast live Matrix QA profile, що використовує середовище `qa-live-shared`
+  baseline, використовуючи agentic parity pack
+- fast live Matrix QA profile, що використовує environment `qa-live-shared`
 - live Telegram QA lane, що використовує Convex CI credential leases
-- `pnpm qa:otel:smoke`, коли release telemetry потребує explicit local proof
+- `pnpm qa:otel:smoke`, коли release telemetry потребує явного local proof
 
-Використовуйте цей 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?" Зберігайте artifact URLs для parity, Matrix і Telegram
+lanes під час схвалення релізу. Full Matrix coverage лишається доступним як
+manual sharded QA-Lab run, а не default release-critical lane.
 
 ### Package
 
 Package box — це installable-product gate. Він підтримується
 `Package Acceptance` і resolver
 `scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує
-candidate у tarball `package-under-test`, який споживає Docker E2E, перевіряє
+candidate у tarball `package-under-test`, який споживає Docker E2E, валідує
 package inventory, записує package version і SHA-256 та тримає
 workflow harness ref окремо від package source ref.
 
-Підтримувані джерела candidate:
+Підтримувані candidate sources:
 
 - `source=npm`: `openclaw@beta`, `openclaw@latest` або точна OpenClaw release
   version
-- `source=ref`: пакує довірену `package_ref` branch, tag або повний commit SHA
+- `source=ref`: pack довірену `package_ref` branch, tag або full commit SHA
   з вибраним `workflow_ref` harness
-- `source=url`: завантажує HTTPS `.tgz` з обов’язковим `package_sha256`
-- `source=artifact`: повторно використовує `.tgz`, завантажений іншим GitHub Actions run
+- `source=url`: download HTTPS `.tgz` з обов'язковим `package_sha256`
+- `source=artifact`: reuse `.tgz`, завантажений іншим GitHub Actions run
 
 `OpenClaw Release Checks` запускає Package Acceptance з `source=artifact`,
-підготовленим release package artifact, `suite_profile=custom`,
+prepared 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=all-since-2026.4.23`,
 `published_upgrade_survivor_scenarios=reported-issues` і
@@ -489,31 +484,31 @@ package QA проти того самого resolved tarball. Upgrade matrix п
 Package Acceptance з `source=npm` для вже shipped candidate або
 `source=ref`/`source=artifact` для SHA-backed local npm tarball перед
 publish. Це GitHub-native
-заміна для більшості package/update coverage, що раніше вимагала
+заміна більшої частини package/update coverage, яка раніше потребувала
 Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding,
 installer і platform behavior, але package/update product validation має
 віддавати перевагу Package Acceptance.
 
 Канонічний checklist для update і plugin validation —
-[Тестування оновлень і plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли
-вирішуєте, який local, Docker, Package Acceptance або release-check lane підтверджує
+[Тестування updates і 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 package `2026.4.23+` —
-це окремий ручний workflow `Update Migration`, а не частина Full Release CI.
+це окремий manual `Update Migration` workflow, а не частина Full Release CI.
 
 Legacy package-acceptance leniency навмисно обмежена в часі. Packages до
-`2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих
-у npm: private QA inventory entries, яких бракує в tarball, відсутній
+`2026.4.25` включно можуть використовувати compatibility path для metadata gaps, уже опублікованих
+до npm: private QA inventory entries, відсутні в tarball, відсутній
 `gateway install --wrapper`, відсутні patch files у tarball-derived git
 fixture, відсутній persisted `update.channel`, legacy plugin install-record
 locations, відсутня marketplace install-record persistence і config metadata
-migration під час `plugins update`. Опублікований package `2026.4.26` може попереджати
+migration під час `plugins update`. Опублікований package `2026.4.26` може warn
 про local build metadata stamp files, які вже були shipped. Пізніші packages
-мають відповідати сучасним package contracts; ті самі gaps провалюють release
+мають відповідати modern package contracts; ті самі gaps провалюють release
 validation.
 
 Використовуйте ширші Package Acceptance profiles, коли release question стосується
-фактичного installable package:
+справжнього installable package:
 
 ```bash
 gh workflow run package-acceptance.yml \
@@ -534,25 +529,26 @@ 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` для сфокусованих reruns
+- `custom`: точний список `docker_lanes` для focused reruns
 
-Для доказу Telegram кандидата пакета увімкніть `telegram_mode=mock-openai` або
-`telegram_mode=live-frontier` у Package Acceptance. Workflow передає
-розв’язаний tarball `package-under-test` у lane Telegram; окремий workflow
-Telegram досі приймає опубліковану специфікацію npm для перевірок після публікації.
+Для доказу Telegram для пакета-кандидата увімкніть `telegram_mode=mock-openai` або
+`telegram_mode=live-frontier` у Прийнятті пакета. Робочий процес передає
+розв’язаний tarball `package-under-test` у лінію Telegram; окремий робочий
+процес Telegram і далі приймає опубліковану npm-специфікацію для перевірок
+після публікації.
 
-## Автоматизація публікації релізу
+## Автоматизація публікації випуску
 
 `OpenClaw Release Publish` є звичайною змінювальною точкою входу для публікації. Він
-оркеструє workflow довіреного видавця в порядку, потрібному для релізу:
+оркеструє робочі процеси довіреного видавця в порядку, потрібному для випуску:
 
-1. Виконати checkout тега релізу та визначити його SHA коміту.
-2. Перевірити, що тег досяжний із `main` або `release/*`.
+1. Отримати тег випуску та визначити SHA його коміту.
+2. Перевірити, що тег доступний із `main` або `release/*`.
 3. Запустити `pnpm plugins:sync:check`.
 4. Запустити `Plugin NPM Release` з `publish_scope=all-publishable` і
    `ref=<release-sha>`.
 5. Запустити `Plugin ClawHub Release` з тим самим scope і SHA.
-6. Запустити `OpenClaw NPM Release` з тегом релізу, dist-tag npm і
+6. Запустити `OpenClaw NPM Release` з тегом випуску, npm dist-tag і
    збереженим `preflight_run_id`.
 
 Приклад публікації beta:
@@ -565,17 +561,7 @@ gh workflow run openclaw-release-publish.yml \
   -f npm_dist_tag=beta
 ```
 
-Приклад публікації alpha:
-
-```bash
-gh workflow run openclaw-release-publish.yml \
-  --ref release/YYYY.M.D \
-  -f tag=vYYYY.M.D-alpha.N \
-  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
-  -f npm_dist_tag=alpha
-```
-
-Стабільна публікація в типовий dist-tag beta:
+Стабільна публікація до типового beta dist-tag:
 
 ```bash
 gh workflow run openclaw-release-publish.yml \
@@ -585,7 +571,7 @@ gh workflow run openclaw-release-publish.yml \
   -f npm_dist_tag=beta
 ```
 
-Пряме просування стабільної версії до `latest` є явним:
+Стабільне просування безпосередньо до `latest` є явним:
 
 ```bash
 gh workflow run openclaw-release-publish.yml \
@@ -595,92 +581,91 @@ gh workflow run openclaw-release-publish.yml \
   -f npm_dist_tag=latest
 ```
 
-Використовуйте нижчерівневі workflow `Plugin NPM Release` і `Plugin ClawHub Release`
-лише для цільового виправлення або повторної публікації. Для вибраного виправлення Plugin передайте
+Використовуйте нижчорівневі робочі процеси `Plugin NPM Release` і `Plugin ClawHub Release`
+лише для цілеспрямованого виправлення або повторної публікації. Для виправлення вибраного Plugin передайте
 `plugin_publish_scope=selected` і `plugins=@openclaw/name` до
-`OpenClaw Release Publish` або запустіть дочірній workflow напряму, коли пакет
-OpenClaw не має публікуватися.
+`OpenClaw Release Publish` або запустіть дочірній робочий процес напряму, коли
+пакет OpenClaw не має бути опублікований.
 
-## Вхідні параметри workflow NPM
+## Вхідні дані робочого процесу 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`: обов’язковий тег випуску, наприклад `v2026.4.2`, `v2026.4.2-1` або
+  `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
+  повний 40-символьний SHA коміту гілки робочого процесу для preflight лише з валідацією
 - `preflight_only`: `true` лише для валідації/збірки/пакування, `false` для
-  справжнього шляху публікації
-- `preflight_run_id`: обов’язковий на справжньому шляху публікації, щоб workflow повторно використав
+  реального шляху публікації
+- `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб робочий процес повторно використав
   підготовлений tarball з успішного preflight-запуску
-- `npm_dist_tag`: цільовий тег npm для шляху публікації; типово `beta`
+- `npm_dist_tag`: цільовий npm-тег для шляху публікації; типово `beta`
 
-`OpenClaw Release Publish` приймає такі керовані оператором вхідні параметри:
+`OpenClaw Release Publish` приймає такі контрольовані оператором вхідні дані:
 
-- `tag`: обов’язковий тег релізу; має вже існувати
-- `preflight_run_id`: id успішного preflight-запуску `OpenClaw NPM Release`;
+- `tag`: обов’язковий тег випуску; має вже існувати
+- `preflight_run_id`: ідентифікатор успішного preflight-запуску `OpenClaw NPM Release`;
   обов’язковий, коли `publish_openclaw_npm=true`
-- `npm_dist_tag`: цільовий тег npm для пакета OpenClaw
+- `npm_dist_tag`: цільовий npm-тег для пакета OpenClaw
 - `plugin_publish_scope`: типово `all-publishable`; використовуйте `selected` лише
-  для цільової роботи з виправлення
+  для цілеспрямованого виправлення
 - `plugins`: розділені комами назви пакетів `@openclaw/*`, коли
   `plugin_publish_scope=selected`
-- `publish_openclaw_npm`: типово `true`; установлюйте `false` лише коли використовуєте
-  workflow як оркестратор виправлення лише для Plugin
+- `publish_openclaw_npm`: типово `true`; встановлюйте `false` лише під час використання
+  робочого процесу як оркестратора виправлення лише для Plugin
 
-`OpenClaw Release Checks` приймає такі керовані оператором вхідні параметри:
+`OpenClaw Release Checks` приймає такі контрольовані оператором вхідні дані:
 
-- `ref`: гілка, тег або повний SHA коміту для валідації. Перевірки з секретами
-  вимагають, щоб розв’язаний коміт був досяжний з гілки OpenClaw або
-  тега релізу.
+- `ref`: гілка, тег або повний SHA коміту для валідації. Перевірки із секретами
+  вимагають, щоб розв’язаний коміт був доступний із гілки OpenClaw або
+  тегу випуску.
 
 Правила:
 
-- Стабільні та корекційні теги можуть публікуватися або до `beta`, або до `latest`
-- Alpha-передрелізні теги можуть публікуватися лише до `alpha`
-- Beta-передрелізні теги можуть публікуватися лише до `beta`
-- Для `OpenClaw NPM Release` вхідний повний SHA коміту дозволений лише коли
+- Стабільні та коригувальні теги можуть публікуватися або до `beta`, або до `latest`
+- Теги beta prerelease можуть публікуватися лише до `beta`
+- Для `OpenClaw NPM Release` введення повного SHA коміту дозволене лише коли
   `preflight_only=true`
 - `OpenClaw Release Checks` і `Full Release Validation` завжди
-  лише для валідації
-- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
-  workflow перевіряє ці metadata перед продовженням публікації
+  лише валідаційні
+- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час preflight;
+  робочий процес перевіряє ці метадані перед продовженням публікації
 
-## Послідовність стабільного npm-релізу
+## Послідовність стабільного npm-випуску
 
-Під час створення стабільного npm-релізу:
+Під час створення стабільного npm-випуску:
 
 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
-   - До появи тега можна використати поточний повний SHA коміту гілки workflow
-     для пробного запуску preflight workflow лише з валідацією
-2. Виберіть `npm_dist_tag=beta` для звичайного потоку спочатку в beta або `latest` лише
+   - До існування тегу можна використати поточний повний SHA коміту гілки робочого процесу
+     для пробного preflight-запуску лише з валідацією
+2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише
    коли ви навмисно хочете пряму стабільну публікацію
-3. Запустіть `Full Release Validation` на гілці релізу, тегу релізу або повному
-   SHA коміту, коли потрібні звичайний CI плюс покриття live prompt cache, Docker, QA Lab,
-   Matrix і Telegram з одного ручного workflow
+3. Запустіть `Full Release Validation` на гілці випуску, тегу випуску або повному
+   SHA коміту, коли потрібне звичайне CI плюс покриття live prompt cache, Docker, QA Lab,
+   Matrix і Telegram з одного ручного робочого процесу
 4. Якщо вам навмисно потрібен лише детермінований звичайний граф тестів, запустіть
-   ручний workflow `CI` на release ref натомість
+   ручний робочий процес `CI` на ref випуску натомість
 5. Збережіть успішний `preflight_run_id`
 6. Запустіть `OpenClaw Release Publish` з тим самим `tag`, тим самим `npm_dist_tag`
-   і збереженим `preflight_run_id`; він публікує зовнішні plugins до npm
+   і збереженим `preflight_run_id`; він публікує externalized plugins до 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 на стабільну версію, або дозвольте його запланованій
-   self-healing синхронізації перемістити `beta` пізніше
+7. Якщо випуск потрапив у `beta`, використайте приватний робочий процес
+   `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
+   для просування цієї стабільної версії з `beta` до `latest`
+8. Якщо випуск навмисно опубліковано безпосередньо до `latest`, а `beta`
+   має негайно слідувати за тією самою стабільною збіркою, використайте той самий приватний
+   робочий процес, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
+   самовідновлювальній синхронізації перемістити `beta` пізніше
 
-Зміна dist-tag розміщена в приватному repo з міркувань безпеки, бо вона все ще
-потребує `NPM_TOKEN`, тоді як публічний repo зберігає публікацію лише через OIDC.
+Мутація dist-tag розташована в приватному репозиторії з міркувань безпеки, бо вона все ще
+потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
 
-Це залишає і шлях прямої публікації, і шлях просування спочатку в beta
+Це зберігає і прямий шлях публікації, і шлях просування beta-first
 задокументованими та видимими для оператора.
 
-Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password
-CLI (`op`) лише всередині виділеної tmux-сесії. Не викликайте `op`
-напряму з основного shell агента; утримання його всередині tmux робить prompts,
-alerts і обробку OTP видимими та запобігає повторним host alerts.
+Якщо maintainer має повернутися до локальної npm-автентифікації, запускайте будь-які команди
+1Password CLI (`op`) лише всередині окремого сеансу tmux. Не викликайте `op`
+безпосередньо з основної shell агента; утримання його всередині tmux робить prompts,
+сповіщення та обробку OTP видимими й запобігає повторним сповіщенням хоста.
 
 ## Публічні посилання
 
@@ -694,10 +679,10 @@ 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 використовують приватну документацію релізу в
+Maintainers використовують приватну документацію випусків у
 [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
 для фактичного runbook.
 
 ## Пов’язане
 
-- [Канали релізів](/uk/install/development-channels)
+- [Канали випусків](/uk/install/development-channels)