diff --git a/docs/uk/ci.md b/docs/uk/ci.md index b1918af76..678359cc6 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,141 +1,142 @@ --- read_when: - - Вам потрібно зрозуміти, чому завдання CI було або не було запущене - - Ви налагоджуєте перевірки GitHub Actions, що не проходять -summary: Граф завдань CI, перевірки за областю та локальні еквіваленти команд + - Потрібно зрозуміти, чому завдання CI було або не було запущено + - Ви налагоджуєте перевірки GitHub Actions, які завершуються невдало +summary: Граф завдань CI, контрольні перевірки області дії та локальні еквіваленти команд title: CI-конвеєр x-i18n: - generated_at: "2026-04-29T06:43:32Z" + generated_at: "2026-04-29T07:27:26Z" model: gpt-5.5 provider: openai - source_hash: 0b6d5c683789fde45995dbab11307cecc7d601d341ab0926ec42703fc0a912ed + source_hash: a804984bbffc5377d69aed508c83ef63e82b86e5ecbc24633a1dd2bbdb4ab4b3 source_path: ci.md workflow: 16 --- -CI запускається на кожен push до `main` і кожен pull request. Він використовує розумне обмеження області, щоб пропускати дорогі завдання, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області й розгортають повний звичайний граф CI для кандидатів на реліз або широкої валідації, з Android-гілками, що вмикаються через `include_android` для окремих ручних запусків. Prerelease-гілки плагінів лише для релізу залишаються вимкненими, якщо `Full Release Validation` не запускає CI з `full_release_validation=true`, що також вмикає Android. +CI запускається під час кожного push до `main` і кожного pull request. Він використовує розумне обмеження області, щоб пропускати дорогі завдання, коли змінилися лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області й розгортають повний звичайний граф CI для реліз-кандидатів або широкої валідації, а Android-ланцюжки вмикаються через `include_android` для окремих ручних запусків. Ланцюжки попереднього релізу Plugin, призначені лише для релізів, містяться в окремому workflow `Plugin Prerelease` і запускаються лише з `Full Release Validation` або явного ручного dispatch. -`Full Release Validation` — це ручний парасольковий workflow для «запустити все -перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний -workflow `CI` із цією ціллю та запускає `OpenClaw Release Checks` для install smoke, -package acceptance, Docker-наборів за релізним шляхом, live/E2E, OpenWebUI, -паритету QA Lab, Matrix і Telegram-гілок. Він також може запускати post-publish -workflow `NPM Telegram Beta E2E`, коли надано специфікацію опублікованого пакета. -`release_profile=minimum|stable|full` керує широтою live/provider, що передається -до release checks: `minimum` залишає найшвидші критичні для релізу гілки OpenAI/core, -`stable` додає стабільний набір provider/backend, а `full` запускає широку -рекомендаційну матрицю provider/media. Парасольковий workflow записує id -запущених дочірніх run, а фінальне завдання `Verify full validation` повторно -перевіряє поточні висновки дочірніх run і додає таблиці найповільніших завдань -для кожного дочірнього run. Якщо дочірній workflow перезапущено й він став зеленим, -перезапустіть лише батьківське verifier-завдання, щоб оновити результат -парасолькового workflow і підсумок часу виконання. +`Full Release Validation` — це ручний парасольковий workflow для "запустити все +перед релізом." Він приймає branch, tag або повний commit SHA, dispatch-ить +ручний workflow `CI` із цією ціллю, dispatch-ить `Plugin Prerelease` для +release-only доказу plugin/package/static/Docker, і dispatch-ить +`OpenClaw Release Checks` для install smoke, package acceptance, Docker +release-path наборів, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram +ланцюжків. Він також може запускати післяпублікаційний workflow `NPM Telegram Beta E2E`, коли +надано специфікацію опублікованого пакета. `release_profile=minimum|stable|full` керує live/provider +шириною, переданою в release checks: `minimum` зберігає найшвидші OpenAI/core +критично важливі для релізу ланцюжки, `stable` додає стабільний набір provider/backend, а +`full` запускає широку рекомендаційну матрицю provider/media. Парасолька записує +ідентифікатори dispatch-нутих дочірніх запусків, а фінальне завдання `Verify full validation` повторно перевіряє +поточні висновки дочірніх запусків і додає таблиці найповільніших завдань для кожного дочірнього +запуску. Якщо дочірній workflow перезапущено й він став зеленим, перезапустіть лише батьківське +завдання verifier, щоб оновити результат парасольки та підсумок часу. Для відновлення `Full Release Validation` і `OpenClaw Release Checks` обидва -приймають `rerun_group`. Використовуйте `all` для кандидата на реліз, `ci` лише -для звичайного дочірнього full CI, `release-checks` для кожного релізного дочірнього -workflow або вужчу релізну групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, -`qa`, `qa-parity`, `qa-live` або `npm-telegram` у парасольковому workflow. Це -утримує перезапуск невдалого релізного середовища в межах після цільового виправлення. +приймають `rerun_group`. Використовуйте `all` для реліз-кандидата, `ci` лише для +звичайного повного дочірнього CI, `release-checks` для кожного дочірнього релізного workflow або вужчу +релізну групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, +`qa-parity`, `qa-live` або `npm-telegram` у парасольці. Це утримує повторний запуск невдалого +релізного бокса в межах після сфокусованого виправлення. Дочірній release live/E2E зберігає широке нативне покриття `pnpm test:live`, але -запускає його як іменовані shards (`native-live-src-agents`, -`native-live-src-gateway-core`, відфільтровані за provider завдання -`native-live-src-gateway-profiles`, `native-live-src-gateway-backends`, -`native-live-test`, `native-live-extensions-a-k`, `native-live-extensions-l-n`, +запускає його як іменовані шарди (`native-live-src-agents`, +`native-live-src-gateway-core`, відфільтровані за provider +завдання `native-live-src-gateway-profiles`, +`native-live-src-gateway-backends`, `native-live-test`, +`native-live-extensions-a-k`, `native-live-extensions-l-n`, `native-live-extensions-openai`, `native-live-extensions-o-z-other`, -`native-live-extensions-xai`, розділені media audio/video shards і відфільтровані -за provider music shards) через `scripts/test-live-shard.mjs` замість одного -послідовного завдання. Це зберігає те саме файлове покриття, водночас полегшуючи -перезапуск і діагностику повільних live-збоїв provider. Агреговані назви shards -`native-live-extensions-o-z`, `native-live-extensions-media` і -`native-live-extensions-media-music` залишаються чинними для ручних одноразових -перезапусків. +`native-live-extensions-xai`, розділені медіа-шарди audio/video, і +відфільтровані за provider музичні шарди) через `scripts/test-live-shard.mjs` замість +одного послідовного завдання. Це зберігає те саме покриття файлів, водночас роблячи повільні live +збої provider простішими для повторного запуску й діагностики. Агреговані +назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і +`native-live-extensions-media-music` залишаються дійсними для ручних +одноразових повторних запусків. -Нативні live media shards запускаються в +Нативні live media шарди запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow -`Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; -media-завдання лише перевіряють бінарні файли перед налаштуванням. Тримайте -Docker-backed live suites на звичайних Blacksmith runners, бо container jobs — -невідповідне місце для запуску вкладених Docker-тестів. +`Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і +`ffprobe`; media-завдання лише перевіряють binaries перед setup. Тримайте live-набори з Docker +на звичайних Blacksmith runners, бо container jobs — неправильне місце +для запуску вкладених Docker tests. -Docker-backed live model/backend shards використовують окремий спільний образ -`ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Live -release workflow збирає та публікує цей образ один раз, після чого Docker live model, -gateway, CLI backend, ACP bind і Codex harness shards запускаються з -`OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці shards незалежно перебудовують повну -source Docker target, release run налаштовано неправильно, і він марнуватиме -час на дубльовані збірки образів. +Live model/backend шарди з Docker використовують окремий спільний +образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Live +release workflow збирає й пушить цей образ один раз, потім Docker live model, +gateway, CLI backend, ACP bind і Codex harness шарди запускаються з +`OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці шарди незалежно перебудовують повну source Docker +ціль, release run налаштовано неправильно, і він марнуватиме wall +clock на дубльовані image builds. -`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз -розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає -цей артефакт і до live/E2E Docker workflow релізного шляху, і до package acceptance -shard. Це зберігає байти пакета узгодженими між релізними середовищами й уникає -повторного пакування того самого кандидата в кількох дочірніх завданнях. +`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз розв’язати вибраний +ref у tarball `release-package-under-test`, потім передає цей artifact +і до live/E2E release-path Docker workflow, і до package acceptance +shard. Це зберігає package bytes узгодженими між release boxes і уникає +повторного пакування того самого кандидата в кількох дочірніх jobs. -`Package Acceptance` — це side-run workflow для валідації артефакта пакета без -блокування release workflow. Він розв’язує одного кандидата з опублікованої npm -специфікації, довіреного `package_ref`, зібраного з вибраним harness -`workflow_ref`, HTTPS URL tarball із SHA-256 або tarball artifact з іншого GitHub -Actions run, вивантажує його як `package-under-test`, а потім повторно використовує -Docker release/E2E scheduler із цим tarball замість повторного пакування workflow -checkout. Профілі покривають smoke, package, product, full і custom вибори Docker -lanes. Профіль `package` використовує offline-покриття плагінів, щоб валідація -опублікованого пакета не залежала від доступності live ClawHub. Додаткова -Telegram-гілка повторно використовує артефакт `package-under-test` у workflow -`NPM Telegram Beta E2E`, а шлях опублікованої npm специфікації зберігається для -окремих dispatch-запусків. +`Package Acceptance` — це side-run workflow для валідації artifact пакета +без блокування release workflow. Він розв’язує одного кандидата з +published npm spec, trusted `package_ref`, зібраного вибраним +`workflow_ref` harness, HTTPS tarball URL із SHA-256 або tarball artifact +з іншого GitHub Actions run, завантажує його як `package-under-test`, потім повторно використовує +Docker release/E2E scheduler із цим tarball замість перепакування +workflow checkout. Профілі охоплюють smoke, package, product, full і custom +вибори Docker lane. Профіль `package` використовує offline plugin coverage, щоб +валідація опублікованого пакета не залежала від live доступності ClawHub. Опціональний +Telegram lane повторно використовує artifact +`package-under-test` у workflow `NPM Telegram Beta E2E`, а шлях +published npm spec збережено для standalone dispatches. -## Приймальне тестування пакета +## Приймання пакета -Використовуйте `Package Acceptance`, коли питання звучить як «чи працює цей -інстальований пакет OpenClaw як продукт?» Це відрізняється від звичайного CI: -звичайний CI валідує дерево source, тоді як package acceptance валідує один -tarball через той самий Docker E2E harness, яким користувачі користуються після -інсталяції або оновлення. +Використовуйте `Package Acceptance`, коли питання звучить так: "чи працює цей встановлюваний пакет OpenClaw +як продукт?" Це відрізняється від звичайного CI: звичайний CI валідовує +дерево source, тоді як package acceptance валідовує один tarball через +той самий Docker E2E harness, який користувачі задіюють після встановлення або оновлення. -Workflow має чотири завдання: +Workflow має чотири jobs: -1. `resolve_package` checkout-ить `workflow_ref`, розв’язує одного кандидата пакета, +1. `resolve_package` checkout-ить `workflow_ref`, розв’язує одного package candidate, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує - `.artifacts/docker-e2e-package/package-candidate.json`, вивантажує обидва як - артефакт `package-under-test` і друкує джерело, workflow ref, package ref, - версію, SHA-256 і профіль у GitHub step summary. + `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як + artifact `package-under-test` і виводить source, workflow ref, package + ref, version, SHA-256 і profile у GitHub step summary. 2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і - `package_artifact_name=package-under-test`. Reusable workflow завантажує цей - артефакт, валідує інвентар tarball, готує package-digest Docker images, коли - потрібно, і запускає вибрані Docker lanes проти цього пакета замість пакування - workflow checkout. Коли профіль вибирає кілька цільових `docker_lanes`, reusable - workflow готує пакет і спільні images один раз, а потім розгортає ці lanes як - паралельні цільові Docker jobs з унікальними артефактами. -3. `package_telegram` додатково викликає `NPM Telegram Beta E2E`. Він запускається, - коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт - `package-under-test`, коли Package Acceptance розв’язав один; окремий Telegram - dispatch усе ще може встановити опубліковану npm специфікацію. -4. `summary` завершує workflow з помилкою, якщо package resolution, Docker acceptance - або додаткова Telegram-гілка завершилися невдало. + `package_artifact_name=package-under-test`. Reusable workflow завантажує + цей artifact, валідовує інвентар tarball, готує package-digest + Docker images за потреби й запускає вибрані Docker lanes проти цього + package замість пакування workflow checkout. Коли profile вибирає + кілька цільових `docker_lanes`, reusable workflow готує package + і shared images один раз, а потім розгортає ці lanes як паралельні targeted Docker + jobs з унікальними artifacts. +3. `package_telegram` опціонально викликає `NPM Telegram Beta E2E`. Він запускається, коли + `telegram_mode` не `none`, і встановлює той самий artifact `package-under-test`, + коли Package Acceptance розв’язав його; standalone Telegram dispatch + все ще може встановити published npm spec. +4. `summary` провалює workflow, якщо package resolution, Docker acceptance або + опціональний Telegram lane зазнали невдачі. Джерела кандидатів: -- `source=npm`: приймає лише `openclaw@beta`, `openclaw@latest` або точну версію - релізу OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для - приймального тестування опублікованих beta/stable. -- `source=ref`: пакує довірений `package_ref` branch, tag або повний commit SHA. - Resolver отримує branches/tags OpenClaw, перевіряє, що вибраний commit досяжний - з історії гілок репозиторію або release tag, встановлює deps у detached worktree - і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. -- `source=url`: завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим. -- `source=artifact`: завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; - `package_sha256` необов’язковий, але його варто надати для зовнішньо поширених - артефактів. +- `source=npm`: приймає лише `openclaw@beta`, `openclaw@latest` або точну + release version OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для + published beta/stable acceptance. +- `source=ref`: пакує trusted branch, tag або full commit SHA `package_ref`. + Resolver fetch-ить OpenClaw branches/tags, перевіряє, що вибраний commit + reachable з repository branch history або release tag, встановлює deps у + detached worktree і пакує його через `scripts/package-openclaw-for-docker.mjs`. +- `source=url`: завантажує HTTPS `.tgz`; `package_sha256` обов’язковий. +- `source=artifact`: завантажує один `.tgz` з `artifact_run_id` і + `artifact_name`; `package_sha256` опціональний, але його варто надати для + externally shared artifacts. -Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений -workflow/harness code, який запускає тест. `package_ref` — це source commit, який -пакується, коли `source=ref`. Це дає поточному test harness змогу валідувати старіші -довірені source commits без запуску старої workflow logic. +Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це trusted +workflow/harness code, який запускає test. `package_ref` — це source commit, +який пакується, коли `source=ref`. Це дає змогу поточному test harness валідовувати +старіші trusted source commits без запуску старої workflow logic. -Профілі відповідають Docker-покриттю: +Профілі відображаються на Docker coverage: - `smoke`: `npm-onboard-channel-agent`, `gateway-network`, `config-reload` - `package`: `npm-onboard-channel-agent`, `doctor-switch`, @@ -143,37 +144,37 @@ workflow/harness code, який запускає тест. `package_ref` — ц `plugin-update` - `product`: `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` -- `full`: повні Docker chunks релізного шляху з OpenWebUI -- `custom`: точні `docker_lanes`; обов’язково, коли `suite_profile=custom` +- `full`: повні Docker release-path chunks з OpenWebUI +- `custom`: точні `docker_lanes`; обов’язковий, коли `suite_profile=custom` -Release checks викликають Package Acceptance із `source=ref`, +Release checks викликають Package Acceptance з `source=ref`, `package_ref=`, `workflow_ref=`, `suite_profile=custom`, `docker_lanes='bundled-channel-deps-compat plugins-offline'` і -`telegram_mode=mock-openai`. Docker chunks релізного шляху покривають перетин -package/update/plugin lanes, тоді як Package Acceptance зберігає artifact-native -proof для bundled-channel compat, offline plugin і Telegram проти того самого -розв’язаного package tarball. -Cross-OS release checks усе ще покривають OS-specific onboarding, installer і -platform behavior; product validation для package/update слід починати з Package +`telegram_mode=mock-openai`. Release-path Docker +chunks покривають overlapping package/update/plugin lanes, а Package +Acceptance зберігає artifact-native bundled-channel compat, offline plugin і +Telegram proof проти того самого розв’язаного package tarball. +Cross-OS release checks все ще покривають OS-specific onboarding, installer і +platform behavior; package/update product validation має починатися з Package Acceptance. Windows packaged і installer fresh lanes також перевіряють, що -встановлений пакет може імпортувати browser-control override із сирого абсолютного +встановлений package може import browser-control override з raw absolute Windows path. -Package Acceptance має обмежені legacy-compatibility windows для вже опублікованих -пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть -використовувати compatibility path для відомих private QA entries у -`dist/postinstall-inventory.json`, які вказують на файли, пропущені в tarball, +Package Acceptance має обмежені legacy-compatibility windows для вже +published packages. Packages до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, +можуть використовувати compatibility path для відомих private QA entries у +`dist/postinstall-inventory.json`, які вказують на tarball-omitted files, `doctor-switch` може пропускати підвипадок persistence `gateway install --wrapper`, -коли пакет не exposes цей flag, `update-channel-switch` може prune відсутні -`pnpm.patchedDependencies` з tarball-derived fake git fixture і може логувати -відсутній persisted `update.channel`, plugin smokes можуть читати legacy -install-record locations або приймати відсутню marketplace install-record -persistence, а `plugin-update` може дозволяти config metadata migration, водночас -і далі вимагаючи, щоб install record і no-reinstall behavior лишалися незмінними. -Опублікований пакет `2026.4.26` також може попереджати про local build metadata -stamp files, які вже були shipped. Пізніші пакети мають відповідати сучасним -contracts; ті самі умови спричиняють failure замість warning або skip. +коли package не exposes that flag, `update-channel-switch` може prune +відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і +може логувати missing persisted `update.channel`, plugin smokes можуть read legacy +install-record locations або accept missing marketplace install-record +persistence, а `plugin-update` може allow config metadata migration, водночас все ще +вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними. Published +package `2026.4.26` також може warn for local build metadata stamp files, +які вже були shipped. Пізніші packages мають задовольняти modern contracts; ті +самі conditions fail замість warn або skip. Приклади: @@ -216,120 +217,125 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Під час налагодження невдалого package acceptance run починайте з summary -`resolve_package`, щоб підтвердити package source, version і SHA-256. Потім -перегляньте дочірній run `docker_acceptance` і його Docker artifacts: +Під час налагодження невдалого package acceptance run почніть із summary `resolve_package`, +щоб підтвердити package source, version і SHA-256. Потім перевірте +дочірній run `docker_acceptance` і його Docker artifacts: `.artifacts/docker-tests/**/summary.json`, `failures.json`, lane logs, phase -timings і rerun commands. Віддавайте перевагу перезапуску failed package profile -або точних Docker lanes замість повторного запуску full release validation. +timings і rerun commands. Надавайте перевагу повторному запуску невдалого package profile або +точних Docker lanes замість повторного запуску full release validation. -QA Lab має окремі CI-доріжки поза основним workflow з розумним обмеженням за областю змін. Workflow -`Parity gate` запускається для відповідних змін у PR і вручну; він -збирає приватне QA runtime-середовище та порівнює mock GPT-5.5 і Opus 4.6 -агентні пакети. Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і -вручну; він розгалужує mock parity gate, live Matrix-доріжку, а також live -Telegram і Discord-доріжки як паралельні завдання. Live-завдання використовують -середовище `qa-live-shared`, а Telegram/Discord використовують оренди Convex. Release -checks запускають live transport-доріжки Matrix і Telegram із детермінованим mock -провайдером і mock-кваліфікованими моделями (`mock-openai/gpt-5.5` і -`mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримок live-моделі -та звичайного запуску Plugin провайдера. Live transport gateway також -вимикає пошук у пам’яті, бо QA parity окремо покриває поведінку пам’яті; -підключення провайдера покривається окремими наборами live model, native provider -і Docker provider. Matrix використовує `--profile fast` для запланованих і release gates, -додаючи `--fail-fast` лише тоді, коли перевірений CLI це підтримує. Типове значення CLI -і ручний ввід workflow залишаються `all`; ручний dispatch `matrix_profile=all` -завжди розбиває повне покриття Matrix на завдання `transport`, `media`, +QA Lab має окремі лінії CI поза основним розумно обмеженим workflow. Workflow +`Parity gate` запускається для відповідних змін у PR і ручного dispatch; він +збирає приватний runtime QA та порівнює mock agentic-пакети GPT-5.5 і Opus 4.6. +Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і за +ручним dispatch; він розгортає mock parity gate, live-лінію Matrix, а також live +лінії Telegram і Discord як паралельні jobs. Live jobs використовують +середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases. Release +checks запускають live transport-лінії Matrix і Telegram із deterministic mock +provider і mock-qualified моделями (`mock-openai/gpt-5.5` та +`mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live model +і звичайного запуску provider-plugin. Live transport gateway також +вимикає пошук у памʼяті, оскільки QA parity окремо покриває поведінку памʼяті; +підключення provider покривають окремі live model, native provider +і Docker provider набори. Matrix використовує `--profile fast` для scheduled і release gates, +додаючи `--fail-fast` лише коли checked-out CLI це підтримує. Стандарт CLI +і ручний workflow input залишаються `all`; ручний dispatch `matrix_profile=all` +завжди ділить повне покриття Matrix на jobs `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` також -запускає критичні для релізу QA Lab-доріжки перед затвердженням релізу; його QA parity -gate запускає candidate і baseline пакети як паралельні завдання доріжок, а потім завантажує -обидва артефакти в невелике звітне завдання для фінального порівняння parity. -Не ставте шлях приземлення PR за `Parity gate`, якщо зміна фактично не -торкається QA runtime, parity пакетів моделей або поверхні, якою володіє parity workflow. -Для звичайних виправлень каналів, конфігурації, документації або unit-тестів розглядайте це як необов’язковий -сигнал і спирайтеся на scoped CI/check докази. +запускає release-critical лінії QA Lab перед release approval; його QA parity +gate запускає candidate і baseline пакети як паралельні lane jobs, потім завантажує +обидва artifacts у невеликий report job для фінального parity comparison. +Не ставте шлях landing PR за `Parity gate`, якщо зміна фактично не +торкається QA runtime, model-pack parity або поверхні, якою володіє parity workflow. +Для звичайних виправлень channel, config, docs або unit-test трактуйте його як optional +signal і натомість дотримуйтеся scoped CI/check evidence. -Workflow `Duplicate PRs After Merge` — це ручний workflow для мейнтейнерів для -очищення дублікатів після приземлення. За замовчуванням він працює в dry-run і закриває лише явно -перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що -приземлений PR змерджено і що кожен дублікат має або спільну згадану issue, -або перетин у змінених hunks. +Workflow `Duplicate PRs After Merge` є ручним workflow для maintainers для +post-land очищення дублікатів. За замовчуванням він працює в dry-run і закриває лише явно +перелічені PR, коли `apply=true`. Перед зміною GitHub він перевіряє, що +landed PR merged і що кожен дублікат має або спільний referenced issue, +або перетин changed hunks. -Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, -а не повним проходом усього репозиторію. Щоденні та ручні запуски сканують код Actions workflow -плюс найризикованіші JavaScript/TypeScript-поверхні auth, secrets, sandbox, cron і -gateway за допомогою високоточних security queries. Завдання -channel-runtime-boundary окремо сканує контракти реалізації core channel -плюс runtime Plugin каналу, gateway, Plugin SDK, secrets і +Workflow `CodeQL` навмисно є вузьким першим проходом security scanner, +а не повним скануванням репозиторію. Щоденні й ручні запуски сканують код Actions workflow +плюс найризикованіші JavaScript/TypeScript поверхні auth, secrets, sandbox, cron і +gateway з high-precision security queries. Job +channel-runtime-boundary окремо сканує core channel implementation +contracts плюс channel plugin runtime, gateway, Plugin SDK, secrets і audit touchpoints у категорії `/codeql-critical-security/channel-runtime-boundary`, -щоб сигнал безпеки каналу міг масштабуватися без розширення базової -JS/TS-категорії. +щоб channel security signal міг масштабуватися без розширення baseline +JS/TS category. -Workflow `CodeQL Android Critical Security` — це запланований Android -security shard. Він збирає Android app вручну для CodeQL на найменшій -мітці Blacksmith Linux runner, яку приймає workflow sanity, і завантажує результати +Workflow `CodeQL Android Critical Security` є scheduled Android +security shard. Він збирає Android app вручну для CodeQL на найменшому +Blacksmith Linux runner label, прийнятому workflow sanity, і завантажує результати в категорію `/codeql-critical-security/android`. -Workflow `CodeQL macOS Critical Security` — це щотижневий/ручний macOS +Workflow `CodeQL macOS Critical Security` є щотижневим/ручним macOS security shard. Він збирає macOS app вручну для CodeQL на Blacksmith macOS, -фільтрує результати збірки залежностей із завантажуваного SARIF і завантажує результати +відфільтровує dependency build results із завантаженого SARIF і завантажує результати в категорію `/codeql-critical-security/macos`. Тримайте його поза щоденним -типовим workflow, бо macOS-збірка домінує в часі виконання навіть коли все чисто. +default workflow, бо macOS build домінує runtime навіть коли він чистий. -Workflow `CodeQL Critical Quality` — це відповідний не-security shard. Він -запускає лише JavaScript/TypeScript quality queries із severity error і без security -на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його -завдання core-auth-secrets сканує auth, secrets, sandbox, cron і gateway security +Workflow `CodeQL Critical Quality` є відповідним non-security shard. Він +запускає лише error-severity, non-security JavaScript/TypeScript quality queries +на вузьких high-value поверхнях на меншому Blacksmith Linux runner. Його +job core-auth-secrets сканує auth, secrets, sandbox, cron і gateway security boundary code в окремій категорії `/codeql-critical-quality/core-auth-secrets`. -Завдання config-boundary -сканує config schema, migration, normalization і IO contracts в окремій -категорії `/codeql-critical-quality/config-boundary`. Завдання +Job config-boundary +сканує config schema, migration, normalization і IO contracts в +окремій категорії `/codeql-critical-quality/config-boundary`. Job gateway-runtime-boundary сканує gateway protocol schemas і server method contracts в окремій категорії -`/codeql-critical-quality/gateway-runtime-boundary`. Завдання +`/codeql-critical-quality/gateway-runtime-boundary`. Job channel-runtime-boundary сканує core channel implementation contracts в -окремій категорії `/codeql-critical-quality/channel-runtime-boundary`. Завдання +окремій категорії `/codeql-critical-quality/channel-runtime-boundary`. Job agent-runtime-boundary сканує command execution, model/provider dispatch, -auto-reply dispatch and queues, а також ACP control-plane runtime contracts в -окремій категорії `/codeql-critical-quality/agent-runtime-boundary`. Завдання -mcp-process-runtime-boundary сканує MCP servers and tool bridges, process +auto-reply dispatch і queues, а також ACP control-plane runtime contracts в +окремій категорії `/codeql-critical-quality/agent-runtime-boundary`. Job +mcp-process-runtime-boundary сканує MCP servers і tool bridges, process supervision helpers і outbound delivery contracts в окремій -категорії `/codeql-critical-quality/mcp-process-runtime-boundary`. Завдання +категорії `/codeql-critical-quality/mcp-process-runtime-boundary`. Job +memory-runtime-boundary сканує memory host SDK, memory runtime facades, +memory Plugin SDK aliases, memory runtime activation glue і memory doctor +commands в окремій категорії `/codeql-critical-quality/memory-runtime-boundary`. +Job ui-control-plane сканує Control UI bootstrap, local persistence, gateway control flows і task control-plane runtime contracts в окремій -категорії `/codeql-critical-quality/ui-control-plane`. Завдання +категорії `/codeql-critical-quality/ui-control-plane`. Job web-media-runtime-boundary сканує core web fetch/search, media IO, media -understanding, image-generation і media-generation runtime contracts в окремій категорії `/codeql-critical-quality/web-media-runtime-boundary`. Завдання +understanding, image-generation і media-generation runtime contracts в +окремій категорії `/codeql-critical-quality/web-media-runtime-boundary`. Job plugin-boundary сканує loader, registry, public-surface і Plugin SDK entrypoint contracts в окремій категорії `/codeql-critical-quality/plugin-boundary`. Тримайте workflow окремо від security, щоб quality findings можна було -планувати, вимірювати, вимикати або розширювати без затемнення security signal. -Розширення CodeQL для Swift, Python і bundled-plugin слід додавати назад як -scoped або sharded подальшу роботу лише після того, як вузькі профілі матимуть стабільні +планувати, вимірювати, вимикати або розширювати без затінення security signal. +Розширення Swift, Python і bundled-plugin CodeQL слід додавати назад як +scoped або sharded follow-up work лише після того, як narrow profiles матимуть стабільні runtime і signal. -Workflow `Docs Agent` — це подієва maintenance-доріжка Codex для підтримання -наявної документації узгодженою з нещодавно приземленими змінами. Вона не має чистого розкладу: -успішний non-bot push CI run на `main` може її запустити, а ручний dispatch може -запустити її напряму. Workflow-run invocations пропускаються, коли `main` уже змістився або коли -інший non-skipped Docs Agent run було створено за останню годину. Коли він запускається, він +Workflow `Docs Agent` є event-driven Codex maintenance lane для підтримання +наявних docs у відповідності до нещодавно landed changes. Він не має pure schedule: +успішний non-bot push CI run на `main` може його запустити, а manual dispatch може +запустити його напряму. Workflow-run invocations пропускаються, коли `main` уже просунувся далі або коли +інший non-skipped Docs Agent run був створений за останню годину. Коли він запускається, він переглядає commit range від попереднього non-skipped Docs Agent source SHA до -поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені після -останнього проходу документації. +поточного `main`, тож один hourly run може покрити всі main changes, накопичені з +останнього docs pass. -Workflow `Test Performance Agent` — це подієва maintenance-доріжка Codex -для повільних тестів. Вона не має чистого розкладу: успішний non-bot push CI run на -`main` може її запустити, але вона пропускається, якщо інший workflow-run invocation уже -запускався або виконується цього UTC-дня. Ручний dispatch обходить цей щоденний activity -gate. Доріжка будує grouped Vitest performance report для повного набору, дозволяє Codex -вносити лише невеликі performance-виправлення тестів зі збереженням покриття замість широких -рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, що зменшують -baseline кількість успішних тестів. Якщо baseline має failing tests, Codex може виправляти -лише очевидні failures, і after-agent full-suite report має пройти перед -будь-яким комітом. Коли `main` просувається до приземлення bot push, доріжка -ребейзить перевірений patch, повторно запускає `pnpm check:changed` і повторює push; -конфліктні застарілі patches пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб Codex -action міг зберегти ту саму drop-sudo safety posture, що й docs agent. +Workflow `Test Performance Agent` є event-driven Codex maintenance lane +для повільних тестів. Він не має pure schedule: успішний non-bot push CI run на +`main` може його запустити, але він пропускається, якщо інший workflow-run invocation уже +запускався або виконується цього UTC day. Manual dispatch обходить цей daily activity +gate. Лінія будує full-suite grouped Vitest performance report, дозволяє Codex +робити лише невеликі coverage-preserving test performance fixes замість broad +refactors, потім повторно запускає full-suite report і відхиляє зміни, що зменшують +passing baseline test count. Якщо baseline має failing tests, Codex може виправляти +лише очевидні failures, а after-agent full-suite report має пройти, перш ніж +щось буде committed. Коли `main` просувається до того, як bot push landed, лінія +перебазовує validated patch, повторно запускає `pnpm check:changed` і повторює push; +conflicting stale patches пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб Codex +action міг зберігати таку саму drop-sudo safety posture, як docs agent. ```bash gh workflow run duplicate-after-merge.yml \ @@ -338,43 +344,43 @@ gh workflow run duplicate-after-merge.yml \ -f apply=true ``` -## Огляд завдань +## Огляд jobs -| Завдання | Призначення | Коли запускається | +| Job | Призначення | Коли запускається | | -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- | -| `preflight` | Виявляє зміни лише в документації, змінені області, змінені extensions і будує CI manifest | Завжди на non-draft push і PR | -| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди на non-draft push і PR | -| `security-dependency-audit` | Аудит production lockfile без залежностей щодо npm advisories | Завжди на non-draft push і PR | -| `security-fast` | Обов’язковий агрегат для швидких security jobs | Завжди на non-draft push і PR | -| `build-artifacts` | Збірка `dist/`, Control UI, перевірки built-artifact і 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-extensions` | Повні shards тестів bundled-plugin у всьому extension suite | Зміни, релевантні для Node | -| `checks-node-core-test` | Core Node test shards, окрім channel, bundled, contract і extension lanes | Зміни, релевантні для Node | -| `check` | Sharded еквівалент основного local 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` | Верифікатор для built-artifact channel tests | Зміни, релевантні для Node | -| `checks-node-compat-node22` | Node 22 compatibility build і smoke lane | Ручний CI dispatch для релізів | -| `plugin-prerelease-suite` | Агрегат для plugin prerelease static checks і Docker product lanes | Full Release Validation CI child | -| `check-docs` | Форматування документації, lint і broken-link checks | Документація змінена | -| `skills-python` | Ruff + pytest для Python-backed skills | Зміни, релевантні для Python-skill | -| `checks-windows` | Windows-specific process/path tests плюс shared runtime import specifier regressions | Зміни, релевантні для Windows | -| `macos-node` | macOS TypeScript test lane із використанням shared built artifacts | Зміни, релевантні для macOS | -| `macos-swift` | Swift lint, build і tests для macOS app | Зміни, релевантні для macOS | -| `android` | Android unit tests для обох flavors плюс одна debug APK build | Зміни, релевантні для Android | -| `test-performance-agent` | Щоденна Codex slow-test optimization після trusted activity | Main CI success або manual dispatch | +| `preflight` | Виявляє docs-only changes, changed scopes, changed extensions і збирає CI manifest | Завжди на non-draft pushes і PRs | +| `security-scm-fast` | Виявлення private key і workflow audit через `zizmor` | Завжди на non-draft pushes і PRs | +| `security-dependency-audit` | Dependency-free production lockfile audit щодо npm advisories | Завжди на non-draft pushes і PRs | +| `security-fast` | Обовʼязковий aggregate для fast security jobs | Завжди на non-draft pushes і PRs | +| `build-artifacts` | Збирає `dist/`, Control UI, built-artifact checks і reusable downstream artifacts | Node-relevant changes | +| `checks-fast-core` | Швидкі Linux correctness lanes, як-от bundled/plugin-contract/protocol checks | Node-relevant changes | +| `checks-fast-contracts-channels` | Sharded channel contract checks зі stable aggregate check result | Node-relevant changes | +| `checks-node-core-test` | Core Node test shards, за винятком channel, bundled, contract і extension lanes | Node-relevant changes | +| `check` | Sharded main local gate equivalent: prod types, lint, guards, test types і strict smoke | Node-relevant changes | +| `check-additional` | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards | Node-relevant changes | +| `build-smoke` | Built-CLI smoke tests і startup-memory smoke | Node-relevant changes | +| `checks` | Verifier для built-artifact channel tests | Node-relevant changes | +| `checks-node-compat-node22` | Node 22 compatibility build і smoke lane | Manual CI dispatch для releases | +| `check-docs` | Docs formatting, lint і broken-link checks | Docs changed | +| `skills-python` | Ruff + pytest для Python-backed Skills | Python-skill-relevant changes | +| `checks-windows` | Windows-specific process/path tests плюс shared runtime import specifier regressions | Windows-relevant changes | +| `macos-node` | macOS TypeScript test lane із використанням shared built artifacts | macOS-relevant changes | +| `macos-swift` | Swift lint, build і tests для macOS app | macOS-relevant changes | +| `android` | Android unit tests для обох flavors плюс одна debug APK build | Android-relevant changes | +| `test-performance-agent` | Щоденна Codex slow-test optimization після trusted activity | Main CI success або manual dispatch | -Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають усі -ланки з областю дії, крім Android: Linux-шарди Node, шарди вбудованих плагінів, контракти каналів, -сумісність із Node 22, `check`, `check-additional`, smoke-перевірку збірки, перевірки документації, -Python Skills, Windows, macOS і i18n Control UI. Окремі ручні запуски CI виконують лише Android з `include_android=true`; повна парасолька релізу -вмикає Android, передаючи `full_release_validation=true`. Передрелізний набір плагінів -виключено з окремого ручного CI, і він вмикається лише тоді, коли -повна парасолька релізу передає `full_release_validation=true`. Ручні запуски використовують -унікальну групу паралельності, щоб повний набір release-candidate не скасовувався -іншим push або PR-запуском на тому самому ref. Необов’язковий вхід `target_ref` дає змогу -довіреному викликачеві запустити цей граф для гілки, тегу або повного SHA коміту, водночас +Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну +не-Android scoped lane: Linux Node shards, bundled-plugin shards, контракти каналів, +сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки docs, +Python skills, Windows, macOS і Control UI i18n. Окремі ручні запуски CI +виконують лише Android з `include_android=true`; повна release umbrella +вмикає Android, передаючи `include_android=true`. Статичні перевірки передрелізу Plugin, +release-only shard `agentic-plugins`, повний пакетний sweep розширень +і Docker lanes передрелізу Plugin виключені з CI та виконуються в +окремому workflow `Plugin Prerelease`. Ручні запуски використовують +унікальну concurrency group, щоб повний набір release-candidate не скасовувався +іншим запуском push або PR на тому самому ref. Необов’язковий вхід `target_ref` дає змогу +довіреному викликачеві запустити цей граф для гілки, тегу або повного commit SHA, водночас використовуючи файл workflow з вибраного dispatch ref. ```bash @@ -385,62 +391,62 @@ gh workflow run full-release-validation.yml --ref main -f ref= ## Порядок fail-fast -Завдання впорядковано так, щоб дешеві перевірки падали до запуску дорогих: +Завдання впорядковані так, щоб дешеві перевірки падали до запуску дорогих: -1. `preflight` вирішує, які ланки взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями. -2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко падають, не чекаючи на важчі завдання артефактів і платформної матриці. -3. `build-artifacts` перекривається зі швидкими Linux-ланками, щоб downstream-споживачі могли стартувати щойно спільна збірка буде готова. -4. Після цього розгалужуються важчі платформні та runtime-ланки: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `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` швидко падають, не чекаючи на важчі завдання матриці артефактів і платформ. +3. `build-artifacts` перекривається зі швидкими Linux lanes, щоб downstream-споживачі могли стартувати одразу після готовності спільного build. +4. Після цього розгортаються важчі platform і runtime lanes: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. -Логіка областей дії міститься в `scripts/ci-changed-scope.mjs` і покрита модульними тестами в `src/scripts/ci-changed-scope.test.ts`. -Ручний dispatch пропускає виявлення changed-scope і змушує маніфест preflight -поводитися так, ніби змінилася кожна область з областю дії. -Редагування CI workflow перевіряють граф Node CI плюс linting workflow, але самі по собі не примушують Windows, Android або macOS native-збірки; ці платформні ланки залишаються прив’язаними до змін платформного вихідного коду. -Редагування лише маршрутизації CI, вибрані дешеві редагування фікстур core-test і вузькі редагування допоміжних засобів/маршрутизації тестів контрактів плагінів використовують швидкий шлях маніфесту лише для Node: preflight, security і одне завдання `checks-fast-core`. Цей шлях уникає артефактів збірки, сумісності з Node 22, контрактів каналів, повних core-шардів, шардів вбудованих плагінів і додаткових guard-матриць, коли змінені файли обмежені поверхнями маршрутизації або допоміжними поверхнями, які швидке завдання перевіряє безпосередньо. -Windows Node-перевірки прив’язані до Windows-специфічних обгорток процесів/шляхів, допоміжних засобів npm/pnpm/UI runner, конфігурації менеджера пакетів і поверхонь CI workflow, які виконують цю ланку; непов’язані зміни вихідного коду, плагінів, install-smoke і лише тестів залишаються на Linux Node-ланках, щоб не резервувати 16-vCPU Windows worker для покриття, яке вже перевіряється звичайними тестовими шардами. -Окремий workflow `install-smoke` повторно використовує той самий скрипт областей дії через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. Pull requests запускають швидкий шлях для поверхонь Docker/пакетів, змін пакетів/маніфестів вбудованих плагінів і core-поверхонь Plugin/канал/Gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише вихідного коду вбудованих плагінів, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає smoke CLI для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє build arg вбудованого розширення і запускає обмежений Docker-профіль вбудованих плагінів під 240-секундним сукупним таймаутом команди, де Docker run кожного сценарію обмежено окремо. Повний шлях зберігає встановлення QR-пакета та Docker/update-покриття інсталятора для нічних запланованих запусків, ручних dispatch, workflow-call перевірок релізу і pull requests, які справді торкаються поверхонь інсталятора/пакета/Docker. Push у `main`, включно з merge-комітами, не примушують повний шлях; коли логіка changed-scope запросила б повне покриття на push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної перевірки або валідації релізу. Повільний smoke Bun global install image-provider окремо gated через `run_bun_global_install_smoke`; він запускається за нічним розкладом і з workflow перевірок релізу, а ручні dispatch `install-smoke` можуть увімкнути його, але pull requests і push у `main` його не запускають. QR і Docker-тести інсталятора зберігають власні install-focused Dockerfile. Локальний `test:docker:all` попередньо збирає один спільний live-test образ, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: базовий Node/Git runner для ланок інсталятора/update/plugin-dependency і функціональний образ, який встановлює той самий tarball у `/app` для звичайних функціональних ланок. Визначення Docker-ланок містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка планувальника міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний план. Планувальник вибирає образ для кожної ланки через `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає ланки з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштуйте стандартну кількість слотів main-pool 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а кількість слотів provider-sensitive tail-pool 10 через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Обмеження важких ланок за замовчуванням становлять `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб npm install і multi-service ланки не перевантажували Docker, тоді як легші ланки все ще заповнюють доступні слоти. Одна ланка, важча за ефективні обмеження, все одно може стартувати з порожнього пулу, а потім виконується сама, доки не звільнить місткість. Старти ланок за замовчуванням рознесені на 2 секунди, щоб уникати локальних сплесків створення в Docker daemon; перевизначте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний агрегатний preflight перевіряє Docker, видаляє застарілі OpenClaw E2E контейнери, виводить статус активних ланок, зберігає таймінги ланок для longest-first впорядкування і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для огляду планувальника. За замовчуванням він припиняє планувати нові pooled-ланки після першої помилки, і кожна ланка має 120-хвилинний fallback-таймаут, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; вибрані live/tail ланки використовують жорсткіші обмеження на ланку. `OPENCLAW_DOCKER_ALL_LANES=` запускає точні ланки планувальника, включно з release-only ланками на кшталт `install-e2e` і розділеними ланками оновлення вбудованих компонентів на кшталт `bundled-channel-update-acpx`, пропускаючи cleanup smoke, щоб agents могли відтворити одну невдалу ланку. Перевикористовуваний live/E2E workflow питає `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live-образу, ланки і credentials потрібне, а потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного запуску, або завантажує package artifact з `package_artifact_run_id`; перевіряє інвентар tarball; збирає і пушить package-digest-tagged bare/functional GHCR Docker E2E образи через Docker layer cache Blacksmith, коли план потребує package-installed ланок; і повторно використовує надані входи `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest образи замість повторної збірки. Workflow `Package Acceptance` є високорівневим gate пакета: він визначає кандидата з npm, довіреного `package_ref`, HTTPS tarball плюс SHA-256 або артефакта попереднього workflow, а потім передає цей єдиний артефакт `package-under-test` у перевикористовуваний Docker E2E workflow. Він тримає `workflow_ref` окремо від `package_ref`, щоб поточна acceptance-логіка могла перевіряти старіші довірені коміти без checkout старого workflow-коду. Перевірки релізу запускають власну дельту Package Acceptance для цільового ref: сумісність bundled-channel, offline plugin fixtures і Telegram package QA щодо визначеного tarball. Docker-набір release-path запускає менші chunked-завдання з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk тягнув лише потрібний тип образу і виконував кілька ланок через той самий зважений планувальник (`OPENCLAW_DOCKER_ALL_PROFILE=release-path`, `OPENCLAW_DOCKER_ALL_CHUNK=core|package-update-openai|package-update-anthropic|package-update-core|plugins-runtime-plugins|plugins-runtime-services|plugins-runtime-install-a|plugins-runtime-install-b|plugins-runtime-install-c|plugins-runtime-install-d|bundled-channels`). OpenWebUI входить до `plugins-runtime-services`, коли це запитує повне release-path покриття, і зберігає окремий chunk `openwebui` лише для dispatch, що стосуються тільки OpenWebUI. Застарілі назви агрегатних chunk `package-update`, `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` досі працюють для ручних перезапусків, але release workflow використовує розділені chunks, щоб installer E2E і sweeping встановлення/видалення вбудованих плагінів не домінували на критичному шляху. Псевдонім ланки `install-e2e` залишається агрегатним псевдонімом ручного перезапуску для обох ланок provider installer. Chunk `bundled-channels` запускає розділені ланки `bundled-channel-*` і `bundled-channel-update-*`, а не серійну все-в-одному ланку `bundled-channel-deps`. Кожен chunk завантажує `.artifacts/docker-tests/` з журналами ланок, таймінгами, `summary.json`, `failures.json`, таймінгами фаз, JSON плану планувальника, таблицями повільних ланок і командами перезапуску для кожної ланки. Вхід workflow `docker_lanes` запускає вибрані ланки проти підготовлених образів замість chunk-завдань, що утримує налагодження невдалої ланки в межах одного цільового Docker-завдання і готує, завантажує або повторно використовує package artifact для цього запуску; якщо вибрана ланка є live Docker lane, цільове завдання локально збирає live-test образ для цього перезапуску. Згенеровані GitHub-команди перезапуску для кожної ланки включають `package_artifact_run_id`, `package_artifact_name` і входи підготовлених образів, коли ці значення існують, щоб невдала ланка могла повторно використати точний пакет і образи з невдалого запуску. Використовуйте `pnpm test:docker:rerun `, щоб завантажити Docker-артефакти з GitHub-запуску і вивести об’єднані/покомпонентні цільові команди перезапуску; використовуйте `pnpm test:docker:timings ` для зведень slow-lane і phase critical-path. Запланований live/E2E workflow щодня запускає повний Docker-набір release-path. Матриця bundled update розділена за ціллю оновлення, щоб повторні проходи npm update і doctor repair могли шардитися з іншими bundled-перевірками. +Логіка scope міститься в `scripts/ci-changed-scope.mjs` і покрита unit tests у `src/scripts/ci-changed-scope.test.ts`. +Ручний dispatch пропускає виявлення changed-scope і змушує preflight manifest +діяти так, ніби змінилася кожна scoped area. +Правки CI workflow перевіряють граф Node CI плюс workflow linting, але самі по собі не примушують виконувати Windows, Android або macOS native builds; ці platform lanes залишаються scoped до змін platform source. +Правки лише маршрутизації CI, вибрані дешеві правки core-test fixtures і вузькі правки helper/test-routing для контрактів Plugin використовують швидкий Node-only manifest path: preflight, security і одне завдання `checks-fast-core`. Цей шлях уникає build artifacts, сумісності з Node 22, контрактів каналів, повних core shards, bundled-plugin shards і додаткових guard matrices, коли змінені файли обмежені routing або helper surfaces, які швидке завдання перевіряє напряму. +Перевірки Windows Node scoped до специфічних для Windows process/path wrappers, helper-ів npm/pnpm/UI runner, конфігурації package manager і CI workflow surfaces, які виконують цю lane; непов’язані source, plugin, install-smoke і test-only зміни залишаються на Linux Node lanes, щоб вони не резервували 16-vCPU Windows worker для coverage, який уже виконується звичайними test shards. +Окремий workflow `install-smoke` повторно використовує той самий scope script через власне завдання `preflight`. Він розділяє smoke coverage на `run_fast_install_smoke` і `run_full_install_smoke`. Pull requests запускають fast path для Docker/package surfaces, змін package/manifest bundled Plugin і core Plugin/channel/gateway/Plugin SDK surfaces, які перевіряють Docker smoke jobs. Source-only зміни bundled Plugin, test-only правки та docs-only правки не резервують Docker workers. Fast path один раз збирає образ root Dockerfile, перевіряє CLI, запускає agents delete shared-workspace CLI smoke, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений bundled-plugin Docker profile під 240-секундним aggregate command timeout, причому Docker run кожного сценарію обмежений окремо. Full path зберігає QR package install і installer Docker/update coverage для нічних запланованих запусків, ручних dispatches, workflow-call release checks і pull requests, які справді зачіпають installer/package/Docker surfaces. Pushes у `main`, включно з merge commits, не примушують full path; коли changed-scope logic запитувала б full coverage для push, workflow зберігає fast Docker smoke і залишає full install smoke для nightly або release validation. Повільний Bun global install image-provider smoke окремо gated через `run_bun_global_install_smoke`; він запускається за нічним розкладом і з workflow release checks, а ручні dispatches `install-smoke` можуть увімкнути його, але pull requests і pushes у `main` його не запускають. QR і installer Docker tests зберігають власні install-focused Dockerfiles. Локальний `test:docker:all` попередньо збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: bare Node/Git runner для installer/update/plugin-dependency lanes і functional image, який встановлює той самий tarball у `/app` для звичайних functionality lanes. Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`, planner logic міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний plan. Scheduler вибирає image для кожної lane за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте стандартну кількість слотів main-pool 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а provider-sensitive кількість слотів tail-pool 10 через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Caps для heavy lanes за замовчуванням дорівнюють `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб npm install і multi-service lanes не перевантажували Docker, тоді як легші lanes усе ще заповнюють доступні слоти. Одна lane, важча за effective caps, усе ще може стартувати з порожнього pool, після чого виконується сама, доки не звільнить capacity. Запуски lanes за замовчуванням рознесені на 2 секунди, щоб уникати локальних Docker daemon create storms; перевизначте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний aggregate preflight перевіряє Docker, видаляє застарілі OpenClaw E2E containers, виводить active-lane status, зберігає lane timings для longest-first ordering і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для перевірки scheduler. За замовчуванням він припиняє планувати нові pooled lanes після першої помилки, і кожна lane має 120-хвилинний fallback timeout, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; вибрані live/tail lanes використовують жорсткіші per-lane caps. `OPENCLAW_DOCKER_ALL_LANES=` запускає точні scheduler lanes, включно з release-only lanes, як-от `install-e2e`, і split bundled update lanes, як-от `bundled-channel-update-acpx`, водночас пропускаючи cleanup smoke, щоб agents могли відтворити одну failed lane. Reusable live/E2E workflow запитує в `scripts/test-docker-all.mjs --plan-json`, яке package, image kind, live image, lane і credential coverage потрібні, потім `scripts/docker-e2e.mjs` перетворює цей plan на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного run, або завантажує package artifact з `package_artifact_run_id`; перевіряє tarball inventory; збирає й публікує package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли plan потребує package-installed lanes; і повторно використовує передані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість повторної збірки. Workflow `Package Acceptance` є high-level package gate: він визначає candidate з npm, довіреного `package_ref`, HTTPS tarball плюс SHA-256 або артефакту попереднього workflow, а потім передає цей єдиний artifact `package-under-test` у reusable Docker E2E workflow. Він тримає `workflow_ref` окремо від `package_ref`, щоб поточна acceptance logic могла перевіряти старіші довірені commits без checkout старого workflow code. Release checks запускають custom Package Acceptance delta для target ref: bundled-channel compat, offline plugin fixtures і Telegram package QA проти resolved tarball. Release-path Docker suite запускає менші chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний йому image kind і виконував кілька lanes через той самий weighted scheduler (`OPENCLAW_DOCKER_ALL_PROFILE=release-path`, `OPENCLAW_DOCKER_ALL_CHUNK=core|package-update-openai|package-update-anthropic|package-update-core|plugins-runtime-plugins|plugins-runtime-services|plugins-runtime-install-a|plugins-runtime-install-b|plugins-runtime-install-c|plugins-runtime-install-d|bundled-channels`). OpenWebUI включено в `plugins-runtime-services`, коли full release-path coverage запитує його, і він зберігає окремий chunk `openwebui` лише для OpenWebUI-only dispatches. Legacy aggregate chunk names `package-update`, `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` усе ще працюють для ручних повторних запусків, але release workflow використовує split chunks, щоб installer E2E і bundled plugin install/uninstall sweeps не домінували на critical path. Alias lane `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes. Chunk `bundled-channels` запускає split lanes `bundled-channel-*` і `bundled-channel-update-*` замість послідовної all-in-one lane `bundled-channel-deps`. Кожен chunk завантажує `.artifacts/docker-tests/` з lane logs, timings, `summary.json`, `failures.json`, phase timings, scheduler plan JSON, slow-lane tables і per-lane rerun commands. Вхід workflow `docker_lanes` запускає вибрані lanes проти prepared images замість chunk jobs, що обмежує debugging failed-lane одним targeted Docker job і готує, завантажує або повторно використовує package artifact для цього run; якщо вибрана lane є live Docker lane, targeted job збирає live-test image локально для цього rerun. Згенеровані per-lane GitHub rerun commands містять `package_artifact_run_id`, `package_artifact_name` і prepared image inputs, коли ці значення існують, щоб failed lane могла повторно використати exact package і images з failed run. Використовуйте `pnpm test:docker:rerun `, щоб завантажити Docker artifacts із GitHub run і вивести combined/per-lane targeted rerun commands; використовуйте `pnpm test:docker:timings ` для slow-lane і phase critical-path summaries. Scheduled live/E2E workflow щодня запускає повний release-path Docker suite. Bundled update matrix розділена за update target, щоб повторні npm update і doctor repair passes могли shard разом з іншими bundled checks. -Поточні 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-b`, `plugins-runtime-install-c`, `plugins-runtime-install-d`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` і `bundled-channels-contracts`. Агрегатний chunk `bundled-channels` залишається доступним для ручних one-shot перезапусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегатними псевдонімами plugin/runtime, але release workflow використовує розділені chunks, щоб channel smokes, цілі оновлення, перевірки plugin runtime і sweeping встановлення/видалення вбудованих плагінів могли виконуватися паралельно. Цільові dispatch `docker_lanes` також розділяють кілька вибраних ланок на паралельні завдання після одного спільного кроку підготовки пакета/образів, а ланки bundled-channel update повторюють спробу один раз для тимчасових npm network помилок. +Поточні 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-b`, `plugins-runtime-install-c`, `plugins-runtime-install-d`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` і `bundled-channels-contracts`. Aggregate chunk `bundled-channels` залишається доступним для ручних one-shot reruns, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються aggregate plugin/runtime aliases, але release workflow використовує split chunks, щоб channel smokes, update targets, plugin runtime checks і bundled plugin install/uninstall sweeps могли виконуватися паралельно. Targeted dispatches `docker_lanes` також розділяють кілька вибраних lanes на parallel jobs після одного спільного кроку package/image preparation, а bundled-channel update lanes повторюють спробу один раз у разі transient npm network failures. -Локальна логіка змінених ліній живе в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний перевірковий gate суворіший щодо архітектурних меж, ніж широкий scope платформи CI: зміни production-коду core запускають typecheck для core prod і core test, а також core lint/guards; зміни лише в тестах core запускають тільки typecheck для core test і core lint; production-зміни extension запускають typecheck для extension prod і extension test, а також extension lint; зміни лише в тестах extension запускають typecheck для extension test і extension lint. Зміни публічного Plugin SDK або plugin-контракту розширюються до typecheck для extensions, бо extensions залежать від цих core-контрактів, але Vitest-прогони для extensions є явною тестовою роботою. Version bumps лише для release metadata запускають цільові перевірки версії/config/root-dependency. Невідомі root/config-зміни безпечно переходять у всі check lanes. -Локальна маршрутизація змінених тестів живе в `scripts/test-projects.test-support.mjs` і -навмисно дешевша за `check:changed`: прямі правки тестів запускають самі себе, -правки source віддають перевагу явним mapping-ам, потім sibling tests та import-graph -dependents. Shared group-room delivery config є одним із явних mapping-ів: -зміни group visible-reply config, source reply delivery mode або -message-tool system prompt проходять через core reply tests плюс Discord і -Slack delivery regressions, щоб зміна shared default падала до першого PR +Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний контрольний gate суворіший щодо архітектурних меж, ніж широка область платформи CI: зміни production-коду core запускають typecheck core prod і core test, а також lint/guards core; зміни лише тестів core запускають тільки typecheck core test і lint core; зміни production-коду розширень запускають typecheck extension prod і extension test, а також lint розширень; зміни лише тестів розширень запускають typecheck extension test і lint розширень. Зміни публічного Plugin SDK або контракту Plugin розширюються до typecheck розширень, бо розширення залежать від цих контрактів core, але проходи Vitest для розширень є явною тестовою роботою. Version bumps лише release metadata запускають цільові перевірки version/config/root-dependency. Невідомі зміни root/config безпечно переходять до всіх check lanes. +Локальна маршрутизація changed-test міститься в `scripts/test-projects.test-support.mjs` і +навмисно дешевша за `check:changed`: прямі зміни тестів запускають самі себе, +зміни source надають перевагу явним мапінгам, потім sibling tests і залежним +елементам import-graph. Спільна конфігурація доставки group-room є одним із явних мапінгів: +зміни до group visible-reply config, source reply delivery mode або +message-tool system prompt проходять через core reply tests, а також регресії доставки Discord і +Slack, щоб зміна спільного default падала до першого PR push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна настільки широка для harness, що дешевий mapped set не є надійним proxy. -Для валідації Testbox запускайте з кореня repo і віддавайте перевагу свіжому warmed box для -широкого proof. Перш ніж витрачати повільний gate на box, який було повторно використано, термін дії якого минув або -який щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` всередині -box. Sanity check швидко падає, коли обов’язкові root files, як-от -`pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 -tracked deletions. Зазвичай це означає, що стан remote sync не є надійною -копією PR. Зупиніть цей box і прогрійте свіжий замість debug product test failure. -Для PR з навмисними великими видаленнями встановіть +Для валідації Testbox запускайте з кореня репозиторію та надавайте перевагу свіжому прогрітому box для +широкого proof. Перед тим як витрачати повільний gate на box, який був повторно використаний, прострочений або +щойно повідомив про неочікувано великий sync, спочатку запустіть `pnpm testbox:sanity` всередині +box. Sanity check швидко падає, коли зникли потрібні root files, як-от +`pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 +tracked deletions. Зазвичай це означає, що remote sync state не є надійною +копією PR. Зупиніть цей box і прогрійте свіжий замість налагодження +product test failure. Для навмисних PR з великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run. -Manual CI dispatches запускають `checks-node-compat-node22` як широке compatibility coverage. Android є opt-in для standalone manual CI через `include_android=true` і завжди ввімкнений для `Full Release Validation`. `plugin-prerelease-suite` є дорожчим product/package coverage, тому він запускається лише тоді, коли `Full Release Validation` запускає CI з `full_release_validation=true`. Звичайні pull requests, `main` pushes і standalone manual CI dispatches тримають цей suite вимкненим. +Manual CI dispatches запускають `checks-node-compat-node22` як широке compatibility coverage. Android є opt-in для standalone manual CI через `include_android=true` і завжди ввімкнений для `Full Release Validation`. `Plugin Prerelease` є дорожчим product/package coverage, тому це окремий workflow, який запускає `Full Release Validation` або явний operator. Звичайні pull requests, `main` pushes і standalone manual CI dispatches тримають цей suite вимкненим. -Найповільніші Node test families розділені або збалансовані так, щоб кожна job залишалася малою без надмірного резервування runners: channel contracts запускаються як три weighted shards, bundled plugin tests балансуються між вісьмома extension workers, малі 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. Extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на group і більшим Node heap, щоб import-heavy plugin batches не створювали додаткових CI jobs. Broad agents lane використовує shared Vitest file-parallel scheduler, бо він dominated by import/scheduling, а не належить одному повільному test file. `runtime-config` запускається з infra core-runtime shard, щоб shared runtime shard не володів tail. Include-pattern shards записують timing entries з використанням CI shard name, тож `.artifacts/vitest-shard-timings.json` може відрізнити whole config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі independent guards concurrently всередині однієї job. Gateway watch, channel tests і core support-boundary shard запускаються concurrently всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи свої старі check names як lightweight verifier jobs, водночас уникаючи двох додаткових Blacksmith workers і другої artifact-consumer queue. -Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane усе ще компілює цей flavor із SMS/call-log BuildConfig flags, уникаючи duplicate debug APK packaging job на кожному Android-relevant push. -GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє на той самий PR або `main` ref. Сприймайте це як CI noise, якщо newest run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тож вони все одно повідомляють нормальні shard failures, але не стають у queue після того, як увесь workflow уже був superseded. -Automatic CI concurrency key versioned (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг нескінченно блокувати новіші main runs. Manual full-suite runs використовують `CI-manual-v1-*` і не cancel in-progress runs. +Найповільніші сімейства Node tests розділені або збалансовані, щоб кожен job залишався малим без надмірного резервування runners: channel contracts запускаються як три зважені shards, малі core unit lanes поєднані в пари, auto-reply запускається як чотири збалансовані workers із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards, а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують власні dedicated Vitest configs замість shared plugin catch-all. `Plugin Prerelease` балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на group і більшим Node heap, щоб import-heavy plugin batches не створювали додаткових CI jobs. Широка agents lane використовує shared Vitest file-parallel scheduler, бо вона обмежена import/scheduling, а не належить одному повільному test file. `runtime-config` запускається з infra core-runtime shard, щоб shared runtime shard не володів хвостом. Include-pattern shards записують timing entries із CI shard name, тому `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards паралельно всередині одного job. Gateway watch, channel tests і core support-boundary shard запускаються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` вже зібрані, зберігаючи їхні старі check names як легкі verifier jobs і водночас уникаючи двох додаткових Blacksmith workers та другої artifact-consumer queue. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює цей flavor із SMS/call-log BuildConfig flags, уникаючи дублювального debug APK packaging job на кожному Android-relevant push. +GitHub може позначати superseded jobs як `cancelled`, коли новіший push потрапляє в той самий PR або `main` ref. Вважайте це CI noise, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все ще повідомляють про звичайні shard failures, але не стають у чергу після того, як увесь workflow уже був superseded. +Ключ automatic CI concurrency версіонований (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг нескінченно блокувати новіші main runs. Manual full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs. ## Runners | Runner | Jobs | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ubuntu-24.04` | `preflight`, fast security jobs і aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), fast protocol/contract/bundled checks, sharded channel contract checks, `check` shards окрім lint, `check-additional` shards і aggregates, Node test aggregate verifiers, docs checks, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла стати в queue раніше | +| `ubuntu-24.04` | `preflight`, швидкі security jobs і aggregates (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled checks, sharded channel contract checks, `check` shards, крім lint, `check-additional` shards і aggregates, Node test aggregate verifiers, docs checks, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла стати в чергу раніше | | `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, lower-weight extension shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | | `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux Node test shards, bundled plugin test shards, `android` | | `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо CPU-sensitive, щоб 8 vCPU коштували більше, ніж заощадили; install-smoke Docker builds, де 32-vCPU queue time коштував більше, ніж заощадив | | `blacksmith-16vcpu-windows-2025` | `checks-windows` | -| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; forks fall back to `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks fall back to `macos-latest` | +| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; forks повертаються до `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks повертаються до `macos-latest` | ## Локальні еквіваленти @@ -471,4 +477,4 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac ## Пов’язане - [Огляд встановлення](/uk/install) -- [Release channels](/uk/install/development-channels) +- [Канали релізів](/uk/install/development-channels) diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md index 3e656bfa3..a111acbf8 100644 --- a/docs/uk/help/testing.md +++ b/docs/uk/help/testing.md @@ -2,34 +2,34 @@ read_when: - Запуск тестів локально або в CI - Додавання регресійних тестів для помилок моделей/провайдерів - - Налагодження Gateway + поведінки агента -summary: 'Набір для тестування: набори тестів unit/e2e/live, ранери Docker і що охоплює кожен тест' + - Налагодження поведінки Gateway + агента +summary: 'Набір для тестування: набори unit/e2e/live-тестів, ранери Docker і що покриває кожен тест' title: Тестування x-i18n: - generated_at: "2026-04-29T05:57:20Z" + generated_at: "2026-04-29T07:27:28Z" model: gpt-5.5 provider: openai - source_hash: 9b06c2e7905ca930f0cac92d43c5902d38b9513968a68d2077ff4ef7a5a345ce + source_hash: c7b506350f11431195cb55c84cb10e99efb5f43b934079528b982627024d1ffc source_path: help/testing.md workflow: 16 --- OpenClaw має три набори Vitest (unit/integration, e2e, live) і невеликий набір -Docker-ранерів. Цей документ є посібником «як ми тестуємо»: +Docker-ранерів. Цей документ є посібником "як ми тестуємо": -- Що покриває кожен набір (і що він свідомо _не_ покриває). -- Які команди запускати для типових робочих процесів (локально, перед push, під час налагодження). +- Що покриває кожен набір (і що він навмисно _не_ покриває). +- Які команди запускати для типових робочих процесів (локально, перед 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) — синтетичний транспортний plugin, який використовується сценаріями на базі репозиторію. +- [QA-канал](/uk/channels/qa-channel) — синтетичний транспортний plugin, який використовують сценарії з репозиторію. -Ця сторінка описує запуск звичайних тестових наборів і Docker/Parallels-ранерів. Розділ нижче, присвячений QA-специфічним ранерам ([QA-специфічні ранери](#qa-specific-runners)), перелічує конкретні виклики `qa` і посилається назад на наведені вище довідники. +Ця сторінка описує запуск звичайних тестових наборів і Docker/Parallels-ранерів. Розділ про QA-специфічні ранери нижче ([QA-специфічні ранери](#qa-specific-runners)) перелічує конкретні виклики `qa` і відсилає до наведених вище довідкових матеріалів. ## Швидкий старт @@ -37,172 +37,172 @@ Docker-ранерів. Цей документ є посібником «як м У більшість днів: - Повний gate (очікується перед push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` -- Швидший локальний запуск повного набору на потужній машині: `pnpm test:max` -- Прямий цикл Vitest watch: `pnpm test:watch` -- Пряме націлювання на файл тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Під час ітерацій над одним збоєм спочатку віддавайте перевагу цільовим запускам. -- Docker-backed QA site: `pnpm qa:lab:up` -- Linux VM-backed QA lane: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- Швидший локальний запуск повного набору на машині з достатніми ресурсами: `pnpm test:max` +- Прямий цикл спостереження Vitest: `pnpm test:watch` +- Пряме таргетування файлів тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` +- Спершу віддавайте перевагу таргетованим запускам, коли ітеруєте над одним збоєм. +- Docker-бекендований QA-сайт: `pnpm qa:lab:up` +- QA-lane на базі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` Коли ви змінюєте тести або хочете додаткової впевненості: - 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` +- Live-набір (моделі + проби інструментів/зображень Gateway): `pnpm test:live` +- Таргетуйте один live-файл без зайвого шуму: `pnpm test:live -- src/agents/models.profiles.live.test.ts` - Docker live model sweep: `pnpm test:docker:live-models` - - Кожна вибрана модель тепер виконує текстовий хід плюс невелику перевірку в стилі читання файлу. - Моделі, метадані яких оголошують вхід `image`, також виконують крихітний image-хід. - Вимкніть додаткові перевірки за допомогою `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або + - Кожна вибрана модель тепер виконує текстовий хід плюс невелику пробу в стилі читання файлу. + Моделі, метадані яких оголошують вхід `image`, також виконують крихітний хід із зображенням. + Вимикайте додаткові проби через `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0`, коли ізолюєте збої провайдера. - - Покриття CI: щоденні `OpenClaw Scheduled Live And E2E Checks` і ручні + - Покриття CI: щоденний `OpenClaw Scheduled Live And E2E Checks` і ручний `OpenClaw Release Checks` обидва викликають reusable live/E2E workflow з `include_live_suites: true`, що включає окремі Docker live model matrix jobs, розбиті за провайдерами. - - Для сфокусованих повторних запусків CI dispatch `OpenClaw Live And E2E Checks (Reusable)` + - Для фокусних повторних запусків CI запускайте `OpenClaw Live And E2E Checks (Reusable)` з `include_live_suites: true` і `live_models_only: true`. - - Додавайте нові high-signal provider secrets до `scripts/ci-hydrate-live-auth.sh` - плюс `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` і його - scheduled/release callers. + - Додавайте нові високосигнальні секрети провайдерів у `scripts/ci-hydrate-live-auth.sh` + плюс `.github/workflows/openclaw-live-and-e2e-checks-reusable.yml` та його + scheduled/release викликачі. - Native Codex bound-chat smoke: `pnpm test:docker:live-codex-bind` - - Запускає Docker live lane проти шляху Codex app-server, прив’язує синтетичний + - Запускає Docker live lane проти шляху Codex app-server, прив'язує синтетичний Slack DM через `/codex bind`, виконує `/codex fast` і `/codex permissions`, а потім перевіряє, що звичайна відповідь і вкладення зображення - проходять через native plugin binding замість ACP. + проходять через нативне прив'язування plugin замість ACP. - Codex app-server harness smoke: `pnpm test:docker:live-codex-harness` - - Запускає gateway agent turns через Codex app-server harness, яким володіє plugin, - перевіряє `/codex status` і `/codex models`, а за замовчуванням виконує image, - cron MCP, sub-agent і Guardian probes. Вимкніть sub-agent probe за допомогою + - Запускає ходи Gateway-агента через harness Codex app-server, яким володіє plugin, + перевіряє `/codex status` і `/codex models`, а за замовчуванням виконує проби image, + cron MCP, sub-agent і Guardian. Вимикайте пробу sub-agent через `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0`, коли ізолюєте інші збої Codex - app-server. Для сфокусованої sub-agent перевірки вимкніть інші перевірки: + app-server. Для фокусної перевірки sub-agent вимкніть інші проби: `OPENCLAW_LIVE_CODEX_HARNESS_IMAGE_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_MCP_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_GUARDIAN_PROBE=0 OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=1 pnpm test:docker:live-codex-harness`. - Це завершується після sub-agent probe, якщо не встановлено + Це завершується після проби sub-agent, якщо не встановлено `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0`. - Crestodian rescue command smoke: `pnpm test:live:crestodian-rescue-channel` - - Opt-in belt-and-suspenders перевірка для поверхні rescue command каналу повідомлень. - Вона виконує `/crestodian status`, ставить у чергу persistent model - change, відповідає `/crestodian yes` і перевіряє шлях audit/config write. + - Додаткова belt-and-suspenders перевірка поверхні команди відновлення message-channel. + Вона виконує `/crestodian status`, ставить у чергу сталу зміну моделі, + відповідає `/crestodian yes` і перевіряє шлях запису audit/config. - Crestodian planner Docker smoke: `pnpm test:docker:crestodian-planner` - - Запускає Crestodian у контейнері без конфігурації з фальшивим Claude CLI у `PATH` - і перевіряє, що fuzzy planner fallback перетворюється на audited typed - config write. + - Запускає Crestodian у контейнері без конфігурації з фейковим Claude CLI у `PATH` + і перевіряє, що нечіткий fallback планувальника перетворюється на аудований типізований + запис конфігурації. - Crestodian first-run Docker smoke: `pnpm test:docker:crestodian-first-run` - - Починає з порожнього каталогу стану OpenClaw, маршрутизує голий `openclaw` до - Crestodian, застосовує setup/model/agent/Discord plugin + SecretRef writes, - перевіряє конфігурацію та audit entries. Той самий шлях Ring 0 setup також - покрито в QA Lab через + - Починає з порожнього каталогу стану OpenClaw, маршрутизує простий `openclaw` до + Crestodian, застосовує setup/model/agent/Discord plugin + записи SecretRef, + валідує конфігурацію та перевіряє audit-записи. Той самий шлях налаштування Ring 0 + також покривається в QA Lab через `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`. -- Moonshot/Kimi cost smoke: із встановленим `MOONSHOT_API_KEY` запустіть +- Moonshot/Kimi cost smoke: з установленим `MOONSHOT_API_KEY` запустіть `openclaw models list --provider moonshot --json`, потім запустіть ізольований `openclaw agent --local --session-id live-kimi-cost --message 'Reply exactly: KIMI_LIVE_OK' --thinking off --json` проти `moonshot/kimi-k2.6`. Перевірте, що JSON повідомляє Moonshot/K2.6, а - assistant transcript зберігає нормалізоване `usage.cost`. + transcript асистента зберігає нормалізований `usage.cost`. -Коли потрібен лише один збійний випадок, віддавайте перевагу звуженню live-тестів через allowlist env vars, описані нижче. +Коли вам потрібен лише один збійний випадок, надавайте перевагу звуженню live-тестів через allowlist env vars, описані нижче. ## QA-специфічні ранери -Ці команди розташовані поруч з основними тестовими наборами, коли потрібен реалізм QA-lab: +Ці команди розташовані поруч з основними тестовими наборами, коли вам потрібна реалістичність QA-lab: -CI запускає QA Lab у виділених workflow. `Parity gate` запускається на відповідних PR і -з manual dispatch із mock providers. `QA-Lab - All Lanes` запускається щоночі на -`main` і з manual dispatch з mock parity gate, live Matrix lane, -Convex-managed live Telegram lane і Convex-managed live Discord lane як -parallel jobs. Scheduled QA і release checks передають Matrix `--profile fast` -явно, тоді як Matrix CLI і manual workflow input default залишаються -`all`; manual dispatch може розбити `all` на `transport`, `media`, `e2ee-smoke`, +CI запускає QA Lab у спеціалізованих workflow. `Parity gate` запускається на відповідних PR і +з ручного dispatch з mock-провайдерами. `QA-Lab - All Lanes` запускається щоночі на +`main` і з ручного dispatch з mock parity gate, live Matrix lane, +live Telegram lane під керуванням Convex і live Discord lane під керуванням Convex як +паралельні jobs. Scheduled QA і release checks передають Matrix `--profile fast` +явно, тоді як Matrix CLI і ручне введення workflow за замовчуванням залишаються +`all`; ручний dispatch може розділити `all` на `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli` jobs. `OpenClaw Release Checks` запускає parity плюс -fast Matrix і Telegram lanes перед release approval, використовуючи +швидкі Matrix і Telegram lanes перед release approval, використовуючи `mock-openai/gpt-5.5` для release transport checks, щоб вони лишалися детермінованими -і уникали звичайного запуску provider-plugin. Ці live transport gateways вимикають -memory search; поведінка пам’яті лишається покритою QA parity suites. +і не запускали звичайний provider-plugin startup. Ці live transport gateways вимикають +memory search; поведінка memory лишається покритою QA parity suites. -Full release live media shards використовують -`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, який уже має +Повні release live media shards використовують +`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, де вже є `ffmpeg` і `ffprobe`. Docker live model/backend shards використовують спільний образ `ghcr.io/openclaw/openclaw-live-test:`, зібраний один раз для вибраного -commit, а потім тягнуть його з `OPENCLAW_SKIP_DOCKER_BUILD=1` замість повторного збирання +commit, а потім завантажують його з `OPENCLAW_SKIP_DOCKER_BUILD=1` замість повторної збірки всередині кожного shard. - `pnpm openclaw qa suite` - - Запускає repo-backed QA scenarios безпосередньо на хості. - - Запускає кілька вибраних scenarios паралельно за замовчуванням з ізольованими - gateway workers. `qa-channel` за замовчуванням має concurrency 4 (обмежено - кількістю вибраних scenarios). Використовуйте `--concurrency `, щоб налаштувати - кількість workers, або `--concurrency 1` для старішого serial lane. - - Завершується з ненульовим кодом, коли будь-який scenario зазнає невдачі. Використовуйте `--allow-failures`, коли - потрібні артефакти без failing exit code. - - Підтримує provider modes `live-frontier`, `mock-openai` і `aimock`. - `aimock` запускає локальний AIMock-backed provider server для експериментального - fixture і protocol-mock coverage без заміни scenario-aware + - Запускає QA-сценарії з репозиторію безпосередньо на host. + - За замовчуванням запускає кілька вибраних сценаріїв паралельно з ізольованими + Gateway workers. `qa-channel` за замовчуванням має concurrency 4 (обмежено + кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати кількість + workers, або `--concurrency 1` для старішої serial lane. + - Завершується з ненульовим кодом, коли будь-який сценарій падає. Використовуйте `--allow-failures`, коли + хочете artifacts без failing exit code. + - Підтримує режими провайдера `live-frontier`, `mock-openai` і `aimock`. + `aimock` запускає локальний provider server на базі AIMock для експериментального + покриття fixtures і protocol-mock без заміни scenario-aware `mock-openai` lane. - `pnpm test:gateway:cpu-scenarios` - Запускає gateway startup bench плюс невеликий mock QA Lab scenario pack (`channel-chat-baseline`, `memory-failure-fallback`, - `gateway-restart-inflight-run`) і записує об’єднаний CPU observation - summary у `.artifacts/gateway-cpu-scenarios/`. - - За замовчуванням позначає лише sustained hot CPU observations (`--cpu-core-warn` - плюс `--hot-wall-warn-ms`), тому короткі startup bursts записуються як metrics - без вигляду minutes-long gateway peg regression. - - Використовує зібрані `dist` artifacts; спочатку запустіть build, коли checkout не - має свіжого runtime output. + `gateway-restart-inflight-run`) і записує об'єднаний підсумок CPU observations + у `.artifacts/gateway-cpu-scenarios/`. + - За замовчуванням позначає лише тривалі гарячі CPU observations (`--cpu-core-warn` + плюс `--hot-wall-warn-ms`), тож короткі startup bursts записуються як metrics + без вигляду хвилинної регресії gateway peg. + - Використовує зібрані `dist` artifacts; спершу запустіть build, якщо checkout ще не має + свіжого runtime output. - `pnpm openclaw qa suite --runner multipass` - - Запускає той самий QA-набір усередині одноразової Multipass Linux VM. - - Зберігає ту саму поведінку scenario-selection, що й `qa suite` на хості. - - Повторно використовує ті самі provider/model selection flags, що й `qa suite`. - - Live-запуски пересилають підтримувані QA auth inputs, практичні для guest: + - Запускає той самий QA suite всередині одноразової Multipass Linux VM. + - Зберігає ту саму поведінку вибору сценаріїв, що й `qa suite` на host. + - Повторно використовує ті самі прапорці вибору провайдера/моделі, що й `qa suite`. + - Live-запуски передають підтримувані QA auth inputs, практичні для guest: env-based provider keys, шлях QA live provider config і `CODEX_HOME`, коли він присутній. - - Output dirs мають лишатися в межах кореня репозиторію, щоб guest міг записувати назад через + - Output dirs мають лишатися під коренем репозиторію, щоб guest міг записувати назад через змонтований workspace. - Записує звичайний QA report + summary плюс Multipass logs у `.artifacts/qa-e2e/...`. - `pnpm qa:lab:up` - - Запускає Docker-backed QA site для operator-style QA work. + - Запускає Docker-бекендований QA-сайт для operator-style QA work. - `pnpm test:docker:npm-onboard-channel-agent` - Збирає npm tarball з поточного checkout, встановлює його глобально в - Docker, запускає non-interactive OpenAI API-key onboarding, за замовчуванням налаштовує Telegram, - перевіряє, що ввімкнення plugin встановлює runtime dependencies на вимогу, + Docker, запускає неінтерактивний OpenAI API-key onboarding, за замовчуванням налаштовує Telegram, + перевіряє, що увімкнення plugin встановлює runtime dependencies на вимогу, запускає doctor і виконує один локальний agent turn проти mocked OpenAI endpoint. - - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити той самий packaged-install + - Використовуйте `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`, щоб запустити ту саму packaged-install lane з Discord. - `pnpm test:docker:session-runtime-context` - Запускає детермінований built-app Docker smoke для embedded runtime context - transcripts. Він перевіряє, що прихований OpenClaw runtime context зберігається як + transcripts. Він перевіряє, що прихований runtime context OpenClaw зберігається як non-display custom message замість витоку у видимий user turn, - потім сіє affected broken session JSONL і перевіряє, що + потім засіває affected broken session JSONL і перевіряє, що `openclaw doctor --fix` переписує його на active branch із backup. - `pnpm test:docker:npm-telegram-live` - Встановлює candidate package OpenClaw у Docker, запускає installed-package - onboarding, налаштовує Telegram через installed CLI, потім повторно використовує + onboarding, налаштовує Telegram через встановлений CLI, а потім повторно використовує live Telegram QA lane з цим installed package як SUT Gateway. - - За замовчуванням використовує `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`; встановіть + - За замовчуванням `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`; установіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz` або - `OPENCLAW_CURRENT_PACKAGE_TGZ`, щоб тестувати resolved local tarball замість + `OPENCLAW_CURRENT_PACKAGE_TGZ`, щоб протестувати resolved local tarball замість встановлення з registry. - Використовує ті самі Telegram env credentials або Convex credential source, що й - `pnpm openclaw qa telegram`. Для CI/release automation встановіть + `pnpm openclaw qa telegram`. Для CI/release automation установіть `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_NPM_TELEGRAM_CREDENTIAL_ROLE=ci|maintainer` перевизначає спільний - `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цього lane. - - GitHub Actions надає цей lane як ручний maintainer workflow - `NPM Telegram Beta E2E`. Він не запускається під час merge. Workflow використовує + `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цієї lane. + - GitHub Actions надає цю lane як ручний maintainer workflow + `NPM Telegram Beta E2E`. Вона не запускається під час merge. Workflow використовує середовище `qa-live-shared` і Convex CI credential leases. - GitHub Actions також надає `Package Acceptance` для side-run product proof проти одного candidate package. Він приймає trusted ref, published npm spec, HTTPS tarball URL плюс SHA-256 або tarball artifact з іншого run, завантажує нормалізований `openclaw-current.tgz` як `package-under-test`, а потім запускає - existing Docker E2E scheduler зі smoke, package, product, full або custom - lane profiles. Встановіть `telegram_mode=mock-openai` або `live-frontier`, щоб запустити + наявний Docker E2E scheduler з smoke, package, product, full або custom + lane profiles. Установіть `telegram_mode=mock-openai` або `live-frontier`, щоб запустити Telegram QA workflow проти того самого artifact `package-under-test`. - Latest beta product proof: @@ -214,7 +214,7 @@ gh workflow run package-acceptance.yml --ref main \ -f telegram_mode=mock-openai ``` -- Exact tarball URL proof вимагає digest: +- Підтвердження exact tarball URL потребує digest: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -224,7 +224,7 @@ gh workflow run package-acceptance.yml --ref main \ -f suite_profile=package ``` -- Доказ артефакту завантажує артефакт tarball з іншого запуску Actions: +- Підтвердження артефакта завантажує tarball-артефакт з іншого запуску Actions: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -235,26 +235,31 @@ gh workflow run package-acceptance.yml --ref main \ ``` - `pnpm test:docker:bundled-channel-deps` - - Пакує та встановлює поточну збірку OpenClaw у Docker, запускає Gateway - з налаштованим OpenAI, а потім вмикає вбудовані канали/Plugin через зміни + - Пакує й установлює поточну збірку OpenClaw у Docker, запускає Gateway + з налаштованим OpenAI, а потім вмикає вбудовані канали/plugins через зміни конфігурації. - - Перевіряє, що виявлення налаштування залишає відсутніми неналаштовані runtime-залежності Plugin, перший налаштований запуск Gateway або doctor встановлює runtime-залежності кожного вбудованого - Plugin на вимогу, а другий перезапуск не перевстановлює залежності, які вже були активовані. - - Також встановлює відому старішу базову версію npm, вмикає Telegram перед запуском - `openclaw update --tag ` і перевіряє, що post-update doctor кандидата відновлює runtime-залежності вбудованого каналу без - postinstall-відновлення на стороні harness. + - Перевіряє, що виявлення налаштування залишає відсутніми залежності середовища виконання + неналаштованих plugin, що перший налаштований запуск Gateway або doctor установлює + залежності середовища виконання кожного вбудованого plugin на вимогу, а другий + перезапуск не перевстановлює вже активовані залежності. + - Також установлює відому старішу базову версію npm, вмикає Telegram перед запуском + `openclaw update --tag ` і перевіряє, що doctor кандидата після + оновлення виправляє залежності середовища виконання вбудованого каналу без + postinstall-виправлення з боку harness. - `pnpm test:parallels:npm-update` - - Запускає native smoke оновлення packaged-install у гостях Parallels. Кожна + - Запускає smoke-перевірку оновлення нативного пакетного встановлення на гостях Parallels. Кожна вибрана платформа спочатку встановлює запитаний базовий пакет, потім запускає - встановлену команду `openclaw update` у тому самому гості та перевіряє - встановлену версію, статус оновлення, готовність Gateway і один локальний хід агента. + встановлену команду `openclaw update` у тому самому гості й перевіряє + встановлену версію, статус оновлення, готовність gateway та один хід + локального агента. - Використовуйте `--platform macos`, `--platform windows` або `--platform linux` під час - ітерацій з одним гостем. Використовуйте `--json` для шляху до підсумкового артефакту та - статусу по кожній лінії. - - Лінія OpenAI типово використовує `openai/gpt-5.5` для live-доказу ходу агента. Передайте `--model ` або встановіть + ітерацій на одному гості. Використовуйте `--json` для шляху до підсумкового артефакта й + статусу кожної lane. + - Lane OpenAI типово використовує `openai/gpt-5.5` для live-підтвердження ходу агента. + Передайте `--model ` або задайте `OPENCLAW_PARALLELS_OPENAI_MODEL`, коли навмисно перевіряєте іншу модель OpenAI. - - Обгортайте довгі локальні запуски в timeout хоста, щоб зависання транспорту Parallels не + - Обгорніть довгі локальні запуски в timeout хоста, щоб зависання транспорту Parallels не використали решту вікна тестування: ```bash @@ -262,74 +267,74 @@ gh workflow run package-acceptance.yml --ref main \ timeout --foreground 90m pnpm test:parallels:npm-update -- --platform windows --json ``` - - Скрипт записує вкладені журнали ліній у `/tmp/openclaw-parallels-npm-update.*`. + - Скрипт записує вкладені журнали lane у `/tmp/openclaw-parallels-npm-update.*`. Перегляньте `windows-update.log`, `macos-update.log` або `linux-update.log`, - перш ніж припускати, що зовнішня обгортка зависла. - - Оновлення Windows може витратити 10-15 хвилин на post-update doctor/runtime - відновлення залежностей на холодному гості; це все ще нормальний стан, якщо вкладений + перш ніж вважати, що зовнішня обгортка зависла. + - Оновлення Windows може витратити 10-15 хвилин на post-update doctor/виправлення + залежностей середовища виконання на холодному гості; це все ще нормально, якщо вкладений debug-журнал npm просувається. - - Не запускайте цю агрегатну обгортку паралельно з окремими smoke-лініями Parallels - для macOS, Windows або Linux. Вони спільно використовують стан VM і можуть конфліктувати під час - відновлення snapshot, обслуговування пакета або стану Gateway у гості. - - Post-update-доказ запускає звичайну поверхню вбудованого Plugin, оскільки + - Не запускайте цю агреговану обгортку паралельно з окремими smoke-lane Parallels + macOS, Windows або Linux. Вони спільно використовують стан VM і можуть конфліктувати під час + відновлення snapshot, роздавання пакетів або стану gateway гостя. + - Post-update-підтвердження запускає звичайну поверхню вбудованого plugin, тому що фасади можливостей, як-от мовлення, генерація зображень і розуміння медіа, - завантажуються через вбудовані runtime API, навіть коли сам хід агента + завантажуються через вбудовані API середовища виконання, навіть коли сам хід агента перевіряє лише просту текстову відповідь. - `pnpm openclaw qa aimock` - Запускає лише локальний сервер провайдера AIMock для прямого smoke-тестування протоколу. - `pnpm openclaw qa matrix` - - Запускає live-лінію QA Matrix проти одноразового homeserver Tuwunel на базі Docker. Лише source-checkout — packaged installs не постачають `qa-lab`. - - Повний CLI, каталог профілів/сценаріїв, env vars і структура артефактів: [Matrix QA](/uk/concepts/qa-matrix). + - Запускає live-lane QA Matrix проти одноразового Docker-backed homeserver Tuwunel. Лише checkout вихідного коду — пакетні встановлення не постачають `qa-lab`. + - Повний CLI, каталог профілів/сценаріїв, змінні середовища й структура артефактів: [QA Matrix](/uk/concepts/qa-matrix). - `pnpm openclaw qa telegram` - - Запускає live-лінію QA Telegram проти справжньої приватної групи, використовуючи токени driver і SUT bot з env. - - Потребує `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Ідентифікатор групи має бути числовим chat id Telegram. - - Підтримує `--credential-source convex` для спільних pooled credentials. Типово використовуйте режим env або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases. - - Завершується з ненульовим кодом, коли будь-який сценарій завершується невдало. Використовуйте `--allow-failures`, коли вам + - Запускає live-lane QA Telegram проти справжньої приватної групи з використанням токенів driver і SUT bot із середовища. + - Потребує `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Ідентифікатор групи має бути числовим ідентифікатором чату Telegram. + - Підтримує `--credential-source convex` для спільних pooled credentials. Типово використовуйте режим env або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases. + - Завершується з ненульовим кодом, коли будь-який сценарій падає. Використовуйте `--allow-failures`, коли вам потрібні артефакти без коду завершення з помилкою. - - Потребує двох різних bot в одній приватній групі, причому SUT bot має надавати username Telegram. - - Для стабільного спостереження bot-to-bot увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох bot і переконайтеся, що driver bot може спостерігати груповий bot traffic. - - Записує звіт Telegram QA, підсумок і артефакт observed-messages у `.artifacts/qa-e2e/...`. Сценарії відповідей містять RTT від запиту надсилання driver до спостереженої відповіді SUT. + - Потребує двох різних bot в одній приватній групі, причому SUT bot має надавати ім'я користувача Telegram. + - Для стабільного спостереження bot-to-bot увімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох bot і переконайтеся, що driver bot може спостерігати груповий bot-трафік. + - Записує звіт QA Telegram, підсумок і артефакт спостережених повідомлень у `.artifacts/qa-e2e/...`. Сценарії з відповідями містять RTT від запиту надсилання driver до спостереженої відповіді SUT. -Live transport lines мають спільний стандартний контракт, щоб нові транспорти не відхилялися; матриця покриття по кожній лінії міститься в [Огляд QA → Покриття live transport](/uk/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` — це широкий синтетичний набір і він не є частиною цієї матриці. +Live transport lanes мають один стандартний контракт, щоб нові транспорти не розходилися; матриця покриття для кожної lane міститься в [огляді QA → Покриття live-транспортів](/uk/concepts/qa-e2e-automation#live-transport-coverage). `qa-channel` — це широкий синтетичний набір і не є частиною цієї матриці. ### Спільні облікові дані Telegram через Convex (v1) Коли `--credential-source convex` (або `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) увімкнено для -`openclaw qa telegram`, QA lab отримує ексклюзивну lease зі спільного пулу на базі Convex, надсилає Heartbeat -для цієї lease, поки лінія виконується, і звільняє lease під час завершення. +`openclaw qa telegram`, QA lab отримує ексклюзивну lease зі сховища на базі Convex, надсилає heartbeats +для цієї lease, поки lane виконується, і звільняє lease під час завершення. Еталонний scaffold проєкту Convex: - `qa/convex-credential-broker/` -Обов’язкові env vars: +Обов'язкові змінні середовища: - `OPENCLAW_QA_CONVEX_SITE_URL` (наприклад `https://your-deployment.convex.site`) -- Один secret для вибраної ролі: +- Один секрет для вибраної ролі: - `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER` для `maintainer` - `OPENCLAW_QA_CONVEX_SECRET_CI` для `ci` - Вибір ролі облікових даних: - CLI: `--credential-role maintainer|ci` - Типове значення env: `OPENCLAW_QA_CREDENTIAL_ROLE` (типово `ci` у CI, інакше `maintainer`) -Необов’язкові env vars: +Необов'язкові змінні середовища: - `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (типово `1200000`) - `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (типово `30000`) - `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (типово `90000`) - `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (типово `15000`) - `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (типово `/qa-credentials/v1`) -- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (необов’язковий trace id) -- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` URL Convex для суто локальної розробки. +- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (необов'язковий trace id) +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє URL Convex з loopback `http://` лише для локальної розробки. -`OPENCLAW_QA_CONVEX_SITE_URL` у звичайній роботі має використовувати `https://`. +`OPENCLAW_QA_CONVEX_SITE_URL` має використовувати `https://` у звичайній роботі. -Admin-команди maintainer (додати/видалити/перелічити пул) вимагають +Команди адміністрування для maintainers (додавання/видалення/список pool) потребують саме `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -CLI helpers для maintainer: +CLI-помічники для maintainers: ```bash pnpm openclaw qa credentials doctor @@ -338,163 +343,129 @@ pnpm openclaw qa credentials list --kind telegram pnpm openclaw qa credentials remove --credential-id ``` -Використовуйте `doctor` перед live-запусками, щоб перевірити URL сайту Convex, broker secrets, -префікс endpoint, HTTP timeout і доступність admin/list без друку -secret values. Використовуйте `--json` для машинно-читаного виводу в скриптах і CI -utilities. +Використовуйте `doctor` перед live-запусками, щоб перевірити URL сайту Convex, секрети broker, +префікс endpoint, HTTP timeout і доступність admin/list без виведення +секретних значень. Використовуйте `--json` для machine-readable виводу в скриптах і CI +утилітах. Типовий контракт endpoint (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): - `POST /acquire` - Запит: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` - Успіх: `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` - - Вичерпано/retryable: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` + - Вичерпано/можна повторити: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` - `POST /heartbeat` - Запит: `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` - Успіх: `{ status: "ok" }` (або порожній `2xx`) - `POST /release` - Запит: `{ kind, ownerId, actorRole, credentialId, leaseToken }` - Успіх: `{ status: "ok" }` (або порожній `2xx`) -- `POST /admin/add` (лише maintainer secret) +- `POST /admin/add` (лише секрет maintainer) - Запит: `{ kind, actorId, payload, note?, status? }` - Успіх: `{ status: "ok", credential }` -- `POST /admin/remove` (лише maintainer secret) +- `POST /admin/remove` (лише секрет maintainer) - Запит: `{ credentialId, actorId }` - Успіх: `{ status: "ok", changed, credential }` - - Захист активної lease: `{ status: "error", code: "LEASE_ACTIVE", ... }` -- `POST /admin/list` (лише maintainer secret) + - Захист active lease: `{ status: "error", code: "LEASE_ACTIVE", ... }` +- `POST /admin/list` (лише секрет maintainer) - Запит: `{ kind?, status?, includePayload?, limit? }` - Успіх: `{ status: "ok", credentials, count }` -Форма payload для Telegram kind: +Форма payload для виду Telegram: - `{ groupId: string, driverToken: string, sutToken: string }` -- `groupId` має бути числовим рядком chat id Telegram. -- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє некоректні payloads. +- `groupId` має бути рядком числового ідентифікатора чату Telegram. +- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє malformed payloads. ### Додавання каналу до QA -Архітектура та імена scenario-helper для нових адаптерів каналів описані в [Огляд QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна планка: реалізувати transport runner на спільному host seam `qa-lab`, оголосити `qaRunners` у маніфесті Plugin, змонтувати як `openclaw qa ` і створити сценарії в `qa/scenarios/`. +Архітектура й назви scenario-helper для нових адаптерів каналів містяться в [огляді QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна вимога: реалізувати transport runner на спільному host seam `qa-lab`, оголосити `qaRunners` у маніфесті plugin, змонтувати як `openclaw qa ` і створити сценарії в `qa/scenarios/`. -## Набори тестів (що де запускається) +## Тестові набори (що де запускається) -Думайте про набори як про «зростання реалістичності» (і зростання flaky/cost): +Думайте про набори як про «зростання реалістичності» (і зростання нестабільності/вартості): ### Unit / integration (типово) - Команда: `pnpm test` -- Конфігурація: нецільові запуски використовують shard set `vitest.full-*.config.ts` і можуть розгортати multi-project shards у per-project configs для паралельного планування -- Файли: core/unit inventories у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; UI unit tests запускаються у виділеному shard `unit-ui` +- Конфігурація: нецільові запуски використовують набір shard `vitest.full-*.config.ts` і можуть розгортати multi-project shards у конфігурації кожного проєкту для паралельного планування +- Файли: core/unit inventories у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; UI unit tests запускаються в окремому shard `unit-ui` - Область: - Чисті unit tests - - In-process integration tests (автентифікація Gateway, маршрутизація, tooling, parsing, config) - - Детерміновані регресії для відомих bugs + - In-process integration tests (auth gateway, routing, tooling, parsing, config) + - Детерміновані регресії для відомих багів - Очікування: - Запускається в CI - Не потребує справжніх ключів - Має бути швидким і стабільним - Тести resolver і public-surface loader мають доводити широку fallback-поведінку `api.js` і - `runtime-api.js` з generated tiny plugin fixtures, а не - реальними bundled plugin source APIs. Реальні завантаження plugin API належать до - contract/integration suites, власником яких є Plugin. + `runtime-api.js` з generated tiny plugin fixtures, а не з + справжніми source APIs вбудованих plugin. Справжні завантаження API plugin належать до + contract/integration suite, якими володіє plugin. - + - - Ненацілений `pnpm test` запускає дванадцять менших конфігурацій шардів (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного гігантського нативного процесу кореневого проєкту. Це зменшує піковий RSS на завантажених машинах і не дає роботі auto-reply/extension виснажувати ресурси для непов’язаних наборів тестів. - - `pnpm test --watch` і далі використовує нативний кореневий граф проєкту `vitest.config.ts`, бо цикл спостереження з кількома шардами непрактичний. - - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спершу спрямовують явні цілі файлів/каталогів через обмежені за областю доріжки, тому `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає повної стартової вартості кореневого проєкту. - - `pnpm test:changed` типово розгортає змінені git-шляхи в дешеві обмежені за областю доріжки: прямі зміни тестів, сусідні файли `*.test.ts`, явні зіставлення джерел і локальні залежні елементи графа імпортів. Зміни config/setup/package не запускають тести широко, якщо явно не використати `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. - - `pnpm check:changed` — це звичайний розумний локальний контрольний gate для вузької роботи. Він класифікує diff на core, тести core, extensions, тести extension, застосунки, docs, метадані release, інструменти live Docker і tooling, а потім запускає відповідні команди typecheck, lint і guard. Він не запускає тести Vitest; для тестового доказу викликайте `pnpm test:changed` або явний `pnpm test `. Зміни версій лише в метаданих release запускають цільові перевірки версії/config/кореневих залежностей із guard, який відхиляє зміни package за межами поля версії верхнього рівня. - - Зміни live Docker ACP harness запускають сфокусовані перевірки: shell-синтаксис для скриптів live Docker auth і dry-run планувальника live Docker. Зміни `package.json` включаються лише тоді, коли diff обмежений `scripts["test:docker:live-*"]`; зміни залежностей, експорту, версії та інших поверхонь package і далі використовують ширші guards. - - Легкі щодо імпортів unit-тести з agents, commands, plugins, допоміжних засобів auto-reply, `plugin-sdk` і подібних ділянок чистих утиліт проходять через доріжку `unit-fast`, яка пропускає `test/setup-openclaw-runtime.ts`; файли зі станом або важкі щодо runtime залишаються на наявних доріжках. - - Вибрані вихідні файли допоміжних засобів `plugin-sdk` і `commands` також зіставляють запуски в режимі changed з явними сусідніми тестами в цих легких доріжках, тож зміни допоміжних засобів уникають повторного запуску всього важкого набору для цього каталогу. - - `auto-reply` має окремі групи для високорівневих допоміжних засобів core, високорівневих інтеграційних тестів `reply.*` і піддерева `src/auto-reply/reply/**`. CI додатково розділяє піддерево reply на шарди agent-runner, dispatch і commands/state-routing, щоб одна група, важка щодо імпортів, не займала весь Node-хвіст. - - Звичайний CI для PR/main навмисно пропускає пакетний sweep extension і shard `agentic-plugins`, призначений лише для release. Full Release Validation запускає дочірній CI з `full_release_validation=true`, що знову вмикає ці важкі щодо plugin/extension набори для кандидатів у release. + - Ненацілений запуск `pnpm test` запускає дванадцять менших конфігурацій шардів (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного гігантського нативного процесу кореневого проєкту. Це зменшує піковий RSS на навантажених машинах і не дає роботі auto-reply/extension виснажувати непов’язані набори тестів. + - `pnpm test --watch` усе ще використовує нативний кореневий граф проєкту `vitest.config.ts`, бо багато-шардовий цикл спостереження непрактичний. + - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спершу маршрутизують явні цілі файлів/каталогів через scoped lanes, тому `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає повної вартості запуску кореневого проєкту. + - `pnpm test:changed` типово розгортає змінені git-шляхи в дешеві scoped lanes: прямі редагування тестів, сусідні файли `*.test.ts`, явні зіставлення з вихідним кодом і залежні елементи локального графа імпортів. Редагування 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 `. Version bumps лише release metadata запускають цільові перевірки version/config/root-dependency, із guard, який відхиляє зміни package поза верхньорівневим полем version. + - Редагування live Docker ACP harness запускають сфокусовані перевірки: shell syntax для live Docker auth scripts і dry-run live Docker scheduler. Зміни `package.json` включаються лише коли diff обмежений `scripts["test:docker:live-*"]`; dependency, export, version та інші редагування package-surface усе ще використовують ширші guards. + - Легкі щодо імпортів unit tests з agents, commands, plugins, auto-reply helpers, `plugin-sdk` і подібних чистих utility-ділянок маршрутизуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. + - Вибрані допоміжні файли вихідного коду `plugin-sdk` і `commands` також зіставляють запуски changed-mode з явними сусідніми тестами в цих light lanes, тому редагування helpers не перезапускають повний важкий набір для цього каталогу. + - `auto-reply` має окремі buckets для top-level core helpers, top-level інтеграційних тестів `reply.*` і піддерева `src/auto-reply/reply/**`. CI додатково розбиває reply subtree на shards agent-runner, dispatch і commands/state-routing, щоб один import-heavy bucket не володів усім Node tail. + - Звичайний PR/main CI навмисно пропускає extension batch sweep і release-only shard `agentic-plugins`. Full Release Validation запускає окремий дочірній workflow `Plugin Prerelease` для цих plugin/extension-heavy наборів на release candidates. - + - - Коли змінюєте вхідні дані виявлення message-tool або runtime-контекст compaction, - зберігайте обидва рівні покриття. - - Додавайте сфокусовані регресійні перевірки допоміжних засобів для чистих меж - маршрутизації та нормалізації. - - Підтримуйте справність інтеграційних наборів вбудованого runner: + - Коли змінюєте входи message-tool discovery або runtime-контекст compaction, зберігайте обидва рівні покриття. + - Додавайте сфокусовані 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`; тести лише допоміжних засобів - не є достатньою заміною для цих інтеграційних шляхів. + - Ці набори перевіряють, що scoped ids і поведінка compaction досі проходять через реальні шляхи `run.ts` / `compact.ts`; helper-only tests не є достатньою заміною для цих інтеграційних шляхів. - + - Базова конфігурація Vitest типово використовує `threads`. - - Спільна конфігурація Vitest фіксує `isolate: false` і використовує - неізольований runner у кореневих проєктах, e2e та live-конфігураціях. - - Коренева UI-доріжка зберігає свій setup і optimizer `jsdom`, але також працює - на спільному неізольованому runner. - - Кожен shard `pnpm test` успадковує ті самі типові значення `threads` + `isolate: false` - зі спільної конфігурації Vitest. - - `scripts/run-vitest.mjs` типово додає `--no-maglev` для дочірніх Node-процесів - Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. - Установіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною - поведінкою V8. + - Спільна конфігурація Vitest фіксує `isolate: false` і використовує non-isolated runner у кореневих проєктах, e2e та live configs. + - Кореневий UI lane зберігає свій setup `jsdom` і optimizer, але також працює на спільному non-isolated runner. + - Кожен shard `pnpm test` успадковує ті самі типові значення `threads` + `isolate: false` зі спільної конфігурації Vitest. + - `scripts/run-vitest.mjs` типово додає `--no-maglev` для дочірніх Node-процесів Vitest, щоб зменшити V8 compile churn під час великих локальних запусків. + Установіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8. - - `pnpm changed:lanes` показує, які архітектурні доріжки активує diff. - - Pre-commit hook виконує лише форматування. Він повторно додає відформатовані файли до staged - і не запускає lint, typecheck або тести. - - Запускайте `pnpm check:changed` явно перед передаванням роботи або push, коли вам - потрібен розумний локальний контрольний gate. - - `pnpm test:changed` типово проходить через дешеві обмежені за областю доріжки. Використовуйте - `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли agent - вирішить, що зміна harness, config, package або contract справді потребує ширшого - покриття Vitest. - - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, - лише з вищим обмеженням worker. - - Локальне автомасштабування worker навмисно консервативне й відступає, - коли середнє навантаження host уже високе, тому кілька одночасних - запусків Vitest типово завдають менше шкоди. - - Базова конфігурація Vitest позначає проєкти/config-файли як - `forceRerunTriggers`, щоб повторні запуски в режимі changed залишалися коректними, коли змінюється - підключення тестів. - - Конфігурація залишає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних - hosts; задайте `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете - одне явне розташування кешу для прямого профілювання. + - `pnpm changed:lanes` показує, які архітектурні lanes викликає diff. + - Pre-commit hook відповідає лише за форматування. Він повторно додає відформатовані файли до staging і не запускає lint, typecheck або тести. + - Запускайте `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 справді потребує ширшого покриття Vitest. + - `pnpm test:max` і `pnpm test:changed:max` зберігають ту саму поведінку маршрутизації, просто з вищим лімітом workers. + - Локальне autoscaling workers навмисно консервативне й відступає, коли load average хоста вже високий, тому кілька одночасних запусків Vitest типово завдають менше шкоди. + - Базова конфігурація Vitest позначає проєкти/config files як `forceRerunTriggers`, щоб reruns changed-mode лишалися коректними, коли змінюється тестове wiring. + - Конфігурація тримає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних хостах; установіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете одну явну cache location для direct profiling. - - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпортів, а також - вивід розбивки імпортів. - - `pnpm test:perf:imports:changed` обмежує той самий профільний перегляд - файлами, зміненими від `origin/main`. - - Дані часу шардів записуються до `.artifacts/vitest-shard-timings.json`. - Запуски всієї конфігурації використовують шлях конфігурації як ключ; CI-шарди - з include-патернами додають назву шарда, щоб відфільтровані шарди можна було - відстежувати окремо. - - Коли один гарячий тест усе ще витрачає більшість часу на стартові імпорти, - тримайте важкі залежності за вузьким локальним швом `*.runtime.ts` і - мокайте цей шов напряму, замість глибоко імпортувати runtime-хелпери лише - для того, щоб пропустити їх через `vi.mock(...)`. - - `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований - `test:changed` із нативним шляхом кореневого проєкту для цього закоміченого - diff і виводить wall time, а також macOS max RSS. - - `pnpm test:perf:changed:bench -- --worktree` бенчмаркить поточне - брудне дерево, маршрутизуючи список змінених файлів через - `scripts/test-projects.mjs` і кореневу конфігурацію Vitest. - - `pnpm test:perf:profile:main` записує CPU-профіль головного потоку для - накладних витрат запуску та трансформацій Vitest/Vite. - - `pnpm test:perf:profile:runner` записує CPU+heap-профілі runner для - unit-набору з вимкненим файловим паралелізмом. + - `pnpm test:perf:imports` вмикає звітування Vitest про import-duration плюс output import-breakdown. + - `pnpm test:perf:imports:changed` обмежує той самий profiling view файлами, зміненими з `origin/main`. + - Дані shard timing записуються в `.artifacts/vitest-shard-timings.json`. + Whole-config runs використовують шлях config як ключ; include-pattern CI shards додають назву shard, щоб filtered shards можна було відстежувати окремо. + - Коли один hot test досі витрачає більшість часу на startup imports, тримайте важкі залежності за вузьким локальним швом `*.runtime.ts` і mock that seam напряму замість deep-importing runtime helpers лише для передавання їх через `vi.mock(...)`. + - `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований `test:changed` із нативним шляхом root-project для цього committed diff і виводить wall time плюс macOS max RSS. + - `pnpm test:perf:changed:bench -- --worktree` benchmarks поточне dirty tree, маршрутизуючи список changed files через `scripts/test-projects.mjs` і кореневу конфігурацію Vitest. + - `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. @@ -503,284 +474,283 @@ utilities. - Команда: `pnpm test:stability:gateway` - Конфігурація: `vitest.gateway.config.ts`, примусово один worker -- Область: - - Запускає справжній loopback Gateway із діагностикою, увімкненою за замовчуванням - - Проганяє синтетичний gateway-повідомлення, пам'ять і churn великих payload через шлях діагностичних подій +- Обсяг: + - Запускає реальний loopback Gateway із diagnostics, типово увімкненими + - Проганяє synthetic gateway message, memory і large-payload churn через diagnostic event path - Запитує `diagnostics.stability` через Gateway WS RPC - - Покриває хелпери збереження пакета діагностичної стабільності - - Перевіряє, що recorder залишається обмеженим, синтетичні RSS-семпли лишаються нижче бюджету тиску, а глибини черг для кожної сесії знову спадають до нуля + - Покриває helpers збереження diagnostic stability bundle + - Перевіряє, що recorder лишається bounded, synthetic RSS samples залишаються нижче pressure budget, а per-session queue depths повертаються до нуля - Очікування: - - Безпечно для CI і без ключів - - Вузька лінія для подальшої роботи над регресіями стабільності, не заміна повного набору Gateway + - CI-safe і без ключів + - Вузький lane для stability-regression follow-up, не заміна повного Gateway suite ### E2E (gateway smoke) - Команда: `pnpm test:e2e` - Конфігурація: `vitest.e2e.config.ts` -- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і E2E-тести bundled-plugin у `extensions/` -- Runtime-типові значення: - - Використовує Vitest `threads` з `isolate: false`, як і решта репозиторію. - - Використовує адаптивних workers (CI: до 2, локально: 1 за замовчуванням). - - За замовчуванням працює в тихому режимі, щоб зменшити накладні витрати console I/O. -- Корисні перевизначення: - - `OPENCLAW_E2E_WORKERS=` для примусового встановлення кількості workers (обмежено 16). - - `OPENCLAW_E2E_VERBOSE=1` для повторного ввімкнення докладного виводу консолі. -- Область: - - Наскрізна поведінка gateway з кількома інстансами - - WebSocket/HTTP-поверхні, pairing Node і важча мережева взаємодія +- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і bundled-plugin E2E tests у `extensions/` +- Типові значення runtime: + - Використовує Vitest `threads` із `isolate: false`, як і решта репозиторію. + - Використовує adaptive workers (CI: до 2, локально: типово 1). + - Типово працює в silent mode, щоб зменшити console I/O overhead. +- Корисні overrides: + - `OPENCLAW_E2E_WORKERS=` для примусового worker count (обмежено 16). + - `OPENCLAW_E2E_VERBOSE=1` для повторного ввімкнення verbose console output. +- Обсяг: + - End-to-end поведінка multi-instance gateway + - WebSocket/HTTP surfaces, node pairing і важча networking - Очікування: - - Працює в CI (коли ввімкнено в pipeline) + - Запускається в CI (коли ввімкнено в pipeline) - Реальні ключі не потрібні - - Більше рухомих частин, ніж в unit-тестах (може бути повільніше) + - Більше рухомих частин, ніж у unit tests (може бути повільніше) -### E2E: smoke бекенда OpenShell +### E2E: OpenShell backend smoke - Команда: `pnpm test:e2e:openshell` - Файл: `extensions/openshell/src/backend.e2e.test.ts` -- Область: +- Обсяг: - Запускає ізольований OpenShell gateway на хості через Docker - Створює sandbox із тимчасового локального Dockerfile - - Перевіряє бекенд OpenShell в OpenClaw через справжній `sandbox ssh-config` + SSH exec - - Перевіряє remote-canonical поведінку файлової системи через sandbox fs bridge + - Перевіряє OpenShell backend OpenClaw через реальні `sandbox ssh-config` + SSH exec + - Перевіряє remote-canonical filesystem behavior через sandbox fs bridge - Очікування: - - Лише opt-in; не входить до стандартного запуску `pnpm test:e2e` - - Потребує локального `openshell` CLI і робочого Docker daemon - - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує тестовий gateway і sandbox -- Корисні перевизначення: - - `OPENCLAW_E2E_OPENSHELL=1` для ввімкнення тесту під час ручного запуску ширшого e2e-набору - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` для вказання нестандартного CLI-бінарника або wrapper-скрипта + - Лише opt-in; не є частиною типового запуску `pnpm test:e2e` + - Потребує локального CLI `openshell` і робочого Docker daemon + - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, потім знищує test gateway і sandbox +- Корисні overrides: + - `OPENCLAW_E2E_OPENSHELL=1` для ввімкнення тесту під час ручного запуску ширшого e2e suite + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` для вказання нетипового CLI binary або wrapper script -### Live (реальні providers + реальні моделі) +### Live (реальні providers + реальні models) - Команда: `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`) -- Область: - - “Чи цей provider/model справді працює _сьогодні_ з реальними creds?” - - Ловить зміни форматів provider, особливості tool-calling, проблеми auth і поведінку rate limit +- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і bundled-plugin live tests у `extensions/` +- Типово: **увімкнено** через `pnpm test:live` (установлює `OPENCLAW_LIVE_TEST=1`) +- Обсяг: + - “Чи цей provider/model фактично працює _сьогодні_ з реальними creds?” + - Виявляє provider format changes, tool-calling quirks, auth issues і rate limit behavior - Очікування: - - За задумом не є стабільним для CI (реальні мережі, реальні політики provider, квоти, збої) + - Не CI-stable за задумом (реальні мережі, реальні provider policies, quotas, outages) - Коштує грошей / використовує rate limits - - Надавайте перевагу запуску звужених піднаборів замість “усього” -- Live-запуски source-ять `~/.profile`, щоб підхопити відсутні API-ключі. -- За замовчуванням live-запуски все одно ізолюють `HOME` і копіюють config/auth-матеріали в тимчасовий тестовий home, щоб unit-fixtures не могли змінити ваш справжній `~/.openclaw`. -- Встановлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли вам навмисно потрібно, щоб live-тести використовували ваш справжній домашній каталог. -- `pnpm test:live` тепер за замовчуванням працює тихіше: він залишає progress-вивід `[live] ...`, але приглушує додаткове повідомлення `~/.profile` і mute-ить логи bootstrap Gateway/Bonjour chatter. Встановіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні startup-логи. -- Ротація API-ключів (provider-specific): задайте `*_API_KEYS` у форматі з комами/крапками з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або per-live override через `OPENCLAW_LIVE_*_KEY`; тести повторюють спроби на відповідях rate limit. -- Вивід progress/heartbeat: - - Live-набори тепер виводять progress-рядки до stderr, щоб довгі provider-виклики були видимо активними навіть тоді, коли capture консолі Vitest тихий. - - `vitest.live.config.ts` вимикає перехоплення консолі Vitest, щоб progress-рядки provider/gateway стрімилися негайно під час live-запусків. - - Налаштовуйте Heartbeat direct-model через `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Налаштовуйте Heartbeat gateway/probe через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. + - Надавайте перевагу запуску звужених subsets замість “everything” +- Live runs source `~/.profile`, щоб підхопити відсутні API keys. +- Типово live runs усе ще ізолюють `HOME` і копіюють config/auth material у тимчасовий test home, щоб unit fixtures не могли змінити ваш реальний `~/.openclaw`. +- Установлюйте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише коли навмисно потрібно, щоб live tests використовували ваш справжній home directory. +- `pnpm test:live` тепер типово використовує тихіший режим: він зберігає progress output `[live] ...`, але приглушує додаткове повідомлення `~/.profile` і вимикає gateway bootstrap logs/Bonjour chatter. Установіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні startup logs. +- Ротація API key (provider-specific): задайте `*_API_KEYS` у форматі з комами/крапками з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) чи per-live override через `OPENCLAW_LIVE_*_KEY`; тести retry on rate limit responses. +- Progress/heartbeat output: + - Live suites тепер emit progress lines до stderr, щоб довгі provider calls були явно активні, навіть коли Vitest console capture тихий. + - `vitest.live.config.ts` вимикає Vitest console interception, щоб provider/gateway progress lines stream негайно під час live runs. + - Налаштовуйте direct-model heartbeats через `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Налаштовуйте gateway/probe heartbeats через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. -## Який набір мені запускати? +## Який suite запускати? -Скористайтеся цією таблицею рішень: +Використовуйте цю таблицю рішень: - Редагування логіки/тестів: запустіть `pnpm test` (і `pnpm test:coverage`, якщо ви змінили багато) -- Зміни в мережевій частині Gateway / WS-протоколі / сполученні: додайте `pnpm test:e2e` -- Налагодження «мій бот не працює» / збоїв, специфічних для провайдера / виклику інструментів: запустіть звужений `pnpm test:live` +- Зміни в мережевій взаємодії Gateway / протоколі WS / сполученні: додайте `pnpm test:e2e` +- Налагодження “мій бот недоступний” / збоїв, специфічних для провайдера / виклику інструментів: запустіть звужений `pnpm test:live` -## Live-тести (що торкаються мережі) +## Live (тести з доступом до мережі) -Про live-матрицю моделей, smoke-тести бекенда CLI, smoke-тести ACP, тестовий -harness сервера застосунку Codex і всі live-тести медіапровайдерів (Deepgram, -BytePlus, ComfyUI, зображення, музика, відео, медіа-harness) — а також обробку -облікових даних для live-запусків — дивіться в +Про live-матрицю моделей, димові перевірки CLI backend, димові перевірки ACP, harness app-server Codex +і всі live-тести медіапровайдерів (Deepgram, BytePlus, ComfyUI, зображення, +музика, відео, медіа-harness), а також обробку облікових даних для live-запусків див. [Тестування — live-набори](/uk/help/testing-live). -## Docker-ранери (необов’язкові перевірки «працює в Linux») +## Docker runners (необов’язкові перевірки "працює в Linux") -Ці Docker-ранери поділяються на дві групи: +Ці Docker runners поділяються на два кошики: -- Ранери live-моделей: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл ключа профілю всередині 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-ранери за замовчуванням використовують меншу межу smoke-перевірок, щоб повний Docker-прогін залишався практичним: - `test:docker:live-models` за замовчуванням має `OPENCLAW_LIVE_MAX_MODELS=12`, а - `test:docker:live-gateway` за замовчуванням має `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, +- Live-model runners: `test:docker:live-models` і `test:docker:live-gateway` запускають лише відповідний live-файл profile-key всередині Docker-образу репозиторію (`src/agents/models.profiles.live.test.ts` і `src/gateway/gateway-models.profiles.live.test.ts`), монтують ваш локальний каталог конфігурації та робочу область (і підключають `~/.profile`, якщо його змонтовано). Відповідні локальні точки входу: `test:live:models-profiles` і `test:live:gateway-profiles`. +- Docker live runners типово мають меншу межу для димових перевірок, щоб повний 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-змінні, коли - вам явно потрібне ширше вичерпне сканування. -- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, один раз пакує OpenClaw як npm-tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Bare-образ — це лише 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-напрямам стартувати одночасно. Якщо окремий напрям важчий за активні обмеження, планувальник усе одно може запустити його, коли пул порожній, а потім тримає його єдиним запущеним, доки знову не з’явиться місткість. Типові значення: 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-хост має більше запасу. Ранер за замовчуванням виконує Docker-перевірку preflight, видаляє застарілі E2E-контейнери OpenClaw, друкує статус кожні 30 секунд, зберігає часи успішних напрямів у `.artifacts/docker-tests/lane-timings.json` і використовує ці часи, щоб у наступних запусках спершу стартували довші напрями. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб надрукувати зважений маніфест напрямів без збирання чи запуску Docker, або `node scripts/test-docker-all.mjs --plan-json`, щоб надрукувати CI-план для вибраних напрямів, потреб пакета/образу та облікових даних. -- `Package Acceptance` — це нативний для GitHub пакетний gate для питання «чи працює цей installable tarball як продукт?» Він визначає один кандидатний пакет із `source=npm`, `source=ref`, `source=url` або `source=artifact`, завантажує його як `package-under-test`, а потім запускає багаторазові Docker E2E-напрями проти саме цього tarball замість повторного пакування вибраного ref. `workflow_ref` вибирає довірені workflow/harness-скрипти, тоді як `package_ref` вибирає коміт/гілку/тег джерела для пакування, коли `source=ref`; це дає змогу поточній логіці acceptance перевіряти старіші довірені коміти. Профілі впорядковано за широтою: `smoke` — швидкі install/channel/agent плюс gateway/config, `package` — контракт package/update/plugin і типовий нативний замінник більшості покриття Parallels для package/update, `product` додає MCP-канали, очищення cron/subagent, вебпошук OpenAI і OpenWebUI, а `full` запускає Docker-фрагменти release-path з OpenWebUI. Перевірка релізу запускає користувацьку дельту пакета (`bundled-channel-deps-compat plugins-offline`) плюс QA пакета Telegram, бо Docker-фрагменти release-path уже покривають перетинні напрями package/update/plugin. Цільові команди повторного запуску GitHub Docker, згенеровані з артефактів, містять попередній артефакт пакета та підготовлені вхідні дані образів, коли вони доступні, тож невдалі напрями можуть уникнути повторного збирання пакета й образів. -- Перевірки збирання та релізу запускають `scripts/check-cli-bootstrap-imports.mjs` після tsdown. Захист обходить статичний зібраний граф із `dist/entry.js` і `dist/cli/run-main.js` та завершується з помилкою, якщо запуск до диспетчеризації команд імпортує пакетні залежності, як-от Commander, prompt UI, undici або логування, до диспетчеризації команди; він також утримує зібраний gateway run chunk у межах бюджету й відхиляє статичні імпорти відомих холодних шляхів Gateway. Smoke-перевірка упакованого CLI також покриває кореневу довідку, довідку onboard, довідку doctor, status, схему config і команду списку моделей. -- Сумісність Package Acceptance зі спадковими версіями обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цієї межі harness терпить лише прогалини метаданих відвантаженого пакета: пропущені приватні записи QA-інвентарю, відсутній `gateway install --wrapper`, відсутні patch-файли у git-фікстурі, отриманій із tarball, відсутній збережений `update.channel`, спадкові розташування install-record Plugin, відсутнє збереження marketplace install-record і міграцію метаданих config під час `plugins update`. Для пакетів після `2026.4.25` ці шляхи є суворими помилками. -- Контейнерні smoke-ранери: `test:docker:openwebui`, `test:docker:onboard`, `test:docker:npm-onboard-channel-agent`, `test:docker:update-channel-switch`, `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` запускають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. + `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці змінні env, коли ви + явно хочете більший вичерпний скан. +- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, один раз пакує OpenClaw як npm-архів tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Голий образ є лише Node/Git runner для напрямів 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 напрямам стартувати одночасно. Якщо один напрям важчий за активні обмеження, планувальник усе одно може запустити його, коли пул порожній, і потім тримає його запущеним наодинці, доки місткість знову не стане доступною. Типові значення: 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, видаляє застарілі E2E-контейнери OpenClaw, друкує статус кожні 30 секунд, зберігає таймінги успішних напрямів у `.artifacts/docker-tests/lane-timings.json` і використовує ці таймінги, щоб у наступних запусках починати з довших напрямів. Використовуйте `OPENCLAW_DOCKER_ALL_DRY_RUN=1`, щоб надрукувати зважений маніфест напрямів без збирання або запуску Docker, або `node scripts/test-docker-all.mjs --plan-json`, щоб надрукувати CI-план для вибраних напрямів, потреб пакетів/образів і облікових даних. +- `Package Acceptance` — це нативний для GitHub шлюз пакета для питання "чи працює цей встановлюваний tarball як продукт?" Він визначає один кандидатний пакет із `source=npm`, `source=ref`, `source=url` або `source=artifact`, завантажує його як `package-under-test`, а потім запускає повторно використовувані Docker E2E-напрями проти саме цього tarball замість перепакування вибраного ref. `workflow_ref` вибирає довірені сценарії workflow/harness, а `package_ref` вибирає початковий commit/branch/tag для пакування, коли `source=ref`; це дає змогу поточній логіці приймання перевіряти старіші довірені commits. Профілі впорядковані за широтою: `smoke` — це швидкі install/channel/agent плюс gateway/config, `package` — це контракт package/update/plugin і типовий нативний замінник більшості покриття package/update у Parallels, `product` додає канали MCP, очищення cron/subagent, вебпошук OpenAI і OpenWebUI, а `full` запускає Docker-фрагменти release-path з OpenWebUI. Перевірка релізу запускає власну package delta (`bundled-channel-deps-compat plugins-offline`) плюс Telegram package QA, бо Docker-фрагменти release-path уже покривають перехресні напрями package/update/plugin. Цільові команди GitHub Docker для повторного запуску, згенеровані з артефактів, містять попередній артефакт пакета та підготовлені вхідні образи, коли вони доступні, тож невдалі напрями можуть уникнути повторного збирання пакета й образів. +- Перевірки збирання та релізу запускають `scripts/check-cli-bootstrap-imports.mjs` після tsdown. Захист проходить статичний зібраний граф від `dist/entry.js` і `dist/cli/run-main.js` і завершується з помилкою, якщо запуск до dispatch статично імпортує залежності пакета, як-от Commander, prompt UI, undici або логування, до dispatch команди; він також утримує зібраний gateway run chunk у межах бюджету й відхиляє статичні імпорти відомих cold gateway paths. Димова перевірка packaged CLI також покриває root help, onboard help, doctor help, status, config schema і команду model-list. +- Legacy-сумісність Package Acceptance обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цієї межі harness допускає лише прогалини метаданих відвантаженого пакета: пропущені приватні записи інвентарю QA, відсутній `gateway install --wrapper`, відсутні patch-файли у git-фікстурі, похідній від tarball, відсутній збережений `update.channel`, застарілі розташування install-record для Plugin, відсутнє збереження marketplace install-record і міграція метаданих конфігурації під час `plugins update`. Для пакетів після `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: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` завантажують один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. -Docker-ранери live-моделей також bind-mount-ять лише потрібні домівки CLI-автентифікації (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у домівку контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени без мутації сховища автентифікації хоста: +Live-model Docker runners також bind-mount лише потрібні домівки автентифікації CLI (або всі підтримувані, коли запуск не звужений), а потім копіюють їх у домашній каталог контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени без зміни сховища автентифікації хоста: - Прямі моделі: `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`) -- 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`) +- Smoke для бекенду CLI: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) +- Smoke для harness сервера застосунку Codex: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) - Gateway + агент розробки: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`) -- Observability smoke: `pnpm qa:otel:smoke` є приватною QA-гілкою перевірки source-checkout. Вона навмисно не входить до Docker-гілок випуску пакета, тому що npm tarball не містить QA Lab. -- Open WebUI live smoke: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) -- Майстер початкового налаштування (TTY, повне створення каркаса): `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 onboarding плюс Telegram за замовчуванням, перевіряє, що doctor відновлює активовані runtime-залежності Plugin, і запускає один змокований хід агента OpenAI. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропускайте перебудову на хості через `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або перемикайте канал через `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. -- Update channel switch smoke: `pnpm test:docker:update-channel-switch` глобально встановлює запакований OpenClaw tarball у Docker, перемикається з пакетного `stable` на git `dev`, перевіряє збережений канал і роботу Plugin після оновлення, потім перемикається назад на пакетний `stable` і перевіряє статус оновлення. -- Session runtime context smoke: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого runtime-контексту в транскрипті плюс doctor-відновлення зачеплених дубльованих гілок prompt-rewrite. -- Bun global install smoke: `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`. -- Installer Docker smoke: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm-кеш між своїми root, update і direct-npm контейнерами. Update smoke за замовчуванням використовує npm `latest` як стабільний baseline перед оновленням до кандидатного tarball. Перевизначайте через `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` локально або через вхід `update_baseline_version` workflow Install Smoke на GitHub. Перевірки встановлювача без root зберігають ізольований npm-кеш, щоб записи кешу, що належать root, не маскували поведінку локального для користувача встановлення. Встановіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати кеш root/update/direct-npm між локальними повторними запусками. -- Install Smoke CI пропускає дубльоване глобальне оновлення direct-npm через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`. -- Agents delete shared workspace CLI smoke: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) за замовчуванням збирає кореневий образ Dockerfile, засіває двох агентів з одним 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`. +- Smoke для спостережуваності: `pnpm qa:otel:smoke` є приватною QA-лінією з source checkout. Вона навмисно не входить до package Docker release lanes, бо npm tarball не містить QA Lab. +- Live smoke для Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) +- Майстер onboarding (TTY, повне створення scaffold): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) +- Smoke npm tarball для onboarding/каналу/агента: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований tarball OpenClaw у Docker, налаштовує OpenAI через onboarding з env-ref і Telegram за замовчуванням, перевіряє, що doctor відновив активовані залежності runtime Plugin, і запускає один замоканий хід агента 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, перемикає з package `stable` на git `dev`, перевіряє збережений канал і роботу Plugin після оновлення, потім перемикає назад на package `stable` і перевіряє статус оновлення. +- Smoke контексту runtime сесії: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого transcript контексту runtime плюс doctor repair для зачеплених дубльованих гілок 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`. +- Docker smoke інсталятора: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm cache між контейнерами root, update і direct-npm. Smoke оновлення за замовчуванням використовує npm `latest` як стабільну базову версію перед оновленням до candidate tarball. Перевизначте локально через `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` або через вхід `update_baseline_version` workflow Install Smoke на GitHub. Перевірки інсталятора без root зберігають ізольований npm cache, щоб записи cache, що належать root, не маскували поведінку встановлення user-local. Задайте `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати cache root/update/direct-npm між локальними повторними запусками. +- Install Smoke CI пропускає дубльоване глобальне оновлення direct-npm через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цієї env, коли потрібне покриття прямого `npm install -g`. +- CLI smoke видалення спільного workspace агентів: `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` і перевіряє, що snapshot-и CDP-ролей охоплюють URL посилань, clickables, підвищені з курсора, iframe refs і метадані 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`, потім примусово спричиняє reject схеми провайдера й перевіряє, що raw detail з’являється в логах Gateway. -- MCP channel bridge (засіяний 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 teardown після ізольованого cron і одноразових subagent-запусків): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Плагіни (install smoke, ClawHub kitchen-sink install/uninstall, marketplace updates і Claude-bundle enable/inspect): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) - Встановіть `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб пропустити блок ClawHub, або перевизначте стандартну пару kitchen-sink package/runtime через `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` і `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Без `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` тест використовує герметичний локальний fixture-сервер 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`) -- Bundled plugin runtime deps: `pnpm test:docker:bundled-channel-deps` за замовчуванням збирає невеликий образ Docker runner, один раз збирає й пакує OpenClaw на хості, а потім монтує цей tarball у кожен сценарій встановлення Linux. Повторно використовуйте образ через `OPENCLAW_SKIP_DOCKER_BUILD=1`, пропускайте перебудову на хості після свіжої локальної збірки через `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` або вкажіть наявний tarball через `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. Повний Docker aggregate і release-path bundled-channel chunks попередньо пакують цей tarball один раз, а потім шардують перевірки bundled channel в незалежні гілки, включно з окремими update lanes для Telegram, Discord, Slack, Feishu, memory-lancedb і ACPX. Release chunks розділяють channel smokes, update targets і setup/runtime contracts на `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` і `bundled-channels-contracts`; aggregate chunk `bundled-channels` залишається доступним для ручних повторних запусків. Release workflow також розділяє provider installer chunks і bundled plugin install/uninstall chunks; застарілі chunks `package-update`, `plugins-runtime` і `plugins-integrations` залишаються aggregate aliases для ручних повторних запусків. Використовуйте `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, щоб звузити channel matrix під час прямого запуску bundled lane, або `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, щоб звузити update scenario. Docker-запуски для окремих сценаріїв за замовчуванням мають `OPENCLAW_BUNDLED_CHANNEL_DOCKER_RUN_TIMEOUT=900s`; multi-target update scenario за замовчуванням має `OPENCLAW_BUNDLED_CHANNEL_UPDATE_DOCKER_RUN_TIMEOUT=2400s`. Lane також перевіряє, що `channels..enabled=false` і `plugins.entries..enabled=false` пригнічують doctor/runtime-dependency repair. -- Звужуйте bundled plugin runtime deps під час ітерацій, вимикаючи непов’язані сценарії, наприклад: +- 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` і перевіряє, що snapshots ролей CDP охоплюють URL посилань, клікабельні елементи, підняті курсором, iframe refs і metadata фреймів. +- Регресія мінімального reasoning для OpenAI Responses web_search: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає замоканий сервер OpenAI через Gateway, перевіряє, що `web_search` підвищує `reasoning.effort` з `minimal` до `low`, потім примусово викликає reject схеми провайдера й перевіряє, що raw detail з'являється в логах Gateway. +- MCP channel bridge (засіяний Gateway + stdio bridge + smoke raw Claude notification-frame): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) +- Pi bundle MCP tools (реальний 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 cleanup (реальний Gateway + демонтаж stdio MCP child після ізольованих запусків cron і одноразового subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Plugins (install smoke, kitchen-sink install/uninstall ClawHub, marketplace updates і ввімкнення/inspect Claude-bundle): `pnpm test:docker:plugins` (скрипт: `scripts/e2e/plugins-docker.sh`) + Задайте `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб пропустити блок ClawHub, або перевизначте стандартну пару kitchen-sink package/runtime через `OPENCLAW_PLUGINS_E2E_CLAWHUB_SPEC` і `OPENCLAW_PLUGINS_E2E_CLAWHUB_ID`. Без `OPENCLAW_CLAWHUB_URL`/`CLAWHUB_URL` тест використовує герметичний локальний fixture server ClawHub. +- Smoke незміненого оновлення Plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) +- Smoke metadata перезавантаження config: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) +- Залежності runtime вбудованого Plugin: `pnpm test:docker:bundled-channel-deps` за замовчуванням збирає невеликий Docker runner image, один раз збирає й пакує OpenClaw на хості, а потім монтує цей tarball у кожен сценарій встановлення Linux. Повторно використайте image через `OPENCLAW_SKIP_DOCKER_BUILD=1`, пропустіть перебудову на хості після свіжої локальної збірки через `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` або вкажіть наявний tarball через `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. Повний Docker aggregate і bundled-channel chunks release-path попередньо пакують цей tarball один раз, потім shard-ять bundled channel checks в незалежні lanes, зокрема окремі update lanes для Telegram, Discord, Slack, Feishu, memory-lancedb і ACPX. Release chunks розділяють channel smokes, update targets і setup/runtime contracts на `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` і `bundled-channels-contracts`; aggregate chunk `bundled-channels` лишається доступним для ручних повторних запусків. Release workflow також розділяє provider installer chunks і chunks install/uninstall вбудованих Plugin; legacy chunks `package-update`, `plugins-runtime` і `plugins-integrations` лишаються aggregate aliases для ручних повторних запусків. Використовуйте `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, щоб звузити матрицю каналів під час прямого запуску bundled lane, або `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, щоб звузити сценарій оновлення. Docker runs для окремого сценарію за замовчуванням використовують `OPENCLAW_BUNDLED_CHANNEL_DOCKER_RUN_TIMEOUT=900s`; multi-target update scenario за замовчуванням використовує `OPENCLAW_BUNDLED_CHANNEL_UPDATE_DOCKER_RUN_TIMEOUT=2400s`. Ця lane також перевіряє, що `channels..enabled=false` і `plugins.entries..enabled=false` придушують doctor/runtime-dependency repair. +- Звужуйте залежності runtime вбудованого Plugin під час ітерацій, вимикаючи непов'язані сценарії, наприклад: `OPENCLAW_BUNDLED_CHANNEL_SCENARIOS=0 OPENCLAW_BUNDLED_CHANNEL_UPDATE_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_ROOT_OWNED_SCENARIO=0 OPENCLAW_BUNDLED_CHANNEL_SETUP_ENTRY_SCENARIO=0 pnpm test:docker:bundled-channel-deps`. -Щоб вручну попередньо зібрати й повторно використовувати спільний функціональний образ: +Щоб вручну попередньо зібрати й повторно використати спільний функціональний image: ```bash OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local pnpm test:docker:e2e-build OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels ``` -Перевизначення образів для конкретних suite, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе ще мають перевагу, коли встановлені. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний образ, скрипти pull-ять його, якщо він ще не локальний. QR і Docker-тести встановлювача зберігають власні Dockerfile, тому що вони перевіряють поведінку package/install, а не спільний runtime зібраного застосунку. +Suite-specific image overrides, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе одно мають пріоритет, коли задані. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний image, скрипти pull-ять його, якщо він ще не локальний. Docker-тести QR та інсталятора зберігають власні Dockerfiles, бо вони перевіряють поведінку package/install, а не спільний runtime зібраного застосунку. -Live-model Docker runners також bind-mount-ять поточний checkout лише для читання і -стейджать його в тимчасовий workdir усередині контейнера. Це зберігає runtime -image компактним, але все одно запускає Vitest проти вашого точного локального source/config. -Крок staging пропускає великі локальні кеші та build outputs застосунків, як-от -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також локальні для застосунку `.build` або -каталоги виводу Gradle, щоб Docker live runs не витрачали хвилини на копіювання -машинно-специфічних artifacts. -Вони також встановлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб gateway live probes не запускали -реальних Telegram/Discord/тощо channel workers усередині контейнера. +Docker runners live-model також bind-mount-ять поточний checkout лише для читання й +stage-ять його в тимчасовий workdir усередині контейнера. Це зберігає runtime +image компактним, водночас запускаючи Vitest проти вашого точного локального source/config. +Крок staging пропускає великі локальні cache та build outputs застосунків, як-от +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, і app-local `.build` або +output directories Gradle, щоб Docker live runs не витрачали хвилини на копіювання +machine-specific artifacts. +Вони також задають `OPENCLAW_SKIP_CHANNELS=1`, щоб live probes Gateway не запускали +реальних workers каналів Telegram/Discord/тощо всередині контейнера. `test:docker:live-models` усе ще запускає `pnpm test:live`, тому також передавайте `OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити gateway -live coverage із цієї Docker lane. -`test:docker:openwebui` є compatibility smoke вищого рівня: він запускає +live coverage з цієї Docker lane. +`test:docker:openwebui` є smoke сумісності вищого рівня: він запускає контейнер Gateway OpenClaw з увімкненими HTTP endpoints, сумісними з OpenAI, -запускає pinned Open WebUI container проти цього gateway, входить через -Open WebUI, перевіряє, що `/api/models` expose-ить `openclaw/default`, потім надсилає -реальний chat request через proxy Open WebUI `/api/chat/completions`. +запускає контейнер pinned Open WebUI проти цього Gateway, входить через +Open WebUI, перевіряє, що `/api/models` exposes `openclaw/default`, потім надсилає +реальний chat request через proxy `/api/chat/completions` Open WebUI. Перший запуск може бути помітно повільнішим, бо Docker може потребувати pull -образу Open WebUI, а Open WebUI може потребувати завершення власного cold-start setup. -Ця lane очікує придатний live model key, і `OPENCLAW_PROFILE_FILE` +image Open WebUI, а Open WebUI може потребувати завершення власного cold-start setup. +Ця lane очікує придатний ключ live model, а `OPENCLAW_PROFILE_FILE` (`~/.profile` за замовчуванням) є основним способом надати його в Dockerized runs. Успішні запуски друкують невеликий JSON payload на кшталт `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` навмисно детермінований і не потребує реального облікового запису Telegram, Discord або iMessage. Він завантажує засіяний контейнер Gateway, запускає другий контейнер, який spawn-ить `openclaw mcp serve`, потім -перевіряє routed conversation discovery, transcript reads, attachment metadata, -live event queue behavior, outbound send routing і Claude-style channel + -permission notifications через реальний stdio MCP bridge. Notification check -напряму інспектує raw stdio MCP frames, щоб smoke перевіряв те, що -bridge фактично emits, а не лише те, що випадково surface-ить конкретний client SDK. +перевіряє routed conversation discovery, transcript reads, metadata вкладень, +поведінку live event queue, outbound send routing і notifications каналу в стилі Claude + +permission через реальний stdio MCP bridge. Перевірка notification +безпосередньо інспектує raw stdio MCP frames, щоб smoke validates те, що +bridge насправді emits, а не лише те, що випадково surface-ить конкретний client SDK. `test:docker:pi-bundle-mcp-tools` детермінований і не потребує live -model key. Він збирає repo Docker image, запускає реальний stdio MCP probe server -усередині контейнера, materializes цей сервер через embedded Pi bundle +model key. Він збирає Docker image repo, запускає реальний stdio MCP probe server +усередині контейнера, матеріалізує цей server через вбудований Pi bundle MCP runtime, виконує tool, а потім перевіряє, що `coding` і `messaging` зберігають -`bundle-mcp` tools, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують. +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 child process завершується після кожного запуску. +ізольований cron turn і одноразовий child turn `/subagents spawn`, потім перевіряє, +що child process MCP завершується після кожного запуску. Ручний ACP plain-language thread smoke (не CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Залиште цей скрипт для робочих процесів регресії/налагодження. Він може знову знадобитися для перевірки маршрутизації потоків ACP, тому не видаляйте його. +- Зберігайте цей скрипт для регресійних і налагоджувальних робочих процесів. Він може знову знадобитися для перевірки маршрутизації ACP-тредів, тому не видаляйте його. Корисні змінні середовища: -- `OPENCLAW_CONFIG_DIR=...` (типово: `~/.openclaw`) монтується до `/home/node/.openclaw` -- `OPENCLAW_WORKSPACE_DIR=...` (типово: `~/.openclaw/workspace`) монтується до `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (типово: `~/.profile`) монтується до `/home/node/.profile` і завантажується перед запуском тестів -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, щоб перевіряти лише змінні середовища, завантажені з `OPENCLAW_PROFILE_FILE`, використовуючи тимчасові каталоги конфігурації/робочої області та без монтування зовнішньої автентифікації CLI -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (типово: `~/.cache/openclaw/docker-cli-tools`) монтується до `/home/node/.npm-global` для кешованих встановлень CLI у Docker -- Зовнішні каталоги/файли автентифікації CLI під `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються до `/home/node/...` перед запуском тестів +- `OPENCLAW_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_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=...`, щоб фільтрувати провайдерів усередині контейнера -- `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб повторно використати наявний образ `openclaw:local-live` для повторних запусків, яким не потрібне повторне збирання -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб переконатися, що облікові дані надходять зі сховища профілів (а не зі змінних середовища) -- `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку Gateway надає для smoke-тесту Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити запит перевірки nonce, який використовує smoke-тест Open WebUI -- `OPENWEBUI_IMAGE=...`, щоб перевизначити зафіксований тег образу Open WebUI +- `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...` для звуження запуску +- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...` для фільтрації провайдерів усередині контейнера +- `OPENCLAW_SKIP_DOCKER_BUILD=1` для повторного використання наявного образу `openclaw:local-live` для повторних запусків, яким не потрібна перебудова +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1` щоб переконатися, що облікові дані надходять зі сховища профілю (а не із середовища) +- `OPENCLAW_OPENWEBUI_MODEL=...` для вибору моделі, яку Gateway надає для smoke-тесту Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...` для перевизначення підказки перевірки nonce, яку використовує smoke-тест Open WebUI +- `OPENWEBUI_IMAGE=...` для перевизначення закріпленого тегу образу Open WebUI ## Перевірка документації Запускайте перевірки документації після редагування документації: `pnpm check:docs`. -Запускайте повну перевірку якорів Mintlify, коли також потрібні перевірки заголовків на сторінці: `pnpm docs:check-links:anchors`. +Запускайте повну перевірку якорів Mintlify, коли також потрібні перевірки заголовків усередині сторінки: `pnpm docs:check-links:anchors`. ## Офлайн-регресія (безпечна для CI) -Це регресії «реального конвеєра» без реальних провайдерів: +Це регресії “справжнього конвеєра” без справжніх провайдерів: -- Виклики інструментів Gateway (імітація OpenAI, реальний gateway + цикл агента): `src/gateway/gateway.test.ts` (випадок: "runs a mock OpenAI tool call end-to-end via gateway agent loop") -- Майстер Gateway (WS `wizard.start`/`wizard.next`, записує конфігурацію + примусово застосовує автентифікацію): `src/gateway/gateway.test.ts` (випадок: "runs wizard over ws and writes auth token config") +- Виклик інструментів 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`, записує конфігурацію + примусова автентифікація): `src/gateway/gateway.test.ts` (кейс: "runs wizard over ws and writes auth token config") -## Оцінювання надійності агентів (skills) +## Оцінювання надійності агента (skills) -У нас уже є кілька безпечних для CI тестів, які поводяться як «оцінювання надійності агентів»: +У нас уже є кілька безпечних для CI тестів, які поводяться як “оцінювання надійності агента”: -- Імітація виклику інструментів через реальний Gateway + цикл агента (`src/gateway/gateway.test.ts`). -- Наскрізні потоки майстра, які перевіряють підключення сесії та ефекти конфігурації (`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 перелічені в запиті, чи вибирає агент правильний skill (або уникає нерелевантних)? -- **Відповідність вимогам:** чи читає агент `SKILL.md` перед використанням і чи виконує потрібні кроки/аргументи? -- **Контракти робочих процесів:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сесії та межі пісочниці. +- **Ухвалення рішень:** коли skills перелічені в prompt, чи вибирає агент правильний skill (або уникає нерелевантних)? +- **Дотримання вимог:** чи читає агент `SKILL.md` перед використанням і чи виконує потрібні кроки/аргументи? +- **Контракти робочого процесу:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сесії та межі sandbox. -Майбутні оцінювання мають спершу залишатися детермінованими: +Майбутні оцінювання насамперед мають залишатися детермінованими: -- Виконувач сценаріїв із mock-провайдерами для перевірки викликів інструментів + порядку, читання файлів skills і підключення сесії. -- Невеликий набір сценаріїв, зосереджених на skills (використання проти уникнення, gating, інʼєкція запиту). -- Необовʼязкові live-оцінювання (за явним увімкненням, керовані змінними середовища) лише після появи безпечного для CI набору. +- Запускач сценаріїв із mock-провайдерами для перевірки викликів інструментів + порядку, читання файлів skill і з’єднання сесій. +- Невеликий набір сценаріїв, сфокусованих на skills (використовувати чи уникати, gating, prompt injection). +- Необов’язкові live-оцінювання (opt-in, із gating через env) лише після впровадження безпечного для CI набору. -## Контрактні тести (форма plugin і channel) +## Контрактні тести (форма plugin і каналу) -Контрактні тести перевіряють, що кожен зареєстрований plugin і channel відповідає своєму -інтерфейсному контракту. Вони проходять по всіх виявлених plugins і запускають набір -перевірок форми та поведінки. Типова unit-доріжка `pnpm test` навмисно -пропускає ці спільні файли seam і smoke; запускайте контрактні команди явно, -коли змінюєте спільні поверхні channel або provider. +Контрактні тести перевіряють, що кожен зареєстрований plugin і канал відповідає своєму +інтерфейсному контракту. Вони проходять усі виявлені plugins і запускають набір +перевірок форми та поведінки. Типова unit-смуга `pnpm test` навмисно +пропускає ці спільні seam- і smoke-файли; запускайте контрактні команди явно, +коли торкаєтеся спільних поверхонь каналів або провайдерів. ### Команди - Усі контракти: `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`: - **plugin** - Базова форма plugin (id, name, capabilities) - **setup** - Контракт майстра налаштування -- **session-binding** - Поведінка привʼязки сесії +- **session-binding** - Поведінка прив’язки сесії - **outbound-payload** - Структура payload повідомлення - **inbound** - Обробка вхідних повідомлень -- **actions** - Обробники дій channel -- **threading** - Обробка ID потоку +- **actions** - Обробники дій каналу +- **threading** - Обробка ID тредів - **directory** - API каталогу/списку учасників -- **group-policy** - Застосування групової політики +- **group-policy** - Забезпечення групової політики -### Контракти статусу provider +### Контракти статусу провайдерів Розташовані в `src/plugins/contracts/*.contract.test.ts`. -- **status** - Проби статусу channel +- **status** - Проби статусу каналу - **registry** - Форма реєстру Plugin -### Контракти provider +### Контракти провайдерів Розташовані в `src/plugins/contracts/*.contract.test.ts`: @@ -789,32 +759,32 @@ key. Він запускає засіяний Gateway з реальним stdio - **catalog** - API каталогу моделей - **discovery** - Виявлення Plugin - **loader** - Завантаження Plugin -- **runtime** - Runtime provider +- **runtime** - Runtime провайдера - **shape** - Форма/інтерфейс Plugin - **wizard** - Майстер налаштування ### Коли запускати - Після зміни експортів або підшляхів plugin-sdk -- Після додавання або зміни channel чи provider plugin -- Після рефакторингу реєстрації або виявлення plugin +- Після додавання або змінення каналу чи provider plugin +- Після рефакторингу реєстрації або виявлення Plugin -Контрактні тести запускаються в CI і не потребують реальних API-ключів. +Контрактні тести запускаються в CI і не потребують справжніх API-ключів. -## Додавання регресій (настанови) +## Додавання регресій (рекомендації) -Коли ви виправляєте проблему provider/model, виявлену наживо: +Коли ви виправляєте проблему провайдера/моделі, виявлену наживо: -- Додайте безпечну для CI регресію, якщо можливо (mock/stub provider або зафіксуйте точне перетворення форми запиту) -- Якщо це за своєю суттю лише live-випадок (обмеження частоти, політики автентифікації), залиште live-тест вузьким і вмикайте його явно через змінні середовища +- Додайте безпечну для CI регресію, якщо можливо (mock/stub провайдера або зафіксуйте точне перетворення форми запиту) +- Якщо це за своєю суттю лише live-сценарій (обмеження швидкості, політики автентифікації), залишайте live-тест вузьким і opt-in через змінні середовища - Віддавайте перевагу найменшому шару, який ловить помилку: - - помилка перетворення/відтворення запиту provider → прямий тест моделей - - помилка конвеєра сесії/історії/інструментів Gateway → live smoke Gateway або безпечний для CI mock-тест Gateway + - помилка перетворення/відтворення запиту провайдера → прямий тест моделей + - помилка конвеєра сесії/історії/інструментів gateway → gateway live smoke або безпечний для CI mock-тест gateway - Запобіжник обходу SecretRef: - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибрану ціль для кожного класу SecretRef з метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec ids із сегментами обходу відхиляються. - - Якщо ви додаєте нову сімʼю цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target ids, щоб нові класи не можна було мовчки пропустити. + - Якщо ви додаєте нову родину цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target ids, щоб нові класи не можна було непомітно пропустити. -## Повʼязане +## Пов’язане -- [Тестування наживо](/uk/help/testing-live) +- [Тестування live](/uk/help/testing-live) - [CI](/uk/ci) diff --git a/docs/uk/reference/RELEASING.md b/docs/uk/reference/RELEASING.md index a49f04635..d0e95f73a 100644 --- a/docs/uk/reference/RELEASING.md +++ b/docs/uk/reference/RELEASING.md @@ -1,239 +1,240 @@ --- read_when: - Пошук визначень публічних каналів випуску - - Запуск перевірки релізу або приймання пакета - - Пошук іменування версій і періодичності випусків -summary: Канали випуску, контрольний список оператора, середовища валідації, іменування версій і періодичність + - Запуск перевірки випуску або приймального тестування пакета + - Шукаєте найменування версій і періодичність випусків +summary: Канали випуску, контрольний список оператора, валідаційні бокси, іменування версій і періодичність title: Політика випусків x-i18n: - generated_at: "2026-04-28T11:24:54Z" + generated_at: "2026-04-29T07:27:34Z" model: gpt-5.5 provider: openai - source_hash: 4bd434932d33d2eefb71c82e2349e370ab2d39f470dba3ff8ffe9a4c317c2191 + source_hash: 84c8dcd13f247b5d136d8a675ce53ef12c68a7f7242d485fe4b55570105ef180 source_path: reference/RELEASING.md workflow: 16 --- -OpenClaw має три публічні канали релізів: +OpenClaw має три публічні канали випусків: -- стабільний: позначені тегами релізи, які типово публікуються в npm `beta`, або в npm `latest` за явним запитом -- бета: передрелізні теги, які публікуються в npm `beta` -- розробницький: рухома головна версія `main` +- stable: випуски з тегами, які за замовчуванням публікуються в npm під `beta`, або в npm під `latest`, коли це явно запитано +- beta: prerelease-теги, які публікуються в npm під `beta` +- dev: рухома вершина `main` -## Назви версій +## Іменування версій -- Версія стабільного релізу: `YYYY.M.D` +- Версія stable-випуску: `YYYY.M.D` - Git-тег: `vYYYY.M.D` -- Версія стабільного коригувального релізу: `YYYY.M.D-N` +- Версія коригувального stable-випуску: `YYYY.M.D-N` - Git-тег: `vYYYY.M.D-N` -- Версія бета-передрелізу: `YYYY.M.D-beta.N` +- Версія beta-prerelease: `YYYY.M.D-beta.N` - Git-тег: `vYYYY.M.D-beta.N` -- Не доповнюйте місяць або день нулями -- `latest` означає поточний просунутий стабільний npm-реліз -- `beta` означає поточну ціль встановлення бета-версії -- Стабільні та стабільні коригувальні релізи типово публікуються в npm `beta`; оператори релізу можуть явно вибрати `latest` або пізніше просунути перевірену бета-збірку -- Кожен стабільний реліз OpenClaw постачається разом з npm-пакетом і macOS-застосунком; - бета-релізи зазвичай спершу перевіряють і публікують шлях npm/пакета, а - збирання/підписування/нотаризацію mac-застосунку лишають для стабільного релізу, якщо це не запитано явно +- Не додавайте нуль на початку місяця чи дня +- `latest` означає поточний просунутий stable-випуск npm +- `beta` означає поточну ціль встановлення beta +- Stable і коригувальні stable-випуски за замовчуванням публікуються в npm під `beta`; оператори випуску можуть явно вибрати `latest` або пізніше просунути перевірену beta-збірку +- Кожен stable-випуск OpenClaw постачається разом із npm-пакетом і застосунком macOS; + beta-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а + збірка/підпис/нотаризація застосунку macOS зарезервовані для stable, якщо їх явно не запитано -## Періодичність релізів +## Ритм випусків -- Релізи рухаються спершу через бета-версію -- Стабільний реліз виходить лише після перевірки останньої бета-версії -- Мейнтейнери зазвичай роблять релізи з гілки `release/YYYY.M.D`, створеної - з поточного `main`, щоб перевірка релізу й виправлення не блокували нову +- Випуски рухаються спочатку через beta +- Stable іде лише після перевірки найновішої beta +- Maintainers зазвичай готують випуски з гілки `release/YYYY.M.D`, створеної + з поточного `main`, щоб перевірка випуску й виправлення не блокували нову розробку в `main` -- Якщо бета-тег уже запушено або опубліковано й він потребує виправлення, мейнтейнери створюють - наступний тег `-beta.N` замість видалення чи повторного створення старого бета-тега -- Докладна процедура релізу, погодження, облікові дані та нотатки щодо відновлення - доступні лише мейнтейнерам +- Якщо beta-тег уже надіслано або опубліковано й він потребує виправлення, maintainers створюють + наступний тег `-beta.N` замість видалення або повторного створення старого beta-тега +- Детальна процедура випуску, погодження, облікові дані й нотатки щодо відновлення + доступні лише maintainers -## Контрольний список оператора релізу +## Контрольний список оператора випуску -Цей контрольний список показує публічну форму процесу релізу. Приватні облікові дані, +Цей контрольний список описує публічну форму процесу випуску. Приватні облікові дані, підписування, нотаризація, відновлення dist-tag і подробиці аварійного відкату залишаються в -релізному регламенті лише для мейнтейнерів. +runbook випуску, доступному лише maintainers. -1. Почніть із поточного `main`: підтягніть останні зміни, переконайтеся, що цільовий коміт запушено, - і підтвердьте, що поточний CI для `main` достатньо зелений, щоб відгалузитися від нього. -2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії комітів за допомогою - `/changelog`, залиште записи орієнтованими на користувача, закомітьте, запуште й виконайте rebase/pull +1. Почніть із поточного `main`: отримайте найновіші зміни, підтвердьте, що цільовий commit надіслано, + і підтвердьте, що поточний CI `main` достатньо зелений, щоб створити від нього гілку. +2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії commit за допомогою + `/changelog`, залиште записи орієнтованими на користувача, створіть commit, надішліть його й виконайте rebase/pull ще раз перед створенням гілки. -3. Перегляньте записи сумісності релізу в +3. Перегляньте записи сумісності випуску в `src/plugins/compat/registry.ts` і `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену сумісність лише тоді, коли шлях оновлення лишається покритим, або зафіксуйте, чому її - навмисно зберігають. -4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну релізну роботу + навмисно збережено. +4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском безпосередньо в `main`. -5. Підвищте версію в усіх потрібних місцях для запланованого тега, потім запустіть - локальну детерміновану попередню перевірку: +5. Оновіть кожне потрібне місце версії для запланованого тегу, потім запустіть + локальний детермінований preflight: `pnpm check:test-types`, `pnpm check:architecture`, `pnpm build && pnpm ui:build` і `pnpm release:check`. -6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тега - для перевірочної попередньої валідації дозволено повний 40-символьний SHA гілки релізу. +6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. Поки тегу немає, + повний 40-символьний SHA гілки випуску дозволено для preflight лише з метою перевірки. Збережіть успішний `preflight_run_id`. -7. Запустіть усі передрелізні тести через `Full Release Validation` для - гілки релізу, тега або повного SHA коміта. Це єдина ручна точка входу - для чотирьох великих релізних тестових блоків: Vitest, Docker, QA Lab і Package. -8. Якщо валідація не пройшла, виправте проблему в гілці релізу й перезапустіть найменший невдалий - файл, канал, job workflow, профіль пакета, провайдера або allowlist моделі, що - доводить виправлення. Перезапускайте повну парасолькову перевірку лише тоді, коли змінена поверхня робить +7. Запустіть усі pre-release тести через `Full Release Validation` для + гілки випуску, тегу або повного SHA commit. Це єдина ручна точка входу + для чотирьох великих тестових боксів випуску: Vitest, Docker, QA Lab і Package. +8. Якщо перевірка не пройшла, виправте проблему в гілці випуску й перезапустіть найменший невдалий + файл, lane, workflow job, профіль пакета, provider або model allowlist, який + доводить виправлення. Перезапускайте повну парасольку лише тоді, коли змінена поверхня робить попередні докази застарілими. -9. Для бета-версії створіть тег `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, потім запустіть - post-publish приймання пакета для опублікованого пакета `openclaw@YYYY.M.D-beta.N` - або `openclaw@beta`. Якщо запушена або опублікована бета потребує виправлення, створіть - наступний `-beta.N`; не видаляйте й не переписуйте стару бета-версію. -10. Для стабільного релізу продовжуйте лише після того, як перевірена бета або реліз-кандидат матиме - потрібні докази валідації. Стабільна npm-публікація повторно використовує успішний - preflight-артефакт через `preflight_run_id`; готовність стабільного macOS-релізу - також потребує запакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого +9. Для beta створіть тег `vYYYY.M.D-beta.N`, опублікуйте з npm dist-tag `beta`, потім запустіть + post-publish package acceptance проти опублікованого пакета `openclaw@YYYY.M.D-beta.N` + або `openclaw@beta`. Якщо надіслана або опублікована beta потребує виправлення, створіть + наступний `-beta.N`; не видаляйте й не переписуйте стару beta. +10. Для stable продовжуйте лише після того, як перевірена beta або release candidate має + потрібні докази перевірки. Stable-публікація npm повторно використовує успішний + preflight-артефакт через `preflight_run_id`; готовність stable-випуску macOS + також вимагає упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`. -11. Після публікації запустіть npm post-publish verifier, за потреби додатковий автономний - опублікований-npm Telegram E2E, коли потрібен post-publish доказ каналу, +11. Після публікації запустіть npm post-publish verifier, необов’язковий автономний + published-npm Telegram E2E, коли потрібен post-publish доказ каналу, просування dist-tag за потреби, нотатки GitHub release/prerelease з - повного відповідного розділу `CHANGELOG.md` і кроки оголошення релізу. + повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску. -## Попередня перевірка релізу +## Preflight випуску -- Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався +- Виконайте `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався покритим поза швидшим локальним шлюзом `pnpm check` -- Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів - імпортів і архітектурних меж були зеленими поза швидшим локальним шлюзом -- Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані - релізні артефакти `dist/*` і бандл Control UI існували для кроку - валідації пакування -- Запустіть ручний workflow `Full Release Validation` перед затвердженням релізу, щоб +- Виконайте `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів + імпортів і меж архітектури були зеленими поза швидшим локальним шлюзом +- Виконайте `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані + релізні артефакти `dist/*` і бандл Control UI існували для кроку перевірки + пакування +- Виконайте ручний workflow `Full Release Validation` перед схваленням релізу, щоб запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку, тег або повний SHA коміту, запускає ручний `CI` і запускає - `OpenClaw Release Checks` для перевірки встановлення, приймання пакета, наборів - release-path для Docker, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram - lane-ів. Надавайте `npm_telegram_package_spec` лише після того, як пакет було - опубліковано і також має виконатися post-publish Telegram E2E. Надавайте + `OpenClaw Release Checks` для install smoke, package acceptance, Docker + release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram + lanes. Надавайте `npm_telegram_package_spec` лише після публікації пакета, + коли також має запуститися післяпублікаційний Telegram E2E. Надавайте `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що - валідація відповідає опублікованому npm-пакету без примусового запуску Telegram E2E. + валідація відповідає опублікованому npm-пакету без примусового Telegram E2E. Приклад: `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D` -- Запустіть ручний workflow `Package Acceptance`, коли потрібне side-channel підтвердження +- Виконайте ручний workflow `Package Acceptance`, коли потрібен побічний доказ для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`, - щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним - harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим - SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub - Actions. Workflow резолвить кандидата в - `package-under-test`, повторно використовує планувальник Docker E2E release проти цього - tarball і може запускати Telegram QA проти того самого tarball з - `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. + щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним harness + `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим SHA-256; або + `source=artifact` для tarball, завантаженого іншим запуском GitHub Actions. + Workflow резолвить кандидата в `package-under-test`, повторно використовує + Docker E2E release scheduler проти цього tarball і може запускати Telegram QA + проти того самого tarball з `telegram_mode=mock-openai` або + `telegram_mode=live-frontier`. Приклад: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f telegram_mode=mock-openai` - Поширені профілі: - - `smoke`: lane-и встановлення/channel/agent, мережі Gateway і перезавантаження конфігурації - - `package`: artifact-native lane-и пакета/оновлення/Plugin без OpenWebUI або live ClawHub - - `product`: профіль package плюс MCP channels, очищення cron/subagent, - вебпошук OpenAI і OpenWebUI - - `full`: chunks Docker release-path з OpenWebUI + Типові профілі: + - `smoke`: install/channel/agent, gateway network і config reload lanes + - `package`: artifact-native package/update/plugin lanes без OpenWebUI або live ClawHub + - `product`: профіль package плюс MCP channels, cron/subagent cleanup, + OpenAI web search і OpenWebUI + - `full`: Docker release-path chunks з OpenWebUI - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску -- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI - для кандидата релізу. Ручні CI dispatch обходять changed scoping - і примусово запускають Linux Node shards, bundled-plugin shards, channel +- Виконайте ручний workflow `CI` напряму, коли потрібне лише повне звичайне CI + покриття для релізного кандидата. Ручні CI dispatch обходять changed + scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, `check`, `check-additional`, build smoke, - перевірки документації, Python skills, Windows, macOS, Android і lane-и i18n - Control UI. + перевірки docs, Python skills, Windows, macOS, Android і Control UI i18n + lanes. Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D` -- Запустіть `pnpm qa:otel:smoke`, коли валідуєте релізну телеметрію. Він перевіряє - QA-lab через локальний OTLP/HTTP receiver і верифікує експортовані назви trace - span, обмежені атрибути та редагування контенту/ідентифікаторів без +- Виконайте `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Це + проганяє QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані + назви trace span, обмежені атрибути та редагування вмісту/ідентифікаторів без потреби в Opik, Langfuse або іншому зовнішньому collector. -- Запускайте `pnpm release:check` перед кожним тегованим релізом +- Виконуйте `pnpm release:check` перед кожним релізом із тегом - Релізні перевірки тепер виконуються в окремому ручному workflow: `OpenClaw Release Checks` -- `OpenClaw Release Checks` також запускає mock parity gate QA Lab плюс швидкий - live-профіль Matrix і lane Telegram QA перед затвердженням релізу. Live - lane-и використовують середовище `qa-live-shared`; Telegram також використовує оренди - облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з - `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар - транспорту Matrix, медіа та E2EE паралельно. -- Крос-OS валідація встановлення й оновлення runtime є частиною публічних +- `OpenClaw Release Checks` також запускає QA Lab mock parity gate плюс швидкий + live Matrix profile і Telegram QA lane перед схваленням релізу. Live + lanes використовують середовище `qa-live-shared`; Telegram також використовує оренди + облікових даних Convex CI. Виконайте ручний workflow `QA-Lab - All Lanes` з + `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний інвентар Matrix + transport, media та E2EE паралельно. +- Cross-OS install і upgrade runtime validation є частиною публічних `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають - перевикористовуваний workflow + reusable workflow `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` -- Цей поділ навмисний: тримайте реальний шлях npm-релізу коротким, - детермінованим і сфокусованим на артефактах, тоді як повільніші live-перевірки залишаються у - власному lane, щоб вони не затримували й не блокували публікацію -- Релізні перевірки з секретами слід запускати через `Full Release +- Цей поділ навмисний: тримайте реальний npm release path коротким, + детермінованим і зосередженим на артефактах, тоді як повільніші live checks залишаються у + власній lane, щоб вони не затримували й не блокували publish +- Релізні перевірки із секретами слід запускати через `Full Release Validation` або з workflow ref `main`/release, щоб логіка workflow і секрети залишалися контрольованими -- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, якщо - резолвлений коміт доступний з гілки OpenClaw або релізного тегу +- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, доки + розв’язаний коміт досяжний з гілки OpenClaw або релізного тегу - Validation-only preflight `OpenClaw NPM Release` також приймає поточний - повний 40-символьний SHA коміту workflow-branch без вимоги запушеного тегу -- Цей шлях SHA призначений лише для валідації й не може бути просунутий у реальну публікацію -- У режимі SHA workflow синтезує `v` лише для - перевірки метаданих пакета; реальна публікація все одно вимагає реального релізного тегу -- Обидва workflow залишають реальний шлях публікації та просування на GitHub-hosted - runners, тоді як немутуючий шлях валідації може використовувати більші + повний 40-символьний SHA коміту workflow-гілки без вимоги запушеного тегу +- Цей шлях SHA призначений лише для валідації й не може бути просунутий у реальний publish +- У режимі SHA workflow синтезує `v` лише для перевірки + метаданих пакета; реальний publish усе ще вимагає справжнього релізного тегу +- Обидва workflow залишають реальний шлях publish і promotion на GitHub-hosted + runners, тоді як немутувальний шлях валідації може використовувати більші Blacksmith Linux runners - Цей workflow запускає `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache` - з використанням workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` -- Передрелізна перевірка npm-релізу більше не чекає на окремий lane релізних перевірок -- Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` - (або відповідний beta/correction тег) перед затвердженням -- Після npm publish запустіть + використовуючи workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` +- npm release preflight більше не чекає на окрему lane релізних перевірок +- Виконайте `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` + (або відповідний beta/correction tag) перед схваленням +- Після npm publish виконайте `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D` - (або відповідну beta/correction версію), щоб перевірити шлях встановлення з опублікованого registry - у свіжому тимчасовому префіксі -- Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live` - щоб перевірити onboarding встановленого пакета, налаштування Telegram і реальний Telegram E2E - проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних Telegram. - Локальні одноразові запуски maintainer-ів можуть опустити змінні Convex і передати три + (або відповідну beta/correction version), щоб перевірити published registry + install path у свіжому тимчасовому префіксі +- Після beta publish виконайте `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live` + щоб перевірити installed-package onboarding, налаштування Telegram і реальний Telegram E2E + проти опублікованого npm-пакета з використанням спільного пулу орендованих облікових даних + Telegram. Локальні одноразові запуски maintainer можуть пропустити vars Convex і передати три env credentials `OPENCLAW_QA_TELEGRAM_*` напряму. -- Maintainer-и можуть запустити ту саму post-publish перевірку з GitHub Actions через +- Maintainers можуть запускати ту саму післяпублікаційну перевірку з GitHub Actions через ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і - не запускається при кожному merge. -- Автоматизація релізів maintainer-ів тепер використовує preflight-then-promote: - - реальна npm publish має пройти успішний npm `preflight_run_id` - - реальна npm publish має бути запущена з тієї самої гілки `main` або + не запускається під час кожного merge. +- Автоматизація релізів maintainer тепер використовує preflight-then-promote: + - реальний npm publish має пройти успішний npm `preflight_run_id` + - реальний npm publish має бути запущений з тієї самої гілки `main` або `release/YYYY.M.D`, що й успішний preflight run - stable npm releases за замовчуванням використовують `beta` - stable npm publish може явно націлюватися на `latest` через workflow input - - мутація npm dist-tag на основі токена тепер живе в + - token-based npm dist-tag mutation тепер живе в `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` - з міркувань безпеки, тому що `npm dist-tag add` все ще потребує `NPM_TOKEN`, тоді як - публічний repo зберігає лише OIDC publish - - публічний `macOS Release` є лише validation-only - - реальний приватний mac publish має пройти успішні приватні mac + з міркувань безпеки, бо `npm dist-tag add` усе ще потребує `NPM_TOKEN`, тоді як + публічний репозиторій зберігає OIDC-only publish + - публічний `macOS Release` призначений лише для валідації + - реальний private mac publish має пройти успішні private mac `preflight_run_id` і `validate_run_id` - - реальні publish paths просувають підготовлені артефакти замість того, щоб повторно - їх збирати + - реальні publish paths просувають підготовлені артефакти замість повторної + їх перебудови - Для stable correction releases на кшталт `YYYY.M.D-N` post-publish verifier також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`, - щоб release corrections не могли непомітно залишити старі глобальні встановлення на + щоб release corrections не могли непомітно залишити старіші global installs на базовому stable payload -- Передрелізна перевірка npm-релізу fails closed, якщо tarball не містить і - `dist/control-ui/index.html`, і непорожній payload `dist/control-ui/assets/`, - щоб ми знову не відправили порожню browser dashboard -- Post-publish verification також перевіряє, що встановлення з опублікованого registry - містить непорожні bundled plugin runtime deps під кореневою структурою `dist/*`. - Реліз, який постачається з відсутніми або порожніми bundled plugin - dependency payloads, не проходить postpublish verifier і не може бути promoted +- npm release preflight закривається з помилкою, якщо tarball не містить одночасно + `dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`, + щоб ми знову не відправили порожню браузерну панель керування +- Post-publish verification також перевіряє, що published registry install + містить непорожні bundled Plugin runtime deps у кореневому layout `dist/*`. + Реліз, який постачається з відсутніми або порожніми bundled Plugin + dependency payloads, провалює postpublish verifier і не може бути promoted to `latest`. -- `pnpm test:install:smoke` також забезпечує бюджет npm pack `unpackedSize` для - candidate update tarball, щоб installer e2e ловив випадкове pack bloat +- `pnpm test:install:smoke` також застосовує budget npm pack `unpackedSize` до + candidate update tarball, щоб installer e2e ловив випадкове розростання pack до release publish path -- Якщо релізна робота зачепила планування CI, timing manifests розширень або - test matrices розширень, згенеруйте заново й перегляньте належні planner-у - workflow matrix outputs `checks-node-extensions` з `.github/workflows/ci.yml` - перед затвердженням, щоб release notes не описували застарілий layout CI +- Якщо релізна робота торкалася CI planning, extension timing manifests або + extension test matrices, перегенеруйте й перегляньте planner-owned + `plugin-prerelease-extension-shard` matrix outputs з + `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не + описували застарілий CI layout - Готовність stable macOS release також включає поверхні updater: - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip` - `appcast.xml` на `main` має вказувати на новий stable zip після publish - - запакований застосунок має зберігати non-debug bundle id, непорожню Sparkle feed - URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor + - запакований app має зберігати non-debug bundle id, непорожній Sparkle feed + URL і `CFBundleVersion` на рівні або вище canonical Sparkle build floor для цієї релізної версії ## Релізні тестові бокси -`Full Release Validation` — це спосіб, яким оператори запускають усі передрелізні тести з +`Full Release Validation` — це спосіб, яким operators запускають усі передрелізні тести з однієї точки входу. Запускайте його з довіреного workflow ref `main` і передавайте релізну гілку, тег або повний SHA коміту як `ref`: @@ -247,34 +248,34 @@ gh workflow run full-release-validation.yml \ -f evidence_package_spec=openclaw@YYYY.M.D-beta.N ``` -Workflow резолвить target ref, запускає ручний `CI` з +Workflow резолвить target ref, запускає manual `CI` з `target_ref=`, запускає `OpenClaw Release Checks` і -опціонально запускає standalone post-publish Telegram E2E, коли -`npm_telegram_package_spec` встановлено. Потім `OpenClaw Release Checks` розгортає +опційно запускає standalone post-publish Telegram E2E, коли +`npm_telegram_package_spec` задано. Потім `OpenClaw Release Checks` розгалужується на install smoke, cross-OS release checks, live/E2E Docker release-path coverage, Package Acceptance з Telegram package QA, QA Lab parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли summary `Full Release Validation` -показує `normal_ci` і `release_checks` як successful, а будь-який опціональний +показує `normal_ci` і `release_checks` як successful, а будь-який optional child `npm_telegram` або successful, або навмисно skipped. Фінальний verifier summary містить таблиці slowest-job для кожного child run, щоб release manager міг бачити поточний critical path без завантаження logs. Child workflows запускаються з довіреного ref, який запускає `Full Release Validation`, зазвичай `--ref main`, навіть коли target `ref` вказує на -старішу release branch або tag. Окремого Full Release Validation -workflow-ref input немає; вибирайте довірений harness, вибираючи workflow run ref. +старішу release branch або tag. Окремого workflow-ref input для Full Release Validation +немає; вибирайте trusted harness, вибираючи workflow run ref. -Використовуйте `release_profile`, щоб вибрати live/provider breadth: +Використовуйте `release_profile`, щоб вибрати ширину live/provider: - `minimum`: найшвидший release-critical OpenAI/core live і Docker path -- `stable`: minimum плюс stable provider/backend coverage для release approval -- `full`: stable плюс широкий advisory provider/media coverage +- `stable`: minimum плюс stable provider/backend coverage для схвалення релізу +- `full`: stable плюс широке advisory provider/media coverage -`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз резолвити target -ref як `release-package-under-test`, і повторно використовує цей артефакт як у -release-path Docker checks, так і в Package Acceptance. Це тримає всі -package-facing boxes на тих самих байтах і уникає повторних package builds. +`OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз розв’язати target +ref як `release-package-under-test` і повторно використовує цей артефакт як у +release-path Docker checks, так і в Package Acceptance. Це утримує всі +package-facing boxes на тих самих bytes і уникає повторних package builds. -Використовуйте ці варіанти залежно від етапу релізу: +Використовуйте ці варіанти залежно від стадії релізу: ```bash # Validate an unpublished release candidate branch. @@ -303,39 +304,40 @@ gh workflow run full-release-validation.yml \ -f npm_telegram_provider_mode=mock-openai ``` -Не використовуйте повну парасольку як перший повторний запуск після сфокусованого виправлення. Якщо один бокс -падає, використайте невдалий дочірній робочий процес, завдання, Docker-лінію, профіль пакета, модельного -провайдера або QA-лінію для наступного доказу. Запускайте повну парасольку знову лише тоді, коли -виправлення змінило спільну оркестрацію релізу або зробило попередні докази всіх боксів -застарілими. Фінальний верифікатор парасольки повторно перевіряє записані ідентифікатори запусків -дочірніх робочих процесів, тож після успішного повторного запуску дочірнього робочого процесу повторно запустіть лише невдале +Не використовуйте повну парасольку як перший повторний запуск після сфокусованого виправлення. Якщо один блок +зазнає невдачі, використовуйте невдалий дочірній workflow, завдання, Docker-лінію, профіль пакета, модельного +провайдера або QA-лінію для наступного підтвердження. Запускайте повну парасольку знову лише тоді, коли +виправлення змінило спільну оркестрацію релізу або зробило попередні докази з усіх блоків +застарілими. Фінальний перевірник парасольки повторно перевіряє записані ідентифікатори запусків дочірніх workflow, +тому після успішного повторного запуску дочірнього workflow повторно запускайте лише невдале батьківське завдання `Verify full validation`. Для обмеженого відновлення передайте `rerun_group` у парасольку. `all` — це справжній -запуск реліз-кандидата, `ci` запускає лише звичайний дочірній CI, `release-checks` запускає -кожен релізний бокс, а вужчі релізні групи — це `install-smoke`, -`cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і -`npm-telegram`, коли надано окрему Telegram-лінію пакета. +запуск release candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease` +запускає лише релізний дочірній Plugin, `release-checks` запускає кожен релізний +блок, а вужчі релізні групи — це `install-smoke`, `cross-os`, +`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` та `npm-telegram`, коли +надано автономну Telegram-лінію пакета. ### Vitest -Vitest-бокс — це ручний дочірній робочий процес `CI`. Ручний CI навмисно -оминає змінену область і примусово запускає звичайний граф тестів для реліз-кандидата: -Linux Node-шарди, шарди вбудованих Plugin, контракти каналів, сумісність із Node 22, +Блок Vitest — це ручний дочірній workflow `CI`. Ручний CI навмисно +оминає changed scoping і примусово запускає звичайний тестовий граф для release +candidate: Linux Node-шарди, шарди bundled-plugin, контракти каналів, сумісність Node 22, `check`, `check-additional`, build smoke, перевірки документації, Python -skills, Windows, macOS, Android і Control UI i18n. +skills, Windows, macOS, Android і i18n Control UI. -Використовуйте цей бокс, щоб відповісти на запитання "чи пройшло дерево джерел повний звичайний набір тестів?" -Це не те саме, що продуктова валідація релізного шляху. Докази, які треба зберігати: +Використовуйте цей блок, щоб відповісти на запитання: «чи пройшло дерево джерельного коду повний звичайний набір тестів?» +Це не те саме, що валідація продукту на релізному шляху. Докази, які потрібно зберегти: -- зведення `Full Release Validation`, що показує URL запущеного `CI` +- підсумок `Full Release Validation`, що показує URL запущеного `CI` - зелений запуск `CI` на точному цільовому SHA -- назви невдалих або повільних шардів із CI-завдань під час розслідування регресій -- артефакти таймінгів Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли +- назви невдалих або повільних шардів із завдань CI під час дослідження регресій +- артефакти часу виконання Vitest, такі як `.artifacts/vitest-shard-timings.json`, коли запуск потребує аналізу продуктивності -Запускайте ручний CI безпосередньо лише тоді, коли релізу потрібен детермінований звичайний CI, але -не Docker, QA Lab, live, cross-OS або пакетні бокси: +Запускайте ручний CI напряму лише тоді, коли реліз потребує детермінованого звичайного CI, але +не Docker, QA Lab, live, cross-OS або package-блоків: ```bash gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D @@ -343,98 +345,98 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D ### Docker -Docker-бокс живе в `OpenClaw Release Checks` через -`openclaw-live-and-e2e-checks-reusable.yml`, а також у релізному режимі робочого процесу -`install-smoke`. Він валідує реліз-кандидата через упаковані -Docker-середовища, а не лише через тести рівня джерел. +Docker-блок міститься в `OpenClaw Release Checks` через +`openclaw-live-and-e2e-checks-reusable.yml`, а також у release-mode +workflow `install-smoke`. Він перевіряє release candidate через упаковані +Docker-середовища, а не лише через тести на рівні джерельного коду. -Релізне Docker-покриття включає: +Покриття release Docker включає: -- повний install smoke з увімкненим повільним Bun global install smoke -- репозиторні E2E-лінії -- Docker-чанки релізного шляху: `core`, `package-update-openai`, +- повний install smoke із увімкненим повільним Bun global install smoke +- repository E2E-лінії +- release-path Docker-частини: `core`, `package-update-openai`, `package-update-anthropic`, `package-update-core`, `plugins-runtime-core`, `plugins-runtime-install-a`, `plugins-runtime-install-b`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` і `bundled-channels-contracts` -- покриття OpenWebUI всередині чанка `plugins-runtime-core`, коли запитано -- розділені лінії залежностей вбудованих каналів між channel-smoke, update-target - і чанками setup/runtime contract замість одного великого завдання bundled-channel -- розділені лінії встановлення/видалення вбудованих Plugin +- покриття OpenWebUI всередині частини `plugins-runtime-core`, коли запитано +- розділені лінії залежностей bundled-channel між channel-smoke, update-target + і setup/runtime contract-частинами замість одного великого завдання bundled-channel +- розділені лінії встановлення/видалення bundled Plugin `bundled-plugin-install-uninstall-0` через `bundled-plugin-install-uninstall-7` -- live/E2E-набори провайдерів і Docker live model-покриття, коли release checks +- live/E2E-набори провайдерів і Docker live-покриття моделей, коли release checks включають live-набори -Використовуйте Docker-артефакти перед повторним запуском. Планувальник релізного шляху завантажує -`.artifacts/docker-tests/` з логами ліній, `summary.json`, `failures.json`, -таймінгами фаз, JSON плану планувальника та командами повторного запуску. Для сфокусованого відновлення -використовуйте `docker_lanes=` у багаторазовому live/E2E-робочому процесі замість -повторного запуску всіх релізних чанків. Згенеровані команди повторного запуску включають попередній -`package_artifact_run_id` і підготовлені Docker image inputs, коли доступні, тож +Використовуйте Docker-артефакти перед повторним запуском. Release-path планувальник завантажує +`.artifacts/docker-tests/` із журналами ліній, `summary.json`, `failures.json`, +часами фаз, JSON плану планувальника та командами повторного запуску. Для сфокусованого відновлення +використовуйте `docker_lanes=` у reusable live/E2E workflow замість +повторного запуску всіх релізних частин. Згенеровані команди повторного запуску включають попередній +`package_artifact_run_id` і підготовлені входи Docker-образів, коли доступні, тож невдала лінія може повторно використати той самий tarball і GHCR-образи. ### QA Lab -QA Lab-бокс також є частиною `OpenClaw Release Checks`. Це агентний -релізний gate поведінки та рівня каналів, окремий від Vitest і Docker -пакетної механіки. +Блок QA Lab також є частиною `OpenClaw Release Checks`. Це релізний gate для агентної +поведінки й рівня каналів, окремий від механіки пакетів Vitest і Docker. -Релізне QA Lab-покриття включає: +Покриття release QA Lab включає: -- mock parity gate, що порівнює кандидатну лінію OpenAI з базовою Opus 4.6 - за допомогою пакета agentic parity -- швидкий live Matrix QA-профіль із використанням середовища `qa-live-shared` -- live Telegram QA-лінію з використанням оренд облікових даних Convex CI -- `pnpm qa:otel:smoke`, коли релізна телеметрія потребує явного локального доказу +- mock parity gate, що порівнює кандидатну лінію OpenAI з базовою лінією Opus 4.6 + за допомогою agentic parity pack +- швидкий live Matrix QA profile із використанням середовища `qa-live-shared` +- live Telegram QA lane із використанням Convex CI credential leases +- `pnpm qa:otel:smoke`, коли релізній телеметрії потрібне явне локальне підтвердження -Використовуйте цей бокс, щоб відповісти на запитання "чи реліз поводиться правильно в QA-сценаріях і -live-потоках каналів?" Зберігайте URL артефактів для ліній parity, Matrix і Telegram -під час схвалення релізу. Повне Matrix-покриття лишається доступним як -ручний шардований запуск QA-Lab, а не як стандартна реліз-критична лінія. +Використовуйте цей блок, щоб відповісти на запитання: «чи поводиться реліз коректно в QA-сценаріях і +live-потоках каналів?» Зберігайте URL артефактів для parity, Matrix і Telegram +ліній під час схвалення релізу. Повне Matrix-покриття залишається доступним як +ручний шардований запуск QA-Lab, а не стандартна релізно-критична лінія. -### Пакет +### Package -Package-бокс — це gate встановлюваного продукту. Він підтримується -`Package Acceptance` і резолвером -`scripts/resolve-openclaw-package-candidate.mjs`. Резолвер нормалізує -кандидат у tarball `package-under-test`, який споживає Docker E2E, валідує +Package-блок — це gate для інстальованого продукту. Він підтримується +`Package Acceptance` і resolver +`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує +кандидата в tarball `package-under-test`, який споживає Docker E2E, перевіряє інвентар пакета, записує версію пакета та SHA-256 і тримає -ref обв'язки робочого процесу окремо від ref джерела пакета. +ref harness workflow окремо від ref джерела пакета. Підтримувані джерела кандидатів: -- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна версія релізу OpenClaw -- `source=ref`: запакувати довірену гілку `package_ref`, тег або повний commit SHA - з вибраною обв'язкою `workflow_ref` -- `source=url`: завантажити HTTPS `.tgz` з обов'язковим `package_sha256` -- `source=artifact`: повторно використати `.tgz`, завантажений іншим запуском GitHub Actions +- `source=npm`: `openclaw@beta`, `openclaw@latest` або точна релізна + версія OpenClaw +- `source=ref`: пакує довірену гілку `package_ref`, тег або повний commit SHA + з вибраним harness `workflow_ref` +- `source=url`: завантажує HTTPS `.tgz` з обов’язковим `package_sha256` +- `source=artifact`: повторно використовує `.tgz`, завантажений іншим запуском GitHub Actions `OpenClaw Release Checks` запускає Package Acceptance із `source=ref`, `package_ref=`, `suite_profile=custom`, `docker_lanes=bundled-channel-deps-compat plugins-offline` і -`telegram_mode=mock-openai`. Docker-чанки релізного шляху покривають -перекривні лінії встановлення, оновлення та plugin-update; Package Acceptance зберігає -artifact-native compat для bundled-channel, offline-фікстури Plugin і Telegram +`telegram_mode=mock-openai`. Release-path Docker-частини покривають +перетинальні лінії встановлення, оновлення та plugin-update; Package Acceptance зберігає +artifact-native bundled-channel compat, offline Plugin fixtures і Telegram package QA проти того самого resolved tarball. Це GitHub-native -заміна більшості покриття package/update, яке раніше вимагало -Parallels. Cross-OS release checks досі важливі для OS-специфічного onboarding, -інсталятора та поведінки платформи, але продуктова валідація package/update має -надавати перевагу Package Acceptance. +заміна більшості покриття package/update, яке раніше потребувало +Parallels. Cross-OS release checks усе ще важливі для специфічних для ОС onboarding, +installer і platform behavior, але валідація продукту package/update має +віддавати перевагу Package Acceptance. -Застарілу поблажливість package-acceptance навмисно обмежено в часі. Пакети до -`2026.4.25` включно можуть використовувати шлях сумісності для metadata gaps, уже опублікованих -у npm: приватні записи QA-інвентаря, відсутні в tarball, відсутній -`gateway install --wrapper`, відсутні patch files у git-фікстурі, похідній від tarball, -відсутній persisted `update.channel`, застарілі розташування install-record Plugin, -відсутнє persistence marketplace install-record і міграція config metadata +Поблажливість legacy package-acceptance навмисно обмежена в часі. Пакети до +`2026.4.25` включно можуть використовувати compatibility path для metadata gaps, уже опублікованих +до npm: приватні QA inventory entries, відсутні в tarball, відсутній +`gateway install --wrapper`, відсутні patch files у tarball-derived git +fixture, відсутній збережений `update.channel`, legacy plugin install-record +locations, відсутня marketplace install-record persistence і міграція config metadata під час `plugins update`. Опублікований пакет `2026.4.26` може попереджати -про stamp-файли metadata локального build, які вже були shipped. Пізніші пакети -мають задовольняти сучасні package contracts; ті самі прогалини провалюють релізну +про local build metadata stamp files, які вже були поставлені. Пізніші пакети +мають відповідати сучасним package contracts; ті самі прогалини провалюють релізну валідацію. Використовуйте ширші профілі Package Acceptance, коли релізне питання стосується -реального встановлюваного пакета: +фактичного інстальованого пакета: ```bash gh workflow run package-acceptance.yml \ @@ -445,87 +447,87 @@ gh workflow run package-acceptance.yml \ -f suite_profile=product ``` -Поширені профілі пакета: +Поширені профілі пакетів: -- `smoke`: швидкі лінії встановлення пакета/каналу/агента, gateway network і config - reload +- `smoke`: швидкі лінії встановлення пакета/каналу/агента, мережі Gateway і + перезавантаження конфігурації - `package`: контракти install/update/plugin package без live ClawHub; це стандарт release-check - `product`: `package` плюс MCP channels, cron/subagent cleanup, OpenAI web search і OpenWebUI -- `full`: Docker-чанки релізного шляху з OpenWebUI +- `full`: Docker release-path chunks з OpenWebUI - `custom`: точний список `docker_lanes` для сфокусованих повторних запусків Для package-candidate Telegram proof увімкніть `telegram_mode=mock-openai` або -`telegram_mode=live-frontier` у Package Acceptance. Робочий процес передає resolved -tarball `package-under-test` у Telegram-лінію; окремий -Telegram-робочий процес досі приймає опубліковану npm spec для post-publish checks. +`telegram_mode=live-frontier` у Package Acceptance. Workflow передає resolved +tarball `package-under-test` у Telegram-лінію; автономний Telegram workflow +досі приймає опублікований npm spec для post-publish checks. -## Вхідні дані робочого процесу NPM +## Вхідні параметри NPM workflow -`OpenClaw NPM Release` приймає ці керовані оператором вхідні дані: +`OpenClaw NPM Release` приймає такі керовані оператором вхідні параметри: -- `tag`: обов'язковий релізний тег, як-от `v2026.4.2`, `v2026.4.2-1` або +- `tag`: обов’язковий релізний тег, такий як `v2026.4.2`, `v2026.4.2-1` або `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний - повний 40-символьний commit SHA workflow-branch для preflight лише з валідацією + повний 40-символьний commit SHA workflow-branch для validation-only preflight - `preflight_only`: `true` для validation/build/package only, `false` для справжнього publish path -- `preflight_run_id`: обов'язковий на справжньому publish path, щоб робочий процес повторно використав - підготовлений tarball з успішного preflight run -- `npm_dist_tag`: цільовий тег npm для publish path; стандартно `beta` +- `preflight_run_id`: обов’язковий на справжньому publish path, щоб workflow повторно використав + підготовлений tarball з успішного preflight-запуску +- `npm_dist_tag`: цільовий npm-тег для publish path; за замовчуванням `beta` -`OpenClaw Release Checks` приймає ці керовані оператором вхідні дані: +`OpenClaw Release Checks` приймає такі керовані оператором вхідні параметри: -- `ref`: гілка, тег або повний commit SHA для валідації. Перевірки з секретами - вимагають, щоб resolved commit був досяжним з гілки OpenClaw або +- `ref`: гілка, тег або повний commit SHA для перевірки. Secret-bearing checks + вимагають, щоб resolved commit був досяжний з гілки OpenClaw або релізного тегу. Правила: -- Stable і correction tags можуть публікуватися в `beta` або `latest` +- Стабільні та correction tags можуть публікуватися або в `beta`, або в `latest` - Beta prerelease tags можуть публікуватися лише в `beta` -- Для `OpenClaw NPM Release` введення повного commit SHA дозволене лише коли +- Для `OpenClaw NPM Release` введення повного commit SHA дозволено лише коли `preflight_only=true` - `OpenClaw Release Checks` і `Full Release Validation` завжди - лише валідаційні + тільки validation-only - Справжній publish path має використовувати той самий `npm_dist_tag`, що використовувався під час preflight; - робочий процес перевіряє ці metadata перед продовженням publish + workflow перевіряє, що metadata перед publish продовжує відповідати ## Послідовність стабільного npm-релізу -Під час створення стабільного npm-релізу: +Під час підготовки стабільного npm-релізу: -1. Запустіть `OpenClaw NPM Release` з `preflight_only=true` - - До існування тега можна використати поточний повний commit SHA workflow-branch +1. Запустіть `OpenClaw NPM Release` із `preflight_only=true` + - До існування тегу можна використати поточний повний commit SHA workflow-branch для validation-only dry run preflight workflow -2. Виберіть `npm_dist_tag=beta` для звичайного beta-first flow або `latest` лише - коли ви навмисно хочете прямий stable publish -3. Запустіть `Full Release Validation` на release branch, release tag або full - commit SHA, коли хочете нормальний CI плюс live prompt cache, Docker, QA Lab, - Matrix і Telegram coverage з одного ручного workflow -4. Якщо вам навмисно потрібен лише deterministic normal test graph, натомість запустіть - ручний workflow `CI` на release ref +2. Виберіть `npm_dist_tag=beta` для звичайного beta-first потоку або `latest` лише + тоді, коли навмисно хочете пряме стабільне опублікування +3. Запустіть `Full Release Validation` на релізній гілці, релізному тегу або повному + commit SHA, коли потрібні звичайний CI плюс live prompt cache, Docker, QA Lab, + Matrix і Telegram-покриття з одного ручного workflow +4. Якщо вам навмисно потрібен лише детермінований звичайний тестовий граф, запустіть + ручний workflow `CI` на release ref натомість 5. Збережіть успішний `preflight_run_id` 6. Запустіть `OpenClaw NPM Release` знову з `preflight_only=false`, тим самим `tag`, тим самим `npm_dist_tag` і збереженим `preflight_run_id` -7. Якщо реліз потрапив у `beta`, використайте приватний - `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` - workflow, щоб просунути цю stable version з `beta` до `latest` -8. Якщо реліз навмисно опубліковано прямо в `latest`, а `beta` - має негайно вказувати на той самий stable build, використайте той самий приватний - workflow, щоб спрямувати обидва dist-tags на stable version, або дозвольте його scheduled +7. Якщо реліз потрапив у `beta`, використайте приватний workflow + `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`, + щоб просунути цю стабільну версію з `beta` до `latest` +8. Якщо реліз навмисно опубліковано напряму в `latest`, а `beta` + має негайно слідувати за тією самою стабільною збіркою, використайте той самий приватний + workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій self-healing sync перемістити `beta` пізніше -Мутація dist-tag живе в приватному репозиторії з міркувань безпеки, бо вона досі -вимагає `NPM_TOKEN`, тоді як публічний репозиторій зберігає OIDC-only publish. +Мутація dist-tag міститься в приватному repo з міркувань безпеки, бо вона все ще +потребує `NPM_TOKEN`, тоді як public repo зберігає OIDC-only publish. -Це робить і direct publish path, і beta-first promotion path задокументованими -та видимими для оператора. +Це робить і direct publish path, і beta-first promotion path +задокументованими та видимими для оператора. -Якщо maintainer має повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password +Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password CLI (`op`) лише всередині dedicated tmux session. Не викликайте `op` -безпосередньо з main agent shell; утримання цього всередині tmux робить prompts, -alerts і OTP handling видимими та запобігає повторним host alerts. +напряму з main agent shell; утримання його всередині tmux робить prompts, +alerts і OTP handling спостережуваними та запобігає повторним host alerts. ## Публічні посилання @@ -539,10 +541,10 @@ alerts і OTP handling видимими та запобігає повторни - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh) - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh) -Супровідники використовують приватну документацію щодо випуску в +Супровідники використовують приватну документацію щодо випусків у [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md) -для фактичної інструкції виконання. +як фактичний операційний посібник. ## Пов’язане -- [Канали випуску](/uk/install/development-channels) +- [Канали випусків](/uk/install/development-channels)