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