diff --git a/docs/uk/concepts/system-prompt.md b/docs/uk/concepts/system-prompt.md
index 637f23342..f9d35fef5 100644
--- a/docs/uk/concepts/system-prompt.md
+++ b/docs/uk/concepts/system-prompt.md
@@ -1,81 +1,123 @@
 ---
 read_when:
-    - Редагування тексту системного промпту, списку інструментів або розділів про час/Heartbeat
-    - Зміна початкового налаштування робочого простору або поведінки впровадження Skills
-summary: Що містить системний промпт OpenClaw і як його зібрано
+    - Редагування тексту системного промпта, списку інструментів або розділів часу/Heartbeat
+    - Зміна поведінки ініціалізації робочого простору або впровадження Skills
+summary: Що містить системний промпт OpenClaw і як його збирають
 title: Системний промпт
 x-i18n:
-    generated_at: "2026-04-27T22:37:53Z"
-    model: gpt-5.4
+    generated_at: "2026-04-28T23:57:29Z"
+    model: gpt-5.5
     provider: openai
-    source_hash: 28339bd25e79c152448d66e4e0c679ff384913e12890f6f67c9c97ddacd4ddbe
+    source_hash: 8c6258ad35d679eaa2bb4d2446e9edfc6bb129888681a0e5d5527c54c5476971
     source_path: concepts/system-prompt.md
-    workflow: 15
+    workflow: 16
 ---
 
-OpenClaw створює власний системний промпт для кожного запуску агента. Промпт **належить OpenClaw** і не використовує типовий промпт pi-coding-agent.
+OpenClaw створює власний системний prompt для кожного запуску агента. Prompt **належить OpenClaw** і не використовує стандартний prompt pi-coding-agent.
 
-Промпт збирається OpenClaw і впроваджується в кожен запуск агента.
+Prompt збирається OpenClaw і вставляється в кожен запуск агента.
 
-Плагіни провайдерів можуть додавати кеш-орієнтовані вказівки для промпту, не замінюючи весь промпт, що належить OpenClaw. Середовище виконання провайдера може:
+Provider plugins можуть додавати cache-aware вказівки для prompt, не замінюючи
+повний prompt, що належить OpenClaw. Provider runtime може:
 
-- замінювати невеликий набір іменованих базових розділів (`interaction_style`, `tool_call_style`, `execution_bias`)
-- впроваджувати **стабільний префікс** над межею кешу промпту
-- впроваджувати **динамічний суфікс** під межею кешу промпту
+- замінювати невеликий набір іменованих основних секцій (`interaction_style`,
+  `tool_call_style`, `execution_bias`)
+- вставляти **стабільний префікс** над межею кешу prompt
+- вставляти **динамічний суфікс** під межею кешу prompt
 
-Використовуйте внески, що належать провайдеру, для налаштування під конкретне сімейство моделей. Зберігайте застарілу мутацію промпту `before_prompt_build` для сумісності або справді глобальних змін промпту, а не для звичайної поведінки провайдера.
+Використовуйте provider-owned внески для налаштування, специфічного для родин моделей. Залишайте застарілу
+мутацію prompt `before_prompt_build` для сумісності або справді глобальних змін prompt,
+а не для звичайної поведінки провайдера.
 
-Накладка для сімейства OpenAI GPT-5 зберігає базове правило виконання компактним і додає специфічні для моделі вказівки щодо фіксації персони, стислого виводу, дисципліни використання інструментів, паралельного пошуку, повноти результату, перевірки, відсутнього контексту та гігієни інструментів термінала.
+Оверлей родини OpenAI GPT-5 зберігає основне правило виконання невеликим і додає
+модельно-специфічні вказівки щодо persona latching, стислого виводу, дисципліни інструментів,
+паралельного пошуку, покриття deliverable, перевірки, відсутнього контексту та
+гігієни terminal-tool.
 
 ## Структура
 
-Промпт навмисно компактний і використовує фіксовані розділи:
+Prompt навмисно компактний і використовує фіксовані секції:
 
-- **Tooling**: нагадування про структуровані інструменти як джерело істини плюс вказівки щодо використання інструментів під час виконання.
-- **Execution Bias**: компактні вказівки для доведення справ до кінця: виконувати дієві запити в межах поточного ходу, продовжувати до завершення або блокування, відновлюватися після слабких результатів інструментів, перевіряти змінний стан наживо та верифікувати перед фіналізацією.
-- **Safety**: коротке нагадування про запобіжники, щоб уникати поведінки, спрямованої на здобуття влади, або обходу нагляду.
-- **Skills** (коли доступні): пояснює моделі, як завантажувати інструкції Skills за потреби.
-- **OpenClaw Self-Update**: як безпечно перевіряти конфігурацію через `config.schema.lookup`, вносити зміни в конфігурацію через `config.patch`, замінювати повну конфігурацію через `config.apply` і запускати `update.run` лише за явним запитом користувача. Інструмент `gateway`, доступний лише власнику, також відмовляється переписувати `tools.exec.ask` / `tools.exec.security`, включно із застарілими псевдонімами `tools.bash.*`, які нормалізуються до цих захищених шляхів exec.
-- **Workspace**: робочий каталог (`agents.defaults.workspace`).
-- **Documentation**: локальний шлях до документації OpenClaw (репозиторій або npm-пакет) і коли її читати.
-- **Workspace Files (injected)**: вказує, що нижче включено файли початкового налаштування.
-- **Sandbox** (коли увімкнено): вказує на ізольоване середовище виконання, шляхи пісочниці та чи доступний exec з підвищеними правами.
-- **Current Date & Time**: локальний час користувача, часовий пояс і формат часу.
-- **Reply Tags**: необов’язковий синтаксис тегів відповіді для підтримуваних провайдерів.
-- **Heartbeats**: промпт Heartbeat і поведінка підтвердження, коли Heartbeat увімкнено для типового агента.
-- **Runtime**: хост, ОС, Node, модель, корінь репозиторію (якщо виявлено), рівень міркування (один рядок).
-- **Reasoning**: поточний рівень видимості + підказка щодо перемикача /reasoning.
+- **Інструменти**: нагадування про structured-tool як source-of-truth плюс runtime-вказівки щодо використання інструментів.
+- **Ухил виконання**: компактні вказівки щодо доведення до кінця: діяти в межах поточного ходу для
+  actionable requests, продовжувати до завершення або блокування, відновлюватися після слабких результатів інструментів,
+  перевіряти змінний стан наживо та перевіряти перед фіналізацією.
+- **Безпека**: коротке нагадування про guardrail, щоб уникати power-seeking behavior або обходу нагляду.
+- **Skills** (коли доступні): повідомляє моделі, як завантажувати інструкції Skills на вимогу.
+- **Самооновлення OpenClaw**: як безпечно переглядати config за допомогою
+  `config.schema.lookup`, виправляти config через `config.patch`, замінювати повний
+  config через `config.apply` і запускати `update.run` лише за явним запитом користувача.
+  Owner-only інструмент `gateway` також відмовляється переписувати
+  `tools.exec.ask` / `tools.exec.security`, зокрема застарілі псевдоніми `tools.bash.*`,
+  які нормалізуються до цих захищених exec-шляхів.
+- **Робоча область**: робочий каталог (`agents.defaults.workspace`).
+- **Документація**: локальний шлях до документації OpenClaw (репозиторій або npm-пакет) і коли її читати.
+- **Файли робочої області (вставлені)**: вказує, що bootstrap-файли включено нижче.
+- **Sandbox** (коли ввімкнено): вказує sandboxed runtime, sandbox-шляхи та чи доступний elevated exec.
+- **Поточна дата й час**: локальний час користувача, часовий пояс і формат часу.
+- **Теги відповіді**: необов’язковий синтаксис тегів відповіді для підтримуваних провайдерів.
+- **Heartbeats**: Heartbeat prompt і поведінка ack, коли Heartbeats увімкнено для агента за замовчуванням.
+- **Runtime**: host, OS, node, model, корінь репозиторію (коли виявлено), рівень thinking (один рядок).
+- **Reasoning**: поточний рівень видимості + підказка перемикача /reasoning.
 
-Розділ Tooling також містить вказівки під час виконання для довготривалої роботи:
+OpenClaw тримає великий стабільний вміст, зокрема **Контекст проєкту**, над
+внутрішньою межею кешу prompt. Мінливі секції каналу/сесії, як-от
+вбудовані вказівки Control UI, **Messaging**, **Voice**, **Контекст групового чату**,
+**Reactions**, **Heartbeats** і **Runtime**, додаються під цією межею,
+щоб локальні бекенди з prefix caches могли повторно використовувати стабільний префікс робочої області
+між ходами каналу. Описи інструментів так само мають уникати вбудовування поточних
+назв каналів, коли прийнята схема вже містить цю runtime-деталь.
 
-- використовуйте Cron для подальших дій у майбутньому (`check back later`, нагадування, періодична робота) замість циклів сну `exec`, трюків із затримкою `yieldMs` або повторного опитування `process`
-- використовуйте `exec` / `process` лише для команд, які запускаються зараз і продовжують працювати у фоновому режимі
-- коли ввімкнено автоматичне пробудження після завершення, запустіть команду один раз і покладайтеся на push-орієнтований шлях пробудження, коли вона виводить результат або завершується з помилкою
-- використовуйте `process` для журналів, стану, введення або втручання, коли потрібно перевірити команду, що виконується
-- якщо завдання більше, надавайте перевагу `sessions_spawn`; завершення субагента працює через push і автоматично оголошується назад запитувачу
-- не опитуйте `subagents list` / `sessions_list` у циклі лише для очікування завершення
+Секція Інструменти також містить runtime-вказівки для тривалої роботи:
 
-Коли увімкнено експериментальний інструмент `update_plan`, Tooling також повідомляє моделі використовувати його лише для нетривіальної багатокрокової роботи, підтримувати рівно один крок `in_progress` і не повторювати весь план після кожного оновлення.
+- використовуйте cron для майбутнього follow-up (`check back later`, нагадування, повторювана робота)
+  замість циклів `exec` sleep, трюків із затримкою `yieldMs` або повторного опитування `process`
+- використовуйте `exec` / `process` лише для команд, які стартують зараз і продовжують виконуватися
+  у фоні
+- коли ввімкнено автоматичне пробудження після завершення, запускайте команду один раз і покладайтеся на
+  push-based wake path, коли вона видає вивід або завершується помилкою
+- використовуйте `process` для логів, статусу, вводу або втручання, коли потрібно
+  оглянути запущену команду
+- якщо завдання більше, віддавайте перевагу `sessions_spawn`; завершення sub-agent є
+  push-based і автоматично повідомляє requester
+- не опитуйте `subagents list` / `sessions_list` у циклі лише для очікування
+  завершення
 
-Запобіжники безпеки в системному промпті мають рекомендаційний характер. Вони спрямовують поведінку моделі, але не забезпечують примусове виконання політики. Для жорсткого забезпечення використовуйте політику інструментів, погодження exec, пісочницю та allowlist каналів; оператори можуть навмисно вимикати це.
+Коли експериментальний інструмент `update_plan` увімкнено, Інструменти також повідомляють
+моделі використовувати його лише для нетривіальної багатокрокової роботи, тримати рівно один
+крок `in_progress` і не повторювати весь план після кожного оновлення.
 
-У каналах із нативними картками/кнопками погодження промпт середовища виконання тепер вказує агенту спершу покладатися на цей нативний інтерфейс погодження. Він має включати ручну команду `/approve` лише тоді, коли результат інструмента вказує, що погодження в чаті недоступні або ручне погодження — єдиний шлях.
+Safety guardrails у системному prompt мають рекомендаційний характер. Вони спрямовують поведінку моделі, але не забезпечують примусове дотримання політики. Для жорсткого enforcement використовуйте policy інструментів, exec approvals, sandboxing і channel allowlists; оператори можуть вимикати їх за дизайном.
 
-## Режими промпту
+На каналах із native approval cards/buttons runtime prompt тепер повідомляє
+агенту спершу покладатися на цей native approval UI. Він має включати ручну
+команду `/approve` лише тоді, коли результат інструмента каже, що chat approvals недоступні або
+ручне approval є єдиним шляхом.
 
-OpenClaw може рендерити менші системні промпти для субагентів. Середовище виконання встановлює `promptMode` для кожного запуску (це не користувацький параметр конфігурації):
+## Режими prompt
 
-- `full` (типово): включає всі розділи вище.
-- `minimal`: використовується для субагентів; опускає **Skills**, **Memory Recall**, **OpenClaw Self-Update**, **Model Aliases**, **User Identity**, **Reply Tags**, **Messaging**, **Silent Replies** і **Heartbeats**. Tooling, **Safety**, Workspace, Sandbox, Current Date & Time (коли відомо), Runtime та впроваджений контекст залишаються доступними.
+OpenClaw може рендерити менші системні prompts для sub-agents. Runtime задає
+`promptMode` для кожного запуску (це не user-facing config):
+
+- `full` (за замовчуванням): містить усі секції вище.
+- `minimal`: використовується для sub-agents; пропускає **Skills**, **Memory Recall**, **Самооновлення OpenClaw**,
+  **Model Aliases**, **User Identity**, **Теги відповіді**,
+  **Messaging**, **Silent Replies** і **Heartbeats**. Інструменти, **Безпека**,
+  робоча область, Sandbox, Поточна дата й час (коли відомо), Runtime і вставлений
+  контекст залишаються доступними.
 - `none`: повертає лише базовий рядок ідентичності.
 
-Коли `promptMode=minimal`, додатково впроваджені промпти позначаються як **Subagent Context** замість **Group Chat Context**.
+Коли `promptMode=minimal`, додаткові вставлені prompts позначаються як **Контекст subagent**
+замість **Контекст групового чату**.
 
-Для запусків автоматичної відповіді в каналі OpenClaw може опускати загальний розділ **Silent Replies**, коли контекст прямого/групового чату вже містить визначену для конкретної розмови поведінку `NO_REPLY`. Це дозволяє уникнути дублювання механіки токенів і в глобальному системному промпті, і в контексті каналу.
+Для запусків channel auto-reply OpenClaw може пропускати загальну секцію **Silent Replies**,
+коли контекст direct/group chat уже містить розв’язану
+conversation-specific поведінку `NO_REPLY`. Це дає змогу уникнути повторення token mechanics
+і в глобальному системному prompt, і в контексті каналу.
 
-## Впровадження початкового налаштування робочого простору
+## Bootstrap-вставлення робочої області
 
-Файли початкового налаштування обрізаються і додаються в **Project Context**, щоб модель бачила контекст ідентичності та профілю без потреби в явному читанні:
+Bootstrap-файли обрізаються й додаються під **Контекст проєкту**, щоб модель бачила ідентичність і профільний контекст без явних читань:
 
 - `AGENTS.md`
 - `SOUL.md`
@@ -83,45 +125,71 @@ OpenClaw може рендерити менші системні промпти
 - `IDENTITY.md`
 - `USER.md`
 - `HEARTBEAT.md`
-- `BOOTSTRAP.md` (лише в абсолютно нових робочих просторах)
-- `MEMORY.md`, якщо присутній
+- `BOOTSTRAP.md` (лише для абсолютно нових робочих областей)
+- `MEMORY.md`, коли присутній
 
-Усі ці файли **впроваджуються у вікно контексту** на кожному ході, якщо не застосовується окремий фільтр для файлу. `HEARTBEAT.md` пропускається у звичайних запусках, коли Heartbeat вимкнено для типового агента або `agents.defaults.heartbeat.includeSystemPromptSection` має значення false. Тримайте впроваджені файли стислими — особливо `MEMORY.md`, який із часом може розростатися й призводити до неочікувано високого використання контексту та частішої Compaction.
+Усі ці файли **вставляються у вікно контексту** на кожному ході, якщо
+не застосовується file-specific gate. `HEARTBEAT.md` пропускається у звичайних запусках, коли
+Heartbeats вимкнено для агента за замовчуванням або
+`agents.defaults.heartbeat.includeSystemPromptSection` має значення false. Тримайте вставлені
+файли стислими — особливо `MEMORY.md`, який може зростати з часом і призводити до
+неочікувано високого використання контексту та частішої Compaction.
 
 <Note>
-Щоденні файли `memory/*.md` **не** є частиною звичайного початкового Project Context. У звичайних ходах доступ до них здійснюється за потреби через інструменти `memory_search` і `memory_get`, тому вони не займають місце у вікні контексту, якщо модель явно їх не читає. Виняток — порожні ходи `/new` і `/reset`: у цьому разі середовище виконання може додати нещодавню щоденну пам’ять як одноразовий блок стартового контексту для цього першого ходу.
+Щоденні файли `memory/*.md` **не** є частиною звичайного bootstrap Контексту проєкту. У звичайних ходах до них звертаються на вимогу через інструменти `memory_search` і `memory_get`, тому вони не враховуються у вікні контексту, якщо модель явно їх не читає. Голі ходи `/new` і `/reset` є винятком: runtime може додати недавню щоденну пам’ять як одноразовий блок startup-context для цього першого ходу.
 </Note>
 
-Великі файли обрізаються з маркером. Максимальний розмір для одного файлу контролюється параметром `agents.defaults.bootstrapMaxChars` (типово: 12000). Загальний обсяг впровадженого початкового вмісту для всіх файлів обмежується параметром `agents.defaults.bootstrapTotalMaxChars` (типово: 60000). Відсутні файли впроваджуються як короткий маркер відсутнього файлу. Коли відбувається обрізання, OpenClaw може впровадити блок попередження в Project Context; це керується через `agents.defaults.bootstrapPromptTruncationWarning` (`off`, `once`, `always`; типово: `once`).
+Великі файли обрізаються з маркером. Максимальний розмір на файл керується
+`agents.defaults.bootstrapMaxChars` (за замовчуванням: 12000). Загальний вставлений bootstrap
+вміст у всіх файлах обмежено `agents.defaults.bootstrapTotalMaxChars`
+(за замовчуванням: 60000). Відсутні файли вставляють короткий маркер missing-file. Коли відбувається обрізання,
+OpenClaw може вставити warning block у Контекст проєкту; керуйте цим через
+`agents.defaults.bootstrapPromptTruncationWarning` (`off`, `once`, `always`;
+за замовчуванням: `once`).
 
-Сеанси субагентів впроваджують лише `AGENTS.md` і `TOOLS.md` (інші файли початкового налаштування відфільтровуються, щоб контекст субагента залишався компактним).
+Сесії sub-agent вставляють лише `AGENTS.md` і `TOOLS.md` (інші bootstrap-файли
+відфільтровуються, щоб зберегти контекст sub-agent невеликим).
 
-Внутрішні хуки можуть перехоплювати цей крок через `agent:bootstrap`, щоб змінювати або замінювати впроваджені файли початкового налаштування (наприклад, замінювати `SOUL.md` альтернативною персоною).
+Внутрішні hooks можуть перехопити цей крок через `agent:bootstrap`, щоб змінити або замінити
+вставлені bootstrap-файли (наприклад, замінити `SOUL.md` на альтернативну persona).
 
-Якщо ви хочете, щоб агент звучав менш узагальнено, почніть із [SOUL.md Personality Guide](/uk/concepts/soul).
+Якщо ви хочете, щоб агент звучав менш generic, почніть із
+[Посібника з особистості SOUL.md](/uk/concepts/soul).
 
-Щоб перевірити, який внесок робить кожен впроваджений файл (сирий чи впроваджений розмір, обрізання, а також накладні витрати схеми інструментів), використовуйте `/context list` або `/context detail`. Див. [Context](/uk/concepts/context).
+Щоб перевірити, скільки додає кожен вставлений файл (raw vs injected, truncation, плюс tool schema overhead), використовуйте `/context list` або `/context detail`. Див. [Контекст](/uk/concepts/context).
 
 ## Обробка часу
 
-Системний промпт містить окремий розділ **Current Date & Time**, коли часовий пояс користувача відомий. Щоб зберігати кеш промпту стабільним, тепер він містить лише **часовий пояс** (без динамічного годинника або формату часу).
+Системний prompt містить окрему секцію **Поточна дата й час**, коли
+часовий пояс користувача відомий. Щоб зберегти cache-stable prompt, тепер вона містить лише
+**часовий пояс** (без динамічного годинника або формату часу).
 
-Використовуйте `session_status`, коли агенту потрібен поточний час; картка статусу містить рядок із часовою міткою. Той самий інструмент також може за потреби встановлювати перевизначення моделі для сеансу (`model=default` очищає його).
+Використовуйте `session_status`, коли агенту потрібен поточний час; status card
+містить рядок timestamp. Той самий інструмент може необов’язково встановлювати per-session model
+override (`model=default` очищає його).
 
-Налаштовується через:
+Налаштовуйте через:
 
 - `agents.defaults.userTimezone`
 - `agents.defaults.timeFormat` (`auto` | `12` | `24`)
 
-Повну інформацію про поведінку див. у [Date & Time](/uk/date-time).
+Повні подробиці поведінки див. у [Дата й час](/uk/date-time).
 
 ## Skills
 
-Коли існують відповідні Skills, OpenClaw впроваджує компактний **список доступних Skills** (`formatSkillsForPrompt`), який включає **шлях до файлу** для кожного Skill. Промпт інструктує модель використовувати `read`, щоб завантажити SKILL.md у вказаному місці (робочий простір, кероване або вбудоване розташування). Якщо жоден Skill не підходить, розділ Skills опускається.
+Коли існують eligible Skills, OpenClaw вставляє компактний **список доступних Skills**
+(`formatSkillsForPrompt`), який містить **шлях до файлу** для кожної Skill. Prompt
+інструктує модель використовувати `read`, щоб завантажити SKILL.md у вказаному
+розташуванні (workspace, managed або bundled). Якщо eligible Skills немає, секція
+Skills пропускається.
 
-Відповідність включає фільтри метаданих Skill, перевірки середовища виконання/конфігурації та ефективний allowlist Skills агента, коли налаштовано `agents.defaults.skills` або `agents.list[].skills`.
+Eligibility включає skill metadata gates, runtime environment/config checks
+і effective agent skill allowlist, коли налаштовано `agents.defaults.skills` або
+`agents.list[].skills`.
 
-Skills, вбудовані в плагін, підходять лише тоді, коли плагін-власник увімкнений. Це дозволяє плагінам інструментів надавати глибші операційні інструкції, не вбудовуючи всі ці вказівки безпосередньо в опис кожного інструмента.
+Plugin-bundled Skills eligible лише тоді, коли їхній owning plugin увімкнено.
+Це дає tool plugins змогу надавати глибші operating guides без вбудовування всіх
+цих вказівок безпосередньо в кожен опис інструмента.
 
 ```
 <available_skills>
@@ -133,33 +201,42 @@ Skills, вбудовані в плагін, підходять лише тоді
 </available_skills>
 ```
 
-Це зберігає базовий промпт компактним і водночас дає змогу цільово використовувати Skills.
+Це зберігає base prompt малим, водночас даючи змогу targeted skill usage.
 
 Бюджет списку Skills належить підсистемі Skills:
 
-- Глобальне типове значення: `skills.limits.maxSkillsPromptChars`
-- Перевизначення для окремого агента: `agents.list[].skillsLimits.maxSkillsPromptChars`
+- Глобальне значення за замовчуванням: `skills.limits.maxSkillsPromptChars`
+- Перевизначення на агента: `agents.list[].skillsLimits.maxSkillsPromptChars`
 
-Загальні обмежені витяги середовища виконання використовують іншу поверхню:
+Generic bounded runtime excerpts використовують іншу surface:
 
 - `agents.defaults.contextLimits.*`
 - `agents.list[].contextLimits.*`
 
-Такий поділ зберігає розмір Skills окремим від розміру читання/впровадження під час виконання, наприклад для `memory_get`, результатів живих інструментів і оновлення AGENTS.md після Compaction.
+Такий поділ тримає sizing Skills окремо від runtime read/injection sizing, як-от
+`memory_get`, live tool results і оновлення AGENTS.md після Compaction.
 
-## Documentation
+## Документація
 
-Системний промпт містить розділ **Documentation**. Коли локальна документація доступна, він указує на локальний каталог документації OpenClaw (`docs/` у Git checkout або документація вбудованого npm-пакета). Якщо локальна документація недоступна, використовується резервний варіант:
+Системний prompt містить секцію **Документація**. Коли локальна документація доступна, вона
+вказує на локальний каталог документації OpenClaw (`docs/` у Git checkout або bundled npm
+package docs). Якщо локальна документація недоступна, використовується fallback на
 [https://docs.openclaw.ai](https://docs.openclaw.ai).
 
-Той самий розділ також містить розташування вихідного коду OpenClaw. Git checkout надають локальний корінь вихідного коду, щоб агент міг безпосередньо перевіряти код. Установки з пакета містять URL вихідного коду GitHub і вказують агенту переглядати код там, коли документація неповна або застаріла. Промпт також згадує публічне дзеркало документації, спільноту Discord і ClawHub ([https://clawhub.ai](https://clawhub.ai)) для пошуку Skills. Він інструктує модель спершу звертатися до документації щодо поведінки OpenClaw, команд, конфігурації чи архітектури, а також самостійно запускати `openclaw status`, коли це можливо (звертаючись до користувача лише тоді, коли доступу бракує).
-Зокрема для конфігурації він спрямовує агентів до дії інструмента `gateway`
-`config.schema.lookup` для точної документації та обмежень на рівні полів, а потім до
+Та сама секція також містить розташування source OpenClaw. Git checkouts показують локальний
+source root, щоб агент міг безпосередньо переглядати код. Package installs містять GitHub
+source URL і повідомляють агенту переглядати source там, коли документація неповна або
+застаріла. Prompt також згадує public docs mirror, community Discord і ClawHub
+([https://clawhub.ai](https://clawhub.ai)) для пошуку Skills. Він повідомляє моделі
+спершу звертатися до документації щодо поведінки OpenClaw, команд, конфігурації або архітектури, а також
+самостійно запускати `openclaw status`, коли можливо (питаючи користувача лише тоді, коли не має доступу).
+Спеціально для configuration він спрямовує агентів до дії інструмента `gateway`
+`config.schema.lookup` для точних field-level docs і constraints, а потім до
 `docs/gateway/configuration.md` і `docs/gateway/configuration-reference.md`
-для ширших рекомендацій.
+для ширших вказівок.
 
 ## Пов’язане
 
-- [Середовище виконання агента](/uk/concepts/agent)
-- [Робочий простір агента](/uk/concepts/agent-workspace)
+- [Runtime агента](/uk/concepts/agent)
+- [Робоча область агента](/uk/concepts/agent-workspace)
 - [Рушій контексту](/uk/concepts/context-engine)
diff --git a/docs/uk/gateway/bonjour.md b/docs/uk/gateway/bonjour.md
index 1aa5cb97e..ae62a978c 100644
--- a/docs/uk/gateway/bonjour.md
+++ b/docs/uk/gateway/bonjour.md
@@ -1,53 +1,53 @@
 ---
 read_when:
-    - Налагодження проблем виявлення Bonjour на macOS/iOS
-    - Зміна типів сервісів mDNS, TXT-записів або UX виявлення
-summary: Виявлення та налагодження Bonjour/mDNS (маяки Gateway, клієнти та поширені режими збоїв)
+    - Налагодження проблем із виявленням Bonjour у macOS/iOS
+    - Зміна типів служб mDNS, записів TXT або UX виявлення
+summary: Виявлення + налагодження Bonjour/mDNS (маячки Gateway, клієнти та типові сценарії збоїв)
 title: Виявлення Bonjour
 x-i18n:
-    generated_at: "2026-04-27T10:59:00Z"
-    model: gpt-5.4
+    generated_at: "2026-04-28T23:57:28Z"
+    model: gpt-5.5
     provider: openai
-    source_hash: 8d00812e18ffa34cd829af88acf5c52966669cf42d4f01f7ad566587b8605ded
+    source_hash: 0720451843aae0509949324e51f3a23dc69e366e68de851c595ce76c8ab0eec9
     source_path: gateway/bonjour.md
-    workflow: 15
+    workflow: 16
 ---
 
 # Виявлення Bonjour / mDNS
 
-OpenClaw використовує Bonjour (mDNS / DNS‑SD), щоб виявити активний Gateway (кінцеву точку WebSocket).
-Multicast-пошук у `local.` — це **зручний механізм лише для LAN**. Вбудований
-плагін `bonjour` відповідає за оголошення в LAN і ввімкнений за замовчуванням. Для міжмережевого виявлення
-той самий маяк також може публікуватися через налаштований wide-area домен DNS-SD.
-Виявлення все одно працює за принципом best-effort і **не** замінює підключення через SSH або Tailnet.
+OpenClaw використовує Bonjour (mDNS / DNS‑SD) для виявлення активного Gateway (кінцевої точки WebSocket).
+Перегляд multicast `local.` — це **зручність лише для LAN**. Вбудований Plugin `bonjour`
+відповідає за оголошення в LAN і ввімкнений за замовчуванням. Для виявлення між різними мережами
+той самий маяк також можна опублікувати через налаштований домен широкозонної DNS-SD.
+Виявлення все одно працює за принципом best-effort і **не** замінює SSH або підключення на основі Tailnet.
 
-## Wide-area Bonjour (Unicast DNS-SD) через Tailscale
+## Широкозонний Bonjour (Unicast DNS-SD) через Tailscale
 
-Якщо Node і Gateway перебувають у різних мережах, multicast mDNS не перетне
-цю межу. Ви можете зберегти той самий UX виявлення, переключившись на **unicast DNS‑SD**
+Якщо вузол і gateway перебувають у різних мережах, multicast mDNS не перетне
+межу. Можна зберегти той самий UX виявлення, перемкнувшись на **unicast DNS‑SD**
 ("Wide‑Area Bonjour") через Tailscale.
 
-Кроки на високому рівні:
+Загальні кроки:
 
-1. Запустіть DNS-сервер на хості Gateway (доступний через Tailnet).
-2. Опублікуйте записи DNS‑SD для `_openclaw-gw._tcp` у виділеній зоні
+1. Запустіть DNS-сервер на хості gateway (доступний через Tailnet).
+2. Опублікуйте DNS‑SD-записи для `_openclaw-gw._tcp` у виділеній зоні
    (приклад: `openclaw.internal.`).
-3. Налаштуйте в Tailscale **split DNS**, щоб вибраний домен резолвився через цей
-   DNS-сервер для клієнтів (зокрема для iOS).
+3. Налаштуйте **split DNS** у Tailscale, щоб вибраний домен для клієнтів
+   (зокрема iOS) розв’язувався через цей DNS-сервер.
 
 OpenClaw підтримує будь-який домен виявлення; `openclaw.internal.` — лише приклад.
-Node на iOS/Android переглядають і `local.`, і ваш налаштований wide-area домен.
+Вузли iOS/Android переглядають і `local.`, і ваш налаштований широкозонний домен.
 
 ### Конфігурація Gateway (рекомендовано)
 
 ```json5
 {
-  gateway: { bind: "tailnet" }, // лише tailnet (рекомендовано)
-  discovery: { wideArea: { enabled: true } }, // вмикає публікацію wide-area DNS-SD
+  gateway: { bind: "tailnet" }, // tailnet-only (recommended)
+  discovery: { wideArea: { enabled: true } }, // enables wide-area DNS-SD publishing
 }
 ```
 
-### Одноразове налаштування DNS-сервера (хост Gateway)
+### Одноразове налаштування DNS-сервера (хост gateway)
 
 ```bash
 openclaw dns setup --apply
@@ -55,8 +55,8 @@ openclaw dns setup --apply
 
 Це встановлює CoreDNS і налаштовує його так, щоб він:
 
-- слухав порт 53 лише на Tailscale-інтерфейсах Gateway
-- обслуговував вибраний вами домен (приклад: `openclaw.internal.`) з `~/.openclaw/dns/<domain>.db`
+- слухав порт 53 лише на інтерфейсах Tailscale gateway
+- обслуговував вибраний домен (приклад: `openclaw.internal.`) з `~/.openclaw/dns/<domain>.db`
 
 Перевірте з машини, підключеної до tailnet:
 
@@ -69,55 +69,55 @@ dig @<TAILNET_IPV4> -p 53 _openclaw-gw._tcp.openclaw.internal PTR +short
 
 У консолі адміністратора Tailscale:
 
-- Додайте nameserver, що вказує на tailnet IP Gateway (UDP/TCP 53).
+- Додайте nameserver, що вказує на tailnet IP gateway (UDP/TCP 53).
 - Додайте split DNS, щоб ваш домен виявлення використовував цей nameserver.
 
-Щойно клієнти приймуть DNS tailnet, Node на iOS і виявлення через CLI зможуть переглядати
+Щойно клієнти приймуть tailnet DNS, вузли iOS і CLI-виявлення зможуть переглядати
 `_openclaw-gw._tcp` у вашому домені виявлення без multicast.
 
 ### Безпека слухача Gateway (рекомендовано)
 
-Порт Gateway WS (типово `18789`) типово прив’язується до loopback. Для доступу з LAN/tailnet
-вкажіть bind явно й залиште автентифікацію ввімкненою.
+Порт WS Gateway (за замовчуванням `18789`) типово прив’язується до loopback. Для доступу
+через LAN/tailnet явно задайте прив’язку й залиште автентифікацію ввімкненою.
 
-Для конфігурацій лише з tailnet:
+Для налаштувань лише через tailnet:
 
 - Установіть `gateway.bind: "tailnet"` у `~/.openclaw/openclaw.json`.
-- Перезапустіть Gateway (або перезапустіть застосунок macOS у рядку меню).
+- Перезапустіть Gateway (або перезапустіть застосунок у menubar macOS).
 
 ## Що оголошується
 
-Лише Gateway оголошує `_openclaw-gw._tcp`. Оголошення multicast у LAN
-забезпечується вбудованим плагіном `bonjour`; публікація wide-area DNS-SD
-залишається у власності Gateway.
+Лише Gateway оголошує `_openclaw-gw._tcp`. LAN multicast-оголошення
+надає вбудований Plugin `bonjour`; публікація широкозонної DNS-SD залишається
+у власності Gateway.
 
 ## Типи сервісів
 
-- `_openclaw-gw._tcp` — транспортний маяк gateway (використовується Node на macOS/iOS/Android).
+- `_openclaw-gw._tcp` — маяк транспорту gateway (використовується вузлами macOS/iOS/Android).
 
-## Ключі TXT (не секретні підказки)
+## TXT-ключі (несекретні підказки)
 
-Gateway оголошує невеликі не секретні підказки, щоб спростити UI-потоки:
+Gateway оголошує невеликі несекретні підказки, щоб зробити UI-потоки зручними:
 
 - `role=gateway`
-- `displayName=<дружня назва>`
+- `displayName=<friendly name>`
 - `lanHost=<hostname>.local`
 - `gatewayPort=<port>` (Gateway WS + HTTP)
-- `gatewayTls=1` (лише коли ввімкнено TLS)
-- `gatewayTlsSha256=<sha256>` (лише коли ввімкнено TLS і доступний відбиток)
-- `canvasPort=<port>` (лише коли ввімкнено хост canvas; наразі це той самий `gatewayPort`)
+- `gatewayTls=1` (лише коли TLS увімкнено)
+- `gatewayTlsSha256=<sha256>` (лише коли TLS увімкнено й fingerprint доступний)
+- `canvasPort=<port>` (лише коли canvas host увімкнено; наразі такий самий, як `gatewayPort`)
 - `transport=gateway`
-- `tailnetDns=<magicdns>` (лише в повному режимі mDNS, необов’язкова підказка, коли доступний Tailnet)
-- `sshPort=<port>` (лише в повному режимі mDNS; wide-area DNS-SD може його не включати)
-- `cliPath=<path>` (лише в повному режимі mDNS; wide-area DNS-SD все одно записує його як підказку для віддаленого встановлення)
+- `tailnetDns=<magicdns>` (лише повний режим mDNS, необов’язкова підказка, коли Tailnet доступний)
+- `sshPort=<port>` (лише повний режим mDNS; широкозонна DNS-SD може його пропускати)
+- `cliPath=<path>` (лише повний режим mDNS; широкозонна DNS-SD все одно записує його як підказку для віддаленого встановлення)
 
-Примітки щодо безпеки:
+Нотатки щодо безпеки:
 
-- TXT-записи Bonjour/mDNS **неавтентифіковані**. Клієнти не повинні вважати TXT авторитетним джерелом маршрутизації.
-- Клієнти повинні маршрутизуватися, використовуючи резолвлену кінцеву точку сервісу (SRV + A/AAAA). Розглядайте `lanHost`, `tailnetDns`, `gatewayPort` і `gatewayTlsSha256` лише як підказки.
-- Автоматичне націлювання SSH так само має використовувати резолвлений хост сервісу, а не лише підказки з TXT.
+- TXT-записи Bonjour/mDNS **не автентифіковані**. Клієнти не повинні вважати TXT авторитетним джерелом маршрутизації.
+- Клієнти мають маршрутизувати, використовуючи розв’язану кінцеву точку сервісу (SRV + A/AAAA). Вважайте `lanHost`, `tailnetDns`, `gatewayPort` і `gatewayTlsSha256` лише підказками.
+- SSH auto-targeting так само має використовувати розв’язаний хост сервісу, а не підказки лише з TXT.
 - TLS pinning ніколи не повинен дозволяти оголошеному `gatewayTlsSha256` перевизначати раніше збережений pin.
-- Node на iOS/Android мають розглядати прямі підключення на основі виявлення як **лише TLS** і вимагати явного підтвердження користувача перед довірою до відбитка при першому підключенні.
+- Вузли iOS/Android мають вважати прямі підключення на основі виявлення **лише TLS** і вимагати явного підтвердження користувача перед довірою до fingerprint уперше.
 
 ## Налагодження на macOS
 
@@ -129,62 +129,63 @@ Gateway оголошує невеликі не секретні підказки
   dns-sd -B _openclaw-gw._tcp local.
   ```
 
-- Резолв одного екземпляра (замініть `<instance>`):
+- Розв’язання одного екземпляра (замініть `<instance>`):
 
   ```bash
   dns-sd -L "<instance>" _openclaw-gw._tcp local.
   ```
 
-Якщо перегляд працює, але резолв — ні, зазвичай це означає проблему політики LAN або
-резолвера mDNS.
+Якщо перегляд працює, але розв’язання не вдається, зазвичай причина в політиці LAN або
+проблемі резолвера mDNS.
 
-## Налагодження в журналах Gateway
+## Налагодження в логах Gateway
 
-Gateway записує журнал у циклічний лог-файл (виводиться під час запуску як
+Gateway пише ротаційний файл журналу (друкується під час запуску як
 `gateway log file: ...`). Шукайте рядки `bonjour:`, особливо:
 
 - `bonjour: advertise failed ...`
+- `bonjour: suppressing ciao cancellation ...`
 - `bonjour: ... name conflict resolved` / `hostname conflict resolved`
 - `bonjour: watchdog detected non-announced service ...`
 - `bonjour: disabling advertiser after ... failed restarts ...`
 
-Bonjour використовує системне ім’я хоста для оголошеного `.local` хоста, якщо воно є
-коректною DNS-міткою. Якщо системне ім’я хоста містить пробіли, підкреслення або інший
-некоректний для DNS-мітки символ, OpenClaw використовує `openclaw.local` як резервний варіант. Установіть
-`OPENCLAW_MDNS_HOSTNAME=<name>` перед запуском Gateway, якщо вам потрібна
-явна мітка хоста.
+Bonjour використовує системне ім’я хоста для оголошеного хоста `.local`, коли воно є
+дійсною DNS-міткою. Якщо системне ім’я хоста містить пробіли, підкреслення або інший
+недійсний символ DNS-мітки, OpenClaw повертається до `openclaw.local`. Установіть
+`OPENCLAW_MDNS_HOSTNAME=<name>` перед запуском Gateway, коли потрібна явна
+мітка хоста.
 
-## Налагодження на iOS Node
+## Налагодження на вузлі iOS
 
-iOS Node використовує `NWBrowser` для виявлення `_openclaw-gw._tcp`.
+Вузол iOS використовує `NWBrowser` для виявлення `_openclaw-gw._tcp`.
 
-Щоб зібрати журнали:
+Щоб зібрати логи:
 
-- Налаштування → Gateway → Додатково → **Discovery Debug Logs**
-- Налаштування → Gateway → Додатково → **Discovery Logs** → відтворіть проблему → **Copy**
+- Settings → Gateway → Advanced → **Discovery Debug Logs**
+- Settings → Gateway → Advanced → **Discovery Logs** → відтворіть → **Copy**
 
-Журнал містить переходи станів браузера та зміни в наборі результатів.
+Журнал містить переходи станів browser і зміни набору результатів.
 
 ## Коли вимикати Bonjour
 
-Вимикайте Bonjour лише тоді, коли оголошення multicast у LAN недоступне або шкідливе.
+Вимикайте Bonjour лише тоді, коли LAN multicast-оголошення недоступне або шкідливе.
 Типовий випадок — Gateway, що працює за Docker bridge networking, WSL або
-мережевою політикою, яка відкидає multicast mDNS. У таких середовищах Gateway
-усе ще доступний через свою опубліковану URL-адресу, SSH, Tailnet або wide-area DNS-SD,
-але автоматичне виявлення в LAN працює ненадійно.
+мережевою політикою, яка відкидає mDNS multicast. У таких середовищах Gateway
+усе ще доступний через опублікований URL, SSH, Tailnet або широкозонну DNS-SD,
+але автоматичне LAN-виявлення ненадійне.
 
-Якщо проблема пов’язана з середовищем розгортання, надавайте перевагу наявному override змінної середовища:
+Віддавайте перевагу наявному перевизначенню середовища, коли проблема пов’язана з deployment:
 
 ```bash
 OPENCLAW_DISABLE_BONJOUR=1
 ```
 
-Це вимикає оголошення multicast у LAN без зміни конфігурації плагіна.
-Це безпечно для образів Docker, service files, launch scripts і одноразового
-налагодження, оскільки параметр зникає разом із середовищем.
+Це вимикає LAN multicast-оголошення без зміни конфігурації Plugin.
+Це безпечно для Docker-образів, service files, launch scripts і одноразового
+налагодження, бо налаштування зникає разом із середовищем.
 
-Використовуйте конфігурацію плагіна лише тоді, коли ви навмисно хочете вимкнути
-вбудований плагін виявлення LAN для цієї конфігурації OpenClaw:
+Використовуйте конфігурацію Plugin лише тоді, коли навмисно хочете вимкнути
+вбудований LAN discovery Plugin для цієї конфігурації OpenClaw:
 
 ```bash
 openclaw plugins disable bonjour
@@ -192,26 +193,27 @@ openclaw plugins disable bonjour
 
 ## Особливості Docker
 
-Вбудований плагін Bonjour автоматично вимикає оголошення multicast у LAN у виявлених
+Вбудований Bonjour Plugin автоматично вимикає LAN multicast-оголошення у виявлених
 контейнерах, коли `OPENCLAW_DISABLE_BONJOUR` не задано. Docker bridge networks
-зазвичай не пересилають multicast mDNS (`224.0.0.251:5353`) між контейнером
-і LAN, тому оголошення з контейнера рідко робить виявлення працездатним.
+зазвичай не пересилають mDNS multicast (`224.0.0.251:5353`) між контейнером
+і LAN, тому оголошення з контейнера рідко забезпечує роботу виявлення.
 
 Важливі особливості:
 
-- Вимкнення Bonjour не зупиняє Gateway. Воно лише зупиняє оголошення multicast у LAN.
-- Вимкнення Bonjour не змінює `gateway.bind`; Docker усе ще типово використовує
+- Вимкнення Bonjour не зупиняє Gateway. Воно лише зупиняє LAN multicast
+  оголошення.
+- Вимкнення Bonjour не змінює `gateway.bind`; Docker усе ще за замовчуванням використовує
   `OPENCLAW_GATEWAY_BIND=lan`, щоб опублікований порт хоста міг працювати.
-- Вимкнення Bonjour не вимикає wide-area DNS-SD. Використовуйте wide-area виявлення
-  або Tailnet, коли Gateway і Node не перебувають в одній LAN.
+- Вимкнення Bonjour не вимикає широкозонну DNS-SD. Використовуйте широкозонне виявлення
+  або Tailnet, коли Gateway і вузол не в одній LAN.
 - Повторне використання того самого `OPENCLAW_CONFIG_DIR` поза Docker не зберігає
-  політику автовимкнення контейнера.
+  політику автоматичного вимкнення контейнера.
 - Установлюйте `OPENCLAW_DISABLE_BONJOUR=0` лише для host networking, macvlan або іншої
-  мережі, де точно проходить multicast mDNS; установлюйте `1` для примусового вимкнення.
+  мережі, де відомо, що mDNS multicast проходить; установлюйте `1`, щоб примусово вимкнути.
 
-## Усунення несправностей вимкненого Bonjour
+## Усунення проблем із вимкненим Bonjour
 
-Якщо Node більше не виявляє Gateway автоматично після налаштування Docker:
+Якщо вузол більше не виявляє Gateway автоматично після налаштування Docker:
 
 1. Підтвердьте, у якому режимі працює Gateway: auto, forced-on чи forced-off:
 
@@ -225,60 +227,60 @@ openclaw plugins disable bonjour
    curl -fsS http://127.0.0.1:18789/healthz
    ```
 
-3. Використовуйте пряме призначення, коли Bonjour вимкнено:
+3. Використовуйте прямий target, коли Bonjour вимкнено:
    - Control UI або локальні інструменти: `http://127.0.0.1:18789`
-   - Клієнти LAN: `http://<gateway-host>:18789`
-   - Міжмережеві клієнти: Tailnet MagicDNS, Tailnet IP, тунель SSH або
-     wide-area DNS-SD
+   - LAN-клієнти: `http://<gateway-host>:18789`
+   - Клієнти між мережами: Tailnet MagicDNS, Tailnet IP, SSH tunnel або
+     широкозонна DNS-SD
 
 4. Якщо ви навмисно ввімкнули Bonjour у Docker через
-   `OPENCLAW_DISABLE_BONJOUR=0`, перевірте multicast із хоста:
+   `OPENCLAW_DISABLE_BONJOUR=0`, протестуйте multicast з хоста:
 
    ```bash
    dns-sd -B _openclaw-gw._tcp local.
    ```
 
-   Якщо перегляд порожній або журнали Gateway показують повторні скасування
-   watchdog у ciao, поверніть `OPENCLAW_DISABLE_BONJOUR=1` і використовуйте прямий
-   маршрут або маршрут через Tailnet.
+   Якщо перегляд порожній або логи Gateway показують повторні ciao watchdog
+   cancellations, відновіть `OPENCLAW_DISABLE_BONJOUR=1` і використовуйте прямий
+   або Tailnet-маршрут.
 
-## Поширені режими збоїв
+## Поширені режими відмов
 
 - **Bonjour не працює між мережами**: використовуйте Tailnet або SSH.
 - **Multicast заблоковано**: деякі Wi‑Fi-мережі вимикають mDNS.
-- **Оголошувач завис у probing/announcing**: хости із заблокованим multicast,
-  container bridges, WSL або зміни інтерфейсів можуть залишити оголошувач ciao у
+- **Advertiser застряг у probing/announcing**: хости із заблокованим multicast,
+  container bridges, WSL або зміни інтерфейсів можуть залишити ciao advertiser у
   неоголошеному стані. OpenClaw повторює спробу кілька разів, а потім вимикає Bonjour
-  для поточного процесу Gateway замість нескінченного перезапуску оголошувача.
+  для поточного процесу Gateway замість нескінченного перезапуску advertiser.
 - **Docker bridge networking**: Bonjour автоматично вимикається у виявлених контейнерах.
   Установлюйте `OPENCLAW_DISABLE_BONJOUR=0` лише для host, macvlan або іншої
-  mDNS-сумісної мережі.
-- **Сон / зміни інтерфейсів**: macOS може тимчасово втрачати результати mDNS; повторіть спробу.
-- **Перегляд працює, але резолв — ні**: використовуйте прості імена машин (уникайте емодзі або
-  розділових знаків), а потім перезапустіть Gateway. Назва екземпляра сервісу утворюється з
-  імені хоста, тому надто складні назви можуть заплутувати деякі резолвери.
+  мережі з підтримкою mDNS.
+- **Sleep / зміни інтерфейсів**: macOS може тимчасово втрачати результати mDNS; повторіть спробу.
+- **Перегляд працює, але розв’язання не вдається**: тримайте імена машин простими (уникайте emoji або
+  пунктуації), потім перезапустіть Gateway. Ім’я екземпляра сервісу походить від
+  імені хоста, тому надто складні імена можуть заплутувати деякі резолвери.
 
-## Екрановані назви екземплярів (`\032`)
+## Екрановані імена екземплярів (`\032`)
 
-Bonjour/DNS‑SD часто екранує байти в назвах екземплярів сервісу як десяткові послідовності `\DDD`
-(наприклад, пробіли стають `\032`).
+Bonjour/DNS‑SD часто екранує байти в іменах екземплярів сервісів як десяткові
+послідовності `\DDD` (наприклад, пробіли стають `\032`).
 
 - Це нормально на рівні протоколу.
-- UI мають декодувати їх для відображення (iOS використовує `BonjourEscapes.decode`).
+- UI має декодувати для відображення (iOS використовує `BonjourEscapes.decode`).
 
 ## Вимкнення / конфігурація
 
-- `openclaw plugins disable bonjour` вимикає оголошення multicast у LAN шляхом вимкнення вбудованого плагіна.
-- `openclaw plugins enable bonjour` відновлює типовий плагін виявлення LAN.
-- `OPENCLAW_DISABLE_BONJOUR=1` вимикає оголошення multicast у LAN без зміни конфігурації плагіна; приймаються truthy-значення `1`, `true`, `yes` і `on` (застаріле: `OPENCLAW_DISABLE_BONJOUR`).
-- `OPENCLAW_DISABLE_BONJOUR=0` примусово вмикає оголошення multicast у LAN, зокрема у виявлених контейнерах; приймаються falsy-значення `0`, `false`, `no` і `off`.
-- Коли `OPENCLAW_DISABLE_BONJOUR` не задано, Bonjour оголошується на звичайних хостах і автоматично вимикається у виявлених контейнерах.
-- `gateway.bind` у `~/.openclaw/openclaw.json` керує режимом bind для Gateway.
-- `OPENCLAW_SSH_PORT` перевизначає SSH-порт, коли оголошується `sshPort` (застаріле: `OPENCLAW_SSH_PORT`).
-- `OPENCLAW_TAILNET_DNS` публікує підказку MagicDNS у TXT, коли ввімкнено повний режим mDNS (застаріле: `OPENCLAW_TAILNET_DNS`).
-- `OPENCLAW_CLI_PATH` перевизначає оголошений шлях CLI (застаріле: `OPENCLAW_CLI_PATH`).
+- `openclaw plugins disable bonjour` вимикає LAN multicast-оголошення, вимикаючи вбудований Plugin.
+- `openclaw plugins enable bonjour` відновлює типовий LAN discovery Plugin.
+- `OPENCLAW_DISABLE_BONJOUR=1` вимикає LAN multicast-оголошення без зміни конфігурації Plugin; прийняті truthy-значення: `1`, `true`, `yes` і `on` (legacy: `OPENCLAW_DISABLE_BONJOUR`).
+- `OPENCLAW_DISABLE_BONJOUR=0` примусово вмикає LAN multicast-оголошення, зокрема всередині виявлених контейнерів; прийняті falsy-значення: `0`, `false`, `no` і `off`.
+- Коли `OPENCLAW_DISABLE_BONJOUR` не задано, Bonjour оголошує на звичайних хостах і автоматично вимикається всередині виявлених контейнерів.
+- `gateway.bind` у `~/.openclaw/openclaw.json` керує режимом прив’язки Gateway.
+- `OPENCLAW_SSH_PORT` перевизначає SSH-порт, коли `sshPort` оголошується (legacy: `OPENCLAW_SSH_PORT`).
+- `OPENCLAW_TAILNET_DNS` публікує підказку MagicDNS у TXT, коли ввімкнено повний режим mDNS (legacy: `OPENCLAW_TAILNET_DNS`).
+- `OPENCLAW_CLI_PATH` перевизначає оголошений шлях CLI (legacy: `OPENCLAW_CLI_PATH`).
 
 ## Пов’язана документація
 
 - Політика виявлення та вибір транспорту: [Виявлення](/uk/gateway/discovery)
-- Pairing і підтвердження Node: [Pairing Gateway](/uk/gateway/pairing)
+- Сполучення вузла + схвалення: [Сполучення Gateway](/uk/gateway/pairing)
diff --git a/docs/uk/reference/test.md b/docs/uk/reference/test.md
index a99a3db7a..de58ab0fe 100644
--- a/docs/uk/reference/test.md
+++ b/docs/uk/reference/test.md
@@ -4,53 +4,53 @@ read_when:
 summary: Як запускати тести локально (vitest) і коли використовувати режими force/coverage
 title: Тести
 x-i18n:
-    generated_at: "2026-04-28T17:51:30Z"
+    generated_at: "2026-04-28T23:57:17Z"
     model: gpt-5.5
     provider: openai
-    source_hash: d7a6f0978c874d50c60706f0336616859f6abdc49855ed768f14088c3a139e23
+    source_hash: a2159520dd308440fce5d82ba251e1f3a37bd37a152b7c5542e92f5cbf924a34
     source_path: reference/test.md
     workflow: 16
 ---
 
 - Повний набір для тестування (набори, live, Docker): [Тестування](/uk/help/testing)
 
-- `pnpm test:force`: Завершує будь-який завислий процес Gateway, що утримує стандартний контрольний порт, а потім запускає повний набір Vitest з ізольованим портом Gateway, щоб серверні тести не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск Gateway залишив порт 18789 зайнятим.
-- `pnpm test:coverage`: Запускає unit-набір із покриттям V8 (через `vitest.unit.config.ts`). Це gate покриття unit для завантажених файлів, а не покриття всіх файлів усього репозиторію. Пороги: 70% для рядків/функцій/інструкцій і 55% для гілок. Оскільки `coverage.all` має значення false, gate вимірює файли, завантажені unit-набором покриття, замість того щоб вважати кожен вихідний файл із розділеної lane непокритим.
-- `pnpm test:coverage:changed`: Запускає unit-покриття лише для файлів, змінених після `origin/main`.
-- `pnpm test:changed`: дешевий розумний запуск тестів для змін. Він запускає точні цілі з прямих змін тестів, сусідні файли `*.test.ts`, явні зіставлення джерел і локальний граф імпортів. Широкі зміни конфігурації/пакетів пропускаються, якщо вони не зіставляються з точними тестами.
-- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: явний широкий запуск тестів для змін. Використовуйте його, коли зміна test harness/конфігурації/пакета має повертатися до ширшої поведінки Vitest для changed-test.
-- `pnpm changed:lanes`: показує архітектурні lanes, спричинені diff відносно `origin/main`.
-- `pnpm check:changed`: запускає розумний check gate для змін у diff відносно `origin/main`. Він запускає typecheck, lint і guard-команди для зачеплених архітектурних lanes, але не запускає тести Vitest. Використовуйте `pnpm test:changed` або явний `pnpm test <target>` для тестового підтвердження.
-- `pnpm test`: спрямовує явні цілі файлів/директорій через scoped Vitest lanes. Запуски без цілі використовують фіксовані shard-групи й розгортаються до leaf-конфігурацій для локального паралельного виконання; група plugin завжди розгортається до shard-конфігурацій кожного plugin замість одного великого процесу root-проєкту.
-- Запуски test wrapper завершуються коротким підсумком `[test] passed|failed|skipped ... in ...`. Власний рядок тривалості Vitest лишається деталізацією для кожного shard.
-- Спільний стан тестів OpenClaw: використовуйте `src/test-utils/openclaw-test-state.ts` з Vitest, коли тесту потрібні ізольовані `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, config fixture, workspace, директорія agent або auth-profile store. Docker/Bash E2E lanes, що source `scripts/lib/docker-e2e-image.sh`, можуть передати `docker_e2e_test_state_shell_b64 <label> <scenario>` у контейнер і виконати там `eval` декодованого фрагмента; scripts із кількома home можуть передати `docker_e2e_test_state_function_b64` і викликати `openclaw_test_state_create <label> <scenario>` у кожному flow. Низькорівневі виклики можуть використовувати `scripts/lib/openclaw-test-state.mjs shell --label <name> --scenario <name>` для shell-фрагмента в контейнері або `node scripts/lib/openclaw-test-state.mjs -- create --label <name> --scenario <name> --env-file <path> --json` для sourceable host env file. `--` перед `create` не дає новішим runtime Node трактувати `--env-file` як прапорець Node.
-- Повні, plugin і include-pattern shard-запуски оновлюють локальні timing-дані в `.artifacts/vitest-shard-timings.json`; пізніші whole-config запуски використовують ці timings для балансування повільних і швидких shards. Include-pattern CI shards додають назву shard до timing key, що зберігає видимість timings відфільтрованих shard без заміни whole-config timing data. Установіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний timing-артефакт.
-- Вибрані тестові файли `plugin-sdk` і `commands` тепер спрямовуються через окремі light lanes, які залишають лише `test/setup.ts`, а runtime-heavy випадки лишають на їхніх наявних lanes.
-- Source-файли із сусідніми тестами зіставляються з цим сусідом перед fallback до ширших directory globs. Зміни helper під `src/channels/plugins/contracts/test-helpers`, `src/plugin-sdk/test-helpers` і `src/plugins/contracts` використовують локальний граф імпортів, щоб запускати тести, які імпортують ці залежності, замість широкого запуску кожного shard, коли шлях залежності точний.
-- `auto-reply` тепер також розділяється на три окремі конфігурації (`core`, `top-level`, `reply`), щоб reply harness не домінував над легшими top-level status/token/helper тестами.
-- Базова конфігурація Vitest тепер за замовчуванням використовує `pool: "threads"` і `isolate: false`, зі спільним non-isolated runner, увімкненим у конфігураціях репозиторію.
+- `pnpm test:force`: Завершує будь-який залишковий процес gateway, що утримує типовий контрольний порт, потім запускає повний набір Vitest з ізольованим портом gateway, щоб серверні тести не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив порт 18789 зайнятим.
+- `pnpm test:coverage`: Запускає модульний набір із покриттям V8 (через `vitest.unit.config.ts`). Це gate покриття завантажених файлів модульними тестами, а не покриття всіх файлів у всьому репозиторії. Пороги: 70% для рядків/функцій/інструкцій і 55% для гілок. Оскільки `coverage.all` має значення false, gate вимірює файли, завантажені набором модульного покриття, замість того щоб вважати кожен source-файл зі split-lane непокритим.
+- `pnpm test:coverage:changed`: Запускає модульне покриття лише для файлів, змінених відносно `origin/main`.
+- `pnpm test:changed`: дешевий розумний запуск тестів для змін. Він запускає точні цілі з прямих змін тестів, сусідніх файлів `*.test.ts`, явних відповідностей source-файлів і локального графа імпортів. Широкі зміни конфігурації/пакетів пропускаються, якщо вони не зіставляються з точними тестами.
+- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: явний широкий запуск тестів для змін. Використовуйте його, коли зміна test harness/config/package має повернутися до ширшої поведінки Vitest для змінених тестів.
+- `pnpm changed:lanes`: показує архітектурні lane, які спрацьовують через diff відносно `origin/main`.
+- `pnpm check:changed`: запускає розумний check gate для змін відносно `origin/main`. Він запускає typecheck, lint і guard-команди для зачеплених архітектурних lane, але не запускає тести Vitest. Для доказу тестами використовуйте `pnpm test:changed` або явний `pnpm test <target>`.
+- `pnpm test`: спрямовує явні цілі файлів/директорій через scoped Vitest lanes. Запуски без цілей використовують фіксовані shard-групи й розгортаються до leaf-конфігів для локального паралельного виконання; група extension завжди розгортається до per-extension shard-конфігів замість одного великого root-project процесу.
+- Запуски test wrapper завершуються коротким підсумком `[test] passed|failed|skipped ... in ...`. Власний рядок тривалості Vitest залишається деталізацією для кожного shard.
+- Спільний тестовий стан OpenClaw: використовуйте `src/test-utils/openclaw-test-state.ts` з Vitest, коли тесту потрібні ізольовані `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, config fixture, workspace, agent dir або auth-profile store. Для process-level E2E тестів, яким потрібен запущений Gateway, використовуйте `test/helpers/openclaw-test-instance.ts`, щоб стан, конфіг, CLI env, запуск gateway, захоплення логів і cleanup залишалися разом. Docker/Bash E2E lanes, які source `scripts/lib/docker-e2e-image.sh`, можуть передавати `docker_e2e_test_state_shell_b64 <label> <scenario>` у контейнер і виконувати `eval` декодованого фрагмента там; multi-home scripts можуть передавати `docker_e2e_test_state_function_b64` і викликати `openclaw_test_state_create <label> <scenario>` у кожному flow. Нижчорівневі викликачі можуть використовувати `scripts/lib/openclaw-test-state.mjs shell --label <name> --scenario <name>` для shell-фрагмента всередині контейнера або `node scripts/lib/openclaw-test-state.mjs -- create --label <name> --scenario <name> --env-file <path> --json` для sourceable host env file. `--` перед `create` не дає новішим Node runtime трактувати `--env-file` як Node flag.
+- Запуски full, extension і include-pattern shard оновлюють локальні timing-дані в `.artifacts/vitest-shard-timings.json`; пізніші whole-config запуски використовують ці timings, щоб збалансувати повільні та швидкі shards. Include-pattern CI shards додають назву shard до timing key, що зберігає filtered shard timings видимими без заміни whole-config timing data. Установіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний timing artifact.
+- Вибрані test-файли `plugin-sdk` і `commands` тепер спрямовуються через dedicated light lanes, які залишають лише `test/setup.ts`, залишаючи runtime-heavy cases на їхніх наявних lanes.
+- Source-файли із сусідніми тестами зіставляються з цим сусіднім тестом перед fallback до ширших directory globs. Зміни helper у `src/channels/plugins/contracts/test-helpers`, `src/plugin-sdk/test-helpers` і `src/plugins/contracts` використовують локальний граф імпортів, щоб запускати importing tests замість широкого запуску кожного shard, коли dependency path точний.
+- `auto-reply` тепер також розділено на три dedicated configs (`core`, `top-level`, `reply`), щоб reply harness не домінував над легшими top-level status/token/helper тестами.
+- Базовий Vitest config тепер типово використовує `pool: "threads"` і `isolate: false`, зі спільним non-isolated runner, увімкненим у configs репозиторію.
 - `pnpm test:channels` запускає `vitest.channels.config.ts`.
-- `pnpm test:extensions` і `pnpm test extensions` запускають усі extension/plugin shards. Важкі channel plugins, browser plugin і OpenAI запускаються як окремі shards; інші групи plugin лишаються пакетованими. Використовуйте `pnpm test extensions/<id>` для однієї lane bundled plugin.
-- `pnpm test:perf:imports`: вмикає звітування Vitest про import-duration + import-breakdown, водночас і далі використовуючи scoped lane routing для явних цілей файлів/директорій.
-- `pnpm test:perf:imports:changed`: те саме import profiling, але лише для файлів, змінених після `origin/main`.
-- `pnpm test:perf:changed:bench -- --ref <git-ref>` порівнює routed changed-mode path із native root-project run для того самого committed git diff.
-- `pnpm test:perf:changed:bench -- --worktree` порівнює поточний набір змін worktree без попереднього commit.
-- `pnpm test:perf:profile:main`: записує CPU profile для головного потоку Vitest (`.artifacts/vitest-main-profile`).
+- `pnpm test:extensions` і `pnpm test extensions` запускають усі extension/plugin shards. Heavy channel plugins, browser plugin і OpenAI запускаються як dedicated shards; інші plugin groups залишаються batched. Використовуйте `pnpm test extensions/<id>` для одного bundled plugin lane.
+- `pnpm test:perf:imports`: вмикає звітування Vitest import-duration + import-breakdown, водночас і далі використовуючи scoped lane routing для явних цілей файлів/директорій.
+- `pnpm test:perf:imports:changed`: те саме import profiling, але лише для файлів, змінених відносно `origin/main`.
+- `pnpm test:perf:changed:bench -- --ref <git-ref>` вимірює routed changed-mode path проти native root-project run для того самого committed git diff.
+- `pnpm test:perf:changed:bench -- --worktree` вимірює поточний worktree change set без попереднього commit.
+- `pnpm test:perf:profile:main`: записує CPU profile для main thread Vitest (`.artifacts/vitest-main-profile`).
 - `pnpm test:perf:profile:runner`: записує CPU + heap profiles для unit runner (`.artifacts/vitest-runner-profile`).
-- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: послідовно запускає кожну full-suite Vitest leaf config і записує згруповані duration data плюс JSON/log артефакти для кожної config. Test Performance Agent використовує це як baseline перед спробами виправити повільні тести.
-- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: порівнює згруповані звіти після зміни, сфокусованої на продуктивності.
-- Інтеграція Gateway: увімкнення за згодою через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
-- `pnpm test:e2e`: Запускає end-to-end smoke-тести Gateway (multi-instance WS/HTTP/node pairing). За замовчуванням використовує `threads` + `isolate: false` з адаптивними workers у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=<n>` і встановіть `OPENCLAW_E2E_VERBOSE=1` для докладних logs.
-- `pnpm test:live`: Запускає provider live tests (minimax/zai). Потребує API keys і `LIVE=1` (або provider-specific `*_LIVE_TEST=1`), щоб зняти пропуск.
-- `pnpm test:docker:all`: Збирає спільний live-test image, один раз пакує OpenClaw як npm tarball, збирає/повторно використовує bare Node/Git runner image плюс functional image, який встановлює цей tarball у `/app`, а потім запускає Docker smoke lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1` через weighted scheduler. Bare image (`OPENCLAW_DOCKER_E2E_BARE_IMAGE`) використовується для installer/update/plugin-dependency lanes; ці lanes монтують попередньо зібраний tarball замість використання скопійованих repo sources. Functional image (`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`) використовується для звичайних built-app functionality lanes. `scripts/package-openclaw-for-docker.mjs` є єдиним local/CI package packer і перевіряє tarball плюс `dist/postinstall-inventory.json` перед тим, як Docker його споживає. Визначення Docker lanes живуть у `scripts/lib/docker-e2e-scenarios.mjs`; planner logic живе в `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` виконує вибраний plan. `node scripts/test-docker-all.mjs --plan-json` виводить scheduler-owned CI plan для вибраних lanes, image kinds, package/live-image needs, state scenarios і credential checks без збирання чи запуску Docker. `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` керує process slots і за замовчуванням дорівнює 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>` керує provider-sensitive tail pool і за замовчуванням дорівнює 10. Heavy lane caps за замовчуванням: `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; provider caps за замовчуванням обмежують до однієї heavy lane на provider через `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` і `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`. Використовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` для більших hosts. Якщо одна lane перевищує effective weight або resource cap на low-parallelism host, вона все одно може стартувати з empty pool і працюватиме сама, доки не звільнить capacity. Запуски lanes за замовчуванням рознесені на 2 секунди, щоб уникнути локальних Docker daemon create storms; перевизначте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. Runner за замовчуванням preflight-перевіряє Docker, очищає застарілі OpenClaw E2E containers, виводить active-lane status кожні 30 секунд, ділить provider CLI tool caches між сумісними lanes, повторює transient live-provider failures один раз за замовчуванням (`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=<n>`) і зберігає lane timings у `.artifacts/docker-tests/lane-timings.json` для longest-first ordering у пізніших запусках. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб надрукувати lane manifest без запуску Docker, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>`, щоб налаштувати status output, або `OPENCLAW_DOCKER_ALL_TIMINGS=0`, щоб вимкнути timing reuse. Використовуйте `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` лише для deterministic/local lanes або `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` лише для live-provider lanes; package aliases: `pnpm test:docker:local:all` і `pnpm test:docker:live:all`. Live-only mode об’єднує main і tail live lanes в один longest-first pool, щоб provider buckets могли пакувати роботу Claude, Codex і Gemini разом. Runner припиняє планувати нові pooled lanes після першої помилки, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, і кожна lane має fallback timeout 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; вибрані live/tail lanes використовують жорсткіші per-lane caps. CLI backend Docker setup commands мають власний timeout через `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS` (за замовчуванням 180). Per-lane logs, `summary.json`, `failures.json` і phase timings записуються під `.artifacts/docker-tests/<run-id>/`; використовуйте `pnpm test:docker:timings <summary.json>`, щоб перевірити повільні lanes, і `pnpm test:docker:rerun <run-id|summary.json|failures.json>`, щоб надрукувати дешеві targeted rerun commands.
+- `pnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.json`: запускає кожен full-suite Vitest leaf config послідовно й записує grouped duration data плюс per-config JSON/log artifacts. Test Performance Agent використовує це як baseline перед спробою виправити повільні тести.
+- `pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.json`: порівнює grouped reports після performance-focused change.
+- Інтеграція Gateway: opt-in через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`.
+- `pnpm test:e2e`: Запускає gateway end-to-end smoke tests (multi-instance WS/HTTP/node pairing). Типово використовує `threads` + `isolate: false` з adaptive workers у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=<n>` і встановіть `OPENCLAW_E2E_VERBOSE=1` для докладних логів.
+- `pnpm test:live`: Запускає provider live tests (minimax/zai). Потребує API keys і `LIVE=1` (або provider-specific `*_LIVE_TEST=1`), щоб зняти skip.
+- `pnpm test:docker:all`: Збирає спільний live-test image, пакує OpenClaw один раз як npm tarball, збирає/перевикористовує bare Node/Git runner image плюс functional image, який інсталює цей tarball у `/app`, потім запускає Docker smoke lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1` через weighted scheduler. Bare image (`OPENCLAW_DOCKER_E2E_BARE_IMAGE`) використовується для installer/update/plugin-dependency lanes; ці lanes монтують prebuilt tarball замість використання скопійованих repo sources. Functional image (`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`) використовується для normal built-app functionality lanes. `scripts/package-openclaw-for-docker.mjs` є єдиним local/CI package packer і перевіряє tarball плюс `dist/postinstall-inventory.json`, перш ніж Docker його споживає. Визначення Docker lane містяться в `scripts/lib/docker-e2e-scenarios.mjs`; planner logic міститься в `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` виконує вибраний plan. `node scripts/test-docker-all.mjs --plan-json` виводить scheduler-owned CI plan для вибраних lanes, image kinds, package/live-image needs, state scenarios і credential checks без build або запуску Docker. `OPENCLAW_DOCKER_ALL_PARALLELISM=<n>` керує process slots і типово дорівнює 10; `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM=<n>` керує provider-sensitive tail pool і типово дорівнює 10. Heavy lane caps типово дорівнюють `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; provider caps типово дорівнюють одному heavy lane на provider через `OPENCLAW_DOCKER_ALL_LIVE_CLAUDE_LIMIT=4`, `OPENCLAW_DOCKER_ALL_LIVE_CODEX_LIMIT=4` і `OPENCLAW_DOCKER_ALL_LIVE_GEMINI_LIMIT=4`. Використовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` для більших hosts. Якщо один lane перевищує effective weight або resource cap на low-parallelism host, він все одно може стартувати з empty pool і працюватиме сам, доки не звільнить capacity. Старти lane типово рознесені на 2 секунди, щоб уникнути локальних Docker daemon create storms; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=<ms>`. Runner типово виконує preflight Docker, очищає stale OpenClaw E2E containers, виводить active-lane status кожні 30 секунд, ділить provider CLI tool caches між compatible lanes, повторює transient live-provider failures один раз типово (`OPENCLAW_DOCKER_ALL_LIVE_RETRIES=<n>`) і зберігає lane timings у `.artifacts/docker-tests/lane-timings.json` для longest-first ordering у пізніших запусках. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб надрукувати lane manifest без запуску Docker, `OPENCLAW_DOCKER_ALL_STATUS_INTERVAL_MS=<ms>` для налаштування status output або `OPENCLAW_DOCKER_ALL_TIMINGS=0`, щоб вимкнути timing reuse. Використовуйте `OPENCLAW_DOCKER_ALL_LIVE_MODE=skip` лише для deterministic/local lanes або `OPENCLAW_DOCKER_ALL_LIVE_MODE=only` лише для live-provider lanes; package aliases: `pnpm test:docker:local:all` і `pnpm test:docker:live:all`. Live-only mode об’єднує main і tail live lanes в один longest-first pool, щоб provider buckets могли пакувати Claude, Codex і Gemini work разом. Runner припиняє планувати нові pooled lanes після першого failure, якщо не встановлено `OPENCLAW_DOCKER_ALL_FAIL_FAST=0`, і кожен lane має 120-minute fallback timeout, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; вибрані live/tail lanes використовують жорсткіші per-lane caps. CLI backend Docker setup commands мають власний timeout через `OPENCLAW_LIVE_CLI_BACKEND_SETUP_TIMEOUT_SECONDS` (типово 180). Per-lane logs, `summary.json`, `failures.json` і phase timings записуються в `.artifacts/docker-tests/<run-id>/`; використовуйте `pnpm test:docker:timings <summary.json>`, щоб переглянути повільні lanes, і `pnpm test:docker:rerun <run-id|summary.json|failures.json>`, щоб надрукувати дешеві targeted rerun commands.
 - `pnpm test:docker:browser-cdp-snapshot`: Збирає Chromium-backed source E2E container, запускає raw CDP плюс ізольований Gateway, виконує `browser doctor --deep` і перевіряє, що CDP role snapshots містять link URLs, cursor-promoted clickables, iframe refs і frame metadata.
 - CLI backend live Docker probes можна запускати як focused lanes, наприклад `pnpm test:docker:live-cli-backend:codex`, `pnpm test:docker:live-cli-backend:codex:resume` або `pnpm test:docker:live-cli-backend:codex:mcp`. Claude і Gemini мають відповідні aliases `:resume` і `:mcp`.
-- `pnpm test:docker:openwebui`: Запускає Dockerized OpenClaw + Open WebUI, входить через Open WebUI, перевіряє `/api/models`, а потім запускає справжній proxied chat через `/api/chat/completions`. Потребує придатного live model key (наприклад OpenAI у `~/.profile`), завантажує зовнішній Open WebUI image і не очікується таким CI-stable, як звичайні unit/e2e suites.
-- `pnpm test:docker:mcp-channels`: Запускає seeded Gateway container і другий client container, який породжує `openclaw mcp serve`, а потім перевіряє routed conversation discovery, transcript reads, attachment metadata, поведінку live event queue, outbound send routing і Claude-style channel + permission notifications через справжній stdio bridge. Твердження Claude notification читає raw stdio MCP frames напряму, щоб smoke відображав те, що bridge фактично emit.
+- `pnpm test:docker:openwebui`: Запускає Dockerized OpenClaw + Open WebUI, входить через Open WebUI, перевіряє `/api/models`, потім запускає real proxied chat через `/api/chat/completions`. Потребує придатного live model key (наприклад OpenAI у `~/.profile`), pulls external Open WebUI image і не очікується як CI-stable на рівні звичайних unit/e2e suites.
+- `pnpm test:docker:mcp-channels`: Запускає seeded Gateway container і другий client container, який spawns `openclaw mcp serve`, потім перевіряє routed conversation discovery, transcript reads, attachment metadata, live event queue behavior, outbound send routing і Claude-style channel + permission notifications через реальний stdio bridge. Claude notification assertion читає raw stdio MCP frames напряму, щоб smoke відображав те, що bridge фактично emits.
 
 ## Локальний PR gate
 
-Для локальних перевірок PR land/gate запустіть:
+Для локальних PR land/gate checks запустіть:
 
 - `pnpm check:changed`
 - `pnpm check`
@@ -59,7 +59,7 @@ x-i18n:
 - `pnpm test`
 - `pnpm check:docs`
 
-Якщо `pnpm test` flakes на навантаженому host, перезапустіть один раз, перш ніж вважати це regression, а потім ізолюйте через `pnpm test <path/to/test>`. Для hosts з обмеженою пам’яттю використовуйте:
+Якщо `pnpm test` нестабільно падає на завантаженому хості, перезапустіть один раз, перш ніж вважати це регресією, а потім ізолюйте проблему за допомогою `pnpm test <path/to/test>`. Для хостів з обмеженою пам’яттю використовуйте:
 
 - `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test`
 - `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed`
@@ -71,13 +71,13 @@ x-i18n:
 Використання:
 
 - `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10`
-- Необов’язкові env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
-- Стандартний prompt: “Відповідай одним словом: ok. Без пунктуації чи додаткового тексту.”
+- Необов’язкове env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY`
+- Типовий промпт: “Відповідай одним словом: ок. Без розділових знаків або додаткового тексту.”
 
 Останній запуск (2025-12-31, 20 запусків):
 
-- minimax медіана 1279ms (мін. 1114, макс. 2431)
-- opus медіана 2454ms (мін. 1224, макс. 3170)
+- minimax медіана 1279 мс (мін. 1114, макс. 2431)
+- opus медіана 2454 мс (мін. 1224, макс. 3170)
 
 ## Бенчмарк запуску CLI
 
@@ -107,23 +107,23 @@ x-i18n:
 - `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `tasks --json`, `tasks list --json`, `tasks audit --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port`
 - `all`: обидва пресети
 
-Вивід містить `sampleCount`, середнє, p50, p95, мін./макс., розподіл кодів виходу/сигналів і підсумки максимального RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують профілі V8 для кожного запуску, щоб вимірювання часу й захоплення профілю використовували той самий harness.
+Вивід містить `sampleCount`, середнє, p50, p95, мін./макс., розподіл кодів виходу/сигналів і зведення max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують профілі V8 для кожного запуску, щоб вимірювання часу та збирання профілів використовували той самий harness.
 
 Угоди щодо збереженого виводу:
 
 - `pnpm test:startup:bench:smoke` записує цільовий smoke-артефакт у `.artifacts/cli-startup-bench-smoke.json`
-- `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json` з `runs=5` і `warmup=1`
-- `pnpm test:startup:bench:update` оновлює fixture базової лінії, внесений у репозиторій, у `test/fixtures/cli-startup-bench.json` з `runs=5` і `warmup=1`
+- `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json` із `runs=5` і `warmup=1`
+- `pnpm test:startup:bench:update` оновлює зафіксовану в репозиторії baseline-фікстуру в `test/fixtures/cli-startup-bench.json` із `runs=5` і `warmup=1`
 
-Fixture, внесений у репозиторій:
+Зафіксована в репозиторії фікстура:
 
 - `test/fixtures/cli-startup-bench.json`
 - Оновіть за допомогою `pnpm test:startup:bench:update`
-- Порівняйте поточні результати з fixture за допомогою `pnpm test:startup:bench:check`
+- Порівняйте поточні результати з фікстурою за допомогою `pnpm test:startup:bench:check`
 
 ## Onboarding E2E (Docker)
 
-Docker необов’язковий; це потрібно лише для контейнеризованих onboarding smoke-тестів.
+Docker необов’язковий; це потрібно лише для контейнеризованих smoke-тестів onboarding.
 
 Повний cold-start потік у чистому Linux-контейнері:
 
@@ -133,9 +133,9 @@ scripts/e2e/onboard-docker.sh
 
 Цей скрипт керує інтерактивним майстром через pseudo-tty, перевіряє файли конфігурації/робочого простору/сесії, потім запускає Gateway і виконує `openclaw health`.
 
-## Smoke-тест імпорту QR (Docker)
+## QR import smoke (Docker)
 
-Гарантує, що підтримуваний runtime helper QR завантажується в підтримуваних Docker runtime Node (Node 24 за замовчуванням, Node 22 сумісний):
+Гарантує, що підтримуваний QR runtime helper завантажується в підтримуваних Docker Node runtimes (Node 24 за замовчуванням, сумісний Node 22):
 
 ```bash
 pnpm test:docker:qr