--- doc-schema-version: 1 read_when: - Как устроен стек QA - Расширение qa-lab, qa-channel или транспортного адаптера - Добавление сценариев QA, хранящихся в репозитории - Создание более реалистичной автоматизации контроля качества для панели управления Gateway summary: 'Обзор стека контроля качества: qa-lab, qa-channel, сценарии на основе репозитория, каналы передачи данных в реальном времени, адаптеры транспорта и отчётность.' title: Обзор контроля качества x-i18n: generated_at: "2026-07-16T16:48:10Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: 8dcb506cedb57289f29938eb55b5f11ceedfaabba88364dce8249116010ce859 source_path: concepts/qa-e2e-automation.md workflow: 16 --- Приватный стек контроля качества проверяет OpenClaw в реалистичных условиях, имитирующих работу каналов, которые невозможно воспроизвести модульным тестом. Компоненты: - `extensions/qa-channel`: синтетический канал сообщений с личными сообщениями, каналами, ветками, реакциями, редактированием и удалением. - `extensions/qa-lab`: интерфейс отладчика, шина контроля качества, профили сценариев и адаптеры транспорта для наблюдения за перепиской, внедрения входящих сообщений и экспорта отчёта в формате Markdown. - `qa/`: хранящиеся в репозитории исходные ресурсы для начальной задачи и базовых сценариев контроля качества. - [Mantis](/ru/concepts/mantis): проверка до и после изменений для ошибок, которые требуют реальных транспортов, снимков экрана браузера, состояния виртуальной машины и доказательств для PR. ## Интерфейс команд Все процессы контроля качества выполняются через `pnpm openclaw qa `. Для многих предусмотрены псевдонимы скриптов `pnpm qa:*`; работают обе формы. | Команда | Назначение | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `qa run` | Встроенная самопроверка контроля качества без `--qa-profile`; средство запуска профилей зрелости на основе таксономии с `--qa-profile smoke-ci`, `--qa-profile release` или `--qa-profile all`. | | `qa suite` | Запускает хранящиеся в репозитории сценарии в канале Gateway для контроля качества. `--runner multipass` использует одноразовую виртуальную машину Linux вместо хоста. | | `qa coverage` | Выводит инвентарный список покрытия сценариев в формате YAML (`--json` для машинного вывода; `--match ` для поиска сценариев, относящихся к изменённому поведению; `--tools` для покрытия фикстурами инструментов среды выполнения). | | `qa parity-report` | Сравнивает два файла `qa-suite-summary.json` для проверки паритета по оси моделей или использует `--runtime-axis --token-efficiency`, чтобы записать отчёты о паритете сред выполнения Codex и OpenClaw и эффективности использования токенов. | | `qa confidence-report` | Классифицирует артефакты подтверждения контроля качества по манифесту и формирует отчёт об уверенности без неизвестных элементов. | | `qa confidence-self-test` | Записывает контрольные индикаторы с намеренно отрицательным результатом, подтверждающие, что проверка уверенности обнаруживает отклонения. | | `qa jsonl-replay` | Воспроизводит подготовленные расшифровки JSONL с помощью стенда воспроизведения для проверки паритета среды выполнения. | | `qa character-eval` | Запускает сценарий контроля качества персонажа для нескольких реальных моделей с оценочным отчётом. См. [Отчётность](#reporting). | | `qa manual` | Выполняет разовый запрос через выбранный канал провайдера и модели. | | `qa ui` | Запускает интерфейс отладчика контроля качества и локальную шину контроля качества (псевдоним: `pnpm qa:lab:ui`). | | `qa docker-build-image` | Собирает предварительно подготовленный образ Docker для контроля качества. | | `qa docker-scaffold` | Создаёт каркас docker-compose для панели контроля качества и канала Gateway. | | `qa up` | Собирает сайт контроля качества, запускает стек на базе Docker и выводит URL (псевдоним: `pnpm qa:lab:up`; вариант `:fast` добавляет `--use-prebuilt-image --bind-ui-dist --skip-ui-build`). | | `qa aimock` | Запускает только сервер провайдера AIMock. | | `qa mock-openai` | Запускает только сервер провайдера `mock-openai`, учитывающий сценарии. | | `qa credentials doctor` / `add` / `list` / `remove` | Управляет общим пулом учётных данных Convex. | | `qa discord` | Канал реального транспорта для настоящего приватного канала гильдии Discord. | | `qa matrix` | Профили Matrix в лаборатории контроля качества для одноразового домашнего сервера Tuwunel. См. [Каналы быстрой проверки Matrix](#matrix-smoke-lanes). | | `qa slack` | Канал реального транспорта для настоящего приватного канала Slack. | | `qa telegram` | Канал реального транспорта для настоящей приватной группы Telegram. | | `qa whatsapp` | Канал реального транспорта для настоящих учётных записей WhatsApp Web. | | `qa mantis` | Средство проверки до и после изменений для ошибок реального транспорта с доказательствами в виде реакций на статус в Discord, быстрой проверки рабочего стола и браузера в Crabbox и быстрой проверки Slack через VNC. См. [Mantis](/ru/concepts/mantis) и [руководство по запуску Mantis Slack Desktop](/ru/concepts/mantis-slack-desktop-runbook). | ### `qa run` на основе профилей `qa run` на основе профилей считывает состав из `taxonomy.yaml`, а затем передаёт разрешённые сценарии через `qa suite`. `--surface` и `--category` фильтруют выбранный профиль вместо определения отдельных каналов. Полученный `qa-evidence.json` включает сводку показателей профиля с количеством выбранных категорий и идентификаторами отсутствующего покрытия; отдельные записи доказательств остаются источником истины для тестов, ролей покрытия и результатов. Идентификаторы покрытия функций таксономии — это точные цели подтверждения, а не псевдонимы: основное покрытие сценария обеспечивает соответствующие идентификаторы, а вторичное покрытие остаётся рекомендательным. Идентификаторы покрытия используют точечную форму `namespace.behavior` с сегментами из строчных букв, цифр и дефисов; идентификаторы профилей, поверхностей и категорий по-прежнему могут использовать существующие дефисные или точечные идентификаторы таксономии. Сокращённые доказательства не включают `execution` для каждой записи и задают `evidenceMode: "slim"`; `smoke-ci` по умолчанию использует сокращённый формат, а `--evidence-mode full` восстанавливает полные записи: ```bash 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, укажите корневой профиль перед командой контроля качества: ```bash pnpm openclaw --profile work qa run --qa-profile smoke-ci ``` ## Процесс оператора Текущий операторский процесс контроля качества использует сайт контроля качества с двумя панелями: - Слева: панель Gateway (Control UI) с агентом. - Справа: лаборатория контроля качества с перепиской в стиле Slack и планом сценария. Запустите его командой: ```bash pnpm qa:lab:up ``` Она собирает сайт контроля качества, запускает канал Gateway на базе Docker и открывает страницу лаборатории контроля качества, где оператор или цикл автоматизации может поручить агенту задачу контроля качества, наблюдать реальное поведение канала и фиксировать, что сработало, завершилось ошибкой или осталось заблокированным. Для более быстрой итерации над интерфейсом лаборатории контроля качества без повторной сборки образа Docker каждый раз запускайте стек с подключённым через bind mount пакетом лаборатории контроля качества: ```bash pnpm openclaw qa docker-build-image pnpm qa:lab:build pnpm qa:lab:up:fast pnpm qa:lab:watch ``` `qa:lab:up:fast` оставляет службы Docker на предварительно собранном образе и подключает `extensions/qa-lab/web/dist` через bind mount к контейнеру `qa-lab`. `qa:lab:watch` пересобирает этот пакет при изменениях, а браузер автоматически перезагружается, когда изменяется хеш ресурса лаборатории контроля качества. ### Быстрые проверки наблюдаемости Контроль качества наблюдаемости доступен только из рабочей копии исходного кода. Архив npm намеренно не включает лабораторию контроля качества (и `qa-channel`), поэтому каналы выпуска пакета Docker не выполняют команды `qa`. При изменении инструментария диагностики запускайте их из собранной рабочей копии исходного кода. | Псевдоним | Что запускается | | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | `pnpm qa:otel:smoke` | Локальный приёмник OpenTelemetry и сценарий `otel-trace-smoke` с включённым `diagnostics-otel`. | | `pnpm qa:otel:collector-smoke` | Тот же контур за реальным Docker-контейнером OpenTelemetry Collector. Используйте его при изменении подключения конечных точек или совместимости коллектора/OTLP. | | `pnpm qa:prometheus:smoke` | Сценарий `docker-prometheus-smoke` с включённым `diagnostics-prometheus`. | | `pnpm qa:observability:smoke` | `qa:otel:smoke`, затем `qa:prometheus:smoke`. | | `pnpm qa:observability:collector-smoke` | `qa:otel:collector-smoke`, затем `qa:prometheus:smoke`. | `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: ```bash pnpm openclaw qa matrix --provider-mode mock-openai --profile release ``` Для контура с актуальным рабочим поставщиком явно укажите совместимые с OpenAI учётные данные: ```bash 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 `, чтобы выбрать отдельные сценарии; явно заданные идентификаторы сценариев имеют приоритет над `--profile`. | Профиль | Сценарии | Назначение | | ------------ | --------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `all` | 93 | Полный каталог (по умолчанию). | | `release` | 2 | Критически важная для выпуска базовая проверка канала и динамическая перезагрузка списка разрешений. | | `fast` | 12 | Целенаправленное покрытие цепочек обсуждений, реакций, подтверждений, политик, допуска ботов и зашифрованных ответов. | | `transport` | 50 | Цепочки обсуждений, маршрутизация личных сообщений/комнат, автоматическое присоединение, подтверждения, реакции, перезапуски, политики упоминаний/списков разрешений, правки и порядок сообщений нескольких участников. | | `media` | 7 | Покрытие изображений, сгенерированных изображений, голосовых сообщений, вложений, неподдерживаемых и зашифрованных медиаданных. | | `e2ee-smoke` | 8 | Минимальное покрытие зашифрованных ответов, цепочек обсуждений, начальной настройки, восстановления, перезапуска, редактирования и сбоев. | | `e2ee-deep` | 18 | Потеря состояния, резервное копирование, восстановление ключей, гигиена устройств и проверка SAS/QR/личных сообщений. | | `e2ee-cli` | 9 | `openclaw matrix encryption setup`, ключ восстановления, несколько учётных записей, полный цикл через Gateway и команды самопроверки посредством тестовой инфраструктуры. | Состав профилей и требования к каналам определены вместе с декларативными сценариями 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`), после чего удаляет окружение. Общие параметры: | Флаг | По умолчанию | Назначение | | ------------------------ | ----------------- | ------------------------------------------------------------------------------------ | | `--profile ` | `all` | Выбрать один из указанных выше профилей. | | `--scenario ` | - | Выбрать один сценарий; можно указывать несколько раз. | | `--fail-fast` | выключено | Остановиться после первой неуспешной проверки или первого неуспешного сценария. | | `--allow-failures` | выключено | Записать артефакты, не возвращая код неуспешного завершения при сбоях сценариев. | | `--provider-mode ` | `live-frontier` | Использовать `mock-openai` для детерминированной диспетчеризации или `live-frontier` для рабочего поставщика. | | `--model ` | значение поставщика по умолчанию | Задать основную ссылку `provider/model`. | | `--alt-model ` | значение поставщика по умолчанию | Задать альтернативную модель, используемую сценариями, которые переключают модели. | | `--fast` | выключено | Включить быстрый режим поставщика там, где он поддерживается. | | `--output-dir ` | создаётся автоматически | Выбрать каталог отчётов; относительные пути разрешаются относительно `--repo-root`. | | `--repo-root ` | текущий каталог | Запустить из нейтрального рабочего каталога. | | `--sut-account ` | `sut` | Выбрать идентификатор учётной записи Matrix в конфигурации дочернего Gateway. | 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. Другие контуры дымового тестирования с реальным транспортом: ```bash pnpm openclaw qa discord pnpm openclaw qa slack pnpm openclaw qa telegram pnpm openclaw qa whatsapp ``` Они нацелены на уже существующий реальный канал с двумя ботами или учётными записями (драйвер + тестируемая система). Необходимые переменные окружения, списки сценариев, выходные артефакты и пул учётных данных Convex для этих четырёх транспортов описаны ниже в [справочнике QA для Discord, Slack, Telegram и WhatsApp](#discord-slack-telegram-and-whatsapp-qa-reference). ### Средства запуска настольного Slack и визуальных задач Mantis Для полного запуска виртуальной машины с настольным Slack и аварийным доступом по VNC выполните: ```bash 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 ` после входа в 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: ```bash pnpm openclaw qa mantis slack-desktop-smoke \ --approval-checkpoints \ --credential-source convex \ --credential-role maintainer ``` Этот режим взаимно исключает `--gateway-setup`. Он запускает сценарии одобрения Slack, отклоняет идентификаторы сценариев, не относящихся к одобрению, ожидает каждое состояние ожидающего и разрешённого одобрения, визуализирует наблюдаемое сообщение Slack API в `approval-checkpoints/-pending.png` и `approval-checkpoints/-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](/ru/concepts/mantis-slack-desktop-runbook). Для задачи на рабочем столе в стиле агента или компьютерного зрения выполните: ```bash 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-учётных данных выполните: ```bash 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 выполните: ```bash 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 `, чтобы настроить число рабочих процессов, или `--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` и принимают одинаковые флаги: | Флаг | По умолчанию | Описание | | ------------------------------------- | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `--scenario ` | - | Запустить только этот сценарий. Можно указывать несколько раз. | | `--output-dir ` | `/.artifacts/qa-e2e/-` | Место записи отчётов, сводок, свидетельств, артефактов транспорта и журнала вывода. Относительные пути разрешаются относительно `--repo-root`. | | `--repo-root ` | `process.cwd()` | Корень репозитория при запуске из нейтрального текущего рабочего каталога. | | `--sut-account ` | `sut` | Идентификатор временной учётной записи в конфигурации Gateway для QA. | | `--provider-mode ` | `live-frontier` | `mock-openai`, `aimock` или `live-frontier`. | | `--model ` / `--alt-model ` | значение поставщика по умолчанию | Ссылки на основную и альтернативную модели. | | `--fast` | выкл. | Быстрый режим поставщика, если поддерживается. | | `--credential-source ` | `env` | См. [пул учётных данных Convex](#convex-credential-pool). | | `--credential-role ` | `ci` в CI, иначе `maintainer` | Роль, используемая при `--credential-source convex`. | | `--allow-failures` | выкл. | Записывать артефакты, не возвращая ненулевой код завершения при сбое сценариев. | Каждый сценарий завершается с ненулевым кодом при сбое любого сценария. `--allow-failures` записывает артефакты, не устанавливая ненулевой код завершения. Telegram также принимает `--list-scenarios`, чтобы вывести доступные идентификаторы сценариев и завершить работу; остальные сценарии не предоставляют этот флаг. ### QA для Telegram ```bash 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. ```bash 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 ```bash 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-mantis-scenarios). Явный запуск сценария автоматического подключения к голосовому каналу Discord: ```bash pnpm openclaw qa discord \ --scenario discord-voice-autojoin \ --provider-mode mock-openai ``` Явный запуск сценария реакций на состояние Mantis: ```bash 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 ```bash 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. Адаптер записывает `.pending.json` и `.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](/ru/channels/slack#quick-setup); пара QA Driver/SUT намеренно разделена, поскольку контуру требуются два разных идентификатора пользователей-ботов в одном рабочем пространстве. **1. Создайте приложение Driver** Перейдите на [api.slack.com/apps](https://api.slack.com/apps) → _Create New App_ → _From a manifest_ → выберите рабочее пространство QA, вставьте следующий манифест, затем выберите _Install to Workspace_: ```json { "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 в реальной среде пока не охватывает обработку реакций. ```json { "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`) и пригласите обоих ботов из самого канала: ```text /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-файл: ```json { "channelId": "Cxxxxxxxxxx", "driverBotToken": "xoxb-...", "sutBotToken": "xoxb-...", "sutAppToken": "xapp-..." } ``` Экспортировав `OPENCLAW_QA_CONVEX_SITE_URL` и `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` в оболочке, зарегистрируйте и проверьте данные: ```bash 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. Выполните сквозную проверку** Запустите поток локально, чтобы убедиться, что оба бота могут общаться друг с другом через брокер: ```bash 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 ```bash 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](#setting-up-the-slack-workspace). Рабочие переменные среды и контракт конечной точки брокера Convex описаны в разделе [Тестирование → Общие учётные данные Telegram через Convex](/ru/help/testing#shared-telegram-credentials-via-convex-v1) (название раздела появилось до создания многоканального пула; семантика аренды одинакова для всех типов). ## Начальные данные из репозитория Ресурсы начальных данных находятся в `qa/`: - `qa/scenarios/index.yaml` - `qa/scenarios//*.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 ` монтируется под общим корневым узлом `qa` - как Gateway настраивается для этого транспорта - как проверяется готовность - как внедряются входящие события - как отслеживаются исходящие сообщения - как предоставляются расшифровки и нормализованное состояние транспорта - как выполняются действия на основе транспорта - как выполняется сброс или очистка для конкретного транспорта Минимальные требования для внедрения нового канала: 1. Оставьте `qa-lab` владельцем общего корневого узла `qa`. 2. Реализуйте транспортный исполнитель на общем стыке хоста `qa-lab`. 3. Сохраняйте механизмы, относящиеся к конкретному транспорту, внутри плагина исполнителя или тестовой обвязки канала. 4. Монтируйте исполнитель как `openclaw qa `, а не регистрируйте конкурирующую корневую команду. Плагины исполнителей должны объявлять `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 `. Отчёт о совпадениях выполняет поиск по метаданным сценариев, ссылкам на документацию, ссылкам на код, идентификаторам покрытия, плагинам и требованиям провайдеров, а затем выводит соответствующие цели `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 или режим выпуска для тестируемого поведения. Контекст карты оценок см. в разделе [Карта оценок зрелости](/ru/maturity/scorecard). Для проверки характера и стиля выполните один и тот же сценарий с несколькими реальными ссылками на модели и создайте экспертно оценённый отчёт Markdown: ```bash 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=`; встроенные параметры также поддерживают `fast`, `no-fast` и `fast=`. `--thinking ` по-прежнему задаёт глобальное резервное значение, а более старая форма `--model-thinking ` сохранена для совместимости. Ссылки на кандидатов 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`. ## Связанная документация - [Карта оценок зрелости](/ru/maturity/scorecard) - [Набор тестов производительности персонального агента](/ru/concepts/personal-agent-benchmark-pack) - [Канал контроля качества](/ru/channels/qa-channel) - [Тестирование](/ru/help/testing) - [Панель управления](/ru/web/dashboard)