chore(i18n): refresh uk translations

2026-04-29 10:43:58 +00:00 · 2026-04-29 10:43:58 +00:00 · f7ed9c9f3d
commit f7ed9c9f3d
parent 0fc3d9e9f0
5 changed files with 1004 additions and 950 deletions
--- a/docs/uk/ci.md
+++ b/docs/uk/ci.md
--- a/docs/uk/gateway/config-agents.md
+++ b/docs/uk/gateway/config-agents.md
@ -1,28 +1,28 @@
 ---
 read_when:
    - Налаштування типових параметрів агента (моделі, мислення, робочий простір, Heartbeat, медіа, Skills)
-    - Налаштування мультиагентної маршрутизації та прив’язок
-    - Налаштування сеансів, доставлення повідомлень і поведінки режиму розмови
-summary: Типові параметри агента, маршрутизація між кількома агентами, сеанс, повідомлення та конфігурація розмови
+    - Налаштування багатоагентної маршрутизації та прив’язок
+    - Налаштування сеансу, доставлення повідомлень і поведінки режиму розмови
+summary: Типові налаштування агента, багатоагентна маршрутизація, конфігурація сеансу, повідомлень і talk
 title: Конфігурація — агенти
 x-i18n:
-    generated_at: "2026-04-29T09:13:06Z"
+    generated_at: "2026-04-29T10:40:34Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 0b093332d62836f3564f248e67e68b058777d84f78e8f1e99ab258f44839c400
+    source_hash: 76d15861fc92ede737d7d37aeb340eeca42e834b9b2d94f81592825247fd453c
    source_path: gateway/config-agents.md
    workflow: 16
 ---

-Ключі конфігурації на рівні агента в `agents.*`, `multiAgent.*`, `session.*`,
+Ключі конфігурації з областю дії агента в `agents.*`, `multiAgent.*`, `session.*`,
 `messages.*` і `talk.*`. Для каналів, інструментів, середовища виконання Gateway та інших
-ключів верхнього рівня див. [довідник із конфігурації](/uk/gateway/configuration-reference).
+ключів верхнього рівня див. [Довідник конфігурації](/uk/gateway/configuration-reference).

-## Типові значення агента
+## Типові налаштування агентів

 ### `agents.defaults.workspace`

-Типове значення: `~/.openclaw/workspace`.
+Типово: `~/.openclaw/workspace`.

 ```json5
 {
@ -32,7 +32,7 @@ x-i18n:

 ### `agents.defaults.repoRoot`

-Необов’язковий корінь репозиторію, який показується в рядку Runtime системного промпта. Якщо не задано, OpenClaw автоматично визначає його, рухаючись вгору від робочої області.
+Необов’язковий корінь репозиторію, який показується в рядку Runtime системного промпта. Якщо не задано, OpenClaw автоматично визначає його, рухаючись угору від робочої області.

 ```json5
 {
@ -58,15 +58,15 @@ x-i18n:
 }
 ```

- Не вказуйте `agents.defaults.skills`, щоб Skills за замовчуванням були необмежені.
+- Не вказуйте `agents.defaults.skills`, щоб Skills типово були необмеженими.
 - Не вказуйте `agents.list[].skills`, щоб успадкувати типові значення.
- Задайте `agents.list[].skills: []`, щоб Skills не було.
+- Задайте `agents.list[].skills: []`, щоб не було Skills.
 - Непорожній список `agents.list[].skills` є остаточним набором для цього агента; він
  не об’єднується з типовими значеннями.

 ### `agents.defaults.skipBootstrap`

-Вимикає автоматичне створення bootstrap-файлів робочої області (`AGENTS.md`, `SOUL.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md`, `BOOTSTRAP.md`).
+Вимикає автоматичне створення файлів початкового налаштування робочої області (`AGENTS.md`, `SOUL.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`, `HEARTBEAT.md`, `BOOTSTRAP.md`).

 ```json5
 {
@ -76,10 +76,10 @@ x-i18n:

 ### `agents.defaults.contextInjection`

-Керує тим, коли bootstrap-файли робочої області вставляються в системний промпт. Типове значення: `"always"`.
+Керує тим, коли файли початкового налаштування робочої області додаються в системний промпт. Типово: `"always"`.

- `"continuation-skip"`: безпечні ходи продовження (після завершеної відповіді асистента) пропускають повторне вставлення bootstrap робочої області, зменшуючи розмір промпта. Запуски Heartbeat і повторні спроби після Compaction усе одно перебудовують контекст.
- `"never"`: вимикає bootstrap робочої області та вставлення контекстних файлів на кожному ході. Використовуйте це лише для агентів, які повністю керують власним життєвим циклом промпта (власні рушії контексту, нативні середовища виконання, що будують власний контекст, або спеціалізовані робочі процеси без bootstrap). Ходи Heartbeat і відновлення після Compaction також пропускають вставлення.
+- `"continuation-skip"`: безпечні ходи продовження (після завершеної відповіді асистента) пропускають повторне додавання початкового налаштування робочої області, зменшуючи розмір промпта. Запуски Heartbeat і повторні спроби після Compaction усе одно перебудовують контекст.
+- `"never"`: вимикає початкове налаштування робочої області та додавання контекстних файлів на кожному ході. Використовуйте це лише для агентів, які повністю керують власним життєвим циклом промпта (власні рушії контексту, нативні середовища виконання, що будують власний контекст, або спеціалізовані робочі процеси без початкового налаштування). Ходи Heartbeat і відновлення після Compaction також пропускають додавання.

 ```json5
 {
@ -89,7 +89,7 @@ x-i18n:

 ### `agents.defaults.bootstrapMaxChars`

-Максимальна кількість символів на один bootstrap-файл робочої області до обрізання. Типове значення: `12000`.
+Максимальна кількість символів на файл початкового налаштування робочої області перед обрізанням. Типово: `12000`.

 ```json5
 {
@ -99,7 +99,7 @@ x-i18n:

 ### `agents.defaults.bootstrapTotalMaxChars`

-Максимальна загальна кількість символів, що вставляються з усіх bootstrap-файлів робочої області. Типове значення: `60000`.
+Максимальна загальна кількість символів, доданих з усіх файлів початкового налаштування робочої області. Типово: `60000`.

 ```json5
 {
@ -109,12 +109,12 @@ x-i18n:

 ### `agents.defaults.bootstrapPromptTruncationWarning`

-Керує текстом попередження, видимим агенту, коли bootstrap-контекст обрізано.
-Типове значення: `"once"`.
+Керує текстом попередження, видимим агенту, коли контекст початкового налаштування обрізано.
+Типово: `"once"`.

- `"off"`: ніколи не вставляти текст попередження в системний промпт.
- `"once"`: вставляти попередження один раз для кожного унікального підпису обрізання (рекомендовано).
- `"always"`: вставляти попередження під час кожного запуску, коли є обрізання.
+- `"off"`: ніколи не додавати текст попередження в системний промпт.
+- `"once"`: додавати попередження один раз для кожного унікального підпису обрізання (рекомендовано).
+- `"always"`: додавати попередження під час кожного запуску, коли є обрізання.

 ```json5
 {
@ -122,25 +122,25 @@ x-i18n:
 }
 ```

-### Карта відповідальності за бюджет контексту
+### Мапа володіння бюджетами контексту

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

 - `agents.defaults.bootstrapMaxChars` /
  `agents.defaults.bootstrapTotalMaxChars`:
-  звичайне вставлення bootstrap робочої області.
+  звичайне додавання початкового налаштування робочої області.
 - `agents.defaults.startupContext.*`:
-  одноразова прелюдія запуску моделі під час скидання/старту, зокрема нещодавні щоденні
-  файли `memory/*.md`. Команди звичайного чату `/new` і `/reset`
+  одноразова преамбула запуску моделі під час скидання/запуску, зокрема нещодавні щоденні
+  файли `memory/*.md`. Прості команди чату `/new` і `/reset`
  підтверджуються без виклику моделі.
 - `skills.limits.*`:
-  компактний список Skills, вставлений у системний промпт.
+  компактний список Skills, доданий у системний промпт.
 - `agents.defaults.contextLimits.*`:
-  обмежені фрагменти середовища виконання та вставлені блоки, якими володіє середовище виконання.
+  обмежені фрагменти середовища виконання та додані блоки, якими володіє середовище виконання.
 - `memory.qmd.limits.*`:
-  розмір фрагмента індексованого пошуку пам’яті та вставлення.
+  розмір фрагмента індексованого пошуку в пам’яті та додавання.

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

 #### `agents.defaults.startupContext`

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

 ```json5
 {
@ -190,18 +190,18 @@ OpenClaw має кілька великих бюджетів промпта/ко
 }
 ```

- `memoryGetMaxChars`: типове обмеження фрагмента `memory_get` до додавання
+- `memoryGetMaxChars`: типове обмеження фрагмента `memory_get` перед додаванням
  метаданих обрізання та повідомлення про продовження.
 - `memoryGetDefaultLines`: типове вікно рядків `memory_get`, коли `lines`
-  опущено.
- `toolResultMaxChars`: обмеження результатів живих інструментів, що використовується для збережених результатів і
+  не вказано.
+- `toolResultMaxChars`: обмеження результатів інструментів у реальному часі, що використовується для збережених результатів і
  відновлення після переповнення.
- `postCompactionMaxChars`: обмеження фрагмента AGENTS.md, що використовується під час вставлення
+- `postCompactionMaxChars`: обмеження фрагмента AGENTS.md, що використовується під час додавання
  оновлення після Compaction.

 #### `agents.list[].contextLimits`

-Перевизначення для окремого агента для спільних параметрів `contextLimits`. Опущені поля успадковуються
+Перевизначення для окремого агента для спільних параметрів `contextLimits`. Пропущені поля успадковуються
 з `agents.defaults.contextLimits`.

 ```json5
@ -228,8 +228,8 @@ OpenClaw має кілька великих бюджетів промпта/ко

 #### `skills.limits.maxSkillsPromptChars`

-Глобальне обмеження для компактного списку Skills, вставленого в системний промпт. Це
-не впливає на читання файлів `SKILL.md` за запитом.
+Глобальне обмеження для компактного списку Skills, доданого в системний промпт. Це
+не впливає на читання файлів `SKILL.md` на вимогу.

 ```json5
 {
@ -262,10 +262,10 @@ OpenClaw має кілька великих бюджетів промпта/ко

 ### `agents.defaults.imageMaxDimensionPx`

-Максимальний розмір у пікселях для найдовшої сторони зображення в блоках зображень transcript/інструментів перед викликами провайдера.
-Типове значення: `1200`.
+Максимальний розмір у пікселях для найдовшої сторони зображення в блоках зображень стенограми/інструментів перед викликами провайдера.
+Типово: `1200`.

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

 ```json5
@ -276,7 +276,7 @@ OpenClaw має кілька великих бюджетів промпта/ко

 ### `agents.defaults.userTimezone`

-Часовий пояс для контексту системного промпта (не для часових позначок повідомлень). Якщо не задано, використовується часовий пояс хоста.
+Часовий пояс для контексту системного промпта (не для часових позначок повідомлень). Резервно використовується часовий пояс хоста.

 ```json5
 {
@ -286,7 +286,7 @@ OpenClaw має кілька великих бюджетів промпта/ко

 ### `agents.defaults.timeFormat`

-Формат часу в системному промпті. Типове значення: `auto` (налаштування ОС).
+Формат часу в системному промпті. Типово: `auto` (налаштування ОС).

 ```json5
 {
@ -343,57 +343,58 @@ OpenClaw має кілька великих бюджетів промпта/ко
 }
 ```

- `model`: приймає або рядок (`"provider/model"`), або об'єкт (`{ primary, fallbacks }`).
+- `model`: приймає або рядок (`"provider/model"`), або об’єкт (`{ primary, fallbacks }`).
  - Рядкова форма задає лише основну модель.
-  - Об'єктна форма задає основну модель і впорядковані моделі резервного перемикання.
- `imageModel`: приймає або рядок (`"provider/model"`), або об'єкт (`{ primary, fallbacks }`).
-  - Використовується шляхом інструмента `image` як його конфігурація візійної моделі.
-  - Також використовується як резервна маршрутизація, коли вибрана/стандартна модель не може приймати вхідні зображення.
+  - Об’єктна форма задає основну модель і впорядковані моделі для аварійного перемикання.
+- `imageModel`: приймає або рядок (`"provider/model"`), або об’єкт (`{ primary, fallbacks }`).
+  - Використовується шляхом інструмента `image` як його конфігурація моделі зору.
+  - Також використовується як резервна маршрутизація, коли вибрана/типова модель не може приймати вхідні зображення.
  - Надавайте перевагу явним посиланням `provider/model`. Голі ідентифікатори приймаються для сумісності; якщо голий ідентифікатор однозначно відповідає налаштованому запису з підтримкою зображень у `models.providers.*.models`, OpenClaw уточнює його до цього провайдера. Неоднозначні налаштовані збіги потребують явного префікса провайдера.
- `imageGenerationModel`: приймає або рядок (`"provider/model"`), або об'єкт (`{ primary, fallbacks }`).
-  - Використовується спільною можливістю генерації зображень і будь-якою майбутньою поверхнею інструмента/плагіна, що генерує зображення.
+- `imageGenerationModel`: приймає або рядок (`"provider/model"`), або об’єкт (`{ primary, fallbacks }`).
+  - Використовується спільною можливістю генерації зображень і будь-якою майбутньою поверхнею інструмента/Plugin, що генерує зображення.
  - Типові значення: `google/gemini-3.1-flash-image-preview` для нативної генерації зображень Gemini, `fal/fal-ai/flux/dev` для fal, `openai/gpt-image-2` для OpenAI Images або `openai/gpt-image-1.5` для виводу OpenAI PNG/WebP із прозорим тлом.
  - Якщо ви вибираєте провайдера/модель напряму, також налаштуйте відповідну автентифікацію провайдера (наприклад, `GEMINI_API_KEY` або `GOOGLE_API_KEY` для `google/*`, `OPENAI_API_KEY` або OpenAI Codex OAuth для `openai/gpt-image-2` / `openai/gpt-image-1.5`, `FAL_KEY` для `fal/*`).
-  - Якщо пропущено, `image_generate` все одно може вивести стандартного провайдера з наявною автентифікацією. Спершу він пробує поточного стандартного провайдера, потім решту зареєстрованих провайдерів генерації зображень у порядку ідентифікаторів провайдера.
- `musicGenerationModel`: приймає або рядок (`"provider/model"`), або об'єкт (`{ primary, fallbacks }`).
+  - Якщо пропущено, `image_generate` все одно може вивести типовий провайдер, підкріплений автентифікацією. Спочатку він пробує поточного типового провайдера, потім решту зареєстрованих провайдерів генерації зображень у порядку ідентифікаторів провайдерів.
+- `musicGenerationModel`: приймає або рядок (`"provider/model"`), або об’єкт (`{ primary, fallbacks }`).
  - Використовується спільною можливістю генерації музики та вбудованим інструментом `music_generate`.
  - Типові значення: `google/lyria-3-clip-preview`, `google/lyria-3-pro-preview` або `minimax/music-2.6`.
-  - Якщо пропущено, `music_generate` все одно може вивести стандартного провайдера з наявною автентифікацією. Спершу він пробує поточного стандартного провайдера, потім решту зареєстрованих провайдерів генерації музики у порядку ідентифікаторів провайдера.
+  - Якщо пропущено, `music_generate` все одно може вивести типовий провайдер, підкріплений автентифікацією. Спочатку він пробує поточного типового провайдера, потім решту зареєстрованих провайдерів генерації музики в порядку ідентифікаторів провайдерів.
  - Якщо ви вибираєте провайдера/модель напряму, також налаштуйте відповідну автентифікацію/API-ключ провайдера.
- `videoGenerationModel`: приймає або рядок (`"provider/model"`), або об'єкт (`{ primary, fallbacks }`).
+- `videoGenerationModel`: приймає або рядок (`"provider/model"`), або об’єкт (`{ primary, fallbacks }`).
  - Використовується спільною можливістю генерації відео та вбудованим інструментом `video_generate`.
  - Типові значення: `qwen/wan2.6-t2v`, `qwen/wan2.6-i2v`, `qwen/wan2.6-r2v`, `qwen/wan2.6-r2v-flash` або `qwen/wan2.7-r2v`.
-  - Якщо пропущено, `video_generate` все одно може вивести стандартного провайдера з наявною автентифікацією. Спершу він пробує поточного стандартного провайдера, потім решту зареєстрованих провайдерів генерації відео у порядку ідентифікаторів провайдера.
+  - Якщо пропущено, `video_generate` все одно може вивести типовий провайдер, підкріплений автентифікацією. Спочатку він пробує поточного типового провайдера, потім решту зареєстрованих провайдерів генерації відео в порядку ідентифікаторів провайдерів.
  - Якщо ви вибираєте провайдера/модель напряму, також налаштуйте відповідну автентифікацію/API-ключ провайдера.
  - Вбудований провайдер генерації відео Qwen підтримує до 1 вихідного відео, 1 вхідного зображення, 4 вхідних відео, тривалість 10 секунд, а також параметри рівня провайдера `size`, `aspectRatio`, `resolution`, `audio` і `watermark`.
- `pdfModel`: приймає або рядок (`"provider/model"`), або об'єкт (`{ primary, fallbacks }`).
+- `pdfModel`: приймає або рядок (`"provider/model"`), або об’єкт (`{ primary, fallbacks }`).
  - Використовується інструментом `pdf` для маршрутизації моделі.
-  - Якщо пропущено, інструмент PDF відкочується до `imageModel`, потім до розв'язаної моделі сеансу/стандартної моделі.
- `pdfMaxBytesMb`: стандартний ліміт розміру PDF для інструмента `pdf`, коли `maxBytesMb` не передано під час виклику.
- `pdfMaxPages`: стандартна максимальна кількість сторінок, яку враховує резервний режим витягування в інструменті `pdf`.
- `verboseDefault`: стандартний рівень докладності для агентів. Значення: `"off"`, `"on"`, `"full"`. Стандартно: `"off"`.
- `elevatedDefault`: стандартний рівень підвищеного виводу для агентів. Значення: `"off"`, `"on"`, `"ask"`, `"full"`. Стандартно: `"on"`.
- `model.primary`: формат `provider/model` (наприклад, `openai/gpt-5.5` для доступу через API-ключ або `openai-codex/gpt-5.5` для Codex OAuth). Якщо ви пропускаєте провайдера, OpenClaw спершу пробує псевдонім, потім унікальний збіг налаштованого провайдера для цього точного ідентифікатора моделі, і лише після цього відкочується до налаштованого стандартного провайдера (застаріла поведінка сумісності, тому надавайте перевагу явному `provider/model`). Якщо цей провайдер більше не надає налаштовану стандартну модель, OpenClaw відкочується до першого налаштованого провайдера/моделі замість показу застарілого стандартного значення видаленого провайдера.
+  - Якщо пропущено, інструмент PDF спочатку відступає до `imageModel`, а потім до розв’язаної моделі сесії/типової моделі.
+- `pdfMaxBytesMb`: типовий ліміт розміру PDF для інструмента `pdf`, коли `maxBytesMb` не передано під час виклику.
+- `pdfMaxPages`: типова максимальна кількість сторінок, яку враховує резервний режим витягання в інструменті `pdf`.
+- `verboseDefault`: типовий рівень докладності для агентів. Значення: `"off"`, `"on"`, `"full"`. Типово: `"off"`.
+- `elevatedDefault`: типовий рівень розширеного виводу для агентів. Значення: `"off"`, `"on"`, `"ask"`, `"full"`. Типово: `"on"`.
+- `model.primary`: формат `provider/model` (наприклад, `openai/gpt-5.5` для доступу через API-ключ або `openai-codex/gpt-5.5` для Codex OAuth). Якщо ви пропускаєте провайдера, OpenClaw спочатку пробує псевдонім, потім унікальний збіг налаштованого провайдера для цього точного ідентифікатора моделі, і лише після цього відступає до налаштованого типового провайдера (застаріла поведінка сумісності, тому надавайте перевагу явному `provider/model`). Якщо цей провайдер більше не надає налаштовану типову модель, OpenClaw відступає до першого налаштованого провайдера/моделі замість того, щоб показувати застарілу типову модель вилученого провайдера.
 - `models`: налаштований каталог моделей і список дозволених моделей для `/model`. Кожен запис може містити `alias` (скорочення) і `params` (специфічні для провайдера, наприклад `temperature`, `maxTokens`, `cacheRetention`, `context1m`, `responsesServerCompaction`, `responsesCompactThreshold`, `chat_template_kwargs`, `extra_body`/`extraBody`).
-  - Безпечні редагування: використовуйте `openclaw config set agents.defaults.models '<json>' --strict-json --merge`, щоб додати записи. `config set` відхиляє заміни, які видалили б наявні записи зі списку дозволених, якщо ви не передасте `--replace`.
-  - Потоки налаштування/онбордингу в межах провайдера зливають вибрані моделі провайдера в цю мапу та зберігають уже налаштованих непов'язаних провайдерів.
-  - Для прямих моделей OpenAI Responses серверна Compaction вмикається автоматично. Використовуйте `params.responsesServerCompaction: false`, щоб припинити ін'єкцію `context_management`, або `params.responsesCompactThreshold`, щоб перевизначити поріг. Див. [серверну Compaction OpenAI](/uk/providers/openai#server-side-compaction-responses-api).
- `params`: глобальні стандартні параметри провайдера, застосовані до всіх моделей. Задаються в `agents.defaults.params` (наприклад, `{ cacheRetention: "long" }`).
- Пріоритет злиття `params` (конфігурація): `agents.defaults.params` (глобальна база) перевизначається `agents.defaults.models["provider/model"].params` (для окремої моделі), потім `agents.list[].params` (відповідний ідентифікатор агента) перевизначає за ключем. Див. [кешування промптів](/uk/reference/prompt-caching) для подробиць.
- `params.extra_body`/`params.extraBody`: розширений наскрізний JSON, що зливається в тіла запитів `api: "openai-completions"` для OpenAI-сумісних проксі. Якщо він конфліктує зі згенерованими ключами запиту, додаткове тіло має перевагу; ненативні маршрути completions все одно після цього прибирають OpenAI-специфічний `store`.
- `params.chat_template_kwargs`: OpenAI-сумісні аргументи шаблону чату vLLM, що зливаються в тіла запитів верхнього рівня `api: "openai-completions"`. Для `vllm/nemotron-3-*` з вимкненим мисленням вбудований Plugin vLLM автоматично надсилає `enable_thinking: false` і `force_nonempty_content: true`; явні `chat_template_kwargs` перевизначають згенеровані стандартні значення, а `extra_body.chat_template_kwargs` все одно має остаточний пріоритет. Для керування мисленням Qwen vLLM задайте `params.qwenThinkingFormat` як `"chat-template"` або `"top-level"` у цьому записі моделі.
- `params.preserveThinking`: увімкнення лише для Z.AI для збереженого мислення. Коли ввімкнено й мислення активне, OpenClaw надсилає `thinking.clear_thinking: false` і повторно відтворює попередній `reasoning_content`; див. [мислення Z.AI і збережене мислення](/uk/providers/zai#thinking-and-preserved-thinking).
- `agentRuntime`: стандартна низькорівнева політика середовища виконання агента. Пропущений ідентифікатор за замовчуванням означає OpenClaw Pi. Використовуйте `id: "pi"`, щоб примусово ввімкнути вбудоване середовище PI, `id: "auto"`, щоб дозволити зареєстрованим середовищам плагінів заявляти підтримувані моделі, зареєстрований ідентифікатор середовища, як-от `id: "codex"`, або підтримуваний псевдонім бекенду CLI, як-от `id: "claude-cli"`. Задайте `fallback: "none"`, щоб вимкнути автоматичний відкат до PI. Явні середовища виконання Plugin, як-от `codex`, за замовчуванням завершуються закрито, якщо ви не задасте `fallback: "pi"` в тій самій області перевизначення. Зберігайте посилання на моделі канонічними як `provider/model`; вибирайте Codex, Claude CLI, Gemini CLI та інші бекенди виконання через конфігурацію середовища виконання замість застарілих префіксів провайдера середовища. Див. [середовища виконання агентів](/uk/concepts/agent-runtimes), щоб дізнатися, чим це відрізняється від вибору провайдера/моделі.
- Автори конфігурації, які змінюють ці поля (наприклад, `/models set`, `/models set-image` і команди додавання/видалення резервних варіантів), зберігають канонічну об'єктну форму та за можливості зберігають наявні списки резервних варіантів.
- `maxConcurrent`: максимальна кількість паралельних запусків агентів між сеансами (кожен сеанс усе одно серіалізований). Стандартно: 4.
+  - Безпечні редагування: використовуйте `openclaw config set agents.defaults.models '<json>' --strict-json --merge`, щоб додати записи. `config set` відхиляє заміни, які видалили б наявні записи списку дозволених, якщо ви не передасте `--replace`.
+  - Потоки налаштування/початкового налаштування з областю дії провайдера об’єднують вибрані моделі провайдера в цю мапу та зберігають уже налаштованих непов’язаних провайдерів.
+  - Для прямих моделей OpenAI Responses серверна Compaction вмикається автоматично. Використовуйте `params.responsesServerCompaction: false`, щоб припинити вставлення `context_management`, або `params.responsesCompactThreshold`, щоб перевизначити поріг. Див. [серверна Compaction OpenAI](/uk/providers/openai#server-side-compaction-responses-api).
+- `params`: глобальні типові параметри провайдера, застосовані до всіх моделей. Задаються в `agents.defaults.params` (наприклад, `{ cacheRetention: "long" }`).
+- Пріоритет об’єднання `params` (конфігурація): `agents.defaults.params` (глобальна база) перевизначається `agents.defaults.models["provider/model"].params` (для окремої моделі), потім `agents.list[].params` (для відповідного ідентифікатора агента) перевизначає за ключем. Докладніше див. [кешування підказок](/uk/reference/prompt-caching).
+- `params.extra_body`/`params.extraBody`: розширений наскрізний JSON, що об’єднується в тіла запитів `api: "openai-completions"` для проксі, сумісних з OpenAI. Якщо він конфліктує зі згенерованими ключами запиту, перемагає додаткове тіло; ненативні маршрути completions після цього все одно вилучають властивий лише OpenAI `store`.
+- `params.chat_template_kwargs`: аргументи шаблону чату, сумісні з vLLM/OpenAI, що об’єднуються в тіла запитів верхнього рівня `api: "openai-completions"`. Для `vllm/nemotron-3-*` з вимкненим thinking вбудований Plugin vLLM автоматично надсилає `enable_thinking: false` і `force_nonempty_content: true`; явні `chat_template_kwargs` перевизначають згенеровані типові значення, а `extra_body.chat_template_kwargs` все одно має остаточний пріоритет. Для керування thinking Qwen у vLLM задайте `params.qwenThinkingFormat` як `"chat-template"` або `"top-level"` у цьому записі моделі.
+- `compat.supportedReasoningEfforts`: список зусиль reasoning, сумісних з OpenAI, для окремої моделі. Додайте `"xhigh"` для кастомних кінцевих точок, які справді його приймають; після цього OpenClaw показує `/think xhigh` у меню команд, рядках сесій Gateway, валідації патчів сесій, валідації CLI агента та валідації `llm-task` для цього налаштованого провайдера/моделі. Використовуйте `compat.reasoningEffortMap`, коли бекенд потребує специфічного для провайдера значення для канонічного рівня.
+- `params.preserveThinking`: опція лише для Z.AI для збереженого thinking. Коли ввімкнено і thinking увімкнений, OpenClaw надсилає `thinking.clear_thinking: false` і повторно відтворює попередній `reasoning_content`; див. [thinking Z.AI і збережений thinking](/uk/providers/zai#thinking-and-preserved-thinking).
+- `agentRuntime`: типова низькорівнева політика виконання агента. Пропущений ідентифікатор типово означає OpenClaw Pi. Використовуйте `id: "pi"`, щоб примусово вибрати вбудований стенд PI, `id: "auto"`, щоб дозволити зареєстрованим стендам Plugin заявляти підтримувані моделі, зареєстрований ідентифікатор стенда, як-от `id: "codex"`, або підтримуваний псевдонім CLI-бекенда, як-от `id: "claude-cli"`. Задайте `fallback: "none"`, щоб вимкнути автоматичний резерв PI. Явні середовища виконання Plugin, як-от `codex`, типово закриваються з помилкою, якщо ви не задасте `fallback: "pi"` у тій самій області перевизначення. Зберігайте посилання на моделі канонічними як `provider/model`; вибирайте Codex, Claude CLI, Gemini CLI та інші бекенди виконання через конфігурацію середовища виконання, а не через застарілі префікси провайдера середовища виконання. Див. [середовища виконання агентів](/uk/concepts/agent-runtimes), щоб зрозуміти, чим це відрізняється від вибору провайдера/моделі.
+- Записувачі конфігурації, які змінюють ці поля (наприклад, `/models set`, `/models set-image` і команди додавання/видалення резервних моделей), зберігають канонічну об’єктну форму та за можливості зберігають наявні списки резервних моделей.
+- `maxConcurrent`: максимальна кількість паралельних запусків агентів між сесіями (кожна сесія все одно серіалізована). Типово: 4.

 ### `agents.defaults.agentRuntime`

 `agentRuntime` керує тим, який низькорівневий виконавець запускає ходи агента. Більшість
-розгортань мають залишати стандартне середовище виконання OpenClaw Pi. Використовуйте його, коли довірений
-Plugin надає нативний harness, як-от вбудований harness Codex app-server,
-або коли потрібен підтримуваний CLI-бекенд, наприклад Claude CLI. Для ментальної
-моделі див. [Середовища виконання агентів](/uk/concepts/agent-runtimes).
+розгортань мають залишати типове середовище виконання OpenClaw Pi. Використовуйте його, коли довірений
+Plugin надає нативний стенд, наприклад вбудований стенд сервера застосунку Codex,
+або коли вам потрібен підтримуваний CLI-бекенд, як-от Claude CLI. Для ментальної
+моделі див. [середовища виконання агентів](/uk/concepts/agent-runtimes).

 ```json5
 {
@ -409,18 +410,18 @@ Plugin надає нативний harness, як-от вбудований harne
 }
 ```

- `id`: `"auto"`, `"pi"`, id зареєстрованого Plugin harness або підтримуваний псевдонім CLI-бекенда. Вбудований Codex Plugin реєструє `codex`; вбудований Anthropic Plugin надає CLI-бекенд `claude-cli`.
- `fallback`: `"pi"` або `"none"`. У `id: "auto"` пропущений fallback за замовчуванням має значення `"pi"`, щоб старі конфігурації могли й далі використовувати PI, коли жоден Plugin harness не бере запуск на себе. У явному режимі Plugin runtime, як-от `id: "codex"`, пропущений fallback за замовчуванням має значення `"none"`, щоб відсутній harness спричиняв помилку, а не мовчки використовував PI. Перевизначення runtime не успадковують fallback із ширшої області; задайте `fallback: "pi"` поруч із явним runtime, коли навмисно хочете цей fallback для сумісності. Збої вибраного Plugin harness завжди показуються напряму.
- Перевизначення середовища: `OPENCLAW_AGENT_RUNTIME=<id|auto|pi>` перевизначає `id`; `OPENCLAW_AGENT_HARNESS_FALLBACK=pi|none` перевизначає fallback для цього процесу.
- Для розгортань лише з Codex задайте `model: "openai/gpt-5.5"` і `agentRuntime.id: "codex"`. Також можна явно задати `agentRuntime.fallback: "none"` для читабельності; це значення за замовчуванням для явних Plugin runtimes.
- Для розгортань Claude CLI віддавайте перевагу `model: "anthropic/claude-opus-4-7"` разом із `agentRuntime.id: "claude-cli"`. Застарілі посилання на моделі `claude-cli/claude-opus-4-7` і далі працюють для сумісності, але нова конфігурація має залишати вибір provider/model канонічним і поміщати бекенд виконання в `agentRuntime.id`.
- Старі ключі runtime-policy переписуються в `agentRuntime` за допомогою `openclaw doctor --fix`.
- Вибір harness закріплюється за id сесії після першого вбудованого запуску. Зміни конфігурації/env впливають на нові або скинуті сесії, а не на наявний transcript. Застарілі сесії з історією transcript, але без записаного закріплення, вважаються закріпленими за PI. `/status` повідомляє фактичний runtime, наприклад `Runtime: OpenClaw Pi Default` або `Runtime: OpenAI Codex`.
- Це керує лише виконанням текстових ходів агента. Генерація медіа, vision, PDF, music, video і TTS і далі використовують свої налаштування provider/model.
+- `id`: `"auto"`, `"pi"`, зареєстрований ідентифікатор стенда Plugin або підтримуваний псевдонім CLI-бекенда. Вбудований Plugin Codex реєструє `codex`; вбудований Plugin Anthropic надає CLI-бекенд `claude-cli`.
+- `fallback`: `"pi"` або `"none"`. У `id: "auto"` пропущений резерв типово дорівнює `"pi"`, щоб старі конфігурації могли й далі використовувати PI, коли жоден стенд Plugin не заявляє запуск. У режимі явного середовища виконання Plugin, як-от `id: "codex"`, пропущений резерв типово дорівнює `"none"`, щоб відсутній стенд завершувався помилкою, а не непомітно використовував PI. Перевизначення середовища виконання не успадковують резерв із ширшої області; задавайте `fallback: "pi"` разом із явним середовищем виконання, коли навмисно хочете цей резерв сумісності. Збої вибраного стенда Plugin завжди показуються напряму.
+- Перевизначення середовища: `OPENCLAW_AGENT_RUNTIME=<id|auto|pi>` перевизначає `id`; `OPENCLAW_AGENT_HARNESS_FALLBACK=pi|none` перевизначає резерв для цього процесу.
+- Для розгортань лише з Codex задайте `model: "openai/gpt-5.5"` і `agentRuntime.id: "codex"`. Ви також можете явно задати `agentRuntime.fallback: "none"` для читабельності; це типове значення для явних середовищ виконання Plugin.
+- Для розгортань Claude CLI надавайте перевагу `model: "anthropic/claude-opus-4-7"` плюс `agentRuntime.id: "claude-cli"`. Застарілі посилання на моделі `claude-cli/claude-opus-4-7` все ще працюють для сумісності, але нова конфігурація має зберігати вибір провайдера/моделі канонічним і розміщувати бекенд виконання в `agentRuntime.id`.
+- Старі ключі політики середовища виконання переписуються в `agentRuntime` командою `openclaw doctor --fix`.
+- Вибір стенда закріплюється за ідентифікатором сесії після першого вбудованого запуску. Зміни конфігурації/середовища впливають на нові або скинуті сесії, а не на наявний transcript. Застарілі сесії з історією transcript, але без записаного закріплення, вважаються закріпленими за PI. `/status` повідомляє ефективне середовище виконання, наприклад `Runtime: OpenClaw Pi Default` або `Runtime: OpenAI Codex`.
+- Це керує лише виконанням текстових ходів агента. Генерація медіа, зір, PDF, музика, відео та TTS і далі використовують свої налаштування провайдера/моделі.

 **Вбудовані скорочення псевдонімів** (застосовуються лише коли модель є в `agents.defaults.models`):

-| Псевдонім           | Модель                                     |
+| Псевдонім           | Модель                                      |
 | ------------------- | ------------------------------------------ |
 | `opus`              | `anthropic/claude-opus-4-6`                |
 | `sonnet`            | `anthropic/claude-sonnet-4-6`              |
@ -431,15 +432,15 @@ Plugin надає нативний harness, як-от вбудований harne
 | `gemini-flash`      | `google/gemini-3-flash-preview`            |
 | `gemini-flash-lite` | `google/gemini-3.1-flash-lite-preview`     |

-Налаштовані вами псевдоніми завжди мають перевагу над типовими значеннями.
+Ваші налаштовані псевдоніми завжди мають пріоритет над типовими.

-Моделі Z.AI GLM-4.x автоматично вмикають режим мислення, якщо ви не задасте `--thinking off` або самостійно не визначите `agents.defaults.models["zai/<model>"].params.thinking`.
-Моделі Z.AI типово вмикають `tool_stream` для потокового передавання викликів інструментів. Щоб вимкнути це, задайте `agents.defaults.models["zai/<model>"].params.tool_stream` значення `false`.
-Моделі Anthropic Claude 4.6 типово використовують `adaptive` мислення, коли явний рівень мислення не задано.
+Моделі Z.AI GLM-4.x автоматично вмикають режим мислення, якщо ви не встановите `--thinking off` або самостійно не задасте `agents.defaults.models["zai/<model>"].params.thinking`.
+Моделі Z.AI типово вмикають `tool_stream` для потокового передавання викликів інструментів. Установіть `agents.defaults.models["zai/<model>"].params.tool_stream` на `false`, щоб вимкнути це.
+Моделі Anthropic Claude 4.6 типово використовують `adaptive` thinking, коли явний рівень thinking не задано.

 ### `agents.defaults.cliBackends`

-Необов’язкові бекенди CLI для резервних запусків лише з текстом (без викликів інструментів). Корисно як запасний варіант, коли API-провайдери дають збій.
+Необов’язкові CLI-бекенди для резервних текстових запусків (без викликів інструментів). Корисно як запасний варіант, коли API-провайдери дають збій.

 ```json5
 {
@ -468,13 +469,13 @@ Plugin надає нативний harness, як-от вбудований harne
 }
 ```

- Бекенди CLI передусім текстові; інструменти завжди вимкнені.
- Сесії підтримуються, коли задано `sessionArg`.
+- CLI-бекенди насамперед текстові; інструменти завжди вимкнені.
+- Сеанси підтримуються, коли задано `sessionArg`.
 - Наскрізне передавання зображень підтримується, коли `imageArg` приймає шляхи до файлів.

 ### `agents.defaults.systemPromptOverride`

-Замінює весь системний промпт, зібраний OpenClaw, фіксованим рядком. Задається на рівні типових значень (`agents.defaults.systemPromptOverride`) або для окремого агента (`agents.list[].systemPromptOverride`). Значення для окремого агента мають пріоритет; порожнє значення або значення лише з пробілів ігнорується. Корисно для контрольованих експериментів із промптами.
+Замініть увесь системний промпт, зібраний OpenClaw, фіксованим рядком. Задається на рівні типових параметрів (`agents.defaults.systemPromptOverride`) або для окремого агента (`agents.list[].systemPromptOverride`). Значення для окремого агента мають пріоритет; порожнє значення або значення лише з пробілів ігнорується. Корисно для контрольованих експериментів із промптами.

 ```json5
 {
@ -488,7 +489,7 @@ Plugin надає нативний harness, як-от вбудований harne

 ### `agents.defaults.promptOverlays`

-Незалежні від провайдера накладки промптів, застосовані за сімейством моделей. Ідентифікатори моделей сімейства GPT-5 отримують спільний контракт поведінки в різних провайдерів; `personality` керує лише дружнім шаром стилю взаємодії.
+Незалежні від провайдера накладки промптів, що застосовуються за сімейством моделей. Ідентифікатори моделей сімейства GPT-5 отримують спільний поведінковий контракт у різних провайдерів; `personality` керує лише дружнім шаром стилю взаємодії.

 ```json5
 {
@ -505,8 +506,8 @@ Plugin надає нативний harness, як-от вбудований harne
 ```

 - `"friendly"` (типово) і `"on"` вмикають дружній шар стилю взаємодії.
- `"off"` вимикає лише дружній шар; позначений контракт поведінки GPT-5 залишається ввімкненим.
- Застаріле `plugins.entries.openai.config.personality` досі читається, коли це спільне налаштування не задано.
+- `"off"` вимикає лише дружній шар; позначений поведінковий контракт GPT-5 залишається ввімкненим.
+- Застарілий `plugins.entries.openai.config.personality` усе ще читається, коли цей спільний параметр не задано.

 ### `agents.defaults.heartbeat`

@ -538,16 +539,16 @@ Plugin надає нативний harness, як-от вбудований harne
 }
 ```

- `every`: рядок тривалості (ms/s/m/h). Типово: `30m` (автентифікація API-ключем) або `1h` (автентифікація OAuth). Задайте `0m`, щоб вимкнути.
- `includeSystemPromptSection`: коли false, вилучає розділ Heartbeat із системного промпта та пропускає ін’єкцію `HEARTBEAT.md` у початковий контекст. Типово: `true`.
- `suppressToolErrorWarnings`: коли true, пригнічує попереджувальні payload-и про помилки інструментів під час запусків Heartbeat.
- `timeoutSeconds`: максимальний час у секундах, дозволений для ходу агента Heartbeat, перш ніж його буде перервано. Не задавайте, щоб використовувати `agents.defaults.timeoutSeconds`.
- `directPolicy`: політика доставки напряму/DM. `allow` (типово) дозволяє доставку до прямої цілі. `block` пригнічує доставку до прямої цілі та виводить `reason=dm-blocked`.
- `lightContext`: коли true, запуски Heartbeat використовують полегшений початковий контекст і зберігають лише `HEARTBEAT.md` із файлів початкового завантаження робочої області.
- `isolatedSession`: коли true, кожен Heartbeat запускається в новій сесії без попередньої історії розмови. Такий самий шаблон ізоляції, як у cron `sessionTarget: "isolated"`. Зменшує витрати токенів на один Heartbeat із ~100K до ~2-5K токенів.
- `skipWhenBusy`: коли true, запуски Heartbeat відкладаються за додаткових зайнятих ліній: робота субагента або вкладених команд. Лінії Cron завжди відкладають Heartbeat, навіть без цього прапорця.
+- `every`: рядок тривалості (ms/s/m/h). Типово: `30m` (автентифікація через API-ключ) або `1h` (OAuth-автентифікація). Установіть `0m`, щоб вимкнути.
+- `includeSystemPromptSection`: коли `false`, вилучає розділ Heartbeat із системного промпта й пропускає ін’єкцію `HEARTBEAT.md` у початковий контекст. Типово: `true`.
+- `suppressToolErrorWarnings`: коли `true`, пригнічує payload-и попереджень про помилки інструментів під час запусків Heartbeat.
+- `timeoutSeconds`: максимальний дозволений час у секундах для ходу агента Heartbeat перед перериванням. Не задавайте, щоб використовувати `agents.defaults.timeoutSeconds`.
+- `directPolicy`: політика доставки напряму/DM. `allow` (типово) дозволяє доставку прямій цілі. `block` пригнічує доставку прямій цілі й виводить `reason=dm-blocked`.
+- `lightContext`: коли `true`, запуски Heartbeat використовують легкий початковий контекст і зберігають лише `HEARTBEAT.md` із початкових файлів робочого простору.
+- `isolatedSession`: коли `true`, кожен Heartbeat запускається в новому сеансі без попередньої історії розмови. Такий самий шаблон ізоляції, як у cron `sessionTarget: "isolated"`. Зменшує витрати токенів на Heartbeat із ~100K до ~2-5K токенів.
+- `skipWhenBusy`: коли `true`, запуски Heartbeat відкладаються за наявності додаткових зайнятих ліній: роботи субагента або вкладених команд. Лінії Cron завжди відкладають Heartbeat, навіть без цього прапорця.
 - Для окремого агента: задайте `agents.list[].heartbeat`. Коли будь-який агент визначає `heartbeat`, Heartbeat запускають **лише ці агенти**.
- Heartbeat запускають повні ходи агента — коротші інтервали витрачають більше токенів.
+- Heartbeat виконують повні ходи агента — коротші інтервали витрачають більше токенів.

 ### `agents.defaults.compaction`

@ -582,22 +583,22 @@ Plugin надає нативний harness, як-от вбудований harne
 }
 ```

- `mode`: `default` або `safeguard` (фрагментоване узагальнення для довгих історій). Див. [Compaction](/uk/concepts/compaction).
- `provider`: ідентифікатор зареєстрованого плагіна провайдера Compaction. Коли задано, замість вбудованого LLM-узагальнення викликається `summarize()` провайдера. У разі збою повертається до вбудованого варіанта. Задання провайдера примусово вмикає `mode: "safeguard"`. Див. [Compaction](/uk/concepts/compaction).
- `timeoutSeconds`: максимальна кількість секунд, дозволена для однієї операції Compaction, перш ніж OpenClaw її перерве. Типово: `900`.
- `keepRecentTokens`: бюджет точки відсікання Pi для збереження найновішого хвоста транскрипта дослівно. Ручний `/compact` враховує це, коли задано явно; інакше ручна Compaction є жорсткою контрольною точкою.
- `identifierPolicy`: `strict` (типово), `off` або `custom`. `strict` додає на початок вбудовані вказівки щодо збереження непрозорих ідентифікаторів під час узагальнення Compaction.
- `identifierInstructions`: необов’язковий власний текст для збереження ідентифікаторів, який використовується, коли `identifierPolicy=custom`.
- `qualityGuard`: перевірки з повторною спробою при некоректно сформованому виводі для safeguard-узагальнень. Типово ввімкнено в режимі safeguard; задайте `enabled: false`, щоб пропустити аудит.
- `postCompactionSections`: необов’язкові назви розділів H2/H3 з AGENTS.md для повторної ін’єкції після Compaction. Типово `["Session Startup", "Red Lines"]`; задайте `[]`, щоб вимкнути повторну ін’єкцію. Коли не задано або явно задано цю типову пару, старі заголовки `Every Session`/`Safety` також приймаються як застарілий резервний варіант.
- `model`: необов’язкове перевизначення `provider/model-id` лише для узагальнення Compaction. Використовуйте це, коли основна сесія має залишатися на одній моделі, а узагальнення Compaction мають виконуватися на іншій; коли не задано, Compaction використовує основну модель сесії.
- `maxActiveTranscriptBytes`: необов’язковий поріг у байтах (`number` або рядки на кшталт `"20mb"`), який запускає звичайну локальну Compaction перед запуском, коли активний JSONL перевищує поріг. Потребує `truncateAfterCompaction`, щоб успішна Compaction могла перейти на менший наступний транскрипт. Вимкнено, коли не задано або дорівнює `0`.
- `notifyUser`: коли `true`, надсилає користувачу короткі повідомлення, коли Compaction починається і коли завершується (наприклад, "Compacting context..." і "Compaction complete"). Типово вимкнено, щоб Compaction відбувалася без повідомлень.
- `memoryFlush`: тихий агентний хід перед автоматичною Compaction для збереження довготривалих спогадів. Задайте `model` як точний provider/model, наприклад `ollama/qwen3:8b`, коли цей сервісний хід має залишатися на локальній моделі; перевизначення не успадковує ланцюжок резервних моделей активної сесії. Пропускається, коли робоча область доступна лише для читання.
+- `mode`: `default` або `safeguard` (фрагментоване підсумовування для довгих історій). Див. [Compaction](/uk/concepts/compaction).
+- `provider`: ідентифікатор зареєстрованого provider plugin Compaction. Коли задано, замість вбудованого LLM-підсумовування викликається `summarize()` провайдера. У разі збою повертається до вбудованого варіанта. Задання провайдера примусово встановлює `mode: "safeguard"`. Див. [Compaction](/uk/concepts/compaction).
+- `timeoutSeconds`: максимальна кількість секунд, дозволена для однієї операції Compaction, перш ніж OpenClaw перерве її. Типово: `900`.
+- `keepRecentTokens`: бюджет точки відсікання Pi для збереження найновішого хвоста транскрипта дослівно. Ручний `/compact` враховує це, коли явно задано; інакше ручна Compaction є жорсткою контрольною точкою.
+- `identifierPolicy`: `strict` (типово), `off` або `custom`. `strict` додає на початку вбудовані настанови щодо збереження непрозорих ідентифікаторів під час підсумовування Compaction.
+- `identifierInstructions`: необов’язковий користувацький текст збереження ідентифікаторів, який використовується, коли `identifierPolicy=custom`.
+- `qualityGuard`: перевірки з повторною спробою при некоректно сформованому виводі для підсумків safeguard. Типово ввімкнено в режимі safeguard; задайте `enabled: false`, щоб пропустити аудит.
+- `postCompactionSections`: необов’язкові назви розділів H2/H3 з AGENTS.md для повторної ін’єкції після Compaction. Типово `["Session Startup", "Red Lines"]`; задайте `[]`, щоб вимкнути повторну ін’єкцію. Коли не задано або явно задано цю типову пару, старіші заголовки `Every Session`/`Safety` також приймаються як застарілий fallback.
+- `model`: необов’язкове перевизначення `provider/model-id` лише для підсумовування Compaction. Використовуйте це, коли основний сеанс має зберігати одну модель, а підсумки Compaction мають виконуватися на іншій; коли не задано, Compaction використовує основну модель сеансу.
+- `maxActiveTranscriptBytes`: необов’язковий поріг у байтах (`number` або рядки на кшталт `"20mb"`), який запускає звичайну локальну Compaction перед запуском, коли активний JSONL перевищує поріг. Потребує `truncateAfterCompaction`, щоб успішна Compaction могла повернутися до меншого наступного транскрипта. Вимкнено, коли не задано або дорівнює `0`.
+- `notifyUser`: коли `true`, надсилає користувачу короткі сповіщення на початку й після завершення Compaction (наприклад, "Compacting context..." і "Compaction complete"). Типово вимкнено, щоб Compaction була тихою.
+- `memoryFlush`: тихий агентний хід перед автоматичною Compaction для збереження довготривалих спогадів. Задайте `model` як точний провайдер/модель, наприклад `ollama/qwen3:8b`, коли цей службовий хід має залишатися на локальній моделі; перевизначення не успадковує fallback-ланцюг активного сеансу. Пропускається, коли робочий простір доступний лише для читання.

 ### `agents.defaults.contextPruning`

-Обрізає **старі результати інструментів** із контексту в пам’яті перед надсиланням до LLM. **Не** змінює історію сесії на диску.
+Обрізає **старі результати інструментів** із контексту в пам’яті перед надсиланням до LLM. **Не** змінює історію сеансу на диску.

 ```json5
 {
@ -619,25 +620,25 @@ Plugin надає нативний harness, як-от вбудований harne
 }
 ```

-<Accordion title="поведінка режиму cache-ttl">
+<Accordion title="cache-ttl mode behavior">

 - `mode: "cache-ttl"` вмикає проходи обрізання.
- `ttl` керує тим, як часто обрізання може запускатися знову (після останнього звернення до кешу).
- Обрізання спочатку м’яко скорочує завеликі результати інструментів, а потім, за потреби, повністю очищає старіші результати інструментів.
+- `ttl` керує тим, як часто обрізання може запускатися знову (після останнього дотику до кешу).
+- Обрізання спершу м’яко скорочує завеликі результати інструментів, а потім, якщо потрібно, жорстко очищає старіші результати інструментів.

 **М’яке скорочення** зберігає початок + кінець і вставляє `...` посередині.

-**Повне очищення** замінює весь результат інструмента заповнювачем.
+**Жорстке очищення** замінює весь результат інструмента на placeholder.

 Примітки:

- Блоки зображень ніколи не скорочуються й не очищуються.
- Співвідношення базуються на символах (приблизно), а не на точній кількості токенів.
+- Блоки зображень ніколи не скорочуються й не очищаються.
+- Коефіцієнти базуються на символах (приблизно), а не на точній кількості токенів.
 - Якщо існує менше ніж `keepLastAssistants` повідомлень асистента, обрізання пропускається.

 </Accordion>

-Див. [Обрізання сесії](/uk/concepts/session-pruning) для подробиць поведінки.
+Див. [Session Pruning](/uk/concepts/session-pruning), щоб дізнатися подробиці поведінки.

 ### Блокове потокове передавання

@ -657,9 +658,9 @@ Plugin надає нативний harness, як-от вбудований harne

 - Канали, відмінні від Telegram, потребують явного `*.blockStreaming: true`, щоб увімкнути блокові відповіді.
 - Перевизначення каналів: `channels.<channel>.blockStreamingCoalesce` (і варіанти для окремих облікових записів). Signal/Slack/Discord/Google Chat типово мають `minChars: 1500`.
- `humanDelay`: випадкова пауза між блоковими відповідями. `natural` = 800–2500ms. Перевизначення для окремого агента: `agents.list[].humanDelay`.
+- `humanDelay`: рандомізована пауза між блоковими відповідями. `natural` = 800–2500ms. Перевизначення для окремого агента: `agents.list[].humanDelay`.

-Див. [Потокове передавання](/uk/concepts/streaming) для подробиць поведінки та фрагментації.
+Див. [Streaming](/uk/concepts/streaming), щоб дізнатися подробиці поведінки й фрагментації.

 ### Індикатори набору

@ -674,16 +675,16 @@ Plugin надає нативний harness, як-от вбудований harne
 }
 ```

- Типово: `instant` для прямих чатів/згадок, `message` для групових чатів без згадки.
- Перевизначення для окремої сесії: `session.typingMode`, `session.typingIntervalSeconds`.
+- Типові значення: `instant` для прямих чатів/згадок, `message` для групових чатів без згадки.
+- Перевизначення для окремого сеансу: `session.typingMode`, `session.typingIntervalSeconds`.

-Див. [Індикатори набору](/uk/concepts/typing-indicators).
+Див. [Typing Indicators](/uk/concepts/typing-indicators).

 <a id="agentsdefaultssandbox"></a>

 ### `agents.defaults.sandbox`

-Необов’язкова ізоляція в sandbox для вбудованого агента. Повний посібник див. у [Sandboxing](/uk/gateway/sandboxing).
+Необов’язкова ізоляція для вбудованого агента. Повний посібник див. у [Sandboxing](/uk/gateway/sandboxing).

 ```json5
 {
@ -778,54 +779,54 @@ Plugin надає нативний harness, як-от вбудований harne
 }
 ```

-<Accordion title="Sandbox details">
+<Accordion title="Відомості про пісочницю">

-**Backend:**
+**Бекенд:**

 - `docker`: локальне середовище виконання Docker (типово)
 - `ssh`: універсальне віддалене середовище виконання на базі SSH
 - `openshell`: середовище виконання OpenShell

-Коли вибрано `backend: "openshell"`, специфічні для середовища виконання налаштування переміщуються до
+Коли вибрано `backend: "openshell"`, параметри, специфічні для середовища виконання, переносяться до
 `plugins.entries.openshell.config`.

 **Конфігурація SSH-бекенду:**

- `target`: ціль SSH у формі `user@host[:port]`
+- `target`: SSH-ціль у форматі `user@host[:port]`
 - `command`: команда SSH-клієнта (типово: `ssh`)
- `workspaceRoot`: абсолютний віддалений корінь, що використовується для робочих просторів у межах кожної області
+- `workspaceRoot`: абсолютний віддалений корінь, що використовується для робочих просторів за областями
 - `identityFile` / `certificateFile` / `knownHostsFile`: наявні локальні файли, що передаються до OpenSSH
 - `identityData` / `certificateData` / `knownHostsData`: вбудований вміст або SecretRefs, які OpenClaw матеріалізує в тимчасові файли під час виконання
 - `strictHostKeyChecking` / `updateHostKeys`: параметри політики ключів хоста OpenSSH

 **Пріоритет автентифікації SSH:**

- `identityData` має перевагу над `identityFile`
- `certificateData` має перевагу над `certificateFile`
- `knownHostsData` має перевагу над `knownHostsFile`
- значення `*Data` на базі SecretRef розв’язуються з активного знімка середовища виконання секретів до запуску сесії пісочниці
+- `identityData` має пріоритет над `identityFile`
+- `certificateData` має пріоритет над `certificateFile`
+- `knownHostsData` має пріоритет над `knownHostsFile`
+- Значення `*Data` на базі SecretRef розв’язуються з активного знімка середовища виконання секретів до запуску сесії пісочниці

 **Поведінка SSH-бекенду:**

- одноразово заповнює віддалений робочий простір після створення або повторного створення
- потім зберігає віддалений робочий простір SSH канонічним
- маршрутизує `exec`, файлові інструменти й медіашляхи через SSH
+- одноразово засіває віддалений робочий простір після створення або повторного створення
+- потім тримає віддалений SSH-робочий простір канонічним
+- маршрутизує `exec`, файлові інструменти та шляхи до медіа через SSH
 - не синхронізує віддалені зміни назад на хост автоматично
- не підтримує контейнери браузера пісочниці
+- не підтримує браузерні контейнери пісочниці

 **Доступ до робочого простору:**

- `none`: робочий простір пісочниці для кожної області в `~/.openclaw/sandboxes`
+- `none`: робочий простір пісочниці для окремої області в `~/.openclaw/sandboxes`
 - `ro`: робочий простір пісочниці в `/workspace`, робочий простір агента змонтовано лише для читання в `/agent`
 - `rw`: робочий простір агента змонтовано для читання/запису в `/workspace`

 **Область:**

- `session`: контейнер і робочий простір для кожної сесії
+- `session`: контейнер і робочий простір для окремої сесії
 - `agent`: один контейнер і робочий простір на агента (типово)
- `shared`: спільний контейнер і робочий простір (без ізоляції між сесіями)
+- `shared`: спільний контейнер і робочий простір (без міжсесійної ізоляції)

-**Конфігурація Plugin OpenShell:**
+**Конфігурація OpenShell Plugin:**

 ```json5
 {
@ -853,29 +854,29 @@ Plugin надає нативний harness, як-от вбудований harne

 **Режим OpenShell:**

- `mirror`: заповнювати віддалений простір із локального перед exec, синхронізувати назад після exec; локальний робочий простір лишається канонічним
- `remote`: одноразово заповнити віддалений простір під час створення пісочниці, потім зберігати віддалений робочий простір канонічним
+- `mirror`: засіває віддалений простір із локального перед exec, синхронізує назад після exec; локальний робочий простір залишається канонічним
+- `remote`: засіває віддалений простір один раз під час створення пісочниці, потім тримає віддалений робочий простір канонічним

-У режимі `remote` локальні для хоста зміни, зроблені поза OpenClaw, не синхронізуються в пісочницю автоматично після кроку заповнення.
-Транспортом є SSH у пісочницю OpenShell, але Plugin керує життєвим циклом пісочниці й необов’язковою дзеркальною синхронізацією.
+У режимі `remote` локальні правки на хості, зроблені поза OpenClaw, не синхронізуються в пісочницю автоматично після етапу засівання.
+Транспортом є SSH у пісочницю OpenShell, але Plugin керує життєвим циклом пісочниці та необов’язковою дзеркальною синхронізацією.

-**`setupCommand`** запускається один раз після створення контейнера (через `sh -lc`). Потребує виходу в мережу, кореневої файлової системи з можливістю запису та користувача root.
+**`setupCommand`** виконується один раз після створення контейнера (через `sh -lc`). Потребує вихідного доступу до мережі, кореня з правом запису та користувача root.

-**Для контейнерів типово використовується `network: "none"`** — установіть `"bridge"` (або власну bridge-мережу), якщо агенту потрібен вихідний доступ.
-`"host"` заблоковано. `"container:<id>"` типово заблоковано, якщо ви явно не встановите
-`sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true` (аварійний виняток).
+**Контейнери типово використовують `network: "none"`** — встановіть `"bridge"` (або власну bridge-мережу), якщо агенту потрібен вихідний доступ.
+`"host"` заблоковано. `"container:<id>"` заблоковано типово, якщо ви явно не встановите
+`sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true` (аварійний обхід).

 **Вхідні вкладення** розміщуються в `media/inbound/*` в активному робочому просторі.

-**`docker.binds`** монтує додаткові каталоги хоста; глобальні прив’язки та прив’язки для окремого агента об’єднуються.
+**`docker.binds`** монтує додаткові каталоги хоста; глобальні прив’язки та прив’язки для окремих агентів об’єднуються.

-**Пісочниця браузера** (`sandbox.browser.enabled`): Chromium + CDP у контейнері. URL noVNC вставляється в системний промпт. Не потребує `browser.enabled` в `openclaw.json`.
-Доступ спостерігача noVNC типово використовує автентифікацію VNC, а OpenClaw видає короткочасний URL із токеном (замість розкриття пароля в спільному URL).
+**Ізольований браузер** (`sandbox.browser.enabled`): Chromium + CDP у контейнері. URL noVNC додається до системного промпта. Не потребує `browser.enabled` в `openclaw.json`.
+Доступ спостерігача noVNC типово використовує автентифікацію VNC, а OpenClaw випускає короткочасний URL із токеном (замість розкриття пароля в спільному URL).

- `allowHostControl: false` (типово) блокує сесіям у пісочниці можливість націлюватися на браузер хоста.
- `network` типово дорівнює `openclaw-sandbox-browser` (виділена bridge-мережа). Установлюйте `bridge` лише тоді, коли вам явно потрібна глобальна bridge-зв’язність.
- `cdpSourceRange` необов’язково обмежує вхід CDP на межі контейнера діапазоном CIDR (наприклад, `172.21.0.1/32`).
- `sandbox.browser.binds` монтує додаткові каталоги хоста лише в контейнер браузера пісочниці. Коли встановлено (включно з `[]`), це замінює `docker.binds` для контейнера браузера.
+- `allowHostControl: false` (типово) блокує націлювання ізольованих сесій на браузер хоста.
+- `network` типово має значення `openclaw-sandbox-browser` (виділена bridge-мережа). Установлюйте `bridge` лише тоді, коли вам явно потрібна глобальна bridge-зв’язність.
+- `cdpSourceRange` необов’язково обмежує вхід CDP на межі контейнера до діапазону CIDR (наприклад, `172.21.0.1/32`).
+- `sandbox.browser.binds` монтує додаткові каталоги хоста лише в контейнер браузера пісочниці. Якщо задано (включно з `[]`), це замінює `docker.binds` для контейнера браузера.
 - Типові параметри запуску визначено в `scripts/sandbox-browser-entrypoint.sh` і налаштовано для контейнерних хостів:
  - `--remote-debugging-address=127.0.0.1`
  - `--remote-debugging-port=<derived from OPENCLAW_BROWSER_CDP_PORT>`
@ -895,20 +896,20 @@ Plugin надає нативний harness, як-от вбудований harne
  - `--metrics-recording-only`
  - `--disable-extensions` (типово ввімкнено)
  - `--disable-3d-apis`, `--disable-software-rasterizer` і `--disable-gpu`
-    увімкнено типово; їх можна вимкнути за допомогою
-    `OPENCLAW_BROWSER_DISABLE_GRAPHICS_FLAGS=0`, якщо це потрібно для використання WebGL/3D.
+    типово ввімкнені й можуть бути вимкнені за допомогою
+    `OPENCLAW_BROWSER_DISABLE_GRAPHICS_FLAGS=0`, якщо цього потребує використання WebGL/3D.
  - `OPENCLAW_BROWSER_DISABLE_EXTENSIONS=0` повторно вмикає розширення, якщо ваш робочий процес
    залежить від них.
  - `--renderer-process-limit=2` можна змінити за допомогою
-    `OPENCLAW_BROWSER_RENDERER_PROCESS_LIMIT=<N>`; установіть `0`, щоб використовувати типове
-    обмеження процесів Chromium.
+    `OPENCLAW_BROWSER_RENDERER_PROCESS_LIMIT=<N>`; встановіть `0`, щоб використовувати
+    типове обмеження процесів Chromium.
  - плюс `--no-sandbox`, коли ввімкнено `noSandbox`.
-  - Типові значення є базовими для образу контейнера; використовуйте власний образ браузера з власною
-    точкою входу, щоб змінити типові значення контейнера.
+  - Типові значення є базовою конфігурацією образу контейнера; використовуйте власний образ браузера з власною
+    точкою входу, щоб змінити типові параметри контейнера.

 </Accordion>

-Пісочниця браузера й `sandbox.docker.binds` доступні лише для Docker.
+Ізоляція браузера в пісочниці та `sandbox.docker.binds` працюють лише з Docker.

 Зібрати образи:

@ -919,13 +920,13 @@ scripts/sandbox-browser-setup.sh   # optional browser image

 ### `agents.list` (перевизначення для окремого агента)

-Використовуйте `agents.list[].tts`, щоб надати агенту власного постачальника TTS, голос, модель,
+Використовуйте `agents.list[].tts`, щоб задати агенту власного провайдера TTS, голос, модель,
 стиль або режим автоматичного TTS. Блок агента глибоко об’єднується поверх глобального
-`messages.tts`, тож спільні облікові дані можуть залишатися в одному місці, а окремі
-агенти перевизначають лише потрібні їм поля голосу або постачальника. Перевизначення активного агента
+`messages.tts`, тож спільні облікові дані можуть лишатися в одному місці, а окремі
+агенти перевизначають лише потрібні їм поля голосу або провайдера. Перевизначення активного агента
 застосовується до автоматичних озвучених відповідей, `/tts audio`, `/tts status` і
 інструмента агента `tts`. Див. [Перетворення тексту на мовлення](/uk/tools/tts#per-agent-voice-overrides)
-для прикладів постачальників і пріоритету.
+для прикладів провайдерів і пріоритету.

 ```json5
 {
@ -979,26 +980,26 @@ scripts/sandbox-browser-setup.sh   # optional browser image
 }
 ```

- `id`: стабільний ідентифікатор агента (обов’язково).
- `default`: коли задано кілька, перший має пріоритет (записується попередження). Якщо не задано жодного, типовим буде перший запис списку.
- `model`: рядкова форма задає сувору основну модель для окремого агента без резервної моделі; об’єктна форма `{ primary }` також сувора, якщо не додати `fallbacks`. Використайте `{ primary, fallbacks: [...] }`, щоб увімкнути резервні варіанти для цього агента, або `{ primary, fallbacks: [] }`, щоб явно вказати сувору поведінку. Завдання Cron, які перевизначають лише `primary`, усе одно успадковують типові резервні варіанти, якщо не задати `fallbacks: []`.
+- `id`: стабільний id агента (обов’язково).
+- `default`: коли задано кілька, перший має пріоритет (записується попередження). Якщо не задано жодного, типовим є перший запис у списку.
+- `model`: рядкова форма задає строгий основний параметр для окремого агента без fallback моделі; об’єктна форма `{ primary }` також строга, якщо ви не додасте `fallbacks`. Використовуйте `{ primary, fallbacks: [...] }`, щоб увімкнути fallback для цього агента, або `{ primary, fallbacks: [] }`, щоб явно задати строгу поведінку. Завдання Cron, які перевизначають лише `primary`, усе ще успадковують типові fallback, якщо ви не задасте `fallbacks: []`.
 - `params`: параметри потоку для окремого агента, об’єднані поверх вибраного запису моделі в `agents.defaults.models`. Використовуйте це для перевизначень, специфічних для агента, як-от `cacheRetention`, `temperature` або `maxTokens`, без дублювання всього каталогу моделей.
- `tts`: необов’язкові перевизначення перетворення тексту на мовлення для окремого агента. Блок глибоко об’єднується поверх `messages.tts`, тож зберігайте спільні облікові дані провайдера та політику резервування в `messages.tts`, а тут задавайте лише значення, специфічні для персони, як-от провайдера, голос, модель, стиль або автоматичний режим.
- `skills`: необов’язковий список дозволених Skills для окремого агента. Якщо пропущено, агент успадковує `agents.defaults.skills`, коли його задано; явний список замінює типові значення замість об’єднання, а `[]` означає відсутність Skills.
- `thinkingDefault`: необов’язковий типовий рівень мислення для окремого агента (`off | minimal | low | medium | high | xhigh | adaptive | max`). Перевизначає `agents.defaults.thinkingDefault` для цього агента, коли не задано перевизначення для окремого повідомлення або сесії. Вибраний профіль провайдера/моделі визначає, які значення є дійсними; для Google Gemini `adaptive` зберігає динамічне мислення, кероване провайдером (`thinkingLevel` пропущено в Gemini 3/3.1, `thinkingBudget: -1` у Gemini 2.5).
- `reasoningDefault`: необов’язкова типова видимість міркування для окремого агента (`on | off | stream`). Застосовується, коли не задано перевизначення міркування для окремого повідомлення або сесії.
+- `tts`: необов’язкові перевизначення перетворення тексту на мовлення для окремого агента. Блок глибоко об’єднується поверх `messages.tts`, тому зберігайте спільні облікові дані провайдера та політику fallback у `messages.tts`, а тут задавайте лише специфічні для персони значення, як-от provider, voice, model, style або автоматичний режим.
+- `skills`: необов’язковий список дозволених Skills для окремого агента. Якщо пропущено, агент успадковує `agents.defaults.skills`, коли це задано; явний список замінює типові значення замість об’єднання, а `[]` означає відсутність Skills.
+- `thinkingDefault`: необов’язковий типовий рівень мислення для окремого агента (`off | minimal | low | medium | high | xhigh | adaptive | max`). Перевизначає `agents.defaults.thinkingDefault` для цього агента, коли не задано перевизначення для окремого повідомлення або сесії. Вибраний профіль провайдера/моделі контролює, які значення є дійсними; для Google Gemini `adaptive` зберігає динамічне мислення, кероване провайдером (`thinkingLevel` пропущено на Gemini 3/3.1, `thinkingBudget: -1` на Gemini 2.5).
+- `reasoningDefault`: необов’язкова типова видимість reasoning для окремого агента (`on | off | stream`). Застосовується, коли не задано перевизначення reasoning для окремого повідомлення або сесії.
 - `fastModeDefault`: необов’язкове типове значення швидкого режиму для окремого агента (`true | false`). Застосовується, коли не задано перевизначення швидкого режиму для окремого повідомлення або сесії.
- `agentRuntime`: необов’язкове низькорівневе перевизначення політики середовища виконання для окремого агента. Використайте `{ id: "codex" }`, щоб зробити одного агента лише Codex, тоді як інші агенти зберігатимуть типовий резервний PI у режимі `auto`.
- `runtime`: необов’язковий дескриптор середовища виконання для окремого агента. Використайте `type: "acp"` із типовими значеннями `runtime.acp` (`agent`, `backend`, `mode`, `cwd`), коли агент має типово використовувати сесії ACP harness.
- `identity.avatar`: шлях відносно робочого простору, URL `http(s)` або URI `data:`.
+- `agentRuntime`: необов’язкове низькорівневе перевизначення політики runtime для окремого агента. Використовуйте `{ id: "codex" }`, щоб зробити одного агента лише Codex, тоді як інші агенти зберігають типовий fallback PI у режимі `auto`.
+- `runtime`: необов’язковий дескриптор runtime для окремого агента. Використовуйте `type: "acp"` з типовими значеннями `runtime.acp` (`agent`, `backend`, `mode`, `cwd`), коли агент має типово використовувати сесії harness ACP.
+- `identity.avatar`: шлях відносно workspace, URL `http(s)` або URI `data:`.
 - `identity` виводить типові значення: `ackReaction` з `emoji`, `mentionPatterns` з `name`/`emoji`.
- `subagents.allowAgents`: список дозволених ідентифікаторів агентів для явних цілей `sessions_spawn.agentId` (`["*"]` = будь-який; типово: лише той самий агент). Додайте ідентифікатор запитувача, коли потрібно дозволити самоспрямовані виклики `agentId`.
- Захист успадкування пісочниці: якщо сесію запитувача ізольовано в пісочниці, `sessions_spawn` відхиляє цілі, які запускалися б без пісочниці.
- `subagents.requireAgentId`: коли true, блокує виклики `sessions_spawn`, які пропускають `agentId` (примушує до явного вибору профілю; типово: false).
+- `subagents.allowAgents`: список дозволених id агентів для явних цілей `sessions_spawn.agentId` (`["*"]` = будь-який; типово: лише той самий агент). Додайте id запитувача, коли самонацілені виклики `agentId` мають бути дозволені.
+- Запобіжник успадкування пісочниці: якщо сесія запитувача працює в пісочниці, `sessions_spawn` відхиляє цілі, які запускалися б без пісочниці.
+- `subagents.requireAgentId`: коли true, блокує виклики `sessions_spawn`, які пропускають `agentId` (змушує явно вибирати профіль; типово: false).

 ---

-## Маршрутизація з кількома агентами
+## Маршрутизація між кількома агентами

 Запускайте кілька ізольованих агентів в одному Gateway. Див. [Multi-Agent](/uk/concepts/multi-agent).

@ -1017,31 +1018,31 @@ scripts/sandbox-browser-setup.sh   # optional browser image
 }
 ```

-### Поля зіставлення прив’язки
+### Поля відповідності прив’язки

- `type` (необов’язково): `route` для звичайної маршрутизації (відсутній тип типово означає route), `acp` для сталих прив’язок розмов ACP.
+- `type` (необов’язково): `route` для звичайної маршрутизації (відсутній type типово означає route), `acp` для постійних прив’язок розмов ACP.
 - `match.channel` (обов’язково)
 - `match.accountId` (необов’язково; `*` = будь-який обліковий запис; пропущено = типовий обліковий запис)
 - `match.peer` (необов’язково; `{ kind: direct|group|channel, id }`)
 - `match.guildId` / `match.teamId` (необов’язково; залежить від каналу)
 - `acp` (необов’язково; лише для `type: "acp"`): `{ mode, label, cwd, backend }`

-**Детермінований порядок зіставлення:**
+**Детермінований порядок відповідності:**

 1. `match.peer`
 2. `match.guildId`
 3. `match.teamId`
-4. `match.accountId` (точний, без peer/guild/team)
-5. `match.accountId: "*"` (для всього каналу)
+4. `match.accountId` (точний збіг, без peer/guild/team)
+5. `match.accountId: "*"` (на весь канал)
 6. Типовий агент

-У межах кожного рівня перемагає перший відповідний запис `bindings`.
+У межах кожного рівня перший відповідний запис `bindings` має пріоритет.

-Для записів `type: "acp"` OpenClaw визначає відповідність за точною ідентичністю розмови (`match.channel` + account + `match.peer.id`) і не використовує наведений вище порядок рівнів прив’язки маршруту.
+Для записів `type: "acp"` OpenClaw визначає відповідність за точною ідентичністю розмови (`match.channel` + обліковий запис + `match.peer.id`) і не використовує наведений вище рівневий порядок прив’язок маршруту.

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

-<Accordion title="Full access (no sandbox)">
+<Accordion title="Повний доступ (без пісочниці)">

 ```json5
 {
@ -1059,7 +1060,7 @@ scripts/sandbox-browser-setup.sh   # optional browser image

 </Accordion>

-<Accordion title="Read-only tools + workspace">
+<Accordion title="Інструменти лише для читання + workspace">

 ```json5
 {
@ -1088,7 +1089,7 @@ scripts/sandbox-browser-setup.sh   # optional browser image

 </Accordion>

-<Accordion title="No filesystem access (messaging only)">
+<Accordion title="Без доступу до файлової системи (лише обмін повідомленнями)">

 ```json5
 {
@ -1134,7 +1135,7 @@ scripts/sandbox-browser-setup.sh   # optional browser image

 </Accordion>

-Див. [Багатоагентна пісочниця та інструменти](/uk/tools/multi-agent-sandbox-tools) для деталей пріоритетності.
+Докладніше про пріоритети див. у [пісочниці й інструментах для кількох агентів](/uk/tools/multi-agent-sandbox-tools).

 ---

@ -1184,36 +1185,36 @@ scripts/sandbox-browser-setup.sh   # optional browser image
 }
 ```

-<Accordion title="Session field details">
+<Accordion title="Відомості про поля сесії">

- **`scope`**: базова стратегія групування сесій для контекстів групового чату.
+- **`scope`**: базова стратегія групування сесій для контекстів групових чатів.
  - `per-sender` (типово): кожен відправник отримує ізольовану сесію в межах контексту каналу.
-  - `global`: усі учасники в контексті каналу спільно використовують одну сесію (використовуйте лише тоді, коли спільний контекст є навмисним).
- **`dmScope`**: спосіб групування приватних повідомлень.
+  - `global`: усі учасники в контексті каналу спільно використовують одну сесію (використовуйте лише тоді, коли потрібен спільний контекст).
+- **`dmScope`**: як групуються приватні повідомлення.
  - `main`: усі приватні повідомлення спільно використовують основну сесію.
-  - `per-peer`: ізоляція за id відправника між каналами.
-  - `per-channel-peer`: ізоляція за каналом + відправником (рекомендовано для скриньок вхідних повідомлень із кількома користувачами).
-  - `per-account-channel-peer`: ізоляція за обліковим записом + каналом + відправником (рекомендовано для кількох облікових записів).
- **`identityLinks`**: зіставляє канонічні id із вузлами з префіксом провайдера для спільного використання сесій між каналами. Команди докування, як-от `/dock_discord`, використовують те саме зіставлення, щоб перемкнути маршрут відповіді активної сесії на інший пов’язаний вузол каналу; див. [Докування каналів](/uk/concepts/channel-docking).
- **`reset`**: основна політика скидання. `daily` скидає о `atHour` за місцевим часом; `idle` скидає після `idleMinutes`. Коли налаштовано обидва варіанти, спрацьовує той, що завершується першим. Актуальність щоденного скидання використовує `sessionStartedAt` рядка сесії; актуальність скидання за простоєм використовує `lastInteractionAt`. Фонові/системні записи подій, як-от Heartbeat, пробудження Cron, сповіщення exec і службовий облік Gateway, можуть оновлювати `updatedAt`, але вони не підтримують актуальність сесій daily/idle.
- **`resetByType`**: перевизначення за типом (`direct`, `group`, `thread`). Застаріле `dm` приймається як псевдонім для `direct`.
- **`parentForkMaxTokens`**: максимальне значення `totalTokens` батьківської сесії, дозволене під час створення розгалуженої сесії потоку (типово `100000`).
-  - Якщо `totalTokens` батьківської сесії перевищує це значення, OpenClaw запускає нову сесію потоку замість успадкування історії транскрипту батьківської сесії.
-  - Установіть `0`, щоб вимкнути цей захист і завжди дозволяти розгалуження від батьківської сесії.
- **`mainKey`**: застаріле поле. Під час виконання для основного кошика прямого чату завжди використовується `"main"`.
- **`agentToAgent.maxPingPongTurns`**: максимальна кількість ходів відповідей між агентами під час обмінів агент-агент (ціле число, діапазон: `0`–`5`). `0` вимикає ланцюжок ping-pong.
- **`sendPolicy`**: зіставлення за `channel`, `chatType` (`direct|group|channel`, із застарілим псевдонімом `dm`), `keyPrefix` або `rawKeyPrefix`. Перша заборона має пріоритет.
- **`maintenance`**: очищення сховища сесій + елементи керування збереженням.
-  - `mode`: `warn` лише виводить попередження; `enforce` застосовує очищення.
-  - `pruneAfter`: віковий поріг для застарілих записів (типово `30d`).
-  - `maxEntries`: максимальна кількість записів у `sessions.json` (типово `500`). Під час виконання пакетне очищення записується з невеликим буфером верхнього рівня для лімітів виробничого розміру; `openclaw sessions cleanup --enforce` застосовує ліміт негайно.
+  - `per-peer`: ізолювати за id відправника між каналами.
+  - `per-channel-peer`: ізолювати за каналом + відправником (рекомендовано для поштових скриньок із кількома користувачами).
+  - `per-account-channel-peer`: ізолювати за обліковим записом + каналом + відправником (рекомендовано для кількох облікових записів).
+- **`identityLinks`**: зіставляє канонічні id із peers із префіксом провайдера для спільного використання сесій між каналами. Команди стикування, як-от `/dock_discord`, використовують те саме зіставлення, щоб перемкнути маршрут відповіді активної сесії на інший пов'язаний peer каналу; див. [Стикування каналів](/uk/concepts/channel-docking).
+- **`reset`**: основна політика скидання. `daily` скидає о `atHour` за місцевим часом; `idle` скидає після `idleMinutes`. Коли налаштовано обидва, спрацьовує те, що настає першим. Актуальність щоденного скидання використовує `sessionStartedAt` рядка сесії; актуальність скидання через бездіяльність використовує `lastInteractionAt`. Фонові/системні записи подій, як-от Heartbeat, пробудження Cron, сповіщення exec і службовий облік Gateway, можуть оновлювати `updatedAt`, але вони не підтримують актуальність щоденних/неактивних сесій.
+- **`resetByType`**: перевизначення за типом (`direct`, `group`, `thread`). Застарілий `dm` приймається як псевдонім для `direct`.
+- **`parentForkMaxTokens`**: максимальне значення `totalTokens` батьківської сесії, дозволене під час створення форкованої сесії потоку (типово `100000`).
+  - Якщо батьківський `totalTokens` перевищує це значення, OpenClaw починає нову сесію потоку замість успадкування історії транскрипту батьківської сесії.
+  - Установіть `0`, щоб вимкнути цей захист і завжди дозволяти форкування від батьківської сесії.
+- **`mainKey`**: застаріле поле. Runtime завжди використовує `"main"` для основного сегмента прямого чату.
+- **`agentToAgent.maxPingPongTurns`**: максимальна кількість ходів-відповідей між агентами під час обмінів агент-агент (ціле число, діапазон: `0`–`5`). `0` вимикає ланцюжок ping-pong.
+- **`sendPolicy`**: зіставлення за `channel`, `chatType` (`direct|group|channel`, із застарілим псевдонімом `dm`), `keyPrefix` або `rawKeyPrefix`. Перша заборона перемагає.
+- **`maintenance`**: очищення сховища сесій + елементи керування зберіганням.
+  - `mode`: `warn` лише видає попередження; `enforce` застосовує очищення.
+  - `pruneAfter`: вікова межа для застарілих записів (типово `30d`).
+  - `maxEntries`: максимальна кількість записів у `sessions.json` (типово `500`). Runtime записує пакетне очищення з невеликим буфером верхнього порога для лімітів production-розміру; `openclaw sessions cleanup --enforce` застосовує ліміт негайно.
  - `rotateBytes`: застаріле й ігнорується; `openclaw doctor --fix` видаляє його зі старіших конфігурацій.
-  - `resetArchiveRetention`: термін збереження архівів транскриптів `*.reset.<timestamp>`. Типово дорівнює `pruneAfter`; установіть `false`, щоб вимкнути.
-  - `maxDiskBytes`: необов’язковий дисковий бюджет каталогу сесій. У режимі `warn` записує попередження до журналу; у режимі `enforce` спершу видаляє найстаріші артефакти/сесії.
-  - `highWaterBytes`: необов’язкова ціль після очищення бюджету. Типово дорівнює `80%` від `maxDiskBytes`.
- **`threadBindings`**: глобальні типові значення для можливостей сесій, прив’язаних до потоків.
+  - `resetArchiveRetention`: зберігання архівів транскриптів `*.reset.<timestamp>`. Типово дорівнює `pruneAfter`; установіть `false`, щоб вимкнути.
+  - `maxDiskBytes`: необов'язковий дисковий бюджет каталогу сесій. У режимі `warn` журналює попередження; у режимі `enforce` спочатку видаляє найстаріші артефакти/сесії.
+  - `highWaterBytes`: необов'язкова ціль після очищення бюджету. Типово дорівнює `80%` від `maxDiskBytes`.
+- **`threadBindings`**: глобальні типові значення для функцій сесій, прив'язаних до потоків.
  - `enabled`: головний типовий перемикач (провайдери можуть перевизначати; Discord використовує `channels.discord.threadBindings.enabled`)
-  - `idleHours`: типове автоматичне зняття фокуса після неактивності в годинах (`0` вимикає; провайдери можуть перевизначати)
+  - `idleHours`: типове автоматичне зняття фокуса через бездіяльність у годинах (`0` вимикає; провайдери можуть перевизначати)
  - `maxAgeHours`: типовий жорсткий максимальний вік у годинах (`0` вимикає; провайдери можуть перевизначати)

 </Accordion>
@ -1252,36 +1253,36 @@ scripts/sandbox-browser-setup.sh   # optional browser image

 ### Префікс відповіді

-Перевизначення для окремого каналу/облікового запису: `channels.<channel>.responsePrefix`, `channels.<channel>.accounts.<id>.responsePrefix`.
+Перевизначення для каналу/облікового запису: `channels.<channel>.responsePrefix`, `channels.<channel>.accounts.<id>.responsePrefix`.

-Визначення (найконкретніше має пріоритет): обліковий запис → канал → глобальне. `""` вимикає та зупиняє каскад. `"auto"` виводить `[{identity.name}]`.
+Визначення (перемагає найконкретніше): обліковий запис → канал → глобальне. `""` вимикає і зупиняє каскад. `"auto"` виводить `[{identity.name}]`.

 **Змінні шаблону:**

-| Змінна            | Опис                         | Приклад                     |
-| ----------------- | ---------------------------- | --------------------------- |
-| `{model}`         | Коротка назва моделі         | `claude-opus-4-6`           |
-| `{modelFull}`     | Повний ідентифікатор моделі  | `anthropic/claude-opus-4-6` |
-| `{provider}`      | Назва провайдера             | `anthropic`                 |
-| `{thinkingLevel}` | Поточний рівень міркування   | `high`, `low`, `off`        |
-| `{identity.name}` | Назва ідентичності агента    | (те саме, що й `"auto"`)    |
+| Змінна           | Опис                   | Приклад                     |
+| ---------------- | ---------------------- | --------------------------- |
+| `{model}`         | Коротка назва моделі   | `claude-opus-4-6`           |
+| `{modelFull}`     | Повний ідентифікатор моделі | `anthropic/claude-opus-4-6` |
+| `{provider}`      | Назва провайдера       | `anthropic`                 |
+| `{thinkingLevel}` | Поточний рівень мислення | `high`, `low`, `off`        |
+| `{identity.name}` | Ім’я ідентичності агента | (те саме, що й `"auto"`)    |

-Змінні не залежать від регістру. `{think}` є псевдонімом для `{thinkingLevel}`.
+Змінні нечутливі до регістру. `{think}` є псевдонімом для `{thinkingLevel}`.

 ### Реакція підтвердження

- За замовчуванням використовується `identity.emoji` активного агента, інакше `"👀"`. Задайте `""`, щоб вимкнути.
- Перевизначення для окремого каналу: `channels.<channel>.ackReaction`, `channels.<channel>.accounts.<id>.ackReaction`.
+- Типово використовує `identity.emoji` активного агента, інакше `"👀"`. Установіть `""`, щоб вимкнути.
+- Перевизначення для каналу: `channels.<channel>.ackReaction`, `channels.<channel>.accounts.<id>.ackReaction`.
 - Порядок визначення: обліковий запис → канал → `messages.ackReaction` → резервне значення ідентичності.
- Область дії: `group-mentions` (за замовчуванням), `group-all`, `direct`, `all`.
- `removeAckAfterReply`: прибирає підтвердження після відповіді в каналах, що підтримують реакції, як-от Slack, Discord, Telegram, WhatsApp і BlueBubbles.
- `messages.statusReactions.enabled`: вмикає реакції статусу життєвого циклу в Slack, Discord і Telegram.
-  У Slack і Discord незадане значення залишає реакції статусу ввімкненими, коли активні реакції підтвердження.
-  У Telegram задайте його явно як `true`, щоб увімкнути реакції статусу життєвого циклу.
+- Область: `group-mentions` (типово), `group-all`, `direct`, `all`.
+- `removeAckAfterReply`: видаляє підтвердження після відповіді в каналах із підтримкою реакцій, таких як Slack, Discord, Telegram, WhatsApp і BlueBubbles.
+- `messages.statusReactions.enabled`: вмикає реакції стану життєвого циклу в Slack, Discord і Telegram.
+  У Slack і Discord незадане значення залишає реакції стану ввімкненими, коли реакції підтвердження активні.
+  У Telegram явно встановіть `true`, щоб увімкнути реакції стану життєвого циклу.

-### Дебаунс вхідних повідомлень
+### Вхідне усунення брязкоту

-Об’єднує швидкі текстові повідомлення від одного відправника в один хід агента. Медіа/вкладення надсилаються негайно. Керівні команди обходять дебаунс.
+Об’єднує швидкі текстові повідомлення від одного відправника в один хід агента. Медіа/вкладення скидають чергу негайно. Команди керування оминають усунення брязкоту.

 ### TTS (перетворення тексту на мовлення)

@ -1331,19 +1332,19 @@ scripts/sandbox-browser-setup.sh   # optional browser image
 }
 ```

- `auto` керує стандартним автоматичним режимом TTS: `off`, `always`, `inbound` або `tagged`. `/tts on|off` може перевизначати локальні налаштування, а `/tts status` показує ефективний стан.
- `summaryModel` перевизначає `agents.defaults.model.primary` для автоматичного резюме.
- `modelOverrides` увімкнено за замовчуванням; `modelOverrides.allowProvider` за замовчуванням має значення `false` (потрібне явне увімкнення).
- API-ключі використовують резервні значення `ELEVENLABS_API_KEY`/`XI_API_KEY` і `OPENAI_API_KEY`.
+- `auto` керує типовим режимом автоматичного TTS: `off`, `always`, `inbound` або `tagged`. `/tts on|off` може перевизначати локальні налаштування, а `/tts status` показує фактичний стан.
+- `summaryModel` перевизначає `agents.defaults.model.primary` для автоматичного підсумку.
+- `modelOverrides` увімкнено типово; `modelOverrides.allowProvider` типово має значення `false` (потрібна явна згода).
+- API-ключі мають резервні значення `ELEVENLABS_API_KEY`/`XI_API_KEY` і `OPENAI_API_KEY`.
 - Вбудовані провайдери мовлення належать Plugin. Якщо задано `plugins.allow`, додайте кожен Plugin провайдера TTS, який хочете використовувати, наприклад `microsoft` для Edge TTS. Застарілий ідентифікатор провайдера `edge` приймається як псевдонім для `microsoft`.
 - `providers.openai.baseUrl` перевизначає кінцеву точку OpenAI TTS. Порядок визначення: конфігурація, потім `OPENAI_TTS_BASE_URL`, потім `https://api.openai.com/v1`.
- Коли `providers.openai.baseUrl` вказує на кінцеву точку не OpenAI, OpenClaw розглядає її як OpenAI-сумісний сервер TTS і послаблює перевірку моделі/голосу.
+- Коли `providers.openai.baseUrl` вказує на кінцеву точку не OpenAI, OpenClaw розглядає її як сумісний з OpenAI сервер TTS і послаблює перевірку моделі/голосу.

 ---

 ## Talk

-Значення за замовчуванням для режиму Talk (macOS/iOS/Android).
+Типові значення для режиму Talk (macOS/iOS/Android).

 ```json5
 {
@ -1374,14 +1375,14 @@ scripts/sandbox-browser-setup.sh   # optional browser image

 - `talk.provider` має відповідати ключу в `talk.providers`, коли налаштовано кілька провайдерів Talk.
 - Застарілі пласкі ключі Talk (`talk.voiceId`, `talk.voiceAliases`, `talk.modelId`, `talk.outputFormat`, `talk.apiKey`) призначені лише для сумісності й автоматично мігруються в `talk.providers.<provider>`.
- Voice ID використовують резервні значення `ELEVENLABS_VOICE_ID` або `SAG_VOICE_ID`.
- `providers.*.apiKey` приймає рядки відкритого тексту або об’єкти SecretRef.
+- Ідентифікатори голосів мають резервні значення `ELEVENLABS_VOICE_ID` або `SAG_VOICE_ID`.
+- `providers.*.apiKey` приймає відкриті текстові рядки або об’єкти SecretRef.
 - Резервне значення `ELEVENLABS_API_KEY` застосовується лише тоді, коли API-ключ Talk не налаштовано.
- `providers.*.voiceAliases` дає директивам Talk використовувати дружні назви.
- `providers.mlx.modelId` вибирає репозиторій Hugging Face, який використовує локальний помічник MLX на macOS. Якщо пропущено, macOS використовує `mlx-community/Soprano-80M-bf16`.
- Відтворення macOS MLX виконується через вбудований помічник `openclaw-mlx-tts`, коли він присутній, або через виконуваний файл у `PATH`; `OPENCLAW_MLX_TTS_BIN` перевизначає шлях до помічника для розробки.
- `speechLocale` задає ідентифікатор локалі BCP 47, який використовується розпізнаванням мовлення Talk на iOS/macOS. Залиште незаданим, щоб використовувати стандартне значення пристрою.
- `silenceTimeoutMs` керує тим, як довго режим Talk чекає після мовчання користувача, перш ніж надіслати транскрипт. Незадане значення зберігає стандартне вікно паузи платформи (`700 ms on macOS and Android, 900 ms on iOS`).
+- `providers.*.voiceAliases` дає директивам Talk змогу використовувати зручні імена.
+- `providers.mlx.modelId` вибирає репозиторій Hugging Face, який використовує локальний помічник MLX для macOS. Якщо не вказано, macOS використовує `mlx-community/Soprano-80M-bf16`.
+- Відтворення macOS MLX виконується через вбудований помічник `openclaw-mlx-tts`, коли він наявний, або через виконуваний файл у `PATH`; `OPENCLAW_MLX_TTS_BIN` перевизначає шлях до помічника для розробки.
+- `speechLocale` задає ідентифікатор локалі BCP 47, який використовується розпізнаванням мовлення Talk в iOS/macOS. Залиште незаданим, щоб використовувати типове значення пристрою.
+- `silenceTimeoutMs` керує тим, як довго режим Talk чекає після тиші користувача, перш ніж надсилати транскрипт. Незадане значення зберігає типове вікно паузи платформи (`700 ms on macOS and Android, 900 ms on iOS`).

 ---

--- a/docs/uk/gateway/local-models.md
+++ b/docs/uk/gateway/local-models.md
@ -1,30 +1,30 @@
 ---
 read_when:
-    - Ви хочете обслуговувати моделі з власної GPU-машини
-    - Ви підключаєте LM Studio або OpenAI-сумісний проксі
-    - Вам потрібні рекомендації щодо найбезпечнішої локальної моделі
-summary: Запускайте OpenClaw на локальних LLM-моделях (LM Studio, vLLM, LiteLLM, користувацькі кінцеві точки OpenAI)
+    - Ви хочете обслуговувати моделі зі свого власного GPU-сервера
+    - Ви налаштовуєте LM Studio або проксі, сумісний з OpenAI
+    - Вам потрібні найбезпечніші рекомендації щодо локальної моделі
+summary: Запускайте OpenClaw на локальних LLM (LM Studio, vLLM, LiteLLM, власні кінцеві точки OpenAI)
 title: Локальні моделі
 x-i18n:
-    generated_at: "2026-04-28T11:12:47Z"
+    generated_at: "2026-04-29T10:40:32Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 4be447ece49ec1b41456db54a223679f4e399b8e9231925fd08d12999af246c9
+    source_hash: 2ec1be4eac371328c1efe80b71450019f68fb1114df90db1532a4ff72bfa0ab1
    source_path: gateway/local-models.md
    workflow: 16
 ---

-Локально це можливо, але OpenClaw очікує великий контекст + сильний захист від prompt injection. Малі карти обрізають контекст і погіршують безпеку. Цільтеся високо: **≥2 максимально укомплектовані Mac Studio або еквівалентна GPU-система (~$30k+)**. Один GPU на **24 GB** працює лише для легших промптів із вищою затримкою. Використовуйте **найбільший / повнорозмірний варіант моделі, який можете запустити**; агресивно квантизовані або “малі” контрольні точки підвищують ризик prompt-injection (див. [Безпека](/uk/gateway/security)).
+Локально можливо, але OpenClaw очікує великий контекст і сильний захист від prompt injection. Малі карти обрізають контекст і погіршують безпеку. Орієнтуйтеся високо: **≥2 максимально укомплектовані Mac Studios або еквівалентна GPU-система (~$30k+)**. Один GPU на **24 GB** працює лише для легших промптів із більшою затримкою. Використовуйте **найбільший / повнорозмірний варіант моделі, який можете запустити**; агресивно квантизовані або “малі” checkpoints підвищують ризик prompt injection (див. [Безпека](/uk/gateway/security)).

-Якщо вам потрібне локальне налаштування з мінімальним тертям, почніть із [LM Studio](/uk/providers/lmstudio) або [Ollama](/uk/providers/ollama) і `openclaw onboard`. Ця сторінка — рекомендаційний посібник для продуктивніших локальних стеків і кастомних локальних серверів, сумісних з OpenAI.
+Якщо вам потрібне локальне налаштування з найменшим тертям, почніть із [LM Studio](/uk/providers/lmstudio) або [Ollama](/uk/providers/ollama) і `openclaw onboard`. Ця сторінка — практичний посібник для потужніших локальних стеків і власних локальних серверів, сумісних з OpenAI.

 <Warning>
-**Користувачі WSL2 + Ollama + NVIDIA/CUDA:** Офіційний інсталятор Ollama для Linux вмикає службу systemd з `Restart=always`. У GPU-налаштуваннях WSL2 автозапуск може повторно завантажити останню модель під час завантаження системи й закріпити пам’ять хоста. Якщо ваша WSL2 VM неодноразово перезапускається після ввімкнення Ollama, див. [цикл аварійного перезапуску WSL2](/uk/providers/ollama#wsl2-crash-loop-repeated-reboots).
+**Користувачі WSL2 + Ollama + NVIDIA/CUDA:** офіційний інсталятор Ollama для Linux вмикає systemd-сервіс із `Restart=always`. У GPU-налаштуваннях WSL2 автозапуск може перезавантажити останню модель під час запуску системи й закріпити пам’ять хоста. Якщо ваша WSL2 VM багаторазово перезапускається після ввімкнення Ollama, див. [цикл аварійного перезапуску WSL2](/uk/providers/ollama#wsl2-crash-loop-repeated-reboots).
 </Warning>

 ## Рекомендовано: LM Studio + велика локальна модель (Responses API)

-Найкращий поточний локальний стек. Завантажте велику модель у LM Studio (наприклад, повнорозмірну збірку Qwen, DeepSeek або Llama), увімкніть локальний сервер (типово `http://127.0.0.1:1234`) і використовуйте Responses API, щоб відокремити reasoning від фінального тексту.
+Найкращий поточний локальний стек. Завантажте велику модель у LM Studio (наприклад, повнорозмірну збірку Qwen, DeepSeek або Llama), увімкніть локальний сервер (типово `http://127.0.0.1:1234`) і використовуйте Responses API, щоб тримати міркування окремо від фінального тексту.

 ```json5
 {
@ -64,15 +64,15 @@ x-i18n:
 **Контрольний список налаштування**

 - Установіть LM Studio: [https://lmstudio.ai](https://lmstudio.ai)
- У LM Studio завантажте **найбільшу доступну збірку моделі** (уникайте “малих”/сильно квантизованих варіантів), запустіть сервер, підтвердьте, що `http://127.0.0.1:1234/v1/models` показує її у списку.
- Замініть `my-local-model` на фактичний ID моделі, показаний у LM Studio.
- Тримайте модель завантаженою; холодне завантаження додає затримку під час запуску.
+- У LM Studio завантажте **найбільшу доступну збірку моделі** (уникайте “малих”/сильно квантизованих варіантів), запустіть сервер, підтвердьте, що `http://127.0.0.1:1234/v1/models` її показує.
+- Замініть `my-local-model` фактичним ID моделі, показаним у LM Studio.
+- Тримайте модель завантаженою; холодне завантаження додає затримку старту.
 - Налаштуйте `contextWindow`/`maxTokens`, якщо ваша збірка LM Studio відрізняється.
 - Для WhatsApp дотримуйтеся Responses API, щоб надсилався лише фінальний текст.

-Залишайте розміщені моделі налаштованими навіть під час локального запуску; використовуйте `models.mode: "merge"`, щоб fallback-и залишалися доступними.
+Тримайте розміщені моделі налаштованими навіть під час локального запуску; використовуйте `models.mode: "merge"`, щоб резервні варіанти лишалися доступними.

-### Гібридна конфігурація: розміщена основна модель, локальний fallback
+### Гібридна конфігурація: розміщена основна, локальна резервна

 ```json5
 {
@ -113,22 +113,21 @@ x-i18n:
 }
 ```

-### Локальна модель першою з розміщеною захисною сіткою
+### Насамперед локально, з розміщеною захисною сіткою

-Поміняйте місцями порядок primary і fallback; залиште той самий блок providers і `models.mode: "merge"`, щоб можна було відкотитися до Sonnet або Opus, коли локальна машина недоступна.
+Поміняйте порядок основної та резервної моделей; залиште той самий блок providers і `models.mode: "merge"`, щоб можна було перейти на Sonnet або Opus, коли локальна машина недоступна.

 ### Регіональне розміщення / маршрутизація даних

- Розміщені варіанти MiniMax/Kimi/GLM також існують в OpenRouter з прив’язаними до регіону endpoint-ами (наприклад, розміщені у США). Виберіть там регіональний варіант, щоб тримати трафік у вибраній юрисдикції, водночас використовуючи `models.mode: "merge"` для fallback-ів Anthropic/OpenAI.
- Лише локальний режим залишається найсильнішим шляхом для приватності; розміщена регіональна маршрутизація — це компроміс, коли потрібні функції провайдера, але потрібен контроль над потоком даних.
+- Розміщені варіанти MiniMax/Kimi/GLM також існують на OpenRouter з прив’язаними до регіону endpoint-ами (наприклад, розміщеними в США). Виберіть там регіональний варіант, щоб утримувати трафік у вибраній юрисдикції, водночас використовуючи `models.mode: "merge"` для резервних варіантів Anthropic/OpenAI.
+- Варіант лише локально лишається найсильнішим шляхом для приватності; розміщена регіональна маршрутизація — це компроміс, коли потрібні можливості провайдера, але ви хочете контролювати потік даних.

 ## Інші локальні проксі, сумісні з OpenAI

-MLX (`mlx_lm.server`), vLLM, SGLang, LiteLLM, OAI-proxy або кастомні
-Gateway-и працюють, якщо вони надають endpoint у стилі OpenAI `/v1/chat/completions`.
+MLX (`mlx_lm.server`), vLLM, SGLang, LiteLLM, OAI-proxy або власні
+gateways працюють, якщо вони надають endpoint OpenAI-стилю `/v1/chat/completions`.
 Використовуйте адаптер Chat Completions, якщо бекенд явно не документує
-підтримку `/v1/responses`. Замініть наведений вище блок provider на ваш
-endpoint і ID моделі:
+підтримку `/v1/responses`. Замініть блок provider вище на ваш endpoint і ID моделі:

 ```json5
 {
@ -162,67 +161,67 @@ endpoint і ID моделі:
 }
 ```

-Якщо `api` пропущено для кастомного provider з `baseUrl`, OpenClaw типово використовує
+Якщо `api` пропущено у власному provider з `baseUrl`, OpenClaw типово використовує
 `openai-completions`. Loopback endpoint-и, як-от `127.0.0.1`, автоматично
-вважаються довіреними; endpoint-и LAN, tailnet і приватного DNS все одно потребують
+вважаються довіреними; endpoint-и LAN, tailnet і приватного DNS усе ще потребують
 `request.allowPrivateNetwork: true`.

-Значення `models.providers.<id>.models[].id` є локальним для provider-а. Не
-включайте туди префікс provider-а. Наприклад, сервер MLX, запущений з
-`mlx_lm.server --model mlx-community/Qwen3-30B-A3B-6bit`, має використовувати такий
-ID каталогу й посилання на модель:
+Значення `models.providers.<id>.models[].id` є локальним для provider. Не
+додавайте туди префікс provider. Наприклад, сервер MLX, запущений із
+`mlx_lm.server --model mlx-community/Qwen3-30B-A3B-6bit`, має використовувати
+такий catalog id і model ref:

 - `models.providers.mlx.models[].id: "mlx-community/Qwen3-30B-A3B-6bit"`
 - `agents.defaults.model.primary: "mlx/mlx-community/Qwen3-30B-A3B-6bit"`

-Встановіть `input: ["text", "image"]` для локальних або проксійованих vision-моделей, щоб
-вкладення зображень додавалися в ходи агента. Інтерактивний onboarding кастомного provider-а
-виводить поширені ID vision-моделей і запитує лише невідомі назви.
-Неінтерактивний onboarding використовує той самий висновок; використовуйте `--custom-image-input`
+Установіть `input: ["text", "image"]` для локальних або проксійованих vision-моделей, щоб
+зображення-вкладення додавалися в ходи агента. Інтерактивне onboarding власного provider
+визначає поширені ID vision-моделей і питає лише про невідомі назви.
+Неінтерактивне onboarding використовує те саме визначення; використовуйте `--custom-image-input`
 для невідомих vision ID або `--custom-text-input`, коли модель із назвою, схожою на відому,
-є text-only за вашим endpoint-ом.
+є text-only за вашим endpoint.

-Залишайте `models.mode: "merge"`, щоб розміщені моделі залишалися доступними як fallback-и.
+Тримайте `models.mode: "merge"`, щоб розміщені моделі лишалися доступними як резервні.
 Використовуйте `models.providers.<id>.timeoutSeconds` для повільних локальних або віддалених
-серверів моделей перед підвищенням `agents.defaults.timeoutSeconds`. Таймаут provider-а
-застосовується лише до HTTP-запитів моделі, включно з підключенням, заголовками, потоковою передачею тіла
-та загальним перериванням guarded-fetch.
+серверів моделей перед підвищенням `agents.defaults.timeoutSeconds`. Тайм-аут provider
+застосовується лише до HTTP-запитів моделі, включно з підключенням, headers, body streaming
+і загальним guarded-fetch abort.

 <Note>
-Для кастомних provider-ів, сумісних з OpenAI, збереження несекретного локального маркера, як-от `apiKey: "ollama-local"`, приймається, коли `baseUrl` розв’язується в loopback, приватну LAN, `.local` або просте ім’я хоста. OpenClaw розглядає його як дійсний локальний credential замість повідомлення про відсутній ключ. Використовуйте реальне значення для будь-якого provider-а, який приймає публічне ім’я хоста.
+Для власних provider, сумісних з OpenAI, збереження несекретного локального маркера, як-от `apiKey: "ollama-local"`, приймається, коли `baseUrl` вказує на loopback, приватну LAN, `.local` або bare hostname. OpenClaw обробляє його як валідні локальні облікові дані, а не повідомляє про відсутній ключ. Використовуйте справжнє значення для будь-якого provider, який приймає публічний hostname.
 </Note>

-Примітка щодо поведінки локальних/проксійованих бекендів `/v1`:
+Примітка щодо поведінки для локальних/проксійованих `/v1` бекендів:

- OpenClaw розглядає їх як proxy-style маршрути, сумісні з OpenAI, а не як нативні
+- OpenClaw обробляє їх як proxy-style маршрути, сумісні з OpenAI, а не як нативні
  endpoint-и OpenAI
- нативне OpenAI-only формування запитів тут не застосовується: без
-  `service_tier`, без Responses `store`, без формування payload для сумісності з OpenAI reasoning
+- нативне лише для OpenAI формування запитів тут не застосовується: без
+  `service_tier`, без Responses `store`, без формування payload для OpenAI reasoning-compat
  і без підказок prompt-cache
- приховані заголовки атрибуції OpenClaw (`originator`, `version`, `User-Agent`)
-  не додаються до цих кастомних proxy URL
+- приховані attribution headers OpenClaw (`originator`, `version`, `User-Agent`)
+  не додаються до цих власних proxy URL

 Примітки щодо сумісності для суворіших бекендів, сумісних з OpenAI:

- Деякі сервери приймають лише рядковий `messages[].content` у Chat Completions, а не
-  структуровані масиви content-part. Встановіть
+- Деякі сервери приймають у Chat Completions лише рядковий `messages[].content`, а не
+  структуровані масиви content-part. Установіть
  `models.providers.<provider>.models[].compat.requiresStringContent: true` для
  таких endpoint-ів.
- Деякі локальні моделі видають окремі bracketed tool requests як текст, наприклад
+- Деякі локальні моделі виводять окремі інструментальні запити в квадратних дужках як текст, наприклад
  `[tool_name]`, за яким іде JSON і `[END_TOOL_REQUEST]`. OpenClaw перетворює
-  їх на реальні tool calls лише тоді, коли назва точно збігається із зареєстрованим
-  інструментом для цього ходу; інакше блок розглядається як непідтримуваний текст і
-  приховується з відповідей, видимих користувачу.
- Якщо модель видає JSON, XML або текст у стилі ReAct, який виглядає як tool call,
-  але provider не видав структурований invocation, OpenClaw залишає це як
+  їх на справжні виклики інструментів лише коли назва точно збігається із зареєстрованим
+  інструментом для цього ходу; інакше блок обробляється як непідтримуваний текст і
+  приховується з видимих для користувача відповідей.
+- Якщо модель виводить JSON, XML або ReAct-style текст, схожий на виклик інструмента,
+  але provider не видав структурований виклик, OpenClaw залишає це як
  текст і записує попередження з run id, provider/model, виявленим шаблоном і
-  назвою інструмента, якщо вона доступна. Розглядайте це як несумісність tool-call
-  у provider/model, а не як завершений запуск інструмента.
- Якщо інструменти з’являються як текст assistant замість виконання, наприклад raw JSON,
-  XML, синтаксис ReAct або порожній масив `tool_calls` у відповіді provider-а,
+  назвою інструмента, коли вона доступна. Вважайте це несумісністю tool-call
+  provider/model, а не завершеним запуском інструмента.
+- Якщо інструменти з’являються як текст асистента замість виконання, наприклад сирий JSON,
+  XML, ReAct syntax або порожній масив `tool_calls` у відповіді provider,
  спершу перевірте, що сервер використовує chat template/parser із підтримкою tool-call. Для
-  OpenAI-compatible бекендів Chat Completions, parser яких працює лише коли використання інструментів
-  примусове, встановіть per-model request override замість покладання на text
+  OpenAI-compatible Chat Completions бекендів, parser яких працює лише коли використання інструментів
+  примусове, задайте per-model request override замість покладання на текстовий
  parsing:

  ```json5
@ -245,71 +244,105 @@ ID каталогу й посилання на модель:

  Використовуйте це лише для моделей/сесій, де кожен звичайний хід має викликати інструмент.
  Це перевизначає типове proxy-значення OpenClaw `tool_choice: "auto"`.
-  Замініть `local/my-local-model` на точне посилання provider/model, показане
+  Замініть `local/my-local-model` точним provider/model ref, показаним
  `openclaw models list`.

  ```bash
  openclaw config set agents.defaults.models '{"local/my-local-model":{"params":{"extra_body":{"tool_choice":"required"}}}}' --strict-json --merge
  ```

+- Якщо власна модель, сумісна з OpenAI, приймає OpenAI reasoning efforts поза
+  вбудованим профілем, оголосіть їх у model compat block. Додавання `"xhigh"`
+  тут робить рівень доступним для `/think xhigh`, session pickers, валідації Gateway і валідації `llm-task`
+  для налаштованого provider/model ref:
+
+  ```json5
+  {
+    models: {
+      providers: {
+        local: {
+          baseUrl: "http://127.0.0.1:8000/v1",
+          apiKey: "sk-local",
+          api: "openai-responses",
+          models: [
+            {
+              id: "gpt-5.4",
+              name: "GPT 5.4 via local proxy",
+              reasoning: true,
+              input: ["text"],
+              cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
+              contextWindow: 196608,
+              maxTokens: 8192,
+              compat: {
+                supportedReasoningEfforts: ["low", "medium", "high", "xhigh"],
+                reasoningEffortMap: { xhigh: "xhigh" },
+              },
+            },
+          ],
+        },
+      },
+    },
+  }
+  ```
+
 - Деякі менші або суворіші локальні бекенди нестабільні з повною
-  формою agent-runtime prompt OpenClaw, особливо коли включено схеми інструментів. Спершу
-  перевірте шлях provider-а за допомогою lean local probe:
+  формою промпта agent-runtime OpenClaw, особливо коли включено схеми інструментів. Спершу
+  перевірте шлях provider за допомогою легкого локального probe:

  ```bash
  openclaw infer model run --local --model <provider/model> --prompt "Reply with exactly: pong" --json
  ```

-  Щоб перевірити маршрут Gateway без повної форми agent prompt, використовуйте
+  Щоб перевірити маршрут Gateway без повної форми промпта агента, використовуйте
  натомість Gateway model probe:

  ```bash
  openclaw infer model run --gateway --model <provider/model> --prompt "Reply with exactly: pong" --json
  ```

-  І локальний, і Gateway model probes надсилають лише наданий prompt. Gateway
-  probe все одно перевіряє маршрутизацію Gateway, автентифікацію та вибір provider-а,
-  але навмисно пропускає попередній transcript сесії, AGENTS/bootstrap context,
+  І локальний, і Gateway model probes надсилають лише наданий промпт. Gateway
+  probe усе ще перевіряє маршрутизацію Gateway, auth і вибір provider,
+  але навмисно пропускає попередній transcript сесії, контекст AGENTS/bootstrap,
  складання context-engine, інструменти та bundled MCP servers.

-  Якщо це успішно, але звичайні ходи агента OpenClaw не вдаються, спершу спробуйте
+  Якщо це спрацьовує, але звичайні ходи агента OpenClaw завершуються помилкою, спершу спробуйте
  `agents.defaults.experimental.localModelLean: true`, щоб прибрати важкі
-  стандартні інструменти, як-от `browser`, `cron` і `message`; це експериментальний
-  прапорець, а не стабільне налаштування default-mode. Див.
-  [Експериментальні функції](/uk/concepts/experimental-features). Якщо це все ще не працює, спробуйте
+  типові інструменти, як-от `browser`, `cron` і `message`; це експериментальний
+  прапорець, а не стабільне налаштування типового режиму. Див.
+  [Експериментальні функції](/uk/concepts/experimental-features). Якщо це все одно не допомагає, спробуйте
  `models.providers.<provider>.models[].compat.supportsTools: false`.

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

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

 - Gateway може дістатися до проксі? `curl http://127.0.0.1:1234/v1/models`.
- Модель LM Studio вивантажено? Перезавантажте; холодний старт є поширеною причиною «зависання».
+- Модель LM Studio вивантажено? Перезавантажте її; холодний старт є поширеною причиною “зависання”.
 - Локальний сервер повідомляє `terminated`, `ECONNRESET` або закриває потік посеред ходу?
  OpenClaw записує низькокардинальний `model.call.error.failureKind` плюс знімок
-  RSS/heap процесу OpenClaw у діагностиці. Для тиску на пам’ять LM Studio/Ollama
-  зіставте цю часову позначку з журналом сервера або журналом аварій macOS /
-  jetsam, щоб підтвердити, чи було завершено сервер моделі.
+  RSS/heap процесу OpenClaw у діагностиці. Для браку памʼяті в LM Studio/Ollama
+  зіставте цю часову мітку з журналом сервера або журналом аварій macOS /
+  jetsam, щоб підтвердити, чи було сервер моделі завершено примусово.
 - OpenClaw попереджає, коли виявлене контекстне вікно менше за **32k**, і блокує роботу нижче **16k**. Якщо ви натрапили на цю попередню перевірку, збільште ліміт контексту сервера/моделі або виберіть більшу модель.
 - Помилки контексту? Зменште `contextWindow` або збільште ліміт сервера.
 - OpenAI-сумісний сервер повертає `messages[].content ... expected a string`?
-  Додайте `compat.requiresStringContent: true` до цього запису моделі.
+  Додайте `compat.requiresStringContent: true` до запису цієї моделі.
 - Прямі крихітні виклики `/v1/chat/completions` працюють, але `openclaw infer model run --local`
-  не вдається на Gemma або іншій локальній моделі? Спершу перевірте URL провайдера, посилання на модель, маркер автентифікації
+  дає збій на Gemma або іншій локальній моделі? Спершу перевірте URL постачальника, посилання на модель, маркер автентифікації
  та журнали сервера; локальний `model run` не включає інструменти агента.
-  Якщо локальний `model run` успішний, але більші ходи агента не вдаються, зменште
+  Якщо локальний `model run` спрацьовує, але більші ходи агента дають збій, зменште
  поверхню інструментів агента за допомогою `localModelLean` або `compat.supportsTools: false`.
- Виклики інструментів відображаються як сирий JSON/XML/ReAct-текст, або провайдер повертає
+- Виклики інструментів відображаються як сирий текст JSON/XML/ReAct або постачальник повертає
  порожній масив `tool_calls`? Не додавайте проксі, який сліпо перетворює текст
-  асистента на виконання інструментів. Спершу виправте chat-шаблон/парсер сервера. Якщо
-  модель працює лише тоді, коли використання інструментів примусове, додайте наведене вище
-  перевизначення для окремої моделі `params.extra_body.tool_choice: "required"` і використовуйте цей запис моделі
+  асистента на виконання інструментів. Спершу виправте шаблон чату/парсер сервера. Якщо
+  модель працює лише коли використання інструментів примусове, додайте наведене вище помодельне
+  перевизначення `params.extra_body.tool_choice: "required"` і використовуйте цей запис моделі
  лише для сеансів, де виклик інструмента очікується на кожному ході.
- Безпека: локальні моделі оминають фільтри на боці провайдера; тримайте агентів вузькими, а compaction увімкненою, щоб обмежити радіус ураження prompt injection.
+- Безпека: локальні моделі пропускають фільтри на боці постачальника; тримайте агентів вузько сфокусованими й увімкніть Compaction, щоб обмежити радіус ураження prompt injection.

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

 - [Довідник із конфігурації](/uk/gateway/configuration-reference)
- [Перемикання моделей у разі збою](/uk/concepts/model-failover)
+- [Відмовостійке перемикання моделей](/uk/concepts/model-failover)
--- a/docs/uk/reference/RELEASING.md
+++ b/docs/uk/reference/RELEASING.md
@ -1,242 +1,163 @@
 ---
 read_when:
-    - Пошук визначень публічних каналів випуску
-    - Запуск перевірки випуску або приймального тестування пакета
-    - Шукаєте найменування версій і періодичність випусків
-summary: Канали випуску, контрольний список оператора, валідаційні бокси, іменування версій і періодичність
+    - Пошук визначень загальнодоступних каналів випуску
+    - Запуск перевірки релізу або приймального тестування пакета
+    - Пошук правил іменування версій і періодичності випусків
+summary: Релізні лінії, контрольний список оператора, бокси валідації, іменування версій і каденція
 title: Політика випусків
 x-i18n:
-    generated_at: "2026-04-29T07:27:34Z"
+    generated_at: "2026-04-29T10:40:36Z"
    model: gpt-5.5
    provider: openai
-    source_hash: 84c8dcd13f247b5d136d8a675ce53ef12c68a7f7242d485fe4b55570105ef180
+    source_hash: 815c4bffe7930384584533e934996592114af510ebd775fc873086d63c74203f
    source_path: reference/RELEASING.md
    workflow: 16
 ---

-OpenClaw має три публічні канали випусків:
+OpenClaw має три публічні гілки релізів:

- stable: випуски з тегами, які за замовчуванням публікуються в npm під `beta`, або в npm під `latest`, коли це явно запитано
- beta: prerelease-теги, які публікуються в npm під `beta`
+- stable: позначені тегами релізи, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано
+- beta: передрелізні теги, які публікуються в npm `beta`
 - dev: рухома вершина `main`

-## Іменування версій
+## Назви версій

- Версія stable-випуску: `YYYY.M.D`
+- Версія стабільного релізу: `YYYY.M.D`
  - Git-тег: `vYYYY.M.D`
- Версія коригувального stable-випуску: `YYYY.M.D-N`
+- Версія коригувального стабільного релізу: `YYYY.M.D-N`
  - Git-тег: `vYYYY.M.D-N`
- Версія beta-prerelease: `YYYY.M.D-beta.N`
+- Версія beta-передрелізу: `YYYY.M.D-beta.N`
  - Git-тег: `vYYYY.M.D-beta.N`
- Не додавайте нуль на початку місяця чи дня
- `latest` означає поточний просунутий stable-випуск npm
+- Не додавайте початкові нулі до місяця чи дня
+- `latest` означає поточний просунутий стабільний npm-реліз
 - `beta` означає поточну ціль встановлення beta
- Stable і коригувальні stable-випуски за замовчуванням публікуються в npm під `beta`; оператори випуску можуть явно вибрати `latest` або пізніше просунути перевірену beta-збірку
- Кожен stable-випуск OpenClaw постачається разом із npm-пакетом і застосунком macOS;
-  beta-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а
-  збірка/підпис/нотаризація застосунку macOS зарезервовані для stable, якщо їх явно не запитано
+- Стабільні та коригувальні стабільні релізи за замовчуванням публікуються в npm `beta`; оператори релізу можуть явно націлитися на `latest` або пізніше просунути перевірену beta-збірку
+- Кожен стабільний реліз OpenClaw постачається разом із npm-пакетом і застосунком macOS;
+  beta-релізи зазвичай спершу перевіряють і публікують шлях npm/пакета, а
+  збирання/підписування/нотаризація Mac-застосунку лишаються для стабільних релізів, якщо їх явно не запитано

-## Ритм випусків
+## Частота релізів

- Випуски рухаються спочатку через beta
- Stable іде лише після перевірки найновішої beta
- Maintainers зазвичай готують випуски з гілки `release/YYYY.M.D`, створеної
-  з поточного `main`, щоб перевірка випуску й виправлення не блокували нову
+- Релізи рухаються спочатку через beta
+- Стабільний реліз виходить лише після перевірки останньої beta
+- Мейнтейнери зазвичай створюють релізи з гілки `release/YYYY.M.D`, створеної
+  з поточного `main`, щоб перевірка релізу та виправлення не блокували нову
  розробку в `main`
- Якщо beta-тег уже надіслано або опубліковано й він потребує виправлення, maintainers створюють
-  наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега
- Детальна процедура випуску, погодження, облікові дані й нотатки щодо відновлення
-  доступні лише maintainers
+- Якщо beta-тег уже надіслано або опубліковано й він потребує виправлення, мейнтейнери створюють
+  наступний тег `-beta.N` замість видалення чи повторного створення старого beta-тега
+- Докладна процедура релізу, схвалення, облікові дані та нотатки з відновлення
+  доступні лише мейнтейнерам

-## Контрольний список оператора випуску
+## Контрольний список оператора релізу

-Цей контрольний список описує публічну форму процесу випуску. Приватні облікові дані,
-підписування, нотаризація, відновлення dist-tag і подробиці аварійного відкату залишаються в
-runbook випуску, доступному лише maintainers.
+Цей контрольний список є публічною формою релізного процесу. Приватні облікові дані,
+підписування, нотаризація, відновлення dist-tag і подробиці екстреного відкату лишаються в
+релізному runbook лише для мейнтейнерів.

-1. Почніть із поточного `main`: отримайте найновіші зміни, підтвердьте, що цільовий commit надіслано,
-   і підтвердьте, що поточний CI `main` достатньо зелений, щоб створити від нього гілку.
-2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії commit за допомогою
-   `/changelog`, залиште записи орієнтованими на користувача, створіть commit, надішліть його й виконайте rebase/pull
+1. Почніть із поточного `main`: підтягніть останні зміни, підтвердьте, що цільовий коміт надіслано,
+   і підтвердьте, що поточний CI `main` достатньо зелений, щоб створити з нього гілку.
+2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою
+   `/changelog`, залиште записи орієнтованими на користувачів, закомітьте їх, надішліть і виконайте rebase/pull
   ще раз перед створенням гілки.
-3. Перегляньте записи сумісності випуску в
+3. Перегляньте записи сумісності релізу в
   `src/plugins/compat/registry.ts` і
   `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену
   сумісність лише тоді, коли шлях оновлення лишається покритим, або зафіксуйте, чому її
   навмисно збережено.
-4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском
+4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну релізну роботу
   безпосередньо в `main`.
-5. Оновіть кожне потрібне місце версії для запланованого тегу, потім запустіть
-   локальний детермінований preflight:
+5. Оновіть кожне потрібне місце з версією для запланованого тега, потім запустіть
+   локальну детерміновану попередню перевірку:
   `pnpm check:test-types`, `pnpm check:architecture`,
   `pnpm build && pnpm ui:build` і `pnpm release:check`.
-6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. Поки тегу немає,
-   повний 40-символьний SHA гілки випуску дозволено для preflight лише з метою перевірки.
+6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тега
+   повний 40-символьний SHA релізної гілки дозволений для попередньої перевірки лише з метою валідації.
   Збережіть успішний `preflight_run_id`.
-7. Запустіть усі pre-release тести через `Full Release Validation` для
-   гілки випуску, тегу або повного SHA commit. Це єдина ручна точка входу
-   для чотирьох великих тестових боксів випуску: Vitest, Docker, QA Lab і Package.
-8. Якщо перевірка не пройшла, виправте проблему в гілці випуску й перезапустіть найменший невдалий
-   файл, lane, workflow job, профіль пакета, provider або model allowlist, який
-   доводить виправлення. Перезапускайте повну парасольку лише тоді, коли змінена поверхня робить
+7. Запустіть усі передрелізні тести через `Full Release Validation` для
+   релізної гілки, тега або повного SHA коміту. Це єдина ручна точка входу
+   для чотирьох великих релізних тестових середовищ: Vitest, Docker, QA Lab і Package.
+8. Якщо перевірка не пройшла, виправте в релізній гілці й повторно запустіть найменший невдалий
+   файл, гілку, завдання workflow, профіль пакета, провайдера або allowlist моделей, що
+   доводить виправлення. Повторно запускайте повну umbrella-перевірку лише тоді, коли змінена поверхня робить
   попередні докази застарілими.
-9. Для beta створіть тег `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, потім запустіть
+9. Для beta позначте тегом `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, потім запустіть
   post-publish package acceptance проти опублікованого пакета `openclaw@YYYY.M.D-beta.N`
   або `openclaw@beta`. Якщо надіслана або опублікована beta потребує виправлення, створіть
   наступний `-beta.N`; не видаляйте й не переписуйте стару beta.
-10. Для stable продовжуйте лише після того, як перевірена beta або release candidate має
-    потрібні докази перевірки. Stable-публікація npm повторно використовує успішний
-    preflight-артефакт через `preflight_run_id`; готовність stable-випуску macOS
-    також вимагає упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого
+10. Для стабільного релізу продовжуйте лише після того, як перевірена beta або release candidate має
+    потрібні докази перевірки. Стабільна npm-публікація повторно використовує успішний
+    артефакт попередньої перевірки через `preflight_run_id`; готовність стабільного релізу macOS
+    також потребує запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого
    `appcast.xml` у `main`.
 11. Після публікації запустіть npm post-publish verifier, необов’язковий автономний
    published-npm Telegram E2E, коли потрібен post-publish доказ каналу,
    просування dist-tag за потреби, нотатки GitHub release/prerelease з
-    повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску.
+    повного відповідного розділу `CHANGELOG.md` і кроки оголошення релізу.

-## Preflight випуску
+## Попередня перевірка релізу

- Виконайте `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався
-  покритим поза швидшим локальним шлюзом `pnpm check`
- Виконайте `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів
-  імпортів і меж архітектури були зеленими поза швидшим локальним шлюзом
- Виконайте `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані
-  релізні артефакти `dist/*` і бандл Control UI існували для кроку перевірки
-  пакування
- Виконайте ручний workflow `Full Release Validation` перед схваленням релізу, щоб
-  запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку,
-  тег або повний SHA коміту, запускає ручний `CI` і запускає
-  `OpenClaw Release Checks` для install smoke, package acceptance, Docker
-  release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram
-  lanes. Надавайте `npm_telegram_package_spec` лише після публікації пакета,
-  коли також має запуститися післяпублікаційний Telegram E2E. Надавайте
-  `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що
-  валідація відповідає опублікованому npm-пакету без примусового Telegram E2E.
-  Приклад:
+- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався покритим поза швидшим локальним шлюзом `pnpm check`
+- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів імпортів і архітектурних меж були зеленими поза швидшим локальним шлюзом
+- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані релізні артефакти `dist/*` і бандл Control UI існували для кроку валідації пакування
+- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб запустити всі передрелізні test boxes з однієї точки входу. Він приймає гілку, тег або повний SHA коміту, запускає ручний `CI` і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів release-path для Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram lanes. Надавайте `npm_telegram_package_spec` лише після публікації пакета, коли також потрібно виконати post-publish Telegram E2E. Надавайте `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що валідація відповідає опублікованому npm-пакету, не примушуючи запускати Telegram E2E. Приклад:
  `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D`
- Виконайте ручний workflow `Package Acceptance`, коли потрібен побічний доказ
-  для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для
-  `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`,
-  щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним harness
-  `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим SHA-256; або
-  `source=artifact` для tarball, завантаженого іншим запуском GitHub Actions.
-  Workflow резолвить кандидата в `package-under-test`, повторно використовує
-  Docker E2E release scheduler проти цього tarball і може запускати Telegram QA
-  проти того самого tarball з `telegram_mode=mock-openai` або
-  `telegram_mode=live-frontier`.
+- Запустіть ручний workflow `Package Acceptance`, коли потрібен доказ із побічного каналу для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`, щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub Actions. Workflow визначає кандидата як `package-under-test`, повторно використовує планувальник Docker E2E релізу для цього tarball і може запускати Telegram QA для того самого tarball з `telegram_mode=mock-openai` або `telegram_mode=live-frontier`.
  Приклад: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f telegram_mode=mock-openai`
-  Типові профілі:
-  - `smoke`: install/channel/agent, gateway network і config reload lanes
-  - `package`: artifact-native package/update/plugin lanes без OpenWebUI або live ClawHub
-  - `product`: профіль package плюс MCP channels, cron/subagent cleanup,
-    OpenAI web search і OpenWebUI
-  - `full`: Docker release-path chunks з OpenWebUI
+  Поширені профілі:
+  - `smoke`: lanes встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації
+  - `package`: lanes пакета/оновлення/Plugin, нативні для артефакта, без OpenWebUI або live ClawHub
+  - `product`: профіль package плюс MCP-канали, очищення cron/subagent, вебпошук OpenAI і OpenWebUI
+  - `full`: фрагменти Docker release-path з OpenWebUI
  - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску
- Виконайте ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI
-  покриття для релізного кандидата. Ручні CI dispatch обходять changed
-  scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel
-  contracts, сумісність Node 22, `check`, `check-additional`, build smoke,
-  перевірки docs, Python skills, Windows, macOS, Android і Control UI i18n
-  lanes.
+- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI для кандидата релізу. Ручні запуски CI обходять changed scoping і примусово вмикають Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python skills, Windows, macOS, Android і lanes Control UI i18n.
  Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D`
- Виконайте `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Це
-  проганяє QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані
-  назви trace span, обмежені атрибути та редагування вмісту/ідентифікаторів без
-  потреби в Opik, Langfuse або іншому зовнішньому collector.
- Виконуйте `pnpm release:check` перед кожним релізом із тегом
- Релізні перевірки тепер виконуються в окремому ручному workflow:
+- Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Він проганяє QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace span, обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в Opik, Langfuse або іншому зовнішньому collector.
+- Запускайте `pnpm release:check` перед кожним тегованим релізом
+- Релізні перевірки тепер запускаються в окремому ручному workflow:
  `OpenClaw Release Checks`
- `OpenClaw Release Checks` також запускає QA Lab mock parity gate плюс швидкий
-  live Matrix profile і Telegram QA lane перед схваленням релізу. Live
-  lanes використовують середовище `qa-live-shared`; Telegram також використовує оренди
-  облікових даних Convex CI. Виконайте ручний workflow `QA-Lab - All Lanes` з
-  `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix
-  transport, media та E2EE паралельно.
- Cross-OS install і upgrade runtime validation є частиною публічних
-  `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають
-  reusable workflow
-  `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
- Цей поділ навмисний: тримайте реальний npm release path коротким,
-  детермінованим і зосередженим на артефактах, тоді як повільніші live checks залишаються у
-  власній lane, щоб вони не затримували й не блокували publish
- Релізні перевірки із секретами слід запускати через `Full Release
-Validation` або з workflow ref `main`/release, щоб логіка workflow і
-  секрети залишалися контрольованими
- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, доки
-  розв’язаний коміт досяжний з гілки OpenClaw або релізного тегу
- Validation-only preflight `OpenClaw NPM Release` також приймає поточний
-  повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тегу
- Цей шлях SHA призначений лише для валідації й не може бути просунутий у реальний publish
- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки
-  метаданих пакета; реальний publish усе ще вимагає справжнього релізного тегу
- Обидва workflow залишають реальний шлях publish і promotion на GitHub-hosted
-  runners, тоді як немутувальний шлях валідації може використовувати більші
-  Blacksmith Linux runners
+- `OpenClaw Release Checks` також запускає mock parity gate QA Lab плюс швидкий live Matrix profile і Telegram QA lane перед схваленням релізу. Live lanes використовують середовище `qa-live-shared`; Telegram також використовує оренди облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix transport, media та E2EE паралельно.
+- Cross-OS runtime-валідація встановлення й оновлення є частиною публічних `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають reusable workflow `.github/workflows/openclaw-cross-os-release-checks-reusable.yml`
+- Цей поділ навмисний: реальний npm release path має залишатися коротким, детермінованим і сфокусованим на артефактах, тоді як повільніші live checks залишаються у власній lane, щоб не затримувати й не блокувати публікацію
+- Релізні перевірки із секретами слід запускати через `Full Release Validation` або з workflow ref `main`/release, щоб логіка workflow і секрети залишалися контрольованими
+- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо визначений коміт досяжний з гілки OpenClaw або релізного тегу
+- validation-only preflight `OpenClaw NPM Release` також приймає поточний повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тегу
+- Цей шлях SHA призначений лише для валідації й не може бути просунутий у реальну публікацію
+- У режимі SHA workflow синтезує `v<package.json version>` лише для перевірки метаданих пакета; реальна публікація все одно потребує справжнього релізного тегу
+- Обидва workflow залишають реальний шлях публікації й просування на GitHub-hosted runners, тоді як немутаційний шлях валідації може використовувати більші Blacksmith Linux runners
 - Цей workflow запускає
  `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache`
-  використовуючи workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
+  з використанням workflow-секретів `OPENAI_API_KEY` і `ANTHROPIC_API_KEY`
 - npm release preflight більше не чекає на окрему lane релізних перевірок
- Виконайте `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
-  (або відповідний beta/correction tag) перед схваленням
- Після npm publish виконайте
+- Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts`
+  (або відповідний beta/correction тег) перед схваленням
+- Після npm publish запустіть
  `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D`
-  (або відповідну beta/correction version), щоб перевірити published registry
-  install path у свіжому тимчасовому префіксі
- Після beta publish виконайте `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`
-  щоб перевірити installed-package onboarding, налаштування Telegram і реальний Telegram E2E
-  проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних
-  Telegram. Локальні одноразові запуски maintainer можуть пропустити vars Convex і передати три
-  env credentials `OPENCLAW_QA_TELEGRAM_*` напряму.
- Maintainers можуть запускати ту саму післяпублікаційну перевірку з GitHub Actions через
-  ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і
-  не запускається під час кожного merge.
- Автоматизація релізів maintainer тепер використовує preflight-then-promote:
-  - реальний npm publish має пройти успішний npm `preflight_run_id`
-  - реальний npm publish має бути запущений з тієї самої гілки `main` або
-    `release/YYYY.M.D`, що й успішний preflight run
-  - stable npm releases за замовчуванням використовують `beta`
-  - stable npm publish може явно націлюватися на `latest` через workflow input
-  - token-based npm dist-tag mutation тепер живе в
-    `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`
-    з міркувань безпеки, бо `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як
-    публічний репозиторій зберігає OIDC-only publish
-  - публічний `macOS Release` призначений лише для валідації
-  - реальний private mac publish має пройти успішні private mac
-    `preflight_run_id` і `validate_run_id`
-  - реальні publish paths просувають підготовлені артефакти замість повторної
-    їх перебудови
- Для stable correction releases на кшталт `YYYY.M.D-N` post-publish verifier
-  також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`,
-  щоб release corrections не могли непомітно залишити старіші global installs на
-  базовому stable payload
- npm release preflight закривається з помилкою, якщо tarball не містить одночасно
-  `dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`,
-  щоб ми знову не відправили порожню браузерну панель керування
- Post-publish verification також перевіряє, що published registry install
-  містить непорожні bundled Plugin runtime deps у кореневому layout `dist/*`.
-  Реліз, який постачається з відсутніми або порожніми bundled Plugin
-  dependency payloads, провалює postpublish verifier і не може бути promoted
-  to `latest`.
- `pnpm test:install:smoke` також застосовує budget npm pack `unpackedSize` до
-  candidate update tarball, щоб installer e2e ловив випадкове розростання pack
-  до release publish path
- Якщо релізна робота торкалася CI planning, extension timing manifests або
-  extension test matrices, перегенеруйте й перегляньте planner-owned
-  `plugin-prerelease-extension-shard` matrix outputs з
-  `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не
-  описували застарілий CI layout
- Готовність stable macOS release також включає поверхні updater:
-  - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
-  - `appcast.xml` на `main` має вказувати на новий stable zip після publish
-  - запакований app має зберігати non-debug bundle id, непорожній Sparkle feed
-    URL і `CFBundleVersion` на рівні або вище canonical Sparkle build floor
-    для цієї релізної версії
+  (або відповідну beta/correction версію), щоб перевірити опублікований шлях встановлення з registry у свіжому тимчасовому префіксі
+- Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`
+  щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних Telegram. Локальні одноразові запуски мейнтейнерів можуть опускати змінні Convex і передавати три облікові дані env `OPENCLAW_QA_TELEGRAM_*` напряму.
+- Мейнтейнери можуть запустити таку саму post-publish перевірку з GitHub Actions через ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і не запускається на кожному merge.
+- Релізна автоматизація мейнтейнерів тепер використовує preflight-then-promote:
+  - реальна npm-публікація має пройти успішний npm `preflight_run_id`
+  - реальна npm-публікація має запускатися з тієї самої гілки `main` або `release/YYYY.M.D`, що й успішний preflight run
+  - стабільні npm-релізи типово використовують `beta`
+  - стабільна npm-публікація може явно цілитися в `latest` через workflow input
+  - token-based мутація npm dist-tag тепер розміщена в `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` з міркувань безпеки, оскільки `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає OIDC-only publish
+  - публічний `macOS Release` є validation-only
+  - реальна приватна mac publish має пройти успішні приватні mac `preflight_run_id` і `validate_run_id`
+  - реальні publish paths просувають підготовлені артефакти замість повторної перебудови
+- Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier також перевіряє той самий шлях оновлення temp-prefix з `YYYY.M.D` до `YYYY.M.D-N`, щоб release corrections не могли непомітно залишити старі глобальні встановлення на базовому stable payload
+- npm release preflight fails closed, якщо tarball не містить і `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`, щоб ми знову не відправили порожню браузерну dashboard
+- Post-publish verification також перевіряє, що опубліковане встановлення з registry містить непорожні runtime-залежності bundled plugin під кореневою розкладкою `dist/*`. Реліз, який постачається з відсутніми або порожніми dependency payloads bundled plugin, не проходить postpublish verifier і не може бути просунутий до `latest`.
+- `pnpm test:install:smoke` також забезпечує бюджет `unpackedSize` npm pack для candidate update tarball, щоб installer e2e виявляв випадкове роздування пакета до release publish path
+- Якщо релізна робота торкнулася планування CI, timing manifests розширень або test matrices розширень, регенеруйте й перегляньте outputs matrix `plugin-prerelease-extension-shard`, якими володіє planner, з `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не описували застарілий layout CI
+- Готовність стабільного macOS-релізу також включає поверхні updater:
+  - GitHub release має в підсумку містити запаковані `.zip`, `.dmg` і `.dSYM.zip`
+  - `appcast.xml` у `main` має вказувати на новий stable zip після publish
+  - запакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor для цієї релізної версії

-## Релізні тестові бокси
+## Релізні test boxes

-`Full Release Validation` — це спосіб, яким operators запускають усі передрелізні тести з
-однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте релізну
-гілку, тег або повний SHA коміту як `ref`:
+`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести з однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте релізну гілку, тег або повний SHA коміту як `ref`:

 ```bash
 gh workflow run full-release-validation.yml \
@ -248,37 +169,21 @@ gh workflow run full-release-validation.yml \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N
 ```

-Workflow резолвить target ref, запускає manual `CI` з
-`target_ref=<release-ref>`, запускає `OpenClaw Release Checks` і
-опційно запускає standalone post-publish Telegram E2E, коли
-`npm_telegram_package_spec` задано. Потім `OpenClaw Release Checks` розгалужується на
-install smoke, cross-OS release checks, live/E2E Docker release-path coverage,
-Package Acceptance з Telegram package QA, QA Lab parity, live Matrix і
-live Telegram. Повний запуск прийнятний лише тоді, коли summary `Full Release Validation`
-показує `normal_ci` і `release_checks` як successful, а будь-який optional
-child `npm_telegram` або successful, або навмисно skipped. Фінальний
-verifier summary містить таблиці slowest-job для кожного child run, щоб release
-manager міг бачити поточний critical path без завантаження logs.
-Child workflows запускаються з довіреного ref, який запускає `Full Release
-Validation`, зазвичай `--ref main`, навіть коли target `ref` вказує на
-старішу release branch або tag. Окремого workflow-ref input для Full Release Validation
-немає; вибирайте trusted harness, вибираючи workflow run ref.
+Workflow визначає target ref, запускає ручний `CI` з `target_ref=<release-ref>`, запускає `OpenClaw Release Checks` і за потреби запускає автономний post-publish Telegram E2E, коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release Checks` розгалужується на install smoke, cross-OS release checks, live/E2E Docker release-path coverage, Package Acceptance з Telegram package QA, паритет QA Lab, live Matrix і live Telegram. Повний запуск є прийнятним лише тоді, коли summary `Full Release Validation` показує `normal_ci` і `release_checks` як успішні, а будь-який необов’язковий child `npm_telegram` або успішний, або навмисно пропущений. Фінальна verifier summary містить таблиці найповільніших jobs для кожного child run, щоб release manager міг бачити поточний critical path без завантаження логів.
+Child workflows запускаються з довіреного ref, який виконує `Full Release Validation`, зазвичай `--ref main`, навіть коли target `ref` вказує на старішу релізну гілку або тег. Окремого workflow-ref input для Full Release Validation немає; обирайте довірений harness, обираючи workflow run ref.

 Використовуйте `release_profile`, щоб вибрати ширину live/provider:

 - `minimum`: найшвидший release-critical OpenAI/core live і Docker path
- `stable`: minimum плюс stable provider/backend coverage для схвалення релізу
- `full`: stable плюс широке advisory provider/media coverage
+- `stable`: minimum плюс стабільне покриття provider/backend для схвалення релізу
+- `full`: stable плюс широке advisory покриття provider/media

-`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз розв’язати target
-ref як `release-package-under-test` і повторно використовує цей артефакт як у
-release-path Docker checks, так і в Package Acceptance. Це утримує всі
-package-facing boxes на тих самих bytes і уникає повторних package builds.
+`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз визначити target ref як `release-package-under-test`, і повторно використовує цей артефакт як у Docker checks release-path, так і в Package Acceptance. Це утримує всі package-facing boxes на тих самих байтах і уникає повторних збірок пакета.

-Використовуйте ці варіанти залежно від стадії релізу:
+Використовуйте ці варіанти залежно від етапу релізу:

 ```bash
-# Validate an unpublished release candidate branch.
+# Валідуйте неопубліковану гілку кандидата релізу.
 gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
@ -286,14 +191,14 @@ gh workflow run full-release-validation.yml \
  -f mode=both \
  -f release_profile=stable

-# Validate an exact pushed commit.
+# Валідуйте точний запушений коміт.
 gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=<40-char-sha> \
  -f provider=openai \
  -f mode=both

-# After publishing a beta, add published-package Telegram E2E.
+# Після публікації beta додайте Telegram E2E для опублікованого пакета.
 gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
@ -304,40 +209,40 @@ gh workflow run full-release-validation.yml \
  -f npm_telegram_provider_mode=mock-openai
 ```

-Не використовуйте повну парасольку як перший повторний запуск після сфокусованого виправлення. Якщо один блок
-зазнає невдачі, використовуйте невдалий дочірній workflow, завдання, Docker-лінію, профіль пакета, модельного
-провайдера або QA-лінію для наступного підтвердження. Запускайте повну парасольку знову лише тоді, коли
-виправлення змінило спільну оркестрацію релізу або зробило попередні докази з усіх блоків
-застарілими. Фінальний перевірник парасольки повторно перевіряє записані ідентифікатори запусків дочірніх workflow,
-тому після успішного повторного запуску дочірнього workflow повторно запускайте лише невдале
+Не використовуйте повну парасольку як перший повторний запуск після сфокусованого виправлення. Якщо один бокс
+зазнає збою, використовуйте невдалий дочірній робочий процес, завдання, Docker-ланку, профіль пакета, постачальника
+моделі або QA-ланку для наступного підтвердження. Запускайте повну парасольку знову лише тоді, коли
+виправлення змінило спільну оркестрацію релізу або зробило попередні докази з усіх боксів
+застарілими. Фінальний перевіряльник парасольки повторно перевіряє записані id запусків дочірніх робочих процесів,
+тому після успішного повторного запуску дочірнього робочого процесу повторно запустіть лише невдале
 батьківське завдання `Verify full validation`.

-Для обмеженого відновлення передайте `rerun_group` у парасольку. `all` — це справжній
-запуск release candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease`
-запускає лише релізний дочірній Plugin, `release-checks` запускає кожен релізний
-блок, а вужчі релізні групи — це `install-smoke`, `cross-os`,
-`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` та `npm-telegram`, коли
-надано автономну Telegram-лінію пакета.
+Для обмеженого відновлення передайте `rerun_group` до парасольки. `all` — це справжній
+запуск реліз-кандидата, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease`
+запускає лише релізний дочірній процес плагіна, `release-checks` запускає кожен релізний
+бокс, а вужчі релізні групи — це `install-smoke`, `cross-os`,
+`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`, коли надано
+окрему пакетну Telegram-ланку.

 ### Vitest

-Блок Vitest — це ручний дочірній workflow `CI`. Ручний CI навмисно
-оминає changed scoping і примусово запускає звичайний тестовий граф для release
-candidate: Linux Node-шарди, шарди bundled-plugin, контракти каналів, сумісність Node 22,
-`check`, `check-additional`, build smoke, перевірки документації, Python
-skills, Windows, macOS, Android і i18n Control UI.
+Бокс Vitest — це ручний дочірній робочий процес `CI`. Ручний CI навмисно
+оминає звуження за змінами та примусово запускає звичайний тестовий граф для реліз-кандидата:
+Linux Node-шарди, шарди вбудованих плагінів, контракти каналів, сумісність із Node 22,
+`check`, `check-additional`, build smoke, перевірки документації, Python Skills, Windows,
+macOS, Android і i18n Control UI.

-Використовуйте цей блок, щоб відповісти на запитання: «чи пройшло дерево джерельного коду повний звичайний набір тестів?»
-Це не те саме, що валідація продукту на релізному шляху. Докази, які потрібно зберегти:
+Використовуйте цей бокс, щоб відповісти на запитання: "чи пройшло дерево вихідного коду повний звичайний набір тестів?"
+Це не те саме, що продуктова валідація релізного шляху. Докази, які потрібно зберігати:

- підсумок `Full Release Validation`, що показує URL запущеного `CI`
+- зведення `Full Release Validation`, що показує URL запущеного `CI`
 - зелений запуск `CI` на точному цільовому SHA
 - назви невдалих або повільних шардів із завдань CI під час дослідження регресій
- артефакти часу виконання Vitest, такі як `.artifacts/vitest-shard-timings.json`, коли
+- артефакти таймінгів Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли
  запуск потребує аналізу продуктивності

-Запускайте ручний CI напряму лише тоді, коли реліз потребує детермінованого звичайного CI, але
-не Docker, QA Lab, live, cross-OS або package-блоків:
+Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований звичайний CI, але
+не потрібні Docker, QA Lab, live, cross-OS або пакетні бокси:

 ```bash
 gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D
@ -345,94 +250,99 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D

 ### Docker

-Docker-блок міститься в `OpenClaw Release Checks` через
-`openclaw-live-and-e2e-checks-reusable.yml`, а також у release-mode
-workflow `install-smoke`. Він перевіряє release candidate через упаковані
-Docker-середовища, а не лише через тести на рівні джерельного коду.
+Бокс Docker живе в `OpenClaw Release Checks` через
+`openclaw-live-and-e2e-checks-reusable.yml`, а також у релізному режимі робочого процесу
+`install-smoke`. Він перевіряє реліз-кандидат через пакетовані
+Docker-середовища, а не лише тести на рівні вихідного коду.

-Покриття release Docker включає:
+Релізне Docker-покриття включає:

- повний install smoke із увімкненим повільним Bun global install smoke
- repository E2E-лінії
- release-path Docker-частини: `core`, `package-update-openai`,
-  `package-update-anthropic`, `package-update-core`, `plugins-runtime-core`,
+- повний install smoke з увімкненим повільним Bun global install smoke
+- E2E-ланки репозиторію
+- Docker-фрагменти релізного шляху: `core`, `package-update-openai`,
+  `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`,
+  `plugins-runtime-services`,
  `plugins-runtime-install-a`, `plugins-runtime-install-b`,
+  `plugins-runtime-install-c`, `plugins-runtime-install-d`,
+  `plugins-runtime-install-e`, `plugins-runtime-install-f`,
+  `plugins-runtime-install-g`, `plugins-runtime-install-h`,
  `bundled-channels-core`, `bundled-channels-update-a`,
-  `bundled-channels-update-b` і `bundled-channels-contracts`
- покриття OpenWebUI всередині частини `plugins-runtime-core`, коли запитано
- розділені лінії залежностей bundled-channel між channel-smoke, update-target
-  і setup/runtime contract-частинами замість одного великого завдання bundled-channel
- розділені лінії встановлення/видалення bundled Plugin
+  `bundled-channels-update-discord`, `bundled-channels-update-b` і
+  `bundled-channels-contracts`
+- покриття OpenWebUI всередині фрагмента `plugins-runtime-services`, коли його запитано
+- розділені ланки залежностей вбудованих каналів між channel-smoke, update-target
+  і фрагментами контрактів setup/runtime замість одного великого завдання для вбудованих каналів
+- розділені ланки встановлення/видалення вбудованих плагінів
  `bundled-plugin-install-uninstall-0` через
-  `bundled-plugin-install-uninstall-7`
- live/E2E-набори провайдерів і Docker live-покриття моделей, коли release checks
+  `bundled-plugin-install-uninstall-23`
+- live/E2E-набори постачальників і Docker live-покриття моделей, коли релізні перевірки
  включають live-набори

-Використовуйте Docker-артефакти перед повторним запуском. Release-path планувальник завантажує
-`.artifacts/docker-tests/` із журналами ліній, `summary.json`, `failures.json`,
-часами фаз, JSON плану планувальника та командами повторного запуску. Для сфокусованого відновлення
-використовуйте `docker_lanes=<lane[,lane]>` у reusable live/E2E workflow замість
-повторного запуску всіх релізних частин. Згенеровані команди повторного запуску включають попередній
-`package_artifact_run_id` і підготовлені входи Docker-образів, коли доступні, тож
-невдала лінія може повторно використати той самий tarball і GHCR-образи.
+Використовуйте Docker-артефакти перед повторним запуском. Планувальник релізного шляху завантажує
+`.artifacts/docker-tests/` із журналами ланок, `summary.json`, `failures.json`,
+таймінгами фаз, JSON плану планувальника та командами повторного запуску. Для сфокусованого відновлення
+використовуйте `docker_lanes=<lane[,lane]>` у багаторазовому live/E2E-робочому процесі замість
+повторного запуску всіх релізних фрагментів. Згенеровані команди повторного запуску включають попередні
+`package_artifact_run_id` і підготовлені вхідні дані Docker-образів, коли вони доступні, щоб
+невдала ланка могла повторно використати той самий tarball і GHCR-образи.

 ### QA Lab

-Блок QA Lab також є частиною `OpenClaw Release Checks`. Це релізний gate для агентної
-поведінки й рівня каналів, окремий від механіки пакетів Vitest і Docker.
+Бокс QA Lab також є частиною `OpenClaw Release Checks`. Це релізний гейт
+агентної поведінки та рівня каналів, окремий від механіки пакетів Vitest і Docker.

-Покриття release QA Lab включає:
+Релізне покриття QA Lab включає:

- mock parity gate, що порівнює кандидатну лінію OpenAI з базовою лінією Opus 4.6
+- mock parity gate, що порівнює кандидатну ланку OpenAI з базовою лінією Opus 4.6
  за допомогою agentic parity pack
- швидкий live Matrix QA profile із використанням середовища `qa-live-shared`
- live Telegram QA lane із використанням Convex CI credential leases
+- швидкий live Matrix QA-профіль із використанням середовища `qa-live-shared`
+- live Telegram QA-ланку з використанням оренд облікових даних Convex CI
 - `pnpm qa:otel:smoke`, коли релізній телеметрії потрібне явне локальне підтвердження

-Використовуйте цей блок, щоб відповісти на запитання: «чи поводиться реліз коректно в QA-сценаріях і
-live-потоках каналів?» Зберігайте URL артефактів для parity, Matrix і Telegram
-ліній під час схвалення релізу. Повне Matrix-покриття залишається доступним як
-ручний шардований запуск QA-Lab, а не стандартна релізно-критична лінія.
+Використовуйте цей бокс, щоб відповісти на запитання: "чи поводиться реліз правильно в QA-сценаріях і
+live-потоках каналів?" Зберігайте URL артефактів для ланок parity, Matrix і Telegram
+під час схвалення релізу. Повне Matrix-покриття залишається доступним як
+ручний шардований запуск QA-Lab, а не типова релізно-критична ланка.

-### Package
+### Пакет

-Package-блок — це gate для інстальованого продукту. Він підтримується
-`Package Acceptance` і resolver
-`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує
-кандидата в tarball `package-under-test`, який споживає Docker E2E, перевіряє
-інвентар пакета, записує версію пакета та SHA-256 і тримає
-ref harness workflow окремо від ref джерела пакета.
+Бокс Package — це гейт інстальованого продукту. Він спирається на
+`Package Acceptance` і резолвер
+`scripts/resolve-openclaw-package-candidate.mjs`. Резолвер нормалізує
+кандидат у tarball `package-under-test`, який споживає Docker E2E, перевіряє
+інвентар пакета, записує версію пакета та SHA-256 і тримає ref обв'язки
+робочого процесу окремо від ref вихідного коду пакета.

 Підтримувані джерела кандидатів:

 - `source=npm`: `openclaw@beta`, `openclaw@latest` або точна релізна
  версія OpenClaw
- `source=ref`: пакує довірену гілку `package_ref`, тег або повний commit SHA
-  з вибраним harness `workflow_ref`
- `source=url`: завантажує HTTPS `.tgz` з обов’язковим `package_sha256`
- `source=artifact`: повторно використовує `.tgz`, завантажений іншим запуском GitHub Actions
+- `source=ref`: запакувати довірену гілку `package_ref`, тег або повний commit SHA
+  з вибраною обв'язкою `workflow_ref`
+- `source=url`: завантажити HTTPS `.tgz` з обов'язковим `package_sha256`
+- `source=artifact`: повторно використати `.tgz`, завантажений іншим запуском GitHub Actions

 `OpenClaw Release Checks` запускає Package Acceptance із `source=ref`,
 `package_ref=<release-ref>`, `suite_profile=custom`,
 `docker_lanes=bundled-channel-deps-compat plugins-offline` і
-`telegram_mode=mock-openai`. Release-path Docker-частини покривають
-перетинальні лінії встановлення, оновлення та plugin-update; Package Acceptance зберігає
-artifact-native bundled-channel compat, offline Plugin fixtures і Telegram
-package QA проти того самого resolved tarball. Це GitHub-native
-заміна більшості покриття package/update, яке раніше потребувало
-Parallels. Cross-OS release checks усе ще важливі для специфічних для ОС onboarding,
-installer і platform behavior, але валідація продукту package/update має
+`telegram_mode=mock-openai`. Docker-фрагменти релізного шляху покривають
+перетин ланок install, update і plugin-update; Package Acceptance зберігає
+артефактно-нативну сумісність вбудованих каналів, офлайн-фікстури плагінів і Telegram
+package QA щодо того самого розв'язаного tarball. Це GitHub-нативна
+заміна більшої частини покриття package/update, яке раніше вимагало
+Parallels. Cross-OS release checks усе ще важливі для OS-специфічного onboarding,
+інсталятора та поведінки платформи, але продуктова валідація package/update має
 віддавати перевагу Package Acceptance.

-Поблажливість legacy package-acceptance навмисно обмежена в часі. Пакети до
-`2026.4.25` включно можуть використовувати compatibility path для metadata gaps, уже опублікованих
-до npm: приватні QA inventory entries, відсутні в tarball, відсутній
-`gateway install --wrapper`, відсутні patch files у tarball-derived git
-fixture, відсутній збережений `update.channel`, legacy plugin install-record
-locations, відсутня marketplace install-record persistence і міграція config metadata
+Пом'якшення legacy package-acceptance навмисно обмежене в часі. Пакети до
+`2026.4.25` включно можуть використовувати шлях сумісності для прогалин метаданих, уже опублікованих
+у npm: приватні QA-записи інвентарю, відсутні в tarball, відсутній
+`gateway install --wrapper`, відсутні patch-файли у git-фікстурі, отриманій із tarball,
+відсутній збережений `update.channel`, legacy-розташування install-record плагінів,
+відсутня сталість marketplace install-record і міграція метаданих config
 під час `plugins update`. Опублікований пакет `2026.4.26` може попереджати
-про local build metadata stamp files, які вже були поставлені. Пізніші пакети
-мають відповідати сучасним package contracts; ті самі прогалини провалюють релізну
+про локальні файли штампу метаданих збірки, які вже були відвантажені. Пізніші пакети
+мають відповідати сучасним контрактам пакета; ті самі прогалини провалюють релізну
 валідацію.

 Використовуйте ширші профілі Package Acceptance, коли релізне питання стосується
@ -447,87 +357,86 @@ gh workflow run package-acceptance.yml \
  -f suite_profile=product
 ```

-Поширені профілі пакетів:
+Поширені профілі пакета:

- `smoke`: швидкі лінії встановлення пакета/каналу/агента, мережі Gateway і
-  перезавантаження конфігурації
- `package`: контракти install/update/plugin package без live ClawHub; це стандарт
-  release-check
- `product`: `package` плюс MCP channels, cron/subagent cleanup, OpenAI web
+- `smoke`: швидкі ланки встановлення пакета/каналу/агента, gateway-мережі та
+  перезавантаження config
+- `package`: контракти install/update/plugin package без live ClawHub; це типовий варіант release-check
+- `product`: `package` плюс MCP-канали, cron/очищення subagent, OpenAI web
  search і OpenWebUI
- `full`: Docker release-path chunks з OpenWebUI
+- `full`: Docker-фрагменти релізного шляху з OpenWebUI
 - `custom`: точний список `docker_lanes` для сфокусованих повторних запусків

-Для package-candidate Telegram proof увімкніть `telegram_mode=mock-openai` або
-`telegram_mode=live-frontier` у Package Acceptance. Workflow передає resolved
-tarball `package-under-test` у Telegram-лінію; автономний Telegram workflow
-досі приймає опублікований npm spec для post-publish checks.
+Для package-candidate Telegram-підтвердження увімкніть `telegram_mode=mock-openai` або
+`telegram_mode=live-frontier` у Package Acceptance. Робочий процес передає
+розв'язаний tarball `package-under-test` у Telegram-ланку; окремий
+Telegram-робочий процес і далі приймає опубліковану npm-специфікацію для post-publish-перевірок.

-## Вхідні параметри NPM workflow
+## Вхідні дані робочого процесу NPM

-`OpenClaw NPM Release` приймає такі керовані оператором вхідні параметри:
+`OpenClaw NPM Release` приймає такі керовані оператором вхідні дані:

- `tag`: обов’язковий релізний тег, такий як `v2026.4.2`, `v2026.4.2-1` або
+- `tag`: обов'язковий релізний тег, як-от `v2026.4.2`, `v2026.4.2-1` або
  `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний
-  повний 40-символьний commit SHA workflow-branch для validation-only preflight
- `preflight_only`: `true` для validation/build/package only, `false` для
-  справжнього publish path
- `preflight_run_id`: обов’язковий на справжньому publish path, щоб workflow повторно використав
+  повний 40-символьний commit SHA гілки робочого процесу для preflight лише з валідацією
+- `preflight_only`: `true` лише для validation/build/package, `false` для
+  справжнього шляху публікації
+- `preflight_run_id`: обов'язковий на справжньому шляху публікації, щоб робочий процес повторно використовував
  підготовлений tarball з успішного preflight-запуску
- `npm_dist_tag`: цільовий npm-тег для publish path; за замовчуванням `beta`
+- `npm_dist_tag`: цільовий npm-тег для шляху публікації; типово `beta`

-`OpenClaw Release Checks` приймає такі керовані оператором вхідні параметри:
+`OpenClaw Release Checks` приймає такі керовані оператором вхідні дані:

- `ref`: гілка, тег або повний commit SHA для перевірки. Secret-bearing checks
-  вимагають, щоб resolved commit був досяжний з гілки OpenClaw або
+- `ref`: гілка, тег або повний commit SHA для валідації. Перевірки із секретами
+  вимагають, щоб розв'язаний коміт був досяжним із гілки OpenClaw або
  релізного тегу.

 Правила:

- Стабільні та correction tags можуть публікуватися або в `beta`, або в `latest`
- Beta prerelease tags можуть публікуватися лише в `beta`
- Для `OpenClaw NPM Release` введення повного commit SHA дозволено лише коли
+- Стабільні та корекційні теги можуть публікуватися або в `beta`, або в `latest`
+- Beta prerelease-теги можуть публікуватися лише в `beta`
+- Для `OpenClaw NPM Release` вхідний повний commit SHA дозволений лише коли
  `preflight_only=true`
 - `OpenClaw Release Checks` і `Full Release Validation` завжди
-  тільки validation-only
- Справжній publish path має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
-  workflow перевіряє, що metadata перед publish продовжує відповідати
+  лише валідаційні
+- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight;
+  робочий процес перевіряє ці метадані перед продовженням публікації

 ## Послідовність стабільного npm-релізу

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

 1. Запустіть `OpenClaw NPM Release` із `preflight_only=true`
-   - До існування тегу можна використати поточний повний commit SHA workflow-branch
-     для validation-only dry run preflight workflow
-2. Виберіть `npm_dist_tag=beta` для звичайного beta-first потоку або `latest` лише
-   тоді, коли навмисно хочете пряме стабільне опублікування
+   - До створення тегу можна використати поточний повний commit SHA гілки робочого процесу
+     для валідаційного dry run preflight-робочого процесу
+2. Виберіть `npm_dist_tag=beta` для звичайного beta-first-потоку або `latest` лише
+   тоді, коли ви навмисно хочете прямої стабільної публікації
 3. Запустіть `Full Release Validation` на релізній гілці, релізному тегу або повному
-   commit SHA, коли потрібні звичайний CI плюс live prompt cache, Docker, QA Lab,
-   Matrix і Telegram-покриття з одного ручного workflow
+   commit SHA, коли потрібне звичайне CI-покриття плюс live prompt cache, Docker, QA Lab,
+   Matrix і Telegram з одного ручного робочого процесу
 4. Якщо вам навмисно потрібен лише детермінований звичайний тестовий граф, запустіть
-   ручний workflow `CI` на release ref натомість
+   ручний робочий процес `CI` на релізному ref
 5. Збережіть успішний `preflight_run_id`
 6. Запустіть `OpenClaw NPM Release` знову з `preflight_only=false`, тим самим
   `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id`
-7. Якщо реліз потрапив у `beta`, використайте приватний workflow
-   `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
+7. Якщо реліз потрапив у `beta`, використовуйте приватний
+   робочий процес `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`,
   щоб просунути цю стабільну версію з `beta` до `latest`
-8. Якщо реліз навмисно опубліковано напряму в `latest`, а `beta`
-   має негайно слідувати за тією самою стабільною збіркою, використайте той самий приватний
-   workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
-   self-healing sync перемістити `beta` пізніше
+8. Якщо реліз навмисно опубліковано прямо в `latest` і `beta`
+   має негайно вказувати на ту саму стабільну збірку, використовуйте той самий приватний
+   робочий процес, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій
+   self-healing-синхронізації перемістити `beta` пізніше

-Мутація dist-tag міститься в приватному repo з міркувань безпеки, бо вона все ще
-потребує `NPM_TOKEN`, тоді як public repo зберігає OIDC-only publish.
+Мутація dist-tag живе у приватному репозиторії з міркувань безпеки, бо вона все ще
+потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC.

-Це робить і direct publish path, і beta-first promotion path
+Це зберігає і шлях прямої публікації, і шлях beta-first-просування
 задокументованими та видимими для оператора.

-Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password
-CLI (`op`) лише всередині dedicated tmux session. Не викликайте `op`
-напряму з main agent shell; утримання його всередині tmux робить prompts,
-alerts і OTP handling спостережуваними та запобігає повторним host alerts.
+Якщо мейнтейнер мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password
+CLI (`op`) лише всередині виділеної tmux-сесії. Не викликайте `op`
+напряму з основної оболонки агента; утримання цього всередині tmux робить prompts,
+alerts і обробку OTP спостережуваними та запобігає повторним host alerts.

 ## Публічні посилання

@ -541,10 +450,10 @@ alerts і OTP handling спостережуваними та запобігає
 - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh)
 - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh)

-Супровідники використовують приватну документацію щодо випусків у
+Супровідники використовують приватну документацію до релізів у
 [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md)
-як фактичний операційний посібник.
+як фактичний регламент виконання.

 ## Пов’язане

- [Канали випусків](/uk/install/development-channels)
+- [Канали релізів](/uk/install/development-channels)
--- a/docs/uk/tools/thinking.md
+++ b/docs/uk/tools/thinking.md
@ -1,137 +1,139 @@
 ---
 read_when:
-    - Налаштування парсингу або типових значень директив thinking, fast-mode чи verbose
+    - Налаштування розбору або стандартних значень директив мислення, швидкого режиму чи докладності
 summary: Синтаксис директив для /think, /fast, /verbose, /trace і видимості міркувань
 title: Рівні мислення
 x-i18n:
-    generated_at: "2026-04-27T14:22:14Z"
-    model: gpt-5.4
+    generated_at: "2026-04-29T10:40:16Z"
+    model: gpt-5.5
    provider: openai
-    source_hash: 0d79dc5a84bb2e695fafb6f2298aabf253126dc20d474bc64ca19a7fe6ac5454
+    source_hash: e9fabead8d2f58fc5bce3bf8b281ad9d52da2cd02ba2777bc1597359537b7705
    source_path: tools/thinking.md
-    workflow: 15
+    workflow: 16
 ---

-## Що це робить
+## Що робить

 - Вбудована директива в будь-якому вхідному тілі: `/t <level>`, `/think:<level>` або `/thinking <level>`.
- Рівні (аліаси): `off | minimal | low | medium | high | xhigh | adaptive | max`
+- Рівні (псевдоніми): `off | minimal | low | medium | high | xhigh | adaptive | max`
  - minimal → «think»
  - low → «think hard»
  - medium → «think harder»
  - high → «ultrathink» (максимальний бюджет)
  - xhigh → «ultrathink+» (моделі GPT-5.2+ і Codex, а також зусилля Anthropic Claude Opus 4.7)
-  - adaptive → кероване провайдером адаптивне thinking (підтримується для Claude 4.6 на Anthropic/Bedrock, Anthropic Claude Opus 4.7 і динамічного thinking Google Gemini)
-  - max → максимальне reasoning провайдера (Anthropic Claude Opus 4.7; Ollama відображає це у своє найвище нативне зусилля `think`)
-  - `x-high`, `x_high`, `extra-high`, `extra high` і `extra_high` відображаються в `xhigh`.
-  - `highest` відображається в `high`.
+  - adaptive → адаптивне мислення, кероване провайдером (підтримується для Claude 4.6 в Anthropic/Bedrock, Anthropic Claude Opus 4.7 і динамічного мислення Google Gemini)
+  - max → максимальне reasoning провайдера (Anthropic Claude Opus 4.7; Ollama зіставляє це зі своїм найвищим нативним зусиллям `think`)
+  - `x-high`, `x_high`, `extra-high`, `extra high` і `extra_high` зіставляються з `xhigh`.
+  - `highest` зіставляється з `high`.
 - Примітки щодо провайдерів:
-  - Меню та селектори thinking керуються профілями провайдерів. Provider plugins оголошують точний набір рівнів для вибраної моделі, включно з мітками на кшталт бінарного `on`.
-  - `adaptive`, `xhigh` і `max` оголошуються лише для профілів провайдерів/моделей, які їх підтримують. Типізовані директиви для непідтримуваних рівнів відхиляються з переліком дійсних варіантів для цієї моделі.
-  - Наявні збережені непідтримувані рівні повторно відображаються за рангом профілю провайдера. `adaptive` повертається до `medium` на неадаптивних моделях, а `xhigh` і `max` повертаються до найбільшого підтримуваного рівня, що не є `off`, для вибраної моделі.
-  - Моделі Anthropic Claude 4.6 типово використовують `adaptive`, коли явно не задано рівень thinking.
-  - Anthropic Claude Opus 4.7 не використовує адаптивне thinking типово. Типове значення зусилля API залишається у власності провайдера, якщо ви явно не встановите рівень thinking.
-  - Anthropic Claude Opus 4.7 відображає `/think xhigh` на адаптивне thinking плюс `output_config.effort: "xhigh"`, тому що `/think` — це директива thinking, а `xhigh` — це параметр effort для Opus 4.7.
-  - Anthropic Claude Opus 4.7 також підтримує `/think max`; це відображається на той самий шлях максимального effort, керований провайдером.
-  - Моделі Ollama з підтримкою thinking надають `/think low|medium|high|max`; `max` відображається на нативне `think: "high"`, тому що нативний API Ollama приймає рядки effort `low`, `medium` і `high`.
-  - Моделі OpenAI GPT відображають `/think` через підтримку effort Responses API, специфічну для моделі. `/think off` надсилає `reasoning.effort: "none"` лише тоді, коли цільова модель це підтримує; інакше OpenClaw пропускає вимкнений payload reasoning замість надсилання непідтримуваного значення.
-  - Застарілі налаштовані посилання OpenRouter Hunter Alpha пропускають ін’єкцію proxy reasoning, тому що цей виведений з експлуатації маршрут міг повертати текст фінальної відповіді через поля reasoning.
-  - Google Gemini відображає `/think adaptive` на динамічне thinking, кероване провайдером у Gemini. Запити Gemini 3 пропускають фіксований `thinkingLevel`, тоді як запити Gemini 2.5 надсилають `thinkingBudget: -1`; фіксовані рівні все одно відображаються на найближчий `thinkingLevel` або бюджет Gemini для цього сімейства моделей.
-  - MiniMax (`minimax/*`) на Anthropic-сумісному streaming path типово використовує `thinking: { type: "disabled" }`, якщо ви явно не встановите thinking у параметрах моделі або параметрах запиту. Це запобігає витоку дельт `reasoning_content` з ненативного формату потоку Anthropic у MiniMax.
-  - Z.AI (`zai/*`) підтримує лише бінарне thinking (`on`/`off`). Будь-який рівень, відмінний від `off`, вважається `on` (відображається на `low`).
-  - Moonshot (`moonshot/*`) відображає `/think off` на `thinking: { type: "disabled" }`, а будь-який рівень, відмінний від `off`, — на `thinking: { type: "enabled" }`. Коли thinking увімкнено, Moonshot приймає лише `tool_choice` `auto|none`; OpenClaw нормалізує несумісні значення до `auto`.
+  - Меню й селектори мислення керуються профілем провайдера. Плагіни провайдерів оголошують точний набір рівнів для вибраної моделі, зокрема мітки на кшталт бінарного `on`.
+  - `adaptive`, `xhigh` і `max` показуються лише для профілів провайдера/моделі, які їх підтримують. Введені директиви для непідтримуваних рівнів відхиляються з чинними варіантами для цієї моделі.
+  - Наявні збережені непідтримувані рівні переозначаються за рангом профілю провайдера. `adaptive` повертається до `medium` на неадаптивних моделях, тоді як `xhigh` і `max` повертаються до найбільшого підтримуваного не-`off` рівня для вибраної моделі.
+  - Моделі Anthropic Claude 4.6 типово використовують `adaptive`, коли явний рівень мислення не задано.
+  - Anthropic Claude Opus 4.7 не використовує адаптивне мислення типово. Типове значення зусилля в його API залишається у власності провайдера, якщо ви явно не задасте рівень мислення.
+  - Anthropic Claude Opus 4.7 зіставляє `/think xhigh` з адаптивним мисленням і `output_config.effort: "xhigh"`, бо `/think` є директивою мислення, а `xhigh` є налаштуванням зусилля Opus 4.7.
+  - Anthropic Claude Opus 4.7 також надає `/think max`; це зіставляється з тим самим шляхом максимального зусилля, що належить провайдеру.
+  - Моделі Ollama з підтримкою мислення надають `/think low|medium|high|max`; `max` зіставляється з нативним `think: "high"`, бо нативний API Ollama приймає рядки зусилля `low`, `medium` і `high`.
+  - Моделі OpenAI GPT зіставляють `/think` через підтримку зусиль Responses API, специфічну для моделі. `/think off` надсилає `reasoning.effort: "none"` лише тоді, коли цільова модель це підтримує; інакше OpenClaw пропускає вимкнене reasoning-навантаження замість надсилання непідтримуваного значення.
+  - Користувацькі записи каталогу, сумісні з OpenAI, можуть увімкнути `/think xhigh`, задавши `models.providers.<provider>.models[].compat.supportedReasoningEfforts` із включеним `"xhigh"`. Це використовує ті самі метадані сумісності, що зіставляють вихідні навантаження зусилля OpenAI reasoning, тому меню, перевірка сесії, agent CLI і `llm-task` узгоджуються з поведінкою транспорту.
+  - Застарілі налаштовані посилання OpenRouter Hunter Alpha пропускають ін’єкцію proxy reasoning, бо цей виведений з обігу маршрут міг повертати текст фінальної відповіді через поля reasoning.
+  - Google Gemini зіставляє `/think adaptive` з динамічним мисленням Gemini, що належить провайдеру. Запити Gemini 3 пропускають фіксований `thinkingLevel`, тоді як запити Gemini 2.5 надсилають `thinkingBudget: -1`; фіксовані рівні все ще зіставляються з найближчим Gemini `thinkingLevel` або бюджетом для цієї родини моделей.
+  - MiniMax (`minimax/*`) на потоковому шляху, сумісному з Anthropic, типово використовує `thinking: { type: "disabled" }`, якщо ви явно не задасте мислення в параметрах моделі або параметрах запиту. Це запобігає витоку дельт `reasoning_content` з ненативного Anthropic-потокового формату MiniMax.
+  - Z.AI (`zai/*`) підтримує лише бінарне мислення (`on`/`off`). Будь-який не-`off` рівень розглядається як `on` (зіставляється з `low`).
+  - Moonshot (`moonshot/*`) зіставляє `/think off` з `thinking: { type: "disabled" }`, а будь-який не-`off` рівень з `thinking: { type: "enabled" }`. Коли мислення ввімкнено, Moonshot приймає лише `tool_choice` `auto|none`; OpenClaw нормалізує несумісні значення до `auto`.

-## Порядок визначення
+## Порядок розв’язання

 1. Вбудована директива в повідомленні (застосовується лише до цього повідомлення).
-2. Перевизначення сесії (встановлюється надсиланням повідомлення, що містить лише директиву).
+2. Перевизначення сесії (задається надсиланням повідомлення, що містить лише директиву).
 3. Типове значення для агента (`agents.list[].thinkingDefault` у конфігурації).
 4. Глобальне типове значення (`agents.defaults.thinkingDefault` у конфігурації).
-5. Резервний варіант: типове значення, оголошене провайдером, якщо доступне; інакше моделі з підтримкою reasoning визначаються як `medium` або найближчий підтримуваний рівень, що не є `off`, для цієї моделі, а моделі без reasoning залишаються `off`.
+5. Резерв: оголошене провайдером типове значення, коли воно доступне; інакше моделі з підтримкою reasoning розв’язуються до `medium` або найближчого підтримуваного не-`off` рівня для цієї моделі, а моделі без reasoning залишаються `off`.

-## Установлення типового значення для сесії
+## Налаштування типового значення сесії

- Надішліть повідомлення, яке **містить лише** директиву (пробіли дозволені), наприклад `/think:medium` або `/t high`.
- Воно закріплюється для поточної сесії (типово для кожного відправника окремо); очищується через `/think:off` або скидання через неактивність сесії.
- Надсилається відповідь-підтвердження (`Thinking level set to high.` / `Thinking disabled.`). Якщо рівень недійсний (наприклад, `/thinking big`), команда відхиляється з підказкою, а стан сесії не змінюється.
- Надішліть `/think` (або `/think:`) без аргументу, щоб побачити поточний рівень thinking.
+- Надішліть повідомлення, яке містить **лише** директиву (пробіли дозволені), наприклад `/think:medium` або `/t high`.
+- Воно закріплюється для поточної сесії (типово для кожного відправника); очищається через `/think:off` або скидання сесії після простою.
+- Надсилається відповідь-підтвердження (`Thinking level set to high.` / `Thinking disabled.`). Якщо рівень недійсний (наприклад, `/thinking big`), команду буде відхилено з підказкою, а стан сесії залишиться без змін.
+- Надішліть `/think` (або `/think:`) без аргументу, щоб побачити поточний рівень мислення.

-## Застосування агентом
+## Застосування за агентом

- **Вбудований Pi**: визначений рівень передається у внутрішньопроцесне середовище виконання агента Pi.
+- **Вбудований Pi**: розв’язаний рівень передається до процесного runtime агента Pi.

 ## Швидкий режим (/fast)

 - Рівні: `on|off`.
- Повідомлення лише з директивою перемикає перевизначення fast-mode для сесії та відповідає `Fast mode enabled.` / `Fast mode disabled.`.
- Надішліть `/fast` (або `/fast status`) без режиму, щоб побачити поточний ефективний стан fast-mode.
- OpenClaw визначає fast mode в такому порядку:
-  1. Вбудована директива/директива-тільки `/fast on|off`
+- Повідомлення лише з директивою перемикає перевизначення швидкого режиму сесії й відповідає `Fast mode enabled.` / `Fast mode disabled.`.
+- Надішліть `/fast` (або `/fast status`) без режиму, щоб побачити поточний ефективний стан швидкого режиму.
+- OpenClaw розв’язує швидкий режим у такому порядку:
+  1. Вбудована або директивна-only `/fast on|off`
  2. Перевизначення сесії
  3. Типове значення для агента (`agents.list[].fastModeDefault`)
  4. Конфігурація для моделі: `agents.defaults.models["<provider>/<model>"].params.fastMode`
-  5. Резервний варіант: `off`
- Для `openai/*` fast mode відображається на пріоритетну обробку OpenAI через надсилання `service_tier=priority` у підтримуваних запитах Responses.
- Для `openai-codex/*` fast mode надсилає той самий прапорець `service_tier=priority` у Codex Responses. OpenClaw зберігає один спільний перемикач `/fast` для обох шляхів автентифікації.
- Для прямих публічних запитів `anthropic/*`, включно з трафіком з OAuth-автентифікацією, надісланим до `api.anthropic.com`, fast mode відображається на рівні сервісу Anthropic: `/fast on` встановлює `service_tier=auto`, `/fast off` встановлює `service_tier=standard_only`.
- Для `minimax/*` на Anthropic-сумісному шляху `/fast on` (або `params.fastMode: true`) переписує `MiniMax-M2.7` на `MiniMax-M2.7-highspeed`.
- Явні параметри моделі Anthropic `serviceTier` / `service_tier` перевизначають типове значення fast-mode, коли встановлено обидва. OpenClaw усе одно пропускає ін’єкцію рівня сервісу Anthropic для не-Anthropic proxy base URL.
- `/status` показує `Fast` лише коли fast mode увімкнено.
+  5. Резерв: `off`
+- Для `openai/*` швидкий режим зіставляється з пріоритетною обробкою OpenAI через надсилання `service_tier=priority` у підтримуваних запитах Responses.
+- Для `openai-codex/*` швидкий режим надсилає той самий прапорець `service_tier=priority` у Codex Responses. OpenClaw зберігає один спільний перемикач `/fast` для обох шляхів автентифікації.
+- Для прямих публічних запитів `anthropic/*`, зокрема OAuth-автентифікованого трафіку, надісланого до `api.anthropic.com`, швидкий режим зіставляється з рівнями сервісу Anthropic: `/fast on` задає `service_tier=auto`, `/fast off` задає `service_tier=standard_only`.
+- Для `minimax/*` на шляху, сумісному з Anthropic, `/fast on` (або `params.fastMode: true`) переписує `MiniMax-M2.7` на `MiniMax-M2.7-highspeed`.
+- Явні параметри моделі Anthropic `serviceTier` / `service_tier` перевизначають типове значення швидкого режиму, коли задано обидва. OpenClaw усе ще пропускає ін’єкцію рівня сервісу Anthropic для base URL proxy, що не належать Anthropic.
+- `/status` показує `Fast` лише коли швидкий режим увімкнено.

-## Директиви verbose (/verbose або /v)
+## Директиви докладності (/verbose або /v)

 - Рівні: `on` (мінімальний) | `full` | `off` (типово).
- Повідомлення лише з директивою перемикає session verbose і відповідає `Verbose logging enabled.` / `Verbose logging disabled.`; недійсні рівні повертають підказку без зміни стану.
- `/verbose off` зберігає явне перевизначення сесії; очистьте його через UI Sessions, вибравши `inherit`.
- Вбудована директива впливає лише на це повідомлення; в інших випадках застосовуються session/global defaults.
- Надішліть `/verbose` (або `/verbose:`) без аргументу, щоб побачити поточний рівень verbose.
- Коли verbose увімкнено, агенти, що виводять структуровані результати інструментів (Pi, інші JSON-агенти), надсилають кожен виклик інструмента назад як окреме повідомлення лише з метаданими з префіксом `<emoji> <tool-name>: <arg>`, коли доступно (шлях/команда). Ці підсумки інструментів надсилаються щойно кожен інструмент запускається (окремими бульбашками), а не як streaming deltas.
- Підсумки збоїв інструментів залишаються видимими у звичайному режимі, але сирі суфікси деталей помилок приховані, якщо verbose не має значення `on` або `full`.
- Коли verbose має значення `full`, виводи інструментів також пересилаються після завершення (окрема бульбашка, обрізана до безпечної довжини). Якщо ви перемкнете `/verbose on|full|off` під час виконання, наступні бульбашки інструментів врахують нове значення.
+- Повідомлення лише з директивою перемикає докладність сесії й відповідає `Verbose logging enabled.` / `Verbose logging disabled.`; недійсні рівні повертають підказку без зміни стану.
+- `/verbose off` зберігає явне перевизначення сесії; очистьте його через UI сесій, вибравши `inherit`.
+- Вбудована директива впливає лише на це повідомлення; інакше застосовуються типові значення сесії/глобальні.
+- Надішліть `/verbose` (або `/verbose:`) без аргументу, щоб побачити поточний рівень докладності.
+- Коли докладність увімкнено, агенти, які видають структуровані результати інструментів (Pi, інші JSON-агенти), надсилають кожен виклик інструмента назад як окреме повідомлення лише з метаданими, з префіксом `<emoji> <tool-name>: <arg>`, коли доступно (шлях/команда). Ці підсумки інструментів надсилаються щойно кожен інструмент стартує (окремі бульбашки), а не як потокові дельти.
+- Підсумки збоїв інструментів залишаються видимими у звичайному режимі, але необроблені суфікси деталей помилок приховані, якщо докладність не `on` або `full`.
+- Коли докладність `full`, вивід інструментів також пересилається після завершення (окрема бульбашка, обрізана до безпечної довжини). Якщо перемкнути `/verbose on|full|off`, поки виконання триває, наступні бульбашки інструментів врахують нове налаштування.

-## Директиви trace Plugin (/trace)
+## Директиви трасування Plugin (/trace)

 - Рівні: `on` | `off` (типово).
- Повідомлення лише з директивою перемикає вивід plugin trace для сесії та відповідає `Plugin trace enabled.` / `Plugin trace disabled.`.
- Вбудована директива впливає лише на це повідомлення; в інших випадках застосовуються session/global defaults.
- Надішліть `/trace` (або `/trace:`) без аргументу, щоб побачити поточний рівень trace.
- `/trace` вужчий за `/verbose`: він показує лише рядки trace/debug, що належать Plugin, наприклад підсумки налагодження Active Memory.
- Рядки trace можуть з’являтися в `/status` і як додаткове діагностичне повідомлення після звичайної відповіді асистента.
+- Повідомлення лише з директивою перемикає вивід трасування Plugin для сесії й відповідає `Plugin trace enabled.` / `Plugin trace disabled.`.
+- Вбудована директива впливає лише на це повідомлення; інакше застосовуються типові значення сесії/глобальні.
+- Надішліть `/trace` (або `/trace:`) без аргументу, щоб побачити поточний рівень трасування.
+- `/trace` вужчий за `/verbose`: він показує лише рядки трасування/налагодження, що належать плагіну, наприклад підсумки налагодження Active Memory.
+- Рядки трасування можуть з’являтися в `/status` і як наступне діагностичне повідомлення після звичайної відповіді асистента.

 ## Видимість reasoning (/reasoning)

 - Рівні: `on|off|stream`.
- Повідомлення лише з директивою перемикає, чи показуються блоки thinking у відповідях.
- Коли увімкнено, reasoning надсилається як **окреме повідомлення** з префіксом `Reasoning:`.
- `stream` (лише Telegram): передає reasoning у чернеткову бульбашку Telegram, поки генерується відповідь, а потім надсилає фінальну відповідь без reasoning.
- Аліас: `/reason`.
+- Повідомлення лише з директивою перемикає, чи показуються блоки мислення у відповідях.
+- Коли ввімкнено, reasoning надсилається як **окреме повідомлення** з префіксом `Reasoning:`.
+- `stream` (лише Telegram): транслює reasoning у чернеткову бульбашку Telegram, поки генерується відповідь, а потім надсилає фінальну відповідь без reasoning.
+- Псевдонім: `/reason`.
 - Надішліть `/reasoning` (або `/reasoning:`) без аргументу, щоб побачити поточний рівень reasoning.
- Порядок визначення: вбудована директива, потім перевизначення сесії, потім типове значення для агента (`agents.list[].reasoningDefault`), потім резервний варіант (`off`).
+- Порядок розв’язання: вбудована директива, потім перевизначення сесії, потім типове значення для агента (`agents.list[].reasoningDefault`), потім резерв (`off`).

-Некоректні теги reasoning локальних моделей обробляються консервативно. Закриті блоки `<think>...</think>` залишаються прихованими у звичайних відповідях, а незакритий reasoning після вже видимого тексту також приховується. Якщо відповідь повністю обгорнута в один незакритий opening tag і інакше була б доставлена як порожній текст, OpenClaw видаляє некоректний opening tag і доставляє решту тексту.
+Некоректні теги reasoning локальної моделі обробляються консервативно. Закриті блоки `<think>...</think>` залишаються прихованими у звичайних відповідях, а незакрите reasoning після вже видимого тексту також приховується. Якщо відповідь повністю обгорнута в один незакритий відкривальний тег і інакше була б доставлена як порожній текст, OpenClaw видаляє некоректний відкривальний тег і доставляє решту тексту.

 ## Пов’язане

- Документація режиму elevated розміщена в [Elevated mode](/uk/tools/elevated).
+- Документація підвищеного режиму міститься в [Підвищений режим](/uk/tools/elevated).

 ## Heartbeats

- Тіло перевірки Heartbeat — це налаштований heartbeat prompt (типово: `Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`). Вбудовані директиви в heartbeat-повідомленні застосовуються як зазвичай (але уникайте зміни типових значень сесії з heartbeat-повідомлень).
- Доставка Heartbeat типово включає лише фінальний payload. Щоб також надсилати окреме повідомлення `Reasoning:` (коли доступне), установіть `agents.defaults.heartbeat.includeReasoning: true` або для конкретного агента `agents.list[].heartbeat.includeReasoning: true`.
+- Тіло Heartbeat-проби є налаштованим Heartbeat-запитом (типово: `Read HEARTBEAT.md if it exists (workspace context). Follow it strictly. Do not infer or repeat old tasks from prior chats. If nothing needs attention, reply HEARTBEAT_OK.`). Вбудовані директиви в Heartbeat-повідомленні застосовуються як зазвичай (але уникайте зміни типових значень сесії з Heartbeats).
+- Доставка Heartbeat типово обмежується лише фінальним навантаженням. Щоб також надсилати окреме повідомлення `Reasoning:` (коли доступне), задайте `agents.defaults.heartbeat.includeReasoning: true` або для агента `agents.list[].heartbeat.includeReasoning: true`.

 ## UI вебчату

- Селектор thinking у вебчаті віддзеркалює збережений рівень сесії зі сховища/конфігурації вхідної сесії під час завантаження сторінки.
- Вибір іншого рівня негайно записує перевизначення сесії через `sessions.patch`; він не чекає наступного надсилання і не є одноразовим перевизначенням `thinkingOnce`.
- Перший варіант завжди має вигляд `Default (<resolved level>)`, де визначене типове значення походить із профілю provider thinking для активної моделі сесії плюс та сама логіка резервних варіантів, яку використовують `/status` і `session_status`.
- Селектор використовує `thinkingLevels`, повернені рядком/типовими значеннями сесії шлюзу, а `thinkingOptions` зберігається як застарілий список міток. UI браузера не зберігає власний список regex провайдерів; plugins володіють наборами рівнів, специфічними для моделі.
- `/think:<level>` усе ще працює й оновлює той самий збережений рівень сесії, тож директиви чату та селектор залишаються синхронізованими.
+- Селектор мислення вебчату відображає збережений рівень сесії зі сховища/конфігурації вхідної сесії під час завантаження сторінки.
+- Вибір іншого рівня одразу записує перевизначення сесії через `sessions.patch`; він не чекає наступного надсилання й не є одноразовим перевизначенням `thinkingOnce`.
+- Перший варіант завжди `Default (<resolved level>)`, де розв’язане типове значення походить із профілю мислення провайдера активної моделі сесії та тієї самої резервної логіки, яку використовують `/status` і `session_status`.
+- Селектор використовує `thinkingLevels`, повернені рядком/типовими значеннями сесії Gateway, а `thinkingOptions` зберігається як застарілий список міток. UI браузера не зберігає власний список regex провайдерів; плагіни володіють наборами рівнів, специфічними для моделей.
+- `/think:<level>` усе ще працює й оновлює той самий збережений рівень сесії, тому директиви чату й селектор залишаються синхронізованими.

 ## Профілі провайдерів

- Provider plugins можуть надавати `resolveThinkingProfile(ctx)` для визначення підтримуваних рівнів і типового значення моделі.
- Provider plugins, що проксують моделі Claude, мають повторно використовувати `resolveClaudeThinkingProfile(modelId)` з `openclaw/plugin-sdk/provider-model-shared`, щоб прямі каталоги Anthropic і proxy залишалися узгодженими.
- Кожен рівень профілю має збережений канонічний `id` (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `adaptive` або `max`) і може містити відображувану `label`. Бінарні провайдери використовують `{ id: "low", label: "on" }`.
- Tool plugins, яким потрібно перевіряти явне перевизначення thinking, мають використовувати `api.runtime.agent.resolveThinkingPolicy({ provider, model })` плюс `api.runtime.agent.normalizeThinkingLevel(...)`; вони не повинні зберігати власні списки рівнів для провайдера/моделі.
- Опубліковані застарілі хуки (`supportsXHighThinking`, `isBinaryThinking` і `resolveDefaultThinkingLevel`) залишаються як адаптери сумісності, але нові користувацькі набори рівнів мають використовувати `resolveThinkingProfile`.
- Рядки/типові значення Gateway надають `thinkingLevels`, `thinkingOptions` і `thinkingDefault`, щоб клієнти ACP/chat відображали ті самі id і label профілів, які використовує валідація під час виконання.
+- Plugin-и провайдерів можуть надавати `resolveThinkingProfile(ctx)`, щоб визначити підтримувані рівні моделі та типовий рівень.
+- Plugin-и провайдерів, які проксіюють моделі Claude, мають повторно використовувати `resolveClaudeThinkingProfile(modelId)` з `openclaw/plugin-sdk/provider-model-shared`, щоб прямі каталоги Anthropic і проксі-каталоги залишалися узгодженими.
+- Кожен рівень профілю має збережений канонічний `id` (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `adaptive` або `max`) і може містити відображуваний `label`. Бінарні провайдери використовують `{ id: "low", label: "on" }`.
+- Plugin-и інструментів, яким потрібно перевіряти явне перевизначення мислення, мають використовувати `api.runtime.agent.resolveThinkingPolicy({ provider, model })` разом із `api.runtime.agent.normalizeThinkingLevel(...)`; вони не мають зберігати власні списки рівнів провайдерів/моделей.
+- Plugin-и інструментів із доступом до налаштованих метаданих користувацьких моделей можуть передавати `catalog` у `resolveThinkingPolicy`, щоб opt-in значення `compat.supportedReasoningEfforts` відображалися у валідації на боці plugin.
+- Опубліковані застарілі хуки (`supportsXHighThinking`, `isBinaryThinking` і `resolveDefaultThinkingLevel`) залишаються адаптерами сумісності, але нові користувацькі набори рівнів мають використовувати `resolveThinkingProfile`.
+- Рядки/типові значення Gateway надають `thinkingLevels`, `thinkingOptions` і `thinkingDefault`, щоб клієнти ACP/чату відображали ті самі ідентифікатори й мітки профілю, які використовує runtime-валідація.