diff --git a/docs/uk/concepts/mantis.md b/docs/uk/concepts/mantis.md index 4e751335e..c7ab8f6ea 100644 --- a/docs/uk/concepts/mantis.md +++ b/docs/uk/concepts/mantis.md @@ -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// @@ -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. | | | ``` -Коли запуск завершується помилкою через збій тестового стенда, коментар має повідомляти саме це, а не натякати, що кандидат не пройшов. +Коли запуск не вдається через збій 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? diff --git a/docs/uk/concepts/qa-e2e-automation.md b/docs/uk/concepts/qa-e2e-automation.md index cfb1a4c1a..95d8e14b4 100644 --- a/docs/uk/concepts/qa-e2e-automation.md +++ b/docs/uk/concepts/qa-e2e-automation.md @@ -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 `. Багато з них мають -псевдоніми скриптів `pnpm qa:*`; підтримуються обидві форми. +Кожен QA-потік виконується через `pnpm openclaw qa `. Багато з них мають псевдоніми скриптів `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-/`. +Повний довідник 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-/`. Для 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 `, щоб налаштувати -кількість 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 ` | — | Запустити лише цей сценарій. Можна повторювати. | -| `--output-dir ` | `/.artifacts/qa-e2e/{telegram,discord}-` | Куди записуються звіти/підсумок/спостережені повідомлення та вихідний журнал. Відносні шляхи обчислюються відносно `--repo-root`. | +| `--output-dir ` | `/.artifacts/qa-e2e/{telegram,discord}-` | Куди записуються звіти/підсумок/спостережені повідомлення та вихідний журнал. Відносні шляхи розв'язуються відносно `--repo-root`. | | `--repo-root ` | `process.cwd()` | Корінь репозиторію під час виклику з нейтрального cwd. | -| `--sut-account ` | `sut` | Тимчасовий ідентифікатор облікового запису в конфігурації QA gateway. | -| `--provider-mode ` | `live-frontier` | `mock-openai` або `live-frontier` (застарілий `live-openai` також працює). | -| `--model ` / `--alt-model ` | типовий для провайдера | Посилання на основну/альтернативну модель. | -| `--fast` | вимкнено | Швидкий режим провайдера, де підтримується. | +| `--sut-account ` | `sut` | Тимчасовий id облікового запису всередині конфігурації QA gateway. | +| `--provider-mode ` | `live-frontier` | `mock-openai` або `live-frontier` (застарілий `live-openai` досі працює). | +| `--model ` / `--alt-model ` | типове значення провайдера | Посилання на основну/альтернативну модель. | +| `--fast` | вимкнено | Швидкий режим провайдера там, де підтримується. | | `--credential-source ` | `env` | Див. [пул облікових даних Convex](#convex-credential-pool). | -| `--credential-role ` | `ci` у CI, інакше `maintainer` | Роль, що використовується, коли `--credential-source convex`. | +| `--credential-role ` | `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//*.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 ` монтується під спільним коренем `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 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 ` замість реєстрації конкуруючої 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=`. `--thinking ` усе ще задає -глобальний fallback, а старіша форма `--model-thinking ` зберігається -для сумісності. -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=`. `--thinking ` досі задає +глобальний резервний варіант, а старіша форма `--model-thinking ` +збережена для сумісності. +Референси кандидатів 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)