diff --git a/docs/uk/ci.md b/docs/uk/ci.md index 118904ea8..a7b4a179c 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,141 +1,138 @@ --- read_when: - - Вам потрібно зрозуміти, чому завдання CI виконалося або не виконалося - - Ви налагоджуєте перевірки GitHub Actions, які не проходять -summary: Граф завдань CI, перевірки за областю дії та локальні еквіваленти команд + - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося + - Ви налагоджуєте невдалі перевірки GitHub Actions +summary: Граф завдань CI, шлюзи області дії та локальні еквіваленти команд title: CI-конвеєр x-i18n: - generated_at: "2026-04-29T09:13:01Z" + generated_at: "2026-04-29T10:40:27Z" model: gpt-5.5 provider: openai - source_hash: fe934a27ac3ad314869c9a3995fb83d0fa1bda61f6e31508ce518ce601b0e3d2 + source_hash: 4e4b9dae0e16e5ae701c4dbe5966ac9c4b3d8a3292f1804eef8f595616170e43 source_path: ci.md workflow: 16 --- -CI запускається під час кожного push до `main` і кожного pull request. Він використовує розумне обмеження області, щоб пропускати дорогі завдання, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області та розгортають повний звичайний граф CI для реліз-кандидатів або широкої валідації, причому Android-лінії вмикаються через `include_android` для окремих ручних запусків. Передрелізні лінії Plugin, призначені лише для релізу, розміщені в окремому workflow `Plugin Prerelease` і запускаються лише з `Full Release Validation` або явного ручного dispatch. +CI запускається під час кожного push до `main` і кожного pull request. Вона використовує розумне обмеження області, щоб пропускати дорогі завдання, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області та розгортають повний звичайний граф CI для реліз-кандидатів або широкої перевірки, з Android-напрямками, що вмикаються через `include_android` для окремих ручних запусків. Релізні напрямки попереднього релізу Plugin живуть в окремому workflow `Plugin Prerelease` і запускаються лише з `Full Release Validation` або явного ручного dispatch. -Шард `check-dependencies` запускає `pnpm deadcode:dependencies`, production-прохід Knip лише для залежностей, закріплений за найновішою версією Knip, яку використовує цей скрипт, із вимкненим мінімальним віком релізу pnpm для встановлення `dlx`. Він блокує нові невикористані, неоголошені, нерозв’язані, бінарні або каталогові залежності, не вмикаючи повний режим Knip для невикористаних файлів, який залишається ручним аудитом, оскільки OpenClaw навмисно завантажує багато Plugin і runtime-поверхонь через маніфести та рядкові специфікатори. +Шард `check-dependencies` запускає `pnpm deadcode:dependencies`, production-прохід Knip лише для залежностей, закріплений на останній версії Knip, яку використовує цей скрипт, із вимкненим мінімальним віком релізу pnpm для встановлення через `dlx`. Він також запускає `pnpm deadcode:unused-files`, який порівнює production-знахідки Knip щодо невикористаних файлів із `scripts/deadcode-unused-files.allowlist.mjs`. Цей захист падає, коли PR додає новий непереглянутий невикористаний файл або залишає застарілий запис у allowlist після очищення, зберігаючи при цьому навмисні поверхні динамічних plugin, згенеровані, build, live-test і package bridge, які Knip не може статично розв’язати. `Full Release Validation` — це ручний umbrella workflow для «запустити все -перед релізом». Він приймає гілку, тег або повний SHA коміту, dispatch-ить -ручний workflow `CI` із цією ціллю, dispatch-ить `Plugin Prerelease` для -релізних доказів Plugin/пакетів/статичних артефактів/Docker, а також dispatch-ить -`OpenClaw Release Checks` для install smoke, package acceptance, Docker -release-path наборів, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram -ліній. Він також може запускати post-publish workflow `NPM Telegram Beta E2E`, коли -надано специфікацію опублікованого пакета. `release_profile=minimum|stable|full` керує широтою live/provider, -яку передають у release checks: `minimum` залишає найшвидші OpenAI/core -релізно-критичні лінії, `stable` додає стабільний набір provider/backend, а -`full` запускає широку advisory provider/media матрицю. Umbrella записує -ідентифікатори запущених дочірніх run, а фінальне завдання `Verify full validation` повторно перевіряє -поточні висновки дочірніх run і додає таблиці найповільніших завдань для кожного дочірнього -run. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське -завдання verifier, щоб оновити результат umbrella і підсумок часу. +перед релізом». Він приймає branch, tag або повний commit SHA, запускає ручний +workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізних доказів +plugin/package/static/Docker і запускає `OpenClaw Release Checks` для install +smoke, package acceptance, Docker-наборів релізного шляху, live/E2E, OpenWebUI, +QA Lab parity, Matrix і Telegram напрямків. Він також може запустити післяпублікаційний workflow `NPM Telegram Beta E2E`, коли надано +специфікацію опублікованого пакета. `release_profile=minimum|stable|full` керує широтою live/provider, +яку передають у release checks: `minimum` залишає найшвидші релізно-критичні +напрямки OpenAI/core, `stable` додає стабільний набір provider/backend, а +`full` запускає широку advisory-матрицю provider/media. Umbrella записує id +запущених дочірніх run, а фінальне завдання `Verify full validation` повторно +перевіряє поточні висновки дочірніх run і додає таблиці найповільніших завдань +для кожного дочірнього run. Якщо дочірній workflow перезапустили і він став +зеленим, перезапустіть лише батьківське завдання verifier, щоб оновити результат +umbrella і підсумок часу. Для відновлення `Full Release Validation` і `OpenClaw Release Checks` обидва приймають `rerun_group`. Використовуйте `all` для реліз-кандидата, `ci` лише для -звичайного повного дочірнього CI, `release-checks` для кожного дочірнього release або вужчу -релізну групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, -`qa-parity`, `qa-live` або `npm-telegram` в umbrella. Це утримує перезапуск невдалої -release box у межах після сфокусованого виправлення. +звичайного дочірнього full CI, `release-checks` для кожного релізного дочірнього +workflow або вужчу релізну групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, +`qa-parity`, `qa-live` або `npm-telegram` на umbrella. Це тримає перезапуск +невдалого релізного box обмеженим після сфокусованого виправлення. -Дочірній release live/E2E зберігає широке нативне покриття `pnpm test:live`, але +Дочірній live/E2E для релізу зберігає широке native-покриття `pnpm test:live`, але запускає його як іменовані шарди (`native-live-src-agents`, `native-live-src-gateway-core`, відфільтровані за provider завдання `native-live-src-gateway-profiles`, `native-live-src-gateway-backends`, `native-live-test`, `native-live-extensions-a-k`, `native-live-extensions-l-n`, `native-live-extensions-openai`, `native-live-extensions-o-z-other`, -`native-live-extensions-xai`, розділені audio/video шарди media, а також -відфільтровані за provider music шарди) через `scripts/test-live-shard.mjs` замість -одного послідовного завдання. Це зберігає те саме файлове покриття, водночас спрощуючи перезапуск -і діагностику повільних live-збоїв provider. Агреговані назви шардів -`native-live-extensions-o-z`, `native-live-extensions-media` і -`native-live-extensions-media-music` залишаються дійсними для ручних +`native-live-extensions-xai`, розділені audio/video-шарди media та +відфільтровані за provider шарди music) через `scripts/test-live-shard.mjs` +замість одного послідовного завдання. Це зберігає те саме файлове покриття, але +полегшує перезапуск і діагностику повільних збоїв live provider. Агреговані +назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і +`native-live-extensions-media-music` залишаються чинними для ручних одноразових перезапусків. -Нативні live media шарди запускаються в +Native live media-шарди запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow -`Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і -`ffprobe`; media-завдання лише перевіряють бінарні файли перед налаштуванням. Тримайте live-набори з підтримкою Docker -на звичайних Blacksmith runners, тому що container jobs не підходять -для запуску вкладених Docker-тестів. +`Live Media Runner Image`. Цей image попередньо встановлює `ffmpeg` і +`ffprobe`; media-завдання лише перевіряють binaries перед setup. Тримайте live-набори з Docker-підтримкою на звичайних Blacksmith runners, бо container jobs — неправильне місце для запуску вкладених Docker tests. -Live model/backend шарди з підтримкою Docker використовують окремий спільний -образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Live -release workflow один раз збирає та публікує цей образ, після чого Docker live model, -gateway, CLI backend, ACP bind і Codex harness шарди запускаються з -`OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці шарди незалежно перебудовують повну source Docker -ціль, release run налаштовано неправильно, і він марнуватиме час на дубльовані збірки образів. +Live model/backend-шарди з Docker-підтримкою використовують окремий спільний +image `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного commit. Live +release workflow збирає і публікує цей image один раз, потім Docker live model, +gateway, CLI backend, ACP bind і Codex harness-шарди запускаються з +`OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці шарди незалежно перебудовують повну +source Docker target, release run налаштовано неправильно, і він витратить wall +clock на дубльовані image builds. -`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране -посилання в tarball `release-package-under-test`, а потім передає цей артефакт -і в live/E2E release-path Docker workflow, і в шард package acceptance. -Це підтримує однаковість байтів пакета між release boxes і уникає -повторного пакування того самого кандидата в кількох дочірніх завданнях. +`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз +розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає +цей artifact і в live/E2E workflow релізного шляху для Docker, і в шард package acceptance. Це зберігає байти пакета узгодженими між release boxes і +уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. -`Package Acceptance` — це side-run workflow для валідації артефакта пакета +`Package Acceptance` — це side-run workflow для перевірки artifact пакета без блокування release workflow. Він розв’язує одного кандидата з -опублікованої npm-специфікації, довіреного `package_ref`, зібраного вибраним -`workflow_ref` harness, HTTPS URL tarball із SHA-256 або tarball-артефакта +опублікованої npm spec, trusted `package_ref`, зібраного з вибраним +`workflow_ref` harness, HTTPS tarball URL із SHA-256 або tarball artifact з іншого GitHub Actions run, завантажує його як `package-under-test`, а потім повторно використовує -Docker release/E2E scheduler із цим tarball замість повторного пакування -workflow checkout. Профілі охоплюють smoke, package, product, full і custom -вибір Docker-ліній. Профіль `package` використовує офлайн-покриття Plugin, щоб -валідація опублікованого пакета не залежала від доступності live ClawHub. Необов’язкова -Telegram-лінія повторно використовує артефакт -`package-under-test` у workflow `NPM Telegram Beta E2E`, а шлях -опублікованої npm-специфікації зберігається для окремих dispatch. +Docker release/E2E scheduler з цим tarball замість повторного пакування +workflow checkout. Профілі покривають smoke, package, product, full і custom +вибори Docker lanes. Профіль `package` використовує offline-покриття plugin, тому +перевірка опублікованого пакета не залежить від доступності live ClawHub. Опційний +напрямок Telegram повторно використовує artifact `package-under-test` у workflow `NPM Telegram Beta E2E`, а шлях +опублікованої npm spec зберігається для standalone dispatch. -## Приймання пакета +## Приймальне тестування пакета -Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей інстальований пакет OpenClaw -як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє -дерево вихідного коду, тоді як package acceptance перевіряє один tarball через -той самий Docker E2E harness, який користувачі задіюють після встановлення або оновлення. +Використовуйте `Package Acceptance`, коли питання звучить як «чи працює цей встановлюваний пакет OpenClaw +як продукт?» Це відрізняється від звичайної CI: звичайна CI перевіряє +дерево source, тоді як package acceptance перевіряє один tarball через той самий +Docker E2E harness, який користувачі задіюють після встановлення або оновлення. -Робочий процес має чотири завдання: +Workflow має чотири завдання: -1. `resolve_package` отримує `workflow_ref`, визначає одного кандидата пакета, +1. `resolve_package` checkout-ить `workflow_ref`, розв’язує одного package-кандидата, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує - `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як - артефакт `package-under-test` і виводить джерело, workflow ref, package - ref, версію, SHA-256 та профіль у зведенні кроку GitHub. + `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як artifact + `package-under-test` і друкує source, workflow ref, package + ref, version, SHA-256 і profile у GitHub step summary. 2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і - `package_artifact_name=package-under-test`. Перевикористовуваний робочий процес завантажує - цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи - package-digest і запускає вибрані Docker-напрями для цього - пакета замість пакування checkout робочого процесу. Коли профіль вибирає - кілька цільових `docker_lanes`, перевикористовуваний робочий процес готує пакет - і спільні образи один раз, а потім розгортає ці напрями як паралельні цільові Docker - завдання з унікальними артефактами. -3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він запускається, коли - `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, - коли Приймання пакета визначило один; автономний Telegram dispatch - усе ще може встановити опубліковану npm-специфікацію. -4. `summary` завершує робочий процес помилкою, якщо визначення пакета, Docker-приймання або - необов’язковий Telegram-напрям зазнали невдачі. + `package_artifact_name=package-under-test`. Reusable workflow завантажує + цей artifact, перевіряє інвентар tarball, готує package-digest + Docker images за потреби та запускає вибрані Docker lanes проти цього + package замість пакування workflow checkout. Коли профіль вибирає + кілька цільових `docker_lanes`, reusable workflow готує package + і спільні images один раз, а потім розгортає ці lanes як паралельні цільові Docker + jobs з унікальними artifacts. +3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли + `telegram_mode` не є `none`, і встановлює той самий artifact `package-under-test`, + якщо Package Acceptance розв’язав його; standalone Telegram dispatch + все ще може встановити опубліковану npm spec. +4. `summary` провалює workflow, якщо package resolution, Docker acceptance або + опційний Telegram lane завершилися невдало. Джерела кандидатів: - `source=npm`: приймає лише `openclaw@beta`, `openclaw@latest` або точну - версію релізу OpenClaw, як-от `openclaw@2026.4.27-beta.2`. Використовуйте це для - приймання опублікованих beta/stable. -- `source=ref`: пакує довірені гілку, тег або повний SHA коміту `package_ref`. - Розв’язувач отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт - досяжний з історії гілки репозиторію або релізного тегу, встановлює залежності у - від’єднаному worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. + release-версію OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для + acceptance опублікованих beta/stable. +- `source=ref`: пакує trusted `package_ref` branch, tag або повний commit SHA. + Resolver fetch-ить branches/tags OpenClaw, перевіряє, що вибраний commit + досяжний з repository branch history або release tag, встановлює deps у + detached worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. - `source=url`: завантажує HTTPS `.tgz`; `package_sha256` обов’язковий. - `source=artifact`: завантажує один `.tgz` з `artifact_run_id` і - `artifact_name`; `package_sha256` необов’язковий, але його варто надати для - артефактів, якими діляться зовні. + `artifact_name`; `package_sha256` опційний, але його варто надати для + artifact, поширених зовні. -Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений -код робочого процесу/оснастки, який запускає тест. `package_ref` — це вихідний коміт, -який пакується, коли `source=ref`. Це дає змогу поточній тестовій оснастці перевіряти -старіші довірені вихідні коміти без запуску старої логіки робочого процесу. +Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це trusted +код workflow/harness, який запускає test. `package_ref` — це source commit, +який пакують, коли `source=ref`. Це дозволяє поточному test harness перевіряти +старіші trusted source commits без запуску старої workflow logic. Профілі відповідають Docker-покриттю: @@ -145,38 +142,37 @@ Telegram-лінія повторно використовує артефакт `plugin-update` - `product`: `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` -- `full`: повні фрагменти Docker release-path з OpenWebUI +- `full`: повні chunks релізного Docker-шляху з OpenWebUI - `custom`: точні `docker_lanes`; обов’язково, коли `suite_profile=custom` -Перевірки релізу викликають Приймання пакета з `source=ref`, +Release checks викликають Package Acceptance з `source=ref`, `package_ref=`, `workflow_ref=`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` і -`telegram_mode=mock-openai`. Docker-фрагменти release-path -покривають перетин напрямів package/update/plugin, тоді як Приймання пакета -зберігає artifact-native доказ сумісності bundled-channel, офлайн-Plugin і -Telegram для того самого визначеного tarball пакета. -Перевірки релізу Cross-OS і далі покривають специфічні для ОС onboarding, інсталятор і -поведінку платформи; перевірку продукту package/update слід починати з Приймання -пакета. Напрями Windows packaged та installer fresh також перевіряють, що -встановлений пакет може імпортувати перевизначення browser-control із сирого абсолютного -шляху Windows. +`telegram_mode=mock-openai`. Docker +chunks релізного шляху покривають перетин package/update/plugin lanes, тоді як Package +Acceptance зберігає artifact-native доказ bundled-channel compat, offline plugin і +Telegram проти того самого розв’язаного package tarball. +Cross-OS release checks і далі покривають OS-специфічне onboarding, installer і +platform behavior; product-перевірку package/update слід починати з Package +Acceptance. Windows packaged і installer fresh lanes також перевіряють, що +встановлений package може імпортувати browser-control override з сирого absolute +Windows path. -Приймання пакета має обмежені вікна зворотної сумісності для вже -опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, -можуть використовувати шлях сумісності для відомих приватних QA-записів у -`dist/postinstall-inventory.json`, які вказують на файли, пропущені з tarball; -`doctor-switch` може пропустити підвипадок збереження `gateway install --wrapper`, -коли пакет не надає цей прапор, `update-channel-switch` може вилучити -відсутні `pnpm.patchedDependencies` з фальшивої git-фікстури, похідної від tarball, і -може логувати відсутній збережений `update.channel`, plugin smoke-тести можуть читати -застарілі розташування install-record або приймати відсутність збереження marketplace -install-record, а `plugin-update` може дозволяти міграцію метаданих конфігурації, водночас -і далі вимагаючи, щоб запис встановлення та поведінка без перевстановлення залишалися -незмінними. Опублікований пакет `2026.4.26` також може попереджати про локальні -файли міток метаданих збірки, які вже були доставлені. Пізніші пакети мають -відповідати сучасним контрактам; ті самі умови спричиняють помилку замість попередження -або пропуску. +Package Acceptance має обмежені вікна legacy-сумісності для вже +опублікованих packages. Packages до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, +можуть використовувати compatibility path для відомих private QA entries у +`dist/postinstall-inventory.json`, які вказують на файли, omitted from tarball, +`doctor-switch` може пропустити підвипадок persistence `gateway install --wrapper`, +коли package не expose-ить цей flag, `update-channel-switch` може prune-ити +відсутні `pnpm.patchedDependencies` з fake git fixture, отриманої з tarball, і +може логувати відсутній persisted `update.channel`, plugin smokes можуть читати legacy +install-record locations або приймати відсутню marketplace install-record +persistence, а `plugin-update` може дозволити config metadata migration, усе ще +вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними. Опублікований +package `2026.4.26` також може попереджати про local build metadata stamp files, +які вже було shipped. Пізніші packages мають відповідати сучасним contracts; ті +самі умови дають failure замість warn або skip. Приклади: @@ -219,23 +215,121 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Під час налагодження невдалого запуску приймання пакета починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lanes, таймінги фаз і команди повторного запуску. Віддавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes замість повторного запуску повної валідації релізу. +Під час налагодження невдалого запуску приймання пакета починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: +`.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали смуг, часові +показники фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або +точних Docker-смуг замість повторного запуску повної перевірки релізу. -QA Lab має окремі CI lanes поза основним smart-scoped workflow. Workflow `Parity gate` запускається для відповідних змін у PR і manual dispatch; він збирає приватний QA runtime і порівнює mock GPT-5.5 та Opus 4.6 агентні пакети. Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і через manual dispatch; він розгортає mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases. Release checks запускають Matrix і Telegram live transport lanes з deterministic mock provider і mock-qualified models (`mock-openai/gpt-5.5` та `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live model і звичайного запуску плагіна провайдера. Live transport gateway також вимикає пошук у пам’яті, оскільки QA parity покриває поведінку пам’яті окремо; підключення провайдерів покривається окремими наборами live model, native provider і Docker provider. Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише тоді, коли це підтримує поточний checked-out CLI. Значення CLI за замовчуванням і manual workflow input лишаються `all`; manual `matrix_profile=all` dispatch завжди розбиває повне покриття Matrix на завдання `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед схваленням релізу; його QA parity gate запускає candidate і baseline packs як паралельні lane-завдання, а потім завантажує обидва артефакти в невелике report-завдання для фінального parity-порівняння. Не ставте шлях landing PR за `Parity gate`, якщо зміна насправді не зачіпає QA runtime, parity model-pack або поверхню, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-тестів розглядайте це як необов’язковий сигнал і спирайтеся на scoped CI/check evidence. +QA Lab має окремі смуги CI поза основним workflow із розумним визначенням області. Workflow +`Parity gate` запускається для відповідних змін у PR і вручну; він +збирає приватне середовище виконання QA та порівнює мокові агентні набори GPT-5.5 і Opus 4.6. +Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і +вручну; він розгортає моковий parity gate, живу смугу Matrix, а також живі +смуги Telegram і Discord як паралельні завдання. Живі завдання використовують середовище +`qa-live-shared`, а Telegram/Discord використовують оренди Convex. Перевірки релізу запускають +живі транспортні смуги Matrix і Telegram з детермінованим моковим +провайдером і моделями з мок-кваліфікацією (`mock-openai/gpt-5.5` і +`mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки живої моделі +та звичайного запуску Plugin провайдера. Живий транспортний Gateway також +вимикає пошук у пам’яті, оскільки parity QA окремо покриває поведінку пам’яті; +підключення провайдера покривають окремі набори для живої моделі, нативного провайдера +та Docker-провайдера. Matrix використовує `--profile fast` для запланованих і релізних gates, +додаючи `--fail-fast` лише тоді, коли CLI з checkout це підтримує. Типове значення CLI +і ручний ввід workflow залишаються `all`; ручний dispatch `matrix_profile=all` +завжди шардить повне покриття Matrix на завдання `transport`, `media`, +`e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` також +запускає критично важливі для релізу смуги QA Lab перед схваленням релізу; його QA parity +gate запускає кандидатний і базовий набори як паралельні завдання смуг, потім завантажує +обидва артефакти в невелике завдання звіту для фінального порівняння parity. +Не ставте шлях landing PR за `Parity gate`, якщо зміна фактично не +торкається середовища виконання QA, parity наборів моделей або поверхні, якою володіє parity workflow. +Для звичайних виправлень каналів, конфігурації, документації або юніт-тестів сприймайте це як необов’язковий +сигнал і дотримуйтеся доказів scoped CI/check. -Workflow `Duplicate PRs After Merge` — це manual maintainer workflow для очищення дублікатів після landing. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR об’єднано, і що кожен дублікат має або спільну referenced issue, або перетин змінених hunks. +Workflow `Duplicate PRs After Merge` — це ручний workflow мейнтейнера для +очищення дублікатів після landing. Типово він працює в dry-run і закриває лише явно +перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що +landed PR змерджено і що кожен дублікат має або спільне згадане issue, +або перекривні змінені hunks. -Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним скануванням репозиторію. Щоденні й ручні запуски сканують код Actions workflow плюс найбільш ризиковані JavaScript/TypeScript поверхні auth, secrets, sandbox, cron і gateway за допомогою high-precision security queries. Завдання channel-runtime-boundary окремо сканує контракти реалізації core channel плюс channel plugin runtime, gateway, Plugin SDK, secrets і audit touchpoints у категорії `/codeql-critical-security/channel-runtime-boundary`, щоб security-сигнал каналу міг масштабуватися без розширення базової JS/TS категорії. +Workflow `CodeQL` навмисно є вузьким сканером безпеки першого проходу, +а не повним скануванням репозиторію. Щоденні й ручні запуски сканують код workflow Actions +плюс найризикованіші поверхні JavaScript/TypeScript для auth, secrets, sandbox, cron і +gateway за допомогою високоточних security queries. Завдання +channel-runtime-boundary окремо сканує контракти реалізації core channel +плюс середовище виконання Plugin каналу, gateway, Plugin SDK, secrets і +audit touchpoints у категорії `/codeql-critical-security/channel-runtime-boundary`, +щоб сигнал безпеки каналів міг масштабуватися без розширення базової +категорії JS/TS. -Workflow `CodeQL Android Critical Security` — це scheduled Android security shard. Він вручну збирає Android app для CodeQL на найменшій Blacksmith Linux runner label, яку приймає workflow sanity, і завантажує результати в категорію `/codeql-critical-security/android`. +Workflow `CodeQL Android Critical Security` — це запланований Android +security shard. Він вручну збирає Android-застосунок для CodeQL на найменшому +лейблі Blacksmith Linux runner, прийнятому workflow sanity, і завантажує результати +в категорію `/codeql-critical-security/android`. -Workflow `CodeQL macOS Critical Security` — це щотижневий/manual macOS security shard. Він вручну збирає macOS app для CodeQL на Blacksmith macOS, відфільтровує результати dependency build із завантаженого SARIF і завантажує результати в категорію `/codeql-critical-security/macos`. Тримайте його поза щоденним workflow за замовчуванням, бо macOS build домінує в runtime навіть коли він clean. +Workflow `CodeQL macOS Critical Security` — це щотижневий/ручний macOS +security shard. Він вручну збирає macOS-застосунок для CodeQL на Blacksmith macOS, +відфільтровує результати збірки залежностей із завантаженого SARIF і завантажує результати +в категорію `/codeql-critical-security/macos`. Тримайте його поза щоденним +типовим workflow, бо збірка macOS домінує за часом виконання навіть коли вона чиста. -Workflow `CodeQL Critical Quality` — це відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries на вузьких high-value поверхнях на меншому Blacksmith Linux runner. Його завдання core-auth-secrets сканує auth, secrets, sandbox, cron і gateway security boundary code в окремій категорії `/codeql-critical-quality/core-auth-secrets`. Завдання config-boundary сканує config schema, migration, normalization і IO contracts в окремій категорії `/codeql-critical-quality/config-boundary`. Завдання gateway-runtime-boundary сканує gateway protocol schemas і server method contracts в окремій категорії `/codeql-critical-quality/gateway-runtime-boundary`. Завдання channel-runtime-boundary сканує core channel implementation contracts в окремій категорії `/codeql-critical-quality/channel-runtime-boundary`. Завдання agent-runtime-boundary сканує command execution, model/provider dispatch, auto-reply dispatch і queues, а також ACP control-plane runtime contracts в окремій категорії `/codeql-critical-quality/agent-runtime-boundary`. Завдання mcp-process-runtime-boundary сканує MCP servers і tool bridges, process supervision helpers та outbound delivery contracts в окремій категорії `/codeql-critical-quality/mcp-process-runtime-boundary`. Завдання memory-runtime-boundary сканує memory host SDK, memory runtime facades, memory Plugin SDK aliases, memory runtime activation glue і memory doctor commands в окремій категорії `/codeql-critical-quality/memory-runtime-boundary`. Завдання ui-control-plane сканує Control UI bootstrap, local persistence, gateway control flows і task control-plane runtime contracts в окремій категорії `/codeql-critical-quality/ui-control-plane`. Завдання web-media-runtime-boundary сканує core web fetch/search, media IO, media understanding, image-generation і media-generation runtime contracts в окремій категорії `/codeql-critical-quality/web-media-runtime-boundary`. Завдання plugin-boundary сканує loader, registry, public-surface і Plugin SDK entrypoint contracts в окремій категорії `/codeql-critical-quality/plugin-boundary`. Тримайте workflow окремо від security, щоб quality findings можна було планувати, вимірювати, вимикати або розширювати без затемнення security-сигналу. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як scoped або sharded follow-up work лише після того, як вузькі профілі матимуть стабільні runtime і signal. +Workflow `CodeQL Critical Quality` — це відповідний shard не для безпеки. Він +запускає лише JavaScript/TypeScript quality queries із severity error та без security +на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його +завдання core-auth-secrets сканує код меж auth, secrets, sandbox, cron і gateway security +в окремій категорії `/codeql-critical-quality/core-auth-secrets`. Завдання config-boundary +сканує схему конфігурації, міграцію, нормалізацію та контракти IO в +окремій категорії `/codeql-critical-quality/config-boundary`. Завдання +gateway-runtime-boundary сканує схеми протоколу gateway і контракти server method +в окремій категорії +`/codeql-critical-quality/gateway-runtime-boundary`. Завдання +channel-runtime-boundary сканує контракти реалізації core channel в +окремій категорії `/codeql-critical-quality/channel-runtime-boundary`. Завдання +agent-runtime-boundary сканує виконання команд, dispatch моделей/провайдерів, +dispatch і черги auto-reply, а також контракти runtime control-plane ACP в +окремій категорії `/codeql-critical-quality/agent-runtime-boundary`. Завдання +mcp-process-runtime-boundary сканує MCP servers і tool bridges, helpers supervision процесів +та контракти outbound delivery в окремій категорії +`/codeql-critical-quality/mcp-process-runtime-boundary`. Завдання +memory-runtime-boundary сканує memory host SDK, memory runtime facades, +аліаси memory Plugin SDK, зв’язувальний код активації memory runtime і команди memory doctor +в окремій категорії `/codeql-critical-quality/memory-runtime-boundary`. +Завдання ui-control-plane сканує bootstrap Control UI, локальне збереження, control flows gateway +і runtime-контракти task control-plane в окремій категорії +`/codeql-critical-quality/ui-control-plane`. Завдання +web-media-runtime-boundary сканує core web fetch/search, media IO, media +understanding, image-generation і media-generation runtime contracts в +окремій категорії `/codeql-critical-quality/web-media-runtime-boundary`. Завдання +plugin-boundary сканує контракти loader, registry, public-surface і entrypoint Plugin SDK +в окремій категорії `/codeql-critical-quality/plugin-boundary`. +Тримайте workflow окремо від security, щоб quality findings можна було +планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. +Розширення CodeQL для Swift, Python і bundled-Plugin слід додавати назад як +scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний +час виконання та сигнал. -Workflow `Docs Agent` — це event-driven Codex maintenance lane для підтримання наявної документації узгодженою з нещодавно landing-змінами. Він не має pure schedule: успішний non-bot push CI run на `main` може його запустити, а manual dispatch може запускати його напряму. Workflow-run invocations пропускаються, коли `main` уже зрушив далі або коли інший non-skipped Docs Agent run було створено за останню годину. Коли він запускається, він переглядає діапазон комітів від попереднього non-skipped Docs Agent source SHA до поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені з останнього docs pass. +Workflow `Docs Agent` — це подієво-керована смуга обслуговування Codex для підтримання +наявної документації в узгодженому стані з нещодавно landing-змінами. Він не має чистого розкладу: +успішний non-bot push CI run на `main` може його запустити, а manual dispatch може +запустити його напряму. Workflow-run invocations пропускаються, коли `main` просунувся далі або коли +інший non-skipped запуск Docs Agent було створено за останню годину. Коли він запускається, він +переглядає діапазон комітів від попереднього non-skipped source SHA Docs Agent до +поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені з +останнього проходу документації. -Workflow `Test Performance Agent` — це event-driven Codex maintenance lane для повільних тестів. Він не має pure schedule: успішний non-bot push CI run на `main` може його запустити, але він пропускається, якщо інший workflow-run invocation уже запускався або виконується цього UTC дня. Manual dispatch обходить цей daily activity gate. Lane збирає full-suite grouped Vitest performance report, дозволяє Codex вносити лише невеликі coverage-preserving test performance fixes замість широких рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, що зменшують passing baseline test count. Якщо baseline має failing tests, Codex може виправляти лише очевидні failures, а after-agent full-suite report має пройти перед будь-яким комітом. Коли `main` просувається до того, як bot push landing, lane rebase-ить validated patch, повторно запускає `pnpm check:changed` і повторює push; conflicting stale patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб Codex action міг зберегти ту саму drop-sudo safety posture, що й docs agent. +Workflow `Test Performance Agent` — це подієво-керована смуга обслуговування Codex +для повільних тестів. Він не має чистого розкладу: успішний non-bot push CI run на +`main` може його запустити, але він пропускається, якщо інший workflow-run invocation уже +запускався або виконується того UTC дня. Manual dispatch обходить цей щоденний gate активності. +Смуга будує full-suite grouped Vitest performance report, дозволяє Codex +робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких +рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, що зменшують +базову кількість успішних тестів. Якщо baseline має failing tests, Codex може виправляти +лише очевидні failures, і after-agent full-suite report має пройти, перш ніж +щось буде закомічено. Коли `main` просувається до landing bot push, смуга +rebase-ить перевірений patch, повторно запускає `pnpm check:changed` і повторює push; +конфліктні застарілі patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб action Codex +міг зберегти ту саму drop-sudo safety posture, що й docs agent. ```bash gh workflow run duplicate-after-merge.yml \ @@ -248,28 +342,42 @@ gh workflow run duplicate-after-merge.yml \ | Завдання | Призначення | Коли запускається | | -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- | -| `preflight` | Виявляє docs-only changes, changed scopes, changed extensions і будує CI manifest | Завжди для non-draft pushes і PRs | +| `preflight` | Виявляє docs-only зміни, змінені області, змінені Plugins і будує маніфест CI | Завжди для non-draft pushes і PRs | | `security-scm-fast` | Виявлення приватних ключів і audit workflow через `zizmor` | Завжди для non-draft pushes і PRs | -| `security-dependency-audit` | Dependency-free production lockfile audit щодо npm advisories | Завжди для non-draft pushes і PRs | -| `security-fast` | Обов’язковий aggregate для fast security jobs | Завжди для non-draft pushes і PRs | -| `build-artifacts` | Збирає `dist/`, Control UI, built-artifact checks і reusable downstream artifacts | Node-relevant changes | -| `checks-fast-core` | Fast Linux correctness lanes, як-от bundled/plugin-contract/protocol checks | Node-relevant changes | +| `security-dependency-audit` | Production lockfile audit без залежностей за npm advisories | Завжди для non-draft pushes і PRs | +| `security-fast` | Обов’язковий aggregate для швидких security jobs | Завжди для non-draft pushes і PRs | +| `build-artifacts` | Збірка `dist/`, Control UI, built-artifact checks і reusable downstream artifacts | Node-relevant changes | +| `checks-fast-core` | Швидкі Linux correctness lanes, як-от bundled/plugin-contract/protocol checks | Node-relevant changes | | `checks-fast-contracts-channels` | Sharded channel contract checks зі стабільним aggregate check result | Node-relevant changes | -| `checks-node-core-test` | Core Node test shards, крім channel, bundled, contract і extension lanes | Node-relevant changes | -| `check` | Sharded main local gate equivalent: prod types, lint, guards, test types і strict smoke | Node-relevant changes | +| `checks-node-core-test` | Core Node test shards, за винятком channel, bundled, contract і extension lanes | Node-relevant changes | +| `check` | Sharded еквівалент основного local gate: prod types, lint, guards, test types і strict smoke | Node-relevant changes | | `check-additional` | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards | Node-relevant changes | | `build-smoke` | Built-CLI smoke tests і startup-memory smoke | Node-relevant changes | | `checks` | Verifier для built-artifact channel tests | Node-relevant changes | | `checks-node-compat-node22` | Node 22 compatibility build і smoke lane | Manual CI dispatch for releases | | `check-docs` | Docs formatting, lint і broken-link checks | Docs changed | | `skills-python` | Ruff + pytest для Python-backed skills | Python-skill-relevant changes | -| `checks-windows` | Windows-specific process/path tests плюс shared runtime import specifier regressions | Windows-relevant changes | -| `macos-node` | macOS TypeScript test lane із використанням shared built artifacts | macOS-relevant changes | +| `checks-windows` | Windows-specific process/path tests плюс regressions shared runtime import specifier | Windows-relevant changes | +| `macos-node` | macOS TypeScript test lane з використанням спільних built artifacts | macOS-relevant changes | | `macos-swift` | Swift lint, build і tests для macOS app | macOS-relevant changes | | `android` | Android unit tests для обох flavors плюс одна debug APK build | Android-relevant changes | -| `test-performance-agent` | Daily Codex slow-test optimization після trusted activity | Main CI success або manual dispatch | +| `test-performance-agent` | Щоденна Codex slow-test optimization після trusted activity | Main CI success or manual dispatch | -Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну scoped lane, крім Android: шарди Linux Node, шарди плагінів у комплекті, контракти каналів, сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python Skills, Windows, macOS і Control UI i18n. Окремі ручні запуски CI виконують лише Android із `include_android=true`; повна парасолька релізу вмикає Android, передаючи `include_android=true`. Статичні перевірки передрелізу Plugin, релізний шард `agentic-plugins`, повний batch sweep розширень і Docker lanes передрелізу плагінів виключені з CI. Набір передрелізних перевірок Docker запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate перевірки релізу. Ручні запуски використовують унікальну групу concurrency, щоб повний набір release candidate не скасовувався іншим push або запуском PR на тому самому ref. Необов’язковий input `target_ref` дає змогу довіреному виклику запустити цей граф для гілки, тегу або повного SHA коміту, використовуючи файл workflow з вибраного dispatch ref. +Manual CI-диспетчеризації виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну +не-Android scoped lane: шарди Linux Node, шарди bundled-plugin, channel +contracts, сумісність Node 22, `check`, `check-additional`, build smoke, перевірки docs, +Python Skills, Windows, macOS і Control UI i18n. Окремі manual CI +dispatches запускають лише Android із `include_android=true`; повна release +umbrella вмикає Android, передаючи `include_android=true`. Статичні перевірки prerelease для Plugin, +release-only шард `agentic-plugins`, повний batch sweep для extension +і Docker lanes для prerelease Plugin виключені з CI. Docker +prerelease suite запускається лише тоді, коли `Full Release Validation` диспетчеризує +окремий workflow `Plugin Prerelease` з увімкненим gate release-validation. +Manual runs використовують +унікальну concurrency group, щоб повний suite release-candidate не скасовувався +іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає +довіреному викликачеві змогу запускати цей граф для branch, tag або повного commit SHA, водночас +використовуючи файл workflow з вибраного dispatch ref. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -279,62 +387,63 @@ gh workflow run full-release-validation.yml --ref main -f ref= ## Порядок fail-fast -Завдання впорядковано так, щоб дешеві перевірки падали до запуску дорогих: +Jobs упорядковані так, щоб дешеві перевірки падали до запуску дорогих: -1. `preflight` вирішує, які lanes взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями. -2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи на важчі матричні завдання для артефактів і платформ. -3. `build-artifacts` перекривається зі швидкими Linux lanes, щоб downstream-споживачі могли стартувати щойно спільний build буде готовий. -4. Після цього розгалужуються важчі platform і runtime lanes: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +1. `preflight` визначає, які lanes взагалі існують. Логіка `docs-scope` і `changed-scope` є steps всередині цього job, а не окремими jobs. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи важчих artifact і platform matrix jobs. +3. `build-artifacts` перекривається зі швидкими Linux lanes, щоб downstream consumers могли стартувати щойно спільна build буде готова. +4. Важчі platform і runtime lanes розгалужуються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. Логіка scope міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. -Ручний dispatch пропускає виявлення changed-scope і змушує manifest preflight діяти так, ніби кожна scoped area змінилася. -Редагування CI workflow перевіряють граф Node CI плюс workflow linting, але самі по собі не примушують запускати нативні builds Windows, Android або macOS; ці platform lanes залишаються scoped до змін у platform source. -Редагування лише маршрутизації CI, вибрані дешеві редагування core-test fixtures, а також вузькі редагування plugin contract helper/test-routing використовують швидкий шлях manifest лише для Node: preflight, security і одне завдання `checks-fast-core`. Цей шлях оминає build artifacts, сумісність із Node 22, контракти каналів, повні core shards, bundled-plugin shards і додаткові guard matrices, коли змінені файли обмежені routing або helper surfaces, які fast task перевіряє напряму. -Windows Node checks обмежені Windows-specific process/path wrappers, npm/pnpm/UI runner helpers, package manager config і поверхнями CI workflow, які виконують цю lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes, щоб вони не резервували 16-vCPU Windows worker для покриття, яке вже перевіряється звичайними test shards. -Окремий workflow `install-smoke` повторно використовує той самий scope script через власне завдання `preflight`. Він розділяє smoke coverage на `run_fast_install_smoke` і `run_full_install_smoke`. Pull requests запускають fast path для Docker/package surfaces, змін package/manifest плагінів у комплекті, а також core plugin/channel/gateway/Plugin SDK surfaces, які перевіряють Docker smoke jobs. Source-only changes у плагінах у комплекті, test-only edits і docs-only edits не резервують Docker workers. Fast path один раз збирає image з root Dockerfile, перевіряє CLI, запускає agents delete shared-workspace CLI smoke, запускає container gateway-network e2e, перевіряє bundled extension build arg і запускає обмежений bundled-plugin Docker profile під 240-секундним aggregate command timeout, причому Docker run кожного scenario обмежений окремо. Full path зберігає QR package install і installer Docker/update coverage для нічних scheduled runs, manual dispatches, workflow-call release checks і pull requests, які справді зачіпають installer/package/Docker surfaces. Pushes у `main`, включно з merge commits, не примушують full path; коли логіка changed-scope запитала б full coverage на push, workflow залишає fast Docker smoke, а full install smoke лишає для nightly або release validation. Повільний Bun global install image-provider smoke окремо gated через `run_bun_global_install_smoke`; він запускається за nightly schedule і з workflow release checks, а manual `install-smoke` dispatches можуть opt in до нього, але pull requests і pushes у `main` його не запускають. QR і installer Docker tests зберігають власні install-focused Dockerfiles. Локальний `test:docker:all` попередньо збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні images `scripts/e2e/Dockerfile`: bare Node/Git runner для installer/update/plugin-dependency lanes і functional image, який встановлює той самий tarball у `/app` для normal functionality lanes. Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`, planner logic міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний plan. Scheduler вибирає image для кожної lane через `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте default main-pool slot count 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а provider-sensitive tail-pool slot count 10 через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Heavy lane caps за замовчуванням мають значення `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб npm install і multi-service lanes не перевантажували Docker, поки легші lanes усе ще заповнюють доступні slots. Одна lane, важча за effective caps, усе ще може стартувати з порожнього pool, а потім виконується сама, доки не звільнить capacity. Запуски lanes за замовчуванням staggered на 2 секунди, щоб уникнути local Docker daemon create storms; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний aggregate preflights Docker, видаляє застарілі OpenClaw E2E containers, виводить active-lane status, зберігає lane timings для longest-first ordering і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для inspection scheduler. Він за замовчуванням припиняє планувати нові pooled lanes після першої failure, і кожна lane має 120-minute fallback timeout, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; вибрані live/tail lanes використовують жорсткіші per-lane caps. `OPENCLAW_DOCKER_ALL_LANES=` запускає exact scheduler lanes, включно з release-only lanes, як-от `install-e2e`, і split bundled update lanes, як-от `bundled-channel-update-acpx`, водночас пропускаючи cleanup smoke, щоб agents могли відтворити одну failed lane. Reusable live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке package, image kind, live image, lane і credential coverage потрібні, а потім `scripts/docker-e2e.mjs` перетворює цей plan на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного run, або завантажує package artifact із `package_artifact_run_id`; перевіряє tarball inventory; збирає й push-ить package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли plan потребує package-installed lanes; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або existing package-digest images замість rebuild. Workflow `Package Acceptance` є high-level package gate: він resolves candidate з npm, довіреного `package_ref`, HTTPS tarball плюс SHA-256 або artifact попереднього workflow, а потім передає цей єдиний artifact `package-under-test` у reusable Docker E2E workflow. Він тримає `workflow_ref` окремо від `package_ref`, щоб поточна acceptance logic могла перевіряти старіші trusted commits без checkout старого workflow code. Release checks запускають custom Package Acceptance delta для target ref: bundled-channel compat, offline plugin fixtures і Telegram package QA against resolved tarball. Release-path Docker suite запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk тягнув лише потрібний image kind і виконував кілька lanes через той самий weighted scheduler (`OPENCLAW_DOCKER_ALL_PROFILE=release-path`, `OPENCLAW_DOCKER_ALL_CHUNK=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|bundled-channels`). OpenWebUI включено до `plugins-runtime-services`, коли full release-path coverage цього вимагає, і він зберігає standalone chunk `openwebui` лише для OpenWebUI-only dispatches. Legacy aggregate chunk names `package-update`, `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` все ще працюють для manual reruns, але release workflow використовує split chunks, щоб installer E2E і bundled plugin install/uninstall sweeps не домінували на critical path. Alias lane `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes. Chunk `bundled-channels` запускає split lanes `bundled-channel-*` і `bundled-channel-update-*`, а не serial all-in-one lane `bundled-channel-deps`. Кожен chunk uploads `.artifacts/docker-tests/` з lane logs, timings, `summary.json`, `failures.json`, phase timings, scheduler plan JSON, slow-lane tables і per-lane rerun commands. Input workflow `docker_lanes` запускає selected lanes against prepared images замість chunk jobs, що утримує debugging failed-lane в межах одного targeted Docker job і prepares, downloads або reuses package artifact для цього run; якщо selected lane є live Docker lane, targeted job локально збирає live-test image для цього rerun. Generated per-lane GitHub rerun commands містять `package_artifact_run_id`, `package_artifact_name` і prepared image inputs, коли ці values існують, тож failed lane може повторно використати exact package і images з failed run. Використовуйте `pnpm test:docker:rerun `, щоб завантажити Docker artifacts із GitHub run і вивести combined/per-lane targeted rerun commands; використовуйте `pnpm test:docker:timings ` для slow-lane і phase critical-path summaries. Scheduled live/E2E workflow щодня запускає full release-path Docker suite. Bundled update matrix розділено за update target, щоб повторні npm update і doctor repair passes могли shard з іншими bundled checks. +Manual dispatch пропускає changed-scope detection і змушує preflight manifest +діяти так, ніби кожна scoped area змінилася. +Редагування CI workflow перевіряють граф Node CI плюс workflow linting, але самі по собі не примушують запускати нативні builds Windows, Android або macOS; ці platform lanes залишаються scoped до змін platform source. +CI routing-only edits, вибрані дешеві core-test fixture edits і вузькі plugin contract helper/test-routing edits використовують швидкий Node-only manifest path: preflight, security і одне завдання `checks-fast-core`. Цей path уникає build artifacts, сумісності Node 22, channel contracts, повних core shards, bundled-plugin shards і додаткових guard matrices, коли змінені файли обмежені routing або helper surfaces, які швидке завдання перевіряє безпосередньо. +Windows Node checks scoped до Windows-specific process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цю lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes, щоб вони не резервували 16-vCPU Windows worker для coverage, який уже перевіряється звичайними test shards. +Окремий workflow `install-smoke` повторно використовує той самий scope script через власний job `preflight`. Він розділяє smoke coverage на `run_fast_install_smoke` і `run_full_install_smoke`. Pull requests запускають fast path для Docker/package surfaces, змін bundled plugin package/manifest, а також core plugin/channel/gateway/Plugin SDK surfaces, які перевіряють Docker smoke jobs. Source-only зміни bundled plugin, test-only edits і docs-only edits не резервують Docker workers. Fast path один раз збирає образ root Dockerfile, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє bundled extension build arg і запускає обмежений bundled-plugin Docker profile під сукупним command timeout 240 секунд, причому Docker run кожного scenario обмежений окремо. Full path залишає QR package install і installer Docker/update coverage для nightly scheduled runs, manual dispatches, workflow-call release checks і pull requests, які справді торкаються installer/package/Docker surfaces. Pushes у `main`, зокрема merge commits, не примушують full path; коли changed-scope logic запросила б full coverage на push, workflow залишає fast Docker smoke і передає full install smoke nightly або release validation. Повільний Bun global install image-provider smoke окремо gate-иться через `run_bun_global_install_smoke`; він запускається за nightly schedule і з release checks workflow, а manual `install-smoke` dispatches можуть увімкнути його, але pull requests і pushes у `main` його не запускають. QR і installer Docker tests зберігають власні install-focused Dockerfiles. Локальний `test:docker:all` попередньо збирає один спільний live-test image, пакує OpenClaw один раз як npm tarball і збирає два спільні images `scripts/e2e/Dockerfile`: bare Node/Git runner для installer/update/plugin-dependency lanes і functional image, який встановлює той самий tarball у `/app` для normal functionality lanes. Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`, planner logic міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний plan. Scheduler вибирає image для lane за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштуйте стандартну main-pool slot count 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM` і provider-sensitive tail-pool slot count 10 через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Heavy lane caps за замовчуванням мають значення `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб npm install і multi-service lanes не перенавантажували Docker, тоді як легші lanes усе ще заповнюють доступні slots. Одна lane, важча за effective caps, усе одно може стартувати з порожнього pool, а потім виконується самостійно, доки не звільнить capacity. Запуски lanes за замовчуванням рознесені на 2 секунди, щоб уникати локальних Docker daemon create storms; перевизначте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний aggregate preflights Docker, видаляє застарілі OpenClaw E2E containers, виводить active-lane status, зберігає lane timings для longest-first ordering і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для перевірки scheduler. Він за замовчуванням припиняє планувати нові pooled lanes після першої failure, і кожна lane має fallback timeout 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; вибрані live/tail lanes використовують жорсткіші per-lane caps. `OPENCLAW_DOCKER_ALL_LANES=` запускає точні scheduler lanes, зокрема release-only lanes, як-от `install-e2e`, і split bundled update lanes, як-от `bundled-channel-update-acpx`, пропускаючи cleanup smoke, щоб agents могли відтворити одну failed lane. Reusable live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, які package, image kind, live image, lane і credential coverage потрібні, потім `scripts/docker-e2e.mjs` перетворює цей plan на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного run, або завантажує package artifact з `package_artifact_run_id`; перевіряє tarball inventory; збирає і пушить package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли plan потребує package-installed lanes; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість rebuild. Docker image pulls повторюються з обмеженим 180-секундним timeout на attempt, щоб завислий registry/cache stream швидко повторився, а не спожив більшість CI critical path. Workflow `Package Acceptance` є high-level package gate: він resolve-ить candidate з npm, довіреного `package_ref`, HTTPS tarball плюс SHA-256 або artifact попереднього workflow, а потім передає цей єдиний artifact `package-under-test` у reusable Docker E2E workflow. Він тримає `workflow_ref` окремо від `package_ref`, щоб поточна acceptance logic могла перевіряти старіші довірені commits без checkout старого workflow code. Release checks запускають custom Package Acceptance delta для target ref: bundled-channel compat, offline plugin fixtures і Telegram package QA для resolved tarball. Release-path Docker suite запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk тягнув лише потрібний image kind і виконував кілька lanes через той самий weighted scheduler (`OPENCLAW_DOCKER_ALL_PROFILE=release-path`, `OPENCLAW_DOCKER_ALL_CHUNK=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`). OpenWebUI включається в `plugins-runtime-services`, коли full release-path coverage запитує це, і зберігає окремий chunk `openwebui` лише для OpenWebUI-only dispatches. Legacy aggregate chunk names `package-update`, `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` досі працюють для manual reruns, але release workflow використовує split chunks, щоб installer E2E і bundled plugin install/uninstall sweeps не домінували над critical path. Alias lane `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes. Chunk `bundled-channels` запускає split lanes `bundled-channel-*` і `bundled-channel-update-*` замість серійної all-in-one lane `bundled-channel-deps`. Кожен chunk uploads `.artifacts/docker-tests/` з lane logs, timings, `summary.json`, `failures.json`, phase timings, scheduler plan JSON, slow-lane tables і per-lane rerun commands. Input workflow `docker_lanes` запускає вибрані lanes на підготовлених images замість chunk jobs, що обмежує debugging failed-lane одним targeted Docker job і готує, завантажує або повторно використовує package artifact для цього run; якщо вибрана lane є live Docker lane, targeted job збирає live-test image локально для цього rerun. Згенеровані per-lane GitHub rerun commands містять `package_artifact_run_id`, `package_artifact_name` і prepared image inputs, коли ці значення існують, щоб failed lane могла повторно використати точні package і images з failed run. Використовуйте `pnpm test:docker:rerun `, щоб завантажити Docker artifacts з GitHub run і вивести combined/per-lane targeted rerun commands; використовуйте `pnpm test:docker:timings ` для slow-lane і phase critical-path summaries. Scheduled live/E2E workflow щодня запускає повний release-path Docker suite. Bundled update matrix розділена за update target, щоб repeated npm update і doctor repair passes могли shard-итися з іншими bundled checks. -Поточні 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`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` і `bundled-channels-contracts`. Агрегований фрагмент `bundled-channels` залишається доступним для ручних одноразових повторних запусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими псевдонімами плагінів/runtime, але релізний workflow використовує розділені фрагменти, щоб smoke-перевірки каналів, цілі оновлення, перевірки runtime плагінів і проходи встановлення/видалення вбудованих плагінів могли виконуватися паралельно. Цільові dispatch-запуски `docker_lanes` також розділяють кілька вибраних lanes на паралельні завдання після одного спільного кроку підготовки пакета/образу, а lanes оновлення вбудованих каналів повторюються один раз у разі тимчасових мережевих збоїв npm. +Поточні 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-discord`, `bundled-channels-update-b` і `bundled-channels-contracts`. Агрегований фрагмент `bundled-channels` лишається доступним для ручних одноразових повторних запусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` лишаються агрегованими псевдонімами плагінів/середовища виконання, але workflow релізу використовує розділені фрагменти, щоб smoke-перевірки каналів, цілі оновлення, перевірки середовища виконання плагінів і проходи встановлення/видалення вбудованих плагінів могли виконуватися паралельно. Цільові dispatch-запуски `docker_lanes` також розділяють кілька вибраних ланів на паралельні jobs після одного спільного кроку підготовки пакета/образу, а лани оновлення вбудованих каналів повторюють спробу один раз у разі тимчасових мережевих збоїв npm. -Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий scope CI-платформи: зміни у production-коді ядра запускають typecheck production-коду ядра і тестів ядра плюс lint/guards ядра, зміни лише в тестах ядра запускають тільки typecheck тестів ядра плюс lint ядра, зміни у production-коді extension запускають typecheck production-коду extension і тестів extension плюс lint extension, а зміни лише в тестах extension запускають typecheck тестів extension плюс lint extension. Зміни публічного Plugin SDK або контракту плагінів розширюються до typecheck extension, бо extensions залежать від цих контрактів ядра, але Vitest-проходи extension є явною тестовою роботою. Version bump-и лише релізних метаданих запускають цільові перевірки версії/конфігурації/root-залежностей. Невідомі зміни root/config безпечно переходять до всіх check lanes. -Локальний роутинг changed-test міститься в `scripts/test-projects.test-support.mjs` і -навмисно дешевший за `check:changed`: прямі зміни тестів запускають самі себе, -зміни джерел віддають перевагу явним мапінгам, потім sibling-тестам і залежним -за import-graph. Спільна конфігурація доставки group-room є одним із явних мапінгів: -зміни конфігурації visible-reply для групи, режиму доставки source reply або -системного prompt-а message-tool проходять через тести core reply плюс регресії доставки Discord і -Slack, щоб зміна спільного default падала до першого push PR. -Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна -настільки широка для harness, що дешевий mapped-набір не є надійним proxy. +Локальна логіка змінених ланів міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий scope CI-платформи: зміни production-коду ядра запускають typecheck production-коду ядра й тестів ядра плюс lint/guards ядра, зміни лише тестів ядра запускають лише typecheck тестів ядра плюс lint ядра, зміни production-коду розширень запускають typecheck production-коду розширень і тестів розширень плюс lint розширень, а зміни лише тестів розширень запускають typecheck тестів розширень плюс lint розширень. Зміни Public Plugin SDK або контрактів плагінів розширюються до typecheck розширень, оскільки розширення залежать від цих контрактів ядра, але Vitest-проходи розширень є явною тестовою роботою. Версійні bump-и лише release-метаданих запускають цільові перевірки версії/config/root-dependency. Невідомі зміни root/config fail safe до всіх check-ланів. +Локальна маршрутизація змінених тестів міститься в `scripts/test-projects.test-support.mjs` і +навмисно дешевша за `check:changed`: прямі зміни тестів запускають самі себе, +зміни source віддають перевагу явним mappings, потім sibling-тестам та import-graph +dependents. Спільна delivery-конфігурація group-room є одним з явних mappings: +зміни до конфігурації видимих відповідей групи, режиму доставки source-відповідей або +system prompt message-tool проходять через core reply tests плюс регресії доставки Discord і +Slack, щоб зміна спільного default падала ще до першого PR +push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна +настільки широка для harness, що дешевий mapped set не є надійним proxy. -Для валідації Testbox запускайте з root репозиторію і віддавайте перевагу свіжому прогрітому box для -широкого proof. Перед тим як витрачати повільний gate на box, який було повторно використано, термін дії якого минув або -який щойно повідомив про несподівано великий sync, спочатку запустіть `pnpm testbox:sanity` всередині -box. Sanity-перевірка швидко падає, коли обов’язкові root-файли, як-от -`pnpm-lock.yaml`, зникли або коли `git status --short` показує принаймні 200 +Для Testbox-валидації запускайте з кореня репозиторію й віддавайте перевагу свіжому прогрітому box для +широкого proof. Перш ніж витрачати повільний gate на box, який було повторно використано, термін якого сплив або +який щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` всередині +box. Sanity-перевірка швидко падає, коли зникли потрібні root-файли, як-от +`pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 відстежуваних видалень. Зазвичай це означає, що remote sync state не є надійною -копією PR. Зупиніть цей box і прогрійте свіжий замість того, щоб налагоджувати -падіння product test. Для PR із навмисними великими видаленнями встановіть +копією PR. Зупиніть цей box і прогрійте свіжий замість налагодження +збою product test. Для навмисних PR з великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity-запуску. `pnpm -testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у -sync-фазі понад п’ять хвилин без post-sync output. Установіть +testbox:run` також завершує локальний виклик Blacksmith CLI, який лишається у +sync phase понад п’ять хвилин без post-sync output. Встановіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей guard, або використайте більше -значення в мілісекундах для незвично великих локальних diff-ів. +значення в мілісекундах для незвично великих локальних diffs. -Ручні CI-dispatches запускають `checks-node-compat-node22` як широке покриття сумісності. Android є opt-in для окремого ручного CI через `include_android=true` і завжди увімкнений для `Full Release Validation`. `Plugin Prerelease` є дорожчим покриттям product/package, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull requests, push-и в `main` і окремі ручні CI-dispatches залишають цей suite вимкненим. +Ручні CI dispatch-запуски виконують `checks-node-compat-node22` як широке coverage сумісності. Android є opt-in для standalone manual CI через `include_android=true` і завжди ввімкнений для `Full Release Validation`. `Plugin Prerelease` є дорожчим product/package coverage, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull requests, push-и в `main` і standalone manual CI dispatch-запуски тримають цей suite вимкненим. -Найповільніші сімейства Node-тестів розділено або збалансовано так, щоб кожне завдання залишалося малим без надмірного резервування runners: контракти каналів виконуються як три weighted shards, малі core unit lanes попарно об’єднані, auto-reply запускається як чотири збалансовані workers із reply subtree, розділеним на shards agent-runner, dispatch і commands/state-routing, а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість спільного plugin catch-all. `Plugin Prerelease` балансує тести вбудованих плагінів між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на group і більшим Node heap, щоб import-heavy plugin batches не створювали додаткових CI jobs. Широка agents lane використовує спільний Vitest file-parallel scheduler, бо вона dominated by import/scheduling, а не належить одному повільному тестовому файлу. `runtime-config` запускається з infra core-runtime shard, щоб спільний runtime shard не володів tail. Include-pattern shards записують timing entries з використанням імені CI shard, тому `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі independent guards concurrently в одному job. Gateway watch, тести каналів і core support-boundary shard виконуються concurrently всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі check names як lightweight verifier jobs і водночас уникаючи двох додаткових Blacksmith workers і другої artifact-consumer queue. -Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює цей flavor із SMS/call-log BuildConfig flags, уникаючи дубльованого debug APK packaging job на кожному Android-relevant push. -GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє в той самий PR або `main` ref. Вважайте це CI-шумом, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють нормальні shard failures, але не стають у queue після того, як увесь workflow уже був superseded. -Автоматичний CI concurrency key versioned (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs. +Найповільніші сімейства Node-тестів розділені або збалансовані так, щоб кожен job лишався малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, малі core unit lanes спарені, auto-reply запускається як чотири збалансовані workers з reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards, а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media та miscellaneous plugin tests використовують свої dedicated Vitest configs замість спільного plugin catch-all. `Plugin Prerelease` балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на group і більшим Node heap, щоб import-heavy plugin batches не створювали додаткових CI jobs. Широкий agents lane використовує спільний Vitest file-parallel scheduler, бо він домінований імпортом/плануванням, а не одним повільним test file. `runtime-config` запускається з infra core-runtime shard, щоб shared runtime shard не володів tail. Include-pattern shards записують timing entries із використанням CI shard name, щоб `.artifacts/vitest-shard-timings.json` міг відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards конкурентно всередині одного job. Gateway watch, channel tests і core support-boundary shard запускаються конкурентно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі check names як легкі verifier jobs і водночас уникаючи двох додаткових Blacksmith workers і другої artifact-consumer queue. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane усе ще компілює цей flavor з BuildConfig flags для SMS/call-log, уникаючи дубльованого debug APK packaging job під час кожного Android-relevant push. +GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє в той самий PR або `main` ref. Вважайте це CI-шумом, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже superseded. +Автоматичний CI concurrency key версійований (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs. ## Runners | Runner | Jobs | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ubuntu-24.04` | `preflight`, швидкі security jobs і aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled checks, sharded channel contract checks, `check` shards окрім lint, `check-additional` shards і aggregates, Node test aggregate verifiers, docs checks, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла ставати в queue раніше | -| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, lower-weight extension shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | +| `ubuntu-24.04` | `preflight`, швидкі security jobs та aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled checks, sharded channel contract checks, `check` shards крім lint, `check-additional` shards і aggregates, Node test aggregate verifiers, docs checks, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла ставати в чергу раніше | +| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, нижчі за вагою extension shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | | `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux Node test shards, bundled plugin test shards, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо CPU-sensitive, що 8 vCPU коштували більше, ніж заощаджували; install-smoke Docker builds, де 32-vCPU queue time коштував більше, ніж заощаджував | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який лишається достатньо CPU-sensitive, щоб 8 vCPU коштували більше, ніж зекономили; install-smoke Docker builds, де 32-vCPU queue time коштував більше, ніж зекономив | | `blacksmith-16vcpu-windows-2025` | `checks-windows` | | `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; forks fallback до `macos-latest` | | `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks fallback до `macos-latest` | diff --git a/docs/uk/gateway/config-agents.md b/docs/uk/gateway/config-agents.md index a66e52fe4..e0299828f 100644 --- 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 '' --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 '' --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`; `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`; `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/"].params.thinking`. -Моделі Z.AI типово вмикають `tool_stream` для потокового передавання викликів інструментів. Щоб вимкнути це, задайте `agents.defaults.models["zai/"].params.tool_stream` значення `false`. -Моделі Anthropic Claude 4.6 типово використовують `adaptive` мислення, коли явний рівень мислення не задано. +Моделі Z.AI GLM-4.x автоматично вмикають режим мислення, якщо ви не встановите `--thinking off` або самостійно не задасте `agents.defaults.models["zai/"].params.thinking`. +Моделі Z.AI типово вмикають `tool_stream` для потокового передавання викликів інструментів. Установіть `agents.defaults.models["zai/"].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 } ``` - + - `mode: "cache-ttl"` вмикає проходи обрізання. -- `ttl` керує тим, як часто обрізання може запускатися знову (після останнього звернення до кешу). -- Обрізання спочатку м’яко скорочує завеликі результати інструментів, а потім, за потреби, повністю очищає старіші результати інструментів. +- `ttl` керує тим, як часто обрізання може запускатися знову (після останнього дотику до кешу). +- Обрізання спершу м’яко скорочує завеликі результати інструментів, а потім, якщо потрібно, жорстко очищає старіші результати інструментів. **М’яке скорочення** зберігає початок + кінець і вставляє `...` посередині. -**Повне очищення** замінює весь результат інструмента заповнювачем. +**Жорстке очищення** замінює весь результат інструмента на placeholder. Примітки: -- Блоки зображень ніколи не скорочуються й не очищуються. -- Співвідношення базуються на символах (приблизно), а не на точній кількості токенів. +- Блоки зображень ніколи не скорочуються й не очищаються. +- Коефіцієнти базуються на символах (приблизно), а не на точній кількості токенів. - Якщо існує менше ніж `keepLastAssistants` повідомлень асистента, обрізання пропускається. -Див. [Обрізання сесії](/uk/concepts/session-pruning) для подробиць поведінки. +Див. [Session Pruning](/uk/concepts/session-pruning), щоб дізнатися подробиці поведінки. ### Блокове потокове передавання @@ -657,9 +658,9 @@ Plugin надає нативний harness, як-от вбудований harne - Канали, відмінні від Telegram, потребують явного `*.blockStreaming: true`, щоб увімкнути блокові відповіді. - Перевизначення каналів: `channels..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). ### `agents.defaults.sandbox` -Необов’язкова ізоляція в sandbox для вбудованого агента. Повний посібник див. у [Sandboxing](/uk/gateway/sandboxing). +Необов’язкова ізоляція для вбудованого агента. Повний посібник див. у [Sandboxing](/uk/gateway/sandboxing). ```json5 { @@ -778,54 +779,54 @@ Plugin надає нативний harness, як-от вбудований harne } ``` - + -**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:"` типово заблоковано, якщо ви явно не встановите -`sandbox.docker.dangerouslyAllowContainerNamespaceJoin: true` (аварійний виняток). +**Контейнери типово використовують `network: "none"`** — встановіть `"bridge"` (або власну bridge-мережу), якщо агенту потрібен вихідний доступ. +`"host"` заблоковано. `"container:"` заблоковано типово, якщо ви явно не встановите +`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=` @@ -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=`; установіть `0`, щоб використовувати типове - обмеження процесів Chromium. + `OPENCLAW_BROWSER_RENDERER_PROCESS_LIMIT=`; встановіть `0`, щоб використовувати + типове обмеження процесів Chromium. - плюс `--no-sandbox`, коли ввімкнено `noSandbox`. - - Типові значення є базовими для образу контейнера; використовуйте власний образ браузера з власною - точкою входу, щоб змінити типові значення контейнера. + - Типові значення є базовою конфігурацією образу контейнера; використовуйте власний образ браузера з власною + точкою входу, щоб змінити типові параметри контейнера. -Пісочниця браузера й `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`) і не використовує наведений вище рівневий порядок прив’язок маршруту. -### Профілі доступу для окремих агентів +### Профілі доступу для окремого агента - + ```json5 { @@ -1059,7 +1060,7 @@ scripts/sandbox-browser-setup.sh # optional browser image - + ```json5 { @@ -1088,7 +1089,7 @@ scripts/sandbox-browser-setup.sh # optional browser image - + ```json5 { @@ -1134,7 +1135,7 @@ scripts/sandbox-browser-setup.sh # optional browser image -Див. [Багатоагентна пісочниця та інструменти](/uk/tools/multi-agent-sandbox-tools) для деталей пріоритетності. +Докладніше про пріоритети див. у [пісочниці й інструментах для кількох агентів](/uk/tools/multi-agent-sandbox-tools). --- @@ -1184,36 +1185,36 @@ scripts/sandbox-browser-setup.sh # optional browser image } ``` - + -- **`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.`. Типово дорівнює `pruneAfter`; установіть `false`, щоб вимкнути. - - `maxDiskBytes`: необов’язковий дисковий бюджет каталогу сесій. У режимі `warn` записує попередження до журналу; у режимі `enforce` спершу видаляє найстаріші артефакти/сесії. - - `highWaterBytes`: необов’язкова ціль після очищення бюджету. Типово дорівнює `80%` від `maxDiskBytes`. -- **`threadBindings`**: глобальні типові значення для можливостей сесій, прив’язаних до потоків. + - `resetArchiveRetention`: зберігання архівів транскриптів `*.reset.`. Типово дорівнює `pruneAfter`; установіть `false`, щоб вимкнути. + - `maxDiskBytes`: необов'язковий дисковий бюджет каталогу сесій. У режимі `warn` журналює попередження; у режимі `enforce` спочатку видаляє найстаріші артефакти/сесії. + - `highWaterBytes`: необов'язкова ціль після очищення бюджету. Типово дорівнює `80%` від `maxDiskBytes`. +- **`threadBindings`**: глобальні типові значення для функцій сесій, прив'язаних до потоків. - `enabled`: головний типовий перемикач (провайдери можуть перевизначати; Discord використовує `channels.discord.threadBindings.enabled`) - - `idleHours`: типове автоматичне зняття фокуса після неактивності в годинах (`0` вимикає; провайдери можуть перевизначати) + - `idleHours`: типове автоматичне зняття фокуса через бездіяльність у годинах (`0` вимикає; провайдери можуть перевизначати) - `maxAgeHours`: типовий жорсткий максимальний вік у годинах (`0` вимикає; провайдери можуть перевизначати) @@ -1252,36 +1253,36 @@ scripts/sandbox-browser-setup.sh # optional browser image ### Префікс відповіді -Перевизначення для окремого каналу/облікового запису: `channels..responsePrefix`, `channels..accounts..responsePrefix`. +Перевизначення для каналу/облікового запису: `channels..responsePrefix`, `channels..accounts..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..ackReaction`, `channels..accounts..ackReaction`. +- Типово використовує `identity.emoji` активного агента, інакше `"👀"`. Установіть `""`, щоб вимкнути. +- Перевизначення для каналу: `channels..ackReaction`, `channels..accounts..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.`. -- 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`). --- diff --git a/docs/uk/gateway/local-models.md b/docs/uk/gateway/local-models.md index d392654aa..5204bf572 100644 --- 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. -**Користувачі 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). ## Рекомендовано: 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..models[].id` є локальним для provider-а. Не -включайте туди префікс provider-а. Наприклад, сервер MLX, запущений з -`mlx_lm.server --model mlx-community/Qwen3-30B-A3B-6bit`, має використовувати такий -ID каталогу й посилання на модель: +Значення `models.providers..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..timeoutSeconds` для повільних локальних або віддалених -серверів моделей перед підвищенням `agents.defaults.timeoutSeconds`. Таймаут provider-а -застосовується лише до HTTP-запитів моделі, включно з підключенням, заголовками, потоковою передачею тіла -та загальним перериванням guarded-fetch. +серверів моделей перед підвищенням `agents.defaults.timeoutSeconds`. Тайм-аут provider +застосовується лише до HTTP-запитів моделі, включно з підключенням, headers, body streaming +і загальним guarded-fetch abort. -Для кастомних 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. -Примітка щодо поведінки локальних/проксійованих бекендів `/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..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 --prompt "Reply with exactly: pong" --json ``` - Щоб перевірити маршрут Gateway без повної форми agent prompt, використовуйте + Щоб перевірити маршрут Gateway без повної форми промпта агента, використовуйте натомість Gateway model probe: ```bash openclaw infer model run --gateway --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..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) diff --git a/docs/uk/reference/RELEASING.md b/docs/uk/reference/RELEASING.md index d0e95f73a..a863524c7 100644 --- 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` лише для перевірки - метаданих пакета; реальний 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` лише для перевірки метаданих пакета; реальна публікація все одно потребує справжнього релізного тегу +- Обидва 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=`, запускає `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=`, запускає `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=` у reusable live/E2E workflow замість -повторного запуску всіх релізних частин. Згенеровані команди повторного запуску включають попередній -`package_artifact_run_id` і підготовлені входи Docker-образів, коли доступні, тож -невдала лінія може повторно використати той самий tarball і GHCR-образи. +Використовуйте Docker-артефакти перед повторним запуском. Планувальник релізного шляху завантажує +`.artifacts/docker-tests/` із журналами ланок, `summary.json`, `failures.json`, +таймінгами фаз, JSON плану планувальника та командами повторного запуску. Для сфокусованого відновлення +використовуйте `docker_lanes=` у багаторазовому 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=`, `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) diff --git a/docs/uk/tools/thinking.md b/docs/uk/tools/thinking.md index cefaf0c41..95787a50a 100644 --- 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 `, `/think:` або `/thinking `. -- Рівні (аліаси): `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..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["/"].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-агенти), надсилають кожен виклик інструмента назад як окреме повідомлення лише з метаданими з префіксом ` : `, коли доступно (шлях/команда). Ці підсумки інструментів надсилаються щойно кожен інструмент запускається (окремими бульбашками), а не як 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-агенти), надсилають кожен виклик інструмента назад як окреме повідомлення лише з метаданими, з префіксом ` : `, коли доступно (шлях/команда). Ці підсумки інструментів надсилаються щойно кожен інструмент стартує (окремі бульбашки), а не як потокові дельти. +- Підсумки збоїв інструментів залишаються видимими у звичайному режимі, але необроблені суфікси деталей помилок приховані, якщо докладність не `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 локальних моделей обробляються консервативно. Закриті блоки `...` залишаються прихованими у звичайних відповідях, а незакритий reasoning після вже видимого тексту також приховується. Якщо відповідь повністю обгорнута в один незакритий opening tag і інакше була б доставлена як порожній текст, OpenClaw видаляє некоректний opening tag і доставляє решту тексту. +Некоректні теги reasoning локальної моделі обробляються консервативно. Закриті блоки `...` залишаються прихованими у звичайних відповідях, а незакрите 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 ()`, де визначене типове значення походить із профілю provider thinking для активної моделі сесії плюс та сама логіка резервних варіантів, яку використовують `/status` і `session_status`. -- Селектор використовує `thinkingLevels`, повернені рядком/типовими значеннями сесії шлюзу, а `thinkingOptions` зберігається як застарілий список міток. UI браузера не зберігає власний список regex провайдерів; plugins володіють наборами рівнів, специфічними для моделі. -- `/think:` усе ще працює й оновлює той самий збережений рівень сесії, тож директиви чату та селектор залишаються синхронізованими. +- Селектор мислення вебчату відображає збережений рівень сесії зі сховища/конфігурації вхідної сесії під час завантаження сторінки. +- Вибір іншого рівня одразу записує перевизначення сесії через `sessions.patch`; він не чекає наступного надсилання й не є одноразовим перевизначенням `thinkingOnce`. +- Перший варіант завжди `Default ()`, де розв’язане типове значення походить із профілю мислення провайдера активної моделі сесії та тієї самої резервної логіки, яку використовують `/status` і `session_status`. +- Селектор використовує `thinkingLevels`, повернені рядком/типовими значеннями сесії Gateway, а `thinkingOptions` зберігається як застарілий список міток. UI браузера не зберігає власний список regex провайдерів; плагіни володіють наборами рівнів, специфічними для моделей. +- `/think:` усе ще працює й оновлює той самий збережений рівень сесії, тому директиви чату й селектор залишаються синхронізованими. ## Профілі провайдерів -- 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-валідація.