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, перевірки області, релізні парасольки та локальні еквіваленти команд
-title: Конвеєр CI
+summary: Граф завдань CI, перевірки за областю охоплення, релізні парасолькові набори та локальні еквіваленти команд
+title: CI-конвеєр
 x-i18n:
-    generated_at: "2026-05-04T22:29:59Z"
+    generated_at: "2026-05-05T01:33:52Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 88d0f7f6cd61d550ec399e8250f685929637cd28638e77aa5a5558775767cac6
+    source_hash: 16771940889d1fa944a5bfafe1152a033d96625595a2d89ff2cedbd3022cee66
     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`. Release-only покриття plugins живе в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або через явний ручний dispatch.
+OpenClaw CI запускається для кожного push у `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі лінії, коли змінилися лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження scope і розгортають повний граф для кандидатів на реліз і широкої валідації. Android-лінії залишаються opt-in через `include_android`. Покриття Plugin лише для релізу розміщене в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch.
 
 ## Огляд pipeline
 
-| Завдання                         | Призначення                                                                                                  | Коли запускається                 |
-| -------------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------- |
-| `preflight`                      | Виявляє docs-only зміни, змінені scopes, змінені extensions і збирає CI manifest                             | Завжди для non-draft pushes і PRs |
-| `security-scm-fast`              | Виявлення private keys і аудит workflow через `zizmor`                                                       | Завжди для non-draft pushes і PRs |
-| `security-dependency-audit`      | Production lockfile audit без залежностей на основі npm advisories                                           | Завжди для non-draft pushes і PRs |
-| `security-fast`                  | Обов’язковий aggregate для швидких security jobs                                                             | Завжди для non-draft pushes і PRs |
-| `check-dependencies`             | Production Knip dependency-only pass плюс guard allowlist для unused files                                   | Node-релевантні зміни             |
-| `build-artifacts`                | Збірка `dist/`, Control UI, built-artifact checks і reusable downstream artifacts                            | Node-релевантні зміни             |
-| `checks-fast-core`               | Швидкі Linux correctness lanes, як-от bundled/plugin-contract/protocol checks                                | Node-релевантні зміни             |
-| `checks-fast-contracts-channels` | Sharded channel contract checks зі стабільним aggregate check result                                         | Node-релевантні зміни             |
-| `checks-node-core-test`          | Core Node test shards, за винятком channel, bundled, contract і extension lanes                              | Node-релевантні зміни             |
-| `check`                          | Sharded еквівалент main local gate: prod types, lint, guards, test types і strict smoke                      | Node-релевантні зміни             |
-| `check-additional`               | Architecture, sharded boundary/prompt drift, extension guards, package boundary і gateway watch              | 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 для releases   |
-| `check-docs`                     | Форматування docs, lint і broken-link checks                                                                 | Змінено docs                      |
-| `skills-python`                  | Ruff + pytest для Python-backed skills                                                                       | Python-skill-релевантні зміни     |
-| `checks-windows`                 | Windows-specific process/path tests плюс shared runtime import specifier regressions                         | Windows-релевантні зміни          |
-| `macos-node`                     | macOS TypeScript test lane із використанням shared built artifacts                                           | macOS-релевантні зміни            |
-| `macos-swift`                    | Swift lint, build і tests для macOS app                                                                      | macOS-релевантні зміни            |
-| `android`                        | Android unit tests для обох flavors плюс одна debug APK build                                                | Android-релевантні зміни          |
-| `test-performance-agent`         | Щоденна Codex оптимізація slow-test після trusted activity                                                   | Main CI success або manual dispatch |
-| `openclaw-performance`           | Щоденні/on-demand Kova runtime performance reports із mock-provider, deep-profile і GPT 5.4 live lanes       | Scheduled і manual dispatch       |
+| Завдання                         | Призначення                                                                                                     | Коли запускається                         |
+| -------------------------------- | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------- |
+| `preflight`                      | Виявляє зміни лише в документації, змінені scopes, змінені extensions і формує CI manifest                      | Завжди для не-draft pushes і PRs          |
+| `security-scm-fast`              | Виявлення приватних ключів і аудит workflow через `zizmor`                                                      | Завжди для не-draft pushes і PRs          |
+| `security-dependency-audit`      | Аудит production lockfile без залежностей проти npm advisories                                                  | Завжди для не-draft pushes і PRs          |
+| `security-fast`                  | Обов’язковий aggregate для швидких security jobs                                                                | Завжди для не-draft pushes і PRs          |
+| `check-dependencies`             | Production Knip dependency-only pass плюс guard allowlist для unused-file                                       | Зміни, релевантні 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 checks зі стабільним aggregate check result                                            | Зміни, релевантні Node                    |
+| `checks-node-core-test`          | Core Node test shards, крім channel, bundled, contract і extension lanes                                        | Зміни, релевантні Node                    |
+| `check`                          | Sharded main local gate equivalent: prod types, lint, guards, test types і strict smoke                         | Зміни, релевантні Node                    |
+| `check-additional`               | Architecture, sharded boundary/prompt drift, extension guards, package boundary і gateway watch                 | Зміни, релевантні 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                                                                        | Manual CI dispatch для releases           |
+| `check-docs`                     | Форматування документації, lint і перевірки broken-link                                                         | Документацію змінено                      |
+| `skills-python`                  | Ruff + pytest для skills на базі Python                                                                         | Зміни, релевантні Python-skill            |
+| `checks-windows`                 | Windows-specific process/path tests плюс shared runtime import specifier regressions                            | Зміни, релевантні Windows                 |
+| `macos-node`                     | macOS TypeScript test lane із використанням shared built artifacts                                              | Зміни, релевантні macOS                   |
+| `macos-swift`                    | Swift lint, build і tests для застосунку macOS                                                                  | Зміни, релевантні macOS                   |
+| `android`                        | Android unit tests для обох flavors плюс одна debug APK build                                                   | Зміни, релевантні Android                 |
+| `test-performance-agent`         | Щоденна оптимізація повільних тестів Codex після trusted activity                                               | Main CI success або manual dispatch       |
+| `openclaw-performance`           | Щоденні/on-demand Kova runtime performance reports з mock-provider, deep-profile і GPT 5.4 live lanes           | Scheduled і manual 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 jobs.
+3. `build-artifacts` перекривається зі швидкими Linux-лініями, щоб 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`.
 
-GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє до того самого PR або ref `main`. Вважайте це шумом CI, якщо найновіший run для того самого 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 може позначати superseded jobs як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це CI-шумом, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні shard failures, але не стають у чергу після того, як весь workflow уже був superseded. Автоматичний CI concurrency key версійований (`CI-v7-*`), тому GitHub-side zombie у старій queue group не може безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs.
 
-## Scope і routing
+## Scope і маршрутизація
 
-Логіка scope живе в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби кожну scoped area було змінено.
+Логіка scope розміщена в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби змінилася кожна scoped area.
 
-- **Редагування CI workflow** валідують Node CI graph плюс workflow linting, але самі по собі не примушують Windows, Android або macOS native builds; ці platform lanes залишаються scoped до platform source changes.
-- **CI routing-only edits, вибрані дешеві 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 перевіряє напряму.
+- **Редагування CI workflow** валідують Node CI graph плюс workflow linting, але самі по собі не змушують запускатися Windows, Android або macOS native builds; ці platform lanes залишаються scoped до platform source changes.
+- **Редагування лише 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.
 
-Найповільніші сімейства Node tests розділені або збалансовані так, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts виконуються як три weighted shards, core unit fast/support lanes виконуються окремо, core runtime infra розділено між state і process/config shards, auto-reply запускається як balanced workers (із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/server configs розділено між chat/auth/model/http-plugin/runtime/startup lanes замість очікування на 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` може відрізнити whole config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard list розподілено по чотирьох matrix shards, кожен із яких паралельно запускає вибрані independent guards і друкує per-check timings, включно з `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 test families розділено або збалансовано, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, core unit fast/support lanes запускаються окремо, core runtime infra розділено між state і process/config shards, auto-reply запускається як balanced workers (із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/server configs розділено між chat/auth/model/http-plugin/runtime/startup lanes замість очікування на built artifacts. Широкі 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 list розподілено на чотири matrix shards, кожен із яких паралельно запускає вибрані independent guards і друкує per-check timings, включно з `pnpm prompt:snapshots:check`, щоб Codex runtime happy-path prompt drift був прив’язаний до PR, який його спричинив. Gateway watch, channel tests і core support-boundary shard запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані.
 
-Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor із SMS/call-log BuildConfig flags, водночас уникаючи duplicate debug APK packaging job на кожному Android-релевантному push.
+Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor із SMS/call-log BuildConfig flags, уникаючи duplicate 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` install) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий unreviewed unused file або залишає stale allowlist entry, водночас зберігаючи intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично resolve.
+Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, закріплений на найновішій версії Knip, з вимкненим minimum release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий неперевірений unused file або залишає застарілий allowlist entry, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично розв’язати.
 
-## Переспрямування активності ClawSweeper
+## Пересилання активності ClawSweeper
 
-`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge з активності репозиторію OpenClaw до ClawSweeper. Він не виконує checkout і не запускає ненадійний pull request code. Workflow створює GitHub App token із `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім dispatches compact `repository_dispatch` payloads до `openclaw/clawsweeper`.
+`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge з активності репозиторію OpenClaw до ClawSweeper. Він не checkout і не виконує untrusted pull request code. Workflow створює GitHub App token з `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім dispatch компактні payloads `repository_dispatch` до `openclaw/clawsweeper`.
 
-Workflow має чотири lanes:
+Workflow має чотири лінії:
 
-- `clawsweeper_item` для точних issue і pull request review requests;
-- `clawsweeper_comment` для явних команд ClawSweeper в issue comments;
-- `clawsweeper_commit_review` для commit-level review requests на `main` pushes;
-- `github_activity` для загальної GitHub activity, яку агент ClawSweeper може inspect.
+- `clawsweeper_item` для точних запитів на review issue і pull request;
+- `clawsweeper_comment` для явних команд ClawSweeper у коментарях issue;
+- `clawsweeper_commit_review` для commit-level review requests на pushes у `main`;
+- `github_activity` для загальної GitHub activity, яку агент ClawSweeper може інспектувати.
 
-Lane `github_activity` пересилає лише normalized 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`, який публікує normalized event до hook OpenClaw Gateway для агента ClawSweeper.
+Лінія `github_activity` пересилає лише нормалізовані metadata: event type, action, actor, repository, item number, URL, title, state і short excerpts для comments або reviews, коли вони є. Вона навмисно не пересилає повне webhook body. Receiving workflow у `openclaw/clawsweeper` — `.github/workflows/github-activity.yml`, який публікує normalized event до OpenClaw Gateway hook для агента ClawSweeper.
 
-Загальна активність є observation, а не delivery-by-default. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли event є несподіваним, actionable, risky або operationally useful. Routine opens, edits, bot churn, duplicate webhook noise і normal review traffic мають призводити до `NO_REPLY`.
+Загальна activity є спостереженням, а не delivery-by-default. Агент 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 ненадійними даними на всьому цьому path. Вони є input для summarization і triage, а не інструкціями для workflow або agent runtime.
+Сприймайте GitHub titles, comments, bodies, review text, branch names і commit messages як untrusted data в усьому цьому path. Це input для summarization і triage, а не instructions для workflow або agent runtime.
 
 ## Ручні dispatches
 
-Ручні dispatch CI запускають той самий граф завдань, що й звичайний CI, але примусово вмикають кожну scoped lane не для Android: Linux Node shards, bundled-Plugin shards, контракти каналів, сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python Skills, Windows, macOS і Control UI i18n. Окремі ручні dispatch CI запускають лише Android з `include_android=true`; повна release-umbrella вмикає Android, передаючи `include_android=true`. Передвипускні статичні перевірки Plugin, release-only shard `agentic-plugins`, повний пакетний sweep розширень і передвипускні Docker lanes для Plugin виключено з CI. Передвипускний Docker suite запускається лише тоді, коли `Full Release Validation` dispatch окремого workflow `Plugin Prerelease` з увімкненим release-validation gate.
+Ручні запуски CI виконують той самий граф завдань, що й звичайна CI, але примусово вмикають кожну не-Android lane з обмеженою областю: Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python skills, Windows, macOS і Control UI i18n. Окремі ручні запуски CI виконують лише Android із `include_android=true`; повна release-парасоля вмикає Android через передавання `include_android=true`. Статичні перевірки prerelease Plugin, release-only shard `agentic-plugins`, повний пакетний sweep extensions і Docker lanes prerelease Plugin виключені з CI. Набір Docker prerelease запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate release validation.
 
-Ручні запуски використовують унікальну concurrency group, тому повний suite реліз-кандидата не скасовується іншим push або PR run на тому самому ref. Необовʼязковий input `target_ref` дає змогу довіреному виклику запустити цей граф для branch, tag або повного commit SHA, використовуючи файл workflow з вибраного dispatch ref.
+Ручні запуски використовують унікальну групу concurrency, тому повний набір release candidate не скасовується іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає довіреному виклику змогу запустити цей граф для branch, tag або повного commit SHA, використовуючи workflow file з вибраного dispatch ref.
 
 ```bash
 gh workflow run ci.yml --ref release/YYYY.M.D
@@ -96,17 +96,17 @@ gh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_andro
 gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
 ```
 
-## Runners
+## Ранери
 
-| Runner                           | Завдання                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| Ранер                            | Завдання                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
 | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ubuntu-24.04`                   | `preflight`, швидкі security jobs і aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, sharded перевірки контрактів каналів, shards `check`, окрім lint, shards і aggregates `check-additional`, aggregate verifiers тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла ставати в чергу раніше |
-| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, легші shards розширень, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types`                                                                                                                                                                                                                                                                                                                   |
+| `ubuntu-24.04`                   | `preflight`, швидкі security jobs і aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, sharded channel contract checks, shards `check`, окрім lint, shards і aggregates `check-additional`, 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-sensitive, щоб 8 vCPU коштували більше, ніж заощаджували); install-smoke Docker builds (час очікування в черзі для 32-vCPU коштував більше, ніж заощаджував)                                                                                                                                                                                                                                                                                                                     |
+| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (настільки чутливий до CPU, що 8 vCPU коштували більше, ніж економили); install-smoke Docker builds (час очікування в черзі на 32-vCPU коштував більше, ніж економив)                                                                                                                                                                                                                                                                                       |
 | `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| `blacksmith-6vcpu-macos-latest`  | `macos-node` на `openclaw/openclaw`; forks fallback до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                  |
-| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks fallback до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                 |
+| `blacksmith-6vcpu-macos-latest`  | `macos-node` на `openclaw/openclaw`; forks повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                               |
+| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                             |
 
 ## Локальні еквіваленти
 
@@ -137,7 +137,7 @@ pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.jso
 
 ## Продуктивність OpenClaw
 
-`OpenClaw Performance` — це workflow продуктивності продукту/runtime. Він запускається щодня на `main` і може запускатися вручну:
+`OpenClaw Performance` — це workflow продуктивності product/runtime. Він запускається щодня на `main` і може бути запущений вручну:
 
 ```bash
 gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3
@@ -145,31 +145,31 @@ gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1
 gh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3
 ```
 
-Ручний dispatch зазвичай benchmark workflow ref. Установіть `target_ref`, щоб benchmark release tag або іншу branch із поточною реалізацією workflow. Опубліковані paths звітів і latest pointers keyed by tested ref, а кожен `index.md` фіксує tested ref/SHA, workflow ref/SHA, Kova ref, profile, lane auth mode, model, repeat count і scenario filters.
+Ручний dispatch зазвичай benchmark workflow ref. Установіть `target_ref`, щоб benchmark release tag або іншу branch з поточною реалізацією workflow. Опубліковані report paths і latest pointers keyed за tested ref, а кожен `index.md` записує tested ref/SHA, workflow ref/SHA, Kova ref, profile, lane auth mode, model, repeat count і scenario filters.
 
 Workflow встановлює OCM із pinned release і Kova з `openclaw/Kova` на pinned input `kova_ref`, а потім запускає три lanes:
 
-- `mock-provider`: діагностичні scenarios Kova проти local-build runtime з deterministic fake OpenAI-compatible auth.
-- `mock-deep-profile`: CPU/heap/trace profiling для startup, gateway і hotspots agent-turn.
-- `live-gpt54`: справжній turn агента OpenAI `openai/gpt-5.4`, пропускається, коли `OPENAI_API_KEY` недоступний.
+- `mock-provider`: diagnostic scenarios Kova проти local-build runtime з deterministic fake OpenAI-compatible auth.
+- `mock-deep-profile`: CPU/heap/trace profiling для hotspots startup, gateway і agent-turn.
+- `live-gpt54`: справжній turn агента OpenAI `openai/gpt-5.4`, який пропускається, коли `OPENAI_API_KEY` недоступний.
 
-Lane mock-provider також запускає OpenClaw-native source probes після проходу Kova: gateway boot timing і memory для default, hook і startup cases із 50 Plugin; повторювані mock-OpenAI цикли hello `channel-chat-baseline`; і CLI startup commands проти booted gateway. Markdown summary source probe розміщено в `source/index.md` у bundle звіту, поруч із raw JSON.
+Lane mock-provider також запускає OpenClaw-native source probes після проходу Kova: gateway boot timing і memory для default, hook і 50-plugin startup cases; repeated mock-OpenAI `channel-chat-baseline` hello loops; і CLI startup commands проти запущеного gateway. Markdown summary source probe міститься в `source/index.md` у report bundle, поруч із raw JSON.
 
-Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також commits `report.json`, `report.md`, bundles, `index.md` і source-probe artifacts у `openclaw/clawgrit-reports` під `openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/`. Поточний pointer tested-ref записується як `openclaw-performance/<tested-ref>/latest-<lane>.json`.
+Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і source-probe artifacts у `openclaw/clawgrit-reports` під `openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/`. Поточний pointer tested-ref записується як `openclaw-performance/<tested-ref>/latest-<lane>.json`.
 
-## Повна валідація релізу
+## Повна перевірка релізу
 
-`Full Release Validation` — це ручний umbrella workflow для «запустити все перед релізом». Він приймає branch, tag або повний commit SHA, dispatch ручний workflow `CI` із цією target, dispatch `Plugin Prerelease` для release-only proof Plugin/package/static/Docker і dispatch `OpenClaw Release Checks` для install smoke, package acceptance, cross-OS package checks, QA Lab parity, Matrix і Telegram lanes. Stable/default runs тримають exhaustive live/E2E і Docker release-path coverage за `run_release_soak=true`; `release_profile=full` примусово вмикає це soak coverage, щоб broad advisory validation залишалася broad. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` з release checks. Після publishing передайте `npm_telegram_package_spec`, щоб rerun тієї самої Telegram package lane проти published npm package.
+`Full Release Validation` — це ручний umbrella workflow для "запустити все перед релізом." Він приймає branch, tag або повний commit SHA, запускає ручний workflow `CI` з цією target, запускає `Plugin Prerelease` для release-only plugin/package/static/Docker proof і запускає `OpenClaw Release Checks` для install smoke, package acceptance, cross-OS package checks, QA Lab parity, Matrix і Telegram lanes. Stable/default runs тримають exhaustive live/E2E і Docker release-path coverage за `run_release_soak=true`; `release_profile=full` примусово вмикає це soak coverage, щоб широка advisory validation лишалася широкою. З `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) для
-stage matrix, точних назв jobs workflow, відмінностей profile, artifacts і
+Див. [Повна перевірка релізу](/uk/reference/full-release-validation) для
+stage matrix, точних назв workflow jobs, відмінностей profile, artifacts і
 focused rerun handles.
 
-`OpenClaw Release Publish` — це ручний mutating release workflow. Dispatch його
-з `release/YYYY.M.D` або `main` після того, як release tag існує, і після того, як
-OpenClaw npm preflight успішно завершився. Він перевіряє `pnpm plugins:sync:check`,
-dispatch `Plugin NPM Release` для всіх publishable packages Plugin, dispatch
-`Plugin ClawHub Release` для того самого release SHA, і лише потім dispatch
+`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
@@ -180,45 +180,41 @@ gh workflow run openclaw-release-publish.yml \
   -f npm_dist_tag=beta
 ```
 
-Для proof pinned commit на branch, що швидко змінюється, використовуйте helper замість
+Для proof pinned commit на швидкозмінній branch використовуйте helper замість
 `gh workflow run ... --ref main -f ref=<sha>`:
 
 ```bash
 pnpm ci:full-release --sha <full-sha>
 ```
 
-GitHub workflow dispatch refs мають бути branches або tags, а не raw commit SHAs.
-Helper pushes тимчасову branch `release-ci/<sha>-...` на target SHA,
-dispatch `Full Release Validation` з цього pinned ref, перевіряє, що кожен child
-workflow `headSha` збігається з target, і видаляє тимчасову branch після завершення
-run. Umbrella verifier також fails, якщо будь-який child workflow запустився на
+GitHub workflow dispatch refs мають бути branches або tags, а не raw commit SHAs. Helper
+pushes тимчасову branch `release-ci/<sha>-...` на target SHA,
+запускає `Full Release Validation` з цього pinned ref, перевіряє, що кожен child
+workflow `headSha` збігається з target, і видаляє тимчасову branch, коли
+run завершується. Umbrella verifier також fails, якщо будь-який child workflow ran на
 іншому SHA.
 
-`release_profile` керує широтою live/provider, що передається до перевірок випуску. Ручні робочі процеси випуску за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли ви навмисно хочете широку консультативну матрицю provider/media. `run_release_soak` керує тим, чи перевірки стабільного/типового випуску запускають вичерпний live/E2E та Docker soak для шляху випуску; `full` примусово вмикає soak.
+`release_profile` керує широтою live/provider, що передається до перевірок релізу. Ручні release workflows за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли ви навмисно хочете широку advisory provider/media матрицю. `run_release_soak` керує тим, чи stable/default перевірки релізу запускають вичерпний live/E2E та Docker release-path soak; `full` примусово вмикає soak.
 
-- `minimum` залишає найшвидші критичні для випуску лінії OpenAI/core.
+- `minimum` залишає найшвидші критичні для релізу OpenAI/core лінії.
 - `stable` додає стабільний набір provider/backend.
-- `full` запускає широку консультативну матрицю provider/media.
+- `full` запускає широку advisory provider/media матрицю.
 
-Парасольковий робочий процес записує ідентифікатори запущених дочірніх виконань, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх виконань і додає таблиці найповільніших завдань для кожного дочірнього виконання. Якщо дочірній робочий процес перезапущено і він стає зеленим, перезапустіть лише батьківське завдання перевірки, щоб оновити результат парасолькового робочого процесу та підсумок часу.
+Umbrella записує ідентифікатори запущених дочірніх прогонів, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх прогонів і додає таблиці найповільніших завдань для кожного дочірнього прогону. Якщо дочірній workflow перезапущено і він стає зеленим, перезапустіть лише батьківське завдання перевірки, щоб оновити результат umbrella і підсумок часу.
 
-Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата випуску, `ci` лише для звичайного дочірнього повного CI, `plugin-prerelease` лише для дочірнього передрелізу plugin, `release-checks` для кожного дочірнього випуску або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` або `npm-telegram` у парасольковому робочому процесі. Це зберігає перезапуск невдалої коробки випуску обмеженим після цільового виправлення.
+Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для release candidate, `ci` лише для звичайного повного CI child, `plugin-prerelease` лише для plugin prerelease child, `release-checks` для кожного release child або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` на umbrella. Це утримує перезапуск невдалого release box обмеженим після сфокусованого виправлення. Для однієї невдалої cross-OS лінії поєднайте `rerun_group=cross-os` із `cross_os_suite_filter`, наприклад `windows/packaged-upgrade`; довгі cross-OS команди виводять рядки heartbeat, а підсумки packaged-upgrade містять часи для кожної фази. QA release-check лінії є advisory, тому QA-only збої попереджають, але не блокують release-check verifier.
 
-`OpenClaw Release Checks` використовує довірене посилання робочого процесу, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт до cross-OS перевірок і Package Acceptance, а також до live/E2E Docker-робочого процесу шляху випуску, коли запускається soak-покриття. Це зберігає байти пакета узгодженими між коробками випуску та уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
+`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз розв'язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт до cross-OS перевірок і Package Acceptance, а також до live/E2E release-path Docker workflow, коли запускається soak coverage. Це зберігає байти пакета узгодженими між release boxes і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
 
-Дублікати виконань `Full Release Validation` для `ref=main` і `rerun_group=all`
-замінюють старіший парасольковий робочий процес. Батьківський монітор скасовує будь-який дочірній робочий процес, який
-він уже запустив, коли батьківський скасовано, тому новіша перевірка main
-не чекає за застарілим двогодинним виконанням release-check. Перевірка гілки/тегу випуску
-та цільові групи перезапуску зберігають `cancel-in-progress: false`.
+Дубльовані запуски `Full Release Validation` для `ref=main` і `rerun_group=all` замінюють старіший umbrella. Батьківський monitor скасовує будь-який дочірній workflow, який він уже запустив, коли батьківський workflow скасовано, тож новіша валідація main не стоїть за застарілим двогодинним release-check прогоном. Валідація release branch/tag і сфокусовані rerun groups зберігають `cancel-in-progress: false`.
 
-## Live та E2E шарди
+## Live та E2E shards
 
-Дочірній release live/E2E зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання:
+Release live/E2E child зберігає широке native покриття `pnpm test:live`, але запускає його як іменовані shards через `scripts/test-live-shard.mjs` замість одного послідовного завдання:
 
 - `native-live-src-agents`
 - `native-live-src-gateway-core`
-- завдання `native-live-src-gateway-profiles` з фільтрацією за provider
+- provider-filtered `native-live-src-gateway-profiles` jobs
 - `native-live-src-gateway-backends`
 - `native-live-test`
 - `native-live-extensions-a-k`
@@ -226,61 +222,59 @@ run. Umbrella verifier також fails, якщо будь-який child workfl
 - `native-live-extensions-openai`
 - `native-live-extensions-o-z-other`
 - `native-live-extensions-xai`
-- розділені audio/video шарди media та шарди music з фільтрацією за provider
+- розділені media audio/video shards і provider-filtered music shards
 
-Це зберігає те саме файлове покриття, водночас спрощуючи перезапуск і діагностику повільних збоїв live provider. Агреговані назви шардів `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 шарди запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному робочим процесом `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють ці бінарні файли перед налаштуванням. Тримайте Docker-backed live набори на звичайних Blacksmith runners — контейнерні завдання є неправильним місцем для запуску вкладених Docker-тестів.
+Native live media shards працюють у `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media jobs лише перевіряють бінарні файли перед налаштуванням. Залишайте Docker-backed live suites на звичайних Blacksmith runners — container jobs є невідповідним місцем для запуску nested Docker tests.
 
-Docker-backed live model/backend шарди використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Live release workflow збирає та пушить цей образ один раз, після чого Docker live model, provider-sharded gateway, CLI backend, ACP bind і Codex harness шарди запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Docker шарди Gateway мають явні обмеження `timeout` на рівні скриптів нижче за тайм-аут завдання робочого процесу, щоб завислий контейнер або шлях очищення швидко завершувався з помилкою, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну source Docker target, виконання випуску налаштоване неправильно і марнуватиме реальний час на дублікати збірок образу.
+Docker-backed live model/backend shards використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Live release workflow збирає і публікує цей образ один раз, після чого Docker live model, provider-sharded gateway, CLI backend, ACP bind і Codex harness shards запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker shards мають явні script-level обмеження `timeout`, нижчі за workflow job timeout, щоб завислий контейнер або шлях cleanup швидко завершувався з помилкою, а не споживав увесь бюджет release-check. Якщо ці shards незалежно перебудовують повну source Docker target, release run налаштований неправильно і марнуватиме wall clock на дубльовані збірки образів.
 
 ## Package Acceptance
 
-Використовуйте `Package Acceptance`, коли питання таке: «чи працює цей інстальований пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі виконують після встановлення або оновлення.
+Використовуйте `Package Acceptance`, коли питання звучить як "чи працює цей інстальований пакет OpenClaw як продукт?" Це відрізняється від звичайного CI: звичайний CI перевіряє source tree, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі задіюють після встановлення або оновлення.
 
 ### Завдання
 
-1. `resolve_package` виконує checkout `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить джерело, посилання робочого процесу, посилання пакета, версію, SHA-256 і профіль у підсумку кроку GitHub.
-2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний робочий процес завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує package-digest Docker-образи і запускає вибрані Docker лінії проти цього пакета замість пакування checkout робочого процесу. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний робочий процес готує пакет і спільні образи один раз, а потім розгортає ці лінії як паралельні цільові Docker-завдання з унікальними артефактами.
-3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance розв’язав його; окремий dispatch Telegram усе ще може встановити опубліковану npm-специфікацію.
-4. `summary` завершує робочий процес з помилкою, якщо розв’язання пакета, Docker acceptance або необов’язкова лінія Telegram завершилися невдало.
+1. `resolve_package` виконує checkout `workflow_ref`, розв'язує один package candidate, записує `.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 завантажує цей артефакт, перевіряє tarball inventory, за потреби готує package-digest Docker images і запускає вибрані Docker lanes проти цього пакета замість пакування workflow checkout. Коли profile вибирає кілька цільових `docker_lanes`, reusable workflow один раз готує пакет і спільні образи, а потім розгалужує ці lanes у паралельні targeted Docker jobs з унікальними артефактами.
+3. `package_telegram` за бажанням викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance розв'язав його; standalone Telegram dispatch усе ще може встановити опубліковану npm spec.
+4. `summary` завершує workflow з помилкою, якщо package resolution, Docker acceptance або необов'язкова Telegram lane завершилися невдало.
 
 ### Джерела кандидатів
 
-- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію випуску OpenClaw, як-от `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованого передрелізу/стабільного випуску.
-- `source=ref` пакує довірену гілку, тег або повний SHA коміту `package_ref`. Розв’язувач отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілок репозиторію або тегу випуску, встановлює залежності у відокремленому worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`.
-- `source=url` завантажує HTTPS `.tgz`; `package_sha256` обов’язковий.
-- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його слід надати для зовнішньо поширених артефактів.
+- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для acceptance опублікованого prerelease/stable.
+- `source=ref` пакує trusted `package_ref` branch, tag або full commit SHA. Resolver завантажує OpenClaw branches/tags, перевіряє, що вибраний коміт досяжний з історії гілок репозиторію або release tag, встановлює deps у detached worktree і пакує його через `scripts/package-openclaw-for-docker.mjs`.
+- `source=url` завантажує HTTPS `.tgz`; `package_sha256` є обов'язковим.
+- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` є необов'язковим, але його варто вказувати для зовнішньо поширених артефактів.
 
-Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код робочого процесу/harness, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточному тестовому harness перевіряти старіші довірені коміти вихідного коду без запуску старої логіки робочого процесу.
+Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це trusted workflow/harness code, який запускає тест. `package_ref` — це source commit, який пакується, коли `source=ref`. Це дає поточному test harness змогу перевіряти старіші trusted source commits без запуску старої workflow logic.
 
-### Профілі наборів
+### Профілі suite
 
 - `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
-- `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom`
+- `full` — повні Docker release-path chunks з OpenWebUI
+- `custom` — точні `docker_lanes`; обов'язково, коли `suite_profile=custom`
 
-Профіль `package` використовує offline plugin покриття, щоб перевірка опублікованого пакета не залежала від live доступності ClawHub. Необов’язкова лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації зберігається для окремих dispatch.
+Профіль `package` використовує offline plugin coverage, щоб валідація published-package не залежала від live доступності ClawHub. Необов'язкова Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а published npm spec path збережено для standalone dispatches.
 
-Для спеціальної політики тестування оновлень і plugin, включно з локальними командами,
-Docker лініями, входами Package Acceptance, типовими значеннями випуску та тріажем збоїв,
-див. [Тестування оновлень і plugin](/uk/help/testing-updates-plugins).
+Щодо спеціальної політики тестування оновлень і plugins, включно з локальними командами, Docker lanes, inputs Package Acceptance, release defaults і triage збоїв, див. [Тестування оновлень і plugins](/uk/help/testing-updates-plugins).
 
-Release checks викликають Package Acceptance з `source=artifact`, підготовленим артефактом пакета випуску, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'` і `telegram_mode=mock-openai`. Це тримає перевірку міграції пакета, оновлення, очищення застарілих залежностей plugin, відновлення встановлення налаштованого plugin, offline plugin, plugin-update і Telegram на тому самому розв’язаному tarball пакета. Встановіть `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму матрицю проти вже доставленого npm-пакета замість артефакту, зібраного з SHA. Cross-OS release checks все ще покривають специфічну для ОС поведінку onboarding, installer і platform; перевірка продукту package/update має починатися з Package Acceptance. Docker лінія `published-upgrade-survivor` перевіряє один опублікований baseline пакета за запуск у блокувальному шляху випуску. У Package Acceptance розв’язаний tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback опублікований baseline, за замовчуванням `openclaw@latest`; команди перезапуску невдалих ліній зберігають цей baseline. Full Release Validation з `run_release_soak=true` або `release_profile=full` встановлює `published_upgrade_survivor_baselines=all-since-2026.4.23` і `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити перевірку на всі стабільні npm-випуски від `2026.4.23` до `latest` і issue-shaped fixtures для конфігурації Feishu, збережених файлів bootstrap/persona, встановлень налаштованих OpenClaw plugin, tilde шляхів журналів і застарілих коренів залежностей legacy plugin. Окремий робочий процес `Update Migration` використовує Docker лінію `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає у вичерпному очищенні опублікованих оновлень, а не у звичайній широті Full Release CI. Локальні агреговані запуски можуть передавати точні специфікації пакетів через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, зберігати одну лінію з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, як-от `openclaw@2026.4.15`, або встановити `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для матриці сценаріїв. Опублікована лінія налаштовує baseline за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також статус RPC після запуску Gateway. Windows packaged і installer fresh лінії також перевіряють, що встановлений пакет може імпортувати browser-control override з сирого абсолютного Windows-шляху. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли його встановлено, інакше `openai/gpt-5.4`, тому install і gateway proof залишаються на тестовій моделі GPT-5, уникаючи типових значень GPT-4.x.
+Release checks викликають Package Acceptance з `source=artifact`, підготовленим артефактом release package, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'` і `telegram_mode=mock-openai`. Це утримує package migration, update, stale-plugin-dependency cleanup, configured-plugin install repair, offline plugin, plugin-update і Telegram proof на тому самому розв'язаному package tarball. Установіть `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму матрицю проти shipped npm package замість SHA-built artifact. Cross-OS release checks усе ще покривають OS-specific onboarding, installer і platform behavior; package/update product validation має починатися з Package Acceptance. Docker lane `published-upgrade-survivor` перевіряє один published package baseline за прогін у blocking release path. У Package Acceptance розв'язаний tarball `package-under-test` завжди є candidate, а `published_upgrade_survivor_baseline` вибирає fallback published baseline, за замовчуванням `openclaw@latest`; команди перезапуску failed-lane зберігають цей baseline. Full Release Validation з `run_release_soak=true` або `release_profile=full` встановлює `published_upgrade_survivor_baselines=all-since-2026.4.23` і `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити перевірку на всі stable npm releases від `2026.4.23` до `latest` і issue-shaped fixtures для Feishu config, збережених bootstrap/persona files, налаштованих встановлень OpenClaw plugin, tilde log paths і застарілих legacy plugin dependency roots. Окремий workflow `Update Migration` використовує Docker lane `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає у вичерпному published update cleanup, а не у звичайній широті Full Release CI. Локальні агреговані запуски можуть передавати точні package specs через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, залишати одну lane з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або встановлювати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для scenario matrix. Published lane налаштовує baseline за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також RPC status після старту Gateway. Windows packaged і installer fresh lanes також перевіряють, що встановлений пакет може імпортувати browser-control override із raw absolute Windows path. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо встановлено, інакше `openai/gpt-5.4`, тож install і gateway proof залишаються на GPT-5 test model, уникаючи GPT-4.x defaults.
 
-### Вікна legacy сумісності
+### Вікна legacy compatibility
 
-Package Acceptance має обмежені вікна legacy сумісності для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності:
+Package Acceptance має обмежені вікна legacy-compatibility для вже опублікованих packages. Packages до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати compatibility path:
 
-- відомі приватні QA entries у `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball;
-- `doctor-switch` може пропустити підвипадок збереження `gateway install --wrapper`, коли пакет не експонує цей прапорець;
-- `update-channel-switch` може вилучати відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і може логувати відсутній збережений `update.channel`;
-- plugin smokes можуть читати legacy розташування install-record або приймати відсутність збереження marketplace install-record;
-- `plugin-update` може дозволяти міграцію metadata конфігурації, водночас усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними.
+- відомі private QA entries у `dist/postinstall-inventory.json` можуть указувати на файли, пропущені в tarball;
+- `doctor-switch` може пропускати підвипадок persistence `gateway install --wrapper`, коли package не надає цей flag;
+- `update-channel-switch` може вилучати відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і може логувати відсутній persisted `update.channel`;
+- plugin smokes можуть читати legacy install-record locations або приймати відсутню marketplace install-record persistence;
+- `plugin-update` може дозволяти config metadata migration, водночас усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними.
 
-Опублікований пакет `2026.4.26` також може попереджати про локальні stamp-файли build metadata, які вже були доставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови завершуються помилкою замість попередження або пропуску.
+Опублікований package `2026.4.26` також може попереджати про local build metadata stamp files, які вже були shipped. Пізніші packages мають відповідати сучасним contracts; ті самі умови завершуються помилкою замість попередження або пропуску.
 
 ### Приклади
 
@@ -323,110 +317,110 @@ gh workflow run package-acceptance.yml \
   -f docker_lanes='install-e2e plugin-update'
 ```
 
-Під час налагодження невдалого запуску package acceptance починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lane, таймінги фаз і команди повторного запуску. Віддавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes, а не повторному запуску повної валідації релізу.
+Під час налагодження невдалого запуску приймання пакета починайте із зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його артефакти Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lane, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes замість повторного запуску повної валідації релізу.
 
-## Інсталяційний smoke-тест
+## Інсталяційний smoke
 
-Окремий робочий процес `Install Smoke` повторно використовує той самий scope-скрипт через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
+Окремий workflow `Install Smoke` повторно використовує той самий скрипт визначення scope через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
 
-- **Швидкий шлях** запускається для pull request, які змінюють поверхні Docker/пакетів, зміни пакетів/маніфестів bundled plugin або поверхні ядра plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише вихідного коду bundled plugin, зміни лише тестів і зміни лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає smoke-тест CLI для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє аргумент збірки bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним таймаутом команди 240 секунд (Docker-запуск кожного сценарію обмежується окремо).
-- **Повний шлях** зберігає QR package install і installer Docker/update покриття для нічних запланованих запусків, ручних dispatch, workflow-call release checks і pull request, які справді торкаються поверхонь installer/package/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR-образ root Dockerfile smoke для цільового SHA, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий bundled-plugin Docker E2E як окремі завдання, щоб робота installer не чекала за root image smokes.
+- **Швидкий шлях** запускається для pull request, що зачіпають Docker/package поверхні, зміни пакета або маніфесту bundled Plugin, або поверхні core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише вихідного коду bundled Plugin, зміни лише тестів і зміни лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI smoke видалення agents для спільного workspace, запускає container gateway-network e2e, перевіряє build arg для bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним таймаутом команди 240 секунд (Docker-запуск кожного сценарію обмежено окремо).
+- **Повний шлях** зберігає QR package install і installer Docker/update coverage для нічних запланованих запусків, ручних dispatch, workflow-call release checks і pull request, які справді зачіпають installer/package/Docker поверхні. У повному режимі install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий bundled-plugin Docker E2E як окремі завдання, щоб робота installer не чекала за root image smokes.
 
-Пуші в `main` (включно з merge-комітами) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття під час push, робочий процес залишає швидкий Docker smoke і передає повний install smoke нічному запуску або валідації релізу.
+Пуші в `main` (включно з merge commit) не примушують повний шлях; коли логіка changed-scope просила б повне покриття під час push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або релізної валідації.
 
-Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з робочого процесу release checks, а ручні dispatch `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` не роблять цього. QR і installer Docker-тести зберігають власні Dockerfile, орієнтовані на інсталяцію.
+Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow release checks, а ручні dispatch `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` - ні. QR і installer Docker tests зберігають власні Dockerfile, сфокусовані на інсталяції.
 
 ## Локальний Docker E2E
 
-`pnpm test:docker:all` попередньо збирає один спільний образ live-test, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
+`pnpm test:docker:all` попередньо збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
 
-- чистий Node/Git runner для installer/update/plugin-dependency lanes;
-- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних lanes.
+- базовий Node/Git runner для lanes installer/update/plugin-dependency;
+- функціональний образ, який інсталює той самий tarball у `/app` для lanes звичайної функціональності.
 
-Визначення Docker lane розміщені в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для кожної lane за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
+Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Scheduler вибирає образ для кожної lane через `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
 
 ### Параметри налаштування
 
 | Змінна                                | Типово  | Призначення                                                                                   |
-| -------------------------------------- | ------- | --------------------------------------------------------------------------------------------- |
-| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10      | Кількість слотів основного пулу для звичайних lanes.                                          |
-| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10      | Кількість слотів tail-пулу, чутливого до провайдерів.                                         |
-| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9       | Ліміт одночасних live lanes, щоб провайдери не throttled.                                     |
-| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10      | Ліміт одночасних lanes для npm install.                                                       |
+| ------------------------------------- | ------- | --------------------------------------------------------------------------------------------- |
+| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10      | Кількість слотів main-pool для звичайних lanes.                                               |
+| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10      | Кількість слотів tail-pool, чутливих до provider.                                             |
+| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9       | Ліміт одночасних live lanes, щоб providers не throttling.                                     |
+| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10      | Ліміт одночасних lanes інсталяції npm.                                                        |
 | `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7       | Ліміт одночасних multi-service lanes.                                                         |
-| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000    | Затримка між стартами lanes, щоб уникнути хвиль create у Docker daemon; задайте `0`, щоб вимкнути затримку. |
-| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000 | Резервний таймаут на lane (120 хвилин); вибрані live/tail lanes використовують жорсткіші обмеження. |
-| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | unset   | `1` друкує план планувальника без запуску lanes.                                              |
-| `OPENCLAW_DOCKER_ALL_LANES`            | unset   | Список точних lanes через кому; пропускає cleanup smoke, щоб агенти могли відтворити одну невдалу lane. |
+| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000    | Затримка між стартами lanes, щоб уникнути create storms демона Docker; встановіть `0`, щоб вимкнути затримку. |
+| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000 | Резервний таймаут на lane (120 хвилин); вибрані live/tail lanes використовують жорсткіші ліміти. |
+| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | unset   | `1` друкує план scheduler без запуску lanes.                                                  |
+| `OPENCLAW_DOCKER_ALL_LANES`            | unset   | Розділений комами точний список lanes; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу lane. |
 
-Lane, важча за свій ефективний ліміт, все одно може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальні сукупні preflight перевіряють Docker, видаляють застарілі OpenClaw E2E-контейнери, виводять статус активних lanes, зберігають таймінги lanes для впорядкування longest-first і за замовчуванням зупиняють планування нових pooled lanes після першої помилки.
+Lane, важча за свій ефективний ліміт, усе ще може стартувати з порожнього pool, а потім працює сама, доки не звільнить capacity. Локальні сукупні preflights перевіряють Docker, видаляють застарілі контейнери OpenClaw E2E, виводять статус активних lanes, зберігають таймінги lanes для впорядкування longest-first і за замовчуванням припиняють планування нових pooled lanes після першої помилки.
 
-### Багаторазовий live/E2E робочий процес
+### Повторно використовуваний live/E2E workflow
 
-Багаторазовий live/E2E робочий процес запитує `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, lane і облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і зведення. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає та пушить bare/functional GHCR Docker E2E-образи з тегом package digest через Docker layer cache Blacksmith, коли план потребує lanes із встановленим пакетом; і повторно використовує передані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest образи замість повторної збірки. Завантаження Docker-образів повторюються з обмеженим 180-секундним таймаутом на спробу, щоб завислий registry/cache stream швидко повторювався, а не забирав більшість критичного шляху CI.
+Повторно використовуваний live/E2E workflow запитує `scripts/test-docker-all.mjs --plan-json`, який пакет, тип образу, live image, lane і покриття облікових даних потрібні. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета з поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає та публікує позначені package-digest bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли плану потрібні lanes з інстальованим пакетом; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість повторної збірки. Pull образів Docker повторюється з обмеженим таймаутом 180 секунд на спробу, щоб завислий потік registry/cache швидко повторювався, а не споживав більшу частину критичного шляху CI.
 
-### Частини release-path
+### Фрагменти релізного шляху
 
-Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний тип образу й виконував кілька lanes через той самий зважений планувальник:
+Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний тип образу й виконував кілька lanes через той самий 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`
 
-Поточні 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. Lane alias `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes.
+Поточні 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 lane `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes.
 
-OpenWebUI включається в `plugins-runtime-services`, коли повне release-path coverage запитує його, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Bundled-channel update lanes повторюють спробу один раз у разі тимчасових npm network failures.
+OpenWebUI включено до `plugins-runtime-services`, коли повне release-path coverage цього вимагає, і зберігає окремий chunk `openwebui` лише для OpenWebUI-only dispatches. Bundled-channel update lanes повторюють запуск один раз у разі тимчасових мережевих збоїв npm.
 
-Кожен chunk завантажує `.artifacts/docker-tests/` з журналами lanes, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями slow-lane і командами повторного запуску для кожної lane. Input робочого процесу `docker_lanes` запускає вибрані lanes проти підготовлених образів замість chunk jobs, що обмежує налагодження failed-lane одним цільовим Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана lane є live Docker lane, цільове job збирає live-test образ локально для цього повторного запуску. Згенеровані команди повторного запуску GitHub для кожної lane містять `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, щоб невдала lane могла повторно використати точний пакет і образи з невдалого запуску.
+Кожен chunk завантажує `.artifacts/docker-tests/` з журналами lanes, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, scheduler plan JSON, таблицями slow-lane і командами повторного запуску для кожної lane. Input workflow `docker_lanes` запускає вибрані lanes проти підготовлених образів замість chunk jobs, що обмежує налагодження failed-lane одним цільовим Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана lane є live Docker lane, цільове job збирає live-test image локально для цього повторного запуску. Згенеровані GitHub-команди повторного запуску для кожної lane включають `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, щоб невдала lane могла повторно використати точний пакет і образи з невдалого запуску.
 
 ```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 робочий процес щодня запускає повний release-path Docker suite.
+Запланований live/E2E workflow щодня запускає повний release-path Docker suite.
 
-## Передреліз Plugin
+## Plugin Prerelease
 
-`Plugin Prerelease` є дорожчим product/package coverage, тому це окремий робочий процес, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, пуші в `main` і автономні ручні CI dispatch не вмикають цей suite. Він балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy plugin batches не створювали додаткові CI jobs. Release-only Docker prerelease path групує цільові Docker lanes у невеликі групи, щоб не резервувати десятки runners для завдань тривалістю від однієї до трьох хвилин.
+`Plugin Prerelease` - це дорожче product/package coverage, тому це окремий workflow, який dispatch виконує `Full Release Validation` або явний оператор. Звичайні pull request, пуші в `main` і автономні ручні CI dispatches не запускають цей suite. Він балансує тести bundled Plugin між вісьмома extension workers; ці extension shard jobs запускають до двох груп конфігурації Plugin одночасно з одним Vitest worker на групу та більшим heap Node, щоб import-heavy Plugin batches не створювали додаткові CI jobs. Релізний Docker prerelease path групує цільові Docker lanes у невеликі групи, щоб не резервувати десятки runners для jobs тривалістю від однієї до трьох хвилин.
 
 ## QA Lab
 
-QA Lab має виділені CI lanes поза основним smart-scoped workflow. Agentic parity вкладений у широкі QA та release harnesses, а не є окремим PR workflow. Використовуйте `Full Release Validation` з `rerun_group=qa-parity`, коли parity має йти разом із широким validation run.
+QA Lab має виділені CI lanes поза основним smart-scoped workflow. Agentic parity вкладено під широкі QA та release harnesses, а не в окремий PR workflow. Використовуйте `Full Release Validation` з `rerun_group=qa-parity`, коли parity має виконуватися разом із широким validation run.
 
-- Робочий процес `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.
+- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і за ручним dispatch; він розгортає mock parity lane, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases.
 
-Release checks запускають Matrix і Telegram live transport lanes з deterministic mock provider і mock-qualified models (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб channel contract був ізольований від live model latency і звичайного startup provider-plugin. Live transport gateway вимикає memory search, бо QA parity окремо покриває поведінку memory; provider connectivity покривається окремими live model, native provider і Docker provider suites.
+Release checks запускають Matrix і Telegram live transport lanes з детермінованим mock provider і mock-qualified models (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб contract каналу було ізольовано від затримки live model і звичайного запуску provider-plugin. Live transport Gateway вимикає memory search, тому що QA parity покриває поведінку memory окремо; provider connectivity покривають окремі live model, native provider і Docker provider suites.
 
-Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише тоді, коли checked-out CLI підтримує це. CLI default і manual workflow input залишаються `all`; manual dispatch `matrix_profile=all` завжди шардить повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
+Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише коли checked-out CLI це підтримує. Типове значення CLI і manual workflow input залишаються `all`; ручний dispatch `matrix_profile=all` завжди розбиває повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
 
-`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у невелике report job для фінального parity comparison.
+`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед approval релізу; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва артефакти в невелике report job для фінального порівняння parity.
 
-Для звичайних PR дотримуйтеся scoped CI/check evidence замість того, щоб розглядати parity як required status.
+Для звичайних PR дотримуйтеся scoped CI/check evidence замість того, щоб вважати parity обов'язковим status.
 
 ## CodeQL
 
-Робочий процес `CodeQL` навмисно є вузьким сканером безпеки першого проходу, а не повним скануванням репозиторію. Щоденні, ручні та захисні запуски для non-draft pull request сканують код Actions workflow, а також найризикованіші поверхні JavaScript/TypeScript за допомогою високонадійних запитів безпеки, відфільтрованих до високого/критичного `security-severity`.
+Робочий процес `CodeQL` навмисно є вузьким сканером безпеки першого проходу, а не повним переглядом репозиторію. Щоденні, ручні та захисні запуски для нечернеткових pull request сканують код робочих процесів Actions, а також поверхні JavaScript/TypeScript із найвищим ризиком за допомогою високодостовірних запитів безпеки, відфільтрованих до високої/критичної `security-severity`.
 
-Захист pull request залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і виконує ту саму високонадійну матрицю безпеки, що й запланований workflow. Android і macOS CodeQL не входять до типових PR-запусків.
+Захист pull request залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src` і виконує ту саму високодостовірну матрицю безпеки, що й запланований робочий процес. Android і macOS CodeQL не входять до стандартних PR-запусків.
 
 ### Категорії безпеки
 
-| Категорія                                        | Поверхня                                                                                                                               |
-| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-security-high/core-auth-secrets`         | Автентифікація, секрети, sandbox, cron і базовий рівень Gateway                                                                        |
-| `/codeql-security-high/channel-runtime-boundary`  | Контракти реалізації основних каналів плюс runtime плагіна каналу, Gateway, Plugin SDK, секрети, точки дотику аудиту                 |
-| `/codeql-security-high/network-ssrf-boundary`     | Основні поверхні SSRF, розбору IP, мережевого захисту, web-fetch і політики SSRF у Plugin SDK                                          |
-| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, допоміжні засоби виконання процесів, вихідна доставка та шлюзи виконання інструментів агентом                            |
-| `/codeql-security-high/plugin-trust-boundary`     | Поверхні довіри для встановлення Plugin, завантажувача, маніфесту, реєстру, встановлення package-manager, завантаження джерел і контракту пакета Plugin SDK |
+| Категорія                                        | Поверхня                                                                                                                         |
+| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
+| `/codeql-security-high/core-auth-secrets`         | Автентифікація, секрети, sandbox, cron і базовий рівень gateway                                                                  |
+| `/codeql-security-high/channel-runtime-boundary`  | Контракти реалізації основних каналів плюс runtime channel plugin, gateway, Plugin SDK, секрети, точки дотику аудиту              |
+| `/codeql-security-high/network-ssrf-boundary`     | Основні поверхні SSRF, розбору IP, мережевого захисту, web-fetch і політики SSRF у Plugin SDK                                    |
+| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, помічники виконання процесів, вихідна доставка та шлюзи виконання інструментів агентом                              |
+| `/codeql-security-high/plugin-trust-boundary`     | Поверхні довіри встановлення Plugin, завантажувача, маніфесту, registry, встановлення package-manager, завантаження джерел і контракту пакетів Plugin SDK |
 
-### Платформоспецифічні фрагменти безпеки
+### Платформозалежні шарди безпеки
 
-- `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 навіть коли все чисто.
+- `CodeQL Android Critical Security` — запланований шард безпеки Android. Збирає Android-застосунок вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому перевіркою коректності робочого процесу. Завантажує результати під `/codeql-critical-security/android`.
+- `CodeQL macOS Critical Security` — щотижневий/ручний шард безпеки macOS. Збирає macOS-застосунок вручну для CodeQL на Blacksmith macOS, відфільтровує результати збірки залежностей із завантажуваного SARIF і завантажує результати під `/codeql-critical-security/macos`. Залишається поза щоденними стандартними запусками, бо збірка macOS домінує за часом виконання навіть коли проходить чисто.
 
 ### Категорії критичної якості
 
-`CodeQL Critical Quality` — відповідний фрагмент не для безпеки. Він виконує лише запити якості JavaScript/TypeScript з error-severity, не пов’язані з безпекою, на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його захист pull request навмисно менший за запланований профіль: non-draft 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/server-method, runtime пам’яті/SDK-зв’язуванні, MCP/процесах/вихідній доставці, runtime провайдера/каталозі моделей, діагностиці сеансів/чергах доставки, завантажувачі Plugin, Plugin SDK/контракті пакета або runtime відповідей Plugin SDK. Зміни конфігурації CodeQL і workflow якості запускають усі дванадцять PR-фрагментів якості.
+`CodeQL Critical Quality` — відповідний небезпечносторонній шард. Він запускає лише JavaScript/TypeScript-запити якості з рівнем помилки, не пов’язані з безпекою, на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його захист pull request навмисно менший за запланований профіль: нечернеткові PR запускають лише відповідні шарди `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін у коді виконання команд/моделей/інструментів агентом і диспетчеризації відповідей, схемі/міграції/IO конфігурації, коді автентифікації/секретів/sandbox/безпеки, runtime основного каналу та вбудованого channel plugin, протоколі Gateway/server-method, runtime пам’яті/SDK-зв’язці, MCP/process/вихідній доставці, runtime провайдера/каталозі моделей, діагностиці сесій/чергах доставки, завантажувачі Plugin, Plugin SDK/контракті пакетів або runtime відповідей Plugin SDK. Зміни конфігурації CodeQL і робочого процесу якості запускають усі дванадцять PR-шардів якості.
 
 Ручний dispatch приймає:
 
@@ -434,40 +428,40 @@ Matrix використовує `--profile fast` для scheduled і release gat
 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
 ```
 
-Вузькі профілі є навчальними/ітераційними хуками для запуску одного фрагмента якості ізольовано.
+Вузькі профілі є навчальними/ітераційними хуками для запуску одного шарда якості ізольовано.
 
-| Категорія                                              | Поверхня                                                                                                                                                              |
-| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/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`       | Виконання команд, диспетчеризація моделей/провайдерів, диспетчеризація й черги автовідповідей, а також runtime-контракти контрольної площини ACP                    |
-| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-сервери та мости інструментів, допоміжні засоби нагляду за процесами й контракти вихідної доставки                                                              |
-| `/codeql-critical-quality/memory-runtime-boundary`      | SDK хоста пам’яті, фасади runtime пам’яті, псевдоніми Plugin SDK для пам’яті, зв’язувальний код активації runtime пам’яті та команди doctor для пам’яті             |
-| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішні частини черги відповідей, черги доставки сеансів, допоміжні засоби прив’язування/доставки вихідних сеансів, поверхні діагностичних подій/log bundle і CLI-контракти session doctor |
-| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Вхідна диспетчеризація відповідей Plugin SDK, допоміжні засоби payload/chunking/runtime для відповідей, параметри відповідей каналу, черги доставки та допоміжні засоби прив’язування сеансу/потоку |
-| `/codeql-critical-quality/provider-runtime-boundary`    | Нормалізація каталогу моделей, автентифікація та discovery провайдера, реєстрація runtime провайдера, типові налаштування/каталоги провайдера та реєстри web/search/fetch/embedding |
-| `/codeql-critical-quality/ui-control-plane`             | Початкове завантаження Control UI, локальна персистентність, контрольні потоки Gateway і runtime-контракти контрольної площини завдань                              |
-| `/codeql-critical-quality/web-media-runtime-boundary`   | Основні runtime-контракти web fetch/search, media IO, розуміння медіа, image-generation і media-generation                                                          |
-| `/codeql-critical-quality/plugin-boundary`              | Контракти завантажувача, реєстру, публічної поверхні та entrypoint Plugin SDK                                                                                        |
-| `/codeql-critical-quality/plugin-sdk-package-contract`  | Опубліковані package-side джерела Plugin SDK і допоміжні засоби контракту пакета плагіна                                                                             |
+| Категорія                                              | Поверхня                                                                                                                                                           |
+| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `/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`     | Контракти реалізації основного каналу та вбудованого channel plugin                                                                                                |
+| `/codeql-critical-quality/agent-runtime-boundary`       | Виконання команд, диспетчеризація моделей/провайдерів, диспетчеризація автоматичних відповідей і черги, а також runtime-контракти контрольної площини ACP                                               |
+| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-сервери та мости інструментів, помічники нагляду за процесами й контракти вихідної доставки                                                                        |
+| `/codeql-critical-quality/memory-runtime-boundary`      | SDK хоста пам’яті, фасади runtime пам’яті, псевдоніми пам’яті Plugin SDK, зв’язка активації runtime пам’яті та команди doctor пам’яті                                    |
+| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішня реалізація черги відповідей, черги доставки сесій, помічники прив’язки/доставки вихідних сесій, поверхні діагностичних подій/пакетів журналів і контракти CLI doctor для сесій |
+| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Вхідна диспетчеризація відповідей Plugin SDK, payload відповідей/чанкінг/runtime-помічники, параметри відповіді каналу, черги доставки та помічники прив’язки сесій/потоків             |
+| `/codeql-critical-quality/provider-runtime-boundary`    | Нормалізація каталогу моделей, автентифікація й виявлення провайдера, реєстрація runtime провайдера, стандартні значення/каталоги провайдера та registry для web/search/fetch/embedding    |
+| `/codeql-critical-quality/ui-control-plane`             | Завантаження Control UI, локальна персистентність, потоки керування Gateway і runtime-контракти контрольної площини задач                                                          |
+| `/codeql-critical-quality/web-media-runtime-boundary`   | Основні runtime-контракти web fetch/search, media IO, розуміння медіа, генерації зображень і генерації медіа                                                    |
+| `/codeql-critical-quality/plugin-boundary`              | Контракти завантажувача, registry, публічної поверхні та entrypoint Plugin SDK                                                                                             |
+| `/codeql-critical-quality/plugin-sdk-package-contract`  | Опубліковане джерело Plugin SDK на стороні пакета та помічники контракту пакета plugin                                                                                      |
 
-Якість залишається окремо від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і вбудованих плагінів слід додавати назад як scoped або sharded follow-up work лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
+Якість залишається окремою від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і вбудованих plugin слід додавати назад як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
 
-## Workflow для обслуговування
+## Робочі процеси супроводу
 
-### Docs Agent
+### Агент документації
 
-Workflow `Docs Agent` — це подієво-керована лінія обслуговування Codex для підтримання наявної документації відповідно до нещодавно змерджених змін. Він не має чистого розкладу: успішний CI-запуск non-bot push на `main` може його запустити, а manual dispatch може запускати його напряму. Workflow-run виклики пропускаються, коли `main` уже просунувся далі або коли інший non-skipped запуск Docs Agent був створений протягом останньої години. Коли він виконується, він переглядає діапазон комітів від попереднього non-skipped Docs Agent source SHA до поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені з часу останнього проходу документації.
+Робочий процес `Docs Agent` — це подієво-керована лінія супроводу Codex для підтримання наявної документації узгодженою з нещодавно доданими змінами. Він не має чистого розкладу: успішний CI-запуск після push не від бота на `main` може його запустити, а ручний dispatch може запустити його напряму. Виклики від workflow-run пропускаються, коли `main` уже посунувся далі або коли інший непропущений запуск Docs Agent був створений протягом останньої години. Коли він запускається, він переглядає діапазон комітів від попереднього непропущеного source SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з останнього проходу документації.
 
-### Test Performance Agent
+### Агент продуктивності тестів
 
-Workflow `Test Performance Agent` — це подієво-керована лінія обслуговування Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск non-bot push на `main` може його запустити, але він пропускається, якщо інший workflow-run виклик уже виконувався або виконується цього UTC-дня. Manual dispatch обходить цей денний activity gate. Лінія будує full-suite grouped Vitest performance report, дозволяє Codex робити лише невеликі coverage-preserving виправлення продуктивності тестів замість широких рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, що зменшують базову кількість успішних тестів. Якщо baseline має failing tests, Codex може виправляти лише очевидні збої, а after-agent full-suite report має пройти перед будь-яким комітом. Коли `main` просувається до того, як bot push потрапить у репозиторій, лінія перебазовує перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні stale patches пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму drop-sudo safety posture, що й docs agent.
+Робочий процес `Test Performance Agent` — це подієво-керована лінія супроводу Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск після push не від бота на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже виконувався або виконується цього UTC-дня. Ручний dispatch обходить цей щоденний шлюз активності. Лінія будує згрупований звіт продуктивності Vitest для повного набору, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт повного набору й відхиляє зміни, що зменшують базову кількість прохідних тестів. Якщо в базовій лінії є тести, що падають, Codex може виправляти лише очевидні помилки, а звіт повного набору після агента має пройти, перш ніж щось буде закомічено. Коли `main` просувається до того, як bot push потрапить у репозиторій, лінія перебазовує перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patch пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму drop-sudo safety posture, що й агент документації.
 
 ### Дублікати PR після merge
 
-Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для post-land duplicate cleanup. Типово він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR змерджено і що кожен дублікат має або спільне referenced issue, або overlapping changed hunks.
+Робочий процес `Duplicate PRs After Merge` — це ручний робочий процес для maintainer після land, призначений для очищення дублікатів. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед мутацією GitHub він перевіряє, що landed PR змержено і що кожен дублікат має або спільне referenced issue, або перекривні змінені hunks.
 
 ```bash
 gh workflow run duplicate-after-merge.yml \
@@ -476,29 +470,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 суворіший щодо архітектурних меж, ніж широкий platform scope CI:
+Локальна логіка changed-lane живе в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий обсяг CI-платформи:
 
 - зміни production-коду core запускають typecheck core prod і core test плюс core lint/guards;
-- зміни лише core test запускають тільки typecheck core test плюс core lint;
+- зміни лише тестів core запускають лише typecheck core test плюс core lint;
 - зміни production-коду extension запускають typecheck extension prod і extension test плюс extension lint;
-- зміни лише extension test запускають typecheck extension test плюс extension lint;
-- зміни публічного Plugin SDK або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core-контрактів (Vitest extension sweeps залишаються explicit test work);
-- metadata-only version bumps релізу запускають цільові перевірки version/config/root-dependency;
+- зміни лише тестів extension запускають typecheck extension test плюс extension lint;
+- зміни публічного Plugin SDK або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core-контрактів (Vitest sweeps для extension залишаються явною тестовою роботою);
+- version bumps лише release metadata запускають цільові перевірки version/config/root-dependency;
 - невідомі зміни root/config fail safe до всіх check lanes.
 
-Локальний changed-test routing міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі редагування тестів запускають самі себе, редагування джерел віддають перевагу явним mappings, потім sibling tests і import-graph dependents. Shared group-room delivery config є одним із явних mappings: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс регресії доставки Discord і Slack, щоб зміна shared default падала до першого 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`: прямі зміни тестів запускають самі себе, зміни джерел віддають перевагу явним мапінгам, а потім sibling tests і залежним від import graph. Спільна конфігурація доставки group-room є одним із явних мапінгів: зміни до конфігурації visible-reply для групи, режиму доставки source reply або system prompt message-tool проходять через core reply tests плюс регресії доставки Discord і Slack, щоб зміна спільного стандартного значення падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна достатньо широка для harness, що дешевий mapped set не є надійним proxy.
 
 ## Валідація Testbox
 
-Запускайте Testbox з кореня репозиторію і для широкого підтвердження надавайте перевагу свіжому прогрітому боксу. Перш ніж витрачати повільний гейт на бокс, який було повторно використано, строк дії якого минув або який щойно повідомив про неочікувано велику синхронізацію, спочатку запустіть `pnpm testbox:sanity` всередині боксу.
+Запускайте Testbox з кореня репозиторію та надавайте перевагу свіжому прогрітому боксу для широкого підтвердження. Перш ніж витрачати повільний гейт на бокс, який було повторно використано, термін дії якого минув або який щойно повідомив про несподівано велику синхронізацію, спочатку виконайте `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 — це репозиторна обгортка для віддалених боксів, призначена для maintainer Linux-підтверджень. Використовуйте її, коли перевірка занадто широка для локального циклу редагування, коли важливий паритет із CI або коли підтвердження потребує секретів, Docker, пакетних доріжок, повторно використовуваних боксів чи віддалених журналів. Звичайний бекенд OpenClaw — `blacksmith-testbox`; власні потужності AWS/Hetzner є fallback на випадок збоїв Blacksmith, проблем із квотами або явного тестування власних потужностей.
+Crabbox — це обгортка віддаленого боксу, що належить репозиторію, для Linux-підтверджень супровідників. Використовуйте її, коли перевірка занадто широка для локального циклу редагування, коли важлива паритетність із CI або коли підтвердження потребує секретів, Docker, package-ланів, повторно використовуваних боксів чи віддалених логів. Звичайний бекенд OpenClaw — `blacksmith-testbox`; власні потужності AWS/Hetzner є запасним варіантом для збоїв Blacksmith, проблем із квотою або явного тестування на власних потужностях.
 
 Перед першим запуском перевірте обгортку з кореня репозиторію:
 
@@ -506,7 +500,7 @@ Crabbox — це репозиторна обгортка для віддален
 pnpm crabbox:run -- --help | sed -n '1,120p'
 ```
 
-Репозиторна обгортка відмовляється від застарілого бінарного файлу Crabbox, який не оголошує `blacksmith-testbox`. Передавайте provider явно, навіть якщо `.crabbox.yaml` має типові значення для owned-cloud.
+Обгортка репозиторію відхиляє застарілий бінарний файл Crabbox, який не оголошує `blacksmith-testbox`. Передавайте провайдера явно, навіть якщо `.crabbox.yaml` має типові налаштування власної хмари.
 
 Гейт змін:
 
@@ -523,7 +517,7 @@ pnpm crabbox:run -- --provider blacksmith-testbox \
   "env CI=1 NODE_OPTIONS=--max-old-space-size=4096 OPENCLAW_TEST_PROJECTS_PARALLEL=6 OPENCLAW_VITEST_MAX_WORKERS=1 OPENCLAW_VITEST_NO_OUTPUT_TIMEOUT_MS=900000 pnpm check:changed"
 ```
 
-Точковий повторний запуск тесту:
+Цільовий повторний запуск тесту:
 
 ```bash
 pnpm crabbox:run -- --provider blacksmith-testbox \
@@ -553,21 +547,21 @@ pnpm crabbox:run -- --provider blacksmith-testbox \
   "env CI=1 NODE_OPTIONS=--max-old-space-size=4096 OPENCLAW_TEST_PROJECTS_PARALLEL=6 OPENCLAW_VITEST_MAX_WORKERS=1 OPENCLAW_VITEST_NO_OUTPUT_TIMEOUT_MS=900000 pnpm test"
 ```
 
-Прочитайте фінальний JSON-підсумок. Корисні поля: `provider`, `leaseId`, `syncDelegated`, `exitCode`, `commandMs` і `totalMs`. Одноразові запуски Crabbox на базі Blacksmith мають автоматично зупиняти Testbox; якщо запуск перервано або cleanup незрозумілий, перегляньте активні бокси й зупиніть лише ті бокси, які створили ви:
+Прочитайте фінальний JSON-підсумок. Корисні поля: `provider`, `leaseId`, `syncDelegated`, `exitCode`, `commandMs` і `totalMs`. Одноразові запуски Crabbox на базі Blacksmith мають автоматично зупиняти Testbox; якщо запуск перервано або очищення незрозуміле, перегляньте активні бокси й зупиняйте лише ті бокси, які створили ви:
 
 ```bash
 blacksmith testbox list
 blacksmith testbox stop --id <tbx_id>
 ```
 
-Використовуйте повторне використання лише тоді, коли вам навмисно потрібні кілька команд на тому самому hydrated-боксі:
+Використовуйте повторне використання лише тоді, коли вам навмисно потрібно кілька команд на тому самому гідратованому боксі:
 
 ```bash
 pnpm crabbox:run -- --provider blacksmith-testbox --id <tbx_id> --no-sync --timing-json --shell -- "pnpm test <path-or-filter>"
 pnpm crabbox:stop -- <tbx_id>
 ```
 
-Якщо зламаним шаром є Crabbox, але сам Blacksmith працює, використайте direct Blacksmith як вузький fallback:
+Якщо зламаним шаром є Crabbox, але сам Blacksmith працює, використайте прямий Blacksmith як вузький запасний варіант:
 
 ```bash
 blacksmith testbox warmup ci-check-testbox.yml --ref main --idle-timeout 90
@@ -575,7 +569,7 @@ blacksmith testbox run --id <tbx_id> "env CI=1 NODE_OPTIONS=--max-old-space-size
 blacksmith testbox stop --id <tbx_id>
 ```
 
-Переходьте до власних потужностей Crabbox лише коли Blacksmith недоступний, обмежений квотою, не має потрібного середовища або власні потужності є явною метою:
+Переходьте на власні потужності Crabbox лише тоді, коли Blacksmith недоступний, обмежений квотою, не має потрібного середовища або власні потужності явно є метою:
 
 ```bash
 pnpm crabbox:warmup -- --provider aws --class beast --market on-demand --idle-timeout 90m
@@ -584,7 +578,7 @@ pnpm crabbox:run -- --id <cbx_id-or-slug> --timing-json --shell -- "env NODE_OPT
 pnpm crabbox:stop -- <cbx_id-or-slug>
 ```
 
-`.crabbox.yaml` володіє типовими значеннями provider, синхронізації та GitHub Actions hydration для owned-cloud доріжок. Він виключає локальний `.git`, щоб hydrated checkout Actions зберігав власні віддалені Git metadata замість синхронізації maintainer-local remotes і object stores, а також виключає локальні артефакти runtime/build, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` володіє checkout, налаштуванням Node/pnpm, fetch `origin/main` і передачею несекретного середовища для owned-cloud команд `crabbox run --id <cbx_id>`.
+`.crabbox.yaml` володіє типовими налаштуваннями провайдера, синхронізації та гідратації GitHub Actions для ланів власної хмари. Він виключає локальний `.git`, щоб гідратований checkout Actions зберігав власні віддалені Git-метадані замість синхронізації локальних віддалених репозиторіїв і сховищ об’єктів супровідника, а також виключає локальні артефакти виконання/збірки, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` володіє checkout, налаштуванням Node/pnpm, отриманням `origin/main` і передаванням несекретного середовища для команд власної хмари `crabbox run --id <cbx_id>`.
 
 ## Пов’язане
 

docs/uk/reference/RELEASING.md

@@ -1,276 +1,276 @@
 ---
 read_when:
     - Шукаємо визначення публічних каналів випуску
-    - Запуск перевірки релізу або приймання пакета
-    - Шукаєте іменування версій і періодичність випусків
-summary: Релізні лінії, контрольний список оператора, середовища валідації, іменування версій і періодичність
+    - Запуск валідації релізу або приймання пакета
+    - Пошук правил іменування версій і періодичності випусків
+summary: Канали випусків, контрольний список оператора, середовища валідації, назви версій і періодичність
 title: Політика випусків
 x-i18n:
-    generated_at: "2026-05-04T22:29:51Z"
+    generated_at: "2026-05-05T01:33:43Z"
     model: gpt-5.5
     provider: openai
-    source_hash: fc9b8f82deb90c57c7777480013a5ee956d1123e0b16134daf90a94bc82952cb
+    source_hash: 41886d3bb2f970e6a86944e5ff207b1b29b1b64b1f234d45f626fed19cf032b3
     source_path: reference/RELEASING.md
     workflow: 16
 ---
 
-OpenClaw має три публічні канали випусків:
+OpenClaw має три публічні канали релізів:
 
-- stable: теговані випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
-- beta: передрелізні теги, які публікуються в npm `beta`
+- stable: позначені тегами релізи, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
+- beta: теги попередніх релізів, які публікуються в npm `beta`
 - dev: рухома вершина `main`
 
 ## Іменування версій
 
-- Версія стабільного випуску: `YYYY.M.D`
+- Версія стабільного релізу: `YYYY.M.D`
   - Git-тег: `vYYYY.M.D`
-- Версія стабільного коригувального випуску: `YYYY.M.D-N`
+- Версія коригувального стабільного релізу: `YYYY.M.D-N`
   - Git-тег: `vYYYY.M.D-N`
-- Версія бета-передрелізу: `YYYY.M.D-beta.N`
+- Версія попереднього beta-релізу: `YYYY.M.D-beta.N`
   - Git-тег: `vYYYY.M.D-beta.N`
-- Не додавайте нулі на початку місяця або дня
-- `latest` означає поточний просунутий стабільний випуск npm
-- `beta` означає поточну ціль встановлення бета-версії
-- Стабільні та стабільні коригувальні випуски за замовчуванням публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або пізніше просунути перевірену бета-збірку
-- Кожен стабільний випуск OpenClaw постачається разом із npm-пакетом і застосунком macOS;
-  бета-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а
-  збірку/підпис/нотаризацію застосунку mac залишають для стабільного випуску, якщо це явно не запитано
+- Не додавайте початковий нуль до місяця або дня
+- `latest` означає поточний просунутий стабільний npm-реліз
+- `beta` означає поточну ціль beta-встановлення
+- Стабільні та коригувальні стабільні релізи за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно націлити `latest` або пізніше просунути перевірену beta-збірку
+- Кожен стабільний реліз OpenClaw постачає npm-пакет і застосунок macOS разом;
+  beta-релізи зазвичай спершу перевіряють і публікують шлях npm/пакета, а
+  збирання/підписування/нотаризацію застосунку Mac залишають для стабільного релізу, якщо це не запитано явно
 
-## Частота випусків
+## Періодичність релізів
 
-- Випуски рухаються спочатку через beta
-- Stable виходить лише після перевірки останньої beta
-- Супровідники зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної
-  з поточного `main`, щоб перевірка випуску та виправлення не блокували нову
+- Релізи рухаються спершу через beta
+- Стабільний реліз виходить лише після перевірки останньої beta
+- Мейнтейнери зазвичай готують релізи з гілки `release/YYYY.M.D`, створеної
+  з поточного `main`, щоб перевірка релізу та виправлення не блокували нову
   розробку в `main`
-- Якщо beta-тег уже надіслано або опубліковано і потрібне виправлення, супровідники створюють
+- Якщо beta-тег уже надіслано або опубліковано й він потребує виправлення, мейнтейнери створюють
   наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега
-- Детальна процедура випуску, затвердження, облікові дані та нотатки з відновлення
-  призначені лише для супровідників
+- Детальна процедура релізу, погодження, облікові дані та нотатки з відновлення
+  призначені лише для мейнтейнерів
 
-## Контрольний список оператора випуску
+## Контрольний список оператора релізу
 
-Цей контрольний список є публічною формою процесу випуску. Приватні облікові дані,
+Цей контрольний список показує публічну форму процесу релізу. Приватні облікові дані,
 підписування, нотаризація, відновлення dist-tag і деталі екстреного відкоту залишаються в
-release runbook лише для супровідників.
+релізному runbook лише для мейнтейнерів.
 
 1. Почніть із поточного `main`: отримайте останні зміни, підтвердьте, що цільовий коміт надіслано,
    і підтвердьте, що поточний CI для `main` достатньо зелений, щоб створити від нього гілку.
 2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою
-   `/changelog`, залишайте записи орієнтованими на користувача, закомітьте його, надішліть і виконайте rebase/pull
+   `/changelog`, залишайте записи орієнтованими на користувача, закомітьте їх, надішліть і виконайте rebase/pull
    ще раз перед створенням гілки.
-3. Перегляньте записи сумісності випуску в
+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 мали спільну версію випуску
-   та метадані сумісності, потім запустіть локальний детермінований preflight:
+5. Оновіть кожне потрібне місце з версією для запланованого тега, виконайте
+   `pnpm plugins:sync`, щоб публіковні Plugin-пакети мали спільну релізну
+   версію та метадані сумісності, а потім запустіть локальний детермінований preflight:
    `pnpm check:test-types`, `pnpm check:architecture`,
    `pnpm build && pnpm ui:build`, `pnpm plugins:sync:check` і
    `pnpm release:check`.
 6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До існування тега
-   повний 40-символьний SHA гілки випуску дозволено для preflight лише з метою перевірки.
+   для preflight лише з перевіркою дозволено повний 40-символьний SHA релізної гілки.
    Збережіть успішний `preflight_run_id`.
 7. Запустіть усі передрелізні тести через `Full Release Validation` для
-   гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу
-   для чотирьох великих тестових блоків випуску: Vitest, Docker, QA Lab і Package.
-8. Якщо перевірка завершується невдало, виправте проблему в гілці випуску та повторно запустіть найменший невдалий
-   файл, канал, завдання workflow, профіль пакета, провайдера або allowlist моделі, що
-   доводить виправлення. Повторно запускайте весь umbrella лише тоді, коли змінена поверхня робить
+   релізної гілки, тега або повного SHA коміту. Це єдина ручна точка входу
+   для чотирьох великих релізних тестових блоків: Vitest, Docker, QA Lab і Package.
+8. Якщо перевірка не проходить, виправте в релізній гілці та повторно запустіть найменший невдалий
+   файл, канал, завдання workflow, профіль пакета, провайдер або allowlist моделей, який
+   доводить виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня робить
    попередні докази застарілими.
-9. Для beta позначте тегом `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з
+9. Для beta позначте `vYYYY.M.D-beta.N`, а потім запустіть `OpenClaw Release Publish` з
    відповідної гілки `release/YYYY.M.D`. Він перевіряє `pnpm plugins:sync:check`,
-   спочатку публікує всі публіковні пакети Plugin в npm, потім публікує той самий
-   набір у ClawHub як tarball-и ClawPack npm-pack, а потім просуває
-   підготовлений preflight-артефакт OpenClaw npm з відповідним dist-tag. Після
-   публікації запустіть приймальну перевірку пакета після публікації
-   для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або
-   `openclaw@beta`. Якщо надісланий або опублікований передреліз потребує виправлення,
-   створіть наступний відповідний номер передрелізу; не видаляйте і не перезаписуйте старий
-   передреліз.
-10. Для stable продовжуйте лише після того, як перевірена beta або release candidate має
-    необхідні докази перевірки. Публікація stable npm також проходить через
+   спершу публікує всі публіковні Plugin-пакети в npm, потім публікує той самий
+   набір у ClawHub як npm-pack tarball-и ClawPack, а потім просуває
+   підготовлений preflight-артефакт npm OpenClaw з відповідним dist-tag. Після
+   публікації запустіть post-publish package
+   acceptance для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або
+   `openclaw@beta`. Якщо надісланий або опублікований попередній реліз потребує виправлення,
+   створіть наступний відповідний номер попереднього релізу; не видаляйте й не переписуйте старий
+   попередній реліз.
+10. Для стабільного релізу продовжуйте лише після того, як перевірена beta або release candidate матиме
+    потрібні докази перевірки. Публікація стабільного релізу в npm також проходить через
     `OpenClaw Release Publish`, повторно використовуючи успішний preflight-артефакт через
-    `preflight_run_id`; готовність стабільного випуску macOS також вимагає
-    запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`.
-11. Після публікації запустіть npm-перевірник після публікації, необов’язковий автономний
-    published-npm Telegram E2E, коли потрібен доказ каналу після публікації,
+    `preflight_run_id`; готовність стабільного релізу macOS також вимагає
+    упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`.
+11. Після публікації запустіть post-publish verifier для npm, необов’язковий standalone
+    published-npm Telegram E2E, коли потрібен post-publish доказ каналу,
     просування dist-tag за потреби, нотатки GitHub release/prerelease з
-    повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску.
+    повного відповідного розділу `CHANGELOG.md` і кроки оголошення релізу.
 
-## Preflight випуску
+## Preflight релізу
 
 - Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався
   покритим поза швидшим локальним шлюзом `pnpm check`
 - Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів
   імпорту та архітектурних меж були зеленими поза швидшим локальним шлюзом
 - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
-  релізні артефакти `dist/*` і бандл Control UI існували для кроку
+  релізні артефакти `dist/*` і пакет Control UI існували для кроку
   валідації пакування
-- Запустіть `pnpm plugins:sync` після підвищення версії в корені й перед тегуванням. Він
-  оновлює версії пакетів придатних до публікації plugin, метадані сумісності
-  OpenClaw peer/API, метадані збірки та заготовки журналів змін plugin, щоб вони відповідали
-  версії основного релізу. `pnpm plugins:sync:check` — це немодифікувальний релізний запобіжник;
+- Запустіть `pnpm plugins:sync` після підняття кореневої версії та перед тегуванням. Він
+  оновлює версії публікованих пакетів plugin, метадані сумісності
+  peer/API OpenClaw, метадані збірки та заготовки журналу змін plugin відповідно до версії
+  основного релізу. `pnpm plugins:sync:check` — це немутуючий релізний запобіжник;
   workflow публікації завершується помилкою до будь-якої мутації реєстру, якщо цей крок було
   забуто.
 - Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб
   запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку,
   тег або повний SHA коміту, запускає ручний `CI` і запускає
-  `OpenClaw Release Checks` для install smoke, package acceptance, між-ОС
+  `OpenClaw Release Checks` для install smoke, package acceptance, крос-OS
   перевірок пакетів, паритету QA Lab, Matrix і Telegram lanes. Стабільні/типові запуски
-  тримають вичерпні live/E2E та Docker release-path soak за
+  тримають вичерпні live/E2E та Docker soak для релізного шляху за
   `run_release_soak=true`; `release_profile=full` примусово вмикає soak. З
   `release_profile=full` і `rerun_group=all` він також запускає package Telegram
-  E2E проти артефакту `release-package-under-test` із release checks.
+  E2E проти артефакту `release-package-under-test` з release checks.
   Надайте `npm_telegram_package_spec` після публікації, коли той самий
-  Telegram E2E має також підтвердити опублікований npm-пакет. Надайте
+  Telegram E2E також має підтвердити опублікований npm-пакет. Надайте
   `package_acceptance_package_spec` після публікації, коли Package Acceptance
-  має виконати свою матрицю package/update проти відвантаженого npm-пакета замість
-  артефакту, зібраного за SHA. Надайте
+  має запустити свою матрицю package/update проти відвантаженого npm-пакета замість
+  артефакту, зібраного з SHA. Надайте
   `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що
-  валідація відповідає опублікованому npm-пакету без примусового Telegram E2E.
+  валідація відповідає опублікованому npm-пакету без примусового запуску Telegram E2E.
   Приклад:
   `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
-- Запустіть ручний workflow `Package Acceptance`, коли потрібен side-channel доказ
+- Запустіть ручний workflow `Package Acceptance`, коли потрібне побічне підтвердження
   для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для
   `openclaw@beta`, `openclaw@latest` або точної версії релізу; `source=ref`,
   щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним
   harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим
   SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub
-  Actions. Workflow визначає кандидата як
+  Actions. Workflow розв’язує кандидата до
   `package-under-test`, повторно використовує Docker E2E release scheduler проти цього
-  tarball і може запускати Telegram QA проти того самого tarball з
+  tarball і може запустити Telegram QA проти того самого tarball з
   `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли
-  вибрані Docker lanes включають `published-upgrade-survivor`, артефакт пакета
+  вибрані Docker lanes містять `published-upgrade-survivor`, артефакт пакета
   є кандидатом, а `published_upgrade_survivor_baseline` вибирає
   опублікований baseline.
   Приклад: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai`
   Поширені профілі:
-  - `smoke`: lanes встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації
-  - `package`: artifact-native lanes package/update/plugin без OpenWebUI або live ClawHub
-  - `product`: профіль package плюс MCP-канали, очищення cron/subagent,
-    вебпошук OpenAI і OpenWebUI
-  - `full`: фрагменти Docker release-path з OpenWebUI
+  - `smoke`: install/channel/agent, gateway network і config reload lanes
+  - `package`: package/update/plugin lanes, нативні для артефакту, без OpenWebUI або live ClawHub
+  - `product`: package-профіль плюс MCP channels, очищення cron/subagent,
+    OpenAI web search і OpenWebUI
+  - `full`: Docker-фрагменти релізного шляху з OpenWebUI
   - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску
 - Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI
-  покриття для релізного кандидата. Ручні запуски CI обходять
-  changed scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel
+  покриття для кандидата релізу. Ручні CI dispatches обходять changed
+  scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel
   contracts, сумісність Node 22, `check`, `check-additional`, build smoke,
   перевірки docs, Python skills, Windows, macOS, Android і Control UI i18n
   lanes.
   Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D`
 - Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Він проганяє
-  QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace
+  QA-lab через локальний OTLP/HTTP-приймач і перевіряє експортовані назви trace
   span, обмежені атрибути та редагування вмісту/ідентифікаторів без
   потреби в Opik, Langfuse або іншому зовнішньому collector.
-- Запустіть `pnpm release:check` перед кожним тегованим релізом
-- Запустіть `OpenClaw Release Publish` для мутувальної послідовності публікації після того, як
+- Запускайте `pnpm release:check` перед кожним тегованим релізом
+- Запустіть `OpenClaw Release Publish` для мутуючої послідовності публікації після того, як
   тег існує. Запускайте його з `release/YYYY.M.D` (або `main`, коли публікуєте
-  тег, досяжний із main), передайте релізний тег і успішний OpenClaw npm
-  `preflight_run_id`, і залишайте типовий scope публікації plugin
-  `all-publishable`, якщо ви навмисно не виконуєте сфокусоване виправлення. Workflow
+  тег, досяжний з main), передайте релізний тег і успішний OpenClaw npm
+  `preflight_run_id`, і залиште типовий scope публікації plugin
+  `all-publishable`, якщо ви навмисно не запускаєте сфокусоване виправлення. Workflow
   серіалізує npm-публікацію plugin, публікацію plugin у ClawHub і npm-публікацію OpenClaw,
-  щоб основний пакет не був опублікований раніше за його зовнішні
+  щоб основний пакет не було опубліковано раніше за його винесені назовні
   plugins.
 - Release checks тепер виконуються в окремому ручному workflow:
   `OpenClaw Release Checks`
-- `OpenClaw Release Checks` також запускає mock parity lane QA Lab плюс швидкий
-  live-профіль Matrix і Telegram QA lane перед схваленням релізу. Live
-  lanes використовують середовище `qa-live-shared`; Telegram також використовує оренди
-  облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з
+- `OpenClaw Release Checks` також запускає QA Lab mock parity lane плюс швидкий
+  live Matrix profile і Telegram QA lane перед схваленням релізу. Live
+  lanes використовують середовище `qa-live-shared`; Telegram також використовує Convex CI
+  credential leases. Запустіть ручний workflow `QA-Lab - All Lanes` з
   `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix
   transport, media та E2EE паралельно.
-- Між-ОС валідація runtime встановлення й оновлення є частиною публічних
+- Крос-OS валідація runtime для install і upgrade є частиною публічних
   `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають
-  багаторазовий workflow
+  повторно використовуваний workflow
   `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
 - Цей поділ навмисний: тримайте реальний шлях npm-релізу коротким,
-  детермінованим і сфокусованим на артефактах, тоді як повільніші live-перевірки залишаються у своїй
+  детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються у своїй
   lane, щоб вони не затримували й не блокували публікацію
-- Release checks із секретами слід запускати через `Full Release
-Validation` або з workflow ref `main`/release, щоб логіка workflow і
-  секрети залишалися контрольованими
+- Релізні перевірки із секретами слід запускати через `Full Release
+Validation` або з ref workflow `main`/release, щоб логіка workflow і
+  secrets залишалися контрольованими
 - `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо
-  resolved commit досяжний із гілки OpenClaw або релізного тегу
-- Validation-only preflight `OpenClaw NPM Release` також приймає поточний
+  розв’язаний коміт досяжний з гілки OpenClaw або релізного тегу
+- validation-only preflight `OpenClaw NPM Release` також приймає поточний
   повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тегу
-- Цей шлях SHA є лише validation-only і не може бути підвищений до реальної публікації
-- У режимі SHA workflow синтезує `v<package.json version>` лише для
-  перевірки метаданих пакета; реальна публікація все одно потребує справжнього релізного тегу
-- Обидва workflow тримають реальний шлях публікації та promotion на GitHub-hosted
-  runners, тоді як немутувальний шлях валідації може використовувати більші
+- Цей шлях SHA призначений лише для валідації й не може бути підвищений до реальної публікації
+- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки
+  метаданих пакета; реальна публікація все одно вимагає справжнього релізного тегу
+- Обидва workflows тримають реальний шлях публікації та promotion на GitHub-hosted
+  runners, тоді як немутуючий шлях валідації може використовувати більші
   Blacksmith Linux runners
 - Цей workflow запускає
   `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
-  з використанням обох workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
+  з використанням workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
 - npm release preflight більше не чекає на окрему release checks lane
 - Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
-  (або відповідний тег beta/correction) перед схваленням
+  (або відповідний beta/correction tag) перед схваленням
 - Після npm publish запустіть
   `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  (або відповідну версію beta/correction), щоб перевірити шлях встановлення
-  опублікованого registry у свіжому тимчасовому prefix
+  (або відповідну beta/correction version), щоб перевірити опублікований registry
+  install path у свіжому тимчасовому 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`,
-  щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E
-  проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних Telegram.
-  Локальні одноразові maintainer-запуски можуть пропустити змінні Convex і передати три
-  env-облікові дані `OPENCLAW_QA_TELEGRAM_*` напряму.
-- Щоб запустити повний post-publish beta smoke з машини maintainer, використовуйте `pnpm release:beta-smoke -- --beta betaN`. Helper запускає Parallels-валідацію npm update/fresh-target, запускає `NPM Telegram Beta E2E`, опитує точний workflow run, завантажує артефакт і друкує Telegram-звіт.
-- Maintainers можуть запустити ту саму post-publish перевірку з GitHub Actions через
+  щоб перевірити onboarding установленого пакета, налаштування Telegram і реальний Telegram E2E
+  проти опублікованого npm-пакета з використанням спільного орендованого пулу Telegram credentials.
+  Локальні одноразові запуски maintainer можуть опускати Convex vars і передавати три
+  env credentials `OPENCLAW_QA_TELEGRAM_*` напряму.
+- Щоб запустити повний post-publish beta smoke з машини maintainer, використовуйте `pnpm release:beta-smoke -- --beta betaN`. Helper запускає Parallels npm update/fresh-target validation, dispatches `NPM Telegram Beta E2E`, polls exact workflow run, downloads artifact і prints Telegram report.
+- Maintainers можуть запускати ту саму post-publish перевірку з GitHub Actions через
   ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
   не запускається на кожному merge.
 - Автоматизація релізів maintainer тепер використовує preflight-then-promote:
-  - реальний npm publish має пройти успішний npm `preflight_run_id`
-  - реальний npm publish має бути запущений із тієї самої гілки `main` або
+  - реальна npm-публікація має пройти успішний npm `preflight_run_id`
+  - реальна npm-публікація має бути запущена з тієї самої гілки `main` або
     `release/YYYY.M.D`, що й успішний preflight run
-  - стабільні npm-релізи типово спрямовані на `beta`
-  - стабільний npm publish може явно спрямовуватися на `latest` через input workflow
-  - token-based мутація npm dist-tag тепер живе в
+  - стабільні npm-релізи типово спрямовуються на `beta`
+  - стабільна npm-публікація може явно націлюватися на `latest` через workflow input
+  - token-based npm dist-tag mutation тепер живе в
     `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
-    з міркувань безпеки, бо `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як
-    публічний репозиторій зберігає OIDC-only publish
-  - публічний `macOS Release` є validation-only; коли тег існує лише в
-    релізній гілці, але workflow запускається з `main`, задайте
+    з міркувань безпеки, бо `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як
+    публічний repo залишає OIDC-only publish
+  - публічний `macOS Release` є validation-only; коли тег існує лише на
+    release branch, але workflow запущено з `main`, задайте
     `public_release_branch=release/YYYY.M.D`
-  - реальний приватний mac publish має пройти успішні приватні mac
+  - реальний private mac publish має пройти успішні private mac
     `preflight_run_id` і `validate_run_id`
-  - реальні publish paths підвищують підготовлені артефакти замість повторної
-    їх збірки
+  - реальні шляхи publish просувають підготовлені артефакти замість повторного
+    їх rebuild
 - Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier
-  також перевіряє той самий шлях temp-prefix upgrade з `YYYY.M.D` до `YYYY.M.D-N`,
-  щоб release corrections не могли непомітно залишити старіші глобальні встановлення на
-  базовому стабільному payload
-- npm release preflight завершується закритою помилкою, якщо tarball не містить обох
-  `dist/control-ui/index.html` і непорожнього payload `dist/control-ui/assets/`,
+  також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`,
+  щоб release corrections не могли непомітно залишити старіші global installs на
+  базовому stable payload
+- npm release preflight fails closed, якщо tarball не містить одночасно
+  `dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`,
   щоб ми знову не відвантажили порожню browser dashboard
 - Post-publish verification також перевіряє, що опубліковані entrypoints plugin і
-  метадані package присутні в установленому registry layout. Реліз, який
+  package metadata присутні в установленій registry layout. Реліз, який
   відвантажує відсутні runtime payloads plugin, провалює postpublish verifier і
   не може бути підвищений до `latest`.
-- `pnpm test:install:smoke` також забезпечує бюджет npm pack `unpackedSize` для
-  candidate update tarball, щоб installer e2e ловив випадкове роздуття пакування
-  до release publish path
-- Якщо релізна робота торкнулася планування CI, manifests timing extension або
-  матриць тестів extension, перегенеруйте й перегляньте planner-owned
+- `pnpm test:install:smoke` також забезпечує budget `unpackedSize` npm pack для
+  candidate update tarball, щоб installer e2e ловив випадкове pack bloat
+  до релізного publish path
+- Якщо релізна робота торкнулася CI planning, extension timing manifests або
+  extension test matrices, згенеруйте заново й перегляньте planner-owned
   matrix outputs `plugin-prerelease-extension-shard` з
   `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не
   описували застарілий CI layout
-- Готовність стабільного macOS-релізу також включає updater surfaces:
-  - GitHub release має врешті містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
+- Готовність стабільного macOS release також включає updater surfaces:
+  - GitHub release має завершитися з упакованими `.zip`, `.dmg` і `.dSYM.zip`
   - `appcast.xml` на `main` має вказувати на новий stable zip після publish
-  - запакований app має зберігати non-debug bundle id, непорожню URL Sparkle feed
-    і `CFBundleVersion` на рівні або вище canonical Sparkle build floor
-    для цієї версії релізу
+  - упакований app має зберігати non-debug bundle id, непорожній Sparkle feed
+    URL і `CFBundleVersion` на рівні або вище канонічної Sparkle build floor
+    для цієї release version
 
 ## Релізні тестові бокси
 
 `Full Release Validation` — це спосіб, яким operators запускають усі передрелізні тести з
-однієї точки входу. Для доказу pinned commit на швидко змінюваній гілці використовуйте
-helper, щоб кожен дочірній workflow запускався з тимчасової гілки, зафіксованої на target
+однієї точки входу. Для доказу pinned commit на швидкозмінній гілці використовуйте
+helper, щоб кожен child workflow запускався з тимчасової гілки, зафіксованої на target
 SHA:
 
 ```bash
@@ -278,11 +278,11 @@ pnpm ci:full-release --sha <full-sha>
 ```
 
 Helper пушить `release-ci/<sha>-...`, запускає `Full Release Validation`
-з цієї гілки з `ref=<sha>`, перевіряє, що кожен дочірній workflow `headSha`
-збігається з target, а потім видаляє тимчасову гілку. Це запобігає випадковому
-підтвердженню нового дочірнього запуску `main`.
+з цієї гілки з `ref=<sha>`, перевіряє, що кожен child workflow `headSha`
+збігається з target, а потім видаляє тимчасову гілку. Це уникає випадкового підтвердження
+новішого child run з `main`.
 
-Для валідації release branch або tag запускайте його з довіреного workflow
+Для валідації release branch або tag запускайте це з довіреного workflow
 ref `main` і передавайте release branch або tag як `ref`:
 
 ```bash
@@ -297,51 +297,51 @@ gh workflow run full-release-validation.yml \
 
 Робочий процес визначає цільовий ref, запускає manual `CI` з
 `target_ref=<release-ref>`, запускає `OpenClaw Release Checks`, готує
-батьківський артефакт `release-package-under-test` для перевірок, орієнтованих на пакет, і
+батьківський артефакт `release-package-under-test` для перевірок, пов’язаних із пакетом, і
 запускає автономний 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, коли soak увімкнено, Package Acceptance з Telegram
+Checks` розгортає install smoke, cross-OS release checks, live/E2E Docker
+release-path coverage, коли soak увімкнено, 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 містить таблиці найповільніших завдань для кожного дочірнього запуску, щоб release
-manager міг бачити поточний критичний шлях без завантаження логів.
-Див. [Повна release validation](/uk/reference/full-release-validation), щоб отримати
-повну матрицю етапів, точні назви workflow job, відмінності між stable і full profile,
-артефакти та ручки сфокусованого повторного запуску.
+зведення перевіряча містить таблиці найповільніших завдань для кожного дочірнього запуску, щоб release
+manager міг бачити поточний критичний шлях без завантаження журналів.
+Див. [Повна валідація релізу](/uk/reference/full-release-validation) щодо
+повної матриці етапів, точних назв завдань workflow, відмінностей між профілями stable і full,
+артефактів і дескрипторів цільового повторного запуску.
 Дочірні workflow запускаються з довіреного ref, який виконує `Full Release
 Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на
-старішу release branch або tag. Окремого workflow-ref input для Full Release Validation
+старішу release branch або tag. Окремого input workflow-ref для Full Release Validation
 немає; вибирайте довірений harness, вибираючи ref запуску workflow.
-Не використовуйте `--ref main -f ref=<sha>` для exact commit proof на рухомій `main`;
-raw commit SHA не можуть бути workflow dispatch refs, тому використовуйте
+Не використовуйте `--ref main -f ref=<sha>` для доказу точного commit на рухомому `main`;
+raw commit SHAs не можуть бути 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 для release approval
+- `minimum`: найшвидший release-critical шлях OpenAI/core live і Docker
+- `stable`: minimum плюс stable provider/backend coverage для схвалення релізу
 - `full`: stable плюс широке advisory provider/media coverage
 
 Використовуйте `run_release_soak=true` зі `stable`, коли release-blocking lanes
 зелені й потрібен вичерпний live/E2E, Docker release-path і
-all-since-2026.4.23 upgrade-survivor sweep перед promotion. `full` передбачає
+all-since-2026.4.23 upgrade-survivor sweep перед просуванням. `full` передбачає
 `run_release_soak=true`.
 
 `OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз визначити цільовий
 ref як `release-package-under-test`, і повторно використовує цей артефакт у cross-OS,
-Package Acceptance та release-path Docker checks, коли виконується soak. Це утримує
-всі package-facing boxes на тих самих байтах і уникає повторних package builds.
+Package Acceptance і release-path Docker checks, коли виконується soak. Це тримає
+всі package-facing boxes на тих самих байтах і уникає повторних збірок package.
 Cross-OS 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
+задано 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.
 
-Використовуйте ці варіанти залежно від етапу release:
+Використовуйте ці варіанти залежно від етапу релізу:
 
 ```bash
 # Validate an unpublished release candidate branch.
@@ -371,40 +371,43 @@ gh workflow run full-release-validation.yml \
   -f npm_telegram_provider_mode=mock-openai
 ```
 
-Не використовуйте повну umbrella як перший повторний запуск після сфокусованого виправлення. Якщо один box
-завершується помилкою, використовуйте failed child workflow, job, Docker lane, package profile, model
-provider або QA lane для наступного proof. Запускайте повну umbrella знову лише тоді,
-коли виправлення змінило shared release orchestration або зробило попередні all-box evidence
-застарілими. Фінальний verifier umbrella повторно перевіряє записані ids запусків child workflow,
-тому після успішного повторного запуску child workflow повторно запустіть лише failed
-`Verify full validation` parent job.
+Не використовуйте повну парасольку як перший повторний запуск після цільового виправлення. Якщо один box
+зазнає невдачі, використовуйте невдалий дочірній workflow, job, Docker lane, package profile, model
+provider або QA lane для наступного доказу. Запускайте повну парасольку знову лише тоді, коли
+виправлення змінило спільну orchestration релізу або зробило попередні all-box evidence
+застарілими. Фінальний перевіряч парасольки повторно перевіряє записані child workflow run
+ids, тому після успішного повторного запуску дочірнього workflow повторно запускайте лише невдале
+батьківське завдання `Verify full validation`.
 
-Для обмеженого відновлення передайте `rerun_group` до umbrella. `all` — це справжній
-release-candidate run, `ci` запускає лише normal CI child, `plugin-prerelease`
-запускає лише release-only Plugin child, `release-checks` запускає кожен release
+Для обмеженого відновлення передайте `rerun_group` до парасольки. `all` — це справжній
+release-candidate run, `ci` запускає лише дочірній normal CI, `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` потребують `npm_telegram_package_spec`; full/all runs
-з `release_profile=full` використовують package artifact із release-checks.
+Цільові повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; full/all runs
+з `release_profile=full` використовують package artifact release-checks. Цільові
+cross-OS reruns можуть додати `cross_os_suite_filter=windows/packaged-upgrade` або
+інший OS/suite filter. Помилки QA release-check є advisory; QA-only
+failure не блокує release validation.
 
 ### Vitest
 
-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
+Vitest box — це дочірній workflow manual `CI`. 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 повний normal test suite?"
-Це не те саме, що release-path product validation. Evidence, яку потрібно зберегти:
+Використовуйте цей box, щоб відповісти на запитання "чи пройшло source tree повний normal test suite?"
+Це не те саме, що release-path product validation. Evidence, які слід зберегти:
 
-- зведення `Full Release Validation`, що показує dispatched `CI` run URL
+- зведення `Full Release Validation`, що показує URL запущеного `CI` run
 - зелений `CI` run на точному target SHA
-- назви failed або slow shards із CI jobs під час дослідження regressions
-- Vitest timing artifacts, як-от `.artifacts/vitest-shard-timings.json`, коли
-  запуск потребує performance analysis
+- назви failed або slow shard із CI jobs під час розслідування регресій
+- артефакти timing Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли
+  run потребує performance analysis
 
-Запускайте manual CI напряму лише тоді, коли release потребує deterministic normal CI, але
+Запускайте manual CI напряму лише тоді, коли релізу потрібен deterministic normal CI, але
 не Docker, QA Lab, live, cross-OS або package boxes:
 
 ```bash
@@ -413,14 +416,14 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
 
 ### Docker
 
-Docker box живе в `OpenClaw Release Checks` через
-`openclaw-live-and-e2e-checks-reusable.yml`, а також release-mode
-workflow `install-smoke`. Він перевіряє release candidate через packaged
+Docker box міститься в `OpenClaw Release Checks` через
+`openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode
+workflow `install-smoke`. Він валідує release candidate через packaged
 Docker environments, а не лише source-level tests.
 
 Release Docker coverage включає:
 
-- full install smoke з увімкненим slow Bun global install smoke
+- повний install smoke з увімкненим slow Bun global install smoke
 - підготовку/повторне використання root Dockerfile smoke image за target SHA, з QR,
   root/gateway і installer/Bun smoke jobs, що виконуються як окремі install-smoke
   shards
@@ -433,46 +436,46 @@ Release Docker coverage включає:
   `plugins-runtime-install-e`, `plugins-runtime-install-f`,
   `plugins-runtime-install-g` і `plugins-runtime-install-h`
 - OpenWebUI coverage всередині chunk `plugins-runtime-services`, коли це запитано
-- розділені bundled Plugin install/uninstall lanes
-  `bundled-plugin-install-uninstall-0` до
+- split bundled plugin install/uninstall lanes
+  `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 завантажує
 `.artifacts/docker-tests/` з lane logs, `summary.json`, `failures.json`,
-phase timings, scheduler plan JSON і rerun commands. Для сфокусованого відновлення
-використовуйте `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow замість
+phase timings, scheduler plan JSON і rerun commands. Для цільового відновлення
+використовуйте `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.
+`package_artifact_run_id` і prepared Docker image inputs, коли вони доступні, тому
+невдала lane може повторно використати той самий tarball і GHCR images.
 
 ### QA Lab
 
 QA Lab box також є частиною `OpenClaw Release Checks`. Це agentic
-behavior і channel-level release gate, окремий від Vitest і Docker
+behavior і channel-level release gate, окремо від Vitest і Docker
 package mechanics.
 
 Release QA Lab coverage включає:
 
-- mock parity lane, що порівнює candidate lane OpenAI з baseline Opus 4.6
-  за допомогою agentic parity pack
+- mock parity lane, що порівнює OpenAI candidate lane з Opus 4.6
+  baseline за допомогою agentic parity pack
 - fast live Matrix QA profile з використанням середовища `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, щоб відповісти: "чи поводиться release правильно у QA scenarios і
+Використовуйте цей box, щоб відповісти на запитання "чи реліз поводиться правильно в QA scenarios і
 live channel flows?" Зберігайте artifact URLs для parity, Matrix і Telegram
-lanes під час схвалення release. Full Matrix coverage лишається доступним як
+lanes під час схвалення релізу. Full Matrix coverage залишається доступним як
 manual sharded QA-Lab run, а не default release-critical lane.
 
 ### Package
 
-Package box — це installable-product gate. Його підтримують
+Package box — це installable-product gate. Він підтримується
 `Package Acceptance` і resolver
 `scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує
-candidate у tarball `package-under-test`, який споживає Docker E2E, перевіряє
-package inventory, записує package version і SHA-256 та утримує
+candidate у tarball `package-under-test`, який споживає Docker E2E, валідує
+package inventory, записує package version і SHA-256, а також тримає
 workflow harness ref окремо від package source ref.
 
 Підтримувані candidate sources:
@@ -484,42 +487,42 @@ workflow harness ref окремо від package source ref.
 - `source=url`: завантажити HTTPS `.tgz` з обов’язковим `package_sha256`
 - `source=artifact`: повторно використати `.tgz`, завантажений іншим GitHub Actions run
 
-`OpenClaw Release Checks` запускає Package Acceptance з `source=artifact`,
-підготовленим release package artifact, `suite_profile=custom`,
+`OpenClaw Release Checks` запускає Package Acceptance з `source=artifact`, підготовленим
+release package artifact, `suite_profile=custom`,
 `docker_lanes=doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update`,
 `telegram_mode=mock-openai`. Package Acceptance утримує migration, update, stale
-Plugin dependency cleanup, offline Plugin fixtures, Plugin update і Telegram
+plugin dependency cleanup, offline plugin fixtures, plugin update і Telegram
 package QA проти того самого resolved tarball. Blocking release checks використовують
 default latest published package baseline; `run_release_soak=true` або
-`release_profile=full` розширює до кожного stable npm-published baseline від
+`release_profile=full` розширює це до кожного stable npm-published baseline від
 `2026.4.23` до `latest` плюс reported-issue fixtures. Використовуйте
-Package Acceptance із `source=npm` для вже shipped candidate або
+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.
+надавати перевагу Package Acceptance.
 
-Канонічний checklist для update і Plugin validation —
-[Тестування updates і Plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли
+Канонічний checklist для update і plugin validation —
+[Тестування оновлень і plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли
 вирішуєте, яка local, Docker, Package Acceptance або release-check lane доводить
-Plugin install/update, doctor cleanup або published-package migration change.
-Вичерпна published update migration з кожного stable package `2026.4.23+` —
-це окремий manual workflow `Update Migration`, а не частина Full Release CI.
+plugin install/update, doctor cleanup або published-package migration change.
+Exhaustive published update migration з кожного stable package `2026.4.23+` є
+окремим manual workflow `Update Migration`, а не частиною Full Release CI.
 
-Legacy package-acceptance leniency навмисно обмежена в часі. Packages до
+Legacy package-acceptance leniency навмисно обмежено в часі. Packages до
 `2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих
-у npm: private QA inventory entries, відсутні в tarball, відсутній
+до npm: private QA inventory entries, відсутні в tarball, відсутній
 `gateway install --wrapper`, відсутні patch files у tarball-derived git
-fixture, відсутній persisted `update.channel`, legacy Plugin install-record
-locations, відсутня marketplace install-record persistence і config metadata
+fixture, відсутній persisted `update.channel`, legacy plugin install-record
+locations, відсутній marketplace install-record persistence і config metadata
 migration під час `plugins update`. Опублікований package `2026.4.26` може попереджати
 про local build metadata stamp files, які вже були shipped. Пізніші packages
 мають задовольняти modern package contracts; ті самі gaps провалюють release
 validation.
 
-Використовуйте ширші Package Acceptance profiles, коли release question стосується
+Використовуйте ширші profiles Package Acceptance, коли release question стосується
 фактичного installable package:
 
 ```bash
@@ -532,34 +535,34 @@ gh workflow run package-acceptance.yml \
   -f published_upgrade_survivor_baseline=openclaw@2026.4.26
 ```
 
-Поширені package profiles:
+Поширені профілі пакетів:
 
-- `smoke`: швидкі лани встановлення пакета/каналу/агента, мережі Gateway і
+- `smoke`: швидкі напрями встановлення пакета/каналу/агента, мережі gateway і
   перезавантаження конфігурації
-- `package`: контракти встановлення/оновлення/пакета Plugin без живого ClawHub; це типовий
-  варіант для release-check
-- `product`: `package` плюс MCP-канали, очищення cron/subagent, вебпошук OpenAI
+- `package`: контракти встановлення/оновлення/пакета Plugin без живого ClawHub; це стандартний профіль
+  перевірки релізу
+- `product`: `package` плюс канали MCP, очищення cron/субагентів, вебпошук OpenAI
   і OpenWebUI
-- `full`: фрагменти Docker release-path з OpenWebUI
-- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків
+- `full`: частини Docker release-path з OpenWebUI
+- `custom`: точний список `docker_lanes` для цільових повторних запусків
 
-Для Telegram-підтвердження кандидата пакета увімкніть `telegram_mode=mock-openai` або
+Для підтвердження Telegram для пакета-кандидата увімкніть `telegram_mode=mock-openai` або
 `telegram_mode=live-frontier` у Package Acceptance. Workflow передає
-розв’язаний tarball `package-under-test` у Telegram-лан; окремий
-Telegram workflow і далі приймає опубліковану npm-специфікацію для перевірок після публікації.
+розв’язаний tarball `package-under-test` у напрям Telegram; окремий
+workflow Telegram усе ще приймає опубліковану npm-специфікацію для перевірок після публікації.
 
 ## Автоматизація публікації релізу
 
-`OpenClaw Release Publish` — звичайна мутувальна точка входу для публікації. Вона
-оркеструє workflows trusted-publisher у порядку, потрібному для релізу:
+`OpenClaw Release Publish` є звичайною мутувальною точкою входу для публікації. Вона
+оркеструє workflow довіреного публікатора в порядку, потрібному для релізу:
 
-1. Взяти release tag і визначити його commit SHA.
-2. Перевірити, що tag досяжний із `main` або `release/*`.
+1. Отримати release tag і визначити його commit SHA.
+2. Перевірити, що тег досяжний із `main` або `release/*`.
 3. Запустити `pnpm plugins:sync:check`.
-4. Dispatch `Plugin NPM Release` з `publish_scope=all-publishable` і
+4. Запустити `Plugin NPM Release` з `publish_scope=all-publishable` і
    `ref=<release-sha>`.
-5. Dispatch `Plugin ClawHub Release` з тим самим scope і SHA.
-6. Dispatch `OpenClaw NPM Release` з release tag, npm dist-tag і
+5. Запустити `Plugin ClawHub Release` з тим самим scope і SHA.
+6. Запустити `OpenClaw NPM Release` з release tag, npm dist-tag і
    збереженим `preflight_run_id`.
 
 Приклад публікації beta:
@@ -572,7 +575,7 @@ gh workflow run openclaw-release-publish.yml \
   -f npm_dist_tag=beta
 ```
 
-Стабільна публікація до типового beta dist-tag:
+Стабільна публікація в стандартний beta dist-tag:
 
 ```bash
 gh workflow run openclaw-release-publish.yml \
@@ -582,7 +585,7 @@ gh workflow run openclaw-release-publish.yml \
   -f npm_dist_tag=beta
 ```
 
-Стабільне просування безпосередньо до `latest` є явним:
+Стабільне просування безпосередньо в `latest` є явним:
 
 ```bash
 gh workflow run openclaw-release-publish.yml \
@@ -592,94 +595,94 @@ gh workflow run openclaw-release-publish.yml \
   -f npm_dist_tag=latest
 ```
 
-Використовуйте нижчорівневі workflows `Plugin NPM Release` і `Plugin ClawHub Release`
-лише для сфокусованого ремонту або повторної публікації. Для ремонту вибраного Plugin передайте
+Використовуйте нижчорівневі workflow `Plugin NPM Release` і `Plugin ClawHub Release`
+лише для цільового виправлення або повторної публікації. Для виправлення вибраного plugin передайте
 `plugin_publish_scope=selected` і `plugins=@openclaw/name` до
-`OpenClaw Release Publish` або запустіть дочірній workflow напряму, коли
-пакет OpenClaw не можна публікувати.
+`OpenClaw Release Publish`, або запустіть дочірній workflow напряму, коли
+пакет OpenClaw не має публікуватися.
 
-## Вхідні дані NPM workflow
+## Вхідні параметри workflow NPM
 
-`OpenClaw NPM Release` приймає такі керовані оператором вхідні дані:
+`OpenClaw NPM Release` приймає такі керовані оператором вхідні параметри:
 
 - `tag`: обов’язковий release tag, наприклад `v2026.4.2`, `v2026.4.2-1` або
   `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
   повний 40-символьний workflow-branch commit SHA для preflight лише з валідацією
-- `preflight_only`: `true` лише для валідації/build/package, `false` для
+- `preflight_only`: `true` лише для валідації/збірки/пакета, `false` для
   реального шляху публікації
 - `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб workflow повторно використав
-  підготовлений tarball з успішного preflight-запуску
-- `npm_dist_tag`: цільовий npm tag для шляху публікації; типово `beta`
+  підготовлений tarball з успішного preflight run
+- `npm_dist_tag`: цільовий тег npm для шляху публікації; стандартно `beta`
 
-`OpenClaw Release Publish` приймає такі керовані оператором вхідні дані:
+`OpenClaw Release Publish` приймає такі керовані оператором вхідні параметри:
 
-- `tag`: обов’язковий release tag; має вже існувати
-- `preflight_run_id`: id успішного preflight-запуску `OpenClaw NPM Release`;
+- `tag`: обов’язковий release tag; уже має існувати
+- `preflight_run_id`: id успішного preflight run `OpenClaw NPM Release`;
   обов’язковий, коли `publish_openclaw_npm=true`
-- `npm_dist_tag`: цільовий npm tag для пакета OpenClaw
-- `plugin_publish_scope`: типово `all-publishable`; використовуйте `selected` лише
-  для сфокусованого ремонтного завдання
+- `npm_dist_tag`: цільовий тег npm для пакета OpenClaw
+- `plugin_publish_scope`: стандартно `all-publishable`; використовуйте `selected` лише
+  для цільових робіт із виправлення
 - `plugins`: розділені комами назви пакетів `@openclaw/*`, коли
   `plugin_publish_scope=selected`
-- `publish_openclaw_npm`: типово `true`; установлюйте `false` лише під час використання
-  workflow як оркестратора ремонту лише для plugins
+- `publish_openclaw_npm`: стандартно `true`; встановлюйте `false` лише під час використання
+  workflow як оркестратора виправлення лише для plugin
 
-`OpenClaw Release Checks` приймає такі керовані оператором вхідні дані:
+`OpenClaw Release Checks` приймає такі керовані оператором вхідні параметри:
 
-- `ref`: branch, tag або повний commit SHA для валідації. Перевірки із секретами
-  вимагають, щоб розв’язаний commit був досяжний з branch OpenClaw або
+- `ref`: гілка, тег або повний commit SHA для валідації. Перевірки з секретами
+  вимагають, щоб визначений commit був досяжний із гілки OpenClaw або
   release tag.
-- `run_release_soak`: увімкнути вичерпні live/E2E, Docker release-path і
-  all-since upgrade-survivor soak на стабільних/типових release checks. Примусово
+- `run_release_soak`: увімкнення вичерпного live/E2E, Docker release-path і
+  all-since upgrade-survivor soak для stable/default release checks. Це примусово
   вмикається через `release_profile=full`.
 
 Правила:
 
-- Стабільні та корекційні tags можуть публікуватися або до `beta`, або до `latest`
-- Beta prerelease tags можуть публікуватися лише до `beta`
-- Для `OpenClaw NPM Release` введення повного commit SHA дозволене лише коли
+- Стабільні й корекційні теги можуть публікуватися або в `beta`, або в `latest`
+- Beta prerelease tags можуть публікуватися лише в `beta`
+- Для `OpenClaw NPM Release` вхідний повний commit SHA дозволений лише коли
   `preflight_only=true`
 - `OpenClaw Release Checks` і `Full Release Validation` завжди
-  лише валідаційні
+  призначені лише для валідації
 - Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
-  workflow перевіряє ці метадані перед продовженням публікації
+  workflow перевіряє ці metadata перед продовженням публікації
 
 ## Послідовність стабільного npm-релізу
 
 Під час підготовки стабільного npm-релізу:
 
 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
-   - До появи tag можна використати поточний повний workflow-branch commit
-     SHA для валідаційного пробного запуску preflight workflow
+   - До появи тегу можна використати поточний повний commit SHA workflow-branch
+     для пробного запуску preflight workflow лише з валідацією
 2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише
    коли навмисно потрібна пряма стабільна публікація
 3. Запустіть `Full Release Validation` на release branch, release tag або повному
    commit SHA, коли потрібні звичайний CI плюс покриття live prompt cache, Docker, QA Lab,
    Matrix і Telegram з одного ручного workflow
 4. Якщо навмисно потрібен лише детермінований звичайний граф тестів, запустіть
-   ручний workflow `CI` на release ref натомість
+   ручний workflow `CI` на release 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`,
+7. Якщо реліз потрапив у `beta`, використайте приватний workflow
+   `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
    щоб просунути цю стабільну версію з `beta` до `latest`
-8. Якщо реліз навмисно опубліковано безпосередньо до `latest`, а `beta`
-   має негайно вказувати на той самий стабільний build, використайте той самий приватний
+8. Якщо реліз навмисно опубліковано напряму в `latest`, а `beta`
+   має негайно слідувати за тією самою стабільною збіркою, використайте той самий приватний
    workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
-   self-healing синхронізації пізніше перемістити `beta`
+   самовідновлювальній синхронізації пізніше перемістити `beta`
 
-Мутація dist-tag розміщена в приватному repo з міркувань безпеки, оскільки вона все ще
-потребує `NPM_TOKEN`, тоді як публічний repo зберігає публікацію лише через OIDC.
+Мутація dist-tag розміщена в приватному репозиторії з міркувань безпеки, бо вона все ще
+потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
 
-Це робить і шлях прямої публікації, і шлях просування beta-first
+Це залишає і прямий шлях публікації, і шлях просування beta-first
 задокументованими та видимими для оператора.
 
-Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password
-CLI (`op`) лише всередині виділеної tmux session. Не викликайте `op`
-напряму з головного agent shell; утримання цього всередині tmux робить prompts,
-alerts і обробку OTP спостережуваними та запобігає повторним alerts хоста.
+Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди CLI 1Password
+(`op`) лише всередині окремої tmux-сесії. Не викликайте `op`
+напряму з основної agent shell; утримання цього всередині tmux робить prompts,
+alerts і обробку OTP видимими та запобігає повторним host alerts.
 
 ## Публічні посилання
 
@@ -693,7 +696,7 @@ alerts і обробку OTP спостережуваними та запобі
 - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
 - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)
 
-Maintainers використовують приватну release-документацію в
+Maintainers використовують приватну документацію релізів у
 [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
 для фактичного runbook.
 

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

@@ -1,24 +1,24 @@
 ---
 read_when:
-    - Запуск або повторний запуск повної перевірки релізу
+    - Запуск або повторний запуск повної валідації релізу
     - Порівняння стабільного та повного профілів перевірки релізу
-    - Налагодження збоїв на етапі перевірки випуску
+    - Налагодження збоїв на етапі валідації релізу
 summary: Етапи повної перевірки релізу, дочірні робочі процеси, профілі релізу, дескриптори повторного запуску та докази
 title: Повна перевірка релізу
 x-i18n:
-    generated_at: "2026-05-04T22:29:50Z"
+    generated_at: "2026-05-05T01:33:44Z"
     model: gpt-5.5
     provider: openai
-    source_hash: d67b7f9d413aa0f367b71f03d5325ff73591ee1ee6c77623712ebd15d295ca8b
+    source_hash: 6cf696761f516fc7f8e9606a2a06fab61a644731330eb484a388f276767a9e0d
     source_path: reference/full-release-validation.md
     workflow: 16
 ---
 
-`Full Release Validation` — це парасолька релізу. Це єдина ручна
-точка входу для дорелізного підтвердження, але більшість роботи відбувається в дочірніх робочих процесах, щоб
-збійний блок можна було запустити повторно без перезапуску всього релізу.
+`Full Release Validation` — це парасольковий релізний процес. Це єдина ручна
+точка входу для передрелізного підтвердження, але більшість роботи виконується в дочірніх workflow, щоб
+невдалий бокс можна було перезапустити без перезапуску всього релізу.
 
-Запускайте його з довіреного посилання робочого процесу, зазвичай `main`, і передавайте гілку релізу,
+Запускайте його з довіреного ref workflow, зазвичай `main`, і передавайте релізну гілку,
 тег або повний SHA коміту як `ref`:
 
 ```bash
@@ -30,103 +30,103 @@ gh workflow run full-release-validation.yml \
   -f release_profile=stable
 ```
 
-Дочірні робочі процеси використовують довірене посилання робочого процесу для обв’язки та вхідний
-`ref` для кандидата, що тестується. Це зберігає доступність нової логіки валідації
-під час перевірки старішої гілки релізу або тегу.
+Дочірні workflow використовують довірений ref workflow для тестового каркаса, а вхідний
+`ref` — для кандидата, що тестується. Це зберігає доступність нової логіки валідації
+під час перевірки старішої релізної гілки або тега.
 
-За замовчуванням `release_profile=stable` запускає блокувальні для релізу напрямки й пропускає
+За замовчуванням `release_profile=stable` запускає релізно-блокувальні доріжки й пропускає
 вичерпний live/Docker soak. Передайте `run_release_soak=true`, щоб включити
-soak-напрямки у стабільний запуск. `release_profile=full` завжди вмикає soak-напрямки, щоб
-широкий дорадчий профіль ніколи не втрачав покриття непомітно.
+soak-доріжки під час стабільного запуску. `release_profile=full` завжди вмикає soak-доріжки, щоб
+широкий консультативний профіль ніколи непомітно не втрачав покриття.
 
 Package Acceptance зазвичай збирає tarball кандидата з розв’язаного
-`ref`, включно із запусками за повним SHA, відправленими через `pnpm ci:full-release`. Після
+`ref`, включно із запусками повного SHA, запущеними через `pnpm ci:full-release`. Після
 публікації передайте `package_acceptance_package_spec=openclaw@YYYY.M.D` (або
 `openclaw@beta`/`openclaw@latest`), щоб натомість запустити ту саму матрицю пакетів/оновлень проти
-опублікованого npm-пакета.
+відвантаженого npm-пакета.
 
-## Етапи верхнього рівня
+## Верхньорівневі етапи
 
-| Етап                 | Деталі                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+| Етап                 | Деталі                                                                                                                                                                                                                                                                                                                                                                                                                                        |
 | -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Розв’язання цілі     | **Завдання:** `Resolve target ref`<br />**Дочірній робочий процес:** немає<br />**Підтверджує:** розв’язує гілку релізу, тег або повний SHA коміту й записує вибрані вхідні дані.<br />**Повторний запуск:** повторно запустіть парасольку, якщо це завершиться збоєм.                                                                                                                                                                      |
-| Vitest і звичайний CI | **Завдання:** `Run normal full CI`<br />**Дочірній робочий процес:** `CI`<br />**Підтверджує:** ручний повний граф CI проти цільового ref, включно з напрямками Linux Node, шардами bundled Plugin, контрактами каналів, сумісністю з Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, Control UI i18n та Android через парасольку.<br />**Повторний запуск:** `rerun_group=ci`. |
-| Дореліз Plugin       | **Завдання:** `Run plugin prerelease validation`<br />**Дочірній робочий процес:** `Plugin Prerelease`<br />**Підтверджує:** лише релізні статичні перевірки Plugin, agentic-покриття Plugin, повні шарди batch розширень і дорелізні Docker-напрямки Plugin.<br />**Повторний запуск:** `rerun_group=plugin-prerelease`.                                                                                                                   |
-| Перевірки релізу     | **Завдання:** `Run release/live/Docker/QA validation`<br />**Дочірній робочий процес:** `OpenClaw Release Checks`<br />**Підтверджує:** install smoke, cross-OS перевірки пакета, Package Acceptance, паритет QA Lab, live Matrix і live Telegram. З `run_release_soak=true` або `release_profile=full` також запускає вичерпні live/E2E набори та Docker-фрагменти шляху релізу.<br />**Повторний запуск:** `rerun_group=release-checks` або вужчий дескриптор release-checks. |
-| Артефакт пакета      | **Завдання:** `Prepare release package artifact`<br />**Дочірній робочий процес:** немає<br />**Підтверджує:** створює батьківський tarball `release-package-under-test` достатньо рано для перевірок, орієнтованих на пакет, яким не потрібно чекати на `OpenClaw Release Checks`.<br />**Повторний запуск:** повторно запустіть парасольку або надайте `npm_telegram_package_spec` для `rerun_group=npm-telegram`.                         |
-| Package Telegram     | **Завдання:** `Run package Telegram E2E`<br />**Дочірній робочий процес:** `NPM Telegram Beta E2E`<br />**Підтверджує:** підтвердження пакета Telegram на основі батьківського артефакту для `rerun_group=all` з `release_profile=full` або підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.<br />**Повторний запуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`.                |
-| Верифікатор парасольки | **Завдання:** `Verify full validation`<br />**Дочірній робочий процес:** немає<br />**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших завдань із дочірніх робочих процесів.<br />**Повторний запуск:** повторно запустіть лише це завдання після повторного запуску невдалого дочірнього процесу до зеленого стану.                                                                       |
+| Розв’язання цілі     | **Job:** `Resolve target ref`<br />**Дочірній workflow:** немає<br />**Підтверджує:** розв’язує релізну гілку, тег або повний SHA коміту й записує вибрані вхідні параметри.<br />**Перезапуск:** перезапустіть парасольковий workflow, якщо це не вдасться.                                                                                                                                                                                 |
+| Vitest і звичайний CI | **Job:** `Run normal full CI`<br />**Дочірній workflow:** `CI`<br />**Підтверджує:** ручний повний граф CI проти цільового ref, включно з доріжками Linux Node, шардами bundled Plugin, контрактами каналів, сумісністю з Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python Skills, Windows, macOS, Control UI i18n і Android через парасольковий workflow.<br />**Перезапуск:** `rerun_group=ci`. |
+| Передреліз Plugin   | **Job:** `Run plugin prerelease validation`<br />**Дочірній workflow:** `Plugin Prerelease`<br />**Підтверджує:** релізні статичні перевірки Plugin, agentic-покриття Plugin, повні пакетні шарди розширень і передрелізні Docker-доріжки Plugin.<br />**Перезапуск:** `rerun_group=plugin-prerelease`.                                                                                                                                       |
+| Релізні перевірки    | **Job:** `Run release/live/Docker/QA validation`<br />**Дочірній workflow:** `OpenClaw Release Checks`<br />**Підтверджує:** install smoke, між-OS перевірки пакета, Package Acceptance, паритет QA Lab, live Matrix і live Telegram. З `run_release_soak=true` або `release_profile=full` також запускає вичерпні live/E2E набори й Docker-чанки релізного шляху.<br />**Перезапуск:** `rerun_group=release-checks` або вужчий release-checks handle. |
+| Артефакт пакета      | **Job:** `Prepare release package artifact`<br />**Дочірній workflow:** немає<br />**Підтверджує:** створює батьківський tarball `release-package-under-test` достатньо рано для перевірок, орієнтованих на пакети, яким не потрібно чекати на `OpenClaw Release Checks`.<br />**Перезапуск:** перезапустіть парасольковий workflow або надайте `npm_telegram_package_spec` для `rerun_group=npm-telegram`. |
+| Package Telegram    | **Job:** `Run package Telegram E2E`<br />**Дочірній workflow:** `NPM Telegram Beta E2E`<br />**Підтверджує:** підтвердження Telegram-пакета на основі батьківського артефакта для `rerun_group=all` з `release_profile=full`, або підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.<br />**Перезапуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`. |
+| Верифікатор парасолькового workflow | **Job:** `Verify full validation`<br />**Дочірній workflow:** немає<br />**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших job з дочірніх workflow.<br />**Перезапуск:** після перезапуску невдалого дочірнього workflow до зеленого стану перезапустіть лише цей job.                                                                                                                                 |
 
-Для `ref=main` і `rerun_group=all` новіша парасолька замінює старішу.
-Коли батьківський процес скасовується, його монітор скасовує будь-який дочірній робочий процес, який він уже
-відправив. Запуски валідації гілок релізу й тегів за замовчуванням не скасовують один одного.
+Для `ref=main` і `rerun_group=all` новіший парасольковий workflow замінює старіший.
+Коли батьківський workflow скасовано, його монітор скасовує будь-який дочірній workflow, який він уже
+запустив. Запуски валідації релізних гілок і тегів за замовчуванням не скасовують одне одного.
 
-## Етапи перевірок релізу
+## Етапи релізних перевірок
 
-`OpenClaw Release Checks` — найбільший дочірній робочий процес. Він один раз розв’язує ціль
-і готує спільний артефакт `release-package-under-test`, коли це потрібно етапам,
-орієнтованим на пакет або Docker.
+`OpenClaw Release Checks` — найбільший дочірній workflow. Він один раз розв’язує ціль
+і готує спільний артефакт `release-package-under-test`, коли він потрібен пакетним
+або Docker-орієнтованим етапам.
 
-| Етап                | Подробиці                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                  |
-| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Ціль релізу         | **Завдання:** `Resolve target ref`<br />**Базовий workflow:** немає<br />**Тести:** вибраний ref, необов’язковий очікуваний SHA, профіль, група повторного запуску та сфокусований фільтр live-набору.<br />**Повторний запуск:** `rerun_group=release-checks`.                                                                                                                                                                                                                                          |
-| Артефакт пакета     | **Завдання:** `Prepare release package artifact`<br />**Базовий workflow:** немає<br />**Тести:** пакує або визначає один кандидатний tarball і завантажує `release-package-under-test` для подальших перевірок, орієнтованих на пакет.<br />**Повторний запуск:** відповідна група пакета, cross-OS або live/E2E.                                                                                                                                                                                       |
-| Install smoke       | **Завдання:** `Run install smoke`<br />**Базовий workflow:** `Install Smoke`<br />**Тести:** повний шлях встановлення з повторним використанням smoke-образу кореневого Dockerfile, встановлення QR-пакета, root і gateway Docker smokes, Docker-тести інсталятора, Bun global install image-provider smoke і швидкий E2E встановлення/видалення bundled-plugin.<br />**Повторний запуск:** `rerun_group=install-smoke`.                                                                                 |
-| Cross-OS            | **Завдання:** `cross_os_release_checks`<br />**Базовий workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`<br />**Тести:** свіжі та upgrade-напрями на Linux, Windows і macOS для вибраного провайдера та режиму з використанням кандидатного tarball і baseline-пакета.<br />**Повторний запуск:** `rerun_group=cross-os`.                                                                                                                                                                      |
-| Repo і live E2E     | **Завдання:** `Run repo/live E2E validation`<br />**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тести:** repository E2E, live cache, OpenAI websocket streaming, native live provider і Plugin shards, а також Docker-backed live model/backend/gateway harnesses, вибрані через `release_profile`.<br />**Запускається:** `run_release_soak=true`, `release_profile=full` або сфокусований `rerun_group=live-e2e`.<br />**Повторний запуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`. |
-| Шлях Docker-релізу  | **Завдання:** `Run Docker release-path validation`<br />**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тести:** Docker chunks для release-path на спільному артефакті пакета.<br />**Запускається:** `run_release_soak=true`, `release_profile=full` або сфокусований `rerun_group=live-e2e`.<br />**Повторний запуск:** `rerun_group=live-e2e`.                                                                                                                                   |
-| Package Acceptance  | **Завдання:** `Run package acceptance`<br />**Базовий workflow:** `Package Acceptance`<br />**Тести:** offline fixtures пакетів Plugin, оновлення Plugin, приймання mock-OpenAI Telegram-пакета та перевірки survivor для published-upgrade на тому самому tarball. Блокувальні release-перевірки використовують стандартний останній опублікований baseline; soak-перевірки розширюються до кожного стабільного npm-релізу від `2026.4.23` включно плюс fixtures для повідомлених проблем.<br />**Повторний запуск:** `rerun_group=package`. |
-| QA parity           | **Завдання:** `Run QA Lab parity lane` і `Run QA Lab parity report`<br />**Базовий workflow:** прямі jobs<br />**Тести:** кандидатні та baseline agentic parity packs, потім parity report.<br />**Повторний запуск:** `rerun_group=qa-parity` або `rerun_group=qa`.                                                                                                                                                                                                                                      |
-| QA live Matrix      | **Завдання:** `Run QA Lab live Matrix lane`<br />**Базовий workflow:** пряме job<br />**Тести:** швидкий live Matrix QA-профіль у середовищі `qa-live-shared`.<br />**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`.                                                                                                                                                                                                                                                                 |
-| QA live Telegram    | **Завдання:** `Run QA Lab live Telegram lane`<br />**Базовий workflow:** пряме job<br />**Тести:** live Telegram QA з орендами облікових даних Convex CI.<br />**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`.                                                                                                                                                                                                                                                                   |
-| Верифікатор релізу  | **Завдання:** `Verify release checks`<br />**Базовий workflow:** немає<br />**Тести:** обов’язкові release-check jobs для вибраної групи повторного запуску.<br />**Повторний запуск:** повторно запустіть після успішного проходження сфокусованих дочірніх jobs.                                                                                                                                                                                                                                       |
+| Етап                | Подробиці                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
+| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Ціль релізу         | **Завдання:** `Resolve target ref`<br />**Базовий workflow:** немає<br />**Тести:** вибраний ref, необов’язковий очікуваний SHA, профіль, група повторного запуску та фільтр сфокусованого live-набору.<br />**Повторний запуск:** `rerun_group=release-checks`.                                                                                                                                                                                                                                           |
+| Артефакт пакета     | **Завдання:** `Prepare release package artifact`<br />**Базовий workflow:** немає<br />**Тести:** пакує або знаходить один кандидатний tarball і завантажує `release-package-under-test` для подальших перевірок, орієнтованих на пакет.<br />**Повторний запуск:** відповідна група пакета, cross-OS або live/E2E.                                                                                                                                                                                        |
+| Install smoke       | **Завдання:** `Run install smoke`<br />**Базовий workflow:** `Install Smoke`<br />**Тести:** повний шлях інсталяції з повторним використанням smoke-образу кореневого Dockerfile, інсталяція QR-пакета, Docker smoke для кореня та Gateway, Docker-тести інсталятора, smoke для image-provider через глобальну інсталяцію Bun і швидкий E2E інсталяції/видалення bundled-Plugin.<br />**Повторний запуск:** `rerun_group=install-smoke`.                                                               |
+| Cross-OS            | **Завдання:** `cross_os_release_checks`<br />**Базовий workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`<br />**Тести:** свіжі та upgrade lanes на Linux, Windows і macOS для вибраного провайдера та режиму з використанням кандидатного tarball і базового пакета.<br />**Повторний запуск:** `rerun_group=cross-os`.                                                                                                                                                                           |
+| Repo та live E2E    | **Завдання:** `Run repo/live E2E validation`<br />**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тести:** repository E2E, live-кеш, OpenAI websocket streaming, native live provider і Plugin shards, а також Docker-backed live model/backend/gateway harnesses, вибрані через `release_profile`.<br />**Запуски:** `run_release_soak=true`, `release_profile=full` або сфокусований `rerun_group=live-e2e`.<br />**Повторний запуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`. |
+| Шлях Docker-релізу  | **Завдання:** `Run Docker release-path validation`<br />**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`<br />**Тести:** Docker chunks для release-path проти спільного артефакта пакета.<br />**Запуски:** `run_release_soak=true`, `release_profile=full` або сфокусований `rerun_group=live-e2e`.<br />**Повторний запуск:** `rerun_group=live-e2e`.                                                                                                                                    |
+| Package Acceptance  | **Завдання:** `Run package acceptance`<br />**Базовий workflow:** `Package Acceptance`<br />**Тести:** офлайн-фікстури пакетів Plugin, оновлення Plugin, package acceptance для mock-OpenAI Telegram і перевірки survivor для published-upgrade проти того самого tarball. Блокувальні release checks використовують стандартний останній опублікований baseline; soak checks розширюються до кожного стабільного npm-релізу від `2026.4.23` включно плюс фікстури повідомлених проблем.<br />**Повторний запуск:** `rerun_group=package`. |
+| QA parity           | **Завдання:** `Run QA Lab parity lane` і `Run QA Lab parity report`<br />**Базовий workflow:** прямі завдання<br />**Тести:** кандидатні та базові пакети agentic parity, потім parity report.<br />**Повторний запуск:** `rerun_group=qa-parity` або `rerun_group=qa`.                                                                                                                                                                                                                                      |
+| QA live Matrix      | **Завдання:** `Run QA Lab live Matrix lane`<br />**Базовий workflow:** пряме завдання<br />**Тести:** швидкий live Matrix QA-профіль у середовищі `qa-live-shared`.<br />**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`.                                                                                                                                                                                                                                                             |
+| QA live Telegram    | **Завдання:** `Run QA Lab live Telegram lane`<br />**Базовий workflow:** пряме завдання<br />**Тести:** live Telegram QA з leases облікових даних Convex CI.<br />**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`.                                                                                                                                                                                                                                                                 |
+| Верифікатор релізу  | **Завдання:** `Verify release checks`<br />**Базовий workflow:** немає<br />**Тести:** обов’язкові release-check завдання для вибраної групи повторного запуску.<br />**Повторний запуск:** повторіть запуск після проходження сфокусованих дочірніх завдань.                                                                                                                                                                                                                                           |
 
-## Фрагменти Docker release-path
+## Docker release-path chunks
 
-Етап Docker release-path запускає ці фрагменти, коли `live_suite_filter`
+Етап Docker release-path запускає ці chunks, коли `live_suite_filter`
 порожній:
 
-| Фрагмент                                                       | Покриття                                                                 |
-| -------------------------------------------------------------- | ------------------------------------------------------------------------ |
-| `core`                                                         | Core Docker release-path smoke-напрями.                                  |
-| `package-update-openai`                                        | Поведінка встановлення та оновлення пакета OpenAI.                       |
-| `package-update-anthropic`                                     | Поведінка встановлення та оновлення пакета Anthropic.                    |
-| `package-update-core`                                          | Нейтральна щодо провайдера поведінка пакета й оновлення.                 |
-| `plugins-runtime-plugins`                                      | Напрями runtime Plugin, які перевіряють поведінку Plugin.                |
-| `plugins-runtime-services`                                     | Напрями runtime Plugin з підтримкою сервісів; включає OpenWebUI за запитом. |
-| `plugins-runtime-install-a` до `plugins-runtime-install-h`     | Пакети встановлення/runtime Plugin, розділені для паралельної валідації релізу. |
+| Chunk                                                           | Покриття                                                                 |
+| --------------------------------------------------------------- | ------------------------------------------------------------------------ |
+| `core`                                                          | Core Docker release-path smoke lanes.                                    |
+| `package-update-openai`                                         | Поведінка інсталяції та оновлення пакета OpenAI.                         |
+| `package-update-anthropic`                                      | Поведінка інсталяції та оновлення пакета Anthropic.                      |
+| `package-update-core`                                           | Провайдер-нейтральна поведінка пакета та оновлення.                      |
+| `plugins-runtime-plugins`                                       | Plugin runtime lanes, що перевіряють поведінку Plugin.                   |
+| `plugins-runtime-services`                                      | Service-backed Plugin runtime lanes; включає OpenWebUI за запитом.       |
+| `plugins-runtime-install-a` through `plugins-runtime-install-h` | Пакети інсталяції/runtime Plugin, розділені для паралельної release validation. |
 
-Використовуйте цільові `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow, коли
-збій стався лише в одному Docker-напрямі. Артефакти релізу містять команди
-повторного запуску для кожного напряму з artifact пакета та вхідними даними повторного використання образу, коли вони доступні.
+Використовуйте цільовий `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow, коли
+зламалася лише одна Docker lane. Артефакти релізу містять команди повторного
+запуску для кожної lane з вхідними даними артефакта пакета та повторного використання образу, коли вони доступні.
 
 ## Профілі релізу
 
-`release_profile` переважно керує шириною live/provider усередині release checks.
+`release_profile` здебільшого керує шириною live/provider всередині release checks.
 Він не прибирає звичайний full CI, Plugin Prerelease, install smoke, package
-acceptance або QA Lab. Для `stable` вичерпні repo/live E2E і Docker
+acceptance або QA Lab. Для `stable` вичерпні repo/live E2E та Docker
 release-path chunks є soak-покриттям і запускаються, коли `run_release_soak=true`.
 `full` примусово вмикає soak-покриття, а також змушує umbrella-запуск виконувати package Telegram
-E2E проти артефакта пакета батьківського релізу, коли `rerun_group=all`, щоб повний
-pre-publish кандидат не пропускав непомітно цей напрям Telegram package.
+E2E проти артефакта батьківського release package, коли `rerun_group=all`, щоб повний
+pre-publish кандидат не пропускав цю Telegram package lane непомітно.
 
-| Профіль  | Призначене використання              | Включене live/provider-покриття                                                                                                                                         |
-| -------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `minimum` | Найшвидший критичний для релізу smoke. | OpenAI/core live path, Docker live models для OpenAI, native gateway core, native OpenAI gateway profile, native OpenAI plugin і Docker live gateway OpenAI.            |
-| `stable` | Стандартний профіль схвалення релізу. | `minimum` плюс Anthropic smoke, Google, MiniMax, backend, native live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і OpenCode Go smoke shard. |
-| `full`   | Широкий advisory sweep.              | `stable` плюс advisory providers, plugin live shards і media live shards.                                                                                               |
+| Профіль  | Призначення                         | Включене live/provider-покриття                                                                                                                                              |
+| -------- | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `minimum` | Найшвидший release-critical smoke.  | OpenAI/core live path, Docker live models для OpenAI, native gateway core, native OpenAI gateway profile, native OpenAI Plugin і Docker live gateway OpenAI.                 |
+| `stable`  | Стандартний профіль схвалення релізу. | `minimum` плюс Anthropic smoke, Google, MiniMax, backend, native live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і OpenCode Go smoke shard. |
+| `full`    | Широкий advisory sweep.             | `stable` плюс advisory providers, Plugin live shards і media live shards.                                                                                                    |
 
-## Додатки лише для full
+## Додавання лише для full
 
-Ці набори пропускаються в `stable` і включаються в `full`:
+Ці набори пропускаються у `stable` і включаються у `full`:
 
-| Область                         | Покриття лише для full                                                                                                      |
-| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
-| Docker live models              | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks.                                                                             |
-| Docker live gateway             | Advisory providers, розділені на shards DeepSeek/Fireworks, OpenCode Go/OpenRouter і xAI/Z.ai.                              |
-| Native gateway provider profiles | Full Anthropic Opus і Sonnet/Haiku shards, Fireworks, DeepSeek, full OpenCode Go model shards, OpenRouter, xAI і Z.ai.       |
-| Native plugin live shards       | Plugins A-K, L-N, O-Z other, Moonshot і xAI.                                                                                |
-| Native media live shards        | Audio, Google music, MiniMax music і video groups A-D.                                                                      |
+| Область                          | Покриття лише у full                                                                                                      |
+| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
+| Docker live models               | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks.                                                                           |
+| Docker live gateway              | Advisory providers, розділені на шарди DeepSeek/Fireworks, OpenCode Go/OpenRouter і xAI/Z.ai.                            |
+| Native gateway provider profiles | Full Anthropic Opus і шарди Sonnet/Haiku, Fireworks, DeepSeek, full OpenCode Go model shards, OpenRouter, xAI і Z.ai.    |
+| Native Plugin live shards        | Plugins A-K, L-N, O-Z other, Moonshot і xAI.                                                                              |
+| Native media live shards         | Audio, Google music, MiniMax music і video groups A-D.                                                                    |
 
 `stable` включає `native-live-src-gateway-profiles-anthropic-smoke` і
 `native-live-src-gateway-profiles-opencode-go-smoke`; `full` натомість використовує ширші
@@ -138,44 +138,55 @@ Anthropic і OpenCode Go model shards. Сфокусовані повторні
 
 Використовуйте `rerun_group`, щоб не повторювати непов’язані release boxes:
 
-| Ідентифікатор       | Область                                                              |
+| Дескриптор          | Область                                                               |
 | ------------------- | --------------------------------------------------------------------- |
 | `all`               | Усі етапи повної валідації релізу.                                    |
 | `ci`                | Лише дочірній ручний повний CI.                                       |
 | `plugin-prerelease` | Лише дочірній попередній реліз Plugin.                                |
 | `release-checks`    | Усі етапи перевірок релізу OpenClaw.                                  |
 | `install-smoke`     | Install Smoke через перевірки релізу.                                 |
-| `cross-os`          | Перевірки релізу для різних ОС.                                       |
-| `live-e2e`          | Валідація E2E repo/live і шляху релізу Docker.                        |
+| `cross-os`          | Крос-ОС перевірки релізу.                                             |
+| `live-e2e`          | Валідація repo/live E2E і Docker release-path.                        |
 | `package`           | Приймання пакета.                                                     |
-| `qa`                | Паритет QA плюс live-напрями QA.                                      |
-| `qa-parity`         | Лише напрями паритету QA і звіт.                                      |
-| `qa-live`           | Лише live Matrix і Telegram для QA.                                   |
+| `qa`                | Паритет QA плюс живі лінії QA.                                        |
+| `qa-parity`         | Лише лінії паритету QA та звіт.                                       |
+| `qa-live`           | Лише жива матриця QA і Telegram.                                      |
 | `npm-telegram`      | E2E Telegram для опублікованого пакета; потребує `npm_telegram_package_spec`. |
 
-Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли один live-набір не пройшов.
-Дійсні ідентифікатори фільтрів визначені в повторно використовуваному live/E2E workflow, зокрема
+Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли відмовив один живий набір тестів.
+Дійсні ідентифікатори фільтрів визначені в багаторазовому workflow live/E2E, зокрема
 `docker-live-models`, `live-gateway-docker`,
 `live-gateway-anthropic-docker`, `live-gateway-google-docker`,
 `live-gateway-minimax-docker`, `live-gateway-advisory-docker`,
 `live-cli-backend-docker`, `live-acp-bind-docker` і
 `live-codex-harness-docker`.
 
-Ідентифікатор `live-gateway-advisory-docker` є агрегованим ідентифікатором повторного запуску для своїх
-трьох сегментів провайдерів, тому він усе одно розгортається до всіх advisory-завдань Docker gateway.
+Дескриптор `live-gateway-advisory-docker` є агрегованим дескриптором повторного запуску для своїх
+трьох шардів провайдерів, тому він усе одно розгортається на всі advisory Docker Gateway jobs.
+
+Використовуйте `cross_os_suite_filter` з `rerun_group=cross-os`, коли відмовила одна крос-ОС лінія.
+Фільтр приймає ідентифікатор ОС, ідентифікатор набору тестів або пару ОС/набір тестів, наприклад
+`windows/packaged-upgrade`, `windows` або `packaged-fresh`. Крос-ОС
+зведення містять таймінги за фазами для ліній оновлення пакетованої версії, а довготривалі
+команди друкують рядки Heartbeat, щоб зависле оновлення Windows було видно до
+тайм-ауту завдання.
+
+Лінії QA для перевірок релізу мають рекомендаційний характер. Відмова лише QA повідомляється як попередження
+і не блокує верифікатор перевірок релізу; перезапустіть `rerun_group=qa`,
+`qa-parity` або `qa-live`, коли потрібні свіжі докази QA.
 
 ## Докази, які слід зберегти
 
-Зберігайте зведення `Full Release Validation` як індекс рівня релізу. Воно посилається на
-ідентифікатори дочірніх запусків і містить таблиці найповільніших завдань. У разі збоїв спершу перевірте дочірній
-workflow, потім повторно запустіть найменший відповідний ідентифікатор вище.
+Зберігайте зведення `Full Release Validation` як індекс рівня релізу. Воно містить посилання
+на ідентифікатори дочірніх запусків і таблиці найповільніших завдань. У разі відмов спочатку перевірте дочірній
+workflow, а потім перезапустіть найменший відповідний дескриптор вище.
 
 Корисні артефакти:
 
 - `release-package-under-test` з батьківського Full Release Validation і `OpenClaw Release Checks`
-- Артефакти шляху релізу Docker у `.artifacts/docker-tests/`
-- Package Acceptance `package-under-test` і артефакти приймання Docker
-- Артефакти перевірок релізу для різних ОС для кожної ОС і набору
+- Артефакти Docker release-path у `.artifacts/docker-tests/`
+- `package-under-test` з приймання пакета та артефакти приймання Docker
+- Артефакти крос-ОС перевірок релізу для кожної ОС і набору тестів
 - Артефакти паритету QA, Matrix і Telegram
 
 ## Файли workflow