diff --git a/docs/uk/ci.md b/docs/uk/ci.md index a71d1016c..d25cf668d 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,64 +1,178 @@ --- read_when: - - Потрібно зрозуміти, чому завдання CI виконалося або не виконалося + - Вам потрібно зрозуміти, чому завдання CI виконалося або не виконалося - Ви налагоджуєте перевірки GitHub Actions, що не проходять -summary: Граф завдань CI, контрольні етапи за областю дії та локальні еквіваленти команд -title: CI-конвеєр +summary: Граф завдань CI, перевірки за областю дії та локальні еквіваленти команд +title: Конвеєр CI x-i18n: - generated_at: "2026-04-29T03:30:36Z" + generated_at: "2026-04-29T04:29:34Z" model: gpt-5.5 provider: openai - source_hash: ff6ec4095aa24350e7dcbb894b06dc5c0eef1441dca882d1c9941c22aedbe2e4 + source_hash: 80e4eb0d3713a353a9b5e3d75a7c94435587d66ac45aad5d906bf6700ddd57fc source_path: ci.md workflow: 16 --- -CI запускається під час кожного push до `main` і кожного pull request. Вона використовує розумне визначення області, щоб пропускати дорогі завдання, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне визначення області та розгортають повний звичайний граф CI для реліз-кандидатів або широкої перевірки. +CI запускається під час кожного push до `main` і кожного pull request. Він використовує розумне визначення області, щоб пропускати дорогі завдання, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне визначення області та розгортають повний звичайний граф CI для реліз-кандидатів або широкої валідації. -`Full Release Validation` — це ручний парасольковий workflow для «запустити все перед релізом». Він приймає гілку, тег або повний SHA коміту, запускає ручний workflow `CI` з цією ціллю та запускає `OpenClaw Release Checks` для перевірки встановлення, приймання пакета, наборів Docker для релізного шляху, live/E2E, OpenWebUI, паритету QA Lab, Matrix і Telegram-ланів. Він також може запускати післяпублікаційний workflow `NPM Telegram Beta E2E`, коли надано специфікацію опублікованого пакета. `release_profile=minimum|stable|full` керує широтою live/провайдерів, що передається до release checks: `minimum` залишає найшвидші критичні для релізу лани OpenAI/core, `stable` додає стабільний набір провайдерів/backend, а `full` запускає широку консультативну матрицю провайдерів/медіа. Парасольковий workflow записує ідентифікатори запущених дочірніх запусків, а фінальне завдання `Verify full validation` повторно перевіряє поточні висновки дочірніх запусків і додає таблиці найповільніших завдань для кожного дочірнього запуску. Якщо дочірній workflow перезапущено й він став зеленим, перезапустіть лише батьківське завдання перевірки, щоб оновити результат парасолькового workflow і підсумок часу. +`Full Release Validation` — це ручний парасольковий workflow для "запустити все +перед релізом". Він приймає гілку, тег або повний SHA коміту, запускає ручний +workflow `CI` із цією ціллю та запускає `OpenClaw Release Checks` +для smoke-перевірки встановлення, приймання пакета, наборів release-path для Docker, +live/E2E, OpenWebUI, паритету QA Lab, 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. Парасольковий workflow записує +ідентифікатори запущених дочірніх запусків, а фінальне завдання `Verify full validation` повторно перевіряє +поточні висновки дочірніх запусків і додає таблиці найповільніших завдань для кожного дочірнього +запуску. Якщо дочірній workflow перезапущено і він став зеленим, перезапустіть лише батьківське +завдання verifier, щоб оновити результат парасолькового workflow і підсумок таймінгів. -Для відновлення `Full Release Validation` і `OpenClaw Release Checks` обидва приймають `rerun_group`. Використовуйте `all` для реліз-кандидата, `ci` лише для звичайного повного дочірнього CI, `release-checks` для кожного релізного дочірнього workflow або вужчу релізну групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` чи `npm-telegram` у парасольковому workflow. Це обмежує перезапуск невдалої релізної машини після точкового виправлення. +Для відновлення `Full Release Validation` і `OpenClaw Release Checks` обидва +приймають `rerun_group`. Використовуйте `all` для реліз-кандидата, `ci` лише для +звичайного повного дочірнього CI, `release-checks` для кожного релізного дочірнього запуску або вужчу +релізну групу: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, +`qa-parity`, `qa-live` або `npm-telegram` у парасольковому workflow. Це утримує перезапуск +невдалого релізного блока в межах після сфокусованого виправлення. -Дочірній live/E2E релізу зберігає широке нативне покриття `pnpm test:live`, але запускає його як іменовані шарди (`native-live-src-agents`, `native-live-src-gateway-core`, відфільтровані за провайдером завдання `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`, розділені шарди аудіо/відео медіа та відфільтровані за провайдером музичні шарди) через `scripts/test-live-shard.mjs` замість одного послідовного завдання. Це зберігає те саме файлове покриття, водночас полегшуючи перезапуск і діагностику повільних live-збоїв провайдерів. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і `native-live-extensions-media-music` залишаються чинними для ручних одноразових перезапусків. +Дочірній 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-extensions-openai`, `native-live-extensions-o-z-other`, +`native-live-extensions-xai`, розділені audio/video shards для media та +відфільтровані за 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` залишаються чинними для ручних +одноразових перезапусків. -Нативні live-шарди медіа запускаються в `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, який збирає workflow `Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і `ffprobe`; медіа-завдання лише перевіряють бінарні файли перед налаштуванням. Залишайте live-набори з Docker на звичайних runner Blacksmith, бо container jobs — неправильне місце для запуску вкладених Docker-тестів. +Нативні live media shards запускаються в +`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow +`Live Media Runner Image`. Цей образ попередньо встановлює `ffmpeg` і +`ffprobe`; media-завдання лише перевіряють наявність бінарників перед налаштуванням. Тримайте Docker-backed +live-набори на звичайних Blacksmith runners, бо container jobs — неправильне +місце для запуску вкладених Docker-тестів. -`OpenClaw Release Checks` використовує довірений ref workflow, щоб один раз розв’язати вибраний ref у tarball `release-package-under-test`, а потім передає цей артефакт і до Docker workflow релізного шляху live/E2E, і до шарда приймання пакета. Це зберігає байти пакета узгодженими між релізними машинами та уникає повторного пакування того самого кандидата в кількох дочірніх завданнях. +Docker-backed shards для live model/backend використовують окремий спільний +образ `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного коміту. Live +release workflow збирає та публікує цей образ один раз, після чого shards Docker live model, +gateway, CLI backend, ACP bind і Codex harness запускаються з +`OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці shards самостійно перебирають повну source Docker +ціль, релізний запуск неправильно налаштований і марнуватиме wall clock на дубльовані збірки образів. -`Package Acceptance` — це side-run workflow для перевірки артефакта пакета без блокування релізного workflow. Він розв’язує одного кандидата з опублікованої npm-специфікації, довіреного `package_ref`, зібраного з вибраним harness `workflow_ref`, HTTPS URL tarball із SHA-256 або tarball-артефакта з іншого запуску GitHub Actions, завантажує його як `package-under-test`, а потім повторно використовує планувальник Docker release/E2E з цим tarball замість повторного пакування checkout workflow. Профілі покривають smoke, package, product, full і custom вибори Docker-ланів. Профіль `package` використовує офлайн-покриття плагінів, тож перевірка опублікованого пакета не залежить від live-доступності ClawHub. Необов’язковий Telegram-лан повторно використовує артефакт `package-under-test` у workflow `NPM Telegram Beta E2E`, а шлях опублікованої npm-специфікації збережено для автономних запусків. +`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз розв’язати вибраний +ref у tarball `release-package-under-test`, а потім передає цей артефакт +і до live/E2E release-path Docker workflow, і до package acceptance +shard. Це зберігає байти пакета узгодженими між релізними блоками та уникає +повторного пакування того самого кандидата в кількох дочірніх завданнях. + +`Package Acceptance` — це побічний workflow для валідації артефакта пакета +без блокування релізного workflow. Він розв’язує одного кандидата з +опублікованої npm-специфікації, довіреного `package_ref`, зібраного за допомогою вибраного +`workflow_ref` harness, HTTPS URL tarball із SHA-256 або tarball-артефакта +з іншого запуску GitHub Actions, завантажує його як `package-under-test`, а потім повторно використовує +Docker release/E2E scheduler із цим tarball замість повторного пакування +checkout workflow. Профілі покривають smoke, package, product, full і custom +вибори Docker lanes. Профіль `package` використовує офлайн-покриття plugin, щоб +валідація опублікованого пакета не залежала від live-доступності ClawHub. Опційний +Telegram-напрям повторно використовує артефакт +`package-under-test` у workflow `NPM Telegram Beta E2E`, а шлях +опублікованої npm-специфікації збережено для standalone dispatches. ## Приймання пакета -Використовуйте `Package Acceptance`, коли питання звучить як «чи працює цей встановлюваний пакет OpenClaw як продукт?» Він відрізняється від звичайної CI: звичайна CI перевіряє дерево вихідного коду, тоді як приймання пакета перевіряє один tarball через той самий Docker E2E harness, який користувачі задіюють після встановлення або оновлення. +Використовуйте `Package Acceptance`, коли питання звучить як "чи працює цей встановлюваний пакет OpenClaw +як продукт?" Це відрізняється від звичайного CI: звичайний CI валідує +дерево вихідного коду, тоді як package acceptance валідує один tarball через той самий +Docker E2E harness, який користувачі виконують після встановлення або оновлення. Workflow має чотири завдання: -1. `resolve_package` робить checkout `workflow_ref`, розв’язує одного кандидата пакета, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як артефакт `package-under-test` і виводить джерело, ref workflow, ref пакета, версію, SHA-256 та профіль у підсумку кроку GitHub. -2. `docker_acceptance` викликає `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Повторно використовуваний workflow завантажує цей артефакт, перевіряє інвентар tarball, за потреби готує Docker-образи package-digest і запускає вибрані Docker-лани проти цього пакета замість пакування checkout workflow. Коли профіль вибирає кілька цільових `docker_lanes`, повторно використовуваний workflow один раз готує пакет і спільні образи, а потім розгортає ці лани як паралельні цільові Docker-завдання з унікальними артефактами. -3. `package_telegram` необов’язково викликає `NPM Telegram Beta E2E`. Він запускається, коли `telegram_mode` не дорівнює `none`, і встановлює той самий артефакт `package-under-test`, якщо Package Acceptance розв’язав пакет; автономний запуск Telegram усе ще може встановити опубліковану npm-специфікацію. -4. `summary` провалює workflow, якщо розв’язання пакета, Docker acceptance або необов’язковий Telegram-лан завершилися з помилкою. +1. `resolve_package` виконує checkout `workflow_ref`, розв’язує одного кандидата пакета, + записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує + `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як + артефакт `package-under-test` і виводить джерело, workflow ref, package + ref, версію, SHA-256 і профіль у підсумку кроку GitHub. +2. `docker_acceptance` викликає + `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і + `package_artifact_name=package-under-test`. Reusable workflow завантажує + цей артефакт, валідує інвентар tarball, готує package-digest + Docker-образи за потреби та запускає вибрані Docker lanes проти цього + пакета замість пакування checkout workflow. Коли профіль вибирає + кілька цільових `docker_lanes`, reusable workflow готує пакет + і спільні образи один раз, а потім розгортає ці lanes як паралельні цільові Docker + завдання з унікальними артефактами. +3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли + `telegram_mode` не є `none`, і встановлює той самий артефакт `package-under-test`, + якщо Package Acceptance розв’язав його; standalone Telegram dispatch + все ще може встановити опубліковану npm-специфікацію. +4. `summary` провалює workflow, якщо розв’язання пакета, Docker acceptance або + опційний Telegram-напрям завершилися невдало. Джерела кандидатів: -- `source=npm`: приймає лише `openclaw@beta`, `openclaw@latest` або точну версію релізу OpenClaw, як-от `openclaw@2026.4.27-beta.2`. Використовуйте це для приймання опублікованих beta/stable. -- `source=ref`: пакує довірену гілку, тег або повний SHA коміту `package_ref`. Розв’язувач отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт досяжний з історії гілок репозиторію або релізного тега, встановлює залежності у detached worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. -- `source=url`: завантажує HTTPS `.tgz`; `package_sha256` є обов’язковим. -- `source=artifact`: завантажує один `.tgz` з `artifact_run_id` і `artifact_name`; `package_sha256` необов’язковий, але його варто надати для зовнішньо поширених артефактів. +- `source=npm`: приймає лише `openclaw@beta`, `openclaw@latest` або точну + релізну версію OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для + приймання опублікованих beta/stable. +- `source=ref`: пакує довірену гілку, тег або повний SHA коміту `package_ref`. + Resolver отримує гілки/теги OpenClaw, перевіряє, що вибраний коміт + досяжний з історії гілки репозиторію або релізного тегу, встановлює залежності у + від’єднаному worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. +- `source=url`: завантажує HTTPS `.tgz`; `package_sha256` обов’язковий. +- `source=artifact`: завантажує один `.tgz` з `artifact_run_id` і + `artifact_name`; `package_sha256` опційний, але його варто надати для + зовнішньо поширюваних артефактів. -Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений код workflow/harness, який запускає тест. `package_ref` — це вихідний коміт, який пакується, коли `source=ref`. Це дає змогу поточному тестовому harness перевіряти старіші довірені вихідні коміти без запуску старої логіки workflow. +Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це довірений +код workflow/harness, який запускає тест. `package_ref` — це вихідний коміт, +який пакується, коли `source=ref`. Це дає змогу поточному test harness валідувати +старіші довірені коміти вихідного коду без запуску старої workflow-логіки. Профілі відповідають Docker-покриттю: - `smoke`: `npm-onboard-channel-agent`, `gateway-network`, `config-reload` -- `package`: `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update` -- `product`: `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` -- `full`: повні фрагменти Docker релізного шляху з OpenWebUI -- `custom`: точні `docker_lanes`; обов’язково, коли `suite_profile=custom` +- `package`: `npm-onboard-channel-agent`, `doctor-switch`, + `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, + `plugin-update` +- `product`: `package` плюс `mcp-channels`, `cron-mcp-cleanup`, + `openai-web-search-minimal`, `openwebui` +- `full`: повні Docker release-path chunks з OpenWebUI +- `custom`: точні `docker_lanes`; обов’язковий, коли `suite_profile=custom` -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-фрагменти релізного шляху покривають лани package/update/plugin, що перетинаються, тоді як Package Acceptance зберігає artifact-native proof для bundled-channel compat, офлайн-плагіна й Telegram проти того самого розв’язаного tarball пакета. -Cross-OS release checks усе ще покривають OS-специфічне onboarding, installer і поведінку платформи; продуктову перевірку package/update слід починати з Package Acceptance. Лани Windows packaged і installer fresh також перевіряють, що встановлений пакет може імпортувати browser-control override із сирого абсолютного шляху Windows. +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 release-path покривають перетин package/update/plugin lanes, тоді як Package +Acceptance зберігає artifact-native bundled-channel compat, offline plugin і +Telegram-доказ проти того самого розв’язаного package tarball. +Cross-OS release checks і далі покривають OS-specific onboarding, installer і +platform behavior; валідацію package/update product слід починати з Package +Acceptance. Windows packaged і installer fresh lanes також перевіряють, що +встановлений пакет може імпортувати browser-control override із сирого абсолютного +Windows-шляху. -Package Acceptance має обмежені вікна legacy-сумісності для вже опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть використовувати compatibility path для відомих приватних QA-записів у `dist/postinstall-inventory.json`, які вказують на файли, пропущені в tarball, `doctor-switch` може пропускати підвипадок збереження `gateway install --wrapper`, коли пакет не надає цей прапорець, `update-channel-switch` може видаляти відсутні `pnpm.patchedDependencies` з tarball-derived fake git fixture і може логувати відсутній збережений `update.channel`, plugin smokes можуть читати legacy install-record locations або приймати відсутнє збереження marketplace install-record, а `plugin-update` може дозволяти міграцію метаданих конфігурації, водночас усе ще вимагаючи, щоб install record і no-reinstall behavior залишалися незмінними. Опублікований пакет `2026.4.26` також може попереджати про локальні файли штампа build metadata, які вже були shipped. Пізніші пакети мають відповідати сучасним контрактам; ті самі умови завершуються помилкою, а не попередженням чи пропуском. +Package Acceptance має обмежені вікна legacy-сумісності для вже +опублікованих пакетів. Пакети до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, +можуть використовувати шлях сумісності для відомих приватних QA entries у +`dist/postinstall-inventory.json`, які вказують на файли, пропущені tarball, +`doctor-switch` може пропустити підвипадок персистентності `gateway install --wrapper`, +коли пакет не надає цей прапорець, `update-channel-switch` може обрізати +відсутні `pnpm.patchedDependencies` із fake git fixture, похідного від tarball, і +може логувати відсутній збережений `update.channel`, plugin smokes можуть читати legacy +розташування install-record або приймати відсутню персистентність marketplace install-record, +а `plugin-update` може дозволити міграцію metadata конфігурації, водночас усе ще +вимагаючи, щоб install record і поведінка no-reinstall залишалися незмінними. Опублікований +пакет `2026.4.26` також може попереджати про stamp-файли локальних build metadata, +які вже були поставлені. Пізніші пакети мають відповідати сучасним контрактам; ті самі +умови завершуються помилкою замість попередження або пропуску. Приклади: @@ -101,106 +215,29 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Під час налагодження невдалого запуску package acceptance починайте з підсумку `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали ланів, timings фаз і команди перезапуску. Надавайте перевагу перезапуску невдалого профілю пакета або точних Docker-ланів замість повторного запуску full release validation. +Під час налагодження невдалого запуску package acceptance починайте з підсумку `resolve_package`, +щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте +дочірній запуск `docker_acceptance` і його Docker-артефакти: +`.artifacts/docker-tests/**/summary.json`, `failures.json`, lane logs, phase +timings і команди перезапуску. Надавайте перевагу перезапуску невдалого профілю пакета або +точних Docker lanes замість перезапуску full release validation. -QA Lab має окремі лінії CI поза основним робочим процесом зі смарт-обмеженням за областю змін. Робочий процес -`Parity gate` запускається для відповідних змін у PR і вручну через dispatch; він -збирає приватне середовище виконання QA і порівнює mock-агентні пакети GPT-5.5 та Opus 4.6. -Робочий процес `QA-Lab - All Lanes` запускається щоночі на `main` і вручну -через dispatch; він розподіляє mock parity gate, live-лінію Matrix, а також live-лінії -Telegram і Discord у паралельні завдання. Live-завдання використовують середовище -`qa-live-shared`, а Telegram/Discord використовують оренди Convex. Перевірки релізу -запускають live-лінії транспорту Matrix і Telegram із детермінованим mock-провайдером, -щоб контракт каналу був ізольований від затримки live-моделі; підключення провайдерів -покривається окремими наборами live-моделі, нативного провайдера та Docker-провайдера. -Matrix використовує `--profile fast` для запланованих і релізних gate-перевірок, -додаючи `--fail-fast` лише тоді, коли це підтримує checkout-нутий CLI. Значення CLI за замовчуванням -і ручне введення робочого процесу залишаються `all`; ручний dispatch `matrix_profile=all` -завжди розбиває повне покриття Matrix на завдання `transport`, `media`, -`e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` також -запускає критичні для релізу лінії QA Lab перед схваленням релізу; його QA parity -gate запускає пакети кандидата й базової лінії як паралельні завдання ліній, потім завантажує -обидва артефакти в невелике завдання звіту для фінального parity-порівняння. -Не ставте шлях приземлення PR за `Parity gate`, якщо зміна фактично не -торкається середовища виконання QA, parity модельних пакетів або поверхні, якою володіє parity-робочий процес. -Для звичайних виправлень каналів, конфігурації, документації або unit-тестів розглядайте це як необов’язковий -сигнал і натомість спирайтеся на scoped CI/check-докази. +Лабораторія QA має окремі CI-лінії поза основним workflow із розумною областю дії. Workflow `Parity gate` запускається для відповідних змін у PR і через ручний запуск; він збирає приватне середовище виконання QA та порівнює agentic-пакети 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. Перевірки релізу запускають live-лінії транспорту Matrix і Telegram із детермінованим mock-провайдером і mock-кваліфікованими моделями (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримки live-моделі та звичайного запуску provider-plugin. Live transport Gateway також вимикає пошук у пам’яті, оскільки parity QA окремо покриває поведінку пам’яті; підключення провайдерів покривають окремі набори live model, native provider і Docker provider. Matrix використовує `--profile fast` для запланованих і релізних gate-перевірок, додаючи `--fail-fast` лише коли checked-out CLI це підтримує. Стандартне значення CLI і ручний вхід workflow залишаються `all`; ручний dispatch `matrix_profile=all` завжди розбиває повне покриття Matrix на завдання `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` також запускає критично важливі для релізу лінії QA Lab перед схваленням релізу; його gate parity QA запускає candidate і baseline пакети як паралельні завдання ліній, а потім завантажує обидва артефакти в невелике звітне завдання для фінального порівняння parity. +Не ставте шлях приземлення PR за `Parity gate`, якщо зміна насправді не торкається середовища виконання QA, parity model-pack або поверхні, якою володіє parity workflow. Для звичайних виправлень каналів, конфігурації, документації або unit-тестів розглядайте це як необов’язковий сигнал і натомість спирайтеся на докази зі scoped CI/check. -Робочий процес `Duplicate PRs After Merge` — це ручний робочий процес мейнтейнера для -прибирання дублікатів після приземлення. За замовчуванням він працює в dry-run і закриває лише явно -перелічені PR, коли `apply=true`. Перед зміною стану GitHub він перевіряє, що -приземлений PR змерджено і що кожен дублікат має або спільну пов’язану issue, -або перекривні змінені hunks. +Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для очищення дублікатів після приземлення. За замовчуванням він працює в режимі dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що приземлений PR змерджено і що кожен дублікат має або спільну referenced issue, або перекривані змінені hunks. -Робочий процес `CodeQL` навмисно є вузьким першим проходом сканера безпеки, -а не повним скануванням репозиторію. Щоденні та ручні запуски сканують код робочих процесів Actions -плюс найбільш ризикові JavaScript/TypeScript-поверхні auth, secrets, sandbox, cron і -gateway із високоточними security-запитами. Завдання -channel-runtime-boundary окремо сканує контракти реалізації core-каналів -плюс середовище виконання Plugin-каналів, Gateway, Plugin SDK, secrets і -audit-точки дотику в категорії `/codeql-critical-security/channel-runtime-boundary`, -щоб сигнал безпеки каналів міг масштабуватися без розширення базової -категорії JS/TS. +Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним скануванням репозиторію. Щоденні та ручні запуски сканують код Actions workflow плюс поверхні найвищого ризику JavaScript/TypeScript для auth, secrets, sandbox, cron і gateway за допомогою високоточних security queries. Завдання channel-runtime-boundary окремо сканує контракти core channel implementation разом із channel plugin runtime, Gateway, Plugin SDK, secrets і audit touchpoints у категорії `/codeql-critical-security/channel-runtime-boundary`, щоб сигнал безпеки каналів міг масштабуватися без розширення базової категорії JS/TS. -Робочий процес `CodeQL Android Critical Security` — це запланований Android-шард -безпеки. Він збирає Android-застосунок вручну для CodeQL на найменшому -лейблі Blacksmith Linux runner, прийнятому workflow sanity, і завантажує результати -в категорію `/codeql-critical-security/android`. +Workflow `CodeQL Android Critical Security` — це запланований Android security shard. Він вручну збирає Android app для CodeQL на найменшій мітці Blacksmith Linux runner, яку приймає workflow sanity, і завантажує результати в категорію `/codeql-critical-security/android`. -Робочий процес `CodeQL macOS Critical Security` — це щотижневий/ручний macOS-шард -безпеки. Він збирає macOS-застосунок вручну для CodeQL на Blacksmith macOS, -фільтрує результати збірки залежностей з завантаженого SARIF і завантажує результати -в категорію `/codeql-critical-security/macos`. Тримайте його поза щоденним -робочим процесом за замовчуванням, бо macOS-збірка домінує за часом виконання навіть коли вона чиста. +Workflow `CodeQL macOS Critical Security` — це щотижневий/ручний macOS security shard. Він вручну збирає macOS app для CodeQL на Blacksmith macOS, відфільтровує результати збірки залежностей із завантаженого SARIF і завантажує результати в категорію `/codeql-critical-security/macos`. Тримайте його поза щоденним стандартним workflow, бо збірка macOS домінує за часом виконання навіть коли все чисто. -Робочий процес `CodeQL Critical Quality` — це відповідний non-security-шард. Він -запускає лише JavaScript/TypeScript quality-запити з error-рівнем severity і без security -за вузькими високовартісними поверхнями на меншому Blacksmith Linux runner. Його -baseline-завдання сканує ту саму поверхню auth, secrets, sandbox, cron і gateway, -що й security-робочий процес. Завдання config-boundary -сканує схеми конфігурації, міграцію, нормалізацію та IO-контракти в окремій -категорії `/codeql-critical-quality/config-boundary`. Завдання -gateway-runtime-boundary сканує схеми Gateway protocol і контракти серверних методів -в окремій категорії -`/codeql-critical-quality/gateway-runtime-boundary`. Завдання -channel-runtime-boundary сканує контракти реалізації core-каналів -в окремій категорії `/codeql-critical-quality/channel-runtime-boundary`. Завдання -agent-runtime-boundary сканує виконання команд, диспетчеризацію model/provider, -диспетчеризацію auto-reply і черги, а також runtime-контракти ACP control-plane -в окремій категорії `/codeql-critical-quality/agent-runtime-boundary`. Завдання -ui-control-plane сканує bootstrap Control UI, локальне збереження, control-потоки Gateway -і runtime-контракти task control-plane в окремій категорії -`/codeql-critical-quality/ui-control-plane`. Завдання -plugin-boundary сканує контракти loader, registry, public-surface і entrypoint Plugin SDK -в окремій категорії `/codeql-critical-quality/plugin-boundary`. -Тримайте цей робочий процес окремо від security, щоб quality-знахідки можна було -планувати, вимірювати, вимикати або розширювати без затемнення security-сигналу. -Розширення CodeQL на Swift, Python і bundled-plugin слід додавати назад як -scoped або sharded follow-up роботу лише після того, як вузькі профілі матимуть стабільні -час виконання й сигнал. +Workflow `CodeQL Critical Quality` — це відповідний non-security shard. Він запускає лише error-severity, non-security JavaScript/TypeScript quality queries по вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його baseline job сканує ту саму поверхню auth, secrets, sandbox, cron і gateway, що й security workflow. Завдання config-boundary сканує config schema, migration, normalization і IO contracts в окремій категорії `/codeql-critical-quality/config-boundary`. Завдання gateway-runtime-boundary сканує gateway protocol schemas і server method contracts в окремій категорії `/codeql-critical-quality/gateway-runtime-boundary`. Завдання channel-runtime-boundary сканує core channel implementation contracts в окремій категорії `/codeql-critical-quality/channel-runtime-boundary`. Завдання agent-runtime-boundary сканує command execution, model/provider dispatch, auto-reply dispatch and queues, а також ACP control-plane runtime contracts в окремій категорії `/codeql-critical-quality/agent-runtime-boundary`. Завдання ui-control-plane сканує Control UI bootstrap, local persistence, gateway control flows і task control-plane runtime contracts в окремій категорії `/codeql-critical-quality/ui-control-plane`. Завдання 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 follow-up work лише після того, як вузькі profiles матимуть стабільні runtime і signal. -Робочий процес `Docs Agent` — це подієво-керована лінія підтримки Codex для утримання -наявної документації узгодженою з нещодавно приземленими змінами. Він не має чистого розкладу: -успішний CI-запуск після non-bot push на `main` може його запустити, а ручний dispatch може -запустити його напряму. Виклики workflow-run пропускаються, коли `main` уже просунувся далі або коли -інший не пропущений запуск Docs Agent був створений протягом останньої години. Коли він запускається, він -переглядає діапазон комітів від попереднього не пропущеного source SHA Docs Agent до -поточного `main`, тож один щогодинний запуск може покрити всі зміни main, накопичені після -останнього проходу документації. +Workflow `Docs Agent` — це подієво-керована лінія підтримки Codex для збереження наявної документації узгодженою з нещодавно приземленими змінами. Він не має чистого schedule: успішний non-bot push CI run на `main` може його запустити, а manual dispatch може запускати його напряму. Workflow-run invocations пропускаються, коли `main` уже просунувся далі або коли інший non-skipped Docs Agent run було створено за останню годину. Коли він запускається, він переглядає діапазон комітів від попереднього non-skipped Docs Agent source SHA до поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені від останнього проходу документації. -Робочий процес `Test Performance Agent` — це подієво-керована лінія підтримки Codex -для повільних тестів. Він не має чистого розкладу: успішний CI-запуск після non-bot push на -`main` може його запустити, але він пропускається, якщо інший виклик workflow-run уже -запускався або виконується того UTC-дня. Ручний dispatch обходить цей щоденний gate -активності. Лінія будує full-suite grouped Vitest performance report, дозволяє Codex -вносити лише невеликі виправлення продуктивності тестів зі збереженням покриття замість широких -рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, що зменшують -базову кількість успішних тестів. Якщо в baseline є failing tests, Codex може виправити -лише очевидні збої, а after-agent full-suite report має пройти перед -будь-яким комітом. Коли `main` просувається до того, як bot push приземлиться, лінія -rebase-ить перевірений patch, повторно запускає `pnpm check:changed` і повторює push; -конфліктні застарілі patch-і пропускаються. Вона використовує GitHub-hosted Ubuntu, щоб action Codex -міг зберегти таку саму drop-sudo safety posture, як і docs agent. +Workflow `Test Performance Agent` — це подієво-керована лінія підтримки Codex для повільних тестів. Він не має чистого schedule: успішний non-bot push CI run на `main` може його запустити, але він пропускається, якщо інший workflow-run invocation уже запускався або виконується цього UTC-дня. Manual dispatch обходить цей daily activity gate. Лінія створює full-suite grouped Vitest performance report, дозволяє Codex вносити лише невеликі coverage-preserving виправлення продуктивності тестів замість широких рефакторингів, потім повторно запускає full-suite report і відхиляє зміни, які зменшують baseline count пройдених тестів. Якщо baseline має failing tests, Codex може виправляти лише очевидні failures, а after-agent full-suite report має пройти перед будь-яким комітом. Коли `main` просувається до того, як bot push приземлиться, лінія робить rebase перевіреного patch, повторно запускає `pnpm check:changed` і повторює push; конфліктні stale patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб Codex action міг зберегти ту саму drop-sudo safety posture, що й docs agent. ```bash gh workflow run duplicate-after-merge.yml \ @@ -211,38 +248,31 @@ gh workflow run duplicate-after-merge.yml \ ## Огляд завдань -| Завдання | Призначення | Коли запускається | -| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- | -| `preflight` | Виявляє docs-only зміни, змінені scopes, змінені extensions і будує CI manifest | Завжди для non-draft push і PR | -| `security-scm-fast` | Виявлення приватних ключів і аудит робочих процесів через `zizmor` | Завжди для non-draft push і PR | -| `security-dependency-audit` | Production-аудит lockfile без залежностей за npm advisories | Завжди для non-draft push і PR | -| `security-fast` | Обов’язковий aggregate для швидких security-завдань | Завжди для non-draft push і PR | -| `build-artifacts` | Збірка `dist/`, Control UI, перевірки built-artifact і reusable downstream artifacts | Node-релевантні зміни | -| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от bundled/plugin-contract/protocol checks | Node-релевантні зміни | -| `checks-fast-contracts-channels` | Sharded channel contract checks зі стабільним aggregate check result | Node-релевантні зміни | -| `checks-node-extensions` | Повні bundled-plugin test shards для всього extension suite | Node-релевантні зміни | -| `checks-node-core-test` | Core Node test shards, крім channel, bundled, contract і extension lanes | Node-релевантні зміни | -| `check` | Sharded еквівалент основного локального gate: prod types, lint, guards, test types і strict smoke | Node-релевантні зміни | -| `check-additional` | Architecture, boundary, extension-surface guards, package-boundary і gateway-watch shards | Node-релевантні зміни | -| `build-smoke` | Built-CLI smoke tests і startup-memory smoke | Node-релевантні зміни | -| `checks` | Verifier для built-artifact channel tests | Node-релевантні зміни | -| `checks-node-compat-node22` | Збірка сумісності Node 22 і smoke-лінія | Ручний CI dispatch для релізів | -| `check-docs` | Форматування документації, lint і перевірки битих посилань | Змінено документацію | -| `skills-python` | Ruff + pytest для Skills на базі Python | Python-skill-релевантні зміни | -| `checks-windows` | Windows-специфічні process/path tests плюс shared runtime import specifier regressions | Windows-релевантні зміни | -| `macos-node` | macOS TypeScript test lane із використанням спільних built artifacts | macOS-релевантні зміни | -| `macos-swift` | Swift lint, build і tests для macOS-застосунку | macOS-релевантні зміни | -| `android` | Android unit tests для обох flavors плюс одна debug APK build | Android-релевантні зміни | -| `test-performance-agent` | Щоденна Codex-оптимізація повільних тестів після trusted activity | Успіх CI main або ручний dispatch | +| Завдання | Призначення | Коли запускається | +| -------------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------- | +| `preflight` | Виявляє зміни лише документації, змінені області, змінені extensions і збирає CI manifest | Завжди для non-draft push і PR | +| `security-scm-fast` | Виявлення private key і audit workflow через `zizmor` | Завжди для non-draft push і PR | +| `security-dependency-audit` | Audit production lockfile без залежностей щодо npm advisories | Завжди для non-draft push і PR | +| `security-fast` | Обов’язковий aggregate для швидких 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` | Повні bundled-plugin test shards для всього extension suite | Зміни, релевантні Node | +| `checks-node-core-test` | Core Node test shards, без channel, bundled, contract і extension lanes | Зміни, релевантні Node | +| `check` | Sharded equivalent main 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` | Verifier для built-artifact channel tests | Зміни, релевантні Node | +| `checks-node-compat-node22` | Node 22 compatibility build і smoke lane | Manual CI dispatch для релізів | +| `check-docs` | Форматування документації, lint і перевірки broken-link | Змінено документацію | +| `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 | -Ручні CI dispatch-и запускають той самий граф завдань, що й звичайний CI, але примусово вмикають кожну -scoped-лінію: Linux Node shards, bundled-plugin shards, channel contracts, -сумісність Node 22, `check`, `check-additional`, build smoke, docs checks, -Python skills, Windows, macOS, Android і Control UI i18n. Ручні запуски використовують -унікальну concurrency group, щоб full suite release-candidate не було скасовано -іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дозволяє -trusted caller запустити цей граф для branch, tag або full commit SHA, водночас -використовуючи файл робочого процесу з вибраного dispatch ref. +Manual CI dispatches запускають той самий job graph, що й звичайний CI, але примусово вмикають кожну scoped lane: Linux Node shards, bundled-plugin shards, channel contracts, Node 22 compatibility, `check`, `check-additional`, build smoke, docs checks, Python skills, Windows, macOS, Android і Control UI i18n. Manual runs використовують унікальну concurrency group, щоб release-candidate full suite не скасовувався іншим push або PR run на тому самому ref. Необов’язковий вхід `target_ref` дає trusted caller змогу запустити цей graph проти branch, tag або full commit SHA, використовуючи workflow file з вибраного dispatch ref. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -252,64 +282,64 @@ 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, щоб нижчі споживачі могли стартувати щойно спільна збірка буде готова. -4. Важчі смуги платформ і середовищ виконання розгалужуються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +1. `preflight` вирішує, які лінії взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою без очікування важчих завдань матриці артефактів і платформ. +3. `build-artifacts` перекривається зі швидкими лініями Linux, щоб низхідні споживачі могли стартувати, щойно спільна збірка буде готова. +4. Важчі платформні та runtime-лінії розгалужуються після цього: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-extensions`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. -Логіка області дії розміщена в `scripts/ci-changed-scope.mjs` і покрита модульними тестами в `src/scripts/ci-changed-scope.test.ts`. -Ручний запуск пропускає виявлення changed-scope і змушує маніфест preflight -діяти так, ніби кожна область із власною областю дії змінилася. -Редагування CI workflow перевіряють граф CI для Node плюс linting workflow, але самі по собі не примушують виконувати нативні збірки Windows, Android або macOS; ці платформні смуги залишаються прив’язаними до змін у платформному вихідному коді. -Редагування лише маршрутизації CI, вибрані дешеві редагування фікстур core-test і вузькі редагування допоміжних засобів/маршрутизації тестів контракту плагіна використовують швидкий шлях маніфесту лише для Node: preflight, security і одне завдання `checks-fast-core`. Цей шлях уникає артефактів збірки, сумісності з Node 22, контрактів каналів, повних core-шардів, шардів bundled-plugin і додаткових матриць захисту, коли змінені файли обмежені поверхнями маршрутизації або допоміжних засобів, які швидке завдання перевіряє напряму. -Перевірки 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 request виконують швидкий шлях для поверхонь Docker/пакетів, змін пакетів/маніфестів bundled plugin і поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke-завдання. Зміни лише у вихідному коді bundled plugin, редагування лише тестів і редагування лише документації не резервують Docker worker. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним таймаутом команди 240 секунд, при цьому Docker-запуск кожного сценарію обмежується окремо. Повний шлях зберігає QR package install і installer Docker/update-покриття для нічних запланованих запусків, ручних запусків, release checks через workflow-call і pull request, які справді зачіпають поверхні installer/package/Docker. Push до `main`, включно з merge commit, не примушують повний шлях; коли логіка changed-scope запитала б повне покриття під час push, workflow зберігає швидкий Docker smoke і залишає повний install smoke для нічної або релізної валідації. Повільний Bun global install image-provider smoke окремо керується `run_bun_global_install_smoke`; він виконується за нічним розкладом і з workflow release checks, а ручні запуски `install-smoke` можуть увімкнути його, але pull request і push до `main` його не запускають. QR і installer Docker-тести зберігають власні Dockerfile, сфокусовані на встановленні. Локальний `test:docker:all` заздалегідь збирає один спільний live-test image, один раз пакує OpenClaw як npm tarball і збирає два спільні образи `scripts/e2e/Dockerfile`: базовий Node/Git runner для смуг installer/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`; налаштуйте стандартну кількість слотів основного пулу 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а кількість слотів tail-пулу, чутливого до провайдерів, 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 і багатосервісні смуги не перевантажували Docker, тоді як легші смуги все ще заповнюють доступні слоти. Одна смуга, важча за ефективні обмеження, все одно може стартувати з порожнього пулу, а потім виконується сама, доки не звільнить місткість. Старти смуг за замовчуванням рознесені на 2 секунди, щоб уникнути локальних сплесків створення в Docker daemon; перевизначте це через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальна сукупна перевірка preflight перевіряє Docker, видаляє застарілі OpenClaw E2E containers, виводить статус активних смуг, зберігає тривалість смуг для впорядкування від найдовших і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для інспекції планувальника. За замовчуванням вона припиняє планувати нові pooled lanes після першої помилки, і кожна смуга має резервний таймаут 120 хвилин, який можна перевизначити через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; вибрані live/tail смуги використовують жорсткіші обмеження для окремих смуг. `OPENCLAW_DOCKER_ALL_LANES=` запускає точні смуги планувальника, включно зі смугами лише для релізу, як-от `install-e2e`, і розділеними bundled update-смугами, як-от `bundled-channel-update-acpx`, пропускаючи cleanup smoke, щоб агенти могли відтворити одну невдалу смугу. Reusable live/E2E workflow запитує `scripts/test-docker-all.mjs --plan-json`, яке покриття пакета, типу образу, live image, смуги й облікових даних потрібне, потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує артефакт пакета з поточного запуску, або завантажує артефакт пакета з `package_artifact_run_id`; перевіряє інвентар tarball; збирає й публікує bare/functional GHCR Docker E2E images із тегами за digest пакета через Docker layer cache Blacksmith, коли план потребує смуг із встановленим пакетом; і повторно використовує надані inputs `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` у reusable Docker E2E workflow. Він тримає `workflow_ref` окремо від `package_ref`, щоб поточна логіка acceptance могла перевіряти старіші довірені commit без checkout старого workflow-коду. Release checks запускають кастомну Package Acceptance delta для цільового ref: bundled-channel compat, offline plugin fixtures і Telegram package QA щодо визначеного tarball. Release-path Docker suite запускає менші chunked jobs із `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` лише для запусків OpenWebUI-only. Застарілі агреговані назви chunk `package-update`, `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` усе ще працюють для ручних повторних запусків, але release workflow використовує розділені chunks, щоб installer E2E і bundled plugin install/uninstall sweeps не домінували на критичному шляху. Псевдонім смуги `install-e2e` залишається агрегованим псевдонімом ручного повторного запуску для обох provider installer lanes. Chunk `bundled-channels` запускає розділені смуги `bundled-channel-*` і `bundled-channel-update-*` замість послідовної all-in-one смуги `bundled-channel-deps`. Кожен chunk завантажує `.artifacts/docker-tests/` із логами смуг, тривалостями, `summary.json`, `failures.json`, тривалостями фаз, JSON плану планувальника, таблицями повільних смуг і командами повторного запуску для кожної смуги. Input workflow `docker_lanes` запускає вибрані смуги щодо підготовлених образів замість chunk jobs, що утримує налагодження невдалої смуги в межах одного цільового Docker job і готує, завантажує або повторно використовує артефакт пакета для цього запуску; якщо вибрана смуга є live Docker lane, цільове завдання локально збирає live-test image для цього повторного запуску. Згенеровані команди повторного запуску GitHub для кожної смуги включають `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли ці значення існують, щоб невдала смуга могла повторно використати точний пакет і образи з невдалого запуску. Використовуйте `pnpm test:docker:rerun `, щоб завантажити Docker artifacts із GitHub run і надрукувати комбіновані/по-смугові цільові команди повторного запуску; використовуйте `pnpm test:docker:timings ` для підсумків повільних смуг і критичного шляху фаз. Запланований live/E2E workflow щодня запускає повний release-path Docker suite. Матриця bundled update розділена за ціллю оновлення, щоб повторні npm update і doctor repair passes могли шардитися з іншими bundled checks. +Логіка області дії міститься в `scripts/ci-changed-scope.mjs` і покрита unit-тестами в `src/scripts/ci-changed-scope.test.ts`. +Ручний запуск пропускає виявлення changed-scope і змушує preflight-маніфест +поводитися так, ніби змінилася кожна область з окремою областю дії. +Редагування CI workflow перевіряють граф Node CI плюс лінтинг workflow, але самі собою не примушують виконувати нативні збірки Windows, Android або macOS; ці платформні лінії залишаються прив’язаними до змін у платформному source. +Редагування лише маршрутизації CI, вибрані дешеві редагування core-test fixture, а також вузькі редагування helper/test-routing для контрактів плагінів використовують швидкий маніфестний шлях лише для Node: preflight, security і одне завдання `checks-fast-core`. Цей шлях уникає build artifacts, сумісності Node 22, контрактів каналів, повних core shards, shards вбудованих плагінів і додаткових guard matrices, коли змінені файли обмежені поверхнями маршрутизації або helper, які швидке завдання перевіряє напряму. +Перевірки Windows Node обмежені специфічними для Windows обгортками process/path, helper для npm/pnpm/UI runner, конфігурацією package manager і поверхнями CI workflow, які виконують цю лінію; непов’язані зміни source, плагінів, install-smoke і test-only залишаються на лініях Linux Node, щоб вони не резервували 16-vCPU Windows worker для покриття, яке вже перевіряється звичайними test shards. +Окремий workflow `install-smoke` повторно використовує той самий scope script через власне завдання `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. Pull requests запускають швидкий шлях для поверхонь Docker/package, змін package/manifest вбудованих плагінів, а також поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише source у вбудованих плагінах, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає smoke CLI для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє build arg вбудованого розширення і запускає обмежений Docker profile вбудованого плагіна під 240-секундним aggregate command timeout, причому Docker run кожного сценарію обмежений окремо. Повний шлях зберігає QR package install і installer Docker/update coverage для нічних запланованих запусків, ручних dispatches, workflow-call release checks і pull requests, які справді зачіпають installer/package/Docker поверхні. Pushes у `main`, включно з merge commits, не примушують виконувати повний шлях; коли логіка changed-scope на push вимагала б повного покриття, workflow зберігає швидкий Docker smoke і залишає full install smoke для нічної або release validation. Повільний Bun global install image-provider smoke окремо керується `run_bun_global_install_smoke`; він запускається за нічним розкладом і з release checks workflow, а ручні 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 і functional image, який встановлює той самий tarball у `/app` для звичайних functionality lanes. Визначення Docker lanes містяться в `scripts/lib/docker-e2e-scenarios.mjs`, логіка planner міститься в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний plan. Scheduler вибирає образ для кожної лінії за допомогою `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, а потім запускає лінії з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштовуйте стандартну кількість слотів main-pool, що дорівнює 10, через `OPENCLAW_DOCKER_ALL_PARALLELISM`, а чутливу до провайдерів кількість слотів 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 lanes не перевантажували Docker, поки легші лінії все ще заповнюють доступні слоти. Одна лінія, важча за ефективні обмеження, все одно може стартувати з порожнього pool, а потім працює сама, доки не звільнить capacity. Старти ліній за замовчуванням рознесені на 2 секунди, щоб уникнути штормів create у локальному Docker daemon; перевизначайте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний aggregate виконує preflight Docker, видаляє застарілі OpenClaw E2E containers, виводить статус активних ліній, зберігає timings ліній для впорядкування longest-first і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для перевірки scheduler. За замовчуванням він припиняє планувати нові pooled lanes після першого failure, і кожна лінія має 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` є високорівневим package gate: він визначає candidate з npm, довіреного `package_ref`, HTTPS tarball плюс SHA-256 або попереднього workflow artifact, а потім передає цей єдиний 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, offline plugin fixtures і Telegram package QA проти resolved tarball. Docker suite release path запускає менші 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`, коли цього вимагає повне release-path coverage, і зберігає окремий chunk `openwebui` лише для OpenWebUI-only dispatches. Legacy aggregate chunk names `package-update`, `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` все ще працюють для manual reruns, але release workflow використовує split chunks, щоб installer E2E і bundled plugin install/uninstall sweeps не домінували в critical path. Lane alias `install-e2e` залишається aggregate manual rerun alias для обох provider installer lanes. Chunk `bundled-channels` запускає split `bundled-channel-*` і `bundled-channel-update-*` lanes замість serial 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. Input workflow `docker_lanes` запускає вибрані lanes проти підготовлених 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 могла повторно використати точний package і images з failed run. Використовуйте `pnpm test:docker:rerun `, щоб завантажити Docker artifacts з GitHub run і вивести combined/per-lane targeted rerun commands; використовуйте `pnpm test:docker:timings ` для summaries slow-lane і phase critical-path. 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` залишається доступним для ручних одноразових повторних запусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими псевдонімами plugin/runtime, але release workflow використовує розділені chunks, щоб channel smokes, цілі оновлення, plugin runtime checks і bundled plugin install/uninstall sweeps могли виконуватися паралельно. Цільові запуски `docker_lanes` також розділяють кілька вибраних смуг на паралельні завдання після одного спільного кроку підготовки пакета/образу, а bundled-channel update lanes повторюють спробу один раз для тимчасових npm network failures. +Поточні 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` залишається доступним для manual 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 step, а bundled-channel update lanes повторюють спробу один раз у разі transient npm network failures. -Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий scope платформи CI: зміни core production запускають core prod і core test typecheck плюс core lint/guards, зміни лише core test запускають тільки core test typecheck плюс core lint, зміни extension production запускають extension prod і extension test typecheck плюс extension lint, а зміни лише extension test запускають extension test typecheck плюс extension lint. Зміни публічного Plugin SDK або plugin-contract розширюються до extension typecheck, бо extensions залежать від цих core contracts, але Vitest extension sweeps є явною тестовою роботою. Version bumps лише для release metadata запускають цільові version/config/root-dependency checks. Невідомі зміни root/config безпечно переходять до всіх check lanes. -Локальна маршрутизація changed-test міститься в `scripts/test-projects.test-support.mjs` і +Локальна логіка змінених lane зберігається в `scripts/changed-lanes.mjs` і виконується через `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широкий scope платформи CI: зміни production-коду core запускають typecheck core prod і core test плюс core lint/guards, зміни лише core test запускають тільки typecheck core test плюс core lint, зміни production-коду extension запускають typecheck extension prod і extension test плюс extension lint, а зміни лише extension test запускають typecheck extension test плюс extension lint. Зміни публічного Plugin SDK або plugin-contract розширюються до typecheck extension, бо extensions залежать від цих core-контрактів, але Vitest sweep для extensions є явною тестовою роботою. Version bump-и лише metadata release запускають цільові перевірки version/config/root-dependency. Невідомі зміни root/config fail safe до всіх check lanes. +Локальна маршрутизація змінених тестів зберігається в `scripts/test-projects.test-support.mjs` і навмисно дешевша за `check:changed`: прямі зміни тестів запускають самі себе, -зміни source віддають перевагу явним mappings, потім sibling tests і import-graph -dependents. Shared group-room delivery config є одним із явних mappings: -зміни до group visible-reply config, source reply delivery mode або -message-tool system prompt проходять через core reply tests плюс Discord і -Slack delivery regressions, щоб зміна shared default падала до першого PR -push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна +зміни source віддають перевагу явним mapping-ам, потім sibling tests та +залежним import-graph. Shared group-room delivery config є одним із явних mapping-ів: +зміни group visible-reply config, source reply delivery mode або +message-tool system prompt проходять через core reply tests плюс регресії доставки Discord і +Slack, тож shared default change падає ще до першого push PR. +Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна настільки harness-wide, що дешевий mapped set не є надійним proxy. -Для Testbox validation запускайте з repo root і віддавайте перевагу свіжому warmed box для -broad proof. Перш ніж витрачати повільний gate на box, який був повторно використаний, expired або +Для валідації Testbox запускайте з кореня repo й віддавайте перевагу свіжому прогрітому box для +широкого proof. Перед тим як витрачати повільний gate на box, який було reused, expired або щойно повідомив про неочікувано великий sync, спершу запустіть `pnpm testbox:sanity` всередині -box. Sanity check швидко падає, коли обов’язкові root files, як-от -`pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 +box. Sanity check швидко падає, коли required root files, як-от +`pnpm-lock.yaml`, зникли або коли `git status --short` показує принаймні 200 tracked deletions. Зазвичай це означає, що remote sync state не є надійною -копією PR. Зупиніть цей box і warmed свіжий замість налагодження -product test failure. Для навмисних PR із великими deletion встановіть +копією PR. Зупиніть цей box і прогрійте свіжий, замість того щоб debug-ити +product test failure. Для PR з intentional large deletion задайте `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity run. -Manual CI dispatches запускають `checks-node-compat-node22` як release-candidate compatibility coverage. Звичайні pull requests і `main` pushes пропускають цю lane і тримають matrix зосередженою на Node 24 test/channel lanes. +Manual CI dispatches запускають `checks-node-compat-node22` як release-candidate compatibility coverage. Звичайні pull requests і push-и в `main` пропускають цей lane та тримають matrix сфокусованою на Node 24 test/channel lanes. -Найповільніші сімейства Node test розділені або збалансовані, щоб кожен job залишався малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, bundled plugin tests балансуються між шістьма extension workers, малі core unit lanes поєднуються, auto-reply запускається як чотири balanced workers із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards, а 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 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` може відрізняти цілий 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, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тож вони все одно повідомляють про звичайні shard failures, але не стають у чергу після того, як увесь workflow уже superseded. -Automatic CI concurrency key версіонований (`CI-v7-*`), тому GitHub-side zombie у старій queue group не може безкінечно блокувати новіші main runs. Manual full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs. +Найповільніші Node test families розділені або збалансовані, щоб кожен job лишався малим без надмірного резервування runners: channel contracts запускаються як три weighted shards, bundled plugin tests балансуються між шістьма extension workers, small core unit lanes об’єднані в пари, auto-reply запускається як чотири balanced workers із reply subtree, розділеним на agent-runner, dispatch і commands/state-routing shards, а 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, бо він домінований import/scheduling, а не одним повільним test file. `runtime-config` запускається з infra core-runtime shard, щоб shared runtime shard не володів tail. Include-pattern shards записують timing entries із назвою CI shard, тож `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від filtered shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої невеликі independent guards паралельно всередині одного job. Gateway watch, channel tests і core support-boundary shard запускаються паралельно всередині `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, уникаючи дубльованого 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, але не стають у 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. -## Runners +## Ранери -| Runner | Jobs | +| Ранер | Jobs | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `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` | +| `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 могла стати в queue раніше | +| `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, де queue time для 32-vCPU коштував більше, ніж зекономив | +| `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 fallback до `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks fallback до `macos-latest` | +| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; forks fallback до `macos-latest` | +| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks fallback до `macos-latest` | -## Локальні відповідники +## Локальні еквіваленти ```bash pnpm changed:lanes # inspect the local changed-lane classifier for origin/main...HEAD @@ -337,5 +367,5 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac ## Пов’язане -- [Огляд установлення](/uk/install) -- [Release channels](/uk/install/development-channels) +- [Огляд встановлення](/uk/install) +- [Канали релізів](/uk/install/development-channels) diff --git a/docs/uk/help/testing.md b/docs/uk/help/testing.md index 43a41991c..9ce8fad65 100644 --- a/docs/uk/help/testing.md +++ b/docs/uk/help/testing.md @@ -2,198 +2,208 @@ read_when: - Запуск тестів локально або в CI - Додавання регресійних тестів для помилок моделей/провайдерів - - Налагодження поведінки Gateway + агента -summary: 'Набір для тестування: набори unit/e2e/live, ранери Docker і що перевіряє кожен тест' + - Налагодження поведінки Gateway та агента +summary: 'Набір для тестування: модульні, e2e та live-набори, виконувачі Docker і що перевіряє кожен тест' title: Тестування x-i18n: - generated_at: "2026-04-28T23:48:37Z" + generated_at: "2026-04-29T04:29:34Z" model: gpt-5.5 provider: openai - source_hash: 94c1fdadf65674bb5ce6a9503fbb7f92cc05a9a7e89557367a73469417c44b5f + source_hash: c2a7f6b046e845f0c1823923090f90b3c246357ee54835a6561dee128d7f1cfc source_path: help/testing.md workflow: 16 --- -OpenClaw має три набори Vitest (unit/integration, e2e, live) і невеликий набір -Docker-засобів запуску. Цей документ є посібником «як ми тестуємо»: +OpenClaw має три набори тестів Vitest (unit/integration, e2e, live) і невеликий набір +Docker-ранерів. Цей документ є посібником "як ми тестуємо": - Що покриває кожен набір (і що він навмисно _не_ покриває). - Які команди запускати для типових робочих процесів (локально, перед push, налагодження). - Як live-тести знаходять облікові дані та вибирають моделі/провайдерів. -- Як додавати регресії для реальних проблем моделей/провайдерів. +- Як додавати регресійні тести для реальних проблем моделей/провайдерів. -**Стек QA (qa-lab, qa-channel, live-лінії транспорту)** задокументовано окремо: +**QA-стек (qa-lab, qa-channel, live transport lanes)** документовано окремо: -- [Огляд QA](/uk/concepts/qa-e2e-automation) — архітектура, поверхня команд, створення сценаріїв. +- [Огляд QA](/uk/concepts/qa-e2e-automation) — архітектура, поверхня команд, написання сценаріїв. - [Matrix QA](/uk/concepts/qa-matrix) — довідник для `pnpm openclaw qa matrix`. -- [Канал QA](/uk/channels/qa-channel) — синтетичний транспортний plugin, який використовують сценарії з репозиторію. +- [QA channel](/uk/channels/qa-channel) — синтетичний transport plugin, який використовується сценаріями на основі репозиторію. -Ця сторінка описує запуск звичайних наборів тестів і Docker/Parallels-засобів запуску. Розділ про спеціальні засоби запуску QA нижче ([Спеціальні засоби запуску QA](#qa-specific-runners)) перелічує конкретні виклики `qa` і посилається назад на наведені вище довідники. +Ця сторінка описує запуск звичайних наборів тестів і Docker/Parallels-ранерів. Розділ про QA-специфічні ранери нижче ([QA-специфічні ранери](#qa-specific-runners)) перелічує конкретні виклики `qa` і відсилає назад до наведених вище довідників. ## Швидкий старт -У більшість днів: +У більшості випадків: - Повний gate (очікується перед push): `pnpm build && pnpm check && pnpm check:test-types && pnpm test` -- Швидший локальний запуск повного набору на машині з достатніми ресурсами: `pnpm test:max` +- Швидший локальний запуск повного набору на потужній машині: `pnpm test:max` - Прямий цикл спостереження Vitest: `pnpm test:watch` -- Пряме таргетування файлів тепер також маршрутизує шляхи extension/channel: `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` -- Надавайте перевагу таргетованим запускам, коли ітеруєте над окремою помилкою. -- Docker-підкріплений QA-сайт: `pnpm qa:lab:up` -- QA-лінія на базі Linux VM: `pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline` +- Пряме таргетування файлів тепер також маршрутизує шляхи extensions/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` -Коли ви змінюєте тести або хочете додаткової впевненості: +Коли ви змінюєте тести або хочете більше впевненості: - Gate покриття: `pnpm test:coverage` - Набір E2E: `pnpm test:e2e` -Коли налагоджуєте реальних провайдерів/моделі (потрібні справжні облікові дані): +Під час налагодження реальних провайдерів/моделей (потрібні реальні облікові дані): -- Live-набір (моделі + gateway-перевірки інструментів/зображень): `pnpm test:live` -- Тихо таргетувати один live-файл: `pnpm test:live -- src/agents/models.profiles.live.test.ts` -- Docker live-перебір моделей: `pnpm test:docker:live-models` - - Кожна вибрана модель тепер виконує текстовий turn плюс невелику перевірку в стилі читання файлу. - Моделі, чиї метадані оголошують вхід `image`, також виконують маленький turn із зображенням. - Вимикайте додаткові перевірки через `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або +- Live-набір (моделі + gateway tool/image probes): `pnpm test:live` +- Таргетувати один live-файл тихо: `pnpm test:live -- src/agents/models.profiles.live.test.ts` +- Docker live model sweep: `pnpm test:docker:live-models` + - Кожна вибрана модель тепер виконує текстовий turn плюс невеликий probe у стилі читання файлу. + Моделі, чиї метадані оголошують вхід `image`, також виконують крихітний image turn. + Вимкніть додаткові probes за допомогою `OPENCLAW_LIVE_MODEL_FILE_PROBE=0` або `OPENCLAW_LIVE_MODEL_IMAGE_PROBE=0`, коли ізолюєте збої провайдера. - Покриття CI: щоденний `OpenClaw Scheduled Live And E2E Checks` і ручний - `OpenClaw Release Checks` обидва викликають reusable live/E2E workflow з + `OpenClaw Release Checks` обидва викликають повторно використовуваний live/E2E workflow з `include_live_suites: true`, що включає окремі Docker live model - matrix jobs, розбиті за провайдерами. - - Для сфокусованих повторних запусків CI dispatch `OpenClaw Live And E2E Checks (Reusable)` + matrix jobs, розбиті за провайдером. + - Для сфокусованих повторних запусків CI запустіть `OpenClaw Live And E2E Checks (Reusable)` з `include_live_suites: true` і `live_models_only: true`. - - Додавайте нові високосигнальні секрети провайдерів до `scripts/ci-hydrate-live-auth.sh` + - Додавайте нові високосигнальні секрети провайдера до `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-лінію проти шляху app-server Codex, прив’язує синтетичний - Slack DM через `/codex bind`, виконує `/codex fast` і - `/codex permissions`, а потім перевіряє, що звичайна відповідь і вкладення зображення + - Запускає Docker live lane проти шляху Codex app-server, прив’язує синтетичний + Slack DM через `/codex bind`, перевіряє `/codex fast` і + `/codex permissions`, потім перевіряє, що звичайна відповідь і вкладення зображення проходять через native plugin binding замість ACP. - Codex app-server harness smoke: `pnpm test:docker:live-codex-harness` - - Запускає agent turns Gateway через plugin-owned Codex app-server harness, - перевіряє `/codex status` і `/codex models`, а за замовчуванням виконує перевірки image, - cron MCP, sub-agent і Guardian. Вимикайте sub-agent probe через + - Запускає gateway agent turns через Codex app-server harness, яким володіє plugin, + перевіряє `/codex status` і `/codex models`, і за замовчуванням виконує image, + cron MCP, sub-agent і Guardian probes. Вимкніть sub-agent probe за допомогою `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_PROBE=0`, коли ізолюєте інші збої Codex - app-server. Для сфокусованої перевірки sub-agent вимкніть інші перевірки: + app-server. Для сфокусованої перевірки sub-agent вимкніть інші probes: `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 probe, якщо не встановлено `OPENCLAW_LIVE_CODEX_HARNESS_SUBAGENT_ONLY=0`. - Crestodian rescue command smoke: `pnpm test:live:crestodian-rescue-channel` - - Додаткова подвійна перевірка поверхні команди порятунку message-channel. + - Opt-in перевірка з додатковим запасом для поверхні команди порятунку message-channel. Вона виконує `/crestodian status`, ставить у чергу постійну зміну моделі, відповідає `/crestodian yes` і перевіряє шлях запису audit/config. - Crestodian planner Docker smoke: `pnpm test:docker:crestodian-planner` - Запускає Crestodian у контейнері без конфігурації з фейковим Claude CLI у `PATH` - і перевіряє, що fuzzy planner fallback перетворюється на audited typed + і перевіряє, що нечіткий planner fallback перетворюється на audited typed config write. - Crestodian first-run Docker smoke: `pnpm test:docker:crestodian-first-run` - - Стартує з порожнього каталогу стану OpenClaw, маршрутизує bare `openclaw` до + - Починає з порожнього каталогу стану OpenClaw, маршрутизує bare `openclaw` до Crestodian, застосовує setup/model/agent/Discord plugin + SecretRef writes, - валідує конфігурацію та перевіряє audit entries. Та саму Ring 0 setup path - також покрито в QA Lab через + валідовує конфігурацію і перевіряє audit entries. Той самий Ring 0 setup path + також покривається в QA Lab через `pnpm openclaw qa suite --scenario crestodian-ring-zero-setup`. -- Moonshot/Kimi cost smoke: із заданим `MOONSHOT_API_KEY` запустіть - `openclaw models list --provider moonshot --json`, потім виконайте ізольований +- 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, а + проти `moonshot/kimi-k2.6`. Перевірте, що JSON повідомляє Moonshot/K2.6 і transcript асистента зберігає нормалізований `usage.cost`. -Коли вам потрібен лише один failing case, надавайте перевагу звуженню live-тестів через allowlist env vars, описані нижче. +Коли вам потрібен лише один збійний випадок, надавайте перевагу звуженню live-тестів через allowlist env vars, описані нижче. -## Спеціальні засоби запуску QA +## QA-специфічні ранери -Ці команди розташовані поруч з основними наборами тестів, коли потрібен реалізм QA-lab: +Ці команди стоять поруч з основними наборами тестів, коли потрібна реалістичність QA-lab: -CI запускає QA Lab у dedicated workflows. `Parity gate` запускається на відповідних PR і -через manual dispatch з mock providers. `QA-Lab - All Lanes` запускається щоночі на -`main` і через manual dispatch з mock parity gate, live Matrix lane, -Convex-managed live Telegram lane і Convex-managed live Discord lane як -parallel jobs. Scheduled QA і release checks явно передають Matrix `--profile fast`, -тоді як Matrix CLI і default ручного workflow input залишаються -`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, +керованим Convex live Telegram lane і керованим Convex live Discord lane як +паралельні jobs. Scheduled QA і release checks явно передають Matrix `--profile fast`, +тоді як Matrix CLI і ручний workflow input за замовчуванням залишаються +`all`; ручний dispatch може шардити `all` на `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli` jobs. `OpenClaw Release Checks` запускає parity плюс -fast Matrix і Telegram lanes перед release approval. +fast Matrix і Telegram lanes перед схваленням релізу, використовуючи +`mock-openai/gpt-5.5` для release transport checks, щоб вони залишалися детермінованими +і уникали звичайного запуску provider-plugin. Ці live transport gateways вимикають +memory search; поведінка memory залишається покритою QA parity suites. + +Full release live media shards використовують +`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, який уже має +`ffmpeg` і `ffprobe`. Docker live model/backend shards використовують спільний +образ `ghcr.io/openclaw/openclaw-live-test:`, зібраний один раз для вибраного +commit, потім тягнуть його з `OPENCLAW_SKIP_DOCKER_BUILD=1` замість перебудови +всередині кожного shard. - `pnpm openclaw qa suite` - - Запускає repo-backed QA scenarios безпосередньо на host. + - Запускає QA-сценарії на основі репозиторію безпосередньо на host. - За замовчуванням запускає кілька вибраних сценаріїв паралельно з ізольованими gateway workers. `qa-channel` за замовчуванням має concurrency 4 (обмежено кількістю вибраних сценаріїв). Використовуйте `--concurrency `, щоб налаштувати кількість - workers, або `--concurrency 1` для старішої serial lane. - - Завершується з non-zero, якщо будь-який сценарій падає. Використовуйте `--allow-failures`, коли - хочете артефакти без failing exit code. - - Підтримує provider modes `live-frontier`, `mock-openai` і `aimock`. - `aimock` запускає local AIMock-backed provider server для experimental - fixture і protocol-mock coverage без заміни scenario-aware + workers, або `--concurrency 1` для старішого serial lane. + - Завершується з non-zero, коли будь-який сценарій завершується невдало. Використовуйте `--allow-failures`, коли + потрібні artifacts без failing exit code. + - Підтримує режими провайдера `live-frontier`, `mock-openai` і `aimock`. + `aimock` запускає локальний AIMock-backed provider server для експериментального + покриття fixture і protocol-mock без заміни scenario-aware `mock-openai` lane. - `pnpm test:gateway:cpu-scenarios` - - Запускає gateway startup bench плюс невеликий mock QA Lab scenario pack + - Запускає gateway startup bench плюс невеликий пакет mock QA Lab сценаріїв (`channel-chat-baseline`, `memory-failure-fallback`, - `gateway-restart-inflight-run`) і записує combined CPU observation + `gateway-restart-inflight-run`) і записує об’єднаний CPU observation summary у `.artifacts/gateway-cpu-scenarios/`. - - За замовчуванням позначає лише sustained hot CPU observations (`--cpu-core-warn` + - За замовчуванням позначає лише стійкі hot CPU observations (`--cpu-core-warn` плюс `--hot-wall-warn-ms`), тому короткі startup bursts записуються як metrics - і не виглядають як minutes-long gateway peg regression. - - Використовує зібрані `dist` artifacts; спершу запустіть build, якщо checkout ще не - має свіжого runtime output. + без вигляду регресії minutes-long gateway peg. + - Використовує зібрані `dist` artifacts; спочатку запустіть build, коли checkout ще не має + свіжого runtime output. - `pnpm openclaw qa suite --runner multipass` - - Запускає той самий QA suite всередині disposable Multipass Linux VM. + - Запускає той самий QA suite всередині одноразової Multipass Linux VM. - Зберігає ту саму поведінку вибору сценаріїв, що й `qa suite` на host. - - Повторно використовує ті самі provider/model selection flags, що й `qa suite`. - - Live-запуски forward supported QA auth inputs, практичні для guest: - env-based provider keys, QA live provider config path і `CODEX_HOME`, - коли присутній. - - Output dirs мають залишатися під repo root, щоб guest міг записувати назад через - mounted workspace. + - Повторно використовує ті самі flags вибору provider/model, що й `qa suite`. + - Live-запуски передають підтримувані QA auth inputs, які практичні для guest: + env-based provider keys, шлях QA live provider config і `CODEX_HOME`, + коли він присутній. + - 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-backed QA site для operator-style QA роботи. - `pnpm test:docker:npm-onboard-channel-agent` - - Створює npm tarball з поточного checkout, глобально встановлює його в - Docker, запускає non-interactive OpenAI API-key onboarding, за замовчуванням налаштовує Telegram, - перевіряє, що enabling plugin встановлює runtime dependencies on - demand, запускає doctor і виконує один local agent turn проти mocked OpenAI + - Збирає npm tarball з поточного checkout, встановлює його глобально в + Docker, запускає non-interactive OpenAI API-key onboarding, за замовчуванням конфігурує Telegram, + перевіряє, що ввімкнення plugin встановлює runtime dependencies на вимогу, + запускає doctor і виконує один local 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` - - Запускає deterministic built-app Docker smoke для embedded runtime context + - Запускає детермінований built-app Docker smoke для embedded runtime context transcripts. Він перевіряє, що прихований OpenClaw runtime context зберігається як - non-display custom message замість витоку у visible user turn, - потім seed affected broken session JSONL і перевіряє, що - `openclaw doctor --fix` переписує його на active branch з backup. + non-display custom message замість протікання у видимий user turn, + потім засіває affected broken session JSONL і перевіряє, що + `openclaw doctor --fix` переписує його на активну гілку з backup. - `pnpm test:docker:npm-telegram-live` - - Встановлює candidate package OpenClaw у Docker, запускає installed-package - onboarding, налаштовує Telegram через installed CLI, потім повторно використовує - live Telegram QA lane з цим installed package як SUT Gateway. - - За замовчуванням `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`; задайте + - Встановлює кандидат пакета OpenClaw у Docker, запускає installed-package + onboarding, конфігурує Telegram через встановлений CLI, потім повторно використовує + live Telegram QA lane з цим встановленим пакетом як SUT Gateway. + - За замовчуванням використовує `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@beta`; встановіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_TGZ=/path/to/openclaw-current.tgz` або `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 встановіть `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` перевизначає shared - `OPENCLAW_QA_CREDENTIAL_ROLE` лише для цієї lane. - - GitHub Actions exposes this lane як ручний maintainer workflow - `NPM Telegram Beta E2E`. Він не запускається під час merge. Workflow використовує + 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 використовує середовище `qa-live-shared` і Convex CI credential leases. -- GitHub Actions також exposes `Package Acceptance` для side-run product proof +- GitHub Actions також виставляє `Package Acceptance` для side-run product proof проти одного candidate package. Він приймає trusted ref, published npm spec, - HTTPS tarball URL plus SHA-256 або tarball artifact з іншого run, uploads - normalized `openclaw-current.tgz` як `package-under-test`, потім запускає - existing Docker E2E scheduler зі smoke, package, product, full або custom - lane profiles. Задайте `telegram_mode=mock-openai` або `live-frontier`, щоб запустити - Telegram QA workflow проти того самого artifact `package-under-test`. + HTTPS tarball URL плюс SHA-256 або tarball artifact з іншого run, завантажує + нормалізований `openclaw-current.tgz` як `package-under-test`, потім запускає + наявний Docker E2E scheduler зі smoke, package, product, full або custom + lane profiles. Встановіть `telegram_mode=mock-openai` або `live-frontier`, щоб запустити + Telegram QA workflow проти того самого `package-under-test` artifact. - Latest beta product proof: ```bash @@ -214,7 +224,7 @@ gh workflow run package-acceptance.yml --ref main \ -f suite_profile=package ``` -- Artifact proof downloads a tarball artifact from another Actions run: +- Доказ артефактом завантажує артефакт tarball з іншого запуску Actions: ```bash gh workflow run package-acceptance.yml --ref main \ @@ -225,32 +235,31 @@ gh workflow run package-acceptance.yml --ref main \ ``` - `pnpm test:docker:bundled-channel-deps` - - Пакує й установлює поточну збірку OpenClaw у Docker, запускає Gateway - з налаштованим OpenAI, а потім вмикає вбудований канал/plugins через - зміни конфігурації. - - Перевіряє, що виявлення налаштування залишає відсутніми неналаштовані - runtime-залежності plugin, що перший налаштований запуск Gateway або doctor - установлює runtime-залежності кожного вбудованого plugin на вимогу, а - другий перезапуск не перевстановлює залежності, які вже були активовані. - - Також установлює відому старішу базову npm-версію, вмикає Telegram перед - запуском `openclaw update --tag ` і перевіряє, що post-update - doctor кандидата відновлює runtime-залежності вбудованого каналу без - postinstall-відновлення з боку harness. + - Пакує та встановлює поточну збірку OpenClaw у Docker, запускає Gateway + з налаштованим OpenAI, а потім вмикає вбудовані канали/plugins через + редагування конфігурації. + - Перевіряє, що виявлення налаштування залишає неналаштовані runtime-залежності plugin + відсутніми, перший налаштований запуск Gateway або doctor встановлює runtime-залежності кожного вбудованого + plugin на вимогу, а другий перезапуск не + перевстановлює залежності, які вже були активовані. + - Також встановлює відомий старіший базовий npm-пакет, вмикає Telegram перед запуском + `openclaw update --tag ` і перевіряє, що + post-update doctor кандидата ремонтує runtime-залежності вбудованих каналів без + postinstall-ремонту з боку harness. - `pnpm test:parallels:npm-update` - - Запускає smoke-тест оновлення нативної packaged-install інсталяції в гостях - Parallels. Кожна вибрана платформа спершу встановлює запитаний базовий - пакет, потім запускає встановлену команду `openclaw update` у тому самому - гості й перевіряє встановлену версію, статус оновлення, готовність gateway - і один хід локального агента. - - Використовуйте `--platform macos`, `--platform windows` або `--platform linux` - під час ітерацій на одному гості. Використовуйте `--json` для шляху до - артефакту підсумку й статусу кожної lane. - - Lane OpenAI типово використовує `openai/gpt-5.5` для live-перевірки ходу - агента. Передайте `--model ` або задайте - `OPENCLAW_PARALLELS_OPENAI_MODEL`, коли навмисно перевіряєте іншу модель - OpenAI. - - Обгортайте довгі локальні запуски в host timeout, щоб зависання транспорту - Parallels не спожили решту вікна тестування: + - Запускає native smoke-тест оновлення packaged-install у гостях Parallels. Кожна + вибрана платформа спершу встановлює запитаний базовий пакет, потім запускає + встановлену команду `openclaw update` у тому самому гості та перевіряє + встановлену версію, статус оновлення, готовність gateway і один локальний хід агента. + - Використовуйте `--platform macos`, `--platform windows` або `--platform linux` під час + ітерацій на одному гості. Використовуйте `--json` для шляху до summary-артефакту та + статусу кожної lane. + - Lane OpenAI використовує `openai/gpt-5.5` для live-доказу agent-turn за + замовчуванням. Передайте `--model ` або встановіть + `OPENCLAW_PARALLELS_OPENAI_MODEL`, коли навмисно перевіряєте іншу + модель OpenAI. + - Обгортайте довгі локальні запуски в timeout хоста, щоб зависання транспорту Parallels не могли + спожити решту тестового вікна: ```bash timeout --foreground 150m pnpm test:parallels:npm-update -- --json @@ -258,73 +267,73 @@ gh workflow run package-acceptance.yml --ref main \ ``` - Скрипт записує вкладені журнали lane у `/tmp/openclaw-parallels-npm-update.*`. - Перегляньте `windows-update.log`, `macos-update.log` або `linux-update.log`, - перш ніж припускати, що зовнішня обгортка зависла. + Перегляньте `windows-update.log`, `macos-update.log` або `linux-update.log` + перед тим, як припускати, що зовнішня обгортка зависла. - Оновлення Windows може витратити 10-15 хвилин на post-update doctor/runtime - відновлення залежностей на холодному гості; це все ще нормальний стан, - якщо вкладений npm debug log просувається. - - Не запускайте цю агреговану обгортку паралельно з окремими smoke-lane - Parallels для macOS, Windows або Linux. Вони спільно використовують стан VM - і можуть конфліктувати під час відновлення snapshot, роздавання пакетів або - стану guest gateway. - - Post-update перевірка запускає звичайну поверхню вбудованого plugin, бо - capability facade, як-от мовлення, генерація зображень і розуміння медіа, - завантажуються через вбудовані runtime API, навіть коли сам хід агента - перевіряє лише просту текстову відповідь. + ремонт залежностей на холодному гості; це все ще нормально, коли вкладений + npm debug-журнал просувається. + - Не запускайте цю aggregate-обгортку паралельно з окремими smoke-lane Parallels + macOS, Windows або Linux. Вони спільно використовують стан VM і можуть конфліктувати під час + відновлення snapshot, обслуговування пакетів або стану gateway гостя. + - Post-update-доказ запускає звичайну поверхню вбудованих plugin, тому що + capability-фасади, як-от мовлення, генерація зображень і розуміння медіа, + завантажуються через вбудовані runtime API навіть тоді, коли сам agent + turn перевіряє лише просту текстову відповідь. - `pnpm openclaw qa aimock` - - Запускає лише локальний сервер провайдера AIMock для прямого smoke-тестування протоколу. + - Запускає лише локальний сервер провайдера AIMock для прямого protocol smoke + тестування. - `pnpm openclaw qa matrix` - - Запускає Matrix live QA lane проти одноразового Docker-backed homeserver Tuwunel. Лише source-checkout — packaged installs не постачають `qa-lab`. - - Повний CLI, каталог профілів/сценаріїв, env vars і структура артефактів: [Matrix QA](/uk/concepts/qa-matrix). + - Запускає live QA lane Matrix проти одноразового Docker-backed homeserver Tuwunel. Лише source-checkout — packaged installs не постачають `qa-lab`. + - Повний CLI, каталог профілів/сценаріїв, env vars і розкладка артефактів: [Matrix QA](/uk/concepts/qa-matrix). - `pnpm openclaw qa telegram` - - Запускає Telegram live QA lane проти реальної приватної групи, використовуючи токени бота-драйвера та SUT-бота з env. - - Потрібні `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Ідентифікатор групи має бути числовим id чату Telegram. - - Підтримує `--credential-source convex` для спільних пулових облікових даних. Типово використовуйте режим env або задайте `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути пулові lease. - - Завершується з ненульовим кодом, якщо будь-який сценарій не вдався. Використовуйте `--allow-failures`, коли - потрібні артефакти без коду виходу з помилкою. - - Потребує двох окремих ботів в одній приватній групі, причому SUT-бот має мати Telegram username. - - Для стабільного bot-to-bot спостереження увімкніть Bot-to-Bot Communication Mode в `@BotFather` для обох ботів і переконайтеся, що бот-драйвер може спостерігати груповий трафік ботів. - - Записує Telegram QA звіт, підсумок і артефакт observed-messages у `.artifacts/qa-e2e/...`. Сценарії з відповідями містять RTT від запиту надсилання драйвером до спостереженої відповіді SUT. + - Запускає live QA lane Telegram проти справжньої приватної групи з використанням токенів driver і SUT bot з env. + - Потребує `OPENCLAW_QA_TELEGRAM_GROUP_ID`, `OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN` і `OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`. Ідентифікатор групи має бути числовим Telegram chat id. + - Підтримує `--credential-source convex` для спільних pooled credentials. Використовуйте режим env за замовчуванням або встановіть `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`, щоб увімкнути pooled leases. + - Завершується з ненульовим кодом, коли будь-який сценарій падає. Використовуйте `--allow-failures`, коли вам + потрібні артефакти без failing exit code. + - Потребує двох окремих bot в одній приватній групі, при цьому SUT bot має відкривати Telegram username. + - Для стабільного bot-to-bot спостереження ввімкніть Bot-to-Bot Communication Mode у `@BotFather` для обох bot і переконайтеся, що driver bot може спостерігати group bot traffic. + - Записує Telegram QA-звіт, summary і артефакт observed-messages у `.artifacts/qa-e2e/...`. Сценарії відповідей містять RTT від запиту надсилання driver до спостереженої відповіді SUT. -Live transport lanes мають один стандартний контракт, щоб нові транспорти не розходилися; матриця покриття для кожної lane міститься в [огляді 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` — це широкий synthetic suite і він не є частиною цієї матриці. ### Спільні облікові дані Telegram через Convex (v1) Коли `--credential-source convex` (або `OPENCLAW_QA_CREDENTIAL_SOURCE=convex`) увімкнено для -`openclaw qa telegram`, QA lab отримує ексклюзивний lease із пулу на базі Convex, надсилає heartbeats -для цього lease, доки lane виконується, і звільняє lease під час завершення. +`openclaw qa telegram`, QA lab отримує ексклюзивну lease зі backed-by-Convex pool, надсилає heartbeats +для цієї lease, поки lane виконується, і звільняє lease під час shutdown. -Еталонний scaffold проєкту Convex: +Reference 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` -- Вибір ролі облікових даних: +- Вибір credential role: - CLI: `--credential-role maintainer|ci` - - Типове значення env: `OPENCLAW_QA_CREDENTIAL_ROLE` (типово `ci` у CI, інакше `maintainer`) + - Env default: `OPENCLAW_QA_CREDENTIAL_ROLE` (за замовчуванням `ci` у CI, інакше `maintainer`) Необов’язкові env vars: -- `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (типово `1200000`) -- `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (типово `30000`) -- `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (типово `90000`) -- `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (типово `15000`) -- `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (типово `/qa-credentials/v1`) -- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (необов’язковий trace id) -- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` URL-адреси Convex лише для локальної розробки. +- `OPENCLAW_QA_CREDENTIAL_LEASE_TTL_MS` (default `1200000`) +- `OPENCLAW_QA_CREDENTIAL_HEARTBEAT_INTERVAL_MS` (default `30000`) +- `OPENCLAW_QA_CREDENTIAL_ACQUIRE_TIMEOUT_MS` (default `90000`) +- `OPENCLAW_QA_CREDENTIAL_HTTP_TIMEOUT_MS` (default `15000`) +- `OPENCLAW_QA_CONVEX_ENDPOINT_PREFIX` (default `/qa-credentials/v1`) +- `OPENCLAW_QA_CREDENTIAL_OWNER_ID` (optional trace id) +- `OPENCLAW_QA_ALLOW_INSECURE_HTTP=1` дозволяє loopback `http://` Convex URL для local-only розробки. -`OPENCLAW_QA_CONVEX_SITE_URL` має використовувати `https://` у звичайній роботі. +`OPENCLAW_QA_CONVEX_SITE_URL` має використовувати `https://` під час звичайної роботи. -Адміністративні команди maintainer (додавання/видалення/перелік пулу) потребують +Адміністративні команди maintainer (pool add/remove/list) потребують саме `OPENCLAW_QA_CONVEX_SECRET_MAINTAINER`. -CLI helpers для maintainer: +CLI-помічники для maintainers: ```bash pnpm openclaw qa credentials doctor @@ -334,16 +343,16 @@ pnpm openclaw qa credentials remove --credential-id ``` Використовуйте `doctor` перед live-запусками, щоб перевірити URL сайту Convex, broker secrets, -префікс endpoint, HTTP timeout і доступність admin/list без виведення -значень secrets. Використовуйте `--json` для machine-readable виводу в скриптах і CI +endpoint prefix, HTTP timeout і досяжність admin/list без виведення +секретних значень. Використовуйте `--json` для machine-readable output у скриптах і CI утилітах. -Типовий контракт endpoint (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): +Контракт endpoint за замовчуванням (`OPENCLAW_QA_CONVEX_SITE_URL` + `/qa-credentials/v1`): - `POST /acquire` - Запит: `{ kind, ownerId, actorRole, leaseTtlMs, heartbeatIntervalMs }` - Успіх: `{ status: "ok", credentialId, leaseToken, payload, leaseTtlMs?, heartbeatIntervalMs? }` - - Вичерпано/можна повторити: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` + - Вичерпано/retryable: `{ status: "error", code: "POOL_EXHAUSTED" | "NO_CREDENTIAL_AVAILABLE", ... }` - `POST /heartbeat` - Запит: `{ kind, ownerId, actorRole, credentialId, leaseToken, leaseTtlMs }` - Успіх: `{ status: "ok" }` (або порожній `2xx`) @@ -356,134 +365,134 @@ pnpm openclaw qa credentials remove --credential-id - `POST /admin/remove` (лише maintainer secret) - Запит: `{ credentialId, actorId }` - Успіх: `{ status: "ok", changed, credential }` - - Захист активного lease: `{ status: "error", code: "LEASE_ACTIVE", ... }` + - Active lease guard: `{ status: "error", code: "LEASE_ACTIVE", ... }` - `POST /admin/list` (лише maintainer secret) - Запит: `{ kind?, status?, includePayload?, limit? }` - Успіх: `{ status: "ok", credentials, count }` -Форма payload для типу Telegram: +Форма payload для виду Telegram: - `{ groupId: string, driverToken: string, sutToken: string }` -- `groupId` має бути рядком числового id чату Telegram. -- `admin/add` перевіряє цю форму для `kind: "telegram"` і відхиляє некоректні payload. +- `groupId` має бути числовим рядком Telegram chat id. +- `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 для нових channel adapters описані в [огляді QA → Додавання каналу](/uk/concepts/qa-e2e-automation#adding-a-channel). Мінімальна вимога: реалізувати transport runner на спільному host seam `qa-lab`, оголосити `qaRunners` у manifest plugin, змонтувати як `openclaw qa ` і створити сценарії в `qa/scenarios/`. -## Набори тестів (що де запускається) +## Тестові набори (що де запускається) -Сприймайте набори як “зростання реалістичності” (і зростання flaky/cost): +Думайте про набори як про «зростання реалізму» (і зростання нестабільності/вартості): -### Unit / integration (типово) +### Unit / integration (за замовчуванням) - Команда: `pnpm test` -- Конфігурація: нецільові запуски використовують набір shard `vitest.full-*.config.ts` і можуть розгортати multi-project shards у per-project configs для паралельного планування -- Файли: інвентарі core/unit у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; UI unit tests запускаються у виділеному shard `unit-ui` -- Обсяг: +- Конфігурація: untargeted runs використовують набір shard `vitest.full-*.config.ts` і можуть розгортати multi-project shards у per-project configs для parallel scheduling +- Файли: core/unit inventories у `src/**/*.test.ts`, `packages/**/*.test.ts` і `test/**/*.test.ts`; UI unit tests запускаються у dedicated shard `unit-ui` +- Scope: - Чисті unit tests - In-process integration tests (gateway auth, routing, tooling, parsing, config) - - Детерміновані регресії для відомих помилок -- Очікування: + - Deterministic regressions для відомих bugs +- Expectations: - Запускається в CI - - Не потребує реальних ключів + - Справжні ключі не потрібні - Має бути швидким і стабільним - + - - Нецільовий `pnpm test` запускає дванадцять менших shard configs (`core-unit-fast`, `core-unit-src`, `core-unit-security`, `core-unit-ui`, `core-unit-support`, `core-support-boundary`, `core-contracts`, `core-bundled`, `core-runtime`, `agentic`, `auto-reply`, `extensions`) замість одного гігантського нативного root-project процесу. Це зменшує піковий RSS на навантажених машинах і не дає auto-reply/extension роботі виснажувати непов’язані набори. - - `pnpm test --watch` все ще використовує нативний граф проєкту root `vitest.config.ts`, бо multi-shard watch loop непрактичний. - - `pnpm test`, `pnpm test:watch` і `pnpm test:perf:imports` спершу маршрутизують явні цілі файлів/каталогів через scoped lanes, тож `pnpm test extensions/discord/src/monitor/message-handler.preflight.test.ts` уникає повної вартості запуску root project. - - `pnpm test:changed` типово розгортає змінені git paths у дешеві scoped lanes: прямі зміни тестів, сусідні файли `*.test.ts`, явні source mappings і локальні залежні елементи import-graph. Зміни config/setup/package не запускають широкі тести, якщо явно не використати `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`. - - `pnpm check:changed` — це звичайний розумний локальний check gate для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata, live Docker tooling і tooling, а потім запускає відповідні команди typecheck, lint і guard. Він не запускає Vitest tests; викликайте `pnpm test:changed` або явний `pnpm test ` для тестового доказу. Version bumps лише для release metadata запускають цільові перевірки version/config/root-dependency з guard, який відхиляє зміни package поза полем version верхнього рівня. - - Зміни live Docker ACP harness запускають сфокусовані перевірки: синтаксис shell для live Docker auth scripts і dry-run live Docker scheduler. Зміни `package.json` включаються лише тоді, коли diff обмежений `scripts["test:docker:live-*"]`; зміни dependency, export, version та інших package-surface все ще використовують ширші guards. - - Import-light unit tests з agents, commands, plugins, auto-reply helpers, `plugin-sdk` і подібних чистих utility-областей маршрутизуються через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. - - Вибрані helper source files `plugin-sdk` і `commands` також маплять changed-mode запуски на явні сусідні тести в цих light lanes, тож зміни helpers уникають повторного запуску повного важкого набору для цього каталогу. - - `auto-reply` має виділені buckets для core helpers верхнього рівня, integration tests `reply.*` верхнього рівня і subtree `src/auto-reply/reply/**`. CI додатково розбиває reply subtree на shards agent-runner, dispatch і commands/state-routing, щоб один import-heavy bucket не володів повним хвостом Node. + - Ненацілений `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/розширень виснажувати ресурси для непов’язаних наборів тестів. + - `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` є звичайним розумним локальним контрольним бар’єром для вузької роботи. Він класифікує diff на core, core tests, extensions, extension tests, apps, docs, release metadata, live Docker tooling і tooling, а потім запускає відповідні команди typecheck, lint і guard. Він не запускає Vitest-тести; для тестового доказу викликайте `pnpm test:changed` або явний `pnpm test `. Зміни версій лише в release metadata запускають цільові перевірки version/config/root-dependency з guard, який відхиляє зміни package поза верхньорівневим полем version. + - Зміни live Docker ACP harness запускають сфокусовані перевірки: синтаксис shell для скриптів live Docker auth і dry-run планувальника live Docker. Зміни `package.json` включаються лише коли diff обмежений `scripts["test:docker:live-*"]`; dependency, export, version та інші зміни поверхні package і далі використовують ширші guards. + - Import-light unit tests з agents, commands, plugins, auto-reply helpers, `plugin-sdk` і подібних чистих utility-зон проходять через lane `unit-fast`, який пропускає `test/setup-openclaw-runtime.ts`; stateful/runtime-heavy файли залишаються на наявних lanes. + - Вибрані helper-файли джерел `plugin-sdk` і `commands` також маплять changed-mode запуски на явні сусідні тести в цих легких lanes, тому helper-зміни не перезапускають повний важкий набір тестів для цієї директорії. + - `auto-reply` має окремі buckets для верхньорівневих core helpers, верхньорівневих integration tests `reply.*` і піддерева `src/auto-reply/reply/**`. CI додатково ділить піддерево reply на shards agent-runner, dispatch і commands/state-routing, щоб один import-heavy bucket не володів повним Node tail. - + - - Коли ви змінюєте вхідні дані виявлення інструментів повідомлень або runtime - контекст Compaction, зберігайте обидва рівні покриття. - - Додавайте сфокусовані регресійні тести допоміжних функцій для меж чистої маршрутизації та нормалізації. - - Підтримуйте справність інтеграційних наборів вбудованого runner: + - Коли ви змінюєте входи виявлення message-tool або runtime-контекст compaction, + зберігайте обидва рівні покриття. + - Додавайте сфокусовані helper-регресії для меж чистої маршрутизації та нормалізації. + - Підтримуйте справний стан integration suites вбудованого 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 id і поведінка Compaction усе ще проходять - через реальні шляхи `run.ts` / `compact.ts`; тести лише допоміжних функцій - не є достатньою заміною для цих інтеграційних шляхів. + - Ці suites перевіряють, що scoped ids і поведінка compaction досі проходять + через реальні шляхи `run.ts` / `compact.ts`; тести лише helpers + не є достатньою заміною для цих integration paths. - + - - Базова конфігурація Vitest за замовчуванням використовує `threads`. + - Базова конфігурація Vitest типово використовує `threads`. - Спільна конфігурація Vitest фіксує `isolate: false` і використовує - неізольований runner у кореневих проектах, e2e та live-конфігураціях. - - Коренева UI-лінія зберігає своє налаштування `jsdom` і оптимізатор, але теж працює на + неізольований runner у кореневих проєктах, e2e і live configs. + - Кореневий UI lane зберігає свої `jsdom` setup і optimizer, але також працює на спільному неізольованому runner. - - Кожен shard `pnpm test` успадковує ті самі типові параметри `threads` + `isolate: false` + - Кожен shard `pnpm test` успадковує ті самі типові значення `threads` + `isolate: false` зі спільної конфігурації Vitest. - - `scripts/run-vitest.mjs` за замовчуванням додає `--no-maglev` для дочірніх процесів Node + - `scripts/run-vitest.mjs` типово додає `--no-maglev` для дочірніх Node-процесів Vitest, щоб зменшити churn компіляції V8 під час великих локальних запусків. - Задайте `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі штатною + Встановіть `OPENCLAW_VITEST_ENABLE_MAGLEV=1`, щоб порівняти зі стандартною поведінкою V8. - - `pnpm changed:lanes` показує, які архітектурні лінії запускає diff. - - Хук pre-commit виконує лише форматування. Він повторно додає відформатовані файли до stage і - не запускає lint, typecheck або тести. - - Явно запускайте `pnpm check:changed` перед передачею або push, коли вам - потрібен smart local check gate. - - `pnpm test:changed` за замовчуванням маршрутизується через дешеві scoped-лінії. Використовуйте - `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли агент - вирішує, що зміна harness, конфігурації, пакета або contract справді потребує ширшого + - `pnpm changed:lanes` показує, які архітектурні lanes запускає diff. + - Pre-commit hook відповідає лише за форматування. Він повторно stage-ить відформатовані файли і + не запускає lint, typecheck або tests. + - Запускайте `pnpm check:changed` явно перед handoff або push, коли вам + потрібен розумний локальний контрольний бар’єр. + - `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` зберігають ту саму поведінку маршрутизації, - лише з вищим лімітом worker. - - Локальне автомасштабування worker навмисно консервативне й зменшує навантаження, - коли середнє навантаження хоста вже високе, тому кілька одночасних - запусків Vitest за замовчуванням завдають менше шкоди. - - Базова конфігурація Vitest позначає файли проектів/конфігурації як - `forceRerunTriggers`, щоб повторні запуски в changed-режимі залишалися коректними, коли змінюється - test wiring. - - Конфігурація зберігає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних - хостах; задайте `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо хочете - одне явне розташування кешу для прямого профілювання. + лише з вищою межею workers. + - Локальне auto-scaling workers навмисно консервативне і зменшує навантаження, + коли середнє навантаження host уже високе, тому кілька паралельних + запусків Vitest типово завдають меншої шкоди. + - Базова конфігурація Vitest позначає projects/config files як + `forceRerunTriggers`, щоб changed-mode перезапуски залишалися коректними, коли + змінюється test wiring. + - Конфігурація тримає `OPENCLAW_VITEST_FS_MODULE_CACHE` увімкненим на підтримуваних + hosts; встановіть `OPENCLAW_VITEST_FS_MODULE_CACHE_PATH=/abs/path`, якщо вам потрібна + одна явна локація cache для прямого profiling. - - `pnpm test:perf:imports` вмикає звітування Vitest про тривалість імпортів, а також - вивід import-breakdown. - - `pnpm test:perf:imports:changed` обмежує той самий профілювальний перегляд - файлами, зміненими відносно `origin/main`. - - Дані таймінгів shard записуються в `.artifacts/vitest-shard-timings.json`. - Запуски всієї конфігурації використовують шлях конфігурації як ключ; CI-shard з include-pattern - додають назву shard, щоб відфільтровані shard можна було відстежувати + - `pnpm test:perf:imports` вмикає звітування Vitest про import-duration плюс + output import-breakdown. + - `pnpm test:perf:imports:changed` звужує той самий profiling view до + файлів, змінених відносно `origin/main`. + - Дані timing для shards записуються в `.artifacts/vitest-shard-timings.json`. + Whole-config runs використовують шлях config як ключ; include-pattern CI + shards додають назву shard, щоб filtered shards можна було відстежувати окремо. - - Коли один гарячий тест усе ще витрачає більшість часу на startup-імпорти, - тримайте важкі залежності за вузьким локальним швом `*.runtime.ts` і - mock-айте цей шов напряму замість того, щоб робити deep-import runtime helper лише + - Коли один hot test усе ще витрачає більшість часу на startup imports, + тримайте важкі dependencies за вузьким локальним seam `*.runtime.ts` і + mock-айте цей seam напряму замість deep-importing runtime helpers лише для передавання їх через `vi.mock(...)`. - - `pnpm test:perf:changed:bench -- --ref ` порівнює маршрутизований - `test:changed` із нативним шляхом root-project для цього закоміченого - diff і виводить wall time плюс macOS max RSS. - - `pnpm test:perf:changed:bench -- --worktree` бенчмаркить поточне - брудне дерево, маршрутизуючи список змінених файлів через + - `pnpm test:perf:changed:bench -- --ref ` порівнює routed + `test:changed` з нативним шляхом root-project для цього committed + diff і друкує wall time плюс macOS max RSS. + - `pnpm test:perf:changed:bench -- --worktree` виконує benchmark поточного + dirty tree, маршрутизуючи список змінених файлів через `scripts/test-projects.mjs` і кореневу конфігурацію Vitest. - - `pnpm test:perf:profile:main` записує CPU-профіль main-thread для - накладних витрат запуску та transform у Vitest/Vite. - - `pnpm test:perf:profile:runner` записує CPU+heap-профілі runner для - unit-набору з вимкненим файловим паралелізмом. + - `pnpm test:perf:profile:main` записує CPU profile main-thread для + startup Vitest/Vite і transform overhead. + - `pnpm test:perf:profile:runner` записує runner CPU+heap profiles для + unit suite з вимкненим file parallelism. @@ -493,252 +502,249 @@ pnpm openclaw qa credentials remove --credential-id - Команда: `pnpm test:stability:gateway` - Конфігурація: `vitest.gateway.config.ts`, примусово один worker - Обсяг: - - Запускає реальний loopback Gateway із діагностикою, увімкненою за замовчуванням - - Проганяє синтетичні gateway-повідомлення, memory та churn великих payload через шлях діагностичних подій + - Типово запускає реальний loopback Gateway з увімкненою diagnostics + - Проганяє synthetic gateway message, memory і large-payload churn через шлях diagnostic event - Запитує `diagnostics.stability` через Gateway WS RPC - - Покриває допоміжні функції збереження діагностичного stability bundle - - Перевіряє, що recorder залишається обмеженим, синтетичні RSS-зразки залишаються нижче бюджету тиску, а глибини черг на сесію знову спадають до нуля + - Покриває helpers для persistence diagnostic stability bundle + - Перевіряє, що recorder залишається bounded, synthetic RSS samples лишаються нижче pressure budget, а per-session queue depths повертаються до нуля - Очікування: - - Безпечно для CI і без ключів - - Вузька лінія для подальшої роботи над регресіями стабільності, не заміна повного набору Gateway + - Безпечно для CI і не потребує ключів + - Вузький lane для follow-up stability-regression, не заміна повного 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-параметри: +- Файли: `src/**/*.e2e.test.ts`, `test/**/*.e2e.test.ts` і bundled-plugin E2E tests у `extensions/` +- Типові значення runtime: - Використовує Vitest `threads` з `isolate: false`, як і решта repo. - - Використовує адаптивні worker (CI: до 2, локально: 1 за замовчуванням). - - За замовчуванням працює в silent-режимі, щоб зменшити накладні витрати console I/O. -- Корисні override: - - `OPENCLAW_E2E_WORKERS=` для примусового задання кількості worker (обмежено 16). - - `OPENCLAW_E2E_VERBOSE=1` для повторного ввімкнення verbose console output. + - Використовує adaptive workers (CI: до 2, локально: типово 1). + - Типово працює в silent mode, щоб зменшити overhead console I/O. +- Корисні overrides: + - `OPENCLAW_E2E_WORKERS=`, щоб примусово задати кількість workers (обмежено 16). + - `OPENCLAW_E2E_VERBOSE=1`, щоб знову ввімкнути verbose console output. - Обсяг: - End-to-end поведінка multi-instance gateway - - WebSocket/HTTP-поверхні, pairing node і важчий networking + - Поверхні WebSocket/HTTP, node pairing і важчий networking - Очікування: - - Запускається в CI (коли увімкнено в pipeline) + - Запускається в CI (коли ввімкнено в pipeline) - Реальні ключі не потрібні - - Більше рухомих частин, ніж в unit-тестах (може бути повільніше) + - Більше рухомих частин, ніж у unit tests (може бути повільніше) ### E2E: OpenShell backend smoke - Команда: `pnpm test:e2e:openshell` - Файл: `extensions/openshell/src/backend.e2e.test.ts` - Обсяг: - - Запускає ізольований OpenShell gateway на хості через Docker - - Створює sandbox із тимчасового локального Dockerfile - - Перевіряє backend OpenShell в OpenClaw через реальні `sandbox ssh-config` + SSH exec - - Перевіряє remote-canonical поведінку файлової системи через sandbox fs bridge + - Запускає ізольований OpenShell gateway на host через Docker + - Створює sandbox з тимчасового локального Dockerfile + - Перевіряє OpenShell backend OpenClaw через реальні `sandbox ssh-config` + SSH exec + - Перевіряє remote-canonical поведінку filesystem через sandbox fs bridge - Очікування: - - Лише opt-in; не частина типового запуску `pnpm test:e2e` + - Лише opt-in; не входить до типового запуску `pnpm test:e2e` - Потребує локального CLI `openshell` і робочого Docker daemon - - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, а потім знищує test gateway і sandbox -- Корисні override: - - `OPENCLAW_E2E_OPENSHELL=1` для ввімкнення тесту під час ручного запуску ширшого e2e-набору - - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell` для вказання не типового CLI binary або wrapper script + - Використовує ізольовані `HOME` / `XDG_CONFIG_HOME`, потім знищує test gateway і sandbox +- Корисні overrides: + - `OPENCLAW_E2E_OPENSHELL=1`, щоб увімкнути test під час ручного запуску ширшого e2e suite + - `OPENCLAW_E2E_OPENSHELL_COMMAND=/path/to/openshell`, щоб указати нестандартний CLI binary або wrapper script -### Live (реальні провайдери + реальні моделі) +### 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`) +- Файли: `src/**/*.live.test.ts`, `test/**/*.live.test.ts` і bundled-plugin live tests у `extensions/` +- Типово: **увімкнено** через `pnpm test:live` (встановлює `OPENCLAW_LIVE_TEST=1`) - Обсяг: - - «Чи цей провайдер/модель справді працює _сьогодні_ з реальними обліковими даними?» - - Виявляти зміни формату провайдерів, особливості tool-calling, проблеми auth і поведінку rate limit + - «Чи цей provider/model справді працює _сьогодні_ з реальними creds?» + - Ловить зміни provider format, нюанси tool-calling, auth issues і поведінку rate limit - Очікування: - - За задумом не стабільно для CI (реальні мережі, реальні політики провайдерів, квоти, збої) + - За задумом не є CI-stable (реальні networks, реальні provider policies, quotas, outages) - Коштує грошей / використовує rate limits - - Надавайте перевагу запуску звужених підмножин замість «усього» -- Live-запуски source-ять `~/.profile`, щоб підхопити відсутні API keys. -- За замовчуванням live-запуски все ще ізолюють `HOME` і копіюють config/auth material у тимчасовий test home, щоб unit fixtures не могли змінити ваш реальний `~/.openclaw`. -- Задавайте `OPENCLAW_LIVE_USE_REAL_HOME=1` лише тоді, коли ви навмисно хочете, щоб live-тести використовували ваш реальний домашній каталог. -- `pnpm test:live` тепер за замовчуванням працює в тихішому режимі: він зберігає progress output `[live] ...`, але приглушує додаткове повідомлення `~/.profile` і вимикає gateway bootstrap logs/Bonjour chatter. Задайте `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні startup logs. -- Ротація API keys (специфічно для провайдера): задайте `*_API_KEYS` у форматі через кому/крапку з комою або `*_API_KEY_1`, `*_API_KEY_2` (наприклад, `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або override для окремого live через `OPENCLAW_LIVE_*_KEY`; тести повторюють спробу на відповідях rate limit. -- Вивід progress/Heartbeat: - - Live-набори тепер виводять рядки progress у stderr, щоб довгі виклики провайдера були видимо активними навіть коли console capture Vitest тихий. - - `vitest.live.config.ts` вимикає console interception Vitest, щоб рядки progress провайдера/gateway стрімилися негайно під час live-запусків. - - Налаштовуйте direct-model Heartbeat через `OPENCLAW_LIVE_HEARTBEAT_MS`. - - Налаштовуйте gateway/probe Heartbeat через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. + - Надавайте перевагу запуску звужених subsets замість «усього» +- Live runs читають `~/.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` і mute-ить gateway bootstrap logs/Bonjour chatter. Встановіть `OPENCLAW_LIVE_TEST_QUIET=0`, якщо хочете повернути повні startup logs. +- Ротація API key (provider-specific): встановіть `*_API_KEYS` у форматі comma/semicolon або `*_API_KEY_1`, `*_API_KEY_2` (наприклад `OPENAI_API_KEYS`, `ANTHROPIC_API_KEYS`, `GEMINI_API_KEYS`) або per-live override через `OPENCLAW_LIVE_*_KEY`; tests повторюють спробу на rate limit responses. +- Progress/heartbeat output: + - Live suites тепер виводять progress lines у stderr, щоб довгі provider calls були видимо active навіть коли console capture Vitest тихий. + - `vitest.live.config.ts` вимикає console interception Vitest, щоб provider/gateway progress lines stream-илися одразу під час live runs. + - Налаштовуйте direct-model heartbeats через `OPENCLAW_LIVE_HEARTBEAT_MS`. + - Налаштовуйте gateway/probe heartbeats через `OPENCLAW_LIVE_GATEWAY_HEARTBEAT_MS`. -## Який набір запускати? +## Який suite запускати? -Використовуйте цю таблицю рішень: +Використовуйте цю decision table: -- Редагуєте логіку/тести: запускайте `pnpm test` (і `pnpm test:coverage`, якщо змінили багато) +- Редагування logic/tests: запускайте `pnpm test` (і `pnpm test:coverage`, якщо ви змінили багато) - Торкаєтеся gateway networking / WS protocol / pairing: додайте `pnpm test:e2e` -- Налагоджуєте «мій бот не працює» / provider-specific failures / tool calling: запускайте звужений `pnpm test:live` +- Налагоджуєте «мій bot не працює» / provider-specific failures / tool calling: запускайте звужений `pnpm test:live` -## Live (тести, що торкаються мережі) +## Live (network-touching) tests -Про live model matrix, CLI backend smokes, ACP smokes, harness Codex app-server -і всі live-тести media-provider (Deepgram, BytePlus, ComfyUI, image, -music, video, media harness), а також credential handling для live-запусків див. -[Тестування — live-набори](/uk/help/testing-live). +Для матриці живих моделей, димових перевірок бекенду CLI, димових перевірок ACP, тестового стенда app-server Codex і всіх live-тестів медіапровайдерів (Deepgram, BytePlus, ComfyUI, зображення, музика, відео, медійний стенд) — а також обробки облікових даних для живих запусків — див. [Тестування — live-набори](/uk/help/testing-live). -## Docker runners (необов’язкові перевірки "works in Linux") +## Docker runners (необов’язкові перевірки «працює в Linux») Ці 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`. -- Live-засоби запуску Docker за замовчуванням використовують меншу межу smoke-перевірки, щоб повний Docker-прогін залишався практичним: - `test:docker:live-models` за замовчуванням має `OPENCLAW_LIVE_MAX_MODELS=12`, а - `test:docker:live-gateway` за замовчуванням має `OPENCLAW_LIVE_GATEWAY_SMOKE=1`, +- Ранери живих моделей: `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 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`. Перевизначайте ці змінні середовища, коли ви + `OPENCLAW_LIVE_GATEWAY_MODEL_TIMEOUT_MS=90000`. Перевизначайте ці змінні середовища, коли явно хочете більший вичерпний скан. -- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, один раз пакує OpenClaw як npm tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Базовий образ є лише 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- і багатосервісним напрямам стартувати одночасно. Якщо окремий напрям важчий за активні обмеження, планувальник усе одно може запустити його, коли пул порожній, і далі тримає його єдиним активним, доки знову не з’явиться місткість. Типові значення: 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-перевірку, видаляє застарілі 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` вибирає source commit/branch/tag для пакування, коли `source=ref`; це дає змогу поточній логіці приймання перевіряти старіші довірені коміти. Профілі впорядковано за широтою: `smoke` — це швидкі install/channel/agent плюс gateway/config, `package` — це контракт package/update/plugin і типова нативна заміна для більшості покриття package/update у Parallels, `product` додає MCP-канали, очищення cron/субагента, OpenAI web search і 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. Packaged CLI smoke також покриває кореневу довідку, onboard-довідку, doctor-довідку, статус, схему конфігурації та команду списку моделей. -- Сумісність Package Acceptance із legacy обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цієї межі harness допускає лише прогалини метаданих доставлених пакетів: пропущені приватні записи QA-інвентарю, відсутній `gateway install --wrapper`, відсутні patch-файли у git-фікстурі, отриманій із tarball, відсутній збережений `update.channel`, legacy-розташування записів встановлення Plugin, відсутнє збереження записів встановлення marketplace та міграцію метаданих конфігурації під час `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` запускають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. +- `test:docker:all` один раз збирає live Docker-образ через `test:docker:live-build`, один раз пакує OpenClaw як npm-tarball через `scripts/package-openclaw-for-docker.mjs`, а потім збирає/повторно використовує два образи `scripts/e2e/Dockerfile`. Базовий образ є лише раннером 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, видаляє застарілі 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/скрипти стенда, тоді як `package_ref` вибирає source commit/branch/tag для пакування, коли `source=ref`; це дає змогу поточній логіці приймання перевіряти старіші довірені коміти. Профілі впорядковані за широтою: `smoke` — швидке встановлення/channel/agent плюс Gateway/config, `package` — контракт package/update/plugin і типова нативна заміна більшої частини покриття package/update у Parallels, `product` додає MCP-канали, очищення cron/subagent, вебпошук OpenAI та OpenWebUI, а `full` запускає Docker-фрагменти release-path з OpenWebUI. Валідація релізу запускає спеціальну дельту пакета (`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 у межах бюджету й відхиляє статичні імпорти відомих холодних Gateway-шляхів. Димова перевірка упакованого CLI також покриває довідку кореня, довідку onboard, довідку doctor, status, схему config і команду списку моделей. +- Зворотна сумісність Package Acceptance обмежена `2026.4.25` (включно з `2026.4.25-beta.*`). До цієї межі стенд допускає лише прогалини метаданих уже випущених пакетів: пропущені приватні записи QA-інвентарю, відсутній `gateway install --wrapper`, відсутні patch-файли у git-фікстурі, похідній від tarball, відсутній збережений `update.channel`, застарілі розташування записів інсталяції плагінів, відсутнє збереження marketplace install-record і міграція метаданих config під час `plugins update`. Для пакетів після `2026.4.25` ці шляхи є суворими помилками. +- Ранери контейнерних димових перевірок: `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` запускають один або кілька реальних контейнерів і перевіряють інтеграційні шляхи вищого рівня. -Live-model Docker-засоби запуску також bind-mount лише потрібні домашні каталоги CLI-автентифікації (або всі підтримувані, коли прогін не звужено), а потім копіюють їх у домашній каталог контейнера перед прогоном, щоб external-CLI OAuth міг оновлювати токени без змінення auth-сховища хоста: +Docker-ранери живих моделей також bind-монтують лише потрібні CLI auth homes (або всі підтримувані, коли запуск не звужено), а потім копіюють їх у домашній каталог контейнера перед запуском, щоб OAuth зовнішнього CLI міг оновлювати токени без зміни auth-сховища хоста: - Прямі моделі: `pnpm test:docker:live-models` (скрипт: `scripts/test-live-models-docker.sh`) -- ACP bind smoke-тест: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`; за замовчуванням покриває Claude, Codex і Gemini, зі строгим покриттям Droid/OpenCode через `pnpm test:docker:live-acp-bind:droid` і `pnpm test:docker:live-acp-bind:opencode`) -- Smoke-тест бекенду CLI: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) -- Smoke-тест Codex app-server harness: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) -- Gateway + агент для розробки: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`) -- Smoke-тест спостережуваності: `pnpm qa:otel:smoke` — це приватна лінія QA для checkout із вихідним кодом. Вона навмисно не входить до Docker-ліній релізу пакета, бо npm-архів не містить QA Lab. -- Live smoke-тест Open WebUI: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) -- Майстер онбордингу (TTY, повне створення каркаса): `pnpm test:docker:onboard` (скрипт: `scripts/e2e/onboard-docker.sh`) -- Smoke-тест онбордингу/каналу/агента npm-архіву: `pnpm test:docker:npm-onboard-channel-agent` глобально встановлює запакований архів OpenClaw у Docker, налаштовує OpenAI через онбординг із посиланням на env і за замовчуванням Telegram, перевіряє, що doctor відремонтував runtime-залежності активованого Plugin, і виконує один змокований хід агента OpenAI. Повторно використовуйте попередньо зібраний архів із `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропускайте перебудову на хості через `OPENCLAW_NPM_ONBOARD_HOST_BUILD=0` або перемикайте канал через `OPENCLAW_NPM_ONBOARD_CHANNEL=discord`. -- Smoke-тест перемикання каналу оновлення: `pnpm test:docker:update-channel-switch` глобально встановлює запакований архів OpenClaw у Docker, перемикає з пакетного `stable` на git `dev`, перевіряє збережений канал і роботу Plugin після оновлення, потім перемикає назад на пакетний `stable` і перевіряє стан оновлення. -- Smoke-тест runtime-контексту сесії: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого runtime-контексту транскрипта та ремонт doctor для зачеплених дубльованих гілок переписування prompt. -- Smoke-тест глобального встановлення Bun: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольованому домашньому каталозі й перевіряє, що `openclaw infer image providers --json` повертає вбудованих провайдерів зображень замість зависання. Повторно використовуйте попередньо зібраний архів із `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропускайте збірку на хості через `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або копіюйте `dist/` із зібраного Docker-образу через `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. -- Docker smoke-тест інсталятора: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm-кеш для root-, update- і direct-npm-контейнерів. Smoke-тест оновлення за замовчуванням використовує npm `latest` як стабільну базову версію перед оновленням до кандидатного архіву. Локально перевизначте через `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` або на GitHub через вхідний параметр `update_baseline_version` workflow Install Smoke. Перевірки інсталятора без root тримають ізольований npm-кеш, щоб записи кешу, що належать root, не маскували поведінку встановлення для локального користувача. Установіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати root/update/direct-npm-кеш під час локальних повторних запусків. -- Install Smoke CI пропускає дубльоване глобальне direct-npm-оновлення через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цього env, коли потрібне покриття прямого `npm install -g`. -- Smoke-тест CLI видалення агентами спільного workspace: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) за замовчуванням збирає кореневий образ Dockerfile, засіває двох агентів з одним workspace в ізольованому домашньому каталозі контейнера, запускає `agents delete --json` і перевіряє валідний JSON та поведінку збереження workspace. Повторно використовуйте образ install-smoke через `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. -- Мережа Gateway (два контейнери, WS-автентифікація + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) -- Smoke-тест snapshot Browser CDP: `pnpm test:docker:browser-cdp-snapshot` (скрипт: `scripts/e2e/browser-cdp-snapshot-docker.sh`) збирає вихідний E2E-образ і шар Chromium, запускає Chromium із raw CDP, виконує `browser doctor --deep` і перевіряє, що snapshot ролей CDP покривають URL посилань, клікабельні елементи, підвищені курсором, iframe-посилання й метадані фреймів. -- Регресія мінімального reasoning для OpenAI Responses web_search: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) пропускає змокований сервер OpenAI через Gateway, перевіряє, що `web_search` піднімає `reasoning.effort` з `minimal` до `low`, потім примусово спричиняє відхилення схеми провайдером і перевіряє, що сирі деталі з'являються в логах Gateway. -- Міст MCP-каналів (засіяний Gateway + stdio-міст + smoke-тест raw Claude notification-frame): `pnpm test:docker:mcp-channels` (скрипт: `scripts/e2e/mcp-channels-docker.sh`) -- MCP-інструменти Pi bundle (реальний stdio MCP-сервер + smoke-тест allow/deny вбудованого профілю Pi): `pnpm test:docker:pi-bundle-mcp-tools` (скрипт: `scripts/e2e/pi-bundle-mcp-tools-docker.sh`) -- Очищення Cron/subagent MCP (реальний Gateway + завершення дочірнього stdio MCP після ізольованого cron і одноразових запусків subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) -- Plugins (install smoke-тест, ClawHub kitchen-sink install/uninstall, оновлення marketplace та ввімкнення/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-сервер ClawHub. -- Smoke-тест незміненого оновлення Plugin: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) -- Smoke-тест метаданих перезавантаження конфігурації: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) -- Runtime-залежності вбудованого Plugin: `pnpm test:docker:bundled-channel-deps` за замовчуванням збирає невеликий образ Docker-runner, один раз збирає й пакує OpenClaw на хості, а потім монтує цей архів у кожний сценарій встановлення Linux. Повторно використовуйте образ через `OPENCLAW_SKIP_DOCKER_BUILD=1`, пропускайте перебудову на хості після свіжої локальної збірки через `OPENCLAW_BUNDLED_CHANNEL_HOST_BUILD=0` або вкажіть на наявний архів через `OPENCLAW_CURRENT_PACKAGE_TGZ=/path/to/openclaw-*.tgz`. Повний Docker-агрегат і release-path chunks bundled-channel попередньо пакують цей архів один раз, а потім розбивають перевірки вбудованих каналів на незалежні лінії, включно з окремими лініями оновлення для Telegram, Discord, Slack, Feishu, memory-lancedb і ACPX. Release chunks розділяють smoke-тести каналів, цілі оновлення та контракти setup/runtime на `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-b` і `bundled-channels-contracts`; агрегатний chunk `bundled-channels` лишається доступним для ручних повторних запусків. Release workflow також розділяє chunks інсталяторів провайдерів і chunks install/uninstall вбудованого Plugin; застарілі chunks `package-update`, `plugins-runtime` і `plugins-integrations` лишаються агрегатними псевдонімами для ручних повторних запусків. Використовуйте `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, щоб звузити матрицю каналів під час прямого запуску bundled-лінії, або `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, щоб звузити сценарій оновлення. Лінія також перевіряє, що `channels..enabled=false` і `plugins.entries..enabled=false` пригнічують ремонт doctor/runtime-залежностей. -- Звужуйте runtime-залежності вбудованого Plugin під час ітерацій, вимикаючи непов'язані сценарії, наприклад: +- ACP bind smoke: `pnpm test:docker:live-acp-bind` (скрипт: `scripts/test-live-acp-bind-docker.sh`; за замовчуванням покриває Claude, Codex і Gemini, зі строгим покриттям Droid/OpenCode через `pnpm test:docker:live-acp-bind:droid` і `pnpm test:docker:live-acp-bind:opencode`) +- CLI backend smoke: `pnpm test:docker:live-cli-backend` (скрипт: `scripts/test-live-cli-backend-docker.sh`) +- Codex app-server harness smoke: `pnpm test:docker:live-codex-harness` (скрипт: `scripts/test-live-codex-harness-docker.sh`) +- Gateway + агент розробки: `pnpm test:docker:live-gateway` (скрипт: `scripts/test-live-gateway-models-docker.sh`) +- Observability smoke: `pnpm qa:otel:smoke` — це приватна QA-лінія перевірки source checkout. Вона навмисно не входить до package Docker release lanes, бо npm tarball не містить QA Lab. +- Open WebUI live smoke: `pnpm test:docker:openwebui` (скрипт: `scripts/e2e/openwebui-docker.sh`) +- Майстер onboarding (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 через onboarding з env-ref і за замовчуванням Telegram, перевіряє, що doctor repair активував 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, перемикається з package `stable` на git `dev`, перевіряє збережений канал і роботу Plugin після оновлення, потім перемикається назад на package `stable` і перевіряє статус оновлення. +- Session runtime context smoke: `pnpm test:docker:session-runtime-context` перевіряє збереження прихованого runtime context у transcript, а також doctor repair уражених дубльованих гілок prompt-rewrite. +- Bun global install smoke: `bash scripts/e2e/bun-global-install-smoke.sh` пакує поточне дерево, встановлює його через `bun install -g` в ізольованому home і перевіряє, що `openclaw infer image providers --json` повертає вбудованих image providers замість зависання. Повторно використовуйте попередньо зібраний tarball через `OPENCLAW_BUN_GLOBAL_SMOKE_PACKAGE_TGZ=/path/to/openclaw-*.tgz`, пропустіть host build через `OPENCLAW_BUN_GLOBAL_SMOKE_HOST_BUILD=0` або скопіюйте `dist/` із зібраного Docker image через `OPENCLAW_BUN_GLOBAL_SMOKE_DIST_IMAGE=openclaw-dockerfile-smoke:local`. +- Installer Docker smoke: `bash scripts/test-install-sh-docker.sh` спільно використовує один npm cache між своїми root, update і direct-npm контейнерами. Update smoke за замовчуванням використовує npm `latest` як stable baseline перед оновленням до candidate tarball. Перевизначте локально через `OPENCLAW_INSTALL_SMOKE_UPDATE_BASELINE=2026.4.22` або через input `update_baseline_version` workflow Install Smoke на GitHub. Non-root перевірки installer зберігають ізольований npm cache, щоб cache entries, які належать root, не маскували user-local install behavior. Установіть `OPENCLAW_INSTALL_SMOKE_NPM_CACHE_DIR=/path/to/cache`, щоб повторно використовувати root/update/direct-npm cache між локальними повторними запусками. +- Install Smoke CI пропускає дубльоване direct-npm global update через `OPENCLAW_INSTALL_SMOKE_SKIP_NPM_GLOBAL=1`; запускайте скрипт локально без цієї env, коли потрібне покриття прямого `npm install -g`. +- Agents delete shared workspace CLI smoke: `pnpm test:docker:agents-delete-shared-workspace` (скрипт: `scripts/e2e/agents-delete-shared-workspace-docker.sh`) за замовчуванням збирає root Dockerfile image, засіває двох агентів з одним workspace в ізольованому container home, запускає `agents delete --json` і перевіряє валідний JSON плюс поведінку збереженого workspace. Повторно використовуйте install-smoke image через `OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_IMAGE=openclaw-dockerfile-smoke:local OPENCLAW_AGENTS_DELETE_SHARED_WORKSPACE_E2E_SKIP_BUILD=1`. +- Gateway networking (два контейнери, WS auth + health): `pnpm test:docker:gateway-network` (скрипт: `scripts/e2e/gateway-network-docker.sh`) +- Browser CDP snapshot smoke: `pnpm test:docker:browser-cdp-snapshot` (скрипт: `scripts/e2e/browser-cdp-snapshot-docker.sh`) збирає source E2E image плюс шар Chromium, запускає Chromium із raw CDP, виконує `browser doctor --deep` і перевіряє, що CDP role snapshots охоплюють link URLs, clickables, підвищені cursor, iframe refs і frame metadata. +- OpenAI Responses web_search minimal reasoning regression: `pnpm test:docker:openai-web-search-minimal` (скрипт: `scripts/e2e/openai-web-search-minimal-docker.sh`) запускає змокований OpenAI server через Gateway, перевіряє, що `web_search` підвищує `reasoning.effort` з `minimal` до `low`, потім примусово викликає reject provider schema і перевіряє, що raw detail з’являється в Gateway logs. +- 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 + teardown stdio MCP child після ізольованих запусків cron і one-shot subagent): `pnpm test:docker:cron-mcp-cleanup` (скрипт: `scripts/e2e/cron-mcp-cleanup-docker.sh`) +- Plugins (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 server ClawHub. +- Plugin update unchanged smoke: `pnpm test:docker:plugin-update` (скрипт: `scripts/e2e/plugin-update-unchanged-docker.sh`) +- Config reload metadata smoke: `pnpm test:docker:config-reload` (скрипт: `scripts/e2e/config-reload-source-docker.sh`) +- Bundled plugin runtime deps: `pnpm test:docker:bundled-channel-deps` за замовчуванням збирає малий Docker runner image, один раз збирає й пакує OpenClaw на хості, потім монтує цей tarball у кожен сценарій Linux install. Повторно використовуйте image через `OPENCLAW_SKIP_DOCKER_BUILD=1`, пропустіть host rebuild після свіжої локальної збірки через `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 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` лишається доступним для ручних reruns. Release workflow також розділяє provider installer chunks і bundled plugin install/uninstall chunks; застарілі chunks `package-update`, `plugins-runtime` і `plugins-integrations` лишаються aggregate aliases для ручних reruns. Використовуйте `OPENCLAW_BUNDLED_CHANNELS=telegram,slack`, щоб звузити channel matrix під час прямого запуску bundled lane, або `OPENCLAW_BUNDLED_CHANNEL_UPDATE_TARGETS=telegram,acpx`, щоб звузити update scenario. Lane також перевіряє, що `channels..enabled=false` і `plugins.entries..enabled=false` пригнічують repair doctor/runtime-dependency. +- Звужуйте bundled plugin runtime deps під час ітерацій, вимикаючи непов’язані сценарії, наприклад: `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`. -Щоб вручну попередньо зібрати й повторно використати спільний функціональний образ: +Щоб вручну попередньо зібрати й повторно використовувати спільний functional image: ```bash OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local pnpm test:docker:e2e-build OPENCLAW_DOCKER_E2E_IMAGE=openclaw-docker-e2e-functional:local OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:mcp-channels ``` -Suite-specific перевизначення образів, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, все одно мають пріоритет, якщо задані. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на віддалений спільний образ, скрипти витягують його, якщо він ще не локальний. QR- і Docker-тести інсталятора зберігають власні Dockerfile, бо вони перевіряють поведінку пакета/встановлення, а не спільний runtime зібраного застосунку. +Suite-specific image overrides, як-от `OPENCLAW_GATEWAY_NETWORK_E2E_IMAGE`, усе ще мають пріоритет, коли їх задано. Коли `OPENCLAW_SKIP_DOCKER_BUILD=1` вказує на remote shared image, скрипти завантажують його, якщо його ще немає локально. QR і installer Docker tests зберігають власні Dockerfiles, бо вони перевіряють package/install behavior, а не shared built-app runtime. -Docker-runner-и live-model також монтують поточний checkout у режимі read-only і -розгортають його в тимчасовий робочий каталог усередині контейнера. Це зберігає runtime -образ легким, але все ще запускає Vitest проти саме вашого локального source/config. -Крок staging пропускає великі локальні кеші та результати збірки застосунків, як-от -`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також локальні для застосунків `.build` або -каталоги результатів Gradle, щоб Docker live-запуски не витрачали хвилини на копіювання -машинно-специфічних артефактів. -Вони також установлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб live-перевірки gateway не запускали -реальні воркери каналів Telegram/Discord тощо всередині контейнера. +Live-model Docker runners також bind-mount поточний checkout read-only і +розгортають його в тимчасовий workdir усередині контейнера. Це зберігає runtime +image компактним, але все одно запускає Vitest проти вашого точного локального source/config. +Крок staging пропускає великі local-only caches і app build outputs, як-от +`.pnpm-store`, `.worktrees`, `__openclaw_vitest__`, а також app-local `.build` або +каталоги Gradle output, щоб Docker live runs не витрачали хвилини на копіювання +machine-specific artifacts. +Вони також установлюють `OPENCLAW_SKIP_CHANNELS=1`, щоб gateway live probes не запускали +реальних Telegram/Discord тощо channel workers усередині контейнера. `test:docker:live-models` усе ще запускає `pnpm test:live`, тому також передавайте -`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити live-покриття gateway -з цієї Docker-лінії. -`test:docker:openwebui` — це суміснісний smoke-тест вищого рівня: він запускає -контейнер gateway OpenClaw з увімкненими OpenAI-сумісними HTTP endpoint, -запускає закріплений контейнер Open WebUI проти цього gateway, входить через -Open WebUI, перевіряє, що `/api/models` показує `openclaw/default`, а потім надсилає -реальний chat-запит через proxy `/api/chat/completions` Open WebUI. -Перший запуск може бути помітно повільнішим, бо Docker може знадобитися витягнути -образ Open WebUI, а Open WebUI може знадобитися завершити власне cold-start налаштування. -Ця лінія очікує придатний live model key, а `OPENCLAW_PROFILE_FILE` -(`~/.profile` за замовчуванням) є основним способом надати його в Dockerized-запусках. -Успішні запуски друкують невеликий JSON payload на кшталт `{ "ok": true, "model": +`OPENCLAW_LIVE_GATEWAY_*`, коли потрібно звузити або виключити gateway +live coverage із цієї Docker lane. +`test:docker:openwebui` — це compatibility smoke вищого рівня: він запускає +контейнер OpenClaw gateway з увімкненими OpenAI-сумісними HTTP endpoints, +запускає pinned container Open WebUI проти цього gateway, входить через +Open WebUI, перевіряє, що `/api/models` експонує `openclaw/default`, а потім надсилає +реальний chat request через proxy `/api/chat/completions` Open WebUI. +Перший запуск може бути помітно повільнішим, бо Docker може знадобитися завантажити +image Open WebUI, а Open WebUI може знадобитися завершити власний cold-start setup. +Ця lane очікує придатний live model key, а `OPENCLAW_PROFILE_FILE` +(`~/.profile` за замовчуванням) є основним способом надати його в Dockerized runs. +Успішні запуски друкують малий JSON payload на кшталт `{ "ok": true, "model": "openclaw/default", ... }`. `test:docker:mcp-channels` навмисно детермінований і не потребує -реального облікового запису Telegram, Discord або iMessage. Він завантажує засіяний Gateway -контейнер, запускає другий контейнер, який породжує `openclaw mcp serve`, потім -перевіряє маршрутизоване виявлення розмов, читання транскриптів, метадані вкладень, -поведінку live event queue, маршрутизацію outbound send і Claude-style channel + -permission notifications через реальний stdio MCP-міст. Перевірка notification -інспектує сирі stdio MCP frames напряму, щоб smoke-тест валідовував те, що -міст фактично випромінює, а не лише те, що випадково показує конкретний client SDK. +реального облікового запису Telegram, Discord або iMessage. Він завантажує засіяний контейнер Gateway, +запускає другий контейнер, який породжує `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. Перевірка notifications +напряму інспектує raw stdio MCP frames, тому smoke перевіряє те, що +bridge фактично емітить, а не лише те, що випадково показує конкретний client SDK. `test:docker:pi-bundle-mcp-tools` детермінований і не потребує live -model key. Він збирає Docker-образ repo, запускає реальний probe-сервер stdio MCP -усередині контейнера, матеріалізує цей сервер через runtime embedded Pi bundle -MCP, виконує інструмент, а потім перевіряє, що `coding` і `messaging` зберігають -інструменти `bundle-mcp`, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують. +model key. Він збирає Docker image репозиторію, запускає реальний stdio MCP probe server +усередині контейнера, матеріалізує цей server через embedded Pi bundle +MCP runtime, виконує tool, а потім перевіряє, що `coding` і `messaging` зберігають +`bundle-mcp` tools, тоді як `minimal` і `tools.deny: ["bundle-mcp"]` їх фільтрують. `test:docker:cron-mcp-cleanup` детермінований і не потребує live model -key. Він запускає засіяний Gateway з реальним probe-сервером stdio MCP, виконує -ізольований cron-хід і одноразовий дочірній хід `/subagents spawn`, а потім перевіряє, -що дочірній процес MCP завершується після кожного запуску. +key. Він запускає засіяний Gateway з реальним stdio MCP probe server, виконує +ізольований cron turn і one-shot child turn `/subagents spawn`, а потім перевіряє, +що MCP child process завершується після кожного запуску. -Ручний ACP smoke-тест thread plain-language (не CI): +Ручний ACP plain-language thread smoke (не CI): - `bun scripts/dev/discord-acp-plain-language-smoke.ts --channel ...` -- Збережіть цей скрипт для workflow регресії/налагодження. Він може знову знадобитися для валідації маршрутизації ACP thread, тому не видаляйте його. +- Зберігайте цей скрипт для regression/debug workflows. Він може знову знадобитися для ACP thread routing validation, тому не видаляйте його. Корисні env vars: -- `OPENCLAW_CONFIG_DIR=...` (типово: `~/.openclaw`) монтується до `/home/node/.openclaw` -- `OPENCLAW_WORKSPACE_DIR=...` (типово: `~/.openclaw/workspace`) монтується до `/home/node/.openclaw/workspace` -- `OPENCLAW_PROFILE_FILE=...` (типово: `~/.profile`) монтується до `/home/node/.profile` і підвантажується перед запуском тестів -- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, щоб перевіряти лише змінні середовища, підвантажені з `OPENCLAW_PROFILE_FILE`, використовуючи тимчасові каталоги конфігурації/робочого простору й без зовнішніх монтувань автентифікації CLI -- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (типово: `~/.cache/openclaw/docker-cli-tools`) монтується до `/home/node/.npm-global` для кешованих установок CLI всередині Docker -- Зовнішні каталоги/файли автентифікації CLI в `$HOME` монтуються лише для читання під `/host-auth...`, а потім копіюються до `/home/node/...` перед запуском тестів - - Типові каталоги: `.minimax` - - Типові файли: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` - - Звужені запуски провайдерів монтують лише потрібні каталоги/файли, виведені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` - - Перевизначайте вручну за допомогою `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або списку через кому, наприклад `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` +- `OPENCLAW_CONFIG_DIR=...` (за замовчуванням: `~/.openclaw`) монтується до `/home/node/.openclaw` +- `OPENCLAW_WORKSPACE_DIR=...` (за замовчуванням: `~/.openclaw/workspace`) монтується до `/home/node/.openclaw/workspace` +- `OPENCLAW_PROFILE_FILE=...` (за замовчуванням: `~/.profile`) монтується до `/home/node/.profile` і завантажується перед запуском тестів +- `OPENCLAW_DOCKER_PROFILE_ENV_ONLY=1`, щоб перевіряти лише змінні середовища, завантажені з `OPENCLAW_PROFILE_FILE`, з використанням тимчасових каталогів конфігурації/робочої області та без зовнішніх монтувань автентифікації CLI +- `OPENCLAW_DOCKER_CLI_TOOLS_DIR=...` (за замовчуванням: `~/.cache/openclaw/docker-cli-tools`) монтується до `/home/node/.npm-global` для кешованих встановлень CLI у Docker +- Зовнішні каталоги/файли автентифікації CLI у `$HOME` монтуються лише для читання у `/host-auth...`, а потім копіюються до `/home/node/...` перед початком тестів + - Каталоги за замовчуванням: `.minimax` + - Файли за замовчуванням: `~/.codex/auth.json`, `~/.codex/config.toml`, `.claude.json`, `~/.claude/.credentials.json`, `~/.claude/settings.json`, `~/.claude/settings.local.json` + - Звужені запуски провайдерів монтують лише потрібні каталоги/файли, визначені з `OPENCLAW_LIVE_PROVIDERS` / `OPENCLAW_LIVE_GATEWAY_PROVIDERS` + - Перевизначте вручну за допомогою `OPENCLAW_DOCKER_AUTH_DIRS=all`, `OPENCLAW_DOCKER_AUTH_DIRS=none` або списку через кому, як-от `OPENCLAW_DOCKER_AUTH_DIRS=.claude,.codex` - `OPENCLAW_LIVE_GATEWAY_MODELS=...` / `OPENCLAW_LIVE_MODELS=...`, щоб звузити запуск -- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, щоб фільтрувати провайдерів у контейнері -- `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб повторно використати наявний образ `openclaw:local-live` для повторних запусків, які не потребують повторного збирання -- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб гарантувати, що облікові дані надходять зі сховища профілю (а не із середовища) +- `OPENCLAW_LIVE_GATEWAY_PROVIDERS=...` / `OPENCLAW_LIVE_PROVIDERS=...`, щоб фільтрувати провайдерів усередині контейнера +- `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб повторно використати наявний образ `openclaw:local-live` для повторних запусків, яким не потрібна перебудова +- `OPENCLAW_LIVE_REQUIRE_PROFILE_KEYS=1`, щоб переконатися, що облікові дані надходять зі сховища профілю (а не з env) - `OPENCLAW_OPENWEBUI_MODEL=...`, щоб вибрати модель, яку Gateway надає для smoke-тесту Open WebUI -- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити prompt перевірки nonce, який використовує smoke-тест Open WebUI +- `OPENCLAW_OPENWEBUI_PROMPT=...`, щоб перевизначити запит перевірки nonce, який використовує smoke-тест Open WebUI - `OPENWEBUI_IMAGE=...`, щоб перевизначити закріплений тег образу Open WebUI ## Перевірка документації -Запускайте перевірки документації після редагування документів: `pnpm check:docs`. -Запускайте повну перевірку якорів Mintlify, коли також потрібні перевірки заголовків на сторінці: `pnpm docs:check-links:anchors`. +Запускайте перевірки документації після редагувань документації: `pnpm check:docs`. +Запускайте повну валідацію якорів 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 (імітація 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`). +- Імітація виклику інструментів через реальний gateway + цикл агента (`src/gateway/gateway.test.ts`). +- Наскрізні потоки майстра, які перевіряють прив’язку сесії та вплив конфігурації (`src/gateway/gateway.test.ts`). -Чого ще бракує для skills (див. [Skills](/uk/tools/skills)): +Чого ще бракує для Skills (див. [Skills](/uk/tools/skills)): -- **Прийняття рішень:** коли skills перелічені в prompt, чи вибирає агент правильний skill (або уникає нерелевантних)? -- **Дотримання вимог:** чи читає агент `SKILL.md` перед використанням і чи дотримується потрібних кроків/аргументів? -- **Контракти workflow:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сесії та межі sandbox. +- **Прийняття рішень:** коли Skills перелічені в запиті, чи вибирає агент правильний skill (або уникає нерелевантних)? +- **Відповідність:** чи читає агент `SKILL.md` перед використанням і чи виконує обов’язкові кроки/аргументи? +- **Контракти робочого процесу:** багатокрокові сценарії, які перевіряють порядок інструментів, перенесення історії сесії та межі пісочниці. -Майбутні оцінювання спершу мають лишатися детермінованими: +Майбутні оцінювання спершу мають залишатися детермінованими: -- Ранер сценаріїв із мокованими провайдерами для перевірки викликів інструментів + порядку, читання файлів skill і зв’язування сесій. -- Невеликий набір сценаріїв, зосереджених на skill (використовувати чи уникати, gating, prompt injection). -- Необов’язкові live-оцінювання (opt-in, керовані змінними середовища) лише після того, як буде готовий безпечний для CI набір. +- Засіб запуску сценаріїв, що використовує імітованих провайдерів для перевірки викликів інструментів + порядку, читання файлів Skills і прив’язки сесії. +- Невеликий набір сценаріїв, сфокусованих на Skills (використовувати чи уникати, обмеження, ін’єкція запиту). +- Необов’язкові live-оцінювання (за явним увімкненням, через env) лише після того, як безпечний для CI набір буде готовий. -## Контрактні тести (форма plugin і каналу) +## Контрактні тести (форма Plugin і каналу) -Контрактні тести перевіряють, що кожен зареєстрований plugin і канал відповідає своєму -контракту інтерфейсу. Вони проходять усі виявлені plugins і запускають набір -перевірок форми та поведінки. Типова unit-смуга `pnpm test` навмисно -пропускає ці спільні seam- і smoke-файли; запускайте контрактні команди явно, +Контрактні тести перевіряють, що кожен зареєстрований Plugin і канал відповідає своєму +контракту інтерфейсу. Вони проходять усі виявлені Plugins і запускають набір +перевірок форми та поведінки. Стандартна unit-лінія `pnpm test` навмисно +пропускає ці файли спільних швів і smoke-тестів; запускайте контрактні команди явно, коли торкаєтеся спільних поверхонь каналів або провайдерів. ### Команди @@ -751,58 +757,58 @@ key. Він запускає засіяний Gateway з реальним probe- Розташовані в `src/channels/plugins/contracts/*.contract.test.ts`: -- **plugin** - Базова форма plugin (id, назва, capabilities) -- **setup** - Контракт майстра налаштування -- **session-binding** - Поведінка зв’язування сесії -- **outbound-payload** - Структура payload повідомлення -- **inbound** - Обробка вхідних повідомлень -- **actions** - Обробники дій каналу -- **threading** - Обробка ID потоку -- **directory** - API каталогу/списку -- **group-policy** - Застосування групової політики +- **plugin** - базова форма Plugin (id, назва, можливості) +- **setup** - контракт майстра налаштування +- **session-binding** - поведінка прив’язки сесії +- **outbound-payload** - структура корисного навантаження повідомлення +- **inbound** - обробка вхідних повідомлень +- **actions** - обробники дій каналу +- **threading** - обробка ID гілки +- **directory** - API каталогу/списку учасників +- **group-policy** - застосування групової політики ### Контракти статусу провайдерів Розташовані в `src/plugins/contracts/*.contract.test.ts`. -- **status** - Перевірки статусу каналу -- **registry** - Форма реєстру Plugin +- **status** - перевірки статусу каналу +- **registry** - форма реєстру Plugin ### Контракти провайдерів Розташовані в `src/plugins/contracts/*.contract.test.ts`: -- **auth** - Контракт потоку автентифікації -- **auth-choice** - Вибір автентифікації +- **auth** - контракт потоку автентифікації +- **auth-choice** - вибір/обрання автентифікації - **catalog** - API каталогу моделей -- **discovery** - Виявлення Plugin -- **loader** - Завантаження Plugin -- **runtime** - Runtime провайдера -- **shape** - Форма/інтерфейс Plugin -- **wizard** - Майстер налаштування +- **discovery** - виявлення Plugin +- **loader** - завантаження Plugin +- **runtime** - середовище виконання провайдера +- **shape** - форма/інтерфейс Plugin +- **wizard** - майстер налаштування ### Коли запускати - Після зміни експортів або підшляхів plugin-sdk -- Після додавання або змінення каналу чи provider plugin +- Після додавання або зміни каналу чи Plugin провайдера - Після рефакторингу реєстрації або виявлення Plugin -Контрактні тести запускаються в CI й не потребують реальних API-ключів. +Контрактні тести запускаються в CI і не потребують реальних API-ключів. -## Додавання регресій (настанови) +## Додавання регресій (поради) Коли ви виправляєте проблему провайдера/моделі, виявлену наживо: -- Додайте безпечну для CI регресію, якщо можливо (мок/стаб провайдера або фіксація точної трансформації форми запиту) -- Якщо це за своєю суттю лише live-випадок (ліміти швидкості, політики автентифікації), зробіть live-тест вузьким і opt-in через змінні середовища -- Віддавайте перевагу найменшому шару, який ловить баг: - - помилка конвертації/відтворення запиту провайдера → прямий тест моделей - - помилка конвеєра сесії/історії/інструментів Gateway → live smoke Gateway або безпечний для CI мок-тест Gateway -- Захисне обмеження обходу SecretRef: - - `src/secrets/exec-secret-ref-id-parity.test.ts` виводить одну вибіркову ціль для кожного класу SecretRef із метаданих реєстру (`listSecretTargetRegistryEntries()`), а потім перевіряє, що exec id із сегментами обходу відхиляються. - - Якщо ви додаєте нову родину цілей SecretRef `includeInPlan` у `src/secrets/target-registry-data.ts`, оновіть `classifyTargetClass` у цьому тесті. Тест навмисно падає на некласифікованих target id, щоб нові класи не можна було мовчки пропустити. +- Додайте безпечну для CI регресію, якщо можливо (mock/stub провайдера або захопіть точне перетворення форми запиту) +- Якщо це за своєю суттю лише live-випадок (обмеження частоти, політики автентифікації), зробіть live-тест вузьким і ввімкненим явно через env vars +- Віддавайте перевагу найменшому шару, який ловить помилку: + - помилка перетворення/повторного відтворення запиту провайдера → прямий тест моделей + - помилка конвеєра сесії/історії/інструментів gateway → live smoke gateway або безпечний для 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, щоб нові класи не можна було непомітно пропустити. ## Пов’язане -- [Live-тестування](/uk/help/testing-live) +- [Тестування наживо](/uk/help/testing-live) - [CI](/uk/ci)