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

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

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

provider также принимает anthropic или minimax для кроссплатформенного первоначального настроечного запуска и сквозного цикла агента. Вспомогательная команда определяет профиль beta по альфа- или бета- версиям пакетов, а в остальных случаях — stable. Передавайте альтернативные входные параметры рабочего процесса через -f key=value; используйте -f release_profile=full только для широкой проверки рекомендаций. Вспомогательная команда создаёт временную ссылку release-ci/*, закреплённую за одним доверенным SHA рабочего процесса origin/main, передаёт целевой SHA только как кандидат ref и удаляет временную ссылку после проверки. Каждый запущенный дочерний процесс должен сообщить тот же SHA рабочего процесса. Передайте -f reuse_evidence=false, чтобы принудительно запустить проверку заново, или --workflow-sha <trusted-main-sha>, чтобы выбрать более старый коммит рабочего процесса, всё ещё доступный из текущего origin/main. Сам рабочий процесс никогда не создаёт и не обновляет ссылки репозитория. Когда Code SHA успешно пройдёт проверки, создайте и зафиксируйте коммитом только CHANGELOG.md. Этот новый коммит станет Release SHA. Запустите ту же вспомогательную команду для Release SHA. Продуктовые свидетельства повторно используются только тогда, когда GitHub подтверждает, что Release SHA является потомком Code SHA, а полный набор изменённых путей в точности равен CHANGELOG.md; предварительная проверка npm и приёмочные проверки пакета и установки всё равно выполняются для Release SHA. release_profile=stable и release_profile=full всегда запускают исчерпывающую длительную проверку в реальной среде и Docker. Передайте run_release_soak=true, чтобы включить те же этапы длительной проверки с профилем beta. Стабильная публикация отклоняет манифест проверки, в котором отсутствуют эта длительная проверка и блокирующие свидетельства производительности продукта. Package Acceptance обычно собирает кандидатный tarball из разрешённого ref, включая запуски для полного SHA, инициированные с pnpm ci:full-release. После публикации бета-версии передайте release_package_spec=openclaw@YYYY.M.PATCH-beta.N, чтобы повторно использовать опубликованный пакет npm в проверках выпуска, Package Acceptance, кроссплатформенных проверках, Docker-проверках пути выпуска и пакетной проверке Telegram. Используйте package_acceptance_package_spec только тогда, когда Package Acceptance должна намеренно проверить другой пакет. Этап проверки пакета плагина Codex в реальной среде следует той же модели: опубликованные значения release_package_spec определяют codex_plugin_spec=npm:@openclaw/codex@<version>; запуски по SHA или артефакту упаковывают extensions/codex из выбранной ссылки; операторы могут напрямую задать codex_plugin_spec для источников плагина npm:, npm-pack: или git:. Этап предоставляет явное разрешение на установку Codex CLI, необходимое этому плагину, затем выполняет предварительную проверку Codex CLI и циклы агента OpenAI в том же сеансе.

Этапы верхнего уровня

Для rerun_group=all сначала выполняется задание Check for reusable validation evidence. Оно ищет последнюю предыдущую успешно завершённую полную проверку с тем же профилем выпуска, фактической настройкой длительной проверки и входными параметрами проверки. Повторные запуски для той же цели используют exact-target-full-validation-v1. Для потомка, полный набор изменений которого в точности равен CHANGELOG.md, используется changelog-only-release-v1; все продуктовые этапы пропускаются, а средство проверки независимо повторно проверяет сравнение коммитов GitHub, неизменяемый родительский артефакт, дочерние запуски и журналы запуска. Любое другое изменение цели требует новой проверки Code SHA. Передайте reuse_evidence=false, чтобы принудительно выполнить новую полную проверку. Повторное использование свидетельств выполняется только из main или канонической ссылки release-ci/*, закреплённой за SHA, чей коммит рабочего процесса остаётся в доверенной линии main; для других ссылок рабочего процесса выбранные этапы запускаются заново. Кроме того, для rerun_group=all задание Verify Docker runtime image assets собирает Docker-цель runtime-assets с помощью OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Оно выполняется параллельно с остальными этапами и контролируется комплексным средством проверки; этапы больше не ожидают его завершения перед запуском. Более узкая группа rerun_group пропускает эту предварительную проверку.

Этап	Подробности
Разрешение цели	Задание: `Resolve target ref` Дочерний рабочий процесс: отсутствует Подтверждает: разрешает ветку выпуска, тег или полный SHA коммита и записывает выбранные входные параметры. Повторный запуск: перезапустите комплексный рабочий процесс, если это задание завершилось с ошибкой.
Предварительная проверка ресурсов Docker	Задание: `Verify Docker runtime image assets` Дочерний рабочий процесс: отсутствует Подтверждает: цель сборки Docker `runtime-assets` по-прежнему успешно собирается до запуска любых других этапов. Выполняется только для `rerun_group=all`. Повторный запуск: перезапустите комплексный рабочий процесс с `rerun_group=all`.
Vitest и обычный CI	Задание: `Run normal full CI` Дочерний рабочий процесс: `CI` Подтверждает: полный граф CI, вручную запущенный для целевой ссылки, включая этапы Linux Node, сегменты встроенных плагинов, сегменты контрактов плагинов и каналов, совместимость с Node 22, `check-`, `check-additional-`, дымовые проверки собранных артефактов, проверки документации, Python Skills, Windows, macOS, интернационализацию Control UI и Android через комплексный рабочий процесс. Повторный запуск: `rerun_group=ci`.
Предвыпускная проверка плагинов	Задание: `Run plugin prerelease validation` Дочерний рабочий процесс: `Plugin Prerelease` Подтверждает: статические проверки плагинов только для выпуска, агентное покрытие плагинов, полные пакетные сегменты плагинов, предвыпускные Docker-этапы плагинов и неблокирующий артефакт `plugin-inspector-advisory` для анализа совместимости. Повторный запуск: `rerun_group=plugin-prerelease`.
Проверки выпуска	Задание: `Run release/live/Docker/QA validation` Дочерний рабочий процесс: `OpenClaw Release Checks` Подтверждает: дымовую проверку установки, кроссплатформенные проверки пакета, Package Acceptance, соответствие QA Lab, проверки Matrix и Telegram в реальной среде. Стабильный и полный профили также запускают исчерпывающие наборы проверок в реальной среде и E2E, а также части Docker-проверки пути выпуска; для бета-профиля их можно включить через `run_release_soak=true`. Повторный запуск: `rerun_group=release-checks` или более узкий обработчик проверок выпуска.
Пакетная проверка Telegram	Задание: `Run package Telegram E2E` Дочерний рабочий процесс: `NPM Telegram Beta E2E` Подтверждает: целевую E2E-проверку Telegram для опубликованного пакета, когда задано `release_package_spec` или `npm_telegram_package_spec`. Полная проверка кандидата вместо этого использует каноническую E2E-проверку Telegram в Package Acceptance. Повторный запуск: `rerun_group=npm-telegram` с `release_package_spec` или `npm_telegram_package_spec`.
Производительность продукта	Задание: `Run product performance evidence` Дочерний рабочий процесс: `OpenClaw Performance` Подтверждает: запуск проверки производительности профиля выпуска (`profile=release`, `repeat=3`, `fail_on_regression=true`, `publish_reports=false`) для целевого SHA. Результаты Kova сохраняются в артефактах рабочего процесса, а дочерний процесс должен подтвердить, что публикация отчёта была пропущена. Обязателен и блокирует выполнение только для `rerun_group=all` или `rerun_group=performance`; не обязателен для более узких групп повторного запуска. Повторный запуск: `rerun_group=performance`.
Комплексное средство проверки	Задание: `Verify full validation` Дочерний рабочий процесс: отсутствует Подтверждает: повторно проверяет записанные результаты дочерних запусков и добавляет таблицы самых медленных заданий из дочерних рабочих процессов. Повторный запуск: после успешного перезапуска сбойного дочернего процесса перезапустите только это задание.

Комплексный рабочий процесс всегда запускает проверку производительности продукта в режиме только артефактов. OpenClaw Performance разрешает публикацию отчёта только для запланированных запусков или ручного запуска, в котором явно задано publish_reports=true. Защитная проверка режима только артефактов должна успешно завершиться, подтвердив, что задание публикации осталось пропущенным. Как новые, так и повторно используемые свидетельства записывают controls.performanceReportPublication=artifact-only; средство проверки и селектор повторного использования отклоняют свидетельства без соответствующего нормализованного подтверждения дочерней проверки производительности. Средство проверки загружает канонический манифест как full-release-validation-<run-id>-<run-attempt>. Инструменты обработки свидетельств проверяют идентификатор артефакта, контрольную сумму, создавший его запуск и попытку, прежде чем загрузить артефакт именно с этим идентификатором. Они ограничивают размер загружаемого ZIP-файла, сверяют его байты с контрольной суммой sha256: из REST и потоково считывают единственную разрешённую ограниченную запись манифеста, не извлекая архив. Псевдоним со стабильным именем временно сохраняется для прежних потребителей публикации. Средство проверки всегда предпочитает артефакт с указанием попытки; на переходный период оно принимает стабильное имя только для манифеста v2, созданного с первой попытки. Для последующих попыток и манифеста v3 это устаревшее имя отклоняется. Для ref=main с rerun_group=all, для ссылок release/* и для альфа-ссылок Tideclaw более новый запуск комплексного рабочего процесса заменяет старый запуск с той же ссылкой и группой повторного запуска. При отмене родительского процесса его монитор отменяет все уже запущенные им дочерние рабочие процессы. Запуски проверок по тегам и закреплённым SHA не отменяют друг друга.

Этапы проверок выпуска

OpenClaw Release Checks — крупнейший дочерний рабочий процесс. Он однократно разрешает целевую ссылку и подготавливает общий артефакт release-package-under-test, когда он необходим этапам, работающим с пакетами или Docker.

Этап	Подробности
Цель выпуска	Задание: `Resolve target ref` Базовый рабочий процесс: отсутствует Тесты: выбранная ссылка, необязательный ожидаемый SHA, профиль, группа повторного запуска и фильтр целевого набора тестов с реальными сервисами. Повторный запуск: `rerun_group=release-checks`.
Артефакт пакета	Задание: `Prepare release package artifact` Базовый рабочий процесс: отсутствует Тесты: упаковывает или определяет один кандидатный tarball и загружает `release-package-under-test` для последующих проверок, связанных с пакетом. Повторный запуск: затронутая группа пакета, кроссплатформенных тестов или тестов с реальными сервисами/E2E.
Дымовой тест установки	Задание: `Run install smoke` Базовый рабочий процесс: `Install Smoke` Тесты: полный путь установки с повторным использованием дымового образа корневого Dockerfile, установкой пакета через QR, дымовыми тестами корневого компонента и Gateway в Docker, тестами установщика в Docker и дымовым тестом поставщика изображений при глобальной установке через Bun. Повторный запуск: `rerun_group=install-smoke`.
Кроссплатформенность	Задание: `cross_os_release_checks` Базовый рабочий процесс: `OpenClaw Cross-OS Release Checks (Reusable)` Тесты: сценарии чистой установки и обновления в Linux, Windows и macOS для выбранного поставщика и режима с использованием кандидатного tarball и базового пакета. Повторный запуск: `rerun_group=cross-os`.
E2E репозитория и реальных сервисов	Задание: `Run repo/live E2E validation` Базовый рабочий процесс: `OpenClaw Live And E2E Checks (Reusable)` Тесты: E2E репозитория, кеш с реальными сервисами, потоковая передача OpenAI через WebSocket, нативные сегменты поставщиков и плагинов с реальными сервисами, а также работающие в Docker стенды моделей, бэкендов и Gateway с реальными сервисами, выбранные с помощью `release_profile`. Запуски: `run_release_soak=true`, `release_profile=full` или целевой `rerun_group=live-e2e`. Повторный запуск: `rerun_group=live-e2e`, необязательно с `live_suite_filter`.
Путь выпуска Docker	Задание: `Run Docker release-path validation` Базовый рабочий процесс: `OpenClaw Live And E2E Checks (Reusable)` Тесты: блоки Docker для пути выпуска, использующие общий артефакт пакета. Запуски: `run_release_soak=true`, `release_profile=full` или целевой `rerun_group=live-e2e`. Повторный запуск: `rerun_group=live-e2e`.
Приёмка пакета	Задание: `Run package acceptance` Базовый рабочий процесс: `Package Acceptance` Тесты: автономные фикстуры пакетов плагинов, обновление плагина, канонический E2E пакета Telegram с имитацией OpenAI и проверки сохранения работоспособности после обновления опубликованной версии на том же tarball. Блокирующие проверки выпуска используют последнюю опубликованную базовую версию по умолчанию; продолжительные проверки (`run_release_soak=true`) расширяют охват до последних 4 стабильных выпусков npm и 3 закреплённых исторических версий (`2026.4.23`, `2026.5.2`, `2026.4.15`) и выполняются с фикстурами обновления для зарегистрированных проблем. Повторный запуск: `rerun_group=package`.
Карта оценки зрелости	Задание: `Render maturity scorecard release docs` Базовый рабочий процесс: `maturity-scorecard.yml` Тесты: формирует документацию рекомендательной карты оценки зрелости для целевой ссылки. Выполняется только при передаче `run_maturity_scorecard=true`. Повторный запуск: `rerun_group=qa` с `run_maturity_scorecard=true`.
Паритет QA	Задание: `Run QA Lab parity lane` и `Run QA Lab parity report` Базовый рабочий процесс: непосредственные задания Тесты: пакеты агентного паритета кандидата и базовой версии, затем отчёт о паритете. Повторный запуск: `rerun_group=qa-parity` или `rerun_group=qa`.
Паритет сред выполнения QA	Задание: `Run QA Lab runtime parity lane` Базовый рабочий процесс: непосредственное задание Тесты: сценарий агентного паритета для пары сред выполнения `openclaw`/`codex` (`pnpm openclaw qa suite --runtime-pair openclaw,codex`), включая стандартный уровень и, с `run_release_soak=true`, уровень продолжительного тестирования. Рекомендательный статус: отдельные сбои не блокируют средство проверки выпуска. Повторный запуск: `rerun_group=qa-parity` или `rerun_group=qa`.
Покрытие инструментов сред выполнения QA	Задание: `Enforce QA Lab runtime tool coverage` Базовый рабочий процесс: непосредственное задание Тесты: динамическое расхождение инструментов между `openclaw` и `codex` на стандартном уровне паритета сред выполнения (`pnpm openclaw qa coverage --tools`) с использованием результата сценария паритета сред выполнения QA. Блокирующий статус: рекомендательное переопределение для этого задания невозможно. Повторный запуск: `rerun_group=qa-parity` или `rerun_group=qa`.
QA Matrix с реальным сервисом	Задание: `Run QA Lab live Matrix lane` Базовый рабочий процесс: непосредственное задание Тесты: быстрый профиль QA Matrix с реальным сервисом в среде `qa-live-shared`. Повторный запуск: `rerun_group=qa-live` или `rerun_group=qa`.
QA Telegram с реальным сервисом	Задание: `Run QA Lab live Telegram lane` Базовый рабочий процесс: непосредственное задание Тесты: QA Telegram с реальным сервисом и арендой учётных данных Convex CI. Повторный запуск: `rerun_group=qa-live` или `rerun_group=qa`.
Средство проверки выпуска	Задание: `Verify release checks` Базовый рабочий процесс: отсутствует Тесты: обязательные задания проверки выпуска для выбранной группы повторного запуска. Повторный запуск: повторить после успешного выполнения целевых дочерних заданий.

Блоки пути выпуска Docker

Этап пути выпуска Docker выполняет следующие блоки, когда live_suite_filter пуст:

Блок	Покрытие
`core`	Основные дымовые сценарии пути выпуска Docker.
`package-update-openai`	Установка и обновление пакета OpenAI, установка Codex по требованию, обращения к плагину Codex с реальным сервисом и вызовы инструментов Chat Completions.
`package-update-anthropic`	Установка и обновление пакета Anthropic.
`package-update-core`	Независимое от поставщика поведение пакета и обновления.
`plugins-runtime-plugins`	Сценарии среды выполнения плагинов, проверяющие поведение плагинов.
`plugins-runtime-services`	Сценарии сред выполнения плагинов с сервисной поддержкой и реальными сервисами.
С `plugins-runtime-install-a` по `plugins-runtime-install-h`	Пакеты установки и выполнения плагинов, разделённые для параллельной проверки выпуска.
`openwebui`	Изолированный дымовой тест совместимости с OpenWebUI на выделенном исполнителе с большим диском, если он запрошен.

Используйте целевой docker_lanes=<lane[,lane]> в повторно используемом рабочем процессе с реальными сервисами/E2E, если завершился сбоем только один сценарий Docker. Артефакты выпуска содержат команды повторного запуска для каждого сценария с параметрами повторного использования артефакта пакета и образа, когда они доступны.

Профили выпуска

release_profile главным образом управляет широтой охвата реальных сервисов и поставщиков в проверках выпуска. Он не исключает обычные полные CI, предварительную проверку выпуска плагина, дымовой тест установки, приёмку пакета или QA Lab. Стабильный и полный профили всегда выполняют исчерпывающие E2E репозитория/реальных сервисов и продолжительные проверки пути выпуска Docker. Бета-профиль может включить их с помощью run_release_soak=true. Приёмка пакета предоставляет канонический E2E пакета Telegram для каждого полного кандидата, поэтому общий рабочий процесс не дублирует этот опрос реального сервиса.

Профиль	Предназначение	Включённое покрытие тестами с реальными сервисами/провайдерами
`beta`	Самая быстрая критически важная для выпуска дымовая проверка.	Основной путь OpenAI с реальными сервисами, модели Docker с реальными сервисами для OpenAI, основная часть нативного Gateway, нативный профиль Gateway для OpenAI, нативный плагин OpenAI и Gateway OpenAI в Docker с реальными сервисами.
`stable`	Профиль по умолчанию для утверждения выпуска.	`beta` плюс дымовая проверка Anthropic, Google, MiniMax, бэкенд, нативная среда тестирования с реальными сервисами, бэкенд CLI в Docker с реальными сервисами, привязка ACP в Docker, среда Codex в Docker, объявление субагентов в Docker и сегмент дымовой проверки OpenCode Go.
`full`	Широкий рекомендательный прогон.	`stable` плюс рекомендательные провайдеры, сегменты плагинов с реальными сервисами и сегменты мультимедиа с реальными сервисами.

Дополнения только для полного профиля

Эти наборы тестов пропускаются в stable и включаются в full:

Область	Покрытие только в полном профиле
Модели Docker с реальными сервисами	OpenCode Go, OpenRouter, xAI, Z.ai и Fireworks.
Gateway в Docker с реальными сервисами	Рекомендательные провайдеры, разделённые на сегменты DeepSeek/Fireworks, OpenCode Go/OpenRouter и xAI/Z.ai.
Профили провайдеров нативного Gateway	Полные сегменты Anthropic Opus и Sonnet/Haiku, Fireworks, DeepSeek, полные сегменты моделей OpenCode Go, OpenRouter, xAI и Z.ai.
Нативные сегменты плагинов с реальными сервисами	Плагины A-K, L-N, прочие O-Z, Moonshot и xAI.
Нативные сегменты мультимедиа с реальными сервисами	Аудио, музыка Google, музыка MiniMax и группы видео A-D.

stable включает native-live-src-gateway-profiles-anthropic-smoke и native-live-src-gateway-profiles-opencode-go-smoke; вместо них full использует более широкие сегменты моделей Anthropic и OpenCode Go. Для выборочных повторных запусков по-прежнему можно использовать агрегированные дескрипторы native-live-src-gateway-profiles-anthropic или native-live-src-gateway-profiles-opencode-go.

Выборочные повторные запуски

Используйте rerun_group, чтобы не запускать повторно несвязанные среды выпуска:

Дескриптор	Область
`all`	Все этапы полной проверки выпуска.
`ci`	Только дочерний процесс полного CI, запускаемый вручную.
`plugin-prerelease`	Только дочерний процесс предварительного выпуска плагинов.
`release-checks`	Все этапы проверок выпуска OpenClaw.
`install-smoke`	От дымовой проверки установки до проверок выпуска.
`cross-os`	Кроссплатформенные проверки выпуска.
`live-e2e`	Сквозные тесты репозитория/реальных сервисов и проверка пути выпуска в Docker.
`package`	Приёмочное тестирование пакета.
`qa`	Проверка эквивалентности QA и каналы QA с реальными сервисами.
`qa-parity`	Только каналы проверки эквивалентности QA и отчёт.
`qa-live`	Matrix/Telegram с реальными сервисами для QA, а также управляемые каналы Discord, WhatsApp и Slack, когда они включены.
`npm-telegram`	Сквозной тест Telegram для опубликованного пакета; требуется `release_package_spec` или `npm_telegram_package_spec`.
`performance`	Только свидетельства производительности продукта.

Используйте live_suite_filter с rerun_group=live-e2e, если произошёл сбой одного набора тестов с реальными сервисами. Допустимые идентификаторы фильтров определены в переиспользуемом рабочем процессе тестов с реальными сервисами/сквозных тестов, включая docker-live-models, live-gateway-docker, live-gateway-anthropic-docker, live-gateway-google-docker, live-gateway-minimax-docker, live-gateway-advisory-docker, live-cli-backend-docker, live-acp-bind-docker и live-codex-harness-docker. Дескриптор live-gateway-advisory-docker — это агрегированный дескриптор повторного запуска для трёх сегментов провайдеров, поэтому он по-прежнему распределяет выполнение по всем рекомендательным заданиям Gateway в Docker. Используйте cross_os_suite_filter с rerun_group=cross-os, если произошёл сбой одного кроссплатформенного канала. Фильтр принимает идентификатор ОС, идентификатор набора тестов или пару ОС/набор тестов, например windows/packaged-upgrade, windows или packaged-fresh. Кроссплатформенные сводки содержат длительность каждого этапа для каналов обновления пакетов, а длительные команды выводят строки Heartbeat, чтобы зависшее обновление было видно до истечения тайм-аута задания. Сбои проверок выпуска QA блокируют обычную проверку выпуска. Проверка покрытия инструментов среды выполнения QA (динамическое расхождение инструментов между openclaw и codex на стандартном уровне) также блокирует средство проверки выпуска, хотя базовый канал проверки эквивалентности среды выполнения QA является рекомендательным. Альфа-запуски Tideclaw всё ещё могут считать рекомендательными каналы проверки выпуска, не связанные с безопасностью пакетов. При release_profile=beta наборы тестов провайдеров с реальными сервисами Run repo/live E2E validation являются рекомендательными: развёртывания моделей сторонних поставщиков меняются независимо от выпуска, поэтому бета-профиль показывает их сбои как предупреждения, а стабильный и полный профили продолжают считать их блокирующими. Когда live_suite_filter явно запрашивает управляемый канал QA с реальными сервисами, например Discord, WhatsApp или Slack, соответствующая переменная репозитория OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED должна быть включена; в противном случае сбор входных данных завершается сбоем, а не молча пропускает канал. Повторно запустите rerun_group=qa, qa-parity или qa-live, когда вам нужны актуальные свидетельства QA.

Сохраняемые свидетельства

Сохраняйте сводку Full Release Validation как индекс уровня выпуска. Она содержит ссылки на идентификаторы дочерних запусков и таблицы самых медленных заданий. При сбоях сначала изучите дочерний рабочий процесс, затем повторно запустите наименьший подходящий дескриптор из перечисленных выше. Зафиксируйте Code SHA и Release SHA, политику повторного использования и набор изменённых путей, родительский запуск с успешным Code SHA и облегчённый родительский запуск с Release SHA. Полезные артефакты:

release-package-under-test из OpenClaw Release Checks
Артефакты пути выпуска Docker в .artifacts/docker-tests/
Приёмочное тестирование пакета package-under-test и артефакты приёмочного тестирования Docker
Артефакты кроссплатформенных проверок выпуска для каждой ОС и набора тестов
Артефакты проверки эквивалентности QA, эквивалентности среды выполнения, Matrix и Telegram

Файлы рабочих процессов

.github/workflows/full-release-validation.yml
.github/workflows/openclaw-release-checks.yml
.github/workflows/openclaw-live-and-e2e-checks-reusable.yml
.github/workflows/plugin-prerelease.yml
.github/workflows/install-smoke.yml
.github/workflows/install-smoke-reusable.yml
.github/workflows/openclaw-cross-os-release-checks-reusable.yml
.github/workflows/package-acceptance.yml
.github/workflows/openclaw-performance.yml
.github/workflows/npm-telegram-beta-e2e.yml

Release notes

Maturity

Release process

Testing and CI

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

Этапы верхнего уровня

Этапы проверок выпуска

Блоки пути выпуска Docker

Профили выпуска

Дополнения только для полного профиля

Выборочные повторные запуски

Сохраняемые свидетельства

Файлы рабочих процессов

​Этапы верхнего уровня

​Этапы проверок выпуска

​Блоки пути выпуска Docker

​Профили выпуска

​Дополнения только для полного профиля

​Выборочные повторные запуски

​Сохраняемые свидетельства

​Файлы рабочих процессов

Этапы верхнего уровня

Этапы проверок выпуска

Блоки пути выпуска Docker

Профили выпуска

Дополнения только для полного профиля

Выборочные повторные запуски

Сохраняемые свидетельства

Файлы рабочих процессов