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

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

​

Именование версий

• Версия стабильного релиза: YYYY.M.PATCH
  • Git-тег: vYYYY.M.PATCH
• Версия корректирующего стабильного релиза: YYYY.M.PATCH-N
  • Git-тег: vYYYY.M.PATCH-N
• Версия предварительного beta-релиза: YYYY.M.PATCH-beta.N
  • Git-тег: vYYYY.M.PATCH-beta.N
• Не дополняйте месяц или патч ведущими нулями
• Начиная с обновления процесса релизов в июне 2026 года, третий компонент — это последовательный номер ежемесячного релизного поезда, а не календарный день. Стабильные и beta-релизы определяют текущий поезд; теги только alpha не занимают и не продвигают номер патча beta/stable. Теги и npm-версии до обновления сохраняют существующие имена и остаются действительными; релизная автоматизация продолжает сравнивать их по году, месяцу, патчу, каналу и номеру предварительного или корректирующего релиза.
• Alpha/nightly-сборки используют следующий невыпущенный патч-поезд и увеличивают только alpha.N для повторных сборок. После появления beta для этого патча новые alpha-сборки переходят к следующему патчу. Игнорируйте устаревшие теги только alpha с более высокими номерами патчей при выборе beta- или стабильного поезда.
• npm-версии неизменяемы. Если beta-тег уже опубликован, не удаляйте, не публикуйте повторно и не используйте его заново; выпускайте следующий номер beta или следующий ежемесячный патч. Поскольку 2026.6.5-beta.1 уже был опубликован во время перехода, релизные поезда июня 2026 года должны использовать патч 5 или выше. Не публикуйте новые стабильные или beta-поезда июня 2026 года как 2026.6.2, 2026.6.3 или 2026.6.4.
• После стабильного 2026.6.5 следующий новый beta-поезд — 2026.6.6-beta.1, даже если уже существуют автоматизированные теги только alpha с более высокими номерами патчей.
• latest означает текущий продвинутый стабильный npm-релиз
• beta означает текущую целевую версию установки beta
• Стабильные и корректирующие стабильные релизы по умолчанию публикуются в npm beta; операторы релиза могут явно выбрать latest или позже продвинуть проверенную beta-сборку
• Каждый стабильный релиз OpenClaw поставляет npm-пакет, приложение macOS и подписанные установщики Windows Hub вместе; beta-релизы обычно сначала проверяют и публикуют путь npm/пакета, а сборка/подпись/нотаризация/продвижение нативного приложения резервируются для стабильного релиза, если явно не запрошено иное

​

Каденция релизов

• Релизы движутся сначала через beta
• Стабильный релиз следует только после проверки последней beta
• Мейнтейнеры обычно выпускают релизы из ветки release/YYYY.M.PATCH, созданной от текущей main, чтобы релизная проверка и исправления не блокировали новую разработку в main
• Если beta-тег был отправлен или опубликован и требует исправления, мейнтейнеры выпускают следующий тег -beta.N вместо удаления или пересоздания старого beta-тега
• Подробная процедура релиза, утверждения, учетные данные и заметки по восстановлению доступны только мейнтейнерам

​

Контрольный список оператора релиза

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, схему конфигурации, метаданные конфигурации встроенных каналов, baseline документации конфигурации, экспорты SDK Plugin и baseline API SDK Plugin в правильном порядке. Закоммитьте любой сгенерированный дрейф перед тегированием. Затем выполните локальную детерминированную предпроверку: 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.
8. Если валидация не проходит, исправьте в релизной ветке и повторно запустите минимальный упавший файл, lane, задание workflow, профиль пакета, provider или allowlist моделей, который доказывает исправление. Повторно запускайте полный зонтичный набор только когда измененная поверхность делает прежние свидетельства устаревшими.
9. Для тегированного beta-кандидата выполните pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N из соответствующей ветки release/YYYY.M.PATCH. Для stable также передайте требуемый исходный релиз Windows: pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z. Помощник выполняет локальные проверки сгенерированного релиза, запускает или проверяет полную релизную валидацию и свидетельства npm-предпроверки, выполняет Parallels fresh/update proof против точно подготовленного tarball плюс Telegram package proof, записывает планы npm Plugin и ClawHub и печатает точную команду OpenClaw Release Publish только после того, как пакет свидетельств зеленый. OpenClaw Release Publish параллельно отправляет выбранные или все публикуемые пакеты Plugin в npm и тот же набор в ClawHub, а затем продвигает подготовленный артефакт npm-предпроверки OpenClaw с соответствующим dist-tag, как только публикация Plugin в npm завершается успешно. После успешного завершения дочерней публикации OpenClaw в npm он создает или обновляет соответствующую страницу релиза/предрелиза GitHub из полного соответствующего раздела CHANGELOG.md. Стабильные релизы, опубликованные в npm latest, становятся последним релизом GitHub; стабильные maintenance-релизы, оставленные в npm beta, создаются с GitHub latest=false. Workflow также загружает свидетельства зависимостей предпроверки, манифест полной валидации и postpublish-свидетельства проверки реестра в GitHub release для реагирования на инциденты после релиза. Workflow публикации сразу печатает ID дочерних запусков, автоматически утверждает release environment gates, которые workflow token имеет право утверждать, суммирует неудачные дочерние задания с хвостами логов, закрывает GitHub release и свидетельства зависимостей сразу после успешной публикации OpenClaw в npm, ожидает ClawHub всякий раз, когда публикуется OpenClaw в npm, затем выполняет pnpm release:verify-beta и загружает postpublish-свидетельства для GitHub release, npm-пакета, выбранных npm-пакетов Plugin, выбранных пакетов ClawHub, ID дочерних workflow-запусков и необязательного ID запуска NPM Telegram. Путь ClawHub повторяет попытки при временных сбоях установки зависимостей CLI, публикует Plugin с успешным preview даже когда одна preview-ячейка нестабильна, и завершается проверкой реестра для каждой ожидаемой версии Plugin, чтобы частичные публикации оставались видимыми и пригодными для повторной попытки. Затем выполните post-publish package acceptance против опубликованного пакета openclaw@YYYY.M.PATCH-beta.N или openclaw@beta. Если отправленный или опубликованный prerelease требует исправления, выпускайте следующий соответствующий prerelease-номер; не удаляйте и не переписывайте старый prerelease.
10. Для stable продолжайте только после того, как проверенная beta или release candidate имеет требуемые свидетельства валидации. Публикация stable в npm также проходит через OpenClaw Release Publish, повторно используя успешный артефакт предпроверки через preflight_run_id; готовность stable-релиза macOS также требует упакованные .zip, .dmg, .dSYM.zip и обновленный appcast.xml в main. Workflow публикации macOS автоматически публикует подписанный appcast в публичную main после проверки релизных ассетов; если защита ветки блокирует прямой push, он открывает или обновляет PR appcast. Готовность stable Windows Hub требует подписанные ассеты OpenClawCompanion-Setup-x64.exe, OpenClawCompanion-Setup-arm64.exe и OpenClawCompanion-SHA256SUMS.txt на GitHub-релизе OpenClaw. Передайте точный подписанный тег релиза openclaw/openclaw-windows-node как windows_node_tag и его утвержденную кандидатом карту digest установщиков как windows_node_installer_digests; OpenClaw Release Publish сохраняет черновик релиза, запускает Windows Node Release и проверяет все три ассета перед публикацией.
11. После публикации выполните npm post-publish verifier, необязательный standalone опубликованный-npm Telegram E2E, когда нужно post-publish свидетельство канала, продвижение dist-tag при необходимости, проверьте сгенерированную страницу GitHub release, выполните шаги релизного объявления, затем завершите закрытие stable main, прежде чем считать стабильный релиз завершенным.

​

Закрытие stable 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, если релиз для Mac его опубликовал.
4. Не добавляйте YYYY.M.PATCH+1, бета-версию или пустой будущий раздел журнала изменений в main, пока оператор явно не начнет эту ветку релиза.
5. Запустите pnpm release:generated:check, pnpm deps:shrinkwrap:check и OPENCLAW_TESTBOX=1 pnpm check:changed. Выполните push, затем убедитесь, что origin/main содержит выпущенную версию и журнал изменений, прежде чем считать стабильный релиз завершенным.
6. Поддерживайте актуальность переменных репозитория RELEASE_ROLLBACK_DRILL_ID и RELEASE_ROLLBACK_DRILL_DATE после каждой приватной тренировки отката. OpenClaw Stable Main Closeout начинается с push в main, который несет выпущенную версию, журнал изменений и appcast после публикации стабильного релиза. Он читает неизменяемые доказательства после публикации, чтобы связать выпущенный тег с его запусками Full Release Validation и Publish, затем проверяет стабильное состояние main, релиз, обязательную стабильную выдержку и блокирующие доказательства производительности. Он прикрепляет неизменяемый манифест закрытия и контрольную сумму к релизу GitHub. Автоматический триггер push пропускает устаревшие релизы, которые предшествуют неизменяемым доказательствам после публикации; он никогда не считает такой пропуск завершенным закрытием. Полное закрытие требует наличия обоих артефактов и совпадающей контрольной суммы. Частичный манифест воспроизводит записанные в нем SHA main и тренировку отката, чтобы заново сгенерировать идентичные байты, затем прикрепляет отсутствующую контрольную сумму; недействительная пара или контрольная сумма без манифеста остаются блокирующими. Запуск, инициированный push, без переменных репозитория для тренировки отката пропускается без завершения закрытия; отсутствующая или более чем 90-дневная запись тренировки по-прежнему блокирует ручное закрытие, подкрепленное доказательствами. Приватные команды восстановления остаются в runbook только для сопровождающих. Используйте ручной dispatch только для исправления или повторного выполнения стабильного закрытия, подкрепленного доказательствами. Устаревший корректирующий fallback-тег может повторно использовать доказательства базового пакета только тогда, когда корректирующий тег разрешается в тот же исходный коммит, что и базовый стабильный тег. Коррекция с другим исходным кодом должна опубликовать и проверить собственные доказательства пакета.

​

Предварительная проверка релиза

• Выполните 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, базовую схему конфигурации, метаданные конфигурации встроенных каналов, базовый снимок документации конфигурации, экспорты SDK Plugin и базовый снимок API SDK Plugin. pnpm release:check повторно запускает эти проверки в режиме проверки и за один проход сообщает о каждом найденном сбое сгенерированного расхождения перед запуском проверок релиза пакета.
• Синхронизация версий Plugin по умолчанию обновляет версии официальных пакетов Plugin и существующие минимальные значения openclaw.compat.pluginApi до версии релиза OpenClaw. Считайте это поле минимальным уровнем API SDK/среды выполнения Plugin, а не просто копией версии пакета: для релизов только Plugin, которые намеренно остаются совместимыми со старыми хостами OpenClaw, оставляйте минимальный уровень равным самому старому поддерживаемому API хоста и документируйте этот выбор в доказательствах релиза Plugin.
• Запустите ручной рабочий процесс Full Release Validation перед одобрением релиза, чтобы запустить все предрелизные тестовые среды из одной точки входа. Он принимает ветку, тег или полный SHA коммита, запускает ручной CI и запускает OpenClaw Release Checks для установочного smoke-теста, приемки пакета, проверок пакета между ОС, паритета QA Lab, Matrix и дорожек Telegram. Стабильные и полные запуски всегда включают исчерпывающие live/E2E и Docker soak для релизного пути; run_release_soak=true сохраняется для явного beta soak. Package Acceptance предоставляет канонический пакетный Telegram E2E во время проверки кандидата, избегая второго параллельного live-опросчика. Укажите release_package_spec после публикации беты, чтобы повторно использовать выпущенный пакет npm в release checks, Package Acceptance и пакетном 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 против этого 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: дорожки установки/канала/агента, сети Gateway и перезагрузки конфигурации
  • package: дорожки пакета/обновления/перезапуска/Plugin, нативные для артефакта, без OpenWebUI или live ClawHub
  • product: профиль пакета плюс каналы MCP, очистка cron/субагентов, веб-поиск OpenAI и OpenWebUI
  • full: фрагменты релизного пути Docker с OpenWebUI
  • custom: точный выбор docker_lanes для сфокусированного повторного запуска
• Запускайте ручной рабочий процесс CI напрямую, когда нужно только детерминированное обычное покрытие CI для релизного кандидата. Ручные запуски CI обходят область измененных файлов и принудительно включают Linux Node shards, shards встроенных Plugin, shards контрактов 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 и проверяет экспорт трасс, метрик и логов, а также ограниченные атрибуты трасс и редактирование содержимого/идентификаторов без необходимости в Opik, Langfuse или другом внешнем сборщике.
• Запускайте pnpm qa:otel:collector-smoke при проверке совместимости со сборщиком. Он направляет тот же экспорт OTLP QA-lab через реальный Docker-контейнер OpenTelemetry Collector перед утверждениями локального приемника.
• Запускайте pnpm qa:prometheus:smoke при проверке защищенного сбора Prometheus. Он проверяет QA-lab, отклоняет неаутентифицированные обращения за сбором и проверяет, что критически важные для релиза семейства метрик не содержат содержимого промптов, сырых идентификаторов, токенов аутентификации и локальных путей.
• Запускайте pnpm qa:observability:smoke, когда нужно выполнить smoke-дорожки OpenTelemetry и Prometheus из исходного checkout подряд.
• Выполняйте pnpm release:check перед каждым помеченным тегом релизом
• Предварительная проверка OpenClaw NPM Release генерирует доказательства релиза зависимостей перед упаковкой npm tarball. Шлюз уязвимостей npm advisory блокирует релиз. Отчет о рисках транзитивного манифеста, поверхности владения/установки зависимостей и изменениях зависимостей служит только релизным доказательством. Отчет об изменениях зависимостей сравнивает релизного кандидата с предыдущим достижимым релизным тегом.
• Предварительная проверка загружает доказательства зависимостей как openclaw-release-dependency-evidence-<tag> и также встраивает их в dependency-evidence/ внутри подготовленного артефакта предварительной проверки npm. Реальный путь публикации повторно использует этот артефакт предварительной проверки, затем прикрепляет те же доказательства к релизу GitHub как openclaw-<version>-dependency-evidence.zip.
• Запустите OpenClaw Release Publish для изменяющей последовательности публикации после того, как тег существует. Запускайте его из release/YYYY.M.PATCH (или main при публикации тега, достижимого из main), передайте тег релиза, успешный preflight_run_id npm OpenClaw и успешный full_release_validation_run_id, и оставьте область публикации Plugin по умолчанию all-publishable, если вы не запускаете намеренно сфокусированное исправление. Рабочий процесс сериализует публикацию npm Plugin, публикацию ClawHub Plugin и публикацию npm OpenClaw, чтобы основной пакет не публиковался раньше своих вынесенных наружу Plugin.
• Стабильный OpenClaw Release Publish требует точный windows_node_tag после существования соответствующего не prerelease-релиза openclaw/openclaw-windows-node. Он также требует одобренную кандидатом карту windows_node_installer_digests. Перед запуском любого дочернего публикационного процесса он проверяет, что исходный релиз опубликован, не является prerelease, содержит обязательные установщики x64/ARM64 и по-прежнему соответствует этой одобренной карте. Затем он запускает Windows Node Release, пока релиз OpenClaw еще является черновиком, передавая закрепленную карту дайджестов установщиков без изменений. Дочерний рабочий процесс скачивает подписанные установщики Windows Hub из этого точного тега, сверяет их с закрепленными дайджестами, проверяет, что их подписи Authenticode используют ожидаемого подписанта OpenClaw Foundation на Windows runner, записывает манифест SHA-256 и загружает установщики вместе с манифестом в канонический релиз OpenClaw на GitHub, затем повторно скачивает продвинутые артефакты и проверяет членство в манифесте и хэши. Родитель проверяет текущий контракт артефактов x64, ARM64 и checksum перед публикацией. Прямое восстановление отклоняет неожиданные имена артефактов OpenClawCompanion-* перед заменой ожидаемых контрактных артефактов закрепленными исходными байтами. Вручную запускайте Windows Node Release только для восстановления и всегда передавайте точный тег, никогда latest, плюс явную JSON-карту expected_installer_digests из одобренного исходного релиза. Ссылки загрузки на сайте должны указывать на точные URL артефактов релиза OpenClaw для текущего стабильного релиза или на releases/latest/download/... только после проверки, что перенаправление GitHub latest указывает на тот же релиз; не ссылайтесь только на страницу релиза companion-репозитория.
• Проверки релиза теперь выполняются в отдельном ручном рабочем процессе: OpenClaw Release Checks
• OpenClaw Release Checks также запускает дорожку mock-паритета 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 параллельно.
• Межплатформенная проверка среды выполнения установки и обновления входит в публичные OpenClaw Release Checks и Full Release Validation, которые напрямую вызывают переиспользуемый рабочий процесс .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• Это разделение намеренно: сохраняйте реальный путь релиза npm коротким, детерминированным и сосредоточенным на артефактах, а более медленные live-проверки держите в собственной дорожке, чтобы они не задерживали и не блокировали публикацию
• Проверки релиза с секретами следует запускать через Full Release Validation или из workflow ref main/release, чтобы логика рабочего процесса и секреты оставались контролируемыми
• OpenClaw Release Checks принимает ветку, тег или полный SHA коммита, если разрешенный коммит достижим из ветки OpenClaw или релизного тега
• Предварительная проверка только для валидации OpenClaw NPM Release также принимает текущий полный 40-символьный SHA коммита ветки рабочего процесса без требования запушенного тега
• Этот путь SHA предназначен только для валидации и не может быть продвинут в реальную публикацию
• В режиме SHA рабочий процесс синтезирует v<package.json version> только для проверки метаданных пакета; реальная публикация все равно требует реальный релизный тег
• Оба рабочих процесса сохраняют реальный путь публикации и продвижения на GitHub-hosted runners, а неизменяющий путь валидации может использовать более крупные Blacksmith Linux runners
• Этот рабочий процесс выполняет OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache с использованием секретов рабочего процесса OPENAI_API_KEY и ANTHROPIC_API_KEY
• Предварительная проверка релиза npm больше не ждет отдельную дорожку release checks
• Перед локальным созданием тега релизного кандидата выполните RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check. Помощник запускает быстрые релизные предохранители, проверки релиза npm/ClawHub Plugin, сборку, сборку UI и release:openclaw:npm:check в порядке, который выявляет типичные ошибки, блокирующие одобрение, до запуска workflow публикации GitHub.
• Выполните 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. Вспомогательный скрипт запускает проверку npm update/fresh-target в Parallels, отправляет NPM Telegram Beta E2E, опрашивает точный workflow run, загружает артефакт и выводит отчет 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 run
  • стабильные npm-релизы по умолчанию используют beta
  • стабильная публикация npm может явно выбрать latest через входной параметр workflow
  • token-based изменение npm dist-tag теперь находится в openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml, потому что npm dist-tag add все еще требует NPM_TOKEN, а исходный репозиторий сохраняет публикацию только через OIDC
  • публичный macOS Release предназначен только для валидации; когда tag существует только в release-ветке, но workflow запускается из main, задайте public_release_branch=release/YYYY.M.PATCH
  • реальная публикация macOS должна пройти успешные macOS preflight_run_id и validate_run_id
  • реальные пути публикации продвигают подготовленные артефакты вместо повторной сборки
• Для стабильных correction-релизов вроде YYYY.M.PATCH-N post-publish-верификатор также проверяет тот же путь обновления во временном префиксе с YYYY.M.PATCH до YYYY.M.PATCH-N, чтобы release corrections не могли незаметно оставить старые глобальные установки на базовом стабильном payload
• npm release preflight завершается отказом, если tarball не включает и dist/control-ui/index.html, и непустой payload dist/control-ui/assets/, чтобы мы снова не поставили пустой браузерный dashboard
• Post-publish-верификация также проверяет наличие опубликованных entrypoints Plugin и метаданных пакета в установленной структуре реестра. Релиз, в котором отсутствуют runtime payloads Plugin, проваливает postpublish-верификатор и не может быть продвинут в latest.
• pnpm test:install:smoke также контролирует бюджет npm pack unpackedSize для candidate update tarball, чтобы installer e2e ловил случайное раздувание пакета до пути публикации release
• Если release-работа затрагивала планирование CI, timing manifests расширений или матрицы тестов расширений, заново сгенерируйте и проверьте принадлежащие planner выходные данные матрицы plugin-prerelease-extension-shard из .github/workflows/plugin-prerelease.yml перед approval, чтобы release notes не описывали устаревшую раскладку CI
• Готовность стабильного macOS release также включает поверхности updater:
  • GitHub release в итоге должен содержать упакованные .zip, .dmg и .dSYM.zip
  • appcast.xml в main после публикации должен указывать на новый стабильный zip; workflow публикации macOS фиксирует это автоматически или открывает appcast PR, когда прямой push заблокирован
  • упакованное приложение должно сохранять не-debug bundle id, непустой URL ленты Sparkle и CFBundleVersion не ниже канонического минимума сборки Sparkle для этой версии release

​

Тестовые боксы релиза

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

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

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

# 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

​

Vitest

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

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

​

Docker

• полный install smoke с включенным медленным Bun global install smoke
• подготовку/повторное использование root Dockerfile smoke image по целевому SHA, с QR, root/gateway и installer/Bun smoke заданиями, запускаемыми как отдельные install-smoke shards
• repository E2E lanes
• Docker chunks релизного пути: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a, plugins-runtime-install-b, 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 through bundled-plugin-install-uninstall-23
• live/E2E provider suites и Docker live model coverage, когда release checks включают live suites

​

QA Lab

• mock parity lane, сравнивающую кандидатную lane OpenAI с baseline Opus 4.6 с использованием agentic parity pack
• быстрый 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 требует явного локального доказательства

​

Package

• source=npm: openclaw@beta, openclaw@latest или точная версия релиза OpenClaw
• source=ref: упаковывает доверенную ветку package_ref, тег или полный SHA коммита с выбранным 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

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: контракты установки/обновления/перезапуска/пакета Plugin плюс доказательство живой установки skill из ClawHub; это значение по умолчанию для release-check
• product: package плюс MCP-каналы, очистка cron/subagent, веб-поиск OpenAI и OpenWebUI
• full: Docker-фрагменты релизного пути с OpenWebUI
• custom: точный список docker_lanes для сфокусированных повторных запусков

​

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

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

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

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

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

​

Входные данные workflow NPM

• tag: обязательный релизный тег, например v2026.4.2, v2026.4.2-1 или v2026.4.2-beta.1; когда preflight_only=true, это также может быть текущий полный 40-символьный SHA коммита ветки workflow для preflight только с валидацией
• preflight_only: true для только валидации/сборки/пакета, false для реального пути публикации
• preflight_run_id: обязателен на реальном пути публикации, чтобы workflow повторно использовал подготовленный tarball из успешного preflight-запуска
• npm_dist_tag: целевой npm-тег для пути публикации; по умолчанию beta

• tag: обязательный релизный тег; уже должен существовать
• preflight_run_id: id успешного preflight-запуска OpenClaw NPM Release; обязателен, когда publish_openclaw_npm=true
• full_release_validation_run_id: id успешного запуска Full Release Validation; обязателен, когда publish_openclaw_npm=true
• windows_node_tag: точный непререлизный релизный тег openclaw/openclaw-windows-node; обязателен для стабильной публикации OpenClaw
• windows_node_installer_digests: одобренная для кандидата компактная JSON-карта текущих имен установщиков Windows к их закрепленным digest sha256:; обязательна для стабильной публикации OpenClaw
• npm_dist_tag: целевой npm-тег для пакета OpenClaw
• plugin_publish_scope: по умолчанию all-publishable; используйте selected только для сфокусированного исправления только Plugin с publish_openclaw_npm=false
• plugins: разделенные запятыми имена пакетов @openclaw/*, когда plugin_publish_scope=selected
• publish_openclaw_npm: по умолчанию true; задавайте false только при использовании workflow как оркестратора исправлений только Plugin
• wait_for_clawhub: по умолчанию false, чтобы доступность npm не блокировалась sidecar ClawHub; задавайте true только когда завершение workflow должно включать завершение ClawHub

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

• Стабильные и корректирующие теги могут публиковаться либо в beta, либо в latest
• Beta prerelease-теги могут публиковаться только в beta
• Для OpenClaw NPM Release ввод полного SHA коммита разрешен только когда preflight_only=true
• OpenClaw Release Checks и Full Release Validation всегда являются только валидационными
• Реальный путь публикации должен использовать тот же npm_dist_tag, который использовался во время preflight; workflow проверяет эти метаданные перед продолжением публикации

​

Последовательность стабильного npm-релиза

1. Запустите OpenClaw NPM Release с preflight_only=true
   • До появления тега можно использовать текущий полный SHA коммита ветки workflow для проверочного dry run только валидации preflight 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 перед продвижением пакета OpenClaw npm
8. Если релиз попал в beta, используйте workflow openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml, чтобы продвинуть эту стабильную версию из beta в latest
9. Если релиз намеренно был опубликован напрямую в latest, а beta должна сразу следовать той же стабильной сборке, используйте тот же релизный workflow, чтобы направить оба dist-tags на стабильную версию, или позвольте его запланированной самовосстанавливающейся синхронизации переместить beta позже

​

Публичные ссылки

• .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

​

Связанные материалы

• Каналы релизов