Release and CI

Політика випусків

OpenClaw наразі надає три канали оновлень для користувачів:

stable: наявний канал схвалених випусків, який і далі визначається через npm latest, доки не буде завершено окремий етап CLI/каналів
beta: теги попередніх випусків, що публікуються в npm beta
dev: рухома вершина main

Окремо оператори випусків можуть публікувати основний пакет за останній завершений місяць у npm extended-stable, починаючи з патча 33. Звичайна фінальна лінія поточного місяця залишається в npm latest; цей поділ публікацій на боці оператора сам собою не змінює визначення каналу оновлень CLI.

Альфа-збірки Tideclaw — це окрема внутрішня лінія попередніх випусків (dist-tag npm alpha), описана в розділах Вхідні параметри робочого процесу NPM і Тестові середовища випуску.

Найменування версій

Версія щомісячного розширено стабільного випуску npm: YYYY.M.PATCH, з PATCH >= 33, тег git vYYYY.M.PATCH
Версія щоденного/звичайного фінального випуску: YYYY.M.PATCH, з PATCH < 33, тег git vYYYY.M.PATCH
Версія звичайного резервного виправного випуску: YYYY.M.PATCH-N, тег git vYYYY.M.PATCH-N
Версія попереднього бета-випуску: YYYY.M.PATCH-beta.N, тег git vYYYY.M.PATCH-beta.N
Версія попереднього альфа-випуску: YYYY.M.PATCH-alpha.N, тег git vYYYY.M.PATCH-alpha.N
Ніколи не доповнюйте місяць або патч початковими нулями
PATCH — це послідовний номер щомісячного циклу випусків, а не календарний день. Звичайні фінальні й бета-випуски просувають поточний цикл; теги лише для альфа-версій ніколи не використовують і не збільшують номер патча бета-/звичайного випуску, тому під час вибору бета- або звичайного циклу ігноруйте застарілі теги лише для альфа-версій із більшими номерами патчів.
Альфа-/нічні збірки використовують наступний ще не випущений цикл патча й для повторних збірок збільшують лише alpha.N. Щойно для цього патча з’являється бета-версія, нові альфа-збірки переходять до наступного патча.
Версії npm незмінні: ніколи не видаляйте, не публікуйте повторно й не використовуйте повторно опублікований тег. Натомість створіть наступний номер попереднього випуску або наступний щомісячний патч.
latest і далі відповідає поточній звичайній/щоденній лінії npm; beta — поточна ціль установлення бета-версії
extended-stable означає підтримуваний пакет npm за попередній місяць, починаючи з патча 33; патч 34 і наступні є випусками технічного обслуговування цієї щомісячної лінії
Звичайні фінальні та звичайні виправні випуски типово публікуються в npm beta; оператори випусків можуть явно вибрати latest або пізніше підвищити перевірену бета-збірку
Спеціальний щомісячний розширено стабільний шлях публікує основний пакет npm і кожен офіційний Plugin, який можна опублікувати в npm, з однаковою точною версією. Він не публікує плагіни в ClawHub і не публікує артефакти macOS або Windows, GitHub Release, dist-теги приватних репозиторіїв, образи Docker, мобільні артефакти чи завантаження з вебсайту.
Кожен звичайний фінальний випуск одночасно постачає пакет npm, застосунок macOS, підписаний автономний Android APK і підписані інсталятори Windows Hub. Бета-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а збирання, підписування, нотаризацію та просування нативних застосунків залишають для звичайного фінального випуску, якщо інше не запитано явно.

Періодичність випусків

Випуски спочатку переходять у бета-канал; стабільний випуск з’являється лише після перевірки найновішої бета-версії
Супровідники зазвичай створюють випуски з гілки release/YYYY.M.PATCH, створеної з поточного main, щоб перевірка та виправлення випуску не блокували нову розробку в main
Якщо тег бета-версії вже надіслано або опубліковано й він потребує виправлення, супровідники створюють наступний тег -beta.N, а не видаляють чи повторно створюють старий
Докладна процедура випуску, погодження, облікові дані та примітки щодо відновлення доступні лише супровідникам

Щомісячна розширено стабільна публікація лише в npm

Це спеціальний виняток із наведеної нижче звичайної процедури випуску. Для завершеного місяця YYYY.M створіть extended-stable/YYYY.M.33; публікуйте vYYYY.M.33 і наступні патчі технічного обслуговування з тієї самої гілки. Тег випуску, вершина гілки, робоча копія, версія пакета, попередня перевірка npm і запуск Full Release Validation мають указувати на той самий коміт. Захищена гілка main вже повинна містити фінальну версію строго пізнішого календарного місяця з патчем нижче 33; патчі технічного обслуговування залишаються придатними після того, як main просунеться більш ніж на один місяць.

У точній розширено стабільній гілці оновіть кореневий пакет до YYYY.M.P, виконайте pnpm release:prep і перевірте, що кожен пакет розширення, придатний до публікації, має ту саму версію. Зафіксуйте й надішліть усі згенеровані зміни, створіть і надішліть незмінний тег vYYYY.M.P на цьому коміті та запишіть отриманий повний SHA. Робочі процеси використовують це підготовлене дерево; вони не оновлюють і не синхронізують версії замість вас.

Запустіть попередню перевірку npm і Full Release Validation із точної вершини підготовленої гілки, а потім збережіть ідентифікатори обох запусків та номер успішної спроби запуску Full Release Validation:

bash

gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -f preflight_only=true \  -f npm_dist_tag=extended-stable gh workflow run full-release-validation.yml \  --ref extended-stable/YYYY.M.33 \  -f ref=extended-stable/YYYY.M.33 \  -f release_profile=stable

release_profile=stable — це наявний профіль глибини перевірки; він відокремлений від dist-тега npm extended-stable і навмисно залишається незмінним.

Після успішного завершення обох запусків опублікуйте кожен офіційний Plugin, придатний до публікації в npm, із тієї самої точної вершини гілки. Патч P має дорівнювати 33 або бути більшим. Передайте повний SHA випуску як ref, дочекайтеся завершення всієї матриці та зворотного зчитування з реєстру, а потім збережіть ідентифікатор успішного запуску Plugin NPM Release:

bash

RELEASE_SHA="$(git rev-parse HEAD)"gh workflow run plugin-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f publish_scope=all-publishable \  -f ref="$RELEASE_SHA" \  -f npm_dist_tag=extended-stable

Робочий процес використовує звичайний підготовлений перелік пакетів all-publishable, зокрема пакети, вихідний код яких не змінювався. Перед успішним завершенням він перевіряє кожен точний пакет і кожен тег плагіна extended-stable. Якщо частковий запуск завершиться невдало, повторіть ту саму команду: уже опубліковані пакети буде використано повторно, відсутні або застарілі теги плагінів буде узгоджено в середовищі випуску npm, а підсумкове зворотне зчитування й далі охоплюватиме повний набір пакетів.

Після успішного завершення робочого процесу плагінів і готовності середовища випуску npm опублікуйте точний tarball основного пакета з попередньої перевірки. Публікація основного пакета перевіряє, що зазначений запуск плагінів має стан completed/success у тій самій канонічній гілці та точний SHA вихідного коду:

bash

gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -f preflight_only=false \  -f npm_dist_tag=extended-stable \  -f preflight_run_id=<npm-preflight-run-id> \  -f full_release_validation_run_id=<full-validation-run-id> \  -f full_release_validation_run_attempt=<full-validation-run-attempt> \  -f plugin_npm_run_id=<plugin-npm-run-id>

Для форка або непродукційної репетиції, яка навмисно не може задовольнити щомісячну політику .33 або політику місяця захищеної гілки main, додайте -f bypass_extended_stable_guard=true до обох запусків попередньої перевірки та публікації npm. Типове значення — false. Обхід приймається лише разом із npm_dist_tag=extended-stable і фіксується в підсумку робочого процесу. Він не обходить вимоги до канонічного посилання робочого процесу extended-stable/YYYY.M.33, рівності вершини гілки, тега й робочої копії, синтаксису фінального тега, рівності версії пакета й тега, ідентичності зазначених запусків і маніфесту, походження tarball, погодження середовища, зворотного зчитування з реєстру або доказів відновлення селектора.

Робочий процес публікації перевіряє ідентичність зазначених запусків попередньої перевірки, валідації та плагінів, дайджест підготовленого tarball і селектори реєстру основного пакета. Після успішного завершення робочого процесу незалежно підтвердьте результат:

bash

npm view [email protected] version --userconfig "$(mktemp)"npm view openclaw@extended-stable version --userconfig "$(mktemp)"

Обидві команди мають повернути YYYY.M.P. Якщо публікація успішна, але зворотне зчитування селектора завершується невдало, не публікуйте незмінну версію пакета повторно. Скористайтеся єдиною командою відновлення npm dist-tag add [email protected] extended-stable, наведеною в підсумку невдалого робочого процесу, який виконується завжди, а потім повторіть обидва незалежні зворотні зчитування. Відкат до попереднього селектора — це окреме рішення оператора, а не шлях відновлення зворотного зчитування.

У публічній документації підтримки Slack, Discord і Codex спочатку визначено як підтримувані розширено стабільні поверхні плагінів. Цей перелік є заявою про підтримку, а не списком дозволів у коді випуску: кожен офіційний Plugin, придатний до публікації в npm, проходить той самий шлях публікації точної версії.

Наведений нижче звичайний контрольний список і далі охоплює бета-версії, latest, GitHub Release, плагіни, macOS, Windows та публікацію для інших платформ. Не виконуйте ці кроки для цього розширено стабільного шляху лише для npm.

Контрольний список оператора звичайного випуску

Цей контрольний список відображає публічну структуру процесу випуску. Приватні облікові дані, підписування, нотаризація, відновлення dist-тегів і подробиці аварійного відкату залишаються в посібнику з випуску, доступному лише супровідникам.

Почніть із поточного main: отримайте останні зміни, переконайтеся, що цільовий коміт надіслано, і що стан CI main достатньо успішний для створення гілки.
Створіть release/YYYY.M.PATCH із цього коміту. Зворотні перенесення необов’язкові; застосовуйте лише вибраний оператором набір. Оновіть усі необхідні розташування версій, виконайте pnpm release:prep, завершіть виправлення випуску й необхідні прямі перенесення та перегляньте src/plugins/compat/registry.ts разом із src/commands/doctor/shared/deprecation-compat.ts.
Зафіксуйте повністю готовий з погляду продукту коміт перед журналом змін як SHA коду. Виконайте детерміновану попередню перевірку вихідного коду, а потім скористайтеся node scripts/full-release-validation-at-sha.mjs --sha <code-sha> --target-ref release/YYYY.M.PATCH. Це фіксує надійні інструменти робочого процесу, тоді як повна матриця Vitest, Docker, QA, пакетів і продуктивності перевіряє точний SHA коду.
Класифікуйте збої перед редагуванням. Збій продукту/коду створює новий SHA коду й вимагає успішної повної перевірки для цього SHA. Збій робочого процесу, тестового каркаса, облікових даних, погодження або інфраструктури виправляється у відповідній власницькій поверхні та повторно запускається для того самого SHA коду.
Лише після успішної перевірки SHA коду згенеруйте верхній розділ CHANGELOG.md зі злитих PR і прямих комітів після останнього доступного опублікованого тега. Записи мають бути орієнтованими на користувачів і без дублікатів. Якщо розбіжний опублікований тег або пізніше пряме перенесення повторно пов’язує вже випущені PR, явно передайте його як --shipped-ref.
Зафіксуйте лише CHANGELOG.md. Цей коміт є SHA випуску. Повна різниця між SHA коду та SHA випуску має точно дорівнювати CHANGELOG.md; будь-який інший змінений шлях повертає випуск до кроку 2.
Запустіть Full Release Validation, прив’язану до SHA, для SHA випуску з увімкненим повторним використанням доказів. Полегшений батьківський запуск має зафіксувати changelog-only-release-v1, указувати на успішно перевірений SHA коду й не запускати дочірні продуктові лінії. Це повторно використовує докази щодо продукту, але не байти пакета.
Запустіть OpenClaw NPM Release із preflight_only=true для SHA/тега випуску. Збережіть успішний preflight_run_id. Це створює та перевіряє точні байти пакета, що містять остаточний журнал змін.
Позначте SHA випуску тегом, а потім запустіть допоміжний засіб кандидата з успішним батьківським запуском перевірки SHA випуску та попередньою перевіркою npm замість повторного запуску кожного з них:
bash
```
pnpm release:candidate -- \  --tag vYYYY.M.PATCH-beta.N \  --full-release-run <release-sha-validation-run-id> \  --npm-preflight-run <preflight-run-id> \  --skip-dispatch
```
Для стабільного випуску також передайте --windows-node-tag vX.Y.Z. Допоміжний засіб перевіряє походження приміток до випуску, байти попередньої перевірки npm, підтвердження встановлення/оновлення Parallels, підтвердження пакета Telegram і плани публікації плагінів, а потім виводить команду публікації.

OpenClaw Release Publish паралельно надсилає вибрані або всі придатні до публікації пакети плагінів до npm і той самий набір до ClawHub, а після успішної публікації плагінів у npm просуває підготовлений артефакт попередньої перевірки npm для OpenClaw із відповідним dist-tag. Робоча копія випуску залишається коренем продукту й даних, а планування та фінальна перевірка виконуються з точної довіреної робочої копії джерела робочого процесу, щоб старіший коміт випуску не міг непомітно використовувати застарілі засоби випуску. До запуску будь-якого дочірнього процесу публікації засіб формує й кешує точний текст випуску GitHub. Якщо повний відповідний розділ CHANGELOG.md вкладається в обмеження GitHub у 125,000 символів і відповідну безпечну межу засобу формування у 125,000 байтів, сторінка містить цей точний розділ ## YYYY.M.PATCH разом із його заголовком. Якщо вихідний розділ не вкладається, сторінка зберігає точні згруповані редакційні примітки та замінює завеликий перелік внесків стабільним посиланням на повний перелік у прив’язаному до тегу CHANGELOG.md; часткові переліки й обрізані пункти ніколи не публікуються. Робочий процес вибирає повний або стислий текст до додавання ### Release verification; якщо завершальна частина підтвердження перевищила б обмеження, він зберігає канонічний текст і покладається натомість на незмінні долучені докази. Стабільні випуски, опубліковані в npm latest, стають останнім випуском GitHub, тоді як стабільні випуски обслуговування, залишені в npm beta, створюються з GitHub latest=false. Робочий процес також завантажує до випуску GitHub докази залежностей із попередньої перевірки, маніфест повної валідації та докази перевірки реєстру після публікації для реагування на інциденти після випуску. Він негайно виводить ідентифікатори дочірніх запусків, автоматично схвалює шлюзи середовища випуску, які дозволено схвалювати токену робочого процесу, підсумовує невдалі дочірні завдання із завершальними фрагментами журналів, заздалегідь створює чернетку сторінки випуску GitHub і паралельно з публікацією OpenClaw у npm просуває ресурси Windows та Android, завершує оформлення сторінки випуску й доказів залежностей після успішного завершення цих етапів, очікує на ClawHub щоразу, коли публікується OpenClaw у npm, а потім запускає перевірку бета-версії з довіреної основної гілки та завантажує докази після публікації для випуску GitHub, пакета npm, вибраних пакетів плагінів npm, вибраних пакетів ClawHub, ідентифікаторів запусків дочірніх робочих процесів і необов’язкового ідентифікатора запуску NPM Telegram. Засіб початкової перевірки ClawHub вимагає точний шлях і SHA робочого процесу з довіреної основної гілки, спроби запуску виробника й завершального процесу, SHA випуску, запитаний набір пакетів, незмінний кортеж артефакту пакета та артефакт завершального зчитування з реєстру; успішний застарілий запуск із посилання на випуск не приймається.

Потім запустіть перевірку прийнятності пакета після публікації для опублікованого пакета [email protected] або openclaw@beta. Якщо надісланий або опублікований попередній випуск потребує виправлення, створіть наступний відповідний номер попереднього випуску; ніколи не видаляйте й не переписуйте попередній.
Після невдалої спроби публікації не змінюйте SHA випуску, якщо тільки помилка не доводить наявність дефекту продукту або журналу змін. Відновлюйте успішні незмінні дочірні процеси й артефакти; ніколи повторно не збирайте й не публікуйте версію пакета, яка вже була успішно опублікована.
Для стабільного випуску продовжуйте лише після того, як перевірена бета-версія або кандидат у випуски матиме необхідні докази валідації. Публікація стабільної версії в npm також проходить через OpenClaw Release Publish, повторно використовуючи успішний артефакт попередньої перевірки через preflight_run_id. Готовність стабільного випуску macOS також вимагає запакованих .zip, .dmg, .dSYM.zip та оновленого appcast.xml у main; робочий процес публікації macOS автоматично публікує підписаний appcast у загальнодоступний main після перевірки ресурсів випуску або відкриває чи оновлює PR для appcast, якщо захист гілки блокує пряме надсилання. Готовність стабільного випуску Windows Hub вимагає підписаних ресурсів OpenClawCompanion-Setup-x64.exe, OpenClawCompanion-Setup-arm64.exe і OpenClawCompanion-SHA256SUMS.txt у випуску OpenClaw на GitHub. Передайте точний підписаний тег випуску openclaw/openclaw-windows-node як windows_node_tag, а схвалену для кандидата мапу дайджестів інсталяторів — як windows_node_installer_digests; OpenClaw Release Publish зберігає чернетку випуску, запускає Windows Node Release і перевіряє всі три ресурси перед публікацією.
Після публікації запустіть перевірку npm після публікації, за потреби окремий E2E-тест Telegram для опублікованого npm-пакета, коли потрібне підтвердження каналу після публікації, просування dist-tag за потреби, перевірте сформовану сторінку випуску GitHub, виконайте кроки оголошення випуску, а потім завершіть закриття стабільного випуску в основній гілці, перш ніж вважати стабільний випуск завершеним.

Закриття стабільного випуску в основній гілці

Публікацію стабільного випуску не завершено, доки main не міститиме фактичний стан випущеної версії.

Почніть зі свіжої останньої версії main. Перевірте release/YYYY.M.PATCH відносно неї та перенесіть уперед справжні виправлення, відсутні в main. Не зливайте бездумно адаптери сумісності, тестування чи валідації, призначені лише для випуску, у новішу main.
Для звичайного шляху встановіть main на випущену стабільну версію. У разі пізнього закриття можна використовувати main, якщо він уже перейшов на пізнішу стабільну версію OpenClaw CalVer; не знижуйте версію вже розпочатого циклу випуску лише заради закриття попереднього випуску. Засіб валідації все одно вимагає точний розділ журналу змін випущеної версії та запис appcast і фіксує фактичну версію та SHA main. Запустіть pnpm release:prep після будь-якої зміни кореневої версії, а потім pnpm deps:shrinkwrap:generate.
Зробіть так, щоб розділ ## YYYY.M.PATCH файлу CHANGELOG.md у main точно відповідав гілці випуску з тегом. Додайте стабільне оновлення appcast.xml, якщо випуск для Mac його опублікував.
Не додавайте YYYY.M.PATCH+1, бета-версію або порожній розділ майбутнього журналу змін до main, доки оператор явно не розпочне цей цикл випуску.
Запустіть pnpm release:generated:check, pnpm deps:shrinkwrap:check і OPENCLAW_TESTBOX=1 pnpm check:changed. Надішліть зміни, а потім перевірте, що origin/main містить випущену версію та журнал змін, перш ніж вважати стабільний випуск завершеним.
Підтримуйте змінні репозиторію RELEASE_ROLLBACK_DRILL_ID і RELEASE_ROLLBACK_DRILL_DATE актуальними після кожної приватної перевірки відкочування.

OpenClaw Stable Main Closeout починається з надсилання main, що містить випущену версію, журнал змін і appcast після публікації стабільного випуску. Він читає незмінні докази після публікації, щоб пов’язати випущений тег із його запусками повної валідації випуску та публікації, а потім перевіряє стан стабільної основної гілки, випуск, обов’язкове стабільне витримування та блокувальні докази продуктивності. Він долучає до випуску GitHub незмінний маніфест закриття та контрольну суму. Автоматичний тригер надсилання пропускає застарілі випуски, що передують незмінним доказам після публікації, і ніколи не вважає таке пропускання завершеним закриттям.

Повне закриття вимагає обох ресурсів і відповідної контрольної суми. Частковий маніфест повторно відтворює записані в ньому SHA main і перевірку відкочування для повторного створення ідентичних байтів, а потім долучає відсутню контрольну суму; недійсна пара або контрольна сума без маніфесту й надалі блокують процес. Запуск, ініційований надсиланням, без змінних репозиторію для перевірки відкочування пропускається без завершення закриття; відсутній або старший за 90 днів запис перевірки так само блокує ручне закриття на основі доказів. Приватні команди відновлення залишаються в інструкції, доступній лише супровідникам. Використовуйте ручний запуск лише для виправлення або повторного відтворення стабільного закриття, підкріпленого доказами.

Якщо батьківський процес публікації випуску завершився невдало лише після долучення незмінних доказів npm/плагінів, спочатку виправте й опублікуйте всі ресурси стабільного випуску для платформ. Потім супровідник може вручну запустити закриття з allow_failed_publish_recovery=true; цей режим приймає лише завершений невдало батьківський процес і додатково вимагає точні контракти ресурсів Android та Windows, дайджести SHA-256 GitHub, перевірку контрольних сум, походження Android і успішне просування Windows, запущене батьківським процесом, чиї перевірки Authenticode та схвалені для кандидата дайджести відповідають опублікованим інсталяторам, разом зі звичайними перевірками macOS/appcast. Автоматичне закриття після надсилання ніколи не вмикає цей режим відновлення.

Застарілий коригувальний тег резервного варіанта може повторно використовувати докази базового пакета лише тоді, коли коригувальний тег вказує на той самий вихідний коміт, що й базовий стабільний тег. Його випуск Android повторно використовує перевірений APK базового тегу й додає дані про походження для коригувального тегу. Коригування з іншим вихідним кодом має опублікувати й перевірити власні докази пакета та використовувати вищий Android versionCode.

Попередня перевірка випуску

Запустіть pnpm check:test-types перед попередньою перевіркою випуску, щоб тестовий TypeScript залишався охопленим поза швидшим локальним шлюзом pnpm check.
Запустіть pnpm check:architecture перед попередньою перевіркою випуску, щоб ширші перевірки циклів імпорту й архітектурних меж успішно проходили поза швидшим локальним шлюзом.
Запустіть pnpm build && pnpm ui:build перед pnpm release:check, щоб очікувані артефакти випуску dist/* і пакет Control UI існували для етапу перевірки пакування.
Запустіть pnpm release:prep після підвищення кореневої версії та перед створенням тегу. Він запускає всі детерміновані генератори випуску, результати яких часто розходяться після зміни версії, конфігурації або API: версії плагінів, shrinkwrap-файли npm, реєстр плагінів, базову схему конфігурації, метадані конфігурації вбудованих каналів, базовий стан документації конфігурації, експорти SDK плагінів і базовий стан API SDK плагінів. pnpm release:check повторно запускає ці захисні перевірки в режимі перевірки (разом із перевіркою бюджету поверхні SDK плагінів) і за один прохід повідомляє про всі помилки розбіжностей у сформованих даних, перш ніж запускати перевірки випуску пакетів.
Синхронізація версій плагінів типово оновлює придатний до публікації пакет середовища виконання @openclaw/ai, версії пакетів офіційних плагінів і наявні мінімальні рівні openclaw.compat.pluginApi до версії випуску OpenClaw. Вважайте це поле мінімальним рівнем API SDK плагінів/середовища виконання, а не лише копією версії пакета: для випусків лише плагінів, які навмисно залишаються сумісними зі старішими хостами OpenClaw, зберігайте мінімальний рівень на найстарішій підтримуваній версії API хоста та задокументуйте цей вибір у доказах випуску плагіна.
Запустіть ручний робочий процес Full Release Validation перед схваленням випуску, щоб запустити всі тестові середовища попереднього випуску з єдиної точки входу. Він приймає гілку, тег або повний SHA коміту, запускає вручну CI і запускає OpenClaw Release Checks для базової перевірки встановлення, прийнятності пакета, міжплатформних перевірок пакета, узгодженості QA Lab, а також напрямів Matrix і Telegram. Стабільні й повні запуски завжди містять вичерпні інтерактивні/E2E-перевірки та витримування шляху випуску Docker; run_release_soak=true збережено для явного витримування бета-версії. Перевірка прийнятності пакета забезпечує канонічний E2E-тест Telegram пакета під час валідації кандидата, усуваючи потребу в другому паралельному засобі інтерактивного опитування.

Передайте release_package_spec після публікації бета-версії, щоб повторно використовувати випущений пакет npm у перевірках випуску, перевірці прийнятності пакета й E2E-тесті Telegram пакета без повторного збирання tarball випуску. Передавайте npm_telegram_package_spec лише тоді, коли Telegram має використовувати інший опублікований пакет, ніж решта засобів валідації випуску. Передавайте package_acceptance_package_spec, коли перевірка прийнятності пакета має використовувати інший опублікований пакет, ніж зазначено в специфікації пакета випуску. Передавайте evidence_package_spec, коли звіт про докази випуску має підтвердити, що валідація відповідає опублікованому пакету npm, без примусового запуску E2E-тесту Telegram.
bash
```
node scripts/full-release-validation-at-sha.mjs \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH
```
Запускайте вручну робочий процес Package Acceptance, коли потрібне підтвердження через побічний канал для кандидата пакета, поки робота над випуском триває. Використовуйте source=npm для openclaw@beta, openclaw@latest або точної версії випуску; source=ref, щоб запакувати довірену гілку/тег/SHA package_ref за допомогою поточного комплексу workflow_ref; source=url для загальнодоступного tarball через HTTPS з обов’язковою контрольною сумою SHA-256 і суворою політикою загальнодоступних URL-адрес; source=trusted-url для іменованої політики довіреного джерела з обов’язковими trusted_source_id і SHA-256; або source=artifact для tarball, завантаженого іншим запуском GitHub Actions.

Робочий процес перетворює кандидата на package-under-test, повторно використовує планувальник випускного Docker E2E для цього tarball і може запускати QA Telegram для того самого tarball за допомогою telegram_mode=mock-openai або telegram_mode=live-frontier. Коли вибрані Docker-смуги містять published-upgrade-survivor, артефакт пакета є кандидатом, а published_upgrade_survivor_baseline вибирає опубліковану базову версію. update-restart-auth використовує пакет-кандидат і як установлений CLI, і як пакет, що тестується, тому перевіряє шлях керованого перезапуску команди оновлення кандидата.

Приклад:
bash
```
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 [email protected] -f telegram_mode=mock-openai
```
Поширені профілі:
- smoke: смуги встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації
- package: нативні для артефакту смуги пакета/оновлення/перезапуску/плагінів без OpenWebUI або активного ClawHub
- product: профіль пакета разом із каналами MCP, очищенням cron/субагентів, вебпошуком OpenAI та OpenWebUI
- full: частини шляху випуску Docker з OpenWebUI
- custom: точний вибір docker_lanes для цільового повторного запуску
Запускайте вручну безпосередньо робочий процес CI, коли потрібне лише детерміноване стандартне покриття CI для кандидата на випуск. Ручні запуски CI обходять визначення області за змінами та примусово запускають сегменти Linux Node, сегменти вбудованих плагінів, сегменти контрактів плагінів і каналів, сумісність із Node 22, check-*, check-additional-*, димові перевірки зібраних артефактів, перевірки документації, Python-навички, Windows, macOS і смуги i18n Control UI. Окремі ручні запуски CI виконують Android лише за запуску з include_android=true; Full Release Validation передає цей вхідний параметр своєму дочірньому процесу CI.
bash
```
gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true
```
Запускайте pnpm qa:otel:smoke під час перевірки телеметрії випуску. Він виконує QA-lab через локальний приймач OTLP/HTTP і перевіряє експорт трасувань, метрик і журналів, а також обмежені атрибути трасування та редагування вмісту й ідентифікаторів без потреби в Opik, Langfuse чи іншому зовнішньому збирачі.
Запускайте pnpm qa:otel:collector-smoke під час перевірки сумісності зі збирачем. Він спрямовує той самий експорт OTLP із QA-lab через справжній Docker-контейнер OpenTelemetry Collector перед перевірками локального приймача.
Запускайте pnpm qa:prometheus:smoke під час перевірки захищеного збирання даних Prometheus. Він виконує QA-lab, відхиляє неавтентифіковане збирання даних і перевіряє, що критично важливі для випуску сімейства метрик не містять вмісту запитів, необроблених ідентифікаторів, токенів автентифікації та локальних шляхів.
Запускайте pnpm qa:observability:smoke для послідовного виконання димових смуг OpenTelemetry та Prometheus із вихідного коду.
Запускайте pnpm release:check перед кожним випуском із тегом.
Попередня перевірка OpenClaw NPM Release створює докази щодо залежностей випуску перед пакуванням npm tarball. Шлюз перевірки вразливостей із рекомендацій npm блокує випуск. Звіти про ризики транзитивного маніфесту, належність залежностей/поверхню встановлення та зміни залежностей слугують лише доказами випуску. Звіт про зміни залежностей порівнює кандидата на випуск із попереднім досяжним тегом випуску. Попередня перевірка завантажує докази щодо залежностей як openclaw-release-dependency-evidence-<tag>, а також вбудовує їх у dependency-evidence/ всередині підготовленого артефакту попередньої перевірки npm. Справжній шлях публікації повторно використовує цей артефакт попередньої перевірки, а потім долучає ті самі докази до випуску GitHub як openclaw-<version>-dependency-evidence.zip.
Запускайте OpenClaw Release Publish для послідовності публікації зі змінами після створення тегу. Запускайте звичайні бета- та стабільні публікації з довіреного main; тег випуску все одно вибирає точний цільовий коміт і може вказувати на release/YYYY.M.PATCH. Альфа-публікації Tideclaw залишаються у відповідній альфа-гілці. Передавайте успішний preflight_run_id npm OpenClaw, успішний full_release_validation_run_id і точний full_release_validation_run_attempt, а також зберігайте стандартну область публікації плагінів all-publishable, якщо навмисно не виконується цільове виправлення. Робочий процес послідовно виконує публікацію плагінів у npm, публікацію плагінів у ClawHub і публікацію OpenClaw у npm, щоб основний пакет не публікувався раніше за його винесені плагіни; просування Windows і Android відбувається одночасно з публікацією основного пакета в npm на чернетковій сторінці випуску. Повторні запуски публікації можна продовжувати: якщо основну версію npm уже опубліковано, основний запуск пропускається після того, як робочий процес підтвердить відповідність tarball у реєстрі артефакту попередньої перевірки тегу; просування Windows/Android пропускається, коли випуск уже містить перевірений контракт артефактів, тому повторна спроба повторює лише невдалі етапи. Цільові виправлення лише плагінів потребують plugin_publish_scope=selected і непорожнього списку плагінів. Запуски all-publishable лише для плагінів потребують повних незмінних доказів попередньої перевірки та повної перевірки випуску; часткові докази відхиляються.
Стабільний OpenClaw Release Publish потребує точного windows_node_tag після появи відповідного випуску openclaw/openclaw-windows-node, що не є попереднім, а також схваленої для кандидата мапи windows_node_installer_digests. Перед запуском будь-якого дочірнього процесу публікації він перевіряє, що вихідний випуск опублікований, не є попереднім, містить необхідні інсталятори x64/ARM64 і досі відповідає цій схваленій мапі. Потім він запускає Windows Node Release, поки випуск OpenClaw ще є чернеткою, передаючи закріплену мапу дайджестів інсталяторів без змін. Дочірній робочий процес завантажує підписані інсталятори Windows Hub із цього точного тегу, зіставляє їх із закріпленими дайджестами, на виконавці Windows перевіряє, що їхні підписи Authenticode використовують очікуваного підписанта OpenClaw Foundation, записує маніфест SHA-256 і завантажує інсталятори разом із маніфестом до канонічного випуску OpenClaw у GitHub, після чого повторно завантажує просунуті артефакти та перевіряє їхню наявність у маніфесті й хеші. Батьківський процес перевіряє поточний контракт артефактів x64, ARM64 і контрольних сум перед публікацією. Пряме відновлення відхиляє неочікувані назви артефактів OpenClawCompanion-* перед заміною очікуваних контрактних артефактів закріпленими байтами джерела.

Запускайте вручну Windows Node Release лише для відновлення та завжди передавайте точний тег, ніколи не latest, а також явну JSON-мапу expected_installer_digests зі схваленого вихідного випуску. Посилання для завантаження на вебсайті мають вести на точні URL-адреси артефактів поточного стабільного випуску OpenClaw або на releases/latest/download/... лише після перевірки, що перенаправлення GitHub на останній випуск веде на той самий випуск; не давайте посилання лише на сторінку випуску супровідного репозиторію.
Перевірки релізу тепер виконуються в окремому ручному робочому процесі: OpenClaw Release Checks. Він також запускає канал перевірки паритету макетів QA Lab, профіль релізу Matrix і канал QA Telegram перед схваленням релізу. Канали живих перевірок використовують середовище qa-live-shared; Telegram також використовує оренди облікових даних Convex CI. Запускайте ручний робочий процес QA-Lab - All Lanes з matrix_profile=all, коли потрібні всі підтримувані сценарії Matrix; робочий процес розподіляє цей вибір між профілями транспорту, медіа та E2EE, щоб повна перевірка вкладалася в обмеження часу кожного завдання.
Міжплатформна перевірка середовища виконання під час установлення й оновлення є частиною публічних OpenClaw Release Checks і Full Release Validation, які безпосередньо викликають повторно використовуваний робочий процес .github/workflows/openclaw-cross-os-release-checks-reusable.yml. Цей поділ навмисний: реальний шлях npm-релізу залишається коротким, детермінованим і зосередженим на артефактах, а повільніші живі перевірки виконуються в окремому каналі, щоб не затримувати й не блокувати публікацію.
Перевірки релізу, що використовують секрети, слід запускати через Full Release Validation або з посилання на робочий процес main/release, щоб логіка робочого процесу й секрети залишалися контрольованими.
OpenClaw Release Checks приймає гілку, тег або повний SHA коміту, якщо визначений коміт доступний із гілки OpenClaw або тегу релізу.
Попередня перевірка OpenClaw NPM Release, призначена лише для валідації, також приймає поточний повний 40-символьний SHA коміту гілки робочого процесу без вимоги опублікованого тегу. Цей шлях із SHA призначений лише для валідації, і його не можна просунути до реальної публікації. У режимі SHA робочий процес синтезує v<package.json version> лише для перевірки метаданих пакета; для реальної публікації все одно потрібен справжній тег релізу.
Обидва робочі процеси залишають шлях реальної публікації та просування на раннерах GitHub, тоді як незмінювальний шлях валідації може використовувати потужніші раннери Blacksmith Linux.
Цей робочий процес запускає OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache, використовуючи обидва секрети робочого процесу: OPENAI_API_KEY і ANTHROPIC_API_KEY.
Попередня перевірка npm-релізу більше не очікує на окремий канал перевірок релізу.
Перед локальним створенням тегу кандидата на реліз запустіть RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check. Допоміжний засіб послідовно запускає швидкі запобіжні перевірки релізу, перевірки релізу плагінів npm/ClawHub, збирання, збирання інтерфейсу та release:openclaw:npm:check, щоб виявити типові помилки, які блокують схвалення, до запуску робочого процесу публікації GitHub.
Перед схваленням запустіть RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (або відповідний тег попереднього чи виправного релізу).
Після публікації npm запустіть node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH (або відповідну бета- чи виправну версію), щоб перевірити шлях установлення з опублікованого реєстру в новому тимчасовому префіксі.
Після публікації бета-версії запустіть [email protected] OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live, щоб перевірити початкове налаштування встановленого пакета, налаштування Telegram і реальний наскрізний тест Telegram для опублікованого npm-пакета за допомогою спільного пулу орендованих облікових даних Telegram. Для одноразових локальних запусків супроводжувачі можуть не задавати змінні Convex, а натомість безпосередньо передати три облікові дані середовища OPENCLAW_QA_TELEGRAM_*.
Щоб запустити повну димову перевірку бета-версії після публікації з комп’ютера супроводжувача, скористайтеся pnpm release:beta-smoke -- --beta betaN. Допоміжний засіб запускає перевірку оновлення npm і нової цільової системи в Parallels, запускає NPM Telegram Beta E2E, опитує точний запуск робочого процесу, завантажує артефакт і виводить звіт Telegram.
Супроводжувачі можуть запустити ту саму перевірку після публікації з GitHub Actions за допомогою ручного робочого процесу NPM Telegram Beta E2E. Він навмисно запускається лише вручну й не виконується після кожного злиття.
Автоматизація релізів для супроводжувачів використовує схему «попередня перевірка, потім просування»:
- Реальна публікація npm має пройти успішну попередню перевірку npm preflight_run_id.
- Оркестрація та попередня перевірка звичайних бета- й стабільних публікацій використовують довірений main для точного цільового тегу. Публікація й попередня перевірка альфа-версії Tideclaw використовують відповідну альфа-гілку.
- Для стабільних npm-релізів типовим є beta; для стабільної публікації npm можна явно вибрати latest через вхідні дані робочого процесу.
- Зміна dist-tag npm на основі токена виконується в openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml, оскільки npm dist-tag add усе ще потребує NPM_TOKEN, тоді як репозиторій вихідного коду залишає публікацію лише через OIDC.
- Публічний macOS Release призначений лише для валідації; якщо тег існує лише в гілці релізу, але робочий процес запускається з main, задайте public_release_branch=release/YYYY.M.PATCH.
- Реальна публікація macOS має пройти успішні попередні перевірки macOS preflight_run_id і validate_run_id.
- Шляхи реальної публікації просувають підготовлені артефакти замість їх повторного збирання.
Для стабільних виправних релізів, як-от YYYY.M.PATCH-N, засіб перевірки після публікації також перевіряє той самий шлях оновлення з тимчасовим префіксом від YYYY.M.PATCH до YYYY.M.PATCH-N, щоб виправлення релізу не могли непомітно залишити старі глобальні встановлення на базовому стабільному пакеті.
Попередня перевірка npm-релізу завершується помилкою, якщо tarball не містить одночасно dist/control-ui/index.html і непорожній пакет dist/control-ui/assets/, щоб ми знову не випустили порожню браузерну панель керування.
Перевірка після публікації також перевіряє наявність точок входу опублікованих плагінів і метаданих пакета в структурі встановленого пакета з реєстру. Реліз без необхідних компонентів середовища виконання плагінів не проходить засіб перевірки після публікації та не може бути просунутий до latest.
pnpm test:install:smoke також забезпечує дотримання бюджету npm pack unpackedSize для tarball кандидата на оновлення, щоб наскрізний тест інсталятора виявляв випадкове роздування пакета до публікації релізу.
Якщо робота над релізом стосувалася планування CI, маніфестів тривалості розширень або матриць тестування розширень, перед схваленням повторно створіть і перевірте результати матриці plugin-prerelease-extension-shard, якими керує планувальник, із .github/workflows/plugin-prerelease.yml, щоб примітки до релізу не описували застарілу структуру CI.
Готовність стабільного релізу macOS також охоплює компоненти оновлення: реліз GitHub зрештою має містити запаковані .zip, .dmg і .dSYM.zip; appcast.xml у main після публікації має вказувати на новий стабільний zip-архів (робочий процес публікації macOS фіксує його автоматично або відкриває PR appcast, якщо пряме надсилання заблоковано); запакована програма має зберігати ідентифікатор пакета не для налагодження, непорожню URL-адресу каналу Sparkle і CFBundleVersion не нижче канонічного мінімального номера збирання Sparkle для цієї версії релізу.

Тестові середовища релізу

Full Release Validation дає операторам змогу запустити повну матрицю продукту з однієї точки входу. Використовуйте цей допоміжний засіб, щоб кожен дочірній робочий процес запускався з тимчасової гілки, зафіксованої на одному довіреному SHA робочого процесу main, а запитаний коміт залишався кандидатом для тестування:

bash

pnpm ci:full-release \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH

Допоміжний засіб отримує поточний origin/main, надсилає release-ci/<workflow-sha>-... на цьому довіреному коміті робочого процесу, визначає beta для альфа- й бета-версій пакетів і stable в інших випадках, запускає Full Release Validation із тимчасової гілки з ref=<target-sha>, перевіряє, що headSha кожного дочірнього робочого процесу відповідає закріпленому SHA батьківського робочого процесу, а потім видаляє тимчасову гілку. Передайте -f reuse_evidence=false, щоб примусово запустити нову перевірку, -f release_profile=full для широкої консультативної перевірки або --workflow-sha <trusted-main-sha>, щоб закріпити старіший коміт, який досі доступний із поточного origin/main. Сам робочий процес ніколи не записує посилання репозиторію. Це забезпечує доступність інструментів релізу лише з main без додавання інструментальних комітів до кандидата та запобігає випадковому використанню новішого дочірнього запуску main як доказу.

Коли Code SHA успішно пройде перевірки, зафіксуйте лише CHANGELOG.md і запустіть той самий допоміжний засіб із Release SHA:

bash

pnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH

Другий батьківський процес повторно використовує результати перевірки продукту, лише коли GitHub підтверджує, що Release SHA походить від Code SHA, а повний набір змінених шляхів точно дорівнює CHANGELOG.md. Він записує changelog-only-release-v1 і не запускає жодних дочірніх процесів продукту. Попередня перевірка npm і приймальні перевірки пакета та встановлення все одно виконуються для Release SHA, оскільки байти його tarball змінилися.

Для нового Code SHA робочий процес визначає ціль, запускає ручний CI, а потім запускає OpenClaw Release Checks. OpenClaw Release Checks розподіляє димову перевірку встановлення, міжплатформні перевірки релізу, живе/наскрізне покриття шляху релізу Docker, коли ввімкнено тривале тестування, Package Acceptance із канонічним наскрізним тестом пакета Telegram, перевірку паритету QA Lab, живий Matrix і живий Telegram. Повний запуск або запуск усіх перевірок прийнятний лише тоді, коли зведення Full Release Validation показує успішними normal_ci, plugin_prerelease і release_checks, за винятком випадків, коли під час цільового повторного запуску навмисно пропущено окремий дочірній процес Plugin Prerelease. Використовуйте окремий дочірній процес npm-telegram лише для цільового повторного запуску перевірки опублікованого пакета з release_package_spec або npm_telegram_package_spec. Підсумок остаточного засобу перевірки містить таблиці найповільніших завдань для кожного дочірнього запуску, щоб менеджер релізу міг бачити поточний критичний шлях без завантаження журналів.

Дочірній процес продуктивності продукту в цьому шляху релізу працює лише з артефактами. Парасольковий процес запускає його з publish_reports=false, а валідація відхиляється, якщо його захисна перевірка режиму лише артефактів не підтверджує, що публікатор звіту Clawgrit залишився пропущеним.

Повну матрицю етапів, точні назви завдань робочих процесів, відмінності між стабільним і повним профілями, артефакти та параметри цільового повторного запуску див. в розділі Повна валідація релізу.

Дочірні робочі процеси запускаються з довіреного посилання, закріпленого на SHA, яке виконує Full Release Validation. Кожен дочірній запуск має використовувати точний SHA батьківського робочого процесу. Не використовуйте безпосередні запуски --ref main -f ref=<sha> як доказ для релізу; використовуйте pnpm ci:full-release --sha <target-sha> --target-ref release/YYYY.M.PATCH.

Використовуйте release_profile, щоб вибрати широту живих перевірок і перевірок постачальників:

beta: найшвидший критичний для релізу шлях живих перевірок OpenAI/ядра та Docker
stable: бета-версія разом із покриттям стабільних постачальників і серверних систем для схвалення релізу
full: стабільна версія разом із широким консультативним покриттям постачальників і медіа

Стабільна й повна валідація завжди запускають вичерпну живу/наскрізну перевірку, перевірку шляху релізу Docker і обмежену перевірку збереження працездатності опублікованих оновлень перед просуванням. Використовуйте run_release_soak=true, щоб запросити таку саму перевірку для бета-версії. Вона охоплює чотири найновіші стабільні пакети, закріплені базові версії 2026.4.23 і 2026.5.2, а також покриття старіших 2026.4.15; дублікати базових версій видаляються, а кожна базова версія розподіляється в окреме завдання раннера Docker.

OpenClaw Release Checks використовує довірене посилання робочого процесу, щоб один раз визначити цільове посилання як release-package-under-test, і повторно використовує цей артефакт у міжплатформних перевірках, Package Acceptance і перевірках шляху релізу Docker під час тривалого тестування. Це зберігає однакові байти в усіх середовищах, що працюють із пакетом, і запобігає повторним збиранням пакета. Після того як бета-версія вже опублікована в npm, задайте [email protected], щоб перевірки релізу один раз завантажили випущений пакет, отримали SHA його вихідного коду збирання з dist/build-info.json і повторно використали цей артефакт для міжплатформних перевірок, Package Acceptance, шляху релізу Docker і каналів перевірки пакета Telegram.

Міжплатформна димова перевірка встановлення OpenAI використовує OPENCLAW_CROSS_OS_OPENAI_MODEL, коли задано змінну репозиторію або організації, а інакше — openai/gpt-5.6-luna, оскільки цей канал перевіряє встановлення пакета, початкове налаштування, запуск Gateway і один живий хід агента, а не вимірює продуктивність найпотужнішої моделі. Ширша матриця живих перевірок постачальників залишається місцем для покриття конкретних моделей.

Використовуйте ці варіанти залежно від етапу релізу:

bash

# Перевірте SHA коду повністю готового продукту.pnpm ci:full-release \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH # Перевірте SHA випуску зі змінами лише в журналі змін, повторно використовуючи докази продукту для SHA коду.pnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH # Після публікації бета-версії додайте Telegram E2E для опублікованого пакета.pnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH \  -f [email protected] \  -f [email protected] \  -f npm_telegram_provider_mode=mock-openai

Не використовуйте повний комплекс перевірок для першого повторного запуску після цільового виправлення. Якщо один блок завершується невдало, для наступної перевірки використовуйте дочірній робочий процес, завдання, Docker-смугу, профіль пакета, постачальника моделі або QA-смугу, де сталася помилка. Запускайте повний комплекс повторно лише тоді, коли виправлення змінило спільну оркестрацію випуску або зробило попередні докази для всіх блоків застарілими. Фінальний верифікатор комплексу повторно перевіряє записані ідентифікатори запусків дочірніх робочих процесів, тому після успішного повторного запуску дочірнього робочого процесу перезапустіть лише невдале батьківське завдання Verify full validation.

rerun_group=all може повторно використати попередній успішний запуск комплексу, якщо профіль випуску, фактичне налаштування тривалої перевірки та вхідні дані валідації збігаються, а цільовий SHA або ідентичний, або нова ціль є нащадком, повний набір змінених шляхів якого точно дорівнює CHANGELOG.md. Повторне використання для точної цілі записує exact-target-full-validation-v1; SHA випуску після валідації записує changelog-only-release-v1. Останній повторно використовує лише валідацію продукту. Попередня перевірка npm, байти пакета, походження приміток до випуску та приймальні перевірки встановлення й оновлення мають усе одно виконуватися для SHA випуску. Будь-яка зміна версії, джерела, згенерованих матеріалів, залежностей, пакета або цілі, якою керує робочий процес, вимагає нового SHA коду та нової повної валідації. Новіші запуски комплексу для того самого посилання release/* і групи повторного запуску автоматично замінюють ті, що виконуються. Передайте reuse_evidence=false, щоб примусово виконати новий повний запуск.

Для обмеженого відновлення передайте комплексу rerun_group. all — це справжній запуск кандидата на випуск, ci запускає лише звичайний дочірній процес CI, plugin-prerelease запускає лише дочірній процес плагінів, призначений виключно для випуску, release-checks запускає кожен блок випуску, а вужчі групи випуску — це install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live і npm-telegram. Цільові повторні запуски npm-telegram вимагають release_package_spec або npm_telegram_package_spec; повні запуски та запуски всього набору використовують канонічний Telegram E2E пакета всередині Package Acceptance. До цільових повторних запусків для кількох ОС можна додати cross_os_suite_filter=windows/packaged-upgrade або інший фільтр ОС чи набору. Помилки перевірок випуску QA блокують звичайну валідацію випуску, зокрема обов’язкову перевірку розбіжностей динамічних інструментів OpenClaw на стандартному рівні. Альфа-запуски Tideclaw усе ще можуть вважати смуги перевірки випуску, що не стосуються безпеки пакета, рекомендаційними. З release_profile=beta набори постачальників у реальному середовищі Run repo/live E2E validation є рекомендаційними (попередження, а не блокувальні помилки); у стабільному та повному профілях вони залишаються блокувальними. Коли live_suite_filter явно запитує контрольовану QA-смугу в реальному середовищі, як-от Discord, WhatsApp або Slack, відповідну змінну репозиторію OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED має бути ввімкнено; інакше отримання вхідних даних завершується помилкою замість непомітного пропуску смуги.

Vitest

Блок Vitest — це ручний дочірній робочий процес CI. Ручний CI навмисно обходить визначення області змін і примусово запускає звичайний граф тестів для кандидата на випуск: сегменти Linux Node, сегменти вбудованих плагінів, сегменти контрактів плагінів і каналів, сумісність із Node 22, check-*, check-additional-*, димові перевірки зібраних артефактів, перевірки документації, Python Skills, Windows, macOS та інтернаціоналізацію Control UI. Android включається, коли Full Release Validation запускає блок, оскільки комплекс передає include_android=true; для окремого ручного CI потрібен include_android=true, щоб охопити Android.

Використовуйте цей блок, щоб відповісти на запитання «чи пройшло дерево вихідного коду повний звичайний набір тестів?». Це не те саме, що валідація продукту шляхом випуску. Зберігайте такі докази:

зведення Full Release Validation, що показує URL запущеного виконання CI
успішне виконання CI для точного цільового SHA
назви невдалих або повільних сегментів із завдань CI під час дослідження регресій
артефакти часових показників Vitest, як-от .artifacts/vitest-shard-timings.json, коли запуск потребує аналізу продуктивності

Запускайте ручний CI безпосередньо лише тоді, коли випуску потрібен детермінований звичайний CI, але не потрібні блоки Docker, QA Lab, перевірок у реальному середовищі, кількох ОС або пакетів. Використовуйте першу команду для прямого CI без Android. Додайте include_android=true, коли прямий CI кандидата на випуск має охоплювати Android:

bash

gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCHgh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH -f include_android=true

Docker

Блок Docker міститься в OpenClaw Release Checks–openclaw-live-and-e2e-checks-reusable.yml, а також у робочому процесі режиму випуску install-smoke. Він перевіряє кандидата на випуск у пакетованих середовищах Docker, а не лише за допомогою тестів на рівні вихідного коду.

Покриття Docker для випуску включає:

повну димову перевірку встановлення з увімкненою повільною димовою перевіркою глобального встановлення Bun
підготовку або повторне використання образу для димової перевірки кореневого Dockerfile за цільовим SHA, причому завдання димових перевірок QR, кореня/Gateway та інсталятора/Bun виконуються як окремі сегменти димової перевірки встановлення
смуги E2E репозиторію
Docker-сегменти шляху випуску: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, від plugins-runtime-install-a до plugins-runtime-install-h і openwebui
покриття OpenWebUI на спеціальному виконавці з великим диском, коли це запитано
розділені смуги встановлення та видалення вбудованих плагінів від bundled-plugin-install-uninstall-0 до bundled-plugin-install-uninstall-23
набори постачальників у реальному середовищі/E2E та Docker-покриття моделей у реальному середовищі, коли перевірки випуску включають такі набори

Перед повторним запуском використовуйте артефакти Docker. Планувальник шляху випуску завантажує .artifacts/docker-tests/ із журналами смуг, summary.json, failures.json, часовими показниками фаз, JSON плану планувальника та командами повторного запуску. Для цільового відновлення використовуйте docker_lanes=<lane[,lane]> у придатному до повторного використання робочому процесі в реальному середовищі/E2E замість повторного запуску всіх сегментів випуску. Згенеровані команди повторного запуску включають попередній package_artifact_run_id і вхідні дані підготовлених образів Docker, коли вони доступні, тому невдала смуга може повторно використати той самий tar-архів та образи GHCR.

QA Lab

Блок QA Lab також є частиною OpenClaw Release Checks. Це шлюз випуску для агентної поведінки та рівня каналів, окремий від Vitest і механіки пакетів Docker.

Покриття QA Lab для випуску включає:

імітаційну смугу паритету, що порівнює смугу-кандидата OpenAI з базовою лінією anthropic/claude-opus-4-8 за допомогою пакета агентного паритету
профіль випуску адаптера Matrix у реальному середовищі з використанням середовища qa-live-shared
QA-смугу Telegram у реальному середовищі з використанням орендованих облікових даних Convex CI
pnpm qa:otel:smoke, pnpm qa:otel:collector-smoke, pnpm qa:prometheus:smoke або pnpm qa:observability:smoke, коли телеметрії випуску потрібен явний локальний доказ

Використовуйте цей блок, щоб відповісти на запитання «чи правильно поводиться випуск у сценаріях QA та потоках каналів у реальному середовищі?». Під час схвалення випуску зберігайте URL-адреси артефактів для смуг паритету, Matrix і Telegram. Повне покриття Matrix залишається доступним як ручний сегментований запуск QA Lab, а не як критична для випуску смуга за замовчуванням.

Пакет

Блок Package — це шлюз для продукту, придатного до встановлення. Він спирається на Package Acceptance і засіб визначення scripts/resolve-openclaw-package-candidate.mjs. Засіб визначення нормалізує кандидата в tar-архів package-under-test, який використовує Docker E2E, перевіряє склад пакета, записує версію пакета та SHA-256 і зберігає посилання середовища робочого процесу окремо від посилання джерела пакета.

Підтримувані джерела кандидатів:

source=npm: openclaw@beta, openclaw@latest або точна версія випуску OpenClaw
source=ref: пакування довіреної гілки, позначки або повного SHA коміту package_ref за допомогою вибраного середовища workflow_ref
source=url: завантаження загальнодоступного HTTPS-ресурсу .tgz з обов’язковим package_sha256; облікові дані в URL-адресі, нестандартні порти HTTPS, приватні, внутрішні або спеціально зарезервовані імена хостів чи визначені адреси, а також небезпечні переспрямування відхиляються
source=trusted-url: завантаження HTTPS-ресурсу .tgz з обов’язковими package_sha256 і trusted_source_id з іменованої політики в .github/package-trusted-sources.json; використовуйте це для корпоративних дзеркал або приватних репозиторіїв пакетів, якими керують супровідники, замість додавання до source=url можливості обходу приватної мережі на рівні вхідних даних
source=artifact: повторне використання .tgz, завантаженого іншим запуском GitHub Actions

OpenClaw Release Checks запускає Package Acceptance з source=artifact, підготовленим артефактом пакета випуску, suite_profile=custom, docker_lanes=doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor root-managed-vps-upgrade update-restart-auth plugins-offline plugin-update plugin-binding-command-escape, telegram_mode=mock-openai. Package Acceptance виконує міграцію, оновлення, оновлення VPS під керуванням root, перезапуск після оновлення з налаштованою автентифікацією, встановлення Skills із ClawHub у реальному середовищі, очищення застарілих залежностей плагінів, автономні фікстури плагінів, оновлення плагінів, захист від обходу прив’язки команд плагінів і QA пакета Telegram для того самого визначеного tar-архіву. Блокувальні перевірки випуску використовують за замовчуванням базову лінію останнього опублікованого пакета; бета-профіль з run_release_soak=true, release_profile=stable або release_profile=full розширює перевірку збереження працездатності після оновлення опублікованих версій до last-stable-4 разом із закріпленими базовими лініями 2026.4.23, 2026.5.2 і 2026.4.15 зі сценаріями reported-issues. Використовуйте Package Acceptance з source=npm для вже випущеного кандидата, source=ref для локального tar-архіву npm на основі SHA перед публікацією, source=trusted-url для корпоративного або приватного дзеркала під керуванням супровідників чи source=artifact для підготовленого tar-архіву, завантаженого іншим запуском GitHub Actions.

Це нативна для GitHub заміна більшої частини перевірок пакетів і оновлень, які раніше потребували Parallels. Перевірки випуску для кількох ОС усе ще важливі для специфічних для ОС процесів початкового налаштування, інсталяторів і поведінки платформи, але для валідації продукту щодо пакетів і оновлень варто віддавати перевагу Package Acceptance.

Канонічний контрольний список для валідації оновлень і плагінів наведено в розділі Тестування оновлень і плагінів. Використовуйте його, вирішуючи, яка локальна, Docker-, Package Acceptance- або release-check-смуга підтверджує зміну встановлення чи оновлення плагіна, очищення за допомогою doctor або міграції опублікованого пакета. Вичерпна міграція оновлення опублікованих версій із кожного стабільного пакета 2026.4.23+ є окремим ручним робочим процесом Update Migration, а не частиною Full Release CI.

Послаблення вимог застарілого процесу приймання пакетів навмисно обмежене в часі. Пакети до 2026.4.25 включно можуть використовувати шлях сумісності для прогалин метаданих, уже опублікованих у npm: відсутніх у tar-архіві приватних записів складу QA, відсутнього gateway install --wrapper, відсутніх файлів виправлень у git-фікстурі, отриманій із tar-архіву, відсутнього збереженого update.channel, застарілих розташувань записів установлення плагінів, відсутнього збереження записів установлення з маркетплейсу та міграції метаданих конфігурації під час plugins update. Опублікований пакет 2026.4.26 може видавати попередження щодо локальних файлів позначок метаданих збірки, які вже були випущені. Пізніші пакети мають відповідати сучасним контрактам пакетів; ті самі прогалини спричиняють помилку валідації випуску.

Використовуйте ширші профілі Package Acceptance, коли питання випуску стосується фактичного пакета, придатного до встановлення:

bash

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 [email protected]

Поширені профілі пакетів:

smoke: швидкі сценарії встановлення пакета/каналу/агента, мережі Gateway і перезавантаження конфігурації
package: контракти встановлення/оновлення/перезапуску/пакета плагіна та перевірка встановлення Skills із ClawHub наживо; це стандартний варіант перевірки релізу
product: package плюс канали MCP, очищення cron/підагентів, вебпошук OpenAI та OpenWebUI
full: частини шляху релізу Docker з OpenWebUI
custom: точний список docker_lanes для цільових повторних запусків

Для перевірки Telegram із пакетом-кандидатом увімкніть telegram_mode=mock-openai або telegram_mode=live-frontier у Package Acceptance. Робочий процес передає визначений tarball package-under-test до сценарію Telegram; окремий робочий процес Telegram і надалі приймає опубліковану специфікацію npm для перевірок після публікації.

Автоматизація публікації звичайного релізу

Для публікації бета-версії, latest, плагіна, GitHub Release і платформ OpenClaw Release Publish є звичайною точкою входу зі зміною стану. Щомісячний шлях лише для npm розширеної стабільної версії .33+ не використовує цей оркестратор. Звичайний робочий процес оркеструє робочі процеси довіреного видавця в порядку, потрібному для релізу:

Отримати тег релізу та визначити SHA його коміту.
Перевірити, що тег досяжний із main або release/* (або з альфа-гілки Tideclaw для попередніх альфа-релізів).
Запустити pnpm plugins:sync:check.
Запустити Plugin NPM Release із publish_scope=all-publishable та ref=<release-sha>.
Запустити Plugin ClawHub Release із тією самою областю дії та SHA.
Запустити OpenClaw NPM Release із тегом релізу, dist-тегом npm і збереженим preflight_run_id після перевірки збереженого full_release_validation_run_id і точної спроби запуску.
Для стабільних релізів створити або оновити GitHub release як чернетку, запустити Windows Node Release із явним windows_node_tag і схваленим для кандидата windows_node_installer_digests, а також перевірити канонічні ресурси інсталятора Windows і контрольних сум. Також запустити Android Release, щоб зібрати підписаний APK для точного тегу разом із контрольною сумою та даними про походження. Перед публікацією чернетки перевірити обидва контракти нативних ресурсів.

Приклад публікації бета-версії:

bash

gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH-beta.N \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=beta

Публікація стабільної версії зі стандартним dist-тегом beta:

bash

gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH \  -f windows_node_tag=vX.Y.Z \  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=beta

Безпосереднє просування стабільної версії до latest задається явно:

bash

gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH \  -f windows_node_tag=vX.Y.Z \  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=latest

Використовуйте низькорівневі робочі процеси Plugin NPM Release та Plugin ClawHub Release лише для цільового виправлення або повторної публікації. OpenClaw Release Publish відхиляє plugin_publish_scope=selected, коли publish_openclaw_npm=true, щоб основний пакет не можна було випустити без усіх офіційних плагінів, придатних до публікації, зокрема @openclaw/diffs-language-pack. Для виправлення вибраного плагіна задайте publish_openclaw_npm=false разом із plugin_publish_scope=selected та plugins=@openclaw/name або запустіть дочірній робочий процес безпосередньо.

Початкова публікація ClawHub є винятком: запустіть Plugin ClawHub New із довіреного main і передайте повний SHA цільового релізу через ref. Ніколи не запускайте сам робочий процес початкової публікації з тегу або гілки релізу:

bash

gh workflow run plugin-clawhub-new.yml \  --ref main \  -f plugins=@openclaw/name \  -f ref=<full-40-character-release-sha> \  -f pretag_validation=true \  -f dry_run=true

Перевірка перед створенням тегу вимагає dry_run=true, відхиляє вхідні дані тегу релізу та батьківського запуску й приймає лише точну ціль, досяжну з main або release/*. Вона не завантажує облікові дані ClawHub, не публікує байти пакета й не змінює конфігурацію довіреного видавця. Робочий процес усе одно визначає актуальний план реєстру, отримує та пакує ціль лише в завданні без секретів, формує зафіксований набір інструментів ClawHub і перевіряє незмінний артефакт та slug/ідентичність пакета до появи тегу релізу. Схвалюйте середовище clawhub-plugin-bootstrap лише після завершення завдань пакування без секретів; це захищене завдання перевірки не має облікових даних або команд, що змінюють стан.

Схвалений пробний запуск або справжня початкова публікація після створення тегу мають містити точний тег релізу, а також ідентифікатор, спробу та гілку батьківського запуску OpenClaw Release Publish. Батьківський процес засвідчує SHA власного робочого процесу й окремий точний довірений SHA main для Plugin ClawHub New; дочірній запуск і кожне схвалення захищеного середовища мають відповідати цьому схваленому SHA дочірнього процесу. Тег релізу повторно перевіряється перед кожною спробою публікації та зміною довіреного видавця.

Завдання пакування завантажує один незмінний артефакт, назва якого, ідентифікатор/дайджест артефакту Actions, запуск/спроба виробника, цільовий SHA та SHA-256/розмір tarball кожного пакета передаються до завдань перевірки й захищених завдань. Захищене завдання отримує лише довірені інструменти main, перевіряє кортеж артефакту через GitHub API, завантажує за точним ідентифікатором артефакту, повторно обчислює хеш кожного tarball і перевіряє локальні шляхи TAR та ідентичність пакета за правилами канонікалізації USTAR зафіксованої версії CLI. Кожен кандидат потім проходить пробну публікацію через зафіксовану версію CLI, яка завершується до звернення до реєстру або автентифікації. Попередній фільтр завдання з обліковими даними обмежує стиснені ClawPacks до 120 MiB, загальний обсяг корисних даних файлів до 50 MiB, розгорнуті дані TAR до 64 MiB, а кількість записів TAR — до 10,000. Виправлення довіреного видавця для наявного пакета залишається лише конфігураційним, але все одно пакує ціль і вимагає відповідності запитаного тегу, точних байтів реєстру та метаданих перед зміною конфігурації довіреного видавця. Перевірка після публікації завантажує артефакт ClawHub і вимагає тих самих SHA-256 та розміру. Відновлення через повторний запуск невдалих завдань може повторно використати артефакт пакета з попередньої спроби, лише якщо відповідне завдання-виробник успішно завершилося. Остаточні докази також пов’язують зафіксовану версію ClawHub, SHA-256 файлу блокування та цілісність npm. Невідповідність вимагає нової версії пакета.

Вхідні дані робочого процесу NPM

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

tag: обов’язковий тег релізу, наприклад v2026.4.2, v2026.4.2-1, v2026.4.2-beta.1 або v2026.4.2-alpha.1; коли preflight_only=true, це також може бути поточний повний 40-символьний SHA коміту гілки робочого процесу для попередньої перевірки без публікації
preflight_only: true лише для перевірки/збирання/пакування, false для справжнього шляху публікації
preflight_run_id: ідентифікатор наявного успішного попереднього запуску, обов’язковий для справжнього шляху публікації, щоб робочий процес повторно використовував підготовлений tarball замість його повторного збирання
full_release_validation_run_id: ідентифікатор успішного запуску Full Release Validation для цього тегу/SHA, обов’язковий для справжньої публікації. Публікації бета-версій можуть виконуватися лише на основі попередньої перевірки з попередженням, але просування стабільної версії/latest усе одно вимагає його.
full_release_validation_run_attempt: точний додатний номер спроби запуску, пов’язаний із full_release_validation_run_id; обов’язковий щоразу, коли надано ідентифікатор запуску, щоб повторні запуски не могли змінити докази авторизації під час публікації.
release_publish_run_id: ідентифікатор схваленого запуску OpenClaw Release Publish; обов’язковий, коли цей робочий процес запускається цим батьківським процесом (виклики справжньої публікації від бота)
plugin_npm_run_id: ідентифікатор успішного запуску Plugin NPM Release для точної вершини; обов’язковий для справжньої публікації основного пакета extended-stable
npm_dist_tag: цільовий тег npm для шляху публікації; приймає alpha, beta, latest або extended-stable і має стандартне значення beta. Остаточний патч 33 і пізніші мають використовувати extended-stable; за замовчуванням extended-stable відхиляє попередні патчі та завжди відхиляє неостаточні теги.
bypass_extended_stable_guard: логічне значення лише для тестування, стандартне значення false; разом із npm_dist_tag=extended-stable обходить щомісячні вимоги до розширеної стабільної версії, зберігаючи перевірки ідентичності релізу, артефакту, схвалення та зворотного зчитування.

Plugin NPM Release приймає npm_dist_tag=default для наявної поведінки релізу або npm_dist_tag=extended-stable для захищеного щомісячного шляху. Варіант розширеної стабільної версії вимагає publish_scope=all-publishable, порожнього вхідного значення plugins, остаточного патча не нижче 33 і канонічної гілки extended-stable/YYYY.M.33 на її точній вершині. Він ніколи не переміщує теги плагінів latest або beta. Нові версії пакетів отримують extended-stable атомарно через довірену публікацію OIDC (npm publish --tag extended-stable); цей початковий робочий процес не використовує npm dist-tag add з автентифікацією за токеном. Повторні спроби пропускають точні версії, які вже є в npm, а потім завершуються з помилкою, якщо повне зворотне зчитування не підтвердить, що кожен точний пакет і тег extended-stable збіглися.

OpenClaw Release Publish приймає такі вхідні дані, керовані оператором:

tag: обов’язковий тег релізу; він уже має існувати
preflight_run_id: ідентифікатор успішного попереднього запуску OpenClaw NPM Release; обов’язковий, коли publish_openclaw_npm=true або plugin_publish_scope=all-publishable
full_release_validation_run_id: ідентифікатор успішного запуску Full Release Validation; обов’язковий, коли publish_openclaw_npm=true або plugin_publish_scope=all-publishable
full_release_validation_run_attempt: точний додатний номер спроби, пов’язаний із full_release_validation_run_id; обов’язковий щоразу, коли надано ідентифікатор запуску
windows_node_tag: точний тег релізу openclaw/openclaw-windows-node, що не є попередньою версією; обов’язковий для публікації стабільної версії OpenClaw
windows_node_installer_digests: схвалена для кандидата компактна JSON-мапа поточних назв інсталяторів Windows до їхніх зафіксованих дайджестів sha256:; обов’язкова для публікації стабільної версії OpenClaw
npm_telegram_run_id: необов’язковий ідентифікатор успішного запуску NPM Telegram Beta E2E для включення до остаточних доказів релізу
npm_dist_tag: цільовий тег npm для пакета OpenClaw, один із alpha, beta або latest
plugin_publish_scope: стандартне значення all-publishable; використовуйте selected лише для цільового виправлення виключно плагінів разом із publish_openclaw_npm=false
plugins: розділені комами назви пакетів @openclaw/*, коли plugin_publish_scope=selected
publish_openclaw_npm: стандартне значення true; задавайте false лише за використання робочого процесу як оркестратора виправлення виключно плагінів
release_profile: профіль покриття релізу, який використовується для підсумків доказів релізу; стандартне значення from-validation, за якого він зчитується з маніфесту перевірки, або перевизначте його на beta, stable чи full
wait_for_clawhub: стандартне значення false, щоб доступність npm не блокувалася супровідним процесом ClawHub; задавайте true лише тоді, коли завершення робочого процесу має включати завершення ClawHub

OpenClaw Release Checks приймає такі вхідні дані, керовані оператором:

ref: гілка, тег або повний SHA коміту для перевірки. Перевірки, що використовують секрети, вимагають, щоб визначений коміт був доступний із гілки OpenClaw або тега випуску.
run_release_soak: увімкнути вичерпні перевірки в реальному середовищі/E2E, перевірки шляху випуску Docker і тривале тестування збереження працездатності після оновлень з усіх попередніх версій для перевірок бета-випуску. Цей параметр примусово вмикається за допомогою release_profile=stable і release_profile=full.

Правила:

Звичайні фінальні та коригувальні версії нижче патча 33 можна публікувати в beta або latest. Фінальні версії з патчем 33 або вище потрібно публікувати в extended-stable, а версії з коригувальним суфіксом на цій межі відхиляються.
Теги попередніх бета-версій можна публікувати лише в beta; теги попередніх альфа-версій — лише в alpha
Для OpenClaw NPM Release введення повного SHA коміту дозволено лише за умови preflight_only=true
OpenClaw Release Checks і Full Release Validation завжди призначені лише для перевірки
Фактичний шлях публікації має використовувати той самий npm_dist_tag, який використовувався під час попередньої перевірки; робочий процес перевіряє ці метадані, перш ніж продовжити публікацію

Послідовність звичайного бета-/останнього стабільного випуску

Ця застаріла послідовність призначена для звичайного оркестрованого випуску, який також охоплює плагіни, GitHub Release, Windows та роботу для інших платформ. Це не щомісячний npm-шлях розширеної стабільної версії .33+, описаний на початку цієї сторінки.

Під час підготовки звичайного оркестрованого стабільного випуску:

Запустіть OpenClaw NPM Release з preflight_only=true. До створення тега для пробного запуску робочого процесу попередньої перевірки без публікації можна використати поточний повний SHA коміту гілки робочого процесу.
Виберіть npm_dist_tag=beta для звичайного процесу, що починається з бета-версії, або latest лише коли навмисно потрібна безпосередня публікація стабільної версії.
Запустіть Full Release Validation у гілці випуску, за тегом випуску або повним SHA коміту, коли потрібно виконати звичайний CI разом із перевірками кешу запитів у реальному середовищі, Docker, QA Lab, Matrix і Telegram в одному ручному робочому процесі. Якщо навмисно потрібен лише детермінований звичайний граф тестування, натомість запустіть ручний робочий процес CI для посилання випуску.
Виберіть точний тег випуску openclaw/openclaw-windows-node, що не є попередньою версією, підписані інсталятори x64 і ARM64 якого мають бути випущені. Збережіть його як windows_node_tag, а перевірену мапу їхніх дайджестів — як windows_node_installer_digests. Допоміжний засіб для кандидата на випуск записує обидва значення та додає їх до згенерованої команди публікації.
Збережіть успішні preflight_run_id, full_release_validation_run_id і точний full_release_validation_run_attempt.
Запустіть OpenClaw Release Publish із довіреного main із тим самим tag, тим самим npm_dist_tag, вибраним windows_node_tag, його збереженим windows_node_installer_digests, збереженим preflight_run_id, full_release_validation_run_id і full_release_validation_run_attempt. Він публікує винесені назовні плагіни в npm і ClawHub перед просуванням npm-пакета OpenClaw.
Якщо випуск опубліковано в beta, використайте робочий процес openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml, щоб просунути цю стабільну версію з beta до latest.
Якщо випуск навмисно опубліковано безпосередньо в latest і beta має відразу вказувати на ту саму стабільну збірку, використайте той самий робочий процес випуску, щоб спрямувати обидва dist-теги на стабільну версію, або дозвольте запланованій самовідновлювальній синхронізації перемістити beta пізніше.

Зміна dist-тегів виконується в репозиторії реєстру випусків, оскільки вона все ще потребує NPM_TOKEN, тоді як вихідний репозиторій зберігає публікацію лише через OIDC. Завдяки цьому як шлях безпосередньої публікації, так і шлях просування після бета-версії залишаються задокументованими й видимими для оператора.

Якщо супровіднику доводиться повернутися до локальної автентифікації npm, усі команди CLI 1Password (op) слід запускати лише в окремому сеансі tmux. Не викликайте op безпосередньо з основної оболонки агента; виконання в tmux забезпечує видимість запитів, сповіщень та обробки OTP і запобігає повторним сповіщенням хоста.

Загальнодоступні посилання

Для фактичної покрокової інструкції супровідники використовують приватну документацію з випуску в openclaw/maintainers/release/README.md.

Пов’язане

Канали випуску

Was this useful?

Політика випусків

Найменування версій

Періодичність випусків

Щомісячна розширено стабільна публікація лише в npm

Контрольний список оператора звичайного випуску

Закриття стабільного випуску в основній гілці

Попередня перевірка випуску

Тестові середовища релізу

Vitest

Docker

QA Lab

Пакет

Автоматизація публікації звичайного релізу

Вхідні дані робочого процесу NPM

Послідовність звичайного бета-/останнього стабільного випуску

Загальнодоступні посилання

Пов’язане

On this page

Molty