From b9a46ae8db2ec8eab1d4e4f868a4b351a29c1a7b Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Wed, 29 Apr 2026 13:39:28 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/ci.md | 443 ++++++++++++++++++++------------------------------ 1 file changed, 178 insertions(+), 265 deletions(-) diff --git a/docs/uk/ci.md b/docs/uk/ci.md index c5398151b..601cde400 100644 --- a/docs/uk/ci.md +++ b/docs/uk/ci.md @@ -1,103 +1,102 @@ --- read_when: - - Вам потрібно зрозуміти, чому CI-завдання запустилося або не запустилося - - Ви налагоджуєте перевірки GitHub Actions, що не проходять -summary: Граф завдань CI, гейти за областю дії та локальні еквіваленти команд + - Вам потрібно зрозуміти, чому завдання CI запустилося або не запустилося + - Ви налагоджуєте перевірки GitHub Actions, що завершуються помилкою +summary: Граф завдань CI, гейти області охоплення та локальні еквіваленти команд title: CI-конвеєр x-i18n: - generated_at: "2026-04-29T11:37:33Z" + generated_at: "2026-04-29T13:37:09Z" model: gpt-5.5 provider: openai - source_hash: f3240aa7058dc4f624c45a400cac7a5b2cbbe442a7e17f3f0e1858cc9a876129 + source_hash: 706dfe3a1b92a4e561ec76d8a6f192ad5d821f4c21ab546d28a9a1f6d4b962cb source_path: ci.md workflow: 16 --- -CI запускається під час кожного push до `main` і кожного pull request. Вона використовує розумне обмеження області, щоб пропускати витратні завдання, коли змінилися лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області й розгортають повний звичайний граф CI для реліз-кандидатів або широкої валідації, причому Android-доріжки вмикаються через `include_android` для окремих ручних запусків. Доріжки передрелізів Plugin лише для релізів живуть в окремому workflow `Plugin Prerelease` і запускаються тільки з `Full Release Validation` або явного ручного dispatch. +CI запускається для кожного push до `main` і кожного pull request. Він використовує розумне обмеження області, щоб пропускати витратні завдання, коли змінено лише непов’язані ділянки. Ручні запуски `workflow_dispatch` навмисно обходять розумне обмеження області й розгортають повний звичайний граф CI для release candidates або широкої валідації, а Android-напрями вмикаються окремо через `include_android` для автономних ручних запусків. Напрями prerelease для Plugin, призначені лише для релізів, містяться в окремому workflow `Plugin Prerelease` і запускаються тільки з `Full Release Validation` або явного ручного dispatch. -Шард `check-dependencies` запускає `pnpm deadcode:dependencies`, production-прохід Knip лише для залежностей, закріплений на останній версії Knip, яку використовує цей script, з вимкненим мінімальним віком релізу pnpm для встановлення `dlx`. Він також запускає `pnpm deadcode:unused-files`, що порівнює production-знахідки Knip щодо невикористаних файлів із `scripts/deadcode-unused-files.allowlist.mjs`. Цей захист падає, коли PR додає новий непереглянутий невикористаний файл або залишає застарілий запис allowlist після очищення, водночас зберігаючи навмисні динамічні поверхні Plugin, generated, build, live-test і package bridge, які Knip не може статично розв’язати. +Шард `check-dependencies` запускає `pnpm deadcode:dependencies`, production-прохід Knip лише для залежностей, закріплений на останній версії Knip, яку використовує цей скрипт, із вимкненим мінімальним віком релізу pnpm для встановлення `dlx`. Він також запускає `pnpm deadcode:unused-files`, який порівнює production-знахідки Knip щодо невикористаних файлів із `scripts/deadcode-unused-files.allowlist.mjs`. Цей запобіжник падає, коли PR додає новий неперевірений невикористаний файл або залишає застарілий запис allowlist після очищення, водночас зберігаючи навмисні поверхні динамічних plugin, згенеровані, build, live-test і package bridge, які Knip не може статично розв’язати. -`Full Release Validation` — це ручний umbrella workflow для "запустити все -перед релізом." Він приймає гілку, tag або повний commit SHA, dispatch-ить +`Full Release Validation` — це ручний парасольковий workflow для «запустити все +перед релізом». Він приймає branch, tag або повний commit SHA, dispatch-ить ручний workflow `CI` з цією ціллю, dispatch-ить `Plugin Prerelease` для -релізних доказів Plugin/package/static/Docker і dispatch-ить +release-only доказів plugin/package/static/Docker і dispatch-ить `OpenClaw Release Checks` для install smoke, package acceptance, Docker release-path suites, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram -lanes. Він також може запускати post-publish workflow `NPM Telegram Beta E2E`, коли надано -опублікований package spec. `release_profile=minimum|stable|full` керує шириною live/provider, -переданою в release checks: `minimum` зберігає найшвидші критичні для релізу доріжки OpenAI/core, +напрямів. Він також може запускати post-publish workflow `NPM Telegram Beta E2E`, коли надано +published package spec. `release_profile=minimum|stable|full` керує шириною live/provider, +яку передають у release checks: `minimum` залишає найшвидші критичні для релізу напрями OpenAI/core, `stable` додає стабільний набір provider/backend, а -`full` запускає широку advisory provider/media matrix. Umbrella записує -ids запущених child run, а фінальне завдання `Verify full validation` повторно перевіряє -поточні висновки child run і додає таблиці найповільніших завдань для кожного child -run. Якщо child workflow перезапущено і він став зеленим, перезапустіть лише parent -verifier job, щоб оновити результат umbrella і timing summary. +`full` запускає широку advisory provider/media matrix. Парасолька записує +ids запущених дочірніх run, а фінальне завдання `Verify full validation` повторно перевіряє +поточні conclusions дочірніх run і додає таблиці найповільніших завдань для кожного дочірнього +run. Якщо дочірній workflow перезапущено і він став green, перезапустіть лише батьківське +завдання verifier, щоб оновити результат парасольки й підсумок часу. Для відновлення `Full Release Validation` і `OpenClaw Release Checks` обидва -приймають `rerun_group`. Використовуйте `all` для реліз-кандидата, `ci` лише для -звичайного full CI child, `release-checks` для кожного release child або вужчу +приймають `rerun_group`. Використовуйте `all` для release candidate, `ci` лише для +звичайного повного дочірнього CI, `release-checks` для кожної release child або вужчу release group: `install-smoke`, `cross-os`, `live-e2e`, `package`, `qa`, -`qa-parity`, `qa-live` або `npm-telegram` в umbrella. Це утримує перезапуск failed -release box у межах після точкового виправлення. +`qa-parity`, `qa-live` або `npm-telegram` у парасольці. Це утримує перезапуск невдалого +release box у межах після сфокусованого виправлення. -Release live/E2E child зберігає широке native покриття `pnpm test:live`, але -запускає його як named shards (`native-live-src-agents`, -`native-live-src-gateway-core`, provider-filtered -`native-live-src-gateway-profiles` jobs, +Дочірній live/E2E реліз зберігає широке native-покриття `pnpm test:live`, але +запускає його як іменовані шарди (`native-live-src-agents`, +`native-live-src-gateway-core`, відфільтровані за provider +завдання `native-live-src-gateway-profiles`, `native-live-src-gateway-backends`, `native-live-test`, `native-live-extensions-a-k`, `native-live-extensions-l-n`, `native-live-extensions-openai`, `native-live-extensions-o-z-other`, -`native-live-extensions-xai`, розділені media audio/video shards і -provider-filtered music shards) через `scripts/test-live-shard.mjs` замість -одного serial job. Це зберігає те саме файлове покриття, водночас полегшуючи повторний запуск -і діагностику повільних live provider failures. Aggregate +`native-live-extensions-xai`, розділені media audio/video шарди та +відфільтровані за provider music шарди) через `scripts/test-live-shard.mjs` замість +одного послідовного завдання. Це зберігає те саме покриття файлів, але робить повільні збої live +provider легшими для повторного запуску й діагностики. Агреговані назви шардів `native-live-extensions-o-z`, `native-live-extensions-media` і -`native-live-extensions-media-music` shard names залишаються чинними для ручних -one-shot reruns. +`native-live-extensions-media-music` залишаються чинними для ручних +одноразових перезапусків. -Native live media shards запускаються в -`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, який збирає -workflow `Live Media Runner Image`. Цей image попередньо встановлює `ffmpeg` і -`ffprobe`; media jobs лише перевіряють binaries перед setup. Тримайте Docker-backed +Native live media шарди запускаються в +`ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`, зібраному workflow +`Live Media Runner Image`. Цей image попередньо встановлює `ffmpeg` і +`ffprobe`; media-завдання лише перевіряють binaries перед setup. Тримайте Docker-backed live suites на звичайних Blacksmith runners, бо container jobs — неправильне місце для запуску nested Docker tests. -Docker-backed live model/backend shards використовують окремий спільний -image `ghcr.io/openclaw/openclaw-live-test:` для вибраного commit. Live -release workflow збирає і публікує цей image один раз, після чого Docker live model, -gateway, CLI backend, ACP bind і Codex harness shards запускаються з -`OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці shards незалежно перебудовують повну source Docker -target, release run налаштовано неправильно, і він марнуватиме wall -clock на дубльовані image builds. +Docker-backed live model/backend шарди використовують окремий спільний +image `ghcr.io/openclaw/openclaw-live-test:` для кожного вибраного commit. Live +release workflow один раз збирає й публікує цей image, потім Docker live model, +gateway, CLI backend, ACP bind і Codex harness шарди запускаються з +`OPENCLAW_SKIP_DOCKER_BUILD=1`. Якщо ці шарди незалежно перебудовують повну source Docker +ціль, release run налаштовано неправильно, і він марнуватиме wall clock на дубльовані image builds. `OpenClaw Release Checks` використовує trusted workflow ref, щоб один раз розв’язати вибраний -ref у tarball `release-package-under-test`, а потім передає цей artifact +ref у tarball `release-package-under-test`, потім передає цей artifact і live/E2E release-path Docker workflow, і package acceptance -shard. Це зберігає package bytes узгодженими між release boxes і уникає -повторного пакування того самого candidate у кількох child jobs. +шарду. Це зберігає package bytes узгодженими між release boxes і уникає +повторного пакування того самого candidate у кількох дочірніх завданнях. `Package Acceptance` — це side-run workflow для валідації package artifact -без блокування release workflow. Він розв’язує один candidate з -опублікованого npm spec, trusted `package_ref`, зібраного з вибраним +без блокування release workflow. Він розв’язує одного candidate з +published npm spec, trusted `package_ref`, зібраного з вибраним `workflow_ref` harness, HTTPS tarball URL із SHA-256 або tarball artifact -з іншого GitHub Actions run, завантажує його як `package-under-test`, а потім повторно використовує +з іншого GitHub Actions run, завантажує його як `package-under-test`, потім повторно використовує Docker release/E2E scheduler із цим tarball замість повторного пакування workflow checkout. Profiles покривають smoke, package, product, full і custom Docker lane selections. Profile `package` використовує offline plugin coverage, щоб -валідація published-package не залежала від live доступності ClawHub. Optional Telegram lane повторно використовує +published-package validation не залежала від live-доступності ClawHub. Опційний Telegram-напрям повторно використовує artifact `package-under-test` у workflow `NPM Telegram Beta E2E`, а -published npm spec path зберігається для standalone dispatches. +published npm spec path збережено для standalone dispatches. -## Приймання package +## Приймання пакета -Використовуйте `Package Acceptance`, коли питання звучить як "чи працює цей installable package OpenClaw -як product?" Це відрізняється від звичайної CI: звичайна CI перевіряє +Використовуйте `Package Acceptance`, коли питання звучить як «чи працює цей installable OpenClaw +package як product?» Він відрізняється від звичайного CI: звичайний CI перевіряє source tree, тоді як package acceptance перевіряє один tarball через той самий -Docker E2E harness, який користувачі запускають після встановлення або оновлення. +Docker E2E harness, який користувачі використовують після install або update. -Workflow має чотири jobs: +Workflow має чотири завдання: -1. `resolve_package` checkout-ить `workflow_ref`, розв’язує один package candidate, +1. `resolve_package` check out `workflow_ref`, розв’язує одного package candidate, записує `.artifacts/docker-e2e-package/openclaw-current.tgz`, записує `.artifacts/docker-e2e-package/package-candidate.json`, завантажує обидва як artifact `package-under-test` і друкує source, workflow ref, package @@ -106,78 +105,80 @@ Workflow має чотири jobs: `openclaw-live-and-e2e-checks-reusable.yml` з `ref=workflow_ref` і `package_artifact_name=package-under-test`. Reusable workflow завантажує цей artifact, перевіряє tarball inventory, готує package-digest - Docker images за потреби і запускає вибрані Docker lanes проти цього + Docker images за потреби й запускає вибрані Docker lanes проти цього package замість пакування workflow checkout. Коли profile вибирає кілька targeted `docker_lanes`, reusable workflow готує package - і shared images один раз, а потім розгортає ці lanes як parallel targeted Docker + і shared images один раз, потім розгортає ці lanes як паралельні targeted Docker jobs з унікальними artifacts. -3. `package_telegram` optionally викликає `NPM Telegram Beta E2E`. Він запускається, коли - `telegram_mode` не `none`, і встановлює той самий artifact `package-under-test`, - коли Package Acceptance розв’язав його; standalone Telegram dispatch +3. `package_telegram` опційно викликає `NPM Telegram Beta E2E`. Він запускається, коли + `telegram_mode` не є `none`, і встановлює той самий artifact `package-under-test`, + коли Package Acceptance розв’язав один; standalone Telegram dispatch усе ще може встановити published npm spec. -4. `summary` провалює workflow, якщо package resolution, Docker acceptance або - optional Telegram lane failed. +4. `summary` валить workflow, якщо package resolution, Docker acceptance або + опційний Telegram-напрям зазнали невдачі. -Candidate sources: +Джерела candidate: - `source=npm`: приймає лише `openclaw@beta`, `openclaw@latest` або точну - версію релізу OpenClaw, як-от `openclaw@2026.4.27-beta.2`. Використовуйте це для + release version OpenClaw, наприклад `openclaw@2026.4.27-beta.2`. Використовуйте це для published beta/stable acceptance. -- `source=ref`: пакує trusted `package_ref` branch, tag або full commit SHA. - Resolver fetch-ить branches/tags OpenClaw, перевіряє, що вибраний commit +- `source=ref`: пакує trusted `package_ref` branch, tag або повний commit SHA. + Resolver fetch-ить OpenClaw branches/tags, перевіряє, що вибраний commit reachable з repository branch history або release tag, встановлює deps у - detached worktree і пакує його за допомогою `scripts/package-openclaw-for-docker.mjs`. -- `source=url`: завантажує HTTPS `.tgz`; `package_sha256` required. + detached worktree і пакує його з `scripts/package-openclaw-for-docker.mjs`. +- `source=url`: завантажує HTTPS `.tgz`; `package_sha256` обов’язковий. - `source=artifact`: завантажує один `.tgz` з `artifact_run_id` і - `artifact_name`; `package_sha256` optional, але його варто надати для + `artifact_name`; `package_sha256` опційний, але його варто надати для externally shared artifacts. Тримайте `workflow_ref` і `package_ref` окремо. `workflow_ref` — це trusted -workflow/harness code, що запускає test. `package_ref` — це source commit, -який пакується, коли `source=ref`. Це дає змогу current test harness перевіряти -старіші trusted source commits без запуску old workflow logic. +workflow/harness code, який запускає test. `package_ref` — source commit, +який пакується, коли `source=ref`. Це дає змогу поточному test harness перевіряти +старіші trusted source commits без запуску старої workflow logic. -Profiles map to Docker coverage: +Profiles відповідають Docker coverage: - `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` plus `mcp-channels`, `cron-mcp-cleanup`, +- `product`: `package` плюс `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui` -- `full`: full Docker release-path chunks with OpenWebUI -- `custom`: exact `docker_lanes`; required when `suite_profile=custom` +- `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`. Release-path Docker -chunks покривають overlapping package/update/plugin lanes, тоді як Package +chunks покривають перетин package/update/plugin lanes, тоді як Package Acceptance зберігає artifact-native bundled-channel compat, offline plugin і -Telegram proof проти того самого resolved package tarball. +Telegram proof проти того самого розв’язаного package tarball. Cross-OS release checks усе ще покривають OS-specific onboarding, installer і platform behavior; package/update product validation має починатися з Package Acceptance. Windows packaged і installer fresh lanes також перевіряють, що -installed package може імпортувати browser-control override з raw absolute +installed package може import browser-control override з raw absolute Windows path. OpenAI cross-OS agent-turn smoke за замовчуванням використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли встановлено, інакше `openai/gpt-5.4-mini`, щоб -install і Gateway proof залишалися швидкими й детермінованими. Dedicated live +install і gateway proof залишалися швидкими й deterministic. Dedicated live provider/model lanes усе ще покривають ширший model routing, включно з повільнішими frontier defaults. -Package Acceptance має bounded legacy-compatibility windows для вже -published packages. Packages through `2026.4.25`, including `2026.4.25-beta.*`, -may use the compatibility path for known private QA entries in -`dist/postinstall-inventory.json` that point at tarball-omitted files, -`doctor-switch` may skip the `gateway install --wrapper` persistence subcase -when the package does not expose that flag, `update-channel-switch` may prune -missing `pnpm.patchedDependencies` from the tarball-derived fake git fixture and -may log missing persisted `update.channel`, plugin smokes may read legacy -install-record locations or accept missing marketplace install-record -persistence, and `plugin-update` may allow config metadata migration while still -requiring the install record and no-reinstall behavior to stay unchanged. Later packages must satisfy the modern contracts; the -same conditions fail instead of warn or skip. +Package Acceptance має обмежені вікна legacy-compatibility для вже +published packages. Packages до `2026.4.25` включно, включно з `2026.4.25-beta.*`, +можуть використовувати compatibility path для відомих private QA entries у +`dist/postinstall-inventory.json`, які вказують на файли, omitted з tarball, +`doctor-switch` може пропускати subcase з persistence `gateway install --wrapper`, +коли package не expose-ить цей flag, `update-channel-switch` може prune +відсутні `pnpm.patchedDependencies` із tarball-derived fake git fixture і +може логувати відсутній persisted `update.channel`, plugin smokes можуть читати legacy +install-record locations або приймати відсутню marketplace install-record +persistence, а `plugin-update` може дозволяти migration config metadata, усе ще +вимагаючи, щоб install record і no-reinstall behavior залишалися unchanged. Published +package `2026.4.26` також може warning для local build metadata stamp files, +які вже були shipped. Пізніші packages мають задовольняти modern contracts; ті самі +умови fail замість warn або skip. Приклади: @@ -220,99 +221,23 @@ gh workflow run package-acceptance.yml \ -f docker_lanes='install-e2e plugin-update' ``` -Під час налагодження невдалого запуску package acceptance починайте зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його Docker-артефакти: -`.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lane, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lanes замість повторного запуску повної валідації релізу. +Під час налагодження невдалого запуску перевірки прийнятності пакета почніть зі зведення `resolve_package`, щоб підтвердити джерело пакета, версію та SHA-256. Потім перевірте дочірній запуск `docker_acceptance` і його артефакти Docker: `.artifacts/docker-tests/**/summary.json`, `failures.json`, журнали lane, таймінги фаз і команди повторного запуску. Надавайте перевагу повторному запуску невдалого профілю пакета або точних Docker lane замість повторного запуску повної перевірки релізу. -QA Lab має окремі CI lanes поза основним smart-scoped workflow. Workflow `Parity gate` запускається для відповідних змін у PR і через manual dispatch; він збирає приватний QA runtime і порівнює agentic packs mock GPT-5.5 та Opus 4.6. Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і через manual dispatch; він розгортає mock parity gate, live Matrix lane, а також live Telegram і Discord lanes як паралельні jobs. Live jobs використовують середовище `qa-live-shared`, а Telegram/Discord використовують Convex leases. Release checks запускають Matrix і Telegram live transport lanes з детермінованим mock provider і mock-qualified models (`mock-openai/gpt-5.5` та -`mock-openai/gpt-5.5-alt`), щоб contract каналу був ізольований від затримки live model і звичайного запуску provider-Plugin. Live transport gateway також вимикає memory search, оскільки QA parity окремо покриває поведінку пам’яті; -provider connectivity покривається окремими наборами live model, native provider і Docker provider. Matrix використовує `--profile fast` для scheduled і release gates, -додаючи `--fail-fast` лише коли checked-out CLI це підтримує. Значення CLI за замовчуванням і manual workflow input залишаються `all`; manual `matrix_profile=all` -dispatch завжди шардує повне покриття Matrix у jobs `transport`, `media`, -`e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` також запускає критичні для релізу QA Lab lanes перед схваленням релізу; його QA parity -gate запускає candidate і baseline packs як паралельні lane jobs, а потім завантажує обидва артефакти в невеликий report job для фінального порівняння parity. -Не ставте шлях landing PR за `Parity gate`, якщо зміна справді не зачіпає QA runtime, model-pack parity або поверхню, якою володіє parity workflow. -Для звичайних виправлень каналів, конфігурації, документації або unit tests розглядайте це як опційний сигнал і дотримуйтеся scoped CI/check evidence. +QA Lab має окремі lane CI поза основним workflow зі смарт-обмеженням області. Workflow `Parity gate` запускається для відповідних змін у PR і вручну; він збирає приватний runtime QA та порівнює агентні пакети mock GPT-5.5 і Opus 4.6. Workflow `QA-Lab - All Lanes` запускається щоночі на `main` і вручну; він розгалужує mock parity gate, live Matrix lane, а також live lane Telegram і Discord як паралельні завдання. Live-завдання використовують середовище `qa-live-shared`, а Telegram/Discord використовують оренди Convex. Перевірки релізу запускають live transport lane Matrix і Telegram з детермінованим mock-провайдером і моделями, кваліфікованими як mock (`mock-openai/gpt-5.5` і `mock-openai/gpt-5.5-alt`), щоб контракт каналу був ізольований від затримок live-моделей і звичайного запуску provider-Plugin. Live transport gateway також вимикає пошук пам’яті, бо QA parity окремо покриває поведінку пам’яті; підключення provider покривається окремими наборами live model, native provider і Docker provider. Matrix використовує `--profile fast` для запланованих і релізних gates, додаючи `--fail-fast` лише коли checked-out CLI це підтримує. Значення CLI за замовчуванням і ручний ввід workflow залишаються `all`; ручний запуск `matrix_profile=all` завжди шардує повне покриття Matrix на завдання `transport`, `media`, `e2ee-smoke`, `e2ee-deep` і `e2ee-cli`. `OpenClaw Release Checks` також запускає критичні для релізу lane QA Lab перед схваленням релізу; його QA parity gate запускає candidate і baseline packs як паралельні lane-завдання, а потім завантажує обидва артефакти в невелике report-завдання для фінального порівняння parity. Не ставте шлях landing PR за `Parity gate`, якщо зміна фактично не зачіпає runtime QA, parity model-pack або поверхню, якою володіє parity workflow. Для звичайних виправлень каналів, config, docs або unit-test вважайте це необов’язковим сигналом і спирайтеся на evidence зі scoped CI/check. -Workflow `Duplicate PRs After Merge` є manual maintainer workflow для очищення дублікатів після landing. За замовчуванням він працює в dry-run і закриває лише явно перелічені PRs, коли `apply=true`. Перед зміною GitHub він перевіряє, що landed PR змерджено і що кожен дублікат має або спільне referenced issue, або перетин changed hunks. +Workflow `Duplicate PRs After Merge` — це ручний maintainer workflow для очищення дублікатів після landing. За замовчуванням він працює як dry-run і закриває лише явно перелічені PR, коли `apply=true`. Перед змінами в GitHub він перевіряє, що landed PR змерджено і що кожен дублікат має або спільну referenced issue, або перекриття змінених hunk. -Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, -а не повним скануванням репозиторію. Daily і manual runs сканують Actions workflow code -та найризикованіші JavaScript/TypeScript поверхні auth, secrets, sandbox, cron і gateway за допомогою high-precision security queries. Job -channel-runtime-boundary окремо сканує core channel implementation -contracts, а також channel Plugin runtime, gateway, Plugin SDK, secrets і -audit touchpoints у категорії `/codeql-critical-security/channel-runtime-boundary`, -щоб сигнал безпеки каналів міг масштабуватися без розширення базової категорії -JS/TS. +Workflow `CodeQL` навмисно є вузьким security scanner першого проходу, а не повним sweep репозиторію. Щоденні та ручні запуски сканують код Actions workflow плюс найризиковіші JavaScript/TypeScript поверхні auth, secrets, sandbox, Cron і gateway за допомогою high-precision security queries. Завдання channel-runtime-boundary окремо сканує контракти реалізації основних каналів плюс runtime channel Plugin, gateway, Plugin SDK, secrets і audit touchpoints у категорії `/codeql-critical-security/channel-runtime-boundary`, щоб security signal каналів міг масштабуватися без розширення baseline категорії JS/TS. -Workflow `CodeQL Android Critical Security` є scheduled Android -security shard. Він вручну збирає Android app для CodeQL на найменшому -Blacksmith Linux runner label, який приймає workflow sanity, і завантажує результати -в категорію `/codeql-critical-security/android`. +Workflow `CodeQL Android Critical Security` — це запланований Android security shard. Він вручну збирає Android app для CodeQL на найменшому Blacksmith Linux runner label, прийнятому workflow sanity, і завантажує результати в категорії `/codeql-critical-security/android`. -Workflow `CodeQL macOS Critical Security` є weekly/manual macOS -security shard. Він вручну збирає macOS app для CodeQL на Blacksmith macOS, -відфільтровує dependency build results із завантаженого SARIF і завантажує результати -в категорію `/codeql-critical-security/macos`. Тримайте його поза daily -default workflow, оскільки macOS build домінує runtime навіть коли все чисто. +Workflow `CodeQL macOS Critical Security` — це щотижневий/ручний macOS security shard. Він вручну збирає macOS app для CodeQL на Blacksmith macOS, відфільтровує результати dependency build із завантаженого SARIF і завантажує результати в категорії `/codeql-critical-security/macos`. Тримайте його поза щоденним workflow за замовчуванням, бо macOS build домінує runtime навіть коли чистий. -Workflow `CodeQL Critical Quality` є відповідним non-security shard. Він -запускає лише error-severity, non-security JavaScript/TypeScript quality queries -на вузьких високовартісних поверхнях на меншому Blacksmith Linux runner. Його -job core-auth-secrets сканує auth, secrets, sandbox, cron і gateway security -boundary code в окремій категорії `/codeql-critical-quality/core-auth-secrets`. -Job config-boundary -сканує config schema, migration, normalization та IO contracts в окремій -категорії `/codeql-critical-quality/config-boundary`. Job -gateway-runtime-boundary сканує gateway protocol schemas і server method -contracts в окремій -категорії `/codeql-critical-quality/gateway-runtime-boundary`. Job -channel-runtime-boundary сканує core channel implementation contracts в -окремій категорії `/codeql-critical-quality/channel-runtime-boundary`. Job -agent-runtime-boundary сканує command execution, model/provider dispatch, -auto-reply dispatch і queues, а також ACP control-plane runtime contracts в -окремій категорії `/codeql-critical-quality/agent-runtime-boundary`. Job -mcp-process-runtime-boundary сканує MCP servers і tool bridges, process -supervision helpers та outbound delivery contracts в окремій -категорії `/codeql-critical-quality/mcp-process-runtime-boundary`. Job -memory-runtime-boundary сканує memory host SDK, memory runtime facades, -memory Plugin SDK aliases, memory runtime activation glue і memory doctor -commands в окремій категорії `/codeql-critical-quality/memory-runtime-boundary`. -Job -ui-control-plane сканує Control UI bootstrap, local persistence, gateway -control flows і task control-plane runtime contracts в окремій -категорії `/codeql-critical-quality/ui-control-plane`. Job -web-media-runtime-boundary сканує core web fetch/search, media IO, media -understanding, image-generation і media-generation runtime contracts в -окремій категорії `/codeql-critical-quality/web-media-runtime-boundary`. Job -plugin-boundary сканує loader, registry, public-surface і Plugin SDK -entrypoint contracts в окремій категорії `/codeql-critical-quality/plugin-boundary`. -Тримайте workflow окремо від security, щоб quality findings можна було -планувати, вимірювати, вимикати або розширювати без затемнення security signal. -Розширення CodeQL для Swift, Python і bundled-Plugin слід додавати назад як -scoped або sharded follow-up work лише після того, як вузькі profiles матимуть стабільні -runtime і signal. +Workflow `CodeQL Critical Quality` — це відповідний non-security shard. Він запускає лише JavaScript/TypeScript quality queries із severity error і non-security над вузькими high-value поверхнями на меншому Blacksmith Linux runner. Його завдання core-auth-secrets сканує код security boundary для auth, secrets, sandbox, Cron і gateway в окремій категорії `/codeql-critical-quality/core-auth-secrets`. Завдання 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 і queues, а також ACP control-plane runtime contracts в окремій категорії `/codeql-critical-quality/agent-runtime-boundary`. Завдання mcp-process-runtime-boundary сканує MCP servers і tool bridges, process supervision helpers та outbound delivery contracts в окремій категорії `/codeql-critical-quality/mcp-process-runtime-boundary`. Завдання memory-runtime-boundary сканує memory host SDK, memory runtime facades, memory Plugin SDK aliases, memory runtime activation glue і memory doctor commands в окремій категорії `/codeql-critical-quality/memory-runtime-boundary`. Завдання ui-control-plane сканує Control UI bootstrap, local persistence, gateway control flows і task control-plane runtime contracts в окремій категорії `/codeql-critical-quality/ui-control-plane`. Завдання web-media-runtime-boundary сканує core web fetch/search, media IO, media understanding, image-generation і media-generation runtime contracts в окремій категорії `/codeql-critical-quality/web-media-runtime-boundary`. Завдання plugin-boundary сканує loader, registry, public-surface і Plugin SDK entrypoint contracts в окремій категорії `/codeql-critical-quality/plugin-boundary`. Завдання plugin-sdk-package-contract сканує опубліковане package-side джерело Plugin SDK і plugin package contract helpers в окремій категорії `/codeql-critical-quality/plugin-sdk-package-contract`. Тримайте workflow окремо від security, щоб quality findings можна було планувати, вимірювати, вимикати або розширювати без розмивання security signal. Розширення CodeQL для Swift, Python і bundled-plugin слід додати назад як scoped або sharded follow-up work лише після того, як вузькі профілі матимуть стабільний runtime і signal. -Workflow `Docs Agent` є event-driven Codex maintenance lane для підтримання -наявної документації узгодженою з нещодавно landed changes. Він не має чистого schedule: успішний non-bot push CI run на `main` може його запустити, а manual dispatch може -запустити його безпосередньо. Workflow-run invocations пропускаються, коли `main` уже просунувся далі або коли -інший non-skipped Docs Agent run було створено протягом останньої години. Коли він запускається, він -переглядає commit range від попереднього non-skipped Docs Agent source SHA до -поточного `main`, тож один hourly run може покрити всі main changes, накопичені після -останнього docs pass. +Workflow `Docs Agent` — це event-driven Codex maintenance lane для підтримання наявної docs у відповідності з нещодавно landed changes. Він не має чистого розкладу: успішний non-bot push CI run на `main` може його запустити, а ручний dispatch може запустити його напряму. Workflow-run invocations пропускаються, коли `main` уже змістився або коли інший non-skipped Docs Agent run було створено за останню годину. Коли він запускається, він переглядає діапазон commit від попереднього non-skipped Docs Agent source SHA до поточного `main`, тож один погодинний запуск може покрити всі зміни main, накопичені з останнього проходу docs. -Workflow `Test Performance Agent` є event-driven Codex maintenance lane -для повільних tests. Він не має чистого schedule: успішний non-bot push CI run на -`main` може його запустити, але він пропускається, якщо інша workflow-run invocation уже -запускалася або виконується цього UTC day. Manual dispatch обходить цей daily activity -gate. Lane будує full-suite grouped Vitest performance report, дозволяє Codex -робити лише невеликі coverage-preserving test performance fixes замість широких -refactors, потім повторно запускає full-suite report і відхиляє зміни, які зменшують -passing baseline test count. Якщо baseline має failing tests, Codex може виправляти -лише очевидні failures, а after-agent full-suite report має пройти перед -будь-яким commit. Коли `main` просувається до того, як bot push потрапить у репозиторій, lane -rebase-ить validated patch, повторно запускає `pnpm check:changed` і повторює push; -conflicting stale patches пропускаються. Він використовує GitHub-hosted Ubuntu, щоб Codex -action міг зберегти таку саму drop-sudo safety posture, як docs agent. +Workflow `Test Performance Agent` — це event-driven Codex maintenance lane для повільних тестів. Він не має чистого розкладу: успішний non-bot push CI run на `main` може його запустити, але він пропускається, якщо інша workflow-run invocation уже запускалася або виконується цього UTC-дня. Ручний dispatch обходить цей daily activity gate. Lane будує grouped Vitest performance report для full-suite, дозволяє Codex вносити лише невеликі coverage-preserving test performance fixes замість широких refactors, потім повторно запускає full-suite report і відхиляє зміни, які зменшують baseline count прохідних тестів. Якщо baseline має failing tests, Codex може виправляти лише очевидні failures, а after-agent full-suite report має пройти перед тим, як щось буде закомічено. Коли `main` просувається до landing bot push, lane rebase validated 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 \ @@ -321,46 +246,46 @@ gh workflow run duplicate-after-merge.yml \ -f apply=true ``` -## Огляд jobs +## Огляд завдань -| Завдання | Призначення | Коли запускається | +| Завдання | Призначення | Коли виконується | | -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- | -| `preflight` | Виявляє зміни лише в документації, змінені області, змінені розширення та збирає CI-маніфест | Завжди для нечернеткових push і PR | -| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для нечернеткових push і PR | -| `security-dependency-audit` | Аудит production lockfile без залежностей за advisories npm | Завжди для нечернеткових push і PR | -| `security-fast` | Обов'язковий агрегат для швидких завдань безпеки | Завжди для нечернеткових push і PR | -| `build-artifacts` | Збирає `dist/`, Control UI, перевірки зібраних артефактів і повторно використовувані downstream-артефакти | Зміни, релевантні для Node | -| `checks-fast-core` | Швидкі Linux-лінії коректності, як-от перевірки bundled/Plugin-contract/protocol | Зміни, релевантні для Node | -| `checks-fast-contracts-channels` | Шардовані перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node | -| `checks-node-core-test` | Шарди тестів core Node, крім ліній каналів, bundled, контрактів і розширень | Зміни, релевантні для Node | -| `check` | Шардований еквівалент головного локального gate: prod-типи, lint, guards, test types і strict smoke | Зміни, релевантні для Node | -| `check-additional` | Архітектура, межі, guards поверхні розширень, package-boundary і шарди gateway-watch | Зміни, релевантні для Node | -| `build-smoke` | Smoke-тести зібраного CLI і smoke startup-memory | Зміни, релевантні для Node | -| `checks` | Верифікатор для тестів каналів зібраних артефактів | Зміни, релевантні для Node | -| `checks-node-compat-node22` | Лінія збірки й smoke для сумісності з Node 22 | Ручний запуск CI для релізів | -| `check-docs` | Перевірки форматування документації, lint і broken-link | Змінено документацію | -| `skills-python` | Ruff + pytest для Skills на базі Python | Зміни, релевантні для Python-Skills | -| `checks-windows` | Специфічні для Windows тести процесів/шляхів плюс спільні регресії runtime import specifier | Зміни, релевантні для Windows | -| `macos-node` | Лінія тестів TypeScript для macOS із використанням спільних зібраних артефактів | Зміни, релевантні для macOS | -| `macos-swift` | Swift lint, збірка й тести для застосунку macOS | Зміни, релевантні для macOS | -| `android` | Unit-тести Android для обох flavor плюс одна debug APK-збірка | Зміни, релевантні для Android | -| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успішний main CI або ручний запуск | +| `preflight` | Виявляє зміни лише в документації, змінені області, змінені plugins і створює CI-маніфест | Завжди для недрафтових push і PR | +| `security-scm-fast` | Виявлення приватних ключів і аудит workflow через `zizmor` | Завжди для недрафтових push і PR | +| `security-dependency-audit` | Аудит production lockfile без залежностей за npm advisories | Завжди для недрафтових push і PR | +| `security-fast` | Обов’язковий агрегат для швидких security-завдань | Завжди для недрафтових push і PR | +| `build-artifacts` | Збірка `dist/`, Control UI, перевірки зібраних артефактів і reusable downstream artifacts | Зміни, релевантні для Node | +| `checks-fast-core` | Швидкі Linux-ланцюжки коректності, як-от bundled/plugin-contract/protocol checks | Зміни, релевантні для Node | +| `checks-fast-contracts-channels` | Sharded перевірки контрактів каналів зі стабільним агрегованим результатом перевірки | Зміни, релевантні для Node | +| `checks-node-core-test` | Shards тестів Core Node, за винятком 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` | Верифікатор для built-artifact channel tests | Зміни, релевантні для Node | +| `checks-node-compat-node22` | Збірка сумісності з Node 22 і smoke lane | Ручний запуск CI для релізів | +| `check-docs` | Форматування документації, lint і перевірки broken links | Документацію змінено | +| `skills-python` | Ruff + pytest для Python-backed skills | Зміни, релевантні для Python skills | +| `checks-windows` | Windows-specific process/path tests плюс regressions shared runtime import specifier | Зміни, релевантні для Windows | +| `macos-node` | macOS TypeScript test lane із використанням спільних built artifacts | Зміни, релевантні для macOS | +| `macos-swift` | Swift lint, build і tests для macOS app | Зміни, релевантні для macOS | +| `android` | Android unit tests для обох flavors плюс одна debug APK build | Зміни, релевантні для Android | +| `test-performance-agent` | Щоденна оптимізація повільних тестів Codex після довіреної активності | Успіх Main CI або ручний запуск | -Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожну -область не для Android: шарди Linux Node, шарди bundled-Plugin, контракти каналів, -сумісність Node 22, `check`, `check-additional`, build smoke, перевірки документації, -Python Skills, Windows, macOS та i18n Control UI. Окремі ручні запуски CI -виконують лише Android із `include_android=true`; повна release umbrella -вмикає Android, передаючи `include_android=true`. Статичні перевірки prerelease для Plugin, -релізний шард `agentic-plugins`, повний пакетний sweep розширень -і Docker-лінії prerelease для Plugin виключено з CI. Docker-набір prerelease -запускається лише тоді, коли `Full Release Validation` запускає -окремий workflow `Plugin Prerelease` із увімкненим gate release-validation. +Ручні запуски CI виконують той самий граф завдань, що й звичайний CI, але примусово вмикають кожен +scoped lane, не пов’язаний з Android: Linux Node shards, bundled-plugin shards, channel +contracts, сумісність із Node 22, `check`, `check-additional`, build smoke, перевірки документації, +Python skills, Windows, macOS і Control UI i18n. Окремі ручні запуски CI +виконують лише Android з `include_android=true`; повний release +umbrella вмикає Android, передаючи `include_android=true`. Статичні перевірки prerelease для Plugin, +release-only shard `agentic-plugins`, повний batch sweep для extensions +і Docker lanes для prerelease Plugin виключено з CI. Набір Docker +prerelease виконується лише тоді, коли `Full Release Validation` запускає +окремий workflow `Plugin Prerelease` з увімкненим gate release-validation. Ручні запуски використовують -унікальну concurrency group, щоб повний набір release-candidate не було скасовано -іншим push або PR-запуском на тому самому ref. Необов'язковий input `target_ref` дає -довіреному caller змогу запускати цей граф для branch, tag або повного commit SHA, -використовуючи workflow-файл з вибраного dispatch ref. +унікальну concurrency group, щоб повний набір release-candidate не скасовувався +іншим push або PR run на тому самому ref. Необов’язковий input `target_ref` дає +довіреному виклику змогу запустити цей граф для branch, tag або повного commit SHA, водночас +використовуючи workflow file з вибраного dispatch ref. ```bash gh workflow run ci.yml --ref release/YYYY.M.D @@ -370,68 +295,56 @@ 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` швидко падають, не чекаючи на важчі matrix-завдання артефактів і платформ. -3. `build-artifacts` перекривається зі швидкими Linux-лініями, щоб downstream-споживачі могли стартувати, щойно спільна збірка буде готова. -4. Після цього розгортаються важчі лінії платформ і runtime: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. +1. `preflight` вирішує, які lanes взагалі існують. Логіка `docs-scope` і `changed-scope` є кроками всередині цього завдання, а не окремими завданнями. +2. `security-scm-fast`, `security-dependency-audit`, `security-fast`, `check`, `check-additional`, `check-docs` і `skills-python` швидко завершуються з помилкою, не чекаючи на важчі завдання artifact і platform matrix. +3. `build-artifacts` виконується паралельно зі швидкими Linux lanes, щоб downstream consumers могли стартувати щойно спільна збірка буде готова. +4. Після цього розгортаються важчі platform і runtime lanes: `checks-fast-core`, `checks-fast-contracts-channels`, `checks-node-core-test`, `checks`, `checks-windows`, `macos-node`, `macos-swift` і `android`. -Логіка області дії міститься в `scripts/ci-changed-scope.mjs` і покрита модульними тестами в `src/scripts/ci-changed-scope.test.ts`. -Ручний запуск пропускає визначення changed-scope і змушує передпольотний маніфест -працювати так, ніби змінилася кожна область із визначеною областю дії. -Зміни CI workflow перевіряють граф Node CI та лінтинг workflow, але самі по собі не примушують запускати нативні збірки Windows, Android або macOS; ці платформні лінії залишаються прив’язаними до змін платформного вихідного коду. -Редагування, що стосуються лише маршрутизації CI, вибрані дешеві зміни фікстур core-тестів, а також вузькі зміни допоміжних засобів/маршрутизації тестів контракту plugin використовують швидкий шлях маніфесту лише для Node: передпольотна перевірка, безпека й один task `checks-fast-core`. Цей шлях уникає артефактів збірки, сумісності з Node 22, контрактів каналів, повних шардів core, шардів bundled-plugin і додаткових матриць захисту, коли змінені файли обмежені поверхнями маршрутизації або допоміжними поверхнями, які швидкий task перевіряє напряму. -Перевірки Windows Node обмежені специфічними для Windows обгортками процесів/шляхів, допоміжними засобами запуску npm/pnpm/UI, конфігурацією менеджера пакетів і поверхнями CI workflow, які виконують цю лінію; не пов’язані зміни вихідного коду, plugin, install-smoke і зміни лише тестів залишаються на лініях Linux Node, щоб вони не резервували 16-vCPU Windows worker для покриття, яке вже перевіряється звичайними тестовими шардами. -Окремий workflow `install-smoke` повторно використовує той самий scope script через власний job `preflight`. Він розділяє smoke-покриття на `run_fast_install_smoke` і `run_full_install_smoke`. Pull requests запускають швидкий шлях для поверхонь Docker/package, змін package/manifest bundled plugin, а також поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише вихідного коду bundled plugin, редагування лише тестів і редагування лише документації не резервують Docker workers. Швидкий шлях один раз збирає образ кореневого Dockerfile, перевіряє CLI, запускає CLI smoke для agents delete shared-workspace, запускає container gateway-network e2e, перевіряє build arg bundled extension і запускає обмежений Docker-профіль bundled-plugin із сукупним тайм-аутом команди 240 секунд, де Docker run кожного сценарію обмежено окремо. Повний шлях зберігає інсталяцію QR package і Docker/update-покриття інсталятора для нічних запланованих запусків, ручних запусків, workflow-call release checks і pull requests, які справді зачіпають поверхні installer/package/Docker. Пуші в `main`, зокрема merge commits, не примушують повний шлях; коли логіка changed-scope запитала б повне покриття на push, workflow залишає швидкий Docker smoke і передає повний install smoke нічній або release-валідації. Повільний Bun global install image-provider smoke окремо керується через `run_bun_global_install_smoke`; він запускається за нічним розкладом і з release checks workflow, а ручні запуски `install-smoke` можуть увімкнути його опційно, але pull requests і пуші в `main` його не запускають. QR і installer Docker tests зберігають власні Dockerfiles, зосереджені на інсталяції. Локальний `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-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 і багатосервісні лінії не перевантажували Docker, тоді як легші лінії все ще заповнюють доступні слоти. Одна лінія, важча за ефективні обмеження, все одно може стартувати з порожнього пулу, а потім виконується сама, доки не звільнить місткість. Старти ліній за замовчуванням зміщені на 2 секунди, щоб уникнути локальних піків створення в Docker daemon; перевизначте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Локальний сукупний запуск виконує передпольотну перевірку 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=` запускає точні лінії планувальника, зокрема release-only lanes на кшталт `install-e2e` і розділені bundled update lanes на кшталт `bundled-channel-update-acpx`, пропускаючи cleanup smoke, щоб agents могли відтворити одну невдалу лінію. Багаторазовий live/E2E workflow запитує `scripts/test-docker-all.mjs --plan-json`, яке покриття package, image kind, live image, lane і credentials потрібне, а потім `scripts/docker-e2e.mjs` перетворює цей план на GitHub outputs і summaries. Він або пакує OpenClaw через `scripts/package-openclaw-for-docker.mjs`, завантажує package artifact поточного запуску, або завантажує package artifact із `package_artifact_run_id`; перевіряє інвентар tarball; збирає й публікує package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли плану потрібні package-installed lanes; і повторно використовує передані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або наявні package-digest images замість перебудови. Завантаження Docker image повторюються з обмеженим 180-секундним тайм-аутом на спробу, щоб завислий registry/cache stream швидко повторювався замість того, щоб споживати більшу частину критичного шляху CI. Workflow `Package Acceptance` є високорівневим package gate: він визначає кандидата з npm, довіреного `package_ref`, HTTPS tarball плюс SHA-256 або артефакту попереднього workflow, а потім передає цей єдиний artifact `package-under-test` у багаторазовий Docker E2E workflow. Він тримає `workflow_ref` окремо від `package_ref`, щоб поточна логіка acceptance могла перевіряти старіші довірені commits без checkout старого workflow code. Release checks запускають власну дельту Package Acceptance для цільового ref: сумісність bundled-channel, offline plugin fixtures і Telegram package QA проти визначеного tarball. Docker suite release-path запускає менші розбиті jobs із `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk завантажував лише потрібний image kind і виконував кілька ліній через той самий зважений планувальник (`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|plugins-runtime-install-e|plugins-runtime-install-f|plugins-runtime-install-g|plugins-runtime-install-h|bundled-channels`). OpenWebUI включається в `plugins-runtime-services`, коли повне release-path-покриття його запитує, і зберігає окремий chunk `openwebui` лише для dispatches, що стосуються тільки OpenWebUI. Застарілі агреговані назви chunks `package-update`, `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` усе ще працюють для ручних повторних запусків, але release workflow використовує розділені chunks, щоб installer E2E і перевірки install/uninstall bundled plugin не домінували критичний шлях. Alias лінії `install-e2e` залишається агрегованим alias для ручного повторного запуску обох provider installer lanes. Chunk `bundled-channels` запускає розділені лінії `bundled-channel-*` і `bundled-channel-update-*`, а не послідовну all-in-one лінію `bundled-channel-deps`. Кожен chunk завантажує `.artifacts/docker-tests/` з logs ліній, timings, `summary.json`, `failures.json`, phase timings, scheduler plan JSON, slow-lane tables і командами повторного запуску для кожної лінії. Input workflow `docker_lanes` запускає вибрані лінії проти підготовлених образів замість chunk jobs, що обмежує debugging невдалої лінії одним цільовим Docker job і готує, завантажує або повторно використовує package artifact для цього запуску; якщо вибрана лінія є live Docker lane, цільовий job локально збирає live-test image для цього повторного запуску. Згенеровані команди GitHub для повторного запуску кожної лінії містять `package_artifact_run_id`, `package_artifact_name` і inputs підготовлених образів, коли такі значення існують, тож невдала лінія може повторно використати точний package і images з невдалого запуску. Використовуйте `pnpm test:docker:rerun `, щоб завантажити Docker artifacts із GitHub run і вивести комбіновані/цільові команди повторного запуску для кожної лінії; використовуйте `pnpm test:docker:timings ` для підсумків slow-lane і phase critical-path. Запланований live/E2E workflow щодня запускає повний release-path Docker suite. Матриця bundled update розділена за ціллю оновлення, щоб повторні npm update і doctor repair passes могли шардитися з іншими bundled checks. +Логіка області живе в `scripts/ci-changed-scope.mjs` і покрита модульними тестами в `src/scripts/ci-changed-scope.test.ts`. +Ручний запуск пропускає виявлення зміненої області й змушує preflight-маніфест +діяти так, ніби змінилася кожна область із визначеним scope. +Редагування CI workflow перевіряють граф Node CI плюс linting workflow, але самі по собі не примушують запускати нативні збірки Windows, Android або macOS; ці платформні lanes залишаються прив’язаними до змін платформного вихідного коду. +Редагування, що стосуються лише маршрутизації CI, вибрані дешеві редагування core-test fixtures і вузькі редагування helper/test-routing для контрактів плагінів використовують швидкий Node-only шлях маніфесту: preflight, security і одне завдання `checks-fast-core`. Цей шлях уникає build artifacts, сумісності з Node 22, контрактів каналів, повних core shards, bundled-plugin shards і додаткових guard matrices, коли змінені файли обмежені поверхнями маршрутизації або helper, які швидке завдання перевіряє безпосередньо. +Windows Node checks обмежені специфічними для Windows wrappers процесів/шляхів, npm/pnpm/UI runner helpers, конфігурацією package manager і поверхнями CI workflow, які виконують цю lane; непов’язані зміни source, plugin, install-smoke і test-only залишаються на Linux Node lanes, щоб вони не резервували 16-vCPU Windows worker для покриття, яке вже перевіряється звичайними test shards. +Окремий workflow `install-smoke` повторно використовує той самий scope script через власне завдання `preflight`. Він розділяє smoke coverage на `run_fast_install_smoke` і `run_full_install_smoke`. Pull requests запускають fast path для Docker/package surfaces, змін package/manifest вбудованих плагінів і поверхонь core plugin/channel/gateway/Plugin SDK, які перевіряють Docker smoke jobs. Зміни лише у вихідному коді вбудованих плагінів, test-only edits і docs-only edits не резервують Docker workers. Fast path один раз збирає root Dockerfile image, перевіряє CLI, запускає agents delete shared-workspace CLI smoke, запускає container gateway-network e2e, перевіряє build arg вбудованого розширення і запускає bounded bundled-plugin Docker profile під 240-секундним aggregate command timeout, причому Docker run для кожного scenario обмежений окремо. Full path зберігає QR package install і installer Docker/update coverage для nightly scheduled runs, manual dispatches, workflow-call release checks і pull requests, які справді зачіпають installer/package/Docker surfaces. `main` pushes, зокрема merge commits, не примушують full path; коли changed-scope logic запитала б full coverage на push, workflow зберігає fast Docker smoke і залишає full install smoke для nightly або release validation. Повільний Bun global install image-provider smoke окремо gated через `run_bun_global_install_smoke`; він запускається за nightly schedule і з release checks workflow, а manual `install-smoke` dispatches можуть opt into it, але pull requests і `main` pushes його не запускають. QR і installer Docker tests зберігають власні install-focused Dockerfiles. Локальний `test:docker:all` prebuilds один shared live-test image, один раз пакує OpenClaw як npm tarball і збирає два shared `scripts/e2e/Dockerfile` images: bare Node/Git runner для installer/update/plugin-dependency lanes і functional image, який installs той самий tarball у `/app` для normal functionality lanes. Визначення Docker lanes живуть у `scripts/lib/docker-e2e-scenarios.mjs`, planner logic живе в `scripts/lib/docker-e2e-plan.mjs`, а runner виконує лише вибраний plan. Scheduler вибирає image для кожної lane через `OPENCLAW_DOCKER_E2E_BARE_IMAGE` і `OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`, потім запускає lanes з `OPENCLAW_SKIP_DOCKER_BUILD=1`; налаштуйте default main-pool slot count 10 через `OPENCLAW_DOCKER_ALL_PARALLELISM` і provider-sensitive tail-pool slot count 10 через `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM`. Heavy lane caps за замовчуванням дорівнюють `OPENCLAW_DOCKER_ALL_LIVE_LIMIT=9`, `OPENCLAW_DOCKER_ALL_NPM_LIMIT=10` і `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT=7`, щоб npm install і multi-service lanes не overcommit Docker, поки lighter lanes все ще заповнюють доступні slots. Одна lane, важча за effective caps, все одно може стартувати з empty pool, а потім виконується самостійно, доки не звільнить capacity. Lane starts за замовчуванням рознесені на 2 секунди, щоб уникнути local Docker daemon create storms; перевизначте через `OPENCLAW_DOCKER_ALL_START_STAGGER_MS=0` або інше значення в мілісекундах. Local aggregate preflights Docker, removes stale OpenClaw E2E containers, emits active-lane status, persists lane timings для longest-first ordering і підтримує `OPENCLAW_DOCKER_ALL_DRY_RUN=1` для scheduler inspection. Він припиняє планувати new pooled lanes після першого failure за замовчуванням, і кожна lane має 120-minute fallback timeout, overrideable через `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS`; selected live/tail lanes використовують tighter 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`, downloads current-run package artifact, або downloads package artifact з `package_artifact_run_id`; validates tarball inventory; builds and pushes package-digest-tagged bare/functional GHCR Docker E2E images через Docker layer cache Blacksmith, коли plan needs package-installed lanes; і повторно використовує надані inputs `docker_e2e_bare_image`/`docker_e2e_functional_image` або existing package-digest images замість rebuild. Docker image pulls retries with a bounded 180-second per-attempt timeout, щоб stuck registry/cache stream швидко retry, а не споживав більшу частину CI critical path. Workflow `Package Acceptance` є high-level package gate: він resolves candidate з npm, trusted `package_ref`, HTTPS tarball plus SHA-256 або prior workflow artifact, а потім передає цей єдиний artifact `package-under-test` у reusable Docker E2E workflow. Він тримає `workflow_ref` окремо від `package_ref`, щоб current acceptance logic могла validate older trusted commits без checkout old workflow code. Release checks запускають custom Package Acceptance delta для target ref: bundled-channel compat, offline plugin fixtures і Telegram package QA against the resolved tarball. Release-path Docker suite запускає smaller chunked jobs з `OPENCLAW_SKIP_DOCKER_BUILD=1`, щоб кожен chunk pulls only the image kind it needs і executes multiple lanes through the same 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|plugins-runtime-install-e|plugins-runtime-install-f|plugins-runtime-install-g|plugins-runtime-install-h|bundled-channels`). OpenWebUI folded into `plugins-runtime-services`, коли full release-path coverage requests it, і зберігає standalone `openwebui` chunk лише для OpenWebUI-only dispatches. Legacy aggregate chunk names `package-update`, `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` досі працюють для manual reruns, але release workflow uses split chunks, щоб installer E2E і bundled plugin install/uninstall sweeps не dominated the 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 `bundled-channel-deps` lane. Кожен chunk uploads `.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` запускає selected lanes against the prepared images замість chunk jobs, що keeps failed-lane debugging bounded to one targeted Docker job і prepares, downloads, or reuses the package artifact for that run; якщо selected lane є live Docker lane, targeted job builds the live-test image locally for that rerun. Generated per-lane GitHub rerun commands include `package_artifact_run_id`, `package_artifact_name` і prepared image inputs, коли ці значення існують, щоб failed lane могла reuse the exact package and images from the failed run. Використовуйте `pnpm test:docker:rerun `, щоб download Docker artifacts from a GitHub run і print combined/per-lane targeted rerun commands; використовуйте `pnpm test:docker:timings ` для slow-lane and phase critical-path summaries. Scheduled live/E2E workflow запускає full release-path Docker suite daily. Bundled update matrix split by update target, щоб repeated npm update і doctor repair passes могли shard with other 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`, `plugins-runtime-install-e`, `plugins-runtime-install-f`, `plugins-runtime-install-g`, `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` і `bundled-channels-contracts`. Агрегований chunk `bundled-channels` залишається доступним для ручних одноразових повторних запусків, а `plugins-runtime-core`, `plugins-runtime` і `plugins-integrations` залишаються агрегованими alias для plugin/runtime, але release workflow використовує розділені chunks, щоб channel smokes, update targets, plugin runtime checks і перевірки install/uninstall bundled plugin могли виконуватися паралельно. Цільові dispatches `docker_lanes` також розділяють кілька вибраних ліній на паралельні jobs після одного спільного етапу підготовки package/image, а bundled-channel update lanes повторюють спробу один раз для тимчасових npm network failures. +Current 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`, `plugins-runtime-install-e`, `plugins-runtime-install-f`, `plugins-runtime-install-g`, `plugins-runtime-install-h`, `bundled-channels-core`, `bundled-channels-update-a`, `bundled-channels-update-discord`, `bundled-channels-update-b` і `bundled-channels-contracts`. Aggregate chunk `bundled-channels` залишається available for 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 могли run in parallel. Targeted `docker_lanes` dispatches також split multiple selected lanes into parallel jobs після одного shared package/image preparation step, а bundled-channel update lanes retry once for transient npm network failures. -Локальна логіка changed-lane міститься в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей локальний check gate суворіший щодо архітектурних меж, ніж широка область платформ CI: production-зміни core запускають core prod і core test typecheck плюс core lint/guards, зміни core лише в тестах запускають тільки core test typecheck плюс core lint, production-зміни extension запускають extension prod і extension test typecheck плюс extension lint, а зміни extension лише в тестах запускають extension test typecheck плюс extension lint. Зміни Public 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` і -навмисно дешевша за `check:changed`: прямі редагування тестів запускають самі себе, -редагування вихідного коду надають перевагу явним mappings, потім sibling tests та import-graph -dependents. Спільна конфігурація доставки group-room є одним із явних mappings: -зміни group visible-reply config, source reply delivery mode або -message-tool system prompt проходять через core reply tests плюс Discord і -Slack delivery regressions, щоб зміна спільного default падала до першого -push PR. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна -настільки широка для harness, що дешевий mapped set не є надійним proxy. +Local changed-lane logic живе в `scripts/changed-lanes.mjs` і виконується `scripts/check-changed.mjs`. Цей local check gate суворіший щодо architecture boundaries, ніж broad CI platform scope: core production changes запускають core prod і core test typecheck плюс core lint/guards, core test-only changes запускають лише core test typecheck plus core lint, extension production changes запускають extension prod і extension test typecheck plus extension lint, а extension test-only changes запускають extension test typecheck plus extension lint. Public Plugin SDK або plugin-contract changes expand to extension typecheck, бо extensions залежать від цих core contracts, але Vitest extension sweeps є explicit test work. Release metadata-only version bumps запускають targeted version/config/root-dependency checks. Unknown root/config changes fail safe to all check lanes. +Local changed-test routing живе в `scripts/test-projects.test-support.mjs` і +навмисно дешевший за `check:changed`: direct test edits запускають themselves, +source edits prefer explicit mappings, потім sibling tests і import-graph +dependents. Shared group-room delivery config є одним з explicit mappings: +зміни до group visible-reply config, source reply delivery mode або +message-tool system prompt route through the core reply tests плюс Discord і +Slack delivery regressions, щоб shared default change failed before the first PR +push. Використовуйте `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` лише тоді, коли зміна +достатньо harness-wide, що cheap mapped set не є trustworthy proxy. -Для валідації Testbox запускайте з кореня репозиторію й надавайте перевагу свіжому прогрітому боксу для -широкого підтвердження. Перед тим як витрачати повільний gate на бокс, який повторно використали, термін дії якого сплив або -який щойно повідомив про неочікувано велику синхронізацію, спершу запустіть `pnpm testbox:sanity` всередині -бокса. Sanity-перевірка швидко падає, коли потрібні кореневі файли, як-от -`pnpm-lock.yaml`, зникли або коли `git status --short` показує щонайменше 200 -відстежуваних видалень. Зазвичай це означає, що стан віддаленої синхронізації не є надійною -копією PR. Зупиніть цей бокс і прогрійте свіжий замість налагодження -збою продуктового тесту. Для PR з навмисними великими видаленнями встановіть -`OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього sanity-запуску. `pnpm -testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у -фазі синхронізації понад п’ять хвилин без виводу після синхронізації. Встановіть -`OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей запобіжник, або використайте більше -значення в мілісекундах для незвично великих локальних diff. +Для перевірки Testbox запускайте з кореня репозиторію й надавайте перевагу свіжому прогрітому боксу для широкого підтвердження. Перед тим як витрачати повільний gate на бокс, який було повторно використано, термін дії якого минув або який щойно повідомив про неочікувано велику синхронізацію, спочатку запустіть `pnpm testbox:sanity` всередині боксу. Перевірка справності швидко завершується з помилкою, коли зникли обов’язкові кореневі файли, як-от `pnpm-lock.yaml`, або коли `git status --short` показує щонайменше 200 відстежуваних видалень. Зазвичай це означає, що стан віддаленої синхронізації не є надійною копією PR. Зупиніть цей бокс і прогрійте свіжий замість налагодження збою продуктового тесту. Для PR із навмисними великими видаленнями встановіть `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` для цього запуску перевірки справності. `pnpm testbox:run` також завершує локальний виклик Blacksmith CLI, який залишається у фазі синхронізації понад п’ять хвилин без виводу після синхронізації. Установіть `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0`, щоб вимкнути цей захист, або використайте більше значення в мілісекундах для незвично великих локальних diff. -Ручні CI-запуски виконують `checks-node-compat-node22` як широке покриття сумісності. Android є опційним для окремого ручного CI через `include_android=true` і завжди ввімкнений для `Full Release Validation`. `Plugin Prerelease` має дорожче покриття продукту/пакетів, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push у `main` і окремі ручні CI-запуски тримають цей набір вимкненим. +Ручні запуски CI виконують `checks-node-compat-node22` як широке покриття сумісності. Android вмикається окремо для автономного ручного CI через `include_android=true` і завжди ввімкнений для `Full Release Validation`. `Plugin Prerelease` є дорожчим покриттям продукту/пакета, тому це окремий workflow, який запускається `Full Release Validation` або явним оператором. Звичайні pull request, push у `main` і автономні ручні запуски CI тримають цей набір вимкненим. -Найповільніші родини тестів Node розділено або збалансовано, щоб кожна job залишалася малою без надмірного резервування раннерів: контракти каналів виконуються як три зважені шарди, малі core unit lanes поєднані парами, auto-reply запускається як чотири збалансовані worker-и з піддеревом reply, розділеним на шарди agent-runner, dispatch і commands/state-routing, а agentic gateway/plugin configs розподілені між наявними source-only agentic Node jobs замість очікування на built artifacts. Широкі browser, QA, media і miscellaneous plugin tests використовують свої dedicated Vitest configs замість спільного plugin catch-all. `Plugin Prerelease` балансує bundled plugin tests між вісьмома extension workers; ці extension shard jobs запускають до двох plugin config groups одночасно з одним Vitest worker на групу й більшим Node heap, щоб import-heavy plugin batches не створювали додаткові CI jobs. Широка agents lane використовує спільний Vitest file-parallel scheduler, бо вона обмежена імпортами/плануванням, а не одним повільним тестовим файлом. `runtime-config` виконується з infra core-runtime shard, щоб shared runtime shard не володів хвостом. Include-pattern shards записують timing entries з назвою CI shard, тож `.artifacts/vitest-shard-timings.json` може відрізнити цілу config від відфільтрованого shard. `check-additional` тримає package-boundary compile/canary work разом і відокремлює runtime topology architecture від gateway watch coverage; boundary guard shard запускає свої малі незалежні guards паралельно всередині однієї job. Gateway watch, channel tests і core support-boundary shard виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` вже зібрані, зберігаючи свої старі check names як легкі verifier jobs і водночас уникаючи двох додаткових Blacksmith workers та другої artifact-consumer queue. -Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane все одно компілює цей flavor з SMS/call-log BuildConfig flags, уникаючи дублювання debug APK packaging job під час кожного Android-relevant push. -GitHub може позначати витіснені jobs як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо найновіший run для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тож вони все одно повідомляють про звичайні shard failures, але не стають у чергу після того, як увесь workflow уже був витіснений. -Автоматичний CI concurrency key має версію (`CI-v7-*`), щоб GitHub-side zombie у старій queue group не міг нескінченно блокувати новіші main runs. Ручні full-suite runs використовують `CI-manual-v1-*` і не скасовують in-progress runs. +Найповільніші сімейства тестів Node розділено або збалансовано так, щоб кожне завдання залишалося невеликим без надмірного резервування runner: контрактні перевірки каналів виконуються як три зважені shard, малі core unit lane об’єднано в пари, auto-reply виконується як чотири збалансовані worker із піддеревом reply, розділеним на shard для agent-runner, dispatch і commands/state-routing, а agentic gateway/plugin configs розподілено між наявними source-only agentic Node завданнями замість очікування на зібрані артефакти. Широкі browser, QA, media та різні plugin тести використовують власні конфіги Vitest замість спільного plugin catch-all. `Plugin Prerelease` балансує тести bundled plugin між вісьмома extension worker; ці extension shard завдання запускають до двох груп plugin config одночасно з одним Vitest worker на групу та більшим heap Node, щоб import-heavy plugin пакети не створювали додаткових CI завдань. Широка agents lane використовує спільний file-parallel планувальник Vitest, бо вона визначається імпортом/плануванням, а не одним повільним тестовим файлом. `runtime-config` виконується разом з infra core-runtime shard, щоб спільний runtime shard не володів хвостом. Include-pattern shards записують timing entries з використанням назви CI shard, тому `.artifacts/vitest-shard-timings.json` може відрізнити цілий config від відфільтрованого shard. `check-additional` тримає package-boundary compile/canary роботу разом і відокремлює архітектуру runtime topology від покриття gateway watch; boundary guard shard запускає свої малі незалежні guard паралельно всередині одного завдання. Gateway watch, тести каналів і core support-boundary shard виконуються паралельно всередині `build-artifacts` після того, як `dist/` і `dist-runtime/` уже зібрані, зберігаючи їхні старі назви перевірок як легкі verifier jobs, але уникаючи двох додаткових Blacksmith worker і другої черги споживачів артефактів. +Android CI запускає і `testPlayDebugUnitTest`, і `testThirdPartyDebugUnitTest`, а потім збирає Play debug APK. Third-party flavor не має окремого source set або manifest; його unit-test lane усе ще компілює цей flavor із прапорцями BuildConfig для SMS/call-log, уникаючи дублювання завдання пакування debug APK для кожного push, релевантного Android. +GitHub може позначати замінені завдання як `cancelled`, коли новіший push потрапляє в той самий PR або ref `main`. Вважайте це шумом CI, якщо найновіший запуск для того самого ref також не падає. Aggregate shard checks використовують `!cancelled() && always()`, тому вони все ще повідомляють звичайні збої shard, але не стають у чергу після того, як увесь workflow уже було замінено. +Автоматичний ключ конкурентності CI версійовано (`CI-v7-*`), щоб zombie з боку GitHub у старій групі черги не міг нескінченно блокувати новіші запуски main. Ручні full-suite запуски використовують `CI-manual-v1-*` і не скасовують уже запущені виконання. -## Ранери +## Runner -| Ранер | Jobs | +| Runner | Завдання | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `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 завдання й aggregate (`security-scm-fast`, `security-dependency-audit`, `security-fast`), швидкі protocol/contract/bundled перевірки, sharded channel contract перевірки, `check` shards окрім lint, `check-additional` shards і aggregate, Node test aggregate verifiers, перевірки документації, Python skills, workflow-sanity, labeler, auto-response; install-smoke preflight також використовує GitHub-hosted Ubuntu, щоб Blacksmith matrix могла стати в чергу раніше | +| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`, нижчі за вагою extension shards, `checks-fast-core`, `checks-node-compat-node22`, `check-prod-types` і `check-test-types` | | `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`, build-smoke, Linux Node test shards, bundled plugin test shards, `android` | -| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо CPU-sensitive, тож 8 vCPU коштували більше, ніж заощаджували; install-smoke Docker builds, де час у черзі для 32-vCPU коштував більше, ніж заощаджував | +| `blacksmith-16vcpu-ubuntu-2404` | `check-lint`, який залишається достатньо чутливим до CPU, тож 8 vCPU коштували більше, ніж заощаджували; install-smoke Docker builds, де час очікування в черзі 32-vCPU коштував більше, ніж заощаджував | | `blacksmith-16vcpu-windows-2025` | `checks-windows` | -| `blacksmith-6vcpu-macos-latest` | `macos-node` на `openclaw/openclaw`; forks повертаються до `macos-latest` | -| `blacksmith-12vcpu-macos-latest` | `macos-swift` на `openclaw/openclaw`; forks повертаються до `macos-latest` | +| `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 @@ -460,4 +373,4 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac ## Пов’язане - [Огляд встановлення](/uk/install) -- [Канали релізів](/uk/install/development-channels) +- [Канали випусків](/uk/install/development-channels)