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

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

Компоненты:

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

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

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

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, укажите корневой профиль перед командой контроля качества:

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

Процесс оператора

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

• Слева: панель Gateway (Control UI) с агентом.
• Справа: лаборатория контроля качества с перепиской в стиле Slack и планом сценария.

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

pnpm qa:lab:up

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

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

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:otel:smoke запускает локальный приёмник OTLP/HTTP, выполняет минимальный проход агента QA-канала, а затем проверяет экспорт трассировок, метрик и журналов. Он декодирует экспортированные интервалы трассировки protobuf и проверяет критически важную для выпуска структуру: должны присутствовать openclaw.run, openclaw.harness.run, интервал вызова модели по последнему семантическому соглашению GenAI, openclaw.context.assembled и openclaw.message.delivery. Дымовой тест принудительно задаёт 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 проверяет, что неаутентифицированные запросы сбора отклоняются, а затем проверяет, что аутентифицированный запрос сбора содержит критически важные для выпуска семейства метрик без содержимого запросов, содержимого ответов, необработанных диагностических идентификаторов, токенов аутентификации и локальных путей.

Контуры дымового тестирования Matrix

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

pnpm openclaw qa matrix --provider-mode mock-openai --profile release

Для контура с актуальным рабочим поставщиком явно укажите совместимые с OpenAI учётные данные:

OPENCLAW_LIVE_OPENAI_KEY="${OPENAI_API_KEY}" \  pnpm openclaw qa matrix --provider-mode live-frontier --profile release

Обычный pnpm openclaw qa matrix запускает полный профиль all и продолжает работу после сбоев сценариев. Используйте --fail-fast для более короткого цикла обратной связи или повторите --scenario <id>, чтобы выбрать отдельные сценарии; явно заданные идентификаторы сценариев имеют приоритет над --profile.

Состав профилей и требования к каналам определены вместе с декларативными сценариями Matrix в qa/scenarios/channels/. Запуск выбирает драйвер канала. Их рабочие реализации находятся в extensions/qa-lab/src/live-transports/matrix/scenarios/.

Адаптер развёртывает одноразовый домашний сервер Tuwunel в Docker (образ по умолчанию ghcr.io/matrix-construct/tuwunel:v1.5.1, имя сервера matrix-qa.test, порт 28008), регистрирует временных пользователей драйвера, тестируемой системы и наблюдателя, создаёт необходимые комнаты и записывает границу запросов/ответов с удалёнными конфиденциальными данными. Затем он запускает реальный плагин Matrix внутри дочернего QA-шлюза, ограниченного этим транспортом (без qa-channel), после чего удаляет окружение.

Общие параметры:

Matrix QA не арендует общие учётные данные Matrix: адаптер создаёт одноразовых пользователей локально, поэтому он не принимает --credential-source или --credential-role. Переопределите образ домашнего сервера с помощью OPENCLAW_QA_MATRIX_TUWUNEL_IMAGE; настройте отрицательные проверки отсутствия ответа с помощью OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS (по умолчанию 8000, ограничивается активным тайм-аутом сценария). Одноразовая команда обычно принудительно выполняет чистое завершение после записи артефактов, поскольку нативные дескрипторы криптографии Matrix могут пережить очистку; задавайте OPENCLAW_QA_MATRIX_DISABLE_FORCE_EXIT=1 только для непосредственной тестовой инфраструктуры, которой необходимо, чтобы команда вернула управление.

Каждый запуск записывает стандартные артефакты QA Lab в выбранный выходной каталог: qa-suite-report.md, qa-suite-summary.json, qa-evidence.json и манифест matrix-harness-*/matrix-qa-harness.json с удалёнными конфиденциальными данными. Если очистка завершится сбоем, выполните выведенную команду восстановления docker compose ... down --remove-orphans. На медленных исполнителях увеличьте окно отсутствия ответа; в быстром CI меньшее окно может ускорить отрицательные проверки.

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

matrix-room-block-streaming и subagent-thread-spawn остаются доступными при явном выборе --scenario, но не входят в профиль all по умолчанию.

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

Сценарии Discord Mantis

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

Другие контуры дымового тестирования с реальным транспортом:

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

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

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

Для полного запуска виртуальной машины с настольным Slack и аварийным доступом по VNC выполните:

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

Эта команда арендует машину Crabbox с рабочим столом и браузером, запускает live-сценарий 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 оставляет постоянно работающий Slack Gateway OpenClaw внутри виртуальной машины на порту 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 в slack-desktop-smoke.png; изображения контрольных точек одобрения служат визуальным доказательством для этого сценария.

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

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

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

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.

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

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

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 и проверяет доступность операций администрирования и получения списка, когда присутствует секрет сопровождающего.

Каноническое покрытие сценариев

Корневой файл taxonomy.yaml определяет семантические идентификаторы покрытия. YAML-файлы сценариев в qa/scenarios/ сопоставляют каждый сценарий с этими идентификаторами и содержат метаданные выполнения: channel является единственным требованием к каналу, а profiles объявляют принадлежность к именованным запускам. Драйвер канала — взаимозаменяемый вариант реализации на уровне запуска. Средства запуска TypeScript запрашивают этот каталог; они не поддерживают параллельные реестры сценариев или покрытия.

Статический вывод qa coverage сообщает о сопоставлении таксономии со сценариями. Фактическое подтверждение поступает из qa-evidence.json, где записываются выполненный сценарий, идентификаторы покрытия, канал, фактически использованный драйвер и результат. Канал и драйвер являются измерениями отчёта, а не дополнительными словарями идентификаторов покрытия или осями допустимости сценариев.

Для запуска в одноразовой виртуальной машине 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, если нужны артефакты без ненулевого кода завершения.

Live-запуски передают поддерживаемые входные данные аутентификации QA, применимые для гостевой системы: ключи поставщиков из переменных среды, путь к конфигурации live-поставщика 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

Профиль release выбирает поддерживаемые YAML-сценарии Telegram; all добавляет подключаемые стресс-проверки сеансов, использования, цепочек ответов и потоковой передачи. Явные значения --scenario переопределяют профиль.

• channel-canary
• channel-mention-gating
• 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

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

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

• qa-suite-report.md
• qa-suite-summary.json
• 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", экспортирует переменные окружения арендованных группы, драйвера и бота SUT в запуск установленного пакета, отправляет Heartbeat для аренды и освобождает её при завершении работы. По умолчанию пакетная обёртка выполняет 20 проверок RTT для channel-canary, использует тайм-аут 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 с двумя ботами: ботом-драйвером, управляемым тестовой обвязкой, и ботом SUT, запускаемым дочерним Gateway OpenClaw через встроенный плагин Discord. Проверяет обработку упоминаний в канале, регистрацию ботом SUT нативной команды /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 — должен совпадать с идентификатором пользователя бота SUT, возвращённым Discord (иначе контур немедленно завершается с ошибкой).

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

• OPENCLAW_QA_DISCORD_VOICE_CHANNEL_ID выбирает голосовой/сценический канал для discord-voice-autojoin; если значение не задано, сценарий выбирает первый голосовой/сценический канал, видимый боту SUT.

Сценарии YAML-модуля Discord (qa/scenarios/channels/discord-*.yaml):

• discord-canary
• discord-mention-gating
• discord-native-help-command-registration
• discord-voice-autojoin — опциональный голосовой сценарий. Запускается отдельно, включает channels.discord.voice.autoJoin и проверяет, что текущее голосовое состояние бота SUT в Discord соответствует целевому голосовому/сценическому каналу. Учётные данные Discord в Convex могут включать необязательный voiceChannelId; в противном случае адаптер средства запуска обнаруживает первый видимый голосовой/сценический канал в гильдии.
• discord-status-reactions-tool-only — опциональный сценарий Mantis. Запускается отдельно, поскольку переводит SUT в режим постоянных ответов гильдии только с результатами инструментов с помощью 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

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

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json — записи свидетельств для проверок транспорта в реальной среде.
• discord-qa-reaction-timelines.json и discord-status-reactions-tool-only-timeline.png при выполнении сценария реакций на состояние.

QA для Slack

pnpm openclaw qa slack

Ориентирован на один реальный приватный канал Slack с двумя разными ботами: ботом-драйвером, управляемым тестовой обвязкой, и ботом SUT, запускаемым дочерним 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_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

Сценарии YAML-модуля Slack (qa/scenarios/channels/slack-*.yaml):

• 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 для бота SUT в целевом сообщении.
• slack-chart-presentation-native — опциональный переносимый сценарий диаграммы, который проверяет нативный блок data_visualization и точный доступный текст.
• slack-table-presentation-native — опциональный переносимый сценарий таблицы, который проверяет нативный блок data_table, точные строки и доступный текст.
• slack-table-invalid-blocks-fallback — опциональный сценарий прямого транспорта, который отправляет структурно читаемую необработанную таблицу, превышающую лимит, со 101 строками данных и заголовком через производственный путь отправки Slack, подтверждает, что сам Slack возвращает invalid_blocks, и проверяет, что сохранённый резервный вариант с отключённым форматированием полон и не содержит нативного блока данных. В сведениях о сценарии сохраняются только безопасные свидетельства в виде кода ошибки, количества и логических значений.
• 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. Сведения о сценарии включают метод сервера приложений Codex, ключ выбранной модели Codex, итоговое состояние хода Codex и проверку маркера операции вместе с отредактированными метаданными подтверждения Slack.

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

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json — записи свидетельств для проверок транспорта в реальной среде.
• 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, выделенное для QA, а не повторно использовать производственное рабочее пространство.

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

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

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

{  "display_information": {    "name": "OpenClaw QA Driver",    "description": "Бот-драйвер тестирования для контура QA 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 в том же рабочем пространстве. Это приложение QA намеренно использует более узкую версию производственного манифеста встроенного плагина Slack (extensions/slack/src/setup-shared.ts:12): области разрешений и события для реакций исключены, поскольку набор QA-проверок Slack в реальной среде пока не охватывает обработку реакций.

{  "display_information": {    "name": "OpenClaw QA SUT",    "description": "Коннектор OpenClaw QA SUT для 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. Создайте канал

В рабочем пространстве QA создайте канал (например, #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 "Начальное заполнение пула QA 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 секунд, а qa-suite-report.md показывает и slack-canary, и slack-mention-gating со статусом pass. Если поток зависает примерно на 90 секунд и завершается с Convex credential pool exhausted for kind "slack", значит, пул пуст или все строки арендованы — qa credentials list --kind slack --status all --json укажет конкретную причину.

QA для WhatsApp

pnpm openclaw qa whatsapp

Используются две выделенные учётные записи WhatsApp Web: учётная запись драйвера, управляемая тестовой системой, и учётная запись SUT, запускаемая дочерним 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.

YAML-сценарии WhatsApp (qa/scenarios/channels/whatsapp-*.yaml):

• Базовое поведение и фильтрация групп: 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 по умолчанию оставлен небольшим — 8 сценариев для быстрой дымовой проверки. Поток mock-openai по умолчанию детерминированно запускает 39 сценариев через реальный транспорт WhatsApp, имитируя только вывод модели; сценарии подтверждения и несколько более тяжёлых или блокирующих проверок по-прежнему запускаются явно по идентификатору сценария.

Драйвер QA для 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), чтобы свидетельства нельзя было принять за подтверждение более строгого контракта, чем они фактически доказывают.

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

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json — записи свидетельств для проверок транспорта в реальном времени.

Пул учётных данных 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, запись рабочего стола с частотой 24 кадра/с, анимированный GIF с частотой 24 кадра/с и ширина предварительного просмотра 1920 пикселей. Комментарии до и после должны публиковать чистый набор, содержащий только необходимые 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 был виден и людям, и агенту.

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.

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

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