openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(i18n): refresh uk translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-05-03 20:33:42 +00:00
parent 843132a556
commit 8ac57b5117
2 changed files with 404 additions and 387 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

420
docs/uk/concepts/mantis.md
View File

@ -1,85 +1,85 @@
---
read_when:
- Створення або запуск візуального QA в реальному часі для помилок OpenClaw
- Додавання перевірки до та після для запиту на злиття
- Додавання сценаріїв для Discord, Slack, WhatsApp або інших транспортів у реальному часі
- Створення або запуск візуального контролю якості в реальному часі для помилок OpenClaw
- Додавання перевірки «до» та «після» для запиту на злиття
- Додавання сценаріїв Discord, Slack, WhatsApp або інших живих транспортів
- Налагодження QA-запусків, які потребують знімків екрана, автоматизації браузера або доступу через VNC
summary: Mantis — це система візуальної наскрізної перевірки для відтворення помилок OpenClaw на робочих транспортах, збирання доказів до й після виправлення та прикріплення артефактів до запитів на злиття.
summary: Mantis — це система візуальної наскрізної перевірки для відтворення помилок OpenClaw на живих транспортах, фіксації доказів до та після і прикріплення артефактів до PR.
title: Богомол
x-i18n:
generated_at: "2026-05-03T17:25:30Z"
generated_at: "2026-05-03T20:32:20Z"
model: gpt-5.5
provider: openai
source_hash: 8918ce7fe1c90184a0bcfc8427f2cd90cb969e3c93027dff08506108bf19c205
source_hash: 6cbacc20df4439d579556a1a807682e08d1c3d56294ec42b324c298599ebe4bb
source_path: concepts/mantis.md
workflow: 16
---
Mantis — це система наскрізної перевірки OpenClaw для помилок, яким потрібні реальне
середовище виконання, реальний транспорт і видимий доказ. Вона запускає сценарій на відомому
помилковому ref, збирає докази, запускає той самий сценарій на кандидатному ref і
публікує порівняння як артефакти, які мейнтейнер може переглянути з PR або
Mantis — це система наскрізної перевірки OpenClaw для багів, яким потрібні справжнє
середовище виконання, справжній транспорт і видимий доказ. Вона запускає сценарій для відомого
поганого ref, збирає докази, запускає той самий сценарій для candidate ref і
публікує порівняння як артефакти, які мейнтейнер може перевірити з PR або
з локальної команди.
Mantis починається з Discord, тому що Discord дає нам цінну першу доріжку:
реальна автентифікація бота, реальні канали гільдії, реакції, потоки, нативні команди та
Mantis починає з Discord, тому що Discord дає нам цінну першу доріжку:
справжню автентифікацію бота, справжні канали guild, реакції, threads, нативні команди та
браузерний UI, де люди можуть візуально підтвердити, що показав транспорт.
## Цілі
- Відтворити помилку з GitHub issue або PR з такою самою формою транспорту, яку бачать
- Відтворити баг з GitHub issue або PR з тією самою формою транспорту, яку бачать
користувачі.
- Захопити артефакт **до** на базовому ref перед застосуванням виправлення.
- Захопити артефакт **після** на кандидатному ref після застосування виправлення.
- Використовувати детермінований оракул, коли це можливо, наприклад читання реакції Discord REST
- Зібрати артефакт **before** на baseline ref перед застосуванням виправлення.
- Зібрати артефакт **after** на candidate ref після застосування виправлення.
- Використовувати детермінований oracle, коли це можливо, наприклад читання реакції через Discord REST
або перевірку транскрипту каналу.
- Захоплювати знімки екрана, коли помилка має видиму поверхню UI.
- Запускати локально з CLI під керуванням агента та віддалено з GitHub.
- Зберігати достатньо стану машини для відновлення через VNC, коли вхід, автоматизація браузера або
автентифікація провайдера застрягає.
- Збирати знімки екрана, коли баг має видиму поверхню UI.
- Запускати локально з CLI, керованого агентом, і віддалено з GitHub.
- Зберігати достатньо стану машини для порятунку через VNC, коли login, автоматизація браузера або
auth provider застрягає.
- Публікувати стислий статус в операторський канал Discord, коли запуск заблокований,
потребує ручної допомоги через VNC або завершується.
потребує ручної допомоги VNC або завершується.
## Нецілі
- Mantis не є заміною модульним тестам. Запуск Mantis зазвичай має перетворитися
на менший регресійний тест після того, як виправлення стане зрозумілим.
- Mantis не є звичайним швидким шлюзом CI. Він повільніший, використовує live-облікові дані та
призначений для помилок, де має значення live-середовище.
- Mantis не повинен вимагати участі людини для нормальної роботи. Ручний VNC — це шлях
відновлення, а не штатний шлях.
- Mantis не зберігає сирі секрети в артефактах, журналах, знімках екрана, Markdown
звітах або коментарях PR.
- Mantis не є заміною unit tests. Запуск Mantis зазвичай має ставати
меншим regression test після того, як виправлення зрозуміле.
- Mantis не є звичайним швидким CI gate. Він повільніший, використовує live credentials і
призначений для багів, де live-середовище має значення.
- Mantis не має вимагати людину для нормальної роботи. Ручний VNC — це шлях
порятунку, а не happy path.
- Mantis не зберігає raw secrets в артефактах, logs, screenshots, Markdown
reports або PR comments.
## Власність
Mantis живе в стеку QA OpenClaw.
Mantis живе в QA stack OpenClaw.
- OpenClaw володіє середовищем виконання сценаріїв, транспортними адаптерами, схемою доказів і
локальним CLI у `pnpm openclaw qa mantis`.
- QA Lab володіє частинами live-транспортного harness, помічниками захоплення браузера та
записувачами артефактів.
- Crabbox володіє прогрітими Linux-машинами, коли потрібна віддалена VM.
- GitHub Actions володіє віддаленою точкою входу workflow та зберіганням артефактів.
- ClawSweeper володіє маршрутизацією коментарів GitHub: розбором команд мейнтейнера,
запуском workflow та публікацією фінального коментаря PR.
- Агенти OpenClaw керують Mantis через Codex, коли сценарій потребує агентного налаштування,
налагодження або звітування про застряглий стан.
- OpenClaw володіє scenario runtime, transport adapters, evidence schema та
локальним CLI під `pnpm openclaw qa mantis`.
- QA Lab володіє частинами live transport harness, browser capture helpers і
artifact writers.
- Crabbox володіє прогрітими Linux machines, коли потрібна remote VM.
- GitHub Actions володіє remote workflow entrypoint і artifact retention.
- ClawSweeper володіє маршрутизацією GitHub comments: parsing maintainer commands,
dispatching the workflow і posting the final PR comment.
- Агенти OpenClaw керують Mantis через Codex, коли scenario потребує agentic setup,
debugging або stuck-state reporting.
Ця межа тримає знання про транспорт в OpenClaw, планування машин у
Crabbox, а клей мейнтейнерського workflow у ClawSweeper.
Ця межа тримає знання про transport в OpenClaw, планування машин у
Crabbox, а workflow glue для мейнтейнерів у ClawSweeper.
## Форма команд
## Форма команди
Перша локальна команда перевіряє бота Discord, гільдію, канал, надсилання повідомлення,
надсилання реакції та шлях артефактів:
Перша локальна команда перевіряє Discord bot, guild, channel, message send,
reaction send і artifact path:
```bash
pnpm openclaw qa mantis discord-smoke \
--output-dir .artifacts/qa-e2e/mantis/discord-smoke
```
Пізніший runner для до і після має приймати таку форму:
Локальний runner before і after приймає таку форму:
```bash
pnpm openclaw qa mantis run \
@ -90,17 +90,39 @@ pnpm openclaw qa mantis run \
--output-dir .artifacts/qa-e2e/mantis/local-discord-status-reactions
```
Smoke-workflow GitHub — це `Mantis Discord Smoke`. GitHub workflow до і після
для першого реального сценарію — `Mantis Discord Status Reactions`. Він
Runner створює відокремлені baseline і candidate worktrees під output
directory, installs dependencies, builds each ref, runs the scenario with
`--allow-failures`, потім записує `baseline/`, `candidate/`, `comparison.json`,
і `mantis-report.md`. Для першого Discord scenario успішна verification
означає, що baseline status — `fail`, а candidate status — `pass`.
GitHub smoke workflow — `Mantis Discord Smoke`. Workflow before і after GitHub
для першого справжнього scenario — `Mantis Discord Status Reactions`. Він
приймає:
- `baseline_ref`: ref, на якому очікується відтворення поведінки лише queued.
- `candidate_ref`: ref, на якому очікується показ `queued -> thinking -> done`.
- `baseline_ref`: ref, який має відтворити queued-only behavior.
- `candidate_ref`: ref, який має показати `queued -> thinking -> done`.
Він checkout-ить ref harness workflow, збирає окремі worktree baseline і candidate,
запускає `discord-status-reactions-tool-only` проти кожного worktree та
завантажує `baseline/`, `candidate/`, `comparison.json` і `mantis-report.md` як
артефакти Actions.
Він checks out workflow harness ref, builds separate baseline and candidate
worktrees, runs `discord-status-reactions-tool-only` against each worktree, and
uploads `baseline/`, `candidate/`, `comparison.json`, and `mantis-report.md` as
Actions artifacts.
Також можна запустити status-reactions run напряму з PR comment:
```text
@Mantis discord status reactions
```
Comment trigger навмисно вузький. Він запускається лише для pull request
comments від користувачів із write, maintain або admin access і розпізнає лише
Discord status-reaction requests. За замовчуванням він використовує відомий поганий baseline ref
і поточний PR head SHA як candidate. Maintainers можуть override будь-який
ref:
```text
@Mantis discord status reactions baseline=origin/main candidate=HEAD
```
Приклади команд ClawSweeper:
@ -109,50 +131,50 @@ Smoke-workflow GitHub — це `Mantis Discord Smoke`. GitHub workflow до і
@clawsweeper verify e2e discord
```
Перша команда явна й зосереджена на сценарії. Друга згодом може зіставляти PR
або issue з рекомендованими сценаріями Mantis на основі міток, змінених файлів і
висновків рев'ю ClawSweeper.
Перша команда явна й зосереджена на scenario. Друга згодом може зіставляти PR
або issue з рекомендованими Mantis scenarios на основі labels, changed files і
ClawSweeper review findings.
## Життєвий цикл запуску
1. Отримати облікові дані.
1. Отримати credentials.
2. Виділити або повторно використати VM.
3. Підготувати чистий checkout для базового ref.
4. Установити залежності та зібрати лише те, що потрібно сценарію.
5. Запустити дочірній OpenClaw Gateway з ізольованою директорією стану.
6. Налаштувати live-транспорт, провайдера, модель і профіль браузера.
7. Запустити сценарій і захопити baseline-докази.
8. Зупинити gateway і зберегти журнали.
9. Підготувати кандидатний ref у тій самій VM.
10. Запустити той самий сценарій і захопити кандидатні докази.
11. Порівняти результати оракула та візуальні докази.
12. Записати Markdown, JSON, журнали, знімки екрана й необов'язкові артефакти трасування.
13. Завантажити артефакти GitHub Actions.
14. Опублікувати стислий статус у PR або Discord.
3. Підготувати чистий checkout для baseline ref.
4. Install dependencies і build лише те, що потрібно scenario.
5. Запустити child OpenClaw Gateway з isolated state directory.
6. Налаштувати live transport, provider, model і browser profile.
7. Запустити scenario і зібрати baseline evidence.
8. Зупинити gateway і зберегти logs.
9. Підготувати candidate ref у тій самій VM.
10. Запустити той самий scenario і зібрати candidate evidence.
11. Порівняти oracle results і visual evidence.
12. Записати Markdown, JSON, logs, screenshots і optional trace artifacts.
13. Upload GitHub Actions artifacts.
14. Опублікувати стислий PR або Discord status message.
Сценарій має мати змогу завершитися помилкою двома різними способами:
Scenario має вміти завершуватися невдало двома різними способами:
- **Помилку відтворено**: baseline завершився невдало очікуваним способом.
- **Збій harness**: налаштування середовища, облікові дані, Discord API, браузер або
провайдер завершилися невдало до того, як оракул помилки став змістовним.
- **Баг відтворено**: baseline failed in the expected way.
- **Збій harness**: environment setup, credentials, Discord API, browser або
provider failed before the bug oracle was meaningful.
Фінальний звіт має розділяти ці випадки, щоб мейнтейнери не плутали нестабільне
середовище з поведінкою продукту.
Final report має розділяти ці випадки, щоб maintainers не плутали flaky
environment із product behavior.
## Discord MVP
Перший сценарій має націлюватися на статусні реакції Discord у каналах гільдії, де
режим доставки відповіді джерела — `message_tool_only`.
Перший scenario має цілитися в Discord status reactions у guild channels, де
source reply delivery mode — `message_tool_only`.
Чому це хороше зерно для Mantis:
Чому це добрий початковий Mantis seed:
- Це видно в Discord як реакції на повідомлення, що запустило сценарій.
- Він має сильний REST-оракул через стан реакцій повідомлення Discord.
- Він перевіряє реальний OpenClaw Gateway, автентифікацію бота Discord, диспетчеризацію повідомлень,
режим доставки відповіді джерела, стан статусних реакцій і життєвий цикл ходу моделі.
- Це видно в Discord як reactions на triggering message.
- Він має strong REST oracle через Discord message reaction state.
- Він проходить через справжній OpenClaw Gateway, Discord bot auth, message dispatch,
source reply delivery mode, status reaction state і model turn lifecycle.
- Він достатньо вузький, щоб перша реалізація залишалася чесною.
Очікувана форма сценарію:
Очікувана форма scenario:
```yaml
id: discord-status-reactions-tool-only
@ -183,12 +205,12 @@ evidence:
screenshotMessageRow: true
```
Baseline-докази мають показувати реакцію підтвердження queued, але без
переходу життєвого циклу в режимі лише tool. Кандидатні докази мають показувати, що статусні
реакції життєвого циклу запускаються, коли `messages.statusReactions.enabled` явно
дорівнює true.
Baseline evidence має показувати queued acknowledgement reaction, але без
lifecycle transition у tool-only mode. Candidate evidence має показувати lifecycle
status reactions, які виконуються, коли `messages.statusReactions.enabled` явно
true.
Виконуваний перший зріз — це opt-in live-сценарій Discord QA:
Виконуваний перший зріз — opt-in Discord live QA scenario:
```bash
pnpm openclaw qa discord \
@ -200,34 +222,34 @@ pnpm openclaw qa discord \
--output-dir .artifacts/qa-e2e/mantis/discord-status-reactions-candidate
```
Він налаштовує SUT з постійно увімкненою обробкою гільдії, `visibleReplies:
"message_tool"`, `ackReaction: "👀"` і явними статусними реакціями. Оракул
опитує реальне повідомлення Discord, що запустило сценарій, і очікує спостережену послідовність
`👀 -> 🤔 -> 👍`. Артефакти містять `discord-qa-reaction-timelines.json`,
`discord-status-reactions-tool-only-timeline.html` і
Він налаштовує SUT з always-on guild handling, `visibleReplies:
"message_tool"`, `ackReaction: "👀"` і explicit status reactions. Oracle
polls the real Discord triggering message і очікує observed sequence
`👀 -> 🤔 -> 👍`. Artifacts include `discord-qa-reaction-timelines.json`,
`discord-status-reactions-tool-only-timeline.html`, and
`discord-status-reactions-tool-only-timeline.png`.
## Наявні частини QA
Mantis має будуватися на наявному приватному стеку QA, а не починатися з
Mantis має будуватися на наявному private QA stack, а не починати з
нуля:
- `pnpm openclaw qa discord` уже запускає live-доріжку Discord з ботами driver і
SUT.
- Live-транспортний runner уже записує звіти й артефакти спостережених повідомлень
у `.artifacts/qa-e2e/`.
- Оренди облікових даних Convex уже надають ексклюзивний доступ до спільних live
транспортних облікових даних.
- Сервіс керування браузером уже підтримує знімки екрана, snapshots,
headless керовані профілі та віддалені CDP-профілі.
- QA Lab уже має debugger UI і bus для тестування у формі транспорту.
- `pnpm openclaw qa discord` уже запускає live Discord lane з driver і
SUT bots.
- Live transport runner уже записує reports і observed-message
artifacts під `.artifacts/qa-e2e/`.
- Convex credential leases уже надають exclusive access to shared live
transport credentials.
- Browser control service уже підтримує screenshots, snapshots,
headless managed profiles і remote CDP profiles.
- QA Lab уже має debugger UI і bus for transport-shaped testing.
Перша реалізація Mantis може бути тонким runner до/після над цими
частинами, плюс один шар візуальних доказів.
Перша реалізація Mantis може бути тонким before/after runner над цими
частинами, плюс один visual evidence layer.
## Модель доказів
Кожен запуск записує стабільну директорію артефактів:
Кожен run записує стабільний artifact directory:
```text
.artifacts/qa-e2e/mantis/<run-id>/
@ -247,79 +269,79 @@ Mantis має будуватися на наявному приватному с
run.log
```
`mantis-summary.json` має бути машинозчитуваним джерелом істини. Markdown-звіт
призначений для коментарів PR і людського рев'ю.
`mantis-summary.json` має бути machine-readable source of truth. Markdown
report призначений для PR comments і human review.
Зведення має містити:
Summary має включати:
- протестовані refs і SHA
- transport і scenario id
- провайдер машини та ідентифікатор машини або lease id
- джерело облікових даних без секретних значень
- результат baseline
- результат candidate
- чи було відтворено помилку на baseline
- чи виправив її candidate
- шляхи артефактів
- очищені від секретів проблеми налаштування або прибирання
- refs і SHAs tested
- transport and scenario id
- machine provider and machine id або lease id
- credential source without secret values
- baseline result
- candidate result
- whether the bug reproduced on baseline
- whether the candidate fixed it
- artifact paths
- sanitized setup or cleanup issues
Знімки екрана — це докази, а не секрети. Вони все одно потребують дисципліни редагування:
можуть з'являтися приватні назви каналів, імена користувачів або вміст повідомлень. Для публічних PR
надавайте перевагу посиланням на артефакти GitHub Actions замість inline-зображень, доки історія
редагування не стане сильнішою.
Screenshots — це evidence, не secrets. Вони все одно потребують redaction discipline:
private channel names, user names або message content можуть з’являтися. Для public PRs
надавайте перевагу GitHub Actions artifact links, а не inline images, доки redaction story
не стане сильнішою.
## Браузер і VNC
## Browser і VNC
Браузерна доріжка має два режими:
Browser lane має два modes:
- **Headless automation**: типово для CI. Chrome запускається з увімкненим CDP, а
Playwright або керування браузером OpenClaw захоплює знімки екрана.
- **VNC rescue**: вмикається на тій самій VM, коли вхід, MFA, антиавтоматизація Discord
або візуальне налагодження потребує людини.
- **Headless automation**: default для CI. Chrome runs with CDP enabled, and
Playwright або OpenClaw browser control captures screenshots.
- **VNC rescue**: enabled on the same VM, коли login, MFA, Discord anti-automation
або visual debugging потребує людину.
Профіль браузера-спостерігача Discord має бути достатньо постійним, щоб уникнути
входу для кожного запуску, але ізольованим від особистого стану браузера. Профіль
належить пулу машин Mantis, а не ноутбуку розробника.
Discord observer browser profile має бути достатньо persistent, щоб уникати
logging in for every run, але isolated from personal browser state. Profile
belongs to the Mantis machine pool, not to a developer laptop.
Коли Mantis застрягає, він публікує статусне повідомлення Discord з:
Коли Mantis застрягає, він публікує Discord status message з:
- run id
- scenario id
- провайдером машини
- директорією артефактів
- інструкціями підключення VNC або noVNC, якщо доступні
- коротким текстом блокера
- machine provider
- artifact directory
- VNC або noVNC connection instructions, якщо доступні
- short blocker text
Перше приватне розгортання може публікувати ці повідомлення в наявний операторський
канал і пізніше перейти до виділеного каналу Mantis.
Перший private deployment може публікувати ці messages в existing operator
channel і пізніше перейти до dedicated Mantis channel.
## Машини
Mantis має надавати перевагу AWS через Crabbox для першої віддаленої реалізації.
Crabbox дає нам прогріті машини, відстеження lease, hydration, журнали, результати та
прибирання. Якщо потужності AWS занадто повільні або недоступні, додайте провайдера Hetzner
за тим самим інтерфейсом машин.
Mantis має надавати перевагу AWS через Crabbox для першої remote implementation.
Crabbox дає нам warmed machines, lease tracking, hydration, logs, results і
cleanup. Якщо AWS capacity надто повільна або недоступна, додайте Hetzner provider
behind the same machine interface.
Мінімальні вимоги до VM:
- Linux з установленим Chrome або Chromium, придатним для desktop
- доступ CDP для автоматизації браузера
- VNC або noVNC для відновлення
- Linux із desktop-capable Chrome або Chromium install
- CDP access for browser automation
- VNC або noVNC для rescue
- Node 22 і pnpm
- checkout OpenClaw і кеш залежностей
- кеш браузера Playwright Chromium, коли використовується Playwright
- достатньо CPU та пам'яті для одного OpenClaw Gateway, одного браузера й одного запуску моделі
- вихідний доступ до Discord, GitHub, провайдерів моделей і брокера облікових даних
- OpenClaw checkout і dependency cache
- Playwright Chromium browser cache, коли використовується Playwright
- достатньо CPU і memory для одного OpenClaw Gateway, одного browser і одного model run
- outbound access to Discord, GitHub, model providers і credential broker
VM не повинна зберігати довгоживучі сирі секрети поза очікуваними сховищами облікових даних або
профілів браузера.
VM не має зберігати long-lived raw secrets поза expected credential або
browser profile stores.
## Секрети
## Secrets
Секрети живуть у секретах організації або репозиторію GitHub для віддалених запусків, і в
локальному файлі секретів під контролем оператора для локальних запусків.
Secrets живуть у GitHub organization або repository secrets для remote runs і в
local operator-controlled secret file для local runs.
Рекомендовані назви секретів:
Рекомендовані secret names:
- `OPENCLAW_QA_DISCORD_MANTIS_BOT_TOKEN`
- `OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN`
@ -327,36 +349,32 @@ VM не повинна зберігати довгоживучі сирі сек
- `OPENCLAW_QA_DISCORD_GUILD_ID`
- `OPENCLAW_QA_DISCORD_CHANNEL_ID`
- `OPENCLAW_QA_DISCORD_NOTIFY_CHANNEL_ID`
- `OPENCLAW_QA_REDACT_PUBLIC_METADATA=1` for public GitHub artifact uploads
- `OPENCLAW_QA_REDACT_PUBLIC_METADATA=1` для завантажень публічних артефактів GitHub
- `OPENCLAW_QA_CONVEX_SITE_URL`
- `OPENCLAW_QA_CONVEX_SECRET_CI`
У довгостроковій перспективі пул облікових даних Convex має залишатися звичайним джерелом live
транспортних облікових даних. Секрети GitHub bootstrap-лять брокер і fallback-доріжки.
У довгостроковій перспективі пул облікових даних Convex має залишатися звичайним джерелом облікових даних для live-транспортів. Секрети GitHub початково налаштовують брокер і резервні лінії.
Runner Mantis ніколи не повинен друкувати:
Запускач Mantis ніколи не повинен друкувати:
- токени ботів Discord
- API-ключі провайдера
- cookies браузера
- вміст auth profile
- API-ключі провайдерів
- cookie браузера
- вміст профілів автентифікації
- паролі VNC
- сирі payload облікових даних
- сирі payload-и облікових даних
Публічні завантаження артефактів також мають редагувати цільові метадані Discord, як-от ідентифікатори бота,
гільдії, каналу та повідомлення. Smoke-workflow GitHub вмикає
`OPENCLAW_QA_REDACT_PUBLIC_METADATA=1` з цієї причини.
Завантаження публічних артефактів також мають редагувати цільові метадані Discord, як-от ідентифікатори бота, guild, каналу та повідомлення. GitHub smoke workflow вмикає `OPENCLAW_QA_REDACT_PUBLIC_METADATA=1` саме з цієї причини.
Якщо token випадково вставлено в issue, PR, chat або log, rotate it
after the new secret has been stored.
Якщо токен випадково вставили в issue, PR, чат або журнал, ротуй його після збереження нового секрету.
## GitHub Artifacts And PR Comments
## Артефакти GitHub і коментарі PR
Робочі процеси Mantis мають завантажувати повний пакет доказів як короткочасний артефакт Actions. Коли робочий процес запускається для звіту про помилку або PR з виправленням, він також має публікувати замасковані PNG-знімки екрана в гілку `qa-artifacts` і створювати або оновлювати коментар у цьому звіті про помилку чи PR з виправленням із вбудованими знімками екрана до/після. Не публікуйте основний доказ лише в загальному PR автоматизації QA. Сирі журнали, спостережені повідомлення та інші об'ємні докази залишаються в артефакті Actions.
Workflow-и Mantis мають завантажувати повний пакет доказів як короткостроковий артефакт Actions. Коли workflow запускається для звіту про bug або fix PR, він також має публікувати відредаговані PNG-знімки екрана в гілку `qa-artifacts` і оновлювати або створювати коментар у цьому bug або fix PR з inline-знімками до/після. Не публікуй основний доказ лише в generic PR автоматизації QA. Сирі журнали, спостережені повідомлення та інші об’ємні докази залишаються в артефакті Actions.
Виробничі робочі процеси мають публікувати ці коментарі через Mantis GitHub App, а не через `github-actions[bot]`. Зберігайте app id і private key як секрети GitHub Actions `MANTIS_GITHUB_APP_ID` і `MANTIS_GITHUB_APP_PRIVATE_KEY`. Якщо app перейменовано, задайте `MANTIS_GITHUB_APP_BOT_LOGIN` як змінну GitHub Actions з новим bot login, наприклад `openclaw-mantis[bot]`. Робочий процес має оновлювати наявний коментар, власником якого є Mantis, якщо такий існує; якщо існує лише старіший коментар від `github-actions[bot]`, він має створити новий коментар від імені Mantis замість переписування коментаря застарілого бота.
Production workflow-и мають публікувати ці коментарі через Mantis GitHub App, а не через `github-actions[bot]`. Збережи app id і private key як секрети GitHub Actions `MANTIS_GITHUB_APP_ID` і `MANTIS_GITHUB_APP_PRIVATE_KEY`. Workflow визначає login бота з токена GitHub App, оновлює наявний коментар, власником якого є Mantis, якщо він існує, і створює новий коментар від імені Mantis замість переписування старіших коментарів `github-actions[bot]`.
Коментар у PR має бути коротким і візуальним:
Коментар PR має бути коротким і візуальним:
```md
Mantis Discord Status Reactions QA
@ -376,15 +394,15 @@ candidate showed the expected queued -> thinking -> done sequence.
| <inline screenshot> | <inline screenshot> |
```
Коли запуск завершується помилкою через збій тестового стенда, коментар має повідомляти саме це, а не натякати, що кандидат не пройшов.
Коли запуск не вдається через збій harness, коментар має вказувати саме це, а не натякати, що кандидат не пройшов.
## Нотатки щодо приватного розгортання
У приватному розгортанні вже може бути Discord-застосунок Mantis. Повторно використайте цей застосунок замість створення іншого app, якщо він має правильні дозволи бота і його можна безпечно ротувати.
У приватному розгортанні вже може бути застосунок Mantis Discord. Використовуй цей застосунок повторно замість створення іншого app, якщо він має потрібні дозволи бота і його можна безпечно ротувати.
Задайте початковий канал сповіщень оператора через секрети або конфігурацію розгортання. Спочатку він може вказувати на наявний канал супровідників або операційний канал, а потім перейти на окремий канал Mantis, коли такий з'явиться.
Задай початковий канал сповіщень оператора через секрети або конфігурацію розгортання. Спочатку він може вказувати на наявний канал maintainers або operations, а потім перейти на виділений канал Mantis, коли він з’явиться.
Не додавайте guild ids, channel ids, bot tokens, browser cookies або VNC passwords у цей документ. Зберігайте їх у секретах GitHub, брокері облікових даних або локальному сховищі секретів оператора.
Не розміщуй guild ids, channel ids, bot tokens, browser cookies або VNC passwords у цьому документі. Зберігай їх у секретах GitHub, брокері облікових даних або локальному сховищі секретів оператора.
## Додавання сценарію
@ -392,44 +410,44 @@ candidate showed the expected queued -> thinking -> done sequence.
- id і title
- transport
- необхідні облікові дані
- політику baseline ref
- політику candidate ref
- патч конфігурації OpenClaw
- required credentials
- baseline ref policy
- candidate ref policy
- OpenClaw config patch
- кроки налаштування
- стимул
- очікуваний oracle baseline
- очікуваний oracle candidate
- очікуваний baseline oracle
- очікуваний candidate oracle
- цілі візуального захоплення
- бюджет тайм-ауту
- бюджет timeout
- кроки очищення
Сценарії мають надавати перевагу невеликим типізованим oracle:
Сценаріям варто віддавати перевагу невеликим typed oracle:
- стан реакції Discord для помилок реакцій
- посилання на повідомлення Discord для помилок тредингу
- Slack thread ts і стан reaction API для помилок Slack
- email message ids і headers для помилок email
- стан реакції Discord для bug-ів реакцій
- посилання на повідомлення Discord для bug-ів threading
- Slack thread ts і стан API реакцій для bug-ів Slack
- ідентифікатори повідомлень email і заголовки для bug-ів email
- знімки екрана браузера, коли UI є єдиним надійним спостережуваним сигналом
Перевірки vision мають бути додатковими. Якщо API платформи може довести помилку, використовуйте API як pass/fail oracle, а знімки екрана залишайте для впевненості людини.
Перевірки vision мають бути додатковими. Якщо API платформи може довести bug, використовуй API як pass/fail oracle і залишай знімки екрана для людської впевненості.
## Розширення провайдерів
Після Discord той самий runner може додати:
Після Discord той самий запускач може додати:
- Slack: реакції, треди, згадки app, модальні вікна, завантаження файлів.
- Email: автентифікація Gmail і трединг повідомлень за допомогою `gog`, коли connectors недостатньо.
- Slack: реакції, threads, app mentions, modals, file uploads.
- Email: автентифікація Gmail і threading повідомлень за допомогою `gog`, коли connectors недостатньо.
- WhatsApp: QR-вхід, повторна ідентифікація, доставка повідомлень, медіа, реакції.
- Telegram: обмеження групових згадок, команди, реакції, де доступно.
- Matrix: зашифровані кімнати, зв'язки тредів або відповідей, відновлення після перезапуску.
- Telegram: gating згадок у групі, команди, реакції, де доступно.
- Matrix: зашифровані кімнати, зв’язки thread або reply, відновлення після перезапуску.
Кожен transport має мати один дешевий smoke-сценарій і один або більше сценаріїв класу помилок. Дорогі візуальні сценарії мають залишатися opt-in.
Кожен transport має мати один дешевий smoke scenario і один або більше bug-class scenarios. Дорогі візуальні сценарії мають залишатися opt-in.
## Відкриті питання
- Який Discord-бот має бути драйвером, а який SUT, коли наявного бота Mantis використовують повторно?
- Чи має вхід спостерігача в браузері використовувати людський обліковий запис Discord, тестовий обліковий запис або лише REST-докази, доступні для читання ботом, на першому етапі?
- Який бот Discord має бути driver, а який SUT, коли наявний бот Mantis використовується повторно?
- Чи має browser login спостерігача використовувати людський обліковий запис Discord, тестовий обліковий запис або лише bot-readable REST evidence для першої фази?
- Як довго GitHub має зберігати артефакти Mantis для PR?
- Коли ClawSweeper має автоматично рекомендувати Mantis замість очікування команди супровідника?
- Чи слід маскувати або обрізати знімки екрана перед завантаженням для публічних PR?
- Коли ClawSweeper має автоматично рекомендувати Mantis замість очікування команди maintainer?
- Чи потрібно редагувати або обрізати знімки екрана перед завантаженням для публічних PR?

371
docs/uk/concepts/qa-e2e-automation.md
View File

@ -1,67 +1,67 @@
---
read_when:
- Розуміння того, як складові QA-стека працюють разом
- Розуміння того, як взаємодіє QA-стек
- Розширення qa-lab, qa-channel або транспортного адаптера
- Додавання QA-сценаріїв на основі репозиторію
- Створення реалістичнішої QA-автоматизації навколо панелі керування Gateway
summary: 'Огляд стеку QA: qa-lab, qa-channel, сценарії, підтримувані репозиторієм, лінії живого транспорту, транспортні адаптери та звітність.'
title: Огляд забезпечення якості
- Створення реалістичнішої автоматизації QA навколо панелі керування Gateway
summary: 'Огляд стека QA: qa-lab, qa-channel, сценарії на основі репозиторію, live-лінії транспорту, транспортні адаптери та звітування.'
title: Огляд QA
x-i18n:
generated_at: "2026-05-03T16:04:56Z"
generated_at: "2026-05-03T20:32:15Z"
model: gpt-5.5
provider: openai
source_hash: 6b4fd8107a4f46e394c9de74d07947310de210e8bff2b4daaea57d0f3644fd60
source_hash: 6a1446fddb00855634d34662a0a47be1e5054a9e7bfed5bc9ae21185d87094d8
source_path: concepts/qa-e2e-automation.md
workflow: 16
---
Приватний QA-стек призначений для перевірки OpenClaw у більш реалістичний
канально-орієнтований спосіб, ніж це може зробити один модульний тест.
Приватний стек QA призначений для перевірки OpenClaw реалістичнішим,
канально-орієнтованим способом, ніж це може зробити один модульний тест.
Поточні компоненти:
Поточні складові:
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, потоку,
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, гілки,
реакції, редагування та видалення.
- `extensions/qa-lab`: UI налагоджувача та QA-шина для спостереження за транскриптом,
інʼєкції вхідних повідомлень і експорту Markdown-звіту.
- `extensions/qa-matrix`, майбутні runner plugins: адаптери live-транспортів, які
- `extensions/qa-lab`: UI відлагоджувача та шина QA для спостереження за транскриптом,
ін'єкції вхідних повідомлень і експорту Markdown-звіту.
- `extensions/qa-matrix`, майбутні runner-плагіни: адаптери live-транспортів, які
керують реальним каналом усередині дочірнього QA gateway.
- `qa/`: seed-ресурси з репозиторію для стартового завдання та базових QA
сценаріїв.
- [Mantis](/uk/concepts/mantis): перевірка до і після live-верифікації для помилок, яким
- [Mantis](/uk/concepts/mantis): перевірка до і після наживо для помилок, яким
потрібні реальні транспорти, знімки екрана браузера, стан VM і докази PR.
## Поверхня команд
Кожен QA-потік запускається через `pnpm openclaw qa <subcommand>`. Багато з них мають
псевдоніми скриптів `pnpm qa:*`; підтримуються обидві форми.
Кожен QA-потік виконується через `pnpm openclaw qa <subcommand>`. Багато з них мають псевдоніми скриптів `pnpm qa:*`;
підтримуються обидві форми.
| Команда | Призначення |
| --------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `qa run` | Вбудована самоперевірка QA; записує Markdown-звіт. |
| `qa suite` | Запустити сценарії з репозиторію проти QA gateway lane. Псевдоніми: `pnpm openclaw qa suite --runner multipass` для одноразової Linux VM. |
| `qa coverage` | Вивести markdown-інвентар покриття сценаріїв (`--json` для машинного виводу). |
| `qa parity-report` | Порівняти два файли `qa-suite-summary.json` і записати agentic-звіт про паритет. |
| `qa character-eval` | Запустити character QA-сценарій на кількох live-моделях зі звітом оцінювання. Див. [Звітування](#reporting). |
| `qa manual` | Запустити одноразовий prompt проти вибраного provider/model lane. |
| `qa ui` | Запустити UI налагоджувача QA і локальну QA-шину (псевдонім: `pnpm qa:lab:ui`). |
| `qa docker-build-image` | Зібрати попередньо підготовлений QA Docker-образ. |
| `qa docker-scaffold` | Записати docker-compose каркас для QA dashboard + gateway lane. |
| `qa up` | Зібрати QA-сайт, запустити Docker-backed стек, вивести URL (псевдонім: `pnpm qa:lab:up`; варіант `:fast` додає `--use-prebuilt-image --bind-ui-dist --skip-ui-build`). |
| `qa aimock` | Запустити лише сервер AIMock provider. |
| `qa mock-openai` | Запустити лише scenario-aware сервер `mock-openai` provider. |
| `qa credentials doctor` / `add` / `list` / `remove` | Керувати спільним пулом облікових даних Convex. |
| `qa matrix` | Live transport lane проти одноразового Tuwunel homeserver. Див. [Matrix QA](/uk/concepts/qa-matrix). |
| `qa telegram` | Live transport lane проти реальної приватної групи Telegram. |
| `qa discord` | Live transport lane проти реального приватного каналу Discord guild. |
| `qa mantis` | Запланований runner для перевірки до і після для помилок live transport. Див. [Mantis](/uk/concepts/mantis). |
| Команда | Призначення |
| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `qa run` | Вбудована самоперевірка QA; записує Markdown-звіт. |
| `qa suite` | Запустити сценарії з репозиторію проти lane QA gateway. Псевдоніми: `pnpm openclaw qa suite --runner multipass` для одноразової Linux VM. |
| `qa coverage` | Надрукувати Markdown-інвентар покриття сценаріїв (`--json` для машинного виводу). |
| `qa parity-report` | Порівняти два файли `qa-suite-summary.json` і записати агентний звіт про паритет. |
| `qa character-eval` | Запустити character QA scenario на кількох live-моделях зі звітом із судженням. Див. [Звітування](#reporting). |
| `qa manual` | Запустити одноразовий prompt проти вибраного lane провайдера/моделі. |
| `qa ui` | Запустити UI відлагоджувача QA та локальну шину QA (псевдонім: `pnpm qa:lab:ui`). |
| `qa docker-build-image` | Зібрати попередньо підготовлений Docker-образ QA. |
| `qa docker-scaffold` | Записати docker-compose scaffold для QA dashboard + gateway lane. |
| `qa up` | Зібрати QA site, запустити стек на Docker і надрукувати URL (псевдонім: `pnpm qa:lab:up`; варіант `:fast` додає `--use-prebuilt-image --bind-ui-dist --skip-ui-build`). |
| `qa aimock` | Запустити лише сервер AIMock provider. |
| `qa mock-openai` | Запустити лише сервер scenario-aware `mock-openai` provider. |
| `qa credentials doctor` / `add` / `list` / `remove` | Керувати спільним пулом облікових даних Convex. |
| `qa matrix` | Live transport lane проти одноразового Tuwunel homeserver. Див. [Matrix QA](/uk/concepts/qa-matrix). |
| `qa telegram` | Live transport lane проти реальної приватної групи Telegram. |
| `qa discord` | Live transport lane проти реального приватного каналу guild Discord. |
| `qa mantis` | Runner для перевірки до і після для помилок live-транспорту, з першим сценарієм Discord status-reactions. Див. [Mantis](/uk/concepts/mantis). |
## Потік оператора
Поточний потік QA-оператора — це QA-сайт із двома панелями:
Поточний операторський потік QA — це двопанельний QA site:
- Ліворуч: Gateway dashboard (Control UI) з агентом.
- Праворуч: QA Lab, що показує Slack-подібний транскрипт і план сценарію.
- Ліворуч: панель Gateway (Control UI) з агентом.
- Праворуч: QA Lab, що показує транскрипт у стилі Slack і план сценарію.
Запустіть його так:
@ -69,13 +69,13 @@ x-i18n:
pnpm qa:lab:up
```
Це збирає QA-сайт, запускає Docker-backed gateway lane і відкриває сторінку
QA Lab, де оператор або цикл автоматизації може дати агенту QA
місію, спостерігати реальну поведінку каналу та зафіксувати, що спрацювало, що не вдалося або
Це збирає QA site, запускає gateway lane на Docker і відкриває сторінку
QA Lab, де оператор або automation loop може дати агенту QA-місію,
спостерігати реальну поведінку каналу та записати, що спрацювало, не спрацювало або
залишилося заблокованим.
Для швидшої ітерації UI QA Lab без перебудови Docker-образу щоразу
запустіть стек із bind-mounted бандлом QA Lab:
Для швидшої ітерації UI QA Lab без перезбирання Docker-образу щоразу
запустіть стек із bind-mounted QA Lab bundle:
```bash
pnpm openclaw qa docker-build-image
@ -86,36 +86,36 @@ pnpm qa:lab:watch
`qa:lab:up:fast` тримає Docker-сервіси на попередньо зібраному образі та bind-mounts
`extensions/qa-lab/web/dist` у контейнер `qa-lab`. `qa:lab:watch`
перезбирає цей бандл при зміні, а браузер автоматично перезавантажується, коли змінюється
asset hash QA Lab.
перезбирає цей bundle при змінах, а браузер автоматично перезавантажується, коли змінюється
хеш ресурсів QA Lab.
Для локального OpenTelemetry trace smoke запустіть:
Для локального smoke OpenTelemetry trace запустіть:
```bash
pnpm qa:otel:smoke
```
Цей скрипт запускає локальний OTLP/HTTP trace receiver, запускає
Цей скрипт запускає локальний OTLP/HTTP trace receiver, виконує
QA-сценарій `otel-trace-smoke` з увімкненим Plugin `diagnostics-otel`, потім
декодує експортовані protobuf spans і перевіряє release-critical форму:
`openclaw.run`, `openclaw.harness.run`, `openclaw.model.call`,
`openclaw.context.assembled` і `openclaw.message.delivery` мають бути присутні;
model calls не повинні експортувати `StreamAbandoned` на успішних turns; raw diagnostic IDs і
атрибути `openclaw.content.*` мають лишатися поза trace. Він записує
`otel-smoke-summary.json` поруч із артефактами QA suite.
model calls не мають експортувати `StreamAbandoned` на успішних ходах; raw diagnostic IDs і
атрибути `openclaw.content.*` мають залишатися поза trace. Він записує
`otel-smoke-summary.json` поруч з артефактами QA suite.
Observability QA лишається доступним лише з source-checkout. npm tarball навмисно не містить
QA Lab, тому package Docker release lanes не запускають команди `qa`. Використовуйте
`pnpm qa:otel:smoke` із зібраного source checkout під час зміни diagnostics
Observability QA залишається лише для source checkout. npm tarball навмисно не містить
QA Lab, тому package Docker release lanes не виконують команди `qa`. Використовуйте
`pnpm qa:otel:smoke` із зібраного source checkout, коли змінюєте diagnostics
instrumentation.
Для transport-real Matrix smoke lane запустіть:
Для lane transport-real Matrix smoke запустіть:
```bash
pnpm openclaw qa matrix --profile fast --fail-fast
```
Повний довідник CLI, каталог профілів/сценаріїв, env vars і структура артефактів для цього lane містяться в [Matrix QA](/uk/concepts/qa-matrix). Коротко: він створює одноразовий Tuwunel homeserver у Docker, реєструє тимчасових driver/SUT/observer користувачів, запускає реальний Matrix Plugin усередині дочірнього QA gateway, обмеженого цим transport (без `qa-channel`), а потім записує Markdown-звіт, JSON-summary, observed-events artifact і combined output log у `.artifacts/qa-e2e/matrix-<timestamp>/`.
Повний довідник CLI, каталог профілів/сценаріїв, env vars і структура артефактів для цього lane містяться в [Matrix QA](/uk/concepts/qa-matrix). Коротко: він provision одноразовий Tuwunel homeserver у Docker, реєструє тимчасових користувачів driver/SUT/observer, запускає реальний Matrix Plugin усередині дочірнього QA gateway, обмеженого цим transport (без `qa-channel`), а потім записує Markdown-звіт, JSON summary, артефакт observed-events і комбінований output log у `.artifacts/qa-e2e/matrix-<timestamp>/`.
Для transport-real Telegram і Discord smoke lanes:
@ -124,7 +124,7 @@ pnpm openclaw qa telegram
pnpm openclaw qa discord
```
Обидва націлені на наявний реальний канал із двома ботами (driver + SUT). Обовʼязкові env vars, списки сценаріїв, вихідні артефакти та пул облікових даних Convex задокументовані нижче в [Довіднику QA для Telegram і Discord](#telegram-and-discord-qa-reference).
Обидва націлені на вже наявний реальний канал із двома ботами (driver + SUT). Обов'язкові env vars, списки сценаріїв, вихідні артефакти та пул облікових даних Convex задокументовані в [довіднику QA для Telegram і Discord](#telegram-and-discord-qa-reference) нижче.
Перед використанням pooled live credentials запустіть:
@ -132,11 +132,11 @@ pnpm openclaw qa discord
pnpm openclaw qa credentials doctor
```
Doctor перевіряє env Convex broker, валідовує налаштування endpoint і перевіряє admin/list reachability, коли наявний maintainer secret. Для secrets він повідомляє лише статус set/missing.
Doctor перевіряє env брокера Convex, валідовує endpoint settings і перевіряє доступність admin/list, коли maintainer secret присутній. Для secrets він повідомляє лише статус set/missing.
## Покриття live transport
Live transport lanes спільно використовують один контракт, замість того щоб кожен вигадував власну форму списку сценаріїв. `qa-channel` — це широка синтетична suite для product-behavior і вона не є частиною матриці покриття live transport.
Live transport lanes мають один спільний контракт замість того, щоб кожен вигадував власну форму списку сценаріїв. `qa-channel` — це широка синтетична suite поведінки продукту й не є частиною матриці покриття live transport.
| Lane | Canary | Mention gating | Bot-to-bot | Allowlist block | Top-level reply | Restart resume | Thread follow-up | Thread isolation | Reaction observation | Help command | Native command registration |
| -------- | ------ | -------------- | ---------- | --------------- | --------------- | -------------- | ---------------- | ---------------- | -------------------- | ------------ | --------------------------- |
@ -144,70 +144,69 @@ Live transport lanes спільно використовують один кон
| Telegram | x | x | x | | | | | | | x | |
| Discord | x | x | x | | | | | | | | x |
Це зберігає `qa-channel` як широку suite для product-behavior, тоді як Matrix,
Telegram і майбутні live transports спільно використовують один явний checklist
transport-contract.
Це зберігає `qa-channel` як широку suite поведінки продукту, тоді як Matrix,
Telegram і майбутні live transports мають один явний checklist транспортного контракту.
Для одноразового Linux VM lane без залучення Docker у QA-шлях запустіть:
Для одноразового lane Linux VM без внесення Docker у шлях QA запустіть:
```bash
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
```
Це завантажує свіжий Multipass guest, встановлює залежності, збирає OpenClaw
усередині guest, запускає `qa suite`, а потім копіює звичайний QA-звіт і
Це завантажує свіжий гостьовий Multipass, встановлює залежності, збирає OpenClaw
усередині guest, запускає `qa suite`, а потім копіює звичайний QA report і
summary назад у `.artifacts/qa-e2e/...` на host.
Він повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на host.
Host і Multipass suite runs за замовчуванням виконують кілька вибраних сценаріїв паралельно
з ізольованими gateway workers. `qa-channel` за замовчуванням має concurrency
4, обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати
кількість workers, або `--concurrency 1` для serial execution.
Команда завершується з ненульовим кодом, коли будь-який сценарій зазнає невдачі. Використовуйте `--allow-failures`, коли
потрібні артефакти без failing exit code.
кількість workers, або `--concurrency 1` для послідовного виконання.
Команда завершується з ненульовим кодом, коли будь-який сценарій не вдається. Використовуйте `--allow-failures`, коли
потрібні артефакти без коду завершення з помилкою.
Live runs передають підтримувані QA auth inputs, практичні для
guest: env-based provider keys, шлях до QA live provider config і
`CODEX_HOME`, коли він наявний. Тримайте `--output-dir` під коренем репозиторію, щоб guest
міг записувати назад через змонтований workspace.
guest: provider keys на основі env, шлях до QA live provider config і
`CODEX_HOME`, коли він присутній. Тримайте `--output-dir` під коренем репозиторію, щоб guest
міг записувати назад через mounted workspace.
## Довідник QA для Telegram і Discord
Matrix має [окрему сторінку](/uk/concepts/qa-matrix) через кількість сценаріїв і Docker-backed homeserver provisioning. Telegram і Discord менші — кілька сценаріїв кожен, без profile system, проти наявних реальних каналів — тому їхній довідник міститься тут.
Matrix має [окрему сторінку](/uk/concepts/qa-matrix) через кількість сценаріїв і provisioning homeserver на Docker. Telegram і Discord менші — кілька сценаріїв кожен, без системи профілів, проти вже наявних реальних каналів — тому їхній довідник міститься тут.
### Спільні прапорці CLI
### Спільні CLI flags
Обидва lanes реєструються через `extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts` і приймають ті самі прапорці:
Обидва lanes реєструються через `extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts` і приймають однакові flags:
| Прапор | Типове значення | Опис |
| ------------------------------------- | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| `--scenario <id>` | — | Запустити лише цей сценарій. Можна повторювати. |
| `--output-dir <path>` | `<repo>/.artifacts/qa-e2e/{telegram,discord}-<timestamp>` | Куди записуються звіти/підсумок/спостережені повідомлення та вихідний журнал. Відносні шляхи обчислюються відносно `--repo-root`. |
| `--output-dir <path>` | `<repo>/.artifacts/qa-e2e/{telegram,discord}-<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` | вимкнено | Швидкий режим провайдера, де підтримується. |
| `--sut-account <id>` | `sut` | Тимчасовий id облікового запису всередині конфігурації 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](#convex-credential-pool). |
| `--credential-role <maintainer\|ci>` | `ci` у CI, інакше `maintainer` | Роль, що використовується, коли `--credential-source convex`. |
| `--credential-role <maintainer\|ci>` | `ci` у CI, інакше `maintainer` | Роль, що використовується, коли `--credential-source convex`. |
Обидві команди завершуються з ненульовим кодом виходу за будь-якого невдалого сценарію. `--allow-failures` записує артефакти без встановлення коду виходу, що позначає помилку.
Обидва завершуються з ненульовим кодом виходу за будь-якого невдалого сценарію. `--allow-failures` записує артефакти без встановлення коду виходу як помилкового.
### QA для Telegram
### QA Telegram
```bash
pnpm openclaw qa telegram
```
Націлюється на одну справжню приватну групу Telegram із двома окремими ботами (драйвер + SUT). SUT-бот має мати ім’я користувача Telegram; спостереження бот-до-бота працює найкраще, коли в обох ботів увімкнено **Bot-to-Bot Communication Mode** у `@BotFather`.
Націлено на одну реальну приватну групу Telegram із двома окремими ботами (драйвер + SUT). SUT-бот повинен мати ім'я користувача Telegram; спостереження bot-to-bot працює найкраще, коли в обох ботів увімкнено **Bot-to-Bot Communication Mode** у `@BotFather`.
Обов’язкові змінні середовища, коли `--credential-source env`:
Обов'язкові env, коли `--credential-source env`:
- `OPENCLAW_QA_TELEGRAM_GROUP_ID` — числовий ідентифікатор чату (рядок).
- `OPENCLAW_QA_TELEGRAM_GROUP_ID` — числовий id чату (рядок).
- `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN`
- `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`
Необов’язково:
Необов'язково:
- `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1` зберігає тіла повідомлень в артефактах спостережених повідомлень (типово редагуються).
- `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1` зберігає тіла повідомлень в артефактах спостережених повідомлень (типово редагує).
Сценарії (`extensions/qa-lab/src/live-transports/telegram/telegram-live.runtime.ts:44`):
@ -223,26 +222,26 @@ pnpm openclaw qa telegram
Вихідні артефакти:
- `telegram-qa-report.md`
- `telegram-qa-summary.json` — включає RTT для кожної відповіді (надсилання драйвером → спостережена відповідь SUT), починаючи з канаркового сценарію.
- `telegram-qa-observed-messages.json` — тіла редагуються, якщо не встановлено `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1`.
- `telegram-qa-summary.json` — включає RTT для кожної відповіді (надсилання драйвером → спостережена відповідь SUT), починаючи з canary.
- `telegram-qa-observed-messages.json` — тіла редагуються, якщо не задано `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1`.
### QA для Discord
### QA Discord
```bash
pnpm openclaw qa discord
```
Націлюється на один справжній приватний канал гільдії Discord із двома ботами: ботом-драйвером, яким керує harness, і SUT-ботом, запущеним дочірнім OpenClaw gateway через вбудований Plugin Discord. Перевіряє обробку згадок каналу, що SUT-бот зареєстрував нативну команду `/help` у Discord, а також opt-in сценарії доказів Mantis.
Націлено на один реальний приватний канал guild Discord із двома ботами: бот-драйвер, керований harness, і SUT-бот, запущений дочірнім OpenClaw gateway через вбудований Discord plugin. Перевіряє обробку згадок каналу, те, що SUT-бот зареєстрував нативну команду `/help` у Discord, і opt-in сценарії доказів Mantis.
Обов’язкові змінні середовища, коли `--credential-source env`:
Обов'язкові env, коли `--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 (інакше lane швидко завершується помилкою).
- `OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID` — має збігатися з id користувача SUT-бота, який повертає Discord (інакше lane швидко завершується з помилкою).
Необов’язково:
Необов'язково:
- `OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1` зберігає тіла повідомлень в артефактах спостережених повідомлень.
@ -251,9 +250,9 @@ pnpm openclaw qa discord
- `discord-canary`
- `discord-mention-gating`
- `discord-native-help-command-registration`
- `discord-status-reactions-tool-only` — opt-in сценарій Mantis. Виконується окремо, бо перемикає SUT у режим постійно ввімкнених, лише інструментальних відповідей гільдії з `messages.statusReactions.enabled=true`, а потім фіксує часову шкалу реакцій REST плюс візуальний артефакт HTML/PNG.
- `discord-status-reactions-tool-only` — opt-in сценарій Mantis. Запускається самостійно, бо перемикає SUT на завжди ввімкнені відповіді guild лише через tools із `messages.statusReactions.enabled=true`, а потім захоплює часову шкалу реакцій REST плюс візуальний артефакт HTML/PNG.
Запустіть сценарій реакцій статусу Mantis явно:
Запустити сценарій реакцій статусу Mantis явно:
```bash
pnpm openclaw qa discord \
@ -268,137 +267,137 @@ pnpm openclaw qa discord \
- `discord-qa-report.md`
- `discord-qa-summary.json`
- `discord-qa-observed-messages.json` — тіла редагуються, якщо не встановлено `OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1`.
- `discord-qa-reaction-timelines.json` і `discord-status-reactions-tool-only-timeline.png`, коли виконується сценарій реакцій статусу.
- `discord-qa-observed-messages.json` — тіла редагуються, якщо не задано `OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1`.
- `discord-qa-reaction-timelines.json` і `discord-status-reactions-tool-only-timeline.png`, коли запускається сценарій реакцій статусу.
### Пул облікових даних Convex
І Telegram, і Discord lanes можуть брати облікові дані з пулу спільного Convex замість читання наведених вище змінних середовища. Передайте `--credential-source convex` (або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`); QA Lab отримує ексклюзивну оренду, надсилає Heartbeat протягом виконання та звільняє її під час завершення. Типи пулу: `"telegram"` і `"discord"`.
Lane Telegram і Discord можуть орендувати облікові дані зі спільного пулу Convex замість читання env vars вище. Передайте `--credential-source convex` (або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`); QA Lab отримує ексклюзивну оренду, надсилає для неї Heartbeat протягом виконання та звільняє її під час завершення. Типи пулу — `"telegram"` і `"discord"`.
Форми payload, які брокер перевіряє на `admin/add`:
- Telegram (`kind: "telegram"`): `{ groupId: string, driverToken: string, sutToken: string }` — `groupId` має бути числовим рядком ідентифікатора чату.
- Telegram (`kind: "telegram"`): `{ groupId: string, driverToken: string, sutToken: string }` — `groupId` має бути числовим рядком chat-id.
- Discord (`kind: "discord"`): `{ guildId: string, channelId: string, driverBotToken: string, sutBotToken: string, sutApplicationId: string }`.
Операційні змінні середовища та контракт endpoint брокера Convex наведені в [Тестування → Спільні облікові дані Telegram через Convex](/uk/help/testing#shared-telegram-credentials-via-convex-v1) (назва розділу передує підтримці Discord; семантика брокера ідентична для обох типів).
Операційні env vars і контракт endpoint брокера Convex описані в [Тестування → Спільні облікові дані Telegram через Convex](/uk/help/testing#shared-telegram-credentials-via-convex-v1) (назва розділу передує підтримці Discord; семантика брокера однакова для обох типів).
## Seeds із репозиторію
## Seeds на основі репозиторію
Seed-активи розміщені в `qa/`:
- `qa/scenarios/index.md`
- `qa/scenarios/<theme>/*.md`
Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
агенту.
Вони навмисно зберігаються в git, щоб план QA був видимим і для людей, і для
агента.
`qa-lab` має залишатися універсальним runner для Markdown. Кожен Markdown-файл сценарію є
`qa-lab` має залишатися універсальним runner для markdown. Кожен markdown-файл сценарію є
джерелом істини для одного тестового запуску й має визначати:
- метадані сценарію
- необов’язкові метадані категорії, capability, lane і ризику
- посилання на документацію та код
- необов’язкові вимоги до Plugin
- необов’язковий patch конфігурації gateway
- необов'язкові метадані категорії, capability, lane і ризику
- посилання на docs і code
- необов'язкові вимоги до plugin
- необов'язковий patch конфігурації gateway
- виконуваний `qa-flow`
Багаторазово використовувана runtime-поверхня, що підтримує `qa-flow`, може залишатися універсальною
та наскрізною. Наприклад, Markdown-сценарії можуть поєднувати помічники транспортної сторони
з помічниками браузерної сторони, які керують вбудованим Control UI через
Повторно використовувана runtime-поверхня, що підтримує `qa-flow`, може залишатися універсальною
та наскрізною. Наприклад, markdown-сценарії можуть поєднувати helpers транспортної сторони
з helpers браузерної сторони, які керують вбудованим Control UI через
Gateway `browser.request` seam без додавання runner для спеціального випадку.
Файли сценаріїв слід групувати за capability продукту, а не за папкою дерева
джерел. Зберігайте ідентифікатори сценаріїв стабільними під час переміщення файлів; використовуйте `docsRefs` і `codeRefs`
для трасованості реалізації.
джерел. Зберігайте ID сценаріїв стабільними, коли файли переміщуються; використовуйте `docsRefs` і `codeRefs`
для простежуваності реалізації.
Базовий список має залишатися достатньо широким, щоб охоплювати:
Базовий список має залишатися достатньо широким, щоб покривати:
- DM і чат каналу
- поведінку thread
- життєвий цикл дій повідомлення
- callback-и cron
- пригадування пам’яті
- життєвий цикл дій із повідомленнями
- callbacks Cron
- пригадування пам'яті
- перемикання моделей
- передавання subagent
- читання репозиторію та читання документації
- одне невелике завдання збірки, наприклад Lobster Invaders
- читання репозиторію та читання docs
- одне невелике завдання збірки, як-от Lobster Invaders
## Mock lanes провайдера
`qa suite` має дві локальні mock lanes провайдера:
- `mock-openai` — scenario-aware mock OpenClaw. Він залишається типовим
детермінованим mock lane для QA з репозиторію та parity gates.
- `aimock` запускає сервер провайдера на базі AIMock для експериментального протоколу,
- `mock-openai` — сценарно-обізнаний mock OpenClaw. Він залишається типовою
детермінованою mock lane для QA на основі репозиторію та parity gates.
- `aimock` запускає сервер провайдера на базі AIMock для експериментального protocol,
fixture, record/replay і chaos coverage. Він є додатковим і не
замінює диспетчер сценаріїв `mock-openai`.
Реалізація provider-lane розміщена в `extensions/qa-lab/src/providers/`.
Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера, конфігурацією моделей gateway,
потребами staging auth-profile і прапорами live/mock capability. Спільний код suite і
gateway має проходити через registry провайдерів замість розгалуження за
Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера, конфігурацією моделі gateway,
потребами staged auth-profile і прапорами capability live/mock. Спільний код suite і
gateway має маршрутизувати через registry провайдера замість розгалуження за
іменами провайдерів.
## Транспортні адаптери
`qa-lab` володіє універсальним транспортним seam для Markdown QA-сценаріїв. `qa-channel` — перший адаптер на цьому seam, але ціль дизайну ширша: майбутні справжні або синтетичні канали мають підключатися до того самого suite runner замість додавання transport-specific QA runner.
`qa-lab` володіє універсальним transport seam для markdown QA-сценаріїв. `qa-channel` — перший адаптер на цьому seam, але ціль дизайну ширша: майбутні реальні або синтетичні канали мають підключатися до того самого suite runner замість додавання транспортно-специфічного QA runner.
На рівні архітектури поділ такий:
- `qa-lab` володіє універсальним виконанням сценаріїв, concurrency worker-ів, записом артефактів і звітуванням.
- Транспортний адаптер володіє конфігурацією gateway, readiness, вхідним і вихідним спостереженням, транспортними діями та нормалізованим станом транспорту.
- Markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає багаторазово використовувану runtime-поверхню, яка їх виконує.
- `qa-lab` володіє універсальним виконанням сценаріїв, concurrency worker, записом артефактів і звітністю.
- Транспортний адаптер володіє конфігурацією gateway, готовністю, inbound і outbound спостереженням, транспортними діями та нормалізованим транспортним станом.
- Markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає повторно використовувану runtime-поверхню, яка їх виконує.
### Додавання каналу
Додавання каналу до системи Markdown QA потребує рівно двох речей:
Додавання каналу до markdown-системи QA потребує рівно двох речей:
1. Транспортного адаптера для каналу.
2. Пакета сценаріїв, який перевіряє контракт каналу.
Не додавайте новий top-level корінь команди QA, коли спільний хост `qa-lab` може володіти потоком.
Не додавайте новий кореневий QA command верхнього рівня, коли спільний хост `qa-lab` може володіти flow.
`qa-lab` володіє спільною механікою хоста:
- коренем команди `openclaw qa`
- запуском і teardown suite
- concurrency worker-ів
- записом артефактів
- генерацією звітів
- виконанням сценаріїв
- корінь команди `openclaw qa`
- запуск і teardown suite
- concurrency worker
- запис артефактів
- генерація звіту
- виконання сценаріїв
- compatibility aliases для старіших сценаріїв `qa-channel`
Runner plugins володіють транспортним контрактом:
- як `openclaw qa <runner>` монтується під спільним коренем `qa`
- як gateway конфігурується для цього транспорту
- як перевіряється readiness
- як інжектуються вхідні події
- як спостерігаються вихідні повідомлення
- як експонуються transcripts і нормалізований стан транспорту
- як виконуються transport-backed дії
- як обробляється transport-specific reset або cleanup
- як перевіряється готовність
- як вводяться inbound-події
- як спостерігаються outbound-повідомлення
- як transcripts і нормалізований транспортний стан надаються назовні
- як виконуються дії, підтримувані транспортом
- як обробляється транспортно-специфічне скидання або очищення
Мінімальна планка прийняття для нового каналу:
Мінімальна планка adoption для нового каналу:
1. Зберігайте `qa-lab` власником спільного кореня `qa`.
2. Реалізуйте transport runner на спільному host seam `qa-lab`.
3. Тримайте transport-specific механіку всередині runner plugin або channel harness.
4. Монтуйте runner як `openclaw qa <runner>` замість реєстрації конкуруючої кореневої команди. Runner plugins мають оголошувати `qaRunners` у `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` із `runtime-api.ts`. Зберігайте `runtime-api.ts` легким; lazy CLI та виконання runner мають залишатися за окремими entrypoints.
5. Напишіть або адаптуйте Markdown-сценарії в тематичних директоріях `qa/scenarios/`.
6. Використовуйте універсальні помічники сценаріїв для нових сценаріїв.
3. Тримайте транспортно-специфічну механіку всередині runner plugin або channel harness.
4. Монтуйте runner як `openclaw qa <runner>` замість реєстрації конкуруючої root command. Runner plugins мають оголошувати `qaRunners` в `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` із `runtime-api.ts`. Тримайте `runtime-api.ts` легким; lazy CLI і виконання runner мають залишатися за окремими entrypoints.
5. Створіть або адаптуйте markdown-сценарії в тематичних директоріях `qa/scenarios/`.
6. Використовуйте універсальні helpers сценаріїв для нових сценаріїв.
7. Зберігайте наявні compatibility aliases робочими, якщо репозиторій не виконує навмисну міграцію.
Правило ухвалення рішення суворе:
Правило ухвалення рішень суворе:
- Якщо поведінку можна виразити один раз у `qa-lab`, розмістіть її в `qa-lab`.
- Якщо поведінка залежить від одного транспорту каналу, тримайте її в цьому runner plugin або plugin harness.
- Якщо сценарію потрібна нова capability, яку може використовувати більше ніж один канал, додайте універсальний помічник замість channel-specific гілки в `suite.ts`.
- Якщо поведінка має сенс лише для одного транспорту, залиште сценарій transport-specific і явно вкажіть це в контракті сценарію.
- Якщо поведінку можна виразити один раз у `qa-lab`, помістіть її в `qa-lab`.
- Якщо поведінка залежить від транспорту одного каналу, тримайте її в цьому runner plugin або plugin harness.
- Якщо сценарію потрібна нова capability, яку може використовувати більше ніж один канал, додайте універсальний helper замість гілки, специфічної для каналу, у `suite.ts`.
- Якщо поведінка має сенс лише для одного транспорту, залиште сценарій транспортно-специфічним і зробіть це явним у контракті сценарію.
### Назви помічників сценаріїв
### Назви helpers сценаріїв
Бажані універсальні помічники для нових сценаріїв:
Бажані універсальні helpers для нових сценаріїв:
- `waitForTransportReady`
- `waitForChannelReady`
@ -413,11 +412,11 @@ Runner plugins володіють транспортним контрактом:
- `formatTransportTranscript`
- `resetTransport`
Аліаси сумісності залишаються доступними для наявних сценаріїв — `waitForQaChannelReady`, `waitForOutboundMessage`, `waitForNoOutbound`, `formatConversationTranscript`, `resetBus` — але під час створення нових сценаріїв слід використовувати загальні назви. Аліаси існують, щоб уникнути одноразової примусової міграції, а не як модель на майбутнє.
Сумісні псевдоніми залишаються доступними для наявних сценаріїв — `waitForQaChannelReady`, `waitForOutboundMessage`, `waitForNoOutbound`, `formatConversationTranscript`, `resetBus` — але для написання нових сценаріїв слід використовувати загальні назви. Псевдоніми існують, щоб уникнути міграції в один день, а не як модель на майбутнє.
## Звітування
`qa-lab` експортує Markdown-звіт протоколу зі спостереженої часової шкали bus.
`qa-lab` експортує протокольний Markdown-звіт зі спостережуваної часової шкали шини.
Звіт має відповідати на такі питання:
- Що спрацювало
@ -425,10 +424,10 @@ Runner plugins володіють транспортним контрактом:
- Що залишилося заблокованим
- Які подальші сценарії варто додати
Для інвентаризації доступних сценаріїв — корисної під час оцінювання обсягу подальшої роботи або підключення нового транспорту — запустіть `pnpm openclaw qa coverage` (додайте `--json` для машиночитаного виводу).
Щоб отримати інвентар доступних сценаріїв — корисний під час оцінювання обсягу подальшої роботи або підключення нового транспорту — виконайте `pnpm openclaw qa coverage` (додайте `--json` для машинозчитуваного виводу).
Для перевірок характеру й стилю запустіть той самий сценарій для кількох live refs моделей
і запишіть оцінений Markdown-звіт:
Для перевірок характеру й стилю запустіть той самий сценарій для кількох живих
референсів моделей і запишіть оцінений Markdown-звіт:
```bash
pnpm openclaw qa character-eval \
@ -447,41 +446,41 @@ pnpm openclaw qa character-eval \
--judge-concurrency 16
```
Команда запускає локальні дочірні процеси QA gateway, а не Docker. Сценарії оцінювання характеру
мають задавати persona через `SOUL.md`, а потім виконувати звичайні ходи користувача,
як-от чат, допомога з workspace і невеликі файлові завдання. Кандидатській моделі
Команда запускає локальні дочірні процеси QA Gateway, а не Docker. Сценарії оцінювання
характеру мають задавати персону через `SOUL.md`, а потім виконувати звичайні ходи
користувача, як-от чат, допомога з робочою областю та невеликі файлові завдання. Моделі-кандидату
не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
транскрипт, записує базову статистику запуску, а потім просить judge models у fast mode з
`xhigh` reasoning, де це підтримується, ранжувати запуски за природністю, vibe та гумором.
Використовуйте `--blind-judge-models`, коли порівнюєте провайдерів: judge prompt усе одно отримує
кожен транскрипт і статус запуску, але candidate refs замінюються нейтральними
мітками на кшталт `candidate-01`; після парсингу звіт зіставляє рейтинги з реальними refs.
Запуски кандидатів за замовчуванням використовують `high` thinking, з `medium` для GPT-5.5 і `xhigh`
для старіших OpenAI eval refs, які це підтримують. Перевизначте конкретного кандидата inline за допомогою
`--model provider/model,thinking=<level>`. `--thinking <level>` усе ще задає
глобальний fallback, а старіша форма `--model-thinking <provider/model=level>` зберігається
для сумісності.
OpenAI candidate refs за замовчуванням використовують fast mode, щоб priority processing застосовувався там, де
провайдер це підтримує. Додайте `,fast`, `,no-fast` або `,fast=false` inline, коли
окремому кандидату або судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
примусово ввімкнути fast mode для кожної кандидатської моделі. Тривалості запусків кандидатів і суддів
записуються у звіт для аналізу benchmark, але judge prompts явно вказують
транскрипт, записує базову статистику запуску, а потім просить моделі-судді в швидкому режимі з
міркуванням `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` лише тоді, коли хочете
примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалості кандидатів і суддів
записуються у звіт для бенчмарк-аналізу, але промпти суддів явно вказують
не ранжувати за швидкістю.
Запуски кандидатських і суддівських моделей обидва за замовчуванням використовують concurrency 16. Зменшіть
`--concurrency` або `--judge-concurrency`, коли ліміти провайдера або навантаження на локальний Gateway
Запуски моделей-кандидатів і моделей-суддів за замовчуванням мають concurrency 16. Зменште
`--concurrency` або `--judge-concurrency`, коли ліміти провайдера чи навантаження на локальний Gateway
роблять запуск надто шумним.
Коли candidate `--model` не передано, character eval за замовчуванням використовує
Коли не передано жодного кандидата `--model`, оцінювання характеру за замовчуванням використовує
`openai/gpt-5.5`, `openai/gpt-5.2`, `openai/gpt-5`, `anthropic/claude-opus-4-6`,
`anthropic/claude-sonnet-4-6`, `zai/glm-5.1`,
`moonshot/kimi-k2.5` і
`google/gemini-3.1-pro-preview`, якщо `--model` не передано.
Коли `--judge-model` не передано, judges за замовчуванням використовують
Коли не передано `--judge-model`, судді за замовчуванням такі:
`openai/gpt-5.5,thinking=xhigh,fast` і
`anthropic/claude-opus-4-6,thinking=high`.
## Пов’язані документи
## Пов’язана документація
- [Matrix QA](/uk/concepts/qa-matrix)
- [QA Channel](/uk/channels/qa-channel)
- [Матричне QA](/uk/concepts/qa-matrix)
- [Канал QA](/uk/channels/qa-channel)
- [Тестування](/uk/help/testing)
- [Dashboard](/uk/web/dashboard)
- [Панель керування](/uk/web/dashboard)