diff --git a/docs/uk/ci.md b/docs/uk/ci.md index 12e1bc303..2ad818918 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,91 +1,98 @@ --- read_when: - - Вам потрібно зрозуміти, чому завдання CI було або не було запущено. - - Ви налагоджуєте збої перевірок GitHub Actions. -summary: Граф завдань CI, обмежувальні перевірки за обсягом змін і локальні еквіваленти команд + - Вам потрібно зрозуміти, чому завдання CI було або не було запущене + - Ви налагоджуєте збої перевірок GitHub Actions +summary: Граф завдань CI, межі перевірок і локальні еквіваленти команд title: Конвеєр CI x-i18n: - generated_at: "2026-04-23T05:16:42Z" + generated_at: "2026-04-23T13:33:21Z" model: gpt-5.4 provider: openai - source_hash: 5c89c66204b203a39435cfc19de7b437867f2792bbfa2c3948371abde9f80e11 + source_hash: 730bba64e0867f41b47e4896f8255b6d23e6530bb91d349abb25b35a43152e9e source_path: ci.md workflow: 15 --- # Конвеєр CI -CI запускається при кожному push до `main` і для кожного pull request. Він використовує розумне обмеження за обсягом змін, щоб пропускати дорогі завдання, коли змінювалися лише несуміжні ділянки. +CI запускається для кожного push у `main` і для кожного pull request. Він використовує розумне визначення меж, щоб пропускати дорогі завдання, коли змінено лише не пов’язані ділянки. -QA Lab має виділені смуги CI поза основним workflow з розумним обмеженням за обсягом змін. Workflow `Parity gate` запускається для відповідних змін у PR і через manual dispatch; він збирає приватне середовище виконання QA і порівнює agentic-паки mock GPT-5.4 та Opus 4.6. Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і через manual dispatch; він розгалужує mock parity gate, live Matrix lane і live Telegram lane як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а смуга Telegram використовує оренди Convex. `OpenClaw Release Checks` також запускає ті самі смуги QA Lab перед затвердженням релізу. +QA Lab має окремі доріжки CI поза основним workflow з розумним визначенням меж. Workflow +`Parity gate` запускається для відповідних змін у PR і при ручному запуску; він +збирає приватне середовище виконання QA і порівнює агентні набори mock GPT-5.4 та Opus 4.6. +Workflow `QA-Lab - All Lanes` запускається щоночі для `main` і при +ручному запуску; він розгалужує mock parity gate, live Matrix lane і live +Telegram lane як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, +а Telegram lane використовує оренди Convex. `OpenClaw Release +Checks` також запускає ті самі доріжки QA Lab перед погодженням релізу. ## Огляд завдань -| Завдання | Призначення | Коли запускається | -| -------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------- | -| `preflight` | Визначення змін лише в документації, змінених областей, змінених extensions і побудова маніфесту CI | Завжди для non-draft push і PR | -| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для non-draft push і PR | -| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisories npm | Завжди для non-draft push і PR | -| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для non-draft push і PR | -| `build-artifacts` | Збірка `dist/`, Control UI, перевірки built-artifact і повторно використовувані downstream artifacts | Зміни, пов’язані з Node | -| `checks-fast-core` | Швидкі Linux-смуги коректності, такі як bundled/plugin-contract/protocol checks | Зміни, пов’язані з Node | -| `checks-fast-contracts-channels` | Розподілені перевірки контрактів каналів зі стабільним агрегованим результатом | Зміни, пов’язані з Node | -| `checks-node-extensions` | Повні розподілені тестові смуги bundled-plugin для всього набору extensions | Зміни, пов’язані з Node | -| `checks-node-core-test` | Розподілені тести core Node, за винятком смуг каналів, bundled, контрактів і extensions | Зміни, пов’язані з Node | -| `extension-fast` | Цільові тести лише для змінених bundled plugins | Pull request зі змінами в extensions | -| `check` | Розподілений еквівалент основної локальної перевірки: prod types, lint, guards, test types і strict smoke | Зміни, пов’язані з Node | -| `check-additional` | Перевірки архітектури, меж, поверхонь extensions, меж пакетів і розподілені перевірки gateway-watch | Зміни, пов’язані з Node | -| `build-smoke` | Smoke-тести зібраного CLI і smoke перевірка пам’яті під час запуску | Зміни, пов’язані з Node | -| `checks` | Верифікатор для channel tests на built-artifact плюс сумісність Node 22 лише для push | Зміни, пов’язані з Node | -| `check-docs` | Форматування документації, lint і перевірки битих посилань | Зміни в документації | -| `skills-python` | Ruff + pytest для Skills на основі Python | Зміни, релевантні Python Skills | -| `checks-windows` | Специфічні для Windows тестові смуги | Зміни, релевантні Windows | -| `macos-node` | Смуга тестів TypeScript на macOS з використанням спільних built artifacts | Зміни, релевантні macOS | -| `macos-swift` | Lint, збірка і тести Swift для застосунку macOS | Зміни, релевантні macOS | -| `android` | Модульні тести Android для обох flavor плюс одна збірка debug APK | Зміни, релевантні Android | +| Завдання | Призначення | Коли запускається | +| --------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------ | +| `preflight` | Виявляє зміни лише в документації, змінені межі, змінені extensions і будує маніфест CI | Завжди для недрафтових push і PR | +| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для недрафтових push і PR | +| `security-dependency-audit` | Аудит production lockfile без залежностей щодо advisories npm | Завжди для недрафтових push і PR | +| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для недрафтових push і PR | +| `build-artifacts` | Збирає `dist/`, Control UI, перевірки built-artifact і повторно використовувані downstream artifacts | Зміни, релевантні до Node | +| `checks-fast-core` | Швидкі Linux-доріжки коректності, такі як перевірки bundled/plugin-contract/protocol | Зміни, релевантні до Node | +| `checks-fast-contracts-channels` | Шардовані перевірки channel contract зі стабільним агрегованим результатом перевірки | Зміни, релевантні до Node | +| `checks-node-extensions` | Повні шардовані тести bundled-plugin для всього набору extension | Зміни, релевантні до Node | +| `checks-node-core-test` | Шарди core Node test, за винятком channel, bundled, contract і extension доріжок | Зміни, релевантні до Node | +| `extension-fast` | Сфокусовані тести лише для змінених bundled plugins | Pull request зі змінами в extension | +| `check` | Шардований еквівалент основної локальної перевірки: production типи, lint, guard, test types і strict smoke | Зміни, релевантні до Node | +| `check-additional` | Шарди архітектури, меж, guard для extension-surface, package-boundary і gateway-watch | Зміни, релевантні до Node | +| `build-smoke` | Smoke-тести built-CLI і smoke перевірка пам’яті під час запуску | Зміни, релевантні до Node | +| `checks` | Верифікатор для channel test built-artifact плюс сумісність Node 22 лише для push | Зміни, релевантні до Node | +| `check-docs` | Форматування документації, lint і перевірки на биті посилання | Змінено документацію | +| `skills-python` | Ruff + pytest для Skills на основі Python | Зміни, релевантні до Python Skills | +| `checks-windows` | Windows-специфічні тестові доріжки | Зміни, релевантні до Windows | +| `macos-node` | Доріжка TypeScript test для macOS з використанням спільних built artifacts | Зміни, релевантні до macOS | +| `macos-swift` | Swift lint, build і тести для застосунку macOS | Зміни, релевантні до macOS | +| `android` | Android unit tests для обох flavor плюс одна збірка debug APK | Зміни, релевантні до Android | -## Порядок швидкого завершення при помилці +## Порядок Fail-Fast -Завдання впорядковані так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запускатимуться дорогі: +Завдання впорядковані так, щоб дешеві перевірки завершувалися з помилкою раніше, ніж запустяться дорогі: -1. `preflight` визначає, які смуги взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання. -2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` завершуються з помилкою швидко, не чекаючи важчих завдань із артефактами та платформною матрицею. -3. `build-artifacts` виконується паралельно зі швидкими Linux-смугами, щоб downstream-споживачі могли почати роботу, щойно спільна збірка буде готова. -4. Після цього розгалужуються важчі платформні та runtime-смуги: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, PR-only `extension-fast`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +1. `preflight` визначає, які доріжки взагалі існують. Логіка `docs-scope` і `changed-scope` — це кроки всередині цього завдання, а не окремі завдання. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` завершуються з помилкою швидко, не чекаючи важчих завдань артефактів і платформної матриці. +3. `build-artifacts` виконується паралельно зі швидкими Linux-доріжками, щоб downstream-споживачі могли стартувати, щойно спільна збірка готова. +4. Після цього розгалужуються важчі платформні та runtime-доріжки: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `extension-fast` лише для PR, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. -Логіка обмеження за обсягом змін міститься в `scripts/ci-changed-scope.mjs` і покрита модульними тестами в `src/scripts/ci-changed-scope.test.ts`. -Зміни workflow CI перевіряють граф Node CI плюс lint workflow, але самі по собі не примушують запускати нативні збірки для Windows, Android або macOS; ці платформні смуги залишаються обмеженими змінами у вихідному коді відповідних платформ. -Перевірки Node для Windows обмежені специфічними для Windows обгортками process/path, допоміжними засобами npm/pnpm/UI runner, конфігурацією package manager і поверхнями workflow CI, які запускають цю смугу; несуміжні зміни в коді, plugins, install-smoke і зміни лише в тестах залишаються в Linux Node lanes, щоб не займати Windows worker із 16 vCPU для покриття, яке вже перевіряється звичайними test shards. -Окремий workflow `install-smoke` повторно використовує той самий script обмеження за обсягом змін через власне завдання `preflight`. Він обчислює `run_install_smoke` із вужчого сигналу changed-smoke, тому Docker/install smoke запускається для змін, пов’язаних з install, packaging, контейнерами, production changes у bundled extensions і поверхнями core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише в тестах і документації не займають Docker workers. Його QR package smoke примушує Docker-layer `pnpm install` виконатися повторно, зберігаючи кеш BuildKit pnpm store, тож він усе одно перевіряє встановлення без повторного завантаження залежностей під час кожного запуску. Його gateway-network e2e повторно використовує runtime image, зібраний раніше в цьому завданні, тому додає реальне покриття WebSocket між контейнерами без додавання ще однієї Docker-збірки. Локальна команда `test:docker:all` попередньо збирає один спільний built-app image з `scripts/e2e/Dockerfile` і повторно використовує його в E2E container smoke runners; повторно використовуваний live/E2E workflow відтворює цей шаблон, збираючи та публікуючи один Docker E2E image GHCR із тегом SHA перед Docker-матрицею, а потім запускаючи матрицю з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Тести Docker для QR та installer зберігають власні Dockerfiles, орієнтовані на встановлення. Окреме завдання `docker-e2e-fast` запускає обмежений Docker profile bundled-plugin із тайм-аутом команди 120 секунд: repair залежностей setup-entry плюс ізоляція синтетичних збоїв bundled-loader. Повна bundled matrix для update/channel залишається manual/full-suite, оскільки виконує повторні реальні проходи npm update і doctor repair. +Логіка меж міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. +Редагування workflow CI перевіряє граф Node CI разом із lint для workflow, але саме по собі не примушує виконувати нативні збірки Windows, Android або macOS; ці платформні доріжки й далі залежать від змін у платформному коді. +Перевірки Windows Node обмежені Windows-специфічними process/path wrappers, npm/pnpm/UI runner helpers, конфігурацією package manager і поверхнями workflow CI, які запускають цю доріжку; не пов’язані зміни в коді, plugin, install-smoke і зміни лише в тестах залишаються на Linux Node доріжках, щоб не резервувати Windows worker на 16 vCPU для покриття, яке вже перевіряється звичайними test shards. +Окремий workflow `install-smoke` повторно використовує той самий скрипт меж через власне завдання `preflight`. Він обчислює `run_install_smoke` із вужчого сигналу changed-smoke, тому Docker/install smoke запускається для змін, релевантних до install, packaging, container, production changes у bundled extension і поверхонь core plugin/channel/gateway/Plugin SDK, які використовують Docker smoke jobs. Зміни лише в тестах і документації не резервують Docker workers. Його smoke для QR package примушує Docker-шар `pnpm install` виконатися повторно, зберігаючи кеш BuildKit pnpm store, тож він усе ще перевіряє встановлення без повторного завантаження залежностей у кожному запуску. Його gateway-network e2e повторно використовує runtime image, зібраний раніше в цьому завданні, тож додає реальне покриття WebSocket між контейнерами без додавання ще однієї Docker-збірки. Локально `test:docker:all` попередньо збирає один спільний live-test image і один спільний built-app image з `scripts/e2e/Dockerfile`, а потім паралельно запускає доріжки live/E2E smoke з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте стандартний паралелізм 4 через `OPENCLAW_DOCKER_ALL_PARALLELISM`. Доріжки, чутливі до запуску або провайдера, виконуються ексклюзивно після паралельного пулу. Повторно використовуваний workflow live/E2E наслідує шаблон спільного image, збираючи й публікуючи один Docker E2E image у GHCR з тегом SHA перед Docker matrix, а потім запускаючи матрицю з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Тести QR і installer Docker зберігають власні Dockerfile, орієнтовані на встановлення. Окреме завдання `docker-e2e-fast` запускає обмежений bundled-plugin Docker profile з тайм-аутом команди 120 секунд: відновлення залежностей setup-entry плюс ізоляція синтетичного збою bundled-loader. Повна bundled update/channel matrix залишається ручною/full-suite, оскільки виконує повторні реальні проходи npm update і doctor repair. -Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Ця локальна перевірка суворіша щодо архітектурних меж, ніж широке CI-обмеження платформ: production changes у core запускають typecheck core prod плюс тести core, зміни лише в тестах core запускають лише typecheck/tests для тестів core, production changes у extensions запускають typecheck extension prod плюс тести extensions, а зміни лише в тестах extensions запускають лише typecheck/tests для тестів extensions. Зміни в публічному Plugin SDK або plugin-contract розширюють валідацію на extensions, оскільки extensions залежать від цих контрактів core. Релізні version bumps лише в metadata запускають цільові перевірки version/config/root-dependency. Невідомі зміни root/config у безпечному режимі запускають усі смуги. +Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Ця локальна перевірка суворіша щодо архітектурних меж, ніж широка платформна межа CI: зміни core production запускають core prod typecheck плюс core tests, зміни лише в core tests запускають лише core test typecheck/tests, зміни extension production запускають extension prod typecheck плюс extension tests, а зміни лише в extension tests запускають лише extension test typecheck/tests. Зміни в публічному Plugin SDK або plugin-contract розширюють валідацію на extension, тому що extension залежать від цих core contract. Version bumps лише в release metadata запускають цільові перевірки version/config/root-dependency. Невідомі зміни в root/config безпечно розширюються до всіх доріжок. -Для push матриця `checks` додає смугу `compat-node22`, яка запускається лише для push. Для pull request ця смуга пропускається, і матриця залишається зосередженою на звичайних test/channel lanes. +Для push матриця `checks` додає доріжку `compat-node22`, яка запускається лише для push. Для pull request ця доріжка пропускається, і матриця залишається зосередженою на звичайних test/channel доріжках. -Найповільніші сімейства тестів Node розділені або збалансовані так, щоб кожне завдання залишалося невеликим: channel contracts розділяють покриття registry і core на шість зважених shard загалом, тести bundled plugin збалансовані на шість workers для extensions, auto-reply працює як три збалансовані workers замість шести дрібних workers, а конфігурації agentic gateway/plugin розподілені по наявних source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media та miscellaneous plugin tests використовують свої виділені конфігурації Vitest замість спільного всеохопного набору plugin. Широка agents lane використовує спільний file-parallel scheduler Vitest, оскільки в ній домінують імпорти/планування, а не один повільний test file. `runtime-config` виконується разом із shard `infra core-runtime`, щоб спільний runtime shard не володів хвостом виконання. `check-additional` тримає разом compile/canary-роботи для меж пакетів і відокремлює архітектуру runtime topology від покриття gateway watch; shard boundary guard запускає свої невеликі незалежні guards паралельно в межах одного завдання. Gateway watch, channel tests і shard support-boundary для core запускаються паралельно в `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої попередні імена перевірок як легкі завдання-верифікатори та уникаючи при цьому двох додаткових Blacksmith workers і другої черги споживачів артефактів. -Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Flavor third-party не має окремого source set чи manifest; його смуга модульних тестів усе одно компілює цей flavor з прапорцями SMS/call-log у BuildConfig, водночас уникаючи дубльованого завдання пакування debug APK при кожному Android-relevant push. -`extension-fast` є лише для PR, оскільки push-запуски вже виконують повні розподілені смуги bundled plugin. Це зберігає швидкий зворотний зв’язок щодо змінених plugins для рев’ю, не займаючи додатковий Blacksmith worker на `main` для покриття, яке вже наявне в `checks-node-extensions`. +Найповільніші сімейства Node test розділені або збалансовані так, щоб кожне завдання залишалося невеликим: channel contracts розділяють покриття registry і core на шість зважених shard загалом, bundled plugin tests балансуються між шістьма extension workers, auto-reply працює як три збалансовані workers замість шести маленьких workers, а agentic gateway/plugin configs розподіляються між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої окремі конфігурації Vitest, а не спільний plugin catch-all. Широка доріжка agents використовує спільний file-parallel scheduler Vitest, оскільки для неї домінують імпорти/планування, а не один повільний test file. `runtime-config` запускається разом із shard infra core-runtime, щоб спільний runtime shard не утримував хвіст. `check-additional` тримає compile/canary-роботи package-boundary разом і відокремлює runtime topology architecture від покриття gateway watch; shard boundary guard запускає свої невеликі незалежні guard паралельно в межах одного завдання. Gateway watch, channel tests і shard core support-boundary запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі назви перевірок як легкі завдання-верифікатори й уникаючи двох додаткових Blacksmith workers та другої черги споживачів артефактів. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. У flavor third-party немає окремого source set або manifest; його доріжка unit-test усе одно компілює цей flavor із прапорцями SMS/call-log BuildConfig, уникаючи при цьому дубльованого завдання пакування debug APK для кожного Android-релевантного push. +`extension-fast` є лише для PR, тому що push-запуски вже виконують повні шарди bundled plugin. Це дає швидкий зворотний зв’язок для changed-plugin під час review, не резервуючи додатковий Blacksmith worker у `main` для покриття, яке вже присутнє в `checks-node-extensions`. -GitHub може позначати замінені новішими завдання як `cancelled`, коли новіший push потрапляє в той самий ref PR або `main`. Ставтеся до цього як до шуму CI, якщо лише найновіший запуск для того самого ref також не завершується з помилкою. Агреговані shard checks використовують `!cancelled() && always()`, тож вони все одно повідомляють про звичайні збої shard, але не стають у чергу після того, як увесь workflow уже було замінено новішим. -Ключ concurrency для CI має версію (`CI-v7-*`), щоб zombie-процес на стороні GitHub у старій групі черги не міг безстроково блокувати новіші запуски на main. +GitHub може позначати витіснені завдання як `cancelled`, коли новіший push потрапляє в той самий ref PR або `main`. Сприймайте це як шум CI, якщо тільки найновіший запуск для того самого ref теж не завершується з помилкою. Агреговані shard checks використовують `!cancelled() && always()`, щоб вони все одно повідомляли про звичайні помилки shard, але не ставали в чергу після того, як увесь workflow уже було витіснено. +Ключ конкурентності CI версіонований (`CI-v7-*`), щоб GitHub-side zombie у старій групі черги не міг безкінечно блокувати новіші запуски main. ## Виконавці -| Виконавець | Завдання | -| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, розподілені перевірки контрактів каналів, shards `check`, крім lint, shards і агрегати `check-additional`, aggregate verifiers тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла раніше стати в чергу | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, shards тестів Linux Node, shards тестів bundled plugin, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо чутливим до CPU, тож 8 vCPU коштували більше, ніж давали економії; Docker-збірки install-smoke, де час очікування в черзі для 32 vCPU коштував більше, ніж давав економії | +| Виконавець | Завдання | +| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки й агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, шардовані перевірки channel contract, шарди `check`, окрім lint, шарди й агрегати `check-additional`, агреговані верифікатори Node test, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; preflight для install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла ставати в чергу раніше | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди Linux Node test, шарди bundled plugin test, `android` | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо чутливим до CPU, тому 8 vCPU коштували дорожче, ніж давали вигоду; Docker-збірки install-smoke, де вартість часу очікування в черзі для 32 vCPU перевищувала отриману користь | | `blacksmith-16vcpu-windows-2025` | `checks-windows` | -| `blacksmith-6vcpu-macos-latest` | `macos-node` у `openclaw/openclaw`; для fork використовується резервний `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; для fork використовується резервний `macos-latest` | +| `blacksmith-6vcpu-macos-latest` | `macos-node` у `openclaw/openclaw`; для fork використовується резервний `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` у `openclaw/openclaw`; для fork використовується резервний `macos-latest` | ## Локальні еквіваленти ```bash -pnpm changed:lanes # перевірити локальний класифікатор changed-lane для origin/main...HEAD +pnpm changed:lanes # переглянути локальний класифікатор changed-lane для origin/main...HEAD pnpm check:changed # розумна локальна перевірка: changed typecheck/lint/tests за boundary lane -pnpm check # швидка локальна перевірка: production tsgo + sharded lint + паралельні fast guards +pnpm check # швидка локальна перевірка: production tsgo + шардований lint + паралельні швидкі guard pnpm check:test-types pnpm check:timed # та сама перевірка з таймінгами для кожного етапу pnpm build:strict-smoke @@ -95,6 +102,6 @@ pnpm test # тести vitest pnpm test:channels pnpm test:contracts:channels pnpm check:docs # форматування документації + lint + биті посилання -pnpm build # зібрати dist, коли важливі смуги CI artifact/build-smoke +pnpm build # зібрати dist, коли важливі доріжки CI artifact/build-smoke node scripts/ci-run-timings.mjs # підсумувати загальний час, час у черзі та найповільніші завдання ``` diff --git a/docs/uk/reference/test.md b/docs/uk/reference/test.md index 9b40e8eb5..783263c9c 100644 --- a/docs/uk/reference/test.md +++ b/docs/uk/reference/test.md @@ -1,50 +1,51 @@ --- read_when: - Запуск або виправлення тестів -summary: Як запускати тести локально (`vitest`) і коли використовувати режими `force`/`coverage` +summary: Як запускати тести локально (`vitest`) і коли використовувати режими force/coverage title: Тести x-i18n: - generated_at: "2026-04-21T21:27:24Z" + generated_at: "2026-04-23T13:33:21Z" model: gpt-5.4 provider: openai - source_hash: ed665840ef2c7728da8ec923eb3ea2878d9b20a841cb2fe4116a7f6334567b8e + source_hash: 2897f6a58720b43c749dc7ea410369a529bb8f72c50f8d9e55f114bf39ccb1a9 source_path: reference/test.md workflow: 15 --- # Тести -- Повний набір для тестування (набори тестів, live, Docker): [Тестування](/uk/help/testing) +- Повний набір для тестування (набори, live, Docker): [Тестування](/uk/help/testing) -- `pnpm test:force`: Завершує будь-який завислий процес gateway, що утримує типовий порт керування, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб тести сервера не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789. -- `pnpm test:coverage`: Запускає набір unit-тестів із покриттям V8 (через `vitest.unit.config.ts`). Це перевірка покриття unit-тестів для завантажених файлів, а не покриття всіх файлів у всьому репозиторії. Порогові значення: 70% для lines/functions/statements і 55% для branches. Оскільки `coverage.all` має значення false, перевірка вимірює файли, завантажені набором unit-тестів із покриттям, замість того щоб вважати всі файли вихідного коду у розбитих lane непокритими. -- `pnpm test:coverage:changed`: Запускає unit-покриття лише для файлів, змінених відносно `origin/main`. -- `pnpm test:changed`: розгортає змінені git-шляхи в scoped lane Vitest, коли diff зачіпає лише routable файли вихідного коду/тестів. Зміни конфігурації/налаштування все одно повертаються до нативного запуску root projects, щоб за потреби зміни у зв’язуванні запускали ширший прогін. -- `pnpm changed:lanes`: показує архітектурні lane, що запускаються diff відносно `origin/main`. -- `pnpm check:changed`: запускає розумну перевірку changed gate для diff відносно `origin/main`. Вона запускає core-роботу разом із core test lanes, роботу extension — разом із extension test lanes, зміни лише в тестах — лише з test typecheck/tests, розширює зміни публічного Plugin SDK або plugin-contract до перевірки extension, а також залишає version bump лише в release metadata на цільових перевірках version/config/root-dependency. -- `pnpm test`: маршрутизує явні цілі файлів/каталогів через scoped lane Vitest. Запуски без цілі використовують фіксовані shard-групи й розгортаються до leaf configs для локального паралельного виконання; група extension завжди розгортається до per-extension shard configs, а не до одного великого процесу root-project. -- Повні запуски та запуски extension shard оновлюють локальні дані часу в `.artifacts/vitest-shard-timings.json`; наступні запуски використовують ці значення часу для балансування повільних і швидких shard. Встановіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний артефакт часу. -- Вибрані тестові файли `plugin-sdk` і `commands` тепер маршрутизуються через окремі легкі lane, які зберігають лише `test/setup.ts`, залишаючи важкі з погляду runtime кейси в їхніх наявних lane. -- Вибрані допоміжні файли вихідного коду `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними sibling tests у цих легких lane, щоб невеликі зміни helper не перезапускали важкі набори, прив’язані до runtime. -- `auto-reply` тепер також розбивається на три окремі конфігурації (`core`, `top-level`, `reply`), щоб harness для reply не домінував над легшими top-level тестами status/token/helper. -- Базова конфігурація Vitest тепер типово використовує `pool: "threads"` і `isolate: false`, а спільний неізольований runner увімкнено в конфігураціях усього репозиторію. +- `pnpm test:force`: завершує будь-який завислий процес gateway, що утримує стандартний порт керування, а потім запускає повний набір Vitest з ізольованим портом gateway, щоб серверні тести не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск gateway залишив зайнятим порт 18789. +- `pnpm test:coverage`: запускає набір unit-тестів із покриттям V8 (через `vitest.unit.config.ts`). Це перевірка unit-покриття для завантажених файлів, а не покриття всіх файлів у всьому репозиторії. Порогові значення: 70% для lines/functions/statements і 55% для branches. Оскільки `coverage.all` має значення false, перевірка вимірює файли, завантажені набором unit-покриття, замість того щоб вважати кожен файл вихідного коду в розбитих lane непокритим. +- `pnpm test:coverage:changed`: запускає unit-покриття лише для файлів, змінених відносно `origin/main`. +- `pnpm test:changed`: розгортає змінені git-шляхи у scoped lane Vitest, коли diff торкається лише routable файлів коду/тестів. Зміни конфігурації/налаштування, як і раніше, повертаються до нативного запуску root projects, щоб за потреби зміни у зв’язуванні перезапускали ширший набір. +- `pnpm changed:lanes`: показує архітектурні lane, які запускаються diff відносно `origin/main`. +- `pnpm check:changed`: запускає розумну перевірку changed gate для diff відносно `origin/main`. Вона запускає core-роботи разом із lane core-тестів, роботи extensions — разом із lane extension-тестів, зміни лише в тестах — лише з typecheck/tests для тестів, розширює зміни публічного Plugin SDK або plugin-contract до перевірки extensions, а також залишає підвищення версій лише в release metadata на таргетованих перевірках version/config/root-dependency. +- `pnpm test`: маршрутизує явно вказані цілі файлів/каталогів через scoped lane Vitest. Нетаргетовані запуски використовують фіксовані групи shard і розгортаються до leaf config для локального паралельного виконання; група extensions завжди розгортається до конфігурацій shard для кожного extension/plugin окремо, а не в один гігантський процес root-project. +- Повні запуски та запуски shard для extensions оновлюють локальні дані таймінгів у `.artifacts/vitest-shard-timings.json`; пізніші запуски використовують ці таймінги для балансування повільних і швидких shard. Установіть `OPENCLAW_TEST_PROJECTS_TIMINGS=0`, щоб ігнорувати локальний артефакт таймінгів. +- Вибрані тестові файли `plugin-sdk` і `commands` тепер маршрутизуються через окремі легкі lane, які зберігають лише `test/setup.ts`, залишаючи runtime-важкі кейси на наявних lane. +- Вибрані допоміжні вихідні файли `plugin-sdk` і `commands` також зіставляють `pnpm test:changed` з явними сусідніми тестами у цих легких lane, тож невеликі зміни в helper не змушують повторно запускати важкі набори з runtime. +- `auto-reply` тепер також розділено на три окремі конфігурації (`core`, `top-level`, `reply`), щоб harness reply не домінував над легшими top-level тестами status/token/helper. +- Базова конфігурація Vitest тепер за замовчуванням використовує `pool: "threads"` та `isolate: false`, а спільний non-isolated runner увімкнено в конфігураціях по всьому репозиторію. - `pnpm test:channels` запускає `vitest.channels.config.ts`. -- `pnpm test:extensions` і `pnpm test extensions` запускають усі shard extension/plugin. Важкі channel extensions і OpenAI запускаються як окремі shard; інші групи extension залишаються згрупованими. Використовуйте `pnpm test extensions/` для одного lane вбудованого plugin. -- `pnpm test:perf:imports`: вмикає звіти Vitest про тривалість імпорту та деталізацію імпортів, при цьому все ще використовує маршрутизацію scoped lane для явних цілей файлів/каталогів. +- `pnpm test:extensions` і `pnpm test extensions` запускають усі shard extension/plugin. Важкі channel extensions і OpenAI виконуються як окремі shard; інші групи extensions залишаються згрупованими. Використовуйте `pnpm test extensions/` для одного lane bundled plugin. +- `pnpm test:perf:imports`: вмикає звіти Vitest про тривалість імпорту та розбивку імпортів, водночас зберігаючи маршрутизацію через scoped lane для явно вказаних цілей файлів/каталогів. - `pnpm test:perf:imports:changed`: те саме профілювання імпортів, але лише для файлів, змінених відносно `origin/main`. -- `pnpm test:perf:changed:bench -- --ref ` виконує benchmark маршрутизованого changed-режиму проти нативного запуску root-project для того самого закоміченого git diff. +- `pnpm test:perf:changed:bench -- --ref ` виконує benchmark маршрутизованого шляху в changed-режимі проти нативного запуску root-project для того самого закоміченого git diff. - `pnpm test:perf:changed:bench -- --worktree` виконує benchmark поточного набору змін у worktree без попереднього коміту. -- `pnpm test:perf:profile:main`: записує CPU-профіль для головного потоку Vitest (`.artifacts/vitest-main-profile`). -- `pnpm test:perf:profile:runner`: записує CPU + heap-профілі для unit runner (`.artifacts/vitest-runner-profile`). -- Інтеграція Gateway: вмикається через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`. -- `pnpm test:e2e`: запускає smoke-тести gateway end-to-end (парування multi-instance WS/HTTP/node). Типово використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовуйте через `OPENCLAW_E2E_WORKERS=` і встановіть `OPENCLAW_E2E_VERBOSE=1` для докладних журналів. -- `pnpm test:live`: запускає live-тести provider (minimax/zai). Потребує API-ключів і `LIVE=1` (або provider-specific `*_LIVE_TEST=1`) для зняття пропуску. -- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, виконує вхід через Open WebUI, перевіряє `/api/models`, а потім запускає реальний проксійований чат через `/api/chat/completions`. Потребує придатного ключа live model (наприклад, OpenAI у `~/.profile`), завантажує зовнішній образ Open WebUI і не вважається настільки стабільним для CI, як звичайні набори unit/e2e. -- `pnpm test:docker:mcp-channels`: запускає seeded контейнер Gateway і другий контейнер-клієнт, який запускає `openclaw mcp serve`, а потім перевіряє routed conversation discovery, читання transcript, метадані вкладень, поведінку черги live events, outbound send routing і сповіщення про channel + permissions у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає сирі stdio MCP-кадри безпосередньо, щоб smoke-тест відображав те, що міст справді надсилає. +- `pnpm test:perf:profile:main`: записує CPU profile для головного потоку Vitest (`.artifacts/vitest-main-profile`). +- `pnpm test:perf:profile:runner`: записує профілі CPU + heap для unit runner (`.artifacts/vitest-runner-profile`). +- Інтеграція Gateway: вмикається явно через `OPENCLAW_TEST_INCLUDE_GATEWAY=1 pnpm test` або `pnpm test:gateway`. +- `pnpm test:e2e`: запускає наскрізні smoke-тести gateway (парування multi-instance WS/HTTP/node). За замовчуванням використовує `threads` + `isolate: false` з адаптивною кількістю workers у `vitest.e2e.config.ts`; налаштовується через `OPENCLAW_E2E_WORKERS=`, а для докладних логів установіть `OPENCLAW_E2E_VERBOSE=1`. +- `pnpm test:live`: запускає live-тести провайдерів (minimax/zai). Потрібні API-ключі та `LIVE=1` (або специфічний для провайдера `*_LIVE_TEST=1`), щоб зняти пропуск. +- `pnpm test:docker:all`: один раз збирає спільний образ live-тестів і образ Docker E2E, а потім запускає Docker smoke lane з `OPENCLAW_SKIP_DOCKER_BUILD=1` із паралелізмом 4 за замовчуванням. Налаштовується через `OPENCLAW_DOCKER_ALL_PARALLELISM=`. Lane, чутливі до старту або провайдера, запускаються ексклюзивно після паралельного пулу. Логи для кожного lane записуються в `.artifacts/docker-tests//`. +- `pnpm test:docker:openwebui`: запускає Dockerized OpenClaw + Open WebUI, виконує вхід через Open WebUI, перевіряє `/api/models`, а потім запускає реальний проксійований чат через `/api/chat/completions`. Потрібен придатний ключ live-моделі (наприклад, OpenAI у `~/.profile`), підтягується зовнішній образ Open WebUI, і цей сценарій не очікується стабільним у CI так, як звичайні набори unit/e2e. +- `pnpm test:docker:mcp-channels`: запускає контейнер Gateway із наповненими даними та другий клієнтський контейнер, який піднімає `openclaw mcp serve`, а потім перевіряє виявлення маршрутизованих розмов, читання transcript, метадані вкладень, поведінку черги live-подій, маршрутизацію вихідних надсилань і сповіщення про channel + permissions у стилі Claude через реальний міст stdio. Перевірка сповіщень Claude читає сирі stdio MCP-фрейми безпосередньо, щоб smoke відображав те, що міст справді надсилає. ## Локальний PR gate -Для локальних перевірок перед приземленням PR/gate запустіть: +Для локальних перевірок перед злиттям PR запускайте: - `pnpm check:changed` - `pnpm check` @@ -53,7 +54,7 @@ x-i18n: - `pnpm test` - `pnpm check:docs` -Якщо `pnpm test` дає флейк на навантаженому хості, перезапустіть один раз, перш ніж вважати це регресією, а потім ізолюйте через `pnpm test `. Для хостів з обмеженою пам’яттю використовуйте: +Якщо `pnpm test` нестабільно проходить на навантаженому хості, перезапустіть його один раз, перш ніж вважати це регресією, а потім ізолюйте проблему через `pnpm test `. Для хостів з обмеженою пам’яттю використовуйте: - `OPENCLAW_VITEST_MAX_WORKERS=1 pnpm test` - `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/tmp/openclaw-vitest-cache pnpm test:changed` @@ -65,13 +66,13 @@ x-i18n: Використання: - `source ~/.profile && pnpm tsx scripts/bench-model.ts --runs 10` -- Необов’язкові env: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY` -- Типовий prompt: “Відповідай одним словом: ok. Без розділових знаків або додаткового тексту.” +- Необов’язкові змінні середовища: `MINIMAX_API_KEY`, `MINIMAX_BASE_URL`, `MINIMAX_MODEL`, `ANTHROPIC_API_KEY` +- Стандартний prompt: “Reply with a single word: ok. No punctuation or extra text.” Останній запуск (2025-12-31, 20 запусків): -- minimax median 1279ms (min 1114, max 2431) -- opus median 2454ms (min 1224, max 3170) +- median для minimax: 1279 мс (min 1114, max 2431) +- median для opus: 2454 мс (min 1224, max 3170) ## Benchmark запуску CLI @@ -94,31 +95,31 @@ x-i18n: - `pnpm tsx scripts/bench-cli-startup.ts --preset real --cpu-prof-dir .artifacts/cli-cpu` - `pnpm tsx scripts/bench-cli-startup.ts --json` -Набори preset: +Preset-и: - `startup`: `--version`, `--help`, `health`, `health --json`, `status --json`, `status` - `real`: `health`, `status`, `status --json`, `sessions`, `sessions --json`, `agents list --json`, `gateway status`, `gateway status --json`, `gateway health --json`, `config get gateway.port` -- `all`: обидва набори preset +- `all`: обидва preset-и -Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і підсумки max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують V8-профілі для кожного запуску, щоб вимірювання часу та збирання профілів використовували один і той самий harness. +Вивід містить `sampleCount`, avg, p50, p95, min/max, розподіл exit-code/signal і підсумки max RSS для кожної команди. Необов’язкові `--cpu-prof-dir` / `--heap-prof-dir` записують профілі V8 для кожного запуску, тож вимірювання часу та збирання профілів використовують один і той самий harness. -Умовності для збереженого виводу: +Домовленості щодо збережених результатів: -- `pnpm test:startup:bench:smoke` записує цільовий smoke-артефакт у `.artifacts/cli-startup-bench-smoke.json` +- `pnpm test:startup:bench:smoke` записує таргетований smoke-артефакт у `.artifacts/cli-startup-bench-smoke.json` - `pnpm test:startup:bench:save` записує артефакт повного набору в `.artifacts/cli-startup-bench-all.json`, використовуючи `runs=5` і `warmup=1` - `pnpm test:startup:bench:update` оновлює закомічений baseline fixture у `test/fixtures/cli-startup-bench.json`, використовуючи `runs=5` і `warmup=1` Закомічений fixture: - `test/fixtures/cli-startup-bench.json` -- Оновлення через `pnpm test:startup:bench:update` -- Порівняння поточних результатів із fixture через `pnpm test:startup:bench:check` +- Оновити можна через `pnpm test:startup:bench:update` +- Порівняти поточні результати з fixture можна через `pnpm test:startup:bench:check` ## Onboarding E2E (Docker) Docker необов’язковий; це потрібно лише для containerized smoke-тестів onboarding. -Повний cold-start flow у чистому Linux-контейнері: +Повний cold-start потік у чистому Linux-контейнері: ```bash scripts/e2e/onboard-docker.sh @@ -126,9 +127,9 @@ scripts/e2e/onboard-docker.sh Цей скрипт проходить інтерактивний майстер через pseudo-tty, перевіряє файли config/workspace/session, потім запускає gateway і виконує `openclaw health`. -## Smoke-тест імпорту QR (Docker) +## Smoke для QR-імпорту (Docker) -Гарантує, що `qrcode-terminal` завантажується в підтримуваних runtime Node у Docker (типово Node 24, сумісність із Node 22): +Гарантує, що `qrcode-terminal` завантажується в підтримуваних Docker-рантаймах Node (Node 24 за замовчуванням, Node 22 сумісний): ```bash pnpm test:docker:qr diff --git a/docs/uk/tools/plugin.md b/docs/uk/tools/plugin.md index 313318a87..f24d6f521 100644 --- a/docs/uk/tools/plugin.md +++ b/docs/uk/tools/plugin.md @@ -1,27 +1,27 @@ --- read_when: - - Установлення або налаштування plugin - - Розуміння правил виявлення та завантаження plugin - - Робота з bundle plugin, сумісними з Codex/Claude + - Встановлення або налаштування плагінів + - Розуміння виявлення плагінів і правил завантаження + - Робота з сумісними з Codex/Claude наборами плагінів sidebarTitle: Install and Configure -summary: Установлення, налаштування та керування plugin OpenClaw -title: Plugin +summary: Встановлюйте, налаштовуйте та керуйте плагінами OpenClaw +title: Плагіни x-i18n: - generated_at: "2026-04-23T06:48:27Z" + generated_at: "2026-04-23T13:33:23Z" model: gpt-5.4 provider: openai - source_hash: dc944b53654552ca5cf6132c6ef16c71745a7bffc249daccaee40c513e04209c + source_hash: 63aa1b5ed9e3aaa2117b78137a457582b00ea47d94af7da3780ddae38e8e3665 source_path: tools/plugin.md workflow: 15 --- -# Plugin +# Плагіни -Plugin розширюють OpenClaw новими можливостями: канали, провайдери моделей, +Плагіни розширюють OpenClaw новими можливостями: канали, провайдери моделей, інструменти, Skills, мовлення, транскрипція в реальному часі, голос у реальному часі, -media-understanding, генерація зображень, генерація відео, web fetch, web -search тощо. Деякі plugin є **core** (постачаються з OpenClaw), інші — -**external** (публікуються спільнотою в npm). +розуміння медіа, генерація зображень, генерація відео, отримання даних із вебу, вебпошук +та інше. Деякі плагіни є **core** (постачаються з OpenClaw), інші — +**external** (опубліковані в npm спільнотою). ## Швидкий старт @@ -32,12 +32,12 @@ search тощо. Деякі plugin є **core** (постачаються з Open ``` - + ```bash - # From npm + # З npm openclaw plugins install @openclaw/voice-call - # From a local directory or archive + # З локального каталогу або архіву openclaw plugins install ./my-plugin openclaw plugins install ./my-plugin.tgz ``` @@ -49,12 +49,12 @@ search тощо. Деякі plugin є **core** (постачаються з Open openclaw gateway restart ``` - Потім налаштуйте в `plugins.entries.\.config` у своєму файлі конфігурації. + Потім налаштуйте в `plugins.entries.\.config` у вашому файлі конфігурації. -Якщо ви віддаєте перевагу керуванню прямо з чату, увімкніть `commands.plugins: true` і використовуйте: +Якщо ви надаєте перевагу керуванню безпосередньо з чату, увімкніть `commands.plugins: true` і використовуйте: ```text /plugin install clawhub:@openclaw/voice-call @@ -62,39 +62,41 @@ search тощо. Деякі plugin є **core** (постачаються з Open /plugin enable voice-call ``` -Шлях установлення використовує той самий resolver, що й CLI: локальний шлях/архів, явний -`clawhub:` або звичайна специфікація пакета (спочатку ClawHub, потім резервний варіант npm). +Шлях установлення використовує той самий механізм визначення, що й CLI: локальний +шлях/архів, явний `clawhub:` або специфікація пакета без префікса +(спочатку ClawHub, потім резервний перехід на npm). -Якщо конфігурація недійсна, установлення зазвичай безпечно завершується відмовою й спрямовує вас до -`openclaw doctor --fix`. Єдиний виняток для відновлення — вузький шлях перевстановлення вбудованого plugin -для plugin, які явно підтримують +Якщо конфігурація некоректна, установлення зазвичай безпечно завершується з відмовою і вказує вам на +`openclaw doctor --fix`. Єдиний виняток для відновлення — вузький шлях перевстановлення вбудованого плагіна +для плагінів, які підтримують `openclaw.install.allowInvalidConfigRecovery`. -Пакетні встановлення OpenClaw не встановлюють завчасно все дерево runtime-залежностей кожного вбудованого plugin. -Коли вбудований plugin, що належить OpenClaw, активний через конфігурацію plugin, застарілу -конфігурацію каналу або маніфест із увімкненням за замовчуванням, під час запуску відновлюються -лише оголошені ним runtime-залежності перед імпортом. External plugin і користувацькі шляхи -завантаження все одно потрібно встановлювати через `openclaw plugins install`. +Упаковані встановлення OpenClaw не встановлюють завчасно все дерево залежностей +runtime кожного вбудованого плагіна. Коли вбудований плагін, що належить OpenClaw, активний через +конфігурацію плагіна, застарілу конфігурацію каналу або маніфест із увімкненням за замовчуванням, +під час запуску відновлюються лише оголошені runtime-залежності цього плагіна перед його імпортом. +External-плагіни та власні шляхи завантаження, як і раніше, потрібно встановлювати через +`openclaw plugins install`. -## Типи plugin +## Типи плагінів -OpenClaw розпізнає два формати plugin: +OpenClaw розпізнає два формати плагінів: -| Формат | Як це працює | Приклади | -| ---------- | ---------------------------------------------------------------- | ------------------------------------------------------ | -| **Native** | `openclaw.plugin.json` + runtime-модуль; виконується в процесі | Офіційні plugin, пакети npm від спільноти | -| **Bundle** | Сумісне з Codex/Claude/Cursor компонування; відображається на функції OpenClaw | `.codex-plugin/`, `.claude-plugin/`, `.cursor-plugin/` | +| Формат | Як це працює | Приклади | +| ---------- | --------------------------------------------------------------- | ------------------------------------------------------ | +| **Native** | `openclaw.plugin.json` + runtime-модуль; виконується в процесі | Офіційні плагіни, пакети npm від спільноти | +| **Bundle** | Сумісне компонування Codex/Claude/Cursor; зіставляється з можливостями OpenClaw | `.codex-plugin/`, `.claude-plugin/`, `.cursor-plugin/` | -Обидва відображаються в `openclaw plugins list`. Докладніше про bundle див. у [Plugin Bundles](/uk/plugins/bundles). +Обидва відображаються в `openclaw plugins list`. Докладніше про набори див. у [Набори плагінів](/uk/plugins/bundles). -Якщо ви пишете native plugin, почніть із [Building Plugins](/uk/plugins/building-plugins) -і [Plugin SDK Overview](/uk/plugins/sdk-overview). +Якщо ви пишете native-плагін, почніть із [Створення плагінів](/uk/plugins/building-plugins) +та [Огляд Plugin SDK](/uk/plugins/sdk-overview). -## Офіційні plugin +## Офіційні плагіни ### Доступні для встановлення (npm) -| Plugin | Пакет | Документація | +| Плагін | Пакет | Документація | | --------------- | --------------------- | ------------------------------------ | | Matrix | `@openclaw/matrix` | [Matrix](/uk/channels/matrix) | | Microsoft Teams | `@openclaw/msteams` | [Microsoft Teams](/uk/channels/msteams) | @@ -106,7 +108,7 @@ OpenClaw розпізнає два формати plugin: ### Core (постачаються з OpenClaw) - + `anthropic`, `byteplus`, `cloudflare-ai-gateway`, `github-copilot`, `google`, `huggingface`, `kilocode`, `kimi-coding`, `minimax`, `mistral`, `qwen`, `moonshot`, `nvidia`, `openai`, `opencode`, `opencode-go`, `openrouter`, @@ -114,22 +116,22 @@ OpenClaw розпізнає два формати plugin: `vercel-ai-gateway`, `volcengine`, `xiaomi`, `zai` - - - `memory-core` — вбудований memory search (стандартно через `plugins.slots.memory`) - - `memory-lancedb` — long-term memory з установленням на вимогу з auto-recall/capture (задайте `plugins.slots.memory = "memory-lancedb"`) + + - `memory-core` — вбудований пошук у пам’яті (типово через `plugins.slots.memory`) + - `memory-lancedb` — довготривала пам’ять з установленням за потреби з автоматичним пригадуванням/захопленням (установіть `plugins.slots.memory = "memory-lancedb"`) - + `elevenlabs`, `microsoft` - - `browser` — вбудований plugin браузера для інструмента browser, CLI `openclaw browser`, методу gateway `browser.request`, runtime браузера та стандартного сервісу керування браузером (увімкнений за замовчуванням; вимкніть перед заміною) - - `copilot-proxy` — міст VS Code Copilot Proxy (за замовчуванням вимкнений) + - `browser` — вбудований browser-плагін для browser-інструмента, CLI `openclaw browser`, методу Gateway `browser.request`, browser-runtime та служби керування browser за замовчуванням (увімкнено за замовчуванням; вимкніть перед його заміною) + - `copilot-proxy` — міст VS Code Copilot Proxy (вимкнено за замовчуванням) -Шукаєте сторонні plugin? Див. [Community Plugins](/uk/plugins/community). +Шукаєте сторонні плагіни? Див. [Плагіни спільноти](/uk/plugins/community). ## Конфігурація @@ -149,85 +151,85 @@ OpenClaw розпізнає два формати plugin: | Поле | Опис | | ---------------- | --------------------------------------------------------- | -| `enabled` | Головний перемикач (стандартно: `true`) | -| `allow` | Список дозволених plugin (необов’язково) | -| `deny` | Список заборонених plugin (необов’язково; deny має пріоритет) | -| `load.paths` | Додаткові файли/каталоги plugin | +| `enabled` | Головний перемикач (типово: `true`) | +| `allow` | Список дозволених плагінів (необов’язково) | +| `deny` | Список заборонених плагінів (необов’язково; deny має пріоритет) | +| `load.paths` | Додаткові файли/каталоги плагінів | | `slots` | Селектори ексклюзивних слотів (наприклад, `memory`, `contextEngine`) | -| `entries.\` | Перемикачі для окремих plugin + config | +| `entries.\` | Перемикачі та конфігурація для окремого плагіна | -Зміни конфігурації **потребують перезапуску gateway**. Якщо Gateway працює з відстеженням config -+ внутрішньопроцесним перезапуском (стандартний шлях `openclaw gateway`), цей -перезапуск зазвичай виконується автоматично невдовзі після застосування змін конфігурації. +Зміни конфігурації **потребують перезапуску Gateway**. Якщо Gateway запущено з +відстеженням конфігурації та внутрішньопроцесним перезапуском (типовий шлях `openclaw gateway`), +цей перезапуск зазвичай виконується автоматично невдовзі після запису конфігурації. - - - **Вимкнений**: plugin існує, але правила ввімкнення його вимкнули. Конфігурація зберігається. - - **Відсутній**: config посилається на id plugin, який під час виявлення не знайдено. - - **Недійсний**: plugin існує, але його config не відповідає оголошеній schema. + + - **Вимкнений**: плагін існує, але правила ввімкнення його вимкнули. Конфігурація зберігається. + - **Відсутній**: конфігурація посилається на ідентифікатор плагіна, який не було знайдено під час виявлення. + - **Недійсний**: плагін існує, але його конфігурація не відповідає оголошеній схемі. ## Виявлення та пріоритет -OpenClaw сканує plugin у такому порядку (перше збігання перемагає): +OpenClaw сканує плагіни в такому порядку (перше знайдене збіг має пріоритет): - - `plugins.load.paths` — явні шляхи до файлів або каталогів. + + `plugins.load.paths` — явні шляхи до файлу або каталогу. - + `\/.openclaw//*.ts` і `\/.openclaw//*/index.ts`. - + `~/.openclaw//*.ts` і `~/.openclaw//*/index.ts`. - - Постачаються з OpenClaw. Багато з них увімкнені за замовчуванням (провайдери моделей, мовлення). + + Постачаються з OpenClaw. Багато з них увімкнено за замовчуванням (провайдери моделей, мовлення). Інші потребують явного ввімкнення. ### Правила ввімкнення -- `plugins.enabled: false` вимикає всі plugin +- `plugins.enabled: false` вимикає всі плагіни - `plugins.deny` завжди має пріоритет над allow -- `plugins.entries.\.enabled: false` вимикає цей plugin -- Plugin із робочого простору **вимкнені за замовчуванням** (їх потрібно явно ввімкнути) -- Вбудовані plugin дотримуються вбудованого набору зі стандартним увімкненням, якщо не перевизначено -- Ексклюзивні слоти можуть примусово ввімкнути вибраний plugin для цього слота +- `plugins.entries.\.enabled: false` вимикає цей плагін +- Плагіни з робочого простору **типово вимкнені** (їх потрібно явно ввімкнути) +- Вбудовані плагіни дотримуються вбудованого набору, увімкненого за замовчуванням, якщо це не перевизначено +- Ексклюзивні слоти можуть примусово ввімкнути вибраний плагін для цього слота -## Слоти plugin (ексклюзивні категорії) +## Слоти плагінів (ексклюзивні категорії) -Деякі категорії є ексклюзивними (одночасно активний лише один): +Деякі категорії є ексклюзивними (одночасно може бути активним лише один): ```json5 { plugins: { slots: { - memory: "memory-core", // or "none" to disable - contextEngine: "legacy", // or a plugin id + memory: "memory-core", // або "none", щоб вимкнути + contextEngine: "legacy", // або id плагіна }, }, } ``` -| Слот | Що він контролює | Стандартно | -| --------------- | ----------------------- | ------------------- | -| `memory` | Активний plugin пам’яті | `memory-core` | +| Слот | Що він керує | Типове значення | +| --------------- | --------------------- | ------------------- | +| `memory` | Active Memory plugin | `memory-core` | | `contextEngine` | Активний рушій контексту | `legacy` (вбудований) | -## Довідник CLI +## Довідка CLI ```bash -openclaw plugins list # компактний inventory -openclaw plugins list --enabled # лише завантажені plugin -openclaw plugins list --verbose # детальні рядки для кожного plugin -openclaw plugins list --json # inventory у машиночитному форматі -openclaw plugins inspect # детальна інформація -openclaw plugins inspect --json # машиночитний формат -openclaw plugins inspect --all # таблиця по всьому набору +openclaw plugins list # компактний перелік +openclaw plugins list --enabled # лише завантажені плагіни +openclaw plugins list --verbose # рядки з подробицями для кожного плагіна +openclaw plugins list --json # машиночитаний перелік +openclaw plugins inspect # докладна інформація +openclaw plugins inspect --json # машиночитаний формат +openclaw plugins inspect --all # таблиця для всього набору openclaw plugins info # псевдонім inspect openclaw plugins doctor # діагностика @@ -235,15 +237,15 @@ openclaw plugins install # установити (спочат openclaw plugins install clawhub: # установити лише з ClawHub openclaw plugins install --force # перезаписати наявне встановлення openclaw plugins install # установити з локального шляху -openclaw plugins install -l # підключити посиланням (без копіювання) для розробки +openclaw plugins install -l # підключити (без копіювання) для розробки openclaw plugins install --marketplace openclaw plugins install --marketplace https://github.com// -openclaw plugins install --pin # зафіксувати точну розв’язану npm-специфікацію +openclaw plugins install --pin # записати точну визначену специфікацію npm openclaw plugins install --dangerously-force-unsafe-install -openclaw plugins update # оновити один plugin +openclaw plugins update # оновити один плагін openclaw plugins update --dangerously-force-unsafe-install openclaw plugins update --all # оновити всі -openclaw plugins uninstall # видалити записи config/встановлення +openclaw plugins uninstall # видалити записи конфігурації/встановлення openclaw plugins uninstall --keep-files openclaw plugins marketplace list openclaw plugins marketplace list --json @@ -252,54 +254,59 @@ openclaw plugins enable openclaw plugins disable ``` -Вбудовані plugin постачаються разом з OpenClaw. Багато з них увімкнені за замовчуванням (наприклад, -вбудовані провайдери моделей, вбудовані провайдери мовлення та вбудований browser -plugin). Інші вбудовані plugin усе ще потрібно вмикати через `openclaw plugins enable `. +Вбудовані плагіни постачаються з OpenClaw. Багато з них увімкнено за замовчуванням (наприклад, +вбудовані провайдери моделей, вбудовані провайдери мовлення та вбудований browser- +плагін). Інші вбудовані плагіни все одно потребують `openclaw plugins enable `. -`--force` перезаписує вже встановлений plugin або hook pack на місці. Використовуйте -`openclaw plugins update ` для звичайних оновлень відстежуваних npm -plugin. Параметр не підтримується разом із `--link`, який повторно використовує шлях до джерела -замість копіювання в керовану ціль встановлення. +`--force` перезаписує наявний встановлений плагін або набір хуків на місці. Використовуйте +`openclaw plugins update ` для звичайних оновлень відстежуваних npm- +плагінів. Він не підтримується разом із `--link`, який повторно використовує вихідний шлях +замість копіювання в кероване місце встановлення. + +Коли `plugins.allow` уже задано, `openclaw plugins install` додає +ідентифікатор встановленого плагіна до цього списку allow перед його ввімкненням, щоб установлені плагіни +можна було одразу завантажити після перезапуску. `openclaw plugins update ` застосовується до відстежуваних встановлень. Передавання -npm-специфікації пакета з dist-tag або точною версією дозволяє зіставити назву пакета -назад із записом відстежуваного plugin і зберегти нову специфікацію для майбутніх оновлень. -Передавання назви пакета без версії переводить точно зафіксоване npm-встановлення назад на -стандартну лінію випусків реєстру. Якщо встановлений npm plugin уже відповідає -розв’язаній версії та зафіксованій ідентичності artifact, OpenClaw пропускає оновлення -без завантаження, перевстановлення чи переписування config. +специфікації npm-пакета з dist-tag або точною версією зіставляє ім’я пакета +назад із записом відстежуваного плагіна та записує нову специфікацію для майбутніх оновлень. +Передавання імені пакета без версії переводить точно зафіксоване встановлення назад на +типову лінію випусків реєстру. Якщо встановлений npm-плагін уже відповідає +визначеній версії та записаній ідентичності артефакту, OpenClaw пропускає оновлення +без завантаження, перевстановлення або перезапису конфігурації. `--pin` працює лише для npm. Він не підтримується з `--marketplace`, оскільки -встановлення з marketplace зберігають метадані джерела marketplace, а не npm-специфікацію. +встановлення з marketplace зберігають метадані джерела marketplace замість специфікації npm. `--dangerously-force-unsafe-install` — це аварійне перевизначення для хибнопозитивних спрацювань вбудованого сканера небезпечного коду. Воно дозволяє продовжити встановлення -та оновлення plugin попри вбудовані findings рівня `critical`, але все одно -не обходить блокування політик plugin `before_install` або блокування через збої сканування. +та оновлення плагінів попри вбудовані результати рівня `critical`, але все одно +не обходить блокування політики плагіна `before_install` або блокування через збій сканування. -Цей прапорець CLI застосовується лише до потоків встановлення/оновлення plugin. Установлення залежностей Skills через Gateway -використовують натомість відповідне перевизначення запиту `dangerouslyForceUnsafeInstall`, тоді як `openclaw skills install` залишається окремим потоком завантаження/встановлення Skills із ClawHub. +Цей прапорець CLI застосовується лише до потоків встановлення/оновлення плагінів. Установлення +залежностей Skills через Gateway використовують натомість відповідне перевизначення запиту `dangerouslyForceUnsafeInstall`, тоді як `openclaw skills install` залишається окремим потоком +завантаження/встановлення Skills із ClawHub. -Сумісні bundle беруть участь у тих самих потоках list/inspect/enable/disable -для plugin. Поточна підтримка runtime включає bundle Skills, Claude command-Skills, -стандартні значення Claude `settings.json`, стандартні значення Claude `.lsp.json` і `lspServers`, оголошені в маніфесті, -Cursor command-Skills і сумісні каталоги hook Codex. +Сумісні набори беруть участь у тих самих потоках list/inspect/enable/disable +для плагінів. Поточна підтримка runtime включає bundle Skills, Claude command-skills, +значення за замовчуванням Claude `settings.json`, значення за замовчуванням Claude `.lsp.json` і оголошені в маніфесті +`lspServers`, Cursor command-skills і сумісні каталоги хуків Codex. -`openclaw plugins inspect ` також повідомляє про виявлені можливості bundle, а також -про підтримувані чи непідтримувані записи MCP і LSP server для plugin, що працюють через bundle. +`openclaw plugins inspect ` також повідомляє про виявлені можливості набору, а також +підтримувані або непідтримувані записи серверів MCP і LSP для плагінів на основі наборів. Джерелами marketplace можуть бути відома назва marketplace Claude з -`~/.claude/plugins/known_marketplaces.json`, локальний корінь marketplace або шлях до -`marketplace.json`, скорочений запис GitHub на кшталт `owner/repo`, URL репозиторію -GitHub або git URL. Для віддалених marketplace записи plugin мають залишатися всередині +`~/.claude/plugins/known_marketplaces.json`, локальний корінь marketplace або +шлях до `marketplace.json`, скорочений запис GitHub на кшталт `owner/repo`, URL репозиторію GitHub +або git URL. Для віддалених marketplace записи плагінів мають залишатися в межах клонованого репозиторію marketplace і використовувати лише відносні джерела шляхів. -Повні подробиці див. в [довіднику CLI `openclaw plugins`](/uk/cli/plugins). +Повні відомості див. у [довідці CLI `openclaw plugins`](/uk/cli/plugins). -## Огляд API plugin +## Огляд API плагінів -Native plugin експортують об’єкт entry, який надає `register(api)`. Старіші -plugin усе ще можуть використовувати `activate(api)` як застарілий псевдонім, але нові plugin мають +Native-плагіни експортують об’єкт entry, який надає `register(api)`. Старіші +плагіни все ще можуть використовувати `activate(api)` як застарілий псевдонім, але нові плагіни мають використовувати `register`. ```typescript @@ -321,48 +328,48 @@ export default definePluginEntry({ ``` OpenClaw завантажує об’єкт entry і викликає `register(api)` під час -активації plugin. Завантажувач і далі використовує резервний варіант `activate(api)` для старіших plugin, -але вбудовані plugin і нові external plugin мають розглядати `register` як +активації плагіна. Для старіших плагінів завантажувач усе ще використовує резервний перехід на `activate(api)`, +але вбудовані плагіни та нові external-плагіни мають розглядати `register` як публічний контракт. Поширені методи реєстрації: -| Метод | Що він реєструє | -| --------------------------------------- | --------------------------- | -| `registerProvider` | Провайдер моделі (LLM) | -| `registerChannel` | Чат-канал | -| `registerTool` | Інструмент агента | -| `registerHook` / `on(...)` | Хуки життєвого циклу | -| `registerSpeechProvider` | Text-to-speech / STT | -| `registerRealtimeTranscriptionProvider` | Потоковий STT | -| `registerRealtimeVoiceProvider` | Двосторонній голос у реальному часі | -| `registerMediaUnderstandingProvider` | Аналіз зображень/аудіо | -| `registerImageGenerationProvider` | Генерація зображень | -| `registerMusicGenerationProvider` | Генерація музики | -| `registerVideoGenerationProvider` | Генерація відео | -| `registerWebFetchProvider` | Провайдер web fetch / scrape | -| `registerWebSearchProvider` | Web search | -| `registerHttpRoute` | HTTP endpoint | -| `registerCommand` / `registerCli` | CLI-команди | -| `registerContextEngine` | Рушій контексту | -| `registerService` | Фоновий сервіс | +| Метод | Що він реєструє | +| --------------------------------------- | -------------------------- | +| `registerProvider` | Провайдер моделі (LLM) | +| `registerChannel` | Канал чату | +| `registerTool` | Інструмент агента | +| `registerHook` / `on(...)` | Хуки життєвого циклу | +| `registerSpeechProvider` | Синтез мовлення / STT | +| `registerRealtimeTranscriptionProvider` | Потоковий STT | +| `registerRealtimeVoiceProvider` | Двобічний голос у реальному часі | +| `registerMediaUnderstandingProvider` | Аналіз зображень/аудіо | +| `registerImageGenerationProvider` | Генерація зображень | +| `registerMusicGenerationProvider` | Генерація музики | +| `registerVideoGenerationProvider` | Генерація відео | +| `registerWebFetchProvider` | Провайдер отримання / збирання даних із вебу | +| `registerWebSearchProvider` | Вебпошук | +| `registerHttpRoute` | HTTP-ендпоінт | +| `registerCommand` / `registerCli` | Команди CLI | +| `registerContextEngine` | Рушій контексту | +| `registerService` | Фонова служба | -Поведінка guard хуків для типізованих хуків життєвого циклу: +Поведінка guard-хуків для типізованих хуків життєвого циклу: -- `before_tool_call`: `{ block: true }` є термінальним; handler нижчого пріоритету пропускаються. -- `before_tool_call`: `{ block: false }` нічого не робить і не скасовує раніше встановлене block. -- `before_install`: `{ block: true }` є термінальним; handler нижчого пріоритету пропускаються. -- `before_install`: `{ block: false }` нічого не робить і не скасовує раніше встановлене block. -- `message_sending`: `{ cancel: true }` є термінальним; handler нижчого пріоритету пропускаються. -- `message_sending`: `{ cancel: false }` нічого не робить і не скасовує раніше встановлене cancel. +- `before_tool_call`: `{ block: true }` є термінальним; обробники з нижчим пріоритетом пропускаються. +- `before_tool_call`: `{ block: false }` нічого не змінює і не скасовує попереднє блокування. +- `before_install`: `{ block: true }` є термінальним; обробники з нижчим пріоритетом пропускаються. +- `before_install`: `{ block: false }` нічого не змінює і не скасовує попереднє блокування. +- `message_sending`: `{ cancel: true }` є термінальним; обробники з нижчим пріоритетом пропускаються. +- `message_sending`: `{ cancel: false }` нічого не змінює і не скасовує попереднє скасування. -Повну поведінку типізованих хуків див. в [SDK Overview](/uk/plugins/sdk-overview#hook-decision-semantics). +Повну інформацію про поведінку типізованих хуків див. в [огляді SDK](/uk/plugins/sdk-overview#hook-decision-semantics). -## Пов’язане +## Пов’язані матеріали -- [Building Plugins](/uk/plugins/building-plugins) — створення власного plugin -- [Plugin Bundles](/uk/plugins/bundles) — сумісність bundle Codex/Claude/Cursor -- [Plugin Manifest](/uk/plugins/manifest) — schema маніфесту -- [Registering Tools](/uk/plugins/building-plugins#registering-agent-tools) — додавання інструментів агента в plugin -- [Plugin Internals](/uk/plugins/architecture) — модель можливостей і конвеєр завантаження -- [Community Plugins](/uk/plugins/community) — сторонні списки +- [Створення плагінів](/uk/plugins/building-plugins) — створіть власний плагін +- [Набори плагінів](/uk/plugins/bundles) — сумісність наборів Codex/Claude/Cursor +- [Маніфест Plugin](/uk/plugins/manifest) — схема маніфесту +- [Реєстрація інструментів](/uk/plugins/building-plugins#registering-agent-tools) — додавання інструментів агента в плагін +- [Внутрішня будова Plugin](/uk/plugins/architecture) — модель можливостей і конвеєр завантаження +- [Плагіни спільноти](/uk/plugins/community) — сторонні добірки diff --git a/docs/uk/tools/thinking.md b/docs/uk/tools/thinking.md index 2a9197443..70fea31a8 100644 --- a/docs/uk/tools/thinking.md +++ b/docs/uk/tools/thinking.md @@ -1,13 +1,13 @@ --- read_when: - - Налаштування рівнів мислення, режиму fast або обробки чи типових значень директив verbose -summary: Синтаксис директив для /think, /fast, /verbose, /trace і видимості міркувань + - Налаштування розбору директив мислення, швидкого режиму або докладного режиму чи значень за замовчуванням +summary: Синтаксис директив для /think, /fast, /verbose, /trace та видимості міркувань title: Рівні мислення x-i18n: - generated_at: "2026-04-23T07:13:38Z" + generated_at: "2026-04-23T13:33:19Z" model: gpt-5.4 provider: openai - source_hash: 66033bb9272c9b9ea8fc85dc91e33e95ce4c469c56a8cd10c19632a5aa8a2338 + source_hash: 4efe899f7b47244745a105583b3239effa7975fadd06bd7bcad6327afcc91207 source_path: tools/thinking.md workflow: 15 --- @@ -22,111 +22,111 @@ x-i18n: - low → «think hard» - medium → «think harder» - high → «ultrathink» (максимальний бюджет) - - xhigh → «ultrathink+» (GPT-5.2 + моделі Codex і зусилля Anthropic Claude Opus 4.7) - - adaptive → кероване провайдером адаптивне мислення (підтримується для Claude 4.6 на Anthropic/Bedrock і Anthropic Claude Opus 4.7) + - xhigh → «ultrathink+» (GPT-5.2 + Codex models і зусилля Anthropic Claude Opus 4.7) + - adaptive → adaptive thinking під керуванням провайдера (підтримується для Claude 4.6 на Anthropic/Bedrock і Anthropic Claude Opus 4.7) - max → максимальне міркування провайдера (наразі Anthropic Claude Opus 4.7) - `x-high`, `x_high`, `extra-high`, `extra high` і `extra_high` зіставляються з `xhigh`. - `highest` зіставляється з `high`. - Примітки щодо провайдерів: - - Меню та перемикачі мислення керуються профілями провайдерів. Plugin провайдерів оголошують точний набір рівнів для вибраної моделі, включно з мітками на кшталт двійкового `on`. - - `adaptive`, `xhigh` і `max` рекламуються лише для профілів провайдер/модель, які їх підтримують. Введені директиви з непідтримуваними рівнями відхиляються з переліком коректних варіантів для цієї моделі. - - Наявні збережені непідтримувані рівні переназначаються за рангом профілю провайдера. `adaptive` повертається до `medium` на моделях без adaptive, а `xhigh` і `max` повертаються до найбільшого підтримуваного рівня, відмінного від `off`, для вибраної моделі. + - Меню та перемикачі мислення керуються профілем провайдера. Plugin провайдера оголошують точний набір рівнів для вибраної моделі, включно з мітками, такими як бінарне `on`. + - `adaptive`, `xhigh` і `max` показуються лише для профілів провайдерів/моделей, які їх підтримують. Типізовані директиви для непідтримуваних рівнів відхиляються з валідними параметрами для цієї моделі. + - Наявні збережені непідтримувані рівні переназначаються за рангом профілю провайдера. `adaptive` повертається до `medium` на неадаптивних моделях, тоді як `xhigh` і `max` повертаються до найбільшого підтримуваного рівня, відмінного від `off`, для вибраної моделі. - Моделі Anthropic Claude 4.6 за замовчуванням використовують `adaptive`, якщо явний рівень мислення не задано. - - Anthropic Claude Opus 4.7 за замовчуванням не використовує adaptive thinking. Типове значення effort API залишається у власності провайдера, якщо ви явно не встановите рівень мислення. - - Anthropic Claude Opus 4.7 зіставляє `/think xhigh` з adaptive thinking плюс `output_config.effort: "xhigh"`, оскільки `/think` є директивою мислення, а `xhigh` — це налаштування effort для Opus 4.7. - - Anthropic Claude Opus 4.7 також підтримує `/think max`; це зіставляється з тим самим шляхом максимального effort, керованим провайдером. - - Моделі OpenAI GPT зіставляють `/think` через підтримку effort API Responses, специфічну для моделі. `/think off` надсилає `reasoning.effort: "none"` лише тоді, коли цільова модель це підтримує; інакше OpenClaw пропускає payload вимкненого reasoning замість надсилання непідтримуваного значення. - - MiniMax (`minimax/*`) на Anthropic-сумісному шляху потокової передачі за замовчуванням використовує `thinking: { type: "disabled" }`, якщо ви явно не встановите thinking у параметрах моделі або параметрах запиту. Це запобігає витоку дельт `reasoning_content` із нерідного Anthropic-формату потоку MiniMax. - - Z.AI (`zai/*`) підтримує лише двійкове thinking (`on`/`off`). Будь-який рівень, відмінний від `off`, розглядається як `on` (зіставляється з `low`). + - Anthropic Claude Opus 4.7 не використовує adaptive thinking за замовчуванням. Його стандартне значення зусилля API лишається під контролем провайдера, якщо ви явно не встановите рівень мислення. + - Anthropic Claude Opus 4.7 зіставляє `/think xhigh` з adaptive thinking плюс `output_config.effort: "xhigh"`, оскільки `/think` — це директива мислення, а `xhigh` — це налаштування зусилля Opus 4.7. + - Anthropic Claude Opus 4.7 також підтримує `/think max`; воно зіставляється з тим самим шляхом максимального зусилля під керуванням провайдера. + - Моделі OpenAI GPT зіставляють `/think` через підтримку зусилля Responses API, специфічну для моделі. `/think off` надсилає `reasoning.effort: "none"` лише тоді, коли цільова модель це підтримує; інакше OpenClaw пропускає вимкнений payload міркування замість надсилання непідтримуваного значення. + - MiniMax (`minimax/*`) на сумісному з Anthropic шляху потокової передачі за замовчуванням використовує `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`. ## Порядок визначення 1. Вбудована директива в повідомленні (застосовується лише до цього повідомлення). 2. Перевизначення сесії (встановлюється надсиланням повідомлення, що містить лише директиву). -3. Типове значення для агента (`agents.list[].thinkingDefault` у config). -4. Глобальне типове значення (`agents.defaults.thinkingDefault` у config). -5. Запасний варіант: типове значення, оголошене провайдером, якщо доступне, `low` для інших моделей каталогу, позначених як reasoning-capable, інакше `off`. +3. Значення за замовчуванням для агента (`agents.list[].thinkingDefault` у config). +4. Глобальне значення за замовчуванням (`agents.defaults.thinkingDefault` у config). +5. Резервне значення: оголошене провайдером значення за замовчуванням, якщо доступне; інакше моделі з підтримкою міркування визначаються як `medium` або найближчий підтримуваний рівень, відмінний від `off`, для цієї моделі, а моделі без міркування залишаються `off`. -## Установлення типового значення для сесії +## Встановлення значення за замовчуванням для сесії - Надішліть повідомлення, яке **містить лише** директиву (дозволено пробіли), наприклад `/think:medium` або `/t high`. -- Це закріплюється для поточної сесії (типово окремо для кожного відправника); очищується через `/think:off` або скидання через бездіяльність сесії. -- Надсилається відповідь-підтвердження (`Thinking level set to high.` / `Thinking disabled.`). Якщо рівень некоректний (наприклад, `/thinking big`), команду буде відхилено з підказкою, а стан сесії залишиться без змін. -- Надішліть `/think` (або `/think:`) без аргументу, щоб переглянути поточний рівень мислення. +- Воно закріплюється для поточної сесії (типово для конкретного відправника); скидається через `/think:off` або скидання через неактивність сесії. +- Надсилається відповідь-підтвердження (`Thinking level set to high.` / `Thinking disabled.`). Якщо рівень недійсний (наприклад, `/thinking big`), команда відхиляється з підказкою, а стан сесії залишається незмінним. +- Надішліть `/think` (або `/think:`) без аргументу, щоб побачити поточний рівень мислення. -## Застосування для агента +## Застосування за агентом -- **Вбудований Pi**: визначений рівень передається у runtime вбудованого агента Pi. +- **Вбудований Pi**: визначений рівень передається до внутрішньопроцесного середовища виконання агента 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. Вбудована/лише-директива `/fast on|off` 2. Перевизначення сесії - 3. Типове значення для агента (`agents.list[].fastModeDefault`) + 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 зіставляється з рівнями service tier 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, як і раніше, пропускає вставлення service tier Anthropic для базових URL не-Anthropic proxy. -- `/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 для проксі-базових URL, які не є Anthropic. +- `/status` показує `Fast` лише тоді, коли швидкий режим увімкнено. ## Докладні директиви (`/verbose` або `/v`) -- Рівні: `on` (мінімальний) | `full` | `off` (типово). -- Повідомлення лише з директивою перемикає verbose для сесії та повертає `Verbose logging enabled.` / `Verbose logging disabled.`; некоректні рівні повертають підказку без зміни стану. -- `/verbose off` зберігає явне перевизначення сесії; очистити його можна в UI Sessions, вибравши `inherit`. -- Вбудована директива застосовується лише до цього повідомлення; інакше діють типові значення сесії/глобальні. -- Надішліть `/verbose` (або `/verbose:`) без аргументу, щоб переглянути поточний рівень verbose. -- Коли verbose увімкнено, агенти, що видають структуровані результати інструментів (Pi, інші JSON-агенти), надсилають кожен виклик інструмента назад як окреме повідомлення лише з метаданими, із префіксом ` : `, коли доступно (шлях/команда). Ці зведення інструментів надсилаються щойно кожен інструмент запускається (окремими бульбашками), а не як дельти потоку. -- Зведення про збої інструментів залишаються видимими в нормальному режимі, але суфікси з необробленими деталями помилки приховуються, якщо verbose не має значення `on` або `full`. -- Коли verbose має значення `full`, результати інструментів також пересилаються після завершення (окрема бульбашка, обрізана до безпечної довжини). Якщо ви перемкнете `/verbose on|full|off`, поки виконання ще триває, наступні бульбашки інструментів врахують нове налаштування. +- Рівні: `on` (мінімальний) | `full` | `off` (за замовчуванням). +- Повідомлення лише з директивою перемикає докладний режим сесії та відповідає `Verbose logging enabled.` / `Verbose logging disabled.`; недійсні рівні повертають підказку без зміни стану. +- `/verbose off` зберігає явне перевизначення сесії; очистіть його через інтерфейс Sessions, вибравши `inherit`. +- Вбудована директива впливає лише на це повідомлення; інакше застосовуються значення за замовчуванням сесії/глобальні. +- Надішліть `/verbose` (або `/verbose:`) без аргументу, щоб побачити поточний рівень докладності. +- Коли verbose увімкнено, агенти, які генерують структуровані результати інструментів (Pi, інші JSON-агенти), надсилають кожен виклик інструмента назад як окреме повідомлення лише з метаданими з префіксом ` : `, коли доступно (path/command). Ці зведення інструментів надсилаються щойно кожен інструмент запускається (окремі бульбашки), а не як потокові дельти. +- Зведення про збої інструментів залишаються видимими у звичайному режимі, але сирі суфікси з деталями помилок приховані, якщо verbose не дорівнює `on` або `full`. +- Коли verbose має значення `full`, після завершення також пересилаються виходи інструментів (окрема бульбашка, обрізана до безпечної довжини). Якщо ви перемкнете `/verbose on|full|off` під час виконання, наступні бульбашки інструментів врахують нове налаштування. -## Директиви trace Plugin (`/trace`) +## Директиви трасування Plugin (`/trace`) -- Рівні: `on` | `off` (типово). -- Повідомлення лише з директивою перемикає вивід trace plugin для сесії та повертає `Plugin trace enabled.` / `Plugin trace disabled.`. -- Вбудована директива застосовується лише до цього повідомлення; інакше діють типові значення сесії/глобальні. -- Надішліть `/trace` (або `/trace:`) без аргументу, щоб переглянути поточний рівень trace. -- `/trace` вужчий за `/verbose`: він показує лише trace/debug-рядки, що належать plugin, наприклад підсумки налагодження Active Memory. -- Рядки trace можуть з’являтися в `/status` і як додаткове діагностичне повідомлення після звичайної відповіді помічника. +- Рівні: `on` | `off` (за замовчуванням). +- Повідомлення лише з директивою перемикає вивід трасування Plugin у сесії та відповідає `Plugin trace enabled.` / `Plugin trace disabled.`. +- Вбудована директива впливає лише на це повідомлення; інакше застосовуються значення за замовчуванням сесії/глобальні. +- Надішліть `/trace` (або `/trace:`) без аргументу, щоб побачити поточний рівень трасування. +- `/trace` вужчий за `/verbose`: він показує лише рядки трасування/налагодження, що належать Plugin, такі як зведення налагодження Active Memory. +- Рядки трасування можуть з’являтися в `/status` і як діагностичне повідомлення після звичайної відповіді помічника. ## Видимість міркувань (`/reasoning`) - Рівні: `on|off|stream`. -- Повідомлення лише з директивою перемикає показ блоків thinking у відповідях. -- Коли ввімкнено, reasoning надсилається як **окреме повідомлення** з префіксом `Reasoning:`. -- `stream` (лише Telegram): транслює reasoning у чернетку-бульбашку Telegram, поки генерується відповідь, а потім надсилає фінальну відповідь без reasoning. +- Повідомлення лише з директивою перемикає, чи показуються блоки мислення у відповідях. +- Коли ввімкнено, міркування надсилається як **окреме повідомлення** з префіксом `Reasoning:`. +- `stream` (лише Telegram): транслює міркування в чернетку-бульбашку Telegram, поки генерується відповідь, а потім надсилає фінальну відповідь без міркування. - Псевдонім: `/reason`. -- Надішліть `/reasoning` (або `/reasoning:`) без аргументу, щоб переглянути поточний рівень reasoning. -- Порядок визначення: вбудована директива, потім перевизначення сесії, потім типове значення для агента (`agents.list[].reasoningDefault`), потім запасний варіант (`off`). +- Надішліть `/reasoning` (або `/reasoning:`) без аргументу, щоб побачити поточний рівень видимості міркувань. +- Порядок визначення: вбудована директива, потім перевизначення сесії, потім значення за замовчуванням для агента (`agents.list[].reasoningDefault`), потім резервне значення (`off`). ## Пов’язане -- Документація про Elevated mode доступна в [Elevated mode](/uk/tools/elevated). +- Документація для підвищеного режиму міститься в [Підвищений режим](/uk/tools/elevated). ## Heartbeat -- Тіло probe Heartbeat — це налаштований prompt 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 застосовуються як зазвичай (але уникайте зміни типових значень сесії з heartbeat). -- Доставка Heartbeat за замовчуванням містить лише фінальний payload. Щоб також надсилати окреме повідомлення `Reasoning:` (коли доступне), установіть `agents.defaults.heartbeat.includeReasoning: true` або для окремого агента `agents.list[].heartbeat.includeReasoning: true`. +- Тіло запиту Heartbeat — це налаштований prompt 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 застосовуються як завжди (але уникайте зміни значень сесії за замовчуванням із heartbeat). +- Доставка Heartbeat за замовчуванням надсилає лише фінальний payload. Щоб також надсилати окреме повідомлення `Reasoning:` (коли доступне), встановіть `agents.defaults.heartbeat.includeReasoning: true` або для конкретного агента `agents.list[].heartbeat.includeReasoning: true`. -## UI вебчату +## Інтерфейс вебчату -- Селектор thinking у вебчаті віддзеркалює збережений рівень сесії зі сховища/конфігурації вхідної сесії під час завантаження сторінки. +- Селектор мислення у вебчаті віддзеркалює збережений рівень сесії зі сховища/конфігурації вхідної сесії під час завантаження сторінки. - Вибір іншого рівня негайно записує перевизначення сесії через `sessions.patch`; він не чекає наступного надсилання і не є одноразовим перевизначенням `thinkingOnce`. -- Перший варіант завжди має вигляд `Default ()`, де визначене типове значення походить із профілю thinking провайдера активної моделі сесії. -- Перемикач використовує `thinkingOptions`, повернені рядком сесії gateway. UI браузера не зберігає власний список regex провайдерів; набори рівнів, специфічні для моделі, належать plugin. +- Перший параметр завжди має вигляд `Default ()`, де визначене значення за замовчуванням походить із профілю мислення провайдера для активної моделі сесії плюс та сама резервна логіка, яку використовують `/status` і `session_status`. +- Перемикач використовує `thinkingOptions`, що повертаються рядком сесії Gateway. Інтерфейс браузера не веде власний список regex провайдерів; Plugin володіють наборами рівнів, специфічними для моделей. - `/think:` як і раніше працює та оновлює той самий збережений рівень сесії, тому директиви чату й перемикач залишаються синхронізованими. ## Профілі провайдерів -- Plugin провайдерів можуть надавати `resolveThinkingProfile(ctx)` для визначення підтримуваних рівнів і типового значення моделі. -- Кожен рівень профілю має збережений канонічний `id` (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `adaptive` або `max`) і може містити відображувану `label`. Двійкові провайдери використовують `{ id: "low", label: "on" }`. +- Plugin провайдерів можуть надавати `resolveThinkingProfile(ctx)` для визначення підтримуваних рівнів і значення за замовчуванням для моделі. +- Кожен рівень профілю має збережений канонічний `id` (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`, `adaptive` або `max`) і може містити відображувану `label`. Бінарні провайдери використовують `{ id: "low", label: "on" }`. - Опубліковані застарілі хуки (`supportsXHighThinking`, `isBinaryThinking` і `resolveDefaultThinkingLevel`) залишаються адаптерами сумісності, але нові користувацькі набори рівнів мають використовувати `resolveThinkingProfile`. -- Рядки Gateway показують `thinkingOptions` і `thinkingDefault`, щоб клієнти ACP/чату відображали той самий профіль, який використовує перевірка runtime. +- Рядки Gateway показують `thinkingOptions` і `thinkingDefault`, щоб клієнти ACP/чату відображали той самий профіль, який використовує перевірка середовища виконання.