extensions/qa-channel: синтетичний канал повідомлень із поверхнями DM, каналу, потоку, реакції, редагування та видалення.extensions/qa-lab: UI налагоджувача і шина QA для спостереження за транскриптом, інжектування вхідних повідомлень і експорту Markdown-звіту.extensions/qa-matrix, майбутні плагіни раннера: адаптери live-транспорту, які керують реальним каналом усередині дочірнього QA Gateway.qa/: seed-ресурси з репозиторію для стартового завдання і базових сценаріїв QA.- Mantis: перевірка до і після live-верифікації для помилок, яким потрібні реальні транспорти, скриншоти браузера, стан VM і PR-докази.
Поверхня команд
Кожен QA-потік запускається черезpnpm openclaw qa <subcommand>. Багато з них мають
аліаси скриптів pnpm qa:*; підтримуються обидві форми.
| Команда | Призначення |
|---|---|
qa run | Вбудована самоперевірка QA без --qa-profile; раннер профілю зрілості на основі таксономії з --qa-profile smoke-ci, --qa-profile release або --qa-profile all. |
qa suite | Запустити сценарії з репозиторію проти лінії QA Gateway. Аліаси: pnpm openclaw qa suite --runner multipass для одноразової Linux VM. |
qa coverage | Вивести інвентар покриття YAML-сценаріїв (--json для машинного виводу). |
qa parity-report | Порівняти два файли qa-suite-summary.json і записати агентний звіт паритету або використати --runtime-axis --token-efficiency, щоб записати звіти паритету runtime Codex-vs-OpenClaw і ефективності токенів з одного підсумку пари runtime. |
qa character-eval | Запустити character QA-сценарій на кількох live-моделях зі звітом оцінювання. Див. Звітування. |
qa manual | Запустити одноразовий промпт проти вибраної лінії провайдера/моделі. |
qa ui | Запустити UI налагоджувача QA і локальну шину QA (аліас: pnpm qa:lab:ui). |
qa docker-build-image | Зібрати попередньо підготовлений Docker-образ QA. |
qa docker-scaffold | Записати docker-compose scaffold для QA-дашборда + лінії Gateway. |
qa up | Зібрати QA-сайт, запустити Docker-backed стек, вивести 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 matrix | Лінія live-транспорту проти одноразового homeserver Tuwunel. Див. Matrix QA. |
qa telegram | Лінія live-транспорту проти реальної приватної групи Telegram. |
qa discord | Лінія live-транспорту проти реального приватного каналу гільдії Discord. |
qa slack | Лінія live-транспорту проти реального приватного каналу Slack. |
qa whatsapp | Лінія live-транспорту проти реальних облікових записів WhatsApp Web. |
qa mantis | Раннер перевірки до і після для помилок live-транспорту, з доказами статус-реакцій Discord, desktop/browser smoke Crabbox і Slack-in-VNC smoke. Див. Mantis і Runbook Mantis Slack Desktop. |
qa run на основі профілю читає належність із taxonomy.yaml, а потім передає
розв’язані сценарії через qa suite. --surface і
--category фільтрують вибраний профіль замість визначення окремих ліній.
Отриманий qa-evidence.json містить підсумок scorecard профілю з
кількістю вибраних категорій і відсутніми ID покриття; окремі записи доказів
залишаються джерелом істини для тестів, ролей покриття і результатів.
ID покриття функцій таксономії є точними цілями доказів, а не псевдонімами. Первинне
покриття сценаріїв виконує відповідні ID; вторинне покриття залишається дорадчим.
ID покриття використовують форму з крапками namespace.behavior із сегментами
нижнього регістру з літер/цифр/дефісів; ID профілю, поверхні та категорії все ще можуть використовувати
наявні дефісні або крапкові ID таксономії.
Стислі докази опускають execution для кожного запису і встановлюють evidenceMode: "slim";
smoke-ci типово використовує стислий режим, а --evidence-mode full відновлює повні записи:
smoke-ci для детермінованого доказу профілю з mock-провайдерами моделей і
локальними серверами провайдерів Crabline. Використовуйте release для доказу Stable/LTS проти live
каналів. Використовуйте all лише для явних запусків доказів повної таксономії; він вибирає
кожну активну категорію зрілості й може передаватися через workflow QA Profile Evidence з qa_profile=all. Коли команді також потрібен кореневий профіль OpenClaw,
розмістіть кореневий профіль перед командою QA:
Потік оператора
Поточний потік оператора QA — це двопанельний QA-сайт:- Ліворуч: дашборд Gateway (Control UI) з агентом.
- Праворуч: QA Lab, що показує Slack-подібний транскрипт і план сценарію.
qa:lab:up:fast тримає Docker-сервіси на попередньо зібраному образі й bind-mount-ить
extensions/qa-lab/web/dist у контейнер qa-lab. qa:lab:watch
перезбирає цей бандл при зміні, а браузер автоматично перезавантажується, коли змінюється
хеш ресурсів QA Lab.
Для локального OpenTelemetry signal smoke запустіть:
otel-trace-smoke
з увімкненим плагіном diagnostics-otel, а потім перевіряє, що трасування,
метрики й логи експортовано. Він декодує експортовані protobuf trace spans
і перевіряє release-critical форму:
openclaw.run, openclaw.harness.run, span виклику моделі за найновішою GenAI semantic-convention,
openclaw.context.assembled і openclaw.message.delivery
мають бути присутні. Smoke примусово встановлює
OTEL_SEMCONV_STABILITY_OPT_IN=gen_ai_latest_experimental, тому span виклику моделі
має використовувати назву {gen_ai.operation.name} {gen_ai.request.model};
виклики моделі не мають експортувати StreamAbandoned на успішних ходах; сирі diagnostic IDs і
атрибути openclaw.content.* мають залишатися поза трасуванням. Сирі OTLP
payloads не мають містити prompt sentinel, response sentinel або ключ QA-сесії.
Він записує otel-smoke-summary.json поруч з артефактами QA suite.
Для OpenTelemetry smoke з collector запустіть:
docker-prometheus-smoke з увімкненим
diagnostics-prometheus, перевіряє, що неавтентифіковані scrapes відхиляються,
а потім перевіряє, що автентифікований scrape містить критично важливі для релізу
сімейства метрик без вмісту промптів, вмісту відповідей, сирих діагностичних
ідентифікаторів, токенів автентифікації або локальних шляхів.
Щоб запустити обидва observability-smoke послідовно, використайте:
qa. Використовуйте pnpm qa:otel:smoke, pnpm qa:prometheus:smoke
або pnpm qa:observability:smoke зі зібраного вихідного checkout під час зміни
інструментації діагностики.
Для транспортно-реальної Matrix smoke-лінії, яка не потребує облікових даних
model-provider, запустіть швидкий профіль із детермінованим mock OpenAI provider:
qa-channel), а потім записує Markdown-звіт, JSON-підсумок, артефакт observed-events і об’єднаний журнал виводу в .artifacts/qa-e2e/matrix-<timestamp>/.
Сценарії покривають транспортну поведінку, яку unit-тести не можуть довести end to end: mention gating, allow-bot policies, allowlists, top-level і threaded replies, DM routing, reaction handling, inbound edit suppression, restart replay dedupe, homeserver interruption recovery, approval metadata delivery, media handling, а також потоки Matrix E2EE bootstrap/recovery/verification. Профіль E2EE CLI також проганяє openclaw matrix encryption setup і команди verification через той самий одноразовий homeserver перед перевіркою відповідей gateway.
Discord також має Mantis-only opt-in сценарії для відтворення помилок. Використовуйте
--scenario discord-status-reactions-tool-only для явної часової шкали status reaction
або --scenario discord-thread-reply-filepath-attachment, щоб створити
справжній Discord thread і перевірити, що message.thread-reply зберігає
вкладення filePath. Ці сценарії не входять до стандартної live Discord lane,
бо це before/after repro probes, а не широке smoke-покриття.
Thread-attachment Mantis workflow також може додати відео-свідчення Discord Web
від залогіненого користувача, коли MANTIS_DISCORD_VIEWER_CHROME_PROFILE_DIR або
MANTIS_DISCORD_VIEWER_CHROME_PROFILE_TGZ_B64 налаштовано в QA
середовищі. Цей viewer profile призначений лише для візуального захоплення; рішення
pass/fail усе одно надходить від Discord REST oracle.
CI використовує ту саму поверхню команд у .github/workflows/qa-live-transports-convex.yml.
Заплановані й стандартні ручні запуски виконують швидкий Matrix profile з
QA-наданими live-frontier credentials, --fast і
OPENCLAW_QA_MATRIX_NO_REPLY_WINDOW_MS=3000. Ручний matrix_profile=all
розгалужується на п’ять profile shards.
Для транспортно-реальних Telegram, Discord, Slack і WhatsApp smoke lanes:
slack-qa/, slack-desktop-smoke.png і slack-desktop-smoke.mp4, коли
video capture доступний, назад до каталогу артефактів Mantis. Crabbox
desktop/browser leases заздалегідь надають capture tools і browser/native-build helper
packages, тому сценарій має встановлювати fallback лише на старіших
leases. Mantis повідомляє загальний і пофазний час у
mantis-slack-desktop-smoke-report.md, щоб повільні запуски показували, куди
пішов час: lease warmup, credential acquisition, remote setup або artifact copy.
Повторно використовуйте --lease-id <cbx_...> після ручного входу в Slack Web
через VNC; повторно використані leases також зберігають теплим pnpm store cache
Crabbox. Стандартний --hydrate-mode source перевіряє з вихідного checkout і
запускає install/build усередині VM. Використовуйте --hydrate-mode prehydrated
лише коли повторно використаний remote workspace уже має node_modules і
зібраний dist/; цей режим пропускає дорогий крок install/build і fail closed,
коли workspace не готовий. З --gateway-setup Mantis залишає постійний
OpenClaw Slack gateway запущеним усередині VM на порту 38973; без нього
команда запускає звичайну bot-to-bot Slack QA lane і завершується після
artifact capture.
Щоб довести native Slack approval UI з desktop evidence, запустіть Mantis approval
checkpoint mode:
--gateway-setup. Він запускає Slack
approval scenarios, відхиляє non-approval scenario ids, очікує на кожному pending і
resolved approval state, рендерить спостережене Slack API message у
approval-checkpoints/<scenario>-pending.png і
approval-checkpoints/<scenario>-resolved.png, а потім завершується з помилкою,
якщо будь-який checkpoint, message evidence, acknowledgement або rendered screenshot
відсутній чи порожній. Cold CI leases усе ще можуть показувати Slack sign-in у
slack-desktop-smoke.png; approval checkpoint images є візуальним proof для цієї lane.
Operator checklist, команда GitHub workflow dispatch, evidence-comment
contract, hydrate-mode decision table, timing interpretation і кроки failure
handling містяться в Mantis Slack Desktop Runbook.
Для desktop task у стилі agent/CV запустіть:
visual-task орендує або повторно використовує desktop/browser машину Crabbox,
запускає crabbox record --while, керує видимим browser через вкладений
visual-driver, захоплює visual-task.png, запускає openclaw infer image describe
для screenshot, коли вибрано --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, vision prompt запитує структурований JSON
verdict і проходить лише тоді, коли модель повідомляє про позитивні видимі докази;
негативна відповідь, яка лише цитує цільовий текст, провалює assertion.
Використовуйте --vision-mode metadata для no-model smoke, що доводить desktop,
browser, screenshot і video plumbing без виклику image-understanding
provider. Recording є обов’язковим артефактом для visual-task; якщо Crabbox не
записує непорожній visual-task.mp4, завдання завершується з помилкою навіть
коли visual driver пройшов. У разі помилки Mantis зберігає lease для VNC, якщо
завдання ще не пройшло і --keep-lease не було встановлено.
Перед використанням pooled live credentials запустіть:
Live transport coverage
Live transport lanes мають один спільний контракт замість того, щоб кожна вигадувала власну форму списку сценаріїв.qa-channel є широким synthetic product-behavior suite і не є частиною live transport coverage matrix.
Live transport runners мають імпортувати спільні scenario ids, baseline
coverage helpers і scenario-selection helper з
openclaw/plugin-sdk/qa-live-transport-scenarios.
| Lane | Canary | Mention gating | Bot-to-bot | Allowlist block | Top-level reply | Quote reply | Restart resume | Thread follow-up | Thread isolation | Reaction observation | Help command | Native command registration |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Matrix | x | x | x | x | x | x | x | x | x | |||
| Telegram | x | x | x | x | ||||||||
| Discord | x | x | x | x | ||||||||
| Slack | x | x | x | x | x | x | x | x | ||||
| x | x | x | x | x | x | x | x |
qa-channel як широкий product-behavior suite, тоді як Matrix,
Telegram та інші live transports мають один явний transport-contract checklist.
Для одноразової Linux VM lane без залучення Docker до QA path запустіть:
qa suite, а потім копіює звичайний QA report і
summary назад у .artifacts/qa-e2e/... на host.
Він повторно використовує ту саму scenario-selection behavior, що й qa suite
на host. Host і Multipass suite runs за замовчуванням виконують кілька вибраних
сценаріїв паралельно з ізольованими gateway workers. qa-channel за замовчуванням
має concurrency 4, обмежену кількістю вибраних сценаріїв. Використовуйте
--concurrency <count>, щоб налаштувати worker count, або --concurrency 1
для serial execution.
Використовуйте --pack personal-agent, щоб запустити personal assistant benchmark pack. Pack
selector є additive з повторюваними прапорцями --scenario: explicit scenarios
запускаються першими, потім pack scenarios запускаються в pack order із видаленням
duplicates.
Використовуйте --pack observability, коли custom QA runner уже надає
OpenTelemetry collector setup і хоче вибрати OpenTelemetry та Prometheus
diagnostics smoke scenarios разом.
Команда завершується з ненульовим кодом, коли будь-який сценарій не проходить.
Використовуйте --allow-failures, коли потрібні артефакти без failing exit code.
Live runs передають підтримувані QA auth inputs, практичні для guest:
env-based provider keys, QA live provider config path і CODEX_HOME, коли він
присутній. Тримайте --output-dir під коренем репозиторію, щоб guest міг
записувати назад через змонтований workspace.
Довідник QA для Telegram, Discord, Slack і WhatsApp
Matrix має окрему сторінку через кількість сценаріїв і Docker-забезпечення homeserver. Telegram, Discord, Slack і WhatsApp запускаються проти попередньо наявних реальних транспортів, тому їхній довідник розміщено тут.Спільні прапорці CLI
Ці смуги реєструються черезextensions/qa-lab/src/live-transports/shared/live-transport-cli.ts і приймають однакові прапорці:
| Прапорець | Типове значення | Опис |
|---|---|---|
--scenario <id> | - | Запустити лише цей сценарій. Можна повторювати. |
--output-dir <path> | <repo>/.artifacts/qa-e2e/<transport>-<timestamp> | Куди записуються звіти, зведення, докази, специфічні для транспорту артефакти та вихідний журнал. Відносні шляхи розв’язуються відносно --repo-root. |
--repo-root <path> | process.cwd() | Корінь репозиторію під час виклику з нейтрального cwd. |
--sut-account <id> | sut | Тимчасовий ідентифікатор облікового запису в конфігурації QA Gateway. |
--provider-mode <mode> | live-frontier | mock-openai або live-frontier (застарілий live-openai усе ще працює). |
--model <ref> / --alt-model <ref> | типове значення провайдера | Посилання на основну/альтернативну модель. |
--fast | вимкнено | Швидкий режим провайдера там, де підтримується. |
--credential-source <env|convex> | env | Див. пул облікових даних Convex. |
--credential-role <maintainer|ci> | ci у CI, інакше maintainer | Роль, що використовується, коли --credential-source convex. |
--allow-failures записує артефакти без встановлення коду завершення як помилкового.
QA Telegram
@BotFather.
Обов’язкові env, коли --credential-source env:
OPENCLAW_QA_TELEGRAM_GROUP_ID- числовий ідентифікатор чату (рядок).OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKENOPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN
extensions/qa-lab/src/live-transports/telegram/telegram-live.runtime.ts):
telegram-canarytelegram-mention-gatingtelegram-mentioned-message-replytelegram-help-commandtelegram-commands-commandtelegram-tools-compact-commandtelegram-whoami-commandtelegram-status-commandtelegram-repeated-command-authorizationtelegram-other-bot-command-gatingtelegram-context-commandtelegram-current-session-status-tooltelegram-reply-chain-exact-markertelegram-stream-final-single-messagetelegram-long-final-reuses-previewtelegram-long-final-three-chunks
mock-openai також включають детерміновані перевірки ланцюжка відповідей і потокової передачі фінального повідомлення. telegram-current-session-status-tool залишається опційним, бо він стабільний лише коли запускається в потоці безпосередньо після canary, а не після довільних відповідей нативних команд. Використайте pnpm openclaw qa telegram --list-scenarios --provider-mode mock-openai, щоб надрукувати поточний поділ типових/опційних сценаріїв із regression refs.
Вихідні артефакти:
telegram-qa-report.mdqa-evidence.json- записи доказів для перевірок живого транспорту, включно з полями профілю, покриття, провайдера, каналу, артефактів, результату та RTT.
qa-evidence.json у result.timing для вибраної перевірки RTT.
OPENCLAW_QA_CREDENTIAL_SOURCE=convex, пакетна жива обгортка орендує облікові дані kind: "telegram", експортує env орендованих групи/драйвера/SUT-бота в запуск установленого пакета, надсилає Heartbeat для оренди та звільняє її під час завершення. Пакетна обгортка типово виконує 20 перевірок RTT для telegram-mentioned-message-reply, має 30-секундний тайм-аут RTT і роль 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
/help у Discord, а також опційні сценарії доказів Mantis.
Обов’язкові env, коли --credential-source env:
OPENCLAW_QA_DISCORD_GUILD_IDOPENCLAW_QA_DISCORD_CHANNEL_IDOPENCLAW_QA_DISCORD_DRIVER_BOT_TOKENOPENCLAW_QA_DISCORD_SUT_BOT_TOKENOPENCLAW_QA_DISCORD_SUT_APPLICATION_ID- має збігатися з ідентифікатором користувача SUT-бота, поверненим Discord (інакше смуга швидко завершується помилкою).
OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1зберігає тіла повідомлень в артефактах спостережених повідомлень.OPENCLAW_QA_DISCORD_VOICE_CHANNEL_IDвибирає голосовий/stage-канал дляdiscord-voice-autojoin; без нього сценарій вибирає перший видимий голосовий/stage-канал для SUT-бота.
extensions/qa-lab/src/live-transports/discord/discord-live.runtime.ts:36):
discord-canarydiscord-mention-gatingdiscord-native-help-command-registrationdiscord-voice-autojoin- опційний голосовий сценарій. Запускається самостійно, вмикаєchannels.discord.voice.autoJoinі перевіряє, що поточний голосовий стан SUT-бота в Discord є цільовим голосовим/stage-каналом. Облікові дані Discord у Convex можуть містити опційнийvoiceChannelId; інакше runner виявляє перший видимий голосовий/stage-канал у гільдії.discord-status-reactions-tool-only- опційний сценарій Mantis. Запускається самостійно, бо перемикає SUT у режим постійно ввімкнених відповідей гільдії лише інструментами зmessages.statusReactions.enabled=true, а потім збирає часову шкалу REST-реакцій плюс візуальні артефакти HTML/PNG. Звіти Mantis до/після також зберігають MP4-артефакти, надані сценарієм, якbaseline.mp4іcandidate.mp4.
discord-qa-report.mdqa-evidence.json- записи доказів для перевірок живого транспорту.discord-qa-observed-messages.json- тіла редагуються, якщо не встановленоOPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1.discord-qa-reaction-timelines.jsonіdiscord-status-reactions-tool-only-timeline.png, коли запускається сценарій статусних реакцій.
QA Slack
--credential-source env:
OPENCLAW_QA_SLACK_CHANNEL_IDOPENCLAW_QA_SLACK_DRIVER_BOT_TOKENOPENCLAW_QA_SLACK_SUT_BOT_TOKENOPENCLAW_QA_SLACK_SUT_APP_TOKEN
OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1зберігає тіла повідомлень в артефактах спостережених повідомлень.OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIRвмикає візуальні контрольні точки схвалення для Mantis. Runner записує<scenario>.pending.jsonі<scenario>.resolved.json, а потім очікує відповідні файли.ack.json.OPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_TIMEOUT_MSперевизначає тайм-аут підтвердження контрольної точки. Типове значення —120000.
extensions/qa-lab/src/live-transports/slack/slack-live.runtime.ts):
slack-canaryslack-mention-gatingslack-allowlist-blockslack-top-level-reply-shapeslack-restart-resumeslack-thread-follow-upslack-thread-isolationslack-approval-exec-native- опційний сценарій нативного схвалення exec у Slack. Запитує схвалення exec через Gateway, перевіряє, що повідомлення Slack має нативні кнопки схвалення, розв’язує його та перевіряє розв’язане оновлення Slack.slack-approval-plugin-native- опційний сценарій нативного схвалення plugin у Slack. Вмикає переспрямування схвалень exec і plugin разом, щоб події plugin не пригнічувалися маршрутизацією схвалень exec, а потім перевіряє той самий шлях нативного UI Slack pending/resolved.
slack-qa-report.mdqa-evidence.json- записи доказів для перевірок живого транспорту.slack-qa-observed-messages.json- тіла редагуються, якщо не встановленоOPENCLAW_QA_SLACK_CAPTURE_CONTENT=1.approval-checkpoints/- лише коли Mantis встановлюєOPENCLAW_QA_SLACK_APPROVAL_CHECKPOINT_DIR; містить JSON контрольних точок, JSON підтверджень і знімки екрана pending/resolved.
Налаштування робочого простору Slack
Смузі потрібні дві окремі програми Slack в одному робочому просторі, а також канал, учасниками якого є обидва боти:channelId- ідентифікаторCxxxxxxxxxxканалу, до якого запрошено обох ботів. Використовуйте виділений канал; смуга публікує повідомлення під час кожного запуску.driverBotToken- токен бота (xoxb-...) програми Driver.sutBotToken- токен бота (xoxb-...) програми SUT, яка має бути окремою програмою Slack від драйвера, щоб її ідентифікатор користувача-бота був іншим.sutAppToken- токен рівня програми (xapp-...) програми SUT зconnections:write, який використовується Socket Mode, щоб програма SUT могла отримувати події.
extensions/slack/src/setup-shared.ts:10) до дозволів і подій, охоплених живим набором QA Slack. Для налаштування виробничого каналу таким, яким його бачать користувачі, див. швидке налаштування каналу Slack; пара QA Driver/SUT навмисно окрема, бо смузі потрібні два різні ідентифікатори користувачів-ботів в одному робочому просторі.
1. Створіть програму Driver
Перейдіть до api.slack.com/apps → Create New App → From a manifest → виберіть робочий простір QA, вставте наведений нижче маніфест, а потім Install to Workspace:
xoxb-...) - це стане driverBotToken. Драйверу потрібно лише публікувати повідомлення й ідентифікувати себе; події та Socket Mode не потрібні.
2. Створіть застосунок SUT
Повторіть Create New App → From a manifest у тому самому робочому просторі. Цей застосунок QA навмисно використовує вужчу версію виробничого маніфесту вбудованого Slack-плагіна (extensions/slack/src/setup-shared.ts:10): області доступу й події для реакцій пропущені, бо live-набір QA для Slack ще не покриває обробку реакцій.
- Install to Workspace → скопіюйте Bot User OAuth Token → це стане
sutBotToken. - Basic Information → App-Level Tokens → Generate Token and Scopes → додайте область доступу
connections:write→ збережіть → скопіюйте значенняxapp-...→ це станеsutAppToken.
auth.test для кожного токена. Runtime розрізняє драйвер і SUT за ідентифікатором користувача; повторне використання одного застосунку для обох одразу зламає фільтрацію згадок.
3. Створіть канал
У робочому просторі QA створіть канал (наприклад, #openclaw-qa) і запросіть обох ботів із самого каналу:
Cxxxxxxxxxx з channel info → About → Channel ID - це стане channelId. Публічний канал підходить; якщо ви використовуєте приватний канал, обидва застосунки вже мають groups:history, тому читання історії в harness усе одно працюватиме.
4. Зареєструйте облікові дані
Є два варіанти. Використовуйте змінні середовища для налагодження на одній машині (задайте чотири змінні OPENCLAW_QA_SLACK_* і передайте --credential-source env) або засійте спільний пул Convex, щоб CI та інші мейнтейнери могли брати їх в оренду.
Для пулу Convex запишіть чотири поля у JSON-файл:
OPENCLAW_QA_CONVEX_SITE_URL і OPENCLAW_QA_CONVEX_SECRET_MAINTAINER експортовано у вашій shell, зареєструйте й перевірте:
count: 1, status: "active", без поля lease.
5. Перевірте end to end
Запустіть лінію локально, щоб підтвердити, що обидва боти можуть спілкуватися один з одним через broker:
slack-qa-report.md показує статус pass для slack-canary і slack-mention-gating. Якщо лінія зависає приблизно на 90 секунд і завершується з Convex credential pool exhausted for kind "slack", пул або порожній, або всі рядки вже орендовані - qa credentials list --kind slack --status all --json покаже, що саме.
WhatsApp QA
--credential-source env:
OPENCLAW_QA_WHATSAPP_DRIVER_PHONE_E164OPENCLAW_QA_WHATSAPP_SUT_PHONE_E164OPENCLAW_QA_WHATSAPP_DRIVER_AUTH_ARCHIVE_BASE64OPENCLAW_QA_WHATSAPP_SUT_AUTH_ARCHIVE_BASE64
OPENCLAW_QA_WHATSAPP_GROUP_JIDвмикає групові сценарії, як-отwhatsapp-mention-gating,whatsapp-group-pending-history-context,whatsapp-broadcast-group-fanout,whatsapp-group-activation-always,whatsapp-group-reply-to-bot-triggers, сценарії групових дій, медіа й опитувань, а такожwhatsapp-group-allowlist-block.OPENCLAW_QA_WHATSAPP_CAPTURE_CONTENT=1зберігає тіла повідомлень в артефактах observed-message.
extensions/qa-lab/src/live-transports/whatsapp/whatsapp-live.runtime.ts):
- Базова перевірка й групова фільтрація:
whatsapp-canary,whatsapp-pairing-block,whatsapp-mention-gating,whatsapp-group-pending-history-context,whatsapp-group-activation-always,whatsapp-group-reply-to-bot-triggers,whatsapp-top-level-reply-shape,whatsapp-restart-resume,whatsapp-group-allowlist-block. - Нативні команди:
whatsapp-help-command,whatsapp-status-command,whatsapp-commands-command,whatsapp-tools-compact-command,whatsapp-whoami-command,whatsapp-context-command,whatsapp-native-new-command. - Поведінка відповідей і фінального виводу:
whatsapp-tool-only-usage-footer,whatsapp-reply-to-message,whatsapp-group-reply-to-message,whatsapp-reply-to-mode-batched,whatsapp-reply-context-isolation,whatsapp-reply-delivery-shape,whatsapp-stream-final-message-accounting. - Дії з повідомленнями на шляху користувача:
whatsapp-agent-message-action-reactпочинається з реального DM від драйвера, дозволяє моделі викликати інструмент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. - Груповий fanout:
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-group-outbound-media,whatsapp-group-outbound-poll,whatsapp-message-actions,whatsapp-reply-context-isolation,whatsapp-reply-delivery-shape. Вони навмисно обходять prompting моделі та доводять детерміновані контракти 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.
live-frontier
залишається малою - 10 сценаріїв для швидкого smoke-покриття. Стандартна
лінія mock-openai запускає 44 детерміновані сценарії через реальний транспорт WhatsApp,
мокаючи лише вивід моделі. Сценарії схвалень і кілька важчих або блокувальних перевірок
залишаються явними за ідентифікатором сценарію.
Драйвер WhatsApp QA спостерігає структуровані live-події (text, media,
location, reaction і poll) і може активно надсилати медіа, опитування,
контакти, локації та стікери. QA Lab імпортує цей драйвер через
поверхню пакета @openclaw/whatsapp/api.js, а не звертається до приватних
runtime-файлів WhatsApp. Для групових спостережень fromJid є JID групи, тоді як
participantJid і fromPhoneE164 ідентифікують учасника-відправника. Вміст
повідомлень за замовчуванням редагується. Прямі перевірки Gateway
для опитування, upload-file, медіа, групового опитування, групових медіа й reply-shape є перевірками контракту транспорту/API;
вони не трактуються як доказ того, що користувацький prompt змусив агента вибрати
ту саму дію. Доказ дії на шляху користувача походить зі сценаріїв, як-от
whatsapp-agent-message-action-react і
whatsapp-group-agent-message-action-react, де драйвер надсилає звичайне
повідомлення WhatsApp, а QA Lab спостерігає отриманий нативний артефакт WhatsApp.
Звіти WhatsApp включають позицію кожного сценарію (user-path, direct-gateway
або native-approval), щоб докази не можна було помилково сприйняти як сильніший контракт,
ніж вони фактично доводять.
Вихідні артефакти:
whatsapp-qa-report.mdqa-evidence.json- записи доказів для перевірок live-транспорту.whatsapp-qa-observed-messages.json- тіла редагуються, якщо не заданоOPENCLAW_QA_WHATSAPP_CAPTURE_CONTENT=1.
Пул облікових даних Convex
Лінії Telegram, Discord, Slack і WhatsApp можуть орендувати облікові дані зі спільного пулу Convex замість читання наведених вище змінних середовища. Передайте--credential-source convex (або задайте OPENCLAW_QA_CREDENTIAL_SOURCE=convex); QA Lab отримує ексклюзивну оренду, надсилає для неї Heartbeat протягом виконання й звільняє її під час завершення. Типи пулу: "telegram", "discord", "slack" і "whatsapp".
Форми payload, які broker перевіряє на admin/add:
- Telegram (
kind: "telegram"):{ groupId: string, driverToken: string, sutToken: string }-groupIdмає бути числовим рядком chat-id. - Реальний користувач 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 не повинні отримувати цей kind. - Discord (
kind: "discord"):{ guildId: string, channelId: string, driverBotToken: string, sutBotToken: string, sutApplicationId: string }. - WhatsApp (
kind: "whatsapp"):{ driverPhoneE164: string, sutPhoneE164: string, driverAuthArchiveBase64: string, sutAuthArchiveBase64: string, groupJid?: string }- номери телефонів мають бути різними рядками E.164.
telegram-user і для TDLib CLI driver, і для свідка Telegram Desktop,
а потім звільняє її після публікації доказу.
Коли PR потребує детермінованого візуального diff, Mantis може використовувати ту саму відповідь mock-моделі
на main і на head PR, поки змінюється форматер Telegram або шар доставлення.
Типові параметри захоплення налаштовані для коментарів PR: стандартний клас Crabbox,
запис desktop із 24fps, motion GIF із 24fps і ширина preview 1920px.
Коментарі before/after мають публікувати чистий bundle, що містить лише
потрібні GIF.
Лінії Slack також можуть використовувати pool. Перевірки форми payload Slack наразі живуть у Slack QA runner, а не в broker; використовуйте { channelId: string, driverBotToken: string, sutBotToken: string, sutAppToken: string }, з id каналу Slack на кшталт Cxxxxxxxxxx. Див. Налаштування workspace Slack для provisioning app і scope.
Операційні env vars і контракт endpoint Convex broker живуть у Тестування → Спільні облікові дані Telegram через Convex (назва розділу передує multi-channel pool; семантика оренди спільна для всіх kind).
Seeds із repo
Seed assets живуть уqa/:
qa/scenarios/index.yamlqa/scenarios/<theme>/*.yaml
qa-lab має залишатися загальним runner сценаріїв YAML. Кожен YAML-файл сценарію є
джерелом істини для одного тестового запуску й має визначати:
- top-level
title - metadata
scenario - необов’язкові metadata category, capability, lane і risk у
scenario - refs docs і code у
scenario - необов’язкові requirements Plugin у
scenario - необов’язковий patch config Gateway у
scenario - виконуваний top-level
flowдля flow-сценаріїв абоscenario.execution.kind/scenario.execution.pathдля сценаріїв Vitest і Playwright
flow, може залишатися загальною
і наскрізною. Наприклад, YAML-сценарії можуть поєднувати helpers транспортного боку
з helpers браузерного боку, які керують вбудованим Control UI через
seam Gateway browser.request без додавання special-case runner.
Файли сценаріїв слід групувати за product capability, а не за папкою source tree.
Зберігайте scenario IDs стабільними під час переміщення файлів; використовуйте docsRefs і codeRefs
для traceability реалізації.
Baseline-список має залишатися достатньо широким, щоб покривати:
- DM і channel chat
- поведінку thread
- lifecycle message action
- callbacks cron
- memory recall
- перемикання model
- handoff subagent
- читання repo і docs
- одне невелике build-завдання, таке як Lobster Invaders
Лінії provider mock
qa suite має дві локальні лінії provider mock:
mock-openai— scenario-aware mock OpenClaw. Він залишається типовою детермінованою mock-лінією для repo-backed QA і parity gates.aimockзапускає provider server на базі AIMock для експериментального protocol, fixture, record/replay і chaos coverage. Він є додатковим і не замінює dispatcher сценаріївmock-openai.
extensions/qa-lab/src/providers/.
Кожен provider володіє своїми defaults, запуском local server, config model Gateway,
потребами staging auth-profile і flags live/mock capability. Спільний код suite і
gateway має маршрутизувати через registry provider, а не розгалужуватися за
іменами provider.
Transport adapters
qa-lab володіє загальним transport seam для YAML QA scenarios. qa-channel є
синтетичним default. crabline запускає локальні provider-shaped servers і виконує
звичайні channel plugins OpenClaw проти них. live зарезервовано для реальних
облікових даних provider і зовнішніх channels.
На рівні архітектури поділ такий:
qa-labволодіє загальним виконанням scenario, concurrency worker, записом artifacts і reporting.- Transport adapter володіє config Gateway, readiness, inbound і outbound observation, transport actions і нормалізованим transport state.
- YAML scenario files у
qa/scenarios/визначають тестовий запуск;qa-labнадає повторно використовувану runtime-поверхню, яка їх виконує.
Додавання channel
Додавання channel до YAML QA system потребує реалізації channel плюс scenario pack, який перевіряє контракт channel. Для smoke CI coverage додайте відповідний local provider server Crabline і expose його через drivercrabline.
Не додавайте новий top-level QA command root, коли спільний host qa-lab може володіти flow.
qa-lab володіє спільною host-механікою:
- command root
openclaw qa - startup і teardown suite
- worker concurrency
- запис artifact
- генерація report
- виконання scenario
- compatibility aliases для старіших scenarios
qa-channel
- як
openclaw qa <runner>mount під спільним rootqa - як gateway configured для цього transport
- як перевіряється readiness
- як inject inbound events
- як observe outbound messages
- як expose transcripts і normalized transport state
- як виконуються transport-backed actions
- як обробляється transport-specific reset або cleanup
- Залиште
qa-labвласником спільного rootqa. - Реалізуйте transport runner на shared host seam
qa-lab. - Тримайте transport-specific mechanics всередині runner plugin або channel harness.
- Mount runner як
openclaw qa <runner>замість реєстрації конкурентної root command. Runner plugins мають оголошуватиqaRunnersуopenclaw.plugin.jsonі експортувати відповідний масивqaRunnerCliRegistrationsзruntime-api.ts. Тримайтеruntime-api.tsлегким; lazy CLI і виконання runner мають залишатися за окремими entrypoints. - Створіть або адаптуйте YAML scenarios у themed directories
qa/scenarios/. - Використовуйте generic scenario helpers для нових scenarios.
- Зберігайте наявні compatibility aliases робочими, якщо repo не виконує intentional migration.
- Якщо behavior можна виразити один раз у
qa-lab, помістіть його вqa-lab. - Якщо behavior залежить від одного channel transport, тримайте його в цьому runner plugin або plugin harness.
- Якщо scenario потребує нової capability, яку може використовувати більше ніж один channel, додайте generic helper замість channel-specific branch у
suite.ts. - Якщо behavior має сенс лише для одного transport, залиште scenario transport-specific і явно зафіксуйте це в scenario contract.
Імена scenario helper
Бажані generic helpers для нових scenarios:waitForTransportReadywaitForChannelReadyinjectInboundMessageinjectOutboundMessagewaitForTransportOutboundMessagewaitForChannelOutboundMessagewaitForNoTransportOutboundgetTransportSnapshotreadTransportMessagereadTransportTranscriptformatTransportTranscriptresetTransport
waitForQaChannelReady, waitForOutboundMessage, waitForNoOutbound, formatConversationTranscript, resetBus - але нові scenarios слід author із generic names. Aliases існують, щоб уникнути flag-day migration, а не як модель на майбутнє.
Reporting
qa-lab експортує Markdown protocol report зі спостережуваної bus timeline.
Report має відповідати:
- Що спрацювало
- Що не спрацювало
- Що залишилося заблокованим
- Які follow-up scenarios варто додати
pnpm openclaw qa coverage (додайте --json для machine-readable output).
Коли вибираєте focused proof для touched behavior або file path, виконайте pnpm openclaw qa coverage --match <query>.
Match report шукає metadata scenario, docs refs, code refs, coverage IDs, plugins і provider requirements, а потім друкує відповідні targets qa suite --scenario ....
Кожен запуск qa suite записує top-level artifacts qa-evidence.json,
qa-suite-summary.json і qa-suite-report.md для вибраного
scenario set. Scenarios, які оголошують execution.kind: vitest або
execution.kind: playwright, виконують відповідний test path і також записують
per-scenario logs. Scenarios, які оголошують execution.kind: script, запускають
evidence producer у execution.path через node --import tsx (з
${outputDir} і ${scenarioId}, розгорнутими в execution.args); producer
записує власний qa-evidence.json, чиї entries імпортуються в suite
output і чиї artifact paths resolve відносно цього producer
qa-evidence.json. Коли до qa suite доходять через
qa run --qa-profile, той самий qa-evidence.json також містить summary
profile scorecard для вибраних taxonomy categories.
Сприймайте це як discovery aid, а не як заміну gate; вибраному scenario все ще потрібен правильний provider mode, live transport, Multipass, Testbox або release lane для behavior under test.
Для контексту scorecard див. Maturity scorecard.
Для перевірок character і style запустіть той самий scenario на кількох live model
refs і запишіть judged Markdown report:
SOUL.md, а потім виконувати звичайні користувацькі ходи, як-от чат, допомога з робочим простором і невеликі файлові завдання. Моделі-кандидату не слід повідомляти, що її оцінюють. Команда зберігає кожен повний транскрипт, записує базову статистику запуску, а потім просить моделі-судді у швидкому режимі з міркуванням xhigh, де це підтримується, ранжувати запуски за природністю, настроєм і гумором.
Використовуйте --blind-judge-models під час порівняння провайдерів: підказка для судді все одно отримує кожен транскрипт і статус запуску, але референси кандидатів замінюються нейтральними мітками, як-от candidate-01; після розбору звіт зіставляє рейтинги назад із реальними референсами.
Запуски кандидатів за замовчуванням використовують мислення high, із medium для GPT-5.5 та xhigh для старіших референсів оцінювання OpenAI, які це підтримують. Перевизначте конкретного кандидата вбудовано за допомогою
--model provider/model,thinking=<level>. --thinking <level> досі задає глобальний резервний варіант, а старішу форму --model-thinking <provider/model=level> збережено для сумісності.
Референси кандидатів OpenAI за замовчуванням використовують швидкий режим, тож пріоритетна обробка застосовується там, де провайдер її підтримує. Додайте ,fast, ,no-fast або ,fast=false вбудовано, коли окремому кандидату чи судді потрібне перевизначення. Передавайте --fast лише тоді, коли потрібно примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалості роботи кандидатів і суддів записуються у звіт для аналізу бенчмарків, але підказки для суддів явно вказують не ранжувати за швидкістю.
Запуски моделей-кандидатів і моделей-суддів за замовчуванням мають паралельність 16. Зменшуйте --concurrency або --judge-concurrency, коли обмеження провайдера або навантаження на локальний Gateway роблять запуск надто шумним.
Коли не передано жодної моделі-кандидата через --model, оцінювання персонажа за замовчуванням використовує
openai/gpt-5.5, 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, якщо не передано --model.
Коли не передано --judge-model, судді за замовчуванням використовують
openai/gpt-5.5,thinking=xhigh,fast і
anthropic/claude-opus-4-8,thinking=high.