--- read_when: - Поиск определений общедоступных каналов выпуска - Запуск проверки релиза или приёмочного тестирования пакета - О наименовании версий и периодичности выпусков summary: Ветки релизов, контрольный список оператора, среды проверки, именование версий и периодичность выпуска title: Политика выпусков x-i18n: generated_at: "2026-07-13T18:32:29Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 24 provider: openai source_hash: f7baee985f9cb8865846d6a6186321f9aa412bfda186446f3ca9c62c656b3add source_path: reference/RELEASING.md workflow: 16 --- OpenClaw в настоящее время предоставляет три пользовательских канала обновлений: - stable: существующий канал продвигаемых выпусков, который до завершения отдельного этапа по CLI/каналам по-прежнему разрешается через npm `latest` - beta: теги предварительных выпусков, публикуемые в npm `beta` - dev: перемещающаяся вершина `main` Кроме того, операторы выпуска могут публиковать основной пакет за последний завершённый месяц в npm `extended-stable`, начиная с патча `33`. Обычная финальная линия текущего месяца остаётся в npm `latest`; это разделение публикаций на стороне оператора само по себе не меняет разрешение каналов обновления CLI. Альфа-сборки Tideclaw относятся к отдельной внутренней ветке предварительных выпусков (dist-tag npm `alpha`), описанной в разделах [Входные параметры рабочего процесса NPM](#npm-workflow-inputs) и [Тестовые среды выпуска](#release-test-boxes). ## Именование версий - Версия ежемесячного расширенно стабильного выпуска 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-tag частных репозиториев, образы 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 и запуск Full Release Validation должны указывать на один и тот же коммит. Защищённая `main` уже должна содержать финальную версию строго более позднего календарного месяца с патчем ниже `33`; обслуживающие патчи остаются допустимыми после того, как `main` продвинется более чем на один месяц. В точной расширенно стабильной ветке обновите версию корневого пакета до `YYYY.M.P`, выполните `pnpm release:prep` и убедитесь, что каждый доступный для публикации пакет расширения имеет ту же версию. Зафиксируйте и отправьте все сгенерированные изменения, создайте и отправьте неизменяемый тег `vYYYY.M.P` на этом коммите и запишите полученный полный SHA. Рабочие процессы используют это подготовленное дерево; они не обновляют и не синхронизируют версии за вас. Запустите предварительную проверку npm и Full Release Validation для точно этой подготовленной вершины ветки, затем сохраните идентификаторы обоих запусков и номер успешной попытки запуска Full Release Validation: ```bash gh workflow run openclaw-npm-release.yml \ --ref extended-stable/YYYY.M.33 \ -f tag=vYYYY.M.P \ -f preflight_only=true \ -f npm_dist_tag=extended-stable gh workflow run full-release-validation.yml \ --ref extended-stable/YYYY.M.33 \ -f ref=extended-stable/YYYY.M.33 \ -f release_profile=stable ``` `release_profile=stable` — существующий профиль глубины проверки; он отделён от dist-tag npm `extended-stable` и намеренно остаётся без изменений. После успешного завершения обоих запусков опубликуйте каждый доступный для публикации в npm официальный плагин из точно той же вершины ветки. Патч `P` должен быть `33` или выше. Передайте полный SHA выпуска как `ref`, дождитесь завершения всей матрицы и обратного чтения из реестра, затем сохраните идентификатор успешного запуска Plugin NPM Release: ```bash RELEASE_SHA="$(git rev-parse HEAD)" gh workflow run plugin-npm-release.yml \ --ref extended-stable/YYYY.M.33 \ -f publish_scope=all-publishable \ -f ref="$RELEASE_SHA" \ -f npm_dist_tag=extended-stable ``` Рабочий процесс использует обычный подготовленный перечень пакетов `all-publishable`, включая пакеты, исходный код которых не изменился. Перед успешным завершением он проверяет каждый точный пакет и каждый тег плагина `extended-stable`. Если частичный запуск завершается ошибкой, повторите ту же команду: уже опубликованные пакеты используются повторно, отсутствующие или устаревшие теги плагинов согласуются в среде выпуска npm, а итоговое обратное чтение по-прежнему охватывает полный набор пакетов. После успешного завершения рабочего процесса плагинов и готовности среды выпуска npm опубликуйте точный tarball основной предварительной проверки. Публикация основного пакета проверяет, что указанный запуск плагинов имеет состояние `completed/success` в той же канонической ветке и точно тот же SHA исходного кода: ```bash gh workflow run openclaw-npm-release.yml \ --ref extended-stable/YYYY.M.33 \ -f tag=vYYYY.M.P \ -f preflight_only=false \ -f npm_dist_tag=extended-stable \ -f preflight_run_id= \ -f full_release_validation_run_id= \ -f full_release_validation_run_attempt= \ -f plugin_npm_run_id= ``` Для форка или непроизводственной репетиции, которая намеренно не может удовлетворить ежемесячной политике `.33` или политике месяца защищённой `main`, добавьте `-f bypass_extended_stable_guard=true` как к предварительному запуску npm, так и к запуску публикации. Значение по умолчанию — `false`. Обход принимается только с `npm_dist_tag=extended-stable` и фиксируется в сводке рабочего процесса. Он не обходит каноническую ссылку рабочего процесса `extended-stable/YYYY.M.33`, равенство вершины ветки, тега и рабочей копии, синтаксис финального тега, равенство версий пакета и тега, идентичность указанных запусков и манифеста, происхождение tarball, согласование среды, обратное чтение из реестра или свидетельство исправления селектора. Рабочий процесс публикации проверяет идентичность указанных запусков предварительной проверки, валидации и плагинов, дайджест подготовленного tarball и селекторы основного пакета в реестре. После успешного завершения рабочего процесса независимо подтвердите результат: ```bash npm view openclaw@YYYY.M.P version --userconfig "$(mktemp)" npm view openclaw@extended-stable version --userconfig "$(mktemp)" ``` Обе команды должны вернуть `YYYY.M.P`. Если публикация проходит успешно, но обратное чтение селектора завершается ошибкой, не публикуйте повторно неизменяемую версию пакета. Используйте единственную команду исправления `npm dist-tag add openclaw@YYYY.M.P extended-stable`, выведенную в всегда выполняемой сводке завершившегося ошибкой рабочего процесса, затем повторите оба независимых обратных чтения. Откат к предыдущему селектору — отдельное решение оператора, а не способ исправления обратного чтения. Публичная документация поддержки первоначально определяет Slack, Discord и Codex как поддерживаемые расширенно стабильные поверхности плагинов. Этот список является заявлением о поддержке, а не списком разрешений в коде выпуска: каждый доступный для публикации в npm официальный плагин следует одному и тому же пути публикации точной версии. Обычный контрольный список ниже по-прежнему охватывает бета-версию, `latest`, выпуск GitHub, плагины, macOS, Windows и публикацию для других платформ. Не выполняйте эти шаги для данного расширенно стабильного процесса только для npm. ## Контрольный список оператора обычного выпуска Этот контрольный список описывает публичную форму процесса выпуска. Частные учётные данные, подписание, нотариальное заверение, восстановление dist-tag и сведения об аварийном откате остаются в доступном только сопровождающим регламенте выпуска. 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 --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. Запустите Full Release Validation с привязкой к SHA выпуска и включённым повторным использованием свидетельств. Облегчённый родительский запуск должен записать `changelog-only-release-v1`, указывать на успешно проверенный SHA кода и не запускать дочерние процессы проверки продукта. При этом повторно используются свидетельства продукта, но не байты пакетов. 8. Запустите `OpenClaw NPM Release` с `preflight_only=true` для SHA/тега выпуска. Сохраните успешный `preflight_run_id`. Это собирает и проверяет точные байты пакета, включающие окончательный журнал изменений. 9. Пометьте SHA выпуска тегом, затем запустите вспомогательный инструмент кандидата с успешным родительским запуском проверки SHA выпуска и предварительной проверкой npm, не запуская их повторно: ```bash pnpm release:candidate -- \ --tag vYYYY.M.PATCH-beta.N \ --full-release-run \ --npm-preflight-run \ --skip-dispatch ``` Для стабильного выпуска также передайте `--windows-node-tag vX.Y.Z`. Вспомогательный скрипт проверяет происхождение примечаний к выпуску, байты предварительной проверки npm, подтверждение установки/обновления в Parallels, подтверждение пакета Telegram и планы публикации плагинов, а затем выводит команду публикации. `OpenClaw Release Publish` параллельно отправляет выбранные или все доступные для публикации пакеты плагинов в npm и тот же набор в ClawHub, а после успешной публикации плагинов в npm продвигает подготовленный артефакт предварительной проверки OpenClaw для npm с соответствующим dist-tag. Рабочая копия выпуска остаётся корнем продукта и данных, а планирование и итоговая проверка выполняются из точной доверенной рабочей копии с исходным кодом рабочего процесса, чтобы более старый коммит выпуска не мог незаметно использовать устаревшие инструменты выпуска. До запуска любого дочернего процесса публикации формируется и кэшируется точное содержимое выпуска GitHub. Если полный соответствующий раздел `CHANGELOG.md` укладывается в ограничение GitHub в 125,000 символов и защитный предел средства формирования в 125,000 байт, страница содержит этот раздел `## YYYY.M.PATCH` целиком, включая его заголовок. Если исходный раздел не помещается, на странице сохраняются точные сгруппированные редакционные примечания, а слишком объёмная запись о вкладах заменяется стабильной ссылкой на полную запись в привязанном к тегу `CHANGELOG.md`; частичные записи и обрезанные пункты никогда не публикуются. Рабочий процесс выбирает полное или компактное содержимое до добавления `### Release verification`; если добавление завершающего блока подтверждений превысит ограничение, он сохраняет каноническое содержимое и вместо этого полагается на неизменяемые прикреплённые доказательства. Стабильные выпуски, опубликованные в npm `latest`, становятся последним выпуском GitHub, а стабильные обслуживающие выпуски, оставленные в npm `beta`, создаются с GitHub `latest=false`. Рабочий процесс также загружает в выпуск GitHub доказательства зависимостей из предварительной проверки, манифест полной валидации и доказательства проверки реестра после публикации для реагирования на инциденты после выпуска. Он немедленно выводит идентификаторы дочерних запусков, автоматически одобряет шлюзы окружения выпуска, которые разрешено одобрять токену рабочего процесса, суммирует сбои дочерних заданий с окончаниями журналов, заранее создаёт черновик страницы выпуска GitHub и параллельно с публикацией OpenClaw в npm продвигает артефакты Windows и Android, завершает страницу выпуска и доказательства зависимостей после успешного выполнения этих этапов, ожидает ClawHub всякий раз, когда публикуется OpenClaw в npm, затем запускает средство проверки бета-версии из доверенной основной ветки и загружает доказательства после публикации для выпуска GitHub, пакета npm, выбранных пакетов плагинов npm, выбранных пакетов ClawHub, идентификаторов запусков дочерних рабочих процессов и необязательного идентификатора запуска NPM Telegram. Средство проверки начальной загрузки ClawHub требует точные путь и SHA рабочего процесса доверенной основной ветки, попытки запуска производителя и завершающего процесса, SHA выпуска, запрошенный набор пакетов, неизменяемый кортеж артефакта пакета и артефакт итогового чтения из реестра; успешный устаревший запуск по ссылке выпуска не принимается. Затем выполните приёмочную проверку пакета после публикации для опубликованного пакета `openclaw@YYYY.M.PATCH-beta.N` или `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 после публикации, при необходимости — отдельный E2E Telegram для опубликованного npm-пакета, когда требуется подтверждение канала после публикации, продвижение dist-tag, если оно необходимо, проверьте сформированную страницу выпуска GitHub, выполните шаги объявления о выпуске, а затем завершите [закрытие стабильного выпуска в основной ветке](#stable-main-closeout), прежде чем считать стабильный выпуск завершённым. ## Закрытие стабильного выпуска в основной ветке Публикация стабильного выпуска не завершена, пока `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`. Отправьте изменения, а затем, прежде чем считать стабильный выпуск завершённым, убедитесь, что `origin/main` содержит выпущенную версию и журнал изменений. 6. После каждой закрытой проверки отката поддерживайте переменные репозитория `RELEASE_ROLLBACK_DRILL_ID` и `RELEASE_ROLLBACK_DRILL_DATE` в актуальном состоянии. `OpenClaw Stable Main Closeout` запускается от отправки `main`, содержащей выпущенную версию, журнал изменений и appcast после публикации стабильного выпуска. Он считывает неизменяемые доказательства после публикации, чтобы связать выпущенный тег с запусками полной валидации выпуска и публикации, а затем проверяет стабильное состояние основной ветки, выпуск, обязательную выдержку стабильного выпуска и блокирующие доказательства производительности. Он прикрепляет к выпуску GitHub неизменяемые манифест закрытия и контрольную сумму. Автоматический триггер при отправке пропускает устаревшие выпуски, созданные до появления неизменяемых доказательств после публикации, и никогда не считает такой пропуск завершённым закрытием. Для полного закрытия необходимы оба артефакта и соответствующая контрольная сумма. Частичный манифест повторно воспроизводит записанные в нём SHA `main` и проверку отката, чтобы заново сформировать идентичные байты, а затем прикрепляет отсутствующую контрольную сумму; недействительная пара или контрольная сумма без манифеста остаётся блокирующим условием. Запуск, инициированный отправкой без переменных репозитория для проверки отката, пропускается без завершения закрытия; отсутствующая или созданная более 90 дней назад запись проверки всё равно блокирует ручное закрытие на основе доказательств. Закрытые команды восстановления остаются в руководстве только для сопровождающих. Используйте ручной запуск только для исправления или повторного выполнения подтверждённого доказательствами закрытия стабильного выпуска. Устаревший резервный тег исправления может повторно использовать доказательства базового пакета, только если тег исправления разрешается в тот же исходный коммит, что и базовый стабильный тег. Его выпуск Android повторно использует проверенный APK базового тега и добавляет сведения о происхождении для тега исправления. Исправление с другим исходным кодом должно опубликовать и проверить собственные доказательства пакета и использовать более высокий Android `versionCode`. ## Предварительная проверка выпуска - Выполните `pnpm check:test-types` перед предварительной проверкой выпуска, чтобы тестовый TypeScript оставался охваченным вне более быстрого локального шлюза `pnpm check`. - Выполните `pnpm check:architecture` перед предварительной проверкой выпуска, чтобы более широкие проверки циклов импорта и архитектурных границ успешно проходили вне более быстрого локального шлюза. - Выполните `pnpm build && pnpm ui:build` перед `pnpm release:check`, чтобы ожидаемые артефакты выпуска `dist/*` и пакет Control UI существовали для этапа проверки упаковки. - Выполните `pnpm release:prep` после повышения корневой версии и перед созданием тега. Команда запускает все детерминированные генераторы выпуска, результаты которых часто расходятся после изменения версии, конфигурации или API: версии плагинов, npm shrinkwrap, инвентарь плагинов, базовую схему конфигурации, метаданные конфигурации встроенных каналов, базовый уровень документации конфигурации, экспорты SDK плагинов и базовый уровень API SDK плагинов. `pnpm release:check` повторно запускает эти проверки в режиме проверки (включая проверку бюджета поверхности SDK плагинов) и за один проход сообщает обо всех расхождениях сформированных данных перед запуском проверок выпуска пакета. - Синхронизация версий плагинов по умолчанию обновляет публикуемый пакет среды выполнения `@openclaw/ai`, версии официальных пакетов плагинов и существующие минимальные версии `openclaw.compat.pluginApi` до версии выпуска OpenClaw. Считайте это поле минимальной версией API SDK/среды выполнения плагинов, а не просто копией версии пакета: для выпусков только плагинов, которые намеренно сохраняют совместимость со старыми хостами OpenClaw, оставляйте минимальную версию на уровне самого старого поддерживаемого API хоста и документируйте этот выбор в доказательствах выпуска плагина. - Перед одобрением выпуска запустите вручную рабочий процесс `Full Release Validation`, чтобы из одной точки запустить все тестовые среды предварительного выпуска. Он принимает ветку, тег или полный SHA коммита, запускает вручную `CI` и запускает `OpenClaw Release Checks` для проверок установки, приёмки пакета, межплатформенных проверок пакета, соответствия QA Lab, Matrix и Telegram. Стабильные и полные запуски всегда включают исчерпывающую проверку в реальной среде/E2E и выдержку пути выпуска Docker; `run_release_soak=true` сохранён для явной выдержки бета-версии. Приёмка пакета обеспечивает канонический E2E Telegram для пакета во время валидации кандидата, предотвращая запуск второго параллельного процесса опроса в реальной среде. После публикации бета-версии укажите `release_package_spec`, чтобы повторно использовать выпущенный пакет npm в проверках выпуска, приёмке пакета и E2E Telegram для пакета без повторной сборки архива выпуска. Указывайте `npm_telegram_package_spec` только тогда, когда Telegram должен использовать опубликованный пакет, отличный от остальной валидации выпуска. Указывайте `package_acceptance_package_spec`, когда приёмка пакета должна использовать опубликованный пакет, отличный от спецификации пакета выпуска. Указывайте `evidence_package_spec`, когда отчёт с доказательствами выпуска должен подтвердить, что валидация соответствует опубликованному пакету npm, не требуя запуска E2E Telegram. ```bash node scripts/full-release-validation-at-sha.mjs \ --sha \ --target-ref release/YYYY.M.PATCH ``` - Запускайте вручную рабочий процесс `Package Acceptance`, когда требуется независимое подтверждение кандидата пакета, пока продолжается работа над выпуском. Используйте `source=npm` для `openclaw@beta`, `openclaw@latest` или точной версии выпуска; `source=ref` — чтобы упаковать доверенную ветку/тег/SHA `package_ref` с текущей тестовой инфраструктурой `workflow_ref`; `source=url` — для общедоступного HTTPS-архива с обязательным SHA-256 и строгой политикой общедоступных URL; `source=trusted-url` — для именованной политики доверенного источника с обязательными `trusted_source_id` и SHA-256; или `source=artifact` — для архива, загруженного другим запуском GitHub Actions. Рабочий процесс разрешает кандидата в `package-under-test`, повторно использует планировщик выпуска Docker E2E для этого архива и может выполнять QA Telegram с тем же архивом посредством `telegram_mode=mock-openai` или `telegram_mode=live-frontier`. Когда выбранные сценарии Docker включают `published-upgrade-survivor`, артефактом пакета служит кандидат, а `published_upgrade_survivor_baseline` выбирает опубликованный базовый вариант. `update-restart-auth` использует пакет кандидата одновременно как установленный CLI и как тестируемый пакет, чтобы проверить путь управляемого перезапуска команды обновления кандидата. Пример: ```bash gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai ``` Распространённые профили: - `smoke`: сценарии установки/каналов/агента, сети Gateway и перезагрузки конфигурации - `package`: сценарии пакета/обновления/перезапуска/плагинов на основе нативных артефактов без OpenWebUI или действующего ClawHub - `product`: профиль пакета, а также каналы MCP, очистка cron/субагентов, веб-поиск OpenAI и OpenWebUI - `full`: части пути выпуска Docker с OpenWebUI - `custom`: точный выбор `docker_lanes` для целевого повторного запуска - Запускайте вручную процесс `CI` напрямую, когда требуется только детерминированное стандартное покрытие CI для кандидата на выпуск. Ручные запуски CI обходят ограничение областью изменений и принудительно запускают сегменты Linux Node, сегменты встроенных плагинов, сегменты контрактов плагинов и каналов, совместимость с Node 22, `check-*`, `check-additional-*`, дымовые проверки собранных артефактов, проверки документации, Python-навыки, Windows, macOS и сценарии интернационализации Control UI. Отдельные ручные запуски CI включают Android только при запуске с `include_android=true`; `Full Release Validation` передаёт этот входной параметр своему дочернему процессу CI. ```bash gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true ``` - Запускайте `pnpm qa:otel:smoke` при проверке телеметрии выпуска. Этот процесс выполняет QA-lab через локальный приёмник OTLP/HTTP и проверяет экспорт трассировок, метрик и журналов, а также ограниченность атрибутов трассировки и редактирование содержимого и идентификаторов без необходимости использовать Opik, Langfuse или другой внешний сборщик. - Запускайте `pnpm qa:otel:collector-smoke` при проверке совместимости со сборщиком. Этот процесс направляет тот же экспорт OTLP из QA-lab через настоящий контейнер Docker с OpenTelemetry Collector перед проверками локального приёмника. - Запускайте `pnpm qa:prometheus:smoke` при проверке защищённого сбора данных Prometheus. Этот процесс выполняет QA-lab, отклоняет неаутентифицированные запросы сбора и проверяет, что критически важные для выпуска семейства метрик не содержат текст запросов, необработанные идентификаторы, токены аутентификации и локальные пути. - Запускайте `pnpm qa:observability:smoke`, чтобы последовательно выполнить сценарии дымовой проверки OpenTelemetry и Prometheus из рабочей копии исходного кода. - Запускайте `pnpm release:check` перед каждым выпуском с тегом. - Предварительная проверка `OpenClaw NPM Release` формирует свидетельства о зависимостях выпуска перед упаковкой tarball npm. Шлюз уязвимостей из рекомендаций npm блокирует выпуск. Отчёты о рисках транзитивного манифеста, владении зависимостями и области установки, а также изменениях зависимостей служат только свидетельствами выпуска. Отчёт об изменениях зависимостей сравнивает кандидата на выпуск с предыдущим достижимым тегом выпуска. Предварительная проверка загружает свидетельства о зависимостях как `openclaw-release-dependency-evidence-`, а также встраивает их в `dependency-evidence/` внутри подготовленного артефакта предварительной проверки npm. Фактический путь публикации повторно использует этот артефакт предварительной проверки, а затем прикрепляет те же свидетельства к выпуску GitHub как `openclaw--dependency-evidence.zip`. - Запускайте `OpenClaw Release Publish` для изменяющей состояния последовательности публикации после создания тега. Запускайте обычные бета- и стабильные публикации из доверенной `main`; тег выпуска по-прежнему выбирает точный целевой коммит и может указывать на `release/YYYY.M.PATCH`. Альфа-публикации Tideclaw остаются в соответствующей альфа-ветке. Передайте успешный `preflight_run_id` npm для OpenClaw, успешный `full_release_validation_run_id` и точный `full_release_validation_run_attempt`, а также сохраняйте область публикации плагинов по умолчанию `all-publishable`, если только вы намеренно не выполняете целевое исправление. Процесс последовательно выполняет публикацию плагинов в npm, публикацию плагинов в ClawHub и публикацию OpenClaw в npm, чтобы основной пакет не был опубликован раньше вынесенных из него плагинов; продвижение Windows и Android выполняется параллельно с публикацией основного пакета в npm на странице черновика выпуска. Повторные запуски публикации можно возобновлять: если версия основного пакета npm уже опубликована, этап публикации основного пакета пропускается после того, как процесс подтвердит соответствие tarball в реестре артефакту предварительной проверки тега; продвижение Windows/Android пропускается, если выпуск уже содержит проверенный контракт артефактов, поэтому при повторной попытке заново выполняются только неудавшиеся этапы. Для целевых исправлений только плагинов требуются `plugin_publish_scope=selected` и непустой список плагинов. Для запусков `all-publishable` только для плагинов требуются полные неизменяемые свидетельства предварительной проверки и Full Release Validation; частичные свидетельства отклоняются. - Для стабильного `OpenClaw Release Publish` требуется точный `windows_node_tag` после появления соответствующего выпуска `openclaw/openclaw-windows-node`, не являющегося предварительным, а также утверждённая для кандидата карта `windows_node_installer_digests`. Перед запуском любого дочернего процесса публикации он проверяет, что исходный выпуск опубликован, не является предварительным, содержит необходимые установщики x64/ARM64 и по-прежнему соответствует утверждённой карте. Затем он запускает `Windows Node Release`, пока выпуск OpenClaw ещё является черновиком, передавая закреплённую карту дайджестов установщиков без изменений. Дочерний процесс загружает подписанные установщики Windows Hub из этого точного тега, сверяет их с закреплёнными дайджестами, на исполнителе Windows проверяет, что их подписи Authenticode используют ожидаемого подписанта OpenClaw Foundation, записывает манифест SHA-256 и загружает установщики вместе с манифестом в канонический выпуск OpenClaw на GitHub, после чего повторно загружает продвинутые артефакты и проверяет их наличие в манифесте и хеши. Родительский процесс перед публикацией проверяет текущий контракт артефактов x64, ARM64 и контрольных сумм. Прямое восстановление отклоняет неожиданные имена артефактов `OpenClawCompanion-*`, прежде чем заменить ожидаемые артефакты контракта закреплёнными байтами исходного выпуска. Запускайте `Windows Node Release` вручную только для восстановления и всегда передавайте точный тег, а не `latest`, а также явную JSON-карту `expected_installer_digests` из утверждённого исходного выпуска. Ссылки для скачивания на сайте должны вести на точные URL-адреса артефактов выпуска OpenClaw для текущего стабильного выпуска либо на `releases/latest/download/...` только после проверки, что перенаправление GitHub на последний выпуск указывает на тот же выпуск; не размещайте ссылку только на страницу выпуска сопутствующего репозитория. - Проверки релиза теперь выполняются в отдельном запускаемом вручную рабочем процессе: `OpenClaw Release Checks`. Он также запускает проверку эквивалентности с имитациями QA Lab, а перед одобрением релиза — быстрый профиль с реальным Matrix и проверку QA Telegram. Проверки с реальными сервисами используют окружение `qa-live-shared`; Telegram также использует аренду учетных данных Convex CI. Запускайте вручную рабочий процесс `QA-Lab - All Lanes` с `matrix_profile=all` и `matrix_shards=true`, когда требуется параллельно проверить полный набор функций транспорта Matrix, мультимедиа и E2EE. - Межплатформенная проверка установки и обновления во время выполнения входит в общедоступные `OpenClaw Release Checks` и `Full Release Validation`, которые напрямую вызывают переиспользуемый рабочий процесс `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`. Такое разделение сделано намеренно: реальный путь выпуска в npm остается коротким, детерминированным и сосредоточенным на артефактах, а более медленные проверки с реальными сервисами выполняются отдельно, чтобы не задерживать и не блокировать публикацию. - Проверки релиза, использующие секреты, следует запускать через `Full Release Validation` или из ссылки на рабочий процесс `main`/release, чтобы логика рабочего процесса и секреты оставались под контролем. - `OpenClaw Release Checks` принимает ветку, тег или полный SHA коммита, если разрешенный коммит достижим из ветки OpenClaw или тега релиза. - Предварительная проверка `OpenClaw NPM Release`, предназначенная только для валидации, также принимает текущий полный 40-символьный SHA коммита ветки рабочего процесса без необходимости отправлять тег. Путь с SHA предназначен только для валидации, и его нельзя преобразовать в реальную публикацию. В режиме SHA рабочий процесс создает `v` только для проверки метаданных пакета; для реальной публикации по-прежнему требуется настоящий тег релиза. - В обоих рабочих процессах реальная публикация и продвижение выполняются на раннерах GitHub, а неизменяющий данные путь валидации может использовать более мощные раннеры Blacksmith Linux. - Этот рабочий процесс запускает `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`, используя секреты рабочего процесса `OPENAI_API_KEY` и `ANTHROPIC_API_KEY`. - Предварительная проверка релиза npm больше не ожидает отдельного этапа проверок релиза. - Перед локальным созданием тега кандидата на выпуск запустите `RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check`. Вспомогательная команда последовательно запускает быстрые защитные проверки релиза, проверки выпуска плагинов в npm/ClawHub, сборку, сборку пользовательского интерфейса и `release:openclaw:npm:check`, чтобы обнаружить распространенные ошибки, блокирующие одобрение, до запуска рабочего процесса публикации GitHub. - Перед одобрением запустите `RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts` (или соответствующий тег предварительного/исправленного выпуска). - После публикации в npm запустите `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH` (или соответствующую бета-версию/версию исправления), чтобы проверить путь установки опубликованного пакета из реестра в новом временном префиксе. - После публикации бета-версии запустите `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.PATCH-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`, чтобы проверить первоначальную настройку установленного пакета, настройку Telegram и реальное сквозное тестирование Telegram опубликованного пакета npm с использованием общего пула арендуемых учетных данных Telegram. Для разовых локальных запусков сопровождающие могут не указывать переменные Convex и напрямую передать три учетных данных окружения `OPENCLAW_QA_TELEGRAM_*`. - Чтобы запустить полную дымовую проверку бета-версии после публикации с компьютера сопровождающего, используйте `pnpm release:beta-smoke -- --beta betaN`. Вспомогательная команда выполняет проверку обновления npm и новой целевой установки в Parallels, запускает `NPM Telegram Beta E2E`, опрашивает точный запуск рабочего процесса, скачивает артефакт и выводит отчет Telegram. - Сопровождающие могут запустить такую же проверку после публикации из GitHub Actions с помощью запускаемого вручную рабочего процесса `NPM Telegram Beta E2E`. Он намеренно запускается только вручную и не выполняется при каждом слиянии. - Автоматизация релиза для сопровождающих сначала выполняет предварительную проверку, а затем продвижение: - Для реальной публикации в npm требуется успешный результат npm `preflight_run_id`. - Оркестрация и предварительная проверка обычных бета- и стабильных публикаций используют доверенный `main` для точного целевого тега. Публикация и предварительная проверка альфа-версии Tideclaw используют соответствующую альфа-ветку. - Стабильные релизы npm по умолчанию используют `beta`; для стабильной публикации npm можно явно указать `latest` во входных данных рабочего процесса. - Изменение dist-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` также контролирует ограничение `unpackedSize` для npm pack в tar-архиве обновления-кандидата, чтобы сквозное тестирование установщика обнаруживало случайное разрастание пакета до начала публикации релиза. - Если работа над релизом затрагивала планирование CI, манифесты длительности расширений или матрицы тестов расширений, перед одобрением повторно создайте и проверьте управляемые планировщиком выходные матрицы `plugin-prerelease-extension-shard` из `.github/workflows/plugin-prerelease.yml`, чтобы примечания к выпуску не описывали устаревшую структуру CI. - Готовность стабильного релиза macOS также включает компоненты обновления: в релизе GitHub должны присутствовать упакованные `.zip`, `.dmg` и `.dSYM.zip`; после публикации `appcast.xml` в `main` должен указывать на новый архив стабильной версии (рабочий процесс публикации macOS фиксирует это изменение автоматически или открывает PR для appcast, если прямая отправка заблокирована); упакованное приложение должно сохранять идентификатор пакета без признака отладочной сборки, непустой URL канала Sparkle и значение `CFBundleVersion`, не ниже канонического минимального номера сборки Sparkle для этой версии релиза. ## Тестовые среды релиза `Full Release Validation` позволяет операторам запускать полную матрицу продукта из одной точки входа. Используйте вспомогательную команду, чтобы каждый дочерний рабочий процесс выполнялся из временной ветки, закрепленной на одном доверенном SHA рабочего процесса `main`, а запрошенный коммит оставался проверяемым кандидатом: ```bash pnpm ci:full-release \ --sha \ --target-ref release/YYYY.M.PATCH ``` Вспомогательная команда получает текущий `origin/main`, отправляет `release-ci/-...` с этим доверенным коммитом рабочего процесса, определяет `beta` для альфа- и бета-версий пакета и `stable` в остальных случаях, запускает `Full Release Validation` из временной ветки с `ref=`, проверяет, что `headSha` каждого дочернего рабочего процесса соответствует закрепленному SHA родительского рабочего процесса, а затем удаляет временную ветку. Передайте `-f reuse_evidence=false`, чтобы принудительно запустить проверку заново, `-f release_profile=full` для широкой рекомендательной проверки или `--workflow-sha `, чтобы закрепить более старый коммит, который все еще достижим из текущего `origin/main`. Сам рабочий процесс никогда не изменяет ссылки репозитория. Это позволяет использовать инструменты релиза, доступные только в основной ветке, не добавляя их коммиты в кандидат, и исключает случайное подтверждение более нового дочернего запуска `main`. Когда Code SHA успешно пройдет проверки, зафиксируйте только `CHANGELOG.md` и запустите ту же вспомогательную команду с Release SHA: ```bash pnpm ci:full-release \ --sha \ --target-ref release/YYYY.M.PATCH ``` Второй родительский процесс повторно использует свидетельства проверки продукта, только если GitHub подтверждает, что Release SHA является потомком Code SHA, а полный набор измененных путей в точности равен `CHANGELOG.md`. Он записывает `changelog-only-release-v1` и не запускает дочерние проверки продукта. Предварительная проверка npm и приемочное тестирование пакета и установки по-прежнему выполняются для Release SHA, поскольку байты его tar-архива изменились. Для нового Code SHA рабочий процесс разрешает целевой объект, вручную запускает `CI`, а затем запускает `OpenClaw Release Checks`. `OpenClaw Release Checks` параллельно запускает дымовую проверку установки, межплатформенные проверки релиза, проверку пути релиза с реальными сервисами и сквозным тестированием в Docker при включенной длительной проверке, Package Acceptance с каноническим сквозным тестом пакета Telegram, проверку эквивалентности QA Lab, реальный Matrix и реальный Telegram. Полный запуск или запуск всех проверок считается приемлемым, только если сводка `Full Release Validation` показывает успешные результаты `normal_ci`, `plugin_prerelease` и `release_checks`, кроме случая, когда прицельный повторный запуск намеренно пропустил отдельний дочерний процесс `Plugin Prerelease`. Используйте отдельный дочерний процесс `npm-telegram` только для прицельного повторного запуска проверки опубликованного пакета с `release_package_spec` или `npm_telegram_package_spec`. Итоговая сводка проверки содержит таблицы самых медленных заданий для каждого дочернего запуска, чтобы руководитель релиза мог видеть текущий критический путь без скачивания журналов. Дочерний процесс производительности продукта в этом пути релиза работает только с артефактами. Зонтичный процесс запускает его с `publish_reports=false`, а валидация отклоняется, если его защитная проверка режима только для артефактов не подтверждает, что публикация отчета Clawgrit осталась пропущенной. Полную матрицу этапов, точные имена заданий рабочих процессов, различия между стабильным и полным профилями, артефакты и параметры прицельного повторного запуска см. в разделе [Полная валидация релиза](/ru/reference/full-release-validation). Дочерние рабочие процессы запускаются из закрепленной по SHA доверенной ссылки, в которой выполняется `Full Release Validation`. Каждый дочерний запуск должен использовать точный SHA родительского рабочего процесса. Не используйте необработанные запуски `--ref main -f ref=` для подтверждения релиза; используйте `pnpm ci:full-release --sha --target-ref release/YYYY.M.PATCH`. Используйте `release_profile` для выбора широты охвата реальных сервисов и поставщиков: - `beta`: самый быстрый критически важный для релиза путь OpenAI/ядра с реальными сервисами и Docker - `stable`: охват поставщиков и серверных компонентов для бета- и стабильных версий при одобрении релиза - `full`: стабильная версия плюс широкая рекомендательная проверка поставщиков и мультимедиа Валидация стабильной версии и полная валидация всегда запускают исчерпывающую проверку с реальными сервисами и сквозным тестированием, проверку пути релиза в Docker и ограниченную проверку сохранения работоспособности опубликованных обновлений перед продвижением. Используйте `run_release_soak=true`, чтобы запросить такую же проверку для бета-версии. Она охватывает четыре последних стабильных пакета, закрепленные базовые версии `2026.4.23` и `2026.5.2`, а также более старую версию `2026.4.15`; повторяющиеся базовые версии удаляются, а каждая оставшаяся базовая версия распределяется в отдельное задание раннера Docker. `OpenClaw Release Checks` использует доверенную ссылку рабочего процесса, чтобы один раз разрешить целевую ссылку как `release-package-under-test`, и повторно использует этот артефакт в межплатформенных проверках, Package Acceptance и проверках пути релиза в Docker при выполнении длительной проверки. Благодаря этому все среды, работающие с пакетами, используют одни и те же байты, а пакеты не собираются повторно. Когда бета-версия уже опубликована в npm, задайте `release_package_spec=openclaw@YYYY.M.PATCH-beta.N`, чтобы проверки релиза один раз скачали выпущенный пакет, извлекли SHA исходной сборки из `dist/build-info.json` и повторно использовали этот артефакт для межплатформенных проверок, Package Acceptance, пути релиза в Docker и проверок пакета Telegram. Межплатформенная дымовая проверка установки OpenAI использует `OPENCLAW_CROSS_OS_OPENAI_MODEL`, если задана переменная репозитория или организации, а иначе — `openai/gpt-5.6-luna`, поскольку этот этап подтверждает установку пакета, первоначальную настройку, запуск Gateway и один реальный запуск агента, а не измеряет производительность наиболее мощной модели. Более широкая матрица реальных поставщиков остается местом для проверки конкретных моделей. Используйте следующие варианты в зависимости от этапа релиза: ```bash # Проверить Code SHA с полной готовностью продукта. pnpm ci:full-release \ --sha \ --target-ref release/YYYY.M.PATCH # Проверить Release SHA с изменениями только в журнале изменений, повторно используя свидетельства по продукту для Code SHA. pnpm ci:full-release \ --sha \ --target-ref release/YYYY.M.PATCH # После публикации бета-версии добавить Telegram E2E для опубликованного пакета. pnpm ci:full-release \ --sha \ --target-ref release/YYYY.M.PATCH \ -f release_package_spec=openclaw@YYYY.M.PATCH-beta.N \ -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N \ -f npm_telegram_provider_mode=mock-openai ``` Не используйте полный комплексный запуск для первого повторного запуска после точечного исправления. Если один блок завершился с ошибкой, для следующей проверки используйте завершившийся с ошибкой дочерний рабочий процесс, задание, ветку Docker, профиль пакета, провайдера модели или ветку QA. Повторно запускайте полный комплексный процесс, только если исправление изменило общую оркестрацию выпуска или сделало устаревшими ранее полученные свидетельства по всем блокам. Итоговый проверяющий компонент комплексного процесса повторно проверяет записанные идентификаторы запусков дочерних рабочих процессов, поэтому после успешного повторного запуска дочернего рабочего процесса повторно запустите только завершившееся с ошибкой родительское задание `Verify full validation`. `rerun_group=all` может повторно использовать предыдущий успешный комплексный запуск, если профиль выпуска, фактическая настройка выдержки и входные данные проверки совпадают, а целевой SHA либо идентичен, либо новая цель является потомком, полный набор изменённых путей которого в точности равен `CHANGELOG.md`. При повторном использовании для точной цели записывается `exact-target-full-validation-v1`; для Release SHA после проверки записывается `changelog-only-release-v1`. В последнем случае повторно используется только проверка продукта. Предварительная проверка npm, байты пакета, происхождение примечаний к выпуску и приёмочные проверки установки и обновления по-прежнему должны выполняться для Release SHA. Любое изменение версии, исходного кода, сгенерированных файлов, зависимостей, пакета или цели, относящейся к рабочему процессу, требует нового Code SHA и новой полной проверки. Более новые комплексные запуски для той же ссылки `release/*` и группы повторного запуска автоматически заменяют выполняющиеся. Передайте `reuse_evidence=false`, чтобы принудительно начать новый полный запуск. Для ограниченного восстановления передайте комплексному процессу `rerun_group`. `all` — реальный запуск кандидата на выпуск, `ci` запускает только обычный дочерний процесс CI, `plugin-prerelease` запускает только дочерний процесс плагинов, предназначенный исключительно для выпуска, `release-checks` запускает все блоки выпуска, а более узкие группы выпуска — `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` и `npm-telegram`. Для точечных повторных запусков `npm-telegram` требуется `release_package_spec` или `npm_telegram_package_spec`; полные запуски и запуски всех проверок используют канонический Telegram E2E пакета внутри Package Acceptance. Для точечных повторных запусков на разных ОС можно добавить `cross_os_suite_filter=windows/packaged-upgrade` или другой фильтр ОС/набора. Сбои проверок выпуска QA блокируют обычную проверку выпуска, включая обязательное выявление расхождений динамических инструментов OpenClaw на стандартном уровне. Альфа-запуски Tideclaw всё ещё могут считать рекомендательными ветки проверки выпуска, не связанные с безопасностью пакета. При `release_profile=beta` наборы `Run repo/live E2E validation` с реальными провайдерами являются рекомендательными (предупреждениями, а не блокирующими ошибками); в стабильном и полном профилях они остаются блокирующими. Когда `live_suite_filter` явно запрашивает контролируемую реальную ветку QA, например Discord, WhatsApp или Slack, должна быть включена соответствующая переменная репозитория `OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED`; иначе сбор входных данных завершится с ошибкой, а не молча пропустит ветку. ### Vitest Блок Vitest — это запускаемый вручную дочерний рабочий процесс `CI`. Ручной CI намеренно обходит ограничение областью изменений и принудительно запускает обычный граф тестов для кандидата на выпуск: сегменты Linux Node, сегменты встроенных плагинов, сегменты контрактов плагинов и каналов, совместимость с Node 22, `check-*`, `check-additional-*`, дымовые проверки собранных артефактов, проверки документации, Skills на 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: ```bash 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 Блок Docker находится в `OpenClaw Release Checks`–`openclaw-live-and-e2e-checks-reusable.yml`, а также в рабочем процессе `install-smoke` режима выпуска. Он проверяет кандидата на выпуск в пакетированных средах Docker, а не только тестами на уровне исходного кода. Покрытие Docker для выпуска включает: - полную дымовую проверку установки с включённой медленной дымовой проверкой глобальной установки Bun - подготовку и повторное использование по целевому SHA дымового образа корневого Dockerfile, при этом задания QR, root/gateway и installer/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=` в повторно используемом рабочем процессе с реальными средами/E2E вместо повторного запуска всех фрагментов выпуска. Сгенерированные команды повторного запуска включают предыдущие `package_artifact_run_id` и входные данные подготовленных образов Docker, когда они доступны, поэтому завершившаяся с ошибкой ветка может повторно использовать тот же tar-архив и образы GHCR. ### QA Lab Блок QA Lab также входит в `OpenClaw Release Checks`. Это шлюз выпуска для агентного поведения и уровня каналов, отдельный от Vitest и механизмов пакетов Docker. Покрытие QA Lab для выпуска включает: - ветку проверки соответствия на имитациях, сравнивающую ветку кандидата OpenAI с базовой линией `anthropic/claude-opus-4-8` с помощью пакета агентной проверки соответствия - быстрый профиль QA для реальной Matrix, использующий среду `qa-live-shared` - ветку QA для реального Telegram, использующую аренду учётных данных Convex CI - `pnpm qa:otel:smoke`, `pnpm qa:otel:collector-smoke`, `pnpm qa:prometheus:smoke` или `pnpm qa:observability:smoke`, когда телеметрии выпуска требуется явное локальное подтверждение Используйте этот блок, чтобы ответить на вопрос: «Правильно ли выпуск ведёт себя в сценариях QA и реальных потоках каналов?» При утверждении выпуска сохраняйте URL артефактов для веток проверки соответствия, Matrix и Telegram. Полное покрытие Matrix остаётся доступным в виде ручного сегментированного запуска QA Lab, а не стандартной критической для выпуска ветки. ### Пакет Блок пакета — это шлюз устанавливаемого продукта. Он основан на `Package Acceptance` и преобразователе `scripts/resolve-openclaw-package-candidate.mjs`. Преобразователь нормализует кандидата в tar-архив `package-under-test`, используемый Docker 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 выполняет для одного и того же разрешённого tar-архива миграцию, обновление, обновление VPS под управлением root, перезапуск после обновления с настроенной аутентификацией, установку опубликованного навыка ClawHub, очистку устаревших зависимостей плагинов, автономные фикстуры плагинов, обновление плагинов, усиление экранирования привязки команд плагинов и QA пакета Telegram. Блокирующие проверки выпуска используют стандартную базовую линию последнего опубликованного пакета; бета-профиль с `run_release_soak=true`, `release_profile=stable` или `release_profile=full` расширяет проверку сохранения работоспособности после обновления опубликованных версий до `last-stable-4` и закреплённых базовых линий `2026.4.23`, `2026.5.2` и `2026.4.15` со сценариями `reported-issues`. Используйте Package Acceptance с `source=npm` для уже выпущенного кандидата, `source=ref` для локального tar-архива npm на основе SHA перед публикацией, `source=trusted-url` для корпоративного или частного зеркала, принадлежащего сопровождающим, либо `source=artifact` для подготовленного tar-архива, загруженного другим запуском GitHub Actions. Это встроенная в GitHub замена большей части покрытия пакетов и обновлений, для которого ранее требовался Parallels. Проверки выпуска на разных ОС по-прежнему важны для специфичных для ОС первоначальной настройки, установщика и поведения платформы, но при проверке продукта, связанной с пакетами и обновлениями, следует предпочитать Package Acceptance. Канонический контрольный список для проверки обновлений и плагинов приведён в разделе [Проверка обновлений и плагинов](/ru/help/testing-updates-plugins). Используйте его при выборе локальной ветки, ветки Docker, Package Acceptance или проверки выпуска, подтверждающей изменение установки или обновления плагина, очистки с помощью doctor либо миграции опубликованного пакета. Исчерпывающая миграция обновлений из каждого стабильного пакета `2026.4.23+` выполняется отдельным ручным рабочим процессом `Update Migration` и не входит в Full Release CI. Послабления для устаревших версий Package Acceptance намеренно ограничены по времени. Пакеты вплоть до `2026.4.25` могут использовать путь совместимости для пробелов в метаданных, уже опубликованных в npm: отсутствующих в tar-архиве записей состава частного QA, отсутствующего `gateway install --wrapper`, отсутствующих файлов исправлений в полученной из tar-архива фикстуре git, отсутствующего сохранённого `update.channel`, устаревших расположений записей установки плагинов, отсутствующего сохранения записей установки из каталога и миграции метаданных конфигурации во время `plugins update`. Опубликованный пакет `2026.4.26` может выдавать предупреждения о файлах отметок метаданных локальной сборки, которые уже были выпущены. Более поздние пакеты должны соответствовать современным контрактам пакетов; те же пробелы приводят к сбою проверки выпуска. Используйте более широкие профили Package Acceptance, когда вопрос выпуска касается фактически устанавливаемого пакета: ```bash gh workflow run package-acceptance.yml \ --ref main \ -f workflow_ref=main \ -f source=npm \ -f package_spec=openclaw@beta \ -f suite_profile=product \ -f published_upgrade_survivor_baseline=openclaw@2026.4.26 ``` Распространённые профили пакетов: - `smoke`: быстрые сценарии установки пакета/канала/агента, настройки сети Gateway и перезагрузки конфигурации - `package`: контракты установки/обновления/перезапуска/пакета плагина, а также подтверждение установки Skills из ClawHub в рабочей среде; это значение по умолчанию для проверки релиза - `product`: `package` плюс каналы MCP, очистка cron/субагентов, веб-поиск OpenAI и OpenWebUI - `full`: части пути релиза Docker с OpenWebUI - `custom`: точный список `docker_lanes` для целевых повторных запусков Для подтверждения Telegram с пакетом-кандидатом включите `telegram_mode=mock-openai` или `telegram_mode=live-frontier` в 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=`. 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 для точного тега вместе с контрольной суммой и сведениями о происхождении. Перед публикацией черновика проверьте оба контракта нативных ресурсов. Пример публикации бета-версии: ```bash gh workflow run openclaw-release-publish.yml \ --ref main \ -f tag=vYYYY.M.PATCH-beta.N \ -f preflight_run_id= \ -f full_release_validation_run_id= \ -f full_release_validation_run_attempt= \ -f npm_dist_tag=beta ``` Публикация стабильной версии в dist-тег beta по умолчанию: ```bash gh workflow run openclaw-release-publish.yml \ --ref main \ -f tag=vYYYY.M.PATCH \ -f windows_node_tag=vX.Y.Z \ -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:","OpenClawCompanion-Setup-arm64.exe":"sha256:"}' \ -f preflight_run_id= \ -f full_release_validation_run_id= \ -f full_release_validation_run_attempt= \ -f npm_dist_tag=beta ``` Прямое продвижение стабильной версии в `latest` задаётся явно: ```bash gh workflow run openclaw-release-publish.yml \ --ref main \ -f tag=vYYYY.M.PATCH \ -f windows_node_tag=vX.Y.Z \ -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:","OpenClawCompanion-Setup-arm64.exe":"sha256:"}' \ -f preflight_run_id= \ -f full_release_validation_run_id= \ -f full_release_validation_run_attempt= \ -f npm_dist_tag=latest ``` Используйте низкоуровневые рабочие процессы `Plugin NPM Release` и `Plugin ClawHub Release` только для целевого исправления или повторной публикации. `OpenClaw Release Publish` отклоняет `plugin_publish_scope=selected`, когда `publish_openclaw_npm=true`, чтобы основной пакет нельзя было выпустить без всех публикуемых официальных плагинов, включая `@openclaw/diffs-language-pack`. Для исправления выбранного плагина задайте `publish_openclaw_npm=false` вместе с `plugin_publish_scope=selected` и `plugins=@openclaw/name` либо запустите дочерний рабочий процесс напрямую. Первичная публикация для начальной настройки ClawHub является исключением: запустите `Plugin ClawHub New` из доверенной `main` и передайте полный SHA целевого релиза через `ref`. Никогда не запускайте сам рабочий процесс начальной настройки из тега или ветки релиза: ```bash gh workflow run plugin-clawhub-new.yml \ --ref main \ -f plugins=@openclaw/name \ -f ref= \ -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`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/full-release-validation.yml) - [`.github/workflows/package-acceptance.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/package-acceptance.yml) - [`.github/workflows/openclaw-npm-release.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-npm-release.yml) - [`.github/workflows/openclaw-release-checks.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-release-checks.yml) - [`.github/workflows/openclaw-cross-os-release-checks-reusable.yml`](https://github.com/openclaw/openclaw/blob/main/.github/workflows/openclaw-cross-os-release-checks-reusable.yml) - [`scripts/resolve-openclaw-package-candidate.mjs`](https://github.com/openclaw/openclaw/blob/main/scripts/resolve-openclaw-package-candidate.mjs) - [`scripts/openclaw-npm-release-check.ts`](https://github.com/openclaw/openclaw/blob/main/scripts/openclaw-npm-release-check.ts) - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh) - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh) Для фактической процедуры сопровождающие используют закрытую документацию по выпуску в [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md). ## Связанные материалы - [Каналы выпусков](/ru/install/development-channels)