chore(i18n): refresh uk translations

2026-04-12 22:01:00 +00:00 · 2026-04-12 22:01:00 +00:00 · 5ae7b9aa75
commit 5ae7b9aa75
parent 90d750b08b
1 changed files with 99 additions and 65 deletions
--- a/docs/uk/reference/RELEASING.md
+++ b/docs/uk/reference/RELEASING.md
@ -5,10 +5,10 @@ read_when:
 summary: Публічні канали релізів, назви версій і періодичність
 title: Політика релізів
 x-i18n:
-    generated_at: "2026-04-10T23:44:31Z"
+    generated_at: "2026-04-12T22:00:22Z"
    model: gpt-5.4
    provider: openai
-    source_hash: ca613d094c93670c012f0b79720fad0d5d85be802f54b0acb7a8f22aca5bde12
+    source_hash: dffc1ee5fdbb20bd1bf4b3f817d497fc0d87f70ed6c669d324fea66dc01d0b0b
    source_path: reference/RELEASING.md
    workflow: 15
 ---
@ -17,99 +17,126 @@ x-i18n:

 OpenClaw має три публічні канали релізів:

- stable: теговані релізи, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запрошено
+- stable: релізи з тегами, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, якщо це явно запитано
 - beta: prerelease-теги, які публікуються в npm `beta`
- dev: рухома вершина `main`
+- dev: поточна рухома вершина `main`

 ## Назви версій

 - Версія stable-релізу: `YYYY.M.D`
  - Git-тег: `vYYYY.M.D`
- Версія stable-коригувального релізу: `YYYY.M.D-N`
+- Версія stable-виправлення: `YYYY.M.D-N`
  - Git-тег: `vYYYY.M.D-N`
- Версія beta-prerelease: `YYYY.M.D-beta.N`
+- Версія beta prerelease: `YYYY.M.D-beta.N`
  - Git-тег: `vYYYY.M.D-beta.N`
- Не додавайте нулі попереду для місяця або дня
- `latest` означає поточний просунутий stable-реліз npm
+- Не додавайте провідні нулі до місяця або дня
+- `latest` означає поточний підвищений stable-реліз у npm
 - `beta` означає поточну ціль встановлення beta
- Stable і stable-коригувальні релізи за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно вибрати `latest` або пізніше просунути перевірену beta-збірку
+- Stable-релізи та stable-виправлення за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно націлити публікацію на `latest` або пізніше підвищити перевірену beta-збірку
 - Кожен реліз OpenClaw постачається разом із npm-пакетом і застосунком для macOS

 ## Періодичність релізів

 - Релізи спочатку проходять через beta
- Stable іде лише після перевірки найновішої beta
- Детальна процедура релізу, затвердження, облікові дані та нотатки щодо відновлення
-  доступні лише для мейнтейнерів
+- Stable виходить лише після перевірки останньої beta
+- Детальна процедура релізу, затвердження, облікові дані та примітки щодо відновлення
+  доступні лише для maintainer-ів

 ## Передрелізна перевірка

 - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
-  артефакти релізу `dist/*` і збірка Control UI існували для кроку
-  перевірки пакування
- Запускайте `pnpm release:check` перед кожним тегованим релізом
- Передрелізна перевірка npm для main-гілки також запускає
+  артефакти релізу `dist/*` і бандл Control UI існували для кроку
+  перевірки pack
+- Запускайте `pnpm release:check` перед кожним релізом із тегом
+- Перевірки релізу тепер виконуються в окремому ручному workflow:
+  `OpenClaw Release Checks`
+- Цей поділ є навмисним: він зберігає реальний шлях npm-релізу коротким,
+  детермінованим і зосередженим на артефактах, тоді як повільніші live-перевірки залишаються
+  у власному каналі, щоб не затримувати і не блокувати публікацію
+- Перевірки релізу потрібно запускати з workflow ref для `main`, щоб
+  логіка workflow і секрети залишалися канонічними
+- Цей workflow приймає або наявний тег релізу, або поточний повний
+  40-символьний SHA коміту `main`
+- У режимі SHA коміту він приймає лише поточний HEAD `origin/main`; для
+  старіших комітів релізу використовуйте тег релізу
+- Передрелізна перевірка лише для валідації `OpenClaw NPM Release` також приймає поточний
+  повний 40-символьний SHA коміту `main` без вимоги наявності запушеного тега
+- Цей шлях SHA є лише для валідації і не може бути підвищений до реальної публікації
+- У режимі SHA workflow синтезує `v<package.json version>` лише для
+  перевірки метаданих пакета; реальна публікація все одно потребує справжнього тега релізу
+- Обидва workflows залишають реальний шлях публікації та підвищення на GitHub-hosted
+  runners, тоді як шлях валідації без змін стану може використовувати більші
+  Blacksmith Linux runners
+- Цей workflow запускає
  `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
-  перед пакуванням tarball, використовуючи обидва секрети воркфлоу:
-  `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
+  використовуючи обидва workflow secrets: `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
+- Передрелізна перевірка npm-релізу більше не чекає окремий канал перевірок релізу
 - Перед затвердженням запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
-  (або відповідний beta/correction-тег)
+  (або відповідний тег beta/виправлення)
 - Після публікації в npm запустіть
  `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  (або відповідну beta/correction-версію), щоб перевірити опублікований шлях
+  (або відповідну beta/версію виправлення), щоб перевірити опублікований шлях
  встановлення з реєстру в новому тимчасовому префіксі
- Автоматизація релізів для мейнтейнерів тепер використовує схему preflight-then-promote:
-  - справжня публікація в npm має пройти успішний npm `preflight_run_id`
-  - stable npm-релізи за замовчуванням ідуть у `beta`
-  - stable npm-публікацію можна явно націлити на `latest` через вхідні параметри воркфлоу
-  - stable npm-просування з `beta` до `latest` усе ще доступне як явний ручний режим у довіреному воркфлоу `OpenClaw NPM Release`
-  - для цього режиму просування все одно потрібен дійсний `NPM_TOKEN` у середовищі `npm-release`, оскільки керування npm `dist-tag` виконується окремо від trusted publishing
+- Автоматизація релізів maintainer-ів тепер використовує схему preflight-then-promote:
+  - реальна публікація в npm має пройти успішний npm `preflight_run_id`
+  - stable npm-релізи за замовчуванням націлюються на `beta`
+  - stable npm-публікація може явно націлюватися на `latest` через вхід workflow
+  - підвищення stable npm з `beta` до `latest` усе ще доступне як явний ручний режим у довіреному workflow `OpenClaw NPM Release`
+  - цей режим підвищення все ще потребує дійсного `NPM_TOKEN` у середовищі `npm-release`, оскільки керування npm `dist-tag` виконується окремо від trusted publishing
  - публічний `macOS Release` призначений лише для валідації
-  - справжня приватна mac-публікація має пройти успішні приватні mac
+  - реальна приватна mac-публікація має пройти успішні приватні mac
    `preflight_run_id` і `validate_run_id`
-  - справжні шляхи публікації просувають підготовлені артефакти замість того, щоб
-    повторно збирати їх знову
- Для stable-коригувальних релізів на кшталт `YYYY.M.D-N`, post-publish verifier
+  - реальні шляхи публікації підвищують уже підготовлені артефакти замість їх повторного збирання
+- Для stable-виправлень на кшталт `YYYY.M.D-N` post-publish verifier
  також перевіряє той самий шлях оновлення в тимчасовому префіксі з `YYYY.M.D` до `YYYY.M.D-N`,
-  щоб коригувальні релізи не могли непомітно залишити старіші глобальні встановлення на
-  базовому stable-навантаженні
- Передрелізна перевірка npm завершується з відмовою за замовчуванням, якщо tarball не містить і
-  `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`,
+  щоб виправлення релізу не могли непомітно залишити старі глобальні встановлення на
+  базовому stable-вмісті
+- Передрелізна перевірка npm-релізу завершується помилкою за замовчуванням, якщо tarball не містить
+  і `dist/control-ui/index.html`, і непорожній вміст `dist/control-ui/assets/`,
  щоб ми знову не випустили порожню панель браузера
- Якщо робота над релізом зачіпала планування CI, маніфести таймінгу розширень або
-  матриці тестування розширень, перед затвердженням згенеруйте наново й перегляньте
-  виходи матриці воркфлоу `checks-node-extensions`, якими володіє planner, з `.github/workflows/ci.yml`,
-  щоб нотатки до релізу не описували застарілу структуру CI
- Готовність stable-релізу macOS також включає поверхні оновлювача:
-  - GitHub-реліз зрештою має містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
-  - `appcast.xml` у `main` має після публікації вказувати на новий stable zip
-  - запакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed
-    URL і `CFBundleVersion`, не нижчий за канонічний мінімальний рівень збірки Sparkle
+- Якщо робота над релізом зачепила планування CI, маніфести часу виконання extensions або
+  матриці тестування extensions, перед затвердженням згенеруйте заново та перегляньте
+  workflow matrix outputs, якими керує planner,
+  `checks-node-extensions` з `.github/workflows/ci.yml`, щоб примітки до релізу не
+  описували застарілу структуру CI
+- Готовність stable-релізу для macOS також охоплює поверхні оновлення:
+  - GitHub-реліз зрештою має містити паковані `.zip`, `.dmg` і `.dSYM.zip`
+  - `appcast.xml` у `main` після публікації має вказувати на новий stable zip
+  - пакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed
+    URL і `CFBundleVersion` на рівні або вище канонічного мінімального Sparkle build
    для цієї версії релізу

-## Вхідні параметри воркфлоу NPM
+## Вхідні параметри workflow NPM

-`OpenClaw NPM Release` приймає такі вхідні параметри, якими керує оператор:
+`OpenClaw NPM Release` приймає такі керовані оператором вхідні параметри:

 - `tag`: обов’язковий тег релізу, наприклад `v2026.4.2`, `v2026.4.2-1` або
-  `v2026.4.2-beta.1`
+  `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
+  повний 40-символьний SHA коміту `main` для передрелізної перевірки лише з валідацією
 - `preflight_only`: `true` лише для валідації/збирання/пакування, `false` для
-  справжнього шляху публікації
- `preflight_run_id`: обов’язковий на справжньому шляху публікації, щоб воркфлоу повторно використав
-  підготовлений tarball з успішного передрелізного запуску
+  реального шляху публікації
+- `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб workflow повторно використав
+  підготовлений tarball з успішного запуску передрелізної перевірки
 - `npm_dist_tag`: цільовий npm-тег для шляху публікації; за замовчуванням `beta`
- `promote_beta_to_latest`: `true`, щоб пропустити публікацію і перемістити вже опубліковану
-  stable-збірку `beta` до `latest`
+- `promote_beta_to_latest`: `true`, щоб пропустити публікацію й перемістити вже опубліковану
+  stable beta-збірку на `latest`
+
+`OpenClaw Release Checks` приймає такі керовані оператором вхідні параметри:
+
+- `ref`: наявний тег релізу або поточний повний 40-символьний SHA коміту `main`
+  для перевірки

 Правила:

- Stable і correction-теги можуть публікуватися або в `beta`, або в `latest`
+- Stable-теги та теги виправлень можуть публікуватися або в `beta`, або в `latest`
 - Beta prerelease-теги можуть публікуватися лише в `beta`
- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час передрелізної перевірки;
-  воркфлоу перевіряє ці метадані перед продовженням публікації
- Режим просування має використовувати stable або correction-тег, `preflight_only=false`,
+- Повний SHA коміту дозволений лише коли `preflight_only=true`
+- Режим SHA коміту для перевірок релізу також вимагає поточний HEAD `origin/main`
+- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час передрелізної перевірки;
+  workflow перевіряє ці метадані перед продовженням публікації
+- Режим підвищення має використовувати stable-тег або тег виправлення, `preflight_only=false`,
  порожній `preflight_run_id` і `npm_dist_tag=beta`
- Режим просування також вимагає дійсний `NPM_TOKEN` у середовищі `npm-release`,
+- Режим підвищення також вимагає дійсний `NPM_TOKEN` у середовищі `npm-release`,
  оскільки `npm dist-tag add` усе ще потребує звичайної npm-автентифікації

 ## Послідовність stable npm-релізу
@ -117,29 +144,36 @@ OpenClaw має три публічні канали релізів:
 Під час випуску stable npm-релізу:

 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true`
-2. Виберіть `npm_dist_tag=beta` для звичайного beta-first потоку, або `latest` лише
-   якщо ви свідомо хочете прямої stable-публікації
-3. Збережіть успішний `preflight_run_id`
-4. Запустіть `OpenClaw NPM Release` знову з `preflight_only=false`, тим самим
+   - До появи тега ви можете використовувати поточний повний 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 публікації
+4. Збережіть успішний `preflight_run_id`
+5. Знову запустіть `OpenClaw NPM Release` з `preflight_only=false`, тим самим
   `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id`
-5. Якщо реліз потрапив у `beta`, пізніше запустіть `OpenClaw NPM Release` з
+6. Якщо реліз потрапив у `beta`, пізніше запустіть `OpenClaw NPM Release` з
   тим самим stable `tag`, `promote_beta_to_latest=true`, `preflight_only=false`,
   порожнім `preflight_run_id` і `npm_dist_tag=beta`, коли захочете перемістити цю
   опубліковану збірку до `latest`

-Режим просування все ще вимагає затвердження середовища `npm-release` і
+Режим підвищення все ще потребує затвердження середовища `npm-release` і
 дійсного `NPM_TOKEN` у цьому середовищі.

-Це залишає як шлях прямої публікації, так і beta-first шлях просування
+Це зберігає як шлях прямої публікації, так і шлях підвищення beta-first
 задокументованими та видимими для оператора.

 ## Публічні посилання

 - [`.github/workflows/openclaw-npm-release.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-npm-release.yml)
+- [`.github/workflows/openclaw-release-checks.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-release-checks.yml)
 - [`scripts/openclaw-npm-release-check.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/openclaw-npm-release-check.ts)
 - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
 - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)

-Мейнтейнери використовують приватну документацію з релізів у
+Maintainer-и використовують приватну документацію релізів у
 [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
-як фактичний runbook.
+для фактичного runbook.