chore(i18n): refresh uk translations

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

@@ -1,51 +1,50 @@
 ---
 read_when:
     - Розширення qa-lab або qa-channel
-    - Додавання QA-сценаріїв на основі репозиторію
-    - Побудова реалістичнішої QA-автоматизації навколо панелі керування Gateway
-summary: Форма приватної QA-автоматизації для qa-lab, qa-channel, початково заповнених сценаріїв і звітів протоколу
-title: QA E2E-автоматизація
+    - Додавання сценаріїв QA, що підтримуються репозиторієм
+    - Побудова більш реалістичної автоматизації QA навколо панелі керування Gateway
+summary: Приватна структура автоматизації QA для qa-lab, qa-channel, підготовлених сценаріїв і звітів протоколу
+title: Автоматизація QA E2E
 x-i18n:
-    generated_at: "2026-04-09T22:54:33Z"
+    generated_at: "2026-04-10T12:52:46Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 357d6698304ff7a8c4aa8a7be97f684d50f72b524740050aa761ac0ee68266de
+    source_hash: e416ffd285a05339a88eb749e37c4ed9448f232ca67dc0c85eba772029b5b306
     source_path: concepts/qa-e2e-automation.md
     workflow: 15
 ---
 
-# QA E2E-автоматизація
+# Автоматизація QA E2E
 
-Приватний QA-стек призначений для тестування OpenClaw у реалістичніший,
-схожий на канал спосіб, ніж це може зробити один модульний тест.
+Приватний стек QA призначений для перевірки OpenClaw у більш реалістичний,
+орієнтований на канали спосіб, ніж це може зробити один модульний тест.
 
 Поточні складові:
 
-- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями для DM, каналу, гілки,
+- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, треду,
   реакцій, редагування та видалення.
-- `extensions/qa-lab`: UI налагодження та QA-шина для спостереження за транскриптом,
-  інʼєкції вхідних повідомлень і експорту Markdown-звіту.
-- `qa/`: ресурси початкового заповнення на основі репозиторію для стартового завдання та базових QA-
-  сценаріїв.
+- `extensions/qa-lab`: UI налагодження та шина QA для спостереження за транскриптом,
+  інʼєкції вхідних повідомлень і експорту звіту у форматі Markdown.
+- `qa/`: ресурси початкових даних, що підтримуються репозиторієм, для стартового завдання та базових сценаріїв QA.
 
-Поточний робочий процес QA-оператора — це двопанельний QA-сайт:
+Поточний потік роботи оператора QA — це сайт QA із двома панелями:
 
 - Ліворуч: панель керування Gateway (Control UI) з агентом.
 - Праворуч: QA Lab, що показує транскрипт у стилі Slack і план сценарію.
 
-Запустіть його командою:
+Запустіть його так:
 
 ```bash
 pnpm qa:lab:up
 ```
 
-Це збирає QA-сайт, запускає lane Gateway на основі Docker і відкриває
-сторінку QA Lab, де оператор або цикл автоматизації може дати агенту QA-
-завдання, спостерігати реальну поведінку каналу та фіксувати, що спрацювало, що
-не спрацювало або що залишилося заблокованим.
+Це збирає сайт QA, запускає lane Gateway на основі Docker і відкриває
+сторінку QA Lab, де оператор або цикл автоматизації може дати агенту
+QA-місію, спостерігати реальну поведінку каналу й записувати, що спрацювало,
+що не спрацювало або що залишилося заблокованим.
 
-Для швидшої ітерації UI QA Lab без повторного збирання Docker-образу щоразу
-запустіть стек із bind-mount пакета QA Lab:
+Для швидшої ітерації UI QA Lab без повторного збирання образу Docker щоразу,
+запустіть стек із bind-mounted збіркою QA Lab:
 
 ```bash
 pnpm openclaw qa docker-build-image
@@ -54,29 +53,31 @@ pnpm qa:lab:up:fast
 pnpm qa:lab:watch
 ```
 
-`qa:lab:up:fast` залишає сервіси Docker на попередньо зібраному образі та монтує
-`extensions/qa-lab/web/dist` у контейнер `qa-lab` через bind-mount. `qa:lab:watch`
-перебудовує цей пакет при змінах, а браузер автоматично перезавантажується, коли
-змінюється хеш ресурсів QA Lab.
+`qa:lab:up:fast` утримує сервіси Docker на попередньо зібраному образі та bind-mount
+`extensions/qa-lab/web/dist` у контейнер `qa-lab`. `qa:lab:watch`
+перезбирає цей пакет при змінах, а браузер автоматично перезавантажується, коли змінюється хеш ресурсів QA Lab.
 
-Для одноразової lane 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` на хості.
-Під час live-запусків пересилаються підтримувані вхідні дані автентифікації QA, які є практичними для
-гостьової системи: ключі провайдера на основі env, шлях до конфігурації QA live provider і
-`CODEX_HOME`, якщо він присутній. Зберігайте `--output-dir` у межах кореня репозиторію, щоб гостьова система
-могла записувати назад через змонтований workspace.
+Використовується та сама поведінка вибору сценаріїв, що й у `qa suite` на хості.
+Запуски suite на хості та в Multipass за замовчуванням виконують кілька вибраних сценаріїв паралельно
+з ізольованими працівниками gateway, до 64 працівників або до кількості вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати кількість працівників, або
+`--concurrency 1` для послідовного виконання.
+Live-запуски пересилають підтримувані вхідні дані автентифікації QA, які практичні для
+гостя: ключі провайдера на основі env, шлях до конфігурації live-провайдера QA і
+`CODEX_HOME`, якщо він присутній. Тримайте `--output-dir` у межах кореня репозиторію, щоб гість
+міг записувати результати назад через змонтований робочий простір.
 
-## Початково заповнені ресурси на основі репозиторію
+## Початкові дані, що підтримуються репозиторієм
 
-Ресурси початкового заповнення містяться в `qa/`:
+Ресурси початкових даних розташовані в `qa/`:
 
 - `qa/scenarios/index.md`
 - `qa/scenarios/*.md`
@@ -84,28 +85,28 @@ pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
 Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
 агенту. Базовий список має залишатися достатньо широким, щоб охоплювати:
 
-- чат у DM і каналі
-- поведінку в гілках
+- DM і чат у каналі
+- поведінку тредів
 - життєвий цикл дій із повідомленнями
 - cron-зворотні виклики
-- згадування памʼяті
+- відтворення памʼяті
 - перемикання моделей
-- передавання до субагента
-- читання репозиторію та читання документації
+- передачу субагенту
+- читання репозиторію та документації
 - одне невелике завдання зі збирання, наприклад Lobster Invaders
 
-## Звітування
+## Звітність
 
-`qa-lab` експортує Markdown-звіт протоколу на основі спостережуваної часової шкали шини.
-Звіт має відповідати на такі запитання:
+`qa-lab` експортує звіт протоколу у форматі Markdown зі спостережуваної часової шкали шини.
+Звіт має відповідати на запитання:
 
 - Що спрацювало
 - Що не спрацювало
 - Що залишилося заблокованим
-- Які сценарії для подальшої роботи варто додати
+- Які сценарії продовження варто додати
 
-Для перевірок характеру та стилю запустіть той самий сценарій для кількох live model
-ref і запишіть Markdown-звіт з оцінюванням:
+Для перевірок характеру та стилю запустіть той самий сценарій для кількох live-моделей
+і запишіть оцінений звіт у форматі Markdown:
 
 ```bash
 pnpm openclaw qa character-eval \
@@ -124,35 +125,34 @@ pnpm openclaw qa character-eval \
   --judge-concurrency 16
 ```
 
-Команда запускає дочірні процеси локального QA gateway, а не Docker. Сценарії character eval
-мають задавати персонажа через `SOUL.md`, а потім виконувати звичайні користувацькі ходи,
-такі як чат, допомога з workspace і невеликі файлові завдання. Моделі-кандидату
-не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
-транскрипт, записує базову статистику запуску, а потім просить моделі-оцінювачі в режимі fast з
+Ця команда запускає локальні дочірні процеси gateway QA, а не Docker. Сценарії оцінювання характеру
+мають задавати персону через `SOUL.md`, а потім виконувати звичайні ходи користувача,
+такі як чат, допомога з робочим простором і невеликі файлові завдання. Моделі-кандидату
+не слід повідомляти, що її оцінюють. Команда зберігає кожен повний транскрипт,
+записує базову статистику запуску, а потім просить моделі-судді у fast mode з
 міркуванням `xhigh` ранжувати запуски за природністю, вайбом і гумором.
-Використовуйте `--blind-judge-models` під час порівняння провайдерів: запит оцінювача все одно отримує
-кожен транскрипт і статус запуску, але ref кандидатів замінюються нейтральними
-мітками на кшталт `candidate-01`; після розбору звіт зіставляє ранжування назад із реальними ref.
-Для запусків кандидатів за замовчуванням використовується рівень thinking `high`, а для моделей OpenAI,
-які це підтримують, — `xhigh`. Перевизначте конкретного кандидата inline за допомогою
-`--model provider/model,thinking=<level>`. `--thinking <level>` як і раніше задає
-глобальний резервний варіант, а стара форма `--model-thinking <provider/model=level>` збережена
-для сумісності.
-Для ref кандидатів OpenAI за замовчуванням використовується режим fast, щоб там, де провайдер це підтримує,
-застосовувалася пріоритетна обробка. Додайте `,fast`, `,no-fast` або `,fast=false` inline, якщо
-для одного кандидата або оцінювача потрібно перевизначення. Передавайте `--fast` лише тоді, коли хочете
-примусово ввімкнути режим fast для кожної моделі-кандидата. Тривалість роботи кандидатів і оцінювачів
-записується у звіт для аналізу бенчмарків, але в запитах до оцінювачів прямо зазначено,
-що не слід ранжувати за швидкістю.
-І для запусків моделей-кандидатів, і для запусків моделей-оцінювачів за замовчуванням використовується паралелізм 16. Зменште
-`--concurrency` або `--judge-concurrency`, якщо обмеження провайдера чи навантаження на локальний gateway
+Використовуйте `--blind-judge-models` при порівнянні провайдерів: підказка для судді все одно отримує
+кожен транскрипт і статус запуску, але посилання кандидатів замінюються на нейтральні
+мітки, такі як `candidate-01`; після розбору звіт зіставляє ранжування з реальними посиланнями.
+Запуски кандидатів за замовчуванням використовують `high` thinking, а для моделей OpenAI — `xhigh`,
+якщо вони це підтримують. Перевизначте конкретного кандидата inline через
+`--model provider/model,thinking=<level>`. `--thinking <level>` усе ще задає
+глобальний резервний варіант, а старіша форма `--model-thinking <provider/model=level>` зберігається для сумісності.
+Посилання кандидатів OpenAI за замовчуванням використовують fast mode, щоб за можливості провайдера
+застосовувалася обробка з пріоритетом. Додайте inline `,fast`, `,no-fast` або `,fast=false`, якщо
+окремому кандидату чи судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
+примусово ввімкнути fast mode для кожної моделі-кандидата. Тривалість запусків кандидатів і суддів
+записується у звіті для аналізу бенчмарків, але підказки для суддів явно вказують
+не ранжувати за швидкістю.
+І запуски моделей-кандидатів, і запуски моделей-суддів за замовчуванням мають concurrency 16. Зменшуйте
+`--concurrency` або `--judge-concurrency`, якщо обмеження провайдера або навантаження на локальний gateway
 роблять запуск надто шумним.
-Якщо не передано жодного кандидата `--model`, для character eval за замовчуванням використовуються
+Якщо не передано жодного кандидатського `--model`, оцінювання характеру за замовчуванням використовує
 `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`.