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

В настоящее время OpenClaw предоставляет три пользовательских канала обновлений:

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

Кроме того, операторы выпуска могут публиковать основной пакет за последний завершённый месяц в npm extended-stable, начиная с патча 33. Обычная финальная линия текущего месяца остаётся в npm latest; это разделение публикаций на стороне оператора само по себе не изменяет разрешение каналов обновлений CLI.

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

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

• Версия ежемесячного расширенно стабильного выпуска npm: YYYY.M.PATCH, с PATCH >= 33, git-тег vYYYY.M.PATCH
• Версия ежедневного/обычного финального выпуска: YYYY.M.PATCH, с PATCH < 33, git-тег vYYYY.M.PATCH
• Версия обычного корректирующего резервного выпуска: YYYY.M.PATCH-N, git-тег vYYYY.M.PATCH-N
• Версия предварительного бета-выпуска: YYYY.M.PATCH-beta.N, git-тег vYYYY.M.PATCH-beta.N
• Версия предварительного альфа-выпуска: YYYY.M.PATCH-alpha.N, git-тег vYYYY.M.PATCH-alpha.N
• Никогда не дополняйте месяц или патч ведущими нулями
• PATCH — это последовательный номер ежемесячной серии выпусков, а не календарный день. Обычные финальные и бета-выпуски продвигают текущую серию; теги только альфа-выпусков никогда не занимают и не продвигают номер патча бета- или обычного выпуска, поэтому при выборе серии бета- или обычного выпуска игнорируйте устаревшие теги только альфа-выпусков с более высокими номерами патчей.
• Альфа-/ночные сборки используют следующую ещё не выпущенную серию патчей и при повторных сборках увеличивают только alpha.N. После появления бета-версии этого патча новые альфа-сборки переходят к следующему патчу.
• Версии npm неизменяемы: никогда не удаляйте, не публикуйте повторно и не используйте заново опубликованный тег. Вместо этого создайте следующий номер предварительного выпуска или следующий ежемесячный патч.
• latest продолжает следовать текущей обычной/ежедневной линии npm; beta — текущая цель установки бета-версии
• extended-stable обозначает поддерживаемый пакет npm за предыдущий месяц, начиная с патча 33; патч 34 и последующие являются выпусками обслуживания этой ежемесячной линии
• Обычные финальные и обычные корректирующие выпуски по умолчанию публикуются в npm beta; операторы выпуска могут явно выбрать latest или позднее продвинуть проверенную бета-сборку
• Выделенный ежемесячный расширенно стабильный процесс публикует основной пакет npm и каждый официальный плагин, допускающий публикацию в npm, с одной и той же точной версией. Он не публикует плагины в ClawHub, а также не публикует артефакты macOS или Windows, выпуск GitHub, dist-теги частных репозиториев, образы Docker, мобильные артефакты или загрузки с сайта.
• Каждый обычный финальный выпуск одновременно включает пакет npm, приложение macOS, подписанный автономный APK Android и подписанные установщики Windows Hub. Для бета-выпусков обычно сначала проверяется и публикуется путь npm/пакета, а сборка, подпись, нотариальное заверение и продвижение нативных приложений выполняются только для обычного финального выпуска, если явно не запрошено иное.

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

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

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

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

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

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

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

release_profile=stable — это существующий профиль глубины проверки; он не связан с dist-тегом npm extended-stable и намеренно остаётся без изменений.

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

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

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

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

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

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

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

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

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

В общедоступной документации поддержки Slack, Discord и Codex первоначально указаны как поддерживаемые поверхности расширенно стабильных плагинов. Этот список описывает поддержку, а не является списком разрешений в коде выпуска: каждый официальный плагин, допускающий публикацию в npm, следует одному и тому же процессу публикации точной версии.

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

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

Этот контрольный список представляет общедоступную схему процесса выпуска. Частные учётные данные, подпись, нотариальное заверение, восстановление dist-тегов и сведения об аварийном откате остаются в руководстве по выпуску, доступном только сопровождающим.

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

2. Создайте release/YYYY.M.PATCH из этого коммита. Обратные переносы необязательны; применяйте только выбранный оператором набор. Увеличьте версии во всех необходимых местах, выполните pnpm release:prep, завершите исправления выпуска и необходимые прямые переносы, затем проверьте src/plugins/compat/registry.ts и src/commands/doctor/shared/deprecation-compat.ts.

3. Зафиксируйте полностью готовый с точки зрения продукта коммит до журнала изменений как SHA кода. Выполните детерминированную предварительную проверку исходного кода, затем используйте node scripts/full-release-validation-at-sha.mjs --sha <code-sha> --target-ref release/YYYY.M.PATCH. Это фиксирует доверенные инструменты рабочего процесса, пока полная матрица Vitest, Docker, QA, пакетов и производительности проверяет точный SHA кода.

4. Классифицируйте сбои до внесения изменений. Сбой продукта или кода создаёт новый SHA кода и требует успешной полной проверки этого SHA. Сбой рабочего процесса, тестовой обвязки, учётных данных, согласования или инфраструктуры устраняется в принадлежащей ему области, после чего проверка повторяется для того же SHA кода.

5. Только после успешной проверки SHA кода создайте верхний раздел CHANGELOG.md на основе объединённых PR и прямых коммитов после последнего достижимого выпущенного тега. Формулируйте записи для пользователей и удаляйте дубликаты. Если расходящийся выпущенный тег или более поздний прямой перенос повторно связывает уже выпущенные PR, передайте его явно как --shipped-ref.

6. Зафиксируйте только CHANGELOG.md. Этот коммит является SHA выпуска. Полная разница между SHA кода и SHA выпуска должна в точности состоять из CHANGELOG.md; изменение любого другого пути возвращает выпуск к шагу 2.

7. Запустите полную проверку выпуска, закреплённую за SHA выпуска, с включённым повторным использованием подтверждений. Облегчённый родительский запуск должен записать changelog-only-release-v1, ссылаться на успешно проверенный SHA кода и не запускать дочерние этапы продукта. При этом повторно используются подтверждения продукта, но не байты пакета.

8. Запустите OpenClaw NPM Release с preflight_only=true для SHA/тега выпуска. Сохраните успешный preflight_run_id. При этом создаются и проверяются точные байты пакета, включающие окончательный журнал изменений.

9. Пометьте SHA выпуска тегом, затем запустите вспомогательное средство кандидата с успешным родительским запуском проверки SHA выпуска и предварительной проверкой npm вместо повторного запуска любого из них:

   pnpm release:candidate -- \  --tag vYYYY.M.PATCH-beta.N \  --full-release-run <release-sha-validation-run-id> \  --npm-preflight-run <preflight-run-id> \  --skip-dispatch

   Для стабильного выпуска также передайте --windows-node-tag vX.Y.Z. Вспомогательный инструмент проверяет происхождение примечаний к выпуску, байты предварительной проверки npm, подтверждение установки/обновления в Parallels, подтверждение пакета Telegram и планы публикации плагинов, а затем выводит команду публикации.

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

   Затем запустите приёмочное тестирование пакета после публикации для опубликованного пакета [email protected] или openclaw@beta. Если отправленная или опубликованная предварительная версия требует исправления, создайте следующий соответствующий номер предварительной версии; никогда не удаляйте и не перезаписывайте прежнюю.

10. После неудачной попытки публикации не изменяйте SHA выпуска, если только ошибка не доказывает дефект продукта или журнала изменений. Возобновляйте успешные неизменяемые дочерние процессы и артефакты; никогда не пересобирайте и не публикуйте повторно уже успешно опубликованную версию пакета.

11. Для стабильного выпуска продолжайте только после того, как проверенная бета-версия или кандидат на выпуск получит необходимые подтверждения валидации. Публикация стабильной версии в npm также выполняется через OpenClaw Release Publish с повторным использованием успешного артефакта предварительной проверки посредством preflight_run_id. Готовность стабильного выпуска macOS также требует наличия упакованных .zip, .dmg, .dSYM.zip и обновлённого appcast.xml в main; рабочий процесс публикации macOS автоматически публикует подписанный appcast в общедоступный main после проверки ресурсов выпуска либо открывает/обновляет PR appcast, если защита ветки блокирует прямую отправку. Готовность стабильного выпуска Windows Hub требует подписанных ресурсов OpenClawCompanion-Setup-x64.exe, OpenClawCompanion-Setup-arm64.exe и OpenClawCompanion-SHA256SUMS.txt в выпуске OpenClaw на GitHub. Передайте точный подписанный тег выпуска openclaw/openclaw-windows-node как windows_node_tag, а одобренную для кандидата карту дайджестов установщиков — как windows_node_installer_digests; OpenClaw Release Publish сохраняет черновик выпуска, запускает Windows Node Release и проверяет все три ресурса перед публикацией.

12. После публикации запустите средство проверки npm после публикации, при необходимости — отдельное сквозное тестирование Telegram для опубликованного пакета npm, когда требуется подтверждение канала после публикации, продвижение dist-тега, если оно необходимо, проверьте сформированную страницу выпуска GitHub, выполните шаги объявления о выпуске, а затем завершите закрытие стабильного выпуска в основной ветке, прежде чем считать стабильный выпуск завершённым.

Закрытие стабильного выпуска в основной ветке

Публикация стабильного выпуска не завершена, пока main не содержит фактически выпущенное состояние.

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

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

Полное закрытие требует обоих ресурсов и соответствующей контрольной суммы. Частичный манифест повторно выполняет записанные в нём SHA main и тренировку отката, чтобы повторно сформировать идентичные байты, а затем прикрепляет недостающую контрольную сумму; недействительная пара или контрольная сумма без манифеста остаётся блокирующей. Запуск, инициированный отправкой и не имеющий переменных репозитория для тренировки отката, пропускается без завершения закрытия; отсутствующая или созданная более 90 дней назад запись тренировки по-прежнему блокирует ручное закрытие на основе подтверждений. Закрытые команды восстановления остаются в руководстве только для сопровождающих. Используйте ручной запуск только для исправления или повторного выполнения закрытия стабильного выпуска на основе подтверждений.

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

Устаревший резервный тег исправления может повторно использовать подтверждение базового пакета только тогда, когда тег исправления указывает на тот же исходный коммит, что и базовый стабильный тег. Его выпуск Android повторно использует проверенный APK базового тега и добавляет происхождение для тега исправления. Исправление с другим исходным кодом должно опубликовать и проверить собственное подтверждение пакета и использовать более высокий Android versionCode.

Предварительная проверка выпуска

• Запустите pnpm check:test-types перед предварительной проверкой выпуска, чтобы тестовый TypeScript продолжал проверяться вне более быстрого локального шлюза pnpm check.

• Запустите pnpm check:architecture перед предварительной проверкой выпуска, чтобы более широкие проверки циклов импорта и архитектурных границ успешно выполнялись вне более быстрого локального шлюза.

• Запустите pnpm build && pnpm ui:build перед pnpm release:check, чтобы ожидаемые артефакты выпуска dist/* и пакет Control UI существовали для этапа валидации упаковки.

• Запустите pnpm release:prep после увеличения корневой версии и до создания тега. Он запускает каждый детерминированный генератор выпуска, результат которого часто расходится после изменения версии, конфигурации или API: версии плагинов, файлы shrinkwrap npm, реестр плагинов, схему базовой конфигурации, метаданные конфигурации встроенных каналов, базовую версию документации конфигурации, экспорты SDK плагинов и базовую версию API SDK плагинов. pnpm release:check повторно запускает эти проверки в режиме проверки (плюс проверку бюджета поверхности SDK плагинов) и за один проход сообщает обо всех расхождениях сформированных данных перед запуском проверок выпуска пакетов.

• Синхронизация версий плагинов по умолчанию обновляет публикуемый пакет среды выполнения @openclaw/ai, версии пакетов официальных плагинов и существующие нижние границы openclaw.compat.pluginApi до версии выпуска OpenClaw. Считайте это поле нижней границей API SDK/среды выполнения плагинов, а не просто копией версии пакета: для выпусков только плагинов, которые намеренно сохраняют совместимость с более старыми хостами OpenClaw, оставляйте нижнюю границу на уровне самого старого поддерживаемого API хоста и документируйте этот выбор в подтверждении выпуска плагина.

• Перед утверждением выпуска вручную запустите рабочий процесс Full Release Validation, чтобы инициировать все блоки предрелизных тестов из одной точки входа. Он принимает ветку, тег или полный SHA коммита, запускает вручную CI и запускает OpenClaw Release Checks для быстрой проверки установки, приёмочного тестирования пакета, межплатформенных проверок пакета, соответствия QA Lab, а также направлений Matrix и Telegram. Стабильные и полные запуски всегда включают исчерпывающие интерактивные/сквозные проверки и выдержку пути выпуска Docker; run_release_soak=true сохраняется для явно заданной выдержки бета-версии. Приёмочное тестирование пакета обеспечивает каноническое сквозное тестирование Telegram для пакета во время валидации кандидата, предотвращая запуск второго параллельного средства опроса в рабочей среде.

  Передайте release_package_spec после публикации бета-версии, чтобы повторно использовать выпущенный пакет npm в проверках выпуска, приёмочном тестировании пакета и сквозном тестировании пакета Telegram без повторной сборки tar-архива выпуска. Передавайте npm_telegram_package_spec только тогда, когда Telegram должен использовать опубликованный пакет, отличный от используемого остальными этапами валидации выпуска. Передавайте package_acceptance_package_spec, когда приёмочное тестирование пакета должно использовать опубликованный пакет, отличный от спецификации пакета выпуска. Передавайте evidence_package_spec, когда отчёт с подтверждениями выпуска должен доказать, что валидация соответствует опубликованному пакету npm, не требуя сквозного тестирования Telegram.

  node scripts/full-release-validation-at-sha.mjs \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH

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

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

  Пример:

  gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f [email protected] -f telegram_mode=mock-openai

  Распространённые профили:

  • smoke: сценарии установки, канала и агента, сети Gateway и перезагрузки конфигурации
  • package: нативные для артефакта сценарии пакета, обновления, перезапуска и плагинов без OpenWebUI или ClawHub в реальной среде
  • product: профиль пакета плюс каналы MCP, очистка cron и субагентов, веб-поиск OpenAI и OpenWebUI
  • full: части пути выпуска Docker с OpenWebUI
  • custom: точный выбор docker_lanes для целевого повторного запуска

• Запускайте вручную непосредственно workflow CI, когда требуется только детерминированное стандартное покрытие CI для кандидата на выпуск. Ручные запуски CI обходят ограничение по изменениям и принудительно запускают сегменты Linux Node, сегменты встроенных плагинов, сегменты контрактов плагинов и каналов, проверку совместимости с Node 22, check-*, check-additional-*, быстрые проверки собранных артефактов, проверки документации, Python Skills, Windows, macOS и сценарии интернационализации Control UI. Отдельные ручные запуски CI выполняют Android только при запуске с include_android=true; Full Release Validation передаёт этот параметр своему дочернему процессу CI.

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

• Запускайте pnpm qa:otel:smoke при проверке телеметрии выпуска. Этот сценарий проверяет QA-lab через локальный приёмник OTLP/HTTP и подтверждает экспорт трассировок, метрик и журналов, а также ограниченность атрибутов трассировки и редактирование содержимого и идентификаторов без необходимости использовать Opik, Langfuse или другой внешний сборщик.

• Запускайте pnpm qa:otel:collector-smoke при проверке совместимости со сборщиком. Этот сценарий направляет тот же экспорт OTLP из QA-lab через настоящий Docker-контейнер OpenTelemetry Collector перед проверками локального приёмника.

• Запускайте pnpm qa:prometheus:smoke при проверке защищённого сбора данных Prometheus. Этот сценарий проверяет QA-lab, отклоняет неаутентифицированные запросы сбора данных и подтверждает, что критически важные для выпуска семейства метрик не содержат содержимое запросов, необработанные идентификаторы, токены аутентификации и локальные пути.

• Запускайте pnpm qa:observability:smoke для последовательного выполнения сценариев быстрой проверки OpenTelemetry и Prometheus из исходного рабочего дерева.

• Запускайте pnpm release:check перед каждым выпуском с тегом.

• Предварительная проверка OpenClaw NPM Release формирует данные о выпуске зависимостей перед упаковкой npm-тарбола. Проверка уязвимостей по рекомендациям npm блокирует выпуск при сбое. Отчёты о рисках транзитивного манифеста, владении зависимостями и поверхности установки, а также изменениях зависимостей служат только подтверждением выпуска. Отчёт об изменениях зависимостей сравнивает кандидата на выпуск с предыдущим доступным тегом выпуска. Предварительная проверка загружает данные о зависимостях как openclaw-release-dependency-evidence-<tag>, а также встраивает их в dependency-evidence/ внутри подготовленного артефакта предварительной проверки npm. Реальный процесс публикации повторно использует этот артефакт предварительной проверки, а затем прикрепляет те же данные к выпуску GitHub как openclaw-<version>-dependency-evidence.zip.

• Запускайте OpenClaw Release Publish для изменяющей состояние последовательности публикации после появления тега. Обычные бета- и стабильные выпуски публикуйте из доверенной main; тег выпуска по-прежнему выбирает точный целевой коммит и может указывать на release/YYYY.M.PATCH. Альфа-выпуски Tideclaw остаются в соответствующей альфа-ветке. Передавайте успешный npm-preflight_run_id OpenClaw, успешный full_release_validation_run_id и точный full_release_validation_run_attempt, сохраняя область публикации плагинов по умолчанию all-publishable, если только намеренно не выполняется целевое исправление. Workflow последовательно выполняет публикацию плагинов в npm, публикацию плагинов в ClawHub и публикацию OpenClaw в npm, чтобы основной пакет не был опубликован раньше вынесенных из него плагинов; продвижение Windows и Android выполняется параллельно с публикацией основного пакета в npm на странице черновика выпуска. Повторные запуски публикации можно продолжать: если основная версия npm уже опубликована, основная отправка пропускается после того, как workflow подтверждает соответствие тарбола в реестре артефакту предварительной проверки тега; продвижение Windows и Android пропускается, если выпуск уже содержит проверенный контракт артефактов, поэтому при повторной попытке заново выполняются только неудавшиеся этапы. Целевые исправления только плагинов требуют plugin_publish_scope=selected и непустого списка плагинов. Запуски all-publishable только для плагинов требуют полных неизменяемых подтверждений предварительной проверки и Full Release Validation; частичные подтверждения отклоняются.

• Для стабильного OpenClaw Release Publish требуется точный windows_node_tag после появления соответствующего выпуска openclaw/openclaw-windows-node, не являющегося предварительным, а также утверждённая для кандидата карта windows_node_installer_digests. Перед запуском любого дочернего процесса публикации проверяется, что исходный выпуск опубликован, не является предварительным, содержит необходимые установщики x64/ARM64 и по-прежнему соответствует утверждённой карте. Затем запускается Windows Node Release, пока выпуск OpenClaw ещё находится в состоянии черновика, с передачей неизменённой закреплённой карты хешей установщиков. Дочерний workflow загружает подписанные установщики Windows Hub из этого точного тега, сверяет их с закреплёнными хешами, на исполнителе Windows проверяет, что их подписи Authenticode используют ожидаемого подписанта OpenClaw Foundation, создаёт манифест SHA-256 и загружает установщики вместе с манифестом в канонический выпуск OpenClaw на GitHub, после чего повторно загружает продвигаемые артефакты и проверяет их наличие в манифесте и хеши. Родительский процесс перед публикацией проверяет текущий контракт артефактов x64, ARM64 и контрольных сумм. При прямом восстановлении неожиданные имена артефактов OpenClawCompanion-* отклоняются до замены ожидаемых артефактов контракта закреплёнными байтами источника.

  Запускайте вручную Windows Node Release только для восстановления и всегда передавайте точный тег, но никогда не latest, а также явную JSON-карту expected_installer_digests из утверждённого исходного выпуска. Ссылки на загрузку на сайте должны указывать на точные URL артефактов текущего стабильного выпуска OpenClaw или на releases/latest/download/... только после проверки, что перенаправление GitHub на последний выпуск указывает на тот же выпуск; не размещайте ссылку только на страницу выпуска в сопутствующем репозитории.

• Проверки релиза теперь выполняются в отдельном запускаемом вручную рабочем процессе: OpenClaw Release Checks. Он также запускает контур проверки паритета имитаций QA Lab, профиль релиза Matrix и контур QA Telegram перед утверждением релиза. Контуры с реальными сервисами используют окружение qa-live-shared; Telegram также использует аренду учетных данных Convex CI. Запускайте вручную рабочий процесс QA-Lab - All Lanes с matrix_profile=all, когда требуются все поддерживаемые сценарии Matrix; рабочий процесс распределяет выбранные сценарии между профилями транспорта, мультимедиа и E2EE, чтобы полная проверка укладывалась в ограничения времени для каждого задания.

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

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

• OpenClaw Release Checks принимает ветку, тег или полный SHA коммита при условии, что разрешенный коммит достижим из ветки OpenClaw или тега релиза.

• Предварительная проверка OpenClaw NPM Release, предназначенная только для валидации, также принимает текущий полный 40-символьный SHA коммита ветки рабочего процесса без необходимости отправлять тег. Путь с SHA предназначен только для валидации и не может быть повышен до реальной публикации. В режиме SHA рабочий процесс создает v<package.json version> только для проверки метаданных пакета; для реальной публикации по-прежнему требуется настоящий тег релиза.

• Оба рабочих процесса оставляют реальную публикацию и повышение на раннерах GitHub, а неизменяющий данные путь валидации может использовать более мощные раннеры Blacksmith Linux.

• Этот рабочий процесс запускает OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache, используя оба секрета рабочего процесса: OPENAI_API_KEY и ANTHROPIC_API_KEY.

• Предварительная проверка релиза npm больше не ожидает отдельного контура проверок релиза.

• Перед локальным созданием тега кандидата в релиз запустите RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check. Вспомогательное средство последовательно запускает быстрые защитные проверки релиза, проверки релиза плагинов npm/ClawHub, сборку, сборку интерфейса и release:openclaw:npm:check, чтобы выявить распространенные ошибки, блокирующие утверждение, до запуска рабочего процесса публикации в GitHub.

• Перед утверждением запустите RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (или соответствующий тег предварительного/исправляющего релиза).

• После публикации в npm запустите node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH (или соответствующую бета-версию/версию исправления), чтобы проверить путь установки из опубликованного реестра в новом временном префиксе.

• После публикации бета-версии запустите [email protected] OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live, чтобы проверить первоначальную настройку установленного пакета, настройку Telegram и реальный E2E Telegram для опубликованного пакета npm с использованием общего пула арендованных учетных данных Telegram. Для разовых локальных запусков сопровождающие могут не указывать переменные Convex и напрямую передать три учетных данных окружения OPENCLAW_QA_TELEGRAM_*.

• Чтобы запустить полную проверку работоспособности бета-версии после публикации с компьютера сопровождающего, используйте pnpm release:beta-smoke -- --beta betaN. Вспомогательное средство запускает проверку обновления npm и новой целевой установки в Parallels, запускает NPM Telegram Beta E2E, опрашивает конкретный запуск рабочего процесса, скачивает артефакт и выводит отчет Telegram.

• Сопровождающие могут запустить ту же проверку после публикации из GitHub Actions с помощью запускаемого вручную рабочего процесса NPM Telegram Beta E2E. Он намеренно запускается только вручную и не выполняется при каждом слиянии.

• Автоматизация релиза для сопровождающих использует схему «предварительная проверка, затем повышение»:

  • Реальная публикация в npm должна пройти успешную предварительную проверку npm preflight_run_id.
  • Оркестрация и предварительная проверка обычных бета- и стабильных публикаций используют доверенный main для точного целевого тега. Публикация и предварительная проверка альфа-версии Tideclaw используют соответствующую альфа-ветку.
  • Стабильные релизы npm по умолчанию используют beta; для стабильной публикации npm можно явно указать latest во входных данных рабочего процесса.
  • Изменение dist-tag npm на основе токена выполняется в openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml, поскольку npm dist-tag add по-прежнему требует NPM_TOKEN, тогда как исходный репозиторий использует для публикации только OIDC.
  • Общедоступный macOS Release предназначен только для валидации; если тег существует только в ветке релиза, но рабочий процесс запускается из main, задайте public_release_branch=release/YYYY.M.PATCH.
  • Реальная публикация для macOS должна пройти успешные предварительные проверки macOS preflight_run_id и validate_run_id.
  • Пути реальной публикации повышают подготовленные артефакты, не пересобирая их повторно.

• Для стабильных исправляющих релизов, таких как YYYY.M.PATCH-N, средство проверки после публикации также проверяет тот же путь обновления во временном префиксе с YYYY.M.PATCH до YYYY.M.PATCH-N, чтобы исправления релиза не могли незаметно оставить прежние глобальные установки на базовой стабильной сборке.

• Предварительная проверка релиза npm завершается с ошибкой, если tar-архив не содержит одновременно dist/control-ui/index.html и непустую полезную нагрузку dist/control-ui/assets/, чтобы снова не выпустить пустую браузерную панель управления.

• Проверка после публикации также удостоверяется, что точки входа опубликованных плагинов и метаданные пакета присутствуют в установленной структуре реестра. Релиз без необходимых полезных нагрузок среды выполнения плагинов не проходит средство проверки после публикации и не может быть повышен до latest.

• pnpm test:install:smoke также контролирует бюджет npm pack unpackedSize для tar-архива кандидата на обновление, чтобы E2E установщика выявлял случайное разрастание пакета до запуска пути публикации релиза.

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

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

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

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

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

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

После успешной проверки SHA кода зафиксируйте только CHANGELOG.md и запустите то же вспомогательное средство с SHA релиза:

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

Второй родитель повторно использует доказательства продукта, только если GitHub подтверждает, что SHA релиза является потомком SHA кода, а полный набор измененных путей в точности равен CHANGELOG.md. Он записывает changelog-only-release-v1 и не запускает дочерние процессы продукта. Предварительная проверка npm и приемочные проверки пакета/установки по-прежнему выполняются для SHA релиза, поскольку байты его tar-архива изменились.

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

Дочерний процесс производительности продукта в этом пути релиза работает только с артефактами. Зонтичный процесс запускает его с publish_reports=false, а валидация отклоняется, если его защитная проверка режима только для артефактов не подтверждает, что средство публикации отчета Clawgrit осталось пропущенным.

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

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

Используйте release_profile, чтобы выбрать широту охвата реальных сервисов/провайдеров:

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

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

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

Проверка установки OpenAI в разных ОС использует OPENCLAW_CROSS_OS_OPENAI_MODEL, если задана переменная репозитория/организации, иначе — openai/gpt-5.6-luna, поскольку этот контур проверяет установку пакета, первоначальную настройку, запуск Gateway и один реальный ход агента, а не производительность самой мощной модели. Более широкая матрица реальных провайдеров остается местом для покрытия конкретных моделей.

Используйте следующие варианты в зависимости от этапа релиза:

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

Не используйте полный зонтичный процесс для первого повторного запуска после точечного исправления. Если один из блоков завершается с ошибкой, для следующей проверки используйте завершившийся с ошибкой дочерний рабочий процесс, задание, Docker-направление, профиль пакета, поставщика модели или направление QA. Повторно запускайте полный зонтичный процесс только тогда, когда исправление изменило общую оркестрацию релиза или сделало предыдущие свидетельства по всем блокам устаревшими. Итоговый проверяющий зонтичного процесса повторно проверяет записанные идентификаторы запусков дочерних рабочих процессов, поэтому после успешного повторного запуска дочернего рабочего процесса перезапустите только завершившееся с ошибкой родительское задание Verify full validation.

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

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

Vitest

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

Используйте этот блок, чтобы ответить на вопрос: «Прошло ли дерево исходного кода полный обычный набор тестов?» Это не то же самое, что проверка продукта по пути релиза. Сохраняемые свидетельства:

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

Запускайте CI вручную напрямую только тогда, когда релизу нужен детерминированный обычный CI, но не нужны блоки Docker, QA Lab, проверок в реальном времени, межплатформенных проверок или пакетов. Используйте первую команду для прямого CI без Android. Добавьте include_android=true, когда прямой CI кандидата на выпуск должен охватывать Android:

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

Docker

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

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

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

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

QA Lab

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

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

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

Используйте этот блок, чтобы ответить на вопрос: «Корректно ли ведёт себя релиз в сценариях QA и потоках каналов в реальном времени?» При одобрении релиза сохраняйте URL артефактов для направлений равнозначности, Matrix и Telegram. Полное покрытие Matrix остаётся доступным в виде запускаемого вручную сегментированного процесса QA Lab, а не используемого по умолчанию критически важного для релиза направления.

Пакет

Блок Package — это шлюз устанавливаемого продукта. Он основан на Package Acceptance и обработчике scripts/resolve-openclaw-package-candidate.mjs. Обработчик нормализует кандидата в tarball package-under-test, используемый Docker E2E, проверяет состав пакета, записывает версию пакета и SHA-256 и хранит ссылку на инфраструктуру рабочего процесса отдельно от ссылки на исходный код пакета.

Поддерживаемые источники кандидатов:

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

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

Это нативная для GitHub замена большей части покрытия пакетов/обновлений, для которого ранее требовался Parallels. Межплатформенные релизные проверки по-прежнему важны для адаптации, установщика и поведения, специфичного для ОС, но при проверке продукта с точки зрения пакетов/обновлений следует отдавать предпочтение Package Acceptance.

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

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

Используйте более широкие профили Package Acceptance, когда вопрос о релизе касается фактически устанавливаемого пакета:

gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=npm \  -f package_spec=openclaw@beta \  -f suite_profile=product \  -f [email protected]

Распространённые профили пакетов:

• smoke: быстрые сценарии установки пакетов/каналов/агентов, настройки сети Gateway и перезагрузки конфигурации
• package: контракты установки/обновления/перезапуска/пакетов плагинов, а также подтверждение установки Skills из ClawHub в рабочей среде; это стандартный вариант проверки релиза
• product: package, а также каналы MCP, очистка cron/субагентов, веб-поиск OpenAI и OpenWebUI
• full: части пути выпуска Docker с OpenWebUI
• custom: точный список docker_lanes для целевых повторных запусков

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

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

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

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

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

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

Публикация стабильной версии с dist-тегом beta по умолчанию:

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

Прямое продвижение стабильной версии в latest задаётся явно:

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

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

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

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

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

Утверждённый пробный или реальный запуск начальной загрузки после создания тега должен включать точный тег релиза, а также идентификатор запуска, попытку и ветку родительского OpenClaw Release Publish. Родитель подтверждает SHA собственного рабочего процесса и отдельный точный доверенный SHA main для Plugin ClawHub New; дочерний запуск и каждое утверждение защищённого окружения должны соответствовать этому утверждённому SHA дочернего процесса. Тег релиза повторно проверяется перед каждой попыткой публикации и изменением доверенного издателя.

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

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

OpenClaw NPM Release принимает следующие входные данные, управляемые оператором:

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

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

OpenClaw Release Publish принимает следующие входные данные, управляемые оператором:

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

OpenClaw Release Checks принимает следующие входные данные, управляемые оператором:

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

Правила:

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

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

Эта устаревшая последовательность предназначена для обычного оркестрируемого выпуска, который также охватывает плагины, GitHub Release, Windows и работу для других платформ. Это не ежемесячный путь расширенного стабильного выпуска .33+ только для npm, описанный в начале этой страницы.

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

1. Запустите OpenClaw NPM Release с preflight_only=true. Пока тег ещё не существует, для пробного запуска рабочего процесса предварительной проверки без публикации можно использовать текущий полный SHA коммита ветки рабочего процесса.
2. Выберите npm_dist_tag=beta для обычного процесса с первоначальным бета-выпуском или latest, только если намеренно требуется прямая публикация стабильной версии.
3. Запустите Full Release Validation в ветке выпуска, по тегу выпуска или полному SHA коммита, если требуется получить из одного вручную запускаемого рабочего процесса обычный CI, а также проверку кеша промптов в реальной среде, Docker, QA Lab, Matrix и Telegram. Если намеренно требуется только детерминированный обычный граф тестов, вместо этого запустите вручную рабочий процесс CI для ссылки выпуска.
4. Выберите точный тег выпуска openclaw/openclaw-windows-node, не являющийся предварительной версией, подписанные установщики x64 и ARM64 которого должны быть выпущены. Сохраните его как windows_node_tag, а проверенную карту их дайджестов — как windows_node_installer_digests. Вспомогательный инструмент кандидата на выпуск записывает оба значения и включает их в сгенерированную команду публикации.
5. Сохраните успешные preflight_run_id, full_release_validation_run_id и точное значение full_release_validation_run_attempt.
6. Запустите OpenClaw Release Publish из доверенного main с теми же tag и npm_dist_tag, выбранным windows_node_tag, сохранённым для него windows_node_installer_digests, сохранёнными preflight_run_id, full_release_validation_run_id и full_release_validation_run_attempt. Этот процесс публикует вынесенные плагины в npm и ClawHub перед продвижением пакета OpenClaw в npm.
7. Если выпуск был размещён в beta, используйте рабочий процесс openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml, чтобы продвинуть эту стабильную версию из beta в latest.
8. Если выпуск намеренно был опубликован напрямую в latest и beta должен сразу указывать на ту же стабильную сборку, используйте тот же рабочий процесс выпуска, чтобы назначить обоим dist-тегам стабильную версию, либо дождитесь, пока запланированная самовосстанавливающая синхронизация позднее переместит beta.

Изменение dist-тегов выполняется в репозитории журнала выпусков, поскольку для него по-прежнему требуется NPM_TOKEN, тогда как репозиторий исходного кода сохраняет публикацию только через OIDC. Благодаря этому и путь прямой публикации, и путь продвижения после первоначального бета-выпуска остаются документированными и видимыми для оператора.

Если сопровождающему приходится вернуться к локальной аутентификации npm, все команды CLI 1Password (op) следует выполнять только в отдельном сеансе tmux. Не вызывайте op напрямую из основной оболочки агента: выполнение внутри tmux делает запросы, оповещения и обработку OTP наблюдаемыми и предотвращает повторные оповещения хоста.

Общедоступные ссылки

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

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

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

• Каналы выпуска