Політика релізів

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

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

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

Назви версій

• Щомісячна версія випуску npm extended-stable: YYYY.M.PATCH, де PATCH >= 33
  • Git-тег: vYYYY.M.PATCH
• Щоденна/звичайна фінальна версія випуску: YYYY.M.PATCH, де PATCH < 33
  • Git-тег: vYYYY.M.PATCH
• Версія звичайного коригувального fallback-випуску: YYYY.M.PATCH-N
  • Git-тег: vYYYY.M.PATCH-N
• Версія beta-передвипуску: YYYY.M.PATCH-beta.N
  • Git-тег: vYYYY.M.PATCH-beta.N
• Не додавайте нулі на початку місяця або патча
• Починаючи з оновлення процесу випуску за червень 2026 року, третій компонент є послідовним щомісячним номером release-train, а не календарним днем. Stable- і beta- випуски визначають поточний train; теги лише alpha не використовують і не просувають номер beta/stable-патча. Теги й npm-версії до оновлення зберігають свої наявні назви та залишаються чинними; автоматизація випусків і надалі порівнює їх за роком, місяцем, патчем, каналом і номером передвипуску або корекції.
• Alpha/nightly-збірки використовують наступний неопублікований patch train і збільшують лише alpha.N для повторних збірок. Щойно цей патч отримує beta, нові alpha-збірки переходять до наступного патча. Ігноруйте застарілі теги лише alpha з більшими номерами патчів під час вибору beta- або stable-train.
• Версії npm незмінні. Якщо beta-тег уже опубліковано, не видаляйте, не публікуйте повторно й не використовуйте його повторно; створіть наступний beta-номер або наступний щомісячний патч. Оскільки 2026.6.5-beta.1 уже було опубліковано під час переходу, release trains за червень 2026 року мають використовувати патч 5 або вищий. Не публікуйте нові stable- або beta-trains за червень 2026 року як 2026.6.2, 2026.6.3 або 2026.6.4.
• Після звичайного фінального 2026.6.5 наступний новий beta train — 2026.6.6-beta.1, навіть якщо вже існують автоматизовані теги лише alpha з більшими номерами патчів.
• latest і надалі відповідає поточній звичайній/щоденній npm-лінії
• beta означає поточну ціль встановлення beta
• extended-stable означає підтримуваний npm-пакет за попередній місяць, починаючи з патча 33; патч 34 і пізніші є maintenance-випусками в цій щомісячній лінії
• Виділений щомісячний шлях extended-stable публікує лише core-пакет npm. Він не публікує plugins, артефакти macOS або Windows, GitHub Release, dist-tags приватного репозиторію, образи Docker, мобільні артефакти або завантаження з вебсайту.

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

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

Щомісячна публікація extended-stable лише в npm

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

Запустіть npm preflight і Повну перевірку випуску з точної гілки extended-stable, потім збережіть обидва ID запусків:

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 — це наявний профіль глибини перевірки; він окремий від npm dist-tag extended-stable і навмисно залишається без змін.

Після успішного завершення обох запусків і готовності середовища випуску npm просуньте точний preflight-тарбол. Патч P має бути 33 або більшим:

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>

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

Workflow публікації перевіряє ідентичності вказаних запусків, digest підготовленого тарболу та обидва selector-и npm registry. Незалежно підтвердьте результат після успішного завершення workflow:

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

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

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

Checklist оператора регулярного випуску

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

1. Почніть із поточного main: підтягніть найновіші зміни, підтвердьте, що цільовий коміт запушено, і підтвердьте, що поточний CI для main достатньо зелений, щоб від нього створювати гілку.
2. Згенеруйте верхній розділ CHANGELOG.md із змерджених PR і всіх прямих комітів від останнього досяжного релізного тегу. Тримайте записи орієнтованими на користувача, дедуплікуйте перетинні записи PR/прямих комітів, закомітьте переписування, запуште його і ще раз виконайте rebase/pull перед створенням гілки.
3. Перегляньте записи сумісності релізу в src/plugins/compat/registry.ts і src/commands/doctor/shared/deprecation-compat.ts. Видаляйте прострочену сумісність лише тоді, коли шлях оновлення лишається покритим, або зафіксуйте, чому її навмисно збережено.
4. Створіть release/YYYY.M.PATCH із поточного main; не виконуйте звичайну релізну роботу безпосередньо в main.
5. Підніміть кожну потрібну локацію версії для запланованого тегу, потім запустіть pnpm release:prep. Він оновлює версії Plugin, інвентар Plugin, схему config, метадані config для вбудованих каналів, baseline документації config, експорти Plugin SDK і baseline API Plugin SDK у правильному порядку. Закомітьте будь-який згенерований дрейф перед тегуванням. Потім запустіть локальний детермінований preflight: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build і pnpm release:check.
6. Запустіть OpenClaw NPM Release з preflight_only=true. До появи тегу повний 40-символьний SHA релізної гілки дозволено для preflight лише валідації. Preflight генерує докази релізу залежностей для точного витягнутого графа залежностей і зберігає їх в npm preflight артефакті. Збережіть успішний preflight_run_id.
7. Запустіть усі передрелізні тести через Full Release Validation для релізної гілки, тегу або повного SHA коміту. Це єдина ручна точка входу для чотирьох великих релізних тестових боксів: Vitest, Docker, QA Lab і Package.
8. Якщо валідація не пройшла, виправте в релізній гілці та перезапустіть найменший невдалий файл, lane, workflow job, package profile, provider або model allowlist, що доводить виправлення. Перезапускайте повний umbrella лише тоді, коли змінена поверхня робить попередні докази застарілими.
9. Для тегованого beta-кандидата запустіть pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N з відповідної гілки release/YYYY.M.PATCH. Для stable також передайте потрібний Windows source release: pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z. Помічник запускає локальні перевірки згенерованого релізу, dispatches або перевіряє повні докази release validation і npm preflight, запускає Parallels fresh/update proof проти точного підготовленого tarball плюс Telegram package proof, записує плани plugin npm і ClawHub та друкує точну команду OpenClaw Release Publish лише після того, як пакет доказів стає зеленим. OpenClaw Release Publish dispatches вибрані або всі придатні до публікації plugin packages до npm і той самий набір до ClawHub паралельно, а потім просуває підготовлений npm preflight artifact OpenClaw з відповідним dist-tag одразу після успішної публікації plugin npm. Після успіху дочірнього publish OpenClaw npm він створює або оновлює відповідну сторінку GitHub release/prerelease з повного відповідного розділу CHANGELOG.md. Stable-релізи, опубліковані в npm latest, стають GitHub latest release; stable maintenance releases, залишені в npm beta, створюються з GitHub latest=false. Workflow також завантажує preflight evidence залежностей, full-validation manifest і postpublish registry verification evidence до GitHub release для реагування на післярелізні інциденти. Publish workflow одразу друкує child run IDs, автоматично схвалює release environment gates, які workflow token має право схвалювати, підсумовує невдалі child jobs з хвостами логів, закриває GitHub release і dependency evidence щойно OpenClaw npm publish успішний, чекає ClawHub щоразу, коли публікується OpenClaw npm, потім запускає pnpm release:verify-beta і завантажує postpublish evidence для GitHub release, npm package, вибраних plugin npm packages, вибраних ClawHub packages, child workflow run IDs і необов’язкового NPM Telegram run ID. Шлях ClawHub повторює тимчасові збої встановлення залежностей CLI, публікує plugins, що пройшли preview, навіть коли одна preview cell flake, і завершується registry verification для кожної очікуваної версії Plugin, щоб часткові публікації лишалися видимими й придатними до повтору. Потім запустіть post-publish package acceptance проти опублікованого openclaw@YYYY.M.PATCH-beta.N або openclaw@beta package. Якщо запушений або опублікований prerelease потребує виправлення, виріжте наступний відповідний номер prerelease; не видаляйте й не переписуйте старий prerelease.
10. Для stable продовжуйте лише після того, як перевірений beta або release candidate має потрібні validation evidence. Stable npm publish також проходить через OpenClaw Release Publish, повторно використовуючи успішний preflight artifact через preflight_run_id; готовність stable macOS release також потребує упакованих .zip, .dmg, .dSYM.zip і оновленого appcast.xml у main. macOS publish workflow автоматично публікує підписаний appcast у публічний main після перевірки release assets; якщо branch protection блокує прямий push, він відкриває або оновлює appcast PR. Готовність Stable Windows Hub потребує підписаних assets OpenClawCompanion-Setup-x64.exe, OpenClawCompanion-Setup-arm64.exe і OpenClawCompanion-SHA256SUMS.txt в OpenClaw GitHub release. Передайте точний підписаний release tag openclaw/openclaw-windows-node як windows_node_tag і його схвалену кандидатом installer digest map як windows_node_installer_digests; OpenClaw Release Publish зберігає release draft, dispatches Windows Node Release і перевіряє всі три assets перед публікацією.
11. Після publish запустіть npm post-publish verifier, необов’язковий standalone published-npm Telegram E2E, коли потрібен post-publish channel proof, promotion dist-tag, коли потрібно, перевірте згенеровану сторінку GitHub release, запустіть кроки release announcement, потім завершіть закриття stable main, перш ніж називати stable release завершеним.

Закриття stable main

Stable-публікація не завершена, доки main не містить фактичний відвантажений стан релізу.

1. Почніть зі свіжого найновішого main. Проаудіюйте release/YYYY.M.PATCH відносно нього й forward-port реальні виправлення, яких немає в main. Не мержте сліпо release-only compatibility, test або validation adapters у новіший main.
2. Установіть main на відвантажену stable-версію, а не на спекулятивний наступний train. Запустіть pnpm release:prep після зміни root version, потім pnpm deps:shrinkwrap:generate.
3. Зробіть так, щоб розділ ## YYYY.M.PATCH у CHANGELOG.md на main точно збігався з тегованою релізною гілкою. Додайте оновлення stable appcast.xml, коли mac release його опублікував.
4. Не додавайте YYYY.M.PATCH+1, beta version або порожній майбутній changelog section до main, доки оператор явно не почне цей release train.
5. Запустіть pnpm release:generated:check, pnpm deps:shrinkwrap:check і OPENCLAW_TESTBOX=1 pnpm check:changed. Запуште, потім перевірте, що origin/main містить відвантажену версію та changelog, перш ніж називати stable release завершеним.
6. Тримайте repository variables RELEASE_ROLLBACK_DRILL_ID і RELEASE_ROLLBACK_DRILL_DATE актуальними після кожного приватного rollback drill. OpenClaw Stable Main Closeout стартує з push у main, який містить відвантажену версію, changelog і appcast після stable publication. Він читає незмінні postpublish evidence, щоб прив’язати відвантажений tag до його Full Release Validation і Publish runs, потім перевіряє stable main state, release, обов’язковий stable soak і blocking performance evidence. Він прикріплює незмінний closeout manifest і checksum до GitHub release. Автоматичний push trigger пропускає legacy releases, що передують незмінним postpublish evidence; він ніколи не трактує цей пропуск як завершений closeout. Повний closeout потребує обох assets і відповідного checksum. Частковий manifest відтворює записаний main SHA і rollback drill, щоб регенерувати ідентичні bytes, потім прикріплює відсутній checksum; недійсна пара або checksum без manifest лишається blocking. Push-triggered run без rollback drill repository variables пропускається без завершення closeout; відсутній або старіший за 90 днів drill record усе ще блокує manual evidence-backed closeout. Приватні recovery commands лишаються в maintainer-only runbook. Використовуйте manual dispatch лише для ремонту або replay evidence-backed stable closeout. Legacy fallback correction tag може повторно використати base-package evidence лише тоді, коли correction tag resolves до того самого source commit, що й base stable tag. Correction з іншим source має опублікувати й перевірити власні package evidence.

Release preflight

• Запустіть 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: версії plugin, інвентар plugin, базову схему конфігурації, метадані конфігурації вбудованих каналів, базову лінію документації конфігурації, експорти plugin SDK і базову лінію API plugin SDK. pnpm release:check повторно запускає ці запобіжники в режимі перевірки й повідомляє про кожен виявлений збій згенерованого розходження за один прохід перед запуском перевірок релізу пакета.
• Синхронізація версій plugin за замовчуванням оновлює версії пакетів офіційних plugin і наявні нижні межі openclaw.compat.pluginApi до версії релізу OpenClaw. Вважайте це поле нижньою межею API plugin SDK/runtime, а не просто копією версії пакета: для релізів лише plugin, які навмисно залишаються сумісними зі старішими хостами OpenClaw, залишайте нижню межу на найстарішому підтримуваному API хоста й документуйте цей вибір у доказах релізу plugin.
• Запустіть ручний робочий процес Full Release Validation перед затвердженням релізу, щоб запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку, тег або повний SHA коміту, запускає ручний CI і запускає OpenClaw Release Checks для install smoke, package acceptance, перевірок пакетів між ОС, паритету QA Lab, ліній Matrix і Telegram. Стабільні й повні запуски завжди містять вичерпні live/E2E та Docker release-path soak; run_release_soak=true збережено для явного beta soak. Package Acceptance надає канонічний package Telegram E2E під час перевірки кандидата, уникаючи другого паралельного live poller. Надайте release_package_spec після публікації beta, щоб повторно використати випущений npm-пакет у release checks, Package Acceptance і package Telegram E2E без повторного збирання релізного tarball. Надайте 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 tarball з обов’язковим SHA-256 і суворою політикою публічних URL; source=trusted-url для іменованої політики довіреного джерела з обов’язковими trusted_source_id і SHA-256; або source=artifact для tarball, завантаженого іншим запуском GitHub Actions. Цей робочий процес розв’язує кандидата до package-under-test, повторно використовує Docker E2E release scheduler проти цього tarball і може запускати Telegram QA проти того самого tarball з telegram_mode=mock-openai або telegram_mode=live-frontier. Коли вибрані Docker-лінії містять published-upgrade-survivor, артефакт пакета є кандидатом, а published_upgrade_survivor_baseline вибирає опубліковану базову лінію. update-restart-auth використовує пакет-кандидат як встановлений CLI і як package-under-test, щоб перевірити керований шлях перезапуску команди оновлення кандидата. Приклад: 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: install/channel/agent, мережа gateway і лінії перезавантаження конфігурації
  • package: package/update/restart/plugin-лінії, нативні для артефакта, без OpenWebUI або live ClawHub
  • product: профіль package плюс канали MCP, cron/subagent cleanup, вебпошук OpenAI і OpenWebUI
  • full: фрагменти Docker release-path з OpenWebUI
  • custom: точний вибір docker_lanes для сфокусованого повторного запуску
• Запустіть ручний робочий процес CI напряму, коли вам потрібне лише детерміноване нормальне покриття CI для кандидата релізу. Ручні запуски CI обходять changed scoping і примусово запускають шарди Linux Node, шарди bundled-plugin, шарди контрактів plugin і каналів, сумісність Node 22, check-*, check-additional-*, smoke-перевірки зібраних артефактів, перевірки документації, Python skills, Windows, macOS і лінії i18n Control UI. Окремі ручні запуски CI запускають Android лише коли їх запущено з include_android=true; Full Release Validation передає цей вхідний параметр своєму дочірньому CI. Приклад з Android: gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true
• Запустіть pnpm qa:otel:smoke під час перевірки релізної телеметрії. Він проганяє QA-lab через локальний OTLP/HTTP receiver і перевіряє експорт трас, метрик і логів, а також обмежені атрибути трас і редагування вмісту/ідентифікаторів без потреби в Opik, Langfuse або іншому зовнішньому колекторі.
• Запустіть pnpm qa:otel:collector-smoke під час перевірки сумісності колектора. Він спрямовує той самий OTLP-експорт QA-lab через реальний Docker-контейнер OpenTelemetry Collector перед локальними перевірками receiver.
• Запустіть pnpm qa:prometheus:smoke під час перевірки захищеного scraping Prometheus. Він проганяє QA-lab, відхиляє неавтентифіковані scrape-запити й перевіряє, що критичні для релізу сімейства метрик залишаються без вмісту prompt, сирих ідентифікаторів, auth tokens і локальних шляхів.
• Запустіть pnpm qa:observability:smoke, коли хочете виконати smoke-лінії OpenTelemetry і Prometheus із source-checkout одну за одною.
• Запустіть pnpm release:check перед кожним тегованим релізом
• Попередня перевірка OpenClaw NPM Release генерує релізні докази залежностей перед пакуванням npm tarball. Шлюз уразливостей npm advisory є блокувальним для релізу. Ризик транзитивного маніфесту, поверхня ownership/install залежностей і звіти про зміни залежностей є лише релізними доказами. Звіт про зміни залежностей порівнює кандидата релізу з попереднім досяжним релізним тегом.
• Попередня перевірка завантажує докази залежностей як openclaw-release-dependency-evidence-<tag> і також вбудовує їх у dependency-evidence/ всередині підготовленого npm preflight artifact. Реальний шлях публікації повторно використовує цей preflight artifact, а потім прикріплює ті самі докази до GitHub release як openclaw-<version>-dependency-evidence.zip.
• Запустіть OpenClaw Release Publish для мутувальної послідовності публікації після того, як тег існує. Запустіть його з release/YYYY.M.PATCH (або main, коли публікуєте тег, досяжний з main), передайте release tag, успішний OpenClaw npm preflight_run_id і успішний full_release_validation_run_id, і залиште стандартну область публікації plugin all-publishable, якщо ви не запускаєте свідомо сфокусоване виправлення. Робочий процес серіалізує публікацію plugin npm, публікацію plugin ClawHub і публікацію OpenClaw npm, щоб основний пакет не було опубліковано перед його externalized plugins.
• Стабільний OpenClaw Release Publish вимагає точний windows_node_tag після того, як існує відповідний непередрелізний реліз openclaw/openclaw-windows-node. Він також вимагає затверджену для кандидата мапу windows_node_installer_digests. Перед запуском будь-якого дочірнього процесу публікації він перевіряє, що вихідний реліз опублікований, не є передрелізним, містить потрібні інсталятори x64/ARM64 і все ще відповідає цій затвердженій мапі. Потім він запускає Windows Node Release, поки реліз OpenClaw ще є чернеткою, передаючи закріплену мапу digest інсталяторів без змін. Дочірній робочий процес завантажує підписані інсталятори Windows Hub з цього точного тегу, звіряє їх із закріпленими digest, перевіряє, що їхні підписи Authenticode використовують очікуваного підписанта OpenClaw Foundation на Windows runner, записує маніфест SHA-256 і завантажує інсталятори плюс маніфест до канонічного GitHub release OpenClaw, потім повторно завантажує просунуті assets і перевіряє належність до маніфесту та хеші. Батьківський процес перевіряє поточний контракт assets для x64, ARM64 і checksum перед публікацією. Пряме відновлення відхиляє неочікувані імена assets OpenClawCompanion-* перед заміною очікуваних contract assets закріпленими байтами джерела. Вручну запускайте Windows Node Release лише для відновлення і завжди передавайте точний тег, ніколи latest, плюс явну JSON-мапу expected_installer_digests із затвердженого вихідного релізу. Посилання для завантаження на сайті мають вказувати на точні URL release asset OpenClaw для поточного стабільного релізу або releases/latest/download/... лише після перевірки, що redirect GitHub latest вказує на той самий реліз; не посилайтеся лише на сторінку релізу companion repo.
• Перевірки релізу тепер виконуються в окремому ручному робочому процесі: OpenClaw Release Checks
• OpenClaw Release Checks також запускає лінію mock parity QA Lab плюс швидкий live-профіль Matrix і лінію Telegram QA перед затвердженням релізу. Live лінії використовують середовище qa-live-shared; Telegram також використовує оренди облікових даних Convex CI. Запустіть ручний робочий процес QA-Lab - All Lanes з matrix_profile=all і matrix_shards=true, коли хочете повний інвентар транспорту Matrix, медіа й E2EE паралельно.
• Крос-ОС перевірка інсталяції й оновлення runtime є частиною публічних OpenClaw Release Checks і Full Release Validation, які напряму викликають повторно використовуваний робочий процес .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• Це розділення навмисне: тримайте реальний npm release path коротким, детермінованим і сфокусованим на артефактах, тоді як повільніші live-перевірки залишаються у власній лінії, щоб вони не затримували й не блокували публікацію
• Релізні перевірки із секретами слід запускати через Full Release Validation або з workflow ref main/release, щоб логіка workflow і секрети залишалися контрольованими
• OpenClaw Release Checks приймає гілку, тег або повний SHA коміту, доки розв’язаний коміт досяжний з гілки OpenClaw або release tag
• Попередня перевірка OpenClaw NPM Release лише для валідації також приймає поточний повний 40-символьний SHA коміту workflow-branch без вимоги pushed tag
• Цей шлях SHA призначений лише для валідації й не може бути просунутий у реальну публікацію
• У режимі SHA робочий процес синтезує v<package.json version> лише для перевірки метаданих пакета; реальна публікація все одно вимагає справжній release tag
• Обидва робочі процеси тримають реальний шлях публікації й просування на GitHub-hosted runners, тоді як немутувальний шлях валідації може використовувати більші Blacksmith Linux runners
• Цей робочий процес запускає OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache з використанням workflow secrets OPENAI_API_KEY і ANTHROPIC_API_KEY
• npm release preflight більше не чекає на окрему лінію release checks
• Перед локальним тегуванням кандидата релізу запустіть RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check. Допоміжний засіб запускає швидкі релізні guardrails, перевірки релізу plugin npm/ClawHub, build, UI build і release:openclaw:npm:check у порядку, який ловить поширені помилки, що блокують затвердження, перед стартом GitHub publish workflow.
• Запустіть RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (або відповідний beta/correction tag) перед затвердженням
• Після публікації npm запустіть node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH (або відповідну beta/correction версію), щоб перевірити опублікований шлях встановлення з реєстру у свіжому тимчасовому префіксі
• Після публікації beta запустіть 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, щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E на опублікованому npm-пакеті з використанням спільного пулу орендованих облікових даних Telegram. Локальні одноразові запуски супровідників можуть опускати змінні Convex і передавати три env облікові дані OPENCLAW_QA_TELEGRAM_* напряму.
• Щоб запустити повний post-publish beta smoke із машини супровідника, використайте pnpm release:beta-smoke -- --beta betaN. Допоміжний інструмент виконує перевірку Parallels npm update/fresh-target, запускає NPM Telegram Beta E2E, опитує точний запуск workflow, завантажує артефакт і друкує звіт Telegram.
• Супровідники можуть запустити ту саму post-publish перевірку з GitHub Actions через ручний workflow NPM Telegram Beta E2E. Він навмисно лише ручний і не запускається під час кожного merge.
• Автоматизація release для супровідників тепер використовує preflight-then-promote:
  • реальна npm-публікація має пройти успішний npm preflight_run_id
  • реальна npm-публікація має бути запущена з тієї самої гілки main або release/YYYY.M.PATCH, що й успішний preflight-запуск
  • стабільні npm release за замовчуванням використовують beta
  • стабільна npm-публікація може явно націлюватися на latest через вхід workflow
  • мутація npm dist-tag на основі токена тепер живе в openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml, оскільки npm dist-tag add досі потребує NPM_TOKEN, тоді як вихідний repo зберігає публікацію лише через OIDC
  • публічний macOS Release призначений лише для перевірки; коли тег існує лише в release-гілці, але workflow запускається з main, задайте public_release_branch=release/YYYY.M.PATCH
  • реальна macOS-публікація має пройти успішні macOS preflight_run_id і validate_run_id
  • реальні шляхи публікації просувають підготовлені артефакти замість того, щоб збирати їх знову
• Для стабільних корекційних release, як-от YYYY.M.PATCH-N, post-publish верифікатор також перевіряє той самий шлях оновлення з тимчасовим префіксом із YYYY.M.PATCH до YYYY.M.PATCH-N, щоб корекції release не могли непомітно залишити старіші глобальні встановлення на базовому стабільному payload
• npm release preflight завершується закритою помилкою, якщо tarball не містить одночасно dist/control-ui/index.html і непорожній payload dist/control-ui/assets/, щоб ми знову не відвантажили порожній browser dashboard
• Post-publish перевірка також перевіряє, що опубліковані entrypoint-и plugin і метадані пакета присутні у встановленій структурі реєстру. Release, який постачає відсутні runtime payload-и plugin, провалює postpublish верифікатор і не може бути просунутий до latest.
• pnpm test:install:smoke також забезпечує бюджет npm pack unpackedSize для candidate update tarball, тож installer e2e виявляє випадкове роздування пакета до шляху публікації release
• Якщо release-робота зачепила CI-планування, extension timing manifests або extension test matrices, повторно згенеруйте й перегляньте належні planner-у matrix-виходи plugin-prerelease-extension-shard з .github/workflows/plugin-prerelease.yml перед схваленням, щоб release notes не описували застарілий CI layout
• Готовність стабільного macOS release також включає поверхні updater:
  • GitHub release має зрештою містити запаковані .zip, .dmg і .dSYM.zip
  • appcast.xml на main має вказувати на новий стабільний zip після публікації; workflow публікації macOS комітить його автоматично або відкриває appcast PR, коли прямий push заблоковано
  • запакований app має зберігати non-debug bundle id, непорожній Sparkle feed URL і CFBundleVersion на рівні або вище канонічної нижньої межі Sparkle build для цієї версії release

Тестові бокси релізу

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

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

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

Для валідації релізної гілки або тегу запускайте її з довіреного workflow-ref 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

Workflow визначає цільовий ref, запускає ручний CI з target_ref=<release-ref>, а потім запускає OpenClaw Release Checks. OpenClaw Release Checks розгалужується на install smoke, крос-ОС релізні перевірки, покриття live/E2E Docker релізного шляху, коли soak увімкнено, Package Acceptance з канонічним Telegram package E2E, QA Lab parity, live Matrix і live Telegram. Повний/all запуск прийнятний лише тоді, коли зведення Full Release Validation показує normal_ci, plugin_prerelease і release_checks як успішні, якщо лише сфокусований повторний запуск навмисно не пропустив окремий дочірній Plugin Prerelease. Використовуйте окремий дочірній npm-telegram лише для сфокусованого повторного запуску опублікованого пакета з release_package_spec або npm_telegram_package_spec. Підсумкове зведення верифікатора містить таблиці найповільніших завдань для кожного дочірнього запуску, щоб менеджер релізу міг бачити поточний критичний шлях без завантаження логів. Див. Повна валідація релізу, щоб переглянути повну матрицю етапів, точні назви завдань workflow, відмінності між stable і full profile, артефакти та ідентифікатори сфокусованих повторних запусків. Дочірні workflow запускаються з довіреного ref, який запускає Full Release Validation, зазвичай --ref main, навіть коли цільовий ref вказує на старішу релізну гілку або тег. Окремого workflow-ref вводу для Full Release Validation немає; вибирайте довірений harness, вибираючи ref запуску workflow. Не використовуйте --ref main -f ref=<sha> для доказу точного коміту на рухомій main; сирі commit SHA не можуть бути refs для workflow dispatch, тому використовуйте pnpm ci:full-release --sha <sha>, щоб створити закріплену тимчасову гілку.

Використовуйте release_profile, щоб вибрати ширину live/provider:

• minimum: найшвидший релізно-критичний live і Docker шлях OpenAI/core
• stable: minimum плюс покриття стабільних provider/backend для схвалення релізу
• full: stable плюс широке advisory-покриття provider/media

Валідація stable і full завжди запускає вичерпний live/E2E, Docker релізний шлях і обмежений sweep перевірки, що опубліковане оновлення переживає upgrade, перед promotion. Використовуйте run_release_soak=true, щоб запросити такий самий sweep для beta. Цей sweep охоплює останні чотири stable пакети плюс закріплені базові версії 2026.4.23 і 2026.5.2 плюс старіше покриття 2026.4.15, з видаленими дубльованими базовими версіями та кожною базовою версією, розбитою в окреме завдання Docker runner.

OpenClaw Release Checks використовує довірений workflow ref, щоб один раз визначити цільовий ref як release-package-under-test, і повторно використовує цей артефакт у крос-ОС, Package Acceptance і Docker перевірках релізного шляху, коли запускається soak. Це тримає всі бокси, що працюють із пакетом, на тих самих байтах і уникає повторних збірок пакета. Після того як beta вже опубліковано в npm, встановіть release_package_spec=openclaw@YYYY.M.PATCH-beta.N, щоб релізні перевірки один раз завантажили відвантажений пакет, витягли його build source SHA з dist/build-info.json і повторно використали цей артефакт для крос-ОС, Package Acceptance, Docker релізного шляху та package Telegram lanes. Крос-ОС OpenAI install smoke використовує OPENCLAW_CROSS_OS_OPENAI_MODEL, коли змінна repo/org задана, інакше openai/gpt-5.4, бо цей lane доводить інсталяцію пакета, onboarding, запуск gateway і один live agent turn, а не бенчмарк найповільнішої моделі за замовчуванням. Ширша live provider matrix залишається місцем для покриття, специфічного для моделей.

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

# Validate an unpublished release candidate branch.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 # Validate an exact pushed commit.gh workflow run full-release-validation.yml \  --ref main \  -f ref=<40-char-sha> \  -f provider=openai \  -f mode=both # After publishing a beta, add published-package Telegram E2E.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

Не використовуйте повну umbrella як перший повторний запуск після сфокусованого виправлення. Якщо один бокс падає, використовуйте для наступного доказу невдалий дочірній workflow, завдання, Docker lane, package profile, model provider або QA lane. Запускайте повну umbrella знову лише тоді, коли виправлення змінило спільну оркестрацію релізу або зробило попередні all-box докази застарілими. Підсумковий верифікатор umbrella повторно перевіряє записані run ids дочірніх workflow, тому після успішного повторного запуску дочірнього workflow повторно запустіть лише невдале батьківське завдання Verify full validation.

Для обмеженого відновлення передайте rerun_group в umbrella. all — це справжній запуск release-candidate, 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; full/all запуски використовують канонічний package Telegram E2E всередині Package Acceptance. Сфокусовані крос-ОС повторні запуски можуть додати cross_os_suite_filter=windows/packaged-upgrade або інший фільтр ОС/набору. Збої QA release-check блокують звичайну релізну валідацію, включно з обов’язковим OpenClaw dynamic tool drift у стандартному tier. Tideclaw alpha запуски все ще можуть вважати non-package-safety release-check lanes advisory. Коли live_suite_filter явно запитує gated QA live lane, як-от Discord, WhatsApp або Slack, відповідна repo-змінна OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED має бути увімкнена; інакше захоплення вводу завершується збоєм замість мовчазного пропуску lane.

Vitest

Бокс Vitest — це ручний дочірній workflow CI. Ручний CI навмисно обходить changed scoping і примусово запускає звичайний граф тестів для release candidate: Linux Node shards, bundled-plugin shards, plugin and channel contract shards, сумісність Node 22, check-*, check-additional-*, built-artifact smoke checks, docs checks, Python skills, Windows, macOS і Control UI i18n. Android включено, коли Full Release Validation запускає бокс, бо umbrella передає include_android=true; окремий ручний CI потребує include_android=true для покриття Android.

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

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

Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований звичайний CI, але не Docker, QA Lab, live, крос-ОС або package бокси. Використовуйте першу команду для прямого CI без Android. Додайте include_android=true, коли прямий release-candidate 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, плюс release-mode workflow install-smoke. Він валідовує release candidate через упаковані Docker середовища, а не лише тести на рівні джерел.

Релізне покриття Docker включає:

• повний install smoke з увімкненим повільним Bun global install smoke
• підготовку/повторне використання root Dockerfile smoke image за цільовим SHA, з QR, root/gateway і installer/Bun smoke jobs, що запускаються як окремі install-smoke shards
• repository E2E lanes
• release-path Docker chunks: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a, plugins-runtime-install-b, plugins-runtime-install-c, plugins-runtime-install-d, plugins-runtime-install-e, plugins-runtime-install-f, plugins-runtime-install-g і plugins-runtime-install-h
• покриття OpenWebUI всередині chunk plugins-runtime-services, коли запитано
• розділені bundled plugin install/uninstall lanes bundled-plugin-install-uninstall-0 до bundled-plugin-install-uninstall-23
• live/E2E provider suites і Docker live model coverage, коли релізні перевірки включають live suites

Використовуйте артефакти Docker перед повторним запуском. Планувальник release-path завантажує .artifacts/docker-tests/ з логами lane, summary.json, failures.json, таймінгами фаз, JSON плану планувальника та командами повторного запуску. Для сфокусованого відновлення використовуйте docker_lanes=<lane[,lane]> у reusable live/E2E workflow замість повторного запуску всіх release chunks. Згенеровані команди повторного запуску включають попередні package_artifact_run_id і підготовлені Docker image inputs, коли доступні, щоб невдалий lane міг повторно використати той самий tarball і GHCR images.

QA Lab

Бокс QA Lab також є частиною OpenClaw Release Checks. Це agentic behavior і channel-level release gate, окремо від Vitest і Docker package mechanics.

Релізне покриття QA Lab включає:

• mock parity lane, що порівнює candidate lane OpenAI з baseline Opus 4.6 за допомогою agentic parity pack
• fast live Matrix QA profile з використанням середовища qa-live-shared
• live Telegram QA lane з використанням Convex CI credential leases
• pnpm qa:otel:smoke, pnpm qa:otel:collector-smoke, pnpm qa:prometheus:smoke або pnpm qa:observability:smoke, коли release telemetry потребує явного локального доказу

Використовуйте цей бокс, щоб відповісти: «чи реліз поводиться правильно в QA scenarios і live channel flows?» Зберігайте artifact URLs для parity, Matrix і Telegram lanes під час схвалення релізу. Повне покриття Matrix залишається доступним як ручний sharded QA-Lab запуск, а не стандартний release-critical lane.

Package

Бокс Package — це gate інстальованого продукту. Він підтримується Package Acceptance і resolver scripts/resolve-openclaw-package-candidate.mjs. Resolver нормалізує candidate у tarball package-under-test, який споживає Docker E2E, перевіряє package inventory, записує версію пакета та SHA-256 і тримає workflow harness ref окремо від package source ref.

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

• source=npm: openclaw@beta, openclaw@latest або точна версія релізу OpenClaw
• source=ref: пакує довірену гілку, тег або повний SHA коміту package_ref з вибраним harness 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 update-restart-auth plugins-offline plugin-update, telegram_mode=mock-openai. Package Acceptance зберігає QA для міграції, оновлення, перезапуску оновлення з налаштованою автентифікацією, встановлення Skills із live ClawHub, очищення застарілих залежностей плагінів, offline-фікстур плагінів, оновлення плагінів і пакета Telegram на тому самому розв’язаному tarball. Блокувальні перевірки релізу використовують типову базову лінію останнього опублікованого пакета; beta-профіль із run_release_soak=true, release_profile=stable або release_profile=full розширюється до кожної стабільної базової лінії, опублікованої в npm, від 2026.4.23 до latest, а також фікстур повідомлених проблем. Використовуйте Package Acceptance із source=npm для вже випущеного кандидата, source=ref для локального npm tarball, підкріпленого SHA, перед публікацією, source=trusted-url для корпоративного/приватного дзеркала, яке супроводжують мейнтейнери, або source=artifact для підготовленого tarball, завантаженого іншим запуском GitHub Actions. Це нативна для GitHub заміна більшості покриття package/update, яке раніше вимагало Parallels. Крос-OS перевірки релізу все ще важливі для OS-специфічної адаптації, інсталятора та поведінки платформи, але продуктова перевірка package/update має надавати перевагу Package Acceptance.

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

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

Використовуйте ширші профілі 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: швидкі lanes встановлення пакета/каналу/агента, мережі Gateway і перезавантаження конфігурації
• package: контракти встановлення/оновлення/перезапуску/пакета плагіна плюс proof встановлення Skills із live ClawHub; це типовий профіль release-check
• product: package плюс MCP-канали, очищення cron/subagent, вебпошук OpenAI і OpenWebUI
• full: Docker chunks для релізного шляху з OpenWebUI
• custom: точний список docker_lanes для фокусних повторних запусків

Для Telegram proof кандидата пакета увімкніть telegram_mode=mock-openai або telegram_mode=live-frontier у Package Acceptance. Workflow передає розв’язаний tarball package-under-test у Telegram lane; окремий Telegram workflow все ще приймає опубліковану npm spec для перевірок після публікації.

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

Для beta, latest, плагіна, GitHub Release і публікації платформ OpenClaw Release Publish є звичайною мутаційною точкою входу. Щомісячний npm-only шлях extended-stable .33+ не використовує цей orchestrator. Регулярний workflow оркеструє trusted-publisher workflows у порядку, потрібному релізу:

1. Checkout релізного тегу й розв’язання його commit SHA.
2. Перевірка, що тег досяжний із main або release/*.
3. Запуск pnpm plugins:sync:check.
4. Dispatch Plugin NPM Release із publish_scope=all-publishable і ref=<release-sha>.
5. Dispatch Plugin ClawHub Release з тим самим scope і SHA.
6. Dispatch OpenClaw NPM Release із релізним тегом, npm dist-tag і збереженим preflight_run_id після перевірки збереженого full_release_validation_run_id.
7. Для стабільних релізів створення або оновлення GitHub release як draft, dispatch Windows Node Release з явним windows_node_tag і candidate-approved windows_node_installer_digests, а також перевірка канонічних assets інсталятора/checksum перед публікацією draft.

Приклад публікації beta:

gh workflow run openclaw-release-publish.yml \  --ref release/YYYY.M.PATCH \  -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 npm_dist_tag=beta

Публікація stable до типового beta dist-tag:

gh workflow run openclaw-release-publish.yml \  --ref release/YYYY.M.PATCH \  -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 npm_dist_tag=beta

Пряме просування stable до latest є явним:

gh workflow run openclaw-release-publish.yml \  --ref release/YYYY.M.PATCH \  -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 npm_dist_tag=latest

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

Вхідні дані NPM workflow

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

• tag: обов’язковий релізний тег, наприклад v2026.4.2, v2026.4.2-1 або v2026.4.2-beta.1; коли preflight_only=true, це також може бути поточний повний 40-символьний SHA коміту workflow-branch для validation-only preflight
• preflight_only: true лише для validation/build/package, false для реального шляху публікації
• preflight_run_id: обов’язковий на реальному шляху публікації, щоб workflow повторно використовував підготовлений tarball з успішного preflight-запуску
• full_release_validation_run_id: обов’язковий для реальної щомісячної extended-stable і регулярної non-beta публікації, щоб workflow автентифікував точний validation run
• npm_dist_tag: цільовий npm tag для шляху публікації; приймає alpha, beta, latest або extended-stable і типово дорівнює beta. Фінальний patch 33 і пізніші мають використовувати extended-stable; типово extended-stable відхиляє попередні patches і завжди відхиляє нефінальні теги.
• bypass_extended_stable_guard: testing-only boolean, типово false; з npm_dist_tag=extended-stable обходить eligibility для щомісячного extended-stable, зберігаючи ідентичність релізу, артефакт, approval і readback checks.

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

• tag: обов’язковий релізний тег; уже має існувати
• preflight_run_id: успішний run id preflight OpenClaw NPM Release; обов’язковий, коли publish_openclaw_npm=true
• full_release_validation_run_id: успішний run id Full Release Validation; обов’язковий, коли publish_openclaw_npm=true
• windows_node_tag: точний non-prerelease release tag openclaw/openclaw-windows-node; обов’язковий для публікації stable OpenClaw
• windows_node_installer_digests: candidate-approved compact JSON map поточних назв Windows installer до їхніх закріплених digest sha256:; обов’язковий для публікації stable OpenClaw
• npm_dist_tag: цільовий npm tag для пакета OpenClaw
• plugin_publish_scope: типово all-publishable; використовуйте selected лише для фокусного plugin-only repair з publish_openclaw_npm=false
• plugins: розділені комами назви пакетів @openclaw/*, коли plugin_publish_scope=selected
• publish_openclaw_npm: типово true; встановлюйте false лише коли використовуєте workflow як plugin-only repair orchestrator
• wait_for_clawhub: типово false, щоб доступність npm не блокувалася sidecar ClawHub; встановлюйте true лише коли завершення workflow має включати завершення ClawHub

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

• ref: гілка, тег або повний commit SHA для перевірки. Перевірки із secrets вимагають, щоб розв’язаний коміт був досяжний з гілки OpenClaw або релізного тегу.
• run_release_soak: opt into exhaustive live/E2E, Docker release-path і all-since upgrade-survivor soak для перевірок beta-релізу. Його примусово вмикають release_profile=stable і release_profile=full.

Правила:

• Регулярні фінальні та correction версії нижче patch 33 можуть публікуватися або до beta, або до latest. Фінальні версії з patch 33 або вище мають публікуватися до extended-stable, а версії з correction-suffix на цій межі відхиляються.
• Beta prerelease tags можуть публікуватися лише до beta
• Для OpenClaw NPM Release вхідний повний commit SHA дозволений лише коли preflight_only=true
• OpenClaw Release Checks і Full Release Validation завжди є validation-only
• Реальний шлях публікації має використовувати той самий npm_dist_tag, який використовувався під час preflight; workflow перевіряє, що метадані перед публікацією лишаються узгодженими

Послідовність регулярного beta/latest stable релізу

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

Під час підготовки регулярного orchestrated stable release:

1. Запустіть OpenClaw NPM Release з preflight_only=true
   • До появи тега можна використати поточний повний SHA коміту гілки workflow для dry run передрелізного workflow лише для перевірки
2. Виберіть npm_dist_tag=beta для звичайного потоку спочатку beta або latest лише тоді, коли ви навмисно хочете виконати пряму стабільну публікацію
3. Запустіть Full Release Validation на релізній гілці, релізному тегу або повному SHA коміту, коли потрібні звичайна CI, а також покриття live prompt cache, Docker, QA Lab, Matrix і Telegram з одного ручного workflow
4. Якщо вам навмисно потрібен лише детермінований звичайний граф тестів, натомість запустіть ручний workflow CI на релізному ref
5. Виберіть точний непререлізний тег релізу openclaw/openclaw-windows-node, чиї підписані інсталятори x64 і ARM64 мають бути випущені. Збережіть його як windows_node_tag, а їхню перевірену мапу дайджестів збережіть як windows_node_installer_digests. Допоміжний інструмент release-candidate записує обидва значення та включає їх у згенеровану команду публікації.
6. Збережіть успішні preflight_run_id і full_release_validation_run_id
7. Запустіть OpenClaw Release Publish з тим самим tag, тим самим npm_dist_tag, вибраним windows_node_tag, його збереженим windows_node_installer_digests, збереженим preflight_run_id і збереженим full_release_validation_run_id; він публікує винесені назовні plugins у npm і ClawHub перед просуванням npm-пакета OpenClaw
8. Якщо реліз потрапив у beta, використайте workflow openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml, щоб просунути цю стабільну версію з beta до latest
9. Якщо реліз навмисно було опубліковано напряму в latest, а beta має негайно вказувати на ту саму стабільну збірку, використайте той самий релізний workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій самовідновлювальній синхронізації перемістити beta пізніше

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

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

Якщо maintainer мусить повернутися до локальної автентифікації npm, запускайте будь-які команди 1Password CLI (op) лише всередині окремої сесії tmux. Не викликайте op безпосередньо з основної оболонки агента; утримання його всередині tmux робить prompts, сповіщення та обробку 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

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

Пов’язане

• Канали релізів