chore(i18n): refresh uk translations

docs/uk/ci.md

@@ -1,75 +1,75 @@
 ---
 read_when:
-    - Потрібно зрозуміти, чому завдання CI було або не було запущене
+    - Потрібно з’ясувати, чому завдання CI виконалося або не виконалося
     - Ви налагоджуєте перевірку GitHub Actions, яка не проходить
     - Ви координуєте запуск або повторний запуск валідації релізу
-summary: Граф завдань CI, гейти області дії, парасолькові релізи та локальні еквіваленти команд
+summary: Граф завдань CI, гейти області дії, релізні парасольки та локальні еквіваленти команд
 title: CI-конвеєр
 x-i18n:
-    generated_at: "2026-04-30T23:44:05Z"
+    generated_at: "2026-05-01T02:24:31Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 67bfe0245e2d78e88357f7068cc9bf9b99559655f87f9b65ffa89649b39bec44
+    source_hash: 0c2ee36f96ccf86d4adb739f5f7efb82c05f733e7693571ce391269d2538fec7
     source_path: ci.md
     workflow: 16
 ---
 
-OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає витратніші напрямки, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно оминають розумне обмеження області й розгортають повний граф для реліз-кандидатів і широкої перевірки. Напрямки Android лишаються опціональними через `include_android`. Покриття Plugin лише для релізів міститься в окремому workflow [`Передреліз Plugin`](#plugin-prerelease) і запускається тільки з [`Повної релізної перевірки`](#full-release-validation) або явного ручного запуску.
+OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі лінії, коли змінилися лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження scope і розгортають повний граф для release candidates та широкої валідації. Android-лінії залишаються opt-in через `include_android`. Покриття Plugin лише для релізів міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch.
 
-## Огляд конвеєра
+## Огляд pipeline
 
 | Завдання                         | Призначення                                                                                  | Коли запускається                  |
 | -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- |
-| `preflight`                      | Виявляє зміни лише в документації, змінені області, змінені extensions і будує маніфест CI  | Завжди для нечернеткових push і PR |
-| `security-scm-fast`              | Виявлення приватних ключів і аудит workflow через `zizmor`                                   | Завжди для нечернеткових push і PR |
-| `security-dependency-audit`      | Аудит production lockfile без залежностей щодо npm advisories                                | Завжди для нечернеткових push і PR |
-| `security-fast`                  | Обов’язковий агрегат для швидких завдань безпеки                                             | Завжди для нечернеткових push і PR |
-| `check-dependencies`             | Production-прохід Knip лише для залежностей плюс guard allowlist невикористаних файлів       | Зміни, релевантні Node             |
-| `build-artifacts`                | Збирає `dist/`, Control UI, перевірки зібраних артефактів і повторно використовувані downstream-артефакти | Зміни, релевантні Node             |
-| `checks-fast-core`               | Швидкі Linux-напрямки коректності, як-от перевірки bundled/plugin-contract/protocol          | Зміни, релевантні Node             |
-| `checks-fast-contracts-channels` | Sharded-перевірки контрактів каналів зі стабільним агрегованим результатом перевірки         | Зміни, релевантні Node             |
-| `checks-node-core-test`          | Shards тестів ядра Node, без напрямків channel, bundled, contract та extension               | Зміни, релевантні Node             |
-| `check`                          | Sharded-еквівалент головного локального gate: production-типи, lint, guards, test types і strict smoke | Зміни, релевантні Node             |
-| `check-additional`               | Shards для architecture, boundary, extension-surface guards, package-boundary і gateway-watch | Зміни, релевантні Node             |
-| `build-smoke`                    | Smoke-тести зібраного CLI і smoke startup-memory                                             | Зміни, релевантні Node             |
-| `checks`                         | Верифікатор для тестів каналів зібраних артефактів                                           | Зміни, релевантні Node             |
-| `checks-node-compat-node22`      | Напрямок збірки сумісності Node 22 і smoke                                                   | Ручний запуск CI для релізів       |
-| `check-docs`                     | Перевірки форматування документації, lint і битих посилань                                   | Змінено документацію               |
-| `skills-python`                  | Ruff + pytest для Skills на базі Python                                                      | Зміни, релевантні Python Skills    |
-| `checks-windows`                 | Специфічні для Windows тести process/path плюс регресії спільних runtime import specifier    | Зміни, релевантні Windows          |
-| `macos-node`                     | Напрямок тестів TypeScript для macOS із використанням спільних зібраних артефактів           | Зміни, релевантні macOS            |
-| `macos-swift`                    | Swift lint, збірка й тести для застосунку macOS                                              | Зміни, релевантні macOS            |
-| `android`                        | Unit-тести Android для обох flavor плюс одна збірка debug APK                                | Зміни, релевантні Android          |
-| `test-performance-agent`         | Щоденна оптимізація повільних тестів Codex після довіреної активності                        | Успіх main CI або ручний запуск    |
+| `preflight`                      | Виявляє зміни лише в docs, змінені scopes, змінені extensions і будує CI manifest            | Завжди для non-draft pushes і PRs  |
+| `security-scm-fast`              | Виявлення приватних ключів і аудит workflow через `zizmor`                                   | Завжди для non-draft pushes і PRs  |
+| `security-dependency-audit`      | Аудит production lockfile без залежностей проти 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-file                    | Node-релевантні зміни              |
+| `build-artifacts`                | Збирає `dist/`, Control UI, перевірки built-artifact і багаторазові 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, boundary, extension-surface guards, package-boundary і gateway-watch shards    | Node-релевантні зміни              |
+| `build-smoke`                    | Built-CLI smoke tests і startup-memory smoke                                                 | Node-релевантні зміни              |
+| `checks`                         | Verifier для built-artifact channel tests                                                    | Node-релевантні зміни              |
+| `checks-node-compat-node22`      | Node 22 compatibility build і smoke lane                                                     | Manual CI dispatch для релізів     |
+| `check-docs`                     | Форматування docs, lint і перевірки broken-link                                              | Docs змінено                       |
+| `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 app                                                      | macOS-релевантні зміни             |
+| `android`                        | Android unit tests для обох flavors плюс один debug APK build                                | Android-релевантні зміни           |
+| `test-performance-agent`         | Щоденна Codex slow-test optimization після trusted activity                                  | Main CI success або manual dispatch |
 
 ## Порядок fail-fast
 
-1. `preflight` вирішує, які напрямки взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями.
-2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи важчих завдань матриці артефактів і платформ.
-3. `build-artifacts` перекривається зі швидкими Linux-напрямками, щоб downstream-споживачі могли стартувати, щойно спільна збірка готова.
-4. Важчі платформні та runtime-напрямки розгортаються після цього: `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 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`.
 
-GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо найновіший запуск для того самого ref також не падає. Агреговані перевірки shards використовують `!cancelled() && always()`, тож вони все ще повідомляють звичайні збої shards, але не стають у чергу після того, як увесь workflow уже замінено. Автоматичний concurrency key CI версіонований (`CI-v7-*`), тож GitHub-side zombie у старій queue group не може безстроково блокувати новіші запуски main. Ручні запуски повного набору використовують `CI-manual-v1-*` і не скасовують запуски, що вже виконуються.
+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. Manual full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs.
 
-## Область і маршрутизація
+## Scope і routing
 
-Логіка області міститься в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`. Ручний запуск пропускає changed-scope detection і змушує маніфест preflight поводитися так, ніби кожну 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 змінилася.
 
-- **Редагування workflow CI** перевіряють граф Node CI плюс workflow linting, але самі по собі не змушують виконувати native-збірки Windows, Android або macOS; ці платформні напрямки лишаються обмеженими змінами платформного source.
-- **Редагування лише маршрутизації CI, вибрані дешеві редагування core-test fixtures і вузькі редагування plugin contract helper/test-routing** використовують швидкий шлях маніфесту лише для Node: `preflight`, security і одне завдання `checks-fast-core`. Цей шлях пропускає build artifacts, сумісність Node 22, channel contracts, повні core shards, bundled-plugin shards і додаткові guard matrices, коли зміна обмежена routing або helper surfaces, які швидке завдання перевіряє напряму.
-- **Перевірки Windows Node** обмежені специфічними для Windows обгортками process/path, помічниками npm/pnpm/UI runner, конфігурацією package manager і поверхнями workflow CI, що виконують цей напрямок; непов’язані source, plugin, install-smoke і test-only зміни лишаються на Linux Node-напрямках.
+- **Редагування CI workflow** валідовують Node CI graph плюс workflow linting, але самі по собі не форсують Windows, Android або macOS native builds; ці platform lanes залишаються scoped до platform source changes.
+- **CI routing-only edits, вибрані cheap 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 розділено або збалансовано, щоб кожне завдання лишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, малі core unit lanes об’єднуються в пари, auto-reply запускається як чотири balanced workers (із reply subtree, розділеним на shards agent-runner, dispatch і commands/state-routing), а agentic gateway/plugin configs розподіляються між наявними source-only agentic Node jobs замість очікування на built artifacts. Широкі browser, QA, media та miscellaneous plugin tests використовують свої dedicated Vitest configs замість спільного plugin catch-all. Include-pattern shards записують timing entries із назвою CI shard, тож `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; shard boundary guard запускає свої малі independent guards паралельно всередині одного завдання. Gateway watch, channel tests і core support-boundary shard запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрано.
+Найповільніші Node test families розділені або збалансовані, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, small core unit lanes paired, auto-reply запускається як four balanced workers (із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Broad browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries із CI shard name, тож `.artifacts/vitest-shard-timings.json` може відрізняти цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої small independent guards конкурентно всередині одного job. Gateway watch, channel tests і core support-boundary shard запускаються конкурентно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані.
 
-Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor із SMS/call-log BuildConfig flags, водночас уникаючи дублювання debug APK packaging job під час кожного Android-relevant push.
+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, закріплений на найновішій версії 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 не може статично розв’язати.
+Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, закріплений на latest Knip version, із вимкненим pnpm minimum release age для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює Knip production unused-file findings із `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий непереглянутий unused file або залишає stale allowlist entry, водночас зберігаючи intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично resolve.
 
-## Ручні запуски
+## Manual dispatches
 
-Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожен scoped lane, крім Android: Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS і Control UI i18n. Окремі ручні запуски CI запускають Android лише з `include_android=true`; повна релізна парасолька вмикає Android, передаючи `include_android=true`. Plugin prerelease static checks, release-only shard `agentic-plugins`, повний extension batch sweep і Docker-напрямки plugin prerelease виключені з CI. Набір Docker prerelease запускається лише тоді, коли `Повна релізна перевірка` запускає окремий workflow `Передреліз Plugin` з увімкненим release-validation gate.
+Manual CI dispatches запускають той самий job graph, що й звичайний CI, але примусово вмикають кожну non-Android scoped lane: Linux Node shards, bundled-plugin shards, channel contracts, Node 22 compatibility, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS і Control UI i18n. Standalone manual CI dispatches запускають Android лише з `include_android=true`; повний release umbrella вмикає Android, передаючи `include_android=true`. Plugin prerelease static checks, release-only shard `agentic-plugins`, full extension batch sweep і plugin prerelease Docker lanes виключені з CI. Docker prerelease suite запускається лише тоді, коли `Full Release Validation` dispatches окремий workflow `Plugin Prerelease` з увімкненим release-validation gate.
 
-Ручні запуски використовують унікальну concurrency group, тож повний набір для release-candidate не скасовується іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає довіреному caller запустити цей граф для branch, tag або full commit SHA, використовуючи файл workflow із вибраного dispatch ref.
+Manual runs використовують унікальну concurrency group, щоб release-candidate full suite не був скасований іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає trusted caller змогу запустити цей graph для branch, tag або full commit SHA, використовуючи workflow file з вибраного dispatch ref.
 
 ```bash
 gh workflow run ci.yml --ref release/YYYY.M.D
@@ -79,15 +79,15 @@ gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
 
 ## Runners
 
-| Виконавець                       | Завдання                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `ubuntu-24.04`                   | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контрактів/вбудованих пакетів, шардовані перевірки контрактів каналів, шарди `check`, крім lint, шарди й агрегати `check-additional`, агреговані верифікатори тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує Ubuntu, розміщений на GitHub, щоб матриця Blacksmith могла ставати в чергу раніше |
-| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, легші шарди Plugin, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types`                                                                                                                                                                                                                                                                                                                   |
-| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів вбудованих Plugin, `android`                                                                                                                                                                                                                                                                                                                                                                           |
-| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (достатньо чутливий до CPU, тому 8 vCPU коштували більше, ніж заощаджували); Docker-збірки install-smoke (час очікування черги 32-vCPU коштував більше, ніж заощаджував)                                                                                                                                                                                                                                                                                                                     |
-| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                        |
-| `blacksmith-6vcpu-macos-latest`  | `macos-node` на `openclaw/openclaw`; форки повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                  |
-| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; форки повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                 |
+| Ранер                            | Завдання                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `ubuntu-24.04`                   | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контрактів/пакетних компонентів, шардовані перевірки контрактів каналів, шарди `check`, крім lint, шарди й агрегати `check-additional`, агреговані верифікатори тестів Node, перевірки документації, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує Ubuntu, розміщений у GitHub, щоб матриця Blacksmith могла стати в чергу раніше |
+| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, легші шарди plugins, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types`                                                                                                                                                                                                                                                                                                                                  |
+| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів пакетних plugins, `android`                                                                                                                                                                                                                                                                                                                                                                         |
+| `blacksmith-16vcpu-ubuntu-2404`  | `check-lint` (достатньо чутливий до CPU, тож 8 vCPU коштували більше, ніж заощаджували); Docker-збірки install-smoke (час очікування в черзі 32-vCPU коштував більше, ніж заощаджував)                                                                                                                                                                                                                                                                                   |
+| `blacksmith-16vcpu-windows-2025` | `checks-windows`                                                                                                                                                                                                                                                                                                                                                                                                                                                          |
+| `blacksmith-6vcpu-macos-latest`  | `macos-node` на `openclaw/openclaw`; форки повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                                 |
+| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; форки повертаються до `macos-latest`                                                                                                                                                                                                                                                                                                                                                                                               |
 
 ## Локальні еквіваленти
 
@@ -117,27 +117,37 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
 
 ## Повна валідація релізу
 
-`Full Release Validation` — це ручний парасольковий workflow для "запустити все перед релізом." Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізних доказів Plugin/пакетів/статичних файлів/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker release-path, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram lanes. Він також може запускати післяпублікаційний workflow `NPM Telegram Beta E2E`, коли надано специфікацію опублікованого пакета.
+`Full Release Validation` — це ручний парасольковий workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного підтвердження plugin/package/static/Docker, а також запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів release-path для Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram lanes. Він також може запускати післяпублікаційний workflow `NPM Telegram Beta E2E`, коли надано специфікацію опублікованого пакета.
 
-`release_profile` керує широтою live/provider, переданою в release checks:
+Див. [Повна валідація релізу](/uk/reference/full-release-validation) для
+матриці етапів, точних назв завдань workflow, відмінностей профілів, артефактів і
+цільових засобів повторного запуску.
 
-- `minimum` залишає найшвидші критично важливі для релізу lanes OpenAI/core.
+`release_profile` керує широтою live/provider, що передається в release checks. Ручні релізні workflows типово використовують `stable`; використовуйте `full` лише тоді, коли ви свідомо хочете широку advisory-матрицю provider/media.
+
+- `minimum` залишає найшвидші критичні для релізу lanes OpenAI/core.
 - `stable` додає стабільний набір provider/backend.
-- `full` запускає широку матрицю рекомендаційних provider/media.
+- `full` запускає широку advisory-матрицю provider/media.
 
-Парасолька записує ідентифікатори запущених дочірніх запусків, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх запусків і додає таблиці найповільніших завдань для кожного дочірнього запуску. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське завдання verifier, щоб оновити результат парасольки та підсумок таймінгів.
+Парасолька записує ідентифікатори запущених дочірніх runs, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх runs і додає таблиці найповільніших завдань для кожного дочірнього run. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське завдання verifier, щоб оновити результат парасольки й підсумок часу.
 
-Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата релізу, `ci` лише для звичайного повного дочірнього CI, `release-checks` для кожного релізного дочірнього workflow або вужчу групу: `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, `plugin-prerelease` лише для дочірнього prerelease plugin, `release-checks` для кожного дочірнього release, або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольці. Це утримує повторний запуск failed release box в обмежених межах після цільового виправлення.
 
-`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв'язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і live/E2E Docker workflow release-path, і shard package acceptance. Це зберігає байти пакета узгодженими між релізними блоками й уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
+`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і в live/E2E release-path Docker workflow, і в shard package acceptance. Це зберігає байти пакета узгодженими між release boxes і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
+
+Дублікати runs `Full Release Validation` для `ref=main` і `rerun_group=all`
+замінюють старішу парасольку. Батьківський monitor скасовує будь-який дочірній workflow, який
+він уже запустив, коли батьківський run скасовано, тому новіша main validation
+не чекає за застарілим двогодинним release-check run. Валідація release branch/tag
+і цільові rerun groups залишають `cancel-in-progress: false`.
 
 ## Live та E2E шарди
 
-Дочірній live/E2E реліз зберігає широке native-покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання:
+Дочірній release live/E2E зберігає широке native-покриття `pnpm test:live`, але запускає його як іменовані шарди через `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`
 - `native-live-src-gateway-backends`
 - `native-live-test`
 - `native-live-extensions-a-k`
@@ -145,57 +155,57 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
 - `native-live-extensions-openai`
 - `native-live-extensions-o-z-other`
 - `native-live-extensions-xai`
-- розділені шарди media audio/video та music-шарди, відфільтровані за provider
+- розділені шарди media audio/video та provider-filtered music shards
 
-Це зберігає те саме файлове покриття, водночас спрощуючи перезапуск і діагностику повільних live-збоїв provider. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових перезапусків.
+Це зберігає те саме файлове покриття, водночас спрощуючи повторний запуск і діагностику повільних live provider failures. Агреговані назви шардiв `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків.
 
-Native live media шарди запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють бінарні файли перед налаштуванням. Тримайте Docker-backed live набори на звичайних runner Blacksmith — container jobs є неправильним місцем для запуску вкладених Docker-тестів.
+Native live media shards виконуються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media jobs лише перевіряють бінарні файли перед налаштуванням. Тримайте live suites на базі Docker на звичайних Blacksmith runners — container jobs не підходять для запуску вкладених Docker tests.
 
-Docker-backed live шарди model/backend використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Live release workflow збирає й публікує цей образ один раз, а потім Docker live model, gateway, CLI backend, ACP bind і Codex harness шарди запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці шарди незалежно перебудовують повну 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`, нижчі за timeout завдання workflow, щоб завислий контейнер або шлях очищення швидко завершувався з помилкою, а не споживав увесь бюджет release-check. Якщо ці шарди самостійно перебудовують повну source Docker target, release run налаштовано неправильно, і він марнуватиме wall clock на дублікати image builds.
 
-## Приймання пакета
+## Package Acceptance
 
-Використовуйте `Package Acceptance`, коли питання таке: "чи працює цей інстальований пакет OpenClaw як продукт?" Це відрізняється від звичайного CI: звичайний CI валідує дерево джерел, тоді як package acceptance валідує один tarball через той самий Docker E2E harness, який користувачі використовують після встановлення або оновлення.
+Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей installable package OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє source tree, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі запускають після install або update.
 
 ### Завдання
 
-1. `resolve_package` checkout-ить `workflow_ref`, розв'язує один кандидат пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить source, workflow ref, package ref, version, SHA-256 і profile у GitHub step summary.
-2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Reusable workflow завантажує цей артефакт, валідує інвентар tarball, готує Docker-образи package-digest, коли потрібно, і запускає вибрані Docker lanes проти цього пакета замість пакування workflow checkout. Коли профіль вибирає кілька цільових `docker_lanes`, reusable workflow готує пакет і спільні образи один раз, а потім розгалужує ці lanes як паралельні цільові Docker-завдання з унікальними артефактами.
-3. `package_telegram` за бажанням викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance розв'язав один; standalone Telegram dispatch усе ще може встановити опубліковану npm-специфікацію.
-4. `summary` провалює workflow, якщо package resolution, Docker acceptance або необов'язковий Telegram lane завершилися невдало.
+1. `resolve_package` перевіряє `workflow_ref`, визначає одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і друкує джерело, посилання workflow, посилання пакета, версію, SHA-256 і профіль у підсумку кроку GitHub.
+2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker-лінії для цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow один раз готує пакет і спільні образи, а потім розгортає ці лінії як паралельні цільові Docker-завдання з унікальними артефактами.
+3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance визначив його; окремий запуск Telegram усе ще може встановити опубліковану npm-специфікацію.
+4. `summary` завершує workflow з помилкою, якщо визначення пакета, Docker Acceptance або необов’язкова Telegram-лінія завершилися невдало.
 
 ### Джерела кандидатів
 
-- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, як-от `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих бета/стабільних версій.
-- `source=ref` пакує довірену гілку, тег або повний SHA коміту `package_ref`. Резолвер отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт доступний з історії гілки репозиторію або з тегу релізу, встановлює залежності у відокремленому робочому дереві та пакує його за допомогою `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 опублікованих beta/stable.
+- `source=ref` пакує довірену гілку, тег або повний SHA коміту `package_ref`. Резолвер отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт доступний з історії гілок репозиторію або релізного тегу, встановлює залежності у від’єднаному worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`.
+- `source=url` завантажує HTTPS `.tgz`; `package_sha256` обов’язковий.
+- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його слід надавати для артефактів, поширених зовні.
 
-Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/стенда, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточному тестовому стенду перевіряти старіші довірені вихідні коміти без запуску старої логіки workflow.
+Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/обв’язки, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточній тестовій обв’язці перевіряти старіші довірені вихідні коміти без запуску старої логіки workflow.
 
 ### Профілі наборів
 
 - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
 - `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `published-upgrade-survivor`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update`
 - `product` — `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
-- `full` — повні фрагменти Docker release-path з OpenWebUI
+- `full` — повні частини Docker release-path з OpenWebUI
 - `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom`
 
-Профіль `package` використовує офлайн-покриття Plugin, тому перевірка опублікованого пакета не залежить від доступності живого ClawHub. Необов’язкова лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях специфікації опублікованого npm зберігається для автономних запусків.
+Профіль `package` використовує офлайн-покриття Plugin, щоб перевірка опублікованого пакета не залежала від доступності live ClawHub. Необов’язкова Telegram-лінія повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації збережено для окремих запусків.
 
-Перевірки релізу викликають Package Acceptance із `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` і `telegram_mode=mock-openai`. Фрагменти Docker release-path покривають лінії package/update/plugin, що перетинаються; Package Acceptance зберігає перевірку сумісності bundled-channel, офлайн Plugin і Telegram, нативну для артефакта, щодо того самого розв’язаного tarball пакета. Крос-OS перевірки релізу й надалі покривають OS-специфічні onboarding, інсталятор і поведінку платформи; продуктову перевірку package/update слід починати з Package Acceptance. Лінії свіжого Windows packaged і installer також перевіряють, що встановлений пакет може імпортувати перевизначення browser-control із сирого абсолютного шляху Windows. Smoke-перевірка agent-turn OpenAI cross-OS за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо її задано, інакше `openai/gpt-5.4-mini`, щоб доказ встановлення та Gateway залишався швидким і детермінованим.
+Release checks викликають Package Acceptance з `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` і `telegram_mode=mock-openai`. Частини Docker release-path покривають перехресні лінії package/update/plugin; Package Acceptance зберігає artifact-native доказ bundled-channel compat, offline plugin і Telegram для того самого визначеного tarball пакета. Cross-OS release checks і далі покривають специфічні для ОС onboarding, installer і поведінку платформи; перевірка продукту package/update має починатися з Package Acceptance. Windows-лінії packaged і installer fresh також перевіряють, що встановлений пакет може імпортувати перевизначення browser-control із необробленого абсолютного шляху Windows. Cross-OS OpenAI agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо встановлено, інакше `openai/gpt-5.4-mini`, щоб доказ встановлення й Gateway залишався швидким і детермінованим.
 
-### Вікна застарілої сумісності
+### Вікна сумісності зі спадковими версіями
 
-Package Acceptance має обмежені вікна застарілої сумісності для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності:
+Package Acceptance має обмежені вікна сумісності зі спадковими версіями для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності:
 
-- відомі приватні QA записи в `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball;
-- `doctor-switch` може пропустити підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець;
-- `update-channel-switch` може вилучати відсутні `pnpm.patchedDependencies` із підробленого git fixture, отриманого з tarball, і може логувати відсутній збережений `update.channel`;
-- smoke-перевірки Plugin можуть читати застарілі розташування записів встановлення або приймати відсутність збереження запису встановлення marketplace;
-- `plugin-update` може дозволяти міграцію метаданих конфігурації, водночас вимагаючи, щоб запис встановлення та поведінка без повторного встановлення залишалися незмінними.
+- відомі приватні QA-записи в `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені з tarball;
+- `doctor-switch` може пропускати підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець;
+- `update-channel-switch` може вилучати відсутні `pnpm.patchedDependencies` з fake git fixture, похідного від tarball, і може журналювати відсутній збережений `update.channel`;
+- plugin smokes можуть читати спадкові розташування install-record або приймати відсутнє збереження marketplace install-record;
+- `plugin-update` може дозволяти міграцію метаданих конфігурації, водночас вимагаючи, щоб install record і поведінка без повторного встановлення лишалися незмінними.
 
-Опублікований пакет `2026.4.26` також може попереджати про локальні файли stamp метаданих збірки, які вже були відвантажені. Пізніші пакети мають задовольняти сучасні контракти; ті самі умови призводять до помилки замість попередження або пропуску.
+Опублікований пакет `2026.4.26` також може попереджати про файли stamp локальних build-метаданих, які вже були поставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови завершуються помилкою замість попередження або пропуску.
 
 ### Приклади
 
@@ -238,152 +248,152 @@ gh workflow run package-acceptance.yml \
   -f docker_lanes='install-e2e plugin-update'
 ```
 
-Під час налагодження невдалого запуску package acceptance починайте з підсумку `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перегляньте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, логи ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker-ліній замість повторного запуску повної перевірки релізу.
+Під час налагодження невдалого запуску package acceptance почніть із підсумку `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перегляньте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker-ліній замість повторного запуску повної release validation.
 
-## Smoke-перевірка встановлення
+## Install smoke
 
-Окремий workflow `Install Smoke` повторно використовує той самий скрипт області через власне завдання `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/package, змін пакетів/маніфестів bundled Plugin або поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише вихідного коду bundled Plugin, правки лише тестів і правки лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє аргумент збірки bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним таймаутом команди 240 секунд (Docker-запуск кожного сценарію обмежується окремо).
-- **Повний шлях** зберігає встановлення QR package і Docker/update-покриття інсталятора для нічних запланованих запусків, ручних запусків, workflow-call перевірок релізу та pull request, які справді торкаються поверхонь installer/package/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR smoke-образ кореневого Dockerfile для цільового SHA, а потім запускає встановлення QR package, smoke-перевірки кореневого Dockerfile/gateway, smoke-перевірки installer/update і швидкий Docker E2E bundled-plugin як окремі завдання, щоб робота інсталятора не чекала за smoke-перевірками кореневого образу.
+- **Швидкий шлях** запускається для pull request, що торкаються Docker/package surfaces, змін пакета/маніфесту вбудованих Plugin або core plugin/channel/gateway/Plugin SDK surfaces, які перевіряють Docker smoke jobs. Зміни лише у вихідному коді вбудованого Plugin, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ root Dockerfile, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє build arg вбудованого extension і запускає обмежений bundled-plugin Docker profile у межах 240-секундного агрегованого таймауту команди (кожен Docker-запуск сценарію обмежується окремо).
+- **Повний шлях** зберігає QR package install і installer Docker/update coverage для нічних запланованих запусків, ручних запусків, workflow-call release checks і pull request, що справді торкаються installer/package/Docker surfaces. У повному режимі install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий bundled-plugin Docker E2E як окремі завдання, щоб installer work не чекав позаду root image smokes.
 
-Пуші в `main` (включно з merge commits) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття на push, workflow зберігає швидку Docker smoke-перевірку й залишає повну install smoke-перевірку для нічної або релізної перевірки.
+Пуші в `main` (зокрема merge commits) не примушують повний шлях; коли логіка changed-scope просила б повне покриття на push, workflow залишає швидкий Docker smoke і лишає повний install smoke для нічної або релізної перевірки.
 
-Повільна smoke-перевірка Bun global install image-provider окремо керується `run_bun_global_install_smoke`. Вона запускається за нічним розкладом і з workflow перевірок релізу, а ручні запуски `Install Smoke` можуть увімкнути її, але pull request і пуші в `main` — ні. Docker-тести QR та інсталятора зберігають власні Dockerfile, сфокусовані на встановленні.
+Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з release checks workflow, а ручні запускі `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` — ні. QR і installer Docker tests зберігають власні install-focused Dockerfiles.
 
 ## Локальний 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`:
 
-- bare runner Node/Git для ліній installer/update/plugin-dependency;
+- мінімальний Node/Git runner для ліній installer/update/plugin-dependency;
 - функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній.
 
-Визначення Docker-ліній розташовані в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для кожної лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
+Визначення Docker-ліній містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка planner — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Scheduler вибирає образ для кожної лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
 
 ### Параметри налаштування
 
-| Змінна                                 | Типове значення | Призначення                                                                                   |
-| -------------------------------------- | --------------- | --------------------------------------------------------------------------------------------- |
-| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10              | Кількість слотів основного пулу для звичайних ліній.                                          |
-| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10              | Кількість слотів tail-пулу, чутливого до провайдерів.                                         |
-| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9               | Ліміт одночасних live-ліній, щоб провайдери не тротлили.                                      |
-| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10              | Ліміт одночасних ліній встановлення npm.                                                       |
-| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7               | Ліміт одночасних multi-service ліній.                                                          |
-| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000            | Затримка між стартами ліній, щоб уникнути штормів створення Docker daemon; задайте `0`, щоб вимкнути затримку. |
+| Змінна                                | Типове значення | Призначення                                                                                   |
+| ------------------------------------- | --------------- | --------------------------------------------------------------------------------------------- |
+| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10              | Кількість слотів main-pool для звичайних ліній.                                               |
+| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10              | Кількість слотів tail-pool, чутливого до provider.                                            |
+| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9               | Ліміт паралельних live-ліній, щоб providers не throttled.                                     |
+| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10              | Ліміт паралельних ліній npm install.                                                          |
+| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7               | Ліміт паралельних multi-service ліній.                                                        |
+| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000            | Затримка між стартами ліній, щоб уникати Docker daemon create storms; встановіть `0`, щоб вимкнути затримку. |
 | `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000         | Резервний таймаут для кожної лінії (120 хвилин); вибрані live/tail лінії використовують жорсткіші обмеження. |
-| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | unset           | `1` друкує план планувальника без запуску ліній.                                              |
-| `OPENCLAW_DOCKER_ALL_LANES`            | unset           | Список точних ліній, розділених комами; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу лінію. |
+| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | unset           | `1` друкує план scheduler без запуску ліній.                                                  |
+| `OPENCLAW_DOCKER_ALL_LANES`            | unset           | Розділений комами точний список ліній; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу лінію. |
 
-Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальний агрегат попередньо перевіряє Docker, видаляє застарілі OpenClaw E2E контейнери, виводить статус активних ліній, зберігає таймінги ліній для впорядкування від найдовших до найкоротших і за замовчуванням припиняє планувати нові pooled лінії після першої помилки.
+Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього pool, а потім працює сама, доки не звільнить capacity. Локальні агреговані preflights перевіряють Docker, видаляють застарілі OpenClaw E2E containers, виводять статус активних ліній, зберігають таймінги ліній для впорядкування longest-first і за замовчуванням припиняють планування нових pooled ліній після першої помилки.
 
-### Багаторазовий live/E2E workflow
+### Повторно використовуваний live/E2E workflow
 
-Багаторазовий live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, лінії та облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає й пушить bare/functional GHCR Docker E2E образи з тегом digest пакета через кеш Docker layers Blacksmith, коли план потребує ліній із встановленим пакетом; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні образи з digest пакета замість повторної збірки. Pull Docker-образів повторюється з обмеженим таймаутом 180 секунд на спробу, щоб завислий registry/cache stream швидко повторювався замість споживання більшої частини критичного шляху CI.
+Повторно використовуваний live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття package, типу image, live image, lane і credentials потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного запуску, або завантажує package artifact з `package_artifact_run_id`; перевіряє інвентар tarball; збирає і пушить package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли плану потрібні package-installed lanes; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість повторної збірки. Завантаження Docker image повторюються з обмеженим 180-секундним timeout на кожну спробу, щоб завислий потік registry/cache швидко повторювався, а не споживав більшу частину критичного шляху CI.
 
 ### Фрагменти release-path
 
-Docker-покриття релізу запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен фрагмент тягнув лише потрібний йому тип образу та виконував кілька ліній через той самий зважений планувальник:
+Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, тож кожен chunk завантажує лише потрібний йому тип image і виконує кілька 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 | bundled-channels`
 
-Поточні релізні Docker-фрагменти: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` через `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` і `bundled-channels-contracts`. Агрегований фрагмент `bundled-channels` залишається доступним для ручних одноразових перезапусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими псевдонімами plugin/runtime. Псевдонім смуги `install-e2e` залишається агрегованим псевдонімом ручного перезапуску для обох смуг інсталяторів провайдерів. Фрагмент `bundled-channels` запускає розділені смуги `bundled-channel-*` і `bundled-channel-update-*`, а не послідовну універсальну смугу `bundled-channel-deps`.
+Поточні 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`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` і `bundled-channels-contracts`. Сукупний chunk `bundled-channels` залишається доступним для ручних одноразових повторних запусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються сукупними alias для plugin/runtime. Alias lane `install-e2e` залишається сукупним alias ручного повторного запуску для обох provider installer lanes. Chunk `bundled-channels` запускає розділені lanes `bundled-channel-*` і `bundled-channel-update-*`, а не послідовну lane all-in-one `bundled-channel-deps`.
 
-OpenWebUI включається до `plugins-runtime-services`, коли повне покриття релізного шляху цього потребує, і зберігає окремий фрагмент `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Смуги оновлення bundled-channel повторюють спробу один раз у разі тимчасових мережевих збоїв npm.
+OpenWebUI включено до `plugins-runtime-services`, коли повне покриття release-path цього вимагає, і зберігає окремий chunk `openwebui` лише для dispatches, призначених тільки для OpenWebUI. Bundled-channel update lanes повторюються один раз у разі тимчасових npm network failures.
 
-Кожен фрагмент вивантажує `.artifacts/docker-tests/` із журналами смуг, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних смуг і командами повторного запуску для кожної смуги. Вхід `docker_lanes` workflow запускає вибрані смуги проти підготовлених образів замість завдань фрагментів, що утримує налагодження збійної смуги в межах одного цільового Docker-завдання та готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана смуга є live Docker-смугою, цільове завдання локально збирає образ live-test для цього повторного запуску. Згенеровані команди GitHub для повторного запуску окремих смуг включають `package_artifact_run_id`, `package_artifact_name` і входи підготовлених образів, коли ці значення існують, тож збійна смуга може повторно використати точний пакет і образи зі збійного запуску.
+Кожен chunk завантажує `.artifacts/docker-tests/` з lane logs, timings, `summary.json`, `failures.json`, phase timings, scheduler plan JSON, slow-lane tables і per-lane rerun commands. Input workflow `docker_lanes` запускає вибрані lanes проти підготовлених images замість chunk jobs, що обмежує debugging failed-lane одним targeted Docker job і готує, завантажує або повторно використовує package artifact для цього запуску; якщо вибрана lane є live Docker lane, targeted job збирає live-test image локально для цього повторного запуску. Згенеровані per-lane GitHub rerun commands містять `package_artifact_run_id`, `package_artifact_name` і prepared image inputs, коли ці значення існують, тож failed lane може повторно використати точні package і images із failed run.
 
 ```bash
 pnpm test:docker:rerun <run-id>      # download Docker artifacts and print combined/per-lane targeted rerun commands
 pnpm test:docker:timings <summary>   # slow-lane and phase critical-path summaries
 ```
 
-Запланований live/E2E workflow щодня запускає повний релізний Docker-набір.
+Запланований live/E2E workflow щодня запускає повний release-path Docker suite.
 
-## Передреліз Plugin
+## Plugin Попередній випуск
 
-`Plugin Prerelease` є дорожчим покриттям продукту/пакета, тому це окремий workflow, який запускається через `Full Release Validation` або явним оператором. Звичайні pull request, push у `main` і автономні ручні CI dispatch тримають цей набір вимкненим. Він балансує тести вбудованих plugin між вісьмома extension-працівниками; ці extension shard-завдання запускають до двох груп конфігурації plugin одночасно з одним Vitest-працівником на групу та більшим heap Node, щоб насичені імпортами пакети plugin не створювали додаткових CI-завдань.
+`Plugin Prerelease` є дорожчим покриттям product/package, тому це окремий workflow, який запускається `Full Release Validation` або явним operator. Звичайні pull requests, пуші в `main` і standalone manual CI dispatches не вмикають цей suite. Він балансує тести bundled plugin між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на групу і більшим Node heap, щоб import-heavy plugin batches не створювали додаткові CI jobs. Release-only Docker prerelease path групує targeted Docker lanes у малі групи, щоб не резервувати десятки runners для jobs тривалістю від однієї до трьох хвилин.
 
-## Лабораторія QA
+## QA Lab
 
-Лабораторія QA має окремі CI-смуги поза основним workflow зі smart scope.
+QA Lab має окремі CI lanes поза основним smart-scoped workflow.
 
-- Workflow `Parity gate` запускається на відповідних змінах PR і ручному dispatch; він збирає приватне середовище виконання QA та порівнює агентні пакети mock GPT-5.5 і Opus 4.6.
-- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і під час ручного dispatch; він розгортає mock parity gate, live Matrix-смугу, а також live Telegram і Discord-смуги як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а Telegram/Discord використовують оренди Convex.
+- Workflow `Parity gate` запускається на відповідних змінах PR і manual dispatch; він збирає приватний QA runtime і порівнює mock GPT-5.5 та Opus 4.6 agentic packs.
+- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і на manual dispatch; він розгортає mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують environment `qa-live-shared`, а Telegram/Discord використовують Convex leases.
 
-Релізні перевірки запускають Matrix і Telegram live transport-смуги з детермінованим mock-провайдером і mock-кваліфікованими моделями (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live-моделі та звичайного запуску provider-plugin. Live transport Gateway вимикає пошук у пам’яті, бо QA parity окремо покриває поведінку пам’яті; з’єднання з провайдером покривають окремі набори live model, native provider і Docker provider.
+Release checks запускають Matrix і Telegram live transport lanes з deterministic mock provider і mock-qualified models (`mock-openai/gpt-5.5` та `mock-openai/gpt-5.5-alt`), щоб channel contract був ізольований від live model latency і звичайного provider-plugin startup. Live transport gateway вимикає memory search, бо QA parity окремо покриває поведінку memory; provider connectivity покривається окремими suites для live model, native provider і Docker provider.
 
-Matrix використовує `--profile fast` для запланованих і релізних gates, додаючи `--fail-fast` лише тоді, коли перевірений CLI це підтримує. Стандартне значення CLI і ручний вхід workflow залишаються `all`; ручний dispatch `matrix_profile=all` завжди розбиває повне покриття Matrix на завдання `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
+Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише коли checked-out CLI це підтримує. CLI default і manual workflow input залишаються `all`; manual dispatch `matrix_profile=all` завжди шардить повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
 
-`OpenClaw Release Checks` також запускає релізно-критичні смуги Лабораторії QA перед затвердженням релізу; його QA parity gate запускає кандидатний і базовий пакети як паралельні завдання смуг, а потім завантажує обидва артефакти в невелике звітне завдання для фінального порівняння паритету.
+`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у малий report job для фінального parity comparison.
 
-Не ставте шлях landing PR за `Parity gate`, якщо зміна фактично не торкається середовища виконання QA, паритету model-pack або поверхні, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації чи unit-тестів вважайте це необов’язковим сигналом і спирайтеся на scoped CI/check докази.
+Не ставте PR landing path за `Parity gate`, якщо зміна фактично не торкається QA runtime, model-pack parity або поверхні, якою володіє parity workflow. Для звичайних виправлень channel, config, docs або unit-test вважайте це optional signal і дотримуйтеся scoped CI/check evidence.
 
 ## CodeQL
 
-Workflow `CodeQL` навмисно є вузьким первинним сканером безпеки, а не повним sweep репозиторію. Щоденні, ручні та guard-запуски для pull request не в draft сканують код Actions workflow плюс JavaScript/TypeScript-поверхні з найвищим ризиком, використовуючи запити безпеки з високою впевненістю, відфільтровані до high/critical `security-severity`.
+Workflow `CodeQL` навмисно є вузьким first-pass security scanner, а не повним repository sweep. Daily, manual і non-draft pull request guard runs сканують Actions workflow code плюс JavaScript/TypeScript поверхні з найвищим ризиком за допомогою high-confidence security queries, відфільтрованих до high/critical `security-severity`.
 
-Guard pull request залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму матрицю безпеки з високою впевненістю, що й запланований workflow. Android і macOS CodeQL не входять до стандартних PR-запусків.
+Pull request guard залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і виконує ту саму high-confidence security matrix, що й scheduled workflow. Android і macOS CodeQL не входять до PR defaults.
 
 ### Категорії безпеки
 
 | Категорія                                         | Поверхня                                                                                                                               |
 | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-security-high/core-auth-secrets`         | Auth, secrets, sandbox, cron і базова лінія gateway                                                                                    |
-| `/codeql-security-high/channel-runtime-boundary`  | Контракти реалізації основного каналу плюс runtime channel plugin, gateway, Plugin SDK, secrets, точки дотику audit                   |
-| `/codeql-security-high/network-ssrf-boundary`     | Основні поверхні SSRF, парсингу IP, network guard, web-fetch і політики SSRF Plugin SDK                                                |
-| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, помічники виконання процесів, outbound delivery і gates виконання інструментів агентом                                   |
-| `/codeql-security-high/plugin-trust-boundary`     | Поверхні довіри інсталяції Plugin, loader, manifest, registry, staging runtime-dependency, source-loading і контракту пакета Plugin SDK |
+| `/codeql-security-high/core-auth-secrets`         | Auth, secrets, sandbox, cron і gateway baseline                                                                                        |
+| `/codeql-security-high/channel-runtime-boundary`  | Core channel implementation contracts плюс channel plugin runtime, gateway, Plugin SDK, secrets, audit touchpoints                    |
+| `/codeql-security-high/network-ssrf-boundary`     | Core SSRF, IP parsing, network guard, web-fetch і Plugin SDK SSRF policy surfaces                                                      |
+| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, process execution helpers, outbound delivery і agent tool-execution gates                                                 |
+| `/codeql-security-high/plugin-trust-boundary`     | Plugin install, loader, manifest, registry, runtime-dependency staging, source-loading і Plugin SDK package contract trust surfaces    |
 
-### Платформоспецифічні security shard
+### Platform-specific security shards
 
-- `CodeQL Android Critical Security` — запланований security shard Android. Збирає Android-застосунок вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Вивантажує під `/codeql-critical-security/android`.
-- `CodeQL macOS Critical Security` — щотижневий/ручний security shard macOS. Збирає macOS-застосунок вручну для CodeQL на Blacksmith macOS, відфільтровує результати dependency build із вивантаженого SARIF і вивантажує під `/codeql-critical-security/macos`. Тримається поза щоденними стандартами, бо macOS build домінує runtime навіть коли проходить без помилок.
+- `CodeQL Android Critical Security` — scheduled Android security shard. Збирає Android app вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує під `/codeql-critical-security/android`.
+- `CodeQL macOS Critical Security` — weekly/manual macOS security shard. Збирає macOS app вручну для CodeQL на Blacksmith macOS, відфільтровує dependency build results із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Залишається поза daily defaults, бо macOS build домінує за runtime навіть коли clean.
 
-### Категорії критичної якості
+### Категорії Critical Quality
 
-`CodeQL Critical Quality` є відповідним не-security shard. Він запускає лише JavaScript/TypeScript-запити якості з error-severity, не пов’язані з безпекою, по вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його guard pull request навмисно менший за запланований профіль: PR не в draft запускають лише відповідні shard `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін у коді виконання команд/моделей/інструментів агентом і dispatch відповіді, схемі конфігурації/міграції/IO-коді, коді auth/secrets/sandbox/security, основному каналі та runtime вбудованого channel plugin, протоколі Gateway/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, runtime провайдера/каталозі моделей, diagnostics сесій/чергах доставки, loader plugin, Plugin SDK/package-contract або runtime відповідей Plugin SDK. Зміни конфігурації CodeQL і quality workflow запускають усі дванадцять PR quality shard.
+`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries по вузьких high-value surfaces на меншому Blacksmith Linux runner. Його pull request guard навмисно менший за scheduled profile: non-draft PRs запускають лише відповідні shards `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для agent command/model/tool execution і reply dispatch code, config schema/migration/IO code, auth/secrets/sandbox/security code, core channel і bundled channel plugin runtime, gateway protocol/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, Plugin SDK/package-contract або змін Plugin SDK reply runtime. Зміни CodeQL config і quality workflow запускають усі дванадцять PR quality shards.
 
-Ручний dispatch приймає:
+Manual dispatch приймає:
 
 ```
 profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
 ```
 
-Вузькі профілі є hooks для навчання/ітерації, щоб запускати один quality shard ізольовано.
+Вузькі profiles є teaching/iteration hooks для запуску одного quality shard ізольовано.
 
-| Категорія                                              | Поверхня                                                                                                                                                                      |
-| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-critical-quality/core-auth-secrets`            | Код межі безпеки Auth, секретів, 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`      | Memory host SDK, фасади runtime пам’яті, псевдоніми memory Plugin SDK, зв’язувальний код активації runtime пам’яті та команди memory doctor                                  |
-| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішня логіка черги відповідей, черги доставки сесій, допоміжні засоби прив’язування/доставки вихідних сесій, поверхні діагностичних подій/пакетів журналів і контракти CLI session doctor |
-| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Вхідна диспетчеризація відповідей Plugin SDK, допоміжні засоби payload/chunking/runtime для відповідей, параметри відповідей каналу, черги доставки та допоміжні засоби прив’язування сесій/потоків |
-| `/codeql-critical-quality/provider-runtime-boundary`    | Нормалізація каталогу моделей, автентифікація та виявлення провайдерів, реєстрація runtime провайдерів, стандартні значення/каталоги провайдерів і реєстри web/search/fetch/embedding |
-| `/codeql-critical-quality/ui-control-plane`             | Початкове завантаження UI керування, локальна сталість даних, потоки керування Gateway і контракти runtime контрольної площини завдань                                        |
-| `/codeql-critical-quality/web-media-runtime-boundary`   | Основні контракти runtime для web fetch/search, media IO, розуміння медіа, генерації зображень і генерації медіа                                                             |
-| `/codeql-critical-quality/plugin-boundary`              | Контракти завантажувача, реєстру, публічної поверхні та точок входу Plugin SDK                                                                                                |
-| `/codeql-critical-quality/plugin-sdk-package-contract`  | Опубліковане джерело Plugin SDK на боці пакета та допоміжні засоби контракту пакета plugin                                                                                   |
+| Категорія                                              | Поверхня                                                                                                                                                              |
+| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `/codeql-critical-quality/core-auth-secrets`            | Код межі безпеки автентифікації, секретів, пісочниці, Cron і Gateway                                                                                                  |
+| `/codeql-critical-quality/config-boundary`              | Схема конфігурації, міграція, нормалізація та IO-контракти                                                                                                            |
+| `/codeql-critical-quality/gateway-runtime-boundary`     | Схеми протоколу Gateway і контракти методів сервера                                                                                                                   |
+| `/codeql-critical-quality/channel-runtime-boundary`     | Контракти реалізації основного каналу та bundled channel plugin                                                                                                        |
+| `/codeql-critical-quality/agent-runtime-boundary`       | Виконання команд, маршрутизація моделей/провайдерів, маршрутизація та черги автоматичних відповідей, а також runtime-контракти control plane 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 провайдерів, типові значення/каталоги провайдерів і реєстри web/search/fetch/embedding |
+| `/codeql-critical-quality/ui-control-plane`             | Початкове завантаження Control UI, локальна персистентність, потоки керування Gateway і runtime-контракти control plane задач                                         |
+| `/codeql-critical-quality/web-media-runtime-boundary`   | Runtime-контракти основних web fetch/search, медійного IO, розуміння медіа, генерації зображень і генерації медіа                                                     |
+| `/codeql-critical-quality/plugin-boundary`              | Контракти завантажувача, реєстру, публічної поверхні та entrypoint Plugin SDK                                                                                         |
+| `/codeql-critical-quality/plugin-sdk-package-contract`  | Опублікований вихідний код Plugin SDK на боці пакета та допоміжні засоби контракту пакета plugin                                                                      |
 
-Якість залишається окремо від безпеки, щоб знахідки щодо якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і вбудованих plugin слід повертати як обмежену за областю або шардовану подальшу роботу лише після того, як вузькі профілі матимуть стабільні runtime і сигнал.
+Якість лишається окремою від безпеки, щоб результати перевірок якості можна було планувати, вимірювати, вимикати або розширювати, не затіняючи сигнал безпеки. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
 
-## Робочі процеси обслуговування
+## Робочі процеси супроводу
 
 ### Агент документації
 
-Робочий процес `Docs Agent` — це подієво керована лінія обслуговування Codex для підтримання наявної документації у відповідності з нещодавно внесеними змінами. Він не має чистого розкладу: успішний CI-запуск push не від бота на `main` може його запустити, а ручний dispatch може запустити його напряму. Виклики через workflow-run пропускаються, коли `main` уже просунувся далі або коли інший непропущений запуск Docs Agent було створено протягом останньої години. Під час запуску він переглядає діапазон комітів від попереднього непропущеного source SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з часу останнього проходу документації.
+Робочий процес `Docs Agent` — це подієво-керований канал супроводу Codex для підтримання наявної документації відповідно до нещодавно landed змін. Він не має чистого розкладу: успішний CI-запуск non-bot push на `main` може його запустити, а manual dispatch може запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже зрушив далі або коли інший non-skipped запуск Docs Agent було створено протягом останньої години. Коли він запускається, він переглядає діапазон комітів від попереднього non-skipped source SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з часу останнього проходу документації.
 
 ### Агент продуктивності тестів
 
-Робочий процес `Test Performance Agent` — це подієво керована лінія обслуговування Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск push не від бота на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже виконувався або виконується цього UTC-дня. Ручний dispatch обходить цей щоденний activity gate. Лінія будує згрупований звіт продуктивності Vitest для повного набору, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт повного набору й відхиляє зміни, що зменшують базову кількість тестів, які проходять. Якщо у baseline є тести з помилками, Codex може виправляти лише очевидні збої, а звіт повного набору після агента має пройти, перш ніж щось буде закомічено. Коли `main` просувається до того, як bot push потрапить у репозиторій, лінія rebase-ить перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patch пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму безпечну позицію drop-sudo, що й агент документації.
+Робочий процес `Test Performance Agent` — це подієво-керований канал супроводу Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск non-bot push на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже виконувався або виконується цього UTC-дня. Manual dispatch обходить цей щоденний activity gate. Канал формує grouped Vitest-звіт продуктивності повного набору, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт повного набору й відхиляє зміни, що зменшують базову кількість passing тестів. Якщо в базовому стані є failing тести, Codex може виправляти лише очевидні збої, а after-agent звіт повного набору має пройти, перш ніж щось буде закомічено. Коли `main` просувається вперед до того, як bot push потрапить у репозиторій, канал перебазовує перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб action Codex міг зберігати ту саму drop-sudo safety posture, що й агент документації.
 
-### Дублікати PR після злиття
+### Дублікати PR після merge
 
-Робочий процес `Duplicate PRs After Merge` — це ручний робочий процес maintainer для очищення дублікатів після land. За замовчуванням він працює як dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR змерджено і що кожен дублікат має або спільну referenced issue, або перекривні змінені hunks.
+Робочий процес `Duplicate PRs After Merge` — це ручний maintainer workflow для очищення дублікатів після landing. За замовчуванням він працює як dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR об’єднано, і що кожен duplicate має або спільну referenced issue, або перекривні changed hunks.
 
 ```bash
 gh workflow run duplicate-after-merge.yml \
@@ -394,25 +404,25 @@ gh workflow run duplicate-after-merge.yml \
 
 ## Локальні check gates і маршрутизація змін
 
-Локальна логіка changed-lane живе в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широка область CI-платформи:
+Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий scope платформи CI:
 
-- зміни core production запускають core prod і core test typecheck плюс core lint/guards;
-- зміни лише core test запускають лише core test typecheck плюс core lint;
-- зміни extension production запускають extension prod і extension test typecheck плюс extension lint;
-- зміни лише extension test запускають extension test typecheck плюс extension lint;
-- зміни публічного Plugin SDK або plugin-contract розширюються до extension typecheck, бо extensions залежать від цих core contracts (обходи Vitest для extensions залишаються явною тестовою роботою);
-- зміни лише release metadata для bump версії запускають цільові перевірки version/config/root-dependency;
-- невідомі зміни root/config безпечно переходять до всіх check lanes.
+- зміни production-коду core запускають core prod і core test typecheck плюс core lint/guards;
+- зміни лише core tests запускають тільки core test typecheck плюс core lint;
+- зміни production-коду extension запускають extension prod і extension test typecheck плюс extension lint;
+- зміни лише extension tests запускають extension test typecheck плюс extension lint;
+- зміни public Plugin SDK або plugin-contract розширюються до extension typecheck, бо extensions залежать від цих core-контрактів (Vitest extension sweeps лишаються явною тестовою роботою);
+- version bumps лише release metadata запускають targeted version/config/root-dependency checks;
+- невідомі зміни root/config fail safe до всіх check lanes.
 
-Локальна маршрутизація changed-test живе в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі редагування тестів запускають самі себе, редагування source віддають перевагу явним зіставленням, потім sibling tests і залежним елементам import graph. Конфігурація доставки shared group-room є одним із явних зіставлень: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс регресії доставки Discord і Slack, щоб зміна спільного стандартного значення падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна достатньо широка для harness, що дешевий mapped set не є надійним proxy.
+Локальна маршрутизація changed-test міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі зміни тестів запускають самі себе, зміни source віддають перевагу явним mappings, потім sibling tests та import-graph dependents. Спільна group-room delivery config є одним із явних mappings: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс регресії доставки Discord і Slack, щоб зміна спільного default впала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна настільки harness-wide, що дешевий mapped set не є надійним proxy.
 
 ## Валідація Testbox
 
-Запускайте Testbox з кореня репозиторію й надавайте перевагу свіжому прогрітому box для широкого proof. Перш ніж витрачати повільний gate на box, який повторно використовувався, протермінувався або щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` всередині box.
+Запускайте Testbox із root репозиторію та віддавайте перевагу свіжій прогрітій box для широкого proof. Перш ніж витрачати повільний gate на box, який було повторно використано, який expired або щойно повідомив про несподівано велику sync, спочатку запустіть `pnpm testbox:sanity` усередині box.
 
-Sanity check швидко падає, коли обов’язкові root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що стан remote sync не є надійною копією PR; зупиніть цей box і прогрійте свіжий замість налагодження помилки product test. Для навмисних PR із великим видаленням задайте `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run.
+Sanity check швидко падає, коли потрібні root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що стан remote sync не є надійною копією PR; зупиніть цю box і прогрійте свіжу замість налагодження product test failure. Для навмисних PR із великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run.
 
-`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у sync phase понад п’ять хвилин без post-sync output. Задайте `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше значення в мілісекундах для незвично великих локальних diffs.
+`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який лишається у фазі sync понад п’ять хвилин без post-sync output. Встановіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше значення в мілісекундах для незвично великих local diffs.
 
 ## Пов’язане
 

docs/uk/reference/RELEASING.md

@@ -1,244 +1,244 @@
 ---
 read_when:
-    - Пошук визначень загальнодоступних каналів релізів
-    - Запуск перевірки релізу або приймання пакета
-    - Шукаєте правила іменування версій і періодичність випусків
-summary: Релізні канали, контрольний список оператора, блоки валідації, іменування версій і періодичність
+    - Пошук визначень публічних каналів випуску
+    - Запуск перевірки релізу або приймального тестування пакета
+    - Пошук схеми іменування версій і періодичності
+summary: Канали випуску, контрольний список оператора, валідаційні бокси, іменування версій і каденція
 title: Політика випусків
 x-i18n:
-    generated_at: "2026-04-30T21:58:08Z"
+    generated_at: "2026-05-01T02:24:33Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 2270223edb41f3c3731ad44fd6f8c8876e9908933bb61eddd350e344e0160121
+    source_hash: bb56568bf860ba9eae47df71c5c1ebefe9eb9ae05ac4706dbb425772ff6cdcaa
     source_path: reference/RELEASING.md
     workflow: 16
 ---
 
-OpenClaw має три публічні канали випусків:
+OpenClaw має три публічні канали релізів:
 
-- стабільний: позначені тегами випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest` за явним запитом
-- бета: передрелізні теги, які публікуються в npm `beta`
-- розробницький: рухома верхівка `main`
+- 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`
   - 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 залишають для стабільних релізів, якщо це не запитано явно
 
-## Частота випусків
+## Частота релізів
 
-- Випуски рухаються спочатку через бета-версію
-- Стабільний випуск іде лише після перевірки найновішої бета-версії
-- Супровідники зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної
-  з поточного `main`, щоб перевірка випуску та виправлення не блокували нову
+- Релізи рухаються спершу через beta
+- Стабільний реліз іде лише після перевірки останньої beta
+- Maintainers зазвичай готують релізи з гілки `release/YYYY.M.D`, створеної
+  з поточної `main`, щоб перевірка релізу й виправлення не блокували нову
   розробку в `main`
-- Якщо бета-тег уже було надіслано або опубліковано і він потребує виправлення, супровідники створюють
-  наступний тег `-beta.N` замість видалення або повторного створення старого бета-тега
-- Детальна процедура випуску, затвердження, облікові дані та нотатки з відновлення
-  доступні лише супровідникам
+- Якщо beta-тег уже було надіслано або опубліковано й він потребує виправлення, maintainers створюють
+  наступний тег `-beta.N` замість видалення чи повторного створення старого beta-тега
+- Докладна процедура релізу, затвердження, облікові дані та нотатки щодо відновлення
+  доступні лише maintainers
 
-## Контрольний список оператора випуску
+## Контрольний список оператора релізу
 
-Цей контрольний список описує публічну форму процесу випуску. Приватні облікові дані,
-підписування, нотаризація, відновлення dist-tag і деталі аварійного відкату залишаються в
-інструкції з випуску лише для супровідників.
+Цей контрольний список описує публічну форму процесу релізу. Приватні облікові дані,
+підписування, нотаризація, відновлення dist-tag і деталі екстреного відкату залишаються в
+релізному runbook лише для maintainers.
 
-1. Почніть із поточного `main`: отримайте найновіші зміни, підтвердьте, що цільовий коміт надіслано,
-   і підтвердьте, що поточний CI для `main` достатньо зелений, щоб створити від нього гілку.
+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. Підвищте версію в кожному потрібному місці для запланованого тега, потім запустіть
+5. Підніміть версію в кожному потрібному місці для запланованого тега, потім запустіть
    локальну детерміновану попередню перевірку:
    `pnpm check:test-types`, `pnpm check:architecture`,
    `pnpm build && pnpm ui:build` і `pnpm release:check`.
-6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До існування тега
-   для попередньої перевірки лише з метою валідації дозволено повний 40-символьний SHA гілки випуску.
+6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тега
+   для попередньої перевірки лише з метою валідації дозволено повний 40-символьний SHA релізної гілки.
    Збережіть успішний `preflight_run_id`.
 7. Запустіть усі передрелізні тести через `Full Release Validation` для
-   гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу
-   для чотирьох великих тестових середовищ випуску: Vitest, Docker, QA Lab і Package.
-8. Якщо валідація не пройшла, виправте в гілці випуску та повторно запустіть найменший невдалий
-   файл, канал, завдання workflow, профіль пакета, провайдера або список дозволених моделей, який
-   доводить виправлення. Повторно запускайте повну парасолькову перевірку лише тоді, коли змінена поверхня робить
+   релізної гілки, тега або повного SHA коміту. Це єдина ручна точка входу
+   для чотирьох великих релізних тестових боксів: Vitest, Docker, QA Lab і Package.
+8. Якщо валідація не проходить, виправте на релізній гілці й повторно запустіть найменший невдалий
+   файл, канал, завдання workflow, профіль пакета, провайдера або allowlist моделей, що
+   доводить виправлення. Повторно запускайте весь umbrella лише тоді, коли змінена поверхня робить
    попередні докази застарілими.
-9. Для бета-версії створіть тег `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, потім запустіть
-   post-publish package acceptance для опублікованого пакета `openclaw@YYYY.M.D-beta.N`
-   або `openclaw@beta`. Якщо надіслана або опублікована бета-версія потребує виправлення, створіть
-   наступний `-beta.N`; не видаляйте й не переписуйте стару бета-версію.
-10. Для стабільного випуску продовжуйте лише після того, як перевірена бета-версія або кандидат випуску має
-    потрібні докази валідації. Стабільна публікація npm повторно використовує успішний
-    артефакт попередньої перевірки через `preflight_run_id`; готовність стабільного випуску macOS
+9. Для beta позначте тегом `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, потім запустіть
+   приймання пакета після публікації проти опублікованого пакета `openclaw@YYYY.M.D-beta.N`
+   або `openclaw@beta`. Якщо надіслана або опублікована beta потребує виправлення, створіть
+   наступний `-beta.N`; не видаляйте й не переписуйте стару beta.
+10. Для стабільного релізу продовжуйте лише після того, як перевірена beta або release candidate має
+    потрібні докази валідації. Стабільна npm-публікація повторно використовує успішний
+    preflight-артефакт через `preflight_run_id`; готовність стабільного релізу macOS
     також потребує запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого
     `appcast.xml` у `main`.
-11. Після публікації запустіть npm post-publish verifier, необов’язковий автономний
+11. Після публікації запустіть npm-перевірку після публікації, необов’язковий автономний
     published-npm Telegram E2E, коли потрібен доказ каналу після публікації,
     просування dist-tag за потреби, нотатки GitHub release/prerelease з
-    повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску.
+    повного відповідного розділу `CHANGELOG.md` і кроки оголошення релізу.
 
-## Попередня перевірка випуску
+## Попередня перевірка релізу
 
 - Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався
   покритим поза швидшим локальним шлюзом `pnpm check`
 - Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів
-  імпорту та архітектурних меж були зеленими поза швидшим локальним шлюзом
+  імпорту та меж архітектури були зеленими поза швидшим локальним шлюзом
 - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
-  релізні артефакти `dist/*` і пакет Control UI існували для кроку валідації
-  пакета
+  релізні артефакти `dist/*` і бандл Control UI існували для етапу перевірки
+  пакування
 - Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб
   запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку,
   тег або повний SHA коміту, запускає ручний `CI` і запускає
-  `OpenClaw Release Checks` для install smoke, приймання пакета, наборів Docker
-  для релізного шляху, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram
-  lanes. Надавайте `npm_telegram_package_spec` лише після публікації пакета,
-  коли також має виконатися післяпублікаційний Telegram E2E. Надавайте
-  `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що
-  валідація відповідає опублікованому npm-пакету, без примусового Telegram E2E.
+  `OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker
+  release-path, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram
+  lanes. Указуйте `npm_telegram_package_spec` лише після публікації пакета,
+  коли також має виконатися післяпублікаційний Telegram E2E. Указуйте
+  `evidence_package_spec`, коли приватний звіт із доказами має підтвердити, що
+  валідація відповідає опублікованому npm-пакету без примусового запуску Telegram E2E.
   Приклад:
   `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
-- Запустіть ручний workflow `Package Acceptance`, коли потрібне підтвердження
-  побічним каналом для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для
+- Запустіть ручний workflow `Package Acceptance`, коли потрібен доказ side-channel
+  для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для
   `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`,
-  щоб запакувати довірену гілку/тег/SHA `package_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 проти цього
   tarball і може запускати Telegram QA проти того самого tarball з
   `telegram_mode=mock-openai` або `telegram_mode=live-frontier`.
   Приклад: `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 telegram_mode=mock-openai`
   Поширені профілі:
-  - `smoke`: lanes інсталяції/каналу/агента, мережі Gateway і перезавантаження конфігурації
-  - `package`: lanes пакета/оновлення/Plugin, нативні для артефакта, без OpenWebUI або live ClawHub
-  - `product`: профіль package плюс MCP-канали, cron/очищення subagent,
+  - `smoke`: lanes для install/channel/agent, мережі Gateway і перезавантаження конфігурації
+  - `package`: lanes для artifact-native package/update/plugin без OpenWebUI або live ClawHub
+  - `product`: профіль package плюс MCP-канали, очищення cron/subagent,
     вебпошук OpenAI і OpenWebUI
-  - `full`: фрагменти Docker release-path з OpenWebUI
+  - `full`: chunks Docker release-path з OpenWebUI
   - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску
-- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI
-  покриття для кандидата релізу. Ручні CI-запуски оминають changed
+- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI
+  для релізного кандидата. Ручні dispatch CI обходять changed
   scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel
   contracts, сумісність Node 22, `check`, `check-additional`, build smoke,
-  перевірки документації, Python skills, Windows, macOS, Android і Control UI i18n
+  перевірки 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
-  span, обмежені атрибути та редагування контенту/ідентифікаторів без потреби
-  в Opik, Langfuse або іншому зовнішньому collector.
-- Запускайте `pnpm release:check` перед кожним тегованим релізом
+- Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Це перевіряє
+  QA-lab через локальний OTLP/HTTP-приймач і верифікує експортовані назви trace
+  span, обмежені атрибути та редагування content/identifier без потреби в
+  Opik, Langfuse або іншому зовнішньому колекторі.
+- Запускайте `pnpm release:check` перед кожним релізом із тегом
 - Релізні перевірки тепер виконуються в окремому ручному workflow:
   `OpenClaw Release Checks`
 - `OpenClaw Release Checks` також запускає mock parity gate QA Lab плюс швидкий
-  live Matrix profile і Telegram QA lane перед схваленням релізу. Live
-  lanes використовують середовище `qa-live-shared`; Telegram також використовує оренду
-  облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з
+  live-профіль Matrix і lane Telegram QA перед схваленням релізу. Live
+  lanes використовують середовище `qa-live-shared`; Telegram також використовує leases облікових даних Convex CI.
+  Запускайте ручний workflow `QA-Lab - All Lanes` з
   `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix
   transport, media та E2EE паралельно.
-- Міжплатформна runtime-валідація інсталяції й оновлення входить до публічних
-  `OpenClaw Release Checks` і `Full Release Validation`, які викликають
+- Cross-OS runtime-валідація встановлення та оновлення є частиною публічних
+  `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають
   reusable workflow
-  `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` напряму
-- Цей поділ навмисний: реальний npm release path має залишатися коротким,
-  детермінованим і сфокусованим на артефактах, тоді як повільніші live-перевірки залишаються
-  у власній lane, щоб не затримувати й не блокувати публікацію
-- Релізні перевірки, що містять секрети, слід запускати через `Full Release
+  `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
+- Це розділення навмисне: тримайте реальний npm release path коротким,
+  детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються у
+  власній lane, щоб вони не затримували й не блокували публікацію
+- Релізні перевірки з секретами слід запускати через `Full Release
 Validation` або з workflow ref `main`/release, щоб логіка workflow і
   секрети залишалися контрольованими
-- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, доки
-  розв’язаний коміт доступний з гілки OpenClaw або релізного тегу
-- Validation-only preflight `OpenClaw NPM Release` також приймає поточний
+- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо
+  резолвлений коміт доступний з гілки OpenClaw або релізного тегу
+- Validation-only передрелізна перевірка `OpenClaw NPM Release` також приймає поточний
   повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тегу
-- Цей SHA path призначений лише для валідації та не може бути підвищений до реальної публікації
-- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки
-  метаданих пакета; реальна публікація все одно вимагає справжнього релізного тегу
-- Обидва workflow тримають реальний шлях публікації та promotion на GitHub-hosted
-  runners, тоді як немутуючий шлях валідації може використовувати більші
+- Цей шлях SHA призначений лише для валідації й не може бути просунутий у реальну публікацію
+- У режимі SHA workflow синтезує `v<package.json version>` лише для
+  перевірки метаданих пакета; реальна публікація все одно потребує справжнього релізного тегу
+- Обидва workflow тримають реальні шляхи публікації та promotion на GitHub-hosted
+  runners, тоді як немутувальний шлях валідації може використовувати більші
   Blacksmith Linux runners
 - Цей workflow запускає
   `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
   з використанням workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
-- npm release preflight більше не чекає на окрему lane релізних перевірок
+- Передрелізна перевірка npm-релізу більше не чекає на окрему lane релізних перевірок
 - Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
-  (або відповідний beta/correction tag) перед схваленням
+  (або відповідний beta/correction тег) перед схваленням
 - Після npm publish запустіть
   `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  (або відповідну beta/correction version), щоб перевірити опублікований шлях інсталяції
-  registry у свіжому тимчасовому префіксі
+  (або відповідну beta/correction версію), щоб перевірити шлях встановлення з опублікованого registry
+  у свіжому тимчасовому 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 vars і передавати три
+  щоб перевірити onboarding установленого пакета, налаштування Telegram і реальний Telegram E2E
+  проти опублікованого npm-пакета з використанням спільного leased pool облікових даних Telegram.
+  Локальні одноразові запуски maintainer можуть опустити Convex vars і передати три
   env credentials `OPENCLAW_QA_TELEGRAM_*` напряму.
 - Maintainers можуть запускати ту саму післяпублікаційну перевірку з GitHub Actions через
   ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
-  не виконується під час кожного merge.
+  не запускається після кожного merge.
 - Автоматизація релізів maintainer тепер використовує preflight-then-promote:
-  - реальна npm publish має пройти успішний npm `preflight_run_id`
-  - реальна npm publish має бути запущена з тієї самої гілки `main` або
+  - реальний npm publish має пройти успішний npm `preflight_run_id`
+  - реальний npm publish має бути запущений з тієї самої гілки `main` або
     `release/YYYY.M.D`, що й успішний preflight run
-  - stable npm releases за замовчуванням спрямовуються до `beta`
-  - stable npm publish може явно цілитися в `latest` через workflow input
-  - token-based mutation npm dist-tag тепер живе в
+  - стабільні npm-релізи за замовчуванням ідуть у `beta`
+  - стабільний npm publish може явно цілити в `latest` через input workflow
+  - token-based мутація npm dist-tag тепер розміщена в
     `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
-    для безпеки, бо `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як
-    публічний repo зберігає OIDC-only publish
-  - публічний `macOS Release` є validation-only; коли tag існує лише в
-    release branch, але workflow запускається з `main`, задайте
+    з міркувань безпеки, бо `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як
+    публічний репозиторій зберігає OIDC-only publish
+  - публічний `macOS Release` є validation-only; коли тег існує лише в
+    релізній гілці, але workflow запускається з `main`, установіть
     `public_release_branch=release/YYYY.M.D`
-  - реальна private mac publish має пройти успішні private mac
+  - реальний приватний mac publish має пройти успішні приватні mac
     `preflight_run_id` і `validate_run_id`
-  - реальні publish paths просувають підготовлені артефакти замість повторного
-    rebuilding
-- Для stable correction releases на кшталт `YYYY.M.D-N` post-publish verifier
-  також перевіряє той самий шлях upgrade в temp-prefix з `YYYY.M.D` до `YYYY.M.D-N`,
-  щоб release corrections не могли непомітно залишити старі глобальні інсталяції на
+  - реальні шляхи публікації просувають підготовлені артефакти замість повторного
+    їх збирання
+- Для стабільних correction-релізів на кшталт `YYYY.M.D-N` післяпублікаційний verifier
+  також перевіряє той самий шлях оновлення temp-prefix з `YYYY.M.D` до `YYYY.M.D-N`,
+  щоб release corrections не могли непомітно залишити старіші глобальні встановлення на
   базовому stable payload
-- npm release preflight fails closed, якщо tarball не містить одночасно
-  `dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`,
-  щоб ми знову не відправили порожній браузерний dashboard
-- Post-publish verification також перевіряє, що опублікована registry install
-  містить непорожні runtime deps bundled plugin під кореневим layout `dist/*`.
-  Реліз, який постачається з відсутніми або порожніми dependency payloads bundled plugin,
+- Передрелізна перевірка npm-релізу fails closed, якщо tarball не містить і
+  `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`,
+  щоб ми знову не відвантажили порожню браузерну панель
+- Післяпублікаційна перевірка також перевіряє, що встановлення з опублікованого registry
+  містить непорожні runtime deps bundled Plugin під кореневим layout `dist/*`.
+  Реліз, який постачається з відсутніми або порожніми payload залежностей bundled Plugin,
   провалює postpublish verifier і не може бути просунутий
   до `latest`.
-- `pnpm test:install:smoke` також застосовує бюджет npm pack `unpackedSize` до
+- `pnpm test:install:smoke` також забезпечує бюджет npm pack `unpackedSize` на
   candidate update tarball, тому installer e2e ловить випадкове pack bloat
   до release publish path
-- Якщо релізна робота торкнулася CI planning, extension timing manifests або
-  extension test matrices, перегенеруйте й перегляньте належні planner
-  outputs matrix `plugin-prerelease-extension-shard` з
+- Якщо релізна робота торкалася планування CI, timing manifests розширень або
+  matrices тестів розширень, перегенеруйте й перегляньте outputs matrix
+  `plugin-prerelease-extension-shard`, якими володіє planner, з
   `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не
-  описували застарілий CI layout
-- Готовність stable macOS release також включає updater surfaces:
+  описували застарілий layout CI
+- Готовність стабільного macOS-релізу також включає поверхні updater:
   - GitHub release має в підсумку містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
   - `appcast.xml` на `main` має вказувати на новий stable zip після publish
   - запакований app має зберігати non-debug bundle id, непорожній Sparkle feed
-    URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor
+    URL і `CFBundleVersion` на рівні або вище канонічної Sparkle build floor
     для цієї release version
 
 ## Релізні тестові бокси
 
-`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести з
-однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте release
-branch, tag або повний commit SHA як `ref`:
+`Full Release Validation` — це спосіб для операторів запускати всі передрелізні тести з
+однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте релізну
+гілку, тег або повний SHA коміту як `ref`:
 
 ```bash
 gh workflow run full-release-validation.yml \
@@ -246,39 +246,42 @@ gh workflow run full-release-validation.yml \
   -f ref=release/YYYY.M.D \
   -f provider=openai \
   -f mode=both \
-  -f release_profile=full \
+  -f release_profile=stable \
   -f evidence_package_spec=openclaw@YYYY.M.D-beta.N
 ```
 
-Workflow розв’язує target ref, запускає ручний `CI` з
+Workflow резолвить target ref, запускає ручний `CI` з
 `target_ref=<release-ref>`, запускає `OpenClaw Release Checks` і
-за потреби запускає окремий post-publish Telegram E2E, коли
-`npm_telegram_package_spec` задано. Далі `OpenClaw Release Checks` розгортає
+опційно запускає standalone післяпублікаційний Telegram E2E, коли
+`npm_telegram_package_spec` установлено. Потім `OpenClaw Release Checks` fan out
 install smoke, cross-OS release checks, live/E2E Docker release-path coverage,
 Package Acceptance з Telegram package QA, QA Lab parity, live Matrix і
-live Telegram. Повний запуск є прийнятним лише тоді, коли summary `Full Release Validation`
-показує `normal_ci` і `release_checks` як успішні, а будь-який optional
-`npm_telegram` child є або успішним, або навмисно пропущеним. Фінальний
-verifier summary містить таблиці slowest-job для кожного child run, щоб release
+live Telegram. Повний запуск прийнятний лише тоді, коли summary `Full Release Validation`
+показує `normal_ci` і `release_checks` як successful, а будь-який опційний
+дочірній `npm_telegram` є або successful, або навмисно skipped. Фінальний
+verifier summary містить таблиці slowest-job для кожного дочірнього запуску, щоб release
 manager міг бачити поточний critical path без завантаження logs.
-Child workflows запускаються з довіреного ref, який виконує `Full Release
+Див. [Повну валідацію релізу](/uk/reference/full-release-validation) для
+повної matrix stage, точних назв job workflow, відмінностей stable і full profile,
+артефактів і handles для сфокусованого повторного запуску.
+Дочірні workflow запускаються з довіреного ref, який запускає `Full Release
 Validation`, зазвичай `--ref main`, навіть коли target `ref` вказує на
-старішу release branch або tag. Окремого workflow-ref input для Full Release Validation
-немає; вибирайте довірений harness через вибір workflow run ref.
+старішу релізну гілку або тег. Немає окремого input workflow-ref для Full Release Validation;
+вибирайте довірений harness, вибираючи ref запуску workflow.
 
-Використовуйте `release_profile`, щоб вибрати ширину live/provider:
+Використовуйте `release_profile`, щоб вибрати широту live/provider:
 
 - `minimum`: найшвидший release-critical OpenAI/core live і Docker path
-- `stable`: minimum плюс stable provider/backend coverage для release approval
-- `full`: stable плюс широкий advisory provider/media coverage
+- `stable`: minimum плюс стабільне покриття provider/backend для схвалення релізу
+- `full`: stable плюс широке покриття advisory provider/media
 
-`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз розв’язати target
-ref як `release-package-under-test`, і повторно використовує цей artifact як у
-release-path Docker checks, так і в Package Acceptance. Це тримає всі
-package-facing boxes на тих самих bytes і уникає повторних package builds.
+`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз резолвити target
+ref як `release-package-under-test`, і повторно використовує цей артефакт як у
+release-path Docker checks, так і в Package Acceptance. Це утримує всі
+package-facing бокси на тих самих байтах і уникає повторних build пакета.
 Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли
-repo/org variable задано, інакше `openai/gpt-5.4-mini`, бо ця lane
-підтверджує package install, onboarding, запуск Gateway і один live agent turn,
+задано repo/org variable, інакше `openai/gpt-5.4-mini`, бо ця lane
+підтверджує install пакета, onboarding, запуск Gateway і один live agent turn,
 а не benchmark найповільнішої default model. Ширша live provider
 matrix залишається місцем для model-specific coverage.
 
@@ -311,40 +314,40 @@ gh workflow run full-release-validation.yml \
   -f npm_telegram_provider_mode=mock-openai
 ```
 
-Не використовуйте повну парасольку як перший повторний запуск після цільового виправлення. Якщо один блок
-завершується невдало, використайте невдалий дочірній workflow, job, Docker-лінію, профіль пакета, модельного
-провайдера або QA-лінію для наступного підтвердження. Запускайте повну парасольку знову лише тоді, коли
-виправлення змінило спільну оркестрацію релізу або зробило попередні докази з усіх блоків
-застарілими. Фінальний верифікатор парасольки повторно перевіряє записані run
-ids дочірніх workflow, тож після успішного повторного запуску дочірнього workflow повторно запустіть лише невдалий
+Не використовуйте повний umbrella-процес як перший повторний запуск після сфокусованого виправлення. Якщо один блок
+не проходить, використовуйте невдалий дочірній workflow, job, Docker-лану, профіль package, model
+provider або QA-лану для наступного доказу. Запускайте повний umbrella-процес знову лише тоді, коли
+виправлення змінило спільну оркестрацію релізу або зробило попередні докази для всіх блоків
+застарілими. Фінальний верифікатор umbrella-процесу повторно перевіряє записані ідентифікатори запусків дочірніх workflow,
+тому після успішного повторного запуску дочірнього workflow повторно запускайте лише невдалий
 батьківський job `Verify full validation`.
 
-Для обмеженого відновлення передайте `rerun_group` у парасольку. `all` — це справжній
-запуск release candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease`
-запускає лише релізний дочірній Plugin, `release-checks` запускає кожен релізний
+Для обмеженого відновлення передайте `rerun_group` до umbrella-процесу. `all` є справжнім
+запуском release candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease`
+запускає лише дочірній процес plugin тільки для релізу, `release-checks` запускає кожен релізний
 блок, а вужчі релізні групи — це `install-smoke`, `cross-os`,
 `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`, коли
-надано окрему пакетну Telegram-лінію.
+надано окрему package Telegram-лану.
 
 ### Vitest
 
 Блок Vitest — це ручний дочірній workflow `CI`. Ручний CI навмисно
-оминає scoped перевірку змін і примусово запускає звичайний граф тестів для release
-candidate: Linux Node shards, bundled-plugin shards, channel contracts, Node 22
-compatibility, `check`, `check-additional`, build smoke, docs checks, Python
+обходить changed scoping і примусово запускає звичайний граф тестів для release
+candidate: шарди Linux Node, шарди bundled-plugin, контракти каналів, сумісність Node 22,
+`check`, `check-additional`, build smoke, перевірки документації, Python
 skills, Windows, macOS, Android і Control UI i18n.
 
-Використовуйте цей блок, щоб відповісти: «чи пройшло дерево джерельного коду повний звичайний набір тестів?»
-Це не те саме, що валідація продукту на релізному шляху. Докази, які слід зберегти:
+Використовуйте цей блок, щоб відповісти на запитання: «чи пройшло дерево вихідного коду повний звичайний набір тестів?»
+Це не те саме, що продуктова валідація release path. Докази, які слід зберегти:
 
-- зведення `Full Release Validation`, що показує URL запущеного `CI` run
+- підсумок `Full Release Validation`, що показує URL запущеного `CI` run
 - зелений `CI` run на точному цільовому SHA
-- назви невдалих або повільних shard із CI jobs під час розслідування регресій
-- артефакти часу виконання Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли
-  run потребує аналізу продуктивності
+- назви невдалих або повільних шардів із CI jobs під час дослідження регресій
+- артефакти таймінгів Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли
+  запуск потребує аналізу продуктивності
 
-Запускайте ручний CI напряму лише тоді, коли реліз потребує детермінованого звичайного CI, але
-не блоків Docker, QA Lab, live, cross-OS або package:
+Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований звичайний CI, але
+не потрібні Docker, QA Lab, live, cross-OS або package-блоки:
 
 ```bash
 gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
@@ -353,18 +356,18 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
 ### Docker
 
 Блок Docker живе в `OpenClaw Release Checks` через
-`openclaw-live-and-e2e-checks-reusable.yml`, а також у релізному режимі
+`openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode
 workflow `install-smoke`. Він валідує release candidate через упаковані
-Docker-середовища, а не лише тести на рівні джерельного коду.
+Docker-середовища, а не лише тести на рівні вихідного коду.
 
-Релізне Docker-покриття включає:
+Релізне покриття Docker включає:
 
 - повний install smoke з увімкненим повільним Bun global install smoke
 - підготовку/повторне використання root Dockerfile smoke image за цільовим SHA, з QR,
-  root/gateway та installer/Bun smoke jobs, що виконуються як окремі install-smoke
-  shards
-- repository E2E lanes
-- релізні Docker chunks: `core`, `package-update-openai`,
+  root/gateway і installer/Bun smoke jobs, що запускаються як окремі install-smoke
+  шарди
+- repository E2E-лани
+- release-path 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-b`,
@@ -374,82 +377,84 @@ Docker-середовища, а не лише тести на рівні дже
   `bundled-channels-core`, `bundled-channels-update-a`,
   `bundled-channels-update-discord`, `bundled-channels-update-b` і
   `bundled-channels-contracts`
-- покриття OpenWebUI всередині chunk `plugins-runtime-services` за запитом
-- розділені bundled-channel dependency lanes між channel-smoke, update-target
+- покриття OpenWebUI всередині chunk `plugins-runtime-services`, коли його запитано
+- розділені лани залежностей bundled-channel між channel-smoke, update-target
   і setup/runtime contract chunks замість одного великого bundled-channel job
-- розділені bundled plugin install/uninstall lanes
-  `bundled-plugin-install-uninstall-0` через
+- розділені лани встановлення/видалення bundled plugin
+  від `bundled-plugin-install-uninstall-0` до
   `bundled-plugin-install-uninstall-23`
 - live/E2E provider suites і Docker live model coverage, коли release checks
   включають live suites
 
-Використовуйте Docker-артефакти перед повторним запуском. Релізний планувальник завантажує
-`.artifacts/docker-tests/` із lane logs, `summary.json`, `failures.json`,
-phase timings, scheduler plan JSON і командами повторного запуску. Для цільового відновлення
+Використовуйте Docker-артефакти перед повторним запуском. Release-path scheduler завантажує
+`.artifacts/docker-tests/` з логами лан, `summary.json`, `failures.json`,
+таймінгами фаз, JSON плану scheduler і командами повторного запуску. Для сфокусованого відновлення
 використовуйте `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow замість
-повторного запуску всіх релізних chunks. Згенеровані команди повторного запуску включають попередні
-`package_artifact_run_id` і підготовлені Docker image inputs, коли вони доступні, тож
-невдала lane може повторно використати той самий tarball і GHCR images.
+повторного запуску всіх release chunks. Згенеровані команди повторного запуску включають попередні
+`package_artifact_run_id` і підготовлені Docker image inputs, коли доступно, тому
+невдала лана може повторно використати той самий tarball і GHCR images.
 
 ### QA Lab
 
 Блок QA Lab також є частиною `OpenClaw Release Checks`. Це агентний
-поведінковий і канальний релізний gate, окремий від механіки пакетів Vitest і Docker.
+поведінковий і channel-level релізний gate, окремий від Vitest і Docker
+package mechanics.
 
 Релізне покриття QA Lab включає:
 
-- mock parity gate, що порівнює кандидатну OpenAI lane з baseline Opus 4.6
+- mock parity gate, що порівнює OpenAI candidate lane з baseline Opus 4.6
   за допомогою agentic parity pack
-- швидкий live Matrix QA profile із використанням середовища `qa-live-shared`
-- live Telegram QA lane із Convex CI credential leases
-- `pnpm qa:otel:smoke`, коли release telemetry потребує явного локального підтвердження
+- швидкий live Matrix QA profile з використанням середовища `qa-live-shared`
+- live Telegram QA lane з використанням Convex CI credential leases
+- `pnpm qa:otel:smoke`, коли релізній телеметрії потрібен явний локальний доказ
 
-Використовуйте цей блок, щоб відповісти: «чи коректно поводиться реліз у QA-сценаріях і
+Використовуйте цей блок, щоб відповісти на запитання: «чи поводиться реліз правильно у QA scenarios і
 live channel flows?» Зберігайте URL артефактів для parity, Matrix і Telegram
-lanes під час затвердження релізу. Повне Matrix-покриття лишається доступним як
+лан під час затвердження релізу. Повне покриття Matrix залишається доступним як
 ручний sharded QA-Lab run, а не стандартна release-critical lane.
 
 ### Package
 
-Блок Package — це gate для installable-product. Він підтримується
+Блок Package — це gate installable-product. Його підтримують
 `Package Acceptance` і resolver
 `scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує
-кандидата в tarball `package-under-test`, який споживає Docker E2E, валідує
-package inventory, записує package version і SHA-256 та тримає
+candidate у tarball `package-under-test`, який споживає Docker E2E, валідує
+package inventory, записує версію package і SHA-256, а також тримає
 workflow harness ref окремо від package source ref.
 
-Підтримувані джерела кандидатів:
+Підтримувані джерела candidate:
 
-- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна версія релізу OpenClaw
-- `source=ref`: пакує довірену гілку `package_ref`, tag або повний commit SHA
-  з вибраним harness `workflow_ref`
-- `source=url`: завантажує HTTPS `.tgz` з обов’язковим `package_sha256`
-- `source=artifact`: повторно використовує `.tgz`, завантажений іншим GitHub Actions run
+- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна release
+  version OpenClaw
+- `source=ref`: запакувати довірену `package_ref` branch, tag або повний commit SHA
+  з вибраним `workflow_ref` harness
+- `source=url`: завантажити HTTPS `.tgz` з обов'язковим `package_sha256`
+- `source=artifact`: повторно використати `.tgz`, завантажений іншим GitHub Actions run
 
-`OpenClaw Release Checks` запускає Package Acceptance із `source=ref`,
+`OpenClaw Release Checks` запускає Package Acceptance з `source=ref`,
 `package_ref=<release-ref>`, `suite_profile=custom`,
 `docker_lanes=bundled-channel-deps-compat plugins-offline` і
-`telegram_mode=mock-openai`. Релізні Docker chunks покривають
-перетинні install, update і plugin-update lanes; Package Acceptance зберігає
+`telegram_mode=mock-openai`. Release-path Docker chunks покривають
+перекривні лани install, update і plugin-update; Package Acceptance зберігає
 artifact-native bundled-channel compat, offline plugin fixtures і Telegram
-package QA проти того самого resolved tarball. Це GitHub-native
-заміна більшості package/update coverage, що раніше вимагала
+package QA для того самого resolved tarball. Це GitHub-native
+заміна більшості покриття package/update, яке раніше потребувало
 Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding,
-installer і platform behavior, але product validation для package/update має
+installer і platform behavior, але package/update product validation має
 надавати перевагу Package Acceptance.
 
-Legacy package-acceptance leniency навмисно обмежена в часі. Пакети до
+Поблажливість legacy package-acceptance навмисно обмежена в часі. Packages до
 `2026.4.25` включно можуть використовувати compatibility path для metadata gaps, уже опублікованих
 у npm: private QA inventory entries, відсутні в tarball, відсутній
 `gateway install --wrapper`, відсутні patch files у tarball-derived git
-fixture, відсутній persisted `update.channel`, legacy plugin install-record
-locations, відсутня marketplace install-record persistence і config metadata
-migration під час `plugins update`. Опублікований пакет `2026.4.26` може попереджати
-про local build metadata stamp files, які вже були випущені. Пізніші пакети
-мають відповідати сучасним package contracts; ті самі прогалини провалюють release
+fixture, відсутній збережений `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
+мають задовольняти сучасні package contracts; ті самі gaps провалюють release
 validation.
 
-Використовуйте ширші профілі Package Acceptance, коли релізне питання стосується
+Використовуйте ширші Package Acceptance profiles, коли release question стосується
 фактичного installable package:
 
 ```bash
@@ -461,87 +466,83 @@ gh workflow run package-acceptance.yml \
   -f suite_profile=product
 ```
 
-Поширені профілі package:
+Поширені package profiles:
 
 - `smoke`: швидкі package install/channel/agent, gateway network і config
   reload lanes
-- `package`: install/update/plugin package contracts без live ClawHub; це стандарт
-  release-check
+- `package`: install/update/plugin package contracts без live ClawHub; це стандарт release-check
 - `product`: `package` плюс MCP channels, cron/subagent cleanup, OpenAI web
   search і OpenWebUI
 - `full`: Docker release-path chunks з OpenWebUI
-- `custom`: точний список `docker_lanes` для цільових повторних запусків
+- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків
 
-Для Telegram-підтвердження package-candidate увімкніть `telegram_mode=mock-openai` або
+Для package-candidate Telegram proof увімкніть `telegram_mode=mock-openai` або
 `telegram_mode=live-frontier` у Package Acceptance. Workflow передає
 resolved tarball `package-under-test` у Telegram lane; окремий
-Telegram workflow все ще приймає опублікований npm spec для post-publish checks.
+Telegram workflow усе ще приймає опубліковану npm spec для post-publish checks.
 
-## Вхідні дані workflow NPM
+## Вхідні дані NPM workflow
 
-`OpenClaw NPM Release` приймає такі operator-controlled inputs:
+`OpenClaw NPM Release` приймає такі керовані оператором input:
 
-- `tag`: обов’язковий release tag, як-от `v2026.4.2`, `v2026.4.2-1` або
+- `tag`: обов'язковий release tag, як-от `v2026.4.2`, `v2026.4.2-1` або
   `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
-  повний 40-character workflow-branch commit SHA для validation-only preflight
-- `preflight_only`: `true` для validation/build/package only, `false` для
-  реального publish path
-- `preflight_run_id`: обов’язковий у реальному publish path, щоб workflow повторно використовував
+  повний 40-символьний commit SHA workflow-branch для validation-only preflight
+- `preflight_only`: `true` для лише validation/build/package, `false` для
+  справжнього publish path
+- `preflight_run_id`: обов'язковий на справжньому publish path, щоб workflow повторно використовував
   підготовлений tarball з успішного preflight run
-- `npm_dist_tag`: цільовий npm tag для publish path; стандартно `beta`
+- `npm_dist_tag`: цільовий npm tag для publish path; за замовчуванням `beta`
 
-`OpenClaw Release Checks` приймає такі operator-controlled inputs:
+`OpenClaw Release Checks` приймає такі керовані оператором input:
 
-- `ref`: гілка, tag або повний commit SHA для валідації. Перевірки із секретами
-  вимагають, щоб resolved commit був досяжний з гілки OpenClaw або
+- `ref`: branch, tag або повний commit SHA для валідації. Secret-bearing checks
+  вимагають, щоб resolved commit був доступний з branch OpenClaw або
   release tag.
 
 Правила:
 
 - Stable і correction tags можуть публікуватися або в `beta`, або в `latest`
 - Beta prerelease tags можуть публікуватися лише в `beta`
-- Для `OpenClaw NPM Release` введення full commit SHA дозволене лише коли
+- Для `OpenClaw NPM Release` input повного commit SHA дозволено лише коли
   `preflight_only=true`
-- `OpenClaw Release Checks` і `Full Release Validation` завжди
+- `OpenClaw Release Checks` і `Full Release Validation` завжди є
   validation-only
-- Реальний publish path має використовувати той самий `npm_dist_tag`, що й під час preflight;
-  workflow перевіряє, що metadata перед publish далі відповідає цьому
+- Справжній publish path має використовувати той самий `npm_dist_tag`, який використовувався під час preflight;
+  workflow перевіряє ці metadata перед продовженням publish
 
 ## Послідовність stable npm release
 
 Під час підготовки stable npm release:
 
 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
-   - До появи tag можна використати поточний повний workflow-branch commit
+   - До існування tag можна використати поточний повний workflow-branch commit
      SHA для validation-only dry run preflight workflow
 2. Виберіть `npm_dist_tag=beta` для звичайного beta-first flow або `latest` лише
-   коли навмисно хочете прямий stable publish
+   тоді, коли ви навмисно хочете direct stable publish
 3. Запустіть `Full Release Validation` на release branch, release tag або повному
-   commit SHA, коли потрібні normal CI плюс live prompt cache, Docker, QA Lab,
-   Matrix і Telegram coverage з одного manual workflow
-4. Якщо навмисно потрібен лише deterministic normal test graph, запустіть
-   manual `CI` workflow на release ref натомість
+   commit SHA, коли потрібні звичайний CI плюс live prompt cache, Docker, QA Lab,
+   Matrix і Telegram coverage з одного ручного workflow
+4. Якщо вам навмисно потрібен лише детермінований звичайний test graph, натомість запустіть
+   ручний workflow `CI` на release ref
 5. Збережіть успішний `preflight_run_id`
 6. Запустіть `OpenClaw NPM Release` знову з `preflight_only=false`, тим самим
    `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id`
 7. Якщо реліз потрапив у `beta`, використайте приватний
-   `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
-   workflow, щоб просунути цю stable version з `beta` до `latest`
+   workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
+   для promotion цієї stable version з `beta` до `latest`
 8. Якщо реліз навмисно опубліковано напряму в `latest`, а `beta`
-   має негайно слідувати за тією самою stable build, використайте той самий приватний
-   workflow, щоб спрямувати обидва dist-tags на stable version, або дозвольте його запланованій
+   має негайно перейти на той самий stable build, використайте той самий приватний
+   workflow, щоб спрямувати обидва dist-tags на stable version, або дозвольте його scheduled
    self-healing sync перемістити `beta` пізніше
 
-Мутація dist-tag живе у приватному репозиторії з міркувань безпеки, бо вона все ще
-потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає OIDC-only publish.
+Мутація dist-tag живе в приватному repo з міркувань безпеки, тому що вона все ще
+потребує `NPM_TOKEN`, тоді як публічний repo зберігає OIDC-only publish.
 
-Це зберігає і direct publish path, і beta-first promotion path
+Це залишає і direct publish path, і beta-first promotion path
 задокументованими та видимими для оператора.
 
-Якщо maintainer мусить вдатися до локальної автентифікації npm, запускайте будь-які команди 1Password
-CLI (`op`) лише всередині спеціального сеансу tmux. Не викликайте `op`
-безпосередньо з основної оболонки агента; утримання його всередині tmux робить запити,
-сповіщення й обробку OTP спостережуваними та запобігає повторним сповіщенням хоста.
+Якщо супровіднику доводиться повертатися до локальної автентифікації npm, запускайте будь-які команди 1Password CLI (`op`) лише всередині окремої сесії tmux. Не викликайте `op` безпосередньо з основної оболонки агента; утримання його всередині tmux робить запити, сповіщення й обробку OTP видимими та запобігає повторним сповіщенням хоста.
 
 ## Публічні посилання
 
@@ -555,9 +556,9 @@ CLI (`op`) лише всередині спеціального сеансу tmu
 - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
 - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)
 
-Maintainers використовують приватну документацію щодо випусків у
+Супровідники використовують приватну документацію щодо випусків у
 [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
-для фактичного регламенту виконання.
+як фактичний runbook.
 
 ## Пов’язане
 

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

@@ -0,0 +1,170 @@
+---
+read_when:
+    - Запуск або повторний запуск повної перевірки релізу
+    - Порівняння стабільного та повного профілів перевірки релізу
+    - Налагодження збоїв на етапі перевірки релізу
+summary: Етапи повної перевірки релізу, дочірні робочі процеси, профілі релізу, дескриптори повторного запуску та докази
+title: Повна перевірка релізу
+x-i18n:
+    generated_at: "2026-05-01T02:24:35Z"
+    model: gpt-5.5
+    provider: openai
+    source_hash: ef87c4b54ed8e4834d5417f8be80b99e7d9c9476caefe0581b0864b07bcc4e1a
+    source_path: reference/full-release-validation.md
+    workflow: 16
+---
+
+`Full Release Validation` — це парасолька релізу. Це єдина ручна
+точка входу для передрелізного підтвердження, але більшість роботи відбувається в дочірніх workflow, щоб
+невдалий бокс можна було запустити повторно без перезапуску всього релізу.
+
+Запускайте її з довіреного посилання workflow, зазвичай `main`, і передайте релізну гілку,
+тег або повний SHA коміту як `ref`:
+
+```bash
+gh workflow run full-release-validation.yml \
+  --ref main \
+  -f ref=release/YYYY.M.D \
+  -f provider=openai \
+  -f mode=both \
+  -f release_profile=stable
+```
+
+Дочірні workflow використовують довірене посилання workflow для harness і вхідний
+`ref` для кандидата, що тестується. Це зберігає доступність нової логіки валідації
+під час перевірки старішої релізної гілки або тегу.
+
+## Верхньорівневі етапи
+
+| Етап                  | Назва job у workflow                      | Дочірній workflow         | Що підтверджує                                                                                                                                                                                                                                                                  | Handle для повторного запуску                                  |
+| --------------------- | ----------------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------- |
+| Визначення target     | `Resolve target ref`                      | немає                     | Визначає релізну гілку, тег або повний SHA коміту та записує вибрані вхідні дані.                                                                                                                                                                                              | Повторно запустіть парасольку, якщо це не вдасться.             |
+| Vitest і звичайний CI | `Run normal full CI`                      | `CI`                      | Ручний повний граф CI проти target ref, включно з Linux Node lanes, shards bundled plugin, контрактами каналів, сумісністю Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python Skills, Windows, macOS, Control UI i18n і Android через парасольку. | `rerun_group=ci`                                                |
+| Передреліз Plugin     | `Run plugin prerelease validation`        | `Plugin Prerelease`       | Статичні перевірки Plugin лише для релізу, покриття agentic plugin, повні shards batch extensions і передрелізні Docker lanes для Plugin.                                                                                                                                      | `rerun_group=plugin-prerelease`                                 |
+| Перевірки релізу      | `Run release/live/Docker/QA validation`   | `OpenClaw Release Checks` | Install smoke, cross-OS перевірки пакета, live/E2E suites, Docker release-path chunks, Package Acceptance, QA Lab parity, live Matrix і live Telegram.                                                                                                                         | `rerun_group=release-checks` або вужчий release-checks handle   |
+| Telegram після публікації | `Run post-publish Telegram E2E`       | `NPM Telegram Beta E2E`   | Необов’язкове підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.                                                                                                                                                                       | `rerun_group=npm-telegram`                                      |
+| Перевірник парасольки | `Verify full validation`                  | немає                     | Повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших job із дочірніх workflow.                                                                                                                                                                | Повторно запустіть лише цю job після доведення невдалої дочірньої до green. |
+
+Для `ref=main` і `rerun_group=all` новіша парасолька замінює старішу.
+Коли parent скасовано, його монітор скасовує будь-який дочірній workflow, який він уже
+запустив. Запуски валідації релізних гілок і тегів типово не скасовують один одного.
+
+## Етапи перевірок релізу
+
+`OpenClaw Release Checks` — найбільший дочірній workflow. Він один раз визначає target
+і готує спільний артефакт `release-package-under-test`, коли він потрібен етапам,
+орієнтованим на пакет або Docker.
+
+| Етап                | Назва job у workflow                                      | Допоміжний workflow або jobs                    | Що тестує                                                                                                                                                                                                        | Handle для повторного запуску                              |
+| ------------------- | --------------------------------------------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
+| Release target      | `Resolve target ref`                                      | немає                                           | Валідує вибраний ref, необов’язковий очікуваний SHA, профіль, rerun group і сфокусований фільтр live suite.                                                                                                      | Повторно запустіть `release-checks`.                        |
+| Артефакт пакета     | `Prepare release package artifact`                        | немає                                           | Пакує або визначає один candidate tarball і завантажує `release-package-under-test` для downstream перевірок, орієнтованих на пакет.                                                                             | Повторно запустіть відповідну групу package, cross-OS або live/E2E. |
+| Install smoke       | `Run install smoke`                                       | `Install Smoke`                                 | Повний шлях встановлення з повторним використанням root Dockerfile smoke image, QR package install, root і Gateway Docker smokes, installer Docker tests, Bun global install image-provider smoke і швидкий bundled-plugin Docker E2E. | `rerun_group=install-smoke`                                 |
+| Cross-OS            | `cross_os_release_checks`                                 | `OpenClaw Cross-OS Release Checks (Reusable)`   | Fresh і upgrade lanes на Linux, Windows і macOS для вибраного provider і mode з використанням candidate tarball плюс baseline package.                                                                           | `rerun_group=cross-os`                                      |
+| Repo і live E2E     | `Run repo/live E2E validation`                            | `OpenClaw Live And E2E Checks (Reusable)`       | Repository E2E, live cache, OpenAI websocket streaming, native live provider і plugin shards, а також live model/backend/gateway harnesses на базі Docker, вибрані через `release_profile`.                       | `rerun_group=live-e2e`, необов’язково з `live_suite_filter` |
+| Docker release path | `Run Docker release-path validation`                      | `OpenClaw Live And E2E Checks (Reusable)`       | Docker chunks release-path проти спільного артефакта пакета.                                                                                                                                                     | `rerun_group=live-e2e`                                      |
+| Package Acceptance  | `Run package acceptance`                                  | `Package Acceptance`                            | Сумісність залежностей bundled-channel у нативному для артефакта режимі, offline plugin package fixtures і mock-OpenAI Telegram package acceptance проти того самого tarball.                                    | `rerun_group=package`                                       |
+| QA parity           | `Run QA Lab parity lane` і `Run QA Lab parity report`     | прямі jobs                                      | Candidate і baseline agentic parity packs, потім parity report.                                                                                                                                                  | `rerun_group=qa-parity` або `rerun_group=qa`                |
+| QA live Matrix      | `Run QA Lab live Matrix lane`                             | пряма job                                       | Швидкий профіль live Matrix QA в середовищі `qa-live-shared`.                                                                                                                                                    | `rerun_group=qa-live` або `rerun_group=qa`                  |
+| QA live Telegram    | `Run QA Lab live Telegram lane`                           | пряма job                                       | Live Telegram QA з leases облікових даних Convex CI.                                                                                                                                                             | `rerun_group=qa-live` або `rerun_group=qa`                  |
+| Перевірник релізу   | `Verify release checks`                                   | немає                                           | Перевіряє обов’язкові release-check jobs для вибраної rerun group.                                                                                                                                               | Повторно запустіть після успішного проходження сфокусованих дочірніх jobs. |
+
+## Docker release-path chunks
+
+Етап Docker release-path запускає ці chunks, коли `live_suite_filter`
+порожній:
+
+| Фрагмент                                                                                   | Покриття                                                                     |
+| ------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
+| `core`                                                                                     | Димові лінії основного Docker release-path.                                  |
+| `package-update-openai`                                                                    | Поведінка встановлення та оновлення пакета OpenAI.                           |
+| `package-update-anthropic`                                                                 | Поведінка встановлення та оновлення пакета Anthropic.                        |
+| `package-update-core`                                                                      | Нейтральна до провайдера поведінка пакета й оновлення.                       |
+| `plugins-runtime-plugins`                                                                  | Лінії середовища виконання Plugin, які перевіряють поведінку Plugin.         |
+| `plugins-runtime-services`                                                                 | Лінії середовища виконання Plugin із сервісною підтримкою; включає OpenWebUI за запитом. |
+| `plugins-runtime-install-a` through `plugins-runtime-install-h`                            | Пакети встановлення/виконання Plugin, розділені для паралельної перевірки релізу. |
+| `bundled-channels-core`                                                                    | Поведінка вбудованих каналів Docker.                                         |
+| `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` | Поведінка оновлення вбудованих каналів.                                      |
+| `bundled-channels-contracts`                                                               | Перевірки контрактів вбудованих каналів у Docker release path.               |
+
+Використовуйте цільовий `docker_lanes=<lane[,lane]>` у повторно використовуваному workflow live/E2E, коли
+збій стався лише в одній лінії Docker. Артефакти релізу містять команди повторного запуску
+для кожної лінії з вхідними даними повторного використання артефакта пакета та образу, коли вони доступні.
+
+## Профілі релізу
+
+`release_profile` керує лише широтою live/provider у перевірках релізу. Він
+не прибирає звичайний повний CI, Plugin Prerelease, install smoke, package
+acceptance, QA Lab або фрагменти Docker release-path.
+
+| Профіль  | Призначене використання              | Увімкнене покриття live/provider                                                                                                                                              |
+| -------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `minimum` | Найшвидший критичний для релізу smoke. | Live-шлях OpenAI/core, live-моделі Docker для OpenAI, ядро native gateway, профіль native OpenAI gateway, native OpenAI plugin і Docker live gateway OpenAI.                  |
+| `stable`  | Типовий профіль схвалення релізу.    | `minimum` плюс Anthropic, Google, MiniMax, backend, native live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і OpenCode Go smoke shard.       |
+| `full`    | Широке advisory-перевіряння.         | `stable` плюс advisory-провайдери, plugin live shards і media live shards.                                                                                                    |
+
+## Додатки лише для full
+
+Ці набори пропускаються у `stable` і включаються у `full`:
+
+| Область                          | Покриття лише для full                                                         |
+| -------------------------------- | ------------------------------------------------------------------------------- |
+| Docker live models               | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks.                                |
+| Docker live gateway              | Advisory shard для DeepSeek, Fireworks, OpenCode Go, OpenRouter, xAI і Z.ai.   |
+| Native gateway provider profiles | Fireworks, DeepSeek, повні шарди моделей OpenCode Go, 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-opencode-go-smoke`; `full`
+натомість використовує ширші шарди моделей OpenCode Go.
+
+## Сфокусовані повторні запуски
+
+Використовуйте `rerun_group`, щоб не повторювати не пов’язані з цим release boxes:
+
+| Ідентифікатор       | Обсяг                                             |
+| ------------------- | ------------------------------------------------- |
+| `all`               | Усі етапи Full Release Validation.                |
+| `ci`                | Лише дочірній ручний full CI.                     |
+| `plugin-prerelease` | Лише дочірній Plugin Prerelease.                  |
+| `release-checks`    | Усі етапи OpenClaw Release Checks.                |
+| `install-smoke`     | Install Smoke через release checks.               |
+| `cross-os`          | Перевірки релізу Cross-OS.                        |
+| `live-e2e`          | Repo/live E2E і перевірка Docker release-path.    |
+| `package`           | Package Acceptance.                               |
+| `qa`                | QA parity плюс QA live lanes.                     |
+| `qa-parity`         | Лише QA parity lanes і звіт.                      |
+| `qa-live`           | Лише QA live Matrix і Telegram.                   |
+| `npm-telegram`      | Лише необов’язковий Telegram E2E після публікації. |
+
+Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли одна live suite завершилася збоєм.
+Чинні ідентифікатори фільтрів визначені в повторно використовуваному 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`.
+
+## Докази, які слід зберігати
+
+Зберігайте зведення `Full Release Validation` як індекс рівня релізу. Воно посилається
+на ідентифікатори дочірніх запусків і містить таблиці найповільніших jobs. У разі збоїв спочатку перевірте дочірній
+workflow, а потім повторно запустіть найменший відповідний ідентифікатор вище.
+
+Корисні артефакти:
+
+- `release-package-under-test` з `OpenClaw Release Checks`
+- Артефакти Docker release-path у `.artifacts/docker-tests/`
+- `package-under-test` з Package Acceptance і артефакти Docker acceptance
+- Артефакти Cross-OS release-check для кожної OS і suite
+- Артефакти QA parity, Matrix і Telegram
+
+## Файли workflow
+
+- `.github/workflows/full-release-validation.yml`
+- `.github/workflows/openclaw-release-checks.yml`
+- `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml`
+- `.github/workflows/plugin-prerelease.yml`
+- `.github/workflows/install-smoke.yml`
+- `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
+- `.github/workflows/package-acceptance.yml`