From 629d551da21d905cce18fdcfabcb6af3216dc051 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Sat, 2 May 2026 19:01:04 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/ci.md | 422 ++++----- docs/uk/cli/doctor.md | 67 +- docs/uk/cli/skills.md | 64 +- docs/uk/gateway/doctor.md | 425 +++++----- docs/uk/help/testing-updates-plugins.md | 226 +++-- docs/uk/help/testing.md | 847 ++++++++++--------- docs/uk/reference/RELEASING.md | 656 +++++++------- docs/uk/reference/full-release-validation.md | 193 +++-- docs/uk/reference/test.md | 120 +-- docs/uk/tools/skills.md | 288 ++++--- 10 files changed, 1703 insertions(+), 1605 deletions(-) diff --git a/docs/uk/ci.md b/docs/uk/ci.md index c73b26d2f..c67c191b9 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,94 +1,94 @@ --- read_when: - - Вам потрібно зрозуміти, чому завдання CI виконалося або не виконалося - - Ви налагоджуєте перевірку GitHub Actions, яка не проходить - - Ви координуєте запуск або повторний запуск валідації релізу + - Потрібно зрозуміти, чому завдання CI запустилося або не запустилося + - Ви налагоджуєте невдалу перевірку GitHub Actions + - Ви координуєте запуск або повторний запуск перевірки релізу - Ви змінюєте диспетчеризацію ClawSweeper або пересилання активності GitHub -summary: Граф завдань CI, гейти області дії, парасольки релізів і локальні еквіваленти команд +summary: Граф завдань безперервної інтеграції, межі області дії, релізні парасольки та локальні еквіваленти команд title: Конвеєр CI x-i18n: - generated_at: "2026-05-02T17:33:52Z" + generated_at: "2026-05-02T18:57:59Z" model: gpt-5.5 provider: openai - source_hash: 9ad5c8b39c21bf3fe6124c64938768efe4b77ef640e8207ef672a80c10291137 + source_hash: 8533e12d2ea99c6c342db46452bc448099c75e4bfc78edbb4b582118567421fd source_path: ci.md workflow: 16 --- -OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає витратні лінії, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно оминають розумне обмеження області й розгортають повний граф для кандидатів на випуск і широкої валідації. Лінії Android залишаються опціональними через `include_android`. Покриття Plugin лише для випусків міститься в окремому workflow [`Попередній випуск Plugin`](#plugin-prerelease) і запускається лише з [`Повної валідації випуску`](#full-release-validation) або явного ручного dispatch. +OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі лінії, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області та розгортають повний граф для кандидатів на реліз і широкої валідації. Лінії Android залишаються opt-in через `include_android`. Покриття Plugin лише для релізів живе в окремому workflow [`Передреліз Plugin`](#plugin-prerelease) і запускається лише з [`Повної валідації релізу`](#full-release-validation) або явного ручного dispatch. ## Огляд pipeline -| Завдання | Призначення | Коли запускається | -| -------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------- | -| `preflight` | Виявляє зміни лише в документації, змінені області, змінені extensions і створює CI-маніфест | Завжди для non-draft push і PR | -| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для non-draft push і PR | -| `security-dependency-audit` | Аудит production lockfile без залежностей щодо npm advisories | Завжди для non-draft push і PR | -| `security-fast` | Обов’язкова агрегація для швидких завдань безпеки | Завжди для non-draft push і PR | -| `check-dependencies` | Production-перевірка Knip лише для залежностей плюс guard allowlist невикористаних файлів | Зміни, релевантні для Node | -| `build-artifacts` | Збирання `dist/`, Control UI, перевірки зібраних артефактів і багаторазові downstream-артефакти | Зміни, релевантні для Node | -| `checks-fast-core` | Швидкі лінії коректності Linux, як-от bundled/plugin-contract/protocol перевірки | Зміни, релевантні для Node | -| `checks-fast-contracts-channels` | Sharded перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node | -| `checks-node-core-test` | Shard-и core Node тестів, окрім ліній channel, bundled, contract і extension | Зміни, релевантні для Node | -| `check` | Sharded еквівалент головного локального gate: production-типи, lint, guards, test-типи та strict smoke | Зміни, релевантні для Node | -| `check-additional` | Shard-и архітектури, меж, guards поверхні extension, package-boundary і gateway-watch | Зміни, релевантні для Node | -| `build-smoke` | Smoke-тести зібраного CLI і smoke запуску з пам’яттю | Зміни, релевантні для Node | -| `checks` | Верифікатор для channel-тестів зібраних артефактів | Зміни, релевантні для Node | -| `checks-node-compat-node22` | Лінія збирання сумісності Node 22 і smoke | Ручний CI dispatch для випусків | -| `check-docs` | Форматування документації, lint і перевірки битих посилань | Документацію змінено | -| `skills-python` | Ruff + pytest для skills на базі Python | Зміни, релевантні для Python-skill | -| `checks-windows` | Специфічні для Windows тести процесів/шляхів плюс regressions спільних runtime import specifier | Зміни, релевантні для Windows | -| `macos-node` | Лінія macOS TypeScript тестів із використанням спільних зібраних артефактів | Зміни, релевантні для macOS | -| `macos-swift` | Swift lint, збирання і тести для macOS app | Зміни, релевантні для macOS | -| `android` | Android unit-тести для обох flavors плюс одне збирання debug APK | Зміни, релевантні для Android | -| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успіх Main CI або ручний dispatch | -| `openclaw-performance` | Щоденні/на вимогу звіти продуктивності runtime Kova з mock-provider, deep-profile і live-лініями GPT 5.4 | Запланований і ручний dispatch | +| Завдання | Призначення | Коли запускається | +| -------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------- | +| `preflight` | Виявляє зміни лише в документації, змінені області, змінені extensions і збирає маніфест CI | Завжди для non-draft push і PR | +| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для non-draft push і PR | +| `security-dependency-audit` | Аудит production lockfile без встановлення залежностей щодо npm advisories | Завжди для non-draft push і PR | +| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для non-draft push і PR | +| `check-dependencies` | Production-прохід Knip лише для залежностей плюс guard allowlist невикористаних файлів | Зміни, релевантні для Node | +| `build-artifacts` | Збірка `dist/`, Control UI, перевірки зібраних артефактів і багаторазові downstream-артефакти | Зміни, релевантні для Node | +| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от bundled/plugin-contract/protocol перевірки | Зміни, релевантні для Node | +| `checks-fast-contracts-channels` | Sharded перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node | +| `checks-node-core-test` | Shards основних тестів Node, без ліній каналів, bundled, contract і extension | Зміни, релевантні для Node | +| `check` | Sharded еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Зміни, релевантні для Node | +| `check-additional` | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards | Зміни, релевантні для Node | +| `build-smoke` | Smoke-тести зібраного CLI і startup-memory smoke | Зміни, релевантні для Node | +| `checks` | Verifier для тестів каналів зібраних артефактів | Зміни, релевантні для Node | +| `checks-node-compat-node22` | Збірка сумісності з Node 22 і smoke-лінія | Ручний CI dispatch для релізів | +| `check-docs` | Форматування документації, lint і перевірки битих посилань | Документацію змінено | +| `skills-python` | Ruff + pytest для skills на базі Python | Зміни, релевантні для Python skills | +| `checks-windows` | Windows-специфічні тести process/path плюс регресії спільних runtime import specifiers | Зміни, релевантні для Windows | +| `macos-node` | Лінія TypeScript-тестів macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS | +| `macos-swift` | Swift lint, build і tests для застосунку macOS | Зміни, релевантні для macOS | +| `android` | Android unit tests для обох flavors плюс одна debug APK build | Зміни, релевантні для Android | +| `test-performance-agent` | Щоденна Codex-оптимізація повільних тестів після довіреної активності | Успіх Main CI або ручний dispatch | +| `openclaw-performance` | Щоденні/on-demand звіти продуктивності Kova runtime з mock-provider, deep-profile і GPT 5.4 live lanes | Запланований і ручний dispatch | ## Порядок 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 consumers могли стартувати щойно спільне збирання буде готове. -4. Важчі лінії платформ і runtime розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +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-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. -GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє до того самого PR або ref `main`. Вважайте це шумом CI, якщо найновіший запуск для того самого ref також не падає. Агреговані перевірки shard-ів використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні збої shard-ів, але не стають у чергу після того, як увесь workflow уже замінено. Автоматичний ключ конкурентності CI версійований (`CI-v7-*`), тому zombie на стороні GitHub у старій queue group не може нескінченно блокувати новіші main-запуски. Ручні запуски повного набору використовують `CI-manual-v1-*` і не скасовують запуски, що вже виконуються. +GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо найновіший запуск для того самого ref також не падає. Агреговані перевірки shards використовують `!cancelled() && always()`, тому вони й далі повідомляють звичайні збої shards, але не стають у чергу після того, як весь workflow уже замінено. Автоматичний ключ concurrency CI має версію (`CI-v7-*`), тому zombie з боку GitHub у старій queue group не може безстроково блокувати новіші запуски main. Ручні запуски повного набору використовують `CI-manual-v1-*` і не скасовують запуски, що вже виконуються. ## Область і маршрутизація -Логіка області міститься в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`. Ручний dispatch пропускає виявлення changed-scope і змушує preflight-маніфест поводитися так, ніби змінилася кожна scoped-ділянка. +Логіка області живе в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Ручний dispatch пропускає виявлення changed-scope і змушує маніфест preflight діяти так, ніби кожну scoped area було змінено. -- **Редагування CI workflow** валідують Node CI graph плюс workflow linting, але самі собою не примушують запускати Windows, Android або macOS native builds; ці платформні лінії залишаються обмеженими змінами platform source. -- **Редагування лише CI routing, вибрані дешеві редагування core-test fixture і вузькі редагування plugin contract helper/test-routing** використовують швидкий Node-only шлях маніфесту: `preflight`, security і одне завдання `checks-fast-core`. Цей шлях пропускає build artifacts, сумісність Node 22, channel contracts, повні core shards, bundled-plugin shards і додаткові guard matrices, коли зміна обмежена routing або helper surfaces, які швидке завдання перевіряє напряму. -- **Windows Node checks** обмежені специфічними для Windows wrappers процесів/шляхів, npm/pnpm/UI runner helpers, package manager config і поверхнями CI workflow, що виконують цю лінію; непов’язані зміни source, plugin, install-smoke і test-only залишаються на Linux Node lanes. +- **Зміни CI workflow** валідують граф Node CI плюс workflow linting, але самі по собі не примушують Windows, Android або macOS native builds; ці платформні лінії залишаються прив’язаними до змін платформного source. +- **CI routing-only edits, вибрані дешеві core-test fixture edits і вузькі plugin contract helper/test-routing edits** використовують швидкий шлях маніфесту лише для Node: `preflight`, security і одне завдання `checks-fast-core`. Цей шлях пропускає build artifacts, Node 22 compatibility, channel contracts, full core shards, bundled-plugin shards і додаткові guard matrices, коли зміна обмежена routing або helper surfaces, які fast task перевіряє напряму. +- **Windows Node checks** прив’язані до Windows-специфічних process/path wrappers, npm/pnpm/UI runner helpers, package manager config і поверхонь CI workflow, які виконують цю лінію; непов’язані source, plugin, install-smoke і test-only зміни залишаються на Linux Node lines. -Найповільніші сімейства Node тестів розділено або збалансовано, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts запускаються як три 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 використовують свої виділені Vitest configs замість спільного plugin catch-all. Include-pattern shards записують timing entries із CI shard name, щоб `.artifacts/vitest-shard-timings.json` міг відрізнити цілий config від відфільтрованого shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards конкурентно всередині одного завдання. Gateway watch, channel tests і core support-boundary shard запускаються конкурентно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані. +Найповільніші сімейства тестів Node розділені або збалансовані так, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts виконуються як три weighted shards, small 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. Broad browser, QA, media і різні plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. 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; shard boundary guard запускає свої малі незалежні guards паралельно всередині одного завдання. Gateway watch, channel tests і core support-boundary shard запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрано. -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-релевантного push. +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-релевантному push. -Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production-перевірку Knip лише для залежностей, pinned до найновішої версії Knip, з вимкненим minimum release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip із `scripts/deadcode-unused-files.allowlist.mjs`. Guard невикористаних файлів падає, коли PR додає новий непереглянутий невикористаний файл або залишає застарілий запис allowlist, зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може розв’язати статично. +Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, закріплений на latest Knip version, із вимкненим minimum release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий неперевірений unused file або залишає stale allowlist entry, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично resolve. -## Передавання активності ClawSweeper +## Перенаправлення активності ClawSweeper -`.github/workflows/clawsweeper-dispatch.yml` — це target-side міст від активності репозиторію OpenClaw до ClawSweeper. Він не checkout-ить і не виконує недовірений код pull request. Workflow створює token GitHub App із `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім надсилає compact payloads `repository_dispatch` до `openclaw/clawsweeper`. +`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge з активності репозиторію OpenClaw до ClawSweeper. Він не виконує checkout і не запускає недовірений код pull request. Workflow створює GitHub App token з `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім відправляє компактні payloads `repository_dispatch` до `openclaw/clawsweeper`. Workflow має чотири лінії: -- `clawsweeper_item` для точних запитів на review issue і pull request; +- `clawsweeper_item` для точних запитів review issue і pull request; - `clawsweeper_comment` для явних команд ClawSweeper у коментарях issue; -- `clawsweeper_commit_review` для commit-level review requests на push до `main`; -- `github_activity` для загальної активності GitHub, яку агент ClawSweeper може інспектувати. +- `clawsweeper_commit_review` для запитів review на рівні commit у push до `main`; +- `github_activity` для загальної активності GitHub, яку агент ClawSweeper може перевірити. -Лінія `github_activity` передає лише нормалізовані метадані: event type, action, actor, repository, item number, URL, title, state і короткі уривки для comments або reviews, коли вони присутні. Вона навмисно уникає передавання повного webhook body. Receiving workflow у `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який публікує нормалізовану подію до OpenClaw Gateway hook для агента ClawSweeper. +Лінія `github_activity` пересилає лише нормалізовані metadata: event type, action, actor, repository, item number, URL, title, state і короткі excerpts для comments або reviews, коли вони присутні. Вона навмисно уникає пересилання повного webhook body. Приймальний workflow у `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який надсилає нормалізовану event до OpenClaw Gateway hook для агента ClawSweeper. -Загальна активність є спостереженням, а не доставленням за замовчуванням. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли подія є несподіваною, actionable, risky або operationally useful. Routine opens, edits, bot churn, duplicate webhook noise і normal review traffic мають давати результат `NO_REPLY`. +Загальна активність є спостереженням, а не доставкою за замовчуванням. Агент ClawSweeper отримує Discord target у своєму prompt і має писати до `#clawsweeper` лише тоді, коли event є несподіваною, actionable, risky або operationally useful. Рутинні відкриття, edits, bot churn, duplicate webhook noise і звичайний review traffic мають завершуватися `NO_REPLY`. -Вважайте GitHub titles, comments, bodies, review text, branch names і commit messages недовіреними даними на всьому цьому шляху. Вони є input для summarization і triage, а не інструкціями для workflow або agent runtime. +Скрізь на цьому шляху вважайте GitHub titles, comments, bodies, review text, branch names і commit messages недовіреними даними. Це input для summarization і triage, а не instructions для workflow або agent runtime. ## Ручні dispatches -Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну не-Android scoped lane: шарди Linux Node, шарди bundled-plugin, контракти каналів, сумісність Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python skills, Windows, macOS і i18n Control UI. Окремі ручні запуски CI виконують лише Android із `include_android=true`; повна релізна парасолька вмикає Android, передаючи `include_android=true`. Статичні перевірки передрелізу Plugin, релізний лише шард `agentic-plugins`, повний пакетний sweep розширень і Docker lanes передрелізу Plugin виключено з CI. Передрелізний набір Docker запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate перевірки релізу. +Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну не-Android lane з обмеженою областю: Linux Node шарди, шарди вбудованих Plugin, контракти каналів, сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python Skills, Windows, macOS і i18n Control UI. Окремі ручні запуски CI виконують лише Android з `include_android=true`; повна релізна парасолька вмикає Android через передавання `include_android=true`. Статичні перевірки передрелізу Plugin, релізний шард `agentic-plugins`, повний пакетний sweep розширень і Docker lanes передрелізу Plugin виключені з CI. Передрелізний набір Docker запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate перевірки релізу. -Ручні запуски використовують унікальну concurrency group, тому повний набір release-candidate не скасовується іншим push або запуском PR на тому самому ref. Необов'язковий ввід `target_ref` дає довіреному викликачеві змогу запускати цей граф для гілки, тега або повного commit SHA, використовуючи файл workflow з вибраного dispatch ref. +Ручні запуски використовують унікальну групу конкурентності, щоб повний набір release-candidate не скасовувався іншим push або PR запуском на тому самому ref. Необов’язковий ввід `target_ref` дає довіреному виклику змогу запустити цей граф для гілки, тегу або повного SHA коміту, використовуючи файл workflow з вибраного dispatch ref. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -96,19 +96,19 @@ gh workflow run ci.yml --ref main -f target_ref= -f include_andro gh workflow run full-release-validation.yml --ref main -f ref= ``` -## Runners +## Ранери -| Runner | Завдання | +| Ранер | Завдання | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколів/контрактів/bundled, шардовані перевірки контрактів каналів, шарди `check`, крім lint, шарди й агрегати `check-additional`, перевіряльники агрегатів тестів Node, перевірки документації, Python skills, workflow-sanity, labeler, auto-response; preflight install-smoke також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла стати в чергу раніше | +| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контрактів/вбудованих пакетів, шардовані перевірки контрактів каналів, шарди `check`, крім lint, шарди та агрегати `check-additional`, верифікатори агрегатів тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб матриця Blacksmith могла стати в чергу раніше | | `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, легші шарди розширень, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | -| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів bundled plugin, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо CPU-чутливий, що 8 vCPU коштували більше, ніж заощаджували); Docker builds install-smoke (час черги 32-vCPU коштував більше, ніж заощаджував) | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, шарди тестів Linux Node, шарди тестів вбудованих Plugin, `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`; forks повертаються до `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks повертаються до `macos-latest` | +| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; форки повертаються до `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; форки повертаються до `macos-latest` | -## Локальні еквіваленти +## Локальні відповідники ```bash pnpm changed:lanes # inspect the local changed-lane classifier for origin/main...HEAD @@ -146,27 +146,27 @@ gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 Workflow встановлює OCM із закріпленого релізу та Kova із закріпленого вводу `kova_ref`, а потім запускає три lanes: -- `mock-provider`: діагностичні сценарії Kova проти runtime локальної збірки з детермінованою фіктивною OpenAI-сумісною автентифікацією. -- `mock-deep-profile`: CPU/heap/trace профілювання для гарячих точок startup, gateway і agent-turn. -- `live-gpt54`: реальний agent turn OpenAI `openai/gpt-5.4`, пропускається, коли `OPENAI_API_KEY` недоступний. +- `mock-provider`: діагностичні сценарії Kova проти runtime локальної збірки з детермінованою фейковою OpenAI-сумісною автентифікацією. +- `mock-deep-profile`: профілювання CPU/heap/trace для гарячих точок запуску, Gateway і agent-turn. +- `live-gpt54`: реальний agent turn OpenAI `openai/gpt-5.4`, який пропускається, коли `OPENAI_API_KEY` недоступний. -Lane mock-provider також запускає нативні source probes OpenClaw після проходу Kova: час запуску Gateway і пам'ять у випадках default, hook і запуску з 50-plugin; повторювані цикли hello mock-OpenAI `channel-chat-baseline`; і команди запуску CLI проти запущеного Gateway. Markdown-зведення source probe міститься в `source/index.md` у report bundle, поруч із сирим JSON. +Lane mock-provider також запускає source probes, рідні для OpenClaw, після проходу Kova: час завантаження Gateway і пам’ять для типових випадків startup default, hook і 50 Plugin; повторювані mock-OpenAI цикли hello `channel-chat-baseline`; і команди запуску CLI проти завантаженого Gateway. Markdown-зведення source probe міститься в `source/index.md` у report bundle, поруч із сирим JSON. -Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і artifacts source-probe в `openclaw/clawgrit-reports` під `openclaw-performance//-//`. Поточний branch pointer записується як `openclaw-performance//latest-.json`. +Кожна lane завантажує GitHub artifacts. Коли `CLAWGRIT_REPORTS_TOKEN` налаштовано, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і artifacts source-probe в `openclaw/clawgrit-reports` під `openclaw-performance//-//`. Поточний покажчик гілки записується як `openclaw-performance//latest-.json`. ## Повна перевірка релізу -`Full Release Validation` — це ручний парасольковий workflow для "запустити все перед релізом". Він приймає гілку, тег або повний commit SHA, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного лише proof plugin/package/static/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker release-path, live/E2E, OpenWebUI, parity QA Lab, Matrix і Telegram lanes. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` з release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму package lane Telegram проти опублікованого npm package. +`Full Release Validation` — це ручний umbrella workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для релізного proof Plugin/пакетів/статики/Docker, а також запускає `OpenClaw Release Checks` для install smoke, package acceptance, Docker release-path наборів, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram lanes. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` із release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму Telegram package lane проти опублікованого npm пакета. -Див. [повну перевірку релізу](/uk/reference/full-release-validation) для +Див. [Повна перевірка релізу](/uk/reference/full-release-validation) для матриці етапів, точних назв завдань workflow, відмінностей профілів, artifacts і цільових дескрипторів повторного запуску. `OpenClaw Release Publish` — це ручний мутувальний релізний workflow. Запускайте його -з `release/YYYY.M.D` або `main` після того, як існує release tag, і після того, як +з `release/YYYY.M.D` або `main` після того, як релізний тег уже існує і після того, як OpenClaw npm preflight успішно завершився. Він перевіряє `pnpm plugins:sync:check`, -запускає `Plugin NPM Release` для всіх публіковних plugin packages, запускає -`Plugin ClawHub Release` для того самого release SHA і лише потім запускає +запускає `Plugin NPM Release` для всіх публіковних Plugin-пакетів, запускає +`Plugin ClawHub Release` для того самого SHA релізу і лише після цього запускає `OpenClaw NPM Release` зі збереженим `preflight_run_id`. ```bash @@ -177,47 +177,47 @@ gh workflow run openclaw-release-publish.yml \ -f npm_dist_tag=beta ``` -Для pinned commit proof на швидкозмінній гілці використовуйте helper замість +Для proof закріпленого коміту на гілці, що швидко змінюється, використовуйте helper замість `gh workflow run ... --ref main -f ref=`: ```bash pnpm ci:full-release --sha ``` -Dispatch refs workflow GitHub мають бути гілками або тегами, а не сирими commit SHA. -Helper пушить тимчасову гілку `release-ci/-...` на target SHA, -запускає `Full Release Validation` з цього pinned ref, перевіряє, що `headSha` кожного дочірнього -workflow збігається з target, і видаляє тимчасову гілку, коли -run завершується. Парасольковий verifier також завершується з помилкою, якщо будь-який дочірній workflow виконувався на +GitHub workflow dispatch refs мають бути гілками або тегами, а не сирими SHA комітів. Helper +пушить тимчасову гілку `release-ci/-...` на цільовому SHA, +запускає `Full Release Validation` із цього закріпленого ref, перевіряє, що кожен дочірній +workflow `headSha` збігається з ціллю, і видаляє тимчасову гілку після завершення +запуску. Umbrella verifier також завершується помилкою, якщо будь-який дочірній workflow виконувався на іншому SHA. -`release_profile` керує шириною live/provider, переданою в release checks. Ручні -релізні workflows типово використовують `stable`; використовуйте `full` лише тоді, коли ви -навмисно хочете широку advisory provider/media matrix. +`release_profile` керує шириною live/provider, що передається в release checks. Ручні +релізні workflows типово використовують `stable`; використовуйте `full` лише тоді, коли +навмисно потрібна широка advisory матриця provider/media. - `minimum` залишає найшвидші критичні для релізу lanes OpenAI/core. - `stable` додає стабільний набір provider/backend. -- `full` запускає широку advisory provider/media matrix. +- `full` запускає широку advisory матрицю provider/media. -Парасолька записує IDs запущених дочірніх run, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх run і додає таблиці найповільніших завдань для кожного дочірнього run. Якщо дочірній workflow повторно запущено і він став green, повторно запустіть лише батьківське verifier job, щоб оновити результат парасольки й зведення timings. +Umbrella записує ids запущених дочірніх run, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх run і додає таблиці найповільніших завдань для кожного дочірнього run. Якщо дочірній workflow запускають повторно і він стає green, повторно запустіть лише батьківське завдання verifier, щоб оновити результат umbrella і зведення часу. -Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата релізу, `ci` лише для звичайного дочірнього повного CI, `plugin-prerelease` лише для дочірнього prerelease Plugin, `release-checks` для кожного дочірнього релізу або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` або `npm-telegram` в umbrella. Це утримує повторний запуск невдалого release box у межах після цільового виправлення. +Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для кандидата на реліз, `ci` лише для звичайного дочірнього завдання повного CI, `plugin-prerelease` лише для дочірнього завдання попереднього релізу Plugin, `release-checks` для кожного дочірнього завдання релізу або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` на парасольковому запуску. Це обмежує повторний запуск невдалого релізного бокса після цілеспрямованого виправлення. -`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і до live/E2E Docker workflow release path, і до package acceptance shard. Це зберігає package bytes узгодженими між release boxes і уникає повторного пакування того самого кандидата в кількох дочірніх jobs. +`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і до workflow Docker для live/E2E релізного шляху, і до шарда приймання пакета. Це зберігає байти пакета узгодженими між релізними боксами й уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. Дублікати запусків `Full Release Validation` для `ref=main` і `rerun_group=all` -замінюють старіший umbrella. Parent monitor скасовує будь-який дочірній workflow, -який він уже dispatch, коли parent скасовано, тож новіша валідація main -не чекає позаду застарілого двогодинного запуску release-check. Валідація release branch/tag -і цільові rerun groups зберігають `cancel-in-progress: false`. +замінюють старіший парасольковий запуск. Батьківський монітор скасовує будь-який дочірній workflow, який +він уже запустив, коли батьківський запуск скасовано, тож новіша валідація main +не чекає за застарілим двогодинним запуском release-check. Валідація релізної гілки/тега +та цілеспрямовані групи повторного запуску зберігають `cancel-in-progress: false`. -## Live та E2E shards +## Live- та E2E-шарди -Дочірній release live/E2E зберігає широке native покриття `pnpm test:live`, але запускає його як іменовані shards через `scripts/test-live-shard.mjs` замість одного послідовного job: +Дочірній release live/E2E зберігає широке покриття нативного `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання: - `native-live-src-agents` - `native-live-src-gateway-core` -- provider-filtered jobs `native-live-src-gateway-profiles` +- завдання `native-live-src-gateway-profiles`, відфільтровані за провайдером - `native-live-src-gateway-backends` - `native-live-test` - `native-live-extensions-a-k` @@ -225,61 +225,61 @@ run завершується. Парасольковий verifier також з - `native-live-extensions-openai` - `native-live-extensions-o-z-other` - `native-live-extensions-xai` -- розділені media audio/video shards і provider-filtered music shards +- розділені шарди медіа audio/video та музичні шарди, відфільтровані за провайдером -Це зберігає те саме файлове покриття, водночас спрощуючи повторний запуск і діагностику повільних збоїв live provider. Агреговані назви shards `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків. +Це зберігає те саме покриття файлів, водночас спрощуючи повторний запуск і діагностику повільних збоїв live-провайдерів. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` лишаються дійсними для ручних одноразових повторних запусків. -Native live media shards запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media jobs лише перевіряють binaries перед setup. Тримайте Docker-backed live suites на звичайних Blacksmith runners — container jobs є неправильним місцем для запуску вкладених Docker tests. +Нативні live-медіашарди запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. У цьому образі попередньо встановлено `ffmpeg` і `ffprobe`; медіазавдання лише перевіряють бінарні файли перед налаштуванням. Тримайте live-набори з Docker-підтримкою на звичайних раннерах Blacksmith — контейнерні завдання є неправильним місцем для запуску вкладених Docker-тестів. -Docker-backed live model/backend shards використовують окремий shared image `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного commit. Live release workflow один раз збирає й публікує цей image, а потім Docker live model, provider-sharded gateway, CLI backend, ACP bind і Codex harness shards запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker shards мають явні script-level обмеження `timeout` нижче за timeout workflow job, щоб завислий container або cleanup path швидко падав, а не споживав увесь бюджет release-check. Якщо ці shards незалежно перебудовують повний source Docker target, release run налаштовано неправильно, і він марнуватиме wall clock на дубльовані image builds. +Live-шарди моделей/backend із Docker-підтримкою використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Release live workflow збирає й публікує цей образ один раз, після чого Docker live model, gateway із шардингом за провайдерами, CLI backend, ACP bind і шарди Codex harness запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker-шарди мають явні обмеження `timeout` на рівні скриптів нижче за timeout завдання workflow, щоб завислий контейнер або шлях очищення швидко падав замість того, щоб споживати весь бюджет release-check. Якщо ці шарди незалежно перебудовують повну Docker-ціль із вихідного коду, релізний запуск налаштовано неправильно, і він марнуватиме час на дубльовані збірки образів. -## Package Acceptance +## Приймання пакета -Використовуйте `Package Acceptance`, коли питання таке: «чи працює цей installable package OpenClaw як продукт?» Він відрізняється від звичайного CI: звичайний CI перевіряє source tree, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі виконують після install або update. +Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей встановлюваний пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як приймання пакета перевіряє один tarball через той самий Docker E2E harness, який користувачі застосовують після встановлення або оновлення. -### Jobs +### Завдання -1. `resolve_package` виконує checkout `workflow_ref`, розв’язує одного package candidate, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.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`. Reusable workflow завантажує цей artifact, перевіряє tarball inventory, готує package-digest Docker images за потреби та запускає вибрані Docker lanes проти цього package замість пакування workflow checkout. Коли profile вибирає кілька цільових `docker_lanes`, reusable workflow один раз готує package і shared images, а потім розгортає ці lanes як паралельні цільові Docker jobs з унікальними artifacts. -3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий artifact `package-under-test`, коли Package Acceptance розв’язав package; окремий Telegram dispatch усе ще може встановити опублікований npm spec. -4. `summary` завершує workflow з помилкою, якщо package resolution, Docker acceptance або опційний Telegram lane завершився невдало. +1. `resolve_package` отримує `workflow_ref`, розв’язує один кандидат пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і друкує джерело, workflow ref, package ref, версію, SHA-256 і профіль у підсумку кроку GitHub. +2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker-доріжки проти цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow готує пакет і спільні образи один раз, а потім розгортає ці доріжки як паралельні цільові Docker-завдання з унікальними артефактами. +3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance розв’язав його; автономний dispatch Telegram усе ще може встановити опубліковану npm-специфікацію. +4. `summary` завершує workflow з помилкою, якщо розв’язання пакета, Docker acceptance або необов’язкова доріжка Telegram зазнали збою. -### Candidate sources +### Джерела кандидатів -- `source=npm` приймає лише `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для acceptance опублікованого prerelease/stable. -- `source=ref` пакує trusted branch, tag або повний commit SHA з `package_ref`. Resolver fetch OpenClaw branches/tags, перевіряє, що вибраний commit reachable з 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` опційний, але його слід надати для externally shared artifacts. +- `source=npm` приймає лише `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованого попереднього/стабільного релізу. +- `source=ref` пакує довірену гілку, тег або повний SHA коміту `package_ref`. Резолвер отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілки репозиторію або релізного тега, встановлює залежності у від’єднаному worktree і пакує його через `scripts/package-openclaw-for-docker.mjs`. +- `source=url` завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим. +- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його варто вказувати для зовнішньо поширених артефактів. -Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це trusted workflow/harness code, який запускає test. `package_ref` — це source commit, який пакується, коли `source=ref`. Це дає змогу поточному test harness перевіряти старіші trusted source commits без запуску старої workflow logic. +Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає поточному тестовому harness змогу перевіряти старіші довірені коміти вихідного коду без запуску старої логіки workflow. -### Suite profiles +### Профілі наборів - `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload` - `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `published-upgrade-survivor`, `plugins-offline`, `plugin-update` - `product` — `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` -- `full` — повні Docker release-path chunks з OpenWebUI +- `full` — повні Docker-фрагменти релізного шляху з OpenWebUI - `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom` -Profile `package` використовує offline plugin coverage, щоб валідація published-package не залежала від live доступності ClawHub. Опційний Telegram lane повторно використовує artifact `package-under-test` у `NPM Telegram Beta E2E`, а шлях published npm spec збережено для окремих dispatches. +Профіль `package` використовує офлайн-покриття Plugin, щоб валідація опублікованого пакета не залежала від доступності live ClawHub. Необов’язкова доріжка Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації зберігається для автономних dispatch. -Щодо спеціальної політики update і plugin testing, включно з локальними commands, -Docker lanes, inputs Package Acceptance, release defaults і failure triage, -див. [Тестування оновлень і plugins](/uk/help/testing-updates-plugins). +Спеціальну політику тестування оновлень і Plugin, зокрема локальні команди, +Docker-доріжки, вхідні дані Package Acceptance, релізні значення за замовчуванням і тріаж збоїв, +див. у [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins). -Release checks викликають Package Acceptance з `source=artifact`, підготовленим release package artifact, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це тримає package migration, update, stale-plugin-dependency cleanup, configured-plugin install repair, offline plugin, plugin-update і Telegram proof на тому самому розв’язаному package tarball. Cross-OS release checks усе ще покривають OS-specific onboarding, installer і platform behavior; package/update product validation має починатися з Package Acceptance. Docker lane `published-upgrade-survivor` перевіряє один published package baseline за запуск. У Package Acceptance розв’язаний tarball `package-under-test` завжди є candidate, а `published_upgrade_survivor_baseline` вибирає fallback published baseline, типово `openclaw@latest`; команди failed-lane rerun зберігають цей baseline. Встановіть `published_upgrade_survivor_baselines=release-history`, щоб розширити lane на deduped history matrix: останні шість stable releases, `2026.4.23` і останній stable release перед `2026-03-15`. Встановіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для Feishu config, збережених bootstrap/persona files, configured OpenClaw plugin installs, tilde log paths і stale legacy plugin dependency roots. Окремий workflow `Update Migration` використовує Docker lane `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає у вичерпному published update cleanup, а не у звичайній широті Full Release CI. Локальні aggregate runs можуть передавати точні package specs через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, зберігати один lane з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або встановлювати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для scenario matrix. Published lane налаштовує baseline за допомогою вбудованого command recipe `openclaw config set`, записує recipe steps у `summary.json` і перевіряє `/healthz`, `/readyz`, а також RPC status після старту Gateway. Windows packaged і installer fresh lanes також перевіряють, що встановлений package може імпортувати browser-control override з raw absolute Windows path. OpenAI cross-OS agent-turn smoke типово використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли встановлено, інакше `openai/gpt-5.4`, тож install і gateway proof залишаються на test model GPT-5, уникаючи GPT-4.x defaults. +Release checks викликають Package Acceptance із `source=artifact`, підготовленим артефактом релізного пакета, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=all-since-2026.4.23`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це тримає перевірки міграції пакета, оновлення, очищення застарілих залежностей Plugin, repair встановлення налаштованого Plugin, офлайн Plugin, plugin-update і Telegram на одному й тому самому розв’язаному tarball пакета. Задайте `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму матрицю проти відвантаженого npm-пакета замість артефакта, зібраного за SHA. Cross-OS release checks усе ще покривають OS-специфічні onboarding, installer і platform behavior; продуктову валідацію пакета/оновлення слід починати з Package Acceptance. Docker-доріжка `published-upgrade-survivor` перевіряє одну baseline опублікованого пакета за запуск. У Package Acceptance розв’язаний tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback baseline опублікованого пакета, за замовчуванням `openclaw@latest`; команди повторного запуску невдалої доріжки зберігають цю baseline. Задайте `published_upgrade_survivor_baselines=all-since-2026.4.23`, щоб розширити Full Release CI на кожен стабільний npm-реліз від `2026.4.23` до `latest`; `release-history` лишається доступним для ручної ширшої вибірки зі старішим pre-date anchor. Задайте `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для конфігурації Feishu, збережених файлів bootstrap/persona, встановлень налаштованих OpenClaw Plugin, шляхів логів із тильдою та застарілих коренів залежностей legacy Plugin. Окремий workflow `Update Migration` використовує Docker-доріжку `update-migration` з `all-since-2026.4.23` і `plugin-deps-cleanup`, коли питання полягає у вичерпному очищенні опублікованих оновлень, а не у звичайній ширині Full Release CI. Локальні агреговані запуски можуть передавати точні специфікації пакетів через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, зберігати одну доріжку з `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, наприклад `openclaw@2026.4.15`, або задавати `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS` для матриці сценаріїв. Опублікована доріжка налаштовує baseline за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також статус RPC після запуску Gateway. Свіжі доріжки Windows packaged та installer також перевіряють, що встановлений пакет може імпортувати перевизначення browser-control із необробленого абсолютного шляху Windows. Cross-OS smoke OpenAI agent-turn за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, якщо його задано, інакше `openai/gpt-5.4`, тож перевірка встановлення й Gateway лишається на тестовій моделі GPT-5, уникаючи значень за замовчуванням GPT-4.x. -### Legacy compatibility windows +### Вікна сумісності з legacy -Package Acceptance має обмежені legacy-compatibility windows для вже опублікованих packages. Packages до `2026.4.25` включно, включно з `2026.4.25-beta.*`, можуть використовувати compatibility path: +Package Acceptance має обмежені вікна legacy-сумісності для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності: -- відомі private QA entries у `dist/postinstall-inventory.json` можуть вказувати на файли, omit у tarball; -- `doctor-switch` може пропустити subcase persistence `gateway install --wrapper`, коли package не expose цей flag; -- `update-channel-switch` може prune відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і може log відсутній persisted `update.channel`; -- plugin smokes можуть читати legacy install-record locations або приймати відсутній marketplace install-record persistence; -- `plugin-update` може дозволяти config metadata migration, водночас усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними. +- відомі приватні QA-записи в `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball; +- `doctor-switch` може пропускати підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець; +- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` із fake git fixture, похідної від tarball, і може логувати відсутній збережений `update.channel`; +- plugin smokes можуть читати legacy-розташування install-record або приймати відсутню persistence marketplace install-record; +- `plugin-update` може дозволяти міграцію metadata конфігурації, водночас усе ще вимагаючи, щоб install record і поведінка no-reinstall лишалися незмінними. -Опублікований package `2026.4.26` також може попереджати про local build metadata stamp files, які вже були shipped. Пізніші packages мають відповідати сучасним contracts; ті самі умови fail замість warn або skip. +Опублікований пакет `2026.4.26` також може попереджати про локальні файли штампів build metadata, які вже були відвантажені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови призводять до помилки, а не до попередження чи пропуску. ### Приклади @@ -322,152 +322,152 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Під час налагодження невдалого запуску package acceptance починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lane, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes замість повторного запуску повної release validation. +Під час налагодження невдалого запуску приймання пакета починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker-ліній замість повторного запуску повної валідації релізу. ## Інсталяційний smoke-тест -Окремий workflow `Install Smoke` повторно використовує той самий scope-скрипт через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. +Окремий workflow `Install Smoke` повторно використовує той самий скрипт області через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. -- **Швидкий шлях** запускається для pull request, які зачіпають Docker/package surfaces, зміни пакета/маніфесту вбудованого Plugin або surfaces ядра plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише у вихідному коді вбудованого Plugin, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ root Dockerfile, перевіряє CLI, запускає CLI smoke для `agents delete shared-workspace`, запускає container gateway-network e2e, перевіряє build arg вбудованого розширення та запускає обмежений Docker-профіль вбудованого Plugin із сукупним timeout команди 240 секунд (Docker-запуск кожного сценарію обмежено окремо). -- **Повний шлях** зберігає QR package install і installer Docker/update coverage для нічних запланованих запусків, ручних dispatch, workflow-call release checks і pull request, які справді зачіпають installer/package/Docker surfaces. У повному режимі install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий Docker E2E для вбудованого Plugin як окремі завдання, щоб installer-робота не чекала за root image smokes. +- **Швидкий шлях** запускається для pull request, які зачіпають поверхні Docker/пакета, зміни пакета/маніфесту вбудованого Plugin або поверхні ядра Plugin/каналу/Gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише у вихідному коді вбудованого Plugin, зміни лише в тестах і зміни лише в документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє аргумент збірки вбудованого розширення та виконує обмежений Docker-профіль вбудованого Plugin з агрегованим тайм-аутом команди 240 секунд (Docker-запуск кожного сценарію обмежено окремо). +- **Повний шлях** зберігає покриття встановлення QR-пакета та Docker/update інсталятора для нічних запланованих запусків, ручних dispatch, workflow-call перевірок релізу та pull request, які справді зачіпають поверхні інсталятора/пакета/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR smoke-образ кореневого Dockerfile для цільового SHA, а потім запускає встановлення QR-пакета, smoke-перевірки кореневого Dockerfile/Gateway, smoke-перевірки інсталятора/update і швидкий Docker E2E для вбудованого Plugin як окремі завдання, щоб робота інсталятора не чекала за smoke-перевірками кореневого образу. -Пуші в `main` (включно з merge commits) не примушують повний шлях; коли changed-scope logic запитала б повне покриття під час push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічного запуску або release validation. +Push до `main` (включно з merge commits) не примушує повний шлях; коли логіка changed-scope запитала б повне покриття під час push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або релізної валідації. -Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow release checks, а ручні dispatch для `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` цього не роблять. QR і installer Docker tests зберігають власні Dockerfiles, сфокусовані на інсталяції. +Повільний Bun global install image-provider smoke окремо контролюється через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow перевірок релізу, а ручні dispatch `Install Smoke` можуть увімкнути його, але pull request і push до `main` не запускають його. QR і Docker-тести інсталятора зберігають власні Dockerfile, зосереджені на інсталяції. ## Локальний Docker E2E -`pnpm test:docker:all` попередньо збирає один спільний образ live-test, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: +`pnpm test:docker:all` попередньо збирає один спільний live-test образ, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: -- базовий Node/Git runner для installer/update/plugin-dependency lanes; -- функціональний образ, який встановлює той самий tarball у `/app` для звичайних functionality lanes. +- базовий Node/Git runner для ліній installer/update/plugin-dependency; +- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній. -Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Scheduler вибирає образ для кожної lane за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`. +Визначення Docker-ліній містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для кожної лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`. ### Налаштування -| Змінна | Типове значення | Призначення | -| ------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------- | -| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних lanes. | -| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів tail-пулу, чутливого до провайдерів. | -| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Ліміт одночасних live lanes, щоб провайдери не застосовували throttling. | -| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Ліміт одночасних npm install lanes. | -| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Ліміт одночасних multi-service lanes. | -| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами lanes, щоб уникати сплесків створення в Docker daemon; установіть `0`, щоб вимкнути затримку. | -| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний timeout для кожної lane (120 хвилин); вибрані live/tail lanes використовують жорсткіші ліміти. | -| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` друкує план scheduler без запуску lanes. | -| `OPENCLAW_DOCKER_ALL_LANES` | unset | Точний список lanes, розділений комами; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу lane. | +| Змінна | За замовчуванням | Призначення | +| ------------------------------------- | ---------------- | -------------------------------------------------------------------------------------------- | +| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних ліній. | +| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів tail-пулу, чутливого до провайдерів. | +| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Обмеження одночасних live-ліній, щоб провайдери не throttling. | +| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Обмеження одночасних ліній npm install. | +| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Обмеження одночасних multi-service ліній. | +| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами ліній, щоб уникнути create storm у Docker daemon; встановіть `0`, щоб вимкнути затримку. | +| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний тайм-аут на лінію (120 хвилин); вибрані live/tail лінії використовують жорсткіші обмеження. | +| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` друкує план планувальника без запуску ліній. | +| `OPENCLAW_DOCKER_ALL_LANES` | unset | Розділений комами точний список ліній; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу лінію. | -Lane, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім виконується самостійно, доки не звільнить capacity. Локальні сукупні preflights перевіряють Docker, видаляють застарілі OpenClaw E2E containers, виводять статус активних lanes, зберігають таймінги lanes для впорядкування longest-first і за замовчуванням припиняють планування нових pooled lanes після першої помилки. +Лінія, важча за свій ефективний ліміт, все одно може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальні агреговані preflight перевіряють Docker, видаляють застарілі OpenClaw E2E контейнери, виводять статус активних ліній, зберігають таймінги ліній для впорядкування від найдовших і за замовчуванням припиняють планувати нові pooled-лінії після першої помилки. ### Повторно використовуваний live/E2E workflow -Повторно використовуваний live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття package, image kind, live image, lane і credentials потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного запуску, або завантажує package artifact із `package_artifact_run_id`; перевіряє tarball inventory; збирає й пушить package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли план потребує package-installed lanes; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість повторної збірки. Pull Docker images повторюється з обмеженим 180-секундним timeout на спробу, щоб завислий registry/cache stream швидко повторювався замість споживання більшої частини критичного шляху CI. +Повторно використовуваний live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, лінії та облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і зведення. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета з поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає та публікує bare/functional GHCR Docker E2E образи, позначені digest пакета, через кеш Docker-шарів Blacksmith, коли план потребує ліній із встановленим пакетом; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest образи замість повторної збірки. Docker image pulls повторюються з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий потік registry/cache швидко повторювався замість споживання більшої частини критичного шляху CI. -### Chunks release path +### Фрагменти release-path -Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk підтягував лише потрібний image kind і виконував кілька lanes через той самий weighted scheduler: +Релізне Docker-покриття запускає менші chunked-завдання з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний тип образу та виконував кілька ліній через той самий зважений планувальник: - `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..h` -Поточні release Docker chunks: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` і `plugins-runtime-install-a` до `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються сукупними псевдонімами plugin/runtime. Псевдонім lane `install-e2e` залишається сукупним ручним rerun alias для обох provider installer lanes. +Поточні Docker chunks для релізу: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-plugins`, `plugins-runtime-services` і від `plugins-runtime-install-a` до `plugins-runtime-install-h`. `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими псевдонімами plugin/runtime. Псевдонім лінії `install-e2e` залишається агрегованим ручним псевдонімом повторного запуску для обох provider installer ліній. -OpenWebUI включається в `plugins-runtime-services`, коли повне покриття release-path цього вимагає, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Bundled-channel update lanes повторюються один раз у разі тимчасових npm network failures. +OpenWebUI згортається в `plugins-runtime-services`, коли це запитує повне release-path покриття, і зберігає окремий chunk `openwebui` лише для dispatch, призначених тільки для OpenWebUI. Bundled-channel update лінії повторюються один раз у разі тимчасових npm network failures. -Кожен chunk завантажує `.artifacts/docker-tests/` із журналами lanes, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану scheduler, таблицями slow-lane і командами rerun для кожної lane. Input workflow `docker_lanes` запускає вибрані lanes проти підготовлених образів замість chunk jobs, що обмежує налагодження failed-lane одним targeted Docker job і готує, завантажує або повторно використовує package artifact для цього запуску; якщо вибрана lane є live Docker lane, targeted job локально збирає live-test image для цього rerun. Згенеровані GitHub rerun commands для кожної lane включають `package_artifact_run_id`, `package_artifact_name` і prepared image inputs, коли ці значення існують, щоб failed lane могла повторно використати точний package і images з failed run. +Кожен chunk завантажує `.artifacts/docker-tests/` із журналами ліній, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість chunk-завдань, що обмежує налагодження невдалої лінії одним цільовим Docker-завданням і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана лінія є live Docker lane, цільове завдання локально збирає live-test образ для цього повторного запуску. Згенеровані GitHub-команди повторного запуску для кожної лінії містять `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, тому невдала лінія може повторно використати точний пакет і образи з невдалого запуску. ```bash -pnpm test:docker:rerun # завантажити Docker-артефакти та надрукувати combined/per-lane targeted rerun commands -pnpm test:docker:timings # summaries slow-lane і phase critical-path +pnpm test:docker:rerun # download Docker artifacts and print combined/per-lane targeted rerun commands +pnpm test:docker:timings # slow-lane and phase critical-path summaries ``` Запланований live/E2E workflow щодня запускає повний release-path Docker suite. -## Plugin Prerelease +## Передреліз Plugin -`Plugin Prerelease` є дорожчим product/package coverage, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, пуші в `main` і окремі ручні CI dispatch не вмикають цей suite. Він балансує тести вбудованого Plugin між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy plugin batches не створювали додаткові CI jobs. Release-only Docker prerelease path групує targeted Docker lanes у невеликі групи, щоб не резервувати десятки runners для одно-трихвилинних завдань. +`Plugin Prerelease` є дорожчим покриттям product/package, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push до `main` і standalone manual CI dispatch не запускають цей suite. Він балансує тести вбудованих Plugin між вісьмома workers розширень; ці extension shard jobs запускають до двох груп конфігурації Plugin одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy пакети Plugin не створювали додаткових CI jobs. Release-only Docker prerelease path пакетно запускає цільові Docker-лінії малими групами, щоб не резервувати десятки runners для завдань на одну-три хвилини. ## QA Lab -QA Lab має виділені CI lanes поза основним smart-scoped workflow. +QA Lab має окремі CI-лінії поза основним smart-scoped workflow. -- Workflow `Parity gate` запускається на відповідних змінах PR і ручному dispatch; він збирає private QA runtime і порівнює agentic packs mock GPT-5.5 та Opus 4.6. -- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і за ручним dispatch; він розгалужує mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують environment `qa-live-shared`, а Telegram/Discord використовують Convex leases. +- Workflow `Parity gate` запускається на відповідних змінах PR і manual dispatch; він збирає приватний QA runtime і порівнює mock GPT-5.5 та Opus 4.6 agentic packs. +- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і manual dispatch; він розгортає mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `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`), щоб channel contract був ізольований від live model latency і звичайного provider-plugin startup. Live transport gateway вимикає memory search, тому що QA parity окремо покриває memory behavior; provider connectivity покривається окремими live model, native provider і Docker provider suites. +Перевірки релізу запускають Matrix і Telegram live transport lanes із детермінованим mock provider і mock-qualified models (`mock-openai/gpt-5.5` та `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live model і звичайного запуску provider-plugin. Live transport Gateway вимикає memory search, тому що QA parity окремо покриває поведінку пам'яті; provider connectivity покривається окремими наборами live model, native provider і Docker provider. -Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише тоді, коли checked-out CLI це підтримує. CLI default і manual workflow input залишаються `all`; ручний dispatch `matrix_profile=all` завжди шардить повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. +Matrix використовує `--profile fast` для запланованих і release gates, додаючи `--fail-fast` лише коли checked-out CLI підтримує це. CLI default і manual workflow input залишаються `all`; manual dispatch `matrix_profile=all` завжди розбиває повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. -`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у невеликий report job для фінального parity comparison. +`OpenClaw Release Checks` також запускає критичні для релізу QA Lab lanes перед схваленням релізу; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва артефакти в невелике report job для фінального parity comparison. -Не ставте PR landing path за `Parity gate`, якщо зміна насправді не зачіпає QA runtime, model-pack parity або surface, яким володіє parity workflow. Для звичайних виправлень channel, config, docs або unit-test вважайте це додатковим сигналом і покладайтеся на scoped CI/check evidence. +Не ставте шлях приземлення PR за `Parity gate`, якщо зміна фактично не торкається QA runtime, parity набору моделей або поверхні, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-тестів розглядайте його як необов’язковий сигнал і натомість спирайтеся на scoped CI/check evidence. ## CodeQL -Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним sweep усього repository. Щоденні, ручні та non-draft pull request guard runs сканують Actions workflow code плюс найризикованіші JavaScript/TypeScript surfaces з high-confidence security queries, відфільтрованими до high/critical `security-severity`. +Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним sweep репозиторію. Щоденні, ручні та guard-запуски pull request не в draft-стані сканують код Actions workflow і найризикованіші JavaScript/TypeScript surfaces із security queries високої впевненості, відфільтрованими до високої/критичної `security-severity`. -Pull request guard залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security matrix, що й scheduled workflow. Android і macOS CodeQL не входять у PR defaults. +Guard для pull request лишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму security matrix високої впевненості, що й scheduled workflow. Android і macOS CodeQL не входять у стандартні PR-запуски. ### Категорії безпеки -| Категорія | Поверхня | +| Категорія | Поверхня | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-security-high/core-auth-secrets` | Базовий рівень автентифікації, секретів, пісочниці, cron і gateway | -| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації основного каналу плюс середовище виконання канального plugin, gateway, Plugin SDK, секрети, точки аудиту | -| `/codeql-security-high/network-ssrf-boundary` | Поверхні політики SSRF для core SSRF, розбору IP, мережевого захисту, web-fetch і Plugin SDK | -| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, допоміжні засоби виконання процесів, вихідна доставка та шлюзи виконання інструментів агента | -| `/codeql-security-high/plugin-trust-boundary` | Поверхні довіри для встановлення Plugin, завантажувача, маніфесту, реєстру, встановлення менеджером пакетів, завантаження джерел і контракту пакета Plugin SDK | +| `/codeql-security-high/core-auth-secrets` | Auth, secrets, sandbox, cron і базова лінія gateway | +| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації core channel плюс channel Plugin runtime, gateway, Plugin SDK, secrets, audit touchpoints | +| `/codeql-security-high/network-ssrf-boundary` | Core SSRF, IP parsing, network guard, web-fetch і surfaces політики SSRF у Plugin SDK | +| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, helpers виконання процесів, outbound delivery і gates виконання agent tool | +| `/codeql-security-high/plugin-trust-boundary` | Plugin install, loader, manifest, registry, package-manager install, source-loading і trust surfaces контракту пакета Plugin SDK | -### Специфічні для платформ security shards +### Платформо-специфічні security shards -- `CodeQL Android Critical Security` — запланований Android security shard. Вручну збирає Android-застосунок для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Вивантажує в `/codeql-critical-security/android`. -- `CodeQL macOS Critical Security` — щотижневий/ручний macOS security shard. Вручну збирає macOS-застосунок для CodeQL на Blacksmith macOS, відфільтровує результати збірки залежностей із вивантаженого SARIF і вивантажує в `/codeql-critical-security/macos`. Залишено поза щоденними стандартними запусканнями, бо збірка macOS домінує за часом виконання навіть коли все чисто. +- `CodeQL Android Critical Security` — scheduled Android security shard. Будує Android app вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує під `/codeql-critical-security/android`. +- `CodeQL macOS Critical Security` — щотижневий/ручний macOS security shard. Будує macOS app вручну для CodeQL на Blacksmith macOS, відфільтровує результати dependency build із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Тримається поза щоденними defaults, бо macOS build домінує runtime навіть коли чистий. ### Категорії Critical Quality -`CodeQL Critical Quality` — відповідний несек'юріті shard. Він запускає лише запити якості JavaScript/TypeScript із severity error і без security над вузькими високовартісними поверхнями на меншому Blacksmith Linux runner. Його запобіжник для pull request навмисно менший за запланований профіль: не-draft PR запускають лише відповідні shards `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін у коді виконання команд/моделей/інструментів агента та диспетчеризації відповідей, коді схем/міграцій/IO конфігурації, коді auth/secrets/sandbox/security, основному каналі та середовищі виконання вбудованого канального plugin, протоколі Gateway/методі сервера, склейці memory runtime/SDK, MCP/process/outbound delivery, середовищі виконання провайдера/каталозі моделей, діагностиці сесій/чергах доставки, завантажувачі plugin, Plugin SDK/контракті пакета або середовищі виконання відповідей Plugin SDK. Зміни конфігурації CodeQL і quality workflow запускають усі дванадцять PR quality shards. +`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries на вузьких високовартісних surfaces на меншому Blacksmith Linux runner. Його pull request guard навмисно менший за scheduled profile: non-draft PRs запускають лише відповідні shards `agent-runtime-boundary`, `config-boundary`, `core-auth-secrets`, `channel-runtime-boundary`, `gateway-runtime-boundary`, `memory-runtime-boundary`, `mcp-process-runtime-boundary`, `provider-runtime-boundary`, `session-diagnostics-boundary`, `plugin-boundary`, `plugin-sdk-package-contract` і `plugin-sdk-reply-runtime` для змін у agent command/model/tool execution і reply dispatch code, config schema/migration/IO code, auth/secrets/sandbox/security code, core channel і bundled channel Plugin runtime, gateway protocol/server-method, memory runtime/SDK glue, MCP/process/outbound delivery, provider runtime/model catalog, session diagnostics/delivery queues, plugin loader, Plugin SDK/package-contract або Plugin SDK reply runtime. Зміни CodeQL config і quality workflow запускають усі дванадцять PR quality shards. -Ручний запуск приймає: +Manual dispatch приймає: ``` profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary ``` -Вузькі профілі — це хуки для навчання/ітерацій, щоб запускати один quality shard ізольовано. +Вузькі profiles — це hooks для навчання/ітерації, щоб запускати один quality shard ізольовано. -| Категорія | Поверхня | +| Категорія | Поверхня | | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-critical-quality/core-auth-secrets` | Код security boundary для автентифікації, секретів, пісочниці, cron і gateway | -| `/codeql-critical-quality/config-boundary` | Схема конфігурації, міграція, нормалізація та IO-контракти | -| `/codeql-critical-quality/gateway-runtime-boundary` | Схеми протоколу Gateway і контракти методів сервера | -| `/codeql-critical-quality/channel-runtime-boundary` | Контракти основного каналу та реалізації вбудованого канального plugin | -| `/codeql-critical-quality/agent-runtime-boundary` | Контракти виконання команд, диспетчеризації model/provider, диспетчеризації й черг auto-reply та середовища виконання ACP control-plane | -| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-сервери та мости інструментів, допоміжні засоби нагляду за процесами й контракти вихідної доставки | -| `/codeql-critical-quality/memory-runtime-boundary` | Memory host SDK, фасади memory runtime, псевдоніми memory Plugin SDK, склейка активації memory runtime і команди memory doctor | -| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішні частини черги відповідей, черги доставки сесій, допоміжні засоби прив'язування/доставки вихідних сесій, поверхні діагностичних подій/пакетів журналів і контракти CLI session doctor | -| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Диспетчеризація вхідних відповідей Plugin SDK, допоміжні засоби payload/chunking/runtime для відповідей, параметри відповіді каналу, черги доставки та допоміжні засоби прив'язування session/thread | -| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, автентифікація й виявлення провайдера, реєстрація середовища виконання провайдера, defaults/catalogs провайдера та реєстри web/search/fetch/embedding | -| `/codeql-critical-quality/ui-control-plane` | Завантаження Control UI, локальна персистентність, потоки керування gateway і runtime-контракти task control-plane | -| `/codeql-critical-quality/web-media-runtime-boundary` | Контракти core web fetch/search, media IO, media understanding, image-generation і media-generation runtime | -| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, публічної поверхні та точки входу Plugin SDK | -| `/codeql-critical-quality/plugin-sdk-package-contract` | Опублікований package-side вихідний код Plugin SDK і допоміжні засоби контракту пакета plugin | +| `/codeql-critical-quality/core-auth-secrets` | Auth, secrets, sandbox, cron і code межі безпеки gateway | +| `/codeql-critical-quality/config-boundary` | Config schema, migration, normalization і IO contracts | +| `/codeql-critical-quality/gateway-runtime-boundary` | Gateway protocol schemas і server method contracts | +| `/codeql-critical-quality/channel-runtime-boundary` | Core channel і bundled channel Plugin implementation contracts | +| `/codeql-critical-quality/agent-runtime-boundary` | Command execution, model/provider dispatch, auto-reply dispatch і queues, а також ACP control-plane runtime contracts | +| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP servers і tool bridges, process supervision helpers і outbound delivery contracts | +| `/codeql-critical-quality/memory-runtime-boundary` | Memory host SDK, memory runtime facades, memory Plugin SDK aliases, memory runtime activation glue і memory doctor commands | +| `/codeql-critical-quality/session-diagnostics-boundary` | Reply queue internals, session delivery queues, outbound session binding/delivery helpers, diagnostic event/log bundle surfaces і session doctor CLI contracts | +| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Plugin SDK inbound reply dispatch, reply payload/chunking/runtime helpers, channel reply options, delivery queues і session/thread binding helpers | +| `/codeql-critical-quality/provider-runtime-boundary` | Model catalog normalization, provider auth і discovery, provider runtime registration, provider defaults/catalogs і web/search/fetch/embedding registries | +| `/codeql-critical-quality/ui-control-plane` | Control UI bootstrap, local persistence, gateway control flows і task control-plane runtime contracts | +| `/codeql-critical-quality/web-media-runtime-boundary` | Core web fetch/search, media IO, media understanding, image-generation і media-generation runtime contracts | +| `/codeql-critical-quality/plugin-boundary` | Loader, registry, public-surface і Plugin SDK entrypoint contracts | +| `/codeql-critical-quality/plugin-sdk-package-contract` | Published package-side Plugin SDK source і helpers контракту plugin package | -Quality залишається окремо від security, щоб quality findings можна було планувати, вимірювати, вимикати або розширювати без затінення security signal. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільні runtime і signal. +Quality тримається окремо від security, щоб quality findings можна було планувати, вимірювати, вимикати або розширювати, не затіняючи security signal. Swift, Python і bundled-plugin CodeQL expansion слід додавати назад як scoped або sharded follow-up work лише після того, як вузькі profiles матимуть стабільні runtime і signal. -## Робочі процеси обслуговування +## Maintenance workflows ### Docs Agent -Workflow `Docs Agent` — це подієво-керована maintenance lane Codex для підтримання наявної документації узгодженою з нещодавно злитими змінами. Вона не має чистого розкладу: успішний 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. +Workflow `Docs Agent` — це event-driven Codex maintenance lane для підтримання наявної документації узгодженою з нещодавно landed changes. Він не має pure schedule: успішний non-bot push CI run на `main` може його запустити, а manual dispatch може запускати його напряму. Workflow-run invocations пропускаються, коли `main` уже просунувся вперед або коли інший non-skipped Docs Agent run було створено за останню годину. Коли він запускається, він переглядає commit range від попереднього non-skipped Docs Agent source SHA до поточного `main`, тож один hourly run може покрити всі main changes, накопичені з останнього docs pass. ### Test Performance Agent -Workflow `Test Performance Agent` — це подієво-керована maintenance lane Codex для повільних тестів. Вона не має чистого розкладу: успішний 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 і відхиляє зміни, що зменшують baseline test count, який проходить. Якщо baseline має failing tests, Codex може виправляти лише очевидні failures, а after-agent full-suite report має пройти перед будь-яким комітом. Коли `main` просувається вперед до того, як bot push потрапить у репозиторій, lane робить rebase перевіреного patch, повторно запускає `pnpm check:changed` і повторює push; stale patches із конфліктами пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб Codex action могла зберігати ту саму drop-sudo safety posture, що й docs agent. +Workflow `Test Performance Agent` — це event-driven Codex maintenance lane для повільних tests. Він не має pure schedule: успішний non-bot push CI run на `main` може його запустити, але він пропускається, якщо інша workflow-run invocation уже запускалася або виконується цього UTC day. Manual dispatch обходить цей daily activity gate. Lane будує full-suite grouped Vitest performance report, дозволяє Codex робити лише невеликі coverage-preserving test performance fixes замість широких refactors, потім повторно запускає full-suite report і відхиляє зміни, що зменшують passing baseline test count. Якщо baseline має failing tests, Codex може виправляти лише очевидні failures, а after-agent full-suite report має пройти перед будь-яким commit. Коли `main` просувається вперед до того, як bot push landed, lane rebase’ить validated patch, повторно запускає `pnpm check:changed` і повторює push; conflicting stale patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб Codex action міг зберегти ту саму drop-sudo safety posture, що й docs agent. -### Дублікати PR після злиття +### Duplicate PRs After Merge -Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для post-land очищення дублікатів. За замовчуванням він працює як dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR злитий і що кожен duplicate має або спільну referenced issue, або перекривні changed hunks. +Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для post-land duplicate cleanup. За замовчуванням він dry-run і закриває лише явно перелічені PRs, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR merged і що кожен duplicate має або shared referenced issue, або overlapping changed hunks. ```bash gh workflow run duplicate-after-merge.yml \ @@ -476,29 +476,29 @@ gh workflow run duplicate-after-merge.yml \ -f apply=true ``` -## Локальні check gates і маршрутизація змін +## Local check gates і changed routing -Local changed-lane logic живе в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж широкий CI platform scope: +Local changed-lane logic живе в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж широкий scope CI platform: -- зміни core production запускають core prod і core test typecheck плюс core lint/guards; -- зміни лише core test запускають лише core test typecheck плюс core lint; -- зміни extension production запускають extension prod і extension test typecheck плюс extension lint; -- зміни лише extension test запускають extension test typecheck плюс extension lint; -- зміни public Plugin SDK або plugin-contract розширюються до extension typecheck, бо extensions залежать від цих core contracts (Vitest extension sweeps залишаються явною test work); -- release metadata-only version bumps запускають цільові version/config/root-dependency checks; -- невідомі root/config changes fail safe до всіх check lanes. +- core production changes запускають core prod і core test typecheck плюс core lint/guards; +- core test-only changes запускають лише core test typecheck плюс core lint; +- extension production changes запускають extension prod і extension test typecheck плюс extension lint; +- extension test-only changes запускають extension test typecheck плюс extension lint; +- public Plugin SDK або plugin-contract changes розширюються до extension typecheck, бо extensions залежать від цих core contracts (Vitest extension sweeps лишаються явною test work); +- release metadata-only version bumps запускають targeted version/config/root-dependency checks; +- unknown root/config changes fail safe до всіх check lanes. -Local changed-test routing живе в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі test edits запускають самі себе, source edits надають перевагу явним mappings, потім sibling tests і import-graph dependents. Shared group-room delivery config є одним із explicit mappings: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс Discord і Slack delivery regressions, щоб shared default change зазнала failure до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна настільки harness-wide, що дешевий mapped set не є надійним proxy. +Маршрутизація локальних тестів за змінами міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі зміни тестів запускають самі себе, зміни джерел віддають перевагу явним зіставленням, потім суміжним тестам і залежним елементам графа імпортів. Спільна конфігурація доставки для групових кімнат є одним із явних зіставлень: зміни конфігурації видимих відповідей у групі, режиму доставки відповідей із джерела або системного промпта інструмента повідомлень проходять через основні тести відповідей, а також регресії доставки Discord і Slack, щоб зміна спільного стандартного значення падала ще до першого push у PR. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна достатньо широка для всього harness, що дешевий зіставлений набір не є надійним proxy. ## Валідація Testbox -Запускайте Testbox із кореня репозиторію та надавайте перевагу свіжому warmed box для broad proof. Перед тим як витрачати повільний gate на box, який reused, expired або щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` усередині box. +Запускайте Testbox з кореня репозиторію й віддавайте перевагу свіжій прогрітій коробці для широкого підтвердження. Перш ніж витрачати повільний gate на коробку, яку було повторно використано, термін дії якої минув або яка щойно повідомила про несподівано велику синхронізацію, спочатку запустіть `pnpm testbox:sanity` всередині коробки. -Sanity check швидко завершується failure, коли required root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що remote sync state не є надійною копією PR; зупиніть цей box і warmed fresh one замість налагодження product test failure. Для intentional large-deletion PR встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run. +Перевірка sanity швидко завершується помилкою, коли зникли потрібні кореневі файли, як-от `pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 відстежуваних видалень. Зазвичай це означає, що стан віддаленої синхронізації не є надійною копією PR; зупиніть цю коробку й прогрійте нову замість налагодження збою тестів продукту. Для PR із навмисними великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього запуску sanity. -`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі синхронізації понад п’ять хвилин без виводу після синхронізації. Установіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей захист, або використайте більше значення в мілісекундах для незвично великих локальних змін. +`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі синхронізації понад п’ять хвилин без виводу після синхронізації. Установіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей запобіжник, або використайте більше значення в мілісекундах для незвично великих локальних diff. -Crabbox — це другий належний репозиторію шлях до віддаленого бокса для перевірки в Linux, коли Blacksmith недоступний або коли бажано використати власну хмарну потужність. Підігрійте бокс, гідратуйте його через workflow проєкту, а потім виконуйте команди через Crabbox CLI: +Crabbox — це другий віддалений шлях коробок, яким володіє репозиторій, для підтвердження в Linux, коли Blacksmith недоступний або коли бажано використовувати власну хмарну місткість. Прогрійте коробку, гідратуйте її через workflow проєкту, а потім запускайте команди через Crabbox CLI: ```bash pnpm crabbox:warmup -- --idle-timeout 90m @@ -507,7 +507,7 @@ pnpm crabbox:run -- --id --shell "OPENCLAW_TESTBOX=1 pnpm check:changed pnpm crabbox:stop -- ``` -`.crabbox.yaml` визначає типові параметри провайдера, синхронізації та гідратації GitHub Actions. Він виключає локальний `.git`, щоб гідратований checkout Actions зберігав власні віддалені метадані Git замість синхронізації локальних для мейнтейнера remotes і сховищ об’єктів, а також виключає локальні runtime/build артефакти, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` визначає checkout, налаштування Node/pnpm, отримання `origin/main` і передавання несекретного середовища, яке згодом використовують команди `crabbox run --id `. +`.crabbox.yaml` керує стандартними значеннями provider, sync і гідратації GitHub Actions. Він виключає локальний `.git`, щоб гідратований checkout Actions зберігав власні віддалені Git-метадані замість синхронізації maintainer-local remotes і object stores, а також виключає локальні runtime/build артефакти, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` керує checkout, налаштуванням Node/pnpm, отриманням `origin/main` і передаванням несекретного середовища, яке пізніші команди `crabbox run --id ` підключають як source. ## Пов’язане diff --git a/docs/uk/cli/doctor.md b/docs/uk/cli/doctor.md index af6a56a31..361ffe3d9 100644 --- a/docs/uk/cli/doctor.md +++ b/docs/uk/cli/doctor.md @@ -5,10 +5,10 @@ read_when: summary: Довідник CLI для `openclaw doctor` (перевірки справності + керовані виправлення) title: Діагностика x-i18n: - generated_at: "2026-05-02T15:57:48Z" + generated_at: "2026-05-02T18:57:43Z" model: gpt-5.5 provider: openai - source_hash: 90da8ffd705cd517fb90367164cc6af3e551befcec15c91746aa1e1e39454f09 + source_hash: c64cefee8f36b38657b72912271e3734411870376d2bd5a374d23a77a080035d source_path: cli/doctor.md workflow: 16 --- @@ -17,7 +17,7 @@ x-i18n: Перевірки справності + швидкі виправлення для Gateway і каналів. -Пов’язано: +Пов’язане: - Усунення несправностей: [Усунення несправностей](/uk/gateway/troubleshooting) - Аудит безпеки: [Безпека](/uk/gateway/security) @@ -34,43 +34,44 @@ openclaw doctor --generate-gateway-token ## Параметри -- `--no-workspace-suggestions`: вимкнути підказки пам’яті/пошуку робочого простору -- `--yes`: приймати значення за замовчуванням без запитів -- `--repair`: застосувати рекомендовані виправлення, не пов’язані із сервісом, без запитів; встановлення й перезапис сервісу Gateway все одно потребують інтерактивного підтвердження або явних команд Gateway +- `--no-workspace-suggestions`: вимкнути пропозиції пам’яті/пошуку робочого простору +- `--yes`: приймати типові значення без запитів +- `--repair`: застосувати рекомендовані виправлення, не пов’язані зі службами, без запитів; встановлення та перезаписи служби Gateway усе ще потребують інтерактивного підтвердження або явних команд Gateway - `--fix`: псевдонім для `--repair` -- `--force`: застосувати агресивні виправлення, зокрема перезапис власної конфігурації сервісу за потреби -- `--non-interactive`: запускати без запитів; лише безпечні міграції та виправлення, не пов’язані із сервісом -- `--generate-gateway-token`: згенерувати й налаштувати токен Gateway -- `--deep`: просканувати системні сервіси на наявність додаткових встановлень Gateway +- `--force`: застосувати агресивні виправлення, зокрема перезапис власної конфігурації служби за потреби +- `--non-interactive`: виконати без запитів; лише безпечні міграції та виправлення, не пов’язані зі службами +- `--generate-gateway-token`: згенерувати та налаштувати токен Gateway +- `--deep`: просканувати системні служби на наявність додаткових встановлень Gateway Примітки: -- Інтерактивні запити (наприклад, виправлення keychain/OAuth) виконуються лише тоді, коли stdin є TTY і `--non-interactive` **не** задано. Запуски без інтерфейсу (cron, Telegram, без термінала) пропускатимуть запити. -- Продуктивність: неінтерактивні запуски `doctor` пропускають завчасне завантаження plugin, щоб перевірки справності без інтерфейсу залишалися швидкими. Інтерактивні сеанси все одно повністю завантажують plugins, коли перевірці потрібен їхній внесок. +- Інтерактивні запити (наприклад, виправлення keychain/OAuth) виконуються лише тоді, коли stdin є TTY і **не** встановлено `--non-interactive`. Безголові запуски (cron, Telegram, без термінала) пропускатимуть запити. +- Продуктивність: неінтерактивні запуски `doctor` пропускають завчасне завантаження Plugin, щоб безголові перевірки справності лишалися швидкими. Інтерактивні сеанси все одно повністю завантажують plugins, коли перевірці потрібен їхній внесок. - `--fix` (псевдонім для `--repair`) записує резервну копію в `~/.openclaw/openclaw.json.bak` і видаляє невідомі ключі конфігурації, перелічуючи кожне видалення. -- `doctor --fix --non-interactive` повідомляє про відсутні або застарілі визначення сервісу Gateway, але не встановлює й не перезаписує їх поза режимом відновлення оновлення. Запустіть `openclaw gateway install` для відсутнього сервісу або `openclaw gateway install --force`, коли ви навмисно хочете замінити засіб запуску. -- Перевірки цілісності стану тепер виявляють осиротілі файли транскриптів у каталозі сеансів. Архівування їх як `.deleted.` потребує інтерактивного підтвердження; `--fix`, `--yes` і запуски без інтерфейсу залишають їх на місці. -- Doctor також сканує `~/.openclaw/cron/jobs.json` (або `cron.store`) на наявність застарілих форм завдань cron і може перезаписати їх на місці до того, як планувальнику доведеться автоматично нормалізувати їх під час виконання. -- У Linux doctor попереджає, коли crontab користувача все ще запускає застарілий `~/.openclaw/bin/ensure-whatsapp.sh`; цей скрипт більше не підтримується й може журналювати хибні збої Gateway WhatsApp, коли cron не має середовища user-bus systemd. -- Doctor очищає застарілий стан підготовки залежностей plugin, створений старішими версіями OpenClaw. Він також відновлює відсутні налаштовані завантажувані plugins, коли реєстр може їх визначити, а прохід doctor 2026.5.2 автоматично встановлює завантажувані plugins, які вже використовує старіша конфігурація, перш ніж позначати конфігурацію зміненою для цього релізу. -- Doctor виправляє застарілу конфігурацію plugin, видаляючи відсутні ідентифікатори plugin з `plugins.allow`/`plugins.entries`, а також відповідну висячу конфігурацію каналу, цілі Heartbeat і перевизначення моделей каналів, коли виявлення plugin справне. -- Doctor ізолює недійсну конфігурацію plugin, вимикаючи відповідний запис `plugins.entries.` і видаляючи його недійсне корисне навантаження `config`. Запуск Gateway уже пропускає лише цей несправний plugin, тож інші plugins і канали можуть продовжувати працювати. -- Установіть `OPENCLAW_SERVICE_REPAIR_POLICY=external`, коли інший супервізор керує життєвим циклом Gateway. Doctor усе одно повідомляє про справність Gateway/сервісу й застосовує виправлення, не пов’язані із сервісом, але пропускає встановлення/запуск/перезапуск/bootstrap сервісу та очищення застарілого сервісу. -- У Linux doctor ігнорує неактивні додаткові systemd units, схожі на Gateway, і не перезаписує метадані команди/точки входу для запущеного сервісу Gateway systemd під час виправлення. Спершу зупиніть сервіс або скористайтеся `openclaw gateway install --force`, коли ви навмисно хочете замінити активний засіб запуску. -- Doctor автоматично мігрує застарілу пласку конфігурацію Talk (`talk.voiceId`, `talk.modelId` тощо) у `talk.provider` + `talk.providers.`. -- Повторні запуски `doctor --fix` більше не повідомляють і не застосовують нормалізацію Talk, коли єдина відмінність — порядок ключів об’єкта. -- Doctor містить перевірку готовності пошуку в пам’яті й може рекомендувати `openclaw configure --section model`, коли облікові дані embedding відсутні. -- Doctor попереджає, коли власника команд не налаштовано. Власник команд — це обліковий запис людини-оператора, якому дозволено запускати команди лише для власника й схвалювати небезпечні дії. Сполучення через DM лише дає комусь змогу спілкуватися з ботом; якщо ви схвалили відправника до появи bootstrap першого власника, явно задайте `commands.ownerAllowFrom`. -- Doctor попереджає, коли налаштовано агентів у режимі Codex і в Codex home оператора існують особисті ресурси Codex CLI. Локальні запуски app-server Codex використовують ізольовані домівки для кожного агента, тож використовуйте `openclaw migrate codex --dry-run`, щоб інвентаризувати ресурси, які слід просувати свідомо. -- Якщо режим sandbox увімкнено, але Docker недоступний, doctor повідомляє високосигнальне попередження з виправленням (`install Docker` або `openclaw config set agents.defaults.sandbox.mode off`). -- Якщо `gateway.auth.token`/`gateway.auth.password` керуються SecretRef і недоступні в поточному шляху команди, doctor повідомляє попередження лише для читання й не записує резервні облікові дані відкритим текстом. -- Якщо перевірка SecretRef каналу не вдається на шляху виправлення, doctor продовжує роботу й повідомляє попередження замість раннього завершення. -- Після міграцій каталогу стану doctor попереджає, коли увімкнені типові облікові записи Telegram або Discord залежать від резервного env, а `TELEGRAM_BOT_TOKEN` або `DISCORD_BOT_TOKEN` недоступні процесу doctor. -- Автоматичне визначення імен користувачів Telegram `allowFrom` (`doctor --fix`) потребує визначуваного токена Telegram у поточному шляху команди. Якщо перевірка токена недоступна, doctor повідомляє попередження й пропускає автоматичне визначення для цього проходу. +- `doctor --fix --non-interactive` повідомляє про відсутні або застарілі визначення служби Gateway, але не встановлює й не перезаписує їх поза режимом виправлення оновлення. Запустіть `openclaw gateway install` для відсутньої служби або `openclaw gateway install --force`, коли ви навмисно хочете замінити launcher. +- Перевірки цілісності стану тепер виявляють осиротілі файли transcript у каталозі sessions. Їх архівування як `.deleted.` потребує інтерактивного підтвердження; `--fix`, `--yes` і безголові запуски залишають їх на місці. +- Doctor також сканує `~/.openclaw/cron/jobs.json` (або `cron.store`) на наявність застарілих форм завдань cron і може переписати їх на місці до того, як scheduler буде змушений автоматично нормалізувати їх під час виконання. +- У Linux doctor попереджає, коли crontab користувача все ще запускає застарілий `~/.openclaw/bin/ensure-whatsapp.sh`; цей скрипт більше не підтримується і може реєструвати хибні збої WhatsApp Gateway, коли cron не має середовища systemd user-bus. +- Doctor очищає застарілий проміжний стан залежностей Plugin, створений старішими версіями OpenClaw. Він також виправляє відсутні налаштовані завантажувані plugins, коли registry може їх розпізнати, а проходження doctor 2026.5.2 автоматично встановлює завантажувані plugins, які вже використовує старіша конфігурація, перед позначенням конфігурації як зміненої для цього випуску. +- Doctor виправляє застарілу конфігурацію Plugin, видаляючи відсутні ідентифікатори Plugin з `plugins.allow`/`plugins.entries`, а також відповідну висячу конфігурацію каналів, цілі Heartbeat і перевизначення моделей каналів, коли виявлення Plugin справне. +- Doctor ізолює недійсну конфігурацію Plugin, вимикаючи відповідний запис `plugins.entries.` і видаляючи його недійсний payload `config`. Запуск Gateway уже пропускає лише цей несправний Plugin, тож інші plugins і канали можуть продовжувати працювати. +- Встановіть `OPENCLAW_SERVICE_REPAIR_POLICY=external`, коли інший supervisor керує життєвим циклом Gateway. Doctor усе ще повідомляє про справність Gateway/служби та застосовує виправлення, не пов’язані зі службами, але пропускає встановлення/запуск/перезапуск/bootstrap служби та очищення застарілих служб. +- У Linux doctor ігнорує неактивні додаткові systemd units, схожі на Gateway, і не переписує метадані команди/entrypoint для запущеної systemd-служби Gateway під час виправлення. Спочатку зупиніть службу або використайте `openclaw gateway install --force`, коли ви навмисно хочете замінити активний launcher. +- Doctor автоматично мігрує застарілу пласку конфігурацію Talk (`talk.voiceId`, `talk.modelId` та пов’язані ключі) у `talk.provider` + `talk.providers.`. +- Повторні запуски `doctor --fix` більше не повідомляють/застосовують нормалізацію Talk, коли єдина різниця полягає в порядку ключів об’єкта. +- Doctor містить перевірку готовності memory-search і може рекомендувати `openclaw configure --section model`, коли облікові дані embedding відсутні. +- Doctor попереджає, коли не налаштовано власника команд. Власник команд — це обліковий запис людини-оператора, якому дозволено виконувати команди лише для власника й схвалювати небезпечні дії. Спарювання через DM лише дає комусь змогу говорити з ботом; якщо ви схвалили відправника до появи bootstrap першого власника, явно встановіть `commands.ownerAllowFrom`. +- Doctor попереджає, коли налаштовані агенти в режимі Codex і в Codex home оператора існують особисті ресурси Codex CLI. Локальні запуски app-server Codex використовують ізольовані home для кожного агента, тому використовуйте `openclaw migrate codex --dry-run`, щоб інвентаризувати ресурси, які слід свідомо просунути. +- Doctor попереджає, коли skills, дозволені для типового агента, недоступні в поточному середовищі виконання, бо відсутні bins, env vars, config або вимоги ОС. `doctor --fix` може вимкнути ці недоступні skills за допомогою `skills.entries..enabled=false`; натомість встановіть/налаштуйте відсутню вимогу, коли хочете зберегти skill активним. +- Якщо sandbox mode увімкнено, але Docker недоступний, doctor повідомляє попередження з високим сигналом і способом виправлення (`install Docker` або `openclaw config set agents.defaults.sandbox.mode off`). +- Якщо `gateway.auth.token`/`gateway.auth.password` керуються SecretRef і недоступні в поточному шляху команди, doctor повідомляє попередження лише для читання й не записує fallback облікові дані у plaintext. +- Якщо перевірка SecretRef каналу завершується невдало в шляху виправлення, doctor продовжує роботу й повідомляє попередження замість раннього завершення. +- Після міграцій каталогу стану doctor попереджає, коли ввімкнені типові облікові записи Telegram або Discord залежать від env fallback, а `TELEGRAM_BOT_TOKEN` або `DISCORD_BOT_TOKEN` недоступні процесу doctor. +- Автоматичне розпізнавання імен користувачів Telegram `allowFrom` (`doctor --fix`) потребує розпізнаваного токена Telegram у поточному шляху команди. Якщо перевірка токена недоступна, doctor повідомляє попередження й пропускає автоматичне розпізнавання для цього проходження. ## macOS: перевизначення env `launchctl` -Якщо ви раніше запускали `launchctl setenv OPENCLAW_GATEWAY_TOKEN ...` (або `...PASSWORD`), це значення перевизначає ваш файл конфігурації й може спричиняти постійні помилки “unauthorized”. +Якщо ви раніше запускали `launchctl setenv OPENCLAW_GATEWAY_TOKEN ...` (або `...PASSWORD`), це значення перевизначає ваш файл конфігурації та може спричиняти постійні помилки “unauthorized”. ```bash launchctl getenv OPENCLAW_GATEWAY_TOKEN @@ -80,7 +81,7 @@ launchctl unsetenv OPENCLAW_GATEWAY_TOKEN launchctl unsetenv OPENCLAW_GATEWAY_PASSWORD ``` -## Пов’язано +## Пов’язане - [Довідник CLI](/uk/cli) - [Gateway doctor](/uk/gateway/doctor) diff --git a/docs/uk/cli/skills.md b/docs/uk/cli/skills.md index f29e3c603..12b8da8bc 100644 --- a/docs/uk/cli/skills.md +++ b/docs/uk/cli/skills.md @@ -1,27 +1,27 @@ --- read_when: - - Ви хочете побачити, які Skills доступні та готові до запуску - - Ви хочете знайти, встановити або оновити Skills з ClawHub - - Ви хочете налагодити відсутні бінарні файли/env/конфігурацію для Skills -summary: Довідка CLI для `openclaw skills` (search/install/update/list/info/check) + - Ви хочете переглянути, які Skills доступні та готові до запуску + - Ви хочете шукати, встановлювати або оновлювати Skills із ClawHub + - Ви хочете налагодити відсутні бінарні файли, змінні середовища або конфігурацію для Skills +summary: Довідник CLI для `openclaw skills` (search/install/update/list/info/check) title: Skills x-i18n: - generated_at: "2026-04-28T00:10:36Z" - model: gpt-5.4 + generated_at: "2026-05-02T18:57:50Z" + model: gpt-5.5 provider: openai - source_hash: 5059bf04c68dabe289d2c376407a52989c970e3d16e7637a2c83f4e24ad6564c + source_hash: d819cdc421151a0093423f57a9e974489e9cc02de644358bd5700ee75181192e source_path: cli/skills.md - workflow: 15 + workflow: 16 --- # `openclaw skills` -Переглядайте локальні Skills та встановлюйте/оновлюйте Skills з ClawHub. +Переглядайте локальні Skills та встановлюйте/оновлюйте Skills із ClawHub. -Пов’язане: +Пов’язано: - Система Skills: [Skills](/uk/tools/skills) -- Конфігурація Skills: [Skills config](/uk/tools/skills-config) +- Конфігурація Skills: [Конфігурація Skills](/uk/tools/skills-config) - Встановлення з ClawHub: [ClawHub](/uk/tools/clawhub) ## Команди @@ -45,37 +45,39 @@ openclaw skills info openclaw skills info --json openclaw skills info --agent openclaw skills check -openclaw skills check --json openclaw skills check --agent +openclaw skills check --json ``` -`search`/`install`/`update` напряму використовують ClawHub і встановлюють у активний -каталог робочого простору `skills/`. `list`/`info`/`check` як і раніше перевіряють локальні -Skills, видимі для поточного робочого простору та конфігурації. Команди, що -працюють з робочим простором, визначають цільовий робочий простір через `--agent `, -потім через поточний робочий каталог, якщо він знаходиться всередині налаштованого -робочого простору агента, а потім через агента за замовчуванням. +`search`/`install`/`update` використовують ClawHub напряму та встановлюють у +каталог `skills/` активного робочого простору. `list`/`info`/`check` і надалі +перевіряють локальні Skills, видимі для поточного робочого простору та конфігурації. +Команди, що спираються на робочий простір, визначають цільовий робочий простір +із `--agent `, потім із поточного робочого каталогу, якщо він розташований +усередині налаштованого робочого простору агента, а потім із типового агента. -Ця команда CLI `install` завантажує теки Skills з ClawHub. Встановлення залежностей -Skills через Gateway, які запускаються під час онбордингу або з налаштувань Skills, -замість цього використовують окремий шлях запиту `skills.install`. +Ця команда CLI `install` завантажує папки Skills із ClawHub. Встановлення +залежностей Skills через Gateway, запущені з onboarding або налаштувань Skills, +натомість використовують окремий шлях запиту `skills.install`. Примітки: -- `search [query...]` приймає необов’язковий запит; не вказуйте його, щоб переглянути стандартну - стрічку пошуку ClawHub. +- `search [query...]` приймає необов’язковий запит; пропустіть його, щоб переглянути типовий + пошуковий потік ClawHub. - `search --limit ` обмежує кількість повернених результатів. -- `install --force` перезаписує наявну теку Skills робочого простору для того самого +- `install --force` перезаписує наявну папку Skill робочого простору для того самого slug. - `--agent ` націлюється на один налаштований робочий простір агента та перевизначає - визначення за поточним робочим каталогом. -- `update --all` оновлює лише відстежувані встановлення з ClawHub в активному робочому просторі. -- `list` є дією за замовчуванням, якщо не вказано підкоманду. -- `list`, `info` і `check` записують свій відформатований вивід у stdout. З - `--json` це означає, що машинозчитувані дані залишаються у stdout для каналів + визначення з поточного робочого каталогу. +- `update --all` оновлює лише відстежувані встановлення ClawHub в активному робочому просторі. +- `check --agent ` перевіряє робочий простір вибраного агента та повідомляє, які + готові Skills фактично видимі для prompt або командної поверхні цього агента. +- `list` є типовою дією, якщо підкоманду не вказано. +- `list`, `info` і `check` записують відрендерений вивід у stdout. З + `--json` це означає, що машиночитне корисне навантаження залишається в stdout для каналів і скриптів. -## Пов’язане +## Пов’язано -- [Довідка CLI](/uk/cli) +- [Довідник CLI](/uk/cli) - [Skills](/uk/tools/skills) diff --git a/docs/uk/gateway/doctor.md b/docs/uk/gateway/doctor.md index b806236ee..39069ce86 100644 --- a/docs/uk/gateway/doctor.md +++ b/docs/uk/gateway/doctor.md @@ -1,20 +1,20 @@ --- read_when: - Додавання або змінення міграцій doctor - - Запровадження несумісних змін конфігурації + - Впровадження несумісних змін конфігурації sidebarTitle: Doctor summary: 'Команда doctor: перевірки справності, міграції конфігурації та кроки відновлення' title: Діагностика x-i18n: - generated_at: "2026-05-02T15:57:45Z" + generated_at: "2026-05-02T18:57:45Z" model: gpt-5.5 provider: openai - source_hash: 1e8150c43662402a4dfe6eb89a804d1de3a73ad8a78f783fd0506e5976c2761f + source_hash: 504cf06e8457315eb1df4970a877b88fdc2e32f34974ce789875373e9e030234 source_path: gateway/doctor.md workflow: 16 --- -`openclaw doctor` — це інструмент виправлення + міграції для OpenClaw. Він виправляє застарілі конфігурацію/стан, перевіряє справність і надає практичні кроки для виправлення. +`openclaw doctor` — це інструмент відновлення + міграції для OpenClaw. Він виправляє застарілі конфігурації/стан, перевіряє працездатність і надає дієві кроки для відновлення. ## Швидкий старт @@ -22,7 +22,7 @@ x-i18n: openclaw doctor ``` -### Режими без інтерфейсу та автоматизації +### Безголові режими та режими автоматизації @@ -30,7 +30,7 @@ openclaw doctor openclaw doctor --yes ``` - Приймає стандартні варіанти без запитів (зокрема кроки перезапуску/сервісу/виправлення sandbox, коли застосовно). + Приймати стандартні значення без запитів (включно з кроками відновлення перезапуску/служби/пісочниці, коли застосовно). @@ -38,7 +38,7 @@ openclaw doctor openclaw doctor --repair ``` - Застосовує рекомендовані виправлення без запитів (виправлення + перезапуски, де це безпечно). + Застосувати рекомендовані виправлення без запитів (виправлення + перезапуски, де це безпечно). @@ -46,7 +46,7 @@ openclaw doctor openclaw doctor --repair --force ``` - Також застосовує агресивні виправлення (перезаписує користувацькі конфігурації супервізора). + Також застосувати агресивні виправлення (перезаписує користувацькі конфігурації супервізора). @@ -54,7 +54,7 @@ openclaw doctor openclaw doctor --non-interactive ``` - Запускається без запитів і застосовує лише безпечні міграції (нормалізація конфігурації + переміщення стану на диску). Пропускає дії перезапуску/сервісу/sandbox, які потребують підтвердження людини. Міграції застарілого стану запускаються автоматично, коли їх виявлено. + Запустити без запитів і застосувати лише безпечні міграції (нормалізація конфігурації + переміщення стану на диску). Пропускає дії перезапуску/служби/пісочниці, які потребують підтвердження людиною. Міграції застарілого стану запускаються автоматично після виявлення. @@ -62,7 +62,7 @@ openclaw doctor openclaw doctor --deep ``` - Сканує системні сервіси на наявність додаткових інсталяцій Gateway (launchd/systemd/schtasks). + Просканувати системні служби на додаткові встановлення gateway (launchd/systemd/schtasks). @@ -73,112 +73,113 @@ openclaw doctor cat ~/.openclaw/openclaw.json ``` -## Що він робить (коротко) +## Що він робить (зведення) - - - Необов’язкове попереднє оновлення для git-інсталяцій (лише інтерактивно). - - Перевірка актуальності протоколу UI (перезбирає Control UI, коли схема протоколу новіша). - - Перевірка справності + запит на перезапуск. - - Зведення стану Skills (придатні/відсутні/заблоковані) і стан Plugin. + + - Необов’язкове попереднє оновлення для git-встановлень (лише інтерактивно). + - Перевірка актуальності протоколу UI (перебудовує Control UI, коли схема протоколу новіша). + - Перевірка працездатності + запит на перезапуск. + - Зведення стану Skills (доступні/відсутні/заблоковані) і стан plugin. - + - Нормалізація конфігурації для застарілих значень. - - Міграція конфігурації Talk із застарілих пласких полів `talk.*` у `talk.provider` + `talk.providers.`. + - Міграція конфігурації Talk із застарілих плоских полів `talk.*` у `talk.provider` + `talk.providers.`. - Перевірки міграції браузера для застарілих конфігурацій розширення Chrome і готовності Chrome MCP. - Попередження про перевизначення провайдера OpenCode (`models.providers.opencode` / `models.providers.opencode-go`). - Попередження про затінення OAuth Codex (`models.providers.openai-codex`). - - Перевірка передумов OAuth TLS для профілів OpenAI Codex OAuth. - - Попередження allowlist Plugin/інструментів, коли `plugins.allow` є обмежувальним, але політика інструментів досі запитує wildcard або інструменти, що належать Plugin. + - Перевірка передумов TLS OAuth для профілів OpenAI Codex OAuth. + - Попередження щодо списку дозволених plugin/інструментів, коли `plugins.allow` є обмежувальним, але політика інструментів усе ще запитує wildcard або інструменти, що належать plugin. - Міграція застарілого стану на диску (сесії/каталог агента/автентифікація WhatsApp). - - Міграція застарілих ключів контракту маніфесту Plugin (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders` → `contracts`). - - Міграція застарілого сховища cron (`jobId`, `schedule.cron`, поля доставки/корисного навантаження верхнього рівня, `provider` у корисному навантаженні, прості резервні webhook-завдання `notify: true`). - - Міграція застарілої політики runtime агента до `agents.defaults.agentRuntime` і `agents.list[].agentRuntime`. - - Очищення застарілої конфігурації Plugin, коли плагіни ввімкнені; коли `plugins.enabled=false`, застарілі посилання на Plugin розглядаються як інертна конфігурація ізоляції та зберігаються. + - Міграція застарілих ключів контракту маніфесту plugin (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders` → `contracts`). + - Міграція застарілого сховища cron (`jobId`, `schedule.cron`, поля доставки/payload верхнього рівня, payload `provider`, прості резервні webhook-завдання `notify: true`). + - Міграція застарілої runtime-policy агента до `agents.defaults.agentRuntime` і `agents.list[].agentRuntime`. + - Очищення застарілої конфігурації plugin, коли plugins увімкнені; коли `plugins.enabled=false`, застарілі посилання на plugin вважаються інертною конфігурацією стримування та зберігаються. - - - Перевірка файлів блокування сесій і очищення застарілих блокувань. - - Виправлення транскриптів сесій для дубльованих гілок переписування prompt, створених ураженими збірками 2026.4.24. - - Виявлення tombstone для відновлення після перезапуску завислого субагента, з підтримкою `--fix` для очищення застарілих прапорців перерваного відновлення, щоб запуск не продовжував вважати дочірній процес перерваним через перезапуск. + + - Перевірка lock-файлів сесій і очищення застарілих lock-файлів. + - Відновлення транскриптів сесій для дубльованих гілок переписування промптів, створених у зачеплених збірках 2026.4.24. + - Виявлення tombstone для відновлення після перезапуску застряглого subagent, з підтримкою `--fix` для очищення застарілих прапорців перерваного відновлення, щоб запуск не продовжував вважати дочірній процес перерваним під час перезапуску. - Перевірки цілісності стану та дозволів (сесії, транскрипти, каталог стану). - Перевірки дозволів файлу конфігурації (chmod 600) під час локального запуску. - - Справність автентифікації моделей: перевіряє завершення строку дії OAuth, може оновлювати токени, що скоро спливають, і повідомляє про cooldown/вимкнені стани auth-profile. - - Виявлення додаткового каталогу робочого простору (`~/openclaw`). + - Стан автентифікації моделі: перевіряє завершення строку дії OAuth, може оновлювати токени, строк дії яких спливає, і повідомляє про стани cooldown/disabled auth-profile. + - Виявлення додаткового каталогу робочої області (`~/openclaw`). - - - Виправлення образу sandbox, коли sandboxing увімкнено. - - Міграція застарілих сервісів і виявлення додаткових Gateway. + + - Відновлення образу пісочниці, коли sandboxing увімкнено. + - Міграція застарілої служби та виявлення додаткових gateway. - Міграція застарілого стану каналу Matrix (у режимі `--fix` / `--repair`). - - Перевірки runtime Gateway (сервіс встановлено, але він не запущений; кешована мітка launchd). - - Попередження про стан каналу (зондуються із запущеного Gateway). - - Аудит конфігурації супервізора (launchd/systemd/schtasks) з необов’язковим виправленням. - - Очищення середовища вбудованого проксі для сервісів Gateway, які захопили значення shell `HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY` під час інсталяції або оновлення. + - Перевірки runtime Gateway (службу встановлено, але вона не запущена; кешована мітка launchd). + - Попередження про стан каналів (перевіряються з запущеного gateway). + - Аудит конфігурації супервізора (launchd/systemd/schtasks) з необов’язковим відновленням. + - Очищення середовища вбудованого проксі для служб gateway, які захопили значення shell `HTTP_PROXY` / `HTTPS_PROXY` / `NO_PROXY` під час встановлення або оновлення. - Перевірки найкращих практик runtime Gateway (Node проти Bun, шляхи менеджера версій). - - Діагностика конфліктів порту Gateway (стандартно `18789`). + - Діагностика конфлікту порту Gateway (типово `18789`). - + - Попередження безпеки для відкритих політик DM. - - Перевірки автентифікації Gateway для режиму локального токена (пропонує генерацію токена, коли джерела токена немає; не перезаписує конфігурації токена SecretRef). - - Виявлення проблем зі спарюванням пристрою (очікувані запити першого спарювання, очікувані підвищення ролі/області дії, застарілий дрейф локального кешу device-token і дрейф автентифікації paired-record). + - Перевірки автентифікації Gateway для режиму локального токена (пропонує генерацію токена, коли джерела токена немає; не перезаписує конфігурації SecretRef токена). + - Виявлення проблем зі спарюванням пристроїв (очікувані перші запити на спарювання, очікувані оновлення ролі/області, застарілий drift локального кешу device-token і drift автентифікації paired-record). - + - Перевірка systemd linger у Linux. - - Перевірка розміру bootstrap-файлу робочого простору (попередження про обрізання/наближення до ліміту для файлів контексту). - - Перевірка стану shell completion і автоінсталяція/оновлення. - - Перевірка готовності провайдера embedding для пошуку в пам’яті (локальна модель, ключ remote API або бінарний файл QMD). - - Перевірки інсталяції з джерел (невідповідність робочого простору pnpm, відсутні UI-ресурси, відсутній бінарний файл tsx). - - Записує оновлену конфігурацію + метадані майстра. + - Перевірка розміру bootstrap-файлу робочої області (попередження про обрізання/наближення до ліміту для контекстних файлів). + - Перевірка готовності Skills для агента за замовчуванням; повідомляє дозволені skills з відсутніми bin, env, config або вимогами ОС, а `--fix` може вимкнути недоступні skills у `skills.entries`. + - Перевірка стану автодоповнення shell і автоматичне встановлення/оновлення. + - Перевірка готовності embedding-провайдера пошуку пам’яті (локальна модель, ключ віддаленого API або бінарний файл QMD). + - Перевірки встановлення з джерел (невідповідність робочої області pnpm, відсутні UI-ресурси, відсутній бінарний файл tsx). + - Записує оновлену конфігурацію + метадані wizard. -## Заповнення й скидання Dreams UI +## Зворотне заповнення та скидання Dreams UI -Сцена Dreams у Control UI включає дії **Backfill**, **Reset** і **Clear Grounded** для робочого процесу grounded dreaming. Ці дії використовують RPC-методи в стилі gateway doctor, але вони **не** є частиною виправлення/міграції CLI `openclaw doctor`. +Сцена Dreams у Control UI містить дії **Backfill**, **Reset** і **Clear Grounded** для workflow grounded dreaming. Ці дії використовують RPC-методи в стилі gateway doctor, але вони **не** є частиною CLI-відновлення/міграції `openclaw doctor`. Що вони роблять: -- **Backfill** сканує історичні файли `memory/YYYY-MM-DD.md` в активному робочому просторі, запускає grounded REM diary pass і записує оборотні backfill-записи в `DREAMS.md`. -- **Reset** видаляє з `DREAMS.md` лише ці позначені backfill-записи щоденника. -- **Clear Grounded** видаляє лише staged grounded-only короткострокові записи, що походять з історичного replay і ще не накопичили live recall або daily support. +- **Backfill** сканує історичні файли `memory/YYYY-MM-DD.md` в активній робочій області, запускає grounded REM diary pass і записує оборотні записи зворотного заповнення в `DREAMS.md`. +- **Reset** видаляє лише ці позначені diary-записи зворотного заповнення з `DREAMS.md`. +- **Clear Grounded** видаляє лише підготовлені короткострокові записи grounded-only, які походять з історичного replay і ще не накопичили live recall або daily support. -Що вони **не** роблять самі по собі: +Чого вони самі по собі **не** роблять: - вони не редагують `MEMORY.md` - вони не запускають повні міграції doctor -- вони не додають автоматично staged grounded candidates у live short-term promotion store, якщо ви спершу явно не запустите staged CLI path +- вони автоматично не розміщують grounded-кандидатів у live short-term promotion store, якщо ви явно спершу не запустите staged CLI path -Якщо ви хочете, щоб grounded historical replay впливав на звичайний deep promotion lane, використовуйте натомість CLI-потік: +Якщо ви хочете, щоб grounded historical replay впливав на звичайну deep promotion lane, натомість використайте CLI-flow: ```bash openclaw memory rem-backfill --path ./memory --stage-short-term ``` -Це додає grounded durable candidates у short-term dreaming store, залишаючи `DREAMS.md` поверхнею для перегляду. +Це розміщує grounded durable candidates у short-term dreaming store, залишаючи `DREAMS.md` поверхнею для перегляду. -## Докладна поведінка й обґрунтування +## Детальна поведінка та обґрунтування - + Якщо це git checkout і doctor запускається інтерактивно, він пропонує оновитися (fetch/rebase/build) перед запуском doctor. - + Якщо конфігурація містить застарілі форми значень (наприклад, `messages.ackReaction` без перевизначення для конкретного каналу), doctor нормалізує їх до поточної схеми. - Це включає застарілі пласкі поля Talk. Поточна публічна конфігурація Talk — це `talk.provider` + `talk.providers.`. Doctor переписує старі форми `talk.voiceId` / `talk.voiceAliases` / `talk.modelId` / `talk.outputFormat` / `talk.apiKey` у мапу провайдера. + Це включає застарілі плоскі поля Talk. Поточна публічна конфігурація Talk — це `talk.provider` + `talk.providers.`. Doctor переписує старі форми `talk.voiceId` / `talk.voiceAliases` / `talk.modelId` / `talk.outputFormat` / `talk.apiKey` у мапу провайдерів. - Doctor також попереджає, коли `plugins.allow` не порожній, а політика інструментів використовує - wildcard або записи інструментів, що належать Plugin. `tools.allow: ["*"]` відповідає лише інструментам - із Plugin, які фактично завантажуються; він не обходить ексклюзивний allowlist Plugin. + Doctor також попереджає, коли `plugins.allow` не порожній і політика інструментів використовує + wildcard або записи інструментів, що належать plugin. `tools.allow: ["*"]` відповідає лише інструментам + із plugins, які фактично завантажуються; це не обходить ексклюзивний список дозволених plugin. - - Коли конфігурація містить застарілі ключі, інші команди відмовляються запускатися та просять вас виконати `openclaw doctor`. + + Коли конфігурація містить застарілі ключі, інші команди відмовляються запускатися й просять вас запустити `openclaw doctor`. Doctor: @@ -186,7 +187,7 @@ openclaw memory rem-backfill --path ./memory --stage-short-term - Покаже застосовану міграцію. - Перепише `~/.openclaw/openclaw.json` з оновленою схемою. - Gateway також автоматично запускає міграції doctor під час старту, коли виявляє застарілий формат конфігурації, тож застарілі конфігурації виправляються без ручного втручання. Міграції сховища cron-завдань обробляються через `openclaw doctor --fix`. + Gateway також автоматично запускає міграції doctor під час запуску, коли виявляє застарілий формат конфігурації, тому застарілі конфігурації відновлюються без ручного втручання. Міграції сховища Cron-завдань обробляє `openclaw doctor --fix`. Поточні міграції: @@ -211,7 +212,7 @@ openclaw memory rem-backfill --path ./memory --stage-short-term - `plugins.entries.voice-call.config.streaming.sttProvider` → `plugins.entries.voice-call.config.streaming.provider` - `plugins.entries.voice-call.config.streaming.openaiApiKey|sttModel|silenceDurationMs|vadThreshold` → `plugins.entries.voice-call.config.streaming.providers.openai.*` - `bindings[].match.accountID` → `bindings[].match.accountId` - - Для каналів з іменованими `accounts`, але із залишковими верхньорівневими значеннями каналу для одного облікового запису, перемістіть ці значення з областю дії облікового запису до підвищеного облікового запису, вибраного для цього каналу (`accounts.default` для більшості каналів; Matrix може зберегти наявну відповідну іменовану/стандартну ціль) + - Для каналів з іменованими `accounts`, але із залишковими значеннями каналу верхнього рівня для одного облікового запису, перемістіть ці значення з областю дії облікового запису в підвищений обліковий запис, вибраний для цього каналу (`accounts.default` для більшості каналів; Matrix може зберегти наявну відповідну іменовану/типову ціль) - `identity` → `agents.list[].identity` - `agent.*` → `agents.defaults` + `tools.*` (tools/elevated/exec/sandbox/subagents) - `agent.model`/`allowedModels`/`modelAliases`/`modelFallbacks`/`imageModelFallbacks` → `agents.defaults.models` + `agents.defaults.model.primary/fallbacks` + `agents.defaults.imageModel.primary/fallbacks` @@ -219,276 +220,276 @@ openclaw memory rem-backfill --path ./memory --stage-short-term - `browser.ssrfPolicy.allowPrivateNetwork` → `browser.ssrfPolicy.dangerouslyAllowPrivateNetwork` - `browser.profiles.*.driver: "extension"` → `"existing-session"` - видаліть `browser.relayBindHost` (застаріле налаштування ретранслятора розширення) - - застаріле `models.providers.*.api: "openai"` → `"openai-completions"` (запуск Gateway також пропускає провайдерів, у яких `api` задано майбутнім або невідомим значенням enum, замість аварійно завершуватися у закритому режимі) + - застаріле `models.providers.*.api: "openai"` → `"openai-completions"` (запуск gateway також пропускає провайдери, у яких `api` встановлено на майбутнє або невідоме значення enum, замість аварійного завершення у закритому стані) - Попередження doctor також містять поради щодо стандартного облікового запису для багатооблікових каналів: + Попередження doctor також містять настанови щодо типового облікового запису для багатооблікових каналів: - Якщо налаштовано два або більше записів `channels..accounts` без `channels..defaultAccount` або `accounts.default`, doctor попереджає, що резервна маршрутизація може вибрати неочікуваний обліковий запис. - - Якщо `channels..defaultAccount` задано як невідомий ідентифікатор облікового запису, doctor попереджає і перелічує налаштовані ідентифікатори облікових записів. + - Якщо `channels..defaultAccount` встановлено на невідомий ID облікового запису, doctor попереджає і перелічує налаштовані ID облікових записів. - Якщо ви вручну додали `models.providers.opencode`, `opencode-zen` або `opencode-go`, це перевизначає вбудований каталог OpenCode з `@mariozechner/pi-ai`. Це може примусово спрямувати моделі до неправильного API або обнулити витрати. Doctor попереджає, щоб ви могли видалити перевизначення та відновити маршрутизацію API й витрати для кожної моделі. + Якщо ви вручну додали `models.providers.opencode`, `opencode-zen` або `opencode-go`, це перевизначає вбудований каталог OpenCode з `@mariozechner/pi-ai`. Це може примусово спрямувати моделі на неправильний API або обнулити вартість. Doctor попереджає, щоб ви могли видалити перевизначення і відновити маршрутизацію API та вартість для кожної моделі. - - Якщо ваша конфігурація браузера досі вказує на видалений шлях розширення Chrome, doctor нормалізує її до поточної моделі локального для хоста підключення Chrome MCP: + + Якщо ваша конфігурація браузера все ще вказує на видалений шлях розширення Chrome, doctor нормалізує її до поточної моделі підключення host-local Chrome MCP: - `browser.profiles.*.driver: "extension"` стає `"existing-session"` - `browser.relayBindHost` видаляється - Doctor також перевіряє локальний для хоста шлях Chrome MCP, коли ви використовуєте `defaultProfile: "user"` або налаштований профіль `existing-session`: + Doctor також перевіряє шлях host-local Chrome MCP, коли ви використовуєте `defaultProfile: "user"` або налаштований профіль `existing-session`: - - перевіряє, чи встановлено Google Chrome на тому самому хості для стандартних профілів автоматичного підключення + - перевіряє, чи Google Chrome встановлено на тому самому хості для типових профілів автоматичного підключення - перевіряє виявлену версію Chrome і попереджає, коли вона нижча за Chrome 144 - нагадує увімкнути віддалене налагодження на сторінці інспектування браузера (наприклад, `chrome://inspect/#remote-debugging`, `brave://inspect/#remote-debugging` або `edge://inspect/#remote-debugging`) - Doctor не може увімкнути налаштування на боці Chrome замість вас. Локальний для хоста Chrome MCP усе ще потребує: + Doctor не може ввімкнути налаштування на стороні Chrome замість вас. Host-local Chrome MCP усе ще потребує: - - браузер на основі Chromium 144+ на хості gateway/node - - браузер, що працює локально - - увімкнене віддалене налагодження в цьому браузері - - підтвердження першого запиту згоди на підключення в браузері + - браузера на основі Chromium 144+ на хості gateway/node + - локально запущеного браузера + - увімкненого віддаленого налагодження в цьому браузері + - схвалення першого запиту згоди на підключення в браузері - Готовність тут стосується лише передумов локального підключення. Existing-session зберігає поточні обмеження маршрутів Chrome MCP; розширені маршрути на кшталт `responsebody`, експорту PDF, перехоплення завантажень і пакетних дій усе ще потребують керованого браузера або сирого профілю CDP. + Готовність тут стосується лише передумов локального підключення. Existing-session зберігає поточні обмеження маршрутів Chrome MCP; розширені маршрути, як-от `responsebody`, експорт PDF, перехоплення завантажень і пакетні дії, усе ще потребують керованого браузера або сирого профілю CDP. - Ця перевірка **не** застосовується до Docker, sandbox, remote-browser або інших безголових потоків. Вони й далі використовують сирий CDP. + Ця перевірка **не** застосовується до Docker, sandbox, remote-browser або інших headless-потоків. Вони й надалі використовують сирий CDP. - Коли налаштовано профіль OpenAI Codex OAuth, doctor перевіряє endpoint авторизації OpenAI, щоб переконатися, що локальний стек Node/OpenSSL TLS може перевірити ланцюг сертифікатів. Якщо перевірка завершується помилкою сертифіката (наприклад, `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, прострочений сертифікат або самопідписаний сертифікат), doctor виводить специфічні для платформи поради щодо виправлення. На macOS з Homebrew Node виправлення зазвичай таке: `brew postinstall ca-certificates`. З `--deep` перевірка виконується навіть тоді, коли gateway справний. + Коли налаштовано профіль OpenAI Codex OAuth, doctor перевіряє кінцеву точку авторизації OpenAI, щоб переконатися, що локальний стек Node/OpenSSL TLS може перевірити ланцюжок сертифікатів. Якщо перевірка завершується помилкою сертифіката (наприклад, `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, прострочений сертифікат або самопідписаний сертифікат), doctor виводить настанови з виправлення для конкретної платформи. На macOS з Homebrew Node виправленням зазвичай є `brew postinstall ca-certificates`. З `--deep` перевірка виконується навіть тоді, коли gateway справний. - Якщо раніше ви додали застарілі транспортні налаштування OpenAI у `models.providers.openai-codex`, вони можуть затіняти вбудований шлях провайдера Codex OAuth, який новіші випуски використовують автоматично. Doctor попереджає, коли бачить ці старі транспортні налаштування разом із Codex OAuth, щоб ви могли видалити або переписати застаріле транспортне перевизначення та повернути вбудовану поведінку маршрутизації/резервування. Користувацькі проксі та перевизначення лише заголовків і надалі підтримуються та не спричиняють це попередження. + Якщо раніше ви додали застарілі налаштування транспорту OpenAI у `models.providers.openai-codex`, вони можуть затіняти вбудований шлях провайдера Codex OAuth, який новіші випуски використовують автоматично. Doctor попереджає, коли бачить ці старі налаштування транспорту поряд із Codex OAuth, щоб ви могли видалити або переписати застаріле перевизначення транспорту і повернути вбудовану поведінку маршрутизації/резервування. Користувацькі проксі та перевизначення лише заголовків усе ще підтримуються і не запускають це попередження. - - Коли ввімкнено комплектний Plugin Codex, doctor також перевіряє, чи refs первинних моделей `openai-codex/*` досі розв'язуються через стандартний runner PI. Така комбінація є дійсною, коли ви хочете використовувати Codex OAuth/автентифікацію підписки через PI, але її легко сплутати з нативним harness сервера застосунку Codex. Doctor попереджає та вказує на явну форму сервера застосунку: `openai/*` плюс `agentRuntime.id: "codex"` або `OPENCLAW_AGENT_RUNTIME=codex`. + + Коли вбудований Codex plugin увімкнено, doctor також перевіряє, чи посилання на первинні моделі `openai-codex/*` досі розв'язуються через типовий PI runner. Така комбінація чинна, коли ви хочете використовувати автентифікацію Codex OAuth/підписки через PI, але її легко сплутати з нативним app-server harness Codex. Doctor попереджає і вказує на явну форму app-server: `openai/*` плюс `agentRuntime.id: "codex"` або `OPENCLAW_AGENT_RUNTIME=codex`. - Doctor не виправляє це автоматично, бо обидва маршрути є дійсними: + Doctor не виправляє це автоматично, бо обидва маршрути чинні: - - `openai-codex/*` + PI означає «використовувати Codex OAuth/автентифікацію підписки через звичайний runner OpenClaw». - - `openai/*` + `agentRuntime.id: "codex"` означає «виконати вбудований turn через нативний сервер застосунку Codex». - - `/codex ...` означає «керувати або прив'язати нативну розмову Codex із чату». - - `/acp ...` або `runtime: "acp"` означає «використовувати зовнішній адаптер ACP/acpx». + - `openai-codex/*` + PI означає "використовувати автентифікацію Codex OAuth/підписки через звичайний runner OpenClaw." + - `openai/*` + `agentRuntime.id: "codex"` означає "запустити вбудований turn через нативний app-server Codex." + - `/codex ...` означає "керувати або прив'язати нативну розмову Codex з чату." + - `/acp ...` або `runtime: "acp"` означає "використовувати зовнішній адаптер ACP/acpx." - Якщо з'являється попередження, виберіть потрібний маршрут і відредагуйте конфігурацію вручну. Залиште попередження без змін, коли PI Codex OAuth є навмисним. + Якщо з'являється попередження, виберіть потрібний маршрут і відредагуйте конфігурацію вручну. Залиште попередження як є, коли PI Codex OAuth є навмисним. - Doctor може мігрувати старіші розкладки на диску до поточної структури: + Doctor може мігрувати старіші розкладки на диску в поточну структуру: - - Сховище сеансів + transcripts: + - Сховище сесій + транскрипти: - з `~/.openclaw/sessions/` до `~/.openclaw/agents//sessions/` - Каталог агента: - з `~/.openclaw/agent/` до `~/.openclaw/agents//agent/` - Стан автентифікації WhatsApp (Baileys): - із застарілих `~/.openclaw/credentials/*.json` (крім `oauth.json`) - - до `~/.openclaw/credentials/whatsapp//...` (стандартний ідентифікатор облікового запису: `default`) + - до `~/.openclaw/credentials/whatsapp//...` (типовий ID облікового запису: `default`) - Ці міграції виконуються за принципом найкращого зусилля та є ідемпотентними; doctor виводитиме попередження, коли залишатиме будь-які застарілі папки як резервні копії. Gateway/CLI також автоматично мігрує застарілі сеанси + каталог агента під час запуску, щоб історія/автентифікація/моделі потрапляли в шлях для конкретного агента без ручного запуску doctor. Автентифікація WhatsApp навмисно мігрується лише через `openclaw doctor`. Нормалізація провайдера talk/мапи провайдерів тепер порівнює за структурною рівністю, тому різниці лише в порядку ключів більше не спричиняють повторних змін без ефекту від `doctor --fix`. + Ці міграції виконуються за принципом найкращого зусилля та є ідемпотентними; doctor виводитиме попередження, коли залишає будь-які застарілі папки як резервні копії. Gateway/CLI також автоматично мігрує застарілі сесії + каталог агента під час запуску, щоб історія/автентифікація/моделі потрапили у шлях для конкретного агента без ручного запуску doctor. Нормалізація провайдера talk/мапи провайдерів тепер порівнює за структурною рівністю, тому відмінності лише в порядку ключів більше не запускають повторні no-op зміни `doctor --fix`. - - Doctor сканує всі встановлені маніфести Plugin на наявність застарілих верхньорівневих ключів можливостей (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders`). Коли їх знайдено, він пропонує перемістити їх до об'єкта `contracts` і переписати файл маніфесту на місці. Ця міграція є ідемпотентною; якщо ключ `contracts` уже має ті самі значення, застарілий ключ видаляється без дублювання даних. + + Doctor сканує всі встановлені маніфести plugin на наявність застарілих ключів можливостей верхнього рівня (`speechProviders`, `realtimeTranscriptionProviders`, `realtimeVoiceProviders`, `mediaUnderstandingProviders`, `imageGenerationProviders`, `videoGenerationProviders`, `webFetchProviders`, `webSearchProviders`). Коли їх знайдено, він пропонує перемістити їх до об'єкта `contracts` і переписати файл маніфесту на місці. Ця міграція ідемпотентна; якщо ключ `contracts` уже має ті самі значення, застарілий ключ видаляється без дублювання даних. - - Doctor також перевіряє сховище завдань cron (`~/.openclaw/cron/jobs.json` за замовчуванням або `cron.store`, коли перевизначено) на старі форми завдань, які планувальник досі приймає для сумісності. + + Doctor також перевіряє сховище завдань cron (`~/.openclaw/cron/jobs.json` типово або `cron.store`, коли перевизначено) на наявність старих форм завдань, які планувальник усе ще приймає для сумісності. Поточні очищення cron включають: - `jobId` → `id` - `schedule.cron` → `schedule.expr` - - верхньорівневі поля payload (`message`, `model`, `thinking`, ...) → `payload` - - верхньорівневі поля delivery (`deliver`, `channel`, `to`, `provider`, ...) → `delivery` - - псевдоніми доставки payload `provider` → явний `delivery.channel` - - прості застарілі резервні webhook-завдання `notify: true` → явний `delivery.mode="webhook"` з `delivery.to=cron.webhook` + - поля payload верхнього рівня (`message`, `model`, `thinking`, ...) → `payload` + - поля delivery верхнього рівня (`deliver`, `channel`, `to`, `provider`, ...) → `delivery` + - delivery-псевдоніми `provider` у payload → явний `delivery.channel` + - прості застарілі резервні завдання webhook `notify: true` → явний `delivery.mode="webhook"` з `delivery.to=cron.webhook` - Doctor автоматично мігрує завдання `notify: true` лише тоді, коли може зробити це без зміни поведінки. Якщо завдання поєднує застарілий резервний notify з наявним режимом доставки не через webhook, doctor попереджає та залишає це завдання для ручного перегляду. + Doctor автоматично мігрує завдання `notify: true` лише тоді, коли може зробити це без зміни поведінки. Якщо завдання поєднує застарілий резервний notify з наявним режимом доставки не через webhook, doctor попереджає і залишає це завдання для ручного перегляду. - На Linux doctor також попереджає, коли crontab користувача досі викликає застарілий `~/.openclaw/bin/ensure-whatsapp.sh`. Цей локальний для хоста скрипт не підтримується поточним OpenClaw і може записувати хибні повідомлення `Gateway inactive` до `~/.openclaw/logs/whatsapp-health.log`, коли cron не може досягти користувацької шини systemd. Видаліть застарілий запис crontab за допомогою `crontab -e`; використовуйте `openclaw channels status --probe`, `openclaw doctor` і `openclaw gateway status` для поточних перевірок справності. + На Linux doctor також попереджає, коли crontab користувача все ще викликає застарілий `~/.openclaw/bin/ensure-whatsapp.sh`. Цей host-local скрипт не підтримується поточним OpenClaw і може записувати хибні повідомлення `Gateway inactive` до `~/.openclaw/logs/whatsapp-health.log`, коли cron не може дістатися до користувацької шини systemd. Видаліть застарілий запис crontab за допомогою `crontab -e`; використовуйте `openclaw channels status --probe`, `openclaw doctor` і `openclaw gateway status` для поточних перевірок справності. - Засіб діагностики сканує кожен каталог сеансу агента на наявність застарілих файлів блокування запису — файлів, що залишилися після аварійного завершення сеансу. Для кожного знайденого файлу блокування він повідомляє: шлях, PID, чи PID досі активний, вік блокування та чи вважається воно застарілим (мертвий PID або старше ніж 30 хвилин). У режимі `--fix` / `--repair` він автоматично видаляє застарілі файли блокування; інакше друкує примітку та вказує повторно запустити з `--fix`. + Doctor сканує кожен каталог сеансів агентів на наявність застарілих файлів блокування запису — файлів, що залишилися після аварійного завершення сеансу. Для кожного знайденого файлу блокування він повідомляє: шлях, PID, чи PID досі активний, вік блокування та чи вважається воно застарілим (мертвий PID або старіше за 30 хвилин). У режимі `--fix` / `--repair` він автоматично видаляє застарілі файли блокування; інакше друкує примітку та вказує повторно запустити з `--fix`. - - Засіб діагностики сканує JSONL-файли сеансів агентів на наявність дубльованої форми гілки, створеної помилкою переписування транскрипту промпта від 2026.4.24: покинутий хід користувача з внутрішнім runtime-контекстом OpenClaw і активний сусідній хід із тим самим видимим користувацьким промптом. У режимі `--fix` / `--repair` засіб діагностики створює резервну копію кожного зачепленого файлу поруч з оригіналом і переписує транскрипт на активну гілку, щоб історія Gateway і читачі пам’яті більше не бачили дубльованих ходів. + + Doctor сканує JSONL-файли сеансів агентів на дубльовану форму гілки, створену помилкою переписування транскрипту промпта від 2026.4.24: покинутий хід користувача з внутрішнім runtime-контекстом OpenClaw плюс активний сусідній елемент із тим самим видимим промптом користувача. У режимі `--fix` / `--repair` doctor створює резервну копію кожного ураженого файлу поруч з оригіналом і переписує транскрипт до активної гілки, щоб історія gateway і читачі пам’яті більше не бачили дубльованих ходів. - Каталог стану — це операційний мозковий стовбур. Якщо він зникне, ви втратите сеанси, облікові дані, журнали та конфігурацію (якщо не маєте резервних копій деінде). + Каталог стану — це операційний стовбур системи. Якщо він зникне, ви втратите сеанси, облікові дані, журнали та конфігурацію (якщо не маєте резервних копій деінде). - Засіб діагностики перевіряє: + Doctor перевіряє: - **Каталог стану відсутній**: попереджає про катастрофічну втрату стану, пропонує повторно створити каталог і нагадує, що не може відновити відсутні дані. - **Дозволи каталогу стану**: перевіряє можливість запису; пропонує виправити дозволи (і виводить підказку `chown`, коли виявлено невідповідність власника/групи). - - **Каталог стану macOS, синхронізований із хмарою**: попереджає, коли стан розташовано під iCloud Drive (`~/Library/Mobile Documents/com~apple~CloudDocs/...`) або `~/Library/CloudStorage/...`, бо шляхи із синхронізацією можуть спричиняти повільніше I/O та перегони блокування/синхронізації. - - **Каталог стану Linux на SD або eMMC**: попереджає, коли стан розташовано на джерелі монтування `mmcblk*`, бо випадкове I/O на SD або eMMC може бути повільнішим і швидше зношувати носій під час записів сеансів і облікових даних. + - **Синхронізований із хмарою каталог стану macOS**: попереджає, коли стан розміщується під iCloud Drive (`~/Library/Mobile Documents/com~apple~CloudDocs/...`) або `~/Library/CloudStorage/...`, оскільки шляхи з синхронізацією можуть спричиняти повільніше I/O та перегони блокування/синхронізації. + - **Каталог стану Linux на SD або eMMC**: попереджає, коли стан розміщується на джерелі монтування `mmcblk*`, оскільки випадкове I/O на SD або eMMC може бути повільнішим і швидше зношувати носій під час записів сеансів та облікових даних. - **Каталоги сеансів відсутні**: `sessions/` і каталог сховища сеансів потрібні для збереження історії та уникнення збоїв `ENOENT`. - - **Невідповідність транскриптів**: попереджає, коли в нещодавніх записах сеансів бракує файлів транскриптів. - - **Основний сеанс "1-рядковий JSONL"**: позначає випадки, коли основний транскрипт має лише один рядок (історія не накопичується). - - **Кілька каталогів стану**: попереджає, коли в домашніх каталогах існує кілька папок `~/.openclaw` або коли `OPENCLAW_STATE_DIR` вказує в інше місце (історія може розділитися між інсталяціями). - - **Нагадування про віддалений режим**: якщо `gateway.mode=remote`, засіб діагностики нагадує запустити його на віддаленому хості (стан міститься там). + - **Невідповідність транскрипту**: попереджає, коли в нещодавніх записах сеансів відсутні файли транскриптів. + - **Основний сеанс "1-line JSONL"**: позначає випадок, коли основний транскрипт має лише один рядок (історія не накопичується). + - **Кілька каталогів стану**: попереджає, коли в домашніх каталогах існує кілька папок `~/.openclaw` або коли `OPENCLAW_STATE_DIR` вказує в інше місце (історія може розділятися між інсталяціями). + - **Нагадування про віддалений режим**: якщо `gateway.mode=remote`, doctor нагадує запустити його на віддаленому хості (стан зберігається там). - **Дозволи файлу конфігурації**: попереджає, якщо `~/.openclaw/openclaw.json` доступний для читання групі/всім, і пропонує посилити дозволи до `600`. - - Засіб діагностики перевіряє OAuth-профілі в сховищі автентифікації, попереджає, коли термін дії токенів скоро спливає або вже сплив, і може безпечно оновити їх, коли це можливо. Якщо OAuth/токен-профіль Anthropic застарів, він пропонує API-ключ Anthropic або шлях setup-token Anthropic. Запити на оновлення з’являються лише під час інтерактивного запуску (TTY); `--non-interactive` пропускає спроби оновлення. + + Doctor перевіряє профілі OAuth у сховищі автентифікації, попереджає, коли строк дії токенів минає або вже минув, і може безпечно оновити їх. Якщо профіль Anthropic OAuth/token застарів, він пропонує ключ API Anthropic або шлях setup-token Anthropic. Запити на оновлення з’являються лише під час інтерактивного запуску (TTY); `--non-interactive` пропускає спроби оновлення. - Коли оновлення OAuth остаточно не вдається (наприклад `refresh_token_reused`, `invalid_grant` або провайдер просить увійти знову), засіб діагностики повідомляє, що потрібна повторна автентифікація, і друкує точну команду `openclaw models auth login --provider ...`, яку потрібно запустити. + Коли оновлення OAuth остаточно не вдається (наприклад, `refresh_token_reused`, `invalid_grant` або провайдер просить увійти знову), doctor повідомляє, що потрібна повторна автентифікація, і друкує точну команду `openclaw models auth login --provider ...` для запуску. - Засіб діагностики також повідомляє про профілі автентифікації, які тимчасово непридатні через: + Doctor також повідомляє про профілі автентифікації, які тимчасово непридатні через: - - короткі періоди очікування (обмеження частоти/тайм-аути/помилки автентифікації) - - довші вимкнення (помилки білінгу/кредитів) + - короткі періоди очікування (обмеження швидкості/тайм-аути/збої автентифікації) + - довші вимкнення (збої оплати/кредитів) - - Якщо `hooks.gmail.model` задано, засіб діагностики перевіряє посилання на модель за каталогом і allowlist та попереджає, коли його не вдасться розв’язати або воно заборонене. + + Якщо встановлено `hooks.gmail.model`, doctor перевіряє посилання на модель за каталогом і allowlist та попереджає, коли воно не розв’яжеться або заборонене. - Коли пісочницю ввімкнено, засіб діагностики перевіряє Docker-образи й пропонує зібрати або перемкнутися на застарілі назви, якщо поточний образ відсутній. + Коли sandboxing увімкнено, doctor перевіряє образи Docker і пропонує зібрати або перейти на застарілі назви, якщо поточного образу немає. - - Засіб діагностики видаляє застарілий згенерований OpenClaw стан проміжної підготовки залежностей плагінів у режимі `openclaw doctor --fix` / `openclaw doctor --repair`. Це охоплює застарілі згенеровані корені залежностей, старі каталоги етапу встановлення та локальне сміття пакетів від попереднього коду відновлення залежностей bundled-plugin. + + Doctor видаляє застарілий згенерований OpenClaw проміжний стан залежностей Plugin у режимі `openclaw doctor --fix` / `openclaw doctor --repair`. Це охоплює застарілі згенеровані корені залежностей, старі каталоги install-stage і локальні для пакета залишки від попереднього коду відновлення залежностей bundled-plugin. - Засіб діагностики також може перевстановити налаштовані завантажувані плагіни, коли конфігурація посилається на них, але локальний реєстр плагінів не може їх знайти. Для винесення bundled-plugin назовні у версії 2026.5.2 засіб діагностики автоматично встановлює завантажувані плагіни, які вже використовує наявна конфігурація, а потім покладається на `meta.lastTouchedVersion`, щоб виконати цей релізний прохід лише один раз. Запуск Gateway і перезавантаження конфігурації не запускають менеджери пакетів; встановлення плагінів залишається явною роботою doctor/install/update. + Doctor також може перевстановити налаштовані завантажувані plugins, коли конфігурація посилається на них, але локальний реєстр plugin не може їх знайти. Для externalization bundled-plugin у 2026.5.2 doctor автоматично встановлює завантажувані plugins, які вже використовує наявна конфігурація, а потім покладається на `meta.lastTouchedVersion`, щоб виконати цей релізний прохід лише один раз. Запуск Gateway і перезавантаження конфігурації не запускають менеджери пакетів; інсталяції plugin залишаються явною роботою doctor/install/update. - - Засіб діагностики виявляє застарілі служби Gateway (launchd/systemd/schtasks) і пропонує видалити їх та встановити службу OpenClaw із поточним портом Gateway. Він також може просканувати додаткові Gateway-подібні служби та надрукувати підказки з очищення. Служби Gateway OpenClaw з іменами профілів вважаються повноцінними та не позначаються як "додаткові". + + Doctor виявляє застарілі сервіси gateway (launchd/systemd/schtasks) і пропонує видалити їх та встановити сервіс OpenClaw з використанням поточного порту gateway. Він також може сканувати наявність додаткових сервісів, схожих на gateway, і друкувати підказки з очищення. Сервіси gateway OpenClaw з іменами профілів вважаються повноцінними та не позначаються як "додаткові." - У Linux, якщо користувацька служба Gateway відсутня, але існує системна служба Gateway OpenClaw, засіб діагностики не встановлює другу користувацьку службу автоматично. Перевірте за допомогою `openclaw gateway status --deep` або `openclaw doctor --deep`, а потім видаліть дублікат або задайте `OPENCLAW_SERVICE_REPAIR_POLICY=external`, коли життєвим циклом Gateway керує системний супервізор. + У Linux, якщо сервіс gateway на рівні користувача відсутній, але існує сервіс gateway OpenClaw на рівні системи, doctor не встановлює автоматично другий сервіс на рівні користувача. Перевірте за допомогою `openclaw gateway status --deep` або `openclaw doctor --deep`, а потім видаліть дублікат або встановіть `OPENCLAW_SERVICE_REPAIR_POLICY=external`, коли системний супервізор керує життєвим циклом gateway. - - Коли обліковий запис каналу Matrix має очікувану або придатну до дії міграцію застарілого стану, засіб діагностики (у режимі `--fix` / `--repair`) створює знімок перед міграцією, а потім виконує найкращі можливі кроки міграції: міграцію застарілого стану Matrix і підготовку застарілого зашифрованого стану. Обидва кроки не є фатальними; помилки журналюються, а запуск продовжується. У режимі лише для читання (`openclaw doctor` без `--fix`) ця перевірка повністю пропускається. + + Коли обліковий запис каналу Matrix має очікувану або доступну для виконання міграцію застарілого стану, doctor (у режимі `--fix` / `--repair`) створює знімок перед міграцією, а потім виконує best-effort кроки міграції: міграцію застарілого стану Matrix і підготовку застарілого зашифрованого стану. Обидва кроки не є фатальними; помилки журналюються, а запуск продовжується. У режимі лише читання (`openclaw doctor` без `--fix`) ця перевірка повністю пропускається. - - Тепер засіб діагностики перевіряє стан сполучення пристроїв як частину звичайного проходу перевірки здоров’я. + + Doctor тепер перевіряє стан сполучення пристрою як частину звичайного проходу перевірки стану. Що він повідомляє: - - очікувані запити першого сполучення - - очікувані підвищення ролі для вже сполучених пристроїв - - очікувані підвищення scope для вже сполучених пристроїв - - відновлення невідповідності публічного ключа, коли ідентифікатор пристрою досі збігається, але ідентичність пристрою більше не відповідає схваленому запису - - сполучені записи, у яких бракує активного токена для схваленої ролі - - сполучені токени, чиї scope відхилилися за межі схваленої базової лінії сполучення - - локальні кешовані записи device-token для поточної машини, які передують ротації токена на боці Gateway або містять застарілі метадані scope + - запити на перше спарювання, що очікують + - підвищення ролі для вже спарених пристроїв, що очікують + - розширення області доступу для вже спарених пристроїв, що очікують + - виправлення невідповідності публічного ключа, коли ідентифікатор пристрою все ще збігається, але ідентичність пристрою більше не збігається із затвердженим записом + - спарені записи без активного токена для затвердженої ролі + - спарені токени, чиї області доступу відхилилися від затвердженої базової лінії спарювання + - локальні кешовані записи токенів пристрою для поточної машини, які передують ротації токена на боці gateway або містять застарілі метадані області доступу - Засіб діагностики не схвалює автоматично запити сполучення й не виконує автоматичну ротацію токенів пристроїв. Натомість він друкує точні наступні кроки: + Засіб діагностики не затверджує запити на спарювання автоматично й не виконує автоматичну ротацію токенів пристроїв. Натомість він друкує точні наступні кроки: - - перегляньте очікувані запити за допомогою `openclaw devices list` - - схваліть точний запит за допомогою `openclaw devices approve ` - - згенеруйте свіжий токен ротацією за допомогою `openclaw devices rotate --device --role ` - - видаліть і повторно схваліть застарілий запис за допомогою `openclaw devices remove ` + - перегляньте запити, що очікують, за допомогою `openclaw devices list` + - затвердьте точний запит за допомогою `openclaw devices approve ` + - виконайте ротацію нового токена за допомогою `openclaw devices rotate --device --role ` + - видаліть і повторно затвердьте застарілий запис за допомогою `openclaw devices remove ` - Це закриває поширену прогалину "вже сполучено, але все ще вимагає сполучення": тепер засіб діагностики відрізняє перше сполучення від очікуваних підвищень ролі/scope і від дрейфу застарілого токена/ідентичності пристрою. + Це закриває поширену прогалину "уже спарено, але все ще з'являється вимога спарювання": тепер засіб діагностики відрізняє перше спарювання від очікуваних підвищень ролі/області доступу та від дрейфу застарілого токена/ідентичності пристрою. - Засіб діагностики видає попередження, коли провайдер відкритий для DM без allowlist або коли політику налаштовано небезпечним способом. + Засіб діагностики видає попередження, коли провайдер відкритий для особистих повідомлень без allowlist або коли політику налаштовано небезпечним способом. - - Якщо запуск відбувається як користувацька служба systemd, засіб діагностики забезпечує ввімкнення lingering, щоб Gateway залишався активним після виходу з системи. + + Якщо запуск відбувається як користувацька служба systemd, засіб діагностики перевіряє, що lingering увімкнено, щоб gateway залишався активним після виходу із системи. - - Засіб діагностики друкує підсумок стану робочого простору для типового агента: + + Засіб діагностики друкує зведення стану робочого простору для агента за замовчуванням: - - **Стан Skills**: рахує придатні, з відсутніми вимогами та заблоковані allowlist Skills. - - **Застарілі каталоги робочого простору**: попереджає, коли `~/openclaw` або інші застарілі каталоги робочого простору існують поруч із поточним робочим простором. - - **Стан Plugin**: рахує ввімкнені/вимкнені/помилкові плагіни; перелічує ID плагінів для всіх помилок; повідомляє можливості bundle plugin. - - **Попередження сумісності Plugin**: позначає плагіни, які мають проблеми сумісності з поточним runtime. - - **Діагностика Plugin**: показує будь-які попередження або помилки під час завантаження, видані реєстром плагінів. + - **Стан Skills**: підраховує skills, що відповідають вимогам, не мають вимог або заблоковані allowlist. + - **Застарілі каталоги робочого простору**: попереджає, коли `~/openclaw` або інші застарілі каталоги робочого простору існують поряд із поточним робочим простором. + - **Стан Plugin**: підраховує увімкнені/вимкнені/помилкові plugins; перелічує ідентифікатори plugins для будь-яких помилок; повідомляє про можливості пакетних plugins. + - **Попередження сумісності Plugin**: позначає plugins, які мають проблеми сумісності з поточним середовищем виконання. + - **Діагностика Plugin**: показує будь-які попередження або помилки під час завантаження, видані реєстром plugin. - - Засіб діагностики перевіряє, чи файли початкового контексту робочого простору (наприклад `AGENTS.md`, `CLAUDE.md` або інші ін’єктовані контекстні файли) наближаються до налаштованого бюджету символів або перевищують його. Він повідомляє для кожного файлу необроблену й ін’єктовану кількість символів, відсоток обрізання, причину обрізання (`max/file` або `max/total`) і загальну кількість ін’єктованих символів як частку від загального бюджету. Коли файли обрізані або близькі до ліміту, засіб діагностики друкує поради для налаштування `agents.defaults.bootstrapMaxChars` і `agents.defaults.bootstrapTotalMaxChars`. + + Засіб діагностики перевіряє, чи bootstrap-файли робочого простору (наприклад `AGENTS.md`, `CLAUDE.md` або інші впроваджені файли контексту) наближаються до налаштованого бюджету символів або перевищують його. Він повідомляє для кожного файлу необроблену кількість символів порівняно з впровадженою, відсоток обрізання, причину обрізання (`max/file` або `max/total`) і загальну кількість впроваджених символів як частку від загального бюджету. Коли файли обрізано або вони близькі до ліміту, засіб діагностики друкує поради щодо налаштування `agents.defaults.bootstrapMaxChars` і `agents.defaults.bootstrapTotalMaxChars`. - - Коли `openclaw doctor --fix` видаляє відсутній плагін каналу, він також видаляє завислу конфігурацію в області цього каналу, яка посилалася на цей плагін: записи `channels.`, цілі Heartbeat, що називали канал, і перевизначення `agents.*.models["/*"]`. Це запобігає циклам завантаження Gateway, коли runtime каналу зник, але конфігурація все ще просить Gateway прив’язатися до нього. + + Коли `openclaw doctor --fix` видаляє відсутній channel plugin, він також видаляє підвішену конфігурацію з областю каналу, яка посилалася на цей plugin: записи `channels.`, цілі heartbeat, що називали канал, і перевизначення `agents.*.models["/*"]`. Це запобігає циклам завантаження Gateway, коли середовище виконання каналу зникло, але конфігурація все ще просить gateway прив'язатися до нього. - Засіб діагностики перевіряє, чи встановлено автодоповнення Tab для поточної оболонки (zsh, bash, fish або PowerShell): + Засіб діагностики перевіряє, чи встановлено автодоповнення клавішею Tab для поточної оболонки (zsh, bash, fish або PowerShell): - - Якщо профіль оболонки використовує повільний динамічний шаблон автодоповнення (`source <(openclaw completion ...)`), засіб діагностики оновлює його до швидшого варіанта з кешованим файлом. - - Якщо автодоповнення налаштовано в профілі, але файл кешу відсутній, засіб діагностики автоматично регенерує кеш. - - Якщо автодоповнення взагалі не налаштовано, засіб діагностики пропонує встановити його (лише інтерактивний режим; пропускається з `--non-interactive`). + - Якщо профіль оболонки використовує повільний динамічний шаблон доповнення (`source <(openclaw completion ...)`), засіб діагностики оновлює його до швидшого варіанта кешованого файлу. + - Якщо доповнення налаштовано в профілі, але файл кешу відсутній, засіб діагностики автоматично регенерує кеш. + - Якщо доповнення взагалі не налаштовано, засіб діагностики пропонує встановити його (лише в інтерактивному режимі; пропускається з `--non-interactive`). - Запустіть `openclaw completion --write-state`, щоб регенерувати кеш вручну. + Запустіть `openclaw completion --write-state`, щоб вручну регенерувати кеш. - Засіб діагностики перевіряє готовність автентифікації локального токена Gateway. + Засіб діагностики перевіряє готовність локальної токен-автентифікації gateway. - - Якщо режим токена потребує токен, а джерела токена немає, засіб діагностики пропонує згенерувати його. - - Якщо `gateway.auth.token` керується SecretRef, але недоступний, засіб діагностики попереджає й не перезаписує його відкритим текстом. - - `openclaw doctor --generate-gateway-token` примусово генерує токен лише тоді, коли не налаштовано SecretRef для токена. + - Якщо режим токена потребує токена, а джерела токена немає, засіб діагностики пропонує згенерувати його. + - Якщо `gateway.auth.token` керується SecretRef, але недоступний, засіб діагностики попереджає та не перезаписує його відкритим текстом. + - `openclaw doctor --generate-gateway-token` примусово генерує токен лише тоді, коли не налаштовано SecretRef токена. - - Деякі потоки відновлення мають перевіряти налаштовані облікові дані, не послаблюючи fail-fast поведінку runtime. + + Деякі потоки виправлення мають перевіряти налаштовані облікові дані без послаблення поведінки швидкого збою під час виконання. - - `openclaw doctor --fix` тепер використовує ту саму модель зведення SecretRef лише для читання, що й команди родини status, для цільових відновлень конфігурації. - - Приклад: відновлення Telegram `allowFrom` / `groupAllowFrom` `@username` намагається використати налаштовані облікові дані бота, коли вони доступні. - - Якщо токен бота Telegram налаштовано через SecretRef, але він недоступний у поточному шляху команди, засіб діагностики повідомляє, що облікові дані налаштовані, але недоступні, і пропускає автоматичне розв’язання замість збою або хибного повідомлення, що токен відсутній. + - `openclaw doctor --fix` тепер використовує ту саму модель підсумку SecretRef лише для читання, що й команди сімейства status, для цільових виправлень конфігурації. + - Приклад: виправлення Telegram `allowFrom` / `groupAllowFrom` `@username` намагається використовувати налаштовані облікові дані бота, коли вони доступні. + - Якщо токен бота Telegram налаштовано через SecretRef, але він недоступний у поточному шляху команди, засіб діагностики повідомляє, що облікові дані налаштовані, але недоступні, і пропускає автоматичне розв'язання замість аварійного завершення або помилкового повідомлення, що токен відсутній. - - Діагностичний засіб виконує перевірку працездатності й пропонує перезапустити gateway, коли він виглядає непрацездатним. + + Doctor виконує перевірку справності та пропонує перезапустити Gateway, коли він виглядає несправним. - - Діагностичний засіб перевіряє, чи налаштований постачальник embedding для пошуку в пам’яті готовий для стандартного агента. Поведінка залежить від налаштованого backend і постачальника: + + Doctor перевіряє, чи налаштований постачальник ембедингів для пошуку пам’яті готовий для типового агента. Поведінка залежить від налаштованого бекенда та постачальника: - - **Backend QMD**: перевіряє, чи доступний і придатний до запуску бінарний файл `qmd`. Якщо ні, друкує вказівки з виправлення, зокрема npm-пакет і варіант ручного шляху до бінарного файла. - - **Явний локальний постачальник**: перевіряє наявність локального файла моделі або розпізнаного URL віддаленої/завантажуваної моделі. Якщо його немає, пропонує перейти на віддаленого постачальника. - - **Явний віддалений постачальник** (`openai`, `voyage` тощо): перевіряє, чи є API-ключ у середовищі або сховищі автентифікації. Друкує дієві підказки для виправлення, якщо ключ відсутній. - - **Автоматичний постачальник**: спочатку перевіряє доступність локальної моделі, а потім пробує кожного віддаленого постачальника в порядку автоматичного вибору. + - **Бекенд QMD**: перевіряє, чи доступний і придатний до запуску бінарний файл `qmd`. Якщо ні, виводить інструкції для виправлення, зокрема npm-пакет і варіант ручного шляху до бінарного файла. + - **Явний локальний постачальник**: перевіряє наявність локального файла моделі або розпізнаної віддаленої/завантажуваної URL-адреси моделі. Якщо її немає, пропонує перейти на віддаленого постачальника. + - **Явний віддалений постачальник** (`openai`, `voyage` тощо): перевіряє, чи є API-ключ у середовищі або сховищі автентифікації. Якщо його немає, виводить практичні підказки для виправлення. + - **Автоматичний постачальник**: спершу перевіряє доступність локальної моделі, а потім пробує кожного віддаленого постачальника в порядку автоматичного вибору. - Коли доступний кешований результат перевірки Gateway (gateway був працездатним під час перевірки), діагностичний засіб зіставляє його результат із видимою для CLI конфігурацією та зазначає будь-яку розбіжність. Діагностичний засіб не запускає новий embedding ping у стандартному шляху; використовуйте команду поглибленого статусу пам’яті, коли потрібна інтерактивна перевірка постачальника. + Коли доступний кешований результат зондування Gateway (Gateway був справним на момент перевірки), doctor зіставляє його результат із конфігурацією, видимою для CLI, і зазначає будь-яку розбіжність. Doctor не запускає новий ping ембедингів у типовому шляху; використовуйте команду глибокого стану пам’яті, коли потрібна жива перевірка постачальника. - Використовуйте `openclaw memory status --deep`, щоб перевірити готовність embedding під час виконання. + Використовуйте `openclaw memory status --deep`, щоб перевірити готовність ембедингів під час виконання. - - Якщо Gateway працездатний, діагностичний засіб виконує перевірку статусу каналу та повідомляє попередження із запропонованими виправленнями. + + Якщо Gateway справний, doctor виконує зондування стану каналу та повідомляє попередження із запропонованими виправленнями. - - Діагностичний засіб перевіряє встановлену конфігурацію supervisor (launchd/systemd/schtasks) на відсутні або застарілі типові значення (наприклад, залежності systemd від network-online і затримку перезапуску). Коли він знаходить невідповідність, рекомендує оновлення й може переписати файл служби/завдання до поточних типових значень. + + Doctor перевіряє встановлену конфігурацію супервізора (launchd/systemd/schtasks) на відсутні або застарілі типові параметри (наприклад, залежності systemd від network-online і затримку перезапуску). Коли він знаходить невідповідність, рекомендує оновлення та може переписати файл служби/завдання до поточних типових значень. Примітки: - - `openclaw doctor` запитує підтвердження перед переписуванням конфігурації supervisor. - - `openclaw doctor --yes` приймає стандартні запити на відновлення. + - `openclaw doctor` запитує підтвердження перед переписуванням конфігурації супервізора. + - `openclaw doctor --yes` приймає типові запити на відновлення. - `openclaw doctor --repair` застосовує рекомендовані виправлення без запитів. - - `openclaw doctor --repair --force` перезаписує користувацькі конфігурації supervisor. - - `OPENCLAW_SERVICE_REPAIR_POLICY=external` залишає діагностичний засіб у режимі лише читання для життєвого циклу служби Gateway. Він усе ще повідомляє про стан служби та виконує відновлення, не пов’язані зі службою, але пропускає встановлення/запуск/перезапуск/bootstrap служби, переписування конфігурації supervisor і очищення застарілих служб, оскільки цим життєвим циклом керує зовнішній supervisor. - - У Linux діагностичний засіб не переписує метадані команди/entrypoint, поки відповідний systemd unit Gateway активний. Він також ігнорує неактивні додаткові gateway-подібні units, які не є застарілими, під час сканування дубльованих служб, щоб супутні файли служб не створювали шуму очищення. - - Якщо token auth вимагає token і `gateway.auth.token` керується SecretRef, встановлення/відновлення служби діагностичним засобом перевіряє SecretRef, але не зберігає розв’язані значення plaintext token у метаданих середовища служби supervisor. - - Діагностичний засіб виявляє керовані значення середовища служби на основі `.env`/SecretRef, які старіші встановлення LaunchAgent, systemd або Windows Scheduled Task вбудовували inline, і переписує метадані служби так, щоб ці значення завантажувалися з runtime-джерела замість визначення supervisor. - - Діагностичний засіб виявляє, коли команда служби все ще фіксує старий `--port` після зміни `gateway.port`, і переписує метадані служби на поточний порт. - - Якщо token auth вимагає token, а налаштований SecretRef token не розв’язується, діагностичний засіб блокує шлях встановлення/відновлення з дієвими вказівками. - - Якщо налаштовано і `gateway.auth.token`, і `gateway.auth.password`, а `gateway.auth.mode` не задано, діагностичний засіб блокує встановлення/відновлення, доки mode не буде задано явно. - - Для Linux user-systemd units перевірки розбіжності token у діагностичному засобі тепер включають джерела як `Environment=`, так і `EnvironmentFile=` під час порівняння метаданих автентифікації служби. - - Відновлення служби діагностичним засобом відмовляються переписувати, зупиняти або перезапускати службу Gateway зі старішого бінарного файла OpenClaw, коли конфігурацію востаннє записала новіша версія. Див. [Усунення несправностей Gateway](/uk/gateway/troubleshooting#split-brain-installs-and-newer-config-guard). + - `openclaw doctor --repair --force` перезаписує власні конфігурації супервізора. + - `OPENCLAW_SERVICE_REPAIR_POLICY=external` залишає doctor у режимі лише читання для життєвого циклу служби Gateway. Він усе одно повідомляє про справність служби та виконує відновлення, не пов’язані зі службою, але пропускає встановлення/запуск/перезапуск/bootstrap служби, переписування конфігурації супервізора та очищення застарілих служб, оскільки цим життєвим циклом керує зовнішній супервізор. + - У Linux doctor не переписує метадані команди/точки входу, доки відповідний systemd unit Gateway активний. Він також ігнорує неактивні додаткові unit-и, схожі на Gateway, які не є застарілими, під час сканування дубльованих служб, щоб супровідні файли служб не створювали зайвий шум очищення. + - Якщо автентифікація токеном вимагає токен і `gateway.auth.token` керується SecretRef, встановлення/відновлення служби doctor перевіряє SecretRef, але не зберігає розв’язані значення токена у відкритому тексті в метадані середовища служби супервізора. + - Doctor виявляє керовані значення середовища служби на основі `.env`/SecretRef, які старіші встановлення LaunchAgent, systemd або Windows Scheduled Task вбудовували inline, і переписує метадані служби так, щоб ці значення завантажувалися з джерела виконання, а не з визначення супервізора. + - Doctor виявляє, коли команда служби все ще закріплює старий `--port` після зміни `gateway.port`, і переписує метадані служби на поточний порт. + - Якщо автентифікація токеном вимагає токен, а налаштований SecretRef токена не розв’язується, doctor блокує шлях встановлення/відновлення з практичними інструкціями. + - Якщо налаштовано і `gateway.auth.token`, і `gateway.auth.password`, а `gateway.auth.mode` не задано, doctor блокує встановлення/відновлення, доки режим не буде задано явно. + - Для Linux user-systemd unit-ів перевірки дрейфу токена doctor тепер охоплюють джерела і `Environment=`, і `EnvironmentFile=` під час порівняння метаданих автентифікації служби. + - Відновлення служби doctor відмовляються переписувати, зупиняти або перезапускати службу Gateway зі старішого бінарного файла OpenClaw, коли конфігурацію востаннє записала новіша версія. Див. [усунення несправностей Gateway](/uk/gateway/troubleshooting#split-brain-installs-and-newer-config-guard). - Ви завжди можете примусово виконати повне переписування через `openclaw gateway install --force`. - - Діагностичний засіб перевіряє runtime служби (PID, останній exit status) і попереджає, коли службу встановлено, але вона фактично не працює. Він також перевіряє конфлікти портів на порту Gateway (типово `18789`) і повідомляє ймовірні причини (Gateway уже працює, SSH-тунель). + + Doctor перевіряє середовище виконання служби (PID, останній статус виходу) і попереджає, коли служба встановлена, але фактично не працює. Він також перевіряє конфлікти портів на порту Gateway (типово `18789`) і повідомляє ймовірні причини (Gateway уже запущено, SSH-тунель). - - Діагностичний засіб попереджає, коли служба Gateway працює на Bun або шляху Node, керованому менеджером версій (`nvm`, `fnm`, `volta`, `asdf` тощо). Канали WhatsApp + Telegram потребують Node, а шляхи менеджера версій можуть ламатися після оновлень, бо служба не завантажує вашу shell init. Діагностичний засіб пропонує перейти на системне встановлення Node, коли воно доступне (Homebrew/apt/choco). + + Doctor попереджає, коли служба Gateway працює на Bun або шляху Node, керованому менеджером версій (`nvm`, `fnm`, `volta`, `asdf` тощо). Канали WhatsApp + Telegram потребують Node, а шляхи менеджера версій можуть ламатися після оновлень, бо служба не завантажує ініціалізацію вашої оболонки. Doctor пропонує перейти на системне встановлення Node, коли воно доступне (Homebrew/apt/choco). - Нововстановлені або відновлені macOS LaunchAgents використовують канонічний системний PATH (`/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin`) замість копіювання інтерактивного shell PATH, тому Volta, asdf, fnm, pnpm та інші каталоги менеджерів версій не змінюють, який Node розв’язують дочірні процеси. Служби Linux усе ще зберігають явні корені середовища (`NVM_DIR`, `FNM_DIR`, `VOLTA_HOME`, `ASDF_DATA_DIR`, `BUN_INSTALL`, `PNPM_HOME`) і стабільні каталоги user-bin, але вгадані fallback-каталоги менеджерів версій записуються до PATH служби лише тоді, коли ці каталоги існують на диску. + Нововстановлені або відновлені macOS LaunchAgents використовують канонічний системний PATH (`/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin`) замість копіювання PATH інтерактивної оболонки, тому Volta, asdf, fnm, pnpm та інші каталоги менеджерів версій не змінюють, який Node розв’язують дочірні процеси. Служби Linux і далі зберігають явні корені середовища (`NVM_DIR`, `FNM_DIR`, `VOLTA_HOME`, `ASDF_DATA_DIR`, `BUN_INSTALL`, `PNPM_HOME`) і стабільні каталоги user-bin, але вгадані резервні каталоги менеджерів версій записуються до PATH служби лише тоді, коли ці каталоги існують на диску. - Діагностичний засіб зберігає всі зміни конфігурації та позначає метадані майстра, щоб зафіксувати запуск діагностики. + Doctor зберігає будь-які зміни конфігурації та ставить мітку метаданих майстра, щоб зафіксувати запуск doctor. - - Діагностичний засіб пропонує систему пам’яті робочого простору, коли її немає, і друкує пораду щодо резервного копіювання, якщо робочий простір ще не перебуває під git. + + Doctor пропонує систему пам’яті робочої області, коли її немає, і виводить пораду щодо резервної копії, якщо робоча область ще не перебуває під git. - Див. [/concepts/agent-workspace](/uk/concepts/agent-workspace), щоб отримати повний посібник зі структури робочого простору та резервного копіювання git (рекомендовано приватний GitHub або GitLab). + Повний посібник зі структури робочої області та резервного копіювання git (рекомендовано приватний GitHub або GitLab) див. у [/concepts/agent-workspace](/uk/concepts/agent-workspace). diff --git a/docs/uk/help/testing-updates-plugins.md b/docs/uk/help/testing-updates-plugins.md index a5c901727..74dd4d1b1 100644 --- a/docs/uk/help/testing-updates-plugins.md +++ b/docs/uk/help/testing-updates-plugins.md @@ -1,34 +1,50 @@ --- read_when: - - Зміна поведінки оновлення OpenClaw, doctor, приймання пакетів або встановлення Plugin + - Зміна поведінки оновлення OpenClaw, doctor, приймання пакунків або встановлення Plugin - Підготовка або затвердження реліз-кандидата - Налагодження регресій оновлення пакета, очищення залежностей Plugin або встановлення Plugin sidebarTitle: Update and plugin tests summary: Як OpenClaw перевіряє шляхи оновлення, міграції пакетів і поведінку встановлення/оновлення Plugin title: 'Тестування: оновлення та Plugin' x-i18n: - generated_at: "2026-05-02T15:57:59Z" + generated_at: "2026-05-02T18:57:57Z" model: gpt-5.5 provider: openai - source_hash: 7843767a4acca25ceea62633faa5f4bec954bebf7cc4eeb9f3b0b990313ff946 + source_hash: 1a56e249f565cc23a439142b3332c0a57fd4afe9021b79f644d353946d6d2ffc source_path: help/testing-updates-plugins.md workflow: 16 --- -Це спеціальний контрольний список для перевірки оновлень і Plugin. Мета проста: довести, що інстальований пакет може оновлювати реальний стан користувача, відновлювати застарілий legacy-стан через `doctor` і надалі встановлювати, завантажувати, оновлювати та видаляти plugins з підтримуваних джерел. +Це спеціальний контрольний список для валідації оновлення та Plugin. Мета +проста: довести, що встановлюваний пакет може оновлювати реальний стан +користувача, відновлювати застарілий legacy-стан через `doctor` і все ще +встановлювати, завантажувати, оновлювати та видаляти Plugin-и з підтримуваних +джерел. -Для ширшої мапи засобу запуску тестів див. [Тестування](/uk/help/testing). Для live-ключів провайдерів і наборів, що торкаються мережі, див. [Live-тестування](/uk/help/testing-live). +Ширшу карту засобів запуску тестів див. у [Тестуванні](/uk/help/testing). Для live-ключів +провайдерів і наборів, що торкаються мережі, див. +[Live-тестування](/uk/help/testing-live). ## Що ми захищаємо -Тести оновлень і Plugin захищають такі контракти: +Тести оновлення та Plugin захищають такі контракти: -- Tarball пакета повний, має дійсний `dist/postinstall-inventory.json` і не залежить від розпакованих файлів репозиторію. -- Користувач може перейти зі старішого опублікованого пакета на кандидатний пакет без втрати конфігурації, агентів, сесій, робочих просторів, списків дозволених plugins або конфігурації каналів. -- `openclaw doctor --fix --non-interactive` відповідає за очищення legacy-стану та шляхи відновлення. Startup не має обростати прихованими міграціями сумісності для застарілого стану Plugin. -- Встановлення Plugin працює з локальних директорій, git-репозиторіїв, npm-пакетів і шляху реєстру ClawHub. -- npm-залежності Plugin встановлюються в керований npm-корінь, скануються перед довірою та видаляються через npm під час uninstall, щоб hoisted-залежності не залишалися. -- Оновлення Plugin стабільне, коли нічого не змінилося: записи встановлення, вирішене джерело, розкладка встановлених залежностей і ввімкнений стан залишаються незмінними. +- Tarball пакета є повним, має дійсний `dist/postinstall-inventory.json` + і не залежить від нерозпакованих файлів репозиторію. +- Користувач може перейти зі старішого опублікованого пакета на пакет-кандидат + без втрати конфігурації, агентів, сесій, робочих просторів, allowlist-ів Plugin + або конфігурації каналу. +- `openclaw doctor --fix --non-interactive` відповідає за очищення legacy-стану та + шляхи відновлення. Запуск не має обростати прихованими міграціями сумісності + для застарілого стану Plugin. +- Встановлення Plugin працює з локальних директорій, git-репозиторіїв, npm-пакетів + і шляху реєстру ClawHub. +- npm-залежності Plugin встановлюються в керований npm-корінь, скануються перед + довірою та видаляються через npm під час видалення, щоб hoisted-залежності + не залишалися. +- Оновлення Plugin є стабільним, коли нічого не змінилося: записи встановлення, + resolved-джерело, макет встановлених залежностей і ввімкнений стан залишаються + незмінними. ## Локальне підтвердження під час розробки @@ -40,25 +56,33 @@ pnpm check:changed pnpm test:changed ``` -Для змін у встановленні, видаленні, залежностях Plugin або package-inventory також запускайте сфокусовані тести, що покривають змінений seam: +Для змін у встановленні, видаленні, залежностях Plugin або інвентарі пакета також +запустіть сфокусовані тести, що покривають відредагований інтерфейс: ```bash pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts ``` -Перед тим як будь-яка package Docker lane споживатиме tarball, підтвердьте артефакт пакета: +Перед тим як будь-яка Docker-доріжка пакета споживатиме tarball, підтвердьте +артефакт пакета: ```bash pnpm release:check ``` -`release:check` запускає перевірки drift для config/docs/API, записує package dist inventory, виконує `npm pack --dry-run`, відхиляє заборонені запаковані файли, встановлює tarball у тимчасовий prefix, запускає postinstall і виконує smoke-перевірки entrypoints вбудованих каналів. +`release:check` запускає перевірки drift-у конфігурації/документації/API, записує +інвентар дистрибутива пакета, запускає `npm pack --dry-run`, відхиляє заборонені +запаковані файли, встановлює tarball у тимчасовий prefix, запускає postinstall і +smoke-перевіряє entrypoint-и bundled-каналів. -## Docker lanes +## Docker-доріжки -Docker lanes є підтвердженням продуктового рівня. Вони встановлюють або оновлюють реальний пакет усередині Linux-контейнерів і перевіряють поведінку через CLI-команди, запуск Gateway, HTTP-проби, RPC-статус і стан файлової системи. +Docker-доріжки є підтвердженням на рівні продукту. Вони встановлюють або +оновлюють реальний пакет усередині Linux-контейнерів і перевіряють поведінку +через CLI-команди, запуск Gateway, HTTP-проби, RPC-статус і стан файлової +системи. -Використовуйте сфокусовані lanes під час ітерацій: +Під час ітерацій використовуйте сфокусовані доріжки: ```bash pnpm test:docker:plugins @@ -68,13 +92,31 @@ pnpm test:docker:published-upgrade-survivor pnpm test:docker:update-migration ``` -Важливі lanes: +Важливі доріжки: -- `test:docker:plugins` перевіряє smoke встановлення Plugin, встановлення з локальної папки, поведінку пропуску оновлення локальної папки, локальні папки з попередньо встановленими залежностями, встановлення `file:` пакетів, git-встановлення з виконанням CLI, оновлення git moving-ref, встановлення з npm registry з hoisted transitive dependencies, npm update no-ops, встановлення з локальної ClawHub fixture та update no-ops, поведінку marketplace update і Claude-bundle enable/inspect. Установіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб блок ClawHub залишався hermetic/offline. -- `test:docker:plugin-update` перевіряє, що незмінений встановлений Plugin не перевстановлюється і не втрачає install metadata під час `openclaw plugins update`. -- `test:docker:upgrade-survivor` встановлює candidate tarball поверх dirty old-user fixture, запускає package update плюс non-interactive doctor, потім стартує loopback Gateway і перевіряє збереження стану. -- `test:docker:published-upgrade-survivor` спочатку встановлює published baseline, налаштовує його через вбудований рецепт `openclaw config set`, оновлює до candidate tarball, запускає doctor, перевіряє legacy cleanup, стартує Gateway і пробує `/healthz`, `/readyz` та RPC status. -- `test:docker:update-migration` є cleanup-heavy published-update lane. Він стартує з налаштованого user state у стилі Discord/Telegram, запускає baseline doctor, щоб налаштовані залежності Plugin мали шанс матеріалізуватися, seed-ить legacy plugin dependency debris для налаштованого packaged plugin, оновлює до candidate tarball і вимагає, щоб post-update doctor видалив legacy dependency roots. +- `test:docker:plugins` валідує smoke встановлення Plugin, встановлення локальних + папок, поведінку пропуску оновлення локальних папок, локальні папки з попередньо + встановленими залежностями, встановлення `file:` пакетів, git-встановлення з + виконанням CLI, оновлення git moving-ref, встановлення з npm-реєстру з hoisted + транзитивними залежностями, npm update no-op-и, встановлення локальних ClawHub + fixture-ів і update no-op-и, поведінку оновлення marketplace, а також увімкнення/ + inspect Claude-bundle. Установіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб блок + ClawHub залишався герметичним/offline. +- `test:docker:plugin-update` валідує, що незмінений встановлений Plugin не + перевстановлюється і не втрачає метадані встановлення під час `openclaw plugins update`. +- `test:docker:upgrade-survivor` встановлює tarball-кандидат поверх брудного + fixture-а старого користувача, запускає оновлення пакета плюс неінтерактивний + doctor, потім запускає loopback Gateway і перевіряє збереження стану. +- `test:docker:published-upgrade-survivor` спочатку встановлює опублікований baseline, + конфігурує його через вбудований рецепт `openclaw config set`, оновлює до + tarball-кандидата, запускає doctor, перевіряє legacy-очищення, запускає Gateway + і зондує `/healthz`, `/readyz` та RPC-статус. +- `test:docker:update-migration` є cleanup-heavy доріжкою опублікованого оновлення. + Вона стартує з налаштованого користувацького стану в стилі Discord/Telegram, + запускає baseline doctor, щоб налаштовані залежності Plugin отримали шанс + матеріалізуватися, додає legacy-сміття залежностей Plugin для налаштованого + packaged Plugin, оновлює до tarball-кандидата та вимагає, щоб post-update doctor + видалив legacy-корені залежностей. Корисні варіанти published-upgrade survivor: @@ -88,9 +130,16 @@ OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=bootstrap-persona \ pnpm test:docker:published-upgrade-survivor ``` -Доступні сценарії: `base`, `feishu-channel`, `bootstrap-persona`, `plugin-deps-cleanup`, `configured-plugin-installs`, `tilde-log-path` і `versioned-runtime-deps`. В aggregate runs `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues` розгортається в усі reported issue-shaped сценарії, включно з configured-plugin install migration. +Доступні сценарії: `base`, `feishu-channel`, `bootstrap-persona`, +`plugin-deps-cleanup`, `configured-plugin-installs`, `tilde-log-path` і +`versioned-runtime-deps`. В aggregate-запусках +`OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues` розгортається в усі +сценарії форми reported issue, включно з міграцією встановлення configured-plugin. -Повна update migration навмисно відокремлена від Full Release CI. Використовуйте ручний workflow `Update Migration`, коли release question: «чи може кожен опублікований stable release від 2026.4.23 і далі оновитися до цього кандидата та очистити plugin dependency debris?»: +Повна міграція оновлень навмисно відокремлена від Full Release CI. Використовуйте +ручний workflow `Update Migration`, коли release-питання таке: «чи може кожен +опублікований stable-реліз від 2026.4.23 і далі оновитися до цього кандидата та +прибрати сміття залежностей Plugin?»: ```bash gh workflow run update-migration.yml \ @@ -101,18 +150,30 @@ gh workflow run update-migration.yml \ -f scenarios=plugin-deps-cleanup ``` -## Package Acceptance +## Приймання пакета -Package Acceptance — це GitHub-native package gate. Він resolve-ить один candidate package у tarball `package-under-test`, записує version і SHA-256, а потім запускає reusable Docker E2E lanes проти саме цього tarball. Workflow harness ref відокремлений від package source ref, тому поточна test logic може перевіряти старіші trusted releases. +Package Acceptance є GitHub-native gate-ом пакета. Він resolves один пакет-кандидат +у tarball `package-under-test`, записує версію та SHA-256, а потім запускає +reusable Docker E2E-доріжки проти саме цього tarball. Ref workflow harness є +окремим від ref джерела пакета, тому поточна тестова логіка може валідувати +старіші довірені релізи. -Джерела candidate: +Джерела кандидатів: -- `source=npm`: перевіряє `openclaw@beta`, `openclaw@latest` або точну опубліковану версію. -- `source=ref`: пакує trusted branch, tag або commit з вибраним current harness. -- `source=url`: перевіряє HTTPS tarball з обов’язковим `package_sha256`. -- `source=artifact`: повторно використовує tarball, завантажений іншим Actions run. +- `source=npm`: валідуйте `openclaw@beta`, `openclaw@latest` або точну + опубліковану версію. +- `source=ref`: пакуйте довірену гілку, тег або commit із вибраним поточним + harness. +- `source=url`: валідуйте HTTPS tarball з обов’язковим `package_sha256`. +- `source=artifact`: повторно використовуйте tarball, завантажений іншим + Actions-запуском. -Release checks викликають Package Acceptance з набором package/update/plugin: +Full Release Validation за замовчуванням використовує `source=artifact`, зібраний +із resolved release SHA. Для post-publish підтвердження передайте +`package_acceptance_package_spec=openclaw@YYYY.M.D`, щоб та сама upgrade-матриця +цілилася в shipped npm-пакет. + +Release checks викликають Package Acceptance з package/update/plugin набором: ```text doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update @@ -121,16 +182,23 @@ doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor Вони також передають: ```text -published_upgrade_survivor_baselines=release-history +published_upgrade_survivor_baselines=all-since-2026.4.23 published_upgrade_survivor_scenarios=reported-issues telegram_mode=mock-openai ``` -Це тримає package migration, update channel switching, stale plugin dependency cleanup, offline plugin coverage, поведінку plugin update і Telegram package QA на одному resolved artifact. +Це тримає міграцію пакета, перемикання update channel, очищення застарілих +залежностей Plugin, offline-покриття Plugin, поведінку оновлення Plugin і +Telegram package QA на одному resolved-артефакті. -`release-history` — це bounded release-check sample: останні шість stable releases, `2026.4.23` і один старіший pre-date anchor. Для exhaustive published update migration coverage використовуйте `all-since-2026.4.23` в окремому workflow Update Migration замість Full Release CI. +`all-since-2026.4.23` є upgrade-вибіркою Full Release CI: кожен stable +npm-published реліз від `2026.4.23` до `latest`. Для вичерпного покриття +міграції опублікованих оновлень використовуйте `all-since-2026.4.23` в окремому +workflow Update Migration замість Full Release CI. `release-history` залишається +доступним для ширшого ручного sampling, коли вам також потрібен legacy pre-date +anchor. -Запускайте package profile вручну під час перевірки кандидата перед release: +Запустіть package profile вручну під час валідації кандидата перед релізом: ```bash gh workflow run package-acceptance.yml \ @@ -139,54 +207,78 @@ gh workflow run package-acceptance.yml \ -f source=npm \ -f package_spec=openclaw@beta \ -f suite_profile=package \ - -f published_upgrade_survivor_baselines=release-history \ + -f published_upgrade_survivor_baselines=all-since-2026.4.23 \ -f published_upgrade_survivor_scenarios=reported-issues \ -f telegram_mode=mock-openai ``` -Використовуйте `suite_profile=product`, коли release question включає MCP channels, cron/subagent cleanup, OpenAI web search або OpenWebUI. Використовуйте `suite_profile=full` лише тоді, коли потрібне повне покриття Docker release-path. +Використовуйте `suite_profile=product`, коли release-питання охоплює MCP-канали, +cron/subagent cleanup, OpenAI web search або OpenWebUI. Використовуйте +`suite_profile=full` лише тоді, коли потрібне повне Docker-покриття release-path. -## Типове для release +## Типове підтвердження для релізу -Для release candidates типовий stack підтвердження такий: +Для release candidates типовий стек підтвердження такий: -1. `pnpm check:changed` і `pnpm test:changed` для source-level regressions. -2. `pnpm release:check` для integrity артефакта пакета. -3. Package Acceptance `package` profile або release-check custom package lanes для контрактів install/update/plugin. -4. Cross-OS release checks для OS-specific installer, onboarding і platform behavior. -5. Live suites лише тоді, коли змінена поверхня торкається provider або hosted-service behavior. +1. `pnpm check:changed` і `pnpm test:changed` для source-level регресій. +2. `pnpm release:check` для цілісності артефакта пакета. +3. Package Acceptance `package` profile або release-check custom package + lanes для контрактів install/update/plugin. +4. Cross-OS release checks для OS-specific installer, onboarding і platform + поведінки. +5. Live-набори лише тоді, коли змінена поверхня торкається поведінки провайдера + або hosted-service. -На maintainer machines broad gates і Docker/package product proof мають запускатися в Testbox, якщо явно не виконується local proof. +На maintainer-машинах broad gates і Docker/package product proof мають запускатися +в Testbox, якщо явно не виконується локальне підтвердження. ## Legacy-сумісність -Compatibility leniency є вузькою та обмеженою в часі: +Поблажливість сумісності є вузькою та обмеженою в часі: -- Пакети до `2026.4.25`, включно з `2026.4.25-beta.*`, можуть tolerate already-shipped package metadata gaps у Package Acceptance. -- Опублікований пакет `2026.4.26` може warning для local build metadata stamp files, які вже shipped. -- Пізніші пакети мають задовольняти сучасні контракти. Ті самі gaps fail замість warning або skipping. +- Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть толерувати + вже shipped прогалини метаданих пакета в Package Acceptance. +- Опублікований пакет `2026.4.26` може попереджати про вже shipped stamp-файли + метаданих локальної збірки. +- Пізніші пакети мають відповідати сучасним контрактам. Ті самі прогалини + провалюються замість warning або skipping. -Не додавайте нові startup migrations для цих старих shapes. Додайте або розширте doctor repair, потім підтвердьте це за допомогою `upgrade-survivor` або `published-upgrade-survivor`. +Не додавайте нові startup-міграції для цих старих форм. Додайте або розширте +doctor-відновлення, потім підтвердьте його через `upgrade-survivor` або +`published-upgrade-survivor`. ## Додавання покриття -Коли змінюєте поведінку update або Plugin, додавайте coverage на найнижчому шарі, який може fail з правильної причини: +Коли змінюєте поведінку оновлення або Plugin, додавайте покриття на найнижчому +рівні, який може впасти з правильної причини: -- Pure path або metadata logic: unit test поруч із source. -- Package inventory або packed-file behavior: `package-dist-inventory` або tarball checker test. -- CLI install/update behavior: Docker lane assertion або fixture. -- Published-release migration behavior: сценарій `published-upgrade-survivor`. -- Registry/package source behavior: fixture `test:docker:plugins` або fixture server ClawHub. -- Dependency layout або cleanup behavior: перевіряйте і runtime execution, і filesystem boundary. npm-залежності можуть бути hoisted під managed npm root, тому тести мають доводити, що root сканується/очищається, замість припущення про package-local дерево `node_modules`. +- Чиста логіка шляхів або метаданих: unit-тест поруч із джерелом. +- Поведінка інвентарю пакета або packed-file: `package-dist-inventory` або тест + tarball checker. +- Поведінка CLI install/update: твердження або fixture Docker-доріжки. +- Поведінка міграції published-release: сценарій `published-upgrade-survivor`. +- Поведінка джерела registry/package: fixture `test:docker:plugins` або fixture + сервер ClawHub. +- Поведінка макета залежностей або очищення: перевіряйте і runtime execution, і + межу файлової системи. npm-залежності можуть бути hoisted під керованим + npm-коренем, тому тести мають доводити, що корінь сканується/очищається, а не + припускати package-local дерево `node_modules`. -Тримайте нові Docker fixtures hermetic за замовчуванням. Використовуйте local fixture registries і fake packages, якщо мета тесту не live registry behavior. +Нові Docker fixture-и за замовчуванням мають бути герметичними. Використовуйте +локальні fixture-реєстри та фейкові пакети, якщо метою тесту не є live-поведінка +реєстру. -## Failure triage +## Тріаж збоїв -Почніть з artifact identity: +Починайте з ідентичності артефакта: -- Summary Package Acceptance `resolve_package`: source, version, SHA-256 і artifact name. -- Docker artifacts: `.artifacts/docker-tests/**/summary.json`, `failures.json`, lane logs і rerun commands. -- Upgrade survivor summary: `.artifacts/upgrade-survivor/summary.json`, включно з baseline version, candidate version, scenario, phase timings і recipe steps. +- Summary Package Acceptance `resolve_package`: source, version, SHA-256 і назва + artifact. +- Docker artifacts: `.artifacts/docker-tests/**/summary.json`, + `failures.json`, lane logs і rerun commands. +- Summary upgrade survivor: `.artifacts/upgrade-survivor/summary.json`, + включно з baseline version, candidate version, scenario, phase timings і + recipe steps. -Надавайте перевагу rerun failed exact lane з тим самим package artifact, а не rerun усього release umbrella. +Віддавайте перевагу повторному запуску exact failed lane з тим самим package +artifact, а не повторному запуску всієї release umbrella. diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md index 4931388ab..85e7f44ab 100644 --- a/docs/uk/help/testing.md +++ b/docs/uk/help/testing.md @@ -1,217 +1,217 @@ --- read_when: - Запуск тестів локально або в CI - - Додавання регресійних тестів для помилок моделі/провайдера + - Додавання регресійних тестів для помилок моделей/провайдерів - Налагодження поведінки Gateway + агента -summary: 'Набір для тестування: модульні/e2e/live-набори, Docker-ранери та що охоплює кожен тест' +summary: 'Набір для тестування: модульні/e2e/живі набори, ранери Docker і що покриває кожен тест' title: Тестування x-i18n: - generated_at: "2026-05-02T16:50:30Z" + generated_at: "2026-05-02T18:57:55Z" model: gpt-5.5 provider: openai - source_hash: 99e7db2ab0069aaa129bed303419b76bb9276f3f53a4ac6bb292120c3a327b7b + source_hash: 723d4769d13a83482bd4afcd1878579ba2b245c8e49cefc2794e865da1ab7dc7 source_path: help/testing.md workflow: 16 --- -OpenClaw має три набори тестів Vitest (unit/integration, e2e, live) і невеликий набір -Docker runner. Цей документ є посібником «як ми тестуємо»: +OpenClaw має три набори Vitest (модульні/інтеграційні, e2e, live) і невеликий набір +Docker-запускачів. Цей документ — посібник «як ми тестуємо»: -- Що покриває кожен набір (і що він свідомо _не_ покриває). -- Які команди запускати для типових робочих процесів (локально, перед push, для налагодження). +- Що покриває кожен набір (і що він навмисно _не_ покриває). +- Які команди запускати для типових робочих процесів (локально, перед push, налагодження). - Як live-тести знаходять облікові дані та вибирають моделі/провайдерів. -- Як додавати регресійні тести для реальних проблем із моделями/провайдерами. +- Як додавати регресії для реальних проблем із моделями/провайдерами. -**QA-стек (qa-lab, qa-channel, live transport lanes)** задокументовано окремо: +**QA-стек (qa-lab, qa-channel, live транспортні лінії)** задокументовано окремо: - [Огляд QA](/uk/concepts/qa-e2e-automation) — архітектура, поверхня команд, створення сценаріїв. -- [Matrix QA](/uk/concepts/qa-matrix) — довідка для `pnpm openclaw qa matrix`. -- [QA channel](/uk/channels/qa-channel) — синтетичний transport plugin, який використовується сценаріями, підтриманими репозиторієм. +- [Matrix QA](/uk/concepts/qa-matrix) — довідник для `pnpm openclaw qa matrix`. +- [QA-канал](/uk/channels/qa-channel) — синтетичний транспортний plugin, який використовується сценаріями на основі репозиторію. -Ця сторінка описує запуск звичайних наборів тестів і Docker/Parallels runner. Розділ про спеціальні QA runner нижче ([QA-specific runners](#qa-specific-runners)) перелічує конкретні виклики `qa` і повертає до наведених вище довідкових матеріалів. +Ця сторінка описує запуск звичайних тестових наборів і Docker/Parallels-запускачів. Розділ про специфічні для QA запускачі нижче ([Специфічні для QA запускачі](#qa-specific-runners)) перелічує конкретні виклики `qa` і повертає до наведених вище довідників. ## Швидкий старт -У більшість днів: +У більшості випадків: - Повний gate (очікується перед push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` -- Швидший локальний запуск повного набору на машині з достатніми ресурсами: `pnpm test:max` -- Прямий watch-цикл Vitest: `pnpm test:watch` -- Пряме таргетування файлів тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Спершу віддавайте перевагу таргетованим запускам, коли ітеруєте над одним збоєм. +- Швидший локальний запуск повного набору на потужній машині: `pnpm test:max` +- Прямий цикл спостереження Vitest: `pnpm test:watch` +- Пряме націлення на файл тепер також маршрутизує шляхи extension/каналу: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Спершу віддавайте перевагу цільовим запускам, коли ітеруєте над одним збоєм. - QA-сайт на базі Docker: `pnpm qa:lab:up` -- QA lane на базі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- QA-лінія на базі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` Коли ви змінюєте тести або хочете додаткової впевненості: -- Coverage gate: `pnpm test:coverage` +- Gate покриття: `pnpm test:coverage` - Набір E2E: `pnpm test:e2e` Під час налагодження реальних провайдерів/моделей (потрібні реальні облікові дані): -- Live-набір (моделі + Gateway tool/image probes): `pnpm test:live` +- Live-набір (моделі + перевірки Gateway tool/image): `pnpm test:live` - Тихо націлити один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -- Звіти про продуктивність runtime: dispatch `OpenClaw Performance` з +- Звіти продуктивності runtime: dispatch `OpenClaw Performance` з `live_gpt54=true` для реального ходу агента `openai/gpt-5.4` або - `deep_profile=true` для CPU/heap/trace артефактів Kova. Щоденні заплановані запуски - публікують артефакти mock-provider, deep-profile і GPT 5.4 lane до - `openclaw/clawgrit-reports`, коли налаштовано `CLAWGRIT_REPORTS_TOKEN`. - Звіт mock-provider також містить source-level показники запуску Gateway, пам’яті, - plugin-pressure, повторюваного fake-model hello-loop і старту CLI. -- Docker live model sweep: `pnpm test:docker:live-models` - - Кожна вибрана модель тепер виконує текстовий хід плюс невелику file-read-style probe. - Моделі, чиї метадані оголошують вхід `image`, також виконують крихітний image-хід. - Вимкніть додаткові probe за допомогою `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або + `deep_profile=true` для артефактів CPU/heap/trace Kova. Щоденні заплановані запуски + публікують артефакти ліній mock-provider, deep-profile і GPT 5.4 до + `openclaw/clawgrit-reports`, коли налаштовано `CLAWGRIT_REPORTS_TOKEN`. Звіт + mock-provider також містить показники завантаження Gateway на рівні джерел, пам’яті, + plugin-pressure, повторюваного hello-loop фейкової моделі та запуску CLI. +- Docker live sweep моделей: `pnpm test:docker:live-models` + - Кожна вибрана модель тепер виконує текстовий хід і невелику перевірку в стилі читання файлу. + Моделі, метадані яких оголошують вхід `image`, також виконують крихітний хід із зображенням. + Вимикайте додаткові перевірки через `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0`, коли ізолюєте збої провайдера. - - Покриття CI: щоденні `OpenClaw Scheduled Live And E2E Checks` і ручні - `OpenClaw Release Checks` обидва викликають reusable live/E2E workflow з - `include_live_suites: true`, що включає окремі Docker live model - matrix jobs, розбиті за провайдерами. - - Для сфокусованих CI rerun виконайте dispatch `OpenClaw Live And E2E Checks (Reusable)` + - Покриття CI: щоденний `OpenClaw Scheduled Live And E2E Checks` і ручний + `OpenClaw Release Checks` обидва викликають багаторазовий live/E2E workflow з + `include_live_suites: true`, що включає окремі Docker live matrix-завдання моделей, + розбиті за провайдером. + - Для сфокусованих повторних запусків CI dispatch `OpenClaw Live And E2E Checks (Reusable)` з `include_live_suites: true` і `live_models_only: true`. - - Додайте нові high-signal секрети провайдера до `scripts/ci-hydrate-live-auth.sh` + - Додавайте нові високосигнальні секрети провайдера до `scripts/ci-hydrate-live-auth.sh` плюс `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` та його - scheduled/release caller. -- Native Codex bound-chat smoke: `pnpm test:docker:live-codex-bind` - - Запускає Docker live lane проти шляху Codex app-server, прив’язує синтетичний - Slack DM через `/codex bind`, виконує `/codex fast` і - `/codex permissions`, а потім перевіряє, що звичайна відповідь і вкладення зображення - проходять через native plugin binding замість ACP. -- Codex app-server harness smoke: `pnpm test:docker:live-codex-harness` - - Запускає ходи агента Gateway через plugin-owned Codex app-server harness, - перевіряє `/codex status` і `/codex models` та за замовчуванням виконує image, - cron MCP, sub-agent і Guardian probe. Вимкніть sub-agent probe за допомогою - `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0`, коли ізолюєте інші збої Codex - app-server. Для сфокусованої перевірки sub-agent вимкніть інші probe: + заплановані/release викликачі. +- Нативний smoke Codex bound-chat: `pnpm test:docker:live-codex-bind` + - Запускає Docker live-лінію проти шляху app-server Codex, прив’язує синтетичний + Slack DM через `/codex bind`, перевіряє `/codex fast` і + `/codex permissions`, а потім верифікує звичайну відповідь і маршрут вкладення зображення + через нативне прив’язування plugin замість ACP. +- Smoke harness app-server Codex: `pnpm test:docker:live-codex-harness` + - Запускає ходи Gateway-агента через належний plugin harness app-server Codex, + перевіряє `/codex status` і `/codex models` та за замовчуванням виконує перевірки image, + Cron MCP, sub-agent і Guardian. Вимикайте перевірку sub-agent через + `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0`, коли ізолюєте інші збої app-server Codex. + Для сфокусованої перевірки sub-agent вимкніть інші перевірки: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness`. - Це завершується після sub-agent probe, якщо не встановлено + Це завершується після перевірки sub-agent, якщо не встановлено `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0`. -- Crestodian rescue command smoke: `pnpm test:live:crestodian-rescue-channel` - - Додаткова belt-and-suspenders перевірка поверхні rescue-команди message-channel. +- Smoke rescue-команди Crestodian: `pnpm test:live:crestodian-rescue-channel` + - Додаткова перевірка «про всяк випадок» для поверхні rescue-команди каналу повідомлень. Вона виконує `/crestodian status`, ставить у чергу постійну зміну моделі, відповідає `/crestodian yes` і перевіряє шлях запису audit/config. -- Crestodian planner Docker smoke: `pnpm test:docker:crestodian-planner` - - Запускає Crestodian у контейнері без config з фейковим Claude CLI у `PATH` - і перевіряє, що fuzzy planner fallback транслюється в audited typed - config write. -- Crestodian first-run Docker smoke: `pnpm test:docker:crestodian-first-run` - - Починає з порожнього OpenClaw state dir, маршрутизує bare `openclaw` до - Crestodian, застосовує setup/model/agent/Discord plugin + SecretRef записи, - валідує config і перевіряє audit entries. Той самий шлях Ring 0 setup - також покрито в QA Lab через +- Docker smoke планувальника Crestodian: `pnpm test:docker:crestodian-planner` + - Запускає Crestodian у контейнері без конфігурації з фейковим Claude CLI у `PATH` + і перевіряє, що нечіткий fallback планувальника перетворюється на аудитований типізований + запис конфігурації. +- Docker smoke першого запуску Crestodian: `pnpm test:docker:crestodian-first-run` + - Починає з порожнього каталогу стану OpenClaw, маршрутизує bare `openclaw` до + Crestodian, застосовує записи setup/model/agent/Discord plugin + SecretRef, + валідує конфігурацію та перевіряє записи аудиту. Той самий шлях налаштування Ring 0 + також покривається в QA Lab через `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`. -- Moonshot/Kimi cost smoke: з установленим `MOONSHOT_API_KEY` запустіть +- Smoke вартості Moonshot/Kimi: з установленим `MOONSHOT_API_KEY` запустіть `openclaw models list --provider moonshot --json`, потім запустіть ізольований `openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json` проти `moonshot/kimi-k2.6`. Перевірте, що JSON повідомляє Moonshot/K2.6, а transcript асистента зберігає нормалізований `usage.cost`. -Коли вам потрібен лише один failing case, віддавайте перевагу звуженню live-тестів через allowlist env vars, описані нижче. +Коли потрібен лише один випадок збою, віддавайте перевагу звуженню live-тестів через env-змінні allowlist, описані нижче. -## QA-specific runners +## Специфічні для QA запускачі -Ці команди розташовані поруч з основними наборами тестів, коли потрібен реалізм QA-lab: +Ці команди розміщені поруч з основними тестовими наборами, коли потрібна реалістичність QA-lab: -CI запускає QA Lab у dedicated workflows. `Parity gate` запускається на відповідних PR і -з manual dispatch з mock providers. `QA-Lab - All Lanes` запускається щоночі на -`main` і з manual dispatch з mock parity gate, live Matrix lane, -Convex-managed live Telegram lane і Convex-managed live Discord lane як -паралельні jobs. Scheduled QA і release checks явно передають Matrix `--profile fast`, -тоді як Matrix CLI і manual workflow input за замовчуванням залишаються -`all`; manual dispatch може розбивати `all` на `transport`, `media`, `e2ee-smoke`, -`e2ee-deep` і `e2ee-cli` jobs. `OpenClaw Release Checks` запускає parity плюс -fast Matrix і Telegram lanes перед release approval, використовуючи -`mock-openai/gpt-5.5` для release transport checks, щоб вони залишалися детермінованими -та уникали звичайного запуску provider-plugin. Ці live transport gateways вимикають -memory search; поведінка пам’яті залишається покритою QA parity suites. +CI запускає QA Lab у виділених workflow. `Parity gate` запускається на відповідних PR і +через ручний dispatch із mock-провайдерами. `QA-Lab - All Lanes` запускається щоночі на +`main` і через ручний dispatch із mock parity gate, live Matrix-лінією, +керованою Convex live Telegram-лінією та керованою Convex live Discord-лінією як +паралельними завданнями. Заплановані QA та release-перевірки передають Matrix `--profile fast` +явно, тоді як Matrix CLI і ручний workflow input за замовчуванням лишаються +`all`; ручний dispatch може shard-ити `all` на завдання `transport`, `media`, `e2ee-smoke`, +`e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` запускає parity плюс +швидкі Matrix і Telegram-лінії перед release approval, використовуючи +`mock-openai/gpt-5.5` для release transport-перевірок, щоб вони лишалися детермінованими +і уникали звичайного запуску provider-plugin. Ці live transport Gateway вимикають +пошук пам’яті; поведінка пам’яті лишається покритою QA parity-наборами. -Full release live media shards використовують +Повні release live media shards використовують `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, який уже має `ffmpeg` і `ffprobe`. Docker live model/backend shards використовують спільний образ `ghcr.io/openclaw/openclaw-live-test:`, зібраний один раз для вибраного -commit, а потім завантажують його з `OPENCLAW_SKIP_DOCKER_BUILD=1` замість повторної збірки -в кожному shard. +коміту, а потім підтягують його з `OPENCLAW_SKIP_DOCKER_BUILD=1` замість перебудови +всередині кожного shard. - `pnpm openclaw qa suite` - - Запускає QA-сценарії, підтримані репозиторієм, безпосередньо на хості. + - Запускає QA-сценарії з репозиторію безпосередньо на хості. - За замовчуванням запускає кілька вибраних сценаріїв паралельно з ізольованими - Gateway-працівниками. Для `qa-channel` стандартна паралельність становить 4 (обмежена - кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати кількість - працівників, або `--concurrency 1` для старішої послідовної лінії. - - Завершується з ненульовим кодом, коли будь-який сценарій не проходить. Використовуйте `--allow-failures`, коли вам - потрібні артефакти без коду завершення з помилкою. + Gateway-воркерами. `qa-channel` за замовчуванням використовує паралельність 4 (обмежену + кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати + кількість воркерів, або `--concurrency 1` для старішої послідовної лінії. + - Завершується з ненульовим кодом, якщо будь-який сценарій завершується невдало. Використовуйте `--allow-failures`, коли + потрібні артефакти без коду виходу, що означає помилку. - Підтримує режими провайдера `live-frontier`, `mock-openai` і `aimock`. - `aimock` запускає локальний сервер провайдера на базі AIMock для експериментального - покриття фікстур і моків протоколу без заміни сценарно-обізнаної - лінії `mock-openai`. + `aimock` запускає локальний провайдерський сервер на базі AIMock для експериментального + покриття фікстур і protocol-mock без заміни лінії + `mock-openai`, що враховує сценарії. - `pnpm test:gateway:cpu-scenarios` - - Запускає бенч запуску Gateway плюс невеликий пакет мокових сценаріїв QA Lab + - Запускає бенч запуску Gateway разом із невеликим пакетом мокових сценаріїв QA Lab (`channel-chat-baseline`, `memory-failure-fallback`, - `gateway-restart-inflight-run`) і записує об’єднаний підсумок спостережень CPU + `gateway-restart-inflight-run`) і записує зведений підсумок спостережень CPU у `.artifacts/gateway-cpu-scenarios/`. - - За замовчуванням позначає лише сталі спостереження гарячого CPU (`--cpu-core-warn` + - За замовчуванням позначає лише тривалі спостереження гарячого CPU (`--cpu-core-warn` плюс `--hot-wall-warn-ms`), тому короткі сплески під час запуску записуються як метрики - без вигляду регресії, коли Gateway на кілька хвилин притискає CPU. - - Використовує зібрані артефакти `dist`; спершу запустіть збірку, якщо checkout ще не - має свіжого runtime-виводу. + і не виглядають як регресія Gateway із навантаженням на кілька хвилин. + - Використовує зібрані артефакти `dist`; спершу запустіть збірку, якщо checkout ще не має + свіжого runtime-виводу. - `pnpm openclaw qa suite --runner multipass` - - Запускає той самий QA-набір усередині одноразової Linux VM Multipass. - - Зберігає ту саму поведінку вибору сценаріїв, що й `qa suite` на хості. + - Запускає той самий QA-набір усередині одноразової Linux-VM Multipass. + - Зберігає таку саму поведінку вибору сценаріїв, як `qa suite` на хості. - Повторно використовує ті самі прапорці вибору провайдера/моделі, що й `qa suite`. - - Живі запуски передають підтримувані QA-входи автентифікації, практичні для гостьової системи: - ключі провайдера на основі env, шлях до конфігурації живого QA-провайдера та `CODEX_HOME`, - коли він наявний. + - Live-запуски передають підтримувані вхідні дані автентифікації QA, практичні для гостьової системи: + ключі провайдерів на основі env, шлях до live-конфігурації QA-провайдера та `CODEX_HOME`, + коли він присутній. - Каталоги виводу мають залишатися в корені репозиторію, щоб гостьова система могла записувати назад через змонтований workspace. - - Записує звичайний QA-звіт і підсумок плюс журнали Multipass у + - Записує звичайний QA-звіт і підсумок, а також журнали Multipass у `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - Запускає QA-сайт на базі Docker для QA-роботи в операторському стилі. - `pnpm test:docker:npm-onboard-channel-agent` - - Збирає npm tarball із поточного checkout, встановлює його глобально в - Docker, запускає неінтерактивний onboarding з ключем OpenAI API, за замовчуванням налаштовує Telegram, - перевіряє, що runtime запакованого Plugin завантажується без виправлення залежностей - під час запуску, запускає doctor і виконує один локальний хід агента проти - мокового endpoint OpenAI. - - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити ту саму лінію - запакованого встановлення з Discord. + - Збирає npm-tarball з поточного checkout, глобально встановлює його в + Docker, запускає неінтерактивний onboarding з OpenAI API-key, за замовчуванням налаштовує Telegram, + перевіряє, що packaged plugin runtime завантажується без startup + dependency repair, запускає doctor і виконує один локальний agent turn проти + мокового OpenAI endpoint. + - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити ту саму лінію packaged-install + з Discord. - `pnpm test:docker:session-runtime-context` - - Запускає детермінований Docker-smoke зібраного застосунку для транскриптів вбудованого runtime-контексту. - Він перевіряє, що прихований runtime-контекст OpenClaw зберігається як - невідображуване користувацьке повідомлення, а не просочується у видимий хід користувача, - потім засіває уражений зламаний session JSONL і перевіряє, - що `openclaw doctor --fix` переписує його на активну гілку з резервною копією. + - Запускає детермінований Docker smoke з built-app для транскриптів embedded runtime context. + Він перевіряє, що прихований OpenClaw runtime context зберігається як + non-display custom message замість витоку у видимий user turn, + потім додає affected broken session JSONL і перевіряє, що + `openclaw doctor --fix` переписує його на активну гілку з резервною копією. - `pnpm test:docker:npm-telegram-live` - - Встановлює пакет-кандидат OpenClaw у Docker, запускає onboarding установленого пакета, - налаштовує Telegram через установлений CLI, а потім повторно використовує - живу QA-лінію Telegram з цим установленим пакетом як SUT Gateway. + - Встановлює кандидатний пакет OpenClaw у Docker, запускає onboarding для installed-package, + налаштовує Telegram через installed CLI, а потім повторно використовує + live Telegram QA lane з цим installed package як SUT Gateway. - За замовчуванням використовує `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`; задайте `OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz` або - `OPENCLAW_CURRENT_PACKAGE_TGZ`, щоб тестувати розв’язаний локальний tarball замість - встановлення з реєстру. - - Використовує ті самі Telegram env-облікові дані або джерело облікових даних Convex, що й - `pnpm openclaw qa telegram`. Для автоматизації CI/релізів задайте + `OPENCLAW_CURRENT_PACKAGE_TGZ`, щоб протестувати resolved local tarball замість + встановлення з registry. + - Використовує ті самі Telegram env credentials або Convex credential source, що й + `pnpm openclaw qa telegram`. Для CI/release automation задайте `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` плюс - `OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі. Якщо - `OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі Convex присутні в CI, - Docker-wrapper автоматично вибирає Convex. + `OPENCLAW_QA_CONVEX_SITE_URL` і role secret. Якщо + `OPENCLAW_QA_CONVEX_SITE_URL` і Convex role secret присутні в CI, + Docker wrapper автоматично вибирає Convex. - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` перевизначає спільну `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цієї лінії. - - GitHub Actions надає цю лінію як ручний workflow для maintainers - `NPM Telegram Beta E2E`. Він не запускається під час merge. Workflow використовує - середовище `qa-live-shared` і оренди облікових даних Convex CI. -- GitHub Actions також надає `Package Acceptance` для побічного продуктового proof - проти одного пакета-кандидата. Він приймає довірений ref, опубліковану npm-специфікацію, - HTTPS URL tarball плюс SHA-256 або артефакт tarball з іншого запуску, завантажує - нормалізований `openclaw-current.tgz` як `package-under-test`, а потім запускає + - GitHub Actions надає цю лінію як ручний maintainer workflow + `NPM Telegram Beta E2E`. Вона не запускається під час merge. Workflow використовує + середовище `qa-live-shared` і Convex CI credential leases. +- GitHub Actions також надає `Package Acceptance` для side-run product proof + проти одного кандидатного пакета. Він приймає trusted ref, published npm spec, + HTTPS tarball URL плюс SHA-256 або tarball artifact з іншого run, завантажує + нормалізований `openclaw-current.tgz` як `package-under-test`, потім запускає наявний Docker E2E scheduler із профілями ліній smoke, package, product, full або custom. Задайте `telegram_mode=mock-openai` або `live-frontier`, щоб запустити Telegram QA workflow проти того самого артефакту `package-under-test`. - - Proof для останньої beta-версії продукту: + - Latest beta product proof: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -221,7 +221,7 @@ gh workflow run package-acceptance.yml --ref main \ -f telegram_mode=mock-openai ``` -- Proof для точного URL tarball потребує digest: +- Exact tarball URL proof вимагає digest: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -231,7 +231,7 @@ gh workflow run package-acceptance.yml --ref main \ -f suite_profile=package ``` -- Artifact proof завантажує артефакт tarball з іншого запуску Actions: +- Artifact proof завантажує tarball artifact з іншого Actions run: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -243,29 +243,30 @@ gh workflow run package-acceptance.yml --ref main \ - `pnpm test:docker:plugins` - Пакує та встановлює поточну збірку OpenClaw у Docker, запускає Gateway - з налаштованим OpenAI, а потім вмикає вбудовані канали/плагіни через редагування конфігурації. - - Перевіряє, що discovery налаштування залишає неналаштовані завантажувані плагіни відсутніми, - перше налаштоване doctor-виправлення явно встановлює кожен відсутній завантажуваний - Plugin, а другий restart не запускає приховане - виправлення залежностей. - - Також встановлює відому старішу npm-базу, вмикає Telegram перед запуском - `openclaw update --tag ` і перевіряє, що post-update doctor кандидата - очищає залишки залежностей legacy Plugin без postinstall-виправлення - з боку harness. + з налаштованим OpenAI, а потім вмикає bundled channel/plugins через правки + конфігурації. + - Перевіряє, що setup discovery залишає неналаштовані downloadable plugins відсутніми, + перший configured doctor repair явно встановлює кожен відсутній downloadable + plugin, а другий restart не запускає hidden dependency + repair. + - Також встановлює відомий старіший npm baseline, вмикає Telegram перед запуском + `openclaw update --tag ` і перевіряє, що candidate's + post-update doctor очищає legacy plugin dependency debris без + harness-side postinstall repair. - `pnpm test:parallels:npm-update` - - Запускає нативний smoke оновлення запакованого встановлення на гостьових системах Parallels. Кожна - вибрана платформа спочатку встановлює запитаний базовий пакет, потім запускає - встановлену команду `openclaw update` у тій самій гостьовій системі та перевіряє - встановлену версію, статус оновлення, готовність Gateway і один локальний - хід агента. + - Запускає native packaged-install update smoke у Parallels guests. Кожна + вибрана платформа спершу встановлює запитаний baseline package, потім запускає + installed команду `openclaw update` у тій самій гостьовій системі та перевіряє + installed version, update status, gateway readiness і один локальний agent + turn. - Використовуйте `--platform macos`, `--platform windows` або `--platform linux` під час - ітерацій на одній гостьовій системі. Використовуйте `--json` для шляху до артефакту підсумку та - статусу кожної лінії. - - Лінія OpenAI за замовчуванням використовує `openai/gpt-5.5` для proof живого ходу агента. + ітерацій з однією гостьовою системою. Використовуйте `--json` для шляху summary artifact і + per-lane status. + - Лінія OpenAI за замовчуванням використовує `openai/gpt-5.5` для live agent-turn proof. Передайте `--model ` або задайте `OPENCLAW_PARALLELS_OPENAI_MODEL`, коли навмисно перевіряєте іншу модель OpenAI. - - Обгортайте довгі локальні запуски в host timeout, щоб зависання транспорту Parallels не могли + - Обгортайте довгі локальні запуски в host timeout, щоб збої транспорту Parallels не могли використати решту вікна тестування: ```bash @@ -274,73 +275,73 @@ gh workflow run package-acceptance.yml --ref main \ ``` - Скрипт записує вкладені журнали ліній у `/tmp/openclaw-parallels-npm-update.*`. - Перегляньте `windows-update.log`, `macos-update.log` або `linux-update.log`, - перш ніж вважати, що зовнішній wrapper завис. - - Оновлення Windows може витратити 10–15 хвилин на post-update doctor і роботу з - оновленням пакетів на холодній гостьовій системі; це все ще нормальний стан, коли вкладений npm + Перегляньте `windows-update.log`, `macos-update.log` або `linux-update.log` + перед припущенням, що зовнішній wrapper завис. + - Windows update може витрачати 10-15 хвилин на post-update doctor і package + update work у холодній гостьовій системі; це все ще нормально, коли вкладений npm debug log просувається. - - Не запускайте цей агрегований wrapper паралельно з окремими smoke-лініями Parallels - macOS, Windows або Linux. Вони спільно використовують стан VM і можуть конфліктувати під час - відновлення snapshot, подавання пакетів або стану Gateway у гостьовій системі. - - Post-update proof запускає звичайну поверхню вбудованих Plugin, бо - фасади можливостей, як-от speech, image generation і media - understanding, завантажуються через вбудовані runtime API, навіть коли сам - хід агента перевіряє лише просту текстову відповідь. + - Не запускайте цей aggregate wrapper паралельно з окремими Parallels + macOS, Windows або Linux smoke lanes. Вони ділять стан VM і можуть конфліктувати під час + snapshot restore, package serving або guest gateway state. + - Post-update proof запускає звичайну поверхню bundled plugin, оскільки + capability facades, як-от speech, image generation і media + understanding, завантажуються через bundled runtime APIs, навіть коли сам agent + turn перевіряє лише просту текстову відповідь. - `pnpm openclaw qa aimock` - - Запускає лише локальний сервер провайдера AIMock для прямого smoke-тестування - протоколу. + - Запускає лише локальний провайдерський сервер AIMock для прямого protocol smoke + testing. - `pnpm openclaw qa matrix` - - Запускає живу QA-лінію Matrix проти одноразового homeserver Tuwunel на базі Docker. Лише source-checkout — запаковані встановлення не постачають `qa-lab`. - - Повний CLI, каталог профілів/сценаріїв, env vars і структура артефактів: [Matrix QA](/uk/concepts/qa-matrix). + - Запускає Matrix live QA lane проти одноразового Tuwunel homeserver на базі Docker. Лише source-checkout — packaged installs не постачають `qa-lab`. + - Повний CLI, profile/scenario catalog, env vars і artifact layout: [Matrix QA](/uk/concepts/qa-matrix). - `pnpm openclaw qa telegram` - - Запускає живу QA-лінію Telegram проти реальної приватної групи, використовуючи токени driver і SUT bot з env. + - Запускає Telegram live QA lane проти справжньої приватної групи, використовуючи driver і SUT bot tokens з env. - Потребує `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Group id має бути числовим Telegram chat id. - - Підтримує `--credential-source convex` для спільних pooled облікових даних. За замовчуванням використовуйте env-режим або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases. - - Завершується з ненульовим кодом, коли будь-який сценарій не проходить. Використовуйте `--allow-failures`, коли вам - потрібні артефакти без коду завершення з помилкою. - - Потребує двох окремих ботів в одній приватній групі, причому SUT bot має надавати Telegram username. - - Для стабільного bot-to-bot спостереження увімкніть Bot-to-Bot Communication Mode в `@BotFather` для обох ботів і переконайтеся, що driver bot може спостерігати груповий bot traffic. - - Записує Telegram QA-звіт, підсумок і артефакт observed-messages у `.artifacts/qa-e2e/...`. Сценарії з відповідями включають RTT від запиту надсилання driver до спостереженої відповіді SUT. + - Підтримує `--credential-source convex` для спільних pooled credentials. За замовчуванням використовуйте env mode або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases. + - Завершується з ненульовим кодом, якщо будь-який сценарій завершується невдало. Використовуйте `--allow-failures`, коли + потрібні артефакти без коду виходу, що означає помилку. + - Потребує двох різних ботів в одній приватній групі, причому SUT bot має надавати Telegram username. + - Для стабільного bot-to-bot observation увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох ботів і переконайтеся, що driver bot може спостерігати group bot traffic. + - Записує Telegram QA report, summary і observed-messages artifact у `.artifacts/qa-e2e/...`. Replying scenarios включають RTT від driver send request до observed SUT reply. -Живі транспортні лінії мають один стандартний контракт, щоб нові транспорти не розходилися; матриця покриття для кожної лінії міститься в [QA overview → Live transport coverage](/uk/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` — це широкий синтетичний набір і не є частиною цієї матриці. +Live transport lanes використовують один стандартний contract, щоб нові транспорти не розходилися; per-lane coverage matrix розміщена в [QA overview → Live transport coverage](/uk/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` — це широкий synthetic suite і не є частиною цієї матриці. -### Спільні Telegram-облікові дані через Convex (v1) +### Спільні Telegram credentials через Convex (v1) Коли `--credential-source convex` (або `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) увімкнено для -`openclaw qa telegram`, QA lab отримує ексклюзивну оренду з pool на базі Convex, надсилає heartbeats -для цієї оренди, поки лінія працює, і звільняє оренду під час shutdown. +`openclaw qa telegram`, QA lab отримує exclusive lease з пулу на базі Convex, надсилає heartbeats +для цієї lease, поки лінія виконується, і звільняє lease під час shutdown. -Еталонний scaffold проєкту Convex: +Reference Convex project scaffold: - `qa/convex-credential-broker/` Обов’язкові env vars: - `OPENCLAW_QA_CONVEX_SITE_URL` (наприклад `https://your-deployment.convex.site`) -- Один секрет для вибраної ролі: +- Один secret для вибраної role: - `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` для `maintainer` - `OPENCLAW_QA_CONVEX_SECRET_CI` для `ci` -- Вибір ролі облікових даних: +- Вибір credential role: - CLI: `--credential-role maintainer|ci` - Env default: `OPENCLAW_QA_CREDENTIAL_ROLE` (за замовчуванням `ci` у CI, інакше `maintainer`) Необов’язкові env vars: -- `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (за замовчуванням `1200000`) -- `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (за замовчуванням `30000`) -- `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (за замовчуванням `90000`) -- `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (за замовчуванням `15000`) -- `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (за замовчуванням `/qa-credentials/v1`) -- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (необов’язковий trace id) -- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` URL Convex для локальної розробки. +- `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (default `1200000`) +- `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (default `30000`) +- `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (default `90000`) +- `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (default `15000`) +- `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (default `/qa-credentials/v1`) +- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (optional trace id) +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` Convex URLs для local-only development. -`OPENCLAW_QA_CONVEX_SITE_URL` у звичайній роботі має використовувати `https://`. +`OPENCLAW_QA_CONVEX_SITE_URL` має використовувати `https://` у звичайній роботі. -Адмін-команди maintainer (pool add/remove/list) потребують саме -`OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. +Maintainer admin commands (pool add/remove/list) вимагають +саме `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -CLI-помічники для maintainers: +CLI helpers для maintainers: ```bash pnpm openclaw qa credentials doctor @@ -349,12 +350,12 @@ pnpm openclaw qa credentials list --kind telegram pnpm openclaw qa credentials remove --credential-id ``` -Використовуйте `doctor` перед живими запусками, щоб перевірити URL сайту Convex, broker secrets, -endpoint prefix, HTTP timeout і доступність admin/list без друку -значень секретів. Використовуйте `--json` для machine-readable виводу в скриптах і CI -утилітах. +Використовуйте `doctor` перед live runs, щоб перевірити Convex site URL, broker secrets, +endpoint prefix, HTTP timeout і admin/list reachability без виведення +secret values. Використовуйте `--json` для machine-readable output у scripts і CI +utilities. -Контракт стандартної кінцевої точки (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): +Стандартний контракт кінцевої точки (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): - `POST /acquire` - Запит: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` @@ -380,77 +381,77 @@ endpoint prefix, HTTP timeout і доступність admin/list без дру Форма payload для типу Telegram: - `{ groupId: string, driverToken: string, sutToken: string }` -- `groupId` має бути числовим рядком ідентифікатора чату Telegram. -- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє неправильно сформовані payload. +- `groupId` має бути рядком числового id чату Telegram. +- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє payload з неправильною структурою. ### Додавання каналу до QA -Архітектура й назви допоміжних сценарних модулів для нових адаптерів каналів описані в [огляді QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна вимога: реалізувати транспортний runner на спільному seam хоста `qa-lab`, оголосити `qaRunners` у маніфесті plugin, змонтувати як `openclaw qa ` і створити сценарії в `qa/scenarios/`. +Архітектура та назви scenario-helper для нових адаптерів каналів описані в [огляді QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна вимога: реалізувати transport runner на спільному шві хоста `qa-lab`, оголосити `qaRunners` у маніфесті Plugin, змонтувати як `openclaw qa ` і створити сценарії в `qa/scenarios/`. ## Набори тестів (що де запускається) -Думайте про ці набори як про «зростання реалістичності» (і зростання нестабільності/вартості): +Сприймайте набори як “зростання реалістичності” (і зростання нестабільності/вартості): -### Модульні / інтеграційні (стандартно) +### Unit / integration (типово) - Команда: `pnpm test` -- Конфігурація: нецільові запуски використовують набір шардів `vitest.full-*.config.ts` і можуть розгортати багатопроєктні шарди в конфіги окремих проєктів для паралельного планування -- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; модульні тести UI запускаються у спеціальному шарді `unit-ui` -- Область: - - Чисті модульні тести - - Внутрішньопроцесні інтеграційні тести (автентифікація gateway, маршрутизація, tooling, parsing, config) +- Конфігурація: незвужені запуски використовують набір шардів `vitest.full-*.config.ts` і можуть розгортати багатопроєктні шарди в поконфігураційні проєкти для паралельного планування +- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; UI unit-тести запускаються у виділеному шарді `unit-ui` +- Обсяг: + - Чисті unit-тести + - Внутрішньопроцесні integration-тести (автентифікація Gateway, маршрутизація, інструменти, парсинг, конфігурація) - Детерміновані регресії для відомих помилок - Очікування: - Запускається в CI - - Реальні ключі не потрібні + - Справжні ключі не потрібні - Має бути швидким і стабільним - - Тести resolver і public-surface loader мають доводити fallback-поведінку широких `api.js` і - `runtime-api.js` за допомогою згенерованих малих фікстур plugin, а не - реальних API вихідного коду bundled plugin. Завантаження API реальних plugin належать до - contract/integration наборів, якими володіють plugin. + - Тести resolver і loader публічної поверхні мають доводити fallback-поведінку широких `api.js` і + `runtime-api.js` за допомогою згенерованих мінімальних fixtures Plugin, а не + API справжнього вбудованого Plugin. Завантаження API справжніх Plugin належать до + контрактних/integration-наборів, якими володіє Plugin. - - Нецільовий `pnpm test` запускає дванадцять менших конфігів шардів (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного гігантського нативного процесу root-project. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension виснажувати непов’язані набори. - - `pnpm test --watch` усе ще використовує нативний граф проєкту root `vitest.config.ts`, бо watch-цикл із багатьма шардами непрактичний. - - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спершу маршрутизують явні цілі файлів/каталогів через scoped lanes, тож `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає повної вартості запуску root project. - - `pnpm test:changed` стандартно розгортає змінені git-шляхи в дешеві scoped lanes: прямі зміни тестів, сусідні файли `*.test.ts`, явні зіставлення source і локальні залежні елементи import-graph. Зміни config/setup/package не запускають широкі тести, якщо явно не використати `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. - - `pnpm check:changed` — звичайний розумний локальний check gate для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata, live Docker tooling і tooling, а потім запускає відповідні команди typecheck, lint і guard. Він не запускає тести Vitest; для тестового доказу викликайте `pnpm test:changed` або явний `pnpm test `. Зміни версій лише в release metadata запускають цільові перевірки version/config/root-dependency із guard, який відхиляє зміни package поза верхньорівневим полем version. - - Зміни live Docker ACP harness запускають сфокусовані перевірки: синтаксис shell для скриптів live Docker auth і dry-run live Docker scheduler. Зміни `package.json` включаються лише тоді, коли diff обмежений `scripts["test:docker:live-*"]`; зміни dependency, export, version та іншої package-surface все ще використовують ширші guards. - - Легкі за імпортами модульні тести з agents, commands, plugins, auto-reply helpers, `plugin-sdk` і подібних чистих utility-областей маршрутизуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. - - Вибрані helper source-файли `plugin-sdk` і `commands` також зіставляють changed-mode запуски з явними сусідніми тестами в цих легких lanes, тож зміни helper не перезапускають повний важкий набір для цього каталогу. - - `auto-reply` має окремі buckets для верхньорівневих core helpers, верхньорівневих інтеграційних тестів `reply.*` і піддерева `src/auto-reply/reply/**`. CI додатково розділяє піддерево reply на шарди agent-runner, dispatch і commands/state-routing, щоб один import-heavy bucket не володів усім хвостом Node. - - Звичайний PR/main CI навмисно пропускає пакетний sweep extensions і release-only шард `agentic-plugins`. Full Release Validation запускає окремий дочірній workflow `Plugin Prerelease` для цих plugin/extension-heavy наборів на release candidates. + - Незвужений `pnpm test` запускає дванадцять менших shard-конфігурацій (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного величезного native-процесу кореневого проєкту. Це зменшує піковий RSS на навантажених машинах і не дає роботі auto-reply/extension витісняти непов’язані набори. + - `pnpm test --watch` і далі використовує native-граф проєктів кореневого `vitest.config.ts`, бо цикл watch із багатьма шардами непрактичний. + - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спершу спрямовують явні цілі файлів/каталогів через scoped lanes, тому `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає повної плати за запуск кореневого проєкту. + - `pnpm test:changed` типово розгортає змінені git-шляхи в дешеві scoped lanes: прямі зміни тестів, сусідні файли `*.test.ts`, явні зіставлення джерел і локальні залежні вузли графа імпортів. Зміни конфігурації/налаштування/package не запускають тести широко, якщо ви явно не використаєте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. + - `pnpm check:changed` є звичайним розумним локальним check gate для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata, live Docker tooling і tooling, а потім запускає відповідні команди typecheck, lint і guard. Він не запускає Vitest-тести; для тестового доказу викликайте `pnpm test:changed` або явний `pnpm test `. Підняття версій лише в release metadata запускає цільові перевірки version/config/root-dependency із guard, який відхиляє зміни package поза верхньорівневим полем version. + - Зміни live Docker ACP harness запускають сфокусовані перевірки: shell-синтаксис для live Docker auth-скриптів і dry-run live Docker scheduler. Зміни `package.json` включаються лише коли diff обмежений `scripts["test:docker:live-*"]`; зміни dependency, export, version та іншої package-поверхні все ще використовують ширші guards. + - Import-light unit-тести з agents, commands, plugins, auto-reply helpers, `plugin-sdk` та подібних чистих utility-зон спрямовуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли лишаються на наявних lanes. + - Вибрані допоміжні source-файли `plugin-sdk` і `commands` також зіставляють запуски changed-mode з явними сусідніми тестами в цих light lanes, тому зміни helper уникають повторного запуску всього важкого набору для цього каталогу. + - `auto-reply` має виділені buckets для верхньорівневих core helpers, верхньорівневих integration-тестів `reply.*` і піддерева `src/auto-reply/reply/**`. CI додатково розділяє піддерево reply на шарди agent-runner, dispatch і commands/state-routing, щоб один import-heavy bucket не володів усім Node-хвостом. + - Звичайний PR/main CI навмисно пропускає пакетний extension sweep і release-only шард `agentic-plugins`. Full Release Validation запускає окремий дочірній workflow `Plugin Prerelease` для цих Plugin/extension-heavy наборів на реліз-кандидатах. - - Коли змінюєте вхідні дані discovery message-tool або runtime-контекст Compaction, + - Коли ви змінюєте вхідні дані виявлення message-tool або runtime-контекст Compaction, зберігайте обидва рівні покриття. - - Додавайте сфокусовані helper-регресії для меж чистої маршрутизації та нормалізації. - - Підтримуйте справність інтеграційних наборів embedded runner: + - Додавайте сфокусовані регресії helper для меж чистої маршрутизації та нормалізації. + - Підтримуйте integration-набори embedded runner справними: `src/agents/pi-embedded-runner/compact.hooks.test.ts`, `src/agents/pi-embedded-runner/run.overflow-compaction.test.ts` і `src/agents/pi-embedded-runner/run.overflow-compaction.loop.test.ts`. - - Ці набори перевіряють, що scoped ids і поведінка Compaction усе ще проходять - через реальні шляхи `run.ts` / `compact.ts`; helper-only тести - не є достатньою заміною для цих інтеграційних шляхів. + - Ці набори перевіряють, що scoped ids і поведінка Compaction все ще проходять + через реальні шляхи `run.ts` / `compact.ts`; тести лише helper + не є достатньою заміною цих integration-шляхів. - - Базовий конфіг Vitest стандартно використовує `threads`. - - Спільний конфіг Vitest фіксує `isolate: false` і використовує - non-isolated runner у root projects, e2e та live config. - - Root UI lane зберігає свій `jsdom` setup і optimizer, але також працює на - спільному non-isolated runner. - - Кожен шард `pnpm test` успадковує ті самі стандартні значення `threads` + `isolate: false` - зі спільного конфіга Vitest. - - `scripts/run-vitest.mjs` стандартно додає `--no-maglev` для дочірніх процесів Vitest Node, - щоб зменшити compile churn V8 під час великих локальних запусків. + - Базова конфігурація Vitest типово використовує `threads`. + - Спільна конфігурація Vitest фіксує `isolate: false` і використовує + неізольований runner у кореневих проєктах, e2e та live-конфігураціях. + - Кореневий UI lane зберігає своє налаштування `jsdom` і optimizer, але також працює на + спільному неізольованому runner. + - Кожен шард `pnpm test` успадковує ті самі типові `threads` + `isolate: false` + зі спільної конфігурації Vitest. + - `scripts/run-vitest.mjs` типово додає `--no-maglev` для дочірніх Node-процесів + Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. Встановіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8. @@ -459,242 +460,242 @@ endpoint prefix, HTTP timeout і доступність admin/list без дру - `pnpm changed:lanes` показує, які архітектурні lanes запускає diff. - - Pre-commit hook виконує лише форматування. Він повторно stage-ить відформатовані файли й + - pre-commit hook виконує лише форматування. Він повторно stage-ить відформатовані файли і не запускає lint, typecheck або tests. - - Запускайте `pnpm check:changed` явно перед handoff або push, коли вам + - Запускайте `pnpm check:changed` явно перед передаванням або push, коли вам потрібен smart local check gate. - - `pnpm test:changed` стандартно маршрутизується через дешеві scoped lanes. Використовуйте - `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли agent + - `pnpm test:changed` типово спрямовується через дешеві scoped lanes. Використовуйте + `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли agent вирішує, що зміна harness, config, package або contract справді потребує ширшого покриття Vitest. - - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, - лише з вищим лімітом workers. - - Локальне auto-scaling workers навмисно консервативне й зменшує навантаження, - коли середнє навантаження хоста вже високе, тож кілька одночасних - запусків Vitest стандартно завдають менше шкоди. - - Базовий конфіг Vitest позначає projects/config files як - `forceRerunTriggers`, щоб reruns у changed-mode залишалися коректними, коли змінюється - wiring тестів. - - Конфіг залишає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних + - `pnpm test:max` і `pnpm test:changed:max` зберігають таку саму поведінку маршрутизації, + лише з вищою межею worker. + - Локальне auto-scaling worker навмисно консервативне і знижує інтенсивність, + коли середнє навантаження хоста вже високе, тому кілька одночасних + запусків Vitest типово завдають менше шкоди. + - Базова конфігурація Vitest позначає проєкти/config-файли як + `forceRerunTriggers`, щоб rerun у changed-mode залишалися коректними, коли змінюється + test wiring. + - Конфігурація тримає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних хостах; встановіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете - одне явне розташування cache для прямого профілювання. + одне явне розташування кешу для прямого profiling. - - `pnpm test:perf:imports` вмикає звітування Vitest про import-duration плюс - вивід import-breakdown. - - `pnpm test:perf:imports:changed` обмежує той самий profiling view - файлами, зміненими з `origin/main`. + - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпортів плюс + output import-breakdown. + - `pnpm test:perf:imports:changed` звужує той самий profiling view до + файлів, змінених від `origin/main`. - Дані часу шардів записуються в `.artifacts/vitest-shard-timings.json`. - Whole-config запуски використовують шлях config як ключ; include-pattern CI - shards додають назву shard, щоб filtered shards можна було відстежувати + Запуски всієї конфігурації використовують шлях конфігурації як ключ; include-pattern CI + shards додають назву шарда, щоб відфільтровані шарди можна було відстежувати окремо. - Коли один hot test усе ще витрачає більшість часу на startup imports, - тримайте важкі залежності за вузьким локальним seam `*.runtime.ts` і - mock-айте цей seam напряму замість deep-importing runtime helpers лише - для передачі їх через `vi.mock(...)`. + тримайте важкі залежності за вузьким локальним швом `*.runtime.ts` і + mock-айте цей шов напряму замість deep-import runtime helpers лише + щоб передати їх через `vi.mock(...)`. - `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований - `test:changed` із нативним root-project path для цього committed - diff і друкує wall time плюс macOS max RSS. - - `pnpm test:perf:changed:bench -- --worktree` бенчмаркить поточне + `test:changed` із native-шляхом кореневого проєкту для цього committed + diff і виводить wall time плюс macOS max RSS. + - `pnpm test:perf:changed:bench -- --worktree` benchmark-ить поточне dirty tree, маршрутизуючи список змінених файлів через - `scripts/test-projects.mjs` і root Vitest config. - - `pnpm test:perf:profile:main` записує main-thread CPU profile для - startup Vitest/Vite і transform overhead. - - `pnpm test:perf:profile:runner` записує runner CPU+heap profiles для - unit suite з вимкненим file parallelism. + `scripts/test-projects.mjs` і кореневу конфігурацію Vitest. + - `pnpm test:perf:profile:main` записує CPU profile головного потоку для + накладних витрат запуску й transform Vitest/Vite. + - `pnpm test:perf:profile:runner` записує CPU+heap profiles runner для + unit suite з вимкненим паралелізмом файлів. -### Стабільність (gateway) +### Стабільність (Gateway) - Команда: `pnpm test:stability:gateway` - Конфігурація: `vitest.gateway.config.ts`, примусово один worker -- Область: - - Запускає реальний loopback Gateway із diagnostics, увімкненими стандартно - - Проганяє синтетичний churn gateway message, memory і large-payload через diagnostic event path +- Обсяг: + - Запускає справжній loopback Gateway із diagnostics, увімкненою типово + - Проганяє synthetic gateway message, memory і large-payload churn через шлях diagnostic event - Запитує `diagnostics.stability` через Gateway WS RPC - - Покриває допоміжні модулі збереження diagnostic stability bundle - - Перевіряє, що recorder залишається обмеженим, синтетичні RSS samples лишаються нижче pressure budget, а глибини per-session queue повертаються до нуля + - Покриває helpers збереження diagnostic stability bundle + - Перевіряє, що recorder лишається обмеженим, synthetic RSS samples лишаються нижче pressure budget, а глибини per-session queue повертаються до нуля - Очікування: - - Безпечно для CI і не потребує ключів - - Вузький lane для подальшої роботи зі stability-regression, не заміна повному набору Gateway + - Безпечно для CI і без ключів + - Вузький lane для follow-up регресій стабільності, не заміна повного набору Gateway ### E2E (gateway smoke) - Команда: `pnpm test:e2e` - Конфігурація: `vitest.e2e.config.ts` -- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і bundled-plugin E2E tests у `extensions/` -- Стандартні runtime-значення: - - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію. - - Використовує адаптивні workers (CI: до 2, локально: стандартно 1). - - Стандартно запускається в silent mode, щоб зменшити overhead console I/O. -- Корисні перевизначення: - - `OPENCLAW_E2E_WORKERS=` для примусового задання кількості workers (обмежено 16). +- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести bundled-plugin у `extensions/` +- Runtime defaults: + - Використовує Vitest `threads` з `isolate: false`, як і решта repo. + - Використовує adaptive workers (CI: до 2, локально: типово 1). + - Типово запускається в silent mode, щоб зменшити накладні витрати console I/O. +- Корисні overrides: + - `OPENCLAW_E2E_WORKERS=` для примусового задання кількості worker (обмежено 16). - `OPENCLAW_E2E_VERBOSE=1` для повторного ввімкнення verbose console output. -- Область: - - End-to-end поведінка multi-instance gateway - - Поверхні WebSocket/HTTP, node pairing і важчий networking +- Обсяг: + - Наскрізна поведінка Gateway з кількома інстансами + - WebSocket/HTTP-поверхні, pairing вузлів і важча мережева взаємодія - Очікування: - Запускається в CI (коли ввімкнено в pipeline) - - Реальні ключі не потрібні - - Більше рухомих частин, ніж у модульних тестах (може бути повільніше) + - Справжні ключі не потрібні + - Більше рухомих частин, ніж у unit-тестах (може бути повільнішим) -### E2E: smoke OpenShell backend +### E2E: OpenShell backend smoke - Команда: `pnpm test:e2e:openshell` - Файл: `extensions/openshell/src/backend.e2e.test.ts` -- Обсяг: +- Область: - Запускає ізольований OpenShell gateway на хості через Docker - Створює sandbox із тимчасового локального Dockerfile - - Перевіряє backend OpenShell в OpenClaw через справжні `sandbox ssh-config` + виконання SSH - - Перевіряє віддалено-канонічну поведінку файлової системи через міст fs sandbox + - Перевіряє backend OpenShell в OpenClaw через реальні `sandbox ssh-config` + виконання SSH + - Перевіряє віддалено-канонічну поведінку файлової системи через sandbox fs bridge - Очікування: - - Лише за явним увімкненням; не є частиною стандартного запуску `pnpm test:e2e` - - Потребує локального CLI `openshell` і робочого daemon Docker - - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує тестовий gateway і sandbox + - Тільки за явним увімкненням; не входить до стандартного запуску `pnpm test:e2e` + - Потребує локального CLI `openshell` і робочого демона Docker + - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, потім знищує тестовий gateway і sandbox - Корисні перевизначення: - `OPENCLAW_E2E_OPENSHELL=1`, щоб увімкнути тест під час ручного запуску ширшого e2e-набору - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, щоб указати нестандартний бінарний файл CLI або wrapper script + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, щоб указати нестандартний CLI-бінарник або script-обгортку -### Live (справжні провайдери + справжні моделі) +### Живі (реальні провайдери + реальні моделі) - Команда: `pnpm test:live` - Конфігурація: `vitest.live.config.ts` -- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і live-тести bundled-plugin у `extensions/` -- За замовчуванням: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`) -- Обсяг: - - «Чи цей провайдер/модель справді працює _сьогодні_ зі справжніми обліковими даними?» - - Виявляє зміни форматів провайдерів, особливості виклику інструментів, проблеми автентифікації та поведінку обмежень швидкості +- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і живі тести bundled-plugin у `extensions/` +- Типово: **увімкнено** через `pnpm test:live` (задає `OPENCLAW_LIVE_TEST=1`) +- Область: + - “Чи цей провайдер/модель справді працює _сьогодні_ з реальними обліковими даними?” + - Виявляє зміни формату провайдера, особливості виклику інструментів, проблеми автентифікації та поведінку обмеження частоти - Очікування: - - За задумом не є стабільним для CI (справжні мережі, реальні політики провайдерів, квоти, збої) - - Коштує грошей / використовує ліміти швидкості - - Віддавайте перевагу запуску звужених підмножин замість «усього» -- Live-запуски підвантажують `~/.profile`, щоб отримати відсутні API-ключі. -- За замовчуванням live-запуски все одно ізолюють `HOME` і копіюють конфігурацію/матеріали автентифікації в тимчасовий тестовий home, щоб unit-фікстури не могли змінити ваш справжній `~/.openclaw`. -- Встановлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли ви навмисно хочете, щоб live-тести використовували ваш справжній домашній каталог. -- `pnpm test:live` тепер за замовчуванням працює тихіше: зберігає прогрес-вивід `[live] ...`, але приховує додаткове повідомлення `~/.profile` і вимикає bootstrap-логи gateway/шум Bonjour. Встановіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні логи запуску. -- Ротація API-ключів (залежить від провайдера): встановіть `*_API_KEYS` у форматі через кому/крапку з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) чи перевизначення для окремого live-запуску через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу при відповідях з обмеженням швидкості. -- Вивід прогресу/heartbeat: - - Live-набори тепер виводять рядки прогресу в stderr, тому довгі виклики провайдера помітно активні навіть тоді, коли захоплення консолі Vitest тихе. - - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, щоб рядки прогресу провайдера/gateway транслювалися негайно під час live-запусків. - - Налаштуйте heartbeats прямих моделей через `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Налаштуйте heartbeats gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. + - За задумом не є стабільним для CI (реальні мережі, реальні політики провайдерів, квоти, збої) + - Коштує грошей / використовує ліміти частоти + - Краще запускати звужені піднабори замість “усього” +- Живі запуски підвантажують `~/.profile`, щоб отримати відсутні API-ключі. +- Типово живі запуски все ще ізолюють `HOME` і копіюють конфігураційні/автентифікаційні матеріали в тимчасову тестову home-директорію, щоб unit-фікстури не могли змінити ваш реальний `~/.openclaw`. +- Задавайте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли навмисно потрібно, щоб живі тести використовували вашу реальну home-директорію. +- `pnpm test:live` тепер типово працює в тихішому режимі: залишає progress-вивід `[live] ...`, але приглушує додаткове повідомлення `~/.profile` і вимикає логи bootstrap gateway/шум Bonjour. Задайте `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні startup-логи. +- Ротація API-ключів (специфічна для провайдера): задайте `*_API_KEYS` у форматі з комами/крапками з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або per-live перевизначення через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу на відповідях про rate limit. +- Progress/heartbeat-вивід: + - Живі набори тепер виводять рядки прогресу в stderr, щоб довгі виклики провайдерів було видно як активні навіть коли перехоплення консолі Vitest тихе. + - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, щоб рядки прогресу провайдера/gateway транслювалися негайно під час живих запусків. + - Налаштовуйте direct-model heartbeats через `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Налаштовуйте gateway/probe heartbeats через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. ## Який набір запускати? Скористайтеся цією таблицею рішень: -- Редагуєте логіку/тести: запустіть `pnpm test` (і `pnpm test:coverage`, якщо змінили багато) -- Торкаєтеся мережевого шару gateway / протоколу WS / pairing: додайте `pnpm test:e2e` -- Налагоджуєте «мій бот не працює» / збої, специфічні для провайдера / виклик інструментів: запустіть звужений `pnpm test:live` +- Редагуєте логіку/тести: запускайте `pnpm test` (і `pnpm test:coverage`, якщо змінили багато) +- Чіпаєте gateway networking / WS protocol / pairing: додайте `pnpm test:e2e` +- Налагоджуєте “мій бот недоступний” / збої, специфічні для провайдера / виклик інструментів: запускайте звужений `pnpm test:live` -## Live-тести (з доступом до мережі) +## Живі (мережеві) тести -Для live-матриці моделей, smoke-тестів backend CLI, smoke-тестів ACP, harness app-server Codex -і всіх live-тестів медіапровайдерів (Deepgram, BytePlus, ComfyUI, зображення, -музика, відео, media harness), а також обробки облікових даних для live-запусків, див. -[Тестування live-наборів](/uk/help/testing-live). Для спеціального контрольного списку оновлень і -валідації Plugin див. -[Тестування оновлень і Plugin](/uk/help/testing-updates-plugins). +Для живої матриці моделей, CLI backend smoke-тестів, ACP smoke-тестів, Codex app-server +harness і всіх живих тестів media-provider (Deepgram, BytePlus, ComfyUI, image, +music, video, media harness), а також обробки облікових даних для живих запусків, див. +[Тестування живих наборів](/uk/help/testing-live). Для спеціального checklist оновлень і +перевірки Plugin див. +[Тестування оновлень і plugins](/uk/help/testing-updates-plugins). -## Docker runners (необов’язкові перевірки «працює в Linux») +## Docker runners (необов’язкові перевірки "works in Linux") Ці Docker runners поділяються на дві групи: -- Live-model runners: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл profile-key всередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують ваш локальний каталог конфігурації та workspace (і підвантажують `~/.profile`, якщо його змонтовано). Відповідні локальні точки входу: `test:live:models-profiles` і `test:live:gateway-profiles`. -- Docker live runners за замовчуванням мають менший smoke-ліміт, щоб повний Docker-прогін залишався практичним: - `test:docker:live-models` за замовчуванням використовує `OPENCLAW_LIVE_MAX_MODELS=12`, а - `test:docker:live-gateway` за замовчуванням використовує `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, +- Live-model runners: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл profile-key усередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують вашу локальну config-директорію й workspace (і підвантажують `~/.profile`, якщо змонтовано). Відповідні локальні entrypoints: `test:live:models-profiles` і `test:live:gateway-profiles`. +- Docker live runners типово мають меншу межу smoke-перевірки, щоб повний Docker sweep лишався практичним: + `test:docker:live-models` типово задає `OPENCLAW_LIVE_MAX_MODELS=12`, а + `test:docker:live-gateway` типово задає `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` і `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env vars, коли ви явно хочете більший вичерпний scan. -- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, один раз пакує OpenClaw як npm tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Bare-образ є лише Node/Git runner для install/update/plugin-dependency lanes; ці lanes монтують попередньо зібраний tarball. Functional-образ встановлює той самий tarball у `/app` для built-app functionality lanes. Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`; логіка planner міститься в `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` виконує вибраний план. Агрегатор використовує зважений локальний scheduler: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує слотами процесів, а обмеження ресурсів не дають важким live-, npm-install- і multi-service lanes стартувати всім одночасно. Якщо окремий lane важчий за активні обмеження, scheduler все одно може запустити його, коли pool порожній, а потім тримає його єдиним запущеним, доки знову не стане доступною capacity. За замовчуванням: 10 слотів, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; налаштовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` лише тоді, коли Docker-хост має більше запасу. Runner за замовчуванням виконує Docker preflight, видаляє застарілі контейнери OpenClaw E2E, друкує статус кожні 30 секунд, зберігає таймінги успішних lanes у `.artifacts/docker-tests/lane-timings.json` і використовує ці таймінги, щоб у наступних запусках першими стартували довші lanes. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб надрукувати зважений маніфест lanes без збирання чи запуску Docker, або `node scripts/test-docker-all.mjs --plan-json`, щоб надрукувати CI-план для вибраних lanes, потреб package/image і облікових даних. -- `Package Acceptance` — це нативний для GitHub package gate для питання «чи працює цей installable tarball як продукт?». Він визначає один candidate package із `source=npm`, `source=ref`, `source=url` або `source=artifact`, завантажує його як `package-under-test`, а потім запускає reusable Docker E2E lanes проти саме цього tarball замість перепакування вибраного ref. Профілі впорядковані за широтою: `smoke`, `package`, `product` і `full`. Див. [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins) щодо контракту package/update/plugin, матриці published-upgrade survivor, стандартних налаштувань release і triage збоїв. -- Перевірки build і release запускають `scripts/check-cli-bootstrap-imports.mjs` після tsdown. Guard обходить статичний built graph від `dist/entry.js` і `dist/cli/run-main.js` та завершується з помилкою, якщо startup imports до dispatch команди імпортують package dependencies, як-от Commander, prompt UI, undici або logging; він також утримує bundled gateway run chunk у межах бюджету та відхиляє статичні імпорти відомих холодних gateway paths. Packaged CLI smoke також охоплює root help, onboard help, doctor help, status, config schema і команду model-list. -- Застаріла сумісність Package Acceptance обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цього cutoff harness допускає лише прогалини shipped-package metadata: пропущені private QA inventory entries, відсутній `gateway install --wrapper`, відсутні patch-файли у tarball-derived git fixture, відсутній persisted `update.channel`, застарілі розташування plugin install-record, відсутня marketplace install-record persistence і міграція config metadata під час `plugins update`. Для package після `2026.4.25` ці шляхи є strict failures. -- Container smoke runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:upgrade-survivor`, `test:docker:published-upgrade-survivor`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` і `test:docker:config-reload` запускають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. +- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, один раз пакує OpenClaw як npm tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Bare-образ є лише runner Node/Git для lanes install/update/plugin-dependency; ці lanes монтують попередньо зібраний tarball. Functional-образ встановлює той самий tarball у `/app` для lanes функціональності built-app. Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`; planner-логіка міститься в `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` виконує вибраний plan. Агрегат використовує зважений локальний scheduler: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує process slots, тоді як resource caps не дають важким live, npm-install і multi-service lanes стартувати всім одночасно. Якщо окремий lane важчий за активні caps, scheduler все одно може запустити його, коли pool порожній, а потім залишає його єдиним запущеним, доки capacity знову не стане доступною. Типові значення: 10 slots, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; налаштовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` лише коли Docker host має більший запас ресурсів. Runner типово виконує Docker preflight, видаляє застарілі OpenClaw E2E containers, друкує статус кожні 30 секунд, зберігає timings успішних lanes у `.artifacts/docker-tests/lane-timings.json` і використовує ці timings, щоб у наступних запусках першими стартували довші lanes. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб надрукувати зважений lane manifest без збірки або запуску Docker, або `node scripts/test-docker-all.mjs --plan-json`, щоб надрукувати CI plan для вибраних lanes, package/image needs і credentials. +- `Package Acceptance` — це GitHub-native package gate для "чи цей installable tarball працює як продукт?" Він визначає один candidate package із `source=npm`, `source=ref`, `source=url` або `source=artifact`, завантажує його як `package-under-test`, а потім запускає reusable Docker E2E lanes проти саме цього tarball замість перепакування вибраного ref. Профілі упорядковані за широтою: `smoke`, `package`, `product` і `full`. Див. [Тестування оновлень і plugins](/uk/help/testing-updates-plugins) щодо package/update/plugin contract, published-upgrade survivor matrix, release defaults і failure triage. +- Build і release checks запускають `scripts/check-cli-bootstrap-imports.mjs` після tsdown. Guard обходить статичний built graph від `dist/entry.js` і `dist/cli/run-main.js` та завершується з помилкою, якщо pre-dispatch startup імпортує package dependencies, як-от Commander, prompt UI, undici або logging, до command dispatch; він також утримує bundled gateway run chunk у межах бюджету й відхиляє статичні імпорти відомих cold gateway paths. Packaged CLI smoke також покриває root help, onboard help, doctor help, status, config schema і команду model-list. +- Сумісність Package Acceptance legacy обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цієї межі harness допускає лише прогалини metadata shipped-package: пропущені private QA inventory entries, відсутній `gateway install --wrapper`, відсутні patch-файли у tarball-derived git fixture, відсутній persisted `update.channel`, legacy plugin install-record locations, відсутня marketplace install-record persistence і config metadata migration під час `plugins update`. Для packages після `2026.4.25` ці paths є суворими failures. +- Container smoke runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:upgrade-survivor`, `test:docker:published-upgrade-survivor`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` і `test:docker:config-reload` завантажують один або кілька реальних containers і перевіряють higher-level integration paths. -Live-model Docker runners також bind-mount лише потрібні auth homes CLI (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у home контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати tokens без зміни auth store хоста: +Live-model Docker runners також bind-mount лише потрібні CLI auth homes (або всі підтримувані, коли запуск не звужений), а потім копіюють їх у home контейнера перед запуском, щоб external-CLI OAuth міг оновлювати tokens без зміни host auth store: - Прямі моделі: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`) -- ACP bind smoke: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`; за замовчуванням охоплює Claude, Codex і Gemini, зі строгим покриттям Droid/OpenCode через `pnpm test:docker:live-acp-bind:droid` і `pnpm test:docker:live-acp-bind:opencode`) +- ACP bind smoke: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`; типово покриває Claude, Codex і Gemini, зі строгим покриттям Droid/OpenCode через `pnpm test:docker:live-acp-bind:droid` і `pnpm test:docker:live-acp-bind:opencode`) - CLI backend smoke: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) - Codex app-server harness smoke: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) -- Gateway + dev agent: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`) -- Observability smoke: `pnpm qa:otel:smoke` є приватною QA-лінією перевірки вихідного checkout. Її навмисно не включено до Docker-ліній випуску пакета, оскільки npm tarball не містить QA Lab. +- Gateway + агент розробки: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`) +- Observability smoke: `pnpm qa:otel:smoke` — приватна QA-лінія source-checkout. Вона навмисно не входить до package Docker release lanes, тому що npm tarball не містить QA Lab. - Open WebUI live smoke: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) -- Майстер онбордингу (TTY, повне scaffold-налаштування): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) -- Npm tarball onboarding/channel/agent smoke: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований OpenClaw tarball у Docker, налаштовує OpenAI через env-ref онбординг і Telegram за замовчуванням, запускає doctor і виконує один змоканий хід агента OpenAI. Повторно використайте попередньо зібраний tarball з `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть перебудову на host за допомогою `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або перемкніть канал за допомогою `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. -- Update channel switch smoke: `pnpm test:docker:update-channel-switch` глобально встановлює запакований OpenClaw tarball у Docker, перемикається з пакетного `stable` на git `dev`, перевіряє збережений канал і роботу плагіна після оновлення, потім перемикається назад на пакетний `stable` і перевіряє статус оновлення. -- Upgrade survivor smoke: `pnpm test:docker:upgrade-survivor` встановлює запакований OpenClaw tarball поверх забрудненої фікстури старого користувача з агентами, конфігурацією каналу, allowlist плагінів, застарілим станом залежностей плагінів і наявними файлами workspace/session. Він запускає оновлення пакета плюс неінтерактивний doctor без live provider або ключів каналу, потім запускає loopback Gateway і перевіряє збереження конфігурації/стану, а також бюджети startup/status. -- Published upgrade survivor smoke: `pnpm test:docker:published-upgrade-survivor` за замовчуванням встановлює `openclaw@latest`, сідує реалістичні файли наявного користувача, налаштовує цей baseline за допомогою вбудованого рецепта команд, перевіряє отриману конфігурацію, оновлює це опубліковане встановлення до candidate tarball, запускає неінтерактивний doctor, записує `.artifacts/upgrade-survivor/summary.json`, потім запускає loopback Gateway і перевіряє налаштовані intents, збереження стану, startup, `/healthz`, `/readyz` і бюджети статусу RPC. Перевизначте один baseline за допомогою `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, попросіть агрегований scheduler розгорнути точні baseline за допомогою `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS` і розгорніть фікстури у формі issue за допомогою `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS`, наприклад `reported-issues`; набір reported-issues містить `configured-plugin-installs` для автоматичного ремонту встановлення зовнішнього плагіна OpenClaw. Package Acceptance експонує їх як `published_upgrade_survivor_baseline`, `published_upgrade_survivor_baselines` і `published_upgrade_survivor_scenarios`. -- Session runtime context smoke: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого transcript runtime context плюс ремонт doctor для зачеплених дубльованих гілок prompt-rewrite. -- Bun global install smoke: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольованому home і перевіряє, що `openclaw infer image providers --json` повертає вбудованих provider зображень замість зависання. Повторно використайте попередньо зібраний tarball з `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть host build за допомогою `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або скопіюйте `dist/` із зібраного Docker image за допомогою `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. -- Installer Docker smoke: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm cache для своїх root, update і direct-npm контейнерів. Update smoke за замовчуванням використовує npm `latest` як stable baseline перед оновленням до candidate tarball. Перевизначте локально за допомогою `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` або через input `update_baseline_version` workflow Install Smoke на GitHub. Non-root перевірки інсталятора тримають ізольований npm cache, щоб записи cache, що належать root, не маскували поведінку user-local встановлення. Установіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати root/update/direct-npm cache між локальними повторними запусками. -- Install Smoke CI пропускає дубльоване direct-npm глобальне оновлення за допомогою `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`. -- Agents delete shared workspace CLI smoke: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) за замовчуванням збирає root Dockerfile image, сідує двох агентів з одним workspace в ізольованому container home, запускає `agents delete --json` і перевіряє коректний JSON плюс поведінку збереженого workspace. Повторно використайте install-smoke image за допомогою `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. +- Майстер онбордингу (TTY, повне створення каркаса): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) +- Npm tarball onboarding/channel/agent smoke: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює упакований tarball OpenClaw у Docker, налаштовує OpenAI через env-ref онбординг і типово Telegram, запускає doctor і виконує один змоканий хід агента OpenAI. Повторно використайте попередньо зібраний tarball з `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть перебудову на хості з `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або змініть канал через `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. +- Update channel switch smoke: `pnpm test:docker:update-channel-switch` глобально встановлює упакований tarball OpenClaw у Docker, перемикається з package `stable` на git `dev`, перевіряє збережений канал і роботу Plugin після оновлення, потім перемикається назад на package `stable` і перевіряє статус оновлення. +- Upgrade survivor smoke: `pnpm test:docker:upgrade-survivor` встановлює упакований tarball OpenClaw поверх брудного fixture старого користувача з агентами, конфігурацією каналів, allowlists Plugin, застарілим станом залежностей Plugin і наявними файлами workspace/session. Він запускає package update і неінтерактивний doctor без live provider або ключів каналів, потім запускає loopback Gateway і перевіряє збереження config/state, а також бюджети startup/status. +- Published upgrade survivor smoke: `pnpm test:docker:published-upgrade-survivor` типово встановлює `openclaw@latest`, сіє реалістичні файли наявного користувача, налаштовує цей baseline через вбудований рецепт команд, перевіряє отриману конфігурацію, оновлює цю опубліковану інсталяцію до tarball-кандидата, запускає неінтерактивний doctor, записує `.artifacts/upgrade-survivor/summary.json`, потім запускає loopback Gateway і перевіряє налаштовані intents, збереження стану, startup, `/healthz`, `/readyz` і бюджети RPC status. Перевизначте один baseline через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, попросіть агрегований планувальник розгорнути точні baselines через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, наприклад `all-since-2026.4.23`, і розгорніть issue-подібні fixtures через `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS`, наприклад `reported-issues`; набір reported-issues містить `configured-plugin-installs` для автоматичного ремонту встановлення зовнішніх OpenClaw Plugin. Package Acceptance надає їх як `published_upgrade_survivor_baseline`, `published_upgrade_survivor_baselines` і `published_upgrade_survivor_scenarios`. +- Session runtime context smoke: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого transcript runtime context і ремонт doctor для зачеплених дубльованих гілок prompt-rewrite. +- Bun global install smoke: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольованому home і перевіряє, що `openclaw infer image providers --json` повертає вбудованих image providers замість зависання. Повторно використайте попередньо зібраний tarball з `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть збірку на хості з `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або скопіюйте `dist/` із зібраного Docker image через `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. +- Installer Docker smoke: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm cache між контейнерами root, update і direct-npm. Update smoke типово використовує npm `latest` як stable baseline перед оновленням до tarball-кандидата. Перевизначте локально через `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` або через input `update_baseline_version` workflow Install Smoke на GitHub. Перевірки non-root installer тримають ізольований npm cache, щоб записи cache, які належать root, не маскували поведінку user-local install. Задайте `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати cache root/update/direct-npm між локальними повторними запусками. +- Install Smoke CI пропускає дубльоване direct-npm global update через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`. +- Agents delete shared workspace CLI smoke: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) типово збирає root Dockerfile image, сіє двох агентів з одним workspace в ізольованому container home, запускає `agents delete --json` і перевіряє валідний JSON та поведінку збереженого workspace. Повторно використайте install-smoke image з `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. - Gateway networking (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) -- Browser CDP snapshot smoke: `pnpm test:docker:browser-cdp-snapshot` (скрипт: `scripts/e2e/browser-cdp-snapshot-docker.sh`) збирає source E2E image плюс шар Chromium, запускає Chromium із raw CDP, виконує `browser doctor --deep` і перевіряє, що CDP role snapshots охоплюють URL посилань, clickables, підвищені cursor, iframe refs і metadata frame. -- OpenAI Responses web_search minimal reasoning regression: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає змоканий сервер OpenAI через Gateway, перевіряє, що `web_search` піднімає `reasoning.effort` з `minimal` до `low`, потім примусово відхиляє provider schema і перевіряє, що raw detail з’являється в логах Gateway. +- Browser CDP snapshot smoke: `pnpm test:docker:browser-cdp-snapshot` (скрипт: `scripts/e2e/browser-cdp-snapshot-docker.sh`) збирає source E2E image і шар Chromium, запускає Chromium із сирим CDP, виконує `browser doctor --deep` і перевіряє, що CDP role snapshots покривають link URLs, cursor-promoted clickables, iframe refs і frame metadata. +- OpenAI Responses web_search minimal reasoning regression: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає змоканий сервер OpenAI через Gateway, перевіряє, що `web_search` підвищує `reasoning.effort` з `minimal` до `low`, потім примусово спричиняє відхилення provider schema і перевіряє, що сирі деталі з’являються в логах Gateway. - MCP channel bridge (seeded Gateway + stdio bridge + raw Claude notification-frame smoke): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) - Pi bundle MCP tools (реальний stdio MCP server + embedded Pi profile allow/deny smoke): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) -- Cron/subagent MCP cleanup (реальний Gateway + демонтаж stdio MCP child після ізольованого cron і one-shot subagent запусків): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Plugins (install/update smoke для локального шляху, `file:`, npm registry з hoisted залежностями, git moving refs, ClawHub kitchen-sink, оновлень marketplace і Claude-bundle enable/inspect): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) - Установіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб пропустити блок ClawHub, або перевизначте стандартну пару kitchen-sink package/runtime за допомогою `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` і `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Без `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` тест використовує герметичний локальний сервер фікстури ClawHub. +- Cron/subagent MCP cleanup (реальний Gateway + демонтаж stdio MCP child після ізольованого cron і one-shot subagent run): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Plugins (install/update smoke для локального path, `file:`, npm registry з hoisted dependencies, git moving refs, ClawHub kitchen-sink, marketplace updates і Claude-bundle enable/inspect): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) + Задайте `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб пропустити блок ClawHub, або перевизначте типову пару kitchen-sink package/runtime через `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` і `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Без `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` тест використовує герметичний локальний fixture server ClawHub. - Plugin update unchanged smoke: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) - Config reload metadata smoke: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) -- Plugins: `pnpm test:docker:plugins` охоплює install/update smoke для локального шляху, `file:`, npm registry з hoisted залежностями, git moving refs, фікстур ClawHub, оновлень marketplace і Claude-bundle enable/inspect. `pnpm test:docker:plugin-update` охоплює поведінку unchanged update для встановлених плагінів. +- Plugins: `pnpm test:docker:plugins` покриває install/update smoke для локального path, `file:`, npm registry з hoisted dependencies, git moving refs, fixtures ClawHub, marketplace updates і Claude-bundle enable/inspect. `pnpm test:docker:plugin-update` покриває поведінку unchanged update для встановлених plugins. -Щоб вручну попередньо зібрати й повторно використовувати спільний functional image: +Щоб попередньо зібрати й повторно використати спільний functional image вручну: ```bash OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local pnpm test:docker:e2e-build OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels ``` -Перевизначення image для конкретних suite, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе одно мають пріоритет, коли їх задано. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний image, скрипти завантажують його, якщо він ще не є локальним. QR і installer Docker тести зберігають власні Dockerfile, бо вони перевіряють поведінку пакета/встановлення, а не спільний runtime зібраного застосунку. +Перевизначення image для конкретних suite, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе одно мають пріоритет, коли задані. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний image, скрипти завантажують його, якщо він ще не локальний. Docker-тести QR та installer зберігають власні Dockerfiles, тому що вони перевіряють поведінку package/install, а не спільний runtime зібраного застосунку. Docker runners для live-model також монтують поточний checkout лише для читання і -розгортають його у тимчасовий workdir всередині контейнера. Це зберігає runtime +стейджать його у тимчасовий workdir всередині контейнера. Це зберігає runtime image компактним, водночас запускаючи Vitest проти вашого точного локального source/config. -Крок staging пропускає великі локальні cache і build outputs застосунку, як-от +Крок staging пропускає великі локальні cache і outputs збірки застосунків, як-от `.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також app-local `.build` або -директорії output Gradle, щоб Docker live runs не витрачали хвилини на копіювання +output directories Gradle, щоб Docker live runs не витрачали хвилини на копіювання machine-specific artifacts. Вони також задають `OPENCLAW_SKIP_CHANNELS=1`, щоб gateway live probes не запускали -реальні worker каналів Telegram/Discord тощо всередині контейнера. +реальні Telegram/Discord/тощо channel workers всередині контейнера. `test:docker:live-models` усе ще запускає `pnpm test:live`, тому також передавайте `OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити gateway -live coverage із цієї Docker lane. -`test:docker:openwebui` є вищорівневим compatibility smoke: він запускає -контейнер Gateway OpenClaw з увімкненими OpenAI-compatible HTTP endpoints, -запускає pinned контейнер Open WebUI проти цього gateway, входить через -Open WebUI, перевіряє, що `/api/models` експонує `openclaw/default`, а потім надсилає -реальний chat request через proxy `/api/chat/completions` Open WebUI. -Перший запуск може бути помітно повільнішим, бо Docker може знадобитися завантажити +live coverage з цієї Docker-лінії. +`test:docker:openwebui` — це високорівневий compatibility smoke: він запускає +контейнер OpenClaw gateway з увімкненими OpenAI-compatible HTTP endpoints, +запускає закріплений контейнер Open WebUI проти цього gateway, входить через +Open WebUI, перевіряє, що `/api/models` надає `openclaw/default`, а потім надсилає +реальний chat request через proxy Open WebUI `/api/chat/completions`. +Перший запуск може бути помітно повільнішим, тому що Docker може знадобитися завантажити image Open WebUI, а Open WebUI може знадобитися завершити власне cold-start setup. -Ця lane очікує придатний live model key, а `OPENCLAW_PROFILE_FILE` -(`~/.profile` за замовчуванням) є основним способом надати його в Dockerized runs. -Успішні запуски друкують невеликий JSON payload на кшталт `{ "ok": true, "model": +Ця лінія очікує придатний live model key, а `OPENCLAW_PROFILE_FILE` +(типово `~/.profile`) є основним способом надати його в Dockerized runs. +Успішні запуски друкують невеликий JSON payload, як-от `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` навмисно детермінований і не потребує реального акаунта Telegram, Discord або iMessage. Він завантажує seeded Gateway -container, запускає другий контейнер, який створює `openclaw mcp serve`, потім +container, запускає другий контейнер, який породжує `openclaw mcp serve`, а потім перевіряє routed conversation discovery, transcript reads, attachment metadata, поведінку live event queue, outbound send routing і Claude-style channel + permission notifications через реальний stdio MCP bridge. Перевірка notification -інспектує raw stdio MCP frames напряму, тож smoke перевіряє те, що -bridge фактично emit, а не лише те, що випадково surface конкретний client SDK. +інспектує сирі stdio MCP frames напряму, тому smoke перевіряє те, що +bridge справді випромінює, а не лише те, що випадково показує конкретний client SDK. `test:docker:pi-bundle-mcp-tools` детермінований і не потребує live model key. Він збирає repo Docker image, запускає реальний stdio MCP probe server всередині контейнера, матеріалізує цей server через embedded Pi bundle MCP runtime, виконує tool, а потім перевіряє, що `coding` і `messaging` зберігають -tools `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують. +`bundle-mcp` tools, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують. `test:docker:cron-mcp-cleanup` детермінований і не потребує live model key. Він запускає seeded Gateway з реальним stdio MCP probe server, виконує ізольований cron turn і one-shot child turn `/subagents spawn`, а потім перевіряє, @@ -703,65 +704,65 @@ key. Він запускає seeded Gateway з реальним stdio MCP probe Ручний ACP plain-language thread smoke (не CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Зберігайте цей скрипт для regression/debug workflows. Він може знову знадобитися для валідації ACP thread routing, тому не видаляйте його. +- Зберігайте цей скрипт для regression/debug workflows. Він може знову знадобитися для перевірки ACP thread routing, тому не видаляйте його. Корисні env vars: - `OPENCLAW_CONFIG_DIR=...` (за замовчуванням: `~/.openclaw`) змонтовано до `/home/node/.openclaw` - `OPENCLAW_WORKSPACE_DIR=...` (за замовчуванням: `~/.openclaw/workspace`) змонтовано до `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (за замовчуванням: `~/.profile`) змонтовано до `/home/node/.profile` і завантажується перед запуском тестів -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, щоб перевірити лише змінні середовища, завантажені з `OPENCLAW_PROFILE_FILE`, використовуючи тимчасові каталоги конфігурації/робочого простору та без зовнішніх монтувань автентифікації CLI -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) змонтовано до `/home/node/.npm-global` для кешованих встановлень CLI всередині Docker -- Зовнішні каталоги/файли автентифікації CLI під `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються до `/home/node/...` перед запуском тестів +- `OPENCLAW_PROFILE_FILE=...` (за замовчуванням: `~/.profile`) змонтовано до `/home/node/.profile` і зчитується перед запуском тестів +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, щоб перевіряти лише змінні середовища, зчитані з `OPENCLAW_PROFILE_FILE`, використовуючи тимчасові каталоги конфігурації/робочого простору та без монтування зовнішньої автентифікації CLI +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) змонтовано до `/home/node/.npm-global` для кешованих інсталяцій CLI всередині Docker +- Зовнішні каталоги/файли автентифікації CLI у `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються до `/home/node/...` перед початком тестів - Каталоги за замовчуванням: `.minimax` - Файли за замовчуванням: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - Звужені запуски провайдерів монтують лише потрібні каталоги/файли, виведені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - - Перевизначте вручну за допомогою `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або списку через кому на кшталт `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` + - Перевизначте вручну за допомогою `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або списку через кому, наприклад `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` - `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...`, щоб звузити запуск - `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, щоб фільтрувати провайдерів у контейнері -- `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб повторно використати наявний образ `openclaw:local-live` для повторних запусків, які не потребують повторного збирання -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб переконатися, що облікові дані надходять зі сховища профілю (не з env) -- `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку Gateway відкриває для smoke-тесту Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити prompt перевірки nonce, який використовує smoke-тест Open WebUI +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб повторно використати наявний образ `openclaw:local-live` для повторних запусків, яким не потрібне повторне збирання +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб переконатися, що облікові дані надходять зі сховища профілю (а не з середовища) +- `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку Gateway надає для smoke-перевірки Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити запит перевірки nonce, який використовує smoke-перевірка Open WebUI - `OPENWEBUI_IMAGE=...`, щоб перевизначити закріплений тег образу Open WebUI ## Перевірка документації -Запускайте перевірки документації після редагування документів: `pnpm check:docs`. -Запускайте повну перевірку anchors Mintlify, коли також потрібні перевірки заголовків на сторінці: `pnpm docs:check-links:anchors`. +Запускайте перевірки документації після редагування документації: `pnpm check:docs`. +Запускайте повну валідацію якорів Mintlify, коли також потрібні перевірки заголовків на сторінці: `pnpm docs:check-links:anchors`. -## Офлайн-регресія (безпечна для CI) +## Офлайн-регресії (безпечні для CI) -Це регресії “реального pipeline” без реальних провайдерів: +Це регресії «справжнього конвеєра» без справжніх провайдерів: -- Виклик інструментів Gateway (mock OpenAI, реальні gateway + цикл агента): `src/gateway/gateway.test.ts` (випадок: "запускає наскрізний виклик інструмента mock OpenAI через цикл агента gateway") -- Майстер Gateway (WS `wizard.start`/`wizard.next`, записує конфігурацію + застосовується автентифікація): `src/gateway/gateway.test.ts` (випадок: "запускає майстер через ws і записує конфігурацію токена автентифікації") +- Виклики інструментів Gateway (макет OpenAI, справжній gateway + цикл агента): `src/gateway/gateway.test.ts` (випадок: "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Майстер Gateway (WS `wizard.start`/`wizard.next`, записує конфігурацію + примусова автентифікація): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config") -## Eval-и надійності агента (skills) +## Оцінювання надійності агента (Skills) -У нас уже є кілька безпечних для CI тестів, які поводяться як “eval-и надійності агента”: +У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності агента»: -- Mock-виклик інструментів через реальні gateway + цикл агента (`src/gateway/gateway.test.ts`). -- Наскрізні потоки майстра, які перевіряють зв’язування сесії та ефекти конфігурації (`src/gateway/gateway.test.ts`). +- Макет виклику інструментів через справжній gateway + цикл агента (`src/gateway/gateway.test.ts`). +- Наскрізні потоки майстра, які перевіряють з’єднання сеансів і вплив конфігурації (`src/gateway/gateway.test.ts`). -Чого досі бракує для skills (див. [Skills](/uk/tools/skills)): +Чого ще бракує для Skills (див. [Skills](/uk/tools/skills)): -- **Ухвалення рішень:** коли skills перелічені в prompt, чи вибирає агент правильний skill (або уникає нерелевантних)? -- **Відповідність вимогам:** чи читає агент `SKILL.md` перед використанням і чи виконує потрібні кроки/аргументи? -- **Контракти workflow:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сесії та межі sandbox. +- **Ухвалення рішень:** коли Skills перелічені в запиті, чи вибирає агент правильну skill (або уникає нерелевантних)? +- **Відповідність:** чи читає агент `SKILL.md` перед використанням і чи виконує потрібні кроки/аргументи? +- **Контракти робочих процесів:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сеансу та межі пісочниці. -Майбутні eval-и мають передусім залишатися детермінованими: +Майбутні оцінювання мають насамперед залишатися детермінованими: -- Runner сценаріїв із mock-провайдерами для перевірки викликів інструментів + порядку, читання файлів skill і зв’язування сесії. -- Невеликий набір сценаріїв, сфокусованих на skill (використовувати чи уникати, gating, prompt injection). -- Необов’язкові live eval-и (opt-in, gated через env) лише після появи безпечного для CI набору. +- Runner сценаріїв із макетами провайдерів для перевірки викликів інструментів + порядку, читання файлів skill і з’єднання сеансів. +- Невеликий набір сценаріїв, сфокусованих на skill (використати або уникнути, gating, prompt injection). +- Опціональні live-оцінювання (за явним увімкненням, обмежені змінними середовища) лише після появи безпечного для CI набору. ## Контрактні тести (форма plugin і каналу) Контрактні тести перевіряють, що кожен зареєстрований plugin і канал відповідає своєму -інтерфейсному контракту. Вони проходять по всіх виявлених plugins і запускають набір -перевірок форми та поведінки. Стандартна unit-lane `pnpm test` навмисно -пропускає ці спільні seam- і smoke-файли; запускайте контрактні команди явно, +інтерфейсному контракту. Вони проходять усі виявлені plugins і запускають набір +перевірок форми та поведінки. Стандартна unit-смуга `pnpm test` навмисно +пропускає ці файли спільних seams і smoke-перевірок; запускайте контрактні команди явно, коли змінюєте спільні поверхні каналів або провайдерів. ### Команди @@ -776,15 +777,15 @@ key. Він запускає seeded Gateway з реальним stdio MCP probe - **plugin** - Базова форма plugin (id, name, capabilities) - **setup** - Контракт майстра налаштування -- **session-binding** - Поведінка зв’язування сесії +- **session-binding** - Поведінка прив’язування сеансу - **outbound-payload** - Структура payload повідомлення - **inbound** - Обробка вхідних повідомлень - **actions** - Обробники дій каналу -- **threading** - Обробка ID thread -- **directory** - API каталогу/roster -- **group-policy** - Застосування групової політики +- **threading** - Обробка ID потоку +- **directory** - API каталогу/реєстру учасників +- **group-policy** - Примусове застосування групової політики -### Контракти статусу провайдера +### Контракти статусу провайдерів Розташовані в `src/plugins/contracts/*.contract.test.ts`. @@ -806,24 +807,24 @@ key. Він запускає seeded Gateway з реальним stdio MCP probe ### Коли запускати -- Після зміни експортів або subpaths plugin-sdk -- Після додавання або зміни каналу чи provider plugin +- Після зміни експортів або підшляхів plugin-sdk +- Після додавання або змінення каналу чи провайдерського plugin - Після рефакторингу реєстрації або виявлення Plugin -Контрактні тести запускаються в CI і не потребують реальних API-ключів. +Контрактні тести виконуються в CI і не потребують справжніх API-ключів. -## Додавання регресій (рекомендації) +## Додавання регресій (настанови) -Коли ви виправляєте проблему провайдера/моделі, виявлену в live: +Коли виправляєте проблему провайдера/моделі, виявлену в live: -- Додайте безпечну для CI регресію, якщо можливо (mock/stub провайдера або зафіксуйте точне перетворення форми запиту) -- Якщо це за своєю суттю лише live-проблема (обмеження частоти, політики автентифікації), тримайте live-тест вузьким і opt-in через env vars -- Надавайте перевагу найменшому шару, який ловить баг: - - баг перетворення/відтворення запиту провайдера → прямий тест моделей - - баг pipeline сесії/історії/інструментів gateway → live smoke gateway або безпечний для CI mock-тест gateway -- Guardrail обходу SecretRef: - - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль для кожного класу SecretRef з метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id із traversal-сегментами відхиляються. - - Якщо ви додаєте нову цільову родину SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target id, щоб нові класи не можна було тихо пропустити. +- Додайте безпечну для CI регресію, якщо можливо (mock/stub провайдер або захоплення точної трансформації форми запиту) +- Якщо це за своєю суттю лише live (обмеження частоти, політики автентифікації), залиште live-тест вузьким і ввімкненим лише явно через змінні середовища +- Надавайте перевагу найменшому шару, який ловить помилку: + - помилка перетворення/відтворення запиту провайдера → прямий тест моделей + - помилка конвеєра gateway сеанс/історія/інструмент → gateway live smoke або безпечний для CI gateway mock test +- Запобіжник обходу SecretRef: + - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль на клас SecretRef з метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec ids із сегментами обходу відхиляються. + - Якщо додаєте нову сім’ю цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target ids, щоб нові класи не можна було пропустити непомітно. ## Пов’язане diff --git a/docs/uk/reference/RELEASING.md b/docs/uk/reference/RELEASING.md index cf43be966..60d723382 100644 --- a/docs/uk/reference/RELEASING.md +++ b/docs/uk/reference/RELEASING.md @@ -1,272 +1,274 @@ --- read_when: - Пошук визначень публічних каналів випуску - - Запуск перевірки випуску або приймального тестування пакета - - Шукаєте інформацію про іменування версій і періодичність випусків -summary: Канали випуску, контрольний список оператора, бокси валідації, іменування версій і ритм -title: Політика випусків + - Запуск перевірки релізу або приймання пакета + - Шукаєте іменування версій і періодичність випусків +summary: Лінії випуску, контрольний список оператора, середовища перевірки, іменування версій і періодичність +title: Політика релізів x-i18n: - generated_at: "2026-05-02T17:33:47Z" + generated_at: "2026-05-02T18:57:49Z" model: gpt-5.5 provider: openai - source_hash: d58ea2416a3c1e129e5167c20b1c8c55eca581c9f811efee5722b5dfd336a85d + source_hash: 18cee58dcad91e24c0d76622a9ed1568f93e4e2c51deae9ad06ccc7feb831d3a source_path: reference/RELEASING.md workflow: 16 --- -OpenClaw має чотири публічні гілки випусків: +OpenClaw має чотири публічні канали релізів: -- стабільна: теговані випуски, які за замовчуванням публікуються до npm `beta`, або до npm `latest`, коли це явно запитано -- альфа: передвипускні теги, які публікуються до npm `alpha` -- бета: передвипускні теги, які публікуються до npm `beta` -- розробницька: рухома верхівка `main` +- stable: позначені тегами релізи, які типово публікуються в npm `beta`, або в npm `latest`, коли це явно запитано +- alpha: prerelease-теги, які публікуються в npm `alpha` +- beta: prerelease-теги, які публікуються в npm `beta` +- dev: рухома вершина `main` ## Іменування версій -- Версія стабільного випуску: `YYYY.M.D` +- Версія стабільного релізу: `YYYY.M.D` - Git-тег: `vYYYY.M.D` -- Версія стабільного коригувального випуску: `YYYY.M.D-N` +- Версія коригувального стабільного релізу: `YYYY.M.D-N` - Git-тег: `vYYYY.M.D-N` -- Версія альфа-передвипуску: `YYYY.M.D-alpha.N` +- Версія alpha prerelease: `YYYY.M.D-alpha.N` - Git-тег: `vYYYY.M.D-alpha.N` -- Версія бета-передвипуску: `YYYY.M.D-beta.N` +- Версія beta prerelease: `YYYY.M.D-beta.N` - Git-тег: `vYYYY.M.D-beta.N` - Не доповнюйте місяць або день нулями -- `latest` означає поточний просунутий стабільний випуск npm +- `latest` означає поточний просунутий стабільний npm-реліз - `alpha` означає поточну ціль встановлення alpha - `beta` означає поточну ціль встановлення beta -- Стабільні та стабільні коригувальні випуски за замовчуванням публікуються до npm `beta`; оператори випуску можуть явно вказати ціль `latest` або пізніше просунути перевірену beta-збірку -- Кожен стабільний випуск OpenClaw постачається разом із npm-пакетом і застосунком macOS; - beta-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а - збирання/підписування/нотаризацію застосунку macOS залишають для стабільного випуску, якщо це не запитано явно +- Стабільні та коригувальні стабільні релізи типово публікуються в npm `beta`; оператори релізу можуть явно вибрати `latest` або пізніше просунути перевірену beta-збірку +- Кожен стабільний реліз OpenClaw постачає npm-пакет і застосунок macOS разом; + beta-релізи зазвичай спершу перевіряють і публікують шлях npm/package, а + збірку/підпис/нотаризацію застосунку mac залишають для stable, якщо це явно не запитано -## Періодичність випусків +## Частота релізів -- Випуски рухаються спочатку через beta -- Стабільний випуск виходить лише після перевірки останньої beta -- Супровідники зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної - з поточного `main`, щоб перевірка випуску та виправлення не блокували нову +- Релізи рухаються спершу через beta +- Stable виходить лише після перевірки останньої beta +- Мейнтейнери зазвичай створюють релізи з гілки `release/YYYY.M.D`, створеної + з поточної `main`, щоб перевірка релізу й виправлення не блокували нову розробку в `main` -- Якщо beta-тег уже надіслано або опубліковано й він потребує виправлення, супровідники створюють +- Якщо beta-тег уже надіслано або опубліковано й потрібне виправлення, мейнтейнери створюють наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега -- Докладна процедура випуску, затвердження, облікові дані та нотатки щодо відновлення - доступні лише супровідникам +- Детальна процедура релізу, затвердження, облікові дані та нотатки з відновлення + доступні лише мейнтейнерам -## Контрольний список оператора випуску +## Чекліст оператора релізу -Цей контрольний список описує публічну форму процесу випуску. Приватні облікові дані, -підписування, нотаризація, відновлення dist-tag і деталі екстреного відкату залишаються в -інструкції з випусків, доступній лише супровідникам. +Цей чекліст описує публічну форму процесу релізу. Приватні облікові дані, +підписування, нотаризація, відновлення dist-tag і деталі аварійного відкату залишаються в +runbook релізу лише для мейнтейнерів. -1. Почніть із поточного `main`: підтягніть останні зміни, підтвердьте, що цільовий коміт надіслано, - і переконайтеся, що поточний CI для `main` достатньо зелений, щоб створити від нього гілку. -2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії комітів за допомогою - `/changelog`, залиште записи орієнтованими на користувача, закомітьте його, надішліть його та ще раз виконайте rebase/pull - перед створенням гілки. -3. Перегляньте записи сумісності випуску в +1. Почніть із поточної `main`: отримайте найновіші зміни, підтвердьте, що цільовий коміт надіслано, + і підтвердьте, що поточний CI `main` достатньо зелений, щоб створювати від нього гілку. +2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою + `/changelog`, залиште записи орієнтованими на користувачів, закомітьте його, надішліть і виконайте rebase/pull + ще раз перед створенням гілки. +3. Перегляньте записи сумісності релізу в `src/plugins/compat/registry.ts` і - `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену - сумісність лише тоді, коли шлях оновлення лишається покритим, або зафіксуйте, чому її + `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте застарілу + сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому її навмисно збережено. -4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском +4. Створіть `release/YYYY.M.D` з поточної `main`; не виконуйте звичайну релізну роботу безпосередньо в `main`. -5. Оновіть кожне потрібне місце з версією для запланованого тега, запустіть - `pnpm plugins:sync`, щоб публіковані пакети Plugin мали спільну версію випуску - та метадані сумісності, потім запустіть локальну детерміновану попередню перевірку: +5. Підніміть версію в кожному потрібному місці для запланованого тега, запустіть + `pnpm plugins:sync`, щоб публіковні пакети Plugin мали спільну версію релізу + й метадані сумісності, потім запустіть локальний детермінований preflight: `pnpm check:test-types`, `pnpm check:architecture`, `pnpm build && pnpm ui:build`, `pnpm plugins:sync:check` і `pnpm release:check`. -6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тега - для попередньої перевірки лише з метою валідації дозволено повний 40-символьний SHA гілки випуску. +6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. Поки тега немає, + повний 40-символьний SHA гілки релізу дозволений для preflight лише з метою перевірки. Збережіть успішний `preflight_run_id`. -7. Запустіть усі передрелізні тести через `Full Release Validation` для - гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу - для чотирьох великих тестових середовищ випуску: Vitest, Docker, QA Lab і Package. -8. Якщо перевірка не пройшла, виправте в гілці випуску та перезапустіть найменший невдалий - файл, лінію, завдання workflow, профіль пакета, провайдер або allowlist моделі, який +7. Запустіть усі pre-release тести через `Full Release Validation` для + гілки релізу, тега або повного SHA коміту. Це єдина ручна точка входу + для чотирьох великих релізних тестових наборів: Vitest, Docker, QA Lab і Package. +8. Якщо перевірка не проходить, виправте це в гілці релізу й повторно запустіть найменший невдалий + файл, канал, workflow job, профіль пакета, провайдера або allowlist моделі, який доводить виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня робить попередні докази застарілими. 9. Для alpha або beta позначте `vYYYY.M.D-alpha.N` або `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з відповідної гілки `release/YYYY.M.D`. Він перевіряє `pnpm plugins:sync:check`, - спочатку публікує всі публіковані пакети Plugin до npm, потім публікує той самий - набір до ClawHub, а тоді просуває підготовлений артефакт попередньої перевірки npm OpenClaw - з відповідним dist-tag. Після публікації запустіть післяпублікаційну перевірку прийнятності пакета - для опублікованого пакета `openclaw@YYYY.M.D-alpha.N`, `openclaw@alpha`, + спершу публікує всі публіковні пакети Plugin в npm, другим кроком публікує той самий + набір у ClawHub, а потім просуває підготовлений preflight-артефакт OpenClaw npm + з відповідним dist-tag. Після публікації запустіть post-publish package + acceptance для опублікованого пакета `openclaw@YYYY.M.D-alpha.N`, `openclaw@alpha`, `openclaw@YYYY.M.D-beta.N` або `openclaw@beta`. Якщо надісланий або - опублікований передвипуск потребує виправлення, створіть наступний відповідний номер передвипуску; - не видаляйте й не переписуйте старий передвипуск. -10. Для стабільного випуску продовжуйте лише після того, як перевірена beta або кандидат у випуск матиме - потрібні докази валідації. Публікація стабільного npm також проходить через - `OpenClaw Release Publish`, повторно використовуючи успішний артефакт попередньої перевірки через - `preflight_run_id`; готовність стабільного випуску macOS також вимагає + опублікований prerelease потребує виправлення, створіть наступний відповідний номер prerelease; + не видаляйте й не переписуйте старий prerelease. +10. Для stable продовжуйте лише після того, як перевірена beta або release candidate має + потрібні докази перевірки. Публікація stable в npm також проходить через + `OpenClaw Release Publish`, повторно використовуючи успішний preflight-артефакт через + `preflight_run_id`; готовність stable-релізу macOS також потребує упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`. -11. Після публікації запустіть npm-перевірку після публікації, необов’язковий автономний - E2E опублікованого npm для Telegram, коли потрібне післяпублікаційне підтвердження каналу, +11. Після публікації запустіть npm post-publish verifier, необов'язковий standalone + published-npm Telegram E2E, коли потрібен post-publish доказ каналу, просування dist-tag за потреби, нотатки GitHub release/prerelease з - повного відповідного розділу `CHANGELOG.md` і кроки оголошення - випуску. + повного відповідного розділу `CHANGELOG.md` і кроки оголошення релізу. -## Попередня перевірка випуску +## Release preflight -- Запустіть `pnpm check:test-types` перед попередньою перевіркою релізу, щоб тестовий TypeScript залишався +- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався покритим поза швидшим локальним шлюзом `pnpm check` -- Запустіть `pnpm check:architecture` перед попередньою перевіркою релізу, щоб ширші перевірки циклів - імпортів і архітектурних меж були успішними поза швидшим локальним шлюзом +- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів + імпорту та меж архітектури були зеленими поза швидшим локальним шлюзом - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані - релізні артефакти `dist/*` і збірка Control UI існували для кроку - перевірки пакування -- Запустіть `pnpm plugins:sync` після підвищення кореневої версії та перед тегуванням. Він - оновлює версії пакетів публіковних plugin, метадані сумісності - OpenClaw peer/API, метадані збірки та заготовки журналів змін plugin відповідно до версії - релізу core. `pnpm plugins:sync:check` є немодифікувальним релізним запобіжником; - publish workflow завершується помилкою до будь-якої зміни реєстру, якщо цей крок було + релізні артефакти `dist/*` і бандл Control UI існували для кроку перевірки + пакування +- Запустіть `pnpm plugins:sync` після підвищення версії в корені й перед створенням тега. Він + оновлює версії пакетів публіковних Plugin, метадані сумісності з OpenClaw peer/API, + метадані збірки та заготовки журналів змін Plugin, щоб вони відповідали версії + релізу ядра. `pnpm plugins:sync:check` — це немутуючий релізний запобіжник; + workflow публікації завершується з помилкою перед будь-якою зміною реєстру, якщо цей крок було забуто. -- Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб +- Запустіть ручний workflow `Full Release Validation` перед затвердженням релізу, щоб запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку, - тег або повний SHA коміту, запускає ручний `CI` і запускає - `OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker - release-path, live/E2E, OpenWebUI, parity QA Lab, Matrix і Telegram + тег або повний SHA коміту, диспетчеризує ручний `CI` і диспетчеризує + `OpenClaw Release Checks` для install smoke, package acceptance, Docker + release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram lanes. З `release_profile=full` і `rerun_group=all` він також запускає package Telegram E2E проти артефакту `release-package-under-test` із release - checks. Укажіть `npm_telegram_package_spec` після публікації, коли той самий - Telegram E2E також має підтвердити опублікований пакет npm. Укажіть - `evidence_package_spec`, коли приватний evidence report має підтвердити, що - валідація відповідає опублікованому пакету npm без примусового Telegram E2E. + checks. Надайте `npm_telegram_package_spec` після публікації, коли той самий + Telegram E2E має також підтвердити опублікований npm-пакет. Надайте + `package_acceptance_package_spec` після публікації, коли Package Acceptance + має запускати свою матрицю package/update проти відвантаженого npm-пакета замість + артефакту, зібраного з SHA. Надайте + `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що + валідація відповідає опублікованому npm-пакету без примусового Telegram E2E. Приклад: `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D` -- Запустіть ручний workflow `Package Acceptance`, коли потрібне side-channel підтвердження +- Запустіть ручний workflow `Package Acceptance`, коли потрібен доказ через побічний канал для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для - `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref` - щоб запакувати довірену гілку/тег/SHA `package_ref` із поточним - harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим - SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub - Actions. Workflow розв’язує кандидата до + `openclaw@alpha`, `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`, + щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним + harness `workflow_ref`; `source=url` для HTTPS-тарболу з обов’язковим + SHA-256; або `source=artifact` для тарболу, завантаженого іншим запуском GitHub + Actions. Workflow розв’язує кандидата в `package-under-test`, повторно використовує Docker E2E release scheduler проти цього - tarball і може запускати Telegram QA проти того самого tarball з - `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані - Docker lanes містять `published-upgrade-survivor`, артефакт пакета є кандидатом, а - `published_upgrade_survivor_baseline` вибирає опублікований baseline. + тарболу й може запускати Telegram QA проти того самого тарболу з + `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли + вибрані Docker lanes містять `published-upgrade-survivor`, артефакт пакета + є кандидатом, а `published_upgrade_survivor_baseline` вибирає опублікований baseline. Приклад: `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 published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai` Поширені профілі: - - `smoke`: lanes встановлення/channel/agent, gateway network і перезавантаження config - - `package`: package/update/plugin lanes, нативні для артефакту, без OpenWebUI або live ClawHub - - `product`: профіль package плюс MCP channels, cron/subagent cleanup, - OpenAI web search і OpenWebUI - - `full`: фрагменти Docker release-path з OpenWebUI + - `smoke`: lanes для install/channel/agent, мережі Gateway і перезавантаження конфігурації + - `package`: artifact-native lanes для package/update/plugin без OpenWebUI або live ClawHub + - `product`: профіль package плюс MCP-канали, очищення cron/subagent, + вебпошук OpenAI і OpenWebUI + - `full`: Docker release-path chunks з OpenWebUI - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску - Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI - для кандидата релізу. Ручні CI dispatches обходять changed + для релізного кандидата. Ручні dispatch CI оминають changed scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel - contracts, сумісність Node 22, `check`, `check-additional`, build smoke, - docs checks, Python skills, Windows, macOS, Android і Control UI i18n + contracts, сумісність із Node 22, `check`, `check-additional`, build smoke, + перевірки документації, Python skills, Windows, macOS, Android і Control UI i18n lanes. Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D` -- Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Він проганяє +- Запустіть `pnpm qa:otel:smoke`, коли перевіряєте релізну телеметрію. Він проганяє QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace span, обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в Opik, Langfuse або іншому зовнішньому collector. -- Запускайте `pnpm release:check` перед кожним тегованим релізом -- Запустіть `OpenClaw Release Publish` для послідовності модифікувальної публікації після того, як - тег існує. Dispatch виконуйте з `release/YYYY.M.D` (або `main`, коли публікуєте - тег, досяжний з main), передайте release tag і успішний OpenClaw npm - `preflight_run_id`, і залишайте стандартний scope публікації plugin - `all-publishable`, якщо ви навмисно не запускаєте сфокусований repair. Workflow - серіалізує plugin npm publish, plugin ClawHub publish і OpenClaw - npm publish, щоб core package не було опубліковано перед його externalized - plugins. -- Release checks тепер виконуються в окремому ручному workflow: +- Запускайте `pnpm release:check` перед кожним релізом із тегом +- Запустіть `OpenClaw Release Publish` для мутуючої послідовності публікації після того, як + тег існує. Dispatch його з `release/YYYY.M.D` (або `main`, коли публікуєте + тег, досяжний із main), передайте релізний тег і успішний OpenClaw npm + `preflight_run_id`, і залишайте типовий scope публікації Plugin + `all-publishable`, якщо тільки ви навмисно не запускаєте сфокусоване виправлення. Workflow + серіалізує npm-публікацію Plugin, публікацію Plugin у ClawHub і npm-публікацію OpenClaw, + щоб core package не було опубліковано перед його зовнішніми + Plugin. +- Release checks тепер запускаються в окремому ручному 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 - credential leases. Запустіть ручний workflow `QA-Lab - All Lanes` з +- `OpenClaw Release Checks` також запускає шлюз QA Lab mock parity плюс швидкий + live Matrix profile і Telegram QA lane перед затвердженням релізу. Live + lanes використовують середовище `qa-live-shared`; Telegram також використовує leases облікових даних 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`, які напряму викликають + `OpenClaw Release Checks` і `Full Release Validation`, які викликають reusable workflow - `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` -- Цей поділ навмисний: тримати реальний шлях npm release коротким, - детермінованим і сфокусованим на артефактах, тоді як повільніші live checks залишаються у власному - lane, щоб вони не затримували й не блокували publish -- Secret-bearing release checks слід dispatch через `Full Release -Validation` або з `main`/release workflow ref, щоб логіка workflow і - secrets залишалися контрольованими + `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` напряму +- Це розділення навмисне: тримайте справжній npm release path коротким, + детермінованим і сфокусованим на артефактах, тоді як повільніші live checks залишаються у своїй + окремій lane, щоб вони не затримували й не блокували публікацію +- Release checks, що містять секрети, слід dispatch через `Full Release +Validation` або з workflow ref `main`/release, щоб логіка workflow і + секрети залишалися контрольованими - `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, доки - розв’язаний коміт досяжний з гілки OpenClaw або release tag -- Validation-only preflight `OpenClaw NPM Release` також приймає поточний - повний 40-символьний SHA коміту workflow-branch без потреби в pushed tag -- Цей шлях SHA призначений лише для валідації й не може бути promoted у реальний publish + розв’язаний коміт досяжний із гілки OpenClaw або релізного тега +- validation-only preflight `OpenClaw NPM Release` також приймає поточний + повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тега +- Цей шлях SHA призначений лише для валідації й не може бути просунутий у справжню публікацію - У режимі SHA workflow синтезує `v` лише для перевірки - метаданих пакета; реальний publish усе ще потребує справжнього release tag -- Обидва workflows зберігають реальний шлях publish і promotion на GitHub-hosted - runners, тоді як немодифікувальний шлях валідації може використовувати більші + метаданих пакета; справжня публікація все одно потребує справжнього релізного тега +- Обидва workflow залишають справжній шлях публікації та promotion на 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` -- npm release preflight більше не чекає на окремий release checks lane + із використанням обох workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` +- npm release preflight більше не чекає на окрему lane release checks - Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` - (або відповідний beta/correction tag) перед схваленням + (або відповідний beta/correction tag) перед затвердженням - Після npm publish запустіть `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D` - (або відповідну beta/correction version), щоб перевірити опублікований registry - install path у свіжому тимчасовому prefix + (або відповідну beta/correction version), щоб перевірити опублікований шлях встановлення з реєстру + у свіжому тимчасовому префіксі - Після 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 package з використанням спільного пулу leased Telegram credential. - Локальні разові запуски maintainers можуть пропустити Convex vars і передати три + щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E + проти опублікованого npm-пакета з використанням спільного leased Telegram credential + pool. Разові локальні запуски maintainer можуть опустити Convex vars і передати три env credentials `OPENCLAW_QA_TELEGRAM_*` напряму. -- Maintainers можуть запускати ту саму post-publish check з GitHub Actions через +- Maintainers можуть запускати ту саму post-publish check із GitHub Actions через ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і - не запускається на кожному merge. + не запускається під час кожного merge. - Maintainer release automation тепер використовує preflight-then-promote: - - реальний npm publish має пройти успішний npm `preflight_run_id` - - реальний npm publish має бути dispatched з тієї самої гілки `main` або + - справжній npm publish має пройти успішний npm `preflight_run_id` + - справжній npm publish має бути dispatch з тієї самої гілки `main` або `release/YYYY.M.D`, що й успішний preflight run - - stable npm releases за замовчуванням спрямовуються до `beta` + - 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`, тоді як публічний repo зберігає OIDC-only publish - - публічний `macOS Release` є validation-only; коли тег існує лише на - release branch, але workflow dispatched з `main`, задайте + - публічний `macOS Release` призначений лише для валідації; коли тег існує лише в + release branch, але workflow dispatch з `main`, задайте `public_release_branch=release/YYYY.M.D` - - реальний private mac publish має пройти успішний private mac + - справжній private mac publish має пройти успішні private mac `preflight_run_id` і `validate_run_id` - - реальні publish paths promote підготовлені артефакти замість повторної - їхньої перебудови -- Для stable correction releases на кшталт `YYYY.M.D-N`, post-publish verifier + - справжні 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 на + щоб release corrections не могли непомітно залишити старіші глобальні встановлення на базовому stable payload -- npm release preflight fails closed, якщо tarball не містить обидва - `dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`, - щоб ми знову не відправили порожній browser dashboard -- Post-publish verification також перевіряє, що entrypoints опублікованих plugin і - package metadata присутні в установленому registry layout. Реліз, який - постачає відсутні plugin runtime payloads, провалює postpublish verifier і - не може бути promoted до `latest`. -- `pnpm test:install:smoke` також застосовує бюджет npm pack `unpackedSize` до - candidate update tarball, щоб installer e2e ловив випадкове pack bloat - до release publish path +- npm release preflight fail closed, якщо тарбол не містить і + `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`, + щоб ми знову не відвантажили порожню браузерну dashboard +- Post-publish verification також перевіряє, що опубліковані entrypoints Plugin і + метадані пакета присутні в установленому layout реєстру. Реліз, який + відвантажує відсутні runtime payloads Plugin, провалює postpublish verifier і + не може бути просунутий до `latest`. +- `pnpm test:install:smoke` також забезпечує бюджет npm pack `unpackedSize` для + candidate update tarball, тож installer e2e ловить випадкове роздуття пакета + перед release publish path - Якщо релізна робота торкалася CI planning, extension timing manifests або - extension test matrices, згенеруйте заново й перегляньте planner-owned + extension test matrices, регенеруйте та перегляньте planner-owned matrix outputs `plugin-prerelease-extension-shard` з - `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не + `.github/workflows/plugin-prerelease.yml` перед затвердженням, щоб release notes не описували застарілий CI layout - Готовність stable macOS release також включає updater surfaces: - - 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 - для цієї release version + - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip` + - `appcast.xml` у `main` має вказувати на новий stable zip після publish + - запакований застосунок має зберігати non-debug bundle id, непорожній Sparkle feed + URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor + для цієї релізної версії ## Релізні тестові бокси -`Full Release Validation` — це спосіб, у який operators запускають усі передрелізні тести з -однієї точки входу. Для pinned commit proof на швидкозмінній гілці використовуйте +`Full Release Validation` — це спосіб, яким operators запускають усі передрелізні тести з +однієї точки входу. Для доказу pinned commit на швидкозмінній гілці використовуйте helper, щоб кожен child workflow запускався з тимчасової гілки, зафіксованої на target SHA: @@ -274,10 +276,10 @@ SHA: pnpm ci:full-release --sha ``` -Helper пушить `release-ci/-...`, запускає `Full Release Validation` -з цієї гілки з `ref=`, перевіряє, що `headSha` кожного child workflow -збігається з target, а потім видаляє тимчасову гілку. Це уникає випадкового підтвердження -новішого child run з `main`. +Helper пушить `release-ci/-...`, dispatch `Full Release Validation` +з цієї гілки з `ref=`, перевіряє, що кожен child workflow `headSha` +відповідає target, а потім видаляє тимчасову гілку. Це запобігає випадковому +доведенню новішого child run `main`. Для валідації release branch або tag запускайте його з довіреного workflow ref `main` і передавайте release branch або tag як `ref`: @@ -292,46 +294,45 @@ gh workflow run full-release-validation.yml \ -f evidence_package_spec=openclaw@YYYY.M.D-beta.N ``` -Робочий процес визначає цільовий ref, запускає ручний `CI` з +Робочий процес визначає цільовий ref, запускає вручну `CI` з `target_ref=`, запускає `OpenClaw Release Checks` і запускає -окремий package Telegram E2E, коли `release_profile=full` з -`rerun_group=all` або коли задано `npm_telegram_package_spec`. Далі `OpenClaw Release -Checks` розгортається на install smoke, cross-OS release checks, live/E2E Docker -release-path покриття, Package Acceptance з Telegram package QA, QA Lab -parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли -зведення `Full Release Validation` -показує `normal_ci` і `release_checks` як успішні. У режимі full/all -дочірній `npm_telegram` також має бути успішним; поза full/all його пропущено, -якщо не було надано опублікований `npm_telegram_package_spec`. Фінальне -зведення верифікатора містить таблиці найповільніших завдань для кожного -дочірнього запуску, щоб менеджер релізу бачив поточний критичний шлях без -завантаження логів. -Див. [Повна валідація релізу](/uk/reference/full-release-validation) для -повної матриці етапів, точних назв завдань workflow, відмінностей між stable і full профілями, -артефактів і цільових механізмів повторного запуску. -Дочірні workflow запускаються з довіреного ref, який запускає `Full Release -Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на -старішу релізну гілку або тег. Окремого входу Full Release Validation -workflow-ref немає; вибирайте довірений harness, вибираючи ref запуску workflow. -Не використовуйте `--ref main -f ref=` для доказу точного коміту на рухомій `main`; -raw commit SHA не можуть бути workflow dispatch refs, тому використовуйте +окремий Telegram E2E для пакета, коли `release_profile=full` з +`rerun_group=all` або коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release +Checks` розгалужується на install smoke, крос-ОС перевірки релізу, live/E2E Docker +покриття release-path, Package Acceptance з Telegram package QA, паритет QA Lab, +live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли у зведенні +`Full Release Validation` +показано успішні `normal_ci` і `release_checks`. У режимі full/all дочірній +`npm_telegram` також має бути успішним; поза full/all його пропускають, якщо не +було надано опублікований `npm_telegram_package_spec`. Підсумкове зведення +верифікатора містить таблиці найповільніших завдань для кожного дочірнього запуску, +щоб менеджер релізу міг бачити поточний критичний шлях без завантаження логів. +Див. [Повна валідація релізу](/uk/reference/full-release-validation) для повної +матриці етапів, точних назв завдань workflow, відмінностей між профілями stable і full, +артефактів і дескрипторів для сфокусованих повторних запусків. +Дочірні workflow запускаються з довіреного ref, який виконує `Full Release +Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на старішу +релізну гілку або тег. Окремого вхідного параметра workflow-ref для Full Release Validation +немає; вибирайте довірений harness, вибираючи ref запуску workflow. +Не використовуйте `--ref main -f ref=` для доказу точного коміту на рухомому `main`; +сирі SHA комітів не можуть бути ref для workflow dispatch, тому використовуйте `pnpm ci:full-release --sha `, щоб створити закріплену тимчасову гілку. Використовуйте `release_profile`, щоб вибрати ширину live/provider: -- `minimum`: найшвидший release-critical OpenAI/core live і Docker path -- `stable`: minimum плюс stable provider/backend покриття для затвердження релізу -- `full`: stable плюс broad advisory provider/media покриття +- `minimum`: найшвидший критичний для релізу OpenAI/core live і Docker path +- `stable`: minimum плюс stable provider/backend покриття для схвалення релізу +- `full`: stable плюс широке консультативне покриття provider/media -`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз -визначити цільовий ref як `release-package-under-test`, і повторно використовує -цей артефакт як у release-path Docker перевірках, так і в Package Acceptance. -Це утримує всі package-facing boxes на тих самих байтах і уникає повторних збірок пакета. -Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли -задано repo/org змінну, інакше `openai/gpt-5.4`, бо ця lane доводить -встановлення пакета, onboarding, запуск Gateway і один live agent turn, +`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз визначити цільовий +ref як `release-package-under-test`, і повторно використовує цей артефакт як у +release-path Docker перевірках, так і в Package Acceptance. Це утримує всі +package-facing boxes на тих самих байтах і уникає повторних збірок пакета. +Крос-ОС OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли задано +змінну repo/org, інакше `openai/gpt-5.4`, оскільки ця lane +доводить встановлення пакета, onboarding, запуск Gateway і один live agent turn, а не бенчмарк найповільнішої моделі за замовчуванням. Ширша live provider -matrix лишається місцем для model-specific покриття. +матриця лишається місцем для покриття, специфічного для моделей. Використовуйте ці варіанти залежно від етапу релізу: @@ -363,40 +364,40 @@ gh workflow run full-release-validation.yml \ -f npm_telegram_provider_mode=mock-openai ``` -Не використовуйте повну парасольку як перший повторний запуск після цільового виправлення. Якщо один box -падає, використовуйте failed child workflow, job, Docker lane, package profile, model -provider або QA lane для наступного доказу. Запускайте повну парасольку знову лише тоді, -коли виправлення змінило спільну release orchestration або зробило попередній all-box доказ -застарілим. Фінальний верифікатор парасольки повторно перевіряє записані child workflow run -ids, тому після успішного повторного запуску дочірнього workflow повторно запускайте лише невдале +Не використовуйте повний umbrella як перший повторний запуск після сфокусованого виправлення. Якщо один box +завершився невдало, використовуйте невдалий дочірній workflow, завдання, Docker lane, package profile, model +provider або QA lane для наступного доказу. Запускайте повний umbrella знову лише тоді, коли +виправлення змінило спільну оркестрацію релізу або зробило попередні all-box докази +застарілими. Підсумковий верифікатор umbrella повторно перевіряє записані ids запусків дочірніх workflow, +тому після успішного повторного запуску дочірнього workflow повторно запускайте лише невдале батьківське завдання `Verify full validation`. -Для обмеженого відновлення передайте `rerun_group` до парасольки. `all` — це реальний -запуск release-candidate, `ci` запускає лише нормальний дочірній CI, `plugin-prerelease` -запускає лише release-only plugin child, `release-checks` запускає кожен release -box, а вужчі release groups — `install-smoke`, `cross-os`, +Для обмеженого відновлення передайте `rerun_group` в umbrella. `all` — це справжній +запуск release-candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease` +запускає лише дочірній plugin для релізу, `release-checks` запускає кожен release +box, а вужчі release groups — це `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`. -Цільові повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; full/all запуски -з `release_profile=full` використовують release-checks package artifact. +Сфокусовані повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; full/all запуски +з `release_profile=full` використовують артефакт пакета release-checks. ### Vitest -Vitest box — це ручний дочірній workflow `CI`. Manual CI навмисно -обходить changed scoping і примусово запускає нормальний test graph для release +Vitest box — це дочірній workflow ручного `CI`. Ручний CI навмисно +оминає changed scoping і примусово запускає звичайний тестовий граф для release candidate: Linux Node shards, bundled-plugin shards, channel contracts, Node 22 compatibility, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS, Android і Control UI i18n. -Використовуйте цей box, щоб відповісти на запитання: "чи пройшло дерево джерел повний нормальний набір тестів?" -Це не те саме, що release-path product validation. Докази, які слід зберігати: +Використовуйте цей box, щоб відповісти: "чи пройшло дерево вихідного коду повний звичайний тестовий набір?" +Це не те саме, що release-path product validation. Докази, які варто зберегти: -- зведення `Full Release Validation`, що показує URL запущеного `CI` run -- `CI` run зелений на точному target SHA +- зведення `Full Release Validation`, яке показує URL запущеного `CI` +- зелений запуск `CI` на точному цільовому SHA - назви невдалих або повільних shard із CI jobs під час розслідування регресій -- артефакти таймінгу Vitest, такі як `.artifacts/vitest-shard-timings.json`, коли +- артефакти таймінгів Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли запуск потребує аналізу продуктивності -Запускайте manual CI напряму лише тоді, коли реліз потребує детермінованого normal CI, але +Запускайте ручний CI напряму лише тоді, коли реліз потребує детермінованого звичайного CI, але не Docker, QA Lab, live, cross-OS або package boxes: ```bash @@ -405,16 +406,16 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D ### Docker -Docker box живе в `OpenClaw Release Checks` через +Docker box міститься в `OpenClaw Release Checks` через `openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode -workflow `install-smoke`. Він валідує release candidate через упаковані -Docker середовища, а не лише source-level tests. +workflow `install-smoke`. Він валідує release candidate через packaged +Docker environments, а не лише через source-level tests. Release Docker coverage включає: - повний install smoke з увімкненим повільним Bun global install smoke -- підготовку/повторне використання root Dockerfile smoke image за target SHA, з QR, - root/gateway і installer/Bun smoke jobs як окремими install-smoke +- підготовку/повторне використання root Dockerfile smoke image за цільовим SHA, із QR, + root/gateway та installer/Bun smoke jobs, що працюють як окремі install-smoke shards - repository E2E lanes - release-path Docker chunks: `core`, `package-update-openai`, @@ -426,85 +427,88 @@ Release Docker coverage включає: `plugins-runtime-install-g` і `plugins-runtime-install-h` - OpenWebUI coverage всередині chunk `plugins-runtime-services`, коли запитано - розділені bundled plugin install/uninstall lanes - `bundled-plugin-install-uninstall-0` до + `bundled-plugin-install-uninstall-0` through `bundled-plugin-install-uninstall-23` - live/E2E provider suites і Docker live model coverage, коли release checks включають live suites -Використовуйте Docker artifacts перед повторним запуском. Release-path scheduler завантажує +Використовуйте артефакти Docker перед повторним запуском. Release-path scheduler завантажує `.artifacts/docker-tests/` з lane logs, `summary.json`, `failures.json`, -phase timings, scheduler plan JSON і rerun commands. Для цільового відновлення -використовуйте `docker_lanes=` на reusable live/E2E workflow замість -повторного запуску всіх release chunks. Згенеровані команди повторного запуску включають попередні -`package_artifact_run_id` і prepared Docker image inputs, коли доступні, тому +phase timings, scheduler plan JSON і rerun commands. Для сфокусованого відновлення +використовуйте `docker_lanes=` у reusable live/E2E workflow замість +повторного запуску всіх release chunks. Згенеровані rerun commands включають попередні +`package_artifact_run_id` і підготовлені Docker image inputs, коли доступно, тож невдала lane може повторно використати той самий tarball і GHCR images. ### QA Lab -QA Lab box також є частиною `OpenClaw Release Checks`. Це agentic -behavior і channel-level release gate, окремо від Vitest і Docker -package mechanics. +QA Lab box також є частиною `OpenClaw Release Checks`. Це агентний +behavior і channel-level release gate, окремий від Vitest і механіки Docker +package. Release QA Lab coverage включає: -- mock parity gate, що порівнює OpenAI candidate lane з Opus 4.6 +- mock parity gate, що порівнює кандидатну OpenAI lane з Opus 4.6 baseline за допомогою agentic parity pack -- швидкий live Matrix QA profile із використанням середовища `qa-live-shared` -- live Telegram QA lane із використанням Convex CI credential leases +- швидкий live Matrix QA profile із середовищем `qa-live-shared` +- live Telegram QA lane з Convex CI credential leases - `pnpm qa:otel:smoke`, коли release telemetry потребує явного локального доказу -Використовуйте цей box, щоб відповісти на запитання: "чи реліз поводиться правильно в QA scenarios і -live channel flows?" Зберігайте artifact URLs для parity, Matrix і Telegram -lanes під час затвердження релізу. Full Matrix coverage лишається доступним як -ручний sharded QA-Lab run, а не default release-critical lane. +Використовуйте цей box, щоб відповісти: "чи реліз поводиться коректно в QA scenarios і +live channel flows?" Зберігайте URL артефактів для parity, Matrix і Telegram +lanes під час схвалення релізу. Повне Matrix coverage лишається доступним як +ручний sharded QA-Lab run, а не як release-critical lane за замовчуванням. -### Package +### Пакет -Package box — це installable-product gate. Він підтримується +Package box — це gate installable-product. Він підтримується `Package Acceptance` і resolver `scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує -candidate у tarball `package-under-test`, який споживає Docker E2E, валідує -package inventory, записує package version і SHA-256, і тримає +кандидата в tarball `package-under-test`, який споживає Docker E2E, валідує +package inventory, записує package version і SHA-256 та тримає workflow harness ref окремо від package source ref. -Підтримувані джерела candidate: +Підтримувані джерела кандидатів: -- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна OpenClaw release - version -- `source=ref`: запакувати довірену `package_ref` branch, tag або full commit SHA - з вибраним `workflow_ref` harness -- `source=url`: завантажити HTTPS `.tgz` з обов’язковим `package_sha256` -- `source=artifact`: повторно використати `.tgz`, завантажений іншим GitHub Actions run +- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна release + version OpenClaw +- `source=ref`: пакує довірену гілку `package_ref`, тег або повний SHA коміту + з вибраним harness `workflow_ref` +- `source=url`: завантажує HTTPS `.tgz` з обов'язковим `package_sha256` +- `source=artifact`: повторно використовує `.tgz`, завантажений іншим запуском GitHub Actions `OpenClaw Release Checks` запускає Package Acceptance з `source=artifact`, підготовленим release package artifact, `suite_profile=custom`, `docker_lanes=doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update`, -`published_upgrade_survivor_baselines=release-history`, +`published_upgrade_survivor_baselines=all-since-2026.4.23`, `published_upgrade_survivor_scenarios=reported-issues` і -`telegram_mode=mock-openai`. Package Acceptance тримає migration, update, stale +`telegram_mode=mock-openai`. Package Acceptance утримує migration, update, stale plugin dependency cleanup, offline plugin fixtures, plugin update і Telegram -package QA проти того самого resolved tarball. Це GitHub-native -заміна для більшості package/update coverage, що раніше потребувало -Parallels. Cross-OS release checks досі важливі для OS-specific onboarding, +package QA на тому самому resolved tarball. Upgrade matrix покриває кожен stable npm-published baseline від `2026.4.23` до `latest`; використовуйте +Package Acceptance з `source=npm` для вже відвантаженого кандидата або +`source=ref`/`source=artifact` для SHA-backed local npm tarball перед +публікацією. Це GitHub-native +заміна більшості package/update coverage, яке раніше вимагало +Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding, installer і platform behavior, але package/update product validation має надавати перевагу Package Acceptance. -Канонічний checklist для update і plugin validation — +Канонічний чеклист для update і plugin validation: [Тестування оновлень і plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли вирішуєте, яка local, Docker, Package Acceptance або release-check lane доводить plugin install/update, doctor cleanup або published-package migration change. -Exhaustive published update migration з кожного stable пакета `2026.4.23+` — -це окремий ручний workflow `Update Migration`, а не частина Full Release CI. +Вичерпна published update migration з кожного stable пакета `2026.4.23+` — це +окремий ручний workflow `Update Migration`, а не частина Full Release CI. Legacy package-acceptance leniency навмисно обмежена в часі. Пакети до `2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих -до npm: private QA inventory entries, відсутні в tarball, відсутній +у npm: private QA inventory entries, яких немає в tarball, відсутній `gateway install --wrapper`, відсутні patch files у tarball-derived git -fixture, відсутній persisted `update.channel`, legacy plugin install-record +fixture, відсутній збережений `update.channel`, legacy plugin install-record locations, відсутня marketplace install-record persistence і config metadata migration під час `plugins update`. Опублікований пакет `2026.4.26` може попереджати -про local build metadata stamp files, які вже були shipped. Пізніші пакети -мають відповідати сучасним package contracts; ті самі gaps провалюють release +про local build metadata stamp files, які вже були відвантажені. Пізніші пакети +мають задовольняти modern package contracts; ті самі gaps провалюють release validation. Використовуйте ширші Package Acceptance profiles, коли release question стосується @@ -529,25 +533,25 @@ gh workflow run package-acceptance.yml \ - `product`: `package` плюс MCP channels, cron/subagent cleanup, OpenAI web search і OpenWebUI - `full`: Docker release-path chunks з OpenWebUI -- `custom`: точний список `docker_lanes` для цільових повторних запусків +- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків -Для перевірки пакета-кандидата Telegram увімкніть `telegram_mode=mock-openai` або +Для підтвердження Telegram для пакета-кандидата увімкніть `telegram_mode=mock-openai` або `telegram_mode=live-frontier` у Package Acceptance. Workflow передає розв’язаний tarball `package-under-test` у lane Telegram; окремий -workflow Telegram досі приймає опубліковану специфікацію npm для перевірок після публікації. +workflow Telegram і надалі приймає опубліковану npm-специфікацію для перевірок після публікації. -## Автоматизація публікації випуску +## Автоматизація публікації релізу `OpenClaw Release Publish` є звичайною мутувальною точкою входу для публікації. Він -оркеструє workflows довіреного публікатора в порядку, потрібному для випуску: +оркеструє workflow trusted-publisher у порядку, потрібному релізу: -1. Отримати тег випуску та визначити SHA його коміту. -2. Перевірити, що тег досяжний з `main` або `release/*`. +1. Взяти release tag і визначити його commit SHA. +2. Перевірити, що tag досяжний з `main` або `release/*`. 3. Запустити `pnpm plugins:sync:check`. 4. Запустити `Plugin NPM Release` з `publish_scope=all-publishable` і `ref=`. -5. Запустити `Plugin ClawHub Release` з тією самою областю та SHA. -6. Запустити `OpenClaw NPM Release` з тегом випуску, npm dist-tag і +5. Запустити `Plugin ClawHub Release` з тією самою областю й SHA. +6. Запустити `OpenClaw NPM Release` з release tag, npm dist-tag і збереженим `preflight_run_id`. Приклад публікації beta: @@ -590,92 +594,92 @@ gh workflow run openclaw-release-publish.yml \ -f npm_dist_tag=latest ``` -Використовуйте нижчерівневі workflows `Plugin NPM Release` і `Plugin ClawHub Release` -лише для сфокусованого ремонту або повторної публікації. Для ремонту вибраного plugin передайте +Використовуйте нижчорівневі workflow `Plugin NPM Release` і `Plugin ClawHub Release` +лише для цільового ремонту або повторної публікації. Для ремонту вибраного Plugin передайте `plugin_publish_scope=selected` і `plugins=@openclaw/name` до -`OpenClaw Release Publish`, або запустіть дочірній workflow напряму, коли -пакет OpenClaw не має публікуватися. +`OpenClaw Release Publish`, або запускайте дочірній workflow безпосередньо, коли +пакет OpenClaw не слід публікувати. ## Вхідні дані workflow NPM -`OpenClaw NPM Release` приймає такі керовані оператором вхідні дані: +`OpenClaw NPM Release` приймає такі вхідні дані, керовані оператором: -- `tag`: обов’язковий тег випуску, наприклад `v2026.4.2`, `v2026.4.2-1` або - `v2026.4.2-alpha.1` чи `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний - повний 40-символьний SHA коміту гілки workflow для preflight лише з валідацією +- `tag`: обов’язковий release tag, як-от `v2026.4.2`, `v2026.4.2-1`, або + `v2026.4.2-alpha.1` чи `v2026.4.2-beta.1`; коли `preflight_only=true`, ним також може бути поточний + повний 40-символьний commit SHA гілки workflow для preflight лише з валідацією - `preflight_only`: `true` лише для валідації/збірки/пакування, `false` для реального шляху публікації - `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб workflow повторно використав підготовлений tarball з успішного preflight-запуску -- `npm_dist_tag`: цільовий тег npm для шляху публікації; за замовчуванням `beta` +- `npm_dist_tag`: цільовий npm tag для шляху публікації; стандартно `beta` -`OpenClaw Release Publish` приймає такі керовані оператором вхідні дані: +`OpenClaw Release Publish` приймає такі введення, керовані оператором: - `tag`: обов’язковий тег випуску; має вже існувати -- `preflight_run_id`: ідентифікатор успішного preflight-запуску `OpenClaw NPM Release`; +- `preflight_run_id`: ідентифікатор успішного попереднього запуску `OpenClaw NPM Release`; обов’язковий, коли `publish_openclaw_npm=true` - `npm_dist_tag`: цільовий тег npm для пакета OpenClaw - `plugin_publish_scope`: за замовчуванням `all-publishable`; використовуйте `selected` лише - для сфокусованого ремонту + для цільових робіт із виправлення - `plugins`: розділені комами назви пакетів `@openclaw/*`, коли `plugin_publish_scope=selected` -- `publish_openclaw_npm`: за замовчуванням `true`; встановлюйте `false` лише під час використання - workflow як оркестратора ремонту лише plugins +- `publish_openclaw_npm`: за замовчуванням `true`; установлюйте `false` лише тоді, коли використовуєте + робочий процес як оркестратор виправлення лише для Plugin -`OpenClaw Release Checks` приймає такі керовані оператором вхідні дані: +`OpenClaw Release Checks` приймає такі введення, керовані оператором: -- `ref`: гілка, тег або повний SHA коміту для валідації. Перевірки із секретами +- `ref`: гілка, тег або повний SHA коміту для перевірки. Перевірки із секретами вимагають, щоб розв’язаний коміт був досяжний з гілки OpenClaw або тегу випуску. Правила: -- Стабільні та коригувальні теги можуть публікуватися або до `beta`, або до `latest` -- Теги передвипуску alpha можуть публікуватися лише до `alpha` -- Теги передвипуску beta можуть публікуватися лише до `beta` -- Для `OpenClaw NPM Release` вхідний повний SHA коміту дозволений лише коли +- Стабільні та коригувальні теги можуть публікуватися або в `beta`, або в `latest` +- Альфа-теги попередніх випусків можуть публікуватися лише в `alpha` +- Бета-теги попередніх випусків можуть публікуватися лише в `beta` +- Для `OpenClaw NPM Release` введення повного SHA коміту дозволене лише коли `preflight_only=true` - `OpenClaw Release Checks` і `Full Release Validation` завжди - призначені лише для валідації -- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що й під час preflight; - workflow перевіряє ці метадані перед продовженням публікації + призначені лише для перевірки +- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час попередньої перевірки; + робочий процес перевіряє ці метадані перед продовженням публікації ## Послідовність стабільного випуску npm Під час підготовки стабільного випуску npm: 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true` - - До появи тегу можна використати поточний повний SHA коміту гілки workflow - для dry run preflight workflow лише з валідацією -2. Виберіть `npm_dist_tag=beta` для звичайного потоку спершу beta, або `latest` лише - коли ви навмисно хочете пряму стабільну публікацію -3. Запустіть `Full Release Validation` на гілці випуску, тегу випуску або повному + - До створення тегу можна використати поточний повний SHA коміту гілки робочого процесу + для dry run робочого процесу попередньої перевірки лише з валідацією +2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише + тоді, коли навмисно потрібна пряма стабільна публікація +3. Запустіть `Full Release Validation` для гілки випуску, тегу випуску або повного SHA коміту, коли потрібні звичайний CI плюс покриття live prompt cache, Docker, QA Lab, - Matrix і Telegram з одного ручного workflow + Matrix і Telegram з одного ручного робочого процесу 4. Якщо навмисно потрібен лише детермінований звичайний граф тестів, натомість запустіть - ручний workflow `CI` на ref випуску + ручний робочий процес `CI` на ref випуску 5. Збережіть успішний `preflight_run_id` 6. Запустіть `OpenClaw Release Publish` з тим самим `tag`, тим самим `npm_dist_tag` - і збереженим `preflight_run_id`; він публікує зовнішні plugins до npm + і збереженим `preflight_run_id`; він публікує зовнішні Plugin в npm і ClawHub перед просуванням npm-пакета OpenClaw -7. Якщо випуск потрапив на `beta`, використайте приватний - workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` - для просування цієї стабільної версії з `beta` до `latest` -8. Якщо випуск навмисно опубліковано напряму до `latest`, а `beta` - має негайно вказувати на ту саму стабільну збірку, використайте той самий приватний - workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій +7. Якщо випуск потрапив у `beta`, використайте приватний робочий процес + `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`, + щоб просунути цю стабільну версію з `beta` до `latest` +8. Якщо випуск навмисно опубліковано безпосередньо в `latest`, а `beta` + має негайно вказувати на той самий стабільний білд, використайте той самий приватний + робочий процес, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій самовідновлювальній синхронізації перемістити `beta` пізніше -Мутація dist-tag розміщена у приватному репозиторії з міркувань безпеки, бо вона досі +Зміна dist-tag живе в приватному репозиторії з міркувань безпеки, оскільки вона все ще потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC. -Це зберігає і прямий шлях публікації, і шлях просування спершу beta -задокументованими та видимими для операторів. +Це робить як шлях прямої публікації, так і шлях просування beta-first +задокументованими й видимими для оператора. -Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди CLI 1Password (`op`) -лише всередині окремої tmux-сесії. Не викликайте `op` -напряму з основної оболонки агента; утримання цього в tmux робить prompts, -alerts і обробку OTP спостережуваними та запобігає повторним alert на хості. +Якщо супровіднику потрібно повернутися до локальної автентифікації npm, запускайте будь-які команди 1Password +CLI (`op`) лише всередині виділеної сесії tmux. Не викликайте `op` +безпосередньо з основної оболонки агента; утримання цього всередині tmux робить запити, +сповіщення та обробку OTP спостережуваними й запобігає повторним сповіщенням хоста. ## Публічні посилання @@ -689,7 +693,7 @@ alerts і обробку OTP спостережуваними та запобі - [`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) -Maintainers використовують приватну документацію випусків у +Супровідники використовують приватну документацію випусків у [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md) для фактичного runbook. diff --git a/docs/uk/reference/full-release-validation.md b/docs/uk/reference/full-release-validation.md index 3cb20637b..51ae014e2 100644 --- a/docs/uk/reference/full-release-validation.md +++ b/docs/uk/reference/full-release-validation.md @@ -1,25 +1,24 @@ --- read_when: - Запуск або повторний запуск повної перевірки релізу - - Порівняння стабільного та повного профілів перевірки випуску + - Порівняння стабільного та повного профілів перевірки релізу - Налагодження збоїв на етапі перевірки релізу -summary: Етапи повної валідації релізу, дочірні робочі процеси, профілі релізу, ідентифікатори повторних запусків і докази +summary: Етапи повної перевірки релізу, дочірні робочі процеси, профілі релізу, дескриптори повторного запуску та докази title: Повна перевірка релізу x-i18n: - generated_at: "2026-05-01T23:10:06Z" + generated_at: "2026-05-02T18:57:53Z" model: gpt-5.5 provider: openai - source_hash: feb4edec850fb97405575c869547b4851bc773507321690670553e6faafc8b0b + source_hash: 3ce1e5a72227ca202335fe68b537491a0b68a0bb2af431aa56c41cf20989e88c source_path: reference/full-release-validation.md workflow: 16 --- `Full Release Validation` — це парасолька релізу. Це єдина ручна -точка входу для передрелізного підтвердження, але більшість роботи виконується -в дочірніх workflow, щоб невдалий бокс можна було перезапустити без повторного -запуску всього релізу. +точка входу для дорелізного підтвердження, але більшість роботи відбувається в дочірніх workflow, щоб +невдалу box можна було повторно запустити без перезапуску всього релізу. -Запускайте її з довіреного ref workflow, зазвичай `main`, і передайте релізну гілку, +Запускайте її з довіреного workflow ref, зазвичай `main`, і передавайте релізну гілку, тег або повний SHA коміту як `ref`: ```bash @@ -31,117 +30,117 @@ gh workflow run full-release-validation.yml \ -f release_profile=stable ``` -Дочірні workflow використовують довірений ref workflow для harness і вхідний -`ref` для кандидата, що тестується. Це зберігає нову логіку валідації доступною +Дочірні workflow використовують довірений workflow ref для harness і вхідний +`ref` для кандидата, що тестується. Це робить нову логіку валідації доступною під час валідації старішої релізної гілки або тегу. -## Верхньорівневі етапи +Package Acceptance зазвичай збирає tarball кандидата з розв’язаного +`ref`, включно із запусками повного SHA, dispatch виконано через `pnpm ci:full-release`. Після +публікації передайте `package_acceptance_package_spec=openclaw@YYYY.M.D` (або +`openclaw@beta`/`openclaw@latest`), щоб натомість запустити ту саму матрицю package/update проти +відправленого npm-пакета. -| Етап | Деталі | -| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Визначення цілі | **Job:** `Resolve target ref`
**Дочірній workflow:** немає
**Підтверджує:** визначає релізну гілку, тег або повний SHA коміту та записує вибрані вхідні параметри.
**Перезапуск:** перезапустіть парасольку, якщо це завершиться невдачею. | -| Vitest і звичайний CI | **Job:** `Run normal full CI`
**Дочірній workflow:** `CI`
**Підтверджує:** ручний повний граф CI для цільового ref, включно з Linux Node lanes, шардами вбудованих Plugin, контрактами каналів, сумісністю з Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, Control UI i18n та Android через парасольку.
**Перезапуск:** `rerun_group=ci`. | -| Передреліз Plugin | **Job:** `Run plugin prerelease validation`
**Дочірній workflow:** `Plugin Prerelease`
**Підтверджує:** релізні статичні перевірки Plugin, агентне покриття Plugin, повні batch-шарди extensions і Docker lanes передрелізу Plugin.
**Перезапуск:** `rerun_group=plugin-prerelease`. | -| Релізні перевірки | **Job:** `Run release/live/Docker/QA validation`
**Дочірній workflow:** `OpenClaw Release Checks`
**Підтверджує:** install smoke, cross-OS package checks, live/E2E suites, chunks релізного шляху Docker, Package Acceptance, паритет QA Lab, live Matrix і live Telegram.
**Перезапуск:** `rerun_group=release-checks` або вужчий handle release-checks. | -| Пакет Telegram | **Job:** `Run package Telegram E2E`
**Дочірній workflow:** `NPM Telegram Beta E2E`
**Підтверджує:** підтвердження пакета Telegram на основі артефакта для `rerun_group=all` з `release_profile=full`, або підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.
**Перезапуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`. | -| Верифікатор парасольки | **Job:** `Verify full validation`
**Дочірній workflow:** немає
**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших job з дочірніх workflow.
**Перезапуск:** після успішного перезапуску невдалого дочірнього workflow перезапустіть лише цей job. | +## Етапи верхнього рівня + +| Етап | Подробиці | +| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Розв’язання цілі | **Job:** `Resolve target ref`
**Дочірній workflow:** немає
**Підтверджує:** розв’язує релізну гілку, тег або повний SHA коміту й записує вибрані вхідні дані.
**Повторний запуск:** повторно запустіть парасольку, якщо це не вдасться. | +| Vitest і звичайний CI | **Job:** `Run normal full CI`
**Дочірній workflow:** `CI`
**Підтверджує:** ручний повний граф CI проти цільового ref, включно з Linux Node lanes, bundled plugin shards, channel contracts, сумісністю з Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, Control UI i18n і Android через парасольку.
**Повторний запуск:** `rerun_group=ci`. | +| Дореліз Plugin | **Job:** `Run plugin prerelease validation`
**Дочірній workflow:** `Plugin Prerelease`
**Підтверджує:** релізні статичні перевірки Plugin, agentic plugin coverage, повні batch shards розширень і дорелізні Docker lanes Plugin.
**Повторний запуск:** `rerun_group=plugin-prerelease`. | +| Релізні перевірки | **Job:** `Run release/live/Docker/QA validation`
**Дочірній workflow:** `OpenClaw Release Checks`
**Підтверджує:** install smoke, cross-OS package checks, live/E2E suites, Docker release-path chunks, Package Acceptance, QA Lab parity, live Matrix і live Telegram.
**Повторний запуск:** `rerun_group=release-checks` або вужчий handle release-checks. | +| Package Telegram | **Job:** `Run package Telegram E2E`
**Дочірній workflow:** `NPM Telegram Beta E2E`
**Підтверджує:** підтвердження Telegram-пакета на основі артефакта для `rerun_group=all` з `release_profile=full` або підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.
**Повторний запуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`. | +| Верифікатор парасольки | **Job:** `Verify full validation`
**Дочірній workflow:** немає
**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших job з дочірніх workflow.
**Повторний запуск:** повторно запустіть лише цей job після повторного запуску невдалого дочірнього запуску до зеленого стану. | Для `ref=main` і `rerun_group=all` новіша парасолька замінює старішу. -Коли батьківський запуск скасовано, його монітор скасовує будь-який дочірній -workflow, який він уже відправив. Запуски валідації релізної гілки й тегу -за замовчуванням не скасовують один одного. +Коли батьківський запуск скасовано, його монітор скасовує будь-який дочірній workflow, який він уже +dispatch виконав. Запуски валідації релізної гілки та тегу типово не скасовують один одного. ## Етапи релізних перевірок -`OpenClaw Release Checks` — найбільший дочірній workflow. Він один раз визначає -ціль і готує спільний артефакт `release-package-under-test`, коли він потрібен -етапам, що працюють із пакетами або Docker. +`OpenClaw Release Checks` — найбільший дочірній workflow. Він розв’язує ціль +один раз і готує спільний артефакт `release-package-under-test`, коли він потрібен етапам, +пов’язаним із package або Docker. -| Етап | Деталі | -| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Ціль релізу | **Job:** `Resolve target ref`
**Базовий workflow:** немає
**Тести:** вибраний ref, необов’язковий очікуваний SHA, профіль, група перезапуску та сфокусований фільтр live suite.
**Перезапуск:** `rerun_group=release-checks`. | -| Артефакт пакета | **Job:** `Prepare release package artifact`
**Базовий workflow:** немає
**Тести:** пакує або визначає один tarball кандидата та завантажує `release-package-under-test` для подальших перевірок, що працюють із пакетами.
**Перезапуск:** відповідна група package, cross-OS або live/E2E. | -| Install smoke | **Job:** `Run install smoke`
**Базовий workflow:** `Install Smoke`
**Тести:** повний шлях установлення з повторним використанням smoke-образу root Dockerfile, встановлення QR-пакета, root і gateway Docker smokes, Docker-тести інсталятора, Bun global install image-provider smoke та швидкий E2E install/uninstall вбудованого Plugin.
**Перезапуск:** `rerun_group=install-smoke`. | -| Cross-OS | **Job:** `cross_os_release_checks`
**Базовий workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`
**Тести:** fresh і upgrade lanes у Linux, Windows і macOS для вибраного провайдера та режиму, з використанням tarball кандидата плюс baseline-пакета.
**Перезапуск:** `rerun_group=cross-os`. | -| Repo і live E2E | **Job:** `Run repo/live E2E validation`
**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`
**Тести:** repository E2E, live cache, OpenAI websocket streaming, native live provider і шарди Plugin, а також Docker-backed live model/backend/gateway harnesses, вибрані `release_profile`.
**Перезапуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`. | -| Релізний шлях Docker | **Job:** `Run Docker release-path validation`
**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`
**Тести:** chunks релізного шляху Docker проти спільного артефакта пакета.
**Перезапуск:** `rerun_group=live-e2e`. | -| Package Acceptance | **Job:** `Run package acceptance`
**Базовий workflow:** `Package Acceptance`
**Тести:** офлайн fixtures пакетів Plugin, оновлення Plugin і mock-OpenAI Telegram package acceptance проти того самого tarball.
**Перезапуск:** `rerun_group=package`. | -| QA parity | **Job:** `Run QA Lab parity lane` і `Run QA Lab parity report`
**Базовий workflow:** прямі jobs
**Тести:** кандидат і baseline agentic parity packs, потім parity report.
**Перезапуск:** `rerun_group=qa-parity` або `rerun_group=qa`. | -| QA live Matrix | **Job:** `Run QA Lab live Matrix lane`
**Базовий workflow:** прямий job
**Тести:** швидкий live Matrix QA profile у середовищі `qa-live-shared`.
**Перезапуск:** `rerun_group=qa-live` або `rerun_group=qa`. | -| QA live Telegram | **Job:** `Run QA Lab live Telegram lane`
**Базовий workflow:** прямий job
**Тести:** live Telegram QA з leases облікових даних Convex CI.
**Перезапуск:** `rerun_group=qa-live` або `rerun_group=qa`. | -| Верифікатор релізу | **Job:** `Verify release checks`
**Базовий workflow:** немає
**Тести:** обов’язкові jobs release-check для вибраної групи перезапуску.
**Перезапуск:** перезапустіть після успішного проходження сфокусованих дочірніх jobs. | +| Етап | Подробиці | +| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Релізна ціль | **Job:** `Resolve target ref`
**Backing workflow:** немає
**Тестує:** вибраний ref, необов’язковий очікуваний SHA, profile, rerun group і сфокусований фільтр live suite.
**Повторний запуск:** `rerun_group=release-checks`. | +| Артефакт пакета | **Job:** `Prepare release package artifact`
**Backing workflow:** немає
**Тестує:** пакує або розв’язує один tarball кандидата й завантажує `release-package-under-test` для downstream package-facing перевірок.
**Повторний запуск:** відповідна package, cross-OS або live/E2E group. | +| Install smoke | **Job:** `Run install smoke`
**Backing workflow:** `Install Smoke`
**Тестує:** повний шлях інсталяції з повторним використанням root Dockerfile smoke image, інсталяцію QR package, root і gateway Docker smokes, installer Docker tests, Bun global install image-provider smoke і швидкий bundled-plugin install/uninstall E2E.
**Повторний запуск:** `rerun_group=install-smoke`. | +| Cross-OS | **Job:** `cross_os_release_checks`
**Backing workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`
**Тестує:** fresh і upgrade lanes на Linux, Windows і macOS для вибраних provider і mode, використовуючи tarball кандидата плюс baseline package.
**Повторний запуск:** `rerun_group=cross-os`. | +| Repo і live E2E | **Job:** `Run repo/live E2E validation`
**Backing workflow:** `OpenClaw Live And E2E Checks (Reusable)`
**Тестує:** repository E2E, live cache, OpenAI websocket streaming, native live provider і plugin shards, а також Docker-backed live model/backend/gateway harnesses, вибрані `release_profile`.
**Повторний запуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`. | +| Docker release path | **Job:** `Run Docker release-path validation`
**Backing workflow:** `OpenClaw Live And E2E Checks (Reusable)`
**Тестує:** Docker chunks релізного шляху проти спільного артефакта пакета.
**Повторний запуск:** `rerun_group=live-e2e`. | +| Package Acceptance | **Job:** `Run package acceptance`
**Backing workflow:** `Package Acceptance`
**Тестує:** offline fixtures пакетів Plugin, оновлення Plugin, package acceptance для mock-OpenAI Telegram і published-upgrade survivor checks з кожного стабільного npm-релізу на або після `2026.4.23` проти того самого tarball.
**Повторний запуск:** `rerun_group=package`. | +| QA parity | **Job:** `Run QA Lab parity lane` і `Run QA Lab parity report`
**Backing workflow:** прямі jobs
**Тестує:** candidate і baseline agentic parity packs, потім parity report.
**Повторний запуск:** `rerun_group=qa-parity` або `rerun_group=qa`. | +| QA live Matrix | **Job:** `Run QA Lab live Matrix lane`
**Backing workflow:** прямий job
**Тестує:** швидкий live Matrix QA profile у середовищі `qa-live-shared`.
**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`. | +| QA live Telegram | **Job:** `Run QA Lab live Telegram lane`
**Backing workflow:** прямий job
**Тестує:** live Telegram QA з орендами облікових даних Convex CI.
**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`. | +| Релізний верифікатор | **Job:** `Verify release checks`
**Backing workflow:** немає
**Тестує:** обов’язкові jobs release-check для вибраної rerun group.
**Повторний запуск:** повторно запустіть після успішного проходження сфокусованих дочірніх jobs. | -## Chunks релізного шляху Docker +## Docker chunks релізного шляху -Етап релізного шляху Docker запускає ці chunks, коли `live_suite_filter` +Етап Docker release-path запускає ці chunks, коли `live_suite_filter` порожній: -| Chunk | Покриття | -| --------------------------------------------------------------- | ------------------------------------------------------------------------- | -| `core` | Smoke lanes релізного шляху Core Docker. | -| `package-update-openai` | Поведінка встановлення й оновлення пакета OpenAI. | -| `package-update-anthropic` | Поведінка встановлення й оновлення пакета Anthropic. | -| `package-update-core` | Провайдер-нейтральна поведінка пакета й оновлення. | -| `plugins-runtime-plugins` | Runtime lanes Plugin, які перевіряють поведінку Plugin. | -| `plugins-runtime-services` | Runtime lanes Plugin на основі сервісів; включає OpenWebUI, коли запитано. | -| `plugins-runtime-install-a` through `plugins-runtime-install-h` | Batch-перевірки встановлення/runtime Plugin, розділені для паралельної релізної валідації. | +| Chunk | Покриття | +| --------------------------------------------------------------- | ------------------------------------------------------------------------ | +| `core` | Core Docker release-path smoke lanes. | +| `package-update-openai` | Поведінка інсталяції та оновлення пакета OpenAI. | +| `package-update-anthropic` | Поведінка інсталяції та оновлення пакета Anthropic. | +| `package-update-core` | Provider-neutral поведінка пакета й оновлення. | +| `plugins-runtime-plugins` | Plugin runtime lanes, які перевіряють поведінку Plugin. | +| `plugins-runtime-services` | Service-backed Plugin runtime lanes; включає OpenWebUI, коли запитано. | +| `plugins-runtime-install-a` through `plugins-runtime-install-h` | Batch інсталяції/runtime Plugin, розділені для паралельної релізної валідації. | -Використовуйте цільові `docker_lanes=` у reusable live/E2E workflow, -коли не пройшла лише одна Docker lane. Релізні артефакти містять команди -перезапуску для кожної lane з artifact пакета та вхідними параметрами повторного -використання образу, коли вони доступні. +Використовуйте цільове `docker_lanes=` у reusable live/E2E workflow, коли +не вдалася лише одна Docker lane. Релізні артефакти містять команди повторного запуску для кожної lane +з package artifact і image reuse inputs, коли вони доступні. -## Релізні профілі +## Релізні profiles -`release_profile` переважно керує шириною live/provider усередині релізних перевірок. -Він не прибирає normal full CI, Plugin Prerelease, install smoke, package -acceptance, QA Lab або chunks релізного шляху Docker. `full` також змушує -парасольку запускати package Telegram E2E проти артефакта релізного пакета, -коли `rerun_group=all`, щоб повний pre-publish кандидат не пропустив мовчки -цю lane пакета Telegram. +`release_profile` переважно керує шириною live/provider у межах перевірок випуску. +Він не вилучає звичайний повний CI, Plugin попередній випуск, install smoke, приймання пакета, QA Lab або фрагменти release-path Docker. `full` також змушує парасольковий запуск виконувати package Telegram E2E для артефакта пакета випуску, коли `rerun_group=all`, тож повний кандидат перед публікацією не пропускає непомітно цю Telegram-лінію пакета. -| Профіль | Призначення | Включене покриття live/provider | -| -------- | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `minimum` | Найшвидший критичний для релізу smoke. | OpenAI/core live-шлях, Docker live-моделі для OpenAI, нативний core Gateway, нативний профіль OpenAI Gateway, нативний OpenAI Plugin і Docker live Gateway OpenAI. | -| `stable` | Стандартний профіль схвалення релізу. | `minimum` плюс Anthropic, Google, MiniMax, backend, нативний live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і smoke-шард OpenCode Go. | -| `full` | Широкий advisory-перегляд. | `stable` плюс advisory-провайдери, live-шарди Plugin і медіа live-шарди. | +| Профіль | Призначення | Включене live/provider-покриття | +| -------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `minimum` | Найшвидший критичний smoke для випуску. | OpenAI/основний live-шлях, Docker live-моделі для OpenAI, основний native gateway, native OpenAI gateway-профіль, native OpenAI plugin і Docker live gateway OpenAI. | +| `stable` | Типовий профіль схвалення випуску. | `minimum` плюс Anthropic, Google, MiniMax, backend, native live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і один smoke-шард OpenCode Go. | +| `full` | Широкий дорадчий sweep. | `stable` плюс дорадчі провайдери, live-шарди plugin і live-шарди медіа. | -## Доповнення лише для full +## Додатки лише для full Ці набори пропускаються в `stable` і включаються в `full`: -| Область | Покриття лише для full | -| ------------------------------- | ---------------------------------------------------------------------------- | -| Docker live-моделі | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks. | -| Docker live Gateway | Advisory-шард для DeepSeek, Fireworks, OpenCode Go, OpenRouter, xAI і Z.ai. | -| Нативні профілі провайдерів Gateway | Fireworks, DeepSeek, повні шарди моделей OpenCode Go, OpenRouter, xAI і Z.ai. | -| Нативні live-шарди Plugin | Plugins A-K, L-N, O-Z other, Moonshot і xAI. | -| Нативні медіа live-шарди | Аудіо, музика Google, музика MiniMax і відеогрупи A-D. | +| Область | Покриття лише для full | +| -------------------------------- | ------------------------------------------------------------------------------- | +| Docker live-моделі | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks. | +| Docker live gateway | Дорадчий шард для DeepSeek, Fireworks, OpenCode Go, OpenRouter, xAI і Z.ai. | +| Native gateway provider-профілі | Fireworks, DeepSeek, повні шарди моделей OpenCode Go, OpenRouter, xAI і Z.ai. | +| Native plugin live-шарди | Plugins A-K, L-N, O-Z інші, Moonshot і xAI. | +| Native media live-шарди | Audio, Google music, MiniMax music і video groups A-D. | `stable` включає `native-live-src-gateway-profiles-opencode-go-smoke`; `full` натомість використовує ширші шарди моделей OpenCode Go. -## Фокусовані повторні запуски +## Сфокусовані повторні запуски -Використовуйте `rerun_group`, щоб не повторювати непов’язані релізні бокси: +Використовуйте `rerun_group`, щоб не повторювати непов’язані release boxes: -| Handle | Обсяг | -| ------------------- | --------------------------------------------------------------------- | -| `all` | Усі етапи Full Release Validation. | -| `ci` | Лише дочірній manual full CI. | -| `plugin-prerelease` | Лише дочірній Plugin Prerelease. | -| `release-checks` | Усі етапи OpenClaw Release Checks. | -| `install-smoke` | Install Smoke через release checks. | -| `cross-os` | Cross-OS release checks. | -| `live-e2e` | Repo/live E2E і валідація Docker release-path. | -| `package` | Package Acceptance. | -| `qa` | QA parity плюс QA live-лінії. | -| `qa-parity` | Лише QA parity-лінії та звіт. | -| `qa-live` | Лише QA live Matrix і Telegram. | -| `npm-telegram` | E2E Telegram для опублікованого пакета; потребує `npm_telegram_package_spec`. | +| Дескриптор | Обсяг | +| ------------------ | --------------------------------------------------------------------- | +| `all` | Усі етапи повної валідації випуску. | +| `ci` | Лише дочірній ручний повний CI. | +| `plugin-prerelease` | Лише дочірній попередній випуск Plugin. | +| `release-checks` | Усі етапи перевірок випуску OpenClaw. | +| `install-smoke` | Install Smoke через перевірки випуску. | +| `cross-os` | Cross-OS перевірки випуску. | +| `live-e2e` | Repo/live E2E і Docker release-path валідація. | +| `package` | Приймання пакета. | +| `qa` | QA parity плюс QA live-лінії. | +| `qa-parity` | Лише QA parity-лінії та звіт. | +| `qa-live` | Лише QA live Matrix і Telegram. | +| `npm-telegram` | Published-package Telegram E2E; потребує `npm_telegram_package_spec`. | Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли збій стався в одному live-наборі. -Дійсні filter ids визначені в багаторазовому workflow live/E2E, зокрема +Дійсні ідентифікатори фільтрів визначені в reusable live/E2E workflow, зокрема `docker-live-models`, `live-gateway-docker`, `live-gateway-anthropic-docker`, `live-gateway-google-docker`, `live-gateway-minimax-docker`, `live-gateway-advisory-docker`, @@ -150,17 +149,17 @@ acceptance, QA Lab або chunks релізного шляху Docker. `full` т ## Докази, які слід зберегти -Зберігайте підсумок `Full Release Validation` як індекс рівня релізу. Він містить посилання -на child run ids і включає таблиці найповільніших job. У разі збоїв спочатку перевірте дочірній -workflow, а потім повторно запустіть найменший відповідний handle вище. +Зберігайте summary `Full Release Validation` як індекс рівня випуску. Він містить посилання +на child run ids і таблиці slowest-job. У разі збоїв спершу перевіряйте child workflow, +а потім повторно запускайте найменший відповідний дескриптор вище. Корисні артефакти: - `release-package-under-test` з `OpenClaw Release Checks` -- Артефакти Docker release-path у `.artifacts/docker-tests/` -- `package-under-test` з Package Acceptance і артефакти Docker acceptance -- Артефакти Cross-OS release-check для кожної OS і suite -- Артефакти QA parity, Matrix і Telegram +- Docker release-path артефакти в `.artifacts/docker-tests/` +- Package Acceptance `package-under-test` і Docker acceptance артефакти +- Cross-OS release-check артефакти для кожної ОС і набору +- QA parity, Matrix і Telegram артефакти ## Файли workflow diff --git a/docs/uk/reference/test.md b/docs/uk/reference/test.md index e44dd938b..c4c20abbc 100644 --- a/docs/uk/reference/test.md +++ b/docs/uk/reference/test.md @@ -1,63 +1,63 @@ --- read_when: - Запуск або виправлення тестів -summary: Як запускати тести локально (vitest) і коли використовувати режими force/coverage +summary: Як запускати тести локально (vitest) і коли використовувати режими примусового запуску/покриття title: Тести x-i18n: - generated_at: "2026-05-02T15:57:36Z" + generated_at: "2026-05-02T18:58:20Z" model: gpt-5.5 provider: openai - source_hash: c1e4aec3c056619467bbf51549699cd0387ebb16576e88f91587aab3f382c6c1 + source_hash: 8a88599d079e1ca42d73d354b582d67dd85be40fc92eed5abe6dcef37dc21f4f source_path: reference/test.md workflow: 16 --- -- Повний набір для тестування (набори тестів, живі тести, Docker): [Тестування](/uk/help/testing) -- Перевірка оновлень і пакетів Plugin: [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins) +- Повний набір для тестування (набори, live, Docker): [Тестування](/uk/help/testing) +- Перевірка оновлень і пакетів Plugin: [Тестування оновлень і плагінів](/uk/help/testing-updates-plugins) -- `pnpm test:force`: Завершує будь-який завислий процес Gateway, що утримує стандартний контрольний порт, а потім запускає повний набір Vitest з ізольованим портом Gateway, щоб серверні тести не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск Gateway залишив порт 18789 зайнятим. -- `pnpm test:coverage`: Запускає модульний набір із покриттям V8 (через `vitest.unit.config.ts`). Це перевірка модульного покриття завантажених файлів, а не покриття всіх файлів у всьому репозиторії. Пороги становлять 70% для рядків/функцій/операторів і 55% для гілок. Оскільки `coverage.all` має значення false, перевірка вимірює файли, завантажені набором модульного покриття, замість того щоб вважати кожен вихідний файл із розділених доріжок непокритим. -- `pnpm test:coverage:changed`: Запускає модульне покриття лише для файлів, змінених після `origin/main`. -- `pnpm test:changed`: дешевий розумний запуск змінених тестів. Він запускає точні цілі з прямих змін тестів, сусідніх файлів `*.test.ts`, явних зіставлень джерел і локального графа імпортів. Широкі зміни конфігурації/пакетів пропускаються, якщо вони не зіставляються з точними тестами. -- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: явний широкий запуск змінених тестів. Використовуйте його, коли зміна тестового обв'язування/конфігурації/пакета має повертатися до ширшої поведінки Vitest для змінених тестів. -- `pnpm changed:lanes`: показує архітектурні доріжки, спричинені diff щодо `origin/main`. -- `pnpm check:changed`: запускає розумну перевірку змін для diff щодо `origin/main`. Вона запускає typecheck, lint і guard-команди для зачеплених архітектурних доріжок, але не запускає тести Vitest. Використовуйте `pnpm test:changed` або явний `pnpm test ` для тестового підтвердження. -- `pnpm test`: спрямовує явні цілі файлів/каталогів через scoped-доріжки Vitest. Запуски без цілі використовують фіксовані групи shard і розгортаються до leaf-конфігів для локального паралельного виконання; група extension завжди розгортається до per-extension shard-конфігів замість одного величезного процесу root-проєкту. -- Запуски тестової обгортки завершуються коротким підсумком `[test] passed|failed|skipped ... in ...`. Власний рядок тривалості Vitest залишається деталізацією для кожного shard. -- Спільний тестовий стан OpenClaw: використовуйте `src/test-utils/openclaw-test-state.ts` з Vitest, коли тесту потрібні ізольовані `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, config fixture, робоча область, каталог агента або сховище auth-profile. -- Допоміжні засоби Process E2E: використовуйте `test/helpers/openclaw-test-instance.ts`, коли process-level E2E-тесту Vitest потрібні запущений Gateway, CLI-середовище, захоплення логів і очищення в одному місці. -- Допоміжні засоби Docker/Bash E2E: доріжки, що source-ять `scripts/lib/docker-e2e-image.sh`, можуть передати `docker_e2e_test_state_shell_b64