chore(i18n): refresh uk translations

docs/uk/concepts/qa-e2e-automation.md

@@ -2,49 +2,49 @@
 read_when:
     - Розширення qa-lab або qa-channel
     - Додавання сценаріїв QA з підтримкою репозиторію
-    - Створення більш реалістичної автоматизації QA навколо панелі керування Gateway
-summary: Приватна структура автоматизації QA для qa-lab, qa-channel, початково заповнених сценаріїв і звітів протоколу
+    - Побудова реалістичнішої автоматизації QA навколо панелі керування Gateway
+summary: Приватна форма автоматизації QA для qa-lab, qa-channel, початково заповнених сценаріїв і звітів протоколу
 title: Автоматизація QA E2E
 x-i18n:
-    generated_at: "2026-04-10T23:36:40Z"
+    generated_at: "2026-04-12T18:04:22Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 5427b505e26bfd542e984e3920c3f7cb825473959195ba9737eff5da944c60d0
+    source_hash: 355ddac0122a1981973b03ef42dd99403347507ffbe8d27a03c318a831dd62d7
     source_path: concepts/qa-e2e-automation.md
     workflow: 15
 ---
 
 # Автоматизація QA E2E
 
-Приватний стек QA призначений для того, щоб перевіряти OpenClaw у більш реалістичний,
-орієнтований на канали спосіб, ніж це може зробити один модульний тест.
+Приватний стек QA призначений для тестування OpenClaw у реалістичніший,
+орієнтований на канали спосіб, ніж це може забезпечити один модульний тест.
 
 Поточні складові:
 
-- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, гілки,
-  реакції, редагування та видалення.
-- `extensions/qa-lab`: UI налагодження та шина QA для спостереження за транскриптом,
-  інʼєкції вхідних повідомлень і експорту Markdown-звіту.
-- `qa/`: ресурси початкового заповнення з підтримкою репозиторію для стартового завдання та базових QA
-  сценаріїв.
+- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, треду,
+  реакцій, редагування та видалення.
+- `extensions/qa-lab`: інтерфейс налагодження та шина QA для спостереження за транскриптом,
+  впровадження вхідних повідомлень і експорту Markdown-звіту.
+- `qa/`: ресурси початкових даних із підтримкою репозиторію для стартового завдання та базових сценаріїв QA.
 
-Поточний робочий процес оператора QA — це сайт QA з двома панелями:
+Поточний робочий процес оператора QA — це двопанельний QA-сайт:
 
 - Ліворуч: панель керування Gateway (Control UI) з агентом.
-- Праворуч: QA Lab, де показано транскрипт у стилі Slack і план сценарію.
+- Праворуч: QA Lab, що показує схожий на Slack транскрипт і план сценарію.
 
-Запустіть його так:
+Запустіть це командою:
 
 ```bash
 pnpm qa:lab:up
 ```
 
-Це збирає сайт QA, запускає лінію gateway на базі Docker і відкриває
-сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA
-місію, спостерігати реальну поведінку каналу та фіксувати, що спрацювало, що не спрацювало або що залишилося заблокованим.
+Це збирає QA-сайт, запускає lane Gateway на базі Docker і відкриває
+сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA-місію,
+спостерігати реальну поведінку каналу та фіксувати, що спрацювало, що не вдалося
+або що залишилося заблокованим.
 
-Щоб швидше ітерувати UI QA Lab без повторного збирання Docker-образу щоразу,
-запустіть стек із bind-mounted збіркою QA Lab:
+Для швидшої ітерації інтерфейсу QA Lab без повторного збирання Docker-образу щоразу
+запустіть стек із прив’язаним змонтованим бандлом QA Lab:
 
 ```bash
 pnpm openclaw qa docker-build-image
@@ -53,100 +53,119 @@ pnpm qa:lab:up:fast
 pnpm qa:lab:watch
 ```
 
-`qa:lab:up:fast` зберігає сервіси Docker на попередньо зібраному образі та bind-mount-ить
+`qa:lab:up:fast` залишає служби Docker на попередньо зібраному образі та прив’язано монтує
 `extensions/qa-lab/web/dist` у контейнер `qa-lab`. `qa:lab:watch`
-перезбирає цей bundle під час змін, а браузер автоматично перезавантажується, коли змінюється хеш ресурсів QA Lab.
+перезбирає цей бандл при змінах, а браузер автоматично перезавантажується, коли змінюється
+хеш ресурсу QA Lab.
 
-Для лінії smoke-тестування Matrix із реальним транспортом запустіть:
+Для smoke-lane Matrix із реальним транспортом виконайте:
 
 ```bash
 pnpm openclaw qa matrix
 ```
 
-Ця лінія розгортає одноразовий homeserver Tuwunel у Docker, реєструє
+Цей lane розгортає тимчасовий homeserver Tuwunel у Docker, реєструє
 тимчасових користувачів driver, SUT і observer, створює одну приватну кімнату, а потім запускає
-реальний плагін Matrix усередині дочірнього процесу QA gateway. Лінія з живим транспортом зберігає конфігурацію дочірнього процесу в межах транспорту, що тестується, тому Matrix працює без
+реальний Plugin Matrix усередині дочірнього процесу QA gateway. Lane із живим транспортом зберігає
+конфігурацію дочірнього процесу обмеженою транспортом, що тестується, тому Matrix працює без
 `qa-channel` у конфігурації дочірнього процесу.
 
-Для лінії smoke-тестування Telegram із реальним транспортом запустіть:
+Для smoke-lane Telegram із реальним транспортом виконайте:
 
 ```bash
 pnpm openclaw qa telegram
 ```
 
-Ця лінія використовує одну реальну приватну групу Telegram замість розгортання
-одноразового сервера. Для неї потрібні `OPENCLAW_QA_TELEGRAM_GROUP_ID`,
+Цей lane націлений на одну реальну приватну групу Telegram замість розгортання
+тимчасового сервера. Для нього потрібні `OPENCLAW_QA_TELEGRAM_GROUP_ID`,
 `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і
-`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, а також два різні боти в одній
-приватній групі. Бот SUT повинен мати імʼя користувача Telegram, а спостереження бот-до-бота
-працює найкраще, коли в обох ботів увімкнено режим Bot-to-Bot Communication Mode
-у `@BotFather`.
+`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`, а також два різні
+боти в одній приватній групі. Бот SUT повинен мати ім’я користувача Telegram, а
+спостереження бот-до-бота працює найкраще, коли в обох ботів увімкнено режим
+Bot-to-Bot Communication Mode у `@BotFather`.
 
-Лінії з живим транспортом тепер використовують один менший спільний контракт замість того, щоб кожна вигадувала
-власну форму списку сценаріїв:
+Тепер lane з живим транспортом використовують один менший контракт замість того, щоб кожен
+вигадував власну форму списку сценаріїв:
 
-`qa-channel` залишається широким набором синтетичних тестів поведінки продукту і не входить
+`qa-channel` залишається широким синтетичним набором перевірок поведінки продукту й не входить
 до матриці покриття живого транспорту.
 
-| Лінія    | Канарка | Гейтінг згадок | Блокування allowlist | Відповідь верхнього рівня | Відновлення після перезапуску | Подальша відповідь у гілці | Ізоляція гілки | Спостереження за реакціями | Команда help |
-| -------- | ------- | -------------- | -------------------- | ------------------------- | ----------------------------- | -------------------------- | -------------- | -------------------------- | ------------ |
-| Matrix   | x       | x              | x                    | x                         | x                             | x                          | x              | x                          |              |
-| Telegram | x       |                |                      |                           |                               |                            |                |                            | x            |
+| Lane     | Канарейка | Гейтінг згадок | Блокування allowlist | Відповідь верхнього рівня | Відновлення після перезапуску | Продовження треду | Ізоляція треду | Спостереження за реакціями | Команда help |
+| -------- | --------- | -------------- | -------------------- | ------------------------- | ----------------------------- | ----------------- | -------------- | -------------------------- | ------------ |
+| Matrix   | x         | x              | x                    | x                         | x                             | x                 | x              | x                          |              |
+| Telegram | x         |                |                      |                           |                               |                   |                |                            | x            |
 
-Це зберігає `qa-channel` як широкий набір тестів поведінки продукту, тоді як Matrix,
-Telegram і майбутні живі транспорти використовують один явний контрольний список транспортного контракту.
+Це зберігає `qa-channel` як широкий набір перевірок поведінки продукту, тоді як Matrix,
+Telegram і майбутні живі транспорти використовують один явний контрольний список
+транспортного контракту.
 
-Для одноразової лінії Linux VM без включення Docker у шлях QA запустіть:
+Для lane з тимчасовою Linux VM без залучення Docker у шлях QA виконайте:
 
 ```bash
 pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
 ```
 
-Це завантажує свіжу гостьову машину Multipass, встановлює залежності, збирає OpenClaw
-усередині гостьової машини, запускає `qa suite`, а потім копіює звичайний звіт QA та
+Це завантажує нову гостьову систему Multipass, встановлює залежності, збирає OpenClaw
+усередині гостьової системи, запускає `qa suite`, а потім копіює стандартний звіт QA і
 підсумок назад у `.artifacts/qa-e2e/...` на хості.
 Воно повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на хості.
 Запуски suite на хості та в Multipass за замовчуванням виконують кілька вибраних сценаріїв паралельно
-з ізольованими воркерами gateway, до 64 воркерів або до кількості вибраних
-сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати кількість воркерів, або
+з ізольованими workers gateway, максимум до 64 workers або до кількості вибраних
+сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати кількість workers, або
 `--concurrency 1` для послідовного виконання.
-Живі запуски передають підтримувані вхідні дані автентифікації QA, які практично використовувати для
-гостьової машини: ключі провайдера на основі env, шлях до конфігурації live-провайдера QA та
-`CODEX_HOME`, якщо він присутній. Тримайте `--output-dir` у межах кореня репозиторію, щоб гостьова машина
+Живі запуски передають підтримувані вхідні дані автентифікації QA, які практично використати
+для гостьової системи: ключі провайдера на основі env, шлях до конфігурації live provider QA та
+`CODEX_HOME`, якщо він присутній. Тримайте `--output-dir` у межах кореня репозиторію, щоб гостьова система
 могла записувати назад через змонтований workspace.
 
 ## Початкові дані з підтримкою репозиторію
 
-Ресурси початкового заповнення знаходяться в `qa/`:
+Ресурси початкових даних розміщені в `qa/`:
 
 - `qa/scenarios/index.md`
 - `qa/scenarios/*.md`
 
-Вони навмисно зберігаються в git, щоб план QA був видимим як для людей, так і для
-агента. Базовий список має залишатися достатньо широким, щоб охоплювати:
+Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
+агенту. Базовий список має залишатися достатньо широким, щоб охоплювати:
 
-- чат у DM і каналі
-- поведінку гілок
+- DM і чат каналу
+- поведінку тредів
 - життєвий цикл дій із повідомленнями
-- cron callbacks
-- відновлення памʼяті
+- зворотні виклики Cron
+- пригадування з пам’яті
 - перемикання моделей
-- передачу підагенту
+- передавання підзадачі субагенту
 - читання репозиторію та документації
 - одне невелике завдання зі збирання, наприклад Lobster Invaders
 
+## Транспортні адаптери
+
+`qa-lab` володіє загальним транспортним швом для Markdown-сценаріїв QA.
+`qa-channel` — перший адаптер на цьому шві, але ціль ширша:
+майбутні реальні або синтетичні канали мають підключатися до того самого runner suite
+замість додавання runner QA, специфічного для транспорту.
+
+На рівні архітектури розподіл такий:
+
+- `qa-lab` володіє виконанням сценаріїв, паралелізмом workers, записом артефактів і звітністю.
+- транспортний адаптер володіє конфігурацією gateway, готовністю, спостереженням за вхідними й вихідними даними, транспортними діями та нормалізованим станом транспорту.
+- сценарії залишаються орієнтованими на Markdown у `qa/scenarios/`.
+
+Рекомендації для мейнтейнерів щодо підключення нових адаптерів каналів наведені в
+[Testing](/uk/help/testing#adding-a-channel-to-qa).
+
 ## Звітність
 
 `qa-lab` експортує Markdown-звіт протоколу зі спостережуваної часової шкали шини.
-Звіт має відповідати на такі питання:
+Звіт має відповідати на такі запитання:
 
 - Що спрацювало
-- Що не спрацювало
+- Що не вдалося
 - Що залишилося заблокованим
-- Які подальші сценарії варто додати
+- Які сценарії продовження варто додати
 
-Для перевірки характеру та стилю запустіть той самий сценарій для кількох live-моделей
-і створіть оцінений Markdown-звіт:
+Для перевірок характеру та стилю запустіть той самий сценарій на кількох живих model
+refs і запишіть оцінений Markdown-звіт:
 
 ```bash
 pnpm openclaw qa character-eval \
@@ -165,37 +184,40 @@ pnpm openclaw qa character-eval \
   --judge-concurrency 16
 ```
 
-Команда запускає локальні дочірні процеси QA gateway, а не Docker. Сценарії оцінювання характеру
-мають задавати persona через `SOUL.md`, а потім запускати звичайні користувацькі ходи,
-такі як чат, допомога з workspace і невеликі файлові завдання. Моделі-кандидату
+Команда запускає локальні дочірні процеси QA gateway, а не Docker. Сценарії
+оцінювання характеру мають задавати persona через `SOUL.md`, а потім виконувати звичайні
+користувацькі ходи, такі як чат, допомога з workspace і невеликі файлові завдання. Моделі-кандидату
 не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
-транскрипт, записує базову статистику запуску, а потім просить моделі-судді в режимі fast з
-міркуванням `xhigh` ранжувати запуски за природністю, атмосферою та гумором.
-Використовуйте `--blind-judge-models` під час порівняння провайдерів: підказка для судді все одно отримує
-кожен транскрипт і статус запуску, але посилання кандидатів замінюються нейтральними
-мітками, такими як `candidate-01`; після розбору звіту ранжування зіставляється назад із реальними посиланнями.
-Для запусків кандидатів за замовчуванням використовується рівень thinking `high`, а для моделей OpenAI, що це підтримують, — `xhigh`. Перевизначте конкретного кандидата вбудовано через
-`--model provider/model,thinking=<level>`. `--thinking <level>` як і раніше задає
-глобальний резервний варіант, а старіша форма `--model-thinking <provider/model=level>` зберігається для сумісності.
-Посилання кандидатів OpenAI за замовчуванням використовують режим fast, щоб застосовувалася пріоритетна обробка там,
-де провайдер це підтримує. Додайте `,fast`, `,no-fast` або `,fast=false` вбудовано, коли для
-окремого кандидата чи судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
-примусово ввімкнути режим fast для кожної моделі-кандидата. Тривалість запусків кандидатів і суддів
-записується у звіт для аналізу бенчмарків, але в підказках для суддів явно сказано
+транскрипт, записує базову статистику запуску, а потім просить моделі-суддів у швидкому режимі з
+міркуванням `xhigh` ранжувати запуски за природністю, вайбом і гумором.
+Використовуйте `--blind-judge-models` під час порівняння провайдерів: запит судді все одно отримує
+кожен транскрипт і статус запуску, але refs кандидатів замінюються нейтральними
+мітками на кшталт `candidate-01`; звіт зіставляє ранжування назад із реальними refs після
+розбору.
+Запуски кандидатів за замовчуванням використовують міркування `high`, а для моделей OpenAI — `xhigh`, якщо це
+підтримується. Перевизначайте конкретного кандидата вбудовано через
+`--model provider/model,thinking=<level>`. `--thinking <level>` і далі задає
+глобальне резервне значення, а стара форма `--model-thinking <provider/model=level>` зберігається
+для сумісності.
+Refs кандидатів OpenAI за замовчуванням працюють у швидкому режимі, щоб використовувалася пріоритетна
+обробка там, де це підтримує провайдер. Додайте `,fast`, `,no-fast` або `,fast=false` вбудовано, коли
+одному кандидату чи судді потрібно перевизначення. Передавайте `--fast` лише якщо хочете
+примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалість виконання кандидатів і суддів
+записується у звіт для аналізу бенчмарків, але в запитах до суддів прямо сказано
 не ранжувати за швидкістю.
-І для запусків моделей-кандидатів, і для моделей-суддів за замовчуванням використовується concurrency 16. Зменшіть
+Як запуски моделей-кандидатів, так і запуски моделей-суддів за замовчуванням мають рівень паралелізму 16. Зменшіть
 `--concurrency` або `--judge-concurrency`, коли обмеження провайдера або навантаження на локальний gateway
 роблять запуск надто шумним.
-Якщо не передано жодного candidate `--model`, для character eval за замовчуванням використовуються
+Якщо не передано жодного кандидата `--model`, character eval за замовчуванням використовує
 `openai/gpt-5.4`, `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`, за замовчуванням як судді використовуються
+Якщо не передано `--judge-model`, за замовчуванням суддями є
 `openai/gpt-5.4,thinking=xhigh,fast` і
 `anthropic/claude-opus-4-6,thinking=high`.
 
-## Повʼязана документація
+## Пов’язані документи
 
 - [Testing](/uk/help/testing)
 - [QA Channel](/uk/channels/qa-channel)