diff --git a/docs/uk/concepts/mantis.md b/docs/uk/concepts/mantis.md index c45465437..e37757c66 100644 --- a/docs/uk/concepts/mantis.md +++ b/docs/uk/concepts/mantis.md @@ -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 ` або `OPENCLAW_MANTIS_CRABBOX_LEASE_ID` повторно використовує прогрітий desktop. +- `--browser-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// @@ -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` -- Запуск: -- Артефакт: -- Базова версія: `` на `` -- Кандидат: `` на `` +- Scenario: `discord-status-reactions-tool-only` +- Run: +- Artifact: +- Baseline: `` at `` +- Candidate: `` at `` -| Базова версія | Кандидат | +| Baseline | Candidate | | ------------------- | ------------------- | | | | ``` @@ -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? diff --git a/docs/uk/concepts/qa-e2e-automation.md b/docs/uk/concepts/qa-e2e-automation.md index 233c8b067..915a4ce54 100644 --- a/docs/uk/concepts/qa-e2e-automation.md +++ b/docs/uk/concepts/qa-e2e-automation.md @@ -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 `. Багато з них мають аліаси скриптів `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-/`. +Повний довідник 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-/`. -Для транспортно-реальних 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 ` для налаштування -кількості workers або `--concurrency 1` для послідовного виконання. +4, обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency `, щоб налаштувати +кількість 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 ` | — | Запустити лише цей сценарій. Можна повторювати. | -| `--output-dir ` | `/.artifacts/qa-e2e/{telegram,discord,slack}-` | Куди записуються звіти/підсумок/спостережені повідомлення та журнал виводу. Відносні шляхи обчислюються відносно `--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` | вимкнено | Швидкий режим провайдера там, де він підтримується. | -| `--credential-source ` | `env` | Див. [пул облікових даних Convex](#convex-credential-pool). | +| Прапорець | Типове значення | Опис | +| ------------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | +| `--scenario ` | — | Запустити лише цей сценарій. Можна повторювати. | +| `--output-dir ` | `/.artifacts/qa-e2e/{telegram,discord,slack}-` | Куди записуються звіти/підсумок/спостережені повідомлення та вихідний журнал. Відносні шляхи обчислюються відносно `--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` | вимкнено | Швидкий режим постачальника, де підтримується. | +| `--credential-source ` | `env` | Див. [Пул облікових даних Convex](#convex-credential-pool). | | `--credential-role ` | `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 ` монтується під спільним root `qa` -- як gateway налаштовується для цього transport -- як перевіряється readiness -- як injected inbound events +- як `openclaw qa ` монтується під спільним коренем `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 ` замість реєстрації конкуруючої кореневої команди. 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 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=`. `--thinking ` все ще задає +для старіших OpenAI eval refs, які це підтримують. Перевизначте окремого кандидата inline за допомогою +`--model provider/model,thinking=`. `--thinking ` усе ще задає глобальний fallback, а старіша форма `--model-thinking ` зберігається для сумісності. -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)