diff --git a/docs/uk/automation/tasks.md b/docs/uk/automation/tasks.md
index 3eb8f98b6..d4c8d3af6 100644
--- a/docs/uk/automation/tasks.md
+++ b/docs/uk/automation/tasks.md
@@ -1,41 +1,41 @@
 ---
 read_when:
-    - Перевірка фонової роботи, що виконується або нещодавно завершилася
+    - Перевірка фонової роботи, яка виконується або нещодавно завершилася
     - Налагодження збоїв доставки для відокремлених запусків агентів
     - Розуміння того, як фонові запуски пов’язані із сеансами, Cron і Heartbeat
 summary: Відстеження фонових завдань для запусків ACP, субагентів, ізольованих завдань Cron і операцій CLI
 title: Фонові завдання
 x-i18n:
-    generated_at: "2026-04-20T18:25:02Z"
+    generated_at: "2026-04-21T19:01:28Z"
     model: gpt-5.4
     provider: openai
-    source_hash: ba5511b1c421bdf505fc7d34f09e453ac44e85213fcb0f082078fa957aa91fe7
+    source_hash: a4cd666b3eaffde8df0b5e1533eb337e44a0824824af6f8a240f18a89f71b402
     source_path: automation/tasks.md
     workflow: 15
 ---
 
 # Фонові завдання
 
-> **Шукаєте планування?** Див. [Автоматизація й завдання](/uk/automation), щоб вибрати правильний механізм. Ця сторінка описує **відстеження** фонової роботи, а не її планування.
+> **Шукаєте планування?** Дивіться [Автоматизація та завдання](/uk/automation), щоб вибрати правильний механізм. Ця сторінка описує **відстеження** фонової роботи, а не її планування.
 
 Фонові завдання відстежують роботу, яка виконується **поза межами вашого основного сеансу розмови**:
-запуски ACP, створення субагентів, виконання ізольованих завдань Cron і операції, ініційовані через CLI.
+запуски ACP, створення субагентів, ізольовані виконання завдань Cron і операції, ініційовані через CLI.
 
-Завдання **не** замінюють сеанси, завдання Cron або Heartbeat — це **журнал активності**, який фіксує, яка відокремлена робота відбулася, коли саме та чи була вона успішною.
+Завдання **не** замінюють сеанси, завдання Cron або Heartbeat — це **журнал активності**, який фіксує, яка відокремлена робота відбулася, коли саме, і чи була вона успішною.
 
 <Note>
-Не кожен запуск агента створює завдання. Ходи Heartbeat і звичайний інтерактивний чат — ні. Усі виконання Cron, створення ACP, створення субагентів і команди агента CLI — так.
+Не кожен запуск агента створює завдання. Ходи Heartbeat і звичайний інтерактивний чат — ні. Усі виконання Cron, створення ACP, створення субагентів і команди агента через CLI — так.
 </Note>
 
 ## Коротко
 
-- Завдання — це **записи**, а не планувальники: Cron і Heartbeat вирішують, _коли_ запускається робота, а завдання відстежують, _що сталося_.
+- Завдання — це **записи**, а не планувальники: Cron і Heartbeat вирішують, _коли_ запускати роботу, а завдання відстежують, _що сталося_.
 - ACP, субагенти, усі завдання Cron і операції CLI створюють завдання. Ходи Heartbeat — ні.
 - Кожне завдання проходить шлях `queued → running → terminal` (`succeeded`, `failed`, `timed_out`, `cancelled` або `lost`).
-- Завдання Cron залишаються активними, поки середовище виконання Cron усе ще володіє цим завданням; чат-орієнтовані завдання CLI залишаються активними лише доти, доки їхній контекст запуску-власник усе ще активний.
-- Завершення працює за push-моделлю: відокремлена робота може напряму сповістити або пробудити сеанс/Heartbeat запитувача після завершення, тому цикли опитування стану зазвичай є неправильною моделлю.
-- Ізольовані запуски Cron і завершення субагентів у режимі best-effort очищають відстежувані вкладки браузера/процеси для свого дочірнього сеансу перед фінальним обліком очищення.
-- Доставка ізольованого Cron пригнічує застарілі проміжні відповіді батьківського процесу, поки ще триває завершення нащадків-субагентів, і надає перевагу фінальному виводу нащадка, якщо він надходить до доставки.
+- Завдання Cron залишаються активними, поки середовище виконання Cron усе ще володіє цим завданням; CLI-завдання на основі чату залишаються активними лише поки активний їхній контекст запуску-власника.
+- Завершення керується подіями надсилання: відокремлена робота може напряму сповістити або пробудити сеанс запитувача/Heartbeat після завершення, тому цикли опитування статусу зазвичай є неправильною моделлю.
+- Ізольовані запуски Cron і завершення субагентів у міру можливого очищають відстежувані вкладки браузера/процеси для свого дочірнього сеансу перед фінальним обліком очищення.
+- Доставка ізольованого Cron пригнічує застарілі проміжні відповіді батьківського процесу, поки ще завершується робота дочірніх субагентів, і надає перевагу фінальному виводу дочірнього процесу, якщо він надходить до моменту доставки.
 - Сповіщення про завершення доставляються безпосередньо в канал або ставляться в чергу до наступного Heartbeat.
 - `openclaw tasks list` показує всі завдання; `openclaw tasks audit` виявляє проблеми.
 - Термінальні записи зберігаються 7 днів, після чого автоматично видаляються.
@@ -43,23 +43,23 @@ x-i18n:
 ## Швидкий старт
 
 ```bash
-# Перелічити всі завдання (спочатку найновіші)
+# Показати всі завдання (найновіші спочатку)
 openclaw tasks list
 
-# Відфільтрувати за середовищем виконання або статусом
+# Фільтрувати за середовищем виконання або статусом
 openclaw tasks list --runtime acp
 openclaw tasks list --status running
 
-# Показати подробиці для конкретного завдання (за ID, run ID або session key)
+# Показати деталі конкретного завдання (за ID, ID запуску або ключем сеансу)
 openclaw tasks show <lookup>
 
-# Скасувати запущене завдання (завершує дочірній сеанс)
+# Скасувати завдання, що виконується (завершує дочірній сеанс)
 openclaw tasks cancel <lookup>
 
 # Змінити політику сповіщень для завдання
 openclaw tasks notify <lookup> state_changes
 
-# Виконати аудит працездатності
+# Запустити перевірку стану
 openclaw tasks audit
 
 # Переглянути або застосувати обслуговування
@@ -74,24 +74,24 @@ openclaw tasks flow cancel <lookup>
 
 ## Що створює завдання
 
-| Джерело                | Тип середовища виконання | Коли створюється запис завдання                         | Політика сповіщень за замовчуванням |
-| ---------------------- | ------------------------ | ------------------------------------------------------ | ----------------------------------- |
-| Фонові запуски ACP     | `acp`                    | Створення дочірнього сеансу ACP                        | `done_only`                         |
-| Оркестрація субагентів | `subagent`               | Створення субагента через `sessions_spawn`             | `done_only`                         |
-| Завдання Cron (усі типи) | `cron`                 | Кожне виконання Cron (основний сеанс та ізольований)   | `silent`                            |
-| Операції CLI           | `cli`                    | Команди `openclaw agent`, що виконуються через Gateway | `silent`                            |
-| Медіазавдання агента   | `cli`                    | Запуски `video_generate`, прив’язані до сеансу         | `silent`                            |
+| Джерело                | Тип середовища виконання | Коли створюється запис завдання                        | Типова політика сповіщень |
+| ---------------------- | ------------------------ | ------------------------------------------------------ | ------------------------- |
+| Фонові запуски ACP     | `acp`                    | Під час створення дочірнього сеансу ACP                | `done_only`               |
+| Оркестрація субагентів | `subagent`               | Під час створення субагента через `sessions_spawn`     | `done_only`               |
+| Завдання Cron (усі типи) | `cron`                 | Для кожного виконання Cron (основний сеанс та ізольовані) | `silent`               |
+| Операції CLI           | `cli`                    | Команди `openclaw agent`, що виконуються через Gateway | `silent`                  |
+| Медіазавдання агента   | `cli`                    | Запуски `video_generate` на основі сеансу              | `silent`                  |
 
-Завдання Cron основного сеансу за замовчуванням використовують політику сповіщень `silent` — вони створюють записи для відстеження, але не генерують сповіщень. Ізольовані завдання Cron також за замовчуванням мають `silent`, але є помітнішими, оскільки виконуються у власному сеансі.
+Завдання Cron основного сеансу типово використовують політику сповіщень `silent` — вони створюють записи для відстеження, але не генерують сповіщень. Ізольовані завдання Cron також типово використовують `silent`, але є помітнішими, оскільки виконуються у власному сеансі.
 
-Запуски `video_generate`, прив’язані до сеансу, також використовують політику сповіщень `silent`. Вони все одно створюють записи завдань, але завершення повертається до початкового сеансу агента як внутрішнє пробудження, щоб агент міг сам написати наступне повідомлення й прикріпити готове відео. Якщо ви ввімкнете `tools.media.asyncCompletion.directSend`, асинхронні завершення `music_generate` і `video_generate` спочатку намагатимуться доставити результат безпосередньо в канал, а вже потім повертатимуться до шляху пробудження сеансу запитувача.
+Запуски `video_generate` на основі сеансу також використовують політику сповіщень `silent`. Вони все одно створюють записи завдань, але завершення повертається до початкового сеансу агента як внутрішнє пробудження, щоб агент міг сам написати наступне повідомлення і прикріпити готове відео. Якщо ви вмикаєте `tools.media.asyncCompletion.directSend`, асинхронні завершення `music_generate` і `video_generate` спочатку намагаються доставити результат безпосередньо в канал, а вже потім переходять до шляху пробудження сеансу запитувача.
 
-Поки завдання `video_generate`, прив’язане до сеансу, все ще активне, інструмент також діє як захисне обмеження: повторні виклики `video_generate` у цьому самому сеансі повертають статус активного завдання замість запуску другого паралельного генерування. Використовуйте `action: "status"`, якщо вам потрібен явний перегляд прогресу/статусу з боку агента.
+Поки завдання `video_generate` на основі сеансу все ще активне, інструмент також працює як захисне обмеження: повторні виклики `video_generate` у тому самому сеансі повертають статус активного завдання замість запуску другої паралельної генерації. Використовуйте `action: "status"`, якщо хочете явний перегляд перебігу/статусу з боку агента.
 
 **Що не створює завдань:**
 
 - Ходи Heartbeat — основний сеанс; див. [Heartbeat](/uk/gateway/heartbeat)
-- Звичайні ходи інтерактивного чату
+- Звичайні інтерактивні ходи чату
 - Прямі відповіді `/command`
 
 ## Життєвий цикл завдання
@@ -99,59 +99,59 @@ openclaw tasks flow cancel <lookup>
 ```mermaid
 stateDiagram-v2
     [*] --> queued
-    queued --> running : agent starts
-    running --> succeeded : completes ok
-    running --> failed : error
-    running --> timed_out : timeout exceeded
-    running --> cancelled : operator cancels
-    queued --> lost : session gone > 5 min
-    running --> lost : session gone > 5 min
+    queued --> running : запускається агент
+    running --> succeeded : успішне завершення
+    running --> failed : помилка
+    running --> timed_out : перевищено час очікування
+    running --> cancelled : оператор скасував
+    queued --> lost : сеанс відсутній > 5 хв
+    running --> lost : сеанс відсутній > 5 хв
 ```
 
-| Статус      | Що це означає                                                              |
-| ----------- | -------------------------------------------------------------------------- |
-| `queued`    | Створено, очікує на запуск агента                                          |
-| `running`   | Хід агента активно виконується                                             |
-| `succeeded` | Успішно завершено                                                          |
-| `failed`    | Завершено з помилкою                                                       |
-| `timed_out` | Перевищено налаштований час очікування                                     |
-| `cancelled` | Зупинено оператором через `openclaw tasks cancel`                          |
-| `lost`      | Середовище виконання втратило авторитетний стан-основу після 5-хвилинного пільгового періоду |
+| Статус      | Що це означає                                                             |
+| ----------- | ------------------------------------------------------------------------- |
+| `queued`    | Створено, очікує запуску агента                                           |
+| `running`   | Хід агента активно виконується                                            |
+| `succeeded` | Успішно завершено                                                         |
+| `failed`    | Завершено з помилкою                                                      |
+| `timed_out` | Перевищено налаштований час очікування                                    |
+| `cancelled` | Зупинено оператором через `openclaw tasks cancel`                        |
+| `lost`      | Середовище виконання втратило авторитетний базовий стан після 5-хвилинного пільгового періоду |
 
-Переходи відбуваються автоматично — коли пов’язаний запуск агента завершується, статус завдання оновлюється відповідно до результату.
+Переходи відбуваються автоматично — коли пов’язаний запуск агента завершується, статус завдання оновлюється відповідно.
 
-`lost` є залежним від середовища виконання:
+`lost` залежить від середовища виконання:
 
-- Завдання ACP: зникли метадані дочірнього сеансу ACP, на які спиралося завдання.
-- Завдання субагента: дочірній сеанс-основа зник зі сховища цільового агента.
+- Завдання ACP: зникли метадані дочірнього сеансу ACP.
+- Завдання субагента: дочірній сеанс зник зі сховища цільового агента.
 - Завдання Cron: середовище виконання Cron більше не відстежує завдання як активне.
-- Завдання CLI: ізольовані завдання дочірнього сеансу використовують дочірній сеанс; чат-орієнтовані завдання CLI натомість використовують живий контекст запуску, тому завислі рядки сеансів каналу/групи/прямих повідомлень не підтримують їх у живому стані.
+- Завдання CLI: ізольовані завдання дочірнього сеансу використовують дочірній сеанс; CLI-завдання на основі чату натомість використовують активний контекст запуску, тому залишкові рядки сеансу каналу/групи/прямих повідомлень не підтримують їхню активність.
 
 ## Доставка і сповіщення
 
-Коли завдання досягає термінального стану, OpenClaw надсилає вам сповіщення. Є два шляхи доставки:
+Коли завдання досягає термінального стану, OpenClaw сповіщає вас. Є два шляхи доставки:
 
-**Пряма доставка** — якщо завдання має ціль каналу (`requesterOrigin`), повідомлення про завершення надсилається прямо в цей канал (Telegram, Discord, Slack тощо). Для завершення субагента OpenClaw також зберігає прив’язане маршрутизування thread/topic, коли воно доступне, і може заповнити відсутні `to` / account із збереженого маршруту сеансу запитувача (`lastChannel` / `lastTo` / `lastAccountId`) перед тим, як відмовитися від прямої доставки.
+**Пряма доставка** — якщо завдання має ціль каналу (`requesterOrigin`), повідомлення про завершення надсилається безпосередньо в цей канал (Telegram, Discord, Slack тощо). Для завершень субагентів OpenClaw також зберігає маршрутизацію прив’язаної гілки/теми, коли це можливо, і може заповнити відсутній `to` / обліковий запис зі збереженого маршруту сеансу запитувача (`lastChannel` / `lastTo` / `lastAccountId`) перед тим, як відмовитися від прямої доставки.
 
-**Доставка через чергу сеансу** — якщо пряма доставка не вдалася або origin не задано, оновлення ставиться в чергу як системна подія в сеансі запитувача й з’являється під час наступного Heartbeat.
+**Доставка через чергу сеансу** — якщо пряма доставка не вдається або origin не задано, оновлення ставиться в чергу як системна подія в сеансі запитувача і з’являється під час наступного Heartbeat.
 
 <Tip>
-Завершення завдання негайно запускає пробудження Heartbeat, щоб ви швидко побачили результат — вам не потрібно чекати наступного запланованого тіку Heartbeat.
+Завершення завдання негайно пробуджує Heartbeat, тому ви швидко бачите результат — не потрібно чекати наступного запланованого тіку Heartbeat.
 </Tip>
 
-Це означає, що типовий робочий процес побудований на push-моделі: один раз запускаєте відокремлену роботу, а далі середовище виконання саме пробуджує або сповіщає вас після завершення. Опитуйте стан завдання лише тоді, коли вам потрібні налагодження, втручання або явний аудит.
+Це означає, що типовий робочий процес базується на надсиланні подій: запустіть відокремлену роботу один раз, а потім дозвольте середовищу виконання пробудити або сповістити вас після завершення. Опитуйте стан завдання лише тоді, коли вам потрібне налагодження, втручання або явний аудит.
 
 ### Політики сповіщень
 
 Керуйте тим, скільки інформації ви отримуєте про кожне завдання:
 
-| Політика              | Що доставляється                                                        |
-| --------------------- | ----------------------------------------------------------------------- |
-| `done_only` (default) | Лише термінальний стан (`succeeded`, `failed` тощо) — **це значення за замовчуванням** |
-| `state_changes`       | Кожна зміна стану та оновлення прогресу                                 |
-| `silent`              | Нічого                                                                   |
+| Політика              | Що доставляється                                                         |
+| --------------------- | ------------------------------------------------------------------------ |
+| `done_only` (типово)  | Лише термінальний стан (`succeeded`, `failed` тощо) — **це типове значення** |
+| `state_changes`       | Кожен перехід стану й оновлення прогресу                                 |
+| `silent`              | Взагалі нічого                                                           |
 
-Змінити політику під час виконання завдання:
+Змініть політику, поки завдання виконується:
 
 ```bash
 openclaw tasks notify <lookup> state_changes
@@ -165,7 +165,7 @@ openclaw tasks notify <lookup> state_changes
 openclaw tasks list [--runtime <acp|subagent|cron|cli>] [--status <status>] [--json]
 ```
 
-Стовпці виводу: ID завдання, Тип, Статус, Доставка, Run ID, Дочірній сеанс, Підсумок.
+Стовпці виводу: ID завдання, вид, статус, доставка, ID запуску, дочірній сеанс, зведення.
 
 ### `tasks show`
 
@@ -173,7 +173,7 @@ openclaw tasks list [--runtime <acp|subagent|cron|cli>] [--status <status>] [--j
 openclaw tasks show <lookup>
 ```
 
-Токен lookup приймає ID завдання, run ID або ключ сеансу. Показує повний запис, включно з часом, станом доставки, помилкою та термінальним підсумком.
+Токен пошуку приймає ID завдання, ID запуску або ключ сеансу. Показує повний запис, зокрема час, стан доставки, помилку й термінальне зведення.
 
 ### `tasks cancel`
 
@@ -181,7 +181,7 @@ openclaw tasks show <lookup>
 openclaw tasks cancel <lookup>
 ```
 
-Для завдань ACP і субагентів це завершує дочірній сеанс. Для завдань, що відстежуються через CLI, скасування фіксується в реєстрі завдань (окремого дескриптора дочірнього середовища виконання немає). Статус переходить у `cancelled`, і, коли це доречно, надсилається сповіщення про доставку.
+Для завдань ACP і субагентів це завершує дочірній сеанс. Для завдань, що відстежуються через CLI, скасування фіксується в реєстрі завдань (окремого дочірнього дескриптора середовища виконання немає). Статус переходить у `cancelled`, а за потреби надсилається сповіщення про доставку.
 
 ### `tasks notify`
 
@@ -197,14 +197,14 @@ openclaw tasks audit [--json]
 
 Виявляє операційні проблеми. За наявності проблем результати також з’являються в `openclaw status`.
 
-| Ознака проблеми            | Серйозність | Тригер                                                |
-| -------------------------- | ----------- | ----------------------------------------------------- |
-| `stale_queued`             | warn        | У черзі понад 10 хвилин                               |
-| `stale_running`            | error       | Виконується понад 30 хвилин                           |
-| `lost`                     | error       | Зникла належність завдання до середовища виконання    |
-| `delivery_failed`          | warn        | Доставка не вдалася, а політика сповіщень не `silent` |
-| `missing_cleanup`          | warn        | Термінальне завдання без часової позначки очищення    |
-| `inconsistent_timestamps`  | warn        | Порушення часової шкали (наприклад, завершено раніше, ніж розпочато) |
+| Проблема                  | Серйозність | Тригер                                                |
+| ------------------------- | ----------- | ----------------------------------------------------- |
+| `stale_queued`            | warn        | У стані queued понад 10 хвилин                        |
+| `stale_running`           | error       | У стані running понад 30 хвилин                       |
+| `lost`                    | error       | Зникло володіння завданням на рівні середовища виконання |
+| `delivery_failed`         | warn        | Доставка не вдалася, а політика сповіщень не `silent` |
+| `missing_cleanup`         | warn        | Термінальне завдання без позначки часу очищення       |
+| `inconsistent_timestamps` | warn        | Порушення часової шкали (наприклад, завершено раніше, ніж розпочато) |
 
 ### `tasks maintenance`
 
@@ -213,21 +213,21 @@ openclaw tasks maintenance [--json]
 openclaw tasks maintenance --apply [--json]
 ```
 
-Використовуйте це, щоб переглянути або застосувати звіряння, проставлення позначок очищення та видалення застарілих даних для завдань і стану Task Flow.
+Використовуйте це, щоб переглянути або застосувати узгодження, проставлення очищення та видалення для стану завдань і Task Flow.
 
-Звіряння залежить від середовища виконання:
+Узгодження залежить від середовища виконання:
 
-- Завдання ACP/субагентів перевіряють свій дочірній сеанс-основу.
-- Завдання Cron перевіряють, чи середовище виконання Cron усе ще володіє цим завданням.
-- Чат-орієнтовані завдання CLI перевіряють контекст активного запуску-власника, а не лише рядок чат-сеансу.
+- Завдання ACP/субагентів перевіряють свій базовий дочірній сеанс.
+- Завдання Cron перевіряють, чи середовище виконання Cron усе ще володіє завданням.
+- CLI-завдання на основі чату перевіряють базовий активний контекст запуску, а не лише рядок сеансу чату.
 
 Очищення після завершення також залежить від середовища виконання:
 
-- Під час завершення субагента в режимі best-effort закриваються відстежувані вкладки браузера/процеси для дочірнього сеансу, перш ніж продовжиться очищення оголошення.
-- Під час завершення ізольованого Cron у режимі best-effort закриваються відстежувані вкладки браузера/процеси для сеансу Cron, перш ніж виконання буде повністю згорнуто.
-- Доставка ізольованого Cron за потреби очікує завершення подальших дій нащадків-субагентів і пригнічує застарілий текст підтвердження батьківського процесу замість його оголошення.
-- Доставка завершення субагента надає перевагу найновішому видимому тексту асистента; якщо він порожній, використовується очищений найновіший текст `tool`/`toolResult`, а запуски лише з викликом інструмента, що завершилися через тайм-аут, можуть згортатися до короткого підсумку часткового прогресу.
-- Помилки очищення не маскують реальний результат завдання.
+- Завершення субагента в міру можливого закриває відстежувані вкладки браузера/процеси для дочірнього сеансу, перш ніж продовжиться оголошене очищення.
+- Завершення ізольованого Cron у міру можливого закриває відстежувані вкладки браузера/процеси для сеансу Cron, перш ніж запуск повністю завершиться.
+- Доставка ізольованого Cron за потреби очікує завершення дочірньої роботи субагентів і пригнічує застарілий текст підтвердження батьківського процесу замість його оголошення.
+- Доставка завершення субагента надає перевагу найновішому видимому тексту асистента; якщо він порожній, використовується очищений найновіший текст tool/toolResult, а запуски лише з викликом інструменту, що завершилися тайм-аутом, можуть зводитися до короткого підсумку часткового прогресу. Термінальні невдалі запуски оголошують статус невдачі без повторного відтворення захопленого тексту відповіді.
+- Збої очищення не повинні маскувати реальний результат завдання.
 
 ### `tasks flow list|show|cancel`
 
@@ -237,35 +237,36 @@ openclaw tasks flow show <lookup> [--json]
 openclaw tasks flow cancel <lookup>
 ```
 
-Використовуйте ці команди, коли вас цікавить саме оркеструвальний Task Flow, а не окремий запис фонового завдання.
+Використовуйте це, коли вас цікавить саме оркеструвальний Task Flow, а не окремий запис фонового завдання.
 
 ## Дошка завдань чату (`/tasks`)
 
-Використовуйте `/tasks` у будь-якому чат-сеансі, щоб побачити фонові завдання, пов’язані з цим сеансом. Дошка показує
-активні й нещодавно завершені завдання з інформацією про середовище виконання, статус, час, а також подробицями прогресу або помилки.
+Використовуйте `/tasks` у будь-якому сеансі чату, щоб переглянути фонові завдання, пов’язані з цим сеансом. Дошка показує активні й нещодавно завершені завдання з середовищем виконання, статусом, часовими даними та деталями прогресу або помилки.
 
-Якщо в поточному сеансі немає видимих пов’язаних завдань, `/tasks` переключається на локальні для агента підрахунки завдань,
-щоб ви все одно бачили огляд без витоку подробиць з інших сеансів.
+Коли поточний сеанс не має видимих пов’язаних завдань, `/tasks` повертається до локальних для агента підрахунків завдань,
+щоб ви все одно отримували огляд без розкриття деталей інших сеансів.
 
-Для повного журналу оператора використовуйте CLI: `openclaw tasks list`.
+Для повного операторського журналу використовуйте CLI: `openclaw tasks list`.
 
 ## Інтеграція статусу (тиск завдань)
 
-`openclaw status` містить стислий підсумок завдань:
+`openclaw status` містить коротке зведення завдань:
 
 ```
 Tasks: 3 queued · 2 running · 1 issues
 ```
 
-Підсумок показує:
+Зведення повідомляє:
 
 - **active** — кількість `queued` + `running`
 - **failures** — кількість `failed` + `timed_out` + `lost`
-- **byRuntime** — розбивка за `acp`, `subagent`, `cron`, `cli`
+- **byRuntime** — розподіл за `acp`, `subagent`, `cron`, `cli`
 
-І `/status`, і інструмент `session_status` використовують знімок завдань з урахуванням очищення: пріоритет надається активним завданням, застарілі завершені рядки приховуються, а нещодавні збої показуються лише тоді, коли активної роботи вже не залишилося. Це допомагає картці статусу зосереджуватися на тому, що важливо саме зараз.
+І `/status`, і інструмент `session_status` використовують знімок завдань з урахуванням очищення: активні завдання
+мають пріоритет, застарілі завершені рядки приховуються, а нещодавні збої показуються лише тоді, коли більше не
+залишається активної роботи. Це допомагає картці статусу зосереджуватися на тому, що важливо саме зараз.
 
-## Зберігання та обслуговування
+## Зберігання й обслуговування
 
 ### Де зберігаються завдання
 
@@ -275,50 +276,50 @@ Tasks: 3 queued · 2 running · 1 issues
 $OPENCLAW_STATE_DIR/tasks/runs.sqlite
 ```
 
-Реєстр завантажується в пам’ять під час запуску Gateway і синхронізує записи в SQLite для надійності між перезапусками.
+Реєстр завантажується в пам’ять під час запуску Gateway і синхронізує записи в SQLite для стійкості між перезапусками.
 
 ### Автоматичне обслуговування
 
 Очищувач запускається кожні **60 секунд** і виконує три дії:
 
-1. **Звіряння** — перевіряє, чи активні завдання все ще мають авторитетну основу в середовищі виконання. Завдання ACP/субагентів використовують стан дочірнього сеансу, завдання Cron — належність до активного завдання, а чат-орієнтовані завдання CLI — контекст запуску-власника. Якщо цей стан-основа відсутній понад 5 хвилин, завдання позначається як `lost`.
-2. **Проставлення позначок очищення** — встановлює часову позначку `cleanupAfter` для термінальних завдань (`endedAt + 7 days`).
-3. **Видалення застарілих даних** — видаляє записи після настання дати `cleanupAfter`.
+1. **Узгодження** — перевіряє, чи активні завдання все ще мають авторитетне базове середовище виконання. Завдання ACP/субагентів використовують стан дочірнього сеансу, завдання Cron — володіння активним завданням, а CLI-завдання на основі чату — базовий контекст запуску. Якщо цей базовий стан відсутній понад 5 хвилин, завдання позначається як `lost`.
+2. **Проставлення очищення** — встановлює часову позначку `cleanupAfter` для термінальних завдань (`endedAt + 7 days`).
+3. **Видалення** — видаляє записи після настання дати `cleanupAfter`.
 
-**Термін зберігання**: записи термінальних завдань зберігаються **7 днів**, після чого автоматично видаляються. Додаткового налаштування не потрібно.
+**Термін зберігання**: термінальні записи завдань зберігаються **7 днів**, після чого автоматично видаляються. Налаштування не потрібне.
 
 ## Як завдання пов’язані з іншими системами
 
-### Завдання і Task Flow
+### Завдання і TaskFlow
 
-[Task Flow](/uk/automation/taskflow) — це рівень оркестрації потоків над фоновими завданнями. Один потік може координувати кілька завдань протягом свого життєвого циклу, використовуючи керовані або дзеркальні режими синхронізації. Використовуйте `openclaw tasks` для перегляду окремих записів завдань і `openclaw tasks flow` для перегляду оркеструвального потоку.
+[TaskFlow](/uk/automation/taskflow) — це рівень оркестрації потоків над фоновими завданнями. Протягом свого життєвого циклу один потік може координувати кілька завдань, використовуючи керовані або дзеркальні режими синхронізації. Використовуйте `openclaw tasks`, щоб переглядати окремі записи завдань, і `openclaw tasks flow`, щоб переглядати оркеструвальний потік.
 
-Докладніше див. у [Task Flow](/uk/automation/taskflow).
+Докладніше див. у [TaskFlow](/uk/automation/taskflow).
 
 ### Завдання і Cron
 
-**Визначення** завдання Cron зберігається в `~/.openclaw/cron/jobs.json`; стан виконання під час роботи зберігається поруч у `~/.openclaw/cron/jobs-state.json`. **Кожне** виконання Cron створює запис завдання — і в основному сеансі, і в ізольованому. Завдання Cron основного сеансу за замовчуванням мають політику сповіщень `silent`, тому вони відстежуються без створення сповіщень.
+**Визначення** завдання Cron зберігається в `~/.openclaw/cron/jobs.json`; стан виконання середовища зберігається поруч у `~/.openclaw/cron/jobs-state.json`. **Кожне** виконання Cron створює запис завдання — і в основному сеансі, і в ізольованому. Завдання Cron основного сеансу типово використовують політику сповіщень `silent`, тому вони відстежуються без створення сповіщень.
 
 Див. [Завдання Cron](/uk/automation/cron-jobs).
 
 ### Завдання і Heartbeat
 
-Запуски Heartbeat — це ходи основного сеансу, вони не створюють записів завдань. Коли завдання завершується, воно може ініціювати пробудження Heartbeat, щоб ви швидше побачили результат.
+Запуски Heartbeat — це ходи основного сеансу, вони не створюють записів завдань. Коли завдання завершується, воно може ініціювати пробудження Heartbeat, щоб ви швидко побачили результат.
 
 Див. [Heartbeat](/uk/gateway/heartbeat).
 
 ### Завдання і сеанси
 
-Завдання може посилатися на `childSessionKey` (де виконується робота) і `requesterSessionKey` (хто її запустив). Сеанси — це контекст розмови; завдання — це відстеження активності поверх нього.
+Завдання може посилатися на `childSessionKey` (де виконується робота) і `requesterSessionKey` (хто її запустив). Сеанси — це контекст розмови; завдання — це надбудова для відстеження активності.
 
 ### Завдання і запуски агентів
 
-`runId` завдання пов’язує його із запуском агента, який виконує роботу. Події життєвого циклу агента (початок, завершення, помилка) автоматично оновлюють статус завдання — вам не потрібно керувати життєвим циклом вручну.
+`runId` завдання пов’язує його із запуском агента, який виконує роботу. Події життєвого циклу агента (запуск, завершення, помилка) автоматично оновлюють статус завдання — вам не потрібно керувати життєвим циклом вручну.
 
 ## Пов’язане
 
-- [Автоматизація й завдання](/uk/automation) — огляд усіх механізмів автоматизації
-- [Task Flow](/uk/automation/taskflow) — оркестрація потоків над завданнями
+- [Автоматизація та завдання](/uk/automation) — огляд усіх механізмів автоматизації
+- [TaskFlow](/uk/automation/taskflow) — оркестрація потоків над завданнями
 - [Заплановані завдання](/uk/automation/cron-jobs) — планування фонової роботи
 - [Heartbeat](/uk/gateway/heartbeat) — періодичні ходи основного сеансу
 - [CLI: Tasks](/cli/index#tasks) — довідка з команд CLI
diff --git a/docs/uk/tools/subagents.md b/docs/uk/tools/subagents.md
index 78b20c58a..452abb6cc 100644
--- a/docs/uk/tools/subagents.md
+++ b/docs/uk/tools/subagents.md
@@ -1,26 +1,26 @@
 ---
 read_when:
-    - Вам потрібна фонова/паралельна робота через агента
-    - Ви змінюєте політику sessions_spawn або інструментів субагентів
-    - Ви реалізуєте або усуваєте проблеми із сесіями субагентів, прив’язаними до тредів
-summary: 'Субагенти: запуск ізольованих агентних виконань, які повідомляють про результати назад у чат запитувача'
-title: Субагенти
+    - Ви хочете фонову/паралельну роботу через агента
+    - Ви змінюєте політику інструмента `sessions_spawn` або підагентів
+    - Ви впроваджуєте або усуваєте несправності сеансів підагентів, прив’язаних до потоку
+summary: 'Підагенти: запуск ізольованих агентних виконань, які повідомляють про результати назад у чат запитувача'
+title: Підагенти
 x-i18n:
-    generated_at: "2026-04-05T18:21:59Z"
+    generated_at: "2026-04-21T19:01:11Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 9df7cc35a3069ce4eb9c92a95df3ce5365a00a3fae92ff73def75461b58fec3f
+    source_hash: 218913f0db88d40e1b5fdb0201b8d23e7af23df572c86ff4be2637cb62498281
     source_path: tools/subagents.md
     workflow: 15
 ---
 
-# Субагенти
+# Підагенти
 
-Субагенти — це фонові агентні виконання, запущені з наявного агентного виконання. Вони працюють у власній сесії (`agent:<agentId>:subagent:<uuid>`) і після завершення **повідомляють** про свій результат назад у чат-канал запитувача. Кожне виконання субагента відстежується як [фонове завдання](/uk/automation/tasks).
+Підагенти — це фонові агентні запуски, породжені з наявного агентного запуску. Вони працюють у власному сеансі (`agent:<agentId>:subagent:<uuid>`) і після завершення **повідомляють** про свій результат назад у чат-канал запитувача. Кожен запуск підагента відстежується як [фонове завдання](/uk/automation/tasks).
 
-## Слеш-команда
+## Slash-команда
 
-Використовуйте `/subagents`, щоб переглядати або керувати виконаннями субагентів для **поточної сесії**:
+Використовуйте `/subagents`, щоб переглядати або керувати запусками підагентів для **поточного сеансу**:
 
 - `/subagents list`
 - `/subagents kill <id|#|all>`
@@ -30,9 +30,9 @@ x-i18n:
 - `/subagents steer <id|#> <message>`
 - `/subagents spawn <agentId> <task> [--model <model>] [--thinking <level>]`
 
-Елементи керування прив’язкою до тредів:
+Елементи керування прив’язкою до потоку:
 
-Ці команди працюють у каналах, які підтримують постійні прив’язки тредів. Див. **Канали з підтримкою тредів** нижче.
+Ці команди працюють у каналах, які підтримують постійні прив’язки до потоків. Див. **Канали з підтримкою потоків** нижче.
 
 - `/focus <subagent-label|session-key|session-id|session-label>`
 - `/unfocus`
@@ -40,129 +40,129 @@ x-i18n:
 - `/session idle <duration|off>`
 - `/session max-age <duration|off>`
 
-`/subagents info` показує метадані виконання (статус, часові мітки, id сесії, шлях до транскрипту, очищення).
-Використовуйте `sessions_history` для обмеженого, відфільтрованого з погляду безпеки представлення для згадування; перевіряйте
-шлях до транскрипту на диску, коли вам потрібен сирий повний транскрипт.
+`/subagents info` показує метадані запуску (статус, часові мітки, id сеансу, шлях до транскрипту, очищення).
+Використовуйте `sessions_history` для обмеженого, відфільтрованого з міркувань безпеки перегляду історії; переглядайте
+шлях до транскрипту на диску, коли вам потрібен необроблений повний транскрипт.
 
-### Поведінка spawn
+### Поведінка запуску
 
-`/subagents spawn` запускає фонового субагента як команду користувача, а не як внутрішню ретрансляцію, і надсилає одне фінальне оновлення про завершення назад у чат запитувача, коли виконання завершується.
+`/subagents spawn` запускає фоновий підагент як команду користувача, а не як внутрішню ретрансляцію, і надсилає одне фінальне оновлення про завершення назад у чат запитувача, коли запуск завершується.
 
-- Команда spawn є неблокувальною; вона одразу повертає id виконання.
-- Після завершення субагент повідомляє зведення/результат назад у чат-канал запитувача.
-- Доставка після завершення є push-орієнтованою. Після запуску не потрібно опитувати `/subagents list`,
-  `sessions_list` або `sessions_history` у циклі лише для очікування
+- Команда spawn не блокує виконання; вона негайно повертає id запуску.
+- Після завершення підагент повідомляє підсумкове повідомлення/результат назад у чат-канал запитувача.
+- Доставка завершення є push-орієнтованою. Після запуску не опитуйте `/subagents list`,
+  `sessions_list` або `sessions_history` у циклі лише для того, щоб дочекатися
   завершення; перевіряйте статус тільки за потреби для налагодження або втручання.
-- Після завершення OpenClaw за принципом best-effort закриває відстежувані вкладки/процеси браузера, відкриті цією сесією субагента, до продовження потоку очищення повідомлення.
+- Після завершення OpenClaw у межах best-effort закриває відстежувані вкладки браузера/процеси, відкриті цим сеансом підагента, перш ніж потік очищення повідомлення про завершення продовжиться.
 - Для ручних запусків доставка є стійкою:
-  - OpenClaw спочатку намагається виконати пряму доставку `agent` зі стабільним ключем ідемпотентності.
-  - Якщо пряма доставка не вдається, він повертається до маршрутизації через чергу.
-  - Якщо маршрутизація через чергу все ще недоступна, спроба повідомлення повторюється з короткою експоненційною затримкою перед остаточною відмовою.
-- Доставка після завершення зберігає визначений маршрут запитувача:
-  - маршрути завершення, прив’язані до треда або розмови, мають пріоритет, коли доступні
-  - якщо джерело завершення надає лише канал, OpenClaw заповнює відсутні target/account із визначеного маршруту сесії запитувача (`lastChannel` / `lastTo` / `lastAccountId`), щоб пряма доставка все одно працювала
-- Передача завершення до сесії запитувача — це внутрішній контекст, згенерований runtime (а не текст, створений користувачем), і вона включає:
-  - `Result` (останній видимий текст відповіді `assistant`, інакше санітизований останній текст tool/toolResult)
+  - OpenClaw спочатку намагається пряму доставку `agent` зі стабільним ключем ідемпотентності.
+  - Якщо пряма доставка не вдається, система переходить до маршрутизації через чергу.
+  - Якщо маршрутизація через чергу все ще недоступна, спроба повідомлення повторюється з коротким експоненційним backoff перед остаточною відмовою.
+- Доставка завершення зберігає визначений маршрут запитувача:
+  - маршрути завершення, прив’язані до потоку або до розмови, мають пріоритет, коли вони доступні
+  - якщо джерело завершення надає лише канал, OpenClaw заповнює відсутні target/account із визначеного маршруту сеансу запитувача (`lastChannel` / `lastTo` / `lastAccountId`), щоб пряма доставка все одно працювала
+- Передача завершення до сеансу запитувача — це внутрішній контекст, згенерований під час виконання (а не текст, створений користувачем), і вона включає:
+  - `Result` (останній видимий текст відповіді `assistant`, або, якщо його немає, санітизований останній текст tool/toolResult; термінальні невдалі запуски не використовують повторно захоплений текст відповіді)
   - `Status` (`completed successfully` / `failed` / `timed out` / `unknown`)
-  - компактну статистику runtime/токенів
-  - інструкцію доставки, яка вказує агенту запитувача переписати це звичайним голосом помічника (а не пересилати сирі внутрішні метадані)
+  - компактну статистику виконання/токенів
+  - інструкцію з доставки, яка наказує агенту запитувача переписати повідомлення звичайним голосом помічника (а не пересилати необроблені внутрішні метадані)
 - `--model` і `--thinking` перевизначають типові значення для цього конкретного запуску.
-- Використовуйте `info`/`log`, щоб перевіряти подробиці та вивід після завершення.
-- `/subagents spawn` — це режим одноразового запуску (`mode: "run"`). Для постійних сесій, прив’язаних до тредів, використовуйте `sessions_spawn` із `thread: true` і `mode: "session"`.
-- Для ACP harness-сесій (Codex, Claude Code, Gemini CLI) використовуйте `sessions_spawn` із `runtime: "acp"` і див. [ACP-агенти](/tools/acp-agents).
+- Використовуйте `info`/`log`, щоб переглянути подробиці та вивід після завершення.
+- `/subagents spawn` — це одноразовий режим (`mode: "run"`). Для постійних сеансів, прив’язаних до потоку, використовуйте `sessions_spawn` з `thread: true` і `mode: "session"`.
+- Для сеансів harness ACP (Codex, Claude Code, Gemini CLI) використовуйте `sessions_spawn` з `runtime: "acp"` і див. [ACP Agents](/uk/tools/acp-agents).
 
 Основні цілі:
 
-- Розпаралелювати роботу типу «дослідження / довге завдання / повільний інструмент» без блокування основного виконання.
-- Ізолювати субагентів типово (розділення сесій + необов’язкова ізоляція).
-- Зробити поверхню інструментів важкою для неправильного використання: субагенти типово **не** отримують інструменти сесій.
+- Паралелізувати роботу типу «дослідження / довге завдання / повільний інструмент», не блокуючи основний запуск.
+- За замовчуванням зберігати ізоляцію підагентів (розділення сеансів + необов’язковий sandboxing).
+- Зберігати поверхню інструментів складною для неправильного використання: підагенти **не** отримують інструменти сеансу за замовчуванням.
 - Підтримувати налаштовувану глибину вкладеності для шаблонів оркестрації.
 
-Примітка щодо вартості: кожен субагент має **власний** контекст і власне використання токенів. Для важких або повторюваних
-завдань установіть для субагентів дешевшу модель, а основного агента залиште на якіснішій моделі.
+Примітка щодо вартості: кожен підагент має **власний** контекст і власне використання токенів. Для важких або повторюваних
+завдань установіть для підагентів дешевшу модель, а основного агента залиште на якіснішій моделі.
 Це можна налаштувати через `agents.defaults.subagents.model` або через перевизначення для окремих агентів.
 
 ## Інструмент
 
 Використовуйте `sessions_spawn`:
 
-- Запускає виконання субагента (`deliver: false`, глобальна lane: `subagent`)
-- Потім виконує крок повідомлення та публікує відповідь-повідомлення назад у чат-канал запитувача
-- Типова модель: успадковується від виклику, якщо ви не встановите `agents.defaults.subagents.model` (або `agents.list[].subagents.model` для окремого агента); явне `sessions_spawn.model` усе одно має пріоритет.
-- Типове thinking: успадковується від виклику, якщо ви не встановите `agents.defaults.subagents.thinking` (або `agents.list[].subagents.thinking` для окремого агента); явне `sessions_spawn.thinking` усе одно має пріоритет.
-- Типовий timeout виконання: якщо `sessions_spawn.runTimeoutSeconds` не задано, OpenClaw використовує `agents.defaults.subagents.runTimeoutSeconds`, якщо його встановлено; інакше використовується `0` (без timeout).
+- Запускає підагентний запуск (`deliver: false`, глобальна смуга: `subagent`)
+- Потім виконує крок повідомлення та публікує відповідь-повідомлення в чат-канал запитувача
+- Типова модель: успадковується від викликача, якщо ви не встановите `agents.defaults.subagents.model` (або `agents.list[].subagents.model` для окремого агента); явне `sessions_spawn.model` усе одно має пріоритет.
+- Типовий thinking: успадковується від викликача, якщо ви не встановите `agents.defaults.subagents.thinking` (або `agents.list[].subagents.thinking` для окремого агента); явне `sessions_spawn.thinking` усе одно має пріоритет.
+- Типовий тайм-аут запуску: якщо `sessions_spawn.runTimeoutSeconds` пропущено, OpenClaw використовує `agents.defaults.subagents.runTimeoutSeconds`, якщо його встановлено; інакше використовується `0` (без тайм-ауту).
 
 Параметри інструмента:
 
-- `task` (обов’язково)
-- `label?` (необов’язково)
-- `agentId?` (необов’язково; запуск під іншим id агента, якщо дозволено)
-- `model?` (необов’язково; перевизначає модель субагента; невалідні значення пропускаються, і субагент працює на типовій моделі з попередженням у результаті інструмента)
-- `thinking?` (необов’язково; перевизначає рівень thinking для виконання субагента)
-- `runTimeoutSeconds?` (типово береться з `agents.defaults.subagents.runTimeoutSeconds`, якщо задано, інакше `0`; якщо встановлено, виконання субагента переривається після N секунд)
-- `thread?` (типово `false`; коли `true`, запитує прив’язку до треда каналу для цієї сесії субагента)
+- `task` (обов’язковий)
+- `label?` (необов’язковий)
+- `agentId?` (необов’язковий; запуск під іншим id агента, якщо це дозволено)
+- `model?` (необов’язковий; перевизначає модель підагента; недійсні значення пропускаються, і підагент запускається на типовій моделі з попередженням у результаті інструмента)
+- `thinking?` (необов’язковий; перевизначає рівень thinking для запуску підагента)
+- `runTimeoutSeconds?` (типово дорівнює `agents.defaults.subagents.runTimeoutSeconds`, якщо встановлено, інакше `0`; якщо встановлено, запуск підагента переривається через N секунд)
+- `thread?` (типово `false`; якщо `true`, запитує прив’язку до потоку каналу для цього сеансу підагента)
 - `mode?` (`run|session`)
-  - типове значення — `run`
-  - якщо `thread: true` і `mode` не задано, типове значення стає `session`
+  - типовим є `run`
+  - якщо `thread: true` і `mode` пропущено, типовим стає `session`
   - `mode: "session"` вимагає `thread: true`
 - `cleanup?` (`delete|keep`, типово `keep`)
-- `sandbox?` (`inherit|require`, типово `inherit`; `require` відхиляє запуск, якщо цільовий дочірній runtime не ізольований)
-- `sessions_spawn` **не** приймає параметри доставки каналу (`target`, `channel`, `to`, `threadId`, `replyTo`, `transport`). Для доставки використовуйте `message`/`sessions_send` із запущеного виконання.
+- `sandbox?` (`inherit|require`, типово `inherit`; `require` відхиляє запуск, якщо цільове дочірнє runtime не sandboxed)
+- `sessions_spawn` **не** приймає параметри доставки каналу (`target`, `channel`, `to`, `threadId`, `replyTo`, `transport`). Для доставки використовуйте `message`/`sessions_send` із запущеного сеансу.
 
-## Сесії, прив’язані до тредів
+## Сеанси, прив’язані до потоку
 
-Коли для каналу ввімкнено прив’язки тредів, субагент може залишатися прив’язаним до треда, щоб подальші повідомлення користувача в цьому треді й надалі маршрутизувалися до тієї самої сесії субагента.
+Коли для каналу ввімкнено прив’язки до потоків, підагент може залишатися прив’язаним до потоку, щоб подальші повідомлення користувача в цьому потоці й надалі маршрутизувалися до того самого сеансу підагента.
 
-### Канали з підтримкою тредів
+### Канали з підтримкою потоків
 
-- Discord (наразі єдиний підтримуваний канал): підтримує постійні сесії субагентів, прив’язані до тредів (`sessions_spawn` із `thread: true`), ручні елементи керування тредами (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) і ключі адаптера `channels.discord.threadBindings.enabled`, `channels.discord.threadBindings.idleHours`, `channels.discord.threadBindings.maxAgeHours` та `channels.discord.threadBindings.spawnSubagentSessions`.
+- Discord (наразі єдиний підтримуваний канал): підтримує постійні сеанси підагентів, прив’язані до потоку (`sessions_spawn` з `thread: true`), ручні елементи керування потоками (`/focus`, `/unfocus`, `/agents`, `/session idle`, `/session max-age`) і ключі адаптера `channels.discord.threadBindings.enabled`, `channels.discord.threadBindings.idleHours`, `channels.discord.threadBindings.maxAgeHours` та `channels.discord.threadBindings.spawnSubagentSessions`.
 
-Швидкий сценарій:
+Короткий потік роботи:
 
-1. Запустіть через `sessions_spawn` із `thread: true` (і за потреби `mode: "session"`).
-2. OpenClaw створює тред або прив’язує його до цільової сесії в активному каналі.
-3. Відповіді та подальші повідомлення в цьому треді маршрутизуються до прив’язаної сесії.
-4. Використовуйте `/session idle`, щоб переглядати/оновлювати автоматичне розфокусування за неактивністю, і `/session max-age`, щоб керувати жорстким лімітом.
-5. Використовуйте `/unfocus`, щоб відв’язати вручну.
+1. Запустіть через `sessions_spawn` із `thread: true` (і, за потреби, `mode: "session"`).
+2. OpenClaw створює потік або прив’язує потік до цільового сеансу в активному каналі.
+3. Відповіді та подальші повідомлення в цьому потоці маршрутизуються до прив’язаного сеансу.
+4. Використовуйте `/session idle`, щоб переглянути/оновити автоматичне зняття фокуса через неактивність, і `/session max-age`, щоб керувати жорстким обмеженням.
+5. Використовуйте `/unfocus`, щоб від’єднати вручну.
 
 Ручні елементи керування:
 
-- `/focus <target>` прив’язує поточний тред (або створює його) до цілі субагента/сесії.
-- `/unfocus` прибирає прив’язку для поточного прив’язаного треда.
-- `/agents` перелічує активні виконання та стан прив’язки (`thread:<id>` або `unbound`).
-- `/session idle` і `/session max-age` працюють лише для сфокусованих прив’язаних тредів.
+- `/focus <target>` прив’язує поточний потік (або створює його) до цільового підагента/сеансу.
+- `/unfocus` видаляє прив’язку для поточного прив’язаного потоку.
+- `/agents` перелічує активні запуски та стан прив’язки (`thread:<id>` або `unbound`).
+- `/session idle` і `/session max-age` працюють лише для сфокусованих прив’язаних потоків.
 
 Перемикачі конфігурації:
 
 - Глобальні типові значення: `session.threadBindings.enabled`, `session.threadBindings.idleHours`, `session.threadBindings.maxAgeHours`
-- Перевизначення каналу та ключі автоматичної прив’язки при запуску є специфічними для адаптера. Див. **Канали з підтримкою тредів** вище.
+- Перевизначення для каналу та ключі автоматичної прив’язки під час запуску залежать від адаптера. Див. **Канали з підтримкою потоків** вище.
 
-Див. [Довідник із конфігурації](/uk/gateway/configuration-reference) і [Слеш-команди](/tools/slash-commands) для актуальних подробиць щодо адаптерів.
+Див. [Configuration Reference](/uk/gateway/configuration-reference) і [Slash commands](/uk/tools/slash-commands), щоб дізнатися актуальні подробиці щодо адаптерів.
 
-Список дозволених:
+Список дозволених значень:
 
-- `agents.list[].subagents.allowAgents`: список id агентів, на які можна націлюватися через `agentId` (`["*"]` дозволяє будь-який). Типово: лише агент запитувача.
-- `agents.defaults.subagents.allowAgents`: типовий список дозволених цільових агентів, який використовується, коли агент запитувача не задає власний `subagents.allowAgents`.
-- Захист успадкування ізоляції: якщо сесія запитувача ізольована, `sessions_spawn` відхиляє цілі, які працювали б без ізоляції.
-- `agents.defaults.subagents.requireAgentId` / `agents.list[].subagents.requireAgentId`: коли true, блокують виклики `sessions_spawn`, у яких пропущено `agentId` (примушує до явного вибору профілю). Типове значення: false.
+- `agents.list[].subagents.allowAgents`: список id агентів, які можна вказувати через `agentId` (`["*"]` дозволяє будь-який). Типово: лише агент запитувача.
+- `agents.defaults.subagents.allowAgents`: типовий список дозволених цільових агентів, який використовується, коли агент запитувача не встановлює власний `subagents.allowAgents`.
+- Захист успадкування sandbox: якщо сеанс запитувача є sandboxed, `sessions_spawn` відхиляє цілі, які працювали б без sandbox.
+- `agents.defaults.subagents.requireAgentId` / `agents.list[].subagents.requireAgentId`: якщо true, блокують виклики `sessions_spawn`, у яких пропущено `agentId` (примушує до явного вибору профілю). Типово: false.
 
 Виявлення:
 
-- Використовуйте `agents_list`, щоб побачити, які id агентів зараз дозволені для `sessions_spawn`.
+- Використовуйте `agents_list`, щоб побачити, які id агентів зараз дозволено для `sessions_spawn`.
 
 Автоархівація:
 
-- Сесії субагентів автоматично архівуються після `agents.defaults.subagents.archiveAfterMinutes` (типове значення: 60).
-- Архівація використовує `sessions.delete` і перейменовує транскрипт на `*.deleted.<timestamp>` (у тій самій папці).
-- `cleanup: "delete"` архівує одразу після повідомлення (транскрипт усе одно зберігається через перейменування).
-- Автоархівація працює за принципом best-effort; відкладені таймери втрачаються, якщо gateway перезапускається.
-- `runTimeoutSeconds` **не** виконує автоархівацію; він лише зупиняє виконання. Сесія залишається до автоархівації.
-- Автоархівація однаково застосовується до сесій глибини 1 і глибини 2.
-- Очищення браузера відокремлене від очищення архіву: відстежувані вкладки/процеси браузера закриваються за принципом best-effort, коли виконання завершується, навіть якщо запис транскрипту/сесії зберігається.
+- Сеанси підагентів автоматично архівуються після `agents.defaults.subagents.archiveAfterMinutes` (типово: 60).
+- Архівування використовує `sessions.delete` і перейменовує транскрипт на `*.deleted.<timestamp>` (у тій самій папці).
+- `cleanup: "delete"` архівує негайно після повідомлення (транскрипт усе одно зберігається через перейменування).
+- Автоархівація виконується в режимі best-effort; заплановані таймери губляться, якщо Gateway перезапускається.
+- `runTimeoutSeconds` **не** виконує автоархівацію; він лише зупиняє запуск. Сеанс залишається до автоархівації.
+- Автоархівація однаково застосовується до сеансів глибини 1 і глибини 2.
+- Очищення браузера є окремим від очищення архіву: відстежувані вкладки/процеси браузера закриваються в режимі best-effort, коли запуск завершується, навіть якщо запис транскрипту/сеансу зберігається.
 
-## Вкладені субагенти
+## Вкладені підагенти
 
-Типово субагенти не можуть запускати власних субагентів (`maxSpawnDepth: 1`). Ви можете ввімкнути один рівень вкладеності, встановивши `maxSpawnDepth: 2`, що дозволяє **шаблон оркестратора**: main → субагент-оркестратор → робочі суб-субагенти.
+За замовчуванням підагенти не можуть породжувати власних підагентів (`maxSpawnDepth: 1`). Ви можете ввімкнути один рівень вкладеності, встановивши `maxSpawnDepth: 2`, що дозволяє **шаблон оркестратора**: main → підагент-оркестратор → підагент-працівник нижчого рівня.
 
 ### Як увімкнути
 
@@ -171,10 +171,10 @@ x-i18n:
   agents: {
     defaults: {
       subagents: {
-        maxSpawnDepth: 2, // дозволити субагентам запускати дочірні агенти (типово: 1)
-        maxChildrenPerAgent: 5, // максимальна кількість активних дочірніх агентів на одну сесію агента (типово: 5)
-        maxConcurrent: 8, // глобальне обмеження concurrency для lane (типово: 8)
-        runTimeoutSeconds: 900, // типовий timeout для sessions_spawn, коли його пропущено (0 = без timeout)
+        maxSpawnDepth: 2, // дозволити підагентам породжувати дочірні агенти (типово: 1)
+        maxChildrenPerAgent: 5, // максимальна кількість активних дочірніх агентів на сеанс агента (типово: 5)
+        maxConcurrent: 8, // глобальне обмеження паралельності для смуги (типово: 8)
+        runTimeoutSeconds: 900, // типовий тайм-аут для sessions_spawn, коли його пропущено (0 = без тайм-ауту)
       },
     },
   },
@@ -183,124 +183,124 @@ x-i18n:
 
 ### Рівні глибини
 
-| Глибина | Форма ключа сесії                           | Роль                                         | Може запускати?               |
-| ------- | ------------------------------------------- | -------------------------------------------- | ----------------------------- |
-| 0       | `agent:<id>:main`                           | Основний агент                               | Завжди                        |
-| 1       | `agent:<id>:subagent:<uuid>`                | Субагент (оркестратор, коли дозволено depth 2) | Лише якщо `maxSpawnDepth >= 2` |
-| 2       | `agent:<id>:subagent:<uuid>:subagent:<uuid>` | Суб-субагент (листовий worker)               | Ніколи                        |
+| Глибина | Форма ключа сеансу                           | Роль                                          | Може породжувати?            |
+| ------- | -------------------------------------------- | --------------------------------------------- | ---------------------------- |
+| 0       | `agent:<id>:main`                            | Основний агент                                | Завжди                       |
+| 1       | `agent:<id>:subagent:<uuid>`                 | Підагент (оркестратор, якщо дозволено глибину 2) | Лише якщо `maxSpawnDepth >= 2` |
+| 2       | `agent:<id>:subagent:<uuid>:subagent:<uuid>` | Підагент другого рівня (кінцевий виконавець)  | Ніколи                       |
 
 ### Ланцюжок повідомлень
 
-Результати рухаються вгору по ланцюжку:
+Результати повертаються вгору по ланцюжку:
 
-1. Worker глибини 2 завершується → повідомляє своєму батьківському оркестратору (глибина 1)
+1. Працівник глибини 2 завершується → повідомляє своєму батьківському елементу (оркестратору глибини 1)
 2. Оркестратор глибини 1 отримує повідомлення, синтезує результати, завершується → повідомляє main
-3. Основний агент отримує повідомлення та доставляє його користувачу
+3. Основний агент отримує повідомлення і доставляє його користувачу
 
-Кожен рівень бачить повідомлення лише від своїх прямих дочірніх елементів.
+Кожен рівень бачить лише повідомлення від своїх прямих дочірніх елементів.
 
 Операційні рекомендації:
 
-- Запускайте дочірню роботу один раз і чекайте подій завершення замість побудови циклів опитування
-  навколо `sessions_list`, `sessions_history`, `/subagents list` або
-  `exec`-команд зі sleep.
-- Якщо подія завершення дочірнього елемента надходить після того, як ви вже надіслали фінальну відповідь,
-  правильною подальшою дією є точний тихий токен `NO_REPLY` / `no_reply`.
+- Запускайте дочірню роботу один раз і чекайте на події завершення замість побудови циклів
+  опитування навколо `sessions_list`, `sessions_history`, `/subagents list` або
+  команд `exec` із sleep.
+- Якщо подія завершення дочірнього елемента приходить після того, як ви вже надіслали фінальну відповідь,
+  правильна подальша дія — це точний беззвучний токен `NO_REPLY` / `no_reply`.
 
 ### Політика інструментів за глибиною
 
-- Роль і область керування записуються в метадані сесії під час spawn. Це не дає плоским або відновленим ключам сесії випадково знову отримати привілеї оркестратора.
-- **Глибина 1 (оркестратор, коли `maxSpawnDepth >= 2`)**: отримує `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, щоб керувати своїми дочірніми елементами. Інші інструменти сесії/системи залишаються забороненими.
-- **Глибина 1 (листовий елемент, коли `maxSpawnDepth == 1`)**: без інструментів сесії (поточна типова поведінка).
-- **Глибина 2 (листовий worker)**: без інструментів сесії — `sessions_spawn` завжди заборонений на глибині 2. Подальших дочірніх елементів запускати не може.
+- Роль і область керування записуються в метадані сеансу під час запуску. Це не дає пласким або відновленим ключам сеансу випадково знову отримати привілеї оркестратора.
+- **Глибина 1 (оркестратор, коли `maxSpawnDepth >= 2`)**: отримує `sessions_spawn`, `subagents`, `sessions_list`, `sessions_history`, щоб керувати своїми дочірніми елементами. Інші інструменти сеансу/системи залишаються забороненими.
+- **Глибина 1 (кінцевий виконавець, коли `maxSpawnDepth == 1`)**: без інструментів сеансу (поточна типова поведінка).
+- **Глибина 2 (кінцевий працівник)**: без інструментів сеансу — `sessions_spawn` на глибині 2 завжди заборонено. Не може породжувати подальших дочірніх елементів.
 
-### Обмеження запуску для окремого агента
+### Ліміт запусків для окремого агента
 
-Кожна сесія агента (на будь-якій глибині) може мати не більше `maxChildrenPerAgent` (типово: 5) активних дочірніх елементів одночасно. Це запобігає неконтрольованому розгалуженню від одного оркестратора.
+Кожен сеанс агента (на будь-якій глибині) може одночасно мати не більше `maxChildrenPerAgent` (типово: 5) активних дочірніх елементів. Це запобігає неконтрольованому розгалуженню від одного оркестратора.
 
 ### Каскадна зупинка
 
 Зупинка оркестратора глибини 1 автоматично зупиняє всіх його дочірніх елементів глибини 2:
 
 - `/stop` в основному чаті зупиняє всіх агентів глибини 1 і каскадно зупиняє їхніх дочірніх елементів глибини 2.
-- `/subagents kill <id>` зупиняє конкретного субагента і каскадно зупиняє його дочірніх елементів.
-- `/subagents kill all` зупиняє всіх субагентів для запитувача і виконує каскадну зупинку.
+- `/subagents kill <id>` зупиняє конкретного підагента і каскадно зупиняє його дочірні елементи.
+- `/subagents kill all` зупиняє всіх підагентів для запитувача і каскадно зупиняє їх.
 
 ## Автентифікація
 
-Автентифікація субагента визначається за **id агента**, а не за типом сесії:
+Автентифікація підагента визначається за **id агента**, а не за типом сеансу:
 
-- Ключ сесії субагента — `agent:<agentId>:subagent:<uuid>`.
-- Сховище auth завантажується з `agentDir` цього агента.
-- Профілі auth основного агента зливаються як **fallback**; профілі агента мають пріоритет у разі конфліктів.
+- Ключ сеансу підагента — `agent:<agentId>:subagent:<uuid>`.
+- Сховище автентифікації завантажується з `agentDir` цього агента.
+- Профілі автентифікації основного агента додаються як **резервний** варіант; профілі агента мають пріоритет над профілями основного агента в разі конфліктів.
 
-Примітка: злиття є адитивним, тож профілі основного агента завжди доступні як fallback. Повністю ізольована auth для кожного агента поки що не підтримується.
+Примітка: злиття є адитивним, тому профілі основного агента завжди доступні як резервні. Повністю ізольована автентифікація для кожного агента поки не підтримується.
 
 ## Повідомлення
 
-Субагенти звітують назад через крок повідомлення:
+Підагенти звітують назад через крок повідомлення:
 
-- Крок повідомлення виконується всередині сесії субагента (а не сесії запитувача).
-- Якщо субагент відповідає точно `ANNOUNCE_SKIP`, нічого не публікується.
-- Якщо останній текст помічника — це точний тихий токен `NO_REPLY` / `no_reply`,
+- Крок повідомлення виконується всередині сеансу підагента (а не сеансу запитувача).
+- Якщо підагент відповідає рівно `ANNOUNCE_SKIP`, нічого не публікується.
+- Якщо останній текст `assistant` — це точний беззвучний токен `NO_REPLY` / `no_reply`,
   вивід повідомлення пригнічується, навіть якщо раніше був видимий прогрес.
 - Інакше доставка залежить від глибини запитувача:
-  - сесії запитувача верхнього рівня використовують подальший виклик `agent` із зовнішньою доставкою (`deliver=true`)
-  - вкладені сесії субагентів-запитувачів отримують внутрішню ін’єкцію подальшої дії (`deliver=false`), щоб оркестратор міг синтезувати результати дочірніх елементів у межах сесії
-  - якщо вкладена сесія субагента-запитувача зникла, OpenClaw повертається до запитувача цієї сесії, коли це можливо
-- Для сесій запитувача верхнього рівня пряма доставка в режимі завершення спочатку визначає будь-який маршрут прив’язаної розмови/треда та перевизначення hook, а потім заповнює відсутні поля channel-target із збереженого маршруту сесії запитувача. Це зберігає доставки завершення в правильному чаті/темі, навіть коли джерело завершення ідентифікує лише канал.
-- Агрегація завершень дочірніх елементів обмежується поточним виконанням запитувача під час побудови вкладених результатів завершення, що запобігає витоку застарілих виводів дочірніх елементів із попередніх запусків у поточне повідомлення.
-- Відповіді-повідомлення зберігають маршрутизацію треда/теми, коли вона доступна в адаптерах каналів.
-- Контекст повідомлення нормалізується до стабільного внутрішнього блоку подій:
+  - сеанси запитувача верхнього рівня використовують подальший виклик `agent` із зовнішньою доставкою (`deliver=true`)
+  - вкладені сеанси підагентів запитувача отримують внутрішнє подальше впровадження (`deliver=false`), щоб оркестратор міг синтезувати результати дочірніх елементів у межах сеансу
+  - якщо вкладений сеанс підагента запитувача зник, OpenClaw, коли це можливо, повертається до запитувача цього сеансу
+- Для сеансів запитувача верхнього рівня пряма доставка в режимі завершення спочатку визначає будь-який маршрут прив’язаної розмови/потоку та перевизначення hook, а потім заповнює відсутні поля цілі каналу зі збереженого маршруту сеансу запитувача. Це зберігає завершення в правильному чаті/темі, навіть коли джерело завершення вказує лише канал.
+- Агрегація завершення дочірніх елементів обмежується поточним запуском запитувача під час побудови вкладених результатів завершення, що запобігає витоку застарілих виводів дочірніх елементів з попередніх запусків у поточне повідомлення.
+- Відповіді повідомлення зберігають маршрутизацію потоку/теми, коли вона доступна в адаптерах каналів.
+- Контекст повідомлення нормалізується до стабільного внутрішнього блоку події:
   - джерело (`subagent` або `cron`)
-  - ключ/id дочірньої сесії
+  - ключ/id дочірнього сеансу
   - тип повідомлення + мітка завдання
-  - рядок статусу, похідний від результату runtime (`success`, `error`, `timeout` або `unknown`)
-  - вміст результату, вибраний з останнього видимого тексту помічника, інакше санітизований останній текст tool/toolResult
-  - інструкція подальшої дії, яка описує, коли слід відповідати, а коли мовчати
-- `Status` не виводиться з виводу моделі; він походить із сигналів результату runtime.
-- У разі timeout, якщо дочірній елемент встиг лише до викликів інструментів, повідомлення може згорнути цю історію в коротке зведення часткового прогресу замість відтворення сирого виводу інструментів.
+  - рядок статусу, похідний від результату виконання (`success`, `error`, `timeout` або `unknown`)
+  - вміст результату, вибраний з останнього видимого тексту `assistant`, або, якщо його немає, санітизований останній текст tool/toolResult; термінальні невдалі запуски повідомляють про статус невдачі без повторення захопленого тексту відповіді
+  - подальша інструкція, яка описує, коли відповідати, а коли залишатися безмовним
+- `Status` не виводиться з виводу моделі; він надходить із сигналів результату виконання.
+- У разі тайм-ауту, якщо дочірній елемент встиг лише виконати виклики інструментів, повідомлення може згорнути цю історію до короткого підсумку часткового прогресу замість відтворення необробленого виводу інструментів.
 
-Корисні навантаження повідомлень містять рядок статистики в кінці (навіть якщо вони обгорнуті):
+Корисні навантаження повідомлень включають рядок статистики в кінці (навіть коли вони обгорнуті):
 
 - Runtime (наприклад, `runtime 5m12s`)
 - Використання токенів (input/output/total)
-- Оцінена вартість, якщо налаштовано ціни моделей (`models.providers.*.models[].cost`)
-- `sessionKey`, `sessionId` і шлях до транскрипту (щоб основний агент міг отримати історію через `sessions_history` або перевірити файл на диску)
-- Внутрішні метадані призначені лише для оркестрації; відповіді, видимі користувачу, слід переписувати звичайним голосом помічника.
+- Оцінена вартість, якщо для моделі налаштовано ціни (`models.providers.*.models[].cost`)
+- `sessionKey`, `sessionId` і шлях до транскрипту (щоб основний агент міг отримати історію через `sessions_history` або переглянути файл на диску)
+- Внутрішні метадані призначені лише для оркестрації; відповіді для користувача слід переписувати звичайним голосом помічника.
 
 `sessions_history` — безпечніший шлях оркестрації:
 
-- згадування відповідей помічника спочатку нормалізується:
-  - thinking-теги видаляються
+- історія `assistant` спочатку нормалізується:
+  - теги thinking видаляються
   - блоки каркаса `<relevant-memories>` / `<relevant_memories>` видаляються
-  - блоки XML-корисного навантаження викликів інструментів у звичайному тексті, як-от `<tool_call>...</tool_call>`,
+  - прості текстові XML-блоки корисного навантаження викликів інструментів, як-от `<tool_call>...</tool_call>`,
     `<function_call>...</function_call>`, `<tool_calls>...</tool_calls>` і
-    `<function_calls>...</function_calls>`, видаляються, включно з обрізаними
-    payload, які так і не закриваються коректно
-  - понижений каркас викликів/результатів інструментів та маркери історичного контексту видаляються
-  - витоки керівних токенів моделі, таких як `<|assistant|>`, інші ASCII
+    `<function_calls>...</function_calls>`, видаляються, включно з усіченими
+    корисними навантаженнями, які так і не закрилися належним чином
+  - знижені до нижчого рівня каркаси викликів/результатів інструментів і маркери історичного контексту видаляються
+  - витеклі керівні токени моделі, як-от `<|assistant|>`, інші ASCII
     токени `<|...|>` і повноширинні варіанти `<｜...｜>`, видаляються
   - некоректний XML викликів інструментів MiniMax видаляється
 - текст, схожий на облікові дані/токени, редагується
-- довгі блоки можуть бути обрізані
-- у дуже великих історіях старіші рядки можуть бути відкинуті або надто великий рядок може бути замінений на
+- довгі блоки можуть бути усічені
+- дуже великі історії можуть відкидати старіші рядки або замінювати надто великий рядок на
   `[sessions_history omitted: message too large]`
-- перевірка сирого транскрипту на диску є fallback, коли вам потрібен повний побайтний транскрипт
+- перегляд необробленого транскрипту на диску — резервний варіант, коли потрібен повний транскрипт байт-у-байт
 
-## Політика інструментів (інструменти субагентів)
+## Політика інструментів (інструменти підагента)
 
-Типово субагенти отримують **усі інструменти, крім інструментів сесій** і системних інструментів:
+За замовчуванням підагенти отримують **усі інструменти, крім інструментів сеансу** та системних інструментів:
 
 - `sessions_list`
 - `sessions_history`
 - `sessions_send`
 - `sessions_spawn`
 
-`sessions_history` і тут залишається обмеженим, санітизованим представленням для згадування; це
-не сирий дамп транскрипту.
+`sessions_history` і тут залишається обмеженим, санітизованим переглядом історії; це не
+необроблений дамп транскрипту.
 
-Коли `maxSpawnDepth >= 2`, субагенти-оркестратори глибини 1 додатково отримують `sessions_spawn`, `subagents`, `sessions_list` і `sessions_history`, щоб керувати своїми дочірніми елементами.
+Коли `maxSpawnDepth >= 2`, підагенти-оркестратори глибини 1 додатково отримують `sessions_spawn`, `subagents`, `sessions_list` і `sessions_history`, щоб керувати своїми дочірніми елементами.
 
 Перевизначення через конфігурацію:
 
@@ -318,7 +318,7 @@ x-i18n:
       tools: {
         // deny має пріоритет
         deny: ["gateway", "cron"],
-        // якщо встановлено allow, політика стає лише allow-only (deny усе одно має пріоритет)
+        // якщо задано allow, діє режим лише allow (deny усе одно має пріоритет)
         // allow: ["read", "exec", "process"]
       },
     },
@@ -326,23 +326,23 @@ x-i18n:
 }
 ```
 
-## Конкурентність
+## Паралельність
 
-Субагенти використовують окрему lane черги в межах процесу:
+Підагенти використовують окрему вбудовану смугу черги:
 
-- Назва lane: `subagent`
-- Конкурентність: `agents.defaults.subagents.maxConcurrent` (типове значення `8`)
+- Назва смуги: `subagent`
+- Паралельність: `agents.defaults.subagents.maxConcurrent` (типово `8`)
 
 ## Зупинка
 
-- Надсилання `/stop` у чаті запитувача перериває сесію запитувача та зупиняє всі активні виконання субагентів, запущені з неї, із каскадним поширенням на вкладених дочірніх елементів.
-- `/subagents kill <id>` зупиняє конкретного субагента і каскадно зупиняє його дочірніх елементів.
+- Надсилання `/stop` у чаті запитувача перериває сеанс запитувача і зупиняє всі активні запуски підагентів, породжені з нього, каскадно охоплюючи вкладених дочірніх елементів.
+- `/subagents kill <id>` зупиняє конкретного підагента і каскадно зупиняє його дочірні елементи.
 
 ## Обмеження
 
-- Повідомлення субагента працює за принципом **best-effort**. Якщо gateway перезапуститься, незавершена робота «повідомити назад» буде втрачена.
-- Субагенти все ще спільно використовують ресурси того самого процесу gateway; розглядайте `maxConcurrent` як запобіжний клапан.
-- `sessions_spawn` завжди є неблокувальним: він одразу повертає `{ status: "accepted", runId, childSessionKey }`.
-- Контекст субагента ін’єктує лише `AGENTS.md` + `TOOLS.md` (без `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` або `BOOTSTRAP.md`).
+- Повідомлення підагента — у режимі **best-effort**. Якщо Gateway перезапускається, незавершена робота з «повідомлення назад» втрачається.
+- Підагенти все ще спільно використовують ресурси того самого процесу Gateway; розглядайте `maxConcurrent` як запобіжний клапан.
+- `sessions_spawn` завжди є неблокувальним: він негайно повертає `{ status: "accepted", runId, childSessionKey }`.
+- Контекст підагента впроваджує лише `AGENTS.md` + `TOOLS.md` (без `SOUL.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md` або `BOOTSTRAP.md`).
 - Максимальна глибина вкладеності — 5 (діапазон `maxSpawnDepth`: 1–5). Для більшості сценаріїв рекомендується глибина 2.
-- `maxChildrenPerAgent` обмежує кількість активних дочірніх елементів на сесію (типове значення: 5, діапазон: 1–20).
+- `maxChildrenPerAgent` обмежує кількість активних дочірніх елементів на сеанс (типово: 5, діапазон: 1–20).