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-04 00:36:45 +00:00
parent 99d232a83c
commit 7c547b21e2
2 changed files with 439 additions and 421 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,85 +1,85 @@
---
read_when:
- Створення або запуск візуального контролю якості в реальному часі для помилок OpenClaw
- Створення або запуск візуального QA у реальному часі для помилок OpenClaw
- Додавання перевірки «до» та «після» для запиту на злиття
- Додавання сценаріїв Discord, Slack, WhatsApp або інших транспортів у реальному часі
- Налагодження QA-запусків, яким потрібні знімки екрана, автоматизація браузера або доступ через VNC
- Додавання сценаріїв Discord, Slack, WhatsApp або інших живих транспортів
- Налагодження запусків QA, яким потрібні знімки екрана, автоматизація браузера або доступ VNC
summary: Mantis — це система візуальної наскрізної перевірки для відтворення помилок OpenClaw на реальних транспортах, фіксації доказів до й після та прикріплення артефактів до запитів на злиття.
title: Богомол
x-i18n:
generated_at: "2026-05-03T20:39:44Z"
generated_at: "2026-05-04T00:35:16Z"
model: gpt-5.5
provider: openai
source_hash: 3463882b01a7941f6d758c509d6cd70e099aa8352053347fa9c37a80e5b256ce
source_hash: 7d1fe1e6cb57406fab351892b43c7057a0d08e26455d76a50157f958474e363e
source_path: concepts/mantis.md
workflow: 16
---
Mantis — це система наскрізної верифікації OpenClaw для помилок, яким потрібні справжній
runtime, справжній транспорт і видимий доказ. Вона запускає сценарій проти відомого
поганого ref, збирає докази, запускає той самий сценарій проти кандидатного ref і
публікує порівняння як артефакти, які maintainer може перевірити з PR або
Mantis — це система наскрізної перевірки OpenClaw для помилок, яким потрібні справжнє
середовище виконання, справжній транспорт і видимий доказ. Вона запускає сценарій на відомому
поганому ref, збирає докази, запускає той самий сценарій на кандидатному ref і
публікує порівняння як артефакти, які мейнтейнер може переглянути з PR або
з локальної команди.
Mantis починає з Discord, тому що Discord дає нам високовартісну першу лінію:
справжню автентифікацію бота, справжні канали guild, реакції, threads, нативні команди та
браузерний UI, де люди можуть візуально підтвердити те, що показав транспорт.
Mantis починає з Discord, тому що Discord дає нам цінну першу смугу:
справжню автентифікацію бота, справжні канали guild, реакції, треди, нативні команди та
інтерфейс браузера, де люди можуть візуально підтвердити, що показав транспорт.
## Цілі
- Відтворити помилку з GitHub issue або PR з тією самою формою транспорту, яку бачать
користувачі.
- Зібрати артефакт **before** на baseline ref перед застосуванням виправлення.
- Зібрати артефакт **after** на candidate ref після застосування виправлення.
- Використовувати детермінований oracle, коли це можливо, наприклад читання реакції через Discord REST
або перевірку transcript каналу.
- Збирати screenshots, коли помилка має видиму UI-поверхню.
- Запускати локально з керованого агентом CLI і віддалено з GitHub.
- Зберігати достатньо стану машини для VNC-відновлення, коли вхід, браузерна автоматизація або
автентифікація provider застрягає.
- Публікувати стислий статус в operator Discord channel, коли запуск заблоковано,
потрібна ручна VNC-допомога або запуск завершено.
- Зібрати артефакт **до** на baseline ref перед застосуванням виправлення.
- Зібрати артефакт **після** на кандидатному ref після застосування виправлення.
- Використовувати детермінований оракул, коли це можливо, наприклад читання реакції через Discord REST
або перевірку транскрипту каналу.
- Знімати скриншоти, коли помилка має видиму поверхню UI.
- Запускатися локально з CLI, керованого агентом, і віддалено з GitHub.
- Зберігати достатньо стану машини для VNC-порятунку, коли вхід, автоматизація браузера або
автентифікація провайдера застрягають.
- Публікувати стислий статус в операторський канал Discord, коли запуск заблокований,
потребує ручної допомоги через VNC або завершується.
## Нецілі
- Mantis не є заміною для unit tests. Запуск Mantis зазвичай має ставати
меншим regression test після того, як виправлення зрозуміле.
- Mantis не є звичайним швидким CI gate. Він повільніший, використовує live credentials і
зарезервований для помилок, де live environment має значення.
- Mantis не має вимагати участі людини для звичайної роботи. Ручний VNC — це шлях відновлення,
а не happy path.
- Mantis не зберігає raw secrets в artifacts, logs, screenshots, Markdown
reports або PR comments.
- Mantis не є заміною юніт-тестів. Запуск Mantis зазвичай має стати
меншим регресійним тестом після того, як виправлення стане зрозумілим.
- Mantis не є звичайним швидким CI-гейтом. Він повільніший, використовує живі облікові дані та
призначений для помилок, де живе середовище має значення.
- Mantis не має вимагати людини для звичайної роботи. Ручний VNC — це шлях порятунку,
а не основний шлях.
- Mantis не зберігає необроблені секрети в артефактах, логах, скриншотах, Markdown
звітах або коментарях PR.
## Власність
Mantis живе в OpenClaw QA stack.
Mantis належить до QA-стека OpenClaw.
- OpenClaw володіє scenario runtime, transport adapters, evidence schema і
- OpenClaw володіє середовищем виконання сценаріїв, транспортними адаптерами, схемою доказів і
локальним 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 comment routing: розбором maintainer commands,
dispatch workflow і публікацією фінального PR comment.
- OpenClaw agents керують Mantis через Codex, коли сценарію потрібні agentic setup,
debugging або stuck-state reporting.
- QA Lab володіє частинами живого транспортного harness, допоміжними засобами захоплення браузера та
записувачами артефактів.
- Crabbox володіє прогрітими Linux-машинами, коли потрібна віддалена VM.
- GitHub Actions володіє віддаленою точкою входу workflow і збереженням артефактів.
- ClawSweeper володіє маршрутизацією коментарів GitHub: розбором команд мейнтейнерів,
запуском workflow і публікацією фінального коментаря PR.
- Агенти OpenClaw керують Mantis через Codex, коли сценарію потрібні агентне налаштування,
налагодження або звітування про застряглий стан.
Ця межа утримує знання про транспорт в OpenClaw, планування машин у
Crabbox, а maintainer workflow glue — у ClawSweeper.
Crabbox, а клей мейнтейнерського workflow — у ClawSweeper.
## Форма команди
Перша локальна команда перевіряє Discord bot, guild, channel, message send,
reaction send і artifact path:
Перша локальна команда перевіряє бота Discord, guild, канал, надсилання повідомлення,
надсилання реакції та шлях артефактів:
```bash
pnpm openclaw qa mantis discord-smoke \
--output-dir .artifacts/qa-e2e/mantis/discord-smoke
```
Локальний before і after runner приймає таку форму:
Локальний runner до і після приймає таку форму:
```bash
pnpm openclaw qa mantis run \
@ -90,34 +90,55 @@ pnpm openclaw qa mantis run \
--output-dir .artifacts/qa-e2e/mantis/local-discord-status-reactions
```
Runner створює detached baseline і candidate worktrees під output
directory, встановлює dependencies, збирає кожен ref, запускає scenario з
Runner створює від’єднані worktree baseline і candidate під вихідним
каталогом, встановлює залежності, збирає кожен ref, запускає сценарій з
`--allow-failures`, потім записує `baseline/`, `candidate/`, `comparison.json`
і `mantis-report.md`. Для першого Discord scenario успішна верифікація
означає, що baseline status — `fail`, а candidate status — `pass`.
і `mantis-report.md`. Для першого сценарію Discord успішна перевірка
означає, що статус baseline — `fail`, а статус candidate — `pass`.
GitHub smoke workflow — це `Mantis Discord Smoke`. Before і after GitHub
workflow для першого справжнього scenario — це `Mantis Discord Status Reactions`. Він
Перший примітив VM/браузера — desktop smoke:
```bash
pnpm openclaw qa mantis desktop-browser-smoke \
--output-dir .artifacts/qa-e2e/mantis/desktop-browser
```
Він орендує або повторно використовує desktop-машину Crabbox, запускає видимий браузер усередині
VNC-сесії, захоплює desktop, витягує артефакти назад у локальний вихідний
каталог і записує команду повторного підключення у звіт. Команда за замовчуванням
використовує провайдера Hetzner, тому що це перший провайдер із робочим покриттям desktop/VNC
у смузі Mantis. Перевизначте його через `--provider`, `--crabbox-bin` або
`OPENCLAW_MANTIS_CRABBOX_PROVIDER`, коли запускаєте проти іншого флоту Crabbox.
Корисні прапорці desktop smoke:
- `--lease-id <cbx_...>` або `OPENCLAW_MANTIS_CRABBOX_LEASE_ID` повторно використовує прогрітий desktop.
- `--browser-url <url>` змінює сторінку, відкриту у видимому браузері.
- `--keep-lease` або `OPENCLAW_MANTIS_KEEP_VM=1` залишає новостворену успішну оренду відкритою для VNC-інспекції. Невдалі запуски за замовчуванням залишають оренду, якщо її було створено, щоб оператор міг перепідключитися.
- `--class`, `--idle-timeout` і `--ttl` налаштовують розмір машини та час життя оренди.
GitHub smoke workflow — це `Mantis Discord Smoke`. GitHub workflow до і після
для першого реального сценарію — `Mantis Discord Status Reactions`. Він
приймає:
- `baseline_ref`: ref, від якого очікується відтворення queued-only behavior.
- `candidate_ref`: ref, від якого очікується показ `queued -> thinking -> done`.
- `baseline_ref`: ref, який, як очікується, відтворює поведінку лише queued.
- `candidate_ref`: ref, який, як очікується, показує `queued -> thinking -> done`.
Він checkout workflow harness ref, збирає окремі baseline і candidate
worktrees, запускає `discord-status-reactions-tool-only` проти кожного worktree і
Він checkout-ить ref workflow harness, збирає окремі worktree baseline і candidate,
запускає `discord-status-reactions-tool-only` проти кожного worktree і
завантажує `baseline/`, `candidate/`, `comparison.json` і `mantis-report.md` як
Actions artifacts.
артефакти Actions.
Ви також можете запустити status-reactions run напряму з PR comment:
Ви також можете запустити status-reactions run напряму з коментаря PR:
```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 можуть перевизначити будь-який
Тригер коментаря навмисно вузький. Він запускається лише на коментарях pull request
від користувачів із доступом write, maintain або admin, і розпізнає лише
запити status-reaction Discord. За замовчуванням він використовує відомий поганий baseline ref
і поточний SHA head PR як candidate. Мейнтейнери можуть перевизначити будь-який
ref:
```text
@ -131,50 +152,51 @@ ref:
@clawsweeper verify e2e discord
```
Перша команда явна й зосереджена на scenario. Друга пізніше може зіставляти PR
або issue з рекомендованими Mantis scenarios на основі labels, changed files і
ClawSweeper review findings.
Перша команда явна й зосереджена на сценарії. Друга згодом може зіставляти PR
або issue з рекомендованими сценаріями Mantis на основі міток, змінених файлів і
знахідок рев’ю ClawSweeper.
## Життєвий цикл запуску
1. Отримати credentials.
1. Отримати облікові дані.
2. Виділити або повторно використати VM.
3. Підготувати clean checkout для baseline ref.
4. Встановити dependencies і зібрати лише те, що потрібно scenario.
5. Запустити дочірній OpenClaw Gateway з ізольованим 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. Завантажити GitHub Actions artifacts.
14. Опублікувати стислий PR або Discord status message.
3. Підготувати desktop/профіль браузера, коли сценарію потрібні докази UI.
4. Підготувати чистий checkout для baseline ref.
5. Встановити залежності та зібрати лише те, що потрібно сценарію.
6. Запустити дочірній OpenClaw Gateway з ізольованим каталогом стану.
7. Налаштувати живий транспорт, провайдера, модель і профіль браузера.
8. Запустити сценарій і зібрати докази baseline.
9. Зупинити gateway і зберегти логи.
10. Підготувати candidate ref у тій самій VM.
11. Запустити той самий сценарій і зібрати докази candidate.
12. Порівняти результати оракула та візуальні докази.
13. Записати Markdown, JSON, логи, скриншоти та необов’язкові trace-артефакти.
14. Завантажити артефакти GitHub Actions.
15. Опублікувати стислий статусний допис у PR або Discord.
Scenario має вміти завершуватися невдачею двома різними способами:
Сценарій має бути здатний завершуватися невдачею двома різними способами:
- **Помилку відтворено**: baseline failed очікуваним способом.
- **Помилка harness**: environment setup, credentials, Discord API, browser або
provider failed до того, як bug oracle став meaningful.
- **Помилку відтворено**: baseline завершився невдачею очікуваним способом.
- **Збій harness**: налаштування середовища, облікові дані, Discord API, браузер або
провайдер зазнали збою до того, як оракул помилки став meaningful.
Фінальний report має розділяти ці випадки, щоб maintainers не плутали flaky
environment із product behavior.
Фінальний звіт має розділяти ці випадки, щоб мейнтейнери не плутали нестабільне
середовище з поведінкою продукту.
## Discord MVP
Перший scenario має таргетувати Discord status reactions у guild channels, де
source reply delivery mode — `message_tool_only`.
Перший сценарій має націлюватися на status reactions Discord у guild-каналах, де
режим доставки вихідної відповіді — `message_tool_only`.
Чому це хороший seed для Mantis:
Чому це хороший початковий сценарій Mantis:
- Це видно в Discord як reactions на triggering message.
- Він має сильний REST oracle через Discord message reaction state.
- Він вправляє справжній OpenClaw Gateway, Discord bot auth, message dispatch,
source reply delivery mode, status reaction state і model turn lifecycle.
- Він видимий у Discord як реакції на повідомлення, що запускає сценарій.
- Він має сильний REST-оракул через стан реакцій повідомлення Discord.
- Він перевіряє справжній OpenClaw Gateway, автентифікацію бота Discord, диспетчеризацію повідомлень,
режим доставки вихідної відповіді, стан status reaction і життєвий цикл модельного turn.
- Він достатньо вузький, щоб перша реалізація залишалася чесною.
Очікувана форма scenario:
Очікувана форма сценарію:
```yaml
id: discord-status-reactions-tool-only
@ -205,12 +227,12 @@ evidence:
screenshotMessageRow: true
```
Baseline evidence має показувати queued acknowledgement reaction, але без
lifecycle transition у tool-only mode. Candidate evidence має показувати lifecycle
status reactions, що виконуються, коли `messages.statusReactions.enabled` явно
true.
Докази baseline мають показувати queued acknowledgement reaction, але без
lifecycle transition у режимі tool-only. Докази candidate мають показувати, що lifecycle
status reactions працюють, коли `messages.statusReactions.enabled` явно
дорівнює true.
Виконуваний перший slice — це opt-in Discord live QA scenario:
Виконуваний перший зріз — це opt-in живий QA-сценарій Discord:
```bash
pnpm openclaw qa discord \
@ -222,34 +244,34 @@ pnpm openclaw qa discord \
--output-dir .artifacts/qa-e2e/mantis/discord-status-reactions-candidate
```
Він налаштовує SUT з always-on guild handling, `visibleReplies:
"message_tool"`, `ackReaction: "👀"` і явними status reactions. Oracle
опитує справжній Discord triggering message і очікує observed sequence
`👀 -> 🤔 -> 👍`. Artifacts включають `discord-qa-reaction-timelines.json`,
Він налаштовує SUT із завжди ввімкненою обробкою guild, `visibleReplies:
"message_tool"`, `ackReaction: "👀"` і явними status reactions. Оракул
опитує справжнє повідомлення Discord, що запустило сценарій, і очікує спостережувану послідовність
`👀 -> 🤔 -> 👍`. Артефакти містять `discord-qa-reaction-timelines.json`,
`discord-status-reactions-tool-only-timeline.html` і
`discord-status-reactions-tool-only-timeline.png`.
## Наявні частини QA
## Наявні компоненти QA
Mantis має будуватися на наявному private QA stack, а не починати з
Mantis має будуватися на наявному приватному QA-стеку, а не починати з
нуля:
- `pnpm openclaw qa discord` вже запускає live Discord lane з driver і
SUT bots.
- Live transport runner уже записує reports і observed-message
artifacts під `.artifacts/qa-e2e/`.
- Convex credential leases уже надають ексклюзивний доступ до shared live
transport credentials.
- Browser control service уже підтримує screenshots, snapshots,
headless managed profiles і remote CDP profiles.
- QA Lab уже має debugger UI і bus для transport-shaped testing.
- `pnpm openclaw qa discord` уже запускає живу смугу Discord з ботами driver і
SUT.
- Живий transport runner уже записує звіти та артефакти observed-message
під `.artifacts/qa-e2e/`.
- Оренди облікових даних Convex уже надають ексклюзивний доступ до спільних живих
транспортних облікових даних.
- Сервіс керування браузером уже підтримує скриншоти, snapshots,
headless керовані профілі та віддалені CDP-профілі.
- QA Lab уже має UI налагоджувача й шину для тестування у формі транспорту.
Перша реалізація Mantis може бути тонким before/after runner поверх цих
частин, плюс один шар visual evidence.
Перша реалізація Mantis може бути тонким runner до/після над цими
компонентами плюс один шар візуальних доказів.
## Модель доказів
Кожен запуск записує стабільний artifact directory:
Кожен запуск записує стабільний каталог артефактів:
```text
.artifacts/qa-e2e/mantis/<run-id>/
@ -269,79 +291,79 @@ Mantis має будуватися на наявному private QA stack, а н
run.log
```
`mantis-summary.json` має бути machine-readable source of truth. Markdown
report призначений для PR comments і human review.
`mantis-summary.json` має бути машинозчитуваним джерелом істини. Markdown
звіт призначений для коментарів PR і людського рев’ю.
Summary має включати:
Підсумок має містити:
- refs і SHAs, які тестувалися
- протестовані refs і SHA
- transport і scenario id
- machine provider і machine id або lease id
- credential source без secret values
- baseline result
- candidate result
- чи помилка відтворилася на baseline
- чи candidate її виправив
- artifact paths
- sanitized setup або cleanup issues
- провайдера машини та machine id або lease id
- джерело облікових даних без значень секретів
- результат baseline
- результат candidate
- чи помилку відтворено на baseline
- чи candidate виправив її
- шляхи артефактів
- санітизовані проблеми налаштування або очищення
Screenshots — це evidence, а не secrets. Вони все одно потребують дисципліни redaction:
private channel names, user names або message content можуть з’явитися. Для public PRs
віддавайте перевагу GitHub Actions artifact links замість inline images, доки redaction story
не стане сильнішою.
Скриншоти — це докази, а не секрети. Вони все одно потребують дисципліни редагування:
можуть з’являтися назви приватних каналів, імена користувачів або вміст повідомлень. Для публічних PR
надавайте перевагу посиланням на артефакти GitHub Actions замість inline-зображень, доки історія
редагування не стане сильнішою.
## Browser і VNC
## Браузер і VNC
Browser lane має два modes:
Смуга браузера має два режими:
- **Headless automation**: за замовчуванням для CI. Chrome запускається з увімкненим CDP, а
Playwright або OpenClaw browser control збирає screenshots.
- **VNC rescue**: увімкнено на тій самій VM, коли login, MFA, Discord anti-automation
або visual debugging потребує людини.
- **Headless automation**: стандартно для CI. Chrome запускається з увімкненим CDP, а
Playwright або керування браузером OpenClaw захоплює скриншоти.
- **VNC rescue**: увімкнено на тій самій VM, коли вхід, MFA, антиавтоматизація Discord
або візуальне налагодження потребують людини.
Discord observer browser profile має бути достатньо persistent, щоб уникати
login для кожного run, але ізольованим від personal browser state. Profile
належить Mantis machine pool, а не developer laptop.
Профіль браузера спостерігача Discord має бути достатньо persistent, щоб не доводилося
входити під час кожного запуску, але ізольованим від особистого стану браузера. Профіль
належить пулу машин Mantis, а не ноутбуку розробника.
Коли Mantis застрягає, він публікує Discord status message з:
Коли Mantis застрягає, він публікує статусне повідомлення Discord з:
- run id
- scenario id
- machine provider
- artifact directory
- VNC або noVNC connection instructions, якщо доступні
- короткий blocker text
- провайдером машини
- каталогом артефактів
- інструкціями підключення VNC або noVNC, якщо доступні
- коротким текстом блокера
Перше private deployment може публікувати ці messages в наявний operator
channel і пізніше перейти до dedicated Mantis channel.
Перше приватне розгортання може публікувати ці повідомлення в наявний канал
операторів і пізніше перейти до окремого каналу Mantis.
## Машини
Mantis має віддавати перевагу AWS через Crabbox для першої remote implementation.
Crabbox дає нам warmed machines, lease tracking, hydration, logs, results і
cleanup. Якщо AWS capacity занадто повільна або недоступна, додайте Hetzner provider
за тим самим machine interface.
Mantis має надавати перевагу AWS через Crabbox для першої віддаленої реалізації.
Crabbox дає нам розігріті машини, відстеження оренди, гідратацію, журнали, результати та
очищення. Якщо потужності AWS надто повільні або недоступні, додайте провайдера Hetzner
за тим самим інтерфейсом машин.
Мінімальні вимоги до VM:
- Linux із desktop-capable Chrome або Chromium install
- CDP access для browser automation
- VNC або noVNC для rescue
- Linux із встановленим Chrome або Chromium, здатним працювати з робочим столом
- доступ CDP для автоматизації браузера
- VNC або noVNC для відновлення
- Node 22 і pnpm
- OpenClaw checkout і dependency cache
- Playwright Chromium browser cache, коли використовується Playwright
- достатньо CPU і memory для одного OpenClaw Gateway, одного browser і одного model run
- outbound access до Discord, GitHub, model providers і credential broker
- клон OpenClaw і кеш залежностей
- кеш браузера Playwright Chromium, коли використовується Playwright
- достатньо CPU та пам’яті для одного OpenClaw Gateway, одного браузера й одного запуску моделі
- вихідний доступ до Discord, GitHub, провайдерів моделей і брокера облікових даних
VM не має зберігати long-lived raw secrets поза очікуваними credential або
browser profile stores.
VM не має зберігати довготривалі сирі секрети поза очікуваними сховищами облікових даних або
профілів браузера.
## Secrets
## Секрети
Secrets живуть у GitHub organization або repository secrets для remote runs, а в
local operator-controlled secret file — для local runs.
Секрети зберігаються в секретах організації або репозиторію GitHub для віддалених запусків і в
локальному файлі секретів під контролем оператора для локальних запусків.
Рекомендовані secret names:
Рекомендовані назви секретів:
- `OPENCLAW_QA_DISCORD_MANTIS_BOT_TOKEN`
- `OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN`
@ -349,61 +371,60 @@ local operator-controlled secret file — для local runs.
- `OPENCLAW_QA_DISCORD_GUILD_ID`
- `OPENCLAW_QA_DISCORD_CHANNEL_ID`
- `OPENCLAW_QA_DISCORD_NOTIFY_CHANNEL_ID`
- `OPENCLAW_QA_REDACT_PUBLIC_METADATA=1` для публічних завантажень артефактів GitHub
- `OPENCLAW_QA_REDACT_PUBLIC_METADATA=1` для завантаження публічних артефактів GitHub
- `OPENCLAW_QA_CONVEX_SITE_URL`
- `OPENCLAW_QA_CONVEX_SECRET_CI`
У довгостроковій перспективі пул облікових даних Convex має залишатися звичайним джерелом для live
облікових даних транспорту. Секрети GitHub початково налаштовують брокер і резервні лінії.
У довгостроковій перспективі пул облікових даних Convex має залишатися звичайним джерелом живих
облікових даних транспорту. Секрети GitHub початково завантажують брокер і резервні лінії.
Запускач Mantis ніколи не повинен друкувати:
- токени ботів Discord
- API-ключі провайдерів
- cookies браузера
- вміст профілю автентифікації
- вміст профілів автентифікації
- паролі VNC
- необроблені payload-и облікових даних
- сирі корисні навантаження облікових даних
Публічні завантаження артефактів також мають редагувати метадані цілі Discord, як-от ідентифікатори ботів,
гільдій, каналів і повідомлень. Smoke workflow GitHub вмикає
Публічні завантаження артефактів також мають редагувати цільові метадані Discord, як-от ідентифікатори ботів,
серверів, каналів і повідомлень. Робочий процес smoke GitHub вмикає
`OPENCLAW_QA_REDACT_PUBLIC_METADATA=1` саме з цієї причини.
Якщо токен випадково вставлено в issue, PR, чат або журнал, змініть його
після того, як новий секрет буде збережено.
Якщо токен випадково вставлено в issue, PR, чат або журнал, оберніть його
після збереження нового секрету.
## Артефакти GitHub і коментарі PR
Workflow-и Mantis мають завантажувати повний пакет доказів як короткоживучий артефакт Actions.
Коли workflow запускається для звіту про помилку або PR із виправленням, він також має
публікувати відредаговані PNG-знімки екрана в гілку `qa-artifacts` і upsert-ити
коментар до цієї помилки або PR із виправленням із вбудованими знімками до/після. Не публікуйте
основний доказ лише в загальному PR автоматизації QA. Необроблені журнали, спостережені
Робочі процеси Mantis мають завантажувати повний пакет доказів як короткоживучий артефакт Actions.
Коли робочий процес запускається для звіту про помилку або PR із виправленням, він також має
опублікувати відредаговані PNG-знімки екрана в гілку `qa-artifacts` і оновити або створити
коментар до цієї помилки чи PR із виправленням із вбудованими знімками до/після. Не публікуйте
основний доказ лише в загальному PR автоматизації QA. Сирі журнали, спостережені
повідомлення та інші об’ємні докази залишаються в артефакті Actions.
Production workflow-и мають публікувати ці коментарі через Mantis GitHub App, а не
через `github-actions[bot]`. Збережіть ідентифікатор застосунку та приватний ключ як
секрети GitHub Actions `MANTIS_GITHUB_APP_ID` і `MANTIS_GITHUB_APP_PRIVATE_KEY`.
Workflow використовує прихований маркер як ключ upsert, оновлює цей
коментар, коли токен може його редагувати, і створює новий коментар від імені Mantis, коли
старіший маркер, власником якого є бот, не можна відредагувати.
Виробничі робочі процеси мають публікувати ці коментарі через GitHub App Mantis, а не
через `github-actions[bot]`. Зберігайте app id і приватний ключ як секрети GitHub Actions
`MANTIS_GITHUB_APP_ID` і `MANTIS_GITHUB_APP_PRIVATE_KEY`. Робочий процес використовує прихований маркер
як ключ upsert, оновлює цей коментар, коли токен може його редагувати, і створює новий
коментар від імені Mantis, коли старіший маркер від бота не можна відредагувати.
Коментар PR має бути коротким і візуальним:
```md
QA реакцій статусу Discord у Mantis
Mantis Discord Status Reactions QA
Підсумок: Mantis повторно запустив повідомлену помилку реакції статусу Discord на відомій
поганій базовій версії та кандидатному виправленні. Базова версія відтворила помилку, тоді як
кандидат показав очікувану послідовність у черзі -> думає -> виконано.
Summary: Mantis reran the reported Discord status-reaction bug against the known
bad baseline and the candidate fix. The baseline reproduced the bug, while the
candidate showed the expected queued -> thinking -> done sequence.
- Сценарій: `discord-status-reactions-tool-only`
- Запуск: <workflow run link>
- Артефакт: <artifact link>
- Базова версія: `<status>` на `<sha>`
- Кандидат: `<status>` на `<sha>`
- Scenario: `discord-status-reactions-tool-only`
- Run: <workflow run link>
- Artifact: <artifact link>
- Baseline: `<status>` at `<sha>`
- Candidate: `<status>` at `<sha>`
| Базова версія | Кандидат |
| Baseline | Candidate |
| ------------------- | ------------------- |
| <inline screenshot> | <inline screenshot> |
```
@ -413,68 +434,65 @@ QA реакцій статусу Discord у Mantis
## Примітки щодо приватного розгортання
У приватному розгортанні вже може бути застосунок Mantis Discord. Повторно використовуйте цей
застосунок замість створення іншого, якщо він має правильні дозволи бота
і його можна безпечно ротувати.
Приватне розгортання вже може мати застосунок Discord Mantis. Використовуйте цей
застосунок повторно замість створення іншого app, якщо він має потрібні дозволи бота
і його можна безпечно обернути.
Налаштуйте початковий канал сповіщень оператора через секрети або конфігурацію
розгортання. Спочатку він може вказувати на наявний канал супровідників або операційний канал,
а потім перейти до виділеного каналу Mantis, коли такий з’явиться.
Задайте початковий канал сповіщень оператора через секрети або конфігурацію розгортання.
Спочатку він може вказувати на наявний канал мейнтейнерів або операцій, а потім перейти
до окремого каналу Mantis, щойно такий з’явиться.
Не додавайте ідентифікатори гільдій, ідентифікатори каналів, токени ботів, cookies браузера або паролі VNC
до цього документа. Зберігайте їх у секретах GitHub, брокері облікових даних або
локальному сховищі секретів оператора.
Не додавайте в цей документ ідентифікатори серверів, ідентифікатори каналів, токени ботів, cookies браузера або паролі VNC.
Зберігайте їх у секретах GitHub, брокері облікових даних або локальному сховищі секретів оператора.
## Додавання сценарію
Сценарій Mantis має оголошувати:
- id і назву
- id і title
- транспорт
- потрібні облікові дані
- політику ref для базової версії
- політику ref для кандидата
- необхідні облікові дані
- політику базового ref
- політику кандидатного ref
- патч конфігурації OpenClaw
- кроки налаштування
- стимул
- очікуваний oracle базової версії
- очікуваний oracle кандидата
- цілі візуального захоплення
- бюджет таймауту
- бюджет тайм-ауту
- кроки очищення
Сценарії мають надавати перевагу малим типізованим oracle:
Сценарії мають надавати перевагу невеликим типізованим oracle:
- стан реакцій Discord для помилок реакцій
- посилання на повідомлення Discord для помилок потоків
- ts потоку Slack і стан API реакцій для помилок Slack
- ідентифікатори повідомлень електронної пошти та заголовки для помилок електронної пошти
- знімки екрана браузера, коли UI є єдиним надійним спостережуваним джерелом
- thread ts Slack і стан API реакцій для помилок Slack
- ідентифікатори повідомлень і заголовки email для помилок email
- знімки екрана браузера, коли UI є єдиним надійним спостережуваним сигналом
Перевірки зору мають бути додатковими. Якщо API платформи може довести помилку, використовуйте
API як oracle успіху/невдачі та залишайте знімки екрана для впевненості людини.
Перевірки зором мають бути додатковими. Якщо API платформи може довести помилку, використовуйте
API як oracle проходження/збою, а знімки екрана залишайте для впевненості людини.
## Розширення провайдерів
Після Discord той самий запускач може додати:
- Slack: реакції, потоки, згадки застосунку, модальні вікна, завантаження файлів.
- Електронна пошта: автентифікація Gmail і потоки повідомлень за допомогою `gog`, коли конекторів
недостатньо.
- Slack: реакції, потоки, згадки app, модальні вікна, завантаження файлів.
- Email: автентифікація Gmail і потоки повідомлень із використанням `gog`, коли connectors недостатньо.
- WhatsApp: QR-вхід, повторна ідентифікація, доставка повідомлень, медіа, реакції.
- Telegram: обмеження згадок у групах, команди, реакції, де доступно.
- Telegram: gate для згадок у групах, команди, реакції там, де доступні.
- Matrix: зашифровані кімнати, зв’язки потоків або відповідей, відновлення після перезапуску.
Кожен транспорт має мати один дешевий smoke-сценарій і один або кілька сценаріїв
класу помилок. Дорогі візуальні сценарії мають залишатися opt-in.
Кожен транспорт має мати один дешевий smoke-сценарій і один або кілька сценаріїв класів помилок.
Дорогі візуальні сценарії мають залишатися opt-in.
## Відкриті питання
- Який бот Discord має бути драйвером, а який SUT, коли повторно використовується
наявний бот Mantis?
- Чи має вхід браузера спостерігача використовувати обліковий запис людини в Discord, тестовий обліковий запис
або лише REST-докази, доступні боту, для першої фази?
- Який бот Discord має бути driver, а який SUT, коли наявний бот Mantis використовується повторно?
- Чи має вхід браузера observer використовувати людський обліковий запис Discord, тестовий обліковий запис
або лише доступні боту REST-докази для першої фази?
- Як довго GitHub має зберігати артефакти Mantis для PR?
- Коли ClawSweeper має автоматично рекомендувати Mantis замість очікування
команди супровідника?
- Коли ClawSweeper має автоматично рекомендувати Mantis замість очікування команди
мейнтейнера?
- Чи потрібно редагувати або обрізати знімки екрана перед завантаженням для публічних PR?

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

@ -1,66 +1,66 @@
---
read_when:
- Розуміння того, як компоненти QA-стека працюють разом
- Розуміння того, як стек QA працює як єдине ціле
- Розширення qa-lab, qa-channel або транспортного адаптера
- Додавання QA-сценаріїв на основі репозиторію
- Створення QA-автоматизації з вищим рівнем реалістичності навколо панелі керування Gateway
- Побудова автоматизації QA з підвищеною реалістичністю навколо панелі керування Gateway
summary: 'Огляд стеку QA: qa-lab, qa-channel, сценарії на основі репозиторію, лінії реального транспорту, транспортні адаптери та звітування.'
title: Огляд забезпечення якості
x-i18n:
generated_at: "2026-05-03T22:25:51Z"
generated_at: "2026-05-04T00:35:17Z"
model: gpt-5.5
provider: openai
source_hash: 7553094890e20eb760df149ac8bd598048c023dc072743ffe2a8dd60d17382de
source_hash: 0b376767b967a51cc8a45ca5ce420f78067b52e6368d2abe921ffed533f6f9ba
source_path: concepts/qa-e2e-automation.md
workflow: 16
---
Приватний QA-стек призначений для перевірки OpenClaw у реалістичніший,
канально-орієнтований спосіб, ніж це може зробити один unit-тест.
Приватний QA-стек призначений для перевірки OpenClaw реалістичнішим,
схожим на канали способом, ніж це може зробити один модульний тест.
Поточні складові:
Поточні складники:
- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, треду,
реакції, редагування та видалення.
- `extensions/qa-lab`: UI відлагоджувача й QA-шина для спостереження за транскриптом,
- `extensions/qa-lab`: UI налагоджувача й QA-шина для спостереження за транскриптом,
ін’єкції вхідних повідомлень і експорту Markdown-звіту.
- `extensions/qa-matrix`, майбутні плагіни-ранери: адаптери live-транспорту, які
керують реальним каналом усередині дочірнього QA Gateway.
- `qa/`: seed-активи з репозиторію для стартового завдання й базових QA-сценаріїв.
- [Mantis](/uk/concepts/mantis): перевірка до та після live-верифікації для помилок, яким
потрібні реальні транспорти, скриншоти браузера, стан VM і докази для PR.
- `extensions/qa-matrix`, майбутні плагіни запуску: адаптери live-транспорту, які
керують реальним каналом усередині дочірнього QA gateway.
- `qa/`: seed-ресурси з репозиторію для початкового завдання та базових QA-сценаріїв.
- [Mantis](/uk/concepts/mantis): перевірка до й після наживо для помилок, яким
потрібні реальні транспорти, знімки екрана браузера, стан VM і докази PR.
## Поверхня команд
Кожен QA-потік виконується через `pnpm openclaw qa <subcommand>`. Багато з них мають
аліаси скриптів `pnpm qa:*`; підтримуються обидві форми.
| Команда | Призначення |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `qa run` | Вбудована самоперевірка QA; записує Markdown-звіт. |
| `qa suite` | Запустити сценарії з репозиторію проти лінії 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-сценарій на кількох live-моделях зі звітом, оціненим суддею. Див. [Звітування](#reporting). |
| `qa manual` | Запустити одноразовий prompt проти вибраної лінії провайдера/моделі. |
| `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-стек і вивести 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](/uk/concepts/qa-matrix). |
| `qa telegram` | Лінія live-транспорту проти реальної приватної групи Telegram. |
| `qa discord` | Лінія live-транспорту проти реального приватного каналу guild Discord. |
| `qa slack` | Лінія live-транспорту проти реального приватного каналу Slack. |
| `qa mantis` | Ранер перевірки до та після для помилок live-транспорту з першим сценарієм статусних реакцій Discord. Див. [Mantis](/uk/concepts/mantis). |
| Команда | Призначення |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `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 parity-звіт. |
| `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 scaffold для QA-дашборда + gateway lane. |
| `qa up` | Зібрати QA-сайт, запустити стек на 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 сервер provider `mock-openai`. |
| `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 slack` | Live transport lane проти реального приватного каналу Slack. |
| `qa mantis` | Runner перевірки до й після для помилок live transport, з доказами status-reactions у Discord і desktop/browser smoke у Crabbox. Див. [Mantis](/uk/concepts/mantis). |
## Потік оператора
Поточний QA-потік оператора — це QA-сайт із двома панелями:
Поточний потік QA-оператора — це двопанельний QA-сайт:
- Ліворуч: панель Gateway (Control UI) з агентом.
- Ліворуч: Gateway-дашборд (Control UI) з агентом.
- Праворуч: QA Lab, що показує Slack-подібний транскрипт і план сценарію.
Запустіть його так:
@ -69,13 +69,13 @@ x-i18n:
pnpm qa:lab:up
```
Це збирає QA-сайт, запускає Docker-лінію Gateway і відкриває сторінку
QA Lab, де оператор або цикл автоматизації може дати агенту QA-місію,
спостерігати реальну поведінку каналу й записати, що спрацювало, що
зламалося або що лишилося заблокованим.
Це збирає QA-сайт, запускає gateway lane на Docker і відкриває
сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA-місію,
спостерігати реальну поведінку каналу й записати, що спрацювало, не спрацювало або
залишилося заблокованим.
Для швидшої ітерації UI QA Lab без перебудови Docker-образу щоразу
запустіть стек із bind-mounted bundle QA Lab:
запустіть стек із bind-mounted бандлом QA Lab:
```bash
pnpm openclaw qa docker-build-image
@ -86,38 +86,38 @@ pnpm qa:lab:watch
`qa:lab:up:fast` тримає Docker-сервіси на попередньо зібраному образі та bind-mount-ить
`extensions/qa-lab/web/dist` у контейнер `qa-lab`. `qa:lab:watch`
перезбирає цей bundle за змін, а браузер автоматично перезавантажується, коли змінюється
asset hash QA Lab.
перезбирає цей бандл при зміні, а браузер автоматично перезавантажується, коли змінюється
хеш ресурсу QA Lab.
Для локального smoke OpenTelemetry trace запустіть:
Для локального OpenTelemetry trace smoke виконайте:
```bash
pnpm qa:otel:smoke
```
Цей скрипт запускає локальний OTLP/HTTP trace receiver, виконує
Цей скрипт запускає локальний приймач трас OTLP/HTTP, виконує
QA-сценарій `otel-trace-smoke` з увімкненим плагіном `diagnostics-otel`, потім
декодує експортовані protobuf spans і перевіряє release-critical форму:
декодує експортовані protobuf spans і перевіряє критичну для релізу форму:
`openclaw.run`, `openclaw.harness.run`, `openclaw.model.call`,
`openclaw.context.assembled` і `openclaw.message.delivery` мають бути присутні;
виклики моделі не мають експортувати `StreamAbandoned` на успішних turns; сирі діагностичні ID та
атрибути `openclaw.content.*` мають лишатися поза trace. Він записує
`otel-smoke-summary.json` поруч з артефактами QA suite.
model calls не мають експортувати `StreamAbandoned` на успішних turns; сирі diagnostic IDs і
атрибути `openclaw.content.*` мають не потрапляти в trace. Він записує
`otel-smoke-summary.json` поруч із артефактами QA suite.
Observability QA лишається доступним лише з source-checkout. npm tarball навмисно не містить
QA Lab, тому package Docker release lanes не запускають команди `qa`. Використовуйте
Observability QA залишається лише для source-checkout. npm tarball навмисно не містить
QA Lab, тому package Docker release lanes не виконують команди `qa`. Використовуйте
`pnpm qa:otel:smoke` із зібраного source checkout, коли змінюєте diagnostics
instrumentation.
Для транспортно-реальної smoke-лінії Matrix запустіть:
Для transport-real Matrix smoke lane виконайте:
```bash
pnpm openclaw qa matrix --profile fast --fail-fast
```
Повний довідник CLI, каталог профілів/сценаріїв, env vars і layout артефактів для цієї лінії описані в [Matrix QA](/uk/concepts/qa-matrix). Коротко: вона provision-ить одноразовий homeserver Tuwunel у Docker, реєструє тимчасових користувачів driver/SUT/observer, запускає реальний плагін Matrix усередині дочірнього QA Gateway, обмеженого цим транспортом (без `qa-channel`), а потім записує Markdown-звіт, JSON summary, артефакт observed-events і комбінований output log у `.artifacts/qa-e2e/matrix-<timestamp>/`.
Повний довідник CLI, каталог профілів/сценаріїв, env vars і структура артефактів для цієї lane містяться в [Matrix QA](/uk/concepts/qa-matrix). Коротко: він provision-ить одноразовий Tuwunel homeserver у Docker, реєструє тимчасових driver/SUT/observer users, запускає реальний Matrix-плагін усередині дочірнього QA gateway, обмеженого цим транспортом (без `qa-channel`), а потім записує Markdown-звіт, JSON summary, артефакт observed-events і об’єднаний output log у `.artifacts/qa-e2e/matrix-<timestamp>/`.
Для транспортно-реальних smoke-ліній Telegram, Discord і Slack:
Для transport-real Telegram, Discord і Slack smoke lanes:
```bash
pnpm openclaw qa telegram
@ -125,91 +125,91 @@ pnpm openclaw qa discord
pnpm openclaw qa slack
```
Вони націлені на вже наявний реальний канал із двома ботами (driver + SUT). Обов’язкові env vars, списки сценаріїв, output artifacts і пул облікових даних Convex задокументовані нижче в [Довіднику QA для Telegram, Discord і Slack](#telegram-discord-and-slack-qa-reference).
Вони націлені на попередньо наявний реальний канал із двома ботами (driver + SUT). Обов’язкові env vars, списки сценаріїв, output artifacts і пул облікових даних Convex задокументовані в [довіднику QA для Telegram, Discord і Slack](#telegram-discord-and-slack-qa-reference) нижче.
Перед використанням pooled live credentials запустіть:
Перед використанням pooled live credentials виконайте:
```bash
pnpm openclaw qa credentials doctor
```
Doctor перевіряє env брокера Convex, валідовує налаштування endpoint і перевіряє доступність admin/list, коли присутній maintainer secret. Для secrets він повідомляє лише статус set/missing.
Doctor перевіряє env Convex broker, валідує налаштування endpoint і перевіряє доступність admin/list, коли присутній maintainer secret. Для секретів він повідомляє лише статус set/missing.
## Покриття live-транспорту
## Покриття live transport
Лінії live-транспорту мають один спільний контракт, а не кожна винаходить власну форму списку сценаріїв. `qa-channel` — це ширший синтетичний suite поведінки продукту, і він не є частиною матриці покриття live-транспорту.
Live transport lanes мають один спільний контракт замість того, щоб кожна з них вигадувала власну форму списку сценаріїв. `qa-channel` — це широка синтетична suite поведінки продукту, і вона не є частиною матриці покриття live transport.
| Лінія | 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 |
| 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 |
| -------- | ------ | -------------- | ---------- | --------------- | --------------- | -------------- | ---------------- | ---------------- | -------------------- | ------------ | --------------------------- |
| Matrix | x | x | x | x | x | x | x | x | x | | |
| Telegram | x | x | x | | | | | | | x | |
| Discord | x | x | x | | | | | | | | x |
| Slack | x | x | x | | | | | | | | |
Це зберігає `qa-channel` як широкий suite поведінки продукту, тоді як Matrix,
Telegram і майбутні live-транспорти мають спільний явний checklist
транспортного контракту.
Це зберігає `qa-channel` як широку suite поведінки продукту, тоді як Matrix,
Telegram і майбутні live transports мають спільний явний checklist
transport-contract.
Для одноразової Linux VM-лінії без залучення Docker у QA-шлях запустіть:
Для одноразової Linux VM lane без залучення Docker у QA path виконайте:
```bash
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
```
Це завантажує свіжий гостьовий Multipass, встановлює залежності, збирає OpenClaw
усередині гостя, запускає `qa suite`, а потім копіює звичайний QA-звіт і
Це завантажує свіжий Multipass guest, встановлює залежності, збирає OpenClaw
усередині guest, запускає `qa suite`, а потім копіює звичайний QA-звіт і
summary назад у `.artifacts/qa-e2e/...` на host.
Він повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на host.
Host- і Multipass-запуски suite за замовчуванням виконують кілька вибраних сценаріїв паралельно
Host і Multipass suite runs за замовчуванням виконують кілька вибраних сценаріїв паралельно
з ізольованими gateway workers. `qa-channel` за замовчуванням має concurrency
4, обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency <count>` для налаштування
кількості workers або `--concurrency 1` для послідовного виконання.
4, обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати
кількість workers, або `--concurrency 1` для послідовного виконання.
Команда завершується з ненульовим кодом, коли будь-який сценарій падає. Використовуйте `--allow-failures`, коли
потрібні артефакти без failing exit code.
Live-запуски передають підтримувані QA auth inputs, практичні для
гостя: env-based provider keys, шлях до QA live provider config і
`CODEX_HOME`, коли він присутній. Тримайте `--output-dir` під коренем репозиторію, щоб гість
Live runs передають підтримувані QA auth inputs, практичні для
guest: provider keys на основі env, шлях QA live provider config і
`CODEX_HOME`, коли він присутній. Тримайте `--output-dir` під коренем репозиторію, щоб guest
міг записувати назад через змонтований workspace.
## Довідник QA для Telegram, Discord і Slack
Matrix має [окрему сторінку](/uk/concepts/qa-matrix) через кількість сценаріїв і Docker-backed homeserver provisioning. Telegram, Discord і Slack менші — по кілька сценаріїв кожен, без системи профілів, проти вже наявних реальних каналів — тому їхній довідник наведено тут.
Matrix має [окрему сторінку](/uk/concepts/qa-matrix) через кількість сценаріїв і Docker-backed homeserver provisioning. Telegram, Discord і Slack менші — по кілька сценаріїв, без системи профілів, проти попередньо наявних реальних каналів — тому їхній довідник міститься тут.
### Спільні CLI flags
Ці лінії реєструються через `extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts` і приймають ті самі flags:
Ці lanes реєструються через `extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts` і приймають ті самі flags:
| Прапор | Типово | Опис |
| ------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| `--scenario <id>` | — | Запустити лише цей сценарій. Можна повторювати. |
| `--output-dir <path>` | `<repo>/.artifacts/qa-e2e/{telegram,discord,slack}-<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](#convex-credential-pool). |
| Прапорець | Типове значення | Опис |
| ------------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| `--scenario <id>` | — | Запустити лише цей сценарій. Можна повторювати. |
| `--output-dir <path>` | `<repo>/.artifacts/qa-e2e/{telegram,discord,slack}-<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](#convex-credential-pool). |
| `--credential-role <maintainer\|ci>` | `ci` у CI, інакше `maintainer` | Роль, що використовується, коли `--credential-source convex`. |
Кожна смуга завершується з ненульовим кодом за будь-якого невдалого сценарію. `--allow-failures` записує артефакти без встановлення коду виходу, що означає помилку.
Кожна смуга завершується з ненульовим кодом у разі будь-якого невдалого сценарію. `--allow-failures` записує артефакти без встановлення коду виходу з помилкою.
### Telegram QA
### QA Telegram
```bash
pnpm openclaw qa telegram
```
Націлюється на одну реальну приватну групу Telegram із двома різними ботами (драйвер + SUT). SUT-бот повинен мати імʼя користувача Telegram; спостереження бот-бот найкраще працює, коли в обох ботів увімкнено **Bot-to-Bot Communication Mode** у `@BotFather`.
Націлюється на одну справжню приватну групу Telegram із двома окремими ботами (драйвер + SUT). Бот SUT повинен мати ім’я користувача Telegram; спостереження бот-до-бота працює найкраще, коли в обох ботів увімкнено **Bot-to-Bot Communication Mode** у `@BotFather`.
Обовʼязкові env, коли `--credential-source env`:
Обов’язкові змінні середовища, коли `--credential-source env`:
- `OPENCLAW_QA_TELEGRAM_GROUP_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`):
@ -222,29 +222,29 @@ pnpm openclaw qa telegram
- `telegram-whoami-command`
- `telegram-context-command`
Артефакти виводу:
Вихідні артефакти:
- `telegram-qa-report.md`
- `telegram-qa-summary.json` — містить RTT для кожної відповіді (надсилання драйвером → спостережена відповідь SUT), починаючи з canary.
- `telegram-qa-summary.json` — включає RTT для кожної відповіді (надсилання драйвером → спостережена відповідь SUT), починаючи з canary.
- `telegram-qa-observed-messages.json` — тіла редагуються, якщо не встановлено `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1`.
### Discord QA
### QA Discord
```bash
pnpm openclaw qa discord
```
Націлюється на один реальний приватний канал гільдії Discord із двома ботами: ботом-драйвером, яким керує harness, і SUT-ботом, запущеним дочірнім OpenClaw gateway через вбудований Discord plugin. Перевіряє обробку згадок у каналі, що SUT-бот зареєстрував нативну команду `/help` у Discord, а також opt-in сценарії доказів Mantis.
Націлюється на один справжній приватний канал гільдії Discord із двома ботами: драйверним ботом, керованим тестовим стендом, і ботом SUT, запущеним дочірнім Gateway OpenClaw через вбудований Discord plugin. Перевіряє обробку згадок каналу, те, що бот SUT зареєстрував нативну команду `/help` у Discord, а також opt-in сценарії доказів Mantis.
Обовʼязкові env, коли `--credential-source 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 (інакше смуга швидко завершується помилкою).
- `OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID` — має збігатися з ідентифікатором користувача бота SUT, поверненим Discord (інакше смуга швидко завершується з помилкою).
Необовʼязково:
Необов’язково:
- `OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1` зберігає тіла повідомлень в артефактах спостережених повідомлень.
@ -253,9 +253,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 на постійно ввімкнені відповіді гільдії лише інструментами з `messages.statusReactions.enabled=true`, а потім захоплює часову шкалу REST-реакцій плюс візуальний артефакт HTML/PNG.
Запустіть сценарій status-reaction Mantis явно:
Запустіть сценарій статусних реакцій Mantis явно:
```bash
pnpm openclaw qa discord \
@ -266,29 +266,29 @@ pnpm openclaw qa discord \
--fast
```
Артефакти виводу:
Вихідні артефакти:
- `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`, коли виконується сценарій status-reaction.
- `discord-qa-reaction-timelines.json` і `discord-status-reactions-tool-only-timeline.png`, коли запускається сценарій статусних реакцій.
### Slack QA
### QA Slack
```bash
pnpm openclaw qa slack
```
Націлюється на один реальний приватний канал Slack із двома різними ботами: ботом-драйвером, яким керує harness, і SUT-ботом, запущеним дочірнім OpenClaw gateway через вбудований Slack plugin.
Націлюється на один справжній приватний канал Slack із двома окремими ботами: драйверним ботом, керованим тестовим стендом, і ботом SUT, запущеним дочірнім Gateway OpenClaw через вбудований Slack plugin.
Обовʼязкові env, коли `--credential-source env`:
Обов’язкові змінні середовища, коли `--credential-source env`:
- `OPENCLAW_QA_SLACK_CHANNEL_ID`
- `OPENCLAW_QA_SLACK_DRIVER_BOT_TOKEN`
- `OPENCLAW_QA_SLACK_SUT_BOT_TOKEN`
- `OPENCLAW_QA_SLACK_SUT_APP_TOKEN`
Необовʼязково:
Необов’язково:
- `OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1` зберігає тіла повідомлень в артефактах спостережених повідомлень.
@ -297,7 +297,7 @@ pnpm openclaw qa slack
- `slack-canary`
- `slack-mention-gating`
Артефакти виводу:
Вихідні артефакти:
- `slack-qa-report.md`
- `slack-qa-summary.json`
@ -305,16 +305,16 @@ pnpm openclaw qa slack
### Пул облікових даних Convex
Смуги Telegram, Discord і Slack можуть орендувати облікові дані зі спільного пулу Convex замість читання env vars вище. Передайте `--credential-source convex` (або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`); QA Lab отримує ексклюзивну оренду, надсилає heartbeat протягом виконання й звільняє її під час завершення роботи. Типи пулу: `"telegram"`, `"discord"` і `"slack"`.
Смуги Telegram, Discord і Slack можуть орендувати облікові дані зі спільного пулу Convex замість читання змінних середовища вище. Передайте `--credential-source convex` (або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`); QA Lab отримує ексклюзивну оренду, надсилає для неї Heartbeat протягом виконання та звільняє її під час завершення роботи. Типи пулу: `"telegram"`, `"discord"` і `"slack"`.
Форми payload, які брокер перевіряє на `admin/add`:
Форми payload, які broker перевіряє на `admin/add`:
- 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 }`.
Операційні env vars і контракт endpoint брокера Convex описані в [Тестування → Спільні облікові дані Telegram через Convex](/uk/help/testing#shared-telegram-credentials-via-convex-v1) (назва розділу зʼявилася до підтримки Discord; семантика брокера ідентична для обох типів).
Операційні змінні середовища та контракт endpoint broker Convex описані в [Testing → Shared Telegram credentials via Convex](/uk/help/testing#shared-telegram-credentials-via-convex-v1) (назва розділу передує підтримці Discord; семантика broker однакова для обох типів).
## Seeds, підкріплені репозиторієм
## Seeds із репозиторію
Seed-ресурси розташовані в `qa/`:
@ -324,109 +324,109 @@ Seed-ресурси розташовані в `qa/`:
Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
агенту.
`qa-lab` має залишатися універсальним markdown runner. Кожен markdown-файл сценарію є
джерелом істини для одного тестового запуску й має визначати:
`qa-lab` має залишатися generic markdown runner. Кожен markdown-файл сценарію є
джерелом істини для одного тестового запуску та має визначати:
- метадані сценарію
- необовʼязкові метадані категорії, можливості, смуги та ризику
- посилання на docs і code
- необовʼязкові вимоги до plugin
- необовʼязковий patch конфігурації gateway
- необов’язкові метадані категорії, capability, смуги та ризику
- посилання на документацію та код
- необов’язкові вимоги до plugin
- необов’язковий patch конфігурації Gateway
- виконуваний `qa-flow`
Багаторазово використовувана runtime-поверхня, що підтримує `qa-flow`, може залишатися універсальною
та наскрізною. Наприклад, markdown-сценарії можуть поєднувати transport-side
помічники з browser-side помічниками, які керують вбудованим Control UI через
шов Gateway `browser.request` без додавання runner для спеціального випадку.
Багаторазова runtime-поверхня, що підтримує `qa-flow`, може залишатися generic
і наскрізною. Наприклад, markdown-сценарії можуть поєднувати помічники на боці
транспорту з помічниками на боці браузера, які керують вбудованим Control UI через
шов Gateway `browser.request`, без додавання спеціалізованого runner.
Файли сценаріїв слід групувати за продуктовою можливістю, а не за папкою
дерева джерел. Зберігайте ідентифікатори сценаріїв стабільними під час переміщення файлів; використовуйте `docsRefs` і `codeRefs`
для трасованості реалізації.
Файли сценаріїв слід групувати за продуктовою capability, а не за папкою дерева
джерел. Зберігайте ідентифікатори сценаріїв стабільними під час переміщення файлів; використовуйте `docsRefs` і `codeRefs`
для простежуваності реалізації.
Базовий список має залишатися достатньо широким, щоб покривати:
- DM і чат каналу
- поведінку thread
- життєвий цикл message action
- callbacks cron
- пригадування памʼяті
- життєвий цикл дій із повідомленнями
- Cron callbacks
- пригадування пам’яті
- перемикання моделей
- передавання subagent
- читання репозиторію та читання docs
- одне невелике build-завдання, наприклад Lobster Invaders
- читання репозиторію та читання документації
- одне невелике завдання збірки, як-от Lobster Invaders
## Mock-смуги провайдерів
## Смуги mock-постачальника
`qa suite` має дві локальні mock-смуги провайдерів:
`qa suite` має дві локальні смуги mock-постачальника:
- `mock-openai` — це scenario-aware OpenClaw mock. Він залишається типовою
детермінованою mock-смугою для repo-backed QA і parity gates.
- `aimock` запускає AIMock-backed сервер провайдера для експериментального protocol,
fixture, record/replay і chaos coverage. Він є додатковим і не
замінює диспетчер сценаріїв `mock-openai`.
- `mock-openai` — scenario-aware mock OpenClaw. Він залишається типовою
детермінованою mock-смугою для QA з репозиторію та parity gates.
- `aimock` запускає сервер постачальника на базі AIMock для експериментального protocol,
fixture, record/replay і chaos-покриття. Він є додатковим і не
замінює scenario dispatcher `mock-openai`.
Реалізація provider-lane розташована в `extensions/qa-lab/src/providers/`.
Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера, конфігурацією моделі gateway,
потребами staged auth-profile, а також live/mock capability flags. Спільний suite і
код gateway мають маршрутизуватися через registry провайдерів замість розгалуження за
іменами провайдерів.
Реалізація смуг постачальників розташована в `extensions/qa-lab/src/providers/`.
Кожен постачальник володіє своїми типовими значеннями, запуском локального сервера, конфігурацією моделі Gateway,
потребами staging auth-profile і прапорцями live/mock capability. Спільний код suite і
Gateway має маршрутизувати через реєстр постачальників замість розгалуження за
іменами постачальників.
## Transport adapters
## Транспортні адаптери
`qa-lab` володіє універсальним transport seam для markdown QA сценаріїв. `qa-channel` є першим adapter на цьому seam, але ціль дизайну ширша: майбутні реальні або synthetic channels мають підключатися до того самого suite runner замість додавання transport-specific QA runner.
`qa-lab` володіє generic транспортним швом для markdown QA-сценаріїв. `qa-channel` є першим адаптером на цьому шві, але ціль дизайну ширша: майбутні справжні або синтетичні канали мають підключатися до того самого suite runner замість додавання транспортно-специфічного QA runner.
На рівні архітектури розподіл такий:
На рівні архітектури поділ такий:
- `qa-lab` володіє універсальним виконанням сценаріїв, паралельністю worker, записом артефактів і звітністю.
- Transport adapter володіє конфігурацією gateway, readiness, inbound and outbound observation, transport actions і normalized transport state.
- Markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає багаторазово використовувану runtime-поверхню, яка їх виконує.
- `qa-lab` володіє generic виконанням сценаріїв, конкурентністю worker, записом артефактів і звітуванням.
- Транспортний адаптер володіє конфігурацією Gateway, готовністю, спостереженням inbound і outbound, транспортними діями та нормалізованим транспортним станом.
- Markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає багаторазову runtime-поверхню, яка їх виконує.
### Додавання каналу
Додавання каналу до markdown QA system вимагає рівно двох речей:
Додавання каналу до markdown QA-системи потребує рівно двох речей:
1. Transport adapter для каналу.
2. Scenario pack, який перевіряє контракт каналу.
1. Транспортного адаптера для каналу.
2. Пакета сценаріїв, що перевіряє контракт каналу.
Не додавайте новий top-level QA command root, коли спільний хост `qa-lab` може володіти потоком.
Не додавайте новий верхньорівневий корінь команди QA, коли спільний host `qa-lab` може володіти flow.
`qa-lab` володіє спільною механікою хоста:
`qa-lab` володіє спільною механікою host:
- command root `openclaw qa`
- корінь команди `openclaw qa`
- запуск і teardown suite
- паралельність worker
- конкурентність worker
- запис артефактів
- генерування звіту
- генерація звіту
- виконання сценаріїв
- aliases сумісності для старіших сценаріїв `qa-channel`
- compatibility aliases для старіших сценаріїв `qa-channel`
Runner plugins володіють transport contract:
Runner plugins володіють транспортним контрактом:
- як `openclaw qa <runner>` монтується під спільним root `qa`
- як gateway налаштовується для цього transport
- як перевіряється readiness
- як injected inbound events
- як `openclaw qa <runner>` монтується під спільним коренем `qa`
- як Gateway конфігурується для цього транспорту
- як перевіряється готовність
- як впроваджуються inbound events
- як спостерігаються outbound messages
- як transcripts і normalized transport state доступні назовні
- як надаються transcripts і нормалізований транспортний стан
- як виконуються transport-backed actions
- як обробляється transport-specific reset або cleanup
- як обробляється транспортно-специфічне скидання або очищення
Мінімальна планка впровадження для нового каналу:
Мінімальний поріг прийняття для нового каналу:
1. Залиште `qa-lab` власником спільного кореня `qa`.
2. Реалізуйте виконавець транспорту на спільному стику хоста `qa-lab`.
3. Тримайте механіку, специфічну для транспорту, всередині Plugin виконавця або обв’язки каналу.
4. Змонтуйте виконавець як `openclaw qa <runner>` замість реєстрації конкуруючої кореневої команди. Plugin-и виконавців мають оголошувати `qaRunners` в `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` з `runtime-api.ts`. Тримайте `runtime-api.ts` легким; ліниве виконання CLI і виконавця має лишатися за окремими точками входу.
5. Створіть або адаптуйте markdown-сценарії у тематичних каталогах `qa/scenarios/`.
2. Реалізуйте runner транспорту на спільному host seam `qa-lab`.
3. Тримайте специфічну для транспорту механіку всередині runner plugin або harness каналу.
4. Змонтуйте runner як `openclaw qa <runner>` замість реєстрації конкуруючої кореневої команди. Runner plugins мають оголошувати `qaRunners` в `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` з `runtime-api.ts`. Тримайте `runtime-api.ts` легким; ліниві CLI та виконання runner мають залишатися за окремими точками входу.
5. Створіть або адаптуйте markdown-сценарії в тематичних каталогах `qa/scenarios/`.
6. Використовуйте загальні допоміжні функції сценаріїв для нових сценаріїв.
7. Зберігайте роботу наявних псевдонімів сумісності, якщо репозиторій не виконує навмисну міграцію.
7. Залишайте наявні псевдоніми сумісності робочими, якщо repo не виконує навмисну міграцію.
Правило ухвалення рішення суворе:
- Якщо поведінку можна виразити один раз у `qa-lab`, помістіть її в `qa-lab`.
- Якщо поведінка залежить від одного транспорту каналу, тримайте її в цьому Plugin виконавця або обв’язці Plugin.
- Якщо сценарію потрібна нова можливість, яку може використовувати більш ніж один канал, додайте загальну допоміжну функцію замість гілки, специфічної для каналу, у `suite.ts`.
- Якщо поведінка має сенс лише для одного транспорту, залиште сценарій специфічним для транспорту й явно вкажіть це в контракті сценарію.
- Якщо поведінка залежить від одного транспорту каналу, тримайте її в цьому runner plugin або plugin harness.
- Якщо сценарію потрібна нова можливість, яку може використовувати більше ніж один канал, додайте загальну допоміжну функцію замість специфічної для каналу гілки в `suite.ts`.
- Якщо поведінка має сенс лише для одного транспорту, залиште сценарій специфічним для транспорту й явно зазначте це в контракті сценарію.
### Назви допоміжних функцій сценаріїв
@ -445,21 +445,21 @@ Runner plugins володіють transport contract:
- `formatTransportTranscript`
- `resetTransport`
Псевдоніми сумісності лишаються доступними для наявних сценаріїв — `waitForQaChannelReady`, `waitForOutboundMessage`, `waitForNoOutbound`, `formatConversationTranscript`, `resetBus` — але для створення нових сценаріїв слід використовувати загальні назви. Псевдоніми існують, щоб уникнути одночасної міграції всього коду, а не як модель на майбутнє.
Псевдоніми сумісності залишаються доступними для наявних сценаріїв — `waitForQaChannelReady`, `waitForOutboundMessage`, `waitForNoOutbound`, `formatConversationTranscript`, `resetBus` — але під час створення нових сценаріїв слід використовувати загальні назви. Псевдоніми існують, щоб уникнути одночасної примусової міграції, а не як модель на майбутнє.
## Звітування
`qa-lab` експортує Markdown-звіт протоколу зі спостережуваної часової шкали шини.
`qa-lab` експортує Markdown-звіт протоколу зі спостережуваної часової лінії bus.
Звіт має відповідати на такі питання:
- Що спрацювало
- Що не спрацювало
- Що не вдалося
- Що залишилося заблокованим
- Які подальші сценарії варто додати
Для інвентаризації доступних сценаріїв — корисної під час оцінювання обсягу подальшої роботи або підключення нового транспорту — виконайте `pnpm openclaw qa coverage` (додайте `--json` для машинозчитуваного виводу).
Для інвентаризації доступних сценаріїв — корисної під час оцінювання обсягу подальшої роботи або підключення нового транспорту — запустіть `pnpm openclaw qa coverage` (додайте `--json` для машинозчитуваного виводу).
Для перевірок характеру та стилю виконайте той самий сценарій на кількох live model
Для перевірок характеру й стилю запустіть той самий сценарій на кількох живих model
refs і запишіть оцінений Markdown-звіт:
```bash
@ -479,42 +479,42 @@ pnpm openclaw qa character-eval \
--judge-concurrency 16
```
Команда запускає дочірні процеси локального QA Gateway, а не Docker. Сценарії оцінювання характеру
мають задавати персону через `SOUL.md`, а потім виконувати звичайні ходи користувача,
як-от чат, допомогу з робочим простором і невеликі файлові завдання. Моделі-кандидату
Команда запускає локальні дочірні процеси QA Gateway, а не Docker. Сценарії оцінювання характеру
мають задавати persona через `SOUL.md`, а потім виконувати звичайні звернення користувача,
як-от чат, допомога з workspace і невеликі файлові завдання. Моделі-кандидату
не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
транскрипт, записує базову статистику запуску, а потім просить моделі-судді у швидкому режимі з
міркуванням `xhigh`, де це підтримується, ранжувати запуски за природністю, вайбом і гумором.
Використовуйте `--blind-judge-models` під час порівняння провайдерів: підказка судді все одно отримує
транскрипт, записує базову статистику запуску, а потім просить judge models у fast mode з
міркуванням `xhigh`, де воно підтримується, ранжувати запуски за природністю, вайбом і гумором.
Використовуйте `--blind-judge-models` під час порівняння провайдерів: judge prompt усе ще отримує
кожен транскрипт і статус запуску, але refs кандидатів замінюються нейтральними
мітками, як-от `candidate-01`; звіт зіставляє рейтинги назад із реальними refs після
розбору.
Запуски кандидатів за замовчуванням використовують мислення `high`, з `medium` для GPT-5.5 і `xhigh`
для старіших refs оцінювання OpenAI, які це підтримують. Перевизначте конкретного кандидата inline за допомогою
`--model provider/model,thinking=<level>`. `--thinking <level>` все ще задає
для старіших OpenAI eval refs, які це підтримують. Перевизначте окремого кандидата inline за допомогою
`--model provider/model,thinking=<level>`. `--thinking <level>` усе ще задає
глобальний fallback, а старіша форма `--model-thinking <provider/model=level>` зберігається
для сумісності.
Refs кандидатів OpenAI за замовчуванням використовують швидкий режим, щоб пріоритетна обробка застосовувалась там, де
провайдер її підтримує. Додайте `,fast`, `,no-fast` або `,fast=false` inline, коли
окремий кандидат або суддя потребує перевизначення. Передавайте `--fast` лише тоді, коли хочете
примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалості для кандидатів і суддів
записуються у звіті для аналізу бенчмарків, але підказки суддів явно вказують
OpenAI refs кандидатів за замовчуванням використовують fast mode, щоб priority processing застосовувалася там, де
провайдер це підтримує. Додайте `,fast`, `,no-fast` або `,fast=false` inline, коли
окремому кандидату чи судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
примусово ввімкнути fast mode для кожної моделі-кандидата. Тривалості кандидатів і суддів
записуються у звіт для аналізу benchmark, але judge prompts явно вказують
не ранжувати за швидкістю.
Запуски моделей-кандидатів і суддів за замовчуванням обидва використовують concurrency 16. Зменште
`--concurrency` або `--judge-concurrency`, коли ліміти провайдера або навантаження на локальний Gateway
роблять запуск занадто шумним.
Коли кандидатський `--model` не передано, оцінювання характеру за замовчуванням використовує
Запуски моделей-кандидатів і суддів за замовчуванням мають concurrency 16. Зменште
`--concurrency` або `--judge-concurrency`, коли ліміти провайдера чи навантаження на локальний Gateway
роблять запуск надто шумним.
Коли не передано candidate `--model`, character eval за замовчуванням використовує
`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` не передано, судді за замовчуванням:
`google/gemini-3.1-pro-preview`, коли не передано `--model`.
Коли не передано `--judge-model`, судді за замовчуванням:
`openai/gpt-5.5,thinking=xhigh,fast` і
`anthropic/claude-opus-4-6,thinking=high`.
## Пов’язані документи
- [Матрична QA](/uk/concepts/qa-matrix)
- [Канал QA](/uk/channels/qa-channel)
- [Matrix QA](/uk/concepts/qa-matrix)
- [QA Channel](/uk/channels/qa-channel)
- [Тестування](/uk/help/testing)
- [Панель керування](/uk/web/dashboard)
- [Dashboard](/uk/web/dashboard)