chore(i18n): refresh uk translations

docs/uk/ci.md

@@ -1,76 +1,77 @@
 ---
 read_when:
     - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося
-    - Ви налагоджуєте перевірки GitHub Actions, що завершуються з помилкою
-summary: Граф завдань CI, перевірки за охопленням і локальні еквіваленти команд
+    - Ви налагоджуєте збої перевірок GitHub Actions
+summary: Граф завдань CI, обмежувальні перевірки за областю змін і локальні еквіваленти команд
 title: Конвеєр CI
 x-i18n:
-    generated_at: "2026-04-20T12:57:36Z"
+    generated_at: "2026-04-20T14:13:25Z"
     model: gpt-5.4
     provider: openai
-    source_hash: b128a0112dbaa6449b4f2ace018939f552f99929044732d18d5bea8b46695815
+    source_hash: dd4ffb6986739ee6f4fca6e8b1f40baee7e47a8387e8d06c722881ebe78b4766
     source_path: ci.md
     workflow: 15
 ---
 
 # Конвеєр CI
 
-CI запускається для кожного push у `main` і для кожного pull request. Він використовує розумне визначення охоплення, щоб пропускати дорогі завдання, коли змінювалися лише не пов’язані ділянки.
+CI запускається для кожного push до `main` і для кожного pull request. Він використовує розумне обмеження за областю змін, щоб пропускати дорогі завдання, коли змінено лише непов’язані частини.
 
 ## Огляд завдань
 
-| Завдання                 | Призначення                                                                            | Коли запускається                   |
-| ------------------------ | -------------------------------------------------------------------------------------- | ----------------------------------- |
-| `preflight`              | Визначає зміни лише в документації, змінені охоплення, змінені розширення та збирає маніфест CI | Завжди для push і PR, що не є draft |
-| `security-fast`          | Виявлення приватних ключів, аудит workflow через `zizmor`, аудит production-залежностей | Завжди для push і PR, що не є draft |
-| `build-artifacts`        | Збирає `dist/` і Control UI один раз, завантажує повторно використовувані артефакти для наступних завдань | Зміни, релевантні для Node          |
-| `checks-fast-core`       | Швидкі Linux-етапи перевірки коректності, як-от bundled/plugin-contract/protocol checks | Зміни, релевантні для Node          |
-| `checks-node-extensions` | Повні шарди тестів bundled-plugin для набору розширень                                 | Зміни, релевантні для Node          |
-| `checks-node-core-test`  | Шарди тестів core Node, за винятком channel-, bundled-, contract- і extension-етапів  | Зміни, релевантні для Node          |
-| `extension-fast`         | Цільові тести лише для змінених bundled plugins                                        | Коли виявлено зміни розширень       |
-| `check`                  | Основний локальний gate у CI: `pnpm check` плюс `pnpm build:strict-smoke`              | Зміни, релевантні для Node          |
-| `check-additional`       | Захисти архітектури, меж, циклів імпорту плюс regression harness для gateway watch     | Зміни, релевантні для Node          |
-| `build-smoke`            | Smoke-тести зібраного CLI та smoke-тест пам’яті під час запуску                        | Зміни, релевантні для Node          |
-| `checks`                 | Решта Linux Node-етапів: тести каналів і сумісність Node 22 лише для push              | Зміни, релевантні для Node          |
-| `check-docs`             | Форматування документації, lint і перевірки битих посилань                             | Документацію змінено                |
-| `skills-python`          | Ruff + pytest для Skills на основі Python                                              | Зміни, релевантні для Python Skills |
-| `checks-windows`         | Специфічні для Windows етапи тестування                                                | Зміни, релевантні для Windows       |
-| `macos-node`             | Етап тестів TypeScript на macOS із використанням спільних зібраних артефактів          | Зміни, релевантні для macOS         |
-| `macos-swift`            | Lint, збірка й тести Swift для застосунку macOS                                        | Зміни, релевантні для macOS         |
-| `android`                | Матриця збірки й тестування Android                                                    | Зміни, релевантні для Android       |
+| Завдання                 | Призначення                                                                               | Коли запускається                    |
+| ------------------------ | ----------------------------------------------------------------------------------------- | ------------------------------------ |
+| `preflight`              | Визначає зміни лише в документації, змінені області, змінені розширення та збирає маніфест CI | Завжди для push і PR, що не є draft  |
+| `security-fast`          | Виявлення приватних ключів, аудит workflow через `zizmor`, аудит production-залежностей   | Завжди для push і PR, що не є draft  |
+| `build-artifacts`        | Збирає `dist/` і Control UI один раз, завантажує повторно використовувані артефакти для downstream-завдань | Зміни, релевантні для Node           |
+| `checks-fast-core`       | Швидкі Linux-перевірки коректності, як-от bundled/plugin-contract/protocol checks         | Зміни, релевантні для Node           |
+| `checks-node-extensions` | Повні шарди тестів bundled-plugin для всього набору розширень                             | Зміни, релевантні для Node           |
+| `checks-node-core-test`  | Шарди основних Node-тестів, без channel, bundled, contract і extension-ланів              | Зміни, релевантні для Node           |
+| `extension-fast`         | Сфокусовані тести лише для змінених bundled plugins                                       | Коли виявлено зміни розширень        |
+| `check`                  | Основна локальна перевірка в CI: `pnpm check`, `pnpm check:test-types` і `pnpm build:strict-smoke` | Зміни, релевантні для Node           |
+| `check-additional`       | Перевірки архітектури, меж, циклів імпорту, а також regression harness для gateway watch  | Зміни, релевантні для Node           |
+| `build-smoke`            | Smoke-тести зібраного CLI та smoke-тест пам’яті під час запуску                           | Зміни, релевантні для Node           |
+| `checks`                 | Решта Linux Node-ланів: channel-тести та сумісність лише для push з Node 22               | Зміни, релевантні для Node           |
+| `check-docs`             | Форматування документації, lint і перевірки битих посилань                                | Документацію змінено                 |
+| `skills-python`          | Ruff + pytest для Skills на Python                                                        | Зміни, релевантні для Python Skills  |
+| `checks-windows`         | Специфічні для Windows тестові лани                                                       | Зміни, релевантні для Windows        |
+| `macos-node`             | Лан тестів TypeScript на macOS із використанням спільних зібраних артефактів              | Зміни, релевантні для macOS          |
+| `macos-swift`            | Swift lint, збірка та тести для застосунку macOS                                          | Зміни, релевантні для macOS          |
+| `android`                | Матриця збірки й тестів Android                                                           | Зміни, релевантні для Android        |
 
 ## Порядок Fail-Fast
 
 Завдання впорядковані так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запустяться дорогі:
 
-1. `preflight` визначає, які етапи взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
-2. `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою, не чекаючи важчих завдань із артефактами та платформними матрицями.
-3. `build-artifacts` виконується паралельно зі швидкими Linux-етапами, щоб наступні споживачі могли почати роботу, щойно буде готова спільна збірка.
-4. Після цього розгалужуються важчі платформні та runtime-етапи: `checks-fast-core`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
+1. `preflight` вирішує, які лани взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання.
+2. `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою, не чекаючи важчих завдань з артефактами та матрицями платформ.
+3. `build-artifacts` виконується паралельно зі швидкими Linux-ланами, щоб downstream-споживачі могли почати роботу, щойно буде готова спільна збірка.
+4. Після цього розгалужуються важчі платформні та runtime-лани: `checks-fast-core`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`.
 
-Логіка охоплення розташована в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`.
-Окремий workflow `install-smoke` повторно використовує той самий скрипт охоплення через власне завдання `preflight`. Він обчислює `run_install_smoke` із вужчого сигналу changed-smoke, тому Docker/install smoke запускається лише для змін, пов’язаних із встановленням, пакуванням і контейнерами.
+Логіка обмеження за областю змін знаходиться в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`.
+Окремий workflow `install-smoke` повторно використовує той самий скрипт областей через власне завдання `preflight`. Він обчислює `run_install_smoke` на основі вужчого сигналу `changed-smoke`, тому Docker/install smoke запускається лише для змін, пов’язаних зі встановленням, пакуванням і контейнерами.
 
-Для push матриця `checks` додає етап `compat-node22`, який виконується лише для push. Для pull request цей етап пропускається, і матриця залишається зосередженою на звичайних test/channel-етапах.
+Для push матриця `checks` додає лан `compat-node22`, який запускається лише для push. Для pull request цей лан пропускається, і матриця зосереджується на звичайних тестових/channel-ланах.
 
-## Runner-и
+## Runners
 
-| Runner                           | Завдання                                                                                               |
-| -------------------------------- | ------------------------------------------------------------------------------------------------------ |
+| Runner                           | Завдання                                                                                             |
+| -------------------------------- | ---------------------------------------------------------------------------------------------------- |
 | `blacksmith-16vcpu-ubuntu-2404`  | `preflight`, `security-fast`, `build-artifacts`, Linux-перевірки, перевірки документації, Python Skills, `android` |
-| `blacksmith-32vcpu-windows-2025` | `checks-windows`                                                                                       |
-| `macos-latest`                   | `macos-node`, `macos-swift`                                                                            |
+| `blacksmith-32vcpu-windows-2025` | `checks-windows`                                                                                     |
+| `macos-latest`                   | `macos-node`, `macos-swift`                                                                          |
 
 ## Локальні еквіваленти
 
 ```bash
-pnpm check          # швидкий локальний gate: tsgo з project references + sharded lint + паралельні швидкі захисти
-pnpm check:timed    # той самий gate із таймінгами по етапах
+pnpm check          # швидка локальна перевірка: production tsgo + шардований lint + паралельні швидкі перевірки
+pnpm check:test-types
+pnpm check:timed    # та сама перевірка з помітками часу для кожного етапу
 pnpm build:strict-smoke
 pnpm check:architecture
 pnpm test:gateway:watch-regression
-pnpm test           # тести vitest
+pnpm test           # vitest-тести
 pnpm test:channels
 pnpm check:docs     # форматування документації + lint + биті посилання
-pnpm build          # збірка dist, коли важливі етапи CI artifact/build-smoke
+pnpm build          # збірка dist, коли важливі CI-лани artifact/build-smoke
 ```

docs/uk/reference/RELEASING.md

@@ -1,14 +1,14 @@
 ---
 read_when:
-    - Шукаю визначення публічних каналів випусків
-    - Шукаю іменування версій і частоту випусків
-summary: Публічні канали випусків, іменування версій і частота випусків
+    - Шукаєте визначення публічних каналів випусків
+    - Шукаєте назви версій і частоту випусків
+summary: Публічні канали випусків, назви версій і частота випусків
 title: Політика випусків
 x-i18n:
-    generated_at: "2026-04-20T12:31:53Z"
+    generated_at: "2026-04-20T14:13:28Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 1ce04bd255ae5f13ff5088414c87e865fe56a8a0d0bf6ef6d8d84cb07ef65f18
+    source_hash: 281b3fd1764c60cb35a25a12c338595020d7c04bcb662e96c4131193a0607537
     source_path: reference/RELEASING.md
     workflow: 15
 ---
@@ -21,160 +21,161 @@ OpenClaw має три публічні канали випусків:
 - beta: теги попередніх випусків, які публікуються в npm `beta`
 - dev: рухома вершина `main`
 
-## Іменування версій
+## Назви версій
 
-- Версія stable-випуску: `YYYY.M.D`
+- Версія стабільного випуску: `YYYY.M.D`
   - Git-тег: `vYYYY.M.D`
-- Версія stable-випуску з виправленням: `YYYY.M.D-N`
+- Версія випуску стабільного виправлення: `YYYY.M.D-N`
   - Git-тег: `vYYYY.M.D-N`
-- Версія beta попереднього випуску: `YYYY.M.D-beta.N`
+- Версія beta prerelease: `YYYY.M.D-beta.N`
   - Git-тег: `vYYYY.M.D-beta.N`
 - Не додавайте нулі попереду для місяця або дня
-- `latest` означає поточний підвищений stable-випуск у npm
+- `latest` означає поточний стабільний випуск npm, який було підвищено
 - `beta` означає поточну ціль встановлення beta
-- Stable-випуски та stable-випуски з виправленнями за замовчуванням публікуються в npm `beta`; оператори випусків можуть явно націлити `latest` або пізніше підвищити перевірену beta-збірку
-- Кожен випуск OpenClaw постачається разом як npm-пакет і macOS app
+- Стабільні випуски та випуски стабільних виправлень за замовчуванням публікуються в npm `beta`; оператори випусків можуть явно націлюватися на `latest` або підвищити перевірену beta-збірку пізніше
+- Кожен випуск OpenClaw одночасно постачає npm package і застосунок macOS
 
 ## Частота випусків
 
 - Випуски спочатку проходять через beta
-- Stable виходить лише після перевірки останньої beta
-- Детальна процедура випуску, погодження, облікові дані та примітки щодо відновлення
-  доступні лише для супроводжувачів
+- Stable з’являється лише після перевірки останньої beta
+- Детальна процедура випуску, затвердження, облікові дані та примітки щодо відновлення доступні
+  лише для супроводжувачів
 
-## Передрелізна перевірка
+## Попередня перевірка випуску
 
-- Запускайте `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки
-  циклів імпорту та меж архітектури були зеленими поза межами швидшого локального циклу
-- Запускайте `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
-  артефакти випуску `dist/*` і пакет Control UI були наявні для кроку
+- Виконайте `pnpm check:test-types` перед попередньою перевіркою випуску, щоб тестовий TypeScript лишався
+  охопленим поза швидшим локальним бар’єром `pnpm check`
+- Виконайте `pnpm check:architecture` перед попередньою перевіркою випуску, щоб ширші перевірки
+  циклів імпорту та меж архітектури були успішними поза швидшим локальним бар’єром
+- Виконайте `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
+  артефакти випуску `dist/*` і bundle Control UI існували для кроку
   перевірки pack
-- Запускайте `pnpm release:check` перед кожним тегованим випуском
+- Виконуйте `pnpm release:check` перед кожним тегованим випуском
 - Перевірки випуску тепер виконуються в окремому ручному workflow:
   `OpenClaw Release Checks`
-- Міжплатформна перевірка встановлення та оновлення під час виконання запускається з
-  приватного workflow-джерела виклику
+- Крос-ОС перевірка встановлення та оновлення під час виконання запускається з
+  приватного caller workflow
   `openclaw/releases-private/.github/workflows/openclaw-cross-os-release-checks.yml`,
   який викликає повторно використовуваний публічний workflow
   `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
-- Такий поділ навмисний: реальний шлях npm-випуску має залишатися коротким,
+- Цей поділ навмисний: він зберігає справжній шлях випуску npm коротким,
   детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються
-  у власному каналі, щоб не затримувати та не блокувати публікацію
-- Перевірки випуску мають запускатися з workflow ref `main`, щоб логіка
-  workflow та секрети залишалися канонічними
+  у власному каналі, щоб не затримувати і не блокувати публікацію
+- Перевірки випуску мають запускатися з посилання workflow `main`, щоб
+  логіка workflow і секрети лишалися канонічними
 - Цей workflow приймає або наявний тег випуску, або поточний повний
   40-символьний SHA коміту `main`
-- У режимі SHA коміту він приймає лише поточний HEAD `origin/main`; для
-  старіших комітів випуску використовуйте тег випуску
-- Передрелізна перевірка лише для валідації `OpenClaw NPM Release` також приймає поточний
-  повний 40-символьний SHA коміту `main` без вимоги наявності опублікованого тегу
+- У режимі SHA коміту він приймає лише поточний HEAD `origin/main`; використовуйте
+  тег випуску для старіших комітів випуску
+- Попередня перевірка лише для валідації `OpenClaw NPM Release` також приймає поточний
+  повний 40-символьний SHA коміту `main` без вимоги вже запушеного тега
 - Цей шлях SHA призначений лише для валідації й не може бути підвищений до реальної публікації
-- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки
-  метаданих пакета; реальна публікація все одно вимагає реального тегу випуску
+- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки метаданих
+  package; реальна публікація все одно потребує реального тега випуску
 - Обидва workflow зберігають реальний шлях публікації та підвищення на GitHub-hosted
-  runners, тоді як немутуючий шлях валідації може використовувати більші
+  runners, тоді як немутувальний шлях валідації може використовувати більші
   Blacksmith Linux runners
 - Цей workflow запускає
   `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
-  використовуючи обидва секрети workflow: `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
-- Передрелізна перевірка npm-випуску більше не чекає на окремий канал перевірок випуску
-- Перед погодженням запускайте
-  `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
-  (або відповідний тег beta/виправлення)
-- Після публікації в npm запускайте
+  з використанням обох workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
+- Попередня перевірка випуску npm більше не чекає на окремий канал перевірок випуску
+- Виконайте `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
+  (або відповідний тег beta/виправлення) перед затвердженням
+- Після публікації в npm виконайте
   `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
   (або відповідну версію beta/виправлення), щоб перевірити опублікований шлях
-  встановлення з реєстру в новому тимчасовому префіксі
-- Автоматизація випусків супроводжувачів тепер використовує підхід preflight-then-promote:
+  встановлення з реєстру в новому тимчасовому prefix
+- Автоматизація випусків супроводжувачів тепер використовує схему preflight-then-promote:
   - реальна публікація в npm має пройти успішний npm `preflight_run_id`
-  - stable npm-випуски за замовчуванням націлені на `beta`
-  - stable npm-публікацію можна явно націлити на `latest` через вхідні дані workflow
-  - зміна npm dist-tag на основі токена тепер знаходиться в
+  - стабільні випуски npm за замовчуванням спрямовуються в `beta`
+  - стабільна публікація npm може явно націлюватися на `latest` через вхід workflow
+  - мутація npm dist-tag на основі токена тепер знаходиться в
     `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
-    з міркувань безпеки, оскільки `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як
-    публічний репозиторій зберігає OIDC-only publish
+    з міркувань безпеки, тому що `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як
+    публічний репозиторій зберігає публікацію лише через OIDC
   - публічний `macOS Release` призначений лише для валідації
-  - реальна приватна mac-публікація має пройти успішні приватні mac
+  - реальна приватна публікація mac має пройти успішні приватні mac
     `preflight_run_id` і `validate_run_id`
-  - реальні шляхи публікації підвищують уже підготовлені артефакти замість того, щоб
-    знову їх перебудовувати
-- Для stable-випусків з виправленнями на кшталт `YYYY.M.D-N` засіб перевірки після публікації
-  також перевіряє той самий шлях оновлення в тимчасовому префіксі з `YYYY.M.D` до `YYYY.M.D-N`,
-  щоб виправлення випусків не могли непомітно залишити старі глобальні встановлення на
-  базовому stable-вмісті
-- Передрелізна перевірка npm-випуску завершується помилкою за принципом fail closed, якщо tarball не містить
-  одночасно `dist/control-ui/index.html` і непорожній вміст `dist/control-ui/assets/`,
+  - реальні шляхи публікації підвищують уже підготовлені артефакти замість повторного
+    їх збирання
+- Для стабільних випусків виправлень на кшталт `YYYY.M.D-N` постпублікаційний верифікатор
+  також перевіряє той самий шлях оновлення через тимчасовий prefix з `YYYY.M.D` до `YYYY.M.D-N`,
+  щоб стабільні виправлення не могли непомітно залишати старі глобальні встановлення на
+  базовому стабільному payload
+- Попередня перевірка випуску npm завершується з помилкою за замовчуванням, якщо tarball не містить і
+  `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`,
   щоб ми знову не випустили порожню панель браузера
-- `pnpm test:install:smoke` також примусово перевіряє бюджет `unpackedSize` для npm pack
-  на tarball кандидата на оновлення, щоб installer e2e виявляв випадкове збільшення pack
-  до шляху публікації випуску
-- Якщо робота над випуском зачепила планування CI, маніфести часу розширень або
-  матриці тестування розширень, перед погодженням заново згенеруйте й перегляньте
-  керовані planner виходи матриці workflow `checks-node-extensions` з `.github/workflows/ci.yml`,
+- `pnpm test:install:smoke` також примусово застосовує бюджет npm pack `unpackedSize` до
+  tarball кандидата на оновлення, щоб e2e перевірка інсталятора виявляла випадкове
+  роздуття pack до шляху публікації випуску
+- Якщо робота над випуском торкалася планування CI, маніфестів часу extension або
+  матриць тестів extension, перед затвердженням заново згенеруйте та перегляньте
+  виходи матриці workflow `checks-node-extensions`, якими керує planner, з `.github/workflows/ci.yml`,
   щоб примітки до випуску не описували застарілу структуру CI
-- Готовність stable macOS release також включає поверхні оновлювача:
-  - GitHub release має в результаті містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
-  - `appcast.xml` у `main` має вказувати на новий stable zip після публікації
-  - запакований app має зберігати bundle id не для debug, непорожній Sparkle feed
-    URL і `CFBundleVersion` на рівні або вище канонічного порога збірки Sparkle
+- Готовність стабільного випуску macOS також включає поверхні оновлювача:
+  - GitHub release має врешті містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
+  - `appcast.xml` у `main` після публікації має вказувати на новий stable zip
+  - запакований застосунок має зберігати не-debug bundle id, непорожній Sparkle feed
+    URL і `CFBundleVersion`, не нижчий за канонічний мінімум Sparkle build
     для цієї версії випуску
 
-## Вхідні дані NPM workflow
+## Вхідні параметри workflow NPM
 
-`OpenClaw NPM Release` приймає такі керовані оператором вхідні дані:
+`OpenClaw NPM Release` приймає такі керовані оператором вхідні параметри:
 
 - `tag`: обов’язковий тег випуску, наприклад `v2026.4.2`, `v2026.4.2-1` або
   `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
-  повний 40-символьний SHA коміту `main` для передрелізної перевірки лише для валідації
-- `preflight_only`: `true` для лише валідації/збірки/пакування, `false` для
+  повний 40-символьний SHA коміту `main` для попередньої перевірки лише з валідацією
+- `preflight_only`: `true` для лише валідації/збирання/пакування, `false` для
   реального шляху публікації
-- `preflight_run_id`: обов’язковий для реального шляху публікації, щоб workflow повторно використав
-  підготовлений tarball з успішного запуску передрелізної перевірки
-- `npm_dist_tag`: цільовий npm-тег для шляху публікації; за замовчуванням `beta`
+- `preflight_run_id`: обов’язковий у реальному шляху публікації, щоб workflow повторно використав
+  підготовлений tarball з успішного запуску попередньої перевірки
+- `npm_dist_tag`: цільовий тег npm для шляху публікації; за замовчуванням `beta`
 
-`OpenClaw Release Checks` приймає такі керовані оператором вхідні дані:
+`OpenClaw Release Checks` приймає такі керовані оператором вхідні параметри:
 
-- `ref`: наявний тег випуску або поточний повний 40-символьний коміт
-  SHA для валідації
+- `ref`: наявний тег випуску або поточний повний 40-символьний SHA коміту `main`
+  для валідації
 
 Правила:
 
-- Stable і теги виправлень можуть публікуватися або в `beta`, або в `latest`
-- Beta-теги попередніх випусків можуть публікуватися лише в `beta`
-- Повний вхідний commit SHA дозволений лише коли `preflight_only=true`
-- Режим commit-SHA для перевірок випуску також вимагає поточний HEAD `origin/main`
-- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час передрелізної перевірки;
+- Stable і correction теги можуть публікуватися або в `beta`, або в `latest`
+- Теги beta prerelease можуть публікуватися лише в `beta`
+- Повний SHA коміту дозволений лише коли `preflight_only=true`
+- Режим SHA коміту для перевірок випуску також вимагає поточний HEAD `origin/main`
+- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що й під час попередньої перевірки;
   workflow перевіряє ці метадані перед продовженням публікації
 
-## Послідовність stable npm-випуску
+## Послідовність стабільного випуску npm
 
-Під час створення stable npm-випуску:
+Під час створення стабільного випуску npm:
 
 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
-   - До появи тегу ви можете використати поточний повний SHA коміту `main` для
-     dry run передрелізного workflow лише для валідації
-2. Виберіть `npm_dist_tag=beta` для звичайного beta-first процесу або `latest` лише
-   коли ви навмисно хочете прямої stable-публікації
-3. Запустіть окремо `OpenClaw Release Checks` з тим самим тегом або
-   повним поточним SHA `main`, якщо вам потрібне live-покриття prompt cache
-   - Це навмисно окремо, щоб live-покриття залишалося доступним без
-     повторного зчеплення довготривалих або нестабільних перевірок із workflow публікації
+   - Поки тег ще не існує, ви можете використати поточний повний SHA коміту `main` для
+     dry run попередньої перевірки workflow лише з валідацією
+2. Оберіть `npm_dist_tag=beta` для звичайного beta-first потоку, або `latest` лише
+   якщо ви навмисно хочете пряму стабільну публікацію
+3. Запустіть `OpenClaw Release Checks` окремо з тим самим тегом або
+   повним поточним SHA `main`, коли вам потрібне live-покриття prompt cache
+   - Це навмисно окремо, щоб live-покриття лишалося доступним без
+     повторного зв’язування довгих або нестабільних перевірок із workflow публікації
 4. Збережіть успішний `preflight_run_id`
-5. Знову запустіть `OpenClaw NPM Release` з `preflight_only=false`, тим самим
+5. Запустіть `OpenClaw NPM Release` знову з `preflight_only=false`, тим самим
    `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id`
 6. Якщо випуск потрапив у `beta`, використайте приватний workflow
    `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
-   щоб підвищити цю stable-версію з `beta` до `latest`
-7. Якщо випуск навмисно був одразу опублікований у `latest`, а `beta`
-   має відразу наслідувати ту саму stable-збірку, використайте той самий приватний
-   workflow, щоб спрямувати обидва dist-tag на stable-версію, або дозвольте його запланованій
-   self-healing синхронізації перемістити `beta` пізніше
+   щоб підвищити цю стабільну версію з `beta` до `latest`
+7. Якщо випуск навмисно було одразу опубліковано в `latest` і `beta`
+   має відразу слідувати за тією самою стабільною збіркою, використайте той самий приватний
+   workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його плановій
+   самовідновлювальній синхронізації перемістити `beta` пізніше
 
-Зміна dist-tag знаходиться в приватному репозиторії з міркувань безпеки, оскільки вона досі
-вимагає `NPM_TOKEN`, тоді як публічний репозиторій зберігає OIDC-only publish.
+Мутація dist-tag живе в приватному репозиторії з міркувань безпеки, тому що вона все ще
+потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.
 
-Це зберігає як шлях прямої публікації, так і шлях підвищення beta-first
-задокументованими й видимими для операторів.
+Це робить як шлях прямої публікації, так і шлях beta-first promotion
+задокументованими та видимими для операторів.
 
 ## Публічні посилання
 
@@ -187,4 +188,4 @@ OpenClaw має три публічні канали випусків:
 
 Супроводжувачі використовують приватну документацію щодо випусків у
 [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
-як фактичну інструкцію.
+як фактичний runbook.

docs/uk/reference/test.md

@@ -1,60 +1,61 @@
 ---
 read_when:
     - Запуск або виправлення тестів
-summary: Як локально запускати тести (vitest) і коли використовувати режими force/coverage
+summary: Як запускати тести локально (vitest) і коли використовувати режими force/coverage
 title: Тести
 x-i18n:
-    generated_at: "2026-04-07T08:14:26Z"
+    generated_at: "2026-04-20T14:13:23Z"
     model: gpt-5.4
     provider: openai
-    source_hash: f7c19390f7577b3a29796c67514c96fe4c86c9fa0c7686cd4e377c6e31dcd085
+    source_hash: 03c44e5e4fab11883d9af416141d3e8013360a46b7c201ad9ac7cee5e6b3d24e
     source_path: reference/test.md
     workflow: 15
 ---
 
 # Тести
 
-- Повний набір інструментів для тестування (набори тестів, live, Docker): [Тестування](/uk/help/testing)
+- Повний набір для тестування (набори тестів, live, Docker): [Тестування](/uk/help/testing)
 
-- `pnpm test:force`: Завершує будь-який завислий процес gateway, що утримує типовий порт керування, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб тести сервера не конфліктували із запущеним екземпляром. Використовуйте це, якщо попередній запуск gateway залишив порт 18789 зайнятим.
-- `pnpm test:coverage`: Запускає набір модульних тестів із покриттям V8 (через `vitest.unit.config.ts`). Глобальні пороги становлять 70% для рядків/гілок/функцій/інструкцій. Із покриття виключено точки входу з великою інтеграційною складовою (зв’язування CLI, мости gateway/telegram, статичний сервер webchat), щоб ціль залишалася зосередженою на логіці, придатній для модульного тестування.
-- `pnpm test:coverage:changed`: Запускає покриття модульних тестів лише для файлів, змінених відносно `origin/main`.
-- `pnpm test:changed`: розгортає змінені git-шляхи в цільові lanes Vitest, якщо diff торкається лише маршрутизовних файлів коду/тестів. Зміни конфігурації/налаштування все одно повертаються до нативного запуску кореневих проєктів, щоб зміни у зв’язуванні за потреби повторно запускали тести ширше.
-- `pnpm test`: спрямовує явні цілі файлів/каталогів через цільові lanes Vitest. Запуски без указання цілі тепер виконують одинадцять послідовних конфігурацій shard (`vitest.full-core-unit-src.config.ts`, `vitest.full-core-unit-security.config.ts`, `vitest.full-core-unit-ui.config.ts`, `vitest.full-core-unit-support.config.ts`, `vitest.full-core-support-boundary.config.ts`, `vitest.full-core-contracts.config.ts`, `vitest.full-core-bundled.config.ts`, `vitest.full-core-runtime.config.ts`, `vitest.full-agentic.config.ts`, `vitest.full-auto-reply.config.ts`, `vitest.full-extensions.config.ts`) замість одного великого процесу кореневого проєкту.
-- Вибрані тестові файли `plugin-sdk` і `commands` тепер спрямовуються через окремі легкі lanes, які залишають лише `test/setup.ts`, а важкі з погляду runtime сценарії — у наявних lanes.
-- Вибрані допоміжні файли коду `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами в цих легких lanes, щоб невеликі зміни в допоміжних функціях не спричиняли повторний запуск важких наборів із підтримкою runtime.
-- `auto-reply` тепер також розділено на три окремі конфігурації (`core`, `top-level`, `reply`), щоб harness reply не домінував над легшими тестами верхнього рівня для status/token/helper.
-- Базова конфігурація Vitest тепер типово використовує `pool: "threads"` і `isolate: false`, а спільний неізольований runner увімкнено в усіх конфігураціях репозиторію.
+- `pnpm test:force`: Завершує будь-який завислий процес gateway, що утримує типовий control port, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб серверні тести не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789.
+- `pnpm test:coverage`: Запускає набір unit-тестів із покриттям V8 (через `vitest.unit.config.ts`). Глобальні пороги становлять 70% для рядків/гілок/функцій/інструкцій. Із покриття виключені entrypoint-и з важкою інтеграцією (CLI wiring, мости gateway/telegram, статичний сервер webchat), щоб ціль залишалася зосередженою на логіці, придатній для unit-тестування.
+- `pnpm test:coverage:changed`: Запускає покриття unit-тестів лише для файлів, змінених відносно `origin/main`.
+- `pnpm test:changed`: розгортає змінені git-шляхи в обмежені lane-и Vitest, коли diff торкається лише routable файлів source/test. Зміни конфігурації/налаштування все ще повертаються до нативного запуску root projects, тож зміни wiring за потреби повторно запускаються ширше.
+- `pnpm test`: спрямовує явні цілі файлів/каталогів через обмежені lane-и Vitest. Нетаргетовані запуски тепер виконують одинадцять послідовних shard-конфігурацій (`vitest.full-core-unit-src.config.ts`, `vitest.full-core-unit-security.config.ts`, `vitest.full-core-unit-ui.config.ts`, `vitest.full-core-unit-support.config.ts`, `vitest.full-core-support-boundary.config.ts`, `vitest.full-core-contracts.config.ts`, `vitest.full-core-bundled.config.ts`, `vitest.full-core-runtime.config.ts`, `vitest.full-agentic.config.ts`, `vitest.full-auto-reply.config.ts`, `vitest.full-extensions.config.ts`) замість одного гігантського процесу root-project.
+- Вибрані тестові файли `plugin-sdk` і `commands` тепер спрямовуються через окремі легкі lane-и, які залишають лише `test/setup.ts`, а runtime-важкі випадки — у наявних lane-ах.
+- Вибрані вихідні helper-файли `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами в цих легких lane-ах, тож невеликі зміни helper-ів не змушують повторно запускати важкі набори з підтримкою runtime.
+- `auto-reply` тепер також поділяється на три окремі конфігурації (`core`, `top-level`, `reply`), щоб harness для reply не домінував над легшими тестами статусу/token/helper верхнього рівня.
+- Базова конфігурація Vitest тепер за замовчуванням використовує `pool: "threads"` та `isolate: false`, із увімкненим спільним неізольованим runner-ом у всіх конфігураціях репозиторію.
 - `pnpm test:channels` запускає `vitest.channels.config.ts`.
 - `pnpm test:extensions` запускає `vitest.extensions.config.ts`.
-- `pnpm test:extensions`: запускає набори тестів extension/plugin.
-- `pnpm test:perf:imports`: вмикає звітування Vitest про тривалість імпорту та деталізацію імпорту, і при цьому все ще використовує маршрутизацію через цільові lanes для явних цілей файлів/каталогів.
-- `pnpm test:perf:imports:changed`: те саме профілювання імпорту, але лише для файлів, змінених відносно `origin/main`.
-- `pnpm test:perf:changed:bench -- --ref <git-ref>` порівнює маршрутний шлях режиму changed із нативним запуском кореневого проєкту для того самого зафіксованого git diff.
-- `pnpm test:perf:changed:bench -- --worktree` порівнює поточний набір змін у worktree без попереднього коміту.
-- `pnpm test:perf:profile:main`: записує CPU profile для головного потоку Vitest (`.artifacts/vitest-main-profile`).
-- `pnpm test:perf:profile:runner`: записує профілі CPU + heap для unit runner (`.artifacts/vitest-runner-profile`).
-- Інтеграція gateway: увімкнення за бажанням через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
-- `pnpm test:e2e`: запускає наскрізні smoke-тести gateway (багатоекземплярне сполучення WS/HTTP/node). Типово використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=<n>` і встановіть `OPENCLAW_E2E_VERBOSE=1` для докладних логів.
-- `pnpm test:live`: запускає live-тести provider (minimax/zai). Потребує API-ключів і `LIVE=1` (або специфічного для provider `*_LIVE_TEST=1`) для зняття пропуску.
-- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, виконує вхід через Open WebUI, перевіряє `/api/models`, а потім запускає реальний проксійований чат через `/api/chat/completions`. Потребує придатного ключа live-моделі (наприклад, OpenAI у `~/.profile`), завантажує зовнішній образ Open WebUI і не очікується як стабільний для CI, як звичайні набори unit/e2e.
-- `pnpm test:docker:mcp-channels`: запускає seeded-контейнер Gateway і другий клієнтський контейнер, який запускає `openclaw mcp serve`, а потім перевіряє виявлення маршрутизованих розмов, читання транскриптів, метадані вкладень, поведінку черги live-подій, маршрутизацію вихідного надсилання та сповіщення в стилі Claude про channel + permission через реальний міст stdio. Перевірка сповіщень Claude читає необроблені кадри stdio MCP напряму, щоб smoke-тест відображав те, що міст насправді надсилає.
+- `pnpm test:extensions`: запускає набори розширень/Plugin-ів.
+- `pnpm test:perf:imports`: вмикає звітність Vitest щодо тривалості імпорту та розбивки імпортів, при цьому для явних цілей файлів/каталогів усе ще використовується спрямування через обмежені lane-и.
+- `pnpm test:perf:imports:changed`: те саме профілювання імпортів, але лише для файлів, змінених відносно `origin/main`.
+- `pnpm test:perf:changed:bench -- --ref <git-ref>` виконує бенчмарк спрямованого режиму changed-mode проти нативного запуску root-project для того самого закоміченого git diff.
+- `pnpm test:perf:changed:bench -- --worktree` виконує бенчмарк поточного набору змін робочого дерева без попереднього коміту.
+- `pnpm test:perf:profile:main`: записує CPU-профіль для головного потоку Vitest (`.artifacts/vitest-main-profile`).
+- `pnpm test:perf:profile:runner`: записує CPU- та heap-профілі для unit runner-а (`.artifacts/vitest-runner-profile`).
+- Інтеграція Gateway: вмикається через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
+- `pnpm test:e2e`: запускає наскрізні smoke-тести gateway (парування multi-instance WS/HTTP/node). За замовчуванням використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=<n>` і встановлюйте `OPENCLAW_E2E_VERBOSE=1` для докладних логів.
+- `pnpm test:live`: запускає live-тести provider-ів (minimax/zai). Потребує API-ключів і `LIVE=1` (або специфічного для provider `*_LIVE_TEST=1`) для зняття пропуску.
+- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, входить через Open WebUI, перевіряє `/api/models`, а потім виконує реальний проксійований чат через `/api/chat/completions`. Потребує придатного live-ключа моделі (наприклад, OpenAI у `~/.profile`), завантажує зовнішній образ Open WebUI і не розрахований на таку стабільність у CI, як звичайні набори unit/e2e.
+- `pnpm test:docker:mcp-channels`: запускає seeded контейнер Gateway і другий клієнтський контейнер, який запускає `openclaw mcp serve`, а потім перевіряє виявлення маршрутизованих розмов, читання transcript, метадані attachment, поведінку черги live-подій, маршрутизацію вихідного надсилання та сповіщення про channel + permission у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає сирі кадри stdio MCP безпосередньо, тож smoke відповідає тому, що міст реально надсилає.
 
 ## Локальний PR gate
 
-Для локальних перевірок перед приземленням/проходженням gate PR запустіть:
+Для локальних перевірок перед злиттям/пропуском PR виконайте:
 
 - `pnpm check`
+- `pnpm check:test-types`
 - `pnpm build`
 - `pnpm test`
 - `pnpm check:docs`
 
-Якщо `pnpm test` дає нестабільний збій на завантаженому хості, перезапустіть один раз, перш ніж вважати це регресією, а потім ізолюйте через `pnpm test <path/to/test>`. Для хостів з обмеженою пам’яттю використовуйте:
+Якщо `pnpm test` дає нестабільний збій на навантаженому хості, перезапустіть один раз, перш ніж вважати це регресією, а потім ізолюйте через `pnpm test <path/to/test>`. Для хостів з обмеженою пам’яттю використовуйте:
 
 - `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test`
 - `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed`
 
-## Бенчмарк затримки моделі (локальні ключі)
+## Бенч латентності моделі (локальні ключі)
 
 Скрипт: [`scripts/bench-model.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-model.ts)
 
@@ -62,14 +63,14 @@ x-i18n:
 
 - `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
 - Необов’язкові env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
-- Типовий prompt: “Відповідай одним словом: ok. Без розділових знаків або зайвого тексту.”
+- Типовий prompt: “Reply with a single word: ok. No punctuation or extra text.”
 
 Останній запуск (2025-12-31, 20 запусків):
 
 - minimax median 1279ms (min 1114, max 2431)
 - opus median 2454ms (min 1224, max 3170)
 
-## Бенчмарк запуску CLI
+## Бенч запуску CLI
 
 Скрипт: [`scripts/bench-cli-startup.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/bench-cli-startup.ts)
 
@@ -90,25 +91,25 @@ x-i18n:
 - `pnpm tsx scripts/bench-cli-startup.ts --preset real --cpu-prof-dir .artifacts/cli-cpu`
 - `pnpm tsx scripts/bench-cli-startup.ts --json`
 
-Набори preset:
+Набори preset-ів:
 
 - `startup`: `--version`, `--help`, `health`, `health --json`, `status --json`, `status`
 - `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port`
-- `all`: обидва presets
+- `all`: обидва набори preset-ів
 
-Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення max RSS для кожної команди. Необов’язковий `--cpu-prof-dir` / `--heap-prof-dir` записує профілі V8 для кожного запуску, щоб вимірювання часу та захоплення профілю використовували той самий harness.
+Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і зведення max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують V8-профілі для кожного запуску, щоб вимірювання часу та збирання профілів використовували один і той самий harness.
 
-Умовні позначення для збереженого виводу:
+Угоди щодо збереженого виводу:
 
 - `pnpm test:startup:bench:smoke` записує цільовий smoke-артефакт у `.artifacts/cli-startup-bench-smoke.json`
-- `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json` з використанням `runs=5` і `warmup=1`
-- `pnpm test:startup:bench:update` оновлює закомічений baseline fixture у `test/fixtures/cli-startup-bench.json` з використанням `runs=5` і `warmup=1`
+- `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json`, використовуючи `runs=5` і `warmup=1`
+- `pnpm test:startup:bench:update` оновлює закомічений baseline fixture у `test/fixtures/cli-startup-bench.json`, використовуючи `runs=5` і `warmup=1`
 
 Закомічений fixture:
 
 - `test/fixtures/cli-startup-bench.json`
-- Оновіть за допомогою `pnpm test:startup:bench:update`
-- Порівняйте поточні результати з fixture за допомогою `pnpm test:startup:bench:check`
+- Оновлення: `pnpm test:startup:bench:update`
+- Порівняння поточних результатів із fixture: `pnpm test:startup:bench:check`
 
 ## Onboarding E2E (Docker)
 
@@ -120,11 +121,11 @@ Docker необов’язковий; це потрібно лише для cont
 scripts/e2e/onboard-docker.sh
 ```
 
-Цей скрипт керує інтерактивним майстром через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`.
+Цей скрипт проводить інтерактивний майстер через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`.
 
-## QR import smoke (Docker)
+## Smoke-тест імпорту QR (Docker)
 
-Гарантує, що `qrcode-terminal` завантажується в підтримуваних Docker runtime Node (типово Node 24, сумісно з Node 22):
+Гарантує, що `qrcode-terminal` завантажується у підтримуваних Docker runtime Node (типово Node 24, сумісно з Node 22):
 
 ```bash
 pnpm test:docker:qr