diff --git a/docs/uk/ci.md b/docs/uk/ci.md index 8646f987a..96737b1dc 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,94 +1,94 @@ --- read_when: - - Потрібно зрозуміти, чому завдання CI запустилося або не запустилося - - Ви налагоджуєте невдалу перевірку GitHub Actions + - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося + - Ви налагоджуєте перевірку GitHub Actions, яка не проходить - Ви координуєте запуск або повторний запуск валідації релізу - - Ви змінюєте диспетчеризацію ClawSweeper або пересилання активності GitHub -summary: Граф завдань CI, перевірки за областю, релізні парасольки та локальні еквіваленти команд + - Ви змінюєте диспетчеризацію ClawSweeper або переспрямування активності GitHub +summary: Граф завдань CI, гейти області дії, релізні парасольки та локальні відповідники команд title: CI-конвеєр x-i18n: - generated_at: "2026-05-02T15:57:59Z" + generated_at: "2026-05-02T16:50:32Z" model: gpt-5.5 provider: openai - source_hash: 9687e386ce6beb96df10b57b43616af5366f231bd603e575ec20df386671564f + source_hash: a43af330938cc44b642678e2e76c9cbffbf507fe3ef7db1f95ce5ca2a08f08da source_path: ci.md workflow: 16 --- -OpenClaw CI виконується під час кожного push до `main` і для кожного pull request. Завдання `preflight` класифікує diff і вимикає дорогі гілки, коли змінилися лише непов’язані області. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області та розгортають повний граф для кандидатів на реліз і широкої валідації. 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`. Покриття Plugin лише для релізів міститься в окремому workflow [`Plugin Prerelease`](#plugin-prerelease) і запускається тільки з [`Full Release Validation`](#full-release-validation) або явного ручного dispatch. ## Огляд pipeline -| Завдання | Призначення | Коли виконується | -| -------------------------------- | --------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | -| `preflight` | Виявляє зміни лише в документації, змінені області, змінені extensions і формує CI-маніфест | Завжди для нечернеткових push і PR | -| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для нечернеткових push і PR | -| `security-dependency-audit` | Аудит production lockfile без залежностей щодо npm advisories | Завжди для нечернеткових push і PR | -| `security-fast` | Обов’язковий агрегат для швидких завдань безпеки | Завжди для нечернеткових push і PR | -| `check-dependencies` | Production-прохід Knip лише для залежностей плюс захист allowlist невикористаних файлів | Зміни, релевантні Node | -| `build-artifacts` | Збірка `dist/`, Control UI, перевірки зібраних артефактів і багаторазові downstream-артефакти | Зміни, релевантні Node | -| `checks-fast-core` | Швидкі Linux-гілки коректності, як-от перевірки bundled/plugin-contract/protocol | Зміни, релевантні Node | -| `checks-fast-contracts-channels` | Sharded-перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні Node | -| `checks-node-core-test` | Шарди тестів Core Node, за винятком гілок каналів, bundled, contract і extension | Зміни, релевантні Node | -| `check` | Sharded-еквівалент головного локального gate: production-типи, lint, guards, test types і strict smoke | Зміни, релевантні Node | -| `check-additional` | Шарди архітектури, boundary, extension-surface guards, package-boundary і gateway-watch | Зміни, релевантні Node | -| `build-smoke` | Smoke-тести зібраного CLI і smoke перевірка пам’яті запуску | Зміни, релевантні Node | -| `checks` | Верифікатор тестів каналів зібраних артефактів | Зміни, релевантні Node | -| `checks-node-compat-node22` | Збірка сумісності з Node 22 і smoke-гілка | Ручний CI dispatch для релізів | -| `check-docs` | Форматування документації, lint і перевірки битих посилань | Змінено документацію | -| `skills-python` | Ruff + pytest для Skills на Python | Зміни, релевантні Python-Skills | -| `checks-windows` | Windows-специфічні тести процесів/шляхів плюс регресії спільних runtime import specifier | Зміни, релевантні Windows | -| `macos-node` | Гілка TypeScript-тестів macOS із використанням спільних зібраних артефактів | Зміни, релевантні macOS | -| `macos-swift` | Swift lint, збірка й тести для застосунку macOS | Зміни, релевантні macOS | -| `android` | Android unit tests для обох flavor плюс одна збірка debug APK | Зміни, релевантні Android | -| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успіх Main CI або ручний dispatch | -| `openclaw-performance` | Щоденні/за запитом Kova runtime звіти продуктивності з гілками mock-provider, deep-profile і GPT 5.4 live | Запланований і ручний dispatch | +| Завдання | Призначення | Коли запускається | +| -------------------------------- | ---------------------------------------------------------------------------------------------------------------- | ---------------------------------- | +| `preflight` | Виявляє зміни лише в документації, changed scopes, changed extensions і будує CI manifest | Завжди для non-draft pushes і PRs | +| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для non-draft pushes і PRs | +| `security-dependency-audit` | Аудит production lockfile без залежностей за 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-file | Зміни, релевантні для 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 еквівалент головного локального gate: prod types, lint, guards, test types і strict smoke | Зміни, релевантні для Node | +| `check-additional` | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards | Зміни, релевантні для Node | +| `build-smoke` | 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 для релізів | +| `check-docs` | Перевірки форматування документації, lint і broken-link | Документацію змінено | +| `skills-python` | Ruff + pytest для Skills на базі Python | Зміни, релевантні для Python-skill | +| `checks-windows` | Windows-specific process/path tests плюс регресії shared runtime import specifier | Зміни, релевантні для 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 | Зміни, релевантні для Android | +| `test-performance-agent` | Щоденна оптимізація slow-test у Codex після trusted activity | Успіх Main CI або ручний dispatch | +| `openclaw-performance` | Щоденні/on-demand звіти Kova runtime performance із 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` швидко падають, не чекаючи на важчі завдання матриці артефактів і платформ. -3. `build-artifacts` перекривається зі швидкими Linux-гілками, щоб downstream-споживачі могли стартувати щойно спільна збірка готова. -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 також не падає. Агреговані перевірки шардів використовують `!cancelled() && always()`, тому вони все одно повідомляють звичайні збої шардів, але не стають у чергу після того, як увесь workflow уже був замінений. Автоматичний ключ конкурентності CI версіонований (`CI-v7-*`), тому GitHub-side zombie у старій групі черги не може безстроково блокувати новіші main-запуски. Ручні запуски повного набору використовують `CI-manual-v1-*` і не скасовують запуски, що вже виконуються. +GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це CI noise, якщо найновіший запуск для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все одно звітують про звичайні shard failures, але не стають у чергу після того, як увесь workflow уже superseded. Автоматичний CI concurrency key версіонований (`CI-v7-*`), тому GitHub-side zombie у старій queue group не може нескінченно блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs. -## Область і маршрутизація +## Scope і маршрутизація -Логіка областей міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. Ручний dispatch пропускає виявлення changed-scope і змушує preflight-маніфест поводитися так, ніби змінилися всі scoped області. +Логіка 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-граф плюс linting workflow, але самі по собі не примушують Windows, Android або macOS native builds; ці platform-гілки залишаються обмеженими змінами platform source. -- **Правки лише маршрутизації CI, вибрані дешеві правки core-test fixture і вузькі правки helper/test-routing для plugin contract** використовують швидкий Node-only шлях маніфесту: `preflight`, security і одне завдання `checks-fast-core`. Цей шлях пропускає build artifacts, сумісність із Node 22, channel contracts, повні core shards, bundled-plugin shards і додаткові матриці guard, коли зміна обмежена routing або helper surfaces, які швидке завдання напряму перевіряє. -- **Windows Node checks** обмежені Windows-специфічними wrappers процесів/шляхів, npm/pnpm/UI runner helpers, конфігурацією package manager і поверхнями CI workflow, які виконують цю гілку; непов’язані source, plugin, install-smoke і test-only зміни залишаються на Linux Node гілках. +- **Редагування CI workflow** перевіряють Node CI graph плюс workflow linting, але самі по собі не примушують виконувати Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source. +- **Редагування лише CI routing, вибрані дешеві 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** обмежені 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-тестів розділено або збалансовано так, щоб кожне завдання залишалося малим без надмірного резервування runners: channel contracts виконуються як три зважені шарди, малі core unit lanes об’єднані парами, auto-reply виконується як чотири збалансовані workers (із reply subtree, розділеним на шарди agent-runner, dispatch і commands/state-routing), а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують власні dedicated Vitest configs замість спільного plugin catch-all. Include-pattern shards записують timing entries із назвою CI shard, щоб `.artifacts/vitest-shard-timings.json` міг відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards конкурентно всередині одного завдання. Gateway watch, channel tests і core support-boundary shard виконуються конкурентно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані. +Найповільніші Node test families розділені або збалансовані так, щоб кожне завдання залишалося невеликим без надмірного резервування runners: channel contracts виконуються як три weighted shards, small core unit lanes паруються, auto-reply запускається як чотири balanced workers (із розбиттям reply subtree на shards agent-runner, dispatch і commands/state-routing), а agentic gateway/plugin configs розподіляються по наявних source-only agentic Node jobs замість очікування built artifacts. Broad browser, QA, media і 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 shard запускає свої невеликі independent guards паралельно всередині одного завдання. Gateway watch, channel tests і core support-boundary shard виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані. -Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test гілка все одно компілює flavor із SMS/call-log BuildConfig flags, уникаючи дубльованого debug APK packaging job для кожного Android-relevant push. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює flavor із BuildConfig flags для SMS/call-log, уникаючи duplicate debug APK packaging job під час кожного Android-relevant push. -Шард `check-dependencies` виконує `pnpm deadcode:dependencies` (production Knip dependency-only pass, закріплений на найновішій версії 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`) і `pnpm deadcode:unused-files`, який порівнює production unused-file findings Knip із `scripts/deadcode-unused-files.allowlist.mjs`. Unused-file guard падає, коли PR додає новий unreviewed unused file або залишає stale allowlist entry, водночас зберігаючи навмисні dynamic plugin, generated, build, live-test і package bridge surfaces, які Knip не може статично resolve. -## Перенаправлення активності ClawSweeper +## Пересилання активності ClawSweeper -`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge з активності репозиторію OpenClaw до ClawSweeper. Він не check out і не виконує недовірений код pull request. Workflow створює GitHub App token із `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім відправляє компактні payloads `repository_dispatch` до `openclaw/clawsweeper`. +`.github/workflows/clawsweeper-dispatch.yml` є target-side bridge від активності repository OpenClaw до ClawSweeper. Він не виконує checkout і не запускає ненадійний код pull request. Workflow створює GitHub App token із `CLAWSWEEPER_APP_PRIVATE_KEY`, а потім dispatches компактні payloads `repository_dispatch` до `openclaw/clawsweeper`. -Workflow має чотири гілки: +Workflow має чотири lanes: -- `clawsweeper_item` для точних запитів review issue і pull request; -- `clawsweeper_comment` для явних команд ClawSweeper у коментарях issue; -- `clawsweeper_commit_review` для commit-level review requests на push до `main`; -- `github_activity` для загальної активності GitHub, яку може перевіряти агент ClawSweeper. +- `clawsweeper_item` для точних issue і pull request review requests; +- `clawsweeper_comment` для явних команд ClawSweeper у issue comments; +- `clawsweeper_commit_review` для commit-level review requests на pushes до `main`; +- `github_activity` для загальної активності GitHub, яку agent ClawSweeper може inspect. -Гілка `github_activity` пересилає лише нормалізовані metadata: event type, action, actor, repository, item number, URL, title, state і короткі excerpts для comments або reviews, коли вони наявні. Вона навмисно уникає пересилання повного webhook body. Приймальний workflow у `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який публікує нормалізовану подію до OpenClaw Gateway hook для агента ClawSweeper. +Lane `github_activity` пересилає лише нормалізовані metadata: event type, action, actor, repository, item number, URL, title, state і short excerpts для comments або reviews, якщо вони є. Вона навмисно не пересилає full webhook body. Receiving workflow в `openclaw/clawsweeper` — це `.github/workflows/github-activity.yml`, який публікує normalized event до OpenClaw Gateway hook для agent ClawSweeper. -Загальна активність є спостереженням, а не доставкою за замовчуванням. Агент ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли подія є несподіваною, actionable, risky або operationally useful. Рутинні opens, edits, bot churn, duplicate webhook noise і normal review traffic мають завершуватися `NO_REPLY`. +General activity — це observation, а не delivery-by-default. Agent ClawSweeper отримує Discord target у своєму prompt і має публікувати в `#clawsweeper` лише тоді, коли event є surprising, 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 недовіреними даними на всьому цьому шляху. Вони є input для summarization і triage, а не інструкціями для workflow або agent runtime. +Сприймайте GitHub titles, comments, bodies, review text, branch names і commit messages як untrusted data в усьому цьому path. Вони є input для summarization і triage, а не instructions для workflow або agent runtime. -## Ручні dispatches +## Manual dispatches -Ручні запускі CI виконують той самий граф завдань, що й звичайна CI, але примусово вмикають кожну scoped lane, не пов’язану з Android: шарди 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`. Статичні перевірки prerelease Plugin, release-only шард `agentic-plugins`, повний batch sweep розширень і Docker lanes prerelease Plugin виключено з CI. Набір Docker prerelease запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate release-validation. +Ручні запуски CI виконують той самий граф завдань, що й звичайна CI, але примусово вмикають кожну не-Android scoped lane: Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python skills, Windows, macOS і Control UI i18n. Автономні ручні запуски CI виконують лише Android із `include_android=true`; повний релізний umbrella вмикає Android, передаючи `include_android=true`. Статичні передрелізні перевірки Plugin, релізний shard `agentic-plugins`, повний пакетний sweep extension і передрелізні Docker lanes Plugin виключено з CI. Передрелізний Docker suite запускається лише тоді, коли `Full Release Validation` запускає окремий workflow `Plugin Prerelease` з увімкненим gate release-validation. -Ручні запускі використовують унікальну concurrency group, тому повний набір release-candidate не скасовується іншим push або PR run на тому самому ref. Необов’язковий вхід `target_ref` дає довіреному викликачеві змогу запускати цей граф для гілки, тега або повного SHA коміту, використовуючи файл workflow з вибраного dispatch ref. +Ручні запуски використовують унікальну групу concurrency, щоб повний suite release-candidate не було скасовано іншим запуском push або PR на тому самому ref. Необов’язковий вхідний параметр `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 +## Ранери -| Runner | Завдання | -| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `ubuntu-24.04` | `preflight`, швидкі завдання безпеки та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі перевірки протоколу/контрактів/bundled, шардовані перевірки контрактів каналів, шарди `check`, крім lint, шарди та агрегати `check-additional`, перевіряльники агрегатів Node tests, перевірки документації, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла стати в чергу раніше | -| `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 tests, шарди bundled plugin tests, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо чутливий до CPU, щоб 8 vCPU коштували більше, ніж заощаджували); install-smoke Docker builds (час очікування в черзі для 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` | +| Ранер | Завдання | +| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `ubuntu-24.04` | `preflight`, швидкі security jobs та агрегати (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled checks, sharded channel contract checks, shards `check`, окрім lint, shards і агрегати `check-additional`, Node test aggregate verifiers, перевірки документації, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла стати в чергу раніше | +| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, легші extension shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | +| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux Node test shards, bundled plugin test shards, `android` | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (достатньо чутливий до CPU, щоб 8 vCPU коштували більше, ніж заощаджували); install-smoke Docker builds (час очікування в черзі 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` | ## Локальні еквіваленти @@ -137,34 +137,36 @@ pnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.jso ## Продуктивність OpenClaw -`OpenClaw Performance` — це workflow продуктивності продукту/runtime. Він щодня запускається на `main` і може бути запущений вручну: +`OpenClaw Performance` — це workflow продуктивності продукту/runtime. Він запускається щодня на `main` і може бути запущений вручну: ```bash gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3 gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_gpt54=true ``` -Workflow встановлює OCM із закріпленого релізу та Kova із закріпленого входу `kova_ref`, а потім запускає три lanes: +Workflow встановлює OCM із pinned release і Kova з pinned input `kova_ref`, а потім запускає три lanes: - `mock-provider`: діагностичні сценарії Kova проти runtime локальної збірки з детермінованою фейковою OpenAI-compatible auth. -- `mock-deep-profile`: профілювання CPU/heap/trace для startup, Gateway і гарячих точок agent-turn. -- `live-gpt54`: реальний turn агента OpenAI `openai/gpt-5.4`, який пропускається, коли `OPENAI_API_KEY` недоступний. +- `mock-deep-profile`: CPU/heap/trace profiling для startup, gateway і agent-turn hotspots. +- `live-gpt54`: реальний agent turn OpenAI `openai/gpt-5.4`, який пропускається, коли `OPENAI_API_KEY` недоступний. -Кожна lane завантажує GitHub artifacts. Коли `CLAWGRIT_REPORTS_TOKEN` налаштовано, workflow також комітить `report.json`, `report.md`, bundles і `index.md` до `openclaw/clawgrit-reports` у `openclaw-performance//-//`. Поточний branch pointer записується як `openclaw-performance//latest-.json`. +Lane mock-provider також запускає OpenClaw-native source probes після проходу Kova: gateway boot timing і пам’ять для випадків запуску default, hook і 50-plugin; повторювані mock-OpenAI loops `channel-chat-baseline` hello; і команди CLI startup проти запущеного gateway. Markdown-зведення source probe міститься в `source/index.md` у report bundle, поруч із raw JSON. -## Повна перевірка релізу +Кожна lane завантажує GitHub artifacts. Коли налаштовано `CLAWGRIT_REPORTS_TOKEN`, workflow також комітить `report.json`, `report.md`, bundles, `index.md` і source-probe artifacts до `openclaw/clawgrit-reports` у `openclaw-performance//-//`. Поточний branch pointer записується як `openclaw-performance//latest-.json`. -`Full Release Validation` — це ручний umbrella workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю, запускає `Plugin Prerelease` для release-only proof Plugin/package/static/Docker і запускає `OpenClaw Release Checks` для install smoke, package acceptance, наборів Docker release-path, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram lanes. З `rerun_group=all` і `release_profile=full` він також запускає `NPM Telegram Beta E2E` проти artifact `release-package-under-test` з release checks. Після публікації передайте `npm_telegram_package_spec`, щоб повторно запустити ту саму Telegram package lane проти опублікованого npm package. +## Повна валідація релізу -Див. [Повну перевірку релізу](/uk/reference/full-release-validation), щоб отримати -stage matrix, точні назви завдань workflow, відмінності профілів, artifacts і +`Full Release Validation` — це ручний umbrella workflow для "запустити все перед релізом". Він приймає branch, tag або повний commit 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`, щоб повторно запустити ту саму Telegram package lane проти опублікованого npm package. + +Див. [Повну валідацію релізу](/uk/reference/full-release-validation) для +stage matrix, точних назв workflow jobs, відмінностей профілів, artifacts і focused rerun handles. `OpenClaw Release Publish` — це ручний mutating release workflow. Запускайте його -з `release/YYYY.M.D` або `main` після того, як release tag існує, і після того, як -OpenClaw npm preflight успішно завершився. Він перевіряє `pnpm plugins:sync:check`, +з `release/YYYY.M.D` або `main` після створення release tag і після успішного +OpenClaw npm preflight. Він перевіряє `pnpm plugins:sync:check`, запускає `Plugin NPM Release` для всіх publishable plugin packages, запускає -`Plugin ClawHub Release` для того самого release SHA, і лише потім запускає +`Plugin ClawHub Release` для того самого release SHA і лише потім запускає `OpenClaw NPM Release` зі збереженим `preflight_run_id`. ```bash @@ -175,40 +177,47 @@ gh workflow run openclaw-release-publish.yml \ -f npm_dist_tag=beta ``` -Для proof закріпленого коміту на швидко змінюваній гілці використовуйте helper замість +Для доказу pinned commit на branch, що швидко змінюється, використовуйте helper замість `gh workflow run ... --ref main -f ref=`: ```bash pnpm ci:full-release --sha ``` -GitHub workflow dispatch refs мають бути гілками або тегами, а не сирими SHA комітів. Helper пушить тимчасову гілку `release-ci/-...` на цільовий SHA, запускає `Full Release Validation` із цього закріпленого ref, перевіряє, що кожен child workflow `headSha` збігається з ціллю, і видаляє тимчасову гілку, коли run завершується. Umbrella verifier також завершується з помилкою, якщо будь-який child workflow виконувався на іншому SHA. +GitHub workflow dispatch refs мають бути branches або tags, а не raw commit SHAs. Helper +публікує тимчасовий branch `release-ci/-...` на цільовому SHA, +запускає `Full Release Validation` з цього pinned ref, перевіряє, що кожен child +workflow `headSha` збігається з ціллю, і видаляє тимчасовий branch, коли +запуск завершується. Umbrella verifier також завершується з помилкою, якщо будь-який child workflow працював на +іншому SHA. -`release_profile` керує шириною live/provider, що передається в release checks. Ручні release workflows за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли ви навмисно хочете широку advisory provider/media matrix. +`release_profile` керує шириною live/provider, що передається в release checks. Ручні +release workflows за замовчуванням використовують `stable`; використовуйте `full` лише тоді, коли ви +навмисно хочете широку advisory provider/media matrix. - `minimum` залишає найшвидші OpenAI/core release-critical lanes. - `stable` додає stable provider/backend set. - `full` запускає широку advisory provider/media matrix. -Umbrella записує ids запущених child runs, а фінальне завдання `Verify full validation` повторно перевіряє поточні conclusions child runs і додає таблиці slowest-job для кожного child run. Якщо child workflow перезапущено і він став зеленим, перезапустіть лише parent verifier job, щоб оновити результат umbrella і підсумок timings. +Umbrella записує ids запущених child runs, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки child run і додає таблиці slowest-job для кожного child run. Якщо child workflow повторно запущено і він став зеленим, повторно запустіть лише parent verifier job, щоб оновити результат umbrella і timing summary. -Для відновлення `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` в umbrella. Це утримує повторний запуск невдалого релізного середовища в обмежених межах після цільового виправлення. +Для відновлення і `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` на парасольковому workflow. Це утримує повторний запуск невдалого релізного бокса в обмежених межах після цільового виправлення. -`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і workflow Docker для live/E2E релізного шляху, і shard приймання пакета. Це зберігає однакові байти пакета в усіх релізних середовищах і уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. +`OpenClaw Release Checks` використовує довірене посилання workflow, щоб один раз розв’язати вибране посилання в tarball `release-package-under-test`, а потім передає цей артефакт і до Docker workflow релізного шляху для live/E2E, і до шарду приймання пакета. Це зберігає байти пакета узгодженими між релізними боксами й уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. -Дублікати запусків `Full Release Validation` для `ref=main` і `rerun_group=all` -замінюють старіший umbrella. Батьківський монітор скасовує будь-який дочірній workflow, який -він уже надіслав, коли батьківський workflow скасовано, тому новіша валідація main -не стоїть за застарілим двогодинним запуском release-check. Валідація гілки/тега релізу +Дубльовані запуски `Full Release Validation` для `ref=main` і `rerun_group=all` +замінюють старіший парасольковий workflow. Батьківський монітор скасовує будь-який дочірній workflow, який він +уже відправив, коли батьківський скасовано, тому новіша валідація main +не очікує за застарілим двогодинним запуском release-check. Валідація релізних гілок/тегів і цільові групи повторного запуску зберігають `cancel-in-progress: false`. -## Live і E2E shards +## Live та E2E шарди -Дочірній live/E2E для релізу зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані shards через `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` -- завдання `native-live-src-gateway-profiles`, відфільтровані за провайдером +- відфільтровані за провайдером завдання `native-live-src-gateway-profiles` - `native-live-src-gateway-backends` - `native-live-test` - `native-live-extensions-a-k` @@ -216,61 +225,61 @@ Umbrella записує ids запущених child runs, а фінальне - `native-live-extensions-openai` - `native-live-extensions-o-z-other` - `native-live-extensions-xai` -- розділені shards аудіо/відео для медіа та shards музики, відфільтровані за провайдером +- розділені шарди media audio/video та відфільтровані за провайдером music шарди -Це зберігає те саме файлове покриття, водночас спрощуючи повторний запуск і діагностику повільних збоїв live-провайдерів. Агреговані назви shards `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються дійсними для ручних одноразових повторних запусків. +Це зберігає те саме файлове покриття, водночас роблячи повільні збої live-провайдерів простішими для повторного запуску й діагностики. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових повторних запусків. -Нативні live media shards запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; медіа-завдання лише перевіряють двійкові файли перед налаштуванням. Залишайте live-набори з Docker-підтримкою на звичайних Blacksmith runners — container jobs є неправильним місцем для запуску вкладених Docker-тестів. +Нативні live media шарди виконуються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; media-завдання лише перевіряють бінарні файли перед налаштуванням. Тримайте live-набори з Docker-підтримкою на звичайних раннерах Blacksmith — контейнерні завдання є неправильним місцем для запуску вкладених Docker-тестів. -Live shards моделей/backend з Docker-підтримкою використовують окремий спільний образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Workflow live-релізу збирає й публікує цей образ один раз, після чого Docker live shards для моделі, Gateway за провайдерами, backend CLI, ACP bind і Codex harness запускаються з `OPENCLAW_SKIP_DOCKER_BUILD=1`. Docker shards Gateway мають явні обмеження `timeout` на рівні скриптів, нижчі за timeout завдання workflow, щоб завислий контейнер або шлях очищення швидко падав, а не споживав увесь бюджет release-check. Якщо ці shards перебудовують повну source Docker target незалежно, релізний запуск налаштовано неправильно, і він марнуватиме реальний час на дубльовані збірки образів. +Live model/backend шарди з Docker-підтримкою використовують окремий спільний образ `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 шарди мають явні обмеження `timeout` на рівні скрипта нижче за timeout завдання workflow, щоб завислий контейнер або шлях очищення швидко падав, а не споживав увесь бюджет release-check. Якщо ці шарди незалежно перебудовують повну source Docker target, релізний запуск налаштовано неправильно, і він витрачатиме час на дубльовані збірки образів. -## Package Acceptance +## Приймання пакета -Використовуйте `Package Acceptance`, коли питання таке: «чи працює цей інстальований пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево source, тоді як package acceptance перевіряє один tarball через той самий Docker E2E harness, який користувачі застосовують після встановлення або оновлення. +Використовуйте `Package Acceptance`, коли питання звучить так: «чи працює цей встановлюваний пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: звичайний CI перевіряє дерево вихідного коду, тоді як приймання пакета перевіряє один 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. -2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Reusable workflow завантажує цей артефакт, перевіряє інвентар tarball, готує Docker-образи package-digest за потреби й запускає вибрані Docker lanes проти цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, reusable workflow готує пакет і спільні образи один раз, а потім розгортає ці lanes як паралельні цільові Docker jobs з унікальними артефактами. -3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, коли Package Acceptance розв’язав один; окремий dispatch Telegram усе ще може встановити опубліковану npm-специфікацію. -4. `summary` завершує workflow з помилкою, якщо розв’язання пакета, Docker acceptance або опційна Telegram lane завершилися невдало. +1. `resolve_package` витягує `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і друкує source, workflow ref, package ref, version, SHA-256 і profile у підсумку кроку GitHub. +2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує package-digest Docker-образи й запускає вибрані Docker lanes проти цього пакета замість пакування workflow checkout. Коли profile вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow готує пакет і спільні образи один раз, а потім розгортає ці lanes як паралельні цільові Docker-завдання з унікальними артефактами. +3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance розв’язав його; автономний dispatch Telegram усе ще може встановити опублікований npm spec. +4. `summary` провалює workflow, якщо розв’язання пакета, Docker acceptance або опційний Telegram lane зазнали невдачі. ### Джерела кандидатів -- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну релізну версію OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих beta/stable. -- `source=ref` пакує довірену гілку, тег або повний SHA коміту `package_ref`. Resolver отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілок репозиторію або релізного тега, встановлює залежності у від’єднаному worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. +- `source=npm` приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих beta/stable. +- `source=ref` пакує довірені `package_ref` branch, tag або full commit SHA. Resolver витягує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілок репозиторію або релізного тегу, встановлює deps у detached worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. - `source=url` завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим. -- `source=artifact` завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` є опційним, але його слід надавати для зовнішньо поширених артефактів. +- `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. +Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточному test harness перевіряти старіші довірені коміти вихідного коду без запуску старої логіки workflow. ### Профілі наборів - `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` — повні chunks Docker релізного шляху з OpenWebUI +- `full` — повні Docker-фрагменти релізного шляху з OpenWebUI - `custom` — точні `docker_lanes`; обов’язково, коли `suite_profile=custom` -Профіль `package` використовує offline-покриття plugins, щоб валідація опублікованого пакета не залежала від live-доступності ClawHub. Опційна Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації зберігається для окремих dispatches. +Профіль `package` використовує offline plugin coverage, щоб валідація опублікованого пакета не залежала від live-доступності ClawHub. Опційний Telegram lane повторно використовує артефакт `package-under-test` у `NPM Telegram Beta E2E`, а шлях опублікованого npm spec збережено для автономних dispatch. -Для спеціальної політики тестування оновлень і plugins, зокрема локальних команд, -Docker lanes, inputs Package Acceptance, релізних defaults і triage збоїв, -див. [Тестування оновлень і plugins](/uk/help/testing-updates-plugins). +Для спеціальної політики тестування оновлень і Plugin, включно з локальними командами, +Docker lanes, вхідними даними Package Acceptance, релізними типовими налаштуваннями та triage збоїв, +див. [Тестування оновлень і plugin](/uk/help/testing-updates-plugins). -Release checks викликають Package Acceptance з `source=artifact`, підготовленим артефактом релізного пакета, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це зберігає перевірку міграції пакета, оновлення, очищення застарілих залежностей plugins, відновлення встановлення налаштованих plugins, offline plugins, plugin-update і Telegram на тому самому розв’язаному package tarball. Cross-OS release checks усе ще покривають OS-specific onboarding, installer і поведінку платформи; продуктова валідація package/update має починатися з Package Acceptance. Docker lane `published-upgrade-survivor` перевіряє один baseline опублікованого пакета за запуск. У Package Acceptance розв’язаний tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback published baseline, за замовчуванням `openclaw@latest`; команди повторного запуску failed-lane зберігають цей baseline. Встановіть `published_upgrade_survivor_baselines=release-history`, щоб розширити lane на дедупліковану матрицю історії: останні шість stable releases, `2026.4.23` і останній stable release перед `2026-03-15`. Встановіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розширити ті самі baselines на issue-shaped fixtures для конфігурації Feishu, збережених файлів bootstrap/persona, встановлень налаштованих plugins OpenClaw, tilde log paths і застарілих legacy plugin dependency roots. Окремий workflow `Update Migration` використовує Docker lane `update-migration` з `all-since-2026.4.23` і `plugin-deps-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` для матриці сценаріїв. Published lane налаштовує baseline за допомогою вбудованого рецепта команди `openclaw config set`, записує кроки рецепта в `summary.json` і перевіряє `/healthz`, `/readyz`, а також статус RPC після запуску Gateway. Windows packaged і installer fresh lanes також перевіряють, що встановлений пакет може імпортувати browser-control override з raw absolute Windows path. Cross-OS agent-turn smoke для OpenAI за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли він заданий, інакше `openai/gpt-5.4`, тож доказ встановлення й Gateway залишається на тестовій моделі GPT-5, уникаючи defaults GPT-4.x. +Release checks викликає Package Acceptance з `source=artifact`, підготовленим release package artifact, `suite_profile=custom`, `docker_lanes='doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update'`, `published_upgrade_survivor_baselines=release-history`, `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Це утримує докази міграції пакета, оновлення, очищення залежностей застарілих plugin, ремонту встановлення налаштованих plugin, offline plugin, plugin-update і Telegram на тому самому розв’язаному package tarball. Cross-OS release checks і далі покривають OS-specific onboarding, installer і platform behavior; package/update product validation має починатися з Package Acceptance. Docker lane `published-upgrade-survivor` перевіряє один опублікований package baseline за запуск. У Package Acceptance розв’язаний tarball `package-under-test` завжди є кандидатом, а `published_upgrade_survivor_baseline` вибирає fallback published baseline, типово `openclaw@latest`; команди повторного запуску failed-lane зберігають цей baseline. Встановіть `published_upgrade_survivor_baselines=release-history`, щоб розгорнути lane на дедупліковану history matrix: останні шість stable releases, `2026.4.23` і останній stable release до `2026-03-15`. Встановіть `published_upgrade_survivor_scenarios=reported-issues`, щоб розгорнути ті самі baselines на issue-shaped fixtures для конфігурації Feishu, збережених bootstrap/persona files, налаштованих встановлень OpenClaw plugin, tilde log paths і застарілих 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 за допомогою вбудованого recipe команди `openclaw config set`, записує recipe steps у `summary.json` і перевіряє `/healthz`, `/readyz` та RPC status після запуску Gateway. Windows packaged і installer fresh lanes також перевіряють, що встановлений пакет може імпортувати browser-control override з raw absolute Windows path. OpenAI cross-OS agent-turn smoke типово використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли встановлено, інакше `openai/gpt-5.4`, тому докази install і gateway залишаються на GPT-5 test model, уникаючи GPT-4.x defaults. -### Вікна сумісності зі спадковими версіями +### Вікна сумісності зі спадщиною -Package Acceptance має обмежені вікна legacy-compatibility для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати шлях сумісності: +Package Acceptance має обмежені вікна legacy-compatibility для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати compatibility path: -- відомі приватні записи QA у `dist/postinstall-inventory.json` можуть указувати на файли, пропущені в tarball; -- `doctor-switch` може пропустити підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець; -- `update-channel-switch` може вилучати відсутні `pnpm.patchedDependencies` з підробленої git fixture, виведеної з tarball, і може логувати відсутній збережений `update.channel`; -- plugin smokes можуть читати legacy locations install-record або приймати відсутнє збереження marketplace install-record; -- `plugin-update` може дозволяти міграцію config metadata, водночас усе ще вимагаючи, щоб install record і поведінка no-reinstall залишалися незмінними. +- відомі private QA entries у `dist/postinstall-inventory.json` можуть вказувати на файли, пропущені з tarball; +- `doctor-switch` може пропустити subcase persistence для `gateway install --wrapper`, коли пакет не надає цей flag; +- `update-channel-switch` може прибрати відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і може залогувати відсутній persisted `update.channel`; +- plugin smokes можуть читати legacy install-record locations або приймати відсутню marketplace install-record persistence; +- `plugin-update` може дозволяти migration config metadata, водночас усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними. -Опублікований пакет `2026.4.26` також може попереджати про локальні файли штампів metadata збірки, які вже були відвантажені. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови призводять до збою, а не до попередження чи пропуску. +Опублікований пакет `2026.4.26` також може попереджати про local build metadata stamp files, які вже були доставлені. Пізніші пакети мають відповідати modern contracts; ті самі умови завершуються failure замість warn або skip. ### Приклади @@ -313,111 +322,111 @@ 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`, журнали lane, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes замість повторного запуску повної валідації релізу. +Під час налагодження невдалого запуску package acceptance почніть із підсумку `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перегляньте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lane, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes замість повторного запуску повної release validation. -## Smoke-перевірка встановлення +## Перевірка встановлення -Окремий робочий процес `Install Smoke` повторно використовує той самий scope-скрипт через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. +Окремий workflow `Install Smoke` повторно використовує той самий scope-скрипт через власне завдання `preflight`. Він розділяє покриття smoke-перевірок на `run_fast_install_smoke` і `run_full_install_smoke`. -- **Швидкий шлях** запускається для pull request, які зачіпають Docker/package поверхні, зміни пакетів/маніфестів bundled plugin або core plugin/channel/gateway/Plugin SDK поверхні, які перевіряють Docker smoke-завдання. Зміни лише у вихідному коді bundled plugin, правки лише тестів і правки лише документації не резервують Docker-воркери. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI smoke для видалення agents у спільному робочому просторі, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений bundled-plugin Docker profile із 240-секундним сукупним таймаутом команди (Docker-запуск кожного сценарію обмежено окремо). -- **Повний шлях** зберігає QR package install і installer Docker/update покриття для нічних запланованих запусків, ручних запусків, release checks через workflow-call і pull request, які справді зачіпають installer/package/Docker поверхні. У повному режимі install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий bundled-plugin Docker E2E як окремі завдання, щоб installer-робота не чекала за root image smokes. +- **Швидкий шлях** запускається для pull requests, що торкаються поверхонь Docker/package, змін пакетів/маніфестів вбудованих Plugin, або поверхонь core Plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише у вихідному коді вбудованих Plugin, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає agents delete shared-workspace CLI smoke, запускає container gateway-network e2e, перевіряє build arg вбудованого extension і запускає обмежений Docker-профіль вбудованих Plugin із 240-секундним агрегованим таймаутом команди (Docker-запуск кожного сценарію обмежено окремо). +- **Повний шлях** залишає встановлення QR package і Docker/update-покриття інсталятора для нічних запланованих запусків, ручних dispatch, workflow-call release checks і pull requests, які справді торкаються поверхонь installer/package/Docker. У повному режимі install-smoke готує або повторно використовує один target-SHA GHCR root Dockerfile smoke image, а потім запускає QR package install, root Dockerfile/gateway smokes, installer/update smokes і швидкий bundled-plugin Docker E2E як окремі jobs, щоб робота інсталятора не чекала за root image smokes. -Пуші в `main` (включно з merge commits) не примушують повний шлях; коли логіка changed-scope запитала б повне покриття під час push, робочий процес зберігає швидкий Docker smoke і залишає повний install smoke для нічного запуску або release validation. +Пуші в `main` (зокрема merge commits) не примушують повний шлях; коли логіка changed-scope запитувала б повне покриття під час push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічного запуску або release validation. -Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з робочого процесу release checks, а ручні запуски `Install Smoke` можуть увімкнути його, але pull request і пуші в `main` ні. QR і installer Docker tests зберігають власні Dockerfile, орієнтовані на встановлення. +Повільний Bun global install image-provider smoke окремо керується `run_bun_global_install_smoke`. Він запускається за нічним розкладом і з workflow release checks, а ручні dispatch `Install Smoke` можуть увімкнути його, але pull requests і пуші в `main` цього не роблять. QR і installer Docker tests зберігають власні install-focused Dockerfiles. ## Локальний Docker E2E `pnpm test:docker:all` попередньо збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: -- базовий Node/Git runner для installer/update/plugin-dependency lanes; -- функціональний образ, який встановлює той самий tarball у `/app` для normal functionality lanes. +- базовий Node/Git runner для lanes інсталятора/update/plugin-dependency; +- функціональний образ, який встановлює той самий tarball у `/app` для lanes звичайної функціональності. -Визначення 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`. +Визначення Docker lanes розташовані в `scripts/lib/docker-e2e-scenarios.mjs`, логіка planner — у `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний plan. Scheduler вибирає образ для lane через `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`. -### Налаштування +### Налаштовувані параметри -| Змінна | Типово | Призначення | -| ------------------------------------- | ------- | -------------------------------------------------------------------------------------------- | -| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів основного пулу для звичайних lanes. | -| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів tail-пулу, чутливого до провайдерів. | -| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Обмеження паралельних live lanes, щоб провайдери не throttled. | -| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Обмеження паралельних npm install lanes. | -| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Обмеження паралельних multi-service lanes. | -| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами lanes, щоб уникнути create storms 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, щоб agents могли відтворити одну невдалу lane. | +| Змінна | Типово | Призначення | +| ------------------------------------- | ------- | --------------------------------------------------------------------------------------------- | +| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | Кількість слотів main-pool для звичайних lanes. | +| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | Кількість слотів tail-pool, чутливого до провайдерів. | +| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | Ліміт одночасних live lanes, щоб провайдери не throttling. | +| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | Ліміт одночасних npm install lanes. | +| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | Ліміт одночасних multi-service lanes. | +| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | Затримка між стартами lanes, щоб уникнути create storms у Docker daemon; задайте `0`, щоб вимкнути затримку. | +| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | Резервний таймаут для кожної lane (120 хвилин); вибрані live/tail lanes мають жорсткіші обмеження. | +| `OPENCLAW_DOCKER_ALL_DRY_RUN` | unset | `1` друкує scheduler plan без запуску lanes. | +| `OPENCLAW_DOCKER_ALL_LANES` | unset | Список точних lanes, розділених комами; пропускає cleanup smoke, щоб agents могли відтворити одну невдалу lane. | -Lane, важча за свій ефективний ліміт, усе ще може стартувати з порожнього пулу, а потім працює сама, доки не звільнить capacity. Локальний aggregate виконує preflight Docker, видаляє застарілі OpenClaw E2E контейнери, виводить статус активних lanes, зберігає таймінги lanes для longest-first ordering і за замовчуванням припиняє планувати нові pooled lanes після першої помилки. +Lane, важча за свій ефективний cap, усе одно може стартувати з порожнього pool, а потім виконується сама, доки не звільнить capacity. Локальний aggregate preflights Docker, видаляє застарілі OpenClaw E2E containers, виводить active-lane status, зберігає таймінги lanes для сортування longest-first і за замовчуванням припиняє планування нових pooled lanes після першої помилки. -### Багаторазовий live/E2E робочий процес +### Повторно використовуваний live/E2E workflow -Багаторазовий live/E2E робочий процес запитує `scripts/test-docker-all.mjs --plan-json`, які package, image kind, live image, lane і credential coverage потрібні. Потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного запуску, або завантажує package artifact з `package_artifact_run_id`; перевіряє inventory tarball; збирає й пушить package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли план потребує package-installed lanes; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість повторної збірки. Docker image pulls повторюються з обмеженим 180-секундним таймаутом на спробу, щоб завислий потік registry/cache швидко повторився, а не спожив більшість критичного шляху CI. +Повторно використовуваний live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке покриття package, image kind, live image, lane і credentials потрібне. Потім `scripts/docker-e2e.mjs` перетворює цей plan на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact із поточного запуску, або завантажує package artifact із `package_artifact_run_id`; перевіряє inventory tarball; збирає і пушить package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли plan потребує package-installed lanes; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість перебудови. Docker image pulls повторюються з обмеженим 180-секундним таймаутом на спробу, щоб завислий registry/cache stream швидко повторився, а не споживав більшість критичного шляху CI. -### Чанки release-path +### Фрагменти release-path -Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk тягнув лише потрібний image kind і виконував кілька lanes через той самий weighted scheduler: +Release Docker coverage запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний image kind і виконував кілька lanes через той самий weighted scheduler: - `OPENCLAW_DOCKER_ALL_PROFILE=release-path` - `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..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` залишаються aggregate plugin/runtime aliases. Alias lane `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes. +Поточні 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. Alias lane `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes. -OpenWebUI входить до `plugins-runtime-services`, коли повне release-path coverage запитує його, і зберігає окремий chunk `openwebui` лише для OpenWebUI-only dispatches. Bundled-channel update lanes повторюються один раз у разі тимчасових npm network failures. +OpenWebUI входить до `plugins-runtime-services`, коли повне release-path coverage запитує його, і зберігає окремий chunk `openwebui` лише для dispatches тільки OpenWebUI. Bundled-channel update lanes повторюють запуск один раз у разі тимчасових npm network failures. -Кожен chunk завантажує `.artifacts/docker-tests/` з lane logs, timings, `summary.json`, `failures.json`, phase timings, scheduler plan JSON, slow-lane tables і per-lane rerun commands. Input робочого процесу `docker_lanes` запускає вибрані lanes проти підготовлених образів замість chunk jobs, що обмежує налагодження failed-lane одним цільовим Docker job і готує, завантажує або повторно використовує package artifact для цього запуску; якщо вибрана lane є live Docker lane, цільове завдання локально збирає live-test image для цього rerun. Згенеровані per-lane GitHub rerun commands включають `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, щоб невдала lane могла повторно використати точний package і images з невдалого запуску. +Кожен chunk завантажує `.artifacts/docker-tests/` із lane logs, timings, `summary.json`, `failures.json`, phase timings, scheduler plan JSON, slow-lane tables і per-lane rerun commands. Input workflow `docker_lanes` запускає вибрані lanes проти підготовлених images замість chunk jobs, що обмежує налагодження failed-lane одним targeted Docker job і готує, завантажує або повторно використовує package artifact для цього запуску; якщо вибрана lane є live Docker lane, targeted job локально збирає live-test image для цього повторного запуску. Згенеровані per-lane GitHub rerun commands містять `package_artifact_run_id`, `package_artifact_name` і prepared image inputs, коли ці значення існують, щоб failed lane могла повторно використати точні package та images з невдалого запуску. ```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 робочий процес щодня запускає повний release-path Docker suite. +Запланований live/E2E workflow щодня запускає повний release-path Docker suite. -## Передреліз Plugin +## Попередній випуск Plugin -`Plugin Prerelease` — дорожче product/package coverage, тому це окремий робочий процес, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, пуші в `main` і окремі ручні CI dispatches тримають цей suite вимкненим. Він балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на group і більшим Node heap, щоб import-heavy plugin batches не створювали додаткові CI jobs. Release-only Docker prerelease path групує цільові Docker lanes у невеликі групи, щоб не резервувати десятки runners для одно-трихвилинних jobs. +`Plugin Prerelease` є дорожчим product/package coverage, тому це окремий workflow, який запускається через `Full Release Validation` або явно оператором. Звичайні pull requests, пуші в `main` і автономні ручні CI dispatches тримають цей suite вимкненим. Він балансує тести вбудованих Plugin між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на group і більшим Node heap, щоб import-heavy plugin batches не створювали додаткових CI jobs. Release-only Docker prerelease path групує targeted Docker lanes у невеликі groups, щоб не резервувати десятки runners для jobs тривалістю від однієї до трьох хвилин. ## QA Lab -QA Lab має dedicated CI lanes поза основним smart-scoped workflow. +QA Lab має виділені CI lanes поза основним smart-scoped workflow. -- Робочий процес `Parity gate` запускається за відповідних PR-змін і ручного dispatch; він збирає приватний QA runtime і порівнює mock GPT-5.5 та Opus 4.6 agentic packs. -- Робочий процес `QA-Lab - All Lanes` запускається щоночі на `main` і вручну; він розгортає mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases. +- Workflow `Parity gate` запускається на відповідних змінах PR і ручному dispatch; він збирає private QA runtime і порівнює mock GPT-5.5 та Opus 4.6 agentic packs. +- Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і під час ручного dispatch; він розгалужує mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують environment `qa-live-shared`, а Telegram/Discord використовують Convex leases. -Release checks запускають Matrix і Telegram live transport lanes з deterministic mock provider і mock-qualified models (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб channel contract був ізольований від live model latency і звичайного provider-plugin startup. Live transport gateway вимикає memory search, бо QA parity окремо покриває memory behavior; provider connectivity покривається окремими live model, native provider і Docker provider suites. +Release checks запускають Matrix і Telegram live transport lanes із deterministic mock provider і mock-qualified models (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб channel contract був ізольований від live model latency і звичайного provider-plugin startup. Live transport gateway вимикає memory search, тому що QA parity окремо покриває memory behavior; provider connectivity покривається окремими live model, native provider і Docker provider suites. -Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише коли checked-out CLI підтримує це. CLI default і manual workflow input залишаються `all`; ручний dispatch `matrix_profile=all` завжди шардить повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. +Matrix використовує `--profile fast` для scheduled і release gates, додаючи `--fail-fast` лише тоді, коли checked-out CLI підтримує це. CLI default і manual workflow input залишаються `all`; ручний dispatch `matrix_profile=all` завжди розбиває повне Matrix coverage на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. -`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у невелике report job для фінального parity comparison. +`OpenClaw Release Checks` також запускає release-critical QA Lab lanes перед release approval; його QA parity gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва artifacts у невеликий report job для фінального parity comparison. -Не ставте PR landing path за `Parity gate`, якщо зміна фактично не зачіпає QA runtime, model-pack parity або поверхню, якою володіє parity workflow. Для звичайних channel, config, docs або unit-test fixes вважайте це optional signal і спирайтеся на scoped CI/check evidence. +Не ставте PR landing path за `Parity gate`, якщо зміна фактично не торкається QA runtime, model-pack parity або поверхні, якою володіє parity workflow. Для звичайних виправлень channel, config, docs або unit-test сприймайте це як optional signal і дотримуйтеся scoped CI/check evidence. ## CodeQL -Робочий процес `CodeQL` навмисно є вузьким first-pass security scanner, а не повним repository sweep. Daily, manual і non-draft pull request guard runs сканують Actions workflow code плюс найризикованіші JavaScript/TypeScript surfaces з high-confidence security queries, відфільтрованими до high/critical `security-severity`. +Workflow `CodeQL` навмисно є вузьким first-pass security scanner, а не повним repository sweep. Daily, manual і non-draft pull request guard runs сканують Actions workflow code плюс JavaScript/TypeScript surfaces із найвищим ризиком, використовуючи high-confidence security queries, відфільтровані до high/critical `security-severity`. -Pull request guard залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security matrix, що й scheduled workflow. Android і macOS CodeQL залишаються поза PR defaults. +Pull request guard залишається легким: він стартує лише для змін у `.github/actions`, `.github/codeql`, `.github/workflows`, `packages` або `src`, і запускає ту саму high-confidence security matrix, що й scheduled workflow. Android і macOS CodeQL не входять у PR defaults. ### Категорії безпеки | Категорія | Поверхня | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-security-high/core-auth-secrets` | Auth, secrets, sandbox, Cron і базова лінія Gateway | -| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації основного каналу, а також середовище виконання Plugin каналу, Gateway, Plugin SDK, secrets, точки аудиту | -| `/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 | +| `/codeql-security-high/core-auth-secrets` | Базова перевірка автентифікації, секретів, пісочниці, cron і gateway | +| `/codeql-security-high/channel-runtime-boundary` | Контракти реалізації основного каналу, а також runtime Plugin каналу, gateway, Plugin SDK, секрети й точки дотику аудиту | +| `/codeql-security-high/network-ssrf-boundary` | Поверхні політики SSRF для ядра SSRF, розбору IP, мережевого захисту, web-fetch і Plugin SDK | +| `/codeql-security-high/mcp-process-tool-boundary` | MCP-сервери, допоміжні засоби виконання процесів, вихідна доставка та шлюзи виконання інструментів агента | +| `/codeql-security-high/plugin-trust-boundary` | Поверхні довіри для встановлення Plugin, завантажувача, маніфесту, реєстру, встановлення менеджером пакетів, завантаження джерел і контракту пакета Plugin SDK | -### Платформо-специфічні безпекові шарди +### Безпекові шарди, специфічні для платформ -- `CodeQL Android Critical Security` — запланований безпековий шард Android. Збирає застосунок Android вручну для CodeQL на найменшому Blacksmith Linux runner, який приймає перевірка коректності workflow. Завантажує в `/codeql-critical-security/android`. -- `CodeQL macOS Critical Security` — щотижневий/ручний безпековий шард macOS. Збирає застосунок macOS вручну для CodeQL на Blacksmith macOS, відфільтровує результати збірки залежностей із завантаженого SARIF і завантажує в `/codeql-critical-security/macos`. Тримається поза щоденними стандартними перевірками, бо збірка macOS домінує за часом виконання навіть коли все чисто. +- `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 домінує в часі виконання навіть коли чиста. ### Категорії Critical Quality -`CodeQL Critical Quality` — відповідний небезпековий шард. Він запускає лише JavaScript/TypeScript-запити якості з рівнем серйозності error і безпекою не пов'язані, на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його guard для pull request навмисно менший за запланований профіль: для PR не в статусі draft запускаються лише відповідні шарди `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` для коду виконання команд/моделей/інструментів агента й dispatch відповіді, коду схеми/міграції/IO конфігурації, коду auth/secrets/sandbox/security, основного каналу та середовища виконання вбудованого Plugin каналу, протоколу Gateway/методу сервера, memory runtime/SDK glue, MCP/process/вихідної доставки, provider runtime/каталогу моделей, діагностики сесій/черг доставки, завантажувача Plugin, Plugin SDK/контракту пакета або змін у середовищі виконання відповідей Plugin SDK. Зміни конфігурації CodeQL і workflow якості запускають усі дванадцять quality-шардів PR. +`CodeQL Critical Quality` — відповідний небезпековий шард. Він запускає лише JavaScript/TypeScript-запити якості з рівнем серйозності error і без безпекового фокуса на вузьких поверхнях високої цінності на меншому Blacksmith Linux runner. Його захист pull request навмисно менший за запланований профіль: нечернеткові 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 конфігурації, коді автентифікації/секретів/пісочниці/безпеки, основному каналі й runtime bundled channel Plugin, протоколі Gateway/server-method, memory runtime/SDK glue, MCP/процесах/вихідній доставці, runtime провайдера/каталозі моделей, діагностиці сеансів/чергах доставки, завантажувачі Plugin, контракті Plugin SDK/пакета або runtime відповідей Plugin SDK. Зміни конфігурації CodeQL і workflow якості запускають усі дванадцять PR-шардів якості. Ручний запуск приймає: @@ -425,40 +434,40 @@ Pull request guard залишається легким: він стартує л 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 ``` -Вузькі профілі — це hooks для навчання/ітерацій, щоб запускати один quality-шард ізольовано. +Вузькі профілі — це навчальні/ітераційні hooks для запуску одного шарда якості ізольовано. -| Категорія | Поверхня | +| Категорія | Поверхня | | ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `/codeql-critical-quality/core-auth-secrets` | 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` | Виконання команд, dispatch моделі/провайдера, dispatch і черги auto-reply, а також runtime-контракти control-plane ACP | -| `/codeql-critical-quality/mcp-process-runtime-boundary` | Сервери MCP та мости інструментів, помічники нагляду за процесами й контракти вихідної доставки | -| `/codeql-critical-quality/memory-runtime-boundary` | Memory host SDK, фасади memory runtime, псевдоніми memory Plugin SDK, glue активації memory runtime і команди memory doctor | -| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішня логіка черги відповідей, черги доставки сесій, помічники прив'язування/доставки вихідних сесій, поверхні діагностичних подій/пакетів логів і контракти CLI session doctor | -| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Dispatch вхідних відповідей Plugin SDK, payload/chunking/runtime-помічники відповідей, параметри відповідей каналів, черги доставки та помічники прив'язування сесій/тредів | -| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, auth і виявлення провайдера, реєстрація provider runtime, defaults/каталоги провайдера та реєстри web/search/fetch/embedding | -| `/codeql-critical-quality/ui-control-plane` | Bootstrap Control UI, локальна персистентність, control flows Gateway і runtime-контракти task control-plane | -| `/codeql-critical-quality/web-media-runtime-boundary` | Основні runtime-контракти web fetch/search, media IO, розуміння медіа, генерації зображень і генерації медіа | -| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, публічної поверхні та entrypoint Plugin SDK | -| `/codeql-critical-quality/plugin-sdk-package-contract` | Опубліковані джерела Plugin SDK на боці пакета та помічники контракту пакета Plugin | +| `/codeql-critical-quality/core-auth-secrets` | Код межі безпеки автентифікації, секретів, пісочниці, cron і Gateway | +| `/codeql-critical-quality/config-boundary` | Схема конфігурації, міграція, нормалізація та IO-контракти | +| `/codeql-critical-quality/gateway-runtime-boundary` | Схеми протоколу Gateway і контракти серверних методів | +| `/codeql-critical-quality/channel-runtime-boundary` | Контракти реалізації основного каналу та bundled channel Plugin | +| `/codeql-critical-quality/agent-runtime-boundary` | Виконання команд, диспетчеризація моделей/провайдерів, диспетчеризація й черги автовідповідей, а також runtime-контракти ACP control-plane | +| `/codeql-critical-quality/mcp-process-runtime-boundary` | MCP-сервери й мости інструментів, допоміжні засоби нагляду за процесами та контракти вихідної доставки | +| `/codeql-critical-quality/memory-runtime-boundary` | Memory host SDK, фасади memory runtime, псевдоніми memory Plugin SDK, зв’язка активації memory runtime і команди memory doctor | +| `/codeql-critical-quality/session-diagnostics-boundary` | Внутрішні механізми черги відповідей, черги доставки сеансів, допоміжні засоби прив’язування/доставки вихідних сеансів, поверхні діагностичних подій/пакетів журналів і CLI-контракти session doctor | +| `/codeql-critical-quality/plugin-sdk-reply-runtime` | Диспетчеризація вхідних відповідей Plugin SDK, допоміжні засоби payload/chunking/runtime відповідей, параметри відповідей каналу, черги доставки й допоміжні засоби прив’язування сеансів/потоків | +| `/codeql-critical-quality/provider-runtime-boundary` | Нормалізація каталогу моделей, автентифікація й виявлення провайдерів, реєстрація runtime провайдера, типові значення/каталоги провайдерів і реєстри web/search/fetch/embedding | +| `/codeql-critical-quality/ui-control-plane` | Bootstrap Control UI, локальна сталість, потоки керування Gateway і runtime-контракти task control-plane | +| `/codeql-critical-quality/web-media-runtime-boundary` | Runtime-контракти основного web fetch/search, media IO, media understanding, генерації зображень і генерації медіа | +| `/codeql-critical-quality/plugin-boundary` | Контракти завантажувача, реєстру, публічної поверхні та entrypoint Plugin SDK | +| `/codeql-critical-quality/plugin-sdk-package-contract` | Опубліковане package-side джерело Plugin SDK і допоміжні засоби контракту пакета Plugin | -Quality тримається окремо від security, щоб findings якості можна було планувати, вимірювати, вимикати або розширювати без затемнення безпекового сигналу. Розширення CodeQL для Swift, Python і вбудованих Plugin слід додавати назад як scoped або sharded follow-up work лише після того, як вузькі профілі матимуть стабільний runtime і сигнал. +Якість залишається окремою від безпеки, щоб знахідки якості можна було планувати, вимірювати, вимикати або розширювати без затемнення безпекового сигналу. Розширення CodeQL для Swift, Python і bundled Plugin слід додавати назад як scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільний runtime і сигнал. -## Workflow супроводу +## Workflow обслуговування ### Docs Agent -Workflow `Docs Agent` — це подієво-керований lane супроводу Codex для підтримання наявної документації узгодженою з нещодавно внесеними змінами. Він не має чистого розкладу: успішний CI-запуск push від не-бота на `main` може його запустити, а ручний dispatch може запустити його напряму. Виклики через workflow-run пропускаються, коли `main` уже зсунувся або коли за останню годину вже було створено інший непропущений запуск Docs Agent. Коли він запускається, він переглядає діапазон комітів від попереднього SHA джерела непропущеного Docs Agent до поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені з останнього проходу документації. +Workflow `Docs Agent` — це подієво-керована lane обслуговування Codex для підтримання наявної документації узгодженою з нещодавно landed changes. Він не має чистого розкладу: успішний CI-запуск push від небота на `main` може його запустити, а manual dispatch може запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже посунувся далі або коли інший непропущений запуск Docs Agent був створений за останню годину. Коли він запускається, він переглядає діапазон комітів від попереднього непропущеного source SHA Docs Agent до поточного `main`, тож один погодинний запуск може охопити всі зміни main, накопичені від останнього проходу документації. ### Test Performance Agent -Workflow `Test Performance Agent` — це подієво-керований lane супроводу Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск push від не-бота на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже запускався або виконується цього UTC-дня. Ручний dispatch обходить цей денний activity gate. Lane збирає згрупований звіт продуктивності Vitest для повного набору, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких refactors, потім повторно запускає звіт повного набору й відхиляє зміни, що зменшують базову кількість прохідних тестів. Якщо в базовій лінії є failing tests, Codex може виправляти лише очевидні failures, а after-agent full-suite report має пройти перед тим, як щось буде закомічено. Коли `main` просувається до того, як bot push потрапить у репозиторій, lane rebase-ить перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб action Codex могла зберегти ту саму drop-sudo safety posture, що й docs agent. +Workflow `Test Performance Agent` — це подієво-керована lane обслуговування Codex для повільних тестів. Він не має чистого розкладу: успішний CI-запуск push від небота на `main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже запускався або виконується того UTC-дня. Manual dispatch обходить цей щоденний gate активності. Lane створює згрупований звіт продуктивності Vitest для всього suite, дозволяє Codex робити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких рефакторингів, потім повторно запускає звіт для всього suite і відхиляє зміни, які зменшують базову кількість прохідних тестів. Якщо baseline має failing tests, Codex може виправляти лише очевидні збої, а after-agent звіт для всього suite має пройти перед будь-яким комітом. Коли `main` просувається до того, як bot push буде landed, lane rebase-ить перевірений patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні застарілі patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб Codex action міг зберігати таку саму drop-sudo safety posture, як docs agent. ### Duplicate PRs After Merge -Workflow `Duplicate PRs After Merge` — це ручний workflow maintainer для cleanup дублікатів після landing. За замовчуванням він працює в dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед мутацією GitHub він перевіряє, що landed PR змарджений і що кожен duplicate має або спільну referenced issue, або overlapping changed hunks. +Workflow `Duplicate PRs After Merge` — це ручний workflow maintainer для очищення дублікатів після land. Типово він працює як dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед мутацією GitHub він перевіряє, що landed PR merged і що кожен duplicate має або спільне referenced issue, або перекривні changed hunks. ```bash gh workflow run duplicate-after-merge.yml \ @@ -469,27 +478,27 @@ gh workflow run duplicate-after-merge.yml \ ## Локальні check gates і changed routing -Локальна логіка changed-lane живе в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий platform scope CI: +Логіка локальних changed-lane міститься в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий scope CI-платформи: -- зміни core production запускають typecheck core prod і core test плюс core lint/guards; -- зміни лише core tests запускають тільки typecheck core test плюс core lint; -- зміни extension production запускають typecheck extension prod і extension test плюс extension lint; -- зміни лише extension tests запускають typecheck extension test плюс extension lint; -- зміни публічного Plugin SDK або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core contracts (Vitest extension sweeps залишаються явною тестовою роботою); +- зміни core production запускають core prod і core test typecheck плюс core lint/guards; +- зміни лише core test запускають лише core test typecheck плюс core lint; +- зміни extension production запускають extension prod і extension test typecheck плюс extension lint; +- зміни лише extension test запускають extension test typecheck плюс extension lint; +- зміни публічного Plugin SDK або plugin-contract розширюються до extension typecheck, бо extensions залежать від цих core contracts (Vitest extension sweeps залишаються явною тестовою роботою); - version bumps лише release metadata запускають цільові перевірки version/config/root-dependency; - невідомі зміни root/config fail safe до всіх check lanes. -Локальний changed-test routing живе в `scripts/test-projects.test-support.mjs` і навмисно дешевший за `check:changed`: прямі зміни тестів запускають самі себе, зміни джерел віддають перевагу явним mappings, потім sibling tests і import-graph dependents. Конфігурація shared group-room delivery — один з явних mappings: зміни до group visible-reply config, source reply delivery mode або message-tool system prompt маршрутизуються через core reply tests плюс delivery regressions Discord і Slack, щоб shared default change зламався до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна настільки harness-wide, що дешевий 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 проходять через основні reply tests плюс Discord і Slack delivery regressions, щоб спільна зміна типового значення падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише коли зміна достатньо harness-wide, що дешевий mapped set не є надійним proxy. ## Валідація Testbox -Запускайте Testbox з кореня репозиторію і віддавайте перевагу свіжому warmed box для broad proof. Перед витрачанням повільного gate на box, який був reused, expired або щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` всередині box. +Запускайте Testbox із кореня repo й надавайте перевагу свіжій прогрітій box для широкого доказу. Перш ніж витрачати повільний gate на box, яку було повторно використано, термін дії якої минув або яка щойно повідомила про несподівано великий sync, спочатку запустіть `pnpm testbox:sanity` усередині box. -Sanity check швидко падає, коли потрібні root files, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що remote sync state не є trustworthy copy PR; зупиніть цей box і warmed fresh one замість debugging product test failure. Для навмисних PR із large-deletion встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run. +Sanity check швидко падає, коли обов’язкові кореневі файли, як-от `pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 tracked deletions. Зазвичай це означає, що стан remote sync не є надійною копією PR; зупиніть цю box і прогрійте свіжу замість того, щоб налагоджувати product test failure. Для навмисних PR із великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run. -`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 — це другий, належний репозиторію шлях віддаленого бокса для підтвердження в Linux, коли Blacksmith недоступний або коли бажано використовувати власну хмарну місткість. Прогрійте бокс, гідруйте його через workflow проєкту, а потім виконуйте команди через Crabbox CLI: +Crabbox — це другий шлях віддаленого box-середовища, що належить репозиторію, для перевірки в Linux, коли Blacksmith недоступний або коли бажано використати власні хмарні ресурси. Прогрійте box, гідруйте його через проєктний workflow, а потім виконуйте команди через Crabbox CLI: ```bash pnpm crabbox:warmup -- --idle-timeout 90m @@ -498,9 +507,9 @@ pnpm crabbox:run -- --id --shell "OPENCLAW_TESTBOX=1 pnpm check:changed pnpm crabbox:stop -- ``` -`.crabbox.yaml` визначає типові параметри провайдера, синхронізації та гідрації GitHub Actions. Він виключає локальний `.git`, щоб гідрований checkout Actions зберігав власні віддалені метадані Git замість синхронізації локальних для мейнтейнера remotes і сховищ об’єктів, а також виключає локальні артефакти виконання/збирання, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` визначає checkout, налаштування Node/pnpm, отримання `origin/main` і передавання несекретного середовища, яке пізніші команди `crabbox run --id ` використовують як джерело. +`.crabbox.yaml` визначає стандартні значення для провайдера, синхронізації та гідрації GitHub Actions. Він виключає локальний `.git`, щоб гідрований checkout Actions зберігав власні віддалені метадані Git замість синхронізації локальних для мейнтейнера віддалених репозиторіїв і сховищ об’єктів, а також виключає локальні артефакти runtime/build, які ніколи не слід передавати. `.github/workflows/crabbox-hydrate.yml` визначає checkout, налаштування Node/pnpm, отримання `origin/main` і передавання несекретного середовища, яке пізніші команди `crabbox run --id ` використовують як джерело. ## Пов’язане -- [Огляд інсталяції](/uk/install) +- [Огляд встановлення](/uk/install) - [Канали розробки](/uk/install/development-channels) diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md index 454c1556f..4931388ab 100644 --- a/docs/uk/help/testing.md +++ b/docs/uk/help/testing.md @@ -1,215 +1,217 @@ --- read_when: - Запуск тестів локально або в CI - - Додавання регресійних тестів для помилок моделей/провайдерів + - Додавання регресійних тестів для помилок моделі/провайдера - Налагодження поведінки Gateway + агента -summary: 'Набір для тестування: набори тестів unit/e2e/live, ранери Docker і що охоплює кожен тест' +summary: 'Набір для тестування: модульні/e2e/live-набори, Docker-ранери та що охоплює кожен тест' title: Тестування x-i18n: - generated_at: "2026-05-02T15:57:51Z" + generated_at: "2026-05-02T16:50:30Z" model: gpt-5.5 provider: openai - source_hash: 217ee866c7e5043c20c09c677e8717e3c8fb836d9016ae3391ecf9058393b2d9 + source_hash: 99e7db2ab0069aaa129bed303419b76bb9276f3f53a4ac6bb292120c3a327b7b source_path: help/testing.md workflow: 16 --- -OpenClaw має три набори тестів Vitest (модульні/інтеграційні, e2e, live) і невеликий набір -Docker-запускачів. Цей документ є посібником «як ми тестуємо»: +OpenClaw має три набори тестів Vitest (unit/integration, e2e, live) і невеликий набір +Docker runner. Цей документ є посібником «як ми тестуємо»: -- Що охоплює кожен набір (і що він навмисно _не_ охоплює). +- Що покриває кожен набір (і що він свідомо _не_ покриває). - Які команди запускати для типових робочих процесів (локально, перед push, для налагодження). - Як live-тести знаходять облікові дані та вибирають моделі/провайдерів. -- Як додавати регресії для реальних проблем моделей/провайдерів. +- Як додавати регресійні тести для реальних проблем із моделями/провайдерами. **QA-стек (qa-lab, qa-channel, live transport lanes)** задокументовано окремо: - [Огляд QA](/uk/concepts/qa-e2e-automation) — архітектура, поверхня команд, створення сценаріїв. -- [Matrix QA](/uk/concepts/qa-matrix) — довідник для `pnpm openclaw qa matrix`. -- [QA channel](/uk/channels/qa-channel) — синтетичний транспортний плагін, який використовується сценаріями, підтриманими репозиторієм. +- [Matrix QA](/uk/concepts/qa-matrix) — довідка для `pnpm openclaw qa matrix`. +- [QA channel](/uk/channels/qa-channel) — синтетичний transport plugin, який використовується сценаріями, підтриманими репозиторієм. -Ця сторінка описує запуск звичайних наборів тестів і Docker/Parallels-запускачів. Розділ про QA-специфічні запускачі нижче ([QA-специфічні запускачі](#qa-specific-runners)) перелічує конкретні виклики `qa` і посилається назад на наведені вище довідники. +Ця сторінка описує запуск звичайних наборів тестів і Docker/Parallels runner. Розділ про спеціальні QA runner нижче ([QA-specific runners](#qa-specific-runners)) перелічує конкретні виклики `qa` і повертає до наведених вище довідкових матеріалів. ## Швидкий старт -У більшості випадків: +У більшість днів: - Повний gate (очікується перед push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` - Швидший локальний запуск повного набору на машині з достатніми ресурсами: `pnpm test:max` -- Прямий цикл спостереження Vitest: `pnpm test:watch` -- Пряме націлювання на файл тепер також маршрутизує шляхи розширень/каналів: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Спершу віддавайте перевагу цільовим запускам, коли ітеруєте над одним збоєм. -- Docker-backed QA-сайт: `pnpm qa:lab:up` -- Linux VM-backed QA lane: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- Прямий watch-цикл Vitest: `pnpm test:watch` +- Пряме таргетування файлів тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Спершу віддавайте перевагу таргетованим запускам, коли ітеруєте над одним збоєм. +- QA-сайт на базі Docker: `pnpm qa:lab:up` +- QA lane на базі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` Коли ви змінюєте тести або хочете додаткової впевненості: -- Gate покриття: `pnpm test:coverage` +- Coverage gate: `pnpm test:coverage` - Набір E2E: `pnpm test:e2e` Під час налагодження реальних провайдерів/моделей (потрібні реальні облікові дані): -- Live-набір (моделі + gateway tool/image probes): `pnpm test:live` -- Тихо націлитися на один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -- Звіти про продуктивність виконання: запустіть `OpenClaw Performance` з +- Live-набір (моделі + Gateway tool/image probes): `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. Щоденні заплановані запуски + `deep_profile=true` для CPU/heap/trace артефактів Kova. Щоденні заплановані запуски публікують артефакти mock-provider, deep-profile і GPT 5.4 lane до `openclaw/clawgrit-reports`, коли налаштовано `CLAWGRIT_REPORTS_TOKEN`. + Звіт mock-provider також містить source-level показники запуску Gateway, пам’яті, + plugin-pressure, повторюваного fake-model hello-loop і старту CLI. - Docker live model sweep: `pnpm test:docker:live-models` - - Кожна вибрана модель тепер виконує текстовий хід і невеликий probe у стилі читання файлу. + - Кожна вибрана модель тепер виконує текстовий хід плюс невелику file-read-style probe. Моделі, чиї метадані оголошують вхід `image`, також виконують крихітний image-хід. - Вимкніть додаткові probes за допомогою `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або + Вимкніть додаткові probe за допомогою `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 jobs, розділені за провайдером. - - Для сфокусованих повторних запусків CI запустіть `OpenClaw Live And E2E Checks (Reusable)` + matrix jobs, розбиті за провайдерами. + - Для сфокусованих CI rerun виконайте dispatch `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 caller. - Native Codex bound-chat smoke: `pnpm test:docker:live-codex-bind` - Запускає Docker live lane проти шляху Codex app-server, прив’язує синтетичний Slack DM через `/codex bind`, виконує `/codex fast` і `/codex permissions`, а потім перевіряє, що звичайна відповідь і вкладення зображення - маршрутизуються через native plugin binding замість ACP. + проходять через native plugin binding замість ACP. - Codex app-server harness smoke: `pnpm test:docker:live-codex-harness` - - Запускає ходи gateway agent через harness Codex app-server, яким володіє плагін, - перевіряє `/codex status` і `/codex models`, і за замовчуванням виконує image, - cron MCP, sub-agent і Guardian probes. Вимкніть sub-agent probe за допомогою + - Запускає ходи агента Gateway через plugin-owned Codex app-server harness, + перевіряє `/codex status` і `/codex models` та за замовчуванням виконує image, + cron MCP, sub-agent і Guardian probe. Вимкніть sub-agent probe за допомогою `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0`, коли ізолюєте інші збої Codex - app-server. Для сфокусованої перевірки sub-agent вимкніть інші probes: + app-server. Для сфокусованої перевірки sub-agent вимкніть інші probe: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness`. Це завершується після sub-agent probe, якщо не встановлено `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0`. - Crestodian rescue command smoke: `pnpm test:live:crestodian-rescue-channel` - - Додаткова перевірка «ремінь і підтяжки» для поверхні rescue command каналу повідомлень. + - Додаткова belt-and-suspenders перевірка поверхні rescue-команди message-channel. Вона виконує `/crestodian status`, ставить у чергу постійну зміну моделі, відповідає `/crestodian yes` і перевіряє шлях запису audit/config. - Crestodian planner Docker smoke: `pnpm test:docker:crestodian-planner` - - Запускає Crestodian у контейнері без конфігурації з фальшивим Claude CLI у `PATH` - і перевіряє, що нечіткий fallback планувальника транслюється в audited typed + - Запускає Crestodian у контейнері без config з фейковим Claude CLI у `PATH` + і перевіряє, що fuzzy planner fallback транслюється в audited typed config write. - Crestodian first-run Docker smoke: `pnpm test:docker:crestodian-first-run` - - Починає з порожнього каталогу стану OpenClaw, маршрутизує bare `openclaw` до - Crestodian, застосовує setup/model/agent/Discord plugin + SecretRef writes, - перевіряє конфігурацію та audit entries. Той самий шлях Ring 0 setup + - Починає з порожнього OpenClaw state dir, маршрутизує bare `openclaw` до + Crestodian, застосовує setup/model/agent/Discord plugin + SecretRef записи, + валідує config і перевіряє audit entries. Той самий шлях Ring 0 setup також покрито в QA Lab через `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`. - 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`. + transcript асистента зберігає нормалізований `usage.cost`. -Коли потрібен лише один збійний випадок, віддавайте перевагу звуженню live-тестів через allowlist env vars, описані нижче. +Коли вам потрібен лише один failing case, віддавайте перевагу звуженню live-тестів через allowlist env vars, описані нижче. -## QA-специфічні запускачі +## QA-specific runners -Ці команди стоять поруч з основними наборами тестів, коли потрібна реалістичність QA-lab: +Ці команди розташовані поруч з основними наборами тестів, коли потрібен реалізм QA-lab: CI запускає QA Lab у dedicated workflows. `Parity gate` запускається на відповідних PR і -з ручного запуску з mock providers. `QA-Lab - All Lanes` запускається щоночі на -`main` і з ручного запуску з mock parity gate, live Matrix lane, +з manual dispatch з mock providers. `QA-Lab - All Lanes` запускається щоночі на +`main` і з manual dispatch з mock parity gate, live Matrix lane, Convex-managed live Telegram lane і Convex-managed live Discord lane як паралельні jobs. Scheduled QA і release checks явно передають Matrix `--profile fast`, тоді як Matrix CLI і manual workflow input за замовчуванням залишаються -`all`; ручний запуск може розбити `all` на jobs `transport`, `media`, `e2ee-smoke`, -`e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` запускає parity плюс +`all`; manual dispatch може розбивати `all` на `transport`, `media`, `e2ee-smoke`, +`e2ee-deep` і `e2ee-cli` jobs. `OpenClaw Release Checks` запускає parity плюс fast Matrix і Telegram lanes перед release approval, використовуючи `mock-openai/gpt-5.5` для release transport checks, щоб вони залишалися детермінованими -і уникали звичайного запуску provider-plugin. Ці live transport gateways вимикають -memory search; behavior memory залишається покритим наборами QA parity. +та уникали звичайного запуску provider-plugin. Ці live transport gateways вимикають +memory search; поведінка пам’яті залишається покритою QA parity suites. 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:`, зібраний один раз для вибраного -коміту, а потім завантажують його з `OPENCLAW_SKIP_DOCKER_BUILD=1` замість перебудови -всередині кожного shard. +commit, а потім завантажують його з `OPENCLAW_SKIP_DOCKER_BUILD=1` замість повторної збірки +в кожному shard. - `pnpm openclaw qa suite` - - Запускає QA-сценарії з репозиторію безпосередньо на хості. + - Запускає QA-сценарії, підтримані репозиторієм, безпосередньо на хості. - За замовчуванням запускає кілька вибраних сценаріїв паралельно з ізольованими - gateway-працівниками. `qa-channel` за замовчуванням має concurrency 4 (обмежено - кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати - кількість працівників, або `--concurrency 1` для старішої послідовної lane. - - Завершується з ненульовим кодом, коли будь-який сценарій зазнає невдачі. Використовуйте `--allow-failures`, коли + Gateway-працівниками. Для `qa-channel` стандартна паралельність становить 4 (обмежена + кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати кількість + працівників, або `--concurrency 1` для старішої послідовної лінії. + - Завершується з ненульовим кодом, коли будь-який сценарій не проходить. Використовуйте `--allow-failures`, коли вам потрібні артефакти без коду завершення з помилкою. - Підтримує режими провайдера `live-frontier`, `mock-openai` і `aimock`. `aimock` запускає локальний сервер провайдера на базі AIMock для експериментального - покриття фікстур і protocol-mock без заміни scenario-aware - lane `mock-openai`. + покриття фікстур і моків протоколу без заміни сценарно-обізнаної + лінії `mock-openai`. - `pnpm test:gateway:cpu-scenarios` - - Запускає startup bench для Gateway плюс невеликий пакет mock-сценаріїв QA Lab + - Запускає бенч запуску Gateway плюс невеликий пакет мокових сценаріїв QA Lab (`channel-chat-baseline`, `memory-failure-fallback`, - `gateway-restart-inflight-run`) і записує об'єднане резюме CPU-спостережень + `gateway-restart-inflight-run`) і записує об’єднаний підсумок спостережень CPU у `.artifacts/gateway-cpu-scenarios/`. - За замовчуванням позначає лише сталі спостереження гарячого CPU (`--cpu-core-warn` - плюс `--hot-wall-warn-ms`), тому короткі сплески запуску записуються як метрики - без вигляду регресії Gateway peg тривалістю в хвилини. - - Використовує зібрані артефакти `dist`; спершу запустіть build, коли checkout ще не + плюс `--hot-wall-warn-ms`), тому короткі сплески під час запуску записуються як метрики + без вигляду регресії, коли Gateway на кілька хвилин притискає CPU. + - Використовує зібрані артефакти `dist`; спершу запустіть збірку, якщо checkout ще не має свіжого runtime-виводу. - `pnpm openclaw qa suite --runner multipass` - - Запускає той самий QA suite всередині одноразової Linux VM Multipass. - - Зберігає таку саму поведінку вибору сценаріїв, як `qa suite` на хості. + - Запускає той самий QA-набір усередині одноразової Linux VM Multipass. + - Зберігає ту саму поведінку вибору сценаріїв, що й `qa suite` на хості. - Повторно використовує ті самі прапорці вибору провайдера/моделі, що й `qa suite`. - - Live-запуски пересилають підтримувані вхідні дані QA auth, практичні для guest: - env-ключі провайдера, шлях до QA live provider config і `CODEX_HOME`, + - Живі запуски передають підтримувані QA-входи автентифікації, практичні для гостьової системи: + ключі провайдера на основі env, шлях до конфігурації живого QA-провайдера та `CODEX_HOME`, коли він наявний. - - Каталоги виводу мають залишатися під коренем репозиторію, щоб guest міг записувати назад через + - Каталоги виводу мають залишатися в корені репозиторію, щоб гостьова система могла записувати назад через змонтований workspace. - - Записує звичайний QA-звіт + резюме та логи Multipass у + - Записує звичайний QA-звіт і підсумок плюс журнали Multipass у `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Запускає Docker-backed QA-сайт для operator-style QA-роботи. + - Запускає QA-сайт на базі Docker для QA-роботи в операторському стилі. - `pnpm test:docker:npm-onboard-channel-agent` - - Збирає npm tarball із поточного checkout, глобально встановлює його в - Docker, запускає неінтерактивний onboarding API-ключа OpenAI, за замовчуванням налаштовує Telegram, - перевіряє, що packaged plugin runtime завантажується без startup - dependency repair, запускає doctor і виконує один локальний agent turn проти - mock-ендпоінта OpenAI. - - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити ту саму packaged-install - lane з Discord. + - Збирає npm tarball із поточного checkout, встановлює його глобально в + Docker, запускає неінтерактивний onboarding з ключем OpenAI API, за замовчуванням налаштовує Telegram, + перевіряє, що runtime запакованого Plugin завантажується без виправлення залежностей + під час запуску, запускає doctor і виконує один локальний хід агента проти + мокового endpoint OpenAI. + - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити ту саму лінію + запакованого встановлення з Discord. - `pnpm test:docker:session-runtime-context` - - Запускає детермінований built-app Docker smoke для вбудованих runtime context - transcripts. Він перевіряє, що прихований runtime context OpenClaw зберігається як - non-display custom message замість витоку у видимий user turn, - потім додає affected broken session JSONL і перевіряє, що - `openclaw doctor --fix` переписує його на active branch із резервною копією. + - Запускає детермінований Docker-smoke зібраного застосунку для транскриптів вбудованого runtime-контексту. + Він перевіряє, що прихований runtime-контекст OpenClaw зберігається як + невідображуване користувацьке повідомлення, а не просочується у видимий хід користувача, + потім засіває уражений зламаний session JSONL і перевіряє, + що `openclaw doctor --fix` переписує його на активну гілку з резервною копією. - `pnpm test:docker:npm-telegram-live` - - Встановлює candidate пакета OpenClaw у Docker, запускає installed-package - onboarding, налаштовує Telegram через встановлений CLI, потім повторно використовує - live Telegram QA lane з цим установленим пакетом як SUT Gateway. + - Встановлює пакет-кандидат OpenClaw у Docker, запускає onboarding установленого пакета, + налаштовує Telegram через установлений CLI, а потім повторно використовує + живу 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/release automation задайте + `OPENCLAW_CURRENT_PACKAGE_TGZ`, щоб тестувати розв’язаний локальний tarball замість + встановлення з реєстру. + - Використовує ті самі Telegram env-облікові дані або джерело облікових даних Convex, що й + `pnpm openclaw qa telegram`. Для автоматизації CI/релізів задайте `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex` плюс - `OPENCLAW_QA_CONVEX_SITE_URL` і role secret. Якщо - `OPENCLAW_QA_CONVEX_SITE_URL` і Convex role secret наявні в CI, - Docker wrapper автоматично вибирає Convex. + `OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі. Якщо + `OPENCLAW_QA_CONVEX_SITE_URL` і секрет ролі Convex присутні в CI, + Docker-wrapper автоматично вибирає Convex. - `OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` перевизначає спільну - `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цієї lane. - - GitHub Actions надає цю lane як manual maintainer workflow - `NPM Telegram Beta E2E`. Вона не запускається під час merge. Workflow використовує - середовище `qa-live-shared` і Convex CI credential leases. -- GitHub Actions також надає `Package Acceptance` для побічного product proof - проти одного candidate package. Він приймає trusted ref, опубліковану npm spec, - HTTPS tarball URL плюс SHA-256 або tarball artifact з іншого запуску, завантажує - нормалізований `openclaw-current.tgz` як `package-under-test`, потім запускає - наявний Docker E2E scheduler із профілями lane smoke, package, product, full або custom. + `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цієї лінії. + - GitHub Actions надає цю лінію як ручний workflow для maintainers + `NPM Telegram Beta E2E`. Він не запускається під час merge. Workflow використовує + середовище `qa-live-shared` і оренди облікових даних Convex CI. +- GitHub Actions також надає `Package Acceptance` для побічного продуктового proof + проти одного пакета-кандидата. Він приймає довірений ref, опубліковану npm-специфікацію, + HTTPS URL tarball плюс SHA-256 або артефакт tarball з іншого запуску, завантажує + нормалізований `openclaw-current.tgz` як `package-under-test`, а потім запускає + наявний Docker E2E scheduler із профілями ліній smoke, package, product, full або custom. Задайте `telegram_mode=mock-openai` або `live-frontier`, щоб запустити Telegram QA workflow проти того самого артефакту `package-under-test`. - - Product proof для останньої beta: + - Proof для останньої beta-версії продукту: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -219,7 +221,7 @@ gh workflow run package-acceptance.yml --ref main \ -f telegram_mode=mock-openai ``` -- Proof для точного tarball URL потребує digest: +- Proof для точного URL tarball потребує digest: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -229,7 +231,7 @@ gh workflow run package-acceptance.yml --ref main \ -f suite_profile=package ``` -- Artifact proof завантажує tarball artifact з іншого запуску Actions: +- Artifact proof завантажує артефакт tarball з іншого запуску Actions: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -240,106 +242,105 @@ gh workflow run package-acceptance.yml --ref main \ ``` - `pnpm test:docker:plugins` - - Пакує та встановлює поточний build OpenClaw у Docker, запускає Gateway - з налаштованим OpenAI, потім вмикає bundled channel/plugins через config - edits. - - Перевіряє, що setup discovery залишає неналаштовані downloadable plugins відсутніми, - перший configured doctor repair встановлює кожен відсутній downloadable - plugin явно, а другий restart не запускає hidden dependency - repair. - - Також встановлює відомий старіший npm baseline, вмикає Telegram перед запуском - `openclaw update --tag ` і перевіряє, що post-update doctor candidate - очищає legacy plugin dependency debris без - harness-side postinstall repair. + - Пакує та встановлює поточну збірку OpenClaw у Docker, запускає Gateway + з налаштованим OpenAI, а потім вмикає вбудовані канали/плагіни через редагування конфігурації. + - Перевіряє, що discovery налаштування залишає неналаштовані завантажувані плагіни відсутніми, + перше налаштоване doctor-виправлення явно встановлює кожен відсутній завантажуваний + Plugin, а другий restart не запускає приховане + виправлення залежностей. + - Також встановлює відому старішу npm-базу, вмикає Telegram перед запуском + `openclaw update --tag ` і перевіряє, що post-update doctor кандидата + очищає залишки залежностей legacy Plugin без postinstall-виправлення + з боку harness. - `pnpm test:parallels:npm-update` - - Запускає native packaged-install update smoke у гостях Parallels. Кожна - вибрана платформа спочатку встановлює запитаний baseline package, потім запускає - встановлену команду `openclaw update` у тому самому guest і перевіряє - встановлену версію, статус оновлення, готовність gateway і один локальний agent - turn. + - Запускає нативний smoke оновлення запакованого встановлення на гостьових системах Parallels. Кожна + вибрана платформа спочатку встановлює запитаний базовий пакет, потім запускає + встановлену команду `openclaw update` у тій самій гостьовій системі та перевіряє + встановлену версію, статус оновлення, готовність Gateway і один локальний + хід агента. - Використовуйте `--platform macos`, `--platform windows` або `--platform linux` під час - ітерацій на одному guest. Використовуйте `--json` для шляху до summary artifact і - статусу кожної lane. - - OpenAI lane за замовчуванням використовує `openai/gpt-5.5` для live agent-turn proof. + ітерацій на одній гостьовій системі. Використовуйте `--json` для шляху до артефакту підсумку та + статусу кожної лінії. + - Лінія OpenAI за замовчуванням використовує `openai/gpt-5.5` для proof живого ходу агента. Передайте `--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 ``` - - Скрипт записує вкладені логи lane у `/tmp/openclaw-parallels-npm-update.*`. - Перегляньте `windows-update.log`, `macos-update.log` або `linux-update.log` - перед припущенням, що зовнішній wrapper завис. - - Windows update може витратити 10-15 хвилин на post-update doctor і package - update work на cold guest; це все ще справний стан, коли вкладений npm + - Скрипт записує вкладені журнали ліній у `/tmp/openclaw-parallels-npm-update.*`. + Перегляньте `windows-update.log`, `macos-update.log` або `linux-update.log`, + перш ніж вважати, що зовнішній wrapper завис. + - Оновлення Windows може витратити 10–15 хвилин на post-update doctor і роботу з + оновленням пакетів на холодній гостьовій системі; це все ще нормальний стан, коли вкладений npm debug log просувається. - - Не запускайте цей aggregate wrapper паралельно з окремими smoke lanes Parallels - macOS, Windows або Linux. Вони спільно використовують VM state і можуть конфліктувати під час - snapshot restore, package serving або guest gateway state. - - Post-update proof запускає звичайну bundled plugin surface, тому що - capability facades, як-от speech, image generation і media - understanding, завантажуються через bundled runtime APIs навіть тоді, коли сам agent - turn перевіряє лише просту текстову відповідь. + - Не запускайте цей агрегований wrapper паралельно з окремими smoke-лініями Parallels + macOS, Windows або Linux. Вони спільно використовують стан VM і можуть конфліктувати під час + відновлення snapshot, подавання пакетів або стану Gateway у гостьовій системі. + - Post-update proof запускає звичайну поверхню вбудованих Plugin, бо + фасади можливостей, як-от speech, image generation і media + understanding, завантажуються через вбудовані runtime API, навіть коли сам + хід агента перевіряє лише просту текстову відповідь. - `pnpm openclaw qa aimock` - - Запускає лише локальний сервер провайдера AIMock для прямого protocol smoke - testing. + - Запускає лише локальний сервер провайдера AIMock для прямого smoke-тестування + протоколу. - `pnpm openclaw qa matrix` - - Запускає Matrix live QA lane проти одноразового Docker-backed homeserver Tuwunel. Лише source-checkout — packaged installs не постачають `qa-lab`. - - Повний CLI, каталог profile/scenario, env vars і макет артефактів: [Matrix QA](/uk/concepts/qa-matrix). + - Запускає живу QA-лінію Matrix проти одноразового homeserver Tuwunel на базі Docker. Лише source-checkout — запаковані встановлення не постачають `qa-lab`. + - Повний CLI, каталог профілів/сценаріїв, env vars і структура артефактів: [Matrix QA](/uk/concepts/qa-matrix). - `pnpm openclaw qa telegram` - - Запускає Telegram live QA lane проти реальної приватної групи з використанням driver і SUT bot tokens з env. + - Запускає живу 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`, коли + - Підтримує `--credential-source convex` для спільних pooled облікових даних. За замовчуванням використовуйте env-режим або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases. + - Завершується з ненульовим кодом, коли будь-який сценарій не проходить. Використовуйте `--allow-failures`, коли вам потрібні артефакти без коду завершення з помилкою. - - Потребує двох різних bot в одній приватній групі, причому SUT bot має відкривати Telegram username. - - Для стабільного bot-to-bot observation увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох bot і переконайтеся, що driver bot може спостерігати group bot traffic. - - Записує Telegram QA report, summary і observed-messages artifact у `.artifacts/qa-e2e/...`. Сценарії відповіді включають RTT від driver send request до observed SUT reply. + - Потребує двох окремих ботів в одній приватній групі, причому SUT bot має надавати Telegram username. + - Для стабільного bot-to-bot спостереження увімкніть Bot-to-Bot Communication Mode в `@BotFather` для обох ботів і переконайтеся, що driver bot може спостерігати груповий bot traffic. + - Записує Telegram QA-звіт, підсумок і артефакт observed-messages у `.artifacts/qa-e2e/...`. Сценарії з відповідями включають RTT від запиту надсилання driver до спостереженої відповіді SUT. -Live transport lanes мають один стандартний contract, щоб нові transports не розходилися; per-lane coverage matrix розміщено в [QA overview → Live transport coverage](/uk/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` — це широкий synthetic suite і не є частиною цієї матриці. +Живі транспортні лінії мають один стандартний контракт, щоб нові транспорти не розходилися; матриця покриття для кожної лінії міститься в [QA overview → Live transport coverage](/uk/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` — це широкий синтетичний набір і не є частиною цієї матриці. -### Спільні Telegram credentials через Convex (v1) +### Спільні Telegram-облікові дані через Convex (v1) Коли `--credential-source convex` (або `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) увімкнено для -`openclaw qa telegram`, QA lab отримує exclusive lease з Convex-backed pool, виконує heartbeats -цього lease, поки lane працює, і звільняє lease під час shutdown. +`openclaw qa telegram`, QA lab отримує ексклюзивну оренду з pool на базі Convex, надсилає heartbeats +для цієї оренди, поки лінія працює, і звільняє оренду під час shutdown. Еталонний scaffold проєкту Convex: - `qa/convex-credential-broker/` -Обов'язкові env vars: +Обов’язкові env vars: -- `OPENCLAW_QA_CONVEX_SITE_URL` (наприклад, `https://your-deployment.convex.site`) -- Один secret для вибраної role: +- `OPENCLAW_QA_CONVEX_SITE_URL` (наприклад `https://your-deployment.convex.site`) +- Один секрет для вибраної ролі: - `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` для `maintainer` - `OPENCLAW_QA_CONVEX_SECRET_CI` для `ci` -- Вибір credential role: +- Вибір ролі облікових даних: - CLI: `--credential-role maintainer|ci` - Env default: `OPENCLAW_QA_CREDENTIAL_ROLE` (за замовчуванням `ci` у CI, інакше `maintainer`) -Необов'язкові env vars: +Необов’язкові env vars: - `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (за замовчуванням `1200000`) - `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (за замовчуванням `30000`) - `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (за замовчуванням `90000`) - `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (за замовчуванням `15000`) - `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (за замовчуванням `/qa-credentials/v1`) -- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (необов'язковий trace id) -- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` URL-адреси Convex лише для локальної розробки. +- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (необов’язковий trace id) +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` URL Convex для локальної розробки. -`OPENCLAW_QA_CONVEX_SITE_URL` має використовувати `https://` у звичайній роботі. +`OPENCLAW_QA_CONVEX_SITE_URL` у звичайній роботі має використовувати `https://`. -Admin commands для maintainer (pool add/remove/list) потребують саме +Адмін-команди maintainer (pool add/remove/list) потребують саме `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -CLI helpers для maintainers: +CLI-помічники для maintainers: ```bash pnpm openclaw qa credentials doctor @@ -348,12 +349,12 @@ pnpm openclaw qa credentials list --kind telegram pnpm openclaw qa credentials remove --credential-id ``` -Використовуйте `doctor` перед live-запусками, щоб перевірити Convex site URL, broker secrets, -endpoint prefix, HTTP timeout і admin/list reachability без друку -secret values. Використовуйте `--json` для machine-readable output у scripts і CI -utilities. +Використовуйте `doctor` перед живими запусками, щоб перевірити URL сайту Convex, broker secrets, +endpoint prefix, HTTP timeout і доступність admin/list без друку +значень секретів. Використовуйте `--json` для machine-readable виводу в скриптах і CI +утилітах. -Стандартний контракт кінцевої точки (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): +Контракт стандартної кінцевої точки (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): - `POST /acquire` - Запит: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` @@ -376,166 +377,167 @@ utilities. - Запит: `{ kind?, status?, includePayload?, limit? }` - Успіх: `{ status: "ok", credentials, count }` -Форма корисного навантаження для типу Telegram: +Форма payload для типу Telegram: - `{ groupId: string, driverToken: string, sutToken: string }` - `groupId` має бути числовим рядком ідентифікатора чату Telegram. -- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє неправильно сформовані корисні навантаження. +- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє неправильно сформовані payload. ### Додавання каналу до QA -Архітектура й назви допоміжних сценарних компонентів для нових адаптерів каналів описані в [огляді QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна вимога: реалізувати транспортний runner на спільному шві хоста `qa-lab`, оголосити `qaRunners` у маніфесті plugin, змонтувати як `openclaw qa ` і написати сценарії в `qa/scenarios/`. +Архітектура й назви допоміжних сценарних модулів для нових адаптерів каналів описані в [огляді QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна вимога: реалізувати транспортний runner на спільному seam хоста `qa-lab`, оголосити `qaRunners` у маніфесті plugin, змонтувати як `openclaw qa ` і створити сценарії в `qa/scenarios/`. ## Набори тестів (що де запускається) -Сприймайте набори як «зростання реалістичності» (і зростання нестабільності/вартості): +Думайте про ці набори як про «зростання реалістичності» (і зростання нестабільності/вартості): -### Модульні / інтеграційні (за замовчуванням) +### Модульні / інтеграційні (стандартно) - Команда: `pnpm test` -- Конфігурація: нецільові запуски використовують набір шардiв `vitest.full-*.config.ts` і можуть розгортати багатопроєктні шарди в конфігурації окремих проєктів для паралельного планування -- Файли: інвентарі core/модульних тестів у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; модульні тести UI запускаються у виділеному шарді `unit-ui` -- Обсяг: +- Конфігурація: нецільові запуски використовують набір шардів `vitest.full-*.config.ts` і можуть розгортати багатопроєктні шарди в конфіги окремих проєктів для паралельного планування +- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; модульні тести UI запускаються у спеціальному шарді `unit-ui` +- Область: - Чисті модульні тести - - Внутрішньопроцесні інтеграційні тести (автентифікація Gateway, маршрутизація, інструменти, розбір, конфігурація) + - Внутрішньопроцесні інтеграційні тести (автентифікація gateway, маршрутизація, tooling, parsing, config) - Детерміновані регресії для відомих помилок - Очікування: - Запускається в CI - Реальні ключі не потрібні - Має бути швидким і стабільним - - Тести розпізнавача й завантажувача публічної поверхні мають доводити широку fallback-поведінку `api.js` і - `runtime-api.js` за допомогою згенерованих мінімальних фікстур plugin, а не - реальних API вихідного коду вбудованого plugin. Реальні завантаження API plugin належать до - контрактних/інтеграційних наборів, якими володіє plugin. + - Тести resolver і public-surface loader мають доводити fallback-поведінку широких `api.js` і + `runtime-api.js` за допомогою згенерованих малих фікстур plugin, а не + реальних API вихідного коду bundled plugin. Завантаження API реальних plugin належать до + contract/integration наборів, якими володіють plugin. - + - - Нецільовий `pnpm test` запускає дванадцять менших конфігурацій шардiв (`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`, явні мапінги вихідного коду й локальні залежні елементи графа імпортів. Правки конфігурації/налаштування/пакетів не запускають широкі тести, якщо ви явно не використаєте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. - - `pnpm check:changed` — це звичайний розумний локальний check gate для вузької роботи. Він класифікує diff на core, тести core, extensions, тести extension, apps, docs, метадані release, live Docker tooling та tooling, а потім запускає відповідні команди typecheck, lint і guard. Він не запускає тести Vitest; викликайте `pnpm test:changed` або явний `pnpm test ` для тестового доказу. Зміни версії лише в метаданих release запускають цільові перевірки version/config/root-dependency із guard, який відхиляє зміни package за межами верхньорівневого поля version. - - Правки live Docker ACP harness запускають сфокусовані перевірки: shell-синтаксис для live Docker auth-скриптів і dry-run live Docker scheduler. Зміни `package.json` включаються лише тоді, коли diff обмежений `scripts["test:docker:live-*"]`; правки dependency, export, version та іншої package-surface і далі використовують ширші guards. - - 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 запуски на явні сусідні тести в цих легких lanes, щоб правки helpers не перезапускали повний важкий набір для цього каталогу. - - `auto-reply` має виділені buckets для верхньорівневих core helpers, верхньорівневих інтеграційних тестів `reply.*` і піддерева `src/auto-reply/reply/**`. CI додатково розділяє піддерево reply на шарди agent-runner, dispatch і commands/state-routing, щоб один import-heavy bucket не займав увесь хвіст Node. - - Звичайний CI для PR/main навмисно пропускає пакетний sweep extension і release-only шард `agentic-plugins`. Full Release Validation запускає окремий дочірній 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`) замість одного гігантського нативного процесу root-project. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension виснажувати непов’язані набори. + - `pnpm test --watch` усе ще використовує нативний граф проєкту root `vitest.config.ts`, бо watch-цикл із багатьма шардами непрактичний. + - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спершу маршрутизують явні цілі файлів/каталогів через scoped lanes, тож `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає повної вартості запуску root project. + - `pnpm test:changed` стандартно розгортає змінені git-шляхи в дешеві scoped lanes: прямі зміни тестів, сусідні файли `*.test.ts`, явні зіставлення source і локальні залежні елементи import-graph. Зміни config/setup/package не запускають широкі тести, якщо явно не використати `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. + - `pnpm check:changed` — звичайний розумний локальний check gate для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata, live Docker tooling і tooling, а потім запускає відповідні команди typecheck, lint і guard. Він не запускає тести Vitest; для тестового доказу викликайте `pnpm test:changed` або явний `pnpm test `. Зміни версій лише в release metadata запускають цільові перевірки version/config/root-dependency із guard, який відхиляє зміни package поза верхньорівневим полем version. + - Зміни live Docker ACP harness запускають сфокусовані перевірки: синтаксис shell для скриптів live Docker auth і dry-run live Docker scheduler. Зміни `package.json` включаються лише тоді, коли diff обмежений `scripts["test:docker:live-*"]`; зміни dependency, export, version та іншої package-surface все ще використовують ширші guards. + - Легкі за імпортами модульні тести з agents, commands, plugins, auto-reply helpers, `plugin-sdk` і подібних чистих utility-областей маршрутизуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. + - Вибрані helper source-файли `plugin-sdk` і `commands` також зіставляють changed-mode запуски з явними сусідніми тестами в цих легких lanes, тож зміни helper не перезапускають повний важкий набір для цього каталогу. + - `auto-reply` має окремі buckets для верхньорівневих core helpers, верхньорівневих інтеграційних тестів `reply.*` і піддерева `src/auto-reply/reply/**`. CI додатково розділяє піддерево reply на шарди agent-runner, dispatch і commands/state-routing, щоб один import-heavy bucket не володів усім хвостом Node. + - Звичайний PR/main CI навмисно пропускає пакетний sweep extensions і release-only шард `agentic-plugins`. Full Release Validation запускає окремий дочірній workflow `Plugin Prerelease` для цих plugin/extension-heavy наборів на release candidates. - + - - Коли ви змінюєте входи виявлення message-tool або runtime-контекст Compaction, + - Коли змінюєте вхідні дані discovery message-tool або runtime-контекст Compaction, зберігайте обидва рівні покриття. - - Додавайте сфокусовані регресії helpers для меж чистої маршрутизації та нормалізації. + - Додавайте сфокусовані helper-регресії для меж чистої маршрутизації та нормалізації. - Підтримуйте справність інтеграційних наборів 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`; helper-only тести + не є достатньою заміною для цих інтеграційних шляхів. - + - - Базова конфігурація Vitest за замовчуванням використовує `threads`. - - Спільна конфігурація Vitest фіксує `isolate: false` і використовує - неізольований runner у кореневих проєктах, e2e та live-конфігураціях. - - Коренева UI lane зберігає своє налаштування `jsdom` та optimizer, але також запускається на - спільному неізольованому runner. - - Кожен шард `pnpm test` успадковує ті самі типові значення `threads` + `isolate: false` - зі спільної конфігурації Vitest. - - `scripts/run-vitest.mjs` за замовчуванням додає `--no-maglev` для дочірніх процесів Node - Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. - Установіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8. + - Базовий конфіг Vitest стандартно використовує `threads`. + - Спільний конфіг Vitest фіксує `isolate: false` і використовує + non-isolated runner у root projects, e2e та live config. + - Root UI lane зберігає свій `jsdom` setup і optimizer, але також працює на + спільному non-isolated runner. + - Кожен шард `pnpm test` успадковує ті самі стандартні значення `threads` + `isolate: false` + зі спільного конфіга Vitest. + - `scripts/run-vitest.mjs` стандартно додає `--no-maglev` для дочірніх процесів Vitest Node, + щоб зменшити compile churn V8 під час великих локальних запусків. + Встановіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною + поведінкою V8. - + - `pnpm changed:lanes` показує, які архітектурні lanes запускає diff. - - Pre-commit hook виконує лише форматування. Він повторно індексує відформатовані файли й - не запускає lint, typecheck або тести. - - Запускайте `pnpm check:changed` явно перед передаванням або push, коли вам - потрібен розумний локальний check gate. - - `pnpm test:changed` за замовчуванням проходить через дешеві scoped lanes. Використовуйте + - Pre-commit hook виконує лише форматування. Він повторно stage-ить відформатовані файли й + не запускає lint, typecheck або tests. + - Запускайте `pnpm check:changed` явно перед handoff або push, коли вам + потрібен smart local check gate. + - `pnpm test:changed` стандартно маршрутизується через дешеві scoped lanes. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли agent - вирішить, що правка harness, config, package або contract справді потребує ширшого + вирішує, що зміна harness, config, package або contract справді потребує ширшого покриття Vitest. - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, - лише з вищою межею workers. - - Автомасштабування локальних workers навмисно консервативне й відступає, - коли середнє навантаження хоста вже високе, тому кілька одночасних - запусків Vitest за замовчуванням завдають менше шкоди. - - Базова конфігурація Vitest позначає проєкти/конфігураційні файли як + лише з вищим лімітом workers. + - Локальне auto-scaling workers навмисно консервативне й зменшує навантаження, + коли середнє навантаження хоста вже високе, тож кілька одночасних + запусків Vitest стандартно завдають менше шкоди. + - Базовий конфіг Vitest позначає projects/config files як `forceRerunTriggers`, щоб reruns у changed-mode залишалися коректними, коли змінюється - test wiring. - - Конфігурація залишає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних - хостах; установіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете - одне явне розташування кешу для прямого профілювання. + wiring тестів. + - Конфіг залишає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних + хостах; встановіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете + одне явне розташування cache для прямого профілювання. - + - - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпортів плюс + - `pnpm test:perf:imports` вмикає звітування Vitest про import-duration плюс вивід import-breakdown. - - `pnpm test:perf:imports:changed` обмежує той самий профілювальний вигляд + - `pnpm test:perf:imports:changed` обмежує той самий profiling view файлами, зміненими з `origin/main`. - - Дані таймінгів шардiв записуються в `.artifacts/vitest-shard-timings.json`. - Запуски всієї конфігурації використовують шлях конфігурації як ключ; include-pattern CI - шарди додають назву шарду, щоб відфільтровані шарди можна було відстежувати + - Дані часу шардів записуються в `.artifacts/vitest-shard-timings.json`. + Whole-config запуски використовують шлях config як ключ; include-pattern CI + shards додають назву shard, щоб filtered shards можна було відстежувати окремо. - - Коли один гарячий тест і далі витрачає більшість часу на стартові імпорти, - тримайте важкі залежності за вузьким локальним швом `*.runtime.ts` і - мокайте цей шов напряму, замість deep-import runtime helpers лише - для передавання їх через `vi.mock(...)`. + - Коли один hot test усе ще витрачає більшість часу на startup imports, + тримайте важкі залежності за вузьким локальним seam `*.runtime.ts` і + mock-айте цей seam напряму замість deep-importing runtime helpers лише + для передачі їх через `vi.mock(...)`. - `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований - `test:changed` із нативним шляхом кореневого проєкту для цього закоміченого - diff і друкує wall time плюс максимальний RSS macOS. + `test:changed` із нативним root-project path для цього committed + diff і друкує wall time плюс macOS max RSS. - `pnpm test:perf:changed:bench -- --worktree` бенчмаркить поточне - брудне дерево, маршрутизуючи список змінених файлів через - `scripts/test-projects.mjs` і кореневу конфігурацію Vitest. - - `pnpm test:perf:profile:main` записує CPU-профіль main-thread для - накладних витрат запуску Vitest/Vite і transform. - - `pnpm test:perf:profile:runner` записує CPU+heap профілі runner для - unit suite з вимкненою файловою паралельністю. + dirty tree, маршрутизуючи список змінених файлів через + `scripts/test-projects.mjs` і root Vitest config. + - `pnpm test:perf:profile:main` записує main-thread CPU profile для + startup Vitest/Vite і transform overhead. + - `pnpm test:perf:profile:runner` записує runner CPU+heap profiles для + unit suite з вимкненим file parallelism. -### Стабільність (Gateway) +### Стабільність (gateway) - Команда: `pnpm test:stability:gateway` - Конфігурація: `vitest.gateway.config.ts`, примусово один worker -- Обсяг: - - Запускає реальний loopback Gateway із діагностикою, увімкненою за замовчуванням - - Проганяє synthetic gateway message, memory і large-payload churn через шлях діагностичної події - - Опитує `diagnostics.stability` через Gateway WS RPC - - Покриває helpers збереження diagnostic stability bundle - - Перевіряє, що recorder залишається обмеженим, synthetic RSS samples залишаються нижче pressure budget, а глибини черг по сесіях спадають назад до нуля +- Область: + - Запускає реальний loopback Gateway із diagnostics, увімкненими стандартно + - Проганяє синтетичний churn gateway message, memory і large-payload через diagnostic event path + - Запитує `diagnostics.stability` через Gateway WS RPC + - Покриває допоміжні модулі збереження diagnostic stability bundle + - Перевіряє, що recorder залишається обмеженим, синтетичні RSS samples лишаються нижче pressure budget, а глибини per-session queue повертаються до нуля - Очікування: - - Безпечно для CI і без ключів - - Вузька lane для подальшого опрацювання stability-regression, а не заміна повного набору Gateway + - Безпечно для CI і не потребує ключів + - Вузький lane для подальшої роботи зі stability-regression, не заміна повному набору Gateway ### E2E (gateway smoke) - Команда: `pnpm test:e2e` - Конфігурація: `vitest.e2e.config.ts` -- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести вбудованих plugin у `extensions/` -- Runtime-типові значення: - - Використовує Vitest `threads` з `isolate: false`, відповідно до решти repo. - - Використовує адаптивних workers (CI: до 2, локально: 1 за замовчуванням). - - За замовчуванням запускається в silent mode, щоб зменшити накладні витрати console I/O. +- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і bundled-plugin E2E tests у `extensions/` +- Стандартні runtime-значення: + - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію. + - Використовує адаптивні workers (CI: до 2, локально: стандартно 1). + - Стандартно запускається в silent mode, щоб зменшити overhead console I/O. - Корисні перевизначення: - - `OPENCLAW_E2E_WORKERS=` для примусового встановлення кількості workers (обмежено 16). - - `OPENCLAW_E2E_VERBOSE=1` для повторного ввімкнення докладного виводу console. -- Обсяг: - - Наскрізна поведінка багатьох екземплярів Gateway - - Поверхні WebSocket/HTTP, сполучення node і важча мережева взаємодія + - `OPENCLAW_E2E_WORKERS=` для примусового задання кількості workers (обмежено 16). + - `OPENCLAW_E2E_VERBOSE=1` для повторного ввімкнення verbose console output. +- Область: + - End-to-end поведінка multi-instance gateway + - Поверхні WebSocket/HTTP, node pairing і важчий networking - Очікування: - Запускається в CI (коли ввімкнено в pipeline) - Реальні ключі не потрібні @@ -545,230 +547,230 @@ utilities. - Команда: `pnpm test:e2e:openshell` - Файл: `extensions/openshell/src/backend.e2e.test.ts` -- Область: - - Запускає ізольований Gateway OpenShell на хості через Docker +- Обсяг: + - Запускає ізольований OpenShell gateway на хості через Docker - Створює sandbox із тимчасового локального Dockerfile - - Перевіряє бекенд OpenShell в OpenClaw через справжні `sandbox ssh-config` + виконання SSH - - Перевіряє поведінку файлової системи з віддаленим канонічним шляхом через міст fs sandbox + - Перевіряє backend OpenShell в OpenClaw через справжні `sandbox ssh-config` + виконання SSH + - Перевіряє віддалено-канонічну поведінку файлової системи через міст fs sandbox - Очікування: - - Лише за явним увімкненням; не входить до стандартного запуску `pnpm test:e2e` - - Потребує локального CLI `openshell` і робочого демона Docker - - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує тестовий Gateway і sandbox + - Лише за явним увімкненням; не є частиною стандартного запуску `pnpm test:e2e` + - Потребує локального CLI `openshell` і робочого daemon Docker + - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує тестовий gateway і sandbox - Корисні перевизначення: - - `OPENCLAW_E2E_OPENSHELL=1`, щоб увімкнути тест під час ручного запуску ширшого набору e2e - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, щоб указати нестандартний бінарний файл CLI або wrapper-скрипт + - `OPENCLAW_E2E_OPENSHELL=1`, щоб увімкнути тест під час ручного запуску ширшого e2e-набору + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, щоб указати нестандартний бінарний файл CLI або wrapper script ### Live (справжні провайдери + справжні моделі) - Команда: `pnpm test:live` - Конфігурація: `vitest.live.config.ts` - Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і live-тести bundled-plugin у `extensions/` -- Стандартно: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`) -- Область: - - “Чи цей провайдер/модель справді працює _сьогодні_ зі справжніми обліковими даними?” +- За замовчуванням: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`) +- Обсяг: + - «Чи цей провайдер/модель справді працює _сьогодні_ зі справжніми обліковими даними?» - Виявляє зміни форматів провайдерів, особливості виклику інструментів, проблеми автентифікації та поведінку обмежень швидкості - Очікування: - - За задумом не є стабільним для CI (справжні мережі, справжні політики провайдерів, квоти, збої) + - За задумом не є стабільним для CI (справжні мережі, реальні політики провайдерів, квоти, збої) - Коштує грошей / використовує ліміти швидкості - - Краще запускати звужені підмножини замість “усього” -- Live-запуски завантажують `~/.profile`, щоб підхопити відсутні API-ключі. -- За замовчуванням live-запуски все ще ізолюють `HOME` і копіюють матеріали конфігурації/автентифікації в тимчасовий тестовий домашній каталог, щоб unit-фікстури не могли змінити ваш справжній `~/.openclaw`. + - Віддавайте перевагу запуску звужених підмножин замість «усього» +- Live-запуски підвантажують `~/.profile`, щоб отримати відсутні API-ключі. +- За замовчуванням live-запуски все одно ізолюють `HOME` і копіюють конфігурацію/матеріали автентифікації в тимчасовий тестовий home, щоб unit-фікстури не могли змінити ваш справжній `~/.openclaw`. - Встановлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли ви навмисно хочете, щоб live-тести використовували ваш справжній домашній каталог. -- `pnpm test:live` тепер за замовчуванням працює в тихішому режимі: зберігає прогрес-вивід `[live] ...`, але приглушує додаткове повідомлення про `~/.profile` і вимикає логи bootstrap Gateway/шум Bonjour. Встановіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні стартові логи. -- Ротація API-ключів (залежно від провайдера): задайте `*_API_KEYS` у форматі з комами/крапками з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) чи live-перевизначення для окремого провайдера через `OPENCLAW_LIVE_*_KEY`; тести повторюють спроби у відповідь на ліміти швидкості. +- `pnpm test:live` тепер за замовчуванням працює тихіше: зберігає прогрес-вивід `[live] ...`, але приховує додаткове повідомлення `~/.profile` і вимикає bootstrap-логи gateway/шум Bonjour. Встановіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні логи запуску. +- Ротація API-ключів (залежить від провайдера): встановіть `*_API_KEYS` у форматі через кому/крапку з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) чи перевизначення для окремого live-запуску через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу при відповідях з обмеженням швидкості. - Вивід прогресу/heartbeat: - - Live-набори тепер виводять рядки прогресу в stderr, щоб довгі виклики провайдерів були помітно активними навіть тоді, коли перехоплення консолі Vitest тихе. - - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, тож рядки прогресу провайдера/Gateway одразу передаються під час live-запусків. - - Налаштуйте heartbeat для прямих моделей через `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Налаштуйте heartbeat для Gateway/перевірок через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. + - Live-набори тепер виводять рядки прогресу в stderr, тому довгі виклики провайдера помітно активні навіть тоді, коли захоплення консолі Vitest тихе. + - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, щоб рядки прогресу провайдера/gateway транслювалися негайно під час live-запусків. + - Налаштуйте heartbeats прямих моделей через `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Налаштуйте heartbeats gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. -## Який набір слід запускати? +## Який набір запускати? Скористайтеся цією таблицею рішень: -- Редагуєте логіку/тести: запускайте `pnpm test` (і `pnpm test:coverage`, якщо змінили багато) -- Торкаєтеся мережевої взаємодії Gateway / протоколу WS / pairing: додайте `pnpm test:e2e` -- Налагоджуєте “мій бот не працює” / збої, специфічні для провайдера / виклик інструментів: запускайте звужений `pnpm test:live` +- Редагуєте логіку/тести: запустіть `pnpm test` (і `pnpm test:coverage`, якщо змінили багато) +- Торкаєтеся мережевого шару gateway / протоколу WS / pairing: додайте `pnpm test:e2e` +- Налагоджуєте «мій бот не працює» / збої, специфічні для провайдера / виклик інструментів: запустіть звужений `pnpm test:live` -## Live (тести, що торкаються мережі) +## Live-тести (з доступом до мережі) -Про live-матрицю моделей, smoke-тести бекенда CLI, smoke-тести ACP, harness app-server Codex -і всі live-тести медіапровайдерів (Deepgram, BytePlus, ComfyUI, зображення, -музика, відео, media harness), а також обробку облікових даних для live-запусків див. -[Тестування live-наборів](/uk/help/testing-live). Для окремого контрольного списку оновлення та -перевірки Plugin див. -[Тестування оновлень і plugins](/uk/help/testing-updates-plugins). +Для live-матриці моделей, smoke-тестів backend CLI, smoke-тестів ACP, harness app-server Codex +і всіх live-тестів медіапровайдерів (Deepgram, BytePlus, ComfyUI, зображення, +музика, відео, media harness), а також обробки облікових даних для live-запусків, див. +[Тестування live-наборів](/uk/help/testing-live). Для спеціального контрольного списку оновлень і +валідації Plugin див. +[Тестування оновлень і Plugin](/uk/help/testing-updates-plugins). -## Docker runners (необов’язкові перевірки "працює в Linux") +## 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`), монтують ваш локальний каталог конфігурації та робочу область (і завантажують `~/.profile`, якщо його змонтовано). Відповідні локальні точки входу: `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`, +- Live-model runners: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл profile-key всередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують ваш локальний каталог конфігурації та workspace (і підвантажують `~/.profile`, якщо його змонтовано). Відповідні локальні точки входу: `test:live:models-profiles` і `test:live:gateway-profiles`. +- Docker live runners за замовчуванням мають менший smoke-ліміт, щоб повний Docker-прогін залишався практичним: + `test:docker:live-models` за замовчуванням використовує `OPENCLAW_LIVE_MAX_MODELS=12`, а + `test:docker:live-gateway` за замовчуванням використовує `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, `OPENCLAW_LIVE_GATEWAY_MAX_MODELS=8`, `OPENCLAW_LIVE_GATEWAY_STEP_TIMEOUT_MS=45000` і - `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env-змінні, коли + `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці env vars, коли ви явно хочете більший вичерпний scan. -- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, один раз пакує OpenClaw як npm tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Базовий образ є лише runner Node/Git для напрямків install/update/plugin-dependency; ці напрями монтують попередньо зібраний tarball. Функціональний образ встановлює той самий tarball у `/app` для напрямків функціональності зібраного застосунку. Визначення Docker-напрямів містяться в `scripts/lib/docker-e2e-scenarios.mjs`; логіка планувальника — у `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` виконує вибраний план. Агрегат використовує зважений локальний планувальник: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує слотами процесів, а обмеження ресурсів не дають важким live-, npm-install- і multi-service-напрямам стартувати всім одночасно. Якщо один напрям важчий за активні обмеження, планувальник усе одно може запустити його, коли pool порожній, і потім тримає його єдиним активним, доки знову не з’явиться доступна ємність. Стандартні значення: 10 слотів, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; налаштовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` лише тоді, коли Docker-хост має більше запасу ресурсів. Runner за замовчуванням виконує Docker preflight, видаляє застарілі контейнери OpenClaw E2E, друкує статус кожні 30 секунд, зберігає таймінги успішних напрямів у `.artifacts/docker-tests/lane-timings.json` і використовує ці таймінги, щоб у наступних запусках спочатку стартували довші напрями. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб надрукувати зважений маніфест напрямів без збирання або запуску Docker, або `node scripts/test-docker-all.mjs --plan-json`, щоб надрукувати CI-план для вибраних напрямів, потреб у package/image та облікових даних. -- `Package Acceptance` — це нативний для GitHub package gate для питання "чи цей installable tarball працює як продукт?" Він розв’язує один кандидатний package з `source=npm`, `source=ref`, `source=url` або `source=artifact`, завантажує його як `package-under-test`, а потім запускає reusable Docker E2E-напрями проти саме цього tarball замість повторного пакування вибраного ref. Профілі впорядковані за широтою: `smoke`, `package`, `product` і `full`. Див. [Тестування оновлень і plugins](/uk/help/testing-updates-plugins) щодо контракту package/update/plugin, матриці виживання published-upgrade, стандартів release і triage збоїв. -- Перевірки build і release запускають `scripts/check-cli-bootstrap-imports.mjs` після tsdown. Захисна перевірка обходить статичний зібраний граф від `dist/entry.js` і `dist/cli/run-main.js` та завершується помилкою, якщо startup до dispatch імпортує package-залежності, як-от Commander, prompt UI, undici або logging, до dispatch команди; вона також тримає зібраний gateway run chunk у межах бюджету та відхиляє статичні імпорти відомих холодних шляхів Gateway. Packaged CLI smoke також покриває root help, onboard help, doctor help, status, config schema і команду списку моделей. -- Сумісність Package Acceptance legacy обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цього cutoff harness допускає лише metadata-прогалини shipped-package: пропущені приватні записи інвентарю QA, відсутній `gateway install --wrapper`, відсутні patch-файли у git-фікстурі, отриманій з tarball, відсутній збережений `update.channel`, legacy-розташування записів встановлення Plugin, відсутнє збереження записів встановлення marketplace і міграцію metadata конфігурації під час `plugins update`. Для packages після `2026.4.25` ці шляхи є суворими помилками. -- Container smoke runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:upgrade-survivor`, `test:docker:published-upgrade-survivor`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` і `test:docker:config-reload` запускають один або кілька справжніх контейнерів і перевіряють інтеграційні шляхи вищого рівня. +- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, один раз пакує OpenClaw як npm tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Bare-образ є лише Node/Git runner для install/update/plugin-dependency lanes; ці lanes монтують попередньо зібраний tarball. Functional-образ встановлює той самий tarball у `/app` для built-app functionality lanes. Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`; логіка planner міститься в `scripts/lib/docker-e2e-plan.mjs`; `scripts/test-docker-all.mjs` виконує вибраний план. Агрегатор використовує зважений локальний scheduler: `OPENCLAW_DOCKER_ALL_PARALLELISM` керує слотами процесів, а обмеження ресурсів не дають важким live-, npm-install- і multi-service lanes стартувати всім одночасно. Якщо окремий lane важчий за активні обмеження, scheduler все одно може запустити його, коли pool порожній, а потім тримає його єдиним запущеним, доки знову не стане доступною capacity. За замовчуванням: 10 слотів, `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`; налаштовуйте `OPENCLAW_DOCKER_ALL_WEIGHT_LIMIT` або `OPENCLAW_DOCKER_ALL_DOCKER_LIMIT` лише тоді, коли Docker-хост має більше запасу. Runner за замовчуванням виконує Docker preflight, видаляє застарілі контейнери OpenClaw E2E, друкує статус кожні 30 секунд, зберігає таймінги успішних lanes у `.artifacts/docker-tests/lane-timings.json` і використовує ці таймінги, щоб у наступних запусках першими стартували довші lanes. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб надрукувати зважений маніфест lanes без збирання чи запуску Docker, або `node scripts/test-docker-all.mjs --plan-json`, щоб надрукувати CI-план для вибраних lanes, потреб package/image і облікових даних. +- `Package Acceptance` — це нативний для GitHub package gate для питання «чи працює цей installable tarball як продукт?». Він визначає один candidate package із `source=npm`, `source=ref`, `source=url` або `source=artifact`, завантажує його як `package-under-test`, а потім запускає reusable Docker E2E lanes проти саме цього tarball замість перепакування вибраного ref. Профілі впорядковані за широтою: `smoke`, `package`, `product` і `full`. Див. [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins) щодо контракту package/update/plugin, матриці published-upgrade survivor, стандартних налаштувань release і triage збоїв. +- Перевірки build і release запускають `scripts/check-cli-bootstrap-imports.mjs` після tsdown. Guard обходить статичний built graph від `dist/entry.js` і `dist/cli/run-main.js` та завершується з помилкою, якщо startup imports до dispatch команди імпортують package dependencies, як-от Commander, prompt UI, undici або logging; він також утримує bundled gateway run chunk у межах бюджету та відхиляє статичні імпорти відомих холодних gateway paths. Packaged CLI smoke також охоплює root help, onboard help, doctor help, status, config schema і команду model-list. +- Застаріла сумісність Package Acceptance обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цього cutoff harness допускає лише прогалини shipped-package metadata: пропущені private QA inventory entries, відсутній `gateway install --wrapper`, відсутні patch-файли у tarball-derived git fixture, відсутній persisted `update.channel`, застарілі розташування plugin install-record, відсутня marketplace install-record persistence і міграція config metadata під час `plugins update`. Для package після `2026.4.25` ці шляхи є strict failures. +- Container smoke runners: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `test:docker:upgrade-survivor`, `test:docker:published-upgrade-survivor`, `test:docker:session-runtime-context`, `test:docker:agents-delete-shared-workspace`, `test:docker:gateway-network`, `test:docker:browser-cdp-snapshot`, `test:docker:mcp-channels`, `test:docker:pi-bundle-mcp-tools`, `test:docker:cron-mcp-cleanup`, `test:docker:plugins`, `test:docker:plugin-update` і `test:docker:config-reload` запускають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. -Live-model Docker runners також монтують лише потрібні домашні каталоги автентифікації CLI (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у домашній каталог контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени без зміни сховища автентифікації хоста: +Live-model Docker runners також bind-mount лише потрібні auth homes CLI (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у home контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати tokens без зміни auth store хоста: - Прямі моделі: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`) - ACP bind smoke: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`; за замовчуванням охоплює Claude, Codex і Gemini, зі строгим покриттям Droid/OpenCode через `pnpm test:docker:live-acp-bind:droid` і `pnpm test:docker:live-acp-bind:opencode`) -- Smoke-тест бекенда CLI: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) -- Smoke-тест Codex app-server harness: `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-доріжка перевірки source-checkout. Її навмисно не включено до Docker-доріжок випуску пакета, оскільки npm tarball не містить QA Lab. -- Live smoke для Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) -- Майстер онбордингу (TTY, повне створення каркаса): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) -- Smoke-тест npm tarball для онбордингу/каналу/агента: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований tarball OpenClaw у Docker, налаштовує OpenAI через онбординг з посиланням на змінні середовища та 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`, попросіть агрегований планувальник розгорнути точні базові версії через `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS` і розгорніть 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 context сесії: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого runtime context у transcript, а також ремонт 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-образу з `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-контейнерів. Smoke-тест оновлення за замовчуванням використовує npm `latest` як стабільну базову версію перед оновленням до кандидатного tarball. Перевизначте локально через `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` або через вхідний параметр `update_baseline_version` workflow Install Smoke на GitHub. Перевірки non-root інсталятора використовують ізольований npm cache, щоб записи cache з root-власником не приховували поведінку встановлення в користувацькому середовищі. Установіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати root/update/direct-npm cache між локальними повторними запусками. -- Install Smoke CI пропускає дубльоване глобальне оновлення direct-npm з `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цієї env, коли потрібне покриття прямого `npm install -g`. -- Smoke-тест CLI видалення агентів зі спільним workspace: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) за замовчуванням збирає образ кореневого Dockerfile, засіває двох агентів з одним workspace в ізольованому home контейнера, запускає `agents delete --json` і перевіряє валідний JSON та поведінку збереженого workspace. Повторно використовуйте образ install-smoke з `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. -- Мережа Gateway (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) -- Smoke-тест snapshot Browser CDP: `pnpm test:docker:browser-cdp-snapshot` (скрипт: `scripts/e2e/browser-cdp-snapshot-docker.sh`) збирає вихідний E2E-образ із шаром Chromium, запускає Chromium із сирим CDP, виконує `browser doctor --deep` і перевіряє, що snapshot-и ролей CDP охоплюють URL посилань, clickable-елементи, підвищені cursor-ом, iframe-посилання та метадані frame. -- Регресія OpenAI Responses web_search з мінімальним reasoning: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає мокований сервер OpenAI через Gateway, перевіряє, що `web_search` підвищує `reasoning.effort` з `minimal` до `low`, потім примусово відхиляє schema провайдера і перевіряє, що сирі деталі з’являються в логах Gateway. -- MCP-міст каналу (засіяний Gateway + stdio-міст + сирий smoke-тест Claude notification-frame): `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 і одноразового subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Plugins (install/update smoke для локального шляху, `file:`, npm registry з hoisted-залежностями, рухомих git refs, ClawHub kitchen-sink, marketplace updates і Claude-bundle enable/inspect): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) - Установіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб пропустити блок ClawHub, або перевизначте стандартну пару package/runtime kitchen-sink через `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` і `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Без `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` тест використовує герметичний локальний fixture-сервер ClawHub. -- Smoke-тест незміненого оновлення Plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) -- Smoke-тест metadata перезавантаження конфігурації: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) -- Plugins: `pnpm test:docker:plugins` охоплює install/update smoke для локального шляху, `file:`, npm registry з hoisted-залежностями, рухомих git refs, фікстур ClawHub, marketplace updates і Claude-bundle enable/inspect. `pnpm test:docker:plugin-update` охоплює поведінку незміненого оновлення для встановлених plugins. +- CLI backend smoke: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) +- Codex app-server harness smoke: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) +- Gateway + dev agent: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`) +- Observability smoke: `pnpm qa:otel:smoke` є приватною QA-лінією перевірки вихідного checkout. Її навмисно не включено до Docker-ліній випуску пакета, оскільки npm tarball не містить QA Lab. +- Open WebUI live smoke: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) +- Майстер онбордингу (TTY, повне scaffold-налаштування): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) +- Npm tarball onboarding/channel/agent smoke: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований OpenClaw tarball у Docker, налаштовує OpenAI через env-ref онбординг і Telegram за замовчуванням, запускає doctor і виконує один змоканий хід агента OpenAI. Повторно використайте попередньо зібраний tarball з `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть перебудову на host за допомогою `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або перемкніть канал за допомогою `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. +- Update channel switch smoke: `pnpm test:docker:update-channel-switch` глобально встановлює запакований OpenClaw tarball у Docker, перемикається з пакетного `stable` на git `dev`, перевіряє збережений канал і роботу плагіна після оновлення, потім перемикається назад на пакетний `stable` і перевіряє статус оновлення. +- Upgrade survivor smoke: `pnpm test:docker:upgrade-survivor` встановлює запакований OpenClaw tarball поверх забрудненої фікстури старого користувача з агентами, конфігурацією каналу, allowlist плагінів, застарілим станом залежностей плагінів і наявними файлами workspace/session. Він запускає оновлення пакета плюс неінтерактивний doctor без live provider або ключів каналу, потім запускає loopback Gateway і перевіряє збереження конфігурації/стану, а також бюджети startup/status. +- Published upgrade survivor smoke: `pnpm test:docker:published-upgrade-survivor` за замовчуванням встановлює `openclaw@latest`, сідує реалістичні файли наявного користувача, налаштовує цей baseline за допомогою вбудованого рецепта команд, перевіряє отриману конфігурацію, оновлює це опубліковане встановлення до candidate tarball, запускає неінтерактивний doctor, записує `.artifacts/upgrade-survivor/summary.json`, потім запускає loopback Gateway і перевіряє налаштовані intents, збереження стану, startup, `/healthz`, `/readyz` і бюджети статусу RPC. Перевизначте один baseline за допомогою `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC`, попросіть агрегований scheduler розгорнути точні baseline за допомогою `OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS` і розгорніть фікстури у формі issue за допомогою `OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS`, наприклад `reported-issues`; набір reported-issues містить `configured-plugin-installs` для автоматичного ремонту встановлення зовнішнього плагіна OpenClaw. Package Acceptance експонує їх як `published_upgrade_survivor_baseline`, `published_upgrade_survivor_baselines` і `published_upgrade_survivor_scenarios`. +- Session runtime context smoke: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого transcript runtime context плюс ремонт doctor для зачеплених дубльованих гілок prompt-rewrite. +- Bun global install smoke: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольованому home і перевіряє, що `openclaw infer image providers --json` повертає вбудованих provider зображень замість зависання. Повторно використайте попередньо зібраний tarball з `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть host build за допомогою `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або скопіюйте `dist/` із зібраного Docker image за допомогою `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. +- Installer Docker smoke: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm cache для своїх root, update і direct-npm контейнерів. Update smoke за замовчуванням використовує npm `latest` як stable baseline перед оновленням до candidate tarball. Перевизначте локально за допомогою `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` або через input `update_baseline_version` workflow Install Smoke на GitHub. Non-root перевірки інсталятора тримають ізольований npm cache, щоб записи cache, що належать root, не маскували поведінку user-local встановлення. Установіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати root/update/direct-npm cache між локальними повторними запусками. +- Install Smoke CI пропускає дубльоване direct-npm глобальне оновлення за допомогою `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`. +- Agents delete shared workspace CLI smoke: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) за замовчуванням збирає root Dockerfile image, сідує двох агентів з одним workspace в ізольованому container home, запускає `agents delete --json` і перевіряє коректний JSON плюс поведінку збереженого workspace. Повторно використайте install-smoke image за допомогою `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. +- Gateway networking (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) +- Browser CDP snapshot smoke: `pnpm test:docker:browser-cdp-snapshot` (скрипт: `scripts/e2e/browser-cdp-snapshot-docker.sh`) збирає source E2E image плюс шар Chromium, запускає Chromium із raw CDP, виконує `browser doctor --deep` і перевіряє, що CDP role snapshots охоплюють URL посилань, clickables, підвищені cursor, iframe refs і metadata frame. +- OpenAI Responses web_search minimal reasoning regression: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає змоканий сервер OpenAI через Gateway, перевіряє, що `web_search` піднімає `reasoning.effort` з `minimal` до `low`, потім примусово відхиляє provider schema і перевіряє, що raw detail з’являється в логах Gateway. +- MCP channel bridge (seeded Gateway + stdio bridge + raw Claude notification-frame smoke): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) +- Pi bundle MCP tools (реальний stdio MCP server + embedded Pi profile allow/deny smoke): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) +- Cron/subagent MCP cleanup (реальний Gateway + демонтаж stdio MCP child після ізольованого cron і one-shot subagent запусків): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Plugins (install/update smoke для локального шляху, `file:`, npm registry з hoisted залежностями, git moving refs, ClawHub kitchen-sink, оновлень marketplace і Claude-bundle enable/inspect): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) + Установіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб пропустити блок ClawHub, або перевизначте стандартну пару kitchen-sink package/runtime за допомогою `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` і `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Без `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` тест використовує герметичний локальний сервер фікстури ClawHub. +- Plugin update unchanged smoke: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) +- Config reload metadata smoke: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) +- Plugins: `pnpm test:docker:plugins` охоплює install/update smoke для локального шляху, `file:`, npm registry з hoisted залежностями, git moving refs, фікстур ClawHub, оновлень marketplace і Claude-bundle enable/inspect. `pnpm test:docker:plugin-update` охоплює поведінку unchanged update для встановлених плагінів. -Щоб вручну попередньо зібрати й повторно використовувати спільний функціональний образ: +Щоб вручну попередньо зібрати й повторно використовувати спільний 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 ``` -Специфічні для набору перевизначення образу, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе одно мають пріоритет, коли задані. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний образ, скрипти завантажують його, якщо його ще немає локально. QR- і installer-Docker-тести зберігають власні Dockerfile, бо вони перевіряють поведінку пакета/встановлення, а не спільний runtime зібраного застосунку. +Перевизначення image для конкретних suite, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе одно мають пріоритет, коли їх задано. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний image, скрипти завантажують його, якщо він ще не є локальним. QR і installer Docker тести зберігають власні Dockerfile, бо вони перевіряють поведінку пакета/встановлення, а не спільний runtime зібраного застосунку. -Docker-ранери live-model також монтують поточний checkout у режимі read-only і -переносять його в тимчасовий workdir всередині контейнера. Це зберігає runtime -образ легким, водночас запускаючи Vitest проти вашого точного локального source/config. -Крок staging пропускає великі локальні cache та build output застосунків, такі як -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також локальні для застосунку `.build` або -каталоги output Gradle, щоб Docker live runs не витрачали хвилини на копіювання -машинно-специфічних артефактів. -Вони також установлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб gateway live probes не запускали -реальні Telegram/Discord/тощо channel workers всередині контейнера. +Docker runners для live-model також монтують поточний checkout лише для читання і +розгортають його у тимчасовий workdir всередині контейнера. Це зберігає runtime +image компактним, водночас запускаючи Vitest проти вашого точного локального source/config. +Крок staging пропускає великі локальні cache і build outputs застосунку, як-от +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також app-local `.build` або +директорії output Gradle, щоб Docker live runs не витрачали хвилини на копіювання +machine-specific artifacts. +Вони також задають `OPENCLAW_SKIP_CHANNELS=1`, щоб gateway live probes не запускали +реальні worker каналів Telegram/Discord тощо всередині контейнера. `test:docker:live-models` усе ще запускає `pnpm test:live`, тому також передавайте `OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити gateway -live-покриття з цієї Docker-доріжки. -`test:docker:openwebui` — це вищорівневий smoke-тест сумісності: він запускає -контейнер Gateway OpenClaw з увімкненими OpenAI-сумісними HTTP endpoints, -запускає закріплений контейнер Open WebUI проти цього Gateway, входить через -Open WebUI, перевіряє, що `/api/models` показує `openclaw/default`, потім надсилає +live coverage із цієї Docker lane. +`test:docker:openwebui` є вищорівневим compatibility smoke: він запускає +контейнер Gateway OpenClaw з увімкненими OpenAI-compatible HTTP endpoints, +запускає pinned контейнер Open WebUI проти цього gateway, входить через +Open WebUI, перевіряє, що `/api/models` експонує `openclaw/default`, а потім надсилає реальний chat request через proxy `/api/chat/completions` Open WebUI. -Перший запуск може бути помітно повільнішим, бо Docker може потребувати завантажити -образ Open WebUI, а Open WebUI може потребувати завершити власне cold-start setup. -Ця доріжка очікує придатний live model key, а `OPENCLAW_PROFILE_FILE` +Перший запуск може бути помітно повільнішим, бо Docker може знадобитися завантажити +image Open WebUI, а Open WebUI може знадобитися завершити власне cold-start setup. +Ця lane очікує придатний live model key, а `OPENCLAW_PROFILE_FILE` (`~/.profile` за замовчуванням) є основним способом надати його в Dockerized runs. -Успішні запуски виводять невелике JSON payload на кшталт `{ "ok": true, "model": +Успішні запуски друкують невеликий JSON payload на кшталт `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` навмисно детермінований і не потребує -реального облікового запису Telegram, Discord або iMessage. Він запускає засіяний Gateway -container, запускає другий контейнер, який породжує `openclaw mcp serve`, потім -перевіряє routed conversation discovery, читання transcript, metadata attachment, +реального акаунта Telegram, Discord або iMessage. Він завантажує seeded Gateway +container, запускає другий контейнер, який створює `openclaw mcp serve`, потім +перевіряє routed conversation discovery, transcript reads, attachment metadata, поведінку live event queue, outbound send routing і Claude-style channel + permission notifications через реальний stdio MCP bridge. Перевірка notification -безпосередньо інспектує сирі stdio MCP frames, щоб smoke-тест перевіряв те, що -bridge фактично emits, а не лише те, що випадково показує конкретний client SDK. +інспектує raw stdio MCP frames напряму, тож smoke перевіряє те, що +bridge фактично emit, а не лише те, що випадково surface конкретний client SDK. `test:docker:pi-bundle-mcp-tools` детермінований і не потребує live model key. Він збирає repo Docker image, запускає реальний stdio MCP probe server -всередині контейнера, матеріалізує цей server через вбудований Pi bundle -MCP runtime, виконує tool, потім перевіряє, що `coding` і `messaging` зберігають -інструменти `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують. +всередині контейнера, матеріалізує цей 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. Він запускає засіяний Gateway із реальним stdio MCP probe server, виконує -ізольований cron turn і одноразовий child turn `/subagents spawn`, потім перевіряє, -що дочірній процес MCP завершується після кожного запуску. +key. Він запускає seeded Gateway з реальним stdio MCP probe server, виконує +ізольований cron turn і one-shot child turn `/subagents spawn`, а потім перевіряє, +що MCP child process завершується після кожного запуску. -Ручний smoke-тест ACP plain-language thread (не CI): +Ручний ACP plain-language thread smoke (не CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Зберігайте цей скрипт для workflows регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації ACP thread, тому не видаляйте його. +- Зберігайте цей скрипт для regression/debug workflows. Він може знову знадобитися для валідації ACP thread routing, тому не видаляйте його. -Корисні змінні середовища: +Корисні env vars: -- `OPENCLAW_CONFIG_DIR=...` (типово: `~/.openclaw`) змонтовано до `/home/node/.openclaw` -- `OPENCLAW_WORKSPACE_DIR=...` (типово: `~/.openclaw/workspace`) змонтовано до `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (типово: `~/.profile`) змонтовано до `/home/node/.profile` і підвантажується перед запуском тестів -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, щоб перевіряти лише змінні середовища, підвантажені з `OPENCLAW_PROFILE_FILE`, використовуючи тимчасові каталоги config/workspace і без зовнішніх монтувань автентифікації CLI -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (типово: `~/.cache/openclaw/docker-cli-tools`) змонтовано до `/home/node/.npm-global` для кешованих встановлень CLI всередині Docker -- Зовнішні каталоги/файли автентифікації CLI під `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються до `/home/node/...` перед початком тестів - - Типові каталоги: `.minimax` - - Типові файли: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - - Звужені запуски provider монтують лише потрібні каталоги/файли, виведені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` +- `OPENCLAW_CONFIG_DIR=...` (за замовчуванням: `~/.openclaw`) змонтовано до `/home/node/.openclaw` +- `OPENCLAW_WORKSPACE_DIR=...` (за замовчуванням: `~/.openclaw/workspace`) змонтовано до `/home/node/.openclaw/workspace` +- `OPENCLAW_PROFILE_FILE=...` (за замовчуванням: `~/.profile`) змонтовано до `/home/node/.profile` і завантажується перед запуском тестів +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, щоб перевірити лише змінні середовища, завантажені з `OPENCLAW_PROFILE_FILE`, використовуючи тимчасові каталоги конфігурації/робочого простору та без зовнішніх монтувань автентифікації CLI +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) змонтовано до `/home/node/.npm-global` для кешованих встановлень CLI всередині Docker +- Зовнішні каталоги/файли автентифікації CLI під `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються до `/home/node/...` перед запуском тестів + - Каталоги за замовчуванням: `.minimax` + - Файли за замовчуванням: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` + - Звужені запуски провайдерів монтують лише потрібні каталоги/файли, виведені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - Перевизначте вручну за допомогою `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або списку через кому на кшталт `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` - `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...`, щоб звузити запуск -- `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 надає для smoke Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити prompt перевірки nonce, який використовує smoke Open WebUI +- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, щоб фільтрувати провайдерів у контейнері +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб повторно використати наявний образ `openclaw:local-live` для повторних запусків, які не потребують повторного збирання +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб переконатися, що облікові дані надходять зі сховища профілю (не з env) +- `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку Gateway відкриває для smoke-тесту Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити prompt перевірки nonce, який використовує smoke-тест Open WebUI - `OPENWEBUI_IMAGE=...`, щоб перевизначити закріплений тег образу Open WebUI ## Перевірка документації -Запускайте перевірки документації після редагування docs: `pnpm check:docs`. -Запускайте повну перевірку anchors Mintlify, коли також потрібні перевірки заголовків усередині сторінок: `pnpm docs:check-links:anchors`. +Запускайте перевірки документації після редагування документів: `pnpm check:docs`. +Запускайте повну перевірку anchors Mintlify, коли також потрібні перевірки заголовків на сторінці: `pnpm docs:check-links:anchors`. ## Офлайн-регресія (безпечна для CI) -Це регресії “справжнього pipeline” без реальних providers: +Це регресії “реального pipeline” без реальних провайдерів: -- Виклик інструментів Gateway (mock OpenAI, реальний gateway + цикл агента): `src/gateway/gateway.test.ts` (випадок: "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Майстер Gateway (WS `wizard.start`/`wizard.next`, записує config + забезпечує auth): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config") +- Виклик інструментів Gateway (mock OpenAI, реальні gateway + цикл агента): `src/gateway/gateway.test.ts` (випадок: "запускає наскрізний виклик інструмента mock OpenAI через цикл агента gateway") +- Майстер Gateway (WS `wizard.start`/`wizard.next`, записує конфігурацію + застосовується автентифікація): `src/gateway/gateway.test.ts` (випадок: "запускає майстер через ws і записує конфігурацію токена автентифікації") -## Оцінювання надійності агента (skills) +## Eval-и надійності агента (skills) -У нас уже є кілька безпечних для CI тестів, що поводяться як “оцінювання надійності агента”: +У нас уже є кілька безпечних для CI тестів, які поводяться як “eval-и надійності агента”: -- Mock-виклик інструментів через реальний gateway + цикл агента (`src/gateway/gateway.test.ts`). -- Наскрізні потоки майстра, що перевіряють зв’язування сесій і ефекти config (`src/gateway/gateway.test.ts`). +- Mock-виклик інструментів через реальні gateway + цикл агента (`src/gateway/gateway.test.ts`). +- Наскрізні потоки майстра, які перевіряють зв’язування сесії та ефекти конфігурації (`src/gateway/gateway.test.ts`). -Чого ще бракує для skills (див. [Skills](/uk/tools/skills)): +Чого досі бракує для skills (див. [Skills](/uk/tools/skills)): - **Ухвалення рішень:** коли skills перелічені в prompt, чи вибирає агент правильний skill (або уникає нерелевантних)? - **Відповідність вимогам:** чи читає агент `SKILL.md` перед використанням і чи виконує потрібні кроки/аргументи? -- **Контракти workflow:** багатокрокові сценарії, що перевіряють порядок інструментів, перенесення історії сесії та межі sandbox. +- **Контракти workflow:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сесії та межі sandbox. -Майбутні оцінювання мають насамперед залишатися детермінованими: +Майбутні eval-и мають передусім залишатися детермінованими: -- Runner сценаріїв із mock providers для перевірки викликів інструментів + порядку, читання skill-файлів і зв’язування сесій. -- Невеликий набір сценаріїв, зосереджених на skills (використати чи уникнути, gating, prompt injection). -- Необов’язкові live evals (opt-in, через env-gate) лише після появи безпечного для CI набору. +- Runner сценаріїв із mock-провайдерами для перевірки викликів інструментів + порядку, читання файлів skill і зв’язування сесії. +- Невеликий набір сценаріїв, сфокусованих на skill (використовувати чи уникати, gating, prompt injection). +- Необов’язкові live eval-и (opt-in, gated через env) лише після появи безпечного для CI набору. -## Контрактні тести (форма plugin і channel) +## Контрактні тести (форма plugin і каналу) -Контрактні тести перевіряють, що кожен зареєстрований plugin і channel відповідає своєму -interface contract. Вони ітерують усі виявлені plugins і запускають набір -перевірок форми та поведінки. Типова unit lane `pnpm test` навмисно +Контрактні тести перевіряють, що кожен зареєстрований plugin і канал відповідає своєму +інтерфейсному контракту. Вони проходять по всіх виявлених plugins і запускають набір +перевірок форми та поведінки. Стандартна unit-lane `pnpm test` навмисно пропускає ці спільні seam- і smoke-файли; запускайте контрактні команди явно, -коли змінюєте спільні поверхні channel або provider. +коли змінюєте спільні поверхні каналів або провайдерів. ### Команди - Усі контракти: `pnpm test:contracts` -- Лише контракти channel: `pnpm test:contracts:channels` -- Лише контракти provider: `pnpm test:contracts:plugins` +- Лише контракти каналів: `pnpm test:contracts:channels` +- Лише контракти провайдерів: `pnpm test:contracts:plugins` -### Контракти channel +### Контракти каналів Розташовані в `src/channels/plugins/contracts/*.contract.test.ts`: @@ -777,51 +779,51 @@ interface contract. Вони ітерують усі виявлені plugins і - **session-binding** - Поведінка зв’язування сесії - **outbound-payload** - Структура payload повідомлення - **inbound** - Обробка вхідних повідомлень -- **actions** - Обробники дій channel +- **actions** - Обробники дій каналу - **threading** - Обробка ID thread -- **directory** - Directory/roster API +- **directory** - API каталогу/roster - **group-policy** - Застосування групової політики -### Контракти статусу provider +### Контракти статусу провайдера Розташовані в `src/plugins/contracts/*.contract.test.ts`. -- **status** - Проби статусу channel -- **registry** - Форма registry plugin +- **status** - Проби статусу каналу +- **registry** - Форма реєстру Plugin -### Контракти provider +### Контракти провайдерів Розташовані в `src/plugins/contracts/*.contract.test.ts`: -- **auth** - Контракт потоку auth -- **auth-choice** - Вибір/selection auth +- **auth** - Контракт потоку автентифікації +- **auth-choice** - Вибір автентифікації - **catalog** - API каталогу моделей -- **discovery** - Виявлення plugin -- **loader** - Завантаження plugin -- **runtime** - Runtime provider -- **shape** - Форма/interface plugin +- **discovery** - Виявлення Plugin +- **loader** - Завантаження Plugin +- **runtime** - Runtime провайдера +- **shape** - Форма/інтерфейс Plugin - **wizard** - Майстер налаштування ### Коли запускати -- Після зміни exports або subpaths plugin-sdk -- Після додавання або змінення channel чи provider plugin -- Після рефакторингу реєстрації або виявлення plugin +- Після зміни експортів або subpaths plugin-sdk +- Після додавання або зміни каналу чи provider plugin +- Після рефакторингу реєстрації або виявлення Plugin -Контрактні тести запускаються в CI і не потребують реальних API keys. +Контрактні тести запускаються в CI і не потребують реальних API-ключів. -## Додавання регресій (настанови) +## Додавання регресій (рекомендації) -Коли ви виправляєте проблему provider/model, виявлену наживо: +Коли ви виправляєте проблему провайдера/моделі, виявлену в live: -- Додайте безпечну для CI регресію, якщо можливо (mock/stub provider або зафіксуйте точну трансформацію request-shape) -- Якщо це невіддільно live-only (обмеження rate limits, політики auth), тримайте live test вузьким і opt-in через env vars -- Надавайте перевагу найменшому шару, який ловить bug: - - bug конвертації/відтворення запиту provider → прямий тест models - - bug pipeline сесії/історії/інструментів gateway → gateway live smoke або безпечний для CI mock-тест gateway -- Запобіжник обходу SecretRef: - - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибрану ціль на клас SecretRef із metadata registry (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec ids із traversal-сегментами відхиляються. - - Якщо ви додаєте нову сім’ю цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target ids, щоб нові класи не можна було тихо пропустити. +- Додайте безпечну для CI регресію, якщо можливо (mock/stub провайдера або зафіксуйте точне перетворення форми запиту) +- Якщо це за своєю суттю лише live-проблема (обмеження частоти, політики автентифікації), тримайте live-тест вузьким і opt-in через env vars +- Надавайте перевагу найменшому шару, який ловить баг: + - баг перетворення/відтворення запиту провайдера → прямий тест моделей + - баг pipeline сесії/історії/інструментів gateway → live smoke gateway або безпечний для CI mock-тест gateway +- Guardrail обходу SecretRef: + - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль для кожного класу SecretRef з метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id із traversal-сегментами відхиляються. + - Якщо ви додаєте нову цільову родину SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target id, щоб нові класи не можна було тихо пропустити. ## Пов’язане