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

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-tag приватних репозиторіїв, образи Docker, мобільні артефакти або завантаження з вебсайту.
• Кожен звичайний фінальний випуск одночасно постачає пакет npm, застосунок macOS, підписаний автономний APK Android і підписані інсталятори Windows Hub. Бета-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а збирання, підписання, нотаризацію та просування нативних застосунків залишають для звичайного фінального випуску, якщо інше не запитано явно.

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

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

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

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

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

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

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-tag npm extended-stable і навмисно не змінюється.

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

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, включно з пакетами, вихідний код яких не змінився. Перед успішним завершенням він перевіряє кожен точний пакет і кожен тег Plugin extended-stable. Якщо частковий запуск завершиться помилкою, повторіть ту саму команду: уже опубліковані пакети буде використано повторно, відсутні або застарілі теги Plugin буде узгоджено в середовищі випуску npm, а фінальне зворотне зчитування все одно охоплюватиме повний набір пакетів.

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

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 і селектори реєстру основного пакета. Після успішного завершення робочого процесу незалежно підтвердьте результат:

npm view openclaw@YYYY.M.P version --userconfig "$(mktemp)"npm view openclaw@extended-stable version --userconfig "$(mktemp)"

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

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

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

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

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

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

2. Згенеруйте верхній розділ CHANGELOG.md зі злитих PR і всіх прямих комітів після останнього доступного тега випуску. Формулюйте записи для користувачів, усуньте дублювання між записами PR і прямих комітів, виконайте коміт і надсилання змін, а потім ще раз перебазуйтеся або отримайте зміни перед створенням гілки. Якщо розбіжний уже випущений тег або подальше перенесення змін уперед повторно пов’язує вже випущені PR, явно передайте цей тег через --shipped-ref; засіб перевірки використовує явні рядки PR із повних записів про внески в нумерованих розділах знімка тега, ігнорує Unreleased і фіксує точний перелік та кількість виключених PR.

3. Перегляньте записи сумісності випусків у src/plugins/compat/registry.ts і src/commands/doctor/shared/deprecation-compat.ts. Видаляйте сумісність, термін дії якої минув, лише якщо шлях оновлення залишається покритим, або зафіксуйте, чому її навмисно збережено.

4. Створіть release/YYYY.M.PATCH з актуальної гілки main. Не виконуйте звичайну роботу над випуском безпосередньо в main.

5. Оновіть усі обов’язкові розташування версії для тега, а потім виконайте pnpm release:prep. Ця команда послідовно оновлює версії плагінів, файли npm shrinkwrap, перелік плагінів, базову схему конфігурації, метадані конфігурації вбудованих каналів, базову версію документації конфігурації, експорти SDK плагінів і базову версію API SDK плагінів. Зафіксуйте всі згенеровані розбіжності до створення тега, а потім виконайте локальну детерміновану попередню перевірку: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build і pnpm release:check.

6. Запустіть OpenClaw NPM Release із preflight_only=true. До створення тега для попередньої перевірки, призначеної лише для валідації, дозволено повний 40-символьний SHA гілки випуску. Попередня перевірка генерує докази випуску залежностей для точної структури залежностей у поточній робочій копії та зберігає їх в артефакті попередньої перевірки npm. Збережіть успішний preflight_run_id.

7. Запустіть усі передвипускні тести через Full Release Validation для гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу для чотирьох великих наборів тестів випуску: Vitest, Docker, QA Lab і Package. Збережіть full_release_validation_run_id і точне значення full_release_validation_run_attempt; обидва є обов’язковими вхідними даними для OpenClaw NPM Release і OpenClaw Release Publish.

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

9. Для позначеного тегом бета-кандидата виконайте pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N з відповідної гілки release/YYYY.M.PATCH. Для стабільного випуску також передайте обов’язковий вихідний випуск Windows: pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z. Допоміжний засіб використовує довірену гілку main як джерело робочого процесу, тоді як кожен робочий процес спрямовано на точний тег. Він зберігає контрольну точку незмінної ідентичності кандидата й інструментарію, а також ідентифікатори запущених виконань у .artifacts/release-candidate/<tag>/release-candidate-state.json; повторне виконання тієї самої команди продовжує саме ці виконання, тоді як будь-яка розбіжність кандидата, інструментарію, профілю чи параметрів призводить до безпечної відмови. Перед запуском повної матриці валідації допоміжний засіб детерміновано формує точний текст випуску GitHub для тега та відхиляє відсутній заголовок версії, текст понад обмеження, для якого неможливо застосувати канонічну стислу форму, або походження бази чи цілі запису про внески, недоступне з тега. Він також перевіряє всі явні метадані виключення базової версії вже випущеного стану за відповідними накопичувальними записами тегів. Потім він виконує локальні перевірки згенерованого випуску, запускає або перевіряє повну валідацію випуску й докази попередньої перевірки npm, виконує перевірку свіжого встановлення та оновлення в Parallels для точно підготовленого tar-архіву разом із перевіркою пакета Telegram, фіксує плани публікації плагінів у npm і ClawHub та виводить точну команду OpenClaw Release Publish лише після успішної перевірки пакета доказів.

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

   Потім виконайте приймальну перевірку пакета після публікації для опублікованого пакета openclaw@YYYY.M.PATCH-beta.N або openclaw@beta. Якщо вже надісланий або опублікований попередній випуск потребує виправлення, створіть наступний відповідний номер попереднього випуску; ніколи не видаляйте й не переписуйте попередній.

10. Для стабільного випуску продовжуйте лише після того, як перевірена бета-версія або кандидат у випуск матиме необхідні докази валідації. Публікація стабільної версії в npm також виконується через OpenClaw Release Publish із повторним використанням успішного артефакту попередньої перевірки через preflight_run_id. Готовність стабільного випуску macOS також вимагає запакованих .zip, .dmg, .dSYM.zip і оновленого appcast.xml у main; робочий процес публікації macOS автоматично публікує підписаний канал оновлень у загальнодоступну гілку main після перевірки ресурсів випуску або відкриває чи оновлює PR для каналу оновлень, якщо захист гілки блокує пряме надсилання. Готовність стабільного 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 і перевіряє всі три ресурси перед публікацією.

11. Після публікації запустіть засіб перевірки npm після публікації, необов’язковий окремий E2E-тест Telegram для опублікованого npm-пакета, якщо потрібне підтвердження роботи каналу після публікації, за потреби просування dist-тега, перевірте згенеровану сторінку випуску GitHub, виконайте кроки оголошення випуску, а потім завершіть Завершення стабільного випуску в main, перш ніж вважати стабільний випуск завершеним.

Завершення стабільного випуску в main

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

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

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

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

Застарілий резервний тег виправлення може повторно використовувати докази базового пакета лише тоді, коли тег виправлення відповідає тому самому вихідному коміту, що й базовий стабільний тег. Його випуск 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: версії плагінів, файли npm shrinkwrap, інвентар плагінів, базову схему конфігурації, метадані конфігурації вбудованих каналів, базовий стан документації конфігурації, експорти 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 збережено для явного тривалого тестування бета-версії. Package Acceptance забезпечує канонічну пакетну перевірку Telegram E2E під час перевірки кандидата, уникаючи другого паралельного опитувача наживо.

  Укажіть release_package_spec після публікації бета-версії, щоб повторно використовувати опублікований пакет npm у перевірках релізу, Package Acceptance і пакетній перевірці Telegram E2E без повторного створення архіву релізу. Указуйте npm_telegram_package_spec лише тоді, коли Telegram має використовувати інший опублікований пакет, ніж решта перевірок релізу. Укажіть package_acceptance_package_spec, коли Package Acceptance має використовувати інший опублікований пакет, ніж зазначений у специфікації пакета релізу. Укажіть evidence_package_spec, коли звіт із доказами релізу має підтвердити, що перевірка відповідає опублікованому пакету npm, не вимагаючи Telegram E2E.

  gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.PATCH

• Запустіть вручну робочий процес Package Acceptance, коли потрібні незалежні докази для кандидата пакета, поки робота над релізом триває. Використовуйте source=npm для openclaw@beta, openclaw@latest або точної версії релізу; source=ref — щоб упакувати довірену гілку, тег або SHA package_ref із поточним набором перевірок workflow_ref; source=url — для загальнодоступного HTTPS-архіву з обов’язковою контрольною сумою SHA-256 і суворою політикою загальнодоступних URL; source=trusted-url — для іменованої політики довіреного джерела з обов’язковими trusted_source_id і SHA-256; або source=artifact — для архіву, завантаженого іншим запуском GitHub Actions.

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

  Приклад:

  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 published_upgrade_survivor_baseline=openclaw@2026.4.26 -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 Skills, Windows, macOS і напрями інтернаціоналізації Control UI. Окремі ручні запуски CI запускають Android лише з параметром include_android=true; Full Release Validation передає цей параметр своєму дочірньому процесу CI.

  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. Перевірка вразливостей за рекомендаціями 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 уже опубліковано, основний запуск пропускається після того, як робочий процес підтвердить відповідність архіву в реєстрі артефакту попередньої перевірки для тегу; просування Windows/Android пропускається, якщо реліз уже містить перевірений контракт ресурсів, тому повторна спроба виконує лише етапи, що завершилися помилкою. Цільові виправлення лише плагінів потребують plugin_publish_scope=selected і непорожнього списку плагінів. Запуски all-publishable лише для плагінів потребують повних незмінних доказів попередньої перевірки та Full Release Validation; часткові докази відхиляються.

• Стабільний 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_shards=true, коли потрібно паралельно виконати повний набір перевірок транспорту Matrix, медіа та E2EE.

• Міжплатформна перевірка встановлення й оновлення під час виконання є частиною загальнодоступних робочих процесів OpenClaw Release Checks і Full Release Validation, які безпосередньо викликають повторно використовуваний робочий процес .github/workflows/openclaw-cross-os-release-checks-reusable.yml. Такий поділ навмисний: реальний шлях випуску npm залишається коротким, детермінованим і зосередженим на артефактах, а повільніші живі перевірки виконуються в окремому контурі, щоб не затримувати й не блокувати публікацію.

• Перевірки випуску, що використовують секрети, слід запускати через Full Release Validation або з посилання робочого процесу main/випуску, щоб логіка робочого процесу й секрети залишалися під контролем.

• 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 (або команду з відповідною бета-/коригувальною версією), щоб перевірити шлях встановлення з опублікованого реєстру в новому тимчасовому префіксі.

• Після публікації бета-версії виконайте OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.PATCH-beta.N 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-тегів 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 завершується відмовою, якщо tar-архів не містить одночасно dist/control-ui/index.html і непорожній вміст dist/control-ui/assets/, щоб ми більше не випускали порожню браузерну панель керування.

• Перевірка після публікації також перевіряє наявність опублікованих точок входу плагінів і метаданих пакета у структурі встановлення з реєстру. Випуск без потрібного вмісту середовища виконання плагінів не проходить засіб перевірки після публікації й не може бути підвищений до latest.

• pnpm test:install:smoke також контролює бюджет unpackedSize npm-пакета для tar-архіву кандидата на оновлення, тому наскрізна перевірка інсталятора виявляє випадкове роздування пакета до проходження шляхом публікації випуску.

• Якщо робота над випуском торкнулася планування CI, маніфестів тривалості розширень або матриць тестування розширень, перед схваленням повторно згенеруйте та перевірте керовані планувальником вихідні дані матриці plugin-prerelease-extension-shard із .github/workflows/plugin-prerelease.yml, щоб примітки до випуску не описували застарілу структуру CI.

• Готовність стабільного випуску macOS також охоплює компоненти оновлення: випуск GitHub має зрештою містити запаковані .zip, .dmg і .dSYM.zip; файл appcast.xml у main після публікації має вказувати на новий стабільний zip-архів (робочий процес публікації macOS фіксує його автоматично або відкриває запит на злиття для appcast, якщо пряме надсилання змін заблоковано); запакована програма має зберігати ідентифікатор пакета, не призначений для налагодження, непорожню URL-адресу каналу Sparkle і CFBundleVersion, що не нижчий за канонічну мінімальну збірку Sparkle для цієї версії випуску.

Тестові середовища випуску

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

pnpm ci:full-release --sha <full-sha>

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

Для валідації гілки або тега випуску запустіть процес із довіреного посилання робочого процесу main і передайте гілку або тег випуску як ref:

gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=stable \  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N

Робочий процес визначає цільове посилання, запускає ручний CI з target_ref=<release-ref>, а потім запускає OpenClaw Release Checks. OpenClaw Release Checks паралельно запускає димову перевірку встановлення, міжплатформні перевірки випуску, живе/наскрізне Docker-покриття шляху випуску, коли ввімкнено тривале тестування, приймальне тестування пакета з канонічним наскрізним тестом пакета 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 залишився пропущеним.

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

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

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

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

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

OpenClaw Release Checks використовує довірене посилання робочого процесу, щоб один раз визначити цільове посилання як release-package-under-test, і повторно використовує цей артефакт у міжплатформних перевірках, приймальному тестуванні пакета й Docker-перевірках шляху випуску під час тривалого тестування. Це забезпечує використання однакових байтів у всіх середовищах, що працюють із пакетом, і запобігає повторному складанню пакета. Після публікації бета-версії в npm установіть release_package_spec=openclaw@YYYY.M.PATCH-beta.N, щоб перевірки випуску один раз завантажили опублікований пакет, отримали SHA вихідного коду збірки з dist/build-info.json і повторно використали цей артефакт у міжплатформних перевірках, приймальному тестуванні пакета, Docker-перевірках шляху випуску та контурах перевірки пакета Telegram.

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

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

# Перевірити неопубліковану гілку кандидата на випуск.gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=stable # Перевірити конкретний надісланий коміт.gh workflow run full-release-validation.yml \  --ref main \  -f ref=<40-char-sha> \  -f provider=openai \  -f mode=both # Після публікації бета-версії додати наскрізне тестування Telegram для опублікованого пакета.gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=full \  -f release_package_spec=openclaw@YYYY.M.PATCH-beta.N \  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N \  -f npm_telegram_provider_mode=mock-openai

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

rerun_group=all може повторно використати попередній успішний запуск комплексу лише тоді, коли він перевіряв точно той самий цільовий SHA, профіль випуску, фактичне налаштування тривалого тестування та вхідні дані перевірки. Це обмежене відновлення для повторного запуску того самого кандидата, а не повторне використання доказів між різними SHA. Для зміненого кандидата, зокрема коміту, що змінює лише журнал змін або версію, повторно запустіть кожну перевірку пакета, артефакту, встановлення, Docker або постачальника, на яку впливають змінені шляхи чи хеші артефактів. Новіші запуски комплексу для того самого посилання release/* і тієї самої групи повторного запуску автоматично замінюють запуски, що виконуються. Передайте reuse_evidence=false, щоб примусово виконати новий повний запуск.

Для обмеженого відновлення передайте комплексу rerun_group. all — це справжній запуск кандидата на випуск, ci запускає лише звичайний дочірній процес CI, plugin-prerelease — лише дочірній процес Plugin, призначений виключно для випуску, 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; повні запуски та запуски all використовують канонічне наскрізне тестування Telegram для пакета в межах Package Acceptance. До цільових повторних запусків для різних ОС можна додати cross_os_suite_filter=windows/packaged-upgrade або інший фільтр ОС/набору. Помилки перевірок випуску QA блокують звичайну перевірку випуску, зокрема обов’язкове виявлення розбіжностей динамічних інструментів OpenClaw на стандартному рівні. Альфа-запуски Tideclaw усе ще можуть вважати напрями перевірки випуску, що не стосуються безпеки пакета, рекомендаційними. З release_profile=beta набори для постачальників у реальному середовищі в Run repo/live E2E validation мають рекомендаційний характер (попередження, а не блокування); профілі stable і full залишають їх блокувальними. Коли live_suite_filter явно запитує керований напрям QA у реальному середовищі, як-от Discord, WhatsApp або Slack, відповідна змінна репозиторію OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED має бути ввімкнена; інакше отримання вхідних даних завершиться помилкою замість непомітного пропуску напряму.

Vitest

Блок Vitest — це дочірній робочий процес CI, який запускається вручну. Ручний CI навмисно обходить визначення області змін і примусово запускає звичайний граф тестів для кандидата на випуск: сегменти Linux Node, сегменти вбудованих Plugin, сегменти контрактів Plugin і каналів, сумісність із 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:

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, root/gateway та installer/Bun, що виконуються як окремі сегменти install-smoke
• напрями наскрізного тестування репозиторію
• фрагменти 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 на окремому виконавці з великим диском, коли це запитано
• розділені напрями встановлення й видалення вбудованих Plugin від bundled-plugin-install-uninstall-0 до bundled-plugin-install-uninstall-23
• набори постачальників для реального середовища й наскрізного тестування, а також охоплення моделей у реальному середовищі Docker, коли перевірки випуску включають набори для реального середовища

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

QA Lab

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

Охоплення QA Lab для випуску включає:

• напрям імітаційного зіставлення, який порівнює напрям кандидата OpenAI з базовим anthropic/claude-opus-4-8 за допомогою набору зіставлення поведінки агента
• швидкий профіль QA 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 Acceptance і розв’язувач scripts/resolve-openclaw-package-candidate.mjs. Розв’язувач нормалізує кандидата в tar-архів package-under-test, який використовується наскрізним тестуванням Docker, перевіряє склад пакета, записує версію пакета та SHA-256 і зберігає посилання на каркас робочого процесу окремо від посилання на джерело пакета.

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

• source=npm: openclaw@beta, openclaw@latest або точна версія випуску OpenClaw
• source=ref: пакування довіреної гілки package_ref, тегу або повного SHA коміту з вибраним каркасом 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 у реальному середовищі, очищення застарілих залежностей Plugin, автономні фікстури Plugin, оновлення Plugin, посилений захист від обходу прив’язки команд Plugin і QA пакета Telegram для того самого визначеного tar-архіву. Блокувальні перевірки випуску використовують стандартну базову версію останнього опублікованого пакета; бета-профіль із run_release_soak=true, release_profile=stable або release_profile=full розширює перевірку published-upgrade-survivor до 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.

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

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

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

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 published_upgrade_survivor_baseline=openclaw@2026.4.26

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

• 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 у перевірці прийнятності пакета. Робочий процес передає визначений tarball package-under-test до сценарію Telegram; окремий робочий процес Telegram, як і раніше, приймає опубліковану специфікацію npm для перевірок після публікації.

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

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

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

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

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:

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 задається явно:

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. Ніколи не запускайте сам робочий процес початкового завантаження з тегу чи гілки випуску:

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 і перевіряє незмінний артефакт, а також ідентифікатор/ідентичність пакета до появи тегу випуску. Схвалюйте середовище 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 МіБ, загальне корисне навантаження файлів — до 50 МіБ, розгорнуті дані TAR — до 64 МіБ, а кількість записів 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 для точного стану HEAD; обов’язковий для справжньої публікації основного пакета 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 для захищеного щомісячного шляху. Варіант 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, який використовувався під час попередньої перевірки; робочий процес перевіряє ці метадані, перш ніж продовжити публікацію

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

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

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

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

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

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

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

• .github/workflows/full-release-validation.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-npm-release.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• scripts/resolve-openclaw-package-candidate.mjs
• scripts/openclaw-npm-release-check.ts
• scripts/package-mac-dist.sh
• scripts/make_appcast.sh

Супроводжувачі використовують приватну документацію щодо випусків у openclaw/maintainers/release/README.md як фактичний посібник із виконання.

Пов’язане

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