chore(i18n): refresh uk translations

2026-04-27 18:58:40 +00:00 · 2026-04-27 18:58:40 +00:00 · 95ad286370
commit 95ad286370
parent 5536af8f30
2 changed files with 378 additions and 380 deletions
--- a/docs/uk/channels/matrix.md
+++ b/docs/uk/channels/matrix.md
@ -1,41 +1,41 @@
 ---
 read_when:
    - Налаштування Matrix в OpenClaw
-    - Налаштування Matrix E2EE та верифікації
+    - Налаштування E2EE та верифікації Matrix
 summary: Статус підтримки Matrix, налаштування та приклади конфігурації
 title: Matrix
 x-i18n:
-    generated_at: "2026-04-27T10:57:54Z"
+    generated_at: "2026-04-27T18:55:33Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 253c91d0b425617a2f6e9bf1edfa56db9fee0607509ec382b3abfb99452f6003
+    source_hash: adfd82ef371046cd537455db77285ab27e3a09f7e589a773c5e12bc766d25512
    source_path: channels/matrix.md
    workflow: 15
 ---

-Matrix — це вбудований plugin каналу для OpenClaw.
+Matrix — це вбудований channel plugin для OpenClaw.
 Він використовує офіційний `matrix-js-sdk` і підтримує DM, кімнати, треди, медіа, реакції, опитування, геолокацію та E2EE.

 ## Вбудований plugin

-Поточні пакетні релізи OpenClaw постачаються з plugin Matrix з коробки. Вам не потрібно нічого встановлювати; активація виконується через налаштування `channels.matrix.*` (див. [Налаштування](#setup)).
+Поточні пакетовані релізи OpenClaw постачаються з plugin Matrix у комплекті. Вам не потрібно нічого встановлювати; його активує налаштування `channels.matrix.*` (див. [Налаштування](#setup)).

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

 ```bash
 openclaw plugins install @openclaw/matrix
-# or, from a local checkout
+# або з локального checkout
 openclaw plugins install ./path/to/local/matrix-plugin
 ```

-`plugins install` реєструє та вмикає plugin, тому окремий крок `openclaw plugins enable matrix` не потрібен. Однак plugin усе одно нічого не робить, доки ви не налаштуєте канал нижче. Див. [Plugins](/uk/tools/plugin) для загальної поведінки plugin та правил встановлення.
+`plugins install` реєструє та вмикає plugin, тому окремий крок `openclaw plugins enable matrix` не потрібен. Однак plugin усе одно нічого не робить, доки ви не налаштуєте канал нижче. Загальну поведінку plugin і правила встановлення див. у [Plugins](/uk/tools/plugin).

 ## Налаштування

 1. Створіть обліковий запис Matrix на вашому homeserver.
-2. Налаштуйте `channels.matrix` за допомогою `homeserver` + `accessToken` або `homeserver` + `userId` + `password`.
+2. Налаштуйте `channels.matrix`, використовуючи або `homeserver` + `accessToken`, або `homeserver` + `userId` + `password`.
 3. Перезапустіть Gateway.
-4. Почніть DM з ботом або запросіть його до кімнати (див. [автоприєднання](#auto-join) — нові запрошення спрацьовують, лише якщо це дозволяє `autoJoin`).
+4. Почніть DM із ботом або запросіть його до кімнати (див. [автоприєднання](#auto-join) — нові запрошення спрацьовують лише тоді, коли це дозволяє `autoJoin`).

 ### Інтерактивне налаштування

@ -44,9 +44,9 @@ openclaw channels add
 openclaw configure --section channels
 ```

-Майстер запитує: URL homeserver, метод автентифікації (токен доступу або пароль), ID користувача (лише для автентифікації паролем), необов’язкову назву пристрою, чи потрібно ввімкнути E2EE, а також чи потрібно налаштувати доступ до кімнат і автоприєднання.
+Майстер запитує: URL homeserver, метод автентифікації (токен доступу або пароль), ID користувача (лише для автентифікації паролем), необов’язкову назву пристрою, чи вмикати E2EE, і чи налаштовувати доступ до кімнат та автоприєднання.

-Якщо відповідні змінні середовища `MATRIX_*` уже існують і для вибраного облікового запису немає збереженої автентифікації, майстер запропонує скористатися env-var shortcut. Щоб визначити назви кімнат перед збереженням allowlist, виконайте `openclaw channels resolve --channel matrix "Project Room"`. Якщо E2EE увімкнено, майстер записує конфігурацію та запускає той самий bootstrap, що й [`openclaw matrix encryption setup`](#encryption-and-verification).
+Якщо відповідні змінні середовища `MATRIX_*` уже існують і для вибраного облікового запису немає збереженої автентифікації, майстер запропонує скористатися змінними середовища. Щоб визначити імена кімнат перед збереженням allowlist, виконайте `openclaw channels resolve --channel matrix "Project Room"`. Якщо E2EE увімкнено, майстер записує конфігурацію та запускає той самий bootstrap, що й [`openclaw matrix encryption setup`](#encryption-and-verification).

 ### Мінімальна конфігурація

@ -83,14 +83,14 @@ openclaw configure --section channels

 ### Автоприєднання

-Значення `channels.matrix.autoJoin` за замовчуванням — `off`. За цього типового налаштування бот не з’являтиметься в нових кімнатах або DM із нових запрошень, доки ви не приєднаєте його вручну.
+`channels.matrix.autoJoin` за замовчуванням має значення `off`. За цього стандартного значення бот не з’являтиметься в нових кімнатах або DM із нових запрошень, доки ви не приєднаєтеся вручну.

-OpenClaw не може визначити в момент запрошення, чи запрошена кімната є DM чи групою, тому всі запрошення — включно із запрошеннями у стилі DM — спочатку проходять через `autoJoin`. `dm.policy` застосовується лише пізніше, після того як бот уже приєднався й кімнату було класифіковано.
+OpenClaw не може визначити під час запрошення, чи є запрошена кімната DM чи групою, тому всі запрошення — включно із запрошеннями у стилі DM — спочатку проходять через `autoJoin`. `dm.policy` застосовується лише пізніше, після того як бот приєднався, а кімната була класифікована.

 <Warning>
 Установіть `autoJoin: "allowlist"` разом із `autoJoinAllowlist`, щоб обмежити, які запрошення бот приймає, або `autoJoin: "always"`, щоб приймати кожне запрошення.

-`autoJoinAllowlist` приймає лише стабільні цілі: `!roomId:server`, `#alias:server` або `*`. Звичайні назви кімнат відхиляються; записи alias визначаються через homeserver, а не за станом, заявленим запрошеною кімнатою.
+`autoJoinAllowlist` приймає лише стабільні цілі: `!roomId:server`, `#alias:server` або `*`. Звичайні назви кімнат відхиляються; записи alias зіставляються через homeserver, а не через стан, заявлений запрошеною кімнатою.
 </Warning>

 ```json5
@ -107,18 +107,18 @@ OpenClaw не може визначити в момент запрошення,
 }
 ```

-Щоб приймати кожне запрошення, використовуйте `autoJoin: "always"`.
+Щоб приймати всі запрошення, використовуйте `autoJoin: "always"`.

 ### Формати цілей allowlist

-Списки дозволів для DM і кімнат найкраще заповнювати стабільними ID:
+Allowlist для DM і кімнат найкраще заповнювати стабільними ID:

 - DM (`dm.allowFrom`, `groupAllowFrom`, `groups.<room>.users`): використовуйте `@user:server`. Відображувані імена визначаються лише тоді, коли каталог homeserver повертає рівно один збіг.
- Кімнати (`groups`, `autoJoinAllowlist`): використовуйте `!room:server` або `#alias:server`. Імена визначаються best-effort за приєднаними кімнатами; нерозпізнані записи ігноруються під час виконання.
+- Кімнати (`groups`, `autoJoinAllowlist`): використовуйте `!room:server` або `#alias:server`. Імена зіставляються best-effort із приєднаними кімнатами; записи, які не вдалося зіставити, ігноруються під час виконання.

 ### Нормалізація ID облікового запису

-Майстер перетворює дружню назву на нормалізований ID облікового запису. Наприклад, `Ops Bot` стає `ops-bot`. Пунктуація екранується в scoped назвах env-var, щоб два облікові записи не конфліктували: `-` → `_X2D_`, тож `ops-prod` відповідає `MATRIX_OPS_X2D_PROD_*`.
+Майстер перетворює зрозумілу назву на нормалізований ID облікового запису. Наприклад, `Ops Bot` стає `ops-bot`. Пунктуація екранується в scoped-іменах змінних середовища, щоб два облікові записи не конфліктували: `-` → `_X2D_`, тому `ops-prod` відповідає `MATRIX_OPS_X2D_PROD_*`.

 ### Кешовані облікові дані

@ -127,25 +127,25 @@ Matrix зберігає кешовані облікові дані в `~/.opencl
 - обліковий запис за замовчуванням: `credentials.json`
 - іменовані облікові записи: `credentials-<account>.json`

-Коли там існують кешовані облікові дані, OpenClaw вважає Matrix налаштованим, навіть якщо токена доступу немає у файлі конфігурації — це стосується налаштування, `openclaw doctor` і перевірок стану каналу.
+Якщо там існують кешовані облікові дані, OpenClaw вважає Matrix налаштованим, навіть якщо токена доступу немає у файлі конфігурації — це охоплює налаштування, `openclaw doctor` і перевірки статусу каналу.

 ### Змінні середовища

-Використовуються, коли еквівалентний ключ конфігурації не задано. Обліковий запис за замовчуванням використовує назви без префікса; іменовані облікові записи використовують ID облікового запису, вставлений перед суфіксом.
+Використовуються, коли еквівалентний ключ конфігурації не задано. Для облікового запису за замовчуванням використовуються імена без префікса; для іменованих облікових записів перед суфіксом вставляється ID облікового запису.

-| Обліковий запис за замовчуванням | Іменований обліковий запис (`<ID>` — нормалізований ID облікового запису) |
-| ------------------------------- | -------------------------------------------------------------------------- |
-| `MATRIX_HOMESERVER`             | `MATRIX_<ID>_HOMESERVER`                                                   |
-| `MATRIX_ACCESS_TOKEN`           | `MATRIX_<ID>_ACCESS_TOKEN`                                                 |
-| `MATRIX_USER_ID`                | `MATRIX_<ID>_USER_ID`                                                      |
-| `MATRIX_PASSWORD`               | `MATRIX_<ID>_PASSWORD`                                                     |
-| `MATRIX_DEVICE_ID`              | `MATRIX_<ID>_DEVICE_ID`                                                    |
-| `MATRIX_DEVICE_NAME`            | `MATRIX_<ID>_DEVICE_NAME`                                                  |
-| `MATRIX_RECOVERY_KEY`           | `MATRIX_<ID>_RECOVERY_KEY`                                                 |
+| Обліковий запис за замовчуванням | Іменований обліковий запис (`<ID>` — це нормалізований ID облікового запису) |
+| ------------------------------- | ----------------------------------------------------------------------------- |
+| `MATRIX_HOMESERVER`             | `MATRIX_<ID>_HOMESERVER`                                                      |
+| `MATRIX_ACCESS_TOKEN`           | `MATRIX_<ID>_ACCESS_TOKEN`                                                    |
+| `MATRIX_USER_ID`                | `MATRIX_<ID>_USER_ID`                                                         |
+| `MATRIX_PASSWORD`               | `MATRIX_<ID>_PASSWORD`                                                        |
+| `MATRIX_DEVICE_ID`              | `MATRIX_<ID>_DEVICE_ID`                                                       |
+| `MATRIX_DEVICE_NAME`            | `MATRIX_<ID>_DEVICE_NAME`                                                     |
+| `MATRIX_RECOVERY_KEY`           | `MATRIX_<ID>_RECOVERY_KEY`                                                    |

-Для облікового запису `ops` назви стають `MATRIX_OPS_HOMESERVER`, `MATRIX_OPS_ACCESS_TOKEN` тощо. Змінні середовища recovery key зчитуються CLI-потоками, які підтримують відновлення (`verify backup restore`, `verify device`, `verify bootstrap`), коли ви передаєте ключ через `--recovery-key-stdin`.
+Для облікового запису `ops` назви стають `MATRIX_OPS_HOMESERVER`, `MATRIX_OPS_ACCESS_TOKEN` і так далі. Змінні середовища recovery key зчитуються recovery-aware потоками CLI (`verify backup restore`, `verify device`, `verify bootstrap`), коли ви передаєте ключ через `--recovery-key-stdin`.

-`MATRIX_HOMESERVER` не можна задавати з робочого `.env`; див. [Файли `.env` робочого простору](/uk/gateway/security).
+`MATRIX_HOMESERVER` не можна задати з робочого `.env`; див. [Файли `.env` робочого простору](/uk/gateway/security).

 ## Приклад конфігурації

@ -184,7 +184,7 @@ Matrix зберігає кешовані облікові дані в `~/.opencl

 ## Попередній перегляд потокових відповідей

-Потокова передача відповідей у Matrix є опціональною. `streaming` керує тим, як OpenClaw доставляє проміжну відповідь асистента; `blockStreaming` визначає, чи зберігати кожен завершений блок як окреме повідомлення Matrix.
+Потокова передача відповідей Matrix opt-in. `streaming` визначає, як OpenClaw доставляє відповідь асистента в процесі генерації; `blockStreaming` визначає, чи зберігається кожен завершений блок як окреме повідомлення Matrix.

 ```json5
 {
@ -196,30 +196,36 @@ Matrix зберігає кешовані облікові дані в `~/.opencl
 }
 ```

-| `streaming`       | Поведінка                                                                                                                                                           |
-| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `"off"` (default) | Очікує повну відповідь і надсилає один раз. `true` ↔ `"partial"`, `false` ↔ `"off"`.                                                                               |
-| `"partial"`       | Редагує одне звичайне текстове повідомлення на місці, поки модель пише поточний блок. Стандартні клієнти Matrix можуть надсилати сповіщення про перший попередній перегляд, а не про фінальне редагування. |
-| `"quiet"`         | Те саме, що й `"partial"`, але повідомлення є notice без сповіщення. Одержувачі отримують сповіщення лише тоді, коли для фіналізованого редагування спрацьовує правило push для конкретного користувача (див. нижче). |
+| `streaming`       | Поведінка                                                                                                                                                              |
+| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `"off"` (типово)  | Дочекатися повної відповіді та надіслати один раз. `true` ↔ `"partial"`, `false` ↔ `"off"`.                                                                          |
+| `"partial"`       | Редагувати одне звичайне текстове повідомлення на місці, поки модель записує поточний блок. Стандартні клієнти Matrix можуть сповістити про перший попередній перегляд, а не про фінальне редагування. |
+| `"quiet"`         | Те саме, що й `"partial"`, але повідомлення є notice без сповіщення. Одержувачі отримають сповіщення лише тоді, коли правилу push для користувача відповідатиме фіналізоване редагування (див. нижче). |

 `blockStreaming` не залежить від `streaming`:

-| `streaming`             | `blockStreaming: true`                                              | `blockStreaming: false` (default)                    |
-| ----------------------- | ------------------------------------------------------------------- | ---------------------------------------------------- |
-| `"partial"` / `"quiet"` | Живий чернетковий варіант поточного блоку, завершені блоки зберігаються як повідомлення | Живий чернетковий варіант поточного блоку, фіналізується на місці |
-| `"off"`                 | Одне повідомлення Matrix зі сповіщенням на кожен завершений блок    | Одне повідомлення Matrix зі сповіщенням для всієї відповіді      |
+| `streaming`             | `blockStreaming: true`                                              | `blockStreaming: false` (типово)                    |
+| ----------------------- | ------------------------------------------------------------------- | --------------------------------------------------- |
+| `"partial"` / `"quiet"` | Жива чернетка для поточного блоку, завершені блоки зберігаються як повідомлення | Жива чернетка для поточного блоку, фіналізується на місці |
+| `"off"`                 | Одне повідомлення Matrix зі сповіщенням на кожен завершений блок    | Одне повідомлення Matrix зі сповіщенням для всієї відповіді |

 Примітки:

- Якщо попередній перегляд перевищує ліміт Matrix на розмір події, OpenClaw припиняє потокову передачу попереднього перегляду й переходить до доставки лише фінальної відповіді.
- Відповіді з медіа завжди надсилають вкладення у звичайному режимі. Якщо застарілий попередній перегляд більше не можна безпечно повторно використати, OpenClaw редагує його перед надсиланням фінальної відповіді з медіа.
- Редагування попереднього перегляду потребує додаткових викликів API Matrix. Залишайте `streaming: "off"`, якщо вам потрібен найконсервативніший профіль обмеження швидкості.
+- Якщо попередній перегляд перевищує ліміт Matrix на розмір однієї події, OpenClaw припиняє потоковий попередній перегляд і переходить до доставки лише фінальної відповіді.
+- Медіавідповіді завжди надсилають вкладення звичайним способом. Якщо застарілий попередній перегляд більше не можна безпечно повторно використати, OpenClaw редагує його перед надсиланням фінальної медіавідповіді.
+- Редагування попереднього перегляду потребує додаткових викликів API Matrix. Залиште `streaming: "off"`, якщо хочете найконсервативніший профіль обмеження частоти запитів.

-### Самостійно розміщені правила push для тихих фіналізованих попередніх переглядів
+## Метадані схвалення

-`streaming: "quiet"` сповіщає одержувачів лише після фіналізації блоку або ходу — правило push для конкретного користувача має збігтися з маркером фіналізованого попереднього перегляду. Повний рецепт див. у [Правилах push Matrix для тихих попередніх переглядів](/uk/channels/matrix-push-rules) (токен одержувача, перевірка pusher, встановлення правил, примітки для окремих homeserver).
+Власні запити на схвалення Matrix — це звичайні події `m.room.message` із OpenClaw-специфічним вмістом кастомної події в `com.openclaw.approval`. Matrix дозволяє кастомні ключі у вмісті подій, тому стандартні клієнти все одно відображають текст повідомлення, а клієнти з підтримкою OpenClaw можуть читати структурований ID схвалення, тип, стан, доступні рішення та деталі exec/plugin.

-## Кімнати бот-бот
+Коли запит на схвалення надто довгий для однієї події Matrix, OpenClaw розбиває видимий текст на частини й додає `com.openclaw.approval` лише до першої частини. Реакції для рішень allow/deny прив’язуються до цієї першої події, тому довгі запити мають ту саму ціль схвалення, що й запити з однією подією.
+
+### Self-hosted правила push для тихих фіналізованих попередніх переглядів
+
+`streaming: "quiet"` сповіщає одержувачів лише після того, як блок або хід буде фіналізовано — правило push для користувача має відповідати маркеру фіналізованого попереднього перегляду. Повний рецепт див. у [Правила push Matrix для тихих попередніх переглядів](/uk/channels/matrix-push-rules) (токен одержувача, перевірка pusher, установлення правила, примітки для окремих homeserver).
+
+## Кімнати бот-до-бота

 За замовчуванням повідомлення Matrix від інших налаштованих облікових записів OpenClaw Matrix ігноруються.

@ -240,19 +246,19 @@ Matrix зберігає кешовані облікові дані в `~/.opencl
 }
 ```

- `allowBots: true` приймає повідомлення від інших налаштованих облікових записів ботів Matrix у дозволених кімнатах і DM.
- `allowBots: "mentions"` приймає ці повідомлення лише тоді, коли вони явно згадують цього бота в кімнатах. DM усе одно дозволені.
+- `allowBots: true` приймає повідомлення від інших налаштованих бот-акаунтів Matrix у дозволених кімнатах і DM.
+- `allowBots: "mentions"` приймає такі повідомлення лише тоді, коли вони явно згадують цього бота в кімнатах. DM усе одно дозволені.
 - `groups.<room>.allowBots` перевизначає налаштування рівня облікового запису для однієї кімнати.
- OpenClaw усе одно ігнорує повідомлення від того самого Matrix user ID, щоб уникнути циклів самовідповідей.
- Matrix тут не надає нативного прапорця бота; OpenClaw трактує «створене ботом» як «надіслане іншим налаштованим обліковим записом Matrix на цьому Gateway OpenClaw».
+- OpenClaw однаково ігнорує повідомлення від того самого ID користувача Matrix, щоб уникнути циклів самовідповідей.
+- Matrix тут не надає власного прапорця бота; OpenClaw трактує "bot-authored" як "надіслане іншим налаштованим обліковим записом Matrix на цьому Gateway OpenClaw".

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

 ## Шифрування та верифікація

-У зашифрованих (E2EE) кімнатах вихідні події зображень використовують `thumbnail_file`, тому попередні перегляди зображень шифруються разом із повним вкладенням. Незашифровані кімнати, як і раніше, використовують звичайний `thumbnail_url`. Жодної конфігурації не потрібно — plugin автоматично визначає стан E2EE.
+У зашифрованих кімнатах (E2EE) вихідні події зображень використовують `thumbnail_file`, тому попередні перегляди зображень шифруються разом із повним вкладенням. Незашифровані кімнати, як і раніше, використовують звичайний `thumbnail_url`. Нічого налаштовувати не потрібно — plugin автоматично визначає стан E2EE.

-Усі команди `openclaw matrix` приймають `--verbose` (повна діагностика), `--json` (машиночитаний вивід) і `--account <id>` (для конфігурацій із кількома обліковими записами). За замовчуванням вивід стислий, із тихим внутрішнім логуванням SDK. У прикладах нижче показано канонічну форму; за потреби додайте прапорці.
+Усі команди `openclaw matrix` підтримують `--verbose` (повна діагностика), `--json` (машиночитаний вивід) і `--account <id>` (багатооблікові конфігурації). За замовчуванням вивід стислий, а внутрішнє логування SDK — тихе. У прикладах нижче показано канонічну форму; за потреби додавайте прапорці.

 ### Увімкнення шифрування

@ -260,12 +266,12 @@ Matrix зберігає кешовані облікові дані в `~/.opencl
 openclaw matrix encryption setup
 ```

-Виконує bootstrap secret storage і cross-signing, за потреби створює резервну копію ключів кімнати, а потім виводить статус і наступні кроки. Корисні прапорці:
+Виконує bootstrap secret storage і cross-signing, за потреби створює резервну копію ключів кімнат, а потім виводить статус і наступні кроки. Корисні прапорці:

- `--recovery-key <key>` застосувати recovery key перед bootstrap (краще використовувати форму stdin, задокументовану нижче)
- `--force-reset-cross-signing` відкинути поточну ідентичність cross-signing і створити нову (використовуйте лише навмисно)
+- `--recovery-key <key>` застосувати recovery key перед bootstrap (бажано використовувати форму через stdin, задокументовану нижче)
+- `--force-reset-cross-signing` відкинути поточну identity cross-signing і створити нову (використовуйте лише свідомо)

-Для нового облікового запису ввімкніть E2EE під час створення:
+Для нового облікового запису увімкніть E2EE під час створення:

 ```bash
 openclaw matrix account add \
@ -274,7 +280,7 @@ openclaw matrix account add \
  --enable-e2ee
 ```

-`--encryption` є псевдонімом для `--enable-e2ee`.
+`--encryption` — це псевдонім для `--enable-e2ee`.

 Еквівалент ручної конфігурації:

@ -301,17 +307,17 @@ openclaw matrix verify status --include-recovery-key --json

 `verify status` повідомляє про три незалежні сигнали довіри (`--verbose` показує всі):

- `Locally trusted`: довіряється лише цим клієнтом
+- `Locally trusted`: довірено лише цим клієнтом
 - `Cross-signing verified`: SDK повідомляє про верифікацію через cross-signing
 - `Signed by owner`: підписано вашим власним self-signing key (лише для діагностики)

-`Verified by owner` стає `yes` лише тоді, коли `Cross-signing verified` має значення `yes`. Локальної довіри або лише підпису власника недостатньо.
+`Verified by owner` стає `yes` лише тоді, коли `Cross-signing verified` має значення `yes`. Локальної довіри або лише підпису owner недостатньо.

-`--allow-degraded-local-state` повертає best-effort діагностику без попередньої підготовки облікового запису Matrix; це корисно для офлайн-перевірок або частково налаштованих probe.
+`--allow-degraded-local-state` повертає best-effort діагностику без попередньої підготовки облікового запису Matrix; корисно для офлайн- або частково налаштованих перевірок.

 ### Верифікація цього пристрою за допомогою recovery key

-Recovery key є чутливим — передавайте його через stdin, а не в командному рядку. Установіть `MATRIX_RECOVERY_KEY` (або `MATRIX_<ID>_RECOVERY_KEY` для іменованого облікового запису):
+Recovery key є чутливим — передавайте його через stdin замість командного рядка. Установіть `MATRIX_RECOVERY_KEY` (або `MATRIX_<ID>_RECOVERY_KEY` для іменованого облікового запису):

 ```bash
 printf '%s\n' "$MATRIX_RECOVERY_KEY" | openclaw matrix verify device --recovery-key-stdin
@ -320,18 +326,18 @@ printf '%s\n' "$MATRIX_RECOVERY_KEY" | openclaw matrix verify device --recovery-
 Команда повідомляє про три стани:

 - `Recovery key accepted`: Matrix прийняв ключ для secret storage або довіри до пристрою.
- `Backup usable`: резервну копію ключів кімнати можна завантажити за допомогою довіреного recovery material.
- `Device verified by owner`: цей пристрій має повну довіру до Matrix cross-signing identity.
+- `Backup usable`: резервну копію ключів кімнат можна завантажити за допомогою довіреного recovery material.
+- `Device verified by owner`: цей пристрій має повну довіру до identity Matrix cross-signing.

-Команда завершується з ненульовим кодом, якщо повна довіра до identity не завершена, навіть якщо recovery key розблокував матеріали резервної копії. У такому разі завершіть self-verification з іншого клієнта Matrix:
+Вона завершується з ненульовим кодом, якщо повна довіра до identity не завершена, навіть якщо recovery key розблокував матеріал резервної копії. У такому разі завершіть self-verification з іншого клієнта Matrix:

 ```bash
 openclaw matrix verify self
 ```

-`verify self` очікує `Cross-signing verified: yes`, перш ніж успішно завершитися. Використовуйте `--timeout-ms <ms>`, щоб налаштувати очікування.
+`verify self` очікує на `Cross-signing verified: yes`, перш ніж успішно завершитися. Використовуйте `--timeout-ms <ms>`, щоб налаштувати очікування.

-Форма з буквальним ключем `openclaw matrix verify device "<recovery-key>"` також підтримується, але ключ потрапляє в історію вашої оболонки.
+Форма з буквальним ключем `openclaw matrix verify device "<recovery-key>"` також підтримується, але ключ потрапить в історію shell.

 ### Bootstrap або відновлення cross-signing

@ -339,38 +345,38 @@ openclaw matrix verify self
 openclaw matrix verify bootstrap
 ```

-`verify bootstrap` — це команда відновлення й налаштування для зашифрованих облікових записів. По черзі вона:
+`verify bootstrap` — це команда відновлення та налаштування для зашифрованих облікових записів. Послідовно вона:

 - виконує bootstrap secret storage, повторно використовуючи наявний recovery key, коли це можливо
 - виконує bootstrap cross-signing і завантажує відсутні публічні ключі
- позначає поточний пристрій і виконує cross-signing
- створює серверну резервну копію ключів кімнати, якщо її ще не існує
+- позначає та cross-signs поточний пристрій
+- створює серверну резервну копію ключів кімнат, якщо її ще не існує

-Якщо homeserver вимагає UIA для завантаження ключів cross-signing, OpenClaw спочатку намагається без автентифікації, потім `m.login.dummy`, а потім `m.login.password` (потрібен `channels.matrix.password`).
+Якщо homeserver вимагає UIA для завантаження ключів cross-signing, OpenClaw спочатку пробує без автентифікації, потім `m.login.dummy`, потім `m.login.password` (потребує `channels.matrix.password`).

 Корисні прапорці:

 - `--recovery-key-stdin` (у парі з `printf '%s\n' "$MATRIX_RECOVERY_KEY" | …`) або `--recovery-key <key>`
- `--force-reset-cross-signing`, щоб відкинути поточну cross-signing identity (лише за свідомого наміру)
+- `--force-reset-cross-signing`, щоб відкинути поточну identity cross-signing (лише свідомо)

-### Резервна копія ключів кімнати
+### Резервне копіювання ключів кімнат

 ```bash
 openclaw matrix verify backup status
 printf '%s\n' "$MATRIX_RECOVERY_KEY" | openclaw matrix verify backup restore --recovery-key-stdin
 ```

-`backup status` показує, чи існує серверна резервна копія і чи може цей пристрій її розшифрувати. `backup restore` імпортує збережені резервні ключі кімнат у локальне криптосховище; якщо recovery key уже є на диску, `--recovery-key-stdin` можна не вказувати.
+`backup status` показує, чи існує серверна резервна копія і чи може цей пристрій її розшифрувати. `backup restore` імпортує резервні ключі кімнат у локальне crypto store; якщо recovery key уже збережено на диску, можна не вказувати `--recovery-key-stdin`.

-Щоб замінити зламану резервну копію новою базовою версією (допускає втрату невідновлюваної старої історії; також може повторно створити secret storage, якщо поточний backup secret неможливо завантажити):
+Щоб замінити зламану резервну копію новою базовою копією (допускає втрату старої історії, яку неможливо відновити; також може заново створити secret storage, якщо поточний секрет резервної копії неможливо завантажити):

 ```bash
 openclaw matrix verify backup reset --yes
 ```

-Додавайте `--rotate-recovery-key` лише тоді, коли ви свідомо хочете, щоб попередній recovery key більше не розблоковував нову базову резервну копію.
+Додавайте `--rotate-recovery-key` лише тоді, коли свідомо хочете, щоб попередній recovery key більше не розблоковував нову базову резервну копію.

-### Перелік, запит і відповідь на верифікації
+### Перелік, запит і відповіді на верифікації

 ```bash
 openclaw matrix verify list
@ -383,46 +389,46 @@ openclaw matrix verify request --own-user
 openclaw matrix verify request --user-id @ops:example.org --device-id ABCDEF
 ```

-Надсилає запит на верифікацію з цього облікового запису OpenClaw. `--own-user` запитує self-verification (ви приймаєте запрошення в іншому клієнті Matrix того самого користувача); `--user-id`/`--device-id`/`--room-id` націлюють запит на іншу особу. `--own-user` не можна поєднувати з іншими прапорцями націлювання.
+Надсилає запит на верифікацію з цього облікового запису OpenClaw. `--own-user` запитує self-verification (ви приймаєте запит в іншому клієнті Matrix того самого користувача); `--user-id`/`--device-id`/`--room-id` націлюються на когось іншого. `--own-user` не можна поєднувати з іншими прапорцями націлювання.

-Для обробки життєвого циклу на нижчому рівні — зазвичай під час супроводу вхідних запитів з іншого клієнта — ці команди працюють із конкретним запитом `<id>` (виводиться командами `verify list` і `verify request`):
+Для обробки lifecycle на нижчому рівні — зазвичай коли ви відстежуєте вхідні запити з іншого клієнта — ці команди працюють із конкретним запитом `<id>` (виводиться командами `verify list` і `verify request`):

-| Команда                                    | Призначення                                                          |
-| ------------------------------------------ | -------------------------------------------------------------------- |
-| `openclaw matrix verify accept <id>`       | Прийняти вхідний запит                                               |
-| `openclaw matrix verify start <id>`        | Запустити потік SAS                                                  |
-| `openclaw matrix verify sas <id>`          | Показати емодзі SAS або десяткові числа                              |
-| `openclaw matrix verify confirm-sas <id>`  | Підтвердити, що SAS збігається з тим, що показує інший клієнт        |
-| `openclaw matrix verify mismatch-sas <id>` | Відхилити SAS, якщо емодзі або десяткові числа не збігаються         |
+| Команда                                    | Призначення                                                        |
+| ------------------------------------------ | ------------------------------------------------------------------ |
+| `openclaw matrix verify accept <id>`       | Прийняти вхідний запит                                             |
+| `openclaw matrix verify start <id>`        | Запустити SAS flow                                                 |
+| `openclaw matrix verify sas <id>`          | Вивести SAS emoji або десяткові числа                              |
+| `openclaw matrix verify confirm-sas <id>`  | Підтвердити, що SAS збігається з тим, що показує інший клієнт      |
+| `openclaw matrix verify mismatch-sas <id>` | Відхилити SAS, якщо emoji або десяткові числа не збігаються        |
 | `openclaw matrix verify cancel <id>`       | Скасувати; приймає необов’язкові `--reason <text>` і `--code <matrix-code>` |

-`accept`, `start`, `sas`, `confirm-sas`, `mismatch-sas` і `cancel` також приймають `--user-id` і `--room-id` як підказки для продовження в DM, коли верифікація прив’язана до певної кімнати прямих повідомлень.
+`accept`, `start`, `sas`, `confirm-sas`, `mismatch-sas` і `cancel` також приймають `--user-id` і `--room-id` як підказки для подальших дій у DM, коли верифікація прив’язана до конкретної кімнати прямого повідомлення.

 ### Примітки щодо кількох облікових записів

-Без `--account <id>` команди Matrix CLI використовують неявний обліковий запис за замовчуванням. Якщо у вас є кілька іменованих облікових записів і не задано `channels.matrix.defaultAccount`, вони не будуть вгадувати й попросять вас вибрати. Коли E2EE вимкнено або недоступне для іменованого облікового запису, помилки вказують на ключ конфігурації цього облікового запису, наприклад `channels.matrix.accounts.assistant.encryption`.
+Без `--account <id>` команди Matrix CLI використовують неявний обліковий запис за замовчуванням. Якщо у вас кілька іменованих облікових записів і не задано `channels.matrix.defaultAccount`, вони не намагатимуться вгадувати й попросять вас вибрати. Коли E2EE вимкнено або недоступне для іменованого облікового запису, помилки вказують на ключ конфігурації цього облікового запису, наприклад `channels.matrix.accounts.assistant.encryption`.

 <AccordionGroup>
  <Accordion title="Поведінка під час запуску">
-    Якщо `encryption: true`, значення `startupVerification` за замовчуванням — `"if-unverified"`. Під час запуску неперевірений пристрій запитує self-verification в іншому клієнті Matrix, пропускаючи дублікати й застосовуючи cooldown (24 години за замовчуванням). Налаштуйте через `startupVerificationCooldownHours` або вимкніть за допомогою `startupVerification: "off"`.
+    Із `encryption: true` значення `startupVerification` за замовчуванням — `"if-unverified"`. Під час запуску неперевірений пристрій запитує self-verification в іншому клієнті Matrix, пропускаючи дублікати й застосовуючи cooldown (24 години за замовчуванням). Налаштуйте через `startupVerificationCooldownHours` або вимкніть через `startupVerification: "off"`.

-    Під час запуску також виконується консервативний bootstrap криптографії, який повторно використовує поточні secret storage і cross-signing identity. Якщо стан bootstrap пошкоджений, OpenClaw намагається виконати захищене відновлення навіть без `channels.matrix.password`; якщо homeserver вимагає password UIA, під час запуску журналюється попередження, але це не є фатальним. Пристрої, уже підписані власником, зберігаються.
+    Під час запуску також виконується консервативний прохід bootstrap crypto, який повторно використовує поточні secret storage та identity cross-signing. Якщо стан bootstrap зламано, OpenClaw намагається виконати захищене відновлення навіть без `channels.matrix.password`; якщо homeserver вимагає password UIA, під час запуску записується попередження, але це не є фатальною помилкою. Пристрої, уже підписані owner, зберігаються.

-    Див. [Міграція Matrix](/uk/channels/matrix-migration), щоб ознайомитися з повним потоком оновлення.
+    Повний процес оновлення див. у [Міграція Matrix](/uk/channels/matrix-migration).

  </Accordion>

  <Accordion title="Сповіщення про верифікацію">
-    Matrix публікує сповіщення про життєвий цикл верифікації в сувору DM-кімнату верифікації як повідомлення `m.notice`: запит, готовність (із підказкою «Verify by emoji»), початок/завершення, а також деталі SAS (емодзі/десяткові числа), коли вони доступні.
+    Matrix публікує сповіщення lifecycle верифікації у строгій DM-кімнаті верифікації як повідомлення `m.notice`: запит, готовність (із підказкою "Verify by emoji"), початок/завершення та деталі SAS (emoji/десяткові числа), коли доступні.

-    Вхідні запити з іншого клієнта Matrix відстежуються й автоматично приймаються. Для self-verification OpenClaw автоматично запускає потік SAS і підтверджує свій бік, щойно стає доступною верифікація за емодзі — вам усе одно потрібно порівняти й підтвердити «They match» у вашому клієнті Matrix.
+    Вхідні запити з іншого клієнта Matrix відстежуються та автоматично приймаються. Для self-verification OpenClaw автоматично запускає SAS flow і підтверджує свій бік, щойно стає доступною верифікація emoji — вам усе одно потрібно порівняти й підтвердити "They match" у вашому клієнті Matrix.

    Системні сповіщення про верифікацію не пересилаються в pipeline чату агента.

  </Accordion>

  <Accordion title="Видалений або недійсний пристрій Matrix">
-    Якщо `verify status` повідомляє, що поточний пристрій більше не значиться на homeserver, створіть новий пристрій Matrix для OpenClaw. Для входу за паролем:
+    Якщо `verify status` повідомляє, що поточний пристрій більше не відображається на homeserver, створіть новий пристрій OpenClaw Matrix. Для входу за паролем:

 ```bash
 openclaw matrix account add \
@ -433,7 +439,7 @@ openclaw matrix account add \
  --device-name OpenClaw-Gateway
 ```

-    Для автентифікації токеном створіть новий токен доступу у вашому клієнті Matrix або UI адміністратора, а потім оновіть OpenClaw:
+    Для автентифікації токеном створіть новий access token у вашому клієнті Matrix або admin UI, а потім оновіть OpenClaw:

 ```bash
 openclaw matrix account add \
@ -442,12 +448,12 @@ openclaw matrix account add \
  --access-token '<token>'
 ```

-    Замініть `assistant` на ID облікового запису з команди, що завершилася помилкою, або пропустіть `--account` для облікового запису за замовчуванням.
+    Замініть `assistant` на ID облікового запису з команди, що завершилася помилкою, або не вказуйте `--account` для облікового запису за замовчуванням.

  </Accordion>

  <Accordion title="Гігієна пристроїв">
-    Старі пристрої під керуванням OpenClaw можуть накопичуватися. Переглядайте список і очищайте:
+    Старі пристрої, якими керує OpenClaw, можуть накопичуватися. Перегляд і очищення:

 ```bash
 openclaw matrix devices list
@ -456,68 +462,68 @@ openclaw matrix devices prune-stale

  </Accordion>

-  <Accordion title="Криптосховище">
-    Matrix E2EE використовує офіційний Rust crypto path із `matrix-js-sdk` з `fake-indexeddb` як shim для IndexedDB. Криптографічний стан зберігається в `crypto-idb-snapshot.json` (з обмежувальними правами доступу до файла).
+  <Accordion title="Crypto store">
+    Matrix E2EE використовує офіційний шлях Rust crypto з `matrix-js-sdk` із `fake-indexeddb` як shim для IndexedDB. Стан crypto зберігається в `crypto-idb-snapshot.json` (із обмежувальними правами доступу до файлу).

-    Зашифрований стан виконання зберігається в `~/.openclaw/matrix/accounts/<account>/<homeserver>__<user>/<token-hash>/` і містить sync store, crypto store, recovery key, знімок IDB, прив’язки тредів і стан startup verification. Коли токен змінюється, але identity облікового запису лишається тією самою, OpenClaw повторно використовує найкращий наявний корінь, щоб попередній стан залишався доступним.
+    Зашифрований стан виконання зберігається в `~/.openclaw/matrix/accounts/<account>/<homeserver>__<user>/<token-hash>/` і містить sync store, crypto store, recovery key, IDB snapshot, thread bindings і стан startup verification. Коли токен змінюється, але identity облікового запису залишається тією самою, OpenClaw повторно використовує найкращий наявний root, щоб попередній стан залишався доступним.

  </Accordion>
 </AccordionGroup>

 ## Керування профілем

-Оновіть власний профіль Matrix для вибраного облікового запису:
+Оновіть self-profile Matrix для вибраного облікового запису:

 ```bash
 openclaw matrix profile set --name "OpenClaw Assistant"
 openclaw matrix profile set --avatar-url https://cdn.example.org/avatar.png
 ```

-Ви можете передати обидва параметри в одному виклику. Matrix безпосередньо приймає URL аватара `mxc://`; якщо ви передаєте `http://` або `https://`, OpenClaw спочатку завантажує файл, а потім зберігає визначений URL `mxc://` у `channels.matrix.avatarUrl` (або в перевизначенні для конкретного облікового запису).
+Ви можете передати обидва параметри одним викликом. Matrix безпосередньо приймає URL аватарів `mxc://`; якщо ви передаєте `http://` або `https://`, OpenClaw спочатку завантажує файл і зберігає визначений URL `mxc://` у `channels.matrix.avatarUrl` (або в перевизначенні для конкретного облікового запису).

 ## Треди

-Matrix підтримує нативні треди Matrix як для автоматичних відповідей, так і для надсилання через message-tool. Поведінку контролюють два незалежні параметри:
+Matrix підтримує нативні треди Matrix як для автоматичних відповідей, так і для надсилань через message-tool. Поведінку керують два незалежні параметри:

 ### Маршрутизація сесій (`sessionScope`)

-`dm.sessionScope` визначає, як DM-кімнати Matrix зіставляються із сесіями OpenClaw:
+`dm.sessionScope` визначає, як DM-кімнати Matrix відображаються на сесії OpenClaw:

- `"per-user"` (default): усі DM-кімнати з тим самим маршрутизованим співрозмовником використовують одну сесію.
+- `"per-user"` (типово): усі DM-кімнати з тим самим маршрутизованим співрозмовником спільно використовують одну сесію.
 - `"per-room"`: кожна DM-кімната Matrix отримує власний ключ сесії, навіть якщо співрозмовник той самий.

-Явні conversation bindings завжди мають пріоритет над `sessionScope`, тому прив’язані кімнати й треди зберігають свою вибрану цільову сесію.
+Явні прив’язки розмов завжди мають пріоритет над `sessionScope`, тому прив’язані кімнати й треди зберігають вибрану цільову сесію.

-### Потоковість відповідей (`threadReplies`)
+### Тредування відповідей (`threadReplies`)

 `threadReplies` визначає, куди бот публікує свою відповідь:

- `"off"`: відповіді верхнього рівня. Вхідні повідомлення в тредах залишаються в батьківській сесії.
+- `"off"`: відповіді верхнього рівня. Вхідні повідомлення в тредах залишаються на батьківській сесії.
 - `"inbound"`: відповідати всередині треду лише тоді, коли вхідне повідомлення вже було в цьому треді.
- `"always"`: відповідати всередині треду, коренем якого є повідомлення-тригер; ця розмова маршрутизується через відповідну сесію з областю треду вже з першого тригера.
+- `"always"`: відповідати всередині треду, коренем якого є повідомлення-тригер; така розмова маршрутизується через відповідну thread-scoped сесію з першого тригера й далі.

-`dm.threadReplies` перевизначає це лише для DM — наприклад, можна ізолювати треди в кімнатах, залишивши DM пласкими.
+`dm.threadReplies` перевизначає це лише для DM — наприклад, щоб ізолювати треди в кімнатах, але зберегти DM пласкими.

-### Успадкування тредів і slash-команди
+### Успадкування тредів і slash commands

 - Вхідні повідомлення в тредах включають кореневе повідомлення треду як додатковий контекст агента.
- Надсилання через message-tool автоматично успадковує поточний тред Matrix, якщо цілиться в ту саму кімнату (або ту саму ціль DM-користувача), якщо явно не задано `threadId`.
+- Надсилання через message-tool автоматично успадковують поточний тред Matrix, якщо ціль — та сама кімната (або той самий DM-користувач), якщо не вказано явний `threadId`.
 - Повторне використання DM user-target спрацьовує лише тоді, коли метадані поточної сесії підтверджують того самого DM-співрозмовника в тому самому обліковому записі Matrix; інакше OpenClaw повертається до звичайної маршрутизації в межах користувача.
 - `/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age` і прив’язаний до треду `/acp spawn` працюють у кімнатах Matrix і DM.
 - `/focus` верхнього рівня створює новий тред Matrix і прив’язує його до цільової сесії, коли `threadBindings.spawnSubagentSessions: true`.
- Запуск `/focus` або `/acp spawn --thread here` всередині наявного треду Matrix прив’язує цей тред на місці.
+- Виконання `/focus` або `/acp spawn --thread here` всередині наявного треду Matrix прив’язує цей тред на місці.

-Коли OpenClaw виявляє, що DM-кімната Matrix конфліктує з іншою DM-кімнатою в межах тієї самої спільної сесії, він публікує одноразове `m.notice` у цій кімнаті з посиланням на можливість виходу через `/focus` і пропозицією змінити `dm.sessionScope`. Це повідомлення з’являється лише тоді, коли ввімкнено прив’язки тредів.
+Коли OpenClaw виявляє, що DM-кімната Matrix конфліктує з іншою DM-кімнатою в межах тієї самої спільної сесії, він публікує одноразове `m.notice` у цій кімнаті з вказівкою на можливість виходу через `/focus` і пропозицією змінити `dm.sessionScope`. Повідомлення з’являється лише тоді, коли увімкнені прив’язки тредів.

-## Прив’язки розмов ACP
+## ACP-прив’язки розмов

 Кімнати Matrix, DM і наявні треди Matrix можна перетворити на постійні робочі простори ACP без зміни поверхні чату.

 Швидкий операторський сценарій:

- Виконайте `/acp spawn codex --bind here` у Matrix DM, кімнаті або наявному треді, який ви хочете й надалі використовувати.
- У Matrix DM або кімнаті верхнього рівня поточний DM/кімната лишається поверхнею чату, а майбутні повідомлення маршрутизуються до створеної ACP-сесії.
- Усередині наявного треду Matrix `--bind here` прив’язує цей поточний тред на місці.
+- Виконайте `/acp spawn codex --bind here` у Matrix DM, кімнаті або наявному треді, яким ви хочете й надалі користуватися.
+- У Matrix DM або кімнаті верхнього рівня поточний DM/кімната залишається поверхнею чату, а майбутні повідомлення маршрутизуються до створеної ACP-сесії.
+- Усередині наявного треду Matrix `--bind here` прив’язує поточний тред на місці.
 - `/new` і `/reset` скидають ту саму прив’язану ACP-сесію на місці.
 - `/acp close` закриває ACP-сесію та видаляє прив’язку.

@ -528,7 +534,7 @@ Matrix підтримує нативні треди Matrix як для авто

 ### Конфігурація прив’язки тредів

-Matrix успадковує глобальні значення за замовчуванням із `session.threadBindings`, а також підтримує перевизначення для каналу:
+Matrix успадковує глобальні значення за замовчуванням із `session.threadBindings`, а також підтримує перевизначення для окремого каналу:

 - `threadBindings.enabled`
 - `threadBindings.idleHours`
@ -536,7 +542,7 @@ Matrix успадковує глобальні значення за замов
 - `threadBindings.spawnSubagentSessions`
 - `threadBindings.spawnAcpSessions`

-Прапорці створення з прив’язкою до тредів Matrix є опціональними:
+Прапорці запуску з прив’язкою до треду Matrix вмикаються опційно:

 - Установіть `threadBindings.spawnSubagentSessions: true`, щоб дозволити `/focus` верхнього рівня створювати й прив’язувати нові треди Matrix.
 - Установіть `threadBindings.spawnAcpSessions: true`, щоб дозволити `/acp spawn --thread auto|here` прив’язувати ACP-сесії до тредів Matrix.
@ -545,41 +551,41 @@ Matrix успадковує глобальні значення за замов

 Matrix підтримує вихідні реакції, вхідні сповіщення про реакції та реакції-підтвердження.

-Інструментарій вихідних реакцій контролюється параметром `channels.matrix.actions.reactions`:
+Інструменти вихідних реакцій контролюються через `channels.matrix.actions.reactions`:

 - `react` додає реакцію до події Matrix.
- `reactions` показує поточне зведення реакцій для події Matrix.
- `emoji=""` видаляє власні реакції бота для цієї події.
- `remove: true` видаляє лише вказану реакцію-емодзі від бота.
+- `reactions` показує поточний підсумок реакцій для події Matrix.
+- `emoji=""` видаляє власні реакції бота на цю подію.
+- `remove: true` видаляє лише вказану emoji-реакцію від бота.

-**Порядок визначення** (перемагає перше визначене значення):
+**Порядок визначення** (перемагає перше задане значення):

-| Налаштування            | Порядок                                                                         |
-| ----------------------- | ------------------------------------------------------------------------------- |
-| `ackReaction`           | для облікового запису → канал → `messages.ackReaction` → запасний emoji identity агента |
-| `ackReactionScope`      | для облікового запису → канал → `messages.ackReactionScope` → значення за замовчуванням `"group-mentions"` |
-| `reactionNotifications` | для облікового запису → канал → значення за замовчуванням `"own"`               |
+| Налаштування            | Порядок                                                                          |
+| ----------------------- | -------------------------------------------------------------------------------- |
+| `ackReaction`           | для облікового запису → каналу → `messages.ackReaction` → fallback на emoji identity агента |
+| `ackReactionScope`      | для облікового запису → каналу → `messages.ackReactionScope` → типове `"group-mentions"` |
+| `reactionNotifications` | для облікового запису → каналу → типове `"own"`                                  |

-`reactionNotifications: "own"` пересилає додані події `m.reaction`, коли вони націлені на повідомлення Matrix, створені ботом; `"off"` вимикає системні події реакцій. Видалення реакцій не синтезується в системні події, тому що Matrix показує їх як редагування, а не як окремі видалення `m.reaction`.
+`reactionNotifications: "own"` пересилає додані події `m.reaction`, коли вони націлені на повідомлення Matrix, створені ботом; `"off"` вимикає системні події реакцій. Видалення реакцій не синтезується в системні події, тому що Matrix показує їх як редагування, а не як окреме видалення `m.reaction`.

 ## Контекст історії

- `channels.matrix.historyLimit` визначає, скільки останніх повідомлень кімнати включаються як `InboundHistory`, коли повідомлення Matrix у кімнаті запускає агента. Використовує запасне значення `messages.groupChat.historyLimit`; якщо обидва не задані, фактичне значення за замовчуванням — `0`. Установіть `0`, щоб вимкнути.
- Історія кімнати Matrix обмежується лише кімнатою. DM і далі використовують звичайну історію сесії.
- Історія кімнати Matrix працює лише для pending: OpenClaw буферизує повідомлення кімнати, які ще не викликали відповіді, а потім фіксує це вікно, коли надходить згадка чи інший тригер.
- Поточне тригерне повідомлення не включається до `InboundHistory`; воно лишається в основному тілі вхідного повідомлення для цього ходу.
- Повторні спроби тієї самої події Matrix повторно використовують початковий знімок історії, а не зміщуються вперед до новіших повідомлень кімнати.
+- `channels.matrix.historyLimit` визначає, скільки нещодавніх повідомлень кімнати включати як `InboundHistory`, коли повідомлення кімнати Matrix запускає агента. Використовує fallback на `messages.groupChat.historyLimit`; якщо обидва не задані, ефективне значення за замовчуванням — `0`. Установіть `0`, щоб вимкнути.
+- Історія кімнати Matrix стосується лише кімнати. DM і далі використовують звичайну історію сесії.
+- Історія кімнати Matrix є лише pending: OpenClaw буферизує повідомлення кімнати, які ще не запустили відповідь, а потім фіксує це вікно, коли надходить згадка або інший тригер.
+- Поточне повідомлення-тригер не включається до `InboundHistory`; воно залишається в основному вхідному тілі для цього ходу.
+- Повторні спроби для тієї самої події Matrix повторно використовують початковий snapshot історії замість зсуву вперед до новіших повідомлень кімнати.

 ## Видимість контексту

-Matrix підтримує спільний параметр `contextVisibility` для додаткового контексту кімнати, такого як отриманий текст відповіді, корені тредів і відкладена історія.
+Matrix підтримує спільний параметр `contextVisibility` для додаткового контексту кімнати, такого як отриманий текст відповіді, корені тредів і pending history.

 - `contextVisibility: "all"` — значення за замовчуванням. Додатковий контекст зберігається як отримано.
- `contextVisibility: "allowlist"` фільтрує додатковий контекст до відправників, дозволених активними перевірками allowlist для кімнати/користувача.
+- `contextVisibility: "allowlist"` фільтрує додатковий контекст до відправників, дозволених активними перевірками allowlist кімнати/користувача.
 - `contextVisibility: "allowlist_quote"` працює як `allowlist`, але все одно зберігає одну явну цитовану відповідь.

-Цей параметр впливає на видимість додаткового контексту, а не на те, чи може саме вхідне повідомлення викликати відповідь.
-Авторизація тригерів, як і раніше, визначається через налаштування `groupPolicy`, `groups`, `groupAllowFrom` і політики DM.
+Це налаштування впливає на видимість додаткового контексту, а не на те, чи саме вхідне повідомлення може запускати відповідь.
+Авторизація тригера, як і раніше, визначається через `groupPolicy`, `groups`, `groupAllowFrom` і налаштування політики DM.

 ## Політика DM і кімнат

@ -602,7 +608,7 @@ Matrix підтримує спільний параметр `contextVisibility`
 }
 ```

-Щоб повністю заглушити DM, залишивши кімнати працювати, установіть `dm.enabled: false`:
+Щоб повністю заглушити DM, але зберегти роботу кімнат, установіть `dm.enabled: false`:

 ```json5
 {
@ -616,7 +622,7 @@ Matrix підтримує спільний параметр `contextVisibility`
 }
 ```

-Див. [Групи](/uk/channels/groups) для поведінки згадувань і allowlist.
+Поведінку згадок і allowlist див. у [Групи](/uk/channels/groups).

 Приклад pairing для Matrix DM:

@ -627,61 +633,61 @@ openclaw pairing approve matrix <CODE>

 Якщо непідтверджений користувач Matrix продовжує писати вам до схвалення, OpenClaw повторно використовує той самий pending pairing code і може надіслати відповідь-нагадування після короткого cooldown замість створення нового коду.

-Див. [Pairing](/uk/channels/pairing) для спільного потоку pairing у DM і схеми зберігання.
+Спільний процес pairing для DM і структуру зберігання див. у [Pairing](/uk/channels/pairing).

-## Відновлення direct room
+## Відновлення direct-кімнати

-Якщо стан прямих повідомлень виходить із синхронізації, OpenClaw може отримати застарілі прив’язки `m.direct`, які вказують на старі solo rooms замість актуального DM. Перевірте поточну прив’язку для співрозмовника:
+Якщо стан direct-message виходить із синхронізації, OpenClaw може залишитися зі застарілими зіставленнями `m.direct`, які вказують на старі solo-кімнати замість актуального DM. Перегляньте поточне зіставлення для співрозмовника:

 ```bash
 openclaw matrix direct inspect --user-id @alice:example.org
 ```

-Виправте її:
+Відновіть його:

 ```bash
 openclaw matrix direct repair --user-id @alice:example.org
 ```

-Обидві команди приймають `--account <id>` для конфігурацій із кількома обліковими записами. Потік відновлення:
+Обидві команди приймають `--account <id>` для багатооблікових конфігурацій. Процес відновлення:

- надає перевагу строгому DM 1:1, який уже прив’язано в `m.direct`
- за потреби переходить до будь-якого поточного strict 1:1 DM із цим користувачем
- створює нову direct room і переписує `m.direct`, якщо справного DM не існує
+- надає перевагу строгому 1:1 DM, який уже зіставлений у `m.direct`
+- у разі потреби переходить до будь-якого поточного strict 1:1 DM із цим користувачем
+- створює нову direct-кімнату та переписує `m.direct`, якщо здорового DM не існує

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

-## Підтвердження exec
+## Погодження exec

-Matrix може працювати як нативний клієнт підтверджень. Налаштування розміщуються в `channels.matrix.execApprovals` (або в `channels.matrix.accounts.<account>.execApprovals` для перевизначення на рівні облікового запису):
+Matrix може виступати нативним клієнтом погодження. Налаштування виконується через `channels.matrix.execApprovals` (або `channels.matrix.accounts.<account>.execApprovals` для перевизначення на рівні облікового запису):

- `enabled`: доставляти підтвердження через нативні підказки Matrix. Якщо не задано або встановлено `"auto"`, Matrix автоматично вмикається, щойно вдається визначити принаймні одного approver. Установіть `false`, щоб явно вимкнути.
- `approvers`: Matrix user ID (`@owner:example.org`), яким дозволено підтверджувати exec-запити. Необов’язково — використовує запасне значення `channels.matrix.dm.allowFrom`.
- `target`: куди надсилати підказки. `"dm"` (за замовчуванням) надсилає в DM approver; `"channel"` надсилає у вихідну кімнату Matrix або DM; `"both"` надсилає в обидва місця.
- `agentFilter` / `sessionFilter`: необов’язкові allowlist для того, які агенти/сесії запускають доставку через Matrix.
+- `enabled`: доставляти погодження через нативні запити Matrix. Якщо не задано або має значення `"auto"`, Matrix автоматично вмикається, щойно вдається визначити хоча б одного погоджувача. Установіть `false`, щоб явно вимкнути.
+- `approvers`: ID користувачів Matrix (`@owner:example.org`), яким дозволено погоджувати exec-запити. Необов’язково — використовує fallback на `channels.matrix.dm.allowFrom`.
+- `target`: куди надсилаються запити. `"dm"` (типово) надсилає в DM погоджувачів; `"channel"` надсилає у вихідну кімнату або DM Matrix; `"both"` надсилає в обидва місця.
+- `agentFilter` / `sessionFilter`: необов’язкові allowlist для агентів/сесій, які запускають доставку через Matrix.

-Авторизація трохи відрізняється залежно від типу підтвердження:
+Авторизація трохи відрізняється залежно від типу погодження:

- **Exec approvals** використовують `execApprovals.approvers`, із запасним значенням `dm.allowFrom`.
+- **Exec approvals** використовують `execApprovals.approvers`, із fallback на `dm.allowFrom`.
 - **Plugin approvals** авторизуються лише через `dm.allowFrom`.

-Обидва типи використовують спільні shortcut реакцій Matrix та оновлення повідомлень. Approver бачать shortcut реакцій у головному повідомленні підтвердження:
+Обидва типи використовують спільні скорочення реакцій Matrix і оновлення повідомлень. Погоджувачі бачать скорочення реакцій на основному повідомленні погодження:

 - `✅` дозволити один раз
 - `❌` відхилити
 - `♾️` дозволити завжди (коли це дозволяє ефективна політика exec)

-Запасні slash-команди: `/approve <id> allow-once`, `/approve <id> allow-always`, `/approve <id> deny`.
+Резервні slash commands: `/approve <id> allow-once`, `/approve <id> allow-always`, `/approve <id> deny`.

-Лише визначені approver можуть дозволяти або відхиляти. Доставка в канал для exec approvals включає текст команди — вмикайте `channel` або `both` лише в довірених кімнатах.
+Лише визначені погоджувачі можуть схвалювати або відхиляти. Доставка exec approvals у канал містить текст команди — вмикайте `channel` або `both` лише в довірених кімнатах.

-Пов’язано: [Exec approvals](/uk/tools/exec-approvals).
+Пов’язане: [Exec approvals](/uk/tools/exec-approvals).

-## Slash-команди
+## Slash commands

-Slash-команди (`/new`, `/reset`, `/model`, `/focus`, `/unfocus`, `/agents`, `/session`, `/acp`, `/approve` тощо) працюють безпосередньо в DM. У кімнатах OpenClaw також розпізнає команди, перед якими стоїть власна згадка Matrix бота, тому `@bot:server /new` запускає шлях команди без кастомного regex для згадок. Це дає змогу боту залишатися чутливим до повідомлень у стилі кімнат `@mention /command`, які Element та подібні клієнти надсилають, коли користувач доповнює ім’я бота через tab перед введенням команди.
+Slash commands (`/new`, `/reset`, `/model`, `/focus`, `/unfocus`, `/agents`, `/session`, `/acp`, `/approve` тощо) працюють безпосередньо в DM. У кімнатах OpenClaw також розпізнає команди з префіксом власної згадки Matrix бота, тому `@bot:server /new` запускає шлях команди без спеціального regex для згадки. Це дає змогу боту реагувати на повідомлення у стилі кімнати `@mention /command`, які Element та подібні клієнти надсилають, коли користувач автодоповнює бота перед введенням команди.

-Правила авторизації, як і раніше, діють: відправники команд мають відповідати тим самим політикам DM або allowlist/owner для кімнат, що й звичайні повідомлення.
+Правила авторизації все одно застосовуються: відправники команд мають відповідати тим самим політикам allowlist/owner для DM або кімнат, що й для звичайних повідомлень.

 ## Кілька облікових записів

@ -715,26 +721,26 @@ Slash-команди (`/new`, `/reset`, `/model`, `/focus`, `/unfocus`, `/agents

 **Успадкування:**

- Значення верхнього рівня `channels.matrix` працюють як значення за замовчуванням для іменованих облікових записів, якщо обліковий запис не перевизначає їх.
- Щоб обмежити успадкований запис кімнати конкретним обліковим записом, використовуйте `groups.<room>.account`. Записи без `account` спільні для всіх облікових записів; `account: "default"` теж працює, коли обліковий запис за замовчуванням налаштовано на верхньому рівні.
+- Значення верхнього рівня `channels.matrix` працюють як значення за замовчуванням для іменованих облікових записів, якщо обліковий запис не має власного перевизначення.
+- Щоб прив’язати успадкований запис кімнати до конкретного облікового запису, використовуйте `groups.<room>.account`. Записи без `account` спільні для всіх облікових записів; `account: "default"` і далі працює, коли обліковий запис за замовчуванням налаштований на верхньому рівні.

 **Вибір облікового запису за замовчуванням:**

- Установіть `defaultAccount`, щоб вибрати іменований обліковий запис, якому надають перевагу неявна маршрутизація, probe і команди CLI.
- Якщо у вас кілька облікових записів і один із них буквально називається `default`, OpenClaw використовує його неявно, навіть якщо `defaultAccount` не задано.
- Якщо у вас кілька іменованих облікових записів і жоден обліковий запис за замовчуванням не вибрано, команди CLI не будуть вгадувати — установіть `defaultAccount` або передайте `--account <id>`.
- Блок верхнього рівня `channels.matrix.*` розглядається як неявний обліковий запис `default`, лише якщо його автентифікація повна (`homeserver` + `accessToken` або `homeserver` + `userId` + `password`). Іменовані облікові записи залишаються доступними через `homeserver` + `userId`, щойно кешовані облікові дані покривають автентифікацію.
+- Установіть `defaultAccount`, щоб вибрати іменований обліковий запис, якому надають перевагу неявна маршрутизація, перевірки та команди CLI.
+- Якщо у вас кілька облікових записів і один із них буквально має назву `default`, OpenClaw використовує його неявно, навіть якщо `defaultAccount` не задано.
+- Якщо у вас кілька іменованих облікових записів і жоден не вибрано за замовчуванням, команди CLI не намагатимуться вгадувати — установіть `defaultAccount` або передайте `--account <id>`.
+- Блок верхнього рівня `channels.matrix.*` розглядається як неявний обліковий запис `default`, лише якщо його автентифікацію завершено (`homeserver` + `accessToken` або `homeserver` + `userId` + `password`). Іменовані облікові записи залишаються доступними через `homeserver` + `userId`, якщо автентифікацію покривають кешовані облікові дані.

 **Підвищення:**

- Коли OpenClaw під час відновлення або налаштування переводить конфігурацію з одного облікового запису в кілька, він зберігає наявний іменований обліковий запис, якщо такий існує або `defaultAccount` уже вказує на нього. Лише ключі автентифікації/bootstrap Matrix переміщуються до підвищеного облікового запису; спільні ключі політики доставки залишаються на верхньому рівні.
+- Коли OpenClaw під час відновлення або налаштування переводить однооблікову конфігурацію в багатооблікову, він зберігає наявний іменований обліковий запис, якщо такий існує або `defaultAccount` уже вказує на нього. У promoted account переміщуються лише ключі автентифікації/bootstrap Matrix; спільні ключі політики доставки залишаються на верхньому рівні.

-Див. [Довідник із конфігурації](/uk/gateway/config-channels#multi-account-all-channels) для спільного шаблону кількох облікових записів.
+Спільний шаблон багатообліковості див. у [Довідник з конфігурації](/uk/gateway/config-channels#multi-account-all-channels).

 ## Приватні/LAN homeserver

 За замовчуванням OpenClaw блокує приватні/внутрішні homeserver Matrix для захисту від SSRF, якщо ви
-явно не дозволите це окремо для кожного облікового запису.
+явно не ввімкнете це окремо для кожного облікового запису.

 Якщо ваш homeserver працює на localhost, LAN/Tailscale IP або внутрішньому hostname, увімкніть
 `network.dangerouslyAllowPrivateNetwork` для цього облікового запису Matrix:
@ -763,12 +769,12 @@ openclaw matrix account add \
  --access-token syt_ops_xxx
 ```

-Ця згода дозволяє лише довірені приватні/внутрішні цілі. Публічні homeserver без шифрування, як-от
-`http://matrix.example.org:8008`, залишаються заблокованими. За можливості віддавайте перевагу `https://`.
+Це opt-in дозволяє лише довірені приватні/внутрішні цілі. Публічні незашифровані homeserver, такі як
+`http://matrix.example.org:8008`, і надалі блокуються. За можливості віддавайте перевагу `https://`.

 ## Проксіювання трафіку Matrix

-Якщо вашому розгортанню Matrix потрібен явний вихідний HTTP(S)-проксі, задайте `channels.matrix.proxy`:
+Якщо вашому розгортанню Matrix потрібен явний вихідний HTTP(S)-proxy, задайте `channels.matrix.proxy`:

 ```json5
 {
@ -783,112 +789,112 @@ openclaw matrix account add \
 ```

 Іменовані облікові записи можуть перевизначати значення верхнього рівня через `channels.matrix.accounts.<id>.proxy`.
-OpenClaw використовує той самий параметр проксі для робочого трафіку Matrix і probe стану облікового запису.
+OpenClaw використовує те саме налаштування proxy як для робочого трафіку Matrix, так і для перевірок статусу облікового запису.

 ## Визначення цілей

-Matrix приймає такі форми цілей скрізь, де OpenClaw просить указати ціль кімнати або користувача:
+Matrix приймає такі формати цілей усюди, де OpenClaw просить вас вказати кімнату або користувача:

 - Користувачі: `@user:server`, `user:@user:server` або `matrix:user:@user:server`
 - Кімнати: `!room:server`, `room:!room:server` або `matrix:room:!room:server`
- Аліаси: `#alias:server`, `channel:#alias:server` або `matrix:channel:#alias:server`
+- Alias: `#alias:server`, `channel:#alias:server` або `matrix:channel:#alias:server`

-ID кімнат Matrix чутливі до регістру. Використовуйте точне написання ID кімнати з Matrix
-під час налаштування явних цілей доставки, завдань Cron, прив’язок або allowlist.
-OpenClaw зберігає внутрішні ключі сесій у канонічному вигляді для сховища, тому ці
-ключі в нижньому регістрі не є надійним джерелом ID доставки Matrix.
+ID кімнат Matrix чутливі до регістру. Використовуйте точний регістр ID кімнати з Matrix
+під час налаштування явних цілей доставки, Cron jobs, прив’язок або allowlist.
+OpenClaw зберігає внутрішні ключі сесій у канонічному вигляді для зберігання, тому ці ключі
+в нижньому регістрі не є надійним джерелом ID доставки Matrix.

-Пошук у живому каталозі використовує обліковий запис Matrix, під яким виконано вхід:
+Живий пошук у каталозі використовує вхідний обліковий запис Matrix:

- Пошук користувачів звертається до каталогу користувачів Matrix на цьому homeserver.
- Пошук кімнат безпосередньо приймає явні ID кімнат і аліаси, а потім за потреби переходить до пошуку назв приєднаних кімнат для цього облікового запису.
- Пошук назв приєднаних кімнат працює best-effort. Якщо назву кімнати не вдається визначити як ID або аліас, вона ігнорується під час визначення allowlist у runtime.
+- Пошук користувачів виконує запити до каталогу користувачів Matrix на цьому homeserver.
+- Пошук кімнат напряму приймає явні ID кімнат і alias, а потім, у разі потреби, шукає за назвами приєднаних кімнат для цього облікового запису.
+- Пошук за назвами приєднаних кімнат є best-effort. Якщо назву кімнати не вдається визначити як ID або alias, під час виконання її буде проігноровано в allowlist resolution.

-## Довідник із конфігурації
+## Довідник з конфігурації

-Поля у стилі allowlist (`groupAllowFrom`, `dm.allowFrom`, `groups.<room>.users`) приймають повні Matrix user ID (найбезпечніший варіант). Точні збіги каталогу визначаються під час запуску та щоразу, коли allowlist змінюється під час роботи монітора; записи, які неможливо визначити, ігноруються під час виконання. Allowlist кімнат з тієї ж причини надають перевагу ID кімнат або аліасам.
+Поля у стилі allowlist (`groupAllowFrom`, `dm.allowFrom`, `groups.<room>.users`) приймають повні ID користувачів Matrix (найбезпечніший варіант). Точні збіги з каталогом визначаються під час запуску та щоразу, коли allowlist змінюється під час роботи монітора; записи, які не вдається визначити, ігноруються під час виконання. Allowlist кімнат із тієї ж причини надають перевагу ID кімнат або alias.

 ### Обліковий запис і з’єднання

 - `enabled`: увімкнути або вимкнути канал.
 - `name`: необов’язкова відображувана мітка для облікового запису.
 - `defaultAccount`: бажаний ID облікового запису, коли налаштовано кілька облікових записів Matrix.
- `accounts`: іменовані перевизначення для окремих облікових записів. Значення верхнього рівня `channels.matrix` успадковуються як значення за замовчуванням.
+- `accounts`: іменовані перевизначення для окремих облікових записів. Значення верхнього рівня `channels.matrix` успадковуються як типові.
 - `homeserver`: URL homeserver, наприклад `https://matrix.example.org`.
 - `network.dangerouslyAllowPrivateNetwork`: дозволити цьому обліковому запису підключатися до `localhost`, LAN/Tailscale IP або внутрішніх hostname.
- `proxy`: необов’язковий URL HTTP(S)-проксі для трафіку Matrix. Підтримується перевизначення на рівні облікового запису.
- `userId`: повний Matrix user ID (`@bot:example.org`).
- `accessToken`: токен доступу для автентифікації на основі токена. Підтримуються значення відкритим текстом і SecretRef у провайдерах env/file/exec ([Керування секретами](/uk/gateway/secrets)).
- `password`: пароль для входу на основі пароля. Підтримуються значення відкритим текстом і SecretRef.
- `deviceId`: явний Matrix device ID.
+- `proxy`: необов’язковий URL HTTP(S)-proxy для трафіку Matrix. Підтримується перевизначення на рівні облікового запису.
+- `userId`: повний ID користувача Matrix (`@bot:example.org`).
+- `accessToken`: токен доступу для автентифікації на основі токена. Підтримуються значення у відкритому тексті та SecretRef у провайдерах env/file/exec ([Керування секретами](/uk/gateway/secrets)).
+- `password`: пароль для входу на основі пароля. Підтримуються значення у відкритому тексті та SecretRef.
+- `deviceId`: явний ID пристрою Matrix.
 - `deviceName`: відображувана назва пристрою, яка використовується під час входу за паролем.
- `avatarUrl`: збережений URL власного аватара для синхронізації профілю й оновлень `profile set`.
- `initialSyncLimit`: максимальна кількість подій, які отримуються під час синхронізації на запуску.
+- `avatarUrl`: збережений URL self-avatar для синхронізації профілю та оновлень `profile set`.
+- `initialSyncLimit`: максимальна кількість подій, що отримуються під час початкової синхронізації при запуску.

 ### Шифрування

- `encryption`: увімкнути E2EE. Значення за замовчуванням: `false`.
- `startupVerification`: `"if-unverified"` (значення за замовчуванням, коли E2EE увімкнено) або `"off"`. Автоматично запитує self-verification під час запуску, якщо цей пристрій не верифіковано.
- `startupVerificationCooldownHours`: час cooldown до наступного автоматичного запиту під час запуску. Значення за замовчуванням: `24`.
+- `encryption`: увімкнути E2EE. Типово: `false`.
+- `startupVerification`: `"if-unverified"` (типово, коли E2EE увімкнено) або `"off"`. Автоматично запитує self-verification під час запуску, якщо цей пристрій не верифіковано.
+- `startupVerificationCooldownHours`: cooldown перед наступним автоматичним запитом під час запуску. Типово: `24`.

 ### Доступ і політика

- `groupPolicy`: `"open"`, `"allowlist"` або `"disabled"`. Значення за замовчуванням: `"allowlist"`.
- `groupAllowFrom`: allowlist user ID для трафіку кімнат.
- `dm.enabled`: якщо `false`, ігнорувати всі DM. Значення за замовчуванням: `true`.
- `dm.policy`: `"pairing"` (за замовчуванням), `"allowlist"`, `"open"` або `"disabled"`. Застосовується після того, як бот уже приєднався й класифікував кімнату як DM; не впливає на обробку запрошень.
- `dm.allowFrom`: allowlist user ID для трафіку DM.
- `dm.sessionScope`: `"per-user"` (за замовчуванням) або `"per-room"`.
- `dm.threadReplies`: перевизначення потоковості відповідей лише для DM (`"off"`, `"inbound"`, `"always"`).
- `allowBots`: приймати повідомлення від інших налаштованих облікових записів ботів Matrix (`true` або `"mentions"`).
- `allowlistOnly`: якщо `true`, примусово змінює всі активні політики DM (крім `"disabled"`) і політики груп `"open"` на `"allowlist"`. Не змінює політики `"disabled"`.
- `autoJoin`: `"always"`, `"allowlist"` або `"off"`. Значення за замовчуванням: `"off"`. Застосовується до кожного запрошення Matrix, включно із запрошеннями у стилі DM.
- `autoJoinAllowlist`: кімнати/аліаси, дозволені, коли `autoJoin` має значення `"allowlist"`. Записи аліасів визначаються через homeserver, а не за станом, заявленим запрошеною кімнатою.
- `contextVisibility`: видимість додаткового контексту (`"all"` за замовчуванням, `"allowlist"`, `"allowlist_quote"`).
+- `groupPolicy`: `"open"`, `"allowlist"` або `"disabled"`. Типово: `"allowlist"`.
+- `groupAllowFrom`: allowlist ID користувачів для трафіку кімнат.
+- `dm.enabled`: коли `false`, ігнорувати всі DM. Типово: `true`.
+- `dm.policy`: `"pairing"` (типово), `"allowlist"`, `"open"` або `"disabled"`. Застосовується після того, як бот приєднався та класифікував кімнату як DM; не впливає на обробку запрошень.
+- `dm.allowFrom`: allowlist ID користувачів для трафіку DM.
+- `dm.sessionScope`: `"per-user"` (типово) або `"per-room"`.
+- `dm.threadReplies`: перевизначення тредування відповідей лише для DM (`"off"`, `"inbound"`, `"always"`).
+- `allowBots`: приймати повідомлення від інших налаштованих бот-акаунтів Matrix (`true` або `"mentions"`).
+- `allowlistOnly`: коли `true`, примусово змінює всі активні політики DM (крім `"disabled"`) і політики груп `"open"` на `"allowlist"`. Не змінює політики `"disabled"`.
+- `autoJoin`: `"always"`, `"allowlist"` або `"off"`. Типово: `"off"`. Застосовується до кожного запрошення Matrix, включно із запрошеннями у стилі DM.
+- `autoJoinAllowlist`: кімнати/alias, дозволені, коли `autoJoin` має значення `"allowlist"`. Записи alias визначаються через homeserver, а не через стан, заявлений запрошеною кімнатою.
+- `contextVisibility`: видимість додаткового контексту (`"all"` типово, `"allowlist"`, `"allowlist_quote"`).

 ### Поведінка відповідей

 - `replyToMode`: `"off"`, `"first"`, `"all"` або `"batched"`.
 - `threadReplies`: `"off"`, `"inbound"` або `"always"`.
- `threadBindings`: перевизначення для каналу для маршрутизації сесій, прив’язаних до тредів, і їх життєвого циклу.
- `streaming`: `"off"` (за замовчуванням), `"partial"`, `"quiet"`. `true` ↔ `"partial"`, `false` ↔ `"off"`.
- `blockStreaming`: якщо `true`, завершені блоки асистента зберігаються як окремі повідомлення про прогрес.
+- `threadBindings`: перевизначення на рівні каналу для маршрутизації сесій і lifecycle, прив’язаних до тредів.
+- `streaming`: `"off"` (типово), `"partial"`, `"quiet"`. `true` ↔ `"partial"`, `false` ↔ `"off"`.
+- `blockStreaming`: коли `true`, завершені блоки асистента зберігаються як окремі повідомлення прогресу.
 - `markdown`: необов’язкова конфігурація рендерингу Markdown для вихідного тексту.
- `responsePrefix`: необов’язковий рядок, який додається перед вихідними відповідями.
- `textChunkLimit`: розмір вихідного фрагмента в символах, коли `chunkMode: "length"`. Значення за замовчуванням: `4000`.
- `chunkMode`: `"length"` (за замовчуванням, розбиває за кількістю символів) або `"newline"` (розбиває за межами рядків).
- `historyLimit`: кількість останніх повідомлень кімнати, що включаються як `InboundHistory`, коли повідомлення в кімнаті запускає агента. Використовує запасне значення `messages.groupChat.historyLimit`; фактичне значення за замовчуванням — `0` (вимкнено).
- `mediaMaxMb`: обмеження розміру медіа в МБ для вихідного надсилання та вхідної обробки.
+- `responsePrefix`: необов’язковий рядок, що додається на початок вихідних відповідей.
+- `textChunkLimit`: розмір вихідного фрагмента в символах, коли `chunkMode: "length"`. Типово: `4000`.
+- `chunkMode`: `"length"` (типово, поділ за кількістю символів) або `"newline"` (поділ за межами рядків).
+- `historyLimit`: кількість нещодавніх повідомлень кімнати, що включаються як `InboundHistory`, коли повідомлення кімнати запускає агента. Використовує fallback на `messages.groupChat.historyLimit`; ефективне типове значення `0` (вимкнено).
+- `mediaMaxMb`: ліміт розміру медіа в МБ для вихідного надсилання та вхідної обробки.

 ### Налаштування реакцій

 - `ackReaction`: перевизначення ack reaction для цього каналу/облікового запису.
- `ackReactionScope`: перевизначення області (`"group-mentions"` за замовчуванням, `"group-all"`, `"direct"`, `"all"`, `"none"`, `"off"`).
- `reactionNotifications`: режим вхідних сповіщень про реакції (`"own"` за замовчуванням, `"off"`).
+- `ackReactionScope`: перевизначення scope (`"group-mentions"` типово, `"group-all"`, `"direct"`, `"all"`, `"none"`, `"off"`).
+- `reactionNotifications`: режим вхідних сповіщень про реакції (`"own"` типово, `"off"`).

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

- `actions`: керування доступом до інструментів для окремих дій (`messages`, `reactions`, `pins`, `profile`, `memberInfo`, `channelInfo`, `verification`).
- `groups`: карта політик для окремих кімнат. Ідентичність сесії після визначення використовує стабільний ID кімнати. (`rooms` — застарілий псевдонім.)
+- `actions`: керування доступністю інструментів для окремих дій (`messages`, `reactions`, `pins`, `profile`, `memberInfo`, `channelInfo`, `verification`).
+- `groups`: карта політик для окремих кімнат. Identity сесії використовує стабільний ID кімнати після визначення. (`rooms` — це застарілий alias.)
  - `groups.<room>.account`: обмежити один успадкований запис кімнати конкретним обліковим записом.
-  - `groups.<room>.allowBots`: перевизначення параметра рівня каналу для окремої кімнати (`true` або `"mentions"`).
-  - `groups.<room>.users`: allowlist відправників для окремої кімнати.
-  - `groups.<room>.tools`: перевизначення дозволу/заборони інструментів для окремої кімнати.
-  - `groups.<room>.autoReply`: перевизначення вимоги згадування для окремої кімнати. `true` вимикає вимоги згадування для цієї кімнати; `false` знову примусово вмикає їх.
-  - `groups.<room>.skills`: фільтр Skills для окремої кімнати.
-  - `groups.<room>.systemPrompt`: фрагмент system prompt для окремої кімнати.
+  - `groups.<room>.allowBots`: перевизначення для кімнати параметра рівня каналу (`true` або `"mentions"`).
+  - `groups.<room>.users`: allowlist відправників для кімнати.
+  - `groups.<room>.tools`: перевизначення allow/deny інструментів для кімнати.
+  - `groups.<room>.autoReply`: перевизначення gating згадок для кімнати. `true` вимикає вимоги до згадок для цієї кімнати; `false` примусово знову вмикає їх.
+  - `groups.<room>.skills`: фільтр Skills для кімнати.
+  - `groups.<room>.systemPrompt`: фрагмент system prompt для кімнати.

-### Налаштування підтвердження exec
+### Налаштування погодження exec

- `execApprovals.enabled`: доставляти exec approvals через нативні підказки Matrix.
- `execApprovals.approvers`: Matrix user ID, яким дозволено підтверджувати. Використовує запасне значення `dm.allowFrom`.
- `execApprovals.target`: `"dm"` (за замовчуванням), `"channel"` або `"both"`.
+- `execApprovals.enabled`: доставляти exec approvals через нативні запити Matrix.
+- `execApprovals.approvers`: ID користувачів Matrix, яким дозволено погоджувати. Використовує fallback на `dm.allowFrom`.
+- `execApprovals.target`: `"dm"` (типово), `"channel"` або `"both"`.
 - `execApprovals.agentFilter` / `execApprovals.sessionFilter`: необов’язкові allowlist агентів/сесій для доставки.

 ## Пов’язане

 - [Огляд каналів](/uk/channels) — усі підтримувані канали
- [Pairing](/uk/channels/pairing) — автентифікація DM і потік pairing
- [Групи](/uk/channels/groups) — поведінка групового чату та керування згадуваннями
+- [Pairing](/uk/channels/pairing) — автентифікація DM і процес pairing
+- [Групи](/uk/channels/groups) — поведінка групового чату та gating згадок
 - [Маршрутизація каналів](/uk/channels/channel-routing) — маршрутизація сесій для повідомлень
 - [Безпека](/uk/gateway/security) — модель доступу та посилення захисту
--- a/docs/uk/tools/exec-approvals-advanced.md
+++ b/docs/uk/tools/exec-approvals-advanced.md
@ -1,41 +1,36 @@
 ---
 read_when:
-    - Налаштування безпечних бінарних файлів або власних профілів safe-bin
-    - Переспрямування погоджень до Slack/Discord/Telegram або інших чат-каналів
-    - Реалізація нативного клієнта погодження для каналу
-summary: 'Розширені погодження exec: безпечні бінарні файли, прив’язка інтерпретатора, переспрямування погодження, нативна доставка'
-title: Погодження exec — розширені можливості
+    - Налаштування безпечних категорій або власних профілів безпечних категорій
+    - Переспрямування схвалень до Slack/Discord/Telegram або інших чат-каналів
+    - Реалізація нативного клієнта схвалення для каналу
+summary: 'Розширені дозволи на виконання: безпечні категорії, прив’язка інтерпретатора, переспрямування схвалення, нативна доставка'
+title: Дозволи на виконання — додатково
 x-i18n:
-    generated_at: "2026-04-25T03:24:44Z"
+    generated_at: "2026-04-27T18:55:34Z"
    model: gpt-5.4
    provider: openai
-    source_hash: f5fab4a65d2d14f0d15cbe750d718b2a4e8f781a218debdb24b41be570a22d87
+    source_hash: 188b94f604a50d67742ebbdbb0238aad9e3de28dc50fb6e5a6070f06ef0adfde
    source_path: tools/exec-approvals-advanced.md
    workflow: 15
 ---

-Розширені теми погодження exec: fast-path `safeBins`, прив’язка
-інтерпретатора/середовища виконання та переспрямування погоджень до чат-каналів
-(включно з нативною доставкою).
-Базову політику та потік погодження див. у [Погодження exec](/uk/tools/exec-approvals).
+Розширені теми дозволів на виконання: швидкий шлях `safeBins`, прив’язка
+інтерпретатора/середовища виконання та переспрямування схвалень до чат-каналів (включно з нативною доставкою).
+Базову політику та потік схвалення див. у [Дозволи на виконання](/uk/tools/exec-approvals).

-## Безпечні бінарні файли (лише stdin)
+## Безпечні категорії (лише stdin)

-`tools.exec.safeBins` визначає невеликий список **лише stdin** бінарних файлів (наприклад,
-`cut`), які можуть працювати в режимі allowlist **без** явних записів в allowlist.
-Безпечні бінарні файли відхиляють позиційні аргументи файлів і токени, схожі на шляхи, тож вони
-можуть працювати лише з вхідним потоком. Розглядайте це як вузький fast-path для
-потокових фільтрів, а не як загальний список довіри.
+`tools.exec.safeBins` визначає невеликий список **лише stdin** бінарних файлів (наприклад, `cut`), які можуть працювати в режимі allowlist **без** явних записів у allowlist. Безпечні категорії відхиляють позиційні файлові аргументи та токени, схожі на шляхи, тому вони можуть працювати лише з вхідним потоком. Сприймайте це як вузький швидкий шлях для потокових фільтрів, а не як загальний список довіри.

 <Warning>
-**Не** додавайте бінарні файли інтерпретаторів або середовищ виконання (наприклад, `python3`, `node`,
-`ruby`, `bash`, `sh`, `zsh`) до `safeBins`. Якщо команда може виконувати код,
-запускати підкоманди або за задумом читати файли, надавайте перевагу явним записам у allowlist
-і залишайте ввімкненими запити на погодження. Власні безпечні бінарні файли мають визначати явний
+**Не** додавайте до `safeBins` інтерпретатори або середовища виконання (наприклад, `python3`, `node`,
+`ruby`, `bash`, `sh`, `zsh`). Якщо команда може виконувати код,
+запускати підкоманди або читати файли за своєю природою, надавайте перевагу явним записам у allowlist
+і залишайте запити на схвалення увімкненими. Для власних безпечних категорій потрібно визначити явний
 профіль у `tools.exec.safeBinProfiles.<bin>`.
 </Warning>

-Типові безпечні бінарні файли:
+Типові безпечні категорії:

 [//]: # "SAFE_BIN_DEFAULTS:START"

@ -43,17 +38,17 @@ x-i18n:

 [//]: # "SAFE_BIN_DEFAULTS:END"

-`grep` і `sort` не входять до типового списку. Якщо ви явно вмикаєте їх, залишайте явні
-записи в allowlist для їхніх сценаріїв, що не використовують stdin. Для `grep` у режимі safe-bin
-шаблон слід передавати через `-e`/`--regexp`; позиційна форма шаблону відхиляється,
-щоб операнди файлів не можна було приховано передати як неоднозначні позиційні аргументи.
+`grep` і `sort` не входять до типового списку. Якщо ви їх увімкнете, зберігайте явні
+записи allowlist для їхніх сценаріїв, що не використовують stdin. Для `grep` у режимі safe-bin
+передавайте шаблон через `-e`/`--regexp`; позиційна форма шаблону відхиляється,
+щоб файлові операнди не можна було замаскувати під неоднозначні позиційні аргументи.

 ### Перевірка Argv і заборонені прапорці

-Перевірка є детермінованою лише за формою argv (без перевірок існування файлів
-у файловій системі хоста), що запобігає поведінці oracle щодо існування файлів через
-відмінності між дозволом і відмовою. Параметри, орієнтовані на файли, заборонені для типових safe-bin;
-довгі параметри перевіряються за принципом fail-closed (невідомі прапорці та неоднозначні скорочення
+Перевірка є детермінованою лише за формою argv (без перевірок існування файлів у файловій системі хоста),
+що запобігає поведінці оракула існування файлів через відмінності між allow/deny.
+Для типових безпечних категорій файлово-орієнтовані параметри заборонені; довгі
+параметри перевіряються за принципом fail-closed (невідомі прапорці та неоднозначні скорочення
 відхиляються).

 Заборонені прапорці за профілем safe-bin:
@ -67,196 +62,193 @@ x-i18n:

 [//]: # "SAFE_BIN_DENIED_FLAGS:END"

-Безпечні бінарні файли також примушують трактувати токени argv як **буквальний текст** під час виконання
-для сегментів лише stdin (без globbing і без розгортання `$VARS`), тож шаблони
+Безпечні категорії також примусово трактують токени argv як **літеральний текст** під час виконання
+(без globbing і без розгортання `$VARS`) для сегментів лише stdin, тож шаблони
 на кшталт `*` або `$HOME/...` не можна використати для прихованого читання файлів.

 ### Довірені каталоги бінарних файлів

-Безпечні бінарні файли мають визначатися з довірених каталогів бінарних файлів (системні типові каталоги плюс
+Безпечні категорії мають визначатися з довірених каталогів бінарних файлів (системні типові шляхи плюс
 необов’язкові `tools.exec.safeBinTrustedDirs`). Записи `PATH` ніколи не вважаються довіреними автоматично.
-Типові довірені каталоги навмисно мінімальні: `/bin`, `/usr/bin`. Якщо
-ваш виконуваний файл safe-bin розташований у шляхах менеджера пакетів/користувача (наприклад
+Типові довірені каталоги навмисно мінімальні: `/bin`, `/usr/bin`. Якщо ваш safe-bin виконуваний файл розташований у шляхах пакетних менеджерів/користувача (наприклад,
 `/opt/homebrew/bin`, `/usr/local/bin`, `/opt/local/bin`, `/snap/bin`), додайте їх
 явно до `tools.exec.safeBinTrustedDirs`.

-### Ланцюжки shell, обгортки та мультиплексори
+### Ланцюжки shell-команд, обгортки та мультиплексори

-Ланцюжки shell (`&&`, `||`, `;`) дозволені, якщо кожен сегмент верхнього рівня
-задовольняє allowlist (включно з safe bins або авто-дозволом Skills). Перенаправлення
-і далі не підтримуються в режимі allowlist. Підстановка команд (`$()` / зворотні лапки) відхиляється
-під час розбору allowlist, зокрема всередині подвійних лапок; використовуйте одинарні
+Ланцюжки shell-команд (`&&`, `||`, `;`) дозволені, якщо кожен сегмент верхнього рівня
+відповідає allowlist (включно з safe bins або автоматичним дозволом Skills). Перенаправлення
+як і раніше не підтримуються в режимі allowlist. Підстановка команд (`$()` / зворотні лапки) 
+відхиляється під час розбору allowlist, зокрема всередині подвійних лапок; використовуйте одинарні
 лапки, якщо вам потрібен буквальний текст `$()`.

-У погодженнях companion-app на macOS сирий текст shell, що містить керувальний або
-розширювальний синтаксис shell (`&&`, `||`, `;`, `|`, `` ` ``, `$`, `<`, `>`, `(`, `)`),
-вважається промахом allowlist, якщо сам бінарний файл shell не внесений до allowlist.
+У схваленнях companion-app на macOS сирий текст shell-команди, що містить керуючий синтаксис shell
+або синтаксис розгортання (`&&`, `||`, `;`, `|`, `` ` ``, `$`, `<`, `>`, `(`, `)`),
+вважається промахом allowlist, якщо сам shell-бінарник не доданий до allowlist.

-Для обгорток shell (`bash|sh|zsh ... -c/-lc`) перевизначення env в межах запиту
+Для shell-обгорток (`bash|sh|zsh ... -c/-lc`) перевизначення env на рівні запиту
 зводяться до невеликого явного allowlist (`TERM`, `LANG`, `LC_*`, `COLORTERM`,
 `NO_COLOR`, `FORCE_COLOR`).

 Для рішень `allow-always` у режимі allowlist відомі обгортки-диспетчери (`env`,
 `nice`, `nohup`, `stdbuf`, `timeout`) зберігають внутрішній шлях до виконуваного файла замість
-шляху до обгортки. Мультиплексори shell (`busybox`, `toybox`) так само розгортаються для
-аплетів shell (`sh`, `ash` тощо). Якщо обгортку або мультиплексор неможливо
+шляху до обгортки. Shell-мультиплексори (`busybox`, `toybox`) розгортаються для
+shell-аплетів (`sh`, `ash` тощо) так само. Якщо обгортку або мультиплексор не можна
 безпечно розгорнути, жоден запис allowlist не зберігається автоматично.

 Якщо ви додаєте до allowlist інтерпретатори на кшталт `python3` або `node`, надавайте перевагу
 `tools.exec.strictInlineEval=true`, щоб inline eval і далі вимагав явного
-погодження. У strict mode `allow-always` усе ще може зберігати нешкідливі
-виклики інтерпретатора/скрипта, але носії inline-eval не зберігаються автоматично.
+схвалення. У строгому режимі `allow-always` усе ще може зберігати нешкідливі
+виклики інтерпретатора/скрипта, але носії inline-eval автоматично не зберігаються.

-### Safe bins проти allowlist
+### Безпечні категорії проти allowlist

-| Тема             | `tools.exec.safeBins`                                  | Allowlist (`exec-approvals.json`)                                                 |
+| Тема             | `tools.exec.safeBins`                                  | Allowlist (`exec-approvals.json`)                                                  |
 | ---------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------- |
-| Мета             | Автодозвіл вузьких stdin-фільтрів                      | Явна довіра до конкретних виконуваних файлів                                      |
-| Тип збігу        | Ім’я виконуваного файла + політика argv safe-bin       | Glob розв’язаного шляху виконуваного файла або glob простого імені команди для команд, викликаних через PATH |
-| Область аргументів | Обмежена профілем safe-bin і правилами буквальних токенів | Лише збіг шляху; за аргументи в іншому відповідальність на вас                    |
-| Типові приклади  | `head`, `tail`, `tr`, `wc`                             | `jq`, `python3`, `node`, `ffmpeg`, власні CLI                                     |
-| Найкраще використання | Низькоризикові текстові перетворення в конвеєрах      | Будь-який інструмент із ширшою поведінкою або побічними ефектами                  |
+| Мета             | Автодозвіл для вузьких stdin-фільтрів                  | Явна довіра до конкретних виконуваних файлів                                       |
+| Тип збігу        | Ім’я виконуваного файла + політика argv safe-bin       | Глоб для шляху до визначеного виконуваного файла або глоб для голого імені команди для команд, викликаних через PATH |
+| Область аргументів | Обмежується профілем safe-bin і правилами літеральних токенів | Лише збіг шляху; аргументи в іншому — ваша відповідальність                        |
+| Типові приклади  | `head`, `tail`, `tr`, `wc`                             | `jq`, `python3`, `node`, `ffmpeg`, власні CLI                                      |
+| Найкраще застосування | Низькоризикові текстові перетворення в конвеєрах   | Будь-який інструмент із ширшою поведінкою або побічними ефектами                   |

 Розташування конфігурації:

- `safeBins` походить із конфігурації (`tools.exec.safeBins` або `agents.list[].tools.exec.safeBins` для конкретного агента).
- `safeBinTrustedDirs` походить із конфігурації (`tools.exec.safeBinTrustedDirs` або `agents.list[].tools.exec.safeBinTrustedDirs` для конкретного агента).
- `safeBinProfiles` походить із конфігурації (`tools.exec.safeBinProfiles` або `agents.list[].tools.exec.safeBinProfiles` для конкретного агента). Ключі профілю для конкретного агента перевизначають глобальні ключі.
+- `safeBins` береться з конфігурації (`tools.exec.safeBins` або на рівні агента `agents.list[].tools.exec.safeBins`).
+- `safeBinTrustedDirs` береться з конфігурації (`tools.exec.safeBinTrustedDirs` або на рівні агента `agents.list[].tools.exec.safeBinTrustedDirs`).
+- `safeBinProfiles` береться з конфігурації (`tools.exec.safeBinProfiles` або на рівні агента `agents.list[].tools.exec.safeBinProfiles`). Ключі профілів на рівні агента перевизначають глобальні ключі.
 - записи allowlist зберігаються в локальному для хоста `~/.openclaw/exec-approvals.json` у `agents.<id>.allowlist` (або через Control UI / `openclaw approvals allowlist ...`).
- `openclaw security audit` попереджає через `tools.exec.safe_bins_interpreter_unprofiled`, коли бінарні файли інтерпретаторів/середовищ виконання з’являються в `safeBins` без явних профілів.
- `openclaw doctor --fix` може згенерувати відсутні записи `safeBinProfiles.<bin>` як `{}` (після цього перегляньте їх і посильте обмеження). Бінарні файли інтерпретаторів/середовищ виконання не генеруються автоматично.
+- `openclaw security audit` попереджає через `tools.exec.safe_bins_interpreter_unprofiled`, коли в `safeBins` з’являються інтерпретатори/середовища виконання без явних профілів.
+- `openclaw doctor --fix` може згенерувати відсутні записи `safeBinProfiles.<bin>` як `{}` (після цього перегляньте їх і посильте обмеження). Інтерпретатори/середовища виконання не генеруються автоматично.

 Приклад власного профілю:
 __OC_I18N_900000__
 Якщо ви явно додаєте `jq` до `safeBins`, OpenClaw усе одно відхиляє builtin `env` у режимі safe-bin,
-тож `jq -n env` не може вивантажити середовище процесу хоста без явного шляху в allowlist
-або запиту на погодження.
+щоб `jq -n env` не міг вивантажити середовище процесу хоста без явного шляху в allowlist
+або запиту на схвалення.

 ## Команди інтерпретатора/середовища виконання

-Запуски інтерпретатора/середовища виконання, підкріплені погодженням, навмисно консервативні:
+Запуски інтерпретатора/середовища виконання, підкріплені схваленням, навмисно зроблені консервативними:

 - Завжди прив’язується точний контекст argv/cwd/env.
- Форми прямого shell-скрипта і прямого файла середовища виконання прив’язуються, наскільки це можливо, до одного конкретного знімка локального файла.
- Поширені форми обгорток менеджерів пакетів, які все ще розв’язуються до одного прямого локального файла (наприклад, `pnpm exec`, `pnpm node`, `npm exec`, `npx`), розгортаються перед прив’язкою.
- Якщо OpenClaw не може точно визначити рівно один конкретний локальний файл для команди інтерпретатора/середовища виконання (наприклад, для скриптів пакетів, форм eval, специфічних для середовища виконання ланцюжків завантаження або неоднозначних багатофайлових форм), виконання з погодженням відхиляється замість того, щоб заявляти про семантичне покриття, якого насправді немає.
+- Форми прямого shell-скрипта та прямого файла середовища виконання за можливості прив’язуються до одного конкретного локального знімка файла.
+- Поширені форми обгорток пакетних менеджерів, які все ще визначаються в один прямий локальний файл (наприклад, `pnpm exec`, `pnpm node`, `npm exec`, `npx`), розгортаються перед прив’язкою.
+- Якщо OpenClaw не може точно визначити рівно один конкретний локальний файл для команди інтерпретатора/середовища виконання (наприклад, package scripts, форми eval, специфічні для середовища виконання ланцюжки loader або неоднозначні багатофайлові форми), виконання, підкріплене схваленням, забороняється замість того, щоб заявляти про семантичне покриття, якого насправді немає.
 - Для таких сценаріїв надавайте перевагу sandboxing, окремій межі хоста або явному довіреному allowlist/повному сценарію, де оператор приймає ширшу семантику середовища виконання.

-Коли потрібні погодження, інструмент exec негайно повертає ідентифікатор погодження. Використовуйте цей ідентифікатор для
-кореляції з подальшими системними подіями (`Exec finished` / `Exec denied`). Якщо до завершення
-тайм-ауту рішення не надходить, запит вважається тайм-аутом погодження і відображається як причина відмови.
+Коли потрібні схвалення, інструмент exec одразу повертає ID схвалення. Використовуйте цей ID, щоб
+співвідносити пізніші системні події (`Exec finished` / `Exec denied`). Якщо жодне рішення не надійде до
+завершення часу очікування, запит вважається тайм-аутом схвалення і відображається як причина відмови.

-### Поведінка доставки followup
+### Поведінка доставки подальших повідомлень

-Після завершення схваленого асинхронного exec OpenClaw надсилає turn `agent` як followup у ту саму сесію.
+Після завершення схваленого асинхронного exec OpenClaw надсилає подальший хід `agent` у ту саму сесію.

- Якщо існує коректна зовнішня ціль доставки (канал, який підтримує доставку, плюс ціль `to`), доставка followup використовує цей канал.
- У сценаріях лише webchat або внутрішньої сесії без зовнішньої цілі доставка followup лишається лише в межах сесії (`deliver: false`).
- Якщо викликач явно запитує сувору зовнішню доставку, але жоден зовнішній канал неможливо розв’язати, запит завершується помилкою `INVALID_REQUEST`.
- Якщо ввімкнено `bestEffortDeliver` і жоден зовнішній канал не вдається розв’язати, доставка знижується до лише-сесійної замість помилки.
+- Якщо існує коректна зовнішня ціль доставки (канал, здатний до доставки, плюс цільовий `to`), подальша доставка використовує цей канал.
+- У сценаріях лише webchat або внутрішньої сесії без зовнішньої цілі подальша доставка залишається лише в межах сесії (`deliver: false`).
+- Якщо викликач явно запитує строгий зовнішній delivery без визначуваного зовнішнього каналу, запит завершується помилкою `INVALID_REQUEST`.
+- Якщо ввімкнено `bestEffortDeliver` і не вдається визначити зовнішній канал, delivery знижується до режиму лише для сесії замість помилки.

-## Переспрямування погоджень до чат-каналів
+## Переспрямування схвалень до чат-каналів

-Ви можете переспрямовувати запити на погодження exec до будь-якого чат-каналу (включно з каналами Plugin) і погоджувати
-їх через `/approve`. Для цього використовується звичайний конвеєр вихідної доставки.
+Ви можете переспрямовувати запити на exec-схвалення до будь-якого чат-каналу (включно з каналами Plugin) і схвалювати
+їх за допомогою `/approve`. Для цього використовується звичайний конвеєр вихідної доставки.

 Конфігурація:
 __OC_I18N_900001__
 Відповідь у чаті:
 __OC_I18N_900002__
-Команда `/approve` обробляє як погодження exec, так і погодження Plugin. Якщо ID не відповідає жодному очікуваному погодженню exec, вона автоматично перевіряє погодження Plugin.
+Команда `/approve` обробляє як exec-схвалення, так і схвалення Plugin. Якщо ID не відповідає очікуваному exec-схваленню, вона автоматично перевіряє схвалення Plugin.

-### Переспрямування погоджень Plugin
+### Переспрямування схвалень Plugin

-Переспрямування погоджень Plugin використовує той самий конвеєр доставки, що й погодження exec, але має власну
+Переспрямування схвалень Plugin використовує той самий конвеєр доставки, що й exec-схвалення, але має власну
 незалежну конфігурацію в `approvals.plugin`. Увімкнення або вимкнення одного не впливає на інше.
 __OC_I18N_900003__
-Форма конфігурації ідентична до `approvals.exec`: `enabled`, `mode`, `agentFilter`,
+Форма конфігурації ідентична `approvals.exec`: `enabled`, `mode`, `agentFilter`,
 `sessionFilter` і `targets` працюють однаково.

-Канали, що підтримують спільні інтерактивні відповіді, відображають однакові кнопки погодження як для exec, так і для
-погоджень Plugin. Канали без спільного інтерактивного UI використовують звичайний текст із
-інструкціями `/approve`.
+Канали, які підтримують спільні інтерактивні відповіді, відображають однакові кнопки схвалення як для exec, так і для схвалень Plugin. Канали без спільного інтерактивного UI переходять до звичайного тексту з інструкціями `/approve`.

-### Погодження в тому самому чаті на будь-якому каналі
+### Схвалення в тому самому чаті на будь-якому каналі

-Коли запит на погодження exec або Plugin походить із чат-поверхні, що підтримує доставку, цей самий чат
-тепер може погодити його через `/approve` типово. Це стосується таких каналів, як Slack, Matrix і
-Microsoft Teams, на додачу до вже наявних сценаріїв Web UI і TUI.
+Коли запит на exec або Plugin-схвалення походить із чат-поверхні, здатної до доставки, той самий чат
+тепер може схвалити його через `/approve` типово. Це стосується таких каналів, як Slack, Matrix і
+Microsoft Teams, на додачу до вже наявних сценаріїв Web UI і terminal UI.

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

 Discord і Telegram також підтримують `/approve` у тому самому чаті, але ці канали все одно використовують свій
-розв’язаний список погоджувачів для авторизації, навіть коли нативну доставку погоджень вимкнено.
+визначений список апруверів для авторизації, навіть якщо нативну доставку схвалень вимкнено.

-Для Telegram та інших нативних клієнтів погодження, які викликають Gateway напряму,
-цей fallback навмисно обмежений збоями типу «погодження не знайдено». Реальна
-відмова/помилка погодження exec не повторюється непомітно як погодження Plugin.
+Для Telegram та інших нативних клієнтів схвалення, які звертаються безпосередньо до Gateway,
+цей резервний механізм навмисно обмежений помилками типу «схвалення не знайдено». Реальна
+відмова/помилка exec-схвалення не повторюється мовчки як схвалення Plugin.

-### Нативна доставка погоджень
+### Нативна доставка схвалень

-Деякі канали також можуть діяти як нативні клієнти погодження. Нативні клієнти додають DM для погоджувачів, fanout чату-джерела
-та специфічний для каналу інтерактивний UX погодження поверх спільного потоку `/approve`
-у тому самому чаті.
+Деякі канали також можуть виступати як нативні клієнти схвалень. Нативні клієнти додають приватні повідомлення апруверам, fanout до чату-джерела
+та специфічний для каналу інтерактивний UX схвалення поверх спільного потоку `/approve` у тому самому чаті.

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

 Загальна модель:

- політика exec на хості, як і раніше, визначає, чи потрібне погодження exec
- `approvals.exec` керує переспрямуванням запитів на погодження до інших чат-цілей
- `channels.<channel>.execApprovals` керує тим, чи діє цей канал як нативний клієнт погодження
+- політика exec на хості, як і раніше, вирішує, чи потрібне exec-схвалення
+- `approvals.exec` керує переспрямуванням запитів на схвалення до інших чат-цілей
+- `channels.<channel>.execApprovals` керує тим, чи виступає цей канал як нативний клієнт схвалення

-Нативні клієнти погодження автоматично вмикають доставку насамперед у DM, коли істинні всі такі умови:
+Нативні клієнти схвалення автоматично вмикають доставку спершу в DM, коли виконуються всі ці умови:

- канал підтримує нативну доставку погоджень
- погоджувачів можна розв’язати з явних `execApprovals.approvers` або з
-  задокументованих fallback-джерел цього каналу
+- канал підтримує нативну доставку схвалень
+- апруверів можна визначити з явних `execApprovals.approvers` або із
+  задокументованих резервних джерел цього каналу
 - `channels.<channel>.execApprovals.enabled` не задано або дорівнює `"auto"`

-Установіть `enabled: false`, щоб явно вимкнути нативний клієнт погодження. Установіть `enabled: true`, щоб примусово
-увімкнути його, коли погоджувачі розв’язуються. Публічна доставка до чату-джерела, як і раніше, явно керується через
+Установіть `enabled: false`, щоб явно вимкнути нативний клієнт схвалення. Установіть `enabled: true`, щоб примусово
+увімкнути його, коли апрувери визначаються. Публічна доставка до чату-джерела й надалі явно задається через
 `channels.<channel>.execApprovals.target`.

-FAQ: [Чому для погоджень exec у чаті існують дві конфігурації?](/help/faq-first-run#why-are-there-two-exec-approval-configs-for-chat-approvals)
+FAQ: [Чому для чат-схвалень є дві конфігурації exec approval?](/help/faq-first-run#why-are-there-two-exec-approval-configs-for-chat-approvals)

 - Discord: `channels.discord.execApprovals.*`
 - Slack: `channels.slack.execApprovals.*`
 - Telegram: `channels.telegram.execApprovals.*`

-Ці нативні клієнти погодження додають маршрутизацію в DM і необов’язковий fanout до каналу поверх спільного
-потоку `/approve` у тому самому чаті та спільних кнопок погодження.
+Ці нативні клієнти схвалення додають маршрутизацію DM і необов’язковий fanout до каналу поверх спільного
+потоку `/approve` у тому самому чаті та спільних кнопок схвалення.

 Спільна поведінка:

 - Slack, Matrix, Microsoft Teams та подібні чати з підтримкою доставки використовують звичайну модель автентифікації каналу
  для `/approve` у тому самому чаті
- коли нативний клієнт погодження вмикається автоматично, типовою нативною ціллю доставки є DM погоджувачів
- для Discord і Telegram лише розв’язані погоджувачі можуть погоджувати або відхиляти
- погоджувачі Discord можуть бути явними (`execApprovals.approvers`) або виводитися з `commands.ownerAllowFrom`
- погоджувачі Telegram можуть бути явними (`execApprovals.approvers`) або виводитися з наявної конфігурації owner (`allowFrom`, а також `defaultTo` для direct-message, де це підтримується)
- погоджувачі Slack можуть бути явними (`execApprovals.approvers`) або виводитися з `commands.ownerAllowFrom`
- нативні кнопки Slack зберігають kind ідентифікатора погодження, тож ID `plugin:` можуть розв’язувати погодження Plugin
-  без другого локального fallback-рівня Slack
- нативна маршрутизація Matrix у DM/канал і скорочення через реакції обробляють як погодження exec, так і Plugin;
-  авторизація Plugin, як і раніше, походить із `channels.matrix.dm.allowFrom`
- запитувач не зобов’язаний бути погоджувачем
- чат-джерело може погоджувати напряму через `/approve`, коли цей чат уже підтримує команди та відповіді
- нативні кнопки погодження Discord маршрутизують за kind ідентифікатора погодження: ID `plugin:` переходять
-  безпосередньо до погоджень Plugin, усе інше переходить до погоджень exec
- нативні кнопки погодження Telegram дотримуються того самого обмеженого fallback від exec до Plugin, що й `/approve`
- коли нативний `target` вмикає доставку до чату-джерела, запити на погодження містять текст команди
- очікувані погодження exec типово спливають через 30 хвилин
- якщо жоден UI оператора або налаштований клієнт погодження не може прийняти запит, запит повертається до `askFallback`
+- коли нативний клієнт схвалення вмикається автоматично, типовою ціллю нативної доставки є DM апруверів
+- для Discord і Telegram лише визначені апрувери можуть схвалювати або відхиляти
+- апрувери Discord можуть бути явними (`execApprovals.approvers`) або виведеними з `commands.ownerAllowFrom`
+- апрувери Telegram можуть бути явними (`execApprovals.approvers`) або виведеними з наявної конфігурації власника (`allowFrom`, а також `defaultTo` для direct-message, де це підтримується)
+- апрувери Slack можуть бути явними (`execApprovals.approvers`) або виведеними з `commands.ownerAllowFrom`
+- нативні кнопки Slack зберігають тип ID схвалення, тому ID `plugin:` можуть визначати схвалення Plugin
+  без другого локального резервного шару Slack
+- нативна DM/канальна маршрутизація Matrix і скорочення через реакції обробляють і exec-, і Plugin-схвалення;
+  авторизація Plugin, як і раніше, надходить із `channels.matrix.dm.allowFrom`
+- нативні запити Matrix включають власний вміст події `com.openclaw.approval` у першій події запиту,
+  щоб Matrix-клієнти з підтримкою OpenClaw могли читати структурований стан схвалення, тоді як стандартні клієнти
+  зберігають резервний варіант у вигляді звичайного тексту `/approve`
+- запитувач не обов’язково має бути апрувером
+- чат-джерело може схвалити безпосередньо через `/approve`, якщо цей чат уже підтримує команди та відповіді
+- нативні кнопки схвалення Discord маршрутизують за типом ID схвалення: ID `plugin:` одразу
+  передаються до схвалень Plugin, усе інше — до exec-схвалень
+- нативні кнопки схвалення Telegram використовують той самий обмежений резервний перехід від exec до Plugin, що й `/approve`
+- коли нативний `target` вмикає доставку до чату-джерела, запити на схвалення містять текст команди
+- очікувальні exec-схвалення типово спливають через 30 хвилин
+- якщо жоден UI оператора або налаштований клієнт схвалення не може прийняти запит, запит переходить до `askFallback`

-Telegram типово використовує DM погоджувачів (`target: "dm"`). Ви можете переключити це на `channel` або `both`, коли
-хочете, щоб запити на погодження також з’являлися у вихідному чаті/темі Telegram. Для тем форуму Telegram
-OpenClaw зберігає тему для запиту на погодження та для follow-up після погодження.
+Telegram типово використовує DM апруверів (`target: "dm"`). Ви можете переключити на `channel` або `both`, якщо
+хочете, щоб запити на схвалення також з’являлися у вихідному чаті/темі Telegram. Для тем форуму Telegram
+OpenClaw зберігає тему для запиту на схвалення та подальшого повідомлення після схвалення.

 Див. також:

@ -265,15 +257,15 @@ OpenClaw зберігає тему для запиту на погодження

 ### Потік macOS IPC
 __OC_I18N_900004__
-Примітки щодо безпеки:
+Примітки з безпеки:

 - Режим Unix socket `0600`, токен зберігається в `exec-approvals.json`.
 - Перевірка peer з тим самим UID.
 - Challenge/response (nonce + HMAC token + request hash) + короткий TTL.

-## Пов’язані матеріали
+## Пов’язане

- [Погодження exec](/uk/tools/exec-approvals) — базова політика та потік погодження
+- [Дозволи на виконання](/uk/tools/exec-approvals) — базова політика та потік схвалення
 - [Інструмент exec](/uk/tools/exec)
- [Режим elevated](/uk/tools/elevated)
+- [Підвищений режим](/uk/tools/elevated)
 - [Skills](/uk/tools/skills) — поведінка автодозволу на основі Skills