> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

Зафиксируйте полностью готовый продуктовый коммит перед изменением журнала как **Code SHA**, затем выполните:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
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`