chore(i18n): refresh uk translations

docs/uk/ci.md

@@ -1,75 +1,75 @@
 ---
 read_when:
-    - Потрібно з’ясувати, чому завдання CI запустилося або не запустилося
-    - Ви налагоджуєте перевірку GitHub Actions, яка не проходить
-    - Ви координуєте запуск або повторний запуск перевірки випуску
-summary: Граф завдань CI, перевірки за областю дії, релізні зведені перевірки та локальні еквіваленти команд
+    - Потрібно зрозуміти, чому завдання CI запустилося або не запустилося
+    - Ви діагностуєте перевірку GitHub Actions, що завершується з помилкою
+    - Ви координуєте запуск або повторний запуск валідації релізу
+summary: Граф завдань CI, гейти області, релізні парасольки та локальні еквіваленти команд
 title: Конвеєр CI
 x-i18n:
-    generated_at: "2026-04-30T05:47:33Z"
+    generated_at: "2026-04-30T05:58:46Z"
     model: gpt-5.5
     provider: openai
-    source_hash: 1cdbf803e7a6c7ad75cd499234a58443e2a36557c34972f59ea144e0ebd3a6f4
+    source_hash: a606991e83c50e82c1e0f8f96fd582fa1c6cbd0b999af4920f1e0af66d54d944
     source_path: ci.md
     workflow: 16
 ---
 
-OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі lanes, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження scope і розгортають повний graph для release candidates і широкої валідації. Android lanes лишаються опційними через `include_android`. Release-only покриття плагінів міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch.
+OpenClaw CI запускається при кожному push до `main` і для кожного pull request. Завдання `preflight` класифікує diff і вимикає витратніші напрями, коли зміни стосуються лише непов’язаних ділянок. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження scope і розгортають повний граф для release candidate та широкої валідації. Напрями Android залишаються opt-in через `include_android`. Покриття Plugin лише для релізу міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або через явний ручний dispatch.
 
-## Огляд Pipeline
+## Огляд pipeline
 
-| Завдання                         | Призначення                                                                                  | Коли запускається                  |
-| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- |
-| `preflight`                      | Виявляє docs-only зміни, змінені scopes, змінені extensions і будує CI manifest              | Завжди для non-draft pushes і PRs  |
-| `security-scm-fast`              | Виявлення приватних ключів і аудит workflow через `zizmor`                                   | Завжди для non-draft pushes і PRs  |
-| `security-dependency-audit`      | Production-аудит lockfile без установлення залежностей за npm advisories                     | Завжди для non-draft pushes і PRs  |
-| `security-fast`                  | Обов’язковий aggregate для швидких security jobs                                             | Завжди для non-draft pushes і PRs  |
-| `check-dependencies`             | Production-прохід Knip лише для залежностей плюс guard allowlist невикористаних файлів       | Node-релевантні зміни              |
-| `build-artifacts`                | Збирає `dist/`, Control UI, перевірки built artifacts і повторно використовувані downstream artifacts | Node-релевантні зміни              |
-| `checks-fast-core`               | Швидкі Linux correctness lanes, як-от bundled/plugin-contract/protocol checks                | Node-релевантні зміни              |
-| `checks-fast-contracts-channels` | Sharded перевірки channel contract зі стабільним aggregate check result                      | Node-релевантні зміни              |
-| `checks-node-core-test`          | Shards тестів Core Node, без 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`                         | Верифікатор для built-artifact channel tests                                                 | Node-релевантні зміни              |
-| `checks-node-compat-node22`      | Node 22 compatibility build і smoke lane                                                     | Manual CI dispatch для releases    |
-| `check-docs`                     | Форматування docs, lint і перевірки broken links                                             | Docs змінено                       |
-| `skills-python`                  | Ruff + pytest для Skills на основі Python                                                    | Зміни, релевантні для Python Skills |
-| `checks-windows`                 | Windows-специфічні тести process/path плюс regressions shared runtime import specifier       | Windows-релевантні зміни           |
-| `macos-node`                     | macOS TypeScript test lane з використанням shared built artifacts                            | macOS-релевантні зміни             |
-| `macos-swift`                    | Swift lint, build і tests для macOS app                                                      | macOS-релевантні зміни             |
-| `android`                        | Android unit tests для обох flavors плюс одна debug APK build                                | Android-релевантні зміни           |
+| Завдання                         | Призначення                                                                                  | Коли запускається                 |
+| -------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------- |
+| `preflight`                      | Виявляє зміни лише в документації, змінені scope, змінені extensions і будує CI manifest     | Завжди для non-draft push і PR    |
+| `security-scm-fast`              | Виявлення приватних ключів і аудит workflow через `zizmor`                                   | Завжди для non-draft push і PR    |
+| `security-dependency-audit`      | Production-аудит lockfile без dependencies на основі npm advisories                          | Завжди для non-draft push і PR    |
+| `security-fast`                  | Обов’язковий aggregate для швидких security-завдань                                          | Завжди для non-draft push і PR    |
+| `check-dependencies`             | Production-прохід Knip лише для dependencies плюс guard allowlist невикористаних файлів      | Node-релевантні зміни             |
+| `build-artifacts`                | Збирає `dist/`, Control UI, перевірки built-artifact і перевикористовувані downstream artifacts | Node-релевантні зміни          |
+| `checks-fast-core`               | Швидкі Linux-напрями коректності, як-от bundled/plugin-contract/protocol checks              | Node-релевантні зміни             |
+| `checks-fast-contracts-channels` | Sharded-перевірки channel contract зі стабільним aggregate check result                      | Node-релевантні зміни             |
+| `checks-node-core-test`          | Shards тестів Core Node, без channel, bundled, contract і extension напрямів                 | Node-релевантні зміни             |
+| `check`                          | Sharded-еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Node-релевантні зміни        |
+| `check-additional`               | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards    | Node-релевантні зміни             |
+| `build-smoke`                    | Built-CLI smoke tests і startup-memory smoke                                                 | Node-релевантні зміни             |
+| `checks`                         | Verifier для built-artifact channel tests                                                    | Node-релевантні зміни             |
+| `checks-node-compat-node22`      | Сумісність із Node 22: build і smoke lane                                                    | Ручний CI dispatch для релізів    |
+| `check-docs`                     | Форматування документації, lint і перевірки broken links                                     | Документацію змінено              |
+| `skills-python`                  | Ruff + pytest для skills на Python                                                           | Зміни, релевантні Python skills   |
+| `checks-windows`                 | Специфічні для Windows process/path tests плюс регресії shared runtime import specifier      | Windows-релевантні зміни          |
+| `macos-node`                     | macOS TypeScript test lane із використанням спільних built artifacts                         | macOS-релевантні зміни            |
+| `macos-swift`                    | Swift lint, build і tests для застосунку macOS                                               | macOS-релевантні зміни            |
+| `android`                        | Android unit tests для обох flavors плюс одна збірка debug APK                               | Android-релевантні зміни          |
 | `test-performance-agent`         | Щоденна оптимізація повільних тестів Codex після trusted activity                            | Успішний Main CI або manual dispatch |
 
 ## Порядок fail-fast
 
-1. `preflight` вирішує, які lanes взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими jobs.
-2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи важчих artifact і platform matrix jobs.
-3. `build-artifacts` перекривається зі швидкими Linux lanes, щоб downstream consumers могли стартувати, щойно shared build готовий.
-4. Важчі platform і runtime lanes розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
+1. `preflight` вирішує, які напрями взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями.
+2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не очікуючи важчих artifact і platform matrix jobs.
+3. `build-artifacts` перекривається зі швидкими Linux-напрямами, щоб downstream consumers могли стартувати одразу, щойно спільний build буде готовий.
+4. Після цього розгортаються важчі platform і runtime напрями: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
 
-GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Сприймайте це як CI noise, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тож вони все одно повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже superseded. Автоматичний CI concurrency key має версію (`CI-v7-*`), тому GitHub-side zombie у старій queue group не може безстроково блокувати новіші main runs. Manual full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs.
+GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це CI-шумом, якщо найновіший запуск для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже було замінено. Автоматичний CI concurrency key має версію (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs.
 
 ## Scope і routing
 
-Логіка scope міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest діяти так, ніби кожна scoped area змінилася.
+Scope logic міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби кожна scoped area змінилася.
 
-- **Редагування CI workflow** валідують Node CI graph плюс workflow linting, але самі по собі не змушують Windows, Android або macOS native builds; ці platform lanes лишаються scoped до platform source changes.
-- **CI routing-only edits, вибрані дешеві core-test fixture edits і вузькі plugin contract helper/test-routing edits** використовують швидкий Node-only manifest path: `preflight`, security і одне завдання `checks-fast-core`. Цей path пропускає build artifacts, Node 22 compatibility, channel contracts, full core shards, bundled-plugin shards і additional guard matrices, коли change обмежена routing або helper surfaces, які fast task перевіряє напряму.
-- **Windows Node checks** scoped до Windows-специфічних process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цю lane; непов’язані source, plugin, install-smoke і test-only changes лишаються на Linux Node lanes.
+- **Редагування CI workflow** перевіряють Node CI graph плюс workflow linting, але самі по собі не примушують Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source.
+- **Редагування лише CI routing, вибрані дешеві core-test fixture edits і вузькі plugin contract helper/test-routing edits** використовують швидкий Node-only manifest path: `preflight`, security і одне завдання `checks-fast-core`. Цей path пропускає build artifacts, сумісність із Node 22, channel contracts, повні core shards, bundled-plugin shards і additional guard matrices, коли зміна обмежена routing або helper surfaces, які fast task перевіряє напряму.
+- **Windows Node checks** scoped до специфічних для Windows process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цей lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes.
 
-Найповільніші сімейства Node tests розділено або збалансовано, щоб кожне job лишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, малі core unit lanes поєднано в пари, auto-reply запускається як чотири balanced workers (із розбиттям reply subtree на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/plugin configs розподілено між наявними source-only agentic Node jobs замість очікування built artifacts. Broad browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries із використанням CI shard name, тож `.artifacts/vitest-shard-timings.json` може відрізняти цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої невеликі незалежні guards concurrently в одному job. Gateway watch, channel tests і core support-boundary shard запускаються concurrently всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані.
+Найповільніші сімейства Node tests розділено або збалансовано, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, малі core unit lanes поєднані в пари, auto-reply запускається як чотири збалансовані workers (із розділенням reply subtree на shards agent-runner, dispatch і commands/state-routing), а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries із використанням CI shard name, тому `.artifacts/vitest-shard-timings.json` може відрізняти цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні 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-релевантного push.
+Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor з BuildConfig flags для SMS/call-log, уникаючи дублювання debug APK packaging job для кожного Android-релевантного push.
 
-Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, pinned до найновішої версії Knip, із вимкненим minimum release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip із `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий непереглянутий unused file або лишає застарілий allowlist entry, водночас зберігаючи intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично resolve.
+Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production-прохід Knip лише для dependencies, закріплений на latest Knip version, із вимкненим minimum release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip із `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий непереглянутий unused file або залишає застарілий allowlist entry, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично розв’язати.
 
 ## Manual 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` dispatches окремий workflow `Plugin Prerelease` з увімкненим release-validation gate.
+Manual CI dispatches запускають той самий job graph, що й звичайний CI, але примусово вмикають кожен scoped lane, крім Android: Linux Node shards, bundled-plugin shards, channel contracts, сумісність із Node 22, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS і Control UI i18n. Окремі manual CI dispatches запускають Android лише з `include_android=true`; full release umbrella вмикає Android, передаючи `include_android=true`. Plugin prerelease static checks, release-only shard `agentic-plugins`, повний 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` дає trusted caller змогу запустити цей graph проти branch, tag або full commit SHA, використовуючи workflow file із вибраного dispatch ref.
+Manual runs використовують унікальну concurrency group, тому full suite для release candidate не скасовується іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає змогу trusted caller запускати цей graph для branch, tag або повного commit SHA, використовуючи workflow file з вибраного dispatch ref.
 
 ```bash
 gh workflow run ci.yml --ref release/YYYY.M.D
@@ -79,15 +79,15 @@ gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
 
 ## Runners
 
-| Виконавець                       | Завдання                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
-| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `ubuntu-24.04`                   | `preflight`, швидкі завдання безпеки й агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контрактів/вбудованого пакета, шардовані перевірки контрактів каналів, шарди `check`, окрім lint, шарди й агрегати `check-additional`, агрегатні верифікатори тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує 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 коштували більше, ніж економили); install-smoke Docker-збірки (час очікування в черзі 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; preflight для 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, шарди тестів пакетних плагінів, `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`                                                                                                                                                                                                                                                                                                                                                                                                 |
 
 ## Локальні еквіваленти
 
@@ -115,29 +115,29 @@ 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, package acceptance, наборів release-path Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram lanes. Він також може запускати післяпублікаційний workflow `NPM Telegram Beta E2E`, коли надано специфікацію опублікованого пакета.
+`Full Release Validation` — це ручний парасольковий workflow для "запустити все перед релізом". Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного підтвердження Plugin/пакета/статичних ресурсів/Docker і запускає `OpenClaw Release Checks` для install smoke, приймання пакета, наборів release-path для Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і ліній Telegram. Він також може запустити після публікації workflow `NPM Telegram Beta E2E`, коли надано специфікацію опублікованого пакета.
 
-`release_profile` керує широтою live/provider, що передається в перевірки релізу:
+`release_profile` керує широтою live/provider, яку передають у перевірки релізу:
 
-- `minimum` залишає найшвидші критичні для релізу OpenAI/core lanes.
+- `minimum` залишає найшвидші критичні для релізу лінії OpenAI/core.
 - `stable` додає стабільний набір provider/backend.
-- `full` запускає широку advisory-матрицю provider/media.
+- `full` запускає широку консультативну матрицю provider/media.
 
-Парасольковий workflow записує ідентифікатори запущених дочірніх виконань, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх виконань і додає таблиці найповільніших завдань для кожного дочірнього виконання. Якщо дочірній workflow перезапустили і він став зеленим, перезапустіть лише батьківське завдання verifier, щоб оновити результат парасолькового workflow і підсумок часу.
+Парасолька записує ідентифікатори запущених дочірніх прогонів, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх прогонів і додає таблиці найповільніших завдань для кожного дочірнього прогону. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське завдання-верифікатор, щоб оновити результат парасольки й підсумок часу.
 
-Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для реліз-кандидата, `ci` лише для звичайного дочірнього повного CI, `release-checks` для кожного дочірнього релізного запуску або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольковому workflow. Це утримує повторний запуск невдалого релізного блока в межах після цільового виправлення.
+Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата релізу, `ci` лише для звичайного дочірнього повного CI, `release-checks` для кожної релізної дочірньої перевірки або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольці. Це тримає перезапуск невдалої релізної коробки обмеженим після цільового виправлення.
 
-`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і в live/E2E release-path Docker workflow, і в package acceptance shard. Це зберігає байти пакета узгодженими між релізними блоками й уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
+`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і в Docker workflow live/E2E release-path, і в шард приймання пакета. Це зберігає байти пакета узгодженими між релізними коробками й уникає повторного пакування того самого кандидата в кількох дочірніх завданнях.
 
-## Live та E2E шарди
+## Live і E2E шарди
 
 Дочірній 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 завдання `native-live-src-gateway-profiles`
 - `native-live-src-gateway-backends`
 - `native-live-test`
 - `native-live-extensions-a-k`
@@ -145,57 +145,57 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
 - `native-live-extensions-openai`
 - `native-live-extensions-o-z-other`
 - `native-live-extensions-xai`
-- розділені медіашарди audio/video і provider-filtered music shards
+- розділені шарди медіа аудіо/відео та відфільтровані за provider шарди музики
 
-Це зберігає те саме файлове покриття, водночас роблячи повільні збої 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`; медіазавдання лише перевіряють бінарні файли перед налаштуванням. Тримайте live suites на базі Docker на звичайних Blacksmith runners — контейнерні завдання не підходять для запуску вкладених Docker-тестів.
+Нативні live media шарди запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють бінарні файли перед налаштуванням. Тримайте live-набори з підтримкою Docker на звичайних запускачах Blacksmith — контейнерні завдання є неправильним місцем для запуску вкладених Docker-тестів.
 
-Live model/backend shards на базі Docker використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Live release workflow збирає й публікує цей образ один раз, а потім шарди Docker live model, gateway, CLI backend, ACP bind і Codex harness запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці шарди самостійно перебудовують повну Docker-ціль джерельного коду, релізний запуск налаштовано неправильно, і він марнуватиме настінний час на дубльовані збірки образів.
+Live model/backend шарди з підтримкою Docker використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:<sha>` для кожного вибраного коміту. Live release workflow один раз збирає й публікує цей образ, після чого шарди Docker live model, Gateway, CLI backend, ACP bind і Codex harness запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці шарди самостійно перебудовують повну ціль Docker із джерел, релізний прогін налаштовано неправильно, і він марнуватиме загальний час на дубльовані збірки образів.
 
 ## Приймання пакета
 
-Використовуйте `Package Acceptance`, коли питання таке: «чи працює цей інстальовний пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево джерельного коду, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі задіюють після встановлення або оновлення.
+Використовуйте `Package Acceptance`, коли питання звучить так: "чи працює цей інстальований пакет OpenClaw як продукт?" Це відрізняється від звичайного CI: звичайний CI перевіряє дерево джерел, тоді як приймання пакета перевіряє один tarball через той самий Docker E2E harness, який користувачі запускають після встановлення або оновлення.
 
 ### Завдання
 
-1. `resolve_package` робить checkout `workflow_ref`, визначає одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить джерело, 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 проти цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, багаторазовий workflow готує пакет і спільні образи один раз, а потім розгортає ці lanes як паралельні цільові Docker-завдання з унікальними артефактами.
-3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance його визначив; окремий запуск Telegram усе ще може встановити опубліковану npm-специфікацію.
-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` і друкує джерело, посилання workflow, посилання пакета, версію, SHA-256 та профіль у підсумку кроку GitHub.
+2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker-лінії проти цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow готує пакет і спільні образи один раз, а потім розгортає ці лінії як паралельні цільові Docker-завдання з унікальними артефактами.
+3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance розв’язав його; окремий запуск Telegram усе ще може встановити опубліковану специфікацію npm.
+4. `summary` провалює workflow, якщо розв’язання пакета, Docker-приймання або опційна лінія Telegram зазнали невдачі.
 
 ### Джерела кандидатів
 
-- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, як-от `openclaw@2026.4.27-beta.2`. Використовуйте це для перевірки прийнятності опублікованих beta/stable версій.
-- `source=ref` пакує довірену гілку, тег або повний SHA коміту з `package_ref`. Резолвер отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілки репозиторію або релізного тегу, встановлює залежності у від’єднаному робочому дереві та пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`.
-- `source=url` завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим.
-- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його слід надати для артефактів, що поширюються зовнішньо.
+- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих бета- та стабільних версій.
+- `source=ref` пакує довірену гілку `package_ref`, тег або повний SHA коміту. Розв’язувач отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілки репозиторію або з тегу релізу, встановлює залежності у від’єднаному робочому дереві й пакує його за допомогою `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` — це початковий коміт, який пакується, коли `source=ref`. Це дає змогу поточному тестовому harness перевіряти старіші довірені початкові коміти без запуску старої логіки workflow.
+Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код робочого процесу/тестового оснащення, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточному тестовому оснащенню перевіряти старіші довірені вихідні коміти без запуску старої логіки робочого процесу.
 
 ### Профілі наборів
 
 - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
 - `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update`
 - `product` — `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
-- `full` — повні фрагменти Docker release-path з OpenWebUI
+- `full` — повні Docker-фрагменти шляху релізу з OpenWebUI
 - `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom`
 
-Профіль `package` використовує offline-покриття plugin, щоб перевірка опублікованого пакета не залежала від доступності живого ClawHub. Необов’язкова лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях специфікації опублікованого npm збережено для автономних запусків.
+Профіль `package` використовує офлайн-покриття Plugin, щоб перевірка опублікованого пакета не залежала від доступності ClawHub наживо. Необов’язкова лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації збережено для автономних запусків.
 
-Релізні перевірки викликають Package Acceptance з `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` і `telegram_mode=mock-openai`. Фрагменти Docker release-path покривають перетин ліній package/update/plugin; Package Acceptance зберігає artifact-native перевірку сумісності bundled-channel, offline plugin і Telegram для того самого розв’язаного tarball пакета. Cross-OS релізні перевірки все ще покривають OS-specific onboarding, інсталятор і поведінку платформи; перевірку package/update продукту слід починати з Package Acceptance. Лінії Windows packaged і installer fresh також перевіряють, що встановлений пакет може імпортувати browser-control override із сирого абсолютного шляху Windows. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо задано, інакше `openai/gpt-5.4-mini`, тож доказ встановлення й Gateway залишається швидким і детермінованим.
+Перевірки релізу викликають Package Acceptance із `source=ref`, `package_ref=<release-ref>`, `workflow_ref=<release workflow ref>`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` і `telegram_mode=mock-openai`. Docker-фрагменти шляху релізу покривають перехресні лінії пакета/оновлення/Plugin; Package Acceptance зберігає нативну для артефакта перевірку сумісності вбудованих каналів, офлайн-Plugin і Telegram для того самого розв’язаного tarball пакета. Перевірки релізу для різних ОС усе ще покривають специфічне для ОС первинне налаштування, інсталятор і поведінку платформи; продуктову перевірку пакета/оновлення слід починати з Package Acceptance. Свіжі лінії Windows для запакованого пакета й інсталятора також перевіряють, що встановлений пакет може імпортувати перевизначення керування браузером із сирого абсолютного шляху Windows. Димовий тест агентного ходу OpenAI для різних ОС за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли його задано, інакше `openai/gpt-5.4-mini`, тому перевірка встановлення й Gateway лишається швидкою та детермінованою.
 
-### Вікна сумісності зі спадщиною
+### Вікна сумісності зі старими версіями
 
-Package Acceptance має обмежені вікна сумісності зі спадщиною для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності:
+Package Acceptance має обмежені вікна сумісності зі старими версіями для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності:
 
-- відомі приватні записи QA у `dist/postinstall-inventory.json` можуть вказувати на файли, відсутні в tarball;
+- відомі приватні QA-записи в `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball;
 - `doctor-switch` може пропускати підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець;
-- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` з fake git fixture, отриманої з tarball, і може логувати відсутній збережений `update.channel`;
-- plugin smokes можуть читати застарілі розташування install-record або приймати відсутнє збереження marketplace install-record;
-- `plugin-update` може дозволяти міграцію метаданих конфігурації, водночас усе ще вимагаючи, щоб install record і поведінка без перевстановлення залишалися незмінними.
+- `update-channel-switch` може вилучати відсутні `pnpm.patchedDependencies` із фіктивної git-фікстури, отриманої з tarball, і може журналювати відсутній збережений `update.channel`;
+- димові тести Plugin можуть читати старі розташування записів встановлення або приймати відсутність збереження запису встановлення з маркетплейса;
+- `plugin-update` може дозволяти міграцію метаданих конфігурації, водночас усе ще вимагаючи, щоб запис встановлення та поведінка без перевстановлення лишалися незмінними.
 
-Опублікований пакет `2026.4.26` також може попереджати про файли штампа локальних build metadata, які вже були поставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови завершуються помилкою замість попередження або пропуску.
+Опублікований пакет `2026.4.26` також може попереджати про файли штампів метаданих локальної збірки, які вже були доставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови спричиняють помилку замість попередження або пропуску.
 
 ### Приклади
 
@@ -238,152 +238,152 @@ gh workflow run package-acceptance.yml \
   -f docker_lanes='install-e2e plugin-update'
 ```
 
-Під час налагодження невдалого запуску package acceptance починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, логи ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю package або точних Docker-ліній замість повторного запуску повної релізної перевірки.
+Під час налагодження невдалого запуску приймання пакета починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали ліній, тривалості фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker-ліній замість повторного запуску повної перевірки релізу.
 
-## Install smoke
+## Димовий тест встановлення
 
-Окремий workflow `Install Smoke` повторно використовує той самий скрипт scope через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
+Окремий робочий процес `Install Smoke` повторно використовує той самий скрипт області через власне завдання `preflight`. Він розділяє димове покриття на `run_fast_install_smoke` і `run_full_install_smoke`.
 
-- **Швидкий шлях** запускається для pull request, які торкаються поверхонь Docker/package, змін package/manifest для bundled plugin або поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише початкового коду bundled plugin, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ root Dockerfile, перевіряє CLI, запускає CLI smoke для видалення agents shared-workspace, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним таймаутом команди 240 секунд (кожен Docker run сценарію обмежено окремо).
-- **Повний шлях** зберігає QR package install і Docker/update покриття інсталятора для нічних запланованих запусків, ручних dispatch, workflow-call релізних перевірок і pull request, які справді торкаються поверхонь installer/package/Docker. У 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 як окремі завдання, щоб робота інсталятора не чекала за root image smokes.
+- **Швидкий шлях** запускається для pull request, які зачіпають поверхні Docker/пакета, зміни пакетів/маніфестів вбудованих Plugin або основні поверхні Plugin/каналу/Gateway/Plugin SDK, які перевіряють Docker-димові завдання. Зміни лише вихідного коду вбудованих Plugin, лише тестові правки та правки лише документації не резервують Docker-воркери. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає димовий тест CLI для видалення агентів спільного робочого простору, запускає container gateway-network e2e, перевіряє аргумент збірки вбудованого розширення і запускає обмежений Docker-профіль вбудованих Plugin із 240-секундним сукупним таймаутом команди (кожен Docker-запуск сценарію обмежено окремо).
+- **Повний шлях** зберігає встановлення QR-пакета й Docker/оновлювальне покриття інсталятора для нічних запланованих запусків, ручних запусків, release checks через workflow-call і pull request, які справді зачіпають поверхні інсталятора/пакета/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR-образ кореневого Dockerfile для димового тесту цільового SHA, а потім запускає встановлення QR-пакета, димові тести кореневого Dockerfile/Gateway, димові тести інсталятора/оновлення і швидкий Docker E2E для вбудованих Plugin як окремі завдання, щоб робота інсталятора не чекала за димовими тестами кореневого образу.
 
-Пуші в `main` (включно з merge commits) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття для push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або релізної перевірки.
+Пуші в `main` (зокрема merge-коміти) не примушують повний шлях; коли логіка області змін просила б повне покриття на push, робочий процес зберігає швидкий Docker-димовий тест і залишає повний димовий тест встановлення для нічної або релізної перевірки.
 
-Повільний Bun global install image-provider smoke окремо керується `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow релізних перевірок, а ручні dispatch `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` — ні. QR і installer Docker tests зберігають власні install-focused Dockerfiles.
+Повільний димовий тест Bun global install image-provider окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з робочого процесу release checks, а ручні запуски `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` — ні. QR і Docker-тести інсталятора зберігають власні Dockerfile, зосереджені на встановленні.
 
 ## Локальний Docker E2E
 
-`pnpm test:docker:all` попередньо збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
+`pnpm test:docker:all` попередньо збирає один спільний live-test образ, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`:
 
-- bare Node/Git runner для ліній installer/update/plugin-dependency;
+- базовий Node/Git runner для ліній інсталятора/оновлення/залежностей Plugin;
 - функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній.
 
 Визначення Docker-ліній містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для кожної лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`.
 
-### Налаштування
+### Параметри налаштування
 
-| Змінна                                | За замовчуванням | Призначення                                                                                   |
-| ------------------------------------- | ---------------- | --------------------------------------------------------------------------------------------- |
-| `OPENCLAW_DOCKER_ALL_PARALLELISM`     | 10               | Кількість слотів main-pool для звичайних ліній.                                               |
-| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10               | Кількість слотів tail-pool, чутливого до провайдерів.                                         |
-| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`      | 9                | Ліміт одночасних live-ліній, щоб провайдери не застосовували throttling.                      |
-| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`       | 10               | Ліміт одночасних ліній npm install.                                                           |
-| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`   | 7                | Ліміт одночасних multi-service ліній.                                                         |
-| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000             | Інтервал між стартами ліній, щоб уникнути create storms демона Docker; задайте `0`, щоб вимкнути інтервал. |
-| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000          | Резервний таймаут для кожної лінії (120 хвилин); вибрані live/tail лінії використовують жорсткіші ліміти. |
-| `OPENCLAW_DOCKER_ALL_DRY_RUN`         | unset            | `1` друкує план планувальника без запуску ліній.                                              |
-| `OPENCLAW_DOCKER_ALL_LANES`           | unset            | Розділений комами точний список ліній; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу лінію. |
+| Змінна                                | Типово  | Призначення                                                                                                  |
+| ------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------ |
+| `OPENCLAW_DOCKER_ALL_PARALLELISM`      | 10      | Кількість слотів основного пулу для звичайних ліній.                                                         |
+| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10      | Кількість слотів хвостового пулу для чутливих до провайдерів ліній.                                          |
+| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT`       | 9       | Обмеження одночасних live-ліній, щоб провайдери не застосовували throttling.                                 |
+| `OPENCLAW_DOCKER_ALL_NPM_LIMIT`        | 10      | Обмеження одночасних ліній встановлення npm.                                                                 |
+| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT`    | 7       | Обмеження одночасних багатосервісних ліній.                                                                  |
+| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000    | Затримка між стартами ліній, щоб уникати штормів створення в Docker daemon; задайте `0`, щоб вимкнути її.    |
+| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`  | 7200000 | Резервний таймаут для кожної лінії (120 хвилин); вибрані live/tail лінії використовують жорсткіші обмеження. |
+| `OPENCLAW_DOCKER_ALL_DRY_RUN`          | unset   | `1` виводить план планувальника без запуску ліній.                                                           |
+| `OPENCLAW_DOCKER_ALL_LANES`            | unset   | Розділений комами точний список ліній; пропускає димове очищення, щоб агенти могли відтворити одну невдалу лінію. |
 
-Лінія, важча за її ефективний ліміт, усе ще може стартувати з порожнього pool, а потім працює сама, доки не звільнить місткість. Локальний сукупний запуск попередньо перевіряє Docker, видаляє застарілі контейнери OpenClaw E2E, виводить статус активних ліній, зберігає таймінги ліній для впорядкування від найдовших і за замовчуванням припиняє планувати нові pooled lanes після першої помилки.
+Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальна сукупна перевірка спершу перевіряє Docker, видаляє застарілі OpenClaw E2E контейнери, виводить статус активних ліній, зберігає тривалості ліній для впорядкування від найдовших і за замовчуванням припиняє планування нових pooled ліній після першої помилки.
 
-### Багаторазовий live/E2E workflow
+### Перевикористовуваний live/E2E робочий процес
 
-Багаторазовий live/E2E workflow запитує `scripts/test-docker-all.mjs --plan-json`, які package, image kind, live image, lane і credential coverage потрібні. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє inventory tarball; збирає й пушить package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли план потребує ліній із встановленим пакетом; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість повторної збірки. Pull Docker images повторюються з обмеженим 180-секундним таймаутом на спробу, щоб завислий registry/cache stream швидко повторювався замість споживання більшої частини критичного шляху CI.
+Перевикористовуваний live/E2E робочий процес запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, лінії та облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub-виводи й зведення. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета з поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає й публікує до GHCR bare/functional Docker E2E образи з тегом digest пакета через кеш Docker-шарів Blacksmith, коли план потребує ліній зі встановленим пакетом; і повторно використовує надані входи `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні образи з digest пакета замість перебудови. Завантаження Docker-образів повторюються з обмеженим 180-секундним таймаутом на спробу, щоб завислий потік реєстру/кешу швидко повторився, а не споживав більшу частину критичного шляху CI.
 
-### Фрагменти release-path
+### Фрагменти шляху релізу
 
-Релізне Docker-покриття запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен фрагмент тягнув лише потрібний йому тип образу й виконував кілька ліній через той самий зважений планувальник:
+Релізне Docker-покриття запускає менші фрагментовані завдання з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен фрагмент завантажував лише потрібний йому тип образу й виконував кілька ліній через той самий зважений планувальник:
 
 - `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
 - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | bundled-channels`
 
-Поточні Docker-фрагменти релізу: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, `plugins-runtime-install-a` до `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` і `bundled-channels-contracts`. Агрегований фрагмент `bundled-channels` залишається доступним для ручних одноразових повторних запусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими псевдонімами plugin/runtime. Псевдонім лінії `install-e2e` залишається агрегованим ручним псевдонімом повторного запуску для обох ліній інсталяторів провайдерів. Фрагмент `bundled-channels` запускає розділені лінії `bundled-channel-*` і `bundled-channel-update-*` замість послідовної лінії «усе-в-одному» `bundled-channel-deps`.
+Поточні Docker-фрагменти релізу: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services`, від `plugins-runtime-install-a` до `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` і `bundled-channels-contracts`. Агрегований фрагмент `bundled-channels` залишається доступним для ручних одноразових повторних запусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими псевдонімами Plugin/середовища виконання. Псевдонім смуги `install-e2e` залишається агрегованим псевдонімом ручного повторного запуску для обох смуг інсталяторів провайдерів. Фрагмент `bundled-channels` запускає розділені смуги `bundled-channel-*` і `bundled-channel-update-*`, а не послідовну універсальну смугу `bundled-channel-deps`.
 
-OpenWebUI включається в `plugins-runtime-services`, коли повне покриття шляху релізу цього потребує, і зберігає окремий фрагмент `openwebui` лише для диспетчеризацій, що стосуються тільки OpenWebUI. Лінії оновлення bundled-channel повторюють спробу один раз у разі тимчасових мережевих збоїв npm.
+OpenWebUI включається до `plugins-runtime-services`, коли повне покриття шляху релізу цього вимагає, і зберігає окремий фрагмент `openwebui` лише для dispatch-запусків, призначених тільки для OpenWebUI. Смуги оновлення bundled-channel виконують одну повторну спробу в разі тимчасових мережевих збоїв npm.
 
-Кожен фрагмент завантажує `.artifacts/docker-tests/` із журналами ліній, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Вхід workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість завдань фрагментів, що обмежує налагодження збійної лінії одним цільовим Docker-завданням і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана лінія є live Docker-лінією, цільове завдання локально збирає образ live-test для цього повторного запуску. Згенеровані команди GitHub для повторного запуску кожної лінії містять `package_artifact_run_id`, `package_artifact_name` і входи підготовлених образів, коли ці значення існують, тож збійна лінія може повторно використати точний пакет і образи зі збійного запуску.
+Кожен фрагмент завантажує `.artifacts/docker-tests/` із журналами смуг, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних смуг і командами повторного запуску для кожної смуги. Вхід `docker_lanes` workflow запускає вибрані смуги проти підготовлених образів замість завдань фрагментів, що обмежує налагодження збійної смуги одним цільовим Docker-завданням і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана смуга є live Docker-смугою, цільове завдання локально збирає образ live-test для цього повторного запуску. Згенеровані команди GitHub для повторного запуску кожної смуги включають `package_artifact_run_id`, `package_artifact_name` і входи підготовлених образів, коли ці значення існують, тож збійна смуга може повторно використати точний пакет і образи зі збійного запуску.
 
 ```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
+pnpm test:docker:rerun <run-id>      # завантажити Docker-артефакти та вивести об'єднані/посмугові цільові команди повторного запуску
+pnpm test:docker:timings <summary>   # зведення повільних смуг і критичного шляху фаз
 ```
 
 Запланований live/E2E workflow щодня запускає повний Docker-набір шляху релізу.
 
 ## Попередній реліз Plugin
 
-`Plugin Prerelease` є дорожчим покриттям продукту/пакета, тому це окремий workflow, який запускається `Full Release Validation` або явно оператором. Звичайні pull request, пуші в `main` і самостійні ручні CI-диспетчеризації тримають цей набір вимкненим. Він балансує тести bundled plugin між вісьмома extension-воркерами; ці завдання extension-шардів запускають до двох груп конфігурації plugin одночасно з одним Vitest-воркером на групу та більшим Node heap, щоб насичені імпортами пакети plugin не створювали додаткових CI-завдань.
+`Plugin Prerelease` є дорожчим покриттям продукту/пакета, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push до `main` і самостійні ручні CI dispatch-запуски залишають цей набір вимкненим. Він балансує тести bundled Plugin між вісьмома extension workers; ці завдання extension shard запускають до двох груп конфігурації Plugin одночасно з одним Vitest worker на групу та більшим heap Node, щоб насичені імпортами пакети Plugin не створювали додаткових CI-завдань.
 
-## QA Lab
+## Лабораторія QA
 
-QA Lab має виділені CI-лінії поза основним smart-scoped workflow.
+Лабораторія QA має спеціальні CI-смуги поза основним smart-scoped workflow.
 
-- Workflow `Parity gate` запускається на відповідних змінах PR і ручній диспетчеризації; він збирає приватний QA runtime і порівнює mock GPT-5.5 та Opus 4.6 agentic packs.
-- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і за ручною диспетчеризацією; він розгалужує mock parity gate, live Matrix-лінію, а також live Telegram і Discord-лінії як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex-оренди.
+- Workflow `Parity gate` запускається за відповідних змін у PR і ручного dispatch; він збирає приватне середовище виконання QA та порівнює агентні пакети mock GPT-5.5 і Opus 4.6.
+- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і за ручного dispatch; він розгалужує mock parity gate, live Matrix-смугу та live Telegram і Discord смуги як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а Telegram/Discord використовують lease-и Convex.
 
-Перевірки релізу запускають live транспортні лінії Matrix і Telegram із детермінованим mock-провайдером і mock-кваліфікованими моделями (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live-моделі та звичайного запуску provider-plugin. Live transport gateway вимикає пошук пам’яті, оскільки QA parity окремо покриває поведінку пам’яті; підключення провайдера покривається окремими наборами live model, native provider і Docker provider.
+Перевірки релізу запускають live transport-смуги Matrix і Telegram з детермінованим mock-провайдером і mock-кваліфікованими моделями (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live-моделі та звичайного запуску provider-plugin. Live transport Gateway вимикає пошук пам'яті, оскільки parity QA окремо покриває поведінку пам'яті; з'єднання з провайдером покриваються окремими наборами live model, native provider і Docker provider.
 
-Matrix використовує `--profile fast` для запланованих і релізних gates, додаючи `--fail-fast` лише тоді, коли checked-out CLI це підтримує. Типове значення CLI і ручний вхід workflow залишаються `all`; ручна диспетчеризація `matrix_profile=all` завжди розбиває повне покриття Matrix на завдання `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
+Matrix використовує `--profile fast` для запланованих перевірок і release gates, додаючи `--fail-fast` лише тоді, коли checked-out CLI це підтримує. Типове значення CLI і вхід manual workflow залишаються `all`; ручний dispatch `matrix_profile=all` завжди розділяє повне покриття Matrix на завдання `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`.
 
-`OpenClaw Release Checks` також запускає критичні для релізу QA Lab-лінії перед схваленням релізу; його QA parity gate запускає candidate і baseline packs як паралельні завдання ліній, а потім завантажує обидва артефакти в невелике звітне завдання для фінального порівняння parity.
+`OpenClaw Release Checks` також запускає критичні для релізу смуги QA Lab перед затвердженням релізу; його QA parity gate запускає candidate і baseline пакети як паралельні завдання смуг, а потім завантажує обидва артефакти в невелике звітне завдання для фінального порівняння parity.
 
-Не ставте шлях landing PR за `Parity gate`, якщо зміна фактично не зачіпає QA runtime, parity model-pack або поверхню, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-test розглядайте це як необов’язковий сигнал і спирайтеся на scoped CI/check докази.
+Не ставте шлях landing для PR за `Parity gate`, якщо зміна фактично не торкається середовища виконання QA, parity model-pack або поверхні, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-test вважайте це необов'язковим сигналом і натомість дотримуйтеся scoped CI/check evidence.
 
 ## CodeQL
 
-Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним скануванням репозиторію. Щоденні, ручні та non-draft guard-запуски pull request сканують код Actions workflow разом із JavaScript/TypeScript-поверхнями найвищого ризику, використовуючи high-confidence security queries, відфільтровані до high/critical `security-severity`.
+Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним скануванням репозиторію. Щоденні, ручні та guard-запуски для non-draft pull request сканують код Actions workflow плюс JavaScript/TypeScript-поверхні найвищого ризику з high-confidence security-запитами, відфільтрованими до high/critical `security-severity`.
 
-Guard pull request залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security matrix, що й запланований workflow. Android і macOS CodeQL не входять до типових PR-запусків.
+Guard для pull request залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security-матрицю, що й запланований workflow. Android і macOS CodeQL залишаються поза типовими PR-перевірками.
 
 ### Категорії безпеки
 
 | Категорія                                         | Поверхня                                                                                                                               |
 | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-| `/codeql-security-high/core-auth-secrets`         | Auth, secrets, sandbox, cron і базова лінія gateway                                                                                    |
-| `/codeql-security-high/channel-runtime-boundary`  | Контракти реалізації core channel плюс channel plugin runtime, gateway, Plugin SDK, secrets, audit touchpoints                        |
-| `/codeql-security-high/network-ssrf-boundary`     | Поверхні Core SSRF, розбору IP, network guard, web-fetch і політики SSRF Plugin SDK                                                    |
-| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, process execution helpers, outbound delivery і gates виконання інструментів агента                                       |
-| `/codeql-security-high/plugin-trust-boundary`     | Поверхні довіри для Plugin install, loader, manifest, registry, staging runtime-dependency, source-loading і package contract Plugin SDK |
+| `/codeql-security-high/core-auth-secrets`         | Базовий рівень auth, secrets, sandbox, cron і gateway                                                                                  |
+| `/codeql-security-high/channel-runtime-boundary`  | Контракти реалізації core channel плюс середовище виконання channel plugin, gateway, Plugin SDK, secrets, audit touchpoints            |
+| `/codeql-security-high/network-ssrf-boundary`     | Поверхні політики SSRF для core SSRF, розбору IP, network guard, web-fetch і Plugin SDK                                                |
+| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, допоміжні засоби виконання процесів, outbound delivery і gates виконання інструментів агентом                             |
+| `/codeql-security-high/plugin-trust-boundary`     | Поверхні довіри для встановлення Plugin, loader, manifest, registry, staging runtime-dependency, source-loading і контракту пакета Plugin SDK |
 
-### Платформоспецифічні security shards
+### Платформо-специфічні security shards
 
-- `CodeQL Android Critical Security` — запланований security shard Android. Збирає Android app вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує під `/codeql-critical-security/android`.
-- `CodeQL macOS Critical Security` — щотижневий/ручний security shard macOS. Збирає macOS app вручну для CodeQL на Blacksmith macOS, відфільтровує результати збірки залежностей із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Тримається поза щоденними типовими запуском, бо збірка macOS домінує за runtime навіть у чистому стані.
+- `CodeQL Android Critical Security` — запланований Android security shard. Збирає Android-застосунок вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує під `/codeql-critical-security/android`.
+- `CodeQL macOS Critical Security` — щотижневий/ручний macOS security shard. Збирає macOS-застосунок вручну для CodeQL на Blacksmith macOS, відфільтровує результати збірки залежностей із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Залишається поза щоденними типовими перевірками, бо збірка macOS домінує час виконання навіть у чистому стані.
 
-### Категорії Critical Quality
+### Категорії критичної якості
 
-`CodeQL Critical Quality` є відповідним non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його guard pull request навмисно менший за запланований профіль: non-draft PR запускають лише відповідні shards `channel-runtime-boundary`, `gateway-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін channel runtime, gateway protocol/server-method, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, package-contract Plugin SDK або reply runtime Plugin SDK. Зміни конфігурації CodeQL і quality workflow запускають усі вісім PR quality shards.
+`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality-запити над вузькими високовартісними поверхнями на меншому Blacksmith Linux runner. Його guard для pull request навмисно менший за запланований профіль: non-draft PR запускають лише відповідні shards `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` для змін у channel 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 або Plugin SDK reply runtime. Зміни конфігурації CodeQL і quality workflow запускають усі дев'ять PR quality shards.
 
-Ручна диспетчеризація приймає:
+Ручний dispatch приймає:
 
 ```
-profile=all|channel-runtime-boundary|gateway-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
+profile=all|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
 ```
 
-Вузькі профілі є teaching/iteration hooks для запуску одного quality shard ізольовано.
+Вузькі профілі — це 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`     | Контракти реалізації каналів ядра                                                                                                                                                |
-| `/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/розбиття на chunks/runtime для відповідей, параметри відповідей каналів, черги доставки та помічники прив’язки сесій/тредів |
-| `/codeql-critical-quality/provider-runtime-boundary`    | Нормалізація каталогу моделей, автентифікація та виявлення провайдерів, реєстрація runtime провайдерів, стандартні параметри/каталоги провайдерів і реєстри web/search/fetch/embedding |
-| `/codeql-critical-quality/ui-control-plane`             | Bootstrap Control UI, локальне збереження, потоки керування Gateway і runtime-контракти площини керування завданнями                                                             |
-| `/codeql-critical-quality/web-media-runtime-boundary`   | Контракти runtime для core web fetch/search, media IO, media understanding, image-generation і media-generation                                                                  |
-| `/codeql-critical-quality/plugin-boundary`              | Контракти loader, registry, public-surface і 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`              | Схема конфігурації, міграція, нормалізація та контракти IO                                                                                                         |
+| `/codeql-critical-quality/gateway-runtime-boundary`     | Схеми протоколу Gateway і контракти методів сервера                                                                                                              |
+| `/codeql-critical-quality/channel-runtime-boundary`     | Контракти реалізації основних каналів                                                                                                                             |
+| `/codeql-critical-quality/agent-runtime-boundary`       | Виконання команд, диспетчеризація моделі/провайдера, диспетчеризація автовідповідей і черги, а також контракти середовища виконання площини керування ACP                                               |
+| `/codeql-critical-quality/mcp-process-runtime-boundary` | Сервери MCP і мости інструментів, допоміжні засоби нагляду за процесами та контракти вихідної доставки                                                                        |
+| `/codeql-critical-quality/memory-runtime-boundary`      | SDK хоста пам’яті, фасади середовища виконання пам’яті, псевдоніми SDK Plugin пам’яті, зв’язувальний код активації середовища виконання пам’яті та команди doctor для пам’яті                                    |
+| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішня логіка черги відповідей, черги доставки сеансів, допоміжні засоби прив’язування/доставки вихідних сеансів, поверхні діагностичних подій/пакетів журналів і контракти CLI doctor для сеансів |
+| `/codeql-critical-quality/plugin-sdk-reply-runtime`     | Диспетчеризація вхідних відповідей SDK Plugin, допоміжні засоби для payload/chunking/runtime відповідей, параметри відповідей каналів, черги доставки та допоміжні засоби прив’язування сеансів/потоків             |
+| `/codeql-critical-quality/provider-runtime-boundary`    | Нормалізація каталогу моделей, автентифікація та виявлення провайдерів, реєстрація середовища виконання провайдерів, типові параметри/каталоги провайдерів і реєстри web/search/fetch/embedding    |
+| `/codeql-critical-quality/ui-control-plane`             | Початкове завантаження Control UI, локальне збереження, потоки керування Gateway і контракти середовища виконання площини керування завданнями                                                          |
+| `/codeql-critical-quality/web-media-runtime-boundary`   | Контракти середовища виконання для основних web fetch/search, media IO, розуміння медіа, генерації зображень і генерації медіа                                                    |
+| `/codeql-critical-quality/plugin-boundary`              | Контракти завантажувача, реєстру, публічної поверхні та точок входу SDK Plugin                                                                                             |
+| `/codeql-critical-quality/plugin-sdk-package-contract`  | Опубліковане джерело SDK Plugin на боці пакета та допоміжні засоби контракту пакета plugin                                                                                      |
 
-Якість лишається відокремленою від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як обмежену за scope або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал.
+Якість залишається окремою від безпеки, щоб знахідки щодо якості можна було планувати, вимірювати, вимикати або розширювати без розмивання сигналу безпеки. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як обмежену за областю або розшардовану подальшу роботу лише після того, як вузькі профілі матимуть стабільне середовище виконання та сигнал.
 
-## Робочі процеси підтримки
+## Робочі процеси обслуговування
 
 ### Docs Agent
 
-Робочий процес `Docs Agent` — це подієво-керована лінія підтримки Codex для підтримання наявної документації узгодженою з нещодавно внесеними змінами. Він не має чистого розкладу: успішний CI-запуск push від не-бота на `main` може його запустити, а ручний dispatch може запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли інший непропущений запуск Docs Agent було створено протягом останньої години. Коли він виконується, він переглядає діапазон комітів від попереднього непропущеного source SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з часу останнього проходу документації.
+Робочий процес `Docs Agent` — це подієво керована лінія обслуговування Codex для підтримання узгодженості наявної документації з нещодавно внесеними змінами. Він не має суто розкладу: успішний CI-запуск після push не від бота на `main` може його запустити, а ручний dispatch може запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли інший непропущений запуск Docs Agent було створено протягом останньої години. Коли він виконується, він переглядає діапазон комітів від попереднього непропущеного вихідного SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені з останнього проходу документації.
 
 ### Test Performance Agent
 
-Робочий процес `Test Performance Agent` — це подієво-керована лінія підтримки Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск push від не-бота на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже виконувався або виконується цього UTC-дня. Ручний dispatch обходить цей денний gate активності. Лінія будує згрупований звіт продуктивності Vitest для повного набору, дозволяє Codex вносити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт повного набору й відхиляє зміни, які зменшують базову кількість успішних тестів. Якщо в baseline є тести, що падають, Codex може виправляти лише очевидні збої, а звіт повного набору після агента має пройти, перш ніж щось буде закомічено. Коли `main` просувається вперед до того, як bot push потрапить у репозиторій, лінія rebases валідований patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patches пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати таку саму безпечну позицію drop-sudo, як і docs agent.
+Робочий процес `Test Performance Agent` — це подієво керована лінія обслуговування Codex для повільних тестів. Він не має суто розкладу: успішний CI-запуск після push не від бота на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже виконувався або виконується цього UTC-дня. Ручний dispatch обходить цей денний шлюз активності. Лінія будує згрупований звіт продуктивності Vitest для повного набору тестів, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт для повного набору тестів і відхиляє зміни, які зменшують базову кількість прохідних тестів. Якщо в базовому стані є тести, що падають, Codex може виправляти лише очевидні збої, а звіт повного набору після агента має пройти перед будь-яким комітом. Коли `main` просувається до того, як bot push буде внесено, лінія rebase-ить перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patch пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб action Codex міг зберігати ту саму безпечну позицію drop-sudo, що й docs agent.
 
 ### Дублікати PR після merge
 
-Робочий процес `Duplicate PRs After Merge` — це ручний maintainer workflow для очищення дублікатів після land. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR змарджено, і що кожен дублікат має або спільне referenced issue, або перетин змінених hunks.
+Робочий процес `Duplicate PRs After Merge` — це ручний робочий процес maintainer для очищення дублікатів після внесення. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед зміною GitHub він перевіряє, що внесений PR змержено і що кожен дублікат має або спільне згадане issue, або перетин змінених hunks.
 
 ```bash
 gh workflow run duplicate-after-merge.yml \
@@ -392,27 +392,27 @@ gh workflow run duplicate-after-merge.yml \
   -f apply=true
 ```
 
-## Локальні check gates і changed routing
+## Локальні шлюзи перевірок і маршрутизація змін
 
-Локальна логіка changed-lane живе в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий scope CI-платформи:
+Локальна логіка changed-lane живе в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей локальний шлюз перевірки суворіший щодо архітектурних меж, ніж широка область платформи CI:
 
-- зміни production-коду ядра запускають core prod і core test typecheck плюс core lint/guards;
-- зміни лише тестів ядра запускають тільки core test typecheck плюс core lint;
-- зміни production-коду extension запускають extension prod і extension test typecheck плюс extension lint;
-- зміни лише тестів extension запускають extension test typecheck плюс extension lint;
-- зміни публічного Plugin SDK або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core-контрактів (Vitest sweeps для extension лишаються явною тестовою роботою);
+- зміни production-коду core запускають typecheck core prod і core test плюс core lint/guards;
+- зміни лише тестів core запускають тільки typecheck core test плюс core lint;
+- зміни production-коду extension запускають typecheck extension prod і extension test плюс extension lint;
+- зміни лише тестів extension запускають typecheck extension test плюс extension lint;
+- зміни публічного SDK Plugin або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих контрактів core (прогони Vitest extension залишаються явною тестовою роботою);
 - version bumps лише release metadata запускають цільові перевірки version/config/root-dependency;
 - невідомі зміни root/config fail safe до всіх check lanes.
 
-Локальний changed-test routing живе в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі зміни тестів запускають самі себе, зміни source віддають перевагу явним mappings, потім sibling tests і import-graph dependents. Конфігурація shared group-room delivery є одним із явних mappings: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс регресії доставки Discord і Slack, щоб зміна shared default падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна достатньо harness-wide, що дешевий mapped set не є надійним proxy.
+Локальна маршрутизація changed-test живе в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі редагування тестів запускають самі себе, редагування джерел віддають перевагу явним мапінгам, потім sibling tests і залежним від import-graph. Конфігурація доставки shared group-room є одним із явних мапінгів: зміни до конфігурації видимих відповідей групи, режиму доставки відповідей з джерела або системного prompt для message-tool маршрутизуються через основні тести відповідей плюс регресії доставки Discord і Slack, щоб зміна shared default падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна настільки широка для harness, що дешевий mapped set не є надійним proxy.
 
 ## Валідація Testbox
 
-Запускайте Testbox з кореня репозиторію й віддавайте перевагу свіжому прогрітому box для широкого proof. Перед тим як витрачати повільний gate на box, який повторно використовувався, протермінувався або щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` всередині box.
+Запускайте Testbox з кореня repo і для широкого proof віддавайте перевагу свіжому прогрітому box. Перед тим як витрачати повільний gate на box, який повторно використано, строк дії якого минув або який щойно повідомив про неочікувано велику синхронізацію, спершу запустіть `pnpm testbox:sanity` всередині box.
 
-Sanity check швидко падає, коли потрібні root-файли, такі як `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що стан remote sync не є надійною копією PR; зупиніть цей box і прогрійте новий замість налагодження збою product test. Для навмисних PR із великими deletion задайте `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 понад п’ять хвилин без output після sync. Задайте `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше значення в мілісекундах для незвично великих локальних diffs.
+`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі sync понад п’ять хвилин без post-sync output. Встановіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше значення в мілісекундах для незвично великих локальних diff.
 
 ## Пов’язане