chore(i18n): refresh uk translations

2026-05-03 22:27:37 +00:00 · 2026-05-03 22:27:37 +00:00 · 464730a240
commit 464730a240
parent 1f46fa1e27
6 changed files with 765 additions and 652 deletions
--- a/docs/uk/concepts/qa-e2e-automation.md
+++ b/docs/uk/concepts/qa-e2e-automation.md
@ -1,67 +1,67 @@
 ---
 read_when:
-    - Розуміння того, як взаємодіє QA-стек
+    - Розуміння того, як компоненти QA-стека працюють разом
    - Розширення qa-lab, qa-channel або транспортного адаптера
    - Додавання QA-сценаріїв на основі репозиторію
-    - Створення реалістичнішої автоматизації QA навколо панелі керування Gateway
-summary: 'Огляд стека QA: qa-lab, qa-channel, сценарії на основі репозиторію, live-лінії транспорту, транспортні адаптери та звітування.'
-title: Огляд QA
+    - Створення QA-автоматизації з вищим рівнем реалістичності навколо панелі керування Gateway
+summary: 'Огляд стеку QA: qa-lab, qa-channel, сценарії на основі репозиторію, лінії реального транспорту, транспортні адаптери та звітування.'
+title: Огляд забезпечення якості
 x-i18n:
-    generated_at: "2026-05-03T20:32:15Z"
+    generated_at: "2026-05-03T22:25:51Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 6a1446fddb00855634d34662a0a47be1e5054a9e7bfed5bc9ae21185d87094d8
+    source_hash: 7553094890e20eb760df149ac8bd598048c023dc072743ffe2a8dd60d17382de
    source_path: concepts/qa-e2e-automation.md
    workflow: 16
 ---

-Приватний стек QA призначений для перевірки OpenClaw реалістичнішим,
-канально-орієнтованим способом, ніж це може зробити один модульний тест.
+Приватний QA-стек призначений для перевірки OpenClaw у реалістичніший,
+канально-орієнтований спосіб, ніж це може зробити один unit-тест.

 Поточні складові:

- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, гілки,
+- `extensions/qa-channel`: синтетичний канал повідомлень із поверхнями DM, каналу, треду,
  реакції, редагування та видалення.
- `extensions/qa-lab`: UI відлагоджувача та шина QA для спостереження за транскриптом,
-  ін'єкції вхідних повідомлень і експорту Markdown-звіту.
- `extensions/qa-matrix`, майбутні runner-плагіни: адаптери live-транспортів, які
-  керують реальним каналом усередині дочірнього QA gateway.
- `qa/`: seed-ресурси з репозиторію для стартового завдання та базових QA
-  сценаріїв.
- [Mantis](/uk/concepts/mantis): перевірка до і після наживо для помилок, яким
-  потрібні реальні транспорти, знімки екрана браузера, стан VM і докази PR.
+- `extensions/qa-lab`: UI відлагоджувача й QA-шина для спостереження за транскриптом,
+  ін’єкції вхідних повідомлень і експорту Markdown-звіту.
+- `extensions/qa-matrix`, майбутні плагіни-ранери: адаптери live-транспорту, які
+  керують реальним каналом усередині дочірнього QA Gateway.
+- `qa/`: seed-активи з репозиторію для стартового завдання й базових QA-сценаріїв.
+- [Mantis](/uk/concepts/mantis): перевірка до та після live-верифікації для помилок, яким
+  потрібні реальні транспорти, скриншоти браузера, стан VM і докази для PR.

 ## Поверхня команд

-Кожен QA-потік виконується через `pnpm openclaw qa <subcommand>`. Багато з них мають псевдоніми скриптів `pnpm qa:*`;
-підтримуються обидві форми.
+Кожен QA-потік виконується через `pnpm openclaw qa <subcommand>`. Багато з них мають
+аліаси скриптів `pnpm qa:*`; підтримуються обидві форми.

-| Команда                                             | Призначення                                                                                                                                                            |
-| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `qa run`                                            | Вбудована самоперевірка QA; записує Markdown-звіт.                                                                                                                     |
-| `qa suite`                                          | Запустити сценарії з репозиторію проти lane QA gateway. Псевдоніми: `pnpm openclaw qa suite --runner multipass` для одноразової Linux VM.                              |
-| `qa coverage`                                       | Надрукувати Markdown-інвентар покриття сценаріїв (`--json` для машинного виводу).                                                                                      |
-| `qa parity-report`                                  | Порівняти два файли `qa-suite-summary.json` і записати агентний звіт про паритет.                                                                                      |
-| `qa character-eval`                                 | Запустити character QA scenario на кількох live-моделях зі звітом із судженням. Див. [Звітування](#reporting).                                                        |
-| `qa manual`                                         | Запустити одноразовий prompt проти вибраного lane провайдера/моделі.                                                                                                   |
-| `qa ui`                                             | Запустити UI відлагоджувача QA та локальну шину QA (псевдонім: `pnpm qa:lab:ui`).                                                                                      |
-| `qa docker-build-image`                             | Зібрати попередньо підготовлений Docker-образ QA.                                                                                                                      |
-| `qa docker-scaffold`                                | Записати docker-compose scaffold для QA dashboard + gateway lane.                                                                                                      |
-| `qa up`                                             | Зібрати QA site, запустити стек на Docker і надрукувати URL (псевдонім: `pnpm qa:lab:up`; варіант `:fast` додає `--use-prebuilt-image --bind-ui-dist --skip-ui-build`). |
-| `qa aimock`                                         | Запустити лише сервер AIMock provider.                                                                                                                                 |
-| `qa mock-openai`                                    | Запустити лише сервер scenario-aware `mock-openai` provider.                                                                                                           |
-| `qa credentials doctor` / `add` / `list` / `remove` | Керувати спільним пулом облікових даних Convex.                                                                                                                        |
-| `qa matrix`                                         | Live transport lane проти одноразового Tuwunel homeserver. Див. [Matrix QA](/uk/concepts/qa-matrix).                                                                      |
-| `qa telegram`                                       | Live transport lane проти реальної приватної групи Telegram.                                                                                                           |
-| `qa discord`                                        | Live transport lane проти реального приватного каналу guild Discord.                                                                                                   |
-| `qa mantis`                                         | Runner для перевірки до і після для помилок live-транспорту, з першим сценарієм Discord status-reactions. Див. [Mantis](/uk/concepts/mantis).                            |
+| Команда                                             | Призначення                                                                                                                                                                |
+| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `qa 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 — це двопанельний QA site:
+Поточний QA-потік оператора — це QA-сайт із двома панелями:

 - Ліворуч: панель Gateway (Control UI) з агентом.
- Праворуч: QA Lab, що показує транскрипт у стилі Slack і план сценарію.
+- Праворуч: QA Lab, що показує Slack-подібний транскрипт і план сценарію.

 Запустіть його так:

@ -69,13 +69,13 @@ x-i18n:
 pnpm qa:lab:up
 ```

-Це збирає QA site, запускає gateway lane на Docker і відкриває сторінку
-QA Lab, де оператор або automation loop може дати агенту QA-місію,
-спостерігати реальну поведінку каналу та записати, що спрацювало, не спрацювало або
-залишилося заблокованим.
+Це збирає QA-сайт, запускає Docker-лінію Gateway і відкриває сторінку
+QA Lab, де оператор або цикл автоматизації може дати агенту QA-місію,
+спостерігати реальну поведінку каналу й записати, що спрацювало, що
+зламалося або що лишилося заблокованим.

-Для швидшої ітерації UI QA Lab без перезбирання Docker-образу щоразу
-запустіть стек із bind-mounted QA Lab bundle:
+Для швидшої ітерації UI QA Lab без перебудови Docker-образу щоразу
+запустіть стек із bind-mounted bundle QA Lab:

 ```bash
 pnpm openclaw qa docker-build-image
@ -84,10 +84,10 @@ pnpm qa:lab:up:fast
 pnpm qa:lab:watch
 ```

-`qa:lab:up:fast` тримає Docker-сервіси на попередньо зібраному образі та bind-mounts
+`qa:lab:up:fast` тримає Docker-сервіси на попередньо зібраному образі та bind-mount-ить
 `extensions/qa-lab/web/dist` у контейнер `qa-lab`. `qa:lab:watch`
-перезбирає цей bundle при змінах, а браузер автоматично перезавантажується, коли змінюється
-хеш ресурсів QA Lab.
+перезбирає цей bundle за змін, а браузер автоматично перезавантажується, коли змінюється
+asset hash QA Lab.

 Для локального smoke OpenTelemetry trace запустіть:

@ -96,35 +96,36 @@ pnpm qa:otel:smoke
 ```

 Цей скрипт запускає локальний OTLP/HTTP trace receiver, виконує
-QA-сценарій `otel-trace-smoke` з увімкненим Plugin `diagnostics-otel`, потім
+QA-сценарій `otel-trace-smoke` з увімкненим плагіном `diagnostics-otel`, потім
 декодує експортовані protobuf spans і перевіряє release-critical форму:
 `openclaw.run`, `openclaw.harness.run`, `openclaw.model.call`,
 `openclaw.context.assembled` і `openclaw.message.delivery` мають бути присутні;
-model calls не мають експортувати `StreamAbandoned` на успішних ходах; raw diagnostic IDs і
-атрибути `openclaw.content.*` мають залишатися поза trace. Він записує
+виклики моделі не мають експортувати `StreamAbandoned` на успішних turns; сирі діагностичні ID та
+атрибути `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.

-Для lane transport-real Matrix smoke запустіть:
+Для транспортно-реальної smoke-лінії Matrix запустіть:

 ```bash
 pnpm openclaw qa matrix --profile fast --fail-fast
 ```

-Повний довідник CLI, каталог профілів/сценаріїв, env vars і структура артефактів для цього lane містяться в [Matrix QA](/uk/concepts/qa-matrix). Коротко: він provision одноразовий Tuwunel homeserver у Docker, реєструє тимчасових користувачів driver/SUT/observer, запускає реальний Matrix Plugin усередині дочірнього QA gateway, обмеженого цим transport (без `qa-channel`), а потім записує Markdown-звіт, JSON summary, артефакт observed-events і комбінований output log у `.artifacts/qa-e2e/matrix-<timestamp>/`.
+Повний довідник CLI, каталог профілів/сценаріїв, env vars і layout артефактів для цієї лінії описані в [Matrix QA](/uk/concepts/qa-matrix). Коротко: вона provision-ить одноразовий homeserver Tuwunel у Docker, реєструє тимчасових користувачів driver/SUT/observer, запускає реальний плагін Matrix усередині дочірнього QA Gateway, обмеженого цим транспортом (без `qa-channel`), а потім записує Markdown-звіт, JSON summary, артефакт observed-events і комбінований output log у `.artifacts/qa-e2e/matrix-<timestamp>/`.

-Для transport-real Telegram і Discord smoke lanes:
+Для транспортно-реальних smoke-ліній Telegram, Discord і Slack:

 ```bash
 pnpm openclaw qa telegram
 pnpm openclaw qa discord
+pnpm openclaw qa slack
 ```

-Обидва націлені на вже наявний реальний канал із двома ботами (driver + SUT). Обов'язкові env vars, списки сценаріїв, вихідні артефакти та пул облікових даних Convex задокументовані в [довіднику QA для Telegram і Discord](#telegram-and-discord-qa-reference) нижче.
+Вони націлені на вже наявний реальний канал із двома ботами (driver + SUT). Обов’язкові env vars, списки сценаріїв, output artifacts і пул облікових даних Convex задокументовані нижче в [Довіднику QA для Telegram, Discord і Slack](#telegram-discord-and-slack-qa-reference).

 Перед використанням pooled live credentials запустіть:

@ -132,81 +133,83 @@ pnpm openclaw qa discord
 pnpm openclaw qa credentials doctor
 ```

-Doctor перевіряє env брокера Convex, валідовує endpoint settings і перевіряє доступність admin/list, коли maintainer secret присутній. Для secrets він повідомляє лише статус set/missing.
+Doctor перевіряє env брокера Convex, валідовує налаштування endpoint і перевіряє доступність admin/list, коли присутній maintainer secret. Для secrets він повідомляє лише статус set/missing.

-## Покриття live transport
+## Покриття live-транспорту

-Live transport lanes мають один спільний контракт замість того, щоб кожен вигадував власну форму списку сценаріїв. `qa-channel` — це широка синтетична suite поведінки продукту й не є частиною матриці покриття live transport.
+Лінії live-транспорту мають один спільний контракт, а не кожна винаходить власну форму списку сценаріїв. `qa-channel` — це ширший синтетичний suite поведінки продукту, і він не є частиною матриці покриття live-транспорту.

-| 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 |
+| Лінія    | 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 transports мають один явний checklist транспортного контракту.
+Це зберігає `qa-channel` як широкий suite поведінки продукту, тоді як Matrix,
+Telegram і майбутні live-транспорти мають спільний явний checklist
+транспортного контракту.

-Для одноразового lane Linux VM без внесення Docker у шлях QA запустіть:
+Для одноразової Linux VM-лінії без залучення Docker у QA-шлях запустіть:

 ```bash
 pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
 ```

 Це завантажує свіжий гостьовий Multipass, встановлює залежності, збирає OpenClaw
-усередині guest, запускає `qa suite`, а потім копіює звичайний QA report і
+усередині гостя, запускає `qa suite`, а потім копіює звичайний QA-звіт і
 summary назад у `.artifacts/qa-e2e/...` на host.
 Він повторно використовує ту саму поведінку вибору сценаріїв, що й `qa suite` на host.
-Host і Multipass suite runs за замовчуванням виконують кілька вибраних сценаріїв паралельно
+Host- і Multipass-запуски suite за замовчуванням виконують кілька вибраних сценаріїв паралельно
 з ізольованими gateway workers. `qa-channel` за замовчуванням має concurrency
-4, обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency <count>`, щоб налаштувати
-кількість workers, або `--concurrency 1` для послідовного виконання.
-Команда завершується з ненульовим кодом, коли будь-який сценарій не вдається. Використовуйте `--allow-failures`, коли
-потрібні артефакти без коду завершення з помилкою.
-Live runs передають підтримувані QA auth inputs, практичні для
-guest: provider keys на основі env, шлях до QA live provider config і
-`CODEX_HOME`, коли він присутній. Тримайте `--output-dir` під коренем репозиторію, щоб guest
-міг записувати назад через mounted workspace.
+4, обмежену кількістю вибраних сценаріїв. Використовуйте `--concurrency <count>` для налаштування
+кількості workers або `--concurrency 1` для послідовного виконання.
+Команда завершується з ненульовим кодом, коли будь-який сценарій падає. Використовуйте `--allow-failures`, коли
+потрібні артефакти без failing exit code.
+Live-запуски передають підтримувані QA auth inputs, практичні для
+гостя: env-based provider keys, шлях до QA live provider config і
+`CODEX_HOME`, коли він присутній. Тримайте `--output-dir` під коренем репозиторію, щоб гість
+міг записувати назад через змонтований workspace.

-## Довідник QA для Telegram і Discord
+## Довідник QA для Telegram, Discord і Slack

-Matrix має [окрему сторінку](/uk/concepts/qa-matrix) через кількість сценаріїв і provisioning homeserver на Docker. Telegram і Discord менші — кілька сценаріїв кожен, без системи профілів, проти вже наявних реальних каналів — тому їхній довідник міститься тут.
+Matrix має [окрему сторінку](/uk/concepts/qa-matrix) через кількість сценаріїв і Docker-backed homeserver provisioning. Telegram, Discord і Slack менші — по кілька сценаріїв кожен, без системи профілів, проти вже наявних реальних каналів — тому їхній довідник наведено тут.

 ### Спільні CLI flags

-Обидва lanes реєструються через `extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts` і приймають однакові flags:
+Ці лінії реєструються через `extensions/qa-lab/src/live-transports/shared/live-transport-cli.ts` і приймають ті самі flags:

-| Прапор                               | Типове значення                                           | Опис                                                                                                                  |
-| ------------------------------------- | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
-| `--scenario <id>`                     | —                                                         | Запустити лише цей сценарій. Можна повторювати.                                                                       |
-| `--output-dir <path>`                 | `<repo>/.artifacts/qa-e2e/{telegram,discord}-<timestamp>` | Куди записуються звіти/підсумок/спостережені повідомлення та вихідний журнал. Відносні шляхи розв'язуються відносно `--repo-root`. |
-| `--repo-root <path>`                  | `process.cwd()`                                           | Корінь репозиторію під час виклику з нейтрального cwd.                                                                |
-| `--sut-account <id>`                  | `sut`                                                     | Тимчасовий id облікового запису всередині конфігурації QA gateway.                                                    |
-| `--provider-mode <mode>`              | `live-frontier`                                           | `mock-openai` або `live-frontier` (застарілий `live-openai` досі працює).                                             |
-| `--model <ref>` / `--alt-model <ref>` | типове значення провайдера                                | Посилання на основну/альтернативну модель.                                                                            |
-| `--fast`                              | вимкнено                                                  | Швидкий режим провайдера там, де підтримується.                                                                       |
-| `--credential-source <env\|convex>`   | `env`                                                     | Див. [пул облікових даних Convex](#convex-credential-pool).                                                          |
-| `--credential-role <maintainer\|ci>`  | `ci` у CI, інакше `maintainer`                            | Роль, що використовується, коли `--credential-source convex`.                                                         |
+| Прапор                               | Типово                                                          | Опис                                                                                                                  |
+| ------------------------------------- | --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| `--scenario <id>`                     | —                                                               | Запустити лише цей сценарій. Можна повторювати.                                                                       |
+| `--output-dir <path>`                 | `<repo>/.artifacts/qa-e2e/{telegram,discord,slack}-<timestamp>` | Куди записуються звіти/підсумок/спостережені повідомлення та журнал виводу. Відносні шляхи обчислюються відносно `--repo-root`. |
+| `--repo-root <path>`                  | `process.cwd()`                                                 | Корінь репозиторію під час виклику з нейтрального cwd.                                                                |
+| `--sut-account <id>`                  | `sut`                                                           | Тимчасовий ідентифікатор облікового запису в конфігурації QA gateway.                                                |
+| `--provider-mode <mode>`              | `live-frontier`                                                 | `mock-openai` або `live-frontier` (застарілий `live-openai` досі працює).                                            |
+| `--model <ref>` / `--alt-model <ref>` | типове значення провайдера                                      | Посилання на основну/альтернативну модель.                                                                            |
+| `--fast`                              | вимкнено                                                        | Швидкий режим провайдера там, де він підтримується.                                                                   |
+| `--credential-source <env\|convex>`   | `env`                                                           | Див. [пул облікових даних Convex](#convex-credential-pool).                                                          |
+| `--credential-role <maintainer\|ci>`  | `ci` у CI, інакше `maintainer`                                  | Роль, що використовується, коли `--credential-source convex`.                                                         |

-Обидва завершуються з ненульовим кодом виходу за будь-якого невдалого сценарію. `--allow-failures` записує артефакти без встановлення коду виходу як помилкового.
+Кожна смуга завершується з ненульовим кодом за будь-якого невдалого сценарію. `--allow-failures` записує артефакти без встановлення коду виходу, що означає помилку.

-### QA Telegram
+### Telegram QA

 ```bash
 pnpm openclaw qa telegram
 ```

-Націлено на одну реальну приватну групу Telegram із двома окремими ботами (драйвер + SUT). SUT-бот повинен мати ім'я користувача Telegram; спостереження bot-to-bot працює найкраще, коли в обох ботів увімкнено **Bot-to-Bot Communication Mode** у `@BotFather`.
+Націлюється на одну реальну приватну групу Telegram із двома різними ботами (драйвер + SUT). SUT-бот повинен мати імʼя користувача Telegram; спостереження бот-бот найкраще працює, коли в обох ботів увімкнено **Bot-to-Bot Communication Mode** у `@BotFather`.

-Обов'язкові env, коли `--credential-source env`:
+Обовʼязкові env, коли `--credential-source env`:

- `OPENCLAW_QA_TELEGRAM_GROUP_ID` — числовий id чату (рядок).
+- `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`):

@ -219,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-observed-messages.json` — тіла редагуються, якщо не задано `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1`.
+- `telegram-qa-summary.json` — містить RTT для кожної відповіді (надсилання драйвером → спостережена відповідь SUT), починаючи з canary.
+- `telegram-qa-observed-messages.json` — тіла редагуються, якщо не встановлено `OPENCLAW_QA_TELEGRAM_CAPTURE_CONTENT=1`.

-### QA Discord
+### Discord QA

 ```bash
 pnpm openclaw qa discord
 ```

-Націлено на один реальний приватний канал guild Discord із двома ботами: бот-драйвер, керований harness, і SUT-бот, запущений дочірнім OpenClaw gateway через вбудований Discord plugin. Перевіряє обробку згадок каналу, те, що SUT-бот зареєстрував нативну команду `/help` у Discord, і opt-in сценарії доказів Mantis.
+Націлюється на один реальний приватний канал гільдії Discord із двома ботами: ботом-драйвером, яким керує harness, і SUT-ботом, запущеним дочірнім OpenClaw gateway через вбудований Discord plugin. Перевіряє обробку згадок у каналі, що SUT-бот зареєстрував нативну команду `/help` у Discord, а також opt-in сценарії доказів Mantis.

-Обов'язкові env, коли `--credential-source env`:
+Обовʼязкові env, коли `--credential-source env`:

 - `OPENCLAW_QA_DISCORD_GUILD_ID`
 - `OPENCLAW_QA_DISCORD_CHANNEL_ID`
 - `OPENCLAW_QA_DISCORD_DRIVER_BOT_TOKEN`
 - `OPENCLAW_QA_DISCORD_SUT_BOT_TOKEN`
- `OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID` — має збігатися з id користувача SUT-бота, який повертає Discord (інакше lane швидко завершується з помилкою).
+- `OPENCLAW_QA_DISCORD_SUT_APPLICATION_ID` — має збігатися з ідентифікатором користувача SUT-бота, який повертає Discord (інакше смуга швидко завершується помилкою).

-Необов'язково:
+Необовʼязково:

 - `OPENCLAW_QA_DISCORD_CAPTURE_CONTENT=1` зберігає тіла повідомлень в артефактах спостережених повідомлень.

@ -250,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 на завжди ввімкнені відповіді guild лише через tools із `messages.statusReactions.enabled=true`, а потім захоплює часову шкалу реакцій REST плюс візуальний артефакт HTML/PNG.
+- `discord-status-reactions-tool-only` — opt-in сценарій Mantis. Виконується самостійно, бо перемикає SUT на завжди ввімкнені відповіді гільдії лише через інструменти з `messages.statusReactions.enabled=true`, а потім захоплює часову шкалу REST-реакцій і візуальний артефакт HTML/PNG.

-Запустити сценарій реакцій статусу Mantis явно:
+Запустіть сценарій status-reaction Mantis явно:

 ```bash
 pnpm openclaw qa discord \
@ -263,141 +266,171 @@ 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`, коли запускається сценарій реакцій статусу.
+- `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.
+
+### Slack QA
+
+```bash
+pnpm openclaw qa slack
+```
+
+Націлюється на один реальний приватний канал Slack із двома різними ботами: ботом-драйвером, яким керує harness, і SUT-ботом, запущеним дочірнім OpenClaw gateway через вбудований Slack plugin.
+
+Обовʼязкові 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` зберігає тіла повідомлень в артефактах спостережених повідомлень.
+
+Сценарії (`extensions/qa-lab/src/live-transports/slack/slack-live.runtime.ts:39`):
+
+- `slack-canary`
+- `slack-mention-gating`
+
+Артефакти виводу:
+
+- `slack-qa-report.md`
+- `slack-qa-summary.json`
+- `slack-qa-observed-messages.json` — тіла редагуються, якщо не встановлено `OPENCLAW_QA_SLACK_CAPTURE_CONTENT=1`.

 ### Пул облікових даних Convex

-Lane Telegram і Discord можуть орендувати облікові дані зі спільного пулу Convex замість читання env vars вище. Передайте `--credential-source convex` (або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`); QA Lab отримує ексклюзивну оренду, надсилає для неї Heartbeat протягом виконання та звільняє її під час завершення. Типи пулу — `"telegram"` і `"discord"`.
+Смуги Telegram, Discord і Slack можуть орендувати облікові дані зі спільного пулу Convex замість читання env vars вище. Передайте `--credential-source convex` (або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`); QA Lab отримує ексклюзивну оренду, надсилає heartbeat протягом виконання й звільняє її під час завершення роботи. Типи пулу: `"telegram"`, `"discord"` і `"slack"`.

 Форми payload, які брокер перевіряє на `admin/add`:

- Telegram (`kind: "telegram"`): `{ groupId: string, driverToken: string, sutToken: string }` — `groupId` має бути числовим рядком chat-id.
+- 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; семантика брокера однакова для обох типів).
+Операційні env vars і контракт endpoint брокера Convex описані в [Тестування → Спільні облікові дані Telegram через Convex](/uk/help/testing#shared-telegram-credentials-via-convex-v1) (назва розділу зʼявилася до підтримки Discord; семантика брокера ідентична для обох типів).

-## Seeds на основі репозиторію
+## Seeds, підкріплені репозиторієм

-Seed-активи розміщені в `qa/`:
+Seed-ресурси розташовані в `qa/`:

 - `qa/scenarios/index.md`
 - `qa/scenarios/<theme>/*.md`

-Вони навмисно зберігаються в git, щоб план QA був видимим і для людей, і для
-агента.
+Вони навмисно зберігаються в git, щоб план QA був видимий і людям, і
+агенту.

-`qa-lab` має залишатися універсальним runner для markdown. Кожен markdown-файл сценарію є
+`qa-lab` має залишатися універсальним markdown runner. Кожен markdown-файл сценарію є
 джерелом істини для одного тестового запуску й має визначати:

 - метадані сценарію
- необов'язкові метадані категорії, capability, lane і ризику
+- необовʼязкові метадані категорії, можливості, смуги та ризику
 - посилання на docs і code
- необов'язкові вимоги до plugin
- необов'язковий patch конфігурації gateway
+- необовʼязкові вимоги до plugin
+- необовʼязковий patch конфігурації gateway
 - виконуваний `qa-flow`

-Повторно використовувана runtime-поверхня, що підтримує `qa-flow`, може залишатися універсальною
-та наскрізною. Наприклад, markdown-сценарії можуть поєднувати helpers транспортної сторони
-з helpers браузерної сторони, які керують вбудованим Control UI через
-Gateway `browser.request` seam без додавання runner для спеціального випадку.
+Багаторазово використовувана runtime-поверхня, що підтримує `qa-flow`, може залишатися універсальною
+та наскрізною. Наприклад, markdown-сценарії можуть поєднувати transport-side
+помічники з browser-side помічниками, які керують вбудованим Control UI через
+шов Gateway `browser.request` без додавання runner для спеціального випадку.

-Файли сценаріїв слід групувати за capability продукту, а не за папкою дерева
-джерел. Зберігайте ID сценаріїв стабільними, коли файли переміщуються; використовуйте `docsRefs` і `codeRefs`
-для простежуваності реалізації.
+Файли сценаріїв слід групувати за продуктовою можливістю, а не за папкою
+дерева джерел. Зберігайте ідентифікатори сценаріїв стабільними під час переміщення файлів; використовуйте `docsRefs` і `codeRefs`
+для трасованості реалізації.

 Базовий список має залишатися достатньо широким, щоб покривати:

 - DM і чат каналу
 - поведінку thread
- життєвий цикл дій із повідомленнями
- callbacks Cron
- пригадування пам'яті
+- життєвий цикл message action
+- callbacks cron
+- пригадування памʼяті
 - перемикання моделей
 - передавання subagent
 - читання репозиторію та читання docs
- одне невелике завдання збірки, як-от Lobster Invaders
+- одне невелике build-завдання, наприклад Lobster Invaders

-## Mock lanes провайдера
+## Mock-смуги провайдерів

-`qa suite` має дві локальні mock lanes провайдера:
+`qa suite` має дві локальні mock-смуги провайдерів:

- `mock-openai` — сценарно-обізнаний mock OpenClaw. Він залишається типовою
-  детермінованою mock lane для QA на основі репозиторію та parity gates.
- `aimock` запускає сервер провайдера на базі AIMock для експериментального protocol,
+- `mock-openai` — це scenario-aware OpenClaw mock. Він залишається типовою
+  детермінованою mock-смугою для repo-backed QA і parity gates.
+- `aimock` запускає AIMock-backed сервер провайдера для експериментального protocol,
  fixture, record/replay і chaos coverage. Він є додатковим і не
  замінює диспетчер сценаріїв `mock-openai`.

-Реалізація provider-lane розміщена в `extensions/qa-lab/src/providers/`.
+Реалізація provider-lane розташована в `extensions/qa-lab/src/providers/`.
 Кожен провайдер володіє своїми типовими значеннями, запуском локального сервера, конфігурацією моделі gateway,
-потребами staged auth-profile і прапорами capability live/mock. Спільний код suite і
-gateway має маршрутизувати через registry провайдера замість розгалуження за
+потребами staged auth-profile, а також live/mock capability flags. Спільний suite і
+код gateway мають маршрутизуватися через registry провайдерів замість розгалуження за
 іменами провайдерів.

-## Транспортні адаптери
+## Transport adapters

-`qa-lab` володіє універсальним transport seam для markdown QA-сценаріїв. `qa-channel` — перший адаптер на цьому seam, але ціль дизайну ширша: майбутні реальні або синтетичні канали мають підключатися до того самого suite runner замість додавання транспортно-специфічного QA runner.
+`qa-lab` володіє універсальним transport seam для markdown QA сценаріїв. `qa-channel` є першим adapter на цьому seam, але ціль дизайну ширша: майбутні реальні або synthetic channels мають підключатися до того самого suite runner замість додавання transport-specific QA runner.

-На рівні архітектури поділ такий:
+На рівні архітектури розподіл такий:

- `qa-lab` володіє універсальним виконанням сценаріїв, concurrency worker, записом артефактів і звітністю.
- Транспортний адаптер володіє конфігурацією gateway, готовністю, inbound і outbound спостереженням, транспортними діями та нормалізованим транспортним станом.
- Markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає повторно використовувану runtime-поверхню, яка їх виконує.
+- `qa-lab` володіє універсальним виконанням сценаріїв, паралельністю worker, записом артефактів і звітністю.
+- Transport adapter володіє конфігурацією gateway, readiness, inbound and outbound observation, transport actions і normalized transport state.
+- Markdown-файли сценаріїв у `qa/scenarios/` визначають тестовий запуск; `qa-lab` надає багаторазово використовувану runtime-поверхню, яка їх виконує.

 ### Додавання каналу

-Додавання каналу до markdown-системи QA потребує рівно двох речей:
+Додавання каналу до markdown QA system вимагає рівно двох речей:

-1. Транспортного адаптера для каналу.
-2. Пакета сценаріїв, який перевіряє контракт каналу.
+1. Transport adapter для каналу.
+2. Scenario pack, який перевіряє контракт каналу.

-Не додавайте новий кореневий QA command верхнього рівня, коли спільний хост `qa-lab` може володіти flow.
+Не додавайте новий top-level QA command root, коли спільний хост `qa-lab` може володіти потоком.

 `qa-lab` володіє спільною механікою хоста:

- корінь команди `openclaw qa`
+- command root `openclaw qa`
 - запуск і teardown suite
- concurrency worker
+- паралельність worker
 - запис артефактів
- генерація звіту
+- генерування звіту
 - виконання сценаріїв
- compatibility aliases для старіших сценаріїв `qa-channel`
+- aliases сумісності для старіших сценаріїв `qa-channel`

-Runner plugins володіють транспортним контрактом:
+Runner plugins володіють transport contract:

- як `openclaw qa <runner>` монтується під спільним коренем `qa`
- як gateway конфігурується для цього транспорту
- як перевіряється готовність
- як вводяться inbound-події
- як спостерігаються outbound-повідомлення
- як transcripts і нормалізований транспортний стан надаються назовні
- як виконуються дії, підтримувані транспортом
- як обробляється транспортно-специфічне скидання або очищення
+- як `openclaw qa <runner>` монтується під спільним root `qa`
+- як gateway налаштовується для цього transport
+- як перевіряється readiness
+- як injected inbound events
+- як спостерігаються outbound messages
+- як transcripts і normalized transport state доступні назовні
+- як виконуються transport-backed actions
+- як обробляється transport-specific reset або cleanup

-Мінімальна планка adoption для нового каналу:
+Мінімальна планка впровадження для нового каналу:

-1. Зберігайте `qa-lab` власником спільного кореня `qa`.
-2. Реалізуйте transport runner на спільному host seam `qa-lab`.
-3. Тримайте транспортно-специфічну механіку всередині runner plugin або channel harness.
-4. Монтуйте runner як `openclaw qa <runner>` замість реєстрації конкуруючої root command. Runner plugins мають оголошувати `qaRunners` в `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` із `runtime-api.ts`. Тримайте `runtime-api.ts` легким; lazy CLI і виконання runner мають залишатися за окремими entrypoints.
-5. Створіть або адаптуйте markdown-сценарії в тематичних директоріях `qa/scenarios/`.
-6. Використовуйте універсальні helpers сценаріїв для нових сценаріїв.
-7. Зберігайте наявні compatibility aliases робочими, якщо репозиторій не виконує навмисну міграцію.
+1. Залиште `qa-lab` власником спільного кореня `qa`.
+2. Реалізуйте виконавець транспорту на спільному стику хоста `qa-lab`.
+3. Тримайте механіку, специфічну для транспорту, всередині Plugin виконавця або обв’язки каналу.
+4. Змонтуйте виконавець як `openclaw qa <runner>` замість реєстрації конкуруючої кореневої команди. Plugin-и виконавців мають оголошувати `qaRunners` в `openclaw.plugin.json` і експортувати відповідний масив `qaRunnerCliRegistrations` з `runtime-api.ts`. Тримайте `runtime-api.ts` легким; ліниве виконання CLI і виконавця має лишатися за окремими точками входу.
+5. Створіть або адаптуйте markdown-сценарії у тематичних каталогах `qa/scenarios/`.
+6. Використовуйте загальні допоміжні функції сценаріїв для нових сценаріїв.
+7. Зберігайте роботу наявних псевдонімів сумісності, якщо репозиторій не виконує навмисну міграцію.

-Правило ухвалення рішень суворе:
+Правило ухвалення рішення суворе:

 - Якщо поведінку можна виразити один раз у `qa-lab`, помістіть її в `qa-lab`.
- Якщо поведінка залежить від транспорту одного каналу, тримайте її в цьому runner plugin або plugin harness.
- Якщо сценарію потрібна нова capability, яку може використовувати більше ніж один канал, додайте універсальний helper замість гілки, специфічної для каналу, у `suite.ts`.
- Якщо поведінка має сенс лише для одного транспорту, залиште сценарій транспортно-специфічним і зробіть це явним у контракті сценарію.
+- Якщо поведінка залежить від одного транспорту каналу, тримайте її в цьому Plugin виконавця або обв’язці Plugin.
+- Якщо сценарію потрібна нова можливість, яку може використовувати більш ніж один канал, додайте загальну допоміжну функцію замість гілки, специфічної для каналу, у `suite.ts`.
+- Якщо поведінка має сенс лише для одного транспорту, залиште сценарій специфічним для транспорту й явно вкажіть це в контракті сценарію.

-### Назви helpers сценаріїв
+### Назви допоміжних функцій сценаріїв

-Бажані універсальні helpers для нових сценаріїв:
+Бажані загальні допоміжні функції для нових сценаріїв:

 - `waitForTransportReady`
 - `waitForChannelReady`
@ -412,11 +445,11 @@ Runner plugins володіють транспортним контрактом:
 - `formatTransportTranscript`
 - `resetTransport`

-Сумісні псевдоніми залишаються доступними для наявних сценаріїв — `waitForQaChannelReady`, `waitForOutboundMessage`, `waitForNoOutbound`, `formatConversationTranscript`, `resetBus` — але для написання нових сценаріїв слід використовувати загальні назви. Псевдоніми існують, щоб уникнути міграції в один день, а не як модель на майбутнє.
+Псевдоніми сумісності лишаються доступними для наявних сценаріїв — `waitForQaChannelReady`, `waitForOutboundMessage`, `waitForNoOutbound`, `formatConversationTranscript`, `resetBus` — але для створення нових сценаріїв слід використовувати загальні назви. Псевдоніми існують, щоб уникнути одночасної міграції всього коду, а не як модель на майбутнє.

 ## Звітування

-`qa-lab` експортує протокольний Markdown-звіт зі спостережуваної часової шкали шини.
+`qa-lab` експортує Markdown-звіт протоколу зі спостережуваної часової шкали шини.
 Звіт має відповідати на такі питання:

 - Що спрацювало
@ -424,10 +457,10 @@ Runner plugins володіють транспортним контрактом:
 - Що залишилося заблокованим
 - Які подальші сценарії варто додати

-Щоб отримати інвентар доступних сценаріїв — корисний під час оцінювання обсягу подальшої роботи або підключення нового транспорту — виконайте `pnpm openclaw qa coverage` (додайте `--json` для машинозчитуваного виводу).
+Для інвентаризації доступних сценаріїв — корисної під час оцінювання обсягу подальшої роботи або підключення нового транспорту — виконайте `pnpm openclaw qa coverage` (додайте `--json` для машинозчитуваного виводу).

-Для перевірок характеру й стилю запустіть той самий сценарій для кількох живих
-референсів моделей і запишіть оцінений Markdown-звіт:
+Для перевірок характеру та стилю виконайте той самий сценарій на кількох live model
+refs і запишіть оцінений Markdown-звіт:

 ```bash
 pnpm openclaw qa character-eval \
@ -446,41 +479,42 @@ pnpm openclaw qa character-eval \
  --judge-concurrency 16
 ```

-Команда запускає локальні дочірні процеси QA Gateway, а не Docker. Сценарії оцінювання
-характеру мають задавати персону через `SOUL.md`, а потім виконувати звичайні ходи
-користувача, як-от чат, допомога з робочою областю та невеликі файлові завдання. Моделі-кандидату
+Команда запускає дочірні процеси локального QA Gateway, а не Docker. Сценарії оцінювання характеру
+мають задавати персону через `SOUL.md`, а потім виконувати звичайні ходи користувача,
+як-от чат, допомогу з робочим простором і невеликі файлові завдання. Моделі-кандидату
 не слід повідомляти, що її оцінюють. Команда зберігає кожен повний
-транскрипт, записує базову статистику запуску, а потім просить моделі-судді в швидкому режимі з
+транскрипт, записує базову статистику запуску, а потім просить моделі-судді у швидкому режимі з
 міркуванням `xhigh`, де це підтримується, ранжувати запуски за природністю, вайбом і гумором.
-Використовуйте `--blind-judge-models` під час порівняння провайдерів: промпт судді все одно отримує
-кожен транскрипт і статус запуску, але референси кандидатів замінюються нейтральними
-мітками, як-от `candidate-01`; після парсингу звіт зіставляє рейтинги назад із реальними референсами.
+Використовуйте `--blind-judge-models` під час порівняння провайдерів: підказка судді все одно отримує
+кожен транскрипт і статус запуску, але refs кандидатів замінюються нейтральними
+мітками, як-от `candidate-01`; звіт зіставляє рейтинги назад із реальними refs після
+розбору.
 Запуски кандидатів за замовчуванням використовують мислення `high`, з `medium` для GPT-5.5 і `xhigh`
-для старіших оцінювальних референсів OpenAI, які це підтримують. Перевизначте конкретного кандидата вбудовано за допомогою
-`--model provider/model,thinking=<level>`. `--thinking <level>` досі задає
-глобальний резервний варіант, а старіша форма `--model-thinking <provider/model=level>`
-збережена для сумісності.
-Референси кандидатів OpenAI за замовчуванням використовують швидкий режим, щоб там,
-де провайдер це підтримує, застосовувалася пріоритетна обробка. Додайте `,fast`, `,no-fast` або `,fast=false` вбудовано, коли
-окремому кандидату чи судді потрібне перевизначення. Передавайте `--fast` лише тоді, коли хочете
-примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалості кандидатів і суддів
-записуються у звіт для бенчмарк-аналізу, але промпти суддів явно вказують
+для старіших refs оцінювання OpenAI, які це підтримують. Перевизначте конкретного кандидата inline за допомогою
+`--model provider/model,thinking=<level>`. `--thinking <level>` все ще задає
+глобальний fallback, а старіша форма `--model-thinking <provider/model=level>` зберігається
+для сумісності.
+Refs кандидатів OpenAI за замовчуванням використовують швидкий режим, щоб пріоритетна обробка застосовувалась там, де
+провайдер її підтримує. Додайте `,fast`, `,no-fast` або `,fast=false` inline, коли
+окремий кандидат або суддя потребує перевизначення. Передавайте `--fast` лише тоді, коли хочете
+примусово ввімкнути швидкий режим для кожної моделі-кандидата. Тривалості для кандидатів і суддів
+записуються у звіті для аналізу бенчмарків, але підказки суддів явно вказують
 не ранжувати за швидкістю.
-Запуски моделей-кандидатів і моделей-суддів за замовчуванням мають concurrency 16. Зменште
-`--concurrency` або `--judge-concurrency`, коли ліміти провайдера чи навантаження на локальний Gateway
-роблять запуск надто шумним.
-Коли не передано жодного кандидата `--model`, оцінювання характеру за замовчуванням використовує
+Запуски моделей-кандидатів і суддів за замовчуванням обидва використовують concurrency 16. Зменште
+`--concurrency` або `--judge-concurrency`, коли ліміти провайдера або навантаження на локальний Gateway
+роблять запуск занадто шумним.
+Коли кандидатський `--model` не передано, оцінювання характеру за замовчуванням використовує
 `openai/gpt-5.5`, `openai/gpt-5.2`, `openai/gpt-5`, `anthropic/claude-opus-4-6`,
 `anthropic/claude-sonnet-4-6`, `zai/glm-5.1`,
 `moonshot/kimi-k2.5` і
-`google/gemini-3.1-pro-preview`, якщо `--model` не передано.
-Коли не передано `--judge-model`, судді за замовчуванням такі:
+`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/concepts/qa-matrix)
 - [Канал QA](/uk/channels/qa-channel)
 - [Тестування](/uk/help/testing)
 - [Панель керування](/uk/web/dashboard)
--- a/docs/uk/concepts/queue-steering.md
+++ b/docs/uk/concepts/queue-steering.md
@ -1,60 +1,63 @@
 ---
 read_when:
-    - Пояснення того, як працює керування, коли агент використовує інструменти
-    - Зміна поведінки черги активного запуску або інтеграції керування під час виконання
-    - Порівняння режимів керування, черги, збирання та подальших дій
-summary: Як керування активним запуском ставить повідомлення в чергу на межах середовища виконання
+    - Пояснення того, як steer поводиться, поки агент використовує інструменти
+    - Зміна поведінки черги активних запусків або інтеграції керування під час виконання
+    - Порівняння режимів steer, queue, collect і followup
+summary: Як керування активним виконанням ставить повідомлення в чергу на межах середовища виконання
 title: Черга керування
 x-i18n:
-    generated_at: "2026-04-30T00:29:59Z"
+    generated_at: "2026-05-03T22:25:48Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 560390c8c26bcce95e0137f4336ad6e62bc3e2344cb15fd12ca3cfe4a85a8acc
+    source_hash: c8df35b127ae0c1e1b3b684a1f63ce33874eb3d0b7bf9d0df7cb9dfce093090a
    source_path: concepts/queue-steering.md
    workflow: 16
 ---

-Коли повідомлення надходить, поки запуск сеансу вже транслюється, OpenClaw може
-надіслати це повідомлення в активне середовище виконання замість запуску ще одного
-запуску для того самого сеансу. Публічні режими нейтральні до середовища виконання; Pi і нативний каркас сервера застосунку Codex
+Коли повідомлення надходить під час потокового виконання запуску сеансу, OpenClaw може
+надіслати це повідомлення в активне середовище виконання замість запуску ще одного виконання для
+того самого сеансу. Публічні режими не залежать від середовища виконання; Pi і нативна обв’язка app-server Codex
 реалізують деталі доставки по-різному.

 ## Межа середовища виконання

-Скерування не перериває виклик інструмента, який уже виконується. Pi перевіряє
-наявність поставлених у чергу повідомлень скерування на межах моделі:
+Керування не перериває виклик інструмента, який уже виконується. Pi перевіряє
+поставлені в чергу повідомлення керування на межах моделі:

 1. Асистент запитує виклики інструментів.
 2. Pi виконує пакет викликів інструментів поточного повідомлення асистента.
-3. Pi генерує подію завершення ходу.
-4. Pi вичерпує поставлені в чергу повідомлення скерування.
+3. Pi надсилає подію завершення ходу.
+4. Pi обробляє поставлені в чергу повідомлення керування.
 5. Pi додає ці повідомлення як повідомлення користувача перед наступним викликом LLM.

-Це зберігає результати інструментів у парі з повідомленням асистента, яке їх запитало,
-а потім дає наступному виклику моделі побачити найновіший ввід користувача.
+Це зберігає результати інструментів пов’язаними з повідомленням асистента, яке їх
+запитало, а потім дає наступному виклику моделі побачити найновіші введені дані користувача.

-Нативний каркас сервера застосунку Codex надає `turn/steer` замість
-внутрішньої черги скерування Pi. OpenClaw адаптує там ті самі режими:
+Нативна обв’язка app-server Codex надає `turn/steer` замість внутрішньої
+черги керування Pi. OpenClaw адаптує ті самі режими там:

 - `steer` групує поставлені в чергу повідомлення протягом налаштованого тихого вікна, а потім надсилає
-  один запит `turn/steer` з усім зібраним вводом користувача в порядку надходження.
+  один запит `turn/steer` з усіма зібраними введеними даними користувача в порядку надходження.
 - `queue` зберігає застарілу серіалізовану форму, надсилаючи окремі запити `turn/steer`.
- `followup`, `collect`, `steer-backlog` і `interrupt` залишаються поведінкою черги, якою володіє OpenClaw,
+- `followup`, `collect`, `steer-backlog` і `interrupt` залишаються поведінкою черги, якою володіє OpenClaw
  навколо активного ходу Codex.

-Ходи перегляду Codex і ручної Compaction відхиляють скерування в межах того самого ходу. Коли
-середовище виконання не може прийняти скерування, OpenClaw повертається до черги подальших дій там, де
+Ходи рецензування Codex і ручної Compaction відхиляють керування в межах того самого ходу. Коли
+середовище виконання не може прийняти керування, OpenClaw повертається до черги подальших дій там, де
 цей режим це дозволяє.

+Ця сторінка пояснює керування в режимі черги для звичайних вхідних повідомлень. Для
+явної команди `/steer <message>` див. [Керування](/uk/tools/steer).
+
 ## Режими

-| Режим           | Поведінка під час активного запуску                                                                                         | Поведінка подальшої дії пізніше                                                   |
+| Режим           | Поведінка активного запуску                                                                                                  | Поведінка подальших дій пізніше                                                     |
 | --------------- | ---------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
-| `steer`         | Вставляє всі поставлені в чергу повідомлення скерування разом на наступній межі середовища виконання. Це стандартний режим. | Повертається до подальшої дії лише тоді, коли скерування недоступне.               |
-| `queue`         | Застаріле почергове скерування. Pi вставляє по одному поставленому в чергу повідомленню на межу моделі; Codex надсилає окремі запити `turn/steer`. | Повертається до подальшої дії лише тоді, коли скерування недоступне.               |
-| `steer-backlog` | Та сама поведінка скерування активного запуску, що й у `steer`.                                                              | Також зберігає те саме повідомлення для пізнішого ходу подальшої дії.              |
-| `followup`      | Не скеровує поточний запуск.                                                                                                 | Запускає поставлені в чергу повідомлення пізніше.                                  |
-| `collect`       | Не скеровує поточний запуск.                                                                                                 | Об'єднує сумісні поставлені в чергу повідомлення в один пізніший хід після вікна debounce. |
+| `steer`         | Вставляє всі поставлені в чергу повідомлення керування разом на наступній межі середовища виконання. Це значення за замовчуванням. | Повертається до подальших дій лише тоді, коли керування недоступне.                 |
+| `queue`         | Застаріле покрокове керування. Pi вставляє одне повідомлення з черги на кожній межі моделі; Codex надсилає окремі запити `turn/steer`. | Повертається до подальших дій лише тоді, коли керування недоступне.                 |
+| `steer-backlog` | Та сама поведінка керування активним запуском, що й у `steer`.                                                               | Також зберігає те саме повідомлення для пізнішого ходу подальших дій.               |
+| `followup`      | Не керує поточним запуском.                                                                                                  | Запускає поставлені в чергу повідомлення пізніше.                                   |
+| `collect`       | Не керує поточним запуском.                                                                                                  | Об’єднує сумісні поставлені в чергу повідомлення в один пізніший хід після вікна debounce. |
 | `interrupt`     | Перериває активний запуск, а потім запускає найновіше повідомлення.                                                          | Немає.                                                                              |

 ## Приклад сплеску
@ -62,35 +65,36 @@ x-i18n:
 Якщо четверо користувачів надсилають повідомлення, поки агент виконує виклик інструмента:

 - `steer`: активне середовище виконання отримує всі чотири повідомлення в порядку надходження перед
-  своїм наступним рішенням моделі. Pi вичерпує їх на наступній межі моделі; Codex
+  своїм наступним рішенням моделі. Pi обробляє їх на наступній межі моделі; Codex
  отримує їх як один пакетний `turn/steer`.
- `queue`: застаріле серіалізоване скерування. Pi вставляє по одному поставленому в чергу повідомленню за раз;
+- `queue`: застаріле серіалізоване керування. Pi вставляє по одному повідомленню з черги;
  Codex отримує окремі запити `turn/steer`.
- `collect`: OpenClaw чекає, доки активний запуск завершиться, а потім створює хід подальшої дії
-  із сумісними поставленими в чергу повідомленнями після вікна debounce.
+- `collect`: OpenClaw чекає, доки активний запуск завершиться, а потім створює хід подальших дій
+  із сумісними повідомленнями з черги після вікна debounce.

 ## Область дії

-Скерування завжди націлене на поточний активний запуск сеансу. Воно не створює новий
+Керування завжди націлене на поточний активний запуск сеансу. Воно не створює новий
 сеанс, не змінює політику інструментів активного запуску й не розділяє повідомлення за відправником. У
-багатокористувацьких каналах вхідні промпти вже містять контекст відправника й маршруту, тож
+багатокористувацьких каналах вхідні підказки вже містять контекст відправника й маршруту, тож
 наступний виклик моделі може бачити, хто надіслав кожне повідомлення.

-Використовуйте `collect`, коли потрібно, щоб OpenClaw побудував пізніший хід подальшої дії, який може
-об'єднувати сумісні повідомлення та зберігати політику відкидання черги подальших дій. Використовуйте
-`queue` лише тоді, коли вам потрібна старіша поведінка почергового скерування.
+Використовуйте `collect`, коли хочете, щоб OpenClaw побудував пізніший хід подальших дій, який може
+об’єднувати сумісні повідомлення й зберігати політику відкидання черги подальших дій. Використовуйте
+`queue` лише тоді, коли вам потрібна старіша поведінка покрокового керування.

 ## Debounce

-`messages.queue.debounceMs` застосовується до доставки подальших дій, включно з `collect`,
-`followup`, `steer-backlog` і резервним варіантом `steer`, коли скерування активного запуску
+`messages.queue.debounceMs` застосовується до доставки подальших дій, зокрема `collect`,
+`followup`, `steer-backlog` і резервного варіанта `steer`, коли керування активним запуском
 недоступне. Для Pi активний `steer` сам не використовує таймер debounce, тому що
-Pi природно групує повідомлення до наступної межі моделі. Для нативного
-каркаса Codex OpenClaw використовує те саме значення debounce як тихе вікно перед
+Pi природно групує повідомлення до наступної межі моделі. Для нативної
+обв’язки Codex OpenClaw використовує те саме значення debounce як тихе вікно перед
 надсиланням пакетного `turn/steer`.

-## Пов'язане
+## Пов’язане

 - [Черга команд](/uk/concepts/queue)
+- [Керування](/uk/tools/steer)
 - [Повідомлення](/uk/concepts/messages)
 - [Цикл агента](/uk/concepts/agent-loop)
--- a/docs/uk/concepts/queue.md
+++ b/docs/uk/concepts/queue.md
@ -1,32 +1,32 @@
 ---
 read_when:
    - Зміна виконання автоматичних відповідей або паралельності
-    - Пояснення режимів /queue або поведінки скерування повідомлень
+    - Пояснення режимів /queue або поведінки спрямування повідомлень
 summary: Режими черги автовідповідей, значення за замовчуванням і перевизначення для окремих сеансів
 title: Черга команд
 x-i18n:
-    generated_at: "2026-05-01T23:48:20Z"
+    generated_at: "2026-05-03T22:25:36Z"
    model: gpt-5.5
    provider: openai
-    source_hash: c59ea6802d8bf526f4005db3b1baa87d96a23d561c916f91520e8e641fbaf74f
+    source_hash: 085aebe7059020f027eb08bb382cce2d253ea117eed0ca77d6ffd208f295acb1
    source_path: concepts/queue.md
    workflow: 16
 ---

-Ми серіалізуємо вхідні запуски автовідповідей (усі канали) через невелику внутрішньопроцесну чергу, щоб запобігти зіткненню кількох запусків агента, водночас зберігаючи безпечний паралелізм між сесіями.
+Ми серіалізуємо вхідні запуски автовідповідей (усі канали) через невелику внутрішньопроцесну чергу, щоб запобігти зіткненню кількох запусків агентів, водночас зберігаючи безпечний паралелізм між сесіями.

 ## Навіщо

- Запуски автовідповідей можуть бути витратними (виклики LLM) і можуть конфліктувати, коли кілька вхідних повідомлень надходять майже одночасно.
- Серіалізація запобігає конкуренції за спільні ресурси (файли сесій, журнали, stdin CLI) і зменшує ймовірність обмежень швидкості на боці вищого рівня.
+- Запуски автовідповідей можуть бути дорогими (виклики LLM) і можуть конфліктувати, коли кілька вхідних повідомлень надходять майже одночасно.
+- Серіалізація запобігає конкуренції за спільні ресурси (файли сесій, журнали, CLI stdin) і зменшує ймовірність лімітів частоти від зовнішніх сервісів.

 ## Як це працює

- FIFO-черга з урахуванням смуг обробляє кожну смугу з налаштовуваним лімітом паралельності (типово 1 для неналаштованих смуг; `main` типово 4, `subagent` — 8).
- `runEmbeddedPiAgent` ставить у чергу за **ключем сесії** (смуга `session:<key>`), щоб гарантувати лише один активний запуск на сесію.
- Кожен запуск сесії потім ставиться в **глобальну смугу** (типово `main`), тож загальний паралелізм обмежується `agents.defaults.maxConcurrent`.
- Коли ввімкнено докладне журналювання, запуски в черзі виводять коротке повідомлення, якщо вони чекали понад ~2 с перед стартом.
- Індикатори набору все одно спрацьовують негайно під час додавання до черги (якщо канал це підтримує), тож користувацький досвід не змінюється, поки ми чекаємо своєї черги.
+- FIFO-черга з урахуванням смуг обробляє кожну смугу з налаштовуваним лімітом конкурентності (типово 1 для неналаштованих смуг; для main типово 4, для subagent — 8).
+- `runEmbeddedPiAgent` додає до черги за **ключем сесії** (смуга `session:<key>`), щоб гарантувати лише один активний запуск на сесію.
+- Потім кожен запуск сесії додається до **глобальної смуги** (`main` типово), щоб загальний паралелізм обмежувався `agents.defaults.maxConcurrent`.
+- Коли ввімкнено докладне журналювання, запуски в черзі виводять коротке повідомлення, якщо чекали понад ~2 с перед стартом.
+- Індикатори набору все одно спрацьовують одразу під час додавання до черги (якщо канал це підтримує), тому користувацький досвід не змінюється, поки ми чекаємо своєї черги.

 ## Типові значення

@ -37,30 +37,31 @@ x-i18n:
 - `cap: 20`
 - `drop: "summarize"`

-`steer` є типовим, бо зберігає активний хід моделі чутливим без
-запуску другого виконання сесії. Він обробляє всі керівні повідомлення, що надійшли
-до наступної межі моделі. Якщо поточний запуск не може приймати керування,
-OpenClaw повертається до запису черги для подальшого ходу.
+`steer` є типовим, бо він зберігає активний хід моделі швидким без
+запуску другої сесії. Він обробляє всі steering-повідомлення, що надійшли
+до наступної межі моделі. Якщо поточний запуск не може приймати steering,
+OpenClaw повертається до запису в черзі followup.

 ## Режими черги

-Вхідні повідомлення можуть керувати поточним запуском, чекати наступного ходу або робити і те, і інше:
+Вхідні повідомлення можуть скеровувати поточний запуск, чекати наступного ходу followup або робити обидва:

- `steer`: ставить керівні повідомлення в чергу активного середовища виконання. Pi доставляє всі очікувані керівні повідомлення **після завершення виконання викликів інструментів поточного ходу асистента**, перед наступним викликом LLM; app-server Codex отримує один пакетний `turn/steer`. Якщо запуск не транслюється активно або керування недоступне, OpenClaw повертається до запису черги для подальшого ходу.
- `queue` (застарілий): старе керування по одному повідомленню за раз. Pi доставляє одне керівне повідомлення з черги на кожній межі моделі; app-server Codex отримує окремі запити `turn/steer`. Віддавайте перевагу `steer`, якщо вам не потрібна попередня серіалізована поведінка.
- `followup`: ставить кожне повідомлення в чергу для пізнішого ходу агента після завершення поточного запуску.
- `collect`: об’єднує повідомлення з черги в **один** подальший хід після вікна тиші. Якщо повідомлення націлені на різні канали/треди, вони обробляються окремо, щоб зберегти маршрутизацію.
- `steer-backlog` (також `steer+backlog`): керує зараз **і** зберігає те саме повідомлення для подальшого ходу.
+- `steer`: додає steering-повідомлення до активного середовища виконання. Pi доставляє всі pending steering-повідомлення **після завершення виконання викликів інструментів поточним ходом асистента**, перед наступним викликом LLM; Codex app-server отримує один пакетний `turn/steer`. Якщо запуск не транслюється активно або steering недоступний, OpenClaw повертається до запису в черзі followup.
+- `queue` (застарілий): старий steering по одному повідомленню. Pi доставляє одне повідомлення steering з черги на кожній межі моделі; Codex app-server отримує окремі запити `turn/steer`. Надавайте перевагу `steer`, якщо вам не потрібна попередня серіалізована поведінка.
+- `followup`: додає кожне повідомлення до черги для пізнішого ходу агента після завершення поточного запуску.
+- `collect`: об’єднує повідомлення з черги в **один** хід followup після періоду тиші. Якщо повідомлення націлені на різні канали/треди, вони обробляються окремо, щоб зберегти маршрутизацію.
+- `steer-backlog` (також `steer+backlog`): скеровує зараз **і** зберігає те саме повідомлення для ходу followup.
 - `interrupt` (застарілий): перериває активний запуск для цієї сесії, а потім запускає найновіше повідомлення.

-Steer-backlog означає, що ви можете отримати подальшу відповідь після керованого запуску, тому
-поверхні потокової передачі можуть виглядати як дублікати. Віддавайте перевагу `collect`/`steer`, якщо хочете
-одну відповідь на вхідне повідомлення.
+Steer-backlog означає, що ви можете отримати відповідь followup після скерованого запуску, тому
+поверхні потокового передавання можуть виглядати як дублікати. Надавайте перевагу `collect`/`steer`, якщо хочете
+одну відповідь на кожне вхідне повідомлення.

-Про специфічну для середовища виконання синхронізацію та поведінку залежностей див.
-[Черга керування](/uk/concepts/queue-steering).
+Про поведінку таймінгу й залежностей для конкретних середовищ виконання див.
+[Черга steering](/uk/concepts/queue-steering). Про явну команду `/steer <message>`
+див. [Steer](/uk/tools/steer).

-Налаштовуйте глобально або для кожного каналу через `messages.queue`:
+Налаштуйте глобально або для кожного каналу через `messages.queue`:

 ```json5
 {
@ -78,53 +79,53 @@ Steer-backlog означає, що ви можете отримати подал

 ## Параметри черги

-Параметри застосовуються до `followup`, `collect` і `steer-backlog` (а також до `steer` або застарілого `queue`, коли керування повертається до подальшого ходу):
+Параметри застосовуються до `followup`, `collect` і `steer-backlog` (а також до `steer` або застарілого `queue`, коли steering повертається до followup):

- `debounceMs`: вікно тиші перед обробкою подальших ходів із черги. Голі числа — це мілісекунди; одиниці `ms`, `s`, `m`, `h` і `d` приймаються параметрами `/queue`.
- `cap`: максимальна кількість повідомлень у черзі на сесію. Значення нижче `1` ігноруються.
- `drop: "summarize"`: типово. Викидає найстаріші записи черги за потреби, зберігає компактні підсумки та вставляє їх як синтетичний подальший запит.
- `drop: "old"`: викидає найстаріші записи черги за потреби без збереження підсумків.
+- `debounceMs`: період тиші перед обробкою queued followups. Числа без одиниць — це мілісекунди; одиниці `ms`, `s`, `m`, `h` і `d` приймаються параметрами `/queue`.
+- `cap`: максимальна кількість повідомлень у черзі на сесію. Значення менші за `1` ігноруються.
+- `drop: "summarize"`: типово. Видаляє найстаріші записи черги за потреби, зберігає компактні підсумки й вставляє їх як синтетичний prompt followup.
+- `drop: "old"`: видаляє найстаріші записи черги за потреби, без збереження підсумків.
 - `drop: "new"`: відхиляє найновіше повідомлення, коли черга вже заповнена.

 Типові значення: `debounceMs: 500`, `cap: 20`, `drop: summarize`.

-## Пріоритетність
+## Пріоритет

 Для вибору режиму OpenClaw визначає:

-1. Вбудоване або збережене перевизначення `/queue` для сесії.
+1. Inline або збережене перевизначення `/queue` для сесії.
 2. `messages.queue.byChannel.<channel>`.
 3. `messages.queue.mode`.
 4. Типовий `steer`.

-Для параметрів вбудовані або збережені параметри `/queue` мають перевагу над конфігурацією. Потім
-застосовуються специфічне для каналу згладжування (`messages.queue.debounceMsByChannel`), типові значення згладжування Plugin,
-глобальні параметри `messages.queue` і вбудовані типові значення. `cap` і `drop` є глобальними/сесійними параметрами, а не ключами конфігурації
-для окремих каналів.
+Для параметрів inline або збережені параметри `/queue` мають пріоритет над конфігурацією. Потім
+застосовуються специфічний для каналу debounce (`messages.queue.debounceMsByChannel`), типові значення debounce для Plugin,
+глобальні параметри `messages.queue` і вбудовані типові значення. `cap` і `drop` — це глобальні/сесійні параметри, а не ключі конфігурації для кожного каналу.

 ## Перевизначення для сесії

 - Надішліть `/queue <mode>` як окрему команду, щоб зберегти режим для поточної сесії.
- Параметри можна комбінувати: `/queue collect debounce:0.5s cap:25 drop:summarize`
+- Параметри можна поєднувати: `/queue collect debounce:0.5s cap:25 drop:summarize`
 - `/queue default` або `/queue reset` очищає перевизначення сесії.

 ## Область дії та гарантії

- Застосовується до запусків агентів автовідповідей у всіх вхідних каналах, що використовують конвеєр відповідей Gateway (веб WhatsApp, Telegram, Slack, Discord, Signal, iMessage, вебчат тощо).
- Типова смуга (`main`) є загальною для процесу для вхідних повідомлень + основних Heartbeat; задайте `agents.defaults.maxConcurrent`, щоб дозволити кілька сесій паралельно.
- Можуть існувати додаткові смуги (наприклад, `cron`, `cron-nested`, `nested`, `subagent`), щоб фонові завдання могли виконуватися паралельно, не блокуючи вхідні відповіді. Ізольовані ходи cron-агента утримують слот `cron`, доки їхнє внутрішнє виконання агента використовує `cron-nested`; обидва використовують `cron.maxConcurrentRuns`. Спільні не-cron потоки `nested` зберігають власну поведінку смуг. Ці відокремлені запуски відстежуються як [фонові завдання](/uk/automation/tasks).
- Смуги для сесії гарантують, що лише один запуск агента торкається певної сесії одночасно.
- Без зовнішніх залежностей або фонових робочих потоків; чистий TypeScript + promises.
+- Застосовується до запусків агентів автовідповідей в усіх вхідних каналах, які використовують конвеєр відповідей Gateway (WhatsApp web, Telegram, Slack, Discord, Signal, iMessage, webchat тощо).
+- Типова смуга (`main`) є процесно-глобальною для вхідних повідомлень + основних heartbeats; задайте `agents.defaults.maxConcurrent`, щоб дозволити кілька сесій паралельно.
+- Можуть існувати додаткові смуги (наприклад, `cron`, `cron-nested`, `nested`, `subagent`), щоб фонові завдання могли виконуватися паралельно, не блокуючи вхідні відповіді. Ізольовані ходи cron-агента утримують слот `cron`, тоді як їхнє внутрішнє виконання агента використовує `cron-nested`; обидва використовують `cron.maxConcurrentRuns`. Спільні non-cron потоки `nested` зберігають власну поведінку смуги. Ці відокремлені запуски відстежуються як [фонові завдання](/uk/automation/tasks).
+- Смуги для сесій гарантують, що лише один запуск агента одночасно працює з певною сесією.
+- Без зовнішніх залежностей або фонових worker threads; лише TypeScript + promises.

 ## Усунення несправностей

- Якщо команди здаються завислими, увімкніть докладні журнали та шукайте рядки “queued for …ms”, щоб підтвердити, що черга обробляється.
- Якщо вам потрібна глибина черги, увімкніть докладні журнали та стежте за рядками часу черги.
- Запуски app-server Codex, які приймають хід, а потім припиняють виводити прогрес, перериваються адаптером Codex, щоб активна смуга сесії могла звільнитися замість очікування тайм-ауту зовнішнього запуску.
- Коли діагностику ввімкнено, сесії, які залишаються в `processing` довше за `diagnostics.stuckSessionWarnMs` без спостережуваної відповіді, інструмента, статусу, блока або прогресу ACP, класифікуються за поточною активністю. Активна робота журналюється як `session.long_running`; активна робота без нещодавнього прогресу журналюється як `session.stalled`; `session.stuck` зарезервовано для застарілого обліку сесій без активної роботи, і лише цей шлях може звільнити відповідну смугу сесії, щоб робота в черзі оброблялася. Повторні діагностичні повідомлення `session.stuck` відступають, поки сесія залишається незмінною.
+- Якщо команди здаються завислими, увімкніть докладні журнали й шукайте рядки “queued for …ms”, щоб підтвердити, що черга обробляється.
+- Якщо потрібна глибина черги, увімкніть докладні журнали й стежте за рядками таймінгу черги.
+- Запуски Codex app-server, які приймають хід, а потім перестають видавати прогрес, перериваються адаптером Codex, щоб активна смуга сесії могла звільнитися замість очікування тайм-ауту зовнішнього запуску.
+- Коли діагностику ввімкнено, сесії, що залишаються в `processing` довше за `diagnostics.stuckSessionWarnMs` без спостереженої відповіді, інструмента, статусу, блока або прогресу ACP, класифікуються за поточною активністю. Активна робота журналюється як `session.long_running`; активна робота без нещодавнього прогресу журналюється як `session.stalled`; `session.stuck` зарезервовано для застарілого обліку сесій без активної роботи, і лише цей шлях може звільнити відповідну смугу сесії, щоб робота в черзі оброблялася. Повторні діагностичні записи `session.stuck` застосовують backoff, доки сесія не змінюється.

 ## Пов’язане

 - [Керування сесіями](/uk/concepts/session)
- [Черга керування](/uk/concepts/queue-steering)
+- [Черга steering](/uk/concepts/queue-steering)
+- [Steer](/uk/tools/steer)
 - [Політика повторних спроб](/uk/concepts/retry)
--- a/docs/uk/tools/slash-commands.md
+++ b/docs/uk/tools/slash-commands.md
@ -6,19 +6,19 @@ sidebarTitle: Slash commands
 summary: 'Слеш-команди: текстові й нативні, конфігурація та підтримувані команди'
 title: Слеш-команди
 x-i18n:
-    generated_at: "2026-05-03T21:42:02Z"
+    generated_at: "2026-05-03T22:25:42Z"
    model: gpt-5.5
    provider: openai
-    source_hash: b95b98f84fd26b706cc38d93935be509033e5df30e00b2f581e326e68b256043
+    source_hash: 49eb41674c8d0a01dbd28a2df783eb9aba3dde18d8425951a266cede825e9a84
    source_path: tools/slash-commands.md
    workflow: 16
 ---

-Команди обробляються Gateway. Більшість команд потрібно надсилати як **окреме** повідомлення, що починається з `/`. Команда bash-чату лише для хоста використовує `! <cmd>` (з `/bash <cmd>` як псевдонімом).
+Команди обробляє Gateway. Більшість команд потрібно надсилати як **окреме** повідомлення, що починається з `/`. Команда bash-чату лише для хоста використовує `! <cmd>` (з `/bash <cmd>` як псевдонімом).

-Коли розмову або потік прив’язано до сесії ACP, звичайний текст подальших відповідей маршрутизується до цієї ACP-обв’язки. Команди керування Gateway усе одно залишаються локальними: `/acp ...` завжди потрапляє до обробника команд OpenClaw ACP, а `/status` і `/unfocus` залишаються локальними, коли для цієї поверхні ввімкнено обробку команд.
+Коли розмова або гілка прив'язана до сесії ACP, звичайний подальший текст спрямовується до цього ACP-інструментарію. Команди керування Gateway усе одно залишаються локальними: `/acp ...` завжди потрапляє до обробника команд OpenClaw ACP, а `/status` і `/unfocus` залишаються локальними щоразу, коли для цієї поверхні ввімкнено обробку команд.

-Є дві пов’язані системи:
+Є дві пов'язані системи:

 <AccordionGroup>
  <Accordion title="Команди">
@ -27,16 +27,16 @@ x-i18n:
  <Accordion title="Директиви">
    `/think`, `/fast`, `/verbose`, `/trace`, `/reasoning`, `/elevated`, `/exec`, `/model`, `/queue`.

-    - Директиви вилучаються з повідомлення до того, як його побачить модель.
+    - Директиви вилучаються з повідомлення до того, як модель його побачить.
    - У звичайних повідомленнях чату (не лише з директивами) вони трактуються як "вбудовані підказки" і **не** зберігають налаштування сесії.
-    - У повідомленнях лише з директивами (повідомлення містить тільки директиви) вони зберігаються в сесії та повертають підтвердження.
-    - Директиви застосовуються лише для **авторизованих відправників**. Якщо задано `commands.allowFrom`, це єдиний список дозволених; інакше авторизація надходить зі списків дозволених/спарювання каналу плюс `commands.useAccessGroups`. Неавторизовані відправники бачать директиви як звичайний текст.
+    - У повідомленнях лише з директивами (повідомлення містить тільки директиви) вони зберігаються в сесії та відповідають підтвердженням.
+    - Директиви застосовуються лише для **авторизованих відправників**. Якщо встановлено `commands.allowFrom`, використовується лише цей список дозволених; інакше авторизація надходить зі списків дозволених каналів/парування плюс `commands.useAccessGroups`. Неавторизовані відправники бачать директиви як звичайний текст.

  </Accordion>
  <Accordion title="Вбудовані скорочення">
-    Лише відправники зі списку дозволених/авторизовані відправники: `/help`, `/commands`, `/status`, `/whoami` (`/id`).
+    Лише відправники зі списку дозволених/авторизовані: `/help`, `/commands`, `/status`, `/whoami` (`/id`).

-    Вони виконуються негайно, вилучаються до того, як модель побачить повідомлення, а решта тексту продовжує проходити звичайним потоком.
+    Вони виконуються негайно, вилучаються до того, як модель побачить повідомлення, а решта тексту продовжує оброблятися звичайним потоком.

  </Accordion>
 </AccordionGroup>
@ -69,170 +69,170 @@ x-i18n:
 ```

 <ParamField path="commands.text" type="boolean" default="true">
-  Вмикає розбір `/...` у повідомленнях чату. На поверхнях без нативних команд (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams) текстові команди й далі працюють, навіть якщо встановити це значення в `false`.
+  Вмикає розбір `/...` у повідомленнях чату. На поверхнях без нативних команд (WhatsApp/WebChat/Signal/iMessage/Google Chat/Microsoft Teams) текстові команди все одно працюють, навіть якщо встановити це значення як `false`.
 </ParamField>
 <ParamField path="commands.native" type='boolean | "auto"' default='"auto"'>
-  Реєструє нативні команди. Авто: увімкнено для Discord/Telegram; вимкнено для Slack (доки ви не додасте slash-команди); ігнорується для провайдерів без нативної підтримки. Встановіть `channels.discord.commands.native`, `channels.telegram.commands.native` або `channels.slack.commands.native`, щоб перевизначити для окремого провайдера (bool або `"auto"`). У Discord `false` пропускає реєстрацію та очищення slash-команд під час запуску; раніше зареєстровані команди можуть залишатися видимими, доки ви не видалите їх із застосунку Discord. Команди Slack керуються в застосунку Slack і не видаляються автоматично.
+  Реєструє нативні команди. Автоматично: увімкнено для Discord/Telegram; вимкнено для Slack (доки ви не додасте slash-команди); ігнорується для провайдерів без нативної підтримки. Установіть `channels.discord.commands.native`, `channels.telegram.commands.native` або `channels.slack.commands.native`, щоб перевизначити для окремого провайдера (bool або `"auto"`). У Discord `false` пропускає реєстрацію та очищення slash-команд під час запуску; раніше зареєстровані команди можуть залишатися видимими, доки ви не видалите їх із застосунку Discord. Командами Slack керують у застосунку Slack, і вони не видаляються автоматично.
 </ParamField>
 У Discord специфікації нативних команд можуть містити `descriptionLocalizations`, які OpenClaw публікує як Discord `description_localizations` і включає в порівняння узгодження.
 <ParamField path="commands.nativeSkills" type='boolean | "auto"' default='"auto"'>
-  Реєструє команди **Skills** нативно, коли це підтримується. Авто: увімкнено для Discord/Telegram; вимкнено для Slack (Slack вимагає створення slash-команди для кожної Skills). Встановіть `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` або `channels.slack.commands.nativeSkills`, щоб перевизначити для окремого провайдера (bool або `"auto"`).
+  Реєструє команди **skill** нативно, коли це підтримується. Автоматично: увімкнено для Discord/Telegram; вимкнено для Slack (Slack вимагає створення slash-команди для кожної навички). Установіть `channels.discord.commands.nativeSkills`, `channels.telegram.commands.nativeSkills` або `channels.slack.commands.nativeSkills`, щоб перевизначити для окремого провайдера (bool або `"auto"`).
 </ParamField>
 <ParamField path="commands.bash" type="boolean" default="false">
  Вмикає `! <cmd>` для запуску команд оболонки хоста (`/bash <cmd>` є псевдонімом; потребує списків дозволених `tools.elevated`).
 </ParamField>
 <ParamField path="commands.bashForegroundMs" type="number" default="2000">
-  Керує тим, як довго bash очікує перед перемиканням у фоновий режим (`0` одразу переводить у фон).
+  Керує тим, як довго bash чекає перед переходом у фоновий режим (`0` одразу переводить у фон).
 </ParamField>
 <ParamField path="commands.config" type="boolean" default="false">
  Вмикає `/config` (читає/записує `openclaw.json`).
 </ParamField>
 <ParamField path="commands.mcp" type="boolean" default="false">
-  Вмикає `/mcp` (читає/записує керовану OpenClaw конфігурацію MCP у `mcp.servers`).
+  Вмикає `/mcp` (читає/записує MCP-конфігурацію, керовану OpenClaw, у `mcp.servers`).
 </ParamField>
 <ParamField path="commands.plugins" type="boolean" default="false">
-  Вмикає `/plugins` (виявлення/стан plugin плюс елементи керування встановленням і ввімкненням/вимкненням).
+  Вмикає `/plugins` (виявлення/стан плагінів, а також встановлення та елементи керування ввімкненням/вимкненням).
 </ParamField>
 <ParamField path="commands.debug" type="boolean" default="false">
  Вмикає `/debug` (перевизначення лише під час виконання).
 </ParamField>
 <ParamField path="commands.restart" type="boolean" default="true">
-  Вмикає `/restart` плюс дії інструментів перезапуску gateway.
+  Вмикає `/restart` плюс дії інструментів перезапуску Gateway.
 </ParamField>
 <ParamField path="commands.ownerAllowFrom" type="string[]">
-  Задає явний список дозволених власників для поверхонь команд/інструментів лише для власника. Це обліковий запис оператора-людини, який може схвалювати небезпечні дії та виконувати команди на кшталт `/diagnostics`, `/export-trajectory` і `/config`. Він відокремлений від `commands.allowFrom` і від доступу через спарювання DM.
+  Задає явний список дозволених власників для командних/інструментальних поверхонь лише для власника. Це обліковий запис оператора-людини, який може схвалювати небезпечні дії та запускати команди на кшталт `/diagnostics`, `/export-trajectory` і `/config`. Він окремий від `commands.allowFrom` і доступу через парування DM.
 </ParamField>
 <ParamField path="channels.<channel>.commands.enforceOwnerForCommands" type="boolean" default="false">
-  Для кожного каналу: змушує команди лише для власника вимагати **ідентичність власника** для запуску на цій поверхні. Коли `true`, відправник має або відповідати розв’язаному кандидату-власнику (наприклад, запису в `commands.ownerAllowFrom` або нативним метаданим власника провайдера), або мати внутрішню область `operator.admin` у внутрішньому каналі повідомлень. Запис із wildcard у `allowFrom` каналу або порожній/нерозв’язаний список кандидатів-власників **не** є достатнім — команди лише для власника на цьому каналі закриваються за замовчуванням. Залиште це вимкненим, якщо хочете, щоб команди лише для власника обмежувалися тільки `ownerAllowFrom` і стандартними списками дозволених команд.
+  Для кожного каналу: змушує команди лише для власника вимагати **ідентичність власника** для запуску на цій поверхні. Коли `true`, відправник має або збігатися з визначеним кандидатом-власником (наприклад, записом у `commands.ownerAllowFrom` або нативними метаданими власника від провайдера), або мати внутрішній scope `operator.admin` у внутрішньому каналі повідомлень. Запис із wildcard у `allowFrom` каналу або порожній/невизначений список кандидатів-власників **не** достатній — команди лише для власника на цьому каналі завершуються закритою відмовою. Залиште це вимкненим, якщо хочете, щоб команди лише для власника обмежувалися тільки `ownerAllowFrom` і стандартними списками дозволених команд.
 </ParamField>
 <ParamField path="commands.ownerDisplay" type='"raw" | "hash"'>
-  Керує тим, як ідентифікатори власників з’являються в системному промпті.
+  Керує тим, як ідентифікатори власника відображаються в системному prompt.
 </ParamField>
 <ParamField path="commands.ownerDisplaySecret" type="string">
-  Необов’язково задає секрет HMAC, що використовується, коли `commands.ownerDisplay="hash"`.
+  За потреби задає секрет HMAC, що використовується, коли `commands.ownerDisplay="hash"`.
 </ParamField>
 <ParamField path="commands.allowFrom" type="object">
-  Список дозволених для авторизації команд за провайдерами. Коли налаштовано, це єдине джерело авторизації для команд і директив (списки дозволених/спарювання каналів і `commands.useAccessGroups` ігноруються). Використовуйте `"*"` для глобального типового значення; ключі конкретних провайдерів перевизначають його.
+  Список дозволених для авторизації команд за провайдерами. Коли налаштовано, це єдине джерело авторизації для команд і директив (списки дозволених каналів/парування та `commands.useAccessGroups` ігноруються). Використовуйте `"*"` для глобального типового значення; ключі конкретних провайдерів його перевизначають.
 </ParamField>
 <ParamField path="commands.useAccessGroups" type="boolean" default="true">
-  Застосовує списки дозволених/політики для команд, коли `commands.allowFrom` не задано.
+  Застосовує списки дозволених/політики для команд, коли `commands.allowFrom` не встановлено.
 </ParamField>

 ## Список команд

 Поточне джерело істини:

- вбудовані команди ядра надходять із `src/auto-reply/commands-registry.shared.ts`
+- базові вбудовані команди надходять із `src/auto-reply/commands-registry.shared.ts`
 - згенеровані dock-команди надходять із `src/auto-reply/commands-registry.data.ts`
- команди plugin надходять із викликів plugin `registerCommand()`
- фактична доступність на вашому gateway усе одно залежить від прапорців конфігурації, поверхні каналу та встановлених/увімкнених plugin
+- команди плагінів надходять із викликів `registerCommand()` плагінів
+- фактична доступність на вашому gateway усе одно залежить від прапорців конфігурації, поверхні каналу та встановлених/увімкнених плагінів

-### Вбудовані команди ядра
+### Базові вбудовані команди

 <AccordionGroup>
  <Accordion title="Сесії та запуски">
    - `/new [model]` запускає нову сесію; `/reset` є псевдонімом скидання.
-    - Control UI перехоплює введене `/new`, щоб створити й перемкнутися на свіжу сесію dashboard; введене `/reset` і далі виконує скидання Gateway на місці.
-    - `/reset soft [message]` зберігає поточний transcript, відкидає повторно використані ідентифікатори сесій backend CLI і повторно запускає завантаження startup/system-prompt на місці.
+    - Control UI перехоплює введене `/new`, щоб створити й перемкнутися на свіжу сесію dashboard; введене `/reset` усе ще виконує скидання Gateway на місці.
+    - `/reset soft [message]` зберігає поточну стенограму, відкидає повторно використані ідентифікатори сесій бекенду CLI та повторно виконує завантаження запуску/системного prompt на місці.
    - `/compact [instructions]` стискає контекст сесії. Див. [Compaction](/uk/concepts/compaction).
    - `/stop` перериває поточний запуск.
-    - `/session idle <duration|off>` і `/session max-age <duration|off>` керують завершенням терміну дії прив’язки потоку.
+    - `/session idle <duration|off>` і `/session max-age <duration|off>` керують завершенням прив'язки гілки.
    - `/export-session [path]` експортує поточну сесію в HTML. Псевдонім: `/export`.
-    - `/export-trajectory [path]` запитує схвалення exec, а потім експортує JSONL [пакет траєкторії](/uk/tools/trajectory) для поточної сесії. Використовуйте це, коли потрібна хронологія prompt, інструментів і transcript для однієї сесії OpenClaw. У групових чатах prompt схвалення та результат експорту надсилаються власнику приватно. Псевдонім: `/trajectory`.
+    - `/export-trajectory [path]` запитує схвалення exec, а потім експортує JSONL [пакет trajectory](/uk/tools/trajectory) для поточної сесії. Використовуйте це, коли потрібна часова шкала prompt, інструментів і стенограми для однієї сесії OpenClaw. У групових чатах запит на схвалення та результат експорту надсилаються власнику приватно. Псевдонім: `/trajectory`.

  </Accordion>
-  <Accordion title="Модель і керування запуском">
-    - `/think <level>` задає рівень thinking. Варіанти надходять із профілю провайдера активної моделі; поширені рівні: `off`, `minimal`, `low`, `medium` і `high`, із власними рівнями на кшталт `xhigh`, `adaptive`, `max` або бінарним `on` лише там, де підтримується. Псевдоніми: `/thinking`, `/t`.
+  <Accordion title="Елементи керування моделлю та запуском">
+    - `/think <level>` задає рівень мислення. Варіанти надходять із профілю провайдера активної моделі; поширені рівні: `off`, `minimal`, `low`, `medium` і `high`, а користувацькі рівні, як-от `xhigh`, `adaptive`, `max`, або бінарне `on`, доступні лише там, де підтримуються. Псевдоніми: `/thinking`, `/t`.
    - `/verbose on|off|full` перемикає докладний вивід. Псевдонім: `/v`.
-    - `/trace on|off` перемикає вивід trace plugin для поточної сесії.
+    - `/trace on|off` перемикає trace-вивід плагінів для поточної сесії.
    - `/fast [status|on|off]` показує або задає швидкий режим.
    - `/reasoning [on|off|stream]` перемикає видимість reasoning. Псевдонім: `/reason`.
-    - `/elevated [on|off|ask|full]` перемикає elevated-режим. Псевдонім: `/elev`.
+    - `/elevated [on|off|ask|full]` перемикає elevated mode. Псевдонім: `/elev`.
    - `/exec host=<auto|sandbox|gateway|node> security=<deny|allowlist|full> ask=<off|on-miss|always> node=<id>` показує або задає типові значення exec.
    - `/model [name|#|status]` показує або задає модель.
-    - `/models [provider] [page] [limit=<n>|size=<n>|all]` перелічує налаштованих/доступних через auth провайдерів або моделі для провайдера; додайте `all`, щоб переглянути повний catalog цього провайдера.
-    - `/queue <mode>` керує поведінкою черги (`steer`, legacy `queue`, `followup`, `collect`, `steer-backlog`, `interrupt`) плюс параметри на кшталт `debounce:0.5s cap:25 drop:summarize`; `/queue default` або `/queue reset` очищає перевизначення сесії. Див. [Черга команд](/uk/concepts/queue) і [Steering-черга](/uk/concepts/queue-steering).
-    - `/steer <message>` вводить guidance в активний запуск для поточної сесії, незалежно від режиму `/queue`. Вона не запускає новий запуск, коли сесія idle. Псевдонім: `/tell`.
+    - `/models [provider] [page] [limit=<n>|size=<n>|all]` перелічує налаштованих/доступних за автентифікацією провайдерів або моделі для провайдера; додайте `all`, щоб переглянути повний каталог цього провайдера.
+    - `/queue <mode>` керує поведінкою черги (`steer`, застаріле `queue`, `followup`, `collect`, `steer-backlog`, `interrupt`) плюс параметрами на кшталт `debounce:0.5s cap:25 drop:summarize`; `/queue default` або `/queue reset` очищає перевизначення сесії. Див. [Черга команд](/uk/concepts/queue) і [Черга steering](/uk/concepts/queue-steering).
+    - `/steer <message>` вставляє вказівки в активний запуск для поточної сесії незалежно від режиму `/queue`. Це не запускає новий запуск, коли сесія неактивна. Псевдонім: `/tell`. Див. [Steer](/uk/tools/steer).

  </Accordion>
  <Accordion title="Виявлення та стан">
-    - `/help` показує короткий підсумок довідки.
-    - `/commands` показує згенерований catalog команд.
-    - `/tools [compact|verbose]` показує, що поточний агент може використовувати саме зараз.
-    - `/status` показує стан виконання/середовища виконання, включно з мітками `Execution`/`Runtime` і використанням/квотою провайдера, коли доступно.
-    - `/diagnostics [note]` — це потік звіту підтримки лише для власника для помилок Gateway і запусків обв’язки Codex. Він щоразу запитує явне схвалення exec перед запуском `openclaw gateway diagnostics export --json`; не схвалюйте diagnostics правилом allow-all. Після схвалення він надсилає звіт, який можна вставити, з локальним шляхом bundle, підсумком manifest, примітками щодо приватності та відповідними ідентифікаторами сесій. У групових чатах prompt схвалення та звіт надсилаються власнику приватно. Коли активна сесія використовує обв’язку OpenAI Codex, те саме схвалення також надсилає релевантний відгук Codex на сервери OpenAI, а завершена відповідь перелічує ідентифікатори сесій OpenClaw, ідентифікатори потоків Codex і команди `codex resume <thread-id>`. Див. [Експорт diagnostics](/uk/gateway/diagnostics).
-    - `/crestodian <request>` запускає помічник налаштування й ремонту Crestodian з DM власника.
+    - `/help` показує коротке довідкове зведення.
+    - `/commands` показує згенерований каталог команд.
+    - `/tools [compact|verbose]` показує, що поточний агент може використовувати просто зараз.
+    - `/status` показує стан виконання/середовища виконання, зокрема мітки `Execution`/`Runtime` і використання/квоту провайдера, коли доступно.
+    - `/diagnostics [note]` — це потік звіту підтримки лише для власника для помилок Gateway і запусків Codex harness. Він щоразу запитує явне схвалення exec перед запуском `openclaw gateway diagnostics export --json`; не схвалюйте діагностику правилом allow-all. Після схвалення він надсилає звіт, придатний для вставлення, з локальним шляхом пакета, зведенням маніфесту, примітками щодо приватності та відповідними ідентифікаторами сесій. У групових чатах запит на схвалення та звіт надсилаються власнику приватно. Коли активна сесія використовує OpenAI Codex harness, те саме схвалення також надсилає релевантний відгук Codex на сервери OpenAI, а завершена відповідь перелічує ідентифікатори сесій OpenClaw, ідентифікатори гілок Codex і команди `codex resume <thread-id>`. Див. [Експорт діагностики](/uk/gateway/diagnostics).
+    - `/crestodian <request>` запускає помічник налаштування та ремонту Crestodian із DM власника.
    - `/tasks` перелічує активні/нещодавні фонові завдання для поточної сесії.
    - `/context [list|detail|json]` пояснює, як збирається контекст.
-    - `/whoami` показує ваш sender id. Псевдонім: `/id`.
-    - `/usage off|tokens|full|cost` керує footer використання для кожної відповіді або друкує локальний підсумок cost.
+    - `/whoami` показує ваш ідентифікатор відправника. Псевдонім: `/id`.
+    - `/usage off|tokens|full|cost` керує нижнім колонтитулом використання для кожної відповіді або друкує локальне зведення вартості.

  </Accordion>
  <Accordion title="Skills, списки дозволених, схвалення">
-    - `/skill <name> [input]` запускає Skills за назвою.
+    - `/skill <name> [input]` запускає skill за назвою.
    - `/allowlist [list|add|remove] ...` керує записами списку дозволених. Лише текст.
-    - `/approve <id> <decision>` вирішує prompts схвалення exec.
+    - `/approve <id> <decision>` вирішує запити на схвалення exec.
    - `/btw <question>` ставить побічне запитання без зміни майбутнього контексту сесії. Псевдонім: `/side`. Див. [BTW](/uk/tools/btw).

  </Accordion>
  <Accordion title="Субагенти та ACP">
    - `/subagents list|kill|log|info|send|steer|spawn` керує запусками субагентів для поточного сеансу.
    - `/acp spawn|cancel|steer|close|sessions|status|set-mode|set|cwd|permissions|timeout|model|reset-options|doctor|install|help` керує сеансами ACP і параметрами середовища виконання.
-    - `/focus <target>` прив’язує поточний потік Discord або тему/розмову Telegram до цілі сеансу.
+    - `/focus <target>` прив’язує поточний потік Discord або тему/розмову Telegram до цільового сеансу.
    - `/unfocus` видаляє поточну прив’язку.
-    - `/agents` виводить агентів, прив’язаних до потоку, для поточного сеансу.
-    - `/kill <id|#|all>` перериває одного або всіх запущених субагентів.
-    - `/subagents steer <id|#> <message>` надсилає керування запущеному субагенту.
+    - `/agents` показує агентів, прив’язаних до потоку, для поточного сеансу.
+    - `/kill <id|#|all>` перериває один або всі запущені субагенти.
+    - `/subagents steer <id|#> <message>` надсилає керування запущеному субагенту. Див. [Керування](/uk/tools/steer).

  </Accordion>
-  <Accordion title="Запис лише для власника та адміністрування">
-    - `/config show|get|set|unset` читає або записує `openclaw.json`. Лише для власника. Потрібно `commands.config: true`.
-    - `/mcp show|get|set|unset` читає або записує конфігурацію сервера MCP, якою керує OpenClaw, у `mcp.servers`. Лише для власника. Потрібно `commands.mcp: true`.
-    - `/plugins list|inspect|show|get|install|enable|disable` перевіряє або змінює стан plugin. `/plugin` є псевдонімом. Запис лише для власника. Потрібно `commands.plugins: true`.
-    - `/debug show|set|unset|reset` керує перевизначеннями конфігурації лише для середовища виконання. Лише для власника. Потрібно `commands.debug: true`.
-    - `/restart` перезапускає OpenClaw, коли ввімкнено. Типово: ввімкнено; задайте `commands.restart: false`, щоб вимкнути.
+  <Accordion title="Записи лише для власника та адміністрування">
+    - `/config show|get|set|unset` читає або записує `openclaw.json`. Лише для власника. Потребує `commands.config: true`.
+    - `/mcp show|get|set|unset` читає або записує конфігурацію MCP-сервера, керовану OpenClaw, у `mcp.servers`. Лише для власника. Потребує `commands.mcp: true`.
+    - `/plugins list|inspect|show|get|install|enable|disable` перевіряє або змінює стан plugin. `/plugin` є псевдонімом. Запис лише для власника. Потребує `commands.plugins: true`.
+    - `/debug show|set|unset|reset` керує перевизначеннями конфігурації лише для середовища виконання. Лише для власника. Потребує `commands.debug: true`.
+    - `/restart` перезапускає OpenClaw, коли це ввімкнено. Типово: увімкнено; задайте `commands.restart: false`, щоб вимкнути.
    - `/send on|off|inherit` задає політику надсилання. Лише для власника.

  </Accordion>
  <Accordion title="Голос, TTS, керування каналом">
    - `/tts on|off|status|chat|latest|provider|limit|summary|audio|help` керує TTS. Див. [TTS](/uk/tools/tts).
    - `/activation mention|always` задає режим активації групи.
-    - `/bash <command>` запускає команду оболонки хоста. Лише текст. Псевдонім: `! <command>`. Потрібно `commands.bash: true` плюс allowlists `tools.elevated`.
+    - `/bash <command>` виконує команду оболонки хоста. Лише текст. Псевдонім: `! <command>`. Потребує `commands.bash: true` плюс списки дозволів `tools.elevated`.
    - `!poll [sessionId]` перевіряє фонове завдання bash.
    - `!stop [sessionId]` зупиняє фонове завдання bash.

  </Accordion>
 </AccordionGroup>

-### Згенеровані команди закріплення
+### Згенеровані команди стикування

-Команди закріплення перемикають маршрут відповіді поточного сеансу на інший пов’язаний
-канал. Див. [Закріплення каналів](/uk/concepts/channel-docking) для налаштування,
-прикладів і усунення несправностей.
+Команди стикування перемикають маршрут відповіді поточного сеансу на інший пов’язаний
+канал. Див. [Стикування каналів](/uk/concepts/channel-docking), щоб дізнатися про налаштування,
+приклади та усунення несправностей.

-Команди закріплення генеруються з plugin каналів із підтримкою нативних команд. Поточний вбудований набір:
+Команди стикування генеруються з plugin каналів із підтримкою нативних команд. Поточний вбудований набір:

 - `/dock-discord` (псевдонім: `/dock_discord`)
 - `/dock-mattermost` (псевдонім: `/dock_mattermost`)
 - `/dock-slack` (псевдонім: `/dock_slack`)
 - `/dock-telegram` (псевдонім: `/dock_telegram`)

-Використовуйте команди закріплення з прямого чату, щоб перемкнути маршрут відповіді поточного сеансу на інший пов’язаний канал. Агент зберігає той самий контекст сеансу, але майбутні відповіді для цього сеансу доставляються вибраному учаснику каналу.
+Використовуйте команди стикування з прямого чату, щоб перемкнути маршрут відповіді поточного сеансу на інший пов’язаний канал. Агент зберігає той самий контекст сеансу, але майбутні відповіді для цього сеансу доставляються вибраному учаснику каналу.

-Команди закріплення потребують `session.identityLinks`. Відправник-джерело та цільовий учасник мають бути в одній групі ідентичностей, наприклад `["telegram:123", "discord:456"]`. Якщо користувач Telegram з id `123` надсилає `/dock_discord`, OpenClaw зберігає `lastChannel: "discord"` і `lastTo: "456"` в активному сеансі. Якщо відправника не пов’язано з учасником Discord, команда відповідає підказкою з налаштування замість переходу до звичайного чату.
+Команди стикування потребують `session.identityLinks`. Відправник джерела і цільовий учасник мають бути в одній групі ідентичностей, наприклад `["telegram:123", "discord:456"]`. Якщо користувач Telegram з id `123` надсилає `/dock_discord`, OpenClaw зберігає `lastChannel: "discord"` і `lastTo: "456"` в активному сеансі. Якщо відправника не пов’язано з учасником Discord, команда відповідає підказкою щодо налаштування замість переходу до звичайного чату.

-Закріплення змінює лише маршрут активного сеансу. Воно не створює облікові записи каналів, не надає доступ, не обходить allowlists каналів і не переносить історію транскрипту до іншого сеансу. Використовуйте `/dock-telegram`, `/dock-slack`, `/dock-mattermost` або іншу згенеровану команду закріплення, щоб знову перемкнути маршрут.
+Стикування змінює лише маршрут активного сеансу. Воно не створює облікові записи каналів, не надає доступ, не обходить списки дозволів каналів і не переносить історію транскрипту в інший сеанс. Використовуйте `/dock-telegram`, `/dock-slack`, `/dock-mattermost` або іншу згенеровану команду стикування, щоб знову перемкнути маршрут.

 ### Команди вбудованих plugin

 Вбудовані plugins можуть додавати більше slash-команд. Поточні вбудовані команди в цьому репозиторії:

- `/dreaming [on|off|status|help]` перемикає dreaming пам’яті. Див. [Dreaming](/uk/concepts/dreaming).
+- `/dreaming [on|off|status|help]` вмикає або вимикає Dreaming пам’яті. Див. [Dreaming](/uk/concepts/dreaming).
 - `/pair [qr|status|pending|approve|cleanup|notify]` керує потоком сполучення/налаштування пристрою. Див. [Сполучення](/uk/channels/pairing).
 - `/phone status|arm <camera|screen|writes|all> [duration]|disarm` тимчасово активує високоризикові команди телефонного вузла.
- `/voice status|list [limit]|set <voiceId|name>` керує конфігурацією голосу Talk. У Discord назва нативної команди — `/talkvoice`.
- `/card ...` надсилає пресети насичених карток LINE. Див. [LINE](/uk/channels/line).
- `/codex status|models|threads|resume|compact|review|diagnostics|account|mcp|skills` перевіряє та керує вбудованим app-server harness Codex. Див. [Harness Codex](/uk/plugins/codex-harness).
+- `/voice status|list [limit]|set <voiceId|name>` керує конфігурацією голосу Talk. У Discord нативна назва команди — `/talkvoice`.
+- `/card ...` надсилає пресети розширених карток LINE. Див. [LINE](/uk/channels/line).
+- `/codex status|models|threads|resume|compact|review|diagnostics|account|mcp|skills` перевіряє та керує вбудованим серверним каркасом застосунку Codex. Див. [Каркас Codex](/uk/plugins/codex-harness).
 - Команди лише для QQBot:
  - `/bot-ping`
  - `/bot-version`
@ -246,88 +246,88 @@ Skills, які може викликати користувач, також до

 - `/skill <name> [input]` завжди працює як універсальна точка входу.
 - skills також можуть з’являтися як прямі команди, наприклад `/prose`, коли skill/plugin їх реєструє.
- реєстрація нативних команд skills керується `commands.nativeSkills` і `channels.<provider>.commands.nativeSkills`.
- специфікації команд можуть надавати `descriptionLocalizations` для нативних поверхонь, які підтримують локалізовані описи, зокрема Discord.
+- реєстрація нативних команд skills контролюється `commands.nativeSkills` і `channels.<provider>.commands.nativeSkills`.
+- специфікації команд можуть надавати `descriptionLocalizations` для нативних поверхонь, що підтримують локалізовані описи, зокрема Discord.

 <AccordionGroup>
-  <Accordion title="Примітки щодо аргументів і парсера">
+  <Accordion title="Нотатки щодо аргументів і парсера">
    - Команди приймають необов’язковий `:` між командою та аргументами (наприклад, `/think: high`, `/send: on`, `/help:`).
    - `/new <model>` приймає псевдонім моделі, `provider/model` або назву провайдера (нечіткий збіг); якщо збігу немає, текст обробляється як тіло повідомлення.
-    - Для повного розподілу використання провайдера застосовуйте `openclaw status --usage`.
+    - Для повного розбору використання провайдера використовуйте `openclaw status --usage`.
    - `/allowlist add|remove` потребує `commands.config=true` і враховує `configWrites` каналу.
-    - У багатооблікових каналах `/allowlist --account <id>`, націлений на конфігурацію, і `/config set channels.<provider>.accounts.<id>...` також враховують `configWrites` цільового облікового запису.
-    - `/usage` керує нижнім колонтитулом використання для кожної відповіді; `/usage cost` друкує локальний підсумок вартості з журналів сеансів OpenClaw.
+    - У багатооблікових каналах `/allowlist --account <id>` для цільової конфігурації та `/config set channels.<provider>.accounts.<id>...` також враховують `configWrites` цільового облікового запису.
+    - `/usage` керує футером використання для кожної відповіді; `/usage cost` друкує локальний підсумок витрат із журналів сеансів OpenClaw.
    - `/restart` увімкнено типово; задайте `commands.restart: false`, щоб вимкнути.
    - `/plugins install <spec>` приймає ті самі специфікації plugin, що й `openclaw plugins install`: локальний шлях/архів, npm-пакет, `git:<repo>` або `clawhub:<pkg>`, а потім запитує перезапуск Gateway, оскільки вихідні модулі plugin змінилися.
    - `/plugins enable|disable` оновлює конфігурацію plugin і запускає перезавантаження plugin Gateway для нових ходів агента.

  </Accordion>
-  <Accordion title="Поведінка, специфічна для каналів">
-    - Нативна команда лише для Discord: `/vc join|leave|status` керує голосовими каналами (недоступна як текст). `join` потребує guild і вибраного voice/stage channel. Потрібні `channels.discord.voice` і нативні команди.
+  <Accordion title="Поведінка, специфічна для каналу">
+    - Нативна команда лише для Discord: `/vc join|leave|status` керує голосовими каналами (недоступна як текст). `join` потребує гільдії та вибраного голосового/сценічного каналу. Потребує `channels.discord.voice` і нативних команд.
    - Команди прив’язки потоків Discord (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) потребують увімкнених ефективних прив’язок потоків (`session.threadBindings.enabled` та/або `channels.discord.threadBindings.enabled`).
-    - Довідник команд ACP і поведінка середовища виконання: [Агенти ACP](/uk/tools/acp-agents).
+    - Довідник команд ACP і поведінка середовища виконання: [агенти ACP](/uk/tools/acp-agents).

  </Accordion>
  <Accordion title="Безпека verbose / trace / fast / reasoning">
-    - `/verbose` призначено для налагодження та додаткової видимості; у звичайному використанні тримайте його **вимкненим**.
-    - `/trace` вужчий за `/verbose`: він показує лише рядки trace/debug, що належать plugin, і залишає звичайний verbose-шум інструментів вимкненим.
-    - `/fast on|off` зберігає перевизначення сеансу. Використовуйте опцію `inherit` в UI Sessions, щоб очистити його й повернутися до типових значень конфігурації.
-    - `/fast` залежить від провайдера: OpenAI/OpenAI Codex зіставляють його з `service_tier=priority` на нативних Responses endpoints, тоді як прямі публічні запити Anthropic, зокрема трафік, автентифікований через OAuth і надісланий до `api.anthropic.com`, зіставляють його з `service_tier=auto` або `standard_only`. Див. [OpenAI](/uk/providers/openai) і [Anthropic](/uk/providers/anthropic).
-    - Підсумки збоїв інструментів усе ще показуються, коли це доречно, але детальний текст збою включається лише коли `/verbose` має значення `on` або `full`.
-    - `/reasoning`, `/verbose` і `/trace` ризиковані в групових налаштуваннях: вони можуть розкрити внутрішні міркування, вивід інструментів або діагностику plugin, які ви не мали наміру показувати. Краще залишати їх вимкненими, особливо в групових чатах.
+    - `/verbose` призначено для налагодження та додаткової видимості; тримайте його **вимкненим** під час звичайного використання.
+    - `/trace` вужчий за `/verbose`: він показує лише рядки трасування/налагодження, що належать plugin, і залишає звичайний докладний шум інструментів вимкненим.
+    - `/fast on|off` зберігає перевизначення сеансу. Використовуйте опцію `inherit` в UI сеансів, щоб очистити її та повернутися до типових значень конфігурації.
+    - `/fast` залежить від провайдера: OpenAI/OpenAI Codex відображають його на `service_tier=priority` у нативних кінцевих точках Responses, тоді як прямі публічні запити Anthropic, зокрема трафік, автентифікований через OAuth і надісланий до `api.anthropic.com`, відображають його на `service_tier=auto` або `standard_only`. Див. [OpenAI](/uk/providers/openai) і [Anthropic](/uk/providers/anthropic).
+    - Підсумки збоїв інструментів усе ще показуються, коли це доречно, але докладний текст збою включається лише коли `/verbose` має значення `on` або `full`.
+    - `/reasoning`, `/verbose` і `/trace` ризиковані в групових налаштуваннях: вони можуть розкрити внутрішнє міркування, вивід інструментів або діагностику plugin, які ви не мали наміру показувати. Краще залишати їх вимкненими, особливо в групових чатах.

  </Accordion>
  <Accordion title="Перемикання моделі">
-    - `/model` негайно зберігає нову модель сеансу.
-    - Якщо агент простоює, наступний запуск використовує її відразу.
-    - Якщо запуск уже активний, OpenClaw позначає live-перемикання як очікуване й перезапускає нову модель лише в чистій точці повторної спроби.
-    - Якщо активність інструментів або вивід відповіді вже почалися, очікуване перемикання може залишатися в черзі до пізнішої можливості повторної спроби або наступного ходу користувача.
-    - У локальному TUI `/crestodian [request]` повертає зі звичайного TUI агента до Crestodian. Це окремо від режиму порятунку каналу повідомлень і не надає віддалених повноважень конфігурації.
+    - `/model` одразу зберігає нову модель сеансу.
+    - Якщо агент бездіяльний, наступний запуск використовує її відразу.
+    - Якщо запуск уже активний, OpenClaw позначає живе перемикання як очікуване й перезапускає в новій моделі лише в чистій точці повторної спроби.
+    - Якщо активність інструментів або вивід відповіді вже почалися, очікуване перемикання може залишатися в черзі до пізнішої можливості повторної спроби або до наступного ходу користувача.
+    - У локальному TUI `/crestodian [request]` повертає зі звичайного TUI агента до Crestodian. Це окремо від режиму порятунку каналу повідомлень і не надає віддалені повноваження конфігурації.

  </Accordion>
  <Accordion title="Швидкий шлях і вбудовані скорочення">
-    - **Швидкий шлях:** повідомлення лише з командами від відправників з allowlist обробляються негайно (обхід черги + моделі).
-    - **Фільтрація згадок у групах:** повідомлення лише з командами від відправників з allowlist обходять вимоги щодо згадок.
-    - **Вбудовані скорочення (лише відправники з allowlist):** певні команди також працюють, коли вбудовані у звичайне повідомлення, і вилучаються до того, як модель побачить решту тексту.
-      - Приклад: `hey /status` запускає відповідь зі статусом, а решта тексту продовжує звичайний потік.
+    - **Швидкий шлях:** повідомлення лише з командами від відправників зі списку дозволів обробляються негайно (обхід черги + моделі).
+    - **Обмеження згадками в групі:** повідомлення лише з командами від відправників зі списку дозволів обходять вимоги згадування.
+    - **Вбудовані скорочення (лише відправники зі списку дозволів):** деякі команди також працюють, коли вбудовані у звичайне повідомлення, і видаляються перед тим, як модель побачить решту тексту.
+      - Приклад: `hey /status` запускає відповідь зі статусом, а решта тексту продовжує проходити звичайним потоком.
    - Наразі: `/help`, `/commands`, `/status`, `/whoami` (`/id`).
    - Несанкціоновані повідомлення лише з командами мовчки ігноруються, а вбудовані токени `/...` обробляються як звичайний текст.

  </Accordion>
  <Accordion title="Команди Skills і нативні аргументи">
-    - **Команди Skills:** skills `user-invocable` доступні як slash-команди. Назви санітизуються до `a-z0-9_` (макс. 32 символи); колізії отримують числові суфікси (наприклад, `_2`).
+    - **Команди Skills:** skills `user-invocable` доступні як slash-команди. Назви очищуються до `a-z0-9_` (макс. 32 символи); колізії отримують числові суфікси (наприклад, `_2`).
      - `/skill <name> [input]` запускає skill за назвою (корисно, коли обмеження нативних команд не дозволяють окремі команди для кожного skill).
-      - Типово команди skills пересилаються до моделі як звичайний запит.
-      - Skills можуть необов’язково оголошувати `command-dispatch: tool`, щоб маршрутизувати команду безпосередньо до інструмента (детерміновано, без моделі).
+      - Типово команди skills переспрямовуються до моделі як звичайний запит.
+      - Skills можуть необов’язково оголошувати `command-dispatch: tool`, щоб маршрутизувати команду напряму до інструмента (детерміновано, без моделі).
      - Приклад: `/prose` (plugin OpenProse) — див. [OpenProse](/uk/prose).
-    - **Аргументи нативних команд:** Discord використовує автодоповнення для динамічних опцій (і меню кнопок, коли ви пропускаєте обов’язкові аргументи). Telegram і Slack показують меню кнопок, коли команда підтримує варіанти вибору, а ви пропускаєте аргумент. Динамічні варіанти обчислюються відносно цільової моделі сеансу, тому специфічні для моделі опції, як-от рівні `/think`, дотримуються перевизначення `/model` цього сеансу.
+    - **Аргументи нативних команд:** Discord використовує автодоповнення для динамічних опцій (і меню кнопок, коли ви пропускаєте обов’язкові аргументи). Telegram і Slack показують меню кнопок, коли команда підтримує варіанти вибору, а ви пропускаєте аргумент. Динамічні варіанти визначаються відносно цільової моделі сеансу, тому специфічні для моделі опції, як-от рівні `/think`, слідують перевизначенню `/model` цього сеансу.

  </Accordion>
 </AccordionGroup>

 ## `/tools`

-`/tools` відповідає на питання про середовище виконання, а не про конфігурацію: **що цей агент може використовувати прямо зараз у цій розмові**.
+`/tools` відповідає на запитання про середовище виконання, а не про конфігурацію: **що цей агент може використовувати прямо зараз у цій розмові**.

 - Типовий `/tools` компактний і оптимізований для швидкого перегляду.
 - `/tools verbose` додає короткі описи.
- Поверхні нативних команд, що підтримують аргументи, надають той самий перемикач режиму `compact|verbose`.
- Результати прив’язані до сеансу, тому зміна агента, каналу, потоку, авторизації відправника або моделі може змінити вивід.
- `/tools` включає інструменти, які фактично доступні під час виконання, зокрема основні інструменти, підключені інструменти plugin та інструменти, що належать каналу.
+- Поверхні нативних команд, які підтримують аргументи, надають той самий перемикач режиму `compact|verbose`.
+- Результати обмежені сеансом, тому зміна агента, каналу, потоку, авторизації відправника або моделі може змінити вивід.
+- `/tools` включає інструменти, які фактично доступні під час виконання, зокрема основні інструменти, підключені інструменти plugin та інструменти, що належать каналам.

-Для редагування профілів і перевизначень використовуйте панель Tools у Control UI або поверхні конфігурації/каталогу, а не сприймайте `/tools` як статичний каталог.
+Для редагування профілю й перевизначень використовуйте панель інструментів Control UI або поверхні конфігурації/каталогу замість того, щоб розглядати `/tools` як статичний каталог.

 ## Поверхні використання (що де показується)

- **Використання/квота провайдера** (приклад: "Claude 80% left") відображається в `/status` для поточного провайдера моделі, коли ввімкнено відстеження використання. OpenClaw нормалізує вікна провайдера до `% left`; для MiniMax поля відсотків лише із залишком інвертуються перед показом, а відповіді `model_remains` надають перевагу запису чат-моделі плюс позначці плану з тегом моделі.
- **Рядки токенів/кешу** в `/status` можуть відступати до останнього запису використання з транскрипта, коли live-знімок сесії неповний. Наявні ненульові live-значення все одно мають пріоритет, а відступ до транскрипта також може відновити мітку активної runtime-моделі плюс більший prompt-орієнтований підсумок, коли збережені підсумки відсутні або менші.
- **Виконання проти runtime:** `/status` повідомляє `Execution` для ефективного шляху пісочниці та `Runtime` для того, хто фактично запускає сесію: `OpenClaw Pi Default`, `OpenAI Codex`, CLI-бекенд або ACP-бекенд.
- **Токени/вартість на відповідь** керуються `/usage off|tokens|full` (додається до звичайних відповідей).
- `/model status` стосується **моделей/автентифікації/ендпоїнтів**, а не використання.
+- **Використання/квота провайдера** (приклад: "Claude 80% left") відображається в `/status` для поточного провайдера моделі, коли ввімкнено відстеження використання. OpenClaw нормалізує вікна провайдера до `% left`; для MiniMax поля відсотків лише із залишком інвертуються перед показом, а відповіді `model_remains` надають перевагу запису chat-моделі плюс позначеній моделлю мітці плану.
+- **Рядки токенів/кешу** в `/status` можуть повертатися до останнього запису використання з транскрипту, коли live-знімок сесії неповний. Наявні ненульові live-значення все одно мають пріоритет, а резерв із транскрипту також може відновити мітку активної runtime-моделі плюс більший prompt-орієнтований підсумок, коли збережені підсумки відсутні або менші.
+- **Виконання проти runtime:** `/status` повідомляє `Execution` для ефективного шляху sandbox і `Runtime` для того, хто фактично запускає сесію: `OpenClaw Pi Default`, `OpenAI Codex`, CLI-бекенд або ACP-бекенд.
+- **Токени/вартість на відповідь** керуються через `/usage off|tokens|full` (додається до звичайних відповідей).
+- `/model status` стосується **моделей/автентифікації/endpoint-ів**, а не використання.

 ## Вибір моделі (`/model`)

-`/model` реалізовано як директиву.
+`/model` реалізовано як directive.

 Приклади:

@ -342,14 +342,14 @@ Skills, які може викликати користувач, також до

 Примітки:

- `/model` і `/model list` показують компактний нумерований вибір (сімейство моделей + доступні провайдери).
- У Discord `/model` і `/models` відкривають інтерактивний вибір зі спадними списками провайдера й моделі плюс кроком «Надіслати».
- `/model <#>` вибирає з цього списку (і за можливості надає перевагу поточному провайдеру).
- `/model status` показує детальний вигляд, зокрема налаштований ендпоїнт провайдера (`baseUrl`) і режим API (`api`), коли вони доступні.
+- `/model` і `/model list` показують компактний нумерований picker (сімейство моделей + доступні провайдери).
+- У Discord `/model` і `/models` відкривають інтерактивний picker із випадаючими списками провайдера й моделі та кроком Submit.
+- `/model <#>` вибирає з цього picker (і надає перевагу поточному провайдеру, коли можливо).
+- `/model status` показує детальний вигляд, зокрема налаштований endpoint провайдера (`baseUrl`) і режим API (`api`), коли вони доступні.

 ## Перевизначення для налагодження

-`/debug` дає змогу задавати **лише runtime** перевизначення конфігурації (у памʼяті, не на диску). Тільки для власника. Вимкнено за замовчуванням; увімкніть через `commands.debug: true`.
+`/debug` дає змогу задавати **лише runtime** перевизначення конфігурації (у памʼяті, не на диску). Лише для власника. Типово вимкнено; увімкніть за допомогою `commands.debug: true`.

 Приклади:

@ -367,7 +367,7 @@ Skills, які може викликати користувач, також до

 ## Вивід трасування Plugin

-`/trace` дає змогу перемикати **привʼязані до сесії рядки трасування/налагодження plugin** без увімкнення повного докладного режиму.
+`/trace` дає змогу перемикати **обмежені сесією рядки трасування/налагодження Plugin** без увімкнення повного докладного режиму.

 Приклади:

@ -380,15 +380,15 @@ Skills, які може викликати користувач, також до
 Примітки:

 - `/trace` без аргументу показує поточний стан трасування сесії.
- `/trace on` вмикає рядки трасування plugin для поточної сесії.
+- `/trace on` вмикає рядки трасування Plugin для поточної сесії.
 - `/trace off` знову вимикає їх.
- Рядки трасування plugin можуть зʼявлятися в `/status` і як подальше діагностичне повідомлення після звичайної відповіді асистента.
+- Рядки трасування Plugin можуть зʼявлятися в `/status` і як подальше діагностичне повідомлення після звичайної відповіді помічника.
 - `/trace` не замінює `/debug`; `/debug` і далі керує лише runtime перевизначеннями конфігурації.
- `/trace` не замінює `/verbose`; звичайний докладний вивід інструментів/стану все ще належить до `/verbose`.
+- `/trace` не замінює `/verbose`; звичайний докладний вивід інструментів/статусу й далі належить до `/verbose`.

 ## Оновлення конфігурації

-`/config` записує у вашу конфігурацію на диску (`openclaw.json`). Тільки для власника. Вимкнено за замовчуванням; увімкніть через `commands.config: true`.
+`/config` записує у вашу конфігурацію на диску (`openclaw.json`). Лише для власника. Типово вимкнено; увімкніть за допомогою `commands.config: true`.

 Приклади:

@ -406,7 +406,7 @@ Skills, які може викликати користувач, також до

 ## Оновлення MCP

-`/mcp` записує керовані OpenClaw визначення MCP-серверів у `mcp.servers`. Тільки для власника. Вимкнено за замовчуванням; увімкніть через `commands.mcp: true`.
+`/mcp` записує керовані OpenClaw визначення серверів MCP у `mcp.servers`. Лише для власника. Типово вимкнено; увімкніть за допомогою `commands.mcp: true`.

 Приклади:

@ -423,7 +423,7 @@ Skills, які може викликати користувач, також до

 ## Оновлення Plugin

-`/plugins` дає операторам змогу переглядати виявлені plugins і перемикати ввімкнення в конфігурації. Потоки лише для читання можуть використовувати `/plugin` як псевдонім. Вимкнено за замовчуванням; увімкніть через `commands.plugins: true`.
+`/plugins` дає операторам змогу переглядати знайдені plugins і перемикати ввімкнення в конфігурації. Потоки лише для читання можуть використовувати `/plugin` як псевдонім. Типово вимкнено; увімкніть за допомогою `commands.plugins: true`.

 Приклади:

@ -436,10 +436,10 @@ Skills, які може викликати користувач, також до
 ```

 <Note>
- `/plugins list` і `/plugins show` використовують справжнє виявлення plugin для поточного робочого простору плюс конфігурацію на диску.
+- `/plugins list` і `/plugins show` використовують реальне виявлення Plugin у поточному workspace плюс конфігурацію на диску.
 - `/plugins install` встановлює з ClawHub, npm, git, локальних каталогів і архівів.
- `/plugins enable|disable` оновлює лише конфігурацію plugin; це не встановлює й не видаляє plugins.
- Зміни ввімкнення та вимкнення гаряче перезавантажують runtime-поверхні plugin Gateway для нових ходів агента; встановлення запитує перезапуск Gateway, бо вихідні модулі plugin змінилися.
+- `/plugins enable|disable` оновлює лише конфігурацію Plugin; це не встановлює й не видаляє plugins.
+- Зміни ввімкнення та вимкнення гаряче перезавантажують runtime-поверхні Plugin Gateway для нових ходів agent; install запитує перезапуск Gateway, тому що вихідні модулі Plugin змінилися.

 </Note>

@ -447,18 +447,18 @@ Skills, які може викликати користувач, також до

 <AccordionGroup>
  <Accordion title="Сесії на поверхню">
-    - **Текстові команди** виконуються у звичайній чат-сесії (приватні повідомлення спільно використовують `main`, групи мають власну сесію).
-    - **Нативні команди** використовують ізольовані сесії:
+    - **Текстові команди** виконуються у звичайній chat-сесії (DM спільно використовують `main`, групи мають власну сесію).
+    - **Native-команди** використовують ізольовані сесії:
      - Discord: `agent:<agentId>:discord:slash:<userId>`
      - Slack: `agent:<agentId>:slack:slash:<userId>` (префікс налаштовується через `channels.slack.slashCommand.sessionPrefix`)
-      - Telegram: `telegram:slash:<userId>` (цілить у чат-сесію через `CommandTargetSessionKey`)
-    - **`/stop`** цілить в активну чат-сесію, щоб вона могла перервати поточний запуск.
+      - Telegram: `telegram:slash:<userId>` (цілиться в chat-сесію через `CommandTargetSessionKey`)
+    - **`/stop`** цілиться в активну chat-сесію, щоб вона могла перервати поточний запуск.

  </Accordion>
  <Accordion title="Особливості Slack">
-    `channels.slack.slashCommand` усе ще підтримується для однієї команди стилю `/openclaw`. Якщо ви вмикаєте `commands.native`, потрібно створити по одній slash-команді Slack для кожної вбудованої команди (ті самі назви, що й у `/help`). Меню аргументів команд для Slack доставляються як ефемерні кнопки Block Kit.
+    `channels.slack.slashCommand` і далі підтримується для однієї команди в стилі `/openclaw`. Якщо ви вмикаєте `commands.native`, потрібно створити по одній slash-команді Slack для кожної вбудованої команди (ті самі назви, що й у `/help`). Меню аргументів команд для Slack доставляються як ephemeral кнопки Block Kit.

-    Нативний виняток Slack: зареєструйте `/agentstatus` (не `/status`), бо Slack резервує `/status`. Текстова `/status` усе ще працює в повідомленнях Slack.
+    Виняток native у Slack: зареєструйте `/agentstatus` (не `/status`), тому що Slack резервує `/status`. Текстова `/status` і далі працює в повідомленнях Slack.

  </Accordion>
 </AccordionGroup>
@ -467,15 +467,15 @@ Skills, які може викликати користувач, також до

 `/btw` — це швидке **побічне запитання** про поточну сесію. `/side` є псевдонімом.

-На відміну від звичайного чату:
+На відміну від звичайного chat:

 - воно використовує поточну сесію як фоновий контекст,
 - воно виконується як окремий одноразовий виклик **без інструментів**,
 - воно не змінює майбутній контекст сесії,
- воно не записується в історію транскрипта,
- воно доставляється як live-побічний результат замість звичайного повідомлення асистента.
+- воно не записується в історію транскрипту,
+- воно доставляється як live побічний результат замість звичайного повідомлення помічника.

-Це робить `/btw` корисним, коли потрібне тимчасове уточнення, поки основне завдання триває.
+Це робить `/btw` корисним, коли вам потрібне тимчасове уточнення, поки основне завдання триває.

 Приклад:

@ -484,10 +484,10 @@ Skills, які може викликати користувач, також до
 /side what changed while the main run continued?
 ```

-Див. [Побічні запитання BTW](/uk/tools/btw), щоб отримати повну поведінку та деталі UX клієнта.
+Див. [Побічні запитання BTW](/uk/tools/btw), щоб переглянути повну поведінку й подробиці UX клієнта.

 ## Повʼязане

- [Створення skills](/uk/tools/creating-skills)
+- [Створення Skills](/uk/tools/creating-skills)
 - [Skills](/uk/tools/skills)
 - [Конфігурація Skills](/uk/tools/skills-config)
--- a/docs/uk/tools/steer.md
+++ b/docs/uk/tools/steer.md
@ -0,0 +1,74 @@
+---
+read_when:
+    - Використання /steer або /tell, коли агент уже працює
+    - Порівняння /steer з /queue steer
+    - Вибір, чи скеровувати поточний запуск, субагента чи сеанс ACP
+sidebarTitle: Steer
+summary: Керуйте активним виконанням без зміни режиму черги
+title: Спрямовуйте
+x-i18n:
+    generated_at: "2026-05-03T22:25:45Z"
+    model: gpt-5.5
+    provider: openai
+    source_hash: 71e1c80c0eea86d5c3c29513d3ed0675c04779fc9c6ee3b8a76c4bedaa264d22
+    source_path: tools/steer.md
+    workflow: 16
+---
+
+`/steer` надсилає вказівки до вже активного запуску. Це для моментів «скоригувати цей запуск, поки він ще виконується», а не для початку нового ходу.
+
+## Поточна сесія
+
+Використовуйте `/steer` верхнього рівня, щоб націлитися на активний запуск для поточної сесії:
+
+```text
+/steer prefer the smaller patch and keep the tests focused
+/tell summarize before making the next tool call
+```
+
+Поведінка:
+
+- Націлюється лише на активний запуск поточної сесії.
+- Працює незалежно від режиму `/queue` сесії.
+- Не запускає новий запуск, коли сесія неактивна.
+- Відповідає попередженням, коли немає активного запуску, який можна спрямувати.
+- Використовує шлях спрямування активного runtime, тож модель бачить вказівки на наступній підтримуваній межі runtime.
+
+## Спрямування проти черги
+
+`/queue steer` змінює поведінку звичайних вхідних повідомлень, коли вони надходять під час активного запуску. `/steer <message>` — це явна команда, яка намагається вставити повідомлення цієї команди в активний запуск на наступній підтримуваній межі runtime, незалежно від збереженого налаштування `/queue`.
+
+Використовуйте:
+
+- `/steer <message>`, коли хочете спрямувати активний запуск просто зараз.
+- `/queue steer`, коли хочете, щоб майбутні звичайні повідомлення типово спрямовували активні запуски.
+- `/queue collect` або `/queue followup`, коли нові повідомлення мають чекати пізнішого ходу замість спрямування активного запуску.
+
+Про режими черги та резервну поведінку див. [Черга команд](/uk/concepts/queue) і [Черга спрямування](/uk/concepts/queue-steering).
+
+## Субагенти
+
+Використовуйте `/subagents steer`, коли ціль — дочірній запуск:
+
+```text
+/subagents steer 2 focus only on the API surface
+```
+
+`/steer` верхнього рівня не вибирає субагента за id або індексом у списку. Він завжди націлюється на активний запуск поточної сесії. Див. [Субагенти](/uk/tools/subagents) для id субагентів, міток і команд керування.
+
+## Сесії ACP
+
+Використовуйте `/acp steer`, коли ціль — сесія середовища ACP:
+
+```text
+/acp steer --session agent:main:acp:codex tighten the repro
+```
+
+Див. [Агенти ACP](/uk/tools/acp-agents) для вибору сесії ACP і поведінки runtime.
+
+## Пов’язане
+
+- [Slash-команди](/uk/tools/slash-commands)
+- [Черга команд](/uk/concepts/queue)
+- [Черга спрямування](/uk/concepts/queue-steering)
+- [Субагенти](/uk/tools/subagents)
--- a/docs/uk/tools/subagents.md
+++ b/docs/uk/tools/subagents.md
@ -1,40 +1,40 @@
 ---
 read_when:
    - Вам потрібна фонова або паралельна робота через агента
-    - Ви змінюєте політику sessions_spawn або інструмента для субагентів
-    - Ви впроваджуєте або усуваєте несправності сеансів субагентів, прив’язаних до потоків
+    - Ви змінюєте політику інструмента sessions_spawn або під-агента
+    - Ви впроваджуєте або усуваєте несправності в сеансах субагентів, прив’язаних до потоку
 sidebarTitle: Sub-agents
-summary: Запускайте ізольовані фонові запуски агентів, які повідомляють результати назад у чат запитувача
+summary: Запускайте ізольовані фонові запуски агента, які повідомляють результати назад у чат запитувача
 title: Субагенти
 x-i18n:
-    generated_at: "2026-05-03T21:42:13Z"
+    generated_at: "2026-05-03T22:25:54Z"
    model: gpt-5.5
    provider: openai
-    source_hash: e09370a96c3af4752a774aba5db62e38b0afd78bc5e105597d977cb130597daf
+    source_hash: d0df39e06b952def3eb0b296f36c7dc8c0b0a115785d865236a970c5d453fc37
    source_path: tools/subagents.md
    workflow: 16
 ---

-Субагенти — це фонові запуски агентів, створені з наявного запуску агента.
+Sub-agents — це фонові запуски агентів, породжені з наявного запуску агента.
 Вони працюють у власному сеансі (`agent:<agentId>:subagent:<uuid>`) і,
-коли завершуються, **оголошують** свій результат назад у канал чату
-запитувача. Кожен запуск субагента відстежується як
+після завершення, **оголошують** свій результат назад у канал чату
+запитувача. Кожен запуск sub-agent відстежується як
 [фонове завдання](/uk/automation/tasks).

 Основні цілі:

- Паралелізувати роботу "дослідження / довге завдання / повільний інструмент" без блокування основного запуску.
- Типово ізолювати субагентів (розділення сеансів + необов'язкова пісочниця).
- Зробити поверхню інструментів стійкою до неправильного використання: субагенти типово **не** отримують інструменти сеансу.
- Підтримувати налаштовувану глибину вкладеності для шаблонів оркестраторів.
+- Паралелізувати роботу з "дослідження / довге завдання / повільний інструмент", не блокуючи основний запуск.
+- Ізолювати sub-agents за замовчуванням (розділення сеансів + необов’язкова пісочниця).
+- Зробити поверхню інструментів складною для неправильного використання: sub-agents за замовчуванням **не** отримують інструменти сеансу.
+- Підтримувати налаштовувану глибину вкладеності для патернів оркестратора.

 <Note>
-**Примітка щодо вартості:** кожен субагент типово має власний контекст і використання токенів. Для важких або повторюваних завдань задайте дешевшу модель для субагентів і залиште основного агента на якіснішій моделі. Налаштуйте через `agents.defaults.subagents.model` або перевизначення для окремого агента. Коли дочірньому запуску справді потрібен поточний транскрипт запитувача, агент може запросити `context: "fork"` для цього одного створення. Сеанси субагентів, прив'язані до гілки, типово мають `context: "fork"`, бо вони відгалужують поточну розмову в подальшу гілку.
+**Примітка щодо вартості:** кожен sub-agent за замовчуванням має власний контекст і використання токенів. Для важких або повторюваних завдань задайте дешевшу модель для sub-agents і залиште основного агента на якіснішій моделі. Налаштовуйте через `agents.defaults.subagents.model` або перевизначення для окремого агента. Коли дочірньому агенту справді потрібен поточний транскрипт запитувача, агент може запросити `context: "fork"` для цього одного породження. Сеанси subagent, прив’язані до треду, за замовчуванням використовують `context: "fork"`, бо вони відгалужують поточну розмову в подальший тред.
 </Note>

-## Слеш-команда
+## Slash-команда

-Використовуйте `/subagents`, щоб переглядати або контролювати запуски субагентів для **поточного
+Використовуйте `/subagents`, щоб переглядати або керувати запусками sub-agent для **поточного
 сеансу**:

 ```text
@ -47,16 +47,16 @@ x-i18n:
 /subagents spawn <agentId> <task> [--model <model>] [--thinking <level>]
 ```

-Використовуйте верхньорівневу `/steer <message>`, щоб скеровувати активний запуск поточного сеансу запитувача. Використовуйте `/subagents steer <id|#> <message>`, коли ціль — дочірній запуск.
+Використовуйте верхньорівневу [`/steer <message>`](/uk/tools/steer), щоб спрямувати активний запуск поточного сеансу запитувача. Використовуйте `/subagents steer <id|#> <message>`, коли ціллю є дочірній запуск.

-`/subagents info` показує метадані запуску (статус, часові позначки, ідентифікатор сеансу,
+`/subagents info` показує метадані запуску (статус, часові позначки, id сеансу,
 шлях до транскрипту, очищення). Використовуйте `sessions_history` для обмеженого,
-відфільтрованого з міркувань безпеки перегляду відтворення; переглядайте шлях до транскрипту на диску, коли вам потрібен сирий повний транскрипт.
+відфільтрованого з міркувань безпеки перегляду пригадування; перевіряйте шлях до транскрипту на диску, коли потрібен сирий повний транскрипт.

-### Елементи керування прив'язкою гілок
+### Керування прив’язкою до треду

-Ці команди працюють у каналах, які підтримують постійні прив'язки гілок.
-Див. [Канали з підтримкою гілок](#thread-supporting-channels) нижче.
+Ці команди працюють у каналах, які підтримують постійні прив’язки до тредів.
+Див. [Канали з підтримкою тредів](#thread-supporting-channels) нижче.

 ```text
 /focus <subagent-label|session-key|session-id|session-label>
@ -66,225 +66,225 @@ x-i18n:
 /session max-age <duration|off>
 ```

-### Поведінка створення
+### Поведінка породження

-`/subagents spawn` запускає фонового субагента як користувацьку команду (а не
-внутрішню ретрансляцію) і надсилає одне фінальне оновлення про завершення назад у
+`/subagents spawn` запускає фоновий sub-agent як команду користувача (а не внутрішню
+ретрансляцію) і надсилає одне фінальне оновлення про завершення назад у
 чат запитувача, коли запуск завершується.

 <AccordionGroup>
-  <Accordion title="Неблокувальне завершення з доставленням за ініціативою системи">
-    - Команда створення не блокує виконання; вона одразу повертає ідентифікатор запуску.
-    - Після завершення субагент оголошує повідомлення з підсумком/результатом назад у канал чату запитувача.
-    - Завершення доставляється за ініціативою системи. Після створення **не** опитуйте `/subagents list`, `sessions_list` або `sessions_history` у циклі лише для очікування завершення; переглядайте статус тільки на вимогу для налагодження або втручання.
-    - Після завершення OpenClaw намагається закрити відстежувані вкладки браузера/процеси, відкриті цим сеансом субагента, перш ніж продовжиться потік очищення оголошення.
+  <Accordion title="Non-blocking, push-based completion">
+    - Команда породження не блокує виконання; вона одразу повертає id запуску.
+    - Після завершення sub-agent оголошує повідомлення з підсумком/результатом назад у канал чату запитувача.
+    - Завершення працює за push-моделлю. Після породження **не** опитуйте `/subagents list`, `sessions_list` або `sessions_history` у циклі лише для очікування завершення; перевіряйте статус лише на вимогу для налагодження або втручання.
+    - Після завершення OpenClaw у режимі best-effort закриває відстежувані вкладки браузера/процеси, відкриті цим сеансом sub-agent, перш ніж потік очищення оголошення продовжиться.

  </Accordion>
-  <Accordion title="Стійкість доставлення під час ручного створення">
-    - OpenClaw спершу пробує пряме доставлення `agent` зі стабільним ключем ідемпотентності.
-    - Якщо пряме доставлення не вдається, він повертається до маршрутизації через чергу.
-    - Якщо маршрутизація через чергу все ще недоступна, оголошення повторюється з коротким експоненційним відступом перед остаточною відмовою.
-    - Доставлення завершення зберігає визначений маршрут запитувача: маршрути завершення, прив'язані до гілки або розмови, мають пріоритет, коли доступні; якщо джерело завершення надає лише канал, OpenClaw заповнює відсутню ціль/обліковий запис із визначеного маршруту сеансу запитувача (`lastChannel` / `lastTo` / `lastAccountId`), тож пряме доставлення все одно працює.
+  <Accordion title="Manual-spawn delivery resilience">
+    - OpenClaw спочатку пробує пряму доставку `agent` зі стабільним ключем ідемпотентності.
+    - Якщо пряма доставка не вдається, він переходить до маршрутизації через чергу.
+    - Якщо маршрутизація через чергу все ще недоступна, оголошення повторюється з коротким експоненційним backoff перед остаточною відмовою.
+    - Доставка завершення зберігає розв’язаний маршрут запитувача: маршрути завершення, прив’язані до треду або розмови, мають пріоритет, коли доступні; якщо джерело завершення надає лише канал, OpenClaw заповнює відсутню ціль/обліковий запис із розв’язаного маршруту сеансу запитувача (`lastChannel` / `lastTo` / `lastAccountId`), щоб пряма доставка все одно працювала.

  </Accordion>
-  <Accordion title="Метадані передавання завершення">
-    Передавання завершення до сеансу запитувача — це внутрішній контекст, згенерований середовищем виконання
-    (а не текст, написаний користувачем), і він містить:
+  <Accordion title="Completion handoff metadata">
+    Передавання завершення до сеансу запитувача — це згенерований під час виконання
+    внутрішній контекст (не текст, створений користувачем), який містить:

-    - `Result` — найновіший видимий текст відповіді `assistant`, інакше очищений найновіший текст tool/toolResult. Запуски, що завершилися невдало в кінцевому стані, не використовують повторно захоплений текст відповіді.
+    - `Result` — найновіший видимий текст відповіді `assistant`, інакше очищений найновіший текст tool/toolResult. Термінально невдалі запуски не повторно використовують захоплений текст відповіді.
    - `Status` — `completed successfully` / `failed` / `timed out` / `unknown`.
-    - Стисла статистика середовища виконання/токенів.
-    - Інструкцію доставлення, яка наказує агенту-запитувачу переписати відповідь звичайним голосом асистента (а не пересилати сирі внутрішні метадані).
+    - Компактну статистику виконання/токенів.
+    - Інструкцію доставки, яка каже агенту-запитувачу переписати відповідь звичайним голосом асистента (а не пересилати сирі внутрішні метадані).

  </Accordion>
-  <Accordion title="Режими та середовище виконання ACP">
-    - `--model` і `--thinking` перевизначають типові значення для цього конкретного запуску.
-    - Використовуйте `info`/`log`, щоб переглядати подробиці й вивід після завершення.
-    - `/subagents spawn` — це одноразовий режим (`mode: "run"`). Для постійних сеансів, прив'язаних до гілки, використовуйте `sessions_spawn` з `thread: true` і `mode: "session"`.
-    - Для сеансів обв'язки ACP (Claude Code, Gemini CLI, OpenCode або явно вказаний Codex ACP/acpx) використовуйте `sessions_spawn` з `runtime: "acp"`, коли інструмент оголошує це середовище виконання. Див. [модель доставлення ACP](/uk/tools/acp-agents#delivery-model) під час налагодження завершень або циклів агент-до-агента. Коли Plugin `codex` увімкнено, керування чатом/гілкою Codex має віддавати перевагу `/codex ...` над ACP, якщо користувач явно не просить ACP/acpx.
-    - OpenClaw приховує `runtime: "acp"`, доки ACP не ввімкнено, запитувач не перебуває в пісочниці, і не завантажено бекенд-Plugin, як-от `acpx`. `runtime: "acp"` очікує зовнішній ідентифікатор обв'язки ACP або запис `agents.list[]` з `runtime.type="acp"`; використовуйте типове середовище виконання субагента для звичайних агентів конфігурації OpenClaw з `agents_list`.
+  <Accordion title="Modes and ACP runtime">
+    - `--model` і `--thinking` перевизначають стандартні значення для цього конкретного запуску.
+    - Використовуйте `info`/`log`, щоб переглянути деталі та вивід після завершення.
+    - `/subagents spawn` — це одноразовий режим (`mode: "run"`). Для постійних сеансів, прив’язаних до треду, використовуйте `sessions_spawn` з `thread: true` і `mode: "session"`.
+    - Для сеансів ACP harness (Claude Code, Gemini CLI, OpenCode або явний Codex ACP/acpx) використовуйте `sessions_spawn` з `runtime: "acp"`, коли інструмент оголошує цю runtime. Див. [модель доставки ACP](/uk/tools/acp-agents#delivery-model) під час налагодження завершень або циклів agent-to-agent. Коли Plugin `codex` увімкнено, керування чатом/тредами Codex має віддавати перевагу `/codex ...` над ACP, якщо користувач явно не просить ACP/acpx.
+    - OpenClaw приховує `runtime: "acp"`, доки ACP не увімкнено, запитувач не перебуває в пісочниці, а backend Plugin, наприклад `acpx`, не завантажено. `runtime: "acp"` очікує зовнішній id ACP harness або запис `agents.list[]` з `runtime.type="acp"`; використовуйте стандартну runtime sub-agent для звичайних агентів конфігурації OpenClaw з `agents_list`.

  </Accordion>
 </AccordionGroup>

 ## Режими контексту

-Нативні субагенти запускаються ізольовано, якщо викликач явно не просить відгалузити
+Нативні sub-agents стартують ізольовано, якщо викликач явно не просить відгалузити
 поточний транскрипт.

-| Режим     | Коли його використовувати                                                                                                           | Поведінка                                                                         |
+| Режим       | Коли використовувати                                                                                                                         | Поведінка                                                                          |
 | ---------- | -------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
-| `isolated` | Свіже дослідження, незалежна реалізація, повільна робота інструмента або будь-що, що можна описати в тексті завдання                 | Створює чистий дочірній транскрипт. Це типове значення, яке зменшує використання токенів. |
-| `fork`     | Робота, що залежить від поточної розмови, попередніх результатів інструментів або нюансованих інструкцій, уже наявних у транскрипті запитувача | Відгалужує транскрипт запитувача в дочірній сеанс перед стартом дочірнього запуску. |
+| `isolated` | Нове дослідження, незалежна реалізація, повільна інструментальна робота або будь-що, що можна коротко описати в тексті завдання                           | Створює чистий дочірній транскрипт. Це стандартний режим, який зменшує використання токенів.  |
+| `fork`     | Робота, що залежить від поточної розмови, попередніх результатів інструментів або нюансованих інструкцій, уже наявних у транскрипті запитувача | Відгалужує транскрипт запитувача в дочірній сеанс перед запуском дочірнього агента. |

-Використовуйте `fork` ощадливо. Він призначений для делегування, чутливого до контексту, а не як
-заміна написанню чіткого промпта завдання.
+Використовуйте `fork` помірковано. Він призначений для делегування, чутливого до контексту, а не як
+заміна чіткому промпту завдання.

 ## Інструмент: `sessions_spawn`

-Запускає запуск субагента з `deliver: false` на глобальній доріжці `subagent`,
-потім виконує крок оголошення й публікує відповідь оголошення в канал чату
+Запускає sub-agent з `deliver: false` на глобальній лінії `subagent`,
+потім виконує крок оголошення та публікує відповідь оголошення в канал чату
 запитувача.

 Доступність залежить від ефективної політики інструментів викликача. Профілі `coding` і
-`full` типово надають `sessions_spawn`. Профіль `messaging`
-цього не робить; додайте `tools.alsoAllow: ["sessions_spawn", "sessions_yield",
+`full` за замовчуванням відкривають `sessions_spawn`. Профіль `messaging`
+не відкриває; додайте `tools.alsoAllow: ["sessions_spawn", "sessions_yield",
 "subagents"]` або використовуйте `tools.profile: "coding"` для агентів, які мають делегувати
-роботу. Політики каналу/групи, провайдера, пісочниці та дозволів/заборон для окремого агента можуть
+роботу. Політики каналу/групи, провайдера, пісочниці та allow/deny для окремого агента можуть
 усе ще прибрати інструмент після етапу профілю. Використовуйте `/tools` з того самого
 сеансу, щоб підтвердити ефективний список інструментів.

-**Типові значення:**
+**Стандартні значення:**

- **Модель:** успадковує викликача, якщо ви не задасте `agents.defaults.subagents.model` (або `agents.list[].subagents.model` для окремого агента); явне `sessions_spawn.model` усе одно має пріоритет.
- **Мислення:** успадковує викликача, якщо ви не задасте `agents.defaults.subagents.thinking` (або `agents.list[].subagents.thinking` для окремого агента); явне `sessions_spawn.thinking` усе одно має пріоритет.
- **Тайм-аут запуску:** якщо `sessions_spawn.runTimeoutSeconds` пропущено, OpenClaw використовує `agents.defaults.subagents.runTimeoutSeconds`, коли його задано; інакше повертається до `0` (без тайм-ауту).
+- **Модель:** успадковує викликача, якщо не задано `agents.defaults.subagents.model` (або `agents.list[].subagents.model` для окремого агента); явне `sessions_spawn.model` усе одно має пріоритет.
+- **Thinking:** успадковує викликача, якщо не задано `agents.defaults.subagents.thinking` (або `agents.list[].subagents.thinking` для окремого агента); явне `sessions_spawn.thinking` усе одно має пріоритет.
+- **Таймаут запуску:** якщо `sessions_spawn.runTimeoutSeconds` пропущено, OpenClaw використовує `agents.defaults.subagents.runTimeoutSeconds`, коли задано; інакше повертається до `0` (без таймауту).

 ### Параметри інструмента

 <ParamField path="task" type="string" required>
-  Опис завдання для субагента.
+  Опис завдання для sub-agent.
 </ParamField>
 <ParamField path="label" type="string">
-  Необов'язкова зрозуміла для людини мітка.
+  Необов’язкова людиночитна мітка.
 </ParamField>
 <ParamField path="agentId" type="string">
-  Створити під іншим ідентифікатором агента, коли це дозволено `subagents.allowAgents`.
+  Породжувати під іншим id агента, коли це дозволено `subagents.allowAgents`.
 </ParamField>
 <ParamField path="runtime" type='"subagent" | "acp"' default="subagent">
-  `acp` призначено лише для зовнішніх обв'язок ACP (`claude`, `droid`, `gemini`, `opencode` або явно запитаний Codex ACP/acpx) і для записів `agents.list[]`, у яких `runtime.type` є `acp`.
+  `acp` призначено лише для зовнішніх ACP harnesses (`claude`, `droid`, `gemini`, `opencode` або явно запитаного Codex ACP/acpx) і для записів `agents.list[]`, у яких `runtime.type` дорівнює `acp`.
 </ParamField>
 <ParamField path="resumeSessionId" type="string">
-  Лише ACP. Відновлює наявний сеанс обв'язки ACP, коли `runtime: "acp"`; ігнорується для нативних створень субагентів.
+  Лише ACP. Відновлює наявний сеанс ACP harness, коли `runtime: "acp"`; ігнорується для нативних породжень sub-agent.
 </ParamField>
 <ParamField path="streamTo" type='"parent"'>
-  Лише ACP. Транслює вивід запуску ACP у батьківський сеанс, коли `runtime: "acp"`; пропустіть для нативних створень субагентів.
+  Лише ACP. Транслює вивід запуску ACP до батьківського сеансу, коли `runtime: "acp"`; пропускайте для нативних породжень sub-agent.
 </ParamField>
 <ParamField path="model" type="string">
-  Перевизначає модель субагента. Недійсні значення пропускаються, і субагент запускається на типовій моделі з попередженням у результаті інструмента.
+  Перевизначає модель sub-agent. Некоректні значення пропускаються, а sub-agent запускається на стандартній моделі з попередженням у результаті інструмента.
 </ParamField>
 <ParamField path="thinking" type="string">
-  Перевизначає рівень мислення для запуску субагента.
+  Перевизначає рівень thinking для запуску sub-agent.
 </ParamField>
 <ParamField path="runTimeoutSeconds" type="number">
-  Типово дорівнює `agents.defaults.subagents.runTimeoutSeconds`, коли задано, інакше `0`. Коли задано, запуск субагента переривається через N секунд.
+  За замовчуванням дорівнює `agents.defaults.subagents.runTimeoutSeconds`, коли задано, інакше `0`. Коли задано, запуск sub-agent переривається після N секунд.
 </ParamField>
 <ParamField path="thread" type="boolean" default="false">
-  Коли `true`, запитує прив'язку гілки каналу для цього сеансу субагента.
+  Коли `true`, запитує прив’язку треду каналу для цього сеансу sub-agent.
 </ParamField>
 <ParamField path="mode" type='"run" | "session"' default="run">
-  Якщо `thread: true` і `mode` пропущено, типовим стає `session`. `mode: "session"` вимагає `thread: true`.
+  Якщо `thread: true` і `mode` пропущено, стандартним стає `session`. `mode: "session"` потребує `thread: true`.
 </ParamField>
 <ParamField path="cleanup" type='"delete" | "keep"' default="keep">
-  `"delete"` архівує одразу після оголошення (усе ще зберігає транскрипт через перейменування).
+  `"delete"` архівує одразу після оголошення (транскрипт усе одно зберігається через перейменування).
 </ParamField>
 <ParamField path="sandbox" type='"inherit" | "require"' default="inherit">
-  `require` відхиляє створення, якщо цільове дочірнє середовище виконання не в пісочниці.
+  `require` відхиляє породження, якщо цільова дочірня runtime не перебуває в пісочниці.
 </ParamField>
 <ParamField path="context" type='"isolated" | "fork"' default="isolated">
-  `fork` відгалужує поточний транскрипт запитувача в дочірній сеанс. Лише нативні субагенти. Створення, прив'язані до гілки, типово використовують `fork`; створення без гілки типово використовують `isolated`.
+  `fork` відгалужує поточний транскрипт запитувача в дочірній сеанс. Лише нативні sub-agents. Породження, прив’язані до треду, за замовчуванням використовують `fork`; породження без треду — `isolated`.
 </ParamField>

 <Warning>
-`sessions_spawn` **не** приймає параметри доставлення каналу (`target`,
-`channel`, `to`, `threadId`, `replyTo`, `transport`). Для доставлення використовуйте
-`message`/`sessions_send` зі створеного запуску.
+`sessions_spawn` **не** приймає параметри доставки каналом (`target`,
+`channel`, `to`, `threadId`, `replyTo`, `transport`). Для доставки використовуйте
+`message`/`sessions_send` із породженого запуску.
 </Warning>

-## Сеанси, прив'язані до гілки
+## Сеанси, прив’язані до треду

-Коли для каналу ввімкнено прив'язки гілок, субагент може залишатися прив'язаним
-до гілки, щоб подальші повідомлення користувача в цій гілці продовжували маршрутизуватися до
-того самого сеансу субагента.
+Коли для каналу ввімкнено прив’язки до тредів, sub-agent може залишатися прив’язаним
+до треду, щоб подальші повідомлення користувача в цьому треді й надалі маршрутизувалися до
+того самого сеансу sub-agent.

-### Канали з підтримкою гілок
+### Канали з підтримкою тредів

 **Discord** наразі є єдиним підтримуваним каналом. Він підтримує
-постійні сеанси субагентів, прив'язані до гілки (`sessions_spawn` з
-`thread: true`), ручні елементи керування гілками (`/focus`, `/unfocus`, `/agents`,
-`/session idle`, `/session max-age`) та ключі адаптера
+постійні сеанси subagent, прив’язані до тредів (`sessions_spawn` з
+`thread: true`), ручне керування тредами (`/focus`, `/unfocus`, `/agents`,
+`/session idle`, `/session max-age`) і ключі адаптера
 `channels.discord.threadBindings.enabled`,
 `channels.discord.threadBindings.idleHours`,
-`channels.discord.threadBindings.maxAgeHours` і
+`channels.discord.threadBindings.maxAgeHours` та
 `channels.discord.threadBindings.spawnSessions`.

 ### Швидкий потік

 <Steps>
-  <Step title="Створення">
-    `sessions_spawn` з `thread: true` (і необов'язково `mode: "session"`).
+  <Step title="Spawn">
+    `sessions_spawn` з `thread: true` (і необов’язково `mode: "session"`).
  </Step>
-  <Step title="Прив'язка">
-    OpenClaw створює або прив'язує гілку до цілі цього сеансу в активному каналі.
+  <Step title="Bind">
+    OpenClaw створює або прив’язує тред до цільового сеансу в активному каналі.
  </Step>
-  <Step title="Маршрутизація подальших повідомлень">
-    Відповіді й подальші повідомлення в цій гілці маршрутизуються до прив'язаного сеансу.
+  <Step title="Route follow-ups">
+    Відповіді та подальші повідомлення в цьому треді маршрутизуються до прив’язаного сеансу.
  </Step>
-  <Step title="Перегляд тайм-аутів">
-    Використовуйте `/session idle`, щоб переглядати/оновлювати автоматичне зняття фокуса через неактивність, і
-    `/session max-age`, щоб контролювати жорстку верхню межу.
+  <Step title="Inspect timeouts">
+    Використовуйте `/session idle`, щоб переглянути/оновити автоматичне скасування фокуса через неактивність, і
+    `/session max-age`, щоб керувати жорстким лімітом.
  </Step>
-  <Step title="Від'єднання">
-    Використовуйте `/unfocus`, щоб від'єднати вручну.
+  <Step title="Detach">
+    Використовуйте `/unfocus`, щоб від’єднати вручну.
  </Step>
 </Steps>

-### Ручні елементи керування
+### Ручне керування

 | Команда            | Дія                                                                   |
 | ------------------ | --------------------------------------------------------------------- |
-| `/focus <target>`  | Прив'язати поточний потік (або створити його) до цілі субагента/сеансу |
-| `/unfocus`         | Прибрати прив'язку для поточного прив'язаного потоку                  |
-| `/agents`          | Показати активні запуски та стан прив'язки (`thread:<id>` або `unbound`) |
-| `/session idle`    | Переглянути/оновити автоматичне скасування фокуса через бездіяльність (лише сфокусовані прив'язані потоки) |
-| `/session max-age` | Переглянути/оновити жорстке обмеження (лише сфокусовані прив'язані потоки) |
+| `/focus <target>`  | Прив’язати поточний потік (або створити його) до цілі під-агента/сеансу |
+| `/unfocus`         | Видалити прив’язку для поточного прив’язаного потоку                  |
+| `/agents`          | Перелічити активні запуски та стан прив’язки (`thread:<id>` або `unbound`) |
+| `/session idle`    | Переглянути/оновити автоматичне зняття фокуса через бездіяльність (лише сфокусовані прив’язані потоки) |
+| `/session max-age` | Переглянути/оновити жорстке обмеження часу (лише сфокусовані прив’язані потоки) |

 ### Перемикачі конфігурації

 - **Глобальне значення за замовчуванням:** `session.threadBindings.enabled`, `session.threadBindings.idleHours`, `session.threadBindings.maxAgeHours`.
- **Перевизначення каналу та ключі автоматичної прив'язки під час створення** залежать від адаптера. Див. [Канали з підтримкою потоків](#thread-supporting-channels) вище.
+- **Перевизначення каналу та ключі автоматичної прив’язки під час створення** залежать від адаптера. Див. [Канали з підтримкою потоків](#thread-supporting-channels) вище.

 Див. [Довідник конфігурації](/uk/gateway/configuration-reference) і
-[Slash-команди](/uk/tools/slash-commands), щоб дізнатися поточні деталі адаптерів.
+[Slash-команди](/uk/tools/slash-commands) для поточних деталей адаптерів.

 ### Список дозволених

 <ParamField path="agents.list[].subagents.allowAgents" type="string[]">
-  Список ідентифікаторів агентів, на які можна націлюватися через явний `agentId` (`["*"]` дозволяє будь-який). За замовчуванням: лише агент-запитувач. Якщо ви задаєте список і все одно хочете, щоб запитувач створював себе з `agentId`, включіть ідентифікатор запитувача до списку.
+  Список ідентифікаторів агентів, на які можна націлюватися через явний `agentId` (`["*"]` дозволяє будь-який). За замовчуванням: лише агент-запитувач. Якщо ви задаєте список і все одно хочете, щоб запитувач міг створювати самого себе з `agentId`, додайте ідентифікатор запитувача до списку.
 </ParamField>
 <ParamField path="agents.defaults.subagents.allowAgents" type="string[]">
  Типовий список дозволених цільових агентів, який використовується, коли агент-запитувач не задає власний `subagents.allowAgents`.
 </ParamField>
 <ParamField path="agents.defaults.subagents.requireAgentId" type="boolean" default="false">
-  Блокувати виклики `sessions_spawn`, які пропускають `agentId` (примусово вимагає явного вибору профілю). Перевизначення для окремого агента: `agents.list[].subagents.requireAgentId`.
+  Блокувати виклики `sessions_spawn`, які пропускають `agentId` (примушує явно вибирати профіль). Перевизначення для окремого агента: `agents.list[].subagents.requireAgentId`.
 </ParamField>

-Якщо сеанс запитувача ізольований у пісочниці, `sessions_spawn` відхиляє цілі,
+Якщо сеанс запитувача працює в пісочниці, `sessions_spawn` відхиляє цілі,
 які запускалися б без пісочниці.

 ### Виявлення

-Використовуйте `agents_list`, щоб побачити, які ідентифікатори агентів зараз дозволені для
-`sessions_spawn`. Відповідь містить ефективну
-модель кожного переліченого агента та вбудовані метадані середовища виконання, щоб виклики могли відрізняти PI, сервер застосунку Codex
+Використовуйте `agents_list`, щоб побачити, які ідентифікатори агентів наразі дозволені для
+`sessions_spawn`. Відповідь містить ефективну модель кожного переліченого агента
+та вбудовані метадані середовища виконання, щоб виклики могли відрізняти PI, сервер застосунку Codex
 та інші налаштовані нативні середовища виконання.

 ### Автоархівація

- Сеанси субагентів автоматично архівуються після `agents.defaults.subagents.archiveAfterMinutes` (за замовчуванням `60`).
- Архівування використовує `sessions.delete` і перейменовує транскрипт на `*.deleted.<timestamp>` (у тій самій папці).
- `cleanup: "delete"` архівує одразу після сповіщення (транскрипт усе одно зберігається через перейменування).
- Автоархівація виконується за принципом найкращих зусиль; очікувані таймери втрачаються, якщо Gateway перезапускається.
- `runTimeoutSeconds` **не** виконує автоархівацію; він лише зупиняє запуск. Сеанс лишається до автоархівації.
+- Сеанси під-агентів автоматично архівуються після `agents.defaults.subagents.archiveAfterMinutes` (за замовчуванням `60`).
+- Архівація використовує `sessions.delete` і перейменовує транскрипт на `*.deleted.<timestamp>` (у тій самій папці).
+- `cleanup: "delete"` архівує одразу після оголошення (транскрипт усе одно зберігається через перейменування).
+- Автоархівація виконується за принципом найкращого зусилля; очікувані таймери втрачаються, якщо Gateway перезапускається.
+- `runTimeoutSeconds` **не** виконує автоархівацію; він лише зупиняє запуск. Сеанс залишається до автоархівації.
 - Автоархівація однаково застосовується до сеансів глибини 1 і глибини 2.
- Очищення браузера відокремлене від архівного очищення: відстежувані вкладки/процеси браузера за найкращими зусиллями закриваються після завершення запуску, навіть якщо запис транскрипта/сеансу зберігається.
+- Очищення браузера відокремлене від очищення архіву: відстежувані вкладки/процеси браузера закриваються за принципом найкращого зусилля після завершення запуску, навіть якщо транскрипт/запис сеансу зберігається.

-## Вкладені субагенти
+## Вкладені під-агенти

-За замовчуванням субагенти не можуть створювати власних субагентів
+За замовчуванням під-агенти не можуть створювати власних під-агентів
 (`maxSpawnDepth: 1`). Задайте `maxSpawnDepth: 2`, щоб увімкнути один рівень
-вкладеності — **патерн оркестратора**: основний → субагент-оркестратор →
-робочі субсубагенти.
+вкладеності — **шаблон оркестратора**: основний → під-агент-оркестратор →
+робочі під-під-агенти.

 ```json5
 {
@ -303,153 +303,153 @@ x-i18n:

 ### Рівні глибини

-| Глибина | Форма ключа сеансу                          | Роль                                          | Може створювати?             |
+| Глибина | Форма ключа сеансу                           | Роль                                          | Може створювати?             |
 | ----- | -------------------------------------------- | --------------------------------------------- | ---------------------------- |
 | 0     | `agent:<id>:main`                            | Основний агент                                | Завжди                       |
-| 1     | `agent:<id>:subagent:<uuid>`                 | Субагент (оркестратор, коли дозволено глибину 2) | Лише якщо `maxSpawnDepth >= 2` |
-| 2     | `agent:<id>:subagent:<uuid>:subagent:<uuid>` | Субсубагент (листовий робітник)               | Ніколи                       |
+| 1     | `agent:<id>:subagent:<uuid>`                 | Під-агент (оркестратор, коли дозволена глибина 2) | Лише якщо `maxSpawnDepth >= 2` |
+| 2     | `agent:<id>:subagent:<uuid>:subagent:<uuid>` | Під-під-агент (листовий робітник)             | Ніколи                       |

-### Ланцюжок сповіщень
+### Ланцюг оголошень

-Результати передаються назад ланцюжком:
+Результати передаються назад угору ланцюгом:

-1. Робітник глибини 2 завершує роботу → сповіщає свого батька (оркестратора глибини 1).
-2. Оркестратор глибини 1 отримує сповіщення, синтезує результати, завершує роботу → сповіщає основний сеанс.
-3. Основний агент отримує сповіщення та доставляє його користувачу.
+1. Робітник глибини 2 завершується → оголошує своєму батьківському сеансу (оркестратору глибини 1).
+2. Оркестратор глибини 1 отримує оголошення, синтезує результати, завершується → оголошує основному.
+3. Основний агент отримує оголошення та доставляє його користувачу.

-Кожен рівень бачить лише сповіщення від своїх прямих дочірніх елементів.
+Кожен рівень бачить лише оголошення від своїх безпосередніх дочірніх сеансів.

 <Note>
-**Операційні вказівки:** запускайте дочірню роботу один раз і чекайте подій
+**Операційні настанови:** запускайте дочірню роботу один раз і чекайте подій
 завершення замість побудови циклів опитування навколо `sessions_list`,
-`sessions_history`, `/subagents list` або команд сну `exec`.
-`sessions_list` і `/subagents list` утримують зв'язки дочірніх сеансів
-сфокусованими на живій роботі — живі дочірні елементи залишаються приєднаними, завершені дочірні елементи
-залишаються видимими в короткому недавньому вікні, а застарілі посилання лише зі сховища на дочірні елементи
+`sessions_history`, `/subagents list` або команд `exec` зі сном.
+`sessions_list` і `/subagents list` утримують зв’язки дочірніх сеансів
+зосередженими на живій роботі — живі дочірні сеанси залишаються прикріпленими, завершені дочірні сеанси
+залишаються видимими протягом короткого недавнього вікна, а застарілі посилання лише зі сховища
 ігноруються після завершення їхнього вікна свіжості. Це запобігає тому, щоб старі метадані `spawnedBy` /
-`parentSessionKey` повторно відроджували примарні дочірні елементи після
-перезапуску. Якщо подія завершення дочірнього елемента надходить після того, як ви вже надіслали
+`parentSessionKey` воскресали примарні дочірні сеанси після
+перезапуску. Якщо подія завершення дочірнього сеансу надходить після того, як ви вже надіслали
 фінальну відповідь, правильне подальше повідомлення — точний мовчазний токен
 `NO_REPLY` / `no_reply`.
 </Note>

 ### Політика інструментів за глибиною

- Роль і область керування записуються в метадані сеансу під час створення. Це запобігає випадковому повторному отриманню привілеїв оркестратора пласкими або відновленими ключами сеансу.
- **Глибина 1 (оркестратор, коли `maxSpawnDepth >= 2`):** отримує `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, щоб керувати своїми дочірніми елементами. Інші інструменти сеансів/системи лишаються забороненими.
- **Глибина 1 (лист, коли `maxSpawnDepth == 1`):** без інструментів сеансів (поточна поведінка за замовчуванням).
- **Глибина 2 (листовий робітник):** без інструментів сеансів — `sessions_spawn` завжди заборонено на глибині 2. Не може створювати подальші дочірні елементи.
+- Роль і область керування записуються в метадані сеансу під час створення. Це не дає плоским або відновленим ключам сеансів випадково знову отримати привілеї оркестратора.
+- **Глибина 1 (оркестратор, коли `maxSpawnDepth >= 2`):** отримує `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, щоб керувати своїми дочірніми сеансами. Інші інструменти сеансу/системи залишаються забороненими.
+- **Глибина 1 (лист, коли `maxSpawnDepth == 1`):** без інструментів сеансу (поточна типова поведінка).
+- **Глибина 2 (листовий робітник):** без інструментів сеансу — `sessions_spawn` завжди заборонено на глибині 2. Не може створювати подальших дочірніх сеансів.

 ### Ліміт створення для окремого агента

-Кожен сеанс агента (на будь-якій глибині) може мати щонайбільше `maxChildrenPerAgent`
-(за замовчуванням `5`) активних дочірніх елементів одночасно. Це запобігає неконтрольованому розгалуженню
+Кожен сеанс агента (на будь-якій глибині) може мати не більше `maxChildrenPerAgent`
+(за замовчуванням `5`) активних дочірніх сеансів одночасно. Це запобігає неконтрольованому розгортанню
 від одного оркестратора.

 ### Каскадна зупинка

-Зупинка оркестратора глибини 1 автоматично зупиняє всі його дочірні елементи глибини 2:
+Зупинка оркестратора глибини 1 автоматично зупиняє всі його дочірні сеанси глибини 2:

- `/stop` в основному чаті зупиняє всіх агентів глибини 1 і каскадно зупиняє їхні дочірні елементи глибини 2.
- `/subagents kill <id>` зупиняє конкретного субагента й каскадно зупиняє його дочірні елементи.
- `/subagents kill all` зупиняє всіх субагентів для запитувача та виконує каскадну зупинку.
+- `/stop` в основному чаті зупиняє всіх агентів глибини 1 і каскадно зупиняє їхні дочірні сеанси глибини 2.
+- `/subagents kill <id>` зупиняє конкретного під-агента і каскадно зупиняє його дочірні сеанси.
+- `/subagents kill all` зупиняє всіх під-агентів для запитувача і виконує каскадну зупинку.

 ## Автентифікація

-Автентифікація субагента визначається за **ідентифікатором агента**, а не за типом сеансу:
+Автентифікація під-агента визначається за **ідентифікатором агента**, а не за типом сеансу:

- Ключ сеансу субагента — `agent:<agentId>:subagent:<uuid>`.
+- Ключ сеансу під-агента: `agent:<agentId>:subagent:<uuid>`.
 - Сховище автентифікації завантажується з `agentDir` цього агента.
- Профілі автентифікації основного агента об'єднуються як **резервні**; профілі агента перевизначають основні профілі у разі конфліктів.
+- Профілі автентифікації основного агента об’єднуються як **резервний варіант**; профілі агента перевизначають основні профілі у разі конфліктів.

-Об'єднання є адитивним, тому основні профілі завжди доступні як
-резервні. Повністю ізольована автентифікація для кожного агента поки не підтримується.
+Об’єднання є додавальним, тому основні профілі завжди доступні як
+резервні. Повністю ізольована автентифікація для кожного агента ще не підтримується.

-## Сповіщення
+## Оголошення

-Субагенти звітують через крок сповіщення:
+Під-агенти звітують назад через крок оголошення:

- Крок сповіщення виконується всередині сеансу субагента (не сеансу запитувача).
- Якщо субагент відповідає точно `ANNOUNCE_SKIP`, нічого не публікується.
- Якщо останній текст асистента є точним мовчазним токеном `NO_REPLY` / `no_reply`, вивід сповіщення пригнічується, навіть якщо раніше був видимий прогрес.
+- Крок оголошення виконується всередині сеансу під-агента (не сеансу запитувача).
+- Якщо під-агент відповідає точно `ANNOUNCE_SKIP`, нічого не публікується.
+- Якщо останній текст асистента є точним мовчазним токеном `NO_REPLY` / `no_reply`, вивід оголошення пригнічується, навіть якщо раніше був видимий прогрес.

 Доставка залежить від глибини запитувача:

 - Сеанси запитувача верхнього рівня використовують подальший виклик `agent` із зовнішньою доставкою (`deliver=true`).
- Вкладені сеанси субагентів-запитувачів отримують внутрішню подальшу ін'єкцію (`deliver=false`), щоб оркестратор міг синтезувати дочірні результати в межах сеансу.
- Якщо вкладений сеанс субагента-запитувача зник, OpenClaw повертається до запитувача цього сеансу, коли він доступний.
+- Вкладені сеанси під-агента-запитувача отримують внутрішнє подальше вставлення (`deliver=false`), щоб оркестратор міг синтезувати результати дочірніх сеансів у межах сеансу.
+- Якщо вкладений сеанс під-агента-запитувача зник, OpenClaw повертається до запитувача цього сеансу, коли він доступний.

 Для сеансів запитувача верхнього рівня пряма доставка в режимі завершення спочатку
-вирішує будь-який прив'язаний маршрут розмови/потоку та перевизначення hook, а потім заповнює
+розв’язує будь-який маршрут прив’язаної розмови/потоку та перевизначення hook, а потім заповнює
 відсутні поля цілі каналу зі збереженого маршруту сеансу запитувача.
-Це утримує завершення в правильному чаті/темі, навіть коли джерело завершення
+Це утримує завершення у правильному чаті/темі, навіть коли джерело завершення
 ідентифікує лише канал.

-Агрегація завершень дочірніх елементів обмежена поточним запуском запитувача під час
-побудови вкладених результатів завершення, запобігаючи витоку застарілих дочірніх
-виводів із попередніх запусків у поточне сповіщення. Відповіді сповіщень зберігають
+Агрегація завершення дочірніх сеансів обмежена поточним запуском запитувача під час
+побудови вкладених результатів завершення, запобігаючи просочуванню виводів дочірніх сеансів
+із попередніх застарілих запусків у поточне оголошення. Відповіді оголошення зберігають
 маршрутизацію потоку/теми, коли вона доступна в адаптерах каналів.

-### Контекст сповіщення
+### Контекст оголошення

-Контекст сповіщення нормалізується до стабільного внутрішнього блока події:
+Контекст оголошення нормалізується до стабільного внутрішнього блока події:

-| Поле           | Джерело                                                                                                      |
+| Поле          | Джерело                                                                                                       |
 | -------------- | ------------------------------------------------------------------------------------------------------------- |
 | Джерело        | `subagent` або `cron`                                                                                         |
 | Ідентифікатори сеансу | Ключ/ідентифікатор дочірнього сеансу                                                                    |
-| Тип            | Тип сповіщення + мітка завдання                                                                              |
-| Статус         | Виведено з результату середовища виконання (`success`, `error`, `timeout` або `unknown`) — **не** виводиться з тексту моделі |
-| Вміст результату | Останній видимий текст асистента, інакше санітизований останній текст tool/toolResult                      |
-| Подальша дія   | Інструкція, що описує, коли відповідати, а коли лишатися мовчазним                                           |
+| Тип            | Тип оголошення + мітка завдання                                                                              |
+| Стан           | Виведено з результату середовища виконання (`success`, `error`, `timeout` або `unknown`) — **не** виводиться з тексту моделі |
+| Вміст результату | Останній видимий текст асистента, інакше очищений останній текст інструмента/toolResult                    |
+| Подальша дія   | Інструкція, що описує, коли відповідати, а коли залишатися мовчазним                                         |

-Термінальні невдалі запуски повідомляють статус помилки без повторного відтворення захопленого
-тексту відповіді. У разі тайм-ауту, якщо дочірній елемент устиг лише виконати виклики інструментів, сповіщення
-може стиснути цю історію в короткий підсумок часткового прогресу замість
-повторного відтворення сирого виводу інструментів.
+Термінальні невдалі запуски повідомляють стан помилки без повторного відтворення захопленого
+тексту відповіді. У разі тайм-ауту, якщо дочірній сеанс встиг лише виконати виклики інструментів, оголошення
+може згорнути цю історію в короткий підсумок часткового прогресу замість
+відтворення сирого виводу інструментів.

 ### Рядок статистики

-Корисні навантаження сповіщень містять рядок статистики в кінці (навіть коли обгорнуті):
+Корисні навантаження оголошень містять рядок статистики в кінці (навіть коли загорнуті):

 - Час виконання (наприклад, `runtime 5m12s`).
 - Використання токенів (вхідні/вихідні/усього).
- Орієнтовна вартість, коли налаштовано ціни моделі (`models.providers.*.models[].cost`).
- `sessionKey`, `sessionId` і шлях транскрипта, щоб основний агент міг отримати історію через `sessions_history` або переглянути файл на диску.
+- Орієнтовна вартість, коли налаштовано ціни моделей (`models.providers.*.models[].cost`).
+- `sessionKey`, `sessionId` і шлях транскрипту, щоб основний агент міг отримати історію через `sessions_history` або переглянути файл на диску.

-Внутрішні метадані призначені лише для оркестрації; відповіді для користувачів
+Внутрішні метадані призначені лише для оркестрації; відповіді для користувача
 слід переписувати звичайним голосом асистента.

 ### Чому варто надавати перевагу `sessions_history`

 `sessions_history` — безпечніший шлях оркестрації:

- Згадування асистента спочатку нормалізується: теги мислення видаляються; каркаси `<relevant-memories>` / `<relevant_memories>` видаляються; XML-блоки корисного навантаження викликів інструментів у простому тексті (`<tool_call>`, `<function_call>`, `<tool_calls>`, `<function_calls>`) видаляються, включно з обрізаними корисними навантаженнями, які ніколи не закриваються коректно; понижені каркаси викликів/результатів інструментів і маркери історичного контексту видаляються; витеклі керівні токени моделі (`<|assistant|>`, інші ASCII `<|...|>`, повної ширини `<｜...｜>`) видаляються; некоректний XML викликів інструментів MiniMax видаляється.
+- Спогади асистента спочатку нормалізуються: теги мислення видаляються; каркас `<relevant-memories>` / `<relevant_memories>` видаляється; XML-блоки корисного навантаження викликів інструментів у plain-text (`<tool_call>`, `<function_call>`, `<tool_calls>`, `<function_calls>`) видаляються, включно з обрізаними корисними навантаженнями, які ніколи коректно не закриваються; знижений каркас викликів/результатів інструментів і маркери історичного контексту видаляються; витеклі керівні токени моделі (`<|assistant|>`, інші ASCII `<|...|>`, повноширинні `<｜...｜>`) видаляються; некоректний XML викликів інструментів MiniMax видаляється.
 - Текст, схожий на облікові дані/токени, редагується.
 - Довгі блоки можуть обрізатися.
- Дуже великі історії можуть відкидати старіші рядки або замінювати завеликий рядок на `[sessions_history omitted: message too large]`.
- Перегляд сирого транскрипта на диску є резервним варіантом, коли потрібен повний побайтово точний транскрипт.
+- Дуже великі історії можуть відкидати старіші рядки або замінювати надмірно великий рядок на `[sessions_history omitted: message too large]`.
+- Перегляд сирого транскрипту на диску є резервним варіантом, коли потрібен повний побайтово точний транскрипт.

 ## Політика інструментів

-Субагенти спочатку використовують той самий профіль і конвеєр політики інструментів, що й батьківський
+Під-агенти спочатку використовують той самий профіль і конвеєр політики інструментів, що й батьківський
 або цільовий агент. Після цього OpenClaw застосовує шар обмежень
-субагента.
+під-агента.

-Без обмежувального `tools.profile` субагенти отримують **усі інструменти, крім
-інструментів сеансів** і системних інструментів:
+Без обмежувального `tools.profile` під-агенти отримують **усі інструменти, крім
+інструментів сеансу** та системних інструментів:

 - `sessions_list`
 - `sessions_history`
 - `sessions_send`
 - `sessions_spawn`

-`sessions_history` і тут лишається обмеженим, санітизованим поданням згадування —
-це не сирий дамп транскрипта.
+`sessions_history` тут також залишається обмеженим, очищеним поданням пригадування — це
+не сирий дамп транскрипту.

-Коли `maxSpawnDepth >= 2`, субагенти-оркестратори глибини 1 додатково
+Коли `maxSpawnDepth >= 2`, під-агенти-оркестратори глибини 1 додатково
 отримують `sessions_spawn`, `subagents`, `sessions_list` і
-`sessions_history`, щоб керувати своїми дочірніми елементами.
+`sessions_history`, щоб керувати своїми дочірніми сеансами.

 ### Перевизначення через конфігурацію

@ -475,11 +475,11 @@ x-i18n:
 }
 ```

-`tools.subagents.tools.allow` — це остаточний фільтр лише дозволеного. Він може звузити
-вже визначений набір інструментів, але не може **додати назад** інструмент, вилучений
+`tools.subagents.tools.allow` — це фінальний фільтр лише для дозволеного. Він може звузити
+вже визначений набір інструментів, але не може **повернути** інструмент, вилучений
 через `tools.profile`. Наприклад, `tools.profile: "coding"` включає
 `web_search`/`web_fetch`, але не інструмент `browser`. Щоб дозволити
-під-агентам із профілем coding використовувати автоматизацію браузера, додайте browser на
+субагентам із coding-профілем використовувати автоматизацію браузера, додайте browser на
 етапі профілю:

 ```json5
@ -491,12 +491,12 @@ x-i18n:
 }
 ```

-Використовуйте `agents.list[].tools.alsoAllow: ["browser"]` для окремого агента, коли автоматизацію браузера має отримати лише один
-агент.
+Використовуйте `agents.list[].tools.alsoAllow: ["browser"]` для окремого агента, коли лише один
+агент має отримати автоматизацію браузера.

 ## Паралельність

-Під-агенти використовують окрему чергу виконання в межах процесу:
+Субагенти використовують окрему внутрішньопроцесну чергу:

 - **Назва черги:** `subagent`
 - **Паралельність:** `agents.defaults.subagents.maxConcurrent` (за замовчуванням `8`)
@ -504,47 +504,47 @@ x-i18n:
 ## Живучість і відновлення

 OpenClaw не вважає відсутність `endedAt` постійним доказом того, що
-під-агент досі активний. Незавершені запуски, старші за вікно застарілого запуску,
-перестають враховуватися як активні/очікувані в `/subagents list`, зведеннях стану,
-блокуванні завершення нащадків і перевірках паралельності для окремої сесії.
+субагент досі активний. Незавершені запуски, старші за вікно застарілого запуску,
+перестають враховуватися як активні/очікувані в `/subagents list`, зведеннях статусу,
+блокуванні завершення нащадків і перевірках паралельності для сесії.

-Після перезапуску Gateway застарілі незавершені відновлені запуски обрізаються, якщо
+Після перезапуску Gateway застарілі незавершені відновлені запуски видаляються, якщо
 їхня дочірня сесія не позначена як `abortedLastRun: true`. Такі
-перервані перезапуском дочірні сесії залишаються придатними для відновлення через потік
-відновлення осиротілих під-агентів, який надсилає синтетичне повідомлення resume перед
+дочірні сесії, перервані перезапуском, лишаються придатними до відновлення через потік
+відновлення осиротілих субагентів, який надсилає синтетичне повідомлення відновлення перед
 очищенням маркера переривання.

 Автоматичне відновлення після перезапуску обмежене для кожної дочірньої сесії. Якщо той самий
-дочірній під-агент неодноразово приймається для відновлення осиротілих у межах
-швидкого вікна повторного зависання, OpenClaw зберігає tombstone відновлення в цій
-сесії та припиняє автоматично відновлювати її під час наступних перезапусків. Запустіть
+дочірній субагент неодноразово приймається для відновлення осиротілої сесії в межах
+швидкого вікна повторного зависання, OpenClaw зберігає tombstone відновлення для цієї
+сесії та припиняє автоматично відновлювати її під час наступних перезапусків. Виконайте
 `openclaw tasks maintenance --apply`, щоб узгодити запис завдання, або
 `openclaw doctor --fix`, щоб очистити застарілі прапорці перерваного відновлення в
 сесіях із tombstone.

 <Note>
-Якщо створення під-агента завершується помилкою Gateway `PAIRING_REQUIRED` /
-`scope-upgrade`, перевірте викликача RPC перед редагуванням стану спарювання.
+Якщо створення субагента завершується помилкою Gateway `PAIRING_REQUIRED` /
+`scope-upgrade`, перевірте викликача RPC перед редагуванням стану сполучення.
 Внутрішня координація `sessions_spawn` має підключатися як
-`client.id: "gateway-client"` з `client.mode: "backend"` через прямий
-local loopback з автентифікацією за спільним токеном/паролем; цей шлях не залежить від
-базового рівня області paired-device для CLI. Віддалені викликачі, явні
-`deviceIdentity`, явні шляхи device-token і клієнти browser/node
-досі потребують звичайного схвалення пристрою для підвищення області.
+`client.id: "gateway-client"` із `client.mode: "backend"` через пряму
+автентифікацію спільним токеном/паролем через loopback; цей шлях не залежить від
+базового рівня області дії сполученого пристрою CLI. Віддаленим викликачам, явним
+`deviceIdentity`, явним шляхам device-token і клієнтам browser/node
+усе ще потрібне звичайне схвалення пристрою для підвищення області дії.
 </Note>

 ## Зупинка

- Надсилання `/stop` у чаті запитувача перериває сесію запитувача й зупиняє всі активні запуски під-агентів, створені з неї, каскадно переходячи до вкладених дочірніх елементів.
- `/subagents kill <id>` зупиняє конкретного під-агента й каскадно зупиняє його дочірні елементи.
+- Надсилання `/stop` у чаті запитувача перериває сесію запитувача та зупиняє всі активні запуски субагентів, створені з неї, каскадно поширюючись на вкладених нащадків.
+- `/subagents kill <id>` зупиняє конкретного субагента та каскадно поширюється на його нащадків.

 ## Обмеження

- Оголошення під-агента виконується за принципом **best-effort**. Якщо gateway перезапускається, очікувана робота "announce back" втрачається.
- Під-агенти досі спільно використовують ресурси того самого процесу gateway; розглядайте `maxConcurrent` як запобіжний клапан.
- `sessions_spawn` завжди неблокувальний: він одразу повертає `{ status: "accepted", runId, childSessionKey }`.
- Контекст під-агента вставляє лише `AGENTS.md` + `TOOLS.md` (без `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` або `BOOTSTRAP.md`).
- Максимальна глибина вкладеності становить 5 (діапазон `maxSpawnDepth`: 1–5). Для більшості випадків використання рекомендовано глибину 2.
+- Оголошення субагента виконується **за найкращих зусиль**. Якщо gateway перезапускається, очікувана робота "announce back" втрачається.
+- Субагенти все ще спільно використовують ресурси того самого процесу gateway; розглядайте `maxConcurrent` як запобіжний клапан.
+- `sessions_spawn` завжди неблокувальний: він негайно повертає `{ status: "accepted", runId, childSessionKey }`.
+- Контекст субагента вставляє лише `AGENTS.md` + `TOOLS.md` (без `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` або `BOOTSTRAP.md`).
+- Максимальна глибина вкладення становить 5 (діапазон `maxSpawnDepth`: 1–5). Для більшості випадків використання рекомендовано глибину 2.
 - `maxChildrenPerAgent` обмежує кількість активних дочірніх елементів на сесію (за замовчуванням `5`, діапазон `1–20`).

 ## Пов’язане