Обзор контроля качества

Приватный стек QA проверяет OpenClaw в реалистичных условиях, воспроизводящих работу каналов, что невозможно обеспечить модульным тестом.

Компоненты:

• extensions/qa-channel: синтетический канал сообщений с личными сообщениями, каналами, ветками, реакциями, редактированием и удалением.
• extensions/qa-lab: интерфейс отладчика и шина QA для просмотра транскрипта, внедрения входящих сообщений и экспорта отчёта Markdown.
• extensions/qa-matrix: адаптер реального транспорта, запускающий настоящий плагин Matrix в дочернем QA gateway.
• qa/: хранящиеся в репозитории исходные ресурсы для начальной задачи и базовых сценариев QA.
• Mantis: проверка до и после для ошибок, которым требуются реальные транспорты, снимки экрана браузера, состояние виртуальной машины и доказательства для PR.

Интерфейс команд

Каждый процесс QA запускается через pnpm openclaw qa <subcommand>. Для многих предусмотрены псевдонимы скриптов pnpm qa:*; работают обе формы.

qa matrix зарегистрирован как плагин средства запуска (extensions/qa-matrix); все остальные указанные выше контуры встроены непосредственно в qa-lab.

qa run на основе профиля

qa run на основе профиля считывает состав из taxonomy.yaml, а затем передаёт разрешённые сценарии через qa suite. --surface и --category фильтруют выбранный профиль вместо определения отдельных контуров. Полученный qa-evidence.json содержит сводку показателей профиля с количеством выбранных категорий и идентификаторами отсутствующего покрытия; отдельные записи доказательств остаются источником истины для тестов, ролей покрытия и результатов. Идентификаторы покрытия функций таксономии являются точными целями доказательства, а не псевдонимами: основное покрытие сценария обеспечивает соответствующие идентификаторы, а вторичное покрытие остаётся рекомендательным. Идентификаторы покрытия используют точечную форму namespace.behavior с сегментами из строчных букв, цифр и дефисов; идентификаторы профилей, поверхностей и категорий могут по-прежнему использовать существующие разделённые дефисами или точками идентификаторы таксономии.

Сокращённые доказательства исключают execution из отдельных записей и задают evidenceMode: "slim"; smoke-ci по умолчанию использует сокращённый формат, а --evidence-mode full восстанавливает полные записи:

pnpm openclaw qa run \  --qa-profile smoke-ci \  --category channel-framework.conversation-routing-and-delivery \  --provider-mode mock-openai \  --output-dir .artifacts/qa-e2e/smoke-ci-profile-dispatch

Используйте smoke-ci для детерминированного доказательства профиля с имитированными поставщиками моделей и локальными серверами поставщиков Crabline. Используйте release для доказательства Stable/LTS с реальными каналами. Используйте all только для явно запрошенных полных прогонов доказательств по таксономии; он выбирает каждую активную категорию зрелости и может запускаться через процесс GitHub Actions QA Profile Evidence с qa_profile=all. Если команде также требуется корневой профиль OpenClaw, укажите корневой профиль перед командой QA:

pnpm openclaw --profile work qa run --qa-profile smoke-ci

Рабочий процесс оператора

Текущий рабочий процесс оператора QA использует сайт QA с двумя панелями:

• Слева: панель Gateway (Control UI) с агентом.
• Справа: QA Lab, отображающая транскрипт в стиле Slack и план сценария.

Запустите его командой:

pnpm qa:lab:up

Она собирает сайт QA, запускает контур gateway на основе Docker и предоставляет страницу QA Lab, где оператор или цикл автоматизации может назначить агенту задачу QA, наблюдать реальное поведение канала и записывать, что сработало, завершилось ошибкой или осталось заблокированным.

Для более быстрой итерации интерфейса QA Lab без повторной сборки Docker-образа при каждом изменении запустите стек с подключённым через bind mount пакетом QA Lab:

pnpm openclaw qa docker-build-imagepnpm qa:lab:buildpnpm qa:lab:up:fastpnpm qa:lab:watch

qa:lab:up:fast оставляет службы Docker на предварительно собранном образе и подключает extensions/qa-lab/web/dist через bind mount к контейнеру qa-lab. qa:lab:watch пересобирает этот пакет при изменениях, а браузер автоматически перезагружается, когда изменяется хеш ресурсов QA Lab.

Базовые проверки наблюдаемости

qa:otel:smoke запускает локальный приёмник OTLP/HTTP, выполняет минимальный проход агента QA-канала, а затем проверяет экспорт трассировок, метрик и журналов. Он декодирует экспортированные интервалы трассировки protobuf и проверяет критически важную для выпуска структуру: должны присутствовать openclaw.run, openclaw.harness.run, интервал вызова модели согласно последней семантической конвенции GenAI, openclaw.context.assembled и openclaw.message.delivery. Smoke-тест принудительно задаёт OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental, поэтому интервал вызова модели должен использовать имя {gen_ai.operation.name} {gen_ai.request.model}; при успешных проходах вызовы модели не должны экспортировать StreamAbandoned; необработанные диагностические идентификаторы и атрибуты openclaw.content.* не должны попадать в трассировку. Запрос сценария просит модель ответить фиксированным маркером и не раскрывать фиксированную секретную строку; необработанные полезные нагрузки OTLP не должны содержать ни то ни другое, а также ключ сеанса QA, полученный из идентификатора сценария. Результат записывается в otel-smoke-summary.json рядом с артефактами набора QA.

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

Линии smoke-тестов Matrix

Чтобы запустить линию smoke-тестов с реальным транспортом Matrix, не требующую учётных данных поставщика моделей, используйте быстрый профиль с детерминированным фиктивным поставщиком OpenAI:

OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000 \  pnpm openclaw qa matrix --provider-mode mock-openai --profile fast --fail-fast

Для линии с поставщиком live-frontier явно укажите совместимые с OpenAI учётные данные:

OPENCLAW_LIVE_OPENAI_KEY="${OPENAI_API_KEY}" \OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000 \  pnpm openclaw qa matrix --provider-mode live-frontier --profile fast --fail-fast

Полный справочник CLI, каталог профилей и сценариев, переменные среды и структура артефактов этой линии приведены в разделе QA Matrix. Вкратце: она развёртывает одноразовый домашний сервер Tuwunel в Docker, регистрирует временных пользователей драйвера/SUT/наблюдателя, запускает реальный плагин Matrix внутри дочернего QA-gateway, ограниченного этим транспортом (без qa-channel), а затем записывает отчёт Markdown, сводку JSON, артефакт наблюдаемых событий и объединённый журнал вывода в каталог .artifacts/qa-e2e/matrix-<timestamp>/.

Сценарии охватывают поведение транспорта, которое модульные тесты не могут подтвердить сквозным образом: фильтрацию по упоминаниям, политики разрешения ботов, списки разрешений, ответы верхнего уровня и в ветках, маршрутизацию личных сообщений, обработку реакций, подавление входящих правок, дедупликацию повторного воспроизведения после перезапуска, восстановление после прерывания работы домашнего сервера, доставку метаданных подтверждения, обработку медиафайлов, а также процессы начальной настройки, восстановления и проверки сквозного шифрования Matrix. Профиль CLI для сквозного шифрования также выполняет openclaw matrix encryption setup и команды проверки через тот же одноразовый домашний сервер, после чего проверяет ответы gateway.

CI использует ту же поверхность команд в .github/workflows/qa-live-transports-convex.yml. Запланированные и стандартные ручные запуски выполняют быстрый профиль Matrix с предоставленными QA учётными данными live-frontier, --fast и OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000. Ручной matrix_profile=all распределяет работу по пяти сегментам профилей: transport, media, e2ee-smoke, e2ee-deep и e2ee-cli.

Сценарии Mantis для Discord

В Discord также есть необязательные сценарии только для Mantis, предназначенные для воспроизведения ошибок. Используйте --scenario discord-status-reactions-tool-only для явной временной шкалы реакций состояния или --scenario discord-thread-reply-filepath-attachment, чтобы создать реальную ветку Discord и проверить, что message.thread-reply сохраняет вложение filePath. Эти сценарии не входят в стандартную рабочую линию Discord, поскольку являются проверками воспроизведения до и после изменения, а не широкими smoke-тестами. Процесс Mantis для вложения в ветке также может добавить видеозапись с подтверждением из Discord Web с выполненным входом, если в среде QA настроен MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR или MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64. Этот профиль просмотра предназначен только для визуальной записи; решение об успешности по-прежнему принимается на основании REST-оракула Discord.

Для линий smoke-тестов с реальным транспортом Discord, Slack, Telegram и WhatsApp:

pnpm openclaw qa discordpnpm openclaw qa slackpnpm openclaw qa telegrampnpm openclaw qa whatsapp

Они используют уже существующий реальный канал с двумя ботами или учётными записями (драйвер + SUT). Обязательные переменные среды, списки сценариев, выходные артефакты и пул учётных данных Convex описаны ниже в справочнике QA для Discord, Slack, Telegram и WhatsApp.

Средства запуска Mantis для рабочего стола Slack и визуальных задач

Чтобы выполнить полный запуск виртуальной машины с рабочим столом Slack и резервным доступом через VNC, выполните:

pnpm openclaw qa mantis slack-desktop-smoke \  --gateway-setup \  --scenario slack-canary \  --keep-lease

Эта команда арендует машину Crabbox с рабочим столом и браузером, запускает рабочую линию Slack внутри виртуальной машины, открывает Slack Web в браузере VNC, записывает рабочий стол и копирует slack-qa/, slack-desktop-smoke.png и slack-desktop-smoke.mp4 (если доступна запись видео) обратно в каталог артефактов Mantis. Арендованные машины Crabbox с рабочим столом и браузером заранее предоставляют средства записи и вспомогательные пакеты браузера/нативной сборки, поэтому сценарий должен устанавливать резервные компоненты только на более старых арендованных машинах. Mantis сообщает об общем времени и времени каждого этапа в mantis-slack-desktop-smoke-report.md, чтобы для медленных запусков было видно, куда ушло время: на прогрев аренды, получение учётных данных, удалённую настройку или копирование артефактов. Повторно используйте --lease-id <cbx_...> после ручного входа в Slack Web через VNC; повторно используемые арендованные машины также сохраняют прогретым кэш хранилища pnpm Crabbox. Стандартный --hydrate-mode source выполняет проверку из рабочей копии исходного кода и запускает установку/сборку внутри виртуальной машины. Используйте --hydrate-mode prehydrated только в том случае, если в повторно используемом удалённом рабочем пространстве уже есть node_modules и собранный dist/; этот режим пропускает затратный этап установки/сборки и аварийно завершает работу, если рабочее пространство не готово. При использовании --gateway-setup Mantis оставляет постоянный Gateway OpenClaw Slack запущенным внутри виртуальной машины на порту 38973; без этого параметра команда выполняет обычную линию QA Slack между ботами и завершается после записи артефактов.

Чтобы подтвердить нативный интерфейс подтверждения Slack с материалами рабочего стола, запустите режим контрольных точек подтверждения Mantis:

pnpm openclaw qa mantis slack-desktop-smoke \  --approval-checkpoints \  --credential-source convex \  --credential-role maintainer

Этот режим несовместим с --gateway-setup. Он запускает сценарии подтверждения Slack, отклоняет идентификаторы сценариев, не относящихся к подтверждению, ожидает в каждом состоянии ожидающего и завершённого подтверждения, отображает наблюдаемое сообщение Slack API в approval-checkpoints/<scenario>-pending.png и approval-checkpoints/<scenario>-resolved.png, а затем завершает работу с ошибкой, если какая-либо контрольная точка, свидетельство сообщения, подтверждение получения или сформированный снимок экрана отсутствуют либо пусты. На холодных арендованных машинах CI в slack-desktop-smoke.png всё ещё может отображаться вход в Slack; изображения контрольных точек подтверждения являются визуальным доказательством для этой линии.

Стандартный запуск контрольных точек сохраняет два стандартных сценария подтверждения Slack. Чтобы записать любой из необязательных маршрутов подтверждения Codex, явно выберите его с помощью --scenario slack-codex-approval-exec-native или --scenario slack-codex-approval-plugin-native; Mantis принимает оба и создаёт одну и ту же пару снимков экрана для ожидающего и завершённого состояний. Средство запуска увеличивает предельные сроки контрольных точек и удалённых команд для каждого выбранного маршрута Codex, чтобы могла завершиться вся последовательность подтверждения, завершения работы агента и обновления завершённого состояния.

Контрольный список оператора, команда запуска рабочего процесса GitHub, контракт комментария со свидетельствами, таблица выбора режима гидратации, интерпретация времени и действия при сбоях приведены в руководстве по запуску Mantis Slack Desktop.

Для задачи рабочего стола в стиле агента/компьютерного зрения выполните:

pnpm openclaw qa mantis visual-task \  --browser-url https://example.net \  --expect-text "Example Domain" \  --vision-model openai/gpt-5.6-luna

visual-task арендует или повторно использует машину Crabbox с рабочим столом и браузером, запускает crabbox record --while, управляет видимым браузером через вложенный visual-driver, создаёт visual-task.png, запускает openclaw infer image describe для снимка экрана, когда выбран --vision-mode image-describe, и записывает visual-task.mp4, mantis-visual-task-summary.json, mantis-visual-task-driver-result.json и mantis-visual-task-report.md. Когда задан --expect-text, запрос к модели компьютерного зрения требует структурированный вердикт JSON (visible, evidence, reason) и считается успешным, только когда модель сообщает visible: true со свидетельством, ссылающимся на ожидаемый текст; ответ visible: false, который лишь цитирует целевой текст, всё равно не проходит проверку. Используйте --vision-mode metadata для smoke-теста без модели, который проверяет работу рабочего стола, браузера, снимка экрана и видеозаписи без обращения к поставщику распознавания изображений. Запись является обязательным артефактом для visual-task; если Crabbox не создаёт непустой visual-task.mp4, задача завершается с ошибкой, даже если визуальный драйвер отработал успешно. При сбое Mantis сохраняет аренду для доступа по VNC, если только задача уже не была выполнена успешно и не был задан --keep-lease.

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

Перед использованием общих рабочих учётных данных выполните:

pnpm openclaw qa credentials doctor

Doctor проверяет переменные среды брокера Convex (OPENCLAW_QA_CONVEX_SITE_URL, OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX), проверяет настройки конечных точек, сообщает только состояние «задано/отсутствует» для OPENCLAW_QA_CONVEX_SECRET_CI и OPENCLAW_QA_CONVEX_SECRET_MAINTAINER, а также проверяет доступность административного интерфейса и списка при наличии секрета сопровождающего.

Покрытие реального транспорта

Линии реального транспорта используют единый контракт вместо того, чтобы каждая из них определяла собственную структуру списка сценариев. qa-channel — это широкий набор синтетических проверок поведения продукта, который не входит в матрицу покрытия реального транспорта.

Средства запуска реального транспорта импортируют общие идентификаторы сценариев, вспомогательные функции базового покрытия и вспомогательную функцию выбора сценариев из openclaw/plugin-sdk/qa-live-transport-scenarios.

Это сохраняет qa-channel как широкий набор тестов поведения продукта, а Matrix, Telegram и другие рабочие транспорты используют единый явный контрольный список контрактов транспорта.

Чтобы запустить одноразовый канал на виртуальной машине Linux без включения Docker в процесс QA, выполните:

pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline

Эта команда запускает новый гостевой экземпляр Multipass, устанавливает зависимости, собирает OpenClaw в гостевой системе, запускает qa suite, а затем копирует обычный отчёт QA и сводку обратно в .artifacts/qa-e2e/... на хосте. Используется то же поведение выбора сценариев, что и у qa suite на хосте.

Запуски набора на хосте и в Multipass по умолчанию выполняют несколько выбранных сценариев параллельно с изолированными рабочими процессами Gateway. Для qa-channel по умолчанию параллелизм равен 4 и ограничен числом выбранных сценариев. Используйте --concurrency <count>, чтобы настроить число рабочих процессов, или --concurrency 1 для последовательного выполнения. Используйте --pack personal-agent, чтобы запустить пакет эталонных тестов персонального ассистента (10 сценариев). Селектор пакета дополняет повторяющиеся флаги --scenario: сначала выполняются явно указанные сценарии, затем сценарии пакета в порядке пакета, при этом дубликаты удаляются. Используйте --pack observability, чтобы одновременно выбрать сценарии otel-trace-smoke и docker-prometheus-smoke, если пользовательский исполнитель QA уже предоставляет настройку коллектора OpenTelemetry.

Команда завершается с ненулевым кодом, если какой-либо сценарий завершается сбоем. Используйте --allow-failures, если вам нужны артефакты без ненулевого кода завершения.

При рабочих запусках в гостевую систему передаются поддерживаемые входные данные аутентификации QA, для которых это практически осуществимо: ключи провайдера из переменных окружения, путь к конфигурации рабочего провайдера QA и CODEX_HOME, если он задан. Храните --output-dir в корне репозитория, чтобы гостевая система могла записывать результаты обратно через смонтированную рабочую область.

Справочник по QA для Discord, Slack, Telegram и WhatsApp

Для Matrix предусмотрена отдельная страница из-за количества сценариев и подготовки домашнего сервера на базе Docker. Discord, Slack, Telegram и WhatsApp работают с уже существующими реальными транспортами, поэтому справочная информация о них находится здесь.

Общие флаги CLI

Эти каналы регистрируются через extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts и принимают одинаковые флаги:

Каждый канал завершается с ненулевым кодом при сбое любого сценария. --allow-failures записывает артефакты, не устанавливая ненулевой код завершения. Telegram также принимает --list-scenarios, чтобы вывести доступные идентификаторы сценариев и завершить работу; другие каналы не предоставляют этот флаг.

QA для Telegram

pnpm openclaw qa telegram

Целевым объектом служит одна реальная закрытая группа Telegram с двумя разными ботами (драйвером и тестируемой системой). У бота тестируемой системы должно быть имя пользователя Telegram; наблюдение за взаимодействием ботов лучше всего работает, когда у обоих ботов включён режим Bot-to-Bot Communication Mode в @BotFather.

Обязательные переменные окружения при --credential-source env:

• OPENCLAW_QA_TELEGRAM_GROUP_ID — числовой идентификатор чата (строка).
• OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN
• OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN

Сценарии (extensions/qa-lab/src/live-transports/telegram/telegram-live.runtime.ts):

• telegram-canary
• telegram-mention-gating
• telegram-mentioned-message-reply
• telegram-help-command
• telegram-commands-command
• telegram-tools-compact-command
• telegram-whoami-command
• telegram-status-command
• telegram-repeated-command-authorization
• telegram-other-bot-command-gating
• telegram-context-command
• telegram-current-session-status-tool
• telegram-tool-only-usage-footer
• telegram-reply-chain-exact-marker
• telegram-stream-final-single-message
• telegram-long-final-reuses-preview
• telegram-long-final-three-chunks

Неявный набор по умолчанию всегда охватывает канарейку, фильтрацию по упоминанию, ответы нативных команд, адресацию команд и групповые ответы между ботами. Значения mock-openai по умолчанию также включают детерминированные проверки цепочки ответов и потоковой передачи итогового сообщения. telegram-current-session-status-tool и telegram-tool-only-usage-footer остаются необязательными: первый стабилен только при запуске непосредственно после канарейки, а второй представляет собой проверку в реальном Telegram нижнего колонтитула /usage в ответах, содержащих только инструменты. Используйте pnpm openclaw qa telegram --list-scenarios --provider-mode mock-openai, чтобы вывести текущее разделение на сценарии по умолчанию и необязательные сценарии со ссылками на регрессии.

Выходные артефакты:

• telegram-qa-report.md
• qa-evidence.json — записи доказательств для проверок рабочего транспорта, включая поля профиля, покрытия, провайдера, канала, артефактов, результата и RTT.

Запуски Telegram из пакета используют тот же контракт учётных данных Telegram. Повторное измерение RTT входит в обычный рабочий канал Telegram для пакета; распределение RTT включается в qa-evidence.json в разделе result.timing для выбранной проверки RTT.

OPENCLAW_QA_CREDENTIAL_SOURCE=convex \pnpm test:docker:npm-telegram-live

Если задан OPENCLAW_QA_CREDENTIAL_SOURCE=convex, обёртка рабочего запуска пакета арендует учётные данные kind: "telegram", экспортирует переменные окружения арендованной группы, драйвера и бота тестируемой системы в запуск установленного пакета, поддерживает аренду с помощью Heartbeat и освобождает её при завершении работы. Обёртка пакета по умолчанию выполняет 20 проверок RTT для telegram-mentioned-message-reply, использует тайм-аут RTT 30s и роль Convex maintainer вне CI, если выбран Convex. Переопределите OPENCLAW_NPM_TELEGRAM_RTT_SAMPLES, OPENCLAW_NPM_TELEGRAM_RTT_TIMEOUT_MS или OPENCLAW_NPM_TELEGRAM_RTT_MAX_FAILURES, чтобы настроить измерение RTT без создания отдельной команды RTT или специального для Telegram формата сводки.

QA для Discord

pnpm openclaw qa discord

Целевым объектом служит один реальный канал закрытого сервера Discord с двумя ботами: ботом-драйвером, которым управляет тестовая система, и ботом тестируемой системы, запускаемым дочерним процессом Gateway OpenClaw через встроенный плагин Discord. Проверяется обработка упоминаний в канале, регистрация ботом тестируемой системы нативной команды /help в Discord и необязательные сценарии сбора доказательств Mantis.

Обязательные переменные окружения при --credential-source env:

• OPENCLAW_QA_DISCORD_GUILD_ID
• OPENCLAW_QA_DISCORD_CHANNEL_ID
• OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN
• OPENCLAW_QA_DISCORD_SUT_BOT_TOKEN
• OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID — должен совпадать с идентификатором пользователя бота тестируемой системы, возвращённым Discord (в противном случае канал немедленно завершается сбоем).

Необязательно:

• OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1 сохраняет тела сообщений в артефактах наблюдаемых сообщений.
• OPENCLAW_QA_DISCORD_VOICE_CHANNEL_ID выбирает голосовой/сценический канал для discord-voice-autojoin; без него сценарий выбирает первый видимый боту тестируемой системы голосовой/сценический канал.

Сценарии (extensions/qa-lab/src/live-transports/discord/discord-live.runtime.ts:36):

• discord-canary
• discord-mention-gating
• discord-native-help-command-registration
• discord-voice-autojoin — необязательный голосовой сценарий. Выполняется отдельно, включает channels.discord.voice.autoJoin и проверяет, что текущее голосовое состояние бота тестируемой системы в Discord соответствует целевому голосовому/сценическому каналу. Учётные данные Discord в Convex могут включать необязательный voiceChannelId; в противном случае исполнитель обнаруживает первый видимый голосовой/сценический канал на сервере.
• discord-status-reactions-tool-only — необязательный сценарий Mantis. Выполняется отдельно, поскольку переводит тестируемую систему в режим постоянных ответов на сервере, содержащих только инструменты, с messages.statusReactions.enabled=true, а затем сохраняет временную шкалу реакций REST и визуальные артефакты HTML/PNG. Отчёты Mantis «до» и «после» также сохраняют предоставленные сценарием артефакты MP4 как baseline.mp4 и candidate.mp4.
• discord-thread-reply-filepath-attachment — необязательный сценарий Mantis; см. сценарии Mantis для Discord.

Явный запуск сценария автоматического подключения к голосовому каналу Discord:

pnpm openclaw qa discord \  --scenario discord-voice-autojoin \  --provider-mode mock-openai

Явный запуск сценария реакций на состояние Mantis:

pnpm openclaw qa discord \  --scenario discord-status-reactions-tool-only \  --provider-mode live-frontier \  --model openai/gpt-5.6-luna \  --alt-model openai/gpt-5.6-luna \  --fast

Выходные артефакты:

• discord-qa-report.md
• qa-evidence.json — записи с доказательствами для проверок транспорта в реальной среде.
• discord-qa-observed-messages.json — содержимое скрыто, если не задано OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1.
• discord-qa-reaction-timelines.json и discord-status-reactions-tool-only-timeline.png, когда выполняется сценарий реакции на статус.

Контроль качества Slack

pnpm openclaw qa slack

Использует один реальный приватный канал Slack с двумя разными ботами: ботом-драйвером, которым управляет тестовая среда, и ботом тестируемой системы, запускаемым дочерним Gateway OpenClaw через встроенный плагин Slack.

Обязательные переменные окружения при --credential-source env:

• OPENCLAW_QA_SLACK_CHANNEL_ID
• OPENCLAW_QA_SLACK_DRIVER_BOT_TOKEN
• OPENCLAW_QA_SLACK_SUT_BOT_TOKEN
• OPENCLAW_QA_SLACK_SUT_APP_TOKEN

Необязательно:

• OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1 сохраняет содержимое сообщений в артефактах наблюдаемых сообщений.
• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR включает контрольные точки визуального подтверждения для Mantis. Средство запуска записывает <scenario>.pending.json и <scenario>.resolved.json, а затем ожидает соответствующие файлы .ack.json.
• OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_TIMEOUT_MS переопределяет время ожидания подтверждения контрольной точки. Значение по умолчанию — 120000.

Канонические сценарии YAML, доступные через адаптер Slack для реальной среды:

• thread-follow-up
• thread-isolation

Императивные сценарии Slack (extensions/qa-lab/src/live-transports/slack/slack-live.runtime.ts):

• slack-canary
• slack-mention-gating
• slack-allowlist-block
• slack-channel-disabled-warning — включаемая явно проверка в реальном Slack, подтверждающая, что настроенный отключённый канал выдаёт структурированное предупреждение без ответа.
• slack-top-level-reply-shape
• slack-restart-resume
• slack-progress-commentary-true, slack-progress-commentary-false, slack-progress-commentary-omitted и slack-progress-commentary-verbose-dedupe — включаемые явно проверки в реальном Slack для независимого управления комментариями и ходом выполнения инструментов, устаревшего поведения по умолчанию при отсутствии ключа и однократной доставки при включённом сохранении подробного хода выполнения.
• slack-reaction-glyph-native — включаемый явно сценарий реакции через инструмент сообщений в реальной среде. Агенту предписывается передать точный символ ✅, после чего подтверждается, что Slack сохранил white_check_mark для бота тестируемой системы в целевом сообщении.
• slack-chart-presentation-native — включаемый явно сценарий переносимой диаграммы, который проверяет нативный блок data_visualization и точный доступный текст.
• slack-table-presentation-native — включаемый явно сценарий переносимой таблицы, который проверяет нативный блок data_table, точные строки и доступный текст.
• slack-table-invalid-blocks-fallback — включаемый явно сценарий прямого транспорта, который отправляет структурно читаемую необработанную таблицу сверх допустимого размера со 101 строкой данных и заголовком через рабочий путь отправки Slack, подтверждает, что сам Slack возвращает invalid_blocks, и проверяет, что сохранённый резервный вариант с отключённым форматированием является полным и не содержит нативного блока данных. В отчёте сохраняются только безопасные доказательства в виде кода ошибки, количества и логических значений; необработанный текст синтетической таблицы следует настройке OPENCLAW_QA_SLACK_CAPTURE_CONTENT.
• slack-approval-exec-native — включаемый явно сценарий нативного подтверждения выполнения команд в Slack. Запрашивает подтверждение выполнения команды через Gateway, проверяет наличие в сообщении Slack нативных кнопок подтверждения, обрабатывает запрос и проверяет обновлённое сообщение Slack после обработки.
• slack-approval-plugin-native — включаемый явно сценарий нативного подтверждения плагина Slack. Одновременно включает пересылку подтверждений выполнения команд и плагина, чтобы события плагина не подавлялись маршрутизацией подтверждений выполнения команд, а затем проверяет тот же нативный путь интерфейса Slack для ожидающего и обработанного состояний.
• slack-codex-approval-exec-native — включаемый явно сценарий подтверждения команды Codex Guardian. Включает плагин Codex в режиме Guardian, направляет инициированный из Slack запуск агента Gateway через тестовую среду сервера приложений Codex, ожидает нативный запрос подтверждения плагина Slack для openclaw-codex-app-server, обрабатывает его и проверяет, что запуск Codex завершается с ожидаемыми маркерами вывода команды и ассистента.
• slack-codex-approval-plugin-native — включаемый явно сценарий подтверждения файла Codex Guardian. Использует инструкцию apply_patch вне рабочего пространства, чтобы Codex задействовал маршрут подтверждения изменения файла через сервер приложений, а затем проверяет тот же нативный путь подтверждения Slack для ожидающего и обработанного состояний, итоговый маркер ассистента и точное содержимое файла перед очисткой.

Для сценариев подтверждения Codex требуется openai/* или codex/* --model, обычные учётные данные реальной модели, а также аутентификация Codex или аутентификация по ключу API, поддерживаемая плагином Codex. Отчёт Slack содержит метод сервера приложений Codex, ключ выбранной модели Codex, итоговое состояние запуска Codex и результат проверки маркера операции вместе со скрытыми метаданными подтверждения Slack.

Выходные артефакты:

• slack-qa-report.md
• qa-evidence.json — записи с доказательствами для проверок транспорта в реальной среде.
• slack-qa-observed-messages.json — содержимое скрыто, если не задано OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1.
• approval-checkpoints/ — только когда Mantis задаёт OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR; содержит JSON контрольной точки, JSON подтверждения и снимки экрана ожидающего и обработанного состояний.

Настройка рабочего пространства Slack

Для этого режима требуются два разных приложения Slack в одном рабочем пространстве, а также канал, участниками которого являются оба бота:

• channelId — идентификатор Cxxxxxxxxxx канала, в который приглашены оба бота. Используйте выделенный канал: при каждом запуске режим публикует в нём сообщения.
• driverBotToken — токен бота (xoxb-...) приложения Driver.
• sutBotToken — токен бота (xoxb-...) приложения SUT, которое должно быть отдельным приложением Slack, отличным от драйвера, чтобы идентификатор его пользователя-бота был уникальным.
• sutAppToken — токен уровня приложения (xapp-...) приложения SUT с областью connections:write, используемый режимом Socket Mode, чтобы приложение SUT могло получать события.

Предпочтительно использовать рабочее пространство Slack, выделенное для контроля качества, а не рабочее пространство продуктивной среды.

Приведённый ниже манифест SUT намеренно ограничивает рабочую конфигурацию встроенного плагина Slack (extensions/slack/src/setup-shared.ts:12) разрешениями и событиями, охватываемыми набором проверок Slack в реальной среде. Настройку рабочего канала в том виде, в котором её выполняют пользователи, см. в разделе Быстрая настройка канала Slack; пара Driver/SUT для контроля качества намеренно разделена, поскольку этому режиму нужны два разных идентификатора пользователей-ботов в одном рабочем пространстве.

1. Создайте приложение Driver

Перейдите на api.slack.com/apps → Create New App → From a manifest → выберите рабочее пространство контроля качества, вставьте следующий манифест, затем нажмите Install to Workspace:

{  "display_information": {    "name": "OpenClaw QA Driver",    "description": "Бот-драйвер тестирования для режима проверок Slack OpenClaw в реальной среде"  },  "features": {    "bot_user": {      "display_name": "OpenClaw QA Driver",      "always_online": true    }  },  "oauth_config": {    "scopes": {      "bot": ["chat:write", "channels:history", "groups:history", "users:read"]    }  },  "settings": {    "socket_mode_enabled": false  }}

Скопируйте Bot User OAuth Token (xoxb-...) — он станет driverBotToken. Драйверу нужно только публиковать сообщения и идентифицировать себя; события и Socket Mode ему не нужны.

2. Создайте приложение SUT

Повторите действия Create New App → From a manifest в том же рабочем пространстве. Это приложение контроля качества намеренно использует сокращённую версию рабочего манифеста встроенного плагина Slack (extensions/slack/src/setup-shared.ts:12): области и события реакций исключены, поскольку набор проверок Slack в реальной среде пока не охватывает обработку реакций.

{  "display_information": {    "name": "OpenClaw QA SUT",    "description": "Коннектор тестируемой системы OpenClaw для OpenClaw"  },  "features": {    "bot_user": {      "display_name": "OpenClaw QA SUT",      "always_online": true    },    "app_home": {      "home_tab_enabled": true,      "messages_tab_enabled": true,      "messages_tab_read_only_enabled": false    }  },  "oauth_config": {    "scopes": {      "bot": [        "app_mentions:read",        "assistant:write",        "channels:history",        "channels:read",        "chat:write",        "commands",        "emoji:read",        "files:read",        "files:write",        "groups:history",        "groups:read",        "im:history",        "im:read",        "im:write",        "mpim:history",        "mpim:read",        "mpim:write",        "pins:read",        "pins:write",        "usergroups:read",        "users:read"      ]    }  },  "settings": {    "socket_mode_enabled": true,    "event_subscriptions": {      "bot_events": [        "app_home_opened",        "app_mention",        "channel_rename",        "member_joined_channel",        "member_left_channel",        "message.channels",        "message.groups",        "message.im",        "message.mpim",        "pin_added",        "pin_removed"      ]    }  }}

После создания приложения в Slack выполните два действия на странице его настроек:

• Install to Workspace → скопируйте Bot User OAuth Token → он станет sutBotToken.
• Basic Information → App-Level Tokens → Generate Token and Scopes → добавьте область connections:write → сохраните → скопируйте значение xapp-... → оно станет sutAppToken.

Убедитесь, что у двух ботов разные идентификаторы пользователей, вызвав auth.test с каждым токеном. Среда выполнения различает драйвер и SUT по идентификатору пользователя; повторное использование одного приложения для обеих ролей немедленно приведёт к сбою проверки упоминаний.

3. Создайте канал

В рабочем пространстве контроля качества создайте канал (например, #openclaw-qa) и пригласите обоих ботов из самого канала:

/invite @OpenClaw QA Driver/invite @OpenClaw QA SUT

Скопируйте идентификатор Cxxxxxxxxxx из channel info → About → Channel ID — он станет channelId. Подойдёт публичный канал; если используется приватный канал, оба приложения уже имеют groups:history, поэтому чтение истории тестовой средой также будет успешным.

4. Зарегистрируйте учётные данные

Доступны два варианта. Для отладки на одном компьютере используйте переменные окружения (задайте четыре переменные OPENCLAW_QA_SLACK_* и передайте --credential-source env) либо заполните общий пул Convex, чтобы CI и другие сопровождающие могли арендовать эти данные.

Для пула Convex запишите четыре поля в файл JSON:

{  "channelId": "Cxxxxxxxxxx",  "driverBotToken": "xoxb-...",  "sutBotToken": "xoxb-...",  "sutAppToken": "xapp-..."}

Экспортировав OPENCLAW_QA_CONVEX_SITE_URL и OPENCLAW_QA_CONVEX_SECRET_MAINTAINER в оболочке, зарегистрируйте и проверьте данные:

pnpm openclaw qa credentials add \  --kind slack \  --payload-file slack-creds.json \  --note "Начальное заполнение пула Slack для контроля качества" pnpm openclaw qa credentials list --kind slack --status all --json

Ожидаются count: 1, status: "active" и отсутствие поля lease.

5. Выполните сквозную проверку

Запустите режим локально, чтобы убедиться, что оба бота могут взаимодействовать друг с другом через брокер:

pnpm openclaw qa slack \  --credential-source convex \  --credential-role maintainer \  --output-dir .artifacts/qa-e2e/slack-local

Успешный запуск завершается значительно быстрее чем за 30 секунд, а slack-qa-report.md показывает статус pass для slack-canary и slack-mention-gating. Если режим зависает примерно на 90 секунд и завершается с Convex credential pool exhausted for kind "slack", значит пул пуст или все записи арендованы — qa credentials list --kind slack --status all --json укажет причину.

Контроль качества WhatsApp

pnpm openclaw qa whatsapp

Использует две выделенные учётные записи WhatsApp Web: учётную запись драйвера, которой управляет тестовая среда, и учётную запись тестируемой системы, запускаемую дочерним Gateway OpenClaw через встроенный плагин WhatsApp.

Обязательные переменные окружения при --credential-source env:

• OPENCLAW_QA_WHATSAPP_DRIVER_PHONE_E164
• OPENCLAW_QA_WHATSAPP_SUT_PHONE_E164
• OPENCLAW_QA_WHATSAPP_DRIVER_AUTH_ARCHIVE_BASE64
• OPENCLAW_QA_WHATSAPP_SUT_AUTH_ARCHIVE_BASE64

Необязательно:

• OPENCLAW_QA_WHATSAPP_GROUP_JID включает групповые сценарии, такие как whatsapp-mention-gating, whatsapp-group-pending-history-context, whatsapp-broadcast-group-fanout, whatsapp-group-activation-always, whatsapp-group-reply-to-bot-triggers, групповые сценарии действий, мультимедиа и опросов, а также whatsapp-group-allowlist-block.
• OPENCLAW_QA_WHATSAPP_CAPTURE_CONTENT=1 сохраняет содержимое сообщений в артефактах наблюдаемых сообщений.

Каталог сценариев (extensions/qa-lab/src/live-transports/whatsapp/whatsapp-live.runtime.ts):

• Базовые проверки и ограничения для групп: whatsapp-canary, whatsapp-pairing-block, whatsapp-mention-gating, whatsapp-group-pending-history-context, whatsapp-group-activation-always, whatsapp-group-reply-to-bot-triggers, whatsapp-top-level-reply-shape, whatsapp-restart-resume, whatsapp-group-allowlist-block.
• Нативные команды: whatsapp-help-command, whatsapp-status-command, whatsapp-commands-command, whatsapp-tools-compact-command, whatsapp-whoami-command, whatsapp-context-command, whatsapp-native-new-command.
• Поведение ответов и итогового вывода: whatsapp-tool-only-usage-footer, whatsapp-reply-to-message, whatsapp-group-reply-to-message, whatsapp-reply-to-mode-batched, whatsapp-reply-context-isolation, whatsapp-reply-delivery-shape, whatsapp-stream-final-message-accounting.
• Действия с сообщениями в пользовательском сценарии: whatsapp-agent-message-action-react начинается с реального личного сообщения от драйвера, позволяет модели вызвать инструмент message и отслеживает нативную реакцию WhatsApp. whatsapp-agent-message-action-upload-file использует тот же подход для message(action=upload-file) и отслеживает нативный медиафайл WhatsApp. whatsapp-group-agent-message-action-react и whatsapp-group-agent-message-action-upload-file подтверждают те же видимые пользователю действия в реальной группе WhatsApp.
• Рассылка в группе: whatsapp-broadcast-group-fanout начинается с одного сообщения с упоминанием в группе WhatsApp и проверяет отдельные видимые ответы от main и qa-second.
• Активация в группе: whatsapp-group-activation-always переводит реальный групповой сеанс в состояние /activation always, подтверждает, что сообщение без упоминания в группе пробуждает агента, а затем восстанавливает /activation mention. whatsapp-group-reply-to-bot-triggers создаёт начальный ответ бота, отправляет на него нативный ответ с цитированием без явного упоминания и проверяет, что агент пробуждается благодаря контексту этого ответа.
• Входящие медиафайлы и структурированные сообщения: whatsapp-inbound-image-caption, whatsapp-audio-preflight, whatsapp-inbound-structured-messages, whatsapp-group-audio-gating, whatsapp-inbound-reaction-no-trigger. Они отправляют через драйвер реальные события WhatsApp с изображениями, аудио, документами, геопозициями, контактами, стикерами и реакциями.
• Прямые проверки контракта Gateway: whatsapp-outbound-media-matrix, whatsapp-outbound-document-preserves-filename, whatsapp-outbound-poll, whatsapp-outbound-send-serialization, whatsapp-group-outbound-media, whatsapp-group-outbound-poll, whatsapp-message-actions, whatsapp-reply-context-isolation, whatsapp-reply-delivery-shape. Они намеренно обходят формирование запросов к модели и подтверждают детерминированные контракты Gateway/канала для send, poll и message.action.
• Покрытие контроля доступа: whatsapp-access-control-dm-open, whatsapp-access-control-dm-disabled, whatsapp-access-control-group-open, whatsapp-access-control-group-disabled, whatsapp-group-allowlist-block.
• Нативные подтверждения: whatsapp-approval-exec-deny-native, whatsapp-approval-exec-native, whatsapp-approval-exec-reaction-native, whatsapp-approval-exec-group-reaction-native, whatsapp-approval-plugin-native.
• Реакции состояния: whatsapp-status-reactions, whatsapp-status-reaction-lifecycle.

Сейчас каталог содержит 52 сценария. Стандартный набор live-frontier ограничен 10 сценариями для быстрой дымовой проверки. Стандартный набор mock-openai детерминированно выполняет 45 сценариев через реальный транспорт WhatsApp, имитируя только вывод модели; сценарии подтверждения и несколько более ресурсоёмких или блокирующих проверок по-прежнему запускаются явно по идентификатору сценария.

Драйвер контроля качества WhatsApp отслеживает структурированные события в реальном времени (text, media, location, reaction и poll) и может активно отправлять медиафайлы, опросы, контакты, геопозиции и стикеры. QA Lab импортирует этот драйвер через поверхность пакета @openclaw/whatsapp/api.js, не обращаясь напрямую к закрытым файлам среды выполнения WhatsApp. При отслеживании групп fromJid обозначает JID группы, а participantJid и fromPhoneE164 идентифицируют отправителя-участника. Содержимое сообщений по умолчанию скрывается. Прямые проверки опросов Gateway, загрузки файлов, медиафайлов, групповых опросов, групповых медиафайлов и формы ответов проверяют контракты транспорта/API; они не считаются подтверждением того, что пользовательский запрос заставил агента выбрать то же действие. Подтверждение действий в пользовательском сценарии обеспечивают такие сценарии, как whatsapp-agent-message-action-react и whatsapp-group-agent-message-action-react, в которых драйвер отправляет обычное сообщение WhatsApp, а QA Lab отслеживает созданный нативный объект WhatsApp. Отчёты WhatsApp содержат режим каждого сценария (user-path, direct-gateway или native-approval), поэтому свидетельство нельзя ошибочно принять за подтверждение более строгого контракта, чем оно фактически доказывает.

Выходные артефакты:

• whatsapp-qa-report.md
• qa-evidence.json — записи свидетельств для проверок транспорта в реальном времени.
• whatsapp-qa-observed-messages.json — содержимое скрывается, если не задано OPENCLAW_QA_WHATSAPP_CAPTURE_CONTENT=1.

Пул учётных данных Convex

Наборы Discord, Slack, Telegram и WhatsApp могут арендовать учётные данные из общего пула Convex вместо чтения указанных выше переменных окружения. Передайте --credential-source convex (или задайте OPENCLAW_QA_CREDENTIAL_SOURCE=convex); QA Lab получает эксклюзивную аренду, отправляет Heartbeat на всём протяжении запуска и освобождает её при завершении работы. Типы пула: "discord", "slack", "telegram" и "whatsapp".

Формы полезной нагрузки, которые брокер проверяет в admin/add:

• Discord (kind: "discord"): { guildId: string, channelId: string, driverBotToken: string, sutBotToken: string, sutApplicationId: string }.
• Telegram (kind: "telegram"): { groupId: string, driverToken: string, sutToken: string } — groupId должен быть числовой строкой идентификатора чата.
• Реальный пользователь Telegram (kind: "telegram-user"): { groupId: string, sutToken: string, testerUserId: string, testerUsername: string, telegramApiId: string, telegramApiHash: string, tdlibDatabaseEncryptionKey: string, tdlibArchiveBase64: string, tdlibArchiveSha256: string, desktopTdataArchiveBase64: string, desktopTdataArchiveSha256: string } — только для подтверждения Mantis через Telegram Desktop. Обычные наборы QA Lab не должны получать этот тип.
• WhatsApp (kind: "whatsapp"): { driverPhoneE164: string, sutPhoneE164: string, driverAuthArchiveBase64: string, sutAuthArchiveBase64: string, groupJid?: string } — номера телефонов должны быть различными строками в формате E.164.

Процесс подтверждения Mantis через Telegram Desktop удерживает одну эксклюзивную аренду Convex telegram-user одновременно для драйвера CLI TDLib и наблюдателя Telegram Desktop, а затем освобождает её после публикации подтверждения.

Когда для PR требуется детерминированное визуальное сравнение, Mantis может использовать один и тот же имитированный ответ модели на main и на вершине PR, пока изменяется средство форматирования Telegram или уровень доставки. Стандартные параметры захвата настроены для комментариев к PR: стандартный класс Crabbox, запись рабочего стола с частотой 24fps, анимация GIF с движением с частотой 24fps и ширина предпросмотра 1920px. Комментарии с результатами до и после должны публиковать чистый набор, содержащий только требуемые GIF-файлы.

Наборы Slack также могут использовать пул. Сейчас проверки формы полезной нагрузки Slack находятся в средстве запуска QA для Slack, а не в брокере; используйте { channelId: string, driverBotToken: string, sutBotToken: string, sutAppToken: string } с идентификатором канала Slack, например Cxxxxxxxxxx. Сведения о подготовке приложения и разрешений см. в разделе Настройка рабочего пространства Slack.

Рабочие переменные окружения и контракт конечной точки брокера Convex описаны в разделе Тестирование → Общие учётные данные Telegram через Convex (название раздела появилось до создания многоканального пула; семантика аренды одинакова для всех типов).

Начальные данные из репозитория

Начальные ресурсы находятся в qa/:

• qa/scenarios/index.yaml
• qa/scenarios/<theme>/*.yaml

Они намеренно хранятся в git, чтобы план контроля качества был доступен как людям, так и агенту.

qa-lab остаётся универсальным средством запуска сценариев YAML. Каждый YAML-файл сценария служит источником истины для одного тестового запуска и должен определять:

• title верхнего уровня
• метаданные scenario
• необязательные метаданные категории, возможности, набора и риска в scenario
• ссылки на документацию и код в scenario
• необязательные требования к плагинам в scenario
• необязательное изменение конфигурации Gateway в scenario
• исполняемый flow верхнего уровня для потоковых сценариев или scenario.execution.kind / scenario.execution.path для сценариев Vitest и Playwright

Многократно используемая поверхность среды выполнения, лежащая в основе flow, остаётся универсальной и сквозной. Например, сценарии YAML могут сочетать вспомогательные средства на стороне транспорта со средствами на стороне браузера, которые управляют встроенным Control UI через шов Gateway browser.request, не добавляя специализированное средство запуска.

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

Базовый список должен оставаться достаточно широким, чтобы охватывать:

• личные сообщения и чаты каналов
• поведение веток обсуждения
• жизненный цикл действий с сообщениями
• обратные вызовы Cron
• извлечение данных из памяти
• переключение моделей
• передачу подагенту
• чтение репозитория и документации
• одну небольшую задачу сборки, например Lobster Invaders

Наборы имитации провайдеров

qa suite содержит два локальных набора имитации провайдеров:

• mock-openai — учитывающая сценарии имитация OpenClaw. Она остаётся стандартным детерминированным набором имитации для контроля качества на основе репозитория и проверок эквивалентности.
• aimock запускает сервер провайдера на основе AIMock для экспериментального покрытия протоколов, фикстур, записи/воспроизведения и хаотических сбоев. Он дополняет, но не заменяет диспетчер сценариев mock-openai.

Реализация наборов провайдеров находится в extensions/qa-lab/src/providers/. Каждый провайдер владеет своими стандартными параметрами, запуском локального сервера, конфигурацией модели Gateway, требованиями к подготовке профиля аутентификации и флагами возможностей реального/имитированного режима. Общий код набора и Gateway использует реестр провайдеров вместо ветвления по их именам.

Транспортные адаптеры

qa-lab предоставляет универсальный транспортный шов для сценариев контроля качества YAML. qa-channel — стандартный синтетический вариант. crabline запускает локальные серверы в форме провайдеров и выполняет обычные плагины каналов OpenClaw для работы с ними. live зарезервирован для реальных учётных данных провайдеров и внешних каналов.

На архитектурном уровне разделение выглядит так:

• qa-lab отвечает за универсальное выполнение сценариев, параллелизм рабочих процессов, запись артефактов и формирование отчётов.
• Транспортный адаптер отвечает за конфигурацию Gateway, готовность, отслеживание входящих и исходящих событий, транспортные действия и нормализованное состояние транспорта.
• Файлы сценариев YAML в qa/scenarios/ определяют тестовый запуск; qa-lab предоставляет многократно используемую поверхность среды выполнения для их исполнения.

Добавление канала

Для добавления канала в систему контроля качества YAML требуется реализация канала и набор сценариев, проверяющий контракт канала. Для покрытия дымовыми проверками CI добавьте соответствующий локальный сервер провайдера Crabline и предоставьте к нему доступ через драйвер crabline.

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

qa-lab отвечает за общие механизмы узла:

• корневой элемент команд openclaw qa
• запуск и завершение работы набора
• параллелизм рабочих процессов
• запись артефактов
• формирование отчётов
• выполнение сценариев
• псевдонимы совместимости для старых сценариев qa-channel

Плагины средств запуска отвечают за транспортный контракт:

• как openclaw qa <runner> подключается под общим корневым элементом qa
• как Gateway настраивается для этого транспорта
• как проверяется готовность
• как внедряются входящие события
• как отслеживаются исходящие сообщения
• как предоставляются расшифровки и нормализованное состояние транспорта
• как выполняются действия, поддерживаемые транспортом
• как выполняется сброс или очистка, специфичные для транспорта

Минимальные требования для добавления нового канала:

1. Оставьте qa-lab владельцем общего корня qa.
2. Реализуйте средство запуска транспорта на общем интерфейсе хоста qa-lab.
3. Сохраняйте специфичные для транспорта механизмы внутри плагина средства запуска или тестовой обвязки канала.
4. Подключайте средство запуска как openclaw qa <runner>, а не регистрируйте конкурирующую корневую команду. Плагины средств запуска должны объявлять qaRunners в openclaw.plugin.json и экспортировать соответствующий массив qaRunnerCliRegistrations из runtime-api.ts. Сохраняйте runtime-api.ts легковесным; отложенная загрузка CLI и выполнение средства запуска должны оставаться за отдельными точками входа. Необязательный adapterFactory предоставляет транспорт общим сценариям, не изменяя существующий каталог сценариев команды.
5. Создавайте или адаптируйте YAML-сценарии в тематических каталогах qa/scenarios/.
6. Используйте универсальные вспомогательные функции сценариев для новых сценариев.
7. Сохраняйте работоспособность существующих псевдонимов совместимости, если только в репозитории не выполняется намеренная миграция.

Правило принятия решения строгое:

• Если поведение можно однократно выразить в qa-lab, поместите его в qa-lab.
• Если поведение зависит от транспорта одного канала, сохраняйте его в соответствующем плагине средства запуска или тестовой обвязке плагина.
• Если сценарию нужна новая возможность, которую могут использовать несколько каналов, добавьте универсальную вспомогательную функцию вместо специфичной для канала ветви в suite.ts.
• Если поведение имеет смысл только для одного транспорта, оставьте сценарий специфичным для транспорта и явно укажите это в контракте сценария.

Имена вспомогательных функций сценариев

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

• waitForTransportReady
• waitForChannelReady
• injectInboundMessage
• injectOutboundMessage
• waitForTransportOutboundMessage
• waitForChannelOutboundMessage
• waitForNoTransportOutbound
• getTransportSnapshot
• readTransportMessage
• readTransportTranscript
• formatTransportTranscript
• resetTransport

Псевдонимы совместимости остаются доступными для существующих сценариев — waitForQaChannelReady, waitForOutboundMessage, waitForNoOutbound, formatConversationTranscript, resetBus, — но при создании новых сценариев следует использовать универсальные имена. Псевдонимы существуют, чтобы избежать одномоментной миграции, а не как модель для дальнейшего развития.

Отчётность

qa-lab экспортирует отчёт о протоколе в формате Markdown на основе наблюдаемой временной шкалы шины. Отчёт должен отвечать на следующие вопросы:

• Что сработало
• Что завершилось с ошибкой
• Что осталось заблокированным
• Какие дополнительные сценарии стоит добавить

Чтобы получить перечень доступных сценариев, полезный при оценке объёма дальнейшей работы или подключении нового транспорта, выполните pnpm openclaw qa coverage (добавьте --json для машиночитаемого вывода). Чтобы выбрать целевую проверку для затронутого поведения или пути к файлу, выполните pnpm openclaw qa coverage --match <query>. Отчёт о совпадениях выполняет поиск по метаданным сценариев, ссылкам на документацию, ссылкам на код, идентификаторам покрытия, плагинам и требованиям провайдеров, а затем выводит соответствующие цели qa suite --scenario ....

Каждый запуск qa suite записывает артефакты верхнего уровня qa-evidence.json, qa-suite-summary.json и qa-suite-report.md для выбранного набора сценариев. Сценарии, объявляющие execution.kind: vitest или execution.kind: playwright, запускают соответствующий путь тестирования и также записывают журналы для каждого сценария. Сценарии, объявляющие execution.kind: script, запускают генератор свидетельств по адресу execution.path через node --import tsx (с ${outputDir} и ${scenarioId}, раскрытыми в execution.args); генератор записывает собственный qa-evidence.json, записи которого импортируются в вывод набора, а пути к артефактам разрешаются относительно qa-evidence.json этого генератора. Когда qa suite достигается через qa run --qa-profile, тот же qa-evidence.json также включает сводку оценочной таблицы профиля для выбранных категорий таксономии.

Рассматривайте результаты покрытия как средство поиска, а не как замену проверкам; для выбранного сценария по-прежнему требуется подходящий режим провайдера, реальный транспорт, Multipass, Testbox или канал выпуска для тестируемого поведения. Контекст оценочной таблицы см. в разделе Оценочная таблица зрелости.

Для проверок характера и стиля запускайте один и тот же сценарий с несколькими реальными ссылками на модели и создавайте оценённый отчёт в формате Markdown:

pnpm openclaw qa character-eval \  --model openai/gpt-5.6-luna,thinking=medium,fast \  --model openai/gpt-5.2,thinking=xhigh \  --model openai/gpt-5,thinking=xhigh \  --model anthropic/claude-opus-4-8,thinking=high \  --model anthropic/claude-sonnet-4-6,thinking=high \  --model zai/glm-5.1,thinking=high \  --model moonshot/kimi-k2.5,thinking=high \  --model google/gemini-3.1-pro-preview,thinking=high \  --judge-model openai/gpt-5.6-sol,thinking=xhigh,fast \  --judge-model anthropic/claude-opus-4-8,thinking=high \  --blind-judge-models \  --concurrency 16 \  --judge-concurrency 16

Команда запускает локальные дочерние процессы Gateway для контроля качества, а не Docker. Сценарии оценки характера должны задавать персону через SOUL.md, а затем выполнять обычные пользовательские запросы, например общение в чате, помощь с рабочей областью и небольшие задачи с файлами. Модели-кандидату не следует сообщать, что её оценивают. Команда сохраняет каждую полную расшифровку, записывает основные статистические данные запуска, а затем просит модели-судьи в быстром режиме с рассуждением xhigh, где оно поддерживается, ранжировать запуски по естественности, атмосфере и юмору. Используйте --blind-judge-models при сравнении провайдеров: запрос судьи по-прежнему получает все расшифровки и статусы запусков, но ссылки на кандидатов заменяются нейтральными метками, например candidate-01; после разбора отчёт сопоставляет результаты ранжирования с реальными ссылками.

По умолчанию запуски кандидатов используют уровень рассуждения high, с medium для GPT-5.6 Luna и xhigh для более старых ссылок оценки OpenAI, которые его поддерживают. Переопределите настройку конкретного кандидата непосредственно с помощью --model provider/model,thinking=<level>; встроенные параметры также поддерживают fast, no-fast и fast=<bool>. --thinking <level> по-прежнему задаёт глобальное резервное значение, а прежняя форма --model-thinking <provider/model=level> сохранена для совместимости. Ссылки на кандидатов OpenAI по умолчанию используют быстрый режим, чтобы применялась приоритетная обработка там, где провайдер её поддерживает. Передавайте --fast только в том случае, если требуется принудительно включить быстрый режим для каждой модели-кандидата. Длительность работы кандидатов и судей записывается в отчёте для анализа производительности, но в запросах судьям явно указано не ранжировать по скорости. По умолчанию запуски моделей-кандидатов и моделей-судей выполняются с параллелизмом 16. Уменьшите --concurrency или --judge-concurrency, если ограничения провайдера или нагрузка на локальный Gateway создают слишком много помех при запуске.

Если --model кандидата не передан, оценка характера по умолчанию использует openai/gpt-5.6-luna, openai/gpt-5.2, openai/gpt-5, anthropic/claude-opus-4-8, anthropic/claude-sonnet-4-6, zai/glm-5.1, moonshot/kimi-k2.5 и google/gemini-3.1-pro-preview. Если --judge-model не передан, по умолчанию используются судьи openai/gpt-5.6-sol,thinking=xhigh,fast и anthropic/claude-opus-4-8,thinking=high.

Связанная документация

• Матричный контроль качества
• Оценочная таблица зрелости
• Набор тестов производительности персонального агента
• Канал контроля качества
• Тестирование
• Панель управления