Огляд контролю якості

Приватний стек QA перевіряє OpenClaw у реалістичний спосіб, що відтворює структуру каналів і недоступний модульним тестам.

Складові:

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

Командний інтерфейс

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

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

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

Поточний робочий процес оператора QA — це двопанельний сайт QA:

• Ліворуч: панель Gateway (Control UI) з агентом.
• Праворуч: QA Lab, що показує подібний до Slack транскрипт і план сценарію.

Запустіть його за допомогою:

pnpm qa:lab:up

Ця команда збирає сайт QA, запускає смугу Gateway на основі Docker і відкриває сторінку QA Lab, де оператор або цикл автоматизації може призначити агенту завдання QA, спостерігати реальну поведінку каналу та фіксувати, що спрацювало, завершилося невдало або залишилося заблокованим.

Для швидшої ітерації інтерфейсу QA Lab без повторного збирання образу Docker щоразу запустіть стек із підключеним через bind mount пакетом QA Lab:

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

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

Димові тести спостережуваності

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

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), реєструє тимчасових користувачів драйвера, SUT і спостерігача, створює потрібні кімнати й записує очищену межу запитів/відповідей. Потім він запускає справжній Plugin Matrix у дочірньому Gateway QA, обмеженому цим транспортом (без qa-channel), і видаляє середовище.

Поширені параметри:

QA Matrix не орендує спільні облікові дані 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 менше вікно може скоротити негативні перевірки.

Сценарії охоплюють поведінку транспорту, яку модульні тести не можуть перевірити наскрізно: фільтрацію згадок, політики дозволу ботів, списки дозволів, відповіді верхнього рівня й у гілках, маршрутизацію приватних повідомлень, оброблення реакцій, ігнорування вхідних редагувань, усунення дублікатів повторного відтворення після перезапуску, відновлення після переривання роботи домашнього сервера, доставлення метаданих схвалення, оброблення мультимедіа, а також процеси початкового налаштування, відновлення й перевірки E2EE Matrix. Профіль CLI E2EE також виконує 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 в одному завданні.

Сценарії Mantis для Discord

Discord також має необов’язкові сценарії лише для Mantis для відтворення помилок. Використовуйте --scenario discord-status-reactions-tool-only для явної часової шкали реакцій стану або --scenario discord-thread-reply-filepath-attachment, щоб створити справжню гілку Discord і перевірити, що message.thread-reply зберігає вкладення filePath. Ці сценарії не входять до типового робочого контуру Discord, оскільки це перевірки відтворення стану до/після, а не широке перевірочне покриття. Робочий процес Mantis для вкладень у гілках також може додати відеозапис підтвердження з автентифікованого Discord Web, якщо в середовищі QA налаштовано MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR або MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64. Цей профіль переглядача призначений лише для візуального запису; рішення про успішність або невдачу все одно надходить від оракула Discord REST.

Для інших контурів перевірки зі справжнім транспортом:

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

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

Виконавці завдань Mantis для настільного Slack і візуальних завдань

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

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

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

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

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

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

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

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

Для завдання на робочому столі в стилі агента/CV запустіть:

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 для базової перевірки без моделі, яка підтверджує роботу робочого столу, браузера, знімків екрана та відеозапису без виклику постачальника розпізнавання зображень. Запис є обов’язковим артефактом для visual-task; якщо Crabbox не записує непорожній visual-task.mp4, завдання завершується помилкою, навіть якщо візуальний драйвер успішно виконав перевірку. У разі помилки Mantis зберігає орендовану машину для VNC, якщо тільки завдання вже не було успішно виконане й не було встановлено --keep-lease.

Перевірка стану пулу облікових даних

Перед використанням спільних інтерактивних облікових даних запустіть:

pnpm openclaw qa credentials 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, коли потрібні артефакти без ненульового коду завершення.

Інтерактивні запуски передають підтримувані вхідні дані автентифікації QA, практичні для гостьової системи: ключі постачальника зі змінних середовища, шлях до конфігурації інтерактивного постачальника QA та CODEX_HOME, коли він наявний. Зберігайте --output-dir у корені репозиторію, щоб гостьова система могла записувати дані назад через змонтований робочий простір.

Довідка з QA для Discord, Slack, Telegram і WhatsApp

Адаптер Matrix використовує описаний вище одноразовий сценарій на основі Docker. Discord, Slack, Telegram і WhatsApp працюють із уже наявними реальними транспортами, тому довідкові відомості про них наведені тут.

Спільні прапорці CLI

Ці сценарії реєструються через extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts та приймають однакові прапорці:

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

QA Telegram

pnpm openclaw qa telegram

Націлено на одну реальну приватну групу Telegram із двома окремими ботами (драйвер + тестована система). Бот тестованої системи повинен мати ім’я користувача Telegram; спостереження між ботами працює найкраще, коли для обох ботів увімкнено Bot-to-Bot Communication Mode у @BotFather.

Обов’язкові змінні середовища, коли --credential-source env:

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

Профіль 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 для кожного сценарію live-адаптера Telegram.

Вихідні артефакти:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json — записи доказів для перевірок live-транспорту, включно з полями профілю, покриття, провайдера, каналу, артефактів, результату та RTT.

Пакетні запуски Telegram використовують той самий контракт облікових даних Telegram. Повторне вимірювання RTT є частиною звичайного пакетного live-конвеєра Telegram; розподіл RTT включається до qa-evidence.json у розділі result.timing для вибраної перевірки RTT.

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

Коли задано OPENCLAW_QA_CREDENTIAL_SOURCE=convex, пакетна live-обгортка орендує облікові дані 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 через вбудований Plugin Discord. Перевіряє обробку згадок у каналі, те, що бот SUT зареєстрував у Discord нативну команду /help, а також необов’язкові сценарії доказів 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 — записи доказів для перевірок live-транспорту.
• discord-qa-reaction-timelines.json і discord-status-reactions-tool-only-timeline.png, коли виконується сценарій реакцій на статус.

QA Slack

pnpm openclaw qa slack

Націлюється на один реальний приватний канал Slack із двома різними ботами: ботом-драйвером, керованим тестовою інфраструктурою, і ботом SUT, запущеним дочірнім Gateway OpenClaw через вбудований Plugin 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-сценарії, доступні через live-адаптер 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 — необов’язковий live-сценарій реакції інструмента повідомлень. Наказує агенту передати точний гліф ✅ і підтверджує, що 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 — необов’язковий сценарій нативного затвердження Plugin у Slack. Одночасно вмикає пересилання затверджень виконання та Plugin, щоб події Plugin не придушувалися маршрутизацією затверджень виконання, а потім перевіряє той самий нативний шлях інтерфейсу Slack для станів очікування та завершення.
• slack-codex-approval-exec-native — необов’язковий сценарій затвердження команд Codex Guardian. Вмикає Plugin Codex у режимі Guardian, маршрутизує ініційований зі Slack хід агента Gateway через тестову інфраструктуру app-server Codex, очікує нативний запит Plugin Slack на затвердження для openclaw-codex-app-server, ухвалює рішення й перевіряє, що хід Codex завершується з очікуваними маркерами виведення команди та асистента.
• slack-codex-approval-plugin-native — необов’язковий сценарій затвердження файлу Codex Guardian. Використовує інструкцію apply_patch поза робочою областю, щоб Codex створив маршрут app-server для затвердження зміни файлу, а потім перевіряє той самий нативний шлях затвердження Slack у станах очікування та завершення, фінальний маркер асистента й точний вміст файлу перед очищенням.

Для сценаріїв затвердження Codex потрібні openai/* або codex/* --model, звичайні облікові дані live-моделі, а також автентифікація Codex або автентифікація за ключем API, яку приймає Plugin Codex. Подробиці сценарію включають метод app-server Codex, ключ вибраної моделі Codex, фінальний статус ходу Codex і перевірку маркера операції разом із редагованими метаданими затвердження Slack.

Вихідні артефакти:

• qa-suite-report.md
• qa-suite-summary.json
• qa-evidence.json — записи доказів для перевірок live-транспорту.
• 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 навмисно звужує робоче встановлення вбудованого Plugin Slack (extensions/slack/src/setup-shared.ts:12) до дозволів і подій, охоплених live-набором 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": "Бот-драйвер тестування для live-конвеєра 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 навмисно використовує вужчу версію робочого маніфесту вбудованого Plugin Slack (extensions/slack/src/setup-shared.ts:12): області дозволів і події реакцій пропущено, оскільки live-набір 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 через вбудований Plugin 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
• необов’язкові вимоги до Plugin у 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 з урахуванням сценаріїв. Він залишається типовою детермінованою смугою імітації для QA на основі репозиторію та перевірок паритету.
• aimock запускає сервер провайдера на основі AIMock для експериментального покриття протоколів, фікстур, запису/відтворення та хаотичного тестування. Він є доповненням і не замінює диспетчер сценаріїв mock-openai.

Реалізація смуг провайдерів розміщена в extensions/qa-lab/src/providers/. Кожен провайдер володіє своїми типовими параметрами, запуском локального сервера, конфігурацією моделі Gateway, потребами в підготовці профілю автентифікації та прапорцями можливостей живого/імітаційного режиму. Спільний код набору й Gateway здійснює маршрутизацію через реєстр провайдерів замість розгалуження за назвами провайдерів.

Транспортні адаптери

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

На рівні архітектури розподіл такий:

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

Додавання каналу

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

Не додавайте новий кореневий рівень команди QA, якщо спільний хост 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 для QA, а не 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.

Пов’язана документація

• Картка оцінювання зрілості
• Пакет еталонних тестів персонального агента
• Канал QA
• Тестування
• Панель керування