chore(i18n): refresh uk translations

docs/uk/ci.md

@@ -1,93 +1,93 @@
 ---
 read_when:
-    - Потрібно з’ясувати, чому завдання CI запустилося або не запустилося
-    - Ви налагоджуєте перевірку GitHub Actions, яка не проходить
-    - Ви координуєте запуск або повторний запуск валідації релізу
+    - Потрібно зрозуміти, чому завдання CI запустилося або не запустилося
+    - Ви налагоджуєте невдалу перевірку GitHub Actions
+    - Ви координуєте запуск або повторний запуск перевірки релізу
     - Ви змінюєте диспетчеризацію ClawSweeper або пересилання активності GitHub
-summary: Граф завдань CI, контрольні перевірки за областю, парасолькові релізні процеси та локальні еквіваленти команд
-title: Конвеєр CI
+summary: Граф завдань CI, гейти за областю дії, парасолькові релізні перевірки та локальні еквіваленти команд
+title: CI-конвеєр
 x-i18n:
-    generated_at: "2026-05-02T04:47:35Z"
+    generated_at: "2026-05-02T06:28:34Z"
     model: gpt-5.5
     provider: openai
-    source_hash: a2da3014e67b8d2d4bb4c1c9d4c6134eed29309bb176544864df568809ae3ac7
+    source_hash: 03258176c6672355abf335bfcb2a962c0ddc62605aaeaba1f60f513d03bce2d4
     source_path: ci.md
     workflow: 16
 ---
 
-OpenClaw CI виконується під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі lanes, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області та розгортають повний граф для реліз-кандидатів і широкої валідації. Android lanes залишаються опціональними через `include_android`. Покриття plugin лише для релізів живе в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається тільки з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch.
+OpenClaw CI запускається для кожного push у `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі lane, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне scoped-обмеження й розгортають повний граф для release candidate та широкої валідації. Android lane залишаються opt-in через `include_android`. Release-only покриття plugin міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch.
 
 ## Огляд pipeline
 
-| Завдання                         | Призначення                                                                                  | Коли запускається                 |
-| -------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------- |
-| `preflight`                      | Виявляє зміни лише в документації, змінені області, змінені extensions і будує CI manifest   | Завжди для non-draft push і PR    |
-| `security-scm-fast`              | Виявлення приватних ключів і аудит workflow через `zizmor`                                   | Завжди для non-draft push і PR    |
-| `security-dependency-audit`      | Аудит production lockfile без залежностей щодо npm advisories                                | Завжди для non-draft push і PR    |
-| `security-fast`                  | Обов’язковий aggregate для швидких security-завдань                                          | Завжди для non-draft push і PR    |
-| `check-dependencies`             | Production Knip dependency-only pass і guard allowlist невикористаних файлів                 | Зміни, релевантні до Node         |
-| `build-artifacts`                | Збирання `dist/`, Control UI, перевірки built-artifact і повторно використовувані downstream artifacts | Зміни, релевантні до Node         |
-| `checks-fast-core`               | Швидкі Linux 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 еквівалент основного локального 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                                                     | Ручний CI dispatch для релізів    |
-| `check-docs`                     | Форматування документації, lint і перевірки broken-link                                      | Змінено документацію              |
-| `skills-python`                  | Ruff + pytest для Skills на Python                                                           | Зміни, релевантні до Python-skill |
-| `checks-windows`                 | Windows-specific process/path tests і shared runtime import specifier regressions            | Зміни, релевантні до Windows      |
-| `macos-node`                     | macOS TypeScript test lane з використанням shared built artifacts                            | Зміни, релевантні до macOS        |
-| `macos-swift`                    | Swift lint, build і tests для macOS app                                                      | Зміни, релевантні до macOS        |
-| `android`                        | Android unit tests для обох flavors і одне debug APK build                                   | Зміни, релевантні до Android      |
-| `test-performance-agent`         | Щоденна оптимізація повільних тестів Codex після довіреної активності                        | Успіх main CI або manual dispatch |
+| Завдання                         | Призначення                                                                                  | Коли запускається                  |
+| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- |
+| `preflight`                      | Виявляє docs-only зміни, змінені scopes, змінені extensions і будує CI manifest              | Завжди для non-draft push і PR     |
+| `security-scm-fast`              | Виявлення приватних ключів і audit workflow через `zizmor`                                   | Завжди для non-draft push і PR     |
+| `security-dependency-audit`      | Audit production lockfile без залежностей щодо npm advisories                                | Завжди для non-draft push і PR     |
+| `security-fast`                  | Обов’язковий aggregate для швидких security jobs                                             | Завжди для non-draft push і PR     |
+| `check-dependencies`             | Production Knip dependency-only pass плюс guard allowlist для unused-file                    | Node-релевантні зміни              |
+| `build-artifacts`                | Build `dist/`, Control UI, built-artifact checks і повторно використовувані 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 еквівалент основного 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                                                     | Ручний CI dispatch для релізів     |
+| `check-docs`                     | Форматування docs, lint і перевірки broken-link                                              | Docs змінено                       |
+| `skills-python`                  | Ruff + pytest для Python-backed skills                                                       | Зміни, релевантні Python-skill     |
+| `checks-windows`                 | Windows-specific process/path tests плюс shared runtime import specifier regressions         | Windows-релевантні зміни           |
+| `macos-node`                     | 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 оптимізація повільних тестів після trusted activity                            | Успіх Main CI або ручний dispatch  |
 
 ## Порядок fail-fast
 
-1. `preflight` вирішує, які lanes взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями.
-2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи важчих artifact і platform matrix jobs.
-3. `build-artifacts` перекривається зі швидкими Linux lanes, щоб downstream consumers могли стартувати, щойно shared build готовий.
+1. `preflight` вирішує, які lane взагалі існують. Логіка `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 або `main` ref. Вважайте це CI-шумом, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже витіснено. Automatic CI concurrency key версіонований (`CI-v7-*`), тому GitHub-side zombie у старій queue group не може безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs.
+GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Сприймайте це як CI noise, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже було superseded. Automatic CI concurrency key має versioned формат (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг нескінченно блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs.
 
-## Область і маршрутизація
+## Scope і routing
 
-Логіка області живе в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби змінилася кожна scoped area.
+Логіка scope міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest діяти так, ніби кожна scoped area змінилася.
 
-- **Редагування CI workflow** валідують Node CI graph і workflow linting, але самі по собі не примушують Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source.
-- **CI routing-only edits, вибрані cheap core-test fixture edits і вузькі plugin contract helper/test-routing edits** використовують fast Node-only manifest path: `preflight`, security і одну задачу `checks-fast-core`. Цей path пропускає build artifacts, Node 22 compatibility, channel contracts, full core shards, bundled-plugin shards і additional guard matrices, коли зміна обмежена routing або helper surfaces, які fast task вправляє напряму.
-- **Windows Node checks** scoped до Windows-specific process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, що виконують цю lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes.
+- **CI workflow edits** валідують Node CI graph плюс workflow linting, але самі собою не примушують Windows, Android або macOS native builds; ці platform lanes залишаються scoped до platform source changes.
+- **CI routing-only edits, selected cheap core-test fixture edits і narrow plugin contract helper/test-routing edits** використовують fast 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; unrelated source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes.
 
-Найповільніші сімейства Node tests розділені або збалансовані, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, small core unit lanes об’єднані в пари, auto-reply запускається як чотири balanced workers (із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Broad browser, QA, media і miscellaneous plugin tests використовують власні dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries з використанням CI shard name, тому `.artifacts/vitest-shard-timings.json` може відрізнити whole config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі independent guards конкурентно всередині одного job. Gateway watch, channel tests і core support-boundary shard запускаються конкурентно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані.
+Найповільніші сімейства Node test розділено або збалансовано так, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts працюють як три weighted shards, small core unit lanes об’єднані в пари, auto-reply працює як чотири balanced workers (із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/plugin configs розподілено між наявними source-only agentic Node jobs замість очікування built artifacts. Broad browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries із назвою CI shard, тому `.artifacts/vitest-shard-timings.json` може відрізнити whole config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої 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 з BuildConfig flags для SMS/call-log, уникаючи duplicate debug APK packaging job на кожному Android-релевантному push.
 
-Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, закріплений на останній версії Knip, з вимкненим pnpm minimum release age для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings від Knip із `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий непереглянутий unused file або залишає застарілий allowlist entry, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично розв’язати.
+Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, pinned до latest Knip version, із вимкненим pnpm minimum release age для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings від Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий unreviewed unused file або залишає stale allowlist entry, зберігаючи intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично resolve.
 
-## Пересилання активності ClawSweeper
+## ClawSweeper activity forwarding
 
-`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge від активності репозиторію OpenClaw до ClawSweeper. Він не checkout і не виконує недовірений код pull request. Workflow створює GitHub App token з `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім dispatch компактні `repository_dispatch` payloads до `openclaw/clawsweeper`.
+`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge від активності репозиторію OpenClaw до ClawSweeper. Він не check out і не виконує untrusted pull request code. Workflow створює GitHub App token із `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім dispatches компактні `repository_dispatch` payloads до `openclaw/clawsweeper`.
 
 Workflow має чотири lanes:
 
-- `clawsweeper_item` для точних запитів review issue і pull request;
-- `clawsweeper_comment` для явних команд ClawSweeper у коментарях issue;
-- `clawsweeper_commit_review` для запитів commit-level review на push до `main`;
-- `github_activity` для загальної активності GitHub, яку агент ClawSweeper може inspect.
+- `clawsweeper_item` для точних issue і pull request review requests;
+- `clawsweeper_comment` для явних ClawSweeper commands у issue comments;
+- `clawsweeper_commit_review` для commit-level review requests на push у `main`;
+- `github_activity` для загальної GitHub activity, яку ClawSweeper agent може inspect.
 
-Lane `github_activity` пересилає лише normalized metadata: event type, action, actor, repository, item number, URL, title, state і short excerpts для comments або reviews, коли вони є. Він навмисно уникає пересилання повного webhook body. Receiving workflow у `openclaw/clawsweeper` — `.github/workflows/github-activity.yml`, який публікує normalized event до OpenClaw Gateway hook для агента ClawSweeper.
+Lane `github_activity` пересилає лише normalized metadata: event type, action, actor, repository, item number, URL, title, state і short excerpts для comments або reviews, коли вони наявні. Вона навмисно уникає пересилання повного webhook body. Receiving workflow у `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який posts normalized event до OpenClaw Gateway hook для ClawSweeper agent.
 
-Загальна активність — це observation, а не delivery-by-default. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` тільки тоді, коли подія є несподіваною, actionable, risky або operationally useful. Routine opens, edits, bot churn, duplicate webhook noise і normal review traffic мають приводити до `NO_REPLY`.
+General activity — це observation, а не delivery-by-default. ClawSweeper agent отримує Discord target у своєму prompt і має post до `#clawsweeper` лише тоді, коли event є surprising, actionable, risky або operationally useful. Routine opens, edits, bot churn, duplicate webhook noise і normal review traffic мають призводити до `NO_REPLY`.
 
-Ставтеся до GitHub titles, comments, bodies, review text, branch names і commit messages як до недовірених даних у всьому цьому path. Це input для summarization і triage, а не instructions для workflow або agent runtime.
+Сприймайте GitHub titles, comments, bodies, review text, branch names і commit messages як untrusted data на всьому цьому path. Вони є input для summarization і triage, а не інструкціями для workflow або agent runtime.
 
-## Manual dispatches
+## Ручні dispatches
 
-Manual CI dispatches запускають той самий job graph, що й normal 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`; full 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` dispatch окремий workflow `Plugin Prerelease` з увімкненим release-validation gate.
+Manual CI dispatches запускають той самий job graph, що й normal 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`; full 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.
 
-Manual runs використовують унікальну concurrency group, щоб release-candidate full suite не було скасовано іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає довіреному caller змогу запустити цей graph проти branch, tag або full commit SHA, використовуючи workflow file з вибраного dispatch ref.
+Manual runs використовують unique concurrency group, тому release-candidate full suite не скасовується іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає trusted caller змогу запускати цей graph проти branch, tag або full commit SHA, використовуючи workflow file із selected dispatch ref.
 
 ```bash
 gh workflow run ci.yml --ref release/YYYY.M.D
@@ -97,15 +97,15 @@ gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
 
 ## Ранери
 
-| Ранер                            | Завдання                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `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 також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла раніше ставати в чергу |
-| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, легші шарди розширень, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types`                                                                                                                                                                                                                                                                                                                               |
-| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів вбудованих 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 також використовує Ubuntu, розміщений на GitHub, щоб матриця Blacksmith могла стати в чергу раніше |
+| `blacksmith-4vcpu-ubuntu-2404`   | `CodeQL Critical Quality`, легші шарди розширень, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types`                                                                                                                                                                                                                                                                                                                   |
+| `blacksmith-8vcpu-ubuntu-2404`   | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів вбудованих 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`                                                                                                                                                                                                                                                                                                                                                                                                 |
 
 ## Локальні відповідники
 
@@ -133,55 +133,62 @@ pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-per
 pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json
 ```
 
-## Повна перевірка релізу
+## Повна валідація релізу
 
-`Full Release Validation` — це ручний парасольковий workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного підтвердження Plugin/пакета/статики/Docker і запускає `OpenClaw Release Checks` для install smoke, приймання пакета, наборів Docker release-path, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram lane. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти артефакту `release-package-under-test` із release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму Telegram package lane проти опублікованого npm-пакета.
+`Full Release Validation` — це ручний парасольковий workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` із цією ціллю, запускає `Plugin Prerelease` для релізних доказів Plugin/пакетів/статичних артефактів/Docker, а також запускає `OpenClaw Release Checks` для install smoke, приймання пакетів, наборів Docker для релізного шляху, live/E2E, OpenWebUI, паритету QA Lab, Matrix і доріжок Telegram. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти артефакту `release-package-under-test` з release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму доріжку пакета Telegram проти опублікованого npm-пакета.
 
-Див. [Повну перевірку релізу](/uk/reference/full-release-validation) для
+Див. [повну валідацію релізу](/uk/reference/full-release-validation) для
 матриці етапів, точних назв завдань workflow, відмінностей профілів, артефактів і
-дескрипторів цільових повторних запусків.
+ручок для сфокусованого повторного запуску.
 
-Для підтвердження закріпленого коміту на гілці, що швидко змінюється, використовуйте помічник замість
+`OpenClaw Release Publish` — це ручний змінювальний workflow релізу. Запускайте його
+з `release/YYYY.M.D` або `main` після того, як існує тег релізу, і після того, як
+передперевірка OpenClaw npm успішно завершилася. Він перевіряє `pnpm plugins:sync:check`,
+запускає `Plugin NPM Release` для всіх публікованих пакетів Plugin, запускає
+`Plugin ClawHub Release` для того самого SHA релізу, і лише після цього запускає
+`OpenClaw NPM Release` зі збереженим `preflight_run_id`.
+
+Для доказу зафіксованого коміту на швидко змінюваній гілці використовуйте helper замість
 `gh workflow run ... --ref main -f ref=<sha>`:
 
 ```bash
 pnpm ci:full-release --sha <full-sha>
 ```
 
-Refs для dispatch workflow GitHub мають бути гілками або тегами, а не сирими SHA комітів.
-Помічник пушить тимчасову гілку `release-ci/<sha>-...` на цільовому SHA,
-запускає `Full Release Validation` із цього закріпленого ref, перевіряє, що кожен дочірній
-workflow `headSha` збігається з ціллю, і видаляє тимчасову гілку, коли
-запуск завершується. Парасольковий перевіряльник також падає, якщо будь-який дочірній workflow працював на
+Refs запуску workflow GitHub мають бути гілками або тегами, а не сирими SHA комітів. Helper
+надсилає тимчасову гілку `release-ci/<sha>-...` на цільовий SHA,
+запускає `Full Release Validation` з цього зафіксованого ref, перевіряє, що кожен дочірній
+workflow `headSha` збігається з ціллю, і видаляє тимчасову гілку, коли запуск
+завершується. Парасольковий верифікатор також завершується з помилкою, якщо будь-який дочірній workflow виконувався на
 іншому SHA.
 
-`release_profile` керує шириною live/provider, що передається в release checks. Ручні
-release workflows типово використовують `stable`; застосовуйте `full` лише коли ви
-свідомо хочете широку advisory provider/media матрицю.
+`release_profile` керує широтою live/provider, що передається в release checks. Ручні
+релізні workflow типово використовують `stable`; використовуйте `full` лише тоді, коли ви
+навмисно хочете широку дорадчу матрицю provider/media.
 
-- `minimum` зберігає найшвидші критичні для релізу OpenAI/core lane.
+- `minimum` залишає найшвидші критичні для релізу доріжки OpenAI/core.
 - `stable` додає стабільний набір provider/backend.
-- `full` запускає широку advisory provider/media матрицю.
+- `full` запускає широку дорадчу матрицю provider/media.
 
-Парасолька записує id запущених дочірніх run, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх run і додає таблиці найповільніших завдань для кожного дочірнього run. Якщо дочірній workflow перезапущено й він став зеленим, перезапустіть лише батьківське завдання verifier, щоб оновити результат парасольки та підсумок таймінгів.
+Парасолька записує id запущених дочірніх запусків, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх запусків і додає таблиці найповільніших завдань для кожного дочірнього запуску. Якщо дочірній workflow перезапустили і він став зеленим, перезапустіть лише батьківське завдання верифікатора, щоб оновити результат парасольки й підсумок часу.
 
-Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для release candidate, `ci` лише для звичайного дочірнього full CI, `plugin-prerelease` лише для дочірнього plugin prerelease, `release-checks` для кожного release child або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` або `npm-telegram` у парасольці. Це утримує повторний запуск збійного release box у межах після цільового виправлення.
+Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата релізу, `ci` лише для звичайного повного дочірнього CI, `plugin-prerelease` лише для дочірнього prerelease Plugin, `release-checks` для кожного дочірнього релізного запуску або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольці. Це тримає повторний запуск невдалого релізного бокса обмеженим після сфокусованого виправлення.
 
-`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і в live/E2E release-path Docker workflow, і в package acceptance shard. Це зберігає байти пакета узгодженими між release boxes і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
+`OpenClaw Release Checks` використовує довірений ref workflow, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і в Docker workflow live/E2E релізного шляху, і в шард приймання пакета. Це зберігає байти пакета узгодженими між релізними боксами й уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
 
 Дублікати запусків `Full Release Validation` для `ref=main` і `rerun_group=all`
-замінюють старішу парасольку. Батьківський монітор скасовує будь-який дочірній workflow, який
-він уже запустив, коли батьківський скасовано, тож новіша main validation
-не стоїть за застарілим двогодинним release-check run. Перевірки release branch/tag
-і цільові rerun groups зберігають `cancel-in-progress: false`.
+замінюють старішу парасольку. Батьківський монітор скасовує будь-який дочірній workflow, який він
+уже запустив, коли батьківський запуск скасовано, тому новіша валідація main
+не стоїть за застарілим двогодинним запуском release-check. Валідація гілки/тега релізу
+та сфокусовані групи повторного запуску зберігають `cancel-in-progress: false`.
 
 ## Live та E2E шарди
 
-Дочірній release live/E2E зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs`, а не як одне послідовне завдання:
+Дочірній release live/E2E зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання:
 
 - `native-live-src-agents`
 - `native-live-src-gateway-core`
-- provider-filtered `native-live-src-gateway-profiles` jobs
+- provider-filtered завдання `native-live-src-gateway-profiles`
 - `native-live-src-gateway-backends`
 - `native-live-test`
 - `native-live-extensions-a-k`
@@ -189,61 +196,61 @@ release workflows типово використовують `stable`; засто
 - `native-live-extensions-openai`
 - `native-live-extensions-o-z-other`
 - `native-live-extensions-xai`
-- розділені медіашарди audio/video і provider-filtered шарди music
+- розділені шарди audio/video media та provider-filtered шарди music
 
-Це зберігає те саме покриття файлів, водночас спрощуючи повторний запуск і діагностику повільних збоїв live provider. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків.
+Це зберігає те саме файлове покриття, водночас полегшуючи повторний запуск і діагностику повільних збоїв live provider. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків.
 
-Нативні live media shards працюють у `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; медіазавдання лише перевіряють бінарні файли перед налаштуванням. Тримайте Docker-backed live suites на звичайних Blacksmith runners — container jobs не підходять для запуску вкладених Docker tests.
+Нативні шарди live media запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; завдання media лише перевіряють бінарні файли перед налаштуванням. Тримайте Docker-backed live-набори на звичайних раннерах Blacksmith — container jobs є неправильним місцем для запуску вкладених Docker-тестів.
 
-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 на дубльовані збірки образів.
+Docker-підкріплені live-шарди моделей/backend використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Workflow live-релізу один раз збирає й публікує цей образ, а потім Docker live model, provider-sharded gateway, CLI backend, ACP bind і Codex harness шарди запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Docker-шарди Gateway мають явні обмеження `timeout` на рівні скриптів, нижчі за timeout job workflow, щоб завислий контейнер або шлях очищення швидко падав, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну Docker-ціль із джерельного коду, запуск релізу налаштований неправильно й марнуватиме реальний час на дубльовані збірки образів.
 
 ## Приймання пакета
 
-Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей інстальовний пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі запускають після встановлення або оновлення.
+Використовуйте `Package Acceptance`, коли питання звучить так: "чи працює цей інстальований пакет OpenClaw як продукт?" Це відрізняється від звичайного CI: звичайний CI перевіряє дерево джерельного коду, тоді як приймання пакета перевіряє один tarball через той самий Docker E2E harness, який користувачі задіюють після встановлення або оновлення.
 
-### Завдання
+### Jobs
 
-1. `resolve_package` робить checkout `workflow_ref`, визначає один кандидат пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і друкує джерело, workflow ref, package ref, версію, SHA-256 і профіль у підсумку кроку GitHub.
-2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Багаторазовий workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker lanes для цього пакета замість пакування workflow checkout. Коли профіль вибирає кілька цільових `docker_lanes`, багаторазовий workflow готує пакет і спільні образи один раз, а потім розгортає ці lanes як паралельні цільові Docker-завдання з унікальними артефактами.
-3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance визначив його; автономний Telegram dispatch усе ще може встановити опублікований npm spec.
-4. `summary` позначає workflow як невдалий, якщо визначення пакета, Docker acceptance або опційний Telegram lane завершилися невдало.
+1. `resolve_package` checkout-ить `workflow_ref`, визначає одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить source, workflow ref, package ref, version, SHA-256 і profile у GitHub step summary.
+2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker lanes проти цього пакета замість пакування workflow checkout. Коли profile вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow один раз готує пакет і спільні образи, а потім розгалужує ці lanes як паралельні цільові Docker jobs з унікальними артефактами.
+3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance визначив його; standalone Telegram dispatch усе ще може встановити опубліковану npm spec.
+4. `summary` провалює workflow, якщо визначення пакета, Docker-приймання або опційна Telegram lane завершилися невдало.
 
 ### Джерела кандидатів
 
-- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для acceptance опублікованих beta/stable.
-- `source=ref` пакує довірену гілку `package_ref`, тег або повний commit SHA. Resolver отримує гілки/теги OpenClaw, перевіряє, що вибраний commit досяжний з історії гілок репозиторію або release tag, встановлює залежності в detached worktree і пакує його через `scripts/package-openclaw-for-docker.mjs`.
-- `source=url` завантажує HTTPS `.tgz`; `package_sha256` обов’язковий.
-- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` опційний, але його слід надавати для зовнішньо поширених артефактів.
+- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих beta/stable.
+- `source=ref` пакує довірену гілку `package_ref`, тег або повний commit SHA. Resolver отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілок репозиторію або release tag, встановлює залежності у detached worktree і пакує його через `scripts/package-openclaw-for-docker.mjs`.
+- `source=url` завантажує HTTPS `.tgz`; `package_sha256` обов'язковий.
+- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` опційний, але його варто надавати для зовнішньо поширених артефактів.
 
-Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це вихідний commit, який пакується, коли `source=ref`. Це дає поточному тестовому harness змогу перевіряти старі довірені commits вихідного коду без запуску старої workflow-логіки.
+Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це коміт джерела, який пакується, коли `source=ref`. Це дозволяє поточному тестовому harness перевіряти старіші довірені коміти джерела без запуску старої workflow-логіки.
 
-### Профілі набору
+### Профілі suite
 
 - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
 - `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `published-upgrade-survivor`, `plugins-offline`, `plugin-update`
 - `product` — `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
-- `full` — повні Docker chunks шляху релізу з OpenWebUI
-- `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom`
+- `full` — повні Docker chunks релізного шляху з OpenWebUI
+- `custom` — точні `docker_lanes`; обов'язково, коли `suite_profile=custom`
 
-Профіль `package` використовує offline-покриття plugin, щоб перевірка опублікованого пакета не залежала від live-доступності ClawHub. Опційний Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованого npm spec збережено для автономних dispatches.
+Профіль `package` використовує offline-покриття plugin, щоб перевірка опублікованого пакета не залежала від live-доступності ClawHub. Опційна Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, із шляхом опублікованої npm spec, залишеним для standalone dispatches.
 
-Для спеціальної політики тестування оновлень і plugin, зокрема локальних команд,
-Docker lanes, входів Package Acceptance, release defaults і triage збоїв,
-див. [Тестування оновлень і plugin](/uk/help/testing-updates-plugins).
+Окрему політику тестування оновлень і plugin, включно з локальними командами,
+Docker lanes, входами Package Acceptance, типовими налаштуваннями релізу й triage збоїв,
+див. у [Тестування оновлень і plugin](/uk/help/testing-updates-plugins).
 
-Release checks викликають Package Acceptance з `source=artifact`, підготовленим артефактом release package, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це тримає перевірки міграції пакета, оновлення, очищення застарілих залежностей plugin, offline plugin, plugin-update і Telegram на одному визначеному package tarball. Cross-OS release checks усе ще покривають OS-специфічний onboarding, installer і поведінку платформи; product validation для package/update має починатися з Package Acceptance. Docker lane `published-upgrade-survivor` перевіряє один baseline опублікованого пакета за запуск. У Package Acceptance визначений tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback опублікований baseline, за замовчуванням `openclaw@latest`; команди повторного запуску failed-lane зберігають цей baseline. Установіть `published_upgrade_survivor_baselines=release-history`, щоб розширити lane до дедуплікованої матриці історії: останні шість stable-релізів, `2026.4.23` і останній stable-реліз перед `2026-03-15`. Установіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для конфігурації Feishu, збережених файлів bootstrap/persona, шляхів журналів із тильдою та застарілих коренів legacy-залежностей plugin. Окремий workflow `Update Migration` використовує Docker lane `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає у вичерпному очищенні опублікованого оновлення, а не у звичайній ширині Full Release CI. Локальні aggregate-запуски можуть передавати точні package specs через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, зберігати один lane через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або встановлювати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для scenario matrix. Опублікований lane налаштовує baseline за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також RPC status після старту Gateway. Windows packaged і installer fresh lanes також перевіряють, що встановлений пакет може імпортувати browser-control override із сирого абсолютного Windows path. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли його встановлено, інакше `openai/gpt-5.5`, щоб докази встановлення й gateway залишалися на бажаній тестовій моделі GPT-5.
+Release checks викликають Package Acceptance з `source=artifact`, підготовленим артефактом release package, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це тримає перевірки міграції пакета, оновлення, очищення застарілих залежностей plugin, offline plugin, plugin-update і Telegram на тому самому визначеному package tarball. Крос-OS release checks усе ще покривають OS-специфічне onboarding, installer і поведінку платформи; продуктову перевірку package/update слід починати з Package Acceptance. Docker lane `published-upgrade-survivor` перевіряє один baseline опублікованого пакета за запуск. У Package Acceptance визначений tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає резервний опублікований baseline, за замовчуванням `openclaw@latest`; команди rerun для failed-lane зберігають цей baseline. Установіть `published_upgrade_survivor_baselines=release-history`, щоб розширити lane на deduped history matrix: останні шість stable-релізів, `2026.4.23` і останній stable-реліз перед `2026-03-15`. Установіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для конфігурації Feishu, збережених bootstrap/persona файлів, tilde log paths і застарілих legacy plugin dependency roots. Окремий workflow `Update Migration` використовує Docker lane `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання стосується вичерпного очищення опублікованих оновлень, а не звичайної широти Full Release CI. Локальні aggregate runs можуть передавати точні package specs через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, залишати одну lane з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або встановлювати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для scenario matrix. Published lane налаштовує baseline через вбудований рецепт команд `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також RPC status після запуску Gateway. Windows packaged і installer fresh lanes також перевіряють, що встановлений пакет може імпортувати browser-control override із raw absolute Windows path. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли він заданий, інакше `openai/gpt-5.5`, щоб install і gateway proof залишалися на пріоритетній GPT-5 тестовій моделі.
 
-### Вікна legacy-сумісності
+### Legacy compatibility windows
 
-Package Acceptance має обмежені вікна legacy-сумісності для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати compatibility path:
+Package Acceptance має обмежені legacy-compatibility windows для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати compatibility path:
 
-- відомі private QA записи в `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball;
-- `doctor-switch` може пропускати subcase persistence `gateway install --wrapper`, коли пакет не експонує цей flag;
-- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` із fake git fixture, похідного від tarball, і може логувати відсутній persisted `update.channel`;
-- plugin smokes можуть читати legacy install-record locations або приймати відсутність marketplace install-record persistence;
-- `plugin-update` може дозволяти міграцію config metadata, водночас вимагаючи, щоб install record і поведінка no-reinstall залишалися незмінними.
+- відомі private QA entries у `dist/postinstall-inventory.json` можуть указувати на файли, пропущені в tarball;
+- `doctor-switch` може пропускати subcase persistence для `gateway install --wrapper`, коли пакет не expose-ить цей flag;
+- `update-channel-switch` може prune-ити відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і може логувати відсутній persisted `update.channel`;
+- plugin smokes можуть читати legacy install-record locations або приймати відсутню marketplace install-record persistence;
+- `plugin-update` може дозволяти міграцію config metadata, водночас усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними.
 
-Опублікований пакет `2026.4.26` також може попереджати про файли local build metadata stamp, які вже були відвантажені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови завершуються помилкою замість попередження або пропуску.
+Опублікований пакет `2026.4.26` також може попереджати про local build metadata stamp files, які вже були випущені. Пізніші пакети мають задовольняти сучасні контракти; ті самі умови призводять до failure, а не warn або skip.
 
 ### Приклади
 
@@ -286,111 +293,111 @@ gh workflow run package-acceptance.yml \
   -f docker_lanes='install-e2e plugin-update'
 ```
 
-Під час debugging невдалого запуску package acceptance починайте з підсумку `resolve_package`, щоб підтвердити джерело пакета, версію і SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, lane logs, phase timings і rerun commands. Віддавайте перевагу повторному запуску невдалого package profile або точних Docker lanes замість повторного запуску повної release validation.
+Під час debugging failed package acceptance run почніть із summary `resolve_package`, щоб підтвердити package source, version і SHA-256. Потім огляньте child run `docker_acceptance` і його Docker artifacts: `.artifacts/docker-tests/**/summary.json`, `failures.json`, lane logs, phase timings і rerun commands. Віддавайте перевагу rerun failed package profile або точних Docker lanes замість rerun повної release validation.
 
 ## Install smoke
 
-Окремий workflow `Install Smoke` повторно використовує той самий scope script через власне завдання `preflight`. Він розділяє smoke coverage на `run_fast_install_smoke` і `run_full_install_smoke`.
+Окремий workflow `Install Smoke` повторно використовує той самий scope script через власний job `preflight`. Він розділяє smoke coverage на `run_fast_install_smoke` і `run_full_install_smoke`.
 
-- **Fast path** запускається для pull requests, які торкаються Docker/package surfaces, змін package/manifest для bundled plugin або core plugin/channel/gateway/Plugin SDK surfaces, які перевіряють Docker smoke jobs. Source-only зміни bundled plugin, test-only edits і docs-only edits не резервують Docker workers. Fast path один раз збирає root Dockerfile image, перевіряє CLI, запускає agents delete shared-workspace CLI smoke, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений bundled-plugin Docker profile під 240-секундним aggregate command timeout (Docker run кожного scenario обмежений окремо).
-- **Full path** зберігає QR package install і installer Docker/update coverage для нічних scheduled runs, manual dispatches, workflow-call release checks і pull requests, які справді торкаються installer/package/Docker surfaces. У full mode install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і fast bundled-plugin Docker E2E як окремі завдання, щоб installer work не чекав за root image smokes.
+- **Швидкий шлях** запускається для pull requests, що торкаються Docker/package surfaces, змін bundled plugin package/manifest або core plugin/channel/gateway/Plugin SDK surfaces, які перевіряють Docker smoke jobs. Source-only зміни bundled plugin, test-only edits і docs-only edits не резервують Docker workers. Fast path один раз збирає root Dockerfile image, перевіряє CLI, запускає agents delete shared-workspace CLI smoke, запускає container gateway-network e2e, перевіряє bundled extension build arg і запускає bounded bundled-plugin Docker profile під 240-секундним aggregate command timeout (Docker run кожного scenario обмежено окремо).
+- **Повний шлях** зберігає QR package install і installer Docker/update coverage для nightly scheduled runs, manual dispatches, workflow-call release checks і pull requests, які справді торкаються installer/package/Docker surfaces. У full mode install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і fast bundled-plugin Docker E2E як окремі jobs, щоб installer work не чекав за root image smokes.
 
-Пуші в `main` (зокрема merge commits) не примушують full path; коли changed-scope logic вимагала б full coverage на push, workflow зберігає fast Docker smoke і залишає full install smoke для нічної або release validation.
+`main` pushes (включно з merge commits) не примушують full path; коли changed-scope logic запитала б full coverage на push, workflow залишає fast Docker smoke і лишає full install smoke для nightly або release validation.
 
-Повільний Bun global install image-provider smoke окремо обмежений через `run_bun_global_install_smoke`. Він запускається за нічним schedule і з release checks workflow, а manual `Install Smoke` dispatches можуть opt into it, але pull requests і пуші в `main` — ні. QR і installer Docker tests зберігають власні install-focused Dockerfiles.
+Повільний Bun global install image-provider smoke окремо gated через `run_bun_global_install_smoke`. Він запускається за nightly schedule і з workflow release checks, а manual dispatches `Install Smoke` можуть opt into it, але pull requests і `main` pushes — ні. QR і installer Docker tests зберігають власні install-focused Dockerfiles.
 
 ## Локальний Docker E2E
 
-`pnpm test:docker:all` попередньо збирає один спільний live-test image, пакує OpenClaw один раз як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
+`pnpm test:docker:all` попередньо збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
 
 - bare Node/Git runner для installer/update/plugin-dependency lanes;
 - functional image, який встановлює той самий tarball у `/app` для звичайних functionality lanes.
 
-Визначення Docker lane розміщені в `scripts/lib/docker-e2e-scenarios.mjs`, planner logic — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний plan. Scheduler вибирає image для кожного lane через `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
+Визначення Docker-ліній містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner лише виконує вибраний план. Планувальник вибирає образ для кожної лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
 
 ### Налаштування
 
-| Змінна                                 | Типово | Призначення                                                                                   |
-| -------------------------------------- | ------ | --------------------------------------------------------------------------------------------- |
-| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10     | Кількість слотів основного пулу для звичайних ліній.                                          |
-| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10     | Кількість слотів хвостового пулу, чутливого до провайдерів.                                   |
-| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9      | Обмеження одночасних live-ліній, щоб провайдери не застосовували throttling.                  |
-| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10     | Обмеження одночасних ліній встановлення npm.                                                   |
-| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7      | Обмеження одночасних багатосервісних ліній.                                                    |
-| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000   | Затримка між стартами ліній, щоб уникати сплесків створення в демонові Docker; задайте `0`, щоб вимкнути затримку. |
-| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000 | Резервний тайм-аут для кожної лінії (120 хвилин); вибрані live/хвостові лінії використовують жорсткіші обмеження. |
-| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | unset  | `1` виводить план планувальника без запуску ліній.                                            |
-| `OPENCLAW_DOCKER_ALL_LANES`            | unset  | Розділений комами точний список ліній; пропускає cleanup smoke, щоб агенти могли відтворити одну невдалу лінію. |
+| Змінна                                 | Типове значення | Призначення                                                                                                      |
+| -------------------------------------- | --------------- | --------------------------------------------------------------------------------------------------------------- |
+| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10              | Кількість слотів основного пулу для звичайних ліній.                                                            |
+| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10              | Кількість слотів хвостового пулу, чутливого до провайдерів.                                                     |
+| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9               | Обмеження одночасних live-ліній, щоб провайдери не вмикали throttling.                                          |
+| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10              | Обмеження одночасних ліній встановлення npm.                                                                    |
+| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7               | Обмеження одночасних багатосервісних ліній.                                                                     |
+| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000            | Інтервал між стартами ліній, щоб уникати штормів створення в Docker daemon; задайте `0`, щоб вимкнути інтервал. |
+| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000         | Резервний тайм-аут на лінію (120 хвилин); вибрані live/хвостові лінії використовують жорсткіші обмеження.       |
+| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | unset           | `1` друкує план планувальника без запуску ліній.                                                                |
+| `OPENCLAW_DOCKER_ALL_LANES`            | unset           | Розділений комами точний список ліній; пропускає cleanup smoke, щоб агенти могли відтворити одну збійну лінію.  |
 
-Лінія, важча за своє ефективне обмеження, усе ще може стартувати з порожнього пулу, а потім виконується самостійно, доки не звільнить місткість. Локальний агрегатор виконує попередні перевірки Docker, видаляє застарілі E2E-контейнери OpenClaw, виводить статус активних ліній, зберігає часові показники ліній для впорядкування від найдовших до найкоротших і за замовчуванням припиняє планувати нові pooled-лінії після першої помилки.
+Лінія, важча за її ефективне обмеження, все ще може стартувати з порожнього пулу, а потім працює самостійно, доки не звільнить місткість. Локальний агрегат попередньо перевіряє Docker, видаляє застарілі OpenClaw E2E-контейнери, виводить статус активних ліній, зберігає таймінги ліній для впорядкування від найдовших до найкоротших і типово припиняє планувати нові pooled-лінії після першого збою.
 
 ### Багаторазовий 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; збирає та публікує позначені digest пакета bare/functional образи GHCR Docker E2E через Docker layer cache Blacksmith, коли план потребує ліній із встановленим пакетом; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest образи замість повторного збирання. Завантаження Docker-образів повторюються з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий потік registry/cache швидко повторювався, а не споживав більшість критичного шляху CI.
+Багаторазовий live/E2E workflow запитує `scripts/test-docker-all.mjs --plan-json`, яке покриття package, типу образу, live-образу, лінії та облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт package з поточного запуску, або завантажує артефакт package з `package_artifact_run_id`; перевіряє інвентар tarball; збирає й пушить bare/functional GHCR Docker E2E-образи з тегом package digest через кеш Docker-шарів Blacksmith, коли плану потрібні лінії з установленим package; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні образи з package digest замість перебудови. Pull Docker-образів повторюється з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий registry/cache stream швидко повторювався, а не споживав більшу частину критичного шляху CI.
 
-### Фрагменти release-path
+### Частини release-path
 
-Покриття Release Docker запускає менші розбиті на фрагменти jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен фрагмент завантажував лише потрібний йому тип образу та виконував кілька ліній через той самий зважений планувальник:
+Release Docker-покриття запускає менші jobs із chunks з `OPENCLAW_SKIP_DOCKER_BUILD=1`, тож кожен chunk підтягує лише потрібний йому тип образу й виконує кілька ліній через той самий зважений планувальник:
 
 - `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
 - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h`
 
-Поточні фрагменти Release Docker: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, а також від `plugins-runtime-install-a` до `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегатними aliases для plugin/runtime. Alias лінії `install-e2e` залишається агрегатним manual rerun alias для обох ліній інсталяторів провайдерів.
+Поточні release Docker chunks: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` і від `plugins-runtime-install-a` до `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегатними alias для plugin/runtime. Alias лінії `install-e2e` залишається агрегатним manual rerun alias для обох ліній встановлювача провайдера.
 
-OpenWebUI включається до `plugins-runtime-services`, коли повне покриття release-path його запитує, і зберігає окремий фрагмент `openwebui` лише для OpenWebUI-only dispatches. Лінії оновлення bundled-channel повторюють спробу один раз у разі тимчасових мережевих помилок npm.
+OpenWebUI входить до `plugins-runtime-services`, коли повне release-path покриття його запитує, і зберігає окремий chunk `openwebui` лише для dispatch, присвячених тільки OpenWebUI. Лінії оновлення bundled-channel повторюють запуск один раз у разі тимчасових npm network failures.
 
-Кожен фрагмент завантажує `.artifacts/docker-tests/` із логами ліній, часовими показниками, `summary.json`, `failures.json`, часовими показниками фаз, JSON плану планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість jobs фрагментів, що обмежує налагодження невдалої лінії одним цільовим Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана лінія є live Docker-лінією, цільовий job локально збирає live-test образ для цього повторного запуску. Згенеровані для кожної лінії команди GitHub rerun включають `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, щоб невдала лінія могла повторно використати точний пакет і образи з невдалого запуску.
+Кожен chunk завантажує `.artifacts/docker-tests/` з logs ліній, таймінгами, `summary.json`, `failures.json`, фазовими таймінгами, JSON плану планувальника, таблицями повільних ліній і командами rerun для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість chunk jobs, що обмежує налагодження збійної лінії одним targeted Docker job і готує, завантажує або повторно використовує артефакт package для цього запуску; якщо вибрана лінія є live Docker-лінією, targeted job локально збирає live-test image для цього rerun. Згенеровані для кожної лінії GitHub-команди rerun включають `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, тож збійна лінія може повторно використати точний package і образи зі збійного запуску.
 
 ```bash
 pnpm test:docker:rerun <run-id>      # download Docker artifacts and print combined/per-lane targeted rerun commands
 pnpm test:docker:timings <summary>   # slow-lane and phase critical-path summaries
 ```
 
-Запланований live/E2E workflow щодня запускає повний набір Docker release-path.
+Запланований live/E2E workflow щодня запускає повний release-path Docker suite.
 
-## Передреліз Plugin
+## Попередній реліз Plugin
 
-`Plugin Prerelease` є дорожчим покриттям product/package, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull requests, push-и в `main` і самостійні manual CI dispatches тримають цей набір вимкненим. Він балансує тести bundled plugin між вісьмома extension workers; ці extension shard jobs запускають до двох груп конфігурації plugin одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy партії plugin не створювали додаткових CI jobs. Release-only Docker prerelease path групує цільові Docker-лінії в невеликі групи, щоб не резервувати десятки runners для jobs тривалістю від однієї до трьох хвилин.
+`Plugin Prerelease` є дорожчим покриттям product/package, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull requests, pushes у `main` і standalone manual CI dispatches не запускають цей suite. Він балансує тести bundled plugin між вісьмома extension workers; ці extension shard jobs запускають до двох груп plugin config одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy plugin batches не створювали додаткових CI jobs. Release-only Docker prerelease path групує targeted Docker lanes у невеликі групи, щоб не резервувати десятки runners для jobs тривалістю від однієї до трьох хвилин.
 
 ## QA Lab
 
 QA Lab має окремі CI-лінії поза основним smart-scoped workflow.
 
-- Workflow `Parity gate` запускається для відповідних змін PR і manual dispatch; він збирає приватний QA runtime і порівнює agentic packs mock GPT-5.5 та Opus 4.6.
-- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і через manual dispatch; він розгалужує mock parity gate, live Matrix-лінію, а також live Telegram і Discord лінії як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases.
+- Workflow `Parity gate` запускається для відповідних змін PR і manual dispatch; він збирає приватний QA runtime і порівнює mock GPT-5.5 та Opus 4.6 agentic packs.
+- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і за manual dispatch; він розгортає mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases.
 
-Release checks запускають live transport-лінії Matrix і Telegram з детермінованим mock provider і mock-qualified models (`mock-openai/gpt-5.5` та `mock-openai/gpt-5.5-alt`), щоб contract каналу був ізольований від затримки live model і звичайного запуску 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`), щоб 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` для scheduled і release gates, додаючи `--fail-fast` лише тоді, коли checked-out CLI це підтримує. Типове значення CLI та input manual workflow залишаються `all`; manual dispatch `matrix_profile=all` завжди розбиває повне покриття Matrix на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
+Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише коли checked-out CLI це підтримує. Типове значення CLI і manual workflow input залишаються `all`; manual dispatch `matrix_profile=all` завжди розбиває повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
 
-`OpenClaw Release Checks` також запускає release-critical лінії QA Lab перед схваленням release; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва артефакти в невеликий report job для фінального порівняння parity.
+`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед approval релізу; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у невеликий report job для фінального parity comparison.
 
-Не ставте шлях landing PR за `Parity gate`, якщо зміна фактично не зачіпає QA runtime, model-pack parity або поверхню, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-тестів вважайте це optional signal і дотримуйтеся scoped CI/check evidence.
+Не ставте PR landing path за `Parity gate`, якщо зміна насправді не зачіпає QA runtime, model-pack parity або surface, яким володіє parity workflow. Для звичайних виправлень channel, config, docs або unit-test розглядайте це як optional signal і дотримуйтеся scoped CI/check evidence.
 
 ## CodeQL
 
-Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним sweep репозиторію. Daily, manual і non-draft pull request guard runs сканують Actions workflow code плюс JavaScript/TypeScript поверхні з найвищим ризиком за допомогою high-confidence security queries, відфільтрованих до high/critical `security-severity`.
+Workflow `CodeQL` навмисно є вузьким first-pass security scanner, а не повним sweep репозиторію. Daily, manual і non-draft pull request guard runs сканують Actions workflow code плюс JavaScript/TypeScript surfaces із найвищим ризиком за допомогою high-confidence security queries, відфільтрованих до high/critical `security-severity`.
 
-Pull request guard залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security matrix, що й scheduled workflow. Android і macOS CodeQL не входять до PR defaults.
+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 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 і поверхні SSRF policy Plugin SDK                                                    |
-| `/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, package-manager install, source-loading і trust surfaces package contract Plugin SDK     |
+| Категорія                                        | Surface                                                                                                                           |
+| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
+| `/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, package-manager install, source-loading і trust surfaces package contract Plugin SDK |
 
 ### Platform-specific security shards
 
 - `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 із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Тримається поза daily defaults, бо macOS build домінує за часом виконання навіть у чистому стані.
+- `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` є відповідним 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.
+`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.
 
 Manual dispatch приймає:
 
@@ -398,40 +405,40 @@ 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
 ```
 
-Вузькі profiles є teaching/iteration hooks для запуску одного quality shard в ізоляції.
+Вузькі профілі є навчальними/ітераційними хуками для запуску одного якісного сегмента ізольовано.
 
-| Категорія                                               | Поверхня                                                                                                                                                                         |
-| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-critical-quality/core-auth-secrets`            | Auth, secrets, sandbox, 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/chunking/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, media IO, розуміння медіа, генерації зображень і генерації медіа                                                               |
-| `/codeql-critical-quality/plugin-boundary`              | Контракти завантажувача, реєстру, публічної поверхні та entrypoint 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`             | Схема конфігурації, міграція, нормалізація та контракти введення-виведення                                                                                                           |
+| `/codeql-critical-quality/gateway-runtime-boundary`    | Схеми протоколу Gateway і контракти методів сервера                                                                                                                                  |
+| `/codeql-critical-quality/channel-runtime-boundary`    | Контракти реалізації основного каналу та вбудованого канального plugin                                                                                                               |
+| `/codeql-critical-quality/agent-runtime-boundary`      | Виконання команд, диспетчеризація моделей/провайдерів, диспетчеризація автовідповідей і черги, а також runtime-контракти площини керування ACP                                      |
+| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-сервери та мости інструментів, допоміжні засоби нагляду за процесами й контракти вихідної доставки                                                                              |
+| `/codeql-critical-quality/memory-runtime-boundary`     | SDK хоста пам’яті, runtime-фасади пам’яті, псевдоніми SDK пам’яті Plugin, зв’язувальний код активації 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-контракти площини керування завданнями                                              |
+| `/codeql-critical-quality/web-media-runtime-boundary`  | Runtime-контракти основного web fetch/search, media IO, розуміння медіа, image-generation і media-generation                                                                         |
+| `/codeql-critical-quality/plugin-boundary`             | Контракти завантажувача, реєстру, публічної поверхні та entrypoint Plugin SDK                                                                                                        |
+| `/codeql-critical-quality/plugin-sdk-package-contract` | Опублікований package-side вихідний код Plugin SDK і допоміжні засоби контрактів пакетів plugin                                                                                     |
 
-Якість залишається окремою від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без розмивання сигналу безпеки. Розширення CodeQL для Swift, Python і bundled-plugin слід повертати як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
+Якість залишається окремо від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і вбудованих plugin слід додавати назад як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
 
-## Робочі процеси супроводу
+## Робочі процеси обслуговування
 
 ### Docs Agent
 
-Робочий процес `Docs Agent` — це подієво-керована лінія супроводу Codex для підтримання наявної документації узгодженою з нещодавно внесеними змінами. Він не має чистого розкладу: успішний CI-запуск push не від бота на `main` може його запустити, а ручний запуск може виконати його напряму. Виклики через workflow-run пропускаються, коли `main` уже просунувся далі або коли інший непропущений запуск Docs Agent було створено протягом останньої години. Коли він виконується, він переглядає діапазон комітів від попереднього непропущеного source SHA Docs Agent до поточного `main`, тому один щогодинний запуск може охопити всі зміни main, накопичені з часу останнього проходу документації.
+Робочий процес `Docs Agent` — це подієво-керована лінія обслуговування Codex для підтримання наявної документації в узгодженості з нещодавно доданими змінами. Він не має чистого розкладу: успішний CI-запуск push не від бота на `main` може його запустити, а manual dispatch може запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли за останню годину було створено інший непропущений запуск Docs Agent. Коли він запускається, він переглядає діапазон комітів від попереднього непропущеного source SHA Docs Agent до поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені з часу останнього проходу документації.
 
 ### Test Performance Agent
 
-Робочий процес `Test Performance Agent` — це подієво-керована лінія супроводу Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск push не від бота на `main` може його запустити, але він пропускається, якщо інший workflow-run виклик уже виконувався або виконується цього UTC-дня. Ручний запуск обходить цей денний gate активності. Лінія будує згрупований звіт продуктивності Vitest для повного набору тестів, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт повного набору й відхиляє зміни, що зменшують базову кількість успішних тестів. Якщо в baseline є тести з помилками, Codex може виправляти лише очевидні збої, а післяагентський звіт повного набору має пройти перед будь-яким комітом. Коли `main` просувається вперед до того, як bot push буде внесено, лінія перебазовує перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму безпечну позицію drop-sudo, що й docs agent.
+Робочий процес `Test Performance Agent` — це подієво-керована лінія обслуговування Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск push не від бота на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже виконувався або виконується цього UTC-дня. Manual dispatch обходить цей щоденний шлюз активності. Лінія збирає згрупований звіт продуктивності Vitest для всього набору, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт для всього набору й відхиляє зміни, які зменшують базову кількість успішних тестів. Якщо в базовому стані є тести, що падають, Codex може виправляти лише очевидні збої, а повний звіт після агента для всього набору має пройти перед тим, як щось буде закомічено. Коли `main` просувається до того, як bot push потрапляє в репозиторій, лінія ребейзить перевірений патч, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі патчі пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму позицію безпеки drop-sudo, що й docs agent.
 
-### Дублікати PR після merge
+### Дублікати PR після злиття
 
-Робочий процес `Duplicate PRs After Merge` — це ручний робочий процес супровідників для очищення дублікатів після land. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR змарджено і що кожен duplicate має або спільну referenced issue, або hunks змін, що перетинаються.
+Робочий процес `Duplicate PRs After Merge` — це ручний workflow для мейнтейнерів для очищення дублікатів після land. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR злито і що кожен дублікат має або спільне referenced issue, або перетин змінених hunks.
 
 ```bash
 gh workflow run duplicate-after-merge.yml \
@@ -440,29 +447,29 @@ gh workflow run duplicate-after-merge.yml \
   -f apply=true
 ```
 
-## Локальні check gates і changed routing
+## Локальні check-gates і маршрутизація змін
 
-Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий scope 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 extension sweeps залишаються явною тестовою роботою);
+- зміни core production запускають typecheck core prod і core test, а також core lint/guards;
+- зміни лише core test запускають лише typecheck core test і core lint;
+- зміни extension production запускають typecheck extension prod і extension test, а також extension lint;
+- зміни лише extension test запускають typecheck extension test і extension lint;
+- зміни публічного Plugin SDK або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core contracts (Vitest extension sweeps залишаються явною тестовою роботою);
 - version bumps лише release metadata запускають цільові перевірки version/config/root-dependency;
-- невідомі зміни root/config безпечно переходять у всі check lanes.
+- невідомі зміни root/config fail safe до всіх check lanes.
 
-Локальний changed-test routing міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі зміни тестів запускають самі себе, зміни source віддають перевагу явним mappings, потім sibling tests і import-graph dependents. Shared group-room delivery config — один із явних mappings: зміни до group visible-reply config, source reply delivery mode або system prompt message-tool проходять через core reply tests плюс регресії доставки Discord і Slack, щоб зміна shared default падала ще до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна достатньо harness-wide, що дешевий mapped set не є надійним proxy.
+Локальна маршрутизація changed-test розміщена в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі редагування тестів запускають самі себе, редагування source віддають перевагу явним mappings, потім sibling tests і import-graph dependents. Спільна конфігурація доставки group-room є одним із явних 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 із кореня репозиторію та віддавайте перевагу свіжому warmed box для широкого proof. Перед тим як витрачати повільний gate на box, який повторно використовували, у якого сплив строк дії або який щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` всередині box.
+Запускайте Testbox з кореня репозиторію й віддавайте перевагу свіжому прогрітому box для широкого доказу. Перед тим як витрачати повільний gate на box, який був повторно використаний, протермінований або щойно повідомив про несподівано великий sync, спочатку запустіть `pnpm testbox:sanity` всередині box.
 
-Sanity check швидко падає, коли потрібні root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що remote sync state не є надійною копією PR; зупиніть цей box і прогрійте новий замість debug product test failure. Для навмисних PR із великими deletions задайте `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run.
+Sanity check швидко падає, коли потрібні root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що remote sync state не є надійною копією PR; зупиніть цей box і прогрійте свіжий замість налагодження збою product test. Для навмисних PR із великими видаленнями задайте `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run.
 
-`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі sync понад п’ять хвилин без 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, або використайте більше значення в мілісекундах для незвично великих локальних diffs.
 
-Crabbox — це repo-owned другий шлях remote-box для Linux proof, коли Blacksmith недоступний або коли власна cloud capacity є кращою. Прогрійте box, hydrate його через project workflow, потім запускайте команди через Crabbox CLI:
+Crabbox — це repo-owned другий шлях remote-box для Linux proof, коли Blacksmith недоступний або коли власна хмарна потужність є кращою. Прогрійте box, hydrate його через project workflow, а потім запускайте команди через Crabbox CLI:
 
 ```bash
 pnpm crabbox:warmup -- --idle-timeout 90m
@@ -471,7 +478,7 @@ pnpm crabbox:run -- --id <cbx_id> --shell "OPENCLAW_TESTBOX=1 pnpm check:changed
 pnpm crabbox:stop -- <cbx_id>
 ```
 
-`.crabbox.yaml` володіє defaults для provider, sync і GitHub Actions hydration. Він виключає локальний `.git`, щоб hydrated Actions checkout зберігав власні remote Git metadata замість синхронізації maintainer-local remotes і object stores, а також виключає локальні runtime/build artifacts, які ніколи не мають передаватися. `.github/workflows/crabbox-hydrate.yml` володіє checkout, налаштуванням Node/pnpm, fetch `origin/main` і передачею non-secret environment, яку пізніші команди `crabbox run --id <cbx_id>` source.
+`.crabbox.yaml` володіє типовими налаштуваннями provider, sync і GitHub Actions hydration. Він виключає локальний `.git`, щоб hydrated Actions checkout зберігав власні remote Git metadata замість синхронізації maintainer-local remotes і object stores, а також виключає локальні runtime/build artifacts, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` володіє checkout, налаштуванням Node/pnpm, fetch `origin/main` і non-secret environment handoff, який пізніші команди `crabbox run --id <cbx_id>` source.
 
 ## Пов’язане
 

docs/uk/reference/RELEASING.md

@@ -1,24 +1,24 @@
 ---
 read_when:
-    - Пошук визначень публічних каналів релізів
-    - Запуск валідації релізу або приймального тестування пакета
-    - Шукаєте інформацію про іменування версій і періодичність випусків
-summary: Релізні канали, контрольний список оператора, середовища валідації, іменування версій і періодичність
+    - Пошук визначень публічних каналів випуску
+    - Запуск перевірки релізу або приймання пакета
+    - Шукаєте правила іменування версій і періодичність випусків
+summary: Релізні лінії, контрольний список оператора, бокси валідації, іменування версій і ритм
 title: Політика випусків
 x-i18n:
-    generated_at: "2026-05-02T04:48:11Z"
+    generated_at: "2026-05-02T06:28:27Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 3ce380a8277e7c8764359e4ded86d1042dcb250691ac62fbee28651f20aa0580
+    source_hash: 97554cdf9ac79080a7b371afe0a0c8288a6ca53729abb42401399dca24a12067
     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`
 
 ## Назви версій
 
@@ -26,232 +26,246 @@ OpenClaw має три публічні канали релізів:
   - Git-тег: `vYYYY.M.D`
 - Версія стабільного коригувального релізу: `YYYY.M.D-N`
   - Git-тег: `vYYYY.M.D-N`
-- Версія бета-передрелізу: `YYYY.M.D-beta.N`
+- Версія beta-попереднього релізу: `YYYY.M.D-beta.N`
   - Git-тег: `vYYYY.M.D-beta.N`
-- Не додавайте початковий нуль до місяця або дня
-- `latest` означає поточний просунутий стабільний npm-реліз
-- `beta` означає поточну ціль встановлення бета-версії
-- Стабільні та стабільні коригувальні релізи за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно націлитися на `latest` або пізніше просунути перевірену бета-збірку
-- Кожен стабільний реліз OpenClaw постачається разом із npm-пакетом і застосунком macOS;
-  бета-релізи зазвичай спершу перевіряють і публікують шлях npm/пакета, а
-  збірку/підпис/нотаризацію застосунку Mac резервують для стабільного релізу, якщо це не запитано явно
+- Не додавайте нулі на початку місяця або дня
+- `latest` означає поточний підвищений стабільний реліз npm
+- `beta` означає поточну ціль установлення beta
+- Стабільні та стабільні коригувальні релізи за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно вибрати `latest` або пізніше підвищити перевірену збірку beta
+- Кожен стабільний реліз OpenClaw постачає npm-пакет і застосунок macOS разом;
+  beta-релізи зазвичай спочатку перевіряють і публікують шлях npm/package, а
+  складання/підписування/нотаризацію застосунку Mac залишають для стабільних релізів, якщо це явно не запитано
 
-## Частота релізів
+## Періодичність релізів
 
-- Релізи рухаються спершу через бета-канал
-- Стабільний реліз виходить лише після перевірки останньої бета-версії
-- Мейнтейнери зазвичай готують релізи з гілки `release/YYYY.M.D`, створеної
-  з поточного `main`, щоб валідація релізу та виправлення не блокували нову
+- Релізи рухаються спочатку через beta
+- Стабільний реліз виходить лише після перевірки останньої beta
+- Мейнтейнери зазвичай створюють релізи з гілки `release/YYYY.M.D`, створеної
+  з поточного `main`, щоб перевірка релізу та виправлення не блокували нову
   розробку в `main`
-- Якщо бета-тег уже надіслано або опубліковано і він потребує виправлення, мейнтейнери створюють
-  наступний тег `-beta.N` замість видалення чи повторного створення старого бета-тега
-- Детальна процедура релізу, затвердження, облікові дані та нотатки з відновлення
+- Якщо beta-тег уже надіслано або опубліковано і він потребує виправлення, мейнтейнери створюють
+  наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега
+- Детальна процедура релізу, затвердження, облікові дані та нотатки щодо відновлення
   доступні лише мейнтейнерам
 
 ## Контрольний список оператора релізу
 
-Цей контрольний список описує публічну форму релізного процесу. Приватні облікові дані,
-підписування, нотаризація, відновлення dist-tag і деталі аварійного відкату залишаються в
-релізному runbook лише для мейнтейнерів.
+Цей контрольний список є публічною формою процесу релізу. Приватні облікові дані,
+підписування, нотаризація, відновлення dist-tag і деталі екстреного відкату залишаються в
+runbook релізів лише для мейнтейнерів.
 
 1. Почніть із поточного `main`: підтягніть останні зміни, підтвердьте, що цільовий коміт надіслано,
-   і підтвердьте, що поточний CI для `main` достатньо зелений, щоб відгалужуватися від нього.
-2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії комітів за допомогою
-   `/changelog`, залиште записи орієнтованими на користувачів, закомітьте його, надішліть і виконайте rebase/pull
+   і підтвердьте, що поточний CI для `main` достатньо зелений, щоб створювати від нього гілку.
+2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою
+   `/changelog`, залиште записи орієнтованими на користувача, закомітьте його, надішліть його, і виконайте rebase/pull
    ще раз перед створенням гілки.
 3. Перегляньте записи сумісності релізу в
    `src/plugins/compat/registry.ts` і
-   `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену
-   сумісність лише тоді, коли шлях оновлення лишається покритим, або зафіксуйте, чому її
-   навмисно збережено.
-4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну релізну роботу
+   `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте застарілу
+   сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому вона
+   навмисно зберігається.
+4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над релізом
    безпосередньо в `main`.
-5. Збільште версію в кожному потрібному місці для запланованого тега, а потім запустіть
-   локальний детермінований preflight:
+5. Підвищте кожне потрібне місце версії для запланованого тега, запустіть
+   `pnpm plugins:sync`, щоб пакети Plugin, придатні для публікації, мали спільну версію релізу
+   та метадані сумісності, потім запустіть локальну детерміновану попередню перевірку:
    `pnpm check:test-types`, `pnpm check:architecture`,
-   `pnpm build && pnpm ui:build` і `pnpm release:check`.
-6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тега
-   для валідаційного preflight дозволено повний 40-символьний SHA релізної гілки.
+   `pnpm build && pnpm ui:build`, `pnpm plugins:sync:check` і
+   `pnpm release:check`.
+6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. Поки тег не існує,
+   повний 40-символьний SHA гілки релізу дозволено для попередньої перевірки лише з метою валідації.
    Збережіть успішний `preflight_run_id`.
 7. Запустіть усі передрелізні тести через `Full Release Validation` для
-   релізної гілки, тега або повного SHA коміту. Це єдина ручна точка входу
-   для чотирьох великих релізних тестових боксів: Vitest, Docker, QA Lab і Package.
-8. Якщо валідація не пройшла, виправте в релізній гілці й повторно запустіть найменший невдалий
-   файл, канал, job workflow, профіль пакета, провайдера або allowlist моделі, що
-   доводить виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня робить
+   гілки релізу, тега або повного SHA коміту. Це єдина ручна точка входу
+   для чотирьох великих тестових середовищ релізу: Vitest, Docker, QA Lab і Package.
+8. Якщо перевірка не проходить, виправте проблему в гілці релізу та повторно запустіть найменший невдалий
+   файл, гілку, job 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. Для стабільного релізу продовжуйте лише після того, як перевірена бета-версія або release candidate матиме
-    потрібні докази валідації. Публікація стабільного npm-релізу повторно використовує успішний
-    preflight-артефакт через `preflight_run_id`; готовність стабільного релізу macOS
-    також вимагає упаковані `.zip`, `.dmg`, `.dSYM.zip` і оновлений
-    `appcast.xml` у `main`.
-11. Після публікації запустіть npm post-publish verifier, за потреби опційний автономний
-    published-npm Telegram E2E, коли потрібен доказ каналу після публікації,
-    просування dist-tag, коли потрібно, нотатки GitHub release/prerelease з
+9. Для beta поставте тег `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з
+   відповідної гілки `release/YYYY.M.D`. Він перевіряє `pnpm plugins:sync:check`,
+   спочатку публікує всі пакети Plugin, придатні для публікації, в npm, другим кроком публікує той самий
+   набір у ClawHub, а потім підвищує підготовлений артефакт попередньої перевірки OpenClaw npm
+   з dist-tag `beta`. Після публікації запустіть post-publish package
+   acceptance для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або `openclaw@beta`.
+   Якщо надіслана або опублікована beta потребує виправлення, створіть наступний `-beta.N`;
+   не видаляйте і не переписуйте стару beta.
+10. Для стабільного релізу продовжуйте лише після того, як перевірена beta або release candidate має
+    потрібні докази валідації. Публікація стабільного npm також проходить через
+    `OpenClaw Release Publish`, повторно використовуючи успішний артефакт попередньої перевірки через
+    `preflight_run_id`; готовність стабільного релізу macOS також потребує
+    упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`.
+11. Після публікації запустіть npm post-publish verifier, необов’язковий окремий
+    published-npm Telegram E2E, коли вам потрібен post-publish доказ каналу,
+    підвищення dist-tag за потреби, нотатки GitHub release/prerelease з
     повного відповідного розділу `CHANGELOG.md` і кроки оголошення релізу.
 
-## Release preflight
+## Попередня перевірка релізу
 
 - Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався
-  покритим поза швидшим локальним шлюзом `pnpm check`
+  покритим поза швидшим локальним gate `pnpm check`
 - Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів
-  імпортів і архітектурних меж були зеленими поза швидшим локальним шлюзом
+  імпорту та меж архітектури були зеленими поза швидшим локальним gate
 - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
-  релізні артефакти `dist/*` і бандл Control UI існували для кроку валідації
-  пакування
+  релізні артефакти `dist/*` і bundle Control UI існували для етапу валідації
+  pack
 - Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб
-  запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку,
-  тег або повний SHA коміту, запускає ручний `CI` і запускає
-  `OpenClaw Release Checks` для інсталяційного smoke-тесту, приймання пакета, Docker
-  наборів release-path, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram
-  lane. З `release_profile=full` і `rerun_group=all` він також запускає package
-  Telegram E2E проти артефакту `release-package-under-test` із release checks.
-  Надайте `npm_telegram_package_spec` після публікації, коли той самий Telegram E2E
-  має також підтвердити опублікований npm-пакет. Надайте
+  запустити всі передрелізні тестові boxes з однієї точки входу. Він приймає гілку,
+  tag або повний commit SHA, запускає ручний `CI` і запускає
+  `OpenClaw Release Checks` для install smoke, package acceptance, Docker
+  release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram
+  lanes. З `release_profile=full` і `rerun_group=all` він також запускає package
+  Telegram E2E проти артефакту `release-package-under-test` з release
+  checks. Надайте `npm_telegram_package_spec` після публікації, коли той самий
+  Telegram E2E також має підтвердити опублікований npm package. Надайте
   `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що
-  валідація відповідає опублікованому npm-пакету, без примусового запуску Telegram E2E.
+  валідація відповідає опублікованому npm package, без примусового Telegram E2E.
   Приклад:
   `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
-- Запустіть ручний workflow `Package Acceptance`, коли потрібне побічне підтвердження
-  для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для
-  `openclaw@beta`, `openclaw@latest` або точної версії релізу; `source=ref`, щоб
-  запакувати довірену гілку/тег/SHA `package_ref` з поточним harness
-  `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим SHA-256; або
-  `source=artifact` для tarball, завантаженого іншим запуском GitHub
-  Actions. Workflow визначає кандидата як
+- Запустіть ручний workflow `Package Acceptance`, коли потрібен side-channel доказ
+  для package candidate, поки релізна робота триває. Використовуйте `source=npm` для
+  `openclaw@beta`, `openclaw@latest` або точної release version; `source=ref`,
+  щоб упакувати довірену гілку/tag/SHA `package_ref` з поточним
+  harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим
+  SHA-256; або `source=artifact` для tarball, завантаженого іншим GitHub
+  Actions run. Workflow resolves candidate to
   `package-under-test`, повторно використовує Docker E2E release scheduler проти цього
   tarball і може запускати Telegram QA проти того самого tarball з
   `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані
-  Docker lanes містять `published-upgrade-survivor`, артефакт пакета є кандидатом, а
-  `published_upgrade_survivor_baseline` вибирає опубліковану базову версію.
+  Docker lanes містять `published-upgrade-survivor`, package artifact є candidate,
+  а `published_upgrade_survivor_baseline` вибирає published baseline.
   Приклад: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai`
-  Типові профілі:
-  - `smoke`: lane для install/channel/agent, gateway network і config reload
-  - `package`: lane для package/update/Plugin, нативні до артефакту, без OpenWebUI або live ClawHub
-  - `product`: профіль package плюс MCP channels, очищення cron/subagent,
-    вебпошук OpenAI і OpenWebUI
-  - `full`: частини Docker release-path з OpenWebUI
+  Поширені профілі:
+  - `smoke`: install/channel/agent, gateway network і config reload lanes
+  - `package`: artifact-native package/update/plugin lanes без OpenWebUI або live ClawHub
+  - `product`: package profile плюс MCP channels, cron/subagent cleanup,
+    OpenAI web search і OpenWebUI
+  - `full`: Docker release-path chunks з OpenWebUI
   - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску
 - Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI
-  покриття для release candidate. Ручні CI dispatch оминають changed
+  покриття для release candidate. Ручні CI dispatches bypass 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
+  contracts, Node 22 compatibility, `check`, `check-additional`, build smoke,
+  docs checks, 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` під час валідації release telemetry. Він проганяє
+  QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace
+  span, обмежені attributes і редагування content/identifier без потреби в
+  Opik, Langfuse або іншому зовнішньому collector.
+- Запустіть `pnpm release:check` перед кожним tagged release
+- Запустіть `OpenClaw Release Publish` для mutating publish sequence після того, як
+  tag існує. Dispatch його з `release/YYYY.M.D` (або `main`, коли публікується
+  main-reachable tag), передайте release tag і успішний OpenClaw npm
+  `preflight_run_id`, і залиште default plugin publish scope
+  `all-publishable`, якщо ви не виконуєте навмисний focused repair. Workflow
+  serializes plugin npm publish, plugin ClawHub publish і OpenClaw
+  npm publish, щоб core package не було опубліковано перед його externalized
+  plugins.
 - Release checks тепер виконуються в окремому ручному workflow:
   `OpenClaw Release Checks`
-- `OpenClaw Release Checks` також запускає QA Lab mock parity gate плюс швидкий
+- `OpenClaw Release Checks` також запускає QA Lab mock parity gate плюс fast
   live Matrix profile і Telegram QA lane перед схваленням релізу. Live
   lanes використовують середовище `qa-live-shared`; Telegram також використовує Convex CI
-  leases облікових даних. Запустіть ручний workflow `QA-Lab - All Lanes` з
-  `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix
-  transport, media і E2EE паралельно.
-- Cross-OS інсталяційна та upgrade runtime валідація є частиною публічних
+  credential leases. Запустіть ручний workflow `QA-Lab - All Lanes` з
+  `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний Matrix
+  transport, media і E2EE inventory паралельно.
+- Cross-OS install і upgrade runtime validation є частиною публічних
   `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають
   reusable workflow
   `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
 - Цей поділ навмисний: тримайте реальний npm release path коротким,
-  детермінованим і сфокусованим на артефактах, тоді як повільніші live checks залишаються у своїй
-  окремій lane, щоб не затримувати й не блокувати публікацію
-- Release checks із секретами слід запускати через `Full Release
-Validation` або з workflow ref `main`/release, щоб логіка workflow і
-  секрети залишалися контрольованими
-- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо
-  визначений коміт доступний з гілки OpenClaw або релізного тегу
-- validation-only preflight `OpenClaw NPM Release` також приймає поточний
-  повний 40-символьний SHA коміту workflow-гілки без вимоги до запушеного тегу
-- Цей шлях SHA призначений лише для валідації й не може бути підвищений до реальної публікації
-- У режимі SHA workflow синтезує `v<package.json version>` лише для
-  перевірки метаданих пакета; реальна публікація все ще потребує справжнього релізного тегу
-- Обидва workflow залишають реальний шлях публікації та promotion на GitHub-hosted
-  runners, тоді як немутувальний шлях валідації може використовувати більші
+  deterministic і artifact-focused, тоді як повільніші live checks залишаються у власному
+  lane, щоб вони не затримували й не блокували publish
+- Secret-bearing release checks слід dispatch через `Full Release
+Validation` або з `main`/release workflow ref, щоб workflow logic і
+  secrets залишалися контрольованими
+- `OpenClaw Release Checks` приймає гілку, tag або повний commit SHA, якщо
+  resolved commit reachable з OpenClaw branch або release tag
+- Validation-only preflight `OpenClaw NPM Release` також приймає поточний
+  повний 40-символьний workflow-branch commit SHA без потреби в pushed tag
+- Цей SHA path призначений лише для валідації й не може бути promoted у реальний publish
+- У SHA mode workflow synthesizes `v<package.json version>` лише для
+  package metadata check; реальний publish усе ще потребує справжнього release tag
+- Обидва workflows тримають реальний publish і promotion path на GitHub-hosted
+  runners, тоді як non-mutating validation path може використовувати більші
   Blacksmith Linux runners
 - Цей workflow запускає
   `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
-  з використанням workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
-- npm release preflight більше не чекає на окрему release checks lane
+  з використанням обох workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
+- npm release preflight більше не чекає на окремий release checks lane
 - Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
   (або відповідний beta/correction tag) перед схваленням
 - Після npm publish запустіть
   `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  (або відповідну beta/correction version), щоб перевірити шлях інсталяції з опублікованого 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-пакета з використанням спільного leased pool облікових даних Telegram.
-  Локальні одноразові maintainer-запуски можуть пропустити Convex vars і передати три
+  (або відповідну beta/correction version), щоб перевірити published registry
+  install path у свіжому temp prefix
+- Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`,
+  щоб перевірити installed-package onboarding, Telegram setup і реальний Telegram E2E
+  проти опублікованого npm package, використовуючи shared leased Telegram credential
+  pool. Локальні одноразові maintainer runs можуть пропускати Convex vars і передавати три
   env credentials `OPENCLAW_QA_TELEGRAM_*` напряму.
-- Maintainers можуть запускати ту саму post-publish перевірку з GitHub Actions через
-  ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
-  не запускається після кожного merge.
+- Maintainers можуть запускати ту саму post-publish check з GitHub Actions через
+  ручний workflow `NPM Telegram Beta E2E`. Він навмисно manual-only і
+  не запускається на кожному merge.
 - Maintainer release automation тепер використовує preflight-then-promote:
-  - реальна npm publish має пройти успішний npm `preflight_run_id`
-  - реальна npm publish має запускатися з тієї самої гілки `main` або
+  - реальний npm publish має пройти успішний npm `preflight_run_id`
+  - реальний npm publish має бути dispatched з тієї самої гілки `main` або
     `release/YYYY.M.D`, що й успішний preflight run
-  - стабільні npm releases за замовчуванням мають `beta`
-  - стабільний npm publish може явно націлюватися на `latest` через workflow input
+  - stable npm releases default to `beta`
+  - stable npm publish може явно цілитися в `latest` через workflow input
   - token-based npm dist-tag mutation тепер живе в
     `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
-    з міркувань безпеки, бо `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як
-    публічний repo зберігає OIDC-only publish
-  - публічний `macOS Release` є validation-only; коли тег існує лише на
-    release branch, але workflow запущено з `main`, задайте
+    для безпеки, бо `npm dist-tag add` все ще потребує `NPM_TOKEN`, тоді як
+    public repo keeps OIDC-only publish
+  - public `macOS Release` є validation-only; коли tag існує лише на
+    release branch, але workflow dispatched з `main`, встановіть
     `public_release_branch=release/YYYY.M.D`
   - реальний private mac publish має пройти успішні private mac
     `preflight_run_id` і `validate_run_id`
-  - реальні publish paths просувають підготовлені артефакти замість повторної
-    перебудови
-- Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier
+  - реальні publish paths promote prepared artifacts замість того, щоб rebuilding
+    them again
+- Для stable correction releases на кшталт `YYYY.M.D-N` post-publish verifier
   також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`,
   щоб release corrections не могли непомітно залишити старіші global installs на
-  базовому stable payload
-- npm release preflight завершується fail closed, якщо tarball не містить одночасно
-  `dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`,
-  щоб ми знову не відправили порожній browser dashboard
-- Post-publish verification також перевіряє, що опубліковані Plugin entrypoints і
-  метадані пакета присутні в установленому registry layout. Реліз, який
-  постачає відсутні runtime payloads Plugin, провалює postpublish verifier і
-  не може бути promoted до `latest`.
-- `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-owned
-  matrix outputs `plugin-prerelease-extension-shard` з
-  `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не
-  описували застарілий CI layout
-- Готовність стабільного macOS release також включає updater surfaces:
-  - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
-  - `appcast.xml` на `main` має вказувати на новий stable zip після publish
-  - запакований app має зберігати non-debug bundle id, непорожній Sparkle feed
-    URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor
-    для цієї версії релізу
+  base stable payload
+- npm release preflight fails closed, якщо tarball не містить одночасно
+  `dist/control-ui/index.html` і non-empty payload `dist/control-ui/assets/`,
+  щоб ми знову не shipped empty browser dashboard
+- Post-publish verification також перевіряє, що published plugin entrypoints і
+  package metadata присутні в installed registry layout. Реліз, який
+  ships missing plugin runtime payloads, fails postpublish verifier і
+  не може бути promoted to `latest`.
+- `pnpm test:install:smoke` також enforces npm pack `unpackedSize` budget on
+  candidate update tarball, щоб installer e2e catches accidental pack bloat
+  перед release publish path
+- Якщо release work touched CI planning, extension timing manifests або
+  extension test matrices, regenerate and review planner-owned
+  `plugin-prerelease-extension-shard` matrix outputs from
+  `.github/workflows/plugin-prerelease.yml` перед approval, щоб release notes не
+  описували stale CI layout
+- Stable macOS release readiness також includes updater surfaces:
+  - GitHub release має в підсумку містити packaged `.zip`, `.dmg` і `.dSYM.zip`
+  - `appcast.xml` on `main` має point at new stable zip after publish
+  - packaged app має keep non-debug bundle id, non-empty Sparkle feed
+    URL і `CFBundleVersion` на або вище canonical Sparkle build floor
+    for that release version
 
-## Релізні тестові бокси
+## Release test boxes
 
-`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести з
-однієї точки входу. Для підтвердження pinned commit на швидко змінюваній гілці використовуйте
-helper, щоб кожен child workflow запускався з тимчасової гілки, зафіксованої на цільовому
+`Full Release Validation` — це спосіб, яким operators запускають усі передрелізні тести з
+однієї точки входу. Для pinned commit proof на швидко змінюваній гілці використовуйте
+helper, щоб кожен child workflow запускався з тимчасової гілки, зафіксованої на target
 SHA:
 
 ```bash
 pnpm ci:full-release --sha <full-sha>
 ```
 
-Helper пушить `release-ci/<sha>-...`, запускає `Full Release Validation`
-з цієї гілки з `ref=<sha>`, перевіряє, що кожен child workflow `headSha`
-відповідає цільовому, а потім видаляє тимчасову гілку. Це запобігає випадковому підтвердженню
-новішого child run `main`.
+Helper pushes `release-ci/<sha>-...`, dispatches `Full Release Validation`
+from that branch with `ref=<sha>`, verifies every child workflow `headSha`
+matches the target, then deletes the temporary branch. This avoids proving a
+newer `main` child run by accident.
 
 Для валідації release branch або tag запустіть його з довіреного workflow
 ref `main` і передайте release branch або tag як `ref`:
@@ -266,47 +280,45 @@ gh workflow run full-release-validation.yml \
   -f evidence_package_spec=openclaw@YYYY.M.D-beta.N
 ```
 
-Робочий процес визначає цільове посилання, запускає ручний `CI` з
+Робочий процес визначає цільовий ref, запускає ручний `CI` з
 `target_ref=<release-ref>`, запускає `OpenClaw Release Checks` і запускає
 окремий пакетний Telegram E2E, коли `release_profile=full` з
 `rerun_group=all` або коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release
-Checks` розгортає перевірку встановлення, кросплатформні перевірки релізу,
-live/E2E покриття релізного шляху Docker, Package Acceptance з QA пакета
-Telegram, паритет QA Lab, live Matrix і live Telegram. Повний запуск прийнятний
-лише тоді, коли зведення `Full Release Validation` показує `normal_ci` і
-`release_checks` як успішні. У режимі full/all дочірній `npm_telegram` також має
-бути успішним; поза full/all його пропускають, якщо не було надано опублікований
-`npm_telegram_package_spec`. Фінальне зведення верифікатора містить таблиці
-найповільніших завдань для кожного дочірнього запуску, щоб менеджер релізу міг
-бачити поточний критичний шлях без завантаження логів.
-Див. [Повну валідацію релізу](/uk/reference/full-release-validation), щоб отримати
-повну матрицю етапів, точні назви завдань workflow, відмінності між stable і
-full профілями, артефакти та цільові засоби повторного запуску.
-Дочірні workflow запускаються з довіреного посилання, яке запускає `Full Release
-Validation`, зазвичай `--ref main`, навіть коли цільове `ref` вказує на старішу
-релізну гілку або тег. Окремого input для workflow-ref у Full Release Validation
-немає; вибирайте довірену обв'язку, вибираючи ref запуску workflow.
-Не використовуйте `--ref main -f ref=<sha>` для доказу точного коміту на рухомій
-`main`; сирі SHA комітів не можуть бути refs для запуску workflow, тому
-використовуйте `pnpm ci:full-release --sha <sha>`, щоб створити закріплену
-тимчасову гілку.
+Checks` розгортає install smoke, cross-OS release checks, live/E2E Docker
+coverage для release path, Package Acceptance з QA пакета Telegram, QA Lab
+parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли
+зведення `Full Release Validation`
+показує `normal_ci` і `release_checks` як успішні. У режимі full/all
+дочірній `npm_telegram` також має бути успішним; поза full/all він пропускається,
+якщо не було надано опублікований `npm_telegram_package_spec`. Фінальне
+зведення verifier містить таблиці найповільніших завдань для кожного дочірнього запуску, щоб release
+manager міг бачити поточний критичний шлях без завантаження логів.
+Див. [Повна валідація релізу](/uk/reference/full-release-validation) для
+повної матриці етапів, точних назв завдань workflow, відмінностей між stable і full профілями,
+артефактів і ручок для сфокусованого повторного запуску.
+Дочірні workflow запускаються з довіреного ref, який виконує `Full Release
+Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на
+старішу релізну гілку або тег. Окремого input workflow-ref для Full Release Validation
+немає; обирайте довірений harness, обираючи ref запуску workflow.
+Не використовуйте `--ref main -f ref=<sha>` для доказу точного коміту на рухомому `main`;
+сирі SHA комітів не можуть бути refs для workflow dispatch, тому використовуйте
+`pnpm ci:full-release --sha <sha>`, щоб створити закріплену тимчасову гілку.
 
 Використовуйте `release_profile`, щоб вибрати ширину live/provider:
 
-- `minimum`: найшвидший релізно-критичний OpenAI/core live і шлях Docker
-- `stable`: minimum плюс stable покриття provider/backend для схвалення релізу
-- `full`: stable плюс широке advisory покриття provider/media
+- `minimum`: найшвидший release-critical OpenAI/core live і Docker path
+- `stable`: minimum плюс stable provider/backend coverage для затвердження релізу
+- `full`: stable плюс широке advisory provider/media coverage
 
-`OpenClaw Release Checks` використовує довірений ref workflow, щоб один раз
-визначити цільовий ref як `release-package-under-test`, і повторно використовує
-цей артефакт як у Docker-перевірках релізного шляху, так і в Package Acceptance.
-Це тримає всі пакетно-орієнтовані бокси на тих самих байтах і уникає повторних
-збірок пакета. Кросплатформна OpenAI перевірка встановлення використовує
-`OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли задано змінну repo/org, інакше
-`openai/gpt-5.5`, оскільки ця лінія доводить встановлення пакета, onboarding,
-запуск Gateway і один live хід агента, а не бенчмарк найповільнішої стандартної
-моделі. Ширша live матриця provider залишається місцем для model-specific
-покриття.
+`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз визначити цільовий
+ref як `release-package-under-test`, і повторно використовує цей артефакт як у
+release-path Docker checks, так і в Package Acceptance. Це утримує всі
+package-facing бокси на тих самих байтах і уникає повторних збірок пакета.
+Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли
+змінну repo/org задано, інакше `openai/gpt-5.5`, оскільки ця lane
+доводить встановлення пакета, onboarding, запуск gateway і один live agent turn,
+а не бенчмарк найповільнішої моделі за замовчуванням. Ширша live provider
+matrix залишається місцем для model-specific coverage.
 
 Використовуйте ці варіанти залежно від етапу релізу:
 
@@ -338,45 +350,41 @@ gh workflow run full-release-validation.yml \
   -f npm_telegram_provider_mode=mock-openai
 ```
 
-Не використовуйте повну парасолькову перевірку як перший повторний запуск після
-цільового виправлення. Якщо один бокс падає, для наступного доказу використайте
-невдалий дочірній workflow, завдання, Docker-лінію, профіль пакета, model
-provider або QA-лінію. Запускайте повну парасолькову перевірку знову лише тоді,
-коли виправлення змінило спільну оркестрацію релізу або зробило попередні
-докази all-box застарілими. Фінальний верифікатор парасольки повторно перевіряє
-записані id запусків дочірніх workflow, тому після успішного повторного запуску
-дочірнього workflow повторно запускайте лише невдале батьківське завдання
-`Verify full validation`.
+Не використовуйте повну umbrella як перший повторний запуск після сфокусованого виправлення. Якщо один box
+падає, використовуйте невдалий дочірній workflow, job, Docker lane, package profile, model
+provider або QA lane для наступного доказу. Запускайте повну umbrella знову лише тоді, коли
+виправлення змінило спільну release orchestration або зробило попередній all-box evidence
+застарілим. Фінальний verifier umbrella повторно перевіряє записані child workflow run
+ids, тому після успішного повторного запуску child workflow повторно запускайте лише невдалий
+батьківський job `Verify full validation`.
 
-Для обмеженого відновлення передайте `rerun_group` до парасольки. `all` є
-справжнім запуском release-candidate, `ci` запускає лише звичайний дочірній CI,
-`plugin-prerelease` запускає лише релізний дочірній Plugin, `release-checks`
-запускає кожен релізний бокс, а вужчі релізні групи: `install-smoke`, `cross-os`,
+Для обмеженого відновлення передайте `rerun_group` в umbrella. `all` — це справжній
+запуск release candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease`
+запускає лише release-only plugin child, `release-checks` запускає кожен release
+box, а вужчі release groups — це `install-smoke`, `cross-os`,
 `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`.
-Цільові повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`;
-full/all запуски з `release_profile=full` використовують артефакт пакета
-release-checks.
+Сфокусовані повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; запуски full/all
+з `release_profile=full` використовують артефакт пакета release-checks.
 
 ### Vitest
 
-Бокс Vitest є ручним дочірнім workflow `CI`. Ручний CI навмисно обходить
-changed scoping і примусово запускає звичайний граф тестів для кандидата
-релізу: Linux Node shards, shards bundled-plugin, контракти каналів,
-сумісність Node 22, `check`, `check-additional`, build smoke, перевірки docs,
-Python skills, Windows, macOS, Android і Control UI i18n.
+Vitest box — це ручний дочірній workflow `CI`. Ручний CI навмисно
+обходить changed scoping і примусово виконує звичайний тестовий граф для release
+candidate: Linux Node shards, bundled-plugin shards, channel contracts, Node 22
+compatibility, `check`, `check-additional`, build smoke, docs checks, Python
+skills, Windows, macOS, Android і Control UI i18n.
 
-Використовуйте цей бокс, щоб відповісти: «чи пройшло дерево вихідного коду
-повний звичайний набір тестів?» Це не те саме, що продуктова валідація
-релізного шляху. Докази, які слід зберігати:
+Використовуйте цей box, щоб відповісти: "чи пройшло дерево джерел повний звичайний набір тестів?"
+Це не те саме, що release-path product validation. Докази, які слід зберігати:
 
-- зведення `Full Release Validation`, що показує URL запущеного `CI`
-- зелений запуск `CI` на точному цільовому SHA
-- назви невдалих або повільних shards із завдань CI під час розслідування регресій
-- артефакти таймінгів Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли
+- зведення `Full Release Validation`, що показує URL запущеного `CI` run
+- зелений `CI` run на точному цільовому SHA
+- назви невдалих або повільних shard із CI jobs під час розслідування регресій
+- артефакти таймінгів Vitest, такі як `.artifacts/vitest-shard-timings.json`, коли
   запуск потребує аналізу продуктивності
 
-Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований
-звичайний CI, але не Docker, QA Lab, live, cross-OS або пакетні бокси:
+Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований звичайний CI, але
+не Docker, QA Lab, live, cross-OS або package boxes:
 
 ```bash
 gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
@@ -384,113 +392,110 @@ 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`, а також у релізному workflow
-`install-smoke`. Він валідує кандидата релізу через пакетовані середовища
-Docker, а не лише тести рівня вихідного коду.
+Docker box живе в `OpenClaw Release Checks` через
+`openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode
+workflow `install-smoke`. Він перевіряє release candidate через упаковані
+Docker середовища, а не лише тести рівня джерел.
 
-Релізне Docker-покриття містить:
+Release Docker coverage включає:
 
-- повну перевірку встановлення з увімкненою повільною Bun global install smoke
-- підготовку/повторне використання root Dockerfile smoke image за цільовим SHA,
-  із QR, root/gateway та installer/Bun smoke завданнями, що запускаються як
-  окремі install-smoke shards
-- repository E2E лінії
-- Docker chunks релізного шляху: `core`, `package-update-openai`,
+- повний install smoke з увімкненим повільним Bun global install smoke
+- підготовку/повторне використання root Dockerfile smoke image за цільовим SHA, з QR,
+  root/gateway і installer/Bun smoke jobs, що виконуються як окремі install-smoke
+  shards
+- repository E2E lanes
+- release-path Docker chunks: `core`, `package-update-openai`,
   `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`,
   `plugins-runtime-services`,
   `plugins-runtime-install-a`, `plugins-runtime-install-b`,
   `plugins-runtime-install-c`, `plugins-runtime-install-d`,
   `plugins-runtime-install-e`, `plugins-runtime-install-f`,
   `plugins-runtime-install-g` і `plugins-runtime-install-h`
-- покриття OpenWebUI всередині chunk `plugins-runtime-services`, коли запитано
-- розділені лінії встановлення/видалення bundled Plugin
-  `bundled-plugin-install-uninstall-0` через
+- OpenWebUI coverage всередині chunk `plugins-runtime-services`, коли це запитано
+- розділені bundled plugin install/uninstall lanes
+  `bundled-plugin-install-uninstall-0` до
   `bundled-plugin-install-uninstall-23`
-- live/E2E набори provider і Docker live model покриття, коли release checks
-  містять live suites
+- live/E2E provider suites і Docker live model coverage, коли release checks
+  включають live suites
 
-Використовуйте артефакти Docker перед повторним запуском. Планувальник
-релізного шляху завантажує `.artifacts/docker-tests/` із логами ліній,
-`summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника та
-командами повторного запуску. Для цільового відновлення використовуйте
-`docker_lanes=<lane[,lane]>` у reusable live/E2E workflow замість повторного
-запуску всіх релізних chunks. Згенеровані команди повторного запуску містять
-попередній `package_artifact_run_id` і prepared Docker image inputs, коли вони
-доступні, щоб невдала лінія могла повторно використати той самий tarball і
-GHCR images.
+Використовуйте Docker артефакти перед повторним запуском. Release-path scheduler завантажує
+`.artifacts/docker-tests/` з логами lane, `summary.json`, `failures.json`,
+таймінгами фаз, scheduler plan JSON і командами повторного запуску. Для сфокусованого відновлення
+використовуйте `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow замість
+повторного запуску всіх release chunks. Згенеровані команди повторного запуску включають попередні
+`package_artifact_run_id` і підготовлені Docker image inputs, коли доступні, щоб
+невдала lane могла повторно використати той самий tarball і GHCR images.
 
 ### QA Lab
 
-Бокс QA Lab також є частиною `OpenClaw Release Checks`. Це релізний gate для
-agentic поведінки та рівня каналів, окремий від Vitest і механіки пакетів
-Docker.
+QA Lab box також є частиною `OpenClaw Release Checks`. Це agentic
+behavior і channel-level release gate, окремий від Vitest і Docker
+package mechanics.
 
-Релізне покриття QA Lab містить:
+Release QA Lab coverage включає:
 
-- mock parity gate, що порівнює candidate lane OpenAI з baseline Opus 4.6 за
-  допомогою agentic parity pack
-- fast live Matrix QA profile з використанням середовища `qa-live-shared`
+- mock parity gate, що порівнює OpenAI candidate lane з Opus 4.6
+  baseline за допомогою agentic parity pack
+- швидкий live Matrix QA profile з використанням середовища `qa-live-shared`
 - live Telegram QA lane з використанням Convex CI credential leases
 - `pnpm qa:otel:smoke`, коли release telemetry потребує явного локального доказу
 
-Використовуйте цей бокс, щоб відповісти: «чи поводиться реліз правильно у QA
-сценаріях і live channel flows?» Зберігайте URL артефактів для ліній parity,
-Matrix і Telegram під час схвалення релізу. Повне покриття Matrix залишається
-доступним як ручний sharded QA-Lab запуск, а не стандартна релізно-критична
-лінія.
+Використовуйте цей box, щоб відповісти: "чи поводиться реліз коректно у QA сценаріях і
+live channel flows?" Зберігайте URL артефактів для parity, Matrix і Telegram
+lanes під час затвердження релізу. Повне Matrix coverage залишається доступним як
+ручний sharded QA-Lab run, а не release-critical lane за замовчуванням.
 
 ### Пакет
 
-Бокс Package є gate installable-product. Він підтримується `Package Acceptance`
-і resolver `scripts/resolve-openclaw-package-candidate.mjs`. Resolver
-нормалізує candidate у tarball `package-under-test`, який споживає Docker E2E,
-валідує інвентар пакета, записує версію пакета та SHA-256 і тримає ref обв'язки
-workflow окремо від ref джерела пакета.
+Package box — це installable-product gate. Він підтримується
+`Package Acceptance` і resolver
+`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує
+candidate у tarball `package-under-test`, який споживає Docker E2E, перевіряє
+інвентар пакета, записує версію пакета та SHA-256 і тримає
+workflow harness ref окремо від package source ref.
 
 Підтримувані джерела candidate:
 
-- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна версія релізу OpenClaw
-- `source=ref`: запакувати довірену гілку `package_ref`, тег або повний SHA
-  коміту з вибраною обв'язкою `workflow_ref`
-- `source=url`: завантажити HTTPS `.tgz` з обов'язковим `package_sha256`
-- `source=artifact`: повторно використати `.tgz`, завантажений іншим запуском
-  GitHub Actions
+- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна release
+  version OpenClaw
+- `source=ref`: пакувати довірену `package_ref` branch, tag або full commit SHA
+  з вибраним `workflow_ref` harness
+- `source=url`: завантажити HTTPS `.tgz` з обов’язковим `package_sha256`
+- `source=artifact`: повторно використати `.tgz`, завантажений іншим GitHub Actions run
 
 `OpenClaw Release Checks` запускає Package Acceptance з `source=artifact`,
-підготовленим артефактом релізного пакета, `suite_profile=custom`,
+підготовленим release package artifact, `suite_profile=custom`,
 `docker_lanes=doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update`,
 `published_upgrade_survivor_baselines=release-history`,
 `published_upgrade_survivor_scenarios=reported-issues` і
-`telegram_mode=mock-openai`. Package Acceptance тримає migration, update,
-очищення застарілих залежностей Plugin, offline Plugin fixtures, plugin update і
-QA пакета Telegram на тому самому визначеному tarball. Це GitHub-native заміна
-для більшості package/update покриття, яке раніше потребувало Parallels.
-Кросплатформні release checks усе ще важливі для OS-specific onboarding,
-installer і platform behavior, але продуктова валідація package/update має
-віддавати перевагу Package Acceptance.
+`telegram_mode=mock-openai`. Package Acceptance утримує migration, update, stale
+plugin dependency cleanup, offline plugin fixtures, plugin update і Telegram
+package QA проти того самого resolved tarball. Це GitHub-native
+заміна більшої частини package/update coverage, яка раніше потребувала
+Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding,
+installer і platform behavior, але package/update product validation має
+надавати перевагу Package Acceptance.
 
-Канонічний checklist для валідації update і Plugin:
-[Тестування оновлень і plugins](/uk/help/testing-updates-plugins). Використовуйте
-його, коли вирішуєте, яка локальна, Docker, Package Acceptance або release-check
-лінія доводить зміну встановлення/оновлення Plugin, doctor cleanup або
-published-package migration. Вичерпна published update migration з кожного
-stable пакета `2026.4.23+` є окремим ручним workflow `Update Migration`, а не
-частиною Full Release CI.
+Канонічний checklist для update і plugin validation —
+[Тестування оновлень і plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли
+вирішуєте, яка local, Docker, Package Acceptance або release-check lane доводить
+plugin install/update, doctor cleanup або published-package migration change.
+Exhaustive published update migration з кожного stable пакета `2026.4.23+` — це
+окремий ручний workflow `Update Migration`, а не частина Full Release CI.
 
-Застаріла поблажливість package-acceptance навмисно обмежена в часі. Пакети до
-`2026.4.25` включно можуть використовувати шлях сумісності для metadata gaps,
-уже опублікованих до npm: приватні записи QA inventory, відсутні в tarball,
-відсутній `gateway install --wrapper`, відсутні patch files у tarball-derived
-git fixture, відсутній збережений `update.channel`, застарілі розташування
-plugin install-record, відсутня persistence marketplace install-record і config
-metadata migration під час `plugins update`. Опублікований пакет `2026.4.26`
-може попереджати про local build metadata stamp files, які вже були shipped.
-Пізніші пакети мають задовольняти сучасні package contracts; ті самі gaps
-провалюють release validation.
+Legacy package-acceptance leniency навмисно обмежена в часі. Пакети до
+`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, які вже були shipped. Пізніші пакети
+мають задовольняти сучасні package contracts; ті самі gaps провалюють release
+validation.
 
-Використовуйте ширші профілі Package Acceptance, коли релізне питання стосується
-реального installable package:
+Використовуйте ширші Package Acceptance profiles, коли release question стосується
+фактичного installable package:
 
 ```bash
 gh workflow run package-acceptance.yml \
@@ -504,85 +509,86 @@ gh workflow run package-acceptance.yml \
 
 Поширені package profiles:
 
-- `smoke`: швидкі лінії package install/channel/agent, gateway network і config
-  reload
-- `package`: контракти install/update/plugin package без live ClawHub; це стандарт
-  release-check
+- `smoke`: quick package install/channel/agent, gateway network і config
+  reload lanes
+- `package`: install/update/plugin package contracts без live ClawHub; це release-check
+  default
 - `product`: `package` плюс MCP channels, cron/subagent cleanup, OpenAI web
   search і OpenWebUI
-- `full`: Docker chunks релізного шляху з OpenWebUI
-- `custom`: точний список `docker_lanes` для цільових повторних запусків
+- `full`: Docker release-path chunks з OpenWebUI
+- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків
 
-Для підтвердження Telegram кандидата пакета увімкніть `telegram_mode=mock-openai` або
+Для підтвердження пакета-кандидата Telegram увімкніть `telegram_mode=mock-openai` або
 `telegram_mode=live-frontier` у Package Acceptance. Workflow передає
-визначений tarball `package-under-test` у лінію Telegram; окремий
-workflow Telegram досі приймає опубліковану специфікацію npm для перевірок після публікації.
+розв’язаний tarball `package-under-test` у доріжку Telegram; окремий
+workflow Telegram досі приймає опубліковану npm-специфікацію для перевірок
+після публікації.
 
-## Вхідні параметри workflow NPM
+## Вхідні дані workflow NPM
 
-`OpenClaw NPM Release` приймає такі вхідні параметри, керовані оператором:
+`OpenClaw NPM Release` приймає такі вхідні дані, керовані оператором:
 
-- `tag`: обов’язковий тег релізу, як-от `v2026.4.2`, `v2026.4.2-1` або
+- `tag`: обов’язковий тег релізу, наприклад `v2026.4.2`, `v2026.4.2-1` або
   `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
   повний 40-символьний SHA коміту гілки workflow для preflight лише з валідацією
 - `preflight_only`: `true` лише для валідації/збірки/пакета, `false` для
   реального шляху публікації
-- `preflight_run_id`: обов’язковий у реальному шляху публікації, щоб workflow повторно використав
+- `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб workflow повторно використав
   підготовлений tarball з успішного preflight-запуску
-- `npm_dist_tag`: цільовий тег npm для шляху публікації; за замовчуванням `beta`
+- `npm_dist_tag`: цільовий тег npm для шляху публікації; типове значення `beta`
 
-`OpenClaw Release Checks` приймає такі вхідні параметри, керовані оператором:
+`OpenClaw Release Checks` приймає такі вхідні дані, керовані оператором:
 
-- `ref`: гілка, тег або повний SHA коміту для валідації. Перевірки, що використовують секрети,
-  вимагають, щоб визначений коміт був досяжний з гілки OpenClaw або
-  тега релізу.
+- `ref`: гілка, тег або повний SHA коміту для валідації. Перевірки, що містять
+  secrets, вимагають, щоб розв’язаний коміт був досяжний з гілки OpenClaw або
+  релізного тегу.
 
 Правила:
 
-- Стабільні й корекційні теги можуть публікуватися або в `beta`, або в `latest`
-- Теги prerelease beta можуть публікуватися лише в `beta`
-- Для `OpenClaw NPM Release` введення повного SHA коміту дозволене лише коли
+- Стабільні та корекційні теги можна публікувати або в `beta`, або в `latest`
+- Beta-теги prerelease можна публікувати лише в `beta`
+- Для `OpenClaw NPM Release` вхідний повний SHA коміту дозволений лише коли
   `preflight_only=true`
-- `OpenClaw Release Checks` і `Full Release Validation` завжди виконують
-  лише валідацію
+- `OpenClaw Release Checks` і `Full Release Validation` завжди
+  призначені лише для валідації
 - Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
-  workflow перевіряє ці метадані перед продовженням публікації
+  workflow перевіряє ці metadata перед продовженням публікації
 
 ## Послідовність стабільного npm-релізу
 
-Під час підготовки стабільного npm-релізу:
+Коли готуєте стабільний npm-реліз:
 
 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
-   - Поки тег ще не існує, можна використати поточний повний SHA коміту гілки workflow
+   - До створення тегу можна використовувати поточний повний SHA коміту гілки workflow
      для пробного запуску preflight workflow лише з валідацією
-2. Виберіть `npm_dist_tag=beta` для звичайного потоку спершу через beta або `latest` лише
-   тоді, коли навмисно потрібна пряма стабільна публікація
-3. Запустіть `Full Release Validation` на гілці релізу, тезі релізу або повному
+2. Виберіть `npm_dist_tag=beta` для звичайного потоку спочатку в beta або `latest` лише
+   коли ви навмисно хочете пряму стабільну публікацію
+3. Запустіть `Full Release Validation` на релізній гілці, релізному тегу або повному
    SHA коміту, коли потрібні звичайний CI плюс покриття live prompt cache, Docker, QA Lab,
    Matrix і Telegram з одного ручного workflow
-4. Якщо навмисно потрібен лише детермінований звичайний граф тестів, натомість запустіть
-   ручний workflow `CI` на ref релізу
+4. Якщо вам навмисно потрібен лише детермінований звичайний граф тестів, запустіть
+   ручний workflow `CI` на release ref натомість
 5. Збережіть успішний `preflight_run_id`
-6. Знову запустіть `OpenClaw NPM Release` з `preflight_only=false`, тим самим
+6. Запустіть `OpenClaw NPM Release` знову з `preflight_only=false`, тим самим
    `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id`
 7. Якщо реліз потрапив у `beta`, використайте приватний
    workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
-   щоб підвищити цю стабільну версію з `beta` до `latest`
-8. Якщо реліз навмисно опубліковано безпосередньо в `latest` і `beta`
-   має одразу вказувати на ту саму стабільну збірку, використайте той самий приватний
+   щоб просунути цю стабільну версію з `beta` до `latest`
+8. Якщо реліз навмисно опубліковано напряму в `latest`, а `beta`
+   має негайно вказувати на ту саму стабільну збірку, використайте той самий приватний
    workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
    самовідновлювальній синхронізації перемістити `beta` пізніше
 
-Зміна dist-tag розміщена в приватному репозиторії з міркувань безпеки, бо вона досі
-потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
+Зміна dist-tag розміщена у приватному repo з міркувань безпеки, оскільки вона досі
+потребує `NPM_TOKEN`, тоді як публічний repo зберігає публікацію лише через OIDC.
 
-Це робить і шлях прямої публікації, і шлях просування спершу через beta
+Це робить і шлях прямої публікації, і шлях просування спочатку через beta
 задокументованими та видимими для оператора.
 
-Якщо супровідник мусить повернутися до локальної автентифікації npm, запускайте будь-які команди 1Password
-CLI (`op`) лише всередині окремої tmux-сесії. Не викликайте `op`
-безпосередньо з основної оболонки агента; утримання цього всередині tmux робить запити,
-сповіщення та обробку OTP видимими й запобігає повторним сповіщенням хоста.
+Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password
+CLI (`op`) лише всередині виділеної tmux-сесії. Не викликайте `op`
+напряму з основної оболонки агента; утримання його всередині tmux робить prompts,
+alerts і обробку OTP видимими та запобігає повторним сповіщенням хоста.
 
 ## Публічні посилання
 
@@ -596,7 +602,7 @@ CLI (`op`) лише всередині окремої tmux-сесії. Не ви
 - [`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.