diff --git a/docs/uk/ci.md b/docs/uk/ci.md index 93c8edab1..57399d96c 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -2,93 +2,93 @@ read_when: - Потрібно зрозуміти, чому завдання CI виконалося або не виконалося - Ви налагоджуєте перевірку GitHub Actions, яка не проходить - - Ви координуєте запуск або повторний запуск валідації релізу + - Ви координуєте запуск або повторний запуск перевірки релізу - Ви змінюєте диспетчеризацію ClawSweeper або пересилання активності GitHub -summary: Граф завдань CI, гейти області дії, парасольки релізів і локальні еквіваленти команд +summary: Граф завдань CI, перевірки області, релізні парасольки та локальні еквіваленти команд title: Конвеєр CI x-i18n: - generated_at: "2026-05-04T04:57:53Z" + generated_at: "2026-05-04T22:29:59Z" model: gpt-5.5 provider: openai - source_hash: 72959d0feaf1339f01c9da263153fd89cc4727da6f928933819931991222714d + source_hash: 88d0f7f6cd61d550ec399e8250f685929637cd28638e77aa5a5558775767cac6 source_path: ci.md workflow: 16 --- -OpenClaw CI запускається під час кожного push до `main` і кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі напрями, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області та розгортають увесь граф для release candidate і широкої валідації. Android-напрями залишаються опційними через `include_android`. Покриття plugin лише для релізів живе в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch. +OpenClaw CI запускається під час кожного push до `main` і для кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі lanes, коли змінено лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно оминають розумне обмеження scope і розгортають повний граф для release candidates і широкої валідації. Android lanes залишаються opt-in через `include_android`. Release-only покриття plugins живе в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається лише з [`Full Release Validation`](#full-release-validation) або через явний ручний dispatch. ## Огляд pipeline -| Завдання | Призначення | Коли запускається | -| -------------------------------- | --------------------------------------------------------------------------------------------------------- | ---------------------------------- | -| `preflight` | Виявляє зміни лише в docs, змінені області, змінені 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` | Обов’язковий aggregate для швидких security-завдань | Завжди для non-draft push і PR | -| `check-dependencies` | Production Knip dependency-only pass плюс guard allowlist невикористаних файлів | Node-релевантні зміни | -| `build-artifacts` | Збірка `dist/`, Control UI, перевірки built artifacts і reusable downstream artifacts | Node-релевантні зміни | -| `checks-fast-core` | Швидкі Linux-напрями коректності, як-от bundled/plugin-contract/protocol checks | Node-релевантні зміни | -| `checks-fast-contracts-channels` | Sharded перевірки channel contract зі стабільним aggregate check result | Node-релевантні зміни | -| `checks-node-core-test` | Shards тестів Core Node, крім channel, bundled, contract і extension напрямів | Node-релевантні зміни | -| `check` | Sharded еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Node-релевантні зміни | -| `check-additional` | Architecture, sharded boundary/prompt drift, extension guards, package boundary і gateway watch | Node-релевантні зміни | -| `build-smoke` | Smoke-тести built-CLI і startup-memory smoke | Node-релевантні зміни | -| `checks` | Verifier для built-artifact channel tests | Node-релевантні зміни | -| `checks-node-compat-node22` | Збірка сумісності з Node 22 і smoke-напрям | Ручний CI dispatch для релізів | -| `check-docs` | Форматування docs, lint і перевірки broken links | Docs змінено | -| `skills-python` | Ruff + pytest для Skills на Python | Python-skill-релевантні зміни | -| `checks-windows` | Windows-специфічні тести process/path плюс спільні регресії runtime import specifier | Windows-релевантні зміни | -| `macos-node` | macOS TypeScript test lane з використанням спільних built artifacts | macOS-релевантні зміни | -| `macos-swift` | Swift lint, build і tests для macOS app | macOS-релевантні зміни | -| `android` | Android unit tests для обох flavors плюс одна збірка debug APK | Android-релевантні зміни | -| `test-performance-agent` | Щоденна Codex оптимізація повільних тестів після trusted activity | Main CI success або manual dispatch | -| `openclaw-performance` | Щоденні/on-demand звіти продуктивності runtime Kova з mock-provider, deep-profile і GPT 5.4 live lanes | Scheduled і manual dispatch | +| Завдання | Призначення | Коли запускається | +| -------------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------- | +| `preflight` | Виявляє docs-only зміни, змінені scopes, змінені extensions і збирає CI manifest | Завжди для non-draft pushes і PRs | +| `security-scm-fast` | Виявлення private keys і аудит workflow через `zizmor` | Завжди для non-draft pushes і PRs | +| `security-dependency-audit` | Production lockfile audit без залежностей на основі npm advisories | Завжди для non-draft pushes і PRs | +| `security-fast` | Обов’язковий aggregate для швидких security jobs | Завжди для non-draft pushes і PRs | +| `check-dependencies` | Production Knip dependency-only pass плюс guard allowlist для unused files | Node-релевантні зміни | +| `build-artifacts` | Збірка `dist/`, Control UI, built-artifact checks і reusable downstream artifacts | Node-релевантні зміни | +| `checks-fast-core` | Швидкі Linux correctness lanes, як-от bundled/plugin-contract/protocol checks | Node-релевантні зміни | +| `checks-fast-contracts-channels` | Sharded channel contract checks зі стабільним aggregate check result | Node-релевантні зміни | +| `checks-node-core-test` | Core Node test shards, за винятком channel, bundled, contract і extension lanes | Node-релевантні зміни | +| `check` | Sharded еквівалент main local gate: prod types, lint, guards, test types і strict smoke | Node-релевантні зміни | +| `check-additional` | Architecture, sharded boundary/prompt drift, extension guards, package boundary і gateway watch | Node-релевантні зміни | +| `build-smoke` | Built-CLI smoke tests і startup-memory smoke | Node-релевантні зміни | +| `checks` | Verifier для built-artifact channel tests | Node-релевантні зміни | +| `checks-node-compat-node22` | Node 22 compatibility build і smoke lane | Ручний CI dispatch для releases | +| `check-docs` | Форматування docs, lint і broken-link checks | Змінено docs | +| `skills-python` | Ruff + pytest для Python-backed skills | Python-skill-релевантні зміни | +| `checks-windows` | Windows-specific process/path tests плюс shared runtime import specifier regressions | Windows-релевантні зміни | +| `macos-node` | macOS TypeScript test lane із використанням shared built artifacts | macOS-релевантні зміни | +| `macos-swift` | Swift lint, build і tests для macOS app | macOS-релевантні зміни | +| `android` | Android unit tests для обох flavors плюс одна debug APK build | Android-релевантні зміни | +| `test-performance-agent` | Щоденна Codex оптимізація slow-test після trusted activity | Main CI success або manual dispatch | +| `openclaw-performance` | Щоденні/on-demand Kova runtime performance reports із mock-provider, deep-profile і GPT 5.4 live lanes | Scheduled і manual 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` падають швидко, не чекаючи на важчі завдання artifacts і platform matrix. -3. `build-artifacts` виконується паралельно зі швидкими Linux-напрямами, щоб downstream consumers могли стартувати одразу, щойно спільна збірка готова. -4. Важчі platform і runtime напрями розгортаються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +1. `preflight` вирішує, які lanes взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи важчих artifact і platform matrix jobs. +3. `build-artifacts` перекривається зі швидкими Linux lanes, щоб downstream consumers могли стартувати, щойно shared build буде готовий. +4. Важчі platform і runtime lanes розгортаються після цього: `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 також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно повідомляють про звичайні shard failures, але не стають у чергу після того, як увесь workflow уже витіснено. Автоматичний concurrency key CI має версію (`CI-v7-*`), тож GitHub-side zombie у старій queue group не може безстроково блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують runs, що вже виконуються. +GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє до того самого PR або ref `main`. Вважайте це шумом CI, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все ще повідомляють звичайні shard failures, але не стають у чергу після того, як увесь workflow уже був superseded. Automatic CI concurrency key версіонований (`CI-v7-*`), тому GitHub-side zombie в старій queue group не може нескінченно блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs. -## Область і маршрутизація +## Scope і routing -Логіка області живе в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби кожна scoped area змінилася. +Логіка scope живе в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Manual dispatch пропускає changed-scope detection і змушує preflight manifest поводитися так, ніби кожну scoped area було змінено. -- **Зміни CI workflow** валідовують Node CI graph плюс workflow linting, але самі по собі не примушують запускати Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source. -- **CI routing-only edits, selected cheap core-test fixture edits і narrow plugin contract helper/test-routing edits** використовують fast Node-only manifest path: `preflight`, security і одне завдання `checks-fast-core`. Цей path пропускає build artifacts, Node 22 compatibility, channel contracts, full core shards, bundled-plugin shards і additional guard matrices, коли зміна обмежена routing або helper surfaces, які fast task безпосередньо перевіряє. -- **Windows Node checks** scoped до Windows-специфічних process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цей lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes. +- **Редагування CI workflow** валідують Node CI graph плюс workflow linting, але самі по собі не примушують Windows, Android або macOS native builds; ці platform lanes залишаються scoped до platform source changes. +- **CI routing-only edits, вибрані дешеві core-test fixture edits і вузькі plugin contract helper/test-routing edits** використовують швидкий Node-only manifest path: `preflight`, security і одне завдання `checks-fast-core`. Цей path пропускає build artifacts, Node 22 compatibility, channel contracts, full core shards, bundled-plugin shards і additional guard matrices, коли зміна обмежена routing або helper surfaces, які fast task перевіряє напряму. +- **Windows Node checks** scoped до Windows-specific process/path wrappers, npm/pnpm/UI runner helpers, package manager config і CI workflow surfaces, які виконують цю lane; непов’язані source, plugin, install-smoke і test-only changes залишаються на Linux Node lanes. -Найповільніші сімейства Node test розділено або збалансовано, щоб кожне завдання залишалося невеликим без надмірного резервування runners: channel contracts запускаються як три weighted shards, core unit fast/support lanes запускаються окремо, core runtime infra розділено між state і process/config shards, auto-reply запускається як balanced workers (із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/server configs розділено між chat/auth/model/http-plugin/runtime/startup lanes замість очікування built artifacts. Broad browser, QA, media і miscellaneous plugin tests використовують власні dedicated Vitest configs замість спільного plugin catch-all. Include-pattern shards записують timing entries з використанням CI shard name, тож `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard list розподілено смугами на чотири matrix shards, кожен із яких паралельно запускає selected independent guards і друкує per-check timings, включно з `pnpm prompt:snapshots:check`, щоб Codex runtime happy-path prompt drift був прив’язаний до PR, який його спричинив. Gateway watch, channel tests і core support-boundary shard виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрано. +Найповільніші сімейства Node tests розділені або збалансовані так, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts виконуються як три weighted shards, core unit fast/support lanes виконуються окремо, core runtime infra розділено між state і process/config shards, auto-reply запускається як balanced workers (із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards), а agentic gateway/server configs розділено між chat/auth/model/http-plugin/runtime/startup lanes замість очікування на built artifacts. Broad browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість shared plugin catch-all. Include-pattern shards записують timing entries з використанням CI shard name, тому `.artifacts/vitest-shard-timings.json` може відрізнити whole config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard list розподілено по чотирьох matrix shards, кожен із яких паралельно запускає вибрані independent guards і друкує per-check timings, включно з `pnpm prompt:snapshots:check`, щоб Codex runtime happy-path prompt drift був прив’язаний до PR, який його спричинив. 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 з SMS/call-log BuildConfig flags, уникаючи дублювання 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, водночас уникаючи duplicate debug APK packaging job на кожному Android-релевантному push. -Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, pinned до найновішої версії Knip, із вимкненим minimum release age pnpm для встановлення `dlx`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий непереглянутий unused file або залишає застарілий allowlist entry, зберігаючи при цьому intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може розв’язати статично. +Shard `check-dependencies` запускає `pnpm deadcode:dependencies` (production Knip dependency-only pass, pinned до найновішої версії Knip, із вимкненим pnpm minimum release age для `dlx` install) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip з `scripts/deadcode-unused-files.allowlist.mjs`. Guard unused-file падає, коли PR додає новий unreviewed unused file або залишає stale allowlist entry, водночас зберігаючи intentional dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично resolve. -## Пересилання активності ClawSweeper +## Переспрямування активності ClawSweeper -`.github/workflows/clawsweeper-dispatch.yml` — це target-side bridge від активності repository OpenClaw до ClawSweeper. Він не checkout і не виконує untrusted pull request code. Workflow створює GitHub App token з `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім надсилає компактні payloads `repository_dispatch` до `openclaw/clawsweeper`. +`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge з активності репозиторію OpenClaw до ClawSweeper. Він не виконує checkout і не запускає ненадійний pull request code. Workflow створює GitHub App token із `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім dispatches compact `repository_dispatch` payloads до `openclaw/clawsweeper`. -Workflow має чотири напрями: +Workflow має чотири lanes: - `clawsweeper_item` для точних issue і pull request review requests; -- `clawsweeper_comment` для явних команд ClawSweeper у issue comments; -- `clawsweeper_commit_review` для commit-level review requests на push до `main`; +- `clawsweeper_comment` для явних команд ClawSweeper в issue comments; +- `clawsweeper_commit_review` для commit-level review requests на `main` pushes; - `github_activity` для загальної GitHub activity, яку агент ClawSweeper може inspect. -Lane `github_activity` пересилає лише нормалізовані metadata: event type, action, actor, repository, item number, URL, title, state і short excerpts для comments або reviews, коли вони наявні. Він навмисно не пересилає повне webhook body. Receiving workflow у `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який надсилає normalized event до OpenClaw Gateway hook для агента ClawSweeper. +Lane `github_activity` пересилає лише normalized metadata: event type, action, actor, repository, item number, URL, title, state і короткі excerpts для comments або reviews, якщо вони є. Він навмисно уникає пересилання повного webhook body. Receiving workflow в `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який публікує normalized event до hook OpenClaw Gateway для агента ClawSweeper. -Загальна активність — це спостереження, а не delivery-by-default. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли подія є несподіваною, actionable, risky або operationally useful. Routine opens, edits, bot churn, duplicate webhook noise і normal review traffic мають приводити до `NO_REPLY`. +Загальна активність є observation, а не delivery-by-default. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли event є несподіваним, actionable, risky або operationally useful. Routine opens, edits, bot churn, duplicate webhook noise і normal review traffic мають призводити до `NO_REPLY`. -Сприймайте GitHub titles, comments, bodies, review text, branch names і commit messages як untrusted data на всьому цьому шляху. Це input для summarization і triage, а не інструкції для workflow або agent runtime. +Вважайте GitHub titles, comments, bodies, review text, branch names і commit messages ненадійними даними на всьому цьому path. Вони є input для summarization і triage, а не інструкціями для workflow або agent runtime. ## Ручні dispatches -Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну не-Android scoped lane: шарди Linux Node, шарди bundled-plugin, контракти каналів, сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python Skills, Windows, macOS і Control UI i18n. Автономні ручні запуски CI виконують лише Android із `include_android=true`; повна release umbrella вмикає Android, передаючи `include_android=true`. Статичні перевірки передрелізу Plugin, релізний шард `agentic-plugins`, повний пакетний sweep розширень і Docker lanes для передрелізу Plugin виключені з CI. Набір Docker-перевірок передрелізу запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate release-validation. +Ручні dispatch CI запускають той самий граф завдань, що й звичайний CI, але примусово вмикають кожну scoped lane не для Android: Linux Node shards, bundled-Plugin shards, контракти каналів, сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python Skills, Windows, macOS і Control UI i18n. Окремі ручні dispatch CI запускають лише Android з `include_android=true`; повна release-umbrella вмикає Android, передаючи `include_android=true`. Передвипускні статичні перевірки Plugin, release-only shard `agentic-plugins`, повний пакетний sweep розширень і передвипускні Docker lanes для Plugin виключено з CI. Передвипускний Docker suite запускається лише тоді, коли `Full Release Validation` dispatch окремого workflow `Plugin Prerelease` з увімкненим release-validation gate. -Ручні запуски використовують унікальну групу concurrency, щоб повний набір release-candidate не скасовувався іншим push або PR-запуском на тому самому ref. Необов’язковий input `target_ref` дає змогу довіреному викликачеві запустити цей граф для гілки, тегу або повного SHA коміту, використовуючи файл workflow з вибраного dispatch ref. +Ручні запуски використовують унікальну concurrency group, тому повний suite реліз-кандидата не скасовується іншим push або PR run на тому самому ref. Необовʼязковий input `target_ref` дає змогу довіреному виклику запустити цей граф для branch, tag або повного commit SHA, використовуючи файл workflow з вибраного dispatch ref. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -96,17 +96,17 @@ 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 -| Ранер | Завдання | -| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `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; 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-збірки 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` | +| Runner | Завдання | +| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ubuntu-24.04` | `preflight`, швидкі security jobs і aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки protocol/contract/bundled, sharded перевірки контрактів каналів, shards `check`, окрім lint, shards і aggregates `check-additional`, aggregate verifiers тестів Node, перевірки документації, Python Skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла ставати в чергу раніше | +| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, легші shards розширень, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux Node test shards, bundled Plugin test shards, `android` | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо CPU-sensitive, щоб 8 vCPU коштували більше, ніж заощаджували); install-smoke Docker builds (час очікування в черзі для 32-vCPU коштував більше, ніж заощаджував) | +| `blacksmith-16vcpu-windows-2025` | `checks-windows` | +| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; forks fallback до `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks fallback до `macos-latest` | ## Локальні еквіваленти @@ -137,7 +137,7 @@ pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.jso ## Продуктивність OpenClaw -`OpenClaw Performance` — це workflow продуктивності продукту/середовища виконання. Він щодня запускається на `main` і може запускатися вручну: +`OpenClaw Performance` — це workflow продуктивності продукту/runtime. Він запускається щодня на `main` і може запускатися вручну: ```bash gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3 @@ -145,31 +145,31 @@ gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 gh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3 ``` -Ручний dispatch зазвичай benchmark-ить workflow ref. Установіть `target_ref`, щоб benchmark-ити релізний тег або іншу гілку з поточною реалізацією workflow. Опубліковані шляхи звітів і latest pointers індексуються за протестованим ref, а кожен `index.md` записує протестовані ref/SHA, workflow ref/SHA, Kova ref, profile, режим автентифікації lane, модель, кількість повторів і фільтри сценаріїв. +Ручний dispatch зазвичай benchmark workflow ref. Установіть `target_ref`, щоб benchmark release tag або іншу branch із поточною реалізацією workflow. Опубліковані paths звітів і latest pointers keyed by tested ref, а кожен `index.md` фіксує tested ref/SHA, workflow ref/SHA, Kova ref, profile, lane auth mode, model, repeat count і scenario filters. Workflow встановлює OCM із pinned release і Kova з `openclaw/Kova` на pinned input `kova_ref`, а потім запускає три lanes: -- `mock-provider`: діагностичні сценарії Kova проти runtime локальної збірки з детермінованою фальшивою OpenAI-compatible автентифікацією. -- `mock-deep-profile`: профілювання CPU/heap/trace для startup, gateway і hotspots agent-turn. -- `live-gpt54`: реальний agent turn OpenAI `openai/gpt-5.4`, який пропускається, коли `OPENAI_API_KEY` недоступний. +- `mock-provider`: діагностичні scenarios Kova проти local-build runtime з deterministic fake OpenAI-compatible auth. +- `mock-deep-profile`: CPU/heap/trace profiling для startup, gateway і hotspots agent-turn. +- `live-gpt54`: справжній turn агента OpenAI `openai/gpt-5.4`, пропускається, коли `OPENAI_API_KEY` недоступний. -Lane mock-provider також запускає нативні для OpenClaw source probes після проходу Kova: вимірювання часу завантаження Gateway і пам’яті для випадків запуску default, hook і 50-plugin; повторювані mock-OpenAI hello-цикли `channel-chat-baseline`; і команди запуску CLI проти завантаженого Gateway. Markdown-зведення source probe міститься в `source/index.md` у bundle звіту, поруч із raw JSON. +Lane mock-provider також запускає OpenClaw-native source probes після проходу Kova: gateway boot timing і memory для default, hook і startup cases із 50 Plugin; повторювані mock-OpenAI цикли hello `channel-chat-baseline`; і CLI startup commands проти booted gateway. Markdown summary source probe розміщено в `source/index.md` у bundle звіту, поруч із raw JSON. -Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і artifacts source-probe в `openclaw/clawgrit-reports` під `openclaw-performance//-//`. Поточний pointer tested-ref записується як `openclaw-performance//latest-.json`. +Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також commits `report.json`, `report.md`, bundles, `index.md` і source-probe artifacts у `openclaw/clawgrit-reports` під `openclaw-performance//-//`. Поточний pointer tested-ref записується як `openclaw-performance//latest-.json`. ## Повна валідація релізу -`Full Release Validation` — це ручний umbrella workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` із цією ціллю, запускає `Plugin Prerelease` для релізних доказів plugin/package/static/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, Docker release-path suites, 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`, щоб повторно запустити ту саму lane пакета Telegram проти опублікованого npm-пакета. +`Full Release Validation` — це ручний umbrella workflow для «запустити все перед релізом». Він приймає branch, tag або повний commit SHA, dispatch ручний workflow `CI` із цією target, dispatch `Plugin Prerelease` для release-only proof Plugin/package/static/Docker і dispatch `OpenClaw Release Checks` для install smoke, package acceptance, cross-OS package checks, QA Lab parity, Matrix і Telegram lanes. Stable/default runs тримають exhaustive live/E2E і Docker release-path coverage за `run_release_soak=true`; `release_profile=full` примусово вмикає це soak coverage, щоб broad advisory validation залишалася broad. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` з release checks. Після publishing передайте `npm_telegram_package_spec`, щоб rerun тієї самої Telegram package lane проти published npm package. -Див. [Повна валідація релізу](/uk/reference/full-release-validation) для -матриці етапів, точних назв завдань workflow, відмінностей profile, artifacts і +Див. [Повну валідацію релізу](/uk/reference/full-release-validation) для +stage matrix, точних назв jobs workflow, відмінностей profile, artifacts і focused rerun handles. -`OpenClaw Release Publish` — це ручний mutating release workflow. Запускайте його -з `release/YYYY.M.D` або `main` після того, як релізний тег існує, і після того, -як preflight OpenClaw npm успішно завершився. Він перевіряє `pnpm plugins:sync:check`, -запускає `Plugin NPM Release` для всіх publishable plugin packages, запускає -`Plugin ClawHub Release` для того самого release SHA і лише потім запускає +`OpenClaw Release Publish` — це ручний mutating release workflow. Dispatch його +з `release/YYYY.M.D` або `main` після того, як release tag існує, і після того, як +OpenClaw npm preflight успішно завершився. Він перевіряє `pnpm plugins:sync:check`, +dispatch `Plugin NPM Release` для всіх publishable packages Plugin, dispatch +`Plugin ClawHub Release` для того самого release SHA, і лише потім dispatch `OpenClaw NPM Release` зі збереженим `preflight_run_id`. ```bash @@ -180,41 +180,45 @@ gh workflow run openclaw-release-publish.yml \ -f npm_dist_tag=beta ``` -Для pinned commit proof на гілці, що швидко рухається, використовуйте helper замість +Для proof pinned commit на branch, що швидко змінюється, використовуйте helper замість `gh workflow run ... --ref main -f ref=`: ```bash pnpm ci:full-release --sha ``` -GitHub workflow dispatch refs мають бути гілками або тегами, а не raw commit SHAs. Helper -пушить тимчасову гілку `release-ci/-...` на цільовому SHA, -запускає `Full Release Validation` з цього pinned ref, перевіряє, що кожен дочірній -workflow `headSha` відповідає цілі, і видаляє тимчасову гілку після завершення -запуску. Umbrella verifier також падає, якщо будь-який дочірній workflow виконувався на +GitHub workflow dispatch refs мають бути branches або tags, а не raw commit SHAs. +Helper pushes тимчасову branch `release-ci/-...` на target SHA, +dispatch `Full Release Validation` з цього pinned ref, перевіряє, що кожен child +workflow `headSha` збігається з target, і видаляє тимчасову branch після завершення +run. Umbrella verifier також fails, якщо будь-який child workflow запустився на іншому SHA. -`release_profile` керує широтою live/provider, що передається до перевірок випуску. Ручні workflows випуску за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли навмисно потрібна широка консультативна матриця provider/media. +`release_profile` керує широтою live/provider, що передається до перевірок випуску. Ручні робочі процеси випуску за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли ви навмисно хочете широку консультативну матрицю provider/media. `run_release_soak` керує тим, чи перевірки стабільного/типового випуску запускають вичерпний live/E2E та Docker soak для шляху випуску; `full` примусово вмикає soak. - `minimum` залишає найшвидші критичні для випуску лінії OpenAI/core. - `stable` додає стабільний набір provider/backend. - `full` запускає широку консультативну матрицю provider/media. -Парасолька записує ідентифікатори запущених дочірніх прогонів, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх прогонів і додає таблиці найповільніших завдань для кожного дочірнього прогону. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське завдання перевірки, щоб оновити результат парасольки та підсумок часу. +Парасольковий робочий процес записує ідентифікатори запущених дочірніх виконань, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх виконань і додає таблиці найповільніших завдань для кожного дочірнього виконання. Якщо дочірній робочий процес перезапущено і він стає зеленим, перезапустіть лише батьківське завдання перевірки, щоб оновити результат парасолькового робочого процесу та підсумок часу. -Для відновлення і `Full Release Validation`, і `OpenClaw Release Checks` приймають `rerun_group`. Використовуйте `all` для release candidate, `ci` лише для звичайного повного дочірнього CI, `plugin-prerelease` лише для дочірнього попереднього випуску Plugin, `release-checks` для кожного дочірнього випуску або вужчу групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольці. Це утримує повторний запуск невдалої 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` використовує довірений ref workflow, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і до Docker workflow live/E2E шляху випуску, і до shard приймання пакета. Це зберігає байти пакета узгодженими між release boxes і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. +`OpenClaw Release Checks` використовує довірене посилання робочого процесу, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт до cross-OS перевірок і Package Acceptance, а також до live/E2E Docker-робочого процесу шляху випуску, коли запускається soak-покриття. Це зберігає байти пакета узгодженими між коробками випуску та уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. -Дублікати прогонів `Full Release Validation` для `ref=main` і `rerun_group=all` заміщують старішу парасольку. Батьківський монітор скасовує будь-який дочірній workflow, який він уже запустив, коли батьківський прогін скасовано, тому новіша валідація main не чекає за застарілим двогодинним прогоном release-check. Валідація release branch/tag і сфокусовані групи повторного запуску зберігають `cancel-in-progress: false`. +Дублікати виконань `Full Release Validation` для `ref=main` і `rerun_group=all` +замінюють старіший парасольковий робочий процес. Батьківський монітор скасовує будь-який дочірній робочий процес, який +він уже запустив, коли батьківський скасовано, тому новіша перевірка main +не чекає за застарілим двогодинним виконанням release-check. Перевірка гілки/тегу випуску +та цільові групи перезапуску зберігають `cancel-in-progress: false`. -## Live та E2E-шарди +## Live та E2E шарди -Дочірній release live/E2E зберігає широке native покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання: +Дочірній release live/E2E зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані шарди через `scripts/test-live-shard.mjs` замість одного послідовного завдання: - `native-live-src-agents` - `native-live-src-gateway-core` -- provider-filtered завдання `native-live-src-gateway-profiles` +- завдання `native-live-src-gateway-profiles` з фільтрацією за provider - `native-live-src-gateway-backends` - `native-live-test` - `native-live-extensions-a-k` @@ -222,59 +226,61 @@ workflow `headSha` відповідає цілі, і видаляє тимчас - `native-live-extensions-openai` - `native-live-extensions-o-z-other` - `native-live-extensions-xai` -- розділені audio/video media шарди та provider-filtered music шарди +- розділені audio/video шарди media та шарди music з фільтрацією за provider -Це зберігає те саме покриття файлів, водночас спрощуючи повторний запуск і діагностику повільних збоїв live provider. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків. +Це зберігає те саме файлове покриття, водночас спрощуючи перезапуск і діагностику повільних збоїв live provider. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових перезапусків. -Native live media шарди виконуються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють бінарні файли перед налаштуванням. Тримайте Docker-backed live suites на звичайних Blacksmith runners — container jobs є неправильним місцем для запуску вкладених Docker tests. +Нативні live media шарди запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному робочим процесом `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють ці бінарні файли перед налаштуванням. Тримайте Docker-backed live набори на звичайних Blacksmith runners — контейнерні завдання є неправильним місцем для запуску вкладених Docker-тестів. -Docker-backed live model/backend шарди використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Live release workflow один раз збирає і публікує цей образ, після чого Docker live model, provider-sharded Gateway, CLI backend, ACP bind і Codex harness шарди запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Gateway Docker шарди мають явні script-level обмеження `timeout`, нижчі за timeout завдання workflow, щоб завислий контейнер або шлях очищення швидко завершувався з помилкою, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну source Docker target, release run налаштовано неправильно, і він марнуватиме wall clock на дубльовані збірки образів. +Docker-backed live model/backend шарди використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Live release workflow збирає та пушить цей образ один раз, після чого Docker live model, provider-sharded gateway, CLI backend, ACP bind і Codex harness шарди запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Docker шарди Gateway мають явні обмеження `timeout` на рівні скриптів нижче за тайм-аут завдання робочого процесу, щоб завислий контейнер або шлях очищення швидко завершувався з помилкою, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну source Docker target, виконання випуску налаштоване неправильно і марнуватиме реальний час на дублікати збірок образу. -## Приймання пакета +## Package Acceptance -Використовуйте `Package Acceptance`, коли питання звучить так: "чи працює цей інстальований пакет OpenClaw як продукт?" Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як приймання пакета перевіряє один tarball через той самий Docker E2E harness, який користувачі задіюють після встановлення або оновлення. +Використовуйте `Package Acceptance`, коли питання таке: «чи працює цей інстальований пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі виконують після встановлення або оновлення. ### Завдання -1. `resolve_package` виконує checkout `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 step summary. -2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Reusable workflow завантажує цей артефакт, валідує інвентар tarball, готує Docker images package-digest за потреби та запускає вибрані Docker lanes проти цього пакета замість пакування workflow checkout. Коли профіль вибирає кілька цільових `docker_lanes`, reusable workflow готує пакет і спільні образи один раз, а потім розгортає ці lanes як паралельні цільові Docker jobs з унікальними артефактами. -3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він виконується, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance розв’язав пакет; автономний Telegram dispatch усе ще може встановлювати опубліковану npm spec. -4. `summary` провалює workflow, якщо розв’язання пакета, Docker acceptance або необов’язкова Telegram lane завершилися з помилкою. +1. `resolve_package` виконує checkout `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить джерело, посилання робочого процесу, посилання пакета, версію, SHA-256 і профіль у підсумку кроку GitHub. +2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний робочий процес завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує package-digest Docker-образи і запускає вибрані Docker лінії проти цього пакета замість пакування checkout робочого процесу. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний робочий процес готує пакет і спільні образи один раз, а потім розгортає ці лінії як паралельні цільові Docker-завдання з унікальними артефактами. +3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance розв’язав його; окремий dispatch Telegram усе ще може встановити опубліковану npm-специфікацію. +4. `summary` завершує робочий процес з помилкою, якщо розв’язання пакета, Docker acceptance або необов’язкова лінія Telegram завершилися невдало. ### Джерела кандидатів -- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну release version OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих prerelease/stable. -- `source=ref` пакує довірену гілку, tag або повний commit SHA `package_ref`. Resolver fetches OpenClaw branches/tags, перевіряє, що вибраний коміт досяжний з історії гілки репозиторію або release tag, встановлює залежності у detached worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. -- `source=url` завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим. -- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його варто надати для зовнішньо поширених артефактів. +- `source=npm` приймає лише `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` — це довірений код workflow/harness, який виконує тест. `package_ref` — це source commit, який пакується, коли `source=ref`. Це дає поточному test harness змогу валідувати старіші довірені source commits без запуску старої workflow logic. +Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код робочого процесу/harness, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточному тестовому harness перевіряти старіші довірені коміти вихідного коду без запуску старої логіки робочого процесу. -### Профілі suite +### Профілі наборів - `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 chunks release-path з OpenWebUI +- `full` — повні Docker chunks шляху випуску з OpenWebUI - `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom` -Профіль `package` використовує offline plugin coverage, щоб валідація опублікованого пакета не залежала від live доступності ClawHub. Необов’язкова Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm spec збережено для автономних dispatches. +Профіль `package` використовує offline plugin покриття, щоб перевірка опублікованого пакета не залежала від live доступності ClawHub. Необов’язкова лінія Telegram повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації зберігається для окремих dispatch. -Про спеціальну політику тестування оновлень і Plugin, включно з локальними командами, Docker lanes, inputs Package Acceptance, release defaults і triage збоїв, див. [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins). +Для спеціальної політики тестування оновлень і plugin, включно з локальними командами, +Docker лініями, входами Package Acceptance, типовими значеннями випуску та тріажем збоїв, +див. [Тестування оновлень і plugin](/uk/help/testing-updates-plugins). -Release checks викликають Package Acceptance з `source=artifact`, підготовленим артефактом release package, `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`. Це тримає package migration, update, stale-plugin-dependency cleanup, configured-plugin install repair, offline plugin, plugin-update і Telegram proof на тому самому розв’язаному package tarball. Установіть `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму матрицю проти вже доставленого npm package замість SHA-built artifact. 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` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback published baseline, за замовчуванням `openclaw@latest`; команди повторного запуску failed-lane зберігають цю baseline. Установіть `published_upgrade_survivor_baselines=all-since-2026.4.23`, щоб розширити Full Release CI на кожен stable npm release від `2026.4.23` до `latest`; `release-history` залишається доступним для ручного ширшого sampling зі старішим pre-date anchor. Установіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для Feishu config, preserved 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`, коли питання полягає в exhaustive 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 із вбудованим рецептом команди `openclaw config set`, записує кроки рецепта в `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`, щоб proof встановлення і Gateway залишався на GPT-5 test model, уникаючи 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'` і `telegram_mode=mock-openai`. Це тримає перевірку міграції пакета, оновлення, очищення застарілих залежностей plugin, відновлення встановлення налаштованого plugin, offline plugin, plugin-update і Telegram на тому самому розв’язаному tarball пакета. Встановіть `package_acceptance_package_spec` у Full Release Validation або OpenClaw Release Checks, щоб запустити ту саму матрицю проти вже доставленого npm-пакета замість артефакту, зібраного з SHA. Cross-OS release checks все ще покривають специфічну для ОС поведінку onboarding, installer і platform; перевірка продукту package/update має починатися з Package Acceptance. Docker лінія `published-upgrade-survivor` перевіряє один опублікований baseline пакета за запуск у блокувальному шляху випуску. У Package Acceptance розв’язаний tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback опублікований baseline, за замовчуванням `openclaw@latest`; команди перезапуску невдалих ліній зберігають цей baseline. Full Release Validation з `run_release_soak=true` або `release_profile=full` встановлює `published_upgrade_survivor_baselines=all-since-2026.4.23` і `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити перевірку на всі стабільні npm-випуски від `2026.4.23` до `latest` і issue-shaped fixtures для конфігурації Feishu, збережених файлів bootstrap/persona, встановлень налаштованих OpenClaw plugin, tilde шляхів журналів і застарілих коренів залежностей legacy plugin. Окремий робочий процес `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 fresh лінії також перевіряють, що встановлений пакет може імпортувати browser-control override з сирого абсолютного Windows-шляху. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли його встановлено, інакше `openai/gpt-5.4`, тому install і gateway proof залишаються на тестовій моделі GPT-5, уникаючи типових значень GPT-4.x. -### Вікна застарілої сумісності +### Вікна legacy сумісності -Package Acceptance має обмежені вікна legacy-compatibility для вже опублікованих 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` можуть вказувати на файли, пропущені в tarball; -- `doctor-switch` може пропустити subcase збереження `gateway install --wrapper`, коли package не exposes цей flag; -- `update-channel-switch` може обрізати відсутні `pnpm.patchedDependencies` з fake git fixture, похідної від tarball, і може логувати відсутній persisted `update.channel`; -- plugin smokes можуть читати legacy install-record locations або приймати відсутнє marketplace install-record persistence; -- `plugin-update` може дозволяти config metadata migration, усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними. +- відомі приватні QA entries у `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені в tarball; +- `doctor-switch` може пропустити підвипадок збереження `gateway install --wrapper`, коли пакет не експонує цей прапорець; +- `update-channel-switch` може вилучати відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і може логувати відсутній збережений `update.channel`; +- plugin smokes можуть читати legacy розташування install-record або приймати відсутність збереження marketplace install-record; +- `plugin-update` може дозволяти міграцію metadata конфігурації, водночас усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними. -Опублікований package `2026.4.26` також може попереджати про local build metadata stamp files, які вже були доставлені. Пізніші packages мають відповідати modern contracts; ті самі умови завершуються помилкою замість warn або skip. +Опублікований пакет `2026.4.26` також може попереджати про локальні stamp-файли build metadata, які вже були доставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови завершуються помилкою замість попередження або пропуску. ### Приклади @@ -317,151 +323,151 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Під час налагодження невдалого запуску перевірки прийнятності пакета починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали ліній, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker-ліній замість повторного запуску повної валідації релізу. +Під час налагодження невдалого запуску package acceptance починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lane, таймінги фаз і команди повторного запуску. Віддавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes, а не повторному запуску повної валідації релізу. -## Димова перевірка встановлення +## Інсталяційний smoke-тест -Окремий workflow `Install Smoke` повторно використовує той самий скрипт визначення області через власне завдання `preflight`. Він розділяє димове покриття на `run_fast_install_smoke` і `run_full_install_smoke`. +Окремий робочий процес `Install Smoke` повторно використовує той самий scope-скрипт через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. -- **Швидкий шлях** запускається для pull request, що торкаються Docker/пакетних поверхонь, змін пакета/маніфесту вбудованого plugin або поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker-димові завдання. Зміни лише вихідного коду вбудованого plugin, редагування лише тестів і редагування лише документації не резервують Docker-воркерів. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI-димову перевірку видалення agents спільного робочого простору, запускає container gateway-network e2e, перевіряє аргумент збирання вбудованого розширення та запускає обмежений Docker-профіль вбудованого plugin із сукупним тайм-аутом команди 240 секунд (Docker-запуск кожного сценарію обмежується окремо). -- **Повний шлях** залишає QR-встановлення пакета та Docker/update-покриття інсталятора для нічних запланованих запусків, ручних dispatch, workflow-call перевірок релізу та pull request, які справді торкаються поверхонь інсталятора/пакета/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR-димовий образ кореневого Dockerfile для цільового SHA, потім запускає QR-встановлення пакета, димові перевірки кореневого Dockerfile/Gateway, димові перевірки інсталятора/оновлення та швидкий Docker E2E для вбудованого plugin як окремі завдання, щоб робота інсталятора не чекала за димовими перевірками кореневого образу. +- **Швидкий шлях** запускається для pull request, які змінюють поверхні Docker/пакетів, зміни пакетів/маніфестів bundled plugin або поверхні ядра plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише вихідного коду bundled plugin, зміни лише тестів і зміни лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає smoke-тест CLI для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє аргумент збірки bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним таймаутом команди 240 секунд (Docker-запуск кожного сценарію обмежується окремо). +- **Повний шлях** зберігає QR package install і installer Docker/update покриття для нічних запланованих запусків, ручних dispatch, workflow-call release checks і pull request, які справді торкаються поверхонь installer/package/Docker. У повному режимі install-smoke готує або повторно використовує один GHCR-образ root Dockerfile smoke для цільового SHA, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий bundled-plugin Docker E2E як окремі завдання, щоб робота installer не чекала за root image smokes. -Пуші в `main` (включно з merge commit) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття на push, workflow зберігає швидку Docker-димову перевірку й залишає повну димову перевірку встановлення для нічної або релізної валідації. +Пуші в `main` (включно з merge-комітами) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття під час push, робочий процес залишає швидкий Docker smoke і передає повний install smoke нічному запуску або валідації релізу. -Повільна Bun global install image-provider димова перевірка окремо керується `run_bun_global_install_smoke`. Вона запускається за нічним розкладом і з workflow перевірок релізу, а ручні dispatch `Install Smoke` можуть увімкнути її, але pull request і пуші в `main` - ні. QR і Docker-тести інсталятора зберігають власні Dockerfile, зосереджені на встановленні. +Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з робочого процесу release checks, а ручні dispatch `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` не роблять цього. QR і installer Docker-тести зберігають власні Dockerfile, орієнтовані на інсталяцію. ## Локальний Docker E2E `pnpm test:docker:all` попередньо збирає один спільний образ live-test, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: -- базовий runner Node/Git для ліній installer/update/plugin-dependency; -- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ліній. +- чистий Node/Git runner для installer/update/plugin-dependency lanes; +- функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних lanes. -Визначення 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`. +Визначення Docker lane розміщені в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для кожної lane за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`. -### Налаштування +### Параметри налаштування | Змінна | Типово | Призначення | -| ------------------------------------- | ------- | --------------------------------------------------------------------------------------------- | -| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів main-pool для звичайних ліній. | -| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів tail-pool, чутливих до провайдера. | -| `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 | Затримка між стартами ліній, щоб уникнути штормів створення 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 могли відтворити одну невдалу лінію. | +| -------------------------------------- | ------- | --------------------------------------------------------------------------------------------- | +| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних lanes. | +| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів tail-пулу, чутливого до провайдерів. | +| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Ліміт одночасних live lanes, щоб провайдери не throttled. | +| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Ліміт одночасних lanes для npm install. | +| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Ліміт одночасних multi-service lanes. | +| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами lanes, щоб уникнути хвиль create у Docker daemon; задайте `0`, щоб вимкнути затримку. | +| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний таймаут на lane (120 хвилин); вибрані live/tail lanes використовують жорсткіші обмеження. | +| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` друкує план планувальника без запуску lanes. | +| `OPENCLAW_DOCKER_ALL_LANES` | unset | Список точних lanes через кому; пропускає cleanup smoke, щоб агенти могли відтворити одну невдалу lane. | -Лінія, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальні сукупні preflight-перевірки перевіряють Docker, видаляють застарілі OpenClaw E2E-контейнери, виводять статус активних ліній, зберігають таймінги ліній для впорядкування longest-first і за замовчуванням припиняють планування нових pooled ліній після першого збою. +Lane, важча за свій ефективний ліміт, все одно може стартувати з порожнього пулу, а потім працює сама, доки не звільнить місткість. Локальні сукупні preflight перевіряють Docker, видаляють застарілі OpenClaw E2E-контейнери, виводять статус активних lanes, зберігають таймінги lanes для впорядкування longest-first і за замовчуванням зупиняють планування нових pooled lanes після першої помилки. -### Повторно використовуваний live/E2E workflow +### Багаторазовий live/E2E робочий процес -Повторно використовуваний live/E2E workflow запитує `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, лінії та облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і зведення. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує artifact пакета з поточного запуску, або завантажує artifact пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає й публікує package-digest-tagged bare/functional GHCR Docker E2E образи через Docker layer cache Blacksmith, коли план потребує ліній із установленим пакетом; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest образи замість повторної збірки. Pull Docker-образів повторюється з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий потік registry/cache швидко повторився, а не спожив більшість критичного шляху CI. +Багаторазовий live/E2E робочий процес запитує `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, lane і облікових даних потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і зведення. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає та пушить bare/functional GHCR Docker E2E-образи з тегом package digest через Docker layer cache Blacksmith, коли план потребує lanes із встановленим пакетом; і повторно використовує передані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest образи замість повторної збірки. Завантаження Docker-образів повторюються з обмеженим 180-секундним таймаутом на спробу, щоб завислий registry/cache stream швидко повторювався, а не забирав більшість критичного шляху CI. -### Фрагменти релізного шляху +### Частини release-path -Релізне Docker-покриття запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk підтягував лише потрібний йому тип образу й виконував кілька ліній через той самий зважений планувальник: +Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний тип образу й виконував кілька lanes через той самий зважений планувальник: - `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. Псевдонім лінії `install-e2e` залишається сукупним ручним псевдонімом повторного запуску для обох provider installer ліній. +Поточні 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` залишаються aggregate plugin/runtime aliases. Lane alias `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes. -OpenWebUI включається в `plugins-runtime-services`, коли повне release-path покриття запитує його, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Лінії оновлення вбудованих каналів повторюють спробу один раз для тимчасових npm мережевих збоїв. +OpenWebUI включається в `plugins-runtime-services`, коли повне release-path coverage запитує його, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Bundled-channel update lanes повторюють спробу один раз у разі тимчасових npm network failures. -Кожен chunk завантажує `.artifacts/docker-tests/` із журналами ліній, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних ліній і командами повторного запуску для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість chunk jobs, що обмежує налагодження невдалих ліній одним цільовим Docker-завданням і готує, завантажує або повторно використовує artifact пакета для цього запуску; якщо вибрана лінія є live Docker-лінією, цільове завдання збирає live-test образ локально для цього повторного запуску. Згенеровані для кожної лінії команди GitHub повторного запуску включають `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, щоб невдала лінія могла повторно використати точний пакет і образи з невдалого запуску. +Кожен chunk завантажує `.artifacts/docker-tests/` з журналами lanes, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями slow-lane і командами повторного запуску для кожної lane. Input робочого процесу `docker_lanes` запускає вибрані lanes проти підготовлених образів замість chunk jobs, що обмежує налагодження failed-lane одним цільовим Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана lane є live Docker lane, цільове job збирає live-test образ локально для цього повторного запуску. Згенеровані команди повторного запуску GitHub для кожної lane містять `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, щоб невдала lane могла повторно використати точний пакет і образи з невдалого запуску. ```bash 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. +Запланований live/E2E робочий процес щодня запускає повний release-path Docker suite. -## Plugin Prerelease +## Передреліз Plugin -`Plugin Prerelease` - дорожче продуктове/пакетне покриття, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, пуші в `main` і автономні ручні CI dispatch не запускають цей suite. Він балансує тести вбудованих plugin між вісьмома воркерами розширень; ці extension shard jobs запускають до двох груп конфігурації plugin одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy пакети plugin не створювали додаткових CI jobs. Релізний Docker prerelease path групує цільові Docker-лінії малими групами, щоб не резервувати десятки runner для завдань тривалістю від однієї до трьох хвилин. +`Plugin Prerelease` є дорожчим product/package coverage, тому це окремий робочий процес, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, пуші в `main` і автономні ручні CI dispatch не вмикають цей suite. Він балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на групу та більшим Node heap, щоб import-heavy plugin batches не створювали додаткові CI jobs. Release-only Docker prerelease path групує цільові Docker lanes у невеликі групи, щоб не резервувати десятки runners для завдань тривалістю від однієї до трьох хвилин. ## QA Lab -QA Lab має виділені CI-лінії поза основним smart-scoped workflow. Agentic parity вкладена в широкі QA та релізні harness, а не є автономним PR workflow. Використовуйте `Full Release Validation` з `rerun_group=qa-parity`, коли parity має йти разом із широким запуском валідації. +QA Lab має виділені CI lanes поза основним smart-scoped workflow. Agentic parity вкладений у широкі QA та release harnesses, а не є окремим PR workflow. Використовуйте `Full Release Validation` з `rerun_group=qa-parity`, коли parity має йти разом із широким validation run. -- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і вручну через dispatch; він розгортає mock parity lane, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases. +- Робочий процес `QA-Lab - All Lanes` запускається щоночі на `main` і під час manual dispatch; він розгортає mock parity lane, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases. -Перевірки релізу запускають Matrix і Telegram live transport lanes із детермінованим mock provider і mock-qualified моделями (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від live model latency і звичайного запуску provider-plugin. Live transport gateway вимикає memory search, тому що QA parity окремо покриває поведінку пам'яті; підключення provider покривається окремими live model, native provider і Docker provider suites. +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 і звичайного startup provider-plugin. Live transport gateway вимикає memory search, бо QA parity окремо покриває поведінку memory; provider connectivity покривається окремими live model, native provider і Docker provider suites. -Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише коли checked-out CLI підтримує це. Типове значення CLI і manual workflow input залишаються `all`; ручний dispatch `matrix_profile=all` завжди розбиває повне Matrix-покриття на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. +Matrix використовує `--profile fast` для scheduled і 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 перед схваленням релізу; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у мале report job для фінального порівняння parity. +`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у невелике report job для фінального parity comparison. -Для звичайних PR дотримуйтеся scoped CI/check evidence замість того, щоб трактувати parity як обов'язковий статус. +Для звичайних PR дотримуйтеся scoped CI/check evidence замість того, щоб розглядати parity як required status. ## CodeQL -Робочий процес `CodeQL` навмисно є вузьким security-сканером першого проходу, а не повним sweep усього репозиторію. Щоденні, ручні та guard-запуски для нечернеткових pull request сканують код робочих процесів Actions, а також поверхні JavaScript/TypeScript із найвищим ризиком, використовуючи високодостовірні security-запити, відфільтровані до високого/критичного `security-severity`. +Робочий процес `CodeQL` навмисно є вузьким сканером безпеки першого проходу, а не повним скануванням репозиторію. Щоденні, ручні та захисні запуски для non-draft pull request сканують код Actions workflow, а також найризикованіші поверхні JavaScript/TypeScript за допомогою високонадійних запитів безпеки, відфільтрованих до високого/критичного `security-severity`. -Guard для pull request залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і виконує ту саму високодостовірну security-матрицю, що й запланований workflow. Android і macOS CodeQL не входять до стандартних PR-запусків. +Захист pull request залишається легким: він запускається лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і виконує ту саму високонадійну матрицю безпеки, що й запланований workflow. Android і macOS CodeQL не входять до типових PR-запусків. -### Security категорії +### Категорії безпеки -| Категорія | Поверхня | -| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-security-high/core-auth-secrets` | Auth, secrets, sandbox, cron і базова поверхня gateway | -| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації core channel плюс runtime channel plugin, gateway, Plugin SDK, secrets, audit touchpoints | -| `/codeql-security-high/network-ssrf-boundary` | Поверхні core SSRF, парсингу IP, network guard, web-fetch і SSRF-політик Plugin SDK | -| `/codeql-security-high/mcp-process-tool-boundary` | MCP servers, helpers виконання процесів, outbound delivery і agent tool-execution gates | -| `/codeql-security-high/plugin-trust-boundary` | Поверхні довіри для Plugin install, loader, manifest, registry, package-manager install, source-loading і package contract Plugin SDK | +| Категорія | Поверхня | +| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | +| `/codeql-security-high/core-auth-secrets` | Автентифікація, секрети, sandbox, cron і базовий рівень Gateway | +| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації основних каналів плюс runtime плагіна каналу, Gateway, Plugin SDK, секрети, точки дотику аудиту | +| `/codeql-security-high/network-ssrf-boundary` | Основні поверхні SSRF, розбору IP, мережевого захисту, web-fetch і політики SSRF у Plugin SDK | +| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, допоміжні засоби виконання процесів, вихідна доставка та шлюзи виконання інструментів агентом | +| `/codeql-security-high/plugin-trust-boundary` | Поверхні довіри для встановлення Plugin, завантажувача, маніфесту, реєстру, встановлення package-manager, завантаження джерел і контракту пакета Plugin SDK | -### Платформозалежні security shards +### Платформоспецифічні фрагменти безпеки -- `CodeQL Android Critical Security` — запланований 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`. Тримається поза щоденними стандартними запускми, бо macOS build домінує runtime навіть коли чистий. +- `CodeQL Android Critical Security` — запланований Android-фрагмент безпеки. Збирає Android-застосунок вручну для CodeQL на найменшому Blacksmith Linux runner, прийнятому workflow sanity. Завантажує під `/codeql-critical-security/android`. +- `CodeQL macOS Critical Security` — щотижневий/ручний macOS-фрагмент безпеки. Збирає macOS-застосунок вручну для CodeQL на Blacksmith macOS, відфільтровує результати збирання залежностей із завантаженого SARIF і завантажує під `/codeql-critical-security/macos`. Залишений поза щоденними типовими запусканнями, бо збирання macOS домінує за runtime навіть коли все чисто. -### Critical Quality категорії +### Категорії критичної якості -`CodeQL Critical Quality` — відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality-запити на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його guard для pull request навмисно менший за запланований профіль: нечернеткові 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` для змін у коді виконання agent command/model/tool і reply dispatch, коді config schema/migration/IO, коді auth/secrets/sandbox/security, 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. +`CodeQL Critical Quality` — відповідний фрагмент не для безпеки. Він виконує лише запити якості JavaScript/TypeScript з error-severity, не пов’язані з безпекою, на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його захист pull request навмисно менший за запланований профіль: non-draft PR запускають лише відповідні фрагменти `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 конфігурації, коді автентифікації/секретів/sandbox/безпеки, runtime основного каналу й вбудованого Plugin каналу, протоколі Gateway/server-method, runtime пам’яті/SDK-зв’язуванні, MCP/процесах/вихідній доставці, runtime провайдера/каталозі моделей, діагностиці сеансів/чергах доставки, завантажувачі Plugin, Plugin SDK/контракті пакета або runtime відповідей Plugin SDK. Зміни конфігурації CodeQL і workflow якості запускають усі дванадцять PR-фрагментів якості. -Manual dispatch приймає: +Ручний 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 ``` -Вузькі профілі — це teaching/iteration hooks для запуску одного quality shard ізольовано. +Вузькі профілі є навчальними/ітераційними хуками для запуску одного фрагмента якості ізольовано. -| Категорія | Поверхня | -| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-critical-quality/core-auth-secrets` | Код boundary для Auth, secrets, sandbox, cron і gateway security | -| `/codeql-critical-quality/config-boundary` | Контракти config schema, migration, normalization і IO | -| `/codeql-critical-quality/gateway-runtime-boundary` | Схеми Gateway protocol і контракти server method | -| `/codeql-critical-quality/channel-runtime-boundary` | Контракти реалізації core channel і bundled channel plugin | -| `/codeql-critical-quality/agent-runtime-boundary` | Контракти command execution, model/provider dispatch, auto-reply dispatch і queues, а також ACP control-plane runtime | -| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP servers і tool bridges, helpers нагляду за процесами та контракти outbound delivery | -| `/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, helpers outbound session binding/delivery, поверхні diagnostic event/log bundle і контракти session doctor CLI | -| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Plugin SDK inbound reply dispatch, helpers reply payload/chunking/runtime, channel reply options, delivery queues і helpers session/thread binding | -| `/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 | -| `/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` | Контракти loader, registry, public-surface і entrypoint Plugin SDK | -| `/codeql-critical-quality/plugin-sdk-package-contract` | Опублікований package-side вихідний код Plugin SDK і helpers plugin package contract | +| Категорія | Поверхня | +| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `/codeql-critical-quality/core-auth-secrets` | Код межі безпеки автентифікації, секретів, sandbox, 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` | Виконання команд, диспетчеризація моделей/провайдерів, диспетчеризація й черги автовідповідей, а також runtime-контракти контрольної площини ACP | +| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-сервери та мости інструментів, допоміжні засоби нагляду за процесами й контракти вихідної доставки | +| `/codeql-critical-quality/memory-runtime-boundary` | SDK хоста пам’яті, фасади runtime пам’яті, псевдоніми Plugin SDK для пам’яті, зв’язувальний код активації runtime пам’яті та команди doctor для пам’яті | +| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішні частини черги відповідей, черги доставки сеансів, допоміжні засоби прив’язування/доставки вихідних сеансів, поверхні діагностичних подій/log bundle і CLI-контракти session doctor | +| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Вхідна диспетчеризація відповідей Plugin SDK, допоміжні засоби payload/chunking/runtime для відповідей, параметри відповідей каналу, черги доставки та допоміжні засоби прив’язування сеансу/потоку | +| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, автентифікація та discovery провайдера, реєстрація runtime провайдера, типові налаштування/каталоги провайдера та реєстри web/search/fetch/embedding | +| `/codeql-critical-quality/ui-control-plane` | Початкове завантаження Control UI, локальна персистентність, контрольні потоки Gateway і runtime-контракти контрольної площини завдань | +| `/codeql-critical-quality/web-media-runtime-boundary` | Основні runtime-контракти web fetch/search, media IO, розуміння медіа, image-generation і media-generation | +| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, публічної поверхні та entrypoint Plugin SDK | +| `/codeql-critical-quality/plugin-sdk-package-contract` | Опубліковані package-side джерела Plugin SDK і допоміжні засоби контракту пакета плагіна | -Quality залишається окремо від security, щоб quality-знахідки можна було планувати, вимірювати, вимикати або розширювати без затемнення security-сигналу. Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як scoped або sharded follow-up work лише після того, як вузькі профілі матимуть стабільні runtime і signal. +Якість залишається окремо від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без затемнення сигналу безпеки. Розширення CodeQL для Swift, Python і вбудованих плагінів слід додавати назад як scoped або sharded follow-up work лише після того, як вузькі профілі матимуть стабільний runtime і сигнал. -## Maintenance workflows +## Workflow для обслуговування ### Docs Agent -Workflow `Docs Agent` — це event-driven Codex maintenance lane для підтримання наявних docs узгодженими з нещодавно landed changes. Він не має чистого розкладу: успішний 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. +Workflow `Docs Agent` — це подієво-керована лінія обслуговування Codex для підтримання наявної документації відповідно до нещодавно змерджених змін. Він не має чистого розкладу: успішний CI-запуск non-bot push на `main` може його запустити, а manual dispatch може запускати його напряму. Workflow-run виклики пропускаються, коли `main` уже просунувся далі або коли інший non-skipped запуск Docs Agent був створений протягом останньої години. Коли він виконується, він переглядає діапазон комітів від попереднього non-skipped Docs Agent source SHA до поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені з часу останнього проходу документації. ### Test Performance Agent -Workflow `Test Performance Agent` — це event-driven Codex maintenance lane для повільних tests. Він не має чистого розкладу: успішний 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 замість широких refactors, потім повторно запускає full-suite report і відхиляє зміни, що зменшують passing baseline test count. Якщо baseline має failing tests, Codex може виправити лише obvious failures, а after-agent full-suite report має пройти, перш ніж щось буде committed. Коли `main` просувається до того, як bot push landed, lane rebases validated patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні stale patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб Codex action міг зберігати таку саму drop-sudo safety posture, як docs agent. +Workflow `Test Performance Agent` — це подієво-керована лінія обслуговування Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск non-bot push на `main` може його запустити, але він пропускається, якщо інший workflow-run виклик уже виконувався або виконується цього UTC-дня. Manual dispatch обходить цей денний activity gate. Лінія будує full-suite grouped Vitest performance report, дозволяє Codex робити лише невеликі coverage-preserving виправлення продуктивності тестів замість широких рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, що зменшують базову кількість успішних тестів. Якщо baseline має failing tests, Codex може виправляти лише очевидні збої, а after-agent full-suite report має пройти перед будь-яким комітом. Коли `main` просувається до того, як bot push потрапить у репозиторій, лінія перебазовує перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні stale patches пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб дія Codex могла зберігати ту саму drop-sudo safety posture, що й docs agent. -### Duplicate PRs After Merge +### Дублікати PR після merge -Workflow `Duplicate PRs After Merge` — це manual maintainer workflow для post-land duplicate cleanup. За замовчуванням він dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед мутацією GitHub він перевіряє, що landed PR merged і що кожен duplicate має або спільне referenced issue, або overlapping changed hunks. +Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для post-land duplicate cleanup. Типово він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR змерджено і що кожен дублікат має або спільне referenced issue, або overlapping changed hunks. ```bash gh workflow run duplicate-after-merge.yml \ @@ -470,29 +476,29 @@ gh workflow run duplicate-after-merge.yml \ -f apply=true ``` -## Local check gates і changed routing +## Локальні check gates і changed routing -Local changed-lane logic міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж широкий CI platform scope: +Локальна changed-lane логіка міститься в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей local check gate суворіший щодо архітектурних меж, ніж широкий platform scope CI: -- 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 розширюються до extension typecheck, бо extensions залежать від цих core contracts (Vitest extension sweeps залишаються explicit test work); -- release metadata-only version bumps запускають targeted version/config/root-dependency checks; -- unknown root/config changes fail safe до всіх check lanes. +- зміни production-коду core запускають typecheck core prod і core test плюс core lint/guards; +- зміни лише core test запускають тільки typecheck core test плюс core lint; +- зміни production-коду extension запускають typecheck extension prod і extension test плюс extension lint; +- зміни лише extension test запускають typecheck extension test плюс extension lint; +- зміни публічного Plugin SDK або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core-контрактів (Vitest extension sweeps залишаються explicit test work); +- metadata-only version bumps релізу запускають цільові перевірки version/config/root-dependency; +- невідомі зміни root/config fail safe до всіх check lanes. -Local changed-test routing міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі test edits запускають самі себе, source edits віддають перевагу explicit 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 впала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна настільки harness-wide, що cheap mapped set не є надійним proxy. +Локальний changed-test routing міститься в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі редагування тестів запускають самі себе, редагування джерел віддають перевагу явним mappings, потім sibling tests і import-graph dependents. Shared group-room delivery config є одним із явних mappings: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt проходять через core reply tests плюс регресії доставки Discord і Slack, щоб зміна shared default падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна достатньо harness-wide, що дешевий mapped set не є надійним proxy. -## Testbox validation +## Валідація Testbox -Запускайте Testbox із кореня репозиторію та віддавайте перевагу свіжій прогрітій машині для широкого підтвердження. Перш ніж витрачати повільну перевірку на машині, яку повторно використали, термін дії якої минув або яка щойно повідомила про неочікувано велику синхронізацію, спершу запустіть `pnpm testbox:sanity` всередині цієї машини. +Запускайте Testbox з кореня репозиторію і для широкого підтвердження надавайте перевагу свіжому прогрітому боксу. Перш ніж витрачати повільний гейт на бокс, який було повторно використано, строк дії якого минув або який щойно повідомив про неочікувано велику синхронізацію, спочатку запустіть `pnpm testbox:sanity` всередині боксу. -Перевірка sanity швидко завершується з помилкою, коли зникли обов’язкові кореневі файли, як-от `pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 відстежуваних видалень. Зазвичай це означає, що стан віддаленої синхронізації не є надійною копією PR; зупиніть цю машину й прогрійте нову, замість того щоб налагоджувати збій продуктового тесту. Для PR з навмисним великим видаленням задайте `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього запуску sanity. +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`, щоб вимкнути цей захист, або використайте більше значення в мілісекундах для незвично великих локальних diff-ів. +`pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі синхронізації понад п’ять хвилин без виводу після синхронізації. Задайте `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей захист, або використайте більше значення в мілісекундах для незвично великих локальних diff. -Crabbox — це обгортка для віддалених машин, що належить репозиторію, для maintainer-підтверджень у Linux. Використовуйте її, коли перевірка занадто широка для локального циклу редагування, коли важлива відповідність CI, або коли підтвердження потребує секретів, Docker, пакетних lane-ів, повторно використовуваних машин чи віддалених логів. Звичайний бекенд OpenClaw — `blacksmith-testbox`; власні потужності AWS/Hetzner є fallback для збоїв Blacksmith, проблем із квотами або явного тестування на власних потужностях. +Crabbox — це репозиторна обгортка для віддалених боксів, призначена для maintainer Linux-підтверджень. Використовуйте її, коли перевірка занадто широка для локального циклу редагування, коли важливий паритет із CI або коли підтвердження потребує секретів, Docker, пакетних доріжок, повторно використовуваних боксів чи віддалених журналів. Звичайний бекенд OpenClaw — `blacksmith-testbox`; власні потужності AWS/Hetzner є fallback на випадок збоїв Blacksmith, проблем із квотами або явного тестування власних потужностей. Перед першим запуском перевірте обгортку з кореня репозиторію: @@ -500,9 +506,9 @@ Crabbox — це обгортка для віддалених машин, що pnpm crabbox:run -- --help | sed -n '1,120p' ``` -Обгортка репозиторію відхиляє застарілий бінарний файл Crabbox, який не рекламує `blacksmith-testbox`. Передавайте provider явно, навіть якщо `.crabbox.yaml` має типові значення owned-cloud. +Репозиторна обгортка відмовляється від застарілого бінарного файлу Crabbox, який не оголошує `blacksmith-testbox`. Передавайте provider явно, навіть якщо `.crabbox.yaml` має типові значення для owned-cloud. -Перевірка змін: +Гейт змін: ```bash pnpm crabbox:run -- --provider blacksmith-testbox \ @@ -517,7 +523,7 @@ pnpm crabbox:run -- --provider blacksmith-testbox \ "env CI=1 NODE_OPTIONS=--max-old-space-size=4096 OPENCLAW_TEST_PROJECTS_PARALLEL=6 OPENCLAW_VITEST_MAX_WORKERS=1 OPENCLAW_VITEST_NO_OUTPUT_TIMEOUT_MS=900000 pnpm check:changed" ``` -Сфокусований повторний запуск тесту: +Точковий повторний запуск тесту: ```bash pnpm crabbox:run -- --provider blacksmith-testbox \ @@ -547,21 +553,21 @@ pnpm crabbox:run -- --provider blacksmith-testbox \ "env CI=1 NODE_OPTIONS=--max-old-space-size=4096 OPENCLAW_TEST_PROJECTS_PARALLEL=6 OPENCLAW_VITEST_MAX_WORKERS=1 OPENCLAW_VITEST_NO_OUTPUT_TIMEOUT_MS=900000 pnpm test" ``` -Прочитайте фінальний JSON-підсумок. Корисні поля: `provider`, `leaseId`, `syncDelegated`, `exitCode`, `commandMs` і `totalMs`. Одноразові запуски Crabbox на базі Blacksmith мають автоматично зупиняти Testbox; якщо запуск перервано або очищення незрозуміле, перегляньте активні машини й зупиніть лише ті, які створили ви: +Прочитайте фінальний JSON-підсумок. Корисні поля: `provider`, `leaseId`, `syncDelegated`, `exitCode`, `commandMs` і `totalMs`. Одноразові запуски Crabbox на базі Blacksmith мають автоматично зупиняти Testbox; якщо запуск перервано або cleanup незрозумілий, перегляньте активні бокси й зупиніть лише ті бокси, які створили ви: ```bash blacksmith testbox list blacksmith testbox stop --id ``` -Використовуйте повторне використання лише тоді, коли вам навмисно потрібно кілька команд на тій самій гідратованій машині: +Використовуйте повторне використання лише тоді, коли вам навмисно потрібні кілька команд на тому самому hydrated-боксі: ```bash pnpm crabbox:run -- --provider blacksmith-testbox --id --no-sync --timing-json --shell -- "pnpm test " pnpm crabbox:stop -- ``` -Якщо зламаним шаром є Crabbox, але сам Blacksmith працює, використайте прямий Blacksmith як вузький fallback: +Якщо зламаним шаром є Crabbox, але сам Blacksmith працює, використайте direct Blacksmith як вузький fallback: ```bash blacksmith testbox warmup ci-check-testbox.yml --ref main --idle-timeout 90 @@ -569,7 +575,7 @@ blacksmith testbox run --id "env CI=1 NODE_OPTIONS=--max-old-space-size blacksmith testbox stop --id ``` -Переходьте до власних потужностей Crabbox лише тоді, коли Blacksmith недоступний, обмежений квотами, не має потрібного середовища або власні потужності є явною метою: +Переходьте до власних потужностей Crabbox лише коли Blacksmith недоступний, обмежений квотою, не має потрібного середовища або власні потужності є явною метою: ```bash pnpm crabbox:warmup -- --provider aws --class beast --market on-demand --idle-timeout 90m @@ -578,7 +584,7 @@ pnpm crabbox:run -- --id --timing-json --shell -- "env NODE_OPT pnpm crabbox:stop -- ``` -`.crabbox.yaml` визначає типові значення provider, синхронізації та гідратації GitHub Actions для owned-cloud lane-ів. Він виключає локальний `.git`, щоб гідратований checkout Actions зберігав власні віддалені Git-метадані замість синхронізації локальних maintainer-remotes і сховищ об’єктів, а також виключає локальні runtime/build-артефакти, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` відповідає за checkout, налаштування Node/pnpm, отримання `origin/main` і передавання несекретного середовища для owned-cloud команд `crabbox run --id `. +`.crabbox.yaml` володіє типовими значеннями provider, синхронізації та GitHub Actions hydration для owned-cloud доріжок. Він виключає локальний `.git`, щоб hydrated checkout Actions зберігав власні віддалені Git metadata замість синхронізації maintainer-local remotes і object stores, а також виключає локальні артефакти runtime/build, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` володіє checkout, налаштуванням Node/pnpm, fetch `origin/main` і передачею несекретного середовища для owned-cloud команд `crabbox run --id `. ## Пов’язане diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md index 40cdff6b0..48ceb2a56 100644 --- a/docs/uk/help/testing.md +++ b/docs/uk/help/testing.md @@ -2,14 +2,14 @@ read_when: - Запуск тестів локально або в CI - Додавання регресійних тестів для помилок моделей/провайдерів - - Налагодження поведінки Gateway + агента -summary: 'Набір для тестування: модульні, наскрізні та live-набори, Docker runners і що покриває кожен тест' + - Налагодження поведінки Gateway та агента +summary: 'Комплект тестування: набори unit/e2e/live, ранери Docker і те, що охоплює кожен тест' title: Тестування x-i18n: - generated_at: "2026-05-04T21:16:56Z" + generated_at: "2026-05-04T22:29:46Z" model: gpt-5.5 provider: openai - source_hash: 9fec86c0e3843a3ad0dcc686f2b942c202af7dd23c33cf55ba384a9643702030 + source_hash: 0262d0bc9302671513cec25c8e7ae9c4b4f495ab8d4fd9a01ac3ce0ab94d476b source_path: help/testing.md workflow: 16 --- @@ -17,118 +17,120 @@ x-i18n: OpenClaw має три набори Vitest (unit/integration, 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) — синтетичний транспортний Plugin, який використовують сценарії, підкріплені репозиторієм. +- [QA-канал](/uk/channels/qa-channel) — синтетичний транспортний plugin, який використовується сценаріями на основі репозиторію. -Ця сторінка описує запуск звичайних тестових наборів і Docker/Parallels-ранерів. Розділ про QA-специфічні ранери нижче ([QA-специфічні ранери](#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` +- Швидший локальний запуск повного набору на машині з достатніми ресурсами: `pnpm test:max` - Прямий цикл спостереження Vitest: `pnpm test:watch` -- Пряме таргетування файлів тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Коли ви ітеруєте над одним збоєм, спочатку віддавайте перевагу таргетованим запускам. -- Docker-підтримуваний QA-сайт: `pnpm qa:lab:up` -- QA lane, підтримуваний Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- Пряме націлювання на файл тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Спершу віддавайте перевагу цільовим запускам, коли ітеруєтеся над одним збоєм. +- QA-сайт на основі Docker: `pnpm qa:lab:up` +- QA-смуга на основі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` -Коли ви змінюєте тести або хочете більшої впевненості: +Коли ви змінюєте тести або хочете додаткової впевненості: - Gate покриття: `pnpm test:coverage` - Набір E2E: `pnpm test:e2e` Під час налагодження реальних провайдерів/моделей (потрібні реальні облікові дані): -- Live-набір (моделі + Gateway-зонди інструментів/зображень): `pnpm test:live` -- Тихо націлитися на один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -- Звіти про продуктивність runtime: запустіть `OpenClaw Performance` з +- Live-набір (моделі + проби інструментів/зображень gateway): `pnpm test:live` +- Тихо націлити один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Звіти про продуктивність 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 до + публікують артефакти смуг mock-provider, deep-profile і GPT 5.4 до `openclaw/clawgrit-reports`, коли налаштовано `CLAWGRIT_REPORTS_TOKEN`. Звіт - mock-provider також містить показники завантаження Gateway на рівні джерел, пам’яті, - plugin-pressure, повторюваного hello-loop fake-model і запуску CLI. -- Docker live model sweep: `pnpm test:docker:live-models` - - Кожна вибрана модель тепер виконує текстовий хід і невеликий зонд у стилі читання файлу. + mock-provider також містить показники завантаження gateway на рівні джерела, пам’яті, + plugin-pressure, повторюваного fake-model hello-loop і старту CLI. +- Live-перевірка моделей у Docker: `pnpm test:docker:live-models` + - Кожна вибрана модель тепер виконує текстовий хід плюс невелику пробу в стилі читання файлу. Моделі, метадані яких оголошують вхід `image`, також виконують крихітний хід із зображенням. - Вимикайте додаткові зонди за допомогою `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або + Вимикайте додаткові проби за допомогою `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0`, коли ізолюєте збої провайдера. - Покриття CI: щоденні `OpenClaw Scheduled Live And E2E Checks` і ручні - `OpenClaw Release Checks` обидва викликають багаторазовий live/E2E workflow з + `OpenClaw Release Checks` обидва викликають reusable live/E2E workflow з `include_live_suites: true`, що включає окремі Docker live model - matrix-завдання, розбиті за провайдером. + matrix jobs, шардовані за провайдером. - Для сфокусованих повторних запусків CI запустіть `OpenClaw Live And E2E Checks (Reusable)` з `include_live_suites: true` і `live_models_only: true`. - - Додавайте нові високосигнальні секрети провайдерів до `scripts/ci-hydrate-live-auth.sh` - плюс `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` і його - запланованих/release-викликачів. + - Додавайте нові high-signal секрети провайдерів до `scripts/ci-hydrate-live-auth.sh` + плюс `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` та його + scheduled/release викликачів. - Native Codex bound-chat smoke: `pnpm test:docker:live-codex-bind` - - Запускає Docker live lane проти шляху Codex app-server, прив’язує синтетичний - Slack DM через `/codex bind`, виконує `/codex fast` і + - Запускає Docker live-смугу проти шляху Codex app-server, прив’язує синтетичний + Slack DM за допомогою `/codex bind`, перевіряє `/codex fast` і `/codex permissions`, а потім перевіряє, що звичайна відповідь і вкладення зображення - проходять через нативну прив’язку Plugin замість ACP. + проходять через native plugin binding замість ACP. - Codex app-server harness smoke: `pnpm test:docker:live-codex-harness` - - Запускає ходи агента Gateway через harness Codex app-server, що належить Plugin, - перевіряє `/codex status` і `/codex models`, а за замовчуванням виконує зонди image, - cron MCP, sub-agent і Guardian. Вимикайте зонд sub-agent за допомогою + - Запускає ходи gateway agent через належний plugin harness Codex app-server, + перевіряє `/codex status` і `/codex models`, а за замовчуванням виконує проби image, + cron MCP, sub-agent і Guardian. Вимикайте пробу sub-agent за допомогою `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0`, коли ізолюєте інші збої Codex - app-server. Для сфокусованої перевірки sub-agent вимкніть інші зонди: + app-server. Для сфокусованої перевірки 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, якщо не встановлено + Це завершується після проби sub-agent, якщо не встановлено `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0`. - Crestodian rescue command smoke: `pnpm test:live:crestodian-rescue-channel` - - Опціональна додаткова перевірка поверхні команди порятунку message-channel. + - Opt-in перевірка з подвійним захистом для поверхні команди порятунку message-channel. Вона виконує `/crestodian status`, ставить у чергу постійну зміну моделі, - відповідає `/crestodian yes` і перевіряє шлях запису audit/config. + відповідає `/crestodian yes` і перевіряє шлях audit/config write. - Crestodian planner Docker smoke: `pnpm test:docker:crestodian-planner` - - Запускає Crestodian у контейнері без конфігурації з фейковим Claude CLI у `PATH` - і перевіряє, що fuzzy planner fallback перетворюється на аудитований типізований + - Запускає Crestodian у контейнері без конфігурації з фейковим Claude CLI на `PATH` + і перевіряє, що нечіткий fallback планувальника перетворюється на аудитований типізований запис конфігурації. - Crestodian first-run Docker smoke: `pnpm test:docker:crestodian-first-run` - - Починає з порожнього каталогу стану OpenClaw, маршрутизує голий `openclaw` до - Crestodian, застосовує setup/model/agent/Discord Plugin + SecretRef-записи, - перевіряє конфігурацію та audit-записи. Той самий шлях налаштування Ring 0 + - Починає з порожньої директорії стану OpenClaw, маршрутизує голий `openclaw` до + Crestodian, застосовує записи setup/model/agent/Discord plugin + SecretRef, + валідовує конфігурацію та перевіряє audit entries. Той самий шлях налаштування Ring 0 також покрито в QA Lab через `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`. -- Moonshot/Kimi cost smoke: із встановленим `MOONSHOT_API_KEY` запустіть +- Moonshot/Kimi cost smoke: з установленим `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, а транскрипт асистента зберігає нормалізований `usage.cost`. -Коли вам потрібен лише один збійний випадок, віддавайте перевагу звуженню live-тестів через env allowlist vars, описані нижче. +Коли вам потрібен лише один збійний випадок, віддавайте перевагу звуженню live-тестів через env vars allowlist, описані нижче. ## QA-специфічні ранери -Ці команди розташовані поруч із головними тестовими наборами, коли потрібна реалістичність QA-lab: +Ці команди розташовані поруч із основними тестовими наборами, коли вам потрібна реалістичність QA-lab: -CI запускає QA Lab у виділених workflow. Agentic parity вкладено під +CI запускає QA Lab у спеціальних workflow. Agentic parity вкладено під `QA-Lab - All Lanes` і release validation, а не окремий PR workflow. -Широка перевірка має використовувати `Full Release Validation` з -`rerun_group=qa-parity` або QA-групу release-checks. `QA-Lab - All Lanes` -запускається щоночі на `main` і з ручного dispatch з mock parity lane, live +Для широкої валідації слід використовувати `Full Release Validation` з +`rerun_group=qa-parity` або QA-групу release-checks. Stable/default release +checks тримають вичерпний live/Docker soak за `run_release_soak=true`; профіль +`full` примусово вмикає soak. `QA-Lab - All Lanes` +запускається щоночі на `main` і з ручного dispatch із mock parity lane, live Matrix lane, Convex-managed live Telegram lane і Convex-managed live Discord -lane як паралельними завданнями. Заплановані QA та release checks явно передають Matrix +lane як паралельні jobs. Scheduled QA і release checks явно передають Matrix `--profile fast`, тоді як Matrix CLI і manual workflow input -за замовчуванням залишаються `all`; ручний dispatch може розбити `all` на `transport`, -`media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli` завдання. `OpenClaw Release +за замовчуванням лишаються `all`; manual dispatch може шардити `all` на jobs +`transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` запускає parity плюс fast Matrix і Telegram lanes перед release -approval, використовуючи `mock-openai/gpt-5.5` для release transport checks, щоб вони залишалися -детермінованими й уникали звичайного запуску provider-plugin. Ці live transport +approval, використовуючи `mock-openai/gpt-5.5` для release transport checks, щоб вони лишалися +детермінованими й уникали звичайного старту provider-plugin. Ці live transport gateways вимикають пошук у пам’яті; поведінка пам’яті лишається покритою QA parity suites. @@ -136,96 +138,95 @@ Full 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` замість повторної збірки +commit, а потім завантажують його з `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`. + покриття фікстур і моків протоколу, не замінюючи смугу `mock-openai`, яка враховує сценарії. - `pnpm test:plugins:kitchen-sink-live` - - Запускає живий набір випробувань Plugin OpenAI Kitchen Sink через QA Lab. Він - встановлює зовнішній пакет Kitchen Sink, перевіряє інвентар поверхні SDK Plugin, + - Запускає живий прогін Plugin OpenAI Kitchen Sink через QA Lab. Він + встановлює зовнішній пакет Kitchen Sink, перевіряє інвентар поверхні plugin SDK, зондує `/healthz` і `/readyz`, записує докази CPU/RSS Gateway, запускає живий хід OpenAI і перевіряє змагальну діагностику. Потребує живої автентифікації OpenAI, наприклад `OPENAI_API_KEY`. У гідратованих сесіях Testbox - автоматично підтягує профіль живої автентифікації Testbox, коли наявний - помічник `openclaw-testbox-env`. + автоматично підтягує live-auth профіль Testbox, коли + наявний помічник `openclaw-testbox-env`. - `pnpm test:gateway:cpu-scenarios` - - Запускає бенч запуску Gateway разом із невеликим пакетом мок-сценаріїв QA Lab + - Запускає бенч старту Gateway плюс невеликий пакет mock-сценаріїв 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` - плюс `--hot-wall-warn-ms`), тому короткі сплески під час запуску записуються як метрики - і не виглядають як регресія Gateway із багатохвилинним завантаженням CPU. - - Використовує зібрані артефакти `dist`; спершу запустіть збірку, якщо checkout ще не має + - За замовчуванням позначає лише тривалі спостереження гарячого CPU (`--cpu-core-warn` + плюс `--hot-wall-warn-ms`), тому короткі сплески під час старту записуються як метрики + без вигляду регресії 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`, + - Живі запуски передають підтримувані вхідні дані QA-автентифікації, практичні для гостя: + ключі провайдера з env, шлях до конфігу QA live provider і `CODEX_HOME`, коли він наявний. - - Каталоги виводу мають залишатися в корені репозиторію, щоб гостьова система могла записувати назад через - змонтований робочий простір. - - Записує звичайний QA-звіт і підсумок, а також логи Multipass у + - Каталоги виводу мають залишатися під коренем репозиторію, щоб гість міг записувати назад через + змонтований workspace. + - Записує звичайний QA-звіт + зведення, а також логи Multipass у `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Запускає QA-сайт на базі Docker для операторської QA-роботи. + - Запускає QA-сайт на базі Docker для operator-style QA-роботи. - `pnpm test:docker:npm-onboard-channel-agent` - - Збирає npm-tarball із поточного checkout, встановлює його глобально в - Docker, запускає неінтерактивний онбординг із ключем OpenAI API, налаштовує Telegram - за замовчуванням, перевіряє, що запакований runtime Plugin завантажується без startup - dependency repair, запускає doctor і виконує один локальний хід агента проти - змоканого endpoint OpenAI. - - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити ту саму лінію packaged-install + - Збирає npm tarball із поточного checkout, встановлює його глобально в + Docker, запускає неінтерактивний onboarding з API-ключем OpenAI, за замовчуванням налаштовує Telegram, + перевіряє, що запакований runtime Plugin завантажується без виправлення залежностей під час старту, + запускає doctor і запускає один локальний хід агента проти + змокованого endpoint OpenAI. + - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити ту саму смугу packaged-install з Discord. - `pnpm test:docker:session-runtime-context` - - Запускає детермінований Docker smoke для зібраного застосунку для transcript-ів вбудованого runtime context. - Він перевіряє, що прихований runtime context OpenClaw зберігається як - невідображуване кастомне повідомлення замість витоку у видимий хід користувача, + - Запускає детермінований Docker smoke для зібраного застосунку щодо транскриптів вбудованого runtime-контексту. + Він перевіряє, що прихований runtime-контекст OpenClaw зберігається як + non-display custom message замість витоку у видимий хід користувача, потім засіває уражений зламаний session JSONL і перевіряє, що `openclaw doctor --fix` переписує його на активну гілку з резервною копією. - `pnpm test:docker:npm-telegram-live` - - Встановлює кандидат пакета OpenClaw у Docker, запускає онбординг встановленого пакета, + - Встановлює candidate-пакет OpenClaw у Docker, запускає onboarding встановленого пакета, налаштовує Telegram через встановлений CLI, а потім повторно використовує - живу QA-лінію Telegram із цим встановленим пакетом як SUT Gateway. + живу QA-смугу Telegram з цим встановленим пакетом як SUT Gateway. - За замовчуванням використовує `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`; задайте `OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz` або `OPENCLAW_CURRENT_PACKAGE_TGZ`, щоб тестувати розв’язаний локальний tarball замість - встановлення з registry. + встановлення з реєстру. - Використовує ті самі env-облікові дані Telegram або джерело облікових даних Convex, що й - `pnpm openclaw qa telegram`. Для CI/автоматизації релізу задайте + `pnpm openclaw qa telegram`. Для автоматизації CI/релізів задайте `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` плюс - `OPENCLAW_QA_CONVEX_SITE_URL` і рольовий секрет. Якщо - `OPENCLAW_QA_CONVEX_SITE_URL` і рольовий секрет Convex наявні в CI, + `OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі. Якщо + `OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі Convex наявні в CI, Docker-обгортка автоматично вибирає Convex. - - Обгортка перевіряє env облікових даних Telegram або Convex на хості перед - роботою Docker build/install. Задавайте `OPENCLAW_NPM_TELEGRAM_SKIP_CREDENTIAL_PREFLIGHT=1` - лише під час навмисного налагодження підготовки до облікових даних. + - Обгортка перевіряє env облікових даних Telegram або Convex на хості до + роботи Docker build/install. Задавайте `OPENCLAW_NPM_TELEGRAM_SKIP_CREDENTIAL_PREFLIGHT=1` + лише коли навмисно налагоджуєте підготовку до налаштування облікових даних. - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` перевизначає спільну - `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цієї лінії. - - GitHub Actions надає цю лінію як ручний maintainer-workflow + `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цієї смуги. + - GitHub Actions надає цю смугу як ручний maintainer workflow `NPM Telegram Beta E2E`. Він не запускається під час merge. Workflow використовує - середовище `qa-live-shared` і lease-и облікових даних Convex CI. -- GitHub Actions також надає `Package Acceptance` для побічного продуктового доказу - проти одного кандидата пакета. Він приймає довірений ref, опубліковану npm-специфікацію, - HTTPS-URL tarball плюс SHA-256 або tarball artifact з іншого run, завантажує + середовище `qa-live-shared` і CI-оренди облікових даних Convex. +- GitHub Actions також надає `Package Acceptance` для side-run product proof + проти одного candidate-пакета. Він приймає довірений ref, опублікований npm spec, + HTTPS tarball URL плюс SHA-256 або tarball-артефакт з іншого запуску, завантажує нормалізований `openclaw-current.tgz` як `package-under-test`, а потім запускає - наявний Docker E2E scheduler із профілями ліній smoke, package, product, full або custom. - Задайте `telegram_mode=mock-openai` або `live-frontier`, щоб запустити - QA-workflow Telegram проти того самого артефакта `package-under-test`. - - Доказ останньої beta для продукту: + наявний Docker E2E scheduler з профілями smoke, package, product, full або custom + lane. Задайте `telegram_mode=mock-openai` або `live-frontier`, щоб запустити + Telegram QA workflow проти того самого артефакту `package-under-test`. + - Product proof для останньої beta: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -235,7 +236,7 @@ gh workflow run package-acceptance.yml --ref main \ -f telegram_mode=mock-openai ``` -- Доказ точного URL tarball потребує digest: +- Proof точного tarball URL потребує digest: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -245,7 +246,7 @@ gh workflow run package-acceptance.yml --ref main \ -f suite_profile=package ``` -- Доказ артефакта завантажує tarball artifact з іншого run Actions: +- Artifact proof завантажує tarball-артефакт з іншого запуску Actions: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -257,73 +258,74 @@ gh workflow run package-acceptance.yml --ref main \ - `pnpm test:docker:plugins` - Пакує та встановлює поточну збірку OpenClaw у Docker, запускає Gateway - з налаштованим OpenAI, а потім вмикає bundled channel/plugins через редагування config. + з налаштованим OpenAI, а потім вмикає вбудовані channel/plugins через редагування + конфігу. - Перевіряє, що setup discovery залишає неналаштовані завантажувані plugins відсутніми, - перший налаштований doctor repair явно встановлює кожен відсутній завантажуваний - plugin, а другий restart не запускає прихований dependency - repair. + перше налаштоване doctor repair явно встановлює кожен відсутній завантажуваний + plugin, а другий restart не запускає приховане виправлення + залежностей. - Також встановлює відомий старіший npm baseline, вмикає Telegram перед запуском - `openclaw update --tag ` і перевіряє, що post-update doctor кандидата - очищає сміття legacy-залежностей Plugin без - postinstall repair з боку harness. + `openclaw update --tag ` і перевіряє, що + post-update doctor candidate очищує legacy debris залежностей plugin без + harness-side postinstall repair. - `pnpm test:parallels:npm-update` - - Запускає native packaged-install update smoke у гостьових системах Parallels. Кожна - вибрана платформа спершу встановлює запитаний baseline package, потім запускає - встановлену команду `openclaw update` у тій самій гостьовій системі й перевіряє + - Запускає нативний packaged-install update smoke на гостях Parallels. Кожна + вибрана платформа спочатку встановлює запитаний baseline-пакет, потім запускає + встановлену команду `openclaw update` у тому самому гості й перевіряє встановлену версію, статус оновлення, готовність Gateway і один локальний хід агента. - Використовуйте `--platform macos`, `--platform windows` або `--platform linux` під час - ітерацій на одній гостьовій системі. Використовуйте `--json` для шляху до summary artifact і - статусу кожної лінії. - - Лінія OpenAI за замовчуванням використовує `openai/gpt-5.5` для живого proof ходу агента. + ітерацій на одному гості. Використовуйте `--json` для шляху до summary artifact і + статусу за смугами. + - Смуга OpenAI за замовчуванням використовує `openai/gpt-5.5` для proof живого agent-turn. Передайте `--model ` або задайте `OPENCLAW_PARALLELS_OPENAI_MODEL`, коли навмисно перевіряєте іншу модель OpenAI. - - Обгорніть довгі локальні запуски в host timeout, щоб зависання транспорту Parallels не могли - забрати решту тестового вікна: + - Обгортайте довгі локальні запуски в host timeout, щоб зависання транспорту Parallels не + використали решту тестового вікна: ```bash timeout --foreground 150m pnpm test:parallels:npm-update -- --json timeout --foreground 90m pnpm test:parallels:npm-update -- --platform windows --json ``` - - Скрипт записує вкладені логи ліній у `/tmp/openclaw-parallels-npm-update.*`. + - Скрипт записує вкладені логи смуг у `/tmp/openclaw-parallels-npm-update.*`. Перегляньте `windows-update.log`, `macos-update.log` або `linux-update.log` - перед припущенням, що зовнішня обгортка зависла. - - Оновлення Windows може витрачати 10-15 хвилин на post-update doctor і package - update work у холодній гостьовій системі; це все ще справний стан, коли вкладений npm + перед тим, як припускати, що зовнішня обгортка зависла. + - Оновлення Windows може витратити 10-15 хвилин на post-update doctor і роботу + з оновлення package на холодному гості; це все ще нормально, якщо вкладений npm debug log просувається. - - Не запускайте цю агрегатну обгортку паралельно з окремими smoke-лініями Parallels - macOS, Windows або Linux. Вони спільно використовують стан VM і можуть конфліктувати під час - відновлення snapshot, serving package або стану Gateway у гостьовій системі. - - Post-update proof запускає звичайну поверхню bundled Plugin, оскільки - capability facades, такі як мовлення, генерація зображень і розуміння media, - завантажуються через bundled runtime APIs, навіть коли сам хід агента + - Не запускайте цю агреговану обгортку паралельно з окремими смугами smoke Parallels + для macOS, Windows або Linux. Вони спільно використовують стан VM і можуть конфліктувати під час + відновлення snapshot, подавання package або стану guest Gateway. + - Post-update proof запускає звичайну поверхню вбудованих plugins, тому що + capability facades, такі як мовлення, генерація зображень і розуміння медіа, + завантажуються через вбудовані runtime APIs, навіть коли сам хід агента перевіряє лише просту текстову відповідь. - `pnpm openclaw qa aimock` - Запускає лише локальний сервер провайдера AIMock для прямого protocol smoke testing. - `pnpm openclaw qa matrix` - - Запускає живу QA-лінію Matrix проти одноразового homeserver Tuwunel на базі Docker. Лише source-checkout — packaged installs не постачають `qa-lab`. - - Повний CLI, каталог профілів/сценаріїв, env vars і layout артефактів: [QA Matrix](/uk/concepts/qa-matrix). + - Запускає живу QA-смугу Matrix проти одноразового Tuwunel homeserver на базі Docker. Лише source-checkout — packaged installs не постачають `qa-lab`. + - Повний CLI, каталог профілів/сценаріїв, env vars і структура артефактів: [Matrix QA](/uk/concepts/qa-matrix). - `pnpm openclaw qa telegram` - - Запускає живу QA-лінію Telegram проти реальної приватної групи, використовуючи токени driver і SUT bot з env. - - Потребує `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Group id має бути числовим chat id Telegram. + - Запускає живу QA-смугу Telegram проти справжньої приватної групи з використанням токенів driver і SUT bot з 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 credentials. Використовуйте env mode за замовчуванням або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases. - - Завершується з ненульовим кодом, коли будь-який сценарій завершується невдало. Використовуйте `--allow-failures`, коли - потрібні артефакти без коду завершення з помилкою. - - Потребує двох різних ботів в одній приватній групі, причому SUT bot має мати Telegram username. - - Для стабільного bot-to-bot спостереження увімкніть 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 до спостереженої відповіді SUT. + - Завершується з ненульовим кодом, якщо будь-який сценарій завершується невдало. Використовуйте `--allow-failures`, коли вам + потрібні артефакти без коду завершення, що означає помилку. + - Потребує двох окремих bots в одній приватній групі, причому SUT bot має надавати Telegram username. + - Для стабільного bot-to-bot observation увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох bots і переконайтеся, що driver bot може спостерігати group bot traffic. + - Записує Telegram QA report, summary і observed-messages artifact у `.artifacts/qa-e2e/...`. Сценарії з відповіддю включають RTT від send request драйвера до спостереженої відповіді SUT. -Живі транспортні лінії спільно використовують один стандартний контракт, щоб нові транспорти не розходилися; матриця покриття кожної лінії міститься в [огляд QA → Покриття живого транспорту](/uk/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` є широким синтетичним набором і не входить до цієї матриці. +Живі transport lanes мають один стандартний контракт, щоб нові transports не розходилися; per-lane coverage matrix розміщена в [Огляд QA → Покриття живого транспорту](/uk/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` — це широкий синтетичний набір і не є частиною цієї matrix. ### Спільні облікові дані Telegram через Convex (v1) Коли `--credential-source convex` (або `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) увімкнено для -`openclaw qa telegram`, QA lab отримує ексклюзивний lease з пулу на базі Convex, виконує Heartbeat -цього lease, поки лінія працює, і звільняє lease під час shutdown. +`openclaw qa telegram`, QA lab отримує ексклюзивну lease з pool на базі Convex, надсилає heartbeats +для цієї lease, поки смуга виконується, і звільняє lease під час shutdown. Еталонний scaffold проєкту Convex: @@ -335,7 +337,7 @@ gh workflow run package-acceptance.yml --ref main \ - Один секрет для вибраної ролі: - `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`) @@ -347,14 +349,14 @@ gh workflow run package-acceptance.yml --ref main \ - `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_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` Convex URLs для local-only development. -`OPENCLAW_QA_CONVEX_SITE_URL` у звичайній роботі має використовувати `https://`. +`OPENCLAW_QA_CONVEX_SITE_URL` має використовувати `https://` за нормальної роботи. -Команди адміністратора для супровідників (додати/видалити/перелічити пул) вимагають саме +Адміністративні команди супровідників (pool add/remove/list) потребують саме `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -Допоміжні CLI-команди для супровідників: +CLI-помічники для супровідників: ```bash pnpm openclaw qa credentials doctor @@ -363,12 +365,12 @@ pnpm openclaw qa credentials list --kind telegram pnpm openclaw qa credentials remove --credential-id ``` -Використовуйте `doctor` перед live-запусками, щоб перевірити URL сайту Convex, секрети broker, -префікс endpoint, HTTP timeout і доступність admin/list без виведення -значень секретів. Використовуйте `--json` для машинозчитуваного виводу у скриптах і CI +Використовуйте `doctor` перед живими запусками, щоб перевірити URL сайту Convex, секрети брокера, +префікс кінцевої точки, тайм-аут HTTP і доступність admin/list без виведення +секретних значень. Використовуйте `--json` для машинозчитуваного виводу в скриптах і CI утилітах. -Типовий контракт endpoint (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): +Контракт кінцевої точки за замовчуванням (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): - `POST /acquire` - Запит: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` @@ -386,138 +388,138 @@ pnpm openclaw qa credentials remove --credential-id - `POST /admin/remove` (лише секрет супровідника) - Запит: `{ credentialId, actorId }` - Успіх: `{ status: "ok", changed, credential }` - - Захист активної lease: `{ status: "error", code: "LEASE_ACTIVE", ... }` + - Захист активної оренди: `{ status: "error", code: "LEASE_ACTIVE", ... }` - `POST /admin/list` (лише секрет супровідника) - Запит: `{ kind?, status?, includePayload?, limit? }` - Успіх: `{ status: "ok", credentials, count }` -Форма payload для типу Telegram: +Форма payload для виду Telegram: - `{ groupId: string, driverToken: string, sutToken: string }` - `groupId` має бути числовим рядком ідентифікатора чату Telegram. -- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє неправильно сформовані payload. +- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє некоректні payload. ### Додавання каналу до QA -Архітектура й назви допоміжних сценарних функцій для нових адаптерів каналів описані в [огляді QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна планка: реалізувати transport runner на спільному host seam `qa-lab`, оголосити `qaRunners` у маніфесті Plugin, змонтувати як `openclaw qa ` і створити сценарії в `qa/scenarios/`. +Архітектура й назви помічників сценаріїв для нових адаптерів каналів описані в [огляді QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна планка: реалізувати transport runner на спільному шві хоста `qa-lab`, оголосити `qaRunners` у маніфесті plugin, змонтувати як `openclaw qa ` і створити сценарії в `qa/scenarios/`. ## Набори тестів (що де запускається) -Сприймайте набори як “зростання реалістичності” (і зростання нестабільності/вартості): +Сприймайте набори як «зростання реалістичності» (і зростання нестабільності/вартості): -### Модульні / інтеграційні (типово) +### Модульні / інтеграційні (за замовчуванням) - Команда: `pnpm test` -- Конфігурація: нецільові запуски використовують набір шардів `vitest.full-*.config.ts` і можуть розгортати багатопроєктні шарди в попроєктні конфігурації для паралельного планування -- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; модульні тести UI запускаються у виділеному шарді `unit-ui` -- Обсяг: +- Конфіг: нецільові запуски використовують набір шард `vitest.full-*.config.ts` і можуть розгортати багатопроєктні шарди в поконфігураційні проєкти для паралельного планування +- Файли: інвентарі ядра/модулів у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; модульні тести UI запускаються у виділеному шарді `unit-ui` +- Область: - Чисті модульні тести - - Внутрішньопроцесні інтеграційні тести (автентифікація Gateway, маршрутизація, tooling, parsing, config) + - Внутрішньопроцесні інтеграційні тести (автентифікація Gateway, маршрутизація, інструменти, розбір, конфіг) - Детерміновані регресії для відомих помилок - Очікування: - Запускається в CI - - Реальні ключі не потрібні + - Не потребує реальних ключів - Має бути швидким і стабільним - - Тести resolver і public-surface loader мають доводити широку fallback-поведінку `api.js` і - `runtime-api.js` зі згенерованими малими фікстурами Plugin, а не - реальними API джерел вбудованих Plugin. Завантаження API реальних Plugin належать до - contract/integration наборів, якими володіє Plugin. + - Тести резолвера й завантажувача публічної поверхні мають доводити широку fallback-поведінку `api.js` і + `runtime-api.js` за допомогою згенерованих крихітних фікстур plugin, а не + реальних API джерел вбудованих plugin. Реальні завантаження API plugin належать до + контрактних/інтеграційних наборів, якими володіє 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` і далі використовує нативний граф проєктів кореневого `vitest.config.ts`, бо багатоshardовий watch loop непрактичний. - - `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`, явні зіставлення джерел і локальні залежні з import-graph. Правки config/setup/package не запускають широкі тести, якщо ви явно не використаєте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. - - `pnpm check:changed` є звичайним розумним локальним check gate для вузької роботи. Він класифікує diff на core, тести core, extensions, тести extension, 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 поза верхньорівневим полем версії. - - Правки live Docker ACP harness запускають сфокусовані перевірки: синтаксис shell для скриптів live Docker auth і dry-run планувальника live Docker. Зміни `package.json` включаються лише тоді, коли diff обмежений `scripts["test:docker:live-*"]`; dependency, export, version та інші правки package-surface і далі використовують ширші guard. - - Import-light модульні тести з agents, commands, plugins, auto-reply helpers, `plugin-sdk` і схожих чистих utility-ділянок спрямовуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. - - Вибрані файли джерел helpers `plugin-sdk` і `commands` також зіставляють changed-mode запуски з явними сусідніми тестами в цих light lanes, тож правки helpers не перезапускають увесь важкий набір для цього каталогу. - - `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 extension і release-only шард `agentic-plugins`. Full Release Validation dispatch окремо запускає дочірній workflow `Plugin Prerelease` для цих plugin/extension-heavy наборів на release candidates. + - Нецільовий `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`) замість одного гігантського нативного процесу кореневого проєкту. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension витісняти непов’язані набори. + - `pnpm test --watch` і далі використовує нативний граф проєктів кореневого `vitest.config.ts`, бо цикл спостереження з багатьма шардами непрактичний. + - `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`, явні мапінги джерел і локальні залежні елементи графа імпортів. Зміни конфігів/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 ` для доказу тестами. Version bumps лише release metadata запускають цільові перевірки version/config/root-dependency із guard, який відхиляє зміни package поза верхньорівневим полем version. + - Зміни live Docker ACP harness запускають фокусовані перевірки: синтаксис shell для скриптів live Docker auth і dry-run планувальника live Docker. Зміни `package.json` включаються лише коли diff обмежений `scripts["test:docker:live-*"]`; зміни dependency, export, version та іншої package-поверхні й далі використовують ширші guards. + - Import-light модульні тести з agents, commands, plugins, auto-reply helpers, `plugin-sdk` і подібних чистих utility-зон маршрутизуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. + - Вибрані вихідні файли помічників `plugin-sdk` і `commands` також маплять changed-mode запуски на явні сусідні тести в цих легких lanes, тож зміни помічників не перезапускають увесь важкий набір для цього каталогу. + - `auto-reply` має виділені bucket для верхньорівневих core helpers, верхньорівневих інтеграційних тестів `reply.*` і піддерева `src/auto-reply/reply/**`. CI додатково ділить піддерево reply на шарди agent-runner, dispatch і commands/state-routing, щоб один import-heavy bucket не забирав увесь хвіст Node. + - Звичайний CI для PR/main навмисно пропускає пакетний sweep extensions і shard `agentic-plugins`, призначений лише для релізів. Full Release Validation запускає окремий дочірній workflow `Plugin Prerelease` для цих важких для plugin/extension наборів на release candidates. - + - - Коли змінюєте вхідні дані discovery message-tool або runtime-контекст Compaction, + - Коли ви змінюєте входи виявлення message-tool або runtime-контекст compaction, зберігайте обидва рівні покриття. - - Додавайте сфокусовані регресії helpers для чистих меж маршрутизації та нормалізації. - - Підтримуйте справність інтеграційних наборів embedded runner: + - Додавайте сфокусовані регресії помічників для чистих меж маршрутизації та нормалізації. + - Підтримуйте здоровими інтеграційні набори 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`; тести лише helpers - не є достатньою заміною цих інтеграційних шляхів. + - Ці набори перевіряють, що scoped ids і поведінка compaction і далі проходять + через реальні шляхи `run.ts` / `compact.ts`; тести лише помічників + не є достатньою заміною для цих інтеграційних шляхів. - + - - Базова конфігурація Vitest типово використовує `threads`. - - Спільна конфігурація Vitest фіксує `isolate: false` і використовує - неізольований runner у кореневих проєктах, e2e і live config. - - Коренева UI lane зберігає свій setup `jsdom` і optimizer, але теж працює на + - Базовий конфіг Vitest за замовчуванням використовує `threads`. + - Спільний конфіг Vitest фіксує `isolate: false` і використовує + неізольований runner у кореневих проєктах, e2e і live-конфігах. + - Кореневий UI lane зберігає свій setup `jsdom` і optimizer, але також працює на спільному неізольованому runner. - - Кожен шард `pnpm test` успадковує ті самі типові значення `threads` + `isolate: false` - зі спільної конфігурації Vitest. - - `scripts/run-vitest.mjs` типово додає `--no-maglev` для дочірніх процесів Node + - Кожен shard `pnpm test` успадковує ті самі значення за замовчуванням `threads` + `isolate: false` + зі спільного конфіга Vitest. + - `scripts/run-vitest.mjs` за замовчуванням додає `--no-maglev` для дочірніх процесів Node Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. - Встановіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8. + Задайте `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8. - + - `pnpm changed:lanes` показує, які архітектурні lanes запускає diff. - - Pre-commit hook виконує лише форматування. Він повторно stage-ить відформатовані файли і + - Pre-commit hook виконує лише форматування. Він повторно додає відформатовані файли до staging і не запускає lint, typecheck або тести. - - Запускайте `pnpm check:changed` явно перед handoff або push, коли вам + - Запускайте `pnpm check:changed` явно перед передаванням роботи або push, коли вам потрібен розумний локальний check gate. - - `pnpm test:changed` типово маршрутизує через дешеві scoped lanes. Використовуйте - `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли агент - вирішує, що правка harness, config, package або contract справді потребує ширшого + - `pnpm test:changed` за замовчуванням маршрутизується через дешеві scoped lanes. Використовуйте + `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли агент + вирішує, що редагування harness, config, package або contract справді потребує ширшого покриття Vitest. - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, - лише з вищим worker cap. - - Локальне auto-scaling workers навмисно консервативне й відступає, - коли середнє навантаження host уже високе, тож кілька одночасних - запусків Vitest типово завдають менше шкоди. - - Базова конфігурація Vitest позначає проєкти/config файли як - `forceRerunTriggers`, щоб reruns у changed-mode залишалися коректними, коли змінюється - test wiring. - - Конфігурація тримає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних - hosts; встановіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете - одне явне розташування cache для прямого profiling. + лише з вищим лімітом workers. + - Автомасштабування локальних workers навмисно консервативне й відступає, + коли load average хоста вже високий, тож кілька одночасних + запусків Vitest за замовчуванням завдають менше шкоди. + - Базовий конфіг Vitest позначає проєкти/конфігураційні файли як + `forceRerunTriggers`, щоб повторні запуски changed-mode залишалися правильними, коли змінюється + обв’язка тестів. + - Конфіг залишає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних + хостах; задайте `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете + одну явну локацію cache для прямого профілювання. - + - - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість import плюс + - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпортів плюс вивід import-breakdown. - - `pnpm test:perf:imports:changed` обмежує той самий profiling view - файлами, зміненими після `origin/main`. - - Дані часу шардів записуються в `.artifacts/vitest-shard-timings.json`. - Запуски всієї конфігурації використовують шлях config як ключ; include-pattern CI - шарди додають назву шарда, щоб відфільтровані шарди можна було відстежувати + - `pnpm test:perf:imports:changed` обмежує той самий перегляд профілювання + файлами, зміненими з `origin/main`. + - Дані часу shard записуються в `.artifacts/vitest-shard-timings.json`. + Запуски whole-config використовують шлях конфіга як ключ; include-pattern CI + shards додають назву shard, щоб відфільтровані shards можна було відстежувати окремо. - - Коли один гарячий тест усе ще витрачає більшість часу на startup imports, - тримайте важкі dependencies за вузьким локальним seam `*.runtime.ts` і - mock-айте цей seam напряму замість deep-import runtime helpers лише + - Коли один hot test усе ще витрачає більшість часу на startup imports, + тримайте важкі залежності за вузьким локальним швом `*.runtime.ts` і + mock цей шов напряму замість deep-import runtime helpers лише щоб передати їх через `vi.mock(...)`. - `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований `test:changed` із нативним шляхом root-project для цього закоміченого - diff і виводить wall time плюс max RSS macOS. - - `pnpm test:perf:changed:bench -- --worktree` benchmark-ить поточне + diff і друкує wall time плюс max RSS на macOS. + - `pnpm test:perf:changed:bench -- --worktree` бенчмаркить поточне dirty tree, маршрутизуючи список змінених файлів через - `scripts/test-projects.mjs` і кореневу конфігурацію Vitest. + `scripts/test-projects.mjs` і кореневий конфіг Vitest. - `pnpm test:perf:profile:main` записує CPU profile головного потоку для - startup Vitest/Vite і transform overhead. + накладних витрат запуску й трансформацій Vitest/Vite. - `pnpm test:perf:profile:runner` записує CPU+heap profiles runner для - unit suite з вимкненим file parallelism. + unit suite з вимкненим файловим паралелізмом. @@ -525,260 +527,260 @@ pnpm openclaw qa credentials remove --credential-id ### Стабільність (Gateway) - Команда: `pnpm test:stability:gateway` -- Конфігурація: `vitest.gateway.config.ts`, примусово один worker -- Обсяг: - - Запускає реальний loopback Gateway із типово ввімкненою diagnostics - - Проганяє синтетичний churn повідомлень gateway, memory і large-payload через diagnostic event path - - Опитує `diagnostics.stability` через Gateway WS RPC - - Покриває helpers збереження diagnostic stability bundle - - Перевіряє, що recorder залишається bounded, синтетичні RSS samples лишаються нижче pressure budget, а глибини per-session queue повертаються до нуля +- Конфіг: `vitest.gateway.config.ts`, примусово один worker +- Область: + - Запускає реальний loopback Gateway із діагностикою, увімкненою за замовчуванням + - Проганяє синтетичні Gateway message, memory і large-payload churn через шлях діагностичних подій + - Запитує `diagnostics.stability` через Gateway WS RPC + - Покриває помічники збереження diagnostic stability bundle + - Перевіряє, що recorder залишається обмеженим, синтетичні RSS samples залишаються нижче pressure budget, а глибини per-session queue повертаються до нуля - Очікування: - Безпечно для CI і без ключів - - Вузька lane для подальшої stability-regression, не заміна повному набору Gateway + - Вузький lane для follow-up регресій стабільності, а не заміна повного набору Gateway -### E2E (gateway smoke) +### E2E (Gateway smoke) - Команда: `pnpm test:e2e` - Конфігурація: `vitest.e2e.config.ts` -- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` та E2E-тести вбудованих plugin під `extensions/` -- Типові параметри середовища виконання: - - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію. +- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести bundled-plugin у `extensions/` +- Типові параметри виконання: + - Використовує Vitest `threads` з `isolate: false`, відповідно до решти репозиторію. - Використовує адаптивні workers (CI: до 2, локально: типово 1). - Типово запускається в тихому режимі, щоб зменшити накладні витрати консольного I/O. - Корисні перевизначення: - `OPENCLAW_E2E_WORKERS=` для примусового задання кількості workers (обмежено 16). - `OPENCLAW_E2E_VERBOSE=1` для повторного ввімкнення докладного консольного виводу. - Область: - - Наскрізна поведінка Gateway з кількома інстансами - - Поверхні WebSocket/HTTP, сполучення вузлів і важчі мережеві сценарії + - Наскрізна поведінка багатоекземплярного Gateway + - Поверхні WebSocket/HTTP, спарювання вузлів і важча мережева взаємодія - Очікування: - Запускається в CI (коли ввімкнено в pipeline) - Реальні ключі не потрібні - - Більше рухомих частин, ніж у unit-тестах (може бути повільніше) + - Більше рухомих частин, ніж у модульних тестах (може бути повільніше) -### E2E: smoke-перевірка бекенду OpenShell +### E2E: smoke-тест бекенду OpenShell - Команда: `pnpm test:e2e:openshell` - Файл: `extensions/openshell/src/backend.e2e.test.ts` - Область: - Запускає ізольований OpenShell Gateway на хості через Docker - Створює sandbox із тимчасового локального Dockerfile - - Перевіряє бекенд OpenShell в OpenClaw через реальні `sandbox ssh-config` + SSH exec + - Перевіряє бекенд OpenShell в OpenClaw через справжні `sandbox ssh-config` + SSH exec - Перевіряє remote-canonical поведінку файлової системи через sandbox fs bridge - Очікування: - - Лише за явним увімкненням; не входить до типового запуску `pnpm test:e2e` + - Лише opt-in; не входить до типового запуску `pnpm test:e2e` - Потребує локального `openshell` CLI та робочого Docker daemon - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує тестовий Gateway і sandbox - Корисні перевизначення: - `OPENCLAW_E2E_OPENSHELL=1` для ввімкнення тесту під час ручного запуску ширшого e2e-набору - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` для вказання нестандартного CLI-бінарника або wrapper-скрипта -### Live (реальні провайдери + реальні моделі) +### Живі (реальні провайдери + реальні моделі) - Команда: `pnpm test:live` - Конфігурація: `vitest.live.config.ts` -- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` та live-тести вбудованих plugin під `extensions/` +- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і живі тести bundled-plugin у `extensions/` - Типово: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`) - Область: - - “Чи справді цей провайдер/модель працює _сьогодні_ з реальними обліковими даними?” - - Виявлення змін формату провайдера, особливостей tool calling, проблем автентифікації та поведінки rate limit + - “Чи цей провайдер/модель справді працює _сьогодні_ зі справжніми обліковими даними?” + - Виявлення змін форматів провайдерів, особливостей tool-calling, проблем автентифікації та поведінки rate limit - Очікування: - За задумом не є стабільним для CI (реальні мережі, реальні політики провайдерів, квоти, збої) - Коштує грошей / використовує rate limits - - Краще запускати звужені підмножини, а не “все” -- Live-запуски завантажують `~/.profile`, щоб підхопити відсутні API-ключі. -- Типово live-запуски все одно ізолюють `HOME` і копіюють конфігурацію/матеріали автентифікації в тимчасовий тестовий home, щоб unit-фікстури не могли змінити ваш реальний `~/.openclaw`. -- Встановлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли навмисно потрібно, щоб live-тести використовували вашу реальну домашню директорію. -- `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: - - Live-набори тепер виводять progress-рядки в stderr, щоб довгі виклики провайдера були помітно активними навіть тоді, коли консольне захоплення Vitest тихе. - - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, щоб progress-рядки провайдера/Gateway одразу транслювалися під час live-запусків. - - Налаштовуйте heartbeat для direct-model через `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Налаштовуйте heartbeat для Gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. + - Надавайте перевагу запуску звужених піднаборів замість “усього” +- Живі запуски підвантажують `~/.profile`, щоб отримати відсутні API-ключі. +- Типово живі запуски все одно ізолюють `HOME` і копіюють матеріали config/auth у тимчасовий тестовий home, щоб модульні fixtures не могли змінити ваш справжній `~/.openclaw`. +- Встановлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли навмисно потрібно, щоб живі тести використовували ваш справжній домашній каталог. +- `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`) або перевизначення для live через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу при відповідях rate limit. +- Вивід прогресу/Heartbeat: + - Живі набори тепер виводять рядки прогресу в stderr, тож тривалі виклики провайдерів помітно активні навіть коли захоплення консолі Vitest тихе. + - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, щоб рядки прогресу провайдера/Gateway транслювалися одразу під час живих запусків. + - Налаштовуйте Heartbeat для direct-model через `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Налаштовуйте Heartbeat для gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. -## Який набір запускати? +## Який набір слід запускати? -Скористайтеся цією таблицею рішень: +Використовуйте цю таблицю рішень: -- Редагуєте логіку/тести: запустіть `pnpm test` (і `pnpm test:coverage`, якщо змінили багато) -- Торкаєтеся мережевої частини Gateway / WS-протоколу / pairing: додайте `pnpm test:e2e` -- Налагоджуєте “мій bot не працює” / помилки, специфічні для провайдера / tool calling: запустіть звужений `pnpm test:live` +- Редагування логіки/тестів: запустіть `pnpm test` (і `pnpm test:coverage`, якщо ви змінили багато) +- Зміна мережевої взаємодії Gateway / WS-протоколу / спарювання: додайте `pnpm test:e2e` +- Налагодження “мій бот не працює” / специфічних для провайдера збоїв / tool calling: запустіть звужений `pnpm test:live` -## Live-тести (що торкаються мережі) +## Живі (мережеві) тести -Для live model matrix, smoke-перевірок CLI-бекенду, smoke-перевірок ACP, harness Codex app-server -та всіх live-тестів media-provider (Deepgram, BytePlus, ComfyUI, image, -music, video, media harness) — а також обробки облікових даних для live-запусків — див. -[Тестування live-наборів](/uk/help/testing-live). Для спеціального чекліста оновлень і -перевірки plugin див. +Для live model matrix, smoke-тестів CLI-бекенду, smoke-тестів ACP, harness app-server Codex +і всіх живих тестів медіапровайдерів (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 поділяються на дві групи: -- 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`, якщо змонтовано). Відповідні локальні entrypoints: `test:live:models-profiles` і `test:live:gateway-profiles`. -- Docker live runners типово використовують менший smoke-ліміт, щоб повний Docker sweep залишався практичним: +- 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 dir і 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 image через `test:docker:live-build`, один раз пакує OpenClaw як npm tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/перевикористовує два образи `scripts/e2e/Dockerfile`. Bare image — це лише Node/Git runner для install/update/plugin-dependency lanes; ці lanes монтують попередньо зібраний tarball. Functional image встановлює той самий 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` виконує вибраний plan. Агрегат використовує weighted local 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`, щоб надрукувати weighted lane manifest без складання або запуску Docker, або `node scripts/test-docker-all.mjs --plan-json`, щоб надрукувати CI plan для вибраних lanes, потреб package/image і облікових даних. -- `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) щодо contract package/update/plugin, матриці published-upgrade survivor, release defaults і failure triage. -- Build and release checks запускають `scripts/check-cli-bootstrap-imports.mjs` після tsdown. Guard обходить статичний built graph від `dist/entry.js` і `dist/cli/run-main.js` та падає, якщо startup до dispatch імпортує 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 command. -- Legacy-сумісність Package Acceptance обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цього cutoff harness допускає лише прогалини metadata shipped-package: пропущені private QA inventory entries, відсутній `gateway install --wrapper`, відсутні patch files у tarball-derived git fixture, відсутній persisted `update.channel`, legacy plugin install-record locations, відсутня persistence marketplace install-record і міграція config metadata під час `plugins update`. Для packages після `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:plugin-lifecycle-matrix` і `test:docker:config-reload` завантажують один або кілька реальних containers і перевіряють high-level integration paths. +- `test:docker:all` один раз збирає live Docker image через `test:docker:live-build`, один раз пакує OpenClaw як npm tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Bare image є лише Node/Git runner для install/update/plugin-dependency lanes; ці lanes монтують попередньо зібраний tarball. Functional image встановлює той самий 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` виконує вибраний plan. Агрегат використовує weighted local scheduler: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує process slots, тоді як resource caps не дають heavy 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`, щоб надрукувати weighted lane manifest без збирання чи запуску Docker, або `node scripts/test-docker-all.mjs --plan-json`, щоб надрукувати CI plan для вибраних lanes, потреб package/image і облікових даних. +- `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, published-upgrade survivor matrix, типових параметрів release і triage збоїв. +- Перевірки build і release запускають `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 обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цієї межі harness допускає лише прогалини shipped-package metadata: пропущені private QA inventory entries, відсутній `gateway install --wrapper`, відсутні patch files у tarball-derived git fixture, відсутній persisted `update.channel`, legacy plugin install-record locations, відсутня marketplace install-record persistence і config metadata migration під час `plugins update`. Для пакетів після `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:plugin-lifecycle-matrix` і `test:docker:config-reload` запускають один або більше реальних containers і перевіряють інтеграційні шляхи вищого рівня. -Live-model Docker runners також bind-mount лише потрібні CLI auth homes (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у container home перед запуском, щоб external-CLI OAuth міг оновлювати tokens без зміни host auth store: +Live-model Docker runners також bind-mount лише потрібні CLI auth homes (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у container home перед запуском, щоб external-CLI OAuth міг оновлювати tokens, не змінюючи auth store хоста: - Прямі моделі: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`) -- Smoke-перевірка прив’язки ACP: `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`) -- Smoke-перевірка бекенда CLI: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) -- Smoke-перевірка harness сервера застосунку Codex: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) -- Gateway + агент розробки: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`) -- Smoke-перевірка спостережуваності: `pnpm qa:otel:smoke` — це приватна QA-гілка перевірки вихідного checkout. Її навмисно не включено до пакетних Docker-гілок релізу, бо npm tarball не містить QA Lab. -- Live smoke Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) -- Майстер onboarding (TTY, повне scaffolding): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) -- Smoke-перевірка npm tarball onboarding/каналу/агента: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований tarball OpenClaw у Docker, налаштовує OpenAI через env-ref onboarding і типово Telegram, запускає doctor та виконує один мокований хід агента OpenAI. Повторно використайте попередньо зібраний tarball із `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть перебудову на хості через `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або перемкніть канал через `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. -- Smoke-перевірка перемикання каналу оновлень: `pnpm test:docker:update-channel-switch` глобально встановлює запакований tarball OpenClaw у Docker, перемикається з пакета `stable` на git `dev`, перевіряє збережений канал і роботу Plugin після оновлення, потім перемикається назад на пакет `stable` і перевіряє статус оновлення. -- Smoke-перевірка збереження після оновлення: `pnpm test:docker:upgrade-survivor` встановлює запакований tarball OpenClaw поверх забрудненого фікстурного стану старого користувача з агентами, конфігурацією каналу, allowlist Plugin, застарілим станом залежностей Plugin і наявними файлами workspace/сесій. Вона запускає оновлення пакета та неінтерактивний doctor без live ключів провайдера чи каналу, потім запускає loopback Gateway і перевіряє збереження конфігурації/стану, а також бюджети запуску/статусу. -- Smoke-перевірка збереження після опублікованого оновлення: `pnpm test:docker:published-upgrade-survivor` типово встановлює `openclaw@latest`, засіває реалістичні файли наявного користувача, налаштовує цей базовий стан за допомогою вбудованого рецепта команд, перевіряє отриману конфігурацію, оновлює це опубліковане встановлення до tarball кандидата, запускає неінтерактивний doctor, записує `.artifacts/upgrade-survivor/summary.json`, потім запускає loopback Gateway і перевіряє налаштовані intents, збереження стану, запуск, `/healthz`, `/readyz` і бюджети статусу RPC. Перевизначте один базовий стан через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, попросіть aggregate scheduler розгорнути точні базові стани через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, наприклад `all-since-2026.4.23`, і розгорніть фікстури у формі issue через `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`. -- Smoke-перевірка runtime-контексту сесії: `pnpm test:docker:session-runtime-context` перевіряє збереження transcript прихованого runtime-контексту та ремонт doctor для уражених дубльованих гілок prompt-rewrite. -- Smoke-перевірка глобального встановлення Bun: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольованому home і перевіряє, що `openclaw infer image providers --json` повертає вбудованих провайдерів зображень замість зависання. Повторно використайте попередньо зібраний 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`. -- Smoke-перевірка Docker інсталятора: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm cache між root, update і direct-npm контейнерами. Update smoke типово використовує npm `latest` як стабільний базовий стан перед оновленням до tarball кандидата. Перевизначте локально через `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` або через input `update_baseline_version` workflow Install Smoke на GitHub. Перевірки інсталятора без root зберігають ізольований npm cache, щоб записи cache, власником яких є root, не маскували поведінку встановлення в локальному середовищі користувача. Установіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати cache root/update/direct-npm між локальними повторними запусками. +- Smoke-тест прив’язування ACP: `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`) +- Smoke-тест бекенда CLI: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) +- Smoke-тест обв’язки сервера застосунку Codex: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) +- Gateway + dev-агент: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`) +- Smoke-тест спостережуваності: `pnpm qa:otel:smoke` — це приватна QA-гілка перевірки з checkout вихідного коду. Її навмисно не включено до Docker-гілок випуску пакета, бо npm-тарбол не містить QA Lab. +- Живий smoke-тест Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) +- Майстер онбордингу (TTY, повне створення каркаса): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) +- Smoke-тест онбордингу/каналу/агента з npm-тарбола: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований тарбол OpenClaw у Docker, налаштовує OpenAI через онбординг з посиланням на env, а також типово Telegram, запускає doctor і виконує один замоканий хід агента OpenAI. Повторно використовуйте попередньо зібраний тарбол із `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропускайте перебудову на хості через `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або перемикайте канал за допомогою `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. +- Smoke-тест перемикання каналу оновлень: `pnpm test:docker:update-channel-switch` глобально встановлює запакований тарбол OpenClaw у Docker, перемикається з пакетного `stable` на git `dev`, перевіряє збережений канал і роботу plugin після оновлення, потім перемикається назад на пакетний `stable` і перевіряє статус оновлення. +- Smoke-тест стійкості після оновлення: `pnpm test:docker:upgrade-survivor` встановлює запакований тарбол OpenClaw поверх забрудненого фікстура старого користувача з агентами, конфігурацією каналів, allowlist-ами plugin, застарілим станом залежностей plugin і наявними файлами робочої області/сесії. Він запускає оновлення пакета плюс неінтерактивний doctor без живого провайдера або ключів каналу, потім стартує loopback Gateway і перевіряє збереження конфігурації/стану, а також бюджети запуску/статусу. +- Smoke-тест стійкості після оновлення з опублікованої версії: `pnpm test:docker:published-upgrade-survivor` типово встановлює `openclaw@latest`, засіває реалістичні файли наявного користувача, налаштовує цей базовий стан вбудованим рецептом команд, перевіряє отриману конфігурацію, оновлює це опубліковане встановлення до кандидатного тарбола, запускає неінтерактивний doctor, записує `.artifacts/upgrade-survivor/summary.json`, потім стартує loopback Gateway і перевіряє налаштовані intents, збереження стану, запуск, `/healthz`, `/readyz` і бюджети RPC-статусу. Перевизначте один базовий стан через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, попросіть агрегований планувальник розгорнути точні базові стани через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS`, наприклад `all-since-2026.4.23`, і розгорніть фікстури у формі issue через `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`; Full Release Validation використовує типовий latest-базовий стан у блокувальному шляху та розгортає до all-since/reported-issues лише для `run_release_soak=true` або `release_profile=full`. +- Smoke-тест runtime-контексту сесії: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого runtime-контексту в транскрипті плюс repair через doctor для уражених дубльованих гілок prompt-rewrite. +- Smoke-тест глобального встановлення Bun: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольованому home і перевіряє, що `openclaw infer image providers --json` повертає вбудованих провайдерів зображень, а не зависає. Повторно використовуйте попередньо зібраний тарбол із `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропускайте збірку на хості через `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або копіюйте `dist/` зі зібраного Docker-образу через `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. +- Docker-smoke інсталятора: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm-кеш між своїми root-, update- і direct-npm-контейнерами. Smoke-тест оновлення типово використовує npm `latest` як stable-базу перед оновленням до кандидатного тарбола. Перевизначте локально через `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` або через input `update_baseline_version` у workflow Install Smoke на GitHub. Перевірки інсталятора без root зберігають ізольований npm-кеш, щоб записи кешу, власником яких є root, не маскували поведінку користувацького локального встановлення. Задайте `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати кеш root/update/direct-npm між локальними перезапусками. - Install Smoke CI пропускає дубльоване глобальне оновлення direct-npm через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`. -- Smoke-перевірка CLI видалення спільного workspace агентів: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) типово збирає image з кореневого Dockerfile, засіває двох агентів з одним workspace в ізольованому container home, запускає `agents delete --json` і перевіряє валідний JSON та поведінку збереженого workspace. Повторно використайте image install-smoke через `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. -- Мережа Gateway (два контейнери, auth WS + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) -- Smoke-перевірка browser CDP snapshot: `pnpm test:docker:browser-cdp-snapshot` (скрипт: `scripts/e2e/browser-cdp-snapshot-docker.sh`) збирає source E2E image разом із шаром Chromium, запускає Chromium із raw CDP, виконує `browser doctor --deep` і перевіряє, що snapshot ролей CDP охоплюють URL посилань, clickables, підвищені курсором, iframe refs і метадані frame. -- Регресія OpenAI Responses web_search minimal reasoning: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає мокований сервер OpenAI через Gateway, перевіряє, що `web_search` піднімає `reasoning.effort` з `minimal` до `low`, потім примусово викликає reject схеми провайдера й перевіряє, що raw detail з’являється в логах Gateway. -- Міст MCP каналу (засіяний Gateway + stdio bridge + smoke-перевірка raw notification-frame Claude): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) -- MCP інструменти Pi bundle (реальний stdio MCP server + smoke-перевірка allow/deny вбудованого профілю Pi): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) -- Очищення Cron/subagent MCP (реальний Gateway + teardown дочірнього stdio MCP після ізольованого cron і one-shot запусків subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Plugins (smoke-перевірка install/update для local path, `file:`, npm registry з hoisted dependencies, git moving refs, ClawHub kitchen-sink, marketplace updates і enable/inspect Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) - Установіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб пропустити блок ClawHub, або перевизначте типову пару package/runtime kitchen-sink через `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` і `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Без `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` тест використовує герметичний локальний сервер фікстури ClawHub. -- Smoke-перевірка незмінного оновлення Plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) -- Smoke-перевірка матриці життєвого циклу Plugin: `pnpm test:docker:plugin-lifecycle-matrix` встановлює запакований tarball OpenClaw у порожньому контейнері, встановлює npm Plugin, перемикає enable/disable, оновлює й відкотить його через локальний npm registry, видаляє встановлений код, потім перевіряє, що uninstall все одно видаляє застарілий стан, одночасно логуючи метрики RSS/CPU для кожної фази життєвого циклу. -- Smoke-перевірка metadata перезавантаження конфігурації: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) -- Plugins: `pnpm test:docker:plugins` охоплює smoke-перевірку install/update для local path, `file:`, npm registry з hoisted dependencies, git moving refs, фікстур ClawHub, marketplace updates і enable/inspect Claude-bundle. `pnpm test:docker:plugin-update` охоплює поведінку незмінного оновлення встановлених Plugin. `pnpm test:docker:plugin-lifecycle-matrix` охоплює відстежувані за ресурсами встановлення, enable, disable, upgrade, downgrade npm Plugin і uninstall за відсутнього коду. +- Smoke-тест CLI видалення агентами спільної робочої області: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) типово збирає образ кореневого Dockerfile, засіває двох агентів з однією робочою областю в ізольованому container home, запускає `agents delete --json` і перевіряє валідний JSON плюс поведінку збереженої робочої області. Повторно використовуйте install-smoke-образ через `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. +- Мережа Gateway (два контейнери, WS-автентифікація + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) +- Smoke-тест CDP-знімка браузера: `pnpm test:docker:browser-cdp-snapshot` (скрипт: `scripts/e2e/browser-cdp-snapshot-docker.sh`) збирає вихідний E2E-образ плюс шар Chromium, запускає Chromium із сирим CDP, виконує `browser doctor --deep` і перевіряє, що CDP-знімки ролей охоплюють URL посилань, clickable-елементи, підвищені курсором, refs iframe і метадані frame. +- Регресія мінімального reasoning для OpenAI Responses web_search: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає замоканий сервер OpenAI через Gateway, перевіряє, що `web_search` піднімає `reasoning.effort` з `minimal` до `low`, потім примусово викликає відхилення схеми провайдером і перевіряє, що сирі подробиці з’являються в логах Gateway. +- Міст каналу MCP (засіяний Gateway + stdio-міст + smoke-тест сирого notification-frame Claude): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) +- MCP-інструменти Pi bundle (реальний stdio MCP-сервер + smoke-тест вбудованого Pi-профілю allow/deny): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) +- Очищення Cron/subagent MCP (реальний Gateway + завершення stdio MCP-дочірнього процесу після ізольованого cron і одноразових запусків subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Plugins (smoke-тест встановлення/оновлення для локального шляху, `file:`, npm registry з hoisted-залежностями, рухомих git refs, ClawHub kitchen-sink, marketplace-оновлень і ввімкнення/інспекції Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) + Задайте `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб пропустити блок ClawHub, або перевизначте типову пару package/runtime для kitchen-sink через `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` і `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Без `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` тест використовує герметичний локальний сервер фікстур ClawHub. +- Smoke-тест незміненого оновлення plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) +- Smoke-тест матриці життєвого циклу Plugin: `pnpm test:docker:plugin-lifecycle-matrix` встановлює запакований тарбол OpenClaw у порожній контейнер, встановлює npm plugin, перемикає enable/disable, оновлює та понижує його версію через локальний npm registry, видаляє встановлений код, потім перевіряє, що uninstall усе ще прибирає застарілий стан, паралельно логуючи метрики RSS/CPU для кожної фази життєвого циклу. +- Smoke-тест metadata reload конфігурації: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) +- Plugins: `pnpm test:docker:plugins` охоплює smoke-тест встановлення/оновлення для локального шляху, `file:`, npm registry з hoisted-залежностями, рухомих git refs, фікстур ClawHub, marketplace-оновлень і ввімкнення/інспекції Claude-bundle. `pnpm test:docker:plugin-update` охоплює поведінку незміненого оновлення для встановлених plugins. `pnpm test:docker:plugin-lifecycle-matrix` охоплює встановлення, enable, disable, upgrade, downgrade і uninstall відсутнього коду для npm plugin з відстеженням ресурсів. -Щоб вручну попередньо зібрати й повторно використати спільний 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 ``` -Специфічні для suite перевизначення image, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе ще мають пріоритет, коли встановлені. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний image, скрипти завантажують його, якщо він ще не локальний. Docker тести QR та інсталятора зберігають власні Dockerfile, бо вони перевіряють поведінку package/install, а не спільний runtime зібраного застосунку. +Перевизначення образів для окремих наборів, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе одно мають пріоритет, коли задані. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний образ, скрипти завантажують його, якщо він ще не локальний. Docker-тести QR та інсталятора зберігають власні Dockerfile, бо вони перевіряють поведінку пакета/встановлення, а не спільний runtime зібраного застосунку. -Docker-ранери для live-моделей також bind-mount-ять поточний checkout у режимі лише для читання та -розгортають його в тимчасовий workdir усередині контейнера. Це зберігає runtime -image компактним, водночас запускаючи Vitest проти вашого точного локального source/config. -Крок розгортання пропускає великі локальні кеші та вихідні файли збірки застосунків, як-от -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також app-local `.build` або -каталоги виводу Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання -machine-specific артефактів. -Вони також задають `OPENCLAW_SKIP_CHANNELS=1`, щоб gateway live probes не запускали -реальні Telegram/Discord тощо channel workers усередині контейнера. -`test:docker:live-models` усе ще запускає `pnpm test:live`, тому також передавайте -`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити gateway -live-покриття з цієї Docker lane. -`test:docker:openwebui` — це smoke-тест сумісності вищого рівня: він запускає -контейнер Gateway OpenClaw з увімкненими OpenAI-сумісними HTTP endpoints, -запускає закріплений контейнер Open WebUI проти цього Gateway, входить через -Open WebUI, перевіряє, що `/api/models` відкриває `openclaw/default`, а потім надсилає -реальний chat request через proxy Open WebUI `/api/chat/completions`. +Docker-ранери live-model також монтують поточний checkout лише для читання та +розгортають його в тимчасовий робочий каталог усередині контейнера. Це зберігає +runtime-образ компактним, але водночас запускає Vitest саме проти вашого локального source/config. +Етап підготовки пропускає великі локальні кеші та вихідні дані збірки застосунків, як-от +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також локальні для застосунків каталоги `.build` або +вихідні каталоги Gradle, щоб live-запуски Docker не витрачали хвилини на копіювання +машинно-специфічних артефактів. +Вони також встановлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб live-зонди Gateway не запускали +реальні робочі процеси каналів Telegram/Discord/тощо всередині контейнера. +`test:docker:live-models` усе ще запускає `pnpm test:live`, тому передавайте також +`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити live-покриття Gateway +з цієї Docker-лінії. +`test:docker:openwebui` — це суміснісний smoke вищого рівня: він запускає +контейнер Gateway OpenClaw з увімкненими HTTP-ендпоінтами, сумісними з OpenAI, +запускає закріплений контейнер Open WebUI проти цього Gateway, виконує вхід через +Open WebUI, перевіряє, що `/api/models` exposes `openclaw/default`, а потім надсилає +реальний запит чату через proxy `/api/chat/completions` Open WebUI. Перший запуск може бути помітно повільнішим, бо Docker може знадобитися завантажити -image Open WebUI, а Open WebUI може знадобитися завершити власне налаштування cold-start. -Ця lane очікує придатний live model key, а `OPENCLAW_PROFILE_FILE` -(`~/.profile` за замовчуванням) є основним способом надати його в Dockerized runs. -Успішні запуски друкують невеликий JSON payload на кшталт `{ "ok": true, "model": +образ Open WebUI, а Open WebUI може знадобитися завершити власне налаштування cold-start. +Ця лінія очікує придатний ключ live-моделі, а `OPENCLAW_PROFILE_FILE` +(`~/.profile` за замовчуванням) є основним способом надати його в Dockerized-запусках. +Успішні запуски друкують невелике JSON-навантаження на кшталт `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` навмисно детермінований і не потребує -реального облікового запису Telegram, Discord або iMessage. Він завантажує seeded контейнер Gateway, -запускає другий контейнер, який породжує `openclaw mcp serve`, а потім -перевіряє виявлення routed conversation, читання transcript, metadata attachment, -поведінку live event queue, outbound send routing і channel + -permission notifications у стилі Claude через реальний stdio MCP bridge. Перевірка notifications -безпосередньо інспектує сирі stdio MCP frames, тому smoke-тест перевіряє те, що -bridge фактично видає, а не лише те, що випадково показує конкретний client SDK. -`test:docker:pi-bundle-mcp-tools` детермінований і не потребує live -model key. Він збирає Docker image репозиторію, запускає реальний stdio MCP probe server -усередині контейнера, матеріалізує цей server через embedded Pi bundle -MCP runtime, виконує tool, а потім перевіряє, що `coding` і `messaging` зберігають -tools `bundle-mcp`, тоді як `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`, а потім перевіряє, -що MCP child process завершується після кожного запуску. +реального облікового запису Telegram, Discord або iMessage. Він запускає контейнер Gateway +із початковими даними, запускає другий контейнер, який породжує `openclaw mcp serve`, а потім +перевіряє маршрутизоване виявлення розмов, читання транскриптів, метадані вкладень, +поведінку live-черги подій, маршрутизацію вихідного надсилання та сповіщення каналу + +дозволів у стилі Claude через справжній stdio MCP bridge. Перевірка сповіщень +безпосередньо інспектує сирі stdio MCP frames, тож smoke перевіряє те, що +bridge фактично emits, а не лише те, що випадково показує конкретний client SDK. +`test:docker:pi-bundle-mcp-tools` детермінований і не потребує ключа live-моделі. +Він збирає Docker-образ repo, запускає справжній stdio MCP probe server +усередині контейнера, матеріалізує цей сервер через вбудований runtime MCP bundle Pi, +виконує інструмент, а потім перевіряє, що `coding` і `messaging` зберігають +інструменти `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують. +`test:docker:cron-mcp-cleanup` детермінований і не потребує ключа live-моделі. +Він запускає Gateway із початковими даними зі справжнім stdio MCP probe server, виконує +ізольований cron-хід і одноразовий дочірній хід `/subagents spawn`, а потім перевіряє, +що дочірній процес MCP завершується після кожного запуску. -Ручний ACP plain-language thread smoke-тест (не CI): +Ручний ACP smoke потоку простою мовою (не CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Зберігайте цей script для regression/debug workflows. Він може знову знадобитися для валідації ACP thread routing, тому не видаляйте його. +- Зберігайте цей скрипт для регресійних/debug workflows. Він може знову знадобитися для валідації маршрутизації потоків ACP, тому не видаляйте його. Корисні змінні середовища: -- `OPENCLAW_CONFIG_DIR=...` (за замовчуванням: `~/.openclaw`) mounted до `/home/node/.openclaw` -- `OPENCLAW_WORKSPACE_DIR=...` (за замовчуванням: `~/.openclaw/workspace`) mounted до `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (за замовчуванням: `~/.profile`) mounted до `/home/node/.profile` і sourced перед запуском tests -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1` для перевірки лише env vars, sourced з `OPENCLAW_PROFILE_FILE`, з використанням тимчасових config/workspace dirs і без external CLI auth mounts -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) mounted до `/home/node/.npm-global` для кешованих CLI installs усередині Docker -- External CLI auth dirs/files у `$HOME` mounted у режимі read-only під `/host-auth...`, а потім копіюються в `/home/node/...` перед початком tests - - Default dirs: `.minimax` - - Default files: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - - Narrowed provider runs монтують лише потрібні dirs/files, inferred з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - - Перевизначте вручну за допомогою `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або comma list на кшталт `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` +- `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`, з використанням тимчасових каталогів config/workspace і без зовнішніх монтувань auth CLI +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) монтується в `/home/node/.npm-global` для кешованих встановлень CLI усередині Docker +- Зовнішні каталоги/файли auth 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` + - Звужені запуски provider монтують лише потрібні каталоги/файли, виведені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` + - Перевизначайте вручну за допомогою `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=...` для фільтрації providers in-container -- `OPENCLAW_SKIP_DOCKER_BUILD=1` для повторного використання наявного image `openclaw:local-live` для reruns, яким не потрібна повторна збірка -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` для гарантії, що creds надходять із profile store (а не env) -- `OPENCLAW_OPENWEBUI_MODEL=...` для вибору model, яку Gateway відкриває для smoke-тесту Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...` для перевизначення nonce-check prompt, що використовується smoke-тестом Open WebUI -- `OPENWEBUI_IMAGE=...` для перевизначення закріпленого image tag Open WebUI +- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` для фільтрації providers у контейнері +- `OPENCLAW_SKIP_DOCKER_BUILD=1` для повторного використання наявного образу `openclaw:local-live` для повторних запусків, які не потребують перескладання +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` для гарантії, що облікові дані походять зі сховища профілю (не з env) +- `OPENCLAW_OPENWEBUI_MODEL=...` для вибору моделі, яку Gateway exposes для smoke Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...` для перевизначення nonce-check промпта, який використовує smoke Open WebUI +- `OPENWEBUI_IMAGE=...` для перевизначення закріпленого тегу образу Open WebUI -## Перевірка документації +## Санітарна перевірка docs -Запускайте перевірки документації після редагування docs: `pnpm check:docs`. -Запускайте повну валідацію anchors Mintlify, коли також потрібні перевірки in-page headings: `pnpm docs:check-links:anchors`. +Запускайте перевірки docs після редагувань docs: `pnpm check:docs`. +Запускайте повну валідацію anchors Mintlify, коли потрібні також перевірки заголовків на сторінці: `pnpm docs:check-links:anchors`. ## Офлайн-регресія (CI-safe) -Це регресії «real pipeline» без реальних providers: +Це регресії “реального pipeline” без реальних providers: -- Gateway tool calling (mock OpenAI, реальний Gateway + agent loop): `src/gateway/gateway.test.ts` (case: "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Gateway wizard (WS `wizard.start`/`wizard.next`, записує config + auth enforced): `src/gateway/gateway.test.ts` (case: "runs wizard over ws and writes auth token config") +- Виклик інструментів Gateway (mock OpenAI, реальний gateway + agent loop): `src/gateway/gateway.test.ts` (case: "runs a mock OpenAI tool call end-to-end via gateway agent loop") +- Майстер Gateway (WS `wizard.start`/`wizard.next`, записує config + auth enforced): `src/gateway/gateway.test.ts` (case: "runs wizard over ws and writes auth token config") -## Agent reliability evals (Skills) +## Оцінювання надійності agent (skills) -У нас уже є кілька CI-safe tests, які поводяться як «agent reliability evals»: +У нас уже є кілька CI-safe тестів, які поводяться як “agent reliability evals”: -- Mock tool-calling через реальний Gateway + agent loop (`src/gateway/gateway.test.ts`). -- End-to-end wizard flows, які перевіряють session wiring і config effects (`src/gateway/gateway.test.ts`). +- Mock tool-calling через реальний gateway + agent loop (`src/gateway/gateway.test.ts`). +- End-to-end wizard flows, які перевіряють session wiring і наслідки config (`src/gateway/gateway.test.ts`). -Чого ще бракує для Skills (див. [Skills](/uk/tools/skills)): +Чого ще бракує для skills (див. [Skills](/uk/tools/skills)): -- **Прийняття рішень:** коли skills перелічені в prompt, чи вибирає agent правильний skill (або уникає нерелевантних)? -- **Відповідність вимогам:** чи читає agent `SKILL.md` перед використанням і чи виконує required steps/args? -- **Workflow contracts:** multi-turn scenarios, які assert-ять tool order, session history carryover і sandbox boundaries. +- **Decisioning:** коли skills перелічені в prompt, чи вибирає agent правильний skill (або уникає нерелевантних)? +- **Compliance:** чи читає agent `SKILL.md` перед використанням і чи виконує required steps/args? +- **Workflow contracts:** multi-turn сценарії, які перевіряють tool order, session history carryover і sandbox boundaries. -Майбутні evals мають спочатку лишатися детермінованими: +Майбутні evals насамперед мають залишатися детермінованими: -- Scenario runner з mock providers для assert tool calls + order, skill file reads і session wiring. -- Невеликий suite skill-focused scenarios (use vs avoid, gating, prompt injection). -- Optional live evals (opt-in, env-gated) лише після того, як CI-safe suite буде на місці. +- Scenario runner із mock providers для перевірки tool calls + order, читання skill file і session wiring. +- Невеликий набір skill-focused scenarios (use vs avoid, gating, prompt injection). +- Необов’язкові live evals (opt-in, env-gated) лише після появи CI-safe набору. -## Contract tests (plugin and channel shape) +## Contract tests (форма Plugin і channel) Contract tests перевіряють, що кожен зареєстрований Plugin і channel відповідає своєму -interface contract. Вони ітерують усі виявлені plugins і запускають suite -assertions для shape і behavior. Default unit lane `pnpm test` навмисно -пропускає ці shared seam і smoke files; запускайте contract commands явно, -коли змінюєте shared channel або provider surfaces. +interface contract. Вони проходять усі виявлені plugins і запускають набір +shape and behavior assertions. Стандартна unit-лінія `pnpm test` навмисно +пропускає ці shared seam і smoke файли; запускайте contract-команди явно, +коли торкаєтеся shared channel або provider surfaces. -### Commands +### Команди - Усі contracts: `pnpm test:contracts` - Лише channel contracts: `pnpm test:contracts:channels` @@ -788,59 +790,59 @@ assertions для shape і behavior. Default unit lane `pnpm test` навмис Розташовані в `src/channels/plugins/contracts/*.contract.test.ts`: -- **plugin** - Базова shape Plugin (id, name, capabilities) -- **setup** - Contract setup wizard -- **session-binding** - Поведінка session binding -- **outbound-payload** - Структура message payload -- **inbound** - Обробка inbound message -- **actions** - Channel action handlers -- **threading** - Обробка Thread ID +- **plugin** - Базова форма Plugin (id, name, capabilities) +- **setup** - Контракт майстра налаштування +- **session-binding** - Поведінка прив’язки session +- **outbound-payload** - Структура payload повідомлення +- **inbound** - Обробка вхідних повідомлень +- **actions** - Обробники дій channel +- **threading** - Обробка thread ID - **directory** - API directory/roster -- **group-policy** - Застосування group policy +- **group-policy** - Забезпечення group policy -### Provider status contracts +### Контракти статусу provider Розташовані в `src/plugins/contracts/*.contract.test.ts`. -- **status** - Channel status probes -- **registry** - Shape registry Plugin +- **status** - Зонди статусу channel +- **registry** - Форма registry Plugin ### Provider contracts Розташовані в `src/plugins/contracts/*.contract.test.ts`: -- **auth** - Contract auth flow -- **auth-choice** - Auth choice/selection -- **catalog** - API model catalog +- **auth** - Контракт auth flow +- **auth-choice** - Вибір/selection auth +- **catalog** - API каталогу моделей - **discovery** - Виявлення Plugin - **loader** - Завантаження Plugin -- **runtime** - Provider runtime -- **shape** - Shape/interface Plugin -- **wizard** - Setup wizard +- **runtime** - Runtime provider +- **shape** - Форма/interface Plugin +- **wizard** - Майстер налаштування ### Коли запускати - Після зміни exports або subpaths plugin-sdk - Після додавання або зміни channel чи provider Plugin -- Після refactoring реєстрації або виявлення Plugin +- Після рефакторингу реєстрації або discovery Plugin Contract tests запускаються в CI і не потребують реальних API keys. -## Додавання регресій (настанови) +## Додавання регресій (guidance) -Коли ви виправляєте provider/model issue, виявлену live: +Коли виправляєте issue provider/model, виявлену live: -- Додайте CI-safe regression, якщо можливо (mock/stub provider або зафіксуйте точну request-shape transformation) -- Якщо це inherently live-only (rate limits, auth policies), тримайте live test вузьким і opt-in через env vars -- Віддавайте перевагу найменшому layer, який ловить bug: +- Додайте CI-safe regression, якщо можливо (mock/stub provider або зафіксуйте точне перетворення request-shape) +- Якщо вона за своєю природою лише live-only (rate limits, auth policies), тримайте live test вузьким і opt-in через env vars +- Надавайте перевагу найменшому шару, який ловить bug: - provider request conversion/replay bug → direct models test - gateway session/history/tool pipeline bug → gateway live smoke або CI-safe gateway mock test -- SecretRef traversal guardrail: - - `src/secrets/exec-secret-ref-id-parity.test.ts` derives one sampled target per SecretRef class з registry metadata (`listSecretTargetRegistryEntries()`), а потім asserts, що traversal-segment exec ids відхиляються. - - Якщо ви додаєте нову `includeInPlan` SecretRef target family у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому test. Test навмисно fails на unclassified target ids, щоб нові classes не могли бути skipped silently. +- Guardrail обходу SecretRef: + - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить один вибірковий target для кожного класу SecretRef із registry metadata (`listSecretTargetRegistryEntries()`), а потім asserts, що traversal-segment exec ids відхиляються. + - Якщо додаєте нову target family SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на unclassified target ids, щоб нові classes не можна було тихо пропустити. ## Пов’язане -- [Testing live](/uk/help/testing-live) -- [Testing updates and plugins](/uk/help/testing-updates-plugins) +- [Тестування live](/uk/help/testing-live) +- [Тестування оновлень і plugins](/uk/help/testing-updates-plugins) - [CI](/uk/ci) diff --git a/docs/uk/reference/RELEASING.md b/docs/uk/reference/RELEASING.md index 4b565725d..8a50e7d6c 100644 --- a/docs/uk/reference/RELEASING.md +++ b/docs/uk/reference/RELEASING.md @@ -1,267 +1,275 @@ --- read_when: - - Пошук визначень публічних каналів релізів - - Запуск перевірки релізу або приймального тестування пакета + - Шукаємо визначення публічних каналів випуску + - Запуск перевірки релізу або приймання пакета - Шукаєте іменування версій і періодичність випусків -summary: Канали релізів, контрольний список оператора, середовища валідації, іменування версій і періодичність +summary: Релізні лінії, контрольний список оператора, середовища валідації, іменування версій і періодичність title: Політика випусків x-i18n: - generated_at: "2026-05-04T06:33:42Z" + generated_at: "2026-05-04T22:29:51Z" model: gpt-5.5 provider: openai - source_hash: ef50d3ef5d1e23b4e2c2b097fc4ca9f6d46bf8acb9aea0c9bca6d14e213b88b6 + source_hash: fc9b8f82deb90c57c7777480013a5ee956d1123e0b16134daf90a94bc82952cb source_path: reference/RELEASING.md workflow: 16 --- OpenClaw має три публічні канали випусків: -- стабільний: теговані випуски, які типово публікуються в npm `beta`, або в npm `latest`, коли це явно запитано -- бета: теги попередніх випусків, які публікуються в npm `beta` -- розробка: рухома вершина `main` +- stable: теговані випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано +- beta: передрелізні теги, які публікуються в npm `beta` +- dev: рухома вершина `main` ## Іменування версій - Версія стабільного випуску: `YYYY.M.D` - Git-тег: `vYYYY.M.D` -- Версія корекційного стабільного випуску: `YYYY.M.D-N` +- Версія стабільного коригувального випуску: `YYYY.M.D-N` - Git-тег: `vYYYY.M.D-N` -- Версія бета-попереднього випуску: `YYYY.M.D-beta.N` +- Версія бета-передрелізу: `YYYY.M.D-beta.N` - Git-тег: `vYYYY.M.D-beta.N` -- Не додавайте початковий нуль до місяця або дня -- `latest` означає поточний просунутий стабільний npm-випуск +- Не додавайте нулі на початку місяця або дня +- `latest` означає поточний просунутий стабільний випуск npm - `beta` означає поточну ціль встановлення бета-версії -- Стабільні та корекційні стабільні випуски типово публікуються в npm `beta`; оператори випуску можуть явно націлити їх на `latest` або просунути перевірену бета-збірку пізніше -- Кожен стабільний випуск OpenClaw постачає npm-пакет і застосунок macOS разом; - бета-випуски зазвичай спершу перевіряють і публікують шлях npm/package, а - збирання/підпис/нотаризацію застосунку Mac залишають для стабільного випуску, якщо це явно не запитано +- Стабільні та стабільні коригувальні випуски за замовчуванням публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або пізніше просунути перевірену бета-збірку +- Кожен стабільний випуск OpenClaw постачається разом із npm-пакетом і застосунком macOS; + бета-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а + збірку/підпис/нотаризацію застосунку mac залишають для стабільного випуску, якщо це явно не запитано -## Каденція випусків +## Частота випусків -- Випуски рухаються спершу через бета-версію -- Стабільний випуск іде лише після перевірки останньої бета-версії -- Мейнтейнери зазвичай відгалужують випуски з гілки `release/YYYY.M.D`, створеної +- Випуски рухаються спочатку через beta +- Stable виходить лише після перевірки останньої beta +- Супровідники зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної з поточного `main`, щоб перевірка випуску та виправлення не блокували нову розробку в `main` -- Якщо бета-тег уже надіслано або опубліковано й він потребує виправлення, мейнтейнери створюють - наступний тег `-beta.N` замість видалення чи повторного створення старого бета-тега -- Детальна процедура випуску, погодження, облікові дані та нотатки з відновлення - доступні лише мейнтейнерам +- Якщо beta-тег уже надіслано або опубліковано і потрібне виправлення, супровідники створюють + наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега +- Детальна процедура випуску, затвердження, облікові дані та нотатки з відновлення + призначені лише для супровідників ## Контрольний список оператора випуску -Цей контрольний список є публічною формою потоку випуску. Приватні облікові дані, +Цей контрольний список є публічною формою процесу випуску. Приватні облікові дані, підписування, нотаризація, відновлення dist-tag і деталі екстреного відкоту залишаються в -ранбуку випуску лише для мейнтейнерів. +release runbook лише для супровідників. 1. Почніть із поточного `main`: отримайте останні зміни, підтвердьте, що цільовий коміт надіслано, - і переконайтеся, що поточний CI `main` достатньо зелений, щоб відгалужуватися від нього. -2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії комітів за допомогою - `/changelog`, залиште записи орієнтованими на користувача, закомітьте його, надішліть і виконайте rebase/pull - ще раз перед відгалуженням. + і підтвердьте, що поточний CI для `main` достатньо зелений, щоб створити від нього гілку. +2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою + `/changelog`, залишайте записи орієнтованими на користувача, закомітьте його, надішліть і виконайте rebase/pull + ще раз перед створенням гілки. 3. Перегляньте записи сумісності випуску в `src/plugins/compat/registry.ts` і `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому її - навмисно збережено. -4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу з випуску + навмисно залишено. +4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском безпосередньо в `main`. -5. Підніміть версію в кожному потрібному місці для запланованого тега, запустіть - `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, профіль пакета, провайдера або список дозволених моделей, який - доводить виправлення. Перезапускайте повну парасольку лише тоді, коли змінена поверхня робить + для чотирьох великих тестових блоків випуску: Vitest, Docker, QA Lab і Package. +8. Якщо перевірка завершується невдало, виправте проблему в гілці випуску та повторно запустіть найменший невдалий + файл, канал, завдання workflow, профіль пакета, провайдера або allowlist моделі, що + доводить виправлення. Повторно запускайте весь umbrella лише тоді, коли змінена поверхня робить попередні докази застарілими. -9. Для бета-версії створіть тег `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з +9. Для beta позначте тегом `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з відповідної гілки `release/YYYY.M.D`. Він перевіряє `pnpm plugins:sync:check`, - спершу публікує всі публіковані пакети Plugin в npm, потім публікує той самий - набір у ClawHub як npm-pack tarballs ClawPack, а потім просуває - підготовлений артефакт попередньої перевірки OpenClaw npm з відповідним dist-tag. Після - публікації запустіть post-publish package - acceptance проти опублікованого пакета `openclaw@YYYY.M.D-beta.N` або - `openclaw@beta`. Якщо надісланий або опублікований попередній випуск потребує виправлення, - створіть наступний відповідний номер попереднього випуску; не видаляйте й не переписуйте старий - попередній випуск. -10. Для стабільного випуску продовжуйте лише після того, як перевірена бета-версія або кандидат у випуск матиме - потрібні докази перевірки. Стабільна публікація npm також проходить через - `OpenClaw Release Publish`, повторно використовуючи успішний артефакт попередньої перевірки через + спочатку публікує всі публіковні пакети Plugin в npm, потім публікує той самий + набір у ClawHub як tarball-и ClawPack npm-pack, а потім просуває + підготовлений preflight-артефакт OpenClaw npm з відповідним dist-tag. Після + публікації запустіть приймальну перевірку пакета після публікації + для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або + `openclaw@beta`. Якщо надісланий або опублікований передреліз потребує виправлення, + створіть наступний відповідний номер передрелізу; не видаляйте і не перезаписуйте старий + передреліз. +10. Для stable продовжуйте лише після того, як перевірена beta або release candidate має + необхідні докази перевірки. Публікація stable npm також проходить через + `OpenClaw Release Publish`, повторно використовуючи успішний preflight-артефакт через `preflight_run_id`; готовність стабільного випуску macOS також вимагає запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`. -11. Після публікації запустіть npm post-publish verifier, необов’язковий автономний +11. Після публікації запустіть npm-перевірник після публікації, необов’язковий автономний published-npm Telegram E2E, коли потрібен доказ каналу після публікації, просування dist-tag за потреби, нотатки GitHub release/prerelease з повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску. -## Попередня перевірка випуску +## Preflight випуску - Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався покритим поза швидшим локальним шлюзом `pnpm check` - Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів імпорту та архітектурних меж були зеленими поза швидшим локальним шлюзом - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані - релізні артефакти `dist/*` і бандл Control UI існували для кроку валідації - пакування -- Запустіть `pnpm plugins:sync` після підняття кореневої версії та перед тегуванням. Він - оновлює версії публікованих пакетів Plugin, метадані сумісності OpenClaw peer/API, - метадані збірки та заготовки журналів змін Plugin відповідно до версії основного - релізу. `pnpm plugins:sync:check` — це немодифікуючий релізний запобіжник; - workflow публікації завершується помилкою до будь-якої зміни реєстру, якщо цей крок - було забуто. + релізні артефакти `dist/*` і бандл Control UI існували для кроку + валідації пакування +- Запустіть `pnpm plugins:sync` після підвищення версії в корені й перед тегуванням. Він + оновлює версії пакетів придатних до публікації plugin, метадані сумісності + OpenClaw peer/API, метадані збірки та заготовки журналів змін plugin, щоб вони відповідали + версії основного релізу. `pnpm plugins:sync:check` — це немодифікувальний релізний запобіжник; + workflow публікації завершується помилкою до будь-якої мутації реєстру, якщо цей крок було + забуто. - Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку, тег або повний SHA коміту, запускає ручний `CI` і запускає - `OpenClaw Release Checks` для smoke-перевірки встановлення, приймання пакета, Docker - наборів для релізного шляху, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram - ліній. З `release_profile=full` і `rerun_group=all` він також запускає пакетний - Telegram E2E проти артефакту `release-package-under-test` із release checks. Передайте - `npm_telegram_package_spec` після публікації, коли той самий Telegram E2E має також - підтвердити опублікований npm-пакет. Передайте `package_acceptance_package_spec` після - публікації, коли Package Acceptance має виконати свою матрицю пакета/оновлення проти - відвантаженого npm-пакета замість артефакту, зібраного з SHA. Передайте - `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що валідація - відповідає опублікованому npm-пакету без примусового Telegram E2E. + `OpenClaw Release Checks` для install smoke, package acceptance, між-ОС + перевірок пакетів, паритету QA Lab, Matrix і Telegram lanes. Стабільні/типові запуски + тримають вичерпні live/E2E та Docker release-path soak за + `run_release_soak=true`; `release_profile=full` примусово вмикає soak. З + `release_profile=full` і `rerun_group=all` він також запускає package Telegram + E2E проти артефакту `release-package-under-test` із release 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`, коли потрібен додатковий бічний доказ +- Запустіть ручний workflow `Package Acceptance`, коли потрібен side-channel доказ для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для - `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`, щоб - запакувати довірену гілку/тег/SHA `package_ref` з поточним harness `workflow_ref`; - `source=url` для HTTPS tarball з обов’язковим SHA-256; або `source=artifact` для - tarball, завантаженого іншим запуском GitHub Actions. Workflow розв’язує кандидата в + `openclaw@beta`, `openclaw@latest` або точної версії релізу; `source=ref`, + щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним + harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим + SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub + Actions. Workflow визначає кандидата як `package-under-test`, повторно використовує Docker E2E release scheduler проти цього tarball і може запускати Telegram QA проти того самого tarball з - `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані Docker - лінії містять `published-upgrade-survivor`, артефакт пакета є кандидатом, а - `published_upgrade_survivor_baseline` вибирає опубліковану базову версію. + `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`: лінії встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації - - `package`: лінії пакета/оновлення/Plugin, нативні для артефакту, без OpenWebUI або live ClawHub - - `product`: профіль пакета плюс MCP-канали, очищення cron/субагентів, + - `smoke`: lanes встановлення/каналу/агента, мережі Gateway і перезавантаження конфігурації + - `package`: artifact-native lanes package/update/plugin без OpenWebUI або live ClawHub + - `product`: профіль package плюс MCP-канали, очищення cron/subagent, вебпошук OpenAI і OpenWebUI - - `full`: фрагменти Docker релізного шляху з OpenWebUI + - `full`: фрагменти Docker release-path з OpenWebUI - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску -- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI - для кандидата релізу. Ручні запуски CI обходять scoped-перевірки зміненого та примусово - запускають Linux Node shards, bundled-plugin shards, контракти каналів, сумісність - Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python skills, - Windows, macOS, Android і лінії Control UI i18n. +- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI + покриття для релізного кандидата. Ручні запуски CI обходять + changed scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel + contracts, сумісність Node 22, `check`, `check-additional`, build smoke, + перевірки docs, Python skills, Windows, macOS, Android і Control UI i18n + lanes. Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D` - Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Він проганяє - QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace span, - обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в Opik, Langfuse - або іншому зовнішньому collector. -- Запускайте `pnpm release:check` перед кожним тегованим релізом -- Запустіть `OpenClaw Release Publish` для модифікуючої послідовності публікації після - появи тегу. Запускайте його з `release/YYYY.M.D` (або `main`, коли публікуєте тег, - досяжний з main), передайте release tag і успішний OpenClaw npm `preflight_run_id`, - і залишайте стандартну область публікації Plugin `all-publishable`, якщо ви навмисно - не виконуєте сфокусоване виправлення. Workflow серіалізує публікацію Plugin у npm, - публікацію Plugin у ClawHub і публікацію OpenClaw у npm, щоб основний пакет не був - опублікований раніше за свої зовнішні Plugin. + QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace + span, обмежені атрибути та редагування вмісту/ідентифікаторів без + потреби в Opik, Langfuse або іншому зовнішньому collector. +- Запустіть `pnpm release:check` перед кожним тегованим релізом +- Запустіть `OpenClaw Release Publish` для мутувальної послідовності публікації після того, як + тег існує. Запускайте його з `release/YYYY.M.D` (або `main`, коли публікуєте + тег, досяжний із main), передайте релізний тег і успішний OpenClaw npm + `preflight_run_id`, і залишайте типовий scope публікації plugin + `all-publishable`, якщо ви навмисно не виконуєте сфокусоване виправлення. Workflow + серіалізує npm-публікацію plugin, публікацію plugin у ClawHub і npm-публікацію OpenClaw, + щоб основний пакет не був опублікований раніше за його зовнішні + plugins. - Release checks тепер виконуються в окремому ручному workflow: `OpenClaw Release Checks` -- `OpenClaw Release Checks` також запускає lane mock parity QA Lab плюс швидкий live - профіль Matrix і Telegram QA lane перед схваленням релізу. Live lanes використовують - середовище `qa-live-shared`; Telegram також використовує оренди облікових даних Convex - CI. Запустіть ручний workflow `QA-Lab - All Lanes` з `matrix_profile=all` і - `matrix_shards=true`, коли потрібен повний інвентар Matrix transport, media та E2EE - паралельно. -- Крос-ОС валідація встановлення та оновлення runtime є частиною публічних +- `OpenClaw Release Checks` також запускає mock parity lane QA Lab плюс швидкий + live-профіль Matrix і Telegram QA lane перед схваленням релізу. Live + lanes використовують середовище `qa-live-shared`; Telegram також використовує оренди + облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з + `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix + transport, media та E2EE паралельно. +- Між-ОС валідація runtime встановлення й оновлення є частиною публічних `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають - повторно використовуваний workflow + багаторазовий workflow `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` -- Це розділення навмисне: реальний шлях npm-релізу має бути коротким, - детермінованим і сфокусованим на артефактах, тоді як повільніші live-перевірки - залишаються у власній lane, щоб не затримувати й не блокувати публікацію +- Цей поділ навмисний: тримайте реальний шлях npm-релізу коротким, + детермінованим і сфокусованим на артефактах, тоді як повільніші live-перевірки залишаються у своїй + lane, щоб вони не затримували й не блокували публікацію - Release checks із секретами слід запускати через `Full Release Validation` або з workflow ref `main`/release, щоб логіка workflow і секрети залишалися контрольованими - `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо - розв’язаний коміт досяжний з гілки OpenClaw або release tag -- validation-only preflight `OpenClaw NPM Release` також приймає поточний - повний 40-символьний SHA коміту workflow-гілки без вимоги pushed tag -- Цей шлях SHA призначений лише для валідації й не може бути підвищений до реальної публікації -- У режимі SHA workflow синтезує `v` лише для перевірки метаданих - пакета; реальна публікація все одно потребує реального release tag -- Обидва workflow зберігають реальний шлях публікації та promotion на GitHub-hosted - runners, тоді як немодифікуючий шлях валідації може використовувати більші + resolved commit досяжний із гілки OpenClaw або релізного тегу +- Validation-only preflight `OpenClaw NPM Release` також приймає поточний + повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тегу +- Цей шлях SHA є лише validation-only і не може бути підвищений до реальної публікації +- У режимі SHA workflow синтезує `v` лише для + перевірки метаданих пакета; реальна публікація все одно потребує справжнього релізного тегу +- Обидва 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 більше не чекає на окрему lane release checks + з використанням обох workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` +- npm release preflight більше не чекає на окрему release checks lane - Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` - (або відповідний beta/correction tag) перед схваленням + (або відповідний тег beta/correction) перед схваленням - Після npm publish запустіть `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D` - (або відповідну beta/correction version), щоб перевірити шлях встановлення з + (або відповідну версію beta/correction), щоб перевірити шлях встановлення опублікованого registry у свіжому тимчасовому prefix -- Після 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` +- Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live`, щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E - проти опублікованого npm-пакета з використанням спільного leased pool облікових даних Telegram. - Локальні одноразові перевірки maintainer можуть пропустити Convex vars і передати три - env credentials `OPENCLAW_QA_TELEGRAM_*` напряму. -- Щоб запустити повний post-publish beta smoke з машини maintainer, використовуйте `pnpm release:beta-smoke -- --beta betaN`. Helper виконує Parallels npm update/fresh-target validation, запускає `NPM Telegram Beta E2E`, опитує точний workflow run, завантажує artifact і друкує Telegram report. -- Maintainers можуть запускати ту саму post-publish перевірку з GitHub Actions через + проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних Telegram. + Локальні одноразові maintainer-запуски можуть пропустити змінні Convex і передати три + env-облікові дані `OPENCLAW_QA_TELEGRAM_*` напряму. +- Щоб запустити повний post-publish beta smoke з машини maintainer, використовуйте `pnpm release:beta-smoke -- --beta betaN`. Helper запускає Parallels-валідацію npm update/fresh-target, запускає `NPM Telegram Beta E2E`, опитує точний workflow run, завантажує артефакт і друкує Telegram-звіт. +- Maintainers можуть запустити ту саму post-publish перевірку з GitHub Actions через ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і - не запускається на кожен merge. + не запускається на кожному merge. - Автоматизація релізів maintainer тепер використовує preflight-then-promote: - - реальна npm-публікація має пройти успішний npm `preflight_run_id` - - реальна npm-публікація має бути запущена з тієї самої гілки `main` або + - реальний npm publish має пройти успішний npm `preflight_run_id` + - реальний npm publish має бути запущений із тієї самої гілки `main` або `release/YYYY.M.D`, що й успішний preflight run - - stable npm releases за замовчуванням переходять у `beta` - - stable npm publish може явно цілитися в `latest` через workflow input - - мутація token-based npm dist-tag тепер живе в + - стабільні npm-релізи типово спрямовані на `beta` + - стабільний npm publish може явно спрямовуватися на `latest` через input workflow + - token-based мутація npm dist-tag тепер живе в `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` - для безпеки, бо `npm dist-tag add` досі потребує `NPM_TOKEN`, тоді як - public repo зберігає лише OIDC-only publish - - public `macOS Release` призначений лише для валідації; коли tag існує лише в - release branch, але workflow запускається з `main`, встановіть + з міркувань безпеки, бо `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як + публічний репозиторій зберігає OIDC-only publish + - публічний `macOS Release` є validation-only; коли тег існує лише в + релізній гілці, але workflow запускається з `main`, задайте `public_release_branch=release/YYYY.M.D` - - реальний private mac publish має пройти успішні private mac + - реальний приватний mac publish має пройти успішні приватні mac `preflight_run_id` і `validate_run_id` - - реальні publish paths просувають підготовлені artifacts замість повторної - перебудови -- Для stable correction releases на кшталт `YYYY.M.D-N` post-publish verifier - також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`, - щоб release corrections не могли непомітно залишити старіші глобальні встановлення - на базовому stable payload -- npm release preflight fails closed, якщо tarball не містить і - `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`, + - реальні publish paths підвищують підготовлені артефакти замість повторної + їх збірки +- Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier + також перевіряє той самий шлях temp-prefix upgrade з `YYYY.M.D` до `YYYY.M.D-N`, + щоб release corrections не могли непомітно залишити старіші глобальні встановлення на + базовому стабільному payload +- npm release preflight завершується закритою помилкою, якщо tarball не містить обох + `dist/control-ui/index.html` і непорожнього payload `dist/control-ui/assets/`, щоб ми знову не відвантажили порожню browser dashboard -- Post-publish verification також перевіряє наявність published plugin entrypoints і - package metadata у встановленому registry layout. Реліз, який відвантажує відсутні - plugin runtime payloads, провалює postpublish verifier і не може бути promoted до `latest`. -- `pnpm test:install:smoke` також застосовує budget npm pack `unpackedSize` до - candidate update tarball, тож installer e2e ловить випадкове pack bloat +- Post-publish verification також перевіряє, що опубліковані entrypoints plugin і + метадані package присутні в установленому registry 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 - `plugin-prerelease-extension-shard` matrix outputs з - `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes - не описували застарілий CI layout -- Готовність stable macOS release також включає updater surfaces: - - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip` +- Якщо релізна робота торкнулася планування CI, manifests timing extension або + матриць тестів extension, перегенеруйте й перегляньте planner-owned + matrix outputs `plugin-prerelease-extension-shard` з + `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не + описували застарілий CI layout +- Готовність стабільного macOS-релізу також включає 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 + - запакований app має зберігати non-debug bundle id, непорожню URL Sparkle feed + і `CFBundleVersion` на рівні або вище canonical Sparkle build floor + для цієї версії релізу ## Релізні тестові бокси -`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести з -однієї точки входу. Для доказу pinned commit на швидкозмінній гілці використовуйте +`Full Release Validation` — це спосіб, яким operators запускають усі передрелізні тести з +однієї точки входу. Для доказу pinned commit на швидко змінюваній гілці використовуйте helper, щоб кожен дочірній workflow запускався з тимчасової гілки, зафіксованої на target SHA: @@ -271,8 +279,8 @@ pnpm ci:full-release --sha Helper пушить `release-ci/-...`, запускає `Full Release Validation` з цієї гілки з `ref=`, перевіряє, що кожен дочірній workflow `headSha` -відповідає target, а потім видаляє тимчасову гілку. Це запобігає випадковому -підтвердженню новішого дочірнього запуску `main`. +збігається з target, а потім видаляє тимчасову гілку. Це запобігає випадковому +підтвердженню нового дочірнього запуску `main`. Для валідації release branch або tag запускайте його з довіреного workflow ref `main` і передавайте release branch або tag як `ref`: @@ -287,49 +295,53 @@ gh workflow run full-release-validation.yml \ -f evidence_package_spec=openclaw@YYYY.M.D-beta.N ``` -Робочий процес визначає цільовий ref, запускає вручну `CI` з +Робочий процес визначає цільовий ref, запускає manual `CI` з `target_ref=`, запускає `OpenClaw Release Checks`, готує -батьківський артефакт `release-package-under-test` для перевірок, пов’язаних із -пакетом, і запускає окремий package Telegram E2E, коли `release_profile=full` з +батьківський артефакт `release-package-under-test` для перевірок, орієнтованих на пакет, і +запускає автономний 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 coverage, 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`. Фінальний підсумок -верифікатора містить таблиці найповільніших завдань для кожного дочірнього -запуску, щоб release manager міг бачити поточний критичний шлях без -завантаження логів. -Див. [Повна валідація релізу](/uk/reference/full-release-validation), щоб отримати -повну матрицю етапів, точні назви завдань workflow, відмінності між профілями -stable і full, артефакти та дескриптори для сфокусованих повторних запусків. -Дочірні workflows запускаються з довіреного ref, який виконує `Full Release +Checks` розгортається на install smoke, cross-OS release checks, live/E2E Docker +покриття release-path, коли soak увімкнено, 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`. Фінальне +зведення verifier містить таблиці найповільніших завдань для кожного дочірнього запуску, щоб release +manager міг бачити поточний критичний шлях без завантаження логів. +Див. [Повна release validation](/uk/reference/full-release-validation), щоб отримати +повну матрицю етапів, точні назви workflow job, відмінності між stable і full profile, +артефакти та ручки сфокусованого повторного запуску. +Дочірні workflow запускаються з довіреного ref, який виконує `Full Release Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на -старішу release-гілку або тег. Окремого input для workflow-ref у Full Release Validation +старішу release branch або tag. Окремого workflow-ref input для Full Release Validation немає; вибирайте довірений harness, вибираючи ref запуску workflow. -Не використовуйте `--ref main -f ref=` для proof точного коміту на рухомому `main`; +Не використовуйте `--ref main -f ref=` для exact commit proof на рухомій `main`; raw commit SHA не можуть бути workflow dispatch refs, тому використовуйте -`pnpm ci:full-release --sha `, щоб створити pinned тимчасову гілку. +`pnpm ci:full-release --sha `, щоб створити закріплену тимчасову branch. Використовуйте `release_profile`, щоб вибрати ширину live/provider: - `minimum`: найшвидший release-critical OpenAI/core live і Docker path -- `stable`: minimum плюс stable provider/backend coverage для схвалення релізу -- `full`: stable плюс broad advisory provider/media coverage +- `stable`: minimum плюс stable provider/backend coverage для release approval +- `full`: stable плюс широке advisory provider/media coverage -`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз -визначити цільовий ref як `release-package-under-test`, і повторно використовує -цей артефакт як у release-path Docker checks, так і в Package Acceptance. Це -тримає всі package-facing boxes на тих самих байтах і уникає повторних збірок -пакета. Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли -задано repo/org variable, інакше `openai/gpt-5.4`, бо ця lane -доводить встановлення пакета, onboarding, запуск gateway і один live agent turn, -а не benchmark найповільнішої default model. Ширша live provider +Використовуйте `run_release_soak=true` зі `stable`, коли release-blocking lanes +зелені й потрібен вичерпний live/E2E, Docker release-path і +all-since-2026.4.23 upgrade-survivor sweep перед promotion. `full` передбачає +`run_release_soak=true`. + +`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз визначити цільовий +ref як `release-package-under-test`, і повторно використовує цей артефакт у cross-OS, +Package Acceptance та release-path Docker checks, коли виконується soak. Це утримує +всі package-facing boxes на тих самих байтах і уникає повторних package builds. +Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли +repo/org variable задана, інакше `openai/gpt-5.4`, оскільки ця lane +доводить package install, onboarding, запуск gateway і один live agent turn, +а не бенчмаркує найповільнішу default model. Ширша live provider matrix залишається місцем для model-specific coverage. -Використовуйте ці варіанти залежно від етапу релізу: +Використовуйте ці варіанти залежно від етапу release: ```bash # Validate an unpublished release candidate branch. @@ -360,17 +372,17 @@ gh workflow run full-release-validation.yml \ ``` Не використовуйте повну umbrella як перший повторний запуск після сфокусованого виправлення. Якщо один box -падає, використовуйте невдалий child workflow, job, Docker lane, package profile, model -provider або QA lane для наступного proof. Запускайте повну umbrella знову лише тоді, коли -виправлення змінило спільну release orchestration або зробило попередні all-box evidence -застарілими. Фінальний verifier umbrella повторно перевіряє записані child workflow run -ids, тому після успішного повторного запуску child workflow повторно запускайте тільки failed -батьківське завдання `Verify full validation`. +завершується помилкою, використовуйте failed child workflow, job, Docker lane, package profile, model +provider або QA lane для наступного proof. Запускайте повну umbrella знову лише тоді, +коли виправлення змінило shared release orchestration або зробило попередні all-box evidence +застарілими. Фінальний verifier umbrella повторно перевіряє записані ids запусків child workflow, +тому після успішного повторного запуску child workflow повторно запустіть лише failed +`Verify full validation` parent job. -Для обмеженого відновлення передайте `rerun_group` в umbrella. `all` є справжнім -release-candidate run, `ci` запускає тільки normal CI child, `plugin-prerelease` -запускає тільки release-only plugin child, `release-checks` запускає кожен release -box, а вужчі release groups: `install-smoke`, `cross-os`, +Для обмеженого відновлення передайте `rerun_group` до umbrella. `all` — це справжній +release-candidate run, `ci` запускає лише normal CI child, `plugin-prerelease` +запускає лише release-only Plugin child, `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 runs з `release_profile=full` використовують package artifact із release-checks. @@ -379,20 +391,20 @@ box, а вужчі release groups: `install-smoke`, `cross-os`, Vitest box — це manual `CI` child workflow. Manual CI навмисно обходить changed scoping і примусово запускає normal test graph для release -candidate: Linux Node shards, bundled-plugin shards, channel contracts, Node 22 +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, щоб відповісти: "чи source tree пройшло full normal test suite?" -Це не те саме, що release-path product validation. Evidence, які слід зберігати: +Використовуйте цей box, щоб відповісти: "чи пройшло source tree повний normal test suite?" +Це не те саме, що release-path product validation. Evidence, яку потрібно зберегти: -- підсумок `Full Release Validation`, що показує URL запущеного `CI` run -- `CI` run зелений на точному target SHA -- назви failed або slow shards із CI jobs під час розслідування regressions +- зведення `Full Release Validation`, що показує dispatched `CI` run URL +- зелений `CI` run на точному target SHA +- назви failed або slow shards із CI jobs під час дослідження regressions - Vitest timing artifacts, як-от `.artifacts/vitest-shard-timings.json`, коли запуск потребує performance analysis -Запускайте manual CI напряму лише тоді, коли релізу потрібен deterministic normal CI, але +Запускайте manual CI напряму лише тоді, коли release потребує deterministic normal CI, але не Docker, QA Lab, live, cross-OS або package boxes: ```bash @@ -402,15 +414,15 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D ### Docker Docker box живе в `OpenClaw Release Checks` через -`openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode -workflow `install-smoke`. Він валідує release candidate через packaged +`openclaw-live-and-e2e-checks-reusable.yml`, а також release-mode +workflow `install-smoke`. Він перевіряє release candidate через packaged Docker environments, а не лише source-level tests. Release Docker coverage включає: - full install smoke з увімкненим slow Bun global install smoke - підготовку/повторне використання root Dockerfile smoke image за target SHA, з QR, - root/gateway і installer/Bun smoke jobs, що працюють як окремі install-smoke + root/gateway і installer/Bun smoke jobs, що виконуються як окремі install-smoke shards - repository E2E lanes - release-path Docker chunks: `core`, `package-update-openai`, @@ -420,9 +432,9 @@ Release Docker coverage включає: `plugins-runtime-install-c`, `plugins-runtime-install-d`, `plugins-runtime-install-e`, `plugins-runtime-install-f`, `plugins-runtime-install-g` і `plugins-runtime-install-h` -- OpenWebUI coverage усередині chunk `plugins-runtime-services`, коли це запитано -- розділені bundled plugin install/uninstall lanes - `bundled-plugin-install-uninstall-0` through +- OpenWebUI coverage всередині chunk `plugins-runtime-services`, коли це запитано +- розділені bundled Plugin install/uninstall lanes + `bundled-plugin-install-uninstall-0` до `bundled-plugin-install-uninstall-23` - live/E2E provider suites і Docker live model coverage, коли release checks включають live suites @@ -430,80 +442,81 @@ Release Docker coverage включає: Використовуйте Docker artifacts перед повторним запуском. 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 замість +використовуйте `docker_lanes=` у reusable live/E2E workflow замість повторного запуску всіх release chunks. Згенеровані rerun commands включають попередні -`package_artifact_run_id` і prepared Docker image inputs, коли вони доступні, тому +`package_artifact_run_id` і prepared Docker image inputs, коли доступні, тож failed lane може повторно використати той самий tarball і GHCR images. ### QA Lab QA Lab box також є частиною `OpenClaw Release Checks`. Це agentic -behavior і channel-level release gate, окремо від Vitest і Docker +behavior і channel-level release gate, окремий від Vitest і Docker package mechanics. Release QA Lab coverage включає: -- mock parity lane, що порівнює OpenAI candidate lane з Opus 4.6 - baseline за допомогою agentic parity pack -- fast live Matrix QA profile з використанням environment `qa-live-shared` +- mock parity lane, що порівнює candidate lane OpenAI з baseline Opus 4.6 + за допомогою agentic parity pack +- fast live Matrix QA profile з використанням середовища `qa-live-shared` - live Telegram QA lane з використанням Convex CI credential leases -- `pnpm qa:otel:smoke`, коли release telemetry потребує явного local proof +- `pnpm qa:otel:smoke`, коли release telemetry потребує explicit local proof -Використовуйте цей box, щоб відповісти: "чи реліз поводиться коректно в QA scenarios і +Використовуйте цей box, щоб відповісти: "чи поводиться release правильно у QA scenarios і live channel flows?" Зберігайте artifact URLs для parity, Matrix і Telegram -lanes під час схвалення релізу. Full Matrix coverage залишається доступним як -manual sharded QA-Lab run, а не як default release-critical lane. +lanes під час схвалення release. Full Matrix coverage лишається доступним як +manual sharded QA-Lab run, а не default release-critical lane. -### Пакет +### Package -Package box — це installable-product gate. Він підкріплений +Package box — це installable-product gate. Його підтримують `Package Acceptance` і resolver `scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує -candidate у tarball `package-under-test`, який споживає Docker E2E, валідує -package inventory, записує package version і SHA-256, а також тримає +candidate у tarball `package-under-test`, який споживає Docker E2E, перевіряє +package inventory, записує package version і SHA-256 та утримує workflow harness ref окремо від package source ref. Підтримувані candidate sources: - `source=npm`: `openclaw@beta`, `openclaw@latest` або точна OpenClaw release version -- `source=ref`: запакувати довірену `package_ref` branch, tag або full commit SHA +- `source=ref`: pack довірену `package_ref` branch, tag або full commit SHA з вибраним harness `workflow_ref` - `source=url`: завантажити HTTPS `.tgz` з обов’язковим `package_sha256` - `source=artifact`: повторно використати `.tgz`, завантажений іншим GitHub Actions run `OpenClaw Release Checks` запускає Package Acceptance з `source=artifact`, -prepared release package artifact, `suite_profile=custom`, +підготовленим 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=all-since-2026.4.23`, -`published_upgrade_survivor_scenarios=reported-issues` і -`telegram_mode=mock-openai`. Package Acceptance тримає migration, update, stale -plugin dependency cleanup, offline plugin fixtures, plugin update і Telegram -package QA проти того самого resolved tarball. Upgrade matrix охоплює кожен stable npm-published baseline від `2026.4.23` до `latest`; використовуйте -Package Acceptance з `source=npm` для вже shipped candidate або +`telegram_mode=mock-openai`. Package Acceptance утримує migration, update, stale +Plugin dependency cleanup, offline Plugin fixtures, Plugin update і Telegram +package QA проти того самого resolved tarball. Blocking release checks використовують +default latest published package baseline; `run_release_soak=true` або +`release_profile=full` розширює до кожного stable npm-published baseline від +`2026.4.23` до `latest` плюс reported-issue fixtures. Використовуйте +Package Acceptance із `source=npm` для вже shipped candidate або `source=ref`/`source=artifact` для SHA-backed local npm tarball перед -публікацією. Це GitHub-native -заміна більшості package/update coverage, яка раніше потребувала +publish. Це 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: -[Testing updates and plugins](/uk/help/testing-updates-plugins). Використовуйте його, коли +Канонічний checklist для update і Plugin validation — +[Тестування updates і 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+` є -окремим manual workflow `Update Migration`, а не частиною Full Release CI. +Plugin install/update, doctor cleanup або published-package migration change. +Вичерпна published update migration з кожного stable package `2026.4.23+` — +це окремий manual workflow `Update Migration`, а не частина Full Release CI. -Legacy package-acceptance leniency навмисно обмежена в часі. Packages through +Legacy package-acceptance leniency навмисно обмежена в часі. Packages до `2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих -в npm: private QA inventory entries missing from the tarball, missing -`gateway install --wrapper`, missing patch files in the tarball-derived git -fixture, missing persisted `update.channel`, legacy plugin install-record -locations, missing marketplace install-record persistence і config metadata +у npm: private QA inventory entries, відсутні в tarball, відсутній +`gateway install --wrapper`, відсутні patch files у tarball-derived git +fixture, відсутній persisted `update.channel`, legacy Plugin install-record +locations, відсутня marketplace install-record persistence і config metadata migration під час `plugins update`. Опублікований package `2026.4.26` може попереджати -про local build metadata stamp files, які вже були shipped. Later packages -мають відповідати modern package contracts; ті самі gaps провалюють release +про local build metadata stamp files, які вже були shipped. Пізніші packages +мають задовольняти modern package contracts; ті самі gaps провалюють release validation. Використовуйте ширші Package Acceptance profiles, коли release question стосується @@ -521,29 +534,32 @@ gh workflow run package-acceptance.yml \ Поширені package profiles: -- `smoke`: швидкі лінії встановлення пакета/каналу/агента, мережі Gateway і перезавантаження конфігурації -- `package`: контракти встановлення/оновлення/пакета Plugin без живого ClawHub; це типовий варіант для release-check -- `product`: `package` плюс MCP-канали, очищення cron/субагентів, вебпошук OpenAI і OpenWebUI +- `smoke`: швидкі лани встановлення пакета/каналу/агента, мережі Gateway і + перезавантаження конфігурації +- `package`: контракти встановлення/оновлення/пакета Plugin без живого ClawHub; це типовий + варіант для release-check +- `product`: `package` плюс MCP-канали, очищення cron/subagent, вебпошук OpenAI + і OpenWebUI - `full`: фрагменти Docker release-path з 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` у лінію Telegram; автономний +розв’язаний tarball `package-under-test` у Telegram-лан; окремий Telegram workflow і далі приймає опубліковану npm-специфікацію для перевірок після публікації. ## Автоматизація публікації релізу -`OpenClaw Release Publish` — звичайна точка входу для змінювальної публікації. Вона -оркеструє workflow trusted-publisher у порядку, потрібному релізу: +`OpenClaw Release Publish` — звичайна мутувальна точка входу для публікації. Вона +оркеструє workflows trusted-publisher у порядку, потрібному для релізу: -1. Забрати тег релізу й визначити його commit 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` і +4. Dispatch `Plugin NPM Release` з `publish_scope=all-publishable` і `ref=`. -5. Запустити `Plugin ClawHub Release` з тією самою областю дії та SHA. -6. Запустити `OpenClaw NPM Release` з тегом релізу, npm dist-tag і +5. Dispatch `Plugin ClawHub Release` з тим самим scope і SHA. +6. Dispatch `OpenClaw NPM Release` з release tag, npm dist-tag і збереженим `preflight_run_id`. Приклад публікації beta: @@ -576,90 +592,94 @@ gh workflow run openclaw-release-publish.yml \ -f npm_dist_tag=latest ``` -Використовуйте нижчорівневі workflow `Plugin NPM Release` і `Plugin ClawHub Release` -лише для цільового виправлення або повторної публікації. Для виправлення вибраного Plugin передайте +Використовуйте нижчорівневі workflows `Plugin NPM Release` і `Plugin ClawHub Release` +лише для сфокусованого ремонту або повторної публікації. Для ремонту вибраного Plugin передайте `plugin_publish_scope=selected` і `plugins=@openclaw/name` до `OpenClaw Release Publish` або запустіть дочірній workflow напряму, коли -пакет OpenClaw не слід публікувати. +пакет OpenClaw не можна публікувати. -## Вхідні дані workflow NPM +## Вхідні дані NPM workflow `OpenClaw NPM Release` приймає такі керовані оператором вхідні дані: -- `tag`: обов’язковий тег релізу, наприклад `v2026.4.2`, `v2026.4.2-1` або +- `tag`: обов’язковий release tag, наприклад `v2026.4.2`, `v2026.4.2-1` або `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний - повний 40-символьний commit SHA гілки workflow для preflight лише з валідацією -- `preflight_only`: `true` лише для валідації/збірки/пакування, `false` для - справжнього шляху публікації -- `preflight_run_id`: обов’язковий у справжньому шляху публікації, щоб workflow повторно використав + повний 40-символьний workflow-branch commit SHA для preflight лише з валідацією +- `preflight_only`: `true` лише для валідації/build/package, `false` для + реального шляху публікації +- `preflight_run_id`: обов’язковий на реальному шляху публікації, щоб workflow повторно використав підготовлений tarball з успішного preflight-запуску -- `npm_dist_tag`: цільовий npm-тег для шляху публікації; типовий — `beta` +- `npm_dist_tag`: цільовий npm tag для шляху публікації; типово `beta` `OpenClaw Release Publish` приймає такі керовані оператором вхідні дані: -- `tag`: обов’язковий тег релізу; має вже існувати +- `tag`: обов’язковий release tag; має вже існувати - `preflight_run_id`: id успішного preflight-запуску `OpenClaw NPM Release`; обов’язковий, коли `publish_openclaw_npm=true` -- `npm_dist_tag`: цільовий npm-тег для пакета OpenClaw -- `plugin_publish_scope`: типовий — `all-publishable`; використовуйте `selected` лише - для цільових робіт із виправлення +- `npm_dist_tag`: цільовий npm tag для пакета OpenClaw +- `plugin_publish_scope`: типово `all-publishable`; використовуйте `selected` лише + для сфокусованого ремонтного завдання - `plugins`: розділені комами назви пакетів `@openclaw/*`, коли `plugin_publish_scope=selected` -- `publish_openclaw_npm`: типовий — `true`; задавайте `false` лише коли використовуєте - workflow як оркестратор виправлення лише для Plugin +- `publish_openclaw_npm`: типово `true`; установлюйте `false` лише під час використання + workflow як оркестратора ремонту лише для plugins `OpenClaw Release Checks` приймає такі керовані оператором вхідні дані: -- `ref`: гілка, тег або повний commit SHA для валідації. Перевірки із секретами - вимагають, щоб розв’язаний commit був досяжний з гілки OpenClaw або - тегу релізу. +- `ref`: branch, tag або повний commit SHA для валідації. Перевірки із секретами + вимагають, щоб розв’язаний commit був досяжний з branch OpenClaw або + release tag. +- `run_release_soak`: увімкнути вичерпні live/E2E, Docker release-path і + all-since upgrade-survivor soak на стабільних/типових release checks. Примусово + вмикається через `release_profile=full`. Правила: -- Стабільні й корекційні теги можуть публікуватися або до `beta`, або до `latest` -- Beta prerelease-теги можуть публікуватися лише до `beta` +- Стабільні та корекційні tags можуть публікуватися або до `beta`, або до `latest` +- Beta prerelease tags можуть публікуватися лише до `beta` - Для `OpenClaw NPM Release` введення повного commit SHA дозволене лише коли `preflight_only=true` -- `OpenClaw Release Checks` і `Full Release Validation` завжди виконують лише валідацію -- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight; +- `OpenClaw Release Checks` і `Full Release Validation` завжди + лише валідаційні +- Реальний шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight; workflow перевіряє ці метадані перед продовженням публікації ## Послідовність стабільного npm-релізу -Коли готуєте стабільний npm-реліз: +Під час підготовки стабільного npm-релізу: 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true` - - До існування тегу можна використати поточний повний commit SHA гілки workflow - для пробного preflight-запуску лише з валідацією + - До появи tag можна використати поточний повний workflow-branch commit + SHA для валідаційного пробного запуску preflight workflow 2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише - коли навмисно хочете пряму стабільну публікацію -3. Запустіть `Full Release Validation` на гілці релізу, тезі релізу або повному - commit SHA, коли потрібні звичайний CI плюс живий кеш промптів, Docker, QA Lab, - Matrix і покриття Telegram з одного ручного workflow + коли навмисно потрібна пряма стабільна публікація +3. Запустіть `Full Release Validation` на release branch, release tag або повному + commit SHA, коли потрібні звичайний CI плюс покриття live prompt cache, Docker, QA Lab, + Matrix і Telegram з одного ручного workflow 4. Якщо навмисно потрібен лише детермінований звичайний граф тестів, запустіть ручний workflow `CI` на release ref натомість 5. Збережіть успішний `preflight_run_id` 6. Запустіть `OpenClaw Release Publish` з тим самим `tag`, тим самим `npm_dist_tag` - і збереженим `preflight_run_id`; він публікує зовнішні Plugin до npm + і збереженим `preflight_run_id`; він публікує зовнішні plugins до npm і ClawHub перед просуванням npm-пакета OpenClaw -7. Якщо реліз потрапив у `beta`, використайте приватний workflow - `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` - для просування цієї стабільної версії з `beta` до `latest` +7. Якщо реліз потрапив на `beta`, використайте приватний + workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`, + щоб просунути цю стабільну версію з `beta` до `latest` 8. Якщо реліз навмисно опубліковано безпосередньо до `latest`, а `beta` - має одразу вказувати на ту саму стабільну збірку, використайте той самий приватний - workflow, щоб спрямувати обидва dist-tag на стабільну версію, або дозвольте його запланованій - самовідновлювальній синхронізації перемістити `beta` пізніше + має негайно вказувати на той самий стабільний build, використайте той самий приватний + workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій + self-healing синхронізації пізніше перемістити `beta` -Зміна dist-tag розміщена в приватному репозиторії з міркувань безпеки, бо вона все ще -потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC. +Мутація dist-tag розміщена в приватному repo з міркувань безпеки, оскільки вона все ще +потребує `NPM_TOKEN`, тоді як публічний repo зберігає публікацію лише через OIDC. Це робить і шлях прямої публікації, і шлях просування beta-first -задокументованими та видимими для операторів. +задокументованими та видимими для оператора. Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password -CLI (`op`) лише всередині окремої tmux-сесії. Не викликайте `op` -напряму з основної оболонки агента; утримання цього всередині tmux робить запити, -сповіщення й обробку OTP видимими та запобігає повторним host-сповіщенням. +CLI (`op`) лише всередині виділеної tmux session. Не викликайте `op` +напряму з головного agent shell; утримання цього всередині tmux робить prompts, +alerts і обробку OTP спостережуваними та запобігає повторним alerts хоста. ## Публічні посилання @@ -673,7 +693,7 @@ CLI (`op`) лише всередині окремої tmux-сесії. Не ви - [`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 використовують приватну документацію релізів у +Maintainers використовують приватну release-документацію в [`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 eb7de7bb3..766600c59 100644 --- a/docs/uk/reference/full-release-validation.md +++ b/docs/uk/reference/full-release-validation.md @@ -1,24 +1,24 @@ --- read_when: - Запуск або повторний запуск повної перевірки релізу - - Порівняння профілів перевірки стабільного та повного релізу - - Налагодження збоїв етапу перевірки релізу -summary: Етапи повної перевірки випуску, дочірні робочі процеси, профілі випуску, дескриптори повторного запуску та докази + - Порівняння стабільного та повного профілів перевірки релізу + - Налагодження збоїв на етапі перевірки випуску +summary: Етапи повної перевірки релізу, дочірні робочі процеси, профілі релізу, дескриптори повторного запуску та докази title: Повна перевірка релізу x-i18n: - generated_at: "2026-05-03T12:10:38Z" + generated_at: "2026-05-04T22:29:50Z" model: gpt-5.5 provider: openai - source_hash: 038901ad751c00b35f69d7ec5caf74e577dcf2350d7658037c3ecc9ff5fab6d7 + source_hash: d67b7f9d413aa0f367b71f03d5325ff73591ee1ee6c77623712ebd15d295ca8b source_path: reference/full-release-validation.md workflow: 16 --- -`Full Release Validation` є загальною перевіркою релізу. Це єдина ручна -точка входу для передрелізного підтвердження, але більшість роботи відбувається в дочірніх workflow, щоб -невдалий box можна було перезапустити без перезапуску всього релізу. +`Full Release Validation` — це парасолька релізу. Це єдина ручна +точка входу для дорелізного підтвердження, але більшість роботи відбувається в дочірніх робочих процесах, щоб +збійний блок можна було запустити повторно без перезапуску всього релізу. -Запускайте його з довіреного ref workflow, зазвичай `main`, і передавайте релізну гілку, +Запускайте його з довіреного посилання робочого процесу, зазвичай `main`, і передавайте гілку релізу, тег або повний SHA коміту як `ref`: ```bash @@ -30,125 +30,130 @@ gh workflow run full-release-validation.yml \ -f release_profile=stable ``` -Дочірні workflow використовують довірений ref workflow для harness і вхідний -`ref` для кандидата, що тестується. Це забезпечує доступність нової логіки валідації -під час перевірки старішої релізної гілки або тегу. +Дочірні робочі процеси використовують довірене посилання робочого процесу для обв’язки та вхідний +`ref` для кандидата, що тестується. Це зберігає доступність нової логіки валідації +під час перевірки старішої гілки релізу або тегу. + +За замовчуванням `release_profile=stable` запускає блокувальні для релізу напрямки й пропускає +вичерпний live/Docker soak. Передайте `run_release_soak=true`, щоб включити +soak-напрямки у стабільний запуск. `release_profile=full` завжди вмикає soak-напрямки, щоб +широкий дорадчий профіль ніколи не втрачав покриття непомітно. Package Acceptance зазвичай збирає tarball кандидата з розв’язаного -`ref`, включно із запусками для повного SHA, відправленими через `pnpm ci:full-release`. Після +`ref`, включно із запусками за повним SHA, відправленими через `pnpm ci:full-release`. Після публікації передайте `package_acceptance_package_spec=openclaw@YYYY.M.D` (або -`openclaw@beta`/`openclaw@latest`), щоб натомість запустити ту саму матрицю package/update для -поставленого npm-пакета. +`openclaw@beta`/`openclaw@latest`), щоб натомість запустити ту саму матрицю пакетів/оновлень проти +опублікованого npm-пакета. ## Етапи верхнього рівня -| Етап | Подробиці | -| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Розв’язання цілі | **Завдання:** `Resolve target ref`
**Дочірній workflow:** немає
**Підтверджує:** розв’язує релізну гілку, тег або повний SHA коміту та записує вибрані вхідні дані.
**Повторний запуск:** перезапустіть загальну перевірку, якщо це не вдається. | -| Vitest і звичайний CI | **Завдання:** `Run normal full CI`
**Дочірній workflow:** `CI`
**Підтверджує:** ручний повний граф CI для цільового ref, включно з Linux Node lanes, shards для bundled plugin, контрактами каналів, сумісністю Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, i18n Control UI та Android через загальну перевірку.
**Повторний запуск:** `rerun_group=ci`. | -| Передрелізна перевірка Plugin | **Завдання:** `Run plugin prerelease validation`
**Дочірній workflow:** `Plugin Prerelease`
**Підтверджує:** релізні статичні перевірки Plugin, agentic-покриття plugin, повні batch shards розширень і передрелізні Docker lanes для plugin.
**Повторний запуск:** `rerun_group=plugin-prerelease`. | -| Перевірки релізу | **Завдання:** `Run release/live/Docker/QA validation`
**Дочірній workflow:** `OpenClaw Release Checks`
**Підтверджує:** install smoke, крос-OS перевірки package, live/E2E suites, chunks релізного Docker-шляху, Package Acceptance, паритет QA Lab, live Matrix і live Telegram.
**Повторний запуск:** `rerun_group=release-checks` або вужчий handle release-checks. | -| Артефакт package | **Завдання:** `Prepare release package artifact`
**Дочірній workflow:** немає
**Підтверджує:** створює батьківський tarball `release-package-under-test` достатньо рано для перевірок, орієнтованих на package, яким не потрібно чекати на `OpenClaw Release Checks`.
**Повторний запуск:** перезапустіть загальну перевірку або надайте `npm_telegram_package_spec` для `rerun_group=npm-telegram`. | -| Package Telegram | **Завдання:** `Run package Telegram E2E`
**Дочірній workflow:** `NPM Telegram Beta E2E`
**Підтверджує:** підтвердження package Telegram, підкріплене батьківським артефактом, для `rerun_group=all` з `release_profile=full`, або підтвердження Telegram для опублікованого package, коли встановлено `npm_telegram_package_spec`.
**Повторний запуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`. | -| Верифікатор загальної перевірки | **Завдання:** `Verify full validation`
**Дочірній workflow:** немає
**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших завдань із дочірніх workflow.
**Повторний запуск:** перезапустіть лише це завдання після успішного перезапуску невдалого дочірнього workflow. | +| Етап | Деталі | +| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Розв’язання цілі | **Завдання:** `Resolve target ref`
**Дочірній робочий процес:** немає
**Підтверджує:** розв’язує гілку релізу, тег або повний SHA коміту й записує вибрані вхідні дані.
**Повторний запуск:** повторно запустіть парасольку, якщо це завершиться збоєм. | +| Vitest і звичайний CI | **Завдання:** `Run normal full CI`
**Дочірній робочий процес:** `CI`
**Підтверджує:** ручний повний граф CI проти цільового ref, включно з напрямками Linux Node, шардами bundled Plugin, контрактами каналів, сумісністю з Node 22, `check`, `check-additional`, build smoke, перевірками документації, Python skills, Windows, macOS, Control UI i18n та Android через парасольку.
**Повторний запуск:** `rerun_group=ci`. | +| Дореліз Plugin | **Завдання:** `Run plugin prerelease validation`
**Дочірній робочий процес:** `Plugin Prerelease`
**Підтверджує:** лише релізні статичні перевірки Plugin, agentic-покриття Plugin, повні шарди batch розширень і дорелізні Docker-напрямки Plugin.
**Повторний запуск:** `rerun_group=plugin-prerelease`. | +| Перевірки релізу | **Завдання:** `Run release/live/Docker/QA validation`
**Дочірній робочий процес:** `OpenClaw Release Checks`
**Підтверджує:** install smoke, cross-OS перевірки пакета, Package Acceptance, паритет QA Lab, live Matrix і live Telegram. З `run_release_soak=true` або `release_profile=full` також запускає вичерпні live/E2E набори та Docker-фрагменти шляху релізу.
**Повторний запуск:** `rerun_group=release-checks` або вужчий дескриптор release-checks. | +| Артефакт пакета | **Завдання:** `Prepare release package artifact`
**Дочірній робочий процес:** немає
**Підтверджує:** створює батьківський tarball `release-package-under-test` достатньо рано для перевірок, орієнтованих на пакет, яким не потрібно чекати на `OpenClaw Release Checks`.
**Повторний запуск:** повторно запустіть парасольку або надайте `npm_telegram_package_spec` для `rerun_group=npm-telegram`. | +| Package Telegram | **Завдання:** `Run package Telegram E2E`
**Дочірній робочий процес:** `NPM Telegram Beta E2E`
**Підтверджує:** підтвердження пакета Telegram на основі батьківського артефакту для `rerun_group=all` з `release_profile=full` або підтвердження Telegram для опублікованого пакета, коли задано `npm_telegram_package_spec`.
**Повторний запуск:** `rerun_group=npm-telegram` з `npm_telegram_package_spec`. | +| Верифікатор парасольки | **Завдання:** `Verify full validation`
**Дочірній робочий процес:** немає
**Підтверджує:** повторно перевіряє записані висновки дочірніх запусків і додає таблиці найповільніших завдань із дочірніх робочих процесів.
**Повторний запуск:** повторно запустіть лише це завдання після повторного запуску невдалого дочірнього процесу до зеленого стану. | -Для `ref=main` і `rerun_group=all` новіша загальна перевірка замінює старішу. -Коли батьківський workflow скасовано, його monitor скасовує будь-який дочірній workflow, який він уже -відправив. Запуски перевірки релізних гілок і тегів за замовчуванням не скасовують один одного. +Для `ref=main` і `rerun_group=all` новіша парасолька замінює старішу. +Коли батьківський процес скасовується, його монітор скасовує будь-який дочірній робочий процес, який він уже +відправив. Запуски валідації гілок релізу й тегів за замовчуванням не скасовують один одного. ## Етапи перевірок релізу -`OpenClaw Release Checks` є найбільшим дочірнім workflow. Він розв’язує ціль -один раз і готує спільний артефакт `release-package-under-test`, коли він потрібен етапам, -орієнтованим на package або Docker. +`OpenClaw Release Checks` — найбільший дочірній робочий процес. Він один раз розв’язує ціль +і готує спільний артефакт `release-package-under-test`, коли це потрібно етапам, +орієнтованим на пакет або Docker. -| Етап | Подробиці | -| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Релізна ціль | **Завдання:** `Resolve target ref`
**Підтримувальний workflow:** немає
**Тести:** вибраний ref, необов’язковий очікуваний SHA, профіль, група повторного запуску та сфокусований фільтр live suite.
**Повторний запуск:** `rerun_group=release-checks`. | -| Артефакт package | **Завдання:** `Prepare release package artifact`
**Підтримувальний workflow:** немає
**Тести:** пакує або розв’язує один tarball кандидата й завантажує `release-package-under-test` для подальших перевірок, орієнтованих на package.
**Повторний запуск:** відповідна група package, cross-OS або live/E2E. | -| Install smoke | **Завдання:** `Run install smoke`
**Підтримувальний workflow:** `Install Smoke`
**Тести:** повний шлях установлення з повторним використанням root Dockerfile smoke image, встановлення QR package, root і gateway Docker smokes, Docker-тести інсталятора, Bun global install image-provider smoke і швидкий bundled-plugin install/uninstall E2E.
**Повторний запуск:** `rerun_group=install-smoke`. | -| Cross-OS | **Завдання:** `cross_os_release_checks`
**Підтримувальний 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 | **Завдання:** `Run repo/live E2E validation`
**Підтримувальний 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 | **Завдання:** `Run Docker release-path validation`
**Підтримувальний workflow:** `OpenClaw Live And E2E Checks (Reusable)`
**Тести:** chunks релізного Docker-шляху для спільного артефакта package.
**Повторний запуск:** `rerun_group=live-e2e`. | -| Package Acceptance | **Завдання:** `Run package acceptance`
**Підтримувальний workflow:** `Package Acceptance`
**Тести:** offline fixtures package plugin, оновлення plugin, приймання package mock-OpenAI Telegram і перевірки збереження published-upgrade з кожного stable npm release на або після `2026.4.23` для того самого tarball.
**Повторний запуск:** `rerun_group=package`. | -| QA parity | **Завдання:** `Run QA Lab parity lane` і `Run QA Lab parity report`
**Підтримувальний workflow:** прямі завдання
**Тести:** candidate і baseline agentic parity packs, потім parity report.
**Повторний запуск:** `rerun_group=qa-parity` або `rerun_group=qa`. | -| QA live Matrix | **Завдання:** `Run QA Lab live Matrix lane`
**Підтримувальний workflow:** пряме завдання
**Тести:** швидкий live Matrix QA profile у середовищі `qa-live-shared`.
**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`. | -| QA live Telegram | **Завдання:** `Run QA Lab live Telegram lane`
**Підтримувальний workflow:** пряме завдання
**Тести:** live Telegram QA з leases облікових даних Convex CI.
**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`. | -| Верифікатор релізу | **Завдання:** `Verify release checks`
**Підтримувальний workflow:** немає
**Тести:** обов’язкові завдання release-check для вибраної групи повторного запуску.
**Повторний запуск:** перезапустіть після проходження сфокусованих дочірніх завдань. | +| Етап | Подробиці | +| ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Ціль релізу | **Завдання:** `Resolve target ref`
**Базовий workflow:** немає
**Тести:** вибраний ref, необов’язковий очікуваний SHA, профіль, група повторного запуску та сфокусований фільтр live-набору.
**Повторний запуск:** `rerun_group=release-checks`. | +| Артефакт пакета | **Завдання:** `Prepare release package artifact`
**Базовий workflow:** немає
**Тести:** пакує або визначає один кандидатний tarball і завантажує `release-package-under-test` для подальших перевірок, орієнтованих на пакет.
**Повторний запуск:** відповідна група пакета, cross-OS або live/E2E. | +| Install smoke | **Завдання:** `Run install smoke`
**Базовий workflow:** `Install Smoke`
**Тести:** повний шлях встановлення з повторним використанням smoke-образу кореневого Dockerfile, встановлення QR-пакета, root і gateway Docker smokes, Docker-тести інсталятора, Bun global install image-provider smoke і швидкий E2E встановлення/видалення bundled-plugin.
**Повторний запуск:** `rerun_group=install-smoke`. | +| Cross-OS | **Завдання:** `cross_os_release_checks`
**Базовий workflow:** `OpenClaw Cross-OS Release Checks (Reusable)`
**Тести:** свіжі та upgrade-напрями на Linux, Windows і macOS для вибраного провайдера та режиму з використанням кандидатного tarball і baseline-пакета.
**Повторний запуск:** `rerun_group=cross-os`. | +| Repo і live E2E | **Завдання:** `Run repo/live E2E validation`
**Базовий 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`.
**Запускається:** `run_release_soak=true`, `release_profile=full` або сфокусований `rerun_group=live-e2e`.
**Повторний запуск:** `rerun_group=live-e2e`, необов’язково з `live_suite_filter`. | +| Шлях Docker-релізу | **Завдання:** `Run Docker release-path validation`
**Базовий workflow:** `OpenClaw Live And E2E Checks (Reusable)`
**Тести:** Docker chunks для release-path на спільному артефакті пакета.
**Запускається:** `run_release_soak=true`, `release_profile=full` або сфокусований `rerun_group=live-e2e`.
**Повторний запуск:** `rerun_group=live-e2e`. | +| Package Acceptance | **Завдання:** `Run package acceptance`
**Базовий workflow:** `Package Acceptance`
**Тести:** offline fixtures пакетів Plugin, оновлення Plugin, приймання mock-OpenAI Telegram-пакета та перевірки survivor для published-upgrade на тому самому tarball. Блокувальні release-перевірки використовують стандартний останній опублікований baseline; soak-перевірки розширюються до кожного стабільного npm-релізу від `2026.4.23` включно плюс fixtures для повідомлених проблем.
**Повторний запуск:** `rerun_group=package`. | +| QA parity | **Завдання:** `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 | **Завдання:** `Run QA Lab live Matrix lane`
**Базовий workflow:** пряме job
**Тести:** швидкий live Matrix QA-профіль у середовищі `qa-live-shared`.
**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`. | +| QA live Telegram | **Завдання:** `Run QA Lab live Telegram lane`
**Базовий workflow:** пряме job
**Тести:** live Telegram QA з орендами облікових даних Convex CI.
**Повторний запуск:** `rerun_group=qa-live` або `rerun_group=qa`. | +| Верифікатор релізу | **Завдання:** `Verify release checks`
**Базовий workflow:** немає
**Тести:** обов’язкові release-check jobs для вибраної групи повторного запуску.
**Повторний запуск:** повторно запустіть після успішного проходження сфокусованих дочірніх jobs. | -## Chunks Docker release-path +## Фрагменти Docker release-path -Етап Docker release-path запускає ці chunks, коли `live_suite_filter` є -порожнім: +Етап Docker release-path запускає ці фрагменти, коли `live_suite_filter` +порожній: -| Chunk | Покриття | -| --------------------------------------------------------------- | ----------------------------------------------------------------------- | -| `core` | Core Docker release-path smoke lanes. | -| `package-update-openai` | Поведінка встановлення й оновлення package OpenAI. | -| `package-update-anthropic` | Поведінка встановлення й оновлення package Anthropic. | -| `package-update-core` | Нейтральна щодо provider поведінка package і update. | -| `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, розділені для паралельної валідації релізу. | +| Фрагмент | Покриття | +| -------------------------------------------------------------- | ------------------------------------------------------------------------ | +| `core` | Core Docker release-path smoke-напрями. | +| `package-update-openai` | Поведінка встановлення та оновлення пакета OpenAI. | +| `package-update-anthropic` | Поведінка встановлення та оновлення пакета Anthropic. | +| `package-update-core` | Нейтральна щодо провайдера поведінка пакета й оновлення. | +| `plugins-runtime-plugins` | Напрями runtime Plugin, які перевіряють поведінку Plugin. | +| `plugins-runtime-services` | Напрями runtime Plugin з підтримкою сервісів; включає OpenWebUI за запитом. | +| `plugins-runtime-install-a` до `plugins-runtime-install-h` | Пакети встановлення/runtime Plugin, розділені для паралельної валідації релізу. | -Використовуйте цільовий `docker_lanes=` у повторно використовуваному live/E2E workflow, коли -завершився з помилкою лише один Docker-лан. Артефакти релізу містять команди -повторного запуску для кожного лану з вхідними параметрами повторного використання -артефакта пакета й образу, коли вони доступні. +Використовуйте цільові `docker_lanes=` у reusable live/E2E workflow, коли +збій стався лише в одному Docker-напрямі. Артефакти релізу містять команди +повторного запуску для кожного напряму з artifact пакета та вхідними даними повторного використання образу, коли вони доступні. ## Профілі релізу -`release_profile` переважно керує широтою live/провайдерів у перевірках релізу. -Він не прибирає звичайний повний CI, Plugin Prerelease, install smoke, package -acceptance, QA Lab або фрагменти Docker release-path. `full` також змушує -зонтичний запуск виконувати package Telegram E2E з батьківським артефактом пакета релізу, коли -`rerun_group=all`, тож повний кандидат перед публікацією не пропускає тихо цей -Telegram package-лан. +`release_profile` переважно керує шириною live/provider усередині release checks. +Він не прибирає звичайний full CI, Plugin Prerelease, install smoke, package +acceptance або QA Lab. Для `stable` вичерпні repo/live E2E і Docker +release-path chunks є soak-покриттям і запускаються, коли `run_release_soak=true`. +`full` примусово вмикає soak-покриття, а також змушує umbrella-запуск виконувати package Telegram +E2E проти артефакта пакета батьківського релізу, коли `rerun_group=all`, щоб повний +pre-publish кандидат не пропускав непомітно цей напрям Telegram package. -| Профіль | Призначення | Включене покриття live/провайдерів | -| -------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `minimum` | Найшвидший критичний smoke для релізу. | OpenAI/core live path, Docker live models для OpenAI, нативне ядро Gateway, нативний профіль OpenAI Gateway, нативний OpenAI Plugin і Docker live gateway OpenAI. | -| `stable` | Типовий профіль схвалення релізу. | `minimum` плюс Anthropic smoke, Google, MiniMax, backend, нативний live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і smoke-шард OpenCode Go. | -| `full` | Широкий консультативний sweep. | `stable` плюс консультативні провайдери, live-шарди Plugin і live-шарди медіа. | +| Профіль | Призначене використання | Включене live/provider-покриття | +| -------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `minimum` | Найшвидший критичний для релізу smoke. | OpenAI/core live path, Docker live models для OpenAI, native gateway core, native OpenAI gateway profile, native OpenAI plugin і Docker live gateway OpenAI. | +| `stable` | Стандартний профіль схвалення релізу. | `minimum` плюс Anthropic smoke, Google, MiniMax, backend, native live test harness, Docker live CLI backend, Docker ACP bind, Docker Codex harness і OpenCode Go smoke shard. | +| `full` | Широкий advisory sweep. | `stable` плюс advisory providers, plugin live shards і media live shards. | -## Доповнення лише для full +## Додатки лише для full Ці набори пропускаються в `stable` і включаються в `full`: | Область | Покриття лише для full | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | Docker live models | OpenCode Go, OpenRouter, xAI, Z.ai і Fireworks. | -| Docker live gateway | Консультативні провайдери, розділені на шарди DeepSeek/Fireworks, OpenCode Go/OpenRouter і xAI/Z.ai. | -| Нативні профілі провайдерів Gateway | Повні шарди Anthropic Opus і Sonnet/Haiku, Fireworks, DeepSeek, повні шарди моделей OpenCode Go, OpenRouter, xAI і Z.ai. | -| Нативні live-шарди Plugin | Plugins A-K, L-N, O-Z other, Moonshot і xAI. | -| Нативні live-шарди медіа | Audio, Google music, MiniMax music і video groups A-D. | +| Docker live gateway | Advisory providers, розділені на shards DeepSeek/Fireworks, OpenCode Go/OpenRouter і xAI/Z.ai. | +| Native gateway provider profiles | Full Anthropic Opus і Sonnet/Haiku shards, Fireworks, DeepSeek, full OpenCode Go model shards, OpenRouter, xAI і Z.ai. | +| Native plugin live shards | Plugins A-K, L-N, O-Z other, Moonshot і xAI. | +| Native media live shards | Audio, Google music, MiniMax music і video groups A-D. | `stable` включає `native-live-src-gateway-profiles-anthropic-smoke` і `native-live-src-gateway-profiles-opencode-go-smoke`; `full` натомість використовує ширші -шарди моделей Anthropic і OpenCode Go. Сфокусовані повторні запуски все ще можуть використовувати -агреговані handle `native-live-src-gateway-profiles-anthropic` або +Anthropic і OpenCode Go model shards. Сфокусовані повторні запуски все ще можуть використовувати +агреговані handles `native-live-src-gateway-profiles-anthropic` або `native-live-src-gateway-profiles-opencode-go`. ## Сфокусовані повторні запуски -Використовуйте `rerun_group`, щоб не повторювати не пов’язані з цим релізні бокси: +Використовуйте `rerun_group`, щоб не повторювати непов’язані release boxes: -| Handle | Обсяг | +| Ідентифікатор | Область | | ------------------- | --------------------------------------------------------------------- | -| `all` | Усі етапи Full Release Validation. | +| `all` | Усі етапи повної валідації релізу. | | `ci` | Лише дочірній ручний повний CI. | -| `plugin-prerelease` | Лише дочірній Plugin Prerelease. | -| `release-checks` | Усі етапи OpenClaw Release Checks. | +| `plugin-prerelease` | Лише дочірній попередній реліз Plugin. | +| `release-checks` | Усі етапи перевірок релізу OpenClaw. | | `install-smoke` | Install Smoke через перевірки релізу. | -| `cross-os` | Перевірки релізу Cross-OS. | -| `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` | Published-package Telegram E2E; потребує `npm_telegram_package_spec`. | +| `cross-os` | Перевірки релізу для різних ОС. | +| `live-e2e` | Валідація E2E repo/live і шляху релізу Docker. | +| `package` | Приймання пакета. | +| `qa` | Паритет QA плюс live-напрями QA. | +| `qa-parity` | Лише напрями паритету QA і звіт. | +| `qa-live` | Лише live Matrix і Telegram для QA. | +| `npm-telegram` | E2E Telegram для опублікованого пакета; потребує `npm_telegram_package_spec`. | -Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли збій стався в одному live-наборі. +Використовуйте `live_suite_filter` з `rerun_group=live-e2e`, коли один live-набір не пройшов. Дійсні ідентифікатори фільтрів визначені в повторно використовуваному live/E2E workflow, зокрема `docker-live-models`, `live-gateway-docker`, `live-gateway-anthropic-docker`, `live-gateway-google-docker`, @@ -156,22 +161,22 @@ Telegram package-лан. `live-cli-backend-docker`, `live-acp-bind-docker` і `live-codex-harness-docker`. -Handle `live-gateway-advisory-docker` є агрегованим handle повторного запуску для його -трьох шардів провайдерів, тому він усе одно розгортається на всі завдання advisory Docker gateway. +Ідентифікатор `live-gateway-advisory-docker` є агрегованим ідентифікатором повторного запуску для своїх +трьох сегментів провайдерів, тому він усе одно розгортається до всіх advisory-завдань Docker gateway. -## Докази, які потрібно зберегти +## Докази, які слід зберегти Зберігайте зведення `Full Release Validation` як індекс рівня релізу. Воно посилається на -ідентифікатори дочірніх запусків і містить таблиці найповільніших завдань. Для збоїв спершу -перегляньте дочірній workflow, а потім повторно запустіть найменший відповідний handle вище. +ідентифікатори дочірніх запусків і містить таблиці найповільніших завдань. У разі збоїв спершу перевірте дочірній +workflow, потім повторно запустіть найменший відповідний ідентифікатор вище. Корисні артефакти: - `release-package-under-test` з батьківського Full Release Validation і `OpenClaw Release Checks` -- Артефакти Docker release-path у `.artifacts/docker-tests/` -- `package-under-test` з Package Acceptance і артефакти Docker acceptance -- Артефакти перевірок релізу Cross-OS для кожної ОС і набору -- Артефакти QA parity, Matrix і Telegram +- Артефакти шляху релізу Docker у `.artifacts/docker-tests/` +- Package Acceptance `package-under-test` і артефакти приймання Docker +- Артефакти перевірок релізу для різних ОС для кожної ОС і набору +- Артефакти паритету QA, Matrix і Telegram ## Файли workflow